INTEGRANTES:

Rational Unified Process

♦ Introducción

♦ Historia del Rational Unified Process

♦ Best Practices for Software Development Teams : Requirements Management

♦ Disciplinas

♦ Fases

♦ Cómo 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/Análisis

♦ Bien documentado

♦ RUP es una enorme base de conocimiento en Ingeniería 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 gestión del proyecto se orienta a la gestión de

riesgos

Historia del Rational Unified Process

Introducción

Best Practices for Software Development Teams:

1. Develop software iteratively

2. MANAGE REQUIREMENTS

3. Use component-based architectures

4. Visually model software

5. Verify software quality

6. Control changes to software

Rational Unified Process

Usted debe asegurarse de:

♦ resolver el problema correcto

♦ construir el sistema correcto

mediante la adopción de un enfoque

sistemático para:

♦ elicitar

♦ organizar

♦ documentar

♦ gestionar

las necesidades cambiantes de una aplicación

de software.

Requirements Management

Requirements Management

Entendimiento de requerimientos:

1. Necesidades de los stakeholders. ♦ Preguntas del tipo: ¿cuál es el problema

a resolver? ¿cuál es el criterio de éxito? Establecen condiciones y contexto para el sistema.

2. Características del sistema. ♦ Se cambia del qué al cómo.

3. Requerimientos de software. ♦ Especifican funcionalidades entendibles

por usuarios y desarrolladores.

Definiciones

REQUISITO:

Una condición o capacidad que el sistema

debe cumplir.

GESTIÓN DE REQUISITOS:

Un enfoque sistemático para:

• Elicitación, organización y documentación de

requisitos.

• Establecer y mantener un acuerdo entre el cliente/usuario y el equipo del proyecto frente a las necesidades cambiantes.

Definiciones

REQUISITO:

Una condición o capacidad que el sistema

debe cumplir.

GESTIÓN DE REQUISITOS:

Un enfoque sistemático para:

• Elicitación, organización y documentación 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 Estática y dinámica 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 lógicamente por naturaleza.

♦ La primera dimensión representa el aspecto dinámico del proceso de su adopción, y se expresa en términos de fases, iteraciones e hitos.

♦ La segunda dimensión representa el aspecto estático del proceso: cómo se describe en términos de componentes de proceso, disciplinas, actividades, flujos de trabajo, artefactos y roles (ver Conceptos clave).

♦ El diagrama muestra cómo el énfasis varía con el tiempo. Por ejemplo, en las primeras iteraciones, pasamos más tiempo en los requisitos y en las iteraciones más tarde que pasamos más tiempo en la aplicación.

Elementos del proceso

Disciplinas de desarrollo

Requirements workflow

Las funciones y los objetos

desarrollados en la disciplina de

Requerimientos.

Actividades

Propósito 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 comprensión de los requisitos del sistema.

♦ Para definir los límites de (delimitan) el sistema.

♦ Para proporcionar una base para la planificación de

los contenidos técnicos de las iteraciones.

♦ Para proporcionar una base para la estimación de

costos y tiempo para desarrollar el sistema.

♦ Para definir una interfaz de usuario para el sistema,

centrándose en las necesidades y objetivos de los

usuarios.

Dificultades Recopilación de Requerimiento

♦ Los requisitos que no siempre son evidentes, y pueden provenir de muchas fuentes.

♦ Los requisitos que no siempre son fáciles de expresar claramente en palabras.

♦ Hay muchos tipos diferentes de requisitos en diferentes niveles de detalle.

♦ El número de requisitos puede llegar a ser difícil de manejar si no se controla.

Dificultades Recopilación de Requerimiento

♦ Los requisitos se relacionan entre sí y también

a otros entregables del proceso de ingeniería

de software.

♦ Requisitos tienen propiedades únicas o valores

de propiedad. Por ejemplo, no son ni tan

importante ni igual de fáciles de cumplir.

♦ Hay muchas partes interesadas, lo que

significa que los requisitos deben ser

administrados por grupos interdisciplinarios de

personas.

♦ Requisitos cambian.

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 gestión 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 definición del sistema durante la fase de elaboración. Gestión del Alcance del Sistema y Administración de cambio de las necesidades se hacen continuamente a lo largo del proyecto.

Requirements workflow

Actividad: Analizar el problema

Propósito:

♦ Obtener un acuerdo sobre

el problema a resolver,

♦ Identificar a los interesados ,

♦ Definir los límites del sistema,

y

♦ Identificar las limitaciones

impuestas en el sistema

Técnicas de muestreo:

♦ Lluvia de ideas

♦ diagramas de espina de

pescado

♦ diagramas de Pareto

Actividad: Analizar el

problema

Actividad: Conocer las necesidades del interesado

Propósito: Es recoger y obtener información

de las partes interesadas en el

proyecto con el fin de entender

cuáles son sus necesidades son

realmente.

Técnicas de muestreo: ♦ Entrevistas

♦ Requisitos del Taller

♦ Lluvia de ideas y la reducción

idea

♦ Revisión de los requisitos

existentes

♦ Taller de Casos de Uso

♦ Storyboarding

♦ juego de roles

Actividad: Conocer las necesidades del interesado

Actividad: Definir el sistema

Propósito: ♦ Alinear el equipo del proyecto en

su comprensión del sistema.

♦ Realizar un análisis de alto nivel de los resultados de recogida de solicitudes de las partes interesadas.

♦ Acotar la visión para incluir las características para incluir en el sistema, junto con los atributos correspondientes.

♦ Acotar el modelo de casos de uso, para incluir los casos de uso definidos.

♦ Más documentar formalmente los resultados de los modelos y documentos.

Técnicas de muestreo: ♦ Requisitos del Taller

♦ Taller de Casos de Uso

♦ Storyboarding

Actividad: Definir el sistema

Actividad: Gestionar el ámbito del sistema

Propósito:

♦ Priorizar y refinar de entrada

para la selección de características y requisitos que se van a incluir en la iteración 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 reunión para discutir la mejor manera de priorizar las necesidades.

Actividad: Gestionar el ámbito del sistema

Actividad: Perfeccionar la definición del sistema

Propósito:

♦ Describir el flujo del caso de uso

de los acontecimientos en

detalle.

♦ Especificaciones suplementarias

Detalle.

♦ Desarrollar una especificación de

requisitos de software, si se

necesita más detalles, y

♦ Modelo y prototipo de la interfaz

de usuario.

Especificadores de Requisitos y

diseñadores 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 sincronía.

Actividad: Perfeccionar la definición del sistema

Actividad: Gestionar cambios de requisitos

Propósito:

♦ 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 más formal por el equipo extendido.

Actividad: Gestionar

cambios de requisitos

• http://cgrw01.cgr.go.cr/rup/RUP.es

• http://sce.uhcl.edu/helm/rationalunifiedprocess/

• http://www.cycoda.com/html/bmdomain.html

Paginas de interes

Fases del desarrollo

4 fases:

♦ Inicio

♦ Elaboración

♦ Construcción

♦ Transición

Conceptos

importantes:

♦ Milestone

(Criterios)

♦ Aproximaci6n

Iterativa e

Incremental

Inception Phase (Objetivos)

♦ Entender que se va a construir (Visión Document,

Brainstorming Sessions)

♦ identificar los puntos clave del proyecto

♦ Definir, al menos, una posible solución

♦ 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 actuación si

se alcanzan

Inception Phase (Artefactos)

♦ Un documento de visión general: • Requerimientos generales del proyecto

• Características principales

• Restricciones

♦ Modelo inicial de casos de uso (10% a 20 % listos).

♦ Glosario.

♦ Caso de negocio: • Contexto

• Criterios de éxito

• Pronóstico financiero

♦ Identificación inicial de riesgos.

♦ Plan de proyecto.

♦ Uno o más prototipos.

Inception Phase

Elaboration Phase (Objetivos)

♦ Identificar y describir gran parte de los requisitos

♦ Diseñar, implementar, revisar y validar la arquitectura

♦ Eliminar los riesgos mas importantes y actualizar la planificación

♦ Refinar el proceso y configurar las herramientas a usar

Elaboration Phase(Lifecycle Arquitecture Milestone)

♦ Documento de Visión y requisitos estables

♦ Arquitectura estable

♦ Se han testeado prototipos para demostrar

que los riesgos mas importantes ya han sido

mitigados

♦ Aceptable la relación de recursos

empleados frente a los estimados

♦ La planificación 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.

♦ Descripción 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 metodologías

CÓMO FALLAR CON EL RATIONAL UNIFIED PROCESS:

SIETE PASOS PARA EL DOLOR Y EL SUFRIMIENTO

♦ Este artículo comparte algunas de las trampas más 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 tecnológicas 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 constitución = requisitos; elaboración

= diseño y la construcción = aplicación.

♦ Usted cree que el propósito de la elaboración es definir

con suma atención los modelos, que son traducido a

código durante la construcción.

♦ Usted cree que sólo los prototipos se crean en

elaboración. En realidad, el núcleo de calidad de

producción de los elementos arquitectónicos de riesgo

deben ser programados en la elaboración.

♦ Usted intenta definir la mayor parte de los requisitos

antes de iniciar el diseño o la implementación.

♦ Usted intenta definir la mayor parte del diseño antes de iniciar la ejecución.

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

♦ Se gasta "mucho tiempo" haciendo requisitos o trabajos de

diseño antes de comenzar la programación.

♦ Una organización considera que una longitud adecuada

iteración se mide en meses, en lugar de semana.

♦ Usted cree que la fase de pre-programación de diagramas

UML y actividades de diseño es un tiempo para completa y

precisa definir diseños y modelos con gran detalle, y de la

programación como una simple traducción mecánica de

estos en el código.

♦ Usted intenta planificar un proyecto en detalle de principio a

fin, la asignación de los trabajos de cada iteración, se intenta

para predecir especulativamente todas las iteraciones, y lo

que va a pasar en cada uno.

♦ Una organización quiere planes creíbles y estimaciones para

los proyectos antes de su llegada al fase de elaboración.

VENTAJAS DEL USO DE RUP

♦ ES UNA METODOLOGÍA QUE USA ALGUNAS DE LAS MEJORES PRÁCTICAS EN DESARROLLO DE SOFTWARE: se adapta perfectamente a proyectos de gran escala y

complejidad, así como de grandes equipos de trabajo,

también cuenta con un gran nivel de aceptación entre

desarrolladores

♦ ES ABIERTA, PÚBLICA Y BIEN DOCUMENTADA: es abiertamente publicada, distribuida, soportada y con

toda su documentación fácilmente disponible.

♦ CAPACITACIÓN DISPONIBLE: La versión on-line del

Rational Unified Process, guía a los usuarios a través del proceso de una manera tutorial de paso a paso. Muchos de los institutos también ofrecen cursos de

formación.

VENTAJAS DEL USO DE RUP

♦ PROCESO DE ENTREGA EFICIENTE: El proceso también

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 FÁCILMENTE LOS RIESGOS: RUP normalmente

ayuda a resolver los riesgos de los proyectos, a fin de

garantizar que se encuentren en línea con las

necesidades cambiantes de los consumidores. Adicionalmente, se utilizan menos recursos para el proceso de integración como la integración es

evidente a través de toda la fase de desarrollo de

software.

VENTAJAS DEL USO DE RUP

♦ CONTROL DE CAMBIOS : Con RUP, la sincronización de

los diversos componentes del proyecto se hace más fácil 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 fácil de modificar procesos

específicos 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 METODOLOGÍA PESADA: Aunque, teóricamente, podría

servir para cualquier tipo y tamaño de proyecto, en la

realidad se considera apropiado para proyectos y equipos

grandes. Probablemente el equipo mínimo debería contar

con 10 o más miembros, caso contrario, tal vez deberían

realizar muchísimas adaptaciones a la metodología.

♦ EL PROCESO ES DEMASIADO COMPLEJO: A menos que tenga

un verdadero experto, es probable que no tendrá éxito en la

adaptación a este proceso. Capacitar al equipo requiere

de tiempo y consultoría. El proceso es demasiado complejo,

demasiado difícil de aprender, y demasiado difícil de aplicar

correctamente.

♦ ASPECTOS SOCIOLÓGICOS: El Proceso Unificado no captan los

aspectos sociológicos del desarrollo de software y los detalles

de cómo desarrollar incrementalmente de manera

verdadera.

DESVENTAJAS DE USAR RUP

♦ INTRODUCE UNA GRAN BUROCRACIA AL PROCESO: Los

métodos tradicionales como RUP, son bastante sistemáticos

en su proceso, los cual implica altos niveles de dedicación en

la planificación y documentación para posteriormente lograr

el desarrollo deseado, sólo la exhaustiva documentación que

exige podría demandar más recursos de los disponibles.

♦ NO ES UNA BUENA OPCIÓN SI SE TRATA DE UN PROYECTO

MEDIANO O PEQUEÑO: que vaya a ser realizado por pocas

personas y mucho menos si es un trabajo individual, como el

típico caso del proyecto desarrollado para obtener un grado

académico en algún centro de formación.

♦ CARACTERÍSTICAS AVANZADAS: la sintaxis de modelación

requiere de notaciones que no poseen los desarrolladores

promedio.

Conclusión

No existen dos proyectos de desarrollo de

software que sean iguales. Cada uno tiene

prioridades, requerimientos, y tecnologías 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 guías consistentes y

personalizadas de procesos para todo el equipo

de proyecto.