Metodologia Rup

ANLISIS DE SISTEMAS II
METODOLOGIA RUP (RATIONAL UNIFIED PROCESS)

INTRODUCCIN.
En la actualidad, la utilizacin de metodologas para el desarrollo de aplicaciones es
casi imposible omitirla, debido a la gran necesidad de control de variables que conlleva
el mismo desarrollo, y para la ordenada elaboracin de las aplicaciones, por lo tanto,
seguir metodologas y estndares nos llevan a estar en competitividad en todo
momento.
Es de suma importancia conocer el modo como se interrelacionan metodologas con
estndares y herramientas siguiendo un nico propsito, el cual consiste en la
elaboracin de aplicaciones de manera eficiente, ordenada y con el menor nmero de
defectos.
La metodologa RUP nos proporciona disciplinas en las cuales se encuentran artefactos
con lo cual se podr contar con guas para poder documentar e implementar de una
manera fcil y eficiente, todas las guas para un buen desarrollo, todo esto dentro de las
respectivas fases con las cuales cuenta.
RESUMEN.
Las metodologas y estndares utilizados en un desarrollo de software nos
proporcionan las guas para poder conocer todo el camino a recorrer desde antes de
empezar la implementacin, con lo cual se asegura la calidad del producto final, as
como tambin el cumplimiento en la entrega del mismo en un tiempo estipulado.
Es de suma importancia elegir la metodologa adecuada, as como las herramientas de
implementacin adecuadas, es por ello que la metodologa RUP basada en UML nos
proporciona todas las bases para llevar al xito la elaboracin del software, para ello la
utilizacin de la herramienta RUP para el desarrollo rpido de aplicaciones.
Este trabajo consta de siete captulos, los cuales se describen a continuacin:
En el captulo uno se abarcar la explicacin de la metodologa RUP con sus bases

en el UML, las partes que la conforman, su funcionalidad; con lo cual podremos
observar la interrelacin entre ambos y la importancia de su uso en el desarrollo de
aplicaciones.
En el captulo dos se abarcar lo que son las dimensiones de RUP dentro de ello
especfica los casos de uso y el proceso modelado a una arquitectura y los
procesos iterativos.
En el captulo tres se abarca lo que son las fases y sus planeaciones los esfuerzos
a los flujos de trabajo y a los de su respecto.
En el captulo cuatro se abarca lo que son las disciplinas como modelado de
negocio, requerimientos, anlisis, etc.
En el captulo cinco se abarca a lo que son las organizaciones del RUP como
actores, artefactos y grados de artefacto.
1 - 26
En el captulo seis se trata de lo que es el Lenguaje Unificado de Modelado (UML)

que se extiende hasta los casos de uso y diagramas y ms mbito de desarrollos
de software.
Y como final el captulo siete se abarca a lo que son las metodologas de diseo y
Anlisis de software con RUP y UML.
Rational Unified Process (RUP)

Las siglas RUP en ingles significa Rational Unified Process (Proceso Unificado de
Racional) es un producto del proceso de ingeniera de software que proporciona un
enfoque disciplinado para asignar tareas y responsabilidades dentro de una
organizacin del desarrollo. Su meta es asegurar la produccin del software de alta
calidad que resuelve las necesidades de los usuarios dentro de un presupuesto y
tiempo establecidos.
Segn Jacaboson, I., Booch, G., Rumbaugh J. (1998)1 El nombre Proceso Unificado se
usa para describir el proceso genrico que incluye aquellos elementos que son
comunes a la mayora de los refinamientos existentes. Tambin permite evitar
problemas legales ya que Proceso Unificado de Rational o RUP son marcas registradas
por IBM (desde su compra de Rational Software Corporation en 2003).
Segn Grady Booch(2000)2 un reflejo de lo que hemos visto en el trabajo con
literalmente decenas de miles de proyectos en los ltimos 20 aos, la codificacin de lo
que funciona en las organizaciones exitosas y lo que est notablemente ausente en los
fallidos.
Captulo 1: Historia.
La Figura 1 ilustra la historia de RUP. El antecedente ms importante se ubica en 1967
con la Metodologa Ericsson (Ericsson Approach) elaborada por Ivar Jacobson, una
aproximacin de desarrollo basada en componentes, que introdujo el concepto de Caso
de Uso. Entre los aos de 1987 a 1995 Jacobson fund la compaa Objectory AB y
lanza el proceso de desarrollo Objectory (abreviacin de Object Factory).
Figura 1: Historia de RUP

2 - 26
Posteriormente en 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
del Enfoque Rational (Rational Approach) adoptando UML como lenguaje de modelado.
Desde ese entonces y a la cabeza de Grady Booch, Ivar Jacobson y James Rumbaugh,
Rational Software desarroll e incorpor diversos elementos para expandir RUP,
destacndose especialmente el flujo de trabajo conocido como modelado del negocio.
En junio del 1998 se lanza Rational Unified Process.
Autores
Jacaboson, I., Booch, G., Rumbaugh J., El Proceso Unificado de Desarrollo de
Software, 2000 Addison Wesley 2 Grady Booch, diseador de software, un
metodologista de software y entusiasta de diseo de patrones. Es director Cientfico de
Rational Software (ahora parte de IBM) y editor de una serie de Benjamin/Cummings.
Captulo 2: Proceso de Desarrollo, Dimensiones del RUP.
El RUP tiene dos dimensiones:
El eje horizontal representa tiempo y demuestra los aspectos del ciclo de vida del
proceso.
El eje vertical representa las disciplinas, que agrupan actividades definidas
Lgicamente por la naturaleza.
La primera dimensin representa el aspecto dinmico del proceso y se expresa en
trminos de fases, de iteraciones, y la finalizacin de las fases.
La segunda dimensin representa el aspecto esttico del proceso: cmo se describe en
trminos de componentes de proceso, las disciplinas, las actividades, los flujos de
trabajo, los artefactos, y los roles.
En la figura 2 se puede observar como vara el nfasis de cada disciplina en un cierto
plazo en el tiempo, y durante cada una de las fases. Por ejemplo, en iteraciones
tempranas, pasamos ms tiempo en requerimientos, y en las ltimas iteraciones
pasamos ms tiempo en poner en prctica la realizacin del proyecto en si.
3 - 26
Figura 2. Disciplinas, fases, iteraciones del RUP
Se puede hacer mencin de las tres caractersticas esenciales que definen al RUP:
2.1.- Caractersticas esenciales
Los autores de RUP destacan que el proceso de software propuesto por RUP tiene tres
caractersticas esenciales: est dirigido por los Casos de Uso, est centrado en la
arquitectura, y es iterativo e incremental.
2.1.1.- Proceso dirigido por Casos de Uso
Segn Kruchten, P.(2000)3, los Casos de Uso son una tcnica de captura de requisitos
que fuerza a pensar en trminos de importancia para el usuario y no slo en trminos
de funciones que seria bueno contemplar.
Se define un Caso de Uso como un fragmento de funcionalidad del sistema que
proporciona al usuario un valor aadido. Los Casos de Uso representan los requisitos
funcionales del sistema.
En RUP los Casos de Uso no son slo una herramienta para especificar los requisitos
del sistema. Tambin guan su diseo, implementacin y prueba. Los Casos de Uso
constituyen un elemento integrador y una gua del trabajo como se muestra en la Figura
3.
4 - 26
Figura 3: Los Casos de Uso integran el trabajo

Los Casos de Uso4 no slo inician el proceso de desarrollo sino que proporcionan un
hilo conductor, permitiendo establecer trazabilidad entre los artefactos que son
generados en las diferentes actividades del proceso de desarrollo. Como se muestra en
la Figura 3, basndose en los Casos de Uso se crean los modelos de anlisis y diseo,
luego la implementacin que los lleva a cabo, y se verifica que efectivamente el
producto implemente adecuadamente cada Caso de Uso. Todos los modelos deben
estar sincronizados con el modelo de Casos de Uso.
Figura 4: Trazabilidad a partir de los Casos de Uso

2.1.2- Proceso centrado en la arquitectura
La arquitectura de un sistema es la organizacin o estructura de sus partes ms
relevantes, lo que permite tener una visin comn entre todos los involucrados
(desarrolladores y usuarios) y una perspectiva clara delsistema completo, necesaria
para controlar el desarrollo [Kru00]. La arquitectura involucra los aspectos estticos y
dinmicos ms significativos del sistema, est relacionada con la toma de decisiones
que indican cmo tiene que ser construido el sistema y ayuda a determinar en qu
orden. Adems la definicin de la arquitectura debe tomar en consideracin elementos
de calidad del sistema, rendimiento, reutilizacin y capacidad de evolucin por lo que
debe ser flexible durante todo el proceso de desarrollo. La arquitectura se ve
5 - 26
influenciada por la plataforma software, sistema operativo, gestor de bases de datos,

protocolos, consideraciones de desarrollo como sistemas heredados. Muchas de estas
restricciones constituyen requisitos no funcionales del sistema.
En el caso de RUP adems de utilizar los Casos de Uso para guiar el proceso se presta
especial atencin al establecimiento temprano de una buena arquitectura que no se vea
fuertemente impactada ante cambios posteriores durante la construccin y el
mantenimiento.
Cada producto tiene tanto una funcin como una forma. La funcin corresponde a la
funcionalidad reflejada en los Casos de Uso y la forma la proporciona la arquitectura.
Existe una interaccin entre los Casos de Uso y la arquitectura, los Casos de Uso
deben encajar en la arquitectura cuando se llevan a cabo y la arquitectura debe permitir
el desarrollo de todos los Casos de Uso requeridos, actualmente y en el futuro. Esto
provoca que tanto arquitectura como Casos de Uso deban evolucionar en paralelo
durante todo el proceso de desarrollo de software.
En la Figura 5 se ilustra la evolucin de la arquitectura durante las fases de RUP. Se
tiene una arquitectura ms robusta en las fases finales del proyecto. En las fases
iniciales lo que se hace es ir consolidando la arquitectura por medio de baselines y se
va modificando dependiendo de las necesidades del proyecto.
Figura 5: Evolucin de la arquitectura del sistema

Es conveniente ver el sistema desde diferentes perspectivas para comprender mejor el
diseo por lo que la arquitectura se representa mediante varias vistas que se centran en
aspectos concretos del sistema, abstrayndose de los dems. Para RUP, todas las
vistas juntas forman el llamado modelo 4+1 de la arquitectura segn Kruchten, P.
(19986), el cual recibe este nombre porque lo forman las vistas lgica, de
implementacin, de proceso y de despliegue, ms la de Casos de Uso que es la que da
cohesin a todas.
6 - 26
Figura 6: Los modelos se completan, la arquitectura no cambia drsticamente

Al final de la fase de elaboracin se obtiene una baseline7 de la arquitectura donde
fueron seleccionados una serie de Casos de Uso arquitectnicamente relevantes
(aquellos que ayudan a mitigar los riesgos ms importantes, aquellos que son los ms
importantes para el usuario y aquellos que cubran las funcionalidades significativas)
Como se observa en la Figura 6, durante la construccin los diversos modelos van
desarrollndose hasta completarse (segn se muestra con las formas rellenas en la
esquina superior derecha). La descripcin de la arquitectura sin embargo, no debera
cambiar significativamente (abajo a la derecha) debido a que la mayor parte de la
arquitectura se decidi durante la elaboracin. Se incorporan pocos cambios a la
arquitectura (indicados con mayor densidad de puntos en la figura inferior derecha)
[JBR00].8
2.1.3.- Proceso iterativo e incremental
El equilibrio correcto entre los Casos de Uso y la arquitectura es algo muy parecido al
equilibrio de la forma y la funcin en el desarrollo del producto, lo cual se consigue con
el tiempo. Para esto, la estrategia que se propone en RUP es tener un proceso iterativo
e incremental en donde el trabajo se divide en partes ms pequeas o mini proyectos.
Permitiendo que el equilibrio entre Casos de Uso y arquitectura se vaya logrando
durante cada mini proyecto, as durante todo el proceso de desarrollo. Cada mini
proyecto se puede ver como una iteracin (un recorrido ms o menos completo a lo
largo de todos los flujos de trabajo fundamentales) del cual se obtiene un incremento
que produce un crecimiento en el producto. Una iteracin puede realizarse por medio
de una cascada como se muestra en la Figura 6. Se pasa por los flujos fundamentales
(Requisitos, Anlisis, Diseo, Implementacin y Pruebas), tambin existe una
planificacin de la iteracin, un anlisis de la iteracin y algunas actividades especficas
7 - 26
de la iteracin. Al finalizar se realiza una integracin de los resultados con lo obtenido

de las iteraciones anteriores.
Figura 7: Una iteracin RUP

El proceso iterativo e incremental consta de una secuencia de iteraciones. Cada
iteracin aborda una parte de la funcionalidad total, pasando por todos los flujos de
trabajo relevantes y refinando la arquitectura. Cada iteracin se analiza cuando termina.
Se puede determinar si han aparecido nuevos requisitos o han cambiado los existentes,
afectando a las iteraciones siguientes. Durante la planificacin de los detalles de la
siguiente iteracin, el equipo tambin examina cmo afectarn los riesgos que an
quedan al trabajo en curso. Toda la retroalimentacin de la iteracin pasada permite
reajustar los objetivos para las siguientes iteraciones. Se contina con esta dinmica
hasta que se haya finalizado por completo con la versin actual del producto.
RUP divide el proceso en cuatro fases, dentro de las cuales se realizan varias
iteraciones en nmero variable segn el proyecto y en las que se hace un mayor o
menor hincapi en los distintas actividades. En la Figura 8 se muestra cmo vara el
esfuerzo asociado a las disciplinas segn la fase en la que se encuentre el proyecto
RUP.
8 - 26
Figura 8: Ciclo de vida

Las primeras iteraciones (en las fases de Inicio y Elaboracin) se enfocan hacia la
comprensin del problema y la tecnologa, la delimitacin del mbito del proyecto, la
eliminacin de los riesgos crticos, y al establecimiento de una baseline 10de la
arquitectura.
Durante la fase de inicio las iteraciones hacen ponen mayor nfasis en actividades
modelado del negocio y de requisitos. En la fase de elaboracin, las iteraciones se
orientan al desarrollo de la baseline de la arquitectura, abarcan ms los flujos de trabajo
de requerimientos, modelo de negocios (refinamiento), anlisis, diseo y una parte de
implementacin orientado a la baseline de la arquitectura. En la fase de construccin,
se lleva a cabo la construccin del producto por medio de una serie de iteraciones.
Para cada iteracin se selecciona algunos Casos de Uso, se refina su anlisis y diseo
y se procede a su implementacin y pruebas. Se realiza una pequea cascada para
cada ciclo. Se realizan tantas iteraciones hasta que se termine la implementacin de la
nueva versin del producto.
En la fase de transicin 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 que dependiendo de la fase el esfuerzo dedicado a
una disciplina vara.
9 - 26
Figura 9. Fases del RUP

Captulo 3: Desarrollo de Etapas (Fases).
El ciclo de vida del software del RUP se descompone en cuatro fases secuenciales
(figura 9). En cada extremo de una fase se realiza una evaluacin (actividad: Revisin
del ciclo de vida de la finalizacin de fase) para determinar si los objetivos de la fase se
han cumplido. Una evaluacin satisfactoria permite que el proyecto se mueva a la
prxima fase.
3.1.- Planeando las fases
El ciclo de vida consiste en una serie de ciclos, cada uno de los cuales produce una
nueva versin del producto, cada ciclo est compuesto por fases y cada una de estas
fases est compuesta por un nmero de iteraciones, estas fases son:
3.1.1.- Concepcin, Inicio o Estudio de oportunidad
Define el mbito y objetivos del proyecto Se define la funcionalidad y capacidades del
producto.
3.1.2.- Elaboracin
Tanto la funcionalidad como el dominio del problema se estudian en profundidad Se
define una arquitectura bsica Se planifica el proyecto considerando recursos
disponibles.
3.1.3.- Construccin
El producto se desarrolla a travs de iteraciones donde cada iteracin involucra tareas
de anlisis, diseo e implementacin Las fases de estudio y anlisis slo dieron una
arquitectura bsica que es aqu refinada de manera incremental conforme se construye
(se permiten cambios en la estructura) Gran parte del trabajo es programacin y
pruebas. Se documenta tanto el sistema construido como el manejo del mismo.
Esta fase proporciona un producto construido junto con la documentacin.
3.1.4.- Transicin
10 - 26
Se libera el producto y se entrega al usuario para un uso real Se incluyen tareas de

marketing, empaquetado atractivo, instalacin, configuracin, entrenamiento, soporte,
mantenimiento, etc.
Los manuales de usuario se completan y refinan con la informacin anterior, estas
tareas se realizan tambin en iteraciones Todas las fases no son idnticas en trminos
de tiempo y esfuerzo.
Aunque esto vara considerablemente dependiendo del proyecto, un ciclo de desarrollo
inicial tpico para un proyecto de tamao mediano debe anticipar la distribucin
siguiente el esfuerzo y horario:
Tabla I. Esfuerzo-horario contra fases del RUP

Lo cual se puede representar grficamente como se muestra en la figura 10:
Figura 10. Recursos utilizados en las fases del RUP en el tiempo.

El modelo cascada segn Winston Royce(1970)13, es un secuencial modelo del desarrollo
del software (un proceso para la creacin del software) en que el desarrollo se considera como
fluyendo constantemente hacia abajo (como a cascada) con las fases de anlisis de requisitos,
diseo, puesta en prctica, prueba (validacin), integracin, y mantenimiento.
Las fases de concepcin y elaboracin seran considerablemente ms pequeas.
Algunas herramientas que pueden automatizar una cierta porcin del esfuerzo de la
fase de construccin pueden atenuar esto, haciendo que la fase de construccin sea
mucho ms pequea que las fases de concepcin y elaboracin juntas. Este es
precisamente el objetivo del trabajo. Cada paso con las cuatro fases produce una
generacin del software. A menos que el producto "muera", se desarrollar nuevamente
repitiendo la misma secuencia las fases de concepcin, elaboracin, construccin y
transicin, pero con diversos nfasis cada fase.
Estos ciclos subsecuentes se llaman los ciclos de la evolucin. Mientras que el producto
pasa durante varios ciclos, se producen las nuevas generaciones. En la figura 11 se
muestre este ciclo evolutivo.
11 - 26
Figura 11. Ciclo evolutivo en la elaboracin de software basado en el RUP

Los ciclos evolutivos pueden ser iniciados por las mejoras sugeridas por el usuario,
cambios en el contexto del usuario, cambios en la tecnologa subyacente, reaccin a la
competicin, etctera. Los ciclos evolutivos tienen tpicamente fases de concepcin y
elaboracin mucho ms cortas, puesto que la definicin y la arquitectura bsicas del
producto son determinadas por los ciclos de desarrollo anteriores. Las excepciones a
esta regla son los ciclos evolutivos en los cuales ocurre o surge un producto
significativo o una redefinicin arquitectnica.
3.1.4.1.- Esfuerzo respecto de los flujos de trabajo
En la figura 5 se muestran ciertos porcentajes, de forma vertical se muestra el esfuerzo
que se tiene que realizar por cada una de las disciplinas o flujos de trabajo14, y los dos
porcentajes que se muestran de forma horizontal son para todo el proyecto.
Explicando mas puntualmente la figura 12 se puede observar que para la obtencin de
requerimientos o requisitos en la fase de concepcin se empiezan a obtener, en la fase
de elaboracin tiene su auge y va declinando en la fase de construccin, realizar todo
esto requiere aproximadamente un 15% de esfuerzo, y as sucesivamente con las
dems disciplinas. En esta seccin y la siguiente, los porcentajes pueden variar de un
proyecto a otro.
El flujo de trabajo (workflow ) es el estudio de los aspectos operacionales de una
actividad de trabajo: cmo se estructuran las tareas, cmo se realizan, cul es su orden
correlativo, cmo se sincronizan, cmo fluye la informacin que soporta las tareas y
cmo se le hace seguimiento al cumplimiento de las tareas.
12 - 26
Figura 12. Esfuerzo respecto de los flujos de trabajo

3.1.4.2 Esfuerzo respecto de las fases.
En la figura 6 se muestran dos filas de porcentajes, el primero que es el esfuerzo
realizado por cada fase en forma general e incluyendo las iteraciones dentro de cada
fase; y en la segunda fila, la duracin que tiene aproximadamente en porcentajes del
tiempo total del proyecto para cada una de las fases incluyendo todas las iteraciones
que conlleven realizar cada fase.
Explicando ms puntualmente una pequea parte de la figura 13 se puede observar
que para la fase de construccin se tiene que dedicar ms esfuerzo y mayor duracin,
siempre y cuando dependiendo de qu disciplina estemos ejecutando, por ejemplo en
la disciplina de implementacin se tiene mucho auge en la fase de construccin.
Figura 13. Esfuerzo respecto de las fases

13 - 26
Captulo 4: Notacin de la metodologa y Disciplinas.

Las disciplinas conllevan los flujos de trabajo, los cuales son una secuencia de pasos
para la culminacin de cada disciplina, estas disciplinas se dividen en dos grupos: las
hyprimarias y las de apoyo. Las primarias son las necesarias para la realizacin de un
proyecto de software, aunque para proyectos no muy grandes se pueden omitir
algunas; entre ellas se tienen: Modelado del Negocio, Requerimientos, Anlisis y
Diseo, Implementacin, Pruebas, Despliegue. Las de apoyo son las que como su
nombre lo indica sirven de apoyo a las primarias y especifican otras caractersticas en
la realizacin de un proyecto de software; entre estas se tienen: Entorno, Gestin del
Proyecto, Gestin de Configuracin y Cambios. A continuacin se describe rpidamente
cada una de estas disciplinas.
4.1.- Modelado del negocio.
Esta disciplina tiene como objetivos comprender la estructura y la dinmica de la
organizacin, comprender problemas actuales e identificar posibles mejoras,
comprender los procesos de negocio. Utiliza el Modelo de CU del Negocio para
describir los procesos del negocio y los clientes, el Modelo de Objetos del Negocio para
describir cada CU del Negocio con los Trabajadores, adems utilizan los Diagramas de
Actividad y de Clases.
4.2.- Requerimientos.
Esta disciplina tiene como objetivos establecer lo que el sistema debe hacer
(Especificar Requisitos), definir los lmites del sistema, y una interfaz de usuario,
realizar una estimacin del costo y tiempo de desarrollo. Utiliza el Modelo de CU para
modelar el Sistema que comprenden los CU, Actores y Relaciones, adems utiliza los
diagramas de Estados de cada CU y las especificaciones suplementarias.
4.3.- Anlisis y diseo.
Esta disciplina define la arquitectura del sistema y tiene como objetivos trasladar
requisitos en especificaciones de implementacin, al decir anlisis se refiere a
transformar CU en clases, y al decir diseo se refiere a refinar el anlisis para poder
implementar los diagramas de clases de anlisis de cada CU, los diagramas de
colaboracin de de cada CU, el de clases de diseo de cada CU, el de secuencia de
diseo de CU, el de estados de las clases, el modelo de despliegue de la arquitectura.
4.4.- Implementacin.
Esta disciplina tiene como objetivos implementar las clases de diseo como
componentes (ej. fichero fuente), asignar los componentes a los nodos, probar los
componentes individualmente, integrar los componentes en un sistema ejecutable
(enfoque incremental). Utiliza el Modelo de Implementacin, conjuntamente los
Diagramas de Componentes para comprender cmo se organizan los Componentes y
dependen unos de otros.
14 - 26
4.5.- Pruebas.
Esta disciplina tiene como objetivos verificar la integracin de los componentes (prueba
de integracin), verificar que todos los requisitos han sido implementados (pruebas del
sistema), asegurar que los defectos detectados han sido resueltos antes de la
distribucin
4.6.- Despliegue.
Esta disciplina tiene como objetivos asegurar que el producto est preparado para el
cliente, proceder a su entrega y recepcin por el cliente. En esta disciplina se realizan
las actividades de probar el software en su entorno final (Prueba Beta), empaquetarlo,
distribuirlo e instalarlo, as como la tarea de ensear al usuario.
4.7.- Gestin y configuracin de cambios.
Es esencial para controlar el nmero de artefactos producidos por la cantidad de
personal que trabajan en un proyecto conjuntamente. Los controles sobre los cambios
son de mucha ayuda ya que evitan confusiones costosas como la compostura de algo
que ya se haba arreglado etc., y aseguran que los resultados de los artefactos no
entren en conflicto con algunos de los siguientes tipos de problemas:
Actualizacin simultnea: Es la actualizacin de algo elaborado con anterioridad, sin
saber que alguien ms lo est actualizando.
Notificacin limitada: Al realizar alguna modificacin, no se deja informacin sobre lo
que se hizo, por lo tanto no se sabe quin, como, y cuando se hizo.
Versiones mltiples: No saber con exactitud, cual es la ltima versin, y al final no se
tiene un orden sobre que modificaciones se han realizado a las diversas versiones.
4.8.- Gestin del proyecto.
La gestin de proyecto su objetivo es equilibrar los objetivos competitivos, administrar el
riesgo, y superar restricciones para entregar un producto que satisface las necesidades
e ambos clientes con xito (los que pagan el dinero) y los usuarios. Con la Gestin del
Proyecto se logra una mejora en el manejo de una entrega exitoso de software. En
resumen su propsito consiste en proveer pautas para:
- Administrar proyectos de software intensivos.
- Planear, dirigir personal, ejecutar acciones y supervisar proyectos.
- Administrar el riesgo.
Sin embargo, esta disciplina no intenta cubrir todos los aspectos de direccin del
proyecto. Por ejemplo, no cubre problemas como:
Administracin de personal: contratando, entrenando, enseando.
Administracin del presupuesto: definiendo, asignando.
Administracin de los contratos con proveedores y clientes.
15 - 26
4.9.- Entorno.
Esta disciplina 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.
Su propsito es proveer a la organizacin que desarrollar el software, un ambiente en
el cual basarse, el cual provee procesos y herramientas para poder desarrollar el
software.
Captulo 5: Ejemplo desarrollado.
Plan de Desarrollo de Software
1.
Introduccin
A continuacin se presenta un plan inicial de desarrollo del sistema Repositorio de
Sistemas, el cual consiste en un proyecto de gestin de sistemas para cualquier
empresa de tamao considerable, que requiera un manejo automatizado de la
informacin de los sistemas utilizados.
El proyecto nace como necesidad de muchos gerentes de empresas grandes de
mantener un Repositorio de sus sistemas, para as mantener un control de la
informacin manejada en la empresa tanto a nivel de la central como en las
distintas oficinas. La central se refiere a la sede principal de la empresa, las
oficinas son centrales que de forma autnoma manejan la informacin
correspondiente a cada pas o regin.
De acuerdo a las caractersticas del proyecto se tom como enfoque de desarrollo
una configuracin del proceso RUP, seleccionando los roles de los participantes, las
actividades a realizar y los artefactos (entregables) que sern generados. Este
documento es a su vez uno de los artefactos de RUP.
1.1
Propsito
El propsito del Plan de Desarrollo de Software es proporcionar la informacin
necesaria para llevar el control del proyecto. Se describe la organizacin del
proyecto y la forma en cmo debe ser llevado o elaborado por los usuarios
desarrolladores del sistema. Tambin sirve como base para llevar a cabo un anlisis
ms detallado del mismo.
En cuanto a cules son los usuarios del Plan de Desarrollo del Software tenemos:
El representante del proyecto: hace uso de este documento para

organizar y designar las tareas del equipo de trabajo, para ver necesidades de
recursos y para realizar su seguimiento.
Los miembros del equipo lo usan para entender qu es lo que deben

hacer, cules tcnicas aplicar, en cul momento se debe hacer y qu otras
actividades dependen de ello.
16 - 26
1.2
Alcance
El Plan de Desarrollo del Software consiste en describir el plan global usado para
el desarrollo del Sistema de Repositorio de Sistemas, el cual pretende gestionar
los diferentes sistemas presentes en una organizacin. Adicionalmente, se
requiere realizar el detalle de las iteraciones individuales, esto se describe en los
planes de cada iteracin, documentos que se aportan en forma separada. Se
necesita del documento Visin durante el proceso de desarrollo, ya que en ese
artefacto se definen las caractersticas del producto a desarrollar, lo cual
constituye la base para la planificacin de las iteraciones. Para esta versin 1.0 del
Plan de Desarrollo del Software, se ha realizado una estimacin aproximada en
base a los requerimientos iniciales del sistema. Para producir nuevas versiones
actualizadas y mejoradas de este documento, se tiene que realizar un seguimiento
en cada una de las iteraciones y de esta manera realizar los ajustes necesarios.
1.3
Definiciones, Acrnimos y Abreviaciones

RS: Repositorio de Sistemas
RUP: Rational Unified Process
1.4
Referencias
Este documento hace referencia a los documentos Visin y Arquitectura del
Software.
1.5
Vista Global
El Plan de Desarrollo contempla las 4 secciones siguientes:
2.
2.1
Vista General del Proyecto: proporciona informacin acerca del

propsito, el alcance y los objetivos del proyecto; las suposiciones y las
restricciones consideradas para el sistema; y por ltimo la evolucin de este
plan a medida que se comienza una nueva iteracin.
Organizacin del Proyecto: describe los roles correspondientes a los

integrantes del equipo de desarrollo, as como las fases en las cuales se divide
el proceso de desarrollo del sistema.
Gestin del Proceso: estima el costo y la planificacin aproximada del

proyecto, define las fases e hitos del proyecto y describe cmo se realizar su
seguimiento.
Vista General del Proyecto
Propsito, Alcance y Objetivos

En una organizacin (por ejemplo: una empresa por departamentos transnacional),
muchas veces es desconocida la cantidad de sistemas internos, ms an es difcil
llevar un monitoreo de cada sistema para llevar un mantenimiento de las
funcionalidades de cada uno de ellos. El propsito principal de este proyecto es
hacer cumplir esos objetivos. Se quiere tener un sistema de control que monitoree y
mantenga informacin detalladas sobre los sistemas de una organizacin.
Actualmente, no se cuenta con un sistema que proporcione tal informacin, es por
ello que nace la necesidad de tener un sistema automatizado para tal fin. Al ser el
primer sistema de este tipo, no se cuenta con precedentes o versiones pasadas de
un sistema anterior, por lo tanto ser desarrollado en su totalidad desde cero.
17 - 26
2.2
1.
Suposiciones y Restricciones
Se asume que el usuario final, en este caso el gerente general de la
empresa, encargada del monitoreo general de los sistemas de la organizacin,
cuenta con los recursos necesarios para el efectivo funcionamiento del sistema,
esto abarca tanto los aspectos relacionados con el hardware como los de software.
2.
Queda a disposicin de los desarrolladores utilizar el lenguaje de
programacin ms conveniente, por lo cual hasta el momento la opcin ms
aceptada sera utilizar un framework de PHP llamado PHPCake.
3.
En cuanto a la informacin manejada, esta debe mantenerse con cierto
grado de confidenciabilidad, flexibilidad, usabilidad y seguridad.
2.3
Evolucin del Plan de Desarrollo del Software.

El Plan de Desarrollo del Software se revisar peridicamente y se refinar antes
del comienzo de cada iteracin.
3. ORGANIZACIN DEL PROYECTO.

Se pretende adaptar el modelo bajo el que se desarrollara el software al proceso
definido por RUP. En vista de que todas las etapas del proyecto se no se adaptan
perfectamente al modelo definido por RUP, se toman solo aquellos aspectos
aplicables del proyecto y se realizan las modificaciones necesarias en los dems
casos. Se debe considerar las posteriores modificaciones al presente plan de
desarrollo.
3.1 Modelo De Proceso.
El proceso de desarrollo del sistema se dividir en cuatro fases:
1. Investigacin: Esta fase implica un estudio profundo de tcnicas, herramientas
y avances en el rea de investigacin, para generar un documento de contexto de
trabajo donde se resuma la informacin recavada.
2. Inicio: Una vez generada la documentacin de contexto de trabajo, al finalizar
la fase de investigacin, el grupo cuenta con la informacin necesaria para analizar
el problema y proponer una solucin al mismo. Esto se realiza en la fase de inicio.
Luego de planteada una solucin al problema, se comienza a detallar tcnicamente
la implementacin de la solucin propuesta.
3. Elaboracin: Es en la fase de elaboracin donde se realiza el diseo del
sistema, lo cual implica definicin de la arquitectura del mismo. Esta fase se da por
culminada cuando dicha arquitectura sea estable.
4. Construccin: Demostrada la estabilidad de la arquitectura adoptada se
comienza a implementar el sistema final. La fase de construccin implica una fuerte
carga horaria de implementacin. A fines de esta fase se comienzan las sesiones
de prueba de la solucin implementada.
18 - 26
3.2 Planificacin De Fases De La Metodologa RUP.

3.2.1. Inicio.
Los objetivos de esta fase son:
Establecer los lmites y alcance del proyecto

Definir casos de uso
Estimar potenciales riesgos
Determinar la factibilidad del proyecto
Definir plan de desarrollo de software
Desarrollar un prototipo inicial no funcional
3.2.2. Elaboracin.
Los objetivos de esta fase son:
Definir la arquitectura del sistema y vistas de casos de uso

Resolver los principales riesgos de la arquitectura
Definir vistas restantes y refinar vistas de casos de uso
Implementar los casos de uso crticos
3.2.3. Construccin.
Los objetivos de la fase son:
3.3
Refinar las vistas de la fase anterior

Implementar las funcionalidades del sistema
Desarrollo iterativo incremental del producto completo
Realizacin de pruebas
Correccin y ajuste de errores
Estructura Organizacional
El equipo consta de nueve integrantes. La estructura organizacional del grupo ha
sido definida como horizontal, debido a las caractersticas del mismo. Cada
integrante esta en capacidad de realizar cualquier actividad referente al proceso
de desarrollo del proyecto. Es necesaria la colaboracin entre miembros y
conocimiento de todas las reas para poder llevar a cabo todas las etapas del
proceso. Sin embargo, es importante llevar a cabo una divisin de tareas con el
fin de incrementar la eficiencia de trabajo, donde sin embargo cualquier
integrante deber estar en la capacidad de suplantar a otro, si as fuese
requerido.
3.3.1 Interfaces Externas.

La profesora Marlene Goncalves se encargar de evaluar el avance del proyecto
basndose en el calendario y el plan de desarrollo.
19 - 26
3.3.2
Roles y Responsabilidades
Los roles y responsabilidades sern rotadas en el transcurso del desarrollo, cada
integrante del grupo deber estar involucrado en todas las reas del proceso de
desarrollo y el nivel de responsabilidad es el mismo para todos.
4.
4.1
Gestin del Proceso

Estimaciones del Proyecto
Al ser un proyecto de carcter acadmico, se deja de lado el aspecto econmico
ya que no se cuenta con un presupuesto ni costos asociados al desarrollo, ya
que su valor se representa en el aporte tecnolgico para la Universidad Simn
Bolvar.
4.2
Plan del Proyecto

Para el desarrollo satisfactorio del sistema fue necesario dividirlo en varias fases,
basadas en la metodologa RUP, cada una estas fases podr contener una o mas
iteraciones obteniendo en cada iteracin un hito especifico.
La descripcin detallada de cada una de las fases y sus iteraciones que
conforman el proceso de desarrollo del sistema se encuentran a continuacin
4.2.1 Plan de las Fases

Fase
Nro.
Iteraciones
Duracin
Fase de Inicio
4 semanas
Fase de Elaboracin
6 semanas
Fase de Construccin
12 semanas
4.2.2 Objetivos de las Fases

Fase
Descripcin
Fase de Inicio
Durante esta fase, se desarrolla una descripcin del producto

final a partir de una buena idea y se presenta el anlisis de
negocio para el producto. En su nica iteracin se especifica
las funcionalidades que debe poseer el sistema y su alcance.
Adems se lleva a cabo un estudio detallado de todo lo que es
el negocio al cual se le est creando el sistema, para as
determinar cules son las necesidades a ser satisfechas con
mayor prioridad, esto se define en el artefacto Visin. Se
definen los casos de uso, como una representacin de las
funcionalidades del sistema y de la interaccin con el usuario.
20 - 26
Se establece el Plan de Desarrollo, donde se describe de forma

detallada las actividades que se llevarn a cabo para crear el
sistema. El final de la fase esta marcado con la aceptacin por
parte del cliente del artefacto Visin y el Plan de Desarrollo.
Fase de
Elaboracin
Se obtiene un entendimiento ms detallado de los

requerimientos, se procede a disear, implementar, validar y
generar una lnea base para la arquitectura. Se definen los
subsistemas, los componentes clave y sus interfaces; se usan
los casos de uso significantes arquitectnicamente para dirigir la
arquitectura. Se consolidan y empaquetan las clases
identificadas. Se disea la Base de datos. Se implementan y
prueban los escenarios crticos. Se debe mitigar los riesgos
esenciales y producir un plan de desarrollo ms preciso. Se
elabora el artefacto de arquitectura el cual contempla todo el
diseo de la arquitectura. La culminacin de esta fase viene
dada por el documento arquitectura y el prototipo
implementado.
Fase de
Construccin
Durante la fase de construccin se terminan de analizar y

disear todos los casos de uso, refinando el Modelo de
Anlisis / Diseo, para el plan inicial no se ha determinado la
cantidad de iteraciones a realizar. Se elaboran varios prototipos
que constituyen versiones iniciales que muestran parcialmente
el funcionamiento de ciertas caractersticas del sistema, las
cuales son probadas hasta ser validadas por el cliente. El fin de
esta fase viene dado por la versin final del sistema, la cual
incluye toda la funcionalidad del producto.
4.2.3 Calendario del Proyecto

A continuacin se presenta un calendario de las principales tareas del proyecto
incluyendo slo la fase de Inicio. Ya que debido al proceso iterativo e incremental
de RUP se realizan en paralelo de todas las disciplinas de desarrollo a lo largo
del proyecto, con lo cual la mayora de los artefactos son generados muy
tempranamente en el proyecto pero van desarrollndose en mayor o menor
grado de acuerdo a la fase e iteracin del proyecto. Se incluyen los artefactos a
entregar en cada fase. La fecha de aprobacin indica cundo el artefacto en
cuestin tiene un estado de completitud suficiente para someterse a revisin y
aprobacin, pero esto no quita la posibilidad de su posterior refinamiento y
cambios.
21 - 26
Fase de Inicio
Duracin: 4 semanas.
Actividad
Levantamiento de Informacin
Detalles del proyecto
Elaboracin de pgina Web con
artefactos
Plan de Iteracin de la fase de
elaboracin
Creacin del Plan inicial de
Desarrollo del proyecto
Creacin de documento Visin
del sistema
Refinacin del documento Visin
del sistema
Modelos de Casos de Uso del
Negocio
Lista inicial de Requerimientos
Especificacin de requerimientos
funcionales y no funcionales
Lista inicial de riesgos asociados
Glosario inicial del proyecto
Prototipo de estructura del
sistema
Elaboracin del documento de
arquitectura inicial.
Semana
Comienzo
-Semana
Entrega
1-3 (Finalizado)
1-3 (Finalizado)
3-4 (Finalizado)
4-5 (Finalizado)
Criterio de culminacin
Esta
fase
culminar
cuando se tengan al
menos 90% de las
actividades
aqu
mencionadas.
2-4 (Finalizado)
3-4 (Finalizado)
4-5 (Finalizado)
4-5 (Finalizado)
3-5 (Finalizado)
5-6 (Finalizado)
4-6 (Finalizado)
5-6 (Finalizado)
4-5 (Finalizado)
4-5 (Finalizado)
Fase de Elaboracin
Duracin: 6 semanas.
Actividad
Refinacin y diagramas de los

Casos de Uso del sistema
Vista de Datos: Creacin de
Modelo Entidad Relacin (ER)
Vista Lgica: Modelo de
Anlisis
Semana
Comienzo
-Semana
Entrega
6-7
(Finalizado
)
7-8
(Finalizado
)
7-8
(Finalizado
)
22 - 26
Iteraci
n
1
1
1.
2.
3.
4.
5.
6.
Casos
de
Usos
Implementados y Criterio
de culminacin de la
iteracin
Casos de Uso:
Ingresar Sistema
Solicitar Asociacin
Listar Asociaciones
pendientes
Aceptar asociacin
Rechazar
asociacin
Ver Asociacin
Diagrama de Clases
Diagrama de Secuencia
Establecer casos de uso
crticos del sistema.
Refinacin del documento de
Arquitectura del Software
Refinacin del prototipo con
los casos de uso crticos del
sistema
Plan de la segunda Iteracin
de la fase de elaboracin
Refinacin de diagramas y de
los casos de uso
Refinacin y actualizacin del
plan de proyecto
8-9
(Finalizado
)
8-9
(Finalizado
)
7-7
(Finalizado
)
8-9
(Finalizado
)
10-12
(Finalizado
)
8-9
(Eliminado)
9-12
(Finalizado
)
11-12
(Finalizado
)
1
1
1
1
1
1
1
7.
Ver Grados de
Asociacin
8.
Consultar
Asociacin
9.
Listar Sistemas
10.
Ver Sistema
11.
Consultar
estadsticas generales
12.
Modificar Sistema
Esta iteracin culminar
cuando:
-Se tengan completos los
modelos de casos de uso,
con
sus
respectivos
diagramas de secuencia.
-Se haya especificado una
arquitectura del software
en al menos un 80%
Fase de Construccin
Duracin: 12 semanas.
Actividad
Plan de la primera
Iteracin de la fase de
construccin
Refinamiento de los
diagramas y la base
de datos
Semana
Comienzo
-Semana
Entrega
1-2
Iteraci
n
Casos de Usos Implementados

y Criterio de culminacin de la
iteracin
1
Casos de Uso:
1-2
Desarrollo del Sistema
1-6
Manual del Usuario
5-6
Ajustes al Sistema
Pruebas
Plan de la segunda
Iteracin de la fase de
construccin
Refinamiento de los
diagramas y la base
de datos
Pruebas
7-7
1-7
6-7
1
1
1
7-8
1. Finalizacin
del
sistemas.
2. Refinacin
del
asociaciones.
3. Mdulo de errores.
mdulo
mdulo
- Base de datos en un 100%

- Sistema desarrollado en un 80%.
- Manual completado en un 80%.
Casos de Uso:
8-12
2
23 - 26
1.
Manejo
de
la
Desarrollo del Sistema

Culminacin del
manual de usuario
Correccin de errores
4.3
6-11
10-11
2
2
8-11
seguridad
2.
Refinacin
mdulo de errores.
3.
Grficos
asociaciones
Se han realizado todas las
pruebas para asegurar que el
sistema est libre de errores.
Seguimiento y Control del Proyecto.
4.4.1 Plan de Manejo de Requerimientos.

En el documento Visin se encuentran de manera detallada los requerimientos
funcionales y no funcionales del sistema. Se establecern en la fase inicial y
sern revisados durante la fase de elaboracin y construccin. En caso de que
surjan nuevos requerimientos durante estas fases habr que discutir sobre su
factibilidad y los riesgos que implicara incluirlos en el desarrollo.
4.3.1
Plan de Control de Plazos.

Con el objetivo de llevar un control sobre el desarrollo del sistema est
establecido un Plan de Proyecto, en el cual se establece un cronograma de
actividades semanales que deben ser realizadas por el equipo de
desarrolladores a lo largo de cada una de las cuatro fases y por cada iteracin.
4.3.2
Plan de Control de Presupuesto

Debido a que el proyecto es de carcter acadmico no supone la elaboracin y
mantenimiento de un presupuesto.
4.3.3
Plan de Control de Calidad.

Para establecer puntos de control sobre el sistema, se realizarn pruebas sobre
los prototipos entregados pertenecientes a cada una de las fases. En base a la
metodologa RUP se aplican las siguientes pruebas para asegurar la calidad del
sistema detectando errores a tiempo:
-. Prueba de Funcionalidad: Certifica que el funcionamiento es acorde con las
funcionalidades reflejadas en los casos de uso, esta prueba incluye la prueba
de seguridad funcional en la cual se certifica que las funciones y datos del
sistema sean accesibles por los actores autorizados.
-. Prueba de Robustez: Certifica la capacidad de resistencia a fallar que tiene el
sistema, probando casos en que el sistema podra fallar, como lo son los
casos borde.
-. Prueba de Volumen Funcional: Certifica si el sistema esta en la capacidad de
manejar altos volmenes de datos sin afectar su rendimiento.
-. Prueba de Concurrencia: Certifica la capacidad del sistema de atender
mltiples solicitudes de parte de los actores que acceden a un mismo recurso.
24 - 26
-. Prueba de Instalacin: En la ultima fase certifica que el sistema esta operativo

y listo para funcionar.
4.3.4
Plan de Reportes.
Esta prevista la entrega de un reporte de status semanalmente, el cual se
contrasta con el plan de desarrollo, adems de los artefactos correspondientes y
estipulados dentro de este plan.
4.4
Plan de Manejo de Riesgos

Para el manejo de riesgos se aplica el modelo CMMI, llamada Gestin de riesgos
(RSKM), su objetivo es de identificar problemas potenciales antes de que ellos
ocurran de modo que actividades que manejan riesgo puedan ser planificadas e
invocadas como sea necesario a travs de la vida del producto y el mitigar
impactos adversos en el alcanzar objetivos. En la primera fase de determinan los
riesgos iniciales y se define su alcance y se establece una estrategia para
mitigarlos. Luego de identificados se evalan, categorizar y se determina su
importancia para el desarrollo del proyecto. Por ltimo se procede a desarrollar el
plan para mitigar los riesgos, el manejo de riesgos es una actividad presente a lo
largo del desarrollo.
4.5
Plan de Culminacin
Para que el desarrollo del sistema culmine de manera exitosa es necesario el
seguimiento constante del plan de desarrollo mediante los reporte de status
semanal, para establecer el avance del proyecto. Es importante tomar en cuenta
los riesgos asociados al proyecto a lo largo de su desarrollo para mitigarlos a
tiempo y as evitar cualquier situacin que ponga en peligro su culminacin. Para
lograr un sistema perdurable y evolutivo, se proporciona la documentacin de
todo el proceso en sus diferentes fases para que de esta manera un equipo de
desarrolladores distinto pueda realizar el mantenimiento y futuras mejoras al
sistema.
CONCLUSIONES.
1. La elaboracin de distintos diagramas y artefactos siguiendo la metodologa RUP
proveen una fcil ejecucin del proceso de elaboracin de un Sistema de Software,
ya que describen cmo est estructurado el sistema desde diferentes perspectivas
orientadas a los diferentes involucrados en un proyecto.
2. Se puede reducir el tiempo de desarrollo de un Sistema de Software, aplicando la
metodologa RUP y UML ya que permite lograr de una manera fiable y rpida el
desarrollo del Sistema deseado.
3. Colocando componentes en los distintos servidores que conformen el sistema a
desarrollar, se cuenta de una manera automtica con todos los servicios prestados
por dichos componentes, es decir, se ponen a disposicin de los desarrollador es un
gran nmero de herramientas que se pueden aprovechar en la realizacin del
Sistema de Software de una manera mucho ms eficaz.
25 - 26
4. El tener todo el procedimiento de desarrollo de un Sistema de Software, es una

herramienta necesaria y efectiva para administrarlo; y as contar con una visin
unificada de todo el proceso, con lo que se facilita la implementacin del mismo.
RECOMENDACIONES.
1. la metodologa RUP cuenta con un enfoque disciplinado en la asignacin de tareas y
responsabilidades dentro de una organizacin del desarrollo, con la cual se puede
mantener una fcil administracin de este proceso.
2. Para obtener un mximo control de variables que conlleva un desarrollo de
aplicaciones y poder mantener una ordenada implementacin de stas, es
importante seguir metodologas y estndares que nos lleven a estar en
competitividad en todo momento.
3. Al implementar un Desarrollo Rpido de Aplicaciones de un Sistema particular, es
importante la utilizacin de Patrones, los cuales ya tienen una funcionalidad general y
han sido predefinidos, y as contar con una base consistente y previamente
elaborada para la implementacin del Software.
BIBLIOGRAFIA.
1. Grupo Isaias Carrillos Perez. (2008) Metodologa del desarrollo de software.New
York: Editorial Edit and write.
2. IBM, Rational Software. (2003). Rational Rapid Developer, Technical Overview.
EE.UU: IBM publications, World Wide Web.
3. ITSA (2008). Metodologas De Desarrollo De Software Canada: Editorial Canada
Pen.
4. Jacaboson, I., Booch, G., Rumbaugh J. (2000) Proceso Unificado de Desarrollo de
Software. New York: Editorial Mc Graw Hill.
5. Kruchten, P. (1995). Architectural Blueprintsthe 4+1 View Model of Software
Architecture. IEEE Software.
6. Marcos, E. (2005). Investigacin en Ingeniera del Software vs. Desarrollo
Software, Grupo KYBELE, Universidad Rey Juan Carlos.
7. Morgan, Stanley (2001). Sr. Business Analyst. New York: Editorial Pretince Hall.
8. Pressman, Roger. (2003) Ingenieria de Software 6ta edic. New York: Editorial Mc
Graw Hill.
9. RUP/Easy. (2004). GUA METODOLGICA DE DESARROLLO DE SISTEMAS
10. Schmuller, Joseph. (2000) Aprendiendo UML en 24 horas. Mxico: Editorial Prentice
all.
11. Sommerville, I. (2005) Ingeniera del software, 7 edicin, Pearson-Addison.
Espaa: Editorial Wesley.
12. Wasserfallmodell, Entstehungskontext, Markus Rerych, und Wirkungsforschung,
(2007). TU-Wien de Gestaltungs- del fr de Institut. Tenido acceso en lnea 28 de
noviembre.
26 - 26

Metodologia Rup

Cargado por

Información del documento

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

Metodologia Rup

Cargado por

Copyright:

Formatos disponibles

ANLISIS DE SISTEMAS II

METODOLOGIA RUP (RATIONAL UNIFIED PROCESS)

En el captulo uno se abarcar la explicacin de la metodologa RUP con sus bases

En el captulo seis se trata de lo que es el Lenguaje Unificado de Modelado (UML)

Rational Unified Process (RUP)

Figura 1: Historia de RUP

Posteriormente en 1995 Rational Software Corporation adquiere Objectory AB y entre

Figura 2. Disciplinas, fases, iteraciones del RUP

Figura 3: Los Casos de Uso integran el trabajo

Figura 4: Trazabilidad a partir de los Casos de Uso

influenciada por la plataforma software, sistema operativo, gestor de bases de datos,

Figura 5: Evolucin de la arquitectura del sistema

Figura 6: Los modelos se completan, la arquitectura no cambia drsticamente

de la iteracin. Al finalizar se realiza una integracin de los resultados con lo obtenido

Figura 7: Una iteracin RUP

Figura 8: Ciclo de vida

Figura 9. Fases del RUP

Se libera el producto y se entrega al usuario para un uso real Se incluyen tareas de

Tabla I. Esfuerzo-horario contra fases del RUP

Figura 10. Recursos utilizados en las fases del RUP en el tiempo.

Figura 11. Ciclo evolutivo en la elaboracin de software basado en el RUP

Figura 12. Esfuerzo respecto de los flujos de trabajo

Figura 13. Esfuerzo respecto de las fases

Captulo 4: Notacin de la metodologa y Disciplinas.

El representante del proyecto: hace uso de este documento para

Los miembros del equipo lo usan para entender qu es lo que deben

Definiciones, Acrnimos y Abreviaciones

Vista General del Proyecto: proporciona informacin acerca del

Organizacin del Proyecto: describe los roles correspondientes a los

Gestin del Proceso: estima el costo y la planificacin aproximada del

Propsito, Alcance y Objetivos

Evolucin del Plan de Desarrollo del Software.

3. ORGANIZACIN DEL PROYECTO.

3.2 Planificacin De Fases De La Metodologa RUP.

Establecer los lmites y alcance del proyecto

Definir la arquitectura del sistema y vistas de casos de uso

Refinar las vistas de la fase anterior

3.3.1 Interfaces Externas.

Gestin del Proceso

Plan del Proyecto

4.2.1 Plan de las Fases

4.2.2 Objetivos de las Fases

Durante esta fase, se desarrolla una descripcin del producto

Se establece el Plan de Desarrollo, donde se describe de forma

Se obtiene un entendimiento ms detallado de los

Durante la fase de construccin se terminan de analizar y

4.2.3 Calendario del Proyecto

Refinacin y diagramas de los

Casos de Usos Implementados

Desarrollo del Sistema

Manual del Usuario

- Base de datos en un 100%

Desarrollo del Sistema

Seguimiento y Control del Proyecto.

4.4.1 Plan de Manejo de Requerimientos.

Plan de Control de Plazos.

Plan de Control de Presupuesto

Plan de Control de Calidad.

-. Prueba de Instalacin: En la ultima fase certifica que el sistema esta operativo

Plan de Manejo de Riesgos

4. El tener todo el procedimiento de desarrollo de un Sistema de Software, es una

También podría gustarte