Você está na página 1de 36

Qu es el UML?

El Lenguaje Unificado de Modelado (Unified Modeling Language) es un


lenguaje que unifica las mejores prcticas de ingeniera que existen actualmente
en la industria para el modelado de sistemas.
Se utiliza para especificar, visualizar, construir y documentar sistemas.
Est basado en el paradigma orientado a objetos.
El UML es la creacin de Grady Booch, James Rumbaugh e Ivar
Jacobson, quienes durante la dcada de los ochentas y noventas disearon cada
quin por su cuenta, y trabajando para empresas distintas, su propia metodologa
para el anlisis y diseo orientado a objetos (Booch, OMT y OOSE
respectivamente). Estos trabajos se convirtieron por esa poca en los ms
influyentes en el rea del modelado de sistemas. A mediados de los aos noventa
empezaron a intercambiar ideas entre s y decidieron desarrollar su trabajo en
conjunto.
En 1994 Rumbaugh ingres a trabajar en Rational Software Corporation,
en donde ya trabajaba Booch. Jacobson ingres en 1995, desde entonces
Rational se ha convertido en la principal empresa en la produccin de
herramientas para el rea de procesos de ingeniera del software y el UML es el
estndar de facto para la industria del software.
En 1997 se liber la versin 1.0 del UML, actualmente se encuentra en la
versin 2.0.
Diagramas del UML
El UML est compuesto por diversos elementos grficos que se combinan
para formar diagramas, los cuales se dividen en los siguientes tipos:

Diagrama de Casos de Uso


Diagrama de Objetos
Diagrama de Secuencias
Diagrama de Estados
Diagrama de Distribucin

Diagrama de Clases
Diagrama de Actividades
Diagrama de Colaboraciones
Diagrama de Componentes

Cada uno de estos diagramas contienen clasificadores, los cuales son


mecanismos que describen caractersticas estructurales y de comportamiento,
ejemplos de estos mecanismos son: clases, interfaces, tipos de datos,
componentes, nodos, casos de uso y subsistemas.
Adems el UML tambin cuenta con elementos de organizacin y extensin
del lenguaje: Paquetes, Notas, Estereotipos.

Diagramas de Casos de Uso


Comportamiento del Sistema
El comportamiento del sistema en desarrollo se documenta en un modelo
de casos de uso, el cual muestra las funciones que el sistema debe cumplir, su
entorno (actores) y las relaciones entre los casos de uso y los actores (diagrama
de casos de uso). El papel ms importante de un modelo de casos de uso es el de
comunicar. Provee un medio utilizado por los clientes o usuarios finales y los
desarrolladores para discutir la funcionalidad y comportamiento del sistema.
Actores
Los actores NO son parte del sistema, representan cualquier ente que
debe interactuar con el sistema. Un actor puede:

Slo meter informacin al sistema


Slo recibir informacin del sistema
Captar y recibir informacin al y desde el sistema.

Comnmente los actores se identifican en el enunciado del problema y por


las conversaciones con los clientes y con los expertos en el dominio del problema.
Las siguientes preguntas pueden ayudar a identificar a los actores de un sistema:

Quin est interesado en cierto requerimiento?


En qu parte de la organizacin va a ser utilizado el sistema?
Quin se beneficiar de la utilizacin del sistema?
Quin proveer al sistema con esta informacin, usar esta informacin y
borrar esta informacin?
Quin mantendr el sistema?
El sistema utiliza un recurso externo?
Una misma persona juega diferentes papeles (roles)?
Varias personas juegan un mismo papel (rol)?
El sistema interacta con un sistema legado?
En UML, un actor se representa tal como se muestra en la imagen.

Documentacin de actores
El modelo deber contar con una breve descripcin para cada actor. La
descripcin deber identificar el rol que desempea el actor mientras interacta
con el sistema.

Casos de Uso
Los casos de uso modelan un dilogo entre los actores y el sistema.
Representan la funcionalidad que provee el sistema, esto es, las habilidades que
el sistema le proveer a un actor. La coleccin de los casos de uso de un sistema
constituyen todas las formas definidas en las que el sistema puede ser utilizado.
La definicin formal de un caso de uso es: Un caso de uso es una secuencia de
transacciones realizadas por un sistema que arrojan un resultado medible de
valores para un actor particular.
Las siguientes preguntas pueden ser utilizadas para ayudar a identificar los
casos de uso de un sistema:

Cules son las tareas de cada actor?


Cualquier actor leer, agregar, modificar o borrar informacin en el
sistema?
Cul caso de uso se encargar de leer, agregar, modificar o borrar esta
informacin?
Cualquier actor necesita informar al sistema acerca de cambios externos
repentinos?
Cualquier actor necesita ser informado acerca de ciertas ocurrencias en el
sistema?
Qu casos de uso mantendrn el sistema?
Todos los requerimientos funcionales pueden ser llevados a cabo por los
casos de uso?

Una regla para identificar un buen caso de uso es la siguiente: Un caso de uso
representa una pieza mayor de funcionalidad que est completa de principio a fin.
Un caso de uso debe entregar algo de valor a un actor.
En UML, un caso de uso se representa por un valo, tal como se muestra en
la Figura.

Documentacin de los Casos de Uso


Enuncia el propsito del caso de uso en pocas frases, constituye una
definicin de alto nivel de la funcionalidad que provee el caso de uso.
El flujo de eventos del caso de uso:
Cada caso de uso tambin es documentado con un flujo de eventos. El flujo
de eventos es una descripcin de los eventos necesarios para llevar a cabo el
comportamiento requerido del caso de uso. El flujo de eventos se redacta en

trminos del qu debe hacer el sistema y no del cmo lo debe hacer. Esto es, se
escribe en el lenguaje del dominio no en trminos de la implementacin. El flujo de
eventos debe incluir:

Cundo y cmo el caso de uso inicia y termina.


Qu interaccin tiene el caso de uso con los actores.
Qu datos necesita el caso de uso
La secuencia normal de eventos para el caso de uso.
La descripcin de cualquier flujo alterno o excepcional.
Un formato comnmente utilizado es el siguiente:

1. Flujo de Eventos para el Caso de Uso <nombre>


1.1. Precondiciones
1.2. Flujo principal
1.3. Subflujos
1.4. Flujos alternos
1.5. Postcondiciones
Relaciones de los Casos de Uso
Una relacin de asociacin puede existir entre un actor y un caso de uso.
Este tipo de relaciones se denominan asociaciones de comunicacin ya que
representan la comunicacin entre un actor y un caso de uso. Una asociacin
puede ser navegable en ambas direcciones o puede ser navegable en una sola
direccin. La direccin de navegacin de una asociacin representa quin est
iniciando la comunicacin. Una asociacin se representa como una lnea que
conecta a los elementos relacionados. La navegacin en una sola direccin se
representa con una flecha.
Existen dos tipos de relaciones que se pueden dar entre los casos de
uso: include y extend.
La relacin include se da entre dos casos de uso cuando uno de ellos
representa funcionalidad que se comparte con otros casos de uso. La asociacin
se representa con una flecha que va desde el caso de uso base hacia el caso de
uso incluido (el que comparte funcionalidad). Ver Figura 3.
La relacin extends se usa para mostrar:
Comportamiento opcional
Comportamiento que se ejecuta slo bajo ciertas circunstancias, tales como
disparar una alarma.
Varios flujos diferentes pueden ser ejecutados basados en la seleccin del
actor.

Este tipo de asociacin se representa como una flecha que apunta del caso de
uso extendido al caso de uso base.

El UML tiene un concepto llamado estereotipo, el cual provee la capacidad


de extender los elementos bsicos de modelado para crear nuevos elementos. De
esta forma, el concepto de estereotipo permite al UML tener un conjunto mnimo
de smbolos que pueden ser extendidos donde se requiera contar con artefactos
de comunicacin que tengan significado para el sistema en desarrollo. Los
nombres de los estereotipos se incluyen entre los smbolos << >> y se ubican
sobre las lneas de relacin. Los estereotipos se utilizan para crear las relaciones
necesarias para los casos de uso.
Diagramas de Casos de Uso
Un diagrama de casos de uso es la vista grfica de algunos o todos los actores,
casos de uso y relaciones identificadas para un sistema. Cada sistema
comnmente tiene un diagrama de casos de uso principal, el cual nos da una
visin de los lmites del sistema (actores) y la funcionalidad ms importante que
provee el sistema (casos de uso). Adems se pueden crear diagramas de casos
de uso que nos muestren todos los casos de uso en los que participa un actor,
todos los actores que participan en un caso de uso o los casos de uso que se
implementarn en una iteracin especfica del desarrollo.
Diagramas de Actividades
Los diagramas de actividades representan la dinmica del sistema. Son
diagramas utilizados para mostrar el flujo de trabajo de un sistema, esto es,
muestran el flujo del control en el sistema conforme pasa de una actividad a otra,
cuales actividades pueden ser llevadas a cabo en paralelo, y cualquier trayectoria
alternativa del flujo.

En la etapa inicial (inception) del proyecto, los diagramas de actividades


pueden ser creados para representar el flujo entre casos de uso, o para
representar el flujo dentro de un caso de uso en particular.
En las etapas avanzadas del proyecto, los diagramas de actividades
pueden ser creados para mostrar el flujo de una operacin en el diseo del
sistema.
Los diagramas de actividades contienen actividades, transiciones entre
actividades, puntos de decisin, y barras de sincronizacin. En el UML las
actividades se representan como rectngulos con bordes redondeados, las
transiciones son flechas dirigidas, los puntos de decisin son rombos, y las barras
de sincronizacin se representan como lneas gruesas horizontales o verticales.

Actividades
Una actividad representa la ejecucin de algn tipo de comportamiento en
el flujo de trabajo.
Transiciones
Las transiciones son utilizadas para mostrar el paso del control de una
actividad a otra. Son disparadas al finalizar el completarse la actividad que la
origina.

Puntos de Decisin
Cuando se modela el flujo de trabajo de un sistema usualmente es
necesario mostrar cuando el flujo del control tiene que cambiar debido a una
decisin. Las transiciones relacionadas con un punto de decisin contienen una
condicion (guard condition), la cual es utilizada para determinar cul trayectoria se
tomar a partir del punto de decisin.
Barras de Sincronizacin
En un flujo de trabajo es comn que se presenten algunas actividades que
pueden ser llevadas a cabo en paralelo. Una barra de sincronizacin permite
especificar qu actividades se pueden llevar a cabo concurrentemente. Tambin
se utilizan para mostrar uniones en el flujo, esto es, qu actividades se tienen que
completar antes de que el procesamiento contine. De esta forma, las barras de
sincronizacin pueden tener muchas transiciones de entrada y una de salida, o
una de entrada y muchas de salida.
Marcos de responsabilidad (Swimlanes)
Los marcos de responsabilidad se utilizan para particionar un diagrama de
actividades. Esto se hace para mostrar qu persona u organizacin es
responsable de las actividades contenidas en el marco. Ver Figura 5
Actividades inicial y final
Existen smbolos especiales que son utilizados para mostrar las actividades inicial
y finales del flujo de trabajo. La actividad de inicio se muestra usando un crculo
relleno y las actividades finales por una diana.

Objetos
Un objeto es la representacin de una entidad, ya sea del mundo real o
conceptual. Un objeto puede representar algo concreto como el camin de Juan o
mi computadora, o un concepto tal como un proceso qumico, una transaccin
bancaria, una orden de compra, el historial crediticio de Mara o una tasa de
inters.
Un objeto es un concepto, abstraccin o cosa con significado y lmites bien
definidos para una aplicacin. Cada objeto en un sistema tiene tres caractersticas:
estado, comportamiento e identidad.
Estado, Comportamiento e Identidad
El estado de un objeto es una de las posibles condiciones en las cuales el
objeto puede existir. El estado de un objeto tpicamente cambia con el tiempo y
est definido por un conjunto de propiedades (llamadas atributos), junto con el
valor de estas propiedades ms las relaciones que el objeto pueda tener con otros
objetos. Por ejemplo, en un sistema de inscripcin de alumnos, el objeto curso
ofertado puede estar en uno de los dos estados: abierto o cerrado. Si el nmero
de estudiantes registrados para el curso ofertado es menor a 10, el estado del
curso ofertado es abierto. Cuando el dcimo estudiante se registre en ese curso
ofertado, el estado se convierte en cerrado.
El comportamiento determina cmo el objeto responde a los requerimientos
por parte de otros objetos y tipifica todo lo que el objeto puede hacer. El
comportamiento se implementa por el conjunto de operaciones del objeto. En el
sistema de inscripcin, el curso ofertado puede tener el comportamiento agregar
estudiante y borrar estudiante.
La identidad significa que cada objeto es nico an cuando su estado es
idntico al de otro objeto. Por ejemplo, Matemticas I y Matemticas II son dos
objetos en el sistema de inscripcin. An y cuando los dos son cursos ofertados,
cada uno tiene su identidad nica.
En UML, los objetos se representan como rectngulos y el nombre del
objeto est subrayado como se muestra.
Matemticas I

Clases
Una clase es una descripcin de un grupo de objetos con propiedades
comunes (atributos), comportamiento comn (operaciones), relaciones comunes
con otros objetos y semntica comn. De esta manera, una clase es una plantilla
(template) para crear objetos. Cada objeto es una instancia de alguna clase, y los
objetos no pueden ser instancias de ms de una clase. Por ejemplo, la clase
CursoOfertado puede estar definida con las siguientes caractersticas:

Atributos: saln, horario


Operaciones: Consulta saln, consulta horario, agrega estudiante, borra
estudiante.

Matemticas I y Matemticas II son objetos que pertenecen a la clase


CursoOfertado. Cada objeto tendr un valor para sus atributos y acceso a las
operaciones especificadas por la clase CursoOfertado.
Una buen clase captura una y solo una abstraccin, deber tener un slo
tema principal. Por ejemplo, una clase que tiene la capacidad de mantener la
informacin acerca de un estudiante y la informacin acerca de todos los cursos
ofertados que el estudiante ha tomado a lo largo de varios aos no es una buena
clase, ya que no est centrada en un tema principal. Esta clase deber ser dividida
en dos clases relacionadas: Estudiante e HistorialEstudiante.
Las clases debern ser nombradas utilizando el vocabulario del dominio. El
nombre deber ser un sustantivo singular que mejor caracterice la abstraccin.
En UML las clases se representan como rectngulos seccionados
horizontalmente. La primera seccin contiene el nombre de la clase, la seccin
media contiene la estructura de la clase (atributos) y la seccin baja contiene el
comportamiento de la clase (operaciones).

Clases y estereotipos
As como las relaciones en los casos de uso, las clases tambin pueden
tener estereotipos. Estos proveen la capacidad de create nuevos tipo de
elementos de modelado, en el caso de las clases, nos permiten crear nuevos tipos
de clases. Algunos estereotipos comunes para las clases son: entidad, lmite,
control y excepcin.
El estereotipo para una clase se muestra arriba del nombre de la clase
encerrado entre los smbolos << >>. Por ejemplo, el software Rational Rose
maneja conos especiales para estos estereotipos.

Descubriendo clases
No existe una receta de cocina para encontrar las clases en el dominio de
un problema. Un buen comienzo para encontrar las clases del sistema en
desarrollo es buscando las clases lmite, entidad y control. Estos estereotipos le
permiten al analista particionar el sistema separando la vista, el dominio y el
control, que est requiriendo el sistema.
Ya que el proceso de anlisis y diseo es iterativo, la lista de clases se
modificar conforme avance el tiempo. El conjunto inicial de clases probablemente
no ser el conjunto de clases que ser implementado. As, el trmino clases
candidatas es comnmente utilizado para describir al primer conjunto de clases
encontradas.
Clases Entidad
Una clase entidad modela informacin y comportamiento asociado que
generalmente es de larga duracin (persistente). Este tipo de clases puede reflejar
una entidad del mundo real o puede ser necesaria para realizar tareas dentro del
sistema. Son por lo regular independientes del entorno, esto es, no son sensitivas
a cmo el entorno se comunica con el sistema. Muchas veces son independientes
de la aplicacin, lo que significa que pueden ser utilizadas en ms de una
aplicacin.
El primer paso es examinar las responsabilidades documentadas en el flujo
de eventos de los casos de uso identificados (esto es, lo que el sistema debe
hacer). Por lo regular son clases necesarias por el sistema para llevar a cabo
alguna responsabilidad. Los sustantivos y las frases con sustantivos utilizadas
para describir la responsabilidad son un buen punto de partida. La lista inicial de
sustantivos debe ser filtrada porque puede contener sustantivos que no
pertenecen al dominio del problema, sustantivos que slo son expresiones del

lenguaje, sustantivos redundantes y sustantivos que son descripciones de las


estructuras de alguna clase.
Las clases entidad por lo regular son encontradas el principio de la fase de
anlisis. Comnmente son llamadas clases de dominio, ya que usualmente
tratan con abstracciones de entidades del mundo real.
Clases Lmite
Las clases lmite se encargan de la comunicacin entre el entorno del
sistema y el interior del sistema. Pueden proveer la interfaz a un usuario o a otro
sistema (esto es, la interfaz con un actor). Constituyen la parte del sistema
dependiente del entorno. Las clases lmite se utilizan para modelar las interfaces
del sistema.
Para descubrir este tipo de clases, es necesario examinar las relaciones
fsicas actor/escenario. Las clases lmite seleccionadas en la fase de Elaboracin,
son tpicamente de alto nivel. Por ejemplo, se puede modelar una ventana pero no
modelar cada una de sus cajas de dilogo y botones. En este punto, uno est
documentando los requerimientos de interfaz de usuario, no implementando la
interfaz.
Las clases lmite tambin son agregadas para facilitar la comunicacin con
otros sistemas. Durante el diseo, estas clases son refinadas para tomar en
cuenta los protocolos de comunicacin elegidos.
Clases de Control
Las clases de control modelan comportamiento secuencial especfico a uno
o ms casos de uso. Las clases de control coordinan eventos necesarios para
realizar el comportamiento especificado en el caso de uso. Uno puede imaginar
una clase de control como aquella que corre o ejecuta el caso de uso,
representan la dinmica del caso de uso. Clases de control son por lo regular
clases dependientes de la aplicacin.
En las primeras etapas de la fase de Elaboracin, una clase de control es
agregada por cada par actor/caso de uso. La clase de control es responsable del
flujo de eventos en el caso de uso.
El uso de las clases de control es muy subjetivo. Si una clase de control
est haciendo ms que establecer una secuencia, entonces est haciendo cosas
de ms. Por ejemplo, en el sistema de Inscripciones de estudiantes, un estudiante
selecciona un curso y si el curso est disponible, el estudiante es agregado en el
curso. Qu clase es responsable de saber cmo agregar el estudiante, la clase
de control o la clase CursoOfertado? La respuesta correcta es CursoOfertado. La
clase de control sabe cundo el estudiante debe ser agregado, la clase
CursoOfertado sabe cmo agregar al estudiante. Una mala clase de control no
slo sabra cuando agregarlo, sino cmo agregarlo.

Obtener las clases de control a partir de los pares actor/caso de uso es slo
un punto de partida, conforme el anlisis y el diseo contina, estas clases
desaparecern, sern divididas o combinadas.

Documentando Clases
Conforme las clases se van creando, deben ser documentadas. La
documentacin deber enunciar el propsito de la clase y no la estructura de la
clase (ya que esta puede ser conocida a partir de sus atributos y sus operaciones).
Si se tiene dificultad para nombrar o documentar una clase, puede ser un
indicador de que no es una buena abstraccin. La siguiente lista tipifica cosas que
pueden suceder conforme las clases se van definiendo y documentando:
Se puede identificar el nombre y una definicin clara y concisa buena
clase candidata.
Se puede identificar el nombre, pero la definicin es la misma que la de otra
clase combinar las clases.
Se puede identificar el nombre, pero se requiere un libro para documentar
el propsito dividir la clase.
No se puede identificar el nombre ni la definicin es necesario ms
anlisis para determinar la abstraccin correcta.
Paquetes
Si el sistema slo contiene unas cuantas clases, se pueden manejar
fcilmente. Muchos sistemas estn compuestos de muchas clases, y por lo tanto
se requiere un mecanismo para agruparlas con fines de facilidad de uso,
mantenibilidad y reusabilidad. Aqu es donde el concepto de paquete es til. Un
paquete es una coleccin de paquetes relacionados y/o clases. Al agrupar clases
en paquetes podemos mirar tanto al ms alto nivel del modelo (los paquetes)
como a mayor profundidad en el modelo entrando al contenido de los paquetes.
Cada paquete contiene una interfaz que es realizada por su conjunto de
clases pblicas (que son aquellas clases con las cuales las clases de otros
paquetes pueden hablar). El resto de las clases en el paquete son clases de
implementacin (clases que no se comunican con clases en otros paquetes).
Si un sistema es complejo, los paquete pueden ser creados en la primera
parte de la fase de Elaboracin para facilitar la comunicacin. Para sistemas ms
simples, las clases encontradas en la primera parte del anlisis pueden ser
agrupadas en un slo paquete el sistema en s. Conforme el anlisis y el diseo
avancen el concepto de paquete ser utilizado para agrupar las clases que son
necesarias para llevar a cabo las decisiones arquitecturales tomadas para el
sistema. En UML los paquetes se representan por folders.

Realizacin de Casos de Uso


Los diagramas de casos de uso representan una visin externa del sistema.
La funcionalidad de los casos de uso es capturada en el flujo de eventos. Los
escenarios son utilizados para describir cmo los casos de uso son realizados
mediante interacciones entre sociedades de objetos. Un escenario es una
instancia de un caso de uso constituye un camino a travs del flujo de eventos
del caso de uso. Los escenarios son desarrollados para ayudar a la identificacin
de los objetos, las clases y las interacciones entre los objetos que son necesarias
para llevar a cabo un pedazo de funcionalidad especificado por el caso de uso.
Los escenarios documentan decisiones acerca de cmo las responsabilidades
especificadas en el caso de uso son distribuidas entre los objetos y las clases del
sistema. Tambin proveen un excelente medio de comunicacin para ser usado en
la discusin de los requerimientos del sistema con el cliente. Los escenarios
hablan el lenguaje del usuario final y el del experto en el dominio del problema, por
lo tanto proveen medios para que ellos establezcan a los desarrolladores sus
expectativas acerca del comportamiento deseado del sistema.
Cada caso de uso es una telaraa de escenarios - escenarios primarios (el
flujo normal del caso de uso) y escenarios secundarios (la lgica s-entonces del
caso de uso). Esto significa que existen una gran cantidad de escenarios para un
sistema. Durante las etapas tempranas del anlisis se puede asegurar que con
solo definir los escenarios primarios para cada caso de uso identificado es
suficiente. Una recomendacin es que la fase del anlisis est prxima a
finalizar una vez que el equipo ha elaborado aproximadamente el 80% de los
escenarios primarios del sistema junto con una seleccin representativa de los
secundarios.
En la Figura vemos la forma de representar la realizacin de un caso de
uso.

Documentacin de Escenarios
El flujo de eventos de un caso de uso es capturado en texto, los escenarios
se capturan en forma de diagramas de interaccin. Existen dos tipos de diagramas
de interaccin diagramas de secuencia y diagramas de colaboracin. Cada
diagrama es una vista grfica del escenario.

Diagramas de Secuencia
Un diagrama de secuencias muestra las interacciones de los objetos
ordenados en una secuencia de tiempo. Muestra los objetos y las clases
involucradas en el escenario y la secuencia de mensajes intercambiados entre los
objetos necesaria para llevar a cabo la funcionalidad del escenario. Los diagramas
de secuencia por lo regular se asocian con las realizaciones de casos de uso en la
vista lgica (Logical View) del sistema en desarrollo.
En UML, un objeto en un diagrama de secuencia es dibujado como un
rectngulo conteniendo el nombre del objeto, subrayado. Un objeto puede
aparecer de tres formas: el nombre del objeto, el nombre del objeto y su clase, o
solamente el nombre de la clase (objeto annimo).

Los nombres de los objetos pueden ser especficos (por ejemplo objeto2:
clase) o pueden ser genricos (por ejemplo objeto1). Comnmente un objeto
annimo (slo el nombre de la clase) puede ser usado para representar cualquier
objeto en la clase.
Cada objeto tiene tambin su lnea de tiempo representada por una lnea
punteada debajo del objeto. Los mensajes entre los objetos se representan por
flechas que apuntan del cliente (el emisor del mensaje) al proveedor (receptor del
mensaje).

Para representar condicionales se utilizan expresiones entre corchetes


antecediendo a los mensajes y si se antepone un asterisco la condicional la
expresin se evala como iteracin, esto es, el mensaje se enva del objeto emisor
al receptor mientras se cumpla la condicin.
Diagramas de Secuencia y Clases Lmite
Las clases lmite son agregadas a los diagramas de secuencia para mostrar
la interaccin con el usuario u otro sistema. En las etapas tempranas del anlisis,
el propsito de mostrar las clases lmite en un diagrama de secuencia es capturar
y documentar los requerimientos de interfaz, no para mostrar como la interfaz ser
implementada. Los detalles de la implementacin dependern de la plataforma de
programacin elegida y es casi seguro que los mensajes mostrados en los
primeros diagramas cambiarn conforme se vaya detallando el sistema.
Complejidad y Diagramas de Secuencia
Qu tan complejo debe ser un diagrama de secuencia? La respuesta es:
El diagrama debe ser lo ms simple posible. Lo importante de estos diagramas es
su simplicidad, es muy fcil ver los objetos, las interacciones , los mensajes entre
ellos y la funcionalidad capturada por el escenario.
Cmo representar lgica condicional? Esto tambin tiene un respuesta
muy subjetiva. Si la lgica es simple, si solo involucra unos cuantos mensajes, se
puede representar en un mismo diagrama utilizando notas. Si es ms compleja,
entonces conviene hacer un diagrama por cada if-then (si-entonces) y otro por
el else (si-no).
Diagramas de Colaboraciones
Un diagrama de colaboraciones es un diagrama en el que se muestran los
objetos con sus relaciones entre s, adems de los mensajes que se intercambian
entre ellos. El diagrama de colaboraciones es semnticamente equivalente al
diagrama de secuencias.
Los elementos que lo componen son:

Objetos representados como rectngulos.


Relaciones entre los objetos, representadas como lneas que los conectan.
Mensajes, representados por texto y una flecha que apunta del objeto
cliente al objeto proveedor as como un nmero que representa el orden
que le corresponde al mensaje dentro de una secuencia de colaboracin.

Las condicionales e iteraciones se representan de la misma forma que en


los diagramas de secuencias.

Diferencia entre los Diagramas de Secuencias y Diagramas de


Colaboraciones
Los diagramas de secuencias proveen una manera ordenada en el tiempo
de ver el escenario, qu pasa primero y qu pasa despus. Los clientes pueden
leer y entender fcilmente este tipo de diagramas, por lo que son tiles en las
etapas iniciales del anlisis. Los diagramas de colaboraciones estn orientados a
proveer la visin general del escenario, ya que las colaboraciones se organizan
alrededor de los enlaces de un objeto con otro. Estos diagramas se utilizan ms
durante la etapa de diseo cuando se est trabajando en la implementacin de las
relaciones entre objetos.
Diagrama de Transicin de Estados
Los casos de uso y los escenarios (diagramas de colaboracin y de
secuencia) proveen una manera de describir el comportamiento del sistema, esto
es, la interaccin que se da entre los objetos dentro del sistema. En ocasiones es
necesario analizar el comportamiento que se da dentro de un objeto. Un diagrama
de transicin de estados (o diagrama de estados) muestra los estados de un
objeto, los eventos o mensajes que causan la transicin de un estado a otro y las
acciones resultantes de ese cambio de estado.
Un diagrama de estados no se va a crear para cada clase del sistema, slo
para aquellas clases con comportamiento dinmico significativo. Los objetos
dinmicos del sistema pueden ser inferidos mediante el estudio de los diagramas
de interaccin (de colaboracin y de secuencia), aquellos objetos que envan y
reciben muchos mensajes se pueden clasificar como objetos dinmicos.
Estados
Un estado representa una condicin en la vida de un objeto durante la cual
se lleva a cabo una accin, se espera por un evento o se satisface una
condicional. El estado de un objeto puede ser caracterizado por el valor de uno o
ms de los atributos de su clase.
La notacin UML para representar un estado es un rectngulo con esquinas
redondeadas.

Un diagrama de estados abarca todos los mensajes que el objeto puede


enviar o recibir. Los escenarios representan una trayectoria a travs de un
diagrama de estados. El intervalo entre dos mensajes enviados por un objeto, por
lo regular representan un estado. Por lo tanto para descubrir los estados de un
objeto se pueden analizar los diagramas de secuencia.

Transiciones de Estado
Una transicin de estado representa un cambio de un estado origen a un
estado sucesor (puede ser el mismo estado origen). Esta transicin puede estar
acompaada de una accin.
Existen dos maneras de que se d una transicin para salir de un estado:
automtica y no-automtica. Una transicin automtica ocurre cuando se completa
la actividad que origina el estado, no existen eventos asociados con esta
transicin. Una transicin no-automtica es causada por un evento (ya sea de otro
objeto o externo al sistema). Los dos tipos de transiciones se consideran
inmediatas y no pueden ser interrumpidas. Las transiciones se representan por
flechas que apuntan del estado origen al estado sucesor.
Detalles de las transiciones
Una transicin puede tener asociada una accin y/o una condicin de
seguridad que a su vez puede disparar un evento. Una accin es comportamiento
que ocurre cuando la transicin se lleva a cabo. Un evento es un mensaje que es
enviado a otro objeto del sistema. Una condicin de seguridad es una expresin
Booleana de valores de atributos que permiten la transicin solo si la condicin es
verdadera. Tanto las acciones como las condiciones de seguridad representan
comportamiento del objeto y por lo general se convierten en operaciones.

Estados Especiales
Existen dos estados especiales. El primero es el estado de inicio. Cada
diagrama debe tener uno y slo un estado de inicio ya que el objeto debe estar en
un estado consistente (no ambiguo) cuando se crea. Se representa por un crculo
relleno. El segundo estado especial es el estado de paro. Un objeto puede tener
mltiples estados de paro. Se representa por una diana.
Detalles del Estado
Todas las acciones que acompaan a las transiciones de entrada a un
estado pueden ser puestas como una accin de entrada dentro del estado. De la
misma forma, todas las acciones que acompaan a las transiciones de salida de
un estado pueden ser puestas como acciones de salida dentro del estado. Al
comportamiento que ocurre dentro del estado se le llama actividad. Una actividad
empieza cuando se entra al estado y se completa o es interrumpida por una
transicin de salida. El comportamiento puede ser una accin simple o puede ser
un evento enviado a otro objeto. As como las acciones y las condiciones de

seguridad (asociadas a las transiciones) el comportamiento por lo regular es


mapeado en operaciones del objeto.

Modelo Lgico
El modelo lgico es una vista esttica de los objetos y clases que
componen el espacio del anlisis/diseo. Consiste en el conjunto de clases y
objetos que han resultado del anlisis y el diseo del sistema, as como las
relaciones de asociacin que existen entre ellas.
Todos los sistemas estn compuestos por muchas clases y objetos. El
comportamiento del sistema se logra a travs de la colaboracin de los objetos
que lo componen. Estas colaboraciones se dan mediante el intercambio de
mensajes entre ellos, el marco bajo el cual se realiza este intercambio de
mensajes se establece mediante las relaciones. Los tipos de relaciones que se
pueden dar entre clases son: dependencia, generalizacin (herencia), asociacin y
realizacin.
Relacin de Dependencia
La relacin de dependencia es la ms dbil de las relaciones entre clases,
muestra una relacin entre un cliente y un proveedor en la cual el cliente no tiene
conocimiento semntico del proveedor. Una relacin de dependencia se
representa como una lnea punteada que apunta del cliente al proveedor.

Relacin de Herencia
La herencia define una relacin entre clases, donde una clase comparte la
estructura y/o el comportamiento de una o ms clases.
Existen
dos
formas
generalizacin y especializacin.

de

encontrar

la

herencia:

La generalizacin provee la capacidad de crear superclases


encapsulen la estructura y comportamiento comn de varias clases.

que

La especializacin provee la habilidad de crear subclases que representan


refinamiento de la superclase, por lo regular estructura y comportamiento es
agregado a la nueva subclase.
En el UML la herencia se representa con una lnea que conecta a la clase
principal con la secundaria. En la parte de la lnea que se conecta con la clase

principal se coloca un tringulo son rellenar que apunta a la clase principal. Este
tipo de asociacin se interpreta con la frase es un tipo de.

Relacin de Asociacin
Una asociacin es una conexin semntica bidireccional entre clases. No
es un flujo de datos como se define en el anlisis y diseo estructurado, los datos
pueden fluir en cualquier direccin a travs de la asociacin. Una asociacin entre
clases significa que existe una liga entre los objetos de las clases asociadas. Por
ejemplo una asociacin entre la clase Empresa y la clase Gerente significa que los
objetos de la clase Empresa estn conectados a los objetos de la clase Gerente.
En la Figura se muestra la forma de representar la asociacin en UML.

Las asociaciones pueden tener nombre. El nombre de una asociacin por lo


regular se representa con un verbo.

En una asociacin se pueden representar los roles que cada clase


desempea, los roles son sustantivos que describen el papel de la clase en la
asociacin.

Restricciones
Es probable que las asociaciones se puedan dar bajo ciertas restricciones,
estas se pueden representar mediante una condicin encerrada entre llaves del
lado de la clase que tiene que cumplirla.

Otro tipo de restriccin es la relacin {or}, esta se puede dar entre una clase
y dos o ms, pero la asociacin es mutuamente excluyente.

Clases de asociacin
Una asociacin, al igual que una clase, puede contener atributos y
operaciones. Cuando este es el caso se define una clase de asociacin.

Multiplicidad
La multiplicidad indica la cantidad de objetos de una clase que se
relacionan con uno o ms objetos de la clase asociada. Se representa mediante
un valor o intervalo de valores a un lado de la clase, que indica el nmero de
ocurrencias de los objetos de la clase que se pueden dar en la asociacin.

Asociaciones calificadas
Cuando la multiplicidad de una asociacin es de uno a muchos, con
frecuencia se presenta un reto muy particular: la bsqueda. Cuando un objeto de
una clase tiene que seleccionar un objeto particular de otra clase para cumplir con

el papel de la asociacin, la primera clase utilizar un atributo en particular para


localizar al objeto adecuado. Normalmente, dicho atributo es un identificador que
puede ser un nmero de identidad.
En UML la informacin de identidad se conoce como calificador y se
representa por un rectngulo pequeo adjunto a la clase que har la bsqueda.

Agregacin
Una relacin de agregacin es una forma especializada de asociacin, en la
cual, el todo est relacionado con sus partes. La agregacin se conoce tambin
como una relacin es parte de.
La notacin UML para una relacin de agregacin es una asociacin con un
diamante junto a la clase que denota el todo. Las siguientes pruebas se utilizan
para determinar si una asociacin debe ser una agregacin:

Se utiliza la frase es parte de para describir la relacin?


Hay algunas operaciones en el todo que automticamente se aplican a
sus partes? Por ejemplo, si al borrar la clase principal es necesario borrar
las clases que dependen de ella.
Existe una asimetra intrnseca en la relacin, donde una clase es
subordinada a la otra?

Composicin
Una composicin es un tipo especial de agregacin. Cada componente
dentro de una composicin puede pertenecer tan slo a un todo. Se representa de
la misma forma que la agregacin, slo que el diamante est relleno.

Relacin de Realizacin
Una realizacin es una relacin semntica entre clasificadores en la cual un
clasificador especifica un contrato que el otro se obliga a cumplir. Grficamente
una realizacin se representa como una lnea punteada con una flecha cerrada
grande apuntando al clasificador que especifica el contrato.
Clases abstractas
Una clase abstracta es aquella que no provee objetos y se utiliza por lo
general como superclase para derivar clases que s aportarn objetos al sistema.
Por ejemplo, en el diagrama presentado anteriormente, es probable que en el
sistema nunca se creen objetos de la clase Persona, sin embargo es necesaria
representarla en el diseo para generalizar los atributos que se utilizarn tanto
para la clase Empleado como para la clase Cliente (nombre, direccin, telfono).
Las clases abstractas se representan con el nombre de la clase en letra cursiva.
Interfaces
Son clases que definen un conjunto de operaciones accesibles
externamente. Se utilizan para modelar una coleccin de operaciones que definen
un servicio que ofertan diferentes clases. Las interfaces no contienen atributos,

solo operaciones. Se representan de dos formas, una es mediante el uso del


estereotipo <<interfaz>> en el compartimiento del nombre de la clase; la otra
forma es mediante un crculo pequeo conectado a cada clase que la implementa.

Visibilidad
Establece el tipo de acceso que van a tener las otras clases a los atributos
u operaciones de una clase. Existen tres niveles:

Pblico: Todas las clases la pueden acceder. Se representa antecediendo el


smbolo de suma (+) al atributo o a la operacin.
Protegido: Slo las clases heredadas lo pueden acceder. Se representa con
el smbolo de nmero (#).
Privado: Slo la clase original tiene acceso. Se representa con el smbolo
de resta (-).
Todas las operaciones en las interfaces y realizaciones son pblicas.

Diagramas de Componentes
Los diagramas de componentes muestran la organizacin y
dependencias entre componentes de software. Un componente puede ser:

las

Un componente de cdigo fuente


Por ejemplo un archivo con cdigo en C.
Un componente de ejecucin (run time)
Por ejemplo un control tipo ActiveX.
Un componente ejecutable
Un programa listo para ser invocado por el intrprete de comandos, por
ejemplo un EXE.
Un componente de software es una parte fsica de un sistema que reside en
la computadora (archivo, tabla de datos, ejecutable, etc.). Un componente se
puede visualizar como el mapeo de una o ms clases del diseo en un pedazo de

software. Esto es, el componente es la implementacin en un lenguaje de


computadora de una o ms clases.
El smbolo principal de un diagrama de componentes es un rectngulo con
dos ms pequeos sobrepuestos del lado izquierdo, el nombre del componente va
dentro del rectngulo mayor.

Un diagrama de componentes se utiliza principalmente para documentar la


dependencia entre las piezas de software, por ejemplo en el siguiente
esquema vemos la dependencia que existe entre el cdigo ejecutable, el cdigo
objeto y el cdigo fuente de un programa escrito en lenguaje C.

La construccin de componentes orientados a la reutilizacin es uno de los


objetivos primordiales del diseo orientado a objetos. El UML permite que se utilice
el mecanismo de interfaces para la comunicacin entre componentes. Tambin en
los sistemas complejos, los componentes se pueden agrupan en paquetes y la
comunicacin entre componentes de distintos paquetes se puede visualizar
mediante el uso de interfaces.

Diagramas de Distribucin
Una vez definidos los componentes de software de un sistema, se requieren
definir los componentes de hardware y la distribucin de los mismos en el
ambiente real de operacin.
El elemento principal de un diagrama de distribucin es el nodo, el cual
puede ser de dos tipos:
Nodo tipo procesador: Es el componente de hardware que puede ejecutar
procesos (cmo un CPU, terminal porttil, punto de venta, etc.)

Nodo tipo dispositivo: Es el componente que no ejecuta procesos, por lo


general es aqul elemento que sirve de contacto con el mundo exterior
(cmo un monitor, impresor, teclado, etc.)

En UML el nodo se representa por medio de un cubo al cual se le asigna un


nombre y se puede utilizar un estereotipo para indicar el tipo de recurso. Una lnea
que asocie a dos cubos representar una conexin entre ellos, esta relacin podr
tener nombre. Aunque por lo regular se utiliza la asociacin simple, tambin es
posible utilizar la relacin de dependencia o agregacin.

El Proceso Unificado de Desarrollo de Software (RUP)


El Proceso Unificado es un proceso de software genrico que puede ser
utilizado para una gran cantidad de tipos de sistemas de software, para diferentes
reas de aplicacin, diferentes tipos de organizaciones, diferentes niveles de
competencia y diferentes tamaos de proyectos.
Provee un enfoque disciplinado en la asignacin de tareas y
responsabilidades dentro de una organizacin de desarrollo. Su meta es asegurar
la produccin de software de muy alta calidad que satisfaga las necesidades de
los usuarios finales, dentro de un calendario y presupuesto predecible.
El Proceso Unificado tiene dos dimensiones

Un eje horizontal que representa el tiempo y muestra los aspectos del ciclo
de vida del proceso a lo largo de su desenvolvimiento
Un eje vertical que representa las disciplinas, las cuales agrupan
actividades de una manera lgica de acuerdo a su naturaleza.

La primera dimensin representa el aspecto dinmico del proceso conforme


se va desarrollando, se expresa en trminos de fases, iteraciones e hitos
(milestones).
La segunda dimensin representa el aspecto esttico del proceso: cmo es
descrito en trminos de componentes del proceso, disciplinas, actividades, flujos
de trabajo, artefactos y roles.

El Proceso Unificado se basa en componentes (component-based), lo que


significa que el sistema en construccin est hecho de componentes de software
interconectados por medio de interfaces bien definidas (well-defined interfaces).
El Proceso Unificado usa el Lenguaje de Modelado Unificado (UML) en la
preparacin de todos los planos del sistema. De hecho, UML es una parte integral
del Proceso Unificado, fueron desarrollados a la par.
Los aspectos distintivos del Proceso Unificado estn capturados en tres
conceptos clave: dirigido por casos de uso (use-case driven), centrado en la
arquitectura (architecture-centric), iterativo e incremental. Esto es lo que hace
nico al Proceso Unificado.
El Proceso Unificado es dirigido por casos de uso
Un sistema de software se crea para servir a sus usuarios. Por lo tanto,
para construir un sistema exitoso se debe conocer qu es lo que quieren y
necesitan los usuarios prospectos.
El trmino usuario se refiere no solamente a los usuarios humanos, sino a
otros sistemas. En este contexto, el trmino usuario representa algo o alguien que
interacta con el sistema por desarrollar.
Un caso de uso es una pieza en la funcionalidad del sistema que le da al
usuario un resultado de valor. Los casos de uso capturan los requerimientos
funcionales. Todos los casos de uso juntos constituyen elmodelo de casos de
uso el cual describe la funcionalidad completa del sistema. Este modelo reemplaza
la tradicional especificacin funcional del sistema. Una especificacin funcional
tradicional se concentra en responder la pregunta: Qu se supone que el sistema
debe hacer? La estrategia de casos de uso puede ser definida agregando tres
palabras al final de la pregunta: por cada usuario? Estas tres palabras tienen una
implicacin importante, nos fuerzan a pensar en trminos del valor a los usuarios y
no solamente en trminos de las funciones que sera bueno que tuviera. Sin
embargo, los casos de uso no son solamente una herramienta para especificar los
requerimientos del sistema, tambin dirigen su diseo, implementacin y pruebas,
esto es, dirigen el proceso de desarrollo.
An y cuando los casos de uso dirigen el proceso, no son elegidos de
manera aislada. Son desarrollados a la par con la arquitectura del sistema, esto
es, los casos de uso dirigen la arquitectura del sistema y la arquitectura del
sistema influencia la eleccin de los casos de uso. Por lo tanto, al arquitectura del
sistema y los casos de uso maduran conforme avanza el ciclo de vida.

El Proceso Unificado est centrado en la arquitectura


El papel del arquitecto de sistemas es similar en naturaleza al papel que el
arquitecto desempea en la construccin de edificios. El edificio se mira desde
diferentes puntos de vista: estructura, servicios, plomera, electricidad, etc. Esto le
permite al constructor ver una radiografa completa antes de empezar a construir.
Similarmente, la arquitectura en un sistema de software es descrita como
diferentes vistas del sistema que est siendo construido.
El concepto de arquitectura de software involucra los aspectos estticos y
dinmicos ms significativos del sistema. La arquitectura surge de las necesidades
de la empresa, tal y como las interpretan los usuarios y otros stakeholders, y tal y
como estn reflejadas en los casos de uso. Sin embargo, tambin est
influenciada por muchos otros factores, tales como la plataforma de software en la
que se ejecutar, la disponiblidad de componentes reutilizables, consideraciones
de instalacin, sistemas legados, requerimientos no funcionales (ej. desempeo,
confiabilidad). La arquitectura es la vista del diseo completo con las
caractersticas ms importantes hechas ms visibles y dejando los detalles de
lado. Ya que lo importante depende en parte del criterio, el cual a su vez viene con
la experiencia, el valor de la arquitectura depende del personal asignado a esta
tarea. Sin embargo, el proceso ayuda al arquitecto a enfocarse en las metas
correctas, tales como claridad (understandability), flexibilidad en los cambios
futuros (resilience) y reuso.
Cmo se relacionan los casos de uso con la arquitectura? Cada producto
tiene funcin y forma. Uno slo de los dos no es suficiente. Estas dos fuerzas
deben estar balanceadas para obtener un producto exitoso. En este caso funcin
corresponde a los casos de uso y forma a la arquitectura. Existe la necesidad de
intercalar entre casos de uso y arquitectura. Es un problema del huevo y la
gallina. Por una parte, los casos de uso deben, cuando son realizados,
acomodarse en la arquitectura. Por otra parte, la arquitectura debe proveer
espacio para la realizacin de todos los casos de uso, hoy y en el futuro. En la
realidad, ambos arquitectura y casos de uso deben evolucionar en paralelo.
El Proceso Unificado es Iterativo e Incremental
Desarrollar un producto de software comercial es una tarea enorme que
puede continuar por varios meses o aos. Es prctico dividir el trabajo en
pequeos pedazos o mini-proyectos. Cada mini-proyecto es una iteracin que
finaliza en un incremento. Las iteraciones se refieren a pasos en el flujo de trabajo,
los incrementos se refieren a crecimiento en el producto. Para ser ms efectivo,
las iteraciones deben estar controladas, esto es, deben ser seleccionadas y
llevadas a cabo de una manera planeada.
Los desarrolladores basan su seleccin de qu van a implementar en una
iteracin en dos factores. Primero, la iteracin trata con un grupo de casos de uso

que en conjunto extienden la usabilidad del producto. Segundo, la iteracin trata


con los riesgos ms importantes. Las iteraciones sucesivas construyen los
artefactos del desarrollo a partir del estado en el que fueron dejados en la iteracin
anterior.
En cada iteracin, los desarrolladores identifican y especifican los casos de
uso relevantes, crean el diseo usando la arquitectura como gua, implementan el
diseo en componentes y verifican que los componentes satisfacen los casos de
uso. Si una iteracin cumple sus metas y usualmente lo hace el desarrollo
contina con la siguiente iteracin. Cuando la iteracin no cumple con sus metas,
los desarrolladores deben revisar sus decisiones previas y probar un nuevo
enfoque.

CMMI
Capability Maturity Model Integration.
Bsicamente el CMMI son normas para calidad enfocada al mundo del
Software.
Estas se aplican a los diferentes procesos que hay que llevar a cabo para
lograr producir software con calidad, es muy importante mencionar que igual que
las normas ISO 9000-3, este modelo nos dice que hay que hacer, y no como hay
que hacerlo.
Anteriormente existan varios sistemas que se utilizaban en los procesos de
desarrollo y mantenimiento de software, dichos procesos eran enfocados a cada
una de las sub-reas en las que se divide el desarrollo de sistemas de software,
entre algunos de estos sistemas tenemos:
La combinacin del sistema CMM-SW (CMM enfocado al desarrollo del
software), con el SE-CMM (Ingeniera de Sistemas), Junto con algn Producto
para el desarrollo.
Entonces la Idea de CMMI a sido integrar esas distintas tecnologas o
fases, en un solo proceso que maneje de forma adecuada las interacciones entre
las fases antes mencionadas, pero por ser parte del sistema, de una manera
optima, ya que anteriormente, era una parte del trabajo, ensamblar los distintos
sistemas mencionados, anteriormente.
El Sistema CMMI, Incluye las herramientas para la implementacin de:
Ingeniera de Sistemas (Systems Engineering SE), Ingeniera de Software
(Software Engieneering SW), Desarrollo integrado del Producto y Procesos
(Integrated product and process development IPPD), Suplidor de recursos (Suplir
sourcing SS).
Madurez en CMMI:
Son nombres que se le dan a ciertos niveles para determinada empresa,
dependiendo de la implementacin de procesos de calidad que est tomando en
cuenta en sus procesos.
Niveles CMMI:
En general los niveles son 6 y estn relacionados con el nivel de
madurez de la empresa y estn distribuidos como sigue:
Nivel 0
Se dice de cuando los niveles de madurez, no son aplicables a una
empresa, no se cumplen los objetivos, o no se concluye el proceso de desarrollo.

Nivel 1 o nivel Inicial de Madurez:


Se agrupan en este nivel las empresas que simplemente no tiene procesos
definidos. Es decir emprenden un proyecto sin tomar en cuenta tiempo que le lleva
producir cierta parte, incluso no dividen el proyecto en partes. Pero que concluyen
el mismo.
Nivel 2 o nivel Gestionado o tambin llamado Repetible:
Se diferencia del Nivel anterior bsicamente, porque el proyecto ha sido
Gestionado. Con gestionado queremos decir que adems de concluir un proceso,
este fue planificado, se revisan y evalan los procesos para ver si se cumplen las
expectativas planteadas. Adems es llamado repetible porque para un proceso
exitoso, este podra repetirse y obtener los mismos resultados exitosos.
Nivel 3 o nivel Definido:
Incluye las caractersticas de un proceso de Nivel 2, pero los procesos
utilizados, son ajustados a la poltica de procesos de la empresa, es decir el
proceso se alinear con las directivas que posee la empresa como propios.
Nivel 4 o nivel Cuantitativamente Gestionado:
Una empresa llega a este nivel, cuando es una empresa con nivel de
madures 3, y adems agrega la caracterstica de agregar la medicin de
resultados de una forma cuantitativa, es de decir poder medir que tan buenos
fueron sus procesos.
Nivel 5 o nivel Optimizado:
Es la empresa que teniendo nivel 4, adems tiene procesos de mejora
continua, es decir mide sus resultados, los analiza, aprende, y toma decisiones a
partir de ellos. Esto llevar a la empresa a estar siempre ms cerca de la
optimizacin.
Como se vio en la lectura, para pasar de un nivel a otro, hay procesos claves que
elevan una empresa de un nivel a otro.
Para pasar de Nivel 0 a Nivel 1 es necesario:
Concluir el proceso de desarrollo.
Para pasar de Nivel 1 a Nivel 2 es necesario:
Agregar los procesos:

Gestin de requisitos
Planificacin de proyectos
Seguimiento y control de proyectos
Gestin de proveedores
Aseguramiento de la calidad
Gestin de la configuracin

Para pasar de Nivel 2 a Nivel 3 es necesario:


Agregar los procesos:

Desarrollo de requisitos
Solucin Tcnica
Integracin del producto
Verificacin
Validacin
Desarrollo y mejora de los procesos de la organizacin
Definicin de los procesos de la organizacin
Planificacin de la formacin
Gestin de riesgos
Anlisis y resolucin de toma de decisiones

Para pasar de Nivel 3 a Nivel 4 es necesario:


Agregar los procesos:

Gestin cuantitativa de proyectos


Mejora de los procesos de la organizacin

Para pasar de Nivel 3 a Nivel 4 es necesario:


Agregar los procesos:
Innovacin organizacional
Anlisis y resolucin de las causas
Beneficios de CMMI
La correcta aplicacin del modelo trae beneficios como, beneficios
puramente ingenieriles:
1. Los procesos maduros permiten:
- Entender lo que est pasando.
- Que el personal desarrolle todo su potencial ms completamente y ms
efectivamente dentro de la organizacin.
2. La mejora de los procesos tiene ms posibilidades de resultar con xito y
ser ms sustanciosa a la organizacin ya que se basa en la definicin,
medicin y control de los procesos.
3. Se incrementa sensiblemente la probabilidad de xito en la introduccin de
nuevas y apropiadas tecnologas, tcnicas y herramientas en la
organizacin.

Beneficios econmicos u organizativos:


1. Enfatiza el desarrollo de procesos en las organizaciones que permiten
mejorar el desarrollo de los productos y los servicios ofertados a los
clientes.
2. Proporciona un marco de trabajo que permite organizar y priorizar las
actividades de mejora de procesos, involucrando al propio producto, al
negocio, al personal y a la tecnologa.
3. Da soporte a la coordinacin de actividades multidisciplinarias que pueden
ser necesarias para construir con xito un determinado producto.
4. Enfatiza el alineamiento de los objetivos de la mejora de procesos con los
objetivos de negocio de las organizaciones

Bibliografa
1. http://yaqui.mxl.uabc.mx/~molguin/as/RUP.htm
2. http://yaqui.mxl.uabc.mx/~molguin/as/UMLCurso2.htm
3. http://juanmarcosteoria2.blogspot.com/2008/01/para-el-enriquecimiento-delos-lectores.html