Modelo Clásico

En el modelo clásico, cada proyecto atraviesa por algún tipo de análisis, diseño e implantación, aunque no se haga exactamente como se muestra en la figura siguiente. El ciclo de vida de proyecto utilizado, pudiera diferir del que se muestra en la figura siguiente en una o todas de las formas siguientes:

• La fase de exploración y análisis pudieran juntarse en una sola.
• Puede no haber fase de estudio de hardware si se cree que cualquier sistema nuevo pudiera instalarse con las computadoras existentes sin causar mayor problema operacional.
• La fase de diseño preliminar y el diseño de detalles pudieran juntarse en una sola llamada simplemente de diseño.
• Diversas fases de pruebas pueden juntarse en una sola; de hecho, podrían incluirse con la codificación.

El ciclo de vida del proyecto clásico

El uso de la implantación ascendente es una de las grandes debilidades del ciclo de vida de los proyectos clásicos. Como se podrá ver en la figura, se espera que los programadores lleven a cabo primero sus pruebas modulares, luego las pruebas del subsistema, y finalmente las pruebas del sistema mismo. Este enfoque también se conoce como el ciclo de vida de cascada. .

Muchas organizaciones que desarrollan sistemas únicos, el enfoque ascendente presenta un gran número de dificultades serias:

• Nada esta hecho hasta que todo esté terminado.
• Las fallas más triviales se encuentran al comienzo del período de prueba y las más graves al final.
• La eliminación de fallas suele ser extremadamente difícil durante las últimas etapas de prueba del sistema.
• La necesidad de prueba con la computadora aumenta exponencialmente durante las etapas finales de prueba.

La segunda debilidad más importante del ciclo de vida de un proyecto clásico es su insistencia en que las fases se sucedan secuencialmente. Querer esto es una tendencia natural humana: deseamos decir que hemos terminado la fase de análisis del sistema y que nunca tendremos que volver a preocuparnos por ella. El único problema del progreso ordenado es que no es nada realista. Por ejemplo, durante el período que transcurre para desarrollar el sistema pueden cambiar ciertos aspectos del ambiente del usuario (la economía, la competencia, los reglamentos gubernamentales que afectan a las actividades del usuario).