UNIVERSIDAD CIENCIAS DE LA INFORMATICA FACULTAD DE INGENIERIA Y TECNOLOGA

DESARROLLO DE UN SISTEMA DE MONITOREO Y CONTROL DE POSICIONAMIENTO VIA GPS APLICABLE EN UNA FLOTA DE VEHCULOS

EDUARDO ACOSTA BECERRA ANDRS BASAEZ MIRANDA MARJORIE CCOPA FLORES GABRIEL MUOZ MIGUEL VARGAS WELCH

2010

UNIVERSIDAD CIENCIAS DE LA INFORMATICA FACULTAD DE INGENIERIA Y TECNOLOGA

DESARROLLO DE UN SISTEMA DE MONITOREO Y CONTROL DE POSICIONAMIENTO VIA GPS APLICABLE EN UNA FLOTA DE VEHCULOS

Trabajo de Titulacin presentado en conformidad a los requisitos para obtener el Ttulo de Ingeniero de Ejecucin en Informtica.

Alumno(s) :
EDUARDO ACOSTA BECERRA ANDRS BASAEZ MIRANDA MARJORIE CCOPA FLORES GABRIEL MUOZ MADRID MIGUEL VARGAS WELCH

Profesor Gua :
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 vehculos va GPS aplicables a una flota de vehculos. El objetivo principal fue crear un sistema informtico que permitiera, mediante parametrizacin adecuada, realizar consultas dinmicas a los datos de posicionamiento de los vehculos, capturados mediante dispositivos con tecnologa GPS, y almacenados en una base de datos, para realizar con ellos el control de gestin a travs de la generacin de reportes de consulta en lnea, de su posicin en un perodo determinado, generacin 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 pequeas empresas de transporte. Como objetivo adicional, se plante dar a conocer el estado del arte de la tecnologa GPS, sus principales caractersticas y utilizacin en el rubro del transporte nacional.

TABLA DE CONTENIDOS
CAPTULO 1: INTRODUCCIN....................................................................................................................................6 CAPTULO 2: OBJETIVOS..........................................................................................................................................8 2.1 OBJETIVO GENERAL................................................................................................................................8 2.2 OBJETIVOS ESPECFICOS .......................................................................................................................8 2. 3 ALCANCES Y LIMITACIONES................................................................................................................8 CAPTULO 3: MARCO TERICO...........................................................................................................................10 3.1 QU ES EL GPS? .................................................................................................................................................12 3.2 CARACTERSTICAS DEL GPS................................................................................................................13 3.3 DETALLES TCNICOS DEL FUNCIONAMIENTO DEL GPS.........................................................................14 3.3.1 PASO 1: TRIANGULACIN DESDE LOS SATLITES........................................................................14 3.3.2 PASO 2: MIDIENDO LA DISTANCIA A LOS SATLITES.................................................................15 3.3.3 PASO 3: CONTROL PERFECTO DEL TIEMPO...................................................................................15 3.3.4 PASO 4: CONOCER DNDE ESTN LOS SATLITES 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 UTILIZACIN.................................................................................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 METODOLOGA EMPLEADA.........................................................................................................................28 3.9.1 METODOLOGA XP O PROGRAMACIN EXTREMA.............................................................................28 3.9.2 USO PRCTICO DE LA METODOLOGA 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 TECNOLOGAS EMPLEADAS.......................................................................................................................42 3.10.1 ARQUITECTURA DE LA SOLUCIN.................................................................................................42 3.10.2 TECNOLOGA DE DESARROLLO....................................................................................................44 CAPTULO 4. DEFINICIN DEL PROYECTO...........................................................................................................45 4.1 ALCANCE..........................................................................................................................................................45 4.2 DETALLE DE LA SOLUCIN........................................................................................................................46 4.3 ENTREGABLES.................................................................................................................................................47 4.4 ROLES Y RESPONSABILIDADES..................................................................................................................49 4.5 SUPUESTOS, RIESGOS, DEPENDENCIAS, RESTRICCIONES...................................................................51 4.6 ESTIMACIN DE RECURSOS/ HORAS.......................................................................................................52 CAPTULO 5: DISEO...........................................................................................................................................53 5.1 MODELAMIENTO....................................................................................................................................53 5.2 HISTORIAS DE USUARIO...............................................................................................................................55

5.3 CARACTERSTICAS.........................................................................................................................................60 PANTALLA PRINCIPAL.......................................................................................................................61 REPORTE DE VELOCIDAD.................................................................................................................61 REPORTE VEHCULO 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 RECEPCIN 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 VEHCULO - (SEQUENCE DIAGRAM) ...........................................................................78 5.4.8.3 DESPLEGAR UBICACIN - (COMMUNICATION DIAGRAM) .....................................................79 5.4.9 ADMINISTRACIN - (USE CASE DIAGRAM) ..................................................................................81 5.4.9 MODELO DE DATOS....................................................................................................................................83 5.5 CONSTRUCCIN DEL SISTEMA...................................................................................................................85 5.5.1 INTERFACES DE BSQUEDA Y DESPLIEGUE DE LA INFORMACIN DE UN MVIL .............85 5.5.1.1 ACCESO AL SISTEMA.......................................................................................................................86 5.5.1.2 MENU PRINCIPAL..............................................................................................................................87 5.6.1.3 SUBMENU CONFIGURACIN DE ALERTAS..................................................................................87 5.5.1.4 SUBMENU REPORTES.......................................................................................................................88 5.5.1.5 CONFIGURAR VEHCULOS:.............................................................................................................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 VEHCULOS / VELOCIDAD MXIMA........................................................................98 5.5.1.16 REPORTE VEHCULO DETENIDO...............................................................................................100 5.5.1.17 REPORTE DISTANCIA RECORRIDA...........................................................................................101 CAPTULO 6: CONCLUSIN................................................................................................................................103 7.1 LINKS DE ACCESO A DOCUMENTACION DESDE INTERNET ...........................................................107

Captulo 1: INTRODUCCIN
Hoy en da las empresas que hacen uso del GPS consiguen aumentar la productividad del personal en movilidad adems de obtener importantes ahorros en combustible, segn una reciente encuesta impulsada por Motorola entre 255 responsables de la toma de decisiones de TI y telecomunicaciones de Norteamrica. Segn este estudio, el beneficio ms citado por casi el 50% de las empresas que utilizan actualmente el GPS, fue una importante reduccin del consumo de carburante, lo que tiene su reflejo en una disminucin de las distancias de los desplazamientos de 231,2 millas semanales de media, con un ahorro registrado de 51.582 dlares anuales en carburantes. En Estados Unidos, con ms de un milln de camioneros, el ahorro potencial en el conjunto de la industria podra alcanzar los 53.000 millones de dlares anuales. El estudio revel asimismo que las empresas que han desplegado tecnologas GPS se ahorran aproximadamente 54 minutos al da, lo que se traduce en un ahorro anual en mano de obra de 5.484 dlares por empleado, o 5,4 millones por empresa encuestada. Adems del ahorro, tambin hay aplicaciones de localizacin a las que se les atribuyen mejoras en la organizacin de rutas, permitiendo a la empresa saber exactamente dnde estn sus empleados en cada momento, y examinar distintas posibilidades antes de implementar una ruta. Las empresas encuestadas emplearon menos tiempo en enfrentarse al trfico o a hallar rutas, incrementando el tiempo dedicado a nuevos o antiguos clientes. De hecho, al preguntarles por qu se plantearan invertir en GPS u otras nuevas tecnologas, los encuestados mencionaron la atencin al cliente como su prioridad nmero uno. El estudio tambin identific otras aplicaciones esenciales, como la navegacin para mejorar la puntualidad y optimizar las rutas. Navegacin y optimizacin 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 da con una solucin de control y monitoreo mediante GPS, para los operadores de flotas de vehculos , se ha convertido en una inversin rentable al corto plazo, toda vez que los ahorros logrados no solo son significativos en cuanto a los costos de combustible. Tambin permitir que los desplazamientos sean planificados y programados con

anticipacin utilizando la informacin 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 operacin de la logstica de entrega de insumos y productos de las empresas. Por ello, y analizando la oferta de los distintos actores oferentes del servicio de monitoreo va GPS existentes actualmente en el mercado nacional, hemos previsto la oportunidad de desarrollar un sistema de monitoreo de mviles va GPS, que considere la posibilidad de ser adquirido por flotas de vehculos de tamao mediano o pequeo. 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 tecnologa en el pas y que en general no est al alcance de la mayora de las Pymes que puedan requerirlo, ser desarrollado con herramientas de software abierto, y cubrir las funcionalidades bsicas de reportaje de informacin.

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

Captulo 2: OBJETIVOS

2.1 OBJETIVO GENERAL Desarrollar un sistema de reporte en lnea que apoye el monitoreo de vehculos de transporte. 2.2 OBJETIVOS ESPECFICOS Para contribuir a lograr el objetivo general se contemplan las siguientes etapas: Presentar el estado del arte en la tecnologa de los GPS y su uso en control de flota. Crear una interfaz grfica que permita visualizar la ubicacin y recorrido de los mviles. Crear reportes de gestin que faciliten la administracin de los mviles. Crear alertas que faciliten la administracin de los mviles. 2. 3 ALCANCES Y LIMITACIONES. ALCANCES: Se desarrollar e implementar un sistema con interfaz grfica que, mediante los elementos de captura y seguimientos utilizados por la tecnologa GPS, permitir desplegar en lnea la posicin de un mvil en un momento y posicin determinados, permitiendo la captura y entrega de informacin de posicionamiento, tiempo de detencin y consumo de combustible realizado por el mvil para llegar desde un punto inicial a un punto determinado. La informacin ser entregada mediante alarmas previamente programadas, a partir de la informacin de posicionamiento capturada por los dispositivos GPS incorporados en el mvil.

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 Integracin y que bsicamente posibilitan entregar una visin de la tecnologa GPS, sus potencialidades y su estado actual de aplicacin mediante el desarrollo de un sistema informtico.

Captulo 3: MARCO TERICO

Con el inicio de la Era Espacial (1957) y el posterior lanzamiento del satlite Vanguard 1 en 1959, se puso de manifiesto que la transmisin de ondas radiales, podan servir para orientar al hombre en cualquier parte del mundo. Los primeros sistemas de posicionamiento, empleaban estaciones de radio AM, (amplitud modulada), que posean una gran cobertura, aunque no permitan determinar con precisin una posicin determinada, ya que las interferencias atmosfricas afectaban dichas seales. Otro inconveniente de las seales AM, es la propia curvatura de la Tierra, ya que sta tiende a desviar las ondas. La solucin para este inconveniente era colocar transmisores de radio en el espacio y que emitieran seales de forma constante en direccin a la Tierra. Este mtodo 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 compaa 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 blicas y programado intencionalmente con ciertos errores de clculo, 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 decisin de ampliar las capacidades del GPS aadiendo una nueva seal para el uso civil, asegurando mejoras significativas en el posicionamiento y navegacin de los usuarios. El Departamento de Defensa, trabaj conjuntamente con la Fuerza Area de Estados Unidos y con los organismos civiles para la modernizacin del sistema GPS, centrndose 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 satlites, el sistema de control y los usuarios. El primer subsistema consiste en una red de 24 satlites artificiales (llamados NAVSTAR), 21 satlites activos ms tres de repuesto, los cuales son propiedad del Gobierno de Estados Unidos. Estos satlites se encuentran uniformemente distribuidos en un total de 6 rbitas (cada una en una direccin distinta y cuyo centro es La Tierra), de forma que hay 4 satlites por rbita. Esta configuracin asegura que siempre puedan "verse" al menos 8 satlites desde casi cualquier punto de la superficie terrestre. Los satlites GPS orbitan la Tierra a una altitud de unos 20.000 Kms. y recorren dos rbitas completas cada da. Describen un tipo de rbita tal que "salen" y se "ponen" dos veces al da. Cada satlite transmite seales de radio a la Tierra con informacin acerca de su posicin y el momento en que se emite la seal. Esta informacin se recibe con receptores GPS, que decodifican las seales enviadas por varios satlites simultneamente y combinan sus informaciones para calcular su propia posicin en la Tierra, es decir sus coordenadas de latitud y longitud con una precisin de unos 10 metros. (4), (5).

(4) Universidad de Concepcin, Facultad de Ingeniera 2001. (5) Geological Survey Of IRAN (G.S.I), http://www.gsi.ir/Science/Lang_en/Page_03-07-01/Introduction.html

3.2 CARACTERSTICAS DEL GPS El GPS fue creado con el objetivo de satisfacer los requerimientos de las fuerzas militares en la determinacin exacta de posicin, velocidad y tiempo, en un sistema de referencia comn, en o cerca de la Tierra, para cualquier condicin climtica. El posicionamiento con GPS significa proporcionar la latitud y longitud del punto en el que se encuentra sobre la superficie terrestre. La mayora 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 da el Sistema de Posicionamiento Global (GPS) est disponible en dos formas bsicas: SPS, iniciales de Standard Positioning Service (Servicio de Posicionamiento Estndar), y PPS, siglas de Precise Positioning Service (Servicio de Posicionamiento Preciso). El SPS proporciona la posicin absoluta de los puntos con una precisin de 100 m. El cdigo PPS permite obtener precisiones superiores a los 20 m.; este cdigo es accesible slo a los militares de Estados Unidos y sus aliados, salvo en situaciones especiales(6). Las tcnicas de mejora, como el GPS diferencial (DGPS), permiten a los usuarios alcanzar hasta 3 m de precisin.

(6) Enciclopedia Microsoft Encarta

3.3 DETALLES TCNICOS DEL FUNCIONAMIENTO DEL GPS.

El funcionamiento del sistema GPS se puede describir en cinco pasos fundamentales:

3.3.1 Paso 1: Triangulacin desde los satlites.

La idea general detrs del GPS es utilizar los satlites en el espacio como puntos de referencia para ubicaciones aqu en la tierra. Esto se logra mediante una exacta medicin de nuestra distancia hacia al menos tres satlites, lo que nos permite triangular nuestra posicin en cualquier parte de la tierra. La idea geomtrica de esta medicin consiste en: supongamos que medimos nuestra distancia al primer satlite y resulta ser de 20.000 Kms., esto limita nuestra posicin a la superficie de una esfera que tiene como centro dicho satlite y cuyo radio es de 20.000 Kms. A continuacin se mide la distancia a un segundo satlite 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 satlite, sino tambin sobre otra esfera que se encuentra a 21.000 Kms. del segundo satlite. En otras palabras, se est en algn lugar de la circunferencia que resulta de la interseccin de las dos esferas. Si ahora se mide la distancia a un tercer satlite y se descubre que est a 23.000 Km de ste, esto limita la posicin an ms a los dos puntos en los cuales la esfera de 23.000 Kms. corta la circunferencia resultante de la interseccin de las dos primeras esferas. Es decir, que midiendo la distancia a tres satlites se limita el posicionamiento a solo dos puntos posibles. Para decidir cual de ellos es la posicin verdadera, se podra efectuar una nueva medicin a un cuarto satlite. Pero normalmente uno de los dos puntos posibles resulta ser muy improbable por su ubicacin demasiado lejana de la superficie terrestre y puede ser descartado sin necesidad de mediciones posteriores. Una cuarta medicin, de todos modos es muy conveniente por otra razn que se ver ms adelante.

3.3.2 Paso 2: Midiendo la distancia a los satlites.

La posicin se calcula a partir de la medicin de la distancia hasta por lo menos tres satlites. En el caso del GPS se est midiendo una seal de radio, que viaja a la velocidad de la luz, alrededor de 300.000 Kms. por segundo. Por lo tanto el problema es en cmo medir ese tiempo que, obviamente, es extremadamente corto. Suponiendo que el GPS, por un lado, y el satlite, por otro, generan una seal auditiva en el mismo instante exacto. Se oira dos versiones de la seal. Una de ellas inmediatamente, la generada por el receptor GPS y la otra con cierto atraso, la proveniente del satlite, porque tuvo que recorrer alrededor de 20.000 Kms. para llegar hasta l. Con esto se puede decir que las seales no estn sincronizadas. Si se quisiera saber cul es la magnitud de la demora de la seal proveniente del satlite se puede retardar la emisin de la seal del GPS hasta lograr la perfecta sincronizacin con la seal que viene del satlite. El tiempo de retardo necesario para sincronizar ambas seales es igual al tiempo de viaje de la seal proveniente del satlite. 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 satlite. La seal emitida por el GPS y por el satlite es llamada Cdigo Pseudo Aleatorio.

3.3.3 Paso 3: Control perfecto del tiempo.

La medicin del tiempo de viaje de una seal es clave para el GPS, los relojes que se usan deben ser muy exactos, dado que si se mide con un desvo de una milsima de segundo, a la velocidad de la luz, esto se traduce en un error de 300 Kms. Por el lado de los satlites, el tiempo es casi perfecto porque lleva a bordo relojes atmicos de una gran precisin, por el alto costo que implica el uso de estos relojes atmicos, los receptores GPS, aqu en la tierra, utilizan relojes mucho menos precisos. Para obtener un tiempo perfecto es necesario realizar una medicin satelital adicional. Cualquier GPS decente debe ser capaz de sintonizar al menos cuatro satlites de manera simultnea. En la prctica, casi todos los GPS en venta actualmente, acceden a ms de 6, y hasta a 12 satlites

simultneamente.

3.3.4 Paso 4: Conocer dnde estn los satlites en el espacio.

Todos ellos estn flotando a unos 20.000 Kms. de altura en el espacio. Un satlite 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 atmsfera. Eso significa que orbitar de manera regular. De acuerdo al Plan Maestro de GPS, la Fuerza Area de los EEUU coloc cada satlite 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 satlite en el espacio, en cada momento. Con el fin de mantener estas rbitas bsicas en forma exacta, los satlites 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, posicin y velocidad de cada satlite. Los errores que ellos controlan son los llamados errores de efemrides, o sea evolucin orbital de los satlites. Estos errores se generan por influencias gravitacionales del sol y de la luna y por la presin de la radiacin solar sobre los satlites. 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 posicin exacta de un satlite, vuelve a enviar dicha informacin al propio satlite. De esa manera el satlite incluye su nueva posicin corregida en la informacin que transmite a travs de sus seales a los GPS. Esto significa que la seal que recibe un receptor de GPS no es solamente un cdigo pseudo aleatorio con fines de tiempo, tambin tiene un mensaje con informacin sobre la rbita exacta del satlite.

3.3.5 Paso 5: Corrigiendo Errores

En este paso slo se van sealar errores que afectan la seal del GPS, hacindola menos precisa. Para un receptor de GPS se debe tener en cuenta una amplia variedad de errores posibles tales como: En el clculo se asume que las seales GPS viajan a la velocidad de la luz, siendo sta solamente constante en el vaco. Adems, las seales GPS atraviesan la ionsfera y tropsfera, el paso de las seales a travs de estas capas provoca un error en el retraso en la recepcin de la seal. Los problemas para la seal 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 atmicos que utilizan son muy precisos, pero no son perfectos. Pueden ocurrir minsculas discrepancias que se transforman en errores de medicin del tiempo de viaje de las seales (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 divisin espacio incluye los satlites y los cohetes Delta que lanzan los satlites desde Cabo Caaveral, en Florida, Estados Unidos. La divisin control incluye la estacin de control principal en la base de las Fuerzas Areas Falcon, en Colorado Springs, Estados Unidos, y las estaciones de observacin situadas en Falcon AFB, Hawai, en la isla de Ascensin en el Atlntico, en Diego Garca en el ocano ndico, y en la isla Kwajalein en el Pacfico sur. La divisin usuario est constituida por receptores GPS de navegacin 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 recepcin de entre cuatro y ocho seales de radio de otros tantos satlites de los cuales se conoce de forma muy exacta su posicin orbital con respecto a la tierra; a la vez, se conoce muy bien el tiempo que han tardado las seales en recorrer el camino entre el satlite y el receptor. Conociendo la posicin de los satlites, la velocidad de propagacin de sus seales y el tiempo empleado en recorrer el camino hasta el usuario, por trilateracin se puede establecer la posicin en trminos 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 satlites que soportan el sistema y las seales de radio que emiten. Estos satlites conforman la llamada constelacin NAVSTAR (Navigation Satellite Timing and Ranging), constituida por 24 satlites operativos ms cuatro de reserva, mantenidos por la fuerza area estadounidense. No hay que olvidar, que el origen de este sistema es militar y su financiacin corre ntegramente a cargo del gobierno de los Estados Unidos. Los 24 satlites y sus 4 de reserva de la constelacin 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 seal de al menos cuatro satlites. Esto es muy importante, porque se necesitan al menos cuatro satlites para conocer la posicin del observador, y que estos se dispongan con un ngulo de elevacin sobre el horizonte superior a 15; no obstante, casi siempre son ms de cuatro los satlites 'visibles'.

3.4.2 Segmento de control

El segmento de control son todas las infraestructuras en tierra necesarias para el control de la constelacin de satlites. Dichas infraestructuras tienen coordenadas terrestres de muy alta precisin y consisten en cinco grupos de instalaciones repartidas por todo el planeta, para tener un control homogneo de toda la constelacin de satlites

Fig. 2 Segmento de Control

Estas infraestructuras realizan un seguimiento continuo de los satlites que pasan por su regin del cielo, acumulando los datos necesarios para el clculo preciso de sus rbitas. Dichas rbitas son muy predecibles, dado que no existe friccin atmosfrica en el entorno donde se mueven los satlites; a las predicciones de las rbitas de los satlites para el futuro se les conoce con el nombre de almanaques, cuyo clculo depende tambin del segmento de control.

3.4.3 Segmento de Usuario

El segmento del usuario est constituido por el hardware (equipos de recepcin) y el software que se utilizan para captar y procesar las seales de los satlites. Se puede utilizar en diversos tipos de actividades relacionados con la vigilancia. Entre ellas podramos citar: La deteccin de la dilatacin de magma de un volcn, La observacin de los movimientos de un iceberg.

Determinar las vibraciones terrestres, fin, cualquier fenmeno natural o creado por el hombre que presente algn movimiento, por ms imperceptible que parezca. Los datos generados por el GPS tambin pueden ser utilizados para estudiar fenmenos 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 kilmetros. Asimismo, el GPS puede servir para comprender mejor los cambios fsicos que ocurren en nuestro planeta. Por ejemplo, los movimientos en las profundas aguas de los ocanos, el monitoreo de el estatus de la actividad volcnica en ciertas regiones. Algunos es la deteccin de los movimientos bajo la tierra tambin Los investigadores del Instituto de Mediciones Geogrficas de Japn han recogido una serie de datos con Geonet, una red de ms de mil sensores GPS que cubre las zonas rurales del pas, para con esto tratar de predecir el comportamiento de las capas subterrneas y por ende predecir cuando un sismo suceder. Es empleado en la navegacin martima, terrestre y area. Tambin empieza a surgir en las calles, donde los autos tienen integrado sistemas de GPS y con esto es prcticamente imposible perderse.

3.5 TIPOS PRINCIPALES DE EQUIPOS GPS

Hoy en da se encuentra una gran variedad de tipos de GPS, por las diversas funcionalidades que tiene y sus formas. Adems, dicha clasificacin puede realizarse por mltiples criterios, como por ejemplo en funcin de la arquitectura (receptores secuenciales, continuos o multiplex), en funcin del mtodo de funcionamiento (correlacin de cdigo o anlisis de fase de la portadora), o en funcin de las aplicaciones a las que se destine.

3.6 VENTAJAS Y DESVENTAJAS DE SU UTILIZACIN .

3.6.1 VENTAJAS El GPS es un sistema que entrega informacin acerca de posicin en la tierra mediante altitud y longitud en forma fcil y rpida, con una precisin casi exacta y cobertura mundial las 24 horas del da incluso en condiciones meteorolgicas muy adversas. Entregan informacin de posicionamiento 100% fiable. Estos dispositivos GPS son de fcil instalacin sobre el parabrisas o tablero de instrumentos, con un soporte que facilita la correcta visualizacin. Facilidad de su uso, ya que permite introducir destinos y rutas de forma mucho ms cmoda y precisa que con los sistemas tradicionales (mapas de carreteras). La portabilidad que tiene el GPS de poder adecuarse a toda instalacin. Actualizacin constante de la informacin cartogrfica. Efectividad en el clculo de la ruta y la legibilidad de la informacin.

Los datos otorgados por los satlites son de mucha utilidad para el hombre, ya que adems de entregar informacin de fiabilidad relativa acerca de

nuestra posicin y altitud, nos otorga datos que son muy tiles para prever los cambios atmosfricos y las condiciones ambientales y climticas del lugar que deseemos tener informacin. Todos los GPS's incorporan funciones de navegacin realmente sofisticadas que harn cambiar todo concepto de la orientacin 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 grfica nos indicar si se est sobre el rumbo correcto o se est desviando en alguna direccin; tambin se puede utilizar la misma funcin 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. Adems se puede deducir la velocidad a la que se desplaza con exactitud, mientras se mantiene el rumbo en lnea 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, tambin posee errores, unos propios del sistema y otros intencionales, que son la principal fuente unitaria de error del sistema. No todos los aparatos GPS porttiles tienen suficiente memoria como para guardar rutas diarias y viajes pre-planificados. La seal del satlite pasa a travs de la atmsfera, encontrndose con la tropsfera y la ionsfera, las que afectan la onda produciendo un cambio de velocidad o retraso conocido con el nombre de refraccin.

3.6.2.1 Errores Intencionales.

Esta fuente de error se realiza con fines netamente estratgicos. El Gobierno de Estados Unidos decidi que deba incorporar distintos grados de error en las mediciones obtenidas por los receptores, por motivos de seguridad . Este gobierno gast 12.000 Millones de dlares para desarrollar el sistema de navegacin ms exacto del mundo, sin embargo, ahora est degradando intencionalmente su exactitud; esta poltica 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 ms exactos. Lo que se hace bsicamente 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 clculos de posicin. Otra forma es que el Departamento de Defensa enva datos orbitales ligeramente errneos a los satlites, que estos reenvan (transmitiendo el error) a los receptores GPS como parte de la seal que emiten.

3.6.2.2 Errores propios del sistema.

Los efectos asociados al satlite y su posicin contribuyen a alterar la medicin de distancia. El mensaje de transmisin est dado por la posicin instantnea del satlite y sus valores son predeterminados por las estaciones de control tierra. De este mensaje, llamado efemrides, se puede deducir dos tipos de error: Es imposible determinar con total exactitud la posicin del satlite porque las rbitas de stos estn influenciadas por la atraccin gravitacional, la que a su vez no ejerce una fuerza constante sobre dichos cuerpos. La medicin del tiempo es fundamental en la medicin de la distancia desde el satlite al Geo receptor; aunque los relojes utilizados son de alta calidad, no son totalmente perfectos.

Otro error se introduce cuando la seal del satlite pasa a travs de la atmsfera, encontrndose con la tropsfera y la ionsfera, las que afectan la

onda produciendo un cambio de velocidad o retraso conocido con el nombre de refraccin. La geometra de los satlites tambin podra afectar la medicin, este factor se conoce con el nombre de Dilucin de la Precisin. La calidad de la medicin depender de la disposicin de los satlites, si stos estn extremadamente juntos la medicin ser poco confiable, en cambio, cuando se encuentran bastante dispersos respecto al valor de la antena, esta ser una buena medicin. Es por esto que si dos receptores estn muy juntos el uno del otro, unos pocos cientos de kilmetros, la seal que alcanza a ambos viajar prcticamente a travs del mismo pasillo de atmsfera y por ello tendrn 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 transmisin por el cual se pueda transmitir en tiempo real o diferido, los datos desde el vehculo a la estacin 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 informacin recolectada es la red de telefona mvil. No es posible brindar el servicio de seguimiento de vehculos, sin contar con el servicio de transmisin de datos que otorgan las propias empresas mviles. Existen 3 grandes operadores de telefona mvil en nuestro pas: Movistar Claro ENTEL PCS. Estas Empresas proveen de servicio de voz, no necesariamente implica entregar servicio de transmisin de datos. En la prctica, las empresas que dan el servicio de posicionamiento global, deben recurrir a las empresas de telefona mvil que tambin proporcionan el servicio de transmisin de datos.

3.7 MERCADO NACIONAL.

Las principales empresas proveedoras del servicio GPS en Chile, son: Empresa GPS Chile ENTEL PCS PointPay MvilMaster Wisetrack Control ptimo Sitrack Internet Participacin de mercado 27% 20% 16% 13% 13% 4% 3% 3%

Fuente: Depto. Marketing MvilMaster 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 ao alcanz el 16% de participacin 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 mviles a incorporar, la extensin del contrato, si el cliente compra el dispositivo GPS o lo toma en comodato. Los contratos tpicos 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 clusulas de salida o con un aviso de 90 das. El modo de cobrar en comodato es un valor por la instalacin, su valor es de 2 UF + IVA y un servicio mensual que oscila entre las 0,8 y 1,1 UF + IVA por mvil/mes. Si el cliente compra el equipo los valores pueden bajar a 0,65UF + IVA mvil/mes.

3.8.2 Equipos utilizados en el mercado nacional Las marcas de equipos GPS ms utilizadas en el mercado nacional son: Virloc, Sky Patrol, Amphora, Antares, Webtech, MT, Portman.

3.9 Metodologa Empleada

Para el desarrollo del sistema se ha determinado utilizar la metodologa XP, cuyas principales caractersticas se detallan a continuacin:

3.9.1 Metodologa XP o Programacin Extrema

XP es un acrnimo del ingls Extreme Programming o Programacin Extrema que es su traduccin al espaol. Fue creada por el estadounidense Kent Beck a mediados de la dcada de los 90's y se trata de una disciplina que extrae diversas prcticas de otras metodologas 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 discusin si XP es una metodologa gil de desarrollo dentro de la ingeniera de software, o bien una disciplina o modelo de proceso de programacin, ya que no solo muestra los pasos a seguir en el desarrollo de software, sino que especifica la dinmica entre los actores y la operatividad del desarrollo del proyecto [BIB.XP1]. Sin embargo su popularidad ha ganado terreno por proponer un mtodo gil, adaptable y flexible a diferencia de las metodologas tradicionales. Una de las caractersticas principales de este mtodo 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 cmo se refuerzan los unos con los otros. El resultado de esta seleccin ha sido esta metodologa 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 dcadas ha forzado la evolucin 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 mtodos tradicionales no siempre tendrn que cumplir con los plazos que un cliente necesita, y no siempre los resultados finales de un producto terminado cubrirn las necesidades de un cliente, si las estrategias del negocio han cambiado y con ello los requerimientos. Resultado de esto, han surgido mtodos 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 ms exigente y un mercado cada vez ms dinmico. El enfoque que ha tenido las metodologas tradicionales en la ingeniera de software por aos ha servido para el desarrollo de sistemas de alta envergadura y criticidad, sin embargo con la masificacin de los computadores personales en el hogar y en la pequea y mediana empresa, los costos de desarrollo no avalan proyectos de negocios donde las necesidades y las estrategias cambian segn se mueve el mercado en el tiempo, por lo que los costos obligan a un cambio de enfoque para transformar y emplear innovadores mtodos de trabajo en favor de optimizar los costos en funcin del tiempo. [Fig 3].

Fig. 3 Diferencias de Enfoques [BIB.XP4]

Los mtodos 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 elaboracin coordinada e incremental del producto que se desea entregar. XP est basado en la iteracin o repeticin continua de procesos durante la realizacin del desarrollo de un proyecto de software, dndole movilidad y adaptabilidad a pesar de la disciplina con la que se lleva a cabo. Segn sus autores, la misin que fundamenta a XP detalla que:

El objetivo que se persegua en el momento de crear esta metodologa era la bsqueda de un mtodo que hiciera que los desarrollos fueran ms sencillos. Aplicando el sentido comn. [BIB.XP3] Los mtodos 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 an 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 ms de diez programadores. 4. Cuando existe una alta tasa de rotacin o renovacin dentro del equipo de desarrollo. 5. Cuando los cambios de requerimientos vienen en funcin 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 programacin extrema, al igual que el comn de los mtodos 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 gua en las especificaciones y requerimientos dentro de cada lnea base en la vida del proyecto. Los principios bsicos de esta metodologa se resumen en lo siguiente [BIB.XP6]: Participacin 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 disea 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 metodologa podra 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 frrea comunicacin y predisposicin al trabajo conjunto en el equipo de desarrollo. Exista un ordenado flujo de comunicacin entre cliente, jefe de proyecto y equipo de desarrollo. El equipo de desarrollo sea tolerante a la revisin y cambio de la programacin realizada por otro programador sobre del cdigo fuente propio. El equipo de desarrollo sea abierto y tolerante a los cambios frecuentes de los requerimientos o del diseo 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 ms 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 interacten con complejos sistemas o infraestructuras hardware/software. Donde no participen diversos equipos de desarrollo dispersos geogrficamente. Una de las cosas que los programadores deben tener en cuenta es que los cambios siempre estarn presentes en el ciclo de vida de un proyecto, cambiarn los requisitos, las reglas del negocio, el personal, la tecnologa, etc. Por lo tanto el problema no estar en el cambio en s, sino en la manera en que se debern 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]: Comunicacin: La comunicacin prevalece en todas las prcticas de XP, y ste fomenta la comunicacin. Comunicacin 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 comunicacin entre los desarrolladores y el cliente o el jefe de proyecto, se pueden realizar cambios que el cliente requiere o no le gustaron, tambin apoya la extensin del conocimiento tcito dentro del equipo de desarrollo, evitando la necesidad de mantener la documentacin escrita. Sencillez: Ayuda a los desarrolladores a encontrar soluciones ms simples a los problemas, tambin los ayuda a crear caractersticas en el diseo que puedan ayudar a resolver problemas a futuro. La sencillez en el cdigo tambin ayuda a la comunicacin y a la documentacin, mientras ms sencillo sea el cdigo, menos necesidad se tendr de explicar y comunicar de l. Retroalimentacin: La retroalimentacin continua del cliente permite a los desarrolladores llevar y dirigir el proyecto en una direccin correcta hacia donde el cliente quiera. La retroalimentacin acta junto con la sencillez y la comunicacin, cuanto mayor retroalimentacin ms fcil es la comunicacin. Cuanto ms simple un sistema ms fcil de probar. Escribir pruebas nos orienta como simplificar un sistema, hasta que las pruebas funcionen, cuando las pruebas funcionen tendr mucho avance echo. Valenta: Asumir retos, ser valientes antes los problemas y afrontarlos. Si el cdigo es engorroso, no se debe terminar odindolo y odiando al sistema, esto trae como consecuencia, una entropa 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 metodologa ayuda a ese cambio. La valenta se extiende tambin para los gerentes o empresarios que financian estos proyectos, puesto que si una de las prcticas 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 aplicacin que suele ser

programado y revisado por una persona y no por dos. Tal como se puede representar en la figura 4, la programacin extrema propone una serie de prcticas que los integrantes del equipo debern adoptar, estos se agrupan en cuatro categoras, los cuales determina el funcionamiento especfico que se debe emplear al momento de programar [BIB.XP8]:

Fig. 4 Esquema Conceptual Metodologa XP [BIB.XP5]

1.- Retroalimentacin a escala fina El principio de pruebas: se tiene que establecer un perodo de pruebas de aceptacin del programa (llamado tambin perodo de caja negra) donde se definirn las entradas al sistema y los resultados esperados de estas entradas. Proceso de planificacin: 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, sealar las prioridades y responder las preguntas de los programadores. Programacin en parejas: uno de los principios ms radicales y en el que la mayora de gerentes de desarrollo pone sus dudas. Requiere que todos los programadores XP escriban su cdigo en parejas, compartiendo una sola mquina. 2.- Proceso continuo 1. Integracin continua: permite al equipo hacer un rpido progreso implementando las nuevas caractersticas del software. 2. Refactorizacin: permite a los equipos de programadores XP mejorar el diseo del sistema a travs de todo el proceso de desarrollo. 3. Entregas pequeas: colocan un sistema sencillo en produccin rpidamente que se actualiza de forma rpida y constante permitiendo que el verdadero valor de negocio del producto sea evaluado en un ambiente real. 3.- Entendimiento compartido Diseo simple: se basa en la filosofa de que el mayor valor de negocio es entregado por el programa ms sencillo que cumpla los requerimientos. Simple Design se enfoca en proporcionar un sistema que cubra las necesidades inmediatas del cliente, ni ms ni menos. Metfora: desarrollada por los programadores al inicio del proyecto, define una historia de cmo funciona el sistema completo. Propiedad colectiva del cdigo: un cdigo con propiedad compartida. Nadie es el propietario de nada, todos son el propietario de todo. Estndar de codificacin: define la propiedad del cdigo compartido as como las reglas para escribir y documentar el cdigo y la comunicacin entre diferentes piezas de cdigo desarrolladas por diferentes equipos.

4.- Bienestar del programador La semana de 40 horas: la programacin extrema sostiene que los programadores cansados escriben cdigo de menor calidad. De acuerdo a estas prcticas, el equipo de desarrollo que adopte XP, sus actividades se centrarn principalmente en estas cuatro: Codificar: Es necesario codificar y plasmar las ideas a travs del cdigo. En programacin, el cdigo expresa la interpretacin del problema, as se puede utilizar el cdigo 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 tena en mente. Tambin 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: Segn una afirmacin 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 querran?". Es importante escuchar a los clientes acerca de cules 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 realimentacin entre ambos ayuden a entender los problemas de una forma objetiva. Disear: El diseo crea una estructura que organiza la lgica del sistema, un buen diseo permite que el sistema crezca con cambios en un solo lugar. Los diseos deben de ser sencillos, si alguna parte del sistema es de desarrollo complejo, lo apropiado es dividirla en varias. Si hay fallos en el diseo o malos diseos, estos deben de ser corregidos cuanto antes. En resumen, segn las actividades que propone XP, se deduce que es necesario codificar porque sin cdigo 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 disear para poder codificar, probar y escuchar indefinidamente. La decisin de adoptar una metodologa 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. Tambin establece que de estas cuatro variables, solo tres de ellas podrn 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 mquinas ms rpidas, mas especialistas tcnicos 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 metodologas para implementar software, es mucho ms barato, debido a que las pruebas se van haciendo segn las versiones liberadas, no es como una metodologa normal, en que primero se realiza el anlisis, despus el diseo, implementacin, pruebas y finalmente produccin, 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 aumentarn el tiempo de realizacin mientras que la optimizacin y la inversin pueden acortarlo. Calidad: Puede representar un cambio extrao; debido a que a mayor calidad menor tiempo de realizacin 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 cul 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 cdigo lo que hace este proceso ms rpido. mbito: Es la que se encuentra libre es el alcance del proyecto, en la cual el equipo determina: la estimacin de las tareas a realizar, que es lo que el cliente quiere, la implementacin de los requisitos ms importantes de manera que este siempre sea funcional.

Todas las metodologas tienen limitantes y los mtodos giles no son la excepcin, stos son apropiados para algunos tipos de desarrollo de sistemas. Son ms idneos para sistemas de negocios pequeos y de tamao medio, como tambin 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 crticos, donde es necesario un anlisis detallado de todos los requerimientos del sistema para comprender sus implicaciones de seguridad o proteccin.

3.9.2 Uso prctico de la metodologa XP en el Proyecto.

Todo proyecto guarda incertidumbres en su desarrollo y evolucin, y no est exento de problemas. Depende mucho de la conformacin de un equipo de trabajo y su disposicin de seguir una disciplina estricta y puntual. Incluso si los programadores ms experimentados y disciplinados estn dispuestos a someterse a una disciplina impuesta por una metodologa, siempre existen los riesgos que esta no rinda los frutos esperados o simplemente no funcione. El trabajar en equipo, es tan difcil 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 podran tener una visin tan clara sobre su equipo, como para saber de antemano si una tarea es apropiada o no para un programador u otro. Pero an as un jefe de proyecto podra no ser asertivo en elegir una metodologa u otra, o de seleccionar un programador para su equipo. La clave est en no aplicar de una manera estricta una metodologa sobre un grupo que recin comienza a conformarse y cuya adaptacin puede tomar un tiempo arriesgado para cualquier proyecto, sino que ms bien, adaptar una metodologa a un orden que recin comienza a funcionar dentro de un grupo. El trabajo en parejas, quizs sea una de las tareas ms difciles de conseguir dentro de un grupo de trabajo, pocos programadores pueden estar abiertos a compartir su trabajo y estar sometidos a opiniones y crticas sobre su forma individual de trabajar, y es precisamente porque cada programador es un individuo que razona y acta 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 ms rpido una versin 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 comn, si se trabaja con un grupo disperso de personas, sea difcil consolidar un equipo de desarrollo, donde el trabajar reunidos en forma presencial sea tambin requerido. Sin embargo, si se puede realizar sutiles cambios a una metodologa, donde el trabajar reunidos en

forma presencial, pueda realizarse de manera virtual, es ms valiosa la contribucin de esta adaptacin para el xito de un proyecto. Una solucin viable para esta problemtica es la de compartir los programas fuentes por medio de un repositorio de cdigo fuente comn 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 cdigo 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 nmero 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 cdigo 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 rpido, fiable y sencillo que permite: Crear proyectos instantneos sobre cualquier tema. Alojar cdigo de Subversin con un 1 gigabyte de espacio de almacenamiento y admitir alojamiento para descargas con 2 gigabytes de espacio de almacenamiento.

Consultar cdigo fuente integrado y utilizar herramientas de revisin de cdigo para facilitar la visualizacin de cdigo, la revisin de contribuciones y el mantenimiento de una base de cdigo de gran calidad. Realizar un seguimiento de problemas y bsquedas 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 pginas previo registro. Posee una extensa documentacin sobre su uso y nos permite crear aplicaciones basadas en la tecnologa de Google Maps, cuyo nico lmite es nuestra imaginacin y talento para programar.

Caractersticas 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 direccin para moverse a la ubicacin que desee. Los resultados de la bsqueda pueden ser restringidos a una zona, gracias a Google Local. Como otros servicios de mapa, Google Maps permite la creacin de pasos para llegar a alguna direccin. Esto permite al usuario crear una lista paso a paso para saber el cmo 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 direccin http://localhost y con esta hagamos los ajustes necesarios y una vez que nuestro cdigo est listo cambiar la API Key por la de nuestro sitio en Internet para publicar la pgina.

3.10 Tecnologas Empleadas.

3.10.1 Arquitectura de la solucin Un nodo GPS en circulacin, enviar peridicamente una seal que ser recibida por una antena de estacin Base de telefona celular (BTS), esta se comunicar a travs 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 informacin en paquetes TCP que sern enviados a la red Internet.

Fig. 5 Arquitectura de la solucin

Estos paquetes TCP, sern capturados por una aplicacin servidora, que se encargar de segmentarlos y almacenarlos en una base de datos, haciendo referencia a los nodos que lo emitieron.

El sistema de supervisin de los nodos GPS, se encargar de proveer al usuario las herramientas necesarias, para la gestin de los vehculos que las portan por medio de una interfaz Web intuitiva y amigable.

3.10.2 TECNOLOGA DE DESARROLLO

Herramienta de desarrollo: PHP 5; Java Standard Edition. Base de datos: Servidor: MySQL. Apache 2

Captulo 4. DEFINICIN DEL PROYECTO

Desarrollar un sistema de reporte en lnea que apoye el de vehculos de transporte. monitoreo

4.1 ALCANCE
Desarrollar e implementar un sistema con interfaz grfica que, mediante los elementos de captura y seguimientos utilizados por la tecnologa GPS, que permita desplegar en lnea la posicin de un mvil en un momento y posicin determinados, y capturar y entregar de informacin de posicionamiento, tiempo de detencin y consumo de combustible realizado por el mvil para llegar desde un punto inicial a un punto determinado. Entregar la informacin mediante alarmas previamente programadas, a partir de la informacin de posicionamiento capturada por los dispositivos GPS incorporados en el mvil. Capacitar al equipo tcnico en la plataforma que se utilizar para el diseo e implementacin de la solucin. Ejecutar un plan de capacitacin sobre el uso de la solucin construida. El sistema a desarrollar solo incorporar las funcionalidades que permitan cumplir con los entregables descritos en el captulo 5, (producto que se entregar), y que bsicamente posibilitan entregar una visin de la tecnologa GPS, sus potencialidades y su estado actual de aplicacin mediante el desarrollo de un sistema informtico.

4.2 DETALLE DE LA SOLUCIN

Disear una interfaz grfica para despliegue de informacin de posicionamiento del (los) mviles a monitorear. Disear los procedimientos y flujos de captura de informacin desde los dispositivos receptores GPS Disear y construir una base de datos para almacenar la informacin capturada Definir los parmetros de entrada y condiciones de monitoreo y captura de informacin desde los mviles. Disear reportes de informacin estadstica generada durante los perodos 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 informacin. Entregar sistema construido y capacitar sobre su operacin y manejo al cliente final.

4.3 ENTREGABLES.
Responsabl e Analista de Procesos, Analista de Sistemas. Criterio de Aceptacin

Entregable Aplicacin grfica que permita visualizar la ubicacin geogrfica de los mviles Reportes de gestin del control de la flota de vehculos Conjunto de alertas que se generen a partir de la ubicacin geogrfica de los vehculos Primer Informe de avance de la solucin

Descripcin Documento con la descripcin de las funcionalidades del sistema desarrollado Documento con la descripcin de los informes que generar el sistema. Informes o avisos de estado generados de acuerdo a parmetros de entrada previamente definidos. Presentacin inicial del sistema a desarrollar, su objetivo, funcionalidades y caractersticas. Presentacin del estado de avance del desarrollo del sistema.

Fecha
17-03-2010

18-03-2010

Analista de Sistemas.

18-03-2010

Analista de Sistemas,

20-03-2010

Jefe de Proyectos, Analista de Sistemas.

Segundo Informe de avance de la solucin

22-03-2010

Analista de Sistemas, Analista de Procesos, Analista QA

Debe cumplir con los parmetros de evaluacin de la asignatura de Seminario de integracin. Debe cumplir con los parmetros de evaluacin de la asignatura de Seminario de integracin.

Entregable Resultados de las pruebas y validaciones del sistema

Descripcin Documento con los resultados de pruebas y validaciones realizadas a la aplicacin desarrollada. Planificacin de la Induccin y Capacitacin de los usuarios del sistema Informe con el detalle de sistema desarrollado.

Fecha
08-04-2010

Responsabl e Analista de Sistemas, Programador de Aplicaciones, Analista QA. Jefe de Proyecto

Criterio de Aceptacin Pruebas aprobadas.

Capacitacin a usuarios y operadores del sistema

13-04-2010

Informe Final de proyecto

22-04-2010

Seguimiento de la Operacin

Reporte estadstico sobre el uso del sistema.

29-04-2010

Plan de induccin y capacitacin con fechas y plazo acordados con usuario final. Jefe de Debe cumplir Proyecto, con los Analista de parmetros de Sistemas, evaluacin de la Desarrollador asignatura de , Analista QA. Seminario de integracin. Jefe Proyecto No aplica.

4.4 ROLES y RESPONSABILIDADES.

Rol Responsabilidades Gestiona administrativamente la ejecucin del proyecto. Realiza seguimiento a las actividades. Coordina y organiza reuniones con el equipo de implementacin, cliente y usuarios finales de la solucin. Gestiona y coordina el traspaso a produccin de la solucin. Recolecta informacin relacionada al uso del GPS y evala principales marcas de equipamiento para anlisis de costos. Revisa, analiza, redisea y normaliza el procedimiento de implantacin del sistema. Recomienda cambios y/o modificaciones al diseo del sistema, de acuerdo a necesidades planteadas por el usuario/cliente final. Documenta el sistema diseado. Disea la aplicacin, incluyendo la interfaz grfica. Documenta el diseo de la solucin. Crea y evala los resultados del plan de pruebas de la solucin. Realiza induccin y capacitacin en el uso de la solucin a los usuarios. Tiempo Requerido (Horas)
Responsable

Jefe de Proyecto

35

Eduardo Acosta

Analista de Procesos

32

Marjorie Ccopa

Analista de Sistemas

28

Miguel Vargas

Rol

Responsabilidades Desarrolla la aplicacin de acuerdo a detalle tcnico funcional entregado por el analista de sistemas. Implementa las validaciones y estndares de calidad que aseguren la solidez de la aplicacin desarrollada Aplica el plan de pruebas a la solucin. Crea manual conciso del usuario. Valida y sugiere modificaciones al sistema desarrollado, con el propsito de asegurar la calidad y cumplimiento de estndares bsicos de calidad que debe cumplir para poder comercializarlo en el mercado.

Tiempo Requerido (Horas)

Responsable

Programa dor /Desarroll ador

129

Gabriel Muoz

Analista QA

24

Andrs Basez

4.5 SUPUESTOS, RIESGOS, DEPENDENCIAS, RESTRICCIONES

Supuestos: 1. La plataforma de infraestructura y software a utilizar en la implementacin son open source. 2. Se dispone de los recursos tcnicos y de equipamiento para dejar el sistema funcionando. 3. Los plazos han sido definidos ajustndose a los plazos definidos por la asignatura de Seminario de Integracin. 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 implementacin del sistema, considera que existe y se encuentra operativo el servicio GPS 2. La interfaz grfica a desarrollar debe estar alineada con el estndar grfico del mercado de GPS. Restricciones: 1. Los recursos asignados al trabajo tendrn aproximadamente un 40% de dedicacin al proyecto.

4.6 ESTIMACIN DE RECURSOS/ HORAS.

Rol Jefe de Proyecto Analista de Procesos Analista de Sistemas Programador de Aplicaciones Analista QA Expertise/Nivel Profesional/Alto Profesional/Medio Profesional/Medio Profesional/Medio Profesional/Bajo Horas 35 32 28 129 24

Captulo 5: DISEO.
5.1 Modelamiento.
El modelo de requerimientos es un catlogo estructurado de requerimientos del usuario final. Estos estn representados como requisitos o elementos de caractersticas.

custom Requirements Model

The Requirements model is a structured catalogue of end-user requirements. These are represented as either Requirement or Feature elements. The model is divided into two sub-catalogues: 1. The Functional requirements package contains requirements and features that represent functional behavior and features that 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 funcionales + Historias de Usuario + Caracteristicas + Interfaz de Usuario

The Functional Requirements package details behavioral requirements that specify how a proposed system will process and handle information. It details the features and rules that must be present to fully implement the functionality desired.

Requerimientos no-funcionales + Performance + Scalability + Security

Read about Requirements Tracing element dependencies Using the Relationship Matrix

+ Persistence + Transport

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-categoras: 1. El paquete contiene los requisitos funcionales de las caractersticas 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 features, behavior, business rules and general functionality that the proposed system must support. + Alarma de Vehiculo Detenido + Alarmas de Velocidad + Busqueda de Vehiculos + Gestor de Alarmas + Indicadores + Monitoreo General de Vehiculos + Reporte de velocidad maxima + Reporte Vehiculo Detenido + Reportes + Trazar Ruta Vehiculo

Caracteristicas + Base de datos MySQL + PHP5 + API Google Maps

Interfaz de Usuario + Pantalla Principal + Reporte de Velocidad + Reporte Vehiculo Detenido

Fig. 7 Requerimientos Funcionales

Los requerimientos funcionales describen las caractersticas, comportamiento, reglas del negocio y la funcionalidad general que el sistema propuesto debe soportar.

5.2 Historias De Usuario.

Segn la metodologa XP, las historias de usuario son la base para la planificacin y definicin de las pautas necesarias para la construccin del sistema propuesto. Estas son definidas por el usuario final o cliente y en ellas se detalla el comportamiento que debe tener cada mdulo o componente de la aplicacin segn el punto de vista del usuario. Con estas descripciones, se modelarn los casos de uso.

custom Historias de Usuario Monitoreo General de Vehiculos

Reportes

Busqueda de Vehiculos

T razar Ruta Vehiculo

Gestor de Alarmas

Indicadores

Alarma de Vehiculo Detenido

Alarmas de Velocidad

Reporte Vehiculo Detenido

Reporte de velocidad maxima

The Business Rules package is a catalogue of 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 Vehculo Detenido. Esta alarma se debe disparar cuando un vehculo queda detenido por un tiempo superior al definido por parmetros del sistema, en jornada de transporte.

Historia de Usuario Nmero: 7 Usuario: Supervisor Riesgo en Desarrollo: ALTA Estimacin de Esfuerzo: 4 Nombre Historia: Alarma de Vehculo Detenido. Prioridad en Negocio: MEDIA Iteracin Asignada: 2

Programador Responsable: Gabriel Muoz

Alarma de Velocidad. Esta alarma se deber disparar cuando un vehculo exceda el umbral de velocidad permitida definido por parmetros de sistema para un vehculo. Historia de Usuario Nmero: 8 Usuario: Supervisor Riesgo en Desarrollo: ALTA Estimacin de Esfuerzo: 4 Nombre Historia: Alarmas de Velocidad. Prioridad en Negocio: MEDIA Iteracin Asignada: 2

Programador Responsable: Gabriel Muoz

Bsqueda de Vehculos. El supervisor accede a un men desplegable y selecciona de un listado del o los vehculos sobre los que desear realizar el seguimiento. Historia de Usuario Nmero: 2 Usuario: Riesgo en Desarrollo: BAJA Estimacin de Esfuerzo: 3 Nombre Historia: Bsqueda de Vehculos. Prioridad en Negocio: ALTA Iteracin Asignada: 1

Programador Responsable: Gabriel Muoz

Gestor de Alarmas. El sistema deber correr de forma peridica un gestor que consulte los indicadores y despliegue ventanas de alarmas cuando se vayan presentando los eventos que disparen dichos indicadores. Historia de Usuario Nmero: 4 Usuario: Supervisor Riesgo en Desarrollo: ALTO Estimacin de Esfuerzo: 5 Nombre Historia: Gestor de Alarmas. Prioridad en Negocio: MEDIA Iteracin Asignada: 2

Programador Responsable: Gabriel Muoz

Indicadores. Se debe realizar consultas peridicas sobre la base de datos y analizar la comparacin de estos datos con umbrales y parmetros definidos en el sistema para gatillar indicadores. Historia de Usuario Nmero: 1 Usuario: Supervisor Riesgo en Desarrollo: ALTA Estimacin de Esfuerzo: 5 Nombre Historia: Indicadores Prioridad en Negocio: BAJA Iteracin Asignada: 3

Programador Responsable: Miguel Vargas

Monitoreo General de Vehculos. El supervisor observa en pantalla los vehculos que actualmente circulan por el pas. Debe realizar acercamientos con la herramienta de Zoom para visualizar el detalle de los vehculos por las calles o carreteras y con ayuda del mouse, arrastrar el mapa para recorrer las calles. Historia de Usuario Nmero: 1 Usuario: Riesgo en Desarrollo: ALTA Estimacin de Esfuerzo: 5 Nombre Historia: Monitoreo General de Vehculos. Prioridad en Negocio: ALTA Iteracin Asignada: 1

Programador Responsable: Gabriel Muoz Reporte de Vehculo Detenido. Este reporte deber desplegar un listado de los vehculos que quedan detenidos en horarios de trabajo, mostrando la hora y coordenadas donde fue registrado el evento. Historia de Usuario Nmero: 5 Usuario: Supervisor Riesgo en Desarrollo: MEDIA Estimacin de Esfuerzo: 3 Nombre Historia: Reporte Vehculo Detenido. Prioridad en Negocio: ALTA Iteracin Asignada: 2

Programador Responsable: Miguel Vargas

Reporte de velocidad mxima. Este reporte deber desplegar un listado de los vehculos 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 instantnea. Historia de Usuario Nmero: 6 Usuario: Supervisor Riesgo en Desarrollo: MEDIA Estimacin de Esfuerzo: 3 Nombre Historia: Reporte de velocidad mxima. Prioridad en Negocio: ALTA Iteracin Asignada: 2

Programador Responsable: Miguel Vargas

Reportes. El Supervisor podr acceder a un repertorio de vnculos que hacen referencia a los reportes en lnea del sistema. Al hacer click sobre los vnculos, se abrir un cuadro de dilogo 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 Nmero: 3 Usuario: Supervisor Riesgo en Desarrollo: BAJO Estimacin de Esfuerzo: 2 Nombre Historia: Reportes. Prioridad en Negocio: BAJA Iteracin Asignada: 2

Programador Responsable: Miguel Vargas

5.3 Caractersticas
Caractersticas tcnicas de las herramientas utilizadas en el desarrollo del sistema.
custom Caracteristicas

Features typically describe discrete pieces of functional behavior that yield a specific result.

API Google Maps

Base de datos MySQL

PHP5

Fig. 9 Caractersticas

Base de datos MySQL. La base de datos utilizada ser MySQL 5.1 o en su ltima versin. PHP5. El lenguaje de programacin ser PHP5. API Google Maps. El sistema usar la API de Google Maps para el despliegue y bsqueda de vehculos

Interfaz de Usuario. El modelo de interfaz de usuario define las pautas para la implementacin de la representacin de informacin 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 descriptions of end-user visible screens and forms which are required to support the proposed system. Busqueda Vehiculos Reportes UI Controls model various common user interface control types navigate Reporte de Velocidad navigate Reporte Vehiculo Detenido Screen elements model proposed user interface components.

GMaps

Reporte Velocidad

Reporte Vehiculo Detenido

Fig. 10 Interfaz de Usuario

Pantalla Principal. Esta interfaz representa el mdulo principal por el cual el usuario acceder a las diversas funcionalidades del sistema.

Reporte de Velocidad Este reporte, desplegar un listado de aquellos vehculos que exceden la velocidad mxima permitida para un vehculo dado.

Reporte Vehculo Detenido Este reporte desplegar un listado de aquellos vehculos que quedan detenidos en terreno durante horarios de produccin.

5.4 Modelo de Casos de Uso.

El Modelo de Casos de Uso es fundamental para la planificacin de un proyecto para la metodologa XP, sienta las bases para el comportamiento de una aplicacin a desarrollar segn las necesidades y requerimientos del cliente. 5.4.1 Modelo de Casos de Uso - (Use Case diagram) En estos casos de uso, se describirn los modelos de comportamiento de la aplicacin definido en los requerimientos de sistema.
uc Modelo de Casos de Uso Caso de uso Principal + Alertas + Autenticar + Buscar Vehiculo + Desplegar Ubicacin + Obtener Reporte Administracion + Editar Vehiculo + Ingresar Vehiculo + Listar Vehiculos + Respaldar Datos Serv idor Sistema Recepcion Datos + Conectar Servidor Socket T CP + Grabar Informacion + Iniciar Cliente Datos + Recibir Datos GPS + Transformar Datos

Serv idor Sistema Alerta + Enviar Alertas y Registro + Recibir Datos + Registrar Datos + T ransformar Datos + Verificar Alertas

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

Fig. 11 Modelo de Casos de Uso

5.4.2 Actores - (Use Case diagram).

Aqu se describirn los distintos actores del sistema, las responsabilidades que competen a cada perfil de usuario o de entidad que interacta con el sistema.
uc Actores

Usuario

GPS

Base Datos

Superv isor

Administrador

Fig. 12 Actores

Administrador. Usuario responsable de la configuracin de los vehculos, patrones y parmetros del sistema. Base Datos. Actor intrnseco del sistema, encargado de proveer y registrar informacin.

GPS. Actor responsable de proveer peridicamente las coordenadas de cada elemento configurado en el sistema. Supervisor. Usuario encargado de realizar consultas y explotacin del sistema. Usuario. Este actor es general para la autenticacin 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 generacin de alertas en lnea cuando un vehculo se detiene en horas de produccin.
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: ACTORES: PROPSITO: DESCRIPCIN: TIPO: PRE CONDICIN: POST CONDICIN: PASOS: ALTERNATIVAS:

Alerta Horas Usuario, Base Datos Generar alertas cuando un vehculo se detiene Este caso de uso describe las acciones necesarias para la generacin de alertas en lnea cuando un vehculo se detiene en horas de produccin. BAJA Recibir fecha como parmetro. No existe Proveer fecha

Desplegar va 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 generacin de alertas en lnea cuando un vehculo exceda la velocidad permitida, durante el trayecto en su jornada.
uc Alerta Velocidad Alerta Velocidad

AccederSistema Alertas

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

Desplegar v ia Web

Fig. 14 Alerta de Velocidad.

CASO DE USO: ACTORES: PROPSITO: DESCRIPCIN:

Alerta Velocidad Usuario, Base Datos Generar alertas cuando un vehculo excede una velocidad mxima Este caso de uso describe las acciones necesarias para la generacin de alertas en lnea cuando un vehculo excede la velocidad permitida, durante el trayecto en su jornada. BAJA Recibir fecha como parmetro No existe

TIPO: PRE CONDICIN: POST CONDICIN:

CASO DE USO: PASOS: ALTERNATIVAS:

Alerta Velocidad Proveer fecha

Desplegar va 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 lnea en funcin de los eventos que se crearn durante la explotacin del sistema.

uc Configurar Alerta Configurar Alertas

Autentificar

Seleccionar Vehiculo

include Administrador (from Actores) Mostrar Alertas

Base Datos (from Actores)

Gestionar Alertas

Fig. 15 Configurar Alerta

CASO DE USO: ACTORES: PROPSITO: DESCRIPCIN:

Configurar Alerta Administrador, Base Datos Configurar intervalos de hora y velocidad mxima por vehculo 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 lnea en funcin de los eventos que se irn generando durante la explotacin del sistema. BAJA

TIPO:

CASO DE USO: PRE CONDICIN: POST CONDICIN: PASOS: ALTERNATIVAS:

Configurar Alerta Seleccionar un vehculo No existe Listar vehculos, seleccionar una fila, editar las columnas

Autentificar. Caso de uso responsable del inicio de sesin de un usuario del sistema. Gestionar Alertas. Caso de uso responsable de la edicin y registro de la configuracin de la alerta. Mostrar Alertas. Caso de uso responsable del despliegue de las alertas generadas a la pantalla del usuario. Seleccionar Vehculo. Caso de uso responsable de la seleccin de vehculos desplegados.

5.4.6 Servidor Sistema Alerta - (Use Case diagram)

Este caso de uso describe el comportamiento del Sistema de Alertas, una aplicacin residente y servidora encargada de la recepcin, captura y transformacin 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 (from Actores)

Verificar Alertas

Env iar Alertas y Registro

Fig. 16 Servidor Sistema de Alerta

CASO DE USO: ACTORES: PROPSITO:

Servidor Sistema de Alerta Usuario, Base Datos Extraer de los paquetes del GPS la informacin til para las alertas

CASO DE USO: DESCRIPCIN:

Servidor Sistema de Alerta Este caso de uso describe el comportamiento del Sistema de Alertas, una aplicacin residente y servidora encargada de la recepcin, captura y transformacin de los paquetes enviados por los nodos GPS para ser almacenados en la base de datos y posteriormente ser notificados al usuario. ALTA Libre No existe Aplicacin residente en memoria, se activa automticamente por S.O.

TIPO: PRE CONDICIN: POST CONDICIN: PASOS: ALTERNATIVAS:

Enviar Alertas y Registro. Caso de uso responsable del despacho de la notificacin 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 generacin de alertas.

5.4.7 Servidor Sistema Recepcin Datos - (Use Case diagram)

En este caso de uso, la precondicin parte con el inicio de conexin al Servidor Socket TCP, para luego iniciar la conexin a la Base de Datos, solo as se podrn recibir los datos desde el nodo GPS y su posterior segmentacin, transformacin 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 (from Actores) Recibir Datos GPS

Base Datos (from Actores)

Transformar Datos

Grabar Informacion

Fig. 17 Servidor Sistema de Recepcin de Datos

CASO DE USO: ACTORES: PROPSITO: DESCRIPCIN:

Servidor sistema de Recepcin de Datos GPS, Base Datos Captura de paquetes, transformacin y almacenamiento de datos en BD. Este caso de uso, levanta la conexin el Servidor Socket TCP, para luego iniciar la conexin a la Base de Datos, solo as se podrn recibir los datos desde el nodo GPS y su posterior segmentacin, transformacin y almacenamiento en la Base de Datos. ALTA Permiso de acceso No existe Aplicacin residente en memoria, se activa automticamente por S.O.

TIPO: PRE CONDICIN: POST CONDICIN: PASOS: ALTERNATIVAS:

Conectar Servidor Socket TCP. Este caso de uso tiene la responsabilidad de iniciar la conexin con el Servidor Socket TCP, que gestiona el puerto que recepciona los paquetes del GPS. Grabar Informacin. 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 conexin 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 informacin 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 monitorizacin de alarmas y a los mapas de ubicacin de los vehculos.

uc Caso de uso principal Monitorear Vehiculo

Autenticar

include

Buscar Vehiculo

Alertas Usuario

Base Datos

include

include

Obtener Reporte

Desplegar Ubicacin

Fig. 18 Caso de Uso Principal

CASO DE USO: ACTORES: PROPSITO: DESCRIPCIN:

Caso de uso principal Usuario, Base Datos Proveer la gestin para la monitorizacin de vehculos en trnsito Este caso de uso es responsable de proveer al usuario la funcionalidad del sistema, proveyendo los accesos a los reportes, paneles de la monitorizacin

CASO DE USO: TIPO: PRE CONDICIN: POST CONDICIN: PASOS: ALTERNATIVAS:

Caso de uso principal de alarmas y a los mapas de ubicacin de los vehculos. ALTA Inicio de sesin de usuarios No existe Iniciar la sesin de usuario

Alertas. Caso de uso responsable del despliegue de alertas en lnea con registros ingresados recientemente del servicio de recepcin de paquetes GPS. Autenticar. Caso de uso responsable del inicio de sesin 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 sesin 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

Autenticacin. 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 autenticacin, donde el usuario ingresa su cuenta y contrasea.

Usuarios.
Esta entidad es la interfaz hacia la base de datos que evala la real identidad del usuario que intenta ingresar.

Buscar Vehculo. Caso de uso responsable de la bsqueda y seleccin de un vehculo para su utilizacin dentro del sistema.

5.4.8.2 Buscar Vehculo - (Sequence diagram)

Este diagrama de secuencia describe los pasos de bsqueda de un vehculo para su utilizacin dentro del sistema, tanto en operaciones diversas como en reportes.
sd Buscar Vehiculo

Usuario

Formulario Busqueda BuscarVehiculo(patente)

Busqueda

Vehiculos

Base Datos

BuscarVehiculo(patente)

TraerVehiculo(patente) BuscaVehiculo(patente)

(from Actores)

(from Actores)

Fig. 20 Buscar Vehculo

8. Bsqueda.
Este controlador redirige el flujo de la consulta y respuesta entre el formulario y la interfaz a la base de datos.

Formulario Bsqueda. Esta vista corresponde al formulario de bsqueda, donde el usuario provee una patente, o la selecciona desde un listado de vehculos existentes.

Vehculos.

Esta entidad corresponde a la interfaz que se encarga de buscar el vehculo con la patente recibida. Desplegar Ubicacin. Caso de uso responsable de desplegar la ubicacin del vehculo en el mapa.

5.4.8.3 Desplegar Ubicacin - (Communication diagram)

En este diagrama de actividades, el usuario recurre a la vista "Desplegar Mapa", para consultar el posicionamiento del vehculo, y este controlador redirige el flujo de la consulta a la entidad "Vehculos" para obtener sus coordenadas en la "Base de Datos". Alternativamente, la vista "Desplegar Mapa" tambin recurre al controlador "Trazar Ruta" para redirigir la consulta a "Vehculos" por el tramo recorrido, retornando la secuencia de coordenadas para el posterior despliegue de la ruta.

sd Desplegar Ubicacin Flujo de actividad para despliegue de ubicacin

Posicionar Vehiculo

Buscar Vehiculo flow

T ramoRecorrido Desplegar Mapa Usuario (from Actores) SecuenciaCoordenadas Vehiculos Base Datos (from Actores)

Trasar Ruta

Fig. 21 Desplegar Vehculo

Desplegar Mapa. Esta vista ser la interfaz directa al usuario, donde podr solicitar al sistema la consulta sobre la ubicacin del vehculo, o bien trazar la ruta del trayecto que ha tenido un vehculo en un momento determinado.

4. Posicionar Vehculo.
Este controlador, redirige la consulta de posicionamiento que hace el usuario desde el mapa y lo solicita a la entidad vehculos. Trazar Ruta. Este controlador recibe la solicitud del usuario para la consulta del tramo recorrido de un vehculo y redirige la consulta a la entidad Vehculos. Asimismo recibe en respuesta la secuencia de coordenadas para que la vista Desplegar Mapa lo dibuje para el usuario. Vehculos. 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 Mxima, Vehculo Detenido, Historial y Distancia Recorrida.

5.4.9 Administracin - (Use Case diagram)

En este caso de uso, el administrador podr tener control y gestin de la configuracin del sistema.

uc Administracion Administracion Datos

Autenticar

(from Caso de uso Principal) include include

Listar Vehiculos

Administrador (from Actores) include

include

Base Datos (from Actores)

Editar Vehiculo Ingresar Vehiculo

Respaldar Datos

Fig. 22 Administracin

CASO DE USO: ACTORES: PROPSITO: DESCRIPCIN: TIPO: PRE CONDICIN:

Administracin Administrador, Base Datos Proveer las herramientas de mantenimiento de configuracin al administrador En este caso de uso, el administrador podr tener control y gestin de la configuracin del sistema. BAJA El usuario debe estar identificado como administrador

CASO DE USO: PASOS: ALTERNATIVAS:

Administracin Iniciar sesin de usuario administrador

POST CONDICIN: No existe

Editar Vehculo Este caso de uso es responsable de la edicin y modificacin de datos de un vehculo en la base de datos. Ingresar Vehculo Este caso de uso es responsable del ingreso de un vehculo a la base de datos. Listar Vehculos. Este caso de uso es responsable de disponer para el usuario el listado de vehculos para su uso en la gestin 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 prxima versin del sistema donde se contempla la gestin de eventos que se generarn a partir del comportamiento de los vehculos en funcin del tiempo.

Fig. 23 Modelo de Datos sistema de control y posicionamiento de vehculos va GPS.

Descripcin 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 razn de 15 segundos aproximadamente. Guarda adems los datos de la geoposicin de los nodos que notifican su ubicacin, la fecha, hora del registro, lugar e identidad del vehculo en circulacin.

10. ALERTAS: Corresponde a una tabla de configuracin, en ella de definen en forma descriptiva los tipos de alertas que se gestionarn en el sistema. 11. ALERT_HORA: Esta es una tabla de configuracin y est estrechamente vinculada con la tabla ALERTAS, y en ella se configuran los horarios de inicio y trmino de la jornada de trabajo. 12. ALERT_VEL: Esta es una tabla de configuracin vinculada con la tabla ALERTAS, en ella se configura la velocidad mxima que puede tener un vehculo. 13. USUARIOS: Esta tabla almacena la configuracin de los usuarios que pueden acceder y hacer uso del sistema, como tambin al personal que tendr asignado uno o ms vehculos a ser monitorizados en el sistema. 14. USERAUTOS: Esta tabla registra la configuracin de los vehculos que estarn asignados a los usuarios y la configuracin de patente, modelo y marca del vehculo, y su capacidad de consumo por kilometraje. 15. CONFIGURACION: Esta tabla es de uso especfico dentro del sistema y es empleada para la personalizacin de consultas a la base de datos, describiendo las tablas, los campos, las relaciones y condiciones especficas para la ejecucin y despliegue de informacin dentro de algunos mdulos del sistema. 16. SOCKETCONFIG: Esta tabla es de uso especfico dentro del sistema y es empleado para registrar temporalmente los paquetes que son recibidos de los nodos por la aplicacin servidora para luego ser segmentados, transformados e insertados en la tabla GEOCODES. 17. EVENTOS: Esta tabla est reservada para una prxima versin del sistema, donde se gestionar los eventos generados por los vehculos en circulacin en funcin del comportamiento dentro de la jornada de trabajo, con la finalidad de generar indicadores visualizables en pantalla.

5.5 Construccin del sistema

5.5.1 Interfaces de bsqueda y despliegue de la informacin de un mvil La secuencia de acceso a los diferentes niveles mdulos y funcionalidades del sistema, se inicia con la autenticacin del usuario, el que ser validado en el momento de iniciar su sesin.

Una vez iniciada la sesin, el usuario tendr a su disposicin el control centralizado del sistema, con un repertorio de opciones agrupados en mens separados, desde los cuales podr acceder a la configuracin, reportes histricos y control del mapa, donde podr visualizar los vehculos en trnsito y sus rutas, como tambin las alertas en lnea que se irn desplegando en el transcurso del tiempo.

5.5.1.1 ACCESO AL SISTEMA

1 2 3
Fig. 24 Interfaz de conexin al sistema

Para ingresar al sistema es necesaria la identificacin por un usuario y contrasea 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 mens, que nos permitirn la administracin del sistema, tanto como vehculos, alertas y reportes.

5.6.1.3 SUBMENU CONFIGURACIN DE ALERTAS

1 2
Fig. 26 Configuracin de Alertas

1 Opcin Hora: Permite configurar alertas por hora tanto para agregar, borrar o editar estas alertas. 2 Opcin Velocidad: Permite configurar alertas de velocidad tanto para editar, agregar, borrar alertas.

5.5.1.4 SUBMENU REPORTES

Fig. 27 Submen Reportes

1 2 3 4

Opcin Velocidad Mxima: Permite visializar el reporte de velocidad mxima Opcin Vehculo Detenido. Opcin Distancia Recorrida Historial: Despliega todos los registros de los vehculos de este usuario, donde donde se podr ver fecha, hora, latitud, longitud y direccin de cada registro.

5.5.1.5 Configurar Vehculos:

Fig. 28 Submen Configurar Vehculos

Esta opcin permite ingresar a un formulario para agregar, editar, o eliminar un vehculo.

5.5.1.6 Submen Control Mapa.

Fig. 29 Submen control mapa

En esta opcin se ingresa al Panel Control Mapa, desde donde se puede analizar el recorrido de los vehculos.

5.5.1.7 Submen Alertas de Horas

Formulario Visualizacin

Fig. 30 Submen Alertas Horas

1 Formulario de visualizacin 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 trmino de una alerta.

5.5.1.9 Editar Alertas.

5.9.1.9

Fig. 32 Formulario de edicin de alerta.

Al seleccionar una alerta y presionar el botn 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 Visualizacin de alertas de velocidad, se visualiza nro. de alerta, patente y velocidad mxima para ese vehculo. 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 mxima

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 Vehculos / Velocidad Mxima.

Fig. 38 Reporte de vehculos velocidad mxima

Presionando sobre la opcin de reporte velocidad mxima, aparecer un formulario de ingreso de fecha a consultar, en este formulario deber ingresar la fecha para buscar vehculos que sobre sobrepasaron la velocidad mxima.

Fig. 39 Reporte de vehculos que sobrepasaron la velocidad mxima establecida

El reporte que se despliega, muestra aquellos vehculos que sobrepasaron la velocidad mxima definida en la configuracin para ese vehculo. Agrupado por perodos de una hora, figurar la velocidad mxima registrada en ese intervalo. Adicionalmente figuran columnas de la cantidad de segundos que mantuvo la velocidad y las coordenadas donde se registr el vehculo en ese instante.

5.5.1.16 Reporte Vehculo Detenido

Fig. 40 Formulario ingreso de fecha.

Presione reporte velocidad mxima y aparecer un formulario de ingreso de fecha a consultar. Posteriormente, se listarn aquellos vehculos que han permanecido detenidos durante intervalos de una hora. Se desplegarn columnas donde figura la cantidad de tiempo detenido, y las coordenadas donde se detuvo.

Fig. 41 Reporte de vehculos detenidos

5.5.1.17 Reporte Distancia Recorrida

Fig. 42 Seleccin de vehculo y fecha

Primero se debe seleccionar desde un listado, la patente de un vehculo , y a continuacin elegir una fecha a consultar.

A continuacin se listar en intervalos de una hora, la distancia en kilmetros que ha recorrido el vehculo durante el tiempo y a la velocidad aproximada figurados en las columnas Tiempo y Km/h. Las columnas de Tiempo, Distancia y Consumo Total, mostrarn en forma acumulada en funcin del tiempo, el consumo acumulado en funcin de las distancias por tiempos recorridos en cada tramo. Adicionalmente se muestran las columnas de las coordenadas de referencia, donde se registra la ubicacin del vehculo durante esos intervalos.

Fig. 43 Reporte de Distancia Recorrida

Captulo 6: CONCLUSIN

A la vista del trabajo realizado, se puede concluir que los objetivos planteados inicialmente se cumplieron en su totalidad, encontrndose el sistema

actualmente disponible y operativo para cumplir con las funcionalidades propuestas inicialmente:

- Crear una interfaz grfica que permita visualizar la ubicacin y recorrido de los mviles. Se desarroll un sistema informtico, orientado a Web, paramtrico y autoconfigurable, utilizando herramientas de tipo interfaz grfica de navegacin intuitiva. open source, con una

- Crear reportes de gestin que faciliten la administracin de los mviles. La informacin capturada puede ser consultada en forma paramtrica y

desplegada en el panel diseado para visualizacin y seguimiento de los mviles.

Crear alertas que faciliten la administracin de los mviles. Se incluy el registro paramtrico de alertas controlables de velocidad y tiempo, desplegando grficamente el estado de un mvil mediante la

utilizacin de cartografa digital, dejando abierta la posibilidad de agregar alertas por otros conceptos.

- Presentar el estado del arte de la tecnologa de los GPS y su uso en control de flota. Se detall las principales caractersticas de la tecnologa GPS, su estado actual, ventajas y desventajas de uso, elementos componentes y principales marcas y empresas proveedoras en el mercado nacional.

La metodologa XP, definida inicialmente para el desarrollo del sistema y cuyas caractersticas principales fueron ampliamente detalladas, fue aplicada en forma eficiente, utilizndose la programacin en parejas, incorporando

activamente al cliente final en todas las modificaciones y correcciones, y realizando entregas de validacin peridicas segn se avanz con el desarrollo.

Para el desarrollo del proyecto, se asignaron distintos roles dentro del grupo, logrndose con ello subdividir las tareas a realizar, y concentrar en cada una las mejores habilidades de cada integrante.

Se realizaron pruebas basadas en la informacin capturada desde el receptor GPS instalado en un grupo de vehculos, y almacenada en una base de datos diseada, para un rango de fecha y tiempo, las que entregaron los resultados esperados. Se prob la interfaz construida, la que eficiente y una navegacin fluida. permite una operacin

La estructura modular y paramtrica con que se dise la solucin, otorga la posibilidad de incorporar rpidamente funcionalidades futuras, de acuerdo al eventual crecimiento del producto una vez comercializado.

Esperamos con todo esto, haber contribuido a entregar una visin actual del estado de la tecnologa GPS, sus fundamentos tcnicos, potencialidades y ventajas de utilizacin aplicadas sobre el desarrollo de un sistema informtico.

Captulo 7: BIBLIOGRAFA
lan Somerville, Ingeniera de Software, 2007, Pearson, Addison Wesley, 2005. ISBN: 84-7829-074-5; Editorial: Pearson, Addson Wesley; Ao 2005; 712 pginas. URL: http://www.scribd.com/doc/25664820/Ingenieria-de-Software-IanSommerville-7ma-Edicion BIB.XP6: Pag. 363. Urbina Lpez Diego Alejandro, Informe Programacin Extrema Universidad Csar Vallejo (UCV), Lima Norte 2009; 11 pginas. URL: http://www.scribd.com/doc/15250014/Programming-Xtreme-Inform-UcvUniversity BIB.XP3: Pag. 2; BIB.XP4: Pag. 11; BIB.XP5: Pag. 10; BIB.XP8: Pag. 3 - 5 Zambrano Jimnez Solange, Juan Carlos Len, Laura Otaiza Gmez. Informe Programacin Extrema Universidad de Los Andes Mrida Colombia, Febrero 2010; 28 pginas. 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 Cmo funciona el GPS en cinco pasos lgicos. 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 , cronologa , funcionamiento y aplicacin del GPS a travs de tres dcadas. Autor: Ramiro Jess 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 orientacin.

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. http://gismac-gps.cl Sitio Web Corporativo Autor: No se menciona. http://www.localizagps.cl Sitio Web Corporativo Autor: No se menciona. http://www.gpschile.com Sitio Web Corporativo Autor: No se menciona. http://www.gpstrace.cl Sitio Web Corporativo Autor: No se menciona. http://www.movilmaster.cl Sitio Web Corporativo Autor: No se menciona. Fecha ltima visita: 20/05/2010 Fecha ltima visita: 23/07/2010 Fecha ltima visita: 25/07/2010 Fecha ltima visita: 24/06/2010 Fecha ltima visita: 23/07/2010

Fecha ltima visita: 26/07/2010