Chinator: Servicio de geolocalización de tiendas de todo a 100/Documentación del proyecto

Ortografía

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

Introducción

Para llevar a cabo este proyecto se decidió utilizar una metodología ágil basada en un desarrollo incremental así como Scrum. Esto es debido a que no disponíamos del tiempo necesario para realiar una metodología pesada por tiempo y costes. De esta forma se decidieron los distintos roles y se decidió que los Sprints serían semanales para así llevar un control y desarrollo continuo donde se le da mas valor al software funcionando que a la documentación exhaustiva.

Estudio de Mercado

España se ha convertido, en el último año, en el país europeo con mayor penetración de dispositivos móviles (tanto smartphonescomo tablets); un dato que tiene fiel reflejo en la actividad que se desarrolla en los markets y en los que se mueven, cada día, 4 millones de aplicaciones descargadas en tablets, smartphones y SmartTVs.

Concretamente, 22 millones de usuarios de España se consideran activos y, por tanto, usan o descargan aplicaciones en sus dispositivos móviles y televisiones inteligentes; un importante nicho de mercado para los desarrolladores y las empresas.

El retrato robot del usuario de aplicaciones para dispositivos móviles, en el caso de España, nos dibuja a una persona que suele instalar una media de 24 aplicaciones en su smartphone y alrededor de 31 aplicaciones en su tablet. Además, suele conectarse a Internet una media de 3 horas diarias a través de sus dispositivos móviles y, con respecto a su perfil socio-demográfico, respondería al de un hombre que vive en zonas urbanas con una edad entre los 25 y 44 años.

Mercado objetivo de Chinator es los habitantes de la Comunidad de Madrid que desee ubicar fácilmente todo tipo de negocio de chinos.

Plan de Proyecto

El documento principal de todo proyecto, en el cual se engloban todos aquellos documentos e información relevante e importante para el desarrollo del proyecto es el plan de proyecto. Por ello, incluido dentro de nuestro plan de proyecto se encuentra información acerca de los riesgos del proyecto, la metodología de desarrollo, diseño de la aplicación y su infraestructura, planes de gestión para garantizar la calidad, postmortem, etc...

Metodología de Desarrollo: Scrum

SCRUM es un modelo de desarrollo ágil caracterizado por: Adoptar una estrategia de desarrollo incremental, en lugar de la planificación y ejecución completa del producto. Basar la calidad del resultado más en el conocimiento tácito de las personas en equipos autoorganizados, que en la calidad de los procesos empleados. Solapamiento de las diferentes fases del desarrollo, en lugar de realizar una tras otra en un ciclo secuencial o de cascada. Su plan de acción se basa en la creación de sprints. Los mismos son objetivos o metas trazadas para ser realizadas en un determinado tiempo.

La decisión de trabajar utilizando la metodología SCRUM se basó, principalmente, en el hecho de que los requisitos y soluciones evolucionan mediante la colaboración de grupos auto organizados y multidisciplinarios. También, porque el mismo se basa en el desarrollo del software en lapsos de iteración relativamente cortos, sin mencionar que las diferentes fases del proyecto se solapan entre sí.

Para satisfacer el proceso de iteración de SCRUM (conocido como sprint), se realizó la planificación de cada uno de los mismos con un tiempo estimado de una (1) semana de duración por cada sprint. Se realizó de esta manera tomando en consideración 2 aspectos: la corta duración del proyecto (menos de un cuatrimestre) y el hecho de que todos los miércoles de todas las semanas tenemos asignado el laboratorio de la asignatura Direccion y Gestion de Proyectos y Sistemas de Información, motivo por el cual el equipo aprovecha de reunirse y de comunicarse todos los avances, retrasos, inquietudes, propuestas y decisiones. Por su parte, nuestro equipo de trabajo esta compuesto por cinco (5) integrantes, cada uno de los cuales tiene un rol asignado, como bien se puede verificar en la sección de Roles de nuestro equipo.

A pesar de que la metodología de SCRUM no exige la realización -masiva- de documentos como otras metodologías de desarrollo, se generarán una serie de documentos mínimos que el equipo considero vital para el sostenimiento, documentación, referencia y escalabilidad del proyecto. Ellos son:

• Diagrama de Clases
• Diagrama de Casos de Uso en UML
• Modelo Entidad Relacion de chinator
• Planificación y Sprints semanal
• Documento de revisión del Sprint
• El Plan de Proyecto

La imagen describe los distintos casos de uso de la aplicación Chinator.

Como se puede apreciar, se tiene el actor <<usuario>> (cliente), el cual puede, en la aplicación de chinator, Ver el mapa (que muestra las localidades de los chinos). Una vez en el mapa, puede crear una tienda de algún chino que el usuario conozca de su existencia, o bien, consultar una tienda de chino existente. Al crearse una nueva tienda, otro caso de uso posible es el de votar (o darle una valoración) a la tienda, lo cual indica la veracidad de que dicha tienda existe, y también, puede crear una solicitud para borrar alguna tienda, en caso de que se detecte que dicha tienda no existe o fue movida de sitio.

La imagen describe el diagrama Entidad-Relación de la base de datos de Chinator

A partir del mismo, se produjo el modelo relacional aplicando la transformación relacional de Codd, para finalmente guiarnos al diseño de las tablas de nuestra base de datos. Las Planificaciones y Sprints se pueden apreciar en el presente documento, en un apartado posterior.

Product Backlog

Se especifican los requisitos del producto a desarrollar. Este documento lo podremos modificar a lo largo del desarrollo del producto excepto en los Sprints

Roles de equipo

En la primera reunión de este proyecto se decidieron los distintos roles del proyecto. De esta forma se definieron los siguientes:

• Product Owner: Iván Pérez
• Scrum Master : Antonio Mundo
• Equipo de desarrollo : Javier Mansilla, Juan Zamorano y Jorge Moreno

Sprints

Se definió qué la duración de los Sprints sería de 1 semana ya que es la frecuencia con la que nos podríamos reunir en clase y determinar el estado de avance de cada miembro del proyecto.

Planificación de Sprints

• Sprint 1 (29 de Octubre)
  • Diseño de App de Android - Funcionalidad primaria
    • Geolocalización por GPS y pintado de mapas en la APP
    • Mejora de interfaz gráfica 1.0
  • Diseño lógico de la BD
    • Diseño modelo Entidad-Relacion (con sus restricciones de cardinalidad)
    • Creación de tablas en MySQL
    • Diseño diagrama relacional
    • Diagrama UML para casos de uso
• Sprint 2 (29 de Octubre - 5 de Noviembre)
  • Diseño de App de Android
    • Diseño de clases y definición de métodos.
    • Logo de la aplicación
    • Mejora en el cargado de mapas
  • Diseño lógico de la BD
    • Diagrama de clases
    • Mejora en el diseño de las tablas.
  • Diseño inicial del servicio web PHP
    • Diseño de clases y definición de métodos.
    • Esqueleto básico (no funcional)
• Sprint 3 (5 de Noviembre - 12 de Noviembre)
  • Definición de metodología de trabajo.
  • Desarrollo del esqueleto del plan de proyecto.
    • Contenido del punto 1 del plan de proyecto.
    • Definición de roles en el equipo.
    • Planificación y especificación de Sprints.
  • Diseño lógico de la BD
    • Arreglar fallos de FK y duplicidad en claves primarias
• Sprint 4 (12 de noviembre - 19 de Noviembre)
  • Diseño de la App de Android.
    • Obtención de la Ciudad de la tienda. (Antonio y Juan)
    • Creación de SAChinator, DAOTiendas y clase Tienda. (Javier)
    • Mejora en el formulario de Inserción de Tienda (Jorge)
  • Diseño del servicio web PHP.
    • Creación de SAChinator, DAOTiendas y clase Tienda (Iván)
  • Pruebas.
    • Comprobar el correcto funcionamiento de la creación y obtención de tiendas. (La opción de valorar no estará disponible aún, por lo que las tiendas se insertarán directamente.)
    • Pruebas con JUnit
• Sprint 5 (19 de noviembre - 26 de Noviembre)
  • Diseño de la App de Android.
    • Creación y almacenamiento del ID único de usuario. (Javier)
    • Creación de DAOValoraciones. (Javier)
    • Mejora en la lista de pendientes (custom adapter) (Javier)
  • Diseño del servicio web PHP.
    • Creación del DAOValoraciones y la clase Valoración. (Iván)
    • Modificar el SATiendas para que actue como en la especificación. (Iván)
  • Pruebas.
    • Comprobar de nuevo la creación y obtención de tiendas, esta vez utilizando el sistema completo de valoración. Valorar las tiendas con votos positivos y votos negativos y verificar la especificación.
• Sprint 6 (26 de noviembre - 3 de Diciembre)
  • Diseño de la App de Android.
    • Remasterización del logotipo. Creación del logotipo 2.0 (Iván)
    • Revisión completa de la estética. Mejora estética: unificación de colores, escalado de letras, revisión del espaciado entre botones, etc… (Javi)
    • Probar la aplicación en distintos dispositivos, distintas versiones de android y distintos tamaños de pantalla. (Todos)
  • Diseño del servicio Web PHP
    • Revisión completa del código y documentación del mismo. (Iván)
  • Página Web.
    • Creación de una página de Noticias, Quienes somos, descargar, etc… (Todos)
  • Documentación:
    • Redactar esqueleto de los términos y condiciones de uso de Chinator. (Jorge)
• Sprint 7 (3 de diciembre - 10 de diciembre)
  • Aplicación:
    • Publicitar la aplicación entre amigos, familiares y conocidos. (Todos)
  • Página web:
    • Creación del apartado Mapa que permite consultar las tiendas desde navegador y visualización de los markers con las Tiendas. (Iván)
    • Creación del apartado API que permite acceder a la documentación del servicio web. (Iván)
    • Creación del repositorio con las versiones de la App. (Javier)
  • Documentación:
    • Terminar la versión 1.0 de los términos y condiciones de uso de Chinator. (Jorge)
    • Comenzar con el Post-Mortem del proyecto. (Antonio y Juan)
• Sprint 8 (10 de diciembre - 17 de diciembre, ÚLTIMO SPRINT).
  • General:
    • Escribir hilos en foros publicitando la aplicación. (Todos)
    • Publicar la aplicación en Google Play o el Market que deseemos.
    • Reparación de errores obtenidos y reportados por los usuarios.
    • Mejora estética de la aplicación utilizando las opiniones de los usuarios.
    • Si ha ocurrido algún retraso, aprovecharemos esta última semana para solventarlo.
  • Página web:
    • Creación del contenido de la ventana emergente de los Markers.

Revisiones de los Sprints

Como una simple planificación no sirve para gestionar un proyecto completo, en Chinator, aprovechando que todas las semanas nos reuníamos, realizamos una revisión en la que seguíamos la siguiente plantilla, y que nos servía para controlar la evolución del proyecto y poder aportar mejoras y cambios antes de que fuese demasiado tarde.

Esta es la plantilla utilizada:

Documento de Revisión del sprint: Sprint NºX

1. Contenido del Sprint.
2. Resultados y valoración.
3. Cambios, mejoras y sugerencias.

A continuación, se puede acceder a todos los documentos generados, de cada Sprint, en imágenes. Estos documentos, al ser documentos firmados y con contenido escrito a mano, no se pueden transformar a formato Wiki, por lo que hemos decidido incorporarlos como fotografías.

• 
  Documento Revisión Sprint 1
• 
  Documento Revisión Sprint 2
• 
  Documento Revisión Sprint 3
• 
  Documento Revisión Sprint 4

• 
  Documento Revisión Sprint 5
• 
  Documento Revisión Sprint 6
• 
  Documento Revisión Sprint 7
• 
  Documento Revisión Sprint 8

Especificación y Diseño

Para realizar la especificación, en el servicio web, nos basamos en el diagrama de casos de uso del apartado anterior. Por cada caso de uso de dicho diagrama, se especificarían con mucho más detalle, los casos de uso que se exponen a continuación, determinando cual es su entrada, sus valores y sus salidas. Estas entradas y salidas son muy concretas, pues estandarizar las entradas y las salidas nos ayuda en el proceso de comunicación con las aplicaciones que deseen comunicarse con la API, y establecer un buen canal, con gran nivel de detalle es una labor necesaria para la reutilización de dicho servicio.

Todos estos diagramas se pueden encontrar en [[ http://chinator.260mb.net/api.html | la web de Chinator ]] aunque se expondrán aquí también para facilitar su lectura y en el caso de que la página web deje de dar soporte.

Casos de uso

Obtener Tienda

• URL: http://chinator.260mb.net/sw.php?command=getTienda&idTienda=id_tienda
• Variables GET:
  • int idTienda: el identificador numérico de la tienda que vamos a obtener.
• Variables POST:
  • int idTienda: el identificador numérico de la tienda que vamos a obtener.
• Return:

{
"return" :
    [
        {
            "ID" : "67",
            "nombre" : "CRM Arañuelo",
            "tipo" : "0",
            "latitud" : "39.8902902275255",
            "longitud" : "-5.534711480140686",
            "ciudad" : "Extremadura",
            "descripcion" : "Lo mejor del mundo",
            "direccion" : "Calle_Antonio_M'_Concha 104"
        }
    ]
}

• Errores:
  • {"error" : "Falta idtienda"}
  • {"error" : "ID tienda no encontrado. "}

Obtener lista de Tiendas

• URL: http://chinator.260mb.net/sw.php?command=getListaTiendas&ciudad=Comunidad_Autonoma
• Variables GET:
  • string ciudad: el nombre de la comunidad autónoma de la cual queremos obtener las tiendas, sustituyendo espacios por barras bajas.
• Variables POST:
  • Ninguno
• Return:

{
"return" :
    [
        {
            "ID" : "67",
            "nombre" : "CRM Arañuelo",
            "tipo" : "0",
            "latitud" : "39.8902902275255",
            "longitud" : "-5.534711480140686",
            "ciudad" : "Extremadura",
            "descripcion" : "Lo mejor del mundo",
            "direccion" : "Calle_Antonio_M'_Concha 104"
        },
        {
            "ID" : "67",
            "nombre" : "CRM Arañuelo",
            "tipo" : "0",
            "latitud" : "39.8902902275255",
            "longitud" : "-5.534711480140686",
            "ciudad" : "Extremadura",
            "descripcion" : "Lo mejor del mundo",
            "direccion" : "Calle_Antonio_M'_Concha 104"
        },
        {...}, ...
    ]
}

• Errores:
  • {"error" : "Falta Ciudad"}
  • Nota: si introduces un identificador de ciudad que no corresponde, no devolverá resultados.

Crear Nueva Tienda

• URL: http://chinator.260mb.net/sw.php?command=createTienda
• Variables GET:
  • Ninguna
• Variables POST:
  • string nombre: El nombre de la tienda que se va a crear.
  • int tipo: El tipo de tienda (0: general, 1: alimentación, 2: ropa, 3: todo a 100, 4: alimentación - todo a 100, 5: alimentación - ropa, 6: ropa - todo a 100.)
  • string descripcion: La descripción de la tienda.
  • float lat: Coordenada Latitud.
  • float lon: Coordenada Longitud.
  • string direccion: Dirección física de la tienda.
  • string horario: Horario de la tienda
  • string ciudad: Comunidad autónoma donde se encuentra la tienda.
• Return:

{"return" : [{ "text" : "New created"}]}

• Errores:
  • {"error" : "Invalid attributes: Nombre Tipo Latitud Longitud Ciudad . "}
  • Nota: La lista de invalid attributes irá variando dependiendo de las variables no válidas.

Borrar Tienda

• URL: http://chinator.260mb.net/sw.php?command=createTienda
• Variables GET:
  • int idTienda: el identificador numérico de la tienda que vamos a marcar para valorar de nuevo.
• Variables POST:
  • int idTienda: el identificador numérico de la tienda que vamos a marcar para valorar de nuevo.
• Return:

{"return" : [{ "text" : "Marked for deleting"}]}

• Errores:
  • {"error" : "La tienda no existe. "}

Obtener lista de tiendas pendientes de Valorar

• URL: http://chinator.260mb.net/sw.php?command=getPendientes&iduser=id_user
• Variables GET:
  • string iduser: el identificador del usuario. Cualquier identificador es válido, siempre que sea lo más único posible. (Nosotros utilizamos UUID)
• Variables POST:
  • Ninguna
• Return:

{
"return" :
    [
        {
            "ID" : "80",
            "nombre" : "prueb",
            "tipo" : "0",
            "latitud" : "37.240311928339594",
            "longitud" : "-5.794957838952541",
            "ciudad" : "Andalucía",
            "descripcion" : "prueb",
            "direccion" : "Urb._Marras_las_C 15"
        },
        {
            "ID" : "75",
            "nombre" : "mercado las maravillas ",
            "tipo" : "0",
            "latitud" : "40.44910582773961",
            "longitud" : "-3.7032270804047585",
            "ciudad" : "Madrid",
            "descripcion" : "tienda donde puedes comprar productos de comida",
            "horario" : "de lunes a sábado de",
            "direccion" : "en obras."
        },
        {...}, ...
    ]
}

• Errores:
  • {"error" : "Falta iduser"}

Valorar Tienda

• URL: http://chinator.260mb.net/sw.php?command=valoraTienda&idtienda=id_tienda&iduser=id_user&valoracion=boolean
• Variables GET:
  • int idTienda: el identificador numérico de la tienda que vamos a valorar
  • string iduser: el identificador del usuario. Cualquier identificador es válido, siempre que sea lo más único posible. (Nosotros utilizamos UUID)
  • boolean valoracion: indica si la valoración es positiva o negativa (true, false, 0, 1).
• Variables POST:
  • Ninguna
• Return:
  • {"return" : [{ "text" : "Valorado con exito"}]}
  • {"return" : [{ "text" : "Validada"}]}
  • {"return" : [{ "text" : "Tienda Borrada"}]}
• Errores:
  • {"error" : "No existe la tienda a valorar. "}
  • {"error" : "IDTienda IDUser valoracion (valid: 1,0,true,false) "}
  • Nota: los valores IDTienda, IDUser, y Valoracion pueden ir variando dependiendo de cual sea el que falte o sea erróneo.

Diagramas de Clases

Parte de todo diseño de un proyecto usualmente contiene diagramas de clases que ayudan a los programadores a conocer la estructura y el funcionamiento de dicho proyecto. Nosotros, aunque el código real es una versión mejorada (Pues el servicio web, por ejemplo, acopla todos los resultados en una clase Return que es un contenedor para resultados a mostrar), se generaron diagramas de clases tanto del servicio web como de la primera versión de la aplicación Android.

Esto agilizó el desarrollo y previno que surgiesen errores en el diseño más adelante, pues dichos diagramas fueron planteados en reuniones de los equipos de desarrollo y pasados a limpio por el equipo de programadores de Chinator.

Diagramas de clases del Servicio Web

Las capas de Integración y Negocio se ven fusionadas en este diagrama. Asimismo se ve que falta la vista del servicio web. Esto es debido a que un servicio web no tiene vista como tal, pues el servicio web existe para reemplazar la fase de integración y negocio de la aplicación Android, la cual hará de vista del proyecto.

No obstante existe una vista secundaria del servicio web. Dicha vista se puede visitar en http://chinator.260mb.net/mapa.html donde se pueden visualizar las tiendas sin necesidad de utilizar la aplicación Android.

La imagen muestra el diagrama de clases del servicio web de Chinator

Diagramas de clases de la aplicación Chinator V1.0

Los diagramas de clases de una aplicación Android son muy extensos y complejos, pues utilizan multitud de clases y funciones de dichas clases que no tiene sentido representarlas en un diagrama, como es el caso de las funciones onCreate de las Activity Android.

Por ello los diagramas que se muestran a continuación, muestran muy a grandes rasgos la arquitectura y el diseño interno de la aplicación Android, sin entrar en extremo detalle del sistema.

Además, los diagramas de la aplicación v2.0 no están disponibles, pues mejoran en gran medida la aplicación v1.0 e incluyen multitud de clases que lleva demasiado tiempo transcribir, realizando dichos diagramas a posteriori, no siendo útiles para el desarrollo del proyecto.

Diagrama de clases de la Vista

Diagrama de clases de la vista de la aplicación Android de Chinator.

Diagrama de clases del Negocio

Diagrama de clases de la parte de negocio de la aplicación Android de Chinator.

Diagrama de clases de Integración

Diagrama de clases de la Integración de la aplicación Android de Chinator.

Planificación Temporal

La planificación temporal del proyecto está basada en la planificación de sprints de Planificación de Sprints de SCRUM . Como dicha planificación es bastante extensa, y nuestro Software de creación de Diagramas de Gantt es limitado y tedioso de utilizar, únicamente se realizó el diagrama de Gantt de los 3 primeros sprints.

Planificación temporal, diagrama de Gantt Chinator

Análisis de Riesgos

Resumen

Se presenta el análisis de riesgo en la ejecución de un proyecto de creación de una aplicación Android para la geolocalización de tiendas de chinos.

Metodología Usada

La metodología usada para el análisis de riesgos de este proyecto ha sido a través del método de Boehm donde se han identificado los distintos riegos

Riesgos

A nivel de personal

• Deficiencias del personal
  • Probabilidad : Poco probable debido a que todos los miembros del equipo tenemos conocimientos suficientes para la elaboración del proyecto.
  • Impacto : Retrasos en la entrega del producto final para cuando está planificado y no conseguir los objetivos de cada semana
  • Técnica de reducción del riesgo : Formar a los integrantes que no tengan los conocimientos suficientes para la elaboración de cada parte del proyecto.
• Planificaciones poco realistas
  • Probabilidad: Si no existe una buena comunicación, una buena relación y/o entendimiento entre los miembros del grupo, se dificulta el hecho de cumplir con los objetivos y los requerimientos planteados.
  • Impacto: Retraso en la entrega de la primera versión operativa de la aplicación para su muestra al resto de la clase.
  • Técnica de reducción del riesgo: Estimación detallada de costes y planificación, diseñar en función del coste, desarrollo incremental, reutilización del software.
• Problemas o conflictos dentro del equipo de trabajo
  • Descripción: Si no existe una buena comunicación, una buena relación y/o entendimiento entre los miembros del grupo, se dificulta el hecho de cumplir con los objetivos y los requerimientos planteados.
  • Probabilidad: Es una posibilidad siempre latente, sin embargo no fue el caso de este proyecto, pues, siguiendo las pautas y canales de comunicación establecidos, no hubo mayores inconvenientes salvo quiza algun retraso en algun apartado.
  • Impacto: Se crea un ambiente de trabajo tenso, incómodo, que disminuye el desempeño del equipo y lo cual debilita el desarrollo del proyecto.
  • Técnica de reducción del riesgo: A la hora de tomar decisiones de cualquier índole, se debe tomar en cuenta la opinión de todos los miembros del equipo. En caso de que alguno esté en desacuerdo con algún aspecto de otro, comunicarlo de inmediato a los demás miembros y al implicado, de forma tal de solventar de la manera más limpia el incidente y evitar que pase a mayores.
• Retiro o abandono de algún miembro del equipo
  • Descripción: Es posible que por algun motivo algun miembro del equipo tenga que abandonar del mismo, trayendo como consecuencia el vacío en alguno de los roles dentro del equipo.
  • Probabilidad: Es poco probable pero no imposible. En efecto siempre está latente la posibilidad de que, por el motivo que sea, algún miembro del equipo abandone el mismo.
  • Impacto:Potencialmente muy grave, dependiendo por supuesto del rol del integrante en el equipo. De darse el caso, los demás miembros del equipo se recargan de trabajo lo cual afecta el avance del sistema requiriendo más tiempo del pautado inicialmente para el desarrollo del mismo.
  • Técnica de reducción del riesgo: Elaborar una planificación de trabajo alternativa para el desarrollo del proyecto tomando en cuenta la posible falta de algún miembro del equipo.

A nivel tecnológico

• Desarrollo erróneo de la interfaz del usuario
  • Probabilidad: Es algo probable debido a que existen distintos usuarios e integrantes del proyecto que no vean adecuada la interfaz que se ha desarrollado.
  • Impacto:Grave, debido a que después de un tiempo de diseño sería una pérdida de tiempo si los integrantes del grupo no aceptan la interfaz diseñada por lo que se perdería el tiempo que se ha invertido en ello.
  • Técnica de reducción del riesgo: Elaborar una interfaz adecuada al usuario haciendo preguntas a usuarios con perfil parecido y que necesiten una mejor adaptación al uso del mismo.
• Deficiencias en componentes proporcionados externamente
  • Probabilidad: Es probable que la versión de MySQL o de PHP implementada en el servidor elegido no sea la adecuada para la ejecución de las tareas necesarias de la aplicación.
  • Impacto: La aplicación no ejecutará las consultas adecuadas o esperadas e incluso la probabilidad de pérdida de datos.
  • Técnica de reducción del riesgo: Comprobación adecuada que las plataformas de desarrollo tienen las versiones adecuadas y encajan con el perfil que estamos buscando.
• Deficiencia o caída del servidor
  • Probabilidad: Alta y latente. Por ser un servidor gratuito, no ofrece las garantías de QoS (Quality of Service) que sí ofrecería un servidor pago.
  • Impacto: El servidor es un punto crítico dentro de la aplicación. El impacto es de alta magnitud, pues es imprescindible los servicios que nos presta el servidor que se usó para la aplicación (260mb) para el funcionamiento del mismo.
  • Técnica de reducción del riesgo: No se puede hacer mucho más que confiar en el buen desempeño del servidor, pues por el hecho de ser gratuito no hay manera legal legal ni moral de hacer alguna reclamación.

Informe Postmorten

Introducción

Alcance

Este documento abarca el proceso de Postmortem del Ciclo 1 de desarrollo del proyecto de aplicación para crear un servicio web capaz de proveer y almacenar tiendas de "Todo a 100" (Incluyendo las coordenadas de su ubicación) y crear una aplicación Android capaz de contactar con dicho servicio web, obtener la ubicación de tiendas de "Todo a 100" y mostrarlas en un mapa, visualizar los detalles de cada tienda, insertar y enviar datos de nuevas tiendas al servicio web, enviar solicitudes de borrado de tiendas y, adicionalmente, permitir a los usuarios decidir si las nuevas inserciones o peticiones de borrado se llevan a cabo o no, mediante un sistema de votos.

Descripción del documento

• En el capítulo 1 se hace una breve introducción a este documento, indicando su propósito, su alcance, describiendo su contenido.

• En el capítulo 2 se presenta un contexto general de lo estipulado en el lanzamiento y la estrategia del proyecto, incluyendo objetivos, requerimientos del ciclo, equipo de trabajo, planeación inicial y compromisos del grupo.

• En el capítulo 3 se presenta el reporte de actividades y avance respecto a metas del proyecto, incluyendo los riesgos del mismo y los eventos que se han presentado respecto a cada uno de ellos y a sus estrategias de mitigación.

• En el capítulo 4 se hace un reporte de avance en la elaboración del producto, describiendo su avance en términos de casos de uso, y el nivel de calidad con que ha sido desarrollado.

• En el capítulo 5 se hace un reporte del proceso en términos de sus metas, el avance frente a lo planeado, cómo se ha realizado el seguimiento y cómo ha funcionado el equipo.

Referencias

• Android developers: http://developer.android.com/index.html
  

• Google Play Services : https://developer.android.com/google/play-services/index.html
  

• APIs de localización: https://developer.android.com/google/play-services/location.html
  

• Manual de PHP : http://php.net/manual/es/index.php
  

Contexto

Objetivos del Proyecto

• Creación de una aplicación Android para la localización de tiendas de chinos a través de aplicaciones de localización y valoración de los usuarios.
• Diseño de una página web en php donde vendrá información de la aplicación y en la que estará alojada la base de datos y las distintas peticiones que hará la aplicación Android al servidor.
• Inserción en el mercado.

Requerimientos del ciclo

• Estudio de qué tipo de tiendas se van a incluir en la aplicación.
• Estudio de qué lenguaje se va a programar la aplicación servidor.
• Incluir la geolocalización de las distintas tiendas a mostrar.
• Diseño del diagrama de clases.
• Diseño e implementación de la base de datos y lenguaje a usar.
• Elección del servidor en el que alojar los servicios para su puesta en marcha.
• Elección de la API para la localización de las tiendas.
• Elección de plataforma para la que se va a desarrollar la aplicación móvil.
• Estudio de viabilidad de la misma aplicación.

Equipo

El equipo está formado por 5 alumnos de la asignatura y está compuesto por:

• Ivan Perez
• Javier Mansilla
• Juan Zamorano
• Antonio Mundo
• Jorge Moreno

Planificación

Se realizó un ajuste de las características específicas para efectuar la planificación, lo cual dio lugar a la siguiente distribución.

Actividad	% Estimado	Horas
Lanzamiento	10%	6
Planificación	15%	9
Requerimientos	5%	3
Diseño	15%	9
Implementación	25%	15
Pruebas	20%	12
Postmorten	5%	3
Tareas administrativas	5%	3
Total Horas		60

Compromisos

• Establecer un sitio de Reuniones (laboratorio de la asignatura cada Miércoles de cada semana) y participar activamente en ellas.
• Cumplir con los compromisos adquiridos para llevar a cabo el proyecto.
• Cumplir con la disponibilidad propuesta para el desarrollo del proyecto por cada uno de los miembros del grupo.
• Realizar aportes al grupo para producir un producto de calidad.
• Mantener actualizada la información contenida tanto en cuenta google drive, SVN Google Code, aplicación Trello para asignación de tareas.
• Mantener comunicación continua con los miembros del grupo de trabajo por cualquiera de los medios existentes (Chat, correo, wiki, skype).
• Cada uno debe velar por el cumplimiento de sus objetivos en cada ciclo.

Reporte de Proyecto

Actividad 1 : Estudiar y analizar cómo va a ser el desarrollo de la aplicación

La aplicación necesita que pueda posicionar la tienda a través de la API de geolocalización de google, además se necesitará una servidor Web para alojar la base de datos y para realizar las peticiones de la aplicación móvil.

Actividad 2 : Elección de plataformas y herramientas en las que realizar el desarrollo

Tras deliberar y recoger información de las distintas plataformas tanto para móvil como para alojamiento web se decide por:

• Para el alojamiento web se decide por desarrollar en lenguaje PHP y por su hosting en la página 260mb.net ya que es gratuito y permite contar con las funciones necesarias de la aplicación web.

• Para la aplicación móvil se decide el desarrollo para móviles con plataforma Android y la utilización de Google SVN para llevar el log de los distintos commits realizados en la misma.

• Para la documentación, diagramas de clases y definición de la estructura de la Base de Datos, entre muchos otros, se usó Google Drive.

• Como herramienta colaborativa de gestión de tareas que permite ver en qué se está trabajando, qué está realizando el resto y en qué parte del proceso se encuentra el mismo, se usó Trello.

• Se usó Google SVN para el control de versiones de la app desarrollada para plataforma Android y donde se puede observar la evolución de la misma y las mejoras introducidas.

Actividad 3 : Desarrollo del esqueleto del plan de proyecto y roles de equipo

Desarrollamos el plan de proyecto a llevar a cabo con las distintas metas a alcanzar en cada semana y definimos los roles que va a tener cada uno en el equipo.

Actividad 4 : Diseño App Android, diseño app PHP y plan de pruebas

• Un primer boceto de la aplicación Android nos permite cargar en mapa google maps la posición por posicionamiento GPS.
• Las primeras pruebas de la aplicación Android demuestran que cuando movemos el mapa a los pocos segundos te vuelve a situar en la posición que marca el GPS por lo que hace molesto el posicionamiento de una nueva tienda en caso que el usuario sepa donde se ubica dicha tienda.
• La plataforma web va tomando forma y se desarrolla el script Entidad-Relación para la creación de la base de datos necesaria para llevar a cabo las gestiones de la aplicación.

Actividad 5 : Mejora App Android, mejora App PHP y plan de pruebas

• Se mejora la aplicación Android con nuevos menús, funcionalidad para valorar positiva o negativamente una tienda y recibir un listado de las tiendas a valorar.
• Se diseña un sistema de parseo para obtener el listado de tiendas a través de una ciudad y de esta forma no tener que sobrecargar el servidor con todo el listado de tiendas pendientes de valorar.
• La página web en PHP ya tiene todas las acciones a realizar desde la aplicación movil y se diseña una página principal para información general y noticias de la misma.
• Se siguen realizando pruebas en distintos dispositivos móviles para comprobar fallos y mejoras.

Actividad 6 : Remasterizar logo, revisión estética app, pruebas en distintos dispositivos y redactar esqueleto términos y condiciones

• Se remasteriza el logo de la aplicación para darle un mejor aspecto.
• La estética de la aplicación Android se rediseña para proporcionar a la botonera nuevo aspecto y mejoras a la hora de hacer peticiones en el listado de tiendas a valorar.
• Se redactan los términos y condiciones de uso de la aplicación y se termina de diseñar todo el diagrama de clases del mismo.
• La aplicación Android se promociona entre conocidos y amigos con el objetivo de una crítica constructiva.

Resumen

Logos Alcanzados

• La planificación fue conjunta, lo cual la hizo más efectiva.
• Las responsabilidades de cada rol fueron asumidas muy bien y cada uno se apropio de su respectivo rol.
• Se definieron compromisos claros en el grupo.
• Se aprovecharon las herramientas disponibles para lograr una comunicación fluida entre los miembros del equipo, como google drive, *Trello o google SVN además de herramienta movil como WhatsApp.
• Se dedicó bastante tiempo al análisis del documento y al ajuste de la arquitectura. Se logró una revisión conjunta de los procesos, *Lo que permitió que se lograra un programa de alta calidad.

Problemas encontrados

• Pérdida de ritmo en el grupo, en términos de seguimiento del proceso.
• Demoras en la ejecución de tareas y en la asistencia a reuniones en clase.
• El desconocimiento por parte de dos de los miembros del grupo para realizar una de las tareas dificultó la entrega de una de las partes de la aplicación Android.
• Las dificultades laborales de uno de los miembros del grupo dificultaron la ejecución de las tareas que tenían asignadas, lo cual afectó bastante el avance del proyecto.

Lecciones aprendidas

• Crear un sistema de multas para retrasos en las tareas y en la llegada a las reuniones funciona más como un elemento disuasivo para retrasos en dichas tareas que como elemento de lucro.
• Se deben implementar mecanismos claros de transferencia de conocimiento cuando se planean cambios de roles entre los miembros del equipo.
• No es necesaria una herramienta compleja para hacer seguimiento a las tareas. Una buena comunicación en el equipo y una herramienta básica como Google Docs pueden suplir herramientas más especializadas.
• De la misma manera, existen soluciones alternativas que pueden optimizar el proceso de calidad, y la revisión de pares, sumada a herramientas como el control de cambios de Word, parecen ser útiles en ese sentido.
• Las reuniones demasiado extensas, sin objetivos claros, sin control de tiempos y a horas muy tardías se vuelven improductivas.
• Un documento de Word no es suficiente para la visualización integral de matrices complejas de análisis de arquitectura empresarial. *Todo análisis de este tipo debe ser apoyado por herramientas externas que permitan la visualización global de toda la problemática.

Gestión de Calidad

Para gestionar la calidad, en Chinator hemos utilizado varios métodos. A continuación se realizará un listado de los métodos utilizados para garantizar la calidad del producto.

Generar documentación software dentro del código.

Aunque sea pequeña, existe documentación dentro del código de la Aplicación Android, y dentro del código de la página web. Dicha documentación está disponible dentro de los repositorios de Chinator, explorando el código fuente.

Realizar Diagramas UML antes de desarrollar.

Hemos generado diagramas UML para prevenir errores y defectos en el programa, y garantizar que la experiencia final de usuario sea más agradable. De esta manera mejoramos la calidad de nuestro producto. Dichos diagramas se pueden encontrar en el plan de proyecto de Chinator.

Realizar una planificación temporal para organizar el trabajo.

Organizar el trabajo con respecto al tiempo asegura que no vamos a dejar trabajo a medias, que dicho trabajo va a poder ser acabado con calma y pensando cada una de las lineas de código que se escribirán. Realizar una planificación implica que cada una de las tareas se van a poder hacer dedicando el tiempo previsto, y no menos del necesario. Dicha planificación está disponible también en el plan de proyecto de Chinator.

Realizar revisiones periódicas.

Revisar que el trabajo se haya realizado correctamente garantiza directamente la calidad, pues un trabajo mal hecho es resultado directo del fracaso de la organización. Estas revisiones se realizaban semanalmente con el objetivo de conocer la situación del proyecto, conocer el estado del trabajo que debemos tener acabado en dicho punto del proyecto, y plantear mejoras posibles para el proyecto, incrementando de esta manera la calidad del proyecto.

Realizar pruebas de software.

Realizar pruebas nos hace ver directamente la calidad que tiene nuestro producto. Si falla mucho, si se ve correctamente en todos los dispositivos, los tiempos de carga y tiempos de respuesta del servidor, etc... Nos sirven para conocer, mediante métricas, la calidad del software desarrollado y de la infraestructura de nuestro sistema. Estas métricas, estableciendo mínimos (Como que el servidor debe de dar respuesta antes de 3s, o que la aplicación debe fallar menos de 5 veces al día) que no debemos superar, nos ayudan a obtener el software con la calidad deseada.

Mecanismos alternativos.

Además de estos mecanismos mencionados, hemos utilizado otros mecanismos, como el uso de SVN que nos ayudan a mantener el código organizado, el uso de Google drive para mantener los documentos actualizados y coordinados entre los miembros del equipo, o el uso de WhatsApp para coordinar al equipo a la hora de realizar tareas.