Plan SQA

Aplicativo para el Sistema de ventas para la empresa pollo Sakura

HISTORIAL DE REVISIONES

Fecha Versión Descripción Autor

23/07/2009 1.0

Introducción al contenido del plan de

SQA para utilización de los

integrantes del Proyecto.

Isabel Guaman

25/07/2009 1.1 Revisión del Documento. Isabel Guaman

TABLA DE CONTENIDO

1. Introducción....................................................................................................3

1.1 Propósito.....................................................................................................3

1.2 Alcance........................................................................................................3

1.3 Objetivos.....................................................................................................3

1.3.1 Objetivo General...................................................................................3

1.3.2 Objetivos Específicos...........................................................................4

1.4 Definiciones, Acrónimos y Abreviaciones....................................................4

1.5 Referencias.................................................................................................4

2. Documentación...............................................................................................4

3. Estándares, prácticas y convenciones...........................................................6

4. Revisiones......................................................................................................6

4.1 Agenda........................................................................................................6

4.2 Revisar el producto.....................................................................................6

4.3 Revisar el proceso.......................................................................................6

4.4 Realizar Revisión Técnica Formal...............................................................7

5. Testeo.............................................................................................................7

6. Información sobre problemas y acción correctiva...........................................7

7. Herramientas, técnicas y metodologías..........................................................8

8. Control de código...........................................................................................8

9. Control de medios..........................................................................................8

10. Recopilación de registros, mantenimiento y retención...................................8

11. Planificación...................................................................................................8

11.1 Planificación general de la revisión de documentos....................................8

11.2 Contenidos generales de los documentos de revisión................................9

11.3 Planificación para la generación de documentos........................................9

11.4 Planificación para la generación de los documentos..................................9

12. Recomendaciones........................................................................................10

13. Anexo...........................................................................................................10

PLAN SQA

1. Introducción

1.1Propósito

El propósito de este plan es especificar las actividades que se realizarán para

asegurar la calidad del software a construir. En él se detalla el producto que se

va a revisar y los estándares, normas o métodos a aplicar; los métodos y

procedimientos que se utilizarán para revisar que la elaboración del producto

se realice como lo establece el modelo de ciclo de vida del proyecto; y

procedimientos para informar a los responsables del producto, los defectos

encontrados y realizar un seguimiento de dichos defectos hasta su corrección.

1.2Alcance

Se describen las tareas de SQA que serán realizadas en el proyecto y la

documentación que produce cada una, y sus relaciones con los puntos clave

definidos en el proceso de desarrollo, así como otras tareas que estén

relacionadas con la calidad de los productos.

Para este proyecto las actividades de SQA definidas en el modelo de proceso

definido de acuerdo al RUP, son:

Actividad Entregable Asociado

Elaboración del Plan de SQA Plan de SQA

Realizar Revisión Técnica

Formal

Informe de Revisión Técnica

Formal

Métricas y Análisis Informe de Metricas

Esta guía permitirá a los integrantes del equipo estar al tanto de la

planificación de SQA1 para realizar las acciones correspondientes y evaluar

potencializadoramente los avances y defectos.

1.3Objetivos

1.3.1 Objetivo General

El objetivo de este plan es brindar una base para la adaptación de la

metodología de desarrollo RUP al modelo de proceso que se aplica en el

proyecto de elaboración del AWCI, destacando los tipos de revisiones a

realizar y el producto a ser desarrollado.

1 El encargado de calidad es responsable de los lineamientos del SQA

1.3.2 Objetivos Específicos

Cumplir los estándares y normas de acuerdo a lo aceptado por el

equipo.

Asegurar el cumplimiento de los requerimientos del cliente

Controlar la configuración del software y la documentación

asociada.

Especificar las pruebas y los controles a ser realizados para el

aseguramiento de la calidad del software.

1.4Definiciones, Acrónimos y Abreviaciones

SQAP: Software Quality Assurance Plan

SQA: Software Quality Assurance (Aseguramiento de la Calidad del

Software)

SCM: Gestión de Configuración del Software.

GP: Gestión del Proyecto.

1.5Referencias

IEEE Std. 730-1 – 1989 Standard for Software Quality Assurance Plans.

Documento de Actividades de Gestión de Calidad – Taller V –

A. Delgado & B. Pérez 2000.

Proyecto de Ingeniería de Software – Curso 2001.

Estándares / Modelos: http://www.tantara.ab.ca/

Modelo CMM: http://www.sei.cmu.edu/cmmi/

UML: http://www.epidataconsulting.com/tikiwiki/tiki-read_article.php?

articleId=15

http://www.epidataconsulting.com/tikiwiki/tiki-read_article.php?

articleId=31

W3C: http://www.w3c.es/

2. Documentación

La documentación que se realizará en el presente proyecto esta de acuerdo

al RUP2, adaptado por el equipo y se consideran los siguientes:

Visión

Especificación de Requerimientos (ERS)

Plan del Proyecto

Plan SQA

Plan de Gestión de Configuración (SCMP)

Descripción de la arquitectura del Software (DAS)

Plan de Pruebas

Para cada documento debe indicarse cual es su objetivo, que norma debe

seguir y que información mínima debe contener para cumplir con las

definiciones del documento.

Visión: Tiene por objetivo proveer información del proyecto en forma

inicial, colocando especial énfasis en el modelado del negocio.

Ref. Formato de Visión

Especificación de Requerimientos (ERS): Tiene por objetivo la

interpretación de los requerimientos y sus cambios de acuerdo a lo

solicitado por el cliente o las observaciones del equipo de desarrollo.

Ref. Formato de ERS

2 De acuerdo al Standard 730-1

Plan del Proyecto: El objetivo es reunir toda la información requerida

para administrar el proyecto de acuerdo al proceso definida por el

equipo.

Plan SQA

Plan de Gestión de Configuración (SCMP). El objetivo es describir

como debe administrarse los artefactos durante el ciclo de vida del

proyecto.

Descripción de la arquitectura del Software (DAS). El objetivo es

especificar los pasos desarrollados para generar la arquitectura del

software incluyendo el análisis, diseño e implementación de los

artefactos que conforman el software.

Plan de Pruebas. El plan de pruebas es el documento que especifica

las pruebas a ser realizadas, incluyendo los valores a ser probados y

los resultados esperados.

Manual de Usuario: Se especifican todas las funciones y la

descripción de los pasos para que el usuario utilice adecuadamente el

software.

Informe de Cierre: El cierre de un proyecto es la culminación del

proceso proyecto actual y el momento de hacer balance del mismo.

3. Estándares, prácticas y convenciones

Estándares de codificación de acuerdo a las convenciones de las

herramientas de desarrollo a ser utilizadas.

Ref. Estándares y normas.

Los artefactos serán desarrollados en lo que respecta a los diagramas

siguiendo la especificación UML

Se seguirán los estándares de la Empresa Microsoft en la

construcción de la aplicación cliente

La documentación seguirán los estándares definidos por el equipo.

Se seguirán los procedimientos definidos en el equipo.

4. Revisiones

En esta sección, se describen las revisiones que serán realizadas,

especificando como y cuando se realizarán, que acciones se tomarán a partir

de los resultados obtenidos y como serán implementadas estas acciones.

Para este proyecto las revisiones previstas son de 3 tipos: revisión del

producto, revisión de proceso y Revisión Técnica Formal.

4.1 Agenda

Ref. Plan del Proyecto sección: cronograma de actividades.

Fase de Inicio. Se revisara el documento de la visión,

comprobando que el objetivo general y los específicos sean

medibles, definidos y con un objetivo claro. Se realizara este

proceso una vez a la semana cada viernes.

Fase de Elaboración. Se controlara y verificara los casos de uso,

los requerimientos por parte del cliente y que el diseño del interfaz

se adecue a las exigencias del cliente. Se realizara un reporte de

revisión para adecuarlo, antes que pase a otra fase.

Fase de Construcción. Se tendrán reportes de revisión de los

modelos de casos de uso y clases de dominio, la codificación del

programa y en los diferentes documentos entregables, basándose

en procedimientos y estándares para su correcta elaboración.

4.2 Revisar el producto

Se realizará después de la fase de elaboración y después de la fase de

construcción, en cada iteración, levantando registros de no conformidad.

4.3 Revisar el proceso

Se realizará después de la entrega de cada documento, identificando las

fallas en el proceso, y levantando registros de no conformidad con el mismo.

4.4 Realizar Revisión Técnica Formal

Objetivo: Descubrir errores en la función, la lógica ó la implementación de

cualquier producto del software, verificar que satisface sus especificaciones,

que se ajusta a los estándares establecidos, señalando las posibles

desviaciones detectadas.

Mecanismo:

Es un proceso de revisión riguroso, su objetivo es llegar a detectar lo antes

posible, los posibles defectos o desviaciones en los productos que se van

generando a lo largo del desarrollo. Por esta característica se adopta esta

práctica para productos que son de especial importancia.

En la reunión participan el responsable de SQA e integrantes del equipo de

desarrollo.

Se debe convocar a la reunión formalmente a los involucrados, informar del

material que ellos deben preparar por adelantado, llevar una lista de

preguntas y dudas que surgen del estudio del producto a ser revisado.

Para este proyecto se consideran de importancia las revisiones del equipo y

debido al poco tiempo se realizara cada 7 días los días viernes a las 9:00

am.

4.5 Métricas y Análisis

El concepto de métrica es el término que describe muchos y muy variados

casos de medición. Siendo una métrica una medida estadística (no

cuantitativa como en otras disciplinas ejemplo física) que se aplica a todos

los aspectos de calidad de software, los cuales deben ser medidos desde

diferentes puntos de vista como el análisis, construcción, funcional,

documentación, métodos, proceso, usuario, entre otros.

Según la ISO 9126 como medición de la calidad del software se tendrán las

siguientes métricas:

El modelo de calidad establecido en la primera parte del estándar, ISO 9126-1,

clasifica la calidad del software en un conjunto estructurado de características y

subcaracterísticas de la siguiente manera:

Funcionalidad - Un conjunto de atributos que se relacionan con la existencia

de un conjunto de funciones y sus propiedades específicas. Las funciones

son aquellas que satisfacen lo indicado o implica necesidades.

o Idoneidad

o Exactitud

o Interoperabilidad

o Seguridad

o Cumplimiento de normas.

Fiabilidad - Un conjunto de atributos relacionados con la capacidad del

software de mantener su nivel de prestación bajo condiciones establecidas

durante un período de tiempo establecido.

o Madurez

o Recuperabilidad

o Tolerancia a fallos

Funcionalidad

Nombre: Completitud de implementación funcional

Propósito: Qué tan completa está la implementación

funcional.

Método de

aplicación:

Contar las funciones faltantes detectadas en la

evaluación y comparar con el número de

funciones descritas en la especificación de

requisitos.

Medición,

fórmula:

X = 1 - A/B

A = número de funciones faltantes

B = número de funciones descritas en la

especificación de requisitos

Interpretación: 0 <= X <= 1

Entre más cercano a 1, más completa.

Tipo de

escala:absoluta

Tipo de

medida:

X = count/count

A = count

B = count

Fuente de

medición:

Especificación de requisitos

Diseño

Código fuente

Informe de revisión

ISO/IEC 12207

SLCP:

6.6 Validación

6.6 Revisión conjunta

Audiencia: Requeridores

Desarrolladores

Fiabilidad

Nombre: Suficiencia de las pruebas

Propósito: Cuántas de los casos de prueba necesarios

están cubiertos por el plan de pruebas.

Método de

aplicación:

Contar las pruebas planeadas y comparar con

el número de pruebas requeridas para obtener

una cobertura adecuada.

Medición,

fórmula:

X = A/B

A = número de casos de prueba en el plan

B = número de casos de prueba requeridos

Interpretación: 0 <= X

Entre X se mayor, mejor la suficiencia.

Tipo de

escala:absoluta

Tipo de

medida:

X = count/count

A = count

B = count

Fuente de

medición:

A proviene del plan de pruebas

B proviene de la especificación de requisitos

ISO/IEC 12207

SLCP:

Aseguramiento de Calidad

Resolución de problemas

Verificación

Audiencia: Desarrolladores

Mantenedores

5. Testeo

Esta sección especifica las pruebas que se realizarán sobre el software

cubierto por el SQAP, para lo cual se realizarán:

Pruebas de unidad: por clase o unidad de programa

pruebas de caja negra al final de cada iteración.

Las pruebas de caja blanca serán realizadas a las clases cuyo

resultado sean fundamentales para el producto y cuando se generen

inconsistencias.

Pruebas de integración: se revisan las clases que están asociadas por

paquetes.

Pruebas del sistema: se debe probar todo el software en conjunto

incluyendo la implementación y ejecución.

Ref. Plan de Pruebas

6. Información sobre problemas y acción correctiva

Esta sección describe las prácticas y procedimientos que serán seguidos

para informar de los problemas detectados, hacer el seguimiento y

resolverlos. Esto se aplica tanto a desviaciones encontradas en el producto

generados como en el proceso seguido. También deben especificarse las

responsabilidades en la implementación de estos mecanismos.

Para el proyecto se levantan los registros de no conformidad con las

especificaciones colocando el área que genero el problema y la acción

correctiva.

7. Herramientas, técnicas y metodologías

En esta sección se indican las herramientas especiales de software, técnicas

y metodologías que apoyarán la gestión del Responsable de Calidad. En

esta sección se incluirán las checklist que serán utilizadas para hacer las

revisiones detalladas en la sección 4 – Revisiones

8. Control de código

Se indican los métodos que se utilizarán para mantener, almacenar, asegurar

y documentar las versiones controladas identificadas en las fases de

desarrollo, lo cual será definido en conjunto con el Arquitecto de Software

9. Control de medios

Se indican los métodos que se utilizarán para proteger el almacenamiento

adecuado de los programas, documentación, etc., así como también la

prevención de acceso sin autorización, daño, etc., lo cual será definido en

conjunto con el Arquitecto de Software.

10. Recopilación de registros, mantenimiento y retención

Se describen los tipos de registros que serán generados, mantenidos y

almacenados por el Responsable de SQA y el objetivo de los mismos,

adjuntando el formato que tendrán dichos documentos.

Para este proyecto los registros que generan las actividades de SQA están

indicados por los entregables asociados: Entrega semanal de

SQA, Informe de revisión de SQA, Informe de Revisión Técnica Formal,

Registros de SQA

11. Planificación

11.1 Planificación general de la revisión de documentos

El ingeniero de Calidad se compromete a revisar los documentos

terminados, para comprobar su adherencia a los estándares. El ciclo de

desarrollo de los documentos será como sigue:

Ingeniero de calidad revisa el plan, y genera los documentos.

Líder recibe los documentos, y cambia los documentos para

solucionar los problemas.

Se repite el ciclo hasta que se llegue a la fase transición.

Luego, para la fase de transición se llevará a cabo la generación de los

documentos, que corresponden a la documentación de la revisión. Los

detalles de esta fase se detallan a continuación.

11.2 Contenidos generales de los documentos de revisión

En la fase de transición se asume que el plan ya se ha terminado y esta es

la última instancia de revisión del documento. Esta revisión queda plasmada

en el documento generado por SQA y que contiene lo siguiente:

Resumen de la fase de transición.

Resultados de las discrepancias.

Problemas no solucionados, con sus respectivos análisis.

Análisis de patrones de ocurrencia de problemas.

Soluciones sugeridas a la gerencia.

Estimación de tiempos de respuesta, corrección.

Conclusión de la fase.

La creación de los documentos no debe tomar más de dos semanas.

11.3 Planificación para la generación de documentos

Para cada uno de los planes se revisará su corrección con respecto a los

estándares impuestos. El proceso de generación de documentos es el

siguiente:

Equipo revisa el documento, y lo entrega con las indicaciones al

Ingeniero de Calidad.

Ingeniero de Calidad procederá a formatear las indicaciones para que

correspondan a la plantilla.

Ingeniero de Calidad devolverá los documentos.

Todo esto será monitoreado en forma constante por el Líder del

Proyecto.

11.4 Planificación para la generación de los documentos

Para generar cada uno de los documentos, se seguirá el siguiente proceso:

El Líder del Proyecto tomará todos los documentos correspondientes

al plan en cuestión, y los juntará en un documento inicial de formato

libre.

El Líder del Proyecto luego redacta un informe en formato libre que

contenga los puntos de contenido general de los documentos y se lo

envía al ingeniero de Calidad.

El ingeniero de Calidad toma el documento y lo formatea según la

plantilla de los documentos de transición que aparece en este

documento, en el anexo.

El ingeniero de Calidad dará el visto bueno al documento para

entregarlo.

12. Recomendaciones

Las actividades a revisar deben ser monitoreadas desde su comienzo.

Comunicar al responsable del artefacto, cuando debe comenzar y que cosas

se van a evaluar.

Si se detectan desviaciones que impactan en el proyecto, el informe acerca

de las revisiones realizadas debe dirigirse al Líder y Arquitecto para que ese

impacto se analice y tenga en cuenta en los planes del proyecto. Lo más

importante es evitar que se ignoren.

13. Anexo

Plantilla de los documentos

Tabla de contenido

1 Introducción

1.1 Propósito

1.2 Alcance

1.3 Objetivos

1.4 Definiciones, siglas, abreviaciones

1.5 Referencias

2 Contenido y Desarrollo del Documento

3 Conclusiones (si es necesario)

4 Anexos