Calidad de Software

Calidad de Software

2

CARRERAS PROFESIONALES

CIBERTEC

CALIDAD DE SOFTWARE

3

ÍNDICE

Página

Presentación

7

Red de contenidos

8

Unidad de aprendizaje 1

1.1 Tema 1 : Calidad de Software

10

1.1.1. : Definición de Calidad

10

1.1.2. : Política de Calidad

11

1.1.3. : Terminología según ISO 8402

11

1.1.4. : Definición de Calidad de Software

13

1.2 Tema 2 : Aseguramiento y Control de Calidad

20

1.2.1. : SQA (Software Quality Assurance) no es lo mismo que

21

SQC (Software Quality Control) 1.2.2. : Funciones Generales del SQA

22

1.3 Tema 3 : Modelo de Procesos

25

1.3.1. : El Proceso de Desarrollo de Software

27

1.3.2. : Normas Relacionados con el Proceso de Desarrollo de

30

Software 1.3.3. : Los Procesos ISO 12207:2008

34

1.4 Tema 4 : Modelo de Ciclo de Vida de Software

35

CIBERTEC

1.4.1. : Codificar y Corregir (Code-and-Fix)

35

1.4.2. : Modelo en Cascada

35

1.4.3. : Desarrollo Evolutivo

37

1.4.4. : Desarrollo Formal de Sistemas

38

1.4.5. : Desarrollo Basado en Reutilización

39

1.4.6. : Procesos Iterativos

40

1.4.7. : ¿Cuál es el modelo de procesos más adecuado?

42

CARRERAS PROFESIONALES

4

1.5 Tema 5 : Verificación y Validación

44

1.5.1. : Verificación

44

1.5.2. : Validación

44

1.5.3. : Ventajas de las Revisiones de Software

45

1.5.4. : Desventajas de las Revisiones de Software

45

1.5.5. : Revisiones Informales y Formales

45

Unidad de aprendizaje 2

2.1 Tema 6 : Modelos de Calidad de Software

85

2.1.1. : Introducción

86

2.1.2. : Perspectivas de Calidad

86

2.1.3. : Calidad desde el Punto de Vista del Proceso

87

2.1.4. : Calidad desde el Punto de Vista del Producto

88

2.1.5. : Calidad desde el Punto de Vista de las Personas

89

2.2 Tema 7 : Métricas de Calidad de Producto Software

90

2.2.1. : ISO/IEC 9126-1 – Modelo de Calidad

91

2.2.2. : ISO/IEC 9126-2 – Métricas Externas

93

2.2.3. : ISO/IEC 9126-3 – Métricas Internas

93

2.2.4. : Relación entre las Métricas Internas y Externas

94

2.2.5. : ISO/IEC 9126-4 – Métricas para Calidad en Uso

95

2.2.6. : ISO/IEC 25000:2005 – SquaRE

96

2.3 Tema 8 : Evaluación de Métricas

98

2.3.1. : Definiciones

98

2.3.2. : Proceso de Evaluación

98

Unidad de aprendizaje 3

3.1 Tema 9 : Pruebas de Software 3.1.1. : Principios Generales de las Pruebas 3.2 Tema 10 : Ciclo de Vida de las Pruebas

105 106 108

3.2.1

Planeación y Control de Pruebas

108

3.2.2

Análisis y Diseño de las Pruebas

108

CARRERAS PROFESIONALES

CIBERTEC

CALIDAD DE SOFTWARE

3.2.3

Implementación y Ejecución de Pruebas

109

3.2.4

Evaluación de Criterios de Salida y Reportes

109

3.2.5

Cierre de Pruebas

109

3.3 Tema 11 : Estrategia de Pruebas

CIBERTEC

5

111

3.3.1

Casos de Prueba

111

3.3.2

Diseño de Casos de Prueba

113

3.3.3

Realizar Casos de Prueba

116

3.3.4

Informe y Seguimiento de Pruebas

118

3.3.5

Relación entre las Pruebas y la Depuración

120

CARRERAS PROFESIONALES

6

CARRERAS PROFESIONALES

CIBERTEC

CALIDAD DE SOFTWARE

7

PRESENTACIÓN Calidad de Software pertenece a la línea formativa y se dicta en la carrera de Computación e Informática y de Administración y Sistemas. Brinda los conceptos fundamentales de calidad que deben ser considerados en los proyectos de desarrollo de sistemas de software. El manual para el curso ha sido diseñado bajo la modalidad de unidades de aprendizaje, las que se desarrollan durante semanas determinadas. En cada una de ellas, hallará los logros, que debe alcanzar al final de la unidad; el tema tratado, el cual será ampliamente desarrollado; y los contenidos, que debe desarrollar, es decir, los subtemas. Por último, encontrará las actividades que deberá desarrollar en cada sesión, que le permitirán reforzar lo aprendido en la clase. El curso tiene un formato teórico práctico. Los conceptos desarrollados son aplicados en el proyecto Integrado de Quinto Ciclo, desarrollado en el curso de Desarrollo de Aplicaciones Web 1, y se complementa con los temas del curso de Gestión de Proyectos de TI. Los conceptos y las técnicas de control de calidad se implementan también en el curso de Análisis y Diseño de Sistemas III de la carrera de Administración y Sistemas, con verificaciones de entregables previamente establecidos. .

CIBERTEC

CARRERAS PROFESIONALES

8

RED DE CONTENIDOS

Calidad de Software

Aseguramie nto de la Calidad de Software

Métricas de Software

Pruebas de Software

Calidad de Software

Modelos de Calidad de Software

Pruebas de Software

Aseguramiento y Control de Calidad

Métricas de Calidad de Productos de Sofware

Ciclo de Vida de las Pruebas

Modelo de Procesos

Estrategia de Pruebas Evaluación de Métricas

Modelos de Ciclo de Vida de Software Verificación y Validación UNIDAD DE APRENDIZAJE

1

CARRERAS PROFESIONALES

CIBERTEC

CALIDAD DE SOFTWARE

9

CALIDAD DE SOFTWARE LOGRO DE LA UNIDAD DE APRENDIZAJE •

Al término de la unidad de aprendizaje, el alumno diseña la lista de verificación del Reporte de Especificación de Software y el Plan de Desarrollo considerando los requerimientos previamente definidos por el Líder Usuario para el proyecto integrado de quinto ciclo.

TEMARIO 1.1. Tema 1: Calidad de Software 1.1.1. Definición de Calidad 1.1.2. Política de Calidad 1.1.3. Terminología según ISO 8402 1.1.4. Definición de Calidad de Software 1.1.4.1. Control de Calidad 1.1.4.2. Aseguramiento de Calidad 1.2. Tema 2: Aseguramiento y Control de Calidad 1.2.1. SQA (Software Quality Assurance) no es lo mismo que SQC (Software 1.2.2.

Quality Control) Funciones Generales del SQA

1.3. Tema 3: Modelo de Procesos 1.3.1. El Proceso de Desarrollo de Software 1.3.2. Normas Relacionadas con el Proceso de Desarrollo de Software 1.3.2.1. Conceptos Clave 1.3.2.2. Ciclos de Vida, Procesos, Productos 1.3.3. Los Procesos ISO 12207:2008 1.4. Tema 4: Modelo de Ciclo de Vida de Software 1.4.1. Codificar y Corregir (Code-and-Fix) 1.4.2. Modelo en Cascada 1.4.3. Desarrollo Evolutivo 1.4.4. Desarrollo Formal de Sistemas 1.4.5. Desarrollo Basado en Reutilización 1.4.6. Procesos Iterativos 1.4.6.1. Desarrollo Incremental 1.4.6.2. Desarrollo en Espiral 1.4.7. ¿Cuál es el modelo de procesos más adecuado? 1.5. Tema 5: Verificación y Validación de Software 1.5.1. Verificación 1.5.2. Validación 1.5.3. Ventajas de las Revisiones de Software 1.5.4. Desventajas de las Revisiones de Software 1.5.5. Revisiones Informales y Formales

CIBERTEC

CARRERAS PROFESIONALES

10

1.1. CALIDAD DE SOFTWARE Los conceptos relacionados con la calidad de software tienen relación directa con la aplicación de la calidad a un producto desarrollado a través de procesos de ingeniería de software. En tal sentido empezaremos dando algunas definiciones de calidad y luego ampliaremos el concepto hacia calidad de software.

1.1.1. Definición de Calidad

CARRERAS PROFESIONALES

CIBERTEC

CALIDAD DE SOFTWARE

11

Existen muchas definiciones de calidad y muchos términos que se utilizan en la gestión de la misma. Para la ISO 8402 (International Standard Organization), complemento de normas de las series de normas ISO 9000, define La Calidad como: "El conjunto de características de una entidad que le confieren la aptitud para satisfacer las necesidades establecidas e implícitas”. También podría decirse que es la “conformidad con los requisitos” y el “grado de excelencia”. En un servicio la calidad se define como la diferencia entre la percepción del servicio y la expectativa que el cliente tenía del mismo. Calidad también es la satisfacción del cliente. La calidad la definen los clientes, por lo que la oferta deberá estar de acuerdo los lo que ellos definen (sus exigencias) y entonces deberá producirse exactamente lo que dichos clientes desean, en el plazo convenido y al mínimo costo e incluso anticiparse a sus necesidades satisfaciendo sus expectativas, lo que dará una ventaja competitiva frente a la competencia. La calidad no solo hace referencia a que un producto o servicio se ajuste a las exigencias. La percepción que los clientes tienen sobre su empresa está basada en el producto o servicio que les suministra, pero también en el contacto diario que mantienen con los directivos. El concepto de calidad abarca no sólo como se atienden las exigencias de sus clientes sino también la forma en que se hace, cómo se atiende el teléfono, la rapidez con que se satisfacen consultas, tener nuevos servicios cuando se los requiere, asegurarse que la factura que sale de la empresa es la correcta. Cada contacto, llamados momentos de la verdad con el cliente, muestra un reflejo de la compañía a los ojos de ese cliente. El recepcionista que atiende las llamadas, los agentes de seguridad que controlan los accesos, los ascensoristas que transportan a la gente y la orientan, los administrativos que envían las facturas, los dictámenes de los abogados, todos deben involucrarse en el concepto de calidad, en satisfacer las exigencias del cliente, en crear una compañía con clase reconocida. La calidad es un concepto objetivo que cada empleado puede comprender y evaluar, y sobre el cual puede asumir responsabilidades. La única forma de alcanzar el objetivo de calidad es: 1. Comprender las exigencias de los clientes externos. 2. Conocer a fondo los procesos internos que le permitan satisfacer esas exigencias. 3. Desarrollar un sistema y cultura empresarial que le aseguren que los errores son evitados o eliminados

1.1.2. Política de Calidad ISO 8402 la define como: "Directrices y objetivos generales de una empresa relativos a la calidad, expresados formalmente por la Dirección General". Es una de las vías para hacer operativa la estrategia. Al desplegar verticalmente la política a través de los niveles jerárquicos de la organización:

CIBERTEC

CARRERAS PROFESIONALES

12

• • •

Se proporciona orientación precisa para que ejecutivos y mandos elaboren planes concretos de acción. Se cohesiona la organización para el cumplimiento de los objetivos de calidad. Se refuerza el compromiso del personal.

La política de calidad debe ser: • • •

Adecuada a la empresa. Coherente con las necesidades y expectativas de sus clientes. Muy simple y fácilmente comprensible para que sea comunicable y entendida sin dificultad.

En cuanto a su contenido, debería hacer referencia a: • • • •

Los grandes objetivos de la empresa. Los colectivos que en ella conviven: personal, accionistas, clientes, proveedores. La disponibilidad de los recursos necesarios; por ejemplo, formación. La vía a utilizar (ISO, Mejora Continua, etc.).

Es la totalidad de aspectos y características de un producto o servicio que se refieren a su capacidad para satisfacer necesidades dadas en la adecuación de sus objetivos'”. El Instituto de Ingeniería de Software (SEI) en su modelo CMM define la calidad como: • El grado en el cual un sistema, componente o proceso cumple con los requisitos especificados. • El grado en el cual el sistema, componente o proceso cumple con las expectativas del cliente o usuario.

1.1.3. Terminología según ISO 8402 1. Calidad: “Conjunto de propiedades y características de un producto o servicio que le confieren su aptitud para satisfacer unas necesidades explicitas o implícitas”. 2. Control de Calidad: “Conjunto de técnicas y actividades de carácter operativo, utilizadas para verificar los requerimientos relativos a la calidad del producto o servicio”. 3. Garantía de Calidad: “Conjunto de acciones planificadas y sistemáticas necesarias para proporcionar la confianza adecuada de que un producto o servicio cumplirá los requerimientos dados sobre calidad”. 4. Gestión de Calidad: “Aspecto de la función de gestión que determina y aplica la política de la calidad, los objetivos y las responsabilidades y que lo realiza con medios tales como la planificación de la calidad, el control de la calidad, la garantía de calidad y la mejora de la calidad”. 5. Sistema de Gestión de Calidad: “Conjunto de la estructura de la organización, de responsabilidades, procedimientos, procesos y recursos que se establecen para llevar a término la gestión de calidad”.

CARRERAS PROFESIONALES

CIBERTEC

CALIDAD DE SOFTWARE

• •

•

13

El QS debe tener el volumen y alcance suficiente para conseguir los objetivos de calidad. El QS de una organización está fundamentalmente previsto para satisfacer las necesidades internas de la organización. Es más amplio que los requerimientos de un cliente concreto que únicamente valore el QS que le interesa (directamente). Para finalidades contractuales o vinculantes en la valoración de la calidad, se puede exigir que se ponga de manifiesto la realización de ciertos elementos del QS.

6. Aseguramiento de la Calidad: “Es un conjunto de actividades preestablecidas y sistematizadas, aplicadas al sistema de calidad, que ha sido demostrado que son necesarias para dar confianza adecuada de que un producto o servicio satisfará los requisitos para la calidad”. 7. Acción Correctiva: “Acción tomada para eliminar las causas de una no conformidad, defecto o cualquier situación indeseable existente, para evitar su repetición”. 8. Acción Preventiva: “Acción tomada para eliminar las causas de una no conformidad, defecto o cualquier situación indeseable potencial, con el fin de evitar que se produzca”. 9. Conformidad: “Cumplimiento de requisitos especificados”. 10. Costos de la no Calidad: “Costos asociados con la provisión de productos o servicios de baja calidad”. 11. Defectos: “No cumplimiento de un requisito o de una expectativa razonable, ligada a un uso previsto, incluyendo los relativos a la seguridad”. 12. Inspección: “Actividades como medir, examinar, ensayar o comparar una o más características de un producto o servicio, y comparar los resultados con los requisitos especificados, con el fin de determinar la conformidad con respecto a cada una de esas características”. 13. No Conformidad: “No satisfacción de un requisito especificado”. 14. Trazabilidad: “Aptitud de reconstruir la historia, la utilización o la localización de un producto por medio de identificaciones registradas”. 15. Validación: “Confirmación por examen y aporte de evidencias objetivas de que los requisitos particulares para un uso específico previsto han sido satisfechos”. 16. Verificación: “Confirmación por examen y aporte de evidencias objetivas que los requisitos especificados han sido satisfechos”.

CIBERTEC

CARRERAS PROFESIONALES

14

SISTEMA DE GESTIÓN DE LA CALIDAD MEJORA CONTINUA

C L I E N T E S

R E Q U I S I T O S

S A T I S F A C C I O N

Responsabilidad de la Dirección Gestión de recursos

Entrada

Medición, análisis y mejoramiento

Realización

Salida

Producto o Servicio

Producto o Servicio

Figura 1.1 - Sistema de Gestión de Calidad

1.1.4. Definición de Calidad de Software La Calidad del Software es el conjunto de cualidades que lo caracterizan y que determinan su utilidad y existencia. Según R. Pressman: “La calidad del software se define como la concordancia con los requisitos funcionales y de rendimiento explícitamente establecidos, con los estándares y procesos de desarrollo explícitamente documentados y con las características implícitas que se espera de todo software desarrollado profesionalmente”. No hay duda de que la anterior definición puede ser modificada o ampliada. De hecho, no tendría fin una discusión sobre una definición definitiva de la calidad del software. Para los propósitos de este enfoque, la anterior definición sirve para hacer hincapié en tres puntos importantes: 1. Los requisitos del software son la base de las medidas de la calidad. La falta de concordancia con los requisitos es una falta de calidad. 2. Los estándares especificados definen un conjunto de criterios de desarrollo que guían la forma en que se aplica la ingeniería del software o del conocimiento. En caso de no seguirse esos criterios, casi siempre habrá falta de calidad. 3. Existe un conjunto de requisitos implícitos que a menudo no se mencionan (por ejemplo la necesidad de una interfaz intuitiva). Si el software se ajusta a sus requisitos explícitos pero falla en alcanzar los requisitos implícitos, la calidad del software se debilita. Queda claro a partir de la definición de calidad del software, que ésta es siempre relativa a los requisitos o necesidades que se desea satisfacer. Por eso la evaluación de la calidad del software siempre va a implicar la comparación entre los requisitos y el producto generado.

CARRERAS PROFESIONALES

CIBERTEC

CALIDAD DE SOFTWARE

15

La Calidad del Software es medible y varía de un sistema a otro o de un programa a otro. Por ejemplo: un software elaborado para el control de naves espaciales debe ser confiable al nivel de "cero fallas"; un software hecho para ejecutarse una sola vez no requiere el mismo nivel de calidad; mientras que un producto de software para ser explotado durante un largo período (10 años o más) necesita ser confiable, mantenible y flexible para disminuir los costos de mantenimiento y perfeccionamiento durante el tiempo de explotación. La Calidad del Software puede medirse después de elaborado el producto. Pero esto puede resultar muy costoso si se detectan problemas derivados de imperfecciones en el diseño, por lo que es imprescindible tener en cuenta tanto la obtención de la calidad como su control durante todas las etapas del ciclo de vida del software. Existen varios factores que determinan la calidad del software y la eficiencia de la organización, entre ellos están la complejidad del producto, las tecnologías y las personas, así como algunas condiciones de entorno que también tienen su impacto, estas pueden ser condiciones de gestión (plazo de entrega, restricciones dentro de la organización), entornos de desarrollo y características del cliente, sin embargo en el centro de todas ellas se encuentra el proceso. El proceso es el único factor de los controlables al mejorar la calidad del software y su rendimiento en la organización. Analizando y mejorando el proceso se puede obtener mejores productos.

Figura 1.2 - Determinantes de la calidad del software y de la efectividad de la organización

Los ejes de desarrollo de software se relacionan con la calidad de la siguiente forma: 1. 2. 3. 4.

Persona: PSP, TSP Producto: McCall, Boehm, ISO/IEC 9126-1 Proceso: CMM, ISO/IEC 15504 Mejora continua del proceso: IDEAL, ISO/IEC 15504, SPI

Por lo tanto:

CIBERTEC

CARRERAS PROFESIONALES

16

Figura 1.3 - Dependencia entre Calidad de Producto y Calidad de Proceso

1.1.4.1. Control de Calidad: Para controlar la Calidad del Software es necesario, definir los parámetros, indicadores o criterios de medición. El software posee determinados índices medibles que son las bases para la calidad, el control y el perfeccionamiento de la productividad. Una vez seleccionados los índices de calidad, debe establecerse el proceso de control, que requiere los siguientes pasos: 1.

2.

3.

Definir el software que va a ser controlado: clasificación por tipo, ámbito de aplicación, complejidad, etc., de acuerdo con los estándares establecidos para el desarrollo del software. Seleccionar una medida que pueda ser aplicada al objeto de control. Para cada clase de software es necesario definir los indicadores y sus magnitudes. Crear o determinar los métodos de valoración de los indicadores: métodos manuales como cuestionarios o encuestas estándares para la medición de criterios parciales y herramientas automatizadas para medir los criterios de cálculo.

Los procedimientos pueden variar en cada organización, pero lo importante es que estén escritos, personalizados, adaptados a los procesos de la organización y, lo que es más importante, que se cumplan. La Calidad del Software debe implementarse a lo largo de todo el ciclo de vida, debe correr paralela desde la planificación del producto hasta la fase de producción del mismo.

CARRERAS PROFESIONALES

CIBERTEC

CALIDAD DE SOFTWARE

17

Para ello se cuenta con una serie de ayudas, a través de distintas actividades para la implantación del control de calidad en el desarrollo que son: • Aplicación de metodología y técnicas de desarrollo • Reutilización de procesos de revisión formales • Prueba del software • Ajustes a los estándares de desarrollo • Control de cambios, mediciones y recopilación de información • Gestión de informes sobre el control de calidad Para la fase de Planificación, se pueden utilizar elementos y herramientas propias de la Gestión de proyectos, como la: • Estimación de la duración, costo y esfuerzo para la construcción del producto. En lo referido a la estimación habrá que tener presentes las Métricas de software • Planificación de tareas que hay que realizar, asignación de personas, tiempo, costo y otros parámetros para construcción del producto Para los procesos de Análisis y Diseño deberemos contar con: • Sistemas de obtención de requisitos • Métricas de software • Herramientas de Generación de Datos • Casos de Prueba En los procesos de Construcción y pruebas deberíamos usar: • Herramientas de Gestión de la Configuración • Herramientas de Simulación • Casos de Pruebas Y, finalmente, para el proceso de Producción, básicamente debemos utilizar: • Herramientas de monitoreo de resultados • Pruebas de producción Definir las regulaciones organizativas para realizar el control: quienes participan en el control de calidad, cuándo se realiza, qué documentos deben ser revisados y elaborados, etc. El Instituto de Ingeniería de Software (SEI) en su modelo CMM define la calidad como: • •

CIBERTEC

El grado en el cual un sistema, componente o proceso cumple con los requisitos especificados. El grado en el cual el sistema, componente o proceso cumple con las expectativas del cliente o usuario.

CARRERAS PROFESIONALES

18

1.1.4.2. Aseguramiento de Calidad: Es el conjunto de actividades planificadas y sistemáticas necesarias para aportar la confianza adecuada en que el producto (software) satisfacerá los requisitos dados de calidad. El aseguramiento pretende dar confianza en que el producto tiene calidad. Aseguramiento de calidad se enfoca en identificar y evaluar los defectos que puedan afectar al software. Si los errores se pueden identificar de forma temprana en el proceso de software, las características del diseño de software se pueden especificar de modo que eliminarán o controlarán los peligros potenciales, al corregir los errores mucho antes en cada etapa es decir durante el proceso, ahorrando esfuerzos, tiempo y recursos. Sridharan (Sridharan, 2000) indica que mientras el software que se está desarrollando reúne los requerimientos y su desempeño sea el esperado, es preciso que se supervisen las actividades de desarrollo del software y su rendimiento, en distintas oportunidades durante cada fase del ciclo de vida. Este es el papel del aseguramiento de la calidad del software. Hay tres aspectos muy importantes con relación aseguramiento de la calidad del software: (Wiegers, 1990) i)

al

La calidad no se puede probar, se construye.

ii) El aseguramiento de la calidad del software no es una tarea que se realiza en una fase particular del ciclo de vida de desarrollo. iii) Las actividades asociadas con el aseguramiento de la calidad del software deben ser realizadas por personas que no estén directamente involucradas en el esfuerzo de desarrollo. El aseguramiento de la calidad de software comprende una gran variedad de tareas: i)

Participar en descripción del proyecto de software.

ii) Auditar el producto de software para verificar el cumplimiento del proceso de software definido. iii) Asegurar que las divergencias en el trabajo de software sean documentadas de acuerdo a los estándares definidos. iv) Almacenar cualquier inconformidad y reportarla a la gerencia media. v) Revisiones del software que se aplican durante cada paso del desarrollo del mismo. Las revisiones del software se aplican en varios momentos del desarrollo, tanto en el análisis como en el diseño y la codificación, de manera que puedan ser eliminados cuanto antes.

CARRERAS PROFESIONALES

CIBERTEC

CALIDAD DE SOFTWARE

19

vi) Gestión de configuraciones de software (control de la documentación del software y de los cambios realizados). El proceso de control de cambios contribuye directamente a la calidad del software.

Figura 1.4 - Componentes del Aseguramiento de Calidad de Calidad (SQA)

El grupo de aseguramiento de calidad participa en la revisión de los productos seleccionados para determinar si se conforman o no a los procedimientos, normas o criterios especificados, siendo totalmente independiente del equipo de desarrollo. Las actividades a realizar por el grupo de aseguramiento de calidad vienen gobernadas por el plan. Sus funciones están dirigidas a: i)

Identificar las posibles desviaciones en los estándares aplicados, así como en los requisitos y procedimientos especificados.

ii) Comprobar que se han llevado a cabo las medidas preventivas o correctivas necesarias. iii) Las revisiones son una de las actividades más importantes del aseguramiento de la calidad, debido a que permiten eliminar defectos lo más pronto posible, cuando son menos costosos de corregir. Es importante señalar que la calidad de un producto software no se puede referir únicamente a obtener un producto sin errores. La especificación de la calidad del software debe ser más detallada y exacta, y el camino para ello es la formalización de la calidad mediante un modelo de calidad. Un modelo de calidad es un conjunto de buenas prácticas para el desarrollo del software, enfocado en los procesos de gestión y desarrollo de proyectos, cuyo objetivo es el desarrollo de productos de calidad de manera consistente y predecible.

CIBERTEC

CARRERAS PROFESIONALES

20

Existen distintos marcos de trabajo que nos ayudan a mejorar los procesos de calidad de software. La finalidad de estos modelos es la de mejorar los procesos de software, brindar pautas para efectuar evaluaciones de la unidad informática, determinar la potencialidad y la efectividad de sus procesos, así como la madurez de la empresa. Se busca mejorar los procesos de software, aumentar la productividad la calidad reduciendo su costo.

CARRERAS PROFESIONALES

CIBERTEC

CALIDAD DE SOFTWARE

21

1.2. ASEGURAMIENTO Y CONTROL DE CALIDAD La Administración de la Calidad, es un área de conocimiento de todo proyecto, que incluye tres fases bien identificadas: la Planificación, el Aseguramiento y el Control. El proceso de Planificación de la Calidad en todo proyecto, toma como entradas las Políticas de Calidad de la compañía, el informe de Alcance del proyecto, la descripción del sistema (producto/s), normas, regulaciones y estándares que deben aplicarse, para producir como salidas un Plan de Dirección de Calidad, definiciones operativas y check-lists utilizadas por los procesos de Aseguramiento y Control de Calidad. Para ello se utilizan como herramientas el Análisis de costo-beneficio, diagramas de flujo, los diagramas de causa-efecto (Ishikawa), o el Benchmarking. Esta fase es la más importante en cuanto a calidad se refiere, porque se identifican posibles cuellos de botella, duplicación del trabajo o problemas de seguridad, y se ofrecen soluciones dentro del Plan de Calidad. El Control de la Calidad comprende el seguimiento de los resultados específicos del proyecto para determinar si cumplen con las normas de calidad, e identificar la forma de eliminar los resultados insatisfactorios. Por lo tanto SQA o Software Quality Assurance, es el proceso de asegurar la calidad, aplicado al software, que debe realizarse a lo largo de todos los procesos de fabricación: desde el análisis de requerimientos hasta la puesta en producción. Al igual que ocurrió con la definición de calidad hay varios puntos de vista desde donde se puede definir el aseguramiento de la calidad del software. Desde el punto de vista de la evidencia, la IEEE define el aseguramiento de la calidad como: “Una guía planificada y sistemática de todas las acciones necesarias para proveer la evidencia adecuada de que un producto cumple los requerimientos técnicos establecidos. Un conjunto de actividades diseñadas para evaluar el proceso por el cual un producto es desarrollado o construido.” Daniel Galin define SQA como: “Un conjunto, sistemático y planificado, de acciones necesarias para proveer la evidencia adecuada de que el proceso de desarrollo o mantenimiento de un sistema de software cumple los requerimientos técnicos funcionales tan bien como los requerimientos gerenciales para cumplir la planificación y operar dentro del presupuesto confinado”. Desde el punto de vista de la visibilidad, el SEI define SQA como “El aseguramiento de la calidad del software provee claro control del proceso que está siendo usado por el proyecto y del producto que se está construyendo.”

CIBERTEC

CARRERAS PROFESIONALES

22

Desde el punto de vista del aseguramiento, Don Reifer define SQA como “El aseguramiento de la calidad del software es el sistema de métodos y procedimientos usados para asegurar que el producto de software alcanza sus requerimientos. El sistema involucra la planificación, estimación y monitoreo de las actividades de desarrollo realizadas por otros.” Desde el punto de vista de la capacidad de uso Schulmeyer y McManus definen SQA como “Las actividades sistemáticas que proveen evidencia de la capacidad o disponibilidad de uso del producto de software total.”

1.2.1.

SQA (Software Quality Assurance) no es lo mismo que SQC (Software Quality Control) Generalmente cuando le preguntamos a un profesional de sistemas que es lo que entiende por aseguramiento de la calidad del software, inmediatamente comienza a hablar de testing, algunos de ellos incluyen a la validación y verificación y luego empiezan a hablar de revisiones, las cuales son sólo extensiones del testing. Es decir, a menudo hay una confusión entre SQA y el testing (el cual actualmente forma parte del área de control de calidad del software SQC). Haciendo sólo testing y revisiones no aseguramos la calidad de los productos, sino aseguramos el cumplimiento de especificaciones tanto funcionales como técnicas. En el desarrollo de software la diferencia entre SQC y SQA no está clara y estos términos a menudo se confunden, SQA se encarga de controlar el cumplimiento del proceso, mientras que SQC son aquellas acciones del aseguramiento de la calidad que proporcionan un medio para controlar y medir las características de un elemento, proceso o facilidad respecto a los requisitos establecidos. La Tabla 1 muestra las diferencias entre Aseguramiento de la calidad (SQA) y Control de calidad (SQC)

SQA Asegura la adherencia a los procesos, estándares y planes. Evalúa que los procesos, planes y estándares utilizados en el proyecto cumplan con los estándares organizacionales Revisa procesos

SQC Detecta problemas en los productos de trabajo.

Verifica que los productos de trabajo cumplan con los estándares de calidad especificados en el plan de proyecto. Revisa el contenido del producto

Tabla 1 – Diferencia entre SQA y SQC

En conclusión, el rol del SQA es auditar que los distintos equipos de la organización, inclusive el de SQC siguen los procedimientos, estándares y procesos establecidos. El equipo de SQA debería

CARRERAS PROFESIONALES

CIBERTEC

CALIDAD DE SOFTWARE

23

establecer métricas para medir la efectividad del proceso. Como complemento el rol de SQC es tomar una actitud activa de verificación y validación del resultado o salida del proceso implementado.

1.2.2.

Funciones Generales del SQA Describir los diferentes roles que puede jugar el equipo de SQA en una organización nos dará una visión clara de las funciones que puede llevar a cabo. “Como policía del proceso” El trabajo del equipo de SQA es asegurar que el desarrollo sigue el proceso establecido. Entre sus funciones en este rol se encuentran: • Auditar los productos del trabajo para identificar deficiencias. • Determinar el cumplimiento del plan de desarrollo del proyecto y del proceso de desarrollo de software. • Juzgar el proceso y no el producto. “Como abogado del cliente” El trabajo del equipo de SQA es representar al cliente. Entre sus funciones en este rol se encuentran: • Identificar la funcionalidad que al cliente le gustaría encontrar. • Ayudar a la organización a sensibilizarse con las necesidades del cliente. • Actuar como un cliente de prueba para obtener una alta satisfacción del cliente. “Como analista” El trabajo del equipo de SQA es recabar información. Entre sus funciones en este rol se encuentran: • Juntar muchos datos sobre todos los aspectos del producto y del proceso. • Con esta información ayudar a mejorar los procesos y los productos. “Como proveedor de información” El trabajo del equipo de SQA es revisar qué es lo que esté hecho y decir cuáles objetivos técnicos realmente están cumplidos para que la gerencia pueda tomar mejores decisiones de negocios. Entre sus funciones en este rol se encuentran: • Proveer información técnica objetiva para que la gerencia pueda usarla para tomar mejores decisiones. • Proveer información apropiada de las clases de productos y de los riesgos asociados con estos. • Concentrarse más en la reducción de los riesgos que en el cumplimiento del proceso.

CIBERTEC

CARRERAS PROFESIONALES

24

“Como responsable de la elaboración del proceso” El trabajo del equipo de SQA es participar en la definición de los planes, procesos, estándares y procedimientos para asegurar que se ajustan a las necesidades del proyecto y que pueden ser usados para realizar las evaluaciones de QA y cumplir los requerimientos del proyecto y las políticas de la organización. Para cumplir este rol el aseguramiento de la calidad debería comenzar en las fases tempranas del proyecto. Para ser efectivo, el equipo que realiza SQA debe ser independiente de la organización de desarrollo. Aunque tener un grupo de auditoría independiente es difícil de aplicar en organizaciones chicas donde hay pequeños ambientes de desarrollos. Pero si la organización es madura y tiene una cultura orientada a la calidad, la función de SQA puede estar embebida en el proceso. Cuando el equipo de SQA esta embebido en el proceso, se deben resolver varios inconvenientes para garantizar la objetividad: • • •

Todo aquel que realice actividades de aseguramiento de la calidad debería estar entrenado en el aseguramiento de la calidad. Las actividades de aseguramiento de la calidad realizadas para un producto deberían ser separadas de aquellas involucradas en el desarrollo y mantenimiento del mismo. Debe estar disponible un canal de comunicación independiente en el nivel apropiado de la gerencia para poder escalar las no conformidades cuando sea necesario.

El equipo de SQA provee a la gerencia de información fehaciente, objetiva en el momento adecuado. La clave aquí está en que el grupo de SQA provee a la gerencia de información técnica objetiva. La gerencia necesita ver a la gente de SQA como una fuente de información significativa que puede ayudarla a tomar decisiones difíciles. La Gerencia usa esta información para tomar decisiones de negocio apropiadas. La objetividad en la evaluación de calidad de los procesos y productos es crítica para el éxito del proyecto. La objetividad se logra con independencia del equipo de SQA y sentido común o criterio. Hay diferentes maneras de realizar evaluaciones objetivas, entre las que se incluyen: • • • •

Auditorías formales realizadas por un área de SQA independiente de la organización. Revisiones de a pares que pueden ser realizadas con distintos niveles de formalidad. Revisiones rigurosas en el lugar de desarrollo. Revisiones distribuidas y comentarios del producto.

CARRERAS PROFESIONALES

CIBERTEC

CALIDAD DE SOFTWARE

25

La tarea del equipo de SQA es un conjunto planificado de tareas, actividades y acciones ejecutadas independientemente de la organización que desarrolla software, que provee a la gerencia del proyecto información fehaciente en un momento preciso que puede ser usada para tomar decisiones de negocio apropiadas

CIBERTEC

CARRERAS PROFESIONALES

26

1.3. MODELO DE PROCESOS Un sistema informático está compuesto por hardware y software. En cuanto al hardware, su producción se realiza sistemáticamente y la base de conocimiento para el desarrollo de dicha actividad está claramente definida. La fiabilidad del hardware es, en principio, equiparable a la de cualquier otra máquina construida por el hombre. Sin embargo, respecto del software, su construcción y resultados han sido históricamente cuestionados debido a los problemas asociados, entre ellos podemos destacar los siguientes: i)

Los sistemas no responden a las expectativas de los usuarios.

ii)

Los programas “fallan” con cierta frecuencia.

iii) Los costos del software son difíciles de prever y normalmente superan las estimaciones. iv) La modificación del software es una tarea difícil y costosa. v)

El software se suele presentar fuera del plazo establecido y con menos prestaciones de las consideradas inicialmente.

vi) Normalmente, es difícil cambiar de entorno hardware usando el mismo software. vii) El aprovechamiento óptimo de los recursos (personas, tiempo, dinero, herramientas, etc.) no suele cumplirse. Según el Centro Experimental de Ingeniería de Software (CEIS), el estudio de mercado “The Chaos Report” realizado por Standish Group Internactional en 1996, concluyó que sólo un 16% de los proyectos de software son exitosos (terminan dentro de plazos y costos y cumplen los requerimientos acordados). Otro 53% sobrepasa costos y plazos y cumple parcialmente los requerimientos. El resto ni siquiera llega al término. Algunas deficiencias comunes en el desarrollo de software son: i)

Escasa o tardía validación con el cliente.

ii)

Inadecuada gestión de los requisitos.

iii) No existe medición del proceso ni registro de datos históricos. iv) Estimaciones imprevistas de plazos y costos. v)

Excesiva e irracional presión en los plazos.

vi) Escaso o deficiente control en el progreso del proceso de desarrollo. vii) No se hace gestión de riesgos formalmente. viii) No se realiza un proceso formal de pruebas. ix) No se realizan revisiones técnicas formales e inspecciones de código.

CARRERAS PROFESIONALES

CIBERTEC

CALIDAD DE SOFTWARE

27

El primer reconocimiento público de la existencia de problemas en la producción de software tuvo lugar en la conferencia organizada en 1968 por la Comisión de Ciencias de la OTAN en Garmisch (Alemania), dicha situación problemática se denominó crisis del software. En esta conferencia, así como en la siguiente realizada en Roma en 1969, se estipuló el interés hacia los aspectos técnicos y administrativos en el desarrollo y mantenimiento de productos software. Se pretendía acordar las bases para una ingeniería de construcción de software. Según Fritz Bauer lo que se necesitaba era “establecer y usar principios de ingeniería orientados a obtener software de manera económica, que sea fiable y funcione eficientemente sobre máquinas reales”. Esta definición marcaba posibles cuestiones tales como: ¿Cuáles son los principios robustos de la ingeniería aplicables al desarrollo de software de computadora? ¿Cómo construimos el software económicamente para que sea fiable? ¿Qué se necesita para crear programas de computadora que funcionen eficientemente no en una máquina sino en diferentes máquinas reales?. Sin embargo, dicho planteamiento además debía incluir otros aspectos, tales como: mejora de la calidad del software, satisfacción del cliente, mediciones y métricas, etc. El “IEEE Standard Glossary of Software Engineering Terminology” (Stad. 610.121990) ha desarrollado una definición más completa para ingeniería del software: “La aplicación de un enfoque sistemático, disciplinado y cuantificable para el desarrollo, operación y mantenimiento del software; es decir, la aplicación de ingeniería al software. El estudio de enfoques en Pressman caracteriza la Ingeniería de Software como “una tecnología multicapa”, ilustrada en la Figura 3.1.

Figura 3.1 - Capas de la Ingeniería de Software

Dichas capas se describen a continuación: 1. Cualquier disciplina de ingeniería (incluida la ingeniería del software) debe descansar sobre un esfuerzo de organización de calidad. La gestión total de la calidad y las filosofías similares fomentan una cultura continua de mejoras de procesos que conduce al desarrollo de enfoques cada vez más robustos para la ingeniería del software. 2. El fundamento de la ingeniería de software es la capa proceso. El proceso define un marco de trabajo para un conjunto de áreas clave, las cuales forman la base del control de gestión de proyectos de software y establecen el contexto en el cual: se aplican los métodos técnicos, se producen resultados de trabajo, se establecen hitos, se asegura la calidad y el cambio se gestiona adecuadamente.

CIBERTEC

CARRERAS PROFESIONALES

28

3. Los métodos de la ingeniería de software indican cómo construir técnicamente el software. Los métodos abarcan una gran gama de tareas que incluyen análisis de requisitos, diseño, construcción de programas, pruebas y mantenimiento. Estos métodos dependen de un conjunto de principios básicos que gobiernan cada área de la tecnología e incluyen actividades de modelado y otras técnicas descriptivas. 4. Las herramientas de la ingeniería del software proporcionan un soporte automático o semi-automático para el proceso y los métodos, a estas herramientas se les llama herramientas CASE (Computer-Aided Software Engineering). Dado lo anterior, el objetivo de la ingeniería de software es lograr productos de software de calidad (tanto en su forma final como durante su elaboración), mediante un proceso apoyado por métodos y herramientas. A continuación nos enfocaremos en el proceso necesario para elaborar un producto de software.

1.3.1.

El Proceso de Desarrollo de Software Un proceso de desarrollo de software tiene como propósito la producción eficaz y eficiente de un producto software que reúna los requisitos del cliente. Dicho proceso, en términos globales se muestra en la Figura 3.2. Este proceso es intensamente intelectual, afectado por la creatividad y juicio de las personas involucradas. Aunque un proyecto de desarrollo de software es equiparable en muchos aspectos a cualquier otro proyecto de ingeniería, en el desarrollo de software hay una serie de desafíos adicionales, relativos esencialmente a la naturaleza del producto obtenido. A continuación se explican algunas particularidades asociadas al desarrollo de software y que influyen en su proceso de construcción. 1.

Un producto software en sí es complejo, es prácticamente inviable conseguir un 100% de confiabilidad de un programa por pequeño que sea. Existe una inmensa combinación de factores que impiden una verificación exhaustiva de las todas posibles situaciones de ejecución que se puedan presentar (entradas, valores de variables, datos almacenados, software del sistema, otras aplicaciones que intervienen, el hardware sobre el cual se ejecuta, etc.).

2.

Un producto software es intangible y por lo general muy abstracto, esto dificulta la definición del producto y sus requisitos, sobre todo cuando no se tiene precedentes en productos software similares. Esto hace que los requisitos sean difíciles de consolidar tempranamente. Así, los cambios en los requisitos son inevitables, no sólo después de entregado en producto sino también durante el proceso de desarrollo.

3.

Además, de las dos anteriores, siempre puede señalarse la inmadurez de la ingeniería del software como disciplina, justificada por su corta vida comparada con otras disciplinas de la ingeniería. Sin embargo, esto no es más que un inútil consuelo.

CARRERAS PROFESIONALES

CIBERTEC

CALIDAD DE SOFTWARE

29

Figura 3.2 - Proceso de Desarrollo de Software

4.

El proceso de desarrollo de software no es único. No existe un proceso de software universal que sea efectivo para todos los contextos de proyectos de desarrollo. Debido a esta diversidad, es difícil automatizar todo un proceso de desarrollo de software.

A pesar de la variedad de propuestas de proceso de software, existe un conjunto de actividades fundamentales que se encuentran presentes en todos ellos: 1. Especificación de software: Se debe definir la funcionalidad y restricciones operacionales que debe cumplir el software. 2. Diseño e Implementación: Se diseña y construye el software de acuerdo a la especificación. 3. Validación: El software debe validarse, para asegurar que cumpla con lo que quiere el cliente. 4. Evolución: El software debe evolucionar, para adaptarse a las necesidades del cliente. Además de estas actividades fundamentales, Pressman menciona un conjunto de “actividades protectoras”, que se aplican a lo largo de todo el proceso del software. Ellas se señalan a continuación: 1. Seguimiento y control de proyecto de software. 2. Revisiones técnicas formales. 3. Garantía de calidad del software. 4. Gestión de configuración del software. 5. Preparación y producción de documentos. 6. Gestión de reutilización. 7. Mediciones. 8. Gestión de riesgos.

CIBERTEC

CARRERAS PROFESIONALES

30

Pressman caracteriza un proceso de desarrollo de software como se muestra en la Figura 2.3. Los elementos involucrados se describen a continuación: 1. Un marco común del proceso, definiendo un pequeño número de actividades del marco de trabajo que son aplicables a todos los proyectos de software, con independencia del tamaño o complejidad. 2. Un conjunto de tareas, cada uno es una colección de tareas de ingeniería del software, hitos de proyectos, entregas y productos de trabajo del software, y puntos de garantía de calidad, que permiten que las actividades del marco de trabajo se adapten a las características del proyecto de software y los requisitos del equipo del proyecto. 3. Las actividades de protección, tales como garantía de calidad del software, gestión de configuración del software y medición, abarcan el modelo del proceso. Las actividades de protección son independientes de cualquier actividad del marco de trabajo y aparecen durante todo el proceso.

Figura 3.3 - Elementos del Proceso de Software

Otra perspectiva utilizada para determinar los elementos del proceso de desarrollo de software es establecer las relaciones entre elementos que permitan responder Quién debe hacer Qué, Cuándo y Cómo debe hacerlo.

CARRERAS PROFESIONALES

CIBERTEC

CALIDAD DE SOFTWARE

31

Figura 3.4 - Relación entre los Elementos del Proceso de Software

En la Figura 3.4 se muestran los elementos de un proceso de desarrollo de software y sus relaciones. Así las interrogantes se responden de la siguiente forma: 1. Quién: Las Personas participantes en el proyecto de desarrollo desempeñando uno o más Roles específicos. 2. Qué: Un Artefacto es producido por un Rol en una de sus Actividades. Los Artefactos se especifican utilizando Notaciones específicas. Las Herramientas apoyan la elaboración de Artefactos soportando ciertas Notaciones. 3. Cómo y Cuándo: Las Actividades son una serie de pasos que lleva a cabo un Rol durante el proceso de desarrollo. El avance del proyecto está controlado mediante hitos que establecen un determinado estado de terminación de ciertos Artefactos. La composición y sincronía de las actividades está basada en un conjunto de Principios y Prácticas. Las Prácticas y Principios enfatizan ciertas actividades y/o la forma como deben realizarse, por ejemplo: desarrollar iterativamente, gestionar requisitos, desarrollo basado en componentes, modelar visualmente, verificar continuamente la calidad, gestionar los cambios, etc.

1.3.2.

Normas Relacionadas con el Proceso de Software La calidad es un concepto que se ha difundido y establecido en diversas actividades del quehacer humano y que se aprecia por su recurrente utilización en distintos ámbitos. En particular, en el campo de las tecnologías de la información, se han desarrollado o se han adaptado, de otros contextos, modelos para favorecer la adopción de buenas prácticas para la realización de los procesos del ciclo de vida del software. Estos modelos en calidad de proceso software han evolucionado, siendo quizás una de las más interesantes el manejo de los conceptos de capacidad de procesos y de madurez organizacional. En especial, en los modelos definidos en las normas ISO/IEC 12207 e ISO/IEC 15504 se presenta un modelo de madurez organizacional.

CIBERTEC

CARRERAS PROFESIONALES

32

En el tema de calidad a nivel de procesos se han desarrollado diversas propuestas para la industria en general como es el caso de los modelos: Malcom Baldrige, EFQM e ISO 9001, entre otros; los mismos que en alguna medida han sido utilizados por las organizaciones que desarrollan software. Un caso particular es la ISO/IEC 90003, que es una guía de aplicación de la ISO 9001:2000 para el sector informático. En el campo de las tecnologías de información, relacionado a procesos de software, se tienen una variedad creciente de propuestas y estándares que han ido evolucionando o mejorando de acuerdo al desarrollo tecnológico. Existen varios modelos que cubren diversos aspectos y han sido desarrollados con distintos propósitos. Entre los modelos relacionados de manera directa o indirecta con los procesos de software se pueden mencionar: ISO/IEC 12207 (procesos del ciclo de vida de software), CMMI (modelo de madurez y capacidad integrada, antes CMM-Sw), RUP (Rational Unified Processes), ISO/IEC 20000 (gestión de servicios de TI), ITIL (biblioteca de infraestructura de tecnologías de información), ISO/IEC 15504 (modelo para la evaluación de capacidades de procesos y madurez de organizaciones), IDEAL (mejora de procesos recomendado para CMMI), PSP (proceso de software para persona), TSP (proceso de software para equipos de trabajo), SCAMPI (método de evaluación de procesos usado para CMMI), Quick Locus (método ligero brasileño de evaluación de CMMI), PMBOK (Cuerpo de conocimiento de gestión de proyectos de PMI), ISO 10006 (directrices para la calidad en la gestión de proyectos), MoProSoft (modelo de procesos de referencia mexicano), EvalProSoft (método de evaluación basado en 15504 para MoProSoft), SIMEP-Sw (conjunto de modelos ligeros para mejor de procesos, colombiano), MPS.BR (modelos de mejor y evaluación de procesos brasileños), TMMI (modelo de madurez para Pruebas de Software), SPIRE (modelo de mejora de la región Europea), TOPS (mejora de procesos para pymes), PROCESSUS, IMPACT y RAPID entre otros. El modelo de madurez organizacional es uno de los tipos de modelos que ha recibido más atención en los últimos años. Dentro del campo de la informática se tienen entre otros a CMMI, MoProSoft, el par ISO/IEC12207-ISO/IEC 15504 y TMMI; y fuera del campo de la informática se tiene a OPM3, SOA-MM, BP-MM y GIMM de una lista mayor de propuestas. Todos estos modelos que pueden tener aspectos diferentes influenciados por el dominio donde aplican, están vinculados necesariamente por el concepto que tratan de representar: un modelo de madurez organizacional; sin embargo al no existir algún referente que oriente como definir este tema, es posible que cada cual adopte el suyo propio.

CARRERAS PROFESIONALES

CIBERTEC

CALIDAD DE SOFTWARE

33

Figura 3.5 - Normas Relacionadas con el Proceso de Software

1.3.2.1.

Conceptos Clave i) Proceso: Conjunto de actividades mutuamente relacionadas o que interactúan, las cuales transforman elementos de entrada en resultados. NTP-ISO/IEC 12207 Procesos del Ciclo de Vida del Software.

Figura 3.6 - Proceso

Figura 3.7 - ¿El desarrollo de software es realmente un proceso?

ii) Modelo: Esquema teórico, generalmente en forma matemática, de un sistema o de una realidad compleja. DRAE iii) Ciclo de desarrollo de software:

CIBERTEC

CARRERAS PROFESIONALES

34

Periodo de tiempo que comienza con la decisión de desarrollar el producto software y termina cuando el software es entregado. IEEE Std. 610.12-1990 Software Engineering Terminology iv) Ciclo de vida de software: Periodo de tiempo que comienza cuando el producto software es concebido y termina cuando el software no está disponible permanentemente para el usuario (retirada del software) . IEEE Std. 610.12-1990 Software Engineering Terminology. v) Estados del ciclo de vida del software: Constituye cada uno de los momentos (“estados”) por las que pasa (evoluciona) el producto software. Ing. Software. R.Fairley

Figura 3.8 - Ciclo de Vida y Ciclo de Desarrollo del Software

1.3.2.2.

Ciclos de Vida, Procesos, Productos Considerando al ciclo de vida como la evolución del producto de software, se infiere que dentro de cada una de las etapas del ciclo de vida se implementen procesos de desarrollo.

Ciclos de vida

Proceso

Necesidades

Especificación de Requisitos

Obtener Requisitos

Diseño

Diseñar Sistema

Codigo

Codificar

Sistema Software

Probar

Figura 3.9 - Procesos y Ciclos de Vida

CARRERAS PROFESIONALES

CIBERTEC

CALIDAD DE SOFTWARE

35

De la definición de proceso se infiere que cada proceso genera productos, tal como se muestra a continuación:

Figura 3.10 - Procesos y Productos

1.3.3.

Los Procesos ISO 12207:2008 El modelo ISO 12207:2008 establece un conjunto de buenas prácticas para guiar a las organizaciones en la mejora de sus procesos de desarrollo y mantenimiento software. En concreto, define 43 procesos que pueden aplicarse durante la adquisición de un producto o servicio software y durante el suministro, desarrollo, operación, mantenimiento y evolución de productos software.

CIBERTEC

CARRERAS PROFESIONALES

36

Figura 3.11 - Modelo de Procesos ISO 12207:2008

CICLO DE VIDA: :

INVOLUCRADOS (STAKEHOLDERS)

Nace

:

Muere

Adquirientes,

proveedores,

usuarios, ...

PROCESOS CORPORATIVOS APLICACIÓN : PROYECTOS PRODUCTOS

DETALLES: :

PROCESOS , DEFINICIO NES Y DESCRIPCIONES

PROYECTOS SERVICIOS

METODO LOG ÍAS , MÉTO DOS Y MÉTRICAS

PROCEDIMIENTO S, TÉCNICAS , HERRAM IENTAS Y ENTORNOS

Figura 3.12 - Modelo de Procesos ISO 12207:2008 – Alcance

CARRERAS PROFESIONALES

CIBERTEC

CALIDAD DE SOFTWARE

37

1.4. MODELO DE CICLO DE VIDA DE SOFTWARE Sommerville define modelo de proceso de software como “Una representación simplificada de un proceso de software, representada desde una perspectiva específica. Por su naturaleza los modelos son simplificados, por lo tanto un modelo de procesos del software es una abstracción de un proceso real.” Los modelos genéricos no son descripciones definitivas de procesos de software; sin embargo, son abstracciones útiles que pueden ser utilizadas para explicar diferentes enfoques del desarrollo de software. Modelos que se van a discutir a continuación: • • • • • • •

Codificar y corregir Modelo en cascada Desarrollo evolutivo Desarrollo formal de sistemas Desarrollo basado en reutilización Desarrollo incremental Desarrollo en espiral

1.4.1.

Codificar y corregir (Code-and-Fix) Este es el modelo básico utilizado en los inicios del desarrollo de software. Contiene dos pasos: •

Escribir código.

•

Corregir problemas en el código.

Se trata de primero implementar algo de código y luego pensar acerca de requisitos, diseño, validación, y mantenimiento. Este modelo tiene tres problemas principales: • Después de un número de correcciones, el código puede tener una muy mala estructura, hace que los arreglos sean muy costosos. • Frecuentemente, aún el software bien diseñado, no se ajusta a las necesidades del usuario, por lo que es rechazado o su reconstrucción es muy cara. • El código es difícil de reparar por su pobre preparación para probar y modificar.

1.4.2.

Modelo en Cascada El primer modelo de desarrollo de software que se publicó se derivó de otros procesos de ingeniería. Éste toma las actividades fundamentales del proceso de especificación, desarrollo, validación y evolución y las representa como fases separadas del proceso.

CIBERTEC

CARRERAS PROFESIONALES

38

El modelo en cascada consta de las siguientes fases: 1. Definición de los requisitos: Los servicios, restricciones y objetivos son establecidos con los usuarios del sistema. Se busca hacer esta definición en detalle. 2. Diseño de software: Se particiona el sistema en sistemas de software o hardware. Se establece la arquitectura total del sistema. Se identifican y describen las abstracciones y relaciones de los componentes del sistema. 3. Implementación y pruebas unitarias: Construcción de los módulos y unidades de software. Se realizan pruebas de cada unidad. 4. Integración y pruebas del sistema: Se integran todas las unidades. Se prueban en conjunto. Se entrega el conjunto probado al cliente. 5. Operación y mantenimiento: Generalmente es la fase más larga. El sistema es puesto en marcha y se realiza la corrección de errores descubiertos. Se realizan mejoras de implementación. Se identifican nuevos requisitos. La interacción entre fases puede observarse en la Figura 4.1. Cada fase tiene como resultado documentos que deben ser aprobados por el usuario. Una fase no comienza hasta que termine la fase anterior y generalmente se incluye la corrección de los problemas encontrados en fases previas.

Figura 4.1 - Modelo de Desarrollo en Cascada

En la práctica, este modelo no es lineal, e involucra varias iteraciones e interacción entre las distintas fases de desarrollo. Algunos problemas que se observan en el modelo de cascada son: •

Las iteraciones son costosas e implican rehacer trabajo debido a la producción y aprobación de documentos.

•

Aunque son pocas iteraciones, es normal congelar parte del desarrollo y continuar con las siguientes fases.

CARRERAS PROFESIONALES

CIBERTEC

CALIDAD DE SOFTWARE

39

•

Los problemas se dejan para su posterior resolución, lo que lleva a que estos sean ignorados o corregidos de una forma poco elegante.

•

Existe una alta probabilidad de que el software no cumpla con los requisitos del usuario por el largo tiempo de entrega del producto.

•

Es inflexible a la hora de evolucionar para incorporar nuevos requisitos. Es difícil responder a cambios en los requisitos.

Este modelo sólo debe usarse si se entienden a plenitud los requisitos. Aún se utiliza como parte de proyectos grandes.

1.4.3.

Desarrollo Evolutivo La idea detrás de este modelo es el desarrollo de una implantación del sistema inicial, exponerla a los comentarios del usuario, refinarla en “N” versiones hasta que se desarrolle el sistema adecuado. En la Figura 4.2 se observa cómo las actividades concurrentes: especificación, desarrollo y validación, se realizan durante el desarrollo de las versiones hasta llegar al producto final. Una ventaja de este modelo es que se obtiene una rápida retroalimentación del usuario, ya que las actividades de especificación, desarrollo y pruebas se ejecutan en cada iteración.

Figura 4.2 - Modelo de Desarrollo Evolutivo

Existen dos tipos de desarrollo evolutivo: Desarrollo Exploratorio: El objetivo de este enfoque es explorar con el usuario los requisitos hasta llegar a un sistema final. El desarrollo comienza con las partes que se tiene más claras. El sistema evoluciona conforme se añaden nuevas características propuestas por el usuario.

CIBERTEC

CARRERAS PROFESIONALES

40

Enfoque utilizando prototipos: El objetivo es entender los requisitos del usuario y trabajar para mejorar la calidad de los requisitos. A diferencia del desarrollo exploratorio, se comienza por definir los requisitos que no están claros para el usuario y se utiliza un prototipo para experimentar con ellos. El prototipo ayuda a terminar de definir estos requisitos. Entre los puntos favorables de este modelo están: • La especificación puede desarrollarse de forma creciente. •

Los usuarios y desarrolladores logran un mejor entendimiento del sistema. Esto se refleja en una mejora de la calidad del software.

•

Es más efectivo que el modelo de cascada, ya que cumple con las necesidades inmediatas del cliente.

Desde una perspectiva de ingeniería y administración se identifican los siguientes problemas: • Proceso no Visible: Los administradores necesitan entregas para medir el progreso. Si el sistema se necesita desarrollar rápido, no es efectivo producir documentos que reflejen cada versión del sistema. •

Sistemas pobremente estructurados: Los cambios continuos pueden ser perjudiciales para la estructura del software haciendo costoso el mantenimiento.

•

Se requieren técnicas y herramientas: Para el rápido desarrollo se necesitan herramientas que pueden ser incompatibles con otras o que poca gente sabe utilizar.

Este modelo es efectivo en proyectos pequeños (menos de 100.000 líneas de código) o medianos (hasta 500.000 líneas de código) con poco tiempo para su desarrollo y sin generar documentación para cada versión. Para proyectos largos es mejor combinar lo mejor del modelo de cascada y evolutivo: se puede hacer un prototipo global del sistema y posteriormente reimplementarlo con un acercamiento más estructurado. Los subsistemas con requisitos bien definidos y estables se pueden programar utilizando cascada y la interfaz de usuario se puede especificar utilizando un enfoque exploratorio.

1.4.4.

Desarrollo Formal de Sistemas Este modelo se basa en transformaciones formales de los requisitos hasta llegar a un programa ejecutable.

CARRERAS PROFESIONALES

CIBERTEC

CALIDAD DE SOFTWARE

41

Figura 4.3 - Paradigma de Programación Automática

La Figura 4.3 ilustra un paradigma ideal de programación automática. Se distinguen dos fases globales: especificación (incluyendo validación) y transformación. Las características principales de este paradigma son: • La especificación es formal y ejecutable constituye el primer prototipo del sistema). •

La especificación es validada mediante prototipado.

•

Posteriormente, a través de transformaciones formales especificación se convierte en la implementación del sistema.

•

En el último paso de transformación se obtiene una implementación en un lenguaje de programación determinado.

•

El mantenimiento se realiza sobre la especificación (no sobre el código fuente), la documentación es generada automáticamente y el mantenimiento es realizado por repetición del proceso (no mediante parches sobre la implementación).

la

Observaciones sobre el desarrollo formal de sistemas: • Permite demostrar la corrección del sistema durante el proceso de transformación. Así, las pruebas que verifican la correspondencia con la especificación no son necesarias. • Es atractivo sobre todo para sistemas donde hay requisitos de seguridad y confiabilidad importantes. • Requiere desarrolladores especializados y experimentados en este proceso para llevarse a cabo.

1.4.5.

Desarrollo Basado en Reutilización Como su nombre lo indica, es un modelo fuertemente orientado a la reutilización. Este modelo consta de 4 fases ilustradas en la Figura 4.4.

CIBERTEC

CARRERAS PROFESIONALES

42

A continuación se describe cada fase: 1. Análisis de componentes: Se determina qué componentes pueden ser utilizados para el sistema en cuestión. Casi siempre hay que hacer ajustes para adecuarlos. 2. Modificación de requisitos: Se adaptan (en lo posible) los requisitos para concordar con los componentes de la etapa anterior. Si no se puede realizar modificaciones en los requisitos, hay que seguir buscando componentes más adecuados (fase 1). 3. Diseño del sistema con reutilización: Se diseña o reutiliza el marco de trabajo para el sistema. Se debe tener en cuenta los componentes localizados en la fase 2 para diseñar o determinar este marco. 4. Desarrollo e integración: El software que no puede comprarse, se desarrolla. Se integran los componentes y subsistemas. La integración es parte del desarrollo en lugar de una actividad separada. Las ventajas de este modelo son: •

Disminuye el costo y esfuerzo de desarrollo.

•

Reduce el tiempo de entrega.

•

Disminuye los riesgos durante el desarrollo.

Figura 4.4 Desarrollo Basado en Reutilización de Componentes

Desventajas de este modelo: •

Los “compromisos” en los requisitos son inevitables, por lo cual puede que el software no cumpla las expectativas del cliente.

•

Las actualizaciones de los componentes adquiridos no están en manos de los desarrolladores del sistema.

CARRERAS PROFESIONALES

CIBERTEC

CALIDAD DE SOFTWARE

1.4.6.

43

Procesos Iterativos A continuación se expondrán dos enfoques híbridos, especialmente diseñados para el soporte de las iteraciones: •

Desarrollo Incremental.

•

Desarrollo en Espiral.

1.4.6.1.

Desarrollo Incremental Mills sugirió el enfoque incremental de desarrollo como una forma de reducir la repetición del trabajo en el proceso de desarrollo y dar oportunidad de retrasar la toma de decisiones en los requisitos hasta adquirir experiencia con el sistema (ver Figura 4.5). Es una combinación del Modelo de Cascada y Modelo Evolutivo. Reduce el rehacer trabajo durante el proceso de desarrollo y da oportunidad para retrasar las decisiones hasta tener experiencia en el sistema. Durante el desarrollo de cada incremento se puede utilizar el modelo de cascada o evolutivo, dependiendo del conocimiento que se tenga sobre los requisitos a implementar. Si se tiene un buen conocimiento, se puede optar por cascada, si es dudoso, evolutivo.

Figura 4.5 - Modelo de Desarrollo Iterativo Incremental

Entre las ventajas del modelo incremental se encuentran: • Los clientes no esperan hasta el fin del desarrollo para utilizar el sistema. Pueden empezar a usarlo desde el primer incremento. • Los clientes pueden aclarar los requisitos que no tengan claros conforme ven las entregas del sistema. • Se disminuye el riesgo de fracaso de todo el proyecto, ya que se puede distribuir en cada incremento. • Las partes más importantes del sistema son entregadas primero, por lo cual se realizan más pruebas en estos módulos y se disminuye el riesgo de fallos.

CIBERTEC

CARRERAS PROFESIONALES

44

Algunas de las desventajas identificadas para este modelo son: • Cada incremento debe ser pequeño para limitar el riesgo (menos de 20.000 líneas). • Cada incremento debe aumentar la funcionalidad. • Es difícil establecer las correspondencias requisitos contra los incrementos.

de

los

• Es difícil detectar las unidades o servicios genéricos para todo el sistema. 1.4.6.2.

Desarrollo en Espiral El modelo de desarrollo en espiral (ver Figura 4.6) es actualmente uno de los más conocidos y fue propuesto por Boehm. El ciclo de desarrollo se representa como una espiral, en lugar de una serie de actividades sucesivas con retrospectiva de una actividad a otra. Cada ciclo de desarrollo se divide en cuatro fases: 1. Definición de objetivos: Se definen los objetivos. Se definen las restricciones del proceso y del producto. Se realiza un diseño detallado del plan administrativo. Se identifican los riesgos y se elaboran estrategias alternativas dependiendo de estos. 2. Evaluación y reducción de riesgos: Se realiza un análisis detallado de cada riesgo identificado. Pueden desarrollarse prototipos para disminuir el riesgo de requisitos dudosos. Se llevan a cabo los pasos para reducir los riesgos. 3. Desarrollo y validación: Se escoge el modelo de desarrollo después de la evaluación del riesgo. El modelo que se utilizará (cascada, sistemas formales, evolutivo, etc.) depende del riesgo identificado para esa fase.

4. Planificación: Se determina si continuar con otro ciclo. Se planea la siguiente fase del proyecto. Este modelo a diferencia de los otros toma en consideración explícitamente el riesgo, esta es una actividad importante en la administración del proyecto. El ciclo de vida inicia con la definición de los objetivos. De acuerdo a las restricciones se determinan distintas alternativas. Se identifican los riesgos al sopesar los objetivos contra las alternativas. Se evalúan los riesgos con actividades como análisis detallado, simulación, prototipos, etc. Se desarrolla un poco el sistema. Se planifica la siguiente fase.

CARRERAS PROFESIONALES

CIBERTEC

CALIDAD DE SOFTWARE

45

Figura 4.6 - Modelo de Desarrollo en Espiral

1.4.7.

¿Cuál es el modelo de proceso más adecuado? Cada proyecto de software requiere de una forma de particular de abordar el problema. Las propuestas comerciales y académicas actuales promueven procesos iterativos, donde en cada iteración puede utilizarse uno u otro modelo de proceso, considerando un conjunto de criterios (Por ejemplo: grado de definición de requisitos, tamaño del proyecto, riesgos identificados, entre otros). En la Tabla 2 se expone un cuadro comparativo de acuerdo con algunos criterios básicos para la selección de un modelo de proceso, la medida utilizada indica el nivel de efectividad del modelo de proceso de acuerdo al criterio (Por ejemplo: El modelo Cascada responde con un nivel de efectividad Bajo cuando los Requisitos y arquitectura no están predefinidos):

CIBERTEC

CARRERAS PROFESIONALES

46

Funciona con requisitos y Modelo de Proceso arquitectura no predefinidos

Produce software altamente fiable

Gestión de riesgos

Visión del Permite progreso por el correcciones Cliente y el Jefe sobre la marcha de Proyecto

Codificar y Corregir

Bajo

Bajo

Bajo

Alto

Medio

Cascada

Bajo

Alto

Bajo

Bajo

Bajo

Medio o Alto

Alto

Bajo

Bajo

Bajo

Alto

Medio

Medio

Alto

Alto

Bajo

Alto

Bajo a Medio

Bajo

Bajo

Medio

Bajo a Alto

Bajo a Medio

Alto

Alto

Incremental

Bajo

Alto

Medio

Bajo

Bajo

Espiral

Alto

Alto

Alto

Medio

Medio

Evolutivo exploratorio Evolutivo prototipado Desarrollo formal de sistemas Desarrollo orientado a la reutilización

Tabla 2 – Comparación entre modelos de proceso de software

CARRERAS PROFESIONALES

CIBERTEC

CALIDAD DE SOFTWARE

47

1.5. VERIFICACIÓN Y VALIDACIÓN DE SOFTWARE Los procesos de verificación y validación determinan si un producto software satisface las necesidades del negocio y si se está construyendo acorde a las especificaciones. Según el SWEBOK 2004, existen dos grupos de técnicas para la comprobación de software: 1. Técnica Estática: Técnica para evaluación del software que no requiere la ejecución del mismo. 2. Técnica Dinámica: Técnica para evaluación del software que sí requiere la ejecución del mismo.

Figura 5.1 – Revisiones y Pruebas

En la Figura 5.1 se puede apreciar que cuando se aplica la técnica dinámica, normalmente se usan pruebas; y cuando se aplica técnica estática se utilizan revisiones.

1.5.1.

Verificación Según la ISO-IEC 12207, la Verificación es el proceso para determinar si los productos software de una actividad cumplen con los requerimientos o condiciones que tienen impuestas por las actividades precedentes. La verificación permite comprobar que el artefacto producido en un proceso corresponde con el que se utilizó a la entrada del proceso. La verificación permite responder la pregunta: ¿Estamos construyendo el producto en forma correcta? La verificación se orienta al proceso.

CIBERTEC

CARRERAS PROFESIONALES

48

1.5.2.

Validación Según la ISO-IEC 12207, la Validación es el proceso para determinar si los requerimientos y el sistema o producto software, tal como se ha construido, cumple con su uso específico previsto. La validación se puede llevar a cabo en etapas tempranas. La validación permite comprobar si el artefacto producido es lo que el usuario necesita. La validación permite responder la pregunta: ¿Estamos construyendo el producto correcto? La validación se orienta al producto.

Las actividades de verificación y validación deben desarrollarse a lo largo de todo el ciclo de vida de software (ver Figura 5.2).

Figura 5.2 – Verificación y Validación

1.5.3.

Ventajas de las Revisiones de Software • • • • • •

1.5.4.

No requiere de código ejecutable, por lo que puede ser realizada desde el inicio (por lo tanto es menos costosa). Se encuentran varios defectos a la vez. Encuentra hasta un 85% de los defectos. Se localiza la posición exacta del defecto. Refuerza el uso de estándares. Mejora la capacitación.

Desventajas de las Revisiones de Software • • • •

Requiere del tiempo de expertos. No se puede verificar características no-funcionales (ejemplo rendimiento). Validan cumplimiento de lo que se especificó, en vez de lo que realmente desea el cliente. Difícil de implementar (es vista como “improductiva” por los desarrolladores).

CARRERAS PROFESIONALES

CIBERTEC

CALIDAD DE SOFTWARE

1.5.5.

49

Revisiones Informales y Formales 1. Informales: • No hay proceso definido. • No existen roles. • Usualmente no planeadas. 2. Formales: • Objetivos definidos. • Proceso documentado. • Roles definidos y personas entrenados en ellos. • Check-list, reglas y métodos para encontrar defectos. • Reporte del resultado. • Recolección de datos para el control del proceso.

Figura 5.3 – Tipos de Revisiones de Software

CIBERTEC

CARRERAS PROFESIONALES

50

Actividades
Los alumnos deberán presentar los documentos de Reportes de Especificación de Software del proyecto integrado, manual de usuario y Reporte de Diseño de Software utilizando los formatos adjuntos.
Los alumnos deberán elaborar un plan de verificación y de validación de los entregables que se desarrollarán como parte del proyecto integrado de quinto ciclo.
Los alumnos deberán elaborar las listas de verificación del RES las que aplicarán en juego de roles como parte del ciclo de proyecto integrado.
Los alumnos harán el seguimiento de levantamiento de las observaciones en una segunda revisión de pares del RES.

CARRERAS PROFESIONALES

CIBERTEC

CALIDAD DE SOFTWARE

51

Formatos 1.

RES – Reporte de Especificación de Software

Reporte de Especificación de Software (RES) Versión

[Nombre del proyecto]

[Este documento es la plantilla base para elaborar el documento Reporte de Especificación de Software. Los textos que aparecen entre paréntesis rectos son explicaciones de que debe contener cada sección. Dichos textos se deben seleccionar y sustituir por el contenido que corresponda. En caso que alguna de las secciones del presente documento no aplique a su proyecto pueden usarse las frases “No hay cambios”, “No hay impacto en esta sección”, “La solución que se está implementando no tiene impacto en esta sección”, “No aplican para el proyecto” (No borrar secciones del documento)]

CIBERTEC

CARRERAS PROFESIONALES

52

HISTORIAL DE REVISIONES

Versión



Autor

Descripción



CARRERAS PROFESIONALES

Fecha de Elaboración

Fecha de Revisión



Revisado por

CIBERTEC

CALIDAD DE SOFTWARE

53

Contenido 1.

Antecedentes ..................................................................................... 54

2.

Objetivos ............................................................................................. 54

3.

Alcance ................................................................................................. 54

3.1. 3.2. 3.3. 3.4.

4.

DENTRO DEL ALCANCE .......................................................................................................... 54 FUERA DEL ALCANCE ............................................................................................................. 54 RESTRICCIONES..................................................................................................................... 54 SUPUESTOS ............................................................................................................................ 55

Procesos de Negocio ....................................................................... 55

4.1. LISTA DE CASOS DE USO DE NEGOCIO.............................................................................. 55 4.1.1. LISTA DE ACTORES DEL NEGOCIO ................................................................................... 55 4.1.2. DIAGRAMA GENERAL DE CASO DEL NEGOCIO ................................................................ 55 4.1.3. ESPECIFICACIÓN DE LOS CASOS DE USO DEL NEGOCIO ............................................... 55 CUN01 – NOMBRE DEL CASO DE USO DEL NEGOCIO ...................................................................... 55 4.2. REALIZACIÓN DE LOS CASOS DE USO DE NEGOCIO .......................................................... 56 4.3. LISTA DE TRABAJADORES DE NEGOCIO............................................................................... 56 4.4. REGLAS DE NEGOCIO ............................................................................................................ 56

5.

Requisitos Funcionales .................................................................. 57

6.

Requisitos No Funcionales............................................................ 57

7.

Modelo de Casos de Uso del Sistema........................................ 60

7.1. 7.2. 7.3. 7.4. 7.5. 7.6. 7.7. 7.8.

LISTA DE ACTORES DE SISTEMA .......................................................................................... 60 DIAGRAMA DE ACTORES DEL SISTEMA ................................................................................ 61 ARQUITECTURA DEL SISTEMA – DIAGRAMA DE PAQUETES ............................................... 61 LISTA DE CASOS DE USO DEL SISTEMA POR PAQUETE...................................................... 61 DIAGRAMA DE CASOS DE USO POR PAQUETE ..................................................................... 61 PRIORIZACIÓN DE LOS CASOS DE USO DEL SISTEMA ....................................................... 61 MATRIZ DE MODELO DE NEGOCIO Y MODELO DE SISTEMA .............................................. 62 ESPECIFICACIÓN DE LOS CASOS DE USO DEL SISTEMA .................................................... 62 CUS01 – Nombre del caso de Uso ..................................................................................................... 63

8.

Flujo General de Navegación ....................................................... 64

9.

Esquema de Seguridad .................................................................. 64

10.

Modelo de Análisis ........................................................................ 65

11.

Modelo Conceptual ....................................................................... 66

CIBERTEC

CARRERAS PROFESIONALES

54

1.

Antecedentes [Describa la situación actual y las necesidades o problemas que se pretende atender. Recuerde que debe tomar como información base lo registrado en el Reporte de Solicitud de Requerimiento (RSRQ).] Nota: Para el caso de los cursos de quinto y sexto ciclo se puede tomar como referencia también el documento de planificación del proyecto (PP)

2.

Objetivos [Referidos a los objetivos del negocio alineados al producto software. Es la explicación resumida de los resultados que el negocio quiere lograr con el sistema, estos pueden ser la solución de alguno o varios problemas, la generación de nuevas oportunidades de negocio, alguna mejora que los usuarios o clientes necesitan o mejorar la información para la toma de decisiones directivas o ejecutivas. Recuerde que puede tomar como información base lo registrado en el Reporte de solicitud de requerimiento (SRQ).] Nota: Para el caso de los cursos de quinto y sexto ciclo se puede tomar como referencia también el documento de planificación de proyecto (PP).]

3.

Alcance 3.1.

Dentro del Alcance [En esta sección deberá incluir el alcance funcional del producto software, dicho alcance se encuentra también definido en el documento de Planificación de Proyecto (PP). Es posible detallar el alcance siempre y cuando no varíe en cuanto al original definido en el PP. Nota: Para los cursos de ADSI y ADSII se define después de haber sido obtenida la Matriz de Actividades Vs. Requisitos.]

3.2.

Fuera del Alcance [En esta sección deberá incluir lo que no es parte del alcance funcional del producto software. Se puede tomar como referencia lo indicado en el documento de PP. Es posible detallar lo que queda fuera del alcance siempre y cuando no varíe en cuanto al original definido en el PP. Nota: Para los cursos de ADSI y ADSII se define después de haber sido obtenida la Matriz de Actividades Vs. Requisitos.]

3.3.

Restricciones [En esta sección deberá incluir las restricciones de la solución propuesta relacionados al software, hardware y a la funcionalidad así como lo referido a los límites que impone la empresa contratante en el desarrollo del producto software.] Nota: Para el caso de los cursos de quinto y sexto ciclo puede tomar como referencia la sección de restricciones del documento de planificación de proyecto (PP).

CARRERAS PROFESIONALES

CIBERTEC

CALIDAD DE SOFTWARE

3.4.

55

Supuestos [En esta sección deberá incluir los principales supuestos relacionados con la implementación del sistema y lo referido a lo que la empresa contratante posee a nivel de tecnologías de información.] Nota: Para el caso de los cursos de quinto y sexto ciclo puede tomar como referencia la sección de supuestos del documento de planificación de proyecto (PP).

4.

Procesos de Negocio 4.1.

Lista de Casos de Uso de Negocio [En esta sección deberá listar los casos de uso de negocio que se obtuvieron a partir de los procesos de negocio identificados dentro del ámbito de la solución y a los cuales se les dará el soporte con el producto software. Cada Caso de Uso de Negocio deberá ser identificado con un código único y correlativo. Ejemplo CUN01. De ser necesario deberá incorporar un diagrama de casos de uso de negocio.]

Caso de uso del negocio CUN01 – [Nombre del CUN01] CUN02 – [Nombre del CUN02]

Descripción

[Descripción del flujo de trabajo del CUN01.] [Descripción del flujo de trabajo del CUN02.]

4.1.1. Lista de Actores del Negocio [En esta sección deberá listar a los actores de negocio incluyendo una descripción por cada uno.]

Actor del Negocio

Descripción

4.1.2. Diagrama General de Caso del Negocio [En esta sección deberá graficar el Diagrama general de Casos de uso del Negocio.] 4.1.3. Especificación de los Casos de Uso del Negocio [Por cada caso de uso de negocio deberá indicar el flujo de trabajo del Caso de Uso del Negocio. Deberá usar la plantilla que a continuación se detalla: CUN01 – Nombre del Caso de Uso del Negocio 1. Breve Descripción

Reutilizar el resumen del punto 4.1 2.

Objetivo

Referido al negocio y alineado al producto software.

CIBERTEC

CARRERAS PROFESIONALES

56

3.

Flujo de Trabajo 3.1

Flujo Básico

1. Indicar el flujo básico del CUN 3.2

Flujos Alternativos

1. Detalle del flujo alterno. 4.

Categoría

Se coloca si es básica, estratégica o de apoyo. 5.

Gestor del proceso

Se identifica a la persona que está interesada en el éxito o fracaso del proceso. 4.2.

Realización de los Casos de Uso de Negocio [En esta sección deberá desarrollar los diagramas de actividades y diagrama de clases de negocio por cada Caso de Uso de Negocio identificado en la sección 4.1. Por cada juego de diagramas deberá identificar cuáles serán las actividades que serán automatizadas.]

4.3.

Lista de Trabajadores de Negocio [En esta sección deberá listar a los trabajadores de negocio incluyendo una descripción por cada uno.]

Trabajador del Negocio

4.4.

Descripción

Reglas de Negocio [En esta sección deberá identificar las reglas que regulan la estructura del negocio y cómo ellos operan afectando el funcionamiento de los procesos de negocio. Dichas reglas de negocio son las que se considerarán para el diseño del sistema. Cada Regla de Negocio deberá ser identificada con un código único y correlativo. Ejemplo: RN01. Para identificar las reglas de negocio puede considerar la siguiente clasificación: Reglas de Estructura: Ejemplo (Todo pedido debe ser realizado por un cliente, y que el mismo debe estar dado de alta. Además una vez que el cliente haya hecho algún pedido, se deberá garantizar que no es posible eliminarlo, al menos que previamente se eliminen todos sus pedidos) Reglas de Derivación: Ejemplo (El total de un pedido se puede calcular a partir de distintas líneas que lo componen, mientras que el total de cada línea se puede calcular a partir del número de unidades vendidas y el precio por unidad) Reglas de Interfaz o de Modelo de Datos: Ejemplo (No hay precio de artículos negativos, el sexo de una persona sólo puede ser masculino o

CARRERAS PROFESIONALES

CIBERTEC

CALIDAD DE SOFTWARE

57

femenino, una fecha tiene que ser siempre una fecha válida - no existe 30 de febrero) Reglas de Operación o Reglas de Flujo: Ejemplo (Un cliente puede hacer una petición de análisis al laboratorio que anota un encargado: hecho esto, se genera un parte para uno o más analistas, estos realizan las mediciones correspondientes y devuelven los partes con la información pertinente, a partir de la cual se genera un informe de análisis, que será un análisis válido solo cuando sea firmado por los responsables de garantizar su corrección)

Código

Descripción

RN-001

[Descripción de la Regla 001]

RN-002

[Descripción de la Regla 002]

RN-00n

5.

Requisitos Funcionales [De acuerdo a lo solicitado explícitamente por el área usuaria, listar todos los requisitos funcionales del producto software. Considere que los requisitos funcionales que liste deberán ser asociados posteriormente a los casos de uso (funciones de software). Cada Requisito Funcional deberá ser identificado con un código único y correlativo. Ejemplo: RF01. Nota: Esta lista proviene de la Matriz de Actividades Vs. Requisitos. Y de la Matriz de Requisitos Funcionales Adicionales.]

Código [Código del requisito funcional] RF-001 RF-002 ... RF-00n

6.

Descripción [Descripción detallada del requisito funcional.] [Descripción detallada del requisito funcional 1.] [Descripción detallada del requisito funcional 2.]

Proceso de Negocio [Identificador del proceso de negocio asociado] [CUN01]

.... [Descripción detallada del requisito funcional n.]

Requisitos No Funcionales [Listar los requisitos no funcionales los mismos que deberán ser considerados para el modelo de calidad de producto. Cada Requisito No Funcional deberá ser identificado con un código único y correlativo. Ejemplo: RNF01.]

Tipo de Requisito [Nombre del tipo de requisito no funcional]

CIBERTEC

Código [Código del requisito no funcional]

Descripción [Descripción detallada del requisito no

Implementación [Describir como se implementará el RNF-00n]

CARRERAS PROFESIONALES

58

Tipo de Requisito Restricciones Diseño

Código

Descripción funcional.]

Implementación

del

[Definir cualquier tipo de restricción de diseño, tales como: proceso de desarrollo de software, sistemas operativos, RNF-001 lenguajes de programación, administrador de base de datos, conexión a la BD, generador de reportes, manejo de información, etc.]

RNF-002

Componentes Adquirir

[Descripción detallada del requisito no funcional 1.]

[Descripción detallada del requisito no funcional 2.]

a

[Identificar los componentes que se deben adquirir o tener en cuenta, para llevar acabo RNF-003 el desarrollo y ejecución del sistema. Ejemplo: lenguajes de programación, servidores, estaciones de trabajo, etc.]

RNF-004

[Descripción detallada del requisito no funcional 3.]

[Descripción detallada del requisito no funcional 4.]

Interfaces de Usuario [Describir las interfaces de usuario que serán implementados en el software. Esto incluye RNF-005 por ejemplo: formatos de la pantalla, página o esquemas de las ventanas, reportes, menús, etc.]

RNF-006

CARRERAS PROFESIONALES

[Descripción detallada del requisito no funcional 5.]

[Descripción detallada del requisito no funcional 6.]

CIBERTEC

CALIDAD DE SOFTWARE

59

Tipo de Requisito Interfaces Hardware

Código

RNF-008

RNF-010

RNF-012

de

[Identificar las licencias RNF-013 que se requieran para el desarrollo del sistema.]

RNF-014

Seguridad [Describir como será RNF-015 controlada la seguridad del sistema.]

CIBERTEC

[Descripción detallada del requisito no funcional 8.]

[Descripción detallada del requisito no funcional 9.]

[Descripción detallada del requisito no funcional 10.]

de

[Describir las interfaces de comunicación para otros sistemas ó RNF-011 dispositivos, tales como: redes de área local, dispositivos de serie remota.]

Requerimientos Licenciamiento

[Descripción detallada del requisito no funcional 7.]

de

[Especificar el uso de otros productos software RNF-009 requeridos e interfaces con otros sistemas de la aplicación.]

Interfaces Comunicaciones

Implementación

de

[Definir cualquier interfase de hardware RNF-007 que será soportado por el software, incluyendo estructura lógica, direcciones físicas, etc.]

Interfaces Software

Descripción

[Descripción detallada del requisito no funcional 11.]

[Descripción detallada del requisito no funcional 12.] [Descripción detallada del requisito no funcional 13.] [Descripción detallada del requisito no funcional 14.] [Descripción detallada del requisito no funcional 15.]

CARRERAS PROFESIONALES

60

Tipo de Requisito

Código RNF-016

[Descripción detallada del requisito no funcional 16.]

con qué RNF-017 trabaja el

[Descripción detallada del requisito no funcional 17.]

RNF-018

[Descripción detallada del requisito no funcional 18.]

Estándares aplicables [Especificar estándares sistema.]

Descripción

Implementación

Requisitos del Sistema [Especificar los requerimientos de plataforma tecnológica RNF-019 necesarios para el diseño y el desarrollo del sistema.]

RNF-020

Requisitos Desempeño

[Descripción detallada del requisito no funcional 20.]

de

[Listar y especificar los requisitos de desempeño con los que debe trabajar RNF-021 el sistema. Ejemplo: Tiempo de respuesta en alguna consulta del sistema.]

RNF-022

7.

[Descripción detallada del requisito no funcional 19.]

[Descripción detallada del requisito no funcional 21.]

[Descripción detallada del requisito no funcional 22.]

Modelo de Casos de Uso del Sistema [En esta sección deberá desarrollar el modelo de sistema o modelo de requisitos. Para ello deberá indicar los actores de sistemas, la arquitectura de sistema (organizada en paquetes) y la relación de casos de uso por cada paquete. Cada Caso de Uso deberá ser identificado con un código único y correlativo. Ejemplo: CUS01.] 7.1.

Lista de Actores de Sistema [Listar a los actores de sistema.]

CARRERAS PROFESIONALES

CIBERTEC

CALIDAD DE SOFTWARE

61

Actor del sistema

7.2.

Descripción

Diagrama de Actores del Sistema [Incorpore el diagrama de actores del sistema.]

7.3.

Arquitectura del Sistema – Diagrama de Paquetes [Incorpore el diagrama de paquetes que representa la arquitectura modular del sistema. Cada Paquete deberá ser identificado con un código único y correlativo. Ejemplo: P01.]

7.4.

Lista de Casos de Uso del Sistema por Paquete [En esta sección deberá listar todos los casos de uso del sistema que se han identificado. Para hacerlo deberá tomar como referencia la organización del sistema de acuerdo al diagrama de paquetes del punto 7.3.]

Paquete: P01 – Nombre del Paquete Caso de uso del sistema

Descripción

CUS01 – [Nombre del Caso [Descripción del caso de uso. En la de Uso] descripción deberá indicar las acciones que permitirá el caso de uso.] CUS02 – [Nombre del Caso [Descripción del caso de uso. En la de Uso] descripción deberá indicar las acciones que permitirá el caso de uso.] 7.5.

Diagrama de Casos de Uso por Paquete [Incorpore el diagrama de casos del uso del sistema de acuerdo a los paquetes y la lista trabajada en el punto 7.4.]

Paquete: P01 – Nombre del Paquete 7.6.

Priorización de los Casos de Uso del Sistema

7.6.1. Clasificación de los Casos de Uso del Sistema [En esta sección deberá clasificar los casos de uso de sistema indicando si son primarios o secundarios.]

0,4 CASO DE USO CUS01XXXXXX CUS02XXXXXX CUS03XXXXXX

CIBERTEC

0,3

IMPORTANCIA COMPLEJIDAD

0,2

0,1

RIESGO

IMPACTO RNF

TOTAL

CLASIFICACIÓN DE CU Primario Secundario Secundario

CARRERAS PROFESIONALES

62

7.6.2. Ciclos de Desarrollo de los Casos de Uso del Sistema [En esta sección deberá indicar en qué ciclo de desarrollo se trabajarán cada uno de los casos de uso del sistema.]

Ciclo de desarrollo

Nombre del caso de uso

Clasificación

Núcleo central o Ciclo 0

CUS01 – Nombre del caso de uso

Primario

Ciclo 1

CUS02 – Nombre del caso de uso

Secundario

CUS03 – Nombre del caso de uso

Secundario

7.7.

Matriz de Modelo de Negocio y Modelo de Sistema [En esta sección deberá incluir una matriz en la que se pueda evidenciar la trazabilidad entre los procesos de negocio y las funciones del producto software.]

Caso del uso del negocio Nº

Actividad a automatizar

Nombre Nº Nombre

CUN01 Caso de Uso de Negocio

1

Actividad a ser automatizada Actividad a ser automatizada Actividad a ser automatizada

2

3

7.8.

Requerimiento funcional

Responsable Nº Nombre Trabajador de Negocio

RF001

Requisito Funcional

Caso de uso del sistema Nº

Nombre Actor

CUS01 Casos de Uso de Sistema

Trabajador de Negocio Trabajador de Negocio

Especificación de los Casos de Uso del Sistema

7.8.1. Especificación de Alto Nivel [En esta sección deberá incluir la especificación de alto nivel de los casos de uso del sistema. Asimismo deberá indicar que requisitos funcionales están asociados a cada caso de uso, tomando como referencia lo indicado en la matriz del punto 7.7.]

Caso de uso:

CUS01 – Nombre del Caso de Uso

Actor(es):

Nombre del actor

Propósito:

Indicar el propósito del caso de uso

Caso de asociado:

uso Indicar si existe algún caso de uso asociado. De no haber indicar No Aplica.

Resumen:

Describir brevemente el caso de uso. Para ello deberá indicar como empieza el caso de uso, que actividades desarrolla y como termina.

Clasificación

Indicar la clasificación del caso de uso

Requisitos

CARRERAS PROFESIONALES

Indicar el(los) asociados.

códigos

de

requisitos

funcionales

CIBERTEC

Actor

CALIDAD DE SOFTWARE

63

7.8.2. Especificación Expandida [Por cada caso de uso de sistema especificado deberá incluir la especificación expandida de casos de uso. Para ello deberá indicar el flujo básico y los flujos alternos e incorporará el prototipo con la inclusión de los controles. Deberá usar la plantilla que a continuación se detalla: CUS01 – Nombre del caso de Uso 1.

Actores

Indicar la lista de actores 2.

Propósito

Indicar el propósito 3.

Breve Descripción

Reutilizar el resumen del punto 7.4 4.

Flujo Básico de Eventos

Indicar el flujo básico de eventos Es posible hacer referencia a las reglas de negocio. 5.

Sub Flujos

Indicar los subflujos del flujo básico. 6.

Flujos Alternos 6.1. Nombre del flujo alterno

1. Detalle del Flujo alterno Se pueden incluir reglas de negocio. 7.

Precondiciones

Descripción de la precondición 8.

Pos condiciones

Descripción de la pos condición 9.

Puntos de Extensión

Indicar si existen puntos de extensión. 10. Requerimientos Especiales

Indicar si existen requerimientos especiales. 11. Prototipos

Incluir los prototipos asociados al caso de uso.

CIBERTEC

CARRERAS PROFESIONALES

64

8.

Flujo General de Navegación [Incluir un árbol de navegación que permita entender el flujo que se seguirá en la navegación por el aplicativo. El siguiente ejemplo muestra un árbol de navegación: Aplicación/módulo/opción/subopción]

Ver Agenda

Encargar Acción

Agenda

Ver Acciones

Ver Alarmas

Acción Propia

APLICACION

Clientes

Consultar Parámetros

Tablas

Resultados

Razones Mantenimiento Matriz CAP Relaciones Matriz GAF

Acciones Enviadas

Avances Reportes

Resultados Históricos Resultado de Acciones Seguimiento Semanal

9.

Esquema de Seguridad [En esta se documenta los esquemas de seguridad en base a perfiles y su acceso a su información. Para ello se utiliza una matriz de perfiles de usuario y accesos por Aplicativo/Módulo/Función.]

CARRERAS PROFESIONALES

CIBERTEC

CALIDAD DE SOFTWARE

Funciones por Módulo Módulo A Consulta de información de empresas Consulta de operadores autorizados Modificación de operadores autorizados

65

Aplicativo Perfil 1 Perfil 2 x x

Módulo B Modificación de cuentas afiliadas Modificación de combinaciones autorizadas

... X

Perfil N x

x

x

X

x

x

x

X

x

x

x

X

x

x

x

X

x

10. Modelo de Análisis 10.1.

Realización de Casos de Uso – Análisis [Esta sección ilustra cómo el software trabaja a partir de los casos de uso o escenarios seleccionados, y explica cómo varios elementos del modelo de análisis contribuyen con ellos funcionalmente. Por cada caso de uso deberá desarrollar un diagrama de secuencia y de clases de análisis. Para ello deberá usar el patrón MVC. Para la realización deberá identificar los escenarios. Dichos escenarios se obtienen de las combinaciones entre el flujo principal y flujos alternativos del la especificación expandida de casos de uso (ver punto 7.8.2).]

Código del CUS – Nombre del CUS Nombre del Escenario [Identifica el escenario a ser realizado y una breve descripción. Se recomienda identificar con un código único a cada escenario. Por ejemplo ESC01]

Diagrama de Secuencia de Análisis [Incluya el diagrama de secuencia de análisis en el cual se observe el uso del patrón MVC que implementa el escenario identificado.]

Diagrama de Clases de Análisis [Incluya el diagrama de clases de análisis obtenido del conjunto de diagramas de secuencia que se implementan por cada escenario.]

CIBERTEC

CARRERAS PROFESIONALES

66

11. Modelo Conceptual [Esta sección ilustra cómo a partir de las clases del tipo entidad se pueden identificar una primera propuesta de modelo de persistencia. Para ello se utiliza un diagrama clases por cada paquete que forma parte de la arquitectura del sistema. Se puede hacer uso de tarjetas CRC para documentar las responsabilidades y colaboraciones de cada clase de persistencia identificada.]

CARRERAS PROFESIONALES

CIBERTEC

CALIDAD DE SOFTWARE

2.

67

MU – Manual de Usuario

Manual de Usuario (MU) Versión

[Nombre del sistema]

[Este documento es la plantilla base para elaborar el Manual de Usuario. Los textos que aparecen entre paréntesis rectos son explicaciones de que debe contener cada sección. Dichos textos se deben seleccionar y sustituir por el contenido que corresponda. En caso que alguna de las secciones del presente documento no aplique al sistema desarrollado pueden usarse las frases “No hay cambios”, “No hay impacto en esta sección”, “La solución que se está implementando no tiene impacto en esta sección”, “No aplican para el sistema” (No borrar secciones del documento)]

CIBERTEC

CARRERAS PROFESIONALES

68

HISTORIAL DE REVISIONES

Versión



Autor

Descripción



CARRERAS PROFESIONALES

Fecha de Elaboración

Fecha de Revisión



Revisado por

CIBERTEC

CALIDAD DE SOFTWARE

69

Contenido 1.

Objetivo del Documento ................................................................ 70

2.

Descripción General del Sistema................................................ 70

3.

Alcance del Sistema ........................................................................ 70

4.

Ingreso al Sistema .......................................................................... 70

5.

Funciones del Sistema ................................................................... 72

5.1.

CIBERTEC

NOMBRE DE LA OPCIÓN ........................................................................................................ 72

CARRERAS PROFESIONALES

70

12. Objetivo del Documento [Describa el objetivo del documento.] El Manual del Usuario del Sistema de Mantenimiento Correctivo de Equipos, brinda las pautas básicas para el fácil acceso a la información que este sistema ofrece, es decir, muestra las principales funcionalidades del sistema, así como la descripción gráfica de cómo navegar dentro del mismo

13. Descripción General del Sistema [Resuma de manera general las funciones que el sistema implementa para dar soporte a las necesidades y requerimientos de los usuarios finales] El sistema permite la generación del Registro de Incidentes para la atención correctiva solicitada por los usuarios vía telefónica o personalmente. Asimismo, se podrá realizar un control de las atenciones realizadas, de las horas hombres invertidos y los materiales e insumos utilizados. Además, este sistema permitirá automatizar los paquetes de servicios con lo que se mejora el control de activos. Siendo una de las necesidades básicas de la empresa el conocer la localización de las máquinas atendidas, así como las máquinas con las que podría contar el cliente registrado. En este sistema se implementará las opciones necesarias para el registro de los datos mencionados

14. Alcance del Sistema [Describa las funciones que el sistema implementa, indicando el nombre de la función y detallándola a nivel de usuario]

Funcionalidad requerida

Funcionalidad detallada

Nombre de la función que se implementa

Descripción de la función implementada indicando las actividades que permite realizar

Registrar incidentes

Permite registrar la solicitud de reparación de maquinaria con los datos del cliente y las máquinas a reparar

15. Ingreso al Sistema [Detalle cómo se debe ingresar al sistema] Ingrese al portal www.maskiner.com.pe, lo que lo llevará a la página de logueo Al ingresar al Sistema de Mantenimiento Correctivo de Equipos, primero pasará por la pantalla de Ingreso al Sistema.

CARRERAS PROFESIONALES

CIBERTEC

CALIDAD DE SOFTWARE

71

Ingresar Usuario

Ingresar contraseña

Hacer clic en el botón para ingresar al Se ingresará los datos solicitados, los cuales, al hacer clic en Ingresar, serán validados por el sistema para el acceso a la pantalla correspondiente al perfil del usuario logueado.

Las siguientes pantallas, mostrarán una barra de menú que permite el acceso a las funcionalidades que se mencionan a continuación:



Menú Principal



Registrar Incidentes



Generar O/T de Inspección



Generar O/T



Registrar Inf.de Liquidación



Aprobar Prefactura



Generar Factura.



Mantener de Clientes



Mantener Equipo



Mantener Paquetes

CIBERTEC

CARRERAS PROFESIONALES

72

16. Funciones del Sistema [Detalle cada una de las funciones del sistema, implementadas en cada una de sus opciones. Se debe explicar brevemente cada opción y luego incluir las pantallas necesarias que le permitan al usuario final entender el cómo se debe usar.]

16.1. Nombre de la Opción [Describa el funcionamiento de la opción. Incorpore además las pantallas que le permitan describir el funcionamiento. Utilice llamadas de ser el caso para clarificar la explicación. Su explicación debe ser clara orientada a usuarios finales]

REGISTRAR INCIDENTES Al ingresar al sistema, el usuario seleccionará la opción de menú Registrar Incidentes que lo llevará a la opción Nuevo Registro de Incidentes.

En esta pantalla el sistema cargará los datos del Registrador (usuario logueado) así como la fecha del día. Aquí deberá seguir los siguientes pasos:

CARRERAS PROFESIONALES

CIBERTEC

CALIDAD DE SOFTWARE

73

Seleccionar la opción Buscar

Se mostrará la opción Buscar Cliente donde deberá: 1.Ingresar el nombre del cliente

2. Seleccione

El sistema listará los clientes que cumplan con el filtro ingresado. Luego el usuario deberá escoger el Cliente que desee seleccionando el ícono seleccionar (

CIBERTEC

).

CARRERAS PROFESIONALES

74

Seleccione haciendo

El sistema regresará a la pantalla de Registro de Incidentes donde se cargará en la memoria los datos del cliente seleccionado. Luego, el usuario deberá:

1.Seleccionar sucursal

2.Seleccionar la opción Buscar Maquinaria.

El sistema cargará las máquinas registradas para la sucursal seleccionada:

CARRERAS PROFESIONALES

CIBERTEC

CALIDAD DE SOFTWARE

75

1.Seleccione la maquinaria.

1.Seleccionar la Naturaleza de la 2.Ingrese la descripción de la

3.Hacer clic en El sistema cargará en la grilla los datos de la avería. Para ingresar nuevas máquinas deberá repetir los mismos pasos y para eliminarla se deberá:

CIBERTEC

CARRERAS PROFESIONALES

76

1.Marcar la casilla de selección de la máquina que desea eliminar de la lista.

2.Hacer clic en la opción Finalmente seleccionar la opción GUARDAR y con ello se mostrará el mensaje de confirmación.

CARRERAS PROFESIONALES

CIBERTEC

CALIDAD DE SOFTWARE

77

DERECHOS DE USO La presente documentación es propiedad de Maskiner S.A. y tiene carácter de confidencial y no podrá ser objeto de reproducción total o parcial, tratamiento informático ni transmisión de ninguna forma o por cualquier medio, ya sea electrónico, mecánico, por fotocopia, registro o cualquiera otro. Asimismo tampoco podrá ser objeto de préstamo, alquiler o cualquier forma de cesión de uso sin el permiso previo y escrito de Maskiner S.A., titular del copyright. El incumplimiento de las limitaciones señaladas por cualquier persona que tenga acceso a la documentación será perseguida conforme a ley.

Términos de Confidencialidad:

Este manual está destinado exclusivamente para Maskiner S.A. Su contenido no debe ser revelado, duplicado, usado, o publicado total o parcialmente, fuera de su organización, o a cualquier otra empresa, sin una autorización expresa escrita del proveedor. Así mismo, el proveedor se compromete a no divulgar total o parcialmente el contenido de este documento referido a necesidades o requerimientos específicos para Maskiner S.A., así como ningún tema de negocios relacionado y que fuere mencionado en reuniones de trabajo previas.

CIBERTEC

CARRERAS PROFESIONALES

78

3.

RDS – Reporte de Diseño de Software

Reporte de Diseño de Software (RDS) Versión

[Nombre del proyecto]

[Este documento es la plantilla base para elaborar el documento Reporte de Diseño de Software. Los textos que aparecen entre paréntesis rectos son explicaciones de que debe contener cada sección. Dichos textos se deben seleccionar y sustituir por el contenido que corresponda. En caso que alguna de las secciones del presente documento no aplique a su proyecto pueden usarse las frases “No hay cambios”, “No hay impacto en esta sección”, “La solución que se está implementando no tiene impacto en esta sección”, “No aplican para el proyecto” (No borrar secciones del documento)]

CARRERAS PROFESIONALES

CIBERTEC

CALIDAD DE SOFTWARE

79

HISTORIAL DE REVISIONES

Versión

Autor

Descripción



CIBERTEC

Fecha de Elaboración

Fecha de Revisión



Revisado por

CARRERAS PROFESIONALES

80

Contenido 1.

Introducción ...................................................................................... 81

1.1. 1.2. 1.3.

PROPÓSITO ............................................................................................................................ 81 ALCANCE ................................................................................................................................ 81 DEFINICIONES, ACRÓNIMOS Y ABREVIATURAS .................................................................. 81

1.3.1. 1.3.2. 1.3.3. 1.4.

Definiciones..................................................................................... 81 Acrónimos ........................................................................................ 81 Abreviaturas ................................................................................... 82

REFERENCIAS ......................................................................................................................... 82

2.

Vista General de la Arquitectura ................................................ 82

3.

Metas y Restricciones de la Arquitectura ............................... 83

4.

Vista de Casos de Uso .................................................................... 83

5.

Vista Lógica ........................................................................................ 83

5.1.

REALIZACIÓN DE CASOS DE USO – MODELO DE ANÁLISIS .............................................. 84

5.1.1. 5.1.2. 5.2. 5.3. 5.4.

Código del CUS – Nombre del CUS .......................................... 84 Diagrama de Clases de Análisis ............................................... 84

MODELO CONCEPTUAL .......................................................................................................... 84 MODELO LÓGICO ................................................................................................................... 84 MODELO DE DISEÑO ............................................................................................................. 85

5.4.1. 5.4.1.1. 5.4.1.2. 5.4.1.3. 5.4.1.4. 5.4.1.5. 5.4.1.6.

5.4.2. 5.4.2.1. 5.4.2.2.

Vista de Capas y Subsistemas .................................................. 85 Capa Capa Capa Capa Capa Capa

de de de de de de

Presentación ....................................................................................................... 86 Negocio ................................................................................................................. 86 Integración .......................................................................................................... 86 Datos ..................................................................................................................... 86 Entidad.................................................................................................................. 87 Interfaces o Elementos Comunes ............................................................... 87

Realización de Casos de Uso – Modelo de Diseño ............. 87 Código del CUS – Nombre del CUS.............................................................................. 87 Diagrama de Clases de Diseño...................................................................................... 87

6.

Vista de Despliegue ......................................................................... 88

7.

Vista de Datos ................................................................................... 88

CARRERAS PROFESIONALES

CIBERTEC

CALIDAD DE SOFTWARE

1.

81

Introducción [Describa de manera breve el contenido del documento orientando descripción hacia la utilidad que la misma busca. Recuerde que para elaboración del documento debe considerar lo desarrollado en el Reporte Especificación de Software (RES) y que es posible que en esta sección pueda complementar la información del documento base RES.]

1.1.

la la de se

Propósito [En esta sección se debe proporcionar una visión general de la arquitectura del sistema haciendo referencia a las diferentes vistas que implementarán los diferentes aspectos.]

1.2.

Alcance [Indicar cuál es el alcance del documento. Considere que en el RES se ha desarrollado la Vista de Sistema (funcional) y que para completar la visión total es necesario incluir la vista de arquitectura, vista lógica, vista de implementación, vista de despliegue y vista de datos. A menudo es necesario incluir una representación de la arquitectura con consideraciones de infraestructura tecnológica, relación con otros sistemas y una vista de procesos en donde se describe la descomposición del sistema en procesos y los métodos de comunicación del sistema.]

1.3.

Definiciones, Acrónimos y Abreviaturas [Proporcione las definiciones, acrónimos utilizarán en el desarrollo del documento.]

y

abreviaturas

que

se

1.3.1. Definiciones [Indique cada una de las definiciones que son relevantes para el entendimiento del presente documento. Cada definición deberá ir acompañada de una breve descripción.]

Definición Asistente de Gestión

Descripción Trabajador encargado de procesar las rectificaciones de los ciudadanos que lo solicitan. También coordina las entregas de hologramas.

1.3.2. Acrónimos [Indique cada una de los acrónimos que son relevantes para el entendimiento del presente documento, para el entendimiento de la arquitectura propuesta y para el diseño detallado. Cada acrónimo deberá ir acompañada de una breve descripción.]

Acrónimo RUP

CIBERTEC

Descripción Rational Unified Process

CARRERAS PROFESIONALES

82

1.3.3. Abreviaturas [Indique cada una de las abreviaturas que son relevantes para el entendimiento del presente documento, para el entendimiento de la arquitectura propuesta y para el diseño detallado. Cada abreviatura deberá ir acompañada de una breve descripción.]

Acrónimo SIGA

1.4.

Descripción Sistema Integrado de Gestión Administrativa

Referencias [Mencione los documentos que sirven como entrada, o salida, y herramientas que se usarán para el desarrollo del presente documento.]

2.

Vista General de la Arquitectura [En esta sección describa la arquitectura de software para el sistema actual, y cómo este será representado. De las vistas de casos de uso, lógica, procesos, despliegue e implementación; se enumerarán las vistas necesarias, y por cada vista, se deberá explicar qué tipo de elementos del modelo contienen.] Ejemplo:

A continuación se muestra la Arquitectura del Sistema ABC, ésta está dividida en tres capas: • Capa de Presentación • Capa de Negocios • Capa de Integración Así mismo la aplicación por un criterio de funcionalidad se ha dividido en seis módulos: • Módulo de Administración del Negocio • Módulo de Empaquetamiento • Módulo de Mensajería • Módulo de Administración de Datos • Servicios Web X12 • Componentes EDI Web SGSS

Aplicativo Externo 1

Módulo de Administración del Negocio

Capa de Presentación

Servicios Web X12

Componentes EDI

Módulo de Empaquetam.

Módulo de Mensajería

Capa de Aplicación y Lógica de Negocio

Módulo de Administración de Datos

Aplicativo Externo N Base de Datos del Sistema

Base de Datos 1

Base de Datos 2

Base de Datos N

Capa de Base de Datos

La figura anterior muestra la distribución de los módulos del software

CARRERAS PROFESIONALES

CIBERTEC

CALIDAD DE SOFTWARE

83

que tendrá el sistema, además de brindar una visión general del sistema. En el gráfico, se observa la distribución en tres capas de la arquitectura, las cuales se describen a continuación.

3.

•

Capa de presentación En esta capa se encuentra la aplicación Web dedicada a la administración y configuración DEL SISTEMA XYZ, la cual estará conformada por las pantallas de presentación al usuario. Estas aplicaciones Web serán páginas ASP.NET.

•

Capa de Lógica de Negocio Esta capa provee todo lo que es la lógica del negocio, es decir la funcionalidad del sistema, ya sean los procesos administrativos, y los procesos referidos a la elegibilidad, crédito hospitalario (cartas de garantía) y crédito ambulatorio (pedidos de reembolso). Además, en esta capa se encuentran los servicios publicados, como los Web Services y los Servicios EDI sobre TCP/IP.

•

Capa de acceso a datos Esta capa provee los servicios y conexiones a la base de datos requeridos por la capa de lógica de Negocio. Por otro lado, el manejador de base de datos utilizado para este sistema será Microsoft SQL Server 2000.

Metas y Restricciones de la Arquitectura [En ésta sección se describe describen los requerimientos de software y objetivos que tienen algún significativo impacto sobre la arquitectura; por ejemplo: seguridad, privacidad de uso del producto, portabilidad, distribución y reuso. Esto también captura las restricciones especiales que quizás apliquen en la: Estrategia de diseño e implementación, herramientas de desarrollo, estructura del equipo, cronograma, leyes y regulaciones legales y otros. Las restricciones que aquí se recogen pueden complementar a las identificas en el RES a excepción de aquellas funcionales.]

4.

Vista de Casos de Uso [En ésta sección se listan los casos de uso o escenarios del modelo de casos de uso. Debe tomar como referencia lo desarrollado en el RES en los puntos punto 7.3, 7.4 y 7.5. Recuerde que debe respetar la codificación indicada en el RES para los paquetes y para los casos de uso. Si fuse necesario ampliar en esta sección recuerde que es necesario se actualice el RES.]

5.

Vista Lógica [La vista lógica está representada por los diagrama de clases del sistema donde se muestran sus relaciones estructurales y de herencia. La definición de clase incluye definiciones para atributos y operaciones. El modelo de casos del punto 3 del presente documento uso aporta información para establecer las clases, objetos, atributos y operaciones.]

CIBERTEC

CARRERAS PROFESIONALES

84

5.1.

Realización de Casos de Uso – Modelo de Análisis [Esta sección ilustra cómo el software trabaja a partir de los casos de uso o escenarios seleccionados, y explica cómo varios elementos del modelo de análisis contribuyen con ellos funcionalmente. Por cada caso de uso deberá desarrollar un diagrama de secuencia y de clases de análisis. Para ello deberá usar el patrón MVC. Para la realización deberá identificar los escenarios. Dichos escenarios se obtienen de las combinaciones entre el flujo principal y flujos alternativos del la especificación expandida de casos de uso (ver punto 7.8.2 del RES).]

5.1.1. Código del CUS – Nombre del CUS Nombre del Escenario [Identifica el escenario a ser realizado y una breve descripción. Se recomienda identificar con un código único a cada escenario. Por ejemplo ESC01]

Diagrama de Secuencia de Análisis [Incluya el diagrama de secuencia de análisis en el cual se observe el uso del patrón MVC que implementa el escenario identificado.]

5.1.2. Diagrama de Clases de Análisis [Incluya el diagrama de clases de análisis obtenido del conjunto de diagramas de secuencia que se implementan por cada escenario.]

5.2.

Modelo Conceptual [Esta sección ilustra cómo a partir de las clases del tipo entidad se pueden identificar una primera propuesta de modelo de persistencia. Para ello se utiliza un diagrama clases por cada paquete que forma parte de la arquitectura del sistema. Se puede hacer uso de tarjetas CRC para documentar las responsabilidades y colaboraciones de cada clase de persistencia identificada.]

5.3.

Modelo Lógico [El modelo lógico es el refinamiento del Modelo Conceptual. Aquí se reducen y/o aumentan clases y sólo quedan aquellas que van a ser diseñadas como tablas de la Base de Datos. El modelo lógico debe representarse con un diagrama de clases de acuerdo a la arquitectura propuesta. Tenga presente que para la transformación del modelo conceptual al modelo lógico se debe tener en cuenta: • Pasar las reglas de negocio • Colocar las multiplicidades entre clases • Identificar los atributos de Enlace o Clase de Enlace de las asociaciones de muchos a muchos • NO INCLUIR los atributos identificadores de la clase (se agregarán en el modelo físico) • Incluir los atributos de las clases que se necesitan para satisfacer los requerimientos del sistema • Documentar un registro de glosario de términos

CARRERAS PROFESIONALES

CIBERTEC

CALIDAD DE SOFTWARE

85

• Verificar que las reglas de negocio se sigan cumpliendo. Se sugiere que por cada clase se tenga un diccionario que incluya el nombre, el tipo, la descripción, atributos, tipo de dato, visibilidad y valor inicial] Nombre

Nombre de la Clase

Tipo

Tipo de Clase (Ejemplo Entidad)

Descripción

Descripción de la clase identificando que representa

Atributo

Tipo de Dato

Visibilidad

Integer / String / Boolean

Público Privado

Nombre atributo

5.4.

del

Valor inicial /

Modelo de Diseño [En esta sección debe representar el refinamiento del modelo de análisis considerando los requisitos no funcionales identificados en el RES.]

5.4.1. Vista de Capas y Subsistemas [Incluir el diagrama en el que se represente la arquitectura de diseño. Para ello puede usar un patrón en el cual se usen capas y subsistemas. Además deberá identificar subsistemas requeridos por el uso de algún patrón de diseño como el DAO Factory, Singleton, Front Controller, entre otros. Por cada capa y subsistema deberá identificar las clases de diseño que se implementarán]

CIBERTEC

CARRERAS PROFESIONALES

86

Presentacion

Business

Integration

Interface Entidad Data

5.4.1.1.

Capa de Presentación [Identifique las clases de diseño de la capa de presentación. Ordene dicha identificación utilizando los paquetes al interior de las capas denominados subsistemas.]

5.4.1.2.

Capa de Negocio [Identifique las clases de diseño de la capa de negocio. Ordene dicha identificación utilizando los paquetes al interior de las capas denominados subsistemas.]

5.4.1.3.

Capa de Integración [Identifique las clases de diseño de la capa de integración. Ordene dicha identificación utilizando los paquetes al interior de las capas denominados subsistemas.]

5.4.1.4.

Capa de Datos [Identifique las clases de diseño de la capa de datos. Ordene dicha identificación utilizando los

CARRERAS PROFESIONALES

CIBERTEC

CALIDAD DE SOFTWARE

87

paquetes al interior de las capas denominados subsistemas.]

5.4.1.5.

Capa de Entidad [Identifique las clases de diseño de la capa de entidad. Ordene dicha identificación utilizando los paquetes al interior de las capas denominados subsistemas.]

5.4.1.6.

Capa de Interfaces o Elementos Comunes [Identifique las clases de diseño de la capa de elementos comunes. Ordene dicha identificación utilizando los paquetes al interior de las capas denominados subsistemas.]

5.4.2. Realización de Casos de Uso – Modelo de Diseño [Esta sección deberá desarrollar los diagramas de secuencia y de clases de diseño a partir de los requisitos no funcionales identificados en el RES y considerando los escenarios identificados en el punto 4.1 del presente documento. Debe asegurarse que las clases que se incorporen deben ser aquellas que se han identificado en el punto 4.4.1 del presente documento.]

5.4.2.1.

Código del CUS – Nombre del CUS [A partir de los casos de uso realizados del modelo de análisis deberá identificar los casos de uso que usará para las realizaciones de diseño.]

Nombre del Escenario [Identifica el escenario a ser realizado y una breve descripción. Se recomienda identificar con un código único a cada escenario. Por ejemplo ESC01. Deberá reusar los escenarios identificados en el modelo de análisis]

Diagrama de Secuencia de Diseño [Incluya el diagrama de secuencia de diseño en el cual se observe el uso de patrones de diseño para las clases que implementarán cada una de las clases lógicas.]

5.4.2.2.

Diagrama de Clases de Diseño [Incluya el diagrama de clases de diseño obtenido del conjunto de diagramas de secuencia que se implementan por cada escenario.]

CIBERTEC

CARRERAS PROFESIONALES

88

6.

Vista de Despliegue [En esta sección se describen unas o más configuraciones físicas de la red (hardware) que se usarán para el despliegue de los componentes de software que forman parte de la solución. Para ello puede usar un Diagrama de Despliegue indicando como mínimo, para cada configuración, en qué nodos físicos (computadoras, CPU) se ejecuta el software y sus interconexiones (bus, LAN, punto a punto, y así sucesivamente). De ser posible se debe incluir un mapeo de los procesos de la vista de procesos sobre los nodos físicos. Además deberá especificar los detalles técnicos de cada nodo en la vista de despliegue.] Sistema Operativo Windows 2000/XP/2003 Professsional Internet Explorer 6.0 o superior PC Cliente Interno

PC Cliente Interno

Intranet Sistema Operativo Windows 2003 Server IIS (Internet Information Server) Net Framework 2.0

Servidor Intranet  

Sistema Operativo Windows 2003 Server COM+ (Component Services) Net Framewok 2.0

Servidor COM+

Sistema Operativo Windows 2003 Server SQL Server 2000

Servidor BD

Inmuebles Adjudicados Presupuesto Archivo Excel Servidor BD Otros Sistemas

Sistema Operativo Windows 2003 Server SQL Server 2000 Sistemas:  Spring (Macro)  Contabilidad MC  Adelantos (Macro)  Provisiones (Macro)  Inmuebles Propios

Internet Mainframe IBM ZSeries  Comprobantes  Contabilidad

Web Service Interface Spring PagoActivo HOST

7.

Vista de Datos [Se debe describir la perspectiva persistente del almacenaje de datos del sistema. Deberá incluir el Modelo de Base de Datos Lógico y Físico, así como el diccionario de datos.]

CARRERAS PROFESIONALES

CIBERTEC

CALIDAD DE SOFTWARE

89

Resumen  El desarrollo de sistemas hoy en día ha tomado gran importancia en el mundo siendo ésta cada vez más creciente.  Aunque esta importancia tienda a aumentar, no todo tiene una buena perspectiva, existen inconvenientes en el desarrollo de los sistemas: grandes retrasos en la programación, inconsistencia en su funcionamiento, entre otros; pero lo más importante es la falta de calidad, punto de gran interés e importancia para el logro de eficiencia y productividad de los sistemas.  Es claro que si un sistema presenta errores al momento de ser utilizado, ese producto pierde confiabilidad a los ojos del usuario hasta el nivel que podría ser desechado como un producto defectuoso.  Por esta razón los proyectos de sistemas que presentan fallas impiden que el sistema funcione como era de esperarse o que sea utilizado en su totalidad. Por ello, es necesario definir e impulsar líneas de acción tendientes a mejorar el sistema producido. Dentro de estas líneas de acción está la relacionada con el proceso mismo del desarrollo del sistema, y como necesidad primordial, la de realizar una investigación que permita conocer de primera mano el estado en que se encuentra su proceso de desarrollo.  Si desea saber más acerca de estos temas, puede consultar las siguientes páginas.  http://www.calidaddelsoftware.com Aquí encontrará diferentes temas relacionados con la mejora de procesos de desarrollo de software.  http://alarcos.inf-cr.uclm.es/Competisoft/ Aquí encontrará diferentes temas relacionados con la mejora de procesos enfocadas a pequeñas empresas.

CIBERTEC

CARRERAS PROFESIONALES

90

CARRERAS PROFESIONALES

CIBERTEC

CALIDAD DE SOFTWARE

91

UNIDAD DE APRENDIZAJE

2

MÉTRICAS DE SOFTWARE LOGRO DE LA UNIDAD DE APRENDIZAJE •

Al término de la unidad de aprendizaje, el alumno elabora un catálogo de métricas de funcionalidad relacionadas con el producto software en desarrollo en el curso de Desarrollo de Aplicaciones Web I.

TEMARIO 2.1. Tema 6: Modelos de Calidad de Software 2.1.1. Introducción 2.1.2. Perspectivas de Calidad 2.1.3. Calidad desde el Punto de Vista del Proceso 2.1.4. Calidad desde el Punto de Vista del Producto 2.1.5. Calidad desde el Punto de Vista de las Personas 2.2. Tema 7: Métricas de Calidad de Producto Software 2.2.1. ISO/IEC 9126-1 – Modelo de Calidad 2.2.2. ISO/IEC 9126-2 – Métricas Externas 2.2.3. ISO/IEC 9126-3 – Métricas Internas 2.2.4. Relación Entre las Métricas Internas y Externas 2.2.5. ISO/IEC 9126-4 – Métricas para Calidad en Uso 2.2.6. ISO/IEC 25000:2005 - SQuaRE 2.3. Tema 8: Evaluación de Métricas 2.3.1. Definiciones 2.3.2. Proceso de Evaluación

CIBERTEC

CARRERAS PROFESIONALES

92

2.1. MODELOS DE CALIDAD DE SOFTWARE 2.1.1.

Introducción Los Modelos de Calidad son aquellos documentos que integran la mayor parte de las mejores prácticas, proponen temas de administración en los que cada organización debe hacer énfasis, integran diferentes prácticas dirigidas a los procesos clave y permiten medir los avances en calidad. Los Estándares de Calidad son aquellos que permiten definir un conjunto de criterios de desarrollo que guían la forma en que se aplica la Ingeniería del Software. Los estándares suministran los medios para que todos los procesos se realicen de la misma forma y son una guía para lograr la productividad y la calidad. Los Modelos y/o Estándares permiten que las Empresas de Software realicen sus tareas y funciones teniendo en cuenta la Calidad. Cualquier organización que se dedica a la investigación, producción y comercialización de software debe considerar la calidad, hoy con más razón, donde existe un mercado en el cual el cliente es cada vez más exigente, no sólo en lo que se refiere al precio, sino sobre todo, en cuanto a los servicios y a la confiabilidad que brindan los productos de software. La calidad desempeña un rol determinante para la competitividad de la empresa. Cuando una empresa está funcionando y decide implantar un Modelo / Estándar de Calidad del Software, es señal que la empresa tiene el propósito de hacerse cada vez más profesional homogenizando los criterios sobre los cuales se debe producir los productos y los servicios de software, que brindarán satisfacción a sus clientes y por lo tanto velarán por los intereses de los accionistas.

2.1.2.

Perspectivas de Calidad Es necesario tener en cuenta cuales son las principales “perspectivas” cuando se habla de “La Calidad”. Como se puede observar en la siguiente figura, existen tres perspectivas bien diferenciadas y relacionadas entre sí, que en el caso del software serían: •

•

•

La calidad desde el punto de vista del producto: que tiene en cuenta las características internas y externas del producto software en sí. La calidad desde el punto de vista de los procesos: que tiene en cuenta las tareas, actividades y procesos que se siguen para obtener el producto software. La calidad desde el punto de vista de las personas: evaluando la formación, experiencia, etc. de las personas involucradas en los procesos para obtener el producto software.

CARRERAS PROFESIONALES

CIBERTEC

CALIDAD DE SOFTWARE

2.1.3.

93

Calidad desde el Punto de Vista del Proceso La calidad desde el punto de vista del proceso considera el hecho que el control de calidad no se realiza sólo al sistema en sí mismo, sino también se abarca todas las actividades de los procesos utilizados para desarrollar el producto software. En este sentido en cada una de las etapas del ciclo de vida de producto se llevarán actividades de control de calidad, garantizando se ha verificado y validado cada uno de los componentes de tal forma que se asegura la calidad del producto a partir del aseguramiento de la calidad del proceso. Es cierto que mientras más se invierta en calidad del proceso mayores serán los costos pero también es cierto que mayores serán los beneficios obtenidos en la fase de mantenimiento del software. La calidad del software, por lo tanto, no se diseña y planifica cuando ya se tiene el producto; muy por el contrario se planifica desde las primeras etapas del ciclo de vida del producto. Una de las formas de evaluar la calidad es ejecutando revisiones, las que permiten establecer un marco común para la definición de distintas etapas de revisión en el ciclo de vida del software este mecanismo no sólo está pensado para las etapas tempranas del ciclo de vida, sino que también puede - y debe ser utilizado en etapas como la de prueba de software y mantenimiento. El mecanismo más común para su implementación es la reunión de revisión, la cual deberá regirse, para asegurar su éxito, por una buena planificación, control y, sobre todo, por la participación dedicada de todos y cada uno de los involucrados. Para implementar los conceptos de calidad desde el punto de vista del proceso también existen diferentes Modelos y/o Estándares de Calidad que proporcionan un marco común para orientar los esfuerzos de aseguramiento de calidad. Por ejemplo la norma ISO/IEC 15504, también conocida como SPICE (Software Process Improvement and Capability dEtermination), es una norma internacional para establecer y mejorar la capacidad y madurez de los procesos de las organizaciones, proporcionando los principios requeridos para realizar una

CIBERTEC

CARRERAS PROFESIONALES

94

evaluación de la calidad de los procesos. Esta norma se puede utilizar junto con la ISO/IEC 12207 que establece un conjunto de buenas prácticas para guiar a las organizaciones en la mejora de sus procesos de desarrollo y mantenimiento de software. Dicha norma define 43 procesos que pueden aplicarse durante la adquisición de un producto o servicio software y durante el suministro, desarrollo, operación, mantenimiento y evolución de productos software. La norma ISO/IEC 15504 permite además realizar evaluaciones usando niveles de madurez. Los niveles de madurez son conjuntos predefinidos de procesos que ayudan a una organización a mejorar en el desarrollo software evolucionando por los distintos niveles. En esta norma, se han establecido 6 niveles que indican la madurez de la organización. Como se observa en la Figura No. 2.2., el nivel inferior (nivel 0) se corresponde con una organización inmadura, los siguientes niveles van haciendo crecer a la organización en su madurez, hasta el máximo nivel, el nivel 5.

Figura 2.1 – Niveles de Madurez

La consecución de los niveles de madurez es de forma escalonada, esto significa que para alcanzar un determinado nivel de madurez deben haberse alcanzado también los niveles inferiores. Cada nivel de madurez estará formado por un conjunto de procesos, estos procesos se definen en los esquemas de certificación

CARRERAS PROFESIONALES

CIBERTEC

CALIDAD DE SOFTWARE

95

2.1.4. Calidad desde el Punto de Vista del Producto La calidad desde el punto de vista del producto se aborda con el uso de Modelos y/o Estándares de Calidad. Dichos modelos ayudan a la puesta en práctica del concepto general de calidad ofreciendo una definición más operacional. En los Modelos de Calidad de Producto, la calidad se define de forma jerárquica. Es un concepto que se deriva de un conjunto de subconceptos, cada uno de los cuales se va a evaluar a través de un conjunto de indicadores o métricas. La estructura es por lo general de tres (3) niveles (Ver figura 2.2).

Figura 2.2 – Estructura de un Modelo de Calidad de Software

Al utilizar los Modelos de Calidad de Producto, se lleva la calidad a algo concreto, algo que se puede definir, que se puede medir y, sobre todo, que se puede planificar. También permiten identificar y comprender las relaciones que se establecen y existen entre las diferentes características de un producto de software. La calidad del producto de software abarca los siguientes aspectos: • • •

Calidad Interna: que se puede medir a partir de las características intrínsecas del producto, por ejemplo el código fuente. Calidad Externa: que se puede medir a partir del comportamiento del producto, por ejemplo durante la ejecución de una prueba. Calidad en Uso: que se puede medir durante la utilización efectiva que hace del producto el usuario final.

Para lograr la calidad suficiente en estos tres aspectos es necesario conocer con suficiente detalle las necesidades reales y expectativas de los usuarios.

CIBERTEC

CARRERAS PROFESIONALES

96

2.1.5.

Calidad desde el Punto de Vista de las Personas Claramente, cualquier proceso de software depende de la calidad de la/s persona/s que lo desarrolla. La optimización de los procesos provee un ambiente de disciplina para trabajar de manera más formal. La disciplina debe ser manejada con cuidado, ya que, es fácil que se convierta en autoritarismo. La diferencia entre un ambiente con disciplina y otro con autoritarismo, es que el ambiente disciplinado controla el entorno y los métodos para especificar un estándar, mientras que un ambiente autoritario define la forma actual del trabajo. La disciplina es requerida en grandes proyectos de software para asegurar, por ejemplo, que todo el personal involucrado utilice la misma convención, no dañar los productos de otros equipos, y sincronizar apropiadamente el trabajo.

En la tabla 3 se muestra una lista resumida de algunos modelos y estándares de calidad. Nivel de Calidad Modelo de Calidad de SW CMMi TickIT Bootstrap Proceso Six Sigma Software

Producto

Personas

Gilb GQM Mc Call Furps Boehm SATC Dromey C-QM Metodología SQAE WebEQM Personal SW Process (PSP) Team SW Process (TSP)

Estándar de Calidad de SW ISO 9003 ISO 12207 ISO 15504 (SPICE) IEE/IEA 12207 ISO 20000 ITIL Cobit ISO 9126-1 ISO 25000 (SQUARE) IEEE Std. 1061-1998

Tabla No. 3 – Modelos y Estándares de Calidad de Software

CARRERAS PROFESIONALES

CIBERTEC

CALIDAD DE SOFTWARE

97

2.2. MÉTRICAS DE CALIDAD DE PRODUCTO SOFTWARE La ISO, bajo la norma ISO-9126, ha establecido un estándar internacional para la evaluación de la calidad de productos de software el cual fue publicado en 1992 con el nombre de “Information technology – Software product evaluation: Quality characteristics and guidelines for their use”, en el cual se establecen las características de calidad para productos de software. El estándar ISO-9126 establece que cualquier componente de la calidad del software puede ser descrito en términos de una o más de seis características básicas, las cuales son: funcionalidad, confiabilidad, usabilidad, eficiencia, mantenibilidad y portatilidad; cada una de las cuales se detalla a través de un conjunto de subcaracterísticas que permiten profundizar en la evaluación de la calidad de productos de software. La tabla 4 muestra la pregunta central que atiende cada una de estas características. Característica Funcionalidad

Pregunta Central ¿Las funciones y propiedades satisfacen las necesidades explícitas e implícitas; esto es, el qué … ?

Confiabilidad Usabilidad

¿Puede mantener el nivel de rendimiento, bajo ciertas condiciones y por cierto tiempo? ¿El software es fácil de usar y de aprender?

Eficiencia ¿Es rápido y minimalista en cuanto al uso de recursos? Mantenibilidad ¿Es fácil de modificar y verificar? Portabilidad ¿Es fácil de transferir de un ambiente a otro? Tabla No. 4 – Características de ISO 9126 y aspecto que atiende cada una

La ISO/IEC 9126 está formada por las siguientes partes: Parte 1 – Modelo de Calidad Parte 2 – Métricas Externas Parte 3 – Métricas Internas Parte 4 – Calidad en Uso

2.2.1. ISO/IEC 9126-1 – Modelo de Calidad Esta parte de la ISO 9126 describe el modelo de calidad del producto de software. La primera parte del modelo especifica 6 características de calidad interna y externa, las cuales están divididas en subcaracterísticas, que se manifiestan externamente cuando el software es utilizado como parte de un sistema, y son un resultado de atributos internos del software. La calidad externa evalúa que el software satisfaga las necesidades del usuario teniendo en cuenta las condiciones especificadas. Esta calidad es medible en el comportamiento del producto. La calidad interna evalúa el total de atributos que un software debe satisfacer teniendo en cuenta condiciones especificadas. Esta calidad es medible a partir de las características intrínsecas.

CIBERTEC

CARRERAS PROFESIONALES

98

Las características definidas son aplicables a todo tipo de software. Las características y subcaracterísticas proveen una terminología consistente respecto de la calidad del producto del software. Esta Norma permite especificar y evaluar la calidad del software desde distintas perspectivas, las cuales están asociadas a la adquisición, requerimientos, desarrollo, uso, evaluación, soporte, mantenimiento, aseguramiento de la calidad, y auditoria del software. Puede ser usada por desarrolladores, evaluadores independientes y grupos de aseguramiento de la calidad responsable de especificar y evaluar la calidad del software. La evaluación de los productos de software que satisfacen las necesidades de calidad del software es uno de los procesos del ciclo de vida de desarrollo del software. La calidad del producto de software puede ser evaluada por medio de la medición de atributos internos, externos o a través de la calidad en uso (Figura 2.3). El objetivo es que el producto tenga el efecto requerido en un contexto particular de uso. La calidad del proceso contribuye a mejorar la calidad del producto, y la calidad del producto contribuye a mejorar la calidad en uso. Evaluar y mejorar la calidad de un proceso contribuye a mejorar la calidad del producto; y esto contribuye a mejorar la calidad en uso. De manera similar, evaluar la calidad en uso puede mejorar la calidad del producto, y evaluar un producto puede mejorar un proceso.

Figura 2.3 – Calidad en el Ciclo de Vida según ISO/IEC 9126-1

Las necesidades de calidad del usuario contribuyen a especificar los “requisitos de calidad externa”, los cuales contribuyen a especificar los “requisitos de calidad interna”. La “calidad interna” indica la existencia de “calidad externa” y ésta indica la existencia de “calidad en uso” (Figura No. 2.4).

CARRERAS PROFESIONALES

CIBERTEC

CALIDAD DE SOFTWARE

99

Figura 2.4 – Relación de Métricas del Modelo / Atributos en ISO/IEC 9126-1

2.2.2. ISO/IEC 9126-2 - Métricas Externas ISO/IEC TR 9126-2 provee métricas externas para la medición de atributos a través de 6 características de calidad externa definidas en ISO/IEC 9126-1. ISO/IEC TR 9126-2 define métricas externas., ISO/IEC TR 9126-3 define métricas internas e ISO/IEC 9126-4 define métricas en calidad en uso para la medición de características o subcaracterísticas. Las métricas internas miden el software en sí mismo, las métricas externas miden el comportamiento del sistema basado en computadora que incluye el software, y las métricas de calidad en uso miden los efectos de uso del software en un contexto de uso específico. Las métricas externas usan medidas de un software, derivadas del comportamiento del mismo, a través de la prueba, operación y observación del software. Antes de adquirir o usar un software, éste debe ser evaluado usando las métricas basadas en los objetivos del área usuaria de la institución relacionados al uso, explotación y dirección del producto, considerando la organización y el ambiente técnico. La métrica externa proporciona a los usuarios, evaluadores, verificadores y desarrolladores, el beneficio que puedan evaluar la calidad del software durante las pruebas o el funcionamiento. Las métricas externas listadas en ISO/IEC TR 9126-2 no están destinadas a ser un conjunto exhaustivo. Los desarrolladores, evaluadores, gerentes de calidad y compradores pueden seleccionar

CIBERTEC

CARRERAS PROFESIONALES

100

métricas de ISO/IEC TR 9126-2 para definir requerimientos, evaluar productos de software, medir aspectos de calidad y otros propósitos. Los usuarios de ISO/IEC TR 9126-2 pueden seleccionar o modificar y aplicar métricas y mediciones a partir de ISO/IEC TR 9126-2 o pueden definir métricas específicas de la aplicación para su dominio de aplicación en particular. ISO/IEC TR 9126-2 es usada junto con ISO/IEC 9126-1. ISO/IEC TR 9126-2 contiene una explicación de cómo aplicar las métricas de calidad del software, un conjunto básico de métricas para cada Subcaracterística y un ejemplo de cómo aplicar las métricas durante el ciclo de vida del producto de software. ISO/IEC TR 9126-2 no asigna un rango de valores para estas métricas en niveles de porcentajes o grados de conformidad, debido a que estos valores son definidos en cada producto de software o en una parte del producto de software, dependiendo de factores tales como la categoría del software, nivel de integridad y necesidades del usuario. Algunos atributos pueden tener un rango de valores deseable, el cual no depende de las necesidades específicas del usuario pero si depende de factores genéricos; por ejemplo factores humanos.

2.2.3. ISO/IEC 9126-3 - Métricas Internas ISO/IEC TR 9126-3 provee métricas internas para la medición de atributos a través de 6 características de calidad interna definidas en ISO/IEC 9126-1. La métrica interna mide el software en sí mismo y puede ser aplicada a un software no ejecutable (como una especificación o código fuente) durante el diseño y la codificación. En el desarrollo de un software, los productos intermedios deben ser evaluados usando métricas internas que permitan medir las propiedades intrínsecas, incluyendo aquellas que pueden derivarse de comportamientos simulados. El propósito principal de esta métrica interna es asegurar que se logre la calidad externa y la calidad de uso requerida. La métrica interna proporciona a los usuarios, evaluadores, verificadores y desarrolladores el beneficio que puedan evaluar la calidad del software y lo referido a problemas de calidad antes que el software sea puesto en ejecución. Las métricas internas miden atributos internos o indican los atributos externos, a través del análisis de las propiedades estáticas de productos intermedios o entregables del software. Las medidas de las métricas internas usan números o frecuencias de elementos de composición de software, los cuales aparecen, por ejemplo, en las sentencias de código de fuente, control de gráficos, flujo de datos y estados de representación de procesos Las métricas listadas en ISO/IEC TR 91263 no están destinadas a ser un conjunto exhaustivo. Los desarrolladores, evaluadores, gerentes de calidad y compradores pueden seleccionar métricas de ISO/IEC TR 9126-3 para definir requerimientos, evaluar productos de software, medir aspectos de calidad y otros propósitos. ISO/IEC TR 9126-3 es usada junto con ISO/IEC 9126-1. ISO/IEC TR 9126-3 contiene una explicación de cómo aplicar las métricas de calidad del software, un conjunto básico de métricas para cada Subcaracterística y un ejemplo de cómo aplicar las métricas

CARRERAS PROFESIONALES

CIBERTEC

CALIDAD DE SOFTWARE

101

durante el ciclo de vida del producto de software. ISO/IEC TR 9126-3 no asigna un rango de valores para estas métricas en niveles de porcentajes o grados de conformidad, debido a que estos valores son definidos en cada producto de software o en una parte del producto de software, dependiendo de factores tales como la categoría del software, nivel de integridad y necesidades del usuario. Algunos atributos pueden tener un rango de valores deseable, el cual no depende de las necesidades específicas del usuario pero si depende de factores genéricos; por ejemplo factores humanos. En la tabla No. 5 se muestra un ejemplo de métrica, tanto para calidad externa como para calidad interna. Note que las entradas para la medición difieren.

2.2.4. Relación Entre las Métricas Internas y Externas Cuando los requisitos de calidad del software son definidos, se listan las características o subcaracterísticas de calidad del software que contribuyen a dichos requisitos. Entonces, las métricas externas apropiadas y los rangos aceptables son especificados para cuantificar el criterio de calidad que valida que el software satisface las necesidades del usuario. Luego, los atributos de calidad interna del software se definen y especifican para planear y finalmente lograr la calidad externa y calidad en el uso requeridas, para construirlos durante el desarrollo del producto. Ver Figura No. 2.5. Las métricas internas y los rangos aceptables son especificados para cuantificar los atributos de calidad interna, así ellos pueden usarse para verificar que el software intermedio reúne las especificaciones de calidad interna durante el desarrollo. Se recomienda que las métricas internas que se usen tengan en lo posible una fuerte relación con la métrica externa diseñada, para que ellas puedan ser usadas para predecir los valores de las métricas externas. Sin embargo, es generalmente difícil diseñar un modelo teórico riguroso que proporcione una relación fuerte entre la métrica interna y la externa. Característica Sub Característica Métrica Próposito de la Métrica

Funcionalidad Aplicabilidad Adecuación Funcional (Calidad Externa) ¿Cuán adecuadas son las funciones evaluadas? Número de funciones que son adecuadas para realizar las tareas específicas comparadas con el número de funciones evaluadas

Método de Aplicación

Fórmula

X=1-A/B Número de funciones en que se detectaron Valor A problemas en la evaluación Valor B Número de funciones evaluadas Interpretación del valor 0