La descarga está en progreso. Por favor, espere

La descarga está en progreso. Por favor, espere

P LAN DE ASEGURAMIENTO DE LA CALIDAD PARA EL PROTOTIPO S CRUM -H ANDLER Marcel Valdez Orozco A00790834 Rubén Valdez Bejarano A00739846 Paolo Iván Aguirre.

Presentaciones similares


Presentación del tema: "P LAN DE ASEGURAMIENTO DE LA CALIDAD PARA EL PROTOTIPO S CRUM -H ANDLER Marcel Valdez Orozco A00790834 Rubén Valdez Bejarano A00739846 Paolo Iván Aguirre."— Transcripción de la presentación:

1 P LAN DE ASEGURAMIENTO DE LA CALIDAD PARA EL PROTOTIPO S CRUM -H ANDLER Marcel Valdez Orozco A Rubén Valdez Bejarano A Paolo Iván Aguirre Montoya A

2 E STRUCTURA 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

3 1. P ROPÓ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.

4 2. D OCUMENTOS DE REFERENCIA IEE 730 Standard for software quality assurance plans 2002 ESA PSS-05-11

5 3. A DMINISTRACIÓN Roles y responsabilidades RolNombreResponsabilidad 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 Valdez 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 José Guzmán Marcel Valdez Deben seguir las métricas y los estándares de codificación para asegurar la calidad de software. Verificadores Paolo Aguirre Rubén Valdez Deben de llevar a cabo las revisiones de software en todas las fases del proyecto.

6 4. D OCUMENTACIÓ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

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

8 P LAN 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

9 5. P ERFILES OPERACIONALES Perfiles de usuarios detectados Cliente Administrador Usuarios SCRUM Perfil de usuarioFrecuencia de uso del sistema Cliente.1 Administrador.3 Usuarios SCRUM.6

10 5. P ERFILES 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.

11 A CTIVIDADES CLAVE

12 6. N ORMAS, PRÁCTICAS, CONVENCIONES Y MÉTRICAS Se utilizarán las convenciones de codificación de C# de Microsoft®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.

13 6. N ORMAS, 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.

14 6. N ORMAS, 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 trunk 2. En esta rama, el desarrollador implementará el requerimiento 3. 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.

15 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. N ORMAS, PRÁCTICAS, CONVENCIONES Y MÉTRICAS

16 7. R EVISIÓ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.

17 R EVISIÓN DEL PLAN DE PROYECTO Proceso de la revisión

18

19

20 B ITÁCORA DE REVISIÓN ID Revisión Fecha Autor Artefacto Fase InicioFinInterrupciónComentarios

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

22 8. P ROCESO 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

23 C ASOS DE P RUEBA – P RODUCT BACKLOG


Descargar ppt "P LAN DE ASEGURAMIENTO DE LA CALIDAD PARA EL PROTOTIPO S CRUM -H ANDLER Marcel Valdez Orozco A00790834 Rubén Valdez Bejarano A00739846 Paolo Iván Aguirre."

Presentaciones similares


Anuncios Google