Ciclos De Vida Del Software

I. DEFINICION DE CICLO DE VIDA DEL SOFTWARE SEGÚN NORMA ISO 12207

La norma ISO 12207-1 entiende por modelo de ciclo de vida a un 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.

II. MODELOS DE CICLO DE VIDA

Las principales diferencias entre distintos modelos de ciclo de vida están dividias en tres grandes visiones:

• EL alcance del ciclo de vida: depende de hasta donde deseamos llegar con el proyecto: solo saber si es viable el desarrollo de un producto, el desarrollo completo o el desarrollo completo más las actualizaciones y el mantenimiento.

• La cualidad y cantidad de las etapas: en que dividiremos el ciclo de vida: según el ciclo de vida que adoptemos, y el proyecto para el cual lo adoptemos.

• La estructura y la sucesión de las etapas: si hay realimentación entre ellas, y si tenemos libertad de repetirlas (iterar).

En los distintos modelos de ciclo de vida mencionaremos el riesgo que supone aceptar al elegirlo. Cuando hablamos de riesgo , nos referimos a la probabilidad que tendremos de volver a retomar una de las etapas anteriores, perdiendo tiempo, dinero y esfuerzo.

1. CICLO DE VIDA LINEAL

Es el más sencillo de todos los modelos. Consiste en descomponer la actividad global del proyecto en etapas separadas, que son realizadas de manera lineal, es decir, cada etapa se realiza una sola vez, a continuación de la etapa anterior y antes de la etapa siguiente. Con un ciclo de vida lineal es muy fácil dividir las tareas, y prever los tiempos (sumando linealmente los de cada etapa).

Las actividades de cada una de las etapas mencionadas deben ser independientes entre sí, es decir, que es condición primordial que no haya retroalimentación entre ellas, aunque si pueden admitirse ciertos supuestos de realimentación correctiva.

Desde el punto de vista de la gestión requiere también que se conozca desde el primer momento, con excesiva rigidez lo que va a ocurrir en cada una de las distintas etapas antes de comenzarla. Esto último minimiza, también las posibilidades de errores durante la codificación y reduce al mínimo la necesidad de requerir información del cliente o del usuario.

Se destaca como ventaja la sencillez de su gestión y administración tanto económica como temporal, ya que se acomoda perfectamente a proyectos internos de una empresa para programas muy pequeños de ABM (sistemas que realizan altas, bajas y modificaciones sobre un conjunto de datos). Tiene como desventaja que no es apto para desarrollos que superen mínimamente requerimientos de retroalimentación entre etapas, es decir es muy costoso retomar una etapa anterior al detectar alguna falla.

• Análisis de requerimientos: Sirve para comprender la naturaleza de los programas a desarrollar, el ingeniero debe comprender el dominio de información del software, así como la función requerida, el comportamiento, el rendimiento y la interconexión.

• Diseño: Es un proceso de muchos pasos que se centra en 4 atributos del programa: Estructura de datos, arquitectura de software, representaciones de interfaz y detalle procedimental (algoritmo). Traduce requisitos en una representación del software donde se puede evaluar su calidad antes de que comience su codificación.

• Generación de código: El diseño se traduce en una forma legible por la máquina, usando lenguajes de programación o lenguajes 4gl entre otros.

• Pruebas: Después de generar el código, se prueba la funcionalidad de este, haciendo un test de los procesos lógicos internos, se busca detectar errores y garantizar que el software hace exactamente lo que debe hacer.

• Mantenimiento: El software debe sufrir cambios, ya sea por la detección de errores, por nuevas necesidades y requerimientos, por modernizar la funcionalidad de este o por adaptación a cambios del medio externo del software. Este modelo es el más antiguo y usado en la ingeniería del software.

Características que hacen adecuado el uso de este modelo

• Se disponga de unos requisitos completos y consistentes al principio del desarrollo.

• Sean proyectos pequeño, en el que el período de congelación de los requisitos es corto, o un proyecto con unos requisitos bastante estables.

Ventajas del modelo lineal secuencial

• Se debe tener en cuenta que fue el primer modelo empleado, y por lo tanto es mejor que ninguno.

• Facilita la gestión del desarrollo.

Desventajas del modelo lineal secuencial

• En general, establecer todos los requisitos al principio del proceso de desarrollo es un mito inalcanzable: Los usuarios no pueden imaginárselo que quieren hasta que no ven un sistema funcionando.

• Los requisitos no se pueden congelar mientras dura el desarrollo. El mercado cambia, todo cambia.

• El usuario debe esperar mucho tiempo hasta ver los resultados.

• Los errores de análisis y diseño son costosos de eliminar, y se propagan a las fases siguientes con un efecto conocido como bola de nieve.

• Se genera mucho mantenimiento inicial debido al período de congelación de requisitos y éste recae, en su mayor parte.

¿Por qué falla algunas veces el modelo lineal?

1. Los proyectos reales raras veces siguen el modelo secuencial que propone el modelo.

2. A menudo es difícil que el cliente exponga explícitamente todos los requerimientos.

3. El cliente debe tener paciencia. Un grave error puede ser desastroso.

Cada uno de estos errores es real. Sin embargo el paradigma del ciclo de vida clásico tiene lugar definido e importante trabajo de la ingeniería del software.

EJEMPLO:

• Un programa que pueda registrar tanto a los trabajadores que generen rentas de 4ta y 5ta categoría, pudiendo deducir sus aportes que realizan a las Administradoras de Fondos de Pensiones ( 5ta categoría) y calcular si están afectos a otros descuentos.

• La realización de una calculadora con distintas funciones que serán dichas por el usuario.

2. CICLO DE VIDA ITERATIVO

Es un modelo derivado del ciclo de vida en cascada. Este modelo busca reducir el riesgo que surge entre las necesidades del usuario y el producto final por malos entendidos durante la etapa de recogida de requisitos.

Consiste en la iteración de varios ciclos de vida en cascada. Al final de cada iteración se le entrega al cliente una versión mejorada o con mayores funcionalidades del producto. El cliente es quien después de cada iteración evalúa el producto y lo corrige o propone mejoras. Estas iteraciones se repetirán hasta obtener un producto que satisfaga las necesidades del cliente

La Especificación de requisitos se realiza en forma creciente: a medida que los Usuarios logran un mejor entendimiento del problema, éste es reflejado en el sistema software. Es decir, el Producto de cada etapa de Especificación de requisitos es un agregado o mejora al Producto de la etapa de especificación anterior.

Este modelo se basa en dos premisas:

1) Los Usuarios a menudo no saben bien lo que quieren o necesitan.

2) Por lo general, los requisitos en algún momento van a cambiar.

Para solucionar el primer punto, los requisitos se determinan en base a alguna forma operacional del sistema (por ejemplo, un prototipo) para ser revisado por los Usuarios. Para atender el segundo punto, se realizan entregas parciales del sistema que permiten incorporar nuevos requisitos o cambios en requisitos existentes en la siguiente entrega. Es decir, cada versión es una mejora sobre la predecesora.

Este modelo se utiliza cuando no se puede especificar a priori “todos” los requisitos del software, sino que el proceso ayudará a ir descubriendo paso a paso los requisitos a partir de cada nueva Entrega.

Este modelo se suele utilizar en proyectos en los que los requisitos no están claros por parte del usuario, por lo que se hace necesaria la creación de distintos prototipos para presentarlos y conseguir la conformidad del cliente.

El proceso en sí mismo consiste de:

• ETAPA DE INICIALIZACIÓN: Se crea una versión del sistema. La meta de esta etapa es crear un producto con el que el usuario pueda interactuar, y por ende retroalimentar el proceso. Debe ofrecer una muestra de los aspectos claves del problema y proveer una solución lo suficientemente simple para ser comprendida e implementada fácilmente. Para guiar el proceso de iteración se crea una lista de control de proyecto, que contiene un historial de todas las tareas que necesitan

...