PROCESO UNIFICADO DE RATIONAL- ANÁLISIS

PRESENTACIÓN

En el presente trabajo presentaremos sobre tema de Proceso Unificado de Rational – Análisis, se explicará sobre los flujos de trabajo de análisis, Modelo en Flujo de Trabajo de Análisis que a su vez contienen Diagramas de Interacción, Diagramas de Estados, Diagrama de Actividades, Diagramas de Clases. Cabe resaltar que no solo puntualizaremos los temas sino que explicaremos cada punto buscando mejorar a la calidad del estudiante al cual expondremos este tema.Hay que tener en cuenta que el concepto de Proceso unificado de Rational se define como: a) algo innovador ya que aporta cosas nuevas al mercado, b) creador de valor a través de la generación de nuevas fuentes de trabajo y rentabilidad y c) orientado al crecimiento debido a que tiene una visión clara de hasta donde se quiere llegar. Para ello se analizará la oferta hotelera actual como así también los principales drivers que consideran los viajantes a la hora de elegir un hotel.

INTRODUCCIÓN

Durante varios años se ha utilizado el modelo tradicional en cascada, demostrando en la práctica que no refleja en la realidad la complejidad inherente al proceso de desarrollo de software. Este problema es derivado de la naturaleza implícita de la estructura de este modelo, definido por una secuencia de grandes etapas que requieren alcanzar hitos que deben ser concluidos antes de continuar con la siguiente fase.

Como una alternativa de solución a este problema, se definieron posteriormente los modelos iterativos e incrementales que trabajan adecuadamente con niveles altos de riesgo, y permiten entregar liberaciones de software en etapas tempranas; tal es el caso del PROCESO UNIFICADO propuesto por IBM, que incluye prácticas claves y aspectos relacionados a la planeación estratégica y administración de riesgos; y actualmente guían de forma natural el proceso de desarrollo de software complejo por lo que ha sido considerado como un estándar el desarrollo de software en las empresas.

El proceso unificado conocido como RUP, es un modelo de software que permite el desarrollo de software a gran escala, mediante un proceso continuo de pruebas y retroalimentación, garantizando el cumplimiento de ciertos estándares de calidad. Aunque con el inconveniente de generar mayor complejidad en los controles de administración del mismo. Sin embargo, los beneficios obtenidos recompensan el esfuerzo invertido en este aspecto.

OBJETIVOS

 Lograr priorizar los objetivos requerimientos, y tecnologías de los diferentes proyectos de desarrollo de software

 Cómo utilizar de forma efectiva reglas de negocio y procedimientos comerciales probados en el desarrollo de software para equipos de desarrollo de software, conocidos como “mejores prácticas”

CONTENIDO

PROCESO UNIFICADO DE RATIONAL – ANÁLISIS

I. Flujo de Trabajo de Análisis

II. Artefactos de Análisis

III. Modelos de Flujo de Trabajo de Análisis

3.1 Diagramas de Interacción

3.1.1 Diagrama de Colaboraciones/ Comunicaciones

3.1.2 Diagrama de Secuencias

3.1.3 Flujo de Eventos

3.2 Diagramas de Estado

3.3 Diagrama de Actividades

3.4 Diagramas de Clases

3.5 Modelo de Datos (DATA MODELER)

3.6 Generación de Código Fuente (SQL)

I. FLUJO DE TRABAJO DE ANALISIS

Un Flujo de Trabajo es una secuencia de actividades que produce un resultado valioso.

No siempre es posible representar flujos de trabajo.

Una lista de actividades, trabajadores y artefactos constituye un proceso.

Esta disciplina explica cómo transformar los productos de trabajo de los requisitos en los productos de trabajo que especifiquen el diseño del software que el proyecto va a desarrollar.

Aunque RUP contempla Análisis y Diseño en mismo Flujo de Trabajo por estar muy relacionadas, son actividades y artefactos diferentes.

Es la descripción de cómo se implementara el sistema.

Se debe de:

 Ejecutar las tareas y funciones descritas en los casos de uso.

 Satisfacer todos los requerimientos.

 Flexible a cambios.

FLUJOS DE TRABAJO ESCENCIALES

 Existen habitualmente problemas de comunicación entre ingenieros de software e ingenieros de comunicación.

 RUP proporciona un lenguaje para estos dos ámbitos.

 Para el modela miento del negocio se usan “busines use cases” (caso de uso de negocio)

Requerimientos:

Los desarrolladores y clientes deben acordar que el sistema debe hacer:

 Revelar requerimientos.

 Documentar funcionalidad y restricciones.

 Documentar decisiones.

 Identificar actores.

 Identificar casos de uso.

 Los casos de uso describen la funcionalidad.

 Los requerimientos no funcionales se incluyen en una especificación complementaria.

II. ARTEFACTOS DE ANALISIS

a. PAQUETE DEL ANALISIS

 Cuando se trabaja en sistemas medianamente complejos se necesita agrupar las clases en módulos lógicos que permitan favorecer la reutilización, que se vuelva más fácil manipular la complejidad y distribuir el trabajo entre los miembros del equipo, por esta razón aparecen los paquetes de análisis.

 Todos los elementos que se encuentran dentro de un paquete del análisis no son necesariamente visibles desde el exterior, es decir, un paquete encapsula a la vez que agrupa.

b. CLASE DE ANALISIS

 Modelo conceptual temprano que describe las características y comportamiento comunes de un conjunto de cosas que existen en el sistema.

 Las clases del Análisis están siempre identificadas con uno de los tres estereotipos siguientes:

 Interfaz (Boundary): se encargan de la modelación de toda la interacción que puede existir entre los actores y el sistema. Constituyen las fronteras del sistema.

 Control: representan la coordinación, secuenciación, transacciones y a veces la lógica del negocio. Se

...