David Velzquez Plascencia

10041207

Metodologas para el desarrollo de

aplicaciones mviles
Una aplicacin mvil es relativamente software, por lo tanto su desarrollo no difiere mucho. Es
cierto que las aplicaciones mviles tienen caractersticas ms particulares como la duracin del
desarrollo, las plataformas que se utilizan y los usuarios que hacen uso de ellas. Por ello existen
varias opciones de metodologas para desarrollo. Aqu se mencionan algunas metodologas:

Modelo en Cascada
Para usar esta metodologa es necesario que se tenga bien planteado lo que se quiere hacer y los
requisitos a cubrir. Esto porque no hay etapas conde se puedan hacer reajustes al producto. Todo
tiene fechas determinadas y presupuestos fijos.

Desarrollo rpido de aplicaciones

Aqu la idea principal es tener un producto desde el principio, el cual no se define como terminado
sino en fase de prueba y conforme va progresando, se hacen las mejoras y se perfecciona. En caso
de requerir cambios, se pueden realizar de manera inmediata, siempre y cuando su estructura sea
fcil de percibir para hacer estos cambios.
Es recomendable usar esta metodologa si el plazo de tiempo es corto, adems es posible el uso de
otra metodologa posterior a la obtencin del prototipo desarrollado que se muestra al cliente para
que vea los avances.

Desarrollo gil
Las metodologas giles son muy adecuadas para el desarrollo de aplicaciones mviles:
En primer lugar, la alta volatilidad del entorno hace que constantemente el equipo de desarrollo se
deba adaptar a nuevos terminales, cambios en la plataforma o en el entorno de desarrollo. Un ritmo
cambiante que requiere una alta respuesta al cambio ms que al seguimiento de un plan concreto.
Como hemos indicado, al menos actualmente, los equipos de desarrollo mvil suelen se integrados
por pocas personas. No ms de ocho o diez desarrolladores entorno a un misma aplicacin o,
incluso, un nico desarrollador. Las interacciones en el proceso y las herramientas son ms
controlables y es posible una fluida comunicacin entre los miembros del equipo.
Una aplicacin se suele realizar en periodos de desarrollo cortos entorno a un mes a seis meses.
Con el propsito de una realimentacin rpida es posibles realizar varias actualizaciones de un
aplicacin segn se van entregando funcionalidades. Un tema demandados por los usuarios en los
distintos markets de aplicaciones que aprecian la frecuente mejora de la aplicacin para mantenerla
viva, e incluso ayuda a su propio marketing al tener ms visibilidad cada vez que se realiza la
actualizacin.

David Velzquez Plascencia

10041207

Mobile-D
El objetivo de este mtodo es conseguir ciclos de desarrollo muy rpidos en equipos muy
pequeos. Fue creado en un proyecto finlands en 2005, pero sigue estando vigente. Basado en
metodologas conocidas pero aplicadas de forma estricta como: extreme programming, Crystal
Methodologies y Rational Unified Process.
Se compone de distintas fases: exploracin, inicializacin, fase de producto, fase de estabilizacin y
la fase de pruebas. Cada una tiene un da de planificacin y otro de entrega.
En la fase de exploracin se centra la atencin en la planificacin y a los conceptos bsicos del
proyecto. Aqu es donde hacemos una definicin del alcance del proyecto y su establecimiento con
las funcionalidades donde queremos llegar.
En la iniciacin configuramos el proyecto identificando y preparando todos los recursos necesarios
como hemos comentado anteriormente en esta fase la dedicaremos un da a la planificacin y el
resto al trabajo y publicacin.
En la fase de producto se repiten interativamente las subfases. Se usa el desarrollo dirigido por
pruebas (TDD), antes de iniciar el desarrollo de una funcionalidad debe existir una pueba que
verifique su funcionamiento. En esta fase podemos decir que se lleva a acabo toda la
implementacin.
Despus de la fase de producto llega la fase de estabilizacin en la que se realizan las acciones de
integracin para enganchar los posibles mdulos separados en una nica aplicacin.
Fase de pruebas. Una vez parado totalmente el desarrollo se pasa una fase de testeo hasta llegar a
una versin estable segn 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 deberamos tener una aplicacin publicable y entregable al cliente.