GARANTÍA DE CALIDAD

DEL SOFTWARE
Por: José Perezalonso
Tipos
Diseño: requisitos, especificaciones y el diseño del sistema.
Concordancia: implementación adaptada al diseño.
Control
Inspección, revisión y pruebas para asegurar que cada producto cumple
con los requisitos asignados.
Garantía
Auditoria para proporcionar la gestión e informar los datos necesarios
sobre la calidad de un producto.
Coste
Prevención: planificación, revisión, equipo de pruebas y formación
Evaluación: inspección de procesos, mantenimiento, pruebas.
Fallos:
Internos: Al detectarse un error en el producto antes del envío
Externos: asociados a los defectos encontrados una vez enviado el
producto al cliente.
 Programa GTC: Gestión total de calidad.
1.Primer paso: Desarrollar un sistema que sea visible, repetible y
mensurable.
2.Segundo paso: Examinar lo intangible que afecta al proceso y
trabajar para optimizar su impacto en el proceso.
3.Tercer paso: Centrarse en el usuario del producto. Examinando la
forma en que el usuario aplica el producto conduce a la mejora del
producto mismo y al proceso que lo creo.
4.Cuarto paso: Gestión más allá del producto inmediato que busca
la oportunidad en áreas relacionadas que se pueden identificar
observando el mercado. Intento de detectar productos nuevos y
beneficiosos.
 Actividades del SQA
El grupo SQA sirve como representación del cliente en casa.

La garantía de calidad del software compete a:

- Los ingenieros de software: realizan revisiones técnicas formales.
- Grupo de SQA: tratan de ayudar al equipo de ingeniería.

Actividades:
Establecer un plan de SQA para un proyecto (durante la planificación del proyecto)
Participar en el desarrollo de la descripción del proceso del software del proyecto.
Revisar actividades de ing. del software para verificar su ajuste al proceso definido.
Auditoria de productos para verificar ajuste definidos al proceso del software.
Asegurar que las desviaciones del trabajo y los productos se documenten y se
manejen de acuerdo con un procedimiento establecido.
 Registrar lo que no se ajuste a los requisitos e informar a los superiores.
•Descubrir errores en la función, la lógica o la implementación

•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 en forma uniforme.

•Hacer que los proyectos sean más manejables.

Al final los participantes deben decidir si:
1.Aceptan el producto sin posteriores modificaciones.
2.Rechazan el producto debido a los serios errores
encontrados (una vez corregidos ha de hacerse una nueva
revisión)
3.Aceptan el producto provisoriamente (sin necesidad de una
nueva revisión)

Se firma.
Se prepara:
- Informe sumario de revisión (que, quien y conclusiones).
- Lista de sucesos de revisión:
1)Identificar áreas problemáticas dentro del producto.
2)Servir como lista de comprobación de puntos de acción que
guíe al productor para hacer las correcciones)
1. Se agrupa y se clasifica la información sobre los defectos del soft.
2. Se intenta encontrar la causa subyacente de cada defecto.
3. Se aísla el 20 % (los pocos vitales)
4. Una vez identificados los defectos vitales, se actúa para corregir los
problemas que han producido los defectos.

Después del análisis, el diseño , la codificación, la prueba y la

entrega , se recopilan los siguientes datos:

• Nro. total de defectos descubiertos durante la etapa.

• Nro. de defectos graves.
• Nro. de defectos moderados.
• Nro. de defectos leves.
• Tamaño del producto (sentencias de diseño, paginas de
documentación).

Índice de fase =
peso * (defectos moderados /total defectos ) + peso * (defectos leves /total
defectos)
Se pueden usar las sig. Herramientas:

1.Análisis del árbol de fallos: modelo gráfico de las combinaciones

secuenciales y concurrentes de los sucesos que pueden conducir a un
estado del sistema o suceso peligroso.
2.Lógica de tiempo real: Construye un modelo (modelo suceso- acción).
Se puede analizar mediante operaciones lógicas para probar las
valoraciones de seguridad de los componentes.
3.Modelos de redes de Petri: Determina los riesgos más peligrosos.

Fiabilidad: utiliza análisis estadístico para determinar la probabilidad

de pueda ocurrir un fallo. El fallo no lleva necesariamente a un riesgo
o accidente.
Seguridad del software: examina los modos según los cuales los
fallos producen consideraciones que pueden llevar a accidentes.
I. Propósito y alcance
II. Referencia
III. Gestión
IV. Documentación
V. Estándares, practicas y convenciones
VI. Revisiones y auditoria
VII. Prueba
VIII. Información sobre problemas y acción correctora
IX. Herramientas, técnicas y metodologías
X. Control de códigos
XI. Control de medios
XII. Control de distribución
XIII. Recopilación de registros, mantenimiento y retención
XIV. Formación
XV. Gestión de riesgos.
Certificado avalado por los auditores.
Cada 6 meses se realiza un ajuste.
Los procesos deben afrontar áreas identificadas en
el estándar y se deben documentar.

ISO 9001 describe en términos generales los

elementos de un sistema de garantía de calidad
(estructura organizativa, recursos, procesos, control
de calidad, mejora de la calidad) pero no describe
como debería implementar una organización estos
elementos del sistema de calidad.
1. Responsabilidad de la gestión.
2. Sistema de calidad.
3. Revisión de contrato.
4. Control de diseño.
5. Control de datos y documentos.
6. Compras.
7. Control del producto suministrado por el cliente.
8. Identificación y posibilidad de seguimiento del producto.
9. Control de proceso.
10. Inspección y prueba.
11. Control de inspección, medición y equipo de prueba.
12. Inspección y estado de prueba.
13. Control de producto no aceptado.
14. Acción correctora y preventiva.
15. Tratamiento , almacenamiento, empaquetamiento,
preservación y entrega.
16. Control de registros de calidad.
17. Auditorias de calidad.
18. Formación.
19. Servicios.
20. Técnicas estadísticas.