# data[].attributes.body
UML (Lenguaje unificado de modelado) es un lenguaje para hacer modelos y es independiente de los métodos de análisis y diseño. Existen diferencias importantes entre un método y un lenguaje de modelado. Un método es una manera explícita de estructurar el pensamiento y las acciones de cada individuo. Además, el método le dice al usuario qué hacer, cómo hacerlo, cuándo hacerlo y por qué hacerlo; mientras que el lenguaje de modelado carece de estas instrucciones. Los métodos contienen modelos y esos modelos son utilizados para describir algo y comunicar los resultados del uso del método.

# data[].attributes.headline
UML es un lenguaje para hacer modelos y es independiente de los métodos de análisis y diseño.

# data[].attributes.subject
UML es un lenguaje para hacer modelos y es independiente de los métodos de análisis y diseño.

# data[].attributes.body
Diagramas: Los diagramas son las gráficas que describen el contenido de una vista. UML tiene nueve tipos de diagramas que son utilizados en combinación para proveer todas las vistas de un sistema: diagramas de caso de uso, de clases, de objetos, de estados, de secuencia, de colaboración, de actividad, de componentes y de distribución.

Símbolos o Elementos de modelo: Los conceptos utilizados en los diagramas son los elementos de modelo que representan conceptos comunes orientados a objetos, tales como clases, objetos y mensajes, y las relaciones entre estos conceptos incluyendo la asociación, dependencia y generalización. Un elemento de modelo es utilizado en varios diagramas diferentes, pero siempre tiene el mismo significado y simbología.

Reglas o Mecanismos generales: Proveen comentarios extras, información o semántica acerca del elemento de modelo; además proveen mecanismos de extensión para adaptar o extender UML a un método o proceso específico, organización o usuario.

# data[].attributes.body
http://profesores.fi-b.unam.mx/carlos/aydoo/uml.html

# data[].attributes.attachment_link.readable_text
En todas las disciplinas de la Ingeniería se hace evidente la importancia de los modelos ya que describen el aspecto y la conducta de " algo". Ese " algo" puede existir, estar en un estado de desarrollo o estar, todavía, en un estado de planeación. Es en este momento cuando los diseñadores del modelo deben investigar los requerimientos del producto terminado y dichos requerimientos pueden incluir áreas tales como funcionalidad, performance y confiabilidad. Además, a menudo, el modelo es dividido en un número de vistas, cada una de las cuales describe un aspecto específico del producto o sistema en construcción.

El modelado sirve no solamente para los grandes sistemas, aun en aplicaciones de pequeño tamaño se obtienen beneficios de modelado, sin embargo es un hecho que entre más grande y más complejo es el sistema, más importante es el papel de que juega el modelado por una simple razón: "El hombre hace modelos de sistemas complejos porque no puede entenderlos en su totalidad".

UML es una técnica para la especificación sistemas en todas sus fases. Nació en 1994 cubriendo los aspectos principales de todos los métodos de diseño antecesores y, precisamente, los padres de UML son Grady Booch, autor del método Booch; James Rumbaugh, autor del método OMT e Ivar Jacobson, autor de los métodos OOSE y Objectory. La versión 1.0 de UML fue liberada en Enero de 1997 y ha sido utilizado con éxito en sistemas construidos para toda clase de industrias alrededor del mundo: hospitales, bancos, comunicaciones, aeronáutica, finanzas, etc.
Los principales beneficios de UML son:

Mejores tiempos totales de desarrollo (de 50 % o más).

Modelar sistemas (y no sólo de software) utilizando conceptos orientados a objetos.

Establecer conceptos y artefactos ejecutables.

Encaminar el desarrollo del escalamiento en sistemas complejos de misión crítica.

Crear un lenguaje de modelado utilizado tanto por humanos como por máquinas.

Mejor soporte a la planeación y al control de proyectos.

Alta reutilización y minimización de costos.

UML, ¿Método o Lenguaje de Modelado?
UML es un lenguaje para hacer modelos y es independiente de los métodos de análisis y diseño. Existen diferencias importantes entre un método y un lenguaje de modelado. Un método es una manera explícita de estructurar el pensamiento y las acciones de cada individuo. Además, el método le dice al usuario qué hacer, cómo hacerlo, cuándo hacerlo y por qué hacerlo; mientras que el lenguaje de modelado carece de estas instrucciones. Los métodos contienen modelos y esos modelos son utilizados para describir algo y comunicar los resultados del uso del método.

Un modelo es expresado en un lenguaje de modelado. Un lenguaje de modelado consiste de vistas, diagramas, elementos de modelo ¾ los símbolos utilizados en los modelos ¾ y un conjunto de mecanismos generales o reglas que indican cómo utilizar los elementos. Las reglas son sintácticas, semánticas y pragmáticas ( figura 1).
figura 1
Vistas: Las vistas muestran diferentes aspectos del sistema modelado. Una vista no es una gráfica, pero sí una abstracción que consiste en un número de diagramas y todos esos diagramas juntos muestran una "fotografía" completa del sistema. Las vistas también ligan el lenguaje de modelado a los métodos o procesos elegidos para el desarrollo. Las diferentes vistas que UML tiene son:

Vista Use-Case: Una vista que muestra la funcionalidad del sistema como la perciben los actores externos.

Vista Lógica: Muestra cómo se diseña la funcionalidad dentro del sistema, en términos de la estructura estática y la conducta dinámica del sistema.

Vista de Componentes: Muestra la organización de los componentes de código.

Vista Concurrente: Muestra la concurrencia en el sistema, direccionando los problemas con la comunicación y sincronización que están presentes en un sistema concurrente.

Vista de Distribución: muestra la distribución del sistema en la arquitectura física con computadoras y dispositivos llamados nodos.

Diagramas: Los diagramas son las gráficas que describen el contenido de una vista. UML tiene nueve tipos de diagramas que son utilizados en combinación para proveer todas las vistas de un sistema: diagramas de caso de uso, de clases, de objetos, de estados, de secuencia, de colaboración, de actividad, de componentes y de distribución.

Símbolos o Elementos de modelo: Los conceptos utilizados en los diagramas son los elementos de modelo que representan conceptos comunes orientados a objetos, tales como clases, objetos y mensajes, y las relaciones entre estos conceptos incluyendo la asociación, dependencia y generalización. Un elemento de modelo es utilizado en varios diagramas diferentes, pero siempre tiene el mismo significado y simbología.

Reglas o Mecanismos generales: Proveen comentarios extras, información o semántica acerca del elemento de modelo; además proveen mecanismos de extensión para adaptar o extender UML a un método o proceso específico, organización o usuario.
FASES DEL DESARROLLO DE UN SISTEMA
Las fases del desarrollo de sistemas que soporta UML son: Análisis de requerimientos, Análisis, Diseño, Programación y Pruebas.
Análisis de Requerimientos
UML tiene casos de uso (use-cases) para capturar los requerimientos del cliente. A través del modelado de casos de uso, los actores externos que tienen interés en el sistema son modelados con la funcionalidad que ellos requieren del sistema (los casos de uso). Los actores y los casos de uso son modelados con relaciones y tienen asociaciones entre ellos o éstas son divididas en jerarquías. Los actores y casos de uso son descritos en un diagrama use-case. Cada use-case es descrito en texto y especifica los requerimientos del cliente: lo que él (o ella) espera del sistema sin considerar la funcionalidad que se implementará. Un análisis de requerimientos puede ser realizado también para procesos de negocios, no solamente para sistemas de software.
Análisis
La fase de análisis abarca las abstracciones primarias (clases y objetos) y mecanismos que están presentes en el dominio del problema. Las clases que se modelan son identificadas, con sus relaciones y descritas en un diagrama de clases. Las colaboraciones entre las clases para ejecutar los casos de uso también se consideran en esta fase a través de los modelos dinámicos en UML. Es importante notar que sólo se consideran clases que están en el dominio del problema (conceptos del mundo real) y todavía no se consideran clases que definen detalles y soluciones en el sistema de software, tales como clases para interfaces de usuario, bases de datos, comunicaciones, concurrencia, etc.
Diseño
En la fase de diseño, el resultado del análisis es expandido a una solución técnica. Se agregan nuevas clases que proveen de la infraestructura técnica: interfaces de usuario, manejo de bases de datos para almacenar objetos en una base de datos, comunicaciones con otros sistemas, etc. Las clases de dominio del problema del análisis son agregadas en esta fase. El diseño resulta en especificaciones detalladas para la fase de programación.
Programación
En esta fase las clases del diseño son convertidas a código en un lenguaje de programación orientado a objetos. Cuando se crean los modelos de análisis y diseño en UML, lo más aconsejable es trasladar mentalmente esos modelos a código.
Pruebas
Normalmente, un sistema es tratado en pruebas de unidades, pruebas de integración, pruebas de sistema, pruebas de aceptación, etc. Las pruebas de unidades se realizan a clases individuales o a un grupo de clases y son típicamente ejecutadas por el programador. Las pruebas de integración integran componentes y clases en orden para verificar que se ejecutan como se especificó. Las pruebas de sistema ven al sistema como una "caja negra" y validan que el sistema tenga la funcionalidad final que le usuario final espera. Las pruebas de aceptación conducidas por el cliente verifican que el sistema satisface los requerimientos y son similares a las pruebas de sistema.

Tabla de Contenido

# data[].attributes.attachment_link.description
En todas las disciplinas de la Ingeniería se hace evidente la importancia de los modelos ya que describen el aspecto y la conducta de " algo". Ese " algo" puede existir, estar en un estado de desarrollo o estar, todavía, en un estado de planeación.

# data[].attributes.body
visualizar.

Especificar .

Construir.

documentar y/o ser base de documentación.

# data[].attributes.body
https://sites.google.com/site/disenodesistemasdmlf/home/-que-es-uml-y-sus-caracteristicas

# data[].attributes.attachment_link.readable_text
Unified Modeling Language - Lenguaje Unificado de Modelado). UML es un lenguaje de modelado de sistemas de software. Se trata de un lenguaje gráfico para construir, documentar, visualizar y especificar un sistema de software. Entre otras palabras, UML se utiliza para definir un sistema de software.

El lenguaje de modelado es la notación (principalmente gráfica) que usan los métodos para expresar un diseño. El proceso indica los pasos que se deben seguir para llegar a un diseño.

Características de un UML :

visualizar.

Especificar .

Construir.

documentar y/o ser base de documentación.

Lo fundamental de una herramienta UML:

La capacidad de diagramación, y los diferentes tipos de diagramas que soporta la herramienta

Documentación

Construcción

Implantación de sistema

Flexibilidad para admitir cambios no previstos durante el diseño o el rediseño.

# data[].attributes.attachment_link.title
¿QUÉ ES UML Y SUS CARACTERÍSTICAS? - DMLF

# data[].attributes.attachment_link.description
Unified Modeling Language - Lenguaje Unificado de Modelado). UML es un lenguaje de modelado de sistemas de software. Se trata de un lenguaje gráfico para construir, documentar, visualizar y especificar un sistema de software. Entre otras palabras, UML se utiliza para definir un sistema de software.

# data[].attributes.body
Por así decirlo, el modelado UML, tiene la función de hacer modelos en la computadora para que este pueda ser visto de manera muy sencilla en el proceso, como tal un ejemplo sería: "El caso de uso", como lo agregue en el ejemplo UML Figura 2. Podemos apreciar 2 ejemplos, que sencillamente están muy específicos, donde indica la creación de un server de manera sencilla, especificando 2 personas "Browser y Administrador" Browser hace la pagina del servidor, mientras que con el administrador, inicia y cierra la pagina.

En pocas palabras, nos da una vista muy sencilla, y sin tantas vueltas el funcionamiento que estas pueden llegar a dar, hay una gran variedad, y de maneras de ejemplificar la utilización de esta.

La finalidad que tiene, es tener una idea clara, del trabajo que se quiere llegara realizar, y a base de eso, poder realizar el trabajo claramente.

La diferencia con RUP

Es que este tiene un montón de procesos, pero lleva la mano de UML, lo que se llega hacer es buscar una manera de que estos se pueda agilizar al momento de estar realizando el trabajo, ya que al estar manejando demasiadas áreas de trabajo, puede tomar mucho tiempo al momento, por eso, optaron por la utilización del modelo RUP, ya que estas define las tareas que puede llegar a tener la persona, y al mismo tiempo, el trabajo en general de los empleados en cuestion.

# data[].attributes.body
El Proceso Unificado Racional (Rational Unified Process en inglés, habitualmente resumido como RUP) es un proceso de desarrollo de software y junto con el Lenguaje Unificado de Modelado UML, constituye la metodología estándar más utilizada para el análisis, implementación y documentación de sistemas orientados a objetos.

# data[].attributes.body
La metodología RUP consiste en una estructura de trabajo de proceso con el objetivo del producto y por tanto basada en el modelo Unified Modeling Language (UML), cuando se habla de programación orientada a objetos.

Aunque RUP se utiliza para proyectos complejos y con equipos extensos, permite realizar actividades y artefactos de acuerdo con la elección del equipo y se puede adaptar para agilizar el proceso .

El modelo se detalla desde tres perspectivas:

Dinámica

Estático

Práctica

# data[].attributes.body
Forma disciplinada de asignar tareas y responsabilidades (quién hace qué, cuándo y cómo)

Pretende implementar las mejores prácticas en Ingeniería de Software

Desarrollo iterativo

Administración de requisitos

Uso de arquitectura basada en componentes

Control de cambios

Modelado visual del software

Verificación de la calidad del software

# data[].attributes.body
https://lean-management.site/rup/

# data[].attributes.attachment_link.readable_text
RUP significa Rational Unified Process . Este término es un proceso creado por la empresa de ingeniería de software, Rational Software Corporation, para guiar el desarrollo de un programa. El RUP es una metodología con prácticas Lean, así como Scrum y Extreme Programming (XP). Estos métodos tienen en común el uso de buenas prácticas que ayudan a obtener técnicas rutinarias y productivas.

¿Qué es la RUP?

Como hemos definido anteriormente, RUP es un acrónimo y significa el Proceso Unificado Racional. Este proceso se usa preferiblemente para proyectos complejos con equipos grandes.

En la gestión de un proyecto, el sistema RUP promueve una solución disciplinada, que consiste en organizar las tareas y responsabilidades de todos dentro de una organización.

Metodología RUP

Las prácticas utilizadas en RUP se basan en varios métodos, pero además, presenta algunos principios similares al de los métodos Lean .

Uno de estos métodos es Scrum , y no es posible clasificar uno como mejor que el otro, sino evaluar cuáles son los objetivos que cada metodología proporciona para tu organización o proyecto.

El Scrum Framework se basa en prácticas según el manifiesto Lean. Los proyectos que se desarrollan en este sistema tienen características como actividades y funcionan de forma iterativa e incremental.

Objetivos del RUP

La metodología RUP consiste en una estructura de trabajo de proceso con el objetivo del producto y por tanto basada en el modelo Unified Modeling Language (UML), cuando se habla de programación orientada a objetos.

El UML compone un lenguaje para definir una secuencia de artefactos y ayudar en la ejecución de las tareas del sistema a desarrollar, a través de diferentes tipos de diagramas.

Todas las técnicas y prácticas utilizadas en el modelo RUP están probadas en la industria del software y la gestión de proyectos.

Aunque RUP se utiliza para proyectos complejos y con equipos extensos, permite realizar actividades y artefactos de acuerdo con la elección del equipo y se puede adaptar para agilizar el proceso .

El modelo se detalla desde tres perspectivas:

Es en la perspectiva dinámica que compone el ciclo de vida del proyecto, en el que se divide en 4 fases secuenciales, denominadas en: inicio, elaboración, construcción y transición .

Desde un punto de vista estático, el RUP se enfoca en las actividades que se llevan a cabo durante el ciclo de vida del proyecto, estas actividades se denominan workflows.

Finalmente, la visión práctica del proceso consta de buenas prácticas de proceso, que son las recomendaciones del método para que todas las actividades se preparen de la mejor manera.

Para aclarar cómo funciona el desarrollo de un proyecto en el RUP, expliquemos qué se hace en cada una de las 4 fases del RUP en el siguiente tema.

Las 4 fases del RUP

Como se indicó en el tema anterior, las fases del RUP están involucradas dentro de la perspectiva del desarrollo dinámico .

Es en este momento que se le da planificación al proyecto, relevamiento de recursos, implementación, pruebas, entre otros. A continuación, comprendamos un poco más sobre cada paso, por separado.

Comienzo

Es en este momento que se elabora la planificación del proyecto con los stakeholders, son ellos quienes han descrito los requisitos para el sistema a desarrollar.

La etapa se realiza en un corto período de tiempo. Guía al equipo para analizar la viabilidad del proyecto y cómo empezar a definir los primeros pasos. Usando este concepto tenemos una metodología llamada Lean Inception .

Elaboración

En la fase de elaboración, o elaboración, busca relevar casos, documentación, estudios base, es decir, modelos para orientar el proyecto. Esto es para orientar cuál será la mejor manera de acuerdo con las premisas de los interesados.

Tras todo este conocimiento, se elabora un plan de proyecto, con todas las características y especificidades, de la forma más detallada posible.

Construcción

Ahí es cuando se termina la construcción del proyecto, por eso tiene ese nombre. El principal objetivo es la elaboración del producto. Dado que el método se basa en el desarrollo de software, estamos hablando de crear códigos.

Además, es en esta etapa que se realizan las primeras pruebas para que se prepare la base inicial para la etapa de transición.

Transición

La transición se expresa como transición, es decir, la fase que pasa el proyecto desde el punto de prueba hasta la implementación.

Después de todas las pruebas realizadas y con el objeto listo, llega el momento de ponerlo a disposición del usuario final, es decir, la entrega del proyecto.

Además de la entrega, esta fase incluye la realización de capacitaciones y asegurar que el objeto final resuelva todos los problemas de las partes interesadas.

Dadas todas las fases que componen un proyecto utilizando la metodología RUP, es importante destacar que en el desarrollo de estas actividades todo el equipo necesita estar orientado a algunas prácticas y realizar los artefactos de forma alineada.

Las mejores prácticas del RUP

Como todo en la vida, hay reglas que seguir. Las buenas prácticas consisten en habilidades que deben desarrollarse para que el aumento se lleve a cabo de la mejor manera posible.

En el caso del RUP, vemos algunas similitudes con los principios del manifiesto Lean , es decir, esta metodología tiene prácticas Lean parcialmente.

Entonces, vayamos a las buenas prácticas del RUP:

Desarrollar el software de forma iterativa

Gestionar requisitos

Utilice arquitecturas basadas en componentes

Modelar visualmente el software

Verifique la calidad del software

Controlar los cambios de software

El objetivo de estas prácticas es lograr que la producción se realice con calidad, en tiempo, con presupuestos predecibles y de manera adecuada para los grupos de interés.

# data[].attributes.attachment_link.title
Metodología RUP: ¿Qué es, cúal es su objetivo y cómo se utiliza?

# data[].attributes.attachment_link.description
RUP significa Rational Unified Process . Este término es un proceso creado por la empresa de ingeniería de software, Rational Software Corporation, para guiar el desarrollo de un programa. El RUP es una metodología con prácticas Lean, así como Scrum y Extreme Programming (XP).

# data[].attributes.body
https://www.programaenlinea.net/proceso-unificado-rational-rup/

# data[].attributes.attachment_link.readable_text
¿Te gustaría aprender Análisis y Diseño Agil Orientado a Objetos?

Proceso Unificado de Rational (RUP)

El Proceso Unificado Racional ( Rational Unified Process en inglés, habitualmente resumido como RUP) es un proceso de desarrollo de software y junto con el Lenguaje Unificado de Modelado UML, constituye la metodología estándar más utilizada para el análisis, implementación y documentación de sistemas orientados a objetos.
El RUP no es un sistema con pasos firmemente establecidos, sino un conjunto de metodologías adaptables al contexto y necesidades de cada organización.
También se conoce por este nombre al software desarrollado por Rational, hoy propiedad de IBM, el cual incluye información entrelazada de diversos artefactos y descripciones de las diversas actividades. Está incluido en el Rational Method Composer (RMC), que permite la personalización de acuerdo a necesidades.
Originalmente se diseñó un proceso genérico y de dominio público, el Proceso Unificado, y una especificación más detallada, elRational Unified Process, que se vendiera como producto independiente.

Principios de desarrollo

El RUP está basado en 5 principios clave que son:

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.

Equilibrar prioridades

Los requerimientos 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 interativamente

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 requerimientos, desarrollo, evaluaciones, planes, resultados,etc. tambien esta metodolgia esta basada en 2 punto 1,2

Elevar el nivel de abstracción

Este principio dominante motiva el uso de conceptos reutilizables tales como patrón del software, lenguajes 4GL o marcos de referencia (frameworks) por nombrar algunos. 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 requerimientos 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.

Ciclo de vida

El ciclo de vida RUP es una implementación del Desarrollo en espiral. Fue creado ensamblando los elementos en secuencias semi-ordenadas. El ciclo de vida organiza las tareas en fases e iteraciones.
RUP 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. En la Figura muestra cómo varía el esfuerzo asociado a las disciplinas según la fase en la que se encuentre el proyecto RUP.
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 baseline (Linea Base) de la arquitectura.
Durante la fase de inicio las iteraciones hacen mayor énfasis en actividades de modelado del negocio y de requerimientos.

En la fase de elaboración, las iteraciones se orientan al desarrollo de la baseline de la arquitectura, abarcan más los flujos de trabajo de requerimientos, modelo de negocios (refinamiento), análisis, diseño y una parte de implementación orientado a la baseline 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.

Principales características

Forma disciplinada de asignar tareas y responsabilidades (quién hace qué, cuándo y cómo)

Pretende implementar las mejores prácticas en Ingeniería de Software

Desarrollo iterativo

Administración de requisitos

Uso de arquitectura basada en componentes

Control de cambios

Modelado visual del software

Verificación de la calidad del software

El RUP es un producto de Rational (IBM). Se caracteriza por ser iterativo e incremental, estar centrado en la arquitectura y guiado por los casos de uso. Incluye artefactos (que son los productos tangibles del proceso como por ejemplo, el modelo de casos de uso, el código fuente, etc.) y roles (papel que desempeña una persona en un determinado momento, una persona puede desempeñar distintos roles a lo largo del proceso)....

Establece oportunidad y alcance

Identifica las entidades externas o actores con las que se trata

Identifica los casos de uso

RUP comprende 2 aspectos importantes por los cuales se establecen las disciplinas:
Proceso: Las etapas de esta sección son: (Revise nuevamente la gráfica)

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 de RUP 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)

Elaboración

Desarrollo(También llamado Implementación,Construcción)

Cierre (También llamado Transición)

Artefactos

RUP en cada una de sus fases (pertenecientes a la estructura estática) realiza una serie de artefactos que sirven para comprender mejor tanto el análisis como el diseño del sistema (entre otros). Estos artefactos (entre otros) son los siguientes:
Inicio:

Documento Visión

Especificación de Requerimientos

Elaboración:

Construcción:

Documento Arquitectura que trabaja con las siguientes vistas:

   Vista Lógica:

Diagrama de clases

Modelo E-R (Si el sistema así lo requiere)

   Vista de Implementación:

Diagrama de Secuencia

Diagrama de estados

Diagrama de Colaboración

   Vista Conceptual:

   Vista física:

Mapa de comportamiento a nivel de hardware.

Te esperamos en los siguientes artículos en donde hablaremos mas acerca de estos temas, los cuales hoy en día son de vital importancia en el mundo de la tecnología.

¿Te gustaría aprender Análisis y Diseño Agil Orientado a Objetos?

# data[].attributes.attachment_link.title
¿Que Es El Proceso Unificado de Rational (RUP)?)

# data[].attributes.attachment_link.description
¿Te gustaría aprender Análisis y Diseño Agil Orientado a Objetos? El Proceso Unificado Racional ( Rational Unified Process en inglés, habitualmente resumido como RUP) es un proceso de desarrollo de software y junto con el Lenguaje Unificado de Modelado UML, constituye la metodología estándar más utilizada para el análisis, implementación y documentación de sistemas orientados a objetos.

# data[].attributes.body
http://rupisw.blogspot.com/2011/11/casos-de-uso-artefactos-roles.html

# data[].attributes.attachment_link.readable_text
Un caso de uso es una descripción de los pasos o actividades que deben hacerse para realizar algún proceso. Los personajes o entidades que participarán en un caso de uso son "actores". En la ingeniería de software, un caso de uso es una secuencia de interacciones que se desarrollarán entre un sistema y sus actores en respuesta a un evento que inicia un actor principal sobre el propio sistema. Los diagramas de casos de especifican la comunicación y el comportamiento de un sistema mediante su interacción con los usuarios y/u otros sistemas (ejemplo de caso de uso: imagen de arriba).

Unidades de informacion creadas, producidas, cambiadas o utilizadas en el proceso de desarrollo, los cuales se pueden representar como documentos necesarios, desde la etapa de analisis hasta la entrega final del producto (diagrama de artefactos: imagen de arriba).

Definen el comportamiento y las tareas de el individuo o grupo de individuos que estan involucrados en el proyecto, en ciertos tipos de proyectos un individuo puede jugar mas de un rol. Los roles son descripciones de actividades realizadas y responsabilidad de artefactos. Algunos ejemplos son: Arquitecto de SW, Analista, Revisor de arquitectura, etc (roles que desempañan en este modelo: imagen de arriba).

# data[].attributes.attachment_link.description
Un caso de uso es una descripción de los pasos o actividades que deben hacerse para realizar algún proceso. Los personajes o entidades que participarán en un caso de uso son "actores".