El enfoque clásico del proyecto

El modelo en cascada es una referencia

El modelo en cascada es el estándar esencial para la gestión de proyectos. Aunque a menudo muestra un concepto opuesto al que se presenta con los métodos ágiles o incluso los promotores lo suelen criticar, lo cierto es que sigue aplicándose con cierto éxito.

Este modelo, que se basa en una sucesión de fases, es de una lógica muy simple. Cada fase comienza cuando termina la anterior, con el objetivo de desarrollar y enriquecer un entregable construido de manera progresiva. De esta manera, las especificaciones son la traducción de la expresión de necesidades, el código fuente se convierte en la materialización de las especificaciones, las pruebas se llevan a cabo en un programa ensamblado (se podría decir compilado), el software se despliega e instala cuando el programa alcanza los estándares de calidad deseados al final de las pruebas, etc.

Este modelo de desarrollo es al menos tan antiguo como la propia programación informática. Y esta observación lleva a dos hechos objetivos.

En primer lugar, un modelo de desarrollo no es un método de gestión de proyectos. Tratándose de una secuencia tan lógica de fases, actividades y tareas, no vale la pena seguir una planificación, gestionar los riesgos o proceder a la toma de decisiones.

En segundo lugar, la antigüedad de este modelo y la persistencia de su uso, ciertamente atestiguan su idoneidad para una cierta tipología de proyectos, pero también por la diferencia en sus límites.

Estas dos observaciones ayudan a posicionar el modelo de cascada y los métodos ágiles respectivamente. No se trata de que estos últimos sean completamente opuestos, ya que integran parcialmente la secuencia de fases del modelo en cascada.

Por lo tanto, es útil dominar la gestión de un proyecto siguiendo un enfoque clásico, para aplicarlo primero a la tipología de proyecto adecuada (ver...

Fases del proyecto

1. La expresión de las necesidades y especificaciones

Estos dos términos son similares, aunque en la práctica una expresión de necesidades es el punto de partida para el desarrollo de especificaciones más completas.

Como ya hemos mencionado, normalmente las especificaciones se critican más que se elogian. Y, sin embargo, es un documento esencial para la realización de un proyecto. El principal problema relacionado con su redacción radica en la interpretación supuestamente equivocada que podríamos hacer de ella, dependiendo de si uno se ocupa de la gestión del proyecto o de la realización del mismo. De hecho, algunas veces los clientes encuentran dificultades reales para expresar claramente sus necesidades (algunas veces incluso escuchamos que la mejor expresión se corresponde con el software realizado). También sucede que, cuando tenemos cierta experiencia, los clientes permanecen deliberadamente poco activos en sus respuestas, buscando maximizar su margen de maniobra y retrasar sus elecciones.

La empresa encargada de la implementación persigue precisamente el objetivo opuesto: cuanto antes identifique el alcance de la solución, mejor será el rendimiento del proyecto, a través de la capitalización del saber hacer (know how).

Por lo tanto, la situación parece difícil de resolver y, sin embargo, se impone rápidamente porque las especificaciones siguen siendo el principal anexo técnico de un contrato de desarrollo informático.

Está claro que los malentendidos se derivan del carácter "inmutable" que se les da a las especificaciones. Sería un fin en sí mismo. Sin embargo, este no es el caso y la solución radica en otra lectura de la observación hecha anteriormente. Si la mejor expresión de una necesidad del cliente es la que implementa el software, es solo una derivación de un conjunto de necesidades que resultan de las especificaciones.

En otras palabras, las especificaciones no son de ninguna manera un documento fijo, sino más bien un lienzo que el proceso de análisis completará y transformará hasta la creación del software.

Y todos los procesos de análisis comienzan priorizando los elementos del proyecto. Por lo tanto, no hay razón para presionar...

El desarrollo del proyecto de control de actividades

Jérôme se siente bastante cómodo organizando el desarrollo del software de control de actividades. Organiza una reunión para todo el equipo del proyecto durante la que recuerda las modalidades de codificación, prueba y despliegue. Como la planificación está apretada, los desarrolladores se tendrán que ceñir estrictamente a estas recomendaciones.

1. Organización del desarrollo

a. La gestión del código fuente y de los elementos de trabajo

El código fuente se comparte mediante el software Azure DevOps, siguiendo la metodología Agile-Scrum. Cada iteración cubre todas las solicitudes (requirements) y anomalías (bugs) que se realizarán durante el período (sprint o iteración).

Los desarrolladores recuperan la última versión de un módulo de código fuente antes de realizar cambios. Al final del día, archivan sus cambios en la medida de lo posible y realizan comprobaciones previas y posteriores para garantizar que los proyectos siempre se compilen sin errores.

Para cada operación de archivado, se debe asociar el identificador del elemento de trabajo y, a continuación, actualizar el estado: activo, en curso, completado, corregido, etc. Los probadores se encargan de controlar estos estados y pueden cerrar los puntos o volver a abrirlos. Los puntos realizados finalmente se cambian a una subiteración actual para que los probadores puedan determinar el alcance de una versión.

La ejecución de pruebas unitarias es un requisito previo para validar un elemento de trabajo (completado o corregido). Los desarrolladores también integran modalidades de prueba especiales en los elementos de trabajo.

b. Documentación

El código se comenta siguiendo los estándares establecidos para el lenguaje de programación. Jérôme insiste en la calidad de los comentarios y su relevancia para el código que describen.

Las herramientas de extracción automática se aplican periódicamente para garantizar que haya comentarios en el código.

Jérôme requiere que las especificaciones técnicas se desarrollen a partir de los documentos proporcionados por los analistas:

Plantillas de base de datos
Diagramas de clases
Gráfico del sitio
Navegación...