CRISTIAN JOEL MONROY PINTO

CAPITULO 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?
CRISTIAN JOEL MONROY PINTO

- 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 “antierrores” (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 antierror.

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 numero 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.
CRISTIAN JOEL MONROY PINTO

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 esta formado el software.