Como se puede deducir de lo dicho hasta ahora, un proyecto de desarrollo requiere un cambio constante. El modelo de desarrollo en cascada intenta evitar el cambio, fijando de forma temprana los requerimientos del sistema. En cambio, los modelos de desarrollo iterativos intentan adaptarse a este cambio, de ah í su idoneidad para el desarrollo de programas.

Hay varios modelos de desarrollo iterativos. Entre ellos podemos destacar el “Unified Process” y su variante el “Rational Unified Process”, que son estándares actuales a nivel internacional. Un modelo iterativo nuevo que ha surgido con fuerza últimamente es el “Extreme Programming (XP)”. Cabe mencionar también el modelo llamado “Feature Driven Development”.

Explicar alguno de estos procesos requeriría mucho más espacio del que tenemos aquí. Sin embargo, nos centraremos en las características generales y más importantes. Para mayor ampliación, el lector puede buscar en Internet o bien contratar alguno de los cursos de Aurum Solutions.

Los modelos iterativos se basan en dividir el proyecto de desarrollo en varias etapas, llamadas iteraciones. Las iteraciones son cortas (unas cuantas semanas, excepto en proyectos enormes) y su duración es fija (no puede alargarse: si hay retrasos, estos se incluyen en otra iteración).

Figura 2. Un modelo de desarrollo iterativo

La idea central es que, en cada una de esas iteraciones, se construye una parte pequeña del sistema (esto se llama a veces “desarrollo incremental”). Para esa parte del sistema, se realiza todo el proceso: análisis, diseño, programación y pruebas. Se acaba la iteración con un ejecutable que incluye todas las partes del sistema construidas hasta el momento. Los aspectos del sistema con más riesgo (por ejemplo, la arquitectura) se construyen en las primeras iteraciones. El esquema de un modelo iterativo se muestra gráficamente en la figura 2.

Las ventajas de este tipo de modelo son las siguientes:

1. Flexibilidad. Los requerimientos no quedan totalmente fijados hasta el final del proyecto de desarrollo. Por ello, se pueden realizar cambios de forma flexible. Por una parte, el conocimiento que se adquiere en una iteración sirve para plantear de forma más realista los requerimientos de la siguiente. Por otra parte, este conocimiento nos puede hacer reformar partes del sistema construidas en iteraciones anteriores. En una palabra, todos los documentos del sistema (requerimientos, diseño y código) no son rígidos sino que pueden cambiarse durante todo el proceso de desarrollo. (Típicamente suelen ser modificados en mayor medida en las primeras iteraciones y en menor medida en las últimas).

2. Mitigación de riesgos. Como las pruebas se hacen desde el principio del proyecto, puede determinarse la viabilidad o eficiencia de las decisiones de diseño. Además, los elementos con más riesgo se tratan en las primeras iteraciones, con lo cual se puede implementar una mitigación de riesgos más temprana y exitosa.

Retroalimentación. Como hay ejecutables desde el mismo comienzo del proyecto, el cliente puede examinarlos y proponer los cambios que necesita para su negocio. También los desarrolladores tienen una rápida retroalimentación de lo que funciona y lo que no, ya que las pruebas se realizan desde el comienzo mismo del proyecto y no se debe esperar al final para hacer las modificaciones necesarias.

Como consecuencia, un modelo de desarrollo iterativo es condición necesaria (aunque no suficiente) para la correcta ejecución de un proceso de desarrollo de software. En el mencionado estudio de dos años sobre proyectos de desarrollo exitosos ([4]), se determinó que el primer factor de éxito para un proyecto de desarrollo es adoptar un modelo iterativo, en vez de un modelo en cascada.

En este artículo sólo hemos examinado la superficie de los modelos iterativos. Un estudio más profundo revelaría una serie de aspectos de suma importancia que no han podido incluirse aquí. Sin embargo, a pesar de la limitación del espacio, se confía en haber proporcionado al lector una idea general de qué tipo de modelo de desarrollo es el más conveniente para su empresa y fomentado la inquietud de seguir informándose con más amplitud sobre ello.

Referencias bibliográficas.

[1] Jones, C. Patterns of Software Systems Failure And Success. International Thomson Publishing, Ene. 1996.
[2] Jones, C. Applied Software Measurement, NY: McGraw-Hill
[3] Boehm, B. and Papaccio, P. 1988 Understanding and Controlling Software Costs. IEEE Transactions and Software Engineering, Oct 1998.
[4]MacCormak, A. Product-Development Practices That Work. MIT Sloan Management Review. Volume 42, Number 2.

Compruebe la calidad de nuestro desarrollo offshore.
Aurum Solutions tiene experiencia en desarrollo offshore en J2EE y .NET de alta calidad y reducidos costos para empresas europeas y norteamericanas. Conozca nuestro desarrollo offshore haciendo clic aquí o en la página Web ../../offshore.html.

Cursos de Aurum Solutions relacionados con el tema de este artículo:
“Gestión de proyectos informáticos”.
“Análisis y diseño orientado a objetos”.

Nota de copyright: Este documento puede ser impreso, copiado y utilizado en cualquier forma que se considere conveniente, siempre que se respete su integridad, el nombre de su autor y el enlace ../../index.html a la empresa Aurum Solutions, S.A. de C.V.