Universidad de San Martn de Porres

Facultad de Ingeniera y Arquitectura Curso de Especializacin Profesional / 2008 - II Curso: Ingeniera de Software Orientada a Objetos
Mg. Ing. Gner Zambrano L.
gzambrano@usmp.edu.pe

Sesin 03 RUP

Contenido:
Describir las 6 mejores prcticas en desarrollo de software. Describir el Rational Unified Process (RUP) en trminos de sus fases y disciplinas. Describir el modelo iterativo para desarrollo de software Comprender los fundamentos del proceso de trabajo del RUP deacuerdo a las necesidades especficas de la organizacin

RUP

RUP

Desarrollo de Sistemas

Notacin: UML

Herramientas: Suite Rational Visual Paradigm Poseidon

Proceso: Rational Unified Process Mtrica 3.0 XP

Qu es Rup?
El Proceso Unificado de Rational (RUP, el original ingls Rational Unified Process) es un proceso de desarrollo de software y junto con el Lenguaje Unificado de Modelado UML, constituye la metodologa estndar ms utilizada para el anlisis, implementacin y documentacin de sistemas orientados a objetos. RUP fue creado por Rational software, filial IBM. RUP est basado en el seguimiento de una serie de normas o mejores prcticas aplicadas a cuatro etapas del desarrollo software: iniciacin, elaboracin, construccin y transicin. Objetivos:
Asegurar la produccin de software de calidad dentro de

plazos. Presupuestos predecibles. Dirigido por casos de uso, centrado en la arquitectura, iterativo (mini-proyectos) e incremental (versiones).

Rup, Evolucin:
Pruebas de rendimiento y carga (Performance Awareness) 1998 Ingeniera de Negocios Administracin de Configuracin y Cambios (Pure-Atria) 1997 Escuela de Requerimientos (Requisite Inc.) Rational Objectory Process 4.1 Rational Unified Process 5.0 Diseo OO de IU Ingeniera de Datos (Vigortech) UML 1.2 Proceso SQA (SQA Inc.) UML 1.0

1996

OMT Booch

Rational Objectory Process 4.0

UML 0.8

1995 1987 1967

Rational Approach

Objectory Process Ericsson method

RUP, estructura: Workflow, Workflow Detail , Roles, Actividades y Artefactos Ejemplo

Workflow: Requirements Workflow Detail:Analyse the Problem

Roles Actividades

Artefactos

RUP, elementos: Unidad de trabajo que puede ejecutar un individuo en un rol especfico Ejemplo: Cmo?
Quin lo hace? Rol: System Analyst: Actividad: Desarrollo de la visin

Qu se produjo? Artefacto: Resultado

Elementos del RUP: Workflows (Qu se est haciendo?) Workflows Primarios Business Modeling (Modado del Negocio) Requirements (Requisitos) Analysis & Design (Anlisis y Diseo) Implementation (Implementacin) Test (Pruebas) Deployment (Despliegue) Workflows de Apoyo Environment (Entorno) Project Management (Gestin del Proyecto) Configuration & Change Management (Gestin de Configuracin y Cambios)

Elementos en RUP: Roles Definen el comportamiento y responsabilidades de los participantes del equipo de trabajo. Analyst: Business-Process Analyst Business Designer Business-Model Reviewer Requirements Reviewer System Analyst Use-Case Specifier User-Interface Designer Developer: Architect Architecture Reviewer Capsule Designer Code Reviewer Database Designer Design Reviewer Designer Implementer Integrator

...continua, Elementos

en RUP: Roles Other: Course Developer Graphic Artist Stakeholder System Administrator Technical Writer Tool Specialist

Testing professional: Test Designer Tester Manager: Change Control Manager Configuration Manager Deployment Manager Process Engineer Project Manager Project Reviewer

Caractersticas del RUP

Caractersticas escenciales del RUP:

Guiado y Manejado por Casos de Uso

Centrado en la Arquitectura

Iterativo e Incremental

...continua, Caractersticas

escenciales del RUP:

Guiado y Manejado por Casos de Uso

Requisitos Anlisis y &Diseo Diseo Anlisis Implementacin Pruebas

Casos de Uso integran el trabajo

Capturar, definir y validar los casos de uso Realizar los casos de uso Verificar que se satisfacen los casos de uso

...continua, Caractersticas

escenciales del RUP:

Centrado en la Arquitectura

Arquitectura de un sistema es la organizacin o estructura de sus partes ms relevantes Un arquitectura ejecutable es una implementacin parcial del sistema, construida para demostrar algunas funciones y propiedades RUP establece refinamientos sucesivos de una arquitectura ejecutable, construida como un prototipo evolutivo
Inception Elaboration Construction Transition

Architecture

...continua, Caractersticas

escenciales del RUP:

Iterativo e Incremental El ciclo de vida iterativo se basa en la evolucin de prototipos ejecutables que se muestran a los usuarios y clientes En el ciclo de vida iterativo a cada iteracin se reproduce el ciclo de vida en cascada a menor escala Enfoque Cascada

Enfoque Iterativo e Incremental

Las mejores prcticas del RUP

MEJORES PRCTICAS DEL RUP

I. Desarrolle Iterativamente
III. Use Arquitectura de Componentes

II. Administre los Requerimientos

IV. Modele Visualmente

V. Verifique Calidad

VI. Controle los Cambios

I. Desarrollo iterativo (reducir riesgos y tiempo)

El software moderno es complejo y novedoso. No es realista usar un modelo lineal de desarrollo como el de cascada. Un proceso iterativo permite una comprensin creciente de los requerimientos a la vez que va creciendo el sistema. Es necesario utilizar un acercamiento iterativo que permita un entendimiento incremental del problema a travs de refinaciones sucesivas, creando de manera incremental una solucin efectiva mediante mltiples iteraciones. Con esto se logra reducir los riesgos del proyecto. Las ventajas principales son: Mitigacin de riesgos Acomodacin de cambios Alcanzar la ms alta calidad Aumento de la reutilizacin

II. Administracin de Requisitos

(El primer paso del xito del proyecto )

El fracaso de un proyecto radica en la mala (o ausencia) administracin de los requerimientos.

II. Administracin de Requisitos, continua...

Los principales problemas de un mal manejo de requerimientos son: Incapacidad para manejar los cambios en los requerimientos durante el desarrollo. Falta de especificacin detallada de los requerimientos. Mala organizacin y control de requerimientos. Requerimientos mal entendidos. Pasos en la Administracin de Requerimientos: Analizar el problema Entender las necesidades del inversionista Definir el sistema Refinar la definicin del sistema Administrar el control de requerimientos

Los casos de uso y los escenarios indicados por el proceso han probado ser una buena forma de captar requerimientos y guiar el diseo, la implementacin y las pruebas.

III. Componentes Arquitectnicos

(La base para la reutilizacin de software)

Uno de los peligros en sistemas grandes y complejos es que al hacer cambios a una parte de la aplicacin se impacten otras partes con el "efecto domin". Los equipos de desarrollo exitosos resuelven estas dependencias potenciales a travs del uso de arquitecturas basadas en componentes. El ensamble de aplicaciones mediante mdulos manejables crea arquitecturas resistentes y flexibles que evitan que los cambios al software conlleven esfuerzos masivos. A medida que las organizaciones reutilizan componentes, reducen la cantidad de cdigo a generar para cada aplicacin. As logran acelerar el tiempo de desarrollo y reducen la probabilidad de introducir errores al sistema.

III. Componentes Arquitectnicos, continua...

La arquitectura debe ser: Flexible Fcil de modificar Intuitivamente comprensible Promueve la reutilizacin de componentes

Organizacin de los componentes del sistema

IV. Modelado Visual UML (Los planos del xito)

Para describir la complejidad de las operaciones actuales, los equipos de desarrollo necesitan una manera altamente descriptiva, intuitiva y precisa para modelar toda la funcionalidad del sistema. Desarrollar bloques de construccin: Ocultan detalles Permiten la comunicacin en el equipo de desarrollo Permiten analizar la consistencia: entre las componentes entre diseo e implementacin UML es la base del modelamiento visual de RUP. El RUP describe cmo modelar visualmente aplicaciones para capturar la estructura y el comportamiento de la arquitectura y de los componentes.

V. Verificacin de la Calidad
(Construyendo con calidad de principio a fin)

Calidad: La caracterstica de demostrar el logro de la realizacin de un producto, que satisface los requerimientos convenidos Segn lo estimado y conducido por un proceso conveniente. Es mucho ms costoso detectar y arreglar errores ya en produccin que encontrarlos en etapas tempranas Tres Dimensiones de la Calidad: Funcionalidad: la aplicacin hace lo requerido? Confiabilidad: la aplicacin responde aceptablemente? Rendimiento: la aplicacin rinde bajo cargas de produccin?

VI. Control de Cambios

(Controlar el proyecto y eliminar los retrasos)

Gerencia del espacio de trabajo

Desarrollo paralelo

Integracin

Gerencia de la estructura

Los cambios son inevitables, pero es necesario evaluar si stos son necesarios y rastrear su impacto.

VI. Control de Cambios, continua...

El trabajo efectivo requiere de una administracin formal de los cambios. Cuando se cuenta con una administracin de cambios del software realmente efectiva se logra que: Los desarrolladores manipulen y controlen con orden y seguridad sus enormes colecciones de archivos y componentes para cada aplicacin. Coordinacin de artefactos y actividades Coordinacin de iteraciones y releases Control de cambios de software Control de las versiones de los artefactos

Estructura del Rup

Estructura del Rup F. Trabajo Procesos

Modelacin de Negocios Requerimientos Anlisis y Diseo

Fases Fases
Inicio Elaboracin Construccin Transicin

Disciplinas

Implementacin Prueba Despliegue

F. Trabajo Soporte
Admin. Configuracin Administracin Ambiente
Iteracin(es) Preliminar Iter. #1 Iter. #2 Iter. #n Iter. #n+1 Iter. #n+2 Iter. #m Iter. #m+1

Iteraciones

La Plataforma Rational
RequisitePro, XDE, Rose Requirements & Use Cases Rose /RQA, XDE, Rose + IDE Test RT, Purify+ Code Unit Tests

XDE, Rose Models

TestManager Test Plan

TestManager Test Cases

TestManager Robot, Test RT System Tests

TestManager Test Results

ClearQuest Defects

Common Process and Guidance Rational Unified Process, Rational Developer Network Progress Metrics and Reporting SoDA, ProjectConsole Software Configuration Management ClearCase, ClearQuest

Estructura del RUP, ejes: El proceso puede describirse en dos dimensiones, o a lo largo de dos ejes: El eje horizontal representa tiempo y muestra el aspecto dinmico del proceso, expresado en trminos de ciclos, fases, iteraciones, y metas. El eje vertical representa el aspecto esttico del proceso; como est descrito en trminos de actividades, artefactos, trabajadores y flujos de trabajo. Representa las disciplinas que agrupan actividades por su naturaleza.

Fases del Rup:

El ciclo de vida del Rup esta representado y organizado por fases: 1. En cuanto a tiempo el ciclo de vida de RUP se descompone en 4 fases secuenciales, cada cual concluye con un producto intermedio. 2. Al terminar cada fase se realiza una evaluacin para determinar si se ha cumplido o no con los objetivos de la misma. 3. Las fases son: Inicio (Inception), Elaboracin, Construccin y Transicin.

Fases del Rup Cundo se hace? I. Fase de Inicio (los objetivos del ciclo de vida) Objetivo general: El objetivo general de esta fase es establecer un acuerdo entre todos los interesados acerca de los objetivos del proyecto. Esta fase es significativamente primaria para el desarrollo de nuevo software, ya que se asegura de identificar los riesgos relacionados con el negocio y requerimientos. Para proyectos de mejora de software existente esta fase es ms breve y se centra en asegurar que vale la pena y es posible, desarrollar el proyecto.

I. Fase de Inicio (los objetivos del ciclo de vida) Objetivos especficos: Establecer el alcance del proyecto, incluyendo la visin operacional, criterio de aceptacin, qu se espera del producto y qu no. Discriminar los casos de uso crticos del sistema, los escenarios primarios de operacin que dirigirn las principales decisiones de diseo. Mostrar al menos una arquitectura candidata para alguno de los escenarios primarios. Estimar el coste global y planificacin para el proyecto completo (estimaciones ms precisas se obtendrn en la fase siguiente).

I. Fase de Inicio (los objetivos del ciclo de vida)

Objetivos del Ciclo de Vida Concepcin Elaboracin Construccin Transicin

Hito: Las partes interesadas deben acordar el mbito del proyecto identificando los principales riesgos y la viabilidad del mismo. El alcance y la estimacin de tiempo y costo. Comprensin de los requerimientos plasmados en casos de uso.

I. Fase de Inicio, productos (artefactos):

Identificacin inicial de riesgos. Plan de proyecto. Caso de negocio: Contexto Criterios de xito Pronstico financiero Un documento de visin general: Requerimientos generales del proyecto Caractersticas principales Restricciones Modelo inicial de casos de uso (10% a 20 % listos). Prototipos. Glosario.

II. Fase de Elaboracin (la arquitectura del ciclo de vida) Objetivo general: El objetivo en esta fase es establecer la arquitectura base del sistema para proveer bases estables para el esfuerzo de diseo e implementacin en la siguiente fase. La arquitectura debe abarcar todos las consideraciones de mayor importancia de los requerimientos y una evaluacin del riesgo.

II. Fase de Elaboracin (la arquitectura del ciclo de vida) Objetivos especficos:
Analizar el dominio del problema. Desarrollar un plan de proyecto Establecer la lnea base de la arquitectura slida

obtenida despus significativos.

de

tratar

los

escenarios

ms

Establecer el ambiente de soporte para el proyecto. Esto

incluye crear los planes de desarrollo, preparar las plantillas de los documentos, instrucciones, y herramientas.

II. Fase de Elaboracin, Hito:

Arquitectura a desarrollar en el Ciclo de Vida

Concepcin

Elaboracin

Construccin

Transicin

Condiciones de xito de la elaboracin: Es estable la visin del producto? Es estable la arquitectura? Las pruebas de ejecucin demuestran que los riesgos han sido abordados y resueltos? Es el plan del proyecto algo realista? Estn de acuerdo con el plan todas las personas involucradas? Obtener una lnea base de la arquitectura del sistema, capturar la mayora de los requisitos y reducir los riesgos principales as como permitir la escalabilidad del equipo del proyecto durante la fase de construccin.

II. Fase de Elaboracin, productos:

Modelo de casos de uso (80% completo) con descripciones

detalladas.
Otros requerimientos funcionales o no, asociados a casos de

uso.
Descripcin de la Arquitectura del Software Un prototipo ejecutable de la arquitectura. Lista revisada de riesgos y del caso de negocio. Plan de desarrollo para el resto del proyecto.

III. Fase de Construccin (Capacidad operativa inicial) Objetivo general: El objetivo de la fase de construccin es clarificar los requerimientos faltantes y completar el desarrollo del sistema basados en la arquitectura base. Vista de cierta forma esta fase es un proceso de manufactura, en el cual el nfasis se torna hacia la administracin de recursos y control de las operaciones para optimizar costos, tiempo y calidad

III. Fase de Construccin (Capacidad operativa inicial) Objetivos especficos: El nfasis est en la produccin eficiente y no ya en la creacin intelectual. Obtener versiones tiles (alfa, beta, y otras entregas de prueba). Desarrollar de forma iterativa e incremental un producto completo que est listo para su transicin hacia la comunidad de usuarios. Decidir si el software, sitio y usuarios estn listos para la instalacin de la aplicacin.

III. Fase de Construccin, Hito:

Capacidad Operacional

Concepcin

Elaboracin

Construccin

Transicin

Condiciones de xito: El producto est maduro y estable para instalarlo en el ambiente del cliente? Estn los interesados listos para recibirlo?

Desarrollo del sistema con calidad de produccin, y puede entonces prepararse para la entrega al equipo de transicin. En esta fase, toda la funcionalidad ha sido implementada, y completadas las pruebas para el estado alfa de la aplicacin.

III. Fase de Construccin, productos: Modelo completo de casos de uso y diseo Liberaciones de productos ejecutables de funcionalidad incremental Documentacin de usuario El producto de software integrado y corriendo en la plataforma adecuada. Una liberacin beta del producto

IV. Fase de Transicin, continua... Objetivo general: Esta fase se enfoca en asegurar que el software este disponible para sus usuarios. Esta fase se puede subdividir en varias iteraciones, adems incluye pruebas del producto para poder hacer el entregable del mismo, as como realizar ajuste menores de acuerdo a los propuestos por el usuario. En este punto, la retroalimentacin de los usuarios se centra en depurar el producto, configuraciones, instalacin y aspectos sobre utilizacin

IV. Fase de Transicin, continua... Objetivos especficos:

1. Realizar pruebas para validar el nuevo sistema con las expectativas de los usuarios. Realizar pruebas y la operacin en paralelo al sistema anterior que se est reemplazando. 2. Entrenamiento de usuarios y encargados del mantenimiento. 3. Actividades de correccin de errores, mejoras en el funcionamiento y rendimiento y usabilidad. 4. Evaluacin de la lnea base de la instalacin con la visin completa y criterios de la aceptacin del producto y lograr el consenso de los involucrados. 5. Ingeniera especfica de instalacin: produccin de los paquetes, etc. comercializacin y

IV. Fase de Transicin, continua...

Concepcin Elaboracin Construccin Transicin

Producto. Sacar el producto final

Consiste en decidir si los objetivos se cumplieron y si debe comenzarse otro ciclo de desarrollo. Es el resultado de la revisin y aceptacin por parte del cliente de los productos y subproductos que le han sido entregados.

IV. Fase de Transicin, productos:

Liberaciones

ejecutables

de

producto

(comparacin

paralela con sistemas antiguos) Pruebas beta para validar el nuevo sistema vs. las expectaciones del usuario Manuales de usuario actualizados Documentacin de desarrollo actualizada Entrenamiento de usuarios Distribucin del producto.

Fases del Rup, Hitos:

Compromiso de recursos para fase elaboracin Concepcin Elaboracin Construccin Aceptacin del cliente

Transicin Liberacin Producto

Tiempo
Hito Objetivos, visin Hito Arquitectura Hito Capacidad Operacional

Una Iteraccin es una secuencia de actividades con un plan establecido y criterio de evaluacin, que da como resultado una versin del sistema.

Fases del Rup, Artefactos:

Disciplinas, flujos de trabajo:

I. Modelo del Negocio Para conseguir sus objetivos, una empresa organiza su actividad por medio de un conjunto de procesos de negocio. Cada uno de ellos se caracteriza por una coleccin de datos que son producidos y manipulados mediante un conjunto de tareas, en las que ciertos agentes (por ejemplo, trabajadores o departamentos) participan de acuerdo a un flujo de trabajo determinado. Adems, estos procesos se hallan sujetos a un conjunto de reglas de negocio, que determinan la estructura de la informacin y las polticas de la empresa. La finalidad del modelado del negocio, es describir cada proceso del negocio del cliente, especificando sus datos, actividades (o tareas), roles (o agentes) y reglas de negocio.

II. Requerimientos
Los desarrolladores y clientes deben acordar qu es lo que el sistema debe hacer: Relevar requerimientos Documentar funcionalidad y restricciones Documentar decisiones Identificar actores Identificar CU Los casos de uso describen la funcionalidad del sistema. Los requerimientos no funcionales se incluyen en una especificacin complementaria.

Permite definir la interfaz de usuario (prototipo) del sistema enfocndose en sus necesidades.

III. Anlisis y Diseo

Descripcin de cmo se implementar el sistema (planos). Debe: Desarrollar las tareas y funciones descritas en los casos de uso Satisfacer todos los requerimientos Ser flexible a cambios El diseo se centra en una arquitectura robusta. Disear y validar la arquitectura es una tarea esencial. El modelo de diseo consta de: Clases estructuradas en paquetes Diseo de subsistemas con interfaces definidas (componentes) Colaboracin entre las clases.

IV. Implementacin Objetivos: Definir la organizacin del cdigo Implementar clases y objetos en forma de componentes (fuente, ejecutables, etc.) Probar los componentes desarrolladas Integrar los componentes (resultados) en un sistema ejecutable La disciplina de implementacin limita su alcance a como las clases individuales sern probadas. Las pruebas del sistema son descritas en futuras disciplinas.

V. Pruebas
Esta disciplina acta como un proveedor de servicios a las otras disciplinas en muchos aspectos. Pruebas se enfoca principalmente en la evaluacin y aseguramiento de la calidad del producto, desarrollado a travs de las siguientes prcticas Encontrar fallas de calidad en el software y documentarlas. Recomendar sobre la calidad percibida en el software. Validar y probar las suposiciones hechas durante el diseo y la especificacin de requerimientos de forma concreta. Validar que el software trabaja como fue diseado. Validar que los requerimientos son implementados apropiadamente

Su objetivo es encontrar y documentar los defectos en la calidad del software

VI. Distribucin
Una vez que el producto de software a sido implementado y probado exitosamente, es momento de hacerlo llegar a sus usuarios finales. Incluye varias actividades: Producir un release Empaquetar el software Distribuir el software Instalar el software Apoyar a los usuarios A veces tambin incluye: Realizar pruebas beta Migracin de datos Aceptacin formal La mayor parte de la distribucin ocurre durante la transicin.

Disciplinas, flujos de soporte:

I. Gestin del Cambio y Configuracin

Consiste en controlar los cambios y mantener la integridad de los productos que incluye el proyecto. El cambio es un factor de riesgo crtico en los proyectos de software. Los artefactos software cambian no slo debido a acciones de mantenimiento posteriores a la entrega del producto, sino que durante el proceso de desarrollo, especialmente importantes por su posible impacto son los cambios en los requisitos. Por otra parte, otro gran desafo que debe abordarse es la construccin de software con la participacin de mltiples desarrolladores, posiblemente distribuidos geogrficamente, trabajando a la vez en una release, y quizs en distintas plataformas.

II. Administracin de Proyectos Es el arte de balancear objetivos en competencia, gestionar los riesgos y sobreponerse a las restricciones para crear con xito un producto que satisfaga las necesidades tanto de los clientes como de los usuarios finales. El propsito de la Administracin de Proyectos es: Proveer un marco de trabajo para administrar los proyectos intensivos de software. Proveer guas prcticas para la planeacin, soporte, ejecucin y monitoreo de proyectos. Proveer un marco de trabajo para la administracin del riesgo.

III. Ambiente

Proporciona a la organizacin el entorno de desarrollo de software apropiado, que contendr las herramientas de desarrollo y del proceso, plantillas, documentos, convenciones a seguir, y cualquier otro elemento necesario para llevar adelante con xito el desarrollo del proyecto. Ambiente y herramientas de desarrollo que harn posible llevar a cabo el proyecto.

Fin de la sesin 03 RUP