Calidad de Software

Calidad de Software
CARRERAS PROFESIONALES
CIBERTEC
CALIDAD DE SOFTWARE
NDICE
Presentacin Red de contenidos
Pgina
7 8
Unidad de aprendizaje 1
1.1 Tema 1 : Calidad de Software 1.1.1. : Definicin de Calidad 1.1.2. : Poltica de Calidad 1.1.3. : Terminologa segn ISO 8402 1.1.4. : Definicin de Calidad de Software 1.2 Tema 2 : Aseguramiento y Control de Calidad 1.2.1. : SQA (Software Quality Assurance) no es lo mismo que SQC (Software Quality Control) 1.2.2. : Funciones Generales del SQA 1.3 Tema 3 : Modelo de Procesos 1.3.1. : El Proceso de Desarrollo de Software 1.3.2. : Normas Relacionados con el Proceso de Desarrollo de Software 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 Reutilizacin 1.4.6. : Procesos Iterativos 1.4.7. : Cul es el modelo de procesos ms adecuado?
10 10 11 11 13 20 21
22 25 27 30
34 35 35 35 37 38 39 40 42
CIBERTEC
1.5 Tema 5 : Verificacin y Validacin 1.5.1. : Verificacin 1.5.2. : Validacin 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
44 44 44 45 45 45
2.1 Tema 6 : Modelos de Calidad de Software 2.1.1. : Introduccin 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 : Mtricas de Calidad de Producto Software 2.2.1. : ISO/IEC 9126-1 Modelo de Calidad 2.2.2. : ISO/IEC 9126-2 Mtricas Externas 2.2.3. : ISO/IEC 9126-3 Mtricas Internas 2.2.4. : Relacin entre las Mtricas Internas y Externas 2.2.5. : ISO/IEC 9126-4 Mtricas para Calidad en Uso 2.2.6. : ISO/IEC 25000:2005 SquaRE 2.3 Tema 8 : Evaluacin de Mtricas 2.3.1. : Definiciones 2.3.2. : Proceso de Evaluacin
85 86 86 87 88 89 90 91 93 93 94 95 96 98 98 98
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 3.2.1 3.2.2 Planeacin y Control de Pruebas Anlisis y Diseo de las Pruebas
105 106 108 108 108
CIBERTEC
CALIDAD DE SOFTWARE
3.2.3 3.2.4 3.2.5
Implementacin y Ejecucin de Pruebas Evaluacin de Criterios de Salida y Reportes Cierre de Pruebas
109 109 109 111 111 113 116 118 120
3.3 Tema 11 : Estrategia de Pruebas 3.3.1 3.3.2 3.3.3 3.3.4 3.3.5 Casos de Prueba Diseo de Casos de Prueba Realizar Casos de Prueba Informe y Seguimiento de Pruebas Relacin entre las Pruebas y la Depuracin
CIBERTEC
CIBERTEC
CALIDAD DE SOFTWARE
PRESENTACIN
Calidad de Software pertenece a la lnea formativa y se dicta en la carrera de Computacin e Informtica y de Administracin 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 diseado 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 sesin, que le permitirn reforzar lo aprendido en la clase. El curso tiene un formato terico prctico. 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 Gestin de Proyectos de TI. Los conceptos y las tcnicas de control de calidad se implementan tambin en el curso de Anlisis y Diseo de Sistemas III de la carrera de Administracin y Sistemas, con verificaciones de entregables previamente establecidos. .
CIBERTEC
RED DE CONTENIDOS
Calidad de Software
Aseguramie nto de la Calidad de Software
Mtricas de Software
Pruebas de Software
Calidad de Software
Modelos de Calidad de Software Mtricas de Calidad de Productos de Sofware
Pruebas de Software
Aseguramiento y Control de Calidad Modelo de Procesos
Ciclo de Vida de las Pruebas Estrategia de Pruebas
Evaluacin de Mtricas Modelos de Ciclo de Vida de Software Verificacin y Validacin

UNIDAD DE APRENDIZAJE
CIBERTEC
CALIDAD DE SOFTWARE
CALIDAD DE SOFTWARE
LOGRO DE LA UNIDAD DE APRENDIZAJE
Al trmino de la unidad de aprendizaje, el alumno disea la lista de verificacin del Reporte de Especificacin de Software y el Plan de Desarrollo considerando los requerimientos previamente definidos por el Lder Usuario para el proyecto integrado de quinto ciclo.
TEMARIO
1.1. Tema 1: Calidad de Software 1.1.1. Definicin de Calidad 1.1.2. Poltica de Calidad 1.1.3. Terminologa segn ISO 8402 1.1.4. Definicin 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 Reutilizacin 1.4.6. Procesos Iterativos 1.4.6.1. Desarrollo Incremental 1.4.6.2. Desarrollo en Espiral 1.4.7. Cul es el modelo de procesos ms adecuado? 1.5. Tema 5: Verificacin y Validacin de Software 1.5.1. Verificacin 1.5.2. Validacin 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
10
1.1. CALIDAD DE SOFTWARE

Los conceptos relacionados con la calidad de software tienen relacin directa con la aplicacin de la calidad a un producto desarrollado a travs de procesos de ingeniera de software. En tal sentido empezaremos dando algunas definiciones de calidad y luego ampliaremos el concepto hacia calidad de software.
1.1.1. Definicin de Calidad
CIBERTEC
CALIDAD DE SOFTWARE
11
Existen muchas definiciones de calidad y muchos trminos que se utilizan en la gestin 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 caractersticas de una entidad que le confieren la aptitud para satisfacer las necesidades establecidas e implcitas. Tambin podra 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 percepcin del servicio y la expectativa que el cliente tena del mismo. Calidad tambin es la satisfaccin 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 mnimo 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 percepcin que los clientes tienen sobre su empresa est basada en el producto o servicio que les suministra, pero tambin en el contacto diario que mantienen con los directivos. El concepto de calidad abarca no slo como se atienden las exigencias de sus clientes sino tambin la forma en que se hace, cmo se atiende el telfono, 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 compaa 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 envan las facturas, los dictmenes de los abogados, todos deben involucrarse en el concepto de calidad, en satisfacer las exigencias del cliente, en crear una compaa 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. Poltica de Calidad

ISO 8402 la define como: "Directrices y objetivos generales de una empresa relativos a la calidad, expresados formalmente por la Direccin General". Es una de las vas para hacer operativa la estrategia. Al desplegar verticalmente la poltica a travs de los niveles jerrquicos de la organizacin:
CIBERTEC
12
Se proporciona orientacin precisa para que ejecutivos y mandos elaboren planes concretos de accin. Se cohesiona la organizacin para el cumplimiento de los objetivos de calidad. Se refuerza el compromiso del personal.
La poltica de calidad debe ser: Adecuada a la empresa. Coherente con las necesidades y expectativas de sus clientes. Muy simple y fcilmente comprensible para que sea comunicable y entendida sin dificultad.
En cuanto a su contenido, debera 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, formacin. La va a utilizar (ISO, Mejora Continua, etc.).
Es la totalidad de aspectos y caractersticas de un producto o servicio que se refieren a su capacidad para satisfacer necesidades dadas en la adecuacin de sus objetivos'. El Instituto de Ingeniera 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. Terminologa segn ISO 8402

1. Calidad: Conjunto de propiedades y caractersticas de un producto o servicio que le confieren su aptitud para satisfacer unas necesidades explicitas o implcitas. 2. Control de Calidad: Conjunto de tcnicas y actividades de carcter operativo, utilizadas para verificar los requerimientos relativos a la calidad del producto o servicio. 3. Garanta de Calidad: Conjunto de acciones planificadas y sistemticas necesarias para proporcionar la confianza adecuada de que un producto o servicio cumplir los requerimientos dados sobre calidad. 4. Gestin de Calidad: Aspecto de la funcin de gestin que determina y aplica la poltica de la calidad, los objetivos y las responsabilidades y que lo realiza con medios tales como la planificacin de la calidad, el control de la calidad, la garanta de calidad y la mejora de la calidad. 5. Sistema de Gestin de Calidad: Conjunto de la estructura de la organizacin, de responsabilidades, procedimientos, procesos y recursos que se establecen para llevar a trmino la gestin de calidad.
CIBERTEC
CALIDAD DE SOFTWARE
13
El QS debe tener el volumen y alcance suficiente para conseguir los objetivos de calidad. El QS de una organizacin est fundamentalmente previsto para satisfacer las necesidades internas de la organizacin. Es ms amplio que los requerimientos de un cliente concreto que nicamente valore el QS que le interesa (directamente). Para finalidades contractuales o vinculantes en la valoracin de la calidad, se puede exigir que se ponga de manifiesto la realizacin 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. Accin Correctiva: Accin tomada para eliminar las causas de una no conformidad, defecto o cualquier situacin indeseable existente, para evitar su repeticin. 8. Accin Preventiva: Accin tomada para eliminar las causas de una no conformidad, defecto o cualquier situacin 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 provisin 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. Inspeccin: Actividades como medir, examinar, ensayar o comparar una o ms caractersticas 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 caractersticas. 13. No Conformidad: No satisfaccin de un requisito especificado. 14. Trazabilidad: Aptitud de reconstruir la historia, la utilizacin o la localizacin de un producto por medio de identificaciones registradas. 15. Validacin: Confirmacin por examen y aporte de evidencias objetivas de que los requisitos particulares para un uso especfico previsto han sido satisfechos. 16. Verificacin: Confirmacin por examen y aporte de evidencias objetivas que los requisitos especificados han sido satisfechos.
CIBERTEC
14
SISTEMA DE GESTIN DE LA CALIDAD MEJORA CONTINUA
C L I E N T E S
R E Q U I S I T O S
Responsabilidad de la Direccin Gestin de recursos
Medicin, anlisis y mejoramiento
Entrada
Realizacin Producto o Servicio
S A T I S F A C C I O N Producto o Servicio
Salida
Figura 1.1 - Sistema de Gestin de Calidad
1.1.4. Definicin de Calidad de Software

La Calidad del Software es el conjunto de cualidades que lo caracterizan y que determinan su utilidad y existencia. Segn R. Pressman: La calidad del software se define como la concordancia con los requisitos funcionales y de rendimiento explcitamente establecidos, con los estndares y procesos de desarrollo explcitamente documentados y con las caractersticas implcitas que se espera de todo software desarrollado profesionalmente. No hay duda de que la anterior definicin puede ser modificada o ampliada. De hecho, no tendra fin una discusin sobre una definicin definitiva de la calidad del software. Para los propsitos de este enfoque, la anterior definicin 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 estndares especificados definen un conjunto de criterios de desarrollo que guan la forma en que se aplica la ingeniera del software o del conocimiento. En caso de no seguirse esos criterios, casi siempre habr falta de calidad. 3. Existe un conjunto de requisitos implcitos que a menudo no se mencionan (por ejemplo la necesidad de una interfaz intuitiva). Si el software se ajusta a sus requisitos explcitos pero falla en alcanzar los requisitos implcitos, la calidad del software se debilita. Queda claro a partir de la definicin de calidad del software, que sta es siempre relativa a los requisitos o necesidades que se desea satisfacer. Por eso la evaluacin de la calidad del software siempre va a implicar la comparacin entre los requisitos y el producto generado.
CIBERTEC
CALIDAD DE SOFTWARE
15
La Calidad del Software es medible y vara 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 perodo (10 aos o ms) necesita ser confiable, mantenible y flexible para disminuir los costos de mantenimiento y perfeccionamiento durante el tiempo de explotacin. La Calidad del Software puede medirse despus de elaborado el producto. Pero esto puede resultar muy costoso si se detectan problemas derivados de imperfecciones en el diseo, por lo que es imprescindible tener en cuenta tanto la obtencin 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 organizacin, entre ellos estn la complejidad del producto, las tecnologas y las personas, as como algunas condiciones de entorno que tambin tienen su impacto, estas pueden ser condiciones de gestin (plazo de entrega, restricciones dentro de la organizacin), entornos de desarrollo y caractersticas 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 organizacin. 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 organizacin
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
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 parmetros, indicadores o criterios de medicin. 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. Definir el software que va a ser controlado: clasificacin por tipo, mbito de aplicacin, complejidad, etc., de acuerdo con los estndares 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 mtodos de valoracin de los indicadores: mtodos manuales como cuestionarios o encuestas estndares para la medicin de criterios parciales y herramientas automatizadas para medir los criterios de clculo.
2.
3.
Los procedimientos pueden variar en cada organizacin, pero lo importante es que estn escritos, personalizados, adaptados a los procesos de la organizacin y, lo que es ms importante, que se cumplan. La Calidad del Software debe implementarse a lo largo de todo el ciclo de vida, debe correr paralela desde la planificacin del producto hasta la fase de produccin del mismo.
CIBERTEC
CALIDAD DE SOFTWARE
17
Para ello se cuenta con una serie de ayudas, a travs de distintas actividades para la implantacin del control de calidad en el desarrollo que son: Aplicacin de metodologa y tcnicas de desarrollo Reutilizacin de procesos de revisin formales Prueba del software Ajustes a los estndares de desarrollo Control de cambios, mediciones y recopilacin de informacin Gestin de informes sobre el control de calidad Para la fase de Planificacin, se pueden utilizar elementos y herramientas propias de la Gestin de proyectos, como la: Estimacin de la duracin, costo y esfuerzo para la construccin del producto. En lo referido a la estimacin habr que tener presentes las Mtricas de software Planificacin de tareas que hay que realizar, asignacin de personas, tiempo, costo y otros parmetros para construccin del producto Para los procesos de Anlisis y Diseo deberemos contar con: Sistemas de obtencin de requisitos Mtricas de software Herramientas de Generacin de Datos Casos de Prueba En los procesos de Construccin y pruebas deberamos usar: Herramientas de Gestin de la Configuracin Herramientas de Simulacin Casos de Pruebas Y, finalmente, para el proceso de Produccin, bsicamente debemos utilizar: Herramientas de monitoreo de resultados Pruebas de produccin Definir las regulaciones organizativas para realizar el control: quienes participan en el control de calidad, cundo se realiza, qu documentos deben ser revisados y elaborados, etc. El Instituto de Ingeniera 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.
CIBERTEC
18
1.1.4.2. Aseguramiento de Calidad: Es el conjunto de actividades planificadas y sistemticas 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 caractersticas del diseo de software se pueden especificar de modo que eliminarn o controlarn 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 rene los requerimientos y su desempeo 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 relacin aseguramiento de la calidad del software: (Wiegers, 1990) i) La calidad no se puede probar, se construye. al
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 estn directamente involucradas en el esfuerzo de desarrollo. El aseguramiento de la calidad de software comprende una gran variedad de tareas: i) Participar en descripcin 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 estndares 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 anlisis como en el diseo y la codificacin, de manera que puedan ser eliminados cuanto antes.
CIBERTEC
CALIDAD DE SOFTWARE
19
vi) Gestin de configuraciones de software (control de la documentacin 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 revisin 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 estn dirigidas a: i) Identificar las posibles desviaciones en los estndares 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 ms importantes del aseguramiento de la calidad, debido a que permiten eliminar defectos lo ms pronto posible, cuando son menos costosos de corregir. Es importante sealar que la calidad de un producto software no se puede referir nicamente a obtener un producto sin errores. La especificacin de la calidad del software debe ser ms detallada y exacta, y el camino para ello es la formalizacin de la calidad mediante un modelo de calidad. Un modelo de calidad es un conjunto de buenas prcticas para el desarrollo del software, enfocado en los procesos de gestin y desarrollo de proyectos, cuyo objetivo es el desarrollo de productos de calidad de manera consistente y predecible.
CIBERTEC
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 informtica, 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.
CIBERTEC
CALIDAD DE SOFTWARE
21
1.2. ASEGURAMIENTO Y CONTROL DE CALIDAD

La Administracin de la Calidad, es un rea de conocimiento de todo proyecto, que incluye tres fases bien identificadas: la Planificacin, el Aseguramiento y el Control. El proceso de Planificacin de la Calidad en todo proyecto, toma como entradas las Polticas de Calidad de la compaa, el informe de Alcance del proyecto, la descripcin del sistema (producto/s), normas, regulaciones y estndares que deben aplicarse, para producir como salidas un Plan de Direccin de Calidad, definiciones operativas y check-lists utilizadas por los procesos de Aseguramiento y Control de Calidad. Para ello se utilizan como herramientas el Anlisis de costo-beneficio, diagramas de flujo, los diagramas de causa-efecto (Ishikawa), o el Benchmarking. Esta fase es la ms importante en cuanto a calidad se refiere, porque se identifican posibles cuellos de botella, duplicacin 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 especficos 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 fabricacin: desde el anlisis de requerimientos hasta la puesta en produccin. Al igual que ocurri con la definicin 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 gua planificada y sistemtica de todas las acciones necesarias para proveer la evidencia adecuada de que un producto cumple los requerimientos tcnicos establecidos. Un conjunto de actividades diseadas para evaluar el proceso por el cual un producto es desarrollado o construido. Daniel Galin define SQA como: Un conjunto, sistemtico 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 tcnicos funcionales tan bien como los requerimientos gerenciales para cumplir la planificacin 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
22
Desde el punto de vista del aseguramiento, Don Reifer define SQA como El aseguramiento de la calidad del software es el sistema de mtodos y procedimientos usados para asegurar que el producto de software alcanza sus requerimientos. El sistema involucra la planificacin, estimacin 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 sistemticas 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 validacin y verificacin y luego empiezan a hablar de revisiones, las cuales son slo extensiones del testing. Es decir, a menudo hay una confusin entre SQA y el testing (el cual actualmente forma parte del rea de control de calidad del software SQC). Haciendo slo testing y revisiones no aseguramos la calidad de los productos, sino aseguramos el cumplimiento de especificaciones tanto funcionales como tcnicas. En el desarrollo de software la diferencia entre SQC y SQA no est clara y estos trminos 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 caractersticas 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, estndares y planes. Evala que los procesos, planes y estndares utilizados en el proyecto cumplan con los estndares organizacionales Revisa procesos
SQC Detecta problemas en los productos de trabajo.
Verifica que los productos de trabajo cumplan con los estndares de calidad especificados en el plan de proyecto. Revisa el contenido del producto
Tabla 1 Diferencia entre SQA y SQC
En conclusin, el rol del SQA es auditar que los distintos equipos de la organizacin, inclusive el de SQC siguen los procedimientos, estndares y procesos establecidos. El equipo de SQA debera
CIBERTEC
CALIDAD DE SOFTWARE
23
establecer mtricas para medir la efectividad del proceso. Como complemento el rol de SQC es tomar una actitud activa de verificacin y validacin 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 organizacin nos dar una visin clara de las funciones que puede llevar a cabo. Como polica 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 gustara encontrar. Ayudar a la organizacin a sensibilizarse con las necesidades del cliente. Actuar como un cliente de prueba para obtener una alta satisfaccin del cliente. Como analista El trabajo del equipo de SQA es recabar informacin. Entre sus funciones en este rol se encuentran: Juntar muchos datos sobre todos los aspectos del producto y del proceso. Con esta informacin ayudar a mejorar los procesos y los productos. Como proveedor de informacin El trabajo del equipo de SQA es revisar qu es lo que est hecho y decir cules objetivos tcnicos realmente estn cumplidos para que la gerencia pueda tomar mejores decisiones de negocios. Entre sus funciones en este rol se encuentran: Proveer informacin tcnica objetiva para que la gerencia pueda usarla para tomar mejores decisiones. Proveer informacin apropiada de las clases de productos y de los riesgos asociados con estos. Concentrarse ms en la reduccin de los riesgos que en el cumplimiento del proceso.
CIBERTEC
24
Como responsable de la elaboracin del proceso El trabajo del equipo de SQA es participar en la definicin de los planes, procesos, estndares 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 polticas de la organizacin. Para cumplir este rol el aseguramiento de la calidad debera comenzar en las fases tempranas del proyecto. Para ser efectivo, el equipo que realiza SQA debe ser independiente de la organizacin de desarrollo. Aunque tener un grupo de auditora independiente es difcil de aplicar en organizaciones chicas donde hay pequeos ambientes de desarrollos. Pero si la organizacin es madura y tiene una cultura orientada a la calidad, la funcin 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 debera estar entrenado en el aseguramiento de la calidad. Las actividades de aseguramiento de la calidad realizadas para un producto deberan ser separadas de aquellas involucradas en el desarrollo y mantenimiento del mismo. Debe estar disponible un canal de comunicacin 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 informacin fehaciente, objetiva en el momento adecuado. La clave aqu est en que el grupo de SQA provee a la gerencia de informacin tcnica objetiva. La gerencia necesita ver a la gente de SQA como una fuente de informacin significativa que puede ayudarla a tomar decisiones difciles. La Gerencia usa esta informacin para tomar decisiones de negocio apropiadas. La objetividad en la evaluacin de calidad de los procesos y productos es crtica para el xito del proyecto. La objetividad se logra con independencia del equipo de SQA y sentido comn o criterio. Hay diferentes maneras de realizar evaluaciones objetivas, entre las que se incluyen: Auditoras formales realizadas por un rea de SQA independiente de la organizacin. 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.
CIBERTEC
CALIDAD DE SOFTWARE
25
La tarea del equipo de SQA es un conjunto planificado de tareas, actividades y acciones ejecutadas independientemente de la organizacin que desarrolla software, que provee a la gerencia del proyecto informacin fehaciente en un momento preciso que puede ser usada para tomar decisiones de negocio apropiadas
CIBERTEC
26
1.3. MODELO DE PROCESOS

Un sistema informtico est compuesto por hardware y software. En cuanto al hardware, su produccin se realiza sistemticamente 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 mquina construida por el hombre. Sin embargo, respecto del software, su construccin y resultados han sido histricamente cuestionados debido a los problemas asociados, entre ellos podemos destacar los siguientes: i) ii) Los sistemas no responden a las expectativas de los usuarios. Los programas fallan con cierta frecuencia.
iii) Los costos del software son difciles de prever y normalmente superan las estimaciones. iv) La modificacin del software es una tarea difcil y costosa. v) El software se suele presentar fuera del plazo establecido y con menos prestaciones de las consideradas inicialmente.
vi) Normalmente, es difcil cambiar de entorno hardware usando el mismo software. vii) El aprovechamiento ptimo de los recursos (personas, tiempo, dinero, herramientas, etc.) no suele cumplirse. Segn el Centro Experimental de Ingeniera de Software (CEIS), el estudio de mercado The Chaos Report realizado por Standish Group Internactional en 1996, concluy que slo 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 trmino. Algunas deficiencias comunes en el desarrollo de software son: i) ii) Escasa o tarda validacin con el cliente. Inadecuada gestin de los requisitos.
iii) No existe medicin del proceso ni registro de datos histricos. iv) Estimaciones imprevistas de plazos y costos. v) Excesiva e irracional presin en los plazos.
vi) Escaso o deficiente control en el progreso del proceso de desarrollo. vii) No se hace gestin de riesgos formalmente. viii) No se realiza un proceso formal de pruebas. ix) No se realizan revisiones tcnicas formales e inspecciones de cdigo.
CIBERTEC
CALIDAD DE SOFTWARE
27
El primer reconocimiento pblico de la existencia de problemas en la produccin de software tuvo lugar en la conferencia organizada en 1968 por la Comisin de Ciencias de la OTAN en Garmisch (Alemania), dicha situacin problemtica se denomin crisis del software. En esta conferencia, as como en la siguiente realizada en Roma en 1969, se estipul el inters hacia los aspectos tcnicos y administrativos en el desarrollo y mantenimiento de productos software. Se pretenda acordar las bases para una ingeniera de construccin de software. Segn Fritz Bauer lo que se necesitaba era establecer y usar principios de ingeniera orientados a obtener software de manera econmica, que sea fiable y funcione eficientemente sobre mquinas reales. Esta definicin marcaba posibles cuestiones tales como: Cules son los principios robustos de la ingeniera aplicables al desarrollo de software de computadora? Cmo construimos el software econmicamente para que sea fiable? Qu se necesita para crear programas de computadora que funcionen eficientemente no en una mquina sino en diferentes mquinas reales?. Sin embargo, dicho planteamiento adems deba incluir otros aspectos, tales como: mejora de la calidad del software, satisfaccin del cliente, mediciones y mtricas, etc. El IEEE Standard Glossary of Software Engineering Terminology (Stad. 610.121990) ha desarrollado una definicin ms completa para ingeniera del software: La aplicacin de un enfoque sistemtico, disciplinado y cuantificable para el desarrollo, operacin y mantenimiento del software; es decir, la aplicacin de ingeniera al software. El estudio de enfoques en Pressman caracteriza la Ingeniera de Software como una tecnologa multicapa, ilustrada en la Figura 3.1.
Figura 3.1 - Capas de la Ingeniera de Software
Dichas capas se describen a continuacin: 1. Cualquier disciplina de ingeniera (incluida la ingeniera del software) debe descansar sobre un esfuerzo de organizacin de calidad. La gestin total de la calidad y las filosofas similares fomentan una cultura continua de mejoras de procesos que conduce al desarrollo de enfoques cada vez ms robustos para la ingeniera del software. 2. El fundamento de la ingeniera 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 gestin de proyectos de software y establecen el contexto en el cual: se aplican los mtodos tcnicos, se producen resultados de trabajo, se establecen hitos, se asegura la calidad y el cambio se gestiona adecuadamente.
CIBERTEC
28
3. Los mtodos de la ingeniera de software indican cmo construir tcnicamente el software. Los mtodos abarcan una gran gama de tareas que incluyen anlisis de requisitos, diseo, construccin de programas, pruebas y mantenimiento. Estos mtodos dependen de un conjunto de principios bsicos que gobiernan cada rea de la tecnologa e incluyen actividades de modelado y otras tcnicas descriptivas. 4. Las herramientas de la ingeniera del software proporcionan un soporte automtico o semi-automtico para el proceso y los mtodos, a estas herramientas se les llama herramientas CASE (Computer-Aided Software Engineering). Dado lo anterior, el objetivo de la ingeniera de software es lograr productos de software de calidad (tanto en su forma final como durante su elaboracin), mediante un proceso apoyado por mtodos y herramientas. A continuacin 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 propsito la produccin eficaz y eficiente de un producto software que rena los requisitos del cliente. Dicho proceso, en trminos 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 ingeniera, en el desarrollo de software hay una serie de desafos adicionales, relativos esencialmente a la naturaleza del producto obtenido. A continuacin se explican algunas particularidades asociadas al desarrollo de software y que influyen en su proceso de construccin. 1. Un producto software en s es complejo, es prcticamente inviable conseguir un 100% de confiabilidad de un programa por pequeo que sea. Existe una inmensa combinacin de factores que impiden una verificacin exhaustiva de las todas posibles situaciones de ejecucin 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.). Un producto software es intangible y por lo general muy abstracto, esto dificulta la definicin del producto y sus requisitos, sobre todo cuando no se tiene precedentes en productos software similares. Esto hace que los requisitos sean difciles de consolidar tempranamente. As, los cambios en los requisitos son inevitables, no slo despus de entregado en producto sino tambin durante el proceso de desarrollo. Adems, de las dos anteriores, siempre puede sealarse la inmadurez de la ingeniera del software como disciplina, justificada por su corta vida comparada con otras disciplinas de la ingeniera. Sin embargo, esto no es ms que un intil consuelo.
2.
3.
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 difcil 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. Especificacin de software: Se debe definir la funcionalidad y restricciones operacionales que debe cumplir el software. 2. Diseo e Implementacin: Se disea y construye el software de acuerdo a la especificacin. 3. Validacin: El software debe validarse, para asegurar que cumpla con lo que quiere el cliente. 4. Evolucin: El software debe evolucionar, para adaptarse a las necesidades del cliente. Adems 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 sealan a continuacin: 1. Seguimiento y control de proyecto de software. 2. Revisiones tcnicas formales. 3. Garanta de calidad del software. 4. Gestin de configuracin del software. 5. Preparacin y produccin de documentos. 6. Gestin de reutilizacin. 7. Mediciones. 8. Gestin de riesgos.
CIBERTEC
30
Pressman caracteriza un proceso de desarrollo de software como se muestra en la Figura 2.3. Los elementos involucrados se describen a continuacin: 1. Un marco comn del proceso, definiendo un pequeo nmero de actividades del marco de trabajo que son aplicables a todos los proyectos de software, con independencia del tamao o complejidad. 2. Un conjunto de tareas, cada uno es una coleccin de tareas de ingeniera del software, hitos de proyectos, entregas y productos de trabajo del software, y puntos de garanta de calidad, que permiten que las actividades del marco de trabajo se adapten a las caractersticas del proyecto de software y los requisitos del equipo del proyecto. 3. Las actividades de proteccin, tales como garanta de calidad del software, gestin de configuracin del software y medicin, abarcan el modelo del proceso. Las actividades de proteccin 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 Quin debe hacer Qu, Cundo y Cmo debe hacerlo.
CIBERTEC
CALIDAD DE SOFTWARE
31
Figura 3.4 - Relacin 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. Quin: Las Personas participantes en el proyecto de desarrollo desempeando uno o ms Roles especficos. 2. Qu: Un Artefacto es producido por un Rol en una de sus Actividades. Los Artefactos se especifican utilizando Notaciones especficas. Las Herramientas apoyan la elaboracin de Artefactos soportando ciertas Notaciones. 3. Cmo y Cundo: 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 terminacin de ciertos Artefactos. La composicin y sincrona de las actividades est basada en un conjunto de Principios y Prcticas. Las Prcticas 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 utilizacin en distintos mbitos. En particular, en el campo de las tecnologas de la informacin, se han desarrollado o se han adaptado, de otros contextos, modelos para favorecer la adopcin de buenas prcticas para la realizacin de los procesos del ciclo de vida del software. Estos modelos en calidad de proceso software han evolucionado, siendo quizs una de las ms 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
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 gua de aplicacin de la ISO 9001:2000 para el sector informtico. En el campo de las tecnologas de informacin, relacionado a procesos de software, se tienen una variedad creciente de propuestas y estndares que han ido evolucionando o mejorando de acuerdo al desarrollo tecnolgico. Existen varios modelos que cubren diversos aspectos y han sido desarrollados con distintos propsitos. 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 (gestin de servicios de TI), ITIL (biblioteca de infraestructura de tecnologas de informacin), ISO/IEC 15504 (modelo para la evaluacin 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 (mtodo de evaluacin de procesos usado para CMMI), Quick Locus (mtodo ligero brasileo de evaluacin de CMMI), PMBOK (Cuerpo de conocimiento de gestin de proyectos de PMI), ISO 10006 (directrices para la calidad en la gestin de proyectos), MoProSoft (modelo de procesos de referencia mexicano), EvalProSoft (mtodo de evaluacin basado en 15504 para MoProSoft), SIMEP-Sw (conjunto de modelos ligeros para mejor de procesos, colombiano), MPS.BR (modelos de mejor y evaluacin de procesos brasileos), TMMI (modelo de madurez para Pruebas de Software), SPIRE (modelo de mejora de la regin 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 ms atencin en los ltimos aos. Dentro del campo de la informtica se tienen entre otros a CMMI, MoProSoft, el par ISO/IEC12207-ISO/IEC 15504 y TMMI; y fuera del campo de la informtica 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, estn vinculados necesariamente por el concepto que tratan de representar: un modelo de madurez organizacional; sin embargo al no existir algn referente que oriente como definir este tema, es posible que cada cual adopte el suyo propio.
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 interactan, 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 terico, generalmente en forma matemtica, de un sistema o de una realidad compleja. DRAE iii) Ciclo de desarrollo de software:
CIBERTEC
34
Periodo de tiempo que comienza con la decisin 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 evolucin del producto de software, se infiere que dentro de cada una de las etapas del ciclo de vida se implementen procesos de desarrollo.
Proceso
Ciclos de vida
Necesidades
Especificacin de Requisitos
Diseo
Codigo
Sistema Software
Obtener Requisitos
Disear Sistema
Codificar
Probar
Figura 3.9 - Procesos y Ciclos de Vida
CIBERTEC
CALIDAD DE SOFTWARE
35
De la definicin de proceso se infiere que cada proceso genera productos, tal como se muestra a continuacin:
Figura 3.10 - Procesos y Productos
1.3.3.
Los Procesos ISO 12207:2008

El modelo ISO 12207:2008 establece un conjunto de buenas prcticas 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 adquisicin de un producto o servicio software y durante el suministro, desarrollo, operacin, mantenimiento y evolucin de productos software.
CIBERTEC
36
Figura 3.11 - Modelo de Procesos ISO 12207:2008
CICLO DE VIDA: :
Nace
Muere
INVOLUCRADOS (STAKEHOLDERS)
Adquirientes,
proveedores,
usuarios, ...
PROCESOS CORPORATIVOS APLICACIN : PROYECTOS PRODUCTOS PROYECTOS SERVICIOS
DETALLES: :
PROCESOS , DEFINICIO NES Y DESCRIPCIONES
METODO LOG AS , MTO DOS Y MTRICAS
PROCEDIMIENTO S , TCNICAS , HERRAM IENTAS Y ENTORNOS
Figura 3.12 - Modelo de Procesos ISO 12207:2008 Alcance
CIBERTEC
CALIDAD DE SOFTWARE
37
1.4. MODELO DE CICLO DE VIDA DE SOFTWARE

Sommerville define modelo de proceso de software como Una representacin simplificada de un proceso de software, representada desde una perspectiva especfica. Por su naturaleza los modelos son simplificados, por lo tanto un modelo de procesos del software es una abstraccin de un proceso real. Los modelos genricos 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 continuacin: Codificar y corregir Modelo en cascada Desarrollo evolutivo Desarrollo formal de sistemas Desarrollo basado en reutilizacin Desarrollo incremental Desarrollo en espiral
1.4.1.
Codificar y corregir (Code-and-Fix)

Este es el modelo bsico utilizado en los inicios del desarrollo de software. Contiene dos pasos: Escribir cdigo. Corregir problemas en el cdigo.
Se trata de primero implementar algo de cdigo y luego pensar acerca de requisitos, diseo, validacin, y mantenimiento. Este modelo tiene tres problemas principales: Despus de un nmero de correcciones, el cdigo puede tener una muy mala estructura, hace que los arreglos sean muy costosos. Frecuentemente, an el software bien diseado, no se ajusta a las necesidades del usuario, por lo que es rechazado o su reconstruccin es muy cara. El cdigo es difcil de reparar por su pobre preparacin 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 ingeniera. ste toma las actividades fundamentales del proceso de especificacin, desarrollo, validacin y evolucin y las representa como fases separadas del proceso.
CIBERTEC
38
El modelo en cascada consta de las siguientes fases: 1. Definicin de los requisitos: Los servicios, restricciones y objetivos son establecidos con los usuarios del sistema. Se busca hacer esta definicin en detalle. 2. Diseo 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. Implementacin y pruebas unitarias: Construccin de los mdulos y unidades de software. Se realizan pruebas de cada unidad. 4. Integracin y pruebas del sistema: Se integran todas las unidades. Se prueban en conjunto. Se entrega el conjunto probado al cliente. 5. Operacin y mantenimiento: Generalmente es la fase ms larga. El sistema es puesto en marcha y se realiza la correccin de errores descubiertos. Se realizan mejoras de implementacin. Se identifican nuevos requisitos. La interaccin 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 correccin de los problemas encontrados en fases previas.
Figura 4.1 - Modelo de Desarrollo en Cascada
En la prctica, este modelo no es lineal, e involucra varias iteraciones e interaccin 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 produccin y aprobacin de documentos. Aunque son pocas iteraciones, es normal congelar parte del desarrollo y continuar con las siguientes fases.
CIBERTEC
CALIDAD DE SOFTWARE
39
Los problemas se dejan para su posterior resolucin, 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 difcil responder a cambios en los requisitos.
Este modelo slo debe usarse si se entienden a plenitud los requisitos. An se utiliza como parte de proyectos grandes.
1.4.3.
Desarrollo Evolutivo
La idea detrs de este modelo es el desarrollo de una implantacin 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 cmo las actividades concurrentes: especificacin, desarrollo y validacin, se realizan durante el desarrollo de las versiones hasta llegar al producto final. Una ventaja de este modelo es que se obtiene una rpida retroalimentacin del usuario, ya que las actividades de especificacin, desarrollo y pruebas se ejecutan en cada iteracin.
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 ms claras. El sistema evoluciona conforme se aaden nuevas caractersticas propuestas por el usuario.
CIBERTEC
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 estn 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 estn: La especificacin 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 ms efectivo que el modelo de cascada, ya que cumple con las necesidades inmediatas del cliente.
Desde una perspectiva de ingeniera y administracin se identifican los siguientes problemas: Proceso no Visible: Los administradores necesitan entregas para medir el progreso. Si el sistema se necesita desarrollar rpido, no es efectivo producir documentos que reflejen cada versin del sistema. Sistemas pobremente estructurados: Los cambios continuos pueden ser perjudiciales para la estructura del software haciendo costoso el mantenimiento. Se requieren tcnicas y herramientas: Para el rpido desarrollo se necesitan herramientas que pueden ser incompatibles con otras o que poca gente sabe utilizar.
Este modelo es efectivo en proyectos pequeos (menos de 100.000 lneas de cdigo) o medianos (hasta 500.000 lneas de cdigo) con poco tiempo para su desarrollo y sin generar documentacin para cada versin. 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 ms 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.
CIBERTEC
CALIDAD DE SOFTWARE
41
Figura 4.3 - Paradigma de Programacin Automtica
La Figura 4.3 ilustra un paradigma ideal de programacin automtica. Se distinguen dos fases globales: especificacin (incluyendo validacin) y transformacin. Las caractersticas principales de este paradigma son: La especificacin es formal y ejecutable constituye el primer prototipo del sistema). La especificacin es validada mediante prototipado. Posteriormente, a travs de transformaciones formales especificacin se convierte en la implementacin del sistema. la
En el ltimo paso de transformacin se obtiene una implementacin en un lenguaje de programacin determinado. El mantenimiento se realiza sobre la especificacin (no sobre el cdigo fuente), la documentacin es generada automticamente y el mantenimiento es realizado por repeticin del proceso (no mediante parches sobre la implementacin).
Observaciones sobre el desarrollo formal de sistemas: Permite demostrar la correccin del sistema durante el proceso de transformacin. As, las pruebas que verifican la correspondencia con la especificacin 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 Reutilizacin

Como su nombre lo indica, es un modelo fuertemente orientado a la reutilizacin. Este modelo consta de 4 fases ilustradas en la Figura 4.4.
CIBERTEC
42
A continuacin se describe cada fase: 1. Anlisis de componentes: Se determina qu componentes pueden ser utilizados para el sistema en cuestin. Casi siempre hay que hacer ajustes para adecuarlos. 2. Modificacin 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 ms adecuados (fase 1). 3. Diseo del sistema con reutilizacin: Se disea o reutiliza el marco de trabajo para el sistema. Se debe tener en cuenta los componentes localizados en la fase 2 para disear o determinar este marco. 4. Desarrollo e integracin: El software que no puede comprarse, se desarrolla. Se integran los componentes y subsistemas. La integracin 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 Reutilizacin 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 estn en manos de los desarrolladores del sistema.
CIBERTEC
CALIDAD DE SOFTWARE
43
1.4.6.
Procesos Iterativos
A continuacin se expondrn dos enfoques hbridos, especialmente diseados para el soporte de las iteraciones: Desarrollo Incremental. Desarrollo en Espiral. Desarrollo Incremental Mills sugiri el enfoque incremental de desarrollo como una forma de reducir la repeticin 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 combinacin 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.
1.4.6.1.
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 ms importantes del sistema son entregadas primero, por lo cual se realizan ms pruebas en estos mdulos y se disminuye el riesgo de fallos.
CIBERTEC
44
Algunas de las desventajas identificadas para este modelo son: Cada incremento debe ser pequeo para limitar el riesgo (menos de 20.000 lneas). Cada incremento debe aumentar la funcionalidad. Es difcil establecer las correspondencias requisitos contra los incrementos. de los
Es difcil detectar las unidades o servicios genricos 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 ms 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. Definicin de objetivos: Se definen los objetivos. Se definen las restricciones del proceso y del producto. Se realiza un diseo detallado del plan administrativo. Se identifican los riesgos y se elaboran estrategias alternativas dependiendo de estos. 2. Evaluacin y reduccin de riesgos: Se realiza un anlisis 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 validacin: Se escoge el modelo de desarrollo despus de la evaluacin del riesgo. El modelo que se utilizar (cascada, sistemas formales, evolutivo, etc.) depende del riesgo identificado para esa fase.
4. Planificacin: Se determina si continuar con otro ciclo. Se planea la siguiente fase del proyecto. Este modelo a diferencia de los otros toma en consideracin explcitamente el riesgo, esta es una actividad importante en la administracin del proyecto. El ciclo de vida inicia con la definicin de los objetivos. De acuerdo a las restricciones se determinan distintas alternativas. Se identifican los riesgos al sopesar los objetivos contra las alternativas. Se evalan los riesgos con actividades como anlisis detallado, simulacin, prototipos, etc. Se desarrolla un poco el sistema. Se planifica la siguiente fase.
CIBERTEC
CALIDAD DE SOFTWARE
45
Figura 4.6 - Modelo de Desarrollo en Espiral
1.4.7.
Cul es el modelo de proceso ms adecuado?

Cada proyecto de software requiere de una forma de particular de abordar el problema. Las propuestas comerciales y acadmicas actuales promueven procesos iterativos, donde en cada iteracin puede utilizarse uno u otro modelo de proceso, considerando un conjunto de criterios (Por ejemplo: grado de definicin de requisitos, tamao del proyecto, riesgos identificados, entre otros). En la Tabla 2 se expone un cuadro comparativo de acuerdo con algunos criterios bsicos para la seleccin 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 estn predefinidos):
CIBERTEC
46
Funciona con requisitos y Modelo de Proceso arquitectura no predefinidos Codificar y Corregir Cascada Evolutivo exploratorio Evolutivo prototipado Desarrollo formal de sistemas Desarrollo orientado a la reutilizacin Incremental Espiral Bajo Bajo Medio o Alto Alto Bajo Medio
Produce software altamente fiable Bajo Alto Alto Medio Alto Bajo a Alto
Gestin de riesgos Bajo Bajo Bajo Medio Bajo a Medio Bajo a Medio
Visin del Permite progreso por el correcciones Cliente y el Jefe sobre la marcha de Proyecto Alto Bajo Bajo Alto Bajo Alto Medio Bajo Bajo Alto Bajo Alto
Bajo Alto
Alto Alto
Medio Alto
Bajo Medio
Bajo Medio
Tabla 2 Comparacin entre modelos de proceso de software
CIBERTEC
CALIDAD DE SOFTWARE
47
1.5. VERIFICACIN Y VALIDACIN DE SOFTWARE

Los procesos de verificacin y validacin determinan si un producto software satisface las necesidades del negocio y si se est construyendo acorde a las especificaciones. Segn el SWEBOK 2004, existen dos grupos de tcnicas para la comprobacin de software: 1. Tcnica Esttica: Tcnica para evaluacin del software que no requiere la ejecucin del mismo. 2. Tcnica Dinmica: Tcnica para evaluacin del software que s requiere la ejecucin del mismo.
Figura 5.1 Revisiones y Pruebas
En la Figura 5.1 se puede apreciar que cuando se aplica la tcnica dinmica, normalmente se usan pruebas; y cuando se aplica tcnica esttica se utilizan revisiones.
1.5.1.
Verificacin
Segn la ISO-IEC 12207, la Verificacin 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 verificacin permite comprobar que el artefacto producido en un proceso corresponde con el que se utiliz a la entrada del proceso. La verificacin permite responder la pregunta: Estamos construyendo el producto en forma correcta? La verificacin se orienta al proceso.
CIBERTEC
48
1.5.2.
Validacin
Segn la ISO-IEC 12207, la Validacin es el proceso para determinar si los requerimientos y el sistema o producto software, tal como se ha construido, cumple con su uso especfico previsto. La validacin se puede llevar a cabo en etapas tempranas. La validacin permite comprobar si el artefacto producido es lo que el usuario necesita. La validacin permite responder la pregunta: Estamos construyendo el producto correcto? La validacin se orienta al producto.
Las actividades de verificacin y validacin deben desarrollarse a lo largo de todo el ciclo de vida de software (ver Figura 5.2).
Figura 5.2 Verificacin y Validacin
1.5.3.
Ventajas de las Revisiones de Software

No requiere de cdigo 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 posicin exacta del defecto. Refuerza el uso de estndares. Mejora la capacitacin.
1.5.4.
Desventajas de las Revisiones de Software

Requiere del tiempo de expertos. No se puede verificar caractersticas no-funcionales (ejemplo rendimiento). Validan cumplimiento de lo que se especific, en vez de lo que realmente desea el cliente. Difcil de implementar (es vista como improductiva por los desarrolladores).
CIBERTEC
CALIDAD DE SOFTWARE
49
1.5.5.
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 mtodos para encontrar defectos. Reporte del resultado. Recoleccin de datos para el control del proceso.
Figura 5.3 Tipos de Revisiones de Software
CIBERTEC
50
Actividades
Los alumnos debern presentar los documentos de Reportes de Especificacin de Software del proyecto integrado, manual de usuario y Reporte de Diseo de Software utilizando los formatos adjuntos. Los alumnos debern elaborar un plan de verificacin y de validacin de los entregables que se desarrollarn como parte del proyecto integrado de quinto ciclo. Los alumnos debern elaborar las listas de verificacin del RES las que aplicarn en juego de roles como parte del ciclo de proyecto integrado. Los alumnos harn el seguimiento de levantamiento de las observaciones en una segunda revisin de pares del RES.
CIBERTEC
CALIDAD DE SOFTWARE
51
Formatos
1. RES Reporte de Especificacin de Software
Reporte de Especificacin de Software (RES)

Versin <x.y.z>
[Nombre del proyecto]
[Este documento es la plantilla base para elaborar el documento Reporte de Especificacin de Software. Los textos que aparecen entre parntesis rectos son explicaciones de que debe contener cada seccin. 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 seccin, La solucin que se est implementando no tiene impacto en esta seccin, No aplican para el proyecto (No borrar secciones del documento)]
CIBERTEC
52
HISTORIAL DE REVISIONES
Versin
Autor
Descripcin
Fecha de Elaboracin
Fecha de Revisin
<x.y.z>
<Persona que elabora <Detalles> el documento>
<Fecha de <Fecha de Elaboracin> Revisin>
Revisado por <Persona(s) que revisa(n) el documento>
CIBERTEC
CALIDAD DE SOFTWARE
53
Contenido
1. 2. 3.
3.1. 3.2. 3.3. 3.4.
Antecedentes ..................................................................................... 54 Objetivos ............................................................................................. 54 Alcance ................................................................................................. 54

DENTRO DEL ALCANCE .......................................................................................................... 54 FUERA DEL ALCANCE ............................................................................................................. 54 RESTRICCIONES..................................................................................................................... 54 SUPUESTOS ............................................................................................................................ 55
4.
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. ESPECIFICACIN DE LOS CASOS DE USO DEL NEGOCIO ............................................... 55 CUN01 NOMBRE DEL CASO DE USO DEL NEGOCIO ...................................................................... 55 4.2. REALIZACIN DE LOS CASOS DE USO DE NEGOCIO .......................................................... 56 4.3. LISTA DE TRABAJADORES DE NEGOCIO............................................................................... 56 4.4. REGLAS DE NEGOCIO ............................................................................................................ 56
5. 6. 7.
7.1. 7.2. 7.3. 7.4. 7.5. 7.6. 7.7. 7.8.
Requisitos Funcionales .................................................................. 57 Requisitos No Funcionales............................................................ 57 Modelo de Casos de Uso del Sistema........................................ 60
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 PRIORIZACIN DE LOS CASOS DE USO DEL SISTEMA ....................................................... 61 MATRIZ DE MODELO DE NEGOCIO Y MODELO DE SISTEMA .............................................. 62 ESPECIFICACIN DE LOS CASOS DE USO DEL SISTEMA .................................................... 62
CUS01 Nombre del caso de Uso ..................................................................................................... 63
8. 9. 10. 11.
Flujo General de Navegacin ....................................................... 64 Esquema de Seguridad .................................................................. 64 Modelo de Anlisis ........................................................................ 65 Modelo Conceptual ....................................................................... 66
CIBERTEC
54
1.
Antecedentes
[Describa la situacin actual y las necesidades o problemas que se pretende atender. Recuerde que debe tomar como informacin 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 tambin el documento de planificacin del proyecto (PP)
2.
Objetivos [Referidos a los objetivos del negocio alineados al producto software. Es la explicacin resumida de los resultados que el negocio quiere lograr con el sistema, estos pueden ser la solucin de alguno o varios problemas, la generacin de nuevas oportunidades de negocio, alguna mejora que los usuarios o clientes necesitan o mejorar la informacin para la toma de decisiones directivas o ejecutivas. Recuerde que puede tomar como informacin 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 tambin el documento de planificacin de proyecto (PP).]
3.
Alcance
3.1. Dentro del Alcance [En esta seccin deber incluir el alcance funcional del producto software, dicho alcance se encuentra tambin definido en el documento de Planificacin de Proyecto (PP). Es posible detallar el alcance siempre y cuando no vare en cuanto al original definido en el PP. Nota: Para los cursos de ADSI y ADSII se define despus de haber sido obtenida la Matriz de Actividades Vs. Requisitos.]
3.2.
Fuera del Alcance [En esta seccin 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 vare en cuanto al original definido en el PP. Nota: Para los cursos de ADSI y ADSII se define despus de haber sido obtenida la Matriz de Actividades Vs. Requisitos.]
3.3.
Restricciones [En esta seccin deber incluir las restricciones de la solucin propuesta relacionados al software, hardware y a la funcionalidad as como lo referido a los lmites 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 seccin de restricciones del documento de planificacin de proyecto (PP).
CIBERTEC
CALIDAD DE SOFTWARE
55
3.4.
Supuestos [En esta seccin deber incluir los principales supuestos relacionados con la implementacin del sistema y lo referido a lo que la empresa contratante posee a nivel de tecnologas de informacin.] Nota: Para el caso de los cursos de quinto y sexto ciclo puede tomar como referencia la seccin de supuestos del documento de planificacin de proyecto (PP).
4.
Procesos de Negocio
4.1. Lista de Casos de Uso de Negocio [En esta seccin deber listar los casos de uso de negocio que se obtuvieron a partir de los procesos de negocio identificados dentro del mbito de la solucin y a los cuales se les dar el soporte con el producto software. Cada Caso de Uso de Negocio deber ser identificado con un cdigo 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]
Descripcin
[Descripcin del flujo de trabajo del CUN01.] [Descripcin del flujo de trabajo del CUN02.]
4.1.1. Lista de Actores del Negocio [En esta seccin deber listar a los actores de negocio incluyendo una descripcin por cada uno.]
Actor del Negocio
Descripcin
4.1.2. Diagrama General de Caso del Negocio [En esta seccin deber graficar el Diagrama general de Casos de uso del Negocio.] 4.1.3. Especificacin 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 continuacin se detalla: CUN01 Nombre del Caso de Uso del Negocio 1. Breve Descripcin
Reutilizar el resumen del punto 4.1

2. Objetivo
Referido al negocio y alineado al producto software.
CIBERTEC
56
3.
Flujo de Trabajo 3.1 Flujo Bsico
1. Indicar el flujo bsico del CUN

3.2 Flujos Alternativos
1. Detalle del flujo alterno.

4. Categora
Se coloca si es bsica, estratgica o de apoyo.

5. Gestor del proceso
Se identifica a la persona que est interesada en el xito o fracaso del proceso.

4.2. Realizacin de los Casos de Uso de Negocio [En esta seccin deber desarrollar los diagramas de actividades y diagrama de clases de negocio por cada Caso de Uso de Negocio identificado en la seccin 4.1. Por cada juego de diagramas deber identificar cules sern las actividades que sern automatizadas.] 4.3. Lista de Trabajadores de Negocio [En esta seccin deber listar a los trabajadores de negocio incluyendo una descripcin por cada uno.]
Trabajador del Negocio
Descripcin
4.4.
Reglas de Negocio [En esta seccin deber identificar las reglas que regulan la estructura del negocio y cmo ellos operan afectando el funcionamiento de los procesos de negocio. Dichas reglas de negocio son las que se considerarn para el diseo del sistema. Cada Regla de Negocio deber ser identificada con un cdigo nico y correlativo. Ejemplo: RN01. Para identificar las reglas de negocio puede considerar la siguiente clasificacin: Reglas de Estructura: Ejemplo (Todo pedido debe ser realizado por un cliente, y que el mismo debe estar dado de alta. Adems una vez que el cliente haya hecho algn pedido, se deber garantizar que no es posible eliminarlo, al menos que previamente se eliminen todos sus pedidos) Reglas de Derivacin: Ejemplo (El total de un pedido se puede calcular a partir de distintas lneas que lo componen, mientras que el total de cada lnea se puede calcular a partir del nmero de unidades vendidas y el precio por unidad) Reglas de Interfaz o de Modelo de Datos: Ejemplo (No hay precio de artculos negativos, el sexo de una persona slo puede ser masculino o
CIBERTEC
CALIDAD DE SOFTWARE
57
femenino, una fecha tiene que ser siempre una fecha vlida - no existe 30 de febrero) Reglas de Operacin o Reglas de Flujo: Ejemplo (Un cliente puede hacer una peticin de anlisis al laboratorio que anota un encargado: hecho esto, se genera un parte para uno o ms analistas, estos realizan las mediciones correspondientes y devuelven los partes con la informacin pertinente, a partir de la cual se genera un informe de anlisis, que ser un anlisis vlido solo cuando sea firmado por los responsables de garantizar su correccin)
Cdigo
RN-001 RN-002
Descripcin [Descripcin de la Regla 001] [Descripcin de la Regla 002]
RN-00n
5.
Requisitos Funcionales
[De acuerdo a lo solicitado explcitamente por el rea usuaria, listar todos los requisitos funcionales del producto software. Considere que los requisitos funcionales que liste debern ser asociados posteriormente a los casos de uso (funciones de software). Cada Requisito Funcional deber ser identificado con un cdigo nico y correlativo. Ejemplo: RF01. Nota: Esta lista proviene de la Matriz de Actividades Vs. Requisitos. Y de la Matriz de Requisitos Funcionales Adicionales.]
Cdigo [Cdigo del requisito funcional] RF-001 RF-002 ... RF-00n
Descripcin [Descripcin detallada del requisito funcional.] [Descripcin detallada del requisito funcional 1.] [Descripcin detallada del requisito funcional 2.] .... [Descripcin detallada del requisito funcional n.]
Proceso de Negocio [Identificador del proceso de negocio asociado] [CUN01]
6.
Requisitos No Funcionales
[Listar los requisitos no funcionales los mismos que debern ser considerados para el modelo de calidad de producto. Cada Requisito No Funcional deber ser identificado con un cdigo nico y correlativo. Ejemplo: RNF01.]
Tipo de Requisito [Nombre del tipo de requisito no funcional]
Cdigo [Cdigo del requisito no funcional]
Descripcin [Descripcin detallada del requisito no
Implementacin [Describir como se implementar el RNF-00n]
CIBERTEC
58
Tipo de Requisito
Restricciones Diseo del
Cdigo
Descripcin funcional.]
Implementacin
[Definir cualquier tipo de restriccin de diseo, tales como: proceso de desarrollo de software, sistemas operativos, RNF-001 lenguajes de programacin, administrador de base de datos, conexin a la BD, generador de reportes, manejo de informacin, etc.]
[Descripcin detallada del requisito no funcional 1.]
RNF-002
Componentes Adquirir
[Identificar los componentes que se deben adquirir o tener en cuenta, para llevar acabo RNF-003 el desarrollo y ejecucin del sistema. Ejemplo: lenguajes de programacin, servidores, estaciones de trabajo, etc.]
RNF-004
Interfaces de Usuario [Describir las interfaces de usuario que sern implementados en el software. Esto incluye RNF-005 por ejemplo: formatos de la pantalla, pgina o esquemas de las ventanas, reportes, mens, etc.]
RNF-006
CIBERTEC
CALIDAD DE SOFTWARE
59
Tipo de Requisito
Interfaces Hardware de
Cdigo
Descripcin
Implementacin
[Definir cualquier interfase de hardware RNF-007 que ser soportado por el software, incluyendo estructura lgica, direcciones fsicas, etc.]
RNF-008
Interfaces Software
de [Descripcin detallada del requisito no funcional 9.]
[Especificar el uso de otros productos software RNF-009 requeridos e interfaces con otros sistemas de la aplicacin.]
RNF-010
Interfaces Comunicaciones
[Describir las interfaces de comunicacin para otros sistemas RNF-011 dispositivos, tales como: redes de rea local, dispositivos de serie remota.]
RNF-012
[Descripcin detallada del requisito no funcional 12.] [Descripcin detallada del requisito no funcional 13.] [Descripcin detallada del requisito no funcional 14.] [Descripcin detallada del requisito no funcional 15.]
Requerimientos Licenciamiento
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
60
Tipo de Requisito
Cdigo
RNF-016
Descripcin
[Descripcin detallada del requisito no funcional 16.] [Descripcin detallada del requisito no funcional 17.] [Descripcin detallada del requisito no funcional 18.]
Implementacin
Estndares aplicables [Especificar estndares sistema.] con qu RNF-017 trabaja el
RNF-018
Requisitos del Sistema [Especificar los requerimientos de plataforma tecnolgica RNF-019 necesarios para el diseo y el desarrollo del sistema.] [Descripcin detallada del requisito no funcional 19.]
RNF-020
Requisitos Desempeo
[Listar y especificar los requisitos de desempeo con los que debe trabajar RNF-021 el sistema. Ejemplo: Tiempo de respuesta en alguna consulta del sistema.]
RNF-022
7.
Modelo de Casos de Uso del Sistema

[En esta seccin 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 relacin de casos de uso por cada paquete. Cada Caso de Uso deber ser identificado con un cdigo nico y correlativo. Ejemplo: CUS01.] 7.1. Lista de Actores de Sistema [Listar a los actores de sistema.]
CIBERTEC
CALIDAD DE SOFTWARE
61
Actor del sistema
Descripcin
7.2.
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 cdigo nico y correlativo. Ejemplo: P01.]
7.4.
Lista de Casos de Uso del Sistema por Paquete [En esta seccin deber listar todos los casos de uso del sistema que se han identificado. Para hacerlo deber tomar como referencia la organizacin del sistema de acuerdo al diagrama de paquetes del punto 7.3.]
Paquete: P01 Nombre del Paquete Caso de uso del sistema Descripcin
CUS01 [Nombre del Caso [Descripcin del caso de uso. En la de Uso] descripcin deber indicar las acciones que permitir el caso de uso.] CUS02 [Nombre del Caso [Descripcin del caso de uso. En la de Uso] descripcin 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. Priorizacin de los Casos de Uso del Sistema
7.6.1. Clasificacin de los Casos de Uso del Sistema

[En esta seccin deber clasificar los casos de uso de sistema indicando si son primarios o secundarios.]
0,4 CASO DE USO CUS01XXXXXX CUS02XXXXXX CUS03XXXXXX
0,3
0,2
RIESGO
0,1
IMPACTO RNF
IMPORTANCIA COMPLEJIDAD
TOTAL
CLASIFICACIN DE CU Primario Secundario Secundario
CIBERTEC
62
7.6.2. Ciclos de Desarrollo de los Casos de Uso del Sistema

[En esta seccin deber indicar en qu ciclo de desarrollo se trabajarn cada uno de los casos de uso del sistema.]
Ciclo de desarrollo
Ncleo central o Ciclo 0 Ciclo 1
Nombre del caso de uso

CUS01 Nombre del caso de uso CUS02 Nombre del caso de uso CUS03 Nombre del caso de uso
Clasificacin Primario Secundario Secundario
7.7.
Matriz de Modelo de Negocio y Modelo de Sistema [En esta seccin 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

CUN01 Caso de Uso de Negocio 1
Actividad a automatizar
Requerimiento funcional
RF001 Requisito Funcional
Caso de uso del sistema N Nombre Actor

Actor CUS01 Casos de Uso de Sistema
Nombre N Nombre
Actividad a ser automatizada Actividad a ser automatizada Actividad a ser automatizada
Responsable N Nombre
Trabajador de Negocio Trabajador de Negocio Trabajador de Negocio
7.8.
Especificacin de los Casos de Uso del Sistema
7.8.1. Especificacin de Alto Nivel

[En esta seccin deber incluir la especificacin de alto nivel de los casos de uso del sistema. Asimismo deber indicar que requisitos funcionales estn asociados a cada caso de uso, tomando como referencia lo indicado en la matriz del punto 7.7.]
Caso de uso:
Actor(es): Propsito: Caso de asociado: Resumen:
CUS01 Nombre del Caso de Uso

Nombre del actor Indicar el propsito del caso de uso
uso Indicar si existe algn caso de uso asociado. De no haber indicar No Aplica. Describir brevemente el caso de uso. Para ello deber indicar como empieza el caso de uso, que actividades desarrolla y como termina. Indicar la clasificacin del caso de uso Indicar el(los) asociados. cdigos de requisitos funcionales
Clasificacin Requisitos
CIBERTEC
CALIDAD DE SOFTWARE
63
7.8.2. Especificacin Expandida

[Por cada caso de uso de sistema especificado deber incluir la especificacin expandida de casos de uso. Para ello deber indicar el flujo bsico y los flujos alternos e incorporar el prototipo con la inclusin de los controles. Deber usar la plantilla que a continuacin se detalla: CUS01 Nombre del caso de Uso 1. Actores
Indicar la lista de actores

2. Propsito
Indicar el propsito
3. Breve Descripcin
Reutilizar el resumen del punto 7.4

4. Flujo Bsico de Eventos
Indicar el flujo bsico de eventos Es posible hacer referencia a las reglas de negocio.
5. Sub Flujos
Indicar los subflujos del flujo bsico.

6. Flujos Alternos 6.1. Nombre del flujo alterno
1. Detalle del Flujo alterno Se pueden incluir reglas de negocio.

7. Precondiciones
Descripcin de la precondicin
8. Pos condiciones
Descripcin de la pos condicin

9. Puntos de Extensin
Indicar si existen puntos de extensin.

10. Requerimientos Especiales
Indicar si existen requerimientos especiales.

11. Prototipos
Incluir los prototipos asociados al caso de uso.
CIBERTEC
64
8.
Flujo General de Navegacin

[Incluir un rbol de navegacin que permita entender el flujo que se seguir en la navegacin por el aplicativo. El siguiente ejemplo muestra un rbol de navegacin: Aplicacin/mdulo/opcin/subopcin]
Ver Agenda
Encargar Accin
Agenda
Ver Acciones
Ver Alarmas
Accin Propia
APLICACION
Clientes
Consultar Parmetros
Tablas
Resultados
Razones Mantenimiento Matriz CAP Relaciones Matriz GAF
Acciones Enviadas
Avances Reportes Resultados Histricos 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 informacin. Para ello se utiliza una matriz de perfiles de usuario y accesos por Aplicativo/Mdulo/Funcin.]
CIBERTEC
CALIDAD DE SOFTWARE
65
Funciones por Mdulo Mdulo A Consulta de informacin de empresas Consulta de operadores autorizados Modificacin de operadores autorizados Mdulo B Modificacin de cuentas afiliadas Modificacin de combinaciones autorizadas
Aplicativo Perfil 1 Perfil 2 x x
... X
Perfil N x
x x
x x
X X
x x
x x
x x
X X
x x
10. Modelo de Anlisis 10.1. Realizacin de Casos de Uso Anlisis

[Esta seccin ilustra cmo el software trabaja a partir de los casos de uso o escenarios seleccionados, y explica cmo varios elementos del modelo de anlisis contribuyen con ellos funcionalmente. Por cada caso de uso deber desarrollar un diagrama de secuencia y de clases de anlisis. Para ello deber usar el patrn MVC. Para la realizacin deber identificar los escenarios. Dichos escenarios se obtienen de las combinaciones entre el flujo principal y flujos alternativos del la especificacin expandida de casos de uso (ver punto 7.8.2).]
Cdigo del CUS Nombre del CUS Nombre del Escenario

[Identifica el escenario a ser realizado y una breve descripcin. Se recomienda identificar con un cdigo nico a cada escenario. Por ejemplo ESC01]
Diagrama de Secuencia de Anlisis

[Incluya el diagrama de secuencia de anlisis en el cual se observe el uso del patrn MVC que implementa el escenario identificado.]
Diagrama de Clases de Anlisis

[Incluya el diagrama de clases de anlisis obtenido del conjunto de diagramas de secuencia que se implementan por cada escenario.]
CIBERTEC
66
11. Modelo Conceptual

[Esta seccin ilustra cmo 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.]
CIBERTEC
CALIDAD DE SOFTWARE
67
2.
MU Manual de Usuario
Manual de Usuario (MU)

Versin <x.y.z>
[Nombre del sistema]
[Este documento es la plantilla base para elaborar el Manual de Usuario. Los textos que aparecen entre parntesis rectos son explicaciones de que debe contener cada seccin. 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 seccin, La solucin que se est implementando no tiene impacto en esta seccin, No aplican para el sistema (No borrar secciones del documento)]
CIBERTEC
68
Versin
Autor
Descripcin
Fecha de Elaboracin
Fecha de Revisin
<x.y.z>
<Persona que elabora <Detalles> el documento>
CIBERTEC
CALIDAD DE SOFTWARE
69
Contenido
1. 2. 3. 4. 5.
5.1.
Objetivo del Documento ................................................................ 70 Descripcin General del Sistema................................................ 70 Alcance del Sistema ........................................................................ 70 Ingreso al Sistema .......................................................................... 70 Funciones del Sistema ................................................................... 72
NOMBRE DE LA OPCIN ........................................................................................................ 72
CIBERTEC
70
12. Objetivo del Documento [Describa el objetivo del documento.]

El Manual del Usuario del Sistema de Mantenimiento Correctivo de Equipos, brinda las pautas bsicas para el fcil acceso a la informacin que este sistema ofrece, es decir, muestra las principales funcionalidades del sistema, as como la descripcin grfica de cmo navegar dentro del mismo
13. Descripcin 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 generacin del Registro de Incidentes para la atencin correctiva solicitada por los usuarios va telefnica o personalmente. Asimismo, se podr realizar un control de las atenciones realizadas, de las horas hombres invertidos y los materiales e insumos utilizados. Adems, este sistema permitir automatizar los paquetes de servicios con lo que se mejora el control de activos. Siendo una de las necesidades bsicas de la empresa el conocer la localizacin de las mquinas atendidas, as como las mquinas con las que podra 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 funcin y detallndola a nivel de usuario]
Funcionalidad requerida Nombre de la funcin que se implementa
Funcionalidad detallada Descripcin de la funcin implementada indicando las actividades que permite realizar Permite registrar la solicitud de reparacin de maquinaria con los datos del cliente y las mquinas a reparar
Registrar incidentes
15. Ingreso al Sistema [Detalle cmo se debe ingresar al sistema]

Ingrese al portal www.maskiner.com.pe, lo que lo llevar a la pgina de logueo Al ingresar al Sistema de Mantenimiento Correctivo de Equipos, primero pasar por la pantalla de Ingreso al Sistema.
CIBERTEC
CALIDAD DE SOFTWARE
71
Ingresar Usuario
Ingresar contrasea
Hacer clic en el botn para ingresar al

Se ingresar los datos solicitados, los cuales, al hacer clic en Ingresar, sern validados por el sistema para el acceso a la pantalla correspondiente al perfil del usuario logueado.
Las siguientes pantallas, mostrarn una barra de men que permite el acceso a las funcionalidades que se mencionan a continuacin:
Men Principal Registrar Incidentes Generar O/T de Inspeccin Generar O/T Registrar Inf.de Liquidacin Aprobar Prefactura Generar Factura. Mantener de Clientes Mantener Equipo Mantener Paquetes
CIBERTEC
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 opcin y luego incluir las pantallas necesarias que le permitan al usuario final entender el cmo se debe usar.]
16.1. Nombre de la Opcin

[Describa el funcionamiento de la opcin. Incorpore adems las pantallas que le permitan describir el funcionamiento. Utilice llamadas de ser el caso para clarificar la explicacin. Su explicacin debe ser clara orientada a usuarios finales]
REGISTRAR INCIDENTES Al ingresar al sistema, el usuario seleccionar la opcin de men Registrar Incidentes que lo llevar a la opcin Nuevo Registro de Incidentes.
En esta pantalla el sistema cargar los datos del Registrador (usuario logueado) as como la fecha del da. Aqu deber seguir los siguientes pasos:
CIBERTEC
CALIDAD DE SOFTWARE
73
Seleccionar la opcin Buscar
Se mostrar la opcin 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
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 opcin Buscar Maquinaria.
El sistema cargar las mquinas registradas para la sucursal seleccionada:
CIBERTEC
CALIDAD DE SOFTWARE
75
1.Seleccione la maquinaria.
1.Seleccionar la Naturaleza de la 2.Ingrese la descripcin de la
3.Hacer clic en El sistema cargar en la grilla los datos de la avera. Para ingresar nuevas mquinas deber repetir los mismos pasos y para eliminarla se deber:
CIBERTEC
76
1.Marcar la casilla de seleccin de la mquina que desea eliminar de la lista.
2.Hacer clic en la opcin Finalmente seleccionar la opcin GUARDAR y con ello se mostrar el mensaje de confirmacin.
CIBERTEC
CALIDAD DE SOFTWARE
77
DERECHOS DE USO La presente documentacin es propiedad de Maskiner S.A. y tiene carcter de confidencial y no podr ser objeto de reproduccin total o parcial, tratamiento informtico ni transmisin de ninguna forma o por cualquier medio, ya sea electrnico, mecnico, por fotocopia, registro o cualquiera otro. Asimismo tampoco podr ser objeto de prstamo, alquiler o cualquier forma de cesin de uso sin el permiso previo y escrito de Maskiner S.A., titular del copyright. El incumplimiento de las limitaciones sealadas por cualquier persona que tenga acceso a la documentacin ser perseguida conforme a ley.
Trminos 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 organizacin, o a cualquier otra empresa, sin una autorizacin 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 especficos para Maskiner S.A., as como ningn tema de negocios relacionado y que fuere mencionado en reuniones de trabajo previas.
CIBERTEC
78
3.
RDS Reporte de Diseo de Software
Reporte de Diseo de Software (RDS)

Versin <x.y.z>
[Este documento es la plantilla base para elaborar el documento Reporte de Diseo de Software. Los textos que aparecen entre parntesis rectos son explicaciones de que debe contener cada seccin. 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 seccin, La solucin que se est implementando no tiene impacto en esta seccin, No aplican para el proyecto (No borrar secciones del documento)]
CIBERTEC
CALIDAD DE SOFTWARE
79
Versin
Autor
Descripcin
Fecha de Elaboracin
Fecha de Revisin
<Persona que elabora <x.y.z> <Detalles> el documento>
CIBERTEC
80
Contenido
1.
1.1. 1.2. 1.3.
Introduccin ...................................................................................... 81
PROPSITO ............................................................................................................................ 81 ALCANCE ................................................................................................................................ 81 DEFINICIONES, ACRNIMOS Y ABREVIATURAS .................................................................. 81
1.3.1. 1.3.2. 1.3.3.

1.4.
Definiciones..................................................................................... 81 Acrnimos ........................................................................................ 81 Abreviaturas ................................................................................... 82
REFERENCIAS ......................................................................................................................... 82
2. 3. 4. 5.
5.1.
Vista General de la Arquitectura ................................................ 82 Metas y Restricciones de la Arquitectura ............................... 83 Vista de Casos de Uso .................................................................... 83 Vista Lgica ........................................................................................ 83
REALIZACIN DE CASOS DE USO MODELO DE ANLISIS .............................................. 84
5.1.1. 5.1.2.
5.2. 5.3. 5.4.
Cdigo del CUS Nombre del CUS .......................................... 84 Diagrama de Clases de Anlisis ............................................... 84
MODELO CONCEPTUAL .......................................................................................................... 84 MODELO LGICO ................................................................................................................... 84 MODELO DE DISEO ............................................................................................................. 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.
Vista de Capas y Subsistemas .................................................. 85

Capa Capa Capa Capa Capa Capa de de de de de de Presentacin ....................................................................................................... 86 Negocio ................................................................................................................. 86 Integracin .......................................................................................................... 86 Datos ..................................................................................................................... 86 Entidad.................................................................................................................. 87 Interfaces o Elementos Comunes ............................................................... 87
5.4.2.
5.4.2.1. 5.4.2.2.
Realizacin de Casos de Uso Modelo de Diseo ............. 87

Cdigo del CUS Nombre del CUS.............................................................................. 87 Diagrama de Clases de Diseo...................................................................................... 87
6. 7.
Vista de Despliegue ......................................................................... 88 Vista de Datos ................................................................................... 88
CIBERTEC
CALIDAD DE SOFTWARE
81
1.
Introduccin
[Describa de manera breve el contenido del documento orientando descripcin hacia la utilidad que la misma busca. Recuerde que para elaboracin del documento debe considerar lo desarrollado en el Reporte Especificacin de Software (RES) y que es posible que en esta seccin pueda complementar la informacin del documento base RES.] la la de se
1.1.
Propsito
[En esta seccin se debe proporcionar una visin general de la arquitectura del sistema haciendo referencia a las diferentes vistas que implementarn los diferentes aspectos.]
1.2.
Alcance
[Indicar cul es el alcance del documento. Considere que en el RES se ha desarrollado la Vista de Sistema (funcional) y que para completar la visin total es necesario incluir la vista de arquitectura, vista lgica, vista de implementacin, vista de despliegue y vista de datos. A menudo es necesario incluir una representacin de la arquitectura con consideraciones de infraestructura tecnolgica, relacin con otros sistemas y una vista de procesos en donde se describe la descomposicin del sistema en procesos y los mtodos de comunicacin del sistema.]
1.3.
Definiciones, Acrnimos y Abreviaturas

[Proporcione las definiciones, acrnimos utilizarn 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 definicin deber ir acompaada de una breve descripcin.]
Definicin Asistente de Gestin
Descripcin Trabajador encargado de procesar las rectificaciones de los ciudadanos que lo solicitan. Tambin coordina las entregas de hologramas.
1.3.2. Acrnimos
[Indique cada una de los acrnimos que son relevantes para el entendimiento del presente documento, para el entendimiento de la arquitectura propuesta y para el diseo detallado. Cada acrnimo deber ir acompaada de una breve descripcin.]
Acrnimo RUP
Descripcin Rational Unified Process
CIBERTEC
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 diseo detallado. Cada abreviatura deber ir acompaada de una breve descripcin.]
Acrnimo SIGA
Descripcin Sistema Integrado de Gestin Administrativa
1.4.
Referencias
[Mencione los documentos que sirven como entrada, o salida, y herramientas que se usarn para el desarrollo del presente documento.]
2.
Vista General de la Arquitectura

[En esta seccin describa la arquitectura de software para el sistema actual, y cmo este ser representado. De las vistas de casos de uso, lgica, procesos, despliegue e implementacin; se enumerarn las vistas necesarias, y por cada vista, se deber explicar qu tipo de elementos del modelo contienen.] Ejemplo:
A continuacin se muestra la Arquitectura del Sistema ABC, sta est dividida en tres capas: Capa de Presentacin Capa de Negocios Capa de Integracin As mismo la aplicacin por un criterio de funcionalidad se ha dividido en seis mdulos: Mdulo de Administracin del Negocio Mdulo de Empaquetamiento Mdulo de Mensajera Mdulo de Administracin de Datos Servicios Web X12 Componentes EDI
Web SGSS
Capa de Presentacin
Servicios Web X12 Mdulo de Administracin del Negocio Mdulo de Empaquetam.
Componentes EDI Mdulo de Mensajera
Capa de Aplicacin y Lgica de Negocio
Aplicativo Externo 1 Aplicativo Externo N
Mdulo de Administracin de Datos

Capa de Base de Datos
Base de Datos del Sistema
Base de Datos 1
Base de Datos 2
Base de Datos N
La figura anterior muestra la distribucin de los mdulos del software
CIBERTEC
CALIDAD DE SOFTWARE
83
que tendr el sistema, adems de brindar una visin general del sistema. En el grfico, se observa la distribucin en tres capas de la arquitectura, las cuales se describen a continuacin. Capa de presentacin En esta capa se encuentra la aplicacin Web dedicada a la administracin y configuracin DEL SISTEMA XYZ, la cual estar conformada por las pantallas de presentacin al usuario. Estas aplicaciones Web sern pginas ASP.NET. Capa de Lgica de Negocio Esta capa provee todo lo que es la lgica del negocio, es decir la funcionalidad del sistema, ya sean los procesos administrativos, y los procesos referidos a la elegibilidad, crdito hospitalario (cartas de garanta) y crdito ambulatorio (pedidos de reembolso). Adems, 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 lgica de Negocio. Por otro lado, el manejador de base de datos utilizado para este sistema ser Microsoft SQL Server 2000.
3.
Metas y Restricciones de la Arquitectura

[En sta seccin se describe describen los requerimientos de software y objetivos que tienen algn significativo impacto sobre la arquitectura; por ejemplo: seguridad, privacidad de uso del producto, portabilidad, distribucin y reuso. Esto tambin captura las restricciones especiales que quizs apliquen en la: Estrategia de diseo e implementacin, 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 excepcin de aquellas funcionales.]
4.
Vista de Casos de Uso

[En sta seccin 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 codificacin indicada en el RES para los paquetes y para los casos de uso. Si fuse necesario ampliar en esta seccin recuerde que es necesario se actualice el RES.]
5.
Vista Lgica
[La vista lgica est representada por los diagrama de clases del sistema donde se muestran sus relaciones estructurales y de herencia. La definicin de clase incluye definiciones para atributos y operaciones. El modelo de casos del punto 3 del presente documento uso aporta informacin para establecer las clases, objetos, atributos y operaciones.]
CIBERTEC
84
5.1.
Realizacin de Casos de Uso Modelo de Anlisis

[Esta seccin ilustra cmo el software trabaja a partir de los casos de uso o escenarios seleccionados, y explica cmo varios elementos del modelo de anlisis contribuyen con ellos funcionalmente. Por cada caso de uso deber desarrollar un diagrama de secuencia y de clases de anlisis. Para ello deber usar el patrn MVC. Para la realizacin deber identificar los escenarios. Dichos escenarios se obtienen de las combinaciones entre el flujo principal y flujos alternativos del la especificacin expandida de casos de uso (ver punto 7.8.2 del RES).]
5.1.1. Cdigo del CUS Nombre del CUS Nombre del Escenario
[Identifica el escenario a ser realizado y una breve descripcin. Se recomienda identificar con un cdigo nico a cada escenario. Por ejemplo ESC01]
Diagrama de Secuencia de Anlisis

[Incluya el diagrama de secuencia de anlisis en el cual se observe el uso del patrn MVC que implementa el escenario identificado.]
5.1.2. Diagrama de Clases de Anlisis

[Incluya el diagrama de clases de anlisis obtenido del conjunto de diagramas de secuencia que se implementan por cada escenario.]
5.2.
Modelo Conceptual
[Esta seccin ilustra cmo 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 Lgico
[El modelo lgico es el refinamiento del Modelo Conceptual. Aqu se reducen y/o aumentan clases y slo quedan aquellas que van a ser diseadas como tablas de la Base de Datos. El modelo lgico debe representarse con un diagrama de clases de acuerdo a la arquitectura propuesta. Tenga presente que para la transformacin del modelo conceptual al modelo lgico 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 agregarn en el modelo fsico) Incluir los atributos de las clases que se necesitan para satisfacer los requerimientos del sistema Documentar un registro de glosario de trminos
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 descripcin, atributos, tipo de dato, visibilidad y valor inicial] Nombre Tipo Descripcin Atributo Nombre atributo del Nombre de la Clase Tipo de Clase (Ejemplo Entidad) Descripcin de la clase identificando que representa Tipo de Dato Integer / String / Boolean Visibilidad Pblico Privado / Valor inicial
5.4.
Modelo de Diseo
[En esta seccin debe representar el refinamiento del modelo de anlisis 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 diseo. Para ello puede usar un patrn en el cual se usen capas y subsistemas. Adems deber identificar subsistemas requeridos por el uso de algn patrn de diseo como el DAO Factory, Singleton, Front Controller, entre otros. Por cada capa y subsistema deber identificar las clases de diseo que se implementarn]
CIBERTEC
86
<<layer>> Presentacion
<<layer>> Business
<<layer>> Integration
<<layer>> Interface <<layer>> Entidad <<layer>> Data
5.4.1.1.
Capa de Presentacin
[Identifique las clases de diseo de la capa de presentacin. Ordene dicha identificacin utilizando los paquetes al interior de las capas denominados subsistemas.]
5.4.1.2.
Capa de Negocio
[Identifique las clases de diseo de la capa de negocio. Ordene dicha identificacin utilizando los paquetes al interior de las capas denominados subsistemas.]
5.4.1.3.
Capa de Integracin
[Identifique las clases de diseo de la capa de integracin. Ordene dicha identificacin utilizando los paquetes al interior de las capas denominados subsistemas.]
5.4.1.4.
Capa de Datos
[Identifique las clases de diseo de la capa de datos. Ordene dicha identificacin utilizando los
CIBERTEC
CALIDAD DE SOFTWARE
87
paquetes al interior de las capas denominados subsistemas.]
5.4.1.5.
Capa de Entidad
[Identifique las clases de diseo de la capa de entidad. Ordene dicha identificacin utilizando los paquetes al interior de las capas denominados subsistemas.]
5.4.1.6.
Capa de Interfaces o Elementos Comunes

[Identifique las clases de diseo de la capa de elementos comunes. Ordene dicha identificacin utilizando los paquetes al interior de las capas denominados subsistemas.]
5.4.2. Realizacin de Casos de Uso Modelo de Diseo

[Esta seccin deber desarrollar los diagramas de secuencia y de clases de diseo 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.
Cdigo del CUS Nombre del CUS

[A partir de los casos de uso realizados del modelo de anlisis deber identificar los casos de uso que usar para las realizaciones de diseo.]
Nombre del Escenario

[Identifica el escenario a ser realizado y una breve descripcin. Se recomienda identificar con un cdigo nico a cada escenario. Por ejemplo ESC01. Deber reusar los escenarios identificados en el modelo de anlisis]
Diagrama de Secuencia de Diseo

[Incluya el diagrama de secuencia de diseo en el cual se observe el uso de patrones de diseo para las clases que implementarn cada una de las clases lgicas.]
5.4.2.2.
Diagrama de Clases de Diseo

[Incluya el diagrama de clases de diseo obtenido del conjunto de diagramas de secuencia que se implementan por cada escenario.]
CIBERTEC
88
6.
Vista de Despliegue
[En esta seccin se describen unas o ms configuraciones fsicas de la red (hardware) que se usarn para el despliegue de los componentes de software que forman parte de la solucin. Para ello puede usar un Diagrama de Despliegue indicando como mnimo, para cada configuracin, en qu nodos fsicos (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 fsicos. Adems deber especificar los detalles tcnicos 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
Sistema Operativo Windows 2003 Server COM+ (Component Services) Net Framewok 2.0
Sistema Operativo Windows 2003 Server SQL Server 2000
Servidor Intranet Inmuebles Adjudicados Presupuesto Archivo Excel
Servidor COM+
Servidor BD
Servidor BD Otros Sistemas
Sistema Operativo Windows 2003 Server SQL Server 2000 Sistemas: Spring (Macro) Contabilidad MC Adelantos (Macro) Provisiones (Macro) Inmuebles Propios
Internet Web Service Interface Spring PagoActivo HOST Mainframe IBM ZSeries Comprobantes Contabilidad
7.
Vista de Datos [Se debe describir la perspectiva persistente del almacenaje de datos del sistema. Deber incluir el Modelo de Base de Datos Lgico y Fsico, as como el diccionario de datos.]
CIBERTEC
CALIDAD DE SOFTWARE
89
Resumen
El desarrollo de sistemas hoy en da ha tomado gran importancia en el mundo siendo sta cada vez ms 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 programacin, inconsistencia en su funcionamiento, entre otros; pero lo ms importante es la falta de calidad, punto de gran inters 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 podra ser desechado como un producto defectuoso. Por esta razn 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 lneas de accin tendientes a mejorar el sistema producido. Dentro de estas lneas de accin est la relacionada con el proceso mismo del desarrollo del sistema, y como necesidad primordial, la de realizar una investigacin que permita conocer de primera mano el estado en que se encuentra su proceso de desarrollo. Si desea saber ms acerca de estos temas, puede consultar las siguientes pginas. 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 pequeas empresas.
CIBERTEC
90
CIBERTEC
CALIDAD DE SOFTWARE
91
MTRICAS DE SOFTWARE
Al trmino de la unidad de aprendizaje, el alumno elabora un catlogo de mtricas 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. Introduccin 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: Mtricas de Calidad de Producto Software 2.2.1. ISO/IEC 9126-1 Modelo de Calidad 2.2.2. ISO/IEC 9126-2 Mtricas Externas 2.2.3. ISO/IEC 9126-3 Mtricas Internas 2.2.4. Relacin Entre las Mtricas Internas y Externas 2.2.5. ISO/IEC 9126-4 Mtricas para Calidad en Uso 2.2.6. ISO/IEC 25000:2005 - SQuaRE 2.3. Tema 8: Evaluacin de Mtricas 2.3.1. Definiciones 2.3.2. Proceso de Evaluacin
CIBERTEC
92
2.1. MODELOS DE CALIDAD DE SOFTWARE

2.1.1. Introduccin
Los Modelos de Calidad son aquellos documentos que integran la mayor parte de las mejores prcticas, proponen temas de administracin en los que cada organizacin debe hacer nfasis, integran diferentes prcticas dirigidas a los procesos clave y permiten medir los avances en calidad. Los Estndares de Calidad son aquellos que permiten definir un conjunto de criterios de desarrollo que guan la forma en que se aplica la Ingeniera del Software. Los estndares suministran los medios para que todos los procesos se realicen de la misma forma y son una gua para lograr la productividad y la calidad. Los Modelos y/o Estndares permiten que las Empresas de Software realicen sus tareas y funciones teniendo en cuenta la Calidad. Cualquier organizacin que se dedica a la investigacin, produccin y comercializacin de software debe considerar la calidad, hoy con ms razn, donde existe un mercado en el cual el cliente es cada vez ms exigente, no slo 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 desempea un rol determinante para la competitividad de la empresa. Cuando una empresa est funcionando y decide implantar un Modelo / Estndar de Calidad del Software, es seal que la empresa tiene el propsito de hacerse cada vez ms profesional homogenizando los criterios sobre los cuales se debe producir los productos y los servicios de software, que brindarn satisfaccin a sus clientes y por lo tanto velarn 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 seran:
La calidad desde el punto de vista del producto: que tiene en cuenta las caractersticas 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 formacin, experiencia, etc. de las personas involucradas en los procesos para obtener el producto software.
CIBERTEC
CALIDAD DE SOFTWARE
93
2.1.3.
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 slo al sistema en s mismo, sino tambin 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 llevarn 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 ms se invierta en calidad del proceso mayores sern los costos pero tambin es cierto que mayores sern los beneficios obtenidos en la fase de mantenimiento del software. La calidad del software, por lo tanto, no se disea 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 comn para la definicin de distintas etapas de revisin en el ciclo de vida del software este mecanismo no slo est pensado para las etapas tempranas del ciclo de vida, sino que tambin puede - y debe ser utilizado en etapas como la de prueba de software y mantenimiento. El mecanismo ms comn para su implementacin es la reunin de revisin, la cual deber regirse, para asegurar su xito, por una buena planificacin, control y, sobre todo, por la participacin dedicada de todos y cada uno de los involucrados. Para implementar los conceptos de calidad desde el punto de vista del proceso tambin existen diferentes Modelos y/o Estndares de Calidad que proporcionan un marco comn para orientar los esfuerzos de aseguramiento de calidad. Por ejemplo la norma ISO/IEC 15504, tambin 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
94
evaluacin de la calidad de los procesos. Esta norma se puede utilizar junto con la ISO/IEC 12207 que establece un conjunto de buenas prcticas 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 adquisicin de un producto o servicio software y durante el suministro, desarrollo, operacin, mantenimiento y evolucin de productos software. La norma ISO/IEC 15504 permite adems realizar evaluaciones usando niveles de madurez. Los niveles de madurez son conjuntos predefinidos de procesos que ayudan a una organizacin 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 organizacin. Como se observa en la Figura No. 2.2., el nivel inferior (nivel 0) se corresponde con una organizacin inmadura, los siguientes niveles van haciendo crecer a la organizacin en su madurez, hasta el mximo nivel, el nivel 5.
Figura 2.1 Niveles de Madurez
La consecucin de los niveles de madurez es de forma escalonada, esto significa que para alcanzar un determinado nivel de madurez deben haberse alcanzado tambin los niveles inferiores. Cada nivel de madurez estar formado por un conjunto de procesos, estos procesos se definen en los esquemas de certificacin
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 Estndares de Calidad. Dichos modelos ayudan a la puesta en prctica del concepto general de calidad ofreciendo una definicin ms operacional. En los Modelos de Calidad de Producto, la calidad se define de forma jerrquica. Es un concepto que se deriva de un conjunto de subconceptos, cada uno de los cuales se va a evaluar a travs de un conjunto de indicadores o mtricas. 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. Tambin permiten identificar y comprender las relaciones que se establecen y existen entre las diferentes caractersticas 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 caractersticas intrnsecas del producto, por ejemplo el cdigo fuente. Calidad Externa: que se puede medir a partir del comportamiento del producto, por ejemplo durante la ejecucin de una prueba. Calidad en Uso: que se puede medir durante la utilizacin 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
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 optimizacin de los procesos provee un ambiente de disciplina para trabajar de manera ms formal. La disciplina debe ser manejada con cuidado, ya que, es fcil 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 mtodos para especificar un estndar, 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 convencin, no daar los productos de otros equipos, y sincronizar apropiadamente el trabajo.
En la tabla 3 se muestra una lista resumida de algunos modelos y estndares de calidad. Nivel de Calidad Modelo de Calidad de SW CMMi TickIT Bootstrap Proceso Six Sigma Software Estndar 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
Producto
Personas
Gilb GQM Mc Call Furps Boehm SATC Dromey C-QM Metodologa SQAE WebEQM Personal SW Process (PSP) Team SW Process (TSP)
Tabla No. 3 Modelos y Estndares de Calidad de Software
CIBERTEC
CALIDAD DE SOFTWARE
97
2.2. MTRICAS DE CALIDAD DE PRODUCTO SOFTWARE

La ISO, bajo la norma ISO-9126, ha establecido un estndar internacional para la evaluacin 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 caractersticas de calidad para productos de software. El estndar ISO-9126 establece que cualquier componente de la calidad del software puede ser descrito en trminos de una o ms de seis caractersticas bsicas, las cuales son: funcionalidad, confiabilidad, usabilidad, eficiencia, mantenibilidad y portatilidad; cada una de las cuales se detalla a travs de un conjunto de subcaractersticas que permiten profundizar en la evaluacin de la calidad de productos de software. La tabla 4 muestra la pregunta central que atiende cada una de estas caractersticas. Caracterstica Funcionalidad Confiabilidad Usabilidad Pregunta Central Las funciones y propiedades satisfacen las necesidades explcitas e implcitas; esto es, el qu ? Puede mantener el nivel de rendimiento, bajo ciertas condiciones y por cierto tiempo? El software es fcil de usar y de aprender?
Eficiencia Es rpido y minimalista en cuanto al uso de recursos? Mantenibilidad Es fcil de modificar y verificar? Portabilidad Es fcil de transferir de un ambiente a otro?
Tabla No. 4 Caractersticas 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 Mtricas Externas Parte 3 Mtricas 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 caractersticas de calidad interna y externa, las cuales estn divididas en subcaractersticas, 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 evala 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 evala el total de atributos que un software debe satisfacer teniendo en cuenta condiciones especificadas. Esta calidad es medible a partir de las caractersticas intrnsecas.
CIBERTEC
98
Las caractersticas definidas son aplicables a todo tipo de software. Las caractersticas y subcaractersticas proveen una terminologa consistente respecto de la calidad del producto del software. Esta Norma permite especificar y evaluar la calidad del software desde distintas perspectivas, las cuales estn asociadas a la adquisicin, requerimientos, desarrollo, uso, evaluacin, 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 evaluacin 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 medicin de atributos internos, externos o a travs 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 segn 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).
CIBERTEC
CALIDAD DE SOFTWARE
99
Figura 2.4 Relacin de Mtricas del Modelo / Atributos en ISO/IEC 9126-1
2.2.2. ISO/IEC 9126-2 - Mtricas Externas

ISO/IEC TR 9126-2 provee mtricas externas para la medicin de atributos a travs de 6 caractersticas de calidad externa definidas en ISO/IEC 9126-1. ISO/IEC TR 9126-2 define mtricas externas., ISO/IEC TR 9126-3 define mtricas internas e ISO/IEC 9126-4 define mtricas en calidad en uso para la medicin de caractersticas o subcaractersticas. Las mtricas internas miden el software en s mismo, las mtricas externas miden el comportamiento del sistema basado en computadora que incluye el software, y las mtricas de calidad en uso miden los efectos de uso del software en un contexto de uso especfico. Las mtricas externas usan medidas de un software, derivadas del comportamiento del mismo, a travs de la prueba, operacin y observacin del software. Antes de adquirir o usar un software, ste debe ser evaluado usando las mtricas basadas en los objetivos del rea usuaria de la institucin relacionados al uso, explotacin y direccin del producto, considerando la organizacin y el ambiente tcnico. La mtrica 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 mtricas externas listadas en ISO/IEC TR 9126-2 no estn destinadas a ser un conjunto exhaustivo. Los desarrolladores, evaluadores, gerentes de calidad y compradores pueden seleccionar
CIBERTEC
100
mtricas de ISO/IEC TR 9126-2 para definir requerimientos, evaluar productos de software, medir aspectos de calidad y otros propsitos. Los usuarios de ISO/IEC TR 9126-2 pueden seleccionar o modificar y aplicar mtricas y mediciones a partir de ISO/IEC TR 9126-2 o pueden definir mtricas especficas de la aplicacin para su dominio de aplicacin en particular. ISO/IEC TR 9126-2 es usada junto con ISO/IEC 9126-1. ISO/IEC TR 9126-2 contiene una explicacin de cmo aplicar las mtricas de calidad del software, un conjunto bsico de mtricas para cada Subcaracterstica y un ejemplo de cmo aplicar las mtricas durante el ciclo de vida del producto de software. ISO/IEC TR 9126-2 no asigna un rango de valores para estas mtricas 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 categora 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 especficas del usuario pero si depende de factores genricos; por ejemplo factores humanos.
2.2.3. ISO/IEC 9126-3 - Mtricas Internas

ISO/IEC TR 9126-3 provee mtricas internas para la medicin de atributos a travs de 6 caractersticas de calidad interna definidas en ISO/IEC 9126-1. La mtrica interna mide el software en s mismo y puede ser aplicada a un software no ejecutable (como una especificacin o cdigo fuente) durante el diseo y la codificacin. En el desarrollo de un software, los productos intermedios deben ser evaluados usando mtricas internas que permitan medir las propiedades intrnsecas, incluyendo aquellas que pueden derivarse de comportamientos simulados. El propsito principal de esta mtrica interna es asegurar que se logre la calidad externa y la calidad de uso requerida. La mtrica 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 ejecucin. Las mtricas internas miden atributos internos o indican los atributos externos, a travs del anlisis de las propiedades estticas de productos intermedios o entregables del software. Las medidas de las mtricas internas usan nmeros o frecuencias de elementos de composicin de software, los cuales aparecen, por ejemplo, en las sentencias de cdigo de fuente, control de grficos, flujo de datos y estados de representacin de procesos Las mtricas listadas en ISO/IEC TR 91263 no estn destinadas a ser un conjunto exhaustivo. Los desarrolladores, evaluadores, gerentes de calidad y compradores pueden seleccionar mtricas de ISO/IEC TR 9126-3 para definir requerimientos, evaluar productos de software, medir aspectos de calidad y otros propsitos. ISO/IEC TR 9126-3 es usada junto con ISO/IEC 9126-1. ISO/IEC TR 9126-3 contiene una explicacin de cmo aplicar las mtricas de calidad del software, un conjunto bsico de mtricas para cada Subcaracterstica y un ejemplo de cmo aplicar las mtricas
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 mtricas 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 categora 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 especficas del usuario pero si depende de factores genricos; por ejemplo factores humanos. En la tabla No. 5 se muestra un ejemplo de mtrica, tanto para calidad externa como para calidad interna. Note que las entradas para la medicin difieren.
2.2.4. Relacin Entre las Mtricas Internas y Externas

Cuando los requisitos de calidad del software son definidos, se listan las caractersticas o subcaractersticas de calidad del software que contribuyen a dichos requisitos. Entonces, las mtricas 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 mtricas internas y los rangos aceptables son especificados para cuantificar los atributos de calidad interna, as ellos pueden usarse para verificar que el software intermedio rene las especificaciones de calidad interna durante el desarrollo. Se recomienda que las mtricas internas que se usen tengan en lo posible una fuerte relacin con la mtrica externa diseada, para que ellas puedan ser usadas para predecir los valores de las mtricas externas. Sin embargo, es generalmente difcil disear un modelo terico riguroso que proporcione una relacin fuerte entre la mtrica interna y la externa.
Caracterstica Sub Caracterstica Mtrica Prposito de la Mtrica Funcionalidad Aplicabilidad Adecuacin Funcional (Calidad Externa) Cun adecuadas son las funciones evaluadas? Nmero de funciones que son adecuadas para realizar las tareas especficas comparadas con el nmero de funciones evaluadas
Mtodo de Aplicacin
Frmula
X=1-A/B Nmero de funciones en que se detectaron Valor A problemas en la evaluacin Valor B Nmero de funciones evaluadas Interpretacin del valor 0<=X<=1 medido Lo ms cerca de 1,0 es lo mejor Especificacin de requerimientos Entrada para la medicin Reporte de validacin
Adecuacin Funcional (Calidad Interna) Cun adecuadas son las funciones revisadas? Contar el nmero de funciones implementadas en las que se detect problemas para realizar las tareas especificadas y comparar con las funciones implementadas. Se puede medir lo siguiente: - todas o parte de las especificaciones de diseno - mdulos/partes completadas de productos de software X=1-A/B Nmero de funciones en que se detectaron problemas en la evaluacin Nmero de funciones revisadas 0<=X<=1 Lo ms cerca de 1,0 es lo mejor Especificacin de requerimientos Reporte de validacin
Tabla No. 5 Mtricas de Calidad Externa e Interna
CIBERTEC
102
2.2.5. ISO/IEC 9126-4 - Mtricas para Calidad en Uso

ISO/IEC TR 9126-4 provee mtricas para la calidad en uso para la medicin de los atributos definidos en ISO/IEC 9126-1. Las mtricas de calidad en uso miden los efectos de uso del software en un contexto especfico de uso. Estas mtricas miden si el producto se corresponde con las necesidades especficas de los usuarios para as obtener los objetivos especficos con eficiencia, productividad, seguridad y satisfaccin en un contexto de uso especfico. Esto solo es llevado a cabo en un ambiente de sistema realista.
Figura 2.5 Relacin de Calidad Externa / Calidad Interna en ISO/IEC 9126-1
2.2.6. ISO/IEC 25000:2005 SquaRE

SQuaRE (Software Quality Requirements and Evaluation) es una nueva serie de normas que se basa en ISO 9126 y en ISO 14598 (Evaluacin del software). Uno de los principales objetivos de la serie SQuaRE es la coordinacin y harmonizacin del contenido de ISO 9126 y de ISO 15939:2002 (Measurement Information Model). ISO 15939 tiene un modelo de informacin que ayuda a determinar que se debe especificar durante la planificacin, performance y evaluacin de la medicin, Para su aplicacin, cuenta con los siguientes pasos: (1) Recopilar los datos, (2) Preparacin de los datos y (3) Anlisis de los datos. Por otro lado, la familia de normas ISO 25000 est formada por 5 divisiones como podemos observar en la Figura No. 2.6 y tiene principalmente dos objetivos:
CIBERTEC
CALIDAD DE SOFTWARE
103
1.
Establecer un modelo de calidad para el producto software, definiendo las caractersticas y subcaractersticas que se deben tener en cuenta. Definir el proceso de evaluacin de la calidad del producto software, con el fin de poder establecer la calidad en funcin del modelo.
2.
Figura 2.6 Composicin de ISO/IEC 25000
La familia de normas ISO 25000 est actualmente en estado de desarrollo y desde el punto de vista de la calidad del producto, su objetivo es sustituir a dos normas: 1. ISO/IEC 9126: que es el conjunto de normas que hasta ahora defina el modelo de calidad para el producto software. 2. ISO/IEC 14598: que es el conjunto de normas que determina el proceso para evaluar el producto software. Por los tanto, mientras la norma ISO/IEC 15504 est orientada a los procesos y puede ser utilizada para evaluar la capacidad de los mismos y la madurez de una organizacin respecto a sus procesos, la familia ISO 25000 est orientada al producto software, permitiendo definir el modelo de calidad y el proceso a seguir para evaluar dicho producto. Finalmente la principal relacin entre estas normas radica en que la serie de normas ISO 25000 se puede utilizar como referencia cuando se evalan los procesos de medicin y aseguramiento de la calidad de una organizacin.
CIBERTEC
104
Figura 2.7 Relacin ISO 25000 / SPICE
2.3. EVALUACIN DE MTRICAS

2.3.1. Definiciones
Desarrollador de producto software: Es la persona u organizacin que fabrica un producto software. Evaluacin de producto software: Operacin tcnica que consiste en producir una evaluacin y valorizacin de una o ms caractersticas de un producto de software de acuerdo a un procedimiento especificado. NOTA: El trmino evaluacin es preferido con el fin de evitar confusin con la nocin de prueba ampliamente aceptada en el campo de la ingeniera de software. Evaluacin de producto software no es necesariamente una prueba de conformidad en el contexto de un esquema de certificacin. Sin embargo, las pruebas de conformidad pueden ser parte de una evaluacin. Evaluador: Es la organizacin que efecta la evaluacin. Un evaluador puede ser por ejemplo un laboratorio de prueba, el departamento de calidad de una organizacin de desarrollo de software, una organizacin gubernamental o un usuario. Herramienta de evaluacin: Es el instrumento que puede ser usado durante una evaluacin para recopilar datos, para efectuar la interpretacin de datos o para automatizar parte de la evaluacin. Ejemplos de herramientas son los analizadores de cdigo fuente para calcular mtricas de cdigo, herramientas CASE para producir modelos formales, ambientes de prueba para hacer funcionar programas ejecutables, listas de control para recopilar datos de inspeccin, hojas de clculo para producir sntesis de medidas. Mtodo de evaluacin: Procedimiento que describe la accin a ser ejecutada por el evaluador con el fin de obtener el resultado para la medicin especificada o verificacin aplicada en los componentes de producto especificados o en la totalidad del producto. Registros de evaluacin: Evidencia objetiva y documentada de todas las actividades ejecutadas y de todos los resultados alcanzados dentro del proceso de evaluacin.
CIBERTEC
CALIDAD DE SOFTWARE
105
Reporte de evaluacin: Documento que presenta resultados de evaluacin informacin relevante a una evaluacin. Solicitante de evaluacin: Persona u organizacin que solicita una evaluacin.
otra
2.3.2. Proceso de Evaluacin

Establecer requerimientos de evaluacin; que incluye el establecimiento de propsitos de la evaluacin, identificar tipo(s) de producto(s) y la especificacin del modelo de calidad (9126-1 Caractersticas de Calidad). Especificar evaluacin; que incluye la seleccin de las mtricas (9126-2 Mtricas Externas, 9126-3 Mtricas Internas), el establecimiento de los niveles de puntuacin para las mtricas y establecer los criterios para la evaluacin. Disear evaluacin; que incluye la generacin del plan de evaluacin. Ejecutar evaluacin; que incluye la toma de medidas, comparar los criterios y evaluar los resultados de la evaluacin.
En la figura No. 2.8 se presenta una propuesta de niveles de puntuacin de las mtricas que debern ser evaluadas para las caractersticas de calidad que se definieron, de acuerdo al modelo, para el componente de producto.
Requerimientos excedidos Nivel Planeado Rango objetivo Valor Medido Satisfactorio
Nivel Actual
Mnimo aceptable
Peor caso
Inaceptable Insatisfactorio
Escala de Medicin
Niveles de Puntuacin
Figura 2.8 Niveles de Puntuacin para Mtricas
CIBERTEC
106
Ejemplo:
A continuacin se presenta un ejemplo de una modelo de calidad con la definicin de mtricas de calidad externa.
Proyecto Componente Caracterstica peso % SISTEMA DE ADMINISTRACIN DE HORARIOS ACADMICOS P01-DISPONIBILIDAD Sub-Caractersticas Aplicabilidad Precisin Seguridad Interoperabilidad Conformidad de funcionalidad Cambiabilidad Analizabilidad Estabilidad Testeabilidad Conformidad de facilidad de mantenimiento Entendibilidad Facilidad de aprendizaje Atractividad Operabilidad Conformidad de usabilidad Madurez Tolerancia a fallos Recuperabilidad Conformidad de fiabilidad Comportamiento en el tiempo Utilizacin de recursos Conformidad de eficiencia Instalabilidad Adaptabilidad Co-existencia Reemplazabilidad Conformidad de Portabilidad peso 7.0 6.0 0.0 0.0 0.0 5.0 4.0 4.0 4.0 0.0 5.0 5.0 5.0 4.0 0.0 3.0 3.0 0.0 0.0 3.0 3.0 0.0 3.0 2.0 2.0 2.0 0.0 % 54% 46% 0% 0% 0% 29% 24% 24% 24% 0% 26% 26% 26% 21% 0% 50% 50% 0% 0% 50% 50% 0% 33% 22% 22% 22% 0%
Funcionalidad
7.0
30%
Facilidad de mantenimiento
5.0
22%
Usabilidad
4.0
17%
Fiabilidad
3.0
13%
Eficiencia
3.0
13%
Portabilidad
1.0
4%
P01 - DISPONIBILIDAD Carcaterstica Subcaraterstica Mtrica (Atributo de Calidad) Peso Valor de Mtrica RNF Las funciones del Mdulo de Disponibilidad deben ser adecuadas por lo menos en el 70% de los casos al proceso de Gestin 40% 70% de Horarios. Las funciones del Mdulo de Disponibilidad deben estar desarrolladas completamente por lo 33% 60% menos al 60%. Las funciones del Mdulo de Disponibilidad deben estar desarrolladas correctamente por lo 27% 60% menos al 60%. El 60% de las funciones del Mdulo de Disponibilidad deben realizar los clculos con la 42% 60% precisin de 2 decimales definida. El 60% de las funciones del Mdulo de Disponibilidad deben realizar los clculos correctos con la precisin de 2 decimales 33% 60% definida. El 50% de las funciones del Mdulo de Disponibilidad deben 25% 50% realizar los clculos correctos. %
Adecuacin funcional 6 Aplicabilidad Integridad de Implementacin funcional 5 Cobertura de implementacin funcional Funcionalidad Precisin esperada 5 Precisin Proveer la Informacin con un grado necesario de precisin 4 Exactitud de clculo 3 4
Figura 2.9 Modelo de Calidad
Figura 2.10 Mtricas de Calidad
CIBERTEC
CALIDAD DE SOFTWARE
107
CATALOGO DE MTRICAS DE FUNCIONALIDAD SISTEMA DE ADMINISTRACIN DE HORARIOS ACADMICOS 1. P01 DISPONIBILIDAD 1.1. Mtricas de Aplicabilidad
FUN-APLIC-001 Funcionalidad FUN 7 Aplicabilidad APLIC 7 Adecuacion funcional 1 Cun adecuadas son las funciones evaluadas? Qu tan importante es que las funciones del Mdulo de Disponibilidad sean adecuadas al proceso de Gestin de Horarios Acadmicos? 40% 6 Cuntas de las funciones Crticas del Mdulo de Disponibilidad deben ser adecuadas al proceso de Gestin de Horarios Acadmicos? 70% Evaluar las funciones y contar las que son adecuadas respecto del total evaluadas. X =1A/B 0 1 100% Figura 2.11 Catlogo de Mtricas
Cdigo Caracterstica Abreviatura Caract. Peso Caract. Sub Caracterstica Abreviatura Sub Caract. Peso Sub Caract. Atributo Nro Atributo Enunciado 9126 u otro Pregunta (peso)
Peso Relativo Peso Absoluto Pregunta (mtrica)
Mtrica Mtodo de aplicacin Frmula Primer valor (A) Segundo Valor (B) Valor Obtenido
CIBERTEC
108
Actividades
Desarrollar el modelo de calidad de los principales componentes del sistema bajo desarrollo del proyecto integrado Definir las mtricas de calidad externa, para cada uno de los principales componentes del sistema bajo desarrollo del proyecto integrado, precisando el peso absoluto y el peso relativo en funcin a la escala definida. Actualizar el RES con los atributos de calidad previamente identificados. Definir el catlogo de mtricas. Actualizar el valor obtenido a partir del plan de pruebas y de evaluacin de mtricas.
CIBERTEC
CALIDAD DE SOFTWARE
109
Resumen
El mundo globalizado exige cada vez ms la aplicacin de estndares internacionales que garanticen la calidad de los productos. Por esta razn, es necesario que todo aquel que se dedica al desarrollo de software incluya en sus procesos, estndares de calidad que permitan certificarse en alguno de los modelos. Aqu se ha presentado un estndar, el ISO 9126, el cual establece una gua para la evaluacin de la calidad de software, sin embargo es necesario que cada empresa dedicada a producir software trabaje en establecer su modelo de calidad que le permita valorar el nivel de excelencia de sus productos, en el que deber incluirse instrumentos de medicin que permitan calificar cuantitativamente cada una de las caractersticas aqu presentadas. Es importante mencionar, que dependiendo de los distintos tipos de aplicaciones las mtricas podrn variar, ya que aunque las caractersticas expuestas son comunes a la totalidad de los productos, cada software particular requiere una evaluacin especifica. Si desea saber ms acerca de estos temas, puede consultar las siguientes pginas. http://www.iso15504.es Aqu encontrar diferentes temas relacionados con la calidad orientada al proceso de software. http://iso25000.com Aqu encontrar diferentes temas relacionados con la calidad orientada al producto de software.
CIBERTEC
110
CIBERTEC
CALIDAD DE SOFTWARE
111
PRUEBAS DE SOFTWARE
Al trmino de la unidad de aprendizaje, el alumno elabora un plan de pruebas en el que, haciendo uso de tcnicas de caja negra defina los casos prueba a ser aplicados a las funciones desarrolladas en el software del proyecto integrado de quinto ciclo. Asimismo deber generar el informe de pruebas en el que se demuestre la aplicacin de los casos de pruebas y adems se sustente el cumplimiento de las mtricas de funcionalidad.
TEMARIO
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 3.2.1. Planeacin y Control de Pruebas 3.2.2. Anlisis y Diseo de las Pruebas 3.2.3. Implementacin y Ejecucin de Pruebas 3.2.4. Evaluacin de Criterios de Salida y Reportes 3.2.5. Cierre de Pruebas 3.3. Tema 11: Estrategia de Pruebas 3.3.1. Casos de Prueba 3.3.2. Diseo de Casos de Prueba 3.3.3. Realizar Casos de Prueba 3.3.4. Informe y Seguimiento de Pruebas 3.3.5. Relacin entre las Pruebas y la Depuracin
CIBERTEC
112
3.1. PRUEBAS DE SOFTWARE

Los sistemas de software son una parte creciente en nuestra vida, desde aplicaciones de negocio (bancos) hasta productos de consumo (autos). Muchas personas han tenido experiencias con software que no trabaja como es esperado. El software que no hace su trabajo correctamente puede acarrear muchos problemas, desde prdida de dinero, tiempo o una mala reputacin, y pueden incluso causar lesiones o muerte. 1. Papel de las pruebas en el desarrollo de software:
Las pruebas rigurosas a los sistemas y documentacin pueden ayudar a reducir el riesgo de ocurrencia de problemas durante la operacin y contribuyen a la calidad del sistema de software, si los defectos encontrados son corregidos antes de que el sistema sea liberado para uso operacional. Las pruebas de software pueden ser requeridas tambin para conocer los requisitos contractuales o trmites legales, o las especificaciones/estndares industriales. 2. Pruebas y Calidad:
Con la ayuda de las pruebas, es posible medir la calidad del software en trminos de defectos encontrados, tanto para requisitos funcionales o no funcionales y caractersticas. Las pruebas pueden dar la confianza sobre la calidad del software si encuentra pocos o ningn defecto. Se debe aprender de las lecciones de proyecto anteriores. Entendiendo las causas races de los defectos encontrado en otros proyectos, los procesos pueden ser mejorados, se debe evitar que esos efectos ocurran nuevamente y como consecuencia, mejorar la calidad de futuros sistemas. Esto es un aspecto del aseguramiento de la calidad. Las pruebas deben ser integradas como parte aseguramiento de la calidad 3. Cuntas pruebas son suficientes?: de las actividades del
En base al nivel de riesgo se determina cuantas pruebas se harn, incluyendo riesgos tcnicos, de negocio y elementos del proyecto como tiempo y presupuesto. Las pruebas deben proveer suficiente informacin a los involucrados para la toma de decisiones sobre la liberacin del software o sistema que est siendo probado, para el paso o la entrega siguiente del desarrollo a los clientes Una percepcin comn de las pruebas es que nicamente consiste en la ejecucin de scripts. Esto es parte de las pruebas, pero no todas las actividades de la fase de pruebas.
CIBERTEC
CALIDAD DE SOFTWARE
113
Las actividades relacionadas a la fase de pruebas existen antes y despus de la ejecucin de pruebas: planeacin y control, eleccin de condiciones de pruebas, diseo de casos de prueba y revisin de resultados, evaluacin de criterios de salida, reportes del proceso de pruebas, finalizacin y clausura. Tambin incluye la revisin de documentos. Existen diferentes objetivos para probar: Encontrar defectos Aumentar la confianza sobre el nivel de calidad Prevenir defectos El diseo de pruebas de manera temprana en el ciclo de vida puede ayudar a prevenir que defectos san introducidos en el cdigo. La revisin de documentos (por ejemplo: Requerimientos) tambin puede ayudar a prevenir la aparicin de defectos en el cdigo. La depuracin y las pruebas son diferentes. Las pruebas pueden mostrar fallas causadas por defectos. La depuracin es la actividad de desarrollo que identifica la causa de un defecto, repara el cdigo y revisa que el defecto haya sido reparado correctamente. La informacin subsecuente del probador asegura que la correccin ha resuelto la falla. La responsabilidad para cada actividad es muy diferente.
3.1.1. Principios Generales de las Pruebas

` Principio 1: Las pruebas muestran la presencia de defectos. Las pruebas pueden mostrar que los defectos estn presentes, pero no pueden probar que no son defectos. Las pruebas reducen la probabilidad de mantener defectos ocultos en el software pero, si no se encuentran defectos, no es una prueba de que este correcto. Principio 2: Las pruebas exhaustivas son imposibles. Probar todo (todas las combinaciones de entradas y precondiciones) no es viable excepto para casos excepcionales. En lugar de pruebas exhaustivas, el anlisis de riesgo y prioridades debera ser usado para enfocar las pruebas. Principio 3: Pruebas tempranas. Las actividades relacionadas a las pruebas, deben iniciar tan temprano como sea posible en el ciclo de vida de desarrollo de software, y debe enfocarse en objetivos definidos. Principio 4: Agrupacin de defectos. Un pequeo nmero de mdulos contienen la mayor parte de los defectos encontrados durante la pre liberacin de pruebas, o es responsable de la mayor parte de las fallas operacionales. Principio 5: Paradoja del pesticida. Si las mismas pruebas son repetidas una y otra vez, ese conjunto de casos de prueba no encontrar ms defectos.
CIBERTEC
114
Para evitar la paradoja del pesticida, los casos de prueba necesitan ser revisados regularmente, deben escribirse nuevos casos de prueba para probar diferentes partes del software o sistema para potenciar el hallazgo de nuevos errores. Principio 6: Las pruebas son dependientes del contexto. Las pruebas son diferentes en diferentes conceptos. Por ejemplo, el software crtico para un banco es probado diferente a un sitio de comercio electrnico. Principio 7: La falacia de la ausencia de errores. Encontrar y reparar defectos no ayuda si la construccin del sistema es inoperable y no satisface las necesidades y expectativas del cliente.
CIBERTEC
CALIDAD DE SOFTWARE
115
3.2. CICLO DE VIDA DE LAS PRUEBAS

La parte ms visible de las pruebas es la ejecucin, pero para qu sean efectivas y eficientes, el plan de pruebas debe incluir el tiempo esperado para la planeacin de pruebas, diseo de casos de prueba, preparacin para la ejecucin y estatus de evaluacin. El proceso bsico de pruebas consiste en las siguientes actividades principales: (ver Figura 3.1) Planeacin y control Anlisis y diseo Implementacin y ejecucin Evaluacin de criterios de salida y reportes Cierre de las actividades de prueba
Figura 3.1 Proceso Bsico de Pruebas
3.2.1. Planeacin y Control de Pruebas

La planeacin de pruebas es la actividad que verifica el objetivo de las pruebas, define los objetivos y la especificacin de las actividades de prueba. El control de pruebas es la actividad que compara el progreso actual a travs del plan, y reporta el estatus incluyendo las desviaciones del plan. Implica tomar acciones necesarias para conocer la misin y objetivos del proyecto.
3.2.2. Anlisis y Diseo de las Pruebas

Es la actividad donde los objetivos generales de las pruebas son transformados en casos de prueba.
CIBERTEC
116
Contempla las siguientes actividades: Revisin de las bases de pruebas (requerimientos, arquitectura, diseo, interfaces). Identificar y priorizar las condiciones de pruebas basadas en al anlisis de la especificacin, estructura. Diseo y priorizacin de casos de prueba. Identificar la informacin necesaria para probar para dar soporte a los casos e prueba y condiciones de prueba. Diseo del ambiente de prueba e identificacin de cualquiera herramienta o infraestructura requerida.
3.2.3. Implementacin y Ejecucin de Pruebas

Es la actividad donde los procedimientos de pruebas o scripts son especificados combinando los casos de prueba en un orden particular e incluyendo cualquier otra informacin necesaria para la ejecucin de pruebas, el ambiente se preparara y se ejecutan las pruebas. Se compone de las siguientes actividades: Desarrollo, implementacin y priorizacin de casos de prueba. Desarrollo y priorizacin de procedimientos de pruebas, creacin de datos de prueba y opcionalmente codificacin de scripts de prueba automatizados. Creacin de paquetes de pruebas desde los procedimientos de prueba para la ejecucin eficiente. Verificar que el ambiente de prueba ha sido configurado correctamente. Ejecucin de procedimientos de pruebas ya sea manual o usando herramientas de ejecucin, de acuerdo a la secuencia planeada. Comparacin de resultados actuales contra los esperados. Reportar discrepancias e incidentes y analizarlos para establecer su causa (defecto en el cdigo, en el documento, error en la ejecucin).
3.2.4. Evaluacin de Criterios de Salida y Reportes

Es la actividad donde la ejecucin de pruebas se determina a travs de los objetivos definidos. Tiene las siguientes actividades: Revisin de bitcora de pruebas a travs de los criterios de salida especificados en el plan de pruebas. Determinacin acerca de si es necesario ejecutar ms pruebas o si los criterios de salida deben ser cambiados. Preparar un reporte condensado de las pruebas a todos los involucrados.
3.2.5. Cierre de Pruebas

Recopilan informacin de las pruebas completadas para consolidar estadsticas, experiencias. Por ejemplo, cuando un sistema de software es liberado, un proyecto de pruebas se completa, un hito es completado.
CIBERTEC
CALIDAD DE SOFTWARE
117
Incluye las siguientes actividades: Revisin de que entregables planeados han sido entregados, cierre del reporte de incidentes o levantamiento de cambios, documentacin y aceptacin del sistema. Finalizacin y almacenamiento del ambiente de pruebas y la infraestructura para su posterior reuso. Anlisis de lecciones aprendidas para futuras liberaciones del proyecto y la mejora de la madurez de pruebas.
CIBERTEC
118
3.3. ESTRATEGIA DE PRUEBAS

Una estrategia de prueba del software integra los mtodos de diseo de caso de pruebas del software en una serie bien planeada de pasos que desembocar en la eficaz construccin del software. La estrategia proporciona un mapa que describe los pasos que se darn como parte de la prueba, indica cundo se planean y cundo se dan estos pasos, adems de cunto esfuerzo, tiempo y recursos consumirn. Por tanto, en cualquier estrategia de prueba debe incorporar la planeacin de pruebas, el diseo de casos de pruebas, la ejecucin de pruebas y la recoleccin y evaluacin de los datos resultantes. Una estrategia de prueba del software debe ser lo suficientemente flexible como para promover un enfoque personalizado. Al mismo tiempo, debe ser lo adecuadamente rgido como para promover una planeacin razonable y un seguimiento administrativo del avance del proyecto.
3.3.1. Casos de Prueba

Un Caso de Prueba es una especificacin, usualmente formal, de un conjunto de entradas de prueba, condiciones de ejecucin y resultados esperados, identificados con el propsito de hacer una evaluacin de aspectos particulares de un elemento objeto de prueba: Los Casos de Prueba reflejan trazabilidad con los CU (Funcionalidad), ya que estos muestran una secuencia ordenada de eventos, al describir flujos bsicos, flujos alternos, precondiciones y pos condiciones. Las especificaciones suplementarias de requerimientos ya que existen otras caractersticas de calidad a evaluar, adems de la funcionalidad, como Usabilidad, Confiabilidad, Eficiencia, Mantenibilidad y Portabilidad. Las especificaciones de diseo del Sistema, ya que se debe verificar que el software fue implementado segn el diseo y que los elementos arquitectnicos garantizan la calidad del software. Esto garantiza que los procedimientos de pruebas sean compatibles con las necesidades de los usuarios/clientes. En la prctica se tiende a asumir que un Caso de Uso en s mismo es un Caso de Prueba y que el equipo del proyecto trabaje correctamente sobre los Casos de Usos sin planificar los Casos de Prueba. Cuando se sienta a probar los Casos de Uso, intuitivamente asume datos y procedimientos de pruebas sin que estas queden documentadas. Esto es un error ya que el Caso de Prueba extiende o ampla la informacin contenida en un Caso de Uso; por ejemplo, en los Casos de Uso no indicamos valores ni condiciones para las pruebas. Los Casos de Prueba son esenciales para todas las actividades de pruebas: Son la base para disear y ejecutar los procedimientos de pruebas. La profundidad de las pruebas es proporcional al nmero de casos de pruebas. El diseo y desarrollo, y los recursos necesarios son gobernados por los casos de pruebas requeridos.
CIBERTEC
CALIDAD DE SOFTWARE
119
Si los Casos de Prueba no son correctos, la Calidad del Sistema se pone en duda y las pruebas dejan de ser confiables. La Figura 3.2 muestra un modelo conceptual sobre los conceptos que estn asociados a los Casos de Prueba. En ella se puede observar que los Casos de Uso son la fuente principal de los Casos de Prueba, estos se encuentran como entregables del documento Plan de Pruebas. Los Casos de Prueba se pueden agrupar mediante Suite de Pruebas. Los Casos de Prueba estn relacionados con el nivel de la prueba y con el tipo de prueba, la cual a su vez contiene la tcnica que permite ejecutar el tipo de prueba. Los Casos de Prueba proveen las instrucciones para el procedimiento de las pruebas. El procedimiento de la prueba se conforma de pasos, condiciones, valores y resultados esperados y obtenidos. A su vez, el procedimiento de las pruebas puede ser automatizado a travs de los script de pruebas. Todos los conceptos indicados anteriormente permiten visionar el enfoque de pruebas: qu se probar, cmo, quin, cundo, para qu? Una vez ejecutados todos los Casos de Prueba, estos resultados deben reflejarse de manera global. Con ello, se establece si al validar el sistema se cumpli con los criterios de aceptacin definidos con el usuario.
Figura 3.2 Modelo conceptual asociado a Casos de Prueba
CIBERTEC
120
3.3.2. Diseo de Casos de Prueba

Un caso de prueba es un conjunto de entradas, condiciones de ejecucin y resultados esperados, desarrollado para conseguir un objetivo particular o condicin de prueba como, por ejemplo, verificar el cumplimiento de un requisito especfico. Para llevar a cabo un caso de prueba es necesario definir las precondiciones y post condiciones, identificar unos valores de entrada, y conocer el comportamiento que debera tener el sistema ante dichos valores. Tras realizar ese anlisis e introducir dichos datos en el sistema, se observar si su comportamiento es el previsto o no y por qu. De esta forma se determinar si el sistema ha pasado o no la prueba. De ah su importancia durante la ejecucin de pruebas. A continuacin se describir los pasos que se realizarn en el curso para disear casos de pruebas. 1. Definir escenarios Se identifican los escenarios tomando como base las narrativas de los Casos de Uso y considerando cada uno de los escenarios especficos que ocurren para cada Caso de Uso. El flujo normal, cada flujo alterno o la combinacin de ellos es un escenario, que puede ser ejecutado y probado. Esto deriva que siempre el primer escenario sea el que evoca todo el flujo normal de ese Caso de Uso en particular y que la relacin entre Caso de Uso y escenarios sea de uno a muchos. Presentar grficamente la secuencia de eventos que se plantea en cada Caso de Uso: esto permite, como lo muestra la Figura 3.3 abstraer los eventos que ocurren en un Caso de Uso: el flujo normal o bsico y los flujos alternos, y sirve de apoyo para visualizar fcilmente las posibles combinaciones que representaran un escenario ya que establece en qu punto del flujo bsico ocurre y adems qu sucede despus que se activa ese flujo alterno: finaliza el Caso de Uso o retorna al flujo bsico. Chequear que se hayan representado grficamente todos los Flujos alternos con su accin de finalizacin o retorno. Establecer a travs de una tabla todos los escenarios asociados a un Caso de Uso, (ver Tabla 6)
CIBERTEC
CALIDAD DE SOFTWARE
121
Figura 3.3 Visualizacin de los Flujos en un CU
2. Identificar condiciones de entrada Las condiciones de entrada son parte del dominio de valores de entrada. Se pueden identificar condiciones de entrada con estados vlidos (V) y no vlidas (NV); asimismo se consideran condiciones de entrada con el estado que no se aplica (N/A) para un determinado escenario. Existen los siguientes tipos de condiciones de entrada: Miembro de un conjunto Lgico Valor Rango
Tabla No. 6 Escenarios por CU
Veamos un ejemplo. Considrese una aplicacin bancaria, donde el usuario puede conectarse al banco por Internet y realizar una serie de operaciones bancarias. Una vez accedido al banco con las siguientes medidas de seguridad (clave de acceso y dems), la
CIBERTEC
122
informacin de entrada del procedimiento que gestiona las operaciones concretas a realizar por el usuario requiere las siguientes entradas: Cdigo de banco. En blanco o nmero de tres dgitos. En este ltimo caso, el primer dgito tiene que ser mayor que 1. Cdigo de sucursal. Un nmero de cuatro dgitos. El primero de ellos mayor de 0. Nmero de cuenta. Nmero de cinco dgitos. Clave personal. Valor alfanumrico de cinco posiciones. Orden. Este valor se seleccionar de una lista desplegable, segn la orden que se desee realizar. Puede estar en Seleccione Orden o una de las dos cadenas siguientes: Talonario o Movimientos En el caso Talonario el usuario recibir un talonario de cheques, mientras que en Movimientos recibir los movimientos del mes en curso. Si no se especifica este dato, el usuario recibir los dos documentos. A continuacin se muestra una tabla con estados de las condiciones de entrada para un caso de prueba por cada escenario: En base a la regla de generacin de Casos de prueba a partir de Clases de equivalencia, se deberan tener 12 casos de prueba.
CONDICIONES DE ENTRADA Cdigo de Nmero Clave Orden sucursal de cuenta personal V V V V NV V V V V V V V NV V V V V V V V NV V V V V V V V
ID CP CP1 CP2 CP3 CP4 CP5 CP6 CP7
Escenario Escenario 1 Escenario 1 Escenario 1 Escenario 2 Escenario 3 Escenario 4 Escenario 5
Cdigo de banco V V V NV V V V
Resultado esperado Mensaje "Envo de talonarios" Mensaje "Envo de movimientos " Mensaje "Envo de talonarios y movimientos" Mensaje Cdigo de banco incorrecto Mensaje Cdigo de sucursal incorrecto Mensaje Nmero de cuenta incorrecto Mensaje Clave incorrecta
Tabla No. 7 Condiciones de Entrada
3. Definir clases de equivalencia Pueden usarse varias tcnicas para identificar los valores de los datos de entrada, la tcnica de particiones o clases de equivalencias es una de ellas.
CIBERTEC
CALIDAD DE SOFTWARE
123
Las clases de equivalencia se identifican examinando cada condicin de entrada (normalmente una frase en la especificacin) y dividindola en dos o ms grupos. Se definen dos tipos de clases de equivalencia:
Condicin de Entrada Clases Vlidas Entrada En blanco Cdigo CEV<01> Clases No Vlidas Entrada Un valor no numrico Cdigo de banco < 200 Si est, es Rango 200 <= Cdigo de banco <= 999 CEV<02> Cdigo de banco > 999 Cdigo de sucursal < 1000 2 Cdigo de sucursal Rango 1000 <= Cdigo de sucursal <=9999 CEV<03> Cdigo de sucursal > 9999 Nmero de ms de cinco dgitos Nmero de menos de cinco dgitos Cadena de ms de cinco posiciones CEV<05> Cadena de menos de cinco posiciones CENV<05> CENV<06> CENV<07> CENV<08> CENV<09> CENV<03> CENV<04> Cdigo CENV<01> CENV<02>
Sec.
Tipo Lgico (puede estar o no)
Cdigo de banco
Nmero de cuenta
Valor
Cualquier nmero de 5 dgitos
CEV<04>
Clave personal
Valor
Cualquier cadena de caracteres alfanumricos de 5 posiciones
Orden
Miembro de un conjunto, con comportamient o distinto
Orden = "Seleccione Orden" Orden = "Talonario" Orden = Movimientos
CEV<06> CEV<07> CEV<08>
Tabla No. 8 Clases de Equivalencia
Clases Vlidas, que representan entradas vlidas al programa. Clases no Vlidas, que representan valores de entrada errneos.
Estas clases se pueden representar en una tabla. A continuacin se muestra las clases de equivalencia para el caso de gestin bancaria anterior:
3.3.3. Realizar Casos de Prueba

En esta ltima etapa, se generan los casos de pruebas. Para ello, se considera como referencia la tabla de condiciones de entrada, indicando en cada caso de prueba las clases de equivalencia creadas. Por ejemplo, para el caso bancario se tendra lo siguiente:
CIBERTEC
ID CP CP1 CP2 CP3 CP4 CP5 CP6 CP7
Clases de equivalencia CEV<02>, CEV<03>, CEV<04>, CEV<05>, CEV<07> CEV<01>, CEV<03>, CEV<04>, CEV<05>, CEV<08> CEV<02>, CEV<03>, CEV<04>, CEV<05>, CEV<06> CENV<01>, CEV<03>, CEV<04>, CEV<05>, CEV<07> CENV<04>, CEV<03>, CEV<04>, CEV<05>, CEV<07> CENV<07>, CEV<03>, CEV<04>, CEV<05>, CEV<07> CENV<09>, CEV<03>, CEV<04>, CEV<05>, CEV<07>
Cdigo de banco 200 820 999 30A 210 210 210
CONDICIONES DE ENTRADA Cdigo de Nmero de Clave personal sucursal cuenta 1000 9999 1001 1989 999 1989 1989 10000 99999 12345 12345 12345 123 12345 Aaaaa Zzzzz A1b2c 1a2b3 1a2b3 1a2b3
Orden Talonario Movimientos Seleccione Orden Seleccione Orden Seleccione Orden Seleccione Orden Seleccione Orden
Resultado esperado Mensaje "Envo de talonarios" Mensaje "Envo de movimientos " Mensaje "Envo de talonarios y movimientos" Mensaje Cdigo de banco incorrecto Mensaje Cdigo de sucursal incorrecto Mensaje Nmero de cuenta incorrecto Mensaje Clave incorrecta
Tabla No. 9 Casos de Prueba
CALIDAD DE SOFTWARE
125
3.3.4. Informe y Seguimiento de Pruebas

De acuerdo al estndar de documentacin de pruebas de software IEEE Std 829-1998, se pueden distinguir histricos, incidencias y resmenes (ver Figura No. 3.4).
Figura 3.4 Documentacin Relacionada con la Ejecucin de las Pruebas
El Histrico de Pruebas (Test Log) documenta todos los hechos relevantes ocurridos durante la ejecucin de las pruebas. El Test Log suele tener la siguiente estructura: Identificador. Descripcin de la prueba: elementos probados y entorno de la prueba. Anotacin de datos sobre cada hecho ocurrido (incluido el comienzo y el final de la prueba) El Informe de Incidente (Test Incident Report) documenta cada incidente (por ejemplo, una interrupcin en las pruebas debido a un corte del fluido elctrico, bloqueo del teclado) ocurrido en la prueba y que requiera de una posterior investigacin. El Informe de Incidente, debe tener la siguiente estructura:
CIBERTEC
126
Identificador. Resumen del incidente. Descripcin de datos objetivos (fecha/hora, esperados) Impacto que tendr sobre las pruebas.
entradas,
resultados
El Informe Resumen de Pruebas (Test Summary Report) resume los resultados de las actividades de prueba (las sealadas en el propio informe) y aporta una evaluacin del software basada en dichos resultados. El Informe Resumen de Pruebas deber tener la siguiente estructura: Identificador. Resumen de la evaluacin de los elementos probados. Variaciones del software respecto de a su especificacin de diseo, as como las variaciones en las pruebas. Valoracin de la extensin de la prueba (cobertura lgica, funcional, de requisitos). Resumen de los resultados obtenidos en las pruebas. Evaluacin de cada elemento software sometido a prueba (evaluacin general del software incluyendo las limitaciones del mismo). Firmas y aprobaciones de quienes deban supervisar el informe.
3.3.5. Relacin entre las Pruebas y la Depuracin

Depuracin es el proceso de analizar y corregir los efectos que sospecha que contiene el software, ver Figura No. 3.5.
Figura 3.5 Proceso de Depuracin
CIBERTEC
CALI DA D DE SOFTW AR E
127
Durante la Depuracin es necesario tener en cuenta lo siguiente, para el proceso de localizacin del error: Analizar la informacin y pensar (analizar bien, en lugar de aplicar un enfoque aleatorio de bsqueda del efecto). Al llegar a un punto muerto, pasar a otra cosa (refresca la mente). Al llegar a un punto muerto, describir el problema a otra persona (el simple hecho de describir el problema a alguien puede ayudar). Usar herramientas de depuracin slo como recurso secundario (no sustituir el anlisis mental). No experimentar cambiando el programa (no s qu est mal, as que cambiar esto y ver lo que sucede No). Se debe atacar los errores individualmente. Se debe fijar la atencin tambin en los datos (no slo en la lgica del programa). Durante el proceso de correccin del error, es necesario considerar las siguientes recomendaciones: Donde hay un defecto, suele haber ms (lo dice la experiencia). Debe fijarse el defecto, no sus sntomas (no debemos enmascarar sntomas, sino corregir el efecto). La probabilidad de corregir perfectamente un defecto no es del 100% (cuando se corrige, hay que probarlo). Cuidado con crear nuevos defectos (al corregir defectos se producen otro nuevos). La correccin debe situarnos temporalmente en la fase de diseo (hay que retocar desde el comienzo, no slo el cdigo). Cambiar el cdigo fuente, no el cdigo objeto.
CIBERTEC
128
Actividades
Elaborar el plan de pruebas para determinar las pruebas que sern aplicadas en el proyecto integrado de quinto ciclo. Desarrollar los casos de prueba de las funciones principales del aplicativo bajo desarrollo en el curso de DAW1. Ejecutar los casos de prueba, para completar los resultados y compararlos con los resultados esperados. Elaborar el informe de pruebas indicando el resultado por cada uno de los mdulos del producto software probado. Evaluar las mtricas de calidad externa definidas en el modelo de calidad de producto software.
CIBERTEC
129
Formatos
PP Plan de Pruebas de Software
Plan de Pruebas
Versin <x.y.z>
CIBERTEC
130
Versin
<x.y.z>
Autor
Descripcin
Fecha de Elaboracin
<Fecha de Elaboracin>
Fecha de Revisin
<Fecha de Revisin>
Revisado por
<Persona(s) que revisa(n) el documento>
<Persona que elabora el <Detalles> documento>
CIBERTEC
131
Contenido
1.
1.1 1.2 2. 3. 3.1 3.2 4. 5. 6. 6.1 6.2
Introduccin
132 DEFINICIONES, ACRNIMOS Y ABREVIATURAS 132 DOCUMENTOS RELACIONADOS Objetivo 132 Alcance 132 DENTRO DEL ALCANCE 133 FUERA DEL MBITO 133 Roles y Recursos 133 Tcnica a utilizar 133 Enfoque de las Pruebas 133 Pruebas Funcionales 134 ACTIVIDADES 134 6.2.1DISEO DE LOS CASOS DE PRUEBA 134 6.2.2GENERACIN DE LOS CASOS DE PRUEBA 134 6.2.3DEFINICIN DE LOS PROCEDIMIENTOS DE PRUEBA 135 6.2.4EJECUCIN DE LOS CASOS DE PRUEBA 135 6.2.5REPORTAR Y DOCUMENTAR LAS PRUEBAS 136 6.2.6 ANLISIS DE RESULTADOS OBTENIDOS 136 132
7. Planificacin 137
CIBERTEC
CALIDAD DE SOFTWARE
132
1.
Introduccin
[Describa de manera breve el contenido del documento orientando la descripcin hacia la utilidad que se quiere conseguir.] [El presente documento describe el plan de pruebas de sistema, esto abarca la metodologa, en donde se especifican mtodos, tcnicas y forma en que se disean, ejecutan, evalan y reportan los resultados de las pruebas de sistema Las pruebas de sistema a desarrollar, luego de leer este plan, se ejecutan en cuanto se ha finalizado con las pruebas de Integracin, ya que se debe tener el sistema completo para poner en prctica las pruebas de sistema. Luego de realizar las pruebas, se verificar si el sistema XYZ cumple con los requisitos exigidos por el usuario, en los cuales se debiera obtener los resultados esperados, de no ser as, se determina que se han encontrado errores que habr que reportar a los desarrolladores]
1.1 Definiciones, Acrnimos y Abreviaturas
1.2 Documentos Relacionados

Ttulo Reporte de Especificacin de Software Fecha 24 de enero de 2011 Identificador del documento RES v2.0
2.
Objetivo
[Describa de manera breve el propsito que se pretende alcanzar con la aplicacin del plan de pruebas.] El documento tiene como objetivo describir el plan a seguir para realizar las pruebas al Sistema, con lo cual se especifican etapas a seguir para disear, generar, definir procedimientos, ejecutar, evaluar y reportar los resultados obtenidos de las pruebas. Al disear y generar las pruebas, stas se validarn con las personas calificadas para ello, para luego ejecutarlas y tomar los resultados obtenidos. Finalmente los resultados se evaluarn y reportarn. Las pruebas del sistema tienen como objetivo ejercitar el sistema comprobando la integracin total del sistema, verificando el funcionamiento correcto de las interfaces entre los distintos subsistemas que lo componen.
3.
Alcance
[Describa de manera breve el alcance de las pruebas descritas en el plan de pruebas.] Las pruebas de sistema a realizar, sern pruebas funcionales sobre las funciones del sistema, a partir de las condiciones de entrada y evaluando los resultados obtenidos. No es necesario conocer la lgica del programa, nicamente la funcionalidad que debe realizar. Para probar correctamente el sistema, las pruebas se realizan basndose en los requerimientos establecidos por el usuario del sistema
CIBERTEC CIBERTEC
<Nombre del Proyecto>
Versin: x.y.z
3.1 Dentro del Alcance

Se contemplan las siguientes actividades para el proceso de desarrollo de pruebas Funcionales: Diseo de casos de prueba Generacin de casos de prueba Definicin de los procedimientos de la prueba Ejecucin de pruebas Reportar y documentar pruebas Anlisis de resultados obtenidos Los mdulos y funciones a ser probados sern: Mdulo 1 Funcin 1 Funcin 2 Mdulo 2 Funcin 1 Funcin 2
3.2 Fuera del mbito Indicar que mdulos no sern objeto de la prueba
4.
Roles y Recursos
Listar los roles y recursos asignados al proyecto
RECURSOS HUMANOS Rol Mnimos recursos recomendados Responsabilidades especficas o comentarios Proporcionar una gestin adecuada. Responsabilidades: Proporcionar una direccin tcnica. Adquirir los recursos apropiados. Informar de la gestin. Identificar, priorizare implementar los casos de prueba. Responsabilidades: Generar el Plan de pruebas. Disear los Casos de prueba. Evaluar el esfuerzo de prueba. Ejecutar las pruebas. Responsabilidades: Ejecutar pruebas. Recuperar los errores. Documentar los defectos. Recurso
Gestor de prueba
Nombre del recurso (probador)
Diseador de prueba
Probador
5.
Tcnica a utilizar
La tcnica a utilizar para las pruebas de sistema son las de Caja Negra.
6. Enfoque de las Pruebas
Los tipos de pruebas que se realizarn al software son:
133
134
6.1
Pruebas Funcionales Estn enfocadas a asegurar que el software realiza correctamente todas las funciones que se han detallado en los requerimientos dados por el usuario. Se realizan pruebas para cada caso de uso y cada una de las actividades a desarrollar se describe en la seccin 6.2
6.2
Actividades De acuerdo a lo establecido en la seccin 3.1., las actividades sern:
6.2.1
Diseo de los Casos de Prueba Para disear los casos de prueba de sistema, se identifica la tcnica de caja negra descrita en la seccin 5. Para confeccionar los casos de prueba con la tcnica Caja Negra, sta provee distintos mtodos. Los que se ocuparn son los siguientes: A partir de especificaciones formas de casos de uso. Particiones de Equivalencia (para condiciones de entrada de tipo valor, rango de valores, miembro de un conjunto y lgica). Anlisis de Valores Lmite (para condiciones de entrada de rango de valores, miembro de un conjunto y lgica)
6.2.2
Generacin de los Casos de Prueba En la generacin o creacin de los casos de prueba, se representan los datos que se utilizarn como condiciones de entrada para ejecutar el software a probar. En concreto, los casos de prueba determinan un conjunto de entradas, condiciones de ejecucin y resultados esperados para un caso de uso en particular. La tcnica de caja negra proporciona distintos criterios para generar los casos de prueba. A continuacin, en las tablas N 1 y 5 se presenta una tabla de formulario de casos de prueba para cada criterio determinado. En general, para la generacin de todos los casos de prueba se debe tener lo siguiente: Aplicativo: Nombre del aplicativo bajo pruebas. Requerimiento: Cdigo del Requerimiento Funcional asociado al CUS que se probar. Proceso: Mdulo en el que reside el CUS que se probar. Caso de Uso: Cdigo y nombre del CUS que se probar Responsable: Nombre del responsable de ejecucin de la prueba. Pre-Condiciones: Que pueden tener relacin con la precondicin del casos de uso. Propsito: Objetivo del caso de prueba. Escenario: Cdigo y nombre del escenario que ser desarrollado por el caso de prueba. Actividad: Descripcin de las acciones para ejercitar el caso de prueba, a partir de las condiciones de entrada (que son las entradas del sistema).
CIBERTEC
Versin: x.y.z Clase de equivalencia: Cdigos de las clases de equivalencia que sern utilizados en la prueba. Resultado esperado: Es el resultado que producir el software al ejecutar dicho caso, lo que es necesario para detectar una posible falla en el programa, adems de observaciones en caso necesario.
A continuacin se presentan los formularios para los casos de pruebas

CASOS DE PRUEBA
Aplicativo: Requerimiento: Proceso
Caso de Uso
Sistema de Planificacin Peridica de Requerimientos Informticos 2

Conocimiento Mantenimiento de reas de Conocimiento
Responsible Pre Condiciones Propsito

Escenario 1.1 Agregar una nueva rea de conocimiento Sec. Actividad 1 2 3
Clase de equivalencia
Resultado Esperado
Tabla N1 Formulario de Casos de Prueba con uso de Criterios de Especificacin Formal, Clases de Equivalencia y Anlisis de Valores Lmite
6.2.3
Definicin de los procedimientos de prueba Para llevar a cabo el procedimiento de prueba, se ha determinado que las actividades de las pruebas funcionales, sern abordadas como se indica a continuacin: Que la encargada de Testing Claudia Melndez (T1), se ocupar de disear, generar, ejecutar y reportar los casos de prueba para los casos de uso de: Mdulo XYZ, Mdulo ABC; descritos en el Reporte de Especificacin de Software (RES) versin x.y.z. Que la encargada de Testing Nadia Aliaga (T2), se ocupar de disear, generar, ejecutar y reportar los casos de prueba para casos de uso de: Mdulo RST, Mdulo UVW; descritos en el Reporte de Especificacin de Software (RES) versin x.y.z Las fechas correspondientes a las actividades, mostrarn en la tabla N3 de la seccin 7. se
6.2.4
Ejecucin de los Casos de Prueba Para la ejecucin de los casos de prueba, teniendo el sistema XYZ integrado, se aplicarn las entradas descritas para cada caso de prueba generado en la seccin 6.2.2, a travs de las interfaces del sistema, para lo cual se deber generar la Tabla N2 de Resultados Obtenidos, en donde se ir comparando los 135
136
resultados obtenidos con los esperados para identificar las posibles fallas (que ocurren cuando un programa no se comporta adecuadamente, esto quiere decir que hay un defecto en el cdigo) y que a continuacin se presenta: Cdigo de Caso de Prueba Salida Esperada Salida obtenida (*)
Tabla N2 Tabla de Resultados Obtenidos (*): La respuesta de la salida obtenida deber ser el resultado de comparar la salida obtenida con la esperada: OK (la salida obtenida est dentro del rango previsto por la salida esperada), falla menor (la diferencia entre las salidas es una cuestin de formato), falla grave (el sistema no complet su salida o la complet pero se "cay" despus). 6.2.5 Reportar y Documentar las Pruebas Luego de haber ejecutado todos los casos de pruebas validados, stos se deben documentar, con el resultado de la ejecucin (salida obtenida), determinando el nmero de cules pasaron satisfactoriamente, cules no lo hicieron y adems que fallas se encontraron. Para el completo reporte de las pruebas, se deber generar un documento, Informe de Reportes de Casos de Prueba a Requerimientos Funcionales, que deber contener: Ttulo Fecha Realizado por Historial de versiones Dependiendo del criterio usado: Tabla de identificacin de clases de equivalencia Tablas de formulario de casos de prueba, aplicando el criterio de clases de equivalencia y anlisis de valores lmite (tabla N1, de la seccin 6.2.2) Tabla de Resultados Obtenidos (Tabla 2) con todos los casos de pruebas 6.2.6 Anlisis de Resultados Obtenidos Para realizar el anlisis de resultados obtenidos, se har de acuerdo a la tabla de resultados obtenidos (tabla N2), y se debern sacar conclusiones de acuerdo al nmero de aprobaciones (resultados esperados OK) y fallas encontradas (resultado obtenido falla menor o falla grave). Para el completo reporte de anlisis de resultados, se deber generar un documento que, deber ser llamado Informe de anlisis de resultados obtenidos de Pruebas a Requerimientos Funcionales, que deber contener: Cul es el estado actual del software, en cuanto al nivel probable de calidad que alcanz? Para esto, se debe determinar el porcentaje de salidas obtenidas con respuesta OK, las cuales se suman, obteniendo el total de nivel de satisfaccin de las pruebas a requerimientos funcionales. Se espera que este porcentaje sea superior a
CIBERTEC
Versin: x.y.z un 85%, de lo contrario el sistema no estara cumpliendo con los atributos de calidad mnimos requerido por el equipo de Calidad. Cunto tiempo se llevaron los procesos de prueba? Se debe mencionar la cantidad de das u horas que se necesit. Cun efectivo fue el proceso de prueba? (cuntos fallas se detectaron?) Se deber dar el nmero de fallas encontradas. Qu tipo de fallas se producen? Se debe mencionar cuntas fallas menores y graves se registraron, cules fueron ms frecuentes Se debe realizar el proceso de depuracin? Esta interrogante se responder en caso de haber encontrado fallas en el sistema. En caso contrario, se comunica en el informe que se ha terminado el proceso de pruebas.
La ltima interrogante mencionada llevar a determinar en este informe si se termina el proceso de pruebas, esto para saber si se puede dar por concluido. En caso negativo, se debe planificar el proceso de depuracin dentro del informe de anlisis de resultados obtenidos. El proceso de depuracin consiste en arreglar las fallas en el sistema que generaron los casos de prueba ejecutados, para esto, se debe informar al lder relacionado, de modo que ste avise al programador correspondiente. Por lo tanto, el programador relacionado, deber depurar la falla encontrada (salida obtenida no esperada) y el ejecutor de las pruebas deber volver a ejecutar todos los casos de prueba nuevamente (casos de prueba que no se ejecutaron satisfactoriamente, y casos que se ejecutaron satisfactoriamente). La razn de esto, es confirmar que la correccin de un defecto no introdujo un nuevo defecto. Esto se debe dejar en claro en el informe de anlisis de resultados obtenidos.
7.
Planificacin
Se contemplan las actividades relacionadas con el plan de Pruebas, en donde se describe: Actividad Responsable, puede ser el equipo de testing (T1: Claudia Mndez y T2: Nadia Aliaga), SQA: Mariela Orrego, Lderes (Fabin Lpez, Daniel Vsquez, Alejandra Torres, Alfonso Morris) Comienzo: fecha en que comienza la actividad Trmino: fecha en que termina la actividad Duracin Actividad Casos de Prueba para Requerimientos Funcionales: nombre de mdulo 1 Casos de Prueba para Requerimientos Funcionales: nombre de Responsable T1 Comienzo do 05 do 05 05-06Trmino vi 10-06-05 Duracin
6 das
T2
05-06-
vi 10-06-05
6 das
137
138
mdulo 2 Informe de casos de pruebas de Sistema Revisin de Informe Correccin de informe Envo de pruebas a equipo Ejecucin de Casos de Prueba de Sistema Informe de Reportes de Pruebas de Sistema e Informe de anlisis de resultados obtenidos Revisin de Reporte e informe de anlisis Correccin de Reporte e informe de anlisis Envo de Informes de reporte y anlisis a equipo
T1, T2 SQA, Lderes T1, T2 T1, T2 Lderes,T1, T2, BD (*) T1, T2
sa 11-0605 ma14-0605 Vie17-0605 Sa18-06-05 ma 28-0605 mi 05 29-06-
sa 11-0605 jue16-0605 Vie17-0605 Sa18-06-05 mi 29-0605 mi 05 29-06-
1 da 3 das 1 da 1 da 2 das 1 da
SQA, Lderes T1, T2 T1, T2
ju 30-06-05 ju 30-06-05 vi 01-07-05
ju 30-06-05 ju 30-06-05 vi 01-07-05
1 da 1 da 1 da
Tabla N3 de Actividades del plan de pruebas de sistema
CIBERTEC
Versin: x.y.z
Resumen
La prueba del software es un elemento crtico para la garanta de la calidad del software. El objetivo de la etapa de pruebas es garantizar la calidad del producto desarrollado. Adems, esta etapa implica: Verificar la interaccin de componentes. Verificar la integracin adecuada de los componentes. Verificar que todos los requisitos se han implementado correctamente. Identificar y asegurar que los defectos encontrados se han corregido antes de entregar el software al cliente. Disear pruebas que sistemticamente saquen a la luz diferentes clases de errores, hacindolo con la menor cantidad de tiempo y esfuerzo. La prueba es un proceso que se enfoca sobre la lgica interna del software y las funciones externas. La prueba es un proceso de ejecucin de un programa con la intencin de descubrir un error. Un buen caso de prueba es aquel que tiene alta probabilidad de mostrar un error no descubierto Una vez generado el cdigo fuente, es necesario probar el software para descubrir (y corregir) la mayor cantidad de errores posible antes de entregarlo al cliente. Su objetivo es disear una serie de casos de prueba que tengan una alta probabilidad de encontrar errores. Aqu es donde entran las tcnicas de prueba del software. Estas tcnicas proporcionan directrices sistemticas para pruebas de diseo que 1) comprueben la lgica interna y las interfaces de todo componente del software y 2) comprueben los dominios de entrada y salida del programa para descubrir errores en su funcin, comportamiento y desempeo. Durante las etapas iniciales del proceso, el desarrollador realiza todas las pruebas. Sin embargo, a medida que avanza este proceso se irn incorporando especialistas en pruebas.
139

Calidad de Software

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Calidad de Software

Uploaded by

Copyright:

Available Formats

Calidad de Software

105 106 108 108 108

3.2.3 3.2.4 3.2.5

Implementacin y Ejecucin de Pruebas Evaluacin de Criterios de Salida y Reportes Cierre de Pruebas

109 109 109 111 111 113 116 118 120

Aseguramie nto de la Calidad de Software

Modelos de Calidad de Software Mtricas de Calidad de Productos de Sofware

Aseguramiento y Control de Calidad Modelo de Procesos

Ciclo de Vida de las Pruebas Estrategia de Pruebas

Evaluacin de Mtricas Modelos de Ciclo de Vida de Software Verificacin y Validacin

Quality Control) Funciones Generales del SQA

1.1. CALIDAD DE SOFTWARE

1.1.1. Definicin de Calidad

1.1.2. Poltica de Calidad

1.1.3. Terminologa segn ISO 8402

SISTEMA DE GESTIN DE LA CALIDAD MEJORA CONTINUA

Responsabilidad de la Direccin Gestin de recursos

Medicin, anlisis y mejoramiento

Realizacin Producto o Servicio

Figura 1.1 - Sistema de Gestin de Calidad

1.1.4. Definicin de Calidad de Software

Figura 1.2 - Determinantes de la calidad del software y de la efectividad de la organizacin

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

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

1.2. ASEGURAMIENTO Y CONTROL DE CALIDAD

SQC Detecta problemas en los productos de trabajo.

Tabla 1 Diferencia entre SQA y SQC

Funciones Generales del SQA

1.3. MODELO DE PROCESOS

Figura 3.1 - Capas de la Ingeniera de Software

El Proceso de Desarrollo de Software

Figura 3.2 - Proceso de Desarrollo de Software

Figura 3.3 - Elementos del Proceso de Software

Figura 3.4 - Relacin entre los Elementos del Proceso de Software

Normas Relacionadas con el Proceso de Software

Figura 3.5 - Normas Relacionadas con el Proceso de Software

Figura 3.6 - Proceso

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

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

Figura 3.9 - Procesos y Ciclos de Vida

Figura 3.10 - Procesos y Productos

Los Procesos ISO 12207:2008

Figura 3.11 - Modelo de Procesos ISO 12207:2008

PROCESOS CORPORATIVOS APLICACIN : PROYECTOS PRODUCTOS PROYECTOS SERVICIOS

PROCESOS , DEFINICIO NES Y DESCRIPCIONES

METODO LOG AS , MTO DOS Y MTRICAS

PROCEDIMIENTO S , TCNICAS , HERRAM IENTAS Y ENTORNOS

Figura 3.12 - Modelo de Procesos ISO 12207:2008 Alcance

1.4. MODELO DE CICLO DE VIDA DE SOFTWARE

Codificar y corregir (Code-and-Fix)

Figura 4.1 - Modelo de Desarrollo en Cascada

Figura 4.2 - Modelo de Desarrollo Evolutivo

Desarrollo Formal de Sistemas

Figura 4.3 - Paradigma de Programacin Automtica

Desarrollo Basado en Reutilizacin

Figura 4.4 Desarrollo Basado en Reutilizacin de Componentes

Figura 4.5 - Modelo de Desarrollo Iterativo Incremental

Figura 4.6 - Modelo de Desarrollo en Espiral

Cul es el modelo de proceso ms adecuado?

Tabla 2 Comparacin entre modelos de proceso de software

1.5. VERIFICACIN Y VALIDACIN DE SOFTWARE

Figura 5.1 Revisiones y Pruebas

Figura 5.2 Verificacin y Validacin

Ventajas de las Revisiones de Software