A menudo los nuevos sistemas se construyen para soportar funciones de negocio inéditas, de las

que se sabe cual es su objetivo pero se desconocen muchas de sus características. El pretender
“congelar” todos los requisitos que necesitará cumplir el nuevo sistema en las primeras etápas del
desarrollo del software se convierte con fercuencia en una perdida de tiempo cuando los requisitos
cambian para adaptarse a nuevas situaciones, en la mayor parte de los casos imposibles de preveer.

En más de una ocasión el nuevo sistema va a constituir la parte “visible” de la nueva función de
negocio que se pretende implantar en la organización, de tal forma que los diseñadores de la
función de negocio irán concretando la forma que debe tomar ésta a medida que se va avanzando en
el desarrollo del software. El propio desarrollo del software servirá para evaluar entre las distintas
posibilidades que se puedan presentar. El “feedback” de los usuarios al usar el nuevo sistema
constituye también una importante fuente de requisitos.

Durante todas las fases del desarrollo aparecen nuevos requisitos que es necesario valorar; en
algunos casos se trata de nuevas funcionalidades no previstas con anterioridad que mejorarían
notablemente el resultado del proyecto; en otros casos se trata de funcionalidades que se convierten
en imprescindibles, por motivos de arquitectura del sitema por ejemplo, de tal forma que no se
puede renuciar a su implementación. Incluso en la etápa de implantación no es infrecuente tener que
atender a la aparición de nuevos requisitos derivados de cambios en la arquitectura de servidores,
comunicaciones, la incorporación de nuevo software de base inexistente en las etapas anteriores del
desarrollo del sistema, etc.

Los documentos de requisitos contienen definiciones textuales y gráficos no normalizados. Ambos

elementos permiten un elevado grado de ambigüedad, que en muchos casos no se aprecia hasta que
el usuario usa el nuevo sistema. Haciendose necesario revisar la definición de los requisitos en ese
momento.

Un enfoque de desarrollo iterativo orientado al manejo del riesgo, con la participación activa de los
usuarios en todas las etápas del desarrollo y el uso de notaciones estandarizadas para la descripción
de los sistemas podría mejorar la calidad del proceso.

El modelo en espiral propuesto por Barry Boehm en 1985 se organiza en iteraciones sucesivas que
dan como resultado prototipos cada vez más evolucionados. En el inicio de cada iteración se
evaluan los riesgos que se van a mitigar en ese ciclo.
El Proceso Unificado de Rational (RUP) ideado por Booch, Rumbaugh y Jacobson propugna un
modelo iteractivo, basado en el manejo del riesgo, centrado en la arquitectura del software y
dirigido por casos de uso.
Se establecen cuatro fases en el ciclo de vida de RUP:
1. Iniciación: Se establece el alcance del proyecto, se analizan los riesgos y se realiza la
planificación general basandose en los casos de uso.
2. Elaboración: Se define la arquitectura del sistema y se comienza a ejecutar el plan de manjo
del riesgo.
3. Construcción: Se completa la funcionalidad del sistema.
4. Transicción: Se realizan las tareas necesarias para proporcionar el sistema a los usuarios
finales.
5. Para realizar cada una de las fases se establecerán el número de iteraciones que se considere
necesario.
Dentro de cada una de las fases se realizan en mayor o menor medida cada uno de los flujos de de
trabajo de los que consta el proceso:
1. Modelo de negocio: Describe la estructura y la dinámica de la organización.
2. Requisitos: Define los requisitos a través de casos de uso.
3. Analisis y diseño: Describe las distintas vistas de la arquitectura con UML (Lenguaje
Unificado de Modelado)
4. Implementación : Construye el sistema usando los lengajes y la arquitectura seleccionados.
5. Pruebas: Describe los casos de prueba, los procedimientos y las métricas para evaluación de
defectos.
6. Despliegue: Define la configuración del sistema.
7. Gestión de configuraciones: Controla los cambios y mantiene la integridad de los elementos
del proyecto.
8. Gestión del proyecto: Describe las estrategias de trabajo durante el proyecto.
9. Entorno. Cubre la infraestructura necesaria para desarrollar el sistema.

El gráfico de “jorobas” carácterístico de RUP muestra el enfasis que se pone en los distintos flujos
de trabajo durante el desarrollo de las iteraciones de cada fase.

En los últimos años han proliferado metodologías basadas de alguna manera en los modelos
iteractivos e incrementales descritos, que se han venido en llamar “ágiles”. La más conocida es XP
(Programación eXtrema) ampliamente aceptada en los entornos de desarrollo de código abierto
(open source).