METODOLOGÍA MOBIL-D

Metodologías Móviles

Descripción breve
[Dibujar su lector con un resumen de la participación. Normalmente es un breve resumen del
documento.
Cuando esté listo para agregar contenido, haga clic aquí y empiece a escribir.]

Ing. Sistemas Computacionales

[Dirección de correo electrónico]
Índice
Introducción ....................................................................................................................................... 2
Desarrollo........................................................................................................................................... 3
Cuadro Comparativo de Metodologías ..................................................................................... 5
Conclusión ......................................................................................................................................... 8
Bibliografía ......................................................................................................................................... 8
Introducción
Las metodologías ágiles poseen ciertas propiedades que las hacen totalmente
aplicables al desarrollo de proyectos de software móvil.

En [12] se identifican los métodos ágiles como la solución potencial para el

desarrollo de software en dispositivos móviles.
Por esta razón, se ha decidido hacer uso de la metodología Mobile-D [13], la cual
fue creada apoyándose en muchas otras soluciones bien conocidas y
consolidadas: eXtreme Program-ming (XP) [14], Crystal methodologies [15] y
Rational Unified Process(RUP) [16]. En resu-men, los principios de programación
extrema se han reutilizado en lo referente a las prácticas de desarrollo, las
metodologías Crystal proporcionan un input muy valioso en términos de la
escalabilidad de los métodos y RUP es la base para el diseño completo del ciclo
de vida.
Desarrollo

El objetivo de este método es conseguir ciclos de desarrollo muy rápidos en

equipos muy pequeños. Fue creado en un proyecto finlandés en 2005, pero sigue
estando vigente. Basado en metodologías conocidas pero aplicadas de forma
estricta como: extreme programming, Crystal Methodologies y Rational Unified
Process.

Se compone de distintas fases: exploración, inicialización, fase de producto, fase

de estabilización y la fase de pruebas. Cada una tiene un día de planificación y
otro de entrega.

Roles

Fase de Exploración
En la fase de exploración se centra la atención en la planificación y a los
conceptos básicos del proyecto. Aquí es donde hacemos una definición del
alcance del proyecto y su establecimiento con las funcionalidades donde
queremos llegar.

Fase de Iniciación
En la iniciación configuramos el proyecto identificando y preparando todos los
recursos necesarios como hemos comentado anteriormente en esta fase la
dedicaremos un día a la planificación y el resto al trabajo y publicación.

Entradas y Salidas

Fase de Producto
En la fase de producto se repiten interactivamente las subfases. Se usa el
desarrollo dirigido por pruebas (TDD), antes de iniciar el desarrollo de una
funcionalidad debe existir una prueba que verifique su funcionamiento. En esta
fase podemos decir que se lleva a acabo toda la implementación.

Fase de estabilización
Después de la fase de producto llega la fase de estabilización en la que se
realizan las acciones de integración para enganchar los posibles módulos
separados en una única aplicación.

Fase de Pruebas o Reparación del sistema

Fase de pruebas. Una vez parado totalmente el desarrollo se pasa una fase de
testeo hasta llegar a una versión estable según lo establecido en las primeras
fases por el cliente. Si es necesario se reparan los errores, pero no se desarrolla
nada nuevo.
Una vez acabada todas las fases deberíamos tener una aplicación publicable y
entregable al cliente
Cuadro Comparativo de Metodologías

MOBILE-D XP Espiral Prototipos RAD RUP Hibryd Managament

Descripción Modelo ágil de desarrollo Se basa en el trabajo Permite desarrollar Representa aquellos Es un MLS pero que Es una metodología
rápido, orientado al objetivo, software aspectos del SW que enfatiza en un ciclo estándar,
enfocado a grupos basándose para esto aprovechando las serán visibles para el extremadamente corto una de las más utilizadas
pequeños y que busca en la velocidad de ventajas tanto del ciclo cliente, el cual lo evalúa, el desarrollo de SW. (junto uml) para análisis,
rápidas respuestas. reacción para la de vida clásico como para así refina los diseño,
Implementación. de la creación de requisitos del SW que se Planifica el desarrollo implementación y
prototipos. desarrollará. del Software, pero este documentación de sistemas
Proporciona un no es estándar y orientado a objetos.
modelo evolutivo para puede variar de una
el desarrollo de aplicación a otra,
sistemas de software también trata de tomar
complejos, mucho más en cuenta las
realista que el ciclo de circunstancias en las
vida clásico, y permite que están el equipo de
la utilización de desarrollo.
prototipos en cualquier
etapa de la evolución
del proyecto.
Características Sus etapas se dividen en Se basa en los Este modelo es que Crea una maqueta, la Fácil de aprender Está dirigido por los casos
ciclos de 3 días con uno UseStories que incorpora en el ciclo de cual muestra la interfaz  Gran impacto de uso y es iterativo e
para planificar, otro para definen los detalles vida el análisis de de la aplicación, interfaz Implementación de Incremental.
trabajar en el proyecto y técnicos de riesgo; un elemento estática, no procesa modelos de negocios
un día final para Implementación. nuevo, de cuyo datos.
presentar resultados análisis económico se
obtiene la finalización
del desarrollo o su
continuación hasta
otras fases
posteriores.
Ventajas Mezcla de muchas Una de las El modelo en espiral Modificación del Mayor flexibilidad. Requiere conocimientos
técnicas. ventajas de la puede adaptarse y Sistema en Etapas Menor codificación del proceso y de
No existían programación aplicarse a lo largo de tempranas de su manual. UML.
demasiados principios de extrema es que se la vida del software de desarrollo. Mayor
desarrollo. adapta al desarrollo computadora. involucramiento de los Progreso visible en las
Dispone de un ciclo de de sistemas Permite al usuarios. etapas tempranas.
desarrollo muy rápido pequeños y grandes. Como el software desarrollador darse
para equipos muy evoluciona a medida cuenta de lo que requiere Posiblemente menos El uso de iteraciones
pequeños. Optimiza el tiempo que progresa el el cliente. fallas. (actividades).
de desarrollo. proceso, el
Permite realizar el desarrollador y el Permite que el Posiblemente menor Facilita la reutilización del
desarrollo del sistema cliente comprenden y desarrollador se dé costo. código teniendo en cuenta
en parejas para reaccionan mejor ante cuenta cómo va que se realizan revisiones en
complementar los riesgos en cada uno avanzando en trabajo. Ciclos de desarrollo las primeras iteraciones lo
conocimientos. de los nivele más pequeños. cual además permite que se
evolutivos. aprecien oportunidades de
El código es mejoras en el diseño.
sencillo y entendible, El modelo en espiral
además de la poca permite a quien lo
documentación a desarrolla aplicar el
elaborar para el enfoque de
desarrollo del construcción de
 sistema. prototipos en cualquier
etapa de evolución del
producto
Desventajas -Corta duración de sus Las desventajas son Resulta difícil Adoptarlo como el Costo de herramientas Por el grado de
desarrollos. que no se tiene la convencer a grandes sistema final: Los integradas y equipo complejidad puede no
-La gran competencia del definición del costo y clientes de que el usuarios y profesionales necesario. resultar muy adecuado.
sector. el tiempo de enfoque evolutivo es de sistemas pueden Progreso más difícil de RUP es generalmente mal
-Obliga a una innovación. desarrollo; el sistema controlable. considerar al prototipo medir. aplicado en el estilo cascada.
va creciendo después como el sistema final Menos eficiente.
de cada entrega al Debido a su elevada cuando aún es Menor precisión
cliente y nadie puede complejidad no se incompleto e inadecuado. científica.
decir que el cliente no aconseja utilizarlo en Riesgo de revertirse a
querrá una función pequeños sistemas. El desarrollador y el las prácticas sin
más; se necesita de Genera mucho tiempo cliente tienen poca control de antaño.
la presencia en el desarrollo del comunicación al inicio del Prototipos pueden no
constante del sistema proceso. escalar, un problema
usuario, lo cual en la mayúsculo
realidad es muy difícil Modelo costoso Surgen cambios
de lograr. Requiere experiencia imprevistos que retrasan
en la identificación de el progreso del prototipo.
riesgos
Fases • Exploración • Pruebas • Planificación • Investigación • Fácil de aprender • Inicio
• Inicialización • Planificación • Análisis de riesgos preliminar • Gran impacto • Elaboración
• Producción • Diseño • Ingeniería • Diseño y construcción • Implementación de • Construcción
• Estabilización • Codificación • Evaluación por el • Evaluación modelos de negocios • Transición
• Prueba y reparación cliente • Modificación
• Diseño técnico
• Programación y
prueba
• Operación y
mantención
Autor Barry Boehm (1988) James Martin en1980
Herramienta Architect Enteprice YAV's RAD Tools Sprintometer
CASE soportada Genera proyectos pre Es una herramienta para la
configurados con gestión. Con el fin de
todos los menús simplificar el intercambio de
estándar y estaciones datos con programas
de trabajo de windows, externos todas las hojas de
ofrece la instalación en cálculo en Sprintometer se
un click de la pueden exportar a Microsoft
herramienta en Excel, también se puede
proyectos existentes. utilizar el formato XML para
· Clarion 5.0 los archivos locales.
Enterprice edition Easy CASE
Es una herramienta de
desarrollo
automatizado, ofrece
soluciones eficientes
para problemas de
negocios.
Conclusión

Bibliografía
Gasca Mantilla, M., & Camargo Ariza, L., & Medina Delgado, B. (2014). Metodología para el desarrollo de aplicaciones
móviles. Tecnura, 18 (40), 20-35.

Reseña del Modelo de Prototipo y Herramientas Case realizado por Breton J. García G. y Rojas I.
Mayo 2011

Beck, K. A. (2004). Extreme Programming Explained. Addison Wesley.

Martin, R., & Newkirk, J. (2002). La programacion extrema en la practica. Pearson Addison-Wesley.