V1-PlanCalidad

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