miércoles, 23 de septiembre de 2015

Ciclo de vida clasico

El modelo de ciclo de vida clásico, también denominado "modelo en cascada", se basa en intentar hacer las cosas bien desde el principio, de una vez y para siempre. Se pasa, en orden, de una etapa a la siguiente sólo tras finalizar con éxito las tareas de verificación y validación propias de la etapa. Si resulta necesario, únicamente se da marcha atrás hasta la fase inmediatamente anterior. 

Este modelo tradicional de ciclo de vida exige una aproximación secuencial al proceso de desarrollo del software. Por desgracia, esta aproximación presenta una serie de graves inconvenientes, entre los que cabe destacar: 

- Los proyectos reales raramente siguen el flujo secuencial de actividades que propone este modelo. 

- Normalmente, es difícil para el cliente establecer explícitamente todos los requisitos al comienzo del proyecto (entre otras cosas, porque hasta que no vea evolucionar el proyecto no tendrá una idea clara de qué es lo que realmente quiere). 

- No habrá disponible una versión operativa del sistema hasta llegar a las etapas finales del proyecto, por lo que la rectificación cualquier decisión tomada erróneamente en las etapas iniciales del proyecto supondrá un coste adicional significativo, tanto económico como temporal (y eso sin tener en cuenta la mala impresión causada por un retraso en la fecha de entrega).


Tal cual, el modelo de ciclo de vida en cascada no nos indica nada acerca de la relación contractual existente entre el cliente y la organización encargada del desarrollo de software. Desde el punto de vista de una empresa de desarrollo de software, formalizar la firma de un contrato al final de la etapa de análisis, por ejemplo, puede ayudar a reducir el riesgo que supone elaborar un presupuesto cuando aún no se dispone de toda la información necesaria para que la estimación del esfuerzo requerido por el proyecto sea lo suficientemente precisa. Este tipo de contrato obliga a que el cliente se haga cargo de los costes adicionales ocasionados por cambios en los requerimientos, mientras que la empresa de desarrollo de software deberá asumir los gastos ocasionados si el producto finalmente entregado no cumple todas las condiciones pactadas a la firma del contrato. Por desgracia, un modelo contractual como el descrito en el párrafo anterior no siempre resulta aceptable para el cliente, que puede verse obligado a invertir dinero a cambio de nada. Esto podría pasar si, tras la etapa de análisis, el proyecto se desestima por no ser técnica o económicamente viable. Es más, si el cliente acepta a regañadientes la firma de un contrato al final de la etapa de análisis, la imagen de la empresa desarrolladora de software puede verse seriamente deteriorada en cuanto surja cualquier tipo de problema.

No hay comentarios:

Publicar un comentario