3. DESARROLLO DEL PROYECTO
3.3 DESARROLLO DEL SPRINT 1
3.3.1 HISTORIAS DE USUARIO
Se inició con la fase de planificación, en ésta fase se identificó el alcance de la aplicación, para ello se realizaron reuniones periódicas con el Scrum Master en las que se establecieron los requerimientos que suplirá el sistema, tanto funcionales como no funcionales. Estos requerimientos fueron recolectados por medio de historias de usuario. Cada una de estas historias contiene la siguiente información [51]:
Nombre: Descripción de la funcionalidad que cumple la HU. Código: Cada tarjeta tiene un identificador único.
Historias de Usuario Relacionadas: Se establecen las dependencias y relaciones existentes entre HU.
Tipo de Historia de usuario: Descripción del tipo de historia de usuario, sea funcional o no funcional. Funcional para aquellas que definen lo que hace el aplicativo, y no funcional para las que describen la apariencia, sensación, operabilidad y mantenimiento de la aplicación [52].
Complejidad: Entre alta (A), media (M) y baja (B), se determina la dificultad para desarrollar cada historia de usuario.
Actor: Rol encargado de llevar a cabo la funcionalidad de la historia de usuario. Descripción: Responde a las preguntas: ¿qué rol es el beneficiado?, ¿qué
funcionalidad quiere del sistema? y ¿qué beneficio va a obtener?
Criterios de Aceptación: Se establecen los requisitos que se deben cumplir para que la HU sea aprobada por el cliente. Los criterios de aceptación se asemejan a un contrato, el cual es acordado entre el cliente y el equipo de desarrollo [53]. Módulo: Con el fin de facilitar la comprensión y legibilidad del aplicativo, el
proyecto se dividió en 4 módulos, cada uno encargado de resolver tareas específicas.
.
A continuación se presentan 11 historias de usuario, cada una con una descripción breve, comprensiva y delimitada.
MÓDULO RESPONSABILIDAD
GESTIÓN DE TARIFAS Encargado de cargar y actualizar, periódicamente, el
modelo de tarifa al inicializar el taxímetro.
MEDICIÓN
Encargado de hacer las mediciones con respecto al tiempo y a la distancia, calculando el costo total de la carrera. Además actualiza y calcula, mediante la asignación de coordenadas espaciales, la localización geográfica del móvil.
NOTIFICACIÓN
Cada vez que haya un nuevo modelo de tarifa, se le informa al usuario que el valor de la tarifa se ha actualizado. También ocurre una notificación cuando el usuario desea reportar en Twitter.
VALIDACIÓN Encargado de verificar, mediante técnicas estadísticas,
el correcto funcionamiento de la aplicación. Tabla 8. Módulos de la aplicación móvil. Fuente: Elaboración propia
3.3.1.1 HU: VERIFICAR Y SOLICITAR LA ACTIVACIÓN DEL GPS
HISTORIA DE USUARIO
Código: Hu_Med_01 Nombre: Verificar y solicitar la activación del GPS.
Tipo HU: Funcional. Complejidad: M
Actor: Sistema. HU Relacionadas: Ninguna
Módulo: Medición.
Descripción: Al iniciar la aplicación se verifica que el usuario tenga el GPS activo. Se asume que el usuario tiene conexión a internet.
CRITERIOS DE ACEPTACIÓN Condición:
Comprobar que el GPS no está activo.
Resultado:
Presentar un mensaje: “El sistema GPS está inactivo, ¿Desea activarlo?” (Redirigir a la configuración del GPS del móvil).
El usuario activa el GPS del móvil. 3.3.1.2 HU: MOSTRAR LA UBICACIÓN DEL USUARIO EN EL MAPA
HISTORIA DE USUARIO
Código: Hu_Med_02 Nombre: Mostrar la ubicación del usuario en el mapa.
Tipo HU: Funcional. Complejidad: M
Actor: Sistema. HU Relacionadas: Hu_Med_01.
Módulo: Medición.
Descripción: Guiar al usuario desde que inicia hasta que finaliza el recorrido por medio del mapa.
CRITERIOS DE ACEPTACIÓN Condición:
Abrir la aplicación.
Resultado:
Obtener las coordenadas de localización del dispositivo móvil y mediante un círculo azul, mostrar la posición del usuario.
3.3.1.3 HU: INICIAR APLICACIÓN
HISTORIA DE USUARIO
Código: Hu_Med_03 Nombre: Iniciar aplicación.
Tipo HU: Funcional. Complejidad: M
Actor: Usuario. HU Relacionadas: Hu_Med_01, Hu_Med_02
Módulo: Medición.
Descripción: Permite que el usuario inicie la aplicación y así comenzar la medición del recorrido. El sistema inicializa los contadores para la medición.
CRITERIOS DE ACEPTACIÓN Condición:
Abrir la aplicación.
La tabla de tarifa no existe.
Resultado:
- Inicializar el contador de tiempo y velocidad en: cero segundos y metros, respectivamente. - Inicializar las unidades de arranque según el modelo de tarifa que esté en vigencia (para el 2014 de 25 unidades).
- Inicializar el valor de la carrera mínima según el modelo de tarifa que esté en vigencia, (para el 2014 en $3.900).
- Verifica que la tarifa exista y esté actualizada.
- Descargar el modelo de tarifa de Parse.
3.3.1.4 HU: INICIAR MEDICIÓN
HISTORIA DE USUARIO
Código: Hu_Med_04 Nombre: Iniciar medición.
Tipo HU: Funcional. Complejidad: A
Actor: Sistema. HU Relacionadas: Hu_Med_01,
Módulo: Medición.
Descripción: Calcular las unidades transcurridas y determinar el factor por el que debe incrementar las unidades, si por distancia o por tiempo (depende de cual esté sucediendo más rápido).
CRITERIOS DE ACEPTACIÓN Condición:
La velocidad del vehículo es menor de 10Km/h.
La velocidad del vehículo es mayor de 10Km/h.
La velocidad del vehículo incrementa y es superior a 10km/h.
La velocidad del vehículo decrementa y es inferior a 10km/h.
Resultado:
Incrementar las unidades por tiempo cada 30 segundos.
Incrementar las unidades por distancia cada 100 metros.
Detener el contador de tiempo y retomar el valor del contador de distancia.
Detener el contador de distancia y retomar el valor del contador de tiempo.
3.3.1.5 HU: CONTABILIZAR Y SELECCIONAR RECARGOS
HISTORIA DE USUARIO
Código: Hu_Med_05 Nombre: Contabilizar y seleccionar recargos.
Tipo HU: Funcional. Complejidad: M
Actor: Usuario. HU Relacionadas: Hu_Med_05, Hu_Med_06
Módulo: Medición.
Descripción: Seleccionar los recargos que aplican al recorrido.
CRITERIOS DE ACEPTACIÓN Condición:
El usuario llega al lugar de destino y da click en el botón detener.
El servicio es pedido por teléfono/aplicación.
Resultado:
Desplegar un menú en el que el usuario podrá seleccionar los recargos a los que aplica la carrera.
Sumar al contador monetario el valor de dicho recargo, el cual dependerá del modelo de tarifa que se haya consultado (para el 2014 de $700).
El servicio de taxi es prestado desde / al aeropuerto.
El servicio de taxi es prestado desde el terminal de transporte.
El servicio de taxi es prestado entre las 10:00pm y las 5:00 am.
El servicio de taxi es prestado un día festivo o un domingo.
Sumar al contador monetario el valor de dicho recargo, el cual dependerá del modelo de tarifa que se haya consultado (para el 2014 de $3.900).
Sumar al contador monetario el valor de dicho recargo, el cual dependerá del modelo de tarifa que se haya consultado (para el 2014 de $500).
Sumar al contador monetario el recargo nocturno, (para el 2014 de $1900).
Sumar al contador monetario el recargo de día dominical o festivo, (para el 2014 de $1900).
3.3.1.6 HU: CALCULAR VALOR DE LA CARRERA
HISTORIA DE USUARIO
Código: Hu_Med_06 Nombre: Calcular valor de la carrera.
Tipo HU: Funcional. Complejidad: B
Actor: Sistema. HU Relacionadas: Hu_Med_03, Hu_Med_04,
Hu_Med_05.
Módulo: Medición.
Descripción: Sumar el valor de la tarifa básica y los recargos causados.
CRITERIOS DE ACEPTACIÓN Condición:
El usuario termina de seleccionar los recargos.
Resultado:
Sumar los recargos seleccionados al contador monetario (tarifa básica).
3.3.1.7 HU: ALMACENAR INFORMACIÓN DELSERVICIO
HISTORIA DE USUARIO
Código: Hu_Med_07 Nombre: Almacenar información del servicio.
Actor: Sistema. HU Relacionadas: Hu_Med_03, Hu_Med_04, Hu_Med_05, Hu_Med_06.
Módulo: Medición.
Descripción: Al detener el recorrido se debe almacenar los datos del servicio.
CRITERIOS DE ACEPTACIÓN Condición:
El usuario da click en “Detener”.
Resultado:
Almacenar en un repositorio central (Parse) los datos del servicio (Ver historia de usuario Hu_Med_08).
3.3.1.8 HU: GENERAR INFORME CON LOS DATOS DEL SERVICIO
HISTORIA DE USUARIO
Código: Hu_Med_08 Nombre: Generar informe con los datos del servicio.
Tipo HU: Funcional. Complejidad: M
Actor: Usuario HU Relacionadas: Hu_Med_03, Hu_Med_04,
Hu_Med_05, Hu_Med_06, Hu_Med_07.
Módulo: Medición.
Descripción: Generar un informe con los datos del servicio, para que posteriormente sirva como soporte en caso de que el usuario desee hacer una denuncia social o para futuros estudios estadísticos.
CRITERIOS DE ACEPTACIÓN Condición:
Al finalizar el recorrido dar click en “Datos de la carrera”.
Resultado:
Generar un informe con los siguientes datos: fecha, hora de servicio, unidades, costo total de la tarifa básica, costo total de los recargos causados, duración, distancia y total a pagar.
3.3.1.9 CARGAR MODELO DE TARIFA
HISTORIA DE USUARIO
Código: Hu_Tar_01. Nombre: Cargar modelo de tarifa.
Tipo HU: No funcional. Complejidad: M
Actor: Sistema, Administrador. HU Relacionadas: Hu_Med_03.
Módulo: Tarifa.
Descripción: Se carga en el servidor el modelo de tarifa.
CRITERIOS DE ACEPTACIÓN Condición:
No existe modelo de tarifa.
Al abrir la aplicación móvil TwTaxi.
Resultado:
El administrador ingresa a la aplicación, con usuario y contraseña e importa el modelo de tarifa a Parse.
La aplicación carga los datos que se encuentran en Parse y los guarda en la base de datos local SQLite.
3.3.1.10 HU: NOTIFICAR Y ACTUALIZAR MODELO DE TARIFA
HISTORIA DE USUARIO
Código: Hu_Tar_02. Nombre: Notificar y actualizar modelo de tarifa.
Tipo HU: No Funcional. Complejidad: M
Actor: Administrador. HU Relacionadas: Hu_Tar_01.
Módulo: Tarifa.
Descripción: Para que los valores a cobrar sean vigentes, se debe actualizar en el servidor el modelo de tarifa según lo reglamentado por la Alcaldía Mayor de Bogotá.
CRITERIOS DE ACEPTACIÓN Condición:
El modelo de tarifa no está en vigencia.
Resultado:
El administrador ingresa a la aplicación, con usuario y contraseña e importa el nuevo modelo de tarifa a Parse.
Al abrir la aplicación móvil TwTaxi. La aplicación detecta que las tarifas han sido actualizadas. Automáticamente, actualiza las tarifas en la aplicación:
- Borra las tarifas que se encuentran en la base de datos local.
- Carga la base de datos que se encuentra en Parse y los guarda en la base de datos local SQLite.
- Notifica con un mensaje al usuario: Las tarifas han sido actualizadas.
3.3.1.11HU: NOTIFICAR QUEJA EN TWITTER
HISTORIA DE USUARIO
Código: Hu_Not_01 Nombre: Notificar queja en Twitter.
Tipo HU: Funcional Complejidad: A
Actor: Usuario. HU Relacionadas: Hu_Med_03, Hu_Med_04,
Hu_Med_05, Hu_Med_06.
Módulo: Notificación.
Descripción: Si el usuario quiere reportar una situación anómala, puede difundirlo por medio de la red social Twitter.
CRITERIOS DE ACEPTACIÓN Condición:
Al finalizar el recorrido el usuario da click en la opción “Reportar”.
Resultado:
Publica en la red social Twitter un reporte con los siguientes datos: placas del taxi, empresa, unidades de diferencia, motivo del reporte y comentarios.