Desarrollo de software. Lo clásico

Se realiza una entrega, una eternidad después del análisis, se pone el producto en producción. Cuanto mayor sea el tiempo que transcurre entre la finalización del análisis y la puesta en producción más posibilidades hay de que más parte del trabajo realizado termine tirándose a la basura.

Por mucho que cambien los responsables funcionales no es lo mismo solicitar cambios (o el listón para los caprichos está más alto) cuando un sistema se usa que cuando un sistema aún no se utiliza.

El problema para el proveedor en este caso será, en caso de conflicto (y los hay y muchos), que el cliente empiece a encontrar grietas entre lo que se ha entregado, lo que aparece en el análisis, lo que el equipo de proyecto ha podido interpretar, etc…, porque si las encuentra y aprieta (sobre todo si tiene la sartén por el mango), puede que parte de lo que haya que rehacer lo tenga que hacer gratis.

El ciclo de vida clásico o en cascada presenta ese riesgo.

Es necesario reducir los tiempos y que si se piden cambios sean en base a un proceso definido y sobre una versión del desarrollo realizado o lo que es lo mismo hacer un planteamiento iterativo e incremental de los desarrollos.

About these ads

Deja un comentario

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.

Únete a otros 3.198 seguidores

%d personas les gusta esto: