Metodologia rup

ANÁLISIS DE SISTEMAS II

METODOLOGIA RUP (RATIONAL UNIFIED PROCESS)
INTRODUCCIÓN.

En la actualidad, la utilización de metodologías 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 elaboración de las aplicaciones, por lo tanto,
seguir metodologías y estándares nos llevan a estar en competitividad en todo
momento.

Es de suma importancia conocer el modo como se interrelacionan metodologías con
estándares y herramientas siguiendo un único propósito, el cual consiste en la
elaboración de aplicaciones de manera eficiente, ordenada y con el menor número de
defectos.

La metodología RUP nos proporciona disciplinas en las cuales se encuentran artefactos
con lo cual se podrá contar con guías para poder documentar e implementar de una
manera fácil y eficiente, todas las guías para un buen desarrollo, todo esto dentro de las
respectivas fases con las cuales cuenta.

RESUMEN.

Las metodologías y estándares utilizados en un desarrollo de software nos
proporcionan las guías para poder conocer todo el camino a recorrer desde antes de
empezar la implementación, con lo cual se asegura la calidad del producto final, así
como también el cumplimiento en la entrega del mismo en un tiempo estipulado.

Es de suma importancia elegir la metodología adecuada, así como las herramientas de
implementación adecuadas, es por ello que la metodología RUP basada en UML nos
proporciona todas las bases para llevar al éxito la elaboración del software, para ello la
utilización de la herramienta RUP para el desarrollo rápido de aplicaciones.

Este trabajo consta de siete capítulos, los cuales se describen a continuación:

En el capítulo uno se abarcará la explicación de la metodología RUP con sus bases
en el UML, las partes que la conforman, su funcionalidad; con lo cual podremos
observar la interrelación entre ambos y la importancia de su uso en el desarrollo de
aplicaciones.
En el capítulo dos se abarcará lo que son las dimensiones de RUP dentro de ello
específica los casos de uso y el proceso modelado a una arquitectura y los
procesos iterativos.
En el capítulo 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 capítulo cuatro se abarca lo que son las disciplinas como modelado de
negocio, requerimientos, análisis, etc.
En el capítulo cinco se abarca a lo que son las organizaciones del RUP como
actores, artefactos y grados de artefacto.
En el capítulo seis se trata de lo que es el Lenguaje Unificado de Modelado (UML)
que se extiende hasta los casos de uso y diagramas y más ámbito de desarrollos de
software.
1 - 25


Y como final el capítulo siete se abarca a lo que son las metodologías de diseño y
Análisis de software con RUP y UML.

RationalUnifiedProcess (RUP)

Las siglas RUP en ingles significa RationalUnifiedProcess (Proceso Unificado de
Racional) es un producto del proceso de ingeniería de software que proporciona un
enfoque disciplinado para asignar tareas y responsabilidades dentro de una
organización del desarrollo. Su meta es asegurar la producción del software de alta
calidad que resuelve las necesidades de los usuarios dentro de un presupuesto y
tiempo establecidos.

Según Jacaboson, I., Booch, G., Rumbaugh J. (1998)1 El nombre Proceso Unificado se
usa para describir el proceso genérico que incluye aquellos elementos que son
comunes a la mayoría de los refinamientos existentes. También 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).

Según 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 años, la codificación de lo
que funciona en las organizaciones exitosas y lo que está notablemente ausente en los
fallidos.

Capítulo 1: Historia.

La Figura 1 ilustra la historia de RUP. El antecedente más importante se ubica en 1967
con la Metodología Ericsson (Ericsson Approach) elaborada por Ivar Jacobson,
unaaproximación de desarrollo basada en componentes, que introdujo el concepto
deCaso de Uso. Entre los años de 1987 a 1995 Jacobson fundó la compañía
ObjectoryAB y lanza el proceso de desarrollo Objectory (abreviación de Object Factory).

Figura 1: Historia de RUP

Posteriormente en 1995 Rational Software Corporation adquiere Objectory AB y
entre1995 y 1997 se desarrolla RationalObjectoryProcess (ROP) a partir de Objectory
3.8 y
del Enfoque Rational (RationalApproach) adoptando UML como lenguaje de modelado.
2 - 25

Desde ese entonces y a la cabeza de Grady Booch, Ivar Jacobson y JamesRumbaugh,
Rational Software desarrolló e incorporó diversos elementos para expandirRUP,
destacándose especialmente el flujo de trabajo conocido como modelado delnegocio.
En junio del 1998 se lanza RationalUnifiedProcess.

Autores

Jacaboson, I., Booch, G., Rumbaugh J., El Proceso Unificado de Desarrollo de
Software, 2000 Addison Wesley2 Grady Booch, diseñador de software, un
metodologista de software y entusiasta de diseño de patrones. Es directorCientífico de
Rational Software (ahora parte de IBM) y editor de una serie de Benjamin/Cummings.

Capítulo 2: Proceso de Desarrollo, Dimensiones del RUP.

El RUP tiene dos dimensiones:

El eje horizontal representa tiempo y demuestra los aspectos del ciclo de vidadel
proceso.

El eje vertical representa las disciplinas, que agrupan actividades definidas
Lógicamente por la naturaleza.

La primera dimensión representa el aspecto dinámico del proceso y se expresa
entérminos de fases, de iteraciones, y la finalización de las fases.

La segunda dimensión representa el aspecto estático del proceso: cómo se describeen
términos de componentes de proceso, las disciplinas, las actividades, los flujos
detrabajo, los artefactos, y los roles.

En la figura 2 se puede observar como varía el énfasis de cada disciplina en un
ciertoplazo en el tiempo, y durante cada una de las fases. Por ejemplo, en
iteracionestempranas, pasamos más tiempo en requerimientos, y en las últimas
iteracionespasamos más tiempo en poner en práctica la realización del proyecto en si.

Figura 2. Disciplinas, fases, iteraciones del RUP

3 - 25

Se puede hacer mención de las tres características esenciales que definen al RUP:

2.1.- Características esenciales

Los autores de RUP destacan que el proceso de software propuesto por RUPtiene tres
características 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

Según Kruchten, P.(2000)3, los Casos de Uso son una técnica de capturade requisitos
que fuerza a pensar en términos de importancia para elusuario y no sólo en términos de
funciones que seria bueno contemplar.

Se define un Caso de Uso como un fragmento de funcionalidad delsistema que
proporciona al usuario un valor añadido. Los Casos de Usorepresentan los requisitos
funcionales del sistema.

En RUP los Casos de Uso no son sólo una herramienta para especificarlos requisitos
del sistema. También guían su diseño, implementación yprueba. Los Casos de Uso
constituyen un elemento integrador y una guíadel trabajo como se muestra en la Figura
3.

Figura 3: Los Casos de Uso integran el trabajo

Los Casos de Uso4 no sólo inician el proceso de desarrollo sino queproporcionan un
hilo conductor, permitiendo establecer trazabilidad entrelos artefactos que son
generados en las diferentes actividades delproceso de desarrollo. Como se muestra en
la Figura 3, basándose en losCasos de Uso se crean los modelos de análisis y diseño,
luego laimplementación que los lleva a cabo, y se verifica que efectivamente elproducto
implemente adecuadamente cada Caso de Uso. Todos losmodelos deben estar
sincronizados con el modelo de Casos de Uso.

4 - 25


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 organización o estructura de suspartes más
relevantes, lo que permite tener una visión común entre todoslos involucrados
(desarrolladores y usuarios) y una perspectiva clara delsistema completo, necesaria
para controlar el desarrollo [Kru00]. Laarquitectura involucra los aspectos estáticos y
dinámicos mássignificativos del sistema, está relacionada con la toma de decisiones
queindican cómo tiene que ser construido el sistema y ayuda a determinar enqué orden.
Además la definición de la arquitectura debe tomar enconsideración elementos de
calidad del sistema, rendimiento, reutilizacióny capacidad de evolución por lo que debe
ser flexible durante todo elproceso de desarrollo. La arquitectura se ve influenciada por
la plataformasoftware, sistema operativo, gestor de bases de datos,
protocolos,consideraciones de desarrollo como sistemas heredados. Muchas deestas
restricciones constituyen requisitos no funcionales del sistema.

En el caso de RUP además de utilizar los Casos de Uso para guiar elproceso se presta
especial atención al establecimiento temprano de unabuena arquitectura que no se vea
fuertemente impactada ante cambiosposteriores durante la construcción y el
mantenimiento.

Cada productotiene tanto una función como una forma. La función corresponde a
lafuncionalidad reflejada en los Casos de Uso y la forma la proporciona laarquitectura.
Existe una interacción entre los Casos de Uso y laarquitectura, los Casos de Uso deben
encajar en la arquitectura cuandose llevan a cabo y la arquitectura debe permitir el
desarrollo de todos losCasos de Uso requeridos, actualmente y en el futuro. Esto
provoca quetanto arquitectura como Casos de Uso deban evolucionar en
paralelodurante todo el proceso de desarrollo de software.

En la Figura 5 se ilustra la evolución de la arquitectura durante las fasesde RUP. Se
tiene una arquitectura más robusta en las fases finales delproyecto. En las fases
iniciales lo que se hace es ir consolidando laarquitectura por medio de baselinesy se va
modificando dependiendo delas necesidades del proyecto.

5 - 25


Figura 5: Evolución de la arquitectura del sistema

Es conveniente ver el sistema desde diferentes perspectivas paracomprender mejor el
diseño por lo que laarquitectura se representa mediante varias vistas que se centran en
aspectos concretos del sistema, abstrayéndose de los demás. Para RUP,todas las
vistas juntas forman el llamado modelo 4+1 de la arquitecturasegún Kruchten, P.(19986),
el cual recibe este nombre porque lo formanlas vistas lógica, de implementación, de
proceso y de despliegue, más lade Casos de Uso que es la que da cohesión a todas.

Figura 6: Los modelos se completan, la arquitectura no cambia drásticamente

Al final de la fase de elaboración se obtiene una baseline7 de laarquitectura donde
fueron seleccionados una serie de Casos de Usoarquitectónicamente relevantes
(aquellos que ayudan a mitigar los riesgosmás importantes, aquellos que son los más
importantes para el usuario yaquellos que cubran las funcionalidades significativas)
Como se observaen la Figura 6, durante la construcción los diversos modelos
vandesarrollándose hasta completarse (según se muestra con las formasrellenas en la
esquina superior derecha). La descripción de la arquitecturasin embargo, no debería

6 - 25

cambiar significativamente (abajo a la derecha)debido a que la mayor parte de la
arquitectura se decidió durante laelaboración. Se incorporan pocos cambios a la
arquitectura (indicadoscon mayor densidad de puntos en la figura inferior derecha)
[JBR00].8

2.1.3.- Proceso iterativo e incremental

El equilibrio correcto entre losCasos de Uso y la arquitectura es algo muy parecido al
equilibrio de laforma y la función en el desarrollo del producto, lo cual se consigue con
eltiempo. Para esto, la estrategia que se propone en RUP es tener unproceso iterativo e
incremental en donde el trabajo se divide en partesmás pequeñas o mini proyectos.
Permitiendo que el equilibrio entre Casosde Uso y arquitectura se vaya logrando
durante cada mini proyecto, asídurante todo el proceso de desarrollo. Cada mini
proyecto se puede vercomo una iteración (un recorrido más o menos completo a lo
largo detodos los flujos de trabajo fundamentales) del cual se obtiene unincremento que
produce un crecimiento en el producto. Una iteraciónpuede realizarse por medio de una
cascada como se muestra en la Figura6. Se pasa por los flujos fundamentales
(Requisitos, Análisis, Diseño,Implementación y Pruebas), también existe una
planificación de laiteración, un análisis de la iteración y algunas actividades específicas
dela iteración. Al finalizar se realiza una integración de los resultados con loobtenido de
las iteraciones anteriores.

Figura 7: Una iteración RUP

El proceso iterativo e incremental consta de una secuencia de iteraciones.Cada
iteración aborda una parte de la funcionalidad total, pasando portodos los flujos de
trabajo relevantes y refinando la arquitectura. Cadaiteración se analiza cuando termina.
Se puede determinar si hanaparecido nuevos requisitos o han cambiado los existentes,
afectando alas iteraciones siguientes. Durante la planificación de los detalles de
lasiguiente iteración, el equipo también examina cómo afectarán los riesgosque aún
quedan al trabajo en curso. Toda la retroalimentación de laiteración pasada permite
reajustar los objetivos para las siguientesiteraciones. Se continúa con esta dinámica
hasta que se haya finalizadopor completo con la versión actual del producto.

7 - 25

RUP divide el proceso en cuatro fases, dentro de las cuales se realizanvarias
iteraciones en número variable según el proyecto y en las que sehace un mayor o
menor hincapié en los distintas actividades. En la Figura8 se muestra cómo varía el
esfuerzo asociado a las disciplinas según lafase en la que se encuentre el
proyectoRUP.

Figura 8: Ciclo de vida

Las primeras iteraciones (en las fases de Inicio y Elaboración) se enfocanhacia 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 alestablecimiento de una baseline10de la
arquitectura.

Durante la fase de inicio las iteraciones hacen ponen mayor énfasis enactividades
modelado del negocio y de requisitos. En la fase deelaboración, las iteraciones se
orientan al desarrollo de la baselinede laarquitectura, abarcan más los flujos de trabajo
de requerimientos, modelode negocios (refinamiento), análisis, diseño y una parte
deimplementación orientado a la baselinede la arquitectura. En la fase deconstrucción,
se lleva a cabo la construcción del producto por medio deuna serie de iteraciones.

Para cada iteración se selecciona algunos Casos de Uso, se refina suanálisis y diseño y
se procede a su implementación y pruebas. Se realizauna pequeña cascada para cada
ciclo. Se realizan tantas iteracioneshasta 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 productopreparado para
su entrega a la comunidad de usuarios. Como se puedeobservar en cada fase
participan todas las disciplinas, pero quedependiendo de la fase el esfuerzo dedicado a
una disciplina varía.
8 - 25


Figura 9. Fases del RUP

Capítulo 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 evaluación
(actividad: Revisióndel ciclo de vida de la finalización de fase) para determinar si los
objetivos de la fase se
han cumplido. Una evaluación satisfactoria permite que el proyecto se mueva a
lapróxima fase.

3.1.- Planeando las fases

El ciclo de vida consiste en una serie de ciclos, cada uno de los cuales produceuna
nueva versión del producto, cada ciclo está compuesto por fases y cada unade estas
fases está compuesta por un número de iteraciones, estas fases son:

3.1.1.- Concepción, Inicio o Estudio de oportunidad

Define el ámbito y objetivos del proyecto Se define la funcionalidad ycapacidades del
producto.

3.1.2.- Elaboración

Tanto la funcionalidad como el dominio del problema se estudian enprofundidad Se
define una arquitectura básica Se planifica el proyectoconsiderando recursos
disponibles.

3.1.3.- Construcción

El producto se desarrolla a través de iteraciones donde cada iteracióninvolucra tareas
de análisis, diseño e implementación Las fases de estudioy análisis sólo dieron una
arquitectura básica que es aquí refinada demanera incremental conforme se construye
(se permiten cambios en laestructura) Gran parte del trabajo es programación y
pruebas. Sedocumenta tanto el sistema construido como el manejo del mismo.

Estafase proporciona un producto construido junto con la documentación.

3.1.4.- Transición
9 - 25


Se libera el producto y se entrega al usuario para un uso real Se incluyentareas de
marketing, empaquetado atractivo, instalación, configuración,entrenamiento, soporte,
mantenimiento, etc.

Los manuales de usuario se completan y refinan con la información anterior,
estastareas se realizan también en iteraciones Todas las fases no son idénticas
entérminos de tiempo y esfuerzo.

Aunque esto varía considerablemente dependiendo del proyecto, un ciclo dedesarrollo
inicial típico para un proyecto de tamaño mediano debe anticipar ladistribución siguiente
el esfuerzo y horario:

Tabla I. Esfuerzo-horario contra fases del RUP

Lo cual se puede representar gráficamente como se muestra en la figura 10:

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

El modelo cascada según Winston Royce(1970)13, es un secuencial modelo deldesarrollo del
software (un proceso para la creación del software) en que el desarrollo seconsidera como
fluyendo constantemente hacia abajo (como a cascada) con las fases deanálisis de requisitos,
diseño, puesta en práctica, prueba (validación), integración, ymantenimiento.

Las fases de concepción y elaboración serían considerablemente más
pequeñas.Algunas herramientas que pueden automatizar una cierta porción del
esfuerzo dela fase de construcción pueden atenuar esto, haciendo que la fase
deconstrucción sea mucho más pequeña que las fases de concepción y
elaboraciónjuntas. Este es precisamente el objetivo del trabajo. Cada paso con las
cuatrofases produce una generación del software. A menos que el producto "muera",
sedesarrollará nuevamente repitiendo la misma secuencia las fases de
concepción,elaboración, construcción y transición, pero con diversos énfasis cada fase.

10 - 25

Estos ciclos subsecuentes se llaman los ciclos de la evolución. Mientras que elproducto
pasa durante varios ciclos, se producen las nuevas generaciones. En lafigura 11 se
muestre este ciclo evolutivo.

Figura 11. Ciclo evolutivo en la elaboración de software basado en el RUP

Los ciclos evolutivos pueden ser iniciados por las mejoras sugeridas por elusuario,
cambios en el contexto del usuario, cambios en la tecnología subyacente,reacción a la
competición, etcétera. Los ciclos evolutivos tienen típicamente fasesde concepción y
elaboración mucho más cortas, puesto que la definición y laarquitectura básicas del
producto son determinadas por los ciclos de desarrolloanteriores. Las excepciones a
esta regla son los ciclos evolutivos en los cualesocurre o surge un producto significativo
o unaredefinición arquitectónica.

3.1.4.1.- Esfuerzo respecto de los flujos de trabajo

En la figura 5 se muestran ciertos porcentajes, de forma verticalse muestra el esfuerzo
que se tiene que realizar por cada una delas disciplinas o flujos de trabajo14, y los dos
porcentajes que semuestran de forma horizontal son para todo el proyecto.

Explicando mas puntualmente la figura 12 se puede observar quepara la obtención de
requerimientos o requisitos en la fase deconcepción se empiezan a obtener, en la fase
de elaboracióntiene su auge y va declinando en la fase de construcción, realizartodo
esto requiere aproximadamente un 15% de esfuerzo, y asísucesivamente con las
demás disciplinas. En esta sección y lasiguiente, 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:cómo se estructuran las tareas, cómo se realizan, cuál es su orden
correlativo, cómo se sincronizan, cómofluye la información que soporta las tareas y
cómo se le hace seguimiento al cumplimiento de las tareas.

11 - 25


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 quees el esfuerzo
realizado por cada fase en forma general eincluyendo las iteraciones dentro de cada
fase; y en la segunda fila,la duración que tiene aproximadamente en porcentajes del
tiempototal del proyecto para cada una de las fases incluyendo todas lasiteraciones que
conlleven realizar cada fase.

Explicando más puntualmente una pequeña parte de la figura 13 sepuede observar que
para la fase de construcción se tiene quededicar más esfuerzo y mayor duración,
siempre y cuandodependiendo de qué disciplina estemos ejecutando, por ejemplo en
la disciplina de implementación se tiene mucho auge en la fase deconstrucción.

Figura 13. Esfuerzo respecto de las fases

12 - 25


Capítulo 4: Notación de la metodología y Disciplinas.

Las disciplinas conllevan los flujos de trabajo, los cuales son una secuencia de
pasospara la culminación de cada disciplina, estas disciplinas se dividen en dos grupos:
lashyprimarias y las de apoyo. Las primarias son las necesarias para la realización de
unproyecto de software, aunque para proyectos no muy grandes se pueden
omitiralgunas; entre ellas se tienen: Modelado del Negocio, Requerimientos, Análisis
yDiseño, Implementación, Pruebas, Despliegue. Las de apoyo son las que como
sunombre lo indica sirven de apoyo a las primarias y especifican otras características
enla realización de un proyecto de software; entre estas se tienen: Entorno, Gestión
delProyecto, Gestión de Configuración y Cambios. A continuación se
describerápidamente cada una de estas disciplinas.

4.1.- Modelado del negocio.

Esta disciplina tiene como objetivos comprender la estructura y la dinámica de
laorganización, comprender problemas actuales e identificar posibles
mejoras,comprender los procesos de negocio. Utiliza el Modelo de CU del Negocio
paradescribir los procesos del negocio y los clientes, el Modelo de Objetos delNegocio
para describir cada CU del Negocio con los Trabajadores, ademásutilizan 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 límites del sistema, y una interfaz de usuario,realizar una
estimación del costo y tiempo de desarrollo. Utiliza el Modelo de CUpara modelar el
Sistema que comprenden los CU, Actores y Relaciones, ademásutiliza los diagramas de
Estados de cada CU y las especificacionessuplementarias.

4.3.- Análisis y diseño.

Esta disciplina define la arquitectura del sistema y tiene como objetivos
trasladarrequisitos en especificaciones de implementación, al decir análisis se refiere
atransformar CU en clases, y al decir diseño se refiere a refinar el análisis parapoder
implementar los diagramas de clases de análisis de cada CU, losdiagramas de
colaboración de de cada CU, el de clases de diseño de cada CU, elde secuencia de
diseño de CU, el de estados de las clases, el modelo dedespliegue de la arquitectura.

4.4.- Implementación.

Esta disciplina tiene como objetivos implementar las clases de diseño
comocomponentes (ej. fichero fuente), asignar los componentes a los nodos, probar
loscomponentes individualmente, integrar los componentes en un sistema
ejecutable(enfoque incremental). Utiliza el Modelo de Implementación, conjuntamente
losDiagramas de Componentes para comprender cómo se organizan losComponentes y
dependen unos de otros.

13 - 25

4.5.- Pruebas.

Esta disciplina tiene como objetivos verificar la integración de los componentes(prueba
de integración), verificar que todos los requisitos han sido implementados(pruebas del
sistema), asegurar que los defectos detectados han sido resueltosantes de la
distribución

4.6.- Despliegue.

Esta disciplina tiene como objetivos asegurar que el producto está preparado parael
cliente, proceder a su entrega y recepción por el cliente. En esta disciplina serealizan
las actividades de probar el software en su entorno final (Prueba Beta),empaquetarlo,
distribuirlo e instalarlo, así como la tarea de enseñar al usuario.

4.7.- Gestión y configuración de cambios.

Es esencial para controlar el número de artefactos producidos por la cantidad
depersonal que trabajan en un proyecto conjuntamente. Los controles sobre loscambios
son de mucha ayuda ya que evitan confusiones costosas como lacompostura de algo
que ya se había arreglado etc., y aseguran que los resultadosde los artefactos no
entren en conflicto con algunos de los siguientes tipos deproblemas:

Actualización simultánea: Es la actualización de algo elaborado con anterioridad,sin
saber que alguien más lo está actualizando.

Notificación limitada: Al realizar alguna modificación, no se deja información sobrelo
que se hizo, por lo tanto no se sabe quién, como, y cuando se hizo.

Versiones múltiples: No saber con exactitud, cual es la última versión, y al final nose
tiene un orden sobre que modificaciones se han realizado a las diversasversiones.

4.8.- Gestión del proyecto.

La gestión de proyectosu objetivo es equilibrar los objetivos competitivos,administrar el
riesgo, y superar restricciones para entregar un producto quesatisface las necesidades
e ambos clientes con éxito (los que pagan el dinero) ylos usuarios. Con la Gestión del
Proyecto se logra una mejoría en el manejo deuna entrega exitoso de software. En
resumen su propósito consiste en proveerpautas 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 dirección
delproyecto. Por ejemplo, no cubre problemas como:

Administración de personal: contratando, entrenando, enseñando.
Administración del presupuesto: definiendo, asignando.
Administración de los contratos con proveedores y clientes.

14 - 25

4.9.- Entorno.

Esta disciplina se enfoca sobre las actividades necesarias para configurar elproceso
que engloba el desarrollo de un proyecto y describe las actividadesrequeridas para el
desarrollo de las pautas que apoyan un proyecto.

Su propósito es proveer a la organización que desarrollará el software, unambiente en
el cual basarse, el cual provee procesos y herramientas para poderdesarrollar el
software.

Capítulo 5: Ejemplodesarrollado.

Plan de Desarrollo de Software
1. Introducción
A continuación se presenta un plan inicial de desarrollo del sistema Repositorio de
Sistemas, el cual consiste en un proyecto de gestión de sistemas para cualquier
empresa de tamaño considerable, que requiera un manejo automatizado de la
información 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
información 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 autónoma manejan la información
correspondiente a cada país o región.

De acuerdo a las características del proyecto se tomó como enfoque de desarrollo
una configuración del proceso RUP, seleccionando los roles de los participantes, las
actividades a realizar y los artefactos (entregables) que serán generados. Este
documento es a su vez uno de los artefactos de RUP.
1.1 Propósito
El propósito del Plan de Desarrollo de Software es proporcionar la información
necesaria para llevar el control del proyecto. Se describe la organización del
proyecto y la forma en cómo debe ser llevado o elaborado por los usuarios
desarrolladores del sistema. También sirve como base para llevar a cabo un
análisis más detallado del mismo.
En cuanto a cuáles 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,
cuáles técnicas aplicar, en cuál momento se debe hacer y qué otras actividades
dependen de ello.

15 - 25

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 organización. Adicionalmente, se
requiere realizar el detalle de las iteraciones individuales, esto se describe en los
planes de cada iteración, documentos que se aportan en forma separada. Se
necesita del documento “Visión” durante el proceso de desarrollo, ya que en ese
artefacto se definen las características del producto a desarrollar, lo cual
constituye la base para la planificación de las iteraciones. Para esta versión 1.0 del
Plan de Desarrollo del Software, se ha realizado una estimación 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, Acrónimos y Abreviaciones
RS: Repositorio de Sistemas
RUP: RationalUnifiedProcess
1.4 Referencias
Este documento hace referencia a los documentos Visión y Arquitectura del
Software.

1.5 Vista Global
El Plan de Desarrollo contempla las 4 secciones siguientes:
Vista General del Proyecto: proporciona información acerca del propósito, el
alcance y los objetivos del proyecto; las suposiciones y las restricciones
consideradas para el sistema; y por último la evolución de este plan a medida
que se comienza una nueva iteración.
Organización 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.
Gestión del Proceso: estima el costo y la planificación aproximada del proyecto,
define las fases e hitos del proyecto y describe cómo se realizará su
seguimiento.
2. Vista General del Proyecto
2.1 Propósito, Alcance y Objetivos
En una organización (por ejemplo: una empresa por departamentos transnacional),
muchas veces es desconocida la cantidad de sistemas internos, más aún es difícil
llevar un monitoreo de cada sistema para llevar un mantenimiento de las
funcionalidades de cada uno de ellos. El propósito principal de este proyecto es
hacer cumplir esos objetivos. Se quiere tener un sistema de control que monitoree y
mantenga información detalladas sobre los sistemas de una organización.

Actualmente, no se cuenta con un sistema que proporcione tal información, 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.
16 - 25

2.2 Suposiciones y Restricciones
1. Se asume que el usuario final, en este caso el gerente general de la empresa,
encargada del monitoreo general de los sistemas de la organización, 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 disposición de los desarrolladores utilizar el lenguaje de programación más
conveniente, por lo cual hasta el momento la opción más aceptada sería utilizar un
framework de PHP llamado PHPCake.
3. En cuanto a la información manejada, esta debe mantenerse con cierto grado de
confidenciabilidad, flexibilidad, usabilidad y seguridad.

2.3 Evolución del Plan de Desarrollo del Software.

El Plan de Desarrollo del Software se revisará periódicamente y se refinará antes
del comienzo de cada iteración.

3. ORGANIZACIÓN 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 demás
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. Investigación:Esta fase implica un estudio profundo de técnicas, herramientas y
avances en el área de investigación, para generar un documento de contexto de
trabajo donde se resuma la información recavada.

2. Inicio: Una vez generada la documentación de contexto de trabajo, al finalizar
la fase de investigación, el grupo cuenta con la información necesaria para analizar
el problema y proponer una solución al mismo. Esto se realiza en la fase de inicio.
Luego de planteada una solución al problema, se comienza a detallar técnicamente
la implementación de la solución propuesta.

3. Elaboración: Es en la fase de elaboración donde se realiza el diseño del
sistema, lo cual implica definición de la arquitectura del mismo. Esta fase se da por
culminada cuando dicha arquitectura sea estable.

4. Construcción: Demostrada la estabilidad de la arquitectura adoptada se
comienza a implementar el sistema final. La fase de construcción implica una fuerte
carga horaria de implementación. A fines de esta fase se comienzan las sesiones
de prueba de la solución implementada.

17 - 25

3.2 Planificación De Fases De La Metodología RUP.

3.2.1. Inicio.
Los objetivos de esta fase son:

Establecer los límites 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. Elaboración.
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 críticos

3.2.3. Construcción.
Los objetivos de la fase son:

Refinar las vistas de la fase anterior
Implementar las funcionalidades del sistema
Desarrollo iterativo incremental del producto completo
Realización de pruebas
Corrección y ajuste de errores

3.3 Estructura Organizacional

El equipo consta de nueve integrantes. La estructura organizacional del grupo ha
sido definida como horizontal, debido a las características del mismo. Cada
integrante esta en capacidad de realizar cualquier actividad referente al proceso
de desarrollo del proyecto. Es necesaria la colaboración 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 división 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
basándose en el calendario y el plan de desarrollo.

18 - 25

3.3.2 Roles y Responsabilidades

Los roles y responsabilidades serán 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. Gestión del Proceso
4.1 Estimaciones del Proyecto

Al ser un proyecto de carácter académico, se deja de lado el aspecto económico
ya que no se cuenta con un presupuesto ni costos asociados al desarrollo, ya
que su valor se representa en el aporte tecnológico para la Universidad Simón
Bolívar.

4.2 Plan del Proyecto

Para el desarrollo satisfactorio del sistema fue necesario dividirlo en varias fases,
basadas en la metodología RUP, cada una estas fases podrá contener una o
mas iteraciones obteniendo en cada iteración un hito especifico.
La descripción detallada de cada una de las fases y sus iteraciones que
conforman el proceso de desarrollo del sistema se encuentran a continuación

4.2.1 Plan de las Fases

Nro.
Fase Duración
Iteraciones

Fase de Inicio 1 4 semanas

Fase de Elaboración 1 6 semanas

Fase de Construcción 2 12 semanas

4.2.2 Objetivos de las Fases

Fase Descripción

Fase de Inicio Durante esta fase, se desarrolla una descripción del producto
final a partir de una buena idea y se presenta el análisis de
negocio para el producto. En su única iteración se especifica
las funcionalidades que debe poseer el sistema y su alcance.
Además 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 cuáles son las necesidades a ser satisfechas con
mayor prioridad, esto se define en el artefacto Visión. Se
definen los casos de uso, como una representación de las
funcionalidades del sistema y de la interacción con el usuario.
Se establece el Plan de Desarrollo, donde se describe de forma

19 - 25


detallada las actividades que se llevarán a cabo para crear el
sistema. El final de la fase esta marcado con la aceptación por
parte del cliente del artefacto Visión y el Plan de Desarrollo.

Fase de Se obtiene un entendimiento más detallado de los
Elaboración requerimientos, se procede a diseñar, implementar, validar y
generar una línea base para la arquitectura. Se definen los
subsistemas, los componentes clave y sus interfaces; se usan
los casos de uso significantes arquitectónicamente para dirigir
la arquitectura. Se consolidan y empaquetan las clases
identificadas. Se diseña la Base de datos. Se implementan y
prueban los escenarios críticos. Se debe mitigar los riesgos
esenciales y producir un plan de desarrollo más preciso. Se
elabora el artefacto de arquitectura el cual contempla todo el
diseño de la arquitectura. La culminación de esta fase viene
dada por el documento arquitectura y el prototipo
implementado.

Fase de Durante la fase de construcción se terminan de analizar y
Construcción diseñar todos los casos de uso, refinando el Modelo de Análisis
/ Diseño, 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 características del sistema, las
cuales son probadas hasta ser validadas por el cliente. El fin de
esta fase viene dado por la versión final del sistema, la cual
incluye toda la funcionalidad del producto.

4.2.3 Calendario del Proyecto

A continuación se presenta un calendario de las principales tareas del proyecto
incluyendo sólo 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 mayoría de los artefactos son generados muy
tempranamente en el proyecto pero van desarrollándose en mayor o menor
grado de acuerdo a la fase e iteración del proyecto. Se incluyen los artefactos a
entregar en cada fase. La fecha de aprobación indica cuándo el artefacto en
cuestión tiene un estado de completitud suficiente para someterse a revisión y
aprobación, pero esto no quita la posibilidad de su posterior refinamiento y
cambios.

20 - 25

Fase de Inicio
Duración: 4 semanas.

Actividad Semana Criterio de culminación
Comienzo -
Semana Entrega
Levantamiento de Información 1-3 (Finalizado) Esta fase culminará
Detalles del proyecto 1-3 (Finalizado) cuando se tengan al
Elaboración de página Web con 3-4 (Finalizado) menos 90% de las
artefactos actividades aquí
Plan de Iteración de la fase de 4-5 (Finalizado) mencionadas.
elaboración
Creación del Plan inicial de 2-4 (Finalizado)
Desarrollo del proyecto
Creación de documento Visión 3-4 (Finalizado)
del sistema
Refinación del documento Visión 4-5 (Finalizado)
del sistema
Modelos de Casos de Uso del 4-5 (Finalizado)
Negocio
Lista inicial de Requerimientos 3-5 (Finalizado)
Especificación de requerimientos 5-6 (Finalizado)
funcionales y no funcionales
Lista inicial de riesgos asociados 4-6 (Finalizado)
Glosario inicial del proyecto 5-6 (Finalizado)
Prototipo de estructura del 4-5 (Finalizado)
sistema
Elaboración del documento de 4-5 (Finalizado)
arquitectura inicial.

Fase de Elaboración

Actividad Semana Iteración Casos de Usos
Comienzo Implementados y Criterio
-Semana de culminación de la
Entrega iteración
Refinación y diagramas de los 6-7 1 Casos de Uso:
Casos de Uso del sistema (Finalizado) 1. Ingresar Sistema
Vista de Datos: Creación de 7-8 1 2. Solicitar Asociación
Modelo Entidad Relación (ER) (Finalizado) 3. Listar Asociaciones
Vista Lógica: Modelo de 7-8 1 pendientes
Análisis (Finalizado) 4. Aceptar asociación
Diagrama de Clases 8-9 1 5. Rechazar asociación
(Finalizado) 6. Ver Asociación
Diagrama de Secuencia 8-9 1 7. Ver Grados de
(Finalizado) Asociación
Establecer casos de uso 7-7 1 8. Consultar

21 - 25


críticos del sistema. (Finalizado) Asociación
Refinación del documento de 8-9 1 9. Listar Sistemas
Arquitectura del Software (Finalizado) 10. Ver Sistema
Refinación del prototipo con 10-12 1 11. Consultar
los casos de uso críticos del (Finalizado) estadísticas generales
sistema 12. Modificar Sistema
Plan de la segunda Iteración 8-9 1
de la fase de elaboración (Eliminado) Esta iteración culminará
Refinación de diagramas y de 9-12 1 cuando:
los casos de uso (Finalizado) -Se tengan completos los
Refinación y actualización del 11-12 1 modelos de casos de uso,
plan de proyecto (Finalizado) con sus respectivos
diagramas de secuencia.
-Se haya especificado una
arquitectura del software
en al menos un 80%

Fase de Construcción

Actividad Semana Iteración Casos de Usos Implementados
Comienzo - y Criterio de culminación de la
Semana iteración
Entrega
Plan de la primera 1-2 1
Iteración de la fase de Casos de Uso:
construcción
Refinamiento de los 1-2 1 1. Finalización del módulo
diagramas y la base sistemas.
de datos 2. Refinación del módulo
asociaciones.
Desarrollo del Sistema 1-6 1 3. Módulo de errores.
Manual del Usuario 5-6 1
Ajustes al Sistema 7-7 1
Pruebas 1-7 1 - Base de datos en un 100%
Plan de la segunda 6-7 1 - Sistema desarrollado en un 80%.
Iteración de la fase de - Manual completado en un 80%.
construcción
Refinamiento de los 7-8 2
diagramas y la base Casos de Uso:
de datos
Pruebas 8-12 2 1. Manejo de la seguridad
Desarrollo del Sistema 6-11 2 2. Refinación módulo de errores.
Culminación del 10-11 2 3. Gráficos asociaciones
manual de usuario Se han realizado todas las
Corrección de errores 8-11 2 pruebas para asegurar que el
sistema está libre de errores.

22 - 25

4.3 Seguimiento y Control del Proyecto.

4.4.1 Plan de Manejo de Requerimientos.

En el documento Visión se encuentran de manera detallada los requerimientos
funcionales y no funcionales del sistema. Se establecerán en la fase inicial y
serán revisados durante la fase de elaboración y construcción. En caso de que
surjan nuevos requerimientos durante estas fases habrá que discutir sobre su
factibilidad y los riesgos que implicaría 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 iteración.

4.3.2 Plan de Control de Presupuesto

Debido a que el proyecto es de carácter académico no supone la elaboración y
mantenimiento de un presupuesto.

4.3.3 Plan de Control de Calidad.

Para establecer puntos de control sobre el sistema, se realizarán pruebas sobre
los prototipos entregados pertenecientes a cada una de las fases. En base a la
metodología 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 podría fallar, como lo son los
casos borde.
-. Prueba de Volumen Funcional: Certifica si el sistema esta en la capacidad de
manejar altos volúmenes de datos sin afectar su rendimiento.
-.Prueba de Concurrencia: Certifica la capacidad del sistema de atender múltiples
solicitudes de parte de los actores que acceden a un mismo recurso.
-. Prueba de Instalación: 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, además de los artefactos correspondientes y
estipulados dentro de este plan.

23 - 25

4.4 Plan de Manejo de Riesgos
Para el manejo de riesgos se aplica el modelo CMMI, llamada Gestión 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 través 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 evalúan, 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 Culminación
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 situación que ponga en peligro su culminación. Para
lograr un sistema perdurable y evolutivo, se proporciona la documentación 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 elaboración de distintos diagramas y artefactos siguiendo la metodología
RUPproveen una fácil ejecución del proceso de elaboración de un Sistema de
Software, yaque describen cómo está estructurado el sistema desde diferentes
perspectivasorientadas a los diferentes involucrados en un proyecto.

2. Se puede reducir el tiempo de desarrollo de un Sistema de Software, aplicando
lametodología RUP y UML ya que permite lograr de una manera fiable y rápida
eldesarrollo del Sistema deseado.

3. Colocando componentes en los distintos servidores que conformen el sistema
adesarrollar,se cuenta de una manera automática con todos los servicios prestados
pordichos componentes, es decir, se ponen a disposición de los desarrollador es un
grannúmero de herramientas que se pueden aprovechar en la realización del
Sistema deSoftware de una manera mucho más eficaz.

4. El tener todo el procedimiento de desarrollo de un Sistema de Software, es
unaherramienta necesaria y efectiva para administrarlo; y así contar con una
visiónunificada de todo el proceso, con lo que se facilita la implementación del
mismo.

RECOMENDACIONES.

1. la metodología RUP cuenta con un enfoque disciplinado en la asignación de tareas
yresponsabilidades dentro de una organización del desarrollo, con la cual se
puedemantener una fácil administración de este proceso.

24 - 25


2. Para obtener un máximo control de variables que conlleva un desarrollo de
aplicaciones ypoder mantener una ordenada implementación de éstas, es importante
seguirmetodologías y estándares que nos lleven a estar en competitividad en todo
momento.

3. Al implementar un Desarrollo Rápido de Aplicaciones de un Sistema particular,
esimportante la utilización de Patrones, los cuales ya tienen una funcionalidad
general y hansido predefinidos, y así contar con una base consistente y previamente
elaborada para laimplementación del Software.

BIBLIOGRAFIA.

1. Grupo Isaias Carrillos Perez. (2008) Metodología 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). Metodologías De Desarrollo De Software Canada:Editorial Canada Pen.
4. Jacaboson, I., Booch, G., Rumbaugh J. (2000) Proceso Unificado de Desarrollo
deSoftware.New York:Editorial Mc Graw Hill.
5. Kruchten, P. (1995). Architectural Blueprints—the “4+1” View Model of
SoftwareArchitecture.IEEE Software.
6. Marcos, E. (2005). “Investigación en Ingeniería del Software vs.
DesarrolloSoftware”, 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 McGraw
Hill.
9. RUP/Easy. (2004). GUÍA METODOLÓGICA DE DESARROLLO DE SISTEMAS
10.Schmuller, Joseph. (2000) Aprendiendo UML en 24 horas.México:Editorial Prentice
all.
11. Sommerville, I. (2005) Ingeniería del software, 7ª edición, Pearson-
Addison.España:Editorial Wesley.
12.Wasserfallmodell, Entstehungskontext, Markus Rerych, und
Wirkungsforschung,(2007). TU-Wien de Gestaltungs- del für de Institut. Tenido
acceso en línea 28 denoviembre.

25 - 25

Metodologia rup

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Metodologia rup

Ähnlich wie Metodologia rup (20)

Metodologia rup