3.1 proceso de desarrollo de software -...

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


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.


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]


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 de tratar

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


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:


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


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


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]


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 DAFO

Para 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:


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.


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:


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.


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 previstos y 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).


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.


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


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


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 comportamiento del 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.


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:


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:


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.


77

3.1 proceso de desarrollo de software -...

Documents