CARMEN LORENA GONZALES PATIO

ING. MARGARITA LOPEZ

8363-7

UNIVERSIDAD LOYOLA

INGENIERIA DE SISTEMAS
NOMBRE
METODOLOGA

CARACTERSTICAS

Metodolog
as
Orientadas
a Objetos

1.- OMT++

1.- LA METODOLOGA OMT++

emplea tres clases de modelos para
describir el sistema:
* Modelo de objetos. Describe la
estructura esttica de los objetos del
sistema (identidad, relaciones con otros
objetos, atributos y operaciones). El
modelo de objetos proporciona el
entorno esencial en el cual se pueden
situar el modelo dinmico y el modelo
funcional. El objetivo es capturar
aquellos conceptos del mundo real que
sean importantes para la aplicacin. Se
representa mediante diagramas de
objetos.
* Modelo dinmico. Describe los
aspectos de un sistema que tratan de la
temporizacin y secuencia de
operaciones (sucesos que marcan los
cambios, secuencias de sucesos, estados
que definen el contexto para los sucesos)
y la organizacin de sucesos y estados.
Captura el control, aquel aspecto de un
sistema que describe las secuencias de
operaciones que se producen sin tener
en cuenta lo que hagan las operaciones,
aquello a lo que afecten o la forma en
que estn implementadas. Se representa
grficamente mediante diagramas
de estado.
* Modelo funcional. Describe las
transformaciones de valores de datos
(funciones, correspondencias,
restricciones y dependencias funcionales)
que ocurren dentro del sistema. Captura
lo que hace el sistema,
independientemente de cuando se haga

VENTAJAS

DESVENTAJAS

1.- Ventajas
* Proporciona una serie de pasos
perfectamente definidos al
desarrollador.

1.- Desventajas
* Hay pocos mtodos para
encontrar inconsistencias en los
modelos.

* Tratamiento especial de la
herencia.

*Interaccin de objetos no
soportada explcitamente en
ninguna herramienta grfica.

* Facilita el mantenimiento dada la

gran cantidad de informacin que se
genera en el anlisis.

*Al ser un anlisis iterativo es difcil

de saber cuando comenzar con el
diseo.

* Es fuerte en el anlisis
*Es dbil en el diseo

FASES

1. Anlisis de objetos: se
centra en entender y modelar
el problema en el
dominio de la aplicacin.
2. Diseo del sistema: se
determina la arquitectura del
sistema en trminos de
subsistemas.
3. Diseo de objetos: se refina
y optimiza el anlisis de objetos
para
implementarlo.
4. Implementacin: se codifica
y prueba lo ya diseado.

o de la forma en que se haga. Se

representa mediante diagramas de flujo
de datos.

2.- METODOLOGIA RUP

2.- METODOLOGA RUMBAUGH

Es una metodologa cuyo fin es entregar
un producto de software. Se estructura
todos los procesos y se mide la eficiencia
de la organizacin.
Es un proceso de desarrollo de software
el cual utiliza 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 es un conjunto de metodologas
adaptables al contexto y necesidades de
cada organizacin.
Describe como aplicar enfoques para el
desarrollo del software, llevando a cabo
unos pasos para su realizacin.
Se centra en la produccin y
mantenimiento de modelos del sistema.
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.
En est metodologia lo que se pretende

1. Fase de Inicio: Esta fase

tiene como propsito definir y
acordar el alcance del proyecto
con los patrocinadores,
identificar los riesgos asociados
al proyecto, proponer una
visin muy general de la
arquitectura de software y
producir el plan de las fases y el
de iteraciones posteriores.

2.- Ventajas
* 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).

2.- Desventajas
* Mtodo pesado
* Por el grado de complejidad
puede ser no muy adecuado.
* En proyectos pequeos, es
posible que no se puedan cubrir los
costos de dedicacin del equipo de
profesionales necesarios.

2. Fase de elaboracin: En la
fase de elaboracin se
seleccionan los casos de uso
que permiten definir la
arquitectura base del sistema y
se desarrollaran en esta fase,
se realiza la especificacin de
los casos de uso seleccionados
y el primer anlisis del dominio
del problema, se disea la
solucin preliminar.
3. Fase de Desarrollo: El
propsito de esta fase es
completar la funcionalidad del
sistema, para ello se deben
clarificar los requerimientos
pendientes, administrar los
cambios de acuerdo a las
evaluaciones realizados por los
usuarios y se realizan las
mejoras para el proyecto.
4. Fase de Cierre: El propsito
de esta fase es asegurar que el
software est disponible para
los usuarios finales, ajustar los
errores y defectos encontrados
en las pruebas de aceptacin,

es el desarrollo de un software, en el cual

se aplicara el PSP y el CMMI en todos sus
fases, que esten en la realizacion de los
procesos
El RUP es un producto de Rational (IBM).
Se caracteriza por ser iterativo e
incremental, estar centrado en la
arquitectura y guiado por los casos de
uso. Incluye artefactos (que son los
productos tangibles del proceso como
por ejemplo, el modelo de casos de uso,
el cdigo fuente, etc.) y roles (papel que
desempea una persona en un
determinado momento, una persona
puede desempear distintos roles a lo
largo del proceso).

capacitar a los usuarios y

proveer el soporte tcnico
necesario. Se debe verificar que
el producto cumpla con las
especificaciones entregadas
por las personas involucradas
en el proyecto.

Metodolog
as agiles

1.-EXTREME
PROGRAMMING (XP)

1.- Las caractersticas fundamentales del

mtodo son:
* Desarrollo iterativo e incremental:
pequeas mejoras, unas tras otras.
* Pruebas unitarias continuas,
frecuentemente repetidas y
automatizadas, incluyendo pruebas de
regresin. Se aconseja escribir el cdigo
de la prueba antes de la codificacin.
* Programacin por parejas: se
recomienda que las tareas de desarrollo
se lleven a cabo por dos personas en un
mismo puesto. Se supone que la mayor
calidad del cdigo escrito de esta manera
-el cdigo es revisado y discutido
mientras se escribe- es ms importante
que la posible prdida de productividad
inmediata.
*Frecuente interaccin del equipo de
programacin con el cliente o usuario. Se
recomienda que un representante del
cliente trabaje junto al equipo de
desarrollo.
* Correccin de todos los errores antes
de aadir nueva funcionalidad. Hacer
entregas frecuentes.

1 Fase: Planificacin del

proyecto.
* Historias de usuario.
* Release planning.
* Iteraciones:
* Velocidad del proyecto.
* Programacin en pareja.
*Reuniones diarias.
1.- Ventajas
*Apropiado para entornos voltiles
* Estar preparados para el cambio,
significa reducir su coste.
* Planificacin ms transparente para
nuestros clientes, conocen las fechas
de entrega de funcionalidades. Vital
para su negocio
*Permitir definir en cada iteracin
cuales son los objetivos de la
siguiente
* Permite tener realimentacin de
los usuarios muy til.

1.- Desventajas
* Delimitar el alcance del proyecto
con nuestro cliente

2 Fase: Diseo.
* Diseos simples.
* Glosarios de trminos.
* Riesgos.
* Funcionalidad extra.
* Tarjetas C.R.C.
3 Fase: Codificacin.
4 Fase: Pruebas.
El uso de los test en X.P es el
siguiente.

2.- AUP (AGIL UNIFIED

PROCESS)

2.- El AUP es un acercamiento

aerodinmico a desarrollo del software
basado en el Proceso Unificado Rational
de IBM (RUP), basado en disciplinas y
entregables incrementales con el tiempo.
El ciclo de vida en proyectos grandes es
serial mientras que en los pequeos es
iterativo. Las disciplinas de Aup son:
Modelado
Implementacin
Prueba
Despliegue
Administracin de la
configuracin
Administracin o
gerencia del Proyecto
Entorno

2.- VENTAJAS.
El personal sabe lo
que esta haciendo: no
obliga a conocer
detalles.

Simplicidad: apuntes
concisos.

Agilidad: procesos
simplificados del RUP

Centrarse en
actividades de alto
valor: esenciales para
el desarrollo.

Herramientas
independientes: a
disposicin del
usuario.

Fcil adaptacin de
este producto: de fcil
acomodo (HTML)

2.- DESVENTAJAS.
El AUP es un producto muy
pesado en relacin al RUP.

Como es un proceso
simplificado, muchos
desarrolladores eligen
trabajar con el RUP, por
tener a disposicin mas
detalles en el proceso.

Inception(Concepcin): El
objetivo de esta fase es obtener
una
comprensin
comn
clienteequipo de desarrollo del
alcance del nuevo sistema y
definir
una
o
varias
arquitecturas candidatas para el
mismo.
Elaboracin: El objetivo es que
el equipo de desarrollo
profundice en la comprensin
de los requisitos del sistema y
en validar la arquitectura.
Construccin: Durante la fase
de construccin el sistema es
desarrollado y probado al
completo en el ambiente de
desarrollo.
Transicin: el sistema se lleva
a los entornos de preproduccin
donde se somete a pruebas de
validacin y aceptacin y
finalmente se despliega en los
sistemas de produccin.

3.- SCRUM

3.- Scrum se focaliza en priorizar el

trabajo en funcin del valor que tenga
para el negocio, maximizando la utilidad
de lo que se construye y el retorno de
inversin. Est diseado especialmente
para adaptarse a los cambios en los
requerimientos, por ejemplo en un
mercado de alta competitividad. Los
requerimientos y las prioridades se
revisan y ajustan durante el proyecto en
intervalos muy cortos y regulares. De
esta forma se puede adaptar en tiempo
real el producto que se est
construyendo a las necesidades del
cliente. Se busca entregar software que
realmente resuelva las necesidades,
aumentando la satisfaccin del cliente.
En Scrum, el equipo se focaliza en una
nica cosa: construir software de calidad.
Por el otro lado, la gestin de un
proyecto Scrum se focaliza en definir
cuales son las caractersticas que debe
tener el producto a construir (qu
construir, qu no y en qu orden) y en
remover cualquier obstculo que pudiera
entorpecer la tarea del equipo de
desarrollo. Se busca que los equipos sean
lo ms efectivos y productivos posible.

1.- Pre-juego

3.- VENTAJAS
-Evaluacin en cada fase que permite
cambios de objetivos.
-Funciona bien en proyectos de
innovacin.
-Es sencillo, ya que sigue los pasos
intuitivos necesarios a la hora de
desarrollar el software.
-Seguimiento detallado en cada una
de las fases.

3.- DESVENTAJAS
La evaluacin de riesgos es
compleja
Excesiva flexibilidad para algunos
proyectos
Se pone al cliente en una
situacin que puede ser muy
incmoda .
El cliente deber ser capaz de
describir y entender a un gran nivel
de detalle para poder acordar un
alcance del proyecto con l.

Planificacin: Definicin de una

nueva versin basada en la pila
actual, junto con una
estimacin de coste y agenda.
Si se trata de un nuevo sistema,
esta fase abarca tanto la visin
como el anlisis. Si se trata de
la mejora de un sistema
existente comprende un
anlisis de alcance ms
limitado. Arquitectura: Diseo
de la implementacin de las
funcionalidades de la pila. Esta
fase incluye la modificacin de
la arquitectura y diseo
generales.
2.- Juego
Desarrollo de sprints:
Desarrollo de la funcionalidad
de la nueva versin con respeto
continuo a las variables de
tiempo, requisitos, costo y
competencia. La interaccin
con estas variables define el
final de esta fase. El sistema va
evolucionando a travs de
mltiples iteraciones de
desarrollo o sprints.
3.- Post-juego
Preparacin para el
lanzamiento de la versin,
incluyendo la documentacin
final y pruebas antes del
lanzamiento de la versin.

1.- UWE

Metodologa
s web

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
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 meta-modelo (modelo
de referencia) que da soporte al mtodo
y el grado de formalismo que alcanza
debido al soporte que proporciona para
la definicin de restricciones sobre los
modelos.

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

1.- Desventajas
* Uso de restricciones escritas

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

2.- RNA
(Mtodo de Anlisis de
Navegacin Relacional)

Es un mtodo de Anlisis de Navegacin

Relacional (Relationship Navigational
Analysis), que define una secuencia de
pasos que se utilizarn para el desarrollo
de la Web. Es especialmente til para uso
de la Web creados en base de sistema de
herencia. En este mtodo encontramos
cinco fases las cuales son: Anlisis del
entorno, donde el propsito de esta fase
es el de estudiar las caractersticas de la
audiencia, luego encontramos las
definiciones de elementos de inters, el
anlisis del conocimiento y navegacin y
finalmente la implementacin de los
anlisis realizados.
La propuesta de RNA es quizs una de las
que ms ha resaltado la necesidad de
trabajar con la especificacin de
requisitos, incluyendo tareas como el
anlisis del entorno y de los elementos
de inters. Adems, resulta interesante
pues plantea la necesidad de analizar los
requisitos conceptuales de manera
independiente a los navegacionales.

2.-Ventajas

2.Desventajas

* Analizar los requisitos conceptuales

de manera independiente a los
navegarelacionales.

* Para proyectos web creados en

base de sistema de herencia

* Dispone de documentacin
detallada de sistema

1 Fase de Anlisis del Entorno,

se determinar y clasifica a los
usuarios finales de la aplicacin
en grupos segn sus perfiles
2 Fase de Definicin de
Elementos: Aqu prosiguen los
elementos de inters en la cual
se han listando dichos
elementos de la aplicacin. Por
elementos de inters se
entienden los documentos, las
pantallas que se van a requerir,
la informacin, etc.
3 Fase de Anlisis del
Conocimiento, se desarrollar un
esquema que represente a la
aplicacin. Para ello RNA
propone identificar los objetos,
los procesos y las operaciones
que se van a poder realizar en
la aplicacin, as como las
relaciones que se producen
entre estos elementos
4 Fase de Anlisis de
Navegacin, se verifica que el
esquema obtenido en la fase
anterior sea enriquecido con
las posibilidades de navegacin
dentro de la aplicacin
5 Fase de Implementacin del
Anlisis, cuando una vez
obtenido el esquema final en el
que ya se encuentran incluidos
los aspectos de navegacin, se
pasa el esquema a un lenguaje
entendible por la mquina

3 EORM

(Enhanced Object Relationship

Methodology)
Es un proceso iterativo que se concentra
en el modelado orientado a objetos y por
la
representacin de relaciones entre estos.
Fue una de las primeras propuestas para
aplicaciones
Web centrada en el paradigma de la
orientacin a objetos.

3 ventajas

3.desventajas

*Flexibilidad entrerelaciones de los

nodos.

*Problemas afuncionamiento
delsistema o aspectos deinterfaz.

*La reutilizacin decdigo y libreras.

*La captura derequisitos es

muy pobre.

*Encajamiento derelaciones
semnticas

*Falta de comentarios o
documentacin.

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

METODOLO
GIAS PARA
APLICACION
ES MOVILES

1 WATERFALL

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
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
rea diferente del desarrollo

1 ventajas

1 desventajas

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
necesitar basndose en
experiencias limitadas de algn
programa que vieron hace
tiempo.

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.

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.

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 que no
son importantes los cambios
constantes en la industria.

2. 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), 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.

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.

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
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
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
BIBLIOGRAFIA: 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