UNIVERSIDAD CIENCIAS DE LA INFORMATICA

FACULTAD DE INGENIERIA Y TECNOLOGÍA

DESARROLLO DE UN SISTEMA DE MONITOREO

Y CONTROL DE POSICIONAMIENTO VIA GPS
APLICABLE EN UNA FLOTA DE VEHÍCULOS

EDUARDO ACOSTA BECERRA

ANDRÉS BASAEZ MIRANDA
MARJORIE CCOPA FLORES
GABRIEL MUÑOZ
MIGUEL VARGAS WELCH

2010
 UNIVERSIDAD CIENCIAS DE LA INFORMATICA
FACULTAD DE INGENIERIA Y TECNOLOGÍA

DESARROLLO DE UN SISTEMA DE MONITOREO

Y CONTROL DE POSICIONAMIENTO VIA GPS
APLICABLE EN UNA FLOTA DE VEHÍCULOS

Trabajo de Titulación presentado en conformidad a los requisitos

para obtener el Título de Ingeniero de Ejecución en Informática.

Alumno(s) :
EDUARDO ACOSTA BECERRA
ANDRÉS BASAEZ MIRANDA
MARJORIE CCOPA FLORES
GABRIEL MUÑOZ MADRID
MIGUEL VARGAS WELCH

Profesor Guía :
GERARDO CERDA NEUMANN

FECHA DE PRESENTACION

13 de Agosto de 2010
RESUMEN

El presente informe detalla las etapas del desarrollo de un sistema de

control y posicionamiento de vehículos vía GPS aplicables a una flota de
vehículos.

El objetivo principal fue crear un sistema informático que permitiera,

mediante parametrización adecuada, realizar consultas dinámicas a los datos de
posicionamiento de los vehículos, capturados mediante dispositivos con
tecnología GPS, y almacenados en una base de datos, para realizar con ellos el
control de gestión a través de la generación de reportes de consulta en línea, de
su posición en un período determinado, generación de ruta óptima de viaje y
control de alertas definidas para velocidad y tiempo de desplazamiento.

El sistema, que ya se encuentra completamente operativo y funcionando,

se desarrolló con herramientas de tipo open source, permitiendo de esta forma
representar una alternativa de bajo costo, para potenciales clientes principalmente
del rango de pequeñas empresas de transporte.

Como objetivo adicional, se planteó dar a conocer el estado del arte de la

tecnología GPS, sus principales características y utilización en el rubro del
transporte nacional.
TABLA DE CONTENIDOS
CAPÍTULO 1: INTRODUCCIÓN....................................................................................................................................6
CAPÍTULO 2: OBJETIVOS..........................................................................................................................................8
2.1 OBJETIVO GENERAL................................................................................................................................8
2.2 OBJETIVOS ESPECÍFICOS .......................................................................................................................8
2. 3 ALCANCES Y LIMITACIONES................................................................................................................8
CAPÍTULO 3: MARCO TEÓRICO...........................................................................................................................10
3.1 QUÉ ES EL GPS? .................................................................................................................................................12
3.2 CARACTERÍSTICAS DEL GPS................................................................................................................13
3.3 DETALLES TÉCNICOS DEL FUNCIONAMIENTO DEL GPS.........................................................................14
3.3.1 PASO 1: TRIANGULACIÓN DESDE LOS SATÉLITES........................................................................14
3.3.2 PASO 2: MIDIENDO LA DISTANCIA A LOS SATÉLITES.................................................................15
3.3.3 PASO 3: CONTROL PERFECTO DEL TIEMPO...................................................................................15
3.3.4 PASO 4: CONOCER DÓNDE ESTÁN LOS SATÉLITES EN EL ESPACIO........................................16
3.3.5 PASO 5: CORRIGIENDO ERRORES.....................................................................................................17
3.3.6 DIVISIONES...........................................................................................................................................18
3.4 SEGMENTOS Y COMPONENTES DEL SISTEMA GPS...............................................................................19
3.4.1 SEGMENTO ESPACIAL........................................................................................................................19
3.4.2 SEGMENTO DE CONTROL.................................................................................................................20
3.4.3 SEGMENTO DE USUARIO...................................................................................................................21
3.5 TIPOS PRINCIPALES DE EQUIPOS GPS.......................................................................................................22
3.6 VENTAJAS Y DESVENTAJAS DE SU UTILIZACIÓN.................................................................................22
3.6.1 VENTAJAS...............................................................................................................................................22
3.6.2 DESVENTAJAS......................................................................................................................................23
3.6.2.1 ERRORES INTENCIONALES.............................................................................................................24
3.6.2.2 ERRORES PROPIOS DEL SISTEMA.................................................................................................24
3.7 MERCADO NACIONAL...................................................................................................................................26
3.8 COSTOS DEL SERVICIO..................................................................................................................................27
3.8.1 COSTO DE CONTRATO DEL SERVICIO DE GPS...............................................................................27
3.8.2 EQUIPOS UTILIZADOS EN EL MERCADO NACIONAL...................................................................27
3.9 METODOLOGÍA EMPLEADA.........................................................................................................................28
3.9.1 METODOLOGÍA XP O PROGRAMACIÓN EXTREMA.............................................................................28
3.9.2 USO PRÁCTICO DE LA METODOLOGÍA XP EN EL PROYECTO.........................................................38
3.9.3 GOOGLE CODE...........................................................................................................................................40
3.9.4 API DE GOOGLE MAPS..............................................................................................................................41
3.9.5 COMO INTEGRAR UN MAPA DE GOOGLE MAPS ................................................................................41
3.10 TECNOLOGÍAS EMPLEADAS.......................................................................................................................42
3.10.1 ARQUITECTURA DE LA SOLUCIÓN.................................................................................................42
3.10.2 TECNOLOGÍA DE DESARROLLO....................................................................................................44
CAPÍTULO 4. DEFINICIÓN DEL PROYECTO...........................................................................................................45
4.1 ALCANCE..........................................................................................................................................................45
4.2 DETALLE DE LA SOLUCIÓN........................................................................................................................46
4.3 ENTREGABLES.................................................................................................................................................47
4.4 ROLES Y RESPONSABILIDADES..................................................................................................................49
4.5 SUPUESTOS, RIESGOS, DEPENDENCIAS, RESTRICCIONES...................................................................51
4.6 ESTIMACIÓN DE RECURSOS/ HORAS.......................................................................................................52
CAPÍTULO 5: DISEÑO...........................................................................................................................................53
5.1 MODELAMIENTO....................................................................................................................................53
5.2 HISTORIAS DE USUARIO...............................................................................................................................55
5.3 CARACTERÍSTICAS.........................................................................................................................................60
PANTALLA PRINCIPAL.......................................................................................................................61
REPORTE DE VELOCIDAD.................................................................................................................61
REPORTE VEHÍCULO DETENIDO......................................................................................................61
5.4 MODELO DE CASOS DE USO.................................................................................................................62
5.4.1 MODELO DE CASOS DE USO - (USE CASE DIAGRAM) .................................................................62
5.4.2 ACTORES - (USE CASE DIAGRAM). ..................................................................................................63
5.4.3 ALERTA HORAS - (USE CASE DIAGRAM). .....................................................................................65
5.4.4 ALERTA VELOCIDAD - (USE CASE DIAGRAM)..............................................................................67
5.4.5 CONFIGURAR ALERTA - (USE CASE DIAGRAM) ...........................................................................69
5.4.6 SERVIDOR SISTEMA ALERTA - (USE CASE DIAGRAM) ..............................................................71
5.4.7 SERVIDOR SISTEMA RECEPCIÓN DATOS - (USE CASE DIAGRAM) .........................................73
5.4.8 CASO DE USO PRINCIPAL - (USE CASE DIAGRAM) ......................................................................75
5.4.8.1 AUTENTICAR - (SEQUENCE DIAGRAM) .......................................................................................76
5.4.8.2 BUSCAR VEHÍCULO - (SEQUENCE DIAGRAM) ...........................................................................78
5.4.8.3 DESPLEGAR UBICACIÓN - (COMMUNICATION DIAGRAM) .....................................................79
5.4.9 ADMINISTRACIÓN - (USE CASE DIAGRAM) ..................................................................................81
5.4.9 MODELO DE DATOS....................................................................................................................................83
5.5 CONSTRUCCIÓN DEL SISTEMA...................................................................................................................85
5.5.1 INTERFACES DE BÚSQUEDA Y DESPLIEGUE DE LA INFORMACIÓN DE UN MÓVIL .............85
5.5.1.1 ACCESO AL SISTEMA.......................................................................................................................86
5.5.1.2 MENU PRINCIPAL..............................................................................................................................87
5.6.1.3 SUBMENU CONFIGURACIÓN DE ALERTAS..................................................................................87
5.5.1.4 SUBMENU REPORTES.......................................................................................................................88
5.5.1.5 CONFIGURAR VEHÍCULOS:.............................................................................................................88
5.5.1.6 SUBMENÚ CONTROL MAPA............................................................................................................89
5.5.1.7 SUBMENÚ ALERTAS DE HORAS...................................................................................................90
5.5.1.9 EDITAR ALERTAS.............................................................................................................................92
5.5.1.10 SUBMENÚ ELIMINAR ALERTA.....................................................................................................93
5.5.1.11 SUBMENÚ ALERTA DE VELOCIDAD...........................................................................................94
5.5.1.13 EDITAR ALERTA DE VELOCIDAD................................................................................................96
5.5.1.14 ELIMINAR ALERTA DE VELOCIDAD..........................................................................................97
5.5.1.15 REPORTE VEHÍCULOS / VELOCIDAD MÁXIMA........................................................................98
5.5.1.16 REPORTE VEHÍCULO DETENIDO...............................................................................................100
5.5.1.17 REPORTE DISTANCIA RECORRIDA...........................................................................................101
CAPÍTULO 6: CONCLUSIÓN................................................................................................................................103
7.1 LINKS DE ACCESO A DOCUMENTACION DESDE INTERNET ...........................................................107
Capítulo 1: INTRODUCCIÓN

Hoy en día las empresas que hacen uso del GPS consiguen aumentar la
productividad del personal en movilidad además de obtener importantes ahorros
en combustible, según una reciente encuesta impulsada por Motorola entre 255
responsables de la toma de decisiones de TI y telecomunicaciones de
Norteamérica.

Según este estudio, el beneficio más citado por casi el 50% de las
empresas que utilizan actualmente el GPS, fue una importante reducción del
consumo de carburante, lo que tiene su reflejo en una disminución de las
distancias de los desplazamientos de 231,2 millas semanales de media, con un
ahorro registrado de 51.582 dólares anuales en carburantes. En Estados
Unidos, con más de un millón de camioneros, el ahorro potencial en el conjunto
de la industria podría alcanzar los 53.000 millones de dólares anuales.

El estudio reveló asimismo que las empresas que han desplegado

tecnologías GPS se ahorran aproximadamente 54 minutos al día, lo que se
traduce en un ahorro anual en mano de obra de 5.484 dólares por empleado, o
5,4 millones por empresa encuestada. Además del ahorro, también hay
aplicaciones de localización a las que se les atribuyen mejoras en la
organización de rutas, permitiendo a la empresa saber exactamente dónde
están sus empleados en cada momento, y examinar distintas posibilidades
antes de implementar una ruta. Las empresas encuestadas emplearon menos
tiempo en enfrentarse al tráfico o a hallar rutas, incrementando el tiempo
dedicado a nuevos o antiguos clientes. De hecho, al preguntarles por qué se
plantearían invertir en GPS u otras nuevas tecnologías, los encuestados
mencionaron la atención al cliente como su prioridad número uno.

El estudio también identificó otras aplicaciones esenciales, como la

navegación para mejorar la puntualidad y optimizar las rutas. Navegación y
optimización de rutas responden a las dificultades a las que con frecuencia
tienen que enfrentarse los trabajadores con movilidad de campo para localizar
nuevas paradas durante su recorrido y optimizar las entregas (1).

Por todo lo anterior, poder contar hoy en día con una solución de control
y monitoreo mediante GPS, para los operadores de flotas de vehículos , se ha
convertido en una inversión rentable al corto plazo, toda vez que los ahorros
logrados no solo son significativos en cuanto a los costos de combustible.
También permitir que los desplazamientos sean planificados y programados con
anticipación utilizando la información entregada por los software de monitoreo,
y dando la posibilidad de administrar y ordenar los tiempos de viaje, optimiza
las entregas de carga, el transporte a tiempo de personas o bien la operación
de la logística de entrega de insumos y productos de las empresas.

Por ello, y analizando la oferta de los distintos actores oferentes del

servicio de monitoreo vía GPS existentes actualmente en el mercado nacional,
hemos previsto la oportunidad de desarrollar un sistema de monitoreo de
móviles vía GPS, que considere la posibilidad de ser adquirido por flotas de
vehículos de tamaño mediano o pequeño.

Para cumplir con el objetivo propuesto de lograr un producto de bajo de

costo el sistema, que pretende ser una oferta alternativa al servicio ofrecido
por los proveedores actuales de esta tecnología en el país y que en general no
está al alcance de la mayoría de las Pymes que puedan requerirlo, será
desarrollado con herramientas de software abierto, y cubrirá las funcionalidades
básicas de reportaje de información.

(1) http://www.noticiasdot.com/wp2/2008/08/12/el-uso-del-gps-en-las-empresas
Capítulo 2: OBJETIVOS

2.1 OBJETIVO GENERAL

▪ Desarrollar un sistema de reporte en línea que apoye el

monitoreo de vehículos de transporte.

2.2 OBJETIVOS ESPECÍFICOS

Para contribuir a lograr el objetivo general se contemplan las siguientes

etapas:

▪ Presentar el estado del arte en la tecnología de los GPS y su uso

en control de flota.
▪ Crear una interfaz gráfica que permita visualizar la ubicación y
recorrido de los móviles.
▪ Crear reportes de gestión que faciliten la administración de los
móviles.
▪ Crear alertas que faciliten la administración de los móviles.

2. 3 ALCANCES Y LIMITACIONES.

ALCANCES:

Se desarrollará e implementará un sistema con interfaz gráfica que,

mediante los elementos de captura y seguimientos utilizados por la tecnología
GPS, permitirá desplegar en línea la posición de un móvil en un momento y
posición determinados, permitiendo la captura y entrega de información de
posicionamiento, tiempo de detención y consumo de combustible realizado por
el móvil para llegar desde un punto inicial a un punto determinado.

La información será entregada mediante alarmas previamente

programadas, a partir de la información de posicionamiento capturada por los
dispositivos GPS incorporados en el móvil.
 LIMITACIONES:

El sistema a desarrollar solo incorporará las funcionalidades que

permitan cumplir con los entregables descritos en la propuesta de trabajo para
la asignatura de Seminario de Integración y que básicamente posibilitan
entregar una visión de la tecnología GPS, sus potencialidades y su estado
actual de aplicación mediante el desarrollo de un sistema informático.
Capítulo 3: MARCO TEÓRICO

Con el inicio de la Era Espacial (1957) y el posterior lanzamiento del

satélite Vanguard 1 en 1959, se puso de manifiesto que la transmisión de ondas
radiales, podían servir para orientar al hombre en cualquier parte del mundo.

Los primeros sistemas de posicionamiento, empleaban estaciones de

radio AM, (amplitud modulada), que poseían una gran cobertura, aunque no
permitían determinar con precisión una posición determinada, ya que las
interferencias atmosféricas afectaban dichas señales. Otro inconveniente de las
señales AM, es la propia curvatura de la Tierra, ya que ésta tiende a desviar las
ondas. La solución para este inconveniente era colocar transmisores de radio
en el espacio y que emitieran señales de forma constante en dirección a la
Tierra. Este método disminuye la interferencia y a la vez cubre un área mucho
mayor que las AM (1).

Sin embargo, no fue hasta 1993 que el Departamento de Defensa de los

Estados Unidos, pone en funcionamiento el sistema conocido como GPS
(Global Positioning System, sistema de posicionamiento global), declarado
plenamente operacional en 1995.

En distintas épocas, hubo otros intentos por desarrollar sistemas de

posicionamiento. Uno de ellos fue GLONASS (Global Navigation Satellite
System) desarrollado por Rusia en 1976. Este sistema fue incompatible con el
sistema creado por Estados Unidos. No fue hasta el 2001 cuando la compañía
Topcon desarrolló un aparato GPS compatible con ambos sistemas (2).
 El sistema GPS vigente es el norteamericano, que en un principio fue
enfocado al desarrollo de estrategias bélicas y programado intencionalmente
con ciertos errores de cálculo, de forma que solo el Departamento de Defensa
de Estados Unidos, pudiera interpretar y corregir esos errores.

En 1998, el Departamento de Defensa de los Estados Unidos, anunció la

decisión de ampliar las capacidades del GPS añadiendo una nueva señal para
el uso civil, asegurando mejoras significativas en el posicionamiento y
navegación de los usuarios. El Departamento de Defensa, trabajó
conjuntamente con la Fuerza Aérea de Estados Unidos y con los organismos
civiles para la modernización del sistema GPS, centrándose en mejorar los
servicios, tanto para el área militar como civil (3).

(1), (2) Así funciona el GPS, Antecedentes del sistema.

(3) ADDITIONAL CIVIL CODED SIGNALS ONFUTURE GLOBAL POSITIONING SYSTEM
(GPS) SATELLITES, Departamento de Defensa de los Estados Unidos.
http://www.defense.gov/releases/release.aspx?releaseid=1623
3.1 Qué es el GPS?

El Sistema GPS (Global Positioning System) o Sistema de

posicionamiento Global es un sistema de posicionamiento terrestre que está
compuesto por tres subsistemas: los satélites, el sistema de control y los
usuarios.

El primer subsistema consiste en una red de 24 satélites artificiales

(llamados NAVSTAR), 21 satélites activos más tres de repuesto, los cuales son
propiedad del Gobierno de Estados Unidos. Estos satélites se encuentran
uniformemente distribuidos en un total de 6 órbitas (cada una en una dirección
distinta y cuyo centro es La Tierra), de forma que hay 4 satélites por órbita. Esta
configuración asegura que siempre puedan "verse" al menos 8 satélites desde
casi cualquier punto de la superficie terrestre. Los satélites GPS orbitan la
Tierra a una altitud de unos 20.000 Kms. y recorren dos órbitas completas cada
día. Describen un tipo de órbita tal que "salen" y se "ponen" dos veces al día.

Cada satélite transmite señales de radio a la Tierra con información

acerca de su posición y el momento en que se emite la señal. Esta información
se recibe con receptores GPS, que decodifican las señales enviadas por varios
satélites simultáneamente y combinan sus informaciones para calcular su
propia posición en la Tierra, es decir sus coordenadas de latitud y longitud con
una precisión de unos 10 metros. (4), (5).

(4) Universidad de Concepción, Facultad de Ingeniería 2001.

(5) Geological Survey Of IRAN (G.S.I), http://www.gsi.ir/Science/Lang_en/Page_03-07-01/Introduc-

tion.html
3.2 CARACTERÍSTICAS DEL GPS

El GPS fue creado con el objetivo de satisfacer los requerimientos de las

fuerzas militares en la determinación exacta de posición, velocidad y tiempo, en
un sistema de referencia común, en o cerca de la Tierra, para cualquier
condición climática.

El posicionamiento con GPS significa proporcionar la latitud y longitud del

punto en el que se encuentra sobre la superficie terrestre. La mayoría de los
receptores proporcionan los valores de estas coordenadas en unidades de
grados (°) y minutos ('). Tanto la latitud como la longitud son ángulos y por tanto
deben medirse con respecto a un ángulo de referencia bien definido.
Hoy en día el Sistema de Posicionamiento Global (GPS) está disponible en dos
formas básicas: SPS, iniciales de Standard Positioning Service (Servicio de
Posicionamiento Estándar), y PPS, siglas de Precise Positioning Service
(Servicio de Posicionamiento Preciso).

El SPS proporciona la posición absoluta de los puntos con una precisión

de 100 m. El código PPS permite obtener precisiones superiores a los 20 m.;
este código es accesible sólo a los militares de Estados Unidos y sus aliados,
salvo en situaciones especiales(6).

Las técnicas de mejora, como el GPS diferencial (DGPS), permiten a los

usuarios alcanzar hasta 3 m de precisión.

(6) Enciclopedia Microsoft Encarta

3.3 DETALLES TÉCNICOS DEL FUNCIONAMIENTO DEL GPS.

El funcionamiento del sistema GPS se puede describir en cinco pasos

fundamentales:

3.3.1 Paso 1: Triangulación desde los satélites.

La idea general detrás del GPS es utilizar los satélites en el espacio

como puntos de referencia para ubicaciones aquí en la tierra.

Esto se logra mediante una exacta medición de nuestra distancia hacia al

menos tres satélites, lo que nos permite triangular nuestra posición en cualquier
parte de la tierra.

La idea geométrica de esta medición consiste en: supongamos que

medimos nuestra distancia al primer satélite y resulta ser de 20.000 Kms., esto
limita nuestra posición a la superficie de una esfera que tiene como centro dicho
satélite y cuyo radio es de 20.000 Kms.

A continuación se mide la distancia a un segundo satélite y se descubre

que se está a 21.000 Kms. de éste. Esto dice que no se está solamente en la
primera esfera, correspondiente al primer satélite, sino también sobre otra
esfera que se encuentra a 21.000 Kms. del segundo satélite. En otras palabras,
se está en algún lugar de la circunferencia que resulta de la intersección de las
dos esferas.

Si ahora se mide la distancia a un tercer satélite y se descubre que está

a 23.000 Km de éste, esto limita la posición aún más a los dos puntos en los
cuales la esfera de 23.000 Kms. corta la circunferencia resultante de la
intersección de las dos primeras esferas.

Es decir, que midiendo la distancia a tres satélites se limita el

posicionamiento a solo dos puntos posibles. Para decidir cual de ellos es la
posición verdadera, se podría efectuar una nueva medición a un cuarto satélite.
Pero normalmente uno de los dos puntos posibles resulta ser muy improbable
por su ubicación demasiado lejana de la superficie terrestre y puede ser
descartado sin necesidad de mediciones posteriores. Una cuarta medición, de
todos modos es muy conveniente por otra razón que se verá más adelante.
3.3.2 Paso 2: Midiendo la distancia a los satélites.

La posición se calcula a partir de la medición de la distancia hasta por lo

menos tres satélites.

En el caso del GPS se está midiendo una señal de radio, que viaja a la
velocidad de la luz, alrededor de 300.000 Kms. por segundo. Por lo tanto el
problema es en cómo medir ese tiempo que, obviamente, es extremadamente
corto.
Suponiendo que el GPS, por un lado, y el satélite, por otro, generan una
señal auditiva en el mismo instante exacto. Se oiría dos versiones de la señal.
Una de ellas inmediatamente, la generada por el receptor GPS y la otra con
cierto atraso, la proveniente del satélite, porque tuvo que recorrer alrededor de
20.000 Kms. para llegar hasta él. Con esto se puede decir que las señales no
están sincronizadas.

Si se quisiera saber cuál es la magnitud de la demora de la señal

proveniente del satélite se puede retardar la emisión de la señal del GPS hasta
lograr la perfecta sincronización con la señal que viene del satélite. El tiempo de
retardo necesario para sincronizar ambas señales es igual al tiempo de viaje de
la señal proveniente del satélite. Suponiendo que sea de 0.06 segundos, y
conociendo este tiempo, se multiplicará por la velocidad de la luz y ya se
obtendrá la distancia hasta el satélite. La señal emitida por el GPS y por el
satélite es llamada “Código Pseudo Aleatorio”.

3.3.3 Paso 3: Control perfecto del tiempo.

La medición del tiempo de viaje de una señal es clave para el GPS, los
relojes que se usan deben ser muy exactos, dado que si se mide con un desvío
de una milésima de segundo, a la velocidad de la luz, esto se traduce en un
error de 300 Kms.

Por el lado de los satélites, el tiempo es casi perfecto porque lleva a

bordo relojes atómicos de una gran precisión, por el alto costo que implica el
uso de estos relojes atómicos, los receptores GPS, aquí en la tierra, utilizan
relojes mucho menos precisos.

Para obtener un tiempo perfecto es necesario realizar una medición

satelital adicional. Cualquier GPS decente debe ser capaz de sintonizar al
menos cuatro satélites de manera simultánea. En la práctica, casi todos los
GPS en venta actualmente, acceden a más de 6, y hasta a 12 satélites
simultáneamente.

3.3.4 Paso 4: Conocer dónde están los satélites en el espacio.

Todos ellos están flotando a unos 20.000 Kms. de altura en el espacio.

Un satélite a gran altura se mantiene estable. La altura de 20.000 Kms. es en
realidad un gran beneficio para este caso, porque algo que está a esa altura
está bien despejado de la atmósfera. Eso significa que orbitará de manera
regular. De acuerdo al Plan Maestro de GPS, la Fuerza Aérea de los EEUU
colocó cada satélite en una órbita muy precisa.

En tierra, todos los receptores de GPS tienen un almanaque programado

en sus computadoras que les informan donde está cada satélite en el espacio,
en cada momento.

Con el fin de mantener estas órbitas básicas en forma exacta, los

satélites de GPS son monitoreados de manera constante por el Departamento
de Defensa de los EEUU. Ellos utilizan radares muy precisos para controlar
constantemente la exacta altura, posición y velocidad de cada satélite. Los
errores que ellos controlan son los llamados errores de efemérides, o sea
evolución orbital de los satélites. Estos errores se generan por influencias
gravitacionales del sol y de la luna y por la presión de la radiación solar sobre
los satélites. Estos errores son generalmente muy sutiles pero si se quiere una
gran exactitud habrá que tenerlo en cuenta.

Una vez que el Departamento de Defensa ha medido la posición exacta

de un satélite, vuelve a enviar dicha información al propio satélite. De esa
manera el satélite incluye su nueva posición corregida en la información que
transmite a través de sus señales a los GPS.

Esto significa que la señal que recibe un receptor de GPS no es

solamente un código pseudo aleatorio con fines de tiempo, también tiene un
mensaje con información sobre la órbita exacta del satélite.
3.3.5 Paso 5: Corrigiendo Errores

En este paso sólo se van señalar errores que afectan la señal del GPS,
haciéndola menos precisa. Para un receptor de GPS se debe tener en cuenta
una amplia variedad de errores posibles tales como:

 En el cálculo se asume que las señales GPS viajan a la velocidad de la

luz, siendo ésta solamente constante en el vacío. Además, las señales
GPS atraviesan la ionósfera y tropósfera, el paso de las señales a través
de estas capas provoca un error en el retraso en la recepción de la señal.

 Los problemas para la señal de GPS no terminan cuando llega a la tierra,

ya que esta puede rebotar variar veces debido a obstrucciones locales
antes de ser captadas por los receptores GPS.

 Los relojes atómicos que utilizan son muy precisos, pero no son
perfectos. Pueden ocurrir minúsculas discrepancias que se transforman
en errores de medición del tiempo de viaje de las señales (6).

(6)http://www.uco.es/~bb1rofra/documentos/comofuncionagps/comofuncionagps.h tml
3.3.6 Divisiones

El Sistema de Posicionamiento Global consta de tres divisiones: espacio,

control y usuario.

La división espacio incluye los satélites y los cohetes Delta que lanzan
los satélites desde Cabo Cañaveral, en Florida, Estados Unidos.

La división control incluye la estación de control principal en la base de

las Fuerzas Aéreas Falcon, en Colorado Springs, Estados Unidos, y las
estaciones de observación situadas en Falcon AFB, Hawai, en la isla de
Ascensión en el Atlántico, en Diego García en el océano Índico, y en la isla
Kwajalein en el Pacífico sur. La división usuario está constituida por receptores
GPS de navegación tanto de uso civil como militar.

Fig. 1 Posiciones Espacio, Control y Usuario

3.4 SEGMENTOS Y COMPONENTES DEL SISTEMA GPS

El fundamento del sistema GPS consiste en la recepción de entre cuatro

y ocho señales de radio de otros tantos satélites de los cuales se conoce de
forma muy exacta su posición orbital con respecto a la tierra; a la vez, se
conoce muy bien el tiempo que han tardado las señales en recorrer el camino
entre el satélite y el receptor.

Conociendo la posición de los satélites, la velocidad de propagación de

sus señales y el tiempo empleado en recorrer el camino hasta el usuario, por
trilateración se puede establecer la posición en términos absolutos del receptor.

Elementos que forman el Sistema del GPS:

 Segmento Espacial.

 Segmento de control

 Segmento del usuario.

3.4.1 SEGMENTO ESPACIAL

El Segmento Espacial está constituido por los satélites que soportan el

sistema y las señales de radio que emiten. Estos satélites conforman la llamada
constelación NAVSTAR (Navigation Satellite Timing and Ranging), constituida
por 24 satélites operativos más cuatro de reserva, mantenidos por la fuerza
aérea estadounidense.

No hay que olvidar, que el origen de este sistema es militar y su

financiación corre íntegramente a cargo del gobierno de los Estados Unidos.

Los 24 satélites y sus 4 de reserva de la constelación NAVSTAR,

circundan la tierra en órbitas a una altura alrededor de los 20.200 Kms. de la
superficie y distribuidos de tal manera que en cada punto de la superficie
terrestre se tiene posibilidad de leer la señal de al menos cuatro satélites. Esto
es muy importante, porque se necesitan al menos cuatro satélites para conocer
la posición del observador, y que estos se dispongan con un ángulo de
elevación sobre el horizonte superior a 15°; no obstante, casi siempre son más
de cuatro los satélites 'visibles'.
3.4.2 Segmento de control

El segmento de control son todas las infraestructuras en tierra necesarias

para el control de la constelación de satélites.

Dichas infraestructuras tienen coordenadas terrestres de muy alta

precisión y consisten en cinco grupos de instalaciones repartidas por todo el
planeta, para tener un control homogéneo de toda la constelación de satélites

Fig. 2 Segmento de Control

Estas infraestructuras realizan un seguimiento continuo de los satélites

que pasan por su región del cielo, acumulando los datos necesarios para el
cálculo preciso de sus órbitas. Dichas órbitas son muy predecibles, dado que no
existe fricción atmosférica en el entorno donde se mueven los satélites; a las
predicciones de las órbitas de los satélites para el futuro se les conoce con el
nombre de almanaques, cuyo cálculo depende también del segmento de
control.
3.4.3 Segmento de Usuario

El segmento del usuario está constituido por el hardware (equipos de

recepción) y el software que se utilizan para captar y procesar las señales de
los satélites. Se puede utilizar en diversos tipos de actividades relacionados
con la vigilancia. Entre ellas podríamos citar:

- La detección de la dilatación de magma de un volcán,

- La observación de los movimientos de un iceberg.

Determinar las vibraciones terrestres, fin, cualquier fenómeno natural o

creado por el hombre que presente algún movimiento, por más imperceptible
que parezca.

Los datos generados por el GPS también pueden ser utilizados para
estudiar fenómenos que ocurren en otros mundos. Los investigadores Andrew
Johnston y James Zimbelman precisaron los flujos de lava que suceden en
Carrizozo, en el campo de prueba de misiles de White Sands, cerca de
Alamogordo y en McCartys, al sur de Grants, los cuales se extienden hasta 50
kilómetros.

Asimismo, el GPS puede servir para comprender mejor los cambios

físicos que ocurren en nuestro planeta. Por ejemplo, los movimientos en las
profundas aguas de los océanos, el monitoreo de el estatus de la actividad
volcánica en ciertas regiones.

Algunos es la detección de los movimientos bajo la tierra también Los

investigadores del Instituto de Mediciones Geográficas de Japón han recogido
una serie de datos con Geonet, una red de más de mil sensores GPS que cubre
las zonas rurales del país, para con esto tratar de predecir el comportamiento
de las capas subterráneas y por ende predecir cuando un sismo sucederá.

Es empleado en la navegación marítima, terrestre y aérea. También

empieza a surgir en las calles, donde los autos tienen integrado sistemas de
GPS y con esto es prácticamente imposible perderse.
3.5 TIPOS PRINCIPALES DE EQUIPOS GPS

Hoy en día se encuentra una gran variedad de tipos de GPS, por las
diversas funcionalidades que tiene y sus formas.

Además, dicha clasificación puede realizarse por múltiples criterios, como

por ejemplo en función de la arquitectura (receptores secuenciales, continuos o
multiplex), en función del método de funcionamiento (correlación de código o
análisis de fase de la portadora), o en función de las aplicaciones a las que se
destine.

3.6 VENTAJAS Y DESVENTAJAS DE SU UTILIZACIÓN.

3.6.1 VENTAJAS

- El GPS es un sistema que entrega información acerca de posición en la

tierra mediante altitud y longitud en forma fácil y rápida, con una
precisión casi exacta y cobertura mundial las 24 horas del día incluso en
condiciones meteorológicas muy adversas.
- Entregan información de posicionamiento 100% fiable.
- Estos dispositivos GPS son de fácil instalación sobre el parabrisas o
tablero de instrumentos, con un soporte que facilita la correcta
visualización.
- Facilidad de su uso, ya que permite introducir destinos y rutas de forma
mucho más cómoda y precisa que con los sistemas tradicionales (mapas
de carreteras).
- La portabilidad que tiene el GPS de poder adecuarse a toda instalación.
- Actualización constante de la información cartográfica.
- Efectividad en el cálculo de la ruta y la legibilidad de la información.

Los datos otorgados por los satélites son de mucha utilidad para el
hombre, ya que además de entregar información de fiabilidad relativa acerca de
nuestra posición y altitud, nos otorga datos que son muy útiles para prever los
cambios atmosféricos y las condiciones ambientales y climáticas del lugar que
deseemos tener información.

Todos los GPS's incorporan funciones de navegación realmente

sofisticadas que harán cambiar todo concepto de la orientación conocida. Por
ejemplo, se puede elaborar rutas sobre mapas, registrando en el dispositivo los
puntos por los que se quiere, o se debe pasar. Sobre el terreno, activando esa
ruta, una pantalla gráfica nos indicará si se está sobre el rumbo correcto o se
está desviando en alguna dirección; también se puede utilizar la misma función
en rutas reversibles, es decir, ir registrando puntos por lo que se va a pasar
para luego poder volver por esos mismos puntos con seguridad. Además se
puede deducir la velocidad a la que se desplaza con exactitud, mientras se
mantiene el rumbo en línea recta, o deducir la velocidad a la que se va
desplazando si se registra todos los puntos de cambio de rumbo y un largo etc.

3.6.2 DESVENTAJAS.

Este espectacular sistema de posicionamiento, como todas las cosas,

también posee errores, unos propios del sistema y otros intencionales, que son
la principal fuente unitaria de error del sistema. No todos los aparatos GPS
portátiles tienen suficiente memoria como para guardar rutas diarias y viajes
pre-planificados.

La señal del satélite pasa a través de la atmósfera, encontrándose con la

tropósfera y la ionósfera, las que afectan la onda produciendo un cambio de
velocidad o retraso conocido con el nombre de refracción.
3.6.2.1 Errores Intencionales.

Esta fuente de error se realiza con fines netamente estratégicos. El

Gobierno de Estados Unidos decidió que debía incorporar distintos grados de
error en las mediciones obtenidas por los receptores, por motivos de seguridad.

Este gobierno gastó 12.000 Millones de dólares para desarrollar el

sistema de navegación más exacto del mundo, sin embargo, ahora está
degradando intencionalmente su exactitud; esta política se denomina
"Disponibilidad Selectiva" y pretende asegurar que ninguna fuerza hostil o grupo
terrorista pueda utilizar el GPS para fabricar armas certeras y atentar contra la
seguridad de los civiles. Los receptores de uso militar utilizan una clave para
eliminar la Disponibilidad Selectiva y son, por ello, mucho más exactos.

Lo que se hace básicamente es que el Departamento de Defensa

introduce cierto "ruido" en los datos del reloj satelital, lo que a su vez se traduce
en errores en los cálculos de posición. Otra forma es que el Departamento de
Defensa envía datos orbitales ligeramente erróneos a los satélites, que estos
reenvían (transmitiendo el error) a los receptores GPS como parte de la señal
que emiten.

3.6.2.2 Errores propios del sistema.

Los efectos asociados al satélite y su posición contribuyen a alterar la

medición de distancia. El mensaje de transmisión está dado por la posición
instantánea del satélite y sus valores son predeterminados por las estaciones
de control tierra. De este mensaje, llamado efemérides, se puede deducir dos
tipos de error:

• Es imposible determinar con total exactitud la posición del satélite porque

las órbitas de éstos están influenciadas por la atracción gravitacional, la
que a su vez no ejerce una fuerza constante sobre dichos cuerpos.

• La medición del tiempo es fundamental en la medición de la distancia

desde el satélite al Geo receptor; aunque los relojes utilizados son de
alta calidad, no son totalmente perfectos.

Otro error se introduce cuando la señal del satélite pasa a través de la

atmósfera, encontrándose con la tropósfera y la ionósfera, las que afectan la
onda produciendo un cambio de velocidad o retraso conocido con el nombre de
refracción.

La geometría de los satélites también podría afectar la medición, este

factor se conoce con el nombre de Dilución de la Precisión. La calidad de la
medición dependerá de la disposición de los satélites, si éstos están
extremadamente juntos la medición será poco confiable, en cambio, cuando se
encuentran bastante dispersos respecto al valor de la antena, esta será una
buena medición. Es por esto que si dos receptores están muy juntos el uno del
otro, unos pocos cientos de kilómetros, la señal que alcanza a ambos viajará
prácticamente a través del mismo pasillo de atmósfera y por ello tendrán los
mismos errores.

Afortunadamente todos estos errores no suman demasiado error total.

Existe una forma de GPS, denominada GPS Diferencial o DGPS, que reduce
significativamente estos problemas.

Las empresas que ofrecen el servicio de GPS, deben contar con dos
elementos indispensables:

 Un medio de transmisión por el cual se pueda transmitir en tiempo real o

diferido, los datos desde el vehículo a la estación base.

 Una plataforma software que interprete y analice los datos recogidos

para desplegarlos en distintos formatos para los clientes.

El medio utilizado para transmitir la información recolectada es la red de

telefonía móvil. No es posible brindar el servicio de seguimiento de vehículos,
sin contar con el servicio de transmisión de datos que otorgan las propias
empresas móviles. Existen 3 grandes operadores de telefonía móvil en nuestro
país:

 Movistar
 Claro
 ENTEL PCS.

Estas Empresas proveen de servicio de voz, no necesariamente implica

entregar servicio de transmisión de datos. En la práctica, las empresas que dan
el servicio de posicionamiento global, deben recurrir a las empresas de telefonía
móvil que también proporcionan el servicio de transmisión de datos.
3.7 MERCADO NACIONAL.

Las principales empresas proveedoras del servicio GPS en Chile, son:

Empresa Participación de mercado

GPS Chile 27%
ENTEL PCS 20%
PointPay 16%
MóvilMaster 13%
Wisetrack 13%
Control óptimo 4%
Sitrack 3%
Internet 3%
Fuente: Depto. Marketing MóvilMaster S.A.

Como en todos los mercados, el servicio de GPS ha tenido entradas y

salidas de empresas, como por ejemplo en el 2004 la empresa Rutacert salió
del mercado y PointPay Chile entró de forma exitosa, ya que en menos de un
año alcanzó el 16% de participación del mercado
3.8 COSTOS DEL SERVICIO.

3.8.1 Costo de contrato del servicio de GPS

El precio que se cobrará al cliente depende de los servicios contratados,

la cantidad de móviles a incorporar, la extensión del contrato, si el cliente
compra el dispositivo GPS o lo toma en comodato. Los contratos típicos son en
comodato con plazos de 12, 24 y 36 meses.

Cuando el cliente compra el GPS generalmente se genera un contrato a

12 meses o un contrato abierto sin cláusulas de salida o con un aviso de 90
días. El modo de cobrar en comodato es un valor por la instalación, su valor es
de 2 UF + IVA y un servicio mensual que oscila entre las 0,8 y 1,1 UF + IVA por
móvil/mes.

Si el cliente compra el equipo los valores pueden bajar a 0,65UF + IVA

móvil/mes.

3.8.2 Equipos utilizados en el mercado nacional

Las marcas de equipos GPS más utilizadas en el mercado nacional son:

Virloc, Sky Patrol, Amphora, Antares, Webtech, MT, Portman.
3.9 Metodología Empleada
Para el desarrollo del sistema se ha determinado utilizar la metodología
XP, cuyas principales características se detallan a continuación:

3.9.1 Metodología XP o Programación Extrema

XP es un acrónimo del inglés Extreme Programming o Programación

Extrema que es su traducción al español. Fue creada por el estadounidense
Kent Beck a mediados de la década de los 90's y se trata de una disciplina que
extrae diversas prácticas de otras metodologías existentes con el fin de resolver
problemas comunes y presentes en el desarrollo de software que causan
generalmente el incumplimiento de plazos de los proyectos, entrega de
productos y la calidad de los mismos.

Se encuentra en discusión si XP es una metodología ágil de desarrollo

dentro de la ingeniería de software, o bien una disciplina o modelo de proceso
de programación, ya que no solo muestra los pasos a seguir en el desarrollo de
software, sino que especifica la dinámica entre los actores y la operatividad del
desarrollo del proyecto [BIB.XP1]. Sin embargo su popularidad ha ganado
terreno por proponer un método ágil, adaptable y flexible a diferencia de las
metodologías tradicionales.

Una de las características principales de este método es que plantea una

forma liviana y adaptable del proceso de desarrollo [BIB.XP2]. Los autores de
XP han seleccionado aquellos que han considerado mejores y han profundizado
en sus relaciones y en cómo se refuerzan los unos con los otros. El resultado
de esta selección ha sido esta metodología única y compacta. Por esto, aunque
no está basada en principios nuevos, sí que el resultado es una nueva manera
de ver el desarrollo de software [BIB.XP3].

La competitiva industria del desarrollo en las últimas décadas ha forzado

la evolución de los modelos tradicionales de desarrollo de software, sobre todo
ante un mundo de negocios tan exigente donde los requerimientos pueden
variar de acuerdo a las condiciones del negocio que un usuario final pueda
manejar en el tiempo. Los métodos tradicionales no siempre tendrán que
cumplir con los plazos que un cliente necesita, y no siempre los resultados
finales de un producto terminado cubrirán las necesidades de un cliente, si las
estrategias del negocio han cambiado y con ello los requerimientos. Resultado
de esto, han surgido métodos y disciplinas nuevas que se ajustan a tales
exigencias sin desaprovechar el trabajo ni menos los ánimos de todo equipo de
desarrollo, cumpliendo así con las necesidades de un cliente cada vez más
exigente y un mercado cada vez más dinámico.

El enfoque que ha tenido las metodologías tradicionales en la ingeniería

de software por años ha servido para el desarrollo de sistemas de alta
envergadura y criticidad, sin embargo con la masificación de los computadores
personales en el hogar y en la pequeña y mediana empresa, los costos de
desarrollo no avalan proyectos de negocios donde las necesidades y las
estrategias cambian según se mueve el mercado en el tiempo, por lo que los
costos obligan a un cambio de enfoque para transformar y emplear innovadores
métodos de trabajo en favor de optimizar los costos en función del tiempo.
[Fig 3].

Fig. 3 Diferencias de Enfoques [BIB.XP4]

Los métodos ágiles evolucionaron de la mano con los modelos iterativos,

y éstos tienen la finalidad de construir un producto por etapas, siendo cada
etapa un conjunto de actividades previamente planificadas para la elaboración
coordinada e incremental del producto que se desea entregar. XP está basado
en la iteración o repetición continua de procesos durante la realización del
desarrollo de un proyecto de software, dándole movilidad y adaptabilidad a
pesar de la disciplina con la que se lleva a cabo. Según sus autores, la misión
que fundamenta a XP detalla que:
“El objetivo que se perseguía en el momento de crear esta metodología era la
búsqueda de un método que hiciera que los desarrollos fueran más sencillos.
Aplicando el sentido común.” [BIB.XP3]

Los métodos ágiles nacieron ante la necesidad de resolver problemas

comunes dentro de todo proyecto de desarrollo, principalmente [BIB.XP2]:

1. Cuando el cliente no tiene claro aún los requerimientos del producto que
necesitan y los van cambiando continuamente.
2. Cuando se trata de un proyecto de alto riesgo: fecha fija de entrega, un
producto de software nunca antes hecho por un equipo de desarrollo o la
comunidad de desarrolladores.
3. Cuando se cuenta con un reducido equipo experimentado de desarrollo,
entre dos y no más de diez programadores.
4. Cuando existe una alta tasa de rotación o renovación dentro del equipo
de desarrollo.
5. Cuando los cambios de requerimientos vienen en función de cambios en
la estrategia del negocio.
6. Cuando hay proyectos donde se debe hacer continuidad o
mantenimiento y la arquitectura del sistema y sus partes son complejas o
confusas.
7. Cuando el objetivo es entregar el software tal cual se necesita y en el
momento que se necesita.

Los principios de la programación extrema, al igual que el común de los

métodos ágiles, es que el proyecto de software vaya evolucionando a la par
con las necesidades del cliente, y en esto el cliente debe ejercer un rol
importante en la vida del mismo. El cliente o usuario final debe ser integrante
del equipo de desarrollo y jugar un papel de árbitro y guía en las
especificaciones y requerimientos dentro de cada línea base en la vida del
proyecto. Los principios básicos de esta metodología se resumen en lo
siguiente [BIB.XP6]:

• Participación del cliente: Los clientes deben está fuertemente implicados

en todo el proceso de desarrollo. Su papel es proporcionar y priorizar
nuevos requerimientos del sistema y evaluar iteraciones del sistema.
• Entrega incremental: El software se desarrolla en incrementos, donde el
cliente especifica los requerimientos a incluir en cada incremento.
• Personas, no procesos: Se deben reconocer y explotar las habilidades
del equipo de desarrollo. Se les debe dejar desarrollar sus propias
formas de trabajar, sin procesos formales a los miembros del equipo.
 • Aceptar el cambio: Se debe contar con que los requerimientos del
sistema cambian, por lo que el sistema se diseña para dar cabida a esos
cambios.
• Mantener la simplicidad: Se deben centrar en la simplicidad tanto del
software a desarrollar como en el proceso de desarrollo. Donde sea
posible, se trabaja activamente para eliminar la complejidad del sistema.

Esta metodología podría funcionar siempre y cuando se cumpla las siguientes

condiciones [BIB.XP7]:

• El cliente o usuario final disponga del tiempo necesario para participar en

el proyecto y dar soporte al equipo de desarrollo en el momento
oportuno.
• Exista una férrea comunicación y predisposición al trabajo conjunto en el
equipo de desarrollo.
• Exista un ordenado flujo de comunicación entre cliente, jefe de proyecto
y equipo de desarrollo.
• El equipo de desarrollo sea tolerante a la revisión y cambio de la
programación realizada por otro programador sobre del código fuente
propio.
• El equipo de desarrollo sea abierto y tolerante a los cambios frecuentes
de los requerimientos o del diseño del sistema a desarrollar.
• No exista una tendencia al sobre tiempo (horas extra), en el horario de
trabajo del equipo de trabajo. XP sugiere no más de 40 horas a la
semana.
• Equipo de desarrollo acotado, cantidad no es calidad, XP sugiere un
rango no inferior a 2 y no superior a 10 programadores.
• El sistema a desarrollar no sea a gran escala o que interactúen con
complejos sistemas o infraestructuras hardware/software.
• Donde no participen diversos equipos de desarrollo dispersos
geográficamente.

Una de las cosas que los programadores deben tener en cuenta es que
los cambios siempre estarán presentes en el ciclo de vida de un
proyecto, cambiarán los requisitos, las reglas del negocio, el personal, la
tecnología, etc. Por lo tanto el problema no estará en el cambio en sí,
sino en la manera en que se deberán enfrentar esos cambios. Como en
cualquier otra actividad humana necesitamos valores para desarrollar
nuestro trabajo y conseguir los planteamientos iniciales.
 Bajo estos principios y condiciones se han definido un grupo de valores
que deben asumir todos aquellos que practican y participan esta
disciplina [BIB.XP10]:

• Comunicación: La comunicación prevalece en todas las prácticas de

XP, y éste fomenta la comunicación. Comunicación cara a cara es la
mejor manera para resolver confusiones y malos entendidos, para
transmitir ideas, conocimientos, dudas y soluciones entre miembros del
equipo. Gracias a la comunicación entre los desarrolladores y el cliente o
el jefe de proyecto, se pueden realizar cambios que el cliente requiere o
no le gustaron, también apoya la extensión del conocimiento tácito dentro
del equipo de desarrollo, evitando la necesidad de mantener la
documentación escrita.

• Sencillez: Ayuda a los desarrolladores a encontrar soluciones más

simples a los problemas, también los ayuda a crear características en el
diseño que puedan ayudar a resolver problemas a futuro. La sencillez en
el código también ayuda a la comunicación y a la documentación,
mientras más sencillo sea el código, menos necesidad se tendrá de
explicar y comunicar de él.

• Retroalimentación: La retroalimentación continua del cliente permite a

los desarrolladores llevar y dirigir el proyecto en una dirección correcta
hacia donde el cliente quiera. La retroalimentación actúa junto con la
sencillez y la comunicación, cuanto mayor retroalimentación más fácil es
la comunicación. Cuanto más simple un sistema más fácil de probar.
Escribir pruebas nos orienta como simplificar un sistema, hasta que las
pruebas funcionen, cuando las pruebas funcionen tendrá mucho avance
echo.

• Valentía: Asumir retos, ser valientes antes los problemas y afrontarlos. Si

el código es engorroso, no se debe terminar odiándolo y odiando al
sistema, esto trae como consecuencia, una entropía positiva. El valor o
coraje requiere que los desarrolladores vayan a la par con el cambio,
porque se debe tener conciencia que este cambio es inevitable, pero el
estar preparado con una metodología ayuda a ese cambio. La valentía
se extiende también para los gerentes o empresarios que financian estos
proyectos, puesto que si una de las prácticas es la del trabajo en parejas,
puede darse a entender que la empresa está pagando a dos por el
trabajo de uno, pero sin embargo lo que se gana es en calidad y tiempo
ahorrado de correcciones y mantenimiento en la aplicación que suele ser
 programado y revisado por una persona y no por dos.

Tal como se puede representar en la figura 4, la programación

extrema propone una serie de prácticas que los integrantes del equipo
deberán adoptar, estos se agrupan en cuatro categorías, los cuales
determina el funcionamiento específico que se debe emplear al momento
de programar [BIB.XP8]:

Fig. 4 Esquema Conceptual Metodología XP [BIB.XP5]

1.- Retroalimentación a escala fina

• El principio de pruebas: se tiene que establecer un período de pruebas

de aceptación del programa (llamado también período de caja negra)
donde se definirán las entradas al sistema y los resultados esperados de
estas entradas.
• Proceso de planificación: en esta fase, el usuario tendrá que escribir
 sus necesidades, definiendo las actividades que realizará el sistema. Se
creará un documento llamado Historias del Usuario (User Stories).

• El cliente en el sitio: se le dará poder para determinar los

requerimientos, definir la funcionalidad, señalar las prioridades y
responder las preguntas de los programadores.

• Programación en parejas: uno de los principios más radicales y en el

que la mayoría de gerentes de desarrollo pone sus dudas. Requiere que
todos los programadores XP escriban su código en parejas,
compartiendo una sola máquina.

2.- Proceso continuo

1. Integración continua: permite al equipo hacer un rápido progreso

implementando las nuevas características del software.

2. Refactorización: permite a los equipos de programadores XP mejorar el

diseño del sistema a través de todo el proceso de desarrollo.

3. Entregas pequeñas: colocan un sistema sencillo en producción

rápidamente que se actualiza de forma rápida y constante permitiendo
que el verdadero valor de negocio del producto sea evaluado en un
ambiente real.

3.- Entendimiento compartido

• Diseño simple: se basa en la filosofía de que el mayor valor de negocio

es entregado por el programa más sencillo que cumpla los
requerimientos. Simple Design se enfoca en proporcionar un sistema que
cubra las necesidades inmediatas del cliente, ni más ni menos.

• Metáfora: desarrollada por los programadores al inicio del proyecto,

define una historia de cómo funciona el sistema completo.

• Propiedad colectiva del código: un código con propiedad compartida.

Nadie es el propietario de nada, todos son el propietario de todo.

• Estándar de codificación: define la propiedad del código compartido así

como las reglas para escribir y documentar el código y la comunicación
entre diferentes piezas de código desarrolladas por diferentes equipos.
4.- Bienestar del programador

La semana de 40 horas: la programación extrema sostiene que los

programadores cansados escriben código de menor calidad.

De acuerdo a estas prácticas, el equipo de desarrollo que adopte XP, sus

actividades se centrarán principalmente en estas cuatro:

• Codificar: Es necesario codificar y plasmar las ideas a través del código.

En programación, el código expresa la interpretación del problema, así
se puede utilizar el código para comunicar, para hacer comunes las
ideas, y por tanto para aprender y mejorar.

• Hacer pruebas: Las pruebas dan la oportunidad de saber si lo

implementado es lo que en realidad se tenía en mente. También son
indicativos de que el trabajo funciona, cuando no se pueda pensar en
cualquier prueba que pudiese originar un fallo en el sistema, entonces el
mismo estará realizado por completo.

• Escuchar: Según una afirmación frecuente entre el personal: "Los

programadores no lo conocemos todo, y sobre todo muchas cosas que
las personas de negocios piensan que son interesantes. Si ellos pudieran
programarse su propio software ¿para qué nos querrían?". Es importante
escuchar a los clientes acerca de cuáles son los problemas de su
negocio de una manera activa, explicando lo que es posible de obtener y
lo que no es posible de obtener, para que esta realimentación entre
ambos ayuden a entender los problemas de una forma objetiva.

• Diseñar: El diseño crea una estructura que organiza la lógica del

sistema, un buen diseño permite que el sistema crezca con cambios en
un solo lugar. Los diseños deben de ser sencillos, si alguna parte del
sistema es de desarrollo complejo, lo apropiado es dividirla en varias. Si
hay fallos en el diseño o malos diseños, estos deben de ser corregidos
cuanto antes.

En resumen, según las actividades que propone XP, se deduce que es

necesario codificar porque sin código no hay programas, Se deben hacer
pruebas por que sin pruebas no se sabe si se ha acabado de codificar,
tenemos que escuchar, porque si no se escucha no se sabe que codificar
 ni probar, y por último hay que diseñar para poder codificar, probar y
escuchar indefinidamente.

La decisión de adoptar una metodología u otra para la puesta en marcha

de un proyecto de software es un paso importante que debe asumir tanto
el jefe de proyecto como el cliente y que debe ser analizado
detenidamente. XP aclara que todo proyecto de desarrollo debe
considerar cuatro variables esenciales. También establece que de estas
cuatro variables, solo tres de ellas podrán ser fijadas o indicadas por el
cliente o jefe de proyecto, mientras que una variable quedará libre
[BIB.XP9]:

• Costo: Del proyecto se incrementa cuando se necesita máquinas más

rápidas, mas especialistas técnicos en determinadas áreas o mejores
oficinas para el equipo de desarrollo.
En XP el costo del cambio maneja un papel muy importante, porque
comparado con otras metodologías para implementar software, es
mucho más barato, debido a que las pruebas se van haciendo según las
versiones liberadas, no es como una metodología normal, en que
primero se realiza el análisis, después el diseño, implementación,
pruebas y finalmente producción, mientras que en la XP siempre se está
implementando, probando y produciendo.

• Tiempo: En el que se planifica y en el que realmente se lleva a cabo el

proyecto. Debe tomare en cuenta que los cambios aumentarán el tiempo
de realización mientras que la optimización y la inversión pueden
acortarlo.

• Calidad: Puede representar un cambio extraño; debido a que a mayor

calidad menor tiempo de realización del proyecto. Por lo tanto el equipo
de desarrolladores está encargado de la tarea de hacer las pruebas con
los mejores resultados posibles para así tener una idea de cuál es el
problema y como lo van a resolver de una manera simple y eficiente,
para que la calidad del proyecto se mantenga al 100% y tener una
facilidad de adaptarse a los cambios del código lo que hace este proceso
más rápido.

• Ámbito: Es la que se encuentra libre es el alcance del proyecto, en la

cual el equipo determina: la estimación de las tareas a realizar, que es lo
que el cliente quiere, la implementación de los requisitos más
importantes de manera que este siempre sea funcional.
Todas las metodologías tienen limitantes y los métodos ágiles no son la
excepción, éstos son apropiados para algunos tipos de desarrollo de
sistemas. Son más idóneos para sistemas de negocios pequeños y de
tamaño medio, como también para el desarrollo de productos de
software para computadores personales. No son adecuados para
sistemas complejos a gran escala, donde puedan participar otros equipos
externos de desarrollo y tenga que adaptarse a complejas iteraciones de
otros proyectos o interactuar con complejos sistemas software/hardware.
Tampoco es viable utilizarlo para proyectos críticos, donde es necesario
un análisis detallado de todos los requerimientos del sistema para
comprender sus implicaciones de seguridad o protección.
3.9.2 Uso práctico de la metodología XP en el Proyecto.

Todo proyecto guarda incertidumbres en su desarrollo y evolución, y no

está exento de problemas. Depende mucho de la conformación de un equipo de
trabajo y su disposición de seguir una disciplina estricta y puntual. Incluso si los
programadores más experimentados y disciplinados están dispuestos a
someterse a una disciplina impuesta por una metodología, siempre existen los
riesgos que esta no rinda los frutos esperados o simplemente no funcione.

El trabajar en equipo, es tan difícil como predecir el futuro de una familia.

En un equipo de trabajo existen personas, y las personas poseen distintos
puntos de vista, distintas formas de pensar, de planificar y decidir. No es
necesario aplicar un juicio de valores sobre las personas ni sobre la calidad de
trabajo individual, los jefes de proyectos podrían tener una visión tan clara sobre
su equipo, como para saber de antemano si una tarea es apropiada o no para
un programador u otro. Pero aún así un jefe de proyecto podría no ser asertivo
en elegir una metodología u otra, o de seleccionar un programador para su
equipo.

La clave está en no aplicar de una manera estricta una metodología

sobre un grupo que recién comienza a conformarse y cuya adaptación puede
tomar un tiempo arriesgado para cualquier proyecto, sino que más bien, adaptar
una metodología a un orden que recién comienza a funcionar dentro de un
grupo.

El trabajo en parejas, quizás sea una de las tareas más difíciles de

conseguir dentro de un grupo de trabajo, pocos programadores pueden estar
abiertos a compartir su trabajo y estar sometidos a opiniones y críticas sobre su
forma individual de trabajar, y es precisamente porque cada programador es un
individuo que razona y actúa de manera individual. Para consolidar una
dualidad dentro de un equipo de trabajo en parejas es necesario que exista una
afinidad y sinergia de manera que dos piensen mejor que uno, en lugar que uno
intente pensar mejor que el otro, y que al final termine la competencia en que
uno termine más rápido una versión del trabajo antes que el otro.

Otro problema que se puede dar con frecuencia es la disponibilidad de

recursos en el tiempo requerido. Es muy común, si se trabaja con un grupo
disperso de personas, sea difícil consolidar un equipo de desarrollo, donde el
trabajar reunidos en forma presencial sea también requerido. Sin embargo, si se
puede realizar sutiles cambios a una metodología, donde el trabajar reunidos en
forma presencial, pueda realizarse de manera virtual, es más valiosa la
contribución de esta adaptación para el éxito de un proyecto.

Una solución viable para esta problemática es la de compartir los

programas fuentes por medio de un repositorio de código fuente común con
control de versiones, donde este repositorio pueda ser accedido de manera
segura desde cualquier lugar y en cualquier momento por los integrantes del
equipo de desarrollo. De esta manera, los cambios realizados por uno u otro
programador, puedan ser vistos y replicados. Esto garantiza que el trabajo en
parejas puede darse en forma remota y virtual, dado que ambos pueden ver el
mismo código fuente, y ambos pueden trabajar en forma colaborativa sin perder
el control sobre las versiones de los fuentes.

Implementar un sistema de control de versiones no es complejo, dado un

sin número de aplicaciones y sistemas que lo permiten. Sin embargo, para
aquellos equipos de desarrollo que no dispongan de recursos para montar un
servicio como este, pueden optar por servicios gratuitos y de confianza que
llevan suficiente tiempo en la red Internet, como es el caso de Google Code,
que es el que se aplica sobre el presente proyecto.
3.9.3 Google Code.

Es el espacio donde Google comparte con todos los usuarios las

herramientas necesarias para que puedan administrar sus propios proyectos de
desarrollo bajo licencia libre. Esto es, el código fuente que se declara con
licencia libre, se ofrece para que cualquier desarrollador pueda utilizarlo en sus
proyectos, o incluso modificarlo respetando las normas de la licencia libre
[BIB.GC1].

El alojamiento de proyectos en Google Code es un servicio de

alojamiento de software libre rápido, fiable y sencillo que permite:

• Crear proyectos instantáneos sobre cualquier tema.

• Alojar código de Subversión con un 1 gigabyte de espacio de
almacenamiento y admitir alojamiento para descargas con 2
gigabytes de espacio de almacenamiento.
• Consultar código fuente integrado y utilizar herramientas de revisión
de código para facilitar la visualización de código, la revisión de
contribuciones y el mantenimiento de una base de código de gran
calidad.
• Realizar un seguimiento de problemas y búsquedas Wiki de
proyectos sencillas, pero flexibles y potentes, que pueden adaptarse
a cualquier proceso de desarrollo.
• Marcar como destacados y actualizar flujos que facilitan el
seguimiento de los proyectos y los desarrolladores que interesan
[BIB.GC2].
3.9.4 API de Google Maps.

Es un conjunto de clases y funciones JS , que podemos cargar en nuestras

propias páginas previo registro. Posee una extensa documentación sobre su
uso y nos permite crear aplicaciones basadas en la tecnología de Google Maps,
cuyo único límite es nuestra imaginación y talento para programar.

Características

Google Maps ofrece la capacidad de hacer acercamientos o alejamientos

para mostrar el mapa. El usuario puede controlar el mapa con el mouse o las
teclas de dirección para moverse a la ubicación que desee.

Los resultados de la búsqueda pueden ser restringidos a una zona,

gracias a Google Local.

Como otros servicios de mapa, Google Maps permite la creación de

pasos para llegar a alguna dirección. Esto permite al usuario crear una lista
paso a paso para saber el cómo llegar a su destino.

3.9.5 Como integrar un mapa de Google Maps

Insertar un mapa en nuestro sitio Web es muy simple haciendo uso de la

API de Google Maps. Lo primero es solicitar nuestra API Key, debemos
especificar en qué URL vamos a utilizar nuestro mapa. Aunque es
recomendable solicitar una para la dirección http://localhost y con esta
hagamos los ajustes necesarios y una vez que nuestro código esté listo cambiar
la API Key por la de nuestro sitio en Internet para publicar la página.
3.10 Tecnologías Empleadas.

3.10.1 Arquitectura de la solución

Un nodo GPS en circulación, enviará periódicamente una señal que será

recibida por una antena de estación Base de telefonía celular (BTS), esta se
comunicará a través de un enlace con un Controlador de Estaciones Base
(BSC), el cual por medio de un procesador adjunto, el Nodo de Soporte del
Servicio GPRS, convertirá estos paquetes de información en paquetes TCP que
serán enviados a la red Internet.

Fig. 5 Arquitectura de la solución

Estos paquetes TCP, serán capturados por una aplicación servidora, que se
encargará de segmentarlos y almacenarlos en una base de datos, haciendo
referencia a los nodos que lo emitieron.
El sistema de supervisión de los nodos GPS, se encargará de proveer al usuario
las herramientas necesarias, para la gestión de los vehículos que las portan por
medio de una interfaz Web intuitiva y amigable.
3.10.2 TECNOLOGÍA DE DESARROLLO

– Herramienta de desarrollo: PHP 5; Java Standard Edition.

– Base de datos: MySQL.

– Servidor: Apache 2
Capítulo 4. DEFINICIÓN DEL PROYECTO
Desarrollar un sistema de reporte en línea que apoye el monitoreo
de vehículos de transporte.

4.1 ALCANCE

• Desarrollar e implementar un sistema con interfaz gráfica que, mediante los

elementos de captura y seguimientos utilizados por la tecnología GPS, que
permita desplegar en línea la posición de un móvil en un momento y posición
determinados, y capturar y entregar de información de posicionamiento,
tiempo de detención y consumo de combustible realizado por el móvil para
llegar desde un punto inicial a un punto determinado.
• Entregar la información mediante alarmas previamente programadas, a partir
de la información de posicionamiento capturada por los dispositivos GPS
incorporados en el móvil.
• Capacitar al equipo técnico en la plataforma que se utilizará para el diseño e
implementación de la solución.
• Ejecutar un plan de capacitación sobre el uso de la solución construida.
• El sistema a desarrollar solo incorporará las funcionalidades que permitan
cumplir con los entregables descritos en el capítulo 5, (producto que se
entregará), y que básicamente posibilitan entregar una visión de la
tecnología GPS, sus potencialidades y su estado actual de aplicación
mediante el desarrollo de un sistema informático.
 4.2 DETALLE DE LA SOLUCIÓN

- Diseñar una interfaz gráfica para despliegue de información de

posicionamiento del (los) móviles a monitorear.

- Diseñar los procedimientos y flujos de captura de información desde los

dispositivos receptores GPS

- Diseñar y construir una base de datos para almacenar la información

capturada

- Definir los parámetros de entrada y condiciones de monitoreo y captura

de información desde los móviles.

- Diseñar reportes de información estadística generada durante los

períodos definidos de captura y monitoreo y que interesa poder
visualizar.

- Probar el sistema construido para revisar y corregir desviaciones en el

procedimiento de captura y despliegue de información.

- Entregar sistema construido y capacitar sobre su operación y manejo al

cliente final.
4.3 ENTREGABLES.

Responsabl Criterio de
Entregable Descripción Fecha
e Aceptación
Aplicación Documento con 17-03-2010 Analista de
gráfica que la descripción de Procesos,
permita las Analista de
visualizar funcionalidades Sistemas.
la ubicación del sistema
geográfica de desarrollado
los móviles
Reportes de Documento con 18-03-2010 Analista de
gestión del la descripción de Sistemas.
control de la los informes que
flota de generará el
vehículos sistema.
Conjunto de Informes o 18-03-2010 Analista de
alertas que se avisos de estado Sistemas,
generen a generados de
partir de la acuerdo a
ubicación parámetros de
geográfica de entrada
los vehículos previamente
definidos.
Primer Informe Presentación 20-03-2010 Jefe de Debe cumplir
de avance de inicial del Proyectos, con los
la solución sistema a Analista de parámetros de
desarrollar, su Sistemas. evaluación de la
objetivo, asignatura de
funcionalidades y Seminario de
características. integración.
Segundo Presentación del 22-03-2010 Analista de Debe cumplir
Informe de estado de Sistemas, con los
avance de la avance del Analista de parámetros de
solución desarrollo del Procesos, evaluación de la
sistema. Analista QA asignatura de
Seminario de
integración.
 Responsabl Criterio de
Entregable Descripción Fecha
e Aceptación
Resultados de Documento con 08-04-2010 Analista de Pruebas
las pruebas y los resultados de Sistemas, aprobadas.
validaciones pruebas y Programador
del sistema validaciones de
realizadas a la Aplicaciones,
aplicación Analista QA.
desarrollada.
Capacitación a Planificación de 13-04-2010 Jefe de Plan de
usuarios y la Inducción y Proyecto inducción y
operadores del Capacitación de capacitación
sistema los usuarios del con fechas y
sistema plazo
acordados con
usuario final.
Informe Final Informe con el 22-04-2010 Jefe de Debe cumplir
de proyecto detalle de Proyecto, con los
sistema Analista de parámetros de
desarrollado. Sistemas, evaluación de la
Desarrollador asignatura de
, Analista QA. Seminario de
integración.
Seguimiento Reporte 29-04-2010 Jefe Proyecto No aplica.
de la estadístico sobre
Operación el uso del
sistema.
4.4 ROLES y RESPONSABILIDADES.

Tiempo
Rol Responsabilidades Requerido Responsable
(Horas)
• Gestiona administrativamente la
ejecución del proyecto.
• Realiza seguimiento a las actividades.
• Coordina y organiza reuniones con el
Jefe de
equipo de implementación, cliente y 35 Eduardo Acosta
Proyecto
usuarios finales de la solución.
• Gestiona y coordina el traspaso a
producción de la solución.

• Recolecta información relacionada al

uso del GPS y evalúa principales
marcas de equipamiento para análisis
de costos.
• Revisa, analiza, rediseña y normaliza
Analista el procedimiento de implantación del
Marjorie
de sistema. 32
Ccopa
Procesos • Recomienda cambios y/o
modificaciones al diseño del sistema,
de acuerdo a necesidades planteadas
por el usuario/cliente final.
• Documenta el sistema diseñado.
•
• Diseña la aplicación, incluyendo la
interfaz gráfica.
Analista • Documenta el diseño de la solución.
de • Crea y evalúa los resultados del plan 28 Miguel Vargas
Sistemas de pruebas de la solución.
• Realiza inducción y capacitación en el
uso de la solución a los usuarios.
 Tiempo
Rol Responsabilidades Requerido Responsable
(Horas)
• Desarrolla la aplicación de acuerdo a
detalle técnico funcional entregado
por el analista de sistemas.
Programa • Implementa las validaciones y
dor estándares de calidad que aseguren
129 Gabriel Muñoz
/Desarroll la solidez de la aplicación
ador desarrollada
• Aplica el plan de pruebas a la
solución.
• Crea manual conciso del usuario.
• Valida y sugiere modificaciones al
sistema desarrollado, con el propósito
Analista de asegurar la calidad y cumplimiento Andrés
24
QA de estándares básicos de calidad que Basáez
debe cumplir para poder
comercializarlo en el mercado.
4.5 SUPUESTOS, RIESGOS, DEPENDENCIAS, RESTRICCIONES

Supuestos: 1. La plataforma de infraestructura y software a utilizar en la

implementación son open source.
2. Se dispone de los recursos técnicos y de equipamiento
para dejar el sistema funcionando.
3. Los plazos han sido definidos ajustándose a los plazos
definidos por la asignatura de Seminario de Integración.
Riesgos: 1. Falta de disponibilidad de tiempo del usuario final para
participar en las inducciones y capacitaciones.
2. El proyecto ha sido calificado con un 25% de riesgo.
Dependencias: 1. La implementación del sistema, considera que existe y se
encuentra operativo el servicio GPS
2. La interfaz gráfica a desarrollar debe estar alineada con
el estándar gráfico del mercado de GPS.
Restricciones: 1. Los recursos asignados al trabajo tendrán
aproximadamente un 40% de dedicación al proyecto.
4.6 ESTIMACIÓN DE RECURSOS/ HORAS.

Rol Expertise/Nivel Horas

Jefe de Proyecto Profesional/Alto 35
Analista de Procesos Profesional/Medio 32
Analista de Sistemas Profesional/Medio 28
Programador de Profesional/Medio 129
Aplicaciones
Analista QA Profesional/Bajo 24
Capítulo 5: DISEÑO.

5.1 Modelamiento.

El modelo de requerimientos es un catálogo estructurado de requerimientos del

usuario final. Estos están representados como requisitos o elementos de
características.

custom Requirements Model

Requerimientos funcionales The Functional Requirements

The Requirements model is a structured catalogue of end-user package details behavioral
requirements. These are represented as either Requirement or + Historias de Usuario requirements that specify how a
Feature elements. + Caracteristicas proposed system will process
+ Interfaz de Usuario and handle information. It
The model is divided into two sub-catalogues: details the features and rules
that must be present to fully
1. The Functional requirements package contains requirements implement the functionality
and features that represent functional behavior and features that desired.
the system under development must support.

2. The Non-functional requirements package contains constraints

and performance levels the system must meet. For example
response times, transactions per second, security strength. Requerimientos no-funcionales
+ Performance
+ Scalability
+ Security
Read about Requirements + Persistence
+ Transport
Tracing element dependencies
Using the Relationship Matrix
The Non-Functional
Requirements package specifies
the various operational
parameters that define the
environment in which the
system will exist. These are
criteria which define
performance levels, scalability,
security requirements, backup,
disaster recovery and other
operational requirements.

Fig. 6 Modelo de Requerimientos

El modelo se divide en dos sub-categorías:

1. El paquete contiene los requisitos funcionales de las características que

representan el comportamiento funcional y que el sistema en desarrollo debe
promover.

2. El paquete de requisitos no funcionales contiene restricciones y niveles de

rendimiento del sistema debe cumplir. Por ejemplo los tiempos de respuesta,
las transacciones por segundo, la capacidad de seguridad.
 custom Requerimientos funcionales

Historias de Usuario
Functional Requirements describe the + Alarma de Vehiculo Detenido
features, behavior, business rules and general
functionality that the proposed system must + Alarmas de Velocidad
support. + Busqueda de Vehiculos
+ Gestor de Alarmas
+ Indicadores
+ Monitoreo General de Vehiculos
+ Reporte de velocidad maxima
+ Reporte Vehiculo Detenido
+ Reportes
+ Trazar Ruta Vehiculo

Caracteristicas
Interfaz de Usuario
+ Base de datos MySQL + Pantalla Principal
+ PHP5 + Reporte de Velocidad
+ API Google Maps + Reporte Vehiculo Detenido

Fig. 7 Requerimientos Funcionales

Los requerimientos funcionales describen las características,

comportamiento, reglas del negocio y la funcionalidad general que el sistema
propuesto debe soportar.
5.2 Historias De Usuario.

Según la metodología XP, las historias de usuario son la base para la

planificación y definición de las pautas necesarias para la construcción del
sistema propuesto. Estas son definidas por el usuario final o cliente y en ellas
se detalla el comportamiento que debe tener cada módulo o componente de la
aplicación según el punto de vista del usuario. Con estas descripciones, se
modelarán los casos de uso.

custom Historias de Usuario

Monitoreo General de
Vehiculos

Reportes Busqueda de T razar Ruta Gestor de Indicadores

Vehiculos Vehiculo Alarmas

Alarma de Alarmas de
Vehiculo Velocidad
Detenido

Reporte Vehiculo Reporte de

Detenido velocidad The Business Rules package is a catalogue of
maxima explicit business rules which are required to be
implemented within the current project. Business
Rules are typically executed during program
execution and control the processing of information
and transactions.

Fig. 8 Historias de Usuario

Alarma de Vehículo Detenido.

Esta alarma se debe disparar cuando un vehículo queda detenido por un

tiempo superior al definido por parámetros del sistema, en jornada de
transporte.
 Historia de Usuario
Número: 7 Usuario: Supervisor
Nombre Historia: Alarma de Vehículo Detenido.
Prioridad en Negocio: MEDIA Riesgo en Desarrollo: ALTA
Iteración Asignada: 2 Estimación de Esfuerzo: 4
Programador Responsable: Gabriel Muñoz

Alarma de Velocidad.

Esta alarma se deberá disparar cuando un vehículo exceda el umbral de

velocidad permitida definido por parámetros de sistema para un vehículo.

Historia de Usuario
Número: 8 Usuario: Supervisor
Nombre Historia: Alarmas de Velocidad.
Prioridad en Negocio: MEDIA Riesgo en Desarrollo: ALTA
Iteración Asignada: 2 Estimación de Esfuerzo: 4
Programador Responsable: Gabriel Muñoz

Búsqueda de Vehículos.

El supervisor accede a un menú desplegable y selecciona de un listado

del o los vehículos sobre los que deseará realizar el seguimiento.

Historia de Usuario
Número: 2 Usuario:
Nombre Historia: Búsqueda de Vehículos.
Prioridad en Negocio: ALTA Riesgo en Desarrollo: BAJA
Iteración Asignada: 1 Estimación de Esfuerzo: 3
Programador Responsable: Gabriel Muñoz
Gestor de Alarmas.
El sistema deberá correr de forma periódica un gestor que consulte los
indicadores y despliegue ventanas de alarmas cuando se vayan
presentando los eventos que disparen dichos indicadores.

Historia de Usuario
Número: 4 Usuario: Supervisor
Nombre Historia: Gestor de Alarmas.
Prioridad en Negocio: MEDIA Riesgo en Desarrollo: ALTO
Iteración Asignada: 2 Estimación de Esfuerzo: 5
Programador Responsable: Gabriel Muñoz

Indicadores.

Se debe realizar consultas periódicas sobre la base de datos y analizar la

comparación de estos datos con umbrales y parámetros definidos en el
sistema para gatillar indicadores.

Historia de Usuario
Número: 1 Usuario: Supervisor
Nombre Historia: Indicadores
Prioridad en Negocio: BAJA Riesgo en Desarrollo: ALTA
Iteración Asignada: 3 Estimación de Esfuerzo: 5
Programador Responsable: Miguel Vargas
Monitoreo General de Vehículos.
El supervisor observa en pantalla los vehículos que actualmente circulan
por el país. Debe realizar acercamientos con la herramienta de Zoom
para visualizar el detalle de los vehículos por las calles o carreteras y con
ayuda del mouse, arrastrar el mapa para recorrer las calles.

Historia de Usuario
Número: 1 Usuario:
Nombre Historia: Monitoreo General de Vehículos.
Prioridad en Negocio: ALTA Riesgo en Desarrollo: ALTA
Iteración Asignada: 1 Estimación de Esfuerzo: 5
Programador Responsable: Gabriel Muñoz

Reporte de Vehículo Detenido.

Este reporte deberá desplegar un listado de los vehículos que quedan
detenidos en horarios de trabajo, mostrando la hora y coordenadas
donde fue registrado el evento.

Historia de Usuario
Número: 5 Usuario: Supervisor
Nombre Historia: Reporte Vehículo Detenido.
Prioridad en Negocio: ALTA Riesgo en Desarrollo: MEDIA
Iteración Asignada: 2 Estimación de Esfuerzo: 3
Programador Responsable: Miguel Vargas
Reporte de velocidad máxima.
Este reporte deberá desplegar un listado de los vehículos que exceden
un umbral de velocidad definida, la hora y las coordenadas donde se
registro el evento, la distancia recorrida en el intervalo de muestreo y la
velocidad instantánea.

Historia de Usuario
Número: 6 Usuario: Supervisor
Nombre Historia: Reporte de velocidad máxima.
Prioridad en Negocio: ALTA Riesgo en Desarrollo: MEDIA
Iteración Asignada: 2 Estimación de Esfuerzo: 3
Programador Responsable: Miguel Vargas

Reportes.
El Supervisor podrá acceder a un repertorio de vínculos que hacen
referencia a los reportes en línea del sistema. Al hacer click sobre los
vínculos, se abrirá un cuadro de diálogo que exigirá una fecha a
consultar. Al proveer la fecha de argumento, se visualizará una ventana
con uno de los reportes que seleccionó.

Historia de Usuario
Número: 3 Usuario: Supervisor
Nombre Historia: Reportes.
Prioridad en Negocio: BAJA Riesgo en Desarrollo: BAJO
Iteración Asignada: 2 Estimación de Esfuerzo: 2
Programador Responsable: Miguel Vargas
5.3 Características

Características técnicas de las herramientas utilizadas en el desarrollo del

sistema.

custom Caracteristicas

Features typically describe discrete pieces API Google Maps

of functional behavior that yield a specific
result.

Base de datos
MySQL

PHP5

Fig. 9 Características

Base de datos MySQL.

La base de datos utilizada será MySQL 5.1 o en su última versión.

PHP5.
El lenguaje de programación será PHP5.

API Google Maps.

El sistema usará la API de Google Maps para el despliegue y búsqueda
de vehículos
Interfaz de Usuario.

El modelo de interfaz de usuario define las pautas para la

implementación de la representación de información que el usuario final
necesita ver y ocupar. En este modelo, se propone el inicio de una estructura
que irá evolucionando y ajustando a la necesidad del cliente.

custom Interfaz de Usuario

Pantalla Principal
The User Interface package contains high level Screen elements model
descriptions of end-user visible screens and forms Busqueda proposed user interface
which are required to support the proposed system. Vehiculos GMaps components.

Reportes

UI Controls model
various common user
interface control types
«navigate» «navigate»

Reporte de Velocidad Reporte Vehiculo Detenido

Reporte Velocidad Reporte Vehiculo Detenido

Fig. 10 Interfaz de Usuario

Pantalla Principal.
Esta interfaz representa el módulo principal por el cual el usuario
accederá a las diversas funcionalidades del sistema.

Reporte de Velocidad
Este reporte, desplegará un listado de aquellos vehículos que exceden la
velocidad máxima permitida para un vehículo dado.

Reporte Vehículo Detenido

Este reporte desplegará un listado de aquellos vehículos que quedan
detenidos en terreno durante horarios de producción.
5.4 Modelo de Casos de Uso.

El Modelo de Casos de Uso es fundamental para la planificación de un

proyecto para la metodología XP, sienta las bases para el comportamiento de
una aplicación a desarrollar según las necesidades y requerimientos del cliente.

5.4.1 Modelo de Casos de Uso - (Use Case diagram)

En estos casos de uso, se describirán los modelos de comportamiento de

la aplicación definido en los requerimientos de sistema.

uc Modelo de Casos de Uso

Caso de uso Principal Administracion Serv idor Sistema Recepcion Datos

+ Alertas + Editar Vehiculo + Conectar Servidor Socket T CP
+ Autenticar + Ingresar Vehiculo + Grabar Informacion
+ Buscar Vehiculo + Listar Vehiculos + Iniciar Cliente Datos
+ Desplegar Ubicación + Respaldar Datos + Recibir Datos GPS
+ Obtener Reporte + Transformar Datos

Serv idor Sistema Alerta

+ Enviar Alertas y Registro

+ Recibir Datos
+ Registrar Datos
+ T ransformar Datos
+ Verificar Alertas

Actores
Configurar Alerta + GPS
Alerta Velocidad Alerta Horas
+ Autentificar + Administrador
+ AccederSistema Alertas + Acceder Sistema Alertas + Gestionar Alertas + Base Datos
+ Desplegar via Web + Desplegar via Web + Mostrar Alertas + Supervisor
+ Generar Alerta + Generar Alerta + Seleccionar Vehiculo + Usuario

Fig. 11 Modelo de Casos de Uso

5.4.2 Actores - (Use Case diagram).

Aquí se describirán los distintos actores del sistema, las

responsabilidades que competen a cada perfil de usuario o de entidad que
interactúa con el sistema.
uc Actores

Usuario

GPS Base Datos

Superv isor Administrador

Fig. 12 Actores

Administrador.

Usuario responsable de la configuración de los vehículos, patrones y

parámetros del sistema.

Base Datos.

Actor intrínseco del sistema, encargado de proveer y registrar

información.
GPS.

Actor responsable de proveer periódicamente las coordenadas de cada

elemento configurado en el sistema.

Supervisor.

Usuario encargado de realizar consultas y explotación del sistema.

Usuario.

Este actor es general para la autenticación de identidad de un usuario de

sistema.
5.4.3 Alerta Horas - (Use Case diagram).

Este caso de uso describe las acciones necesarias para la generación de

alertas en línea cuando un vehículo se detiene en horas de producción.
uc Alerta Horas

Alertas Hora

Acceder Sistema
Alertas

Generar Alerta

Usuario

(from Actores) Base Datos

(from Actores)

Desplegar v ia Web

Fig. 13 Alerta Horas

CASO DE USO: Alerta Horas

ACTORES: Usuario, Base Datos
PROPÓSITO: Generar alertas cuando un vehículo se detiene
DESCRIPCIÓN: Este caso de uso describe las acciones necesarias para la generación de
alertas en línea cuando un vehículo se detiene en horas de producción.
TIPO: BAJA
PRE CONDICIÓN: Recibir fecha como parámetro.
POST CONDICIÓN: No existe
PASOS: Proveer fecha
ALTERNATIVAS:
Desplegar vía Web.

Desplegar las alertas generadas en pantalla.

Generar Alerta.

Caso de uso responsable de trabajar los datos del Sistema Alertas.

Acceder Sistema Alertas.

Caso de uso responsable de acceder a datos generados por el Sistema

de Alertas.
5.4.4 Alerta Velocidad - (Use Case diagram).

Este caso de uso describe las acciones necesarias para la generación de

alertas en línea cuando un vehículo exceda la velocidad permitida, durante el
trayecto en su jornada.

uc Alerta Velocidad

Alerta Velocidad

AccederSistema
Alertas

Base Datos
Usuario
Generar Alerta (from Actores)
(from Actores)

Desplegar v ia Web

Fig. 14 Alerta de Velocidad.

CASO DE USO: Alerta Velocidad

ACTORES: Usuario, Base Datos
PROPÓSITO: Generar alertas cuando un vehículo excede una velocidad máxima
DESCRIPCIÓN: Este caso de uso describe las acciones necesarias para la generación de
alertas en línea cuando un vehículo excede la velocidad permitida, durante el
trayecto en su jornada.
TIPO: BAJA
PRE CONDICIÓN: Recibir fecha como parámetro
POST CONDICIÓN: No existe
CASO DE USO: Alerta Velocidad
PASOS: Proveer fecha
ALTERNATIVAS:

Desplegar vía Web.

Desplegar las alertas generadas en pantalla.

Generar Alerta.

Caso de uso responsable de trabajar los datos del Sistema Alertas.

Acceder Sistema Alertas.

Caso de uso responsable de acceder a datos generados por el Sistema

de Alertas.
5.4.5 Configurar Alerta - (Use Case diagram)

Este caso de uso le otorga al usuario Administrador la facultad de

configurar las opciones y atributos de las alertas que el sistema irá generando
en línea en función de los eventos que se crearán durante la explotación del
sistema.

uc Configurar Alerta

Configurar Alertas

Autentificar

Seleccionar Vehiculo

«include» Base Datos

Administrador
(from Actores)
(from Actores)

Mostrar Alertas

Gestionar Alertas

Fig. 15 Configurar Alerta

CASO DE USO: Configurar Alerta

ACTORES: Administrador, Base Datos
PROPÓSITO: Configurar intervalos de hora y velocidad máxima por vehículo
DESCRIPCIÓN: Este caso de uso le otorga al usuario Administrador la facultad de configurar las
opciones y atributos de las alertas que el sistema irá generando en línea en
función de los eventos que se irán generando durante la explotación del
sistema.
TIPO: BAJA
CASO DE USO: Configurar Alerta
PRE CONDICIÓN: Seleccionar un vehículo
POST CONDICIÓN: No existe
PASOS: Listar vehículos, seleccionar una fila, editar las columnas
ALTERNATIVAS:

Autentificar.

Caso de uso responsable del inicio de sesión de un usuario del sistema.

Gestionar Alertas.

Caso de uso responsable de la edición y registro de la configuración de

la alerta.

Mostrar Alertas.

Caso de uso responsable del despliegue de las alertas generadas a la

pantalla del usuario.

Seleccionar Vehículo.

Caso de uso responsable de la selección de vehículos desplegados.

5.4.6 Servidor Sistema Alerta - (Use Case diagram)

Este caso de uso describe el comportamiento del Sistema de Alertas,

una aplicación residente y servidora encargada de la recepción, captura y
transformación de los paquetes enviados por los nodos GPS para ser
almacenados en la base de datos y posteriormente ser notificados al usuario.

uc Sistema Alerta

Sistema Alerta

Recibir Datos

GPS
(from Actores) Transformar Datos

Base Datos

(from Actores)

Registrar Datos

Usuario
Verificar Alertas
(from Actores)

Env iar Alertas y

Registro

Fig. 16 Servidor Sistema de Alerta

CASO DE USO: Servidor Sistema de Alerta

ACTORES: Usuario, Base Datos
PROPÓSITO: Extraer de los paquetes del GPS la información útil para las alertas
CASO DE USO: Servidor Sistema de Alerta
DESCRIPCIÓN: Este caso de uso describe el comportamiento del Sistema de Alertas, una
aplicación residente y servidora encargada de la recepción, captura y
transformación de los paquetes enviados por los nodos GPS para ser
almacenados en la base de datos y posteriormente ser notificados al usuario.
TIPO: ALTA
PRE CONDICIÓN: Libre
POST CONDICIÓN: No existe
PASOS: Aplicación residente en memoria, se activa automáticamente por S.O.
ALTERNATIVAS:

Enviar Alertas y Registro.

Caso de uso responsable del despacho de la notificación de la alerta

generada hacia el usuario.

Recibir Datos.

Caso de uso responsable de recibir del actor GPS, los paquetes de datos
para ser registrados en la base de datos.

Registrar Datos.

Caso de uso responsable de registrar los datos trabajados en la base de

datos.

Transformar Datos.

Caso de uso responsable de analizar, segmentar y estructurar los datos

provenientes del GPS.

Verificar Alertas.

Caso de uso responsable de validar los registros para su posterior

generación de alertas.
5.4.7 Servidor Sistema Recepción Datos - (Use Case diagram)

En este caso de uso, la precondición parte con el inicio de conexión al

Servidor Socket TCP, para luego iniciar la conexión a la Base de Datos, solo así
se podrán recibir los datos desde el nodo GPS y su posterior segmentación,
transformación y almacenamiento en la Base de Datos.

uc Sistema Recepcion Datos

Sistema Recepcion Datos

Conectar Serv idor

Socket TCP

«include»

Iniciar Cliente Datos

«include»

GPS Base Datos

(from Actores) Recibir Datos GPS (from Actores)

Transformar Datos

Grabar Informacion

Fig. 17 Servidor Sistema de Recepción de Datos

CASO DE USO: Servidor sistema de Recepción de Datos
ACTORES: GPS, Base Datos
PROPÓSITO: Captura de paquetes, transformación y almacenamiento de datos en BD.
DESCRIPCIÓN: Este caso de uso, levanta la conexión el Servidor Socket TCP, para luego
iniciar la conexión a la Base de Datos, solo así se podrán recibir los datos
desde el nodo GPS y su posterior segmentación, transformación y
almacenamiento en la Base de Datos.
TIPO: ALTA
PRE CONDICIÓN: Permiso de acceso
POST CONDICIÓN: No existe
PASOS: Aplicación residente en memoria, se activa automáticamente por S.O.
ALTERNATIVAS:

Conectar Servidor Socket TCP.

Este caso de uso tiene la responsabilidad de iniciar la conexión con el

Servidor Socket TCP, que gestiona el puerto que recepciona los
paquetes del GPS.

Grabar Información.

Este caso de uso se responsabiliza de almacenar la estructura trabajada

de los datos del GPS hacia la base de datos.

Iniciar Cliente Datos.

Este caso de uso, se responsabiliza de iniciar la conexión con la base de

datos y mediar los traspasos de los datos provenientes del Servidor
Socket TCP.

Recibir Datos GPS.

Este caso de uso se responsabiliza de recibir los paquetes provenientes

del nodo GPS.

Transformar Datos.
 Este caso de uso se responsabiliza de segmentar los datos capturados, y
transformarlos a una estructura de información adecuada para la base de
datos.
5.4.8 Caso de uso Principal - (Use Case diagram)

Este caso de uso es responsable de proveer al usuario la funcionalidad

del sistema, proveyendo los accesos a los reportes, paneles de la
monitorización de alarmas y a los mapas de ubicación de los vehículos.

uc Caso de uso principal

Monitorear Vehiculo

Autenticar

«include»

Buscar Vehiculo

Alertas Base Datos

Usuario

«include» «include»

Obtener Reporte Desplegar Ubicación

Fig. 18 Caso de Uso Principal

CASO DE USO: Caso de uso principal

ACTORES: Usuario, Base Datos
PROPÓSITO: Proveer la gestión para la monitorización de vehículos en tránsito
DESCRIPCIÓN: Este caso de uso es responsable de proveer al usuario la funcionalidad del
sistema, proveyendo los accesos a los reportes, paneles de la monitorización
CASO DE USO: Caso de uso principal
de alarmas y a los mapas de ubicación de los vehículos.
TIPO: ALTA
PRE CONDICIÓN: Inicio de sesión de usuarios
POST CONDICIÓN: No existe
PASOS: Iniciar la sesión de usuario
ALTERNATIVAS:

Alertas.

Caso de uso responsable del despliegue de alertas en línea con registros

ingresados recientemente del servicio de recepción de paquetes GPS.

Autenticar.

Caso de uso responsable del inicio de sesión de un usuario al sistema.

5.4.8.1 Autenticar - (Sequence diagram)

Este diagrama de secuencia explica la secuencia de pasos

necesarios para el inicio de una sesión de usuario, proveyendo la
seguridad necesaria al sistema y restringiendo su uso exclusivo a
usuarios registrados.

sd Autencicar

Usuario Pantalla Ingreso Autenticacion Usuarios Base Datos

AutenticarUsuario(user, pass) AutenticarUsuario(user, pass)

ValidaUsuario(user, pass)
BuscarUsuario(user)

Validacion(pass)
 Fig. 19 Autenticar

Autenticación.

Este controlador se encarga de mediar el flujo de consulta y

respuesta entre el formulario y la interfaz hacia la base de datos.

• Pantalla Ingreso.

Esta vista corresponde al formulario de autenticación, donde el

usuario ingresa su cuenta y contraseña.

• Usuarios.

Esta entidad es la interfaz hacia la base de datos que evalúa la

real identidad del usuario que intenta ingresar.

Buscar Vehículo.

Caso de uso responsable de la búsqueda y selección de un vehículo

para su utilización dentro del sistema.
 5.4.8.2 Buscar Vehículo - (Sequence diagram)

Este diagrama de secuencia describe los pasos de búsqueda de

un vehículo para su utilización dentro del sistema, tanto en operaciones
diversas como en reportes.

sd Buscar Vehiculo

Usuario Formulario Busqueda Vehiculos Base Datos

Busqueda

BuscarVehiculo(patente)
BuscarVehiculo(patente)

TraerVehiculo(patente)

BuscaVehiculo(patente)

(from Actores) (from Actores)

Fig. 20 Buscar Vehículo

8. Búsqueda.

Este controlador redirige el flujo de la consulta y respuesta entre

el formulario y la interfaz a la base de datos.

• Formulario Búsqueda.

Esta vista corresponde al formulario de búsqueda, donde el

usuario provee una patente, o la selecciona desde un listado de
vehículos existentes.

• Vehículos.
 Esta entidad corresponde a la interfaz que se encarga de buscar
el vehículo con la patente recibida.

• Desplegar Ubicación.
•
Caso de uso responsable de desplegar la ubicación del vehículo
en el mapa.

5.4.8.3 Desplegar Ubicación - (Communication diagram)

En este diagrama de actividades, el usuario recurre a la vista

"Desplegar Mapa", para consultar el posicionamiento del vehículo, y este
controlador redirige el flujo de la consulta a la entidad "Vehículos" para
obtener sus coordenadas en la "Base de Datos".

Alternativamente, la vista "Desplegar Mapa" también recurre al

controlador "Trazar Ruta" para redirigir la consulta a "Vehículos" por el
tramo recorrido, retornando la secuencia de coordenadas para el
posterior despliegue de la ruta.

sd Desplegar Ubicación

Flujo de actividad para despliegue de ubicación

Posicionar Vehiculo Buscar Vehiculo

«flow»

T ramoRecorrido

Desplegar Mapa Vehiculos

Usuario Base Datos

(from Actores) SecuenciaCoordenadas (from Actores)

Trasar Ruta

Fig. 21 Desplegar Vehículo

 • Desplegar Mapa.

Esta vista será la interfaz directa al usuario, donde podrá solicitar

al sistema la consulta sobre la ubicación del vehículo, o bien trazar
la ruta del trayecto que ha tenido un vehículo en un momento
determinado.

4. Posicionar Vehículo.

Este controlador, redirige la consulta de posicionamiento que hace

el usuario desde el mapa y lo solicita a la entidad vehículos.

• Trazar Ruta.

Este controlador recibe la solicitud del usuario para la consulta del

tramo recorrido de un vehículo y redirige la consulta a la entidad
Vehículos.

Asimismo recibe en respuesta la secuencia de coordenadas para

que la vista Desplegar Mapa lo dibuje para el usuario.

Vehículos.

Esta entidad se encarga de recibir las peticiones de consulta para

realizarlas en la base de datos y proveer la respuesta necesaria y
requerida.

Obtener Reporte.

Caso de uso responsable de generar reportes de Velocidad Máxima,

Vehículo Detenido, Historial y Distancia Recorrida.
5.4.9 Administración - (Use Case diagram)

En este caso de uso, el administrador podrá tener control y gestión de la

configuración del sistema.

uc Administracion

Administracion Datos

Autenticar

(from Caso de uso Principal)

«include» «include»

Listar Vehiculos

Administrador
«include» «include» Base Datos
(from Actores)
(from Actores)

Editar Vehiculo

Ingresar Vehiculo

Respaldar Datos

Fig. 22 Administración

CASO DE USO: Administración

ACTORES: Administrador, Base Datos
PROPÓSITO: Proveer las herramientas de mantenimiento de configuración al
administrador
DESCRIPCIÓN: En este caso de uso, el administrador podrá tener control y gestión de la
configuración del sistema.
TIPO: BAJA
PRE CONDICIÓN: El usuario debe estar identificado como administrador
CASO DE USO: Administración
POST CONDICIÓN: No existe
PASOS: Iniciar sesión de usuario administrador
ALTERNATIVAS:

Editar Vehículo

Este caso de uso es responsable de la edición y modificación de datos

de un vehículo en la base de datos.

Ingresar Vehículo

Este caso de uso es responsable del ingreso de un vehículo a la base de

datos.

Listar Vehículos.

Este caso de uso es responsable de disponer para el usuario el listado

de vehículos para su uso en la gestión del sistema.

Respaldar Datos.

Este caso de uso provee la herramienta al usuario para el aseguramiento

y respaldo los datos de la base.
5.4.9 Modelo de Datos
Las tablas principales donde se centraliza todo el movimiento de los datos son
“geocodes” y “userautos”. La tabla “eventos” está reservada para una próxima
versión del sistema donde se contempla la gestión de eventos que se
generarán a partir del comportamiento de los vehículos en función del tiempo.

Fig. 23 Modelo de Datos sistema de control y posicionamiento de vehículos vía GPS.

Descripción de tablas en Modelo de Datos

9. GEOCODES:
Esta tabla registra las coordenadas de los nodos GPS que circulan en
terreno, acumulando registros en una razón de 15 segundos
aproximadamente. Guarda además los datos de la geoposición de los
nodos que notifican su ubicación, la fecha, hora del registro, lugar e
identidad del vehículo en circulación.
10. ALERTAS:
Corresponde a una tabla de configuración, en ella de definen en forma
descriptiva los tipos de alertas que se gestionarán en el sistema.

11. ALERT_HORA:
Esta es una tabla de configuración y está estrechamente vinculada con la
tabla ALERTAS, y en ella se configuran los horarios de inicio y término
de la jornada de trabajo.

12. ALERT_VEL:
Esta es una tabla de configuración vinculada con la tabla ALERTAS, en
ella se configura la velocidad máxima que puede tener un vehículo.

13. USUARIOS:
Esta tabla almacena la configuración de los usuarios que pueden
acceder y hacer uso del sistema, como también al personal que tendrá
asignado uno o más vehículos a ser monitorizados en el sistema.

14. USERAUTOS:
Esta tabla registra la configuración de los vehículos que estarán
asignados a los usuarios y la configuración de patente, modelo y marca
del vehículo, y su capacidad de consumo por kilometraje.

15. CONFIGURACION:
Esta tabla es de uso específico dentro del sistema y es empleada para la
personalización de consultas a la base de datos, describiendo las tablas,
los campos, las relaciones y condiciones específicas para la ejecución y
despliegue de información dentro de algunos módulos del sistema.

16. SOCKETCONFIG:
Esta tabla es de uso específico dentro del sistema y es empleado para
registrar temporalmente los paquetes que son recibidos de los nodos por
la aplicación servidora para luego ser segmentados, transformados e
insertados en la tabla GEOCODES.

17. EVENTOS:
Esta tabla está reservada para una próxima versión del sistema, donde
se gestionará los eventos generados por los vehículos en circulación en
función del comportamiento dentro de la jornada de trabajo, con la
finalidad de generar indicadores visualizables en pantalla.
5.5 Construcción del sistema
5.5.1 Interfaces de búsqueda y despliegue de la información de un móvil

La secuencia de acceso a los diferentes niveles módulos y funcionalidades

del sistema, se inicia con la autenticación del usuario, el que será validado
en el momento de iniciar su sesión.

Una vez iniciada la sesión, el usuario tendrá a su disposición el control

centralizado del sistema, con un repertorio de opciones agrupados en menús
separados, desde los cuales podrá acceder a la configuración, reportes
históricos y control del mapa, donde podrá visualizar los vehículos en tránsito y
sus rutas, como también las alertas en línea que se irán desplegando en el
transcurso del tiempo.
5.5.1.1 ACCESO AL SISTEMA

3
Fig. 24 Interfaz de conexión al sistema

Para ingresar al sistema es necesaria la identificación por un usuario y

contraseña

1.- Ingreso de usuario

2.- Ingreso de Password
3.- Ingreso al Sistema
5.5.1.2 MENU PRINCIPAL

1 2 3 4

Fig. 25 Despliegue de Menú principal.

Una vez ingresado nos encontraremos 4 menús, que nos permitirán la

administración del sistema, tanto como vehículos, alertas y reportes.

5.6.1.3 SUBMENU CONFIGURACIÓN DE ALERTAS

Fig. 26 Configuración de Alertas

1 Opción Hora: Permite configurar alertas por hora tanto para agregar, borrar o
editar estas alertas.

2 Opción Velocidad: Permite configurar alertas de velocidad tanto para editar,

agregar, borrar alertas.
5.5.1.4 SUBMENU REPORTES

Fig. 27 Submenú Reportes

1 Opción Velocidad Máxima: Permite visializar el reporte de velocidad máxima

2 Opción Vehículo Detenido.
3 Opción Distancia Recorrida
4 Historial: Despliega todos los registros de los vehículos de este usuario,
donde donde se podrá ver fecha, hora, latitud, longitud y dirección de cada
registro.

5.5.1.5 Configurar Vehículos:

Fig. 28 Submenú Configurar Vehículos

Esta opción permite ingresar a un formulario para agregar, editar, o eliminar un

vehículo.
5.5.1.6 Submenú Control Mapa.

Fig. 29 Submenú control mapa

En esta opción se ingresa al Panel Control Mapa, desde donde se puede

analizar el recorrido de los vehículos.
5.5.1.7 Submenú Alertas de Horas

Formulario Visualización

Fig. 30 Submenú Alertas Horas

1 Formulario de visualización de alertas Hora. Muestra el nro. de alerta,

patente, hora inicio de alerta y hora final de alerta.

2 Opciones Formulario:

Eliminar un registro de alerta.

Recargar Tabla.

Agregar o eliminar columnas a visualizar

Editar un registro seleccionado.

Agregar una nueva alerta/hora.

5.5.1.8 Agregar Alertas.

5.9.1
.8

Fig. 31 Submenú agregar alertas

Formulario de ingreso de alertas

Seleccionar una patente, ingresar hora inicio y término de una alerta.

5.5.1.9 Editar Alertas.

5.9.1.9

Fig. 32 Formulario de edición de alerta.

Al seleccionar una alerta y presionar el botón editar se accede a

actualizar las horas de esa alerta.
5.5.1.10 Submenú Eliminar Alerta.

Fig. 33 Submenú Eliminar Alerta

Permite eliminar un registro seleccionado.

5.5.1.11 Submenú Alerta de Velocidad.

Fig. 34 Submenú Alerta de Velocidad

1 Visualización de alertas de velocidad, se visualiza nro. de alerta, patente y

velocidad máxima para ese vehículo.

2 Opciones Formulario.

Eliminar un registro de alerta

Recargar tabla.

Agregar o eliminar columnas a visualizar

Editar un registro seleccionado.

Agregar una nueva alerta velocidad.

5.5.1.12 Agregar Alerta de Velocidad

Fig. 35 Agregar Alerta velocidad

En este formulario se permite ingresar una nueva alerta de velocidad,

seleccionando una patente y agregando la velocidad que no debe exceder.
5.5.1.13 Editar Alerta de Velocidad

Fig. 36 Editar alerta velocidad

Al seleccionar una fila, se puede editar la alerta, modificando la velocidad

máxima
5.5.1.14 Eliminar Alerta de Velocidad.

Fig. 37 Eliminar alerta velocidad

Al seleccionar una fila se permite eliminar la alerta.

5.5.1.15 Reporte Vehículos / Velocidad Máxima.

Fig. 38 Reporte de vehículos velocidad máxima

Presionando sobre la opción de reporte velocidad máxima, aparecerá

un formulario de ingreso de fecha a consultar, en este formulario deberá
ingresar la fecha para buscar vehículos que sobre sobrepasaron la velocidad
máxima.
 Fig. 39 Reporte de vehículos que sobrepasaron la velocidad máxima establecida

El reporte que se despliega, muestra aquellos vehículos que

sobrepasaron la velocidad máxima definida en la configuración para ese
vehículo.

Agrupado por períodos de una hora, figurará la velocidad máxima

registrada en ese intervalo. Adicionalmente figuran columnas de la cantidad de
segundos que mantuvo la velocidad y las coordenadas donde se registró el
vehículo en ese instante.
5.5.1.16 Reporte Vehículo Detenido

Fig. 40 Formulario ingreso de fecha.

Presione reporte velocidad máxima y aparecerá un formulario de ingreso

de fecha a consultar.

Posteriormente, se listarán aquellos vehículos que han

permanecido detenidos durante intervalos de una hora. Se desplegarán
columnas donde figura la cantidad de tiempo detenido, y las coordenadas
donde se detuvo.

Fig. 41 Reporte de vehículos detenidos

5.5.1.17 Reporte Distancia Recorrida

Fig. 42 Selección de vehículo y fecha

Primero se debe seleccionar desde un listado, la patente de un vehículo ,

y a continuación elegir una fecha a consultar.
 A continuación se listará en intervalos de una hora, la distancia en
kilómetros que ha recorrido el vehículo durante el tiempo y a la velocidad
aproximada figurados en las columnas Tiempo y Km/h. Las columnas de
Tiempo, Distancia y Consumo Total, mostrarán en forma acumulada en función
del tiempo, el consumo acumulado en función de las distancias por tiempos
recorridos en cada tramo. Adicionalmente se muestran las columnas de las
coordenadas de referencia, donde se registra la ubicación del vehículo durante
esos intervalos.

Fig. 43 Reporte de Distancia Recorrida

Capítulo 6: CONCLUSIÓN

A la vista del trabajo realizado, se puede concluir que los objetivos planteados

inicialmente se cumplieron en su totalidad, encontrándose el sistema

actualmente disponible y operativo para cumplir con las funcionalidades

propuestas inicialmente:

- Crear una interfaz gráfica que permita visualizar la ubicación y recorrido

de los móviles.

Se desarrolló un sistema informático, orientado a Web, paramétrico y

autoconfigurable, utilizando herramientas de tipo open source, con una

interfaz gráfica de navegación intuitiva.

- Crear reportes de gestión que faciliten la administración de los móviles.

La información capturada puede ser consultada en forma paramétrica y

desplegada en el panel diseñado para visualización y seguimiento de los

móviles.
- Crear alertas que faciliten la administración de los móviles.

Se incluyó el registro paramétrico de alertas controlables de velocidad y

tiempo, desplegando gráficamente el estado de un móvil mediante la

utilización de cartografía digital, dejando abierta la posibilidad de agregar

alertas por otros conceptos.

- Presentar el estado del arte de la tecnología de los GPS y su uso en

control de flota.

Se detalló las principales características de la tecnología GPS, su estado

actual, ventajas y desventajas de uso, elementos componentes y principales

marcas y empresas proveedoras en el mercado nacional.

La metodología XP, definida inicialmente para el desarrollo del sistema y

cuyas características principales fueron ampliamente detalladas, fue aplicada

en forma eficiente, utilizándose la programación en parejas, incorporando

activamente al cliente final en todas las modificaciones y correcciones, y

realizando entregas de validación periódicas según se avanzó con el desarrollo.

Para el desarrollo del proyecto, se asignaron distintos roles dentro del grupo,

lográndose con ello subdividir las tareas a realizar, y concentrar en cada una las

mejores habilidades de cada integrante.

Se realizaron pruebas basadas en la información capturada desde el receptor

GPS instalado en un grupo de vehículos, y almacenada en una base de datos

diseñada, para un rango de fecha y tiempo, las que entregaron los resultados

esperados. Se probó la interfaz construida, la que permite una operación

eficiente y una navegación fluida.

La estructura modular y paramétrica con que se diseñó la solución, otorga la

posibilidad de incorporar rápidamente funcionalidades futuras, de acuerdo al

eventual crecimiento del producto una vez comercializado.

Esperamos con todo esto, haber contribuido a entregar una visión actual del

estado de la tecnología GPS, sus fundamentos técnicos, potencialidades y

ventajas de utilización aplicadas sobre el desarrollo de un sistema informático.

Capítulo 7: BIBLIOGRAFÍA

lan Somerville, Ingeniería de Software, 2007, Pearson, Addison Wesley, 2005.

ISBN: 84-7829-074-5; Editorial: Pearson, Addson Wesley; Año 2005; 712
páginas.
URL: http://www.scribd.com/doc/25664820/Ingenieria-de-Software-Ian-
Sommerville-7ma-Edicion
BIB.XP6: Pag. 363.

Urbina López Diego Alejandro, Informe “Programación Extrema” Universidad

César Vallejo (UCV), Lima Norte 2009; 11 páginas.
URL: http://www.scribd.com/doc/15250014/Programming-Xtreme-Inform-Ucv-
University
BIB.XP3: Pag. 2; BIB.XP4: Pag. 11; BIB.XP5: Pag. 10; BIB.XP8: Pag. 3 - 5

Zambrano Jiménez Solange, Juan Carlos León, Laura Otaiza Gómez.

Informe “Programación Extrema” Universidad de Los Andes Mérida
Colombia, Febrero 2010; 28 páginas.
URL: http://www.scribd.com/doc/26495149/Programacion-extrema-Informe
BIB.XP1: Pag. 5; BIB.XP2: Pag. 7;BIB.XP7: Pag. 24 ;BIB.XP9: Pag. 10;
BIB.XP10: Pag. 12.

Google Code, Alojamiento de proyectos; Fecha Consulta: 18 Julio 2010

BIB.GC1: URL: http://code.google.com/p/support/wiki/GettingStarted

BIB.GC2: URL: http://code.google.com/intl/es-ES/projecthosting
7.1 LINKS DE ACCESO A DOCUMENTACION DESDE INTERNET

http://www.elgps.com/documentos/comofuncionagps/comofuncionagps.html

Cómo funciona el GPS en cinco pasos lógicos.

Autor: Trimble Navigation Limited. Fecha última visita: 25/07/2010

http://escuadronfrontera.blogspot.com/2008/07/el-g-p-s.html

El GPS, partes del sistema de posicionamiento global.

Autor: No se menciona. Fecha última visita: 25/07/2010

http://www.scribd.com/doc/2567422/el-funcionamiento-del-gps

Segmentos y componentes del sistema GPS.

Autor: No se menciona. Fecha última visita: 25/07/2010

http://homepages.mty.itesm.mx/al584299/mypaper.htm

Historia , cronología , funcionamiento y aplicación del “GPS” a través de

tres décadas.
Autor: Ramiro Jesús Ayala Arizpe. Fecha última visita: 22/06/2010

http://www.infoaventura.com/reportaje.asp?Id=13

Ventajas del GPS respecto a los sistemas habituales de orientación.

Autor: No se menciona. Fecha última visita: 25/07/2010

http://www.asifunciona.com/electronica/af_gps/af_gps_7.htm

Sitio Web educativo.

Autor: No se menciona. Fecha última visita: 26/07/2010
Principales Empresas nacionales proveedoras del servicio GPS

http://www.daycro.cl/home.php?e[1]=1&e[2]=5

Sitio Web Corporativo

Autor: No se menciona. Fecha última visita: 23/07/2010

http://gismac-gps.cl

Sitio Web Corporativo

Autor: No se menciona. Fecha última visita: 24/06/2010

http://www.localizagps.cl

Sitio Web Corporativo

Autor: No se menciona. Fecha última visita: 25/07/2010

http://www.gpschile.com

Sitio Web Corporativo

Autor: No se menciona. Fecha última visita: 23/07/2010

http://www.gpstrace.cl

Sitio Web Corporativo

Autor: No se menciona. Fecha última visita: 20/05/2010

http://www.movilmaster.cl

Sitio Web Corporativo

Autor: No se menciona. Fecha última visita: 26/07/2010