Sistema de Monitoreo y Control de Posicionamiento via GPS
Short Description
Descripción: UNIVERSIDAD CIENCIAS DE LA INFORMATICA FACULTAD DE INGENIERIA Y TECNOLOGÍA DESARROLLO DE UN SISTEMA ...
Description
UNIVERSIDAD CIENCIAS DE LA INFORMATICA FACULTAD DE INGENIERIA Y TECNOLOGÍA
DESARROLLO DE UN SISTEMA DE MONITOREO Y CONTROL DE POSICIONAMIENTO VIA GPS APLICABLE EN UNA FLOTA DE VEHÍCULOS
EDUARDO ACOSTA BECERRA ANDRÉS BASAEZ MIRANDA MARJORIE CCOPA FLORES GABRIEL MUÑOZ MIGUEL VARGAS WELCH
2010
UNIVERSIDAD CIENCIAS DE LA INFORMATICA FACULTAD DE INGENIERIA Y TECNOLOGÍA
DESARROLLO DE UN SISTEMA DE MONITOREO Y CONTROL DE POSICIONAMIENTO VIA GPS APLICABLE EN UNA FLOTA DE VEHÍCULOS
Trabajo de Titulación presentado en conformidad a los requisitos para obtener el Título de Ingeniero de Ejecución en Informática.
Alumno(s) : EDUARDO ACOSTA BECERRA ANDRÉS BASAEZ MIRANDA MARJORIE CCOPA FLORES GABRIEL MUÑOZ MADRID MIGUEL VARGAS WELCH
Profesor Guía : GERARDO CERDA NEUMANN
FECHA DE PRESENTACION 13 de Agosto de 2010
RESUMEN El presente informe detalla las etapas del desarrollo de un sistema de control y posicionamiento de vehículos vía GPS aplicables a una flota de vehículos. El objetivo principal fue crear un sistema informático que permitiera, mediante parametrización adecuada, realizar consultas dinámicas a los datos de posicionamiento de los vehículos, capturados mediante dispositivos con tecnología GPS, y almacenados en una base de datos, para realizar con ellos el control de gestión a través de la generación de reportes de consulta en línea, de su posición en un período determinado, generación de ruta óptima de viaje y control de alertas definidas para velocidad y tiempo de desplazamiento. El sistema, que ya se encuentra completamente operativo y funcionando, se desarrolló con herramientas de tipo open source, permitiendo de esta forma representar una alternativa de bajo costo, para potenciales clientes principalmente del rango de pequeñas empresas de transporte. Como objetivo adicional, se planteó dar a conocer el estado del arte de la tecnología GPS, sus principales características y utilización en el rubro del transporte nacional.
TABLA DE CONTENIDOS CAPÍTULO 1: INTRODUCCIÓN....................................................................................................................................6 CAPÍTULO 2: OBJETIVOS..........................................................................................................................................8 2.1 OBJETIVO GENERAL................................................................................................................................8 2.2 OBJETIVOS ESPECÍFICOS .......................................................................................................................8 2. 3 ALCANCES Y LIMITACIONES................................................................................................................8 CAPÍTULO 3: MARCO TEÓRICO...........................................................................................................................10 3.1 QUÉ ES EL GPS? .................................................................................................................................................12 3.2 CARACTERÍSTICAS DEL GPS................................................................................................................13 3.3 DETALLES TÉCNICOS DEL FUNCIONAMIENTO DEL GPS.........................................................................14 3.3.1 PASO 1: TRIANGULACIÓN DESDE LOS SATÉLITES........................................................................14 3.3.2 PASO 2: MIDIENDO LA DISTANCIA A LOS SATÉLITES.................................................................15 3.3.3 PASO 3: CONTROL PERFECTO DEL TIEMPO...................................................................................15 3.3.4 PASO 4: CONOCER DÓNDE ESTÁN LOS SATÉLITES EN EL ESPACIO........................................16 3.3.5 PASO 5: CORRIGIENDO ERRORES.....................................................................................................17 3.3.6 DIVISIONES...........................................................................................................................................18 3.4 SEGMENTOS Y COMPONENTES DEL SISTEMA GPS...............................................................................19 3.4.1 SEGMENTO ESPACIAL........................................................................................................................19 3.4.2 SEGMENTO DE CONTROL.................................................................................................................20 3.4.3 SEGMENTO DE USUARIO...................................................................................................................21 3.5 TIPOS PRINCIPALES DE EQUIPOS GPS.......................................................................................................22 3.6 VENTAJAS Y DESVENTAJAS DE SU UTILIZACIÓN.................................................................................22 3.6.1 VENTAJAS...............................................................................................................................................22 3.6.2 DESVENTAJAS......................................................................................................................................23 3.6.2.1 ERRORES INTENCIONALES.............................................................................................................24 3.6.2.2 ERRORES PROPIOS DEL SISTEMA.................................................................................................24 3.7 MERCADO NACIONAL...................................................................................................................................26 3.8 COSTOS DEL SERVICIO..................................................................................................................................27 3.8.1 COSTO DE CONTRATO DEL SERVICIO DE GPS...............................................................................27 3.8.2 EQUIPOS UTILIZADOS EN EL MERCADO NACIONAL...................................................................27 3.9 METODOLOGÍA EMPLEADA.........................................................................................................................28 3.9.1 METODOLOGÍA XP O PROGRAMACIÓN EXTREMA.............................................................................28 3.9.2 USO PRÁCTICO DE LA METODOLOGÍA XP EN EL PROYECTO.........................................................38 3.9.3 GOOGLE CODE...........................................................................................................................................40 3.9.4 API DE GOOGLE MAPS..............................................................................................................................41 3.9.5 COMO INTEGRAR UN MAPA DE GOOGLE MAPS ................................................................................41 3.10 TECNOLOGÍAS EMPLEADAS.......................................................................................................................42 3.10.1 ARQUITECTURA DE LA SOLUCIÓN.................................................................................................42 3.10.2 TECNOLOGÍA DE DESARROLLO....................................................................................................44 CAPÍTULO 4. DEFINICIÓN DEL PROYECTO...........................................................................................................45 4.1 ALCANCE..........................................................................................................................................................45 4.2 DETALLE DE LA SOLUCIÓN........................................................................................................................46 4.3 ENTREGABLES.................................................................................................................................................47 4.4 ROLES Y RESPONSABILIDADES..................................................................................................................49 4.5 SUPUESTOS, RIESGOS, DEPENDENCIAS, RESTRICCIONES...................................................................51 4.6 ESTIMACIÓN DE RECURSOS/ HORAS.......................................................................................................52 CAPÍTULO 5: DISEÑO...........................................................................................................................................53 5.1 MODELAMIENTO....................................................................................................................................53 5.2 HISTORIAS DE USUARIO...............................................................................................................................55
5.3 CARACTERÍSTICAS.........................................................................................................................................60 PANTALLA PRINCIPAL.......................................................................................................................61 REPORTE DE VELOCIDAD.................................................................................................................61 REPORTE VEHÍCULO DETENIDO......................................................................................................61 5.4 MODELO DE CASOS DE USO.................................................................................................................62 5.4.1 MODELO DE CASOS DE USO - (USE CASE DIAGRAM) .................................................................62 5.4.2 ACTORES - (USE CASE DIAGRAM). ..................................................................................................63 5.4.3 ALERTA HORAS - (USE CASE DIAGRAM). .....................................................................................65 5.4.4 ALERTA VELOCIDAD - (USE CASE DIAGRAM)..............................................................................67 5.4.5 CONFIGURAR ALERTA - (USE CASE DIAGRAM) ...........................................................................69 5.4.6 SERVIDOR SISTEMA ALERTA - (USE CASE DIAGRAM) ..............................................................71 5.4.7 SERVIDOR SISTEMA RECEPCIÓN DATOS - (USE CASE DIAGRAM) .........................................73 5.4.8 CASO DE USO PRINCIPAL - (USE CASE DIAGRAM) ......................................................................75 5.4.8.1 AUTENTICAR - (SEQUENCE DIAGRAM) .......................................................................................76 5.4.8.2 BUSCAR VEHÍCULO - (SEQUENCE DIAGRAM) ...........................................................................78 5.4.8.3 DESPLEGAR UBICACIÓN - (COMMUNICATION DIAGRAM) .....................................................79 5.4.9 ADMINISTRACIÓN - (USE CASE DIAGRAM) ..................................................................................81 5.4.9 MODELO DE DATOS....................................................................................................................................83 5.5 CONSTRUCCIÓN DEL SISTEMA...................................................................................................................85 5.5.1 INTERFACES DE BÚSQUEDA Y DESPLIEGUE DE LA INFORMACIÓN DE UN MÓVIL .............85 5.5.1.1 ACCESO AL SISTEMA.......................................................................................................................86 5.5.1.2 MENU PRINCIPAL..............................................................................................................................87 5.6.1.3 SUBMENU CONFIGURACIÓN DE ALERTAS..................................................................................87 5.5.1.4 SUBMENU REPORTES.......................................................................................................................88 5.5.1.5 CONFIGURAR VEHÍCULOS:.............................................................................................................88 5.5.1.6 SUBMENÚ CONTROL MAPA............................................................................................................89 5.5.1.7 SUBMENÚ ALERTAS DE HORAS...................................................................................................90 5.5.1.9 EDITAR ALERTAS.............................................................................................................................92 5.5.1.10 SUBMENÚ ELIMINAR ALERTA.....................................................................................................93 5.5.1.11 SUBMENÚ ALERTA DE VELOCIDAD...........................................................................................94 5.5.1.13 EDITAR ALERTA DE VELOCIDAD................................................................................................96 5.5.1.14 ELIMINAR ALERTA DE VELOCIDAD..........................................................................................97 5.5.1.15 REPORTE VEHÍCULOS / VELOCIDAD MÁXIMA........................................................................98 5.5.1.16 REPORTE VEHÍCULO DETENIDO...............................................................................................100 5.5.1.17 REPORTE DISTANCIA RECORRIDA...........................................................................................101 CAPÍTULO 6: CONCLUSIÓN................................................................................................................................103 7.1 LINKS DE ACCESO A DOCUMENTACION DESDE INTERNET ...........................................................107
Capítulo 1: INTRODUCCIÓN Hoy en día las empresas que hacen uso del GPS consiguen aumentar la productividad del personal en movilidad además de obtener importantes ahorros en combustible, según una reciente encuesta impulsada por Motorola entre 255 responsables de la toma de decisiones de TI y telecomunicaciones de Norteamérica. Según este estudio, el beneficio más citado por casi el 50% de las empresas que utilizan actualmente el GPS, fue una importante reducción del consumo de carburante, lo que tiene su reflejo en una disminución de las distancias de los desplazamientos de 231,2 millas semanales de media, con un ahorro registrado de 51.582 dólares anuales en carburantes. En Estados Unidos, con más de un millón de camioneros, el ahorro potencial en el conjunto de la industria podría alcanzar los 53.000 millones de dólares anuales. El estudio reveló asimismo que las empresas que han desplegado tecnologías GPS se ahorran aproximadamente 54 minutos al día, lo que se traduce en un ahorro anual en mano de obra de 5.484 dólares por empleado, o 5,4 millones por empresa encuestada. Además del ahorro, también hay aplicaciones de localización a las que se les atribuyen mejoras en la organización de rutas, permitiendo a la empresa saber exactamente dónde están sus empleados en cada momento, y examinar distintas posibilidades antes de implementar una ruta. Las empresas encuestadas emplearon menos tiempo en enfrentarse al tráfico o a hallar rutas, incrementando el tiempo dedicado a nuevos o antiguos clientes. De hecho, al preguntarles por qué se plantearían invertir en GPS u otras nuevas tecnologías, los encuestados mencionaron la atención al cliente como su prioridad número uno. El estudio también identificó otras aplicaciones esenciales, como la navegación para mejorar la puntualidad y optimizar las rutas. Navegación y optimización de rutas responden a las dificultades a las que con frecuencia tienen que enfrentarse los trabajadores con movilidad de campo para localizar nuevas paradas durante su recorrido y optimizar las entregas (1). Por todo lo anterior, poder contar hoy en día con una solución de control y monitoreo mediante GPS, para los operadores de flotas de vehículos , se ha convertido en una inversión rentable al corto plazo, toda vez que los ahorros logrados no solo son significativos en cuanto a los costos de combustible. También permitir que los desplazamientos sean planificados y programados con
anticipación utilizando la información entregada por los software de monitoreo, y dando la posibilidad de administrar y ordenar los tiempos de viaje, optimiza las entregas de carga, el transporte a tiempo de personas o bien la operación de la logística de entrega de insumos y productos de las empresas. Por ello, y analizando la oferta de los distintos actores oferentes del servicio de monitoreo vía GPS existentes actualmente en el mercado nacional, hemos previsto la oportunidad de desarrollar un sistema de monitoreo de móviles vía GPS, que considere la posibilidad de ser adquirido por flotas de vehículos de tamaño mediano o pequeño. Para cumplir con el objetivo propuesto de lograr un producto de bajo de costo el sistema, que pretende ser una oferta alternativa al servicio ofrecido por los proveedores actuales de esta tecnología en el país y que en general no está al alcance de la mayoría de las Pymes que puedan requerirlo, será desarrollado con herramientas de software abierto, y cubrirá las funcionalidades básicas de reportaje de información.
(1) http://www.noticiasdot.com/wp2/2008/08/12/el-uso-del-gps-en-las-empresas
Capítulo 2: OBJETIVOS
2.1 OBJETIVO GENERAL ▪ Desarrollar un sistema de reporte en línea que apoye el monitoreo de vehículos de transporte. 2.2 OBJETIVOS ESPECÍFICOS Para contribuir a lograr el objetivo general se contemplan las siguientes etapas: ▪ Presentar el estado del arte en la tecnología de los GPS y su uso en control de flota. ▪ Crear una interfaz gráfica que permita visualizar la ubicación y recorrido de los móviles. ▪ Crear reportes de gestión que faciliten la administración de los móviles. ▪ Crear alertas que faciliten la administración de los móviles. 2. 3 ALCANCES Y LIMITACIONES. ALCANCES: Se desarrollará e implementará un sistema con interfaz gráfica que, mediante los elementos de captura y seguimientos utilizados por la tecnología GPS, permitirá desplegar en línea la posición de un móvil en un momento y posición determinados, permitiendo la captura y entrega de información de posicionamiento, tiempo de detención y consumo de combustible realizado por el móvil para llegar desde un punto inicial a un punto determinado. La información será entregada mediante alarmas previamente programadas, a partir de la información de posicionamiento capturada por los dispositivos GPS incorporados en el móvil.
LIMITACIONES: El sistema a desarrollar solo incorporará las funcionalidades que permitan cumplir con los entregables descritos en la propuesta de trabajo para la asignatura de Seminario de Integración y que básicamente posibilitan entregar una visión de la tecnología GPS, sus potencialidades y su estado actual de aplicación mediante el desarrollo de un sistema informático.
Capítulo 3: MARCO TEÓRICO Con el inicio de la Era Espacial (1957) y el posterior lanzamiento del satélite Vanguard 1 en 1959, se puso de manifiesto que la transmisión de ondas radiales, podían servir para orientar al hombre en cualquier parte del mundo. Los primeros sistemas de posicionamiento, empleaban estaciones de radio AM, (amplitud modulada), que poseían una gran cobertura, aunque no permitían determinar con precisión una posición determinada, ya que las interferencias atmosféricas afectaban dichas señales. Otro inconveniente de las señales AM, es la propia curvatura de la Tierra, ya que ésta tiende a desviar las ondas. La solución para este inconveniente era colocar transmisores de radio en el espacio y que emitieran señales de forma constante en dirección a la Tierra. Este método disminuye la interferencia y a la vez cubre un área mucho mayor que las AM (1). Sin embargo, no fue hasta 1993 que el Departamento de Defensa de los Estados Unidos, pone en funcionamiento el sistema conocido como GPS (Global Positioning System, sistema de posicionamiento global), declarado plenamente operacional en 1995. En distintas épocas, hubo otros intentos por desarrollar sistemas de posicionamiento. Uno de ellos fue GLONASS (Global Navigation Satellite System) desarrollado por Rusia en 1976. Este sistema fue incompatible con el sistema creado por Estados Unidos. No fue hasta el 2001 cuando la compañía Topcon desarrolló un aparato GPS compatible con ambos sistemas (2).
El sistema GPS vigente es el norteamericano, que en un principio fue enfocado al desarrollo de estrategias bélicas y programado intencionalmente con ciertos errores de cálculo, de forma que solo el Departamento de Defensa de Estados Unidos, pudiera interpretar y corregir esos errores. En 1998, el Departamento de Defensa de los Estados Unidos, anunció la decisión de ampliar las capacidades del GPS añadiendo una nueva señal para el uso civil, asegurando mejoras significativas en el posicionamiento y navegación de los usuarios. El Departamento de Defensa, trabajó conjuntamente con la Fuerza Aérea de Estados Unidos y con los organismos civiles para la modernización del sistema GPS, centrándose en mejorar los servicios, tanto para el área militar como civil (3).
(1), (2) Así funciona el GPS, Antecedentes del sistema. (3) ADDITIONAL CIVIL CODED SIGNALS ONFUTURE GLOBAL POSITIONING SYSTEM (GPS) SATELLITES, Departamento de Defensa de los Estados Unidos. http://www.defense.gov/releases/release.aspx?releaseid=1623
3.1 Qué es el GPS? El Sistema GPS (Global Positioning System) o Sistema de posicionamiento Global es un sistema de posicionamiento terrestre que está compuesto por tres subsistemas: los satélites, el sistema de control y los usuarios. El primer subsistema consiste en una red de 24 satélites artificiales (llamados NAVSTAR), 21 satélites activos más tres de repuesto, los cuales son propiedad del Gobierno de Estados Unidos. Estos satélites se encuentran uniformemente distribuidos en un total de 6 órbitas (cada una en una dirección distinta y cuyo centro es La Tierra), de forma que hay 4 satélites por órbita. Esta configuración asegura que siempre puedan "verse" al menos 8 satélites desde casi cualquier punto de la superficie terrestre. Los satélites GPS orbitan la Tierra a una altitud de unos 20.000 Kms. y recorren dos órbitas completas cada día. Describen un tipo de órbita tal que "salen" y se "ponen" dos veces al día. Cada satélite transmite señales de radio a la Tierra con información acerca de su posición y el momento en que se emite la señal. Esta información se recibe con receptores GPS, que decodifican las señales enviadas por varios satélites simultáneamente y combinan sus informaciones para calcular su propia posición en la Tierra, es decir sus coordenadas de latitud y longitud con una precisión de unos 10 metros. (4), (5).
(4) Universidad de Concepción, Facultad de Ingeniería 2001. (5) Geological Survey Of IRAN (G.S.I), http://www.gsi.ir/Science/Lang_en/Page_03-07-01/Introduction.html
3.2 CARACTERÍSTICAS DEL GPS El GPS fue creado con el objetivo de satisfacer los requerimientos de las fuerzas militares en la determinación exacta de posición, velocidad y tiempo, en un sistema de referencia común, en o cerca de la Tierra, para cualquier condición climática. El posicionamiento con GPS significa proporcionar la latitud y longitud del punto en el que se encuentra sobre la superficie terrestre. La mayoría de los receptores proporcionan los valores de estas coordenadas en unidades de grados (°) y minutos ('). Tanto la latitud como la longitud son ángulos y por tanto deben medirse con respecto a un ángulo de referencia bien definido. Hoy en día el Sistema de Posicionamiento Global (GPS) está disponible en dos formas básicas: SPS, iniciales de Standard Positioning Service (Servicio de Posicionamiento Estándar), y PPS, siglas de Precise Positioning Service (Servicio de Posicionamiento Preciso). El SPS proporciona la posición absoluta de los puntos con una precisión de 100 m. El código PPS permite obtener precisiones superiores a los 20 m.; este código es accesible sólo a los militares de Estados Unidos y sus aliados, salvo en situaciones especiales(6). Las técnicas de mejora, como el GPS diferencial (DGPS), permiten a los usuarios alcanzar hasta 3 m de precisión.
(6) Enciclopedia Microsoft Encarta
3.3 DETALLES TÉCNICOS DEL FUNCIONAMIENTO DEL GPS. El funcionamiento del sistema GPS se puede describir en cinco pasos fundamentales:
3.3.1 Paso 1: Triangulación desde los satélites. La idea general detrás del GPS es utilizar los satélites en el espacio como puntos de referencia para ubicaciones aquí en la tierra. Esto se logra mediante una exacta medición de nuestra distancia hacia al menos tres satélites, lo que nos permite triangular nuestra posición en cualquier parte de la tierra. La idea geométrica de esta medición consiste en: supongamos que medimos nuestra distancia al primer satélite y resulta ser de 20.000 Kms., esto limita nuestra posición a la superficie de una esfera que tiene como centro dicho satélite y cuyo radio es de 20.000 Kms. A continuación se mide la distancia a un segundo satélite y se descubre que se está a 21.000 Kms. de éste. Esto dice que no se está solamente en la primera esfera, correspondiente al primer satélite, sino también sobre otra esfera que se encuentra a 21.000 Kms. del segundo satélite. En otras palabras, se está en algún lugar de la circunferencia que resulta de la intersección de las dos esferas. Si ahora se mide la distancia a un tercer satélite y se descubre que está a 23.000 Km de éste, esto limita la posición aún más a los dos puntos en los cuales la esfera de 23.000 Kms. corta la circunferencia resultante de la intersección de las dos primeras esferas. Es decir, que midiendo la distancia a tres satélites se limita el posicionamiento a solo dos puntos posibles. Para decidir cual de ellos es la posición verdadera, se podría efectuar una nueva medición a un cuarto satélite. Pero normalmente uno de los dos puntos posibles resulta ser muy improbable por su ubicación demasiado lejana de la superficie terrestre y puede ser descartado sin necesidad de mediciones posteriores. Una cuarta medición, de todos modos es muy conveniente por otra razón que se verá más adelante.
3.3.2 Paso 2: Midiendo la distancia a los satélites. La posición se calcula a partir de la medición de la distancia hasta por lo menos tres satélites. En el caso del GPS se está midiendo una señal de radio, que viaja a la velocidad de la luz, alrededor de 300.000 Kms. por segundo. Por lo tanto el problema es en cómo medir ese tiempo que, obviamente, es extremadamente corto. Suponiendo que el GPS, por un lado, y el satélite, por otro, generan una señal auditiva en el mismo instante exacto. Se oiría dos versiones de la señal. Una de ellas inmediatamente, la generada por el receptor GPS y la otra con cierto atraso, la proveniente del satélite, porque tuvo que recorrer alrededor de 20.000 Kms. para llegar hasta él. Con esto se puede decir que las señales no están sincronizadas. Si se quisiera saber cuál es la magnitud de la demora de la señal proveniente del satélite se puede retardar la emisión de la señal del GPS hasta lograr la perfecta sincronización con la señal que viene del satélite. El tiempo de retardo necesario para sincronizar ambas señales es igual al tiempo de viaje de la señal proveniente del satélite. Suponiendo que sea de 0.06 segundos, y conociendo este tiempo, se multiplicará por la velocidad de la luz y ya se obtendrá la distancia hasta el satélite. La señal emitida por el GPS y por el satélite es llamada “Código Pseudo Aleatorio”.
3.3.3 Paso 3: Control perfecto del tiempo. La medición del tiempo de viaje de una señal es clave para el GPS, los relojes que se usan deben ser muy exactos, dado que si se mide con un desvío de una milésima de segundo, a la velocidad de la luz, esto se traduce en un error de 300 Kms. Por el lado de los satélites, el tiempo es casi perfecto porque lleva a bordo relojes atómicos de una gran precisión, por el alto costo que implica el uso de estos relojes atómicos, los receptores GPS, aquí en la tierra, utilizan relojes mucho menos precisos. Para obtener un tiempo perfecto es necesario realizar una medición satelital adicional. Cualquier GPS decente debe ser capaz de sintonizar al menos cuatro satélites de manera simultánea. En la práctica, casi todos los GPS en venta actualmente, acceden a más de 6, y hasta a 12 satélites
simultáneamente.
3.3.4 Paso 4: Conocer dónde están los satélites en el espacio. Todos ellos están flotando a unos 20.000 Kms. de altura en el espacio. Un satélite a gran altura se mantiene estable. La altura de 20.000 Kms. es en realidad un gran beneficio para este caso, porque algo que está a esa altura está bien despejado de la atmósfera. Eso significa que orbitará de manera regular. De acuerdo al Plan Maestro de GPS, la Fuerza Aérea de los EEUU colocó cada satélite en una órbita muy precisa. En tierra, todos los receptores de GPS tienen un almanaque programado en sus computadoras que les informan donde está cada satélite en el espacio, en cada momento. Con el fin de mantener estas órbitas básicas en forma exacta, los satélites de GPS son monitoreados de manera constante por el Departamento de Defensa de los EEUU. Ellos utilizan radares muy precisos para controlar constantemente la exacta altura, posición y velocidad de cada satélite. Los errores que ellos controlan son los llamados errores de efemérides, o sea evolución orbital de los satélites. Estos errores se generan por influencias gravitacionales del sol y de la luna y por la presión de la radiación solar sobre los satélites. Estos errores son generalmente muy sutiles pero si se quiere una gran exactitud habrá que tenerlo en cuenta. Una vez que el Departamento de Defensa ha medido la posición exacta de un satélite, vuelve a enviar dicha información al propio satélite. De esa manera el satélite incluye su nueva posición corregida en la información que transmite a través de sus señales a los GPS. Esto significa que la señal que recibe un receptor de GPS no es solamente un código pseudo aleatorio con fines de tiempo, también tiene un mensaje con información sobre la órbita exacta del satélite.
3.3.5 Paso 5: Corrigiendo Errores En este paso sólo se van señalar errores que afectan la señal del GPS, haciéndola menos precisa. Para un receptor de GPS se debe tener en cuenta una amplia variedad de errores posibles tales como: En el cálculo se asume que las señales GPS viajan a la velocidad de la luz, siendo ésta solamente constante en el vacío. Además, las señales GPS atraviesan la ionósfera y tropósfera, el paso de las señales a través de estas capas provoca un error en el retraso en la recepción de la señal. Los problemas para la señal de GPS no terminan cuando llega a la tierra, ya que esta puede rebotar variar veces debido a obstrucciones locales antes de ser captadas por los receptores GPS. Los relojes atómicos que utilizan son muy precisos, pero no son perfectos. Pueden ocurrir minúsculas discrepancias que se transforman en errores de medición del tiempo de viaje de las señales (6).
(6)http://www.uco.es/~bb1rofra/documentos/comofuncionagps/comofuncionagps.h tml
3.3.6 Divisiones El Sistema de Posicionamiento Global consta de tres divisiones: espacio, control y usuario. La división espacio incluye los satélites y los cohetes Delta que lanzan los satélites desde Cabo Cañaveral, en Florida, Estados Unidos. La división control incluye la estación de control principal en la base de las Fuerzas Aéreas Falcon, en Colorado Springs, Estados Unidos, y las estaciones de observación situadas en Falcon AFB, Hawai, en la isla de Ascensión en el Atlántico, en Diego García en el océano Índico, y en la isla Kwajalein en el Pacífico sur. La división usuario está constituida por receptores GPS de navegación tanto de uso civil como militar.
Fig. 1 Posiciones Espacio, Control y Usuario
3.4 SEGMENTOS Y COMPONENTES DEL SISTEMA GPS El fundamento del sistema GPS consiste en la recepción de entre cuatro y ocho señales de radio de otros tantos satélites de los cuales se conoce de forma muy exacta su posición orbital con respecto a la tierra; a la vez, se conoce muy bien el tiempo que han tardado las señales en recorrer el camino entre el satélite y el receptor. Conociendo la posición de los satélites, la velocidad de propagación de sus señales y el tiempo empleado en recorrer el camino hasta el usuario, por trilateración se puede establecer la posición en términos absolutos del receptor. Elementos que forman el Sistema del GPS:
Segmento Espacial.
Segmento de control
Segmento del usuario.
3.4.1 SEGMENTO ESPACIAL El Segmento Espacial está constituido por los satélites que soportan el sistema y las señales de radio que emiten. Estos satélites conforman la llamada constelación NAVSTAR (Navigation Satellite Timing and Ranging), constituida por 24 satélites operativos más cuatro de reserva, mantenidos por la fuerza aérea estadounidense. No hay que olvidar, que el origen de este sistema es militar y su financiación corre íntegramente a cargo del gobierno de los Estados Unidos. Los 24 satélites y sus 4 de reserva de la constelación NAVSTAR, circundan la tierra en órbitas a una altura alrededor de los 20.200 Kms. de la superficie y distribuidos de tal manera que en cada punto de la superficie terrestre se tiene posibilidad de leer la señal de al menos cuatro satélites. Esto es muy importante, porque se necesitan al menos cuatro satélites para conocer la posición del observador, y que estos se dispongan con un ángulo de elevación sobre el horizonte superior a 15°; no obstante, casi siempre son más de cuatro los satélites 'visibles'.
3.4.2 Segmento de control El segmento de control son todas las infraestructuras en tierra necesarias para el control de la constelación de satélites. Dichas infraestructuras tienen coordenadas terrestres de muy alta precisión y consisten en cinco grupos de instalaciones repartidas por todo el planeta, para tener un control homogéneo de toda la constelación de satélites
Fig. 2 Segmento de Control
Estas infraestructuras realizan un seguimiento continuo de los satélites que pasan por su región del cielo, acumulando los datos necesarios para el cálculo preciso de sus órbitas. Dichas órbitas son muy predecibles, dado que no existe fricción atmosférica en el entorno donde se mueven los satélites; a las predicciones de las órbitas de los satélites para el futuro se les conoce con el nombre de almanaques, cuyo cálculo depende también del segmento de control.
3.4.3 Segmento de Usuario El segmento del usuario está constituido por el hardware (equipos de recepción) y el software que se utilizan para captar y procesar las señales de los satélites. Se puede utilizar en diversos tipos de actividades relacionados con la vigilancia. Entre ellas podríamos citar: -
La detección de la dilatación de magma de un volcán, La observación de los movimientos de un iceberg.
Determinar las vibraciones terrestres, fin, cualquier fenómeno natural o creado por el hombre que presente algún movimiento, por más imperceptible que parezca. Los datos generados por el GPS también pueden ser utilizados para estudiar fenómenos que ocurren en otros mundos. Los investigadores Andrew Johnston y James Zimbelman precisaron los flujos de lava que suceden en Carrizozo, en el campo de prueba de misiles de White Sands, cerca de Alamogordo y en McCartys, al sur de Grants, los cuales se extienden hasta 50 kilómetros. Asimismo, el GPS puede servir para comprender mejor los cambios físicos que ocurren en nuestro planeta. Por ejemplo, los movimientos en las profundas aguas de los océanos, el monitoreo de el estatus de la actividad volcánica en ciertas regiones. Algunos es la detección de los movimientos bajo la tierra también Los investigadores del Instituto de Mediciones Geográficas de Japón han recogido una serie de datos con Geonet, una red de más de mil sensores GPS que cubre las zonas rurales del país, para con esto tratar de predecir el comportamiento de las capas subterráneas y por ende predecir cuando un sismo sucederá. Es empleado en la navegación marítima, terrestre y aérea. También empieza a surgir en las calles, donde los autos tienen integrado sistemas de GPS y con esto es prácticamente imposible perderse.
3.5 TIPOS PRINCIPALES DE EQUIPOS GPS Hoy en día se encuentra una gran variedad de tipos de GPS, por las diversas funcionalidades que tiene y sus formas. Además, dicha clasificación puede realizarse por múltiples criterios, como por ejemplo en función de la arquitectura (receptores secuenciales, continuos o multiplex), en función del método de funcionamiento (correlación de código o análisis de fase de la portadora), o en función de las aplicaciones a las que se destine.
3.6 VENTAJAS Y DESVENTAJAS DE SU UTILIZACIÓN. 3.6.1 VENTAJAS -
El GPS es un sistema que entrega información acerca de posición en la tierra mediante altitud y longitud en forma fácil y rápida, con una precisión casi exacta y cobertura mundial las 24 horas del día incluso en condiciones meteorológicas muy adversas.
-
Entregan información de posicionamiento 100% fiable.
-
Estos dispositivos GPS son de fácil instalación sobre el parabrisas o tablero de instrumentos, con un soporte que facilita la correcta visualización.
-
Facilidad de su uso, ya que permite introducir destinos y rutas de forma mucho más cómoda y precisa que con los sistemas tradicionales (mapas de carreteras).
-
La portabilidad que tiene el GPS de poder adecuarse a toda instalación.
-
Actualización constante de la información cartográfica.
-
Efectividad en el cálculo de la ruta y la legibilidad de la información.
Los datos otorgados por los satélites son de mucha utilidad para el hombre, ya que además de entregar información de fiabilidad relativa acerca de
nuestra posición y altitud, nos otorga datos que son muy útiles para prever los cambios atmosféricos y las condiciones ambientales y climáticas del lugar que deseemos tener información. Todos los GPS's incorporan funciones de navegación realmente sofisticadas que harán cambiar todo concepto de la orientación conocida. Por ejemplo, se puede elaborar rutas sobre mapas, registrando en el dispositivo los puntos por los que se quiere, o se debe pasar. Sobre el terreno, activando esa ruta, una pantalla gráfica nos indicará si se está sobre el rumbo correcto o se está desviando en alguna dirección; también se puede utilizar la misma función en rutas reversibles, es decir, ir registrando puntos por lo que se va a pasar para luego poder volver por esos mismos puntos con seguridad. Además se puede deducir la velocidad a la que se desplaza con exactitud, mientras se mantiene el rumbo en línea recta, o deducir la velocidad a la que se va desplazando si se registra todos los puntos de cambio de rumbo y un largo etc.
3.6.2 DESVENTAJAS. Este espectacular sistema de posicionamiento, como todas las cosas, también posee errores, unos propios del sistema y otros intencionales, que son la principal fuente unitaria de error del sistema. No todos los aparatos GPS portátiles tienen suficiente memoria como para guardar rutas diarias y viajes pre-planificados. La señal del satélite pasa a través de la atmósfera, encontrándose con la tropósfera y la ionósfera, las que afectan la onda produciendo un cambio de velocidad o retraso conocido con el nombre de refracción.
3.6.2.1 Errores Intencionales. Esta fuente de error se realiza con fines netamente estratégicos. El Gobierno de Estados Unidos decidió que debía incorporar distintos grados de error en las mediciones obtenidas por los receptores, por motivos de seguridad. Este gobierno gastó 12.000 Millones de dólares para desarrollar el sistema de navegación más exacto del mundo, sin embargo, ahora está degradando intencionalmente su exactitud; esta política se denomina "Disponibilidad Selectiva" y pretende asegurar que ninguna fuerza hostil o grupo terrorista pueda utilizar el GPS para fabricar armas certeras y atentar contra la seguridad de los civiles. Los receptores de uso militar utilizan una clave para eliminar la Disponibilidad Selectiva y son, por ello, mucho más exactos. Lo que se hace básicamente es que el Departamento de Defensa introduce cierto "ruido" en los datos del reloj satelital, lo que a su vez se traduce en errores en los cálculos de posición. Otra forma es que el Departamento de Defensa envía datos orbitales ligeramente erróneos a los satélites, que estos reenvían (transmitiendo el error) a los receptores GPS como parte de la señal que emiten.
3.6.2.2 Errores propios del sistema. Los efectos asociados al satélite y su posición contribuyen a alterar la medición de distancia. El mensaje de transmisión está dado por la posición instantánea del satélite y sus valores son predeterminados por las estaciones de control tierra. De este mensaje, llamado efemérides, se puede deducir dos tipos de error: •
Es imposible determinar con total exactitud la posición del satélite porque las órbitas de éstos están influenciadas por la atracción gravitacional, la que a su vez no ejerce una fuerza constante sobre dichos cuerpos.
•
La medición del tiempo es fundamental en la medición de la distancia desde el satélite al Geo receptor; aunque los relojes utilizados son de alta calidad, no son totalmente perfectos.
Otro error se introduce cuando la señal del satélite pasa a través de la atmósfera, encontrándose con la tropósfera y la ionósfera, las que afectan la
onda produciendo un cambio de velocidad o retraso conocido con el nombre de refracción. La geometría de los satélites también podría afectar la medición, este factor se conoce con el nombre de Dilución de la Precisión. La calidad de la medición dependerá de la disposición de los satélites, si éstos están extremadamente juntos la medición será poco confiable, en cambio, cuando se encuentran bastante dispersos respecto al valor de la antena, esta será una buena medición. Es por esto que si dos receptores están muy juntos el uno del otro, unos pocos cientos de kilómetros, la señal que alcanza a ambos viajará prácticamente a través del mismo pasillo de atmósfera y por ello tendrán los mismos errores. Afortunadamente todos estos errores no suman demasiado error total. Existe una forma de GPS, denominada GPS Diferencial o DGPS, que reduce significativamente estos problemas. Las empresas que ofrecen el servicio de GPS, deben contar con dos elementos indispensables: Un medio de transmisión por el cual se pueda transmitir en tiempo real o diferido, los datos desde el vehículo a la estación base. Una plataforma software que interprete y analice los datos recogidos para desplegarlos en distintos formatos para los clientes. El medio utilizado para transmitir la información recolectada es la red de telefonía móvil. No es posible brindar el servicio de seguimiento de vehículos, sin contar con el servicio de transmisión de datos que otorgan las propias empresas móviles. Existen 3 grandes operadores de telefonía móvil en nuestro país: Movistar Claro ENTEL PCS. Estas Empresas proveen de servicio de voz, no necesariamente implica entregar servicio de transmisión de datos. En la práctica, las empresas que dan el servicio de posicionamiento global, deben recurrir a las empresas de telefonía móvil que también proporcionan el servicio de transmisión de datos.
3.7 MERCADO NACIONAL. Las principales empresas proveedoras del servicio GPS en Chile, son: Empresa GPS Chile ENTEL PCS PointPay MóvilMaster Wisetrack Control óptimo Sitrack Internet
Participación de mercado 27% 20% 16% 13% 13% 4% 3% 3%
Fuente: Depto. Marketing MóvilMaster S.A.
Como en todos los mercados, el servicio de GPS ha tenido entradas y salidas de empresas, como por ejemplo en el 2004 la empresa Rutacert salió del mercado y PointPay Chile entró de forma exitosa, ya que en menos de un año alcanzó el 16% de participación del mercado
3.8 COSTOS DEL SERVICIO. 3.8.1 Costo de contrato del servicio de GPS El precio que se cobrará al cliente depende de los servicios contratados, la cantidad de móviles a incorporar, la extensión del contrato, si el cliente compra el dispositivo GPS o lo toma en comodato. Los contratos típicos son en comodato con plazos de 12, 24 y 36 meses. Cuando el cliente compra el GPS generalmente se genera un contrato a 12 meses o un contrato abierto sin cláusulas de salida o con un aviso de 90 días. El modo de cobrar en comodato es un valor por la instalación, su valor es de 2 UF + IVA y un servicio mensual que oscila entre las 0,8 y 1,1 UF + IVA por móvil/mes. Si el cliente compra el equipo los valores pueden bajar a 0,65UF + IVA móvil/mes.
3.8.2 Equipos utilizados en el mercado nacional Las marcas de equipos GPS más utilizadas en el mercado nacional son: Virloc, Sky Patrol, Amphora, Antares, Webtech, MT, Portman.
3.9 Metodología Empleada Para el desarrollo del sistema se ha determinado utilizar la metodología XP, cuyas principales características se detallan a continuación:
3.9.1 Metodología XP o Programación Extrema XP es un acrónimo del inglés Extreme Programming o Programación Extrema que es su traducción al español. Fue creada por el estadounidense Kent Beck a mediados de la década de los 90's y se trata de una disciplina que extrae diversas prácticas de otras metodologías existentes con el fin de resolver problemas comunes y presentes en el desarrollo de software que causan generalmente el incumplimiento de plazos de los proyectos, entrega de productos y la calidad de los mismos. Se encuentra en discusión si XP es una metodología ágil de desarrollo dentro de la ingeniería de software, o bien una disciplina o modelo de proceso de programación, ya que no solo muestra los pasos a seguir en el desarrollo de software, sino que especifica la dinámica entre los actores y la operatividad del desarrollo del proyecto [BIB.XP1]. Sin embargo su popularidad ha ganado terreno por proponer un método ágil, adaptable y flexible a diferencia de las metodologías tradicionales. Una de las características principales de este método es que plantea una forma liviana y adaptable del proceso de desarrollo [BIB.XP2]. Los autores de XP han seleccionado aquellos que han considerado mejores y han profundizado en sus relaciones y en cómo se refuerzan los unos con los otros. El resultado de esta selección ha sido esta metodología única y compacta. Por esto, aunque no está basada en principios nuevos, sí que el resultado es una nueva manera de ver el desarrollo de software [BIB.XP3]. La competitiva industria del desarrollo en las últimas décadas ha forzado la evolución de los modelos tradicionales de desarrollo de software, sobre todo ante un mundo de negocios tan exigente donde los requerimientos pueden variar de acuerdo a las condiciones del negocio que un usuario final pueda manejar en el tiempo. Los métodos tradicionales no siempre tendrán que cumplir con los plazos que un cliente necesita, y no siempre los resultados finales de un producto terminado cubrirán las necesidades de un cliente, si las estrategias del negocio han cambiado y con ello los requerimientos. Resultado de esto, han surgido métodos y disciplinas nuevas que se ajustan a tales exigencias sin desaprovechar el trabajo ni menos los ánimos de todo equipo de
desarrollo, cumpliendo así con las necesidades de un cliente cada vez más exigente y un mercado cada vez más dinámico. El enfoque que ha tenido las metodologías tradicionales en la ingeniería de software por años ha servido para el desarrollo de sistemas de alta envergadura y criticidad, sin embargo con la masificación de los computadores personales en el hogar y en la pequeña y mediana empresa, los costos de desarrollo no avalan proyectos de negocios donde las necesidades y las estrategias cambian según se mueve el mercado en el tiempo, por lo que los costos obligan a un cambio de enfoque para transformar y emplear innovadores métodos de trabajo en favor de optimizar los costos en función del tiempo. [Fig 3].
Fig. 3 Diferencias de Enfoques [BIB.XP4]
Los métodos ágiles evolucionaron de la mano con los modelos iterativos, y éstos tienen la finalidad de construir un producto por etapas, siendo cada etapa un conjunto de actividades previamente planificadas para la elaboración coordinada e incremental del producto que se desea entregar. XP está basado en la iteración o repetición continua de procesos durante la realización del desarrollo de un proyecto de software, dándole movilidad y adaptabilidad a pesar de la disciplina con la que se lleva a cabo. Según sus autores, la misión que fundamenta a XP detalla que:
“El objetivo que se perseguía en el momento de crear esta metodología era la búsqueda de un método que hiciera que los desarrollos fueran más sencillos. Aplicando el sentido común.” [BIB.XP3] Los métodos ágiles nacieron ante la necesidad de resolver problemas comunes dentro de todo proyecto de desarrollo, principalmente [BIB.XP2]: 1. Cuando el cliente no tiene claro aún los requerimientos del producto que necesitan y los van cambiando continuamente. 2. Cuando se trata de un proyecto de alto riesgo: fecha fija de entrega, un producto de software nunca antes hecho por un equipo de desarrollo o la comunidad de desarrolladores. 3. Cuando se cuenta con un reducido equipo experimentado de desarrollo, entre dos y no más de diez programadores. 4. Cuando existe una alta tasa de rotación o renovación dentro del equipo de desarrollo. 5. Cuando los cambios de requerimientos vienen en función de cambios en la estrategia del negocio. 6. Cuando hay proyectos donde se debe hacer continuidad o mantenimiento y la arquitectura del sistema y sus partes son complejas o confusas. 7. Cuando el objetivo es entregar el software tal cual se necesita y en el momento que se necesita. Los principios de la programación extrema, al igual que el común de los métodos ágiles, es que el proyecto de software vaya evolucionando a la par con las necesidades del cliente, y en esto el cliente debe ejercer un rol importante en la vida del mismo. El cliente o usuario final debe ser integrante del equipo de desarrollo y jugar un papel de árbitro y guía en las especificaciones y requerimientos dentro de cada línea base en la vida del proyecto. Los principios básicos de esta metodología se resumen en lo siguiente [BIB.XP6]: • • •
Participación del cliente: Los clientes deben está fuertemente implicados en todo el proceso de desarrollo. Su papel es proporcionar y priorizar nuevos requerimientos del sistema y evaluar iteraciones del sistema. Entrega incremental: El software se desarrolla en incrementos, donde el cliente especifica los requerimientos a incluir en cada incremento. Personas, no procesos: Se deben reconocer y explotar las habilidades del equipo de desarrollo. Se les debe dejar desarrollar sus propias formas de trabajar, sin procesos formales a los miembros del equipo.
• •
Aceptar el cambio: Se debe contar con que los requerimientos del sistema cambian, por lo que el sistema se diseña para dar cabida a esos cambios. Mantener la simplicidad: Se deben centrar en la simplicidad tanto del software a desarrollar como en el proceso de desarrollo. Donde sea posible, se trabaja activamente para eliminar la complejidad del sistema.
Esta metodología podría funcionar siempre y cuando se cumpla las siguientes condiciones [BIB.XP7]: • • • • • • • • •
El cliente o usuario final disponga del tiempo necesario para participar en el proyecto y dar soporte al equipo de desarrollo en el momento oportuno. Exista una férrea comunicación y predisposición al trabajo conjunto en el equipo de desarrollo. Exista un ordenado flujo de comunicación entre cliente, jefe de proyecto y equipo de desarrollo. El equipo de desarrollo sea tolerante a la revisión y cambio de la programación realizada por otro programador sobre del código fuente propio. El equipo de desarrollo sea abierto y tolerante a los cambios frecuentes de los requerimientos o del diseño del sistema a desarrollar. No exista una tendencia al sobre tiempo (horas extra), en el horario de trabajo del equipo de trabajo. XP sugiere no más de 40 horas a la semana. Equipo de desarrollo acotado, cantidad no es calidad, XP sugiere un rango no inferior a 2 y no superior a 10 programadores. El sistema a desarrollar no sea a gran escala o que interactúen con complejos sistemas o infraestructuras hardware/software. Donde no participen diversos equipos de desarrollo dispersos geográficamente. Una de las cosas que los programadores deben tener en cuenta es que los cambios siempre estarán presentes en el ciclo de vida de un proyecto, cambiarán los requisitos, las reglas del negocio, el personal, la tecnología, etc. Por lo tanto el problema no estará en el cambio en sí, sino en la manera en que se deberán enfrentar esos cambios. Como en cualquier otra actividad humana necesitamos valores para desarrollar nuestro trabajo y conseguir los planteamientos iniciales.
Bajo estos principios y condiciones se han definido un grupo de valores que deben asumir todos aquellos que practican y participan esta disciplina [BIB.XP10]: •
Comunicación: La comunicación prevalece en todas las prácticas de XP, y éste fomenta la comunicación. Comunicación cara a cara es la mejor manera para resolver confusiones y malos entendidos, para transmitir ideas, conocimientos, dudas y soluciones entre miembros del equipo. Gracias a la comunicación entre los desarrolladores y el cliente o el jefe de proyecto, se pueden realizar cambios que el cliente requiere o no le gustaron, también apoya la extensión del conocimiento tácito dentro del equipo de desarrollo, evitando la necesidad de mantener la documentación escrita.
•
Sencillez: Ayuda a los desarrolladores a encontrar soluciones más simples a los problemas, también los ayuda a crear características en el diseño que puedan ayudar a resolver problemas a futuro. La sencillez en el código también ayuda a la comunicación y a la documentación, mientras más sencillo sea el código, menos necesidad se tendrá de explicar y comunicar de él.
•
Retroalimentación: La retroalimentación continua del cliente permite a los desarrolladores llevar y dirigir el proyecto en una dirección correcta hacia donde el cliente quiera. La retroalimentación actúa junto con la sencillez y la comunicación, cuanto mayor retroalimentación más fácil es la comunicación. Cuanto más simple un sistema más fácil de probar. Escribir pruebas nos orienta como simplificar un sistema, hasta que las pruebas funcionen, cuando las pruebas funcionen tendrá mucho avance echo.
•
Valentía: Asumir retos, ser valientes antes los problemas y afrontarlos. Si el código es engorroso, no se debe terminar odiándolo y odiando al sistema, esto trae como consecuencia, una entropía positiva. El valor o coraje requiere que los desarrolladores vayan a la par con el cambio, porque se debe tener conciencia que este cambio es inevitable, pero el estar preparado con una metodología ayuda a ese cambio. La valentía se extiende también para los gerentes o empresarios que financian estos proyectos, puesto que si una de las prácticas es la del trabajo en parejas, puede darse a entender que la empresa está pagando a dos por el trabajo de uno, pero sin embargo lo que se gana es en calidad y tiempo ahorrado de correcciones y mantenimiento en la aplicación que suele ser
programado y revisado por una persona y no por dos. Tal como se puede representar en la figura 4, la programación extrema propone una serie de prácticas que los integrantes del equipo deberán adoptar, estos se agrupan en cuatro categorías, los cuales determina el funcionamiento específico que se debe emplear al momento de programar [BIB.XP8]:
Fig. 4 Esquema Conceptual Metodología XP [BIB.XP5]
1.- Retroalimentación a escala fina • El principio de pruebas: se tiene que establecer un período de pruebas de aceptación del programa (llamado también período de caja negra) donde se definirán las entradas al sistema y los resultados esperados de estas entradas. • Proceso de planificación: en esta fase, el usuario tendrá que escribir
sus necesidades, definiendo las actividades que realizará el sistema. Se creará un documento llamado Historias del Usuario (User Stories). • El cliente en el sitio: se le dará poder para determinar los requerimientos, definir la funcionalidad, señalar las prioridades y responder las preguntas de los programadores. • Programación en parejas: uno de los principios más radicales y en el que la mayoría de gerentes de desarrollo pone sus dudas. Requiere que todos los programadores XP escriban su código en parejas, compartiendo una sola máquina. 2.- Proceso continuo 1. Integración continua: permite al equipo hacer un rápido progreso implementando las nuevas características del software. 2. Refactorización: permite a los equipos de programadores XP mejorar el diseño del sistema a través de todo el proceso de desarrollo. 3. Entregas pequeñas: colocan un sistema sencillo en producción rápidamente que se actualiza de forma rápida y constante permitiendo que el verdadero valor de negocio del producto sea evaluado en un ambiente real. 3.- Entendimiento compartido •
Diseño simple: se basa en la filosofía de que el mayor valor de negocio es entregado por el programa más sencillo que cumpla los requerimientos. Simple Design se enfoca en proporcionar un sistema que cubra las necesidades inmediatas del cliente, ni más ni menos.
•
Metáfora: desarrollada por los programadores al inicio del proyecto, define una historia de cómo funciona el sistema completo.
•
Propiedad colectiva del código: un código con propiedad compartida. Nadie es el propietario de nada, todos son el propietario de todo.
•
Estándar de codificación: define la propiedad del código compartido así como las reglas para escribir y documentar el código y la comunicación entre diferentes piezas de código desarrolladas por diferentes equipos.
4.- Bienestar del programador La semana de 40 horas: la programación extrema sostiene que los programadores cansados escriben código de menor calidad. De acuerdo a estas prácticas, el equipo de desarrollo que adopte XP, sus actividades se centrarán principalmente en estas cuatro: •
Codificar: Es necesario codificar y plasmar las ideas a través del código. En programación, el código expresa la interpretación del problema, así se puede utilizar el código para comunicar, para hacer comunes las ideas, y por tanto para aprender y mejorar.
•
Hacer pruebas: Las pruebas dan la oportunidad de saber si lo implementado es lo que en realidad se tenía en mente. También son indicativos de que el trabajo funciona, cuando no se pueda pensar en cualquier prueba que pudiese originar un fallo en el sistema, entonces el mismo estará realizado por completo.
•
Escuchar: Según una afirmación frecuente entre el personal: "Los programadores no lo conocemos todo, y sobre todo muchas cosas que las personas de negocios piensan que son interesantes. Si ellos pudieran programarse su propio software ¿para qué nos querrían?". Es importante escuchar a los clientes acerca de cuáles son los problemas de su negocio de una manera activa, explicando lo que es posible de obtener y lo que no es posible de obtener, para que esta realimentación entre ambos ayuden a entender los problemas de una forma objetiva.
•
Diseñar: El diseño crea una estructura que organiza la lógica del sistema, un buen diseño permite que el sistema crezca con cambios en un solo lugar. Los diseños deben de ser sencillos, si alguna parte del sistema es de desarrollo complejo, lo apropiado es dividirla en varias. Si hay fallos en el diseño o malos diseños, estos deben de ser corregidos cuanto antes. En resumen, según las actividades que propone XP, se deduce que es necesario codificar porque sin código no hay programas, Se deben hacer pruebas por que sin pruebas no se sabe si se ha acabado de codificar, tenemos que escuchar, porque si no se escucha no se sabe que codificar
ni probar, y por último hay que diseñar para poder codificar, probar y escuchar indefinidamente. La decisión de adoptar una metodología u otra para la puesta en marcha de un proyecto de software es un paso importante que debe asumir tanto el jefe de proyecto como el cliente y que debe ser analizado detenidamente. XP aclara que todo proyecto de desarrollo debe considerar cuatro variables esenciales. También establece que de estas cuatro variables, solo tres de ellas podrán ser fijadas o indicadas por el cliente o jefe de proyecto, mientras que una variable quedará libre [BIB.XP9]: •
Costo: Del proyecto se incrementa cuando se necesita máquinas más rápidas, mas especialistas técnicos en determinadas áreas o mejores oficinas para el equipo de desarrollo. En XP el costo del cambio maneja un papel muy importante, porque comparado con otras metodologías para implementar software, es mucho más barato, debido a que las pruebas se van haciendo según las versiones liberadas, no es como una metodología normal, en que primero se realiza el análisis, después el diseño, implementación, pruebas y finalmente producción, mientras que en la XP siempre se está implementando, probando y produciendo.
•
Tiempo: En el que se planifica y en el que realmente se lleva a cabo el proyecto. Debe tomare en cuenta que los cambios aumentarán el tiempo de realización mientras que la optimización y la inversión pueden acortarlo.
•
Calidad: Puede representar un cambio extraño; debido a que a mayor calidad menor tiempo de realización del proyecto. Por lo tanto el equipo de desarrolladores está encargado de la tarea de hacer las pruebas con los mejores resultados posibles para así tener una idea de cuál es el problema y como lo van a resolver de una manera simple y eficiente, para que la calidad del proyecto se mantenga al 100% y tener una facilidad de adaptarse a los cambios del código lo que hace este proceso más rápido.
•
Ámbito: Es la que se encuentra libre es el alcance del proyecto, en la cual el equipo determina: la estimación de las tareas a realizar, que es lo que el cliente quiere, la implementación de los requisitos más importantes de manera que este siempre sea funcional.
Todas las metodologías tienen limitantes y los métodos ágiles no son la excepción, éstos son apropiados para algunos tipos de desarrollo de sistemas. Son más idóneos para sistemas de negocios pequeños y de tamaño medio, como también para el desarrollo de productos de software para computadores personales. No son adecuados para sistemas complejos a gran escala, donde puedan participar otros equipos externos de desarrollo y tenga que adaptarse a complejas iteraciones de otros proyectos o interactuar con complejos sistemas software/hardware. Tampoco es viable utilizarlo para proyectos críticos, donde es necesario un análisis detallado de todos los requerimientos del sistema para comprender sus implicaciones de seguridad o protección.
3.9.2 Uso práctico de la metodología XP en el Proyecto. Todo proyecto guarda incertidumbres en su desarrollo y evolución, y no está exento de problemas. Depende mucho de la conformación de un equipo de trabajo y su disposición de seguir una disciplina estricta y puntual. Incluso si los programadores más experimentados y disciplinados están dispuestos a someterse a una disciplina impuesta por una metodología, siempre existen los riesgos que esta no rinda los frutos esperados o simplemente no funcione. El trabajar en equipo, es tan difícil como predecir el futuro de una familia. En un equipo de trabajo existen personas, y las personas poseen distintos puntos de vista, distintas formas de pensar, de planificar y decidir. No es necesario aplicar un juicio de valores sobre las personas ni sobre la calidad de trabajo individual, los jefes de proyectos podrían tener una visión tan clara sobre su equipo, como para saber de antemano si una tarea es apropiada o no para un programador u otro. Pero aún así un jefe de proyecto podría no ser asertivo en elegir una metodología u otra, o de seleccionar un programador para su equipo. La clave está en no aplicar de una manera estricta una metodología sobre un grupo que recién comienza a conformarse y cuya adaptación puede tomar un tiempo arriesgado para cualquier proyecto, sino que más bien, adaptar una metodología a un orden que recién comienza a funcionar dentro de un grupo. El trabajo en parejas, quizás sea una de las tareas más difíciles de conseguir dentro de un grupo de trabajo, pocos programadores pueden estar abiertos a compartir su trabajo y estar sometidos a opiniones y críticas sobre su forma individual de trabajar, y es precisamente porque cada programador es un individuo que razona y actúa de manera individual. Para consolidar una dualidad dentro de un equipo de trabajo en parejas es necesario que exista una afinidad y sinergia de manera que dos piensen mejor que uno, en lugar que uno intente pensar mejor que el otro, y que al final termine la competencia en que uno termine más rápido una versión del trabajo antes que el otro. Otro problema que se puede dar con frecuencia es la disponibilidad de recursos en el tiempo requerido. Es muy común, si se trabaja con un grupo disperso de personas, sea difícil consolidar un equipo de desarrollo, donde el trabajar reunidos en forma presencial sea también requerido. Sin embargo, si se puede realizar sutiles cambios a una metodología, donde el trabajar reunidos en
forma presencial, pueda realizarse de manera virtual, es más valiosa la contribución de esta adaptación para el éxito de un proyecto. Una solución viable para esta problemática es la de compartir los programas fuentes por medio de un repositorio de código fuente común con control de versiones, donde este repositorio pueda ser accedido de manera segura desde cualquier lugar y en cualquier momento por los integrantes del equipo de desarrollo. De esta manera, los cambios realizados por uno u otro programador, puedan ser vistos y replicados. Esto garantiza que el trabajo en parejas puede darse en forma remota y virtual, dado que ambos pueden ver el mismo código fuente, y ambos pueden trabajar en forma colaborativa sin perder el control sobre las versiones de los fuentes. Implementar un sistema de control de versiones no es complejo, dado un sin número de aplicaciones y sistemas que lo permiten. Sin embargo, para aquellos equipos de desarrollo que no dispongan de recursos para montar un servicio como este, pueden optar por servicios gratuitos y de confianza que llevan suficiente tiempo en la red Internet, como es el caso de Google Code, que es el que se aplica sobre el presente proyecto.
3.9.3 Google Code. Es el espacio donde Google comparte con todos los usuarios las herramientas necesarias para que puedan administrar sus propios proyectos de desarrollo bajo licencia libre. Esto es, el código fuente que se declara con licencia libre, se ofrece para que cualquier desarrollador pueda utilizarlo en sus proyectos, o incluso modificarlo respetando las normas de la licencia libre [BIB.GC1]. El alojamiento de proyectos en Google Code es un servicio de alojamiento de software libre rápido, fiable y sencillo que permite: •
Crear proyectos instantáneos sobre cualquier tema.
•
Alojar código de Subversión con un 1 gigabyte de espacio de almacenamiento y admitir alojamiento para descargas con 2 gigabytes de espacio de almacenamiento.
• Consultar código fuente integrado y utilizar herramientas de revisión de código para facilitar la visualización de código, la revisión de contribuciones y el mantenimiento de una base de código de gran calidad. • Realizar un seguimiento de problemas y búsquedas Wiki de proyectos sencillas, pero flexibles y potentes, que pueden adaptarse a cualquier proceso de desarrollo. •
Marcar como destacados y actualizar flujos que facilitan el seguimiento de los proyectos y los desarrolladores que interesan [BIB.GC2].
3.9.4 API de Google Maps. Es un conjunto de clases y funciones JS , que podemos cargar en nuestras propias páginas previo registro. Posee una extensa documentación sobre su uso y nos permite crear aplicaciones basadas en la tecnología de Google Maps, cuyo único límite es nuestra imaginación y talento para programar.
Características Google Maps ofrece la capacidad de hacer acercamientos o alejamientos para mostrar el mapa. El usuario puede controlar el mapa con el mouse o las teclas de dirección para moverse a la ubicación que desee. Los resultados de la búsqueda pueden ser restringidos a una zona, gracias a Google Local. Como otros servicios de mapa, Google Maps permite la creación de pasos para llegar a alguna dirección. Esto permite al usuario crear una lista paso a paso para saber el cómo llegar a su destino. 3.9.5 Como integrar un mapa de Google Maps Insertar un mapa en nuestro sitio Web es muy simple haciendo uso de la API de Google Maps. Lo primero es solicitar nuestra API Key, debemos especificar en qué URL vamos a utilizar nuestro mapa. Aunque es recomendable solicitar una para la dirección http://localhost y con esta hagamos los ajustes necesarios y una vez que nuestro código esté listo cambiar la API Key por la de nuestro sitio en Internet para publicar la página.
3.10 Tecnologías Empleadas. 3.10.1 Arquitectura de la solución Un nodo GPS en circulación, enviará periódicamente una señal que será recibida por una antena de estación Base de telefonía celular (BTS), esta se comunicará a través de un enlace con un Controlador de Estaciones Base (BSC), el cual por medio de un procesador adjunto, el Nodo de Soporte del Servicio GPRS, convertirá estos paquetes de información en paquetes TCP que serán enviados a la red Internet.
Fig. 5 Arquitectura de la solución
Estos paquetes TCP, serán capturados por una aplicación servidora, que se encargará de segmentarlos y almacenarlos en una base de datos, haciendo referencia a los nodos que lo emitieron.
El sistema de supervisión de los nodos GPS, se encargará de proveer al usuario las herramientas necesarias, para la gestión de los vehículos que las portan por medio de una interfaz Web intuitiva y amigable.
3.10.2 TECNOLOGÍA DE DESARROLLO –
Herramienta de desarrollo: PHP 5; Java Standard Edition.
–
Base de datos:
MySQL.
–
Servidor:
Apache 2
Capítulo 4. DEFINICIÓN DEL PROYECTO Desarrollar un sistema de reporte en línea que apoye el de vehículos de transporte.
monitoreo
4.1 ALCANCE • Desarrollar e implementar un sistema con interfaz gráfica que, mediante los elementos de captura y seguimientos utilizados por la tecnología GPS, que permita desplegar en línea la posición de un móvil en un momento y posición determinados, y capturar y entregar de información de posicionamiento, tiempo de detención y consumo de combustible realizado por el móvil para llegar desde un punto inicial a un punto determinado. •
Entregar la información mediante alarmas previamente programadas, a partir de la información de posicionamiento capturada por los dispositivos GPS incorporados en el móvil.
•
Capacitar al equipo técnico en la plataforma que se utilizará para el diseño e implementación de la solución.
•
Ejecutar un plan de capacitación sobre el uso de la solución construida.
•
El sistema a desarrollar solo incorporará las funcionalidades que permitan cumplir con los entregables descritos en el capítulo 5, (producto que se entregará), y que básicamente posibilitan entregar una visión de la tecnología GPS, sus potencialidades y su estado actual de aplicación mediante el desarrollo de un sistema informático.
4.2 DETALLE DE LA SOLUCIÓN -
Diseñar una interfaz gráfica para despliegue de información de posicionamiento del (los) móviles a monitorear.
-
Diseñar los procedimientos y flujos de captura de información desde los dispositivos receptores GPS
-
Diseñar y construir una base de datos para almacenar la información capturada
-
Definir los parámetros de entrada y condiciones de monitoreo y captura de información desde los móviles.
-
Diseñar reportes de información estadística generada durante los períodos definidos de captura y monitoreo y que interesa poder visualizar.
-
Probar el sistema construido para revisar y corregir desviaciones en el procedimiento de captura y despliegue de información.
-
Entregar sistema construido y capacitar sobre su operación y manejo al cliente final.
4.3 ENTREGABLES. Responsabl e Analista de Procesos, Analista de Sistemas.
Entregable
Descripción
Fecha
Aplicación gráfica que permita visualizar la ubicación geográfica de los móviles Reportes de gestión del control de la flota de vehículos Conjunto de alertas que se generen a partir de la ubicación geográfica de los vehículos
Documento con la descripción de las funcionalidades del sistema desarrollado
17-03-2010
Documento con la descripción de los informes que generará el sistema. Informes o avisos de estado generados de acuerdo a parámetros de entrada previamente definidos. Presentación inicial del sistema a desarrollar, su objetivo, funcionalidades y características. Presentación del estado de avance del desarrollo del sistema.
18-03-2010
Analista de Sistemas.
18-03-2010
Analista de Sistemas,
20-03-2010
Jefe de Proyectos, Analista de Sistemas.
22-03-2010
Analista de Sistemas, Analista de Procesos, Analista QA
Primer Informe de avance de la solución
Segundo Informe de avance de la solución
Criterio de Aceptación
Debe cumplir con los parámetros de evaluación de la asignatura de Seminario de integración. Debe cumplir con los parámetros de evaluación de la asignatura de Seminario de integración.
Entregable
Descripción
Fecha
Resultados de las pruebas y validaciones del sistema
Documento con los resultados de pruebas y validaciones realizadas a la aplicación desarrollada. Planificación de la Inducción y Capacitación de los usuarios del sistema
08-04-2010
Informe Final de proyecto
Informe con el detalle de sistema desarrollado.
22-04-2010
Seguimiento de la Operación
Reporte estadístico sobre el uso del sistema.
29-04-2010
Capacitación a usuarios y operadores del sistema
13-04-2010
Responsabl e Analista de Sistemas, Programador de Aplicaciones, Analista QA. Jefe de Proyecto
Criterio de Aceptación Pruebas aprobadas.
Plan de inducción y capacitación con fechas y plazo acordados con usuario final. Jefe de Debe cumplir Proyecto, con los Analista de parámetros de Sistemas, evaluación de la Desarrollador asignatura de , Analista QA. Seminario de integración. Jefe Proyecto No aplica.
4.4 ROLES y RESPONSABILIDADES. Rol
Responsabilidades •
Jefe de Proyecto
• • • •
Analista de Procesos
• •
• • • Analista de Sistemas
• • •
Gestiona administrativamente la ejecución del proyecto. Realiza seguimiento a las actividades. Coordina y organiza reuniones con el equipo de implementación, cliente y usuarios finales de la solución. Gestiona y coordina el traspaso a producción de la solución. Recolecta información relacionada al uso del GPS y evalúa principales marcas de equipamiento para análisis de costos. Revisa, analiza, rediseña y normaliza el procedimiento de implantación del sistema. Recomienda cambios y/o modificaciones al diseño del sistema, de acuerdo a necesidades planteadas por el usuario/cliente final. Documenta el sistema diseñado. Diseña la aplicación, incluyendo la interfaz gráfica. Documenta el diseño de la solución. Crea y evalúa los resultados del plan de pruebas de la solución. Realiza inducción y capacitación en el uso de la solución a los usuarios.
Tiempo Requerido (Horas)
Responsable
35
Eduardo Acosta
32
Marjorie Ccopa
28
Miguel Vargas
Rol
Responsabilidades •
Programa dor /Desarroll ador
•
• • •
Analista QA
Desarrolla la aplicación de acuerdo a detalle técnico funcional entregado por el analista de sistemas. Implementa las validaciones y estándares de calidad que aseguren la solidez de la aplicación desarrollada Aplica el plan de pruebas a la solución. Crea manual conciso del usuario. Valida y sugiere modificaciones al sistema desarrollado, con el propósito de asegurar la calidad y cumplimiento de estándares básicos de calidad que debe cumplir para poder comercializarlo en el mercado.
Tiempo Requerido (Horas)
Responsable
129
Gabriel Muñoz
24
Andrés Basáez
4.5 SUPUESTOS, RIESGOS, DEPENDENCIAS, RESTRICCIONES Supuestos:
1. La plataforma de infraestructura y software a utilizar en la implementación son open source. 2. Se dispone de los recursos técnicos y de equipamiento para dejar el sistema funcionando. 3. Los plazos han sido definidos ajustándose a los plazos definidos por la asignatura de Seminario de Integración. Riesgos: 1. Falta de disponibilidad de tiempo del usuario final para participar en las inducciones y capacitaciones. 2. El proyecto ha sido calificado con un 25% de riesgo. Dependencias: 1. La implementación del sistema, considera que existe y se encuentra operativo el servicio GPS 2. La interfaz gráfica a desarrollar debe estar alineada con el estándar gráfico del mercado de GPS. Restricciones: 1. Los recursos asignados al trabajo tendrán aproximadamente un 40% de dedicación al proyecto.
4.6 ESTIMACIÓN DE RECURSOS/ HORAS. Rol
Expertise/Nivel
Horas
Jefe de Proyecto
Profesional/Alto
35
Analista de Procesos
Profesional/Medio
32
Analista de Sistemas
Profesional/Medio
28
Programador de Aplicaciones Analista QA
Profesional/Medio
129
Profesional/Bajo
24
Capítulo 5: DISEÑO. 5.1 Modelamiento. El modelo de requerimientos es un catálogo estructurado de requerimientos del usuario final. Estos están representados como requisitos o elementos de características.
custom Requirements Model
The Requirements model is a structured catalogue of end-user requirements. These are represented as either Requirement or Feature elements.
Requerimientos funcionales + Historias de Usuario + Caracteristicas + Interfaz de Usuario
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 no-funcionales + Performance + Scalability + Security
Read about Requirements
+ Persistence + Transport
Tracing element dependencies Using the Relationship Matrix
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.
The Non-Functional Requirements package specifies the various operational parameters that define the environment in which the system will exist. These are criteria which define performance levels, scalability, security requirements, backup, disaster recovery and other operational requirements.
Fig. 6 Modelo de Requerimientos
El modelo se divide en dos sub-categorías: 1. El paquete contiene los requisitos funcionales de las características que representan el comportamiento funcional y que el sistema en desarrollo debe promover. 2. El paquete de requisitos no funcionales contiene restricciones y niveles de rendimiento del sistema debe cumplir. Por ejemplo los tiempos de respuesta, las transacciones por segundo, la capacidad de seguridad.
custom Requerimientos funcionales Historias de Usuario Functional Requirements describe the 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 características, comportamiento, reglas del negocio y la funcionalidad general que el sistema propuesto debe soportar.
5.2 Historias De Usuario. Según la metodología XP, las historias de usuario son la base para la planificación y definición de las pautas necesarias para la construcción del sistema propuesto. Estas son definidas por el usuario final o cliente y en ellas se detalla el comportamiento que debe tener cada módulo o componente de la aplicación según el punto de vista del usuario. Con estas descripciones, se modelarán los casos de uso.
custom Historias de Usuario Monitoreo General de Vehiculos
Reportes
Gestor de Alarmas
T razar Ruta Vehiculo
Busqueda de Vehiculos
Alarma de Vehiculo Detenido
Reporte Vehiculo Detenido
Reporte de velocidad maxima
Indicadores
Alarmas de Velocidad
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 Vehículo Detenido. Esta alarma se debe disparar cuando un vehículo queda detenido por un tiempo superior al definido por parámetros del sistema, en jornada de transporte.
Historia de Usuario Número: 7
Usuario: Supervisor
Nombre Historia: Alarma de Vehículo Detenido. Prioridad en Negocio: MEDIA
Riesgo en Desarrollo: ALTA
Iteración Asignada: 2
Estimación de Esfuerzo: 4
Programador Responsable: Gabriel Muñoz
Alarma de Velocidad. Esta alarma se deberá disparar cuando un vehículo exceda el umbral de velocidad permitida definido por parámetros de sistema para un vehículo. Historia de Usuario Número: 8
Usuario: Supervisor
Nombre Historia: Alarmas de Velocidad. Prioridad en Negocio: MEDIA
Riesgo en Desarrollo: ALTA
Iteración Asignada: 2
Estimación de Esfuerzo: 4
Programador Responsable: Gabriel Muñoz
Búsqueda de Vehículos. El supervisor accede a un menú desplegable y selecciona de un listado del o los vehículos sobre los que deseará realizar el seguimiento. Historia de Usuario Número: 2
Usuario:
Nombre Historia: Búsqueda de Vehículos. Prioridad en Negocio: ALTA
Riesgo en Desarrollo: BAJA
Iteración Asignada: 1
Estimación de Esfuerzo: 3
Programador Responsable: Gabriel Muñoz
Gestor de Alarmas. El sistema deberá correr de forma periódica un gestor que consulte los indicadores y despliegue ventanas de alarmas cuando se vayan presentando los eventos que disparen dichos indicadores. Historia de Usuario Número: 4
Usuario: Supervisor
Nombre Historia: Gestor de Alarmas. Prioridad en Negocio: MEDIA
Riesgo en Desarrollo: ALTO
Iteración Asignada: 2
Estimación de Esfuerzo: 5
Programador Responsable: Gabriel Muñoz
Indicadores. Se debe realizar consultas periódicas sobre la base de datos y analizar la comparación de estos datos con umbrales y parámetros definidos en el sistema para gatillar indicadores. Historia de Usuario Número: 1
Usuario: Supervisor
Nombre Historia: Indicadores Prioridad en Negocio: BAJA
Riesgo en Desarrollo: ALTA
Iteración Asignada: 3
Estimación de Esfuerzo: 5
Programador Responsable: Miguel Vargas
Monitoreo General de Vehículos. El supervisor observa en pantalla los vehículos que actualmente circulan por el país. Debe realizar acercamientos con la herramienta de Zoom para visualizar el detalle de los vehículos por las calles o carreteras y con ayuda del mouse, arrastrar el mapa para recorrer las calles. Historia de Usuario Número: 1
Usuario:
Nombre Historia: Monitoreo General de Vehículos. Prioridad en Negocio: ALTA
Riesgo en Desarrollo: ALTA
Iteración Asignada: 1
Estimación de Esfuerzo: 5
Programador Responsable: Gabriel Muñoz Reporte de Vehículo Detenido. Este reporte deberá desplegar un listado de los vehículos que quedan detenidos en horarios de trabajo, mostrando la hora y coordenadas donde fue registrado el evento. Historia de Usuario Número: 5
Usuario: Supervisor
Nombre Historia: Reporte Vehículo Detenido. Prioridad en Negocio: ALTA
Riesgo en Desarrollo: MEDIA
Iteración Asignada: 2
Estimación de Esfuerzo: 3
Programador Responsable: Miguel Vargas
Reporte de velocidad máxima. Este reporte deberá desplegar un listado de los vehículos que exceden un umbral de velocidad definida, la hora y las coordenadas donde se registro el evento, la distancia recorrida en el intervalo de muestreo y la velocidad instantánea. Historia de Usuario Número: 6
Usuario: Supervisor
Nombre Historia: Reporte de velocidad máxima. Prioridad en Negocio: ALTA
Riesgo en Desarrollo: MEDIA
Iteración Asignada: 2
Estimación de Esfuerzo: 3
Programador Responsable: Miguel Vargas
Reportes. El Supervisor podrá acceder a un repertorio de vínculos que hacen referencia a los reportes en línea del sistema. Al hacer click sobre los vínculos, se abrirá un cuadro de diálogo que exigirá una fecha a consultar. Al proveer la fecha de argumento, se visualizará una ventana con uno de los reportes que seleccionó.
Historia de Usuario Número: 3
Usuario: Supervisor
Nombre Historia: Reportes. Prioridad en Negocio: BAJA
Riesgo en Desarrollo: BAJO
Iteración Asignada: 2
Estimación de Esfuerzo: 2
Programador Responsable: Miguel Vargas
5.3 Características Características técnicas de las herramientas utilizadas en el desarrollo del sistema. custom Caracteristicas
Features typically describe discrete pieces of functional behavior that yield a specific result.
API Google Maps
Base de datos MySQL
PHP5
Fig. 9 Características
Base de datos MySQL. La base de datos utilizada será MySQL 5.1 o en su última versión. PHP5. El lenguaje de programación será PHP5. API Google Maps. El sistema usará la API de Google Maps para el despliegue y búsqueda de vehículos
Interfaz de Usuario. El modelo de interfaz de usuario define las pautas para la implementación de la representación de información que el usuario final necesita ver y ocupar. En este modelo, se propone el inicio de una estructura que irá evolucionando y ajustando a la necesidad del cliente. custom Interfaz de Usuario Pantalla Principal The User Interface package contains high level descriptions of end-user visible screens and forms which are required to support the proposed system.
Busqueda Vehiculos
GMaps
Screen elements model proposed user interface components.
Reportes UI Controls model various common user interface control types «navigate» Reporte de Velocidad
Reporte Velocidad
«navigate» Reporte Vehiculo Detenido
Reporte Vehiculo Detenido
Fig. 10 Interfaz de Usuario
Pantalla Principal. Esta interfaz representa el módulo principal por el cual el usuario accederá a las diversas funcionalidades del sistema.
Reporte de Velocidad Este reporte, desplegará un listado de aquellos vehículos que exceden la velocidad máxima permitida para un vehículo dado.
Reporte Vehículo Detenido Este reporte desplegará un listado de aquellos vehículos que quedan detenidos en terreno durante horarios de producción.
5.4 Modelo de Casos de Uso. El Modelo de Casos de Uso es fundamental para la planificación de un proyecto para la metodología XP, sienta las bases para el comportamiento de una aplicación a desarrollar según las necesidades y requerimientos del cliente. 5.4.1 Modelo de Casos de Uso - (Use Case diagram) En estos casos de uso, se describirán los modelos de comportamiento de la aplicación definido en los requerimientos de sistema. uc Modelo de Casos de Uso Caso de uso Principal
Administracion
Serv idor Sistema Recepcion Datos
+ Alertas
+ Editar Vehiculo
+ Conectar Servidor Socket T CP
+ Autenticar
+ Ingresar Vehiculo
+ Grabar Informacion
+ Buscar Vehiculo
+ Listar Vehiculos
+ Iniciar Cliente Datos
+ Desplegar Ubicación
+ Respaldar Datos
+ Recibir Datos GPS
+ Obtener Reporte
+ Transformar Datos
Serv idor Sistema Alerta + Enviar Alertas y Registro + Recibir Datos + Registrar Datos + T ransformar Datos + Verificar Alertas
Actores Configurar Alerta Alerta Velocidad
Alerta Horas
+ GPS
+ Autentificar
+ Administrador
+ AccederSistema Alertas
+ Acceder Sistema Alertas
+ Gestionar Alertas
+ Base Datos
+ Desplegar via Web
+ Desplegar via Web
+ Mostrar Alertas
+ Supervisor
+ Generar Alerta
+ Generar Alerta
+ Seleccionar Vehiculo
+ Usuario
Fig. 11 Modelo de Casos de Uso
5.4.2 Actores - (Use Case diagram). Aquí se describirán los distintos actores del sistema, las responsabilidades que competen a cada perfil de usuario o de entidad que interactúa con el sistema. uc Actores
Usuario
GPS
Superv isor
Base Datos
Administrador
Fig. 12 Actores
Administrador. Usuario responsable de la configuración de los vehículos, patrones y parámetros del sistema. Base Datos. Actor intrínseco del sistema, encargado de proveer y registrar información.
GPS. Actor responsable de proveer periódicamente las coordenadas de cada elemento configurado en el sistema. Supervisor. Usuario encargado de realizar consultas y explotación del sistema. Usuario. Este actor es general para la autenticación de identidad de un usuario de sistema.
5.4.3 Alerta Horas - (Use Case diagram). Este caso de uso describe las acciones necesarias para la generación de alertas en línea cuando un vehículo se detiene en horas de producción. uc Alerta Horas Alertas Hora
Acceder Sistema Alertas
Generar Alerta Usuario (from Actores)
Base Datos (from Actores)
Desplegar v ia Web
Fig. 13 Alerta Horas
CASO DE USO:
Alerta Horas
ACTORES:
Usuario, Base Datos
PROPÓSITO:
Generar alertas cuando un vehículo se detiene
DESCRIPCIÓN:
Este caso de uso describe las acciones necesarias para la generación de alertas en línea cuando un vehículo se detiene en horas de producción.
TIPO:
BAJA
PRE CONDICIÓN:
Recibir fecha como parámetro.
POST CONDICIÓN:
No existe
PASOS:
Proveer fecha
ALTERNATIVAS:
Desplegar vía Web. Desplegar las alertas generadas en pantalla. Generar Alerta. Caso de uso responsable de trabajar los datos del Sistema Alertas.
Acceder Sistema Alertas. Caso de uso responsable de acceder a datos generados por el Sistema de Alertas.
5.4.4 Alerta Velocidad - (Use Case diagram). Este caso de uso describe las acciones necesarias para la generación de alertas en línea cuando un vehículo exceda la velocidad permitida, durante el trayecto en su jornada. uc Alerta Velocidad Alerta Velocidad
AccederSistema Alertas
Base Datos Usuario
Generar Alerta
(from Actores)
(from Actores)
Desplegar v ia Web
Fig. 14 Alerta de Velocidad.
CASO DE USO:
Alerta Velocidad
ACTORES:
Usuario, Base Datos
PROPÓSITO:
Generar alertas cuando un vehículo excede una velocidad máxima
DESCRIPCIÓN:
Este caso de uso describe las acciones necesarias para la generación de alertas en línea cuando un vehículo excede la velocidad permitida, durante el trayecto en su jornada.
TIPO:
BAJA
PRE CONDICIÓN:
Recibir fecha como parámetro
POST CONDICIÓN:
No existe
CASO DE USO:
Alerta Velocidad
PASOS:
Proveer fecha
ALTERNATIVAS:
Desplegar vía Web. Desplegar las alertas generadas en pantalla. Generar Alerta. Caso de uso responsable de trabajar los datos del Sistema Alertas.
Acceder Sistema Alertas. Caso de uso responsable de acceder a datos generados por el Sistema de Alertas.
5.4.5 Configurar Alerta - (Use Case diagram) Este caso de uso le otorga al usuario Administrador la facultad de configurar las opciones y atributos de las alertas que el sistema irá generando en línea en función de los eventos que se crearán durante la explotación del sistema.
uc Configurar Alerta Configurar Alertas
Autentificar
Seleccionar Vehiculo
«include» Administrador
Base Datos (from Actores)
(from Actores) Mostrar Alertas
Gestionar Alertas
Fig. 15 Configurar Alerta
CASO DE USO:
Configurar Alerta
ACTORES:
Administrador, Base Datos
PROPÓSITO:
Configurar intervalos de hora y velocidad máxima por vehículo
DESCRIPCIÓN:
Este caso de uso le otorga al usuario Administrador la facultad de configurar las opciones y atributos de las alertas que el sistema irá generando en línea en función de los eventos que se irán generando durante la explotación del sistema.
TIPO:
BAJA
CASO DE USO:
Configurar Alerta
PRE CONDICIÓN:
Seleccionar un vehículo
POST CONDICIÓN:
No existe
PASOS:
Listar vehículos, seleccionar una fila, editar las columnas
ALTERNATIVAS:
Autentificar. Caso de uso responsable del inicio de sesión de un usuario del sistema. Gestionar Alertas. Caso de uso responsable de la edición y registro de la configuración de la alerta. Mostrar Alertas. Caso de uso responsable del despliegue de las alertas generadas a la pantalla del usuario. Seleccionar Vehículo. Caso de uso responsable de la selección de vehículos desplegados.
5.4.6 Servidor Sistema Alerta - (Use Case diagram) Este caso de uso describe el comportamiento del Sistema de Alertas, una aplicación residente y servidora encargada de la recepción, captura y transformación de los paquetes enviados por los nodos GPS para ser almacenados en la base de datos y posteriormente ser notificados al usuario.
uc Sistema Alerta Sistema Alerta
Recibir Datos
GPS (from Actores)
Transformar Datos
Base Datos (from Actores) Registrar Datos
Usuario
Verificar Alertas
(from Actores)
Env iar Alertas y Registro
Fig. 16 Servidor Sistema de Alerta
CASO DE USO:
Servidor Sistema de Alerta
ACTORES:
Usuario, Base Datos
PROPÓSITO:
Extraer de los paquetes del GPS la información útil para las alertas
CASO DE USO:
Servidor Sistema de Alerta
DESCRIPCIÓN:
Este caso de uso describe el comportamiento del Sistema de Alertas, una aplicación residente y servidora encargada de la recepción, captura y transformación de los paquetes enviados por los nodos GPS para ser almacenados en la base de datos y posteriormente ser notificados al usuario.
TIPO:
ALTA
PRE CONDICIÓN:
Libre
POST CONDICIÓN:
No existe
PASOS:
Aplicación residente en memoria, se activa automáticamente por S.O.
ALTERNATIVAS:
Enviar Alertas y Registro. Caso de uso responsable del despacho de la notificación de la alerta generada hacia el usuario. Recibir Datos. Caso de uso responsable de recibir del actor GPS, los paquetes de datos para ser registrados en la base de datos. Registrar Datos. Caso de uso responsable de registrar los datos trabajados en la base de datos. Transformar Datos. Caso de uso responsable de analizar, segmentar y estructurar los datos provenientes del GPS. Verificar Alertas. Caso de uso responsable de validar los registros para su posterior generación de alertas.
5.4.7 Servidor Sistema Recepción Datos - (Use Case diagram) En este caso de uso, la precondición parte con el inicio de conexión al Servidor Socket TCP, para luego iniciar la conexión a la Base de Datos, solo así se podrán recibir los datos desde el nodo GPS y su posterior segmentación, transformación y almacenamiento en la Base de Datos. uc Sistema Recepcion Datos Sistema Recepcion Datos
Conectar Serv idor Socket TCP
«include»
Iniciar Cliente Datos
«include»
GPS
Base Datos Recibir Datos GPS
(from Actores)
Transformar Datos
Grabar Informacion
Fig. 17 Servidor Sistema de Recepción de Datos
(from Actores)
CASO DE USO:
Servidor sistema de Recepción de Datos
ACTORES:
GPS, Base Datos
PROPÓSITO:
Captura de paquetes, transformación y almacenamiento de datos en BD.
DESCRIPCIÓN:
Este caso de uso, levanta la conexión el Servidor Socket TCP, para luego iniciar la conexión a la Base de Datos, solo así se podrán recibir los datos desde el nodo GPS y su posterior segmentación, transformación y almacenamiento en la Base de Datos.
TIPO:
ALTA
PRE CONDICIÓN:
Permiso de acceso
POST CONDICIÓN:
No existe
PASOS:
Aplicación residente en memoria, se activa automáticamente por S.O.
ALTERNATIVAS:
Conectar Servidor Socket TCP. Este caso de uso tiene la responsabilidad de iniciar la conexión con el Servidor Socket TCP, que gestiona el puerto que recepciona los paquetes del GPS. Grabar Información. Este caso de uso se responsabiliza de almacenar la estructura trabajada de los datos del GPS hacia la base de datos. Iniciar Cliente Datos. Este caso de uso, se responsabiliza de iniciar la conexión con la base de datos y mediar los traspasos de los datos provenientes del Servidor Socket TCP. Recibir Datos GPS. Este caso de uso se responsabiliza de recibir los paquetes provenientes del nodo GPS. Transformar Datos.
Este caso de uso se responsabiliza de segmentar los datos capturados, y transformarlos a una estructura de información adecuada para la base de datos. 5.4.8 Caso de uso Principal - (Use Case diagram) Este caso de uso es responsable de proveer al usuario la funcionalidad del sistema, proveyendo los accesos a los reportes, paneles de la monitorización de alarmas y a los mapas de ubicación de los vehículos.
uc Caso de uso principal Monitorear Vehiculo
Autenticar
«include»
Buscar Vehiculo
Alertas
Base Datos
Usuario
«include»
Obtener Reporte
«include»
Desplegar Ubicación
Fig. 18 Caso de Uso Principal
CASO DE USO:
Caso de uso principal
ACTORES:
Usuario, Base Datos
PROPÓSITO:
Proveer la gestión para la monitorización de vehículos en tránsito
DESCRIPCIÓN:
Este caso de uso es responsable de proveer al usuario la funcionalidad del sistema, proveyendo los accesos a los reportes, paneles de la monitorización
CASO DE USO:
Caso de uso principal de alarmas y a los mapas de ubicación de los vehículos.
TIPO:
ALTA
PRE CONDICIÓN:
Inicio de sesión de usuarios
POST CONDICIÓN:
No existe
PASOS:
Iniciar la sesión de usuario
ALTERNATIVAS:
Alertas. Caso de uso responsable del despliegue de alertas en línea con registros ingresados recientemente del servicio de recepción de paquetes GPS. Autenticar. Caso de uso responsable del inicio de sesión de un usuario al sistema.
5.4.8.1 Autenticar - (Sequence diagram) Este diagrama de secuencia explica la secuencia de pasos necesarios para el inicio de una sesión de usuario, proveyendo la seguridad necesaria al sistema y restringiendo su uso exclusivo a usuarios registrados. sd Autencicar
Usuario
Pantalla Ingreso
AutenticarUsuario(user, pass)
Autenticacion
Usuarios
Base Datos
AutenticarUsuario(user, pass) ValidaUsuario(user, pass) BuscarUsuario(user)
Validacion(pass)
Fig. 19 Autenticar
Autenticación. Este controlador se encarga de mediar el flujo de consulta y respuesta entre el formulario y la interfaz hacia la base de datos.
• Pantalla Ingreso. Esta vista corresponde al formulario de autenticación, donde el usuario ingresa su cuenta y contraseña.
• Usuarios. Esta entidad es la interfaz hacia la base de datos que evalúa la real identidad del usuario que intenta ingresar.
Buscar Vehículo. Caso de uso responsable de la búsqueda y selección de un vehículo para su utilización dentro del sistema.
5.4.8.2 Buscar Vehículo - (Sequence diagram) Este diagrama de secuencia describe los pasos de búsqueda de un vehículo para su utilización dentro del sistema, tanto en operaciones diversas como en reportes. sd Buscar Vehiculo
Usuario
Formulario Busqueda
Busqueda
Vehiculos
Base Datos
BuscarVehiculo(patente) BuscarVehiculo(patente)
TraerVehiculo(patente) BuscaVehiculo(patente)
(from Actores)
(from Actores)
Fig. 20 Buscar Vehículo
8. Búsqueda. Este controlador redirige el flujo de la consulta y respuesta entre el formulario y la interfaz a la base de datos.
•
Formulario Búsqueda. Esta vista corresponde al formulario de búsqueda, donde el usuario provee una patente, o la selecciona desde un listado de vehículos existentes.
• Vehículos.
Esta entidad corresponde a la interfaz que se encarga de buscar el vehículo con la patente recibida. • •
Desplegar Ubicación. Caso de uso responsable de desplegar la ubicación del vehículo en el mapa.
5.4.8.3 Desplegar Ubicación - (Communication diagram) En este diagrama de actividades, el usuario recurre a la vista "Desplegar Mapa", para consultar el posicionamiento del vehículo, y este controlador redirige el flujo de la consulta a la entidad "Vehículos" para obtener sus coordenadas en la "Base de Datos". Alternativamente, la vista "Desplegar Mapa" también recurre al controlador "Trazar Ruta" para redirigir la consulta a "Vehículos" por el tramo recorrido, retornando la secuencia de coordenadas para el posterior despliegue de la ruta.
sd Desplegar Ubicación Flujo de actividad para despliegue de ubicación
Posicionar Vehiculo
Buscar Vehiculo «flow»
T ramoRecorrido Desplegar Mapa
Vehiculos
Usuario
Base Datos
(from Actores)
(from Actores)
SecuenciaCoordenadas
Trasar Ruta
Fig. 21 Desplegar Vehículo
•
Desplegar Mapa. Esta vista será la interfaz directa al usuario, donde podrá solicitar al sistema la consulta sobre la ubicación del vehículo, o bien trazar la ruta del trayecto que ha tenido un vehículo en un momento determinado.
4. Posicionar Vehículo. Este controlador, redirige la consulta de posicionamiento que hace el usuario desde el mapa y lo solicita a la entidad vehículos. •
Trazar Ruta. Este controlador recibe la solicitud del usuario para la consulta del tramo recorrido de un vehículo y redirige la consulta a la entidad Vehículos. Asimismo recibe en respuesta la secuencia de coordenadas para que la vista Desplegar Mapa lo dibuje para el usuario.
Vehículos. Esta entidad se encarga de recibir las peticiones de consulta para realizarlas en la base de datos y proveer la respuesta necesaria y requerida. Obtener Reporte. Caso de uso responsable de generar reportes de Velocidad Máxima, Vehículo Detenido, Historial y Distancia Recorrida.
5.4.9 Administración - (Use Case diagram) En este caso de uso, el administrador podrá tener control y gestión de la configuración del sistema.
uc Administracion Administracion Datos
Autenticar
(from Caso de uso Principal) «include»
«include»
Listar Vehiculos
Administrador «include»
(from Actores)
«include»
Base Datos (from Actores)
Editar Vehiculo Ingresar Vehiculo
Respaldar Datos
Fig. 22 Administración
CASO DE USO:
Administración
ACTORES:
Administrador, Base Datos
PROPÓSITO:
Proveer las herramientas de mantenimiento de configuración al administrador
DESCRIPCIÓN:
En este caso de uso, el administrador podrá tener control y gestión de la configuración del sistema.
TIPO:
BAJA
PRE CONDICIÓN:
El usuario debe estar identificado como administrador
CASO DE USO:
Administración
POST CONDICIÓN: No existe PASOS:
Iniciar sesión de usuario administrador
ALTERNATIVAS:
Editar Vehículo Este caso de uso es responsable de la edición y modificación de datos de un vehículo en la base de datos. Ingresar Vehículo Este caso de uso es responsable del ingreso de un vehículo a la base de datos. Listar Vehículos. Este caso de uso es responsable de disponer para el usuario el listado de vehículos para su uso en la gestión del sistema. Respaldar Datos. Este caso de uso provee la herramienta al usuario para el aseguramiento y respaldo los datos de la base.
5.4.9 Modelo de Datos Las tablas principales donde se centraliza todo el movimiento de los datos son “geocodes” y “userautos”. La tabla “eventos” está reservada para una próxima versión del sistema donde se contempla la gestión de eventos que se generarán a partir del comportamiento de los vehículos en función del tiempo.
Fig. 23 Modelo de Datos sistema de control y posicionamiento de vehículos vía GPS.
Descripción de tablas en Modelo de Datos 9. GEOCODES: Esta tabla registra las coordenadas de los nodos GPS que circulan en terreno, acumulando registros en una razón de 15 segundos aproximadamente. Guarda además los datos de la geoposición de los nodos que notifican su ubicación, la fecha, hora del registro, lugar e identidad del vehículo en circulación.
10. ALERTAS: Corresponde a una tabla de configuración, en ella de definen en forma descriptiva los tipos de alertas que se gestionarán en el sistema. 11. ALERT_HORA: Esta es una tabla de configuración y está estrechamente vinculada con la tabla ALERTAS, y en ella se configuran los horarios de inicio y término de la jornada de trabajo. 12. ALERT_VEL: Esta es una tabla de configuración vinculada con la tabla ALERTAS, en ella se configura la velocidad máxima que puede tener un vehículo. 13. USUARIOS: Esta tabla almacena la configuración de los usuarios que pueden acceder y hacer uso del sistema, como también al personal que tendrá asignado uno o más vehículos a ser monitorizados en el sistema. 14. USERAUTOS: Esta tabla registra la configuración de los vehículos que estarán asignados a los usuarios y la configuración de patente, modelo y marca del vehículo, y su capacidad de consumo por kilometraje. 15. CONFIGURACION: Esta tabla es de uso específico dentro del sistema y es empleada para la personalización de consultas a la base de datos, describiendo las tablas, los campos, las relaciones y condiciones específicas para la ejecución y despliegue de información dentro de algunos módulos del sistema. 16. SOCKETCONFIG: Esta tabla es de uso específico dentro del sistema y es empleado para registrar temporalmente los paquetes que son recibidos de los nodos por la aplicación servidora para luego ser segmentados, transformados e insertados en la tabla GEOCODES. 17. EVENTOS: Esta tabla está reservada para una próxima versión del sistema, donde se gestionará los eventos generados por los vehículos en circulación en función del comportamiento dentro de la jornada de trabajo, con la finalidad de generar indicadores visualizables en pantalla.
5.5 Construcción del sistema 5.5.1 Interfaces de búsqueda y despliegue de la información de un móvil La secuencia de acceso a los diferentes niveles módulos y funcionalidades del sistema, se inicia con la autenticación del usuario, el que será validado en el momento de iniciar su sesión.
Una vez iniciada la sesión, el usuario tendrá a su disposición el control centralizado del sistema, con un repertorio de opciones agrupados en menús separados, desde los cuales podrá acceder a la configuración, reportes históricos y control del mapa, donde podrá visualizar los vehículos en tránsito y sus rutas, como también las alertas en línea que se irán desplegando en el transcurso del tiempo.
5.5.1.1 ACCESO AL SISTEMA
1 2 3 Fig. 24 Interfaz de conexión al sistema
Para ingresar al sistema es necesaria la identificación por un usuario y contraseña 1.- Ingreso de usuario 2.- Ingreso de Password 3.- Ingreso al Sistema
5.5.1.2 MENU PRINCIPAL 1
2
4
3
Fig. 25 Despliegue de Menú principal.
Una vez ingresado nos encontraremos 4 menús, que nos permitirán la administración del sistema, tanto como vehículos, alertas y reportes.
5.6.1.3 SUBMENU CONFIGURACIÓN DE ALERTAS
1 2 Fig. 26 Configuración de Alertas
1 Opción Hora: Permite configurar alertas por hora tanto para agregar, borrar o editar estas alertas. 2 Opción Velocidad: Permite configurar alertas de velocidad tanto para editar, agregar, borrar alertas.
5.5.1.4 SUBMENU REPORTES
1
2
3
4
Fig. 27 Submenú Reportes
1 2 3 4
Opción Velocidad Máxima: Permite visializar el reporte de velocidad máxima Opción Vehículo Detenido. Opción Distancia Recorrida Historial: Despliega todos los registros de los vehículos de este usuario, donde donde se podrá ver fecha, hora, latitud, longitud y dirección de cada registro.
5.5.1.5 Configurar Vehículos:
Fig. 28 Submenú Configurar Vehículos
Esta opción permite ingresar a un formulario para agregar, editar, o eliminar un vehículo.
5.5.1.6 Submenú Control Mapa.
Fig. 29 Submenú control mapa
En esta opción se ingresa al Panel Control Mapa, desde donde se puede analizar el recorrido de los vehículos.
5.5.1.7 Submenú Alertas de Horas Formulario Visualización
1
2
Fig. 30 Submenú Alertas Horas
1 Formulario de visualización de alertas Hora. Muestra el nro. de alerta, patente, hora inicio de alerta y hora final de alerta. 2 Opciones Formulario: Eliminar un registro de alerta. Recargar Tabla. Agregar o eliminar columnas a visualizar Editar un registro seleccionado. Agregar una nueva alerta/hora.
5.5.1.8 Agregar Alertas.
5.9.1 .8
Fig. 31 Submenú agregar alertas
Formulario de ingreso de alertas Seleccionar una patente, ingresar hora inicio y término de una alerta.
5.5.1.9 Editar Alertas.
5.9.1.9
Fig. 32 Formulario de edición de alerta.
Al seleccionar una alerta y presionar el botón editar se accede a actualizar las horas de esa alerta.
5.5.1.10 Submenú Eliminar Alerta.
Fig. 33 Submenú Eliminar Alerta
Permite eliminar un registro seleccionado.
5.5.1.11 Submenú Alerta de Velocidad.
1
2
Fig. 34 Submenú Alerta de Velocidad
1 Visualización de alertas de velocidad, se visualiza nro. de alerta, patente y velocidad máxima para ese vehículo. 2 Opciones Formulario. Eliminar un registro de alerta Recargar tabla. Agregar o eliminar columnas a visualizar Editar un registro seleccionado. Agregar una nueva alerta velocidad.
5.5.1.12 Agregar Alerta de Velocidad
Fig. 35 Agregar Alerta velocidad
En este formulario se permite ingresar una nueva alerta de velocidad, seleccionando una patente y agregando la velocidad que no debe exceder.
5.5.1.13 Editar Alerta de Velocidad
Fig. 36 Editar alerta velocidad
Al seleccionar una fila, se puede editar la alerta, modificando la velocidad máxima
5.5.1.14 Eliminar Alerta de Velocidad.
Fig. 37 Eliminar alerta velocidad
Al seleccionar una fila se permite eliminar la alerta.
5.5.1.15 Reporte Vehículos / Velocidad Máxima.
Fig. 38 Reporte de vehículos velocidad máxima
Presionando sobre la opción de reporte velocidad máxima, aparecerá un formulario de ingreso de fecha a consultar, en este formulario deberá ingresar la fecha para buscar vehículos que sobre sobrepasaron la velocidad máxima.
Fig. 39 Reporte de vehículos que sobrepasaron la velocidad máxima establecida
El reporte que se despliega, muestra aquellos vehículos que sobrepasaron la velocidad máxima definida en la configuración para ese vehículo. Agrupado por períodos de una hora, figurará la velocidad máxima registrada en ese intervalo. Adicionalmente figuran columnas de la cantidad de segundos que mantuvo la velocidad y las coordenadas donde se registró el vehículo en ese instante.
5.5.1.16 Reporte Vehículo Detenido
Fig. 40 Formulario ingreso de fecha.
Presione reporte velocidad máxima y aparecerá un formulario de ingreso de fecha a consultar. Posteriormente, se listarán aquellos vehículos que han permanecido detenidos durante intervalos de una hora. Se desplegarán columnas donde figura la cantidad de tiempo detenido, y las coordenadas donde se detuvo.
Fig. 41 Reporte de vehículos detenidos
5.5.1.17 Reporte Distancia Recorrida
Fig. 42 Selección de vehículo y fecha
Primero se debe seleccionar desde un listado, la patente de un vehículo , y a continuación elegir una fecha a consultar.
A continuación se listará en intervalos de una hora, la distancia en kilómetros que ha recorrido el vehículo durante el tiempo y a la velocidad aproximada figurados en las columnas Tiempo y Km/h. Las columnas de Tiempo, Distancia y Consumo Total, mostrarán en forma acumulada en función del tiempo, el consumo acumulado en función de las distancias por tiempos recorridos en cada tramo. Adicionalmente se muestran las columnas de las coordenadas de referencia, donde se registra la ubicación del vehículo durante esos intervalos.
Fig. 43 Reporte de Distancia Recorrida
Capítulo 6: CONCLUSIÓN
A la vista del trabajo realizado, se puede concluir que los objetivos planteados inicialmente se cumplieron en su totalidad,
encontrándose el sistema
actualmente disponible y operativo para cumplir con las funcionalidades propuestas inicialmente:
- Crear una interfaz gráfica que permita visualizar la ubicación y recorrido de los móviles. Se desarrolló un sistema informático, orientado a Web, paramétrico y autoconfigurable, utilizando herramientas de tipo
open source, con una
interfaz gráfica de navegación intuitiva.
- Crear reportes de gestión que faciliten la administración de los móviles. La información capturada puede ser
consultada en forma paramétrica y
desplegada en el panel diseñado para visualización y seguimiento de los móviles.
-
Crear alertas que faciliten la administración de los móviles. Se incluyó el registro paramétrico de alertas controlables de velocidad y tiempo,
desplegando gráficamente el estado de un móvil mediante la
utilización de cartografía digital, dejando abierta la posibilidad de agregar alertas por otros conceptos.
- Presentar el estado del arte de la tecnología de los GPS y su uso en control de flota. Se detalló las principales características de la tecnología GPS, su estado actual, ventajas y desventajas de uso, elementos componentes y principales marcas y empresas proveedoras en el mercado nacional.
La metodología XP, definida inicialmente para el desarrollo del sistema y cuyas características principales fueron ampliamente detalladas, fue aplicada en forma eficiente, utilizándose la
programación en parejas,
incorporando
activamente al cliente final en todas las modificaciones y correcciones, y realizando entregas de validación periódicas según se avanzó con el desarrollo.
Para el desarrollo del proyecto, se asignaron distintos roles dentro del grupo, lográndose con ello subdividir las tareas a realizar, y concentrar en cada una las mejores habilidades de cada integrante.
Se realizaron pruebas basadas en la información capturada desde el receptor GPS instalado en un grupo de vehículos, y almacenada en una base de datos diseñada, para un rango de fecha y tiempo, las que entregaron los resultados esperados. Se probó la interfaz construida, la que
permite una operación
eficiente y una navegación fluida.
La estructura modular y paramétrica con que se diseñó la solución, otorga la posibilidad de incorporar rápidamente funcionalidades futuras, de acuerdo al eventual crecimiento del producto una vez comercializado.
Esperamos con todo esto, haber contribuido a entregar una visión actual del estado de la tecnología GPS, sus fundamentos técnicos, potencialidades y ventajas de utilización aplicadas sobre el desarrollo de un sistema informático.
Capítulo 7: BIBLIOGRAFÍA lan Somerville, Ingeniería de Software, 2007, Pearson, Addison Wesley, 2005. ISBN: 84-7829-074-5; Editorial: Pearson, Addson Wesley; Año 2005; 712 páginas. URL: http://www.scribd.com/doc/25664820/Ingenieria-de-Software-IanSommerville-7ma-Edicion BIB.XP6: Pag. 363. Urbina López Diego Alejandro, Informe “Programación Extrema” Universidad César Vallejo (UCV), Lima Norte 2009; 11 páginas. URL: http://www.scribd.com/doc/15250014/Programming-Xtreme-Inform-UcvUniversity BIB.XP3: Pag. 2; BIB.XP4: Pag. 11; BIB.XP5: Pag. 10; BIB.XP8: Pag. 3 - 5 Zambrano Jiménez Solange, Juan Carlos León, Laura Otaiza Gómez. Informe “Programación Extrema” Universidad de Los Andes Mérida Colombia, Febrero 2010; 28 páginas. URL: http://www.scribd.com/doc/26495149/Programacion-extrema-Informe BIB.XP1: Pag. 5; BIB.XP2: Pag. 7;BIB.XP7: Pag. 24 ;BIB.XP9: Pag. 10; BIB.XP10: Pag. 12. Google Code, Alojamiento de proyectos; Fecha Consulta: 18 Julio 2010 BIB.GC1: URL: http://code.google.com/p/support/wiki/GettingStarted BIB.GC2: URL: http://code.google.com/intl/es-ES/projecthosting
7.1 LINKS DE ACCESO A DOCUMENTACION DESDE INTERNET http://www.elgps.com/documentos/comofuncionagps/comofuncionagps.html Cómo funciona el GPS en cinco pasos lógicos. Autor: Trimble Navigation Limited. Fecha última visita: 25/07/2010 http://escuadronfrontera.blogspot.com/2008/07/el-g-p-s.html El GPS, partes del sistema de posicionamiento global. Autor: No se menciona. Fecha última visita: 25/07/2010 http://www.scribd.com/doc/2567422/el-funcionamiento-del-gps Segmentos y componentes del sistema GPS. Autor: No se menciona.
Fecha última visita: 25/07/2010
http://homepages.mty.itesm.mx/al584299/mypaper.htm Historia , cronología , funcionamiento y aplicación del “GPS” a través de tres décadas. Autor: Ramiro Jesús Ayala Arizpe. Fecha última visita: 22/06/2010 http://www.infoaventura.com/reportaje.asp?Id=13 Ventajas del GPS respecto a los sistemas habituales de orientación.
Autor: No se menciona.
Fecha última visita: 25/07/2010
http://www.asifunciona.com/electronica/af_gps/af_gps_7.htm Sitio Web educativo. Autor: No se menciona.
Fecha última visita: 26/07/2010
Principales Empresas nacionales proveedoras del servicio GPS http://www.daycro.cl/home.php?e[1]=1&e[2]=5 Sitio Web Corporativo Autor: No se menciona.
Fecha última visita: 23/07/2010
http://gismac-gps.cl Sitio Web Corporativo Autor: No se menciona.
Fecha última visita: 24/06/2010
http://www.localizagps.cl Sitio Web Corporativo Autor: No se menciona.
Fecha última visita: 25/07/2010
http://www.gpschile.com Sitio Web Corporativo Autor: No se menciona.
Fecha última visita: 23/07/2010
http://www.gpstrace.cl Sitio Web Corporativo Autor: No se menciona.
Fecha última visita: 20/05/2010
http://www.movilmaster.cl Sitio Web Corporativo Autor: No se menciona.
Fecha última visita: 26/07/2010
View more...
Comments
