RESUMEN

El siguiente documento entrega el proyecto denominado “Prototipo de Sistema de

Gestión Móvil de Radio Taxi”, que fue diseñado especialmente para esta actividad. La
problemática principal es que no hay un software que desarrolle tareas de informática como
asimismo de control de la flota.

El proyecto de título incluye las etapas: proyecto I y proyecto II, que considera: Plan
de trabajo metodología de desarrollo, análisis y diseño del sistema, prototipos funcionales de
la aplicación Web, Web Móvil y de la Api del google Maps. Además el plan de pruebas
parcial, con datos ingresados parcialmente, con el objetivo de un mejor funcionamiento de la
aplicación. Como también toda la investigación asociada para poder elaborar de una forma
óptima nuestro trabajo de título.

PALABRAS CLAVES: Web, Web Móvil, Api google Maps.

ABSTRACT

The following document to ides a project called " Mobile Radio Taxi Prototype" which
was specially designed for this particular assignment. The main problem is that there is no
such software as to develop the computing tasks of the control of the fleet.

The final assignment includes: Project I & Project II which considers: A work plan,
methodology development, analysis and system design, functional prototypes of the web
application, mobile web and google maps API. Besides the partial testing plan with partially
entered data with the aim to better the application performance as all the research also linked
to optimally prepare our job title.
1. Introducción

En el presente trabajo de título se da a conocer el trabajo realizado en los cursos de

proyecto I y proyecto II de la carrera de Ingeniería de Ejecución en Informática de la
Pontificia Universidad Católica de Valparaíso, proyecto que tiene como nombre Prototipo de
Sistema de Gestión Móvil de Radio Taxis. Se dará a conocer el análisis, diseño e
implementación de dicho prototipo, además de toda la investigación previa asociada tanto
como a las tecnologías informáticas como también al cliente objetivo del proyecto.

El tema a abordar es en el rubro de las empresas de radio taxis de Valparaíso, como es

bien conocido estas empresas se dedican a prestar servicios de transporte de usuarios, los que
pueden ser tanto dentro de la zona como fuera, aeropuerto, centros turísticos, regiones etc.

Este tipo de empresas están divididas en dos partes funcionales, los choferes con sus
automóviles designados o propios y la central de pedidos. Ambas partes comunican por medio
de radios, lo que genera que el chofer pierda la concentración en la conducción lo que puede
provocar un accidente de tráfico. Esta interacción es necesaria ya que la central no sabe la
ubicación actual del móvil, debe entregar la orden de un nuevo pedido o simplemente cancelar
una carrera.

Por otra parte la central no cuenta con un sistema informático acorde a sus necesidades
y lleva por intermedio de papel todos sus registros.

La idea principal es elaborar un sistema que permita tener un control de la flota, por
medio de dispositivos móviles, y que también permita gestionar la flota con una aplicación
web.
Si bien se ha señalado los aspectos principales del trabajo de título, es necesario
mencionar las diversas tecnologías y aplicaciones utilizadas a lo largo del trabajo realizado.
Las cuales serían las siguientes:

Asp.net. C#

SQL Server 2005

Visual Studio 2008

Entre otras.

Cabe señalar, que en el transcurso de este documento será explicaran con mayor detalle
cada una de estas, así como también hay que mencionar que se utilizan un número elevado de
tecnologías, entre las cuales existía algunas de conocimiento previo y otras que por el
contrario representaron un desafío en lo que respecta al aprendizaje de nuevos conocimientos
emanados del gran mundo de la informática.

2
2. Objetivos

2.1 Objetivo general

El objetivo del proyecto es desarrollar un prototipo de sistema para la gestión de

servicios de radio taxis utilizando tecnologías web, móviles y geo posicionamiento satelital

2.2 Objetivo específicos

 Investigar todas de las tecnologías necesarias para realizar del prototipo Web,
Web móvil y sistema de seguimiento (GPS).

 Recabar toda la información del cliente objetivo, su forma de trabajo e

identificar sus falencias.

 Elaborar una solución que permita mejorar la forma de trabajo de este tipo de
empresas, así como también la correcta integración de las tecnologías
utilizadas.

 Desarrollar un prototipo funcional que sea capaz de administrar una empresa de

radio taxis.
 Evaluar la solución propuesta mediantes pruebas de software.

3
3. Descripción de la empresa

Las empresas de radio taxi, son empresas que prestan servicio de traslado de pasajeros,
valores, mensajería como de encargos, además del Turismo en el ámbito nacional.
Las empresas de este rubro cuanta de dos áreas principales.
1. Central de pedidos. Está a cargo de La que se encarga de la recepción de los
pedidos, control y asignación de la flota, además del llevar el registro de la parte
contable de la empresa.

2. La flota. Está compuesta por una serie de automóviles con sus choferes, es la parte
móvil de la empresas

3.1. Flujo de trabajo.

Figura 1 Flujo de trabajo telefónico

4
Descripción de los pasos:

 Recepción del pedido. Aquí el recepcionista se encarga de verificar el tipo de

llama si esta para: realizar un pedido, modificar un pedido o para cancelar.

 Realizar pedido. Se capturan los datos tanto como del cliente como del
pedido que desea realizar, en caso de que el cliente no esté registrado se
registra.

 Registran datos. Se registrara el tipo del pedido, se le asigna un vehículo.

Este último ya se encuentra con un chofer asignado.

 Despacho del móvil. En este punto encontramos dos casos posibles.


El primero de ellos es que el móvil salga directamente de la central al origen
de cliente

O bien seria cuando el chofer tiene que terminar un pedido en curso para
acudir al nuevo.

En ambos casos la central llama al cliente para dar aviso que su taxi se
encuentra en camino.

 Modificar un pedido. En este caso el cliente debe tener un pedido

relacionado, al cual le desee modificar un campo.

 Búsqueda. La búsqueda del pedido se realiza mediante Rut del cliente o

bien por el ID del pedido.

 Se modifican. Los datos del pedido a decisión del cliente.

 Guardado. De los nuevos datos del pedido

 Cancelación de pedido. El cliente quiere cancelar una reserva hecha

anteriormente.

 Búsqueda. La búsqueda del pedido se realiza mediante Rut del cliente o

bien por el ID del pedido.

 Eliminación. Se elimina el pedido.

5
4. Problemática

Las empresas de este rubro no cuentan con sistema informático para la administración de
la flota, clientes frecuentes, choferes, por ende todos sus registros son manejados en algunos
casos en Excel o simplemente en papel.
El encargado de llevar estos registros por lo general cumple la función de recepcionista de
pedidos, por lo cual su trabajo se hace engorroso, si es un día con alta demanda de servicios
esto se complica aún más y se pierden clientes al no poder atenderlos.

La toma de decisiones pasa solamente por la experiencia que pueda tener el administrador
y con la escasa información que se ha obtenido. La asignación de un vehículo a un cliente es
una de la decisiones más comunes que se toman y a veces las respuestas a esta decisiones no
suelen ser las mejores.

4.1. Problemas encontrados

En el análisis de la empresa se encontraron distintos problemas y/o falencias que

impiden tener un funcionamiento más eficiente.
A continuación se entregara un detalle de los principales problemas:

 Recepción de un pedido. Si bien las empresas cuentan con personal que por
su experiencia puede entender una gran cantidad de pedidos en poco tiempo,
como la forma más tradicional de realizar un pedido es vía telefónica esto
provoca que la línea puede saturarse en periodo de tiempo, con lo cual se
perderán posibles clientes.

 Asignación de un pedido. La asignación de un pedido es vital para el

funcionamiento de la empresa y esta se realiza sin tener información
instantánea donde se encuentran los móviles, por lo cual se pierde tiempo en
establecer comunicación entre los posible automóviles que estén libres o
próximos al nuevo servicio.

 Registro de la flota. Si bien toda empresa sabe cuántos vehículos posee y la

capacidad de estos, no poseen una descripción más detallada de cada uno de
estos además de no contar con un seguimiento en tiempo real de la flota.

 Registro de choferes. La cantidad de choferes depende del tamaño de la

empresa de radio taxi, se mantiene un registro de cada uno lo que no revierte
mayor problema para la empresa. No se lleva a un registro acabado de los
servicios realizados
6
5. Estado del arte

5.1. Tecnologías
5.1.1. Sistema de Posicionamiento Global (GPS)

Gps o Sistema de Posicionamiento Global por sus siglas, es un sistema para

conocer nuestra posición a través de nuestra latitud, longitud y altura. Su
funcionamiento está basado por medio de 21 satélites que orbitan por la tierra, los que
promedio de una triangulación nos entregan nuestra posición con unos poco metros de
diferencia.

Figura 2 Sistema de Posicionamiento Global

7
5.1.2. Tecnología WAP

WAP es un protocolo basado en los estándares de Internet que ha sido

desarrollado para permitir a teléfonos celulares navegar a través de Internet. Con la
tecnología WAP se pretende que desde cualquier teléfono celular WAP se pueda
acceder a la información que hay en Internet así como realizar operaciones de
comercio electrónico.

WAP es una serie de tecnologías que consisten en: WML, que es el lenguaje de
etiquetas, WMLScript es un lenguaje de script, lo que vendría a ser JavaScript.

Las páginas WAP son simples ficheros de texto con extensiones WML.
Podemos definir WML como un lenguaje heredado de HTML, pero basado en XML, y
que es usado para especificar contenido para dispositivos WAP. Se usa para poder crear
páginas que pueden ser mostradas en un navegado WAP. WML usa lo que se llama
WMLScripts para poder ejecutar códigos simples en el cliente. Se puede comparar de
alguna manera con JavaScript, con la diferencia en que el consumo de memoria y CPU
es bastante menor.

5.1.2.1. Arquitectura
La arquitectura basada en la arquitectura definida para el World Wide Web,
pero adaptada a los nuevos requisitos del sistema.

Figura 3 Arquitectura WAP.

8
  Pasarela. Esta pasarela actúa como un mediador un dispositivo celular
y un servidor Web. Básicamente, enruta peticiones del cliente a un
servidor Web

 Servidor. Es el elemento que recibe la petición de la pasarela WAP,

procesa dicha petición y finalmente vuelve a enviar la salida a la
pasarela de nuevo. La pasarela entonces mandará la información al
dispositivo WAP.

 Cliente. Son los teléfonos móviles, los cuales son partes de la red
Wireless. Estos dispositivos envían la petición WAP a la pasarela WAP,
la cual a su vez traduce dichas peticiones en un formato que el servidor
Web puede entender. Cuando la pasarela WAP vuelve a recibir la
respuesta del servidor Web, lo vuelve a traducir en un formato WAP
para que el dispositivo lo pueda interpretar.

5.1.3. Tecnología GPRS

GPRS o en su traducción Servicio de Radio transmisión de Paquetes, es una solución

para datos móviles ya que ofrece más velocidad en los servicios de dato, esta tecnología es
conocida como “2.5” ya que proviene de su antecesor la tecnología GSM.

5.1.3.1. Que es Tecnología GSM

El sistema GSM es el sistema de comunicación de móviles digital de 2ª

generación basado en células de radio. Apareció para dar respuestas a los
problemas de los sistemas analógicos.
Fue diseñado para la transmisión de voz por lo que se basa en la conmutación
de circuitos, aspecto del que se diferencia del sistema GPRS. Al realizar la
transmisión mediante conmutación de circuitos los recursos quedan ocupados
durante toda la comunicación y la tarificación es por tiempo

9
5.1.3.2. Cómo Funciona el GPRS

Esta tecnología está basado en paquete, es decir que los datos son divididos
en varios paquetes que son transmitidos en breves ráfagas. Este diseño es más
eficiente ya que por una parte el usuario siempre está conectado por lo cual no
tiene que conectarse a la red para obtener los datos, segundo reduce los costos de
operatividad de la red.

En GSM, cuando se realiza una llamada se asigna un canal de

comunicación al usuario, que permanecerá asignado aunque no se envíen datos. En
GPRS los canales de comunicación se comparten entre los distintos usuarios
dinámicamente, de modo que un usuario sólo tiene asignado un canal cuando se
está realmente transmitiendo datos. Para utilizar GPRS se precisa un teléfono que
soporte esta tecnología. La mayoría de estos terminales soportarán también GSM,
por lo que podrá realizar sus llamadas de voz utilizando la red GSM de modo
habitual y sus llamadas de datos (conexión a internet, WAP,...) tanto con GSM
como con GPRS.

5.1.3.3. Velocidades

Tradicionalmente la transmisión de datos inalámbrica se ha venido

realizando utilizando un canal dedicado GSM a una velocidad máxima de 9.6
Kbps. Con el GPRS no sólo la velocidad de transmisión de datos se ve aumentada
hasta un mínimo 40 Kbps y un máximo de 115 Kbps por comunicación, sino que
además la tecnología utilizada permite compartir cada canal por varios usuarios,
mejorando así la eficiencia en la utilización de los recursos de red.
La tecnología GPRS permite proporcionar servicios de transmisión de datos
de una forma más eficiente a como se venía haciendo hasta el momento

10
5.2. La web

5.2.1. ¿Qué es la web?

La World Wide Web es un sistema de documentos o páginas web, interconectados

por enlaces de hipertexto, disponibles en Internet.

El elemento básico de la Web es la página web, un documento que contiene

enlaces de hipertexto a otros documentos relacionados que pueden estar localizados en
la propia máquina o en máquinas remotas. De esta forma, siguiendo los enlaces se
puede navegar por la red visitando páginas ubicadas en distintos lugares como si
formaran una unidad.

El protocolo de la Web específica un formato para escribir los documentos que

forman parte de ella: es el Hypertext Markup Language (HTML). Sin embargo,
también es posible acceder a documentos de otros formatos a través de la interfaz web
sin necesidad de reescribirlos, gracias a las funcionalidades incorporadas por los
navegadores.
La Web comenzó siendo un medio para el intercambio de información
básicamente textual, pero debido a su popularización ha ido incrementando su
contenido y actualmente puede utilizarse para transmitir cualquier tipo de medio, como
gráficos, imágenes, audio, vídeo o animaciones.

11
5.2.2. Tecnologías web

5.2.2.1. Navegador Web.

Es un software que permite visualizar páginas web a través de Internet,

algunos vienen incluidos en sistemas operativos y otros son gratuitos. Los
navegadores se comunican con los servidores web por medio de http para acceder a
las direcciones de internet a través de los motores de búsqueda.

Figura 4 Navegadores Web.

12
5.2.2.2. Aplicación Web

Una aplicación web es un programa diseñado para ejecutarse atreves de un

navegador web. Esta reside en un servidor y requiere de un computador con
conexión a internet para su empleo.

Figura 5 Aplicación Web.

Ventajas

 No requiere de un computador con gran tecnología.

 Es independiente al sistema operativo que se utilice.

 Presenta movilidad al usuario al tener acceso desde cualquier

computador con internet.

Desventajas
 Dependen de la conexión a internet.

 Estabilidad de servidor, muchas visitas en mismo lapso de tiempo.

13
5.2.2.3. Servidor Web

Un servidor Web es un programa que implementa el protocolo http. Este

protocolo está diseñado para transferir lo que llamamos hipertextos, páginas Web o
paginas HTML, textos complejos con enlaces, figuras, formularios, botones y
objetos incrustados como animaciones o reproducciones de sonidos.

Un servidor Web se encarga de mantenerse a la espera de peticiones HTTP

llevada a cabo por un navegador. El navegador realiza una petición al servidor y
este le responde con el contenido que el cliente solicita.

A continuación se dará un ejemplo de una petición.

Figura 6 Arquitectura Servidor Web.

 Escribimos la dirección en nuestro navegador.

 Este realiza la petición http al servidor.
 El servidor responde al cliente enviando el código de la página (HTML)
 El navegador recibe el código, lo interpreta y lo muestra por pantalla.

También podemos tener aplicaciones Web. Estas son fragmentos de código que
se ejecutan cuando se realizan ciertas peticiones o respuestas HTTP. Hay que tener
en cuenta que estas aplicaciones tienen caras por así decirlo.

 Aplicaciones en el lado del cliente: Son las aplicaciones tipo

Javascript, el servidor proporciona el código de las aplicaciones al
cliente y este, mediante el navegador, las ejecuta.

14
  Aplicaciones en el lado del servidor: el servidor Web ejecuta la
aplicación; esta, una vez ejecutada, genera cierto código HTML; el
servidor toma este código recién creado y lo envía al cliente.

Las aplicaciones de servidor suelen ser la opción por la que se opta en la

mayoría de las ocasiones para realizar aplicaciones Web. La razón es que, al
ejecutarse esta en el servidor y no en el computador del cliente, este no necesita
ninguna capacidad adicional, cualquier cliente dotado de un navegador Web básico
puede utilizar este tipo de aplicaciones

5.3. API de Google Maps

El API de Google Maps permite insertar Google Maps en las páginas web con
JavaScript. El API proporciona diversas utilidades para manipular mapas y añadir
contenido al mapa mediante diversos servicios, permitiendo crear sólidas aplicaciones de
mapas en tu sitio web. Es un servicio gratuito, disponible para cualquier sitio web que sea
gratuito para el consumidor.

Figura 7 Ejemplo Google Maps.

15
 5.4. Web móvil

5.4.1. ¿Qué es la web móvil?

La web móvil hace referencia a una web en la que el usuario puede acceder desde
cualquier lugar, independiente del tipo de dispositivo móvil que utilice.
Esta conexión puede ser por medio de Wi-Fi o por empresas que presten servicios
de internet móvil, las más conocidas en Chile son: ENTEL, CLARO, MOVISTAR.

Figura 8 Internet Móvil.

5.4.2. Limitaciones

1 2
En un estudio de realizado por Jakob Nielsen sobre “usabilidad móvil” da a
conocer 4 problemas que puede encontrar el usuario al momento de acceder a la web
móvil.

1 ingeniero de interfaces, obtuvo su doctorado en diseño de interfaces de usuario y ciencias de la

computación en la Universidad Técnica de Dinamarca.

2 Artículo publicado http://www.useit.com/alertbox/mobile-usability.html

16
  Pantallas pequeñas que un dispositivo sea móvil tiene relación con el
tamaño que este posea. Lo que da menos opciones visibles en un momento
dado, imposibilidad de más ventanas complicando la interacción.

 Entrada ineficiente la introducción de texto es lenta y propensa a errores

tipográficos, ya que se cuenta con mini teclado o con pantalla touch.

 Actualización la actualización de la página es muy lenta incluso contando con

tecnología 3g.

 Los sitios los sitios están enfocados para el uso de escritorio, por lo cual no
cumple con las especificaciones para el uso móvil.

Los primeros dos problemas son netamente de tipo de dispositivo móvil, en la

actualidad ya existen nuevos aparatos que logran aminorar estas limitaciones.

5.4.3. Web móvil del futuro

3
La idea de hacer más sencillo el uso de la web móvil, por lo cual la W3C
propone crear una web única que esté disponible para cualquier dispositivo Móvil. Lo
que ayudara a garantizar una mejor experiencia del usuario en el dispositivo móvil,
teniendo en cuenta las capacidades del dispositivo, la ubicación y la información del
contexto.

5.4.4. Tecnologías

 XHTML Su traducción es Lenguaje extensible de marcado de hipertexto, es el

lenguaje de marcado pensado para sustituir a HTML como estándar para las
páginas web. XHTML es la versión XML de HTML, por lo que tiene,
básicamente, las mismas funcionalidades, pero cumple las especificaciones,
más estrictas, de XML. La idea principal es que la información y la forma de
presentarla estén claramente separadas

3 El World Wide Web Consortium (W3C) es una comunidad internacional que desarrolla estándares que
aseguran el crecimiento de la Web a largo plazo

17
  Ventajas: Los documentos XHTML pueden visualizarse en navegadores
HTML. El código fuente que se obtiene es muy claro y muy fácil de
modificar. Compatible con los nuevos estándares que actualmente está
desarrollando el W3C como recomendación para futuros usuarios

 CSS: Es un lenguaje de hojas de estilos creado para controlar el aspecto o

presentación de los documentos electrónicos definidos con HTML y XHTML.
CSS es la mejor forma de separar los contenidos y su presentación y es
imprescindible para crear páginas web complejas.

Mejora la accesibilidad del documento, reduce la complejidad de su

mantenimiento y permite visualizar el mismo documento en infinidad de
dispositivos diferentes.
Al crear una página web, se utiliza en primer lugar el lenguaje
HTML/XHTML para marcar los contenidos, es decir, para designar la función
de cada elemento dentro de la página: párrafo, titular, texto destacado, tabla,
lista de elementos, etc.

Una vez creados los contenidos, se utiliza el lenguaje CSS para definir el
aspecto de cada elemento: color, tamaño y tipo de letra del texto, separación
horizontal y vertical entre elementos, posición de cada elemento dentro de la
página, etc.

5.5. Motor de base de datos.

5.5.1. PostgreSQL

Es un sistema de gestión de bases de datos objeto-relacional, distribuido bajo

licencia BSD y con su código fuente disponible libremente. Es el sistema de gestión de
bases de datos de código abierto más potente y robusto del mercado. Su desarrollo
comenzó hace más de 15 años, y durante este tiempo, estabilidad, potencia, robustez,
facilidad de administración e implementación de estándares han sido las características
que más se han tenido en cuenta durante su desarrollo. PostgreSQL funciona muy bien
con grandes cantidades de datos y una alta concurrencia de usuarios accediendo a la
vez al sistema.
Algunas características que presenta PostgeSQL son las siguientes:
 Acceso concurrente multi-versión (MVCC)
 Copias de seguridad.
18
  Disponible para Linux y UNIX en todas sus variantes (AIX, BSD, HP-UX, SGI
IRIX, Mac OS X, Solaris, Tru64) y Windows 32/64bit
 Juegos de caracteres internacionales

 Funciones/procedimientos almacenados (stored procedures) en numerosos

lenguajes de programacion, entre otros PL/pgSQL (similar al PL/SQL de
oracle), PL/Perl, PL/Python y PL/Tcl

 APIs para programar en C/C++, Java, .Net, Perl, Python, Ruby, Tcl, ODBC,
PHP, Lisp, Scheme, Qt y muchos otros.
 Llaves primarias y foráneas.

5.6. Entorno de desarrollo

5.6.1. Microsoft Visual estudio 2008

Es un entorno de desarrollo integrado para sistemas operativos Windows. Soporta

varios lenguajes de programación tales como Visual C++, Visual C#, Visual J#,
ASP.NET y Visual Basic .NET, aunque actualmente se han desarrollado las extensiones
necesarias para muchos otros.
Visual Studio permite a los desarrolladores crear aplicaciones de escritorio, sitios
y sistemas Web, así como servicios web en cualquier entorno que soporte la plataforma
.NET. Así se pueden crear aplicaciones que se intercomuniquen entre estaciones de
trabajo, páginas Web y dispositivos móviles.

5.6.2. SQL Server 2008 Express

Microsoft SQL Server 2008 Express es un sistema de administración de datos

eficaz y confiable que ofrece un variado conjunto de características, protección de
datos y rendimiento para clientes de aplicaciones incrustadas, aplicaciones web ligeras
y almacenes de datos locales. SQL Server 2008 Express, que está diseñado para una
implementación sencilla y una creación de prototipos rápida, está disponible de forma
gratuita y su redistribución con aplicaciones también es gratuita. Está diseñado para
integrarse a la perfección con otras inversiones de infraestructura de servidor.

[1] (Microsoft.SqlServer.Server2009) [2] (Microsoft Visual Estudio, 2008).

19
6. Solución propuesta

6.1. Nuevo Flujo de trabajo

Figura 9 Nuevo Flujo de Trabajo

Descripción de los pasos:

 Recepción del pedido. Aquí el recepcionista se encarga de verificar el tipo de

llama si esta para: realizar un pedido, modificar un pedido o para cancelar.

 Realizar pedido. Se capturan los datos tanto como del cliente como del
pedido que desea realizar, en caso de que el cliente no esté registrado se
registra.

 Registran datos. Se registrara el tipo del pedido, se le asigna un vehículo.

Este último ya se encuentra con un chofer asignado.
20
  Despacho del móvil. En este punto encontramos dos casos posibles.

El primero de ellos es que el móvil salga directamente de la central al origen
de cliente

O bien seria cuando el chofer tiene que terminar un pedido en curso para
acudir al nuevo.

 Modificar un pedido. En este caso el cliente debe tener un pedido

relacionado, al cual le desee modificar un campo.

 Búsqueda. La búsqueda del pedido se realiza mediante Rut del cliente o

bien por el ID del pedido.

 Se modifican. Los datos del pedido a decisión del cliente.

 Guardado. De los nuevos datos del pedido

 Cancelación de pedido. El cliente quiere cancelar una reserva realizada

anteriormente.

 Búsqueda. La búsqueda del pedido se realiza mediante Rut del cliente o

bien por el ID del pedido.

 Eliminación. Se elimina el pedido.

21
6.2. Flujo de trabajo Web

Figura 10 Nuevo flujo de trabajo web

Descripción de los pasos:

 Login. El Cliente al ingresar a la Sucursal Virtual debe identificarse.

 Realizar pedido. Se capturan los datos tanto como del cliente como del
pedido que desea realizar, en caso de que el cliente no esté registrado se
registra.

 Registran datos. Se registrara el tipo del pedido, se le asigna un vehículo.

Este último ya se encuentra con un chofer asignado.

 Confirmación. Luego de confirma se le entrega el ID del pedido al

cliente.
.

 No Registrado. Se debe registrar el cliente para realizar el pedido

22
  Registrar. Se registra el cliente, capturando sus datos, luego se direcciona
al login.

 Cancelar. No desear registrarse.

6.3. Solución General

Diseño e implementación de un sistema que nos permita gestionar una empresa de

radio taxis, desde la entrada de un pedido hasta que el servicio allá concluido. Todo esto
implementando una aplicación web, una web móvil, además de contar con un sistema de
seguimiento por cada automóvil que pertenezca a la empresa.

Figura 11 Modelo Solución General.

6.4. Soluciones Específicas

6.4.1. Gestión Pedidos

Para los pedidos van a existir 3 formas de realizar un pedido, con esto pretendemos
darle al cliente una mayor diversidad a la hora de necesitar un móvil, a continuación se
explicaran con detalles cada uno de estas formas.

23
  Telefónica. El cliente al llamar a la Central se pedirán sus datos, con lo cual se
conocerá si es cliente nuevo o ya ha utilizado antes el servicio, la información
personal del usuario también servirá para reducir los falsos pedidos. Este
módulo nos permitirá agilizar un pedido telefónico logrando atender una mayor
cantidad de llamadas en un mínimo de tiempo, así no se perderán clientes si la
línea está ocupada por mucho tiempo.

 Internet. El cliente deberá entregar una serie de datos personales como del
pedido, el administrador será avisado automáticamente de que hay un pedido
vía internet y este estará a cargo de dar de alta el pedido, avisándole
oportunamente al cliente. La ventaja que ofrece este módulo, será que el cliente
podrá reservar con una mayor cantidad de tiempo su radio taxi.

 Internet móvil: Estará enfocado al cliente que cuente con un dispositivo

móvil con capacidad de navegar por internet, por lo que se creara un módulo
dedicado para el pedido por este tipo de dispositivos, su funcionamiento será
igual al de vía internet. La ventaja que nos entregara este tipo de pedido será
captar al cliente que no puede realizar un pedido telefónico y no se encuentra
cerca de un computador.

Figura 12 Modelo de los pedidos.

Los pedidos estarán categorizados por distintos estados.

 Pedido Activo: Esto quiere decir que el servicio se encuentra en curso, ya se

encuentra con un cliente y un vehículo asignado.

24
  Pedido Reservado: El pedido no se ha realizado y no tiene asignado un
automóvil, el sistema para este tipo de pedidos deberá entregar una alerta
cuanto este próximo a cumplirse fecha y/u hora del pedido

 Pedido Terminado: Este tipo de pedido tendrá información de que

automóvil lo realizo y su costo.

6.4.2. Gestión de la Flota

6.4.2.1. Administrativa

Para la gestión de la flota se creara un módulo donde el administrador

pueda llevar un registro de todos los automóviles que componen la flota, donde se
podrá ver el estado en que se encuentra cada vehículo (operativo o en mantención),
los choferes que tienen asignados, datos propios de cada uno (patente, revisión
técnica, capacidad) además de un detalle de la última reparación que se le realizó a
cada vehículo.

6.4.2.2. Seguimiento Satelital

Cada automóvil contará con un sistema GPS, con el cual se podrá conocer
la posición actual de cada uno de éstos, lo que permitirá asignar el automóvil que
se encuentre más próximo a un nuevo cliente

25
 Figura 13 Modelo funcional de seguimiento satelital.

6.4.3. Gestión Choferes

Se creará un registro de cada chofer que trabaje en la empresa, con todos sus
datos personales y con los viajes que allá realizado en un periodo de tiempo, además de
tener una bitácora de observaciones. Los choferes serán ingresados previamente por el
administrador a cargo.

6.4.4. Gestión Administrador

Se creara un registro de administrador, con todos los datos personales, el cual

gestionara los choferes, la flota, recepcionistas y nuevos administradores. Se creara un
una administrador root para poder utilizar por primera vez el sistema.

26
6.4.5. Gestión Recepcionista

Se creara un registro recepcionista, con todos los datos personales, los permisos
que se le otorgaran serán la gestión de los pedidos y de los clientes. Un recepcionista
deberá ser registrado por un administrador para poder utilizar el sistema.

6.4.6. Gestión Cliente

Se confeccionará un registro de cada cliente, de sus últimos pedidos, si necesita

algún tipo de atención especial (para personas con capacidades especiales). Un cliente
deberá registrarse en el sistema si desea hacer un pedido vía internet e internet móvil.

27
7. Paradigma y metodología de desarrollo
7.1. Metodología de desarrollo.

La metodología escogida para el presente proyecto es la orientada a objetos, dada las

ventajas que presenta sobre el modelo de desarrollo estructurado. A continuación se
expondrán las principales características.

 Abstracción: Expresa las características esenciales de un objeto, las cuales

distinguen al objeto de los demás.

 Encapsulamiento: Se denomina encapsulamiento al ocultamiento de los

datos miembro de un objeto, de manera que sólo se puede cambiar mediante las
operaciones definidas para ese objeto

 Herencia: La herencia permite definir nuevas clases a partir de otras clases ya

existentes, de modo que presenten las mismas características y comportamiento
de éstas, así como otras adicionales.

 Polimorfismo: El polimorfismo es la propiedad en la que una función que

tiene el mismo nombre en diferentes clases, se ejecuta de forma diferente en
cada clase.
Algunas ventajas:

 Fomenta la reutilización de componentes.

 Construcción de prototipos
 Utiliza UML como lenguaje para documentar y especificar

 Presenta una alta modularidad lo que permite separar el sistema en secciones

más chicas que son más fáciles de programar

7.2. Paradigma de desarrollo.

En una primera instancia se comenzó a desarrollar el proyecto utilizando un modelo de

desarrollo en cascada, con lo cual se pensó que el modelo mencionado concordaba con el
proyecto, pero luego de un tiempo, se notó que los requerimientos no estaban totalmente
claros y no se adecuaba a las expectativas. Por lo cual el modelo de desarrollo en cascada no
era adecuado para el proyecto, por lo que se decidió cambiar el modelo de desarrollo y se notó

28
que el que mejor se adaptaba a las necesidades presentes era el modelo de desarrollo
incremental.

El modelo guía a utilizar corresponde al de Desarrollo Incremental. Este modelo se basa

en la construcción de solo una parte del sistema, con la finalidad principal de reducir las
dificultades y riesgos que pudiesen suscitarse al momento de ejecutar sistemas extensos.

Por lo cual se desarrollara el sistema por módulos, para así después continuar con los
siguientes módulos del sistema. Con esto se quiere lograr un mayor entendimiento de estos y
tener la posibilidad de detectar los distintos sucesos que ocurren a lo largo del desarrollo del
sistema.

En el modelo de desarrollo incremental para proyectos podemos destacar los siguientes

puntos:

 El hecho de que elaborar un sistema de tamaño pequeño, conlleva menores riesgos que
los asociados a uno de mayor magnitud.

 Si se cometen errores, el incremento desarrollado previamente puede ser utilizado.

Asimismo, los errores de desarrollo ejercidos en un incremento, cuentan con la
posibilidad de arreglo en el inicio del incremento sucesor.

 Al desarrollar las funcionalidades por parte, se hace más fácil conocer si los
requerimientos planificados para los niveles que siguen son adecuados y efectivos.

 Al realizar un desarrollo incremental del sistema, aminoran las probabilidades de

modificaciones que pudiesen surgir en el transcurso del proyecto, lo que representa un
bajo cambio de los requerimientos planteados por los usuarios.

 En cada incremento se puede usar un modelo diferente, cascada en el caso de que los
requerimientos estén bien claro o evolutivo si no están tan claros.

Esquema de cómo serán las iteraciones en el proyecto:

Figura 14 Modelo Incremental

29
7.3. Arquitectura.

Para el desarrollo de este proyecto se ocupara la arquitectura de 3 capas, la cual es una

especialización de la arquitectura cliente-servidor donde la carga se divide en tres partes
con un reparto claro de funciones: una capa para la presentación, otra para el cálculo y otra
para el almacenamiento.

Figura 15 Arquitectura de 3 capas.

 Presentación: Esta capa se comunica únicamente con la capa de negocio.

También es conocida como interfaz gráfica y debe tener la característica de ser
entendible y fácil de usar para el usuario.

 Negocio: Se denomina capa de negocio o lógica del negocio porque es aquí

donde se establecen todas las reglas que deben cumplirse. Esta capa se
comunica con la capa de presentación, para recibir las solicitudes y presentar
los resultados, y con la capa de datos.

30
  Capa de datos: Aquí es donde residen los datos y es la encargada de acceder
a los mismos. Está formada por uno o más gestores de bases de datos que
realizan todo el almacenamiento de datos, reciben solicitudes de
almacenamiento o recuperación de información desde la capa de negocio.

7.4. Herramientas.

Las herramientas que a continuación se van a exponer, nos ayudaran y facilitaran en el

trabajo de las distintas actividades que se realizaran en el transcurso del proyecto.

Microsoft Word. Es un programa editor de texto ofimático, permite crear

documentos sencillos o profesionales. Es el más popular en su estilo.

Microsoft PowerPoint: Es un programa que permite hacer presentaciones, y es

usado ampliamente los ámbitos de negocios y educacionales.

StarUml: Software gratuito, que permite confeccionar distintos tipos de diagramas y

UML.

DIA: Software gratuito, que también permite el manejo de diagramas y uml. Utilizado
para resolver las falencias del anterior.

31
8. Diagramas Caso de Uso
8.1. Caso de Uso General, aplicación Web

Figura 16 Diagrama Caso de uso general.

32
8.1.1. Especificaciones del caso de uso general.

Caso de uso: Gestionar Administrador

Actores: Principal: Administrador

Tipo: Principal

Descripción: El administrador podrá crear, buscar,

modificar, eliminar un administrador.
Tabla 1 Gestionar administrador

Caso de uso: Gestionar Recepcionista

Actores: Principal: Administrador

Tipo: Principal

Descripción: El administrador podrá crea, buscar,

modificar, eliminar un Recepcionista.
Tabla 2 Gestionar Recepcionista

Caso de uso: Gestionar Flota

Actores: Principal: Administrador

Tipo: Principal

Descripción: El administrador podrá agregar, eliminar,

modificar, buscar cada vehículo.
Tabla 3 Gestionar Flota

33
Caso de uso: Gestionar Chofer

Actores: Principal: Administrador

Tipo: Principal

Descripción: El administrador podrá crear, buscar,

modificar, eliminar un chofer, además
tendrá una bitácora del chofer donde se
encontrara un registro de sus servicios
realizados.
Tabla 4 Gestionar choferes

Caso de uso: Gestionar Pedidos

Actores: Principal : Recepcionista

Secundario: Cliente

Tipo: Principal

Descripción: El Recepcionista podrá crear, buscar,

modificar, eliminar un pedido. También
puede dejar una observación del pedido,
conocer el estado en que se encuentra,
asignar un automóvil al pedido.
El cliente solamente podrá crear un pedio.

Tabla 5 Gestionar pedido

34
Caso de uso: Gestionar Cliente

Actores: Principal: Recepcionista

Secundario: Cliente

Tipo: Principal

Descripción: El Recepcionista podrá crear, buscar,

modificar, eliminar un cliente, también
tendrá un registro de los últimos servicios
que ha solicitado.
El Cliente podrá solamente inscribirse en
el sistema, con esto podrá realizar pedidos
por internet.
Tabla 6 Gestionar cliente

35
 8.2. Caso de uso: Gestionar Recepcionista

Figura 17 Caso de uso Gestionar Recepcionista

8.2.1. Caso de uso: Gestionar Recepcionista – Narrativo Extendido

Caso de Uso: Gestionar Recepcionista.

Actor Principal(s): Usuario administrador.

Actor Secundario (s):

Propósito: Gestionar los recepcionistas de la
empresa.

Tipo: Principal.

36
Descripción: El administrador podrá realizar distintas
acciones sobre los recepcionistas de la
empresa.

Curso normal de los eventos:

ACTORES RESPUESTA DEL SISTEMA

1. El administrador selecciona del menú 2. Retorna las opciones:

principal –administración- la opción A. Ingresar recepcionista
“Clientes”. B. Modificar recepcionista
C. Eliminar recepcionista
D. Buscar recepcionista
E. Volver

3. Si el usuario administrador selecciona: 4.

A. Ingresar recepcionista A. Va al paso 5
B. Modificar recepcionista B. Va al paso 9
C. Eliminar recepcionista C. Va al paso 14
D. Buscar recepcionista D. Va al paso 20
E. Volver E. Ir al paso

5. Se solicita ingresar los datos del

recepcionista.

6. El administrador ingresa los datos del 7. El sistema verifica que el recepcionista

recepcionista no exista y que los datos ingresados sean
válidos.

8. Se ingresa el recepcionista al sistema y

se muestra un mensaje de que fue
ingresado exitosamente. Salta al paso 23.

9. El sistema pide ingresar el Rut.

10. El recepcionista ingresa el Rut 11. El sistema verifica si el Rut es válido

y si el recepcionista existe, mostrando en
pantalla todos los datos del recepcionista
que pueden ser modificados.
12. El administrador modifica los datos en 13. El sistema verifica que los nuevos
pantalla que desee y selecciona el botón datos ingresados son válidos y guarda las
modificar. modificaciones realizadas arrojando un
mensaje de éxito. Salta al paso 23

14. El sistema pide ingresar el Rut del

recepcionista.
3
7
15. El administrador ingresa el Rut. 16. El sistema verifica si el Rut es válido
y si el recepcionista existe, mostrando los
datos recepcionista.

17. El sistema arroja un mensaje de

advertencia indicando que se va a eliminar
un recepcionista, mostrando por pantalla
las opciones de aceptar o cancelar.

18. El administrador oprime el botón 19. El sistema elimina el registro del

aceptar. recepcionista y se muestra por pantalla un
mensaje de que la operación realizada fue
correcta. Salta al paso 23

20. Se pide ingresar el Rut del

recepcionista.

21. El administrador ingresa el Rut del 22. El sistema verifica que el Rut
recepcionista. ingresado es válido y que existe,
mostrando por pantalla todos los datos del
recepcionista.

23. Menú recepcionista.

24. Menú Administración.

Curso alternativo de los eventos:

7-B. Los datos ingresados no son válidos:

El sistema arroja un mensaje indicando de
que los datos ingresados no son válidos.
Salta al paso 23
7-C. El recepcionista ya existe:
El sistema arroja un mensaje indicando
que el cliente ya existe. Salta al paso 23

11-B. El Rut ingresado no es válido:

El sistema envía un mensaje indicando
que el Rut ingresado no es válido. Salta al
paso 23.
11-C. El recepcionista no existe:
El sistema envía un mensaje indicando
que el recepcionista no existe. Salta al
38
paso 23.

16-B. El Rut ingresado no es válido:

El sistema envía un mensaje indicando
que el Rut ingresado no es válido. Salta al
paso 23.
16-C. El recepcionista no existe:
El sistema envía un mensaje indicando
que el cliente no existe. Salta al paso 23.
17-B. El asistente presiona el botón
cancelar.
Salta al paso 23.
22-B. El rut ingresado no es válido:
El sistema envía un mensaje indicando
que el rut ingresado no es válido. Salta al
paso 23.
22-C. El recepcionista no existe:
El sistema envía un mensaje indicando
que el recepcionista no existe. Salta al
paso 23.

39
 8.3. Caso de uso: Gestionar Cliente

Figura 18 Gestionar Cliente

8.3.1. Caso de uso: Gestionar cliente – Narrativo Extendido

Caso de Uso: Gestionar cliente.

Actor Principal(s): Recepcionista.

Actor Secundario (s): Cliente

Propósito: Gestionar los clientes de la empresa.

Tipo: Principal.

Descripción: El usuario administrador podrá realizar

distintas acciones sobre los clientes de la
empresa.

Curso normal de los eventos:

ACTORES RESPUESTA DEL SISTEMA

1. El usuario administrador selecciona del 2. Retorna las opciones:

40
menú principal –administración- la opción A. Ingresar cliente
“Clientes”. B. Modificar cliente
C. Eliminar cliente
D. Buscar cliente
E. Volver

3. Si el usuario administrador selecciona: 4.

A. Ingresar cliente A. Va al paso 5
B. Modificar cliente B. Va al paso 9
C. Eliminar cliente C. Va al paso 14
D. Buscar cliente D. Va al paso 20
E. Volver E. Ir al paso

5. Se solicita ingresar los datos del cliente

6. El usuario cliente ingresa los datos del 7. El sistema verifica que el cliente no
cliente exista y que los datos ingresados sean
válidos.

8. Se ingresa el cliente al sistema y se

muestra un mensaje de que fue ingresado
exitosamente. Salta al paso 23.

9. El sistema pide ingresar el rut.

10. El usuario cliente ingresa el rut 11. El sistema verifica si el rut es válido y
si el cliente existe, mostrando en pantalla
todos los datos del cliente que pueden ser
modificados.
12. El usuario administrador modifica los 13. El sistema verifica que los nuevos
datos en pantalla que desee y selecciona el datos ingresados son válidos y guarda las
botón modificar. modificaciones realizadas arrojando un
mensaje de éxito. Salta al paso 23

14. El sistema pide ingresar el rut del

cliente.

15. El usuario administrador ingresa el Rut. 16. El sistema verifica si el Rut es válido
y si el cliente existe, además de que no
esté asociado a ningún pedido (pendiente).

17. El sistema arroja un mensaje de

advertencia indicando que se va a eliminar
un cliente, mostrando por pantalla las
4
1
 opciones de aceptar o cancelar.

18. El usuario administrador oprime el 19. El sistema elimina el registro del

botón aceptar. cliente y se muestra por pantalla un
mensaje de que la operación realizada fue
correcta. Salta al paso 23

20. Se pide ingresar el Rut del cliente o

bien los apellidos.

21. El usuario administrador ingresa el Rut 22. El sistema verifica que el Rut
del cliente. ingresado es válido y que existe,
mostrando por pantalla todos los datos del
cliente.

23. Menú cliente.

24. Menú Administración.

Curso alternativo de los eventos:

7-B. Los datos ingresados no son válidos:

El sistema arroja un mensaje indicando de
que los datos ingresados no son válidos.
Salta al paso 23
7-C. El cliente ya existe:
El sistema arroja un mensaje indicando
que el cliente ya existe. Salta al paso 23

11-B. El Rut ingresado no es válido:

El sistema envía un mensaje indicando
que el Rut ingresado no es válido. Salta al
paso 23.
11-C. El cliente no existe:
El sistema envía un mensaje indicando
que el cliente no existe. Salta al paso 23.

16-B. El Rut ingresado no es válido:

El sistema envía un mensaje indicando
que el Rut ingresado no es válido. Salta al
paso 23.
16-C. El cliente no existe:
El sistema envía un mensaje indicando
que el cliente no existe. Salta al paso 23.
16-B. El cliente está asociado a un pedido
42
 (pendiente):
El sistema envía un mensaje de que el
cliente registrado no se puede eliminar.
Salta al paso 23.
17-B. El asistente presiona el botón
cancelar.
Salta al paso 23.
22-B. El rut ingresado no es válido:
El sistema envía un mensaje indicando
que el rut ingresado no es válido. Salta al
paso 23.
22-C. El cliente no existe:
El sistema envía un mensaje indicando
que el cliente no existe. Salta al paso 23.

Tabla 7 Gestionar cliente - narrativo extendido

43
 8.4. Caso de uso: Gestionar chofer

Figura 19 Caso de uso: Gestionar chofer

8.4.1. Caso de uso: Gestionar chofer – Narrativo extendido

Caso de Uso: Gestionar chofer.

Actor Principal(s): Administrador.

Actor Secundario (s):

Propósito: Gestionar los choferes que trabajan en la
empresa.
Tipo: Principal.

Descripción: El usuario administrador podrá realizar

distintas acciones sobre los choferes que
trabajan en la empresa.

44
Curso normal de los eventos:
ACTORES RESPUESTA DEL SISTEMA

1. El usuario administrador selecciona del 2. Retorna las opciones:

menú principal la opción “Choferes”. A. Ingresar choferes.
B. Modificar choferes.
C. Eliminar choferes.
D. Buscar choferes.
E. Volver

3. Si el Usuario administrador selecciona: 4.

A. Ingresar choferes. A. Ir al paso 5
B. Modificar choferes. B. Ir al paso 9
C. Eliminar choferes. C. Ir al paso 14
D. Buscar choferes. D. Ir al paso 20
E. Volver E. Ir al paso

5. Se solicita ingresar los datos del

técnico.

6. El Usuario Administrador ingresa los 7. El sistema verifica que el Chofer no

datos del Chofer. exista y que los datos ingresados sean
válidos.

8. Se ingresa el chofer al sistema y se

muestra un mensaje de que fue ingresado
exitosamente. Salta al paso 23.

9. El sistema pide ingresar el rut del

chofer.

10. El usuario administrador ingresa el rut 11. El sistema verifica si el rut es válido y
del chofer. si el chofer existe, mostrando en pantalla
todos los datos del chofer que pueden ser
modificados.

12. El usuario administrador modifica los 13. El sistema verifica que los nuevos
datos en pantalla que desee y selecciona el datos ingresados son válidos y guarda las
botón modificar. modificaciones realizadas arrojando un
mensaje de éxito. Salta al paso 23

14. El sistema pide ingresar el rut del

chofer.

15. El Usuario administrador ingresa el rut 16. El sistema verifica si el rut es válido y

45
del chofer. si el chofer existe, además de que no esté
asociado a ningún automóvil.

17. El sistema arroja un mensaje de

advertencia indicando que se va a eliminar
un chofer, mostrando por pantalla las
opciones de aceptar o cancelar.

18. El usuario administrador oprime el 19. El sistema elimina el registro del

botón aceptar. chofer y se muestra por pantalla un
mensaje de que la operación realizada fue
correcta. Salta al paso 23

20. Se pide ingresar el rut del chofer.

21. El usuario administrador ingresa el rut 22. El sistema verifica que el rut
del chofer. ingresado es válido y que existe,
mostrando por pantalla todos los datos del
chofer.

23. Menú técnico.

24. Menú Administración.

Curso alternativo de los eventos:

7-B. Los datos ingresados no son válidos:

El sistema arroja un mensaje indicando de
que los datos ingresados no son válidos.
Salta al paso 24
7-C. El técnico ya existe:
El sistema arroja un mensaje indicando
que el técnico ya fue registrado
anteriormente. Salta al paso 23

11-B. El rut ingresado no es válido:

El sistema envía un mensaje indicando
que el rut ingresado no es válido. Salta al
paso 23.
11-C. El técnico no existe:
El sistema envía un mensaje indicando
que el técnico no existe. Salta al paso 23.
16-B. El rut ingresado no es válido:
El sistema envía un mensaje indicando
que el rut ingresado no es válido. Salta al
46
 paso 23.
16-C. El técnico no existe:
El sistema envía un mensaje indicando
que el técnico no existe. Salta al paso 23.
17-B El usuario administrador presiona el
botón cancelar.
Salta al paso 23
22-B. El rut ingresado no es válido:
El sistema envía un mensaje indicando
que el rut ingresado no es válido. Salta al
paso 23.
22-C. El técnico no existe:
El sistema envía un mensaje indicando
que el técnico no existe. Salta al paso 23.
Tabla 8 Gestionar chofer - narrativo extendido

47
 8.5. Caso de uso: Gestionar Flota

Figura 20 Caso de uso: Gestionar Flota

8.5.1. Caso de uso: Gestionar Flota – Narrativo extendido

Caso de Uso: Gestionar Automóviles.

Actor Principal(s): Administrador.

Actor Secundario (s):

Propósito: Gestionar los automóviles que pertenecen
a la empresa.
Tipo: Principal.

Descripción: El usuario administrador podrá realizar

distintas acciones automóviles que
pertenecen a la empresa.

Curso normal de los eventos:

ACTORES RESPUESTA DEL SISTEMA

1. El usuario administrador selecciona del 2. Retorna las opciones:

menú principal la opción “Flota”. A. Ingresar automóvil.
4
8
 B. Modificar automóvil.
C. Eliminar automóvil.
D. Buscar automóvil.
F. Volver

3. Si el Usuario administrador selecciona: 4.

A. Ingresar automóvil. A. Ir al paso 5
B. Modificar automóvil. B. Ir al paso 9
C. Eliminar automóvil. C. Ir al paso 14
D. Buscar automóvil. D. Ir al paso 20
E. Volver E. Ir al paso

5. Se solicita ingresar los datos del

automóvil.

6. El Usuario Administrador ingresa los 7. El sistema verifica que el Automóvil no

datos del automóvil. exista y que los datos ingresados sean
válidos.

8. Se ingresa el automóvil al sistema y se

muestra un mensaje de que fue ingresado
exitosamente. Salta al paso 23.

9. El sistema pide ingresar la patente del

automóvil.

10. El usuario administrador ingresa la 11. El sistema verifica si la patente es

patente del automóvil. válida y si el automóvil existe, mostrando
en pantalla todos los datos del automóvil
que pueden ser modificados.

12. El usuario administrador modifica los 13. El sistema verifica que los nuevos
datos en pantalla que desee y selecciona el datos ingresados son válidos y guarda las
botón modificar. modificaciones realizadas arrojando un
mensaje de éxito. Salta al paso 23

14. El sistema pide ingresar la patente del

automóvil.

15. El Usuario administrador ingresa la 16. El sistema verifica si la patente es

patente. válida y si el automóvil existe.

17. El sistema arroja un mensaje de

advertencia indicando que se va a eliminar
un automóvil, mostrando por pantalla las
4
9
 opciones de aceptar o cancelar.

18. El usuario administrador oprime el 19. El sistema elimina el registro del

botón aceptar. automóvil y se muestra por pantalla un
mensaje de que la operación realizada fue
correcta. Salta al paso 23

20. Se pide ingresar la patente del

automóvil.

21. El usuario administrador ingresa la 22. El sistema verifica que la patente

patente del automóvil. ingresada es válida y que existe,
mostrando por pantalla todos los datos del
automóvil.

23. Menú flota.

24. Menú Administración.

Curso alternativo de los eventos:

7-B. Los datos ingresados no son válidos:

El sistema arroja un mensaje indicando de
que los datos ingresados no son válidos.
Salta al paso 24
7-C. La patente ya existe:
El sistema arroja un mensaje indicando
que el automóvil ya fue registrado
anteriormente. Salta al paso 23

11-B. La patente ingresada no es válida:

El sistema envía un mensaje indicando
que la patente ingresada no es válida.
Salta al paso 23.
11-C. El automóvil no existe:
El sistema envía un mensaje indicando
que el automóvil no existe. Salta al paso
23.
16-B. La patente ingresada no es válida:
El sistema envía un mensaje indicando
que la patente ingresada no es válida.
Salta al paso 23.
16-C. El automóvil no existe:
El sistema envía un mensaje indicando
que el técnico no existe. Salta al paso 23.
50
 17-B El usuario administrador presiona el
botón cancelar.
Salta al paso 23
22-B. La patente ingresada no es válida:
El sistema envía un mensaje indicando
que la patente ingresada no es válida.
Salta al paso 23.
22-C. El automóvil no existe:
El sistema envía un mensaje indicando
que el automóvil no existe. Salta al paso
23.
Tabla 9 Gestionar flota - narrativo extendido

51
 8.6. Caso de uso: Gestionar Pedido

Figura 21 Gestionar Pedido

8.6.1. Caso de uso: Gestionar Pedido – Narrativo extendido

Caso de Uso: Gestionar Pedido.

Actor Principal(s): Recepcionista.

Actor Secundario (s): Cliente.

Propósito: Gestionar un pedidos tanto como por vía
telefónica como por vía web.
Tipo: Principal.

Descripción: El usuario administrador podrá realizar

distintas acciones agregar eliminar buscar
editar un pedido y el cliente podrá crear
un pedido.

52
Curso normal de los eventos:
ACTORES RESPUESTA DEL SISTEMA

1. El usuario administrador selecciona del 2. Retorna las opciones en caso de

menú administración la opción “pedido” y el Administrador:
cliente en inicio selecciona “Pedido”.
A. Ingresar pedido.
B. Modificar pedido.
C. Eliminar pedido.
D. Buscar pedido.
E. Volver
Retorna las opciones en caso de

Cliente:
AA. Ingresar pedido.
3. Si el Usuario administrador selecciona: 4.
A. Ingresar Pedido. A. Ir al paso 5
B. Modificar Pedido. B. Ir al paso 14
C. Eliminar Pedido. C. Ir al paso 19
D. Buscar Pedido. D. Ir al paso 26
E. Volver E. Ir al paso 40
Si el Cliente selecciona:

AA. Ingresar Pedido AA. Ir al paso 9

5. Se solicita el rut del cliente.

6. El Usuario Administrador ingresa el rut 7. El sistema verifica que el rut que exista.
del cliente.
8. El sistema entrega los datos del Cliente. 9. se solicita los datos del pedido.

10. el usuario administrador ingresa los 11. Se verifica que los datos del pedido
datos entregaros por el cliente. sean correctos.

12. El sistema pide confirmar el pedido.

13. el usuario confirma el pedido. 14. El sistema ingresa le nuevo pedido.

Ir a paso39.

15. El sistema pide ingresar el rut del

cliente o el código del pedido.

16. El usuario ingresa el rut del cliente y/o el 17. El sistema verificara si los datos
código del pedido. coinciden con algún pedido, mostrando
por pantalla la información del pedido.
5
3
 En caso que la búsqueda sea por rut se
desplegara un listado con los últimos
pedidos del cliente.

18. El Usuario administrador podrá 19. El sistema verifica que los nuevos
modificar los datos que desee finalizando datos ingresados son válidos y guarda las
apretando el botón modificar. En el caso que modificaciones realizadas arrojando un
se desplegué el listados del pedidos del mensaje de éxito. Ir a paso39.
cliente se deberá elegir le pedido a
modificar.
20. El sistema pide ingresar el rut del
cliente o el código del pedido

21. El usuario ingresa el rut del cliente y/o el 22. El sistema verificara si los datos
código del pedido. coinciden con algún pedido, mostrando
por pantalla la información del pedido.
En caso que la búsqueda sea por rut se
desplegara un listado con los últimos
pedidos del cliente.

23. El usuario selección el pedido y presiona 24. El sistema envía un mensaje de

el botón eliminar confirmación de la eliminación.

25. El usuario confirma la eliminación. 26 El sistema elimina el registro del

cliente y se muestra por pantalla un
mensaje de que la operación realizada fue
correcta. Ir a paso39.

27. El sistema pide ingresar el rut del

cliente o el código del pedido
28. El usuario ingresa el rut del cliente y/o el 29. El sistema verificara si los datos
código del pedido. coinciden con algún pedido, mostrando
por pantalla la información del pedido.
En caso que la búsqueda sea por rut se
desplegara un listado con los últimos
pedidos del cliente.

30. El sistema entrega los datos del

usuario y pide ingresar datos del pedido.
31. El Cliente ingresa los datos del pedido. 32. Se verifican que los datos sean
correctos.
33. se pide confirmar el pedido.
34. El Cliente confirma el pedido. 35. El sistema ingresa el pedido y lo deja
automáticamente pendiente. Enviando un
5
4
 mensaje al administrador que existe un
nuevo pedido. Ir a paso39.
36. El sistema pide ingresar el rut del
cliente o el código del pedido
37. El Cliente ingresa el rut y/o el código del 38. El sistema verificara si los datos
pedido. coinciden con algún pedido, mostrando
por pantalla la información del pedido.
En caso que la búsqueda sea por rut se
desplegara un listado con los últimos
pedidos del cliente. Ir a paso39.

39. Menú Pedidos.

40. Menú Administración.
Curso alternativo de los eventos:

7-B. El cliente no se encuentra registrado,

se envía al módulo ingresar cliente.

9-B. Los datos ingresados no son

correctos, el sistema señala cuales están
erróneos y se envía la paso 10.

12-B. Se cancela el pedido ir al paso 39.

17-B. Los datos ingresados no son
correctos, el sistema señala cuales están
erróneos y se envía la paso 15.
19-B. Se muestran los errores y se va a la
paso 18.
22-B. Se informa que no existe pedido o
que los datos son erróneos. Ir al paso 20

25-B. El usuario cancela la eliminación. Ir

al paso 39.
29-B. Los datos no coinciden.se muetra
un mensaje. Ir paso 39.
32-B. Hay datos erróneos se señala cuales
son y se pide corregirlos.
35-B. El cliente cancela el pedido. ir al
paso 39.
38-B. Los datos no coinciden señalando
que no existe. Ir al paso 39.
Tabla 10 Gestionar pedido - narrativo extendido

55
 8.7. Caso de uso: Gestionar Administrador

Figura 22 Caso de uso: Gestionar Administrador

8.7.1. Caso de uso: Gestionar Administrador – Narrativo extendió

Caso de Uso: Gestionar usuario administrador.

Actor Principal(s): Usuario administrador

Actor Secundario (s):

Propósito: Gestionar los usuarios administradores de
la empresa.

Tipo: Principal.

Descripción: El usuario administrador podrá realizar

distintas acciones sobre los usuarios
administradores de la empresa.

Curso normal de los eventos:

56
ACTORES RESPUESTA DEL SISTEMA

1. El usuario administrador selecciona del 2. Retorna las opciones:

menú principal –administración- la opción A. Ingresar usuario
“Usuario”. B. Modificar usuario
C. Eliminar usuario
D. Buscar usuario
E. Volver

3. Si el usuario administrador selecciona: 4.

A. Ingresar usuario A. Va al paso 5
B. Modificar usuario B. Va al paso 9
C. Eliminar usuario C. Va al paso 14
D. Buscar usuario D. Va al paso 20
E. Volver E. Ir al paso

5. Se solicita ingresar los datos del usuario

6. El usuario cliente ingresa los datos del 7. El sistema verifica que el cliente no
cliente exista y que los datos ingresados sean
válidos.

8. Se ingresa el cliente al sistema y se

muestra un mensaje de que fue ingresado
exitosamente. Salta al paso 23.

9. El sistema pide ingresar el rut.

10. El usuario cliente ingresa el rut 11. El sistema verifica si el rut es válido y
si el cliente existe, mostrando en pantalla
todos los datos del cliente que pueden ser
modificados.

12. El usuario administrador modifica los 13. El sistema verifica que los nuevos
datos en pantalla que desee y selecciona el datos ingresados son válidos y guarda las
botón modificar. modificaciones realizadas arrojando un
mensaje de éxito. Salta al paso 23

14. El sistema pide ingresar el rut del

cliente.

15. El usuario administrador ingresa el rut. 16. El sistema verifica si el rut es válido y
si el cliente existe, además de que no esté
asociado a ningún pedido (pendiente).

5
7
 17. El sistema arroja un mensaje de
advertencia indicando que se va a eliminar
un cliente, mostrando por pantalla las
opciones de aceptar o cancelar.

18. El usuario administrador oprime el 19. El sistema elimina el registro del

botón aceptar. cliente y se muestra por pantalla un
mensaje de que la operación realizada fue
correcta. Salta al paso 23

20. Se pide ingresar el rut del cliente o

bien los apellidos.

21. El usuario administrador ingresa el rut 22. El sistema verifica que el rut
del cliente. ingresado es válido y que existe,
mostrando por pantalla todos los datos del
cliente.

23. Menú cliente.

24. Menú Administración.

Curso alternativo de los eventos:

7-B. Los datos ingresados no son válidos:

El sistema arroja un mensaje indicando de
que los datos ingresados no son válidos.
Salta al paso 23
7-C. El cliente ya existe:
El sistema arroja un mensaje indicando
que el cliente ya existe. Salta al paso 23

11-B. El rut ingresado no es válido:

El sistema envía un mensaje indicando
que el rut ingresado no es válido. Salta al
paso 23.
11-C. El cliente no existe:
El sistema envía un mensaje indicando
que el cliente no existe. Salta al paso 23.

16-B. El rut ingresado no es válido:

El sistema envía un mensaje indicando
que el rut ingresado no es válido. Salta al
paso 23.
16-C. El cliente no existe:
58
 El sistema envía un mensaje indicando
que el cliente no existe. Salta al paso 23.
16-B. El cliente está asociado a un pedido
(pendiente):
El sistema envía un mensaje de que el
cliente registrado no se puede eliminar.
Salta al paso 23.
17-B. El asistente presiona el botón
cancelar.
Salta al paso 23.
22-B. El rut ingresado no es válido:
El sistema envía un mensaje indicando
que el rut ingresado no es válido. Salta al
paso 23.
22-C. El cliente no existe:
El sistema envía un mensaje indicando
que el cliente no existe. Salta al paso 23.

Tabla 11 Gestionar administrador - narrativo extendido

59
9. Modelo de Datos
9.1.Diagrama de Clases

Figura 23 Diagrama de clase

60
9.2. Modelo de datos: Entidad – Relación.

Figura 24 Modelo Entidad-Relación

61
9.3. Modelo de datos: Relacional.

Figura 25 Modelo relacional

62
10. Diagrama de Secuencia
10.1. Agregar Cliente

Figura 26 Diagrama secuencia - agregar cliente

63
10.2. Modificar Cliente

Figura 27 Diagrama secuencia - modificar cliente

64
10.3. Eliminar Cliente

Figura 28 Diagrama secuencia - Eliminar cliente

65
10.4. Asignar chofer

Figura 29 Diagrama secuencia - asignar chofer

66
10.5. Ingresar_pedido

Figura 30 Diagrama secuencia - ingresar pedido

67
11. Diagrama de despliegue

Figura 31 Diagrama de despliegue

68
12. Descripción Prototipo

A continuación se detallan los distintos elementos presentes en cada una de las

interfaces del Sistema de Control de Flujo de Trabajo

12.1. Interfaz

Figura 32 Interfaz

69
12.2. Navegabilidad
12.2.1. Principal

En la imagen que se muestra a continuación podemos apreciar la pantalla de

bienvenida de la aplicación web, esta sección es esencial en nuestra aplicación ya que
podremos encontrar información de la empresa y la sucursal virtual, parte en la cual el
cliente podrá acceder mediante un login. Por otra parte encontramos la sección
administración por la cual accederemos a otro login que será para el personal que
ocupara el sistema en sí.

Figura 33 Interfaz Principal

70
12.2.2. Login

Figura 34 Login

Este login corresponde a las personas Administrador, Recepcionista, al cual se

accederá en la parte administración de la página de bienvenida de la aplicación.

71
12.2.3. Administración

Para administrar un pedido entrante, debemos buscar el cliente ya sea por Rut o
por sus apellidos, una vez tengamos al el cliente rellenamos los datos tanto como la
dirección de origen como la de destino, una vez tengamos registrado esto asignamos el
estado si para el momento o si es una reserva a mayor tiempo. Cuanto tengamos ya
todos los datos solicitados al cliente asignaremos un taxista que se encuentre
disponible, esto lo podemos ver en una grilla que desplegara con todos los choferes
con que cuente la empresa terminado eso le damos a confirmar.

Figura 35 Administración

72
 12.2.4. Agregar Cliente

Para crear una ficha de un cliente, debemos seleccionar en las pestaña superior la
opción Clientes, una vez seleccionado se despegara una serie de datos a rellenar, si un
datos no es completado se remarcara para que sea corregido

Figura 36 Agregar Cliente

73
12.2.5. Modificar Cliente

Para modificar, seleccionamos clientes, luego en el sub-menu la opción

modificar, el cual desplegara una opción de buscar al cliente por su Rut, buscamos y
nos arrojara la información del cliente con todos sus datos para que sean modificados,
una vez aplicados le damos a aceptar.

Figura 37 Modificar Cliente

74
12.2.6. Eliminar Cliente

Escogemos la opción Clientes, luego en el sub-menu escogemos la opción

eliminar, se desplegara la opción de buscar cliente por su Rut, una vez encontrado se
desplegara toda la información del cliente, para confirmar la eliminación apretamos el
botón Eliminar. Se desplegara un mensaje con la confirmación de que el cliente fue
eliminado.

Figura 38 Eliminar Cliente

75
12.2.7. Login Móvil

Una vez que ingresemos a la página desde un dispositivo móvil, nos

direccionara a la opción de ingresar como cliente, con nuestro nombre de
usuario y contraseña.

Figura 39 Login movil

76
12.2.8. Solicitud taxi desde móvil

Para solicitar un taxi via móvil, nos vamos a la sección solicitar taxi,
donde se desplegara el mapa indicándonos nuestra posición actual, para
confirmar nuestra posición le damos a solicitar taxi el cual nos entregara un
mensaje de que el pedido fue solicitado.

Figura 40 Pedido Movil

77
13. Plan de pruebas

El plan de pruebas realizado para esta entrega, está diseñado para realizar pruebas de
caja negra con motivo de probar la funcionalidad del Módulo de Administrador y
Recepcionista. No se requiere otro tipo de pruebas debido a la gran cantidad de inspecciones
del código utilizando el depurador que provee visual Studio 2008.

Con el resultado de las pruebas notamos algunos errores como:

 En el ingreso de un pedido las direcciones tanto como origen y destino no eran

asignadas al pedido, por lo cual no quedaban registradas en la base de datos ya que de
por estructura deben tener una relación a un pedido.

 Al momento de ingresar un vehículo necesariamente debemos registrar un chofer a

cargo de este, pero el sistema no nos está dando la posibilidad de registrar un chofer en
caso que no exista ninguno.

 Idem para el caso pedido, en caso que no esté registrado el cliente.

El resultado de estas pruebas ha sido un éxito ya que se encontraron errores que no

estaban contemplados, por lo tanto estos serán solucionados a la brevedad.

Para ver las demás evaluaciones de esta prueba revisar el documento (Anexo A: Plan
de Pruebas).

78
14. Conclusiones

A lo largo del proyecto de título, mostramos las distintas etapas en la elaboración en la

elaboración de un software a medida de las cuales se obtuvo lo siguiente:

Investigación, si bien esta etapa es la inicial en la elaboración de un software es la que

presenta más desafío, ya que es en esta etapa donde debemos capturar la mayor información
relacionada con el cliente, logrando entender de forma minuciosa su forma de trabajar. Si no
logramos esto es muy probable que tengamos problemas que costaran un mayor tiempo en
resolver en las etapas siguientes de trabajo.

Diseño de una solución, una vez que se da por terminada la esta investigativa debemos
identificar todos los detalles de la situación actual del cliente, con esto poder crear varias
estrategias de diseño y poder optar a la que más se acomodé. En este diseños hay que
considerar que tendremos distintos elementos que interactuaran entre sí, como los son el
Hardware que contamos o que tendremos que adquirir y el recurso humano que interactuará
con nuestro sistema de información.

Desarrollo e implantación, cuando nos encontramos en esta etapa recién podremos

prototipos que nos ayudaran a entender de una mejor forma la funcionalidad de las distintas
actividades básicas de un sistema como son: la entrada, almacenamiento, procesamiento y
salida de la información. Sin embargo el manejó de las estas evoluciones es crucial para el
seguir agrupando las distintas características de cada uno de los módulos ya que si no
encontramos que la evolución ha dado los resultados esperados o el cliente decidió cambiar
alguna de las especiaciones podemos volver a una versión anterior. Una vez que tengamos
nuestro desarrollo terminado y el cliente satisfecho con su funcionamiento queda la parte de
implementación, la cual deberemos capacitar a él o los usuarios como también que logren
entender que la actual plataforma cambiara su actual forma de trabajar pero los beneficios
asociados a este cambio serán los óptimos.

Si bien este proyecto está enfocado en un cliente específico, hemos podido tener una
mirada real de lo que se trata la elaboración de un software, tendremos la capacidad analítica
para poder abarcar cualquier problema que se nos presente a lo largo de nuestra vida como
informático.

79
15. Bibliografía

 [1] (Microsoft.SqlServer.Server2009) Disponible en http://msdn.microsoft.com/es-

es/library/microsoft.sqlserver.server%28VS.85%29.aspx. Revisado por última vez el
15 de abril de 2010.

 [2] (Microsoft Visual Estudio, 2008).Disponible en:

http://www.microsoft.com/spanish/msdn/latam/visualstudio2008/descripcion.aspx,
Revisado por última vez el 15 de abril de 2010.

 [3] (Microsoft SQL Server 2008 Express Edition) Disponible en:

https://www.dreamspark.com/Products/product.aspx?productid=14, licencia bajo
convenio con la Pontificia Universidad Católica de Valparaíso

 [4] (Día, Programa para diagramas UML) Disponible en:

http://projects.gnome.org/dia/ Licencia Gratuita.

 [5] (StarUml) Disponible en: http://staruml.sourceforge.net/en/ Licencia Gratuita

 [6] (Vargas del Valle et al, 2007)Ricardo J. Vargas Del Valle, Juan P. Maltés
Granados. Programación en capas: Disponible en http://www.di-
mare.com/adolfo/cursos/2007-2/pp-.

 [7] (Temples Ocupado) Disponible en: http://www.freetemplatesonline.com/

 [8] (Departamento de Computación, FUIBA, 2006). Arquitectura del software.

Disponible en http://materias.fi.uba.ar/7572/.

80