Propuesta de Servicios de Desarrollo

Cliente: Empresa Municipal de Movilidad del Municipio de Cuenca (EMOV)
Contacto: Ing. Claudio Crespo, Director de Planificación de la Empresa de Movilidad (EMOV) del Municipio de Cuenca
Fecha: 2 de Febrero de 2015

Por medio de la presente, PlexiFactory presenta su propuesta de Servicios de Desarrollo de una Plataforma de Operación para el Sistema de Parqueo Rotativo de la Ciudad de Cuenca. Esta propuesta se enmarca dentro de un proceso de ampliación de la cobertura del sistema de parqueo, combinado con una optimización de recursos de control. preliminares * La Empresa de Movilidad del Municipio de Cuenca (EMOV) será el Cliente de la propuesta. * El Cliente ha requerido información técnica y comercial para esta Plataforma, incluyendo todos los componentes necesarios para su operación, que incluyen (1) el pago del servicio por parte del usuario, (2) el registro de uso del servicio, (3) el control de usuarios que podrían haber excedido su tiempo y el cobro de las consiguientes multas por infracción y (4) un módulo de reportes para toma de decisiones.

* Existe información que por su naturaleza es necesaria que PlexiFactory reciba como parte de este proceso y que podrá ser considerada confidencial por el Cliente y viceversa. Se procederá a la firma de Acuerdos de confidencialidad entre PlexiFactory y el Cliente. De considerarse necesario, y de acuerdo a las instrucciones del cliente, PlexiFactory se compromete a destruir toda información digital y física recibida desde el Cliente una vez que el proyecto se considere entregado.

* La presente propuesta es propiedad intelectual de PlexiFactory y es confidencial entre la EMOV y PlexiFactory. No se podrá compartir información parcial o total de la misma a ningún tercero. PlexiFactory podrá utilizar la metodología y tecnología descrita en el presente documento en otros procesos de licitación.

* Se han tomado en cuenta las siguientes premisas como guías de la solución: * Se construirá una plataforma de muy simple operación, de uso masivo. * Se respetará en la medida de lo posible la participación de los negocios que actualmente venden las tarjetas de prepago de Parqueo. * Se generará una plataforma escalable, que permita adicionar áreas de parqueo de manera rápida, con un marginal mínimo de costo en cuanto a control. * Se generarán maneras redundantes de pagar por el servicio. * El resultado económico del proceso deberá ser positivo. Es decir que el Cliente deberá percibir un flujo positivo de dinero tomando en cuenta sus Ingresos y sus Costos Operativos. Se deberá tomar en cuenta además el flujo de Gastos de Capital invertido en Hardware y Software, de acuerdo a lo planteado y aprobado en la propuesta.

Nuestra propuesta
La solución propuesta por PlexiFactory está compuesta de cuatro módulos: * Módulo de Registro de Usuario * Módulo de Pago del Servicio * Módulo de Registro de Uso del Servicio * Módulo de Control de Uso del Servicio * Módulo de Reportes e Inteligencia de Negocios
Para implementar estos módulos, se van a desarrollar tres Plataformas de Soporte a través de las cuales el usuario puede hacer uso del servicio, dos de ellas son automáticas y una manual: * Plataforma Móvil Smartphone [Automática]. * Plataforma Teléfono Móvil [Automática]. * Compra Manual en Local [Manual].
Se explican en detalle estas plataformas de soporte más adelante.
El desarrollo de estos módulos y plataformas se hará en tres fases, inicialmente identificadas: * Fase I: Prototipo. * Fase II: Desarrollo y automatización. * Fase III: Migración del Sistema

* Fase I – Prototipo.
Esta fase incluye el desarrollo de un simulador del Nuevo Sistema en un archivo Excel. Este simulador servirá para validar los conceptos de Pago, Uso de Servicio, Control y Reportes con el Cliente.
El Cliente desde el inicio proveerá información que ayude a dimensionar el sistema en términos de compras de tarjetas, ingresos del sistema, número de usuarios estimados, zonas con mayor afluencia, etc.
Si bien los casos de uso y los escenarios incluidos se los definirá de manera manual, la ventaja de generar un prototipo, es que en muy poco tiempo, el Cliente tendrá una idea clara del funcionamiento del sistema y podrá validar si es que necesita información adicional o no.
El prototipo incluirá registros de pago y uso de servicio en todas las plataformas automáticas y manuales aprobadas por el Cliente. Se generarán miles de datos simulados dentro del prototipo, que permitirán la validación del funcionamiento del sistema. Todos los reportes a ser generados en el sistema una vez terminado se incluirán también en el prototipo, para que de esta forma los usuarios finales tengan una idea clara de los indicadores y columnas que van a requerir en cada uno de ellos.
El prototipo no incluirá gráficos de las zonas de parqueo, conexión con una base de datos ni con sistemas externos de pago. Será un simulador de la realidad, con automatización muy básica, la mínima necesaria para que el Cliente valide el proceso.
Una vez que el Prototipo ha sido estudiado y validado, se procederá a la construcción del sistema final. Se ha escogido Excel como la plataforma básica de desarrollo por la rapidez y flexibilidad que tiene para realizar cambios en su estructura, generar reportes adicionales, simular bases de datos, etc.

* Fase II – Desarrollo y Automatización.
Esta fase comprende el desarrollar todos los módulos y plataformas del sistema, en las tecnologías seleccionadas. El desarrollo se lo hará utilizando recursos locales, que serán quienes otorguen soporte al sistema una vez entregado. Esta fase tendrá como base el prototipo previamente aprobado, y un dimensionamiento inicial, con base en la información del sistema actual provista por el Cliente.

El Desarrollo se hará por equipos y utilizando principalmente metodología de desarrollo rápido (Scrum), donde se definirán semanalmente los objetivos y requerimientos a ser desarrollados por cada equipo y éstos se implementarán de acuerdo a este plan.

Se prevé que en un inicio un equipo se dedique a implementar el back-end del sistema, comprendido con su base de datos, conexión de redes, etc., que incluiría toda la base del sistema, mientras que otro equipo se dedicaría al desarrollo del Front-End, es decir todos los aplicativos que permitirán al usuario Pagar y Registrar el uso del servicio. En la sección “Descripción Detallada de Requerimientos” se documentan los requerimientos de la plataforma.

Se tendrán reuniones bi-semanales de avance con el Cliente y se enviarán minutas semanales que incluyan las actividades realizadas y el estado de progreso de cada plataforma. Estos indicadores serán acordados con el cliente previo el inicio de la Fase II.

* Fase III – Migración de Sistema
La última fase la constituye la migración del sistema actual al sistema nuevo. Aquí se incluirán elementos de sociabilización y comunicación, así como la definición del mejor plan que permita, con el menor riesgo posible, empezar el uso del nuevo sistema.

Se recomienda inicialmente tener un período de “marcha blanca”, o uso paralelo de ambos sistemas, dando incentivos de precio o tiempo adicional a las personas que utilicen el sistema. Esto permitirá validar la robustez y capacidad de los sistemas instalados. Luego de que este período termine, se procederá a validar la estabilidad del sistema y pasar o no a la siguiente fase, o volver a realizar cambios adicionales a la misma.

Descripción Detallada de Requerimientos
Se explica la propuesta de cada de los módulos anteriormente mencionados: * Módulo de Registro de Usuario
Este módulo permitirá que los usuarios de Smartphones y SMS puedan registrar su teléfono en la aplicación. El usuario una vez que descargue la aplicación desde el App Store de su preferencia deberá:

* Plataforma Smartphone * Solicitar un código de activación, que le llegará vía SMS * Una vez ingresado el código deberá ingresar datos básicos de identificación * Nombre Completo * Cédula de Identidad * Correo electrónico

* Plataforma SMS * Deberá enviar un SMS con la palabra ACTIVAR a un número de teléfono predeterminado. * No se pedirán más datos.

Si un usuario realizó la activación vía Smartphone, podrá realizar pagos vía SMS sin problema, y viceversa.

* Módulo de Pago del Servicio.
El pago del servicio seguirá siendo previo a su uso (pre-pago), lo que asegura los ingresos para el Cliente y disminuye la posibilidad de cartera vencida. Este es el mismo esquema que se usa en la actualidad a través de la compra de tarjetas de Pre-pago del servicio en locales próximos al sitio de parqueo, en cada cuadra incluida en la cobertura.

El usuario se acerca al local cercano a la zona de parqueo y compra una tarjeta recargable por $1, $5 ó $10 USD. De esta forma los negocios no pierden su participación en el sistema. Las comisiones por venta de estas tarjetas deberían definirse entre el Cliente y los locales. El usuario, una vez que tiene la tarjeta en su poder la debe activar a través de las plataformas de soporte.

Cada tarjeta tiene un número de serie único y la EMOV tendrá un registro de qué tarjetas se repartieron a qué locales. De esta forma, cuando el cliente activa una tarjeta, el Cliente conocerá al instante el nivel de ventas del local participante.

Si el cliente prefiere una transacción manual, el local deberá realizar la activación por el cliente, por valores de $0,25, $0,50, $0,75 ó $1 USD. El proceso de activación será exactamente el mismo que para las tarjetas prepagos, con la diferencia de que el local generará la transacción. Se prevé la entrega de una Tablet, una impresora y servicio de conexión para cada uno de los locales, permitiendo la realización de esta transacción en línea. No se requerirá hardware especial para este efecto.

La información a ingresarse para activar el servicio, en todos los casos será: * El número de serie de la tarjeta. Este número de serie estará internamente ligado al valor de la misma y el local que la expendió. * El número de teléfono celular de la persona que lo activó. De esta manera, la tarjeta no estará ligada a un vehículo en particular sino al teléfono celular de la persona.

Para las plataformas de soporte automáticas el usuario podrá acceder de manera automática a su saldo vigente. Un usuario puede tener más de una tarjeta de pre-pago activa a la vez.

* Módulo de Registro de Uso del Servicio.
El registro del servicio será llevado a cabo inmediatamente después de que el usuario haya escogido una zona de parqueo disponible. El usuario deberá ingresar la siguiente información, para registrar el inicio del uso del parqueo:

* El número de tarjeta de la cual el usuario va a descontar el uso * La placa del vehículo * El número de minutos a ser utilizados (en fracciones de 15 minutos) * La zona de parqueo * La fecha y hora de inicio del servicio (generado automáticamente)

Las plataformas de soporte tendrán la información disponible necesaria para realizar este proceso de manera expedita y sin demoras. El usuario, una vez que haya registrado el uso del servicio, recibirá una confirmación de la hora exacta de inicio y fin del servicio de parqueo.

La zona de parqueo es un concepto nuevo que se introduce en esta propuesta y que permitirá facilitar el control del uso de las zonas de parqueo. Para cada cuadra incluida dentro de la cobertura del servicio existirá señalética que claramente mostrará el código de zona de parqueo. Referirse al Anexo #1 para una explicación más detallada del uso y su propuesta de etiquetado.

Una vez que el usuario registra el inicio de uso del parqueo, el sistema central empezará automáticamente una rutina de revisión de tiempo, conectada al Módulo de Control. Si es que el usuario prefiere realizar el pago a través del proceso manual, es el local quien generará las instrucciones al sistema central con toda la información anteriormente descrita. El proceso interno de generación de registro de uso será el mismo tanto para plataformas automáticas como manuales.

En la plataforma Smartphone, el aplicativo validará la cercanía del usuario con la zona de parqueo, de esta manera previniendo que el usuario ingrese una zona de parqueo distinta. En la plataforma Móvil no se tendrá esa validación.

En la plataforma Smartphone, cuando falten 10 minutos para terminar el tiempo de parqueo, se enviará una alerta al usuario preguntándole si es que quiere extender el servicio o si quiere una alarma cuando falten 5 minutos. En la plataforma Móvil no se tendrá el servicio de alertas, pero el usuario sí podría realizar una extensión vía una opción SMS.

Cuando el usuario libere su puesto de parqueo, deberá ingresar a la aplicación y liberar el sitio. Si lo hace tendrá un bono en minutos dentro de su tarjeta. Si es que no lo hace, el sistema dejará el puesto como abierto y generará una alarma cuando otro usuario quiera utilizarlo.

Como una fase II de la implementación, se permitirá que usuarios regalen minutos a otros usuarios solamente enviando el número celular y el monto a regalar. De esta manera, si un usuario no tiene suficiente dinero en su cuenta, otro usuario se lo podría entregar. Habría que trabajar con el regulador y validar que este servicio sea posible de entregar.

* Módulo de Control de Uso del Servicio
El proceso de control actual, según se explicó, tiene una connotación principalmente manual. Es decir, el personal de EMOV tiene rutas de revisión pre-definidas, donde sus fiscalizadores validan la hora de fin del servicio de parqueo y la comparan con la hora actual, a través de una inspección visual de la tarjeta actualmente utilizada. Existen una serie de reglamentos derivados de esta inspección que pueden determinar que una multa sea asociada con un usuario.

El acercamiento que PlexiFactory propone para este módulo estará basado fuertemente en el análisis histórico de datos de comportamiento de las zonas de parqueo y de la rotación de los usuarios, generando así una ruta óptima de revisión para los fiscalizadores.
A través de algoritmos desarrollados específicamente para esta aplicación, se determinará qué zonas de parqueo tendrán una probabilidad mayor o menor de tener una situación donde sancionar a uno o varios usuarios, y se la incorporará a la ruta de inspección de alguno de los fiscalizadores, seleccionando siempre el fiscalizador más cercano.
El algoritmo automáticamente generará rutas de control, balanceando la carga de los fiscalizadores, y modificando la ruta de inspección de manera inteligente. El sistema de control sabrá en qué zona de parqueo está cada inspector, basado en la lectura GPS del dispositivo móvil que contendrá la aplicación de control.
Ver el Anexo #2 para una descripción detallada del algoritmo. El mismo será entregado con su código fuente a la EMOV y podrá ser sujeto a revisiones y modificaciones de ser necesario.

Como parte final, este módulo se retroalimentará de las infracciones asignadas a los usuarios, de ser el caso. Así, si un usuario comete una infracción, además de seguir todo el proceso administrativo de la entrega de la multa, inhabilitación del vehículo, etc., el fiscalizador deberá ingresar en su aplicativo la placa del vehículo, la zona de parqueo y la hora en la que fue multado, para llevar un registro completo de cada uso del servicio.

* Módulo de Reportes e Inteligencia de Negocios
El último módulo que integra la aplicación es el de Reportes y soporte a decisiones. Este módulo contendrá acceso a la información generada en la base de datos central para cada uno de los módulos anteriores.

Este módulo será accedido internamente, por usuarios previamente definidos y autorizados por la EMOV. Será un sistema web, accesible a través de cualquier navegador Internet. El usuario tendrá a su disposición un generador de reportes, donde a través de la selección y modificación de filtros, la información de la base de datos podrá ser consultada.

La información será presentada a través de tablas de datos y gráficos de líneas y barras. Se desplegarán también líneas de tiempo y gráficos de tendencia de ser el caso. Estos gráficos se definirán con el Cliente en la etapa de prototipo. Se prevé preliminarmente desarrollar los siguientes módulos de reportes Reporte | Descripción | Filtros Incluidos | Comentario | Ingresos | Permite revisar las compras y activaciones de tarjetas | Rango de fechas, zona de parqueo, días de semana | | Uso de Servicio | Revisión de estadísticas de parqueo | Rango de fechas, zona de parqueo | | Multas | Revisión de infracciones | Rango de fechas, zona de parqueo, días de semana | | Fiscalización | Revisión de actividad por fiscalizador | Rango de fechas, zona de parqueo, días de semana | | Dashboard | Indicadores principales:- Por usuario: Promedio de parqueos por mes- Por Zona: Rotación de parqueos- Por Día de Semana: Búsqueda de estacionalidad | De acuerdo al reporte, será la Zona de Parqueo, el Día de semana, etc. | Se establecerán estos indicadores con el Cliente antes de empezar este módulo | Reincidencia | Permitirá ver usuarios o zonas de parqueos donde existan más multas | Placa del vehículo, Rango de fechas, zona de parqueo, día de semana | | Constructor de Reportes | Se tendrán a disposición del usuario una serie de campos base, con un módulo de filtros dinámico | Los filtros serán dinámicos para el usuario e inicialmente serán: rangos de fecha, zona de parqueo, día de semana, placa, fiscalizador, etc. | |

* Todos los reportes serán incluidos en el prototipo.

Plataformas de Soporte
Como soporte de uso a estos módulos, y como una forma masiva de extender el proceso, PlexiFactory propone desarrollar dos plataformas móviles: * Plataforma Smartphone. Esta solución está basada en el uso de teléfonos inteligentes (smartphones), asumiendo que el usuario tiene a su alcance un servicio de Internet en el aparato telefónico móvil. Se estima que en el país existen 1.3millones de teléfonos inteligentes representantando el 17% de lus usuarios de telefonía celular en el páis. en el país.

La plataforma Smartphone estará provista por una aplicación atractiva visualmente y de muy fácil uso, que le permitirá al usuario tanto pagar, como registrar el uso del sistema. El aplicativo para Smartphone estará hecho en tecnología HTML5, independiente del sistema operativo, que permitirá publicarlo en las tiendas de aplicaciones con mayor rapidez. Se prevé incluir pruebas de la aplicación en plataformas iOS (Apple) y Android.

* Plataforma Telefonía Móvil. Esta solución estará basada en tecnología SMS y funcionará de manera similar a las plataformas de activación de servicios celulares que los proveedores de servicio han puesto a disposición de los usuarios. Se estima que un 86.4% de los hogares tiene acceso a estos dispositivos y el 76% de las personas comprendidas entre 25 y 44 años de edad cuenta con estos dispositivos, y si bien la plataforma no será tan atractiva visualmente, tanto la activación como el uso del servicio se podrían implementar de manera muy simple.

Este aplicativo estará hecho a base de menús de selección múltiple, como se utiliza actualmente en la activación de servicios SMS.

* Proceso Manual. Una última opción considerada es generar una variante mínima al proceso actual de compra de minutos de parqueo, donde el usuario se debe acercar todavía al local cercano a la zona de parqueo, pre-pagar por su servicio y dejar su comprobante en un lugar visible del vehículo. Con esta opción se incluyen a todos los usuarios que no posean un celular al momento de usar el servicio, extranjeros y demás personas que no conozcan de su uso.

Se presenta a continuación una tabla que resume las prestaciones de cada plataforma Servicio | Smartphone | Móvil SMS | Manual | Registro | | | | Registro de Usuario | X | Solamente # Móvil | | Pago | | | | Compra de Tarjetas por Internet | X | | | Compra de Tarjetas en Locales | X | X | Solamente para ese momento | Registro de Uso | | | | Registro en cualquier zona | X | X | Se especifica en el local de compra | Alerta 5/10 minutos antes de que el tiempo termine | X | | | Posibilidad de extensión vía teléfono | X | X | | Liberación de Parqueo | X – Minutos adicionales | X – Minutos adicionales | | Reportes | | | | Reporte de Tarjetas Activadas | X | X | | | | | |

Metodología de Proyecto * Para el planteamiento, diseño, construcción y puesta en marcha de la plataforma se generará un proyecto maestro, compuesto de algunos sub-proyectos, que llevarán al objetivo definitivo. Un diseño preliminar de este esquema se muestra a continuación: * Proyecto Maestro * Fase I – Prototipo

* Fase II – Desarrollo y automatización * Construcción del Componente Core de la plataforma * Módulo de Pago del Servicio * Aplicación Smartphone * Aplicación Teléfono Móvil * Pago Manual del Servicio * Módulo de Control de Uso del Servicio * Módulo de Reportes e Inteligencia de Negocios

* Fase III – Migración del Sistema

* El portafolio de proyectos mencionado será planteado de acuerdo a las normas del Project Management Institute (PMI) y su documentación y avance respetará esa norma. Se tendrá un repositorio compartido en la nube para estos efectos que estará vigente desde el inicio hasta la entrega del proyecto.

Recursos
PlexiFactory tiene entre sus filas a personal con amplia experiencia en el área de desarrollo. Al inicio del proyecto, se entregará el Curriculum Vitae de cada integrante del equipo, indicando los temas de mayor relevancia para el proyecto. PlexiFactory se encargará de asignar las tareas de acuerdo a su complejidad al personal adecuado.
PlexiFactory asignará un Director de Proyecto que será la contraparte con el Cliente. Este Director será el encargado de generar los informes, generar las agendas de las reuniones y en general escuchar y solucionar los requerimientos del Cliente. De acuerdo al grado de paralelismo requerido, se asignarán además Jefes de Equipo, que liderarán a los distintos equipos de desarrollo. El dimensionamiento de recursos se hará en forma coordinada con el Cliente.
PlexiFactory será la responsable del pago de Seguridad Social y demás beneficios de ley a sus desarrolladores, quienes ocasionalmente podrían requerir trabajar desde las instalaciones del cliente.
Seguridad de Información
PlexiFactory resguardará la información del cliente como suya propia y la eliminará de sus servidores de correo y de archivos una vez que se termine cada Orden de Trabajo, a menos que sea formalmente requerido su almacenamiento por el Cliente. Los representantes de PlexiFactory firmarán Acuerdos de Confidencialidad con el Cliente de considerarse necesario.
Entregables
Se detalla a continuación un listado de entregables del servicio Tipo Entregable | Entregable | Descripción | Documento Parcial | Informe Semanal de Avance | Entregado cada Viernes por la tarde, contiene los avances semanales | Documento Parcial | Minuta de Reunión Bi-Semanal | Entregada después de cada reunión bi-semanal, contiene los casos de uso a ser probados y las plataformas. Es la base de la ejecución semanal de testing. | Documento Total | Informe Final | Una vez terminado el contrato, se generará un informe final con el formato requerido por el Cliente | Aplicativo | Aplicativo Smartphone | Es el aplicativo que los usuarios podrán bajarse desde los App Store de iOS o Android. | Aplicativo | Aplicativo SMS | Aplicativo que va a estar hospedado en un servicio SMS | | | |

Condiciones Comerciales * Cada orden de trabajo tendrá un mínimo de 100 horas. * El pago de cada Orden de Trabajo se hará de la siguiente manera * 25% de anticipo al día de la firma del Contrato * 50% prorrateado entre el número de fases definidas en partes iguales * 25% a la entrega final del proyecto * Los pagos se harán en Pesos Chilenos, considerando la UF del día para su conversión * Esta propuesta tiene una validez de 60 días

-------------------------------------------------

Contacto: Gustavo Vinueza C. – Director de Tecnología
Teléfono: +5939 82808750 guz@plexifactory.biz Rafael Salas y Joaquín Pinto, CP 010105
Cuenca, Ecuador

Anexo #1: Etiquetado de Zonas de Parqueo
La propuesta de etiquetado de las Zonas de Parqueo busca facilitar la localización tanto de los fiscalizadores como de los vehículos de los usuarios. Si bien se podría referenciar cada localización con los nombres de calles y numeración actual, para un sistema de fácil acceso se propone que cada cuadra tenga una numeración de zona de Parqueo distinta. Se detallan a continuación dos propuestas, que pueden ser refinadas con el Cliente, hasta llegar a una final: 1. Propuesta Ordinal
Cada zona de parqueo tendrá 4 números: * El último será el número de cuadra, empezando en sentido de las manecillas del reloj, con la cuadra apuntando hacia el norte como #1 * Los tres primeros serán el número de manzana, definidos en un mapa

Así, por ejemplo el código 0022 será la segunda cuadra de la manzana 002. A este código se le podría añadir el número de parroquia de ser necesario. 2. Propuesta de Código
En esta propuesta se generará un código compuesto de letras y números, que servirá para identificar la zona de parqueo.

Anexo #2: Descripción del Algoritmo de Control de Fiscalización. * Cada fiscalizador recibe su ruta tipo por la mañana * El algoritmo de control empieza a funcionar 15 minutos después del inicio de la hora de operación mínima * En la base de datos se tiene para cada cuadra la siguiente información: * Hora Inicio y Fin * Zona de Parqueo (cuadra) * Número de vehículos que pueden estacionar * Promedio de vehículos estacionados a esa hora
Así, p.ej. para la zona 0011, que tiene 10 parqueos disponibles, se tiene que de 13h00 a 14h00 el promedio de vehículos estacionados es de 8.5, eso quiere decir que es una hora muy alta en términos de ocupación. Podría ser que para la misma zona de 10h00 a 11h00 se tengan nada más 4 vehículos como promedio. * Así, el algoritmo buscará en la base de datos los vehículos que están como activos en esa zona de parqueo y podría arrojar los siguientes resultados, asumiendo que la hora de ejecución del algoritmo son las 12:30:
Zona 0011, 12h00 a 13h00, promedio 8.5 vehículos, capacidad 10 vehículos ID | Placa | Hora Inicio | Hora Fin | Estado | | | 1 | ABC-123 | 12:15 | 13:30 | OK | | | 2 | ACD-345 | 11:00 | 12:00 | Abierto | | | 3 | BGF-123 | 12:15 | 12:45 | OK | | | 4 | FGB -789 | 12:00 | 13:00 | OK | | | 5 | AFF-540 | 11:00 | 13:00 | OK | | | 6 | AZZ-190 | 12:15 | 14:00 | OK | | | 7 | AFD-289 | 11:00 | 11:30 | Abierto | | | 8 | ADD-789 | 11:00 | 11:30 | Abierto | | | 9 | KLI-090 | 12:00 | 13:00 | Ok | | | 10 | UIO-281 | 10:00 | 11:00 | Abierto | | | 11 | AFJ-001 | 10:30 | 11:45 | Abierto | | |

* El Estado se asignará como Abierto cuando la hora fin sea menor a la hora actual y el usuario no haya liberado el puesto.

* Se generarán alarmas cuando: * Existan vehículos tanto en estado OK como Abiertos que sumen más que la capacidad actual de la zona de parqueo. En el ejemplo se tienen 11 vehículos asignados a una zona de 10. * Cuando un registro de uso permanezca en Abierto más de 15 minutos de su hora actual

* Con esta alarma, se modificará la ruta del fiscalizador más cercano, obligándolo a que vaya a validar que los vehículos que estén estacionados sean los asignados como OK y ningún otro. La ruta original del Fiscalizador seleccionado se modifica, alertando al Fiscalizador que en la Zona 0011 existe una alarma y que debe revisarlo.

* Por ejemplo se asigna al Fiscalizador 5, quien estaba a 200 metros, que vaya a revisar lo ocurrido. En su aplicación, el Fiscalizador verá lo siguiente:

Revisión de Zona 0011, Alarma de Capacidad y Sobretiempo * * Los siguientes vehículos deberían estar estacionados en la zona: * ABC-123 [ ], BGF-123 [ ], FGB-789 [ ], AFF-540 [ ], AZZ-190 [ ], KLI-090 [ ] * Se desconoce el estado de los siguientes vehículos * ACD-345 [ ], AFD-289 [ ], ADD-789 [ ], UIO-281 [ ], AFJ-001 [ ] * Existen otros vehículos sin registro? * Placa 1 * Placa 2 |
El fiscalizador debe validar qué vehículos están en la cuadra, cuáles de los en estado abierto no aparecen y si existe algún otro vehículo infractor que está estacionado pero que no ha registrado su uso.
Una vez que el fiscalizador revisa la Zona de Parqueo la deja como OK, y esto deja a todos los vehículos como OK, modificando los Abiertos.

* Si es que no hay alarmas, es decir, que no existen registros de vehículos Abiertos más de 15 minutos ni una supuesta sobrecapacidad, el fiscalizador simplemente debe seguir la ruta definida por el sistema desde la mañana y revisar sus zonas de optoi