ANÁLISIS Y DISEÑO DE SISTEMAS I ING. ALEYDA ROCHA O.

TEMA I

PROCESO UNIFICADO DE DESARROLLO DE SOFTWARE (RUP)

1. CARACTERÍSTICAS ESENCIALES

 Forma disciplinada de asignar tareas y responsabilidades (quién hace qué, cuándo y cómo)
 Pretende implementar las mejores prácticas en Ingeniería de Software
 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

2. PRINCIPIOS

La metodología RUP se basa en un conjunto de principios de desarrollo de software y las mejores

prácticas, por ejemplo:

a) Desarrollo de software iterativo

b) La gestión de requisitos
c) El uso de una arquitectura basada en componentes
d) Software de modelado visual
e) La verificación de la calidad del software
f) Control de cambios en el software

a) DESARROLLO ITERATIVO

Teniendo en cuenta el tiempo necesario para desarrollar un software grande y sofisticada, no se

puede definir el problema y construir software en un solo paso. Los requisitos cambiarán a menudo
en el curso del desarrollo del proyecto, debido a las restricciones de la arquitectura, las necesidades
del usuario o para una mayor comprensión del problema original.

Los cambios permiten que el proyecto para estar constantemente refinada, y la señal a los elementos
del proyecto de alto riesgo como las tareas de mayor prioridad. Idealmente, al final de cada iteración
habrá una versión ejecutable, lo que ayuda a reducir el riesgo de configuración de diseño, que
permite una mayor respuesta de los usuarios y ayudar al desarrollador a permanecer centrado.
ANÁLISIS Y DISEÑO DE SISTEMAS I ING. ALEYDA ROCHA O.

RUP utiliza el desarrollo iterativo e incremental por las siguientes razones:

 La integración se hace paso a paso durante el proceso de desarrollo, cada paso se limita a
unos pocos elementos
 La integración es menos complejo, reduciendo el coste y aumentar la eficiencia
diseño de las piezas por separado y / o implementación pueden ser fácilmente identificados
para su posterior reutilización
 Requisitos cambios son registrados y pueden ser acomodados
 Los riesgos se abordan en el comienzo del desarrollo y cada iteración permite la verificación
de riesgos ya percibidas y la identificación de nuevos
 Para la arquitectura de software se mejora a través de un repetidor scrutinize
 El uso de iteraciones, un proyecto tendrá un plan general, así como varios planes de
iteración. La participación de las partes interesadas a menudo se alienta a cada entrega. En
esta forma, las entregas sirven como una manera de conseguir el compromiso de los
involucrados, mientras que también promueve una comparación constante entre las
necesidades y el desarrollo de la organización a los conflictos que surjan.

b) LA GESTIÓN DE REQUISITOS

La gestión de requisitos en RUP se centra en encontrar el final – el usuario necesita para la

identificación y especificación de lo que necesita y la identificación de lo que debe ser cambiado.
Esto trae los siguientes beneficios:

La corrección de los requisitos genera la corrección del producto, por lo que se satisfacen las
necesidades de los usuarios se incluirán las características requeridas, lo que reduce el costo de los
acontecimientos posteriores.

RUP sugiere que la administración de requerimientos tiene que seguir las actividades:

 Análisis de los problemas es que de acuerdo con el problema y crear medidas que
probarán su valor para la organización
 La comprensión de las necesidades de sus grupos de interés es para compartir el
problema y los valores con los principales interesados y elevar lo que las necesidades están
involucradas en el desarrollo de la idea
 La definición del problema es la definición de las características de las necesidades y el
diseño de los casos de uso, actividades que mostrarán fácilmente los requisitos de alto nivel
y el esquema modelo de uso del sistema
 Administrar el alcance del sistema es el alcance de los cambios que se comunica con
base en el progreso y los resultados seleccionados en el orden en que los diagramas de flujo
de los casos de uso son atacados
 Refinar los ajustes del sistema de ofertas con los detalles de los diagramas de flujo de
casos de uso con las partes interesadas con el fin de crear una especificación de las
aplicaciones de software que puede servir como un contrato entre su grupo y el cliente y
puede guiar las actividades de ensayo y proyecto
 Los requisitos de gestión del cambio es la forma de identificar las llegadas de los cambios
en las aplicaciones en un proyecto que ya ha comenzado
ANÁLISIS Y DISEÑO DE SISTEMAS I ING. ALEYDA ROCHA O.

c) EL USO DE UNA ARQUITECTURA BASADA EN COMPONENTES

La arquitectura basada en componentes crea un sistema que es fácilmente extensible, intuitiva y

fácil de entender y promueve la reutilización de software.

Un componente de frecuencia asociado con un conjunto de objetos en objetos – programación

orientada

Arquitectura de software aumenta en importancia cuando un sistema se hace más grande y más
compleja. RUP se centra en la producción de arquitectura básica en los primeros pocas
iteraciones. Esta arquitectura se convierte en un prototipo en los ciclos iniciales de desarrollo.

La arquitectura desarrollada en cada iteración para convertirse en la arquitectura final del sistema.
RUP también propuso reglas de diseño y limitaciones para capturar normas de arquitectura. Para
el desarrollo iterativo es posible para identificar gradualmente componentes que a continuación se
pueden desarrollar o comprado reutilizada. Estos componentes se construyen a menudo en las
infraestructuras existentes, tales como CORBA y COM o Java EE, o PHP

d) SOFTWARE DE MODELADO VISUAL

Haciendo abstracción de su programación de su código y representarla por medio de bloques de

construcción gráficas constituye una forma eficaz de obtener una visión general de una solución. El
uso de esta representación, los recursos técnicos pueden determinar la mejor manera de poner en
práctica un conjunto dado de interdependencias lógicas.

Esto también crea una capa intermedia entre el proceso de negocio y el código necesario a través
de tecnología de la información. Un modelo en este contexto es una pantalla y al mismo tiempo una
simplificación de un diseño complejo. RUP especifica qué modelos son necesarios y por qué.

El Lenguaje de Modelado Unificado (UML) se puede utilizar para el modelado de casos de uso,
diagramas de clases y otros objetos. RUP también analiza otras formas de construir estos modelos.

e) SOFTWARE DE CONTROL DE CALIDAD

Aseguramiento de la calidad del software es el punto de fallo más común en los proyectos de
software, ya que esto es a menudo algo que no se había pensado anteriormente y, a veces es
tratado por diferentes equipos. RUP ayuda en la planificación del control de calidad y se encarga de
su construcción en todos los procesos de participación de todos los miembros del equipo.

No es una tarea está dirigida específicamente a la calidad; RUP supone que cada miembro del
equipo es responsable de la calidad durante todo el proceso. El proceso se centra en el
descubrimiento del nivel esperado de la calidad y proporciona pruebas en los procesos para medir
este nivel.
ANÁLISIS Y DISEÑO DE SISTEMAS I ING. ALEYDA ROCHA O.

f) CONTROL DE CAMBIOS EN EL SOFTWARE

En todos los proyectos de software, los cambios son inevitables. RUP define métodos para controlar,
seguir y supervisar estos cambios. RUP define también el trabajo seguro de espacios (espacios de
trabajo seguros en inglés), lo que garantiza que un sistema de ingeniería de software no se ve
afectada por los cambios en otros sistemas. Este concepto es pegar bien con arquitecturas de
software basados en componentización.

3. ROLES

Según RUP, un rol es un puesto que puede ser asignado a una persona o conjunto de personas que
trabajan juntos en un equipo, y que requiere responsabilidades y habilidades sobre cómo realizar
actividades específicas y desarrollar determinados artefactos.

Los miembros de un equipo de proyecto, generalmente cubren varios roles; sin embargo, los roles
no son individuales, ellos más bien describen cómo los individuos se comportan en un negocio y qué
responsabilidades tienen estos individuos.

RUP clasifica los roles en cinco grandes grupos: Analistas, desarrolladores, probadores, directivos
y otros:

 Analistas: Analista del proceso de negocios, diseñador de negocios, revisor del modelo de
negocios, analista de sistema, especificador de requisitos, revisor de requisitos y diseñador
de la interfaz de usuario.

 Desarrolladores: Arquitecto de software, revisor de la arquitectura, diseñador, diseñador de

cápsula, diseñador de base de datos, revisor del diseño, programador, revisor del código,
integrador.

 Probadores: Diseñador de prueba, probador.

 Directivos: Director de control de cambio, director de configuración, director de implantación,

ingeniero de proceso, director del proyecto, revisor del proyecto.

 Otros: Stakeholder, cualquier rol, desarrollador de cursos, artista gráfico, administrador de

sistema, documentador técnico, especialista en herramientas.
ANÁLISIS Y DISEÑO DE SISTEMAS I ING. ALEYDA ROCHA O.

4. FASES

Cada ciclo constas de cuatro fases: inicio, elaboración, construcción, y transición

Cada fase se subdivide en iteraciones. En cada iteración se desarrolla en secuencia un conjunto de

disciplinas o flujos de trabajos.

Hitos

Cada fase finaliza con un hito. Cada hito se determina por la disponibilidad de un conjunto de
artefactos, es decir un conjunto de modelos o documentos que han sido desarrollados hasta alcanzar
un estado predefinido.

Los hitos tienen muchos objetivos. El más crítico es que los directores deben tomar ciertas
decisiones antes de que el trabajo continúe con la siguiente fase. Los hitos también permiten
controlar la dirección y progreso del trabajo. Al final se obtiene un conjunto de datos a partir del
seguimiento del tiempo y esfuerzo consumidos en cada fase. Estos datos son útiles para las
estimaciones en futuros proyectos.
ANÁLISIS Y DISEÑO DE SISTEMAS I ING. ALEYDA ROCHA O.

a) FASE DE INICIO

Durante la fase de inicio se desarrolla una descripción del producto final, y se presenta el análisis
del negocio. Esta fase responde las siguientes preguntas:

 ¿Cuáles son las principales funciones del sistema para los usuarios mas
 importantes?
 ¿Cómo podría ser la mejor arquitectura del sistema?
 ¿Cuál es el plan del proyecto y cuánto costará desarrollar el producto?

En esta fase se identifican y priorizan los riesgos más importantes. El objetivo de esta fase es ayudar
al equipo de proyecto a decidir cuáles son los verdaderos objetivos del proyecto. Las iteraciones
exploran diferentes soluciones posibles, y diferentes arquitecturas posibles.

Puede que todo el trabajo físico realizado en esta fase sea descartado. Lo único que normalmente
sobrevive a la fase de inicio es el incremento del conocimiento en el equipo.

Los artefactos que típicamente sobreviven a esta fase son:

 Un enunciado de los mayores requerimientos planteados generalmente como casos de uso.

 Un boceto inicial de la arquitectura.
 Una descripción de los objetivos del proyecto.
 Una versión muy preliminar del plan del proyecto.
 Un modelo del negocio.

La fase de inicio finaliza con el Hito de Objetivos del Ciclo de Vida. Este hito es alcanzado cuando
el equipo de proyectos y los stakeholders llegan a un acuerdo sobre:

1. Cuál es el conjunto de necesidades del negocio, y que conjunto de funciones satisfacen estas
necesidades.
2. Una planificación preliminar de iteraciones.
3. Una arquitectura preliminar.

Debe poder responderse las siguientes cuestiones:

 ¿Se ha determinado con claridad el ámbito del sistema? ¿Se ha determinado lo que va a
estar dentro del sistema y fuera del sistema?
 ¿Se ha llegado a un acuerdo con todas las personas involucradas (stakeholders) sobre los
requisitos funcionales del sistema?
 ¿Se vislumbra una arquitectura que pueda soportar estas características?
 ¿Se identifican los riesgos críticos? ¿Se prevé forma de mitigarlos?
 ¿El uso del producto justifica la relación costo-beneficio?
 ¿Es factible para su organización llevar adelante el proyecto?
 ¿Están los inversores de acuerdo con los objetivos?
ANÁLISIS Y DISEÑO DE SISTEMAS I ING. ALEYDA ROCHA O.

b) FASE DE ELABORACIÓN

Durante la fase de elaboración se especifican en detalle la mayoría de los casos de uso del producto
y se diseña la arquitectura.

Las iteraciones en la fase de elaboración:

 Establecen una firme comprensión del problema a solucionar.

 Establece la fundación arquitectural para el software.
 Establece un plan detallado para las siguientes iteraciones.
 Elimina los mayores riesgos.

El resultado de esta fase es la línea base de la arquitectura. En esta fase se construyen típicamente
los siguientes artefactos:

 El cuerpo básico del SW en la forma de un prototipo arquitectural.

 Casos de prueba
 La mayoría de los casos de uso (80%) que describen la funcionalidad del sistema.
 Un plan detallado para las siguientes iteraciones.

La fase de elaboración finaliza con el hito de la Arquitectura del Ciclo de Vida. Este hito se alcanza
cuando el equipo de desarrollo y los stakeholders llegan a un acuerdo sobre:

 Los casos de uso que describen la funcionalidad del sistema.

 La línea base de la arquitectura
 Los mayores riesgos han sido mitigados
 El plan del proyecto

Al alcanzar este hito debe poder responderse a preguntas como:

 ¿Se ha creado una línea base de la arquitectura? ¿Es adaptable y robusta? ¿Puede
evolucionar?
 ¿Se han identificado y mitigado los riesgos más graves?
 ¿Se ha desarrollado un plan del proyecto hasta el nivel necesario para respaldar una agenda,
costes, y calidad realista?
 ¿Proporciona el proyecto, una adecuada recuperación de la inversión?
 ¿Se ha obtenido la aprobación de los inversores?

c) FASE DE CONSTRUCCIÓN

Durante la fase de construcción se crea el producto. La línea base de la arquitectura crece hasta
convertirse en el sistema completo.

Al final de esta fase, el producto contiene todos los casos de uso implementados, sin embargo,
puede que no esté libre de defectos. Los artefactos producidos durante esta fase son:
ANÁLISIS Y DISEÑO DE SISTEMAS I ING. ALEYDA ROCHA O.

 El sistema software
 Los casos de prueba
 Los manuales de usuario

La fase de construcción finaliza con el hito de Capacidad Operativa Inicial. Este hito se alcanza
cuando el equipo de desarrollo y los stakeholders llegan a un acuerdo sobre:

 El producto es estable para ser usado

 El producto provee alguna funcionalidad de valor
 Todas las partes están listas para comenzar la transición

d) FASE DE TRANSICIÓN

La fase de transición cubre el período durante el cual el producto se convierte en la versión beta.

Las iteraciones en esta fase continúan agregando características al SW. Sin embargo, las
características se agregan a un sistema que el usuario se encuentra utilizando activamente.
Los artefactos construidos en esta fase son los mismos que en la fase de construcción. El equipo se
encuentra ocupado fundamentalmente en corregir y extender la funcionalidad del sistema
desarrollado en la fase anterior.

La fase de transición finaliza con el hito de Lanzamiento del Producto, Este hito se alcanza cuando
el equipo de desarrollo y los stakeholders llegan a un acuerdo sobre:

 Se han alcanzado los objetivos fijados en la fase de Inicio.

 El usuario está satisfecho.

5. DISCIPLINAS

Cada disciplina es un conjunto de actividades relacionadas (flujos de trabajo) vinculadas a un área

específica dentro del proyecto total. Las más importantes son: Requerimientos, Análisis, Diseño,
Codificación, y Prueba.

El agrupamiento de actividades en disciplinas es principalmente una ayuda para comprender el

proyecto desde la visión tradicional en cascada.
ANÁLISIS Y DISEÑO DE SISTEMAS I ING. ALEYDA ROCHA O.

Cada disciplina está asociada con un conjunto de modelos que se desarrollan. Estos modelos están
compuestos por artefactos. Los artefactos más importantes son los modelos que cada disciplina
realiza: modelo de casos de uso, modelo de diseño, modelo de implementación, y modelo de prueba.

El Proceso Unificado consiste en una serie de disciplinas o flujos de trabajo que van desde los
requisitos hasta las pruebas. Los flujos de trabajo desarrollan modelos desde el modelo de casos de
uso hasta el modelo de pruebas.