Pruebas en un Modelo de Ciclo de Vida (K2 - entender, explicar , razonar)

Objetivos:

1. Explicar la relación existente entre desarrollo, actividades de pruebas y productos de trabajo en el ciclo de vida del desarrollo, poniendo ejemplos utilizando tipos de proyectos y productos (K2).
2. Reconocer el hecho de que los modelos de desarrollo de software deben adaptarse al contexto de las características del proyecto y del producto (K1).
3. Retener las características de buenas pruebas aplicables a cualquier modelo de ciclo de vida (K1)

Términos usados en este artículo: MODELO DE CICLO DE VIDA, BUENAS PRÁCTICAS, PRUEBAS.

Antecedentes.

En cualquier modelo de ciclo de vida que se ha seleccionado, se dan varias características de buenas pruebas:

• Para cada actividad de desarrollo existe una actividad de prueba correspondiente.
• Cada nivel de prueba tiene objetivos de pruebas específicos para dicho nivel.
• Los procesos de análisis y diseño de las pruebas para un nivel de prueba dado deben iniciarse durante la actividad de desarrollo correspondiente.
• Los probadores deben iniciar su participación en la revisión de los documentos en cuanto haya borradores disponibles en el ciclo de vida de desarrollo.

Los niveles de prueba pueden combinarse o reorganizarse en función de la naturaleza del proyecto o de la arquitectura del sistema. Así por ejemplo, para la integración de un producto de software comercial de distribución masiva (COST) en un sistema, el comprador puede realizar las pruebas de integración a nivel del sistema (por ejemplo, integración de la infraestructura y demás sistemas o despliegue del sistema) y las pruebas de aceptación (funcionales y/o no funcionales, y pruebas de usuario y/o operativas).

Resumamos los modelos de ciclo de vida.

Ahora bien, resumamos los modelos de ciclo de vida para darnos cuenta que tipo de pruebas son eficaces para las buenas prácticas.

Modelo de Cascada

1. Es un modelo orientado en las actividades.
2. Prescribe una ejecución secuencial de un subconjunto de los procesos de desarrollo y de administración.
3. Es el modelo más antiguo, propuesto por Witnston Royce en 1970.

Cuáles son sus fortalezas?

1. Fácil entendimiento e implementación.
2. Ampliamente utilizado y conocido (en teoría).
3. Refuerza buenos hábitos: definir antes que diseñar, diseñar antes que codificar.
4. Identifica entregables e hitos.
5. Orientado a documentos.
6. Funciona bien en productos maduros y equipos débiles.

Cuáles son sus debilidades?

1. No aprovecha la iteración, no el desarrollo exploratorio.
2. Espera requerimientos definidos completamente al inicio del proyecto -->IREAL.
3. Dificulta la administración del riesgo.
4. El software es entregado tarde en el proyecto. Esto hace que se detecten errores graves muy tarde.
5. Hacer cambios es difícil y costoso. 

Modelo en V

1. Busca hacer la actividad de pruebas más efectiva y productiva.
2. Los planes (y casos de prueba) se van elaborando a medida que se avanza en el desarrollo del proyecto.

Modelo en Espiral

1. Modelo centrado en las actividades.
2. Basado en las mismas actividades del modelo de cascada.
3. Introduce: manejo de riesgos y creación de prototipos.
4. Las actividades son organizadas en ciclos.
5. Un ciclo corresponde a la construcción de un producto intermedio.
6. Las actividades de cada ciclo son: 

• Determinar objetivos, 
• Especificar las restricciones, 
• Generar alternativas,
•  Identificar riesgos,Resolver riesgos, 
• Desarrollar y verificar próximo nivel del producto, 
• Desarrollar el plan del ciclo

Modelo Unified Process

1. Consiste en varios ciclos.
2. Al final de cada uno, un producto es entregado al cliente.
3. Cada ciclo consiste de cuatro fases: Inception, Elaboration, Construction y Transition.
4. Cada fase puede tener varias iteraciones.
5. Una iteración construye un conjunto de casos de uso relacionados o mitiga algún riesgo de los identificados.

Modelo Team Software Process TSP

1. Establecer un marco común para desarrollar modelos de ciclo de vida.
2. Proceso: conjunto de actividades para alcanzar un propósito.
3. 17 rocesos define el estándar organizados en grupos de procesos.
4. Cada proceso está compuesto de actividades.