La metodologa OMT (Object Modeling Technique) fue creada por James

Rumbaugh y Michael Blaha en 1991.

OMT es una de las metodologas de anlisis y diseo orientadas a objetos,
ms maduras y eficientes que existen en la actualidad. La gran virtud que
aporta esta metodologa es su carcter de abierta (no propietaria), que le
permite ser de dominio pblico y , en consecuencia, sobrevivir con enorme
vitalidad. Esto facilita su evolucin para acoplarse a todas las necesidades
actuales y futuras de la ingeniera de software.
Las fases que conforman a la metodologa OMT son:
1.2.3.4.-

Analisis
Diseo del Sistema
Diseo de Objetos
Implementeacion

La metodologa OMT emplea tres clases de modelos para describir el

sistema:
1.- Modelo de objetos.
2.- Modelo dinamico.
3.- Modelo funcional.

Introduccin

Existen muchas aproximaciones de desarrollo de software que utilizan modelos

orientado a objetos, pero que no tienen todos los soportes para desarrollo de
aplicaciones de base de datos. Algunas aproximaciones carecen de suficientes
abstracciones y tienen un bajo relacionamiento para detalles de implementacin.
Otros mtodos de programacin orientados ponen un escaso nfasis en la estructura de
datos y constantes, que son muy importantes para aplicaciones de base de datos.
OMT pone nfasis en la importancia del modelo y uso de modelo para lograr una
abstraccin , en el cual el anlisis esta enfocado en el mundo real para un nivel de
diseo, tambin pone detalles particulares para modelado de recursos de la
computadora. Esta Tecnologa puede ser aplicado en varios aspectos de implementacin
incluyendo archivos, base de datos relacionales, base de datos orientados a objetos.
OMT esta construido alrededor de descripciones de estructura de datos, constantes,
sistemas para procesos de transacciones.
Desde que la comunidad de programacin orientada a objetos tuvo la nocin de
incorporar el pensamiento de que los objetos son entidades coherentes con identidad
estado y conducta, estos objetos pueden ser organizados por sus similitudes y sus
diferencias, puestas en uso en herencia y polimorfismo.

Desde el modelado de informacin, tuvo que ser adoptada la nocin de entidades que
son conectadas con entidad relacin, los modelos de relacin son declarativas,
imperativas.
OMT pone nfasis en especificaciones declarativas de la informacin, para capturar
limpiamente los requerimientos, especificaciones imperativas para poder descender
prematuramente en el diseo, declaraciones que permiten optimizar los
estados, adems provee un soporte declarativo para una directa implementacin de
DBMS.
INTRODUCCION

El objeto que modela la tcnica (OMT) comienza en la conceptualizacin del sistema y

atraviesa el ciclo vital del desarrollo del sistema de software lgica a travs de la puerta
en practica de sistema. El proceso consiste en cuatro actividades de alto nivel. Cada
actividad es dirigida por una descripcin del flujo del trabajo e implica la creacin de
modelos mltiples.
La tcnica que modela el objeto es utilizado para mostrar la estructura esttica de un
sistema mostrando los objetos en el sistema, juntos con sus lazos, atributos y
operaciones.
OMT se puede adaptar para utilizar en diversos ordenes de sus actividades importantes
para permitir que la ejecucin simultanea en el trabajo sea realizada y la iteracin de
actividades y de sus tareas. As ajustes de OMT agradable en un marco modelo espiral
de ciclo vital del desarrollo incremental del software lgica.
OMT utiliza tres modelos fundamentales para capturar el comportamiento y el diseo
para el sistema. Estos modelos son:
1. Modelo del objeto, que representa la naturaleza estructural del sistema.
2. Modelo dinmico, que representa el comportamiento del sistema.
3. Modelo funcional, que describe los algoritmos requeridos para satisfacer los
requisitos del proceso del sistema.
Estos tres modelos son puestos en ejecucin iterando concluido un conjunto de
microprocesos del anlisis, a partir de la fase de la conceptualizacin a travs de la fase
del diseo del objeto.

METODOLOGA ORIENTADAS A OBJETOS (OMT).

La metodologa a seguir es la OMT(Object Modeling Techique) de Rumbaugh. Surgi en los laboratorios
Bell de USA. Tiene las siguientes fases:
1. Conceptualizacin.
2. Anlisis.
3. Diseo Sistema.
4. Diseo Objeto.
5. Implementacin.

OMT es una de las metodologas de anlisis y diseo de desarrollo de

software orientado a objetos ms eficiente que existe en la actualidad.

Es uno de los precursores de UML.

Esta metodologa se extiende del anlisis, al diseo, a la implementacin

durante sus etapas.

Etapas de OMT
1. Anlisis: es una abstraccin concisa y precisa de qu debe hacer el sistema
deseado, no cmo debe ser hecho.
2. Diseo del Sistema: en esta etapa se deben decidir las caractersticas del
funcionamiento para optimizar el sistema, as como escoger una estrategia
para atacar el problema.
3. 3. Diseo de Objetos: se agregan los detalles de implementacin al
modelo de diseo y las clases de objetos son reforzadas con las estructuras
de datos y algoritmos escogidos.
4. 4. Implementacin: las clases de objetos y las relaciones entre ellas
definidas durante el diseo de objetos son trasladadas a un lenguaje de
programacin, a una base de datos o implementacin de hardware.
Modelos de OMT

Modelo de Objetos: describe la estructura esttica de los objetos de un

sistema y sus relaciones. Utiliza diagramas de clases.

Modelo Dinmico: determina cmo los aspectos del sistema que cambian
a travs del tiempo. Utiliza diagramas de estado.

Modelo Funcional: describe las trasformaciones de los valores de los datos

dentro de un sistema. Utiliza diagramas de flujo de datos.

Conclusiones

La metodologa OMT (Object Modeling Technique) desarrollada por

James Rumbaugh es base para el desarrollo de software orientado a
objetos y se extiende del anlisis, al diseo, a la implementacin

La metodologa OMT posee cuatro etapas: anlisis, diseo del sistema,

diseo de objetos e implementacin definidas por tres modelos: el modelo
de objetos, el modelo dinmico y el modelo funcional
Rational Unified Process (RUP)
La metodologa RUP, llamada as por sus siglas en ingls Rational Unified Process, divide en 4 fases el
desarrollo del software:

Inicio, El Objetivo en esta etapa es determinar la visin del proyecto.

Elaboracin, En esta etapa el objetivo es determinar la arquitectura ptima.

Construccin, En esta etapa el objetivo es llevar a obtener la capacidad operacional inicial.

Transmisin, El objetivo es llegar a obtener el release del proyecto.

Cada una de estas etapas es desarrollada mediante el ciclo de iteraciones, la cual consiste en reproducir el
ciclo de vida en cascada a menor escala. Los Objetivos de una iteracin se establecen en funcin de la
evaluacin de las iteraciones precedentes.
Vale mencionar que el ciclo de vida que se desarrolla por cada iteracin, es llevada bajo dos disciplinas:
Disciplina de Desarrollo

Ingeniera de Negocios: Entendiendo las necesidades del negocio.

Requerimientos: Trasladando las necesidades del negocio a un sistema automatizado.

Anlisis y Diseo: Trasladando los requerimientos dentro de la arquitectura de software.

Implementacin: Creando software que se ajuste a la arquitectura y que tenga el comportamiento

deseado.

Pruebas: Asegurndose que el comportamiento requerido es el correcto y que todo los solicitado
esta presente.

Disciplina de Soporte

Configuracin y administracin del cambio: Guardando todas las versiones del proyecto.

Administrando el proyecto: Administrando horarios y recursos.

Ambiente: Administrando el ambiente de desarrollo.

Distribucin: Hacer todo lo necesario para la salida del proyecto

Es recomendable que a cada una de estas iteraciones se les clasifique y ordene segn su prioridad, y que
cada una se convierte luego en un entregable al cliente. Esto trae como beneficio la retroalimentacin que
se tendra en cada entregable o en cada iteracin.
Los elementos del RUP son:

Actividades, Son los procesos que se llegan a determinar en cada iteracin.

Trabajadores, Vienen hacer las personas o entes involucrados en cada proceso.

Artefactos, Un artefacto puede ser un documento, un modelo, o un elemento de modelo.

Una particularidad de esta metodologa es que, en cada ciclo de iteracin, se hace exigente el uso de
artefactos, siendo por este motivo, una de las metodologas ms importantes para alcanzar un grado de
certificacin en el desarrollo del software.
Conclusin:

La Metodologa RUP es mas adaptable para proyectos de largo plazo.

METODOLOGIA ROM
Consiste en el desarrollo de software utilizando objetos que hayan sido
previamente desarrollados en otros proyectos

METODOLOGIA RUP

PROCESO DE DESARROLLO DE SOFTWARE:

La metodologa RUP es una disciplina que nos permite mantener un orden
debidamente estricto el cual asigna responsabilidades en una empresa.
RUP que significa Proceso Unificado racional es un programa creado por IBM
el cual se desarrollo orientado para desarrollar modelos que representen en
la empresa, habiendo sido debidamente investigada la empresa.
Nos brinda la facilidad de utilizar UML de forma prctica, adems un apoyo
para realizar muchos procesos que existen para modelar o documentar el
sistema de una empresa.
RUP es un software moderno es complejo y novedoso.
Un proceso iterativo permite una comprensin creciente de los
requerimientos a la vez que se va haciendo crecer el sistema.
RUP sigue un modelo iterativo que aborda las tareas ms riesgosas
primero.
Con esto se logra reducirlos riesgos del proyecto y tener un subsistema
ejecutable tempranamente.

RUP es una herramienta determinada por ciclos y fases para el proceso del
Modelado

Fases de la Metodologa RUP

Un ciclo est conformado por 4 fases cada una las cuales son:
Fase de Inicio
Fase de Elaboracin
Fase de Construccin
Fase de Transicin
PRINCIPALES CARACTERISTICAS
Forma disciplinada de asignar tareas y responsabilidades (quin hace qu,
cundo y cmo)
Pretende implementar las mejores prcticas en Ingeniera de Software
Desarrollo iterativo
Administracin de requisitos
Uso de arquitectura basada en componentes
Control de cambios
Modelado visual del software
Verificacin de la calidad del software
Implementacin del RUP para el proyecto
La metodologa RUP es ms apropiada para proyectos grandes (Aunque
tambin pequeos), dado que requiere un equipo de trabajo capaz de
administrar un proceso complejo en varias etapas. En proyectos pequeos,
es posible que no se puedan cubrir los costos de dedicacin del equipo de
profesionales necesarios
RUP
Rational Unified Process

El Proceso Unificado Racional, Rational Unified Process en ingls, y sus

siglas RUP, es un proceso de desarrollo de software y junto con el Lenguaje
Unificado de Modelado UML, constituye la metodologa estndar ms utilizada
para el anlisis, implementacin y documentacin de sistemas orientados a
objetos.
El RUP no es un sistema con pasos firmemente establecidos, sino que
trata de un conjunto de metodologas adaptables al contexto y necesidades de
cada organizacin, donde el software es organizado como una coleccin de
unidades atmicas llamados objetos, constituidos por datos y funciones, que
interactan entre s.

Tambin se conoce por este nombre al software desarrollado por

Rational, hoy propiedad de IBM, el cual incluye informacin entrelazada de
diversos artefactos y descripciones de las diversas actividades. Est incluido en
el Rational Method Composer (RMC), que permite la personalizacin de
acuerdo a necesidades.
Originalmente se dise un proceso genrico y de dominio pblico,
el Proceso Unificado, y una especificacin ms detallada, el Rational Unified
Process, que se vendiera como producto independiente.
RUP se divide en 4 fases, dentro de las cuales se realizan varias iteraciones
segn el proyecto y en las que se hace mayor o menos esfuerzo en las distintas
actividades.
En las iteraciones de cada fase se hacen diferentes esfuerzos en diferentes
actividades:
Fase de Inicio (Inspeccin y Concepcin) Se hace un plan de fases, donde
se identifican los principales casos de uso y se identifican los riesgos. Se
concreta la idea, la visin del producto, como se enmarca en el negocio, el
alcance del proyecto.
Fase de Elaboracin: se realiza el plan de proyecto, donde se completan
los casos de uso y se mitigan los riesgos. Planificar las actividades
necesarias y los recursos requeridos, especificando las caractersticas y el
diseo de la arquitectura.
Fase de Construccin: se basa en la elaboracin de un producto
totalmente operativo y en la elaboracin del manual de usuario. Construir el
producto, la arquitectura y los planes, hasta que el producto est listo para
ser enviado a la comunidad de usuarios.
Fase de Transicin: se realiza la instalacin del producto en el cliente y se
procede al entrenamiento de los usuarios. Realizar la transicin del
producto a los usuarios, lo cual incluye: manufactura, envo, entrenamiento,
soporte y mantenimiento del producto, hasta que el cliente quede
satisfecho, por tanto en esta fase suelen ocurrir cambios.
Con estas fases se logra ejecutar un conjunto de mejores prcticas, como lo
son:

 Desarrollar Software Iterativamente

Modelar el software visualmente
Gerenciar los Requerimientos
Usar arquitecturas basadas en componentes
Verificacion continua de la calidad
Gerenciar los cambios

Metodologa de Booch
La Metodologa de Booch es una tcnica usada en ingeniera de software. Es un
lenguaje de modelado de objetos y una metodologa ampliamente usada en el diseo de
software orientado a objetos. Fue desarrollada por Grady Booch mientras trabajaba para
Rational Software (hoy parte de IBM).
Los aspectos notables de la metodologa de Booch han sido superados por el Lenguaje
Unificado de Modelado, que combina elementos grficos de la metodologa de Booch
junto a elementos de la tcnica de modelado de objetos y la Ingeniera de software
orientada a objetos
Los aspectos metodolgicos de la metodologa de Booch fueron incorporados en varias
metodologas y procesos, siendo la principal de ellas el Proceso Racional Unificado
(RUP).

Metodologa de Booch

Surge debido a los objetivos de la ingeniera de software

Entregar un producto Software que satisfaga las necesidades

del usuario, de forma eficiente y predecible.

Abarca un microproceso de desarrollo y un macroproceso de

desarrollo.

Fue creado por Grady Booch en 1994, mientras estuvo en Rational

Software

Modelos del Mtodo de Booch

Modelo de Lgica: est representado en la estructura clase-objeto.

Modelo Esttico: es representado por el diagrama de clase, en el

que se construye la arquitectura que se definir para el sistema.

Modelo Dinmico: es representado por el diagrama de objeto que

muestra cmo las clases interactan unas con otras.

El Mtodo de Booch

Es un ciclo de vida iterativo e incremental, en el cual se mira el

desarrollo del producto como una serie de despacho (releases) de
arquitectura que evolucionan hacia el sistema final.

El cambio se prev en todas las fases. Se trata de una reduccin del

riesgo en el proceso impulsado.

Macro-Proceso

Engloba una actividad de planificacin arquitectnica, que agrupa

capas de objetos por nivel de abstraccin.
Identifica situaciones relevantes.

Crea un prototipo de diseo y valida el prototipo aplicndolo a

situaciones de uso.

Es un proceso de alto nivel.

Micro-Proceso

Define un conjunto de reglas que regulan el uso de operaciones y

atributos, de reglas y polticas.

Desarrolla situaciones que describen la semntica de las reglas y

polticas.

Crea un prototipo para cada poltica.

Instrumenta y refina el prototipo.

Es un proceso de bajo nivel

Conclusiones

El mtodo de Anlisis y Diseo Orientado a Objetos, desarrollado por

Grady Booch, se basa en dividir un solo proceso en un microproceso y
un macroproceso.

Grady Booch para desarrollar el mtodo de Anlisis y Diseo

Orientado a Objetos, uni conceptos de otras metodologas,
incluyendo su trabajo anterior, Objectory, OMT, entre otros.

El mtodo de Booch se basa en el desarrollo iterativo de un sistema,

en el cual se mira el producto como una serie de arquitecturas que
evolucionan hacia el sistema el desarrollo final.

Extreme Programming (XP)

Es una de las metodologas de desarrollo de software ms exitosas en la actualidad utilizadas para
proyectos de corto plazo, corto equipo y cuyo plazo de entrega era ayer. La metodologa consiste en una
programacin rpida o extrema, cuya particularidad es tener como parte del equipo, al usuario final, pues
es uno de los requisitos para llegar al xito del proyecto.
Caractersticas de XP, la metodologa se basa en:

Pruebas Unitarias: se basa en las pruebas realizadas a los principales procesos, de tal manera
que adelantndonos en algo hacia el futuro, podamos hacer pruebas de las fallas que pudieran
ocurrir. Es como si nos adelantramos a obtener los posibles errores.

Refabricacin: se basa en la reutilizacin de cdigo, para lo cual se crean patrones o modelos

estndares, siendo ms flexible al cambio.

Programacin en pares: una particularidad de esta metodologa es que propone la

programacin en pares, la cual consiste en que dos desarrolladores participen en un proyecto en
una misma estacin de trabajo. Cada miembro lleva a cabo la accin que el otro no est haciendo
en ese momento. Es como el chofer y el copiloto: mientras uno conduce, el otro consulta el
mapa.

Qu es lo que propone XP?

Empieza en pequeo y aade funcionalidad con retroalimentacin continua

El manejo del cambio se convierte en parte sustantiva del proceso

El costo del cambio no depende de la fase o etapa

No introduce funcionalidades antes que sean necesarias

El cliente o el usuario se convierte en miembro del equipo

Derechos del Cliente

Decidir que se implementa

Saber el estado real y el progreso del proyecto

Aadir, cambiar o quitar requerimientos en cualquier momento

Obtener lo mximo de cada semana de trabajo

Obtener un sistema funcionando cada 3 o 4 meses

Derechos del Desarrollador

Decidir cmo se implementan los procesos

Crear el sistema con la mejor calidad posible

Pedir al cliente en cualquier momento aclaraciones de los requerimientos

Estimar el esfuerzo para implementar el sistema

Cambiar los requerimientos en base a nuevos descubrimientos

Lo fundamental en este tipo de metodologa es:

La comunicacin, entre los usuarios y los desarrolladores

La simplicidad, al desarrollar y codificar los mdulos del sistema

La retroalimentacin, concreta y frecuente del equipo de desarrollo, el cliente y los usuarios

finales

Microsoft Solution Framework (MSF)

Esta es una metodologa flexible e interrelacionada con una serie de conceptos, modelos y prcticas de
uso, que controlan la planificacin, el desarrollo y la gestin de proyectos tecnolgicos. MSF se centra en
los modelos de proceso y de equipo dejando en un segundo plano las elecciones tecnolgicas.

Figura 3: Metodologa MSF

MSF tiene las siguientes caractersticas:

Adaptable: es parecido a un comps, usado en cualquier parte como un mapa, del cual su uso es
limitado a un especfico lugar.

Escalable: puede organizar equipos tan pequeos entre 3 o 4 personas, as como tambin,
proyectos que requieren 50 personas a ms.

Flexible: es utilizada en el ambiente de desarrollo de cualquier cliente.

Tecnologa Agnstica: porque puede ser usada para desarrollar soluciones basadas sobre
cualquier tecnologa.

MSF se compone de varios modelos encargados de planificar las diferentes partes implicadas en el
desarrollo de un proyecto: Modelo de Arquitectura del Proyecto, Modelo de Equipo, Modelo de Proceso,
Modelo de Gestin del Riesgo, Modelo de Diseo de Proceso y finalmente el modelo de Aplicacin.

Modelo de Arquitectura del Proyecto: Diseado para acortar la planificacin del ciclo
de vida. Este modelo define las pautas para construir proyectos empresariales a travs
del lanzamiento de versiones.

Modelo de Equipo: Este modelo ha sido diseado para mejorar el rendimiento del
equipo de desarrollo. Proporciona una estructura flexible para organizar los equipos de
un proyecto. Puede ser escalado dependiendo del tamao del proyecto y del equipo de
personas disponibles.

Modelo de Proceso: Diseado para mejorar el control del proyecto, minimizando el

riesgo, y aumentar la calidad acortando el tiempo de entrega. Proporciona una
estructura de pautas a seguir en el ciclo de vida del proyecto, describiendo las fases, las
actividades, la liberacin de versiones y explicando su relacin con el Modelo de
equipo.

Modelo de Gestin del Riesgo: Diseado para ayudar al equipo a identificar las
prioridades, tomar las decisiones estratgicas correctas y controlar las emergencias que
puedan surgir. Este modelo proporciona un entorno estructurado para la toma de
decisiones y acciones valorando los riesgos que puedan provocar.

Modelo de Diseo del Proceso: Diseado para distinguir entre los objetivos
empresariales y las necesidades del usuario. Proporciona un modelo centrado en el
usuario para obtener un diseo eficiente y flexible a travs de un enfoque iterativo. Las
fases de diseo conceptual, lgico y fsico proveen tres perspectivas diferentes para los
tres tipos de roles: los usuarios, el equipo y los desarrolladores.

Modelo de Aplicacin: Diseado para mejorar el desarrollo, el mantenimiento y el

soporte, proporciona un modelo de tres niveles para disear y desarrollar aplicaciones
software. Los servicios utilizados en este modelo son escalables, y pueden ser usados en
un solo ordenador o incluso en varios servidores.

Conclusin:

La Metodologa XP en cambio, se recomienda para proyectos de corto plazo.

La Metodologa MSF se adapta a proyectos de cualquier dimensin y de cualquier tecnologa.

Podemos concluir adems, que lo ms importante antes de elegir la metodologa que usars para
la implementacin de tu software, es determinar el alcance que tendr y luego de ah ver cual es
la que ms se acomoda en tu aplicacin.

Metodologia Agil MSF (Microsoft Solution FrameWork)

La metodologia MSF es del tipo de metodologias agiles, esta enfocada a dirigir
proyectos o soluciones de innovacion, en ella no se detalla ni se hace enfasis de la
organizacion ni el tamao del equipo de desarrollo, esta mas bien centrada en la
gestion y administracion del proyecto para lograr el impacto deseado.
Involucra indudablemente la calidad ya que prevee liberar una solucion si esta aun
tiene fallos o desperfectos para ello propone seleccionar un grupo de prueba piloto
el cual es una VERSION BETA y cumplido un tiempo de prueba ya es liberada la
version formal o VERSION ALFA en la cual est garantizada la calidad.
Consta de 5 fases:

Vision: En esta fase se debe realizar un estudio de lo que pretendemos en

el futuro que haga nuestra aplicacion o nuestro proyecto para ello debemos
realizar un documento de estrategia y alcande donde debe quedar pactada
la nececidad de funcionalidad y servicio que se debe contar en la solucion.
Debemos crear los equipos de trabajo junto con el plan de trabajo, Para
asegurar el exito del proyecto es importante tener en cuenta el analisis de
riesgos y plan de contingencia.

Planificacion: En esta fase basicamente debemos concreatar claramente

como va a estar estructurada nuestra solucion para ello debemos crear un
documento de planificacion y diseo de la arquitectura, disear las pruebas
de concepto donde se plantean los diferentes escenarios para probar la
validez de los criterios utilizados para el diseo, debemos establecer
metricas.

Desarrollo: En la etapa de desarrollo debemos codificar las aplicaciones y

realizar las configuraciones necesarias para que la solucion funcione, es
importante hacer pruebas continuamente asi se verifica la calidad del
producto continuamente a lo largo del desarrollo y no unicamente al final de
el proceso.

Estabilizacion: Esta fase debemos seleccionar el entorno de prueba piloto y

lo que pretendemos con esto es identifiar las deficiencias con un grupo
reducido de usuarios para corregirlas y asi en el futuro no tener problemas
cuando se use la solucion por todos, ocacionalmente a esta etapa se le llama
BETA, debemos crear un plan de gestion de incidencias, realizar una revision
de documentacion final de la arquitectura y Elaboracion de plan de
despliegue o implementacion.

Despliegue o Implementacion: En esta etapa final ya se ha comprobado

la calidad de la solucion por lo cual esta lista para ser publicada, en este

sentido debemos liberar la solucion y crear un registro de mejoras y

sugerencias, revisar las guias y manuales y entrega de proyecto final.
Este ciclo se puede llevar a cabo de forma iterativa, de manera que cuando
liberamos una solucion podemos iniciar nuevamente la metodologia para darle mas
funcionalidad.

Metodologa Kendall & Kendall

El ciclo de vida de vida del desarrollo de sistemas (SDLC, Systems

Development life cycle) es un enfoque por fases para el anlisis y el diseo
cuya premisa principal consiste en que los sistemas se desarrollan mejor
utilizando un ciclo especifico de actividades del analista y el usuario.
(Kendall & Kendall)
Segn la metodologa de Kendall & Kendall el ciclo de vida de un sistema
consta de siete partes: siendo la primera la identificacin del problema, la
segunda identificacin de requisitos de informacin, la tercera es el anlisis
de las necesidades del sistema, la cuarta es el diseo del sistema
recomendado, la quinta desarrollo y documentacin del sistema, la sexta
prueba y mantenimiento y la ltima implementacin y evaluacin. Cada
fase se explica por separado pero nunca se realizan como pasos aislados,
ms bien es posible que algunas actividades se realicen de manera
simultnea, y algunas de ellas podran repetirse.

FASE I: Identificacin de problemas, oportunidades y objetivos

FASE II: Determinacin de los requerimientos de informacin
FASE III: Anlisis de las necesidades del sistema
FASE IV: Diseo del sistema recomendado
FASE V: Desarrollo y documentacin del software
FASE VI: Prueba y mantenimiento del sistema

FASE VII: Implementacin y evaluacin

Metodologa UML:
La metodologa que se propone, denominada UML-MAST, concilia las
diferencias entre la visin del diseador de sistemas de tiempo real y la del
de sistemas orientados a objetos. A tal fin define un nivel de abstraccin
adecuado para los elementos de modelado del comportamiento de tiempo
real, que permite formularlos con una estructura paralela a la arquitectura
lgica del sistema, y vincularlos a esta. La semntica de modelado sigue el
perfil UML para planificabilidad, rendimiento y tiempo (SPT) estandarizado
por el OMG, del que UML-MAST puede considerase una implementacin. La
propuesta se integra con las herramientas de anlisis y diseo de sistemas
de tiempo real MAST (Modeling and Analysis Suite for Real-Time
Applications), que analiza los modelos y retorna los resultados al modelo
inicial para su interpretacin por el diseador. Asimismo, se han definido
criterios para la extensin de esta metodologa a otros niveles de
abstraccin tales como sistemas basados en componentes y sistemas
implementados utilizando Ada 95. Parte de los resultados de este trabajo
han sido incorporados por el OMG a su perfil SPT.
Lenguaje Unificado de Modelado (UML, por sus siglas en ingls, Unified
Modeling Language) es el lenguaje de modelado de sistemas de software
ms conocido y utilizado en la actualidad; est respaldado por el OMG
(Object Management Group). Es un lenguaje grfico para visualizar,
especificar, construir y documentar un sistema. UML ofrece un estndar
para describir un "plano" del sistema (modelo), incluyendo aspectos
conceptuales tales como procesos de negocio y funciones del sistema, y
aspectos concretos como expresiones de lenguajes de programacin,
esquemas de bases de datos y componentes reutilizables.
Es importante resaltar que UML es un "lenguaje de modelado" para
especificar o para describir mtodos o procesos. Se utiliza para definir un
sistema, para detallar los artefactos en el sistema y para documentar y
construir. En otras palabras, es el lenguaje en el que est descrito el
modelo.
Se puede aplicar en el desarrollo de software entregando gran variedad de
formas para dar soporte a una metodologa de desarrollo de software (tal
como el Proceso Unificado Racional o RUP), pero no especifica en s mismo
qu metodologa o proceso usar.
UML no puede compararse con la programacin estructurada, pues UML
significa Lenguaje Unificado de Modelado, no es programacin, solo se
diagrama la realidad de una utilizacin en un requerimiento. Mientras que,
programacin estructurada, es una forma de programar como lo es la
orientacin a objetos, sin embargo, la programacin orientada a objetos
viene siendo un complemento perfecto de UML, pero no por eso se toma
UML slo para lenguajes orientados a objetos.
UML cuenta con varios tipos de diagramas, los cuales muestran diferentes
aspectos de las entidades representadas.

Lenguaje Unificado de Modelado (LUM o UML, por sus siglas en ingls, Unified
Modeling Language) es el lenguaje de modelado de sistemas de software ms conocido
y utilizado en la actualidad; est respaldado por el OMG (Object Management Group).
Es un lenguaje grfico para visualizar, especificar, construir y documentar un sistema.
UML ofrece un estndar para describir un "plano" del sistema (modelo), incluyendo
aspectos conceptuales tales como procesos de negocio, funciones del sistema, y
aspectos concretos como expresiones de lenguajes de programacin, esquemas de bases
de datos y compuestos reciclados.

Es importante remarcar que UML es un "lenguaje de modelado" para especificar o para

describir mtodos o procesos. Se utiliza para definir un sistema, para detallar los
artefactos en el sistema y para documentar y construir. En otras palabras, es el lenguaje
en el que est descrito el modelo.
Se puede aplicar en el desarrollo de software gran variedad de formas para dar soporte a
una metodologa de desarrollo de software (tal como el Proceso Unificado Racional o
RUP), pero no especifica en s mismo qu metodologa o proceso usar.
UML no puede compararse con la programacin estructurada, pues UML significa
Lenguaje Unificado de Modelado, no es programacin, solo se diagrama la realidad de
una utilizacin en un requerimiento. Mientras que, programacin estructurada, es una
forma de programar como lo es la orientacin a objetos, sin embargo, la programacin
orientada a objetos viene siendo un complemento perfecto de UML, pero no por eso se
toma UML slo para lenguajes orientados a objetos.
UML cuenta con varios tipos de diagramas, los cuales muestran diferentes aspectos de
las entidades representadas.

UML [UML] es un lenguaje para especificar, construir, visualizar y documentar los

artefactos de un sistema de software orientado a objetos (OO). Un artefacto es una
informacin que es utilizada o producida mediante un proceso de desarrollo de
software.
UML se quiere convertir en un lenguaje estndar con el que sea posible modelar todos
los componentes del proceso de desarrollo de aplicaciones. Sin embargo, hay que tener
en cuenta un aspecto importante del modelo: no pretende definir un modelo estndar de
desarrollo, sino nicamente un lenguaje de modelado. Otros mtodos de modelaje como
OMT (Object Modeling Technique) o Booch s definen procesos concretos. En UML los
procesos de desarrollo son diferentes segn los distintos dominios de trabajo; no puede
ser el mismo el proceso para crear una aplicacin en tiempo real, que el proceso de
desarrollo de una aplicacin orientada a gestin, por poner un ejemplo.

Las diferencias son muy marcadas y afectan a todas las faces del proceso. El mtodo del
UML recomienda utilizar los procesos que otras metodologas tienen definidos.
Leer ms: http://www.monografias.com/trabajos5/insof/insof.shtml#ixzz2M7DJzVqc

UML es una metodologa de desarrollo de software?

No, UML no es una metodologa de desarrollo y te voy a comentar un poco
que es y su origen. En la dcada de los ochentas y parte de los noventas
existieron muchas propuestas de diagramas para realizar analisis y diseo
de los mismos. Entonces, es por ah de 1994 cuando la empresa Rational
decide contratar a 3 personas para que con sus propuestas crearan un solo
lenguaje para hacer anlisis y diseo de sistemas.
Algo as como existe una notacin especial en la rama de la qumica con sus
frmulas, o de la msica con sus notas, de tal forma que un msico o
qumico del otro lado del mundo puede interpretar una partitura o una
frmula qumica de alguien que la escribe aqu en Mxico. Algo as se
intent crear con UML, un lenguaje que pudiera entender cualquier
ingeniero de software aqu o en china.
Pues bien, quisieron crear un Lenguaje Unificado para el rea de anlisis y
diseo de sistemas de informacin. Lo cual dio origen a un conjunto de
varios diagramas posibles a usar:
Diagramas Estructurales
Diagrama de Clases
Diagrama de Objetos
Diagrama de Componentes
Diagrama de Estructura Compuesta
Diagrama de Despliegue
Diagrama de Paquetes
Diagrama de Comportamiento
Diagrama de Interaccin
Diagrama de Secuencia
Diagrama de Comunicaciones
Diagrama de Descripcin de la Interaccin
Diagrama de Tiempos
Diagrama de Actividades
Diagrama de Casos de Uso
Diagrama de Mquina de Estados
Es necesario usar todos? No, realmente tu usas los que necesites para
representar tu arquitectura del sistema.
Entonces que es UML? Es un lenguaje (o conjunto de diagramas) que te
sirven para analizar, disear e interpretar la arquitectura de un sistema
computacional.
- Una respuesta ms breve, directa que la que te dieron es difcil.
Como te lo han dicho: NO.
Una metodologa busca definir el que y como, estructurar las actividades
para conducir el proyecto. En cambio UML es una de las tantas herramientas
que uno puede o no utilizarlas. A algunos les resultar tedioso, aburrido, y

hasta innecesario; pero a otros les sirve de mucha ayuda para aclarase las
dudas y hacer un mejor anlisis y una mejor propuesta.