1. PLAN DE ASEGURAMIENTO DE LA CALIDAD
(PPQA)
Aplicación móvil para la reserva y compra de pasajes en Terminal de Buses Bimodal Santa Cruz
“El Viajero”
(Versión 1.0)

2. PLAN DE ASEGURAMIENTO DE LA CALIDAD
Proyecto:Aplicación móvil para la reserva y compra de pasajes en
Terminal de Buses Bimodal Santa Cruz “El Viajero”
PPQA
Versión 1.0
HOJA DE CONTROL
IDENTIFICACIÓN DEL DOCUMENTO
Código
PPQA
Título
PLAN DE ASEGURAMIENTO DE LA CALIDAD
Nombre del Archivo
PPQA.doc
Nº de Versión
1.0
Fecha creación
23 de noviembre del 2013
Elaborado por
Director de Proyecto
LISTA DE DISTRIBUCIÓN
Oficina de gestión de
Fanny Rivera Vera (Director (a) de Proyecto )
proyecto (PMO)
FranskRoman Cambara (Jefe de Proyecto )
Fanny Rivera Vera (Proyect Manager )
Wilma Cruz Serrudo (Consultora de negocios )
Equipo de desarrollo
Jhon Ramiro Vidal Alvarez (Arquitecto )
Leandro Edgardo Ramirez Cortez (Programador )
FranskRoman Cambara (SQA )
REVISIÓN DEL DOCUMENTO
Revisado por
Equipo de desarrollo
En fecha
24 de noviembre del 2013
APROBACIÓN DEL DOCUMENTO
Aprobado por
Equipo de desarrollo
En fecha
25 de noviembre del 2013

3. PLAN DE ASEGURAMIENTO DE LA CALIDAD
Proyecto:Aplicación móvil para la reserva y compra de pasajes en
Terminal de Buses Bimodal Santa Cruz “El Viajero”
PPQA
Versión 1.0
CONTROL DE VERSIONES
Versión
01
Causa del Cambio
Versión Inicial
Responsable
Fecha
FranskRoman Cambara (Jefe de
25 de
Proyecto )
noviembre

4. PLAN DE ASEGURAMIENTO DE LA CALIDAD
Proyecto:Aplicación móvil para la reserva y compra de pasajes en
Terminal de Buses Bimodal Santa Cruz “El Viajero”
PPQA
Versión 1.0
Índice
1.
OBJETIVO ..............................................................................................................................6
2.
ALCANCE ..............................................................................................................................6
3.
VISIÓN ..................................................................................................................................6
4.
MISIÓN .................................................................................................................................6
5.
DEFINICIONES .......................................................................................................................6
5.1.
Verificación ...................................................................................................................6
5.2.
Validación .....................................................................................................................6
5.3.
Lecciones Aprendidas ...................................................................................................6
5.4.
Líder Par .......................................................................................................................7
5.5.
No Conformidad y/o hallazgo .......................................................................................7
5.6.
Proceso de Pruebas ......................................................................................................7
5.7.
Pruebas funcionales .....................................................................................................7
5.8.
Pruebas No funcionales ................................................................................................8
5.9.
Matriz de Requerimientos de pruebas (MRP) ..............................................................8
5.10.
Iteración de Pruebas .................................................................................................8
5.11.
Script de Pruebas ......................................................................................................8
5.12.
Lista de Chequeo de Unidad .....................................................................................8
6.
POLITICAS Y CONDICIONES GENERALES ...............................................................................9
7.
PROCEDIMIENTOS ................................................................................................................9
7.1.
ACTIVIDADES DE ASEGURAMIENTO DE CALIDAD .........................................................9
7.1.1.
Gestión de Proyectos ............................................................................................9
7.1.2.
Gestión de Requerimientos ................................................................................10
7.1.3.
Análisis................................................................................................................12
7.1.4.
Diseño y Construcción ........................................................................................13
7.1.5.
Pruebas ...............................................................................................................14
7.1.6.
Capacitación e Implantación...............................................................................14
7.1.7.
Todos los procedimientos...................................................................................15
7.2.
METODOLOGIA DEL PROCESO DE PRUEBAS ...............................................................16
7.2.1.
Etapa de Análisis y Planeación de las Pruebas ....................................................16
7.2.2.
Etapa de Diseño de Pruebas ...............................................................................16
7.2.3.
Etapa de ejecución de pruebas ...........................................................................16
7.2.4.
Etapa de Control, Seguimiento y Retro alimentación .........................................17

5. PLAN DE ASEGURAMIENTO DE LA CALIDAD
Proyecto:Aplicación móvil para la reserva y compra de pasajes en
Terminal de Buses Bimodal Santa Cruz “El Viajero”
PPQA
Versión 1.0
7.3.
ACTIVIDADES POR ETAPAS EN EL PROCESO DE PRUEBAS...........................................17
7.4.
TIPOS DE PRUEBAS .....................................................................................................21
7.4.1.
Pruebas de Unidad (Por el desarrollador) ...........................................................21
7.4.2.
Pruebas de Integración (Con otros sistemas) .....................................................21
7.4.3.
Pruebas Funcionales del software ......................................................................21
7.4.4.
Pruebas No Funcionales .....................................................................................22
7.4.5.
Pruebas de Sistemas ...........................................................................................22
7.4.6.
Pruebas de Procesos ...........................................................................................22
7.4.7.
Pruebas de aceptación .......................................................................................22
7.5.
TÉCNICAS DE PRUEBAS FUNCIONALES .......................................................................23
7.6.
TABLA DE INDICADORES .............................................................................................23
8.
FORMATO ...........................................................................................................................24
9.
ANEXOS ..............................................................................................................................25

6. PLAN DE ASEGURAMIENTO DE LA CALIDAD
Proyecto:Aplicación móvil para la reserva y compra de pasajes en
Terminal de Buses Bimodal Santa Cruz “El Viajero”
PPQA
Versión 1.0
1. OBJETIVO
Definir actividades y tiempos de aplicación de ellas, para ejecutar el procedimiento,
construcción y mantenimiento de soluciones informáticas, con un nivel aceptable de calidad.
2. ALCANCE
Las actividades descritas en este documento, deberán aplicarse en todos los proyectos en los
que se involucren soluciones informáticas institucionales en OMEGASOFT.
3. VISIÓN
Ser una empresa líder en desarrollo e integración de soluciones informáticas. De esta manera
lograremos el reconocimiento y la madurez necesaria para exportar nuestros productos
contribuyendo al desarrollo del Software Boliviano como un producto de calidad internacional.
4. MISIÓN
Crear soluciones tecnológicas rentables e innovadoras que contribuyan al crecimiento de
nuestros clientes y por consiguiente a toda su organización.
5. DEFINICIONES
5.1.
Verificación
Actividad para confirmar que el proceso aplicado para la generación y/o mantenimiento de
una solución informática institucional, mantiene los lineamientos definidos y
estandarizados para alcanzar soluciones informáticas de alta calidad.
5.2.
Validación
Es el proceso de revisión de registros generados por el cumplimiento de los lineamientos
definidos y estandarizados para alcanzar soluciones informáticas de alta calidad.
Actividad para confirmar que el producto resultante
es capaz de satisfacer los
requerimientos para su aplicación especificada o uso previsto.
5.3.
Lecciones Aprendidas
Experiencia positiva o negativa obtenida durante la realización de alguna actividad en el
proceso de desarrollo y/o mantenimiento de soluciones informáticas.

7. PLAN DE ASEGURAMIENTO DE LA CALIDAD
Proyecto:Aplicación móvil para la reserva y compra de pasajes en
Terminal de Buses Bimodal Santa Cruz “El Viajero”
5.4.
PPQA
Versión 1.0
Líder Par
Es el rol desempeñado por un líder de desarrollo de producto que puede realizar las
revisiones respectivas para otro producto de desarrollo para el que no es el líder.
Indicador de Calidad, criterio cuya medición determina el nivel de calidad con la que se
entregará una solución informática.
5.5.
No Conformidad y/o hallazgo
Es una desviación en los resultados esperados sobre la solución informática. Pueden ser
clasificadas en:

Bloqueantes : es el tipo de no conformidad que detiene la operación de un
programa /componente o hace que este arroje resultados que impiden la
continuidad de la operación del Cliente.

Funcionales: Es el tipo de no conformidad que se presenta cuando al ejecutar un
opción particular del sistema Creada para dar solución a un requerimientos
funcional, no se evidencia que el requerimiento se solucione.

Presentación: son no conformidades relacionadas con la presentación de los
resultados en la ejecución de una opción del Sistema; estos deben ajustarse a los
estándares definidos y con las reglas gramaticales y ortográficas del idioma en es
presentadas la solución.
5.6.
Proceso de Pruebas
Es el mecanismo mediante el cual se detectan las no conformidades en una solución
informática. El mecanismo usado debe garantizar con un nivel alto de aceptación en los
diferentes usuarios que intervienen en el proceso. El proceso de pruebas es transversal en
el ciclo de vida de desarrollo del Software.
Requerimiento de Prueba, identifica una condición o aspecto particular que requiere ser
verificados o probado sobre una unidad o conjuntos de unidades de Software
desarrolladas o modificadas.
5.7.
Pruebas funcionales
Son evaluaciones que se hacen sobre la ejecución de una funcionalidad que esta siendo
ajustada en la solución informática.

8. PLAN DE ASEGURAMIENTO DE LA CALIDAD
Proyecto:Aplicación móvil para la reserva y compra de pasajes en
Terminal de Buses Bimodal Santa Cruz “El Viajero”
5.8.
PPQA
Versión 1.0
Pruebas No funcionales
Corresponde a las evaluaciones que se hacen sobre los elementos que intervienen en el
resultado de la ejecución de una funcionalidad de la solución informática. Ej. Rendimiento,
Carga, Estress y Seguridad.
5.9.
Matriz de Requerimientos de pruebas (MRP)
Es un modelo jerárquico de requerimientos de prueba.
5.10. Iteración de Pruebas
Corresponde a una ejecución de total o parcialmente de una MRP.
5.11. Script de Pruebas
Unidad de software que permiten la ejecución automática de una funcionalidad especifica
que genera un resultado particular.
5.12. Lista de Chequeo de Unidad
Documento que relaciona criterios a ser verificados y validados como registros de calidad;
las listas de chequeo se gestionan de manera transversal en los diferentes procedimientos
internos del área de desarrollo de software.

9. PLAN DE ASEGURAMIENTO DE LA CALIDAD
Proyecto:Aplicación móvil para la reserva y compra de pasajes en
Terminal de Buses Bimodal Santa Cruz “El Viajero”
PPQA
Versión 1.0
6. POLITICAS Y CONDICIONES GENERALES
Los procedimiento internos definidos al interior del área de desarrollo de Software de
OMEGASOFT, Son basados en pautas entregadas por las siguientes políticas de Calidad:
ISO 9001: 2000 Sistema de gestión de la Calidad – Requisitos,
Capability Maturity Model for Software(SW-CMM). Practicas del Nivel 2 Nivel 3.
Adicionalmente se anotan las siguientes Sugerencias:

Anotación 1: las actividades de aseguramiento planteadas en este documento, se
sugiere sean realizadas por el líder par y luego por un profesional que tenga el rol
de aseguramiento de calidad en el área de desarrollo de OMEGASOFT.

Anotación 2: las actividades de aseguramiento planteadas en este documento, las
realizará un líder par cada mes (cuando aplica), pero el líder de desarrollo del
proyecto podrá aplicarse así mismo este proceso de calidad y mantener informes
y registros para presentación ante el líder par o al profesional líder de calidad,
para que posteriormente se presenten las auditorías de calidad respectivamente
con el mínimo número posible de no conformidades.

Anotación 3: Las actividades de aseguramientos planteadas en este documento,
serán aplicadas sobre muestreos de cada tipo de ítem involucrado en el proceso.
7. PROCEDIMIENTOS
7.1.
ACTIVIDADES DE ASEGURAMIENTO DE CALIDAD
7.1.1. Gestión de Proyectos
ETAPA
ACTIVIDAD
RESPONSABLE
1. Cumple
con
el
estándar
REGISTRO
de
documentación requerido y registrado en
el documento respectivo de la definición
del proceso
2. Se
cumple
Verificar el Proceso de Gestión
especificadas
de Proyectos.
con
en
el
las
proyecto.
documento
del
3. Identificar y registrar el resultado o
hallazgo
de
la
aplicación
de
esta
actividad( fecha, hora, ejecutor, de la
verificación, hallazgo)
4. Existe
el
registro
de
Formato
actividades
problemas
lista
de
Chequeo
Rol QA, líder desarrollo
Aseguramiento
Calidad
de

10. PLAN DE ASEGURAMIENTO DE LA CALIDAD
Proyecto:Aplicación móvil para la reserva y compra de pasajes en
Terminal de Buses Bimodal Santa Cruz “El Viajero”
PPQA
Versión 1.0
recurrentes, experiencias exitosas, tips u
otros que se consideren relativo a la
etapa del proyecto en la base de lecciones
aprendidas del grupo de desarrollo del
producto(mínimo tres registros)
1. Se encuentra anexo el cronograma del
proyecto respectivo.
2. Se evidencia la existencia de registros
asociados con la gestión del proyecto de
acuerdo al plan y cronograma definidos
para el proyecto.
3. Se evidencia el cumplimiento de la
definición de roles y plan de comunicación
del proyecto.
Formato
4. Se identifican casos de riesgos y se
Validar el proceso de Gestión
evidencian registros de las acciones definidas
de Proyectos.
Rol QA, líder desarrollo
Aseguramiento
Calidad
5. Identificar y registrar el resultado o hallazgo
de la aplicación de esta actividad( Fecha,
Hora, Ejecutor del validación y hallazgo)
6. Existe el registro de problemas recurrentes,
experiencias exitosas, tips u otros que se
considere relativo a las etapas del proyecto
en la base de conocimiento del grupo de
desarrollo del producto. (mínimo tres
registros)
7.1.2. Gestión de Requerimientos
ACTIVIDAD
de
Chequeo
enel plan de riesgos del proyecto.
ETAPA
lista
RESPONSABLE
REGISTRO
de

11. PLAN DE ASEGURAMIENTO DE LA CALIDAD
Proyecto:Aplicación móvil para la reserva y compra de pasajes en
Terminal de Buses Bimodal Santa Cruz “El Viajero”
PPQA
Versión 1.0
1. Cumple con el estándar de documentación
requerido y registrado en el documento
respectivo de la definición del proceso.
2. Se tienen los informes de resultados de
aplicación de las técnicas de revisión de
requerimientos
estipulados
como
estándares.
3. Verificar que existen los resultados de los
Formato
Verificar Gestión de
indicadores de medición de satisfacción del
Chequeo
Solicitudes y
usuario final definidos para esta etapa.
Rol QA, líder desarrollo
4. Identificar y registrar el resultado o hallazgo
Requerimientos
lista
Aseguramiento
de
de
Calidad
dela aplicación de esta actividad (Fecha,
hora,ejecutor de la verificación, hallazgo).
5. Existe el registro de problemas recurrentes,
experiencias exitosas, tips u otros que se
considere relativo a las etapas del proyecto en
la base de lecciones aprendidas del grupo de
desarrollo
del
producto.
(mínimo
tres
registros)
1. Confrontar
en
correspondiente(Casos
el
de
documento
uso)
la
representación delrequerimiento funcional
2. Validar el cumplimiento del caso de uso o
requerimietno con la realización de la
prueba respectiva.
3. Aplicación del estándar de usabilidad del
Validar
la
gestión
de
Solicitudes y Requerimientos
Formato
usuario ( prototipos), cuando el estándar
Chequeo
Rol QA, líder desarrollo
exige aplicación.
4. Validar
reuniones
definitivas
de
aceptación con usuarios finales
5. Validar la ejecución y cumplimiento de
resultados de los indicadores de gestión
definidos
6. Identificar y registrar el resultado o
hallazgo de la aplicación de esta actividad
(fecha , hora, ejecutor de la validación y
hallazgo).
lista
Aseguramiento
Calidad
de
de

12. PLAN DE ASEGURAMIENTO DE LA CALIDAD
Proyecto:Aplicación móvil para la reserva y compra de pasajes en
Terminal de Buses Bimodal Santa Cruz “El Viajero”
7. Existe
el
registro
de
PPQA
Versión 1.0
problemas
recurrentes,experiencias exitosas, tips u
otros que seconsidere relativo a las etapas
del proyecto en la base de conocimiento del
grupo de desarrollo delproducto. (mínimo
tres registros)
7.1.3. Análisis
ETAPA
ACTIVIDAD
1.
RESPONSABLE
REGISTRO
Verificar el cumplimiento de las
actividades
de
la
metodología
definidas para la etapa de análisis.
2.
Verificar el cumplimiento de los
estándares
de
herramientas
definidos para esta etapa.
Verificar Analisis
Identificar y registrar el resultado o
Formato
hallazgo de la aplicación de esta
3.
Chequeo
actividad (Fecha, hora, ejecutor de la
Rol QA, líder desarrollo
validación y hallazgo)
4.
lista
Aseguramiento
de
de
Calidad
Existe el registro de problemas
recurrentes, experiencias exitosas,
tips u otros que se considere relativo
a las etapas del proyecto en la base
de lecciones aprendidas del grupo de
desarrollo del producto. (mínimo
tres registros)
1.
Formato
los
Validar análisis
Hay evidencia del cumplimiento de
Chequeo
resultados
obtenidos en la
ejecución de los indicadores de
Gestión definidos.
Rol QA, líder desarrollo
lista
Aseguramiento
Calidad
de
de

13. PLAN DE ASEGURAMIENTO DE LA CALIDAD
Proyecto:Aplicación móvil para la reserva y compra de pasajes en
Terminal de Buses Bimodal Santa Cruz “El Viajero”
PPQA
Versión 1.0
7.1.4. Diseño y Construcción
ETAPA
ACTIVIDAD
1.
RESPONSABLE
REGISTRO
Revisión de los registros definidos
alcumplimiento de las actividades
definidas para la etapa de diseño y
construcción.
2.
Identificar y registrar el resultado o
hallazgo de la aplicación de esta
Formato
actividad (Fecha, hora, ejecutor de la
Verificar Diseño y
Construcción
validación y hallazgo)
3.
Encuentre a lo sumo tres registros
correspondientes
a
lista
de
Chequeo
Rol QA, líder desarrollo
Aseguramiento
de
Calidad
problemas
recurrentes, experiencias exitosas,
tips u otros que se considere relativo
a las etapas (análisis, diseño y
construcción) del proyecto en la base
de lecciones aprendidas del grupo de
desarrollo del producto
1.
Encuentre en el documento técnico
de Diseño y Construcción la totalidad
de las necesidades y expectativas
acordadas
con
el
cliente.
(Requerimientos)
2.
Revisión de los registros definidos al
cumplimiento de las actividades
definidas para la etapa de diseño y
construcción.
Validar Diseño y
Construcción
3.
Formato
Chequeo
Identificar y registrar el resultado o
hallazgo de la aplicación de esta
actividad (Fecha, hora, ejecutor de la
validación, hallazgo)
4.
Encuentre a lo sumo tres registros
correspondientes
a
problemas
recurrentes, experiencias exitosas,
tips u otros que se considere relativo
a las etapas (análisis, diseño y
construcción) del proyecto en la base
Rol QA, líder desarrollo
lista
Aseguramiento
Calidad
de
de

14. PLAN DE ASEGURAMIENTO DE LA CALIDAD
Proyecto:Aplicación móvil para la reserva y compra de pasajes en
Terminal de Buses Bimodal Santa Cruz “El Viajero”
PPQA
Versión 1.0
de lecciones aprendidas del grupo de
desarrollo del producto.
7.1.5. Pruebas
ETAPA
ACTIVIDAD
1.
RESPONSABLE
REGISTRO
Se visualizan en el Plan de pruebas
losdiferentes
acorde
tipos
con
de
pruebas
losrequerimientos
funcionales y no funcionales en el
proyecto específico.
Verificar el Plan de pruebas
2.
Formato
Chequeo
Se
evidencian
registros
de
la
Rol QA, líder desarrollo
aplicación de los planes de prueba.
3.
lista
Aseguramiento
de
de
Calidad
Identificar y registrar el resultado o
hallazgo de la aplicación de esta
actividad (Fecha, hora, ejecutor de la
validación y hallazgo).
1.
Se tiene el registro de la ejecución y
de los hallazgos obtenidos con la
Formato
aplicación de los indicadores de
gestión definidos para la etapa.
Validar Pruebas
2.
Identificar y registrar el resultado o
lista
de
Chequeo
Rol QA, líder desarrollo
Aseguramiento
de
Calidad
hallazgo de la aplicación de esta
actividad (Fecha, hora, ejecutor de la
validación y hallazgo).
7.1.6. Capacitación e Implantación
ETAPA
ACTIVIDAD
1.
Se
RESPONSABLE
evidencian
los
REGISTRO
documentos
definidos como entregables en esta
etapa.
Verificar entregables
2.
Formato
Existe evidencia de la coordinación
Chequeo
del producto terminado
de lascapacitaciones con el área de
(documentación).
capacitación
de
la
división
de
recursos humanos de la Universidad.
3.
Identificar y registrar el resultado o
hallazgo de la aplicación de esta
Rol QA, líder desarrollo
lista
Aseguramiento
Calidad
de
de

15. PLAN DE ASEGURAMIENTO DE LA CALIDAD
Proyecto:Aplicación móvil para la reserva y compra de pasajes en
Terminal de Buses Bimodal Santa Cruz “El Viajero”
PPQA
Versión 1.0
actividad (Fecha, hora, ejecutor de la
validación y hallazgo).
4.
Encuentre
a
lo
sumo
tres
registroscorrespondientes
a
problemas recurrentes, experiencias
exitosas,
tips
u
otros
que
seconsidere, relativo a la etapa de
pruebas del proyecto en la base de
lecciones aprendidas del grupo de
desarrollo del producto.
1.
Se tiene el registro de la ejecución y
de loshallazgos obtenidos con la
aplicación de los indicadores de
gestión definidos para la etapa.
2.
Validación
Capacitación
e
Evidenciar
en
los
Formato
registros
encontrados el cumplimiento del
Implantación
estándar
y
consistencia de
documentos
definidos
los
lista
de
Chequeo
Rol QA, líder desarrollo
Aseguramiento
de
Calidad
como
entregables en esta etapa.
3.
Evidenciar los registros de asistencia
a las capacitaciones de los diferentes
usuarios finales involucrados.
7.1.7. Todos los procedimientos
ETAPA
ACTIVIDAD
Verificar y validar las acciones
correctivas
tomadas
hallazgos.
y
a
preventivas
partir
de
los
1.
RESPONSABLE
REGISTRO
Evidenciar registros de la realización
Formato
de lasauditorías de acuerdo a los
Chequeo
planes ycronogramas propuestos por
producto y de lasrecomendaciones
respectivas.
Rol QA, líder desarrollo
lista
Aseguramiento
Calidad
de
de

16. PLAN DE ASEGURAMIENTO DE LA CALIDAD
Proyecto:Aplicación móvil para la reserva y compra de pasajes en
Terminal de Buses Bimodal Santa Cruz “El Viajero”
7.2.
PPQA
Versión 1.0
METODOLOGIA DEL PROCESO DE PRUEBAS
El área de Desarrollo de la Oficina de
OMEGASOFT establece las siguientes etapas y
actividades para el proceso de pruebas:
7.2.1. Etapa de Análisis y Planeación de las Pruebas
El objetivo de ésta es reconocer funcional y técnicamente el alcance de una solución (ajuste o
nueva).
El reconocimiento funcional se realiza sobre la matriz de descomposición funcional del
producto (MDF) especificando el proceso, subproceso y/o funcionalidad que se afecta con la
solución que se plantea.
Las actividades incluidas en el documento Plan de Pruebas, serán basadas en el
reconocimiento inicial de los tipos de pruebas que se deban realizar, tiempos estimados y
responsables de ellas, para nuevas soluciones informáticas. Para ajustes a base instalada el
plan de pruebas estará contenido en el cronograma del proyecto, en cada una de las etapas
del ciclo del software.
7.2.2. Etapa de Diseño de Pruebas
Identificación de los requerimientos de pruebas a ejecutar que apliquen para la revisión y
validación del requerimiento funcional identificado. El conjunto de estos requerimientos de
pruebas identificados constituye la Matriz de Requerimientos de Pruebas (MRP) de la solución
planteada. Deberán armarse tantas MRP's como funcionalidades impactadas del producto.
Para la construcción de una MRP, seguir los lineamientos definidos en el documento
MO_ConstrucciónMRP.
Una MRP, debe cumplir con las siguientes características:
Eficiente ,que permita identificar de manera suficiente las no conformidades de la soluscion,
durante la ejecución de los requerimientos de pruebas que la conforman.
Confiable, que cubra completamente el alcance de la solución que se plantea para la(s)
funcionalidad(es).
Para la construcción de Pruebas No Funcionales OMEGASOFT – Área de desarrollo se veldra de
herramientas de Software libre como Jmeter, de acuerdo al tipo de prueba NO funcional a
realizar y al criterio del grupo arquitectónico del proyecto.
7.2.3. Etapa de ejecución de pruebas
Corresponde a un ciclo de iteraciones de pruebas para validar la solución. Durante
lasactividades relacionadas en esta etapa, se reportan no conformidades y/o hallazgos.

17. PLAN DE ASEGURAMIENTO DE LA CALIDAD
Proyecto:Aplicación móvil para la reserva y compra de pasajes en
Terminal de Buses Bimodal Santa Cruz “El Viajero”
PPQA
Versión 1.0
7.2.4. Etapa de Control, Seguimiento y Retro alimentación
Consiste en la verificación de las acciones correctivas y/o preventivas generadas como
respuestas a las no conformidades reportadas en la etapa anterior.
7.3.
ETAPA
ACTIVIDADES POR ETAPAS EN EL PROCESO DE PRUEBAS
Nº ACTIVIDAD
RESPONSABLES
REGISTRO
Determine la(s) funcionalidad(es) que debe(n)
Líder de
Líder de Desarrollo
Lista de Chequeo
ser
Desarrollo y/o
de
Ingeniero de
SQA
desarrollo
1
PARTICIPANTES
en
afectada(s)
con
la
solución
del
requerimiento funcional
actualizada
su
camporespectivo.
Revisar la ficha de información del producto, la
Líder de
base de lecciones aprendidas, el proceso
Desarrollo y/o
de
llevado a cabo del desarrollo de la solución.
Ingeniero de
SQA
desarrollo
2
Líder de Desarrollo
Lista de Chequeo
en
actualizada
su
camporespectivo
y
Desarrollo y/o
Lista de Chequeo
subproceso
planeación
Líder de
descomposiciónfuncional (MDF), en el proceso,
3
Identifique, conozca y afecte la matriz de
y/o
Ingeniero de
de
corresponda
Análisis
de
desarrollo
SQA
funcionalidades
acuerdo
ala
que
solución
Líder de Desarrollo
planteada.
MDF afectada.
actualizada
en
su
camporespectivo
Diligencie formato Plan de pruebas si es una
Líder de
nueva solución informática. O ajuste el
Desarrollo y/o
Pruebas
cronograma del proyecto en caso de ser un
Ingeniero de
diligenciado o
ajuste Base Instalada. (Tipos de Pruebas,
4
Líder de Desarrollo
desarrollo
Cronograma
Técnicas, Tiempos (de acuerdo a la base de
Formato Plan De
Proyecto afectado.
estimación definida) y responsables)
Líder de
Desarrollo y/o
de
si
Ingeniero de
SQA
estos ya existen ajustarlos si es del caso para
Diseño
Para cada uno de los procesos impactados en la
MDF Identifique los requerimientos de prueba,
1
Líder de Desarrollo
desarrollo
en
reutilizarlos, de lo contrario crearlos utilizando
Lista de Chequeo
actualizada
su
camporespectivo
las
técnicas apropiadas para esto. (Ver anexo
Técnicas de pruebas en este documento)
2
Diseño
Ajuste para reutilizar las Matrices de
Líder de
Requerimientos de prueba (MRP's) y la lista de
Desarrollo y/o
Lista de Chequeo
chequeo
Ingeniero de
de
de
prueba,
por
funcionalidad
Líder de Desarrollo
MRP

18. PLAN DE ASEGURAMIENTO DE LA CALIDAD
Proyecto:Aplicación móvil para la reserva y compra de pasajes en
Terminal de Buses Bimodal Santa Cruz “El Viajero”
impactada;
PPQA
Versión 1.0
desarrollo
SQA
actualizada
en caso de no existir, crearlos utilizando las
en
su
Técnicas apropiadas para esto. (Ver numeral
camporespectivo
5.5
Técnicas de Pruebas en este documento y
Formato MRPF_
Matriz_Requerimientos_Pruebas_Funcionales)
Ajuste los script's para la ejecución de
Administrador
Administrador
Lista de
laspruebas no funcionales para reusarlos, si no
De Configuración,
De Configuración
Chequeo de
existen crearlos.
3
Líder de Desarrollo,
SQA con campo
scripts
automáticos
chequeado.
Líder de Desarrollo
Líder de
Lista
y/o Ingeniero de
Desarrollo
de
pruebas.
desarrollo,
SQA con campo
administrador
scripts
de Configuración
Diseño
Usando los mecanismos (script's automáticos o
digitación) definidos prepare los datos de
4
deChequeo
automáticos
chequeado.
Líder de
Líder de
Lista de Chequeo
Desarrollo, DBA,
Desarrollo,
Pruebas con
controlado para la ejecución de las pruebas
Ingeniero
DBA
Campo Ambiente
tanto
Desarrollo,
funcionales como no funcionales si son del
Arquitecto
caso.
soluciones
Socializar y validar con el usuario funcional la o
Líder de Desarrollo
Líder de
Lista de
lasMRP'sasociadas
6
Defina y solicite al DBA de la Oficina el
ambiente
5
y/o Ingeniero de
Desarrollo.
Chequeo Pruebas
a
las
funcionalidades
impactadas por los requerimientos funcionales.
de
de
de
Pruebas
chequeado.
Desarrollo.
con campo MRP's
Asociadas
socializadas
chequeado.
Líder de
Administrador
Ambiente de
Desarrollo,
de
Pruebas con
scripts de migración de datos diseñados
Administrador
Configuración
Datos básicos
preparando el ambiente de datos de acuerdo a
Ejecución
En el ambiente controlado de pruebas ejecute
los
1
de
migrados para
los requerimientos funcionales a probar y
Configuración
las pruebas.
MRP's
Lista de
identificadas en el plan de pruebas.
Chequeo de
SQA
actualizada en

19. PLAN DE ASEGURAMIENTO DE LA CALIDAD
Proyecto:Aplicación móvil para la reserva y compra de pasajes en
Terminal de Buses Bimodal Santa Cruz “El Viajero”
PPQA
Versión 1.0
su campo
respectivo
Administrador
Líder de
Ambiente de
Ejecute los requerimientos de prueba
de
Desarrollo
Pruebas
identificados (MRP's). Valide la lista de
Configuración,
actualizado.
chequeo
Líder de
Lista de
de unidad.
Desarrollo y/o
Chequeo de
Valide el procedimiento de construcción y
Ingeniero de
SQA
ejecución de las pruebas No Funcionales,
desarrollo
actualizada en
2
creado
su campo
para el producto particular
respectivo
Registre los hallazgos de la ejecución de las
Líder de
Líder de
Herramienta
pruebas y clasifique las no conformidades.
Desarrollo y/o
Desarrollo
para el registro
Utilice
Ingeniero de
de No
el formato de No Conformidades o en la
3
desarrollo
Conformidades
herramienta indicada para esto. Ver anexo
actualizada.
NC_NO_Conformidades.
Ajustar la funcionalidad de acuerdo a las no
Líder de
Líder de
Lista de
conformidades reportadas por el proceso de
Desarrollo y/o
Desarrollo
Chequeo de
pruebas.
Ingeniero de
SQA
desarrollo
4
actualizada en
su campo
respectivo
Realice el análisis de los resultados de las
Líder de Desarrollo
Líder de
Lista de Chequeo
pruebas efectuadas.
5
y/o Ingeniero de
Desarrollo
de
desarrollo
SQA
actualizada
en
su
campo
respectivo.
Convocar si es del caso, a reunión informativa
Líder de
Líder de
Lista de Chequeo
para el análisis del resultado de las pruebas e
Desarrollo,
Desarrollo
de
identificación de aspectos claves a mejorar.
1
Arquitecto
de
SQA
soluciones,
Coordinador
Ejecución
actualizada
en
de
su
campo
desarrollo,
respectivo.
Coordinador de
Identificación
infraestructura
Aspectos claves de
Mejoramiento.
2
Retroalimentar en los informes de avance del
Líder de
Líder de
Lista de Chequeo
proyecto, los resultados parciales de los ciclos
Desarrollo ,
Desarrollo
de

20. PLAN DE ASEGURAMIENTO DE LA CALIDAD
Proyecto:Aplicación móvil para la reserva y compra de pasajes en
Terminal de Buses Bimodal Santa Cruz “El Viajero”
PPQA
Versión 1.0
de
Ingeniero de
SQA
actualizada
pruebas efectuados.
desarrollo,
en
Administrador
su
de
respectivo.
campo
Configuración.
3
Verificar acciones preventivas y correctivas
Líder y/o
Líder de
Lista de Chequeo
generadas de acuerdo a No conformidades
ingeniero de
Desarrollo
de
registradas en la herramienta para esto.
Desarrollo,
SQA
actualizada
en
su campo
respectivo

21. PLAN DE ASEGURAMIENTO DE LA CALIDAD
Proyecto:Aplicación móvil para la reserva y compra de pasajes en
Terminal de Buses Bimodal Santa Cruz “El Viajero”
7.4.
PPQA
Versión 1.0
TIPOS DE PRUEBAS
7.4.1. Pruebas de Unidad (Por el desarrollador)
Las pruebas de unidad están orientadas principalmente a validar el cumplimiento de los
estándares de presentación y demás características visuales de la aplicación como la salida
de los reportes y la apariencia de las interfaces de entrada y salida de datos.
Para ejecutar estas pruebas, los Ingenieros se basan en listas de chequeo de unidad
diseñadas especialmente para cada tipo de aplicación en la etapa de construcción del
software.
7.4.2. Pruebas de Integración (Con otros sistemas)
El objetivo fundamental de esta prueba es comprobar que las interfaces entre losdistintos
módulos y/o productos son correctas.
Estrategias de pruebas de Integración:
De arriba a abajo (top-down): Consiste en empezar la integración y la prueba por los
módulos que están en los niveles superiores de abstracción, e integrar incrementalmente
los niveles inferiores.
De abajo a arriba (bottom-up): Consiste en empezar la integración y la prueba por los
módulos que están en los niveles inferiores de abstracción, e integrar incrementalmente
los niveles superiores.
De big-bang: Consiste en integrar y probar todo al mismo tiempo.
7.4.3. Pruebas Funcionales del software
Son evaluaciones que se hacen sobre la ejecución de una funcionalidad que esta siendo
ajustada en la solución informática. La funcionalidad del software mapea las reglas del negocio
de forma segura y acertada.
Prueba de Regresión
Las pruebas de regresión son una actividad selectiva que busca asegurar que cuando una no
conformidad encontrada en el sistema ha sido corregida ninguna de las funcionalidades
liberadas previamente falla como resultado de las correcciones ó que las características
nuevamente agregadas no han creado conflicto con las versiones anteriores del software.

22. PLAN DE ASEGURAMIENTO DE LA CALIDAD
Proyecto:Aplicación móvil para la reserva y compra de pasajes en
Terminal de Buses Bimodal Santa Cruz “El Viajero”
PPQA
Versión 1.0
Es una medida del control de calidad para asegurarse de que el código nuevo modificado
todavía es conforme con los requisitos especificados y que el código sinmodificar no ha sido
afectado por la actividad del mantenimiento.
7.4.4. Pruebas No Funcionales
Corresponde a las evaluaciones que se hacen sobre elementos que intervienen en el resultado
de la ejecución de una funcionalidad de la solución informática. Ej. Rendimiento, Carga, Estress
y Seguridad.
7.4.5. Pruebas de Sistemas
Las Pruebas del sistema tienen su foco principal en las no conformidades que se presentan en
el Nivel más alto de la integración.
La pruebas del sistema incluye típicamente de funcionalidad, de usabilidad, de seguridad, de
internacionalización y de localización, de confiabilidad y de disponibilidad, de capacidad, de
funcionamiento, de recuperación, de portabilidad y otros, y es deber del responsable de las
MRP's definidas plantear requerimientos de pruebas orientados a hacer las validaciones
mínimas de rendimiento, concurrencia y recuperación que apliquen a cada caso.
7.4.6. Pruebas de Procesos
El objetivo de las pruebas de procesos, es validar que los procesos soportados por la aplicación
se cumplen completamente, es decir, que los procesos fluyen desde su inicio hasta el final.
Para las pruebas de procesos se reutiliza gran parte del diseño de las funcionales, sin embargo
es necesario identificar los “casos tipo” de prueba y la ejecución se debe iniciar una vez se han
concluido las pruebas funcionales, si esto no se cumple, se podrían identificar no
conformidades durante las pruebas de procesos que debieron ser identificadas durante las
pruebas funcionales o las de integración, lo cual resulta más costoso para el proyecto.
7.4.7. Pruebas de aceptación
Este tipo de pruebas son las que se hacen con los clientes finales quienes definen la aceptación
del sistema. Son lo más exhaustivas posible (equivalentes al nivel de pruebas del sistema). A
éste nivel de interacción con clientes, deben definirse las condiciones de las pruebas y ante
todo buscar la reutilización de los instrumentos construidos para las pruebas funcionales. Se
plantearán preguntas típicas que deben ser resueltas antes del inicio de las pruebas.

23. PLAN DE ASEGURAMIENTO DE LA CALIDAD
Proyecto:Aplicación móvil para la reserva y compra de pasajes en
Terminal de Buses Bimodal Santa Cruz “El Viajero”
7.5.
PPQA
Versión 1.0
TÉCNICAS DE PRUEBAS FUNCIONALES
Las técnicas de pruebas funcionales que el Área de Desarrollo de OMEGASOFT utiliza son
aquellas en las cuales el equipo del Área de Desarrollo fue capacitado, y se deja al criterio del
Líder de Desarrollo la utilización de una u otra de acuerdo al análisis que éste haya realizado y
lo que desea probar.
Algunas de las técnicas son:
Técnicas de Caja blanca o estructurales
Técnicas de Caja negra o funcionales: Partición Equivalente (Técnica basada en la
Especificación), Análisis del valor Límite (Técnica basada en la Especificación), Tablas de
decisión (Técnica basada en la Especificación), Arreglo Ortogonal.
La documentación sobre estas técnicas se encuentra almacenada en el software controlador
de versiones en la carpeta (pruebas funcionales).
7.6.
TABLA DE INDICADORES
Nro
Nombre
Objetivos
Formula de calculo
Resultado esperado
Observaciones
1
Desviación en
la planeación
Identificar la
desviación en días en
la planeación de una
actividad
Máximo: 20%
Desviación con valor
negativo: Significa
que se terminó antes
de lo planeado
2
Desviación de
esfuerzo en la
planeación
Identificar si se
realizó un esfuerzo
mayor o menor al
planeado en una
actividad
A: Fecha real
B: Fecha presupuestada
C: Duración total del plan (en
días)
Desviación en tiempo de
Planeación = (A-B)/C
A:Esfuerzo real (en días)
B:Esfuerzo presupuestado (en
días)
Desviación por actividad = 1 –
(A/B)
Mínimo: -20%
Máximo: 20%
Desviación con valor
negativo: Significa
subestimación
Desviación Acumulado =
((SumatoriaB SumatoriaA)/(SumatoriaB))*1
Desviación con valor
positivo: Significa
sobrestimación

24. PLAN DE ASEGURAMIENTO DE LA CALIDAD
Proyecto:Aplicación móvil para la reserva y compra de pasajes en
Terminal de Buses Bimodal Santa Cruz “El Viajero”
PPQA
Versión 1.0
00
3
Reproceso en
los
requerimientos
Identificar la
eficiencia del proceso
de la gestión del
requerimientos
4
Correctitud
Identificar qué
porcentaje de las
actividades
evaluadas se
comportan
correctamente con
respecto al resultado
esperado
8. FORMATO


Lista de Chequeo SQA
Formato NC
A:Número de requerimientos
en la gestión
B:Número de requerimientos
no aprobados
Reproceso = (100*B)/A
A: Número de actividades con
no conformidades
B: Total de actividades
evaluadas.
Correctitud = (1 - (A/B))*100
Máximo: 30%
Mínimo: 80%
Máximo:100%
Las actividades
pueden ser de
cualquier tipo y en
cualquier proceso o
fase.
Ej:
Requerimientos,
pruebas, diseño, etc.

25. PLAN DE ASEGURAMIENTO DE LA CALIDAD
Proyecto:Aplicación móvil para la reserva y compra de pasajes en
Terminal de Buses Bimodal Santa Cruz “El Viajero”
9. ANEXOS
PPQA
Versión 1.0

26. PLAN DE ASEGURAMIENTO DE LA CALIDAD
Proyecto:Aplicación móvil para la reserva y compra de pasajes en
Terminal de Buses Bimodal Santa Cruz “El Viajero”
PPQA
Versión 1.0
A.1. Formulario de Estado Inicial Prácticas Específicas REQM
Si No N/A
1. ¿Se han identificado quiénes son los proveedores de
requisitos autorizados (canales apropiados o fuentes
oficiales de quien poder recibir requisitos, por ejemplo,
cliente externo, interno, usuarios finales, etc.)?
2. ¿Se han establecido criterios objetivos para la
evaluación y aceptación de los requisitos (ej.: clara y
adecuadamente definido, completo, consistente con
otros
requisitos,
identificado
unívocamente,
implementable adecuadamente, testearle, trazable)?
3. ¿Se analizan los requisitos para garantizar que se
cumplen los criterios de aceptación establecidos?
4. ¿Se llega a un conjunto de requisitos acordados por
ambas partes de forma que los participantes del
proyecto puedan comprometerse con dichos requisitos?
5. ¿Existe un registro donde se recojan los requisitos del
cliente (documento, BD o herramienta específica de
gestión de requisitos)?
6. ¿Se evalúa el impacto de los requisitos (y de los
cambios a requisitos) sobre los compromisos ya
existentes?
7. ¿Queda documentado el compromiso del personal
encargado de implementar los requisitos para con los
mismos (ej.: firma del plan de proyecto, actas de la
reunión de lanzamiento o de las reuniones internas de
requisitos, atributo en la BD de requisitos para reflejar el
estado de revisión/compromiso)?
8. ¿Se ha establecido claramente quién es el responsable
de aprobar/rechazar una petición de cambio a un
requisito?; ¿se han definido criterios de escalado para
tomar esta decisión?
9. ¿Se controla el estado de los requisitos?; ¿existen
atributos que indiquen el estado actual de cada
requisito?
10. ¿Se revisan el plan de proyecto y los WorkProducts
relacionados con los requisitos para asegurar que
existe consistencia con los requisitos y los cambios
realizados en ellos?
11. ¿Existen
Procesos,
Procedimientos,
Plantillas,
Herramientas para Gestión de Requisitos? ¿La utilizan
los proyectos?
12. ¿Se tiene una trazabilidad (ej.: matriz de trazabilidad)
desde los requisitos fuente hacia sus derivadas y a la
inversa?
Comentario

27. PLAN DE ASEGURAMIENTO DE LA CALIDAD
Proyecto:Aplicación móvil para la reserva y compra de pasajes en
Terminal de Buses Bimodal Santa Cruz “El Viajero”
13. ¿Se identifican incoherencias entre los requisitos, los
planes de proyecto y los WorkProducts, se documentan
y se toman medidas correctivas?
PPQA
Versión 1.0

28. PLAN DE ASEGURAMIENTO DE LA CALIDAD
Proyecto:Aplicación móvil para la reserva y compra de pasajes en
Terminal de Buses Bimodal Santa Cruz “El Viajero”
PPQA
Versión 1.0
A2. Formulario para Estado Inicial Prácticas Específicas PP
Si No N/A
1. ¿Se dispone de plantillas de Estructura de Desglose de
Trabajo (WBS) estándar (por tipología de proyectos) en
la unidad organizativa?
2. ¿Se desarrolla un WBS de la arquitectura del producto
teniendo en cuenta que se puedan identificar los riegos
y sus tareas de mitigación, tareas de prestaciones de
apoyo, tareas de adquisición de nuevos conocimientos,
tareas para la integración, tareas para control de
calidad o verificación de planes?
3. ¿Se identifican los paquetes de trabajo con suficiente
detalle como para precisar estimaciones de tareas de
proyecto, responsabilidades y calendario?
4. ¿Se identifican los productos que se adquirirán
externamente?
5. ¿Se estima las horas de trabajo y el coste del proyecto
(teniendo en cuenta los atributos de los WorkProducts,
necesidades de infraestructura, etc.?
6. ¿Se identifican los principales hitos del proyecto?
7. ¿Se identifican los principales hitos del proyecto?
8. ¿Se identifican las dependencias de las tareas
(predecesor-sucesor) y se intentan reducir al mínimo el
tiempo global de la tarea con métodos como el camino
critico CPM?
9. ¿Se establece y mantiene el presupuesto y calendario
general del proyecto?
10. ¿Se identifica y documenta una lista de riesgos para el
proyecto (ej.: falta de recursos, falta de conocimiento,
etc.)? ¿Se determinan la probabilidad de ocurrencia,
impacto y gravedad de cada riesgo?
11. ¿Se obtiene un acuerdo en forma de documento con las
partes interesadas sobre la corrección de los riegos
documentados?
Comentario

29. PLAN DE ASEGURAMIENTO DE LA CALIDAD
Proyecto:Aplicación móvil para la reserva y compra de pasajes en
Terminal de Buses Bimodal Santa Cruz “El Viajero”
PPQA
Versión 1.0
A.3. Formulario para el Estado Inicial Prácticas Específicas MA
Si No N/A
1. ¿La dirección establece periódicamente cuáles son los
objetivos estratégicos de la organización? (por ejemplo:
aumentar rentabilidad, aumentar satisfacción del
cliente, aumentar calidad del producto, etc.)
2. ¿Se priorizan las necesidades de información u
objetivos según su importancia y siempre ajustándolo a
los limites posibles?
3. ¿Se definen y documentan objetivos operativos de
medición para la unidad de desarrollo alineados a los
objetivos estratégicos de la organización? (por ejemplo:
objetivo estratégico-aumentar satisfacción del cliente,
objetivo operativo para la unidad de desarrollo-reducir
errores en producción)
4. ¿Se dispone una trazabilidad entre las necesidades de
información y los objetivos?
5. ¿Se revisan periódicamente los indicadores y se
actualizan en caso necesario?
6. ¿Existe una definición operativa clara y sin
ambigüedades para cada indicador (ej.: descripción del
indicador, fórmula, unidades de medición, etc.)?
7. ¿Existe una definición operativa clara y sin
ambigüedades para cada indicador (ej.: descripción del
indicador, fórmula, unidades de medición, etc.)
8. ¿Se identifican medidas ya existentes que se ocupen ya
de los objetivos en el proyecto o en otros de la
organización?
9. ¿Se identifican las fuentes existentes de datos que se
generan en la labor actual?
10. ¿Los procedimientos de recogida y almacenamiento de
los indicadores son estándar para todos los proyectos?
Comentario

30. PLAN DE ASEGURAMIENTO DE LA CALIDAD
Proyecto:Aplicación móvil para la reserva y compra de pasajes en
Terminal de Buses Bimodal Santa Cruz “El Viajero”
PPQA
Versión 1.0
A.3. Formulario para el Estado Inicial Prácticas Específicas MA
Si No N/A
1.
11. ¿La dirección establece periódicamente cuáles son los
objetivos estratégicos de la organización? (por ejemplo:
aumentar rentabilidad, aumentar satisfacción del
cliente, aumentar calidad del producto, etc.)
2.
12. ¿Se priorizan las necesidades de información u
objetivos según su importancia y siempre ajustándolo a
los limites posibles?
3.
13. ¿Se definen y documentan objetivos operativos de
medición para la unidad de desarrollo alineados a los
objetivos estratégicos de la organización? (por ejemplo:
objetivo estratégico-aumentar satisfacción del cliente,
objetivo operativo para la unidad de desarrollo-reducir
errores en producción)
4.
14. ¿Se dispone una trazabilidad entre las necesidades de
información y los objetivos?
5.
15. ¿Se revisan periódicamente los indicadores y se
actualizan en caso necesario?
6.
16. ¿Existe una definición operativa clara y sin
ambigüedades para cada indicador (ej.: descripción del
indicador, fórmula, unidades de medición, etc.)?
7.
17. ¿Existe una definición operativa clara y sin
ambigüedades para cada indicador (ej.: descripción del
indicador, fórmula, unidades de medición, etc.)
8.
18. ¿Se identifican medidas ya existentes que se ocupen ya
de los objetivos en el proyecto o en otros de la
organización?
9.
19. ¿Se identifican las fuentes existentes de datos que se
generan en la labor actual?
10.
20. ¿Los procedimientos de recogida y almacenamiento de
los indicadores son estándar para todos los proyectos?
Comentario