Modelos De Proseso De Software

COMPARATIVA DE LOS MODELOS DE PROCESO DE SOFTWARE

I. DESCRIPCIÓN DE LOS MODELOS DE PROCESO DE SOFTWARE

EL MODELO LINEAL (O MODELO EN CASCADA).

Es el más antiguo de todos los modelos de Ingeniería del Software. El modelo lineal presenta una estructura secuencial (de ahí el nombre de Modelo en cascada) formada por seis fases o etapas:

- Análisis del Sistema

- Análisis de Requisitos de Software

- Diseño

- Codificación

- Prueba

- Mantenimiento

Las fases incluyen dentro de sí determinadas tareas que clasifican de una forma clara el trabajo a realizar.

El desarrollo de las fases, como he mencionado antes, se produce de manera secuencial. Una vez se produce el análisis tanto del Sistema como de los requisitos del software demandado por el cliente, (fases en las que la intervención del cliente es absolutamente necesaria), se procede a la fase de diseño de la arquitectura global del software. Un diseño elaborado de forma cuidadosa llevará a una rápida codificación. Tras haber traducido el programa a un lenguaje comprensible para el ordenador, se comprueban los elementos de forma individual y más tarde de manera homogénea (todos los sistemas a la vez). Una vez entregado el software al cliente, la fase de Mantenimiento comprenderá las actualizaciones y las correcciones de errores que sean necesarias en el programa.

El Modelo en cascada no permite retroceder (más tarde analizaremos las ventajas e inconvenientes de todos los modelos en común), por lo que se hace estrictamente necesario que al final de cada fase el analista de sistemas o, en su caso, el programador, verifique y valide todo el trabajo realizado, ya que un error no detectado a tiempo podría perjudicar gravemente la fecha de entrega del software a nuestro cliente.

EL MODELO INCREMENTAL.

El modelo incremental es una evolución del modelo de cascada; viene a suplir el problema de no poder retroceder en las fases de desarrollo del software. Es, por tanto, un modelo no secuencial.

El funcionamiento es sencillo. Comienza con el análisis de los requisitos, tras el cual se prepara un primer diseño. La novedad de este modelo respecto del anterior, es la introducción de iteraciones para “bifurcar” diseños. Es decir, este modelo ofrece la posibilidad de comenzar un diseño, arquitectura, estructura, etc del software, que de no convencer al cliente (o al propio programador) es rechazado y se comienza con una segunda iteración (o un segundo diseño), sin necesidad de realizar un nuevo análisis de requisitos. Pueden realizarse tantas iteraciones (también llamadas incrementos) como sean necesarias.

EL MODELO DE CONSTRUCCIÓN DE PROTOTIPOS.

Este modelo no secuencial, basado en la construcción de simulaciones o modelos ejecutables de aplicaciones más extensos, persigue un objetivo principal: la participación directa del cliente en la construcción del software requerido. Las fases son similares a las del modelo en cascada: es necesario un análisis previo de los requisitos tanto del sistema como del cliente, se concibe la arquitectura del sistema y se realiza el diseño del software. Sin embargo, se incluye un elemento hasta ahora no utilizado, que consiste en el diseño rápido de un prototipo que se mostrará al cliente para que evalúe el trabajo realizado.

El prototipo es una versión reducida del programa completo; es una “fachada virtual” que mostramos al cliente (que carece de la posibilidad de ser utilizada de la forma en que lo haríamos con el software final. Tras recoger los requisitos tanto del cliente como del sistema, se comienza con el diseño rápido del prototipo; el diseño completo obedece al previo diseño de pequeños prototipos específicos para funciones individuales. Más tarde, estos diseños serán unidos en uno sólo.

Después, se procede a la construcción del mismo. Éste prototipo es el que mostraremos al cliente para que lo evalúe y considere cambios en él, aunque no se trate de una versión definitiva.

EL MODELO EN ESPIRAL.

Este modelo, también no secuencial, es algo más complejo que los anteriores, aunque incluye un elemento muy útil e importante en el desarrollo del software: análisis de riesgos. El modelo en espiral concreta cuatro fases:

- Planificación

- Análisis de Riesgos

- Ingeniería (Construcción del prototipo)

- Evaluación por el cliente

Si ésta última fase es afirmativa, el modelo continúa con la estructura del Ciclo de vida Clásico. Si el cliente no está satisfecho con el resultado, se cubre otra banda de la espiral y se vuelve a la primera fase (de planificación).

II. VENTAJAS E INCONVENIENTES DE LOS MODELOS

Podemos considerar al modelo en cascada como el más sencillo de utilizar, aunque también podríamos dudar de su eficacia dado el alto número de inconvenientes que presenta, siendo el principal el que se trate de un modelo secuencial; por otra parte, este modelo exige tareas de profundización en el análisis de requisitos del sistema. Si este sistema no es bien conocido, o es difícil de analizar, esta fase puede alargarse demasiado.

Ninguno de los modelos es perfecto; el modelo incremental añade la posibilidad de utilizar iteraciones para doblegar el diseño y contemplar varias posibilidades hasta elegir una. Es un modelo completamente interactivo, que permite trabajar con él en situaciones en las que los cambios de opinión estén a la orden del día. Cada incremento es un paso más en el desarrollo del software final, lo que nos permite cambiar entre iteraciones (o bien proceder a la entrega del software a nuestro cliente como si se tratara de “fascículos semanales”).

Esta ventaja es también el principal inconveniente; no en todas las situaciones de desarrollo de software podemos permitirnos la división del trabajo en incrementos, ni tampoco periodificar la entrega de los mismos. Además, aunque la mayoría de las veces el software se puede fragmentar y podemos trabajar con un conjunto de programas determinado, pueden darse situaciones en las que sea imposible ejecutar una iteración sin la existencia de otra que cumpla una función complementaria.

Los prototipos (cambiando de modelo), son una herramienta muy eficaz para imaginar el software completo de una forma rápida y sencilla. De esta forma, incluso observando el prototipo podemos descubrir requerimientos del software en los que antes no habíamos reparado. Mejora también el proceso de introducción de cambios en el desarrollo de los programas. En el modelo incremental podíamos recurrir a las iteraciones, pero resultará más sencillo (y sobre todo, más visual) realizar éstas modificaciones sobre el prototipo en cuestión. Además, ésta operación puede realizarse bajo la

...