PLAN DE CALIDAD Fecha 24-03-2009 Proceso Versión 1.0 Entregable Descripción Versión inicial de la especificación de los actores del sistema Riesgos de calidad Descripción del control a efectuar Las reglas de funcionamiento del grupo no sean claras Hacer una retroalimentación y verificar que se estén cumpliendo los acuerdos y de ser necesario aplicar sanciones Acta de constitución del proyecto Iniciación Especificación de Requerimientos Requerimientos funcionales Cambios en los requerimientos aprobados inicialmente Especificación de Requerimientos Especificación Demoras en la Requerimientos de retroalimentación funcionales Requerimientos del cliente Especificación de Requerimientos Especificación de casos de uso Calidad de Software Incompletos, ambiguos Autor Rafael Esteban Espinel Pinzón Criterio de Aceptación El 100% de los requerimientos se deben estableer de comun acuerdo cn el cliente Si el cliente Que los cambios realiza cambios, solictados, no efectuar una impacten la fecha adecuada de entrega del gestión de proyecto más de cambios, con un 10% ni en su análisis de funcionalidad impactos primaria Que haya por lo menos un caso de uso por módulo Prerequisito Líder del proyecto Acta de constitución inicial aprobada y firmada por todos los integrantes Líder del proyecto Especificaciones claras definidas en el documento de alcance del proyecto Líder del proyecto Acta de aprobación de requerimientos firmada por el cliente y el líder del grupo. Líder del proyecto Documento Gestión de la Calidad del Proyecto, aprobado por el cliente Que todos los integrantes del grupo, aprueben las reglas Acta de aprobación de requerimientos firmada por el cliente y el líder del grupo. Aprobación por parte del cliente del documento Gestión de la calidad del proyecto Responsable Se aceptarán modificaciones, máximo hasta 2 días después de entregado el documento o producto Se aceptarán máximo 2 errores de completitud o ambiguedad por caso de uso. Líder Desarrollo Definición de módulos del sistema Página 1 de 4 PLAN DE CALIDAD Especificación de Requerimientos Planeación Planeación Especificación detallada de Casos de Uso Lista de actividades Cronograma Calidad de Software Incompletos, inconsistentes, ambiguos, no viables Incompletas, ambiguas, que no se puedan calcular los tiempos Los tiempos y recursos no esten bien definidos El 100% de los casos de uso deben satisfacer por lo menos un requerimiento Líder general de Desarrollo negocio y debe tener definido un criterio de prioridad VoBo Cliente, Revisión VoBo Líder Líder del conjunta técnicoDesarrollo VoBo proyecto funcional Lider Proyecto Verificar que el 100% de las Las actividades actividades estén deben relacionadas a un corresponder paquete de Líder del minimos a las trabajo y que se proyecto actividades les pueda asignar correspondienes un tiempo en a cada entrega horas para su ejecución. Verificar que haya un 0% de sobreasignaciones de trabajo. Deben estar el Solamente se 100% de las Líder del aceptará un 10% actividades proyecto máximo de definidas. sobreasignación del tiempo disponible del recurso Incluir en el formato de C.U el requerimiento general de negocio asociado y criterio de aceptación Especificación de casos de uso Especificación de casos de uso Especificación de Requerimientos Página 2 de 4 PLAN DE CALIDAD Diseño Especificación de diseño de software Incompleto Verificar que se describe la estructura total del Debe contener el producto, su diseño componentes conceptual, principales y diseño de alto especificaciones nivel y una de interfaz, para lo estructura cual debe mostrar complementaria por lo menos el que defina el 90% de las bosquejo de relaciones entre diseño los casos de uso especificados con los componentes. Hacer matriz que cruza componente con caso de uso Diseño Diseño de Alto Nivel El diseño no contempla todos los requerimientos funcionales Construcción Componente Arquitectura Base No cumpla con su correcta funcionalidad Carga no representativa Pruebas Pruebas Equipo y Ambiente no representativo Mejora entre prueba y prueba Calidad de Software Cada caso de uso debe estar soportado por lo menos por un componente del diseño El componente El componente debe incluir debe tener mínimo 1 prueba pruebas unitarias unitaria que valide anexas su correcta funcionalidad La prueba debe La prueba de cumplir con el carga debe mismo número soportar mínimo el de usuarios número de concurrentes usuarios de definidos en el especificados en documento de los req no requerimientos funcionales no funcionales Se debe tener el Se debe cumplir mismo con el mismo procesador, ambiente que se memoria, sistema va a tener en operativo y producción servidor de aplicaciones Se debe mejorar El porcentaje de entre la prueba mejora en inmediatamente desempeño debe anterior a la ser mínimo el 5% Líder de Diseño Requrimientos funcionales, no funcionales y la definción de los modulos del sistema Líder Desarrollo Líder Desarrollo Realizar set de pruebas unitarias Tener los Líder Calidad Requerimientos No funcionales Tener claro el ambiente que se Líder Calidad va a tener en producción Líder Calidad Página 3 de 4 PLAN DE CALIDAD actual Cierre Proyecto Acta de cierre del proyecto Calidad de Software Pruebas de integración Los componentes no se acoplan bien Producto terminado Haya casos de uso no implementados en el sistema Pruebas de aceptación de producto terminado El producto no cumple con toda la funcionalidad que el cliente espera El producto sea de baja calidad No deben existir dos componentes o más con una funcionalidad común y se acoplan perfectamente El 100% de los casos de uso, están implementados y probados 0% de pruebas bloqueantes y hasta 10% pruebas no bloqueantes Acta de cierre El producto debe firmada y ser de la más aprobada por el alta calidad cliente y el líder del proyecto Arquitectura Líder Calidad base y diseño detallado Líder Calidad Casos de uso detallados Aceptación del equipo de Líder Calidad pruebas de producto Líder Proyecto Acta de constitución del proyecto, definición de requerimientos funcionales, pruebas funcionales 100% aprobadas Página 4 de 4