CapÃ_tulo 3

Vista previa del material en texto

Arquitectura de Fault Tolerance System distribuido entre UAVs 
 
57 
 
 
3. Gestión de Proyectos Software 
 
3.1 Proceso de desarrollo de software 
El proceso de desarrollo de software se refiere principalmente al aspecto de la 
producción de software, tales como herramientas de software. Estos procesos se 
emplean fundamentalmente para apoyar la gestión de desarrollo de software, y en 
general están enfocadas hacia la solución de problemas empresariales. Muchos procesos 
de desarrollo de software se pueden ejecutar de forma similar a los procesos generales 
de gestión de proyectos. 
Una de las claves principales de la gestión de proyectos es la gestión del riesgo. La 
gestión del riesgo es el proceso de medir o evaluar el riesgo y el desarrollo de 
estrategias para gestionar el riesgo. En general, las estrategias empleadas incluyen 
transferir el riesgo a otra parte independiente del proyecto, evitar el riesgo, reducir el 
efecto negativo del riesgo, y la aceptación de todas o algunas de las consecuencias de un 
riesgo particular. La gestión del riesgo en la gestión de proyectos de software comienza 
con las reglas de negocios para iniciar el proyecto, que incluye un análisis de costo-
beneficio, así como una lista de opciones de respaldo para el fracaso del proyecto, 
llamado plan de contingencia. 
Un subconjunto de la gestión de riesgos que está ganando cada vez más atención es la 
Gestión de Oportunidades, lo que significa la misma cosa, sólo que el resultado del 
riesgo potencial tendrá un efecto positivo, en lugar de un impacto negativo. Aunque 
teóricamente se manejan de la misma manera, el uso del término "oportunidad" en lugar 
del término “riesgo”, como algo negativo, ayuda a mantener el equipo centrado en los 
posibles resultados positivos de cualquier riesgo dado que pueda registrarse en el 
proyecto, como proyectos spin-off, ganancias inesperadas, o liberar recursos 
adicionales. 
La gestión de requisitos es el proceso de identificación, documentación, análisis, 
seguimiento, priorización y consenso de los requisitos además del control del cambio y 
la comunicación de las partes interesadas pertinentes. La parte de la gestión de 
requisitos, que incluye el análisis de requerimientos, es una parte importante del proceso 
de ingeniería de software, por lo que los analistas de negocios o desarrolladores de 
software identifican las necesidades o requerimientos de un cliente. Posteriormente, una 
vez identificados estos requisitos se procede al diseño de la solución deseada. 
Otra parte importante de la gestión de proyectos es la gestión del cambio. La gestión del 
cambio es el proceso de identificar, documentar, analizar, priorizar y acordar cambios 
durante el desarrollo del proyecto. El análisis de impacto del cambio en el desarrollo (ya 
Arquitectura de Fault Tolerance System distribuido entre UAVs 
 
58 
 
sea un ámbito nuevo o alterado) es también una parte importante del proceso de 
ingeniería de software. El equipo de desarrollo de software identifica las necesidades 
que han cambiado o requerimientos nuevos de un cliente, y una vez identificados, estos 
requisitos forman la base para el diseño modificable de la solución buscada. 
Teóricamente, cada cambio puede afectar el cronograma y presupuesto de un proyecto 
de software, y por lo tanto, por definición, se debe incluir el riesgo-beneficio antes de su 
aprobación. 
Para llevar a cabo una gestión de proyectos adecuada hace falta realizar una gestión de 
versiones. La Gestión de Versiones es el proceso de identificar, documentar, priorizar y 
consensuar los lanzamientos de software, así como controlar las fechas de lanzamientos 
y comunicar a las partes interesadas pertinentes. La mayoría de los proyectos de 
software pueden lanzar versiones con diferentes estados, siendo estos en desarrollo, en 
prueba o en producción. En proyectos muy grandes, donde los equipos están muy 
distribuidos, estos necesitan integrar su trabajo antes del lanzamiento de programas 
funcionales a los usuarios. A menudo, puede haber más de un estado de prueba, es 
decir, este estado puede referirse a pruebas unitarias o pruebas de integración, antes de 
su lanzamiento para las pruebas de aceptación del usuario (UAT). [56] 
 
 
3.2 PLANIFICACIÓN SCRUM 
Scrum es un marco de trabajo de desarrollo ágil de software iterativo e incremental para 
gestionar proyectos o productos. En pocas palabras, Scrum es un proceso en el que se 
aplican de manera regular un conjunto de buenas prácticas para trabajar 
colaborativamente, en equipo, y obtener así el mejor resultado de un proyecto. 
Una de las claves principales en Scrum es que se tiene en cuenta que los clientes pueden 
cambiar de opinión sobre lo que quieren y necesitan durante el desarrollo del producto, 
es decir cambian los requisitos. En este sentido, Scrum adopta un enfoque empírico, 
aceptando que el problema inicial no puede ser totalmente comprendido o definido 
(debido a la naturaleza cambiante de este), y enfocando a su vez en maximizar la 
habilidad del equipo a la hora de la entregar código funcional que cumpla con los 
requisitos variables. 
 
Roles 
En el Scrum, procedimiento que se basa en un conjunto de acciones definidas, con la 
ayuda de la acción de las personas y la combinación de la tecnología, se diferencian 
ciertos roles: los roles principales, que son tres, y una serie de roles auxiliares. 
Arquitectura de Fault Tolerance System distribuido entre UAVs 
 
59 
 
Los roles vinculados al proyecto en el proceso Scrum y los que llevan a cabo el producir 
el producto (objetivo) son los roles principales, y a su vez representan al equipo 
llamando en adelante equipo Scrum. 
 
Roles principales 
 
Product owner 
El Product Owner se considera como la voz del cliente. Su labor es asegurar que 
el equipo ofrezca un valor para el negocio, y se centra en el producto basándose 
en el enfoque del cliente y en las historias de uso dándoles una prioridad en los 
Product Backlog. 
Los equipos Scrum deben configurarse con ciertos roles como es el Product 
Owner, quien a su vez es parte del equipo de desarrollo. No conviene que se 
combine con el Scrum Master, aunque en ciertos entornos empresariales se 
combina con el Project Manager, ya que ofrece una mayor visión del alcance del 
producto. 
 
Equipo 
El equipo se suele componer de entre 5 o 9 personas multifuncionales. Su 
trabajo consiste en analizar, diseñar, desarrollar, probar la comunicación técnica, 
documentar, etc. siendo su responsabilidad final el conseguir potenciales 
incrementos en el producto al final de cada Sprint. Se trata de un equipo 
organizado por sí mismo, aunque existe cierta comunicación con la gestión de 
proyectos. 
 
Scrum Master 
El Scrum Master es quien debe velar por la buena marcha del proyecto para 
conseguir el objetivo del Sprint, y ha de eliminar los obstáculos que aparezcan 
para su equipo. 
 No se trata de ser un líder del equipo sino de tener el comportamiento de 
amortiguador para que las influencias que pudieran darse no perturben al equipo. 
También ha de hacer que se cumplan las reglas, para ello presidirá reuniones 
importantes y motivará al equipo para mejorar. 
Su diferencia con la del Project Manager reside en que éste último puede tener 
responsabilidad sobre la gestión de personas externas, es decir, no relacionadas 
con el equipo Scrum. [57] 
 
 
 
Arquitectura de Fault Tolerance System distribuido entre UAVs 
 
60 
 
 
Roles auxiliares 
Se trata de aquellos que no tienen una participación frecuente y formal en el proceso 
Scrum; no obstante han de tenerse en cuenta: 
 
Project Manager 
Esta persona juega el rol de responsable para que el proyecto sea un éxito 
 
El Project Executive y el Project Board 
En todo proyecto existen impedimentos y problemas que han de ser tratados fuera del 
equipo Scrum. El Project Executive y el Project Board serán los responsables detratar 
estos casos. 
 
Asesores de Proyecto 
Cuando el equipo Scrum deba consultar algo, estas son las personas a las que deben 
acudir. El grupo de Asesores de Proyecto está compuesto por representantes del Senior 
Supplier, del Senior User y por el Project Executive. 
 
Managers 
Los manager como en cualquier proyecto son la personas que controlan de forma 
general el entorno de trabajo. 
 
Inversores y partes interesadas 
Se trata de personas que de forma continua interactúan tanto con el grupo de Asesores 
como con el equipo Scrum. 
En ocasiones los propios clientes, los usuarios finales o bien los proveedores son los 
inversores. Y si lo desean pueden estar involucrados en el proceso Scrum durante la 
revisión del sprint. [58] 
 
 
 
Sprint 
 
Arquitectura de Fault Tolerance System distribuido entre UAVs 
 
61 
 
 
Figura 9: Proceso de Scrum. 
 
Se trata de la unidad básica y principal de desarrollo del proceso Scrum (en la figura 9 
se puede ver el proceso Scrum). Lo característico del Sprint es que: 
-Tiene una " duración fija " de esfuerzo, fijada por anticipado y es norma que dure 
entre una semana y un mes. 
-Cada Sprint es precedido por una reunión de planificación, basada en: 
· Identificación de tareas para el sprint. 
· Estimación de los objetivos de sprint. 
· Revisión/reunión retrospectiva. 
· Examinación del progreso. 
· Identificación de tareas para el próximo sprint. 
 
Reuniones 
 
Scrum Diario 
 
 
Figura 10: Scrum diario en el lugar común de trabajo. 
 
El equipo de proyecto realiza una reunión cada día durante el sprint y sigue las 
siguientes reglas: 
Arquitectura de Fault Tolerance System distribuido entre UAVs 
 
62 
 
· El equipo de desarrollo ha de presentarse preparado con las novedades 
para tratar en la reunión. 
· La reunión comienza puntual, incluso si algún miembro del equipo de 
desarrollo no se encuentra presente. 
· Ha de tener lugar el mismo sitio y a la misma hora cada día (vea figura 
10). 
· Será de duración fija, de 15 minutos o menos. 
· Generalmente solo hablan activamente los miembros principales. 
Las obligaciones de los miembros del equipo son responder a: 
· ¿Qué has hecho desde ayer? 
· ¿Qué piensas hacer hoy? 
· ¿Impedimentos / tropiezos? En el caso de haberlos, se identificarán y 
documentarán por el Scrum Master, y fuera de la reunión se procederá a su 
resolución. 
 
Backlog refinement (grooming) 
Se trata de un proceso de creación de historias, y si se consideran demasiado grandes en 
su inicio, de su descomposición y de la creación en otras más pequeñas. 
En este último caso han de perfeccionarse los criterios de aceptación para las historias 
individuales, y se ha de otorgar prioridad y tamaño de las individuales en el Product 
Backlog con la medición de esfuerzo / puntos. 
 
En cuanto a las reuniones para ello: 
· Máximo serán de 1h. 
· Está en manos del equipo cuántas sesiones por semana consideran 
necesarias. 
 
Scrum de Scrums 
Es otro tipo de encuentro, generalmente tras el scrum diario. Aquí asiste una persona 
asignada de cada grupo de scrum y pueden discutir su trabajo, 
Es idéntico al scrum diario, con la adición de las siguientes cuestiones: 
· ¿Qué ha hecho su equipo desde la última reunión? 
· ¿Qué va a hacer su equipo antes de la siguiente reunión? 
· ¿Hay algo atrasando a su equipo? 
· ¿Se va a cargar algo a otro equipo? 
 
Reunión de planificación de Sprint 
Hay que realizar una "reunión de planificación de Sprint" al comienzo del ciclo (cada 7-
30 días). Se trata de seleccionar el trabajo por hacer, preparar el Sprint Backlog 
detallado en cuanto a tiempo necesario para realizar el trabajo con todo el equipo. Se 
Arquitectura de Fault Tolerance System distribuido entre UAVs 
 
63 
 
tiene que identificar y comunicar la cantidad probable de trabajo para realizar en el 
sprint actual, y el plazo total es de 8 horas divididas de la siguiente forma: 
· Las primeras 4 horas: el equipo dará prioridad al Producto 
Backlog. 
· Siguientes 4 horas: el equipo de desarrollo debatirá y llevará a 
cabo el plan de sprint que ha resultado de la Sprint Backlog. 
 
 
Fin de ciclo 
Cuando acaba el ciclo sprint se dará lugar a otras dos reuniones [58]: 
"Reunión de Revisión de Sprint": 
· Revisar el trabajo completado y el trabajo planificado no completado. 
· Demo: presentar el trabajo realizado con los grupos de interés. 
· El tiempo para esta reunión es de 4 horas. 
"Sprint Retrospectivo". 
· Reflexión del sprint anterior por parte del equipo. 
· Proceso de mejora continua. 
· Preguntarse en la retrospectiva de Sprint: ¿Qué salió bien durante el 
Sprint? ¿podría mejorarse en el siguiente sprint? 
· Límite de tiempo de tres horas. 
· Esta reunión se ve facilitada por el Scrum Master. 
 
 
Objetos 
 
Product Backlog 
La Product Backlog es una lista ordenada de los "requisitos" que se mantiene 
para un producto, se entiende como el "qué" se construirá, ordenado en el orden 
relativo en el que se debe construir. Es abierto y editable por cualquier persona, 
pero el Product Owner es en última instancia responsable de ordenarlos para el 
equipo de desarrollo. Para realizar el orden se tiene en consideración el riesgo, el 
valor de negocio, las dependencias, fechas… La pendiente del producto y el 
valor comercial de cada elemento de la lista también es responsabilidad del 
Product Owner. 
Las características adicionales del Product Backlog se escriben normalmente en 
formato de historia. 
El equipo de desarrollo también forma parte de este objeto. Se encarga de 
determinar el esfuerzo estimado para completar cada elemento. El equipo 
Arquitectura de Fault Tolerance System distribuido entre UAVs 
 
64 
 
contribuye mediante la estimación de elementos e historias de uso, ya sea en la 
dotación de los puntos o de horas estimadas. 
 
Sprint Backlog 
 
Figura 11: Task board. 
 
La responsabilidad del Sprint Backlog recae sobre el equipo de desarrollo. Se 
trata de una lista de trabajo que se debe abordar en el siguiente sprint. 
La creación de esta lista se obtiene mediante la selección de historias / 
características de la parte superior del Product Backlog, y tiene fin cuando el 
equipo considera que hay suficiente trabajo para cargar en otro sprint. 
Para ello se ha de tener en cuenta la velocidad de los Sprints anteriores y utilizar 
este número como una guía de refencia de la cantidad de "esfuerzo" que se 
puede completar. 
Las tareas del Sprint Backlog nunca son asignadas, sino que los miembros del 
equipo se inscriben a ellas según sea necesario durante el Scrum diario. Deberían 
de ser normalmente entre cuatro y dieciséis horas de trabajo. Esto promueve la 
auto-organización del equipo de desarrollo. 
Generalmente se ayudan de una task board (vea figura 11) con el fin de ver y 
modificar el estado de las tareas en curso, y se utilizan palabras tan sencillas 
como: "to do", "in progress" y "done". 
Finalmente cuando un Sprint ha sido entregado, la pendiente del producto se 
analiza y re-prioriza de nuevo si es necesario, y se seleccionarían el siguiente 
conjunto de funcionalidades para el próximo Sprint. 
 
Incremento 
Se trata de un aumento, y es la suma de todas las historias de usuario de 
productos terminados durante un sprint y todos los sprints anteriores. Esta suma 
ha de hacerse al final de un sprint. [59] 
Arquitectura de Fault Tolerance System distribuido entre UAVs 
 
65 
 
 
 
Burn down 
 
Figura 12: Una iteración completada, mostrando el esfuerzo y tareas restantes para cada uno de los 21 días de 
trabajo de la iteración. 
 
Es un gráfico destinado (vea figura 12) a mostrar el trabajo que queda en el 
Sprint Backlog. Se actualiza diariamente. Actualizado cada día para dar una 
visión simple de la marcha del sprint y con la posibilidad de visualizaciones 
rápidas para tomar referencias. 
 
 
 
 
 
3.3 Análisis DAFOPara analizar la viabilidad del proyecto tanto en factores internos como externos, se ha 
realizado un análisis DAFO, conociendo a través de esta herramienta los puntos fuertes 
por los que apostar y oportunidades que debemos explotar, así como combatir nuestras 
debilidades y amenazas: 
 
 
 
Arquitectura de Fault Tolerance System distribuido entre UAVs 
 
66 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Figura 13: Cuadro DAFO 
 
 
Una vez realizado el análisis, se establecen las distintas estrategias que se pueden llevar 
a cabo: 
 
Debilidades reforzadas con nuestros puntos fuertes: 
 
ü D1-F3: El tiempo limitado puede verse mejor aprovechado gracias al 
asesoramiento y ayuda de compañeros del departamento. 
ü D2-F2: El desarrollo aislado de la arquitectura con respecto a Fault Tolerance 
System se suple con reuniones directas con la Universidad. 
F1: Todo el equipo y material necesario para llevar a cabo el 
desarrollo del proyecto. 
F2: Reuniones directas con el departamento correspondiente en la 
Universidad. 
F3: Personal cualificado en el laboratorio, cuya experiencia sirve de 
gran ayuda. 
F4: Uso de metodologías ágiles, se gana experiencia con el trabajo de 
los compañeros, conciencia de la situación y estado del proyecto. 
F5: Los integrantes del departamento trabajan en proyectos similares 
y se comparte el conocimiento. 
F6: Vigilancia tecnológica. 
F7: Uso de una bien documentada wikipage 
 
O1: El proyecto se integra dentro de EC-SAFEMOBILE. 
 
O2: Posibilidad de utilizar productos internos y reusar arquitecturas 
software. 
O3: Creación de sinergias de red (colaboraciones con otros proyectos 
y con la Universidad de Sevilla). 
O4: Posibilidad de reutilizar este proyecto para proyectos futuros. 
O5: Uso de software libre. 
O6: Seguimiento de pautas de certificados y normas de calidad. 
 
D1: Tiempo muy limitado. 
D2: Desarrollo de la arquitectura y del sistema de tolerancia de 
fallos de manera aislada. 
D3: Disponibildad limitada de asistencia técnica por parte del 
tutor 
D4: Sin capacidad de uso de licencias. 
D5: Capacidad limitada de Vigilancia tecnológica. 
D6: No se hace uso de certificados y normas de calidad. 
 
 
A1: Necesidad de asistencia por parte del tutor. 
A2: Cambios en los requisitos del proyecto. 
A3: Desarrollo de la arquitectura independientemente del 
sistema de tolerancia de fallos (desarrollado en la Universidad) 
A4: La arquitectura no puede ser testada mas que con un 
dummy. 
 
 
Arquitectura de Fault Tolerance System distribuido entre UAVs 
 
67 
 
ü D3-F4: El uso de metodologías ágiles eficiencia el tiempo disponible con el 
tutor, el cual tiene consciencia del estado del proyecto al tener reuniones diarias, 
que provoca que la comunicación sea rápida y efectiva. 
ü D5-F6: La capacidad limitada de vigilancia tecnológica puede verse aumentada 
teniendo consciencia del estado de los demás proyectos desarrollados en el 
departamento, que al englobarse estos en el mismo sector, podemos valernos de 
la información que se maneja, al igual que de sus respectivas vigilancias 
tecnológicas. 
 
Debilidades reforzadas con oportunidades: 
 
ü D1-O2: El limitado tiempo puede verse aumentado si ahorramos tiempo usando 
las arquitecturas software anteriormente desarrolladas en el departamento en vez de 
desarrollarlas desde cero. 
ü D4-O5: El limitado uso del software de pago debido al coste de las licencias, 
puede verse apoyado por el uso de software libre. 
ü D6-O6: Aun sin obtener certificados o reconocimientos de la calidad del 
software, se hace un seguimiento de las pautas de esto para conseguir la mayor calidad 
posible como producto Arquitectura del sistema. 
Amenazas reforzadas con nuestros puntos fuertes: 
 
ü A1-F7: Al existir una wikipage bien documentada se puede paliar la necesidad 
de asistencia del tutor. Se hace usos de toda esta documentación, a lo que guía de 
instalaciones y documentación generada en anteriores proyectos se refiere. 
ü A2-F4: Una de las claves del desarrollo ágil es la flexibilidad en el desarrollo 
atendiendo a los cambios de requisitos durante el desarrollo del proyecto, por lo que los 
cambios en los requisitos pueden ser altamente tolerados. 
ü A4-F1: Aun no pudiéndose testear la arquitectura con su correspondiente 
sistema, en el departamento de Simulación y Software se cuenta con todo el equipo para 
el correcto funcionamiento de Fault Tolerance System que se encuadrara dentro de EC-
SAFEMOBIL, por lo que se ha testado el funcionamiento de todos los módulos 
desarrollados. 
 
Amenazas reforzadas con oportunidades: 
Arquitectura de Fault Tolerance System distribuido entre UAVs 
 
68 
 
ü A3-O3: La creación de sinergias con otros proyectos similares ayudan a la 
adquisición de experiencia y conocimiento que palian los desarrollos independientes de 
arquitectura y sistema. 
 
Puntos fuertes para ser aprovechados por oportunidades: 
 
ü F1-O1: El sistema de tolerancia de fallos dispone de toda la arquitectura 
operativa, equipo y material necesario para finalizar con éxito este subproyecto de EC-
SAFEMOBIL. 
ü F7-O4: Se puede hacer uso de la wikipage del departamento de Simulación y 
Software, para bien documentar el presente proyecto a modo que su arquitectura pueda 
ser reusada en posteriores proyectos. 
 
 
 
 
 
 
 
 
 
 
3.4 GESTIÓN DE LA CALIDAD DEL SOFTWARE 
 
La Gestión de la Calidad es un campo que aún no goza de mucha popularidad en el 
desarrollo software en contraposición a otros campos de la ingeniería donde la práctica 
de la gestión de la calidad está presente en la mayoría de los proyectos. Esta práctica 
provee al proyecto de técnicas, normas, condiciones y de una correcta comunicación 
para el mejor desarrollo posible para conseguir un producto que satisfaga en lo máximo 
posible al usuario haciendo uso del mínimo de recursos posibles. A modo de llevar a 
cabo una gestión adecuada se ha seguido (aunque no certificado) la norma ISO/IEC 
25000, que ya se detallará posteriormente. 
Arquitectura de Fault Tolerance System distribuido entre UAVs 
 
69 
 
 
Definiciones 
 
El objetivo de la Gestión de Calidad de Software (Software Quality Management, SQM) 
no es solamente la propia gestión como su nombre indica, sino también su proceso de 
desarrollo. Además, ha de entenderse como una cultura, la Cultura de Calidad; siendo 
ésta un ambiente organizacional donde la calidad es vista como una responsabilidad de 
todos. 
Cuando se habla de un producto de calidad, se habla de un producto que cumple con sus 
necesidades y que además satisface al usuario. 
 
3.4.1 Descripción 
Cogiendo como referencia al equipo científico de Ian Sommerville, se puede utilizar la 
Gestión de Calidad de Software (SQM) como un conjunto de capas de calidad. Estas 
capas de calidad se clasifican de la siguiente manera: 
· Garantía de Calidad del Software (Software Quality Assurance, SQA) 
· Plan de Calidad del Software (Software Quality Plan, SQP) 
· Control de Calidad del Software (Software Quality Control, SQC) 
Garantía de Calidad de Software (SQA) 
Para cumplir con una garantía mínima en cuanto a la Calidad del Software conviene 
seguir una guía de calidad en la propia organización. 
Esta guía debe tratar una serie de normas, reglamentos y procedimientos a seguir; y a su 
vez verificar, evaluar y confirmar los equipos de trabajo durante el ciclo de vida del 
desarrollo de software; basándose en el conocimiento de las mejores prácticas y 
aplicándose herramientas Off-The-Shelf. 
Plan de Calidad del Software (SQP) 
Se entiende como un plan de calidad, un proyecto escrito donde se declara el 
compromiso de seguir un conjunto de normas aplicables y reguladoras, y unos 
procedimientos y herramientas a utilizar durante todo el ciclo de vida del desarrollo. 
Es importante que el plan contenga los objetivos de calidad que se deben alcanzar, así 
como los riesgos previstosy la gestión de estos. Algunas acciones del SQP derivan de: 
· Componentes adaptados a las necesidades del proyecto según la Garantía de 
Calidad del Software (SQA). 
Arquitectura de Fault Tolerance System distribuido entre UAVs 
 
70 
 
· Nuevos procedimientos, estándares y herramientas que complementen lo que 
pudiera faltar o no se aplique en la SQA o bien sean importados de fuera de la 
organización. 
· Cualquier desviación del SQA que deba ser justificada por el director del 
proyecto y confirmada por la dirección de la empresa. 
 
Control de Calidad de Sofware(SQC) 
Esta capa asegura que tanto el proceso SQA como SQP estén siendo seguidos por el 
equipo de desarrollo, e incluye actividades como [60]: 
· Orientación de cómo realizar documentos, bien definidos con plantillas estándar. 
· Aconsejar cómo llevar a cabo los procesos estándar, como pueden ser las 
revisiones de calidad tanto para verificar, como para evaluar y confirmar el 
producto. 
· Verificación y evaluación para la mejora de la utilización de los métodos, 
procedimientos y herramientas para el software adoptado. 
El objetivo que persigue el SQC es: 
· Asegurar que el Software alcanza el nivel requerido de calidad. 
· Alentar a todo el equipo con la "cultura de calidad", y que sea vista como una 
responsabilidad de todos los miembros de la organización. 
· Reducir la curva de aprendizaje y ayudar con la continuidad en caso de cambiar 
la posición a los miembros del equipo dentro de la organización. 
· La prevención de fallos a través de un desarrollo adecuado. 
(Cabe citar que muchas personas usan los términos SQM y SQA indistintamente) 
 
 
 
3.4.2 Calidad del Producto Software y la norma ISO/IEC 
 
Hoy en día el desarrollo y la selección de los productos de software son muy 
importantes. Y tanto es así que las especificaciones exhaustivas y la evaluación de 
calidad del producto del software son factores primordiales para garantizar la calidad 
adecuada. 
Todas las características de calidad de un producto software son especificadas y 
evaluadas siempre que sea posible con el uso de medidas validadas y ampliamente 
aceptadas. 
Arquitectura de Fault Tolerance System distribuido entre UAVs 
 
71 
 
La calidad del producto junto con la calidad del proceso son los aspectos más 
importantes actualmente en el desarrollo de Software. En calidad del producto 
recientemente ha aparecido una nueva versión de la norma ISO/IEC 9126: la norma 
ISO/IEC 25000. 
En lo que se refiere a calidad del producto la norma ISO/IEC 25000 proporciona una 
guía para el uso de las nuevas series de estándares internacionales, llamados Requisitos 
y Evaluación de Calidad de Productos de Software (SQuaRE). Constituyen una serie de 
normas basadas en la ISO 9126 y en la ISO 14598 (Evaluación del Software), y su 
objetivo principal es guiar el desarrollo de los productos de software con la 
especificación y evaluación de requisitos de calidad. Establece criterios para la 
especificación de requisitos de calidad de productos software, sus métricas y su 
evaluación. 
Así como las características de calidad y sus medidas son útiles no solo para la 
evaluación del producto de Software, sino también para definir requisitos de calidad; el 
predecesor de SQuaRE, ISO/IEC 9126:1991 ha sido reemplazado por dos Estándares 
Internacionales: 
- ISO/IEC 9126, para la calidad del producto del Software (Software Product 
Quality) 
- ISO/IEC 14598, para la evaluación del producto del Software (Software Product 
Evaluation) 
El fin que se pretende conseguir con estos Estándares Internacionales es moverse a una 
lógica organizada y enriquecer y unificar las series cubriendo los dos principales 
procesos: 
- los requisitos de especificación de la calidad del Software y, 
- la evaluación de la calidad del Software con el apoyo de un proceso de medición 
para su calidad. 
El propósito de la serie SQuaRE de Estándares Internacionales es ayudar a aquellos 
productos de Software a que sean desarrollados y adquiridos bajo las especificaciones y 
la evaluación de los requisitos de calidad, centrándose únicamente en la calidad del 
producto de Software. [61] 
 
 
Las diferencias más notorias entre ISO/IEC 9126, IEC 14598 y la serie de Estándares 
Internacionales SQuaRE son las que se citan a continuación: 
• La presentación de un nuevo modelo de referencia 
• Guías específicas y detalladas para cada división 
• Elementos de medida de calidad dentro de la División de Medición de la Calidad 
Arquitectura de Fault Tolerance System distribuido entre UAVs 
 
72 
 
• La introducción de la División de los Requisitos de Calidad 
• La incorporación y revisión de los procesos de evaluación 
• El uso práctico en forma de ejemplos 
• La coordinación y armonización de los contenidos con la norma ISO / IEC 
15939 
Concretando en la serie SQuaRE, ésta se divide en las siguientes divisiones: 
· ISO/IEC 2500n. División de Gestión de Calidad. 
Los estándares que forman esta división definen todos los modelos comunes, 
términos y referencias a los que se alude en las demás divisiones de SQuaRE. 
· ISO/IEC 2501n. División del Modelo de Calidad. 
El estándar que conforma esta división presenta un modelo de calidad detallado, 
incluyendo características para la calidad interna, externa y en uso. 
· ISO/IEC 2502n. División de Mediciones de Calidad. 
Los estándares pertenecientes a esta división incluyen un modelo de referencia 
de calidad del producto software, definiciones matemáticas de las métricas de 
calidad y una guía práctica para su aplicación. Presenta aplicaciones de métricas 
para la calidad de software interna, externa y en uso. 
· ISO/IEC 2503n. División de Requisitos de Calidad. 
Los estándares que forman parte de esta división ayudan a especificar los 
requisitos de calidad. Estos requisitos pueden ser usados en el proceso de 
especificación de requisitos de calidad para un producto software que va a ser 
desarrollado o como entrada para un proceso de evaluación. El proceso de 
definición de requisitos se guía por lo establecido en la norma ISO/IEC 15288 
(ISO, 2003). 
· ISO/IEC 2504n. División de Evaluación de la Calidad. 
Estos estándares proporcionan requisitos, recomendaciones y guías para la 
evaluación de un producto software, tanto si la llevan a cabo evaluadores, como 
clientes o desarrolladores. 
· ISO/IEC 25050–25099. Estándares de extensión SQuaRE. 
 Incluyen requisitos para la calidad de productos de software “Off-The-Shelf” y 
para el formato común de la industria (CIF) para informes de usabilidad. [62] 
 
 
A parte de las divisiones nombradas, la serie SQuaRE tienen un uso reservado de la 
norma ISO/IEC 25050 hasta la ISO/IEC 25099 para ser utilizadas en la extensión de los 
Estándares Internacionales y/o los informes técnicos. Y con el objetivo de facilitar el 
uso práctico de los estándares asociados y los informes técnicos, dispone de: 
• Términos y definiciones 
• Modelos de referencia 
Arquitectura de Fault Tolerance System distribuido entre UAVs 
 
73 
 
• Guía General 
• Las Guías de división individuales anteriormente nombradas 
• Normas Internacionales sobre: requisitos de especificación, planificación, 
gestión, medición y evaluación. 
 
La norma ISO 25000 ha sido desarrollada por el subcomité SC 7 (Ingeniería de 
Software y Sistemas) del Comité Técnico Conjunto ISO/IEC JTC 1; y al igual que la 
norma ISO/IEC 9126, este estándar define tres vistas diferenciadas en el estudio de la 
calidad de un producto: 
· Vista interna: esta vista se ocupa de las propiedades del software en cuanto al 
tamaño, la complejidad o la conformidad con las normas de orientación a 
objetos; y puede utilizarse desde las primeras fases del desarrollo, permitiendo 
detectar deficiencias en el software en edades muy tempranas del ciclo de vida 
del software. 
· Vista externa: es la vista que analiza el comportamientodel software, digamos 
en producción, y estudia sus atributos, lo que podrían ser, por ejemplo, el 
rendimiento de un software en una máquina determinada, el uso de memoria de 
un programa o el tiempo de funcionamiento entre fallos. Esta segunda vista, a 
diferencia de la interna, necesita que el producto software este completo y se 
utilizará por tanto en el pase a producción del producto, siendo muy dependiente 
de la máquina donde se ejecute. 
· Vista en uso: mide la productividad y la efectividad del usuario final al utilizar 
el software. Esta tercera vista también estudia el producto software finalizado y 
será dependiente del usuario a la par que estará condicionada a los factores 
personales del mismo. [62] 
 
Puede observarse que las distintas vistas se interrelacionan afectando los valores de la 
vista interna a los de la vista externa y los de la vista externa a los de la vista en uso. Así 
por ejemplo, un software con una alta complejidad probado sobre una máquina con 
bajas prestaciones tendrá un rendimiento bajo que provocará que el usuario final tenga 
un rendimiento inferior al esperado independientemente de sus factores humanos. 
 
La serie ISO 25000 no establece los niveles de calidad deseables para cada proyecto, si 
bien se recomienda que los requisitos de calidad deban ser proporcionales a las 
necesidades de la aplicación y lo crítico que debe ser el correcto funcionamiento del 
sistema implementado. 
Esta serie establece, que la calidad del producto software, está compuesta de 
características de calidad que se indican en las denominadas medidas de calidad de 
software (Software Quality Measures) (véase Figura 14), las cuales a su vez se 
componen de subcaracterísticas y estas últimas de atributos. Aunque estos últimos no 
se especifican ya que se entiende que son entidades dependientes del producto software 
y variarán según varíe la naturaleza del software analizado: lenguaje, paradigma de 
programación, complejidad tecnológica, etc. 
Arquitectura de Fault Tolerance System distribuido entre UAVs 
 
74 
 
La obtención del valor de estas medidas de calidad de software se consigue aplicando 
una función de medida (Measurement Function) a los elementos de medida de calidad 
(Quality Measure Elements). Estos elementos son medidas base o medidas derivadas 
obtenidas, según describe el método de medición correspondiente (Measurement 
Method), de acuerdo a la ISO/IEC 15939. 
 
 
 
Figura 14: Modelo de Referencia de Medición de la Calidad del Producto Software, según la ISO/IEC 25000. 
 
 
Estas mediciones dan como resultado una serie de métricas que se pueden clasificar en 
tres categorías según sea su naturaleza: 
· Métricas básicas, que se obtienen directamente de analizar el código o la 
ejecución del software. 
· Métricas de agregación, que consisten en la composición de una métrica a partir 
de un conjunto definido de métricas básicas, generalmente mediante una suma 
ponderada. 
· Métricas derivadas, que son una función matemática que utiliza como entrada el 
valor de otras métricas. [62] 
 
El modelo establece diez características, seis que son comunes a las vistas interna y 
externa y cuatro que son propias de la vista en uso. Las características que definen las 
vistas interna y externa, se muestran a continuación en la Figura 15 y son: 
 
Arquitectura de Fault Tolerance System distribuido entre UAVs 
 
75 
 
 
Figura 15: Características de la Calidad según la ISO/IEC 9126. 
 
 
 
 
· Funcionalidad, capacidad del software de proveer los servicios necesarios para 
cumplir con los requisitos funcionales. 
· Fiabilidad, capacidad del software de mantener las prestaciones requeridas del 
sistema, durante un tiempo establecido y bajo un conjunto de condiciones 
definidas. 
· Usabilidad, esfuerzo requerido por el usuario para utilizar el producto 
satisfactoriamente. 
· Eficiencia, relación entre las prestaciones del software y los requisitos 
necesarios para su utilización. 
· Mantenibilidad, esfuerzo necesario para adaptarse a las nuevas especificaciones 
y requisitos del software. 
· Portabilidad, capacidad del software de ser transferido de un entorno a otro. 
 
Mientras que las características propias de la vista en uso, son las siguientes y se 
reflejan en la Figura 16: 
Arquitectura de Fault Tolerance System distribuido entre UAVs 
 
76 
 
 
Figura 16: Características de la vista en uso. 
 
· Efectividad, capacidad del software de facilitar al usuario alcanzar los objetivos 
con precisión y completitud. 
· Productividad, capacidad del software de permitir a los usuarios gastar la 
cantidad apropiada de recursos en relación a la efectividad obtenida. 
· Seguridad, capacidad del software para cumplir con los niveles de riesgo 
permitidos tanto para posibles daños físicos como para posibles riesgos de datos. 
· Satisfacción, capacidad del software de cumplir con las expectativas de los 
usuarios en un contexto determinado. [62] 
 
Ámbito / Alcance 
Como se ha ido diciendo anteriormente, la idea de las normas o Estándares 
Internacionales es: proporcionar una Guía para el uso de las normas internacionales 
SQuaRE sobre los Requisitos de Calidad y Evaluación del producto de Software; dando 
una visión general del contenido de la serie SQuaRE, modelos de referencia y 
definiciones así como la relación entre distintas documentaciones. 
 
 
 
 
 
 
 
 
Arquitectura de Fault Tolerance System distribuido entre UAVs 
 
77