UNIVERSIDAD NACIONAL PEDRO RUIZ

GALLO

Facultad de Ciencias Físicas y Matemáticas

INTEGRANTES:

RAMOS VENITES RICHARD

RODRIGUEZ CHISCUL ERICK
VASQUEZ CHAMAY KEVIN

PROFESOR:

CAMPOS FLORES, FREDDY

Lambayeque, Octubre del 2018.

Plan de SQA Página 1 de 15

ANÁLISIS Y DISEÑO DEL SISTEMA
DE MATRÍCULA DE LA INSTITUCIÓN
EDUCATIVA “APLICACIÓN” 10836

Plan de SQA
Versión [1.0]

Historial de revisiones
FECHA VERSIÓN DESCRIPCIÓN AUTOR
Ramos Benites Richard
18/10/2018 1.0 Creación del documento. Rodriguez Chiscul Erick
Vasquez Chamay Kevin
Ramos Benites Richard
30/10/2018 1.1 Revisión Rodriguez Chiscul Erick
Vasquez Chamay Kevin

Plan de SQA Página 2 de 15

 CONTENIDO

1. PROPÓSITO ..................................................................................................................................... 4
2. ACRÓNIMOS Y ABREVIATURAS ................................................................................................ 4
3. REFERENCIAS ................................................................................................................................. 4
4. GESTIÓN ............................................................................................................................................ 4
4.1. ORGANIZACIÓN ............................................................................................................................. 4
4.2. ACTIVIDADES ................................................................................................................................ 6
4.2.1. Ciclo de vida del software cubierto por el Plan ................................................................... 6
4.2.2. Actividades de calidad a realizarse ...................................................................................... 6
4.2.3. Revisar cada producto .......................................................................................................... 7
4.2.4. Revisar el ajuste al proceso .................................................................................................. 7
4.2.5. Realizar Revisión Técnica Formal (RTF) ............................................................................. 7
4.3. RESPONSABLES ............................................................................................................................. 8
5. DOCUMENTACIÓN ......................................................................................................................... 9
5.1. DOCUMENTACIÓN MÍNIMA REQUERIDA ......................................................................................... 9
5.1.1. Especificación de Requerimientos ........................................................................................ 9
5.1.2. Diseño del Sistema y Descripción de la Arquitectura ........................................................ 10
5.1.3. Plan de Verificación y Validación ...................................................................................... 10
5.1.4. Reportes de Verificación .................................................................................................... 11
6. ESTÁNDARES Y MÉTRICAS ....................................................................................................... 11
7. REVISIONES ................................................................................................................................... 12
7.1. DESCRIPCIÓN............................................................................................................................... 12
7.1.1. Revisión de Calidad de Producto ....................................................................................... 12
7.1.2. Revisión de Ajuste al Proceso............................................................................................. 13
7.1.3. Revisión Técnica Formal (RTF): ........................................................................................ 13
7.2. REQUERIMIENTOS MÍNIMOS ........................................................................................................ 14
7.2.1. Revisión de requerimientos................................................................................................. 14
7.2.2. Revisión de diseño preliminar ............................................................................................ 14
7.2.3. Revisión de diseño crítico ................................................................................................... 14
7.2.4. Revisión del Plan de Verificación & Validación ................................................................ 14
7.2.5. Revisiones de gestión .......................................................................................................... 14
7.2.6. Revisión Post Mortem ......................................................................................................... 14
7.3. AGENDA ...................................................................................................................................... 14
8. VERIFICACIÓN .............................................................................................................................. 14
9. REPORTE DE PROBLEMAS Y ACCIONES CORRECTIVAS ................................................ 14
10. HERRAMIENTAS, TÉCNICAS Y METODOLOGÍAS .............................................................. 14
11. GESTIÓN DE CONFIGURACIÓN ............................................................................................... 15
12. GESTIÓN DE RIESGOS ................................................................................................................. 15
13. CORRESPONDENCIA DE ESTE PLAN CON EL ESTÁNDAR IEEE 730 [1] ........................ 15

Plan de SQA Página 3 de 15

 1. Propósito

El propósito de este Plan SQA es:

• Mejorar la calidad del software, monitoreando apropiadamente tanto los

productos de software como el proceso de desarrollo que los genera.
• Asegurar el cumplimiento de los estándares y procedimientos
establecidos para el software y el proceso de software establecidos.
• Asegurar que cualquier desviación en el producto, el proceso, o los
estándares sean elevados a la gerencia para poder resolverlas.

Además, el software que se desea construir será un sistema que pretende realizar lo
siguiente:
• Reducir y optimizar el tiempo en los procesos de matrícula.
• Incrementar la eficiencia realizada por el personal administrativo de la I.E en
mención.
• Gestionar de manera más eficiente la entrega de calificaciones al alumnado.
• Organizar la documentación recibida por la I.E para la realización de los diferentes
procesos.

2. Acrónimos y Abreviaturas
SQA: Aseguramiento de la Calidad del Software.
V & V: Validación y Verificación.
RTF: Revisión Técnica Formal.
MCU: Modelos de Casos de Uso.
DCU: Diagramas de Casos de Uso.
DC: Diagramas de Clases.
DE: Diagramas de Estado.

3. Referencias
[1] IEEE Std 730-1998, IEEE Standard for Software Quality Assurance Plans.
[2] Norma ISO (International Organization for Standardization) 9001:2015.
[3] IS-1(2001) – Proyecto de Ingeniería de Software

4. Gestión
La gestión del proyecto de este proyecto estará a cargo del Administrador del
Proyecto, pero, además será controlado y monitoreado tanto por el Responsable
de SQA como por el Administra ya mencionado con anterioridad.
Ambos en conjunto controlaran y supervisaran que las actividades se ajusten a
este documento, evitando cualquier desviación del plan propuesto.
El Responsable SQA del área de gestión de calidad en el proyecto es el
responsable de realizar la gestión que asegura que el proceso establecido sea
realmente implementado y que los productos de ese proceso cumplan con los
criterios de calidad establecidos en este plan.

4.1 Organización
La mayoría de las actividades realizadas durante el proyecto impactan, en
mayor o menor medida, en la calidad del producto final.
Las líneas de trabajo con un impacto más directo son:

Plan de SQA Página 4 de 15

  Requerimientos
 Análisis
 Diseño
 Implementación
 Verificación

El equipo de trabajo está estructurado de la siguiente forma:

Nombres y
Rol Responsabilidades Específicas o Comentarios
Apellidos
 Proporcionar liderazgo en la planeación, organización y control del
esfuerzo del trabajo para lograr el objetivo establecido.
 Asegurar que el alcance del trabajo se termine con calidad, dentro del
presupuesto y a tiempo para que el cliente quede satisfecho.
 Coordinar las actividades de los distintos miembros del equipo para
Administrador Ramos Benites
asegurar que realicen las tareas correctas en el tiempo adecuado y
del Proyecto Richard trabajen como un grupo.
 Identificar a una persona o grupo que realice las funciones de SQA.
 Revisar y aprobar el Plan de aseguramiento de la calidad del proyecto.
 Resolver y dar seguimiento a cualquier asunto de calidad levantado por
el SQA.
 Asegurarse de que se realicen estudios de factibilidad.
 Asegurarse de que se desarrollen prototipos para probar y eliminar
riesgos técnicos que hagan fracasar el proyecto, así como también
disminuir la calidad del mismo
 Revisión Técnica Formal (RTF).
Administrador Vasquez Chamay
SQA Kevin.  Realizar mediciones para comprobar la calidad del proyecto
 Asegurarse de que se realice la actividad de implementación y se haga
según los estándares de calidad propuestos
 Evitar el desperdicio de esfuerzo en el proceso de construcción del
Software.
 Realizar el Informe Final de Calidad.
 El diseñador debe cumplir los plazos acordados en la documentación
 El diseñador debe corregir sus errores
Diseñador de Rodriguez Chiscul
 Implementar la calidad en el diseño de acuerdo a este plan de SQA.
Interfaz Erick
 El diseñador debe ser discreto.

 Implementar la calidad en las pruebas de acuerdo al plan SQA

 Resolver y dar seguimiento a cualquier asunto de calidad que tenga
Administrador Rodriguez Chiscul relación con las pruebas del sistema
Erick
de Pruebas  Verificar que los factores de calidad se implementaron en el sistema.
 Implementar las prácticas de pruebas en el sistema, procesos y
procedimientos, como está definido en el documento de pruebas.
 Implementar la calidad en la codificación de acuerdo a este plan de SQA.
 Identificar, implementar y evaluar los factores de calidad que van a ser
Ramos Benites
Desarrollador implementados en el sistema.
Richard
 Analizar los requerimientos y sugerencias de los Usuarios.

Plan de SQA Página 5 de 15

 Nombres y
Rol Responsabilidades Específicas o Comentarios
Apellidos
 Dar seguimiento a los riesgos identificados.
 Buscar medidas de contingencia de los riesgos identificados.
Administrador Vasquez Chamay  Comentar acerca del plan de aseguramiento de la calidad.
de Riesgos Kevin
 Notificar al administrador del proyecto cuando un riesgo identificado, se
convierta en un problema.

4.2 Actividades
4.2.1 Ciclo de vida del software cubierto por el Plan
A continuación, se muestran las etapas del ciclo de vida en las que se realizarán
revisiones, y para cada una, se muestra los productos a los cuales se les realizarán
revisiones:

 Análisis:
Especificación de Requerimientos.
Modelos de Casos de uso.
 Requerimientos.
Documento de Especificación de Requerimientos.
Modelo de Casos de Uso.
Alcance del Sistema.
Pautas de Interfaz de Usuario.
 Diseño.
Descripción de la Arquitectura.
 Implementación.
Informe de Verificación unitaria.
 Verificación.
Plan de Verificación y Validación.
Plan de Verificación de la iteración.
Modelo de Casos de Prueba.
 Implantación.
Materiales para Soporte al Usuario.
Plan de Implantación.
 Gestión de Proyecto.
Plan del Proyecto.
Gestión de Riesgos.
Plan de la Iteración.

4.2.2 Actividades de calidad a realizarse

Las tareas a ser llevadas a cabo deberán reflejar las evaluaciones a realizar,
los estándares a seguir, los productos a revisar, los procedimientos a seguir
en la elaboración de los distintos productos y los procedimientos para

Plan de SQA Página 6 de 15

 informar de los defectos detectados a sus responsables y realizar el
seguimiento de los mismos hasta su corrección.

Las actividades que se realizarán son:

 Revisar cada producto
 Revisar el ajuste al proceso
 Realizar Revisión Técnica Formal (RTF)

4.2.3 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 revisión previos, si se
encuentra alguna no resuelta, debe ser incluida en la siguiente revisión. Se
debe identificar, documentar y seguir la pista a las desviaciones
encontradas y verificar que se hayan realizado las correcciones. Como
salida se obtiene el Informe de revisión de SQA, este informe debe ser
distribuido a los responsables del producto y se debe asegurar de que son
conscientes de desviaciones o discrepancias encontradas.

4.2.4 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. Se debe recoger la información necesaria de cada
producto, buscando hacia atrás los productos previos que deberían haberse
generado, para poder establecer los criterios de revisión y evaluar si el
producto cumple con las especificaciones. Esta información se obtiene de
los siguientes documentos: Plan del Proyecto, Plan de la iteración, Plan de
Verificación. Antes de comenzar, se debe verificar en los informes de
revisión 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 revisión de SQA correspondiente a la evaluación de ajuste al
Proceso, este informe debe ser distribuido a los responsables de las
actividades y se debe asegurar de que son conscientes de desviaciones o
discrepancias encontradas.

4.2.5 Realizar Revisión Técnica Formal (RTF)

El objetivo de la RTF es descubrir errores en la función, la lógica o la
implementación de cualquier producto del software, verificar que satisface
sus especificaciones. Es un proceso de revisión riguroso, su objetivo es
llegar a detectar lo antes posible, los posibles defectos en el software que
se van generando a lo largo del desarrollo. Por esta característica se adopta
esta práctica para productos que son de especial importancia.

Plan de SQA Página 7 de 15

 En la reunión participan el responsable de SQA e integrantes del equipo
de desarrollo. Se debe convocar a la reunión 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 duración de la reunión no debe ser mayor
a dos horas. Como salida se obtiene el Informe de RTF.

4.2.6 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.7 Relaciones entre las actividades de SQA y la planificación

En esta sección se incluye una lista con las actividades de calidad a
realizarse durante el proyecto, especificando en que semana del proyecto
se realizan.
Actividad Semana cuando se realiza
Elaboración del Plan de SQA 7
Revisar el ajuste al proceso 7, 8, 9
Evaluación final de SQA 15
Evaluación de la calidad de los productos 9, 10, 11, 12
Evaluar y ajustar el Plan de SQA 7, 8, 9, 10
Realizar Revisión Técnica Formal (RTF) 10, 11, 12
Identificación de Propiedades de Calidad 1, 2, 3, 4

4.3 Responsables
A continuación, se muestra una lista con los responsables de cada una de
las disciplinas del proyecto.
Disciplina Responsable
Requerimientos Grupo de Trabajo
Diseño Rodriguez Chiscul Erick
Implementación Grupo de Trabajo
Verificación Rodriguez Chiscul Erick
Implantación No definido aún
Gestión de Configuración y Control
Vasquez Chamay Kevin
de Cambios
Gestión de Proyecto Ramos Benites Richard
Gestión de Calidad Vasquez Chamay Kevin

Plan de SQA Página 8 de 15

5 Documentación
Identificación de la documentación relativa a desarrollo, Verificación &
Validación, uso y mantenimiento del software.
Establecer como los documentos van a ser revisados para chequear consistencia:
se confirman criterio e identificación de las revisiones.

5.1 Documentación mínima requerida

Esta busca asegurar que la implementación logrará satisfacer los
requerimientos.

5.1.1 Especificación de Requerimientos

El documento de especificación de requerimientos deberá describir,
de forma clara y precisa, cada uno de los requerimientos esenciales
del software además de las interfaces externas.
El cliente deberá obtener como resultado del proyecto una
especificación 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.

La especificación debe:
 Ser completa:
a. Externa, respecto al alcance acordado.
b. Internamente, no deben existir elementos sin especificar.

 Ser consistente, no puede haber elementos contradictorios.

 Ser no ambigua, todo término referido al área de aplicación
debe estar definido en un glosario.
 Ser verificable, debe ser posible verificar siguiendo un método
definido, si el producto final cumple o no con cada
requerimiento.
 Estar acompañada 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 específicos del software que
tienen incidencia sobre la calidad en el uso y se detallan a
continuación:

Usabilidad
a. Comprensible.
b. Aprendible.
c. Operable.
d. Atractivo.

Eficiencia
a. Comportamiento respecto al tiempo.

Plan de SQA Página 9 de 15

 b. Utilización de recursos.

Mantenibilidad
a. Modificable.
b. Verificable.
Portabilidad
a. Adaptable.
b. Instalable.

Cada uno de estos atributos debe cumplir con las normas y regulaciones
aplicables a cada uno.

5.1.2 Diseño del Sistema y Descripción de la Arquitectura

 Se requiere que el aplicativo pueda desarrollarse en el Sistema

operativo Windows, ya que las computadoras con las que cuenta las I.E
tienen instalado el Sistema Operativo en mención.
 La aplicación de be contar con toda la documentación necesaria, así
como un manual de usuario, para facilitar el uso del aplicativo a l
persona que se encuentre encargada.
 El Sistema debe contar con una ventana de autentificación para evitar
el mal uso de los datos que se almacena.
 La aplicación deberá contar con interfaces amigables y de fácil uso,
dando al usuario una mejor experiencia con el uso del software.

 El sistema debe proporcionar mensajes de error que sean informativos

y orientados al usuario final, por si el usuario está usando
incorrectamente el aplicativo.

5.1.3 Plan de Verificación y Validación

El Plan de V & V deberá identificar y describir los métodos a ser
utilizados en:
 La verificación de que:
a. los requerimientos descritos en el documento de requerimientos
han sido aprobados por una autoridad apropiada. En este caso sería
que cumplan con el acuerdo logrado entre el cliente y el equipo.
b. los requerimientos descritos en el documento de requerimientos
son implementados en el diseño expresado en el documento de
diseño.
c. el diseño expresado en el documento de diseño esta
implementado en código.
 Validar que el código, cuando es ejecutado, se adecua a los
requerimientos expresados en el documento de requerimientos.

Plan de SQA Página 10 de 15

 5.1.4 Reportes de Verificación
Estos documentos deben especificar los resultados de la ejecución de los
procesos descritos en el Plan de V & V.

5.1.5 Documentación de usuario

La documentación 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
ejecución exitosa del software.
Todos los errores deben ser identificados y las acciones correctivas
descritas.
Como resultado del proyecto el cliente obtendrá una documentación para
el usuario de acuerdo a los requerimientos específicos del proyecto.
5.1.6 Plan de Gestión de configuración
El Plan de gestión de configuración debe contener métodos para
identificar componentes de software, control e implementación de
cambios, y registro y reporte del estado de los cambios implementados.

6 Estándares y Métricas
6.1 Estándares
Como estándares de documentación se definirán dos documentos:
 Estándar de documentación técnica

La documentación técnica del producto debe:

 Ser adecuada para que un grupo independiente del de desarrollo pueda
manejar el mantenimiento del producto.
 Incluir fuentes, Modelos de Casos de Uso, Objetos

Para la escritura de documentos se han definido plantillas para ser utilizadas en la

elaboración de entregables.
En estas plantillas se definen:
 encabezado y pie de página.
 fuente y tamaño de fuente para estilo normal
 fuente y tamaño de fuente para los títulos a utilizar
 datos mínimos que se deben incluir: fecha, versión y responsables.

Se busca reflejar en la documentación los siguientes atributos de calidad:

 Legibilidad
o Estructura
o Tamaño
o Ilustraciones
o Facilidad para ubicar información relevante

Plan de SQA Página 11 de 15

  Completo
 Correcto

La responsabilidad de cumplir con los estándares definidos es del encargado de

cada entregable, definido en el plan de iteración. El responsable de SQA junto con
su asistente revisará el cumplimiento de éstos estándares y reportará eventuales
defectos a los correspondientes responsables.

6.2 Métricas
Las siguientes mediciones se harán y se utilizarán para determinar el costo y el
calendario de la situación de las actividades a lo largo del proyecto:

a. Tiempo Estimado
b. Tiempo real invertido
c. Esfuerzo planeado
d. Esfuerzo realizado
e. Costo planeado
f. Costo real
g. Número de incumplimiento sin arreglar
h. Número de incumplimiento arreglados
i. Número total de incumplimientos

Para ver más detalles ver el plan métricas.

El personal de métricas es responsable de la presentación de informen a estas

medidas al director del proyecto sobre una base quincenal.

7 Revisiones
7.1 Descripción
En esta sección se definen los tres tipos de revisiones (Revisión de Calidad
de Producto, Revisión de Ajuste al Proceso y Revisión Técnica Formal – RTF
–), sus objetivos y mecanismos.
7.1.1 Revisión de Calidad de Producto
Objetivo: Revisar los productos que se definieron como claves para
asegurar la calidad. Detectar desviaciones en los objetivos de calidad
definidos e informar a los responsables para que sean corregidas.
Mecanismo:
Se revisan los productos para verificar que cumplan con los
estándares (sección 6) y con los objetivos de calidad utilizando las
checklists definidas para el producto.
Se debe verificar que no queden correcciones sin resolver en los
informes de revisión previos, si se encuentra alguna no resuelta, debe
ser incluida en la siguiente revisión. Se debe identificar, documentar
y seguir la pista a las desviaciones encontradas y verificar que se
hayan realizado las correcciones.
Como salida se obtiene el Informe de revisión de SQA, que contiene
todas las desviaciones o defectos encontrados durante la revisión.
Este informe debe ser distribuido a los responsables del producto y

Plan de SQA Página 12 de 15

 se debe asegurar que ellos son conscientes de las desviaciones o
discrepancias encontradas y de las acciones correctivas que deben
realizar.
7.1.2 Revisión de Ajuste al Proceso
Objetivo: Revisar si los productos se obtuvieron realizando las
actividades que se indican en el Modelo de Proceso.
Mecanismo:
Se revisan los productos que se definen como claves para verificar el
cumplimiento de las actividades definidas en el proceso, durante todo
el ciclo de vida del software.
Se debe recoger la información necesaria de cada producto, buscando
hacia atrás los productos previos que deberían haberse generado y
son entradas para el producto objeto de revisión, para poder
establecer los criterios de revisión y evaluar si el producto cumple con
las especificaciones.
Esta información se obtiene de los siguientes documentos:
 Plan del Proyecto
 Plan de la Desarrollo
 Plan de Verificación y Validación
Se debe verificar si todos los pasos del proceso de desarrollo son
seguidos apropiadamente.
Antes de comenzar, se debe verificar en los informes de revisión
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 revisión de SQA
correspondiente a la revisión de ajuste al proceso, que contiene todas
las desviaciones o defectos encontrados durante la revisión. Este
informe debe ser distribuido a los responsables de las actividades y
se debe asegurar que ellos son conscientes de las desviaciones o
discrepancias encontradas y de las acciones correctivas que deben
realizar.
7.1.3 Revisión Técnica Formal (RTF):
Objetivo: Descubrir errores en la función, la lógica ó la
implementación de cualquier producto del software, verificar que
satisface sus especificaciones, que se ajusta a los estándares
establecidos, señalando las posibles desviaciones detectadas.

Mecanismo: Es un proceso de revisión 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
característica se adopta esta práctica para productos que son de
especial importancia.
En la reunión participan el responsable de SQA e integrantes del
equipo de desarrollo.
Se debe convocar a la reunión 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.
Como salida se obtiene el Informe de RTF.

Plan de SQA Página 13 de 15

 7.2 Requerimientos Mínimos
7.2.1 Revisión de requerimientos
Esta revisión se realiza para asegurar que se cumplió con los
requerimientos especificados por el Cliente.
7.2.2 Revisión de diseño preliminar
Esta revisión se realiza para asegurar la consistencia y suficiencia técnica
del diseño preliminar del software.
7.2.3 Revisión de diseño crítico
Esta revisión se realiza para asegurar la consistencia del diseño detallado
con la especificación de requerimientos.
7.2.4 Revisión del Plan de Verificación & Validación
Esta revisión se realiza para asegurar la consistencia y completitud de los
métodos especificados en el Plan de V & V.
7.2.5 Revisiones de gestión
Estas revisiones se realizan periódicamente para asegurar la ejecución de
todas las actividades identificadas en este Plan. Deben realizarse por una
persona ajena al grupo de trabajo (en caso de que sea posible).
7.2.6 Revisión Post Mortem
Esta revisión se realiza al concluir el proyecto para especificar las
actividades de desarrollo implementadas durante el proyecto y para
proveer recomendaciones.
7.3 Agenda
En esta sección se detallan todas las revisiones de calidad que se realizarán
durante todo el proyecto organizado por fase e iteración.
8 Verificación
No se encontraron más verificaciones que las expuestas en el Plan de verificación
y validación.
9 Reporte de problemas y acciones correctivas
Cuando finalice la elaboración de un producto, el responsable de SQA realizará
la revisión del mismo, procediendo a informar al responsable de dicho producto
en caso de encontrar errores. Según el momento de la semana en que se
entregue el producto, se podrá corregir el mismo o incluir la corrección en la
semana siguiente.
10 Herramientas, técnicas y metodologías
Para elaborar una buena evaluación del proyecto deben incluirse herramientas
CASE para SQA, analizadores de código, simuladores, paquetes de análisis,
herramientas de comunicación, etc.
Dentro de las técnicas destacan los estándares, revisiones, verificación de
requerimientos y de diseño, mediciones, análisis de defectos.
Por otro lado, las metodologías corresponden a la integración de las
herramientas y técnicas. Deben ser claramente especificadas.

Plan de SQA Página 14 de 15

11 Gestión de configuración
El objetivo del SQA en esta área es asegurar que se realizan las actividades de
gestión de configuración establecidas en el Plan de Configuración y que se
realizan tal como están establecidas en el proceso.
12 Gestión de riesgos
Los riesgos identificados, la estrategia de mitigación, monitoreo y plan de
contingencia a ser llevados a cabo, están descritos en el Documento de Riesgos
13 Correspondencia de este plan con el estándar IEEE 730 [1]
Secciones del estándar
Secciones de este plan
IEEE 730 [1]
1 Propósito 1 Propósito
2 Acrónimos y Abreviaturas, se agrega a este
plan.
2 Referencias 3 Referencias
3 Gestión 4 Gestión
4 Documentación 5 Documentación
5 Estándares, prácticas, 6 Estándares y métricas
convenciones y métricas
6 Revisiones y auditorias 7 Revisiones
7 Test 8 Verificación
8 Reporte de problemas y 9 Reporte de problemas y acciones correctivas
acción correctiva
9 Herramientas, técnicas y 10 Herramientas, técnicas y metodologías
metodologías
10 Control de código 11 Gestión de configuración
11 Control de medios 11 Gestión de configuración
12 Control de proveedores No aplica a este plan, porque no hay
proveedores en los proyectos donde se aplica
el mismo
13 Recopilación de registros, No aplica a este plan, porque los registros que
mantenimiento y retención serán generados por el responsable de SQA
son los entregables que se generan durante el
proyecto y ya están explicitados en la sección
4.2 Tareas
14 Entrenamiento No aplica a este plan, porque las actividades
de entrenamiento para alcanzar las
necesidades del plan de SQA no forman parte
del proyecto.
15 Gestión de riesgos 12 Gestión de riesgos

Plan de SQA Página 15 de 15