INTRODUCCIÓN REVISIÓN DE ARTEFACTOS Y PRUEBAS DE SOFTWARE REVISIÓN DE ARTEFACTOS CRITERIOS DE REVISIÓN...

Transcripción

1 S GESTIÓN SQA

2 Tabla de Contenido INTRODUCCIÓN REVISIÓN DE ARTEFACTOS Y PRUEBAS DE SOFTWARE REVISIÓN DE ARTEFACTOS CRITERIOS DE REVISIÓN CATALOGACIÓN DE OBSERVACIONES CRITERIOS DE APROBACIÓN WORKFLOW DE REVISIÓN DE ARTEFACTOS WORKFLOW DE REPORTE DE OBSERVACIONES WORKFLOW DE REVISIÓN DE PROTOTIPOS DE MITIGACIÓN TESTING DE SOFTWARE CRITERIOS DE TESTING DE SOFTWARE CATALOGACIÓN DE DEFECTOS CRITERIOS DE APROBACIÓN WORKFLOW DE TESTING DE SOFTWARE WORKFLOW DE REPORTE DE DEFECTOS INDICADORES DE CALIDAD INDICADORES DE CALIDAD PARA EL PROCESO DE TESTING DE SOFTWARE ÍNDICE DE CALIDAD ITERACIONES DE LA PIEZA DE SOFTWARE ÍNDICE DE ESTADO DE LOS DEFECTOS DETECTADOS ÍNDICE DE RIESGOS MENSUAL

3 4.7 CHECKLIST DE REVISIÓN DE ARTEFACTOS GESTIÓN ÁREA SQA FASE DE INICIO ARTEFACTOS FASE DE ELABORACIÓN ARTEFACTOS FASE DE CONSTRUCCIÓN ARTEFACTOS PRUEBAS DE ACEPTACIÓN WORKFLOW PRUEBAS DE ACEPTACIÓN FASE DE TRANSICIÓN ARTEFACTOS PLAN SQA EQUIPO QA INTERNO

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 pruebas 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 pruebas o a la verificación de las piezas de software. A continuación, se describen algunos elementos estructurales de la metodología de SQA usada y recomendada por Intesis S.A. 4

5 2 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. 2.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. 2.2 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: Términos vagos: algún, a veces, a menudo, usualmente, en general, etc. La ocurrencia debe estar explicitada y fundamentada Comparaciones ambiguas: o más alto, más bajo, mayor, menor, máximo, mínimo. Las comparaciones deben ser fundamentadas respecto a. 5

6 Rangos No definidos: o 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. Cálculos No definidos: o [(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 o 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 o 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 o El artefacto no debe contener faltas de ortografía. Correctitud 6

7 o 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 o Los artefactos deben mantener en su desarrollo la correspondiente trazabilidad con los demás artefactos. 7

8 3 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 8

9 4 CRITERIOS DE APROBACIÓN Un artefacto será aprobado si y sólo si NO posee observaciones de severidad Grave ni observaciones de severidad Mediana. 4.1 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: 9

10 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 10

11 4.2 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. 11

12 4.3 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 12

13 4.4 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 o 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 o 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 o 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 13

14 o 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 o Se refiere a que la pieza de software debe ser verificable de acuerdo a las especificaciones definidas. Precisión o 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 o Se relaciona con la capacidad de localizar y corregir defectos una vez que el producto está funcionando. 14

15 4.5 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. 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. 15

16 4.5.1 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. Resultados Resultados En el proceso En el proceso Aprobación Resultado de Pruebas sin Defectos de Pruebas con Defectos Menores de Pruebas con Defectos Medianos o Graves de Pruebas se recaban Req. Nuevos Alto Impacto (SI/NO) de Pruebas se recaban Req. Nuevos Bajo Impacto (SI/NO) (SI/NO) (%) (SI/NO) 100% 0% NO NO NO SI 80% < 20% NO NO NO SI 80% < 20% NO NO SI SI SI - NO 16

17 - - 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 Nuevo Requerimiento El requerimiento impacta fuertemente en la funcionalidad Alto Impacto del componente. El esfuerzo de implementarlo en esta etapa es grande Nuevo Requerimiento El requerimiento es de bajo impacto en la funcionalidad Bajo Impacto del 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 17

18 No existan Nuevos Requerimientos de Alto impacto Una vez que la pieza de software se encuentre aprobado, se está en condiciones de llevar a cabo las Pruebas de Aceptación con el Cliente. 18

19 4.5.2 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 19

20 4.5.3 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. 20

21 4.6 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 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. 21

22 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. 22

23 n i * ISi i IDS 1 Ps 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 23

24 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, 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: Nivel de Error Descripción 1 Observación Grave 2 Observación Mediana 3 Observación Menor 24

25 5 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 en el proyecto, desde la fase de Inicio hasta la fase de Transición. 5.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 25

26 Análisis Requerimientos Modelamiento de Negocio Disciplina 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 Modelo de Negocio Modelo de Entidades de Dominio Matriz de Trazabilidad Entidades de Dominio x BP Glosario de Conceptos de Negocio 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 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 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 26

27 Pruebas Arquitectura Implementación Diseño 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 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 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 SAD Software Architecture Description 27 Plan de QA Diagrama de Casos de Prueba Casos de prueba Escenarios Sistémicos Datos de Prueba Formularios de Reportes de Ejecución de Pruebas Minuta de Prueba de Aceptación Plan de QA Diagrama de Casos de Prueba Casos de prueba Escenarios Sistémicos Datos de Prueba Formulario Reportes de Ejecución de Pruebas Matriz de Trazabilidad RQ x Casos de

28 Administración de la configuración Administración de Proyecto Despliegue 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 Pruebas No aplica Plan de Proyecto Plan de Administración de Requerimientos Plan de Comunicación Plan de Administración de Riesgos 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 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. 28

29 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 Formulario 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 Formulario 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 5.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: 29

30 Análisis Requerimientos Modelamiento de Negocio Disciplina Artefacto Generado y/o Actualizado Artefacto Validado por el Área SQA Modelo de Negocio Modelo de Entidades de Dominio Matriz de Trazabilidad Entidades de Dominio x BP Glosario de Conceptos de Negocio Ficha de Actividades No Aplica Modelo de Requerimientos Documento de Visión Matriz de Trazabilidad Requerimientos por BP Actas de Aprobación Minuta de Requerimientos de Análisis No Aplica 30 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 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

31 Pruebas Arquitectura Implementación Diseño 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 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 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 SAD Software Architecture Description Plan de QA Diagrama de Casos de Prueba Casos de prueba Escenarios Sistémicos Datos de Prueba Formulario Reportes de Ejecución de Pruebas Minuta de Prueba de Aceptación Plan de QA Diagrama de Casos de Prueba Casos de prueba Escenarios Sistémicos Datos de Prueba Formulario Reportes de Ejecución de Pruebas Matriz de Trazabilidad RQ x Casos de 31

32 Administración de la Configuración Administración de Proyecto Despliegue 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 Pruebas No aplica Minuta / Agenda de Reunión Lista de Riesgos Carta Gantt Estado de Avance Riesgos Plan de Administración de 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 Formulario 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 Formulario Reporte de Ejecución de Pruebas es informar las 32

33 pruebas ejecutadas y resultados obtenidos, indicando, si existiera, el desvío de los resultados esperados. 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 33

34 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 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. 5.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 34

35 Análisis Requerimientos Modelamiento de Negocio Disciplina 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: Artefacto Generado y/o Actualizado Artefacto Validado por el Área SQA Modelo de Negocio Modelo de Entidades de Dominio Matriz de Trazabilidad Entidades de Dominio x BP Glosario de Conceptos de Negocio Ficha de Actividades No Aplica 35 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 No Aplica No Aplica

36 Arquitectura Implementación Diseño 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 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 Diagrama de Tablas Matriz de Trazabilidad Tablas x Clases de Diseño Aplicación UI Aplicación Negocio Aplicación Reporte Diccionario de Datos de la Aplicación Script de Carga de Datos No Aplica 36

37 Administración de la Configuración Administración de Proyecto Despliegue Pruebas 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 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 Datos de Prueba Reportes de Ejecución de Pruebas Minuta de Prueba de Aceptació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 No Aplica 37

38 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. 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 38

39 Intesis: Analista SQA Líder de Proyecto Analista Senior 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. 39

40 5.3.3 WORKFLOW PRUEBAS DE ACEPTACIÓN La interacción dada en las Pruebas de Aceptación se puede visualizar en el siguiente flujo de trabajo: 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 40

41 Requerimientos Modelamiento de Negocio Disciplina 5.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 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 Modelo de Negocio Modelo de Entidades de Dominio Matriz de Trazabilidad Entidades de Dominio x BP Glosario de Conceptos de Negocio Ficha de Actividades No Aplica Modelo de Requerimientos Documento de Visión Matriz de Trazabilidad Requerimientos por BP Actas de Aprobación Minuta de Requerimientos de Análisis No Aplica 41

42 Implementación Diseño 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 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 No Aplica Aplicación UI Aplicación Negocio Aplicación Reporte Diccionario de Datos de la Aplicación 42

43 Administración de Proyecto Despliegue Pruebas Arquitectura Script de Carga de Datos SAD Software Architecture Description No Aplica 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 Plan de Administración de Riesgos Minuta / Agenda de Reunión Lista de Riesgos Carta Gantt Estado de Avance Documento de Lecciones Aprendidas 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 43

44 Administración de la Configuración Plan de SCM Repositorio No Aplica 44

45 7 PLAN SQA El propósito del Plan SQA 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. Este plan 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. 45.

46 8 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. 46