Ventajas-Inconvenientes de Los Modelos

Ventajas-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 supervisión del cliente, lo que hace a éste modelo más interactivo aún que su predecesor. Sin embargo, los prototipos tienen un gran problema en contraposición a sus ventajas: la rapidez con la que se diseñan y construyen pueden llevar a errores que no sean detectados en la fase de prueba y acaben integrándose en el producto final. Además, un prototipo es una representación casi exacta del programa final, carente de contenido real. Pero esto es algo que el cliente desconoce; si tiene prisa, puede creer que nuestro trabajo está mucho más avanzado de lo que creía (a pesar de que el prototipo sea tan sólo la fachada de un edificio sin paredes ni escaleras) y puede optar por adelantar la fecha de entrega; al final, el pobre programador es el que paga las consecuencias haciendo horas extras y, además, si se acelera demasiado la construcción del sistema final volvemos al problema de la inclusión de errores no detectados a tiempo.

Por raro que sea, o difícil de entender, el modelo en espiral parece entender los problemas de los anteriores e intentar subsanarlos. Si en el modelo anterior utilizábamos prototipos para hacernos una idea del software final, en éste modelo los utilizaremos también para hacernos una idea detallada de cuáles son los errores que tiene, o podría tener el programa durante su funcionamiento (lo que antes llamábamos análisis de riesgos). Esta manera de enfocar el diseño del software permite al cliente evaluar los factores de riesgo que le comunica el prototipo de análisis de riesgo, y según esta información tomar una decisión u otra. Esto hace que el modelo en espiral sea todavía más interactivo que los anteriores.

En cada fase se evalúa el trabajo terminado y, si nos dan el visto bueno, continuamos “girando” en la espiral hasta que llegamos a la evaluación del cliente, la cual decidirá si continuamos en el modelo clásico o volvemos a la primera fase del modelo en espiral. Sin embargo, todo éste análisis de riesgos (que tan útil parece ser) no parece fácil de utilizar; un análisis de riegos detallado utilizado sin experiencia podría sobre valorar (o subestimar) los errores que se presenten, haciendo imposible en paso a la siguiente fase (y entonces sí que nos meteríamos en una verdadera espiral sin fin, cosa que al cliente no debe hacerle mucha gracia). Éste problema genera otro adicional, y es que viendo estas situaciones, será difícil convencer al cliente para que acepte un proyecto realizado bajo las condiciones de éste modelo.

Tabla Modelos de Proceso de Software