WheresApp: Servicio de geolocalización de amigos mediante aplicación móvil/transicion

Ortografía

Esta página o sección necesita una revisión de ortografía y gramática.
Puedes ayudar editándolo

< WheresApp: Servicio de geolocalización de amigos mediante aplicación móvil

Este recurso de aprendizaje es una actividad creada originalmente como caso práctico del proyecto de aprendizaje Dirección y gestión de proyectos y sistemas informáticos.

Planificación y Soporte a la Transición

• Estrategia
  • Breve planificación con perspectiva de objetivos basada en hitos => Modelo Scrum (Melé)
• Preparación
  • Especificación + Diseño + Estimaciones => 6 Sprints de 2 semanas
• Planificación
  • 1 para Documentación inicial (Mercado y ERS)
  • 1 para Diseño, prototipos y pruebas
  • 3 para Implementación
  • 1 para Cierre y corregir

Documentos de Scrum.

Gestión de Cambios

Para lograr que el proyecto perdure en el tiempo es necesario realizar una correcta gestión de cambios. Dicha gestión de cambios será encargada de proveer de un procedimiento repetible para la generación/detección, análisis, evaluación, determinación e implantación del cambio, de una forma eficaz. En primer lugar, dada la ausencia de cliente en este proyecto contaremos con varias fuentes del cambio, las detectadas por la dirección como oportunidades, los fallos en origen, las detectadas por cambios en el medio de desarrollo y las detectadas por los usuarios. Estas últimas son una categoría especial, ya que no se producirán hasta la fase de operación.

Cambios como oportunidades

Es común que surjan ideas durante el desarrollo que no se contemplaron en origen pero que pueden causar un enriquecimiento de la aplicación. Sin embargo, su implantación puede provocar retrasos que deben ser evaluados. El prodecimiento para incluir dichas oportunidades es el siguiente:

• Evaluar el enriquecimiento de la aplicación.
• Estudiar las partes implicadas.
• Realizar una estimación del cambio.
• Aceptar o rechazar la propuesta.
• Ajustar las planificaciones y distribuir las nuevas tareas.
• Añadir y modificar la información de la SRS.
• Informar de los cambios a los recursos implicados.

Para aceptar o rechazar la propuesta se evaluará la ganancia con respecto al impacto en la planificación/productividad.

Cambios como fallos

Cuando se piensa una aplicación en primera instancia existen detalles que no se perciben o se imaginan de una forma a como realmente puede que se desarrollen. Por ello, durante las reuniones de SCRUM todos los integrantes deberán comentar aquellas trabas o fallos que hayan encontrado durante su semana de desarrollo. En función de su criticidad se categorizarán en tres tipos:

• Fallos catastróficos: Son aquellos que no permiten continuar con el desarrollo del proyecto. Por ejemplo, si alguna de las APIs bloqueara el acceso a la aplicación. Estos fallos deberán preveerse siempre contando con alternativas. En nuestro caso, en la fase de diseño se han evitado la mayoría de estos fallos, pues se realizó un estudio de las APIs, optándose por OpenStreetMaps como gestión de rutas y AppEngine como plataforma cloud gratuíta.
• Fallos críticos: Son aquellos que se producen por un comportamiento inesperado de la tecnología. Normalmente son provocados por la inexperiencia. Para estos fallos se tratará de incrementar la productividad, provocando una reunión extraordinaria si fuera necesario para tratar posibles alternativas o el estudio del código que causa problemas por varios miembros del equipo.
• Fallos leves: Son aquellos comportamientos que no se consiguen pero cuya ausencia en la implementación final no es vital. Simplemente se evaluará el coste en tiempo de solucionar el fallo y de ser demasiado elevado simplemente se descartará dicha funcionalidad.

Cambios en el medio de desarrollo

Debida a su corta duración, no se esperan cambios en el medio. Además, las APIs elegidas fomentan la retrocompatibilidad por lo que será extremadamente raro. Si bien podrían producirse problemas de permisos y en cuanto a la legislación que nos permita acceder a la ubicación en los dispositivos, no se contempla que ocurran.

Cambios por los usuarios

Este aspecto se gestiona en la fase de transición, y lleva un procedimiento similar a los cambios por oportunidades. Sin embargo, dado que ya se habrá finalizado la planificación se realizará una evaluación del coste de implantación en cuanto a la disponibilidad de los recursos y el coste económico del mismo.

Gestión de Configuración

En todo proyecto de Software con varios miembros implicados la gestión de la configuración es una parte vital. Permite mantener la visión unificada del estado actual del proyecto entre todos los integrantes del mismo, previniendo errores y permitiendo informar de una forma eficaz de los cambios en documentos, código y servicios. Para llevarla a cabo realizaremos los siguientes procedimientos administrativos:

Gestión de la documentación

Debido a la elevada cantidad de documentación y la generación procedimental de la misma, con sus continuas modificaciones se hace necesaria una metodología repetible para la gestión, archivado y informe de la misma. Todos los documentos cuentan con ello en su segunda página con un detalle de la versión, participantes que deben de ser informados de los cambios de dicho documento y un breve resumen de los cambios realizados en el mismo. Cada documento llevará asociado un código de versión y un nombre único. Al producirse cualquier cambio relevante en el documento se generará una nueva versión del mismo y se informará a todos los participantes. Por ello, diferenciamos entre cambios menores y cambios relevantes. Los menores serán aquellos que realicen aclaraciones o correcciones ortográficas. Los cambios relevantes quedan a juicio del editor, pero por lo general serán aquellos que aporten contenido y realicen cambios en el mismo que cambie el significado o lo extienda significativamente. El procedimiento de generación de una versión implica:

• Generación de una copia del documento anterior.
• Archivado en la carpeta que contiene las versiones anteriores.
• Bloqueo del documento a editar por el equipo de edición.
• Edición del documento.
• Generación del resumen y número de versión.
• Informado a los miembros.

Siguiendo estos pasos se optimiza el uso de la documentación y se puede realizar el seguimientos de los cambios para su posterior análisis y mejora continua del proceso. Toda la edición de la documentación se realizará online en la infraestructura proporcionada por la UCM y Google, Google Drive.

Gestión del código

De una forma prácticamente obligatoria, es necesario para el desarrollo del código el uso de una plataforma que mantenga la última versión del código accesible y que permita una integración de cambios y el trabajo distribuido y simultáneo del equipo. Es por ello la existencia y la popularidad de los conocidos sistemas de control de versiones. En este proyecto se ha optado por utilizar el conocido sistema libre GitHub, que proporciona almacenamiento y una interfaz de uso cómoda, además de proporcionar métricas que permitirán evaluar a los desarrolladores y al desarrollo del proceso, en cuanto a su cercanía a la planificación. GitHub hace uso de GIT para gestionar el código y las distintas ramas o versiones. Para facilitar el trabajo y tenerlo mas ordenado hacemos uso de Gitflow. Gitflow nos permite gestionar de manera correcta las distintas features que estamos implementando así como las versiones que mantenemos. Es como una filosofía mas que metodología a la hora de trabajar con GIT.

Gestión de Entregas y Despliegues

Actualmente se posee una plataforma que provee mecanismos de versionamiento y despliegue de versiones. Estas versiones no se despliegan en producción hasta que estén debidamente probadas.

La plataforma esta formada por las herramientas online GitHub y TravisCI:

• GitHub: En GitHub tenemos alojado el repositorio con el código fuente del proyecto.

• TravisCI: TravisCI es un gestor de integración y despliegue, alojado en la nube y integrado con GitHub nos permite realizar una construcción del proyecto con sus dependencias y ejecución de test. Ademas en nuestro caso haciendo uso de los tags de git realizamos el despliegue automatico sobre GitHub de las release del proyecto siempre y cuando la construcción sea satisfactoria.

• Play Store: El despliegue principal es realizado en el Play Store de Google. Este es gestionado actualmente de manera manual por motivos de seguridad ya que para realizar este despliegue de manera automática con TravisCI es necesario tener almacenadas las claves de acceso a la API de Play Store en el repositorio y dado que este es publico sería una importante brecha de seguridad.