No puede haber una respuesta exacta a esta pregunta, ya que la selección del modelo de desarrollo debe basarse en las circunstancias específicas de cada proyecto, sin embargo, desde mi experiencia profesional, tiendo a favorecer los modelos evolutivos, por contra de los modelos en cascada. Estos últimos se basan en la premisa de que se pasa de cada estadio del desarrollo al siguiente una vez cumplidos ciertos hitos preestablecidos. La dificultad que presentan estos modelos consiste en la imposibilidad práctica de obtener las especificaciones integras del proyecto desde el principio (e incluso en cada una de sus fases), con el fin de establecer claramente dichos hitos. Creo que todos hemos vivido situaciones en las que los mismos usuarios no están conscientes de lo que quieren, sobre todo cuando estamos hablando de las áreas con menos procedimientos y más dinámicas de la empresa, como son las de marketing y ventas.
Ciertamente, tal como se muestra en el gráfico anexo, un modelo en cascada no impide realizar pasos atrás para corregir errores generados en etapas anteriores, el problema principal, desde mi punto de vista, es que gran parte de los errores de diseño o técnicos suelen descubrirse en las etapas finales de construcción y pruebas, justo cuando es más costosa su corrección. Adicionalmente este modelo suele requerir el desarrollo de una gran cantidad de documentación que normalmente se queda obsoleta con mucha rapidez, ya que los cambios o correcciones realizados en las etapas finales pocas veces son realmente actualizados en la documentación generada de las etapas previas. A pesar de los expuesto anteriormente, este uno de los modelos más utilizados por las grandes consultoras, ya que se adecua mejor a su esquema de jerarquía organizativa (Consultores – Analistas – Programadores), en la cual, las primeras etapas del desarrollo (desde la definición de alcances hasta el diseño técnico) es encargado a los niveles más altos de la jerarquía, dejando lo referente a la construcción en manos de los niveles más bajos y por lo general menos experimentados. Este esquema de por si no es malo, solo que se ve afectado por el uso de personas sin suficiente experiencia, que no saben o no pueden asumir los errores u omisiones proveniente de etapas anteriores.
Tal como comenté al principio, sobre todo en el caso de implantaciones de paquetes comerciales (dígase Siebel, SAP CRM u otro), apuesto por un modelo de desarrollo en espiral, basado en prototipos o entregas parciales, en las cuales se define al inicio lo que debería ser el corazón del sistema y los alcances generales del mismo, realizándose un desarrollo por etapas, en la cual cada etapa por si misma se gestiona como si fuese un mini-proyecto que se va enriqueciendo con la aportación de las etapas subsiguientes. Las ventajas de este modelo consisten principalmente en otorgar visibilidad a los usuarios, desde los primeros momentos del proyecto, de lo que será una aproximación al resultado final esperado, evitando sorpresas de última hora o errores de interpretación. Adicionalmente, les permite digerir con mayor facilidad un conjunto reducido de funcionalidades a la vez. Por otro lado, el nivel de experticia requerido de los consultores suele ser mayor, pero el tamaño general del equipo de proyectos se reduce. Cada desarrollador asume más de una función, ya que no existe una separación explícitamente marcada entre las etapas de análisis, diseño, construcción y pruebas.
Por el contrario, este modelo exige un esfuerzo mayor en la gestión de los alcances del proyecto, debido a que no requiere que todos los puntos estén cerrados antes de iniciar el desarrollo, lo cual puede ser un arma de doble filo si no se controlan minuciosamente los riesgos asociados.
