DOCUMENTACIN

Aplicacin mvil OaxaTaxi.

INSTITUTO TECNOLGICO DE OAXACA

MATERIA:
Fundamentos de ingeniera de Software

INTEGRANTES:
Lpez Guzmn Oscar Eduardo

Montes Bautista Joaquin Enrique

Garca Labastida Daniel de Jess

Ortz Martnez Eric

Ramrez Arellano David de Jess

JULIO DE 2017
Contenido
1.Introduccin .......................................................................................................... 2
2.Desarrollo ............................................................................................................. 4
2.1 Comunicacin con el cliente .......................................................................... 4
2.1.1 Planteamiento del problema ................................................................... 4
2.1.1.1. Enunciado del problema ............................................................ 4
2.1.1.2. Formulacin del problema. ........................................................ 5
2.1.2. Objetivo ................................................................................................. 6
2.1.3. Recoleccin de requisitos ...................................................................... 6
2.2. Fundamento terico...................................................................................... 8
2.2.1. Metodologa de espiral .......................................................................... 8
2.2.1.1. Estructura bsica ........................................................................ 8
2.2.1.2. Modificaciones ............................................................................ 8
2.2.2. Anlisis de requisitos ............................................................................ 8
2.2.2.1. Ingeniera de requisitos ............................................................. 8
2.2.3. Modelos ................................................................................................ 8
2.2.3.1. Modelo de dominio. ................................................................... 8
2.2.3.2. Modelo de clases ....................................................................... 8
2.2.3.3. Modelo de casos de uso ............................................................ 8
2.2.3.4. Modelo de interfaces ................................................................. 8
2.3. Planificacin ................................................................................................. 8
2.3.1. Requisitos .............................................................................................. 8
2.3.2. Requisitos funcionales......................................................................... 17
2.3.3. Requisitos no funcionales. ................................................................... 17
2.4. Construccin de los modelos ..................................................................... 17
2.4.1. Modelo de dominio. ............................................................................. 17
2.4.2. Modelo de clases................................................................................. 19
2.4.3. Modelos de casos de uso .................................................................... 20
2.4.3.1. Casos de uso............................................................................ 20
2.4.3.2. Subcasos de uso del administrador .......................................... 22
2.4.3.3. Subcasos de uso del cliente ..................................................... 23
2.4.3.4. Subcasos de uso del conductor................................................ 24

1
 2.4.4. Descripcin de los casos de uso. ........................................................ 25
2.4.4.1. Casos de uso generales ........................................................... 25
2.4.4.2. Subcasos de uso del administrador ........................................... 25
2.4.4.3. Subcasos de uso del cliente ...................................................... 25
2.4.4.4. Subcasos de uso del conductor................................................. 25
2.4.5. Modelo de interfaces ........................................................................... 25
2.5. Pruebas y evaluacin del cliente .................................................................. 25
3. Conclusin......................................................................................................... 26

1.Introduccin
En esta documentacin, se detalla el proceso que se lleva a cabo para la realizacin
del diseo de una aplicacin mvil para los taxistas de la ciudad de Oaxaca de
Jurez.

En la ciudad de Oaxaca de Jurez, el transporte pblico resulta de vital importancia

para la ciudadana que diariamente realiza sus actividades laborales, acadmicas y
sociales. Existen tres tipos de transporte pblico en la ciudad, microbuses y
mototaxis, que siguen una ruta especfica, y el servicio de taxis que se divide en dos
grupos, los taxis que tienen una ruta marcada, comnmente llamados taxis
forneos, y aquellos que pertenecen a una unin de taxistas denominada Sitio,
de la cual tambin reciben su caracterstico nombre, Taxis de sitio.

En la actualidad, la globalizacin y la tecnologa avanzan a pasos agigantados, y la

poblacin est cada da en busca de mejores y ms eficientes servicios, la inclusin
de aplicaciones mviles que agilizan muchas labores cotidianas de las personas,
hace que los servidores pblicos busquen mtodos para modernizar sus servicios y
no perder clientes, ante la competencia que ofrece servicios actualizados.

La importancia de tener una aplicacin que permita controlar el proceso que implica
un viaje, desde la comodidad de un dispositivo mvil, radica en la libertad y
seguridad que un cliente puede sentir con un servicio de transporte pblico que se

2
preocupe por ellos; es por eso que resulta tambin de menester importancia realizar
un diseo que garantice que el proceso que implica un viaje en taxi, resulte en una
experiencia satisfactoria.

Para la realizacin de esta aplicacin, se ha decidido tomar una metodologa de

espiral clsica de 6 fases, y excluir una de sus fases, pues al tratarse de la
realizacin de un diseo, y no de un software completo, sera imposible contemplar
una etapa de codificacin.

A continuacin, se detallan las fases que se contemplaron para el desarrollo de este

diseo por cada iteracin.

Comunicacin con el cliente: Se realizaron las tareas necesarias para poder

plantear la comunicacin entre el desarrollador y el cliente, con el fin de establecer
el problema que resolver el sistema a desarrollar, dichas tareas son:

Planteamiento del problema.

Planteamiento del objetivo del sistema.
Recoleccin de requisitos.

Planificacin: Una vez obtenida toda la informacin del cliente referente a los
requisitos del sistema, se realiz el anlisis de dicha informacin para establecer un
listado de requisitos y determinar cules eran obligatorios, cules deseables, y por
qu.

Anlisis de riesgos: Se realiz un anlisis de riesgos potenciales que pudieran

resultar en prdidas de tiempo o dinero, se establecieron tiempos y se contemplaron
posibles medidas ante casos riesgosos.

Construccin y modelado: Se contempla todo el proceso de modelado, y diseo del

sistema, el cual comprende 4 modelos importantes:

Modelo de dominio
Modelo de clases
Modelo de casos de usos
Modelo de interfaces

3
Evaluacin del cliente: Etapa en la que se presenta al cliente el diseo del software,
se presenta tambin la documentacin y se lleva a cabo una retroalimentacin de
su parte para determinar cambio y correcciones siempre y cuando se traten de
aspectos que hayan sido contemplados en el primer contacto con l, y no se hayan
analizado o modelado de manera correcta.

En caso de futuras iteraciones, se contempla una estructura similar, pero cambiando

algunos procesos especficos, pues dichas iteraciones seran para perfeccionar el
modelo ya establecido.

2.Desarrollo

2.1 Comunicacin con el cliente

El primer acercamiento con los clientes, consisti en una charla con algunos vocales
de diferentes sitios de taxis de Oaxaca, en la cual se les cuestion, entre otras
cosas, su opinin sobre las aplicaciones mviles, y los principales problemas que
enfrentaban los sitios de taxis. Posteriormente, se propuso la realizacin del diseo
de una aplicacin mvil que resolviera estos problemas, y as se obtuvo la
confirmacin para comenzar con el diseo y se decidi que Oaxataxi, sera el
nombre de dicha aplicacin.

2.1.1 Planteamiento del problema

2.1.1.1. Enunciado del problema

En la ciudad Oaxaca de Jurez, una gran parte de la poblacin hace uso de los taxis
como su nico transporte pblico, sin embargo, hasta el da de hoy, la ciudad de
Oaxaca contina manejando un servicio de transporte tradicional, en el que los
usuarios buscan un transporte en la calle, es por eso que las empresas de
transporte buscan la vinculacin con los usuarios para trabajar en conjunto para una
mayor calidad de servicio, la adopcin de nuevas tecnologas comienza a resultar
de vital importancia en una poca de globalizacin y sacar provecho de estas
tecnologas para facilitar su labor.

4
En la actualidad se vive en una poca de estancamiento en el uso de tecnologas
para la automatizacin en el servicio de transporte. No existe un control de las
unidades de transporte, de demanda por parte de los usuarios, de sus ingresos, las
rutas optimas en diferentes situaciones tales como trfico lento, accidentes,
bloqueos, obras pblicas, o cualquier imprevisto que afecte la circulacin.

Oaxaca, es una ciudad que depende en gran medida del turismo que genera, en
todo el ao, se reciben visitantes de distintas partes del mundo, algunos de ellos
acostumbrados a mejores servicios de transporte, a menos trfico lento y una
cultura vial mas avanzada.

Los usuarios han evolucionado en el uso del transporte pblico, cada da est
buscando un servicio de transporte mas moderno y de mejor calidad, el uso de
aplicaciones mviles para tener un medio de transporte a su disposicin en breves
minutos adems de mejores tarifas y una mejor integracin con las nuevas
tecnologas.

2.1.1.2. Formulacin del problema.

En virtud de lo anterior, el sistema de agilizacin en el transporte pblico que se
disear, adems de llevar la tecnologa a un espacio donde no est presente,
busca resolver las siguientes interrogantes que surgen como parte de la
problemtica:

Cmo funcionara una aplicacin de transporte, implementada por transportistas

pbicos?

Se puede implementar un sistema as, sin quitar de funcionamiento el sistema

tradicional de taxis?

Qu cambios significativos puede llevar el uso de nuevas tecnologas en el

transporte?

Por qu otros sistemas similares no funcionaron en la ciudad de Oaxaca?

5
2.1.2. Objetivo
Disear un sistema informtico para los taxistas de la ciudad de Oaxaca de Jurez.

El diseo del sistema debe incluir caractersticas que permitan a los taxistas brindar
un servicio digital y estar informados de imprevistos en la ciudad que pudieran
dificultar su trabajo.

2.1.3. Recoleccin de requisitos

Para indagar sobre las necesidades que el sistema debe satisfacer, as como
comprender los procesos internos que se desarrollan mientras se presta el servicio
de transporte, se llevar a cabo una entrevista con uno de los representantes de
los sitios de taxis, que tendr la siguiente estructura:

Guion de entrevista:

Presentacin e introduccin a la entrevista.

Primera parte
1.- Cul es su nombre?
2.- Qu edad tiene?
3.- Cul es el cargo que ostenta dentro de la unin de taxis?
4.- Cunto tiempo tiene desempeando esta labor?

Segunda parte (Respecto al sistema)

5.- Cules son los problemas que debe resolver el sistema a disear?
6.- Qu caractersticas debe cumplir el sistema?
7.- Quines sern los usuarios finales?
8.- Cul, y cunta ser la informacin que almacene el sistema?
9.- Qu se har con dicha informacin?
10.- Cules son las caractersticas que debe cumplir un taxista para ser
contratado?
11.- Con cuntos taxis se cuenta actualmente?
12.- Durante qu horarios trabaja cada taxi?

6
 13.- Cul es el criterio que se utiliza para designar el precio que se le
cobrar a un cliente?
14.- Cules dira usted, que son los problemas mas frecuentes a los que
se enfrentan los taxistas mientras desempean su labor?
15.- En cuntos sitios estn divididos los taxis de Oaxaca? Y Cules son
sus lmites?
16.- Adems de los taxistas y los clientes Alguien mas utilizara la
aplicacin?
17.- Qu haran esas personas adicionales con la aplicacin?
18.- Cules son las funciones que desempea cada taxista?
19.- Cules son las funciones que, los representantes que no son taxistas,
desempean?
20.- Actualmente Utilizan algn tipo de call center o nmero para llamar
taxis?
21.- Cuentan con algn logotipo y/o color representativo de todos los
taxis?
22.- Qu interfaces de usuario debe contemplar el sistema?
23.- Cmo sern atendidas las peticiones de viaje?

Tercera parte
23.- Por qu le convenci la idea de una aplicacin mvil para el sitio?
24.- Cunto estaran dispuestos a invertir en mejoras fsicas que requiera
la aplicacin?
25.- Cmo se realizarn los cobros?
26.- Cmo se imagina el producto final?
27.- Cules cree que sean los problemas a los que se enfrentara para
implementarla?
28.- Qu opina del uso de las aplicaciones mviles en la actualidad?
29.- Conoce la aplicacin Uber? Qu opina de ella? La ha utilizado?
30.- Qu mejorara de esa aplicacin?
31.- Qu informacin de los empleados ser visible para el usuario?
32.- Qu debera hacer el sistema en caso de que un automvil se
descomponga a mitad del viaje?
33.- Qu har la aplicacin al recibir quejas del servicio?

7
 Agradecimiento y despedida.

La entrevista arroj una gran cantidad de informacin que ser til para determinar los
requisitos.

2.2. Fundamento terico.

2.2.1. Metodologa de espiral

2.2.1.1. Estructura bsica

2.2.1.2. Modificaciones

2.2.2. Anlisis de requisitos

2.2.2.1. Ingeniera de requisitos

2.2.3. Modelos

2.2.3.1. Modelo de dominio.

2.2.3.2. Modelo de clases

2.2.3.3. Modelo de casos de uso

2.2.3.4. Modelo de interfaces

2.3. Planificacin
La planificacin, es la segunda fase que contempla nuestra metodologa de espiral,
en ella se contemplan las tareas referentes a la gestin de los elementos bsicos
para la realizacin de nuestro diseo. Se contempla extraer los requisitos y
organizarlos de una manera que haga ms sencillo trabajar con ellos, para dicha
organizacin utilizamos diagramas y tablas para visualizar sus caractersticas.

2.3.1. Requisitos
Como resultado del anlisis realizado sobre las respuestas obtenidas en la
entrevista con el cliente, se realiz la siguiente tabla con un total de 81 requisitos;

8
se considera el nmero de requisito(Rn), la descripcin del requisito, la razn que
lo justifica y si se trata de un requisito deseable u obligatorio.

N Requisito Razn Deseable Obligatorio

R1 Se tratar de una El software funcionar X
aplicacin para nicamente en dispositivos
dispositivos mviles mviles
R2 El software estar El software ser soportado X
disponible en la Play por Android 3.0 o superior
Store
R3 El software estar El software ser soportado X
disponible en la App por iOS 7 o superior
Store
R4 La aplicacin no La primera ve que se inicie la X
funcionar sin registro aplicacin mostrar la opcin
previo de registrarse o iniciar
sesin.
R5 Se podr iniciar sesin El software contar con X
como taxista cuentas de tipo Taxista
R6 Se podr iniciar sesin El software contar con X
como cliente cuentas de tipo Cliente
R7 Se podr iniciar sesin El software contar con X
como dueo de taxi cuentas de tipo Taxista
R8 Se podr iniciar sesin El software contar con X
como administrador cuentas de tipo
administrador, para
gestionar y supervisar
cuentas
R9 La vista principal La interfaz principal ser un X
mostrar 5 opciones men de 5 opciones

9
R10 La primera opcin ser Botn que abrir un layout X
para pedir un viaje diferente para el proceso de
viaje
R11 La aplicacin detectar Se pedir autorizacin para X
la ubicacin del acceder a servicios de
usuario ubicacin
R12 El usuario podr El usuario seleccionar en el X
ingresar su destino mapa el destino.
R13 Llegar una A los 5 taxis disponibles mas X
notificacin a los cercanos les llegar una
taxistas cercanos notificacin de un viaje
R14 La aplicacin contar Cuando un taxista acepte el X
con una opcin para viaje, se enviar una
confirmar que el taxi notificacin al cliente y se
va en camino borrar la notificacin de
viaje de los otros taxis
R15 La aplicacin har que Tanto el cliente como el X
se acuerde el tipo de taxista podrn elegir si es un
cobro viaje con pago electrnico o
en efectivo, ambos deben
coincidir, para continuar
R16 El taxista podr Se preguntar al taxista X
ingresar cunto cunto ser el cobro
cobrar por el viaje
R17 El cliente puede Dentro de la notificacin de X
aceptar o rechazar el tomar el viaje, el cliente
precio puede aceptar o rechazar el
precio de un viaje
R18 Opcin para cancelar La aplicacin permitir X
viaje cancelar un viaje ya
establecido, especificando

10
 los motivos, por ambas
partes
R19 Opcin para ver datos Se contar con un botn par X
del conductor ver los datos del conductor
R20 La aplicacin mostrar El nombre del conductor X
el nombre del debe ser visible para todos
conductor
R21 La aplicacin mostrar El nombre del usuario ser X
el nombre del cliente. visible para el taxista
R22 La aplicacin mostrar Una imagen escaneada de la X
una imagen con la licencia de conducir ser
licencia del conductor parte de los datos del taxista
al cliente
R23 La aplicacin mostrar Se contar con un sistema de X
las opiniones de un puntuacin de 5 estrellas, y
taxista la posibilidad de hacer un
comentario acerca de un
taxista
R24 La aplicacin mostrar El nmero de placa ser X
el nmero de placa de visible para el usuario
un taxi
R25 La aplicacin mostrar La lista de conductores de un X
qu conductores taxi ser visible para el
conducen qu taxi usuario
R26 La segunda opcin del En la segunda opcin se X
men ser para abrir un layout con los taxis
visualizar mapa de disponibles marcados en un
taxis mapa
R27 Los taxis disponibles Una pequea imagen de un X
estarn marcados en taxi verde se mostrar
verde cuando un taxi est libre

11
R28 Opcin para ver Al clickear sobre una unidad X
informacin de la disponible se podr ver la
unidad informacin de esta
R29 Opcin para iniciar Al clickear sobre una unidad X
viaje disponible se podr solicitar
un viaje y una notificacin
ser enviada a esa unidad
R30 La tercera opcin del Se mostrar un botn que X
men ser para los abrir un layout para
ajustes visualizar los ajustes
R31 Se podr iniciar o Dentro de los ajustes se X
cerrar sesin podr ver la cuenta
R32 Se podrn ver y editar Se podr eliminar o agregar X
datos de tarjeta tarjeta de crdito/dbito
R33 La cuarta opcin ser Botn que abrir un layout X
para reportar quejas y con un formulario para
errores reportar errores o quejas del
servicio
R34 La quinta opcin ser Botn que finalizar la X
para salir aplicacin matando todos
sus procesos
R35 El taxista tendr la Con un sistema de X
opcin de enviar notificaciones se alertar de
notificaciones de un inconveniente en la
bloqueos o accidentes ciudad
a los dems taxistas
R36 Se podr puntuar el Con un sistema de 5 estrellas X
servicio se podr puntuar al taxista y
a la unidad
R37 La aplicacin permitir Al final del viaje se dar la X
agregar comentarios opcin de agregar

12
 acerca de un taxista o comentarios de el taxista o el
un taxi taxi
R38 Los dueos de algn Cada viaje se registrar en X
taxi pueden ver el una bd que ser visible para
historial completo de el dueo del taxi y para los
viajes administradores
R39 Opcin para reportar El taxista podr solicitar X
falla tcnica asistencia mecnica dejando
la unidad fuera de servicio
R40 Opcin de emergencia Sistema de emergencia en X
caso de robo o asalto que
alertar al sitio
R41 La aplicacin detectar En basea la ubicacin, la X
cuando se termine el aplicacin detectar cuando
viaje el viaje haya finalizado
R42 Opcin de reportar un El taxista o administrador X
usuario podr reportar un usuario
R43 Motivos de reporte Todo reporte tendr un X
motivo justificado y se
reportarn al administrador
en forma de notificacin
R44 Se podrn aadir fotos Permitir subir fotos a las X
en los reportes de notificaciones de bloqueo o
bloqueo accidente
R45 Detectar taxi en Se detectar cuando el taxi X
movimiento est en movimiento y se
deshabilitarn las opciones
de escritura manual
R46 Chat para taxistas Contar con un grupo de X
chat para los taxistas

13
R47 Opcin para pedir
reelevo cercano
R48 Opcin para compartir
R49 Opcin de descuento
R50 Servidor exclusivo
R51 Cambio de idioma
R52 Asistente de uso
R53 En la pantalla principal
sern visibles los logos
de los sitios
R54 Colores amarillos
R55 Diseo mnimalista
R56 Colores combinados
R57 Interfaces intuitivas
R58 Opcin de ayuda
Un taxi podr solicitar a otro X
que reeleve su pasaje
enviando los datos del viaje
Se podr realizar una X
publicacin referente a que
se est utiliando la aplicacin
En cada viaje se podrn X
ingresar codigos de
descuentos
Servidor dedicado para la X
aplicacin
Opcin en los ajustes para X
cambiar idioma a ingls o
espaol
En los ajustes se podr X
activar un asistente que
guiar enlos recorrridos
El layout principal tendr de X
fondo includos los logotipos
de los sitios
Se incluirn colores amarillos X
en todas las interfaces
Las interfaces deben ser X
minimalistas y no cargadas
Colores que combinen con el X
amarillo y no sean muy
llamativos
La aplicacin mvil debe ser X
fcil de utilizar
Botn para mostrar ayuda X
14
R59 Ayuda para clientes Ayuda especializada para los X
clientes
R60 Ayuda para los taxistas Ayuda especializada para los X
taxistas
R61 Ayuda para los dueos Ayuda especializada para los X
dueos de taxis
R62 Base de datos Base de datos MySQL en el X
servidor
R63 Seguridad Protocolos seguros para cada X
transaccin y manejo de
informacin
R64 Velocidad de la No debe presentar un X
aplicacin tiempo de respuesta lento
incluso en dispositivos de
gama baja
R65 Al registrarse solicitar Solicitar nombre del cliente X
nombre del cliente para la bd
R66 Al registrarse solicitar Solicitar edad del cliente X
edad del cliente para la bd
R67 Al registrarse solicitar Solicitar correo del cliente X
correo del cliente para la bd
R68 Al registrarse solicitar Solicitar numero de telfono X
numero de telfono del cliente para la bd
del cliente
R69 Opcin para inicio de Utilizar Apis para permitir el X
sesin con redes registro a travs de redes
sociales sociales como Facebook,
Twitter o Google
R70 Taxista podr reportar Un taxista puede reportar a X
a taxista otro especificando el motivo

15
R71 El administrador El administrador puede X
puede eliminar gestionar las cuentas de los
cuentas de taxistas taxistas
R72 El administrador El administrador puede X
puede eliminar gestionar las cuentas de los
cuentas de taxis taxis
R73 El administrador El administrador puede X
puede eliminar gestionar las cuentas de los
cuentas de clientes clientes
R74 El administrador El administrador puede X
puede eliminar gestionar las cuentas de los
cuentas de dueos dueos
R75 Modo de comandos de El taxista en movimiento X
voz activar el modo de
comandos de voz
R76 Comando de voz para Se iniciar el proceso de X
hacer un reporte reporte diciendo Hacer un
reporte
R77 Comando de voz para Se finalizar el viaje diciendo X
finalizar viaje Finalizar viaje
R78 Comando de voz para Se cancelar el viaje X
cancelar viaje cancelar viaje viaje
R79 Comando de voz para Se iniciar el proceso de X
pedir relevo peticin de relevo diciendo
Pedir relevo
R80 Opcin de contacto Se permitir a un usuario X
con el administrador contactar con el
administrador
R81 Ser visible el nmero En los layouts se mostrar un X
actual del call center mensaje de Prefiere

16
 llamar? Adjuntando el
nmero del call center
Tabla 1. Lista general de Requisitos

Despus de priorizar los requisitos y compararlos con nuestros conocimientos

previos de aplicaciones similares, logramos determinar que 71 de los 81 requisitos
resultan indispensables para el diseo optimo del sistema, siendo as 10 de stos,
requisitos deseables.

La lista de los requisitos servir como base para el correcto modelado de los
mismos.

2.3.2. Requisitos funcionales

2.3.3. Requisitos no funcionales.

2.4. Construccin de los modelos

La tercera fase de la metodologa de espiral, propone resolver de manera
conceptual, la problemtica planteada en la fase de comunicacin con el cliente,
con un diagrama de dominio se identifica el funcionamiento general de la aplicacin,
posteriormente se especifica, con un modelo de clases, el comportamiento de la
aplicacin, y con diagramas de casos de uso, se detallan los procesos con los que
cumplir el sistema.

2.4.1. Modelo de dominio.

Se realiza un modelo de dominio (Figura 1), para el cul se realiz un diagrama de
clases que lo representa. En base a los requisitos. Las clases abstradas fueron:

Administrador: Que se encarga de gestionar la aplicacin y mantener el control de

la misma. (R8, R71, R72, R73, R74).

Conductor: Representa la clase de todos los taxistas, se eligieron sus atributos

basndose en la informacin que en la entrevista con el cliente, nos dijo que
debamos mostrar. (R5, R16, R22, R35, R60, R70)

17
Cliente: Es el usuario final de la aplicacin, sus atributos son destinados para que
el viaje resulte seguro para todos. (R6, R12, R21, R32, R59, R65, R66, R67, R68).

Taxi: Aunque la clase sugiere la representacin de un automvil, aquellos que

accederan a este tipo de cuenta, seran los dueos de los taxis, para verificar su
historial, modificar su informacin, entre otras cosas. (R7, R24, R38).

Viaje: Representa la clase que engloba las caractersticas de un viaje, y sus

atributos son todo lo necesario para generar un registro completo. (R10, R12, R18,
R29, R38, R41)

Sitio: Hace referencia nicamente al punto en que se controlan todos los taxis. (R14,
R81)

Figura 1. Modelo de Dominio

El modelo de dominio nos proporciona una idea bastante clara del concepto del
problema, a pesar de tratarse de un modelo conceptual, el modelo de dominio nos

18
permite crear una estructura para el diseo y sirve como una conexin ms neutral
entre los requisitos y el diseo orientado a objetos, las relaciones y las propiedades
no presentaran alteraciones significativas en un posterior modelo.

2.4.2. Modelo de clases.

Se realiz un diagrama de clases orientado a objetos tomando como base los
requisitos, y el modelo de dominio; modelar las clases junto con sus
caractersticas y acciones, permite detallar y dar una estructura clara a nuestro
diseo.

La clase Usuario: Es una superclase de Taxi, Conductor y Cliente, representa

los tipos de sesiones que pueden ser abiertas adems de las cuentas privilegiadas
como las de administrador.

Figura 2. Modelo de clases

19
Gracias a este modelo de clases se pueden visualizar las relaciones entre las
clases que se involucran, adems se representan las acciones que cada clase
puede realizar, esto servir como base para un modelado de casos de uso.

2.4.3. Modelos de casos de uso

Se realizaron 4 diagramas de casos usos contemplando las acciones o usos que
cada actor identificado realizar dentro del sistema diseado.

2.4.3.1. Casos de uso

Para empezar, se implement un diagrama de casos de uso general (Figura 3),

que muestra las principales acciones que todos los usuarios pueden realizar.
Posteriormente, se modelaron las acciones especficas, o subcasos de uso que
cada actor poda realizar.

Dicho diagrama general de casos de uso, contempla dos actores principales:

Usuario: Que representa todo usuario del sistema, que no tenga permisos
suficientes para una gestin sobre cuentas que no sean la suya, este actor agrupa
a todos los que sern usuarios finales de los procesos de transporte.

Los usuarios pueden ser:

Cliente: Este actor hace referencia a los usuarios que harn uso de los
procesos de transporte, gestin de su propia cuenta, y realizacin de
reportes.
Conductor: El conductor, hace uso de los procesos de transporte como
prestador de servicio, gestin de su propia cuenta, y realizacin de reportes.

Administrador: Este actor, representa a los administradores del sitio que podrn
gestionar informacin referente a los usuarios y a los conductores, sobre este
actor recae la responsabilidad de atender las quejas y los reportes realizados por
los usuarios, por eso, a pesar de poseer casos de uso similares a los de los
usuarios, no se consideran como tal.

20
Figura 3. Modelo de casos de uso.

Cada actor est relacionado de diferente manera a 4 casos de uso cada uno, esta
relacin representa acciones que los actores pueden realizar, pero que no realizarn
de la misma manera

21
2.4.3.2. Subcasos de uso del administrador
El primer diagrama de subcasos de uso pertenece al actor Administrador.

Figura 4.
Casos de uso
del administrador

El administrador es el que mas vara en cuanto casos de uso se refiere, pues se

considera que todo el peso de gestionar las cuentas de los usuarios y los taxistas,
tambin recae sobre ellos.

22
2.4.3.3. Subcasos de uso del cliente

Figura 5. Casos
de uso del
cliente

23
2.4.3.4. Subcasos de uso del conductor

Figura 6. Casos de
uso del
conductor

24
El diagrama del cliente (Figura 5), y el del conductor (Figura 6), respetando la
estructura del diagrama general cuentan con 4 casos principales y con
especificaciones sobre procesos que incluye el hecho de gestionar su cuenta, y a
quienes se puede calificar, por ejemplo.

El diseo toma una forma bastante slida haciendo uso de estos diagramas.

2.4.4. Descripcin de los casos de uso.

2.4.4.1. Casos de uso generales

2.4.4.2. Subcasos de uso del administrador

2.4.4.3. Subcasos de uso del cliente

2.4.4.4. Subcasos de uso del conductor.

2.4.5. Modelo de interfaces

2.5. Pruebas y evaluacin del cliente

A manera de prueba, se considera que el cliente mismo sea quien defina si, el
diseo de verdad representa la aplicacin que se tena en mente, toda la
documentacin fue revisada por el cliente entrevistado y se recibieron los siguientes
comentarios:

Respecto al planteamiento del problema, se propone plantear como preguntas de

reflexin el tema de las aplicaciones mviles como uso cotidiano.

Respecto a los requisitos, se revis y aprob cada uno de los requisitos sin agregar
ni quitar ninguno de ellos.

Respecto al modelado no hubo muchos comentarios, todos los modelos fueron

aprobados y el cliente propuso algn bosquejo de cmo se veran las pantallas de
la aplicacin para ver el modelo como algo real.

El modelo fue claro y contundente para el cliente y algunos trabajadores que

estaban en el momento que se present la documentacin.

25
3. Conclusin
Realizada la documentacin de una primera iteracin del proceso de desarrollo de
software mvil para un servicio de taxis, que abarca nicamente hasta el diseo del
mismo, se ha podido dejar en claro que, una aplicacin funcional de este estilo, no
es una idea poco viable en la ciudad de Oaxaca de Jurez, como se pensaba; a
pesar de la renuencia de algunos dueos de taxis para que la aplicacin funcionara,
la mayora estaba decido a ser parte de un cambio generacional, dejando ver que,
no nicamente la poblacin es la que busca da a da que nuevas tecnologas sean
aplicadas a su vida diaria, sino que los trabajadores del transporte pblico tambin
esperan que en algn momento esta tecnologa pueda ayudarlos de manera eficaz.

Se puede concluir entonces, que una aplicacin mvil s puede integrarse al servicio
de transporte pblico integrando ambas formas de trabajo, y que si bien, otros
sistemas similares no funcionaron en la ciudad de Oaxaca, no ha sido por temor o
rechazo de los taxistas hacia las aplicaciones mviles, sino por su rechazo, a tener
competencia que no se encontrara en las mismas condiciones.

Respecto a la aplicacin se puede concluir que su diseo fue muy acertado, la

metodologa que se seleccion al principio fue utilizada de manera correcta,
considerando que nicamente se trataba de un diseo, sin embargo, el diseo
realizado puede bien aplicarse en el desarrollo de la aplicacin sin ningn problema.

26