|
“Para que un esfuerzo de desarrollo de software tenga éxito, es esencial comprender perfectamente los requisitos del software. Independientemente de lo bien diseñado o codificado que esté un programa, si se ha analizado y especificado pobremente, decepcionará al usuario y desprestigiará al que lo ha desarrollado”. Roger S. Pressman. Ingeniería del Software. Mc Graw Hill 1995. Parece lógico suponer que antes de empezar a construir algo, lo mejor es conocer con detalle qué es lo que vamos a hacer.
Una constructora, por ejemplo, podría levantar el edificio que espera su cliente, de forma evolutiva e incremental, a través de ciclos sucesivos de: “construcción – validación con el cliente – demolición de lo erróneo”. Pero contar con un proyecto detallado antes de empezar la construcción es un modelo de desarrollo mucho más adecuado.
En el desarrollo de software, el razonamiento que implica esta comparación es un punto de discordia importante entre defensores de modelos procesos, y de modelos ágiles.
Para los modelos de procesos (CMMI, ISO15504...) y para el marco de gestión de proyectos predictivo (PMI, IPMA...) es obvio y axiomático que:
- Para saber el tiempo y el precio que costará el proyecto, hay que tener una planificación detallada.
- Para elaborar un plan detallado hay que saber con precisión, qué es lo que se va a construir.
- La gestión de proyectos es la profesión que comprende las áreas de conocimiento necesarias para planificar, gestionar la ejecución del trabajo planificado, detectar y corregir las desviaciones.
Sin embargo para la gestión de proyectos adaptable o ágil, las fases no son fases, sino actividades que se desarrollan durante todo el ciclo de vida, a demanda según las circunstancias. El diseño, por ejemplo no es la fase que se realiza después de los requisitos. El diseño, como el descubrimiento de los requisitos, o la codificación y pruebas son actividades que se ejecutan según se van necesitando, a lo largo de iteraciones cortas.
Los requisitos no se conocen de forma detallada al comenzar. La comunicación con el cliente, el análisis y la interacción con los resultados de cada iteración los irán descubriendo.
Las fechas no son resultado de una planificación, sino restricciones de negocio. La garantía del resultado no se confía a los procesos sino a la excelencia técnica y a la responsabilidad del equipo.
La existencia de estos dos enfoques para la gestión de proyectos ocasiona:
- Discusiones de caracter fundamentalista entre defensores de ambos "bandos".
- Despistes y desaguisados al aplicarlos en las organizaciones y en los proyectos que por simpatías, corazonadas o asesoramientos poco objetivos adoptan tal cual modelos poco apropiados.
Algunas cuestiones que ayudan a dar una perspectiva objetiva sobre la utilidad, y ámbito de cada marco:
El software no resulta comparable a la materia prima de otras ingenierías.
El software no es físico, y los sistemas de soft, a diferencia de los artefactos físicos son muy maleables. Por eso es tendencioso presuponer una "talla única" de gestión válida para cualquier sistema y establecer un paralelismo transitivo de métodos que por ser apropiados para la construcción de edificios o aviones, también lo son para desarrollar software.
A nadie se le ocurre comenzar la construcción de un edificio sin saber cuál será exactamente el nº de plantas, o la superficie de éstas; o desarrollar una embarcación básica, e ir ampliando y modificando sus características, a medida que por el uso las van descubriendo los usuarios.
Sin embargo con el software esto es posible.
La capacidad de fertilización que sobre el concepto inicial del producto da el ver, tocar y jugar con un prototipo, con un fragmento de la obra, descubre posibilidades valiosas para el producto, que de otra forma difícilmente podrían haber sido incluidas en una descripción inicial.
La cuestión es: ¿cómo de caro resulta construir poco a poco, realizando "prototipos" que retro-enriquecen la visión del producto?.
Si puedo:
- Poner en contacto directo a desarrolladores y usuarios.
- Conseguir que formen un equipo excelente y motivado.
- Conseguir que toquen, interactúen y vean partes operativas del producto en fases tempranas, y enriquezcan el concepto y valor del producto.
Entonces puedo lograr productos con mayor innovación y con un valor superior al que el que habría conseguido a través de una obtención detallada de requisitos inicial y cerrada.
"Preferimos el software que funciona a la documentación exhaustiva" (agilemanifesto.org)
- La cuestión no es decidir cuál es el mejor modelo para los sistemas de software, sino para "este" sistema de software, con sus características determinadas:
- Grado de incertidumbre del escenario tecnológico sobre el que se desarrolla.
- Grado de inestabilidad del entorno de mercado del cliente.
- Nitidez de la visión del producto.
- Nivel de valor que por innovación necesita el cliente.
- Estructura y factores sociales de las organizaciones adquirientes y suministradora.
- etc.
Si de lo que se trata es del programa para la gestión de un producto bancario, archiconocido, del que se pueden saber extraer y analizar todos sus requisitos al comenzar el proyecto, y para el que el cliente no espera un valor de innovación, sino eficiencia y predecibilidad de desarrollo; por muy software que sea, lo más acertado será conducir el proyecto con un modelo de gestión clásico predictivo. Blogalaxia Tags: requisitos desarrollo+de+software ingeniería+del+software software+engineering
|
Suscripción RSS 
