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



CONTROL DE VERSIONES

Versión Causa del Cambio Responsable Fecha

01 Versión Inicial FranskRoman Cambara (Jefe de

Proyecto )

25 de

noviembre



Í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



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



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.



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.



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.



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



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)


Formato lista de

Chequeo

Aseguramiento de

Calidad

7.1.2. Gestión de Requerimientos




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)


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


hallazgo de la aplicación de esta actividad

(fecha , hora, ejecutor de la validación y

hallazgo).


Formato lista de

Chequeo

Aseguramiento de

Calidad




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


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.



actividad (Fecha, hora, ejecutor de la

validación y hallazgo)


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)


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.


Formato lista de

Chequeo

Aseguramiento de

Calidad



7.1.4. Diseño y Construcción


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.




validación y hallazgo)

3. Encuentre a lo sumo tres registros

correspondientes a problemas



a las etapas (análisis, diseño y

construcción) del proyecto en la base


desarrollo del producto


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.




validación, hallazgo)

4. Encuentre a lo sumo tres registros

correspondientes a problemas



a las etapas (análisis, diseño y

construcción) del proyecto en la base


Formato lista de

Chequeo

Aseguramiento de

Calidad




desarrollo del producto.

7.1.5. Pruebas


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.




validación y hallazgo).


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.






Formato lista de

Chequeo

Aseguramiento de

Calidad

7.1.6. Capacitación e Implantación


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.




Formato lista de

Chequeo

Aseguramiento de

Calidad





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.


Formato lista de

Chequeo

Aseguramiento de

Calidad

7.1.7. Todos los procedimientos


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.


Formato lista de

Chequeo

Aseguramiento de

Calidad



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.



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


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


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



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.


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



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.


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



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



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.



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.



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



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



9. ANEXOS



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?



13. ¿Se identifican incoherencias entre los requisitos, los planes de proyecto y los WorkProducts, se documentan y se toman medidas correctivas?



A2. Formulario para Estado Inicial Prácticas Específicas PP


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?



A.3. Formulario para el Estado Inicial Prácticas Específicas MA


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?



A.3. Formulario para el Estado Inicial Prácticas Específicas MA























doc 4 plan de aseguramiento de la calidad (ppqa)

Documents