Metodologia rup

35
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: 1 - 35

Transcript of Metodologia rup

Page 1: 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

Page 2: Metodologia rup

ANÁLISIS DE SISTEMAS II

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.

Rational Unified Process (RUP)

Las siglas RUP en ingles significa Rational Unified Process (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 seusa 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 1967con la Metodología Ericsson (Ericsson Approach) elaborada por Ivar Jacobson, una aproximación de desarrollo basada en componentes, que introdujo el concepto de Caso de Uso. Entre los años de 1987 a 1995 Jacobson fundó la compañía Objectory AB 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 entre 1995 y 1997 se desarrolla Rational Objectory Process (ROP) a partir de Objectory 3.8 ydel Enfoque Rational (Rational Approach) adoptando UML como lenguaje de modelado.

2 - 25

Page 3: Metodologia rup

ANÁLISIS DE SISTEMAS II

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, destacándose 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, diseñador de software, un metodologista de software y entusiasta de diseño de patrones. Es director Cientí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 vida del 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 en té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 describe en términos 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 varía 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 más tiempo en requerimientos, y en las últimas iteraciones pasamos más tiempo en poner en práctica la realización del proyecto en si.

Figura 2. Disciplinas, fases, iteraciones del RUP

3 - 25

Page 4: Metodologia rup

ANÁLISIS DE SISTEMAS II

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 RUP tiene 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 captura de requisitos que fuerza a pensar en términos de importancia para el usuario y no sólo en términos 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 añadido. Los Casos de Uso representan los requisitos funcionales del sistema.

En RUP los Casos de Uso no son sólo una herramienta para especificar los requisitos del sistema. También guían su diseño, implementación y prueba. Los Casos de Uso constituyen un elemento integrador y una guía del 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 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, basándose en los Casos de Uso se crean los modelos de análisis y diseño, luego la implementación 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.

4 - 25

Page 5: Metodologia rup

ANÁLISIS DE SISTEMAS II

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 sus partes más relevantes, lo que permite tener una visión común entre todos los involucrados (desarrolladores y usuarios) y una perspectiva clara delsistema completo, necesaria para controlar el desarrollo [Kru00]. La arquitectura involucra los aspectos estáticos y dinámicos más significativos del sistema, está relacionada con la toma de decisiones que indican cómo tiene que ser construido el sistema y ayuda a determinar en qué orden. Además la definición de la arquitectura debe tomar en consideración elementos de calidad del sistema, rendimiento, reutilización y capacidad de evolución por lo que debe ser flexible durante todo el proceso de desarrollo. La arquitectura se ve 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 además de utilizar los Casos de Uso para guiar el proceso se presta especial atención al establecimiento temprano de una buena arquitectura que no se vea fuertemente impactada ante cambios posteriores durante la construcción y el mantenimiento.

Cada producto tiene tanto una función como una forma. La función corresponde a la funcionalidad reflejada en los Casos de Uso y la forma la proporciona la arquitectura. Existe una interacción 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 evolución de la arquitectura durante las fases de RUP. Se tiene una arquitectura más 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.

5 - 25

Page 6: Metodologia rup

ANÁLISIS DE SISTEMAS II

Figura 5: Evolución de la arquitectura del sistema

Es conveniente ver el sistema desde diferentes perspectivas para comprender mejor el diseño por lo que la arquitectura se representa mediante varias vistas que se centran enaspectos concretos del sistema, abstrayéndose de los demás. Para RUP, todas las vistas juntas forman el llamado modelo 4+1 de la arquitectura según Kruchten, P.(19986), el cual recibe este nombre porque lo forman las vistas lógica, de implementación, de proceso y de despliegue, más la de 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 la arquitectura donde fueron seleccionados una serie de Casos de Uso arquitectónicamente relevantes (aquellos que ayudan a mitigar los riesgos más importantes, aquellos que son los más importantes para el usuario y aquellos que cubran las funcionalidades significativas) Como se observa en la Figura 6, durante la construcción los diversos modelos van desarrollándose hasta completarse (según se muestra con las formas rellenas en la

6 - 25

Page 7: Metodologia rup

ANÁLISIS DE SISTEMAS II

esquina superior derecha). La descripción de la arquitectura sin embargo, no debería cambiar significativamente (abajo a la derecha) debido a que la mayor parte de la arquitectura se decidió durante la elaboración. 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 función 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 más pequeñas 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 iteración (un recorrido más 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 iteración puede realizarse por medio de una cascada como se muestra en la Figura 6. Se pasa por los flujos fundamentales (Requisitos, Análisis, Diseño, Implementación y Pruebas), también existe una planificación de la iteración, un análisis de la iteración y algunas actividades específicas de la iteración. Al finalizar se realiza una integración de los resultados con lo obtenido de las iteraciones anteriores.

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 por todos los flujos de trabajo relevantes y refinando la arquitectura. Cada iteración se analiza cuando termina. Se puede determinar si han aparecido nuevos requisitos o han cambiado los existentes, afectando a las iteraciones siguientes. Durante la planificación de los detalles de la siguiente iteración, el equipo también examina cómo afectarán los riesgos que aún quedan al trabajo en curso. Toda la retroalimentación de la iteración pasada permite reajustar los objetivos para las siguientes iteraciones. Se continúa con esta dinámica hasta que se haya finalizado por completo con la versión actual del producto.

7 - 25

Page 8: Metodologia rup

ANÁLISIS DE SISTEMAS II

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

Figura 8: Ciclo de vida

Las primeras iteraciones (en las fases de Inicio y Elaboración) se enfocan hacia la comprensión del problema y la tecnología, la delimitación del ámbito del proyecto, la eliminación de los riesgos críticos, y al establecimiento de 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 elaboración, las iteraciones se orientan al desarrollo de la baseline de la arquitectura, abarcan más los flujos de trabajo de requerimientos, modelo de negocios (refinamiento), análisis, diseño y una parte de implementación orientado a la baseline de la arquitectura. En la fase de construcción, se lleva a cabo la construcción del producto por medio de una serie de iteraciones.

Para cada iteración se selecciona algunos Casos de Uso, se refina su análisis y diseño y se procede a su implementación y pruebas. Se realiza una pequeña cascada para cada ciclo. Se realizan tantas iteraciones hasta que se termine la implementación de la nueva versión del producto.

En la fase de transición se pretende garantizar que se tiene un producto preparado para su entrega a la comunidad de usuarios. Como se puede observar en cada fase

8 - 25

Page 9: Metodologia rup

ANÁLISIS DE SISTEMAS II

participan todas las disciplinas, pero que dependiendo de la fase el esfuerzo dedicado a una disciplina varía.

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ón del ciclo de vida de la finalización de fase) para determinar si los objetivos de la fase sehan cumplido. Una evaluación satisfactoria permite que el proyecto se mueva a la próxima fase.

3.1.- Planeando las fases

El ciclo de vida consiste en una serie de ciclos, cada uno de los cuales produce una nueva versión del producto, cada ciclo está compuesto por fases y cada una de 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 y capacidades del producto.

3.1.2.- Elaboración

Tanto la funcionalidad como el dominio del problema se estudian en profundidad Se define una arquitectura básica Se planifica el proyecto considerando recursos disponibles.

3.1.3.- Construcción

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

Esta fase proporciona un producto construido junto con la documentación.

9 - 25

Page 10: Metodologia rup

ANÁLISIS DE SISTEMAS II

3.1.4.- Transición

Se libera el producto y se entrega al usuario para un uso real Se incluyen tareas 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, estas tareas se realizan también en iteraciones Todas las fases no son idénticas en términos de tiempo y esfuerzo.

Aunque esto varía considerablemente dependiendo del proyecto, un ciclo de desarrollo inicial típico para un proyecto de tamaño mediano debe anticipar la distribució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 del desarrollo del software (un proceso para la creación del software) en que el desarrollo se considera como fluyendo constantemente hacia abajo (como a cascada) con las fases de análisis de requisitos, diseño, puesta en práctica, prueba (validación), integración, y mantenimiento.

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 de la fase de construcción pueden atenuar esto, haciendo que la fase de construcción sea mucho más pequeña que las fases de concepción y elaboración juntas. Este es precisamente el objetivo del trabajo. Cada paso con las cuatro fases produce una generación del software. A menos que el producto "muera", se desarrollará 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

Page 11: Metodologia rup

ANÁLISIS DE SISTEMAS II

Estos ciclos subsecuentes se llaman los ciclos de la evolución. Mientras que el producto pasa durante varios ciclos, se producen las nuevas generaciones. En la figura 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 el usuario, 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 fases de concepción y elaboración mucho más cortas, puesto que la definición y la arquitectura básicas 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 redefinición arquitectónica.

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 obtención de requerimientos o requisitos en la fase de concepción se empiezan a obtener, en la fase de elaboración tiene su auge y va declinando en la fase de construcción, realizar todo esto requiere aproximadamente un 15% de esfuerzo, y así sucesivamente con las demás disciplinas. En esta sección 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: cómo se estructuran las tareas, cómo se realizan, cuál es su orden correlativo, cómo se sincronizan, cómo fluye la información que soporta las tareas y cómo se le hace seguimiento al cumplimiento de las tareas.

11 - 25

Page 12: Metodologia rup

ANÁLISIS DE SISTEMAS II

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 duración 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 más puntualmente una pequeña parte de la figura 13 se puede observar que para la fase de construcción se tiene que dedicar más esfuerzo y mayor duración, siempre y cuando dependiendo de qué disciplina estemos ejecutando, por ejemplo enla disciplina de implementación se tiene mucho auge en la fase de construcción.

Figura 13. Esfuerzo respecto de las fases

12 - 25

Page 13: Metodologia rup

ANÁLISIS DE SISTEMAS II

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

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

4.1.- Modelado del negocio.

Esta disciplina tiene como objetivos comprender la estructura y la dinámica de la organización, 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, además 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 límites del sistema, y una interfaz de usuario, realizar una estimación del costo y tiempo de desarrollo. Utiliza el Modelo de CU para modelar el Sistema que comprenden los CU, Actores y Relaciones, además utiliza los diagramas de Estados de cada CU y las especificaciones suplementarias.

4.3.- Análisis y diseño.

Esta disciplina define la arquitectura del sistema y tiene como objetivos trasladar requisitos en especificaciones de implementación, al decir análisis se refiere a transformar CU en clases, y al decir diseño se refiere a refinar el análisis para poder implementar los diagramas de clases de análisis de cada CU, los diagramas de colaboración de de cada CU, el de clases de diseño de cada CU, el de secuencia de diseño de CU, el de estados de las clases, el modelo de despliegue de la arquitectura.

4.4.- Implementación.

Esta disciplina tiene como objetivos implementar las clases de diseño 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 Implementación, conjuntamente los Diagramas de Componentes para comprender cómo se organizan los Componentes y dependen unos de otros.

13 - 25

Page 14: Metodologia rup

ANÁLISIS DE SISTEMAS II

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 resueltos antes de la distribución

4.6.- Despliegue.

Esta disciplina tiene como objetivos asegurar que el producto está preparado para el cliente, proceder a su entrega y recepción 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 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 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 había arreglado etc., y aseguran que los resultados de los artefactos no entren en conflicto con algunos de los siguientes tipos de problemas:

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 sobre lo 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 no se tiene un orden sobre que modificaciones se han realizado a las diversas versiones.

4.8.- Gestión del proyecto.

La gestión 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 Gestión del Proyecto se logra una mejoría en el manejo de una entrega exitoso de software. En resumen su propósito 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 dirección del proyecto. 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

Page 15: Metodologia rup

ANÁLISIS DE SISTEMAS II

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 propósito es proveer a la organización que desarrollará el software, un ambiente en el cual basarse, el cual provee procesos y herramientas para poder desarrollar el software.

Capítulo 5: Ejemplo desarrollado.

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

Page 16: Metodologia rup

ANÁLISIS DE SISTEMAS II

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: Rational Unified Process

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

Page 17: Metodologia rup

ANÁLISIS DE SISTEMAS II

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

Page 18: Metodologia rup

ANÁLISIS DE SISTEMAS II

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.

 

3.3.2 Roles y Responsabilidades 

18 - 25

Page 19: Metodologia rup

ANÁLISIS DE SISTEMAS II

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 Proceso4.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

FaseNro.

IteracionesDuración

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 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

19 - 25

Page 20: Metodologia rup

ANÁLISIS DE SISTEMAS II

parte del cliente del artefacto Visión y el Plan de Desarrollo.

Fase de Elaboración

Se obtiene un entendimiento más detallado de los 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 Construcción

Durante la fase de construcción se terminan de analizar y 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.

Fase de InicioDuración: 4 semanas.

20 - 25

Page 21: Metodologia rup

ANÁLISIS DE SISTEMAS II

Actividad Semana Comienzo -

Semana Entrega

Criterio de culminación

Levantamiento de Información 1-3 (Finalizado) Esta fase culminará cuando se tengan al menos 90% de las actividades aquí mencionadas.

Detalles del proyecto 1-3 (Finalizado)Elaboración de página Web con artefactos

3-4 (Finalizado)

Plan de Iteración de la fase de elaboración

4-5 (Finalizado)

Creación del Plan inicial de Desarrollo del proyecto

2-4 (Finalizado)

Creación de documento Visión del sistema

3-4 (Finalizado)

Refinación del documento Visión del sistema

4-5 (Finalizado)

Modelos de Casos de Uso del Negocio

4-5 (Finalizado)

Lista inicial de Requerimientos 3-5 (Finalizado)Especificación de requerimientos funcionales y no funcionales

5-6 (Finalizado)

Lista inicial de riesgos asociados 4-6 (Finalizado)Glosario inicial del proyecto 5-6 (Finalizado)Prototipo de estructura del sistema

4-5 (Finalizado)

Elaboración del documento de arquitectura inicial.

4-5 (Finalizado)

Fase de ElaboraciónDuración: 6 semanas.

Actividad Semana Comienzo -Semana Entrega

Iteración Casos de Usos Implementados y Criterio de culminación de la iteración

Refinación y diagramas de los Casos de Uso del sistema

6-7 (Finalizado)

1 Casos de Uso:1. Ingresar Sistema2. Solicitar Asociación3. Listar Asociaciones pendientes4. Aceptar asociación5. Rechazar asociación6. Ver Asociación7. Ver Grados de Asociación8. Consultar Asociación9. Listar Sistemas10. Ver Sistema

Vista de Datos: Creación de Modelo Entidad Relación (ER)

7-8(Finalizado)

1

Vista Lógica: Modelo de Análisis

7-8(Finalizado)

1

Diagrama de Clases 8-9(Finalizado)

1

Diagrama de Secuencia 8-9(Finalizado)

1

Establecer casos de uso críticos del sistema.

7-7(Finalizado)

1

Refinación del documento de Arquitectura del Software

8-9(Finalizado)

1

21 - 25

Page 22: Metodologia rup

ANÁLISIS DE SISTEMAS II

11. Consultar estadísticas generales12. Modificar Sistema

Esta iteración 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%

Refinación del prototipo con los casos de uso críticos del sistema

10-12(Finalizado)

1

Plan de la segunda Iteración de la fase de elaboración

8-9(Eliminado)

1

Refinación de diagramas y de los casos de uso

9-12(Finalizado)

1

Refinación y actualización del plan de proyecto

11-12(Finalizado)

1

Fase de ConstrucciónDuración: 12 semanas.

Actividad Semana Comienzo -

Semana Entrega

Iteración Casos de Usos Implementados y Criterio de culminación de la

iteración

Plan de la primera Iteración de la fase de construcción

1-2 1Casos de Uso:

1. Finalización del módulo sistemas.

2. Refinación del módulo asociaciones.

3. Módulo de errores.

- Base de datos en un 100%- Sistema desarrollado en un 80%.- Manual completado en un 80%.

Refinamiento de los diagramas y la base de datos

1-2 1

Desarrollo del Sistema 1-6 1

Manual del Usuario 5-6 1

Ajustes al Sistema 7-7 1Pruebas 1-7 1Plan de la segunda Iteración de la fase de construcción

6-7 1

Refinamiento de los diagramas y la base de datos

7-8 2Casos de Uso:

1. Manejo de la seguridad2. Refinación módulo de

errores.3. Gráficos asociacionesSe han realizado todas las pruebas para asegurar que el sistema está libre de errores.

Pruebas 8-12 2Desarrollo del Sistema 6-11 2Culminación del manual de usuario

10-11 2

Corrección de errores 8-11 2

22 - 25

Page 23: Metodologia rup

ANÁLISIS DE SISTEMAS II

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

Page 24: Metodologia rup

ANÁLISIS DE SISTEMAS II

4.4 Plan de Manejo de RiesgosPara 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ónPara 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 RUP proveen una fácil ejecución del proceso de elaboración de un Sistema de Software, ya que describen cómo 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 metodología RUP y UML ya que permite lograr de una manera fiable y rápida el desarrollo del Sistema deseado.

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

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 visión unificada 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 y responsabilidades dentro de una organización del desarrollo, con la cual se puede mantener una fácil administración de este proceso.

24 - 25

Page 25: Metodologia rup

ANÁLISIS DE SISTEMAS II

2. Para obtener un máximo control de variables que conlleva un desarrollo de aplicaciones y poder mantener una ordenada implementación de éstas, es importante seguir metodologí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, es importante la utilización 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 implementació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 de Software. New York: Editorial Mc Graw Hill.

5. Kruchten, P. (1995). Architectural Blueprints—the “4+1” View Model of Software Architecture. IEEE Software.

6. Marcos, E. (2005). “Investigación en Ingeniería 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). GUÍA METODOLÓGICA DE DESARROLLO DE SISTEMAS10. 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 de noviembre.

25 - 25