2.4.- Actividades de SQA

Software Quality Assurance (Aseguramiento de la Calidad del Software)

• Establecimiento de un plan de calidad para un proyecto.
• Evaluaciones a realizar
• Auditorías y revisiones a realiza.

• Estándares que se pueden aplicar al proyecto
• Procedimientos para información y seguimiento de errores.
• Documentos producidos por el grupo de SQA
• Retroalimentación al equipo del proyecto
• Participación en el desarrollo de la descripción del proceso de software del proyecto.
• Revisión de las actividades de ingeniería del software para verificar su ajuste al proceso de software definido.
• Auditoría de los productos de software designados para verificar el ajuste con los definidos como parte del proceso de software.
• Asegurar que las desviaciones del trabajo y los productos del software se documenten y se manejen de acuerdo con el procedimiento establecido.
• Registrar e informar lo que no se ajuste a los requisitos.

Las revisiones sirven para:

• Señalar la necesidad de mejoras en el producto de una sola persona o un equipo.
• Confirmar las partes de un producto en las que no es necesaria o no es deseable una mejora.
• Conseguir un trabajo técnico de una calidad más uniforme, o más predecible, que la que puede ser conseguida sin revisiones, con el fin de hacer más manejable el trabajo técnico.
  

2.4.1 Revisiones de Software.

Impacto de los defectos sobre el costo

• Errores vs. Defectos.
• El objetivo principal de la revisiones es encontrar errores durante el proceso.
• Las actividades de diseño introducen del 50% al 65% de los errores.
• Las revisiones técnicas formales son efectivas hasta en 75% para encontrar errores.
• Un error en el diseño cuesta 1x, antes de probar 6.5x, durante la prueba 15x, a la entrega 60-100x.

Modelo de amplificación de defectos

2.4.2 Revisiones Técnicas Formales.

Objetivos:

• Descubrir errores en la función, la lógica o la implementación de cualquier representación del software.
• Verificar que el software bajo revisión alcanza sus requisitos.
• Garantizar que el software ha sido representado de acuerdo con ciertos estándares predefinidos.
• Conseguir un software desarrollado de forma uniforme.
• Hacer que los proyectos sean más manejables.

La reunión de revisión:

• Deben convocarse para la revisión entre 3 y 5 personas.
• Se debe preparar por adelantado, pero sin que se requiera más de 2 horas de trabajo de cada persona.
• La duración de la reunión de revisión debe <>

Roles:

• El productor
• Revisor
• El jefe de revisión
• El registrador

Registro e informe de la revisión:
Elaborar un resumen de revisión

• Qué fue revisado?
• Quién lo revisó?
• Qué se descubrió y cuáles fueron las conclusiones?

Elaborar una lista de sucesos:

• Identificar áreas problemáticas dentro del producto.
• Lista de comprobación de puntos de acción para las correcciones.

Directrices para una revisión:

1. Revisar al producto, no al productor.
2. Fijar una agenda y mantenerla.
3. Limitar el debate y las impugnaciones.
4. Enunciar áreas de problemas, pero no intentar resolver cualquier problema que se ponga de manifiesto.
5. Tomar notas escritas.
6. Limitar el número de participantes e insistir en la preparacion anticipada.
7. Desarrollar una lista de comprobación para cada producto que haya de ser revisado.
8. Disponer de recursos y una agenda para las Revisiones Tecnicas formales.
9. Llevar a cabo un buen entrenamiento de todos los revisadores.
10. Repasar las revisiones anteriores.