2. Documentación

Plan SQA
Aplicativo para el Sistema de ventas para la empresa pollo Sakura
HISTORIAL DE REVISIONES
Fecha
Versión
Descripción
Autor
Introducción al contenido del plan de
23/07/2009
1.0
SQA para utilización de los
Isabel Guaman
integrantes del Proyecto.
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 ............................................................................................................... 4
1.3
Objetivos ............................................................................................................. 4
1.3.1
Objetivo General ........................................................................................... 4
1.3.2
Objetivos Específicos ................................................................................... 5
1.4
Definiciones, Acrónimos y Abreviaciones............................................................ 5
1.5
Referencias ......................................................................................................... 5
2.
Documentación....................................................................................................... 6
3.
Estándares, prácticas y convenciones ................................................................... 7
4.
Revisiones .............................................................................................................. 8
4.1
Agenda ................................................................................................................ 8
4.2
Revisar el producto ........................................................................................... 10
4.3
Revisar el proceso............................................................................................. 10
4.4
Realizar Revisión Técnica Formal ..................................................................... 10
5.
Testeo .................................................................................................................. 14
6.
Información sobre problemas y acción correctiva................................................. 15
7.
Herramientas, técnicas y metodologías ................................................................ 15
8.
Control de código ................................................................................................. 15
9.
Control de medios ................................................................................................ 16
10.
Recopilación de registros, mantenimiento y retención ......................................... 16
11.
Planificación ......................................................................................................... 16
11.1 Planificación general de la revisión de documentos .......................................... 16
11.2 Contenidos generales de los documentos de revisión ...................................... 17
11.3 Planificación para la generación de documentos .............................................. 17
11.4 Planificación para la generación de los documentos ........................................ 17
12.
Recomendaciones ................................................................................................ 18
13.
Anexo ................................................................................................................... 18
PLAN SQA
1.
Introducción
1.1
Propó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.
Alcance
1.2
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.3
1.3.1
Objetivos
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.4
Definiciones, 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.5
Referencias
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/tikiread_article.php?articleId=15
http://www.epidataconsulting.com/tikiwiki/tikiread_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 Contar las funciones faltantes detectadas en la
aplicación: evaluación y comparar con el número de
funciones descritas en la especificación de
requisitos.
Medición, X = 1 - A/B
fórmula: 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 X = count/count
medida: A = count
B = count
Fuente de Especificación de requisitos
medición: Diseño
Código fuente
Informe de revisión
ISO/IEC 12207 6.6 Validación
SLCP: 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 Contar las pruebas planeadas y comparar con
aplicación: el número de pruebas requeridas para obtener
una cobertura adecuada.
Medición, X = A/B
fórmula: 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 X = count/count
medida: A = count
B = count
Fuente de A proviene del plan de pruebas
medición: B proviene de la especificación de requisitos
ISO/IEC 12207 Aseguramiento de Calidad
SLCP: 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.
11.1
Planificación
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