Professional Documents
Culture Documents
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
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.
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.
al no ser un mtodo
de desarrollo es
independiente del
ciclo de desarrollo
no se presta con
facilidad al diseo de
sistemas distribuidos.
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.
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.
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.
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
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
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
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.
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.
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
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.
necesitar basndose
en experiencias
limitadas de algn
programa que vieron
hace tiempo.
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.
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.
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
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
Mobile
Developme
nt Process
Spiral
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