Capítulo 17

17.1. Con sus palabras, describa la diferencia entre verificación y validación. ¿Ambas usan
los métodos de diseño de casos de prueba y estrategias de pruebas?

Verificación: conjunto de actividades que aseguran que el software implementa correctamente

una función específica.

Validación: son las actividades que buscan asegurar si el software construido se ajusta a los
requisitos del cliente.

Ambas utilizan los métodos de diseño de casos de prueba y estrategias de pruebas.

17.2. Mencione algunos problemas que pueden asociarse con la creación de un grupo de
prueba independiente. ¿Los GPI y el SQA se integran con las mismas personas?

El propósito de un GIP (Grupo Independiente de Prueba) es el de eliminar el conflicto de

intereses que, de otro modo, estaría presente. Al personal del equipo que forma .el equipo
independiente se le paga para que encuentre errores. El responsable del desarrollo del
software no entrega simplemente el programa al GIP y se desentiende. El responsable del
desarrollo y el GIP trabajan estrechamente a lo largo del proyecto de software para asegurar
que se realizan pruebas “exhaustivas”, mientras se realiza la prueba, el desarrollador debe
estar disponible para corregir los errores que se van descubriendo.

La verificación y la validación abarcan una amplia lista de actividades SQA (Software Quality
Assurance) que incluye:

Revisiones técnicas formales, auditorias de calidad y de configuración, monitorización de

rendimientos, simulación, estudios de factibilidad, revisión de la documentación, revisión de la
base de datos, análisis algorítmico, pruebas de desarrollo, pruebas de validación y pruebas de
instalación.

Las pruebas constituyen el último bastión desde el cual se puede evaluar la calidad y descubrir
los errores. Pero las pruebas no deben ser vistas como una red de seguridad. No se pueden
probar la calidad. Si no está ahí antes de comenzar la prueba, no estará cuando se termine.

17.3. ¿Siempre es posible desarrollar una estrategia para probar software que usa la
secuencia de pasos de prueba descritos en la sección 17.1.3? ¿Qué posibles complicaciones
pueden surgir para sistemas incrustados?

- Que todos los componentes se dañen

- Difícil de reparar
- No se puede modificar

17.4. ¿Por qué un módulo altamente acoplado es difícil para la prueba de unidad?

Acoplamiento: Cuando por ejemplo una clase A, usa una clase B, entonces se dice que A
depende de B. En este caso, A no puede realizar su trabajo sin B, y A no puede ser reutilizada
sin tener que reutilizar B. Entonces, como A depende de B, se dice que hay acoplamiento.

Una de las posibles causas de esto puede ser que los módulos del software estén altamente
acoplados entre sí, y por no controlarlo, no te des ni cuenta de ello.

17.5. El concepto de “anti errores” (sección 17.3.1) es una forma extremadamente efectiva
de brindar asistencia de depuración interna cuando se descubre un error:

a) Desarrolle un conjunto de lineamientos para anti error.

Lo perfecto es enemigo de lo bueno. Las leyes, los reglamentos y las herramientas de puesta
en práctica no tienen que ser perfectas, sino que deben funcionar. Mientras más sencillas
sean, más fácil será poner en práctica el control de calidad desde el inicio.

Es conveniente crear una única Autoridad de Aguas, pero de no ser posible, es necesario
reducir los costos provocados por el proceso de toma de decisiones aisladas y los conflictos
interinstitucionales frente al usuario.

b) Analice las ventajas de usar la técnica.

Ayuda a seguir pasos para reducir el número de errores o fallos al momento de realizar un
proyecto

c) Analice las desventajas.

Si no se realiza como esta descrito en la técnica puede ampliar el número de errores en el

proyecto.

17.6. ¿Cómo puede la calendarización del proyecto afectar la prueba de integración?

Es una actividad que distribuye estimaciones de esfuerzo a través de la duración planificada del
proyecto, al asignar el esfuerzo a tareas específicas de ingeniería del software.

Cuando no todos los grupos terminan partes del software en una fecha indicada.

17.7. ¿La prueba de unidad es posible o incluso deseable en todas las circunstancias?
Proporcione ejemplos para justificar su respuesta.

- Detectar un error específico.

- Descubrir errores no descubiertos antes.
- Tener un buen caso de prueba.

Además, los atributos que debería tener una buena prueba son:

- Intentar obtener la más alta probabilidad de encontrar un error.

- No debe ser redundante.
- No debe ser ni demasiado sencilla ni demasiado compleja.

17.8. ¿Quién debe realizar la prueba de validación: el desarrollador o el usuario del

software? Justifique su respuesta.

Un desarrollador experto porque puede dar un criterio tanto de la parte que va a manejar el
usuario como de la manera lógica que está formado el software.