Proceso Unificado de Desarrollo

Proceso Unificado de Desarrollo (UP del Ingles Unified Process)

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 metodos de analisis y diseno orientados a objetos que surgio a finales de la decada de los 1980 y principios de la siguiente. El UML unifica, sobre todo, los metodos 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 administracion de objetos).

¿Por qué analizar y diseñar?

En resumidas cuentas, la cuestion fundamental del desarrollo del software es la escritura del código. Después de todo, los diagramas son solo imagenes bonitas. Ningun usuario va a agradecer la belleza de los dibujos; lo que el usuario quiere es software que funcione (UML Gota a Gota, Addison Wesley, Pag 7). Por lo tanto, cuando considere usar el UML es importante preguntarse por qué lo hará y como le ayudara a usted cuando llegue el momento de escribir el codigo. No existe una evidencia empirica adecuada que demuestre si estas tecnicas son buenas o malas; Pero lo que si es cierto es que es de considerable ayuda para las etapas de mantenimiento en proyectos de mediana/avanzada envergadura.

         La metodología de UP, es un método iterativo de diseño de software que describe cómo desarrollar software de forma eficaz, utilizando técnicas probadas en la industria.

 El Proceso Unificado de Desarrollo de 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, enfocado en el riesgo, y por ser iterativo e incremental.

El Proceso Unificado no es simplemente un proceso, sino un marco de trabajo extensible que puede ser adaptado a organizaciones o proyectos específicos.

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. Es una metodología orientada a conducir el proceso de desarrollo de software en sus aspectos técnicos; los flujos y productos de trabajo de UP no incluyen la administración del proyecto.

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 esta realizando una especificación previa excesiva, lo que responde más a un modelo en cascada.

• Objetivos:   

o   Establecer una justificación para el proyecto.  
o   Establecer el ámbito del proyecto. 
o   Esbozar los casos de uso y los requisitos clave que dirigirán  las decisiones de diseño.
o   Esbozar las arquitecturas candidatas. 
o   Identificar riesgos.
o   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.

• Base de Arquitectura Ejecutable:

·  La arquitectura se valida a través de la implementación de una Base de   Arquitectura Ejecutable: 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.

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).

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.

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.

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.

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.                         

Estructura del Proceso Unificado

 



 Arquitectura lógica de tres capas de una aplicación cliente/servidor

http://ingsoftware072301.obolog.com/up-proceso-unificado-2010775

http://es.wikipedia.org/wiki/Proceso_Unificado