3.5.4 Implementación y pruebas

 

Implementación

En la implementación empezamos con el resultado del diseño e implementamos el sistema en término de componentes, es decir, ficheros de código fuente, scripts, ficheros de código binario, ejecutables y similares.

La implementación es el centro durante las iteraciones de construcción, aunque también se lleva a cabo trabajo de implementación durante la fase de elaboración, para crear la línea base ejecutable de la arquitectura, y durante la fase de transición para tratar defectos tardíos.

En este flujo de trabajo se implementan las clases y objetos en ficheros fuente, binarios, ejecutables y demás. Además, se deben hacer las pruebas de unidad, es decir, cada implementador es responsable de probar las unidades que produzca. El resultado final de este flujo de trabajo es un sistema ejecutable.

En cada iteración habrá que hacer lo siguiente:

  • Planificar qué subsistemas deben ser implementados y en qué orden deben ser integrados, formando el Plan de Integración.
  • Cada implementador decide en qué orden implementa los elementos del subsistema.
  • Si encuentra errores de diseño, los notifica.
  • Se prueban los subsistemas individualmente.
  • Se integra el sistema siguiendo el plan.

La estructura de todos los elementos implementados, forma el modelo de implementación. La integración debe ser incremental, es decir, en cada momento sólo se añade un elemento. De este modo, es más fácil localizar fallos y los componentes se prueban más a fondo. En fases tempranas del proceso se pueden implementar prototipos para reducir el riesgo. Su utilidad puede ir desde ver si el sistema es viable desde el principio, probar tecnologías o diseñar la interfaz de usuario. Los prototipos pueden ser exploratorios (desechables) o evolutivos. Estos últimos llegan a transformarse en el sistema final.

Pruebas

Los objetivos de la prueba son:

  • Planificar las pruebas necesarias en cada iteración, incluyendo las pruebas de integración y las pruebas de sistema.
  • Diseñar e implementar pruebas creando los casos de prueba (especifican qué probar), procedimientos de prueba (especifican cómo realizar las pruebas), creando componentes de prueba para automatizar las pruebas.
  • Realizar las pruebas. 

Este flujo de trabajo es el encargado de evaluar la calidad del producto que estamos desarrollando, pero no para aceptar o rechazar el producto al final del proceso de desarrollo, sino que debe ir integrado en todo el ciclo de vida.

Esta disciplina brinda soporte a las otras disciplinas. Sus objetivos son:

  • Encontrar y documentar defectos en la calidad del software.
  • Generalmente asesora sobre la calidad del software percibida.
  • Provee la validación de los supuestos realizados en el diseño y especificación de requisitos por medio de demostraciones concretas.
  • Verificar las funciones del producto de software según lo diseñado.
  • Verificar que los requisitos tengan su apropiada implementación.

Las actividades de este flujo comienzan pronto en el proyecto con el plan de prueba (el cual contiene información sobre los objetivos generales y específicos de las prueba en el proyecto, así como las estrategias y recursos con que se dotará a esta tarea) o incluso antes, con alguna evaluación durante la fase de inicio y continuará, durante todo el proyecto.

El desarrollo del flujo de trabajo consistirá en planificar qué es lo que hay que probar, diseñar cómo se va a hacer, implementar lo necesario para llevarlos a cabo, ejecutarlos en los niveles necesarios y obtener los resultados, de forma que la información obtenida nos sirva para ir refinando el producto a desarrollar.