El Ciclo de Vida de los Sistemas

En esta entrada desarrollamos el Tema dedicado al concepto de ciclo de vida de los sistemas de información.

Concepto de Ciclo de Vida de un Sistema de Información.

Según el estandar ISO-12207 el ciclo de vida de un sistema de información es el marco de referencia que contiene los procesos, las actividades y las tareas involucradas en el desarrollo, la explotación y el mantenimiento de un producto de software, abarcando la vida del sistema desde la definición de los requisitos hasta la finalización de su uso.

El ciclo de vida es el conjunto de fases (o etapas) por las que pasa el sistema desde que se concibe hasta que se retira del servicio. Es decir, se trata de la estructura del proceso de producción del sistema de información. El Modelo de Ciclo de Vida indica cuáles son las actividades a realizar y el orden en que se van a realizar.

Todo ciclo de vida debe cubrir tres objetivos básicos:

1. Definir las actividades a realizar y en qué orden.
2. Asegurar la consistencia con el resto de los sistemas de información de la organización.
3. Proporcionar puntos de control para la gestión del proyecto (calendario y presupuesto). No hay que confundir este concepto con el de método o metodología, la metodología indica cómo avanzar en la construcción del sistema esto es con qué técnicas, puede determinar los recursos a utilizar o las personas implicadas en cada actividad entre otras características.

El ciclo de vida nos indica las activ¡dades a realizar, y en qué orden, para construir un Sistema de Información. Una metodología indica cómo avanzar en la construcción del sistema, es decir, las técnicas a seguir.

Descripción del ciclo de vida según la norma ISO-12207.

Según la Norma ISO 12207-1, las actividades a realizar durante el ciclo de vida del software se agrupan en cinco procesos principales, ocho procesos de soporte y cuatro procesos de la organización, así como un proceso especial que permite adaptar el ciclo de vida a cada proyecto concreto. A destacar que la norma no recomienda ningún modelo concreto de ciclo de vida, ni de gestión del software, ni detalla cómo realizar ninguna de las actividades.

Los procesos principales del ciclo de vida

Son aquellos que resultan útiles a las personas que inician o realizan el desarrollo, la explotación o el mantenimiento del software a lo largo del ciclo de vida. Estas personas son los compradores, los proveedores, el personal de desarrollo, los usuarios y el personal encargado del mantenimiento del software.

• Proceso de adquisición: Contiene las actividades y tareas que el comprador, el cliente o el usuario realizan para adquirir un sistema o un producto software. Aquí están incluidos la preparación y publicación de una solicitud de ofertas, la selección del proveedor del software y la correspondiente gestión de los procesos desde la adquisición hasta la aceptación del producto.
• Proceso de suministro: Contiene las actividades y tareas que el suministrador o proveedor realiza. Comienzan con la preparación de una propuesta para responder a una petición de oferta de un comprador o con la firma de un contrato con el comprador para proporcionarle un producto software. Trata, asimismo, de la identificación de los procedimientos y de los recursos necesarios para gestionar y garantizar el éxito del proyecto, incluyendo el desarrollo de los planes del proyecto y la ejecución de dichos planes hasta la entrega del producto software al comprador.
• Proceso de desarrollo: Contiene las actividades de análisis de requisitos, diseño, codificación, integración, pruebas e instalación y aceptación.
  
  • Análisis de requisitos del sistema: Aquí son especificados todos los requisitos del Sistema de Información, funciones y capacidades que debe cumplir, requisitos de seguridad, interfaces, de mantenimiento, etc.
  • Diseño de la arquitectura del sistema: Se identifican los principales componentes hardware y software.
  • Análisis de los requisitos de software: Se establecen dichos requisitos, incluyendo el nivel de calidad que debe cumplir el sistema.
  • Diseño de la arquitectura del software: El diseñador debe transformar el análisis anterior en una arquitectura en la que se puedan identificar sus componentes principales.
  • Diseño detallado del software: Aquí se realiza un diseño detallado de cada componente software, de las bases de datos y manuales de usuario.
  • Codificación y pruebas unitarias: Se desarrollan y se documentan los componentes del punto anterior.
  • Pruebas de integración: Se integran los componentes del software realizando las correspondientes pruebas.
  • Prueba del software: Las pruebas se planifican y diseñan de forma sistemática para poder detectar el máximo número y variedad de defectos con el mínimo consumo de tiempo y esfuerzo.
  • Integración del sistema: Aquí se realizan las pruebas conjuntas de los elementos hardware y software.
  • Implantación del software desarrollado en el entorno de explotación final. Cuando se sustituya a un software ya existente, puede ser recomendable un período de tiempo en el que convivan los dos sistemas.
• Proceso de aceptación del software.
• Proceso de explotación: Comprende la propia explotación del software y el soporte operativo a los usuarios del sistema.
• Proceso de mantenimiento: Aparece cuando, tarde o temprano, el software requiere modificaciones, bien por errores, necesidades de mejora, etc.

Como podemos apreciar, los procesos y subprocesos de la metodología METRICA V3 se corresponden perfectamente con los procesos principales del ciclo de vida de sistemas de Informacion de la norma ISO. METRICA, además, especifica las actividades y tareas, y las técnicas y entregables a generar (frente a la norma, que se limita a describir los procesos del ciclo de vida).

Procesos de soporte.

Sirven de apoyo al resto de procesos y pueden aplicarse en cualquier punto del ciclo de vida.

• Proceso de documentación: Comprende todas las actividades que permiten desarrollar, distribuir y mantener la documentación necesaria para todas las personas involucradas : consultores, jefes de proyecto, analistas, programadores, usuarios, etc.
• Proceso de gestión de la configuración: Controla las modificaciones y las versiones de los elementos de configuración del software del sistema.
• Proceso de aseguramiento de la calidad: Comprueba que los procesos y los productos software del ciclo de vida cumplen con los requisitos especificados y se ajustan a los planes establecidos.
• Proceso de verificación: El objetivo es demostrar la consistencia, completitud y corrección del software entre las fases del ciclo de desarrollo de un proyecto (por ejemplo, si el código es coherente con el diseño). Este proceso puede ser responsabilidad de una empresa de servicios y, en este caso se conoce como proceso de verificación independiente.
• Proceso de validación: El objetivo es determinar la corrección del producto final respecto a las necesidades del usuario. Al igual que el anterior, este proceso puede ser ejecutado por una organización de servicios, denominándose proceso de validación independiente.
• Proceso de revisión conjunta: Para evaluar el estado del software y sus productos en una determinada actividad del ciclo de vida o una fase de un proyecto. Las revisiones conjuntas se celebran tanto a nivel de gestión como a nivel técnico del proyecto a lo largo de todo su ciclo de vida. Un mecanismo habitual de revisión son las reuniones y la responsabilidad es generalmente compartida entre un grupo de personas pertenecientes a la organización.
• Proceso de auditoría: Permite determinar, en los hitos preestablecidos, si se han cumplido los requisitos, los planes y, en suma, el contrato.
• Proceso de resolución de problemas: Permite analizar y solucionar los problemas, sean éstos diferencias con los requisitos o con el contrato. Aporta un medio oportuno y documentado para asegurar que los problemas detectados son analizados y solucionados.

Los procesos de soporte de la norma se corresponden con las INTERFASES de METRICA V3 (gestión de proyectos, aseguramiento de la calidad, gestión de la configuración, etc)

Procesos de la organización.

Son los utilizados por una organización para llevar a cabo funciones como la gestión, formación del personal o procesos de mejora continua.

• Proceso de gestión: Contiene las actividades y las tareas genéricas que puede emplear una organización que tenga que gestionar sus procesos. Incluye actividades como la planificación, el seguimiento y control, la revisión y evaluación.
• Proceso de infraestructura: Establece la infraestructura necesaria para cualquier otro proceso: hardware, software, herramientas, técnicas, etc para el desarrollo, explotación y mantenimiento.
• Proceso de mejora: Para mejorar los procesos del ciclo de vida del software.
• Proceso de formación: Para mantener al personal con la adecuada formación, lo que conlleva el desarrollo del material de formación, así como la implementación del plan de formación de la organización.

Proceso de adaptación.

Sirve para realizar la adaptación básica de la norma ISO 12207-1 respecto a los proyectos software. Como es sabido, las variaciones en las políticas y procedimientos de la organización, los métodos y estrategias de adquisición, el tamaño y complejidad de los proyectos, los requisitos del sistema y los métodos de desarrollo, entre otros, influencian la forma de adquirir, desarrollar, explotar o mantener un sistema.

Dado que los procesos se aplican durante el ciclo de vida del software, y además se utilizan de diferentes formas por las diferentes organizaciones y con distintos puntos de vista y objetivos, es preciso comprender los procesos, las organizaciones y sus relaciones bajo diferentes puntos de vista:

• Contrato: El comprador y el proveedor negocian y firman el contrato, empleando los procesos de adquisición y suministro.
• Gestión o dirección: El comprador, el proveedor, el desarrollador, el operador y el personal de mantenimiento gestionan sus respectivos procesos en el proyecto software.
• Explotación: El operador proporciona el servicio de explotación del software a los usuarios.
• Ingeniería: El desarrollador o el personal de mantenimiento llevan a cabo sus respectivas tareas de ingeniería para producir o modificar los productos de software.
• Soporte: Los grupos de soporte (el de gestión de la configuración, el de aseguramiento de la calidad, el de auditoria, etc) proporcionan servicios de apoyo a otros grupos en el cumplimiento de tareas únicas y específicas.

Clasificación de los modelos de ciclo de vida

Existen distintos modelos de ciclo de vida o lo que es lo mismo distintas pautas a seguir en el desarrollo de los Sistemas de Información. Naturalmente si se trata de proyectos sencillos en organizaciones pequeñas no es precisa la formalización del sistema. Sin embargo en organizaciones grandes o para proyectos complejos es imprescindible establecer un modo de hacer común. Una posible clasificación sería la que divide los modelos de ciclo de vida en:

• Modelos tradicionales: Son los de más amplia utilización. Dentro de este grupo estarían:
  
  
  • Modelo en cascada.
  • Modelos basados en prototipos:
    
    • Modelo de construcción de prototipos.
    • Modelo de desarrollo incremental.
    • Modelo de prototipado evolutivo.
• Modelos alternativos
  
  • Modelo en espiral
  • Modelos basados en transformaciones
    
    • Las que usan técnicas de cuarta generación (Roger Pressman): Suelen estar basados en herramientas de cuarta generación (lenguajes no procedimentales para consultas a BD; generadores de código, de pantallas, de informes; herramientas de manipulación de datos; facilidades gráficas de alto nivel)
    • Basados en modelos de transformación (Carma McClure) . Basados en herramientas CASE que permiten, siguiendo el MCV clásico, pasar de una etapa a otra aplicando las transformaciones que dan las herramientas.

En ambos casos, la filosofía general es llegar a generar código a partir de unas especificaciones transformándolas por medio de herramientas. La diferencia entre uno y otro es el uso de unas u otras herramientas.

Aparte de estos modelos de ciclo de vida en la actualidad existen nuevas alternativas:

• Proceso unificado de desarrollo del software de Rational (RUP).
• modelo basado en Desarrollo de Software Basado en Componentes (DSBC o CBSB).
• modelo de la Programación Extrema (eXtreme Programmming).

En la práctica, en la construcción de un Sistema de Información no se suelen seguir los modelos en su forma pura sino que de acuerdo con las peculiaridades del sistema y de la experiencia del jefe del proyecto, se pueden adoptar aspectos de otros modelos que sean más adecuados al caso concreto. Esto es así porque no existe un modelo mejor que los demás, cada uno tiene sus ventajas e inconvenientes.

La ausencia de modelo: el modelo CODE-AND-FIX.

El MODELO CODE-AND-FIX. Es el modelo básico usado en los primeros tiempos del desarrollo del software y se componía de dos pasos:

1. Escribir algún código o programa (CODE).
2. Resolver los problemas en el código (FIX).

Code and fix: No siempre el mejor camino es el más corto. (Proverbio chino).

Dice Steve McConnell en su libro "Desarrollo y gestión de proyectos informáticos" que codificar y corregir (code-and-fix) es un modelo poco útil pero bastante común. Para McConnell code-and-fix es un modelo no formal que se utiliza normalmente porque es simple, pero no porque funcione bien. Puede ser efectivo para proyectos de pequeño tamaño (literalmente para "proyectos pequeños que se intentan liquidar poco después de ser construidos", de hecho "resulta peligroso para otro tipo de proyectos que no sean pequeños"), pero nada más.

Ante esto, y considerando los proyectos como pequeños y con plazo de entrega para ayer, ¿no es mejor comenzar a codificar cuanto antes?. McConnell presenta este revelador ejemplo de que no es así:

Larry Constantine cuenta una historia sobre el concurso de Software de la Australian Computer Society (Constantine, 1995b). El concurso consistió en llamar a equipos formados por tres personas para desarrollar y entregar una aplicación de 200 puntos de función en 6 horas. El equipo de Ernst y Young decidió seguir una metodología de desarrollo formal, una versión reducida de la metodología que acostumbraban a seguir; completa con actividades por etapas y entregas intermedias. Su propuesta incluyó un cuidadoso análisis y diseño, empleando técnicas metodológicas. Muchos de sus competidores se metieron de lleno en la codificación, y en las primeras horas, el equipo de Ernst y Young se quedó atrás. Sin embargo, al mediodía el equipo de Ernst y Young era el equipo dominante. Al terminar el día, este equipo perdió, pero no fue debido a su metodología formal. Perdieron porque sobreescribieron accidentalmente alguno de los archivos, entregando menos funciones al final del día de las que habían demostrado que tenían a la hora del almuerzo. Reaparecieron unos meses más tarde en otro concurso de desarrollo rápido (esta vez con control de versiones y haciendo copias de seguridad) y ganaron (Constantine, 1996).

Este no-modelo tiene tres dificultades principales:

• Después de un número de ajustes, el código se hace tan poco estructurado que los siguientes ajustes se convierten en muy costosos. Esto hizo ver la necesidad de una fase previa de diseño antes de la de codificación.
• Frecuentemente, incluso con el software bien diseñado, se ajustaba poco a las necesidades de los usuarios. Esto condujo a la necesidad de introducir una fase de análisis de requerimientos antes del diseño.
• El ajuste del código (programa) era caro debido a su poca preparación para ser validado y modificado. Este problema hizo resaltar la necesidad de la planificación y preparación de las distintas tareas en cada fase.

El modelo por etapas (Stage-Wise) y el modelo en cascada (Waterfall)

Las dificultades del método CODE-AND-FIX condujeron, ya en el año 1956, al convencimiento de la necesidad de realizar el desarrollo de software en un modelo por etapas (STAGEWISE). En este modelo el software debe desarrollarse en etapas sucesivas (planificación, especificaciones de operación, especificaciones de codificación, codificación, prueba de cada unidad, prueba de integración, eliminación de problemas, evaluación del sistema.

El modelo en cascada (WATERFALL) es una mejora del modelo anterior y ha tenido desde los años 70 un papel fundamental en el desarrollo de proyectos software, tanto es así que se le conoce también como modelo clásico del ciclo de vida del desarrollo de software. Fue enunciado por ROYCE en 1970 y las dos mejoras sustanciales que introdujo en el modelo STAGE-WISE son las siguientes:

1. Considera la realización de bucles de realimentación entre etapas, permitiendo la resolución de problemas detectados en una etapa, en la etapa anterior. Con el fin de eliminar bucles de vuelta excesivamente largos que repercutirían en una carga excesiva de trabajo en el proceso, sólo admite vueltas a la etapa anterior.
2. Una incorporación inicial del prototipado en el ciclo de vida del software. Los prototipos se utilizan para captar especificaciones durante el análisis, o para probar posibles soluciones durante el diseño pero, generalmente, una vez cumplida su misión se deben desechar, procediéndose a una especificación formal.

El modelo en cascada ayudó a eliminar muchas dificultades previamente encontradas en proyectos de desarrollo de software. Algunas de sus dificultades iniciales han sido subsanadas en sucesivas extensiones del modelo que permite considerar desarrollos paralelos, familias de programas, acomodación de cambios evolutivos, desarrollo y verificación formal del software, validación por etapas y análisis de riesgos.

Sin embargo, incluso con profundas revisiones y mejoras, el esquema básico del modelo en cascada ha seguido presentando algunas dificultades fundamentales, lo que ha llevado a buscar modelos alternativos.

Una dificultad principal del modelo en cascada es su énfasis en documentos totalmente elaborados como criterio de terminación de las distintas fases de análisis de requerimientos y diseño. Para algunos tipos de software, como compiladores o sistemas operativos, esta forma de proceder es la más efectiva. Sin embargo no es la más adecuada para otros tipos de software como, particularmente, el que se usa en las aplicaciones interactivas y de usuario final. Esta exigencia de rellenar documentos estándares ha conducido, en muchos proyectos, a escribir detalladas especificaciones para interfaces de usuario pobremente comprendidas y al desarrollo de grandes cantidades de código no utilizable.

Según este modelo tendríamos las siguientes fases en el ciclo de vida de un proyecto:

1. Análisis: Consiste en la recopilación de los requisitos del software. Se debe comprender el ámbito de información del software así como la función, el rendimiento y las interfaces requeridas. Estos requisitos se deben documentar y revisar de tal manera que los entiendan tanto los usuarios como el equipo de desarrollo del software. En esta fase se desarrollará el documento de requisitos del software que consistirá en una especificación precisa y completa de lo que debe hacer el sistema.
2. Diseño: Consiste en descomponer y organizar el sistema en elementos componentes que puedan ser desarrollados por separado. El resultado del diseño es la colección de especificaciones de cada elemento componente. En esta fase se desarrollará el Documento del diseño del Software que será una descripción del estructura global del sistema.
3. Codificación: En esta fase se traduce el diseño a un lenguaje legible para el computador. También se harán las pruebas o ensayos necesarios para garantizar que dicho código funciona correctamente. La documentación de esta fase será el Código fuente.
4. Integración: Consiste en probar el sistema completo para garantizar el funcionamiento correcto del conjunto antes de ser puesto en explotación. Aquí tendremos el Sistema Software ejecutable.
5. Mantenimiento: Puede ocurrir que durante la explotación del sistema sea necesario realizar cambios para corregir errores que no han sido detectados en las fases anteriores o bien para introducir mejoras. Tendremos que hacer un Documento de cambios ante cualquier modificación. En todas estas fases la verificación y validación se han de tener en cuenta. La verificación consiste en comprobar que el software que se está desarrollando cumple los requisitos y la validación lo que hace es comprobar que las funciones del software son las que el usuario desea.

El modelo en cascada trata de aislar cada fase de la siguiente de manera que las fases sucesivas puedan ser desarrolladas por grupos de personas distintas facilitándose así la especialización. El número de fases es irrelevante, lo que caracteriza verdaderamente a este modelo es la secuencialidad entre las fases y la necesidad de completar cada una de ellas para pasar a la siguiente. El sistema está terminado

cuando se han realizado todas las fases.

El modelo en cascada ayudó a eliminar muchos de los problemas que se planteaban antes de su utilización, además ha sido la base para la normalización y la adopción de estándares. A medida que ha sido utilizado se han detectado en él debilidades e inconsistencias que se han intentado corregir con diversas modificaciones y/o extensiones al modelo.

Críticas al modelo en cascada

Las principales críticas al modelo se centran en sus características básicas, es decir secuencialidad y utilización de los resultados de una fase para acometer la siguiente de manera que el sistema sólo se puede validar cuando está terminado.

Flujo secuencial.

Los proyectos reales raramente siguen el flujo secuencias que propone el modelo. Siempre ocurren interacciones y en las últimas fases sobre todo se pueden realizar en paralelo algunas áreas como por ejemplo codificación y pruebas. Una aplicación del modelo en sentido estricto obligaría a la “congelación” de los requisitos de los usuarios, supuesto este completamente alejado de la realidad. El modelo no contempla la posibilidad de realimentación entre fases.

Resultados totales

El modelo en su formulación pura no prevé revisiones o validaciones intermedias por parte del usuario, así los resultados de los trabajos sólo se ven al final de una serie de tareas y fases de tal forma que si se ha producido un error en las primeras fases este sólo se detectará al final y su corrección tendrá un costo muy elevado, puesto que será preciso rehacer todo el trabajo desde el principio. El modelo no dispone de resultados parciales que permitan validar si el sistema cumple con los requisitos desde las primeras fases, dándose el caso de sistemas perfectamente formalizados y documentados que no cumplen los requisitos del usuario.

Modelos de ciclo de vida basados en prototipos

Estos modelos fueron creados para solventar las diferencias percibidas en los modelos clásicos. Permiten a los desarrolladores construir rápidamente versiones tempranas de los sistemas software que pueden evaluar los usuarios.

No resulta económico generar documentación durante las fases iterativas de la construcción del prototipo. Existen varios modelos derivados del uso de prototipos:

• Prototipos rápidos, también llamados maquetas
• Prototipos evolutivos
• Prototipado incremental

Prototipado Rápido

Los prototipos deben poder construirse con facilidad para evaluarlos en una temprana fase del desarrollo y además han de ser baratos. Otra de las características es que deben ser desarrollados en poco tiempo. También se denominan de usar y tirar.

Tienen como finalidad la de adquirir experiencia sin pretender emplearlos como productos. Una vez aceptado, el prototipo se desecha y se comienza el desarrollo desde cero, ya que generalmente el prototipo se ha construido tomando decisiones de implementación contrarias al buen criterio de desarrollo de software. El prototipo sirve para crear y validar la especificación, y para que el usuario tenga una idea de cómo será el softwareantes de que comience el desarrollo. Posteriormente se convierte en un modelo en cascada. El prototipo puede ser un

simple dibujo en papel. Los objetivos del prototipo son:

• Reducir el riesgo de construir un producto que se aleje de las necesidades del usuario
• Reducir el coste de desarrollo al disminuir las correcciones en etapas avanzadas del mismo.
• Aumentar las posibilidades de éxito del producto.

Prototipado Evolutivo

Fue enunciado por James Martin. En el se construye una implementación parcial del sistema que satisface los requisitos conocidos, la cual es empleada por el usuario para comprender mejor la totalidad de requisitos que desea. Responde al enunciado “no sé qué quiero, pero cuando vea algo te lo digo”.

Estos modelos se encaminan a conseguir un sistema flexible que se pueda expandir de forma que sea posible realizar rápidamente un nuevo sistema cuando los requisitos cambian. Están especialmente indicados en situaciones en la que se trabaja con lenguajes de 4ª generación (4GL) y cuando el usuario no sabe lo que quiere. En este modelo se asume que los requisitos desde el principio van a cambiar continuamente, además lo lógico es comenzar con los aspectos que mejor se comprendan puesto que solo se conocerán unos pocos requisitos y los restantes se tienen que ir descubriendo en sucesivas evoluciones del prototipo; cada versión que se desarrolle será una nueva versión de todo el sistema. Está relacionado con el concepto de RAD (Rapid Application Development – Desarrollo Rápido de Aplicaciones), que identifica los asistentes, plantillas y entornos de fácil y rápida creación de software (Access, Visual Basic, etc.)

Para poder evolucionar el prototipo sin desecharlo es necesario hacer uso de la reutilización, por tanto está fuertemente relacionado con técnicas de desarrollo que contemplen reutilización (Orientación a Objetos, por ejemplo).

El modelo de prototipado o desarrollo evolutivo (Evolutionary Development model) también tiene sus dificultades. Se le puede considerar como una nueva versión, utilizando lenguajes de programación de más alto nivel, del viejo modelo CODE-AND-FIX. Otro inconveniente que presenta es partir de la suposición, muchas veces no realista, de que el sistema operacional del usuario final será lo suficientemente flexible como para poder incorporar caminos de evolución futuros no planificados con anterioridad.

Prototipado Incremental

Incorpora conceptos del modelo en Cascada y del de Prototipos. El proyecto se desarrolla en capas. Partiendo de un modelo en cascada se crea una primera versión, cuya funcionalidad se va ampliando a medida la especificación crece. La gran diferencia respecto al modelo evolutivo es que los requisitos sí se conocen en su totalidad, pero su implementación se va dosificando deliberadamente.

Ventajas e inconvenientes de los modelos basados en prototipos

Las ventajas de los modelos basados en prototipos son:

• Los requisitos de los usuarios son más fáciles de determinar y la implantación del sistema será más sencilla debido a que los usuarios conocen lo que esperan.
• Los sistemas se desarrollan más rápidamente
• Este paradigma facilita la comunicación con los usuarios mejorándose dicha comunicación entre el analista y el usuario.

Adolecen de los siguientes problemas:

• Puede crear falsas expectativas en el usuario ya que puede ver el prototipo como si fuera el producto final
• Puede darse una fuerte intromisión de los usuarios finales en la integración
• Se producen inconsistencias entre el prototipo y el sistema final
• Para todo tipo de prototipado cabe decir que no es un paradigma apto para proyectos grandes y de larga duración ni para aplicaciones pequeñas (menos de un mes), siendo óptimo en aplicaciones y proyectos cuya duración esté fijada entre 3 y 5 meses.

El modelo de ciclo de vida en espiral

Como alternativa a los modelos de ciclo de vida tradicionales se encuentra este modelo que fue propuesto por Böehm para solventar los principales problemas que presentaban aquellos. Puede considerarse como un refinamiento del modelo evolutivo general. Este modelo se caracteriza principalmente porque incorpora un nuevo elemento: el análisis de riesgos. Las principales diferencias entre este modelo y los anteriores son:

• En este modelo hay un reconocimiento explícito de las diferentes alternativas para alcanzar los objetivos del proyecto.
• Se centra en la identificación de los riesgos asociados a cada alternativa y en la manera de resolver dichos riesgos.
• Los proyectos se dividen en ciclos (ciclos de la espiral) avanzándose en el desarrollo mediante consensos al final de cada ciclo.
• Se adapta a cualquier tipo de actividad.

Es el modelo de ciclo de vida más versátil y flexible, pero también el más complejo. Cada vuelta de la espiral (ciclo) supone una refinación en el desarrollo. Cada ciclo comprende la realización de las siguientes fases:

1. Planificación. Se definen los objetivos de la fase o ciclo, así como todos los condicionantes para el cumplimiento de los mismos (restricciones de coste, tiempo, etc.) y las posibles alternativas.
2. Análisis de riesgos. Se evalúa el riesgo de cada alternativa y se elige la apropiada.
3. Ingeniería. Se construye el producto.
4. Evaluación. Se valida con el cliente si lo producido es lo adecuado. Se revisan los planes para el próximo ciclo.

La fase de Ingeniería puede desarrollarse siguiendo cualquiera de los modelos de ciclo de vida vistos anteriormente (se dice que el modelo en espiral incluye los anteriores modelos).

En la gráfica que representa la evolución del ciclo de vida según el modelo en espiral, la dimensión radial nos permite medir el coste de la ejecución del proyecto, mientras que la dimensión angular representa el avance en su ejecución.

Ventajas del modelo en espiral.

La ventaja principal del modelo en espiral es que su rango de opciones acomoda las buenas características de los demás modelos de desarrollo de software, mientras su procedimiento dirigido por el riesgo, evita muchas de sus dificultades. En situaciones apropiadas, el modelo en espiral es equivalente a uno de los modelos de proceso existentes. En otras situaciones, guía la elaboración de una mezcla adecuada de procedimientos existentes para un proyecto dado.

Las condiciones bajo las cuales el modelo en espiral llega a ser equivalente a otros modelos de desarrollo de software destacados se pueden resumir como sigue:

• Si un proyecto tiene un riesgo bajo en áreas tales como el establecimiento de una interfaz de usuario no adecuada o en el cumplimiento de requerimientos rigurosos de ejecución y si, por el contrario, tiene un alto riesgo en la predicción y control del presupuesto y del calendario de elaboración, entonces. Estas consideraciones conducen el modelo en espiral a uno equivalente al modelo en cascada.
• Si los requerimientos de productos software son muy estables (implicando un bajo riesgo de diseño y fragmentación de código debido a los cambios de requerimientos durante el desarrollo) y si la presencia de errores en el producto software constituye un alto riesgo para la operación a la que se aplica, entonces, estas consideraciones sobre el riesgo conducen al modelo en espiral a asemejarse al modelo TWO-LEG de especificación precisa y desarrollo de programas formal deductivo.
• Si un proyecto tiene un bajo riesgo en áreas tales como pérdidas en el presupuesto y predicción y control de calendario, encontrándose con problemas de integración de grandes sistemas, o enfrentarse con esclerosis en la información y si hay un alto riesgo de producir una interface de usuario equivocada o de obtener unos requerimientos de soporte a las decisiones del usuario equivocados, entonces, estas consideraciones de riesgo conducen al modelo en espiral a ser equivalente al modelo de desarrollo evolutivo.
• Si se dispone de capacidades de generación de software automatizado, entonces, el modelo en espiral acomoda bien al desarrollo de prototipado rápido o a la aplicación del modelo de transformación dependiendo de las consideraciones de riesgo implicadas.
• Si los elementos de alto riesgo de un proyecto implican una mezcla de items de riesgo citado anteriormente, entonces, el procedimiento en espiral reflejará una mezcla de los modelos de proceso anteriores. Haciendo esto, sus características de eliminación de riesgos generalmente evitarán dificultades de otros modelos.

Otras ventajas adicionales del modelo en espiral son:

• Concentra su atención en opciones que consideran la reutilizacíón de software existente. Los pasos implicados en la identificación y evaluación de alternativas potencian estas opciones.
• Permite preparar la evolución del ciclo de vida, crecimiento y cambios del producto software.
• Proporciona un mecanismo de incorporación de objetivos de calidad en el desarrollo de producto software. Este mecanismo se deriva del énfasis puesto en la identificación de todos los objetivos restricciones durante cada uno de los círculos de la espiral.
• Es especialmente adecuado para la temprana eliminación de errores y alternativas poco atractivas. Los pasos de análisis de riesgo, validación y aceptación de compromisos cubren estas consideraciones. Para cada una de las fuentes de actividad del proyecto y gasto de recursos, se hace la pregunta claves ¿cuánto es suficiente?; dicho de otra forma: ¿cuántos requerimientos de análisis, planificación, gestión de la configuración, garantía de calidad, pruebas, verificaciones formales, etc. debería incluir el proyecto? Utilizando el procedimiento dirigido por el riesgo uno puede ver que la respuesta no es la misma para todos los proyectos y que el nivel apropiado de esfuerzo viene determinado por el nivel de riesgo incurrido por no hacer lo suficiente.
• No implica procedimientos separados para el desarrollo del software y la mejora del mismo (o mantenimiento). Este aspecto evita la frecuente consideración residual atribuida al mantenimiento del software. También ayuda a evitar muchos de los problemas que actualmente sobrevienen cuando se abordan mejoras de alto riesgo como si fuesen esfuerzos rutinarios de mantenimiento.
• Proporciona un marco viable para integrar los desarrollos de sistemas software-hardware. El centrar la atención en la gestión del riesgo y en la eliminación de alternativas no atractivas lo antes posible y con el menor coste es, igualmente, aplicable al software y al hardware.

El modelo en espiral se adapta al diseño y programación orientada a objetos (Booch, 1991), y posiblemente con estos métodos es cuando permite obtener mejores resultados: el modelo en espiral potencia la utilización de desarrollos incrementales, y cuando sea necesario, la reelaboración de partes ya desarrollados. la abstracción, encapsulación, modularidad y jerarquización, elementos fundamentales de los métodos orientados a objeto, permiten realizar fácilmente los desarrollos incrementales y hacer menos traumáticas las reelaboraciones.

Dificultades del modelo en espiral

El modelo en espiral completo puede aplicarse con éxito en muchas situaciones, pero es necesario tener en cuenta algunas dificultades antes de que pueda considerarse como un modelo maduro, aplicable de forma universal. Los tres primeros retos con que se enfrenta son:

• ajustar su aplicabilidad para el caso de software contratado, con lo que ello implica (cerrar de antemano el alcance y los requisitos funcionales qeu debe cubrir el software, y ajustarse a unos plazos de entrega predeterminados).
• depender en exceso de la experiencia en la evaluación de riesgos y la necesidad de una elaboración adicional de los pasos del modelo en espiral.

Adaptar su aplicabilidad al software contratado.

El modelo en espiral actualmente trabaja bien en desarrollos de software internos pero necesita un trabajo adicional para adaptarlo al mundo de los contratos de adquisición del software. Los desarrollos internos de software tienen bastante flexibilidad y libertad para acomodarse a confirmaciones etapa por etapa; para diferir confirmaciones a determinadas opciones; para establecer miniespirales con las que resolver caminos críticos; para ajustar niveles de esfuerzo, o para acomodar prácticas tales como el prototipado, el desarrollo evolutivo o

diseño a coste. En el mundo de la adquisición de software es muy difícil conseguir estos grados de flexibilidad y libertad sin perder responsabilidad y control y es muy difícil definir contratos que no especifiquen por adelantado los productos a obtener.

Recientemente, se ha progresado en el establecimiento de mecanismos de contratación más flexibles pero todavía se necesitan mejoras para conseguir que los compradores se sientan completamente cómodos utilizándolos.

Dependencia de la experiencia en la evaluación de riesgos

El modelo en espiral da un papel relevante a la habilidad de los desarrolladores de software para identificar y gestionar las fuentes de riesgo del proyecto. Un buen ejemplo de esto es la especificación dirigida por el riesgo en el modelo en espiral. En ella se debe llegar a un alto nivel de detalle en los elementos de alto riesgo dejando, los de bajo riesgo, para una elaboración en etapas posteriores. Un equipo de desarrolladores inexpertos o de bajo nivel pueden producir una especificación con un patrón diferente en los niveles de detalle: una gran elaboración en cuanto al detalle para los elementos de bajo riesgo y pequeña elaboración de elementos mal comprendidos, con alto riesgo. A menos que se realice una revisión de tales especificaciones por desarrolladores expertos, este tipo de proyectos ofrecerá inicialmente la ilusión de progreso durante un período, cuando en realidad el proyecto está condenado al desastre.

Otra preocupación es que la especificación será, en exceso, dependiente de las personas. Por ejemplo, un diseño producido por un experto puede ser implementado por no expertos; en este caso, el experto que no necesita mucha documentación detallada, debe producir suficiente documentación adicional para que los no expertos no se extravíen. Con una aproximación convencional, dirigida por la documentación, el requerimiento de llevar todos los aspectos de la especificación a un nivel uniforme de detalle elimina algunos problemas potenciales y permite una adecuada revisión de algunos aspectos por revisores inexpertos. No obstante, esto produce pérdidas de tiempo a los expertos que deben

buscar los aspectos críticos en medio de un gran volumen de detalles no críticos. Por otra parte, si los elementos de alto riesgo se han presentado por medio de rimbombantes referencias a funcionalidades mal entendidas, como un nuevo concepto de sincronización o un nuevo DBMS comercial, existe un riesgo, aún mayor, de que el enfoque tradicional conduzca al fracaso.

Los esfuerzos para aplicar y refinar el modelo de espiral se han centrado en la creación de una disciplina de gestión del riesgo del software, incluyendo técnicas de identificación del riesgo, análisis de riesgo, priorización del riesgo, planteamiento de gestión del riesgo, y búsqueda de elementos de riesgo.

El Plan de Gestión del Riesgo.

Incluso si una organización no está lista para adoptar el procedimiento completo de espiral, una característica técnica del mismo que puede ser fácilmente adaptada a cualquier modelo de ciclo de vida proporciona muchos de los beneficios de dicho procedimiento. Se trata del Plan de Gestión del Riesgo. Este plan, básicamente, asegura que en cada proyecto se haga una identificación temprana de sus items de riesgo más altos; desarrolla una estrategia para resolver los items de riesgo; identifica y establece una agenda para resolver nuevos items de riesgo a medida que afloran y, por último, muestra los progresos respecto al plan en revisiones mensuales.

El plan de gestión de riesgo y las técnicas para gestión de riesgo de Software proporcionan un fundamento para adaptar los conceptos del modelo en espiral a los procedimientos de adquisición y desarrollo de software más asentados.

Se pueden sacar las siguientes cuatro conclusiones:

1. El modelo en espiral, por su naturaleza de estar dirigido por el riesgo, es más adaptable a un amplio rango de situaciones que los procedimientos dirigidos por la documentación, tales como el modelo en cascada o los procedimientos dirigidos por el código, tales como el modelo de desarrollo evolutivo. Es particularmente aplicable a sistemas de software muy grandes y complejos.
2. El modelo en espiral ha tenido éxito en su mayor aplicación realizada hasta ahora: el desarrollo del TRW- SPS. Sobre todo permite alcanzar un alto nivel de capacidades ambientales de soporte del software en un corto plazo y proporciona la flexibilidad necesaria para acomodar un rango de alternativas técnicas y objetivos de usuario muy dinámico.
3. El modelo en espiral no está, todavía, tan completamente elaborado como los modelos más establecidos. Por esta razón, el modelo en espiral puede ser aplicado por personal experto, pero necesita elaboración posterior en áreas tales como contratación, especificaciones, puntos de control, revisiones, calendarios e identificación de áreas de riesgo para ser completamente aplicable en todas las situaciones.
4. Algunas implementaciones parciales del modelo en espiral como el Plan de Gestión del Riesgo, son compatibles con la mayoría de los modelos de proceso actuales y son muy útiles para superar las mayores fuentes de riesgo de proyectos.

TODO: Modelos basados en transformación, RUP (proceso unificado), FUDS, metodologías agiles, programación extrema, etc

Bibliografía.

• Steve McConnell, "Desarrollo y gestión de proyectos informáticos". 1996
• Grady Booch, James Rumbaugh, Ivar Jacobson. "El lenguaje unificado de modelado". Ed.: Addison Wesley

Si te ha gustado esta entrada, suscríbete para recibir las próximas entradas por correo electrónico. Por favor, apoya este blog.