Presentación de ciclo de vida

CICLO DE VIDA DE UN SOFTWARE

TEMA: MODELOS DE CICLO DE VIDA DE UN SOFTWARE

Ciclo de vida de un software.

Por ciclo de vida, se entiende: La sucesión de etapas por las que pasa el software desde que un nuevo proyecto es concebido hasta que se deja de usar. Cada una de estas etapas lleva asociada una serie de tareas que deben realizarse, y una serie de documentos (en sentido amplio: software) que serán la salida de cada una de estas fases y servirán de entrada en la fase siguiente.

MODELOS DE CICLOS DE VIDA DE UN SOFTWARE

Existen diversos modelos de ciclo de vida, es decir, diversas formas de ver el proceso de desarrollo de software, y cada uno de ellos va asociado a un paradigma de la ingeniería del software, es decir, a una serie de métodos, herramientas y procedimientos que debemos usar a lo largo de un proyecto. Aquí veremos algunos de los principales modelos de ciclo de vida.

                                           MODELO CASCADA.

Es el enfoque metodológico que ordena rigurosamente las etapas del proceso para el desarrollo de software, de tal forma que el inicio de cada etapa debe esperar a la finalización de la etapa anterior.

De esta forma, cualquier error de diseño detectado en la etapa de prueba conduce necesariamente al rediseño y nueva programación del código afectado, aumentando los costos del desarrollo. La palabra cascada sugiere, mediante la metáfora de la fuerza de la gravedad, el esfuerzo necesario para introducir un cambio en las fases más avanzadas de un proyecto.

Análisis de requisitos.- En esta fase se analizan las necesidades de los usuarios finales del software para determinar qué objetivos debe cubrir. 

Diseño del Programa.- Es la fase en donde se realizan los algoritmos necesarios para el cumplimiento de los requerimientos del usuario así como también los análisis necesarios para saber que herramientas usar en la etapa de Codificación.

Codificación.-Es la fase en donde se implementa el código fuente, haciendo uso de prototipos así como de pruebas y ensayos para corregir errores.

Dependiendo del lenguaje de programación y su versión se crean las bibliotecas y componentes reutilizables dentro del mismo proyecto para hacer que la programación sea un proceso mucho más rápido.

Pruebas.- Los elementos, ya programados, se ensamblan para componer el sistema y se comprueba que funciona correctamente y que cumple con los requisitos, antes de ser entregado al usuario final.

Verificación.- Es la fase en donde el usuario final ejecuta el sistema, para ello el o los programadores ya realizaron exhaustivas pruebas para comprobar que el sistema no falle.

En la creación de desarrollo de cascada se implementa los códigos de investigación y pruebas del mismo.

Mantenimiento.- Una de las etapas más críticas, ya que se destina un 75% de los recursos, es el mantenimiento del Software ya que al utilizarlo como usuario final puede ser que no cumpla con todas nuestras expectativas.

MODELO PROTOTIPO.

 El prototipo debe ser construido en poco tiempo, usando los programas adecuados y no se debe utilizar muchos recursos.

La construcción de prototipos se puede utilizar como un modelo del proceso independiente, se emplea más comúnmente como una técnica susceptible de implementarse dentro del contexto de cualquiera de los modelos del proceso expuestos. Sin importar la forma en que éste se aplique, el paradigma de construcción de prototipos ayuda al desarrollador de software y al cliente a entender de mejor manera cuál será el resultado de la construcción cuando los requisitos estén satisfechos. De esta manera, este ciclo de vida en particular, involucra al cliente más profundamente para adquirir el producto.

Ventajas

·         Este modelo es útil cuando el cliente conoce los objetivos generales para el software, pero no identifica los requisitos detallados de entrada, procesamiento o salida.

·         También ofrece un mejor enfoque cuando el responsable del desarrollo del software está inseguro de la eficacia de un algoritmo, de la adaptabilidad de un sistema operativo o de la forma que debería tomar la interacción humano-máquina.

MODELO ESPIRAL

El desarrollo en espiral es un modelo de ciclo de vida utilizado generalmente en la Ingeniería de software. Las actividades de este modelo se conforman en una espiral, en la que cada bucle o iteración representa un conjunto de actividades. Las actividades no están fijadas a ninguna prioridad, sino que las siguientes se eligen en función del análisis de riesgo, comenzando por el bucle interior.

Ventajas

El análisis del riesgo se hace de forma explícita y clara. Une los mejores elementos de los restantes modelos.

·         Reduce riesgos del proyecto

·         Incorpora objetivos de calidad

·         Integra el desarrollo con el mantenimiento, etc.

Además es posible tener en cuenta mejoras y nuevos requerimientos sin romper con la metodología, ya que este ciclo de vida no es rígido ni estático.

Desventajas

·         Genera mucho tiempo en el desarrollo del sistema

·         Modelo costoso

·         Requiere experiencia en la identificación de riesgos

Este sistema es muy utilizado en proyectos grandes y complejos o EMPRESAS  como puede ser, por ejemplo, la creación de un Sistema Operativo.

Al ser un modelo de Ciclo de Vida orientado a la gestión de riesgo se dice que uno de los aspectos fundamentales de su éxito radica en que el equipo que lo aplique tenga la necesaria experiencia y habilidad para detectar y catalogar correctamente los riesgos.

Modelo Desarrollo orientado a Hitos"

En este ciclo de vida básicamente se trabaja secuencialmente en la base estable del producto que incluye llegar hasta el diseño de la arquitectura, pero a partir de ahí se trabaja en ciclos iterativos sobre el diseño detallado, codificación y pruebas. Los contenidos de estos ciclos se priorizan para optimizar según la relevancia de las funcionalidades implementadas.

Ventajas:

• Es una estrategia relativamente óptima ante una situación de fecha límite rígido.
• Permite reducir mucho el riesgo en proyectos grandes si se gestionan sus módulos de menor prioridad con esta técnica.

Inconvenientes:

• Si se consiguen implementar relativamente pocas funcionalidades de las previstas se habrá perdido mucho tiempo en la especificación y diseño de funcionalidades no implementadas al final, por tanto hay que medir bien la ambición del trabajo previo a los ciclos iterativos.

MODELO MIXTO

Los modelos presentados solo son algunos de los existentes, ante un proyecto concreto cabe la posibilidad de combinar modelos diferentes si el perfil del proyecto lo hace aconsejable, es decir, los modelos presentados no se deben interpretar con un espíritu excesivamente purista, sino tomarlos como estrategias de base ante una serie de características de un proyecto.

Lo importante es que se haga el ejercicio de plantear una estrategia de desarrollo que responda de una manera coherente a la situación previsible del proyecto al que se aplica. Los modelos aquí presentados pueden ser válidos para muchas ocasiones, y si no lo fueran constituirán una "inspiración" para diseñar un modelo a medida más adecuado.

MODELO DE TRANSFORMACIÓN

Este modelo trata de resolver los problemas asociados a la dificultad de modificar el código en paradigmas como el de versiones sucesivas. Para ello parte de la premisa de la existencia de un sistema que pueda convertir fácilmente los requerimientos en código.

Los pasos seguidos en este modelo son:

• Una especificación formal del sistema.
• Una transformación automática (o asistida) de las especificaciones a código.
• Una serie de iteraciones sobre el código obtenido con objeto de mejorarlo.
• Prueba general del resultado.
• Iteraciones para ajustar el resultado a las especificaciones. Si se realiza alguna modificación sobre éstas se repite el proceso hasta que requerimientos y código final sean válidos.

La principal dificultad para la aplicación de este modelo de desarrollo está en la falta de un sistema adecuado para transformar los requerimientos en código. Esta transformación puede ser llevada a cabo en pequeños proyectos dedicados a tareas específicas, pero no es posible generalizar su aplicación.