Un poco de RUP

Entendiendo por proceso de desarrollo de software al conjunto de actividades necesarias para transformar los requisitos de un usuario en un sistema software podríamos decir que RUP es en la actualidad el proceso de desarrollo más completo, documentado e implantado.

Los aspectos definitorios de RUP se pueden resumir en 3:

· Dirigido por casos de uso

· Centrado en la Arquitectura

· Iterativo e incremental

FASES RUP:

· Concepción: su objetivo es establecer los requisitos de negocio que cubrirá el sistema identificando todas las entidades que interactúan con el sistema (personas, sistemas, etc.) y hacer una valoración de la viabilidad del proyecto.

· Elaboración: su objetivo es entender muy bien el problema desde el punto de vista del equipo de desarrollo. Lleva consigo la elaboración de la arquitectura marco del sistema y el diseño de la solución técnica, así como determinar el plan del proyecto e identificar los riesgos fundamentales del mismo.

Al final de la fase se tiene definida la arquitectura, el modelo de requisitos del sistema empleando los diagramas de casos de uso especificados en lenguaje UML, el plan de desarrollo y los estándares de calidad que se han de seguir en el proyecto o las herramientas que se han de emplear durante el transcurso del mismo.

· Construcción. En esta fase se profundiza en el diseño de los componentes y de manera iterativa se van añadiendo las funcionalidades al software a medida que se construyen y prueban, permitiendo a la vez que se puedan ir incorporando cambios.

Se podrán planificar entregas al final de cada iteración, momento en el que se recoge feedback del usuario final y en el que se proponen cambios. Tras el análisis del impacto que suponen los mismos se decide si el mejor momento en que incorporar dichos cambios al sistema. Al final de la fase se tiene un sistema completamente operativo y la documentación para entregar a los usuarios.

· Transición. La fase final del RUP se ocupa del traslado del software desde los entornos de desarrollo a los entornos de producción, en los que el usuario final hará uso del sistema. Dependiendo del tipo de proyecto podrá requerir de entornos intermedios (preproducción o de aceptación por usuarios, etc.) para su correcta validación, antes de su pase a producción.

Cada fase en RUP Cada fase en RUP puede descomponerse en iteraciones. El objetivo de cada iteración es desarrollar algún producto de software que funcione, que pueda ser mostrado y resulte significativo a todos los implicados (tanto internos como externos). En general, el software desarrollado por una iteración debería abarcar todos o la mayor parte de los subsistemas del proyecto. Se realizan todas las actividades (flujos del trabajo) del proceso.

Hay 2 Tipos de iteraciones:

· Iteraciones refinadoras: Amplían el nivel de detalle o refinan el producto de la iteración anterior.

· Iteraciones aditivas: Añaden funcionalidad, habitualmente se concretan mediante una selección de casos de uso.

FLUJOS DE TRABAJO O DISCIPLINAS RUP

Cada fase se completa con la realización de varias iteraciones en las que se desarrollan una serie de actividades, que el modelo RUP clasifica en 9 disciplinas que tienen más o menos importancia en función de lo cerca que se esté o no de la finalización del proyecto.

1. Modelado de Negocio:Comprender las necesidades del Negocio.

2. Requisitos:Traducir necesidades del negocio en comportamientos de un sistema automático.

3. Análisis y Diseño: Traducir requisitos en una arquitectura software.

4. Implementación: Crear software que encaje en la arquitectura y realice el comportamiento solicitado.

5. Pruebas:Asegurarse de que el comportamiento solicitado es correcto, y que todo lo solicitado está presente.

6. Configuración y Gestión del Cambio:Mantener traza de las distintas versiones de todos los productos.

7. Gestión del proyecto:Gestionar planificaciones y recursos.

8. Entornos: Establecer y mantener el entorno de desarrollo.

9. Despliegue: Todo aquello necesario para instalar el proyecto.

RESUMEN DEL PROCESO:

RUP EN PROYECTOS PEQUEÑOS Y MEDIOS

Sin embargo debido al gran nivel de detalle requerido en sus artefactos RUP en muchos casos RUP no se considera práctico para proyectos pequeños o cortos.

Por suerte RUP es más que un proceso, es un marco de trabajo genérico que puede y permite (debe) adaptarse a las necesidades de este tipo de proyectos al ser adaptables al contexto y necesidades de las organizaciones

Una de las claves para la aplicación efectiva de RUP en pequeños proyectos es cuidar el subconjunto de artefactos y mantenerlos concisos y libres de cualquier formalismo superfluo. Formalismos, procesos y documentación no son sustitutivos de la disciplina, habilidad o entendimiento.

DIRIGIDO POR CASOS DE USO

Un sistema software ve la luz para dar servicio a sus usuarios. Por tanto, para construir un sistema con éxito debemos conocer lo que sus futuros usuarios necesitan y desean: el término usuario representa alguien o algo (como otro sistema fuera del sistema en consideración) que interactúa con el sistema que estamos desarrollando.

Una interacción de este tipo es un caso de uso (fragmento de funcionalidad del sistema que proporciona al usuario un resultado importante).

Los casos de uso representan los requisitos funcionales. Todos los casos de uso juntos constituyen el modelo de casos de uso, el cual describe la funcionalidad total del sistema.

Los casos de uso no son sólo una herramienta para especificar los requisitos de un sistema. También guían un diseño, implementación y prueba; esto es:

guían el proceso de desarrollo.

además le proporcionan un hilo conductor.

Los casos de uso guían el proceso aunque se desarrollan a la vez que la arquitectura del sistema.

Los casos de uso guían la arquitectura del sistema y la arquitectura del sistema influye en la selección de los casos de uso. Por tanto, la arquitectura del sistema como los casos de uso maduran según avanza el ciclo de desarrollo.

CENTRADO EN LA ARQUITECTURA

El concepto de arquitectura software incluye los aspectos estáticos y dinámicos más significativos del sistema.

La arquitectura se refleja en los casos de uso, también se ve influida por muchos otros factores, como:

· la plataforma en la que tiene que funcionar el software (arquitectura hardware, sistema operativo, sistema de gestión de bases de datos, protocolos para comunicaciones de red),

· los bloques de construcción reutilizables de que se dispone (por ejemplo, un marco de trabajo para interfaces gráficas de usuario),

· consideraciones de implantación,

· sistemas heredados,

· y requisitos no funcionales (por ejemplo, rendimiento, fiabilidad).

La arquitectura es una vista del diseño completo con las características más importantes resaltadas, dejando los detalles de lado.

El valor de una arquitectura depende de las personas que se hayan responsabilizado de su creación

Cómo se relacionan casos de uso y la arquitectura?

Debe haber interacción entre los casos de uso y la arquitectura. En realidad, tanto la arquitectura como los casos de uso deben evolucionar en paralelo.

• Por un lado, los casos de uso deben encajar en la arquitectura cuando se llevan a cabo.
• Por otro lado, la arquitectura debe permitir el desarrollo de todos los casos de uso requeridos, ahora y en el futuro.

ITERATIVO E INCREMENTAL

El desarrollo de un producto software comercial supone un gran esfuerzo que puede durar años.

Es práctico dividir el trabajo en partes más pequeñas o mini-proyectos. Cada mini-proyecto es una iteración que resulta en un incremento.

Las iteraciones hacen referencia a pasos en el flujo de trabajo, y los incrementos, al crecimiento del producto. Para una efectividad máxima, las iteraciones deben estar controladas; esto es, deben seleccionarse y ejecutarse de una forma planificada.

Los desarrolladores basan la selección de lo que se implementará en una iteración en dos factores:

· En primer lugar, la iteración trata de un grupo de casos de uso que juntos amplían la utilidad del producto desarrollado hasta ahora.

· En segundo lugar, la iteración trata los riesgos más importantes . Las iteraciones sucesivas se construyen sobre los artefactos de desarrollo tal como quedaron al final de la última iteración. Al ser mini-proyectos, comienzan con los casos de uso y continúan a través del trabajo de desarrollo subsiguiente, análisis, diseño, implementación y prueba, que termina convirtiendo en código ejecutable los casos de uso que se desarrollaban en la iteración.