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 UsoDiagrama de Clases

Diagrama de ObjetosDiagrama de Actividades

Diagrama de SecuenciasDiagrama de Colaboraciones

Diagrama de EstadosDiagrama de Componentes

Diagrama de Distribucin

Cada uno de estos diagramas contienenclasificadores, 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 SistemaEl 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.

ActoresLos 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 laimagen.

Documentacin de actoresEl 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 UsoLos 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 formasdefinidas 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 laFigura.

Documentacin de los Casos de UsoEnuncia 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 delqudebe hacer el sistema y no delcmolo 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 1.1. Precondiciones1.2. Flujo principal1.3. Subflujos1.4. Flujos alternos1.5. Postcondiciones

Relaciones de los Casos de UsoUna 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:includeyextend.

La relacinincludese 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). VerFigura3.La relacinextendsse 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 ActividadesLos diagramas de actividadesrepresentan 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.

ActividadesUna actividad representa la ejecucin de algn tipo de comportamiento en el flujo de trabajo.

TransicionesLas 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 DecisinCuando 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 SincronizacinEn 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. VerFigura5

Actividades inicial y finalExisten 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 ylas actividades finales por una diana.

ObjetosUn 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 IdentidadEl 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:abiertoocerrado. Si el nmero de estudiantes registrados para el curso ofertado es menor a 10, el estado del curso ofertado esabierto. Cuando el dcimo estudiante se registre en ese curso ofertado, el estado se convierte encerrado.

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

ClasesUna 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 informacinacerca 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 estereotiposAs 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 clasesNo 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 EntidadUna 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 LmiteLas 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 ControlLas 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 ClasesConforme 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.

PaquetesSi 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 UsoLos 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 lgicas-entoncesdel 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 finalizaruna vez que el equipo ha elaborado aproximadamente el 80% de los escenarios primarios del sistema junto con una seleccin representativa de los secundarios.En laFiguravemos la forma de representar la realizacin de un caso de uso.

Documentacin de EscenariosEl 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 secuenciay diagramas de colaboracin. Cada diagrama es una vista grfica delescenario.Diagramas de SecuenciaUn 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 representarcondicionales 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 LmiteLas 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 SecuenciaQu 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 cadaif-then(si-entonces) y otro por elelse(si-no).Diagramas de ColaboracionesUn 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 EstadosLos 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.EstadosUn 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 EstadoUna 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 transicionesUna transicin puede tener asociada unaacciny/o unacondicin de seguridadque a su vez puede disparar unevento. Unaaccines comportamiento que ocurre cuando la transicin se lleva a cabo. Uneventoes un mensaje que es enviado a otro objeto del sistema. Unacondicin de seguridades una expresin Booleana de valores de atributos que permiten la transicin solo si la condicin es verdadera. Tanto lasaccionescomo lascondiciones de seguridadrepresentan comportamiento del objeto y por lo general se convierten en operaciones.

Estados EspecialesExisten dos estados especiales. El primero es elestado 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 elestado de paro. Un objeto puede tener mltiples estados de paro. Se representa por una diana.

Detalles del EstadoTodas las acciones que acompaan a las transiciones de entrada a un estado pueden ser puestas como unaaccin de entradadentro del estado. De la misma forma, todas las acciones que acompaan a las transiciones de salida de un estado pueden ser puestas comoacciones de salidadentro del estado. Al comportamiento que ocurre dentro del estado se le llamaactividad.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 lasaccionesy lascondiciones de seguridad(asociadas a las transiciones) el comportamiento por lo regular es mapeado en operaciones del objeto.

Modelo LgicoEl 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, elmarco 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 DependenciaLa 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 HerenciaLa herencia define una relacin entre clases, donde una clase comparte la estructura y/o el comportamiento de una o ms clases.

Existen dos formas de encontrar la herencia: generalizacinyespecializacin.

Lageneralizacinprovee la capacidad de crear superclases que encapsulen la estructura y comportamiento comn de varias clases.

Laespecializacinprovee 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 AsociacinUna 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 laFigurase 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.

RestriccionesEs 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 asociacinUna asociacin, al igual que una clase, puede contener atributos y operaciones. Cuando este es el caso se define una clase de asociacin.

MultiplicidadLa 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 calificadasCuando 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.

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

ComposicinUna 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 RealizacinUna 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 abstractasUna 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.InterfacesSon 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 en el compartimiento del nombre de la clase; la otra forma es mediante un crculo pequeo conectado a cada clase que la implementa.

VisibilidadEstablece 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 ComponentesLos diagramas de componentes muestran la organizacin y las dependencias entre componentes de software. Un componente puede ser:

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 esquemavemos 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 DistribucinUna 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 tipoprocesador: Es el componente de hardware que puede ejecutar procesos (cmo un CPU, terminal porttil, punto de venta, etc.) Nodo tipodispositivo: 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.

Uncaso de usoes 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 usoel 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 IncrementalDesarrollar 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.

CMMICapability 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 modelonos diceque 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.

Entoncesla Ideade 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 EngineeringSE), Ingeniera de Software (Software EngieneeringSW), Desarrollo integrado del Producto y Procesos (Integrated product and process developmentIPPD),Suplidor de recursos (Suplir sourcingSS).

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 madurezde la empresa y estn distribuidos como sigue:

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

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

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

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

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

Nivel5o 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 Nivel0 aNivel 1 es necesario:Concluir el proceso de desarrollo.

Para pasar de Nivel1 aNivel 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 Nivel2 aNivel 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 Nivel3 aNivel 4 es necesario:Agregar los procesos:

Gestin cuantitativa de proyectos Mejora de los procesos de la organizacin

Para pasar de Nivel3 aNivel 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-de-los-lectores.html