M09-Gestión SQA v1.3

M09 - Metodología Gestión SQA INTESIS
Desarrollo de Software Servidor Terminológico (SEMANTIKOS)
SERVICIO DE SALUD METROPOLITANO OCCIDENTE

Tabla de Contenido
............................................................................................................................................................. 1
1 Introducción ............................................................................................................... 4
2 Objetivos.................................................................................................................... 5
3 Alcances .................................................................................................................... 5
4 Fase 1: Inicio y Fase 2: Elaboración ......................................................................... 6
4.1 Objetivo ..................................................................................................................... 6
5 Fase 3: Construcción y Fase 4: Pruebas .................................................................. 6
5.1 Objetivo ..................................................................................................................... 6
6 Fase 5: Transición ..................................................................................................... 7
6.1 Objetivo ..................................................................................................................... 7
7 Fase 6: Producción y Retiro ...................................................................................... 7
8 GESTIÓN ÁREA SQA ................................................................................................................. 8
8.1 FASE DE INICIO .................................................................................................... 8

8.1.1 Artefactos ................................................................................................................ 10
8.2 FASE DE ELABORACIÓN ...................................................................................... 13

8.2.1 Artefactos ................................................................................................................ 13
8.3 FASE DE CONSTRUCCIÓN ................................................................................... 18

8.3.1 Artefactos ................................................................................................................ 18
8.3.2 Pruebas de Aceptación ........................................................................................... 22
8.4 FASE DE TRANSICIÓN ......................................................................................... 23

8.4.1 Artefactos ................................................................................................................ 24
9 REVISIÓN DE ARTEFACTOS Y PRUEBAS DE SOFTWARE .............................................. 30
2
9.1 REVISIÓN DE ARTEFACTOS ................................................................................. 30
9.1.1 Criterios de Revisión ............................................................................................... 30
9.1.2 Catalogación de Observaciones ............................................................................. 32
9.1.3 Criterios de Aprobación ........................................................................................... 33
9.2 TESTING DE SOFTWARE...................................................................................... 37

9.2.1 Criterios de Testing de Software ............................................................................. 37
9.2.2 Catalogación de Defectos ....................................................................................... 38
9.2.3 Criterios de Aprobación ........................................................................................... 39
9.3 INDICADORES DE CALIDAD .................................................................................. 44

9.3.1 Indicadores de Calidad para el proceso de Testing de Software ........................... 44
Este índice demuestra mayor calidad del artefacto mientras más se acerque a cero ............. 45
9.3.2 Índice de Calidad iteraciones de la pieza de software ............................................ 45
9.3.3 Índice de estado de los defectos detectados .......................................................... 46
9.3.4 Índice de Riesgos Mensual ..................................................................................... 46
10 CHECKLIST DE REVISIÓN DE ARTEFACTOS ................................................................ 47
3
1 Introducción
Dado que es factor crítico de éxito en el desarrollo de proyectos de software y es necesario contar
con un plan de acciones que permitan obtener el producto en la calidad, costo y plazo deseado,
Intesis utilizando las mejores prácticas del negocio, usa el procedimiento SQA - Software Quality
Assurance (Aseguramiento de la Calidad del Software), basado en la metodología usada en el
proyecto - , definiendo las actividades a realizar para el proyecto del Cliente.
El proceso de revisión y testing es el encargado de evaluar la calidad de los artefactos y piezas de
software, no solamente en la instancia de aprobación o rechazo del producto final, sino que
formando parte de todo el ciclo de vida del proyecto, para así generar acciones oportunas de
mejoras sobre puntos deficitarios, a fin de asegurar la calidad y no alterar las variables de tiempo y
costo. Se define revisión a la verificación de artefactos y testing o a la verificación de las piezas de
software.
Para llevar a cabo el SQA, se identifica el siguiente equipo de trabajo y sus funciones de
cumplimiento:
 Equipo QA Interno: Está formado por los integrantes de las diferentes disciplinas que participan
en todas las fases del proyecto revisando los artefactos, prácticas y estándares en las distintas
etapas y realizando el testing y pruebas de aceptación con el Cliente, a fin de asegurar la calidad
desde el inicio del proyecto hasta su puesta en producción. Sus actividades en el ámbito de SQA
son:
o Revisión cruzada o de pares de los artefactos generados, con el objetivo de verificar
integridad y consistencia
o Cuando corresponda, la validación de artefactos generados o disponibilizados por otra fase o
disciplina.
El ámbito en el cual se desarrolla este plan, corresponde a las actividades a realizar por el Equipo
QA Interno, de aquí en adelante referido como área SQA, para el proyecto.
4
2 Objetivos
El propósito de este Plan se resume en los siguientes puntos:
o Definir el proceso y los procedimientos del área SQA, definiendo las instancias de revisión,
las actividades que involucra y sus propósitos.
o Reconocer los entregables a QA en cada fase del proyecto, indicando la disciplina
responsable y los aspectos de su revisión.
o Definir los entregables de QA y sus propósitos.
3 Alcances
El Plan SQA para el proyecto, tiene como finalidad asegurar que los artefactos o productos
definidos, bajo la metodología usada en el proyecto cumplan con los niveles de calidad
establecidos según las convenciones y procedimientos especificados por el área SQA.
Para llevar a cabo este objetivo, el proceso de calidad considera la realización de actividades en
todas las fases de desarrollo de la arquitectura SOA, desde la gestión de proyecto hasta la puesta
en producción de los productos de software.
Estas actividades consideran tareas de revisión, testing, registro y seguimiento de defectos y
observaciones, todas aplicables en menor y en mayor grado en cada una de las fases de desarrollo
del producto: Incepción, Elaboración, Construcción, Transición y Producción. Teniendo en
consideración que el área SQA no interfiere en el ámbito SQA interno de cada Disciplina, sino en
los entregables de las mismas en las diferentes fases del proyecto.
Para entender cuál es el tipo de revisión que se realizará en cada una de las fases usada en el
proyecto, es necesario describir el marco y alcance general de cada una de las etapas, por lo cual
se define a continuación el propósito y principales artefactos disponibles en cada fase usada en el
proyecto:
5
4 Fase 1: Inicio y Fase 2: Elaboración
4.1 Objetivo
El objetivo de la fase de Inicio es realizar el levantamiento de requerimientos de alto nivel con el

objetivo de validar y verificar el alcance de requerimientos del proyecto. En este período se detalla
el alcance del proyecto y se detallan los planes de trabajo. Intesis participa entregando su
conocimiento funcional y estableciendo los requerimientos.
Es importante mencionar que para cumplir con el requisito Fase 1: Inicio, es necesario contar con
el documento funcional sobre la gestión del proyecto y la estructura de la arquitectura de la
solución, antes de la fecha de inicio de este proceso. Esta información es necesaria para la
generación de los conectores y configuración de los aplicativos
Se entiende que el atraso de cualquiera de los requisitos antes mencionados, repercutirá

directamente con los plazos del proyecto.
5 Fase 3: Construcción y Fase 4: Pruebas
5.1 Objetivo
El objetivo de la fase Construcción es detallar los requerimientos al producto, elaborar los

requisitos de arquitectura, establecer el enfoque de pruebas, criterios de aceptación en el proyecto
y generan la implementación base.
Además de transformar el Diseño elaborado en la Fase 2: Elaboración, en los componentes ya

mencionados con anterioridad que conforman la solución. Esta fase ha sido abordada en una
etapa, con actividades de construcción, pruebas unitarias y de revisión por parte de Intesis para
verificar que las funcionalidades estén correctamente implementadas. Al final de esta fase se
cuenta con el aplicativo completo con respecto al ciclo de negocio elegido y definido por el Cliente.
Estará listo para ser sometido a pruebas integrales junto con los planes de prueba a aplicar.
6
El objeto de la fase Pruebas es verificar el correcto funcionamiento de la aplicación, considerando
el flujo de negocio indicado por Intesis. Esta fase será abordada con actividades de pruebas
integrales.
6 Fase 5: Transición
6.1 Objetivo
El objetivo de esta fase es verificar el correcto funcionamiento de la aplicación, para su paso a

producción.
7 Fase 6: Producción y Retiro
7.1 Objetivo
El objetivo de la fase es la de Certificación Completa habilitando el ambiente de producción,
capacitar a los usuarios, y soportar la aplicación en producción en un Piloto. Al término de estas
actividades se entrega la versión de la aplicación definitiva, junto con la documentación asociada.
La definición y objetivos de cada una de estas fases exponen las ideas principales de la
metodología usada en el proyecto, sin embargo, es preciso indicar que la metodología en cada
fase reconoce Disciplinas. Ambos conceptos, Fase y Disciplina, forman parte del ciclo de desarrollo
de software propuesto por la metodología usada en el proyecto. Las disciplinas usadas en el
proyecto están enfocadas en tres ámbitos:
 Disciplinas de Desarrollo
 Disciplinas de Soporte
 Disciplinas Enterprise
El Plan SQA pertenece a la Disciplina de Desarrollo, denominada Testing.
7
8 Gestión Área SQA
El área SQA define, desde una perspectiva global, las actividades que son necesarias para dar
cumplimiento al aseguramiento de la calidad, las cuales se definen para cada una de las fases de
la metodología (usada en el proyecto) por cada disciplina de desarrollo.
Para verificar la adherencia de los atributos de calidad en un determinado producto o artefacto de
software se definen las siguientes actividades:
 Revisión de Artefactos
 Definición de Indicadores de Calidad
 Testing de Software
 Reporte y Seguimiento de observaciones y defectos
 Definición de estándares, prácticas y convenciones de calidad
A continuación se detalla la gestión del área SQA por cada fase usada en el proyecto, desde la
fase de Incepción hasta la fase de Construcción.
8.1 Fase de Inicio
En esta fase la gestión del área SQA tiene como foco principal:
 Revisión de los artefactos disponibles para cada disciplina

 Aprobación del cierre de la fase de Incepción y paso a la fase de Elaboración
 Desarrollo de artefactos de la disciplina de Testing, enfocados a la revisión o testing de
“Prototipos de Mitigación de Riesgos”
8
9
8.1.1 Artefactos
Los artefactos generados y/o actualizados, junto con los que el área SQA revisa por cada disciplina
en la fase de Incepción, son los siguientes:
Artefacto Generado y/o Actualizado Artefacto Validado por el Área SQA

de Disciplina
 Modelo de Negocio  Modelo de Negocio

 Modelo de Entidades de Dominio  Modelo de Entidades de Dominio
 Matriz de Trazabilidad Entidades de  Matriz de Trazabilidad Entidades de
Dominio x BP Dominio x BP
Modelamiento
 Glosario de Conceptos de Negocio  Glosario de Conceptos de Negocio

Negocio
 Modelo de Requerimientos  Modelo de Requerimientos

 Documento de Visión  Documento de Visión
Requerimientos
 Matriz de Trazabilidad Requerimientos por  Matriz de Trazabilidad Requerimientos por

BP BP
 Modelo de RQ  Modelo de RQ
 Especificaciones de RQ  Especificaciones de RQ
 Diagramas de Actividad de RQ  Diagramas de Actividad de RQ
 Modelo de Clases de Análisis y Diagramas  Modelo de Clases de Análisis y Diagramas
de Estado de Estado
 Prototipo GUI  Prototipo GUI
 Diagrama de Navegabilidad  Diagrama de Navegabilidad
 Matriz de Trazabilidad de Requerimientos  Matriz de Trazabilidad de Requerimientos x
Análisis
x RQ RQ
 Matriz de Trazabilidad de Mapeo GUI x  Matriz de Trazabilidad de Mapeo GUI x RQ
10
RQ  Matriz de Trazabilidad de RQ x Clases de
 Matriz de Trazabilidad de RQ x Clases de Análisis
Análisis
 Matriz de Trazabilidad de Reportes por
RQ
 Diagramas de Clases de Diseño y Estados  Diagramas de Clases de Diseño y Estados
 Prototipo de Mitigación de Riesgos  Matriz de Trazabilidad Clases de Análisis x
 Matriz de Trazabilidad Clases de Análisis Clases de Diseño
x Clases de Diseño  Matriz de Trazabilidad Clases de Diseño x
 Matriz de Trazabilidad Clases de Diseño x RQ
Diseño
RQ
 Diagrama de Tablas  No Aplica
 Matriz de Trazabilidad Tablas x Clases de
Diseño
 Aplicación – UI
Implementación
 Aplicación – Negocio
 Aplicación – Reporte
 Diccionario de Datos de la Aplicación
 Script de Carga de Datos
 SAD – Software Architecture Description  SAD – Software Architecture Description
Arquitectura
 Plan de QA  Plan de QA
 Diagrama de Casos de Prueba  Diagrama de Casos de Prueba
 Casos de prueba  Casos de prueba
 Escenarios Sistémicos  Escenarios Sistémicos
 Datos de Prueba  Datos de Prueba
 Reportes de Ejecución de Pruebas  Reportes de Ejecución de Pruebas
Pruebas
 Minuta de Prueba de Aceptación  Matriz de Trazabilidad RQ x Casos de

 Matriz de Trazabilidad RQ x Casos de Pruebas
11
Pruebas
 Plan de Despliegue  No aplica

 Guía de Usuario
 Guía de Operaciones
Despliegue
 Material de Capacitaciones
 Nota de Entrega
 Plan de Proyecto  Plan de Proyecto
 Plan de Administración de Requerimientos  Plan de Administración de Requerimientos
 Plan de Comunicación
 Plan de Administración de Riesgos
 Minuta / Agenda de Reunión
Administración de Proyecto
 Minuta / Agenda de Reunión  Lista de Riesgos

 Lista de Riesgos  Carta Gantt
 Carta Gantt  Estado de Avance
 Estado de Avance
 Documento de Lecciones Aprendidas
 Plan de SCM  Plan de SCM

la
Administración
 Repositorio  Repositorio
Configuración
de
La revisión de cada artefacto se realiza según criterios especificados en las secciones Revisión de
Artefactos y Checklist de Revisión de Artefactos.
12
El artefacto Ficha de Actividades y respectivo Diagrama de Actividades, de la disciplina de
Modelamiento de Negocio, tienen su origen en la fase de Pre Incepción ya aprobado por el Cliente,
por tal motivo este artefacto no es observable ni modificable. A pesar de ello la disciplina Testing
los tomará como base para la comprensión del negocio.
El artefacto “Reportes de Ejecución de Pruebas” elaborado por la disciplina de Testing es el
resultado de la verificación del “Prototipo de Mitigación de Riesgos” desarrollado por la disciplina de
Diseño. El propósito del Reporte de Ejecución de Pruebas es informar las pruebas ejecutadas y
resultados obtenidos, indicando, si existiera, el desvío de los resultados esperados.
La condición necesaria para la aprobación del cierre de la fase de Incepción y paso a la fase de
Elaboración se basa en la completitud, consistencia y claridad lograda, la posibilidad de extrapolar
escenarios y los indicadores de calidad obtenidos según revisión de artefactos y riesgos vigentes.
Detalle de indicadores de calidad en la sección Indicadores de Calidad
8.2 Fase de Elaboración
 Revisión de los artefactos disponibles para cada disciplina

 Aprobación del cierre de la fase de Elaboración y paso a la fase de Construcción
 Elaboración de artefactos de la disciplina de Testing, enfocados al testing de software que
tiene lugar en la siguiente fase y a la revisión o testing de “Prototipos de Mitigación de Riesgos”
8.2.1 Artefactos
en la fase de Elaboración, son los siguientes:
13
Disciplina
 Modelo de Negocio  No Aplica

Modelamiento de Negocio
 Modelo de Entidades de Dominio

 Matriz de Trazabilidad Entidades de
Dominio x BP
 Glosario de Conceptos de Negocio
 Ficha de Actividades
 Modelo de Requerimientos  No Aplica

 Documento de Visión
 Matriz de Trazabilidad Requerimientos por
BP
Requerimientos
 Actas de Aprobación
 Minuta de Requerimientos de Análisis
 Modelo de RQ  Modelo de RQ
 Especificaciones de RQ  Especificaciones de RQ
 Diagramas de Actividad de RQ  Diagramas de Actividad de RQ
 Modelo de Clases de Análisis y Diagramas  Modelo de Clases de Análisis y Diagramas
de Estado de Estado
 Prototipo GUI  Prototipo GUI
 Diagrama de Navegabilidad  Diagrama de Navegabilidad
 Matriz de Trazabilidad de Requerimientos  Matriz de Trazabilidad de Mapeo GUI x RQ
x RQ  Matriz de Trazabilidad de RQ x Clases de
 Matriz de Trazabilidad de Mapeo GUI x Análisis
RQ  Matriz de Trazabilidad de Reportes por RQ
Análisis
 Matriz de Trazabilidad de RQ x Clases de

Análisis
14
RQ
 Diagramas de Clases de Diseño y Estados  Diagramas de Clases de Diseño y Estados

 Prototipo de Mitigación de Riesgos  Prototipo de Mitigación de Riesgos
 Matriz de Trazabilidad Clases de Análisis  Matriz de Trazabilidad Clases de Análisis x
x Clases de Diseño Clases de Diseño
 Matriz de Trazabilidad Clases de Diseño x  Matriz de Trazabilidad Clases de Diseño x
Diseño
RQ RQ
Diseño
Implementación
 SAD – Software Architecture Description  SAD – Software Architecture Description
Arquitectura
 Plan de QA  Plan de QA
 Diagrama de Casos de Prueba  Diagrama de Casos de Prueba
 Casos de prueba  Casos de prueba
 Escenarios Sistémicos  Escenarios Sistémicos
 Datos de Prueba  Datos de Prueba
 Reportes de Ejecución de Pruebas  Reportes de Ejecución de Pruebas
 Minuta de Prueba de Aceptación  Matriz de Trazabilidad RQ x Casos de
Pruebas
 Matriz de Trazabilidad RQ x Casos de Pruebas

Pruebas
15
 Plan de Despliegue  No aplica
Despliegue
 Nota de Entrega
 Plan de Proyecto  Minuta / Agenda de Reunión
Plan de Administración de  Lista de Riesgos
Requerimientos  Carta Gantt

Plan de Comunicación
Plan de Administración de Riesgos


 Lista de Riesgos
 Carta Gantt
 Plan de SCM  No Aplica

la
Administración
 Repositorio
Configuración
de
El artefacto “Reportes de Ejecución de Pruebas” elaborado por la disciplina de Pruebas es el
resultado de la revisión o testing de “Prototipos de Mitigación de Riesgos” desarrollados por la
disciplina de Diseño. El propósito del Reporte de Ejecución de Pruebas es informar las pruebas
ejecutadas y resultados obtenidos, indicando, si existiera, el desvío de los resultados esperados.
16
Los restantes artefactos elaborados, para cada proyecto de Administración de Personas, por la
disciplina de Testing en esta fase tienen los siguientes propósitos:
 Plan de QA: este artefacto corresponde a un documento en formato Word almacenado en

CVS. Su propósito es declarar el ámbito de las pruebas, objetivo de las pruebas, elementos a
testear, estimación de recursos y tiempos a consumir. En el caso de que la disciplina de
Implementación informe que realizará entregas parciales de la pieza de software, se detalla en el
Plan de QA, el ámbito y contenido de cada una de estas Iteraciones.
 Diagrama de Casos de Prueba: este artefacto corresponde a un diagrama de casos de

prueba almacenado en VISIO. Su propósito es representar la secuencia de aplicación de los casos
de prueba elaborados por cada caso de uso sistémico del proyecto.
 Casos de Prueba: este artefacto corresponde a la especificación unitaria de casos de

prueba. Son obtenidos de los casos de uso sistémicos y artefactos a fin del proyecto, constan de
datos de entrada, un procedimiento de realización de la prueba, identifica las funcionalidades a
probar y los resultados esperados. Cabe mencionar que el equipo del Cliente entrega, cuando
estime necesario, casos o escenarios especiales, que considere relevantes para ser ejecutados
durante las pruebas funcionales.
Corresponde a una planilla Excel almacenada en CVS. Su propósito es declarar los casos de
prueba del proyecto que deben ser ejecutados una vez construida la pieza de software.
 Escenarios Sistémicos: este artefacto corresponde a un modelo de acciones del usuario y

del sistema, son obtenidos de los casos de uso sistémicos del proyecto y se almacenan en VISIO.
Su propósito es proporcionar visibilidad global del proyecto entrelazando los casos de uso
sistémicos del proyecto, logrando así escenarios globales.
 Datos de Prueba: este artefacto corresponde a los datos que se utilizarán para la ejecución
de los casos de prueba, se obtienen de los Casos de Prueba. Corresponde a una planilla Excel
almacenada en CVS. Su propósito es identificar las características de los datos de pruebas
requeridos para la ejecución de los Casos de Prueba. En los casos en que la obtención de datos
presenta inconvenientes o bien se requiere de información asociada a otros actores del sistema, el
17
equipo del Cliente aporta su conocimiento y posición para facilitar la obtención o generación de
Datos de Prueba.
 Matriz de Trazabilidad RQ x Casos de Pruebas: este artefacto corresponde a la matriz

almacenada en VISIO que es extrapolada de la elaboración de casos de prueba. Su propósito es
representar la relación existente entre casos de uso sistémicos y los casos de prueba elaborados.
La condición necesaria para la aprobación del cierre de la fase de Elaboración y paso a la fase de
Construcción se basa en la completitud, consistencia y claridad lograda, la estabilización del
modelado de negocio y análisis, la definición del 100% de los escenarios sistémicos y los
indicadores de calidad obtenidos según revisión de artefactos y riesgos vigentes. Detalle de
indicadores de calidad en la sección Indicadores de Calidad
8.3 Fase de Construcción
 Testing de software
 Elaboración de artefactos de la disciplina de Testing
 Ejecución de Pruebas de Aceptación con el Cliente
 Aprobación del cierre de la fase de Construcción y paso a la fase de Transición
8.3.1 Artefactos
en la fase de Construcción, son los siguientes:
18
Disciplina


Dominio x BP

BP
Requerimientos
 Modelo de RQ  No Aplica
 Especificaciones de RQ
 Diagramas de Actividad de RQ
 Modelo de Clases de Análisis y Diagramas
de Estado
 Prototipo GUI
 Diagrama de Navegabilidad
 Matriz de Trazabilidad de Requerimientos
x RQ
 Matriz de Trazabilidad de Mapeo GUI x
RQ
Análisis

Análisis
19
RQ
 Diagramas de Clases de Diseño y Estados  No Aplica

 Prototipo de Mitigación de Riesgos
 Matriz de Trazabilidad Clases de Análisis
x Clases de Diseño
 Matriz de Trazabilidad Clases de Diseño x
Diseño
RQ
 Diagrama de Tablas  Diagrama de Tablas
 Matriz de Trazabilidad Tablas x Clases de  Matriz de Trazabilidad Tablas x Clases de
Diseño Diseño
 Aplicación – UI  Aplicación – UI
Implementación
 Aplicación – Negocio  Aplicación – Negocio

 Aplicación – Reporte  Aplicación – Reporte
 Diccionario de Datos de la Aplicación  Diccionario de Datos de la Aplicación
 Script de Carga de Datos  Script de Carga de Datos
 SAD – Software Architecture Description  No Aplica
Arquitectura
 Plan de QA  Datos de Prueba

 Diagrama de Casos de Prueba  Reportes de Ejecución de Pruebas
 Casos de prueba  Minuta de Prueba de Aceptación
 Escenarios Sistémicos
 Datos de Prueba
 Reportes de Ejecución de Pruebas
 Minuta de Prueba de Aceptación
Pruebas
 Matriz de Trazabilidad RQ x Casos de

Pruebas
20
 Plan de Despliegue  Plan de Despliegue
 Guía de Usuario  Guía de Usuario
 Guía de Operaciones  Guía de Operaciones
Despliegue
 Material de Capacitaciones  Material de Capacitaciones

 Nota de Entrega  Nota de Entrega
 Plan de Administración de  Lista de Riesgos
 Carta Gantt
Requerimientos


 Carta Gantt

la
Administración
 Repositorio
Configuración
de
En esta fase la disciplina de Pruebas contempla la estabilización del Plan de QA y Datos de
pruebas utilizados. El artefacto “Reportes de Ejecución de Pruebas” elaborado por la disciplina de
Testing en esta fase es el resultado del proceso de Testing de Software. La Minuta de Prueba de
Aceptación corresponde al resultado de las Pruebas de Aceptación realizadas en conjunto con el
Cliente, este proceso es descrito en la sección Pruebas de Aceptación.
21
La condición necesaria para la aprobación del cierre de la fase de Construcción y paso a la fase de
Transición se basa en la construcción lograda respecto al cumplimiento de las especificaciones y
los indicadores de calidad obtenidos según revisión de artefactos, testing de software y riesgos
vigentes. Detalle de indicadores de calidad en la sección Indicadores de Calidad. Adicionalmente
se debe dar cumplimiento a las Pruebas de Aceptación con el Cliente, proceso que se describe en
la siguiente sección Pruebas de Aceptación.
8.3.2 Pruebas de Aceptación
Una vez finalizados los procesos de revisión de artefactos y de testing de software con resultados
exitosos, se está en condiciones de realizar las Pruebas de Aceptación con el Cliente.
Las Pruebas de Aceptación tienen como finalidad que el Cliente valide y verifique que el sistema o
pieza de software se ajuste a sus requerimientos y necesidades. El área SQA lleva a cabo una
demostración formal del funcionamiento de la pieza de software.
Los participantes requeridos para la ejecución de las Pruebas de Aceptación son:
Cliente: Responsable Técnico (Analista SQA)
Responsable de Negocio
Intesis: Analista SQA
Líder de Proyecto
Analista Senior
22
Analista Programador
Dependiendo de la complejidad del componente abordado, aumentará el número de Analistas de
Intesis y responsables del Cliente.
Las pruebas a realizar en las sesiones de pruebas de aceptación son acordadas previamente entre
el área SQA y los Responsables Técnico y de Negocio Cliente, para ello el área SQA realiza una
propuesta de los casos de prueba a ejecutar. Esta propuesta es aceptada u objetada por el
Cliente. En éste último escenario es el Cliente quien da las directrices para la selección de casos
de pruebas a ejecutar o bien propone sus propios casos y datos de prueba.
Una vez finalizada la Prueba de Aceptación, el Cliente y demás participantes firman la
correspondiente Minuta de Prueba de Aceptación, que contiene las pruebas realizadas y
eventuales acuerdos de modificación o incorporación.
Si el resultado es exitoso el Cliente aprueba mediante la minuta descrita, el paso a Producción de
la pieza de software verificada. Esto según programación acordada.
Si el resultado no es satisfactorio el Cliente indica las razones del rechazo del paso a Producción
de la pieza de software y se establecen acuerdos de plazos y condiciones para una posterior
demostración formal del funcionamiento de la pieza de software.
8.4 Fase de Transición
 Verificar el correcto funcionamiento de la aplicación, para su paso a producción.

 Preparar ambiente de Pruebas
23
 Aprobación Pruebas de Componentes
8.4.1 Artefactos
en la fase de Transición, son los siguientes:

Disciplina


Dominio x BP

BP
Requerimientos
 Modelo de RQ  No Aplica
 Especificaciones de RQ
Análisis
 Diagramas de Actividad de RQ
24
 Modelo de Clases de Análisis y Diagramas
de Estado
 Prototipo GUI
 Diagrama de Navegabilidad
 Matriz de Trazabilidad de Requerimientos
x RQ
 Matriz de Trazabilidad de Mapeo GUI x
RQ
Análisis
RQ
 Diagramas de Clases de Diseño y Estados  No Aplica
 Prototipo de Mitigación de Riesgos
 Matriz de Trazabilidad Clases de Análisis
x Clases de Diseño
 Matriz de Trazabilidad Clases de Diseño x
Diseño
RQ
Diseño
Implementación
 SAD – Software Architecture Description  No Aplica
Arquitectura
25
 Plan de QA  Reportes de Ejecución de Pruebas
 Diagrama de Casos de Prueba  Minuta de Prueba de Aceptación
 Casos de prueba
 Escenarios Sistémicos
 Datos de Prueba
 Reportes de Ejecución de Pruebas
 Minuta de Prueba de Aceptación
Pruebas
 Matriz de Trazabilidad RQ x Casos de

Pruebas
 Plan de Despliegue  Nota de Entrega
Despliegue
 Nota de Entrega
Plan de Administración de  Lista de Riesgos
Requerimientos  Carta Gantt

Plan de Comunicación  Documento de Lecciones Aprendidas
Plan de Administración de Riesgos


 Carta Gantt
26
la
Administración  Repositorio
Configuración
de
27
8.4.2 Workflow Pruebas de Aceptación
La interacción dada en las Pruebas de Aceptación se puede visualizar en el siguiente flujo de
trabajo:
28
Definición de las Pruebas de Aceptación
El analista SQA se comunica con los Responsables de
Negocio y Técnico del Proyecto, indicando propuesta
de pruebas a realizar detallando datos utilizados y
transacciones a ejecutar
Responsables de Negocio y Técnico Cliente.

¿Responsables de
indican pruebas a realizar
Cliente aceptan
Los Responsables de Negocio y Usuarios Proy. indican No
prueba
las pruebas que desean realizar en la sesión de
propuesta?
Pruebas de Aceptación
Si
Coordinación Prueba de Aceptación

Se acuerda fecha, hora y lugar de la Prueba de Aceptación entre los
participantes: Responsable Técnico. - Responsable de Negocio -
Analista SQA - Líder de Proyecto – Analista Senior
- Analista Programador
El Analista SQA prepara datos y verifica ambiente y parametrización
de acuerdo a las pruebas a realizar
Realización de la Prueba de
Aceptación
Se llevan a cabo las pruebas acordadas
con Cliente
Generación de Minuta con Observaciones ¿Existen

El analista SQA genera minuta detallando las observaciones del
pruebas realizadas y resultado de las mismas, Si Cliente tras las
indicando las observaciones del Cliente y acuerdos pruebas
relacionados indicados por el líder de proyecto realizadas?
No
¿Los Responsables Generación de Minuta sin observaciones

del Cliente señalan que El analista SQA genera minuta detallando las
las observaciones pruebas realizadas y resultado de las mismas
detectadas impiden la
aprobación de la
componente? No
Firma de Minuta de Aprobación

Los participantes de la sesión firman minuta de
Si aceptación donde se aprueba el paso a
Producción del componente probado
Firma de Minuta de Acuerdos
Los participantes de la sesión firman minuta de
acuerdo donde se indica la razón del rechazo por parte
del Cliente del paso a Producción y se indican plazos
para la posterior prueba de aceptación con las
observaciones del Cliente aplicadas
29
9 Revisión de Artefactos y Pruebas de Software
Para que un proceso de calidad sea efectivo es necesario definir los criterios de evaluación, los
cuales se encuentran relacionados con el tipo de verificación, revisión de artefactos o pruebas de
software.
9.1 Revisión de Artefactos
El proceso de revisión de artefactos se relaciona con la verificación de especificaciones, las cuales
son generadas desde la fase de incepción en adelante, las consideraciones de este proceso se
detallan a continuación.
9.1.1 Criterios de Revisión
En el proceso de revisión de artefactos se consideran los siguientes criterios:
 Claridad y Simplicidad
El artefacto debe ser preciso y entendible.
 Completitud
El artefacto no debe contener ambigüedades, ni temas sin resolver, en el caso de existir
pendientes debe explicitar responsable y fecha de solución. Adicionalmente no debe contener
términos del tipo:
30
o Términos vagos: algún, a veces, a menudo, usualmente, en general, etc. La ocurrencia debe
estar explicitada y fundamentada
o Comparaciones ambiguas: más alto, más bajo, mayor, menor, máximo, mínimo. Las
comparaciones deben ser fundamentadas “respecto a”.
o Rangos No definidos: Los valores varían entre 1 y 100, etc. Los rangos deben ser
claramente definidos explicitando consideraciones del tipo: los valores son enteros, reales, etc.
o Cálculos No definidos: [(a+b-c)*d]/e. Los cálculos deben explicitar el tratamiento numérico,
correspondientes a la acción de redondear, truncar o aproximar según corresponda.
 Consistencia
Los artefactos se encuentran relacionados entre sí. No deben existir inconsistencias y deben
utilizar los mismos conceptos. Las referencias descritas deben ser correctas y no deben existir
elementos contradictorios.
 Redacción
El artefacto debe estar escrito respetando un lenguaje claro, siempre en tercera persona y tiempo
verbal presente, no se deben utilizar términos persuasivos (ciertamente, claramente, obviamente,
se deduce que, etc.), los términos utilizados deben ser expuestos en un lenguaje cordial.
 Ortografía
El artefacto no debe contener faltas de ortografía.
 Correctitud
El artefacto debe ser consecuencia de los requerimientos y formar parte de la especificación global
del producto a construir, manteniendo uniformidad con las técnicas, términos utilizados, notaciones
definidas en templates y guías oficializadas.
 Trazabilidad
Los artefactos deben mantener en su desarrollo la correspondiente trazabilidad con los demás
artefactos.
31
9.1.2 Catalogación de Observaciones
Las observaciones detectadas en el proceso de revisión de artefactos, podrán ser catalogadas en
tres niveles de severidad: Grave, Mediana y Menor, cuya clasificación dependerá de la magnitud
del error cometido.
A continuación se grafica la relación entre criterio y severidad:
CRITERIO SEVERIDAD
Grave Mediana Menor
Claridad y Simplicidad X X
Completitud X X
Consistencia X X
Redacción X X X
Ortografía X X
Correctitud X X
Trazabilidad X X
32
9.1.3 Criterios de Aprobación
Un artefacto será aprobado si y sólo si NO posee observaciones de severidad Grave ni
observaciones de severidad Mediana.
9.1.4 Workflow de Revisión de Artefactos
Para lograr mayor efectividad en el proceso de revisión de artefactos, se requiere la participación
del analista SQA en reuniones de trabajo previas a la entrega oficial de artefactos al área SQA de
cada disciplina. Una vez efectuadas estas reuniones el Workflow de Revisión de Artefactos es el
siguiente:
33
Recepción de Artefactos
La solicitud la realiza la disciplina solicitante a través
del Jira indicando ubicación de los artefactos con su
respectivo Tag CVS y VISIO, asignando la solicitud al
analista SQA definido para el proyecto en cuestión
Reunión de exposición de artefactos

La disciplina presenta los artefactos al analista
SQA, señalando consideraciones especiales y
cualquier tema que considere relevante para
la revisión
Revisión de artefactos
El analista SQA realiza la revisión
conforme a los criterios y checklist
definidos
¿Existen
observaciones?
No
Si
Reunión de entrega y resolución de

observaciones Registro de conformidad de artefactos
El analista SQA presenta a la Disciplina las El analista SQA registra la conformidad del área
observaciones detectadas, acordando cada una SQA con los artefactos revisados en el
en el transcurso de la reunión requerimiento Jira y procede a resolverlo
Cierre del Requerimiento

No de revisión
¿Existen La Disciplina cierra el
observaciones que requerimiento de revisión
generan
modificaciones?
Si
Registro de modificaciones acordadas

El analista SQA registra los acuerdos en el
requerimiento Jira y lo asigna al responsable de
la Disciplina
34
9.1.5 Workflow de Reporte de Observaciones
Las observaciones detectadas en el proceso de revisión de artefactos, son reportadas en el
siguiente Workflow de estados:
EP
Ingresar
EP
Open Inválido
inválidar
EP
Corregido
revisar
ESQA
revisar
EP
corregido
En revisión ESQA En corrección

corregir
ESQA
cerrar
EP: Equipo Proyecto

Cerrado ESQA: Equipo SQA
Nota: En todos los estados se podrá reasignar a otro

responsable, ingresar un comentario, adjuntar archivos,
Linkear a otros issues o editar los mismos.
1.1.1.1.
35
9.1.6 Workflow de Revisión de Prototipos de Mitigación
El Workflow de Revisión de Prototipos de Mitigación de Riesgos es el siguiente:
Solicitud de prueba de prototipo de

mitigación de riesgo
La solicitud la realiza la disciplina de Diseño a través de
Jira indicando ubicación de artefactos asociados con su
respectivo Tag CVS y VISIO, asignando la solicitud al
analistas SQA definido para el proyecto en cuestión
Reunión de coordinación de prueba

Los analistas de SQA y Diseño se reunen para
afinar condiciones de la prueba, esclarecer
objetivos, coordinar tiempos y establecer
criterios de revisión
Revisión de prototipo
El analista SQA realiza la revisión
conforme a los criterios acordados
Reporte de Ejecución de la prueba

El analista SQA adjunta el reporte del resultado
de las pruebas en el requerimiento Jira y lo
deja en estado resuelto
Si
Presentación del resultado de la prueba
El analista SQA presenta al analista de Diseño
solicitante el resultado de la prueba
Cierre del requerimiento

El analista programador procede a cerrar el
requerimiento de prueba de prototipo de
mitigación de riesgo
¿Se requiere
de una nueva
prueba?
No
36
9.2 Testing de Software
El proceso de testing de software se relaciona con la verificación de la pieza de software construida
según las especificaciones generadas desde la fase de incepción en adelante, las consideraciones
de este proceso se detallan a continuación.
9.2.1 Criterios de Testing de Software
Los factores de calidad que son considerados en el modelo de calidad para el testing de una pieza
de software son:
 Confiabilidad
Se refiere a la fiabilidad en el funcionamiento del producto. El producto es capaz de funcionar sin
errores en cualquier circunstancia y siempre de acuerdo a las especificaciones definidas.
 Seguridad
Considera si el producto de software, de acuerdo a las especificaciones definidas, contempla todos
los aspectos de seguridad necesarios para garantizar el control de acceso y manejo de datos en el
sistema.
 Usabilidad
Se relaciona con la cantidad de esfuerzo requerido para aprender a utilizar o manejar el producto.
La pieza de software debe responder a los estándares de usabilidad definidos para el proyecto.
 Integridad entre componentes

Se refiere a la correcta operación de la pieza de software en conjunto con otros componentes o
módulos. La pieza de software debe procurar integridad dentro del sistema como también con
sistemas externos, según corresponda.
 Verificabilidad
37
Se refiere a que la pieza de software debe ser verificable de acuerdo a las especificaciones
definidas.
 Precisión
Se refiere a que la pieza de software debe proporcionar el grado de certeza requerido en los
cálculos que contempla, de acuerdo a las especificaciones definidas.
 Mantenimiento
Se relaciona con la capacidad de localizar y corregir defectos una vez que el producto esta
funcionando.
9.2.2 Catalogación de Defectos
Un defecto generado tras el testing de software es producto de una desviación de la construcción e
implementación respecto a las especificaciones definidas.
Los defectos detectados en el proceso de testing de software, podrán ser catalogados en cuatro
niveles de severidad, cuya clasificación dependerá del grado de desviación que la pieza de
software presenta respecto de las especificaciones definidas y del alcance del defecto sobre el
testing.
Severidad Descripción
Crítico El defecto impide acceder a la funcionalidad. Las pruebas de la pieza de software
deben suspenderse. El defecto no permite continuar la operación del sistema.
38
Grave Es posible acceder a la funcionalidad, pero la misma no puede ser ejecutada en
forma completa. La ejecución de la prueba no cumple con el resultado esperado.
Existe una severa desviación respecto a los requerimientos. El defecto restringe
la ejecución de gran parte de la funcionalidad definida. No existe un camino
alternativo de solución.
Mediano Es posible acceder a la funcionalidad, ésta no se ejecuta completamente o no
cumple con el resultado esperado, pero existe un camino alternativo para cumplir
la funcionalidad.
Menor El defecto no afecta el correcto funcionamiento de la aplicación. No es crítico para
el desempeño del usuario ni afecta la información del sistema.
9.2.3 Criterios de Aprobación
Un proceso de testing se ejecuta con la intención de asegurar el correcto funcionamiento de una
pieza de software. Esta fase puede llevar días, meses y hasta años, sin embargo; ¿Cómo saber
cuándo es necesario dejar de hacer pruebas?. Normalmente para tomar esta decisión es necesario
definir anticipadamente el grado de exigencia funcional y los criterios de aprobación de la pieza de
software.
A continuación se proponen los siguientes criterios de aprobación, los cuales indicarán las
condiciones necesarias que se deben cumplir en el proceso de testing para que éste sea
considerado satisfactorio.
39
Resultados Resultados En el proceso de En el proceso de Aprobación
Resultado de Pruebas de Pruebas Pruebas se Pruebas se
(SI/NO)
de recaban Req. recaban Req.
con con Defectos
Pruebas Nuevos Nuevos Bajo
Defectos
sin Medianos o Impacto
Menores Alto Impacto
Defectos Graves
(SI/NO)
(%) (SI/NO)
(SI/NO)
100% 0% NO NO NO SI
80% < 20% NO NO NO SI
80% < 20% NO NO SI SI
- - - SI - NO
- - SI - - NO
- > 20% - - - NO
Se define como un nuevo requerimiento a toda funcionalidad del Sistema que no se encuentra
especificada en los artefactos de análisis generados y aprobados por el Cliente.
Los nuevos requerimientos serán tipificados según el impacto que provocan en el sistema, de la
siguiente manera:
Tipo Descripción
40
Nuevo Requerimiento El requerimiento impacta fuertemente en la funcionalidad del
Alto Impacto componente. El esfuerzo de implementarlo en esta etapa es

grande
Nuevo Requerimiento El requerimiento es de bajo impacto en la funcionalidad del
Bajo Impacto componente. El esfuerzo de implementarlo en esta etapa
podría no ser importante.
En función a las definiciones anteriores, las piezas de software serán aprobadas cuando:
 No existan defectos Medianos

 No existan defectos Graves
 No existen defectos Menores detectados en más del 20% de las pruebas
 No existan Nuevos Requerimientos de Alto impacto
Una vez que la pieza de software se encuentre aprobado, se está en condiciones de llevar a acabo
las Pruebas de Aceptación con el Cliente. Sección Pruebas de Aceptación no se encontró
documento
41
9.2.4 Workflow de Testing de Software
El Workflow de Testing de Software es el siguiente:
Recepción de la pieza de software

La solicitud la realiza la disciplina de despliegue,
adjuntando la correspondiente Nota de Entrega y
asignando la solicitud al analista SQA definido para el
proyecto
Prueba de Humo
El analista SQA realiza una prueba de
humo a fin de verificar la versión
entregada cumple con las funcionalidades
mínimas para dar inicio a las pruebas
Registro del rechazo del testing de software

El analista SQA registra el rechazo de la pieza de ¿Prueba de Solicitud de carga de datos
software en el requerimiento y procede Rechazar Test No Humo El analista SQA solicita la carga de datos
Funcional adjuntando el Reportes de Ejecución de exitosa? de prueba a analistas programador
Pruebas
Si Carga de Datos
Si El analista programador realiza la
carga de datos
¿Se requiere
carga de
datos? Revisión de Carga de Datos
El analista SQA verifica la carga
de datos No
No
Revisión de artefactos
El analista SQA realiza el testing ¿La carga de
conforme al Plan de QA, Si datos es
Escenarios Sistémicos y correcta?
Casos de Prueba elaborados
¿Existen
No
defectos?
Registro de aprobación de la pieza de
software
No El analista SQA registra la aprobación de la pieza
Si de software y procede Aprobar Test Funcional
Reporte de defecto en circuito Jira

El analista SQA reporta los defectos detectados Paso a producción
según catalogación correspondiente La disciplina de Despliegue prepara la entrega
formal de la pieza de software al cliente, junto
con la migración de datos requerida y la
Si correspondiente capacitación al usuario
¿La versión
cumple los
criterios de
aprobación?
42
9.2.5 Workflow de Reporte de Defectos
Los defectos detectados en el proceso de testing de software son reportados en el siguiente
Workflow de estados:
ESQA
Ingresar
ESQA
Open Inválido
inválidar
EI
posponer
EI
corregir Pospuesto
EI
corregir
En corrección
ESQA EI
re-corregir resolver
Resuelto
ESQA
cerrar
EI: Equipo Implementación
Cerrado ESQA: Equipo SQA
Nota: En todos los estados se podrá reasignar a otro

responsable, ingresar un comentario, adjuntar archivos,
Linkear a otros issues o editar los mismos.
43
9.3 Indicadores de Calidad
La disciplina de testing es la responsable de evaluar la calidad durante todo el ciclo de vida del
proyecto, a fin de proporcionar información que permita generar las acciones oportunas de mejoras
sobre puntos deficitarios, con el objetivo de asegurar la calidad y no alterar las variables de tiempo
y costo.
Para medir la calidad se requiere recopilar y analizar información, la cual da origen a los
indicadores de calidad.
Para el proceso de revisión de artefactos y testing de software, la medida de la calidad nace de la

recopilación de la siguiente información:
 Observaciones en la revisión de artefactos, acordadas por artefacto y por nivel de

severidad
 Defectos en el testing de software, detectados por versión y por nivel de severidad
 Riesgos detectados por fase
De este modo se tienen los siguientes indicadores de calidad:
9.3.1 Indicadores de Calidad para el proceso de Testing de Software
ISi: Índice de Calidad de la pieza de software, testing versión i
La medición del Índice de Calidad, por cada versión de pieza de software, en cada fase, está dada
por la distribución de defectos detectados, considerando severidad y tamaño del artefacto.
44
ISi: Índice de Calidad versión i.
Di: Nº total de defectos encontrados durante la versión desarrollada de la pieza de software.
Ci: Nº total de defectos críticos detectados en la versión i.
Gi: Nº total de defectos graves detectados en la versión i.
Mdi: Nº total de defectos medianos detectados en la versión i.
Mei: Nº total de defectos menores detectados en la versión i.
Pj: Ponderación para defectos críticos, graves, medianos y menores, donde j=1, 2, 3, 4.
C  G   Md i   Mei 
IS i  P1  i   P2  i   P3    P4  
 Di   Di   Di   Di 
Este índice demuestra mayor calidad del artefacto mientras más se acerque a cero
9.3.2 Índice de Calidad iteraciones de la pieza de software
La medición del índice de calidad, en la iteración de versiones, en cada fase, está dado por el
efecto acumulativo de cada ISi, que se obtiene asignando un peso mayor a los defectos detectados
en versiones posteriores de la pieza de software.
 i * ISi
IDS  i 1
Ps
45
Donde,
Ps: Tamaño del producto (cantidad de casos de prueba asociados) en la versión i.
n: Número de iteraciones de la pieza de software
Este índice demuestra mayor calidad del artefacto mientras más se acerque a cero.
9.3.3 Índice de estado de los defectos detectados
Este índice corresponde a la cantidad de defectos vigentes; es decir aquellos defectos que se han
reportado y sobre los cuales no se ha obtenido respuesta en un transcurso de 3 días hábiles.
La medición del estado de defectos detectados, permite visualizar cuándo se requieren recursos
adicionales, en la disciplina de Diseño, para la resolución de defectos.
Este índice demuestra correcta dotación de recursos, si los defectos detectados sin respuesta, en
el transcurso de 3 días hábiles, tienden a cero.
9.3.4 Índice de Riesgos Mensual
En el transcurso del proyecto, toda disciplina debe levantar los riesgos que visualice que
comprometen el correcto desarrollo del proyecto y que afectan las variables de tiempo y costo.
Estos riesgos son asignados al responsable correspondiente.
El índice de riesgos se obtiene de la identificación de los riesgos levantados asociados al proyecto
en un mes. Se consideran los estados: Riesgos Atendidos y Riesgos No Atendidos. Donde Riesgos
46
No Atendidos corresponden a aquellos que no se encuentran solucionados ni están en vías de
solución. De este modo para el mes “m” se tiene el siguiente Índice de Riesgos Mensual:
RiesgosNoAtendidosm
IRm 
TotalRiesgosDetectados m
Este índice resulta aceptable, cuando los riesgos se encuentran resueltos o en proceso de solución
IRm  0,2
en un porcentaje mayor o igual al 80%, esto es: .
10 Checklist de Revisión de Artefactos
En los checklist para la revisión de artefactos se encuentran los principales puntos a verificar en la
revisión de cada artefacto, los cuales son generados y/o actualizados en cada fase del proyecto
según lo descrito en la sección Gestión Área SQA
Los niveles de error definidos para la revisión de artefactos son:
47
Nivel de Error Descripción
1 Observación Grave
2 Observación Mediana
3 Observación Menor
48

M09-Gestión SQA v1.3

Cargado por

Copyright:

Formatos disponibles

M09-Gestión SQA v1.3

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

M09-Gestión SQA v1.3

Cargado por

Copyright:

Formatos disponibles

M09 - Metodología Gestión SQA INTESIS

Desarrollo de Software Servidor Terminológico (SEMANTIKOS)

SERVICIO DE SALUD METROPOLITANO OCCIDENTE

4 Fase 1: Inicio y Fase 2: Elaboración ......................................................................... 6

4.1 Objetivo ..................................................................................................................... 6

5 Fase 3: Construcción y Fase 4: Pruebas .................................................................. 6

5.1 Objetivo ..................................................................................................................... 6

6 Fase 5: Transición ..................................................................................................... 7

6.1 Objetivo ..................................................................................................................... 7

7 Fase 6: Producción y Retiro ...................................................................................... 7

8 GESTIÓN ÁREA SQA ................................................................................................................. 8

8.1 FASE DE INICIO .................................................................................................... 8

8.2 FASE DE ELABORACIÓN ...................................................................................... 13

8.3 FASE DE CONSTRUCCIÓN ................................................................................... 18

8.3.2 Pruebas de Aceptación ........................................................................................... 22

8.4 FASE DE TRANSICIÓN ......................................................................................... 23

9 REVISIÓN DE ARTEFACTOS Y PRUEBAS DE SOFTWARE .............................................. 30

9.1.2 Catalogación de Observaciones ............................................................................. 32

9.1.3 Criterios de Aprobación ........................................................................................... 33

9.2 TESTING DE SOFTWARE...................................................................................... 37

9.2.2 Catalogación de Defectos ....................................................................................... 38

9.2.3 Criterios de Aprobación ........................................................................................... 39

9.3 INDICADORES DE CALIDAD .................................................................................. 44

9.3.2 Índice de Calidad iteraciones de la pieza de software ............................................ 45

9.3.3 Índice de estado de los defectos detectados .......................................................... 46

9.3.4 Índice de Riesgos Mensual ..................................................................................... 46

10 CHECKLIST DE REVISIÓN DE ARTEFACTOS ................................................................ 47

Assurance (Aseguramiento de la Calidad del Software), basado en la metodología usada en el

proyecto - , definiendo las actividades a realizar para el proyecto del Cliente.

El proceso de revisión y testing es el encargado de evaluar la calidad de los artefactos y piezas de

costo. Se define revisión a la verificación de artefactos y testing o a la verificación de las piezas de

QA Interno, de aquí en adelante referido como área SQA, para el proyecto.

El propósito de este Plan se resume en los siguientes puntos:

establecidos según las convenciones y procedimientos especificados por el área SQA.

en producción de los productos de software.

Estas actividades consideran tareas de revisión, testing, registro y seguimiento de defectos y

del producto: Incepción, Elaboración, Construcción, Transición y Producción. Teniendo en

los entregables de las mismas en las diferentes fases del proyecto.

se define a continuación el propósito y principales artefactos disponibles en cada fase usada en el

El objetivo de la fase de Inicio es realizar el levantamiento de requerimientos de alto nivel con el

Se entiende que el atraso de cualquiera de los requisitos antes mencionados, repercutirá

5 Fase 3: Construcción y Fase 4: Pruebas

El objetivo de la fase Construcción es detallar los requerimientos al producto, elaborar los

Además de transformar el Diseño elaborado en la Fase 2: Elaboración, en los componentes ya

El objetivo de esta fase es verificar el correcto funcionamiento de la aplicación, para su paso a

7 Fase 6: Producción y Retiro

de software propuesto por la metodología usada en el proyecto. Las disciplinas usadas en el

proyecto están enfocadas en tres ámbitos:

El Plan SQA pertenece a la Disciplina de Desarrollo, denominada Testing.

la metodología (usada en el proyecto) por cada disciplina de desarrollo.

Para verificar la adherencia de los atributos de calidad en un determinado producto o artefacto de

software se definen las siguientes actividades:

fase de Incepción hasta la fase de Construcción.

8.1 Fase de Inicio

 Revisión de los artefactos disponibles para cada disciplina

en la fase de Incepción, son los siguientes:

Artefacto Generado y/o Actualizado Artefacto Validado por el Área SQA

 Modelo de Negocio  Modelo de Negocio