M09 - Metodología Gestión SQA INTESIS. Desarrollo de Software Servidor Terminológico (SEMANTIKOS) SERVICIO DE SALUD METROPOLITANO OCCIDENTE

Transcripción

1 M09 - Metodología Gestión SQA INTESIS S Desarrollo de Software Servidor Terminológico (SEMANTIKOS) SERVICIO DE SALUD METROPOLITANO OCCIDENTE

2 Tabla de Contenido Introducción Objetivos Alcances Fase 1: Inicio y Fase 2: Elaboración Objetivo Fase 3: Construcción y Fase 4: Pruebas Objetivo Fase 5: Transición Objetivo Fase 6: Producción y Retiro GESTIÓN ÁREA SQA FASE DE INICIO Artefactos FASE DE ELABORACIÓN Artefactos FASE DE CONSTRUCCIÓN Artefactos Pruebas de Aceptación FASE DE TRANSICIÓN Artefactos REVISIÓN DE ARTEFACTOS Y PRUEBAS DE SOFTWARE

3 9.1 REVISIÓN DE ARTEFACTOS Criterios de Revisión Catalogación de Observaciones Criterios de Aprobación TESTING DE SOFTWARE Criterios de Testing de Software Catalogación de Defectos Criterios de Aprobación INDICADORES DE CALIDAD Indicadores de Calidad para el proceso de Testing de Software Este índice demuestra mayor calidad del artefacto mientras más se acerque a cero Índice de Calidad iteraciones de la pieza de software Índice de estado de los defectos detectados Índice de Riesgos Mensual CHECKLIST DE REVISIÓN DE ARTEFACTOS

4 1 Introducción Dado que es factor crítico de éxito en el desarrollo de proyectos de software y es necesario contar con un plan de acciones que permitan obtener el producto en la calidad, costo y plazo deseado, Intesis utilizando las mejores prácticas del negocio, usa el procedimiento SQA - Software Quality Assurance (Aseguramiento de la Calidad del Software), basado en la metodología usada en el proyecto -, definiendo las actividades a realizar para el proyecto del Cliente. El proceso de revisión y testing es el encargado de evaluar la calidad de los artefactos y piezas de software, no solamente en la instancia de aprobación o rechazo del producto final, sino que formando parte de todo el ciclo de vida del proyecto, para así generar acciones oportunas de mejoras sobre puntos deficitarios, a fin de asegurar la calidad y no alterar las variables de tiempo y costo. Se define revisión a la verificación de artefactos y testing o a la verificación de las piezas de software. Para llevar a cabo el SQA, se identifica el siguiente equipo de trabajo y sus funciones de cumplimiento: Equipo QA Interno: Está formado por los integrantes de las diferentes disciplinas que participan en todas las fases del proyecto revisando los artefactos, prácticas y estándares en las distintas etapas y realizando el testing y pruebas de aceptación con el Cliente, a fin de asegurar la calidad desde el inicio del proyecto hasta su puesta en producción. Sus actividades en el ámbito de SQA son: o Revisión cruzada o de pares de los artefactos generados, con el objetivo de verificar integridad y consistencia o Cuando corresponda, la validación de artefactos generados o disponibilizados por otra fase o disciplina. El ámbito en el cual se desarrolla este plan, corresponde a las actividades a realizar por el Equipo QA Interno, de aquí en adelante referido como área SQA, para el proyecto. 4

5 2 Objetivos El propósito de este Plan se resume en los siguientes puntos: o Definir el proceso y los procedimientos del área SQA, definiendo las instancias de revisión, las actividades que involucra y sus propósitos. o Reconocer los entregables a QA en cada fase del proyecto, indicando la disciplina responsable y los aspectos de su revisión. o Definir los entregables de QA y sus propósitos. 3 Alcances El Plan SQA para el proyecto, tiene como finalidad asegurar que los artefactos o productos definidos, bajo la metodología usada en el proyecto cumplan con los niveles de calidad establecidos según las convenciones y procedimientos especificados por el área SQA. Para llevar a cabo este objetivo, el proceso de calidad considera la realización de actividades en todas las fases de desarrollo de la arquitectura SOA, desde la gestión de proyecto hasta la puesta en producción de los productos de software. Estas actividades consideran tareas de revisión, testing, registro y seguimiento de defectos y observaciones, todas aplicables en menor y en mayor grado en cada una de las fases de desarrollo del producto: Incepción, Elaboración, Construcción, Transición y Producción. Teniendo en consideración que el área SQA no interfiere en el ámbito SQA interno de cada Disciplina, sino en los entregables de las mismas en las diferentes fases del proyecto. Para entender cuál es el tipo de revisión que se realizará en cada una de las fases usada en el proyecto, es necesario describir el marco y alcance general de cada una de las etapas, por lo cual se define a continuación el propósito y principales artefactos disponibles en cada fase usada en el proyecto: 5

6 4 Fase 1: Inicio y Fase 2: Elaboración 4.1 Objetivo El objetivo de la fase de Inicio es realizar el levantamiento de requerimientos de alto nivel con el objetivo de validar y verificar el alcance de requerimientos del proyecto. En este período se detalla el alcance del proyecto y se detallan los planes de trabajo. Intesis participa entregando su conocimiento funcional y estableciendo los requerimientos. Es importante mencionar que para cumplir con el requisito Fase 1: Inicio, es necesario contar con el documento funcional sobre la gestión del proyecto y la estructura de la arquitectura de la solución, antes de la fecha de inicio de este proceso. Esta información es necesaria para la generación de los conectores y configuración de los aplicativos Se entiende que el atraso de cualquiera de los requisitos antes mencionados, repercutirá directamente con los plazos del proyecto. 5 Fase 3: Construcción y Fase 4: Pruebas 5.1 Objetivo El objetivo de la fase Construcción es detallar los requerimientos al producto, elaborar los requisitos de arquitectura, establecer el enfoque de pruebas, criterios de aceptación en el proyecto y generan la implementación base. Además de transformar el Diseño elaborado en la Fase 2: Elaboración, en los componentes ya mencionados con anterioridad que conforman la solución. Esta fase ha sido abordada en una etapa, con actividades de construcción, pruebas unitarias y de revisión por parte de Intesis para verificar que las funcionalidades estén correctamente implementadas. Al final de esta fase se cuenta con el aplicativo completo con respecto al ciclo de negocio elegido y definido por el Cliente. Estará listo para ser sometido a pruebas integrales junto con los planes de prueba a aplicar. 6

7 El objeto de la fase Pruebas es verificar el correcto funcionamiento de la aplicación, considerando el flujo de negocio indicado por Intesis. Esta fase será abordada con actividades de pruebas integrales. 6 Fase 5: Transición 6.1 Objetivo El objetivo de esta fase es verificar el correcto funcionamiento de la aplicación, para su paso a producción. 7 Fase 6: Producción y Retiro 7.1 Objetivo El objetivo de la fase es la de Certificación Completa habilitando el ambiente de producción, capacitar a los usuarios, y soportar la aplicación en producción en un Piloto. Al término de estas actividades se entrega la versión de la aplicación definitiva, junto con la documentación asociada. La definición y objetivos de cada una de estas fases exponen las ideas principales de la metodología usada en el proyecto, sin embargo, es preciso indicar que la metodología en cada fase reconoce Disciplinas. Ambos conceptos, Fase y Disciplina, forman parte del ciclo de desarrollo de software propuesto por la metodología usada en el proyecto. Las disciplinas usadas en el proyecto están enfocadas en tres ámbitos: Disciplinas de Desarrollo Disciplinas de Soporte Disciplinas Enterprise El Plan SQA pertenece a la Disciplina de Desarrollo, denominada Testing. 7

8 8 Gestión Área SQA El área SQA define, desde una perspectiva global, las actividades que son necesarias para dar cumplimiento al aseguramiento de la calidad, las cuales se definen para cada una de las fases de la metodología (usada en el proyecto) por cada disciplina de desarrollo. Para verificar la adherencia de los atributos de calidad en un determinado producto o artefacto de software se definen las siguientes actividades: Revisión de Artefactos Definición de Indicadores de Calidad Testing de Software Reporte y Seguimiento de observaciones y defectos Definición de estándares, prácticas y convenciones de calidad A continuación se detalla la gestión del área SQA por cada fase usada en el proyecto, desde la fase de Incepción hasta la fase de Construcción. 8.1 Fase de Inicio En esta fase la gestión del área SQA tiene como foco principal: Revisión de los artefactos disponibles para cada disciplina Aprobación del cierre de la fase de Incepción y paso a la fase de Elaboración Desarrollo de artefactos de la disciplina de Testing, enfocados a la revisión o testing de Prototipos de Mitigación de Riesgos 8

9 9

10 8.1.1 Artefactos Los artefactos generados y/o actualizados, junto con los que el área SQA revisa por cada disciplina en la fase de Incepción, son los siguientes: Artefacto Generado y/o Actualizado Artefacto Validado por el Área SQA Análisis Requerimientos Modelamiento de Disciplina Modelo de Negocio Modelo de Entidades de Dominio Matriz de Trazabilidad Entidades de Dominio x BP Glosario de Conceptos de Negocio Modelo de Requerimientos Documento de Visión Matriz de Trazabilidad Requerimientos por BP Modelo de RQ Especificaciones de RQ Diagramas de Actividad de RQ Modelo de Clases de Análisis y Diagramas de Estado Prototipo GUI Diagrama de Navegabilidad Matriz de Trazabilidad de Requerimientos x RQ Matriz de Trazabilidad de Mapeo GUI x Modelo de Negocio Modelo de Entidades de Dominio Matriz de Trazabilidad Entidades de Dominio x BP Glosario de Conceptos de Negocio Modelo de Requerimientos Documento de Visión Matriz de Trazabilidad Requerimientos por BP Modelo de RQ Especificaciones de RQ Diagramas de Actividad de RQ Modelo de Clases de Análisis y Diagramas de Estado Prototipo GUI Diagrama de Navegabilidad Matriz de Trazabilidad de Requerimientos x RQ Matriz de Trazabilidad de Mapeo GUI x RQ 10

11 Diseño RQ Matriz de Trazabilidad de RQ x Clases de Análisis Matriz de Trazabilidad de Reportes por RQ Diagramas de Clases de Diseño y Estados Prototipo de Mitigación de Riesgos Matriz de Trazabilidad Clases de Análisis x Clases de Diseño Matriz de Trazabilidad Clases de Diseño x RQ Diagrama de Tablas Matriz de Trazabilidad Tablas x Clases de Diseño Matriz de Trazabilidad de RQ x Clases de Análisis Diagramas de Clases de Diseño y Estados Matriz de Trazabilidad Clases de Análisis x Clases de Diseño Matriz de Trazabilidad Clases de Diseño x RQ No Aplica Implementación Arquitectura Pruebas Aplicación UI Aplicación Negocio Aplicación Reporte Diccionario de Datos de la Aplicación Script de Carga de Datos SAD Software Architecture Description Plan de QA Diagrama de Casos de Prueba Casos de prueba Escenarios Sistémicos Datos de Prueba Reportes de Ejecución de Pruebas Minuta de Prueba de Aceptación Matriz de Trazabilidad RQ x Casos de SAD Software Architecture Description Plan de QA Diagrama de Casos de Prueba Casos de prueba Escenarios Sistémicos Datos de Prueba Reportes de Ejecución de Pruebas Matriz de Trazabilidad RQ x Casos de Pruebas 11

12 Pruebas Despliegue Administración de Proyecto Administración Plan de Despliegue Guía de Usuario Guía de Operaciones Material de Capacitaciones Nota de Entrega Plan de Proyecto Plan de Administración de Requerimientos Plan de Comunicación Plan de Administración de Riesgos Minuta / Agenda de Reunión Lista de Riesgos Carta Gantt Estado de Avance Documento de Lecciones Aprendidas Plan de SCM Repositorio No aplica Plan de Proyecto Plan de Administración de Requerimientos Plan de Comunicación Plan de Administración de Riesgos Minuta / Agenda de Reunión Lista de Riesgos Carta Gantt Estado de Avance Plan de SCM Repositorio La revisión de cada artefacto se realiza según criterios especificados en las secciones Revisión de Artefactos y Checklist de Revisión de Artefactos. 12

13 El artefacto Ficha de Actividades y respectivo Diagrama de Actividades, de la disciplina de Modelamiento de Negocio, tienen su origen en la fase de Pre Incepción ya aprobado por el Cliente, por tal motivo este artefacto no es observable ni modificable. A pesar de ello la disciplina Testing los tomará como base para la comprensión del negocio. El artefacto Reportes de Ejecución de Pruebas elaborado por la disciplina de Testing es el resultado de la verificación del Prototipo de Mitigación de Riesgos desarrollado por la disciplina de Diseño. El propósito del Reporte de Ejecución de Pruebas es informar las pruebas ejecutadas y resultados obtenidos, indicando, si existiera, el desvío de los resultados esperados. La condición necesaria para la aprobación del cierre de la fase de Incepción y paso a la fase de Elaboración se basa en la completitud, consistencia y claridad lograda, la posibilidad de extrapolar escenarios y los indicadores de calidad obtenidos según revisión de artefactos y riesgos vigentes. Detalle de indicadores de calidad en la sección Indicadores de Calidad 8.2 Fase de Elaboración En esta fase la gestión del área SQA tiene como foco principal: Revisión de los artefactos disponibles para cada disciplina Aprobación del cierre de la fase de Elaboración y paso a la fase de Construcción Elaboración de artefactos de la disciplina de Testing, enfocados al testing de software que tiene lugar en la siguiente fase y a la revisión o testing de Prototipos de Mitigación de Riesgos Artefactos Los artefactos generados y/o actualizados, junto con los que el área SQA revisa por cada disciplina en la fase de Elaboración, son los siguientes: 13

14 Artefacto Generado y/o Actualizado Artefacto Validado por el Área SQA Análisis Requerimientos Modelamiento de Negocio Disciplina Modelo de Negocio Modelo de Entidades de Dominio Matriz de Trazabilidad Entidades de Dominio x BP Glosario de Conceptos de Negocio Ficha de Actividades Modelo de Requerimientos Documento de Visión Matriz de Trazabilidad Requerimientos por BP Actas de Aprobación Minuta de Requerimientos de Análisis Modelo de RQ Especificaciones de RQ Diagramas de Actividad de RQ Modelo de Clases de Análisis y Diagramas de Estado Prototipo GUI Diagrama de Navegabilidad Matriz de Trazabilidad de Requerimientos x RQ Matriz de Trazabilidad de Mapeo GUI x RQ Matriz de Trazabilidad de RQ x Clases de Análisis No Aplica No Aplica Modelo de RQ Especificaciones de RQ Diagramas de Actividad de RQ Modelo de Clases de Análisis y Diagramas de Estado Prototipo GUI Diagrama de Navegabilidad Matriz de Trazabilidad de Mapeo GUI x RQ Matriz de Trazabilidad de RQ x Clases de Análisis Matriz de Trazabilidad de Reportes por RQ 14

15 Matriz de Trazabilidad de Reportes por RQ Diseño Diagramas de Clases de Diseño y Estados Prototipo de Mitigación de Riesgos Matriz de Trazabilidad Clases de Análisis x Clases de Diseño Matriz de Trazabilidad Clases de Diseño x RQ Diagrama de Tablas Matriz de Trazabilidad Tablas x Clases de Diseño Diagramas de Clases de Diseño y Estados Prototipo de Mitigación de Riesgos Matriz de Trazabilidad Clases de Análisis x Clases de Diseño Matriz de Trazabilidad Clases de Diseño x RQ No Aplica Implementación Arquitectura Pruebas Aplicación UI Aplicación Negocio Aplicación Reporte Diccionario de Datos de la Aplicación Script de Carga de Datos SAD Software Architecture Description Plan de QA Diagrama de Casos de Prueba Casos de prueba Escenarios Sistémicos Datos de Prueba Reportes de Ejecución de Pruebas Minuta de Prueba de Aceptación Matriz de Trazabilidad RQ x Casos de Pruebas SAD Software Architecture Description Plan de QA Diagrama de Casos de Prueba Casos de prueba Escenarios Sistémicos Datos de Prueba Reportes de Ejecución de Pruebas Matriz de Trazabilidad RQ x Casos de Pruebas 15

16 Despliegue Plan de Despliegue Guía de Usuario Guía de Operaciones Material de Capacitaciones Nota de Entrega Plan de Proyecto Plan de Administración de Requerimientos Plan de Comunicación No aplica Minuta / Agenda de Reunión Lista de Riesgos Carta Gantt Estado de Avance Plan de Administración de Riesgos Administración de Proyecto Administración Minuta / Agenda de Reunión Lista de Riesgos Carta Gantt Estado de Avance Documento de Lecciones Aprendidas Plan de SCM Repositorio No Aplica El artefacto Reportes de Ejecución de Pruebas elaborado por la disciplina de Pruebas es el resultado de la revisión o testing de Prototipos de Mitigación de Riesgos desarrollados por la disciplina de Diseño. El propósito del Reporte de Ejecución de Pruebas es informar las pruebas ejecutadas y resultados obtenidos, indicando, si existiera, el desvío de los resultados esperados. 16

17 Los restantes artefactos elaborados, para cada proyecto de Administración de Personas, por la disciplina de Testing en esta fase tienen los siguientes propósitos: Plan de QA: este artefacto corresponde a un documento en formato Word almacenado en CVS. Su propósito es declarar el ámbito de las pruebas, objetivo de las pruebas, elementos a testear, estimación de recursos y tiempos a consumir. En el caso de que la disciplina de Implementación informe que realizará entregas parciales de la pieza de software, se detalla en el Plan de QA, el ámbito y contenido de cada una de estas Iteraciones. Diagrama de Casos de Prueba: este artefacto corresponde a un diagrama de casos de prueba almacenado en VISIO. Su propósito es representar la secuencia de aplicación de los casos de prueba elaborados por cada caso de uso sistémico del proyecto. Casos de Prueba: este artefacto corresponde a la especificación unitaria de casos de prueba. Son obtenidos de los casos de uso sistémicos y artefactos a fin del proyecto, constan de datos de entrada, un procedimiento de realización de la prueba, identifica las funcionalidades a probar y los resultados esperados. Cabe mencionar que el equipo del Cliente entrega, cuando estime necesario, casos o escenarios especiales, que considere relevantes para ser ejecutados durante las pruebas funcionales. Corresponde a una planilla Excel almacenada en CVS. Su propósito es declarar los casos de prueba del proyecto que deben ser ejecutados una vez construida la pieza de software. Escenarios Sistémicos: este artefacto corresponde a un modelo de acciones del usuario y del sistema, son obtenidos de los casos de uso sistémicos del proyecto y se almacenan en VISIO. Su propósito es proporcionar visibilidad global del proyecto entrelazando los casos de uso sistémicos del proyecto, logrando así escenarios globales. Datos de Prueba: este artefacto corresponde a los datos que se utilizarán para la ejecución de los casos de prueba, se obtienen de los Casos de Prueba. Corresponde a una planilla Excel almacenada en CVS. Su propósito es identificar las características de los datos de pruebas requeridos para la ejecución de los Casos de Prueba. En los casos en que la obtención de datos presenta inconvenientes o bien se requiere de información asociada a otros actores del sistema, el 17

18 equipo del Cliente aporta su conocimiento y posición para facilitar la obtención o generación de Datos de Prueba. Matriz de Trazabilidad RQ x Casos de Pruebas: este artefacto corresponde a la matriz almacenada en VISIO que es extrapolada de la elaboración de casos de prueba. Su propósito es representar la relación existente entre casos de uso sistémicos y los casos de prueba elaborados. La revisión de cada artefacto se realiza según criterios especificados en las secciones Revisión de Artefactos y Checklist de Revisión de Artefactos. La condición necesaria para la aprobación del cierre de la fase de Elaboración y paso a la fase de Construcción se basa en la completitud, consistencia y claridad lograda, la estabilización del modelado de negocio y análisis, la definición del 100% de los escenarios sistémicos y los indicadores de calidad obtenidos según revisión de artefactos y riesgos vigentes. Detalle de indicadores de calidad en la sección Indicadores de Calidad 8.3 Fase de Construcción En esta fase la gestión del área SQA tiene como foco principal: Testing de software Elaboración de artefactos de la disciplina de Testing Ejecución de Pruebas de Aceptación con el Cliente Aprobación del cierre de la fase de Construcción y paso a la fase de Transición Artefactos Los artefactos generados y/o actualizados, junto con los que el área SQA revisa por cada disciplina en la fase de Construcción, son los siguientes: 18

19 Artefacto Generado y/o Actualizado Artefacto Validado por el Área SQA Análisis Requerimientos Modelamiento de Negocio Disciplina Modelo de Negocio Modelo de Entidades de Dominio Matriz de Trazabilidad Entidades de Dominio x BP Glosario de Conceptos de Negocio Ficha de Actividades Modelo de Requerimientos Documento de Visión Matriz de Trazabilidad Requerimientos por BP Actas de Aprobación Minuta de Requerimientos de Análisis Modelo de RQ Especificaciones de RQ Diagramas de Actividad de RQ Modelo de Clases de Análisis y Diagramas de Estado Prototipo GUI Diagrama de Navegabilidad Matriz de Trazabilidad de Requerimientos x RQ Matriz de Trazabilidad de Mapeo GUI x RQ Matriz de Trazabilidad de RQ x Clases de Análisis No Aplica No Aplica No Aplica 19

20 Matriz de Trazabilidad de Reportes por RQ Diseño Diagramas de Clases de Diseño y Estados Prototipo de Mitigación de Riesgos Matriz de Trazabilidad Clases de Análisis x Clases de Diseño Matriz de Trazabilidad Clases de Diseño x RQ Diagrama de Tablas Matriz de Trazabilidad Tablas x Clases de Diseño No Aplica Diagrama de Tablas Matriz de Trazabilidad Tablas x Clases de Diseño Implementación Arquitectura Pruebas Aplicación UI Aplicación Negocio Aplicación Reporte Diccionario de Datos de la Aplicación Script de Carga de Datos SAD Software Architecture Description Plan de QA Diagrama de Casos de Prueba Casos de prueba Escenarios Sistémicos Datos de Prueba Reportes de Ejecución de Pruebas Minuta de Prueba de Aceptación Matriz de Trazabilidad RQ x Casos de Pruebas Aplicación UI Aplicación Negocio Aplicación Reporte Diccionario de Datos de la Aplicación Script de Carga de Datos No Aplica Datos de Prueba Reportes de Ejecución de Pruebas Minuta de Prueba de Aceptación 20

21 Despliegue Plan de Despliegue Guía de Usuario Guía de Operaciones Material de Capacitaciones Nota de Entrega Plan de Proyecto Plan de Administración de Requerimientos Plan de Comunicación Plan de Despliegue Guía de Usuario Guía de Operaciones Material de Capacitaciones Nota de Entrega Minuta / Agenda de Reunión Lista de Riesgos Carta Gantt Estado de Avance Plan de Administración de Riesgos Administración de Proyecto Administración Minuta / Agenda de Reunión Lista de Riesgos Carta Gantt Estado de Avance Documento de Lecciones Aprendidas Plan de SCM Repositorio No Aplica En esta fase la disciplina de Pruebas contempla la estabilización del Plan de QA y Datos de pruebas utilizados. El artefacto Reportes de Ejecución de Pruebas elaborado por la disciplina de Testing en esta fase es el resultado del proceso de Testing de Software. La Minuta de Prueba de Aceptación corresponde al resultado de las Pruebas de Aceptación realizadas en conjunto con el Cliente, este proceso es descrito en la sección Pruebas de Aceptación. 21

22 La revisión de cada artefacto se realiza según criterios especificados en las secciones Revisión de Artefactos y Checklist de Revisión de Artefactos. La condición necesaria para la aprobación del cierre de la fase de Construcción y paso a la fase de Transición se basa en la construcción lograda respecto al cumplimiento de las especificaciones y los indicadores de calidad obtenidos según revisión de artefactos, testing de software y riesgos vigentes. Detalle de indicadores de calidad en la sección Indicadores de Calidad. Adicionalmente se debe dar cumplimiento a las Pruebas de Aceptación con el Cliente, proceso que se describe en la siguiente sección Pruebas de Aceptación Pruebas de Aceptación Una vez finalizados los procesos de revisión de artefactos y de testing de software con resultados exitosos, se está en condiciones de realizar las Pruebas de Aceptación con el Cliente. Las Pruebas de Aceptación tienen como finalidad que el Cliente valide y verifique que el sistema o pieza de software se ajuste a sus requerimientos y necesidades. El área SQA lleva a cabo una demostración formal del funcionamiento de la pieza de software. Los participantes requeridos para la ejecución de las Pruebas de Aceptación son: Cliente: Responsable Técnico (Analista SQA) Responsable de Negocio Intesis: Analista SQA Líder de Proyecto Analista Senior 22

23 Analista Programador Dependiendo de la complejidad del componente abordado, aumentará el número de Analistas de Intesis y responsables del Cliente. Las pruebas a realizar en las sesiones de pruebas de aceptación son acordadas previamente entre el área SQA y los Responsables Técnico y de Negocio Cliente, para ello el área SQA realiza una propuesta de los casos de prueba a ejecutar. Esta propuesta es aceptada u objetada por el Cliente. En éste último escenario es el Cliente quien da las directrices para la selección de casos de pruebas a ejecutar o bien propone sus propios casos y datos de prueba. Una vez finalizada la Prueba de Aceptación, el Cliente y demás participantes firman la correspondiente Minuta de Prueba de Aceptación, que contiene las pruebas realizadas y eventuales acuerdos de modificación o incorporación. Si el resultado es exitoso el Cliente aprueba mediante la minuta descrita, el paso a Producción de la pieza de software verificada. Esto según programación acordada. Si el resultado no es satisfactorio el Cliente indica las razones del rechazo del paso a Producción de la pieza de software y se establecen acuerdos de plazos y condiciones para una posterior demostración formal del funcionamiento de la pieza de software. 8.4 Fase de Transición En esta fase la gestión del área SQA tiene como foco principal: Verificar el correcto funcionamiento de la aplicación, para su paso a producción. Preparar ambiente de Pruebas 23

24 Aprobación Pruebas de Componentes Artefactos Los artefactos generados y/o actualizados, junto con los que el área SQA revisa por cada disciplina en la fase de Transición, son los siguientes: Artefacto Generado y/o Actualizado Artefacto Validado por el Área SQA Análisis Requerimientos Modelamiento de Negocio Disciplina Modelo de Negocio Modelo de Entidades de Dominio Matriz de Trazabilidad Entidades de Dominio x BP Glosario de Conceptos de Negocio Ficha de Actividades Modelo de Requerimientos Documento de Visión Matriz de Trazabilidad Requerimientos por BP Actas de Aprobación Minuta de Requerimientos de Análisis Modelo de RQ Especificaciones de RQ Diagramas de Actividad de RQ No Aplica No Aplica No Aplica 24

25 Diseño Modelo de Clases de Análisis y Diagramas de Estado Prototipo GUI Diagrama de Navegabilidad Matriz de Trazabilidad de Requerimientos x RQ Matriz de Trazabilidad de Mapeo GUI x RQ Matriz de Trazabilidad de RQ x Clases de Análisis Matriz de Trazabilidad de Reportes por RQ Diagramas de Clases de Diseño y Estados Prototipo de Mitigación de Riesgos Matriz de Trazabilidad Clases de Análisis x Clases de Diseño Matriz de Trazabilidad Clases de Diseño x RQ Diagrama de Tablas Matriz de Trazabilidad Tablas x Clases de Diseño No Aplica No Aplica Implementación Arquitectura Aplicación UI Aplicación Negocio Aplicación Reporte Diccionario de Datos de la Aplicación Script de Carga de Datos SAD Software Architecture Description No Aplica 25

26 Pruebas Despliegue Plan de QA Diagrama de Casos de Prueba Casos de prueba Escenarios Sistémicos Datos de Prueba Reportes de Ejecución de Pruebas Minuta de Prueba de Aceptación Matriz de Trazabilidad RQ x Casos de Pruebas Plan de Despliegue Guía de Usuario Guía de Operaciones Material de Capacitaciones Nota de Entrega Plan de Proyecto Plan de Administración de Requerimientos Plan de Comunicación Reportes de Ejecución de Pruebas Minuta de Prueba de Aceptación Nota de Entrega Minuta / Agenda de Reunión Lista de Riesgos Carta Gantt Estado de Avance Documento de Lecciones Aprendidas Plan de Administración de Riesgos Administración de Proyecto Minuta / Agenda de Reunión Lista de Riesgos Carta Gantt Estado de Avance Documento de Lecciones Aprendidas 26

27 Administración Plan de SCM Repositorio No Aplica 27

28 8.4.2 Workflow Pruebas de Aceptación La interacción dada en las Pruebas de Aceptación se puede visualizar en el siguiente flujo de trabajo: 28

29 Definición de las Pruebas de Aceptación El analista SQA se comunica con los Responsables de Negocio y Técnico del Proyecto, indicando propuesta de pruebas a realizar detallando datos utilizados y transacciones a ejecutar Responsables de Negocio y Técnico Cliente. indican pruebas a realizar Los Responsables de Negocio y Usuarios Proy. indican las pruebas que desean realizar en la sesión de Pruebas de Aceptación No Responsables de Cliente aceptan prueba propuesta? Si Coordinación Prueba de Aceptación Se acuerda fecha, hora y lugar de la Prueba de Aceptación entre los participantes: Responsable Técnico. - Responsable de Negocio - Analista SQA - Líder de Proyecto Analista Senior - Analista Programador El Analista SQA prepara datos y verifica ambiente y parametrización de acuerdo a las pruebas a realizar Realización de la Prueba de Aceptación Se llevan a cabo las pruebas acordadas con Cliente Generación de Minuta con Observaciones El analista SQA genera minuta detallando las pruebas realizadas y resultado de las mismas, indicando las observaciones del Cliente y acuerdos relacionados indicados por el líder de proyecto Si Existen observaciones del Cliente tras las pruebas realizadas? No Los Responsables del Cliente señalan que las observaciones detectadas impiden la aprobación de la componente? Generación de Minuta sin observaciones El analista SQA genera minuta detallando las pruebas realizadas y resultado de las mismas No Si Firma de Minuta de Acuerdos Los participantes de la sesión firman minuta de acuerdo donde se indica la razón del rechazo por parte del Cliente del paso a Producción y se indican plazos para la posterior prueba de aceptación con las observaciones del Cliente aplicadas Firma de Minuta de Aprobación Los participantes de la sesión firman minuta de aceptación donde se aprueba el paso a Producción del componente probado 29

30 9 Revisión de Artefactos y Pruebas de Software Para que un proceso de calidad sea efectivo es necesario definir los criterios de evaluación, los cuales se encuentran relacionados con el tipo de verificación, revisión de artefactos o pruebas de software. 9.1 Revisión de Artefactos El proceso de revisión de artefactos se relaciona con la verificación de especificaciones, las cuales son generadas desde la fase de incepción en adelante, las consideraciones de este proceso se detallan a continuación Criterios de Revisión En el proceso de revisión de artefactos se consideran los siguientes criterios: Claridad y Simplicidad El artefacto debe ser preciso y entendible. Completitud El artefacto no debe contener ambigüedades, ni temas sin resolver, en el caso de existir pendientes debe explicitar responsable y fecha de solución. Adicionalmente no debe contener términos del tipo: 30

31 o Términos vagos: algún, a veces, a menudo, usualmente, en general, etc. La ocurrencia debe estar explicitada y fundamentada o Comparaciones ambiguas: más alto, más bajo, mayor, menor, máximo, mínimo. Las comparaciones deben ser fundamentadas respecto a. o Rangos No definidos: Los valores varían entre 1 y 100, etc. Los rangos deben ser claramente definidos explicitando consideraciones del tipo: los valores son enteros, reales, etc. o Cálculos No definidos: [(a+b-c)*d]/e. Los cálculos deben explicitar el tratamiento numérico, correspondientes a la acción de redondear, truncar o aproximar según corresponda. Consistencia Los artefactos se encuentran relacionados entre sí. No deben existir inconsistencias y deben utilizar los mismos conceptos. Las referencias descritas deben ser correctas y no deben existir elementos contradictorios. Redacción El artefacto debe estar escrito respetando un lenguaje claro, siempre en tercera persona y tiempo verbal presente, no se deben utilizar términos persuasivos (ciertamente, claramente, obviamente, se deduce que, etc.), los términos utilizados deben ser expuestos en un lenguaje cordial. Ortografía El artefacto no debe contener faltas de ortografía. Correctitud El artefacto debe ser consecuencia de los requerimientos y formar parte de la especificación global del producto a construir, manteniendo uniformidad con las técnicas, términos utilizados, notaciones definidas en templates y guías oficializadas. Trazabilidad Los artefactos deben mantener en su desarrollo la correspondiente trazabilidad con los demás artefactos. 31

32 9.1.2 Catalogación de Observaciones Las observaciones detectadas en el proceso de revisión de artefactos, podrán ser catalogadas en tres niveles de severidad: Grave, Mediana y Menor, cuya clasificación dependerá de la magnitud del error cometido. A continuación se grafica la relación entre criterio y severidad: CRITERIO SEVERIDAD Grave Mediana Menor Claridad y Simplicidad X X Completitud X X Consistencia X X Redacción X X X Ortografía X X Correctitud X X Trazabilidad X X 32

33 9.1.3 Criterios de Aprobación Un artefacto será aprobado si y sólo si NO posee observaciones de severidad Grave ni observaciones de severidad Mediana Workflow de Revisión de Artefactos Para lograr mayor efectividad en el proceso de revisión de artefactos, se requiere la participación del analista SQA en reuniones de trabajo previas a la entrega oficial de artefactos al área SQA de cada disciplina. Una vez efectuadas estas reuniones el Workflow de Revisión de Artefactos es el siguiente: 33

34 Recepción de Artefactos La solicitud la realiza la disciplina solicitante a través del Jira indicando ubicación de los artefactos con su respectivo Tag CVS y VISIO, asignando la solicitud al analista SQA definido para el proyecto en cuestión Reunión de exposición de artefactos La disciplina presenta los artefactos al analista SQA, señalando consideraciones especiales y cualquier tema que considere relevante para la revisión Revisión de artefactos El analista SQA realiza la revisión conforme a los criterios y checklist definidos Existen observaciones? No Si Reunión de entrega y resolución de observaciones El analista SQA presenta a la Disciplina las observaciones detectadas, acordando cada una en el transcurso de la reunión Registro de conformidad de artefactos El analista SQA registra la conformidad del área SQA con los artefactos revisados en el requerimiento Jira y procede a resolverlo Existen observaciones que generan modificaciones? No Cierre del Requerimiento de revisión La Disciplina cierra el requerimiento de revisión Si Registro de modificaciones acordadas El analista SQA registra los acuerdos en el requerimiento Jira y lo asigna al responsable de la Disciplina 34

35 9.1.5 Workflow de Reporte de Observaciones Las observaciones detectadas en el proceso de revisión de artefactos, son reportadas en el siguiente Workflow de estados: EP Ingresar Open EP inválidar Inválido ESQA revisar EP revisar Corregido EP corregido En revisión ESQA cerrar ESQA corregir En corrección Cerrado EP: Equipo Proyecto ESQA: Equipo SQA Nota: En todos los estados se podrá reasignar a otro responsable, ingresar un comentario, adjuntar archivos, Linkear a otros issues o editar los mismos

36 9.1.6 Workflow de Revisión de Prototipos de Mitigación El Workflow de Revisión de Prototipos de Mitigación de Riesgos es el siguiente: Solicitud de prueba de prototipo de mitigación de riesgo La solicitud la realiza la disciplina de Diseño a través de Jira indicando ubicación de artefactos asociados con su respectivo Tag CVS y VISIO, asignando la solicitud al analistas SQA definido para el proyecto en cuestión Reunión de coordinación de prueba Los analistas de SQA y Diseño se reunen para afinar condiciones de la prueba, esclarecer objetivos, coordinar tiempos y establecer criterios de revisión Revisión de prototipo El analista SQA realiza la revisión conforme a los criterios acordados Reporte de Ejecución de la prueba El analista SQA adjunta el reporte del resultado de las pruebas en el requerimiento Jira y lo deja en estado resuelto Si Presentación del resultado de la prueba El analista SQA presenta al analista de Diseño solicitante el resultado de la prueba Cierre del requerimiento El analista programador procede a cerrar el requerimiento de prueba de prototipo de mitigación de riesgo Se requiere de una nueva prueba? No 36

37 9.2 Testing de Software El proceso de testing de software se relaciona con la verificación de la pieza de software construida según las especificaciones generadas desde la fase de incepción en adelante, las consideraciones de este proceso se detallan a continuación Criterios de Testing de Software Los factores de calidad que son considerados en el modelo de calidad para el testing de una pieza de software son: Confiabilidad Se refiere a la fiabilidad en el funcionamiento del producto. El producto es capaz de funcionar sin errores en cualquier circunstancia y siempre de acuerdo a las especificaciones definidas. Seguridad Considera si el producto de software, de acuerdo a las especificaciones definidas, contempla todos los aspectos de seguridad necesarios para garantizar el control de acceso y manejo de datos en el sistema. Usabilidad Se relaciona con la cantidad de esfuerzo requerido para aprender a utilizar o manejar el producto. La pieza de software debe responder a los estándares de usabilidad definidos para el proyecto. Integridad entre componentes Se refiere a la correcta operación de la pieza de software en conjunto con otros componentes o módulos. La pieza de software debe procurar integridad dentro del sistema como también con sistemas externos, según corresponda. Verificabilidad 37

38 Se refiere a que la pieza de software debe ser verificable de acuerdo a las especificaciones definidas. Precisión Se refiere a que la pieza de software debe proporcionar el grado de certeza requerido en los cálculos que contempla, de acuerdo a las especificaciones definidas. Mantenimiento Se relaciona con la capacidad de localizar y corregir defectos una vez que el producto esta funcionando Catalogación de Defectos Un defecto generado tras el testing de software es producto de una desviación de la construcción e implementación respecto a las especificaciones definidas. Los defectos detectados en el proceso de testing de software, podrán ser catalogados en cuatro niveles de severidad, cuya clasificación dependerá del grado de desviación que la pieza de software presenta respecto de las especificaciones definidas y del alcance del defecto sobre el testing. Severidad Descripción Crítico El defecto impide acceder a la funcionalidad. Las pruebas de la pieza de software deben suspenderse. El defecto no permite continuar la operación del sistema. 38

39 Grave Es posible acceder a la funcionalidad, pero la misma no puede ser ejecutada en forma completa. La ejecución de la prueba no cumple con el resultado esperado. Existe una severa desviación respecto a los requerimientos. El defecto restringe la ejecución de gran parte de la funcionalidad definida. No existe un camino alternativo de solución. Mediano Es posible acceder a la funcionalidad, ésta no se ejecuta completamente o no cumple con el resultado esperado, pero existe un camino alternativo para cumplir la funcionalidad. Menor El defecto no afecta el correcto funcionamiento de la aplicación. No es crítico para el desempeño del usuario ni afecta la información del sistema Criterios de Aprobación Un proceso de testing se ejecuta con la intención de asegurar el correcto funcionamiento de una pieza de software. Esta fase puede llevar días, meses y hasta años, sin embargo; Cómo saber cuándo es necesario dejar de hacer pruebas?. Normalmente para tomar esta decisión es necesario definir anticipadamente el grado de exigencia funcional y los criterios de aprobación de la pieza de software. A continuación se proponen los siguientes criterios de aprobación, los cuales indicarán las condiciones necesarias que se deben cumplir en el proceso de testing para que éste sea considerado satisfactorio. 39

40 Resultados Resultados En el proceso de En el proceso de Aprobación Resultado de Pruebas sin Defectos de Pruebas con Defectos Menores (%) de Pruebas con Defectos Medianos o Graves (SI/NO) Pruebas recaban Nuevos Alto Impacto (SI/NO) se Req. Pruebas recaban Nuevos Impacto (SI/NO) se Req. Bajo (SI/NO) 100% 0% NO NO NO SI 80% < 20% NO NO NO SI 80% < 20% NO NO SI SI SI - NO - - SI - - NO - > 20% NO Se define como un nuevo requerimiento a toda funcionalidad del Sistema que no se encuentra especificada en los artefactos de análisis generados y aprobados por el Cliente. Los nuevos requerimientos serán tipificados según el impacto que provocan en el sistema, de la siguiente manera: Tipo Descripción 40

41 Nuevo Requerimiento Alto Impacto Nuevo Requerimiento El requerimiento impacta fuertemente en la funcionalidad del componente. El esfuerzo de implementarlo en esta etapa es grande El requerimiento es de bajo impacto en la funcionalidad del Bajo Impacto componente. El esfuerzo de implementarlo en esta etapa podría no ser importante. En función a las definiciones anteriores, las piezas de software serán aprobadas cuando: No existan defectos Medianos No existan defectos Graves No existen defectos Menores detectados en más del 20% de las pruebas No existan Nuevos Requerimientos de Alto impacto Una vez que la pieza de software se encuentre aprobado, se está en condiciones de llevar a acabo las Pruebas de Aceptación con el Cliente. Sección Pruebas de Aceptación no se encontró documento 41

42 9.2.4 Workflow de Testing de Software El Workflow de Testing de Software es el siguiente: Recepción de la pieza de software La solicitud la realiza la disciplina de despliegue, adjuntando la correspondiente Nota de Entrega y asignando la solicitud al analista SQA definido para el proyecto Prueba de Humo El analista SQA realiza una prueba de humo a fin de verificar la versión entregada cumple con las funcionalidades mínimas para dar inicio a las pruebas Registro del rechazo del testing de software El analista SQA registra el rechazo de la pieza de software en el requerimiento y procede Rechazar Test Funcional adjuntando el Reportes de Ejecución de Pruebas No Prueba de Humo exitosa? Solicitud de carga de datos El analista SQA solicita la carga de datos de prueba a analistas programador Si Si Carga de Datos El analista programador realiza la carga de datos Se requiere carga de datos? Revisión de Carga de Datos El analista SQA verifica la carga de datos No No Revisión de artefactos El analista SQA realiza el testing conforme al Plan de QA, Escenarios Sistémicos y Casos de Prueba elaborados Si La carga de datos es correcta? No Existen defectos? Si No Registro de aprobación de la pieza de software El analista SQA registra la aprobación de la pieza de software y procede Aprobar Test Funcional Reporte de defecto en circuito Jira El analista SQA reporta los defectos detectados según catalogación correspondiente La versión cumple los criterios de aprobación? Si Paso a producción La disciplina de Despliegue prepara la entrega formal de la pieza de software al cliente, junto con la migración de datos requerida y la correspondiente capacitación al usuario 42

43 9.2.5 Workflow de Reporte de Defectos Los defectos detectados en el proceso de testing de software son reportados en el siguiente Workflow de estados: ESQA Ingresar Open ESQA inválidar Inválido EI corregir EI posponer EI corregir Pospuesto En corrección ESQA re-corregir EI resolver Resuelto ESQA cerrar Cerrado EI: Equipo Implementación ESQA: Equipo SQA Nota: En todos los estados se podrá reasignar a otro responsable, ingresar un comentario, adjuntar archivos, Linkear a otros issues o editar los mismos. 43

44 9.3 Indicadores de Calidad La disciplina de testing es la responsable de evaluar la calidad durante todo el ciclo de vida del proyecto, a fin de proporcionar información que permita generar las acciones oportunas de mejoras sobre puntos deficitarios, con el objetivo de asegurar la calidad y no alterar las variables de tiempo y costo. Para medir la calidad se requiere recopilar y analizar información, la cual da origen a los indicadores de calidad. Para el proceso de revisión de artefactos y testing de software, la medida de la calidad nace de la recopilación de la siguiente información: Observaciones en la revisión de artefactos, acordadas por artefacto y por nivel de severidad Defectos en el testing de software, detectados por versión y por nivel de severidad Riesgos detectados por fase De este modo se tienen los siguientes indicadores de calidad: Indicadores de Calidad para el proceso de Testing de Software ISi: Índice de Calidad de la pieza de software, testing versión i La medición del Índice de Calidad, por cada versión de pieza de software, en cada fase, está dada por la distribución de defectos detectados, considerando severidad y tamaño del artefacto. 44

45 ISi: Índice de Calidad versión i. Di: Nº total de defectos encontrados durante la versión desarrollada de la pieza de software. Ci: Nº total de defectos críticos detectados en la versión i. Gi: Nº total de defectos graves detectados en la versión i. Mdi: Nº total de defectos medianos detectados en la versión i. Mei: Nº total de defectos menores detectados en la versión i. Pj: Ponderación para defectos críticos, graves, medianos y menores, donde j=1, 2, 3, 4. Ci Gi Mdi Mei IS i P1 P2 P3 P4 Di Di Di Di Este índice demuestra mayor calidad del artefacto mientras más se acerque a cero Índice de Calidad iteraciones de la pieza de software La medición del índice de calidad, en la iteración de versiones, en cada fase, está dado por el efecto acumulativo de cada ISi, que se obtiene asignando un peso mayor a los defectos detectados en versiones posteriores de la pieza de software. n i * ISi i IDS 1 Ps 45

46 Donde, Ps: Tamaño del producto (cantidad de casos de prueba asociados) en la versión i. n: Número de iteraciones de la pieza de software Este índice demuestra mayor calidad del artefacto mientras más se acerque a cero Índice de estado de los defectos detectados Este índice corresponde a la cantidad de defectos vigentes; es decir aquellos defectos que se han reportado y sobre los cuales no se ha obtenido respuesta en un transcurso de 3 días hábiles. La medición del estado de defectos detectados, permite visualizar cuándo se requieren recursos adicionales, en la disciplina de Diseño, para la resolución de defectos. Este índice demuestra correcta dotación de recursos, si los defectos detectados sin respuesta, en el transcurso de 3 días hábiles, tienden a cero Índice de Riesgos Mensual En el transcurso del proyecto, toda disciplina debe levantar los riesgos que visualice que comprometen el correcto desarrollo del proyecto y que afectan las variables de tiempo y costo. Estos riesgos son asignados al responsable correspondiente. El índice de riesgos se obtiene de la identificación de los riesgos levantados asociados al proyecto en un mes. Se consideran los estados: Riesgos Atendidos y Riesgos No Atendidos. Donde Riesgos 46

47 No Atendidos corresponden a aquellos que no se encuentran solucionados ni están en vías de solución. De este modo para el mes m se tiene el siguiente Índice de Riesgos Mensual: IR m RiesgosNoAtendidos m TotalRiesgosDetectados m Este índice resulta aceptable, cuando los riesgos se encuentran resueltos o en proceso de solución en un porcentaje mayor o igual al 80%, esto es: IR m 0,2. 10 Checklist de Revisión de Artefactos En los checklist para la revisión de artefactos se encuentran los principales puntos a verificar en la revisión de cada artefacto, los cuales son generados y/o actualizados en cada fase del proyecto según lo descrito en la sección Gestión Área SQA Los niveles de error definidos para la revisión de artefactos son: 47

48 Nivel de Error Descripción 1 Observación Grave 2 Observación Mediana 3 Observación Menor 48