archivo

Archivos diarios: junio 17, 2011

Existe proyectos de desarrollo de software que no terminan de funcionar adecuadamente para clientes (no tiene todas las funcionalidades principales implementadas o algunas de ellas no tienen un comportamiento adecuado) y para proveedores (desviación del esfuerzo estimado y disminución de la expectativa de beneficio o incluso, entrada en pérdidas) por el hecho de que no se han priorizado adecuadamente en el proceso de desarrollo las funcionalidades a implementar, lo que ha podido provocar que se haya distraido la atención y el esfuerzo en tareas que no son importantes o decisivas en el proyecto, perdiendo el enfoque de lo que resulta importante o no.

Esta circunstancia en un desarrollo utilizando el ciclo de vida clásico o en cascada resulta fatal y dará lugar a multitud de situaciones de conflicto entre cliente y proveedor, ya que en fases tardías del desarrollo se intentará enderezar la nave y salvo que todos los requisitos se hayan catalogado, la única solución será entrar en un proceso de negociación entre las partes, intercambiando unos requisitos por otros, solución que por otra lado no dejará satisfecho a nadie. Incluso catalogándose los requisitos, existen tantas posibles contingencias que pueden provocar desviaciones en proyecto, que pueden hacer que no se terminen implementando todos los requisitos, lo que hará que al final se tenga un producto donde buena parte de las funcionalidades no estén disponibles. Es lo mismo que tener un coche que a simple vista resulta estupendo, pero al que le faltan piezas fundamentales para que funcione o para que su conducción sea cómodo.

En desarrollos iterativos e incrementales con ciclos de corta duración, este tipo de problemas se detectarán antes por regla general (siempre y cuando el equipo de usuarios no persista en su error hasta iteraciones muy posteriores), sobre todo en aquellas soluciones que pretenden que en pocas iteraciones se tenga ya una aplicación o esqueleto andante que ya pueda ser utilizado por los usuarios.