Guia Sqpa 1 0

Documento gua de SQAP
Pgina 1 de 30
Descripcin: Describe una gua para el desarrollo de la norma
Fecha de revisin: Junio 2010

Revisin No: 1.0
Referencia a la norma: Estndar IEEE 730 | El estndar que corresponde a los planes del aseguramiento de la calidad
Autores: Alan Lozada, Angel Snchez, Jos Navarro, Ivvette Valdez
Fuente: http://mcateam.wordpress.com/equipo-2/

gua sqpa 1.0
Pgina 2 de 30

Revisin No: 1.0
Gua SQAP
Contenido
1.
PROPSITO........................................................................................................................................3
2.
REFERENCIAS...................................................................................................................................5
3.
DEFINICIONES Y ACRNIMOS...................................................................................................5
3.1.
DEFINICIONES.................................................................................................................................5
3.1.1.
Mtrica de Salto:...................................................................................................................5
3.1.2.
Mtricas de punto de decisin:.............................................................................................5
3.1.3.
Mtrica de Mensajes de Errores:..........................................................................................5
3.1.4.
Aseguramiento de Calidad:...................................................................................................5
3.1.5.
Mtricas de demostracin de requerimientos:......................................................................5
3.2.
ACRNIMOS....................................................................................................................................5
4.
GESTIN.............................................................................................................................................6
4.1.
ORGANIZACIN..............................................................................................................................6
4.2.
ACTIVIDADES.................................................................................................................................7
4.2.1.
Ciclo de vida del software cubierto por el Plan....................................................................7
4.2.2.
Revisar cada producto...........................................................................................................8
4.2.3.
Revisar el ajuste al proceso...................................................................................................8
4.2.4.
Realizar Revisin Tcnica Formal (RTF).............................................................................8
4.2.5.
Asegurar que las desviaciones son documentadas................................................................9
4.2.6.
Revisar las entregas..............................................................................................................9
4.2.7.
Relaciones entre las actividades de SQA y la planificacin.................................................9
4.3.
RESPONSABLES...............................................................................................................................9
5.
DOCUMENTACIN...........................................................................................................................9
5.1.
PROPSITO......................................................................................................................................9
5.2.
DOCUMENTACIN MNIMA REQUERIDA........................................................................................10
5.2.1.
Especificacin de requerimientos del software (SRS).........................................................10
5.2.2.
Descripcin del diseo del software (SDD)........................................................................11
5.2.3.
Plan de Verificacin & Validacin (SVVP).........................................................................11
5.2.4.
Reportes de Verificacin & Validacin...............................................................................12
5.2.5.
Documentacin de usuario..................................................................................................12
5.2.6.
Plan de Gestin de configuracin (SCMP).........................................................................12
5.3.
OTROS DOCUMENTOS...................................................................................................................12
5.3.1.
Plan de desarrollo:..............................................................................................................12
5.4.
ESTNDARES PARA LOS NOMBRES DE LOS DOCUMENTOS............................................................12
6.
ESTNDARES, PRCTICAS, CONVENCIONES Y MTRICAS............................................13

6.1.
ESTNDAR DE DOCUMENTACIN..................................................................................................13
6.1.1.
Estndar de documentacin tcnica e implementacin......................................................14
6.1.2.
Estndar de documentacin de usuario..............................................................................14
6.1.3.
Estndar de verificacin y prcticas...................................................................................14

Pgina 3 de 30
Revisin No: 1.0
6.1.4.
Mtricas elegidas para los productos y procesos SQA:......................................................14
6.2.
OTROS ESTNDARES....................................................................................................................14
Estndares de programacin:.....................................................................................................14
7.
REVISIONES Y AUDITORIAS.......................................................................................................14
7.1.
OBJETIVO......................................................................................................................................14
7.2.
REQUERIMIENTOS MNIMOS..........................................................................................................14
7.2.1.
Revisin de requerimientos (SRR).......................................................................................15
7.2.2.
Revisin de diseo preliminar (PDR)..................................................................................15
7.2.3.
Revisin de diseo crtico (CDR)........................................................................................15
7.2.4.
Revisin del Plan de Verificacin & Validacin (SVVPR)..................................................15
7.2.5.
Auditoria funcional..............................................................................................................15
7.2.6.
Auditoria fsica....................................................................................................................15
7.2.7.
Auditorias internas al proceso............................................................................................15
7.2.8.
Revisiones de gestin...........................................................................................................15
7.2.9.
Revisin del Plan de gestin de configuracin (SCMPR)...................................................16
7.2.10. Revisin Post Mortem.........................................................................................................16
7.2.11. Agenda.................................................................................................................................16
7.3.
OTRAS REVISIONES.......................................................................................................................16
7.3.1.
Revisin de documentacin de usuario...............................................................................16
8.
VERIFICACIN...............................................................................................................................16
9.
REPORTE DE PROBLEMAS Y ACCIONES CORRECTIVAS..................................................16
10.
HERRAMIENTAS, TCNICAS Y METODOLOGAS............................................................17
11.
CONTROL DE CDIGO.............................................................................................................18
12.
ENTRENAMIENTO.....................................................................................................................18
13.
GESTIN DE RIESGOS..............................................................................................................18
APNDICE A.............................................................................................................................................19
CHECKLIST PARA LA REVISIN DE REQUERIMIENTOS:.............................................................................19
CHECKLIST PARA LA REVISIN DE SCM:.................................................................................................22
CHECKLIST PARA LA REVISIN DEL MODELO DE CASOS DE USO.............................................................23
CHECKLIST PARA LA REVISIN DE LA DESCRIPCIN DE LA ARQUITECTURA..........................................24
CHECKLIST PARA LA REVISIN DEL MODELO DE DISEO........................................................................25
Pgina 4 de 30

Revisin No: 1.0
1.
Propsito
El propsito de Plan de Calidad (SQAP) consiste en especificar las pautas
a seguir durante el proceso de desarrollo para poder asegurar la calidad del
mismo y del producto a construir, detallando todo lo referente a la planificacin
del seguimiento de la calidad en el proyecto, indicando para cada actividad, los
atributos de calidad relevantes, los mtodos de evaluacin de calidad, en que
momento se realizarn dichos mtodos y los responsables, centrndose en el
producto mas all del proceso.
Productos Generales
PG 1.Productos Particulares
PP 1.1.Productos Especficos
Actividades
PE 1.1.1.PE 1.1.2.PE 1.1.3.PE 1.1.4.-
Actividades

Pgina 5 de 30
Revisin No: 1.0
PE 1.2.1.PE 1.2.2.PE 1.2.3.PE 1.2.4.-
PE 1.3.1.PE 1.3.2.PE 1.3.3.PE 1.3.4.-
Actividades
Pgina 6 de 30
Revisin No: 1.0

2.
Referencias
1. ANSI/IEEE Std. 730.1-1989, IEEE Standard for Software Quality Assurance
Plans.
2. http://www.fing.edu.uy/~pgcalpro/index.htm
3. http://www.sqa.org
4. http://www.sqatester.com
5. http://www.sqassociates.com
6. http://metrics.sourceforge.net/
7. http://www.qa-systems.com/downloads/qstudioforjava/pro/index.html
8. http://javacentral.compuware.com/products/optimaladvisor/
Clave
3.
Autor/Ao
Lugar
Titulo
Especificacin
Definiciones y acrnimos
3.1.
Definiciones
Las definiciones establecen el significado en el contexto del SQAP. Otras

definiciones pueden encontrarse en IEEE Std 610.12-1990, o en versiones
posteriores del mismo.
3.1.1.
Mtrica de Salto:
El resultado de dividir el total de mdulos en cual cada salto ha sido

ejecutado por lo menos una vez, sobre el total de mdulos.
3.1.2.
Mtricas de punto de decisin:
El resultado de dividir el total de mdulos en los cuales cada punto de

decisin ha tenido:
1) Todas las condiciones vlidas, y 2) por lo menos una condicin invlida,
procesada correctamente, dividido el numero de mdulos.
3.1.3.
Mtrica de Mensajes de Errores:
El resultado de dividir el total de mensajes de errores que han sido

formalmente demostrados, sobre el total de mensajes de errores.
3.1.4.
Aseguramiento de Calidad:

Pgina 7 de 30
Revisin No: 1.0
Un patrn sistemtico y planeado de acciones necesarias para proveer

argumentos de que el tem o producto consta de los requerimientos
tcnicos establecidos.
3.1.5.
Mtricas de demostracin de requerimientos:
El resultado de dividir el total de requerimientos independientes

identificados en la SRS que han sido exitosamente probados sobre el total
de requerimientos independientes identificados en la SRS.
3.2.
Acrnimos
Los siguientes contratos alfabticos aparecen dentro del texto de este

plan:
CDR Revisin de Diseo Crtico
PDR Revisin de Diseo Preliminar
SCMP Plan de Gestin de Configuracin de Software
SCMPR Revisin del Plan de Gestin de Configuracin de Software
SDD Descripcin del Diseo de Software
SQA Aseguramiento de la calidad del Software
SQAP Plan de Aseguramiento de Calidad del Software
SRR Revisin de los Requerimientos del Software
SRS Especificacin de los Requerimientos del Software
SVVP Plan de Verificacin y Validacin de Software
SVVPR Revisin del Plan de Verificacin y Validacin de Software
SVVR Reporte de Verificacin y Validacin de Software
UDR Revisin de la documentacin de Usuario
4.
Gestin
La organizacin de las actividades y los responsables asociados (para la primera
fase), se encuentran en el correspondiente documento de Plan de la iteracin.
All se detallan todas las responsabilidades de cada integrante del staff.
4.1.
Organizacin
El encargado de SQA es el responsable de asegurar la calidad sobre los

productos, pero es de importancia que cada integrante del grupo adopte un
Pgina 8 de 30

Revisin No: 1.0
comportamiento responsable, y consiente acerca de decisiones tomadas que

puedan en un futuro estropear la calidad del producto.
Disciplinas (Lneas de trabajo)

Bsicas
RRHH
Requerimientos
Diseo
Implementacin
Verificacin
Implantacin
Gestin
Gestin de Configuracin (SCM)

Gestin del proyecto
Gestin de la calidad
Formacin y entrenamiento
Estructurar la tabla de referencia entre los elementos

organizacin representado en el rbol jerrquico.
Clave
Puesto
Nivel
Corresponden
cia
que
integran
la
Dependenci
a
Estructurar la tabla de los elementos de que integran la organizacin

representada en el rbol jerrquico as como el rea, actividades y
responsabilidades.
Clase
Puesto
Nombre
Actividade
s
Responsabilid
ades

Pgina 9 de 30
Revisin No: 1.0
4.2.
Actividades
4.2.1. Ciclo de vida del software cubierto por el Plan
Como se indic anteriormente, el plan cubre, del ciclo de vida del software,
las fases de evaluacin, elaboracin, construccin y transicin. Las tareas a ser
llevadas a cabo debern reflejar las evaluaciones a realizar, los estndares a
seguir, los productos a revisar, los procedimientos a seguir en la elaboracin de
los distintos productos y los procedimientos para informar de los defectos
detectados a sus responsables y realizar el seguimiento de los mismos hasta su
correccin.
Las actividades que se realizarn son:
Revisar cada producto
Revisar las entregas
Revisar el ajuste al proceso
Realizar Revisin Tcnica Formal (RTF)
Asegurar que las desviaciones son documentadas.
Evaluacin final de calidad.
4.2.2. Revisar cada producto

En esta actividad se revisan los productos que se definieron como claves
para verificar en el Plan de calidad.
Se debe verificar que no queden correcciones sin resolver en los informes de
revisin previos, si se encuentra alguna no resuelta, debe ser incluida en la
siguiente revisin. Se revisan los productos contra los estndares, utilizando la
checklist definida para el producto.
Como salida se obtiene el Informe de revisin de SQA, este informe debe
ser distribuido a los responsables del producto y se debe asegurar de que son
concientes de desviaciones o discrepancias encontradas. ste documento a su
vez sirve para el director del proyecto para tener una idea general del trabajo
semanal del grupo en cuanto a documentacin, y hace referencia a todos los
documentos entregados, por lo que se debe de poder navegar a travs de l
fcilmente.
4.2.3. Revisar el ajuste al proceso
En esta actividad se revisan los productos que se definieron como claves
para verificar el cumplimiento de las actividades definidas en el proceso. Con el
fin de asegurar la calidad en el producto final del desarrollo, se deben llevar a
cabo revisiones sobre los productos durante todo el ciclo de vida del software.

Pgina 10 de 30
Revisin No: 1.0
Se debe recoger la informacin necesaria de cada producto, buscando hacia

atrs los productos previos que deberan haberse generado, para poder
establecer los criterios de revisin y evaluar si el producto cumple con las
especificaciones. Esta informacin se obtiene de los siguientes documentos: Plan
del Proyecto, Plan de la iteracin, Plan de Verificacin.
Antes de comenzar, se debe verificar en los informes de revisin previos que
todas las desviaciones fueron corregidas, si no es as, las faltantes se incluyen
para ser evaluadas. Como salida se obtiene el Informe de revisin de SQA
correspondiente a la evaluacin de ajuste al Proceso, este informe debe ser
distribuido a los responsables de las actividades y se debe asegurar de que son
concientes de desviaciones o discrepancias encontradas.
4.2.4. Realizar Revisin Tcnica Formal (RTF)
El objetivo de la RTF es descubrir errores en la funcin, la lgica la
implementacin de cualquier producto del software, verificar que satisface sus
especificaciones, que se ajusta a los estndares establecidos, sealando las
posibles desviaciones detectadas. Es un proceso de revisin riguroso, su objetivo
es llegar a detectar lo antes posible, los posibles defectos o desviaciones en los
productos que se van generando a lo largo del desarrollo. Por esta caracterstica
se adopta esta prctica para productos que son de especial importancia. En la
reunin participan el responsable de SQA e integrantes del equipo de desarrollo.
Se debe convocar a la reunin formalmente a los involucrados, informar del
material que ellos deben preparar por adelantado, llevar una lista de preguntas y
dudas que surgen del estudio del producto a ser revisado. La duracin de la
reunin no debe ser mayor a dos horas. Como salida se obtiene el Informe de
RTF.
Pgina 11 de 30

Revisin No: 1.0
4.2.5. Asegurar que las desviaciones son documentadas

Las desviaciones encontradas en las actividades y en los productos deben
ser documentadas y ser manejadas de acuerdo a un procedimiento establecido.
Se debe chequear que los responsables de cada plan los modifiquen cada vez que
sea necesario, basados en las desviaciones encontradas.
4.2.6. Revisar las entregas
sta actividad consiste en revisar semanalmente la totalidad de los
entregables del proceso, se documentan las desviaciones y se corrigen si son
menores, de lo contrario, el documento sigue el ciclo definido en la seccin 9.
ste documento a su vez sirve para el director del proyecto para tener una idea
general del trabajo semanal del grupo en cuanto a documentacin, y hace
referencia a todos los documentos entregados, por lo que se debe de poder
navegar a travs de l fcilmente.
4.2.7. Relaciones entre las actividades de SQA y la planificacin
Esta planificacin es estimada, y se ajustar posteriormente en los
posteriores planes de cada iteracin.
Actividad
Semana cuando se realiza
Planificar la calidad
Identificar las Propiedades de Calidad
Plan de Calidad
Evaluar y ajustar el Plan de SQA
Evaluar la calidad de los productos
Revisar el Ajuste al proceso
Revisar las entregas
RTF
Realizar el Informe Final de Calidad
4.3.
Responsables
Los responsables de cada actividad se encuentran en el respectivo

documento de planificacin de la iteracin: Plan de Iteracin N_VXX.doc, donde
N indica la iteracin y XX su respectiva versin.
5.
Documentacin
5.1.
Propsito
Identificacin de la documentacin relativa a desarrollo, Verificacin &

Validacin, uso y mantenimiento del software. Establecer como los documentos

Pgina 12 de 30
Revisin No: 1.0
van a ser revisados para chequear consistencia: se confirman criterio e

identificacin de las revisiones.
5.2.
Documentacin mnima requerida
Es la mnima para asegurar que la implementacin lograr satisfacer los

requerimientos.
5.2.1. Especificacin de requerimientos del software (SRS)
Para lograr satisfacer los requerimientos debemos de tener un documento
de SRS que describa de forma clara y precisa cada uno de los requerimientos
esenciales del software adems de las interfaces externas.
El cliente deber obtener como resultado del proyecto una especificacin
adecuada a sus necesidades en el rea de alcance del proyecto, de acuerdo al
compromiso inicial del trabajo y a los cambios que este haya sufrido a lo largo del
proyecto, que cubra aquellos aspectos que se haya acordado detallar con el
cliente. Si es necesario, se pueden construir 2 documentos para la especificacin,
uno tcnico y otro mas orientado al cliente, para esto, se debe aplicar SCM a
cada versin.
La especificacin debe ser:
Ser completa :
a. Externa, respecto al alcance acordado.
b. Internamente, no deben existir elementos sin especificar.
Ser consistente, no pueden haber elementos contradictorios.
Ser no ambigua, todo trmino referido al rea de aplicacin debe estar

definido en un glosario.
Ser verificable, debe ser posible verificar siguiendo un mtodo definido,

si el producto final cumple o no con cada requerimiento.
Estar acompaada de un detalle de los procedimientos adecuados para

verificar si el producto cumple o no con los requerimientos.
Incluir requerimientos de calidad del producto a construir.
Los requerimientos de calidad del producto a construir son considerados

dentro de atributos especficos del software que tienen incidencia sobre la
calidad en el uso y se detallan a continuacin:
Funcionalidad
a.
adecuacin a las necesidades
b.
precisin de los resultados
c.
interoperabilidad
d.
seguridad de los datos

Pgina 13 de 30
Revisin No: 1.0
Confiabilidad
a.
madurez
b.
tolerancia a faltas
c.
recuperabilidad
Usabilidad
a.
comprensible
b.
aprendible
c.
operable
d.
atractivo
Eficiencia
a.
comportamiento respecto al tiempo
b.
utilizacin de recursos
Mantenibilidad
a.
analizable
b.
modificable
c.
estable, no se producen efectos inesperados luego de modificaciones
d.
verificable
Portabilidad
b.
instalable
c.
co-existencia
Cada uno de los anteriores debe cumplir con las normas y regulaciones
aplicables a cada atributo en su contexto.
Anexo A (SRS)
5.2.2. Descripcin del diseo del software (SDD)
El documento de diseo especifica como el software ser construido
satisfacer los requerimientos. Deber describir los componentes y
componentes del diseo del software, incluyendo interfaces internas.
documento deber ser elaborado primero como Preliminar y luego
gradualmente extendido hasta llegar a obtener el Detallado.
para
subEste
ser
El cliente deber obtener como resultado del proyecto el diseo de un

producto de software que cubra aquellos aspectos que se haya acordado con el
cliente incorporar al diseo, en funcin de la importancia que estos presenten y
de sus conexiones lgicas.

Pgina 14 de 30
Revisin No: 1.0
El diseo debe:
Corresponder a los requerimientos a incorporar:

a. Todo elemento del diseo debe contribuir a algn requerimiento, y/o
tener un valor agregado para una solucin que agregue atributos de
calidad al software.
b. La implementacin de todo requerimiento a incorporar debe estar
contemplada en por lo menos un elemento del diseo.
Ser consistente con la calidad del producto
Para la revisin del diseo, se presentan las checklist en el Apndice B.

5.2.3. Plan de Verificacin & Validacin (SVVP)
El Plan de Verificacin y Validacin se encuentra en el documento de
VRPVVGXv1.0.doc, el mismo deber identificar y describir los mtodos a ser
utilizados en:
La verificacin de que:
a. los requerimientos descritos en el SRS han sido aprobados por una
autoridad apropiada. En este caso sera que cumplan con el
acuerdo logrado entre el cliente y el equipo.
b. los requerimientos descritos en el SRS son implementados en el
diseo expresado en el documento de diseo.
c. el diseo expresado en el SDD esta implementado en cdigo.
Validar que el cdigo, cuando es ejecutado, se adecua a los

requerimientos expresados en SRS.
5.2.4. Reportes de Verificacin & Validacin
Estos documentos deben especificar los resultados de la ejecucin de los

procesos descritos en el Plan de V & V, VRPVVGXv1.0.doc.
5.2.5. Documentacin de usuario
La documentacin de usuario debe especificar y describir los datos y
entradas de control requeridos, as como la secuencia de entradas, opciones,
limitaciones de programa y otros elementos necesarios para la ejecucin exitosa
del software. Todos los errores deben ser identificados y las acciones correctivas
descritas. Como resultado del proyecto el cliente obtendr una documentacin
para el usuario de acuerdo a los requerimientos especficos del proyecto.
5.2.6. Plan de Gestin de configuracin (SCMP)

Pgina 15 de 30
Revisin No: 1.0
El SCMP debe contener mtodos para identificar componentes de software,

control e implementacin de cambios, y registro y reporte del estado de los
cambios implementados. Referirse a Plan del SCM.doc.
5.3.
Otros documentos
5.3.1. Plan de desarrollo:
El plan de proyecto debe contener la planificacin de las actividades a

realizarse durante el proceso de desarrollo. Debe estimar el esfuerzo necesario
para la realizacin del producto de forma de asegurar el nivel de calidad
esperado. Debe especificar las responsabilidades de los integrantes del equipo de
desarrollo as como el tiempo de dedicacin requerido en cada una de las
actividades asignadas. Se debe definir en este documento el alcance del proyecto
y las limitaciones del mismo, especificando que tareas se realizaran y cuales no.
Debe brindar una descripcin general del proceso de desarrollo y como sern
implementadas las etapas del mismo.
Incluir una estimacin inicial de la agenda y una explicacin del
procedimiento a seguir para ajustarla. El Plan debe especificar los entregables
requeridos en cada etapa y la prioridad de los mismos, de forma de asignar ms
esfuerzo a hitos ms importantes para la calidad del producto.
Debe especificarse en el mismo las pautas a seguir en la actividad de ajuste
del Plan, que variables sern analizadas y en que medida se cuantificara cada
una. Es responsabilidad de los integrantes del equipo de SQA brindar apoyo en
las cuantificaciones de calidad y esfuerzo.
5.4.
Estndares para los nombres de los documentos
Los nombres de los documentos deben ser los nombres originales de las
plantillas, salvo las siguientes excepciones: Los documentos que se entreguen
mas de uno por semana, o sea, los cuales el mismo nombre de entregable aplica
a mas de una vez por semana (ej. Reunion de requerimiento), debern llamarse:
NOriginal_DDMMAAAAvX.Y donde NOriginal es el nombre original del documento
(SQAPLAG1), DD, MM, AAAA son da mes y ao en cual se realiz la actividad
respectivamente y X.Y es nmero de versin. Luego, los documentos que no
evolucionen (cambien de versin) y se entreguen semanalmente o en una
determinada semana, sern nombrados: NOriginal_SemNvX.Y donde N es la
semana en la que se realiz la actividad.
6.
Estndares, prcticas, convenciones y mtricas

En esta seccin el plan pretende identificar los estndares, prcticas,
convenciones y mtricas que sern aplicadas para la evaluacin de Calidad.
Adems de indicar como ser monitoreado y asegurado el cumplimiento con
estos elementos.
6.1.
Estndar de documentacin
Como estndares de documentacin se definirn dos documentos, se debe

unificar el uso de herramientas para documentar con uniformidad todos los
documentos. La documentacin debe reflejar con los siguientes atributos de
calidad:

Pgina 16 de 30
Revisin No: 1.0
Legibilidad
i. Estructura
ii. Tamao
iii. Ilustraciones
iv. Facilidad para ubicar informacin relevante
Completo
Correcto
Para la escritura de documentos se han definido plantillas para ser utilizadas

en la elaboracin de entregables.
En estas plantillas se definen:
Encabezado y pie de pgina.
Fuente y tamao de fuente para estilo normal
Fuente y tamao de fuente para los ttulos a utilizar
Datos mnimos que se deben incluir: fecha, versin y responsables.
Historia de revisiones
ndice de contenido
La responsabilidad de apegarse a los estndares definidos es del encargado

del entregable, definido en el plan de iteracin, el cual es resultado en primera
instancia por la reunin quincenal del grupo, ajustado luego de la reunin de
responsables por rea, y finalmente definida por el administrador del equipo. El
equipo de SQA revisar el cumplimento de stos estndares y reportar
eventuales defectos a los correspondientes responsables, auditando y formando
el ciclo de defectos a definido en la seccin 9.
6.1.1. Estndar de documentacin tcnica e implementacin

La misma debe:
Ser adecuada para que un grupo independiente del de desarrollo pueda

encarar el mantenimiento del producto. Esto es importantsimo del punto
de vista del actual cliente.
Incluir fuentes, Modelos de Casos de Uso, Objetos
Referirse al documento Estndar de Doc. Tcnica e Implementacin

(IMEDTGXvY.doc, IMEIGXvY.doc).
6.1.2. Estndar de documentacin de usuario
Existe un documento para ste propsito, referirse a IPEDUGXvY.doc.

Pgina 17 de 30
Revisin No: 1.0
6.1.3. Estndar de verificacin y prcticas

Se utilizan las prcticas definidas en el Plan de Verificacin y Validacin.
Como estndar se utiliza el documento de: Std 1012-1986 IEEE Standard for
Software Verification and Validation Plans. Referirse al SVVP (Plan de Verificacin
y Validacin, VRPVVGXv1.0.doc).
6.1.4. Mtricas elegidas para los productos y procesos SQA:
1) Mtrica de Saltos;
2) Mtrica de puntos de decisin;
3) Mtrica de Error de mensajes;
4) Mtrica de Demostracin de Requerimientos.
Ver Apndice A para ver mtricas definidas.
6.2.
Otros Estndares
Estndares de programacin:
Los estndares de programacin fomentan buenas prcticas en las
herramientas en las cuales se utilizan, ayudan a terceros a entender las
soluciones y evitan malas prcticas y/o enfoques. Se definieron nomenclaturas
para
el
estndar,
basados
en
el
estndar
de
Sun
http://java.sun.com/docs/codeconv/index.html.
7.
Revisiones y auditorias
7.1.
Objetivo
Definicin de las revisiones y auditorias tcnicas y de gestin que se realizarn.
Especificacin de cmo sern llevadas a cabo dichas revisiones y auditorias.
Revisar y auditar objetivamente los productos y las actividades para verificar

que estn conformes con los procedimientos y estndares aplicables.
Proporcionar los resultados de estas revisiones o auditorias informando a la

directora del proyecto cuando sea necesaria su mediacin.
7.2.
Requerimientos mnimos
Todos los entregables son revisados semanalmente por el equipo

SQA, los mismos se basan en los estndares y prcticas definidas, lo
primero que se audita es quin hace las revisiones, lo cual queda en el
historial de revisiones y adems se formula el documento Entrega
Semanal de SQA. Luego, las revisiones a realizarse son: Revisin de
productos (seccin 3.2.2), Revisin de ajuste del proceso (seccin 3.2.3)
y RTF (seccin 3.2.4). La correspondiente agenda se encuentra en la
seccin 3.2.6.

Pgina 18 de 30
Revisin No: 1.0
7.2.1. Revisin de requerimientos (SRR)

Esta revisin se realiza para asegurar que se cumpli con los
requerimientos especificados por el Cliente. El responsable de SQA no es a
menudo el mejor recurso para hacer esta revisin, pues, el mismo no conoce
tan a fondo los requerimientos como otros integrantes del staff, por lo que
puede ser apropiado que participe un asistente en el mismo. El mismo debe de
estar organizado segn los diferentes conceptos (como lo pide el cliente), por
ejemplo:
X-
Actividad
Explicar que es la actividad
X.1 - Requerimiento 1 sobre actividad
Ver Apndice A
7.2.2. Revisin de diseo preliminar (PDR)
Esta revisin se realiza para asegurar la consistencia y suficiencia tcnica
del diseo preliminar del software.
7.2.3. Revisin de diseo crtico (CDR)
Esta revisin se realiza para asegurar la consistencia del diseo detallado
con la especificacin de requerimientos.
7.2.4. Revisin del Plan de Verificacin & Validacin (SVVPR)
Esta revisin se realiza para asegurar la consistencia y completitud de los
mtodos especificados en el Plan de V & V.
7.2.5. Auditoria funcional
Esta auditoria se realiza previa a la liberacin del software, para verificar
que todos los requerimientos especificados en el documento de requerimientos
fueron cumplidos.
7.2.6. Auditoria fsica
Esta revisin se realiza para verificar que el software y la documentacin
son consistentes y estn aptos para la liberacin.
7.2.7. Auditorias internas al proceso
Estas auditorias son para verificar la consistencia: del cdigo versus el
documento de diseo, especificaciones de interfase, implementaciones de
diseo versus requerimientos funcionales, requerimientos funcionales versus
descripciones de testeo.
7.2.8. Revisiones de gestin
Estas revisiones se realizan peridicamente para asegurar la ejecucin de
todas las actividades identificadas en este Plan. Si es posible, se procurar
realizar por una persona ajena al grupo de trabajo, por ejemplo el director del
proyecto.
Pgina 19 de 30

Revisin No: 1.0
7.2.9. Revisin del Plan de gestin de configuracin (SCMPR)

Esta revisin se realiza para asegurar la consistencia y completitud de los
mtodos especificados en el Plan de gestin de configuracin.
7.2.10.Revisin Post Mortem
Esta revisin se realiza al concluir el proyecto para especificar las
actividades de desarrollo implementadas durante el proyecto y para proveer
recomendaciones, y aunque no hay un mejor momento de realizarla, se fijar
una agenda para la misma.
7.2.11.Agenda
Se estima la semana en la cual se realizarn las revisiones, luego estas
se ajustaran de acuerdo a la disponibilidad de los recursos humanos y las
prioridades del grupo en el plan de iteracin correspondiente.
Revisin
Semanas en las que se realizan.
Revisin de Requerimientos
Semanas 3 a 7
Revisin de Diseo preliminar
Semanas 4 a 6
Revisin de Diseo Crtico
Semanas 7 a 10
Revisin de Plan de V&V
Semanas 5, 7 y 10
Auditoria funcional
Semana 12
Auditoria fsica
Semana 12
Auditorias internas al proceso
Semanas 4, 6, 8, 10, 12
Revisin de gestin
Semanas 4, 6, 8, 10, 12
Revisin del plan de gestin
Semanas 4, 6, 8, 10, 12
Revisin Post Mortem
Semana 15
7.3.
Otras revisiones
7.3.1. Revisin de documentacin de usuario
Se revisa la completitud, claridad, correctitud y aplicacin de uso.
8.
Verificacin
Las verificaciones se encuentran en su totalidad en el SVVP,lo nico que
se le agrega es utilizar los mtodos y herramientas definidas en la Seccin 10.
9.
Reporte de problemas y acciones correctivas

En primera instancia, se asigna a un entregable un responsable, ste es
el encargado de entregar en fecha el entregable en el TeamWork, y adems
de ser el responsable de evaluar el avance del mismo y reflejarlo diariamente
Pgina 20 de 30

Revisin No: 1.0
en el programa. Adems el responsable de SQA, asigna un revisor de SQA y se

encarga de comunicarle que es el encargado de las revisiones correspondientes
a ese entregable. Cuando el documento esta finalizado (por el responsable),
ste pasa en revisin. El revisor asignado es encargado de revisar el documento
y de registrar los defectos del entregable, cuando termina la revisin, l es
encargado de reportar los defectos al responsable SQA y al responsable del
entregable, para que ste ltimo se encargue de las correcciones o asignaciones
para las mismas. Este ciclo lo debe auditar el responsable SQA para tomar
acciones correctivas en el staff o en la mejora de la aplicacin del proceso.
A continuacin se presenta un diagrama del ciclo de vida del entregable:
No iniciado
En construccin
Finalizado
En correccin
En revisin
Entregado
Validado
10. Herramientas, tcnicas y metodologas

Luego de haber estudiado herramientas que dan soporte a las mismas,
tales como Elips, se lleg a la conclusin que aumenta el riesgo en cuanto a la
prdida de tiempo en implementar su uso, por lo que se descart. Se utilizarn
s herramientas como QStudio for Java, Metrics y Optimal Advisor, para el
soporte a la verificacin de diseo y cdigo.
QStudio for Java es una herramienta para analizar la calidad de un cdigo
Java, muestra errores y posibles errores incurridos y soluciones sugeridas para
l. El responsable SQA se encargar de utilizar la herramienta y capacitar a
quien sea necesario, segn se planifique posteriuormente. Se obtuvo una
licencia
free
anual
(http://www.qasystems.com/downloads/qstudioforjava/pro/index.html).

Pgina 21 de 30
Revisin No: 1.0
Se incorpor a El entorno el Plug-In Metrics 1.3.6 a Eclipse, ste permite es un

open source que permite hacer mediciones fcilmente en software O.O. por
ms, referirse a http://metrics.sourceforge.net/
Optimal advisor se seguir investigando, por ms informacin referirse a
http://javacentral.compuware.com/products/optimaladvisor/
Las tcnicas y metodologas para asegurar la calidad, estn en la seccin 4 de
este documento. Las mtricas y aplicaciones de estas herramientas en el
Apndice 10.
11. Control de Cdigo

Para el control de cambios se adopt CVS, ya fue presentado el
mecanismo mencionado al grupo y se har otra presentacin especial para el
grupo de desarrolladores. Referirse a SCMP para obtener la completa
documentacin.
12. Entrenamiento
Se preparar una presentacin del SQAP y se acordar con el
administrador una reunin grupal para conocerlo, ya que es muy importante que
el grupo conozca las necesidades del mismo.
13. Gestin de riesgos

Los riesgos identificados, la estrategia de mitigacin, monitoreo y plan de
contingencia a ser llevados a cabo, sern descritos en el Documento de Gestin
de Riesgos.
Pgina 22 de 30

Revisin No: 1.0
APNDICE A
CheckList para la revisin de requerimientos:
N
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
Pregunta
Los requerimientos estn escritos en un lenguaje no
tcnico y comprensible para el usuario/cliente?
Hay algn requerimiento que pueda tener ms de una
interpretacin?
Cada caracterstica del producto final es descripta con una
nica terminologa?
Hay un glosario en el cual el significado especfico de cada
trmino est definido?
Los requerimientos pueden ser entendidos, implementados
y verificados por un grupo independiente?
Hay un ndice?
Estn todas las figuras, tablas y diagramas necesarios?
Todas las figuras, tablas, y diagramas tiene referencias
cruzadas?
Todas las figuras, tablas y diagramas estn rotulados?
Todas las unidades de medida estn definidas?
Algn requerimiento debera estar especificado con ms
detalle?
Algn requerimiento debera estar especificado con menos
detalle?
Todos los requerimientos estn definidos?
Se ha definido qu informacin falta si es que falta alguna?
Estn incluidos todos los requerimientos relacionados con
la funcionalidad?
Hay algn requerimiento no satisfactorio?
el rendimiento?
interfaces externas?
permanencia de datos?
software a utilizar?
comunicaciones?
el hardware?
las entradas?
salidas?
No
NA.

Pgina 23 de 30
Revisin No: 1.0
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48

informes?
seguridad?
mantenibilidad?
la instalacin?
la criticidad?
la disponibilidad?
la recuperacin?
Los cambios posibles a los requerimientos estn
especificados?
La probabilidad del cambio est especificada para cada
requerimiento?
Existen distintos requerimientos que describen el mismo
objeto que entran en conflicto en lo referente a las
caractersticas?
Todos los requerimientos son trazables desde necesidades
especficas del usuario?
Todos los requerimientos son trazables desde fuentes
especficas (personas o documentos)?
Todos los requerimientos son trazables hacia documentos
de diseo especficos?
Todos los requerimientos son trazables hacia mdulos de
Software especficos?
Hay algn requerimiento que es imposible de verificar?
Para cada requerimiento hay un proceso que puede se
ejecutado por un humano o una mquina para verificar los
requerimientos?
El documento de requerimientos est organizado clara y
lgicamente?
La estructura del documento se adhiere a un estndar
aceptado?
Hay alguna redundancia en los requerimientos?
Cada requerimiento es relevante al problema y a su
solucin?
Algunos de los requerimientos definidos son en realidad
detalles de diseo?
detalles de verificacin?
detalles de gestin del proyecto?
Todas las fuentes de entrada estn especificadas?

Pgina 24 de 30
Revisin No: 1.0
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
Todos los requerimientos de precisin de las entradas

estn especificados?
Todos los rangos de las entradas estn especificados?
Todas las frecuencias de entradas estn especificadas?
Todos los formatos de entrada estn especificados?
Todos los requerimientos de precisin de las salidas estn
especificados?
Todos los rangos de las salidas estn especificados?
Todas las frecuencias de salidas estn especificadas?
Todos los formatos de salidas estn especificados?
Todas las funciones del software estn especificadas?
Todas las entradas para cada funcin estn especificadas?
Todos los aspectos de procesamiento exitoso para cada
funcin estn especificados?
Todos los aspectos de procesamiento no exitoso para cada
funcin estn especificados?
Todas las salidas para cada funcin estn especificadas?
Todos los requerimientos de desempeo para cada funcin
estn especificados?
Todas las restricciones de diseo para cada funcin estn
especificadas?
Todos los atributos para cada funcin estn definidos?
Todos los requerimientos de seguridad para cada funcin
estn definidos?
Todos los requerimientos de base de datos para cada
funcin estn definidos?
Todos los requerimientos operacionales estn definidos?
Todos los requerimientos de instalacin para cada funcin
estn definidos?
Todas las interfaces de usuario estn especificadas?
Todas las interfaces batch estn especificadas?
Todas las interfaces de hardware estn especificadas?
Todas las interfaces de software estn especificadas?
Todas las interfaces de comunicacin estn especificadas?
Todas las interacciones humano-computadora para las
interfaces de usuario estn especificadas?
Todos los tiempos de procesamiento esperados estn
especificados?
Todas las tasas de transferencia de datos estn
especificadas?
Todas las tasas de rendimiento (throughput) estn
especificadas?
Las consecuencias de las fallas del software para cada
requerimiento estn especificadas?
Est detallada la informacin a proteger de las fallas?

Pgina 25 de 30
Revisin No: 1.0
80
81
82
83
84
85
86
87
88
89
90
Esta especificada la memoria (principal) mnima?

Esta especificado el almacenamiento mnimo?
Esta especificada la memoria (principal) mxima?
Esta especificado el almacenamiento mximo?
Est definida la plataforma de software requerida?
Estn definidas las herramientas de software requeridas?
Todos los productos de software adquiridos que se usarn
con el sistema estn especificados?
El nmero estimado de conexiones de red est
especificado?
Los requerimientos de desempeo mnimos de la red estn
especificados?
Los requerimientos son verificables?
Los requerimientos son realistas?

Pgina 26 de 30
Revisin No: 1.0
CheckList para la revisin de SCM:

N1
1
2
3
4
5
6
7
8
9
10
Pregunta
Los productos de software a controlar estn identificados
claramente en el plan?
Existe una regla para nombrar a cada producto de
software?
Se especifica cundo se crea una nueva lnea base?
Se especifica qu productos son incluidos en la nueva
lnea base?
Se especifica quienes son responsables por los productos
incluidos en la lnea base?
Existe una regla para identificar las lneas base (versin)?
Existe un procedimiento de control de cambios bien
definido (qu debe hacer un integrante del grupo cuando
quiere modificar cualquier producto presente en la lnea
base)?
Se especifica en el plan si se reportar el estado de
implementacin de los cambios permitidos?
El plan asigna a cada actividad SCM un responsable?
El plan describe qu herramientas son utilizadas para
implementar las actividades SCM?
No
NA.

Pgina 27 de 30
Revisin No: 1.0
CheckList para la revisin del modelo de casos de uso.

N
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
Pregunta
Todos los actores del modelo son exactamente los que se
desprenden del Documento de Requerimientos?
Todos los actores estn claramente definidos y son
consistentes con el Documento de Requerimientos?
Se puede ver claramente desde el diagrama de casos de uso
y sus descripciones qu actores estn involucrados en cada
caso de uso?
Todos los actores estn conectados con los casos de uso
correctos de acuerdo al Documento de Requerimientos?
Todos los casos de uso del modelo son exactamente los que
se desprenden del Documento de Requerimientos?
Todos los casos de uso llevan a cumplir un solo objetivo
claramente definido?
Todos los casos de uso tienen nombres que trasmiten
claramente cul es su objetivo?
Todos los nombre de los casos de uso comienzan con un
verbo en infinitivo?
Todas las interacciones de los actores con el sistema son
consistentes con las descripciones de los actores?
Todas las descripciones de los casos de uso son consistentes
con el Documento de Requerimientos?
Todas las entradas y salidas estn correctamente definidas
para cada caso de uso?
Todos los flujos alternativos han sido cubiertos?
Todas las pre y postcondiciones para cada caso de uso estn
especificadas?
Todas los diagramas de los casos de uso concuerdan con las
descripciones de los mismos?
Todos los casos de uso estn escritos como casos de uso
esenciales?
Todos los casos de uso estn libres de detalles de
implementacin?
No
NA.
Pgina 28 de 30

Revisin No: 1.0
CheckList para la revisin de la Descripcin de la Arquitectura.
Pregunta
1
2
3
4
5
6
7
Se han considerado varios estilos arquitectnicos

diferentes antes de la definicin de la arquitectura
resultante?
La arquitectura seleccionada ha sido ejercitada en
escenarios reales?
Se especifican en el documento los mapeos entre los
requerimientos y el Modelo de Diseo?
Se especifican en el documento los mapeos entre el
Modelo de Diseo y el Modelo de Implementacin?
Se tienen en cuenta todas las propiedades de calidad
que debe tener el sistema?
Se ha alcanzado un grado adecuado de modularidad?
Se ha diseado para el cambio?
No
NA.
Pgina 29 de 30

Revisin No: 1.0
CheckList para la revisin del modelo de diseo.
Pregunta
1
2
3
4
5
Se han definido subsistemas como parte de la

representacin del diseo?
El SAD describe cada funcin usando una notacin
bien definida de tal manera que pueda ser verificada
contra el RQDRQ y que el cdigo pueda ser verificado
contra el SAD?
El modelo de diseo permite cumplir con todos los
requerimientos explcitos?
El modelo de diseo permite cumplir con todos los
requerimientos implcitos?
Se definieron los aspectos claves de la interfaz de
usuario?
Se describen y justifican las principales estructuras de
datos? Se describe la estructura usada para el manejo
de threads? Se describe la estructura para el
almacenamiento de filtros?
6
Se describen y justifican los algoritmos claves?
Manejo de filtro, manejo de threads, ordenamiento de
eventos.
10
11
12
13
Se describe como interactan los subsistemas entre si

mediante diagramas de secuencia. Por ejemplo si dado
un evento generado, se describe por que subsistemas
pasa antes de llegar al monitor.
Se localizaron operaciones crticas y se ubicaron en
un nmero reducido de subsistemas con poca
comunicacin? (se pens en el desempeo?)
Se estructuro en capas con los recursos ms crticos
protegidos por las capas ms internas con alto nivel de
validacin? (se pens en el seguridad?)
Todas las entradas y salidas estn identificadas y
descriptas con el detalle necesario para implementar el
programa?
El diseo toma en cuenta todos las situaciones y
condiciones esperadas?
El diseo especifica comportamiento apropiado al
enfrentar entradas inesperadas y otras condiciones
anmalas?
No
NA.

Pgina 30 de 30
Revisin No: 1.0
14
Se ha tenido en cuenta la facilidad de mantenimiento?

Como se pueden agregar nuevos sistemas para
monitorear sin tener que cambiar lo hecho, a que
mdulos afecta ste cambio? Como se pueden agregar
nuevos eventos a monitorear sin tener que cambiar los
ya existentes, a que mdulos afecta ste cambio?
El diseo hace uso de esconder la informacin como
se especifica a continuacin? Los mdulos estn
organizados de tal manera que cambios en los
requerimientos slo requieren cambios en pocos
mdulos. La funcionalidad es particionada en
programas para maximizar la cohesin y minimizar el
acoplamiento (alta cohesin y bajo acoplamiento). Se
ha tenido en cuenta la alta cohesin y bajo
acoplamiento de los componentes?
15
16
17
18
19
20
21
22
23
Se ha tenido en cuenta la identificacin y manejo de

excepciones?
Se ha tenido en cuenta la prevencin de faltas o la
tolerancia a faltas?
Se apunta al reuso de componentes? Cuales
componentes son reusables?
La notacin utilizada es consistente?
Se ha tenido en cuenta la facilidad de
implementacin?
Se ha alcanzado un grado adecuado de modularidad?
El diseo est libre de contradicciones internas?
El diseo es de baja complejidad?
El estilo de presentacin y el nivel de detalle son
consistentes ante todo el documento?
24
Son las funciones diseadas implementables con los
recursos disponibles?
25

Guia Sqpa 1 0

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Guia Sqpa 1 0

Încărcat de

Drepturi de autor:

Formate disponibile

Documento gua de SQAP

Descripcin: Describe una gua para el desarrollo de la norma

Fecha de revisin: Junio 2010

Documento gua de SQAP

Documento gua de SQAP

Descripcin: Describe una gua para el desarrollo de la norma

Fecha de revisin: Junio 2010

ESTNDARES, PRCTICAS, CONVENCIONES Y MTRICAS............................................13

Documento gua de SQAP

REPORTE DE PROBLEMAS Y ACCIONES CORRECTIVAS..................................................16

HERRAMIENTAS, TCNICAS Y METODOLOGAS............................................................17

Documento gua de SQAP

Descripcin: Describe una gua para el desarrollo de la norma

Fecha de revisin: Junio 2010

PE 1.1.1.PE 1.1.2.PE 1.1.3.PE 1.1.4.-

Documento gua de SQAP

PE 1.2.1.PE 1.2.2.PE 1.2.3.PE 1.2.4.-

Documento gua de SQAP

Descripcin: Describe una gua para el desarrollo de la norma

Revisin No: 1.0

Las definiciones establecen el significado en el contexto del SQAP. Otras

El resultado de dividir el total de mdulos en cual cada salto ha sido

Mtricas de punto de decisin:

El resultado de dividir el total de mdulos en los cuales cada punto de

Mtrica de Mensajes de Errores:

El resultado de dividir el total de mensajes de errores que han sido

Documento gua de SQAP

Un patrn sistemtico y planeado de acciones necesarias para proveer

Mtricas de demostracin de requerimientos:

El resultado de dividir el total de requerimientos independientes

Los siguientes contratos alfabticos aparecen dentro del texto de este

El encargado de SQA es el responsable de asegurar la calidad sobre los

Documento gua de SQAP

Descripcin: Describe una gua para el desarrollo de la norma

Fecha de revisin: Junio 2010

comportamiento responsable, y consiente acerca de decisiones tomadas que

Disciplinas (Lneas de trabajo)

Gestin de Configuracin (SCM)

Estructurar la tabla de referencia entre los elementos

Estructurar la tabla de los elementos de que integran la organizacin

Documento gua de SQAP

Revisar cada producto

Revisar las entregas

Revisar el ajuste al proceso

Realizar Revisin Tcnica Formal (RTF)

Asegurar que las desviaciones son documentadas.

Evaluacin final de calidad.

4.2.2. Revisar cada producto

Documento gua de SQAP

Se debe recoger la informacin necesaria de cada producto, buscando hacia

Documento gua de SQAP

Descripcin: Describe una gua para el desarrollo de la norma

Fecha de revisin: Junio 2010

4.2.5. Asegurar que las desviaciones son documentadas

Semana cuando se realiza

Los responsables de cada actividad se encuentran en el respectivo

Identificacin de la documentacin relativa a desarrollo, Verificacin &

Documento gua de SQAP

van a ser revisados para chequear consistencia: se confirman criterio e

Documentacin mnima requerida

Es la mnima para asegurar que la implementacin lograr satisfacer los

Ser consistente, no pueden haber elementos contradictorios.

Ser no ambigua, todo trmino referido al rea de aplicacin debe estar