En la literatura existe una multitud de modelos de ciclo de vida. Algunos son prescripciones sobre la forma en la que debería realizarse el desarrollo de software, mientras que otros son descripciones de la forma en la que se desarrollan programas actualmente. En teoría ambos tipos de modelos deberían ser iguales o similares, pero en la práctica no lo son. La construcción un modelo de ciclo de vida y la discusión sobre sus subprocesos ayuda a comprender este salto entre lo que debería ser y lo que realmente es.
Modelo de Cascada
En los años 70 se impuso un nuevo enfoque de desarrollo del software, introducido por Royce en 1970, a través de un ciclo de vida en “cascada” (así denominado por la disposición de las distintas fases de desarrollo, en las que los resultados de una fase parecen caer en cascada hacia la siguiente fase, tal como se muestra en la Figura 1). El método ideado por Royce constituye uno de los primeros modelos de ciclo de vida publicados, por lo que también recibe el nombre de modelo de ciclo de vida clásico. Este método modela el ciclo convencional de la Ingeniería del Software, aplicando un enfoque sistemático y secuencial de desarrollo que comienza con la ingeniería del sistema y progresa a través del análisis, diseño, codificación, pruebas y mantenimiento.
Como sugiere el esquema del modelo en cascada, antes de poder avanzar a la siguiente etapa, es necesario haber finalizado completamente la etapa anterior. Asociada con cada etapa del proceso existen hitos y documentos, de tal forma que se puede utilizar el modelo para comprobar los avances del proyecto y para estimar cuánto falta para su finalización.
Este modelo es muy útil pues ayuda a los desarrolladores a comprender qué es lo que tienen que hacer en cada momento. Su simplicidad hace que resulte sencillo explicárselo a los clientes que no están familiarizados el proceso software. Además, se muestran de forma explícita qué productos intermedios se tienen que obtener antes de abordar las siguientes tareas.
Una modificación sobre este modelo consiste en la introducción de una revisión y vuelta atrás, con el fin de corregir las deficiencias detectadas durante las distintas etapas, o para completar o aumentar las funcionalidades del sistema en desarrollo, resultando un diagrama de fases y etapas tal como el que se muestra en la Figura 2. De esta manera, durante cualquiera de las fases se puede retroceder momentáneamente a una fase previa para solucionar el problemas que se pudieran haber encontrado.
Normalmente, el ciclo de vida del software se suele dividir en tres fases: una de Planificación, otra de Desarrollo y una tercera de Mantenimiento, que engloban a las seis etapas (Ingeniería del Sistema, Análisis de los Requisitos, Diseño, Codificación, Pruebas y Mantenimiento) tradicionales del ciclo de vida.
La fase de Planificación del software comprende las etapas de Ingeniería del Sistema o Análisis del Sistema (en concreto el establecimiento de los Requisitos del Software o “Plan Software”) y el Análisis de los Requisitos del Software (que se traduce en una “Especificación de Requisitos”). La fase de Desarrollo comprende las etapas de Diseño, Codificación y Pruebas. Por último, la fase de Mantenimiento incorpora solamente la etapa propia de Mantenimiento.
A pesar de su antigüedad, el ciclo de vida clásico se ha hecho con un lugar importante en el área de la Ingeniería del Software. Proporciona una guía de trabajo en la que se encuentran métodos para el análisis, diseño, codificación, pruebas y mantenimiento. El ciclo de vida en cascada sigue siendo el modelo de proceso más extensamente utilizado por los ingenieros del software, principalmente por su sencillez y facilidad de llevar a cabo. Pese a tener debilidades, es significativamente mejor que un enfoque arbitrario (como el de codificar y corregir) para el desarrollo del software. Muchos de los posteriores modelos de ciclo de vida son, en realidad, modificaciones sobre el modelo clásico, al que se le incorporan iteraciones o nuevas actividades.
Modelo en V
El modelo en V es una variación del modelo en cascada que muestra cómo se relacionan las actividades de prueba con el análisis y el diseño. Como se muestra en la Figura 3, la codificación forma el vértice de la V, con el análisis y el diseño a la izquierda y las pruebas y el mantenimiento a la derecha.
La unión mediante líneas discontinuas entre las fases de la parte izquierda y las pruebas de la derecha representa una doble información. Por un lado sirve para indicar en qué fase de desarrollo se deben definir las pruebas correspondientes. Por otro sirve para saber a qué fase de desarrollo hay que volver si se encuentran fallos en las pruebas correspondientes.
Por lo tanto el modelo en V hace más explícita parte de las iteraciones y repeticiones de trabajo que están ocultas en el modelo en cascada. Mientras el foco del modelo en cascada se sitúa en los documentos y productos desarrollados, el modelo en V se centra en las actividades y la corrección.
Prototipado
En contraste con la Ingeniería de Software de la década de los 70, que dio respuesta a proyectos grandes pero con requisitos estables, la Ingeniería de Software de los 80 reaccionó a las complicaciones resultantes de encontrarse con requisitos poco claros y dinámicos, dando lugar a la “construcción de prototipos”. El modelo de ciclo de vida de prototipos fue propuesto por Gomaa en 1984.
Un prototipo es un mecanismo para identificar los requisitos del software. La construcción de prototipos es un proceso que facilita al ingeniero de software el desarrollo de la aplicación. El prototipo suele tomar una de las tres formas siguientes:
• Un modelo en papel o en computadora que describe la interacción hombre-máquina, de forma que facilite al usuario la comprensión de su funcionamiento. Por ejemplo, si el sistema a construir es un cajero automático, se puede hacer un programa que simule la interacción del usuario con el cajero sin que el programa esté conectado a ninguna base de datos real ni se despache dinero. De esta manera el cliente puede hacerse a la idea de cómo va a funcionar el sistema final sin tener que construirlo, y así discutirlo con el ingeniero de software. Naturalmente, en un prototipo no se simularán todas las funcionalidades del sistema pero, si es necesario, se podrán construir otros a medida que la aplicación se vaya desarrollando (ver más abajo cuáles son las etapas para su utilización)
• Un modelo que implementa una función requerida importante. Es el mismo caso que anteriormente pero sin centrarse en la interacción hombre-máquina. Por ejemplo, el modelo podría simular todos los pasos a seguir internamente en el sistema en el acceso a la base de datos de clientes cuando se quiere obtener dinero del cajero, pero sin que realmente se trate de una base de datos real ni de un cliente del banco.
• Un programa real que se adecue en parte al software que se desea desarrollar. Por ejemplo, se puede disponer de una aplicación relacionada con un “cajero automático”, que al presentarla al cliente, permita al analista identificar las necesidades del cliente y por lo tanto los requisitos del software a construir.
Normalmente, el prototipo sirve como mecanismo para identificar los requisitos del software, y su construcción suele llevar las siguientes etapas:
1) Recolección de requisitos. El ingeniero de software y el cliente definen los objetivos globales del software, y aquéllos más específicos que se desean destacar con el prototipo.
2) Diseño rápido. Centrado en los aspectos del software visible al usuario (por ejemplo, interfaz de usuario, entradas y salidas...).
3) Construcción del prototipo.
4) Evaluación del prototipo. Se realiza por el cliente y usuarios, lo que permitirá concretar y refinar los requisitos del software a desarrollar.
5) Refinamiento del prototipo. Se produce un proceso iterativo en el que el prototipo es refinado para que satisfaga las necesidades del cliente, al tiempo que facilita al ingeniero de software un mejor conocimiento del sistema.
6) Producto. En la mayoría de los casos este sistema refinado (piloto) hay que desecharlo y hacer uno nuevo. Por ello, el desarrollo de un prototipo se debe planificar con el acuerdo expreso del cliente.
Algunos ingenieros del software abogan por desarrollar rápidamente un prototipo que les permita especificar completamente el sistema y obtener más consistentemente el producto final. Sobre el desarrollo rápido de prototipos, pueden realizarse las siguientes observaciones:
• Un prototipo rápido es básicamente una técnica de análisis que permite completar el conjunto de requisitos funcionales de un sistema software.
• Lo deseable es evolucionar el prototipo hasta obtener el producto final, en lugar de deshacerlo y construir un producto final nuevo. Este deseo es válido si del prototipo se puede obtener dicho producto (lo que no suele ser fácil), y su coste es inferior a su reconstrucción. Incluso, se podría recomendar utilizar aquellas técnicas que permitan evolucionar un prototipo hasta el producto final.
• Cualquier aplicación nueva que el ingeniero de software sospeche que su funcionalidad puede presentar el riesgo de no ser aceptable para el usuario o si la interfaz de usuario es importante para el éxito de la aplicación, es una aplicación fuertemente candidata para que se desarrolle un rápido prototipo.
• En un proyecto de prototipado bien planificado, aproximadamente el 50% del esfuerzo de desarrollo, desde su inicio hasta la aprobación final de su funcionalidad, es la contribución del usuario. Los equipos de prototipado están compuestos típicamente por la mitad de usuarios y la otra mitad de desarrolladores software.
• Es habitual tener que tirar la primera versión de cualquier sistema que se desarrolle por primera vez. Por ello, es aconsejable que la primera demostración de un prototipo rápido sea intencionalmente imperfecta, de forma que sea barato de producir y muy fácil de modificar, para que se pueda garantizar que el sistema final que se suministra se ajuste mejor a los requisitos del usuario.
• El prototipado rápido es una solución que “evita el riesgo” en lugar de una solución de riesgo. Así, el prototipado rápido no introduce nuevos riesgos políticos o económicos al proceso de desarrollo de software, sino que reduce significativamente varios factores de riesgo asociados con su desarrollo, como los que se han señalado anteriormente.
• El prototipado rápido es un método normal para el desarrollo de nuevas aplicaciones y llegará a ser más y más evidente que el prototipado rápido produce mejores sistemas y con costes más bajos.
Desarrollo Rápido de Aplicaciones
El Desarrollo Rápido de Aplicaciones, abreviado como RAD (del inglés Rapid Application Development) es un modelo de ciclo de vida que enfatiza un desarrollo extremadamente corto. Se trata de una adaptación del modelo tradicional en cascada en el que se logra el desarrollo rápido utilizando una construcción basada en componentes. Si se comprenden bien los requisitos y se limita el ámbito del proyecto, el proceso RAD permite crear un sistema completamente funcional dentro de periodos cortos de tiempo (entre 60 y 90 días).
Cuando se utiliza para aplicaciones de sistemas de información, el enfoque RAD tiene las siguientes fases:
1. Modelado de Gestión: se modela el flujo de información entre las funciones de gestión.
2. Modelado de Datos: se refina el flujo de información como un conjunto de objetos de datos necesarios para apoyar la empresa. Se definen las características de cada uno de los objetos y sus relaciones.
3. Modelado del Proceso: se definen las transformaciones (añadir, modificar, suprimir o recuperar) sobre los objetos del modelo de datos para lograr los flujos de información de cada función de gestión.
4. Generación de Aplicaciones: codificación de una función de gestión.
5. Pruebas y entrega: prueba de los componentes y entrega del programa que realiza una función de gestión.
La clave del modelo RAD está en los cambios en las etapas de codificación y pruebas:
• Codificación. El modelo RAD asume la utilización de técnicas de cuarta generación. En lugar de crear software con lenguajes de programación de tercera generación, se trabaja para volver a utilizar componentes de programas ya existentes (cuando es posible) o a crear componentes reutilizables (cuando sea necesario). En todos los casos se utilizan herramientas para facilitar la construcción de software.
• Pruebas. Como se enfatiza la reutilización, ya se han comprobado muchos de los componentes de los programas. Esto reduce en muchos casos el tiempo de pruebas, aunque se deben probar todos los componentes nuevos y se deben ejercitar todas las interfaces a fondo.
El modelo de ciclo de vida RAD se muestra en la Figura 4. Las limitaciones de tiempo impuestas en un proyecto RAD exigen que la aplicación cumpla con el requisito de “ámbito en escalas”, que indique que una aplicación pueda modularse de forma que cada una de las funciones principales pueda completarse en menos de tres meses. Además, cada una de las funciones puede ser afrontadas por un equipo RAD separado e integrarse en un único conjunto.
Modelo en Espiral
Boehm cerró la década de los 80 publicando en 1988 un modelo de ciclo de vida en espiral (Figura 5) que sustituye a la solución en fases del “modelo en cascada” con ciclos de experimentación y aprendizaje. El modelo incorpora un nuevo elemento en el desarrollo de software como es el “análisis de riesgos” y define cuatro actividades principales representadas por los cuatro cuadrantes de la figura:
• Planificación -> Determina objetivos, alternativas y restricciones
• Análisis de riesgo -> Evalúa alternativas, identifica y resuelve riesgos.
• Ingeniería -> Desarrollo y verificación del producto del siguiente nivel.
• Evaluación del cliente -> Valoración de los resultados y planificación de la siguiente fase.
Con cada iteración alrededor de la espiral (comenzando en el centro y siguiendo hacia el exterior), se van construyendo sucesivas versiones del software, cada vez más completas. Durante la primera vuelta de la espiral, en el primer cuadrante (superior izquierdo) se determinan objetivos, alternativas y restricciones; y en el segundo cuadrante (superior derecho) se analizan e identifican los riesgos (¿se dispone de personal?, ¿está preparado?, ¿existe mercado para el producto?, etc.). Si el análisis de los riesgos indica que existe incertidumbre en los requisitos se puede desarrollar un prototipo para su valoración, y también se pueden usar simulaciones y otros modelos para definir más el problema y refinar los requisitos.
En el cuadrante tercero (inferior derecho) se incorporan incrementalmente las etapas del ciclo de vida tradicional en cada ciclo de la espiral.
En el cuarto cuadrante (inferior izquierdo) el cliente evalúa el trabajo de ingeniería de esa espiral y sugiere modificaciones. Basándose en los comentarios del cliente, se produce la siguiente fase de planificación y de análisis de riesgos. En cada bucle alrededor de la espiral, al finalizar el análisis de riesgo, se debe tomar la decisión de seguir adelante o no con el proyecto. Si se sigue avanzando, cada vuelta alrededor de la espiral conduce más hacia fuera, hacia un modelo más completo del sistema, y al final al propio sistema operacional. Cada vuelta requiere más desarrollo de ingeniería de software, y el número de actividades del tercer cuadrante aumenta al alejarse del centro de la espiral.
El paradigma del modelo en espiral es actualmente el enfoque más realista en la ingeniería del software tradicional para sistemas grandes, ya que utiliza un enfoque evolutivo que permite al ingeniero y al cliente entender y reaccionar a los riesgos que se detectan en cada espiral. Utiliza la creación de prototipos como un mecanismo de reducción del riesgo y mantiene el enfoque del ciclo de vida clásico, pero incorporándolo dentro de un proceso iterativo que refleja de forma más realista el mundo real. No se disponen de cifras comparativas de su bondad con respecto a otros ciclos de vida, pero indudablemente sus resultados parecen superiores ya que engloba a los ciclos clásicos y de prototipos.
Otros ciclos de vida
Con el fin de completar la enumeración de los modelos de ciclo de vida, se recogen de forma muy resumida dos modelos muy distintos de los anteriores:
• Modelo de especificación operativa. Este modelo fue propuesto por Zave en 1984 y se basa en que los requisitos del sistema se evalúan o ejecutan de una forma que demuestra el comportamiento del sistema. Esta especificación operativa (escrita en un lenguaje de especificación formal que pueda ser interpretado por un ordenador) puede transformarse posteriormente una especificación más orientada a la implementación, que se convierte en el sistema (Figura 6).
• Modelo de transformación: se utiliza soporta automatizado para realizar una serie de transformaciones que conviertan una especificación en un sistema completo. Este modelo fue propuesto por Blazer en 1981 y también requiere la existencia de una especificación escrita en un lenguaje formal (Figura 7).
No hay comentarios:
Publicar un comentario