ASEGURAMIENTO DE CALIDAD. ING. DE SOFTWARE

...

- 8.11 – Revise la tabla 8.1 y seleccione las cuatro causas vitales de errores serios y moderados. Sugiera acciones correctoras basándose en la información presentada en otros capítulos.

Graves.

- Especificación incompleta o errónea (EIE). Volver hacer otra reunión TFEA.

- Error en la presentación de datos (ERD). Recurrir a la herramienta CASE.

- Error en la traducción del diseño al lenguaje de programación (TLP).

- Error en la lógica del diseño (ELD).

Moderados.

- Especificación incompleta o errónea (EIE). Volver hacer otra reunión TFEA.

- Mala interpretación de la comunicación del cliente (MCC). Llevar a cabo cuidadosamente la reunión TFEA, donde se definen los objetivos, procesos y restricciones del software.

- Error en la presentación de datos (ERD). Recurrir a la herramienta CASE.

- Prueba incompleta o errónea (PIE).

- 8.14 – El concepto de TMEF del software sigue abierto a debate. ¿Puede pensar en algunas razones para ello?

El TMEF es una herramienta para medir los fallos del sistema, pero no es la más indicada para medir su fiabilidad partiendo de esta. La tasa de fallo varía en cada programa por lo que no es un buen dato para medir la fiabilidad e incluso si se corrigen todos los fallos, no tendrá un gran impacto en la fiabilidad del software. Esto sucede porque el usuario de enfrenta a los fallos, no al número total de ellos. Medir la disponibilidad del software (probabilidad de que funcione bien) es más factible.

- 8.15 – Considere dos sistemas de seguridad crítica que estén controlados por una computadora. Liste al menos tres peligros para cada uno de ellos si se puedan relacionar directamente con los fallos del software.

Un sistema de seguridad para que los empelados accedan a ciertas áreas de la empresa usando su huella digital. Incumplimiento en los estándares de programación (IEP); Pruebas incompletas o errónea (PIE) y Error en la traducción del diseño al lenguaje de programación (TLP). Estos pueden causar el acceso de un empleado no autorizado a una planta, que el sistema le niegue el acceso a todo el mundo por un tiempo indefinido, etc.

Un sistema de alarmas en una casa o negocio. Interfaz del módulo inconsistente (IMI); Pruebas incompletas o erróneas (PIE) y Error en la traducción del diseño al lenguaje de programación (TLP).

- Elabore un esquema resumido de un plan SQA (Para el proceso final de Ing. De Software I), con un ejemplo para cada uno de sus componentes (documentos, requisitos, procedimientos, etc.). Como fuente adicional, puede utilizar el documento contenido en la fuente No. 3 disponible en el grupo web de la materia.

Organización

Rol

Responsable/s

Administrador

Pabel López,Joan Cespedes

Analista

Pabel López,Joan Cespedes

Responsable SQA

Joan Cespedes

Diseñador Interfaz Usuario

Pabel López

Implementador

Joan Cespedes

Verificación y pruebas

Pabel López

Planificación

Actividad

Semana de realización

Elaboración del plan SQA

1

Evaluar y ajustar Plan SQA

2, 4

Revisar el ajuste del proceso

2,3,4,5,6,7

Revisión Técnica Formal (RTF)

3,4,6

Realizar el informe final de calidad

8

Responsabilidades

Producto

Responsable

Documento de Requerimientos

Pabel López,Joan Cespedes

Modelo de caso de uso

Pabel López,Joan Cespedes

Alcance del sistema

Pabel López,Joan Cespedes

Descripción de la arquitectura

Pabel López,Joan Cespedes

Modelo de diseño

Pabel López,Joan Cespedes

Modelo de datos

Pabel López,Joan Cespedes

Estándar de implementación

Joan Cespedes

Estándar de documentación técnica

Joan Cespedes

Documento de estimaciones

Joan Cespedes

Documentos de riesgos

Pabel López

Plan de proyecto

Joan Cespedes

Plan de validación y verificación

Pabel López

Plan de implantación

Joan Cespedes

Documentación de usuario

Pabel López

Plan de gestión de configuración

Pabel