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.

...