domingo, 6 de noviembre de 2016
INTRODUCCIÓN
El objetivo del llamado 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.
Modelo de
desarrollo de Software Unificado
El Proceso Unificado no es simplemente un proceso, sino
un marco de trabajo extensible que puede ser adaptado a organizaciones o
proyectos específicos. De la misma forma, el Proceso Unificado de Rational,
también es un marco de trabajo extensible, por lo que muchas veces resulta
imposible decir si un refinamiento particular del proceso ha sido derivado del
Proceso Unificado o del RUP. Por dicho motivo, los dos nombres suelen
utilizarse para referirse a un mismo concepto.
El nombre Proceso Unificado 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
Proceso Unificado de Rational o RUP son marcas registradas por IBM (desde su compra
de Rational Software Corporation en 2003). 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,
el 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.
El 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. El refinamiento más conocido y documentado del Proceso
Unificado es el Proceso Unificado de Rational o simplemente RUP.
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 (la de inicio puede incluir varias iteraciones en
proyectos grandes). 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
o en cascada: 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. El proceso dirigido por casos de uso es el
rup. Nota: en UP se está Dirigido por requisitos y riesgos de acuerdo con el
Libro UML 2 de ARLOW, Jim que menciona el tema.
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. La analogía
con la construcción es clara, cuando construyes un edificio existen diversos
planos que incluyen los distintos servicios del mismo: electricidad,
fontanería, etc.
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.
Lenguaje unificado de modelado
El Lenguaje unificado de modelado no es el sucesor de la
oleada de métodos de análisis y diseño orientados a objetos que surgió a
finales de la década de los 1980 y principios de la siguiente. El UML unifica,
sobre todo, los métodos de Booch, Rumbaugh, Brühl (OMT) y Jacobson, pero su
alcance ha llegado a formar parte fundamental de la Ingeniería de Software tras
su estandarización en 1997 con el OMG (Object Management Group o Grupo de administración
de objetos).
Vida del Proceso Unificado de
Desarrollo
El Proceso Unificado se repite a lo largo de una serie de
ciclos que constituyen la vida de un sistema. Al final de cada uno de ellos se
obtiene una versión final del producto, que no sólo satisface ciertos casos de
uso, sino que está lista para ser entregada y puesta en producción. En caso de
que fuese necesario publicar otra versión, deberían repetirse los mismos pasos
a lo largo de otro ciclo.
Como se ha comentado en el apartado anterior, cada ciclo
se compone de varias fases, y dentro de cada una de ellas, los directores o los
desarrolladores pueden descomponer adicionalmente el trabajo en iteraciones,
con sus incrementos resultantes. Cada fase termina con un hito, determinado por
la disponibilidad de un conjunto de artefactos, modelos o documentos.
Las iteraciones de cada fase se desarrollan a través de
las actividades de identificación de requisitos, análisis, diseño,
implementación, pruebas e integración.
FASES DE DESARROLLO
Fase de Inicio.
Es la fase más pequeña del proyecto e, idealmente, debe
realizarse también en un periodo de tiempo pequeño (una única iteración). El
hecho de llevar a cabo una fase de inicio muy larga indica que se está
realizando una especificación previa excesiva, lo que responde más a un modelo
en cascada.
Objetivos:
ü Establecer una
justificación para el proyecto.
ü Establecer el ámbito del
proyecto.
ü Esbozar los casos de uso
y los requisitos clave que dirigirán las
decisiones de diseño.
ü Esbozar las
arquitecturas candidatas.
ü Identificar riesgos.
ü Preparar el plan del
proyecto y la estimación de costes.
ü El hito de final de fase
se conoce como Hito Objetivo del Ciclo de Vida.
Fase de Elaboración.
Durante esta fase se capturan la mayoría de los
requisitos del sistema, los objetivos
principales de esta fase serán la identificación de riesgos y establecer y validar
la arquitectura del sistema, la arquitectura se valida a través de la
implementación de una Base de
Arquitectura Ejecutable la cual se trata de una implementación parcial
del sistema que incluye los componentes principales del mismo. Al final de la
fase de elaboración la base de arquitectura ejecutable debe demostrar que
soporta los aspectos clave de la funcionalidad del sistema y que muestra la
conducta adecuada en términos de rendimiento, escalabilidad y coste.
Al final de la
fase se elabora un plan para la fase de construcción. El hito arquitectura del
ciclo de vida marca el final de la fase.
Fase de construcción.
ü Es la fase más larga de
proyecto.
ü El sistema es construido
en base a lo especificado en la fase de elaboración.
ü Las características del
sistema se implementan en una serie de iteraciones cortas y limitadas en el
tiempo.
ü El resultado de cada
iteración es una versión ejecutable de software.
ü El hito de capacidad
operativa inicial marca el final de la fase.
Fase de transición.
En esta fase el sistema es desplegado para los usuarios finales, la
retroalimentación recibida permite incorporar refinamientos al sistema en las
sucesivas iteraciones.
Esta iteración también cubre el entrenamiento de los usuarios para la
utilización del sistema. El hito de lanzamiento del producto marca el final de
la fase.
DISCIPLINAS
Modelado del negocio
ü El objetivo es
establecer un canal de comunicación entre los ingenieros del negocio y los
ingenieros del software.
ü Los ingenieros del software
deben conocer la estructura y dinámica de la organización objetivo (el
cliente), los problemas actuales y sus posibles mejoras.
ü Se plasma en la
identificación del modelo del dominio en el que se visualizan los aspectos
básicos del dominio de aplicación.
Requisitos
El objetivo es describir que es lo que tiene que hacer el sistema y poner a los desarrolladores y al cliente de acuerdo en esta descripción.
El objetivo es describir que es lo que tiene que hacer el sistema y poner a los desarrolladores y al cliente de acuerdo en esta descripción.
Análisis y diseño
ü Describe como el
software será realizado en la fase de implementación.
ü Se plasma en un modelo
de diseño que consiste en una serie de clases (agrupadas en paquetes y
subsistemas) con interfaces bien definidos.
ü También contiene
descripciones de cómo los objetos colaboran para realizar las acciones
incluidas en los casos de uso.
Implementación
Se implementan las clases y objetos en términos de componentes (ficheros fuentes, binarios, ejecutables, entre otros).
Se implementan las clases y objetos en términos de componentes (ficheros fuentes, binarios, ejecutables, entre otros).
Prueba
Se comprueba que el funcionamiento es correcto analizando diversos aspectos: los objetos como unidades, la integración entre objetos, la implementación de todos los requisitos, entre otros.
Se comprueba que el funcionamiento es correcto analizando diversos aspectos: los objetos como unidades, la integración entre objetos, la implementación de todos los requisitos, entre otros.
Despliegue
Se crea la versión externa del producto, se empaqueta, se distribuye y se instala en el lugar de trabajo. También se da asistencia y ayuda a los usuarios.
Se crea la versión externa del producto, se empaqueta, se distribuye y se instala en el lugar de trabajo. También se da asistencia y ayuda a los usuarios.
Gestión de configuraciones y
cambios
ü Gestiona aspectos como
los sistemas de control de versiones.
ü Controla las peticiones
de cambios clasificándolas según su estado (nueva, registrada, aprobada,
asignada, completa, entre otros).
ü Los datos se almacenan
en una base de datos y se pueden obtener informes periódicos.
ü Herramientas como Rational ClearQuest o Bugzilla.
Gestión del proyecto
Encargada de definir los planes del proyecto global, los planes de fase y los planes de iteración.
Encargada de definir los planes del proyecto global, los planes de fase y los planes de iteración.
Entorno
ü Se centra en las
actividades necesarias para configurar el proceso de un proyecto.
ü El objetivo es proveer a
la organización de desarrollo software de un entorno de trabajo (que incluye
procedimientos y herramientas) que soporten al equipo de desarrollo.
Ventajas del modelo
Unificado
Estas son algunas de las ventajas del modelo RUP:
ü Mitigación temprana de
posibles riesgos altos
ü Progreso visible en las
etapas tempranas
ü El conocimiento
adquirido en una iteración puede aplicarse de iteración a iteración
ü Los usuarios están involucrados
continuamente
Desventajas del
modelo Unificado
Estas son algunas de las desventajas del modelo RUP:
ü Por el grado de
complejidad puede no resultar muy adecuado.
ü El RUP es generalmente
mal aplicado en el estilo cascada.
ü Requiere conocimientos
del proceso y de UML
