GESTION DE PROYECTOS

DE TI
RUP-UML
OBJETIVOS

El alumno ser capaz de comprender los siguientes

temas:

RUP
 Caractersticas
 Fases
 Disciplinas
 Artefactos
 Roles

UML
 Diagramas usados en UML 1.X y UML 2.0
IBM(R) Rational Unified Process(R)
PRINCIPALES ARTEFACTOS RUP

Disciplina Artefacto Inicio Elaboracin Construccin Transicin

Administracin de Plan de Desarrollo I R R R
Proyecto
Lista de Riesgos I R R R
Requisitos Modelo de Casos de Uso I R
Visin I R
SRS I R
Glosario I R
Anlisis y Diseo Modelo de Diseo I R
Documento de Arquitectura I
de SW
Modelo de Datos I R
Implementacin Modelo Implementacin I R R
Pruebas Plan de Pruebas I R R
Despliegue Plan de Despliegue I

I = Inicio, R= Refinamiento
Caractersticas de RUP
CARACTERISTICAS DEL RUP

<<communicate>>

Consulta
Administrador
<<extend>>

Identificacion

Dirigido por los

Casos de Uso

Centrado en la Iterativo e
Arquitectura Incremental
DIRIGIDO POR CASOS DE USO

Un caso de uso es un fragmento de

funcionalidad del sistema que proporciona un
resultado de valor a un usuario. Los casos de
uso modelan los requerimientos funcionales del
sistema.

Los casos de uso tambin guan el proceso de
desarrollo (diseo, implementacin y pruebas).

De este modo los casos de uso no solo inician el
proceso de desarrollo sino que le proporcionan
un hilo conductor, que avanza a travs de una
serie de flujos de trabajo.
DEPENDENCIA ENTRE LOS CASOS DE USO Y LOS DEMS
MODELOS

<<communicate>>

Consulta
Administrador
<<extend>>

Identificacion
Especificado por Realizado por Distribuido por Implementado por

Modelo de anlisis Modelo de diseo Verificado por

Modelo de despliegue Modelo de

implementacin
X
OX

X
OX
X
OX

Modelo de prueba
ITERATIVO E INCREMENTAL

El esfuerzo de desarrollo de un proyecto de

software se divide en partes mas pequeas o
mini proyectos.

Cada mini proyecto es una iteracin que resulta
en un incremento.

Las iteraciones deben seleccionarse y ejecutarse
de forma planificada. Esta seleccin se basa en
dos cosas:

El conjunto de casos de uso que amplan
funcionalidad

En los riesgos mas importantes que deben
mitigarse
APLICANDO CASCADA ITERATIVAMENTE

Iteracin 1 Iteracin 2 Iteracin 3

R R R
D D D
C C C
T T T

T I EMPO

Las primeras iteraciones reducen los principales riesgos

Cada iteracin produce una versin ejecutable, un incremento
adicional al sistema

Cada iteracin incluye integracin y test
CENTRADO EN LA ARQUITECTURA

La arquitectura se describe mediante diferentes

vistas del sistema en construccin.

Incluye aspectos estticos y dinmicos.

La arquitectura es una vista del diseo completo
con las caractersticas ms importantes
resaltadas, dejando de los detalles de lado.

La arquitectura debe permitir el desarrollo de
todos los casos de uso requeridos actualmente y
a futuro, y los casos de uso deben encajar en la
arquitectura.
QUE ES UN MODELO?

Un Modelo es
una Simplificacin de la Realidad
POR QU DEBE MODELARSE UN SOFTWARE?

Disear un modelo para sistemas de software es

tan fundamental como tener un modelo para
una construccin grande. Los buenos modelos:
 Identifican requerimientos y comunican
informacin
 Se enfocan en como interactan los
componentes sin necesidad de detalles
 Permite visualizar las relaciones entre
componentes de diseo
 Mejor la comunicacin entre un equipo de
desarrollo a travs del uso de un lenguaje
grfico comn
UNIFIED MODELING LANGUAGE (UML)

Qu es UML?

Es un estndar notacional empleado para
modelar y representar sistemas de software y
sus partes desde distintas perspectivas,
generando diagramas o artefactos.

Etapas donde se utiliza UML

 Requerimientos
 Anlisis
 Diseo
 Implementacin
DIAGRAMAS UML 1.X

State
State
Use Case Diagramas de
Diagrams
Use Case Diagrams State
Use Case Diagramas de
Diagrams Clases State
Use Case Diagrams Diagramas de
Diagrams
Diagramas de
Diagrams Casos de Uso Diagrams
Diagrams Objetos
Secuencia

Scenario State
Scenario State
Diagramas de
Diagrams Diagramas de
Diagrams
Diagrams Diagrams
Colaboracin Modelos Componentes

Scenario Component
Scenario Component
Diagramas
Diagrams
Diagramas de
Diagrams
Diagrams Diagrams de
Estados Diagramas de Distribucin
Actividad
DIAGRAMAS UML 2.0

Diagrama de Diagramas de
Maquina de Estados Casos de Uso
Diagrama de
Diagrama de Clases
Actividad Diagrama de
Objetos
Diagrama de
Secuencia
Diagrama de
Diagrama Visin Despliegue
de Interaccin
Modelos
Diagrama de
Diagrama Componentes
de Tiempos

Diagrama Diagrama de Diagrama de Estructura

de Comunicacin Estructura Paquete Compuesta
ARQUITECTURA DE SOFTWARE

Captura los aspectos estratgicos de la

estructura de alto nivel de un sistema

Abarca un conjunto de decisiones significativas
acerca de la organizacin de un sistema.
Involucra:
 Seleccin de elementos que componen un
sistema y las interfaces entre ellos.
 El comportamiento, especificado a travs de
colaboraciones entre esos elementos.
 Funcionalidad, desempeo, control de errores
y persistencia.
ORGANIZACIN DE MOLELOS

Vistas de UML: Arquitectura 4 + 1

5 Vistas

9 Diagramas
MODELO DE VISTAS 4+1

Creado por Philippe Kruchten(1995), vinculado

al Rational Unified Process (RUP), que define
cuatro vistas diferentes:
 La vista estructural o lgica. Provee una
descripcin esttica de las clases primarias y
sus relaciones
 La vista de implementacin. Para mostrar
cmo el cdigo se organiza en paquetes y
bibliotecas y el uso de software estndar
comercial
MODELO DE VISTAS 4+1

 La vista de comportamiento. Para mostrar los

procesos y las tareas
 La vista de ambiente o de despliegue, para
mostrar los procesadores, dispositivos y
enlaces en el medio operacional

Existe una quinta vista, la de usuario, que
consiste en una seleccin de casos de uso o de
escenarios que los arquitectos pueden elaborar a
partir de las cuatro vistas anteriores.
ORGANIZACIN DE MODELOS
FASES DEL RUP
FASE DE INICIO (INCEPTION)

Durante la fase de inicio se desarrolla la

descripcin del producto final, y se presenta el
anlisis del negocio.

Esta fase responde las siguientes preguntas:
 Cules son las principales funciones del
sistema para los usuarios mas importantes?
 Cul es el plan del proyecto y cuanto costar
desarrollar el producto?

En esta fase se identifican y priorizan los riesgos
mas importantes.
WORKFLOW
FASE DE INICIO (INCEPTION)

Artefactos
Un documento de visin Caso de negocio:
general:
Contexto
Requerimientos generales
Criterios de xito
del proyecto
Pronstico financiero
Caractersticas principales
Identificacin inicial de
Restricciones
riesgos.
Modelo inicial de casos de
Plan de proyecto.
uso (10% a 20 % listos).
Uno o ms prototipos.
Glosario.
FASE DE INICIO (INCEPTION)

Hito:
Objetivos del
Ciclo de Vida

Inicio Elaboracin Construccin Transicin

Las partes interesadas deben acordar el

alcance y la estimacin de tiempo y costo.
Comprensin de los requerimientos plasmados
en casos de uso.
FASE DE INICIO (INCEPTION)
NUEVO PROYECTO

Paso previo para

identificar el problema a
solucionar
EL STAKEHOLDER

Es un rol que es responsable por representar a

un grupo de inters, cuyas necesidades deben
ser satisfechas por el proyecto.

El papel puede ser desempeado por alguien
que es (o ser potencialmente) afectado por el
resultado del proyecto
EL STAKEHOLDER

Muchos de los interesados son usuarios del sistema. Otros

son slo usuarios indirectos del sistema o se ven afectados
slo por los resultados del sistema. La comprensin de
quines son los interesados y sus necesidades son
elementos clave en el desarrollo de una solucin eficaz.

Ejemplos de Stakeholders:
 Clientes o representante del cliente, Usuarios
o usuario representante, Inversionistas,
 Accionistas, Propietarios o miembro de la
Junta, Gerentes, Compradores,
 Diseadores, Tester, Documentadores, entre
otros.
DOCUMENTO VISION

Requerimiento Inicial del Mi problema es

o de los Stakeholder la lentitud en la

Desde el punto de vista atencin ..
del Analista se analiza
los requerimientos
iniciales y se realiza la
visin inicial de lo que
ser la Aplicacin Final
Stakeholder

Analista
EJEMPLO: Requerimiento Stakeholder

La Gerente de los un restaurant, nos hace el siguiente

requerimiento:

Necesita que se generen automticamente los requerimientos de
compra de productos de acuerdo a la venta de platos del da

Personalizar la venta de los platos y que su precio se calcule de
forma automtica

Se requiere tener una gestin de mesas de forma grafica.

Control de stock por unidades, envases y medidas (Administrar
un conjunto de unidades de medida y sus respectivas
conversiones)

Gestionar clientes, proveedores y productos

Estadsticas de venta y de compra.

Ventas Delivery por WEB y telfono. Gestin y recepcin de
pedidos
Nota: Adems el restaurante cuenta con un sistema de facturacin
(Visual Basic 6.0 y SQL 2000), este sistema solo se tiene los
ejecutables, por lo que no se puede modificar. Esto solo corre en
la mquina de caja
PROYECTO

Versi
Versin 1.0

Una vez realizada la
Visin el Jefe de
Proyecto evala los
riesgos, los costos, realiza
el plan de desarrollo de
software y el plan de
iteracin del proyecto para
la fase de inception.

Lista de Riesgos
Caso de Negocio
Plan de Desarrollo de Software
Plan de Iteracin para inception
CASO DE NEGOCIO

El Caso de negocio ofrece la informacin

necesaria desde un punto de vista empresarial
para determinar si procede o no este proyecto o
si vale la pena o no invertir en l.

Para que un producto de software sea valido, los
negocios debe incluir una serie de supuestos
sobre el proyecto y el orden de magnitud de
retorno de la inversin (ROI).

Por ejemplo, el retorno de la inversin ser de
una magnitud de cinco si sta ha sido
completada en un ao, dos si sta ha sido
completada en dos aos, y un nmero negativo
despus de eso.
ESTRUCTURA DE UN DOCUMENTO CASO DE NEGOCIO

1. INTRODUCCIN
1.1 Propsito
1.2 Alcance
1.3 Definiciones, Acrnimos y Abreviaturas
1.4 Referencias
1.5 Descripcin
2. DESCRIPCIN DEL PRODUCTO
3. CONTEXTO DEL NEGOCIO
4. OBJETIVOS DEL PRODUCTO
5. PRONSTICO FINANCIERO
6. RESTRICCIONES
LISTA DE RIESGOS

En el desarrollo de Sw. un riesgo es una variable

que puede tomar un valor que pueda disminuir
la probabilidad de xito en un proyecto o
eliminarla por completo.

EL RUP cuenta con un documento que clasifica e
identifica los riesgos para poder ser mitigados.
EJEMPLO
PLAN DE DESARROLLO DE SOFTWARE

El Plan de Desarrollo de Software es un proceso

global, compuesto por un artefacto que rene
toda la informacin necesaria para administrar el
proyecto.

Incluye una serie de artefactos desarrollados
durante la fase inicial y se mantiene a lo largo
del proyecto.
PLAN DE PROYECTO ITERATIVO

Preguntas
 Cuntas iteraciones se necesitan?
 Cuan larga debe ser una iteracin?
 Cmo se determina el contenido y objetivos
para una iteracin?
 Cmo realizar un seguimiento a una
iteracin?
 Asignacin de tareas y responsabilidades del
equipo
PLAN DE PROYECTO ITERATIVO

Las primeras iteraciones (en las fases de Inicio y

Elaboracin) se enfocan hacia:
 La compresin del problema y la
tecnologa
 La delimitacin del mbito del proyecto
 La eliminacin de los riesgos crticos
 Al establecimiento de una baseline de
la arquitectura.
PLAN DE PROYECTO ITERATIVO

Elaboracin de 2 dimensiones de planes

 Plan de Fases
 Plan de Iteracin

Consideraciones especiales
 Ambos planes deben tener en cuenta el factor
riesgo (evitarlo, transferirlo o aceptarlo), lo
cual implica elaborar actividades para
disminuir el riesgo o definir un plan de
contingencia
 Tener presente mtricas para medir
cumplimiento de objetivos
EL PLAN DE FASES

Contenido

Fechas de los principales puntos de control
 Fecha Fin de la Etapa Inception con el proyecto bien definido
 Fecha Fin de la Etapa Elaboration con las Arquitectura
terminadas
 Fecha Fin de la Etapa Construction con la versin beta
 Fecha Fin de la Etapa Transition con la versin final del
Producto

Definicin de perfiles del Staff

Fechas de menores puntos de control
 Fecha Fin de cada iteracin y sus principales objetivo

Se debe tener presente lo siguiente para la definicin de fechas
 Existen arquitecturas ya desarrolladas
 Cantidad de riesgos que necesitan
 Experiencia del equipo
 Desarrollo complejo
EL PLAN DE ITERACIN

Contenido

Siempre existen dos planes de iteracin activas
 El plan de la iteracin actual, se utiliza
para realizar un seguimiento
 El plan de la siguiente iteracin, se afina
en base a la presente iteracin

Una iteracin es como un mini-proyecto con
tiempos, asignacin de tareas y cuyo producto es
una versin del SW a revisar

Fechas de menores puntos de control
 Fecha Fin de cada iteracin y sus
principales objetivos
EL PLAN DE ITERACIN

Contenido

Definicin de la duracin de una iteracin
 Cultura organizacional
 Nivel de automatizacin del equipo de
SW
 Distribucin de la informacin
 Experiencia en pruebas

Nmero de iteraciones
 Anlisis por Fases o Etapa
EL PLAN DE ITERACIN

Pasos para elaborar el plan de iteracin

 Definir los objetivos de xito de cada iteracin

Permite realizar un control de la iteracin

Permite costear
 Identificar los artefactos que se necesitarn elaborar o
actualizar y las actividades para realizar las operaciones
mencionadas
 Ordenar y priorizar las actividades acorde con los
recursos
 Utilizar estimaciones para asignar tiempos para cada
actividad
ENTORNO DEL PROYECTO
EJEMPLO: Herramientas de soporte al proyecto

Word
 Formato de los entregables,
 Tabla de contenido
 Encabezados y pie de pagina
 Estructura de documentos

Project
 Diagrama de Gantt
 Diagrama de Recursos

Microsoft Visio for Enterprise Architect
 Modelos (Diagramas UML)
FASE DE ELABORACION

Se especifican en detalle la mayora de los casos de uso y

se disea la arquitectura.

Las iteraciones en la fase de elaboracin:
 Establecen una firme comprensin del
problema a solucionar.
 Establece un plan detallado para las siguientes
iteraciones.
 Elimina los mayores riesgos.

El resultado de esta fase es la lnea base de la
arquitectura.
WORKFLOW
FASE DE ELABORACION

Los objetivos son:

 Recopilar la mayor parte de los requisitos
definindolos como casos de uso
 Establecer una lnea base de la arquitectura
guiar el trabajo en las fases posteriores
 Continuar la observacin y control de los
riesgos crticos
Para ello
Se toman decisiones considerando:
requisitos funcionales y no funcionales
FASE DE ELABORACION

Artefactos:

Modelo de casos de uso Un prototipo ejecutable

(80% completo) con de la arquitectura.
descripciones detalladas.
Lista revisada de riesgos
Otros requerimientos no y del caso de negocio.
funcionales o no asociados
Plan de desarrollo para el
a casos de uso.
resto del proyecto.
Descripcin de la
Un manual de usuario
Arquitectura del Software.
preliminar.
FASE DE ELABORACION

Hito: Arquitectura de
Ciclo de Vida

Concepcin Elaboracin Construccin Transicin

Condiciones de xito de la elaboracin:

Es estable la visin del producto?
Es estable la arquitectura?
Las pruebas de ejecucin demuestran que los riesgos
han sido abordados y resueltos?
Estn de acuerdo con el plan todas las personas
involucradas?
FASE DE CONSTRUCCIN

En esta fase todas los componentes restantes se

desarrollan e incorporan al producto.

Todo es probado a profundidad.

El nfasis est en la produccin eficiente y no ya
en la creacin intelectual.

Puede hacerse construccin en paralelo, pero
esto exige una planificacin detallada y una
arquitectura muy estable.
FASE DE CONSTRUCCIN

Los objetivos son:

 Lnea base de la arquitectura crece hasta
convertirse en el sistema completo
 Riesgos reducidos o rutinarios
 Implementacin de los casos de uso
 Prototipo
Para ello
A travs de sucesivas iteraciones e
incrementos se desarrolla un producto
software, listo para operar, ste es
frecuentemente llamado versin beta
FASE DE CONSTRUCCIN

ARTEFACTOS:
 El producto de software integrado y
corriendo en la plataforma adecuada.
 Manuales de usuario.
 Una descripcin del release actual.
FASE DE CONSTRUCCION

Hito: Capacidad
Operacional

Concepcin Elaboracin Construccin Transicin

Se obtiene un producto Beta que debe decidirse si

puede ponerse en ejecucin sin mayores riesgos.
Condiciones de xito:
El producto est maduro y estable para instalarlo en
el ambiente del cliente?
FASE DE TRANSICIN

Los objetivos son:

 Cumplir los requisitos de fases anteriores
 Gestionar todos los aspectos de implantacin
 Pruebas de aceptacin

Para ello
Las iteraciones en esta fase continan
agregando caractersticas al sw.
El equipo se encuentra ocupado en corregir
y extender la funcionalidad del sistema
desarrollado en la fase anterior.
FASE DE TRANSICIN

El objetivo es traspasar el software desarrollado

a los usuarios.

Incluye:
 Pruebas Beta para validar el producto con las
expectativas del cliente
 Ejecucin paralela con sistemas antiguos
 Conversin de datos
 Entrenamiento de usuarios
 Distribuir el producto
FASE DE TRANSICIN

Hito:
Producto

Concepcin Elaboracin Construccin Transicin

Condiciones de xito:
Se han alcanzado los objetivos fijados en
la fase de Inicio ?
El usuario est satisfecho ?
Disciplinas y Flujos de
Trabajo
 DISCIPLINAS Y FLUJOS DE TRABAJO

Disciplinas de
Proceso

Disciplinas
de Soporte
DISCIPLINAS

Una disciplina es una coleccin de actividades

relacionadas vinculadas con un rea especfica
del proyecto.

Facilitar la comprensin del proyecto desde la
perspectiva tradicional del modelo en cascada.
FLUJO DE TRABAJO

Describe la secuencia en que se realizan las

actividades en una disciplina, quienes la realizan
(trabajadores) y que artefactos producen..
DISCIPLINAS DE SOPORTE

1. Gestin de configuraciones: controla los cambios y

mantiene la integridad de los artefactos de un proyecto.
2. Gestin del Proyecto: describe varias estrategias de
trabajo en un proceso iterativo.
3. Entorno: cubre la infraestructura necesaria para
desarrollar un sistema.
ADMINISTRACIN Y CONFIGURACIN DE CAMBIOS

Forma de controlar los artefactos producidos por

las personas que trabajan en el proyecto.

Algunos problemas habituales:
 Actualizaciones simultneas
 Mltiples versiones

RUP da guas para:
 Desarrollos en paralelo
 Automatizar la construccin
 Administrar defectos
ADMINISTRACIN DEL PROYECTO

Es el arte de balancear objetivos contrarios, manejar

riesgos y producir software que satisface a clientes y
usuarios.
Existen pocos proyectos realmente exitosos.
RUP incluye:
Un framework para manejo de proyectos de
software
Guas para planificacin, provisin de personal,
ejecucin y monitoreo de planes
Un framework para manejar riesgos
DISCIPLINAS DE PROCESO

1. Modelado del negocio: describe la estructura y la

dinmica de la organizacin.
2. Requisitos: describe el mtodo basado en casos de uso
para extraer los requisitos.
3. Anlisis y diseo: describe las diferentes vistas
arquitectnicas.
DISCIPLINAS DE PROCESO

4. Implementacin: tiene en cuenta el desarrollo de

software, la prueba de unidades y la integracin.
5. Pruebas: describe los casos de pruebas, los
procedimientos y las mtricas para evaluacin de defectos.
6. Despliegue: cubre la configuracin del sistema
entregable.
Modelado de Negocio

Disciplina RUP
MODELADO DE NEGOCIO

El objetivo es entender la estructura y la dinmica del

negocio.

Se elabora un Modelo de Casos de Uso del Negocio
describe los proceso de negocio de una empresa en
trminos de

Casos de uso del negocio y

Actores del negocio

que se corresponden con los procesos del
negocio y los clientes respectivamente .
ACTIVIDADES DEL MODELO DE NEGOCIO
ARTEFACTOS
Requerimientos
REQUERIMIENTOS EN LAS PRIMERAS FASES

Inicio
Elaboracin
 Usa el lenguaje del  Usa el lenguaje de
Cliente los desarrolladores
 Descripcin de los  Se refinan los
CU en lenguaje requisitos.
natural,
 Se estructuran los
 Se usan Diagramas requisitos en base a
de actividad. clases y paquetes.
 Vista externa del  Vista interna del
sistema. sistema.
 RUP - WORKFLOW DE REQUERIMIENTOS

Encontrar Actores
Analista de Sistemas y Casos de Uso
Estructurar el Modelo
de Casos de Uso

Arquitecto Priorizar
los Casos de Uso

Detallar
Especificador CU los Casos de Uso

Diseador de Interfaz Prototipar

de usuario la Interfaz de Usuario
ACTIVIDADES - REQUERIMIENTOS
ARTEFACTOS - REQUERIMIENTOS
Anlisis y Diseo
Refinamiento de los Casos de Uso

Modelamiento del
negocio
(Casos de Uso)

Requerimientos
(Detalle Caso Uso)

Anlisis y Diseo
(Clases y diagrama
de secuencias)
ACTIVIDADES DE ANALISIS Y DISEO
ARTEFACTOS DE ANALISIS Y DISEO
Componentes de una Arquitectura Fsica
Implementacin
IMPLEMENTACIN - ACTIVIDADES
IMPLEMENTACIN - ARTEFACTOS
IMPLEMENTACION

Trabajador Responsable de (artefacto)

Arquitecto Modelo de implementacin
Modelo de despliegue
Descripcin de la arquitectura

Integrador de sistema Plan de integracin de

construccin
Ingeniero de Componentes Componente
Implementacin de subsistema
Interfaz
DIAGRAMA DE COMPONENTES
Pruebas
PRUEBAS

Los objetivos de la prueba son:

 Planificar las pruebas necesarias en cada
iteracin, incluyendo las pruebas de
integracin y las pruebas de sistema.
 Disear e implementar pruebas creando:

Casos de prueba (especifican qu probar),
Procedimientos de prueba (especifican cmo realizar
las pruebas),

Componentes de prueba para automatizar las
pruebas.
 Realizar las pruebas.
ACTIVIDADES
ARTEFACTOS
Despliegue
DESPLIEGUE

Producir un producto y hacerlo llegar a sus

usuarios finales.

Incluye varias actividades:
 Producir un release
 Empaquetar el software
 Distribuir el software
 Realizar pruebas beta
 Instalar el software
 Apoyar a los usuarios
 Migracin de datos
ACTIVIDADES
ARTEFACTOS
Conclusiones
CONCLUSIONES

La aplicacin formal del Proceso Unificado supone:

 Desventajas:

Grandes esfuerzos en la construccin de
modelos.

Necesidad del soporte de herramientas
informticas.
 Ventajas:

Disminuye el riesgo del error de anlisis /
diseo acumulado.

Aligera el esfuerzo en implementacin.

Proporciona la documentacin del ciclo de
vida en el mismo proceso.
CONCLUSIONES

El Proceso Unificado es flexible y se puede

adaptar al grado de complejidad del modelo de
proceso de desarrollo (descarte de algunos
modelos o flujos).

El Proceso Unificado es abierto y permite la
incorporacin de enfoques y artefactos
complementarios:
 Patrones de diseo.
 Patrones de implementacin.
 Combinacin de varios modelos de proceso.
 Arquitecturas Dirigidas por Modelos (Model
Driven Architectures).
BIBLIOGRAFIA

1. Booch G., Rumbaugh J., Jacobson I. El Lenguaje Unificado de Modelado,

Addison-Wesley, Madrid, 1999.
2. Bruegge B., Dutoit A.H. Ingeniera de Software Orientado a Objetos, Prentice
Hall Pearson educacin, Mxico, 2002.
3. Jacobson I., Booch G., Rumbaugh J. El Proceso Unificado de Desarrollo de
Software, Addison-Wesley, Madrid, 2000.
4. Pressman R.S. Ingeniera del Software. Un enfoque prctico (5 ed.) Mc
Graw-Hill; New York , 2001.
5. Rumbaugh J., Jacobson I., Booch G. El Lenguaje Unificado de Modelado.
Manual de Referencia, Addison-Wesley, Madrid, 2000.
6. Sommerville I. Ingeniera de software, 6 edicin, Prentice Hall Pearson
educacin, Mxico, 2002.
7. Stevens P., Pooley R. Utilizacin de UML en Ingeniera del Software con
Objetos y Componentes, Addison-Wesley, Madrid, 2002.