P LAN DE ASEGURAMIENTO DE LA CALIDAD PARA EL PROTOTIPO S CRUM -H ANDLER Marcel Valdez Orozco...
-
Upload
angelita-torre -
Category
Documents
-
view
7 -
download
0
Transcript of P LAN DE ASEGURAMIENTO DE LA CALIDAD PARA EL PROTOTIPO S CRUM -H ANDLER Marcel Valdez Orozco...
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