Software de Reconocimiento de Patrones Vehiculares
Item type info:eu-repo/semantics/bachelorThesis
Authors Martínez Butrón, Miguel Ángel; Villar Da Silva, EdsonJair
Publisher Universidad Peruana de Ciencias Aplicadas (UPC)
Rights info:eu-repo/semantics/openAccess
Downloaded 11-Apr-2018 08:12:06
Item License http://creativecommons.org/licenses/by-nc-nd/4.0/
Link to item http://hdl.handle.net/10757/273588
FACULTAD DE INGENIERÍA
CARRERA DE INGENIERÍA DE SOFTWARE
Software de Reconocimiento de Patrones Vehiculares
TESIS
Para optar el título profesional de:
INGENIERO DE SOFTWARE
AUTORES:
MIGUEL ÁNGEL MARTÍNEZ BUTRÓN
EDSON JAIR VILLAR DA SILVA
ASESOR DE TESIS:
DAVID MAURICIO SÁNCHEZ
Lima, Perú
2009
ii
iii
Este documento se lo dedicamos a nuestros
padres, profesores y amigos que brindaron su
apoyo incondicional para el desarrollo de este
trabajo.
iv
v
RESUMEN
La ciudad de Lima, en los últimos años, ha venido registrando un alarmante crecimiento en
lo que respecta a los índices de crímenes y secuestros, siendo éstos más pronunciados en
ciertos distritos de la capital. Ante esta situación, la Policía Nacional del Perú (PNP) y el
Serenazgo han debido redoblar esfuerzos para enfrentar este problema.
Paralelamente, hemos sido testigos de cómo las aplicaciones y dispositivos de seguridad han
evolucionado y hoy, ofrecen al público una amplia gama de servicios tecnológicos. Es así
que las municipalidades de algunos distritos limeños han implementando el uso de estas
herramientas (cámaras de seguridad en las calles, equipos que registran el exceso de
velocidad en las pistas, entre otros) y, a través de ellos, buscan reforzar la labor que cumplen
las fuerzas del orden.
Frente al contexto expuesto líneas arriba, se elaboró un profundo análisis de la coyuntura
para determinar cuál sería la mejor solución. Como resultado, en este presente trabajo se
detalla la iniciativa propuesta: la concepción y el desarrollo de una herramienta de apoyo
para la Policía Nacional del Perú y el Serenazgo, que complemente su labor de mantener la
seguridad ciudadana, reduciendo los peligros en las calles. Y, a través del proyecto llamado
Software de Reconocimiento de Patrones Vehiculares, se propone cumplir con este objetivo.
Basándose en un análisis de los patrones de comportamiento de los vehículos a lo largo y
ancho de una región geográfica, éstos se comparan con una serie de datos provistos por
sistemas de información externos, relacionados con los datos de los vehículos, de los
propietarios de los vehículos, de los antecedentes policiales de los propietarios, de vehículos
con orden de captura y de ubicaciones de lugares en donde se cometen delitos. Entre estas
fuentes de información se encuentran las de instituciones del Estado tales como el Registro
Nacional de Identificación y Estado Civil (RENIEC), la Superintendencia Nacional de los
Registros Públicos (SUNARP) y la Policía Nacional del Perú (PNP).
En las páginas siguientes, se encuentra la explicación detallada de cada aspecto relacionado
con este proyecto.
vi
vii
ÍNDICE
INTRODUCCIÓN .......................................................................................................................... 1
CAPÍTULO 1. PLANTEAMIENTO Y ANÁLISIS DEL PROBLEMA ................................... 3
1.1 Análisis de la realidad .............................................................................................................. 3
1.2 Oportunidad de negocio .......................................................................................................... 5
CAPÍTULO 2. FUNDAMENTO TEÓRICO ............................................................................... 7
2.1 Arquitectura de Software ......................................................................................................... 7
2.2 Arquitectura Orientada a Servicios (SOA) ............................................................................. 8
2.3 Sistemas Expertos .................................................................................................................... 9
2.4 Sistema de codificación de las placas vehiculares ...............................................................12
CAPÍTULO 3. SOFTWARE DE RECONOCIMIENTO DE PATRONES VEHICULARES15
3.1 Propuesta ................................................................................................................................15
3.2 Objetivo General del Proyecto ..............................................................................................17
3.3 Objetivos Específicos ............................................................................................................17
3.4 Alcance ...................................................................................................................................18
3.5 Requerimientos del Software ................................................................................................20
3.6 Interacción con otros sistemas ...............................................................................................35
3.7 Fuentes de información de ejemplo ......................................................................................37
CAPÍTULO 4. GESTIÓN DEL PROYECTO ...........................................................................41
4.1 Estimación ..............................................................................................................................41
4.2 Hitos ........................................................................................................................................43
4.2.1. Fase de Concepción .........................................................................................................43
4.2.2. Fase de Elaboración .........................................................................................................44
4.2.3. Fase de Construcción ......................................................................................................45
4.2.4. Fase de Transición ...........................................................................................................45
4.3 Riesgos ...................................................................................................................................45
4.3.1. Consideraciones ...............................................................................................................45
4.3.2. Cuadro Resumen .............................................................................................................46
CAPÍTULO 5. DISEÑO DE LA SOLUCIÓN ...........................................................................51
5.1 Arquitectura de la solución ....................................................................................................51
5.2 Módulo Servidor ....................................................................................................................53
viii
5.3 Módulo de Reconocimiento de Patrones ..............................................................................55
5.4 Módulo Implementador .........................................................................................................55
5.5 Módulo de Monitoreo ............................................................................................................58
5.6 Módulo de Mantenimiento ....................................................................................................61
CAPÍTULO 6. CONSTRUCCIÓN DEL PRODUCTO ............................................................65
6.1 Herramientas de desarrollo ....................................................................................................65
6.1.1. Entonos de desarrollo ......................................................................................................65
6.1.2. Herramientas CASE ........................................................................................................66
6.1.3. Herramientas de gestión ..................................................................................................66
6.1.4. Herramientas de SQA y Gestión del Cambio ................................................................66
6.2 Estándares y patrones de diseño ............................................................................................66
6.2.1. Adapter .............................................................................................................................66
6.2.2. Bridge ...............................................................................................................................67
6.3 Proyectos creados en el desarrollo del software ...................................................................67
6.3.1. Módulo Monitoreo ..........................................................................................................67
6.3.2. Módulo Mantenimiento ..................................................................................................69
6.3.3. Módulo Servidor ..............................................................................................................70
6.3.4. Módulo de Reconocimiento de Patrones........................................................................72
6.3.5. Módulo Implementador ..................................................................................................73
CAPÍTULO 7. ASEGURAMIENTO DE LA CALIDAD DEL SOFTWARE........................77
7.1 Fábricas de Software UPC ....................................................................................................77
7.2 Pruebas Funcionales ..............................................................................................................78
7.3 Resultados de las pruebas ......................................................................................................79
7.3.1. NET Factory ....................................................................................................................79
7.3.2. V&V .................................................................................................................................81
CAPÍTULO 8. EMPAQUETADO Y PUESTA EN MARCHA DEL SISTEMA...................83
8.1 Instaladores del sistema .........................................................................................................83
8.2 Despliegue del sistema en un entorno real ............................................................................84
8.3 Despliegue del sistema en las instalaciones de la universidad.............................................86
CONCLUSIONES ........................................................................................................................... i
RECOMENDACIONES .............................................................................................................. iii
GLOSARIO DE TÉRMINOS ....................................................................................................... v
BIBLIOGRAFÍA ......................................................................................................................... vii
ADJUNTOS ................................................................................................................................. xii
ix
ÍNDICE DE FIGURAS
Figura 1.1 – Unidad ViaPK ......................................................................................................... 6
Figura 2.1 – Proceso de desarrollo de un sistema experto ....................................................... 10
Figura 2.2 – Red Neuronal Artificial ........................................................................................ 11
Figura 2.3 – Ejemplo de Red Neuronal Artificial .................................................................... 11
Figura 3.1 – Software de Reconocimiento de Patrones Vehiculares ....................................... 16
Figura 3.2 – Interfaz de los Reportes Predefinidos................................................................... 22
Figura 3.3 – Interfaz del Reporte de Autos con Orden de Captura Detectados por el Sistema
..................................................................................................................................................... 22
Figura 3.4 – Interfaz del Reporte de Autos Sospechosos Detectados por el Sistema ............. 22
Figura 3.5 – Interfaz del Reporte de Alertas Lanzadas por el Sistema.................................... 23
Figura 3.6 – Prototipo para lanzar las alertas ............................................................................ 24
Figura 3.7 – Interfaz de centros de seguridad correspondientes a un determinado punto
geográfico ................................................................................................................................... 25
Figura 3.8 – Interfaz del mantenimiento de Centro de Seguridad ........................................... 25
Figura 3.9 – Interfaz de asociación de Centros de Seguridad con Zonas ................................ 26
Figura 3.10 – Interfaz del Mantenimiento de Instituciones ..................................................... 27
Figura 3.11 – Interfaz del Mantenimiento de Marcas .............................................................. 27
Figura 3.12 – Interfaz del Mantenimiento de Modelos ............................................................ 28
Figura 3.13 – Interfaz del Mantenimiento de la entidad Propietario ....................................... 29
Figura 3.14 – Interfaz del Mantenimiento de la entidad Tipo de Zona ................................... 29
Figura 3.15 – Interfaz del Mantenimiento de la entidad Vehículo .......................................... 30
Figura 3.16 – Interfaz de asociación de Vehículos con Zonas ................................................ 30
Figura 3.17 – Interfaz del mantenimiento de Zonas ................................................................. 31
Figura 3.18 – Interfaz de Rastreo de Vehículos ....................................................................... 33
Figura 3.19 – Interfaz principal del Módulo de Monitoreo con el detalle de una alerta ........ 34
Figura 3.20 – Interfaz del Historial de Alertas.......................................................................... 34
Figura 3.21 – Interfaz del Log del Sistema ............................................................................... 35
Figura 3.22 – Sistema Dummy .................................................................................................. 38
Figura 3.23 – SRPV con el sistema Dummy ............................................................................ 39
Figura 3.24 – Servicios proveedores de información ............................................................... 40
x
Figura 5.1 – Componentes del Módulo Proveedor .................................................................. 52
Figura 5.2 – Componentes del Módulo Implementador .......................................................... 53
Figura 5.3 – Componentes del Módulo Servidor ..................................................................... 53
Figura 5.4 – Componentes del Módulo de Reconocimiento de Patrones ............................... 55
Figura 5.5 – Componentes del Módulo Implementador .......................................................... 56
Figura 5.6 – Componentes del Módulo de Monitoreo ............................................................. 58
Figura 5.7 – Interfaz de seguimiento y rastreo de vehículos .................................................... 59
Figura 5.8 – Interfaz principal del módulo de Monitoreo ........................................................ 60
Figura 5.9 – Interfaz de historial de alertas ............................................................................... 60
Figura 5.10 – Componentes del Módulo de Mantenimiento ................................................... 61
Figura 5.11 – Interfaz de selección de Zonas ........................................................................... 62
Figura 5.12 – Interfaz del Log del Sistema ............................................................................... 63
Figura 5.13 – Interfaz de asociación de Vehículos con Zonas ................................................ 63
Figura 5.14 – Interfaz del mantenimiento de Zonas ................................................................. 64
Figura 6.1 – Proyecto UPC.SRPV.Monitoreo.GUI en Visual Studio ..................................... 68
Figura 6.2 – Proyecto UPC.SRPV.Monitoreo.BLL en Visual Studio .................................... 68
Figura 6.3 – Proyecto UPC.SRPV.Monitoreo.Consumidor.Interfaces en Visual Studio ...... 68
Figura 6.4 – Proyecto UPC.SRPV.Monitoreo.Consumidor en Visual Studio ........................ 69
Figura 6.5 – Proyecto UPC.SRPV.Mantenimiento.GUI en Visual Studio ............................. 69
Figura 6.6 – Proyecto UPC.SRPV.Mantenimiento.BLL en Visual Studio ............................ 69
Figura 6.7 – Proyecto UPC.SRPV.Mantenimiento.Consumidor.Interfaces en Visual Studio
..................................................................................................................................................... 70
Figura 6.8 – Proyecto UPC.SRPV.Mantenimiento.Consumidor en Visual Studio ................ 70
Figura 6.9 – Proyecto UPC.SRPV.Servidor.Proveedor en Visual Studio .............................. 70
Figura 6.10 – Proyecto UPC.SRPV.Servidor.Proveedor.Interfaces en Visual Studio ........... 71
Figura 6.11 – Proyecto UPC.SRPV.DAL.Interfaces en Visual Studio ................................... 71
Figura 6.12 – Proyecto UPC.SRPV.DAL en Visual Studio .................................................... 72
Figura 6.13 – Proyecto UPC.SRPV.Servicios.ReconocimientoDePatrones en Visual Studio
..................................................................................................................................................... 73
Figura 6.14 – Proyecto UPC.SRPV.Servicio.Implementador en Visual Studio .................... 73
Figura 6.15 – Proyecto UPC.SRPV.Servicios.Eventos.Interfaces en Visual Studio .............. 73
Figura 6.16 – Proyecto UPC.SRPV.Servicios.Eventos en Visual Studio ............................... 74
Figura 6.17 – Proyecto UPC.SRPV.Servicios.Propietario.Interfaces en Visual Studio ......... 74
Figura 6.18 – Proyecto UPC.SRPV.Servicios.Propietario en Visual Studio .......................... 74
xi
Figura 6.19 – Proyecto UPC.SRPV.Servicios.Vehiculo.Interfaces en Visual Studio ............ 74
Figura 6.20 – Proyecto UPC.SRPV.Servicios.Vehiculo en Visual Studio ............................. 75
Figura 6.21 – Proyecto UPC.SRPV.Servicios.RegistrosCriminales.Interfaces en Visual
Studio .......................................................................................................................................... 75
Figura 6.22 – Proyecto UPC.SRPV.Servicios.RegistrosCriminales en Visual Studio .......... 75
Figura 8.1 – Diagrama de despliegue en un entorno real ......................................................... 85
Figura 8.2 – Diagrama de despliegue en la universidad .......................................................... 86
xii
xiii
ÍNDICE DE TABLAS
Tabla 1.1 – Índices de robos en vivienda .................................................................................... 4
Tabla 1.2 – Índices de secuestros ................................................................................................ 4
Tabla 4.1 – Estimación del esfuerzo por caso de uso ............................................................... 42
Tabla 4.2 – Estimación del esfuerzo del proyecto .................................................................... 42
Tabla 4.3 – Distribución del esfuerzo y el tiempo según RUP ................................................ 42
Tabla 4.4 – Distribución del esfuerzo y el tiempo del proyecto .............................................. 42
Tabla 4.5 – Hitos de la fase de Concepción .............................................................................. 43
Tabla 4.6 – Hitos de la fase de Elaboración .............................................................................. 44
Tabla 4.7 – Hitos de la fase de Construcción............................................................................ 45
Tabla 4.8 – Hitos de la fase de Transición ................................................................................ 45
Tabla 7.1 – Reporte inicial de NET Factory ............................................................................. 80
Tabla 7.2 – Reporte final de NET Factory ................................................................................ 80
Tabla 7.3 – Porcentaje de solución de errores .......................................................................... 81
xiv
SOFTWARE DE RECONOCIMIENTO DE PATRONES VEHICULARES
1
INTRODUCCIÓN
A medida que el parque automotriz de la ciudad de Lima va creciendo, se va
incrementando la cantidad de actos delictivos producidos con el uso de vehículos. Esta
es una de las principales razones por las que se ha detectado que los organismos de
seguridad necesitan de una herramienta de apoyo para combatir acciones criminales que
implican el uso de vehículos.
Normalmente, el trabajo de las fuerzas del orden se da en dos momentos: antes o
después de ocurrido el incidente. Por lo general, los organismos de este tipo se centran
en el segundo caso, con investigaciones sobre lo ocurrido, para luego capturar a los
criminales directamente o predecir los próximos movimientos para atraparlos in
fraganti, que es algo similar al primer caso. Lamentablemente, por limitaciones de
tiempo y de personal, las fuerzas del orden no cuentan con los recursos suficientes para
rastrear a todos los criminales que son denunciados o a todos los sospechosos.
Las fuerzas del orden han realizado este trabajo durante muchos años de una manera
artesanal, por lo que este proyecto busca proveer una herramienta sofisticada de apoyo a
las autoridades, para automatizar el seguimiento del comportamiento de los vehículos
utilizados en acciones criminales o incluso predecir posibles actos delictivos, a través
INTRODUCCIÓN
2
del uso de técnicas de inteligencia artificial para reconocer ciertos patrones de
comportamiento definidos en la aplicación.
En el presente documento se analiza la realidad de la seguridad ciudadana, así como los
sistemas que se usan actualmente para el apoyo en el trabajo de las fuerzas del orden. A
partir de este análisis, se identifica la problemática existente, las características
requeridas para una solución de software para esta situación, y las metodologías y
técnicas que la soportan. Posteriormente, se presenta el Software de Reconocimiento de
Patrones Vehiculares como una propuesta de solución que tiene como objetivo apoyar a
la Policía y a Serenazgo en la identificación de vehículos que han actuado o que pueden
actuar en actos delictivos. A continuación, se detallan los requerimientos funcionales y
no funcionales que el producto software debe cubrir, la gestión del proyecto, el diseño
de la solución y el detalle de las pruebas realizadas sobre el mismo. En la gestión del
proyecto, se ahonda en la estimación realizada para cada uno de los casos de uso, las
fases definidas y los riesgos considerados. Por otro lado, dentro del diseño de la
aplicación, se muestra la arquitectura definida para cada uno de los módulos y la
descripción de los componentes que estos contienen. Por último, se describe el
despliegue del sistema, seguido por las conclusiones y recomendaciones para el mismo.
SOFTWARE DE RECONOCIMIENTO DE PATRONES VEHICULARES
3
CAPÍTULO 1. PLANTEAMIENTO Y ANÁLISIS DEL PROBLEMA
En el Perú, la seguridad ciudadana es una preocupación constante para las fuerzas del
orden público. El problema es tan fuerte que ha llevado a que los municipios distritales
de la ciudad de Lima inviertan fuertes sumas de dinero en la constitución de organismos
paralelos a la policía, lo que se conoce como Serenazgo. En este capítulo se hace
estudio de la realidad para enfocar el problema y dar una propuesta de solución.
1.1 Análisis de la realidad Como es de conocimiento popular, Lima es un foco latente de problemas de seguridad.
Según una encuesta desarrollada por el Instituto de Defensa Legal (IDL)1, los
principales problemas son los robos en la calle, pandillaje, consumo y comercialización
de drogas, robos en viviendas, secuestros, entre otros. En las tablas 1.1 y 1.2 se pueden
apreciar datos capturados por el Instituto de Defensa Legal para el caso del robo en
viviendas y los secuestros, con una muestra de 514 personas de diferentes estratos
socioeconómicos. En respuesta a estos problemas, algunos municipios han optado por la
adquisición de sistemas de vigilancia basados en cámaras de video y estrategias de
1 Cfr. Instituto de Defensa Legal 2007
CAPÍTULO 1. PLANTEAMIENTO Y ANÁLISIS DEL PROBLEMA
4
trabajo conjunto entre instituciones como la Policía Nacional del Perú y Serenazgo.
Aunque, como se puede ver en las cifras, son problemas aún latentes en la sociedad, y
se necesita un mayor esfuerzo y sistemas más eficaces para controlarlos.
CUADRO Nº 10-C
¿En los últimos seis meses usted o alguien de su familia ha sido
víctima de un robo o intento de robo en su vivienda?
AGO.
2004
ABR.
2005
NOV.
2005
FEB.
2007
Sí 25.0 18.9 14.8 16.5
No 75.0 80.9 85.2 83.5
No responde - 0.2 - -
1Tabla 1.1 – Índices de robos en vivienda Fuente: IDL 2007
CUADRO Nº 27-C
¿En los últimos seis meses usted o alguien de su familia ha sido
víctima de un secuestro o intento de secuestro al paso?
AGO.
2004
ABR.
2005
NOV.
2005
FEB.
2007
Sí 3.9 2.6 1.0 2.9
No 94.1 96.1 97.3 97.1
No responde - 1.4 1.8 -
2Tabla 1.2 – Índices de secuestros Fuente: IDL 2007
La Policía Nacional del Perú tiene algunas estrategias para cumplir con el objetivo de la
seguridad ciudadana. Dentro de esta organización hay una división llamada Radio
Patrulla, que es la encargada de intervenir en caso de asaltos a entidades bancarias y/o
comerciales, secuestros, prevención de robo de vehículos, entre otras acciones
delictivas2. Según lo indagado con el Crnl. PNP Oswaldo Alfaro, Jefe de la División de
Emergencias de Radio Patrulla, este departamento presenta 3 modos de trabajo: Puestos
de Aproximación Ciudadana, Puestos Fijos y Puestos de Apoyo. Los Puestos de
Aproximación Ciudadana son puntos clave en los que siempre están ubicados los
vehículos de la policía, de tal manera que puedan empezar una persecución
rápidamente, en caso de necesitarse. Los Puestos Fijos, como su nombre lo indica, son
2 Ministerio del Interior 2009
SOFTWARE DE RECONOCIMIENTO DE PATRONES VEHICULARES
5
puntos en los que los vehículos deben permanecer permanentemente para el resguardo
de alguna entidad cercana asignada, como es el caso de las embajadas. Por último, los
Puestos de Apoyo son aquellos en los que las unidades brindan apoyo a algunas
comisarías para mejorar la seguridad ciudadana de los alrededores.
A pesar de las estrategias tan bien definidas con las que cuenta Radio Patrulla, el modo
de intervención a un vehículo sospechoso es bastante rudimentario. Por lo general, el
operativo comienza con la llamada de un informante, alguien al que le parece
sospechoso un cierto vehículo. La central atiende la queja e inmediatamente después se
comunica con los patrulleros para que el más cercano verifique la existencia del
vehículo y corrobore la información. En caso de que el vehículo cuente con alguna
característica que lo haga parecer extraño, el policía del patrullero solicita verificar si el
auto tiene orden de captura (requisitoria), en caso de que no tenga, se solicita los datos
del conductor y de los tripulantes. Si alguno tiene requisitoria, el policía tomará las
acciones respectivas. El problema en este escenario es que no siempre hay un
informante y es ahí donde es necesario un refuerzo en la seguridad.
1.2 Oportunidad de negocio
El ámbito de la seguridad ciudadana es un territorio prácticamente desolado cuando se
respecta a la tecnología, excepto por algunos países. Poco esfuerzo de desarrollo de
software es dedicado a este nicho de negocio y mucho menos en el Perú. Inglaterra es
un gran referente en cuanto al uso de tecnologías orientadas a la vigilancia se refiere. La
aplicación de ciencia y tecnología en sus labores como herramientas para mejorar el
desempeño de su trabajo ha permitido que se desarrollen múltiples aplicaciones de
software, por ejemplo: sistemas de reconocimiento facial, sistemas de reconocimiento
de audio y video, sistemas de reconocimiento de placas, entre otras.3
Recientemente, en el Perú, se ha lanzado una unidad móvil de monitoreo, denominada
ViaPK. Esta unidad adquirida a inicios del 2008 por la Municipalidad del Callao, cuenta
con un equipo capaz de capturar la imagen de un automóvil, reconocer la placa y
confrontar la placa con la base de datos de la Policía Nacional del Perú para verificar si
3 Cfr. Home Office 2004
CAPÍTULO 1. PLANTEAMIENTO Y ANÁLISIS DEL PROBLEMA
6
el vehículo presenta alguna irregularidad. Además puede detectar el exceso de velocidad
para tomar las acciones correspondientes. 4
1Figura 1.1 – Unidad ViaPK
Fuente: Municipalidad Provincial del Callao 2008
Actualmente, la Policía Nacional del Perú cuenta con una serie de cámaras distribuidas
en algunos puntos estratégicos de la ciudad; sin embargo, se puede anticipar un
incremento en el número de estos equipos debido a su gran utilidad en labores de
seguridad y la reducción continua de su precio. Un sistema capaz de orquestar la
información capturada por estas cámaras, además de algunos datos clave para la
identificación de vehículos sospechosos, puede llegar a ser una valiosa herramienta de
apoyo a las fuerzas del orden.
4 Cfr. Municipalidad del Callao 2008
SOFTWARE DE RECONOCIMIENTO DE PATRONES VEHICULARES
7
CAPÍTULO 2. FUNDAMENTO TEÓRICO
Una serie de conceptos respaldan el desarrollo de un proyecto de esta naturaleza. En
este capítulo se hace una breve descripción de los términos más importantes que
ayudarán a tener un mejor entendimiento de este documento y del proyecto en general.
2.1 Arquitectura de Software
La arquitectura es la base fundamental de cualquier estructura. Gracias al desarrollo de
esta disciplina, el mundo ha visto majestuosas construcciones que el hombre cada día
desea superar, desde las Pirámides de Egipto hasta las Torres Petronas en Kuala
Lumpur. Asimismo, su contraparte en el mundo del desarrollo de software es la
Arquitectura de Software, disciplina que también busca desarrollar soluciones robustas
y flexibles a la vez, de acuerdo al entorno de un determinado problema y los
requerimientos del negocio.
CAPÍTULO 2. FUNDAMENTO TEÓRICO
8
Tan importante es el desarrollo de una buena arquitectura de software que la
Organización Internacional para la Estandarización (ISO) ha definido una serie de
atributos de calidad que guían el desarrollo del software5, entre los que se encuentran
los siguientes:
Portabilidad: Es el atributo que está enlazado a la adaptabilidad del software
a diferentes ambientes, facilidad de instalación y reemplazo.
Usabilidad: Es el atributo que le da la característica de ser fácil de usar y de
entender.
Funcionalidad: Es el atributo que asegura que el software cumple con el
propósito para el cual fue definido.
Confiabilidad: Es el atributo que asegura la madurez del software y su
tolerancia a fallas.
Mantenibilidad: Es el atributo que afirma que el software es fácil de analizar,
de modificar y de probar.
Eficiencia: Es el atributo que se encarga de calificar el manejo de los
recursos usados por el sistema.
2.2 Arquitectura Orientada a Servicios (SOA)
SOA es una propuesta para el desarrollo de una arquitectura de software en la que se
contempla la necesidad de unir las fuentes de información de la organización para
brindar un servicio más simple, flexible e integrado.6
Uno de los más grandes méritos de la Arquitectura Orientada a Servicios, es que
permite relacionar necesidades con capacidades. Para lograr este objetivo, SOA tiene
tres conceptos que lo describen en su totalidad. En primer lugar, la visibilidad, que se
refiere a que los que ofrecen sus capacidades y los que tienen necesidades se puedan ver
entre sí para que sepan entre quiénes pueden colaborar. En segundo lugar, la
interacción, que representa la comunicación que se establece entre ambas partes, los que
tienen las capacidades y los que tienen necesidades. Esta comunicación, tal como ocurre
en el mundo real, representa el intercambio de información entre los mencionados y
tiene como fin un efecto palpable, que es el tercer concepto clave de SOA. El efecto
5 Cfr. ISO 2007
6 Cfr. Microsoft 2008
SOFTWARE DE RECONOCIMIENTO DE PATRONES VEHICULARES
9
causado por la interacción de ambas entidades, suele tener como resultado la entrega de
la información solicitada o un cambio en el estado de las entidades que están
relacionadas en la interacción anteriormente establecida.7
Por otro lado, por servicio, se entiende el hecho de realizar un trabajo por otra persona o
entidad, justamente lo que se busca con SOA. SOA propone organizar las piezas de
software de tal manera que se distribuyan en proveedores de servicios y consumidores
que tengan la necesidad de utilizar dichos servicios.
La principal ventaja de la Arquitectura Orientada a Servicios, es que provee un
paradigma para organizar redes de aplicaciones a través del consumo y ofrecimiento de
servicios entre ellas. Además, por su propuesta de interacción entre consumidores y
proveedores de servicios, permite un crecimiento totalmente controlado de los sistemas
empresariales, puesto que se reduce el esfuerzo de desarrollo al promover la
cooperación entre aplicaciones.
Gracias a SOA, se puede centralizar el acceso a los recursos de información y evitar
problemas como la duplicación de código para el acceso a las fuentes de información.
Una propuesta realmente adecuada para este proyecto.
2.3 Sistemas Expertos
Son sistemas basados en conocimiento. Se plasma la experiencia de un experto humano
en forma de reglas que serán almacenadas en una base de conocimientos, para que se
puedan obtener conclusiones a partir de algunos hechos que serán los inputs de un
motor de inferencia. El motor de inferencia es la parte del sistema experto que se
encarga de procesar la información (base de hechos) en base a las reglas especificadas y
la experiencia (base de conocimiento). El objetivo primordial de estas aplicaciones es
simular el análisis y conclusiones que tendría un ser humano ducho en un área
específica del saber ante una consulta.8
Además, los sistemas expertos cuentan con algunas características muy especiales.
Entre los muchos beneficios que brindan dichos sistemas está la capacidad de poder
7 Cfr. Oasis 2006
8 Cfr. Giarratano y Riley 1998: 1-4
CAPÍTULO 2. FUNDAMENTO TEÓRICO
10
brindar resultados aproximados que solo serán aceptados si cumplen con un nivel de
confianza definido. Como no siempre se pueden obtener resultados 100% certeros,
gracias al nivel de confianza especificado, se le puede dar un rango de error al programa
para considerar acertadas o no sus conclusiones. Otra característica con la que puede
contar un sistema experto, es la capacidad de explicar su conclusión, para tener una idea
más clara que siguió para obtener sus resultados.9
Estos sistemas, de gran utilidad, principalmente son utilizados como tutores inteligentes
en el aprendizaje y como ayuda en la toma de decisiones.10
2Figura 2.1 – Proceso de desarrollo de un sistema experto
Fuente: Knowledge Systems Institute
La base de conocimientos está representada por las reglas que serán tomadas como
ejemplo para la detección de los vehículos. En cuanto al motor de inferencia, en este
caso está representado por una red neuronal, la cual es capaz de aprender y sacar
conclusiones acerca de un conjunto de datos de entrada, en contraste con los ejemplos
en los que se ha basado para aprender. La librería usada para la red neuronal del sistema
se llama Neuro.Net, desarrollada por la empresa XP Idea (http://xpidea.com) y basada
en la metodología de aprendizaje llamada Back Propagation.
9 Cfr. Giarratano y Riley 1998: 165-223
10 Cfr. Giarratano y Riley 1998: 15-20
SOFTWARE DE RECONOCIMIENTO DE PATRONES VEHICULARES
11
3Figura 2.2 – Red Neuronal Artificial
Fuente: LIN 2004
Una red neuronal está compuesta por una serie inputs que se relacionan con los outputs
a través de conexiones. Cada una de estas conexiones tiene un determinado peso. Los
outputs tienen un valor llamado umbral y es el valor mínimo que se debe obtener de la
suma de las multiplicaciones de los valores de entrada por los pesos de cada una de las
conexiones que los relacionan. Por ejemplo, si el Input 1 tiene el valor 2 y el Input 2
tiene el valor 3; mientras que el peso de la conexión del Input 1 con el Output 1 es 1 y la
del Input 2 con el Output 1 es 1 (ver Figura 2.3). Si el umbral del Output 1 es 4 y se
ingresan ambos inputs, se puede decir que se cumple el Output 1. Esto se debe a que la
suma de las multiplicaciones de los inputs con los pesos de sus conexiones (2x1 + 3x1),
excede el valor mínimo para que se cumpla el Output 1, que es 4.11
2Input 1
3Input 2
1
Output 141
4Figura 2.3 – Ejemplo de Red Neuronal Artificial
Fuente: Elaboración propia
Para efectos de aprendizaje de las redes neuronales, se agregan capas intermedias entre
los inputs iniciales y los outputs finales. En el caso de la técnica de aprendizaje Back
11
Cfr. Stergiou y Siganos 1997
CAPÍTULO 2. FUNDAMENTO TEÓRICO
12
Propagation, las conexiones son inicializadas con valores aleatorios, los que serán
afinados posteriormente gracias a su rutina de aprendizaje. Esta rutina de aprendizaje
consiste en leer una serie de ejemplos de inputs y sus respectivos outputs, para graduar
los pesos de las conexiones hasta que la red funcione correctamente con los ejemplos
ingresados. Como es de suponer, en un principio puede que no funcionen los pesos de
las conexiones; sin embargo, se utiliza la diferencia entre el valor obtenido y valor
esperado para volver a calcular los pesos que deberían tener las conexiones, en el
sentido contrario. Vale decir, desde los outputs hacia los inputs.12
2.4 Sistema de codificación de las placas vehiculares
Por otro lado, el Ministerio de Transportes y Comunicaciones del Perú, a través del
Reglamento de placa única nacional de rodaje (2007) y de la Resolución Ministerial
321-2008 MTC/02: Modificación de las letras que identifican a los vehículos (2008), ha
dispuesto las reglas para la codificación de las placas de los vehículos del Perú. A
continuación se presenta un resumen de estas normas:
X1X2X3-000 ó X1X2-0000
PRIMERA LETRA X1:
Automóvil: A, B, C, D, E, F, G, H, I, J, K, L
Vehículo menor Automotor y Furgoneta: M, N
Camioneta Pick up: O, P
Camioneta Panel: Q
Camioneta Rural: R
Station Wagon: S,T
Ómnibus: U, V
Camión: W, X
Remolcador: Y
Remolque y Semi-remolque: Z
12
Cfr. Stergiou y Siganos 1997
SOFTWARE DE RECONOCIMIENTO DE PATRONES VEHICULARES
13
SEGUNDA LETRA X2:
A: Tumbes
B: Piura
C: Lambayeque
D: La Libertad
E: Ancash
F: Ica
G,I,Q,O: Lima - Callao
H: Arequipa
J: Moquegua
K: Tacna
L: Cajamarca
M: Huanuco
N: Pasco
P: Junín
R: Huancavelica
S: Ayacucho
T: Apurímac
U: Puno
V: Madre de Dios
W: Amazonas
X: San Martín
Y: Loreto
Z: Cuzco
Si la placa cuenta una tercera letra, es decir, X3, ésta es correlativa. Por esta razón, tanto
X3, como las cifras que se plasman en la placa, no brindan mayor información acerca
del vehículo.
En caso de que un vehículo no cumpla con esta codificación, existen muy altas
posibilidades de que tenga placas adulteradas.
CAPÍTULO 2. FUNDAMENTO TEÓRICO
14
SOFTWARE DE RECONOCIMIENTO DE PATRONES VEHICULARES
15
CAPÍTULO 3. SOFTWARE DE RECONOCIMIENTO DE
PATRONES VEHICULARES
En este capítulo se busca hacer una descripción detallada del proyecto, así como plasmar sus
objetivos y su alcance, para aclarar cualquier duda que se pueda tener con respecto al mismo.
3.1 Propuesta La propuesta de este proyecto es la realización de un sistema capaz de ayudar en la
labor de seguimiento de vehículos y prevención de actos delictivos, a través del manejo
de información recolectada de diferentes fuentes. Actualmente, algunas de estas fuentes
no explotan la información que obtienen al 100%; mientras que otras son usadas de una
manera bastante rudimentaria.
CAPÍTULO 3. SOFTWARE DE RECONOCIMIENTO DE PATRONES VEHICULARES
16
Proveedor de servicios por
Internet
Proveedor de eventos
Proveedor de antecedentes
policiales
Proveedor de órdenes de captura
e infracciones de tránsito
Software de Reconocimiento
de Patrones Vehiculares
Equipo de reconocimiento
de placas
Proveedor de datos personales
5Figura 3.1 – Software de Reconocimiento de Patrones Vehiculares
Fuente: Elaboración propia con imágenes obtenidas de Microsoft Office 2003 Clip Art
Tal como se muestra en la figura 3.1, este es un sistema de colaboración, es decir, no
tendría sentido sin la interacción con otros sistemas que lo alimenten de información.
Entre los datos que necesitaría para funcionar correctamente se encuentran los
siguientes:
Coordenadas de los vehículos, enviadas por cámaras con la capacidad de
reconocer las placas
Información acerca de vehículos con orden de captura
Información acerca de los propietarios de los vehículos detectados
SOFTWARE DE RECONOCIMIENTO DE PATRONES VEHICULARES
17
Entre las ventajas más saltantes que brinda una solución como el Software de
Reconocimiento de Patrones Vehiculares están las siguientes:
Alerta temprana
Gracias a los criterios que se definan para determinar si un vehículo es sospechoso o no,
se puede determinar qué vehículos lo son, para que se pueda alertar a las fuerzas del
orden antes de que se produzca un acto delictivo. Por mencionar algunos criterios, uno
de ellos es si el vehículo cuenta con orden de captura o si el propietario posee
requisitoria, o si el vehículo pasa más de 5 veces por un mismo punto de la ciudad en un
corto periodo de tiempo, entre otras.
Mayor supervisión de los vehículos que circulan por la zona
Todas las funcionalidades de la aplicación se resumen en una mayor supervisión de los
vehículos, de tal manera que se pueda mejorar la labor de vigilancia realizada por las
fuerzas del orden.
Proveer información sobre vehículos sospechosos a otros interesados
La capacidad que posee el sistema para determinar vehículos sospechosos es información
muy valiosa para entidades externas tales como la PNP y el Serenazgo, entre otros.
3.2 Objetivo General del Proyecto
Desarrollar un software capaz de analizar el tráfico de vehículos en la ciudad de Lima para
proporcionar información importante para la detección de vehículos sospechosos en 3
escenarios de tiempo: inmediatamente, con información de corto plazo y con información de
largo plazo.
3.3 Objetivos Específicos
Entre los objetivos específicos que se trazaron para este proyecto, se encuentran los
siguientes:
CAPÍTULO 3. SOFTWARE DE RECONOCIMIENTO DE PATRONES VEHICULARES
18
Objetivo específico 1. Desarrollar un software capaz de:
o Capturar y almacenar las placas de los vehículos que transitan en
distintos puntos de la ciudad por medio de las imágenes que son
capturadas por cámaras de seguridad.
o Procesar los datos de las placas en tiempo real con información de
requisitorias suministradas por las fuerzas policiales.
o Analizar el desplazamiento de los vehículos que están circulando
para detectar patrones de conducta sospechosos.
o Analizar el desplazamiento de los vehículos por períodos largos de
tiempo para detectar patrones de conducta sospechosos.
Determinar en qué consiste un patrón sospechoso
Mantener eventos históricos para su posterior análisis
Comparar las conductas de los vehículos con los patrones
definidos como sospechosos
o Emitir las alertas de detección de vehículos sospechosos respectivas
para los tres escenarios definidos (en tiempo real, a corto y a largo
plazo)
o Mostrar los puntos en los que se divisó un determinado vehículo, en
un rango de fechas (Rastreo de vehículos)
Objetivo específico 2. Implantar el Módulo Servidor, el Servicio
Implementador, el Servicio de Reconocimiento de Patrones y la base de
datos en un servidor de prueba, dentro del dominio de la universidad;
mientras que el Módulo de Mantenimiento y el Módulo de Monitoreo, en
computadoras conectadas a la misma red.
3.4 Alcance
Dentro del alcance del proyecto se considera la implementación del sistema central de
comunicaciones, servicio de implementación de datos, servicio de reconocimiento de
patrones vehiculares, módulo de monitoreo y módulo de mantenimiento.
En resumen, los subsistemas y las funciones que serán implementados son los siguientes:
SOFTWARE DE RECONOCIMIENTO DE PATRONES VEHICULARES
19
Reconocimiento de patrones de comportamiento
Definición de un vehículo sospechoso: El sistema se encargará de analizar el
comportamiento de cada vehículo de acuerdo a los lugares por los que ha estado
circulando, la frecuencia, entre otros criterios. Para esto se contempla la existencia de
un software desarrollado por terceros que brindará las coordenadas, las fechas, las
horas y las placas de los vehículos. Esta información deberá ser obtenida con el uso
de cámaras y aplicaciones capaces de reconocer las placas de los vehículos.
Gestión
Servidor
o Manejo del acceso al repositorio de datos: El acceso a la base de datos se
encontrará centralizado para tener un mayor control sobre el acceso a la
información.
o Comunicación con otros sistemas para la obtención de información
adicional: Este sistema no es autosuficiente, ni busca serlo, es por esta razón
que depende de otras aplicaciones para obtener información como el tráfico
de los vehículos (coordenadas, fechas, horas y placas), información de los
vehículos (propietarios, marcas, modelos, órdenes de captura), datos
personales de los propietarios, registros criminales (coordenadas, fechas,
horas, tipo de crimen)
Monitoreo
o Rastreo de vehículos en un entorno amigable al usuario: El sistema deberá
permitir que se haga el rastreo de los vehículos, basado en la información con
la que cuenta, y mostrarlo de manera que pueda ser fácil de interpretar.
o Notificación de las alertas detectadas al operador y a los centros de
seguridad: Una vez que el sistema detecte un comportamiento sospechoso en
algún vehículo, deberá notificar inmediatamente a los operadores y a los
centros de seguridad suscritos acerca del incidente.
o Generación de reportes sobre los vehículos sospechosos que son detectados
por el sistema.
Mantenimiento
CAPÍTULO 3. SOFTWARE DE RECONOCIMIENTO DE PATRONES VEHICULARES
20
o Mantenimiento de la información del sistema y sus usuarios: El sistema
permitirá hacer mantenimiento a ciertas tablas de la base de datos a las que
deben tener acceso los operadores.
3.5 Requerimientos del Software
De acuerdo al alcance definido, se establecieron una serie de requerimientos del producto,
los que fueron plasmados en forma de casos de uso. Los casos de uso del sistema software,
son los siguientes:
Autenticar usuario
Generar Reportes
Identificar Sospechoso
Lanzar Alerta
Mantener Centros de Seguridad
Mantener Institución
Mantener Marcas
Mantener Modelos
Mantener Propietarios
Mantener Tipos de zona
Mantener Vehículos
Mantener Zonas
Obtener Información del Propietario del Vehículo
Obtener Información del Vehículo
Obtener Registros Criminales por Zonas
Rastrear Vehículos por criterios
Registrar Alerta
Registrar Eventos
Ver Detalle de Alerta
Ver Historial de Alertas
Ver Log del Sistema
SOFTWARE DE RECONOCIMIENTO DE PATRONES VEHICULARES
21
Adicionalmente, se definieron dos roles en la aplicación: Operador y Administrador. Ambos
tienen los mismos permisos en la versión 1.0 del software, excepto que el administrador
puede ver un registro detallado de todas las acciones realizadas por los usuarios en la base de
datos.
A continuación se dará una pequeña descripción de cada uno de los casos de uso. Para más
detalle, ver las especificaciones de casos de uso.
Autenticar usuario
Para asegurar un buen nivel de seguridad, se decidió trabajar con Active Directory.
De este modo, solo los usuarios con acceso al dominio podrán ejecutar la aplicación.
Una vez que el usuario inicie la sesión de Windows, solo podrá acceder a la
aplicación, si pertenece al rol correcto. Es decir, los usuarios que se asignen al rol
indicado como rol de administradores para la aplicación, serán los únicos que podrán
ver el log de transacciones; mientras que los usuarios asignados al rol de operadores
podrán realizar todas las demás acciones. Cualquier usuario que no pertenezca a
estos roles no podrá ejecutar la aplicación.
Generar Reportes
Debido a que la aplicación tiene muchos procesos que son transparentes ante el
usuario final, el usuario necesita una forma de visualizar el resultado de la aplicación.
Por esta razón, se definieron algunos reportes que, tanto el operador como el
administrador, pueden visualizar. Estos reportes permiten ver los vehículos
sospechosos detectados, los vehículos con orden de captura y las alertas lanzadas, en
un determinado intervalo de tiempo.
CAPÍTULO 3. SOFTWARE DE RECONOCIMIENTO DE PATRONES VEHICULARES
22
6Figura 3.2 – Interfaz de los Reportes Predefinidos
Fuente: Elaboración propia
7Figura 3.3 – Interfaz del Reporte de Autos con Orden de Captura Detectados por el
Sistema Fuente: Elaboración propia
8Figura 3.4 – Interfaz del Reporte de Autos Sospechosos Detectados por el Sistema
Fuente: Elaboración propia
SOFTWARE DE RECONOCIMIENTO DE PATRONES VEHICULARES
23
9Figura 3.5 – Interfaz del Reporte de Alertas Lanzadas por el Sistema
Fuente: Elaboración propia
Identificar Sospechoso
La aplicación cuenta con la capacidad de analizar si un vehículo es sospechoso o no,
de acuerdo a una serie de inputs. El criterio que tiene el sistema para determinar si un
vehículo es sospechoso o no, está definido por una tabla de la base de datos que es la
base del entrenamiento del módulo que identifica los vehículos sospechosos
(Servicio de Reconocimiento de Patrones). Entre los factores claves para decidir si
un vehículo es sospechoso o no, se encuentran los siguientes:
o Placa válida: Se verifica si la placa del vehículo en cuestión coincide con los
estándares de codificación de placas. Estos estándares se usan para clasificar
a los vehículos ya sea por el tipo de vehículo o el departamento de
inscripción del mismo. Para mayor detalle, ver la sección “Sistema de
codificación de las placas vehiculares” del capítulo anterior.
o Pasó por el mismo punto: Se verifica si el vehículo ha pasado por un mismo
punto de observación una cantidad N de veces en un periodo de tiempo T.
Los valores de N y T pueden ser configurados en el sistema. En esta
categorización, se descartan a los “vehículos conocidos en la zona” los cuales
son vehículos de propietarios que residen en la zona o la frecuentan
constantemente y no significan un riesgo en ese lugar.
CAPÍTULO 3. SOFTWARE DE RECONOCIMIENTO DE PATRONES VEHICULARES
24
o Pasó por lugares cercanos: Se verifica si el vehículo ha pasado por varios
puntos de observación que se encuentran a corta distancia en un periodo de
tiempo T, lo que puede indicar que el vehículo se encuentra rondando en la
zona. No se toman en cuenta los “vehículos conocidos en la zona”.
o Lunas polarizadas: Se verifica si el vehículo en cuestión cuenta con lunas
polarizadas.
o Modelo frecuentemente usado: Se verifica si el modelo del vehículo es uno
frecuentemente usado en actos ilícitos.
o Propietario con antecedentes: Se verifica si el propietario del vehículo posee
antecedentes policiales.
La combinación de estos factores son los que definirán si un vehículo es sospechoso
o no, de acuerdo a los registros de ejemplo ingresados en la base de datos. Para un
mayor detalle sobre esta funcionalidad, puede consultar el artefacto Especificación
de Caso de Uso: Identificar Sospechoso, adjunto a este documento.
Lanzar Alerta
Una vez que un vehículo sospechoso es detectado, el sistema debe guardar el registro
en la base de datos. Las aplicaciones de Monitoreo que estén corriendo en ese
momento, mostrarán la alerta registrada en la base de datos. Esta lista de alertas
registradas se refrescará cada cierto tiempo en la pantalla principal del módulo de
Monitoreo.
10Figura 3.6 – Prototipo para lanzar las alertas
Fuente: Elaboración propia
SOFTWARE DE RECONOCIMIENTO DE PATRONES VEHICULARES
25
11Figura 3.7 – Interfaz de centros de seguridad correspondientes a un determinado
punto geográfico Fuente: Elaboración propia
Mantener Centros de Seguridad
El operador debe ser capaz de insertar nuevos Centros de Seguridad o actualizar los
existentes. Llámese Centro de Seguridad a una división de una institución que tiene
asignado una determinada jurisdicción. Por ejemplo, una comisaría podría ser un
centro de seguridad para la institución PNP.
12Figura 3.8 – Interfaz del mantenimiento de Centro de Seguridad
Fuente: Elaboración propia
CAPÍTULO 3. SOFTWARE DE RECONOCIMIENTO DE PATRONES VEHICULARES
26
13Figura 3.9 – Interfaz de asociación de Centros de Seguridad con Zonas
Fuente: Elaboración propia
Mantener Institución
El operador debe ser capaz de insertar nuevas Instituciones o actualizar las
existentes. Una institución es definida como una entidad perteneciente a las fuerzas
del orden, que está representada a través de uno o más centros de seguridad. Por
ejemplo, una institución puede ser la Policía Nacional del Perú o Municipalidad de
San Borja o Serenazgo, según la forma en la que se desee organizar a los centros de
seguridad.
SOFTWARE DE RECONOCIMIENTO DE PATRONES VEHICULARES
27
14Figura 3.10 – Interfaz del Mantenimiento de Instituciones
Fuente: Elaboración propia
Mantener Marcas
El operador debe ser capaz de insertar nuevas marcas o actualizar las existentes. Las
marcas pueden contener valores como Toyota, Ford, etc.
15Figura 3.11 – Interfaz del Mantenimiento de Marcas
Fuente: Elaboración propia
CAPÍTULO 3. SOFTWARE DE RECONOCIMIENTO DE PATRONES VEHICULARES
28
Mantener Modelos
El operador debe ser capaz de insertar nuevos modelos o actualizar los existentes.
Los modelos cuentan con información de la clase de vehículo. Esto es un dato muy
importante para la detección de vehículos con placas fraudulentas.
16Figura 3.12 – Interfaz del Mantenimiento de Modelos
Fuente: Elaboración propia
Mantener Propietarios
El operador debe ser capaz de insertar nuevos Propietarios o actualizar los existentes.
Estos datos son importantes para saber de quién se está tratando al momento de
evaluar si un vehículo es sospechoso.
SOFTWARE DE RECONOCIMIENTO DE PATRONES VEHICULARES
29
17Figura 3.13 – Interfaz del Mantenimiento de la entidad Propietario
Fuente: Elaboración propia
Mantener Tipos de Zona
El operador debe ser capaz de insertar nuevos Tipos de Zona o actualizar los
existentes. Tipo de zona es la clasificación que se le da a una determinada zona. Por
ejemplo, un tipo de zona puede ser Departamento, Ciudad, Región, etc.
18Figura 3.14 – Interfaz del Mantenimiento de la entidad Tipo de Zona
Fuente: Elaboración propia
CAPÍTULO 3. SOFTWARE DE RECONOCIMIENTO DE PATRONES VEHICULARES
30
Mantener Vehículos
El operador debe ser capaz de insertar nuevos vehículos o actualizar los existentes.
Aquí se puede manejar información adicional sobre el vehículo para mejorar la
calidad del análisis realizado.
19Figura 3.15 – Interfaz del Mantenimiento de la entidad Vehículo
Fuente: Elaboración propia
20Figura 3.16 – Interfaz de asociación de Vehículos con Zonas
Fuente: Elaboración propia
SOFTWARE DE RECONOCIMIENTO DE PATRONES VEHICULARES
31
Mantener Zonas
El operador debe ser capaz de insertar nuevas Zonas o actualizar las existentes. Esta
sección debe ser íntegramente mantenida por el usuario, al menos en esta versión de
la aplicación. El sistema permite seleccionar las regiones correspondientes a las
zonas a partir de un mapa.
21Figura 3.17 – Interfaz del mantenimiento de Zonas
Fuente: Elaboración propia
Obtener Información del Propietario del Vehículo
El sistema es capaz de obtener información relacionada al propietario de un vehículo
desde fuentes externas, siempre y cuando estén disponibles. Esta tarea no es visible
para el usuario y se ejecuta automáticamente. La frecuencia con la que se lleva a
cabo esta tarea puede ser configurada como se crea conveniente (ver Adjunto Guía
de Instalación).
Obtener Información del Vehículo
El sistema es capaz de obtener información relacionada con el vehículo, de tal
manera que pueda tener datos actualizados para un mejor análisis, desde fuentes de
datos externas, como del Registro Nacional de Identificación y Estado Civil
(RENIEC), la Superintendencia Nacional de los Registros Públicos (SUNARP) y la
Policía Nacional del Perú (PNP). Para el desarrollo del proyecto, se simuló la
existencia de estas fuentes de información, como se explica más adelante. Esta tarea
CAPÍTULO 3. SOFTWARE DE RECONOCIMIENTO DE PATRONES VEHICULARES
32
no es visible para el usuario y se ejecuta automáticamente. La frecuencia con la que
se lleva a cabo esta tarea puede ser configurada como se crea conveniente (ver
Adjunto Guía de Instalación).
Obtener Registros Criminales por Zonas
El sistema es capaz de obtener información de registros criminales en determinados
puntos geográficos, desde fuentes de datos externas, como del Registro Nacional de
Identificación y Estado Civil (RENIEC), la Superintendencia Nacional de los
Registros Públicos (SUNARP) y la Policía Nacional del Perú (PNP). Para el
desarrollo del proyecto, se simuló la existencia de estas fuentes de información,
como se explica más adelante. Esta tarea no es visible para el usuario y se ejecuta
automáticamente. La frecuencia con la que se lleva a cabo esta tarea puede ser
configurada como se crea conveniente (ver Adjunto Guía de Instalación).
Registrar Eventos
El sistema obtiene información acerca de nuevos eventos desde fuentes de datos
externas. Por evento, se entiende una incidencia del reconocimiento de una
determinada placa, a una hora y en un punto geográfico exacto. Esta tarea no es
visible para el usuario y se ejecuta automáticamente. La frecuencia con la que se
lleva a cabo esta tarea puede ser configurada como se crea conveniente (ver Adjunto
Guía de Instalación).
Rastrear Vehículos por criterios
El sistema permite mostrar los puntos por los que pasó un determinado vehículo, a
partir de su placa y el rango de tiempo en el que se desea ver sus movimientos.
SOFTWARE DE RECONOCIMIENTO DE PATRONES VEHICULARES
33
22Figura 3.18 – Interfaz de Rastreo de Vehículos
Fuente: Elaboración propia
Registrar Alerta
Una vez que se detecta un vehículo sospechoso, se debe generar una alerta, para que
luego pueda ser vista por los operadores en la interfaz principal del módulo de
Monitoreo.
Ver Detalle de Alerta
A través del módulo de monitoreo, el sistema permite mostrar el detalle de las alertas
lanzadas. Además, permite ver las autoridades a las que se debería reportar el
incidente, de acuerdo a la zona en la que fue detectado el vehículo al momento de la
emisión de la alerta.
CAPÍTULO 3. SOFTWARE DE RECONOCIMIENTO DE PATRONES VEHICULARES
34
23Figura 3.19 – Interfaz principal del Módulo de Monitoreo con el detalle de una alerta
Fuente: Elaboración propia
Ver Historial de Alertas
El sistema muestra las alertas lanzadas en un determinado intervalo de tiempo, de
acuerdo a los criterios que seleccione el usuario. Estos criterios pueden ser el tipo de
alerta o el estado (atendido o no atendido).
24Figura 3.20 – Interfaz del Historial de Alertas
Fuente: Elaboración propia
SOFTWARE DE RECONOCIMIENTO DE PATRONES VEHICULARES
35
Ver Log del Sistema
El administrador puede ver un log donde se indican las transacciones que se han
realizado (se registran las transacciones siempre y cuando el almacenamiento de
transacciones esté habilitado).
25Figura 3.21 – Interfaz del Log del Sistema
Fuente: Elaboración propia
Vale hacer la aclaración de que en la mayoría de los mantenimientos no se colocó la opción
eliminar, debido a que al trabajar con datos históricos, esta información es de gran
importancia y no se puede correr el riesgo de perderla.
3.6 Interacción con otros sistemas
En el afán de desarrollar un sistema más completo y capaz de alimentarse de la información
de otros sistemas, se pensó en implementar una manera de comunicarse con otros sistemas
para complementar la información y así hacer una evaluación más completa de los
vehículos. La información obtenida se centraliza en tres aspectos principales:
Posicionamiento global de los vehículos
Para lograr el rastreo de los vehículos sospechosos con mayor facilidad y de una manera
más amigable al usuario final, se consume el servicio Google Maps provisto por
Google.
CAPÍTULO 3. SOFTWARE DE RECONOCIMIENTO DE PATRONES VEHICULARES
36
Datos de los vehículos
El sistema requiere de información extra sobre los vehículos para poder determinar si
estos se comportan de manera sospechosa. La información que se requiere se detalla en
la Tabla 3.1. Este aspecto se centra en la verificación de órdenes de captura de los
vehículos. En el futuro podría extenderse a infracciones de tránsito. En la actualidad
existen sistemas donde se muestra la información de los vehículos por Internet, como es
el caso de la página Web de la Superintendencia Nacional de los Registros Públicos
(SUNARP)13
, para los datos generales de los vehículos e información de los
propietarios. Por otro lado, las papeletas y órdenes de captura existentes pueden
obtenerse de la página Web de Papeletas por Infracciones de Tránsito del Servicio de
Administración Tributaria (SAT)14
. En este sitio, se revelan los resultados del trabajo
conjunto que el SAT y la Policía de Tránsito realizan15
. Adicionalmente, en la
indagación realizada con el Crnl. PNP Oswaldo Alfaro, Jefe de la División de
Emergencias de Radio Patrulla, se hizo mención a un sistema interno en el que se
manejaban tanto las requisitorias de las personas como las de los vehículos, DATAPOL;
sin embargo, el uso de este sistema está restringido a la Red Privada Policial. Para el
desarrollo de este proyecto, se usaron datos de prueba para cubrir toda la información
mencionada anteriormente.
Datos de los propietarios
Se obtienen los datos personales básicos de los propietarios para luego ser usados como
información complementaria al momento de comunicar las alertas detectadas a los
operadores del sistema. En un entorno real, esta información podría extraerse del sitio
Web del Registro de Identificación y Estado Civil (RENIEC)16
.
Antecedentes policiales de los propietarios
Esta información se requiere por ser usada como dato al momento de evaluar a los
vehículos y calificarlos como sospechosos o no sospechosos.
13
Cfr. SUNARP 2009 14
Cfr. SAT 2009 15
Cfr. El Comercio 2007 16
Cfr. RENIEC 2009
SOFTWARE DE RECONOCIMIENTO DE PATRONES VEHICULARES
37
Información de actos criminales
Esta información se requiere por ser usada como dato al momento de evaluar los
vehículos. Se refiere a la zona e indica si en la zona en donde se vio al vehículo se ha
producido algún tipo de acto ilícito, esto para ser usado como referencia para determinar
los vehículos sospechosos.
A continuación se muestra una tabla en donde se indican los diferentes datos que son
requeridos de los sistemas de información externos, así como su relación con una entidad del
sistema. Estos sistemas están representados por el nombre de la entidad a la que pertenecen.
Tabla 3.1 – Información extraída de sistemas externos Fuente: Elaboración propia
3.7 Fuentes de información de ejemplo Debido a la sensibilidad de la información externa requerida por el sistema, fue
imposible conseguir acceso a la misma en un espacio tan corto de tiempo. Sin embargo,
para la culminación exitosa del proyecto, se decidió desarrollar un mini sistema capaz
de simular la información que brindarían estos agentes externos. A continuación se
detallan las capacidades de este mini sistema.
Entidad del sistema Valores Sistema externo
Orden de Captura Motivo PIT (Sitio Web de Papeletas
por Infracciones de Tránsito)
Propietario del Vehículo Fecha de adquisición SUNARP
Propietario del Vehículo Propietario(s) de un
vehículo
SUNARP
Propietario Nombres RENIEC
Propietario Apellidos RENIEC
Propietario Dirección RENIEC
Propietario Fecha de nacimiento RENIEC
Propietario Número de DNI RENIEC
Antecedentes Policiales Motivo PNP
Vehículo Año de fabricación SUNARP
Vehículo Modelo SUNARP
Registro Criminal Fecha y hora PNP
Registro Criminal Coordenadas aproximadas PNP
Vehículo Placa EQUIPOS DE SEGURIDAD
Evento Vehículo EQUIPOS DE SEGURIDAD
Evento Fecha y hora EQUIPOS DE SEGURIDAD
Evento Coordenadas EQUIPOS DE SEGURIDAD
CAPÍTULO 3. SOFTWARE DE RECONOCIMIENTO DE PATRONES VEHICULARES
38
Este sistema Dummy es un Web Service que se conecta a una base de datos en la que se
almacenan todos los datos de prueba para que puedan ser expuestos por el servicio,
como se puede ver en la Figura 3.22. La información es consumida por una serie de
componentes pertenecientes al Módulo Implementador de la aplicación principal. Se ha
definido un componente por cada elemento de información que se desea obtener. Los
componentes que se encargan de la conexión directa con el sistema Dummy son los
siguientes:
26Figura 3.22 – Sistema Dummy
Fuente: Elaboración propia
UPC.SRPV.Servicios.Eventos: Este componente se encarga de realizar la conexión
con el Web Service con el objetivo de obtener los eventos más recientes registrados
en la base de datos, es decir, los vehículos que fueron identificados en un
determinado punto geográfico y a una determinada hora.
UPC.SRPV.Servicios.Propietario: Este componente se encarga de facilitar la
conexión con el Dummy con el fin de obtener información relacionada con los
propietarios de los vehículos registrados en los eventos. Se obtienen datos personales
y los antecedentes policiales de los propietarios.
UPC.SRPV.Servicios.RegistrosCriminales: Esta pieza de software se conecta con el
servicio Web para obtener registros de eventos criminales ocurridos en distintos
puntos de la ciudad.
UPC.SRPV.Servicios.Vehiculo: Este elemento se encarga de implementar los
métodos necesarios para conectarse con el Dummy para obtener información
relacionada a los vehículos que fueron identificados en los eventos.
SOFTWARE DE RECONOCIMIENTO DE PATRONES VEHICULARES
39
El sistema Dummy centraliza toda la información que debería ser provista por los
servicios de terceros para simular la existencia de los mismos, como se puede ver en la
Figura 3.23.
27Figura 3.23 – SRPV con el sistema Dummy
Fuente: Elaboración propia
La desintegración de los componentes que se usan para consumir la información fue
realizada teniendo en cuenta que las fuentes externas pueden ser variables. Vale decir,
nadie asegura que el formato en el que se obtiene la información va a mantenerse todo
el tiempo, es por eso que el desarrollo del software fue pensado como si cada fuente de
información fuera un servicio distinto, como se muestra en la Figura 3.24. En caso de
que los proveedores de esta data hagan un cambio en sus servicios, bastaría con
modificar el componente que implementa los métodos adecuados para la obtención de la
información del proveedor correspondiente. Esto le brinda la flexibilidad necesaria al
sistema para reducir el esfuerzo de programación al máximo en caso de un cambio en
los sistemas externos.
CAPÍTULO 3. SOFTWARE DE RECONOCIMIENTO DE PATRONES VEHICULARES
40
28Figura 3.24 – Servicios proveedores de información
Fuente: Elaboración propia
SOFTWARE DE RECONOCIMIENTO DE PATRONES VEHICULARES
41
CAPÍTULO 4. GESTIÓN DEL PROYECTO
En este capítulo se detalla lo referente a las tareas administrativas y de organización de los
recursos para el éxito en el desarrollo del proyecto. Además se plasma la carga de tareas a lo
largo de cada una de las fases del proyecto y los riesgos que se identificaron en el proceso.
4.1 Estimación
Como parte de la metodología, el tiempo destinado a la implementación del sistema debe
estar estimado para que se puedan asignar los recursos correctamente. El equipo de
desarrollo ha hecho uso de la técnica de estimación por casos de uso, lo cual dio un resultado
de de 1562 horas-hombre de esfuerzo, asumiendo que los integrantes del equipo son capaces
de culminar con un punto de función (UCP) en 10 horas. Esta información complementa a la
estimación ya que con esto se puede determinar el tiempo de duración del proyecto, el cual
es 16 meses, aproximadamente. Para más detalle se muestra la siguiente tabla.
# Caso de Uso UAW UUCW UUCP AUCP
1 Autenticación de usuario 1 10 11 9.99
3 Mantener vehículos 3 5 8 7.27
5 Mantener Centros de Seguridad 3 5 8 7.27
7 Rastrear vehículos por criterios 3 10 13 11.81
CAPÍTULO 4. GESTIÓN DEL PROYECTO
42
# Caso de Uso UAW UUCW UUCP AUCP
9 Ver historial de alertas 3 5 8 7.27
11 Registrar Evento 1 5 6 5.45
13 Obtener información del vehículo 2 5 7 6.36
15
Obtener información del propietario del
vehículo 2 5 7 6.36
17 Identificar sospechoso 1 10 11 9.99
19 Registrar Alerta 1 5 6 5.45
21 Lanzar Alerta 3 5 8 7.27
23 Generar reportes 3 5 8 7.27
25 Ver Log del sistema 3 5 8 7.27
27 Obtener registros criminales por zonas 2 5 7 6.36
29 Ver detalle de alerta 3 5 8 7.27
31 Mantener Instituciones 3 5 8 7.27
33 Mantener propietarios 3 5 8 7.27
35 Mantener tipos de zonas 3 5 8 7.27
37 Mantener modelos 3 5 8 7.27
39 Mantener marcas 3 5 8 7.27
41 Mantener Zonas 3 5 8 7.27
UCP 156.20
3Tabla 4.1 – Estimación del esfuerzo por caso de uso Fuente: Elaboración propia
Horas x UCP 10
Esfuerzo total (horas-hombre) 1562.04
Hombres-Mes 32.54
Número de integrantes del proyecto 2
Meses 16.27 4Tabla 4.2 – Estimación del esfuerzo del proyecto
Fuente: Elaboración propia
La metodología RUP da una visión, de acuerdo a la experiencia de diversos proyectos, de
cuánto tiempo y esfuerzo se debe destinar a cada una de las fases del RUP. Los tiempos se
muestran en la siguiente tabla, donde también se puede encontrar el tiempo estimado del
proyecto para cada una de estas fases.
Concepción Elaboración Construcción Transición
ESFUERZO 5,00 % 20,00 % 65,00 % 10,00 %
TIEMPO 12,00 % 21,00 % 50,00 % 17,00 % 5Tabla 4.3 – Distribución del esfuerzo y el tiempo según RUP
Fuente: West 2002
Concepción Elaboración Construcción Transición
ESFUERZO 78.10 312.41 1015.32 156.20
TIEMPO 1.95 3.42 8.14 2.77 6Tabla 4.4 – Distribución del esfuerzo y el tiempo del proyecto
Fuente: Elaboración propia
SOFTWARE DE RECONOCIMIENTO DE PATRONES VEHICULARES
43
Debido a que los tiempos estimados sobrepasaban por mucho los tiempos con los que se
contaba en el curso de Taller de Proyectos, Proyecto 1 y Proyecto 2, fue necesario continuar
con el desarrollo del mismo fuera del horario definido para estos cursos, para poder culminar
en los tres ciclos. Cabe señalar que durante la fase de Construcción se solicitó apoyo para
realizar las pruebas, por lo que el tiempo estimado para el proyecto se vio disminuido. Para
más detalle sobre los tiempos de las actividades, ver los adjuntos Plan de Iteración C1, C2 y
C3.
4.2 Hitos
A continuación, se describen los hitos para cada una de las fases del RUP. Para mayor
información acerca de estas fases, se puede recurrir a los planes de iteración de cada una de
ellas, que se encuentran en la sección de adjuntos.
4.2.1. Fase de Concepción
En esta fase desarrollaron los requisitos del producto desde la perspectiva del usuario, los
cuales fueron establecidos en el artefacto llamado Documento de Visión. Los principales
casos de uso fueron identificados y se plasmaron en el SRS (Especificación de los
Requerimientos del Software). La aceptación del cliente/usuario del Documento de Visión y
del Plan de Desarrollo marcó el final de esta fase. Además, el plan de riesgos, plan de
iteración, estimación del proyecto, entre otros. Al final de la fase se generó un release con
todos los artefactos citados. Los artefactos incluidos en esta entrega son el Plan de Desarrollo
del Software, Plan de Aceptación del Producto, Plan de Iteración, Lista de Riesgos,
Estimación del Proyecto, Visión del Proyecto, Reporte de Estado del Proyecto, SRS,
Especificaciones Suplementarias, Reporte de Estado del Proyecto y Prototipo Visual del
Producto.
Hito Fecha
Elaboración de la línea de base 01 Viernes semana 7 del 2007-1
Presentación de los Analistas ante
el Comité de Proyectos
Lunes semana 9 del 2007-1
7Tabla 4.5 – Hitos de la fase de Concepción Fuente: Elaboración propia
CAPÍTULO 4. GESTIÓN DEL PROYECTO
44
4.2.2. Fase de Elaboración
En esta fase se analizaron los requisitos y se desarrolló un prototipo de arquitectura
(incluyendo las partes más relevantes y/o críticas del sistema). Al final de esta fase, todos los
casos de uso correspondientes a los requerimientos que serían implementados en el primer
release de la fase de Construcción fueron analizados y diseñados (en el Modelo de
Análisis/Diseño).
La revisión y aceptación del prototipo de la arquitectura del sistema marcó el final de esta
fase. Adicionalmente, se incluyó una nueva versión de los artefactos entregados
anteriormente, con algunas mejoras.
La primera iteración tuvo como objetivo la identificación y especificación de los principales
casos de uso, así como su realización preliminar en el Modelo de Análisis/Diseño. También
se hizo una revisión general del estado de los artefactos hasta este punto y se ajustó la
planificación para asegurar el cumplimiento de los objetivos. Para esta línea base se
definieron los siguientes artefactos: Prototipo Visual del Producto (GUI), Modelo de Casos
de Uso, Reporte de Estado del Proyecto, Especificación de Casos de Uso, Modelo de
Análisis, Reporte de Estado del Proyecto, Estimación del Proyectos, Prototipo de la
Arquitectura del Software, Modelo de la Arquitectura del Software, SAD, Plan de Desarrollo
del Software y Plan de Pruebas.
Hito Fecha
Elaboración de la línea de base 02 Viernes semana 7 del 2007-1
Entrega por los Analistas a los
Gerentes de la “Formulación del
Proyecto” con observaciones
levantadas.
Lunes semana 9 del 2007-1
Presentación de los gerentes al
Comité de Proyectos y evaluación
conjunta
Miércoles semana 16 del 2007-1
Presentación de los Analistas ante
el Comité de Proyectos
Lunes semana 17 del 2007-1
8Tabla 4.6 – Hitos de la fase de Elaboración Fuente: Elaboración propia
SOFTWARE DE RECONOCIMIENTO DE PATRONES VEHICULARES
45
4.2.3. Fase de Construcción
Durante la fase de Construcción se terminó el análisis y diseño de todos los casos de uso,
refinando el Modelo de Análisis/Diseño. El producto se construyó en 3 iteraciones, de las
cuales se obtuvo un release, el cual fue sometido a pruebas y validado con el cliente/usuario.
Se comenzó la elaboración de material de apoyo al usuario. El hito que marcó el fin de esta
fase fue la presentación de un release con toda la capacidad operacional del producto, listo
para ser entregado a los usuarios para las pruebas beta.
Hito Fecha
Creación de línea de base C1 Viernes semana 7 del 2008-1
Presentación de los Analistas ante
el Comité de Proyectos
Lunes semana 9 del 2008-1
Creación de línea de base C2 Viernes semana 15 del 2008-1
Presentación de los Analistas ante
el Comité de Proyectos
Lunes semana 17 del 2008-1
Creación de línea de base C3 Viernes semana 7 del 2008-2
Presentación de los Analistas ante
el Comité de Proyectos
Lunes semana 9 del 2008-2
9Tabla 4.7 – Hitos de la fase de Construcción Fuente: Elaboración propia
4.2.4. Fase de Transición
El hito que marcó el fin de esta fase contemplaba la entrega de toda la documentación del
proyecto, con los manuales de instalación, el material de apoyo al usuario y el producto
empaquetado.
Hito Fecha
Creación de línea de base T1 Viernes semana 15 del 2008-2
Presentación de los Analistas ante
el Comité de Proyectos
Lunes semana 17 del 2008-2
10Tabla 4.8 – Hitos de la fase de Transición Fuente: Elaboración propia
4.3 Riesgos
4.3.1. Consideraciones
Los riesgos han sido clasificados por el tipo de efecto:
Costos: Los costos del proyecto pueden crecer.
Cronograma: Los entregables del producto pueden ser entregados tardíamente.
CAPÍTULO 4. GESTIÓN DEL PROYECTO
46
Funcionalidad: El nivel de desempeño o la capacidad prevista por los
entregables puede verse reducida.
Calidad: El nivel de excelencia de los entregables puede verse afectado.
4.3.2. Cuadro Resumen
Se ha realizado un cuadro de resumen ordenado de acuerdo al nivel de riesgo encontrado.
SOFTWARE DE RECONOCIMIENTO DE PATRONES VEHICULARES
47
ID Nombre Tipo de
Riesgo Impacto Probabilidad
Cálculo
del riesgo
Magnitud
riesgo
Contingencia
Riesgos relativos al normal desarrollo del proyecto
1 Ausencia de uno o más
integrantes del proyecto. Cronograma 1 3 3 BAJO
Hacer conocer al integrante del equipo sobre la
importancia del proyecto y de su rol en él.
2 Problemas de
convivencia con otros
equipos de proyectos en
el ambiente de trabajo.
Cronograma 1 4 6 BAJO
Redactar un acuerdo de convivencia que sea aceptado
por todas las personas que se encuentran en un
determinado ambiente de trabajo.
3 Problemas para
concretar entrevistas con
el cliente del proyecto.
Cronograma 2 4 8 MEDIO
Hacer recordar constantemente al cliente sobre las
entrevistas programadas.
Riesgos relacionados a la planificación, control y seguimiento del proyecto
4 Falta de precisión en la
estimación del proyecto. Calidad 3 2 8 MEDIO
Realizar una estimación poco optimista y asegurarse
que, durante el desarrollo del proyecto, no se produzcan
retrasos muy largos.
5 Sobrepaso del tiempo
destinado a cada tarea
del proyecto.
Cronograma 4 3 11 MEDIO
Destinar más tiempo a las tareas o asignarle un periodo
de holgura mayor a cada una.
6 Mal control de los
cambios. Calidad 4 2 10 MEDIO
Cada vez que se realice un cambio en el diseño o la
implementación, se deberá crear un registro en el
historial del componente(s) afectado(s).
7 Pérdida de información
vital sobre el proyecto. Costos 4 1 9 MEDIO
Tener backups del repositorio del proyecto en medios
de almacenamiento diseñados para catástrofes.
CAPÍTULO 4. GESTIÓN DEL PROYECTO
48
ID Nombre Tipo de
Riesgo Impacto Probabilidad
Cálculo
del riesgo
Magnitud
riesgo
Contingencia
Riesgos relacionados a la construcción y uso de herramientas
8 Tiempo destinado a
aprendizaje es muy
corto.
Cronograma 3 3 9 MEDIO
Incluir en la estimación, el tiempo para navegar por
Internet e investigar acerca de soluciones a los
problemas técnicos que se pudieran suscitar.
9 Falta de disponibilidad
de componentes de
desarrollo de terceros. Cronograma 3 4 10 MEDIO
Si existe un componente que cumple con los
requerimientos del proyecto, adquirirlo. En caso de que
no se pueda adquirir, desarrollar una pieza de software
con características similares.
10 Falta de disponibilidad
de herramientas de
desarrollo requeridas por
el proyecto. Cronograma 4 3 11 MEDIO
Luego de la conversación entre el equipo de desarrollo
y el jefe de proyecto, gestionar la instalación o
habilitación del recurso de software o hardware
requerido. Se deberá reorganizar el plan de trabajo e ir
avanzando con otras tareas que no requieran de las
herramientas no disponibles.
11 Falta de documentación
técnica sobre el tema del
proyecto.
Calidad 3 3 9 MEDIO
Capacitar constantemente al equipo de proyecto sobre
las nuevas tecnologías o técnicas de desarrollo.
12
Inadecuada
documentación en la
implementación (código
fuente).
Calidad 2 3 7 BAJO
Desarrollar un artefacto en el que se listen las pautas y
acuerdos sobre cómo se debe escribir código fuente, de
manera que sea legible para los desarrolladores.
13 Problemas de
integración entre los
diferentes componentes
del sistema.
Cronograma 4 2 10 MEDIO
Destinar más tiempo al diseño para evitar esta clase de
situaciones.
SOFTWARE DE RECONOCIMIENTO DE PATRONES VEHICULARES
49
14 Errores en la arquitectura
del sistema Funcionalidad 3 2 8 MEDIO
Realizar los cambios necesarios en la arquitectura e
implementar un caso de uso significativo para probar
que funcione de acuerdo a lo esperado.
CAPÍTULO 4. GESTIÓN DEL PROYECTO
50
SOFTWARE DE RECONOCIMIENTO DE PATRONES VEHICULARES
51
CAPÍTULO 5. DISEÑO DE LA SOLUCIÓN
En este capítulo se busca hacer una descripción detallada de cada una de las piezas de
software que se consideraron en la solución desarrollada.
5.1 Arquitectura de la solución
La arquitectura del Software de Reconocimiento de Patrones Vehiculares ha sido
desarrollada bajo una serie de buenas prácticas que aseguran el cumplimiento de uno de
los requerimientos principales de esta aplicación: la flexibilidad. La flexibilidad es una
necesidad básica en un sistema como este, que depende tanto de aplicaciones externas o
piezas de software externas que prácticamente sería inútil sin ellas. Por esta razón, los
lazos que comunican este sistema con otras piezas de software tienen que ser lo
suficientemente flexibles para que se puedan amoldar a nuevas piezas de software o a
las modificaciones que puedan realizarse a las actuales.
Otro de los requerimientos más importantes en el diseño del sistema es la centralización de
las comunicaciones. Esto se relaciona directamente con temas de seguridad y la
administración del acceso al repositorio de datos. En el proyecto se plantea que los módulos
CAPÍTULO 5. DISEÑO DE LA SOLUCIÓN
52
clientes, tales como el módulo de Monitoreo, de Mantenimiento, de Reconocimiento de
Patrones y el Implementador, puedan comunicarse con el módulo Servidor y que puedan
reemplazarse en cualquier momento por nuevas versiones de los mismos o por unos
completamente nuevos. Frente a este requerimiento, en el proyecto se optó por adoptar el
estilo arquitectónico Orientado a Servicios (SOA), para brindar los servicios de acceso a
datos y a los sistemas externos. Estos servicios se implementaron a través del uso de
Servicios Web. A continuación se muestra la parte de la arquitectura del sistema encargada
de la administración de las comunicaciones, el módulo Servidor.
29Figura 5.1 – Componentes del Módulo Proveedor
Fuente: Elaboración propia
Otro de los requerimientos planteados se refiere a la parte del sistema encargada de las
comunicaciones con los sistemas externos, de los que se extraerá información
complementaria para el funcionamiento del módulo de reconocimiento de vehículos.
Como parte del diseño, se plantea que este módulo contenga piezas de software que
permitan el libre reemplazo o actualización de las fuentes de información, es decir, que
este módulo permita cambiar la manera como se extrae la información de los sistemas
externos. Para esto, se plantea el uso de interfaces, las cuales serán implementadas por
piezas de software específicas para extraer la información de los sistemas externos. En
caso de que el sistema externo cambie la estructura de la información brindada, solo
SOFTWARE DE RECONOCIMIENTO DE PATRONES VEHICULARES
53
sería necesario reemplazar el componente implementador de la interfaz para que pueda
extraer la información satisfactoriamente.
30Figura 5.2 – Componentes del Módulo Implementador
Fuente: Elaboración propia
5.2 Módulo Servidor Este módulo es la columna vertebral del sistema, ya que se encarga de la gestión de las
comunicaciones de los demás módulos con el repositorio de datos. Los componentes que
intervienen en este módulo son los siguientes:
31Figura 5.3 – Componentes del Módulo Servidor
Fuente: Elaboración propia
CAPÍTULO 5. DISEÑO DE LA SOLUCIÓN
54
UPC.SRPV.Servidor.Proveedor.Interfaces
Este componente es el que contiene la interfaz que deberá implementar el módulo
UPC.SRPV.Servidor.Proveedor. En la interfaz IServidor se declaran todos los
métodos que debería implementar la clase Servidor del componente
UPC.SRPV.Servidor.Proveedor.
UPC.SRPV.Servidor.Proveedor
Este componente es el que contiene la implementación de la interfaz IServidor del
módulo UPC.SRPV.Servidor.Proveedor.Interfaces. En caso de que se deba hacer un
cambio en la implementación, por ejemplo, si se desea que el servidor ya no se
implemente por Web Services, sino por Net Remoting, éste es el componente que se
debería cambiar, junto con los componentes consumidores del módulo de
Mantenimiento y de Monitoreo.
UPC.SRPV.DAL.Intefaces
Este componente contiene todas las interfaces de los objetos de acceso a datos. Cada
una de estas será implementada por un objeto con el nombre de la interfaz, pero sin
la letra “I” delantera. Por ejemplo, si se tiene un IDAOEvento, su objeto
implementador en el componente UPC.SRPV.DAL será DAOEvento.
UPC.SRPV.DAL
Este componente contiene los objetos que implementan las interfaces definidas en
UPC.SRPV.DAL.Intefaces. Este componente se conecta directamente con el
componente UPC.Data, el cual se encargará de hacer la conexión directa con la base
de datos.
UPC.Data
Este componente de acceso a datos es el que interactúa con la base de datos
(PatronesVehiculares) directamente. El componente fue modificado de su versión
original desarrollada por el Ing. Aarón Ibáñez, con la ayuda de algunos alumnos de
la universidad, para que se pueda adaptar al uso de esquemas en Microsoft SQL
Server 2005. Además, se tuvieron que hacer correcciones a la implementación de
algunos de los métodos para que pueda funcionar correctamente.
SOFTWARE DE RECONOCIMIENTO DE PATRONES VEHICULARES
55
5.3 Módulo de Reconocimiento de Patrones
Este módulo se encarga del procesamiento de la información de los vehículos con el fin de
determinar si cumple con las características de un vehículo sospechoso. Para realizar esta
función, se optó por implementar una red neuronal ya que, de acuerdo a los requerimientos
descritos en el capítulo 3, esta es era opción más acorde a las necesidades. Este módulo se
concibió como un proceso independiente de los demás, que se encuentra procesando la
información de los vehículos constantemente, razón por la cual se decidió encapsularlo en un
servicio de Windows.
32Figura 5.4 – Componentes del Módulo de Reconocimiento de Patrones
Fuente: Elaboración propia
UPC.SRPV.Servicios.ReconocimientoDePatrones
Este Windows Service tiene como objetivo analizar los eventos a medida que se van
registrando en la base de datos, para luego identificar a los vehículos sospechosos. La
identificación de los vehículos sospechosos se hace a través de una red neuronal.
Esta red neuronal es entrenada al momento de iniciar el servicio en base a los datos
que se encuentran registrados en la tabla Sistema.EntrenamientoDeRed. Esta tabla
contiene una serie de reglas que son ejemplos en los que el sistema puede afirmar
que un vehículo es sospechoso o que no lo es. Una vez que se detectan nuevos
eventos registrados, el servicio evalúa el vehículo relacionado con cada evento, para
determinar si es o no es sospechoso.
5.4 Módulo Implementador Este módulo se encarga de las comunicaciones del sistema con fuentes de información
externas. Tiene la tarea de extraer información con el fin de replicarla en el sistema para que
las tareas de identificación de vehículos sospechosos se puedan realizar exitosamente. Los
componentes que intervienen en su arquitectura se muestran a continuación.
CAPÍTULO 5. DISEÑO DE LA SOLUCIÓN
56
33Figura 5.5 – Componentes del Módulo Implementador
Fuente: Elaboración propia
UPC.SRPV.Servicios.Implementador
Este Windows Service se encuentra en permanente funcionamiento y se encarga de
obtener la información relacionada a los vehículos que se han detectado en los
nuevos eventos que se van registrando en la base de datos.
UPC.SRPV.Servicios.Propietario.Interfaces
Este componente contiene las interfaces que debe implementar el componente
UPC.SRPV.Servicios.Propietario.
UPC.SRPV.Servicios.Propietario
Este componente implementa las interfaces definidas en
UPC.SRPV.Servicios.Interfaces. Se comunica directamente con el servicio que
provee los datos de los propietarios. En caso de que el servicio cambie su estructura
o simplemente se cambie de proveedor, lo único que deberá modificarse es este
componente.
WSPropietarios
Este componente representa al servicio que provee información acerca de los
propietarios de ciertos vehículos. Para efectos de la realización del proyecto, este
servicio se ha incluido en un Web Service que funciona como un dummy que
obtiene información de una base de datos donde se registran los datos de prueba.
SOFTWARE DE RECONOCIMIENTO DE PATRONES VEHICULARES
57
UPC.SRPV.Servicios.RegistrosCriminales.Interfaces
Este componente contiene las interfaces que el componente
UPC.SRPV.Servicios.RegistrosCriminales deberá implementar para realizar lo
propio.
UPC.SRPV.Servicios.RegistrosCriminales
Este componente implementa las interfaces definidas en el componente
UPC.SRPV.Servicios.RegistrosCriminales.Interfaces. Tiene como objetivo obtener
los registros criminales suscitados en diversos lugares de la ciudad. En caso de que
cambie la fuente de datos de registros criminales, basta con cambiar este componente
para que la aplicación continúe funcionando apropiadamente.
WSRegistrosCriminales
Este componente representa la fuente de datos de registros criminales. Para efectos
del desarrollo del proyecto, esta fuente de datos se simuló como parte del Web
Service WSDummy.
UPC.SRPV.Servicios.Vehiculo.Interfaces
Este componente contiene las interfaces que deberá implementar el componente
UPC.SRPV.Servicios.Vehiculo.
UPC.SRPV.Servicios.Vehiculo
Este componente implementa las interfaces definidas por el componente
UPC.SRPV.Servicios.Vehiculo.Interfaces. El objetivo de este componente es
comunicarse con el servicio proveedor de información acerca de los vehículos para
obtener la información relacionada con los autos que se han detectado en los nuevos
eventos registrados. En caso de que cambie la fuente de datos de los vehículos, este
es el único componente que deberá ser reemplazado.
WSVehiculos
Este componente representa al servicio proveedor de información relacionada con
los vehículos. Para efectos del desarrollo del proyecto, este componente fue
implementado como parte del Web Service WSDummy.
CAPÍTULO 5. DISEÑO DE LA SOLUCIÓN
58
UPC.SRPV.Servicios.Eventos.Interfaces
Este componente contiene las interfaces que definen las tareas necesarias para la
obtención de eventos.
UPC.SRPV.Servicios.Eventos
Este componente implementa las interfaces definidas en
UPC.SRPV.Servicios.Eventos.Interfaces. El objetivo de esta pieza de software es
comunicarse con el servicio proveedor de eventos para obtener los eventos a partir de
una determinada fecha. En caso de que se cambie de proveedor de eventos, lo único
que se deberá sustituir es este componente.
WSEventos
Este componente representa al servicio proveedor de eventos. Para efectos del
desarrollo del proyecto, se incluyó como parte del WSDummy, junto con los otros
proveedores de información.
5.5 Módulo de Monitoreo
Este módulo contiene la interfaz principal del sistema. Cuenta con capacidades referentes al
rastreo y seguimiento de vehículos, visualización de las alertas, visualización del historial de
alertas y generación de reportes.
La arquitectura de este módulo es la que se presenta a continuación.
34Figura 5.6 – Componentes del Módulo de Monitoreo
Fuente: Elaboración propia
SOFTWARE DE RECONOCIMIENTO DE PATRONES VEHICULARES
59
Google Maps API
Este componente representa al servicio provisto por Google para el uso de sus
mapas, es decir, Google Maps. Gracias a este componente se pudo mostrar una
interfaz de rastreo, bastante amigable al usuario. El uso de este componente supuso
un arduo trabajo de investigación para darle las funcionalidades adecuadas. A
continuación se muestra la interfaz de rastreo de vehículos.
35Figura 5.7 – Interfaz de seguimiento y rastreo de vehículos
Fuente: Elaboración propia
UPC.SRPV.Monitoreo.GUI
Este componente contiene la parte gráfica del sistema. En él se encuentran todas las
interfaces visuales. Además, este componente hace referencia al componente de
seguridad para asignarle el acceso debido solo a los usuarios autorizados. A
continuación se muestran algunas de las interfaces de este componente.
CAPÍTULO 5. DISEÑO DE LA SOLUCIÓN
60
36Figura 5.8 – Interfaz principal del módulo de Monitoreo
Fuente: Elaboración propia
37Figura 5.9 – Interfaz de historial de alertas
Fuente: Elaboración propia
UPC.SRPV.Monitoreo.BLL
Este componente contiene la lógica del negocio del Módulo de Monitoreo. En él se
definen una serie de operaciones que ayudarán al componente
UPC.SRPV.Monitoreo.GUI a mostrar los datos necesarios al usuario. Además, es el
nexo con el consumidor, es decir, si se cambia el componente
UPC.SRPV.Servidor.Proveedor, deberá cambiar el
UPC.SRPV.Monitoreo.Consumidor, pero el UPC.SRPV.Monitoreo.BLL no
necesitará ser modificado.
UPC.SRPV.Monitoreo.Consumidor.Interfaces
Este componente contiene las interfaces que definen los métodos que deberán ser
implementados por las clases de UPC.SRPV.Monitoreo.Consumidor. Estos métodos
SOFTWARE DE RECONOCIMIENTO DE PATRONES VEHICULARES
61
sirven para conectarse con el componente UPC.SRPV.Servidor.Proveedor y obtener
la información necesaria para el funcionamiento del módulo.
UPC.SRPV.Monitoreo.Consumidor
Este componente implementa las interfaces declaradas en
UPC.SRPV.Monitoreo.Consumidor.Interfaces. La función principal de esta pieza de
software es comunicarse con el componente UPC.SRPV.Servidor.Proveedor para
poder obtener los datos solicitados desde el UPC.SRPV.Monitoreo.BLL.
5.6 Módulo de Mantenimiento A través de este módulo, los operadores o administradores podrán insertar o actualizar los
datos almacenados en algunas de las tablas del sistema. Además, el administrador podrá ver
el Log de los cambios realizados en la base de datos, por cualquier usuario.
Los componentes definidos para este módulo, se pueden apreciar en la siguiente imagen.
38Figura 5.10 – Componentes del Módulo de Mantenimiento
Fuente: Elaboración propia
Google Maps API
Tal como se vio en la sección del Módulo de Monitoreo, este componente representa
al servicio provisto por Google para el uso de sus mapas, es decir, Google Maps.
CAPÍTULO 5. DISEÑO DE LA SOLUCIÓN
62
Gracias a este componente se pudo mostrar una de selección de zonas bastante
amigable. A continuación se muestra la interfaz de selección de zonas que se
encuentra en el componente UPC.SRPV.Mantenimiento.GUI.
39Figura 5.11 – Interfaz de selección de Zonas
Fuente: Elaboración propia
UPC.SRPV.Mantenimiento.GUI
Este componente contiene todas las interfaces de usuario que se presentarán en el
Módulo de Mantenimiento. Para la muestra de su información, se comunica con
UPC.SRPV.Mantenimiento.BLL. Además, se comunica con el
UPC.SRPV.Seguridad para que solo puedan tener acceso los usuarios autorizados.
A continuación se muestran algunas de las interfaces del módulo.
SOFTWARE DE RECONOCIMIENTO DE PATRONES VEHICULARES
63
40Figura 5.12 – Interfaz del Log del Sistema
Fuente: Elaboración propia
41Figura 5.13 – Interfaz de asociación de Vehículos con Zonas
Fuente: Elaboración propia
CAPÍTULO 5. DISEÑO DE LA SOLUCIÓN
64
42Figura 5.14 – Interfaz del mantenimiento de Zonas
Fuente: Elaboración propia
UPC.SRPV.Mantenimiento.BLL
Este componente contiene la lógica del negocio del Módulo de Mantenimiento. Para
realizar su función, se comunica con el UPC.SRPV.Mantenimiento.Consumidor, que
contiene la implementación de las interfaces definidas en
UPC.SRPV.Mantenimiento.Consumidor.Interfaces.
UPC.SRPV.Mantenimiento.Consumidor.Interfaces
Este componente tiene las interfaces que deberá implementar el componente
UPC.SRPV.Mantenimiento.Consumidor. Estas interfaces tienen el objetivo de
definir los métodos que se usarán para comunicarse con el servicio
UPC.SRPV.Servidor.Proveedor.
UPC.SRPV.Mantenimiento.Consumidor
Este componente implementa las interfaces definidas en
UPC.SRPV.Mantenimiento.Consumidor.Interfaces. El objetivo de este componente
es comunicarse con el servicio UPC.SRPV.Servidor.Proveedor para facilitar la
información necesaria para el correcto funcionamiento del módulo a sus capas
superiores.
SOFTWARE DE RECONOCIMIENTO DE PATRONES VEHICULARES
65
CAPÍTULO 6. CONSTRUCCIÓN DEL PRODUCTO
Este capítulo está destinado a la fase de construcción del software. En él se tratarán temas
como herramientas usadas, estándares aplicados, y las piezas de software creadas para darle
vida al sistema en el entorno de desarrollo y producción.
6.1 Herramientas de desarrollo Para la construcción del software se usaron suites de desarrollo acordes con la plataforma de
desarrollo elegida para el proyecto, así como otras que son ampliamente aceptadas y
preferidas por la comunidad de desarrolladores. Las herramientas utilizadas en el proyecto se
pueden categorizar en las siguientes:
6.1.1. Entonos de desarrollo
Microsoft Visual Studio 2005: Entorno de desarrollo bajo tecnología .Net. Este
IDE es ampliamente preferido por la comunidad de desarrollos bajo plataforma
.Net. Su uso fue intensivo durante el desarrollo del proyecto.
Microsoft SQL Server 2005: Esta herramienta de administración de bases de
datos relacionales fue utilizada en el proyecto para la gestión de los repositorios.
CAPÍTULO 6. CONSTRUCCIÓN DEL PRODUCTO
66
6.1.2. Herramientas CASE
IBM Rational Rose: Herramienta CASE propietaria de IBM. Esta herramienta se
utilizó para elaborar los diagramas UML.
6.1.3. Herramientas de gestión
Microsoft Project 2003: Se utilizó para manejar la planeación del proyecto.
TortoiseCVS y CVSNT: Fueron utilizadas para controlar los cambios en el
código fuente.
6.1.4. Herramientas de SQA y Gestión del Cambio
IBM Rational Robot: Herramienta para realizar pruebas automáticas al software.
IBM Rational Test Manager: Herramienta para realizar pruebas manuales al
software.
IBM Rational ClearQuest: Herramienta de gestión de cambio en el desarrollo del
software.
6.2 Estándares y patrones de diseño
Para la fase de construcción del software, se han establecido ciertos estándares para
facilitar la codificación e interpretación del código fuente de la aplicación. Estos
estándares se elaboran con la finalidad de mejorar la calidad del producto. En el
presente proyecto se ha elaborado un documento llamado “Estándares de Codificación“,
el cual se encuentra entre los adjuntos presentados.
En cuanto a las buenas prácticas y patrones de desarrollo, se puede encontrar una lista
extensa, pero para el desarrollo de este sistema se han usado, principalmente, los
siguientes:
6.2.1. Adapter
Este patrón de diseño fue creado para solucionar aquellos problemas en los que se
necesita que dos clases que normalmente no podrían comunicarse por incompatibilidad
en sus interfaces, lo hagan a través de una tercera clase. Este patrón es bastante usado a
lo largo de todo el sistema. Puntualmente, su uso radica al adaptar el componente que
SOFTWARE DE RECONOCIMIENTO DE PATRONES VEHICULARES
67
captura las imágenes de la cámara al componente externo de reconocimiento de
imágenes, para conectar el servicio que obtiene información de los vehículos con la
pieza de software o Web Service que la provea y para comunicar el servicio que obtiene
información de los propietarios con la aplicación.
6.2.2. Bridge
Este patrón fue creado para eliminar la unión entre una abstracción y su implementación. En
la arquitectura del Sistema de Reconocimiento de Patrones Vehiculares está presente en la
separación de las clases adaptadoras de sus interfaces, de tal manera que, en caso de que se
cambie de algún proveedor de información o pieza de software, solo se tendría que crear un
adaptador que cumpla con las interfaces definidas, de tal manera que no hayan malos
entendidos con los componentes que usen esta información
6.3 Proyectos creados en el desarrollo del software El software se encuentra dividido en módulos, por lo que es conveniente realizar el listado de
proyectos de código fuente en base a criterios como módulo y capa.
6.3.1. Módulo Monitoreo
Este módulo se encuentra dividido en dos capas, la Capa de Presentación y la Capa de
Lógica de Negocios. Para su correcto funcionamiento, necesita conectarse al Servidor
Central. Adicionalmente, se encuentra dividido en los siguientes proyectos:
UPC.SRPV.Monitoreo.GUI: Proyecto de tipo Windows Forms que contiene las interfaces
gráficas de usuario del módulo.
CAPÍTULO 6. CONSTRUCCIÓN DEL PRODUCTO
68
43Figura 6.1 – Proyecto UPC.SRPV.Monitoreo.GUI en Visual Studio Fuente: Elaboración propia
UPC.SRPV.Monitoreo.BLL: Proyecto de tipo Librería de Clases que contiene las
funcionalidades necesarias para apoyar a la interfaz gráfica.
44Figura 6.2 – Proyecto UPC.SRPV.Monitoreo.BLL en Visual Studio Fuente: Elaboración propia
UPC.SRPV.Monitoreo.Consumidor.Interfaces: Proyecto de tipo Librería de Clases que
contiene las interfaces para comunicarse con el Servidor Central.
45Figura 6.3 – Proyecto UPC.SRPV.Monitoreo.Consumidor.Interfaces en Visual Studio Fuente: Elaboración propia
UPC.SRPV.Monitoreo.Consumidor: Proyecto de tipo Librería de Clases que contiene la
implementación de las interfaces para comunicarse con el Servidor Central.
SOFTWARE DE RECONOCIMIENTO DE PATRONES VEHICULARES
69
46Figura 6.4 – Proyecto UPC.SRPV.Monitoreo.Consumidor en Visual Studio Fuente: Elaboración propia
6.3.2. Módulo Mantenimiento
Este módulo se encuentra dividido en dos capas, la Capa de Presentación y la Capa de
Lógica de Negocios. Cuenta con la lógica necesaria para comunicarse con el servidor central
para funcionar. Este módulo se encuentra dividido en los siguientes proyectos:
UPC.SRPV.Mantenimiento.GUI: Proyecto de tipo Windows Forms que contiene las
interfaces gráficas de usuario del módulo.
47Figura 6.5 – Proyecto UPC.SRPV.Mantenimiento.GUI en Visual Studio Fuente: Elaboración propia
UPC.SRPV.Mantenimiento.BLL: Proyecto de tipo Librería de Clases que contiene las
funciones necesarias para servir a la interfaz gráfica.
48Figura 6.6 – Proyecto UPC.SRPV.Mantenimiento.BLL en Visual Studio Fuente: Elaboración propia
CAPÍTULO 6. CONSTRUCCIÓN DEL PRODUCTO
70
UPC.SRPV.Mantenimiento.Consumidor.Interfaces: Proyecto de tipo Librería de clases que
contiene las interfaces para comunicarse con el Servidor Central.
49Figura 6.7 – Proyecto UPC.SRPV.Mantenimiento.Consumidor.Interfaces en Visual Studio
Fuente: Elaboración propia
UPC.SRPV.Mantenimiento.Consumidor: Proyecto de tipo Librería de Clases que contiene la
implementación de las interfaces para comunicarse con el Servidor Central.
50Figura 6.8 – Proyecto UPC.SRPV.Mantenimiento.Consumidor en Visual Studio Fuente: Elaboración propia
6.3.3. Módulo Servidor
Este módulo se encuentra dividido en dos capas, la Capa Acceso a Datos y la Capa
Proveedora de Servicios. Cuenta con la lógica necesaria para comunicarse con la base de
datos. Este módulo se encuentra dividido en los siguientes proyectos:
UPC.SRPV.Servidor.Proveedor: Proyecto de tipo Web Service que contiene la totalidad de
servicios para el funcionamiento del sistema. Esta capa implementa la interfaz de servicios
que se encuentra en el proyecto UPC.SRPV.Servidor.Proveedor.Interfaces.
51Figura 6.9 – Proyecto UPC.SRPV.Servidor.Proveedor en Visual Studio Fuente: Elaboración propia
UPC.SRPV.Servidor.Proveedor.Interfaces: Proyecto de tipo Librería de Clases que contiene
las interfaces que indican los servicios que se deben brindar a través del Servidor Central.
SOFTWARE DE RECONOCIMIENTO DE PATRONES VEHICULARES
71
52Figura 6.10 – Proyecto UPC.SRPV.Servidor.Proveedor.Interfaces en Visual Studio Fuente: Elaboración propia
UPC.SRPV.DAL.Interfaces: Proyecto de tipo Librería de Clases que contiene las interfaces
que se deben implementar para poder acceder al repositorio de datos.
53Figura 6.11 – Proyecto UPC.SRPV.DAL.Interfaces en Visual Studio Fuente: Elaboración propia
UPC.SRPV.DAL: Proyecto de tipo Librería de clases que contiene la implementación de las
interfaces para comunicarse con el repositorio de datos. Este proyecto contiene una
referencia al componente reusable UPC.Data, el cual brinda funcionalidad para simplificar el
acceso al repositorio de datos.
CAPÍTULO 6. CONSTRUCCIÓN DEL PRODUCTO
72
54Figura 6.12 – Proyecto UPC.SRPV.DAL en Visual Studio Fuente: Elaboración propia
6.3.4. Módulo de Reconocimiento de Patrones
Este módulo se constituye por un solo proyecto que implementa un Servicio de Windows y
que consta de una sola capa.
UPC.SRPV.Servicios.ReconocimientoDePatrones: Proyecto de tipo Windows Service que
contiene la lógica necesaria para realizar el reconocimiento de patrones de comportamiento
de los vehículos. En este proyecto se hace referencia al componente reusable
xpidea.neuro.net.dll el cual brinda funcionalidad relacionada al trabajo con redes neuronales.
SOFTWARE DE RECONOCIMIENTO DE PATRONES VEHICULARES
73
55Figura 6.13 – Proyecto UPC.SRPV.Servicios.ReconocimientoDePatrones en Visual Studio Fuente: Elaboración propia
6.3.5. Módulo Implementador
Este módulo se encuentra dividido en dos capas, la capa de lógica de negocio y una capa
constituida por un servicio de tipo Windows. Cuenta con la lógica para extraer información
de los sistemas externos. Este módulo se encuentra dividido en los siguientes proyectos:
UPC.SRPV.Servicios.Implementador: Proyecto de tipo Windows Service que contiene las
funcionalidad para realizar las tareas de extracción de información de los sistemas externos.
56Figura 6.14 – Proyecto UPC.SRPV.Servicio.Implementador en Visual Studio Fuente: Elaboración propia
UPC.SRPV.Servicios.Eventos.Interfaces: Proyecto de tipo Librería de Clases que contiene
las interfaces para comunicarse con el sistema externo que provee información de los
eventos.
57Figura 6.15 – Proyecto UPC.SRPV.Servicios.Eventos.Interfaces en Visual Studio Fuente: Elaboración propia
CAPÍTULO 6. CONSTRUCCIÓN DEL PRODUCTO
74
UPC.SRPV.Servicios.Eventos: Proyecto de tipo Librería de Clases que contiene la
implementación de las interfaces para obtener los eventos.
58Figura 6.16 – Proyecto UPC.SRPV.Servicios.Eventos en Visual Studio Fuente: Elaboración propia
UPC.SRPV.Servicios.Propietario.Interfaces: Proyecto de tipo Librería de Clases que
contiene las interfaces para comunicarse con el sistema externo que provee información de
los propietarios.
59Figura 6.17 – Proyecto UPC.SRPV.Servicios.Propietario.Interfaces en Visual Studio Fuente: Elaboración propia
UPC.SRPV.Servicios.Propietario: Proyecto de tipo Librería de Clases que contiene la
implementación de las interfaces para obtener los propietarios.
60Figura 6.18 – Proyecto UPC.SRPV.Servicios.Propietario en Visual Studio Fuente: Elaboración propia
UPC.SRPV.Servicios.Vehiculo.Interfaces: Proyecto de tipo Librería de Clases que contiene
las interfaces para comunicarse con el sistema externo que provee información de los
vehículos.
61Figura 6.19 – Proyecto UPC.SRPV.Servicios.Vehiculo.Interfaces en Visual Studio Fuente: Elaboración propia
SOFTWARE DE RECONOCIMIENTO DE PATRONES VEHICULARES
75
UPC.SRPV.Servicios.Vehiculo: Proyecto de tipo Librería de Clases que contiene la
implementación de las interfaces para obtener los vehículos.
62Figura 6.20 – Proyecto UPC.SRPV.Servicios.Vehiculo en Visual Studio Fuente: Elaboración propia
UPC.SRPV.Servicios.RegistrosCriminales.Interfaces: Proyecto de tipo Librería de Clases
que contiene las interfaces para comunicarse con el sistema externo que provee información
de los registro de crímenes en la ciudad.
63Figura 6.21 – Proyecto UPC.SRPV.Servicios.RegistrosCriminales.Interfaces en Visual Studio
Fuente: Elaboración propia
UPC.SRPV.RegistrosCriminales: Proyecto de tipo Librería de Clases que contiene la
implementación de las interfaces para obtener los registro de crímenes.
64Figura 6.22 – Proyecto UPC.SRPV.Servicios.RegistrosCriminales en Visual Studio Fuente: Elaboración propia
CAPÍTULO 6. CONSTRUCCIÓN DEL PRODUCTO
76
SOFTWARE DE RECONOCIMIENTO DE PATRONES VEHICULARES
77
CAPÍTULO 7. ASEGURAMIENTO DE LA CALIDAD DEL
SOFTWARE
Para asegurar la calidad del producto final y de los artefactos relacionados al mismo, se han
realizado una serie de pruebas. En principio, la mayoría de las pruebas fueron de índole
funcional. En este capítulo se describe el proceso que se siguió para llevar a cabo esta tarea.
7.1 Fábricas de Software UPC
Debido a ciertas complicaciones que se encontraron con proyectos anteriores, el Comité de
Proyectos de la carrera decidió idear una manera de asegurar la calidad de los proyectos que
se presentaran. Para lograr este fin, se dispuso la reorganización de algunos de los talleres
existentes, los cursos de Taller de Desarrollo, Taller de Desarrollo y Pruebas, y Validación y
Verificación, se transformaron en empresas o fábricas de software.
Estas empresas tenían como objetivo principal el aseguramiento de la calidad de los
artefactos presentados por los equipos de proyecto. Para esto, las empresas brindaban
servicios a los alumnos de los cursos de Taller de Proyectos, Proyecto 1 y Proyecto 2. Los
servicios provistos por estas empresas eran de desarrollo, pruebas de software, y validación y
verificación de artefactos.
CAPÍTULO 7. ASEGURAMIENTO DE LA CALIDAD DEL SOFTWARE
78
Para cumplir con sus objetivos, las empresas definieron toda una estructura de trabajo basada
en roles. Dentro de ellas se dividieron en equipos para poder suplir las necesidades de los
equipos de proyecto. Como resultado, además de la retroalimentación que se podía obtener
del trabajo con estos equipos, las empresas emitían un certificado que aseguraba que su
trabajo se había cumplido de manera satisfactoria y un reporte con el resultado de las
pruebas, según correspondiera.
En el caso particular de este proyecto, el equipo tuvo que interactuar con las empresas de
NET Factory y V&V. El trabajo de NET Factory consistía en realizar pruebas funcionales
sobre aplicaciones desarrolladas con la tecnología .NET, basadas en las especificaciones de
casos de uso. Por otro lado, V&V se encargaba de hacer la verificación y la validación de los
documentos, así como la prueba de aceptación de los productos, para luego emitir un
certificado de conformidad.
7.2 Pruebas Funcionales Estas pruebas estuvieron a cargo de la empresa NET Factory. Para dar inicio a las pruebas, se
tuvo que firmar un contrato en el que tanto la empresa como el equipo de proyecto se
comprometían a facilitar el trabajo mutuo a través de la entrega de todos los artefactos
solicitados por ambas partes.
Una vez realizado el contrato, un equipo de testers fue asignado al proyecto. A este personal
se le hizo entrega de los documentos correspondientes a las especificaciones de casos de uso
del sistema. El equipo de testers se encargó de verificar el correcto funcionamiento del
sistema, de acuerdo al contenido de las especificaciones.
Para que el equipo de testers pudiera realizar su trabajo, el equipo de proyecto decidió
trabajar con máquinas virtuales de Microsoft Virtual PC. En estas máquinas virtuales se
instalaron y configuraron todos los módulos del proyecto para que los testers pudieran hacer
las pruebas correctamente.
Adicionalmente, durante las pruebas, se detectaron algunas fallas en la estructura de los
documentos entregados. Estos documentos fueron enviados a la empresa de V&V para una
revisión a mayor detalle.
SOFTWARE DE RECONOCIMIENTO DE PATRONES VEHICULARES
79
Culminadas las pruebas funcionales, el equipo de testers envió un reporte de las pruebas
realizadas. Este reporte contenía una lista con todas las fallas encontradas.
El equipo del proyecto se encargó de corregir todos los defectos encontrados, tal como lo
indicaron los testers. Una vez que se verificó que el software no contaba con las fallas
encontradas, se volvió a enviar el software y los documentos para una nueva revisión.
El equipo de testers se encargó de verificar que todo se encontrara funcionando
correctamente e incluso dio algunas recomendaciones de mejora.
Gracias a NET Factory y al equipo de testers asignados, se pudieron solucionar muchas
fallas en el sistema y, en consecuencia, se pudo asegurar un alto nivel de calidad en el
desarrollo. Como resultado, se hizo entrega de una constancia del trabajo realizado en el
proyecto.
Por otro lado, la empresa V&V también asignó un equipo de testers para la realización de
pruebas sobre los documentos del sistema. Este grupo de testers se encargó de encontrar
errores en los documentos, clasificarlos y, por último, reportarlos.
Los errores encontrados en los documentos fueron revisados y corregidos, de acuerdo al
nivel de severidad asignado. Una vez que se verificó que los errores fueron corregidos, se
envió a la empresa de V&V una vez más. Lamentablemente, por la fecha de entrega del
segundo reporte, las últimas recomendaciones no fueron plasmadas en los documentos; sin
embargo, no fueron tan críticas como las primeras.
Como se puede apreciar, gracias a las empresas de pruebas, se pudieron mejorar los
documentos y la aplicación, es decir, las empresas cumplieron con su objetivo y el equipo
del proyecto también se vio beneficiado con su trabajo.
7.3 Resultados de las pruebas
7.3.1. NET Factory
La empresa NET Factory clasificó los errores de acuerdo a una escala de severidad que se
había definido. A continuación se presentan los valores de la escala:
CAPÍTULO 7. ASEGURAMIENTO DE LA CALIDAD DEL SOFTWARE
80
Crítico: El aplicativo no puede ser completado exitosamente o el usuario no
obtendrá ningún beneficio del sistema si el defecto no es adecuadamente
dirigido.
Alta: Alguna parte del aplicativo no puede ser exitosamente completado o el
usuario recibirá solamente un beneficio parcial del sistema.
Promedio: Un elemento del aplicativo está en riesgo, el usuario perderá un
pequeño beneficio del sistema.
Baja: Temas cosméticos o triviales.
Gracias a la primera evaluación realizada por el equipo de pruebas de la empresa NET
Factory, en un inicio se pudieron identificar 59 errores. En la Tabla 7.1 se puede ver la
cantidad de errores por severidad encontrados.
Severidad # de
errores
Crítico 12
Alta 5
Promedio 11
Baja 31
11Tabla 7.1 – Reporte inicial de NET Factory Fuente: Elaboración propia
Estos errores fueron tratados en su mayoría para lograr reducirlos al máximo. En la
evaluación final realizada por el equipo de testers, se determinó que 33 de los errores
anteriormente mencionados fueron solucionados. El detalle de estos errores por severidad se
puede ver en la Tabla 7.2.
Severidad # de
errores
Crítico 9
Alta 4
Promedio 1
Baja 19
12Tabla 7.2 – Reporte final de NET Factory Fuente: Elaboración propia
Como se puede observar en la Tabla 7.3 la mayoría de los errores de severidad crítica y alta
fueron solucionados.
SOFTWARE DE RECONOCIMIENTO DE PATRONES VEHICULARES
81
Severidad
Porcentaje de
resolución
Crítico 75.00% Alta 80.00% Promedio 9.09% Baja 61.29%
13Tabla 7.3 – Porcentaje de solución de errores Fuente: Elaboración propia
Otros errores fueron corregidos luego del periodo de evaluación para lograr que el sistema
culmine correctamente, por esta razón no se pudo obtener un certificado de la empresa NET
Factory.
7.3.2. V&V
Por otro lado, con la aprobación de NET Factory, V&V se encargó de realizar las pruebas de
aceptación de usuario. Como resultado de la ejecución de las pruebas, el evaluador logró
concluir lo siguiente:
Para la validación de este proyecto el equipo de trabajo no presentó ninguna
dificultad en la documentación debido a que ya se habían realizado pruebas de
verificación en los documentos de casos de uso.
El proyecto cumple con la documentación necesaria y con los requisitos
previamente establecidos por la empresa durante el proceso de validación.
Las observaciones encontradas de mayor criticidad fueron corregidas por el
responsable del proyecto.
El proyecto especificado previamente está terminado y por tanto ha pasado
satisfactoriamente por el proceso de validación.
Estas conclusiones fueron plasmadas en un certificado que se les hizo entrega a los
miembros del grupo al final de las pruebas (ver adjunto Informe final de Verificación y
Validación).
CAPÍTULO 7. ASEGURAMIENTO DE LA CALIDAD DEL SOFTWARE
82
SOFTWARE DE RECONOCIMIENTO DE PATRONES VEHICULARES
83
CAPÍTULO 8. EMPAQUETADO Y PUESTA EN MARCHA DEL
SISTEMA
En este capítulo se describen los elementos que forman parte de la instalación del sistema,
así como el despliegue de la solución en un entorno real y en las instalaciones de la
universidad.
8.1 Instaladores del sistema
El sistema cuenta con instaladores para cada uno de sus módulos. Estos instaladores han sido
construidos de la forma mencionada para facilitar las tareas de despliegue del sistema.
Los instaladores del sistema se encuentran divididos en secciones de acuerdo al módulo al
que pertenecen. Estos se listan a continuación:
SqlDBRestore: Tiene la finalidad de instalar el repositorio de información del
sistema.
SRPV.Mantenimiento: Tiene la finalidad de instalar el módulo de Monitoreo.
SRPV.Mantenimiento: Tiene la finalidad de instalar el módulo de
Mantenimiento.
CAPÍTULO 8. EMPAQUETADO Y PUESTA EN MARCHA DEL SISTEMA
84
SRPV.Servidor: Tiene la finalidad de instalar el servidor central del sistema.
SRPV.Servicios.Implementador: Tienen la finalidad de instalar el módulo
encargado de la extracción de información de sistemas externos.
SRPV.Servicios.ReconocimientoDePatrones: Tiene la finalidad de instalar el
módulo encargado del reconocimiento de los patrones de movimiento de los
vehículos.
Con respecto al proceso de instalación del sistema, se creó un documento con el nombre
“Guía de Instalación” (ver adjunto Guía de Instalación), el cual detalla los pasos necesarios
para realizar la correcta instalación del sistema. Este documento se encuentra dentro de los
adjuntos.
Debido a que el proyecto se desarrolla íntegramente bajo las instalaciones de los
laboratorios de la universidad, el sistema ha sido condicionado para que los sistemas
externos con los que se debería interactuar en un entorno real, sean simulados de tal
manera se pueda comprobar el correcto funcionamiento del mismo. Para esto, se decidió
preparar un módulo representado por un Servicio Web que brinde la información que
sería extraída de los sistemas externos. Este módulo recibe el nombre de WSdummy y
cuenta con un instalador para el Servicio Web y un script para la creación del
repositorio de datos del mismo.
8.2 Despliegue del sistema en un entorno real
Como se puede ver en la figura anterior, dentro del ámbito del sistema se presentan 4
equipos a los que se les debe prestar especial atención, debido a que estos deben tenerse en
cuenta al momento de realizar el despliegue de la aplicación.
SOFTWARE DE RECONOCIMIENTO DE PATRONES VEHICULARES
85
INTERNET
VPN
Servicio de Registro de la Policía (PNP)
Servicio de Registro Público (SUNARP)
MANTENIMIENTOMONITOREO
SERVIDOR
Capa de Acceso a Datos
Servicio Implementador
Servicio de Reconocimiento de Patrones
db_PatronesVehiculares
65Figura 8.1 – Diagrama de despliegue en un entorno real Fuente: Elaboración propia
A continuación se enumeran los equipos y se describen sus principales funciones.
Monitoreo
Computadora en la que se encuentran instalados los componentes del paquete de
monitoreo. Puede haber múltiples computadoras con esta función. Se necesita la
intervención de un usuario para su funcionamiento. En estos equipos se puede realizar el
rastreo de vehículos y la mayoría de funciones que necesitan de un usuario final.
Mantenimiento
Computadora en la que están instalados los componentes de mantenimiento. Puede
haber múltiples computadoras con esta función. Se necesita la intervención de un
usuario para maniobrar el sistema y, básicamente, se pueden realizar tareas de inserción,
eliminación y modificación a las tablas de la aplicación.
Servidor
Computadora que contiene paquetes como el proveedor de servicios y de la capa de
acceso a datos. También contiene al servicio Implementador y al servicio de
Reconocimiento de Patrones, en permanente funcionamiento. Además, cumple con la
función de servidor Web, donde se colocará el Web Service de la aplicación. En este
CAPÍTULO 8. EMPAQUETADO Y PUESTA EN MARCHA DEL SISTEMA
86
computador también se encuentra el servidor de base de datos Microsoft SQL Server
2005. Por último, podría actuar como el Controlador de Dominio, en caso de que no
haya otro equipo que cumpla con esta función.
8.3 Despliegue del sistema en las instalaciones de la universidad Para el caso del despliegue del sistema en las instalaciones de la universidad, lo que se tenía
planeado para un entorno real, no se pudo concretar. Esta diferencia en el despliegue se debe,
esencialmente, a la negativa de la interacción con sistemas externos, por lo cual se optó por
implementar un Servicio Web que simule ser los sistemas externos y que sirva como fuente
de información para el módulo Implementador.
A continuación se muestra el diagrama de despliegue en las instalaciones de la universidad.
VPN
MANTENIMIENTOMONITOREO
SERVIDOR
Servicio web WsDummy (Sistema externo)
Capa de Acceso a Datos
Servicio Implementador
Servicio de Reconocimiento de Patrones
db_PatronesVehiculares
Wsdummy (bd) 66Figura 8.2 – Diagrama de despliegue en la universidad
Fuente: Elaboración propia
Deloitte Touche Tohmatsu Services, Inc.
Noviembre 2008
CONCLUSIONES
Las fuerzas del orden no se abastecen para realizar un seguimiento minucioso a
todos los vehículos que puedan resultar sospechosos, es por eso que necesitan de
herramientas de apoyo para mejorar su rendimiento.
Dado que en la actualidad, diversas entidades del Estado cuentan con sistemas de
información, esta información puede ser explotada para sacarle el mejor provecho
en herramientas que puedan apoyar a las fuerzas del orden.
Un software como este, necesita estar en constante comunicación con otras
aplicaciones o piezas de software para lograr su cometido.
Debido a su alta dependencia de otras aplicaciones, el Software de
Reconocimiento de Patrones Vehiculares necesitó que los puntos en los que se
unía con otros sistemas sean lo suficientemente flexibles para que puedan estar
CAPÍTULO 8. EMPAQUETADO Y PUESTA EN MARCHA DEL SISTEMA
ii
listos para cambiar de fuente de información o para soportar modificaciones en las
fuentes de información existentes con una baja posibilidad de fallas, el mínimo
esfuerzo y la mayor rapidez posible.
Aunque sea difícil de concebir la idea de un sistema con esta capacidad
funcionando en la realidad peruana, específicamente en Lima, se puede observar
que el sistema ViaPK, implantado por la Municipalidad del Callao ya se encuentra
funcionando y cuenta con resultados bastante satisfactorios hasta el momento.
Aunque el fin de ViaPK no es tan ambicioso como el de este software, ViaPK ha
abierto un nicho en la sociedad que está preparado para recibir a este proyecto.
SOFTWARE DE RECONOCIMIENTO DE PATRONES VEHICULARES
iii
RECOMENDACIONES
Automatizar las alertas para que sean enviadas directamente a las autoridades.
Unir el producto con un sistema de reconocimiento de placas que se integre con
cámaras en distintos puntos de la ciudad.
Intentar instalar el software en un entorno real para pulir los criterios para
determinar vehículos sospechosos y aumentar las reglas de aprendizaje del
sistema para que sea más certero.
Integrar con un sistema capaz de reconocer las características físicas de los
vehículos como el color y el polarizado de las lunas, para poder tener más criterios
para la detección de vehículos sospechosos.
CAPÍTULO 8. EMPAQUETADO Y PUESTA EN MARCHA DEL SISTEMA
iv
SOFTWARE DE RECONOCIMIENTO DE PATRONES VEHICULARES
v
GLOSARIO DE TÉRMINOS
Centro de Seguridad: Un Centro de Seguridad está definido como un puesto de
una determinada institución, que tiene asignada una zona como su jurisdicción.
Por ejemplo, Serenazgo de Surco.
Institución: Es un organismo al que se le va a notificar de eventos relacionados
con alertas lanzadas por el sistema. Por ejemplo, la Policía Nacional del Perú.
Serenazgo: Es un órgano encargado de coordinar y colaborar con otras
instituciones para la protección de las personas y bienes, con el objetivo de
mantener la tranquilidad y el orden ciudadano.17
ViaPk: Unidad móvil que permite identificar vehículos robados, con placas
clonadas, o que registren papeletas o infracciones al reglamento de tránsito.18
17
Cfr. Municipalidad de La Molina 2009 18
Cfr. Municipalidad del Callao 2008
CAPÍTULO 8. EMPAQUETADO Y PUESTA EN MARCHA DEL SISTEMA
vi
Zona: Región geográfica de forma rectangular, usada en el Software de
Reconocimiento de Patrones Vehiculares, que está definida entre dos puntos.
Estos puntos son sus coordenadas de inicio y de fin.
SOFTWARE DE RECONOCIMIENTO DE PATRONES VEHICULARES
vii
BIBLIOGRAFÍA
El Comercio (2007) Unos 1.000 vehículos exceden diariamente límites de velocidad
(consulta: 19 de julio de 2009)
(http://www.elcomercio.com.pe/EdicionImpresa/Html/2007-03-
28/ImEcVidayFuturo0698296.html)
GAMMA, Erich y otros (1994) Design Patterns: Design Patterns: Elements of Reusable
Object-Oriented Software. Boston: Addison-Wesley.
GIARRATANO, Joseph y RILEY, Gary (1998) Sistemas Expertos: Principios y
Programación. 3ª.ed. Madrid: Thomson.
Home Office (2004) POLICE SCIENCE AND TECHNOLOGY STRATEGY 2004 – 2009
(consulta: 22 de febrero de 2008)
(http://police.homeoffice.gov.uk/publications/operational-
policing/PoliceST_S2_part2.pdf?view=Binary)
CAPÍTULO 8. EMPAQUETADO Y PUESTA EN MARCHA DEL SISTEMA
viii
Instituto Nacional de Defensa de la Competencia y de la Protección de la Propiedad
Intelectual (INDECOPI) (2006) TECNOLOGIA DE LA INFORMACION. Procesos del
ciclo de vida del software. 2a. ed. Lima: INDECOPI.
Instituto de Defensa Legal (2007) Percepción sobre la seguridad ciudadana (consulta: 7 de
julio de 2008)
(http://www.seguridadidl.org.pe/destacados/2007/12-02/percepcion.doc)
ISO (2007) Text of ISO/IEC FCD 19796-3 ITLET - Quality management, assurance and
metrics - Part 3: Reference methods and metrics (consulta: 10 de julio de 2008)
(http://isotc.iso.org/livelink/livelink/fetch/2000/2122/327993/806742/1056984/36N1523_Te
xt_of_ISO_IEC_FCD_19796-3_ITLET_-_Quality_management__assurance_and_
metrics_-_Part_3._Reference_methods_and_metrics?nodeid=6422394&vernum=0)
KNOWLEDGE SYSTEMS INSTITUTE (2005) Expert Systems and their Essentials
Components (consulta: 10 de julio de 2008)
(http://distancelearning.ksi.edu/demo/509/cis509.htm)
LIN, ChieYu (2004) Neural Networks: A New Computing Paradigm (consulta: 10 de julio
de 2008)
(http://research.yale.edu/ysm/article.jsp?articleID=318)
MICROSOFT (2008) What are SOA & BPM? (consulta: 10 de julio de 2008)
(http://www.microsoft.com/soa/about/whatis.aspx)
Ministerio del Interior (2009) Reseña histórica y funciones del Escuadrón de Emergencia –
Centro (consulta: 14 de febrero de 2009)
(http://www.mininter.gob.pe/noticias/noticia.php?C_WC1Page=134&cat=1&sub=0&web=
212)
SOFTWARE DE RECONOCIMIENTO DE PATRONES VEHICULARES
ix
Municipalidad de La Molina (2009) La Unidad de Serenazgo (consulta: 01 de febrero de
2009)
(http://www.munimolina.gob.pe/m2_seguridadserena.htm)
Municipalidad del Callao (2008) Moderna móvil permite detectar placas clonadas y
vehículos robados (consulta: 27 de noviembre de 2008)
(http://www.municallao.gob.pe/Webcallao/html/servicios/transporte/noti_transport_00002.h
tml)
OASIS (2006) Reference Model for Service Oriented Architecture 1.0 (consulta: 13 de
marzo de 2009)
(http://docs.oasis-open.org/soa-rm/v1.0/soa-rm.pdf)
PERÚ. Ministerio de Transportes y Comunicaciones (2007) Reglamento de placa única
nacional de rodaje.
PERÚ. Ministerio de Transportes y Comunicaciones (2008) Resolución Ministerial 321-
2008 MTC/02: Modificación de las letras que identifican a los vehículos.
RENIEC (2009) Servicio de Consultas en Línea (consulta: 18 de julio de 2009)
(https://cel.reniec.gob.pe/cel/html/infor.html)
SAT (2009) Papeletas por Infracciones de Tránsito (consulta: 19 de julio de 2009)
(http://www.pit.gob.pe)
STERGIOU, Christos y SIGANOS, Dimitrios (1997) Neural Networks (consulta: 28 de
febrero de 2008)
(http://www.doc.ic.ac.uk/~nd/surprise_96/journal/vol4/cs11/report.html)
SUNARP (2009) Publicidad Registral en Línea (consulta: 18 de julio de 2009)
(http://www.sunarp.gob.pe/Pub_regsitral.asp)
CAPÍTULO 8. EMPAQUETADO Y PUESTA EN MARCHA DEL SISTEMA
x
WEST, David (2002) Planning a Project with Rational Unified Process (consulta: 11 de
junio de 2009)
(http://www.imsi-pm.com/home/library/Planning_an_IT_Project_with_RUP.pdf)
SOFTWARE DE RECONOCIMIENTO DE PATRONES VEHICULARES
xi
CAPÍTULO 8. EMPAQUETADO Y PUESTA EN MARCHA DEL SISTEMA
xii
ADJUNTOS
Los siguientes entregables se adjuntaron al Proyecto:
Plan de Iteración C1
Plan de Iteración C2
Plan de Iteración C3
Plan de Iteración T1
Estándar de Codificación
Guía de Instalación
Informe final de Verificación y Validación
Especificación de Caso de Uso Identificar Sospechoso
Así mismo, se anexa un CD que contiene la totalidad de artefactos generados durante el
desarrollo del proyecto. Módulo de Mantenimiento, Módulo de Monitoreo, Servicio
Implementador, Servicio de Reconocimiento de Sospechosos, Módulo de Servidor, una copia de
respaldo de la base de datos e instaladores.
SOFTWARE DE RECONOCIMIENTO DE PATRONES VEHICULARES
xiii
Sistema de Reconocimiento de Patrones Vehiculares
Plan de Iteración C1
CAPÍTULO 8. EMPAQUETADO Y PUESTA EN MARCHA DEL SISTEMA
xiv
Tabla de Contenidos
1. Introducción .............................................................................................................................. i
1.1 PROPÓSITO I
1.2 REFERENCIAS I
1.3 RESUMEN I
2. Plan .......................................................................................................................................... ii
3. Recursos .................................................................................................................................. ii
4. Casos de Uso .......................................................................................................................... iii
5. Criterios de Evaluación .......................................................................................................... iii
Deloitte Touche Tohmatsu Services, Inc.
Noviembre 2008
Plan de Iteración C1
1. Introducción
Como parte de la organización de las actividades del proyecto. Se han creado ciertos
documentos para que en ellos se plasmen las actividades a realizar. En el plan de
iteración se brinda información sobre una determinada iteración de una fase del
proyecto.
1.1 Propósito
El plan de iteración contiene información sobre las actividades, los tiempos, los
artefactos y los entregables correspondiente a una iteración determinada. Este
documento está destinado a describir la primera iteración (C1) perteneciente a la fase
de Construcción. Por ello, el presente plan sirve como guía para el equipo de proyecto
y a su vez para tomar decisiones con respecto al tiempo del proyecto.
1.2 Referencias
Las descripciones mas detalladas de las referencias realizadas en el documento pueden ser
encontradas en los siguientes artefactos:
Sistema de Reconocimiento de Patrones Vehiculares - SRS
Sistema de Reconocimiento de Patrones Vehiculares - Plan de Aceptación
del Producto
Sistema de Reconocimiento de Patrones Vehiculares - Plan de Desarrollo del
Software
1.3 Resumen
Este documento, en primer lugar nos brinda el plan completo y detallado para
la iteración C1. En segundo lugar, se verá en detalle sobre los recursos
humanos y materiales para esta etapa. En tercer lugar, se verá los casos de
uso a desarrollar en esta etapa. Y por último, se verá los criterios de evaluación
a los que serán sometidos todos los artefactos que se realicen en esta etapa.
CAPÍTULO 8. EMPAQUETADO Y PUESTA EN MARCHA DEL SISTEMA
ii
2. Plan
A continuación se muestra el plan detallado para esta fase de Construcción:
En este cuadro se describe los tiempo, artefactos y entregables que se deben alcanzar
para esta tercera fase.
Iteración: 1
Fase: Construcción
Inicio: Semana 1 del periodo 2008-1
Fin: Semana 7 del periodo 2008-1
Hito: Creación de línea de base 3.0
Casos de uso:
Lanzar alerta
Ver historial de alertas
Autenticar usuario
Registrar alerta
Entregables:
Documento de evaluación de Casos de uso
Linea de Base C1
PPTs de la presentación
Formulación de proyecto
3. Recursos
Según el planeamiento acordado, la fase de Construcción de divide en tres
iteraciones, cada una con igual cantidad de esfuerzo. De acuerdo a la
estimación hecha por el equipo de planeamiento, esta iteración demandará un
esfuerzo de 362 horas-hombre, y consumirá un tiempo de 21 días, teniendo en
cuenta que se tendrá a 3 programadores y hay sólo tres días laborables por
semana. El calendario del proyecto consta de 3 días útiles por semana: lunes,
miércoles y viernes, 4 horas el día.
SOFTWARE DE RECONOCIMIENTO DE PATRONES VEHICULARES
iii
4. Casos de Uso
En esta iteración se planea desarrollar cuatro casos de usos para poder probar que el
diseño planteado por el equipo de proyecto haya sido el correcto. Los casos de uso a
implementar son los siguientes y han sido elegidos de acuerdo a una priorización y
distribución semejante de esfuerzo.
Registrar alerta
Lanzar alerta
Ver historial de alertas
Autenticar usuario
5. Criterios de Evaluación
Los criterios de Evaluación son los siguientes:
Funcionalidad: Se evaluará que los casos de uso estén
completamente implementados y probados. El caso de uso no debe
presentar falles en su ejecución.
Calidad: Se evaluará que los casos de uso estén implementados
siguiendo las pautas establecidas en las guías de Diseño, GUI y
Codificación. Se verificará que la implementación de los casos de uso
estén acorde a las guías.
CAPÍTULO 8. EMPAQUETADO Y PUESTA EN MARCHA DEL SISTEMA
iv
Sistema de Reconocimiento de Patrones Vehiculares
Plan de Iteración C2
SOFTWARE DE RECONOCIMIENTO DE PATRONES VEHICULARES
v
Tabla de Contenidos
1. Introducción .............................................................................................................................. i
1.1 PROPÓSITO I
1.2 REFERENCIAS I
1.3 RESUMEN I
2. Plan .......................................................................................................................................... ii
3. Recursos .................................................................................................................................. ii
4. Casos de Uso .......................................................................................................................... iii
5. Criterios de Evaluación .......................................................................................................... iv
Deloitte Touche Tohmatsu Services, Inc.
Noviembre 2008
Plan de Iteración C2
6. Introducción
Como parte de la organización de las actividades del proyecto. Se han creado ciertos
documentos para que en ellos se plasmen las actividades a realizar. En el plan de
iteración se brinda información sobre una determinada iteración de una fase del
proyecto.
6.1 Propósito
El plan de iteración contiene información sobre las actividades, los tiempos, los
artefactos y los entregables correspondiente a una iteración determinada. Este
documento está destinado a describir la segunda iteración (C2) perteneciente a la fase
de Construcción. Por ello, el presente plan sirve como guía para el equipo de proyecto
y a su vez para tomar decisiones con respecto al tiempo del proyecto.
6.2 Referencias
Las descripciones mas detalladas de las referencias realizadas en el documento
pueden ser encontradas en los siguientes artefactos:
Sistema de Reconocimiento de Patrones Vehiculares - SRS
Sistema de Reconocimiento de Patrones Vehiculares - Plan de
Aceptación del Producto
Sistema de Reconocimiento de Patrones Vehiculares - Plan de
Desarrollo del Software
6.3 Resumen
Este documento, en primer lugar nos brinda el plan completo y detallado para la
iteración C2. En segundo lugar, se verá en detalle sobre los recursos humanos y
materiales para esta etapa. En tercer lugar, se verá los casos de uso a desarrollar en
esta etapa. Y por último, se verá los criterios de evaluación a los que serán sometidos
todos los artefactos que se realicen en esta etapa.
CAPÍTULO 8. EMPAQUETADO Y PUESTA EN MARCHA DEL SISTEMA
ii
7. Plan
A continuación se muestra el plan detallado para esta fase de Construcción 2:
En este cuadro se describe los tiempo, artefactos y entregables que se deben alcanzar
para esta segunda fase.
Iteración: 2
Fase: Construcción
Inicio: Semana 9
Fin: Semana 15
Hito: Creación de línea de base 04
Casos de uso:
Rastreas vehículos por criterios
Ver detalle de alerta
Ver log del sistema
Generar reportes
Mantener marcas
Mantener modelos
Mantener tipos de zonas
Mantener instituciones
Mantener tipos de zonas
Mantener operadores
8. Recursos
Según el planeamiento acordado, la fase de Construcción de divide en tres
iteraciones, cada una con igual cantidad de esfuerzo. De acuerdo a la estimación
hecha por el equipo de planeamiento, esta iteración demandará un esfuerzo de 419
horas-hombre, y consumirá un tiempo de 21 días, teniendo en cuenta que sólo son
tres días laborables por semana. El calendario del proyecto consta de 3 días útiles por
semana: lunes, miércoles y viernes, 4 horas el día. Se obliga el uso de un
programador de apoyo para las labores de implementación (un total de 48 horas).
SOFTWARE DE RECONOCIMIENTO DE PATRONES VEHICULARES
iii
9. Casos de Uso
En esta iteración se planea desarrollar cuatro casos de usos para poder probar que el
diseño planteado por el equipo de proyecto haya sido el correcto. Los casos de uso a
implementar son los siguientes y han sido elegidos de acuerdo a una priorización.
Rastreas vehículos por criterios
Ver detalle de alerta
Ver log del sistema
Generar reportes
Mantener marcas
Mantener modelos
Mantener tipos de zonas
Mantener instituciones
CAPÍTULO 8. EMPAQUETADO Y PUESTA EN MARCHA DEL SISTEMA
iv
Mantener tipos de zonas
Mantener operadores
10. Criterios de Evaluación
Los criterios de Evaluación son los siguientes:
Funcionalidad: Se evaluará que los casos de uso estén
completamente implementados y probados.
Calidad: Se evaluará que los casos de uso estén implementados
siguiendo las pautas establecidas en las guías de Diseño, GUI y
Codificación.
SOFTWARE DE RECONOCIMIENTO DE PATRONES VEHICULARES
v
Sistema de Reconocimiento de Patrones Vehiculares
Plan de Iteración C3
CAPÍTULO 8. EMPAQUETADO Y PUESTA EN MARCHA DEL SISTEMA
vi
Tabla de Contenidos
1. Introducción .............................................................................................................................. i
1.1 PROPÓSITO I
1.2 REFERENCIAS I
1.3 RESUMEN I
2. Plan .......................................................................................................................................... ii
3. Recursos .................................................................................................................................. ii
4. Casos de Uso .......................................................................................................................... iii
5. Criterios de Evaluación .......................................................................................................... iii
Deloitte Touche Tohmatsu Services, Inc.
Noviembre 2008
Plan de Iteración C3
11. Introducción
Como parte de la organización de las actividades del proyecto. Se han creado ciertos
documentos para que en ellos se plasmen las actividades a realizar. En el plan de
iteración se brinda información sobre una determinada iteración de una fase del
proyecto.
11.1 Propósito
El plan de iteración contiene información sobre las actividades, los tiempos, los
artefactos y los entregables correspondiente a una iteración determinada. Este
documento está destinado a describir la tercera iteración (C3) perteneciente a la fase
de Construcción. Por ello, el presente plan sirve como guía para el equipo de proyecto
y a su vez para tomar decisiones con respecto al tiempo del proyecto.
11.2 Referencias
Las descripciones mas detalladas de las referencias realizadas en el documento pueden ser
encontradas en los siguientes artefactos:
Sistema de Reconocimiento de Patrones Vehiculares - SRS
Sistema de Reconocimiento de Patrones Vehiculares - Plan de Aceptación
del Producto
Sistema de Reconocimiento de Patrones Vehiculares - Plan de Desarrollo del
Software
11.3 Resumen
Este documento, en primer lugar nos brinda el plan completo y detallado para
la iteración C3. En segundo lugar, se verá en detalle sobre los recursos
humanos y materiales para esta etapa. En tercer lugar, se verá los casos de
uso a desarrollar en esta etapa. Y por último, se verá los criterios de evaluación
a los que serán sometidos todos los artefactos que se realicen en esta etapa.
CAPÍTULO 8. EMPAQUETADO Y PUESTA EN MARCHA DEL SISTEMA
ii
12. Plan
A continuación se muestra el plan detallado para esta fase de Construcción:
En este cuadro se describe los tiempo, artefactos y entregables que se deben alcanzar
para la presente iteración.
Iteración: 3
Fase: Construcción
Inicio: Semana 1 del periodo 2008-2
Fin: Semana 7 del periodo 2008-2
Hito: Creación de línea de base 5.0
Casos de uso:
Obtener registros criminales
Obtener información de vehículos
Obtener información del propietario
Identificar sospechoso
Mantener Centros de Seguridad
Mantener Propietarios
Mantener Vehículos
Entregables:
Documento de evaluación de Casos de uso
Linea de Base C3 (5.0)
Memoria del Proyecto
13. Recursos
Según el planeamiento acordado, la fase de Construcción de divide en tres
iteraciones, cada una con igual cantidad de esfuerzo. De acuerdo a la
estimación hecha por el equipo de planeamiento, esta iteración demandará un
esfuerzo de 362 horas-hombre, y consumirá un tiempo de 21 días, teniendo en
cuenta que se tendrá a 3 programadores y hay sólo tres días laborables por
semana. El calendario del proyecto consta de 3 días útiles por semana: lunes,
miércoles y viernes, 4 horas el día.
SOFTWARE DE RECONOCIMIENTO DE PATRONES VEHICULARES
iii
CAPÍTULO 8. EMPAQUETADO Y PUESTA EN MARCHA DEL SISTEMA
iv
14. Casos de Uso
En esta iteración se planea desarrollar los casos de usos restantes para poder dar con
terminado el proceso de desarrollo del sistema. Los casos de uso a implementar son
los siguientes y han sido elegidos de acuerdo a una priorización y distribución
semejante de esfuerzo.
Obtener registros criminales
Obtener información de vehículos
Obtener información del propietario
Identificar sospechoso
Mantener Centros de Seguridad
Mantener Propietarios
Mantener Vehículos
15. Criterios de Evaluación
Los criterios de Evaluación son los siguientes:
Funcionalidad: Se evaluará que los casos de uso estén
completamente implementados y probados. El caso de uso no debe
presentar fallas en su ejecución.
Calidad: Se evaluará que los casos de uso estén implementados
siguiendo las pautas establecidas en las guías de Diseño y Codificación.
Se verificará que la implementación de los casos de uso estén acorde a
las guías.
Performance: Se tomará en cuenta el tiempo y los recursos que son
necesarios por el sistema para mantenerse en funcionamiento.
SOFTWARE DE RECONOCIMIENTO DE PATRONES VEHICULARES
v
Sistema de Reconocimiento de Patrones Vehiculares
Plan de Iteración T1
CAPÍTULO 8. EMPAQUETADO Y PUESTA EN MARCHA DEL SISTEMA
vi
Tabla de Contenidos
1. Introducción .............................................................................................................................. i 1.1 PROPÓSITO I 1.2 REFERENCIAS I 1.3 RESUMEN I 2. Plan .......................................................................................................................................... ii
3. Recursos .................................................................................................................................. ii
4. Actividades .............................................................................................................................. ii
5. Criterios de Evaluación .......................................................................................................... iii
Deloitte Touche Tohmatsu Services, Inc.
Noviembre 2008
Plan de Iteración T1
16. Introducción
Como parte de la organización de las actividades del proyecto. Se han creado ciertos
documentos para que en ellos se plasmen las actividades a realizar. En el plan de iteración
se brinda información sobre una determinada iteración de una fase del proyecto.
16.1 Propósito
El plan de iteración contiene información sobre las actividades, los tiempos, los artefactos y
los entregables correspondiente a una iteración determinada. Este documento está
destinado a describir la primera iteración perteneciente a la fase de Transición (T1). Por
ello, el presente plan sirve como guía para el equipo de proyecto y a su vez para tomar
decisiones con respecto al tiempo del proyecto.
16.2 Referencias
Las descripciones mas detalladas de las referencias realizadas en el documento pueden ser
encontradas en los siguientes artefactos:
Sistema de Reconocimiento de Patrones Vehiculares - SRS
Sistema de Reconocimiento de Patrones Vehiculares - Plan de Aceptación del
Producto
Sistema de Reconocimiento de Patrones Vehiculares - Plan de Desarrollo del
Software
16.3 Resumen
Este documento, en primer lugar nos brinda el plan completo y detallado para la
iteración T1. En segundo lugar, se verá en detalle sobre los recursos humanos y
materiales para esta etapa. Y por último, se verá los criterios de evaluación a los que
serán sometidos todos los artefactos que se realicen en esta etapa.
CAPÍTULO 8. EMPAQUETADO Y PUESTA EN MARCHA DEL SISTEMA
ii
17. Plan
A continuación se muestra el plan detallado para esta fase de Construcción:
En este cuadro se describe los tiempo, artefactos y entregables que se deben alcanzar para
la presente iteración.
Iteración: 1
Fase: Transición
Inicio: Semana 9 del periodo 2008-2
Fin: Semana 15 del periodo 2008-2
Hito: Creación de línea de base 6.0
Entregables:
Memoria del Proyecto
CD Empaquetado del Proyecto
CD de la Documentación Técnica del Proyecto
18. Recursos
Según el planeamiento acordado, la fase de Transición tiene una sola iteración. De
acuerdo a la estimación hecha por el equipo de planeamiento, esta iteración
demandará un esfuerzo de 194 horas-hombre, y consumirá un tiempo de 21 días,
teniendo en cuenta que se tendrá a 2 analistas y hay sólo tres días laborables por
semana. El calendario del proyecto consta de 3 días útiles por semana: lunes,
miércoles y viernes, 4 horas el día.
19. Actividades
En esta iteración no se implementará ningún caso de uso, se planea mejorar los
casos de usos desarrollados, además de pulir los documentos e instaladores de la
aplicación. En esta iteración se realizarán tareas de corrección e instalación del
sistema en un entorno preparado para el despliegue. A continuación planteamos las
actividades a realizar.
SOFTWARE DE RECONOCIMIENTO DE PATRONES VEHICULARES
iii
20. Criterios de Evaluación
Los criterios de Evaluación son los siguientes:
Funcionalidad: Se evaluará que los casos de uso estén completamente
implementados y probados. El caso de uso no debe presentar fallas en su
ejecución.
Performance: Se tomará en cuenta el tiempo y los recursos que son
necesarios por el sistema para mantenerse en funcionamiento.
Calidad: Los documentos deben estar de acuerdo a los lineamientos del
Comité de Proyectos. Además, la aplicación debe ser certificada por las
empresas .Net Factory y V&V.
CAPÍTULO 8. EMPAQUETADO Y PUESTA EN MARCHA DEL SISTEMA
iv
Sistema de Reconocimiento de Patrones Vehiculares
Estándares de Codificación
SOFTWARE DE RECONOCIMIENTO DE PATRONES VEHICULARES
v
Tabla de contenidos
1. Introducción .............................................................................................................................. i
1.1 PROPÓSITO I
1.2 ALCANCE I
1.3 DEFINICIONES, ACRÓNIMOS Y ABREVIACIONES I
1.4 REFERENCIAS I
1.5 DESCRIPCIÓN GENERAL III
2. Organización del Código y Estilo .......................................................................................... iii
3. Comentarios ............................................................................................................................ iii
4. Nombrado de tipos y variables............................................................................................... iv
5. Declaraciones .......................................................................................................................... vi
6. Expresiones y Estados ............................................................................................................ vi
7. Manejo de Errores y Excepciones ........................................................................................ vii
Deloitte Touche Tohmatsu Services, Inc.
Setiembre 2009
Estándares de Codificación
21. Introducción
En la actualidad existen muchas normas que son la base para establecer estándares y buenas practicas en el desarrollo de software, los niveles de calidad por lo general están regulados por el CMMI e ISO entre otros. A pesar de que estas normas existen, es muy frecuente que los desarrolladores no se apeguen a tales reglas, algunas veces por desconocimiento parcial o total de ellas, costumbres en su estilo de programación o malas practicas. Es por esto que es necesario que toda empresa, organización o equipo de proyecto defina que estándar usara o se apegue a un estándar propio, que sea asimilado por cada uno de los miembros del equipo presentes y los que se incorporen en el futuro.
21.1 Propósito
El objetivo principal para llevar a cabo revisiones del código durante el desarrollo del código, es encontrar los defectos presentes en el mismo. También ayudan a reconocer si se están cumpliendo los estándares preestablecidos. Para efecto del mismo es necesario mantener el mismo estándar a lo largo de todo el proyecto para evitar que las revisiones sean ineficientes.
21.2 Alcance
Este documento abarca estándares con respecto al nombrado de las clases, interfaces, proyectos, librerías, componentes y demás elementos que constituyen el código fuente del sistema. También abarca recomendaciones y pautas que el desarrollador debe seguir para conseguir una codificación con cierto nivel de calidad, incluyendo manejo de errores, patrones de diseño, reconocimiento de secciones reusables, etc.
21.3 Definiciones, Acrónimos y Abreviaciones
Las definiciones se encuentran en el Glosario del Proyecto.
21.4 Referencias
Los documentos que se han tomado como base para la elaboración del presente documento son:
Glosario
CAPÍTULO 8. EMPAQUETADO Y PUESTA EN MARCHA DEL SISTEMA
ii
Guía de diseño
SOFTWARE DE RECONOCIMIENTO DE PATRONES VEHICULARES
iii
21.5 Descripción General
En el siguiente documento no se pretende definir un estándar inflexible, sino más bien establecer las bases para buenas practicas en la codificación de las aplicaciones.
Aunque las estándares de codificación no influyen en la funcionalidad de la aplicación si ayudan a una mejor comprensión del mismo. Es necesario tomar en cuenta los diferentes tipos de lenguajes de programación para establecer un buen estándar de comunicación.
22. Organización del Código y Estilo
La legibilidad del código fuente repercute directamente en lo bien que un programador comprende un sistema de software. La mantenibilidad del código es la facilidad con que el sistema de software puede modificarse para añadirle nuevas características, modificar las ya existentes, depurar errores, o mejorar el rendimiento. Aunque la legibilidad y la mantenibilidad son el resultado de muchos factores, una faceta del desarrollo de software en la que todos los programadores influyen especialmente es en la técnica de codificación. El mejor método para asegurarse de que un equipo de programadores mantenga un código de calidad es establecer un estándar de codificación sobre el que se efectuarán luego revisiones del código de rutinas.
23. Comentarios
Con respecto a los comentarios, estos deberán regirse por las siguientes indicaciones:
Al principio de cada método, haga una pequeña explicación de lo que se va a hacer ahí. Esto ayuda en gran manera a comprender el código. También indique si dentro de esta se están usando características especiales del framework que este utilizando, este puede ser el caso si se esta usando Hashtables, Caches, Sessions, etc.
Evite añadir comentarios al final de una línea de código, porque lo hacen más difícil de leer.
Evite los comentarios recargados, como las líneas enteras de asteriscos. En su lugar, utilice espacios para separar los comentarios y el código.
Antes de la implementación, quite todos los comentarios temporales o innecesarios, para evitar cualquier confusión en la futura fase de mantenimiento.
Use frases completas cuando escriba comentarios. Los comentarios deben aclarar el código, no añadirle ambigüedad.
Vaya comentando al mismo tiempo que programa, porque probablemente no tenga tiempo de hacerlo más tarde. Por otro lado, aunque tuviera oportunidad de revisar el código que ha escrito, lo
CAPÍTULO 8. EMPAQUETADO Y PUESTA EN MARCHA DEL SISTEMA
iv
que parece obvio hoy es posible que seis semanas después no lo sea.
Para la documentación de los métodos de las clases se usarán los estándares de Microsoft sobre la documentación basada en xml, que permite la generación automática de la documentación.
Use los comentarios para explicar el propósito del código. No los use como si fueran traducciones literales.
Haga comentarios en el código que esté formado por bucles o bifurcaciones lógicas. Se trata en estos casos de áreas clave que ayudarán a los lectores del código fuente.
Realice los comentarios en un estilo uniforme, respetando una puntuación y estructura coherentes a lo largo de toda la aplicación.
Cada declaración de variable importante debe incluir un comentario en la misma línea que describa el uso de la variable que se declara, a menos que sea obvia.
Después de la secuencia de continuación de línea no puede escribirse un comentario en la misma línea.
24. Nombrado de tipos y variables
El esquema de nombres es una de las ayudas más importantes para entender el flujo lógico de una aplicación. A través de los diferentes proyectos realizados durante la carrera, se han identificado ciertos errores recurrentes con respecto a este tema. A continuación se describirán algunos de ellos. En la mayoría de casos, el nombrado de los métodos expresa el "cómo" en lugar del "qué" sobre la funcionalidad que cumple. Un ejemplo de ello es nombrar a un procedimiento que hace una consulta a una base de datos es llamado “RealizarConsultaSelectClientes” en lugar de un nombrado genérico como “ObtenerClientes”. Si se utiliza un nombre que evite referirse a la implementación, se estará conservando la abstracción de la estructura ya que la implementación, está sujeta a cambios y así se evitará hacer un Refactoring al procedimiento. Cuando se de el caso que se tenga que nombrar a un método con más de una palabra, se deberá escribir la primera letra de cada palabra con Mayúsculas, para así comprender mejor su función. Un ejemplo de ellos nombrar un método con “ActualizarTasaDeCambio” en lugar de “Actualizartasadecambio”. Si se da el caso, prefiera hacer uso de la característica “Overload” del método para así evitar tener nombres diferentes para un mismo método que necesite diferentes parámetros para poder cumplir su función. Con respecto al nombrado de las variables, se seguirá el estándar propuesto por Microsoft.
SOFTWARE DE RECONOCIMIENTO DE PATRONES VEHICULARES
v
A continuación, un ejemplo que englobe todo lo mencionado anteriormente. //SaveXlsToDb tiene la función de persistir la información dada como parámetro a través de un //DataTable hacia una base de datos Excel. public void SaveXlsToDb(DataTable dt) { //AppConfiguration es una clase que contiene métodos estáticos que facilitan la obtención //de la cadena de conexión para acceder a la base de datos Excel., también tiene //información sobre el comando sql para realizar la acción. SqlConnection cn = new SqlConnection(AppConfiguration.getStringDbConnection()); try { SqlCommand cmd = new SqlCommand(AppConfiguration.getInsertCommandName(), cn); cmd.CommandType = CommandType.StoredProcedure; foreach (DataColumn col in dt.Columns) { SqlParameter parameter = new SqlParameter(); parameter.ParameterName = "@" + col.ColumnName; parameter.SourceColumn = col.ColumnName; cmd.Parameters.Add(parameter); } SqlDataAdapter dap = new SqlDataAdapter(); dap.InsertCommand = cmd; cn.Open(); dap.Update(dt); } catch (Exception) { throw; } finally { cn.Close(); cn.Dispose(); } } Desde el punto de vista de la programación, un nombre único sirve solamente para diferenciar un elemento de otro. Los nombres expresivos funcionan como ayuda para el lector, por eso, es lógico dar nombres que sean fáciles de comprender. No obstante, asegúrese de que los nombres escogidos sean compatibles con las reglas de cada lenguaje y con los estándares.
CAPÍTULO 8. EMPAQUETADO Y PUESTA EN MARCHA DEL SISTEMA
vi
25. Declaraciones
Con respecto a la declaración de clases, interfaces y demás elementos, se dan las siguientes recomendaciones. Con respecto a los elementos de la declaración de una clase, se debe definir en orden descendente lo siguiente: Atributos, Constructores, Enumeraciones, Clases anidadas, Propiedades y por ultimo los Métodos. Con respecto a la visibilidad de los diferentes elementos de la clase , se seguirá el siguiente orden:
public
protected
internal
private
Con respecto a las interfaces que se declaren, se seguirá el siguiente orden de los elementos.
Métodos
Propiedades (Get y/o Set) Con respecto a las enumeraciones que se declaren, los elementos de dicha estructura deberán estar en orden alfabético y con la primera letra en mayuscula. Ejemplo:
public enum ProviderType { ComPlusProvider, DataAccessProvider, RemotingProvider, WebServiceProvider }
26. Expresiones y Estados
Si se están almacenando variables dentro un tipo Collection como las clases HashTable, Cache o Session, por ejemplo, se deberá hacer un registro en un archivo de texto sobre las variables que se guardan en ellos, su nombre, tipo e identificación dentro de la colección. Ejemplo: string nombre = “Miguel Martinez”; bool isAdmin = true; HashTable ht = new HashTable(); ht[“Nombre”] = nombre;
SOFTWARE DE RECONOCIMIENTO DE PATRONES VEHICULARES
vii
ht[“IsAdmin”] = isAdmin; El archivo de texto deberá tener lo siguiente: Colección Identificador Variable Tipo de la variable ht Nombre nombre string ht IsAdmin isAdmin bool … … … … Es recomendado que las variables de tipo boolean o bool, de acuerdo al lenguaje a usar, contengan una palabra que describa su estado: puedeEliminarse, esGrande, tieneHijos, etc. Y siempre se debe referir al estado verdadero: tieneCredito en cambio de noTieneCredito.
27. Manejo de Errores y Excepciones
Los errores que ocurran durante el normal funcionamiento de la aplicación, se deberá crear un clases que herede de la clase ApplicationException y debe asignarle un mensaje de error apropiado, luego deberán ser dados a conocer al usuario a través del método estático MessageBox.Show(). Las excepciones se deben capturarsiempre en el nivel mas alto del sistema, es decir en la capa de más abstracción, por lo general es la capa de interfaz de usuario. Es una directiva general evitar en todo caso crear excepciones personalizadas, pero en el caso de que sea necesario siga estas premisas:
Se deben manejaren clases aparte y se debe heredar de la clase ApplicationException.
Implemente el patrón de diseño de las excepciones, sobrescribiendo estos 2 métodos :
- public MiExcepcion()
- public MiExcepcion(string message)
Nunca declare una sentencia catch vacía. Evite anidar bloques try/catch. Ordene la captura de excepciones (catch) siempre en orden descendente desde la más particular hasta la más genérica. Evite relanzar una excepción, permita mejor que vaya ascendiendo y que sea capturada en la capa superior. Si relanza una excepción omita la referencia: try { .... } catch (Exception)
CAPÍTULO 8. EMPAQUETADO Y PUESTA EN MARCHA DEL SISTEMA
viii
{ throw;
} Match (SqlException) { throw; } Use los bloque finally solo para realizar funciones de limpieza y liberación de recursos. Siempre que sea posible prefiera la validación al manejo de excepciones: try {
connection.Close(); } catch (Exception a) {
//... Manejo de excepción }
Cámbielo por: if (connection.State() != connection.State.Closed ) {
connection.Close(); }
SOFTWARE DE RECONOCIMIENTO DE PATRONES VEHICULARES
ix
Sistema de Reconocimiento de Patrones Vehiculares
Guía de Instalación
CAPÍTULO 8. EMPAQUETADO Y PUESTA EN MARCHA DEL SISTEMA
x
Tabla de Contenidos 1. Introducción .............................................................................................................................. i 1.1. PROPÓSITO I
1.2. ALCANCE I
2. Instalación ................................................................................................................................. i 2.1. PRERREQUISITOS I
2.2. INSTALACIÓN DE LA BASE DE DATOS I
2.2.1. INICIO I
2.2.2. CONFIGURACIÓN DE LA INSTALACIÓN II
2.2.3. SELECCIÓN DE LA COPIA DE SEGURIDAD DE LA BASE DE DATOS III
2.2.4. FINALIZACIÓN DE LA INSTALACIÓN DE LA BASE DE DATOS IV
2.3. CONFIGURACIÓN DE LA BASE DE DATOS IV
2.3.1. CREACIÓN DE USUARIOS IV
2.4. INSTALACIÓN DEL SERVICIO SERVIDOR VI
2.4.1. INSTALACIÓN VI
2.4.2. CONFIGURACIÓN DEL PROVEEDOR VIII
2.4.3. CONFIGURACIÓN DEL ARCHIVO WEB.CONFIG VIII
2.4.4. CONFIGURACIÓN DEL ARCHIVO DE CONEXIÓN IX
2.4.5. USO DE LA HERRAMIENTA DE ENCRIPTACIÓN DE CADENA DE CONEXIÓN IX
2.4.6. CONFIGURACIÓN DEL IIS (SERVICIOS DE INTERNET INFORMATION SERVER) XII
2.4.7. CONFIGURACIÓN DE LAS PROPIEDADES DEL PROVEEDOR XIV
2.4.8. CONFIGURACIÓN DE LA RED NEURONAL XIV
2.5. INSTALACIÓN DEL SERVICIO DUMMY XVII
2.5.1. RESTAURACIÓN DE LA BASE DE DATOS SRPV_DUMMY XVII
2.5.2. CONFIGURACIÓN DEL WEB SERVICE WSDUMMY XX
2.5.3. CONFIGURACIÓN DEL IIS XXIII
2.6. INSTALACIÓN DEL SERVICIO IMPLEMENTADOR XXVII
2.6.1. INSTALACIÓN XXVII
2.6.2. CONFIGURACIÓN DE SERVICIOS XXIX
2.7. INSTALACIÓN DEL SERVICIO DE RECONOCIMIENTO DE PATRONES. XXX
2.7.1. INSTALACIÓN XXX
2.7.2. CONFIGURACIÓN DEL SERVICIO XXXIII
2.8. INSTALACIÓN DEL MODULO DE MONITOREO. XXXIII
2.8.1. INSTALACIÓN XXXIII
2.9. INSTALACIÓN DEL MODULO DE MANTENIMIENTO XXXVI
2.9.1. INSTALACIÓN. XXXVI
Deloitte Touche Tohmatsu Services, Inc.
Noviembre 2008
Guía de Instalación
1. Introducción
1.1. Propósito
El presente documento tiene la finalidad de orientar al usuario indicando los pasos
necesarios al instalar cada uno de los módulos del Sistema de Reconocimiento de
Patrones Vehiculares.
1.2. Alcance
En esta guía completa se incluye el proceso de instalación del sistema y las principales
funcionalidades.
2. Instalación
2.1. Prerrequisitos
Si no cuenta con los requisitos necesarios para desplegar el sistema, los instaladores del
sistema le advertirán que debe instalarlos antes de proseguir con la instalación actual del
Sistema de Reconocimiento de Patrones Vehiculares. Para instalar adecuadamente el
software se necesitan:
.NET Framework 2.0
IIS V5.1 o superior
SQL Server 2005
2.2. Instalación de la base de datos
2.2.1. Inicio
Al ejecutar el programa “SRPV - SQLServerDBRestore.exe” que se encuentra
ubicado en la carpeta Disco:\Otros\SQLServerDBRestore, se mostrará el instalador
de la base de datos:
CAPÍTULO 8. EMPAQUETADO Y PUESTA EN MARCHA DEL SISTEMA
ii
2.2.2. Configuración de la instalación
Deberá ingresar los datos del servidor donde se va a instalar la base de datos, el
nombre de la base de datos (db_PatronesVehiculares) y llenar los datos que se le
solicitan.
Si selecciona la opción “Integrated Security”, la conexión al servidor se hará por
Active Directory, de lo contrario deberá ingresar el usuario y clave de un usuario
con derechos suficientes para crear y restaurar una base de datos.
Si selecciona la opción “Crear base de datos”, el sistema creará una base de datos
con el nombre indicado en el campo “Nombre de la base de datos”, se recomienda
poner db_PatronesVehiculares. De lo contrario usará una base de datos ya creada.
En los campos Ruta del archivo db_PatronesVehiculares_primary,
db_PatronesVehiculares_historico y db_PatronesVehiculares_log se deben colocar
las carpetas en las que se ubicarán cada uno de estos 3 archivos vitales para el
funcionamiento de la base de datos.
SOFTWARE DE RECONOCIMIENTO DE PATRONES VEHICULARES
iii
2.2.3. Selección de la copia de seguridad de la base de datos
El campo “Archivo de backup” debe contener la ruta exacta del archivo .bak que se
va a restaurar. En el CD se encuentra en la ruta Disco:\ Base de datos\
db_PatronesVehiculares.bak
CAPÍTULO 8. EMPAQUETADO Y PUESTA EN MARCHA DEL SISTEMA
iv
2.2.4. Finalización de la instalación de la base de datos
Una vez que se han completado todos los datos, debe hacer clic en el botón ejecutar.
Una vez finalizada la instalación se mostrara el mensaje indicando que la instalación
ha sido finalizada con éxito.
2.3. Configuración de la base de datos
2.3.1. Creación de usuarios
Para cada usuario que desee agregar, debe seguir los siguientes pasos: Abra la
interfaz de Microsoft SQL Server Management Studio, elija el servidor de base de
datos a usar, haga clic derecho en la carpeta SecurityLogins y seleccione la
opción New Login.
SOFTWARE DE RECONOCIMIENTO DE PATRONES VEHICULARES
v
Seleccione una cuenta del dominio, como se ve en el ejemplo, seleccione la opción
Windows authentication y seleccione db_PatronesVehiculares como la base de
datos por defecto.
CAPÍTULO 8. EMPAQUETADO Y PUESTA EN MARCHA DEL SISTEMA
vi
Seleccione la opción User Mapping y debe verificar que las opciones que se
muestran a continuación estén seleccionadas.
Haga clic en OK para que se guarden los cambios.
2.4. Instalación del Servicio Servidor
2.4.1. Instalación
De clic en siguiente para comenzar la instalación.
SOFTWARE DE RECONOCIMIENTO DE PATRONES VEHICULARES
vii
En la opción Site debe seleccionar el sitio Web en el que se va a alojar el directorio
virtual del Web Service. En la opción Virtual directory debe colocar el nombre del
directorio virtual en el que se va a instalar el Web Service.
Haga clic en siguiente para iniciar la instalación.
Una vez finalizada la instalación se mostrara el mensaje de instalación satisfactoria.
CAPÍTULO 8. EMPAQUETADO Y PUESTA EN MARCHA DEL SISTEMA
viii
Haga clic en el botón Close.
2.4.2. Configuración del Proveedor
Busque la carpeta donde se ha instalado el proveedor. Siga la ruta descrita en la
imagen.
2.4.3. Configuración del archivo Web.config
Abra el archivo Web.config en el Block de Notas y verifique que la instalación
tenga los mismos parámetros al descrito en la imagen siguiente. Puede sustituir el
parámetro RegistrarLog por True si desea que se guarde un registro de cada una de
las acciones realizadas sobre la base de datos. Puede cambiar el valor del parámetro
FechaMasAntigua por una fecha en el formato dd/mm/yyyy para asignar una fecha
como límite inferior para las operaciones como la obtención de eventos.
SOFTWARE DE RECONOCIMIENTO DE PATRONES VEHICULARES
ix
2.4.4. Configuración del archivo de conexión
Abra el archivo conexion.txt. Ahí se muestra una cadena de conexión de ejemplo,
encriptada.
2.4.5. Uso de la herramienta de encriptación de cadena de conexión
Ejecute la aplicación Encriptador (Otros EncriptadorEncriptador.exe)
CAPÍTULO 8. EMPAQUETADO Y PUESTA EN MARCHA DEL SISTEMA
x
Seleccione la cadena encriptada del bloc de notas, cópiela y péguela en el cuadro de
texto de Cadena encriptada.
Haga clic en el botón Desencriptar. Esto mostrará la cadena de conexión
desencriptada en el cuadro de texto superior.
Sustituya el Data Source en donde aparezca con el servidor donde instaló la base de
datos.
SOFTWARE DE RECONOCIMIENTO DE PATRONES VEHICULARES
xi
Después de realizar el cambio haga clic en Encriptar y la cadena de conexión
encriptada se generará en el cuadro de texto inferior, reemplazando el valor que
había anteriormente.
Copie la cadena encriptada y reemplace la cadena que se encuentra en el
conexión.txt con la nueva cadena de conexión.
CAPÍTULO 8. EMPAQUETADO Y PUESTA EN MARCHA DEL SISTEMA
xii
Grabe los cambios realizados en el archivo.
2.4.6. Configuración del IIS (Servicios de Internet Information Server)
Abra la consola de administración del IIS, elija el directorio virtual en el que instaló
el Web Service (Proveedor) tal como de muestra en la imagen, dé clic derecho y
elija la opción de propiedades.
Se va a mostrar una interfaz como la siguiente:
Verifique que las opciones estén configuradas tal como se muestra en la imagen
siguiente en la pestaña Directorio Virtual.
Elija la pestaña Documentos u debe aparecer tal como se muestra a continuación.
SOFTWARE DE RECONOCIMIENTO DE PATRONES VEHICULARES
xiii
Elija la pestaña Seguridad de directorios y dé clic en modificar.
Elija la opción Autenticación de Windows integrada y de clic en Aceptar.
CAPÍTULO 8. EMPAQUETADO Y PUESTA EN MARCHA DEL SISTEMA
xiv
Elija la pestaña ASP.NET y verifique que la versión de ASP.NET sea la 2.0.50727 y
luego dé clic en Aceptar.
2.4.7. Configuración de las propiedades del proveedor
En la siguiente ruta de Inetpub\wwwroot ubique la carpeta Proveedor, dé clic
derecho sobre la misma y elija la opción Propiedades.
2.4.8. Configuración de la red neuronal
La red neuronal que usará el Servicio de Reconocimiento de Patrones necesita una
serie de parámetros que le ayudarán a tomar las decisiones acerca de los vehículos.
Para esto, se debe ir a la tabla Sistema.EntrenamientoDeRed e insertar una serie de
registros que ayudarán a configurar la red. En la tabla aparecen los siguientes
campos:
SOFTWARE DE RECONOCIMIENTO DE PATRONES VEHICULARES
xv
entrenamientodered_id: Este es un campo autogenerado. El sistema le asignará un
valor al guardar el registro
placa_valida: Si este valor es “True”, indica que la placa del vehículo tiene
codificación errada. Si es “False”, significa que la codificación de la placa es
correcta.
paso_por_el_mismo_punto: Si este valor es “True”, indica que el vehículo ha sido
visto por el mismo punto en un plazo de tiempo determinado por el parámetro
PorElMismoPunto_TiempoEnMinutos del Servicio de Reconocimiento de Patrones
una cantidad de veces mínima definida por el parámetro PorElMismoPunto_Veces.
paso_cerca_de_un_punto: Si este valor es “True”, indica que el vehículo ha sido
visto cerca a un punto (es decir, a una cantidad de kilómetros a la redonda definida
por el parámetro PorLaMismaZona_KmALaRedonda) en un intervalo de minutos
definido por los parámetros PorLaMismaZona_MinimaDiferenciaEnMinutos y
PorLaMismaZona_MaximaDiferenciaEnMinutos, una cantidad de veces mayor o
igual al parámetro PorLaMismaZona_MinimaCantidadDeVeces.
hay_informacion_de_polarizado: Es True si se ha obtenido información sobre el
polarizado de las lunas, de lo contrario es False.
lunas_polarizadas: Si el campo hay_informacion_de_polarizado es False, este valor
no se tomará en cuenta, de lo contrario, True indica que el vehículo cuenta con lunas
polarizadas y False, que no.
hay_informacion_del_modelo: Si el valor es True, indica que se ha podido obtener
el modelo del vehículo que está siendo evaluado.
modelo_frecuentemente_usado: Si el valor anterior es False, este valor no se tomará
en cuenta, de lo contrario, True significa que el modelo del vehículo es un modelo
frecuentemente usado en actos criminales.
hay_informacion_del_propietario: Si el valor es True, indica que se ha podido
obtener información acerca del propietario del vehículo.
propietario_con_antecedentes: Si el campo anterior tiene como valor False, este
valor no se tomará en cuenta, de lo contrario, True indica que el propietario del
vehículo cuenta con antecedentes policiales.
sospechoso: Este campo indica el resultado del análisis toda la combinación de
datos anteriores. Es decir, si el juego de valores es un ejemplo de un vehículo
sospechoso, este valor será True, de lo contrario, será False.
Además en la carpeta en la que se instaló el Servicio de Reconocimiento de Patrones
debe existir un archivo con extensión .config. Este archivo contiene una serie de
parámetros como PorElMismoPunto_Veces, PorElMismoPunto_TiempoEnMinutos,
PorLaMismaZona_ MinimaDiferenciaEnMinutos,
PorLaMismaZona_MaximaDiferenciaEn-Minutos,
PorLaMismaZona_KmALaRedonda y PorLaMismaZona_
MinimaCantidadDeVeces cuyo uso fue explicado en las líneas anteriores. Además,
CAPÍTULO 8. EMPAQUETADO Y PUESTA EN MARCHA DEL SISTEMA
xvi
este archivo cuenta con un parámetro adicional, NivelDeConfianza. Este parámetro
indica el nivel de confianza que se tendrá sobre el resultado del análisis de la red
neuronal, vale decir, si la red neuronal indica que un vehículo es sospechoso con
una confianza del 80% y el valor del parámetro NivelDeConfianza es 95%, este
vehículo no será considerado como sospechoso.
OJO: Debe tener mucho cuidado al manipular los parámetros del archivo .config ya
que puede inutilizar el servicio.
En el proveedor elija la opción de Seguridad y dé clic en Agregar.
Ingrese el nombre ASPNET, haga clic en el botón Comprobar nombres y luego
seleccione Aceptar.
SOFTWARE DE RECONOCIMIENTO DE PATRONES VEHICULARES
xvii
Seleccione el usuario ASPNET y otórguele los mismos permisos tal y como se
muestran a continuación.
2.5. Instalación del Servicio Dummy
2.5.1. Restauración de la base de datos srpv_dummy
Dé clic derecho sobre la carpeta Databases y elija la opción restaurar base de datos.
CAPÍTULO 8. EMPAQUETADO Y PUESTA EN MARCHA DEL SISTEMA
xviii
Se mostrara la siguiente ventana. Elija la opción From device (Desde un dispositivo)
y haga clic en el botón
Seleccione Add, ubique el archivo srpv_dummy.bak (OtrosServicio
DummyBase de datossrpv_dummy.bak) y haga clic en el botón OK.
SOFTWARE DE RECONOCIMIENTO DE PATRONES VEHICULARES
xix
Seleccione el backup a restaurar y elija el nombre de la base de datos srpv_dummy
en la opción To database.
Elija la página Options. Seleccione la opción Overwrite the existing database,
verifique que las rutas sean correctas y luego dé clic en OK.
CAPÍTULO 8. EMPAQUETADO Y PUESTA EN MARCHA DEL SISTEMA
xx
Luego de seguir los pasos descritos, debe aparecer un mensaje de éxito en la
restauración de la base de datos.
2.5.2. Configuración del Web Service WSDummy
Copie la carpeta WSdummy de que se encuentra en OtrosServicio
DummyWSdummy
SOFTWARE DE RECONOCIMIENTO DE PATRONES VEHICULARES
xxi
Péguela en la ruta C:\Inetpub\wwwroot (asegúrese de que el usuario ASPNET tiene
derechos de lectura y escritura sobre esta carpeta, tal como se hizo para la carpeta
Proveedor)
Entre a la carpeta WsDummy
CAPÍTULO 8. EMPAQUETADO Y PUESTA EN MARCHA DEL SISTEMA
xxii
Abra el archivo de configuración dando clic derecho y elija abrir con bloc de notas.
En el archivo de configuración Web.config cambie los valores de usuario y
password de la cadena de conexión para que funcione correctamente.
Guarde los cambios realizados.
SOFTWARE DE RECONOCIMIENTO DE PATRONES VEHICULARES
xxiii
2.5.3. Configuración del IIS
En la consola de administración del IIS, haga clic derecho en el sitio Web donde se
vaya a alojar el WSDummy, seleccione NuevoDirectorio virtual…
Se mostrara el asistente para la creación del directorio virtual.
Ingrese el siguiente nombre del servicio (WSDummy)
CAPÍTULO 8. EMPAQUETADO Y PUESTA EN MARCHA DEL SISTEMA
xxiv
Elija el siguiente directorio y dé clic en siguiente
Habilite las siguientes opciones.
SOFTWARE DE RECONOCIMIENTO DE PATRONES VEHICULARES
xxv
Finalizado el proceso se mostrara el siguiente mensaje.
2.5.4. Configuración de las propiedades de WSDummy
Dé clic derecho sobre el directorio virtual WSDummy y elija propiedades. Debe
seleccionar las siguientes opciones.
CAPÍTULO 8. EMPAQUETADO Y PUESTA EN MARCHA DEL SISTEMA
xxvi
En Seguridad de directorios, haga clic en el botón Modificar (en el grupo Control de
autenticación y acceso anónimo). A continuación, haga las configuraciones como se
muestra en la siguiente imagen:
En la pestaña ASP.NET verifique que la versión sea 2.0.5027.
SOFTWARE DE RECONOCIMIENTO DE PATRONES VEHICULARES
xxvii
2.6. Instalación del Servicio Implementador
2.6.1. Instalación
Ejecute el asistente de instalación (en la carpeta Servicio Implementador) y haga
clic en Siguiente
Seleccione la ubicación donde va a ser instalada la aplicación y dé clic en siguiente.
CAPÍTULO 8. EMPAQUETADO Y PUESTA EN MARCHA DEL SISTEMA
xxviii
Haga clic en siguiente.
El sistema va a mostrar la barra de progreso de la instalación
SOFTWARE DE RECONOCIMIENTO DE PATRONES VEHICULARES
xxix
Una vez completada la instalación se mostrara la siguiente ventana
2.6.2. Configuración de servicios
Vaya a InicioEjecutar, escriba “services.msc” y haga clic en Aceptar. Elija el
ServicioImplementador, dé clic derecho sobre el mismo y elija la opción Iniciar.
CAPÍTULO 8. EMPAQUETADO Y PUESTA EN MARCHA DEL SISTEMA
xxx
Si se desea cambiar la frecuencia con la que se ejecuta la verificación de
información más reciente, se puede modificar el archivo
UPC.SRPV.Servicios.Implementador.exe.config, que se encuentra en la carpeta de
instalación, como se muestra a continuación:
2.7. Instalación del Servicio de Reconocimiento de Patrones.
2.7.1. Instalación
Ejecute el instalador del Servicio de Reconocimiento de Patrones (en la carpeta
Servicio de Reconocimiento de Patrones)
SOFTWARE DE RECONOCIMIENTO DE PATRONES VEHICULARES
xxxi
Elija la ruta donde va a ser instalada la aplicación y haga clic en el botón Siguiente.
Inicie el proceso de instalación, haciendo clic en el botón Siguiente.
CAPÍTULO 8. EMPAQUETADO Y PUESTA EN MARCHA DEL SISTEMA
xxxii
Se mostrará el progreso de la instalación
Por último, se muestra una pantalla indicando que la instalación ha sido completada.
Haga clic en el botón Cerrar.
SOFTWARE DE RECONOCIMIENTO DE PATRONES VEHICULARES
xxxiii
2.7.2. Configuración del servicio
Inicie el Servicio de Reconocimiento de Patrones
(ServicioIdentificadorDeSospechosos) en la interfaz de servicios, tal como se hizo
con el ServicioImplementador.
2.8. Instalación del Modulo de Monitoreo.
2.8.1. Instalación
Elija el asistente de instalación (en la carpeta Monitoreo)
CAPÍTULO 8. EMPAQUETADO Y PUESTA EN MARCHA DEL SISTEMA
xxxiv
Seleccione la carpeta de instalación y dé clic en siguiente
Confirme la instalación dando clic en Siguiente.
SOFTWARE DE RECONOCIMIENTO DE PATRONES VEHICULARES
xxxv
Se mostrará la barra de progreso de la instalación
Si la instalación ha finalizado con éxito se mostrara el mensaje de Éxito
CAPÍTULO 8. EMPAQUETADO Y PUESTA EN MARCHA DEL SISTEMA
xxxvi
2.9. Instalación del Modulo de Mantenimiento
2.9.1. Instalación.
Elija el asistente de instalación del Módulo de Mantenimiento (en la carpeta
Mantenimiento)
Seleccione la ruta de instalación y haga clic en el botón Siguiente
SOFTWARE DE RECONOCIMIENTO DE PATRONES VEHICULARES
xxxvii
Confirme la instalación y dé clic en Siguiente
Se mostrará la barra de progreso de la instalación
CAPÍTULO 8. EMPAQUETADO Y PUESTA EN MARCHA DEL SISTEMA
xxxviii
Se visualizará el mensaje de instalación completa. Haga clic en el botón Cerrar.
En este punto a finalizado la instalación de los módulos, los cuales están listos para
ser usados. Para conocer el uso del Sistema de Reconocimiento de Patrones
Vehiculares, es recomendable que lea el Manual de Usuario del sistema que se
encuentra anexada al mismo.
SOFTWARE DE RECONOCIMIENTO DE PATRONES VEHICULARES
xxxix
Informe de Verificación y Validación
Informe en el que se certifica el pase de algún proyecto por la empresa Verificación y Validación.
CAPÍTULO 8. EMPAQUETADO Y PUESTA EN MARCHA DEL SISTEMA
xl
La Empresa Verificación y Validación mediante este documento certifica que el proyecto de nombre Sistema de Reconocimiento de Patrones Vehicular SRPVque tiene como responsable al Sr. Edson Villar ha culminado con la evaluación brindada por la empresa. El proyecto SRPV ha pasado por las siguientes evaluaciones:
1. Pruebas de Aceptacion de Usuario.
Este proyecto ha sido evaluado por el equipo de Piero Ramos. Cuyas conclusiones finales fueron las siguientes:
1. Para la validación de este proyecto el equipo de trabajo no presento ninguna dificultad en la
documentacion debido a que ya se habian realizado pruebas de verificacion en los documentos
de casos de uso.
2. El proyecto cumple con la documentación necesaria y con los requisitos previamente
establecidos por la empresa durante el proceso de validación.
3. Las observaciones encontradas de mayor criticidad fueron corregidas por el responsable del
proyecto.
4. El proyecto especificado previamente están terminado y por tanto ha pasado satisfactoriamente
por el proceso de validación.
…………………….... ……..……………… ……………………..
Gerente Sub Gerente Jefe de Recursos
SOFTWARE DE RECONOCIMIENTO DE PATRONES VEHICULARES
xli
Sistema de Reconocimiento de Patrones Vehiculares
Especificación de Caso de Uso:
Autenticar usuario
CAPÍTULO 8. EMPAQUETADO Y PUESTA EN MARCHA DEL SISTEMA
xlii
SOFTWARE DE RECONOCIMIENTO DE PATRONES VEHICULARES
43
Especificación de caso de uso: Autenticar usuario
Autenticar usuario
Descripción
Para mantener el seguimiento de las acciones realizadas y un buen nivel de seguridad en el sistema, se debe contar con la posibilidad de verificar que los usuarios que intentan ingresar a la aplicación, sean los usuarios indicados.
Actores
Administrador Operadorentos El caso de uso se inicia cuando el actor ingresa a un módulo del sistema.
Flujo Básico
1. El actor ingresa a uno de los módulos del sistema. 2. El sistema verifica si la cuenta del actor tiene privilegios para ingresar al
módulo deseado. 2.1. El sistema obtiene la información del usuario de su cuenta en el active
directory y lo verifica. 2.2. El sistema permite el acceso al usuario al módulo deseado.
3. El caso de uso termina.
Flujos Alternativos
<2.1> <Error de conexión con el servidor>
Este flujo se activa cuando no se puede realizar la conexión con el servidor. Se muestra un aviso sobre el evento ocurrido. El flujo continúa en el evento anterior.
<2.2.1> <El usuario no tiene permisos para ingresar al módulo deseado>
Este flujo se activa cuando la cuenta del usuario no tiene privilegios de acceso. El flujo continúa en el punto 3. econdiciones
La cuenta de usuario debe estar registrada en el sistema.
El usuario autenticado debe pertenecer al grupo de usuarios con permisos para ejecutar la
aplicación.
Precondiciones
El usuario puede acceder a las aplicaciones.