METODOLOG

IA
ORIENTADA
A OBJETOS

NOMBRE

CARACTERICTICAS

BOOCH

Booch es una
metodologa
desarrollada por
Grady Booch en
1996. Cubre las fases
de anlisis y diseo de
un sistema
orientado a objetos.
Se enfoca
principalmente al
diseo de
estado de un proyecto
por la riqueza de su
notacin
reflejada en las
interacciones entre
entidades. Soporta el
desarrollo iterativo e
incremental de un
sistema. En muchas
ocasiones es criticada
por el uso de muchos
smbolos
distintos.
La metodologa de
Booch usa los
siguientes tipos de
diagramas para
describir las
decisiones de anlisis
y diseo,
tcticas y
estratgicas, que
deben ser hechas en
la creacin
de un sistema
orientado por objetos.

VENTAJAS
1) Establece un
lenguaje de enlace
para expresar el
modelado de datos
entre analistas,
usuarios,
programadores y en
general, personas
involucradas en un
proyecto de
desarrollo.
2) Permite llegar de
manera guiada y
prcticamente
automtica, a un
diseo y desarrollo
correcto y
normalizado
(siempre y cuando
la definicin de
objetos sea correcta
de acuerdo a la
realidad de
negocio).
3) Proximidad de los
conceptos de
modelado respecto
a objetos del mundo
real
4) Conduce de
manera fcil y
rpida a un
incremento de la
productividad.
5) Tambin usa
tcnicas de

DESVENTAJAS

Quizs una de ellas

sea que a la hora de
realizar el anlisis y
los requerimientos,
se torna un poco
complicado o difcil
segn lo cita el
autor Roger S.
Pressman en su libro
ingeniera del
Software.
El Anlisis Orientado
objetos no se enfoca
directamente para
luego modelar
procesos de
negocios, por lo que
no est orientado a
lo que necesita el
experto en el
dominio del negocio.
Predispone un
enfoque orientado a
objetos lo que puede
contradecir un
enfoque orientado
al negocio.

FASES

Anlisis de
requerimientos
se establecen los
requerimientos desde una
perspectiva del consumidor
o usuario, ste paso genera
una descripcin de alto nivel
del funcionamiento y de la
estructura del sistema.
Anlisis de Dominio
se definen las clases, sus
atributos, la herencia de
clases y mtodos de stas.
Los diagramas de los
objetos son realizados
posteriormente.
Diseo
Un diseo lgico es
mapeado fsicamente en
donde los detalles de la
ejecucin, procesos,
rendimiento, tipo de datos,
estructura de datos,
visibilidad y distribucin son
establecidos.

razonamiento
similar usadas para
resolver problemas
en otros dominios

OBJETORY

ObjectOry,
una metodologia
basada en el
paradigma de
orientacin a objetos,
fue creada por la
compaa Objectory
Systems, fundada en
1987 por Jacobson. Es
un proceso
organizado para la
construccin industrial
de software. Este
proceso de diseo
est guiado por casos
de uso, una tcnica
que centra el
entendimiento de un
sistema en la forma
en la cual es usado.

El Mtodo OORAM se
remonta a principios
de los aos 70
e introduce el

Permiten el desarrollo
de un sistema a partir
de requisitos poco
claros o cambiantes.
Esto ocurre con cierta
frecuencia en muchos
proyectos de software.
2.
Como
informacin
complementaria a los
requisitos constituyen
un gran apoyo a las
estimaciones de
esfuerzo de todas las
reas, incluyendo
proveedores.
3.
Son ms fciles
de abordar con los
usuarios finales.
4.
El usuario
participa ms
activamente en la
construccin del
producto de software
(La Solucin), ya que
lo puede ver y,
dependiendo del tipo
de prototipo,
utilizar desde el
primer momento.

Se puede usar para

diferentes tipos de

El usuario quiere
empezar a trabajar
desde el primer
momento con el
prototipo para
solucionar su
problema particular,
cuando el prototipo es
solo un modelo de lo
que ser el producto.
2.
Los prototipos
generan o pueden
generar otro tipo de
problemas si su
presentacin y
discusin con los
usuarios no es
controlada: puesto que
son modelos
inconclusos, los
usuarios suelen
enfocarse en aspectos
superficiales del
prototipo que los
pueden dejar
inconformes luego de
verlos por primera
vez. Tambin es
posible que se pierda
mucho tiempo,
innecesariamente,
tratando de hacer
entender al usuario la
finalidad real de los
prototipos.

no es un mtodo de
desarrollo.

Modelo de
requerimientos
Modelo de Casos de Uso con
interfaces de usuario
del sistema.
Modelo de objetos del
dominio.
Modelo de anlisis
Modelo de objetos con
objetos Entidades, de
Interfaz y de Control
Modelo de diseo
Modelo de paquetes.
Definicin de mdulos en la
implementacin y detalle de
las clases de diseo en
cada uno de ellos.
Implementacin
Cdigo de las clases,
organizado por paquetes.
Pruebas
Definicin de pruebas de
unidad
Definicin de pruebas de
protocolo de clases.

Tecnologa
(conceptos, notacin,
tcnicas y
herramientas): donde se

OORAM

OMT

concepto de modelo
de roles como
principal
mecanismo de
abstraccin.
El modelo de roles
describe los objetos
que participan en
una actividad y las
interacciones entre
ellos. El mtodo
OOram se define
como un marco de
referencia para una
familia de
metodologas
orientadas-a-objetos,
tras lo que se
muestran las mejoras
que el mtodo
introduce en las tres
dimensiones tpicas
que componen el
grueso de
metodologas

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

sistemas
consolida muchas de
las notaciones y
conceptos ms usadas
orientados a objetos.

Proporciona una serie

de pasos
perfectamente
definidos al
desarrollador.
Tratamiento especial
de la herencia.
Facilita el
mantenimiento dada

al no ser un mtodo
de desarrollo es
independiente del
ciclo de desarrollo
no se presta con
facilidad al diseo de
sistemas distribuidos.

Hay pocos mtodos

para encontrar
inconsistencias en los
modelos.
Interaccin de objetos
no soportada
explcitamente en
ninguna herramienta
grfica.

muestran el poderoso
modelado de roles en
anlisis y su integracin
posterior -sntesis en
OOram-, junto con los
conceptos bsicos (roles,
puertos -que anuncian la
visibilidad de un rol respecto
de otro-, etc.) y
algunas herramientas.
Proceso con Entregables
(la secuencia de pasos y la
documentacin que los
acompaa): OOram
distingue tres distintos
procesos: creacin del
modelo, desarrollo del
sistema y construccin de
piezas reutilizables.
Organizacin
(las maneras en que la
empresa
acoge lo anterior): aqu se
explicitan las dificultades de
disear para reutilizar y las
ventajas que supone el uso
de cadenas de valor.

Anlisis
Documento de anlisis, que
incluye:
Descripcin del problema
Modelo de Objetos
Modelo dinmico
Modelo funcional
Diseo del sistema
Definicin de subsistemas
Diseo de objetos

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.

RUP

RUP es un marco de
trabajo genrico que
puede
especializarse para
una gran variedad de
sistemas de
software, para
diferentes reas de
aplicacin, diferentes
tipos de
organizaciones,
diferentes niveles de
aptitud y diferentes
tamaos de
proyectos.
RUP divide el proceso
de desarrollo en
ciclos, teniendo un

la gran cantidad de
informacin que se
genera en el anlisis.
Es fuerte en el
anlisis

-Es el proceso de
desarrollo ms
general de los
existentes
actualmente.
-Es una forma
disciplinada de
asignar tareas y
responsabilidades en
una empresa de
desarrollo (quin hace
qu, cundo y cmo).

Al ser un anlisis
iterativo es difcil de
saber cuando
comenzar con el
diseo.
Es dbil en el diseo

Por el grado de
complejidad puede no
resultar muy
adecuado.
RUP es generalmente
mal aplicado en el
estilo cascada.

Documento de diseo, que

incluye versiones detalladas
de los modelos de objetos,
dinmico y funcional.
Implementacin
Diseo de bases de datos, si
se requieren.

Modelamiento del
Negocio
Describe los procesos de
negocio, identificando
quines participan y las
actividades que requieren
automatizacin.
Requerimientos
Define qu es lo que el
sistema debe hacer, para lo
cual se identifican las
funcionalidades requeridas y
las restricciones que
se imponen.
Anlisis y Diseo
Describe cmo el sistema
ser
realizado a partir de la
funcionalidad prevista y las
restricciones impuestas
(requerimientos), por lo
que indica con precisin lo

producto funcional al
final de cada ciclo,
cada ciclo se divide en
fases que finalizan
con un hito donde se
debe tomar una
decisin importante.

que se debe programar.

Implementacin
Define cmo se organizan
las
clases y objetos en
componentes, cules nodos
se utilizarn y la ubicacin
en ellos de los componentes
y la estructura de las capas
de la aplicacin.
Pruebas
Busca los defectos a lo largo
del ciclo de vida.

METODOLOG
IAS AGILES

DSDM

La metodologia DSDM
es caracterizada por
su rapidez de
desarrollo atendiendo
a las demandas de
tecnologia de forma
eficaz y eficiente
previendo que
transcurra mucho
tiempo y la tecnologia
cambie.
Es una metodologia
agil situada dentro de
las RAD(rapid
aplication
development), es
ideal para proyectos
de sistemas de
informacion cuyos

- Trabajo en equipo
tanto los
desarrolladores, los
usuarios y los
Stakeholders.
- El equipo de
desarrollo puede
tomar sus deciciones
sin depender de
autorizaciones de sus
superiores.
- El desarrollo es
iterativo e incremental
El equipo de desarrollo
debe realizar entregas

Ningun sistema es
construido a la
perfeccion en el
primer intento.
La entrega del
proyecto debera ser a
tiempo, respetando
presupuesto y
asegurando la calidad.
DSDM solo quiere que
se complete la
iteracion con la
funcionalidad
suficiente como para
que inicie la siguiente
iteracion.
DSDM es utilizado en
sistemas TI pero
tambien pudiera ser
utilizado para

Estudio de Viabilidad:
estudio de
requerimientos
(humanos, materiales y
financieros) y los
problemas de la empresa
o cliente.
Estudio de la Empresa:
como planificar las
actividades de la
empresa.
Iteracion del Modelo
Funcional: plantear un
modelo previo que de

SCRUM

presupuestos y
agendas son muy
apretadas.
DSDM consiste en
tecnicas de desarrollo
y gestion del proyecto
en la misma
metodologia.

cortas pero
frecuentemente, estas
entregas deben ser
funcionales.
Todos los cambios
pueden ser
revertibles, es decir,
debemos tener una
linea base y a partir
de ella crear
funcionalidad, pero si
no tenemos los
resultados deseados
podemos regresar a la
linea base
nuevamente.
La verificacion de
calidad debe existir a
lo largo del proceso de
desarrollo y no
solamente en al final
del proyecto.

proyectos en donde se
requiera cambio de
algun sistema aunque
no sea TI.
La evaluacion de
riesgo debe estar
enfocada en entregar
funcionalidad no en el
proceso de desarrollo
La estimacion debe
estar basada en
funcionalidad del
negocio.

solucion aceptable a la
problematica, esta es la
etapa de diseo.
Diseo e Iteracion de
Estructura: se realiza la
codificacion de la
solucion, se prueba
paralelamente la calidad
del producto y se
documenta el manual de
usuario y tecnico.
Implementacion:
entrega del producto al
cliente o usuario final.

Aproximadamente en
1986 Hirotaka
Takeuchi e Ikujiro
Nonaka describieron
una nueva forma para
el desarrollo
productos
comerciales, que
incrementaba la
rapidez y la
flexibilidad en el
proceso. Ellos
comparan este nuevo
mtodo, en la cual las
fases se traslapan de
manera intensa y el
proceso completo es
realizado por un
equipo con funciones

El cliente puede
comenzar a utilizar el
producto
rpidamente.
El cliente puede
decidir los nuevos
objetivos a realizar.
Se agila el proceso,
porque se divide el
problema en
pequeas tareas.
Menos probabilidad de
que se den sorpresas
o desarrollos
inesperados porque el
cliente va viendo poco
a poco lo que se est
desarrollando.

Existe la tendencia
que si se deja una
tarea sin terminar y
que por las exigencias
del Dueo del
Producto se deban
realizar otras nuevas.
Estas tareas no
terminadas puedan
obstaculizar la
planeacin de nuevas
sprints y se deba
volver al problema
original.
Alto nivel de stress de
los miembros del
equipo, el desgaste
puede ser excesivo y
estresante lo que

La Pila de Producto
(Product BackLog), que es
una lista de todas las cosas
Por Realizar del proyecto.
Esta lista es confeccionada
por el Dueo del Producto
de acuerdo a los
requerimientos y esta
ordenada por la prioridad
que tiene cada elemento en
la pila.
La Pila del Sprint (Sprint
BackLog), son las
actividades que se van a
realizar dentro de un sprint.
El Grafico de Trabajo
Pendiente (Burndown
Chart). Representa
visualmente el trabajo que

diversas, como en el
rugby, donde el
equipo entero acta
como un solo hombre
para intentar llegar al
otro lado del campo,
pasando el baln de
uno a otro. Estos
casos de estudio se
originan de las
industrias
automovilsticas, as
como de fabricacin
de mquinas
fotogrficas,
computadoras e
impresoras.
En 1991 Peter
DeGrace y Leslie Stahl
en su libro Wicked
Problems, Righteous
Solutions, se refirieron
a esta aproximacin
como Scrum, un
trmino propio del
rugby mencionado en
el artculo por
Takeuchi y Nonaka.

puede disminuir el
rendimiento.
La necesidad de
contar con equipos
multidisciplinarios
puede ser un
problema, porque
cada integrante del
equipo debe estar en
capacidad de resolver
cualquier tarea y no
siempre se cuenta con
este perfil en la
empresa.
El equipo puede estar
tentado de tomar el
camino ms corto para
cumplir con un sprint,
que no
necesariamente puede
ser el de mejor calidad
en el desarrollo del
producto.

est por hacer versus el

tiempo restante del
proyecto. El trabajo
pendiente se representa en
el eje vertical y el tiempo en
el eje horizontal.
Se definen tres reuniones
que se deben realizar
utilizando el mtodo Scrum:
Planeacin del Sprint
(Scrum Planning), con la
ayuda del Product Owner y
el Scrum Master y el equipo,
se compromete con las
actividades que se deben
realizar de la Pila del
Producto.
Reunin Diario de Scrum
(Daily Scrum), esta
actividad se lleva a cabo
todos los das y debe durar
quince minutos o menos.
Durante esta reunin el
Scrum Master debe
determinar los problemas e
identificar si estos se
pudieran convertir en un
impedimento para
completar el proyecto.
Revision del Sprint
(Sprint Review). Al final
del sprint se muestra a los
clientes y al Dueo del
Producto lo que ha
terminado el equipo.
Retrospectiva del Sprint
(Sprint Retrospective).
Esta reunin tambin se
lleva al final del Sprint, y a
diferencia de la Revisin del
Sprint, sirve para mejorar al
equipo.

XP

RUP

Es una metodologa
gil centrada en
potenciar las
relaciones
interpersonales como
clave para el xito en
desarrollo de
software,
promoviendo el
trabajo en equipo,
preocupndose por el
aprendizaje de los
desarrolladores, y
propiciando un buen
clima de trabajo. XP
se basa en
realimentacin
continua entre el
cliente y el equipo de
desarrollo,
comunicacin fluida
entre todos los
participantes,
simplicidad en las
soluciones
implementadas y
coraje para enfrentar
los cambios. XP se
define como
especialmente
adecuada para
proyectos con
requisitos imprecisos
y muy cambiantes, y
donde existe un alto
riesgo tcnico.

Programacin
organizada.
Menor taza de
errores.
Satisfaccin del
programador.
Solucin de errores
de programas
Versiones nuevas
Implementa una
forma de trabajo
donde se
adapte fcilmente a
las circunstancias

Es recomendable
emplearlo solo en
proyectos a corto
plazo
Altas comisiones en
caso de fallar
Imposible prever todo
antes de programar
Demasiado costoso e
innecesario

1. El principio de pruebas
2. Proceso de
planificacin
3. El cliente en el lugar
4. Programacin en
parejas
5. Integracin continua
6. Refactorizacin
7. Entregas pequeas
8. Diseo simple
9. Metfora
10. Propiedad colectiva
del cdigo
11. Estndar de
codificacin
12. La semana de 40
horas

Sus caractersticas es
que es iterativo e
incremental y est
basada mucho en los
casos de uso, tambin
sus caractersticas es
que verifica de

Comprar puede
ahorrar dinero en
comparacin con
construir.
Los entregables
pueden ser facilmente
trasladados a otra

Comprar puede ser

ms caro que
construir.
Costo de herramientas
integradas y equipo
necesario.
Progreso ms difcil de

1.- Fase de inicio

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

manera seguida la
calidad del software y
administrar los
requisitos. Este
proceso de desarrollo
tiene tanto artefactos
como roles (que son
las personas que
estn encargadas
dentro del desarrollo o
proceso).

plataforma.
El desarrollo se realiza
a un nivel de
abstraccin mayor.
Visibilidad temprana.
Mayor flexibilidad.
Menor codificacin
manual.
Mayor
involucramiento de los
usuarios.
Posiblemente menos
fallas.
Posiblemente menor
costo.
Ciclos de desarrollo
ms pequeos.

medir.
Menos eficiente.
Menor precisin
cientfica.
Riesgo de revertirse a
las prcticas sin
control de antao.
Ms fallas (por
sndrome de "codificar
a lo bestia").
Prototipos pueden no
escalar, un problema
maysculo.
Funciones reducidas
(por "timeboxing").
Dependencia en
componentes de
terceros: funcionalidad
de ms o de menos,
problemas legales.

enmarca en el negocio, el
alcance del proyecto.
2.- Modelado del negocio
En esta fase el equipo se
familiarizar ms al
funcionamiento de la
empresa, sobre conocer sus
procesos.
3.- Requisitos
En esta lnea los requisitos
son el contrato que se debe
cumplir, de modo que los
usuarios finales tienen que
comprender y aceptar los
requisitos que
especifiquemos.
4.- Fase de elaboracin
Se realiza el plan de
proyecto, donde se
completan los casos de uso
y se mitigan los riesgos.
5.- Anlisis y Diseo
En esta actividad se
especifican los
requerimientos y se
describen sobre cmo se
van a implementar en el
sistema.
6.- Fase de construccin
Se basa en la elaboracin de
un producto totalmente
operativo y en la
elaboracin del manual de
usuario.
7.- Implementacin
Se implementan las clases y
objetos en ficheros fuente,
binarios, ejecutables y
dems. El resultado final es
un sistema ejecutable.
8.- Pruebas
Este flujo de trabajo es el
encargado de evaluar la
calidad del producto que

estamos desarrollando, pero

no para aceptar o rechazar
el producto al final del
proceso de desarrollo
9.- Etapa de transicin
El objetivo es llegar a
obtener el release del
proyecto. Se realiza la
instalacin del producto en
el cliente y se procede al
entrenamiento de los
usuarios.
10.- Despliegue
Esta actividad tiene como
objetivo producir con xito
distribuciones del producto
y distribuirlo a los usuarios.

RAD

Equipos compuestos
por alrededor de seis
personas, incluyendo
desarrolladores y
usuarios de tiempo
completo del sistema
as como aquellas
personas involucradas
con los requisitos.
Los desarrolladores de
RAD deben ser
"renacentistas":
analistas, diseadores
y programadores en
uno.

Comprar puede
ahorrar dinero en
comparacin con
construir.
Los entregables
pueden ser facilmente
trasladados a otra
plataforma.
El desarrollo se realiza
a un nivel de
abstraccin mayor.
Visibilidad temprana.
Mayor flexibilidad.
Menor codificacin
manual.
Mayor

Comprar puede ser

ms caro que
construir.
Costo de herramientas
integradas y equipo
necesario.
Progreso ms difcil de
medir.
Menos eficiente.
Menor precisin
cientfica.
Riesgo de revertirse a
las prcticas sin
control de antao.
Ms fallas (por
sndrome de "codificar
a lo bestia").
Prototipos pueden no
escalar, un problema
maysculo.
Funciones reducidas
(por "timeboxing").

Modelado de gestin: el
flujo de informacin entre
las funciones de gestin se
modela de forma que
responda a las siguientes
preguntas: Qu
informacin conduce el
proceso de gestin? Qu
informacin se genera?
Quin la genera? A dnde
va la informacin? Quin la
proceso?
Modelado de datos: el
flujo de informacin definido
como parte de la fase de
modelado de gestin se
refina como un conjunto de
objetos de datos necesarios
para apoyar la empresa.
Modelado de proceso: los
objetos de datos definidos
en la fase de modelado de
datos quedan transformados
para lograr el flujo de
informacin necesario para
implementar una funcin de

involucramiento de los
usuarios.
Posiblemente menos
fallas.
Posiblemente menor
costo.
Ciclos de desarrollo
ms pequeos.

METODOLOG
IAS WEB

UWE

1.- es una
metodologa detallada
para el proceso de
autora de
aplicaciones con una
definicin exhaustiva
del proceso de diseo
que debe ser utilizado.
Este proceso, iterativo
e incremental, incluye
flujos de trabajo y
puntos de control, y
sus fases coinciden
con las propuestas en
el Proceso Unificado
de Modelado.UWE
est especializada en
la especificacin de
aplicaciones
adaptativas, y por
tanto
hace especial hincapi
en caractersticas

1.-ventajas
* Uso exclusivo de
estndares
reconocidos como
UML compatible con
internacionalmente.
*Establece un
formalismo ms rgido

Dependencia en
componentes de
terceros: funcionalidad
de ms o de menos,
problemas legales.

1.- Desventajas
* Uso de restricciones
escritas

gestin.
Generacin de
aplicaciones: El DRA
asume la utilizacin de
tcnicas de cuarta
generacin. En lugar de
crear software con lenguajes
de programacin de tercera
generacin, el proceso DRA
trabaja para volver a utilizar
componentes de programas
ya existentes (cuando es
posible) o a crear
componentes reutilizables
(cuando sea necesario).
Pruebas de entrega:
Como el proceso DRA
enfatiza la reutilizacin, ya
se han comprobado muchos
de los componentes de los
programas.
1) Captura, anlisis y
especificacin de
requisitos: En simple
palabras y bsicamente,
durante esta fase, se
adquieren, renen y
especifican las
caractersticas funcionales
y no funcionales que
deber cumplir la
aplicacin web.
2) Diseo del sistema:
Se basa en la especificacin
de
requisitos producido por el
anlisis de los
requerimientos (fase de
anlisis).
3) Codificacin del software:
Durante esta etapa se
realizan las tareas que
comnmente se conocen

de personalizacin,
como es la definicin
de un modelo de
usuario o una etapa
de definicin de
caractersticas
adaptativas de la
navegacin en funcin
de las preferencias,
conocimiento o tareas
de usuario.Otras
caractersticas
relevantes del proceso
y mtodo de autora
de UWE son el uso del
paradigma orientado a
objetos, su orientacin
al usuario, la
definicin de un metamodelo (modelo de
referencia) que da
soporte al mtodo y el
grado de formalismo
que alcanza debido al
soporte que
proporciona para

como programacin
4) Pruebas:
Las pruebas se utilizan para
asegurar el correcto
funcionamiento de
secciones de cdigo
5) La Instalacin o Fase de
Implementacin: Proceso por
el cual los programas
desarrollados son
transferidos apropiadamente
al computador destino
6) El Mantenimiento:
es el proceso de control,
mejora y optimizacin del
software ya desarrollado e
instalado, que tambin incluye
depuracin de errores y
defectos que puedan haberse
filtrado de la fase de pruebas
descontrol.

la definicin de
restricciones sobre los
modelos.

(Enhanced Object
Relationship
Methodology)

EORM

Es un proceso iterativo
que se concentra en el

3 ventajas

3.desventajas

*Flexibilidad
entrerelaciones de
los nodos.

*Problemas
afuncionamiento
delsistema o
aspectos deinterfaz.

1. FASE DE ANALISIS
Se realizar un estudio de las
necesidades de la
aplicacin, del entorno de
trabajo y de los actores..
2. FASE DE DISEO.
Un proceso o un Sistema,
con suficientes detalles

modelado orientado a
objetos y por la

*La reutilizacin
decdigo y libreras.

representacin de
relaciones entre estos.
Fue una de las
primeras propuestas
para aplicaciones

*Encajamiento
derelaciones
semnticas

Web centrada en
el paradigma de la
orientacin a
objetos.

*La captura
derequisitos es
muy pobre.
*Falta de
comentarios o
documentaci
n.

como para permitir su

interpretacin y realizacin
fsica. La etapa del Diseo
del Sistema encierra cuatro
etapas:
A. El diseo de los
datos Trasforma el modelo
de dominio de la
informacin, creado durante
el anlisis
B. El Diseo
Arquitectnico Define la
relacin entre cada uno de
los elementos estructurales
del programa.
C. El Diseo de la
Interfaz Describe como se
comunica el Software
consigo mismo.
D. El Diseo de
procedimientos
Transforma elementos
estructurales de la
arquitectura del programa.
3. FASE DE
IMPLEMENTACION
Y SALIDA A PRODUCCION
La fase de implementacin es
conocida tambin como fase
de codificacin, pues supone
todo el proceso de escribir el
cdigo software necesario
que har posible que el
sistema.

OOHDM

OOHDM es una
metodologa de
desarrollo propuesta
por Rossi y Schwabe
(ROSSI 1996) para la
elaboracin de
aplicaciones
multimedia y tiene
como objetivo
simplificar y a la vez
hacer ms eficaz el
diseo de aplicaciones
hipermedia. OOHDM
est basada en HDM,
en el sentido de que
toma muchas de las
definiciones, sobre
todo en los aspectos
de navegacin,
planteadas en el
modelo de HDM. Sin
embargo, OOHDM
supera con creces a
su antecesor, ya que
no es simplemente un
lenguaje de
modelado, sino que
define unas pautas de
trabajo, centrado
principalmente en el
diseo, para
desarrollar
aplicaciones
multimedia de forma
metodolgica.

OOHDM es sin duda

una de las
metodologas que ms
aceptacin ha tenido,
y sigue teniendo, en el
desarrollo de
aplicaciones
multimedia.
Actualmente est
sirviendo como base
para el desarrollo de
nuevos sistemas de
informacin web.
OOHDM es una
propuesta basada en
el diseo, que ofrece
una serie de ideas que
han sido asumidas por
bastantes propuestas
y que han dado muy
buenos resultados. La
primera de ellas es
que hace una
separacin clara entre
lo conceptual, lo
navegacional y lo
visual.
OOHDM hace uso
tambin de la
orientacin a objetos y
de un diagrama tan
estandarizado como el
de clases, para
representar el aspecto
de la navegacin a
travs de las clases
navegacionales:
ndices, enlaces y
nodos.

Por otra parte, OOHDM

presenta algunas
deficiencias, deja
fuera de su mbito un
aspecto esencial que
es el tratamiento de la
funcionalidad del
sistema. El qu se
puede hacer en el
sistema y en qu
momento de la
navegacin o de la
interfaz se puede
hacer, el cual lo deja
como tarea de
implementacin.
Adems, OOHDM no
ofrece ningn
mecanismo para
trabajar con mltiples
actores. Por ejemplo,
imaginemos que la
interfaz y la
navegacin de la
aplicacin varia
sustancialmente
dependiendo de quin
se conecte a la
aplicacin. El
diagrama
navegacional, los
contextos
navegacionales y los
ADVs resultaran muy
complejos para
representar esta
variabilidad.
OOHDM que no parece
adecuada es la de los
contextos
navegacionales.

Determinacin de
Requerimientos
Diseo Conceptual
Diseo Navegacional
Diseo de Interfaz
Abstracto
Implementacin

METODOLOG
IA SISTEMAS
EXPERTOS

BUCHANAN

En la adquisicin de
conocimiento (de
distintas
fuentes: libros,
expertos) el ingeniero
de
conocimiento procede
a travs de una serie
de
etapas para producir
un SE.
La caracterstica ms
importante de esta
metodologa es la
constante relacin
ente el
Ingeniero de
Conocimiento y el
Experto del rea.
Se destacan 6 etapas
fundamentales

Metodologa de Buchanan
Identificacin
Se identifican los
participantes y roles, los
recursos, fuentes de
conocimiento.
Se establecen las facilidades
computacionales y
presupuestos.
Se identifican los objetivos o
metas.
Conceptualizacin
Formalizacin
Inteligencia Artificial
4. Implementacin
Se formaliza el conocimiento
obtenido del
Experto y se elige la
organizacin, el
lenguaje y el ambiente de
programacin.
5. Testeo
Se observa el
comportamiento del
prototipo, el funcionamiento
de la base de
conocimiento y la estructura
de las
inferencias, verificndose la
performance
del sistema.
6. Revisin del prototipo
Se reformulan los
conceptos.
Se redisea y refina el
prototipo.
1.
Definicin del
dominio: Descripcin del

METODOLO
GIA
GROVER

Esta metodologa
propone una serie de
etapas en el
desarrollo del proceso
de adquisicin del
conocimiento, cada
una de las cuales va
acompaada de una
documentacin
detalla.

problema, referencias
bibliogrficas, glosario,
criterios de performance,
escenarios de ejemplos,
identificacin de expertos.
2.
Formulacin del
conocimiento fundamental:
Chequeo de sintaxis,
chequeo de
comportamiento. (Escenario
inicial, revisin del experto)
3.
Consolidacin del
conocimiento basal.
(Escenarios nuevos)

METODOLO
GIA BRULE

Muchos de los
trabajos
en SE no son dirigidos
correctamente.
En la mayora de los
casos el problema se
encuentra en la
construccin del
software y no en
la adquisicin del
conocimiento.
La caracterstica ms

La caracterstica ms
importante de sta
metodologa es la obtencin
de documentacin que
puede reemplazar
parcialmente al experto, y
servir a los diseadores y
usuarios como medio de
documentacin y referencia.
Pre-planeamiento
Definir el problema, investigar
la factibilidad del proyecto, el costo
de conduccin, probabilidad de
xito.
Diseo y especificacin.
Crear el equipo de trabajo,
estructurar las perspectivas,
planificar la primera sesin para
definir el modelo perspectiva inicial
mediante la creacin de un
prototipo
demostrativo.
Desarrollo temprano.
El equipo realiza su primer
esfuerzo de desarrollo. El final de
esta ser un

import
ante de esta
metodologa
es el desarrollo de un
SE temprano, que
incrementalmente
converge al sistema
experto final.

METODOLOG
IA
APLICACION
ES MOBILES

WATERFAL
L

1. El modelo waterfall
es el modelo ms
esttico y predictivo.
Es aplicable en
proyectos en los que
los requisitos estn
fijados y no van a
cambiar durante el
ciclo de vida del
desarrollo.
La documentacin es
muy importante,
todos
los
documentos
referentes
a
la
arquitectura deben
hacerse antes de
comenzar
el
desarrollo

diseo relativamente estable.

Implementacin.
Si el diseo es satisfactorio,
comienza la implementacin. Es un
proceso interactivo, definicin del
sistema, construccin e
implementacin.
Evaluacin.
Se verifica y valida el sistema
experto y se establece la
performance del sistema.
Supervisin.
Consiste en un testeo en lnea, en
un
ambiente limitado y controlado.
Mantenimiento
En todo sistema se requiere de un
mantenimiento para poder existir
y/o progresar, como as tambin la
actualizacin del sistema.

El nfasis que hacer el

Waterfall est en el
planeamiento del
proyecto, por lo que
antes de si quiera
iniciar el desarrollo,
todos deben tener una
visin clara de donde
se desea llegar.
Debido a que se
requiere un
planeamiento
exhaustivo por
adelantado, se pueden
medir de forma ms
exacta los tiempos y
presupuestos del
proyecto, lo que
usualmente tiende a
complacer al cliente.

Es muy usual que las

personas para quienes
se desarrolla el
software
(el cliente) no tengan
muy claro (o
nada claro)
exactamente qu es lo
que necesitan, y en
casi todos los casos,
no saben las
capacidades de la
tecnologa disponible
en el mercado, por lo
que sus
requerimientos no
necesariamente son lo
que realmente
necesitan, sino ms
bien, lo que creen

REQUISITOS
DISEO
IMPLEMENTACION
VERIFICACION
MANTENIMIENTO
En el contexto del desarrollo
de
aplicaciones mviles, el
modelo waterfall puede ser
aplicable a proyectos
realmente controlados y
previsibles, en los que no hay
mucha incertidumbre por lo
que se desea hacer y para los

 Waterfall supone
que no habr
cambios a lo largo
del desarrollo del
producto final
-Empieza con la
recopilacin de los
requisitos
Se basan en el
contrato, por eso los
requisitos del cliente y
la documentacin es
tan importante
-Su desarrollo
est dirigido
por la
documentacin
-La integracin de los
diferentes mdulos
se producen al final
-La comunicacin con
las personas que
conocen la lgica
del negocio slo se
producen al inicio
del proyecto
-Esta centrado en el
anlisis y el diseo
para ello se apoya
en los arquitectos y
diseadores
El producto final no
est compuesto
nicamente por el
propio software, sino
que puede incluir la
documentacin, el
manual de usuario y
otros.
-Cada desarrollador
est a cargo de un

Potenciales riesgos
y/o problemas que
pudieran surgir en
etapas avanzadas del
proyecto se puede
identificar durante la
etapa de
planeamiento inicial,
por lo que las
soluciones para estos
se pueden planear sin
que el proyecto
empiece si quiera la
etapa de desarrollo.

Con este mtodo, el

proceso de
documentacin suele
ser mucho ms
detallado. Muchas
organizaciones
encuentran esto
atractivo. Tambin,
debido a que se trata
de un mtodo lineal,
es ms fcil de
entender,
especialmente para
personas que no son
expertos en proyectos
de TI o
que no cuentan con
mucha experiencia.
Usualmente los
equipos se sienten
ms cmodos con
este enfoque.

necesitar basndose
en experiencias
limitadas de algn
programa que vieron
hace tiempo.

Los cambios en los

requerimientos no
pueden ser fcilmente
incorporados con una
metodologa Waterfall
y hay usualmente
procedimientos de
cambios muy
laboriosos por los
cuales pasar cuando
existen cambios, lo
cual significa por
supuesto, invertir ms
dinero y tiempo.
En otras palabras, esta
metodologa es
increblemente rgida
e inflexible. Alterar el
diseo inicial del
proyecto en
cualquiera
de sus etapas puede
convertirse en
una pesadilla, y por
supuesto, una vez
que una etapa se ha
completado, es
prcticamente
imposible realizar los
cambios solicitados,
por lo menos dentro
del tiempo y
presupuesto
planeados
inicialmente.

que no son importantes los

cambios constantes en la
industria.

rea diferente del

desarrollo

MOBILE-D

El mtodo Mobile-D
se desarroll junto
con un proyecto
finlands en el 2004.
Fue realizado,
principalmente, por
investigadores de la
VTT (Instituto de
Investigacin
Finlands) y, a pesar
de que es un mtodo
antiguo, sigue en vigor
(se est utilizando en
proyectos de xito y
est basado en
tcnicas que
funcionan).
El objetivo es
conseguir ciclos de
desarrollos muy
rpidos en equipos
muy pequeos (de no
ms de diez
desarrolladores)
trabajando en un
mismo espacio fsico.
Segn este mtodo,
trabajando de esa
manera se deben
conseguir productos
totalmente funcionales
en menos de diez
semanas.
Se trata de mtodo
basado en soluciones
conocidas y
consolidadas: Extreme
Programming (XP),

1 Fase de Exploracin
Se centra la atencin a la
planificacin y a los
conceptos bsicos del
proyecto. Se realizan
losalcances del proyecto y
su establecimiento con las
funcionalidades donde se va
a llegar.Tipo de patrn:
Patrn de faseEl propsito
de esta fase es la
planificacin y
establecimiento de una
buena planificacin
2 Ventajas
Un costo bajo al
realizar un cambio
en el proyecto.

Entrega resultados de

manera rpida.

Asegura el software

adecuado en el
momento adecuado

2 Desventajas
No sirve para grupos
de desarrollos grandes
y segmentados.

Depende de buena
comunicacin entre
los miembros del
equipo.

Awell planned is half done

, esta fase es muy importante
para establecer las bases
para unaimplementacin
bien controlada de software,
la arquitectura del producto,
el proceso dedesarrollo y la
seleccin del medio
ambiente.
2 Fase de Iniciacin
En la iniciacin se configura
el proyecto y se preparan
todos los recursos
necesarios, se lededica un
da a la planificacin y el
resto al trabajo y
publicacin.Tipo de patrn:
Patrn de faseClasificacin
de patrn: EsencialEl
propsito de esta fase es
permitir el xito de las
siguientes fases del
proyecto mediante la
preparacin y verificacin
de todas las cuestiones
fundamentales

Crystal
Methodologies y
Rational Unified
Process
(RUP), XP para las
prcticas de
desarrollo, Crystal
para escalar los
mtodos y RUP como
base en el diseo del
ciclo de vida.

del desarrollo a fin de que

todos estn en plena
disposicin de la aplicacin
de los requisitos
seleccionados por el cliente.
3 Fase de Producto
Antes de iniciar el desarrollo
de
una funcionalidad debe
existir una prueba que
verifique su funcionamiento,
en esta fase se lleva a cabo
toda la implementacin de
los
mdulos.
El propsito en la fase de
produccin es implementar
la funcionalidad requerida
en
el producto mediante
la aplicacin del ciclo
de desarrollo iterativo
e incremental.

4 Fase de Estabilizacin
En esta fase se llega la
integracin para vincular
los mdulos separados en
una nica aplicacin.
Tipo de patrn: Patrn de
fase. Clasificacin de patrn:
Esencial El propsito de la
fase de estabilizacin es
asegurar la calidad de la
implementacin del
proyecto.
5 Fase de pruebas
Se pasa al testeo hasta tener
una versin estable del
producto segn lo

establecido por el cliente. Si

es necesario se reparan
errores pero no se desarrolla
nada nuevo. Una vez
terminado todas las fases se
debera contar con una
aplicacin publicable y
entregable al cliente

Hybrid
Methodolo
gy Design

Esta metodologa
utiliza el modelo
iterativo incremental
para el proceso de
desarrollo y as lograr
la rpida
entrega de software y
mejorar las
capacidades de
gestin
de riesgos. Algunas de
las caractersticas
giles que se
destacan y que
tambin se alinean
con las necesidades
de
desarrollo de
aplicaciones mviles
son segn

Desarrollo basado en
pruebas.

Esta propuesta
metodolgica utiliza el
modelo de desa
rrollo en espiral como
base, e incorpora
procesos de
evaluacin de la
usabilidad, priorizando
la participacin
del usuario en todos

en la primera iteracin se
determinan los
requisitos del sistema y se
identifican usuarios, tareas
y contextos en los que se
utilizar la aplicacin.
Luego,
se definen y priorizan los
atributos de facilidad de uso
y se identifican mtricas
para cada atributo; se dibuja

Participacin contina del

cliente.
Establecimiento de
prioridades en los requisitos.
Comunicacin efectiva.
Calidad garantizada.
Desarrolladores expertos.
Revisin de todo el proceso
y sesiones de aprendizaje.
Proceso de adaptacin.

Mobile
Developme
nt Process
Spiral

los procesos del ciclo

de vida de
diseo, con el fin de
garantizar un diseo
centrado en el
usuario, aun cuando
se trata de un modelo
de proceso
orientado a proyectos
grandes y costosos,
ya que est
destinado a ser un
modelo de reduccin
de riesgos

un prototipo de la interfaz
de aplicacin y se realiza la
prueba del prototipo, los
desarrolladores podrn
utilizar
diferentes tcnicas de
usabilidad para medir el
valor de
cada atributo.
En la segunda iteracin el
equipo de desarrollo
recoger
ms datos y requisitos,
explorar si hay ms
usuarios
potenciales, tareas y
contextos en los que se
utilizar la
aplicacin.
En la tercera iteracin los
desarrolladores pueden
identificar y priorizar los
atributos de usabilidad con
mayor
claridad utilizando los
resultados de la iteracin
anterior;
se desarrolla el diseo de
todo el sistema y se realiza
la
versin alfa con sus
respectivas pruebas, el
equipo de
desarrollo compara los
resultados con la calificacin
de
la iteracin anterior.
En la cuarta iteracin los
resultados de la iteracin
anterior son utilizados para
identificar y dar prioridad a

los
atributos de facilidad de
uso; se desarrolla la versin
beta
y se libera para su
evaluacin por parte del
cliente.
En la quinta iteracin se
desarrolla el producto final;
se
realiza una evaluacin de
facilidad de uso, la
calificacin
de cada atributo se calcula y
se compara con la
calificacin de la fase
anterior.

WEBGRAFIA:
http://tecnologiarup.blogspot.com/2012/11/cuales-son-las-ventajas-y-desventajas.html
http://www.monografias.com/trabajos13/metomt/metomt.shtml

http://www.academia.edu/23746235/Mobile-D; https://prezi.com/w6vtbtpc_gaf/metodologias-de-desarrollo-de-aplicaciones-moviles/;
http://www.genbetadev.com/desarrollo-aplicaciones-moviles/metodos-aplicables-para-el-desarrollo-de-aplicaciones-moviles;
http://www.academia.edu/10851613/CUADRO_COMPARATIVO_ENTRE_METODOLOG%C3%8DAS_DE_DESARROLLO_DE_APLICACIONES_WEB ;
http://metodologiaeorm.blogspot.com/p/ventajas_23.html
https://procesosdesoftware.wikispaces.com/METODOLOGIA+RUP