Modelos de Ciclo de Vida del Software: Desarrollo y Prototipado

Modelos de Ciclo de Vida del Software

Modelo Incremental

El modelo de ciclo de vida en cascada obtiene el código como resultado de un proceso de refinamiento a partir de las especificaciones y diseño. Cuando el código es entregado al usuario es cuando este dispone de un producto sobre el que puede evaluar la satisfacción de sus necesidades. En caso de que esto no sea así, es necesario volver a las fases anteriores (costoso en tiempo y esfuerzo, sobre todo, cuando los problemas surgen de una mala interpretación de los requisitos de usuario).

Existe otro enfoque posible en el que al usuario se le van exponiendo productos intermedios denominados prototipos que le acercan al sistema final. Estos productos intermedios sirven para validar con el usuario el sistema que se está construyendo antes de realizar la implementación.

Un prototipo puede definirse como un modelo parcial ejecutable de un sistema de software. Por modelo del sistema entendemos una descripción del sistema bajo una cierta perspectiva (por ejemplo, arquitectura, datos, comportamiento) empleando notaciones no necesariamente similares al código final; lo definimos como parcial porque no es necesario que cubra todo el sistema sino aquellas partes o perspectivas que se pretenden analizar; finalmente, debe ser ejecutable para que la validación del sistema pueda hacerse a partir de la experimentación con el prototipo por parte de usuarios y analistas.

Modelo Basado en Prototipos Desechables

El modelo con prototipo desechable aborda el problema de la inestabilidad de los requisitos generando un prototipo lo antes posible que sirva de base al mejor conocimiento de los requisitos de usuario. Este prototipo es desechado cuando usuarios y desarrolladores acuerdan un documento de requisitos de usuario. La Figura 8 describe este modelo. Podemos ver cómo apoya a la fase de análisis de requisitos (tanto de usuario como de sistema) permitiendo incrementar la confianza en que los requisitos identificados son los que realmente se necesitan.

Modelo Basado en Prototipado Incremental

Si bien con el modelo basado en prototipos desechables podemos tener mayor confianza en que el producto que le entreguemos al usuario responda a los requisitos deseados por este, es aún cierto que el producto, desde el punto de vista del diseñador, puede presentar muchos problemas que sólo serán evaluados cuando el producto se haya implementado. Concretamente, algunos requisitos funcionales no pueden evaluarse en un prototipo desechable porque la estructura del sistema final no es directamente extrapolable de la del prototipo (como puede ocurrir con los requisitos temporales o aspectos de rendimiento).

Modelo de Síntesis Automatizada

Un modelo de ciclo de vida de síntesis automatizada es aquel que está basado en el empleo de una tecnología de software que permite generar automáticamente una implementación a partir de la especificación detallada de los requisitos de software del sistema (denominado especificación).

Este es el modelo de ciclo de vida que subyace bajo la utilización de métodos formales. Sin entrar en detalles sobre las tecnologías de software basadas en métodos formales (serán mencionadas en el siguiente Capítulo) vamos a indicar los aspectos básicos de este modelo. La Figura 11 representa esquemáticamente las fases seguidas en el desarrollo.

Meta-modelo en Espiral

Hace unos años, Boehm propuso un modelo de desarrollo software capaz de acomodar muchos de los modelos definidos anteriormente [8]. Debido a ello se le suele conocer como meta-modelo en espiral.

La Figura 12 representa la estructura general de este modelo. En él podemos ver cuatro cuadrantes ligados a actividades genéricas de planificación, desarrollo, evaluación y selección de alternativas. El desarrollo del sistema pasa por una serie de ciclos en los que tanto el conocimiento del sistema a realizar como el propio sistema van avanzando hasta obtener el producto final. En la última espiral se prosigue con un desarrollo convencional al haberse eliminado las incertidumbres en las espirales anteriores.

La utilización de la espiral sugiere un avance en el tiempo del desarrollo del producto y también un incremento paulatino del coste. Las espirales son progresivamente más costosas (como lo es también el coste acumulado).

La idea clave detrás del modelo es asegurar que los aspectos menos conocidos o más críticos sean realizados antes, en la suposición de que de poco sirve completar partes poco críticas si estas pueden verse modificadas o invalidadas por las partes críticas. El uso de prototipos es fuertemente promovido (aunque basado en prototipos desechables). En este sentido, el mismo Boehm indica que la característica esencial es la orientación hacia la identificación y resolución de riesgos.

Concepto de Tecnología de Software

Definimos tecnología de software como un conjunto integrado de notaciones, herramientas y métodos, basados en unos sólidos fundamentos, que permiten el desarrollo de un producto software en un contexto organizativo dado.

• Marco de razonamiento. Por marco de razonamiento nos referimos al conjunto de conceptos y mecanismos que una tecnología de software posee para asegurar que el sistema se basa en la existencia de unos conceptos rigurosos y bien relacionados o, mejor aún, de un modelo matemático para representar la ejecución de un programa. Este modelo matemático, convenientemente manipulado, permite obtener información sobre el sistema en construcción.
• Notaciones. Lenguajes para poder describir el sistema en desarrollo.
• Métodos de desarrollo. Los métodos de desarrollo indican cómo proceder para ir de los requisitos al diseño y de este a la implementación, aprovechando las notaciones y herramientas disponibles y sabiendo cómo dividir el trabajo entre los componentes del equipo humano de desarrollo.

Los métodos proporcionan una disciplina en el proceso de refinamiento que guía al diseñador a lo largo de varias fases, desde la descripción de los requisitos en lenguaje natural hasta su completa especificación. Posteriormente, a esa especificación se le añaden las decisiones de diseño continuando el proceso de refinamiento hasta poder implementar el sistema en un lenguaje convencional.