Estrategias De Desarrollo De Aplicaciones

Modelo Monolítico

Este proceso se divide en fases claramente especificadas, que pueden variar dependiendo de los autores consultados, pero conservan siempre la misma idea, de que no puede empezar una fase hasta que no se termine la anterior.

La primera fase que se toma en cuenta es el Estudio de Factibilidad del proyecto. Una vez estudiada la factibilidad y aprobado el proyecto, se pasa al Análisis de Requerimientos donde se establecen y se especifican los requerimientos a detalle junto con el cliente, luego pasamos al Diseño de la solución de cómputo, posteriormente a la Codificación y Pruebas de los módulos, (pues en lo general, el sistema debe estar modularizado) sigue la Integración de los módulos en un sistema completo haciendo Pruebas de este sistema integrado, posteriormente la fase de Entrega e Instalación del sistema al usuario, y finalmente el Mantenimiento, el cual puede ser la fase más costosa y más larga en tiempo, por las adaptaciones, modificaciones y correcciones según las necesidades del usuario.

En este modelo, el grupo de desarrollo no puede empezar una fase siguiente si la anterior no quedó totalmente terminada. Por ejemplo, si no se hizo la fase de Estudio de Factibilidad, no se documentaron los resultados de esta fase y no se aprobó el proyecto, no se puede empezar la fase de Análisis; si esta tampoco se termina no puede iniciar entonces la de Diseño. Cada fase emite un producto para la siguiente fase, (ya sea documentación o el propio código) el cual es indispensable para formar la entrada de la misma.

La ventaja de este modelo, es que ya tenemos cierta disciplina en el desarrollo de sistemas; se introducen la planeación y administración, pues las fases se deben planear en tiempo y recursos (humanos y físicos), y se deben administrar, es decir, alguien vigila que el grupo de desarrollo realmente se ajuste a lo que se ha planeado y está cumpliendo con este proceso de desarrollo.

En este modelo, la fase de Codificación se pospone hasta que se entienda bien el objetivo del proyecto (los requerimientos) y hasta que se haga el diseño de todo el sistema. Esto es una ventaja pues se evita construir productos que finalmente no cumplirán en su totalidad con lo que el usuario requiere. La desventaja de este modelo es que es lineal, rígido y monolítico, por lo tanto irrealista, pues la gente difícilmente se espera, para realizar sus propias actividades, a que terminen sus compañeros de fases anteriores. Podemos ver aquí el anti patrón "análisis - parálisis": la persona que hace el análisis no es capaz de decir que ya entendió el problema, que ya tiene todos los requerimientos porque siempre le parece que falta algo, dando como consecuencia el retardo en la entrega de los documentos de análisis a los grupos responsables de las siguientes partes. Difícilmente en la realidad se puede organizar el trabajo en esta forma tan rígida.

Además este modelo presenta dificultad para introducir modificaciones, sobre todo en la fase de Mantenimiento, porque para realizarlo habría que volver a empezar todo el ciclo, modificando la información de cada fase, para tener así una especificación y documentación consistente con el mantenimiento realizado.

Esto último es importante puesto que dentro del Mantenimiento tenemos que el 20% es correctivo (se corrigen los errores del sistema original), otro 20% es adaptativo (adaptamos sin cambios esenciales en las funciones originales) y el 60% está dirigido al perfeccionamiento del sistema (ampliamos el sistema con nuevos requerimientos del usuario). De no documentar debidamente cada mantenimiento, corremos el riesgo (que de hecho actualmente existe en gran medida) de tener sistemas que no cuentan con su documentación actualizada.

Este modelo está enfocado a la producción de documentos. Cada fase tiene que entregar un producto (documento o software) bien documentado, para que otros grupos puedan trabajar con ellos.

Ventaja: requiere de disciplina, planeación y administración, la puesta en práctica se pospone hasta que se entienda bien el objetivo.

Desventaja: linear, rígido, monolítico, no realista. Difícil de introducir modificaciones sobre todo en la fase de mantenimiento, la cual en 20% es correctiva, otro 20% adaptativa pero en más del 50% está dirigida al perfeccionamiento del sistema.

Característica: enfocado a la producción de documentación.

Modelo Evolutivo

A partir de este modelo, encontramos los más recientes originados del de cascada, que actualmente están impactando y adaptándose cada vez más a la orientación a objetos.

El modelo Evolutivo conocido también como incremental e iterativo, consiste en hacer la documentación de las fases, realizando un prototipo del sistema, se evalúa el qué tan lejos el prototipo está de la solución final esperada por el cliente; se toman en cuenta las observaciones de esta evaluación, y se crea un nuevo prototipo que las incluya. Esto se realiza en una vuelta repetitiva donde se incrementa el alcance del prototipo en pequeñas proporciones hasta cumplir los requerimientos totales.

En este método no es necesario esperar hasta que toda una fase esté terminada para iniciar la siguiente. Si se cuenta con una parte del análisis bien entendida, se puede realizar un primer diseño del corazón o de una parte medular del sistema, hacer su codificación y con esto, formar nuestro primer prototipo que ampliaremos en las siguientes iteraciones (vueltas), creando prototipos cada vez mejores y amplios con respecto a los requerimientos originales.

La ventaja es que es ideal para sistemas que no tiene bien definidos

...