Que Es RUP

¿Que es RUP?
RUP (Rational Unified Process) es una secuencia de

pasos necesarios para el desarrollo y/o
mantenimiento de gran cantidad de sistemas, en
diferentes áreas de aplicación diferentes
organizaciones, diferentes medios de competencia y en proyectos de tamaños
variables (desde el más básico al más complejo). Actualmente es propiedad de
International Business Machines (IBM) y está basado en un enfoque
disciplinado de asignación de tareas y responsabilidades dentro de
una organización de desarrollo con la finalidad de asegurar la obtención de un
software de alta calidad que satisfagan la necesidad de los usuarios finales
dentro de un calendario y tiempo predecible.
Elementos de RUP
 Disciplinas: son los 'contenedores' empleados para organizar todas las

actividades durante el ciclo de vida del sistema.
 Artefactos: son los elementos de entrada y salida de las actividades. Es
un elemento que el proyecto produce y utiliza para componer el
producto final.
 Flujos de Trabajo: constituye la secuencia de actividades que producen
resultados visibles por medio de la integración de los roles y las
actividades, artefactos y disciplinas.
 Roles: son las personas o entes que están involucradas en cada proceso
Diagramas UML empleados en cada fase de la metodología RUP y los artefactos
que genera.
Estructura y Fases de RUP
Principalmente RUP esta compuesta por el trabajo realizado en función de dos

vertientes que originalmente la definen como tal.
La primera es
la dimensión horizontal (véase la
ilustración 1) representa
el aspecto dinámico del proceso
que, de acuerdo con este, se vaya
ejecutando en función del tiempo;
estos procesos se expresan en
forma de ciclos, fases, iteraciones
e hitos.
La segunda dimensión representa

el aspecto estático de esta metodología; principalmente se refiere a las
actividades, disciplinas, flujos de trabajo, artefactos (documentación y
diagramas esenciales) y roles (personas que desempeñan un papel en el
desarrollo del sistema).
Dentro de estas vertientes derivan una serie de hitos que permiten definir el
alcance del proyecto para luego planificarlo y elaborar una arquitectura base
que dará pie a la construcción del sistema y así finalmente permitirá la
transición a los usuarios por medio de la liberación del software terminado,
pero no publicado (periodo de prueba).
Durante el ciclo de vida RUP, cada iteración es llevada a cabo por dos disciplinas
que son disciplina de Desarrollo y disciplina de Soporte.
La disciplina de Desarrollo está estructurada de la siguiente manera:

 Ingeniería de negocios: es aplicada para entender las necesidades y la
cultura empresarial dentro de la organización.
 Requerimientos: para trasladar las necesidades a un sistema
automatizado.
 Análisis y Diseño: permite representar los requerimientos obtenidos en
una arquitectura de software.
 Implementación: se crea un software que se ajuste a la arquitectura
alcanzada y que tenga el comportamiento deseado.
 Pruebas: permite asegurar que el comportamiento requerido sea el
correcto y que todo lo solicitado este presente.
La disciplina de Soporte se estructura del modo siguiente:
 Configuración y Administración del Cambio: guarda todas las versiones

del proyecto.
 Administración Directa del Proyecto: administra los horarios y recursos.
 Ambiente: gestiona todo el entorno de desarrollo.
 Distribución: hace todo lo necesario para la salida del proyecto
Ilustración 1
Fase de Análisis
La fase inicial de la metodología RUP es sumamente importante ya que en la
misma se definirá que hará el sistema y el alcance del mismo. Alrededor de
estos lineamientos gira una gran cantidad de consideraciones que son
realmente necesarias e importantes para el proceso de conceptualizar lo que el
usuario líder quiere.
La importancia de esta fase reside, en que no existe herramientas tecnológicas
para la documentación de requerimientos, lo que hace que el tiempo en esta
fase sea mayor. Un error durante esta etapa elevaría exponencialmente el costo
de la producción del software, también esta etapa es sumamente difícil ya que
en la misma surgen contradicciones y ambigüedades que atentan contra el
correcto comienzo de la vida del software.
No es un secreto que la ausencia de información acerca del problema y el

ambiente donde se encuentra el mismo representa una causa proporcional de
una incorrecta conceptualización lo que acarrea un impacto en el dominio de
aplicación del software que se desarrollará y en el ambiente donde este será
implementado. Muchas veces esta causa reside más en la parte humana ya que
existen algunos usuarios que no conocen ellos mismos cómo se llevan, de
manera exacta, a cabo las tareas que lo ligan a un proceso por otro lado existen
los usuarios que son reacios al cambio o sencillamente son incapaces de tomar
decisiones por temor lo que hace muy difícil de extraer requerimientos.
En esta fase la idea fundamental es entender a ciencia cierta qué es lo que se

desea alcanzar por medio de la determinación de la visión, alcance y limitación
del proyecto considerando el tiempo, los costos y riesgos que involucra la
construcción del mismo.
Consideraciones del Analista
Es elemental tomar en cuenta una serie de puntos durante la fase de análisis,
estos son elementales para tener una certeza de que es lo que se quiere y a
quien(es) afectara el sistema a desarrollar.
Estos puntos pueden listarse de la manera siguiente:
1. El tiempo tope para la puesta en marcha del sistema a desarrollar.
2. Si el cliente es el usuario final.
3. Si los usuarios tienen conocimientos en manejo de herramientas
informáticas.
4. Explorar las expectativas del usuario. Que quiere el usuario que haga el
sistema, como quiere que se comporte el mismo y como él (el usuario)
describiría el sistema que él desea.
5. Es elemental saber si la(s) persona(s) que son o serán sometidas a un
instrumento de recolección de datos son las calificadas para tal proceso.
6. Hay que evaluar la posibilidad o necesidad de que el sistema sea
ampliado futuramente.
7. La frecuencia del mantenimiento del sistema (en caso que lo necesite).
8. Los aspectos legales del sistema, si existe algún ente u órgano regulador
que intervenga con alguna parte del sistema.
9. Con respecto a la gerencia es importante saber en cuanto tiempo
estipulan recuperar lo invertido en el proyecto.
Determinación de Requerimientos
Se puede definir un requerimiento como un aviso, manifestación o pregunta

que se hace, generalmente bajo fe notarial, a alguien exigiendo o interesando
de él que exprese y declare su actitud o su respuesta.
Cuando este término es empleado en la metodología RUP se dice que son las
necesidades de un usuario para resolver un problema o alcanzar un objetivo,
basándose este hecho a una condición primordial presente en un sistema o
componente del mismo para satisfacer una especificación dada.
Los requerimientos, como se dijo anteriormente, son la base fundamental del

sistema por ende los mismo deben contener una serie de características, las
cuales son las que definen la importancia del mismo para el desarrollo del
sistema, estas características son:
 Necesario: Un requerimiento es necesario si su omisión provoca una
deficiencia en el sistema a construir, y además su capacidad,
características físicas o factor de calidad no pueden ser reemplazados por
otras capacidades del producto o del proceso.
 Conciso: Un requerimiento es conciso si en su redacción resume
claramente su objetivo. Su redacción debe ser simple y clara para
aquellos que vayan a consultarlo en un futuro.
 Completo: Un requerimiento está completo si no necesita ampliar
detalles en su redacción, es decir, si se proporciona la información
suficiente para su comprensión. Esta característica se cumple cuando se
incluyen todas las funciones que el cliente necesita sin hacer
redundancia.
 Consistente: Un requerimiento es consistente si no es contradictorio con
otro requerimiento.
 No ambiguo: Un requerimiento no es ambiguo cuando tiene una sola
interpretación. El lenguaje usado en su definición, no debe causar
confusiones.
 Verificable: Un requerimiento es verificable cuando puede ser
cuantificado de manera que permita hacer uso de los siguientes métodos
de verificación: inspección, análisis, demostración o pruebas.
Los requerimientos requieren de una evaluación que permita deducir la

elaboración del sistema en función de los mismos, en función de esto cada
requerimiento puede ser clasificado como posible, deseable o innecesario, de
acuerdo con esta tipificación se considera la estrategia de incluir los posibles,
discutir o negociar los requerimientos deseados y desechar los innecesarios.
En base a la evaluación se considera las factibilidades siguientes:
Factibilidad Técnica: determina la posibilidad de implementar un

requerimiento con la tecnología que se posee actualmente.
Factibilidad operacional: establece si es posible utilizar el sistema sin

alterar el esquema organizacional de la estructura empresarial.
Factibilidad económica: estipula si el presupuesto establecido puede ser

cubierto por parte de cliente.
Se han determinado los siguientes principios para representar los requisitos de

software:
1. Separar la funcionalidad de la implementación
2. Desarrollar un modelo de comportamiento de un sistema que
comprenda los datos y las respuestas funcionales de un sistema a
varios estímulos del entorno.
3. Establecer los componentes del sistema que interactúan con él.
4. Definir el entorno en que operara el sistema.
5. Crear un modelo intuitivo.
6. Considerar que una especificación es una abstracción de una
situación real por lo cual será incompleta y existirá a muchos niveles
de detalle.
7. Definir un contenido y estructura que sea susceptible a cambios
Ilustración 2
El Analista como Negociador
El analista, por su rol característico representa un agente de cambio para la

organización para la que desempeña sus labores, esto implica promover un
cambio que involucre el uso de los sistemas de información, durante este
proceso es necesario enseñar al usuario el proceso de cambio ya que las
modificaciones a un sistema existente no solo afectan a este sino al resto de la
organización en general. Durante este rol el analista juega rol determinante a
la hora de dar una opinión especializada en el caso de que las evaluación de los
requerimientos establezca que existe que hay alguno muy costoso o fuera del
rango de posibilidades tanto de la organización, del tiempo previsto o de los
recursos tecnológicos que se posean.
El analista debe considerar la eficiencia y la eficacia durante el proceso de

desarrollo del proyecto por lo cual, él mismo debe de fungir como moderador
entre los requerimientos del usuario en función de las herramientas y recursos
con los que él cuenta, por ende surge la propuesta como pieza fundamental de
establecer un equilibrio entre la posibilidad de satisfacer la demanda del
usuario y el requerimiento como tal, para así hacerlo factible dentro de los
parámetros que rigen al analista y su grupo de trabajo.
Estas propuestas se orientan generalmente en el ahorro de tiempo, de costos,
de efectividad y/o eficiencia del proyecto a desarrollar.

Que Es RUP

Cargado por

Copyright:

Formatos disponibles

Que Es RUP

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Que Es RUP

Cargado por

Copyright:

Formatos disponibles

¿Que es RUP?

RUP (Rational Unified Process) es una secuencia de

 Disciplinas: son los 'contenedores' empleados para organizar todas las

Principalmente RUP esta compuesta por el trabajo realizado en función de dos

La segunda dimensión representa

La disciplina de Desarrollo está estructurada de la siguiente manera:

La disciplina de Soporte se estructura del modo siguiente:

 Configuración y Administración del Cambio: guarda todas las versiones

No es un secreto que la ausencia de información acerca del problema y el

En esta fase la idea fundamental es entender a ciencia cierta qué es lo que se

Se puede definir un requerimiento como un aviso, manifestación o pregunta

Los requerimientos, como se dijo anteriormente, son la base fundamental del

Los requerimientos requieren de una evaluación que permita deducir la

En base a la evaluación se considera las factibilidades siguientes:

Factibilidad Técnica: determina la posibilidad de implementar un

Factibilidad operacional: establece si es posible utilizar el sistema sin

Factibilidad económica: estipula si el presupuesto establecido puede ser

Se han determinado los siguientes principios para representar los requisitos de

El Analista como Negociador

El analista, por su rol característico representa un agente de cambio para la

El analista debe considerar la eficiencia y la eficacia durante el proceso de

También podría gustarte