Proceso Unificado de Desarrollo

Este recurso de aprendizaje es una lección creada originalmente como material didáctico del proyecto de aprendizaje Dirección y Gestión de Proyectos y Sistemas Informáticos.

El proceso unificado de desarrollo es un tipo de metodología tradicional empleada en el desarrollo de software. Algunas implementaciones conocidas son el Open Unified Process (UOP) y el Rational Unified Process (RUP), siendo esta última la más conocida.

Introducción

El objetivo del llamado Rational Unified Process® (RUP) de IBM, la implementación más popular del Proceso Unificado de Desarrollo, es establecer un modelo de proceso (un marco de trabajo, digamos) en el que desarrollar software de calidad y con rigor.

Este modelo de proceso se asienta en un conjunto subyacente de filosofías y principios para conseguir un desarrollo de software correcto, proporciona una infraestructura de bloques de construcción del proceso y de contenidos reutilizables, y presenta un método con un lenguaje preciso con el que definir todas las partes del proceso.

Características principales

Se trata de un modelo de proceso de desarrollo de software "pesado" o tradicional, con estas características principales:

• Está dirigido por los llamados "casos de uso"
• Es centrado en la "arquitectura", como espina dorsal del software
• Es iterativo e incremental

Algunas de las metas que se buscan al usar este modelo de proceso son:

• Adaptar el proceso a las necesidades de la organización
• Mantener un equilibrio entre las distintas prioridades
• Permitir colaborar entre equipos
• Demostrar valor iterativamente (una iteración es una secuencia de actividades, con un plan de línea base y unos criterios de evaluación, que resulta en una entrega)
• Elevar el valor de la abstracción que se realiza al diseñar software
• Enfocarse continuamente en la calidad (algo muy habitual en las metodologías más "pesadas" o tradicionales)

Fases

Estas son las fases en que se divide cada uno de los ciclos de vida por los que pasa un proyecto software:

• Concepción: El alcance de un acuerdo entre todos los interesados respecto a los objetivos (de este ciclo) del proyecto. Los objetivos en esta fase son:
  • Establecer el ámbito de software y las condiciones de los límites del proyecto.
  • Discriminar los casos de uso más importantes del sistema.
  • Estimar el costo global y la planificación de todo el proyecto.
  • Estimar los riesgos potenciales.
  • Preparar el entorno de soporte para el proyecto.

• Elaboración: El establecimiento de una línea base para la arquitectura del sistema. Los objetivos en esta fase son:
  • Garantizar que la arquitectura, los requisitos y los planes son lo bastante estables, y que los riesgos están suficientemente mitigados.
  • Tratar todos los riesgos arquitectónicamente significativos del proyecto.
  • Producir un prototipo de componentes de calidad de producción.
  • Establecer un entorno de soporte.

• Construcción: La finalización del desarrollo del sistema basado en la arquitectura de línea base anterior. Los objetivos en esta fase son:
  • Minimizar los costos de desarrollo optimizando los recursos y evitando las reconstrucciones y los fragmentos innecesarios.
  • Conseguir la calidad adecuada de forma rápida y práctica.
  • Conseguir versiones útiles (alfa, beta y otros releases de prueba) de forma rápida y práctica.
  • Completar el análisis, diseño, desarrollo y prueba de toda la funcionalidad necesaria.
  • Desarrollar de forma iterativa e incremental un producto.

• Transición: La garantía de que el software está operativo y es de utilidad para los usuarios. Los objetivos en esta fase son:
  • Ejecutar el despliegue.
  • Prueba de versión beta para validar el nuevo sistema contra las expectativas del usuario.
  • Convertir bases de datos operativas.
  • Formación de usuarios y mantenedores.
  • Despliegue de la fuerza de marketing, distribución y ventas.
  • Alcanzar la capacidad de soporte propio del usuario.

Componentes y servicios

Arquitectura orientada a servicios

El Proceso Unificado es un modelo basado en componentes, y también podemos decir que tiene una configuración modular cuando el proyecto cuenta con una arquitectura orientada a servicios (Service Oriented Architecture o SOA).

Cuando trabajamos con SOA:

• El proceso se enfoca en el Análisis y Diseño de Servicios
• Todas las actividades del RUP deben ser reestructuradas para soportar SOA (aunque hay muchos elementos en común ya)

SOA define un conjunto de técnicas y productos de trabajo, tal como aparece en la figura de esta sección, para definir modelos de solución de extremo a extremo.

Casos de uso

Los casos de uso son una técnica, muy característica de este modelo de proceso, con la que especificar el comportamiento del sistema.

Un Caso de Uso es una secuencia de 
interacciones  entre un sistema y 
alguien o algo que usa alguno 
de sus servicios.

Si vemos el software como un sistema que ofrece a su entorno una serie de servicios, un caso de uso es una forma de expresar la manera en que un usuario o un sistema externo (llamado 'actor') lo utiliza.

Los casos de uso no describen ninguna funcionalidad interna (oculta al exterior) del sistema, ni explican cómo se implementará. Simplemente muestran los pasos que el actor sigue para realizar una tarea.

La técnica de caso de uso es muy útil en el desarrollo de sistemas interactivos, ya que expresa la intención que tiene el actor al hacer uso del sistema. Como técnica de extracción de requisitos permite que el analista se centre en las necesidades del usuario (¿qué espera éste lograr al utilizar el sistema?), evitando que los desarrolladores dirijan la funcionalidad del nuevo sistema basándose solamente en criterios tecnológicos. A su vez, mientras se obtienen los requisitos, el analista se concentra en las tareas centrales del usuario, las más importantes, describiendo por lo tanto los casos de uso que mayor valor aportan al negocio. Esto facilita luego la priorización de estos requisitos.

Los casos de uso pueden ser útiles para establecer requisitos de comportamiento, pero no establecen completamente los requisitos funcionales ni permiten determinar los requisitos no funcionales. Los casos de uso deben complementarse con información adicional como reglas de negocio, requisitos no funcionales, diccionario de datos, etc. que complementa los requisitos formales del sistema. De hecho cada caso de uso considerado 'crítico' debería tener una serie de requisitos no funcionales que especifiquen a fondo el comportamiento asociado.

Ventajas y recomendaciones de uso

Cuando utilizar RUP

Cualquier Proceso Unificado, y concretamente RUP, proporciona un entorno de proceso bastante configurable y basado en fuertes estándares. Este entorno de proceso permite establecer un método personalizado para cada organización, configurándolo para satisfacer las necesidades exclusivas de cada proyecto.

El Proceso Unificado es una recopilación de buenas prácticas de Ingeniería del Software que se están mejorando continuamente de forma regular para reflejar los cambios que sufre la industria. Además, pretende obtener productos de muy alta calidad, si bien sus diferentes características como el estar formado por varias fases, con múltiples iteraciones por fase, etc. pueden provocar que el proceso sea costoso y no sea adaptable para proyectos de pequeña escala. Aún así, el hecho de que este modelo siga un esquema iterativo e incremental permite bastante flexibilidad y adaptación a proyectos menores, en caso de que quisiéramos usarlo.

Este modelo de proceso está pensado para usarse desde el principio de un nuevo proyecto, y puede seguir utilizándose en todos los ciclos de desarrollo siguientes, mucho tiempo después de que el proyecto inicial haya terminado.

El modelo tiene en cuenta:

• Los propósitos empresariales, la visión, el ámbito y los riesgos del proyecto
• La cantidad de esfuerzo requerida para el desarrollo de software
• La estructura del ciclo vital del proyecto (número de iteraciones, duración total del proyecto y de cada una de sus fases)

Conclusiones

En resumidas cuentas, podemos decir que el Proceso Unificado es un importante marco de referencia en Ingeniería de Software con el que definir, implementar y distribuir aplicaciones de software.

Presenta un modelo dividido en 4 fases:

• Concepcion: Sobretodo define el alcance del proyecto
• Elaboración: Especificación formal, análisis y diseño
• Construcción: Implementación
• Transición: Cierre del proyecto y paso a producción

Las ventajas de este modelo son la reducción de riesgos en el proyecto, la garantía de calidad, y la integración entre lo que es propiamente desarrollo con mantenimiento de software (a base de ir iterando en cada fase, combinando actividades de uno y otro tipo).

Como desventajas, podemos señalar que requiere una gran previsión sobre lo que va a ocurrir (para poder controlarlo) y que genera abundante trabajo adicional (y costes asociados) de documentación y comunicación, con lo que no suele resultar práctico para proyectos pequeños.

Lecciones relacionadas

• Procesos de desarrollo software
• Metodologías pesadas de desarrollo software
• Metodologías ágiles de desarrollo software
• Scrum

Referencias

• «El proceso de desarrollo de software». Consultado el 27 de noviembre de 2014. 
• Sparks, Geoffrey. «Una introducción al UML». Consultado el 27 de noviembre de 2014. 
• Jcobson, Ivar. El proceso unificado de desarrollo de software. 
• Carrillo Ramos, Anay. Enseñanza de la metodología RUP de Ingeniería de Software. 

Participantes activos

• Carlos Quinto
• Victor Mariscal
• Ricardo Mendoza
• Ignacio Melendrez
• Esteban.alej