|
2.PROYECTOS CON MODELO DE DESARROLLO EN CASCADA.
Si la empresa realmente aplica un modelo de desarrollo, es probable que
utilice un modelo en cascada (waterfall model), ya que éste ha
sido el modelo de desarrollo dominante en el área informática
durante muchos años.
La figura 1 muestra un esquema simplificado
de este modelo. Para los no versados en Ingeniería del Software,
diremos que el análisis (más propiamente, “análisis
de requerimientos”) es una descripción de lo que debe hacer
el sistema, el diseño son los “planos” del sistema
y la programación es el proceso de construir el sistema acabado.
Una vez realizada la programación, es necesario probar el programa
para detectar los posibles errores y corregirlos, etapa
que se denomina con el nombre de “Pruebas”.
Figura 1. El modelo de desarrollo en cascada
En un modelo en cascada, primero se realiza el análisis. Cuando
se tiene un análisis acabado se comienza a desarrollar el diseño.
Cuando el diseño está acabado, se lleva a cabo la programación.
Cuando la programación está acabada se realizan las pruebas.
A primera vista, este orden parece lógico, pues el diseño
se basa en el análisis, de la misma manera que la programación
se basa en el diseño y las pruebas en la programación. Además,
esto es análogo a lo que sucede en las otras ingenierías.
Usando la analogía anterior, es evidente que no se empieza a construir
un edificio hasta que los planos estén totalmente acabados.
Sin embargo, como hemos dicho, los programas informáticos son
mucho más complejos y abstractos que un edificio o que cualquier
producto resultante de otra ingeniería. Es por esto que este modelo
no se adecua bien al desarrollo de sistemas. Sus principales defectos
son los siguientes:
Rigidez y poca adaptabilidad. En un mundo perfecto,
los clientes y los desarrolladores tendrían claros los requerimientos (lo que
debe hacer el sistema) desde un principio y estos requerimientos no cambiarían
durante el proceso de desarrollo. Sin embargo, la realidad
es que los requerimientos cambian constantemente, bien porque el cliente
se da cuenta
de necesidades que ignoraba, bien porque el mercado o la
tecnología
evolucionan o bien porque los desarrolladores se dan cuenta de requisitos
técnicos que no habían previsto en un principio.
Un estudio realizado ([2]) revela que los requerimientos no anticipados
en el comienzo del proyecto pueden suponer un 25% del total para proyectos
de desarrollo medios y hasta un 50% para proyectos grandes (similares
resultados se presentan en el artículo [3]).
El modelo en cascada no permite acomodar estos cambios, ya que los requerimientos
quedan fijados desde el comienzo, no pudiendo ser modificados
con posterioridad.
Baja mitigación de riesgos. Con el modelo en
cascada no ess hasta el final del proyecto cuando se
pueden hacer pruebas y determinar la viabilidad o eficiencia
de nuestra arquitectura. Así, los elementos más
riesgosos (como la viabilidad de la arquitectura del
sistema) se determinan al término del proceso
de desarrollo, cuando es más difícil y
costoso modificarlos, además de que se ha perdido
valioso tiempo y recursos diseñando una arquitectura
que al final se revela como no viable.
Falta de retroalimentación. Es bien conocido que, la mayoría
de las veces, el cliente comienza con una idea aproximada y vaga de lo
que quiere y, sólo cuando ve el programa funcionando, comienza
a comprender en detalle lo que realmente necesita. Sin embargo, en el
modelo en cascada, sólo se tiene un ejecutable del sistema hasta
el final del proyecto. En este punto, los cambios son caros
o poco posibles ya que la estructura del sistema está firmemente establecida.
Como consecuencia, el modelo de desarrollo en cascada es demasiado rígido
para un proceso tan dinámico como es el desarrollo de software.
Es por eso que adoptarlo es contraproducente para la correcta ejecución
del proyecto de software. De hecho, en un estudio de dos años sobre
proyectos de desarrollo exitosos que se publicó en [4], se determinó que
el primer factor de éxito para un proyecto de desarrollo es adoptar
un modelo de desarrollo diferente del modelo en cascada.
|
