2. RUP
RUP
Historia
Historia
(Rational Unified Process - Proceso Unificado Racional)
(Rational Unified Process - Proceso Unificado Racional)
► En 1967, Metodología Ericsson (Ericsson Approach) elaborada por Ivar
En 1967, Metodología Ericsson (Ericsson Approach) elaborada por Ivar
Jacobson, una aproximación de desarrollo basada en componentes, que
Jacobson, una aproximación de desarrollo basada en componentes, que
introdujo el concepto de Caso de Uso.
introdujo el concepto de Caso de Uso.
► Entre 1987 y 1995 Jacobson fundó la compañía Objectory AB y lanza el
Entre 1987 y 1995 Jacobson fundó la compañía Objectory AB y lanza el
proceso de desarrollo Objectory (abreviación de Object Factory).
proceso de desarrollo Objectory (abreviación de Object Factory).
► 1995 Rational Software Corporation adquiere Objectory AB y entre 1995 y
1995 Rational Software Corporation adquiere Objectory AB y entre 1995 y
1997 se desarrolla Rational Objectory Process (ROP) a partir de Objectory 3.8 y
1997 se desarrolla Rational Objectory Process (ROP) a partir de Objectory 3.8 y
del Enfoque Rational (Rational Approach) adoptando UML como lenguaje de
del Enfoque Rational (Rational Approach) adoptando UML como lenguaje de
modelado.
modelado.
► Desde ese entonces y a la cabeza de Grady Booch, Ivar Jacobson y
Desde ese entonces y a la cabeza de Grady Booch, Ivar Jacobson y
James Rumbaugh, Rational Software desarrolló e incorporó diversos
James Rumbaugh, Rational Software desarrolló e incorporó diversos
elementos para expandir RUP, destacándose especialmente el flujo de
elementos para expandir RUP, destacándose especialmente el flujo de
trabajo conocido como modelado del negocio.
trabajo conocido como modelado del negocio.
► En junio del 1998 se lanza Rational Unified Process.
En junio del 1998 se lanza Rational Unified Process.
4. UML
UML
(
(Unified Modeling Language)
Unified Modeling Language)
► El lenguaje UML comenzó a gestarse en octubre de 1994, cuando James
El lenguaje UML comenzó a gestarse en octubre de 1994, cuando James
Rumbaugh se unió a la compañía Rational fundada por Grady Booch (dos
Rumbaugh se unió a la compañía Rational fundada por Grady Booch (dos
reputados investigadores en el área de metodología del software). El
reputados investigadores en el área de metodología del software). El
objetivo de ambos era unificar dos métodos que habían desarrollado: el
objetivo de ambos era unificar dos métodos que habían desarrollado: el
método Booch y el OMT (Object Modelling Tool). El primer borrador
método Booch y el OMT (Object Modelling Tool). El primer borrador
apareció en octubre de 1995. En esa misma época otro reputado
apareció en octubre de 1995. En esa misma época otro reputado
investigador, Ivar Jacobson, se unió a Rational y se incluyeron ideas suyas.
investigador, Ivar Jacobson, se unió a Rational y se incluyeron ideas suyas.
Estas tres personas son conocidas como los tres amigos.
Estas tres personas son conocidas como los tres amigos.
► Además, este lenguaje se abrió a la colaboración de otras empresas para
Además, este lenguaje se abrió a la colaboración de otras empresas para
que aportaran sus ideas. Todas estas colaboraciones condujeron a la
que aportaran sus ideas. Todas estas colaboraciones condujeron a la
definición de la primera versión de UML. La versión 1.0 de UML surgió en
definición de la primera versión de UML. La versión 1.0 de UML surgió en
1997 con la contribución de IBM, HP, Oracle, Microsoft y otras
1997 con la contribución de IBM, HP, Oracle, Microsoft y otras
organizaciones.
organizaciones.
► El desarrollo de UML continúa actualmente bajo el control de IBM (que
El desarrollo de UML continúa actualmente bajo el control de IBM (que
adquirió Rational); la última versión de UML es la 2.0.
adquirió Rational); la última versión de UML es la 2.0.
5. UML
UML
¿Qué es UML?
¿Qué es UML?
UML es ante todo un lenguaje.
UML es ante todo un lenguaje.
Un lenguaje proporciona un
Un lenguaje proporciona un
vocabulario y unas reglas para
vocabulario y unas reglas para
permitir una comunicación. En
permitir una comunicación. En
este caso, este lenguaje se
este caso, este lenguaje se
centra en la representación
centra en la representación
gráfica de un sistema. Este
gráfica de un sistema. Este
lenguaje nos indica cómo crear
lenguaje nos indica cómo crear
y leer los modelos, pero no dice
y leer los modelos, pero no dice
cómo crearlos. Esto último es el
cómo crearlos. Esto último es el
objetivo de las metodologías
objetivo de las metodologías
de desarrollo.
de desarrollo.
6. UML
UML
Objetivos
Objetivos
Los objetivos de UML son muchos, pero se pueden
Los objetivos de UML son muchos, pero se pueden
sintetizar sus funciones:
sintetizar sus funciones:
Visualizar
Visualizar: UML permite expresar de una forma gráfica un
: UML permite expresar de una forma gráfica un
sistema de forma que otro lo puede entender.
sistema de forma que otro lo puede entender.
Especificar
Especificar: UML permite especificar cuáles son las
: UML permite especificar cuáles son las
características de un sistema antes de su construcción.
características de un sistema antes de su construcción.
Construir
Construir: A partir de los modelos especificados se pueden
: A partir de los modelos especificados se pueden
construir los sistemas diseñados.
construir los sistemas diseñados.
Documentar
Documentar: Los propios elementos gráficos sirven como
: Los propios elementos gráficos sirven como
documentación del sistema desarrollado que pueden
documentación del sistema desarrollado que pueden
servir para su futura revisión.
servir para su futura revisión.
7. UML
UML
Composición
Composición
Un modelo UML está
Un modelo UML está
compuesto por tres clases
compuesto por tres clases
de bloques de construcción:
de bloques de construcción:
Elementos
Elementos: Los elementos
: Los elementos
son abstracciones de cosas
son abstracciones de cosas
reales o ficticias(objetos,
reales o ficticias(objetos,
acciones, etc.)
acciones, etc.)
Relaciones
Relaciones: relacionan los
: relacionan los
elementos entre sí.
elementos entre sí.
Diagramas
Diagramas: Son colecciones
: Son colecciones
de elementos con sus
de elementos con sus
relaciones.
relaciones.
8. UML
UML
Diagramas
Diagramas
Diagramas de estructura:
Diagramas de estructura:
Diagrama de clases.
Diagrama de clases.
Diagrama de
Diagrama de
componentes.
componentes.
Diagrama de objetos
Diagrama de objetos
Diagrama de estructura
Diagrama de estructura
compuesta
compuesta
Diagrama de despliegue
Diagrama de despliegue
Diagrama de paquetes
Diagrama de paquetes
Diagramas de comportamiento:
Diagramas de comportamiento:
Diagrama de actividades
Diagrama de actividades
Diagrama de casos de uso
Diagrama de casos de uso
Diagrama de estados
Diagrama de estados
Diagramas de interacción:
Diagramas de interacción:
Diagrama de secuencia
Diagrama de secuencia
Diagrama de comunicación
Diagrama de comunicación
Diagrama de tiempos
Diagrama de tiempos
Diagrama de vista de
Diagrama de vista de
interacción
interacción
9. ¿
¿Qué es un Proceso?
Qué es un Proceso?
► Un proceso define
Un proceso define Quién
Quién está haciendo
está haciendo Qué
Qué,
,
Cuándo
Cuándo y
y Cómo
Cómo para lograr un cierto objetivo.
para lograr un cierto objetivo.
En la ingeniería de software el objetivo es
En la ingeniería de software el objetivo es
construir un producto de software ó mejorar
construir un producto de software ó mejorar
alguno existente.
alguno existente.
Proceso de Ingeniería
de Software
Requerimientos
Nuevos ó Modificados Nuevo ó Modificado
Sistema
10. Noción de Proceso
Noción de Proceso
Rol que puede
ser
desempeñado
por un
individuo o
conjunto de
individuos en
la organización
de desarrollo
Trabajador/Quién?
Diseñador
Actividad/Cómo?
Describe una
unidad de trabajo
que puede ser
asignada a un
trabajador.
Diseño de
Casos de uso
Pieza de información que
es producida,
modificada, ó utilizada
por un proceso
Artefacto/Qué?
Paquete de
Caso de Uso
Caso de Uso
responsable de
11. Beneficios de la Metodología
Beneficios de la Metodología
Orientada a Objetos
Orientada a Objetos
• Reduce la complejidad del mantenimiento (extensibilidad y
Reduce la complejidad del mantenimiento (extensibilidad y
facilidad de cambios).
facilidad de cambios).
• Disminuye la brecha semántica entre la visión interna y la
Disminuye la brecha semántica entre la visión interna y la
visión externa del sistema.
visión externa del sistema.
• Facilita la construcción de prototipos.
Facilita la construcción de prototipos.
• El diseñador piensa en términos del comportamiento de
El diseñador piensa en términos del comportamiento de
objetos y no en detalles de bajo nivel.
objetos y no en detalles de bajo nivel.
• Mejor comunicación entre los profesionales de los Sistemas de
Mejor comunicación entre los profesionales de los Sistemas de
Información y los empresarios.
Información y los empresarios.
• Mayor nivel de automatización de las bases de datos.
Mayor nivel de automatización de las bases de datos.
• La comprensión del sistema es más fácil porque la semántica
La comprensión del sistema es más fácil porque la semántica
entre el sistema y la realidad son similares.
entre el sistema y la realidad son similares.
12. El Problema
El Problema
•Si un proceso es utilizado, equipos
funcionales diferentes normalmente utilizan
procesos y lenguajes de modelación
inconsistentes.
Requerimientos
Pruebas
Análisis
Diseño
•La mayoría de los proyectos de software
utilizan procesos que no están bien
definidos. En su lugar los miembros del
equipo (re)inventan sus propios procesos.
?
?
?
?
?
?
?
•Los procesos no están apropiadamente
relacionados con herramientas, ó no están
propiamente automatizados.
?
Proceso Herramienta
13. Rational Unified Process (RUP)
Rational Unified Process (RUP)
► Captura varias de las mejores prácticas en el desarrollo moderno de
Captura varias de las mejores prácticas en el desarrollo moderno de
software en una forma que es aplicable para un amplio rango de
software en una forma que es aplicable para un amplio rango de
proyectos y organizaciones.
proyectos y organizaciones.
► Es una guía de cómo utilizar de manera efectiva UML.
Es una guía de cómo utilizar de manera efectiva UML.
► Provee a cada miembro de un equipo un fácil acceso a una base de
Provee a cada miembro de un equipo un fácil acceso a una base de
conocimiento con guías, plantillas y herramientas para todas las
conocimiento con guías, plantillas y herramientas para todas las
actividades críticas de desarrollo.
actividades críticas de desarrollo.
► Crea y mantiene modelos, en lugar de enfocarse en la producción de una
Crea y mantiene modelos, en lugar de enfocarse en la producción de una
gran cantidad de papeles de documentación.
gran cantidad de papeles de documentación.
14. Rational Unified Process (RUP)
Rational Unified Process (RUP)
RUP se divide en 4 fases:
RUP se divide en 4 fases:
1.
1. Inicio (Inspección y Concepción)
Inicio (Inspección y Concepción)
Plan de Fases, Identificación Casos de Uso y Riesgos
Plan de Fases, Identificación Casos de Uso y Riesgos
2.
2. Elaboración
Elaboración
Plan de Proyecto, Diseño de la Arquitectura
Plan de Proyecto, Diseño de la Arquitectura
3.
3. Construcción
Construcción
Elaborar Producto Operativo, Manual Usuario
Elaborar Producto Operativo, Manual Usuario
4.
4. Transición
Transición
Instalación, Entrenamiento de Usuarios
Instalación, Entrenamiento de Usuarios
15. Estructura del RUP
Estructura del RUP
[Dimensiones]
[Dimensiones]
El proceso puede describirse en dos dimensiones, o a
El proceso puede describirse en dos dimensiones, o a
lo largo de dos ejes:
lo largo de dos ejes:
El eje horizontal representa
El eje horizontal representa tiempo
tiempo y muestra el
y muestra el
aspecto dinámico del proceso, expresado en términos
aspecto dinámico del proceso, expresado en términos
de
de ciclos
ciclos,
, fases
fases,
, iteraciones
iteraciones, y
, y metas
metas.
.
El eje vertical representa el aspecto estático del
El eje vertical representa el aspecto estático del
proceso; como está descrito en términos de
proceso; como está descrito en términos de
actividades
actividades,
, artefactos
artefactos,
, trabajadores
trabajadores y
y flujos de trabajo
flujos de trabajo.
.
17. Principios de Desarrollo
Principios de Desarrollo
El RUP está basado en 6 principios
El RUP está basado en 6 principios
clave que son los siguientes:
clave que son los siguientes:
1.
1. Adaptar el proceso
Adaptar el proceso
2.
2. Equilibrar prioridades
Equilibrar prioridades
3.
3. Demostrar valor iterativamente
Demostrar valor iterativamente
4.
4. Colaboración entre equipos
Colaboración entre equipos
5.
5. Elevar el nivel de abstracción
Elevar el nivel de abstracción
6.
6. Enfocarse en la calidad
Enfocarse en la calidad
18. Principales Características
Principales Características
► Forma disciplinada de asignar tareas y responsabilidades (quién hace qué,
Forma disciplinada de asignar tareas y responsabilidades (quién hace qué,
cuándo y cómo)
cuándo y cómo)
► Pretende implementar las mejores prácticas en Ingeniería de Software
Pretende implementar las mejores prácticas en Ingeniería de Software
► Desarrollo iterativo
Desarrollo iterativo
► Administración de requisitos
Administración de requisitos
► Uso de arquitectura basada en componentes
Uso de arquitectura basada en componentes
► Control de cambios
Control de cambios
► Modelado visual del software
Modelado visual del software
► Verificación de la calidad del software
Verificación de la calidad del software
El RUP es un producto de Rational (IBM). Se caracteriza por ser iterativo e
El RUP es un producto de Rational (IBM). Se caracteriza por ser iterativo e
incremental, estar centrado en la arquitectura y guiado por los casos de
incremental, estar centrado en la arquitectura y guiado por los casos de
uso. Incluye artefactos (que son los productos tangibles del proceso como
uso. Incluye artefactos (que son los productos tangibles del proceso como
por ejemplo, el modelo de casos de uso, el código fuente, etc.) y roles
por ejemplo, el modelo de casos de uso, el código fuente, etc.) y roles
(papel que desempeña una persona en un determinado momento, una
(papel que desempeña una persona en un determinado momento, una
persona puede desempeñar distintos roles a lo largo del proceso).
persona puede desempeñar distintos roles a lo largo del proceso).
19. 6 Mejores Prácticas
6 Mejores Prácticas
Desarrollar Software Iterativamente
Desarrollar Software Iterativamente
Modelar el software visualmente
Modelar el software visualmente
Gerenciar (Administración de) los
Gerenciar (Administración de) los
Requerimientos
Requerimientos
Usar arquitecturas basadas en componentes
Usar arquitecturas basadas en componentes
Verificación continua de la calidad
Verificación continua de la calidad
Gerenciar (Control de) los cambios
Gerenciar (Control de) los cambios
20. 6 Mejores Prácticas
6 Mejores Prácticas
► RUP describe como utilizar de forma efectiva
RUP describe como utilizar de forma efectiva
procedimientos comerciales probados en el
procedimientos comerciales probados en el
desarrollo de software para equipos de desarrollo
desarrollo de software para equipos de desarrollo
de software, conocidos como “mejores prácticas”.
de software, conocidos como “mejores prácticas”.
Desarrollo
Iterativo
Modelamiento
Visual
Verificación de
la Calidad
Arquitecturas
/Componentes
Administración de Requerimientos
Control de Cambios
21. Incremento de la
Incremento de la
Productividad en Equipo
Productividad en Equipo
Todos los miembros del equipo comparten
Todos los miembros del equipo comparten
• 1 Base de conocimiento
1 Base de conocimiento
• 1 Proceso
1 Proceso
• 1 Vista de cómo desarrollar software
1 Vista de cómo desarrollar software
• 1 Lenguaje de modelamiento (UML)
1 Lenguaje de modelamiento (UML)
Administrador
Base de Datos
Líder de
Proyecto
Analista
Diseñador/
Desarrollador
Ingeniero de
Desempeño
Pruebas
Administrador de
Configuración
22. Desarrollo Iterativo de Software
Desarrollo Iterativo de Software
► Dados los sistemas de software sofisticados de la
Dados los sistemas de software sofisticados de la
actualidad, no es posible hacer de manera secuencial la
actualidad, no es posible hacer de manera secuencial la
definición completa del problema, diseñar la solución
definición completa del problema, diseñar la solución
completa, construir el software y por último probarlo.
completa, construir el software y por último probarlo.
► El descubrimiento de defectos en fases posteriores de
El descubrimiento de defectos en fases posteriores de
diseño dan como resultado un aumento en los costos y/ó
diseño dan como resultado un aumento en los costos y/ó
la cancelación del proyecto.
la cancelación del proyecto.
El tiempo y dinero gastados en la implementación de un
diseño fallido, son no recuperables
24. Características del Desarrollo Iterativo
Características del Desarrollo Iterativo
Permite un entendimiento incremental del problema a través
Permite un entendimiento incremental del problema a través
de refinamientos sucesivos.
de refinamientos sucesivos.
Habilita una fácil retroalimentación de usuario.
Habilita una fácil retroalimentación de usuario.
Metas específicas permiten que el equipo de desarrollo
Metas específicas permiten que el equipo de desarrollo
mantenga su atención en producir resultados.
mantenga su atención en producir resultados.
El progreso es medido conforme avanzan las
El progreso es medido conforme avanzan las
implementaciones.
implementaciones.
25. Administración de Requerimientos
Administración de Requerimientos
► Licitar, organizar, y documentar la funcionalidad y
Licitar, organizar, y documentar la funcionalidad y
restricciones requeridas.
restricciones requeridas.
► Llevar un registro y documentación de cambios y
Llevar un registro y documentación de cambios y
decisiones.
decisiones.
► Los requerimientos de negocio son fácilmente
Los requerimientos de negocio son fácilmente
capturados y comunicados a través de casos de uso.
capturados y comunicados a través de casos de uso.
► Los casos de uso son instrumentos importantes de
Los casos de uso son instrumentos importantes de
planeación.
planeación.
Modelo de Diseño
Modelo de Implementación Modelo de Prueba
verifica
realización influenciado por
Los casos de uso
Los casos de uso
dirigen el trabajo
dirigen el trabajo
desde el análisis
desde el análisis
hasta las pruebas
hasta las pruebas
26. Arquitectura Basada en Casos de Uso
Arquitectura Basada en Casos de Uso
Se enfoca en el pronto desarrollo de una
Se enfoca en el pronto desarrollo de una
arquitectura ejecutable robusta.
arquitectura ejecutable robusta.
Resistente al cambio mediante el uso de
Resistente al cambio mediante el uso de
interfaces bien definidas.
interfaces bien definidas.
Intuitivamente comprensible.
Intuitivamente comprensible.
Promueve un reuso más efectivo de software.
Promueve un reuso más efectivo de software.
Es derivada a partir de los casos de uso más
Es derivada a partir de los casos de uso más
importantes.
importantes.
27. Arquitectura 4
Arquitectura 4+1
+1
► La vista lógica
La vista lógica, que es el modelo de objetos del
, que es el modelo de objetos del
diseño,
diseño,
► La vista de realización,
La vista de realización, que describe la
que describe la
organización estática del software en su entorno
organización estática del software en su entorno
de desarrollo.
de desarrollo.
► La vista de proceso,
La vista de proceso, que captura los aspectos de
que captura los aspectos de
sincronización y concurrencia del diseño,
sincronización y concurrencia del diseño,
► La vista de distribución,
La vista de distribución, que describe la
que describe la
correspondencia del software sobre el hardware y
correspondencia del software sobre el hardware y
refleja sus aspectos distribuidos,
refleja sus aspectos distribuidos,
29. Control de Cambios del Software
Control de Cambios del Software
► Controlar, llevar un registro y monitorear cambios
Controlar, llevar un registro y monitorear cambios
para permitir un desarrollo iterativo.
para permitir un desarrollo iterativo.
► Establece espacios de trabajo seguros para cada
Establece espacios de trabajo seguros para cada
desarrollador
desarrollador
Provee aislamiento de cambios hechos en otros espacios de
Provee aislamiento de cambios hechos en otros espacios de
trabajo
trabajo
Controla todos los artefactos de software – modelos, código,
Controla todos los artefactos de software – modelos, código,
documentos, etc.
documentos, etc.
ALERT
REPORT
Administración de
Espacios de Trabajo
Desarrollo en
Paralelo
Administración de
Construcción
Integración de
Proceso
30. Fases en RUP
Fases en RUP
► Inicio
Inicio – Define el alcance del proyecto
– Define el alcance del proyecto
► Elaboración
Elaboración – Plan del proyecto, especificación de
– Plan del proyecto, especificación de
características, arquitectura base
características, arquitectura base
► Construcción
Construcción – Construir el producto
– Construir el producto
► Transición
Transición – Transición del producto a la comunidad del
– Transición del producto a la comunidad del
usuario
usuario
Inicio
Inicio Elaboración
Elaboración Construcción
Construcción Transición
Transición
Tiempo
Tiempo
Metas
Metas
Principales
Principales
31. Fase de Inicio
Fase de Inicio
► Propósito
Propósito
Establecer
Establecer casos de negocios
casos de negocios para un nuevo sistema o para alguna
para un nuevo sistema o para alguna
actualización importante de un sistema existente
actualización importante de un sistema existente
Especificar el alcance del proyecto
Especificar el alcance del proyecto
► Resultado
Resultado
Una visión general de los requerimientos del proyecto, i.e., los
Una visión general de los requerimientos del proyecto, i.e., los
requerimientos principales
requerimientos principales
► Un modelo inicial de casos de uso y modelo del dominio (10-20%)
Un modelo inicial de casos de uso y modelo del dominio (10-20%)
Un caso de negocios inicial, incluyendo:
Un caso de negocios inicial, incluyendo:
► Evaluación inicial de riesgos
Evaluación inicial de riesgos
► Una estimación de los recursos requeridos
Una estimación de los recursos requeridos
32. Fase de Elaboración
Fase de Elaboración
► Propósito
Propósito
Analizar el dominio del problema
Analizar el dominio del problema
Establecer una buena arquitectura
Establecer una buena arquitectura
Lidiar con los elementos de riesgo más altos del proyecto
Lidiar con los elementos de riesgo más altos del proyecto
Desarrollar un plan comprensivo mostrando como el
Desarrollar un plan comprensivo mostrando como el
proyecto será completado
proyecto será completado
► Resultado
Resultado
Un modelo del dominio y de casos de uso 80% completo
Un modelo del dominio y de casos de uso 80% completo
Requerimientos suplementarios que capturen los
Requerimientos suplementarios que capturen los
requerimientos no funcionales y cualesquiera requerimientos
requerimientos no funcionales y cualesquiera requerimientos
que no estén asociados con un caso de uso específico
que no estén asociados con un caso de uso específico
Una lista de riesgos revisada
Una lista de riesgos revisada
33. Fase de Construcción
Fase de Construcción
►Propósito
Propósito
Desarrollar incrementalmente producto de
Desarrollar incrementalmente producto de
software completo el cual estará listo para ser
software completo el cual estará listo para ser
transferido al usuario
transferido al usuario
►Productos
Productos
Un modelo completo de diseño y casos de uso
Un modelo completo de diseño y casos de uso
Liberaciones de productos ejecutables de
Liberaciones de productos ejecutables de
funcionalidad incremental
funcionalidad incremental
Documentación de usuario
Documentación de usuario
Una liberación “beta” del producto
Una liberación “beta” del producto
34. Fase de Transición
Fase de Transición
► Hacer la transición final del producto de software al
Hacer la transición final del producto de software al
usuario
usuario
► Productos
Productos
Liberaciones ejecutables de producto
Liberaciones ejecutables de producto
“
“Pruebas beta” para validar el nuevo sistema vs. las expectaciones
Pruebas beta” para validar el nuevo sistema vs. las expectaciones
del usuario
del usuario
Manuales de usuario actualizados
Manuales de usuario actualizados
Documentación de desarrollo actualizada
Documentación de desarrollo actualizada
► Está el usuario satisfecho?
Está el usuario satisfecho?
► Gastos reales de los recursos vs. Gastos previstos
Gastos reales de los recursos vs. Gastos previstos
Aceptables?
Aceptables?
35. Iteraciones
Iteraciones
► Cada fase en RUP puede descomponerse en
Cada fase en RUP puede descomponerse en
iteraciones. Una
iteraciones. Una iteración
iteración es un ciclo de desarrollo
es un ciclo de desarrollo
completo dando como resultado una entrega de
completo dando como resultado una entrega de
producto ejecutable (interna o externa)
producto ejecutable (interna o externa)
Iteración
Iteración
Preliminar
Preliminar
Iteración de
Iteración de
Arquitectura
Arquitectura
Iteración de
Iteración de
Arquitectura
Arquitectura
Iteración de
Iteración de
Desarrollo
Desarrollo
Iteración de
Iteración de
Desarrollo
Desarrollo
Iteración de
Iteración de
Desarrollo
Desarrollo
Iteración de
Iteración de
Transición
Transición
Iteración de
Iteración de
Transición
Transición
Inicio
Inicio Elaboración
Elaboración Construcción
Construcción Transición
Transición
Liberaciones
Liberaciones
externas
internas
iteraciones
36. Modelos y Flujos de Trabajo
Modelos y Flujos de Trabajo
► Un
Un flujo de trabajo
flujo de trabajo es una secuencia de actividades
es una secuencia de actividades
que producen un resultado de valor observable.
que producen un resultado de valor observable.
► Se necesita una forma de describir secuencias
Se necesita una forma de describir secuencias
significativas que produzcan algún resultado
significativas que produzcan algún resultado
válido, y que muestre la interacción entre
válido, y que muestre la interacción entre
trabajadores.
trabajadores.
► En términos de UML pueden ser expresados como
En términos de UML pueden ser expresados como
un diagrama de secuencia, un diagrama de
un diagrama de secuencia, un diagrama de
colaboración, ó como un diagrama de actividad.
colaboración, ó como un diagrama de actividad.
► Los grupos de trabajo agrupan actividades en
Los grupos de trabajo agrupan actividades en
forma lógica
forma lógica
37. Modelos y Flujos de
Modelos y Flujos de
Trabajo
Trabajo
Modelo de
Diseño
Modelo de
Implementación
Modelo de
Prueba
realizado por
realizado por
Implementado por
Implementado por
Flujo de Trabajo
Flujo de Trabajo
de Requerimientos
de Requerimientos
Flujo de Trabajo de
Flujo de Trabajo de
Diseño de Análisis
Diseño de Análisis
Flujo de Trabajo
Flujo de Trabajo
de Implementación
de Implementación
Flujo de Trabajo
Flujo de Trabajo
de Prueba
de Prueba
Modelo de
Caso de Uso
Modelación
Modelación
de Negocios
de Negocios
Modelo de Negocios
verificado por
verificado por
Cada flujo de trabajo describe
Cada flujo de trabajo describe
como crear y mantener un modelo
como crear y mantener un modelo
en particular
en particular
38. Roles que se cumplen en RUP
Roles que se cumplen en RUP
► Analistas:
Analistas:
Analista de procesos de negocio.
Analista de procesos de negocio.
Diseñador del negocio.
Diseñador del negocio.
Analista de sistema.
Analista de sistema.
Especificador de requisitos.
Especificador de requisitos.
39. Roles que se cumplen en RUP
Roles que se cumplen en RUP
► Desarrolladores:
Desarrolladores:
Arquitecto de software.
Arquitecto de software.
Diseñador
Diseñador
Diseñador de interfaz de usuario
Diseñador de interfaz de usuario
Diseñador de cápsulas.
Diseñador de cápsulas.
Diseñador de base de datos.
Diseñador de base de datos.
Implementador.
Implementador.
Integrador.
Integrador.
40. Roles que se cumplen en RUP
Roles que se cumplen en RUP
► Gestores:
Gestores:
Jefe de proyecto
Jefe de proyecto
Jefe de control de cambios.
Jefe de control de cambios.
Jefe de configuración.
Jefe de configuración.
Jefe de pruebas
Jefe de pruebas
Jefe de despliegue
Jefe de despliegue
Ingeniero de procesos
Ingeniero de procesos
Revisor de gestión del proyecto
Revisor de gestión del proyecto
Gestor de pruebas.
Gestor de pruebas.
41. Roles que se cumplen en RUP
Roles que se cumplen en RUP
► Apoyo:
Apoyo:
Documentador técnico
Documentador técnico
Administrador de sistema
Administrador de sistema
Especialista en herramientas
Especialista en herramientas
Desarrollador de cursos
Desarrollador de cursos
Artista gráfico
Artista gráfico
42. Roles que se cumplen en RUP
Roles que se cumplen en RUP
► Especialista en pruebas:
Especialista en pruebas:
Especialista en Pruebas (tester)
Especialista en Pruebas (tester)
Analista de pruebas
Analista de pruebas
Diseñador de pruebas
Diseñador de pruebas
► Otros roles:
Otros roles:
Stakeholders.
Stakeholders.
Revisor
Revisor
Coordinación de revisiones
Coordinación de revisiones
Revisor técnico
Revisor técnico
Cualquier rol
Cualquier rol
43. Conclusiones
Conclusiones
► RUP es una metodología completa y extensa que intenta
RUP es una metodología completa y extensa que intenta
abarcar todo el mundo del desarrollo software.
abarcar todo el mundo del desarrollo software.
► La elaboración de distintos diagramas y artefactos siguiendo la
La elaboración de distintos diagramas y artefactos siguiendo la
metodología RUP proveen una fácil ejecución del proceso de
metodología RUP proveen una fácil ejecución del proceso de
elaboración de un Sistema de Software.
elaboración de un Sistema de Software.
► Lo que hace único a RUP, son que los casos de uso no son sólo
Lo que hace único a RUP, son que los casos de uso no son sólo
una herramienta para especificar los requisitos del sistema,
una herramienta para especificar los requisitos del sistema,
sino que también guían su diseño, implementación y prueba.
sino que también guían su diseño, implementación y prueba.
Los casos de uso constituyen un elemento integrador y una
Los casos de uso constituyen un elemento integrador y una
guía del trabajo.
guía del trabajo.
44. ► Además de utilizar los casos de uso para guiar el proceso; se
Además de utilizar los casos de uso para guiar el proceso; se
presta especial atención al establecimiento temprano de una
presta especial atención al establecimiento temprano de una
buena arquitectura que no se vea fuertemente impactada
buena arquitectura que no se vea fuertemente impactada
ante cambios posteriores durante la construcción y el
ante cambios posteriores durante la construcción y el
mantenimiento. También este propone que cada fase se
mantenimiento. También este propone que cada fase se
desarrolle en iteraciones.
desarrolle en iteraciones.
► Se puede reducir el tiempo de desarrollo de un Sistema de
Se puede reducir el tiempo de desarrollo de un Sistema de
Software, aplicando la metodología RUP ya que permite lograr
Software, aplicando la metodología RUP ya que permite lograr
de una manera fiable y rápida el desarrollo del Sistema
de una manera fiable y rápida el desarrollo del Sistema
deseado
deseado.
.
Conclusiones
Conclusiones
45. Recomendaciones
Recomendaciones
► La metodología RUP cuenta con un enfoque disciplinado en
La metodología RUP cuenta con un enfoque disciplinado en
la asignación de tareas y responsabilidades dentro de una
la asignación de tareas y responsabilidades dentro de una
organización del desarrollo, con la cual se puede mantener
organización del desarrollo, con la cual se puede mantener
una fácil administración de este proceso.
una fácil administración de este proceso.
► Para obtener un máximo control de variables que conlleva
Para obtener un máximo control de variables que conlleva
un desarrollo de aplicaciones y poder mantener una
un desarrollo de aplicaciones y poder mantener una
ordenada implementación de éstas, es importante seguir
ordenada implementación de éstas, es importante seguir
metodologías y estándares que nos lleven a estar en
metodologías y estándares que nos lleven a estar en
competitividad en todo momento.
competitividad en todo momento.
► Al implementar un Desarrollo Rápido de Aplicaciones de un
Al implementar un Desarrollo Rápido de Aplicaciones de un
Sistema particular, es importante la utilización de Patrones.
Sistema particular, es importante la utilización de Patrones.
46. Referencias
Referencias
IBM, Rational Software. (2003). Rational Rapid Developer, Technical
IBM, Rational Software. (2003). Rational Rapid Developer, Technical
Overview. EE.UU: IBM publications, World Wide Web.
Overview. EE.UU: IBM publications, World Wide Web.
ITSA (2008). Metodologías De Desarrollo De Software. Canada: Editorial
ITSA (2008). Metodologías De Desarrollo De Software. Canada: Editorial
Canada Pen.
Canada Pen.
Jacaboson, I., Booch, G., Rumbaugh J. (2000) Proceso Unificado de
Jacaboson, I., Booch, G., Rumbaugh J. (2000) Proceso Unificado de
Desarrollo de Software.
Desarrollo de Software. New York: Editorial Mc Graw Hill.
New York: Editorial Mc Graw Hill.
Sommerville, I. (2005) Ingeniería del software, 7ª edición, Pearson-
Sommerville, I. (2005) Ingeniería del software, 7ª edición, Pearson-
Addison. España: Editorial Wesley.
Addison. España: Editorial Wesley.
Pressman, Roger. (2003) Ingenieria de Software 6ta edic.
Pressman, Roger. (2003) Ingenieria de Software 6ta edic. New York: Editorial
New York: Editorial
Mc Graw Hill.
Mc Graw Hill.
Philippe Kruchten, The Rational Unified Process An Introduction, Addison
Philippe Kruchten, The Rational Unified Process An Introduction, Addison
Wesley, 2001.
Wesley, 2001.
Grady Booch, Object Solutions, Addison-Wesley, 1995.
Grady Booch, Object Solutions, Addison-Wesley, 1995.
Walker Royce, Software Project Management A Unified Framework,
Walker Royce, Software Project Management A Unified Framework,
Addison-Wesley, 1998.
Addison-Wesley, 1998.
![Estructura del RUP
Estructura del RUP
[Dimensiones]
[Dimensiones]
El proceso puede describirse en dos dimensiones, o a
El proceso puede describirse en dos dimensiones, o a
lo largo de dos ejes:
lo largo de dos ejes:
El eje horizontal representa
El eje horizontal representa tiempo
tiempo y muestra el
y muestra el
aspecto dinámico del proceso, expresado en términos
aspecto dinámico del proceso, expresado en términos
de
de ciclos
ciclos,
, fases
fases,
, iteraciones
iteraciones, y
, y metas
metas.
.
El eje vertical representa el aspecto estático del
El eje vertical representa el aspecto estático del
proceso; como está descrito en términos de
proceso; como está descrito en términos de
actividades
actividades,
, artefactos
artefactos,
, trabajadores
trabajadores y
y flujos de trabajo
flujos de trabajo.
.](https://image.slidesharecdn.com/rup-250502235308-82ca34a2/85/RUP-RATIONAL-UNIFIED-PROCESS-PROCESO-UNIFICADO-15-320.jpg)
