Doc 4 plan de aseguramiento de la calidad (ppqa)
-
Upload
fanny-lorena-rivera-vera -
Category
Documents
-
view
1.009 -
download
4
description
Transcript of Doc 4 plan de aseguramiento de la calidad (ppqa)
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)
PLAN DE ASEGURAMIENTO DE LA CALIDAD PPQA Versión 1.0
Proyecto:Aplicación móvil para la reserva y compra de pasajes en Terminal de Buses Bimodal Santa Cruz “El Viajero”
HOJA DE CONTROL
LISTA DE DISTRIBUCIÓN
Oficina de gestión de
proyecto (PMO)
Fanny Rivera Vera (Director (a) de Proyecto )
FranskRoman Cambara (Jefe de Proyecto )
Equipo de desarrollo
Fanny Rivera Vera (Proyect Manager )
Wilma Cruz Serrudo (Consultora de negocios )
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
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
PLAN DE ASEGURAMIENTO DE LA CALIDAD PPQA Versión 1.0
Proyecto:Aplicación móvil para la reserva y compra de pasajes en Terminal de Buses Bimodal Santa Cruz “El Viajero”
CONTROL DE VERSIONES
Versión Causa del Cambio Responsable Fecha
01 Versión Inicial FranskRoman Cambara (Jefe de
Proyecto )
25 de
noviembre
PLAN DE ASEGURAMIENTO DE LA CALIDAD PPQA Versión 1.0
Proyecto:Aplicación móvil para la reserva y compra de pasajes en Terminal de Buses Bimodal Santa Cruz “El Viajero”
Í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
PLAN DE ASEGURAMIENTO DE LA CALIDAD PPQA Versión 1.0
Proyecto:Aplicación móvil para la reserva y compra de pasajes en Terminal de Buses Bimodal Santa Cruz “El Viajero”
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
PLAN DE ASEGURAMIENTO DE LA CALIDAD PPQA Versión 1.0
Proyecto:Aplicación móvil para la reserva y compra de pasajes en Terminal de Buses Bimodal Santa Cruz “El Viajero”
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.
PLAN DE ASEGURAMIENTO DE LA CALIDAD PPQA Versión 1.0
Proyecto:Aplicación móvil para la reserva y compra de pasajes en Terminal de Buses Bimodal Santa Cruz “El Viajero”
5.4. 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.
PLAN DE ASEGURAMIENTO DE LA CALIDAD PPQA Versión 1.0
Proyecto:Aplicación móvil para la reserva y compra de pasajes en Terminal de Buses Bimodal Santa Cruz “El Viajero”
5.8. 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.
PLAN DE ASEGURAMIENTO DE LA CALIDAD PPQA Versión 1.0
Proyecto:Aplicación móvil para la reserva y compra de pasajes en Terminal de Buses Bimodal Santa Cruz “El Viajero”
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 REGISTRO
Verificar el Proceso de Gestión
de Proyectos.
1. Cumple con el estándar de
documentación requerido y registrado en
el documento respectivo de la definición
del proceso
2. Se cumple con las actividades
especificadas en el documento del
proyecto.
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 problemas
Rol QA, líder desarrollo
Formato lista de
Chequeo
Aseguramiento de
Calidad
PLAN DE ASEGURAMIENTO DE LA CALIDAD PPQA Versión 1.0
Proyecto:Aplicación móvil para la reserva y compra de pasajes en Terminal de Buses Bimodal Santa Cruz “El Viajero”
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)
Validar el proceso de Gestión
de Proyectos.
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.
4. Se identifican casos de riesgos y se
evidencian registros de las acciones definidas
enel plan de riesgos del proyecto.
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)
Rol QA, líder desarrollo
Formato lista de
Chequeo
Aseguramiento de
Calidad
7.1.2. Gestión de Requerimientos
ETAPA ACTIVIDAD RESPONSABLE REGISTRO
PLAN DE ASEGURAMIENTO DE LA CALIDAD PPQA Versión 1.0
Proyecto:Aplicación móvil para la reserva y compra de pasajes en Terminal de Buses Bimodal Santa Cruz “El Viajero”
Verificar Gestión de
Solicitudes y
Requerimientos
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
indicadores de medición de satisfacción del
usuario final definidos para esta etapa.
4. Identificar y registrar el resultado o hallazgo
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)
Rol QA, líder desarrollo
Formato lista de
Chequeo
Aseguramiento de
Calidad
Validar la gestión de
Solicitudes y Requerimientos
1. Confrontar en el documento
correspondiente(Casos de 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
usuario ( prototipos), cuando el estándar
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).
Rol QA, líder desarrollo
Formato lista de
Chequeo
Aseguramiento de
Calidad
PLAN DE ASEGURAMIENTO DE LA CALIDAD PPQA Versión 1.0
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 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 RESPONSABLE REGISTRO
Verificar Analisis
1. 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.
3. Identificar y registrar el resultado o
hallazgo de la aplicación de esta
actividad (Fecha, hora, ejecutor de la
validación y hallazgo)
4. 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)
Rol QA, líder desarrollo
Formato lista de
Chequeo
Aseguramiento de
Calidad
Validar análisis
1. Hay evidencia del cumplimiento de
los resultados obtenidos en la
ejecución de los indicadores de
Gestión definidos.
Rol QA, líder desarrollo
Formato lista de
Chequeo
Aseguramiento de
Calidad
PLAN DE ASEGURAMIENTO DE LA CALIDAD PPQA Versión 1.0
Proyecto:Aplicación móvil para la reserva y compra de pasajes en Terminal de Buses Bimodal Santa Cruz “El Viajero”
7.1.4. Diseño y Construcción
ETAPA ACTIVIDAD RESPONSABLE REGISTRO
Verificar Diseño y
Construcción
1. 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
actividad (Fecha, hora, ejecutor de la
validación y hallazgo)
3. 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
de lecciones aprendidas del grupo de
desarrollo del producto
Rol QA, líder desarrollo
Formato lista de
Chequeo
Aseguramiento de
Calidad
Validar Diseño y
Construcción
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.
3. 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
Formato lista de
Chequeo
Aseguramiento de
Calidad
PLAN DE ASEGURAMIENTO DE LA CALIDAD PPQA Versión 1.0
Proyecto:Aplicación móvil para la reserva y compra de pasajes en Terminal de Buses Bimodal Santa Cruz “El Viajero”
de lecciones aprendidas del grupo de
desarrollo del producto.
7.1.5. Pruebas
ETAPA ACTIVIDAD RESPONSABLE REGISTRO
Verificar el Plan de pruebas
1. Se visualizan en el Plan de pruebas
losdiferentes tipos de pruebas
acorde con losrequerimientos
funcionales y no funcionales en el
proyecto específico.
2. Se evidencian registros de la
aplicación de los planes de prueba.
3. Identificar y registrar el resultado o
hallazgo de la aplicación de esta
actividad (Fecha, hora, ejecutor de la
validación y hallazgo).
Rol QA, líder desarrollo
Formato lista de
Chequeo
Aseguramiento de
Calidad
Validar Pruebas
1. Se tiene el registro de la ejecución y
de los hallazgos obtenidos con la
aplicación de los indicadores de
gestión definidos para la etapa.
2. Identificar y registrar el resultado o
hallazgo de la aplicación de esta
actividad (Fecha, hora, ejecutor de la
validación y hallazgo).
Rol QA, líder desarrollo
Formato lista de
Chequeo
Aseguramiento de
Calidad
7.1.6. Capacitación e Implantación
ETAPA ACTIVIDAD RESPONSABLE REGISTRO
Verificar entregables
del producto terminado
(documentación).
1. Se evidencian los documentos
definidos como entregables en esta
etapa.
2. Existe evidencia de la coordinación
de lascapacitaciones con el área de
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
Formato lista de
Chequeo
Aseguramiento de
Calidad
PLAN DE ASEGURAMIENTO DE LA CALIDAD PPQA Versión 1.0
Proyecto:Aplicación móvil para la reserva y compra de pasajes en Terminal de Buses Bimodal Santa Cruz “El Viajero”
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.
Validación Capacitación e
Implantación
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. Evidenciar en los registros
encontrados el cumplimiento del
estándar y consistencia de los
documentos definidos como
entregables en esta etapa.
3. Evidenciar los registros de asistencia
a las capacitaciones de los diferentes
usuarios finales involucrados.
Rol QA, líder desarrollo
Formato lista de
Chequeo
Aseguramiento de
Calidad
7.1.7. Todos los procedimientos
ETAPA ACTIVIDAD RESPONSABLE REGISTRO
Verificar y validar las acciones
correctivas y preventivas
tomadas a partir de los
hallazgos.
1. Evidenciar registros de la realización
de lasauditorías de acuerdo a los
planes ycronogramas propuestos por
producto y de lasrecomendaciones
respectivas.
Rol QA, líder desarrollo
Formato lista de
Chequeo
Aseguramiento de
Calidad
PLAN DE ASEGURAMIENTO DE LA CALIDAD PPQA Versión 1.0
Proyecto:Aplicación móvil para la reserva y compra de pasajes en Terminal de Buses Bimodal Santa Cruz “El Viajero”
7.2. 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.
PLAN DE ASEGURAMIENTO DE LA CALIDAD PPQA Versión 1.0
Proyecto:Aplicación móvil para la reserva y compra de pasajes en Terminal de Buses Bimodal Santa Cruz “El Viajero”
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. ACTIVIDADES POR ETAPAS EN EL PROCESO DE PRUEBAS
ETAPA Nº ACTIVIDAD PARTICIPANTES RESPONSABLES REGISTRO
Análisis y
planeación
1
Determine la(s) funcionalidad(es) que debe(n)
ser afectada(s) con la solución del
requerimiento funcional
Líder de
Desarrollo y/o
Ingeniero de
desarrollo
Líder de Desarrollo Lista de Chequeo
de
SQA actualizada
en su
camporespectivo.
2 Revisar la ficha de información del producto, la
base de lecciones aprendidas, el proceso
llevado a cabo del desarrollo de la solución.
Líder de
Desarrollo y/o
Ingeniero de
desarrollo
Líder de Desarrollo Lista de Chequeo
de
SQA actualizada
en su
camporespectivo
3 Identifique, conozca y afecte la matriz de
descomposiciónfuncional (MDF), en el proceso,
subproceso y/o funcionalidades que
corresponda de acuerdo ala solución
planteada.
Líder de
Desarrollo y/o
Ingeniero de
desarrollo
Líder de Desarrollo MDF afectada.
Lista de Chequeo
de
SQA actualizada
en su
camporespectivo
4 Diligencie formato Plan de pruebas si es una
nueva solución informática. O ajuste el
cronograma del proyecto en caso de ser un
ajuste Base Instalada. (Tipos de Pruebas,
Técnicas, Tiempos (de acuerdo a la base de
estimación definida) y responsables)
Líder de
Desarrollo y/o
Ingeniero de
desarrollo
Líder de Desarrollo Formato Plan De
Pruebas
diligenciado o
Cronograma
Proyecto afectado.
Diseño
1 Para cada uno de los procesos impactados en la
MDF Identifique los requerimientos de prueba,
si
estos ya existen ajustarlos si es del caso para
reutilizarlos, de lo contrario crearlos utilizando
las
técnicas apropiadas para esto. (Ver anexo
Técnicas de pruebas en este documento)
Líder de
Desarrollo y/o
Ingeniero de
desarrollo
Líder de Desarrollo Lista de Chequeo
de
SQA actualizada
en su
camporespectivo
Diseño
2 Ajuste para reutilizar las Matrices de
Requerimientos de prueba (MRP's) y la lista de
chequeo de prueba, por funcionalidad
Líder de
Desarrollo y/o
Ingeniero de
Líder de Desarrollo MRP
Lista de Chequeo
de
PLAN DE ASEGURAMIENTO DE LA CALIDAD PPQA Versión 1.0
Proyecto:Aplicación móvil para la reserva y compra de pasajes en Terminal de Buses Bimodal Santa Cruz “El Viajero”
impactada;
en caso de no existir, crearlos utilizando las
Técnicas apropiadas para esto. (Ver numeral
5.5
Técnicas de Pruebas en este documento y
Formato MRPF_
Matriz_Requerimientos_Pruebas_Funcionales)
desarrollo SQA actualizada
en su
camporespectivo
Diseño
3 Ajuste los script's para la ejecución de
laspruebas no funcionales para reusarlos, si no
existen crearlos.
Administrador
De Configuración,
Líder de Desarrollo,
Administrador
De Configuración
Lista de
Chequeo de
SQA con campo
scripts
automáticos
chequeado.
4 Usando los mecanismos (script's automáticos o
digitación) definidos prepare los datos de
pruebas.
Líder de Desarrollo
y/o Ingeniero de
desarrollo,
administrador
de Configuración
Líder de
Desarrollo
Lista deChequeo
de
SQA con campo
scripts
automáticos
chequeado.
5 Defina y solicite al DBA de la Oficina el
ambiente
controlado para la ejecución de las pruebas
tanto
funcionales como no funcionales si son del
caso.
Líder de
Desarrollo, DBA,
Ingeniero de
Desarrollo,
Arquitecto de
soluciones
Líder de
Desarrollo,
DBA
Lista de Chequeo
Pruebas con
Campo Ambiente
de Pruebas
chequeado.
6 Socializar y validar con el usuario funcional la o
lasMRP'sasociadas a las funcionalidades
impactadas por los requerimientos funcionales.
Líder de Desarrollo
y/o Ingeniero de
Desarrollo.
Líder de
Desarrollo.
Lista de
Chequeo Pruebas
con campo MRP's
Asociadas
socializadas
chequeado.
Ejecución
1 En el ambiente controlado de pruebas ejecute
los
scripts de migración de datos diseñados
preparando el ambiente de datos de acuerdo a
los requerimientos funcionales a probar y
MRP's
identificadas en el plan de pruebas.
Líder de
Desarrollo,
Administrador
de
Configuración
Administrador
de
Configuración
Ambiente de
Pruebas con
Datos básicos
migrados para
las pruebas.
Lista de
Chequeo de
SQA
actualizada en
PLAN DE ASEGURAMIENTO DE LA CALIDAD PPQA Versión 1.0
Proyecto:Aplicación móvil para la reserva y compra de pasajes en Terminal de Buses Bimodal Santa Cruz “El Viajero”
su campo
respectivo
2
Ejecute los requerimientos de prueba
identificados (MRP's). Valide la lista de
chequeo
de unidad.
Valide el procedimiento de construcción y
ejecución de las pruebas No Funcionales,
creado
para el producto particular
Administrador
de
Configuración,
Líder de
Desarrollo y/o
Ingeniero de
desarrollo
Líder de
Desarrollo
Ambiente de
Pruebas
actualizado.
Lista de
Chequeo de
SQA
actualizada en
su campo
respectivo
3 Registre los hallazgos de la ejecución de las
pruebas y clasifique las no conformidades.
Utilice
el formato de No Conformidades o en la
herramienta indicada para esto. Ver anexo
NC_NO_Conformidades.
Líder de
Desarrollo y/o
Ingeniero de
desarrollo
Líder de
Desarrollo
Herramienta
para el registro
de No
Conformidades
actualizada.
4 Ajustar la funcionalidad de acuerdo a las no
conformidades reportadas por el proceso de
pruebas.
Líder de
Desarrollo y/o
Ingeniero de
desarrollo
Líder de
Desarrollo
Lista de
Chequeo de
SQA
actualizada en
su campo
respectivo
5 Realice el análisis de los resultados de las
pruebas efectuadas.
Líder de Desarrollo
y/o Ingeniero de
desarrollo
Líder de
Desarrollo
Lista de Chequeo
de
SQA actualizada
en
su campo
respectivo.
Ejecución
1 Convocar si es del caso, a reunión informativa
para el análisis del resultado de las pruebas e
identificación de aspectos claves a mejorar.
Líder de
Desarrollo,
Arquitecto de
soluciones,
Coordinador de
desarrollo,
Coordinador de
infraestructura
Líder de
Desarrollo
Lista de Chequeo
de
SQA actualizada
en
su campo
respectivo.
Identificación
Aspectos claves de
Mejoramiento.
2 Retroalimentar en los informes de avance del
proyecto, los resultados parciales de los ciclos
Líder de
Desarrollo ,
Líder de
Desarrollo
Lista de Chequeo
de
PLAN DE ASEGURAMIENTO DE LA CALIDAD PPQA Versión 1.0
Proyecto:Aplicación móvil para la reserva y compra de pasajes en Terminal de Buses Bimodal Santa Cruz “El Viajero”
de
pruebas efectuados.
Ingeniero de
desarrollo,
Administrador
de
Configuración.
SQA actualizada
en
su campo
respectivo.
3 Verificar acciones preventivas y correctivas
generadas de acuerdo a No conformidades
registradas en la herramienta para esto.
Líder y/o
ingeniero de
Desarrollo,
Líder de
Desarrollo
Lista de Chequeo
de
SQA actualizada
en
su campo
respectivo
PLAN DE ASEGURAMIENTO DE LA CALIDAD PPQA Versión 1.0
Proyecto:Aplicación móvil para la reserva y compra de pasajes en Terminal de Buses Bimodal Santa Cruz “El Viajero”
7.4. 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.
PLAN DE ASEGURAMIENTO DE LA CALIDAD PPQA Versión 1.0
Proyecto:Aplicación móvil para la reserva y compra de pasajes en Terminal de Buses Bimodal Santa Cruz “El Viajero”
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.
PLAN DE ASEGURAMIENTO DE LA CALIDAD PPQA Versión 1.0
Proyecto:Aplicación móvil para la reserva y compra de pasajes en Terminal de Buses Bimodal Santa Cruz “El Viajero”
7.5. 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
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
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:Esfuerzo real (en días) B:Esfuerzo presupuestado (en días) Desviación por actividad = 1 – (A/B) Desviación Acumulado = ((SumatoriaB - SumatoriaA)/(SumatoriaB))*1
Mínimo: -20% Máximo: 20%
Desviación con valor negativo: Significa subestimación Desviación con valor positivo: Significa sobrestimación
PLAN DE ASEGURAMIENTO DE LA CALIDAD PPQA Versión 1.0
Proyecto:Aplicación móvil para la reserva y compra de pasajes en Terminal de Buses Bimodal Santa Cruz “El Viajero”
00
3 Reproceso en los requerimientos
Identificar la eficiencia del proceso de la gestión del requerimientos
A:Número de requerimientos en la gestión B:Número de requerimientos no aprobados Reproceso = (100*B)/A
Máximo: 30%
4 Correctitud Identificar qué porcentaje de las actividades evaluadas se comportan correctamente con respecto al resultado esperado
A: Número de actividades con no conformidades B: Total de actividades evaluadas. Correctitud = (1 - (A/B))*100
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.
8. FORMATO Lista de Chequeo SQA
Formato NC
PLAN DE ASEGURAMIENTO DE LA CALIDAD PPQA Versión 1.0
Proyecto:Aplicación móvil para la reserva y compra de pasajes en Terminal de Buses Bimodal Santa Cruz “El Viajero”
9. ANEXOS
PLAN DE ASEGURAMIENTO DE LA CALIDAD PPQA Versión 1.0
Proyecto:Aplicación móvil para la reserva y compra de pasajes en Terminal de Buses Bimodal Santa Cruz “El Viajero”
A.1. Formulario de Estado Inicial Prácticas Específicas REQM
Si No N/A Comentario
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?
PLAN DE ASEGURAMIENTO DE LA CALIDAD PPQA Versión 1.0
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?
PLAN DE ASEGURAMIENTO DE LA CALIDAD PPQA Versión 1.0
Proyecto:Aplicación móvil para la reserva y compra de pasajes en Terminal de Buses Bimodal Santa Cruz “El Viajero”
A2. Formulario para Estado Inicial Prácticas Específicas PP
Si No N/A Comentario
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?
PLAN DE ASEGURAMIENTO DE LA CALIDAD PPQA Versión 1.0
Proyecto:Aplicación móvil para la reserva y compra de pasajes en Terminal de Buses Bimodal Santa Cruz “El Viajero”
A.3. Formulario para el Estado Inicial Prácticas Específicas MA
Si No N/A Comentario
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?
PLAN DE ASEGURAMIENTO DE LA CALIDAD PPQA Versión 1.0
Proyecto:Aplicación móvil para la reserva y compra de pasajes en Terminal de Buses Bimodal Santa Cruz “El Viajero”
A.3. Formulario para el Estado Inicial Prácticas Específicas MA
Si No N/A Comentario
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.)
12. ¿Se priorizan las necesidades de información u objetivos según su importancia y siempre ajustándolo a los limites posibles?
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)
14. ¿Se dispone una trazabilidad entre las necesidades de información y los objetivos?
15. ¿Se revisan periódicamente los indicadores y se actualizan en caso necesario?
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.)?
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.)
18. ¿Se identifican medidas ya existentes que se ocupen ya de los objetivos en el proyecto o en otros de la organización?
19. ¿Se identifican las fuentes existentes de datos que se generan en la labor actual?
20. ¿Los procedimientos de recogida y almacenamiento de los indicadores son estándar para todos los proyectos?
Si No N/A Comentario
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?