Modelos de desarrollo de software - Modelo V (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: SOFTWARE DE DISTRIBUCIÓN MASIVA (COST), MODELO DE DESARROLLO ITERATIVO-INCREMNETAL, VALIDACIÓN, VERIFICACIÓN, MODELO V.

Antecedentes.

El proceso de pruebas no es un proceso aislado; las actividades de pruebas están asociadas a actividades de desarrollo de software. El desarrollo de distintos modelos de ciclo de vida requiere distintos enfoques de pruebas.

Modelo V (Modelo de desarrollo secuencial) (K2).

A pesar de que existen variantes al modelo V, el tipo de modelo V generalizado se basa en cuatro niveles de pruebas correspondientes a los cuatro niveles de desarrollo.

Los cuatro niveles que se utilizan en este programa de estudio son los siguientes:

1. Pruebas de componentes (unidades).
2. Pruebas de integración.
3. Pruebas de sistemas.
4. Pruebas de aceptación.

En la práctica, un modelo V puede tener más, menos o diferentes niveles de desarrollo y pruebas, en función del proyecto y del producto de software. Así por ejemplo, pueden realizarse las pruebas de integración de componentes a continuación de las pruebas de componente, y las pruebas de integración de sistemas después de las pruebas de sistemas.

Los productos de trabajo de software como por ejemplo : escenarios , casos de uso, especificaciones de requerimientos, documentos de diseño y código - que se elaboran en la fase de desarrollo a menudo conforman la base de las pruebas en uno o más niveles de pruebas. Las referencias a productos de trabajo genéricos incluyen el Capability Maturity Model Integration (CMMI) o "Procesos del ciclo de vida del software" (IEEE/IEC  12207). La verificación y validación ( y el diseño de pruebas temprano) pueden realizarse durante el desarrollo de los productos de trabajo de software.

Estrategia de aplicación de las pruebas.

• Se comienza en la prueba de cada módulo, que normalmente la realiza el propio personal de desarrollo en su entorno.
• Con el esquema del diseño del software, los módulos probados se integran para comprobar sus interfaces en el trabajo conjunto (prueba de integración).
• El software totalmente ensamblado se prueba como un conjunto para comprobar si cumple o no tanto los requisitos funcionales como los requisitos de rendimientos, seguridad, etc (prueba funcional o de validación).
• El software ya validado se integra con el resto del sistema (por ejemplo, elementos mecánicos, interfaces electrónicas, etc.) para probar su funcionamiento conjunto (Prueba del sistema).
• Por último, el producto final se pasa a la prueba de aceptación para que el usuario compruebe en su propio entorno de explotación si lo acepta como está o no (prueba de aceptación.). 

Relación entre productos de desarrollo y niveles de prueba.

Existe una correspondencia entre cada nivel de prueba y el trabajo realizado en cada etapa del desarrollo.

Conceptos.

Pruebas Unitarias:

Se trata de las pruebas formales que permiten declarar que un módulo está listo y terminado (no las informales que se realizan mientras se desarrollan los módulos).

Hablamos de una unidad de prueba para referirnos a uno o más módulos que cumplen las siguientes condiciones [IEEE, 1986a]:

• Todos son del mismo progarma.
• Al menos uno de ellos no ha sido probado.
• El conjunto de módulos es el objeto de un proceso de prueba.

La prueba de unidad puede abarcar desde un módulo hasta un grupo de módulos (incluso un porgrama completo).

Estas pruebas suelen realizarlas el propio personal de desarrollo, pero evitando que sea el propio programador del módulo.

Pruebas de Integración:

Implican una progresión ordenada de pruebas que van desde los componentes o módulos y que culminan en el sistema completo.

El orden de integración elegido afecta a diversos factores, como los siguientes:

• La forma de preparar casos.
• Las herramientas necesarias.
• El orden de codificar y probar los módulos.
• El coste de la depuración.
• EL coste de preparación de casos.

Tipos fundamentales de integración:

• Integración incremental. Se combina el siguiente módulo que se se debe probar con el conjunto de módulos que ya han sido probados.

1. Ascendente.- Se comienza por los módulos hojas.
2. Descendentes.- Se comienza por el módulo raíz.

• Integración no incremental. Se prueba cada módulo por separado y luego se integran todos de una vez y se prueba el programa completo.

Habitualmente las pruebas de unidad y de integración se solapan y mezclan en el tiempo.

Integración Incremental.

Proceso para la integración incremental ascendente.

• Se combinan los módulos de bajo nivel en grupos que realicen una función o subfunción específica (o quizás si no es necesario, individualmente), de este modo reducimos el número de pasos de integración.
• Se escribe para cada grupo un módulo impulsor o conductor, de este modo permitimos simular la llamada a los módulos, introducir datos de prueba y recoger resultados.
• Se prueba cada grupo mediante su impulsor.
• Se eliminan los módulos impulsores y se sustituyen por los módulos de nivel superior en la jerarquía.

Diseño modular sobre el que se realiza la integración

Primera fase de la integración ascendente del ejemplo.

Segunda y tercera fase de la integración ascendente del ejemplo

Proceso para la integración incremental descendente.

• Comienza por el módulo de control principal y va incorporando módulos subordinados progresivamente.
• No hay un orden adecuado de integración, pero unos consejos son los siguientes:

1. Si hay secciones críticas (especialmente complejas) se deben integrar lo antes posible.
2. EL orden de integración debe incorporar cuanto antes los módulos de entrada/salida para facilitar la ejecución de pruebas.

• Existen dos formas básicas de hacer esta integración:

1. Primero en profundidad: Se van completando ramas del arbol (ABECFGD)
2. Primero en anchura: Se van completando niveles de jerarquía (ABCDEFG) 

Etapas fundamentales de la integración descendente. 

• El módulo raíz es el primero: Se escriben módulos ficticios que simulan los subordinados.
• Una vez probado el módulo raíz (sin detectarse ya ningún defecto), se sustituye uno de los subordinados ficticios por el módulo correspondiente según el orden elegido.
• Se ejecutan las correspondientes pruebas cada vez que se incorpora un módulo nuevo.
• Al terminar cada prueba, se sustituye un ficticio por su correspondiente real.
• Conviene repetir algunos casos de prueba de ejecuciones anteriores para asegurarse de que no se ha introducido ningún defecto nuevo.

Qué son los módulos ficticios?

La creación de módulos ficticios subordinados es más complicada que la creación de impulsores. Listaremos    estos módulos de menor complejidad a mayor complejidad:

1. Módulos que sólo muestran un mensaje de traza.
2. Módulos que muestran los parámetros que se les pasa.
3. Módulos que devuelven un valor que no depende de los parámetros que se pasen como entrada.
4. Módulos que, en función de los parámetros pasados, devuelven un valor de salida que más o menos se corresponda con dicha entrada.

Una posible clasificación de los módulos ficticios es como se muestra en la siguiente imaágen.

Un paso intermedio en la integración descendente primero en la profundidad del ejemplo.

Un  paso intermedio en la integración descendente primero en la anchura del ejemplo.

Integración No Incremental.

 Para cada módulo que tiene que ser probado necesita lo siguiente:

1. Un módulo impulsor, que transmite o "impulsa" los datos de prueba al módulo y muestra los resultados de dichos casos de prueba.
2. Uno o mas módulos ficticios que simulan la función de cada módulo subordinado llamado por el módulo que se va a probar.

Una vez probado cada módulo por separado, se ensamblan todos de una vez y se prueban en conjunto.

Una prueba típica del módulo en la integración no incremental  es como se muestra en la siguiente imagen.

 Comparación de los distintos tipos de integración 

Ventajas de la no incremental:

1. Requiere menos tiempo de máquina para las pruebas, ya que se prueba de una vez la combinación de los módulos.
2. Existen más oportunidades de probar módulos en paralelo.

Ventajas de la incremental:

1. Requiere menos trabajo, ya que se escriben menos módulos impulsores y ficticios.
2. Los defectos y errores en las interfaces se detectan antes, ya que se empieza antes a probar las uniones entre los módulos.
3. La depuración es mucho más fácil, ya que si se detectan los síntomas de un defecto en un paso de la integración hay que atribuirlo muy probablemente al último módulo incorporado.
4. Se examina con mayor detalle el programa, al ir comprobando cada interfaz poco a poco.

Ventajas y desventajas de las integraciones ascendente y descendente.