INTEGRANTES:

Rational Unified Process

Introduccin Historia del Rational Unified Process Best Practices for Software Development Teams : Requirements Management Disciplinas Fases Cmo fallar con el RUP ventajas Desventajas conclusiones

Que es el Rational Unified Process (RUP)?

RUP es un marco de referencia de procesos Modelado en SPEM (Software Process Engineering Metamodel) Influenciado por patrones de Proceso/Anlisis Bien documentado RUP es una enorme base de conocimiento en Ingeniera del Software Desarrollado por Rational (IBM)

Que es el Rational Unified Process (RUP)?

Caracterizado por:
Iterativo e incremental Dirigido por casos de uso Centrado en la arquitectura software La gestin del proyecto se orienta a la gestin de riesgos

Historia del Rational Unified Process

Introduccin

Rational Unified Process

Best Practices for Software Development Teams: 1. 2. 3. 4. 5. 6. Develop software iteratively MANAGE REQUIREMENTS Use component-based architectures Visually model software Verify software quality Control changes to software

Requirements Management
Usted debe asegurarse de:
resolver el problema correcto construir el sistema correcto

mediante la adopcin sistemtico para:

elicitar organizar documentar gestionar

de

un

enfoque

las necesidades cambiantes de una aplicacin de software.

Requirements Management
Entendimiento de requerimientos: 1. Necesidades de los stakeholders.
Preguntas del tipo: cul es el problema a resolver? cul es el criterio de xito? Establecen condiciones y contexto para el sistema.

2. Caractersticas del sistema.

Se cambia del qu al cmo.

3. Requerimientos de software.
Especifican funcionalidades entendibles por usuarios y desarrolladores.

Definiciones
REQUISITO:
Una condicin o capacidad que el sistema debe cumplir.

GESTIN DE REQUISITOS:
Un enfoque sistemtico para:
Elicitacin, organizacin y documentacin de requisitos. Establecer y mantener un acuerdo entre el cliente/usuario y el equipo del proyecto frente a las necesidades cambiantes.

Definiciones
REQUISITO:
Una condicin o capacidad que el sistema debe cumplir.

GESTIN DE REQUISITOS:
Un enfoque sistemtico para:
Elicitacin, organizacin y documentacin de requisitos. Establecer y mantener un acuerdo entre el cliente/usuario y el equipo del proyecto frente a las necesidades cambiantes.

Mapa del territorio

Requisitos accesibles para todo el equipo

RequisitePro: Estructura del proyecto

Vista Esttica y dinmica de RUP

Arquitectura general del RUP

El diagrama muestra la arquitectura general del RUP, que tiene dos dimensiones: el eje horizontal representa el tiempo y muestra los aspectos del ciclo de vida del proceso de medida que se desarrolla el eje vertical representa las disciplinas, que las actividades de grupo lgicamente por naturaleza. La primera dimensin representa el aspecto dinmico del proceso de su adopcin, y se expresa en trminos de fases, iteraciones e hitos. La segunda dimensin representa el aspecto esttico del proceso: cmo se describe en trminos de componentes de proceso, disciplinas, actividades, flujos de trabajo, artefactos y roles (ver Conceptos clave). El diagrama muestra cmo el nfasis vara con el tiempo. Por ejemplo, en las primeras iteraciones, pasamos ms tiempo en los requisitos y en las iteraciones ms tarde que pasamos ms tiempo en la aplicacin.

Elementos del proceso

Disciplinas de desarrollo

Requirements workflow
Actividades
Las funciones y los objetos desarrollados en la disciplina de Requerimientos.

Propsito de la Disciplina de Requerimientos

Establecer y mantener un acuerdo con los clientes y otras partes interesadas sobre lo que el sistema debe hacer. Para ofrecer a los desarrolladores de sistemas una mejor comprensin de los requisitos del sistema. Para definir los lmites de (delimitan) el sistema. Para proporcionar una base para la planificacin de los contenidos tcnicos de las iteraciones. Para proporcionar una base para la estimacin de costos y tiempo para desarrollar el sistema. Para definir una interfaz de usuario para el sistema, centrndose en las necesidades y objetivos de los usuarios.

Dificultades Recopilacin de Requerimiento

Los requisitos que no siempre son evidentes, y pueden provenir de muchas fuentes. Los requisitos que no siempre son fciles de expresar claramente en palabras. Hay muchos tipos diferentes de requisitos en diferentes niveles de detalle. El nmero de requisitos puede llegar a ser difcil de manejar si no se controla.

Dificultades Recopilacin de Requerimiento

Los requisitos se relacionan entre s y tambin a otros entregables del proceso de ingeniera de software. Requisitos tienen propiedades nicas o valores de propiedad. Por ejemplo, no son ni tan importante ni igual de fciles de cumplir. Hay muchas partes interesadas, lo que significa que los requisitos deben ser administrados por grupos interdisciplinarios de personas. Requisitos cambian.

Requirements workflow
Para ayudar a explicar la disciplina Requerimientos, hemos organizado las actividades y artefactos en los detalles del flujo de trabajo. Cada detalle flujo de trabajo representa una habilidad clave que necesita ser aplicado para llevar a cabo la gestin de requisitos eficaz. Analizar el problema y entender las necesidades de soporte de la estaca se centran en la fase inicial de un proyecto, mientras que el nfasis se defina en el sistema y mejorar la definicin del sistema durante la fase de elaboracin. Gestin del Alcance del Sistema y Administracin de cambio de las necesidades se hacen continuamente a lo largo del proyecto.

Actividad: Analizar el problema

Propsito:
Obtener un acuerdo sobre el problema a resolver, Identificar a los interesados, Definir los lmites del sistema, y Identificar las limitaciones impuestas en el sistema

Tcnicas de muestreo:
Lluvia de ideas diagramas de espina pescado diagramas de Pareto de

Actividad: Analizar el problema

Actividad: Conocer las necesidades del interesado

Propsito:
Es recoger y obtener informacin de las partes interesadas en el proyecto con el fin de entender cules son sus necesidades son realmente.

Tcnicas de muestreo:
Entrevistas Requisitos del Taller Lluvia de ideas y la reduccin idea Revisin de los requisitos existentes Taller de Casos de Uso Storyboarding juego de roles

Actividad: Conocer las necesidades del interesado

Actividad: Definir el sistema

Propsito:
Alinear el equipo del proyecto en su comprensin del sistema. Realizar un anlisis de alto nivel de los resultados de recogida de solicitudes de las partes interesadas. Acotar la visin para incluir las caractersticas para incluir en el sistema, junto con los atributos correspondientes. Acotar el modelo de casos de uso, para incluir los casos de uso definidos. Ms documentar formalmente los resultados de los modelos y documentos. Requisitos del Taller Taller de Casos de Uso Storyboarding

Tcnicas de muestreo:

Actividad: Definir el sistema

Actividad: Gestionar el mbito del sistema

Propsito: Priorizar y refinar de entrada para la seleccin de caractersticas y requisitos que se van a incluir en la iteracin actual. Definir el conjunto de casos de uso (o escenarios) que representan algunas significativa funcionalidad central. Definir los atributos y requisitos traceabilities de mantener. El equipo de arquitectura, encabezar una reunin para discutir la mejor manera de priorizar las necesidades.

Actividad: Gestionar el mbito del sistema

Actividad: Perfeccionar la definicin del sistema

Propsito: Describir el flujo del caso de uso de los acontecimientos en detalle. Especificaciones suplementarias Detalle. Desarrollar una especificacin de requisitos de software, si se necesita ms detalles, y Modelo y prototipo de la interfaz de usuario. Especificadores de Requisitos y diseadores de la interfaz de usuario deben colaborar estrechamente para definir los requisitos detallados del sistema. Aunque gran parte del trabajo se realiza de forma individual, tutoriales frecuentes se deben realizar para que el equipo est en sincrona.

Actividad: Perfeccionar la definicin del sistema

Actividad: Gestionar cambios de requisitos

Propsito: Evaluar las solicitudes de cambio presentadas formalmente y determinar su impacto en el conjunto requisito existente. Estructurar el modelo de casos de uso. Establecer atributos y traceabilities requisitos adecuados. Formalmente verificar que los resultados de la disciplina Requisitos ajustan a la vista del cliente del sistema. El equipo de desarrollo debe llevar a cabo unas cuantas rondas de recorridos internos para limpiar las incoherencias innecesarias antes de que su trabajo es inspeccionado y revisado de manera ms formal por el equipo extendido.

Actividad: Gestionar cambios de requisitos

Paginas de interes
http://cgrw01.cgr.go.cr/rup/RUP.es
http://sce.uhcl.edu/helm/rationalunifiedprocess/ http://www.cycoda.com/html/bmdomain.html

Fases del desarrollo

4 fases: Inicio Elaboracin Construccin Transicin Conceptos importantes: Milestone (Criterios) Aproximaci6n Iterativa e Incremental

Inception Phase (Objetivos)

Entender que se va a construir (Visin Document, Brainstorming Sessions) identificar los puntos clave del proyecto Definir, al menos, una posible solucin Entender cuales son los costes, tiempos, y los riesgos del proyecto (Business Case) Decidir el proceso a seguir y las herramientas a usar (Development case)

Inception Phase(Lifecycle Objective Milestone)

Consenso con el cliente en el alcance del proyecto y en las estimaciones Consenso en que se han identificado los requisitos clave del proyecto Consenso en que las estimaciones de coste/tiempo, las prioridades, los riesgos y el proceso de desarrollo a usar, son apropiados Consenso en que se han identificado los riesgos iniciales y en el plan de actuacin si se alcanzan

Inception Phase (Artefactos)

Un documento de visin general:
Requerimientos generales del proyecto Caractersticas principales Restricciones

Modelo inicial de casos de uso (10% a 20 % listos). Glosario. Caso de negocio:

Contexto Criterios de xito Pronstico financiero

Identificacin inicial de riesgos. Plan de proyecto. Uno o ms prototipos.

Inception Phase

Elaboration Phase (Objetivos)

Identificar y describir gran parte de los requisitos Disear, implementar, revisar y validar la arquitectura Eliminar los riesgos mas importantes y actualizar la planificacin Refinar el proceso y configurar las herramientas a usar

Elaboration Phase(Lifecycle Arquitecture Milestone)

Documento de Visin y requisitos estables Arquitectura estable Se han testeado prototipos para demostrar que los riesgos mas importantes ya han sido mitigados Aceptable la relacin de recursos empleados frente a los estimados La planificacin de las iteraciones para la siguiente fase es abordable El cliente aprueba todo lo anterior

Elaboration Phase(Artefactos )
Modelo de casos de uso (80% completo) con descripciones detalladas. Otros requerimientos no 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. Un manual de usuario preliminar.

Iterative-incremental development and the Rational Unified Process

Incremental mini-waterfall with feedback loops

Optimizing iterative and incremental development

Comparativa con otras metodologas

CMO FALLAR CON EL RATIONAL UNIFIED PROCESS: SIETE PASOS PARA EL DOLOR Y EL SUFRIMIENTO

Este artculo comparte algunas de las trampas ms comunes experimentados por los equipos que intentan adaptar el Rational Unified Process para sus necesidades, presentado con un poco de lengua en la mejilla. Paso 1: Superponer pensamiento en "cascada Paso 2: Aplicar el RUP como un proceso predictivo pesado Paso 3: Evite las habilidades de tecnolgicas de objeto Paso 4: Subestimar desarrollo iterativo adaptativo Paso 5: Evite mentores que entienden desarrollo iterativo Paso 6: Adoptar el RUP en un big bang Paso 7: Tome el consejo de fuentes mal informados

Usted sabe que usted no entiende el RUP cuando ...

Usted piensa que constitucin = requisitos; elaboracin = diseo y la construccin = aplicacin. Usted cree que el propsito de la elaboracin es definir con suma atencin los modelos, que son traducido a cdigo durante la construccin. Usted cree que slo los prototipos se crean en elaboracin. En realidad, el ncleo de calidad de produccin de los elementos arquitectnicos de riesgo deben ser programados en la elaboracin. Usted intenta definir la mayor parte de los requisitos antes de iniciar el diseo o la implementacin. Usted intenta definir la mayor parte del diseo antes de iniciar la ejecucin.

Usted sabe que usted no entiende el RUP cuando ...

Se gasta "mucho tiempo" haciendo requisitos o trabajos de diseo antes de comenzar la programacin. Una organizacin considera que una longitud adecuada iteracin se mide en meses, en lugar de semana. Usted cree que la fase de pre-programacin de diagramas UML y actividades de diseo es un tiempo para completa y precisa definir diseos y modelos con gran detalle, y de la programacin como una simple traduccin mecnica de estos en el cdigo. Usted intenta planificar un proyecto en detalle de principio a fin, la asignacin de los trabajos de cada iteracin, se intenta para predecir especulativamente todas las iteraciones, y lo que va a pasar en cada uno. Una organizacin quiere planes crebles y estimaciones para los proyectos antes de su llegada al fase de elaboracin.

VENTAJAS DEL USO DE RUP

ES UNA METODOLOGA QUE USA ALGUNAS DE LAS MEJORES PRCTICAS EN DESARROLLO DE SOFTWARE: se adapta perfectamente a proyectos de gran escala y complejidad, as como de grandes equipos de trabajo, tambin cuenta con un gran nivel de aceptacin entre desarrolladores ES ABIERTA, PBLICA Y BIEN DOCUMENTADA: es abiertamente publicada, distribuida, soportada y con toda su documentacin fcilmente disponible. CAPACITACIN DISPONIBLE: La versin on-line del Rational Unified Process, gua a los usuarios a travs del proceso de una manera tutorial de paso a paso. Muchos de los institutos tambin ofrecen cursos de formacin.

VENTAJAS DEL USO DE RUP

PROCESO DE ENTREGA EFICIENTE: El proceso tambin cuenta con un proceso de entrega eficiente, que ofrece a los administradores de proyectos la oportunidad de planificar y poner en marcha el proyecto. En otras palabras, no hay necesidad de inventar su proyecto desde cero cuando se puede reutilizar procesos RESUELVE FCILMENTE LOS RIESGOS: RUP normalmente ayuda a resolver los riesgos de los proyectos, a fin de garantizar que se encuentren en lnea con las necesidades cambiantes de los consumidores. Adicionalmente, se utilizan menos recursos para el proceso de integracin como la integracin es evidente a travs de toda la fase de desarrollo de software.

VENTAJAS DEL USO DE RUP

CONTROL DE CAMBIOS : Con RUP, la sincronizacin de los diversos componentes del proyecto se hace ms fcil cuando los componentes se manejan por diferentes equipos. PATRONES FLEXIBLES: RUP ofrece a los administradores la posibilidad de volver a utilizar los procesos para hacer frente a problemas comunes. Dado que los proyectos no son similares, es fcil de modificar procesos especficos para hacer frente a sus necesidades de proyectos. APOYA EL DESARROLLO ITERATIVO: RUP organiza los sistemas en fases para asegurar que cada proceso tenga mejores iteraciones ejecutables,

DESVENTAJAS DE USAR RUP

ES UNA METODOLOGA PESADA: Aunque, tericamente, podra servir para cualquier tipo y tamao de proyecto, en la realidad se considera apropiado para proyectos y equipos grandes. Probablemente el equipo mnimo debera contar con 10 o ms miembros, caso contrario, tal vez deberan realizar muchsimas adaptaciones a la metodologa. EL PROCESO ES DEMASIADO COMPLEJO: A menos que tenga un verdadero experto, es probable que no tendr xito en la adaptacin a este proceso. Capacitar al equipo requiere de tiempo y consultora. El proceso es demasiado complejo, demasiado difcil de aprender, y demasiado difcil de aplicar correctamente. ASPECTOS SOCIOLGICOS: El Proceso Unificado no captan los aspectos sociolgicos del desarrollo de software y los detalles de cmo desarrollar incrementalmente de manera verdadera.

DESVENTAJAS DE USAR RUP

INTRODUCE UNA GRAN BUROCRACIA AL PROCESO: Los mtodos tradicionales como RUP, son bastante sistemticos en su proceso, los cual implica altos niveles de dedicacin en la planificacin y documentacin para posteriormente lograr el desarrollo deseado, slo la exhaustiva documentacin que exige podra demandar ms recursos de los disponibles. NO ES UNA BUENA OPCIN SI SE TRATA DE UN PROYECTO MEDIANO O PEQUEO: que vaya a ser realizado por pocas personas y mucho menos si es un trabajo individual, como el tpico caso del proyecto desarrollado para obtener un grado acadmico en algn centro de formacin. CARACTERSTICAS AVANZADAS: la sintaxis de modelacin requiere de notaciones que no poseen los desarrolladores promedio.

Conclusin
No existen dos proyectos de desarrollo de software que sean iguales. Cada uno tiene prioridades, requerimientos, y tecnologas muy diferentes. Sin embargo, en todos los proyectos, se debe minimizar el riesgo, garantizar la predictibilidad de los resultados y entregar software de calidad superior a tiempo. Rational Unified Process, o RUP, es una plataforma flexible de procesos de desarrollo de software que ayuda brindando guas consistentes y personalizadas de procesos para todo el equipo de proyecto.