RESUMEN

PROCESO
UNIFICADO
 Modelo de Proceso Unificado
Llamado también Proceso Unificado de Desarrollo Software o simplemente Proceso Unificado es un
marco de desarrollo de software que se caracteriza por estar dirigido por casos de uso, centrado en la
arquitectura y por ser iterativo e incremental.

No es solo un proceso, sino un marco de trabajo extensible que puede ser adaptado a organizaciones o
proyectos específicos que constituye la metodología estándar más utilizada para el análisis, implementación y
documentación de sistemas orientados a objetos.

Se usa para describir el proceso genérico que incluye aquellos elementos que son comunes a la mayoría de los
refinamientos existentes. También permite evitar problemas legales ya que es una marca registrada por IBM.

El primer libro sobre el tema se denominó, en su versión española, El Proceso Unificado de Desarrollo de
Software (ISBN 84-7829-036-2) y fue publicado en 1999 por Ivar Jacobson, Grady Booch y James Rumbaugh,
conocidos también por ser los desarrolladores del UML (Lenguaje Unificado de Modelado). Desde entonces los
autores que publican libros sobre el tema y que no están afiliados a Rational utilizan el término Proceso
Unificado, mientras que los autores que pertenecen a Rational favorecen el nombre de Proceso Unificado de
Rational.

 Características

 Iterativo e Incremental

El Proceso Unificado es un marco de desarrollo iterativo e incremental compuesto de cuatro fases

denominadas Inicio, Elaboración, Construcción y Transición. Cada una de estas fases es a su vez dividida
en una serie de iteraciones. Estas iteraciones ofrecen como resultado un incremento del producto desarrollado
que añade o mejora las funcionalidades del sistema en desarrollo.

Cada una de estas iteraciones se divide a su vez en una serie de disciplinas que recuerdan a las definidas en
el ciclo de vida clásico: Análisis de requisitos, Diseño, Implementación y Prueba. Aunque todas las
iteraciones suelen incluir trabajo en casi todas las disciplinas, el grado de esfuerzo dentro de cada una de ellas
varía a lo largo del proyecto.

 Dirigido por los casos de uso

En el Proceso Unificado los casos de uso se utilizan para capturar los requisitos funcionales y para definir los
contenidos de las iteraciones. La idea es que cada iteración tome un conjunto de casos de uso o escenarios y
desarrolle todo el camino a través de las distintas disciplinas: diseño, implementación, prueba, etc.

 Centrado en la arquitectura

El Proceso Unificado asume que no existe un modelo único que cubra todos los aspectos del sistema. Por
dicho motivo existen múltiples modelos y vistas que definen la arquitectura de software de un sistema.

 Enfocado en los riesgos

El Proceso Unificado requiere que el equipo del proyecto se centre en identificar los riesgos críticos en una
etapa temprana del ciclo de vida. Los resultados de cada iteración, en especial los de la fase de Elaboración,
deben ser seleccionados en un orden que asegure que los riesgos principales son considerados primero.
 Fases

 Establece oportunidad y alcance

 Identifica las entidades externas o actores con las que se trata
 Identifica los casos de uso

Comprende dos aspectos importantes por los cuales se establecen las disciplinas:

Proceso:

Las etapas de esta sección son:

 Modelado de negocio
 Requisitos
 Análisis y Diseño
 Implementación
 Pruebas
 Despliegue

Soporte:

En esta parte nos encontramos con las siguientes etapas:

 Gestión del cambio y configuraciones

 Gestión del proyecto
 Entorno

La estructura dinámica del modelo de proceso unificado es la que permite que éste sea un proceso de
desarrollo fundamentalmente iterativo, y en esta parte se ven inmersas las 4 fases descritas anteriormente:

Inicio(También llamado Incepción o Concepción)

Elaboración
Desarrollo(También llamado Implementación, Construcción)
Cierre (También llamado Transición)

 Fase de Inicio

Esta fase tiene como propósito definir y acordar el alcance del proyecto, identificar los riesgos asociados al
proyecto, proponer una visión muy general de la arquitectura de software y producir el plan de las fases y el de
iteraciones posteriores.

 Fase de elaboración

Se seleccionan los casos de uso que permiten definir la arquitectura base del sistema y se desarrollaran en
esta fase, se realiza la especificación de los casos de uso seleccionados y el primer análisis del dominio del
problema, se diseña la solución preliminar.

 Fase de Desarrollo o Construcción

El propósito de esta fase es completar la funcionalidad del sistema, para ello se deben clarificar los requisitos
pendientes, administrar los cambios de acuerdo a las evaluaciones realizados por los usuarios y se realizan las
mejoras para el proyecto.

 Fase de Cierre o Transición

El propósito de esta fase es asegurar que el software esté disponible para los usuarios finales, ajustar los
errores y defectos encontrados en las pruebas de aceptación, capacitar a los usuarios y proveer el soporte
técnico necesario. Se debe verificar que el producto cumpla con las especificaciones entregadas por las
personas involucradas en el proyecto.
 Principios de desarrollo

Está basado en seis principios claves que son los siguientes:

 Adaptar el proceso

El proceso deberá adaptarse a las características propias del proyecto u organización. El tamaño del mismo,
así como su tipo o las regulaciones que lo condicionen, influirán en su diseño específico. También se deberá
tener en cuenta el alcance del proyecto en un área sub formal.

 Equilibrar prioridades

Los requisitos de los diversos participantes pueden ser diferentes, contradictorios o disputarse recursos
limitados. Debe encontrarse un equilibrio que satisfaga los deseos de todos. Gracias a este equilibrio se podrán
corregir desacuerdos que surjan en el futuro.

 Demostrar valor iterativamente

Los proyectos se entregan, aunque sea de un modo interno, en etapas iteradas. En cada iteración se analiza la
opinión de los inversores, la estabilidad y calidad del producto, y se refina la dirección del proyecto así como
también los riesgos involucrados.

 Colaboración entre equipos

El desarrollo de software no lo hace una única persona sino múltiples equipos. Debe haber una comunicación
fluida para coordinar requisitos, desarrollo, evaluaciones, planes, resultados, etc.

 Elevar el nivel de abstracción

Este principio dominante motiva el uso de conceptos reutilizables tales como patrón del software, lenguajes o
marcos de referencia (frameworks). Esto evita que los ingenieros de software vayan directamente de los
requisitos a la codificación de software a la medida del cliente, sin saber con certeza qué codificar para
satisfacer de la mejor manera los requisitos y sin comenzar desde un principio pensando en la reutilización del
código. Un alto nivel de abstracción también permite discusiones sobre diversos niveles y soluciones
arquitectónicas. Éstas se pueden acompañar por las representaciones visuales de la arquitectura, por ejemplo
con el lenguaje UML.

 Enfocarse en la calidad

El control de calidad no debe realizarse al final de cada iteración, sino en todos los aspectos de la producción.
El aseguramiento de la calidad forma parte del proceso de desarrollo y no de un grupo independiente.

 Disciplinas o Modelos

 Modelo de casos de uso.- representa los requisitos funcionales del sistema.

 Modelo de análisis.- representa el diseño de las ideas.
 Modelo de diseño.- establece el vocabulario del problema y de su solución.
 Modelo de implementación.- define los elementos a ensamblar y el sistema físico.
 Modelo de distribución.- define la topología hardware para la ejecución del sistema.
 Modelo de pruebas.- define cómo validar y verificar el sistema.
 Ciclo de vida

En la Figura nos muestra cómo varía el esfuerzo asociado a las disciplinas s egún la fase e n la que se
encuentre el proyecto.

Es una implementación del Desarrollo en espiral que organiza las tareas en fases e iteraciones.

Divide el proceso en cuatro fases, dentro de las cuales se realizan varias iteraciones en número variable según
el proyecto y en las que se hace un mayor o menor hincapié en las distintas actividades.

Las primeras iteraciones (en las fases de Inicio y Elaboración) se enfocan hacia la comprensión del problema y
la tecnología, la delimitación del ámbito del proyecto, la eliminación de los riesgos críticos, y al establecimiento
de una Línea Base de la arquitectura.

Durante la fase de inicio las iteraciones hacen mayor énfasis en actividades de modelado del negocio y de
requisitos.

En la fase de elaboración, las iteraciones se orientan al desarrollo de la Línea Base de la arquitectura, abarcan
más los flujos de trabajo de requisitos, modelo de negocios, análisis, diseño y una parte de implementación
orientado a la Línea Base de la arquitectura.

En la fase de construcción, se lleva a cabo la construcción del producto por medio de una serie de iteraciones.

Para cada iteración se selecciona algunos Casos de Uso, se refina su análisis y diseño y se procede a su
implementación y pruebas. Se realiza una pequeña cascada para cada ciclo. Se realizan tantas iteraciones
hasta que se termine la implementación de la nueva versión del producto.

En la fase de transición se pretende garantizar que se tiene un producto preparado para su entrega a la
comunidad de usuarios.

Como se puede observar en cada fase participan todas las disciplinas, pero que dependiendo de la fase el
esfuerzo dedicado a una disciplina varía.