“AÑO DEL BUEN SERVICIO AL CIUDADANO”

INSTITUTO SUPERIOR TECNOLÓGICO PÚBLICO

“JOAQUÍN REÁTEGUI MEDINA”

CARRERA TÉCNICA PROFESIONAL:

COMPUTACIÓN E INFORMÁTICA
SEMESTRE:
IV
UNIDAD DIDÁCTICA:
METODOLOGIA DE DESARROLLO DE SOFTWARE
TEMA:
FILOSOFIA RUP, FASES DE DESARROLLO
PROFESOR:
ING. MANUEL SALVADOR VARGAS P.
INTEGRANTES:
 ERIS
 ROMAINA AHUANARI WILLY D

NAUTA-LORETO-PERÚ

2017
 FILOSOFIA RUP Y FASES DE DESARROLLO
El Proceso Racional Unificado o RUP (por sus siglas en inglés de Rational Unified Process) es
un proceso de desarrollo de software desarrollado por la empresa Rational Software,
actualmente propiedad de IBM.1 Junto con el 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.
El RUP no es un sistema con pasos firmemente establecidos, sino un conjunto de metodologías
adaptables al contexto y necesidades de cada organización. También se conoce por este nombre
al software, también desarrollado por Rational, que incluye información entrelazada de
diversos artefactos y descripciones de las diversas actividades. Está incluido en el Rational
Method Composer (RMC), que permite la personalización de acuerdo con las necesidades.
Originalmente se diseñó un proceso genérico y de dominio público, el Proceso Unificado, y una
especificación más detallada, el Rational Unified Process, que se vendiera como producto
independiente.
HISTORIA
Los orígenes de RUP se remontan al modelo espiral original de Barry Boehm. Ken Hartman, uno
de los contribuidores claves de RUP colaboró con Boehm en la investigación. En 1995, Rational
Software compró una compañía sueca llamada Objectory AB, fundada por Ivar Jacobson, famoso
por haber incorporado los casos de uso a los métodos de desarrollo orientados a objetos.
El Rational Unified Process fue el resultado de una convergencia de Rational Approach y Objectory
(el proceso de la empresa Objectory AB). El primer resultado de esta fusión fue el Rational
Objectory Process, la primera versión de RUP, fue puesta en el mercado en 1998, siendo el
arquitecto en jefe Philippe Kruchten.
El primer libro para describir el proceso fue titulado The Unified Software Development Process3
En 2006, IBM creó un subconjunto de RUP ajustado para proyectos de desarrollo ágil - publicado
como un método libre, llamado OpenUP a través del sitio de Eclipse
PRINCIPALES CARACTRISTICAS
 Desarrollo iterativo
 Administración de requisitos
 Uso de arquitectura basada en componentes
 Control de cambios
 Modelado visual del software
 Verificación de la calidad del software
 Pretende implementar las mejores prácticas en Ingeniería de Software, de forma que se
adapte a cualquier proyecto
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 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 (papel que desempeña una persona en un determinado momento, una persona puede
desempeñar distintos roles a lo largo del proceso).
PRINCPIO DE DESARROLLO
La Filosofía del RUP está basado en 6 principios clave que son los siguientes:
Adaptar el proceso
El proceso deberá adaptarse a las necesidades del cliente ya que es muy importante interactuar
con él. Las características propias del proyecto, el tamaño del mismo, así como su tipo o las
regulaciones que lo condicionen, influirán en su diseño específico. También se deberá tener en
cuenta el alcance del proyecto.
Equilibrar prioridades
Los requisitos de los diversos participantes pueden ser diferentes, contradictorios o disputarse
recursos limitados. Debe poder encontrarse un equilibrio que satisfaga los deseos de todos .
Gracias a este equilibrio se podrán corregir desacuerdos que surjan en el futuro.
Demostrar valor iterativamente
Los proyectos se entregan, aunque sea de un modo interno, en etapas iteradas. En cada iteración
se analiza la opinión de los inversores, la estabilidad y calidad del producto, y se refina la dirección
del proyecto así como también los riesgos involucrados.
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.
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, también es una estrategia de desarrollo de software.
Elevar el nivel de abstracción
Este principio dominante motiva el uso de conceptos reutilizables tales como patrones de diseño
del software, lenguajes 4GL o esquemas (frameworks) por nombrar algunos. Estos se pueden
acompañar por las representaciones visuales de la arquitectura, por ejemplo con UML.
ESTRUCTURA DEL PROCESO
El proceso puede ser descrito en dos dimensiones o ejes :
Eje horizontal: Representa el tiempo y es considerado el eje de los aspectos dinámicos del
proceso. Indica las características del ciclo de vida del proceso expresado en términos de fases,
iteraciones e hitos. Se puede observar en la Figura 6 que RUP consta de cuatro
fases: Inicio, Elaboración, Construcción y Transición. Como se mencionó anteriormente cada
fase se subdivide a la vez en iteraciones.
Eje vertical: Representa los aspectos estáticos del proceso. Describe el proceso en términos
de componentes de proceso, disciplinas, flujos de trabajo, actividades, artefactos y roles.

Estructura Estática
La estructura estática establece las actividades específicas de cada uno de los
integrantes del equipo de desarrollo, así como la forma de realizar estas actividades.
RUP define cuatro elementos en la estructura estática:
· Roles.
· Actividades.
· Flujo de trabajo.
Roles
Un rol define el comportamiento y responsabilidades de un individuo, o de un grupo de individuos
trabajando juntos como un equipo. Una persona puede desempeñar diversos roles, así como un
mismo rol puede ser representado por varias personas.
RUP define grupos de roles, agrupados por participación en actividades
relacionadas. Estos grupos son:
Analistas:
 Analista de procesos de negocio.
 Diseñador del negocio.
 Analista de sistema.
 Especificador de requisitos.
Desarrolladores:
 Arquitecto de software.
 Diseñador de interfaz de usuario.
 Diseñador de base de datos.
Gestores:
 Jefe de proyecto.
 Jefe de configuración.
 Jefe de pruebas.
Apoyo:
 Documentador técnico.
 Administrador de sistema.
 Artista gráfico.
Especialistas en pruebas:
 Especialista en Pruebas (tester).
 Analista de pruebas.
 Diseñador de pruebas.

ACTIVIDADES
Una actividad es una unidad de trabajo que es asignado a un rol específico. Las actividades tienen
un objetivo concreto, normalmente expresado en términos de crear o actualizar algún producto.

ARTEFACTOS
Un producto o artefacto es un trozo de información que es producido, modificado o usado durante
el proceso de desarrollo de software. Los productos son los resultados tangibles del proyecto,
las cosas que va creando y usando hasta obtener el producto final.

FLUJOS DE TRABAJO
Un flujo de trabajo es una relación de actividades que nos producen unos resultados observables.
RUP determina los siguientes flujos de trabajo:
  Modelado de negocio.
 Requisitos.
 Análisis y diseño.
 Implementación.
 Pruebas.
 Despliegue.
 Gestión del proyecto.

Estructura Dinámica del proceso.

RUP se repite a lo largo de una serie de ciclos que constituyen la vida de un producto. Cada ciclo
concluye con una generación del producto para los clientes. Cada ciclo consta de
cuatro fases: Inicio, Elaboración, Construcción y Transición. Cada fase se subdivide a la vez en
iteraciones, el número de iteraciones en cada fase es variable. Cada fase se concluye con un hito
bien definido, un punto en el tiempo en el cual se deben tomar ciertas decisiones críticas y
alcanzar las metas clave antes de pasar a la siguiente fase, ese hito principal de cada fase se
compone de hitos menores que podrían ser los criterios aplicables a cada iteración.
Proceso iterativo e incremental
RUP propone tener un proceso en partes más pequeñas o mini proyectos, permitiendo generar
un equilibrio entre casos de uso y arquitectura. Cada mini proyecto se puede ver como una
iteración del cual se obtiene un incremento que produce un crecimiento en el producto.
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.
 DIMENSIONES DE LA FILOSOFIA RUP
 Establece oportunidad y alcance
 Identifica las entidades externas o actores con las que se trata
 Identifica los casos de uso
RUP comprende 2 aspectos importantes por los cuales se establecen las disciplinas:
Proceso de la filosofía RUP
Las etapas de esta sección son:
 Modelado de negocio
 Requisitos
 Análisis y Diseño
 Implementación
 Pruebas
 Despliegue
Soporte
En esta parte nos encontramos con las siguientes etapas:

 Gestión del cambio y configuraciones

 Gestión del proyecto
  Entorno
La estructura dinámica de RUP es la que permite que éste sea un proceso de desarrollo
fundamentalmente iterativo, y en esta parte se ven inmersas las cuatro fases descritas
anteriormente:

 Inicio (también llamado Incepción o Concepción).

 Elaboración.
 Desarrollo (también llamado Implementación, Construcción).
 Cierre (también llamado Transición).

FASES DE LA METODOLOGIA RUP

Fase de Inicio
Esta fase tiene como propósito definir y acordar el alcance del proyecto con los patrocinadores
o alumnos de un proyecto en el cual tenemos que, identificar los riesgos asociados al proyecto,
proponer una visión muy general de la arquitectura de software y producir el plan de las fases y
el de iteraciones posteriores.
Fase de Elaboración
En la fase de elaboración se seleccionan los casos de uso que permiten definir la arquitectura
base del sistema y se desarrollaran en esta fase, se realiza la especificación de los casos de uso
seleccionados y el primer análisis del dominio del problema, se diseña la solución preliminar.
Fase de Desarrollo
El propósito de esta fase es completar la funcionalidad del sistema, para ello se deben clarificar
los requisitos pendientes, administrar los cambios de acuerdo a las evaluaciones realizados por
los usuarios y se realizan las mejoras para el proyecto.
Fase de Transición
El propósito de esta fase es asegurar que el software esté disponible para los usuarios finales,
ajustar los errores y defectos encontrados en las pruebas de aceptación, capacitar a los usuarios
y proveer el soporte técnico necesario. Se debe verificar que el producto cumpla con las
especificaciones entregadas por las personas involucradas en el proyecto.
CICLO DE VIDA RUP
El ciclo de vida RUP es una implementación del desarrollo en espiral. Fue creado ensamblando los
elementos en secuencias semi-ordenadas. El ciclo de vida organiza las tareas en fases e
iteraciones.
RUP divide el proceso en cuatro fases, dentro de las cuales se realizan pocas pero grandes y
formales iteraciones en número variable según el proyecto. En la Figura muestra cómo varía el
esfuerzo asociado a las disciplinas según la fase en la que se encuentre el proyecto RUP.
Las primeras iteraciones (en las fases de Inicio y Elaboración) se enfocan hacia la comprensión
del problema y la tecnología,
la delimitación del ámbito del
proyecto, la eliminación de
los riesgos críticos, y al
establecimiento de
2
una baseline (línea base) de
la arquitectura.
Durante la fase de inicio las
iteraciones hacen mayor
énfasis en actividades de
modelado del negocio y de
requisitos.
En la fase de elaboración, las iteraciones se orientan al desarrollo de la baseline de la
arquitectura, abarcan más los flujos de trabajo de requisitos, modelo de negocios (refinamiento),
análisis, diseño y una parte de implementación orientado a la base de la arquitectura.
Para cada iteración se seleccionan algunos Casos de Uso, se refinan su análisis y diseño y se
procede a su implementación y pruebas. Se realiza una pequeña cascada para cada ciclo. Se
realizan iteraciones hasta que se termine la implementación de la nueva versión del producto.
En la fase de transición se pretende garantizar que se tiene un producto preparado para su
entrega a la comunidad de usuarios.
Como se puede observar en cada fase participan todas las disciplinas, pero dependiendo de la
fase el esfuerzo dedicado a una disciplina varía.