INFORME METODOLOGIA RUP EQUIPO 7
Introducción
El desarrollo de software no es una
tarea fácil. Las metodologías ágiles nos ayudan a establecer un control en el
proceso de desarrollo de software. Su filosofía, que el cliente sea más
colaborativo y propone el desarrollo de software en iteraciones. Estas
metodologías están revolucionando la manera de hacer software en menos tiempo
pero manteniendo la alta calidad del mismo.
Esta vez hablaremos de RUP (Rational Unified Process) una
metodología ágil, iterativa e incremental. Creada para adaptarse a la
organización, basada en UML.
Índice
I. ¿Qué es RUP?
1.1.
Principios
1.2.
Características
II. Ciclo de vida
2.1.
Iteraciones
2.2.
Disciplinas
III. RUP vs. XP
IV. Prácticas fundamentales de RUP
V. Ventajas y desventajas
Conclusiones
Bibliografía
¿Qué es RUP?
Proceso de desarrollo
de software creado por la empresa Rational.
Con ayuda del Lenguaje Unificado de Modelado (UML), constituye la metodología
estándar más utilizada para el análisis, diseño, implementación y documentación
de sistemas orientados a objetos.
No es un sistema con
pasos firmemente establecidos, sino un conjunto de metodologías adaptables al
contexto y necesidades de cada organización.
RUP (Rational Unified Process) se
inició aproximadamente en el año 1998 siendo predecesora de Rational Objectory
Process, que fue creada por:
● Iván Jacobson
● Grady Booch
● James Rumbaugh
● Philippe Kruchten
El Proceso Unificado de Rational o RUP son
marcas registradas por IBM (desde su compra de Rational Software Corporation en
2003).
Principios
El RUP está basado en 6
principios clave que son:
•Adaptar el proceso: El proceso deberá adaptarse a las
necesidades del cliente ya que es muy importante interactuar con él.
•Equilibrar prioridades: Los requisitos de los diversos
participantes pueden ser diferentes, contradictorios o disputarse recursos
limitados.
•Demostrar valor iterativamente: Los proyectos se entregan, aunque
sea de un modo interno, en etapas iteradas.
•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.
•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.
Características esenciales de RUP
La mayoría de los autores destacan
que el proceso de software propuesto por RUP tiene 3 principales
características las cuales son:
● Está dirigido por los Casos de Uso.
Los casos de uso los podríamos
definir como un fragmento de funcionalidad del sistema.
Los casos de uso son una técnica de
captura de requerimientos que te hacen pensar en términos de importancia para
el usuario y no sólo en términos de funciones que serían bueno contemplar.
Los casos de uso no solo empiezan el
proceso de desarrollo sino que proporcionan una guía conductora, permitiendo establecer
conexiones o trazos entre los artefactos que son generados en las diferentes
actividades del proceso de desarrollo.
Bueno basándonos en esto los que
hacen los casos de uso se crean los modelos de análisis y diseño como primera
instancia, seguida de los que es la fase de implementación que los lleva a
cabo, y por último se verifica que todo el producto esté implementado
adecuadamente con cada caso de uso.
● Está centrado en la arquitectura
(Análisis).
La arquitectura de un sistema es la
organización o estructura de sus partes más relevantes, lo que permite tener
una visión común entre todos los involucrados (desarrolladores y usuarios) y
una perspectiva clara del sistema completo, necesaria para controlar el
desarrollo. La arquitectura involucra todos los aspectos estáticos y dinámicos
más significativos del sistema.
RUP además de utilizar los casos de
uso para guiar el proceso presenta especial atención al establecimiento
temprano de una buena arquitectura.
Cada producto tiene tanto una función
como una forma. La función corresponde a la funcionalidad reflejada en los
casos de uso y la forma proporciona la arquitectura. Los casos de uso deben
encajar en la arquitectura cuando se lleven a cabo y la arquitectura debe
permitir el desarrollo de todos los casos de uso requeridos actualmente y en el
futuro.
● Es iterativo e incremental.
Consta de una secuencia
de iteraciones, cada iteración aborda una parte de la funcionalidad total,
pasando por cada uno de los flujos de trabajo relevantes y refinando la arquitectura
de los mismos.
Se pasa por los flujos
fundamentales (Requisitos, Análisis, Diseño, Implementación y Pruebas), también
existe una planificación de la iteración, un análisis de la iteración y algunas
actividades específicas de la iteración. Al finalizar se realiza una
integración de los resultados con lo obtenido de las iteraciones anteriores
Debe tener un equilibro
entre los casos de uso y la arquitectura, la estrategia de RUP es dividir el
trabajo en partes pequeñas o mini proyectos, permitiendo que el equilibrio
entre casos de uso y arquitectura se logre durante cada pequeña parte o mini
proyecto así hasta que termine todo el proceso de desarrollo.
Fases de RUP (Ciclo de vida)
Inicio: En esta fase se definen los alcances del proyecto, se identifican
los riesgos y se propone una visión muy general de la arquitectura de software.
Además, se pueden
establecer casos de negocio para un nuevo sistema o para alguna actualización
importante de un sistema existente.
Los objetivos de esta
fase son:
● Establecer el ámbito
del proyecto y sus límites.
● Encontrar los Casos de
Uso críticos del sistema, los escenarios básicos que definen la funcionalidad.
● Mostrar al menos una
arquitectura candidata para los escenarios principales.
● Estimar el coste en
recursos y tiempo de todo el proyecto.
● Estimar los riesgos,
las fuentes de incertidumbre.
Al terminar:
● Todos los interesados
en el proyecto coinciden en la definición del ámbito del sistema y las
estimaciones de agenda.
● Entendimiento de los
requisitos, como evidencia de la fidelidad de los Casos de Uso principales.
● Las estimaciones de
tiempo, coste y riesgo son creíbles.
● Comprensión total de
cualquier prototipo de la arquitectura desarrollado.
● Los gastos hasta el
momento se asemejan a los planeados.
Elaboración: Se analiza el dominio del problema, se
seleccionan los casos de uso que permiten definir la arquitectura base del
sistema, se diseña la solución preliminar.
Los objetivos de esta
fase son:
● Definir, validar y
cimentar la arquitectura.
● Completar la visión.
● Crear un plan fiable
para la fase de construcción.
● Este plan puede
evolucionar en sucesivas iteraciones. Debe incluir los costes si procede.
● Demostrar que la
arquitectura propuesta soportará la visión con un coste razonable y en un
tiempo razonable.
Al terminar:
● Un prototipo ejecutable
de la arquitectura.
● Lista de riesgos y caso
de negocio revisados.
● Plan de desarrollo para
el proyecto.
● Un caso de desarrollo
actualizado que especifica el proceso a seguir.
● Un manual de usuario
preliminar (opcional).
Construcción: Se lleva a cabo la construcción del producto,
se redefine su análisis y diseño y se procede a su implantación y pruebas.
Los objetivos concretos
incluyen:
● Minimizar los costes de
desarrollo mediante la optimización de recursos y evitando el tener que rehacer
un trabajo o incluso desecharlo.
● Conseguir una calidad
adecuada tan rápido como sea práctico.
● Conseguir versiones
funcionales (alfa, beta, y otras versiones de prueba) tan rápido como sea
práctico.
Los resultados deben
ser:
● Modelos Completos (Casos
de Uso, Análisis, Diseño, Despliegue e Implementación)
● Arquitectura íntegra
(mantenida y mínimamente actualizada)
● Riesgos Presentados
Mitigados
● Plan del Proyecto para
la fase de Transición.
● Manual Inicial de
Usuario (con suficiente detalle)
● Prototipo Operacional –
beta
● Caso del Negocio
Actualizado
Transición: El propósito de esta fase es asegurar que el
software esté disponible para la entrega al usuario.
Entrega del Producto
¿Está el usuario
satisfecho?
Gastos reales de los
recursos vs. Gastos previstos aceptables.
Los principales
objetivos de esta fase son:
● Conseguir que el
usuario se valga por sí mismo.
● Un producto final que
cumpla los requisitos esperados, que funcione y satisfaga suficientemente al
usuario.
Los resultados de la
fase de transición son:
● Prototipo Operacional
● Documentos Legales
● Caso del Negocio
Completo
● Línea de Base del
Producto completa y corregida que incluye todos los modelos del sistema
● Descripción de la
Arquitectura completa y corregida
● Las iteraciones de esta
fase irán dirigidas normalmente a conseguir una nueva versión.
La duración y esfuerzo
que debe ser dedicado en cada fase es una variable dependiendo de las
características que contenga el proyecto en desarrollo.
|
INICIO
|
ELABORACIÓN
|
CONSTRUCCIÓN
|
TRANSICIÓN
|
ESFUERZO
|
5%
|
20%
|
65%
|
10%
|
TIEMPO
|
10%
|
30%
|
50%
|
10%
|
Iteraciones
Cada fase en RUP puede
descomponerse en iteraciones. Una iteración es un ciclo de desarrollo completo
dando como resultado una entrega de producto ejecutable (interna o externa).
Una iteración puede
realizarse por medio de una cascada. Se pasa por los flujos fundamentales
(Requisitos, Análisis, Diseño, Implementación y Pruebas), también existe una
planificación de la iteración, un análisis de la iteración y algunas
actividades específicas de la iteración. Al finalizar se realiza una
integración de los resultados con lo obtenido de las iteraciones anteriores.
El proceso iterativo e
incremental consta de una secuencia de iteraciones. Cada iteración aborda una
parte de la funcionalidad total, pasando por todos los flujos de trabajo
relevantes y refinando la arquitectura. Cada iteración se analiza cuando
termina. Se puede determinar si han aparecido nuevos requisitos o han cambiado
los existentes, afectando a las iteraciones siguientes. Durante la
planificación de los detalles de la siguiente iteración, el equipo también
examina cómo afectarán los riesgos que aún quedan al trabajo en curso. Toda la
retroalimentación de la iteración pasada permite reajustar los objetivos para
las siguientes iteraciones. Se continúa con esta dinámica hasta que se haya
finalizado por completo con la versión actual del producto.
Disciplinas
Las disciplinas
conllevan los flujos de trabajo, los cuales son una secuencia de pasos para la
culminación de cada disciplina, estas disciplinas se dividen en dos grupos: las
primarias y las de apoyo.
Las primarias son las
necesarias para la realización de un proyecto de software. (Flujos del trabajo
de proceso)
Las de apoyo sirven de
apoyo a las primarias y especifican otras características en la realización de
un proyecto de software. ( Flujos de trabajo de soporte).
1. Flujos del Trabajo de Proceso
Modelado del negocio: Tiene como objetivos comprender la estructura
y la dinámica de la organización, comprender problemas actuales e identificar
posibles mejoras, comprender los procesos de negocio.
Requerimientos: Tiene como objetivos establecer lo que el
sistema debe hacer (Especificar Requisitos), definir los límites del sistema, y
una interfaz de usuario, realizar una estimación del costo y tiempo de
desarrollo.
Análisis y Diseño: Define la arquitectura del sistema y tiene
como objetivos trasladar requisitos en especificaciones de implementación.
Implementación: Tiene como objetivo implementar las clases de
diseño como componentes
Pruebas: Tiene como objetivo verificar la integración
de los componentes, verificar que todos los requisitos han sido implementados.
Despliegue: Asegura que es producto esté preparado para el
cliente.
2. Flujo de Trabajo de Soporte
Gestión y configuración de cambios: Los controles sobre
los cambios son de mucha ayuda ya que evitan confusiones costosas como la
compostura de algo que ya se había arreglado etc.
Gestión del proyecto: su objetivo es equilibrar los objetivos
competitivos, administrar el riesgo, y superar restricciones para entregar un
producto que satisface las necesidades de los clientes con.
Entorno: se enfoca sobre las actividades necesarias para configurar
el proceso que engloba el desarrollo de un proyecto y describe las actividades
requeridas para el desarrollo de las pautas que apoyan un proyecto.
RUP Vs XP
RUP
|
XP
|
● Forma disciplinada de
asignar tareas y responsabilidades en una empresa de desarrollo
● Un cambio en las
etapas de vida del sistema incrementa el costo
● Requiere un grupo
grande de programadores para trabajar esta metodología
● Describe una clase de
los procesos que son iterativos e incrementales
● Es un proceso de
desarrollo más general de los existentes actualmente
● Los procesos de RUP
estiman tareas y horario del plan midiendo la velocidad de iteraciones
concerniente a sus estimaciones originales.
● Las iteraciones
tempranas de proyectos conducidos RUP se enfocan fuertemente sobre
arquitectura del software; la puesta en práctica rápida de características se
retrasa hasta que se ha identificado y se ha probado una arquitectura firme.
|
● Busca simplificar el
desarrollo del software y que se logrará la reducción en el costo del
proyecto
● Reduce el costo del
cambio en las etapas de vida del sistema
● Se requiere de un
grupo pequeño de programadores, se irán aumentando conforme sea necesario
● Sus programadores
pueden ser ordinarios
● El desarrollo de
software es riesgoso y difícil de controlar
● Se harán pruebas todo
el tiempo, no sólo de cada nueva clase (pruebas unitarias) sino que también
los clientes comprobarán que el proyecto va satisfaciendo los requisitos
(pruebas funcionales).
● intenta reducir la
complejidad del software por medio de un trabajo orientado directamente al
objetivo, basado en las relaciones interpersonales y la velocidad de reacción
●
Es un sistema de prácticas mínimas - le suponen
utilizarlas todas en el principio de un proyecto y adaptarlas y agregar los
adicionales como cuando se experimenta la necesidad.
|
Prácticas fundamentales de RUP
La perspectiva práctica
en el RUP describe buenas prácticas dentro de la ingeniería del software que
son aconsejables en el desarrollo de sistemas. Se recomienda seis buenas
prácticas fundamentales.
1. Desarrolle
el software de forma iterativa. Planifica los incrementos del sistema basado en
las prioridades del usuario y desarrollo y entrega de las características del
sistema de más alta prioridad al inicio del proceso de desarrollo
2. Gestión
de requerimientos. Documenta explícitamente los requerimientos del cliente y se
mantiene al tanto de los cambios.
3. Utilización
de arquitecturas en componentes. Se estructura la arquitectura del sistema
4. Modelo
del software visualmente. Utilización de modelos gráficos UML
5. Verificación
de la calidad del software. Se asegura que se cumplan los estándares de calidad
organizacionales
6. Control
de cambios del software. Gestiona los cambios del software usando un sistema de
gestión de cambios
Ventajas y Desventajas
VENTAJAS
● RUP ha madurado con el
tiempo
● Requiere conocimientos
del proceso y de UML
● UML hace que el
software se apegue a estándares de la industria
● Adaptable a la
organización
● Progreso visible en las
etapas tempranas
● El uso de las
iteraciones (actividades) permite evaluar tempranamente los riesgos en lugar de
descubrir problemas en la integración final del sistema
● Facilita la
reutilización del código teniendo en cuenta que se realizan revisiones en las
primeras interacciones lo cual además permite que se aprecien oportunidades de
mejoras en el diseño
DESVENTAJAS
● Por el grado de
complejidad puede no resultar muy adecuado
● RUP es generalmente mal
aplicado en el estilo de cascada
● Sistemas híbridos: en
empresas que hay organismos híbridos y nos adaptables a cualquier empresa UML
no es efectivo
● Costosa la compra de
herramientas y capacitación del equipo, requiere de tiempo y consultoría
● Limitaciones en ciclo
de vida pues no lo contempla por completo.
● Posee características
avanzadas en la sintaxis de modelación, requiere notaciones que no poseen los desarrolladores promedio
Conclusiones
RUP es una metodología
ágil para el análisis, diseño, desarrollo, implementación y documentación de
sistemas orientados a objetos. No es un modelo con pasos definidos, sino un
modelo adaptable a las necesidades de la organización. Sus principios son: adaptar
el proceso según el contexto de la organización. Establecer prioridades,
establecer las iteraciones, colaboración de equipos, código reutilizable y
enfocarse en la calidad.
Esta metodología
promueve la interacción con el cliente y la comunicación entre equipos. Así
mismo, que el control de calidad no se realice sólo en la parte final de la
iteración, sino en durante todo el proceso.
Se basa en UML, es
decir, está dirigido por casos de uso. Esto hace que se sea más costoso y con
mayor grado de complejidad por lo que puede resultar no muy adecuado.
BIBLIOGRAFÍA
★ Cuatro enfoques metodológicos para el desarrollo de Software RUP – MSF – XP - SCRUM, Recibido el 1 de
abril de 20111. Aprobado el 10 de junio de 2011, Oliver Andrés Pérez A.
★ Inventum No. 10 Facultad de Ingeniería UNIMINUTO - Junio de 2011 - ISSN 1909 - 2520
★ Ingeniería del Software- Ian
Sommerville- Séptima Edición - PEARSON EDUCACIÓN, S.A. , Madrid 2005
★ Cocolito. (s.f.). cocolito. Recuperado el 2013 de
Septiembre de 09, de http://cocolito.comoj.com/rup.html
