Vicente Ferrández López
Carlos Ferrando Galiana
Lionel Giró

EL PROCESO UNIFICADO

El Proceso Unificado es un proceso de desarrollo de software, es decir, el conjunto de actividades necesarias para transformar las necesidades de los usuarios en un sistema software.

Para definir “UP” podemos decir que las características que le hacen diferenciarse del resto de procesos son:

1 - Conducido por casos de uso

Los casos de uso son pequeños fragmentos de usabilidad del proceso, en los que se basa para la creacion de modelos de uso. Estos influyen directamente en la elaboracion de requisitos del proyecto. Los casos de uso ayudan al constante desarrollo del proceso y guian al desarrollador en él.

En primer lugar se crean una serie de requisitos funcionales a partir de una simulacion de usabilidad del software, esto creara el Modelo de Casos de Uso.
A continuacion(opcionalmente) se creara el modelo de analisis a partir del Modelo de Casos de Uso. En este se documentan un conjunto de clases que son utilizados para la realizacion de un descripcion de llevada a cabo de los casos de uso del modelo de casos de uso. Las clases son recopilaciones de los roles que se dan en todas las practicas de los casos de uso, consolidandolas y borrando repeticiones innecesarias entre los mismos roles.
Seguidamente se crea el modelo de diseño a partir del modelo de analisis, cogiendo el modelo de analisis como origen principal y adaptandolo a un contexto de implementacion particular. La diferencia entre le modelo de diseño y el modelo de analisis, es que este ultimo, debe adecuarse al entorno de implementacion particular.
Se dan casos en los que las clases se multiplican en una cantidad intangible, de manera que se crean los llamados subsistemas, estos son agrupamientos semanticos de clases, o incluso de otros subsistemas. Su desarrollo puede venir dado por una directa agrupacion de clases previamente identificadas, de manera que se produce un diseño ascendente.
A continuacion, se crea el modelo de implementacion partiendo del modelo de diseño. Los componentes forman el modelo de implementacion, los cuales incluyen todos los ejecutables, codigos fuente, scripts... etc Un componente es una estructura fisica del producto, y como pieza tiene posibilidad de reemplazo, que proporciona y ademas cumple la realizacion de un conjunto de interfaces.
Por ultimo, se realizan las pruebas de los casos de uso, con el fin de verificar que el sistema cumple con los requisitos especificados y ejecuta correctamente las ordenes implementadas. Este esta compuesto por dos protocolos; un procedimiento de prueba, que son las pautas a seguir para llevar a cabo en un caso de prueba la preparacion, ejecucio y evaluacion; un caso de prueba, que es una composicion de entradas de prueba, condiciones de ejecucion y resultados esperados, desarrollados para un objetivo concreto, como el hecho de probar un camino concreto a traves de un caso de uso.

2 - Iterativo

La division de un proyecto en diferentes segmentos es una manera practica de agilizar su desarrollo, cada parte es una iteracio que resulta en un incremento. Las iteraciones hacen referencia a pasos en el flujo de trabajo, y los incrementos a crecimientos en el producto. Las iteraciones deben de tener un control, es decir, deben ser seleccionadas y ejecutadas de forma planificada.
Los criterios que siguen los desarrolladores para clasificar su selección del resultado de cada iteracion son dos:
-La iteracion trata los riesgos mas importantes
-La iteracion trata en grupo de casos de uso que juntos amplian la utilidad del producto desarrollado hasta ahora.
Los desarrolladores del proyecto identifican los casos de uso releveantes y crean un diseño, para implementar dichos casos de uso en cada iteracion. Si la iteracion es satisfactoria con los objetivos establecidos previamente se pasa a la siguiente, en caso contrario se deben revisar las premisas y reorganizar el enfoque inicial.
A continuacion un grafico muestra la cadena de produccion de las iteraciones:

El uso de iteraciones aporta cierto auge derendimiento en el proceso de desarrollo, reduce el riesgo a los costes de un solo incremento, tambien lo reduce de los atrasos temporales, acelera el desarrollo ya que los implicados en el proyecto funcionan de manera mas eficiente al obtener resultados a corto plazo.

3 - Centrado en la arquitectura

La arquitectura del software abarca diferentes decisiones sobre el desarrollo del sw; la organización del sistema de sw, elementos de la composicion estructural, interfaces o comportamientos de subsitemas entre otros.
La arquitectura es necesaria para comprender el sistema, organizar el desarrollo, fomentar la reutilizacion y para evolucionar el sistema. Se desarrolla mediante iteraciones, el resultado de la fase de elaboracion es la base de dicha arquitectura.
La descripcion de la arquitectura es el grupo de modelos que definen la linea base de la arquitectura en la version interna del sistema en el final de la fase de elaboracion. La funcion de la descripcion es el enrutamiento de la plantilla de desarrollo a traves del ciclo de vida del sistema. Consta de cinco partes según el modelo, de casos de uso, de analisis, de diseño de despliegue y de implementacion.

Elementos del proceso Unificado

UP esta formado por diversos elementos que describiremos a continuación de forma superficial:

Fases del UP

Aunque posteriormente hablaremos con mas detalles sobre las fases, superficialmente podemos decir que en el UP  se reconocen las fases de Inicio, Elaboración, Construcción y Transición, en cada una de las cuales se cumplen una o más iteraciones.
El desarrollo es iterativo e incremental, eso quiere decir que en cada iteración se agrega algo más, y el sistema está en continuo crecimiento hasta su entrega. En cada iteración hay análisis de requerimientos, diseño, implementación y verificación, así como puesta a punto y coordinación de todos los artefactos.

1. Inicio: En la fase de inicio se hace un análisis del proyecto de la empresa cliente ("el negocio"), alcance del proyecto, calculos de plazos y costos. Se define la viabilidad del proyecto.

2. Elaboración: En la fase de elabración se produce una implementación iterativa del núcleo central de la aplicación, se resoluciónan los riesgos más altos, es decir, se elaboran las bases esenciales del proyecto desde donde empezar a iterar(actualizar el proyecto),se identificacian de nuevos requisitos y nuevos alcances, y se logran estimaciones más ajustadas.

3. Construcción: En la fase de construcción se implementan el resto de los requisitos, menos imprescindibles y elementos mas sencillos. Además se produce la preparación para el despliegue del proyecto.

4. Transición: En la fase de transición dan a lugar las pruebas beta y el despliegue del producto.

Disciplinas y artefactos

El UP se organiza en disciplinas o flujos de trabajo. Un flujo de trabajo o disciplina, es un conjunto de actividades realizadas en un área determinada. Las actividades producen artefactos.
Podemos describir artefacto como todo aquel resultado del trabajo, ya sea texto, diagrama, pagina webm codigo en lenguaje de programación, etc. de las diferentes disciplinas que se ejecutan.

Las disciplinas mas relevantes y unos pocos artefactos resultantes de cada campo:

Modelado del Negocio:
El objetivo es crear un canal de comunicación entre los ingenieros del software y los gestores del negocio, para ello los ingenieros del software deben conocer las necesidades del cliente, los problemas actuales y sus posibles mejoras.

Modelo de Dominio:
Como resultado del Modelado del Negocio se obtiene el Modelo de Dominio donde se reflejan los aspectos básicos del dominio(casos de uso).

Requerimientos:
El objetivo es describir que tiene que hacer el sistema o proyecto, y poner de acuerdo usuarios y desarrolladores los usos del sistema en si.

Modelo de Casos de Uso

Llamamos modelo de casos de uso a la combinación de casos de uso y sus correspondientes diagramas. Los modelos de casos de uso se suelen acompañar por un glosario que describe la terminología utilizada.

Visión y Análisis del Negocio:

El propósito del modelo de análisis de negocio es describir como será el software realizado en la fase de implementación.

Especificacion Complementaria:

La Especificación Complementaria reúne requerimientos, restricciones e información que resulta difícil reflejar en los Casos de Uso o en el Glosario. Algunos desarrolladores prefieren reunir los requerimientos propios de un caso de uso en este documento, como manera de tenerlos en cuenta globalmente.

Diseño:
Consiste en modelo de diseño basado en una serie de clases (agrupadas en paquetes y subsistemas) con interfaces bien definidos. También contiene descripciones de las interacciones de los objetos para realizar las acciones que se incluyen en los casos de uso.

Documento de Arquitectura:

Se trata de un documento informativo sobre la estructura de las interfaces del diseño.

Implementacion:
Esta disciplina consiste en la implementación de todos los componentes del sistema (clases,objetos,ficheros fuente, binarios, ejecutables, etc.).

Modelo de implementación:

Resultado de la implementación de todos los componentes del sistema en la fase o disciplina de implementación.

Gestion de proyecto:
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, etc.

Pruebas y Entorno:
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, etc.



No en todos los proyectos son necesarios todos los artefactos ni se la misma importancia a cada uno, lo recomendable es el uso de pocos artefactos, seleccionando los adecuados para cada proyecto. Aunque los mas importantes e imprescindibles son los correspondientes a cada disciplina(Ej. modelo de casos de uso o dominio, modelo de diseño, modelo de implementación, y modelo de prueba).



Hitos

Cada fase finaliza con un hito, que se determina por el conjunto de artefactos disponibles después de la finalización de la fase, es decir un conjunto de modelos, documentos o archivos que han sido desarrollados hasta alcanzar cierto estado.
El objetivo principal de los hitos es que los directores tomen ciertas decisiones antes de que el trabajo continúe con la siguiente fase.
Los hitos también permiten controlar la dirección y progreso del trabajo.
Al final se obtiene un conjunto de datos a partir del seguimiento del tiempo y esfuerzo de cada fase. Estos datos son útiles para preveer comportamientos en futuros proyectos.






Disciplinas del Proceso Unificado


1 - Captacion de los requisitos

El fin de establecer los requisitos es conducir al desarrollo correcto del sistema.
Se parte de un modelo del negocio o se crea uno, si se trata de un sistema acotado se parte de un modelo del dominio.

El sistema de trabajo de los requisitos es el siguiente:
-Enumerar los requisitos; se crean a partir de una lista especifica de caracteristicas del sistema deseadas. Se registran datos de cada caracteristica como nombre, estado, coste, prioridad... Estos datos sirven para estimar el volumen del proyecto y como clasificarlo en las diferentes iteraciones.
-Comprender el contexto del sistema; el contexto del sistema se establece en base al modelado del dominio y al modelado del negocio. El modelo del dominio especifica los terminos relevantes del contexto como elementos del dominio relacionados entre ellos, el del negocio define los procesos con el fin de entenderlos, especifica el proceso de negocio que el sistema adjuntara.
-Capturar los requisitos funcionales y los no funcionales; los funcionales son obtenidos con los casos de uso, los no funcionales especifican propiedades del sistema como restricciones o rendimientos, .

Modelo del Dominio
El modelo de dominio obtiene los tipos de elementos mas importates del sistema, estos representan el contenido o las situaciones en el entorno del sistema. Se representa normalmente con digramas constituidos por diagramas de clases en UML. El objetivo es entender y describir las clases mas relevantes en el contexto del sistema.

Modelo del Negocio
El modelo del negocio es una tecnicapara comprender los procesos de negocio de la organización, esta soportado por el modelado de casos de uso y el de objetos.
El modelo de casos de usos del negocio define un sistema desde la perspectiva de su uso y especifica como proporciona valos a sus usuarios.
El modelo de objetos del negocio es elaborado por un sector del equipo desarrolladores que se abastecen del conjunto de entidades del negocio y de unidades de trabajo.

Busqueda de casos de uso a partir de un modelo del negocio
Cada trabajador y cliente tendran la necesidad de un soporte del sistema de informacion, el cual se determinara conel flujo de acciones de las relaciones de diferentes sw-clientes.
Cuando se establezcan todos los “roles” del sw y clientes se pueden definir los casos de uso de los actores del sistema.

Requisitos adicionales
Los requisitos no funcionales (o adicionales) como el rendimiento, interfaces o requisitos de diseño fisico, se captan con una lista de requisitos que mas tarde se usaran en el analisis junto al modelo de casos de uso.


2 - Análisis.

En el análisis de los requisitos que se establecieron en la captura de requisitos, estos se definen mas minuciosamente y se reestructuran con el objetivo de comprenderlos con mayor precision y por establecer una definicion facil de manejar que ayude en la estructuracion interna del sistema. Analizar los requisitos en el modelo de analisis aporta ciertas ventajas como:
-Especificacion mas precisa de los requisitos
-Mayor formalismo y uso para razonamientos de funcionamientos internos del sistema
-Estructura los requisitos de forma que mejora la comprension, preparacion, modificacion y mantenimiento.
-Es una buena base para el inicio del diseño del sistema y en su implementacion.

3 - Diseño.

En el proceso de diselo modelamos el sistema y su arquitectura con el fin de que soporte tanlos los requisitos funcionales como los no funcionales. Es el eje central en la fase final de la elaboracion y comienzo en las iteraciones de construccion.
Una clase de diseño se define como la abstraccion sin brechas con una contruccion o clase en la implementacion del sistema, implementado en un lenguaje de programacion, con atributos y operaciones especificos.
Una realizacion de caso de uso de diseño esta relacionado directamente con la relaizacion del caso de uso analisis.
Los subsistemas de diseño son una forma de organizar los artefactos del modelo de diseño en sector mas maleables, pueden cosntar de clases de diseño, interfaces, subsistemas y realizaciones de casos de uso.
Una clase de diseño implementa una interfaz, estas forman la separacion de la funcionalidad respecto de las implementaciones.
El modelo de despliegue esta formado por una serie de objetos que definen las distribucion del sistema en cuanto a su constitucion funcional entre nodos de computo.
La realizacion de diseños de casos de uso proporciona una identificacion de clases y/o subsistemas necesarios para llevar a cabo el caso de uso. Para la definicion de los requisitos sobre las operaciones de las clases de diseño e incluso para los subsistemas e interfaces.


Artefactos del UP

Podemos definir artefacto como cualquier resultado o producto de un trabajo en un proceso.
Las actividades tienen artefactos de entrada y de salida. Los trabajadores utilizan artefactos para realizar actividades y producen artefactos como resultado de sus actividades.
Los artefactos son responsabilidad de un único trabajador y cada artefacto proviene de un trabajo especifico. Un trabajador es el “propietario” de un artefacto, pero otros trabajadores pueden usarlo y tal vez modificarlo si tienen permiso para ello.

Un artefacto puede ser cualquier tipo de modelo, documento, gráfica, boceto, etc. que de como resultado o utilicemos a la hora de realizar actividades.

Para dejar claro lo que es un modelo, llamamos modelo a una representación abstracta, conceptual, gráfica o visual a fin de, en general, explorar, controlar y predecir un comportamiento futuro de un proceso. Un modelo permite determinar un resultado final a partir de ciertos datos de entrada(que también pueden ser otros modelos o diversos artefactos).

Algunos de los artefactos mas relevantes son, en la disciplina de de requerimientos y modelado del negocio :

Modelo de Dominio:
Como resultado del Modelado del Negocio se obtiene el Modelo de Dominio donde se reflejan los aspectos básicos del dominio(casos de uso).

Modelo de Casos de Uso

Llamamos modelo de casos de uso a la combinación de casos de uso y sus correspondientes diagramas. Los modelos de casos de uso se suelen acompañar por un glosario que describe la terminología utilizada.

Visión y Análisis del Negocio:

El propósito del modelo de análisis de negocio es describir como será el software realizado en la fase de implementación.

Especificacion Complementaria:

La Especificación Complementaria reúne requerimientos, restricciones e información que resulta difícil reflejar en los Casos de Uso o en el Glosario. Algunos desarrolladores prefieren reunir los requerimientos propios de un caso de uso en este documento, como manera de tenerlos en cuenta globalmente.

Glosario:

Terminología clave del dominio.

Lista de riesgos y plan de gestión del riesgo:

Describe los riesgos del negocio, técnicos, recursos, planificación, y las ideas para acabar con ellos o darles respuesta.

En la disciplina de Diseño podemos encontrar desde cualquier documento artistico o boceto, hasta diagramas de usos y funcionalidades:

Documento de Arquitectura:

Se trata de un documento informativo sobre la estructura de las interfaces del diseño.*

Modelo de Datos:

Un modelo de datos es un lenguaje orientado a describir una base de datos.También puede ser considerado como un modelo que permite describir los elementos que intervienen en un problema dado y la forma en que se relacionan esos elementos entre sí.

En la fase de implementación:

Componentes:

Cualquier parte implementada o a implementar.

Modelo de implementación:

Resultado de la implementación de todos los componentes del sistema en la fase o disciplina de implementación.

En la disciplina de pruebas:

Plan de pruebas:

Cualquier guión preestablecido que indique que probar.

Defectos:

Cualquier imperfección que surja a partir de cualquier actividad de la disciplina de pruebas

Prototipos y pruebas de conceptos:

Para clarificar la visión y validar las ideas técnicas.

Existen muchas más, ya que cualquier cosa que sea resultado de una actividad puede considerarse artefacto.



Fases del Proceso Unificado


El proceso unificado cuenta de cuatro fases estas son: Inicio, Elaboración, Construcción y Transición.
En algunos libros también encontramos una quinta fase llamada producción, solo estudiaremos las primeras, ya que de la fase de producción la información encontrada no es muy clara (sobre todo hace referencia al Proceso unificado empresa (EUP)). De toda forma la mencionamos y sabemos que esta quinta fase seria el lanzamiento del software.

Fase de Inicio

En  esta primera fase se determina la viabilidad del producto es decir si merece la pena desarrollar el producto o no, para ello se deben realizaran una serie de pautas alguna de ellas son las siguientes:

Determinar los objetivos.
Realizar un análisis del negocio.
Elegir la mejor arquitectura.
Realizar la planificación del proyecto

    Calcular los Costes de desarrollo

    Identificar posibles riesgos y/o problemas.

El objetivo de esta fase es ayudar al equipo del proyecto a decidir cuales son los
verdaderos objetivos del proyecto.

Las iteraciones realizadas en esta fase darán como resultado diferentes soluciones
posibles y diferentes arquitecturas posibles, sin embargo estos resultados puede que sean descartados por lo que lo único que normalmente sobrevive a la fase de inicio es el incremento del conocimiento en el equipo.

Lo que generalmente sobrevive a esta fase es:

- Un enunciado de los mayores requerimientos planteados generalmente como casos de uso.
- Un boceto inicial de la arquitectura.
- Una descripción de los objetivos del proyecto.
- Una versión muy preliminar del plan del proyecto.
- Un modelo del negocio.

La fase de inicio finaliza con el Hito de Objetivos del Ciclo de Vida.
Este hito es alcanzado cuando el equipo de proyectos y los stakeholders llegan a un acuerdo sobre:

- Cuál es el conjunto de necesidades del negocio, y que conjunto de funciones
satisfacen estas necesidades.
- Una planificación preliminar de iteraciones.
- Una arquitectura preliminar.
Debe poder responderse las siguientes cuestiones:
- ¿Se ha determinado con claridad el ámbito del sistema? ¿Se ha determinado lo que
va a estar dentro del sistema y fuera de el sistema?
- ¿Se ha llegado a un acuerdo con todas las personas involucradas (stakeholders)
sobre los requisitos funcionales del sistema?
- ¿Se vislumbra una arquitectura que pueda soportar estas características?
- ¿Se identifican los riesgos críticos? ¿Se prevé forma de mitigarlos?
- ¿El uso del producto justifica la relación costo-beneficio?
- ¿Es factible para su organización llevar adelante el proyecto?
- ¿Están los inversores de acuerdo con los objetivos?

Fase de Elaboración


En la fase de elaboración se especifican detalladamente la mayoría de los casos de uso del producto y se diseña la arquitectura base.

Las iteraciones producidas en la fase de elaboración:
Establecen comprensión del problema a solucionar.
- Establece la arquitectural para el software.
- Establece un plan detallado para las siguientes iteraciones.
- Elimina los mayores riesgos.

Estas iteraciones darán como resultado la línea base de la arquitectura.

En esta fase se desarrolla lo siguientes artefactos:
- El cuerpo básico del sw en la forma de un prototipo arquitectural.
- Casos de prueba
- La mayoría de los casos de uso (alrededor del 80%) que describen la funcionalidad del sistema.
- Una planificación detallada para las siguientes iteraciones.

La fase de elaboración finaliza con el hito de la Arquitectura del Ciclo de Vida.
Este hito se alcanza cuando el equipo de desarrollo y los stakeholders llegan a un
acuerdo sobre:
- Los casos de uso que describen la funcionalidad del sistema.
- La arquitectura base.
- Los riesgos más grandes han sido mermados.
- La planificación del proyecto.

Al finalizar esta fase se debe poder responder a preguntas como:
- ¿Se ha creado una línea base de la arquitectura?
- ¿Es adaptable y robusta?
 ¿Puede evolucionar?
- ¿Se han identificado y disminuido los riesgos más graves?
- ¿Se ha desarrollado una planificación del proyecto hasta el nivel necesario para respaldar una agenda, costes, y calidades realistas?
- ¿Proporciona el proyecto, una adecuada recuperación de la inversión?
- ¿Se ha obtenido la aprobación de los inversores?


Fase de Construcción

En la fase de construcción se crea el producto. La línea base de la arquitectura obtenida en la fase de elaboración crece hasta convertirse en el sistema completo.

Al finalizar de esta fase, el producto contiene todos los casos de uso implementados,  aunque es posible que no esté libre de defectos.

En esta fase se desarrollan los siguientes artefactos:

- El sistema “software”
- Casos de prueba.
- Manuales de usuario

La fase de construcción finaliza cuando el equipo de desarrollo y los stakeholders determinan que:

- El producto es estable para ser usado.
- El producto dispone de alguna funcionalidad de valor.
- Todas las partes están preparadas para comenzar la transición.

Fase de Transición

Esta fase de transición es el tiempo en el que el producto se convierte en la versión beta.
Las iteraciones en esta fase continúan agregando, características al sw. Aunque esta vez estas características se agregan a un sistema que el usuario se encuentra utilizando de modo activo.

En esta fase se desarrollan los mismos artefactos que en la fase de construcción.

El equipo se encuentra ocupado principalmente en corregir y ampliar la funcionalidad del sistema desarrollado en la fase de construccion.

La fase de transición finaliza con el Lanzamiento del Producto,.y este se alcanza cuando:

- Se han alcanzado los objetivos fijados en la fase de Inicio.
- El usuario está satisfecho.

Glosario:
Stakeholders: (quienes pueden afectar o son afectados por las actividades de una empresa)



Herramientas para aplicar UP

El proceso unificado es soportado por herramientas que automatizan entre otras cosas, el modelado de sistemas con UML, la administración de cambios y las pruebas.
Estas herramientas las podemos encontrar como una familia en el mejor de los casos, o bien encontrar alternativas independientes para cada función.

Familia de herramientas:

Quizás la mejor alternativa en software que podemos encontrar para una empresa es IBM Rational ya que dispone de herramientas  para el despliegue, diseño, construcción, pruebas y administración de proyectos.

¿Qué ofrece IBM RATIONAL?

Gestión de cambios, configuraciones y releases: Mejorar la distribución de software y la rastreabilidad del ciclo vital, desde los requisitos hasta el despliegue.

Gestión de arquitectura empresarial: Aplicar las decisiones correctas y los mejores planes a la transformación empresarial.

Pruebas de software y gestión de calidad: Garantizar la funcionalidad, fiabilidad y el rendimiento del software durante el desarrollo y la producción.

Desarrollo de software: Diseñar, modelar, desarrollar y distribuir un software y unos sistemas de mejor calidad.

Gestión de productos, proyectos y catálogos: Transformar la manera en la que las empresas definen y ofrecen sus valores, mediante la gestión del rendimiento.

Gestión de requisitos: Definir y gestionar requisitos y proporcionar rastreabilidad y alineación con los procesos empresariales.

Seguridad de aplicaciones web: Proteger los datos y satisfacer los requisitos de conformidad normativos y corporativos.

El mayor inconveniente que nos encontramos a la hora de adquirir este software es su elevado coste.

Otras herramientas:

Microsoft Visio:
Podemos definir Visio como la herramienta de Microsoft para crear diagramas de forma visual e intuitiva obteniendo resultados profesionales.
Esta destinado a entornos profesiones e incluye herramientas y plantillas para simplificar la creación de diagramas,  si tenemos que destacar sus mayores  ventajas son la posibilidad de crear gráficos a partir de tablas en Excel y la facilidad para conectarse e interactuar con Sharepoint, realmente útil en entornos empresariales.
Ventajas:

• Interfaz muy clara
• Fácil de usar
• Integrado con otros programas de Microsoft Office
• Incluye muchas plantillas prediseñadas

Desventajas:

• Algunas plantillas desfasadas

Existen muchas versiones de este software tenemos que aclarar que las versiones que nos permiten utilizar herramientas uml son Visio Profesional o Visio Premium.

Diagramas disponibles:

• Diagramas de casos de uso
• Diagramas de estructura estática
• Diagramas de paquetes
• Diagramas de actividad
• Diagramas de estados
• Diagramas de secuencia
• Diagramas de colaboración
• Diagramas de componentes
• Diagramas de implementación

Requisitos mínimos:

• Procesador: 500 MHz.
• Memoria: 256 MB.
• Espacio libre en disco: 2 GB.
• Resolución de pantalla: 1024x768.
• Internet Explorer 6.

S.O :  WinXP/2003/Vista/7


SmartDraw:
Es quizás la herramienta mas popular para crear diagramas uml un complemento perfecto para office, llena con elegancia la laguna existente en Office, ofreciendo una poderosa aplicación de dibujo con la que se puede crear todo tipo de diagramas de flujo, diagramas de Gantt, calendarios, árboles de decisión e incluso mapas (gracias a la integración que tiene con Google Maps).
Crear un diagrama de aspecto agradable con SmartDraw sólo requiere arrastrar uno de los muchos elementos incluídos en la biblioteca y unirlos mediante líneas inteligentes que buscan las mejores rutas y puntos de unión. En SmartDraw los objetos pueden a su vez modificarse, agruparse o cambiarse por otros.
Pero SmartDraw no sería tan conocido si no fuese por sus opciones de exportación, que incluyen el formato PDF, Word y Powerpoint (programa con el cual la integración es perfecta).

Ventajas:

• Creación de diagramas potente y flexible

• Amplísima biblioteca de elementos gráficos
• Corrección ortográfica en español

Desventajas:

• Consume abundantes recursos
• Instalación lenta

Licencia: de Pago.

S.O: Win98/98SE/Me/2000/XP/2003/Vista/7

SmartDraw soporta los siguientes formatos:
SDR, SDT, WMF, PDF, DOC, PPT, XLS, HTML, JPG, PNG, GIF, TIFF, BMP, EMF, VDX, VSD, SDL.

Requisitos mínimos:

• Procesador: 833 MHz.
• Memoria: 256 MB.
• Espacio libre en disco: 3,0 GB.

idioma: Inglés


StarUML:
Es un proyecto de código abierto y nace como remplazo a otras herramientas UML comerciales.
Si observamos sus características mas importantes destaca su sencillez con un simple vistazo a la interfaz se ven las funciones principales del programa, otra característica importante es que su código es  totalmente compatible con C++ y Java, también permite dibujar los gráficos manualmente o seleccionar las plantillas que contiene el archivo de instalación para modificarlas. Esta última opción es muy recomendable para quien no ha trabajado con archivos UML / MDA.

S.O : Win98SE/Me/2000/NT/XP
Licencia: Gratis (GPL)
Idioma:  Inglés

SourceForge:
SourceForge.net Es una base de datos de proyectos de software, alberga más de 100.000 proyectos, y más de un millón de usuarios, lo que lo convierte en el sitio con mayúsculas para cualquiera que esté interesado en lanzar un proyecto o colaborar con otros proyectos. A su vez también, es el lugar desde el que los usuarios tienen acceso a lo mejor del software opensource.
Todo el software disponible en SourceForge es de código abierto, gracias a ello cualquiera con los conocimientos necesarios pueda acceder al código fuente y de este modo colaborar en su desarrollo, aportar nuevas ideas, etc.
Podemos decir que la misión principal de SourceForge es reunir a desarrolladores de todo el mundo en torno a un proyecto concreto, y además proporcionar una serie de herramientas y servicios para facilitar el nacimiento de ese software.
SourceForge  facilita herramientas para hacer posible la realización de todas las tareas de coordinación y comunicación entre desarrolladores, de este modo éstos no acaban duplicando el trabajo y se mantienen coordinados, es decir facilita que personas en distintas partes del mundo trabajen juntos como si estuvieran dentro de la misma oficina.

Microsoft .net:
.NET Framework es la plataforma de desarrollo de código administrado de Microsoft. Dispone de una serie de herramientas y librerías con las que se pueden crear todo tipo de aplicaciones, ya sea las tradicionales aplicaciones de escritorio (WPF o Windows Forms ) o aplicaciones para XBOX (XNA) pasando por desarrollo web (ASP.NET), desarrollo para móviles (compact framework), aplicaciones de servidor (WPF, WCF), etc.

Algunas herramientas disponibles:
·         StyleCop: Analizador código fuente para establecer pautas de calidad
·         Code Header Designer: Crea una cabecera para todos los ficheros de código.
·         Visual Studio Express: Herramientas gratuitas para desarrolladores
·         SandCastle: Generador de documentación
·         nUnit: Conocido framework de testing de lenguajes .NET
·         .NET Reflector: Explora navega y analiza ensamblados .NET




REFERENCIAS

http://es.wikipedia.org/wiki/Proceso_Unificado#Caracter.C3.ADsticas

http://www.slideshare.net/Sofylutqm/el-proceso-unificado-3943047

http://www.youtube.com/watch?v=uW7V7-fyA5c

http://www.utim.edu.mx/~pmendoza/ftp/rup.pdf
http://iie.fing.edu.uy/ense/asign/desasoft/Teorico2/ProcesoUnificado.pdf

http://www.slideshare.net/pabloto/el-proceso-unificado

http://quegrande.org/apuntes/EI/OPT/PAI/teoria/07-08/tema_2_-_el_proceso_unificado.pdf