viernes, 26 de septiembre de 2008

Acerca de - Integrantes

  • Conde Brito Karina

  • Nava Leydi

  • Rojas Vera Martha Eugenia

jueves, 25 de septiembre de 2008

Ciclos de Vida - Bibliografía

Libros

• Roger S. Pressman. Ingenieria del Software. Ed. McGrawhill
• Henry F. Korth. Analisis y Diseño de Sistemas. Ed. McGrawhill
• Jeffrey L. Whitten. Analisis y Diseño de Sistemas de Información. Ed. Irwin.
• Steve MacConell. Desarrollo y Gestion de Proyectos Informaticos. Ed. McGrawhill

Direcciones Web

http://www.mancomunitatplademallorca.net/wms/ofo/imgdb//archivo_adj17144622.pdf
http://www.ra-ma.es/cf/html/catalogo/libros/down/adaigGS.pdf
http://img.redusers.com/imagenes/libros/lpcu097/capitulogratis.pdf
http://inge.uasnet.mx/pagina_web/areas_acad/prog_compu/Ciclo%20de%20vida%20del%20desarrollo%20del%20software.pdf

Ciclos de Vida - Conclusiones


Luego de ver algunos de los modelos de ciclo de vida más utilizados surge la pregunta con la respuesta más codiciada: ¿qué modelo de ciclo de vida elegir? Sabemos que ninguno predomina sobre los otros. Por ello, debemos elegir el modelo que mejor se adapte al proyecto que desarrollaremos. Podemos analizar, para guiarnos en nuestra elección, la complejidad del problema, el tiempo que disponemos para hacer la entrega final, o si el usuario o cliente desea entregas parciales, la comunicación que existe entre el equipo de desarrollo y el usuario y, por último, qué certeza (o incertidumbre) tenemos de que los requerimientos dados por el usuario son correctos y completos

Tal y como se ha visto en el apartado anterior cualquier modelo tiene ventajas e inconvenientes, con lo que, al comenzar un proyecto, habrá que examinar la situación actual para comprobar cuál es el modelo más adecuado al caso.

Una primera pauta para elegir el modelo de ciclo de vida es que, cuanto más lineal sea el modelo, más rápido será su desarrollo. Sin embargo, y en contrapartida, cuanto más lineal sea el modelo más completos deberán ser los requisitos antes del comienzo del proyecto.
Algunas cuestiones que pueden plantearse para elegir entre los distintos modelos de ciclo de vida son las siguientes:

• ¿Existe la posibilidad de que el entendimiento entre las partes cambie significativamente a medida que avance el proyecto? Si puede cambiar ese entendimiento, es decir, si los requisitos pueden cambiar, es recomendable optar por modelos que incluyan la realización de prototipos o el desarrollo evolutivo, de forma que se puedan acometer de forma cómoda los cambios del programa debidos a nuevos requisitos.

• ¿Se comprende bien toda la arquitectura del sistema al comenzar el proyecto? Si la arquitectura es estable desde el principio, puede optarse por modelos de ciclo de vida lineales en las fases de diseño y codificación. En caso contrario deberá optarse por modelos que realicen varias iteraciones en esas fases.

• ¿Cuánta fiabilidad se necesita? Si se necesita un alto grado de fiabilidad entonces será necesario acudir a modelos de ciclo de vida basados en la especificación formal de requisitos. En estos modelos se dedica una gran cantidad de tiempo a especificar de forma correcta el programa, que luego se construye derivando una implementación a partir de esa especificación mediante métodos que garantizan la corrección de lo que se produce.

• ¿Cuánto tiempo extra se necesita para planificar y diseñar durante el proyecto para posibles versiones futuras? Cuando se desea crear componentes reutilizables para futuras versiones del mismo programa, o bien para futuros programas que funcionen en el mismo entorno, es conveniente elegir modelos de ciclo de vida que pongan énfasis en la reutilización, como el modelo RAD.

• ¿Se está sometido a una planificación predefinida? En estos casos deberá elegirse el modelo que más se ajuste a esa planificación y que permita un desarrollo más controlado en riesgos, como el modelo en espiral.

• ¿Puede ser necesario realizar modificaciones a medio camino? Si es así deberá optarse por modelos de ciclo de vida basados en prototipos evolutivos o incrementales.

• ¿Debe proporcionarse a los clientes signos visibles de progreso durante el proyecto? En estos casos también se debe optar por modelos que permitan la construcción de prototipos incrementales.

• ¿Cuánta preparación y formación son necesarias para utilizar el modelo de ciclo de vida con éxito? En muchas ocasiones la selección del ciclo de vida viene impuesta por los conocimientos del personal del equipo de desarrollo. Si el elegir un modelo exige un largo periodo de entrenamiento, puede ser recomendable elegir otro modelo de ciclo de vida menos eficiente pero que ya conozcan los desarrolladores.

Ciclos de Vida - Ventajas/Desventajas

Cada modelo de los existentes presenta sus ventajas e inconvenientes según el tipo de desarrollo que se quiera realizar y dependiendo de multitud de factores, puede resultar más adecuado utilizar uno y otro. Seguidamente, se van a resumir las principales características de los modelos de ciclo de vida más importantes:

Modelo “codificar y corregir”
Ventajas:

• Permite una construcción rápida del sistema
• Es útil para sistemas de un tamaño muy reducido, que no requiera más de dos o tres programadores y que no requiera un mantenimiento posterior
• No pierde tiempo en las etapas de planificación, documentación, control de calidad...
• Cualquiera, sin preparación técnica, lo puede utilizar

Desventajas:

• Carece de cualquier control y gestión del proceso
• No dispone de las fases necesarias en todo proyecto de software: especificaciones, diseño...
• Se dificulta la corrección de errores y el mantenimiento al carecer de una documentación del proceso adecuada
• No proporciona medios de evaluación ni de prevención de riesgos
• Resulta peligroso para proyectos grandes

Modelo en “cascada”

Ventajas:

• Es un modelo sencillo y disciplinado
• Es fácil aprender a utilizarlo y comprender su funcionamiento
• Está dirigido por los tipos de documentos y resultados que deben obtenerse al final de cada etapa
• Ha sido muy usado y, por tanto, está ampliamente contrastado
• Ayuda a detectar errores en las primeras etapas a bajo costo
• Ayuda a minimizar los gastos de planificación, pues se realiza sin problemas

Desventajas:

• Los proyectos raramente siguen el proceso lineal tal como se definía originalmente el ciclo de vida
• Es difícil que el cliente exponga explícitamente todos los requisitos al principio
• El cliente debe tener paciencia pues obtendrá el producto al final del ciclo de vida
• No refleja exactamente cómo se programa realmente el sistema, en el que suele haber un gran componente iterativo
• Puede resultar complicado regresar a etapas anteriores (ya acabadas) para realizar correcciones
• El producto final obtenido puede que no refleje todos los requisitos del usuario

Modelo en “V”

Ventajas:

• La relación entre las etapas de desarrollo y los distintos tipos de pruebas facilitan la localización de fallos
• Es un modelo sencillo y de fácil aprendizaje
• Hace explícito parte de la iteración y trabajo que hay que revisar

• Especifica bien los roles de los distintos tipos de pruebas a realizar
• Involucra al usuario en las pruebas

Desventajas:

• Es difícil que el cliente exponga explícitamente todos los requisitos
• El cliente debe tener paciencia pues obtendrá el producto al final del ciclo de vida
• Las pruebas pueden ser caras y, a veces, no lo suficientemente efectivas
• El producto final obtenido puede que no refleje todos los requisitos del usuario

“Prototipos”

Ventajas:

• Permite la construcción del sistema con requisitos poco claros o cambiantes
• El cliente recibe una versión del sistema en muy poco tiempo, por lo que lo puede evaluar, probar e, incluso, empezar a utilizarlo
• Se pueden introducir cambios en las funcionalidades del sistema en cualquier momento
• Involucra al usuario en la evaluación de la interfaz de usuario
• Se reduce el riesgo y la incertidumbre sobre el desarrollo
• Genera signos visibles de progreso, que se utilizan cuando existe una demanda en la velocidad del desarrollo
• Permite entender bien el problema antes de la implementación final

Desventajas:

• El cliente puede quedar convencido con las primeras versiones y, quizás, no vea la necesidad de completar el sistema o rediseñarlo con la calidad necesaria
• Requiere trabajo del cliente para evaluar los distintos prototipos y traducirlo en nuevos requisitos
• Requiere un tiempo adicional para definir adecuadamente el sistema
• No se sabe exactamente cuánto será el tiempo de desarrollo ni cuantos prototipos se tienen que desarrollar
• Si un prototipo fracasa, el coste del proyecto puede resultar muy caro

“Desarrollo Rápido de Aplicaciones”

Ventajas:

• Enfatiza ciclos de desarrollo extremadamente cortos
• Tiene las ventajas del modelo clásico
• Se asegura de que el producto entregado cumple las necesidades del cliente

Desventajas:

• Solo se puede aplicar si el sistema se puede modularizar de forma que permita completarse cada una de las funciones principales en menos de tres meses
• Para proyectos grandes puede requerir muchos equipos de trabajo distintos
• Requiere clientes y desarrolladores comprometidos en las rápidas actividades necesarias

• No resulta adecuado cuando los riesgos técnicos son elevados
• Se pueden tener problemas con la aceptación del prototipo

Modelo en “espiral”

Ventajas:

• Incorpora muchas de las ventajas de los otros ciclos de vida
• Conjuga la naturaleza iterativa de los prototipos con los aspectos controlados y sistemáticos del modelo clásico
• Proporciona el potencial para el desarrollo rápido de versiones incrementales
• Puede adaptarse y aplicarse a lo largo de la vida del software
• Es un enfoque realista del desarrollo del software
• Permite aplicar el enfoque de construcción de prototipos en cualquier momento para reducir riesgos
• Reduce los riesgos antes de que se conviertan en problemáticos
• Controla muy bien los riesgos y mientras más iteraciones se realicen, menos riesgos habrá
• Monitoriza y controla los riesgos continuamente

Desventajas:

• Puede resultar difícil convencer a algunos clientes de que el enfoque evolutivo es controlable
• Solo resulta aplicable para proyectos de gran tamaño
• Supone una carga de trabajo adicional, no presente en otros ciclos de vida
• Requiere una considerable habilidad para la evaluación y resolución del riesgo, y se basa en esta habilidad para el éxito
• Si un riesgo importante no es descubierto y gestionado, indudablemente surgirán problemas
• Es bastante complicado de realizar y su complejidad puede incrementarse hasta hacerlo impracticable
• El modelo no se ha utilizado tanto como otros, por lo que tendrán que pasar años antes de que determine con certeza la eficacia de este modelo

Ciclos de Vida - Clasificación


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.



Figura 1 Ciclo de vida en cascada o clásico


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.



Figura 2 Ciclo de vida en cascada o clásico completo


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.



Figura 3 Modelo de Ciclo de Vida en V


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.



Figura 4 El modelo de Ciclo de Vida RAD


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.



Figura 5 Modelo en espiral


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).



Figura 6 Modelo de Ciclo de Vida de Especificación Operativa


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).



Figura 7 Modelo de Ciclo de Vida de Transformación

Ciclos de Vida - Historia/Antecedentes


Tradicionalmente el desarrollo de aplicaciones informáticas se llevaba a cabo de forma individualizada, a base de codificar (generar líneas de código) y probar lo realizado cuanto antes.

La misma persona escribía el código, lo ejecutaba y, si fallaba, lo depuraba. El proceso se realizaba sin ninguna planificación previa y sin que soliese existir documentación alguna.

Debido a que la movilidad en el trabajo era baja, los ejecutivos estaban seguros de que esa persona estaría allí cuando se produjese algún fallo.

En principio, el hecho de que desde un primer momento se vaya generando código, podría considerarse como un síntoma de enorme progreso, pero puede suponer posteriormente un gran retroceso e incluso la necesidad de desechar una gran parte de lo realizado en el caso de que existan errores y no se puedan llevar a cabo las modificaciones necesarias para subsanarlos (por ejemplo, si al 90% del código se descubre que el diseño de la base de datos es incorrecto, puede suponer desechar el trabajo y tener que comenzar de nuevo). Con este enfoque, cualquier cosa que no sea codificación pura y dura no se realiza (como, por ejemplo, actividades de planificación, de documentación, de aseguramiento de la calidad).

Esta forma de desarrollar aplicaciones es muy común en muchas organizaciones y, generalmente, se utiliza cuando no se elige o sigue un enfoque de desarrollo (ciclo de vida) concreto y/o apenas se realiza la actividad de planificación.

Además, otro factor que juega a favor de este enfoque de codificar y probar es que requiere poca experiencia y cualquier persona podrá fácilmente familiarizarse con él.

Esta forma de desarrollar software puede ser eficaz en programas pequeños.
Para otro tipo de proyectos, puede resultar peligrosa su utilización, ya que no se puede conocer el progreso del proyecto, ni tampoco su calidad, simplemente se está codificando y probando hasta que finaliza el proyecto. Otras maneras de realizar el desarrollo software, como se verán en los siguientes apartados, permitirán, por ejemplo, conocer el progreso, detectar un error lo antes posible, etc.

Por lo tanto, es probable que las aplicaciones realizadas según este enfoque de codificar y probar:

• Sean poco flexibles, y ante posibles modificaciones se incremente el coste de los proyectos e, incluso, en ocasiones, resulten virtualmente irrealizables debido a la naturaleza personalizada de los programas y a la falta de documentación (lo que provocará problemas de mantenimiento).

• Sean incompletas o no reflejen bien las necesidades del cliente, es decir, que no realicen todas las funciones requeridas y, además, lo hagan con una escasa fiabilidad.

• Provoquen el descontento de los clientes, pues se producen retrasos en la entrega (no se conoce el momento exacto en el que se entregarán), aparecen errores una vez que la aplicación ha sido entregada (lógico al no haberse realizado de forma sistemática actividades de verificación y validación en el proyecto).

Por tanto, es necesario que todo esfuerzo en el desarrollo del software conlleve
un enfoque lógico para su realización. Dicho enfoque debe abarcar toda la vida del sistema, comenzando con su concepción y finalizando cuando ya no se utiliza o se retira.

El ciclo de vida software es la descripción de las distintas formas de desarrollo
de un proyecto o aplicación informática, es decir, la orientación que debe seguirse para obtener, a partir de los requerimientos del cliente, sistemas que puedan ser utilizados por dicho cliente. También puede definirse como el conjunto de fases o etapas, procesos y actividades requeridas para ofertar, desarrollar, probar, integrar, explotar y mantener un producto software.

Ciclos de Vida - Descripción


• Ciclo de vida se refiere al período de tiempo que comienza cuando se concibe la idea de generar el programa hasta que finalmente se retira.

• Se denomina al conjunto de fases como ser: Todo proyecto de ingeniería tiene unos fines ligados a la obtención de un producto, proceso o servicio que es necesario generar a través de diversas actividades. Algunas de estas actividades pueden agruparse en fases porque globalmente contribuyen a obtener un producto intermedio, necesario para continuar hacia el producto final y facilitar la gestión del proyecto.

• Facilita el control sobre los tiempos en que es necesario aplicar recursos de todo tipo (personal, equipos, suministros, etc.) al proyecto. Si el proyecto incluye subcontratación de partes a otras organizaciones, el control del trabajo subcontratado se facilita en la medida en que esas partes encajen bien en la estructura de las fases. El control de calidad también se ve facilitado si la separación entre fases se hace corresponder con puntos en los que ésta deba verificarse (mediante comprobaciones sobre los productos parciales obtenidos).

• Es un conjunto ordenado de tareas como un proceso: una serie de pasos que incluye actividades, restricciones y recursos que producen un resultado de un determinado tipo.

Características

• El proceso describe todas las actividades principales.

• El proceso utiliza recursos que están sujetos a una serie de restricciones y genera productos intermedios y finales.

• El proceso puede descomponerse en subprocesos que están enlazados de una forma determinada e, incluso, se puede definir como una jerarquía de procesos, organizados de forma que cada subproceso tenga su propio modelo de proceso.

• Cada actividad del proceso tiene definidos criterios de entrada y salida, de forma que queda claramente especificado cuándo empieza y termina cada actividad.

• Las actividades de un proceso están organizadas en forma de secuencia, de forma que puede saberse cuándo se realiza una actividad en relación con el resto.

• Todo proceso incorpora un conjunto de principios básicos que explican los objetivos de cada actividad.

• Pueden existir restricciones o controles para las actividades, recursos o productos. Así, por ejemplo, el presupuesto o la planificación pueden restringir la cantidad de tiempo que se puede dedicar a una actividad o, por otro lado, una herramienta puede limitar la forma en la que se utiliza un recurso.

El ciclo de vida software da respuesta a las siguientes preguntas de la gestión de un proyecto de software:

¿Qué haré a continuación?
¿Cuánto tiempo continuaré haciéndolo?


El ciclo de vida que se seleccione en un proyecto influirá en el éxito del proyecto, y puede ayudar a asegurar que cada paso que se dé acorte más la consecución del objetivo.

Dependiendo del ciclo de vida que se seleccione, se puede aumentar la velocidad de desarrollo, mejorar la calidad, el control y el seguimiento del proyecto, minimizar gastos y riesgos, o mejorar las relaciones con los clientes. Una selección ineficaz puede ser una fuente constante de ralentización del trabajo, trabajo repetitivo, innecesario y frustrante.

Las funciones principales de un ciclo de vida software son:

• Determinar el orden de las fases y procesos involucrados en el desarrollo del software y su evolución, teniendo en cuenta el modelo de procesos que se utilice como referencia.

• Establecer los criterios de transición para pasar de una fase a la siguiente. Todo ello, incluye los criterios para la terminación de la fase actual y los criterios para seleccionar e iniciar la fase siguiente.