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

3. ADMINISTRACIÓN

Roles y responsabilidadesRol 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 Rubén ValdezJosé Guzmán

Deben de tomar los requerimientos del sistema según los estándares de calidad.

Diseñadores Marcel ValdezPaolo Aguirre

Deben diseñar la arquitectura de software según los estándares de calidad que se encuentran en el plan de calidad.

Desarrolladores José GuzmánMarcel Valdez

Deben seguir las métricas y los estándares de codificación para asegurar la calidad de software.

Verificadores Paolo AguirreRubén Valdez

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:1. Al implementar un requerimiento de sistema, cada desarrollador

deberá crear una rama o branch del tronco o trunk2. En esta rama, el desarrollador implementará el requerimiento3. Al finalizar la implementación correcta en la rama, el

desarrollador pondrá un candado sobre el tronco principal.4. Inmediatemente, se hará una integración o merge en su copia

local de su rama con el tronco.5. 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.

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

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.

6. NORMAS, PRÁCTICAS, CONVENCIONES Y MÉTRICAS

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