• Author / Uploaded
• Freyja Bear

• Categories
• Software
• Redes sociales y digitales
• Tecnología digital
• Ciencias de la Computación
• Diseño

Citation preview

RUP (Proceso Unificado de Racional (Rational Unified Process)) RUP

Es un producto de Rational (IBM) Sus principales caracteristicas son: • Es iterativo e incremental • Es centrado en la arquitectura (basado en componentes) • Esta guiado por los casos de uso • Control de cambios • Verificación de la calidad del software Incluye artefactos: Son los productos tangibles del proceso, por ejemplo: modelo de casos de uso, código fuente, etc. Incluye roles: papel que desempeña una persona en un determinado momento, una persona puede desempeñar distintos roles a lo largo del proceso. RUP se basa en componentes (component-based), lo que significa que el sistema en construcción está hecho de componentes de software interconectados por medio de interfaces bien definidas (well-defined interfaces). RUP usa el Lenguaje de Modelado Unificado (UML) en la preparación de todos los planos del sistema. Los aspectos distintivos de RUP están capturados en tres conceptos clave: dirigido por casos de uso (use-case driven), centrado en la arquitectura (architecture-centric), iterativo e incremental. Esto es lo que hace único al Proceso Unificado. La arquitectura provee la estructura sobre la cual guiar el trabajo en iteraciones, mientras que los casos de uso definen las metas y dirigen el trabajo en cada iteración. El Proceso Unificado es dirigido por casos de uso Un caso de uso es una pieza en la funcionalidad del sistema que le da al usuario un resultado de valor. Los casos de uso capturan los requerimientos funcionales. Todos los casos de uso juntos constituyen el modelo de casos de uso el cual describe la funcionalidad completa del sistema. Los casos de uso no son solamente una herramienta para especificar los requerimientos del sistema, también dirigen su diseño, implementación y prueba Aún y cuando los casos de uso dirigen el proceso, no son elegidos de manera aislada. Son desarrollados a la par con la arquitectura del sistema, esto es, los casos de uso dirigen la arquitectura del sistema y la arquitectura del sistema influencia la elección de los casos de uso. Por lo tanto, al arquitectura del sistema y los casos de uso maduran conforme avanza el ciclo de vida. Proceso Unificado está centrado en la arquitectura La arquitectura en un sistema de software es descrita como diferentes vistas del sistema que está siendo construido. El concepto de arquitectura de software involucra los aspectos estáticos y dinámicos más significativos del sistema. La arquitectura surge de las necesidades de la empresa, tal y como las interpretan los usuarios y otros stakeholders, y tal y como están reflejadas en los casos de uso. Sin

embargo, también está influenciada por muchos otros factores, tales como la plataforma de software en la que se ejecutará, la disponiblidad de componentes reutilizables, consideraciones de instalación, sistemas legados, requerimientos no funcionales (ej. desempeño, confiabilidad). La arquitectura es la vista del diseño completo con las características más importantes hechas más visibles y dejando los detalles de lado. Ya que lo importante depende en parte del criterio, el cual a su vez viene con la experiencia, el valor de la arquitectura depende del personal asignado a esta tarea. Sin embargo, el proceso ayuda al arquitecto a enfocarse en las metas correctas, tales como claridad , flexibilidad en los cambios futuros y reuso. El Proceso Unificado es Iterativo e Incremental Es práctico dividir el trabajo en pequeños pedazos o mini-proyectos. Cada mini-proyecto es una iteración que finaliza en un incremento. Las iteraciones se refieren a pasos en el flujo de trabajo, los incrementos se refieren a crecimiento en el producto. Para ser más efectivo, las iteraciones deben estar controladas, esto es, deben ser seleccionadas y llevadas a cabo de una manera planeada. Las iteraciones sucesivas construyen los artefactos del desarrollo a partir del estado en el que fueron dejados en la iteración anterior. En cada iteración, los desarrolladores identifican y especifican los casos de uso relevantes, crean el diseño usando la arquitectura como guía, implementan el diseño en componentes y verifican que los componentes satisfacen los casos de uso. Si una iteración cumple sus metas el desarrollo continúa con la siguiente iteración. Cuando la iteración no cumple con sus metas, los desarrolladores deben revisar sus decisiones previas y probar un nuevo enfoque. Como filosofia, RUP maneja 6 principios básicos, en los que está basado: •

•

•

•

•

Adaptar el proceso: El proceso deberá adaptarse a las necesidades del cliente ya que es muy importante interactura con él. Las caracteristicas propias del proyecto u organización, tamaño, tipo, regulaciones que lo condicionesn, ya que influirán en su diseño en especifico. Equilibrar prioridades: Los requisitos 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 iterativamente: 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 tambien 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 requisitos, desarrollo, evaluaciones, planes, resultados, etc. 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 requisitos 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 organiza las tareas en fases e iteraciones. Fases Proceso: Las etapas de esta sección son: • 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

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. • Inicio(También llamado Incepción o Concepción) • Elaboración • Desarrollo(También llamado Implementación, Construcción) • Cierre (También llamado Transición)

Fase de Inicio: Esta fase tiene como propósito definir y acordar el alcance del proyecto con los patrocinadores, identificar los riesgos asociados al proyecto, proponer una visión muy general de la arquitectura de software y producir el plan de las fases y el de iteraciones posteriores. Fase de Elaboración: En la fase de elaboración se seleccionan los casos de uso que permiten definir la arquitectura base del sistema y se desarrollaran en esta fase, se realiza la especificación de los casos de uso seleccionados y el primer análisis del dominio del problema, se diseña la solución preliminar. Fase de Desarrollo: El propósito de esta fase es completar la funcionalidad del sistema, para ello se deben clarificar los requisitos pendientes, administrar los cambios de acuerdo a las evaluaciones realizados por los usuarios y se realizan las mejoras para el proyecto. Fase de Cierre: El propósito de esta fase es asegurar que el software esté disponible para los usuarios finales, ajustar los errores y defectos encontrados en las pruebas de aceptación, capacitar a los usuarios y proveer el soporte técnico necesario. Se debe verificar que el producto cumpla con

las especificaciones entregadas por las personas involucradas en el proyecto. DESCRIPCIÓN DE LAS ACTIVIDADES Dependiendo de las iteración del proceso el equipo de desarrollo puede realizar 7 tipos de actividades en este: FASE DE INICIO Durante la fase de inicio las iteraciones hacen ponen mayor énfasis en actividades modelado del negocio y de requisitos. Modelado del negocio En esta fase el equipo se familiarizará más al funcionamiento de la empresa, sobre conocer sus procesos. • Entender la estructura y la dinámica de la organización para la cual el sistema va ser desarrollado • Entender el problema actual en la organización objetivo e identificar potenciales mejoras. • Asegurar que clientes, usuarios finales y desarrolladores tengan un entendimiento común de la organización objetivo. Requisitos En esta línea los requisitos son el contrato que se debe cumplir, de modo que los usuarios finales tienen que comprender y aceptar los requisitos que especifiquemos. • Establecer y mantener un acuerdo entre clientes y otros stakeholders sobre lo que el sistema podría hacer. • Proveer a los desarrolladores un mejor entendimiento de los requisitos del sistema. • Definir el ámbito del sistema. • Proveer una base para estimar costos y tiempo de desarrollo del sistema. • Definir una interfaz de usuarios para el sistema, enfocada a las necesidades y metas del usuario FASE DE ELABORACIÓN En la fase de elaboración, las iteraciones se orientan al desarrollo de labaseline de laarquitectura, 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 labas eline de laarquitectura. Análisis y Diseño En esta actividadse especifican los requerimientos y se describen sobre como se van a implementar en el sistemas • Transformar los requisitos al diseño delsistema. • Desarrollar una arquitectura para el sistema. • Adaptar el diseño para que sea consistente con el entorno de implementación

}

FASE DE CONSTRUCCIÓN Implementación Seimplementan las clases y objetos en ficheros fuente, binarios, ejecutables y demás. El resultado final es un sistema ejecutable. • Planificar qué subsistemas deben ser implementados y en que orden deben ser integrados, formando el Plan de Integración. • Cada implementador decide en que orden implementa los elementos del subsistema. • Si encuentra errores de diseño, los notifica. • Se integra el sistema siguiendo el plan. Pruebas Este flujo de trabajo es el encargado de evaluar la calidad del producto que estamos desarrollando, pero no para aceptar o rechazar el producto al final del proceso de desarrollo,sino que debe ir integrado en todo el ciclo de vida. • Encontrar y documentar defectos en la calidad del software. • Generalmente asesora sobre la calidad del software percibida. • Provee la validación de los supuestos realizados en el diseño y especificación de requisitos por medio de demostraciones concretas. • Verificar las funciones del producto de software según lo diseñado. • Verificar que los requisitos tengan su apropiada implementación Despliegue Esta actividad tiene como objetivo producir con éxito distribuciones del producto y distribuirlo a los usuarios. Las actividades implicadas incluyen: • Probar el producto en su entorno de ejecución final. • Empaquetar el software para su distribución. • Distribuir el software. • Instalar el software. • Proveer asistencia y ayuda a los usuarios. • Formar a los usuarios y al cuerpo de ventas. • Migrar el software existente o convertir bases de datos

DURANTE TODO EL PROYECTO Gestión del proyecto Se vigila el cumplimiento delos objetivos, gestión de riesgos y restricciones para desarrollar un producto que sea acorde a los requisitos de los clientes y los usuarios. • Proveer un marco de trabajo para la gestión de proyectos de software intensivos. • Proveer guías prácticas realizar planeación, contratar personal, ejecutar y monitorear el proyecto. • Proveer un marco de trabajo para gestionar riesgos. Configuración y control de cambios El control de cambios permite mantener la integridad de todos los artefactos que se crean en el proceso, así como de mantener información del proceso evolutivo que han seguido. Entorno La finalidad de esta actividad es dar soporte al proyecto con las adecuadas herramientas,procesos y métodos. Brinda una especificación de las herramientas que se van a necesitar encada momento, así como definir la instancia concreta del proceso que se va a seguir. En concreto las responsabilidades de este flujo de trabajo incluyen: • Selección y adquisición de herramientas • Establecer y configurar las herramientas para que se ajusten a la organización. • Configuración del proceso. • Mejora del proceso. • Servicios técnicos

ROLES

Analistas: • Analista de procesos de negocio. • Diseñador del negocio. • Analista de sistema. • Especificador de requisitos. Desarrolladores: • Arquitecto de software. • Diseñador • Diseñador de interfaz de usuario • Diseñador de cápsulas. • Diseñador de base de datos. • Implementador. • Integrador. Gestores: • Jefe de proyecto • Jefe de control de cambios. • Jefe de configuración. • Jefe de pruebas • Jefe de despliegue • Ingeniero de procesos • Revisor de gestión del proyecto • Gestor de pruebas. Apoyo: • Documentador técnico • Administrador de sistema • Especialista en herramientas • Desarrollador de cursos • Artista gráfico Especialista en pruebas: • Especialista en Pruebas (tester) • Analista de pruebas • Diseñador de pruebas Otros roles: • Stakeholders. • Revisor • Coordinación de revisiones • Revisor técnico • Cualquier rol

ARTEFACTOS

Los artefactos son los entregables que son producidos durante y al final del proyecto. Los artefactos pueden ser: •

Un documento: Como un documento de la arquitectura de software, etc.

•

Un modelo: Como el modelo de casos de uso, o el modelo de diseño.

•

Un elemento del modelo: Es un elemento en el modelo, como una clase o un subsistema.

RUP en cada una de sus fases realiza una serie de artefactos que sirven para comprender mejor tanto el análisis como el diseño del sistema (entre otros). RUP proporciona una serie de templates o artefactos a seguir, y los cuales se pueden implementar en las faces, estos artefactos son los siguientes: Business Nombre Business Vision Business Architecture Document Business Glossary Bill of Materials Business Modeling Guidelines Business Rules Business Use-Case Specification Supplementary Business Specification Business Use-Case Realization Specification Business Case Target-Organization Assessment

Project Management Nombre Vision Vision (Small Project) Software Development Plan Software Development Plan (Small Project) Glossary Development Case Development-Organization Assessment Risk List Risk Management Plan Iteration Plan Iteration Assessment Measurement Plan Status Assessment Problem Resolution Plan Requirements Nombre Requirements Management Plan Software Requirements Specification for Subsystem Software Requirements Specification For Subsystem or Feature Use-Case-Modeling Guidelines Use-Case Specification Use-Case-Realization Specification Supplementary Specification

Development Nombre Design Guidelines Programming Guidelines Software Architecture Document Integration Build Plan

Testing and Quality Nombre Test Evaluation Summary Test Guidelines Iteration or Master Test Plan Quality Assurance Plan Test Case

Deployment Nombre Product Acceptance Plan Configuration Management Plan Deployment Plan Release Notes

Los artefctos que se propone implementar como minímo en cada una de las fases (entre otros) son los siguientes: Inicio: • Documento Visión • Especificación de Requisitos Elaboración: • Diagramas de caso de uso Desarrollo: • 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 • Modelo de dominio Vista física • Mapa de comportamiento a nivel de hardware.