archivo

Archivos diarios: julio 24, 2011

A veces un proyecto de desarrollo de software se convierte paulatinamente en un Death March Project sin que los responsables de la gestión económica del proyecto por parte del proveedor terminen por darse cuenta de que el mismo ha entrado en una dinámica de difícil salida.

El equipo de proyecto empieza a tener overtime, los plazos que parecían kilométricos ahora se asemejan a centímetros y la calidad de los trabajos empieza a resentirse.

Si el jefe de proyectos está muy apartado del proyecto, el responsable del equipo no le da la información necesaria o no le quiere advertir o es el mismo jefe de proyectos el que piensa que puede darle una vuelta a la situación sin avisar al responsable económico de la cuenta, provocará que la información tarde en llegar a quien tiene que tomar decisiones y tal vez cuando empiecen a aplicarse, las pérdidas del proyecto se verán difícilmente reducidas.

Es cierto como dice Yourdon que un Death March Project se huele en el aire, por lo que al final quien se tiene que enterar se entera, pero el problema no es ese, sino que se entere demasiado tarde como para que las medidas que adopte sirvan para algo.

Me comentó hace poco un amigo que el pilar principal en el que se tiene que sustentar un proyecto de desarrollo de software es la realización de un buen diseño del modelo de datos.

Por un lado implica que se han capturado adecuadamente los requisitos de almacenamiento y por otro que su traslación al modelo ha sido adecuada.

Aunque pueda parecer sorprendente la calidad de los modelos de datos deja mucho que desear: falta de normalización cuando lo que conviene es normalizar, falta de desnormalización cuando lo que conviene es desnormalizar, modelos complejos en lugar de soluciones simples, etc… y como bien dice mi amigo: “Por muy bien que construyas el edificio si los cimientos no son sólidos terminará tambaleándose”.