Plan-de-sqa.pdf m4o3s

Proyecto ScrumCeption

Plan de SQA

Hernán Esteves 18 de octubre de 2015

Historia de revisiones Fecha de la revisión

Versión

28/08/15 28/08/15 29/08/15 30/08/15

1.0 1.1 1.2 1.3

05/09/15

2.0

Descripción

Autor

Version inicial Atributos de calidad definidos Agregados estándares Revisioón SQA - Agregado estándar de documentación Nuevos estándares de documentación.

Hernán Esteves Hernán Esteves Hernán Esteves Hernán Esteves Hernán Esteves

Removidos de la documentación mínima: Reportes de V&V. Documentación de . Descripción del diseño. 06/09/15 18/10/15

2.1 2.2

RTF ajustado Actualización (RTF reemplazado por inspecciones periódicas)

Q : Nuevo contenido en esta versión.

Hernán Esteves Hernán Esteves

Hernán Esteves

Índice 1. Propósito

3

2. Referencias

3

3. Gestión 3.1. Organización . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2. Actividades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.1. Ciclo de vida del software cubierto por el Plan . . . . . . . 3.2.2. Actividades de calidad a realizarse . . . . . . . . . . . . . . 3.2.3. Revisar cada producto . . . . . . . . . . . . . . . . . . . . . 3.2.4. Revisar ajuste al proceso . . . . . . . . . . . . . . . . . . . 3.2.5. Q Realizar inspecciones de código . . . . . . . . . . . . . . 3.2.6. Asegurar que las desviaciones son documentadas . . . . . 3.2.7. Relaciones entre las actividades de SQA y la planificación 3.2.8. Responsables . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

3 3 4 4 4 5 5 5 6 6 6

4. Documentación 4.1. Propósito . . . . . . . . . . . . . . . . . . . . . . . . . 4.2. Documentación mínima requerida . . . . . . . . . . . 4.2.1. Especificación de requerimientos del software 4.2.2. Plan de V&V . . . . . . . . . . . . . . . . . . . 4.2.3. Plan de Gestión de configuración . . . . . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

6 6 6 6 8 8

5. Estándares, prácticas, convenciones y métricas 5.1. Estándar de documentación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2. Estándar de verificación y prácticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8 8 8

6. Revisiones y auditorías 6.1. Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2. Requerimientos mínimos . . . . . . . . . . . . . . . . 6.2.1. Revisión de requerimientos . . . . . . . . . . . 6.2.2. Revisión de diseño y arquitectura . . . . . . . . 6.2.3. Revisión del Plan de Verificación & Validación 6.2.4. Auditoría funcional . . . . . . . . . . . . . . . . 6.2.5. Auditoría física . . . . . . . . . . . . . . . . . . 6.2.6. Auditorías internas al proceso . . . . . . . . . . 6.2.7. Revisiones de gestión . . . . . . . . . . . . . . 6.2.8. Revisión del Plan de gestión de configuración . 6.2.9. Revisión Post Mortem . . . . . . . . . . . . . . 6.3. Agenda . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . .

. . . . . . . . . . . .

. . . . .

. . . . . . . . . . . .

. . . . .

. . . . . . . . . . . .

. . . . .

. . . . . . . . . . . .

. . . . .

. . . . . . . . . . . .

. . . . .

. . . . . . . . . . . .

. . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

9 9 9 9 9 9 9 9 9 9 10 10 10

7. Reporte de problemas y acciones correctivas

10

8. Gestión de riesgos

10

Plan de SQA

2

Hernán Esteves

1.

Propósito El producto será una herramienta que se encargue de obtener métricas de los proyectos que utilizan metodologías ágiles desde distintas fuentes, las procese, y exponga de una manera amigable al . Además, debe permitir configurar las métricas a observar según las diferentes etapas de un proyecto, entre otros detalles. El propósito del documento es establecer un plan a seguir para asegurar que el producto obtenido cumple con un mínimo estándar de calidad aceptable abarcando todos los sprints del desarrollo.

2.

Referencias Documentos de la memoria de 2014 (grupo 3 y 5). ISO/IEC 9126.

3.

Gestión La gestión de la calidad estará a cargo del responsable de SQA, cuyo deber es determinar los estándares de calidad que deben cumplirse y asegurar su cumplimiento. El responsable de V&V estará también involucrado en la gestión de calidad ya que los requisitos no funcionales deben ser testeados mediante distintas pruebas.

3.1.

Organización Los roles definidos son: Rol Scrum Master Desarrolador Responsable de SCM, Desarrollador Responsable de SQA, Desarrollador Desarrollador Diseñador de Interfaz, Desarrollador Responsable de verificación, Desarrollador Asistente de Comunicación, Desarrollador Arquitecto , Desarrollador Diseñador de Interfaz, Desarrollador Documentador de , Desarrollador Responsable de integración, Desarrollador

Nombre Matias Rodal Medina Hector Barrios Olascuaga Marco Centurión Virdo Hernan Esteves Rosano Juan Andrés Friss de Kereki Carlos Enrique Huerta Santana Fabián Larrañaga Fagián Octavio Pérez Kempner Federico Kauffman Piñeiro Gonzalo Rosso Alfonso José Diego Suárez Hernández Nicolás Tabaré Tomeo Raspino

Las líneas de trabajo definidas para controlar la calidad: Plan de SQA

3

Hernán Esteves Relevamiento de requisitos y análisis: Sera necesario relevar la mayor cantidad de requisitos no funcionales y que por ende impliquen ciertos atributos de calidad. Diseño y arquitectura En el diseño y arquitectura se deberán realizar monitoreos de SQA para poder prever que tenga cierto impacto negativo en los atributos de calidad. Implementación El cliente ha proporcionado un estándar de codificación que deberá cumplirse. Verificación Se trabajará en conjunto con el responsable de Verificación con el fin de asegurar que el producto cumple con lo que debe realizar y con sus atributos de calidad. Gestión el proyecto El responsable de SQA deberá notificar al Scrum Master cuando se detecten desvíos en el plan de calidad para que pueda tomar las medidas necesarias. Gestión de configuración Se trabajará en conjunto con el responsable de SCM para asegurar la calidad de la configuración.

3.2. 3.2.1.

Actividades Ciclo de vida del software cubierto por el Plan Se realizarán revisiones de todos los documentos que se deban entregar en la semana. El responsable de SQA revisará todos aquellos documentos que sean enviados para su revisión hasta el sábado de cada semana. Los demás serán entregados, pero no quedarán revisados en esa entrega. Se realizarán revisiones sobre el código también y sobre los procesos usados. Por lo tanto, el plan cubre las etapas de requisitos, análisis, diseño, implementación y verificación.

3.2.2.

Actividades de calidad a realizarse Las tareas a ser llevadas a cabo deberán reflejar las evaluaciones a realizar, los estándares a seguir, los productos a revisar, los procedimientos a seguir en la elaboración de los distintos productos y los procedimientos para informar de los defectos detectados a sus responsables y realizar el seguimiento de los mismos hasta su corrección. Las actividades que se realizarán son: Historias a Verificar: Revisar cada producto

Plan de SQA

4

Hernán Esteves Revisar el ajuste al proceso Realizar inspecciones de código. Asegurar que las desviaciones son documentadas. 3.2.3.

Revisar cada producto En esta actividad se revisan los productos que se definieron como claves para verificar en el Plan de calidad. Se debe verificar que no queden correcciones sin resolver en los informes de revisión previos, si se encuentra alguna no resuelta, debe ser incluida en la siguiente revisión. Se revisan los productos contra los estándares. Se debe identificar, documentar y seguir la pista a las desviaciones encontradas y verificar que se hayan realizado las correcciones. Como salida se obtiene el Informe de revisión de SQA, este informe debe ser distribuido a los responsables del producto y se debe asegurar de que son concientes de desviaciones o discrepancias encontradas.

3.2.4.

Revisar ajuste al proceso En esta actividad se revisan los productos que se definieron como claves para verificar el cumplimiento de las actividades definidas en el proceso. Con el fin de asegurar la calidad en el producto final del desarrollo, se deben llevar a cabo revisiones sobre los productos durante todo el ciclo de vida del software. Se debe recoger la información necesaria de cada producto, buscando hacia atrás los productos previos que deberían haberse generado, para poder establecer los criterios de revisión y evaluar si el producto cumple con las especificaciones. Esta información se obtiene de los siguientes documentos: Plan del Proyecto, Plan de la iteración, Plan de Verificación. Antes de comenzar, se debe verificar en los informes de revisión previos que todas las desviaciones fueron corregidas, si no es así, las faltantes se incluyen para ser evaluadas. Como salida se obtiene el Informe de revisión de SQA correspondiente a la evaluación de ajuste al Proceso, este informe debe ser distribuido a los responsables de las actividades y se debe asegurar de que son concientes de desviaciones o discrepancias encontradas.

3.2.5. Q Realizar inspecciones de código El objetivo de la inspección de código es asegurarse de que los estándares de codificación son cumplidos. Además se evaluará que el código sea entendible y tenga una cantidad suficiente de comentarios. En esta actividad también se analizarán que los tests unitarios sean correctos, es decir que cubran el código de forma correcta y no solamente ejecutándolo.

Plan de SQA

5

Hernán Esteves 3.2.6.

Asegurar que las desviaciones son documentadas Las desviaciones encontradas en las actividades y en los productos deben ser documentadas y ser manejadas de acuerdo a un procedimiento establecido. Se debe chequear que los responsables de cada plan los modifiquen cada vez que sea necesario, basados en las desviaciones encontradas.

3.2.7.

3.2.8.

Relaciones entre las actividades de SQA y la planificación

Actividad

Semana de ejecución

Relevamiento de atributos de calidad Plan de calidad Ajuste del plan de calidad Revisión Técnica formal Q Inspección de código Revisar las entregas e informe SQA Revisar ajuste al proceso Evaluar la calidad de los productos Realizar informe final de calidad

2y3 3 4 a 12 4 a 12 7 a 14 Todas 4 a 12 3 a 14 13 y 14

Responsables En todas las actividades mencionadas el responsable es el responsable SQA.

4. 4.1.

Documentación Propósito Identificación de la documentación relativa a desarrollo, Verificación & Validación, uso y mantenimiento del software. Establecer como los documentos van a ser revisados para chequear consistencia: se confirman criterio e identificación de las revisiones.

4.2.

Documentación mínima requerida La documentación mínima es la requerida para asegurar que la implementación logrará satisfacer los requerimientos.

4.2.1.

Especificación de requerimientos del software El documento de especificación de requerimientos deberá describir, de forma clara y precisa, cada uno de los requerimientos esenciales del software además de las interfaces externas.

Plan de SQA

6

Hernán Esteves El cliente deberá obtener como resultado del proyecto una especificación adecuada a sus necesidades en el área de alcance del proyecto, de acuerdo al compromiso inicial del trabajo y a los cambios que este haya sufrido a lo largo del proyecto, que cubra aquellos aspectos que se haya acordado detallar con el cliente. La especificación debe: Ser completa: • Externa, respecto al alcance acordado. • Internamente, no deben existir elementos sin especificar. Ser consistente, no pueden haber elementos contradictorios. Ser no ambigua, todo término referido al área de aplicación debe estar definido en un glosario. Ser verificable, debe ser posible verificar siguiendo un método definido, si el producto final cumple o no con cada requerimiento. Estar acompañada de un detalle de los procedimientos adecuados para verificar si el producto cumple o no con los requerimientos. Incluir requerimientos de calidad del producto a construir. Los requerimientos de calidad del producto a construir son considerados dentro de atributos específicos del software que tienen incidencia sobre la calidad en el uso y se detallan a continuación: Funcionalidad • seguridad de los datos Usabilidad • comprensible • aprendible • operable • atractivo Portabilidad Mantenibilidad • analizable • modificable Cada uno de estos atributos debe cumplir con las normas y regulaciones aplicables a cada uno.

Plan de SQA

7

Hernán Esteves 4.2.2.

Plan de V&V El Plan de V&V deberá identificar y describir los métodos a ser utilizados en: La verificación de que: • los requerimientos descritos en el documento de requerimientos han sido aprobados por una autoridad apropiada. En este caso sería que cumplan con el acuerdo logrado entre el cliente y el equipo. • los requerimientos descritos en el documento de requerimientos son implementados en el diseño expresado en el documento de diseño. • el diseño expresado en el documento de diseño esta implementado en código. Validar que el código, cuando es ejecutado, se adecua a los requerimientos expresados en el documento de requerimientos.

4.2.3.

Plan de Gestión de configuración El Plan de gestión de configuración debe contener métodos para identificar componentes de software, control e implementación de cambios, y registro y reporte del estado de los cambios implementados

5. 5.1.

Estándares, prácticas, convenciones y métricas Estándar de documentación Para los documentos que se entregan semanalmente, se ha definido un nuevo estandar. El estandar incluye el uso de LATEXpara la elaboracion de los mismos. Se ha definido una plantilla base y que se subió al sitio Overleaf.com. En dicho sitio se elaboraran y editarán todos los documentos. En cuanto a los nombres de los documentos se deberá utilizar un prefijo “[Sem X][vY.Y]” seguido del título del documento; X corresponde a la semana de la entrega y Y.Y a la versión del documento. Debido a que el modelo de procesos utilizado es una metodología ágil se priorizará el software funcionando ante la documentación, por lo que se deberá entregar la documentación que sea más importante y necesaria.

5.2.

Estándar de verificación y prácticas Se utilizan las prácticas definidas en el Plan de Verificación y Validación. El cliente ha requerido explícitamente un cubrimiento mínimo del 70 %.

Plan de SQA

8

Hernán Esteves

6. 6.1.

Revisiones y auditorías Objetivo Definición de las revisiones y auditorías técnicas y de gestión que se realizarán. Especificación de cómo serán llevadas a cabo dichas revisiones y auditorías.

6.2. 6.2.1.

Requerimientos mínimos Revisión de requerimientos Esta revisión se realiza para asegurar que se cumplió con los requerimientos especificados por el Cliente.

6.2.2.

Revisión de diseño y arquitectura Esta revisión se realiza para asegurar la consistencia del diseño y arquitectura detallado con la especificación de requerimientos.

6.2.3.

Revisión del Plan de Verificación & Validación Esta revisión se realiza para asegurar la consistencia y completitud de los métodos especificados en el Plan de V & V.

6.2.4.

Auditoría funcional Esta auditoría se realiza previa a la liberación del software, para verificar que todos los requerimientos especificados en el documento de requerimientos fueron cumplidos.

6.2.5.

Auditoría física Esta revisión se realiza para verificar que el software y la documentación son consistentes y están aptos para la liberación.

6.2.6.

Auditorías internas al proceso Estas auditorías son para verificar la consistencia: del código versus el documento de diseño, especificaciones de interfases, implementaciones de diseño versus requerimientos funcionales, requerimientos funcionales versus descripciones de testeo.

6.2.7.

Revisiones de gestión Estas revisiones se realizan periódicamente para asegurar la ejecución de todas las actividades identificadas en este Plan.

Plan de SQA

9

Hernán Esteves 6.2.8.

Revisión del Plan de gestión de configuración Esta revisión se realiza para asegurar la consistencia y completitud de los métodos especificados en el Plan de gestión de configuración.

6.2.9.

Revisión Post Mortem Esta revisión se realiza al concluir el proyecto para especificar las actividades de desarrollo implementadas durante el proyecto y para proveer recomendaciones.

6.3.

7.

Agenda Revisión

Semana de ejecución

Revisión de requerimientos Revisión de diseño y arquitectura Revisión del plan de V&V Auditoria funcional Auditoria física Auditorías internas al proceso Revisión de gestión Revisión del plan de gestión de configuración Revisión post mortem

3a9 4y5 3 12 12 6, 8, 11 y 12 Siempre 4 12

Reporte de problemas y acciones correctivas Cada vez que se detecte un desvío o sugerencia para mejorar en el futuro se notificaran a todos los integrantes del grupo y si las sugerencias no son tomadas en cuenta y los desvíos persisten se notificará especialmente al . En el caso de la documentación, el responsable de SQA recibirá documentos para su revisión hasta los sábados de cada semana. Los demás serán entregados, pero sin revisión. Como resultado se obtendrá un informe de SQA donde se detallarán los puntos débiles y fuertes de cada entrega semanal. Cuando los problemas surjan en un área especial, por ejemplo, SCM o V&V, entonces solamente los responsables serán notificados para que tomen medidas correctivas.

8.

Gestión de riesgos Los riesgos, así como sus estrategias de mitigación, plan de contingencia y monitoreo están especificados en el documento de gestión de riesgos. Al terminar cada semana se evaluará el estado de cada riesgo y se tomarán las medidas necesarias según sea la situación del riesgo.

Plan de SQA

10