Plan de aseguramiento de la calidad para el prototipo Scrum-Handler Marcel Valdez Orozco A00790834 Rubén Valdez Bejarano A00739846 Paolo Iván Aguirre Montoya A00739866

Estructura del plan de calidad Propósito del plan Documentos de referencia Administración del equipo de trabajo Documentación Perfiles operacionales Normas, prácticas, convenciones y métricas Revisión y verificación del prototipo Proceso de validación del prototipo Notificación de problemas Herramientas técnicas y metodologías Colección de registros, mantenimiento y retención Gestión de riesgos Glosario

1. Propósito del plan de calidad Definir un conjunto de actividades y métricas que auxilien en el aseguramiento de la calidad del prototipo Scrum-Handler, que es un sistema gestor de proyectos basados en Scrum, la metodología de desarrollo ágil. Este documento abarcará inspecciones de elementos como: el análisis de requerimientos, el plan de proyecto, el diseño GUI y el desarrollo del prototipo. Cabe destacar que su ciclo de vida es muy corto pues es un prototipo para un futuro sistema con mayor funcionalidad, sin embargo, la intención de realizar con calidad este prototipo, es asegurar el reúso de los artefactos, para futuro el desarrollo de la aplicación.

2. Documentos de referencia IEE 730 “Standard for software quality assurance plans 2002” ESA PSS-05-11

Responsabilidad en el SQP 3. Administración Roles y responsabilidades Rol Nombre Responsabilidad en el SQP Administrador Rubén Valdez Debe de asegurarse de que el equipo de trabajo ejecute todas las actividades de calidad en las fases del proyecto, además de comunicar los errores que se han ido encontrando en el documento. Analistas José Guzmán Deben de tomar los requerimientos del sistema según los estándares de calidad. Diseñadores Marcel Valdez Paolo Aguirre Deben diseñar la arquitectura de software según los estándares de calidad que se encuentran en el plan de calidad. Desarrolladores Deben seguir las métricas y los estándares de codificación para asegurar la calidad de software. Verificadores Deben de llevar a cabo las revisiones de software en todas las fases del proyecto.

4. Documentación Documentos a inspeccionar y validar Especificación de Requerimientos de Software (SRD) Documento de Plan de Proyecto Documentos de Diseño de Software (SDD) Documentos de Código Fuente

Plan de verificación y validación Plan de Verificacion Establecer el proceso para la inspección de cada documento. Establecer “Checklists” para la revisión de cada documento por fases. Establecer las formas de registro de defectos en cada parte de la verificacion

Plan de verificación y validación Plan de Validación Establecer el procedimiento para hacer casos de pruebas. Establecer un formato para llenar los casos de pruebas Establecer casos de prueba críticos: Unitarias Integración Sistema Aceptación

5. Perfiles operacionales Perfiles de usuarios detectados Cliente Administrador Usuarios SCRUM Perfil de usuario Frecuencia de uso del sistema Cliente .1 Administrador .3 Usuarios SCRUM .6

5. Perfiles operacionales Modos del sistema Modo de administración de proyectos Según los servicios que facilita el modo del sistema se calcularon las actividades claves, y se le dio un peso según su uso diario.

Actividades clave

6. Normas, prácticas, convenciones y métricas Se utilizarán las convenciones de codificación de C# de Microsoft® No se podrá hacer Commit al repositorio principal SVN, si la evaluación de StyleCop para Visual Studio 2010, utilizando la convención de codificación de Microsoft®, determina que hay errores de estilo en algún documento de código fuente. No se podrá hacer Commit al repositorio SVN si el proyecto no compila exitosamente. No se podrá hacer Commit al repositorio SVN si la aplicación tiene errores de ejecución conocidos.

6. Normas, prácticas, convenciones y métricas No se podrá hacer Commit al repositorio SVN, si algún documento de código fuente tiene implementaciones incompletas, a menos que haya algún placeholder con el comentario “// TODO: [Descripción de funcionalidad faltante]”, dentro del archivo de código fuente donde se codificará la implementación. Ningún documento de código puede tener más de 500 líneas de código, a menos que sea autogenerado. Ningún método puede tener más de 50 líneas de código, a menos que sea autogenerado.

6. Normas, prácticas, convenciones y métricas Norma de integración continua: Al implementar un requerimiento de sistema, cada desarrollador deberá crear una rama o branch del tronco o trunk En esta rama, el desarrollador implementará el requerimiento Al finalizar la implementación correcta en la rama, el desarrollador pondrá un candado sobre el tronco principal. Inmediatemente, se hará una integración o merge en su copia local de su rama con el tronco. El desarrollador ejecutará las pruebas unitarias y de integración sobre el programa resultante de la integración, y si alguna prueba unitaria o de integración se ejecuta insatisfactoriamente, es responsabilidad del desarrollador arreglar tal defecto. Sólo al conformar satisfactoriamente con todas las pruebas unitarias, integración, y demás normas, prácticas y convenciones, se podrá hacer Commit al repositorio SVN de código, en el tronco o trunk principal.

6. Normas, prácticas, convenciones y métricas Se crearán pruebas unitarias para todo método que tenga más de un predicado o línea de código. Se crearán Contratos de precondición, para todo método público que asuma características de los parámetros. Ejemplo: Contract.Requires(param != null); Se crearán Contratos de postcondición, para todo método público que crea o modifica el estado públicamente visible de un objeto, incluído a sí mismo. Ejemplo: Contract.Ensures(this.Counter == Contract.OldValue(this.Counter) + 1) Se crearán Contratos de Invariantes de Clase, para toda clase con métodos y estado públicos.

7. Revisión y verificación del prototipo Definir procesos de revisión para cada artefacto, documento o entregable crítico en el desarrollo de software que especifiquen los pasos a seguir y las actividades a llevar a cabo para evitar discrepancias en el proceso de revisión como tal. De igual manera, definir formas de registro de todos los defectos encontrados y checklists con la finalidad de tener una sola forma de registro estandarizada para todos los diferentes procesos de revisión.

Revisión del plan de proyecto Proceso de la revisión

Bitácora de revisión ID Revisión Fecha Autor Artefacto Fase Inicio Fin   Fecha Autor Artefacto Fase Inicio Fin Interrupción Comentarios

Después del proceso se provee un checklist similar a las inspecciones que se realizaron en clase.

8. Proceso de validación del prototipo Se provee un proceso para desarrollar los Casos de Prueba que tiene los pasos: Planeación de Desarrollo de Casos de Prueba Diseño de Casos de prueba y una plantilla para documentarlos. Revisión e Inspección de Casos de Prueba Inspección de los Casos de Prueba Así mismo, se incluye un proceso para ejecutar los Casos de Prueba que tiene los pasos: Planeación de su ejecución Preparación de Pruebas Ejecución de Casos de Prueba y una plantilla para registrar los resultados de la ejecución Análisis de Resultados

Casos de Prueba– Product backlog