UNIVERSIDAD TECNOLÓGICA DEL PERÚ

FACULTAD DE INGENIERÍA INDUSTRIAL Y DE SISTEMAS

DISEÑO DE UN PROTOTIPO PARA UN SISTEMA MÓVIL DE

CONSULTA Y REGISTRO DE DOCUMENTOS DE
INFRACCIONES DE TRÁNSITO

Presentado por:

TERRAZOS LUNA, Luigy Benedicto

VERASTEGUI AVILA, David Orlando

Asesor:

ARTICA CUYUBAMBA, Gustavo

LIMA

2014
INDICE
Introducción: ..........................................................................................................................10
1. Capítulo I: Aspectos Generales .....................................................................................11
1.1 Definición del Problema ..........................................................................................11
1.2 Objetivos .................................................................................................................15
1.2.1 Objetivo General ..............................................................................................15
1.2.2 Objetivos Específicos ......................................................................................15
1.3 Motivación y Justificación .......................................................................................15
1.3.1 Motivación: .......................................................................................................15
1.3.2 Justificación: ....................................................................................................16
2. Capitulo II: Fundamento Teórico....................................................................................22
2.1 Antecedentes de Investigación...............................................................................22
2.1.1 Sistema Unificado Nacional Automatizado de Movilidad e Información –
SUNAMI 22
2.1.2 Sistema Integrado de Información sobre Multas y Sanciones por Infracciones
de Tránsito – SIMIT ........................................................................................................23
2.2 Marco Teórico .........................................................................................................25
2.2.1 Herramientas de Integración ...........................................................................25
2.2.2 Herramientas de Base de Datos y Modelamiento ..........................................33
2.2.3 IDE’s de Desarrollo ..........................................................................................35
2.2.4 Servidor de Aplicaciones .................................................................................37
2.2.5 Herramienta de Metodología ...........................................................................38
2.2.6 Programación...................................................................................................39
2.2.7 Herramientas de Monitoreo .............................................................................45
2.2.8 ISO 3166-1 ALFA-2 .........................................................................................46
2.3 Marco Conceptual ...................................................................................................48
2.3.1 Modelo Conceptual ..........................................................................................48
2.3.2 DIVPOLTRAN (División de Policía de Tránsito): ............................................48
2.3.3 SAT ..................................................................................................................52
2.3.4 MTC .................................................................................................................53
2.3.5 SUNARP ..........................................................................................................54
2.3.6 Touring .............................................................................................................54

2
 2.3.7 Sistema Web Movil ..........................................................................................55
2.3.8 Sistemas Distribuidos ......................................................................................56
2.3.9 SOA..................................................................................................................57
2.3.10 BPEL ................................................................................................................60
2.3.11 Enterprise Service Bus ....................................................................................60
2.3.12 Metodología .....................................................................................................62
2.4 Marco Metodológico................................................................................................67
2.5 Marco Legal ............................................................................................................71
2.5.1 Ley de Transparencia y Acceso a la Información Pública ..............................71
3. Capítulo III: Desarrollo de la Aplicación .........................................................................78
3.1 Modelamiento..........................................................................................................78
3.1.1 Requerimientos Funcionales ...........................................................................78
3.1.2 Requerimientos no Funcionales ......................................................................79
3.1.3 Diseño de la Arquitectura ................................................................................80
3.1.4 Diseño de da Base de Datos...........................................................................85
3.1.5 Oracle Data Integration ...................................................................................94
3.2 Desarrollo ................................................................................................................97
3.2.1 Metodología a Aplicar ......................................................................................97
3.2.2 Tabla de SCRUM.............................................................................................98
3.2.3 Sprint Done ......................................................................................................99
3.2.4 Aspectos Generales ...................................................................................... 100
3.2.5 Tarea – Desarrollo de la Aplicación .............................................................. 101
3.2.6 Modelamiento de Datos................................................................................. 102
3.2.7 Diseño de Interfaces...................................................................................... 103
3.3 Aplicación .............................................................................................................. 104
3.3.1 Secuencia de Funcionamiento ...................................................................... 104
3.3.2 Web Services................................................................................................. 116
3.4 Monitoreo .............................................................................................................. 121
3.5 Mantenimiento....................................................................................................... 131
3.5.1 Mantenimiento de base de datos .................................................................. 131
3.5.2 Mantenimiento de Servidores:....................................................................... 131
3.5.3 Mantenimiento de Servidor de Aplicaciones ................................................. 131

3
4. Capítulo IV: Análisis de Costo Beneficio ..................................................................... 132
4.1 Análisis de Costo .................................................................................................. 132
4.1.1 Viabilidad Técnica.......................................................................................... 133
4.1.2 Viabilidad Económica .................................................................................... 136
4.2 Análisis de Beneficios ........................................................................................... 144
4.2.1 Cronograma de Actividades .......................................................................... 145
4.3 Análisis de Sensibilidad ........................................................................................ 147
5. Capítulo V: Conclusiones y Recomendaciones........................................................... 150
5.1 Conclusiones......................................................................................................... 150
5.2 Recomendaciones ................................................................................................ 150
Referencias:......................................................................................................................... 151

4
DEDICATORIA

Dedico este proyecto de Investigación a

mis padres porque son mi motivo para
salir adelante y ser una persona de
bien, por su apoyo incondicional y su
confianza brindada para cumplir mis
metas y porque son el mejor ejemplo de
perseverancia y dedicación, a los
profesores por sus constantes
enseñanzas y trasmisión de
experiencias y a todas las personas que
conocí en este tiempo y siempre me
dieron su apoyo, y a mi compañero
Luigy por acompañarme y apoyarme en
la realización de este proyecto.

David O. Verastegui Avila

5
DEDICATORIA

Dedico este proyecto a mis padres por

invertir en mi educación, en mis hermanas
por su constante apoyo, a mi primo Ronald
Luna que incentivo la Ingeniería de Sistemas
en mí, a mis mentores Ing. Moreno, Ing.
Zuloaga, Ing. Dongo e Ing. Petrlik que me
ayudaron en la pasión de la programación y
por los grandes consejos que me dieron, a
mi compañero de proyecto David por
soportar la presión y por dar toda la
dedicación para nuestro proyecto. Como
también a la nueva familia a donde
pertenezco IBM del Perú donde espero
conseguir todo lo planeado para mi carrera.

Luigy B. Terrazos Luna

6
RESUMEN

El presente trabajo de tesis "Diseño de un prototipo para un Sistema

Web Móvil de consulta y registro de documentos de Infracciones de
Tránsito" tuvo como motivación principal percibir el alto índice de
accidentes de tránsito en Lima Metropolitana.

Por tal motivo el desarrollo de este proyecto que brindara una

herramienta tecnológica al Policía de Tránsito donde podrá realizar
consultas al momento de la intervención al conductor y con ello tomar
una decisión preventiva.

Nuestra Arquitectura se basa en SOA (Arquitectura Orientada a

Servicios) para lograr integrar la información de las entidades
relacionadas (MTC, SUNARP y SAT) con la Policía Nacional del Perú
(PNP), para el desarrollo del proyecto se utilizara una Metodología Ágil
(SCRUM).

La plataforma será de entorno Web Móvil con el fin de que cualquier

dispositivo móvil con conexión a internet pueda utilizarlo, será
programado con el lenguaje de programación Java, aplicando las
buenas prácticas como la ejecución de pruebas unitarias y se accederá
a la información mediante Servicios Web.

Se realizó la validación funcional del Sistema con el Mayor de la

Comisaria de Pamplona I, donde se tuvo como resultado la aceptación
del prototipo. El resultado es la reducción de la tasa de accidentes de
tránsito y la disminución del tiempo de intervención al conductor.

7
ABSTRACT

The present thesis "Design of a prototype for a Mobile Web Query

System and registration documents Traffic Violations" main motivation
was to perceive the high rate of traffic accidents in Lima.

Therefore the development of this project will provide a technological

tool to Traffic Police where can inquire at the time of the intervention the
driver and thereby take a preventive decision.

Our architecture is based on SOA (Service Oriented Architecture) to

achieve integrate information from related entities (MTC, SUNARP and
SAT) with the National Police of Peru (PNP) for the project Agile
(SCRUM methodology was used ).

The platform is Mobile Web environment so that any mobile device with
Internet connection can use it, will be programmed with the Java
programming language, applying best practices and the implementation
of unit testing and access the information using Web Services.

Functional validation system with the Mayor of Commissioner of

Pamplona I, where resulted in the acceptance of the prototype was
performed. The result is a reduction in the rate of traffic accidents and
reducing the time of intervention to the driver.

8
AGRADECIMIENTO

Agradecer en primer lugar la Universidad Tecnológica del

Perú, a la plana docente por sus conocimientos y
experiencias transmitidas durante toda la carrera
universitaria.

A nuestro asesor Gustavo Artica Cuyubamba por sus

correcciones, observaciones constructivas y dedicación
para seguir con nuestros objetivos.

9
Introducción:

Al día ocurren muchos accidentes de tránsito a nivel nacional por que no se prevé
de los malos conductores, la corrupción policial y entre otros factores que ocurren
en Lima.

Un conductor puede tener muchas papeletas y seguir conduciendo, esto se debe a

que cuando el conductor comete una infracción y es intervenido por un policía de
tránsito, el policía solo atina a seguir registrando la infracción mas no tomar una
medida correspondiente, como sancionarlo por sobrepasar los puntos permitidos
para conducir, esto es debido a que no cuentan con ninguna herramienta
tecnológica que les proporcione la información en el momento oportuno, otro sería
el caso si fuera intervenido por un patrullero inteligente que cuenta con una laptop
en el interior del vehículo donde consulta vía web los sistemas de otras entidades
para poder realizar las respectivas consultas sobre el conductor, pero la cantidad
de patrulleros inteligentes en todo el Perú es de aproximadamente de 800
vehículos [1] , debido a eso nuestro proyecto va orientado a aquellos policías de
tránsito de a pie.

Para esto se plantea diseñar un Sistema Web Móvil que realizara consultas donde
se visualizara la información del Ministerio de Transportes y Comunicaciones
(MTC) y Superintendencia Nacional de los Registros Públicos (SUNARP) para
obtener el estado del conductor, los puntos que tiene en ese momento, la vigencia
del SOAT, el estado de su licencia y el estado del vehículo.

Este sistema ayudara a los policías de tránsito a prevenir accidentes futuros ya

que con la información en el tiempo oportuno se podría tomar las medidas
preventivas y no esperar a que las cifras de accidentes de tránsito sigan en
aumento.

10
1. Capítulo I: Aspectos Generales

1.1 Definición del Problema

Actualmente los índices de accidente de tránsito son muy altos, según INEI en
el periodo de Enero – Marzo del 2012 se han registrado 22 mil 223 accidentes
de tránsito, siendo el mayor número en Lima con 11mil 616 (estadística en
publicación de INEI) [2], en el 2011 el MINSA dio una revelación muy
sorprendente que al día mueren 7 peruanos en accidentes de tránsito y 30
quedan heridas (información publicada por el MINSA) [3], el 14 de octubre del
2012 el periódico El Comercio dio a conocer en el los últimos 4 años anteriores
a esa fecha ocurrieron 5400 muertes en accidentes de tránsito (información
publicada en el diario “comercio”) [4].

Figura 1: Número de Accidentes de Tránsito en Perú (Trimestre 2010 - 2012)

Fuente: Instituto Nacional de Estadística e Informática - INEI.

De acuerdo a los datos proporcionados por la Policía Nacional del Perú [5], la
tendencia del número de accidentes de tránsito se está incrementando a nivel
nacional. En el año 2002 se produjeron 74 221 accidentes de tránsito en
comparación con el año 2012 en el que ocurrieron 94 972 lo que representa un
incremento de 27% de los accidentes en el periodo analizado.

11
 Figura 2: Número de Accidentes de Tránsito por Año, Perú

Fuente: Policía Nacional del Perú - Estado Mayor General/DIRPEP-DIVES T-UP

En la gráfica siguiente se observa que el número de heridos por accidentes de

tránsito registrados por la Policía Nacional es ascendente en los últimos años;
de igual manera, se observa que para el periodo 2010-2012, la tendencia de la
mortalidad fue ascendente [5].

Figura 3: Número de heridos y muertos por accidentes de tránsito en el Perú

Fuente: Policía Nacional del Perú - Estado Mayor General/DIRPEP-DIVES T-UP

12
 Cuando sucede un accidente de tránsito es donde se dan cuenta que el
conductor tenía muchas papeletas en su historial y nunca se le retuvo la licencia
de conducir por superar los 100 puntos.

La policía de tránsito no tiene ninguna herramienta de consultas de documento

y esta es una necesidad a la que se le tiene que dar mucha prioridad.

La intervención del policía al conductor se realiza de la siguiente manera:

 Se le pide el DNI y la licencia de conducir, el policía tiene que revisar que
los datos concuerden en los documentos, pero no están comprobando si
en realidad los dos sean verdaderos o falsos, debido a que no todo los
policías se encuentran en la capacidad de afirmar que los documentos
sean verdaderos, para esto tienen que llevar un curso de peritaje que lo
da el Ministerio Público.
 Con la tarjeta de propiedad del vehículo realizan el mismo procedimiento
que con la licencia de conducir, más no hacen una consulta si este
vehículo tiene una requisitoria o si fue robado.
 El SOAT para verificar que este con la fecha vigente.
 La indicación al conductor de la infracción que cometió, registro de la
papeleta y concluye con la firma del conductor que se puede dar o no.

Como observamos en ningún momento pudo comprobar algún documento, solo

por reglamento siguió estos procedimientos y se demoró aproximadamente de
5 a 10 minutos (según los policías de tránsito) [6] ocasionando que se formen
colas de automóviles y generando tráfico.

13
 Figura 4: Diagrama de Causa – Efecto “Accidentes de Tránsito”

PNP MTC

Falta de Integración
Falta de de la base de datos
Herramientas con la PNP
Tecnológicas de
consultas
Accidentes
de Tránsito
Falta de Integración
de la base de datos
Falta de Integración
con la PNP de la base de datos
con la PNP

SAT SUNARP

Fuente: Elaboración Propia

Actualmente la Dirección de la Policía de Tránsito no cuenta con Herramientas

Tecnológicas para consultar el estado del conductor al momento de ser
intervenido, ocasionando que los infractores sigan transitando por las calles.
Además de que la integración de la información con las otras entidades (MTC,
SUNARP y SAT) es manual, debido a que al momento de la generación de las
papeletas estas son enviadas físicamente al SAT para que se cargue en sus
sistemas y logren hacer el cobro de las infracciones, el mismo caso se aplica
para el MTC. El MTC y SUNARP provee herramientas tecnológicas como
“Sistema de Licencias de Conductor por puntos”, “Consulta Vehicular” y
“Sistema de Consultas de SOAT” que solo pueden ser accedidas mediante las
patrullas inteligentes.

14
 1.2 Objetivos
1.2.1 Objetivo General

 Diseño de un prototipo de un Sistema Web Móvil para la Policía

de Tránsito, con el fin de reducir el alto índice de accidentes de
tránsito.

1.2.2 Objetivos Específicos

 Integrar y normalizar la información de las entidades del MTC,

SUNARP y del SAT.
 Desarrollar una herramienta tecnológica para realizar consultas
de la información de los conductores.
 Automatizar los procesos de integración de datos con las
entidades SUNARP, MTC y SAT.
 Validar la funcionalidad con un usuario de una entidad de la
policía de tránsito.
 Validación del modelo propuesto.

1.3 Motivación y Justificación

1.3.1 Motivación:

La motivación tuvo en primer lugar ver y escuchar diariamente tantas

noticias de accidentes de tránsito que ocurren a nivel nacional, conductores
irresponsables, que luego de ser intervenidos se descubre que tienen varias
papeletas acumuladas e incluso que no contaban con brevete, porque se
les retuvo anteriormente o nunca lo tramitaron.

A este problema se le suma la falta de herramientas tecnológicas que no

cuenta la policía de tránsito al intervenir a un conductor, ocasionando
accidentes de tránsito futuros que muchas veces acaban en tragedias
mortales.

15
 1.3.2 Justificación:

Al momento de la intervención de un Policía de Tránsito a un conductor, no

cuenta con una herramienta tecnológica para realizar las consultas
pertinentes sobre el conductor y el vehículo, esto se debe a que no tiene la
información disponible. Además que dicha información no está integrada
con las entidades (PNP, MTC, SUNARP y SAT) que son las encargadas de
gestionar el Transporte Terrestre en el Perú.

Por tal motivo se plantea el diseño de un sistema que tendrá el propósito de

disminuir la tasa de accidentes de tránsito y la tasa de mortalidad a causas
de accidentes de tránsito, buscando la integración de la información del
MTC, SUNARP y SAT con la PNP.

1.3.2.1 Situación actual:

Figura 5: Proceso Actual de registro de papeletas

Diagrama Funcional
Fase
Policía

Detiene el vehículo
Registrar Papeleta Deja las papeletas
físicas en su
división policial.

Vehículo se detiene Vehículo se Retira

Conductor

El conductor entrega sus documentos

Firma Papeleta

Fuente: Elaboración Propia

En la Figura N° 5 se observa el proceso actual de registro de papeleta

donde el Policía de Tránsito solicita que el vehículo se detenga,
posteriormente el vehículo se detiene donde el policía solicita los
documentos al conductor, el conductor entrega sus documentas, luego el

16
 policía de tránsito registra la papeleta y posteriormente entrega el
documento al conductor para que lo firme, el vehículo pasa a retirarse y
luego el policía tiene que dejar las papeletas registradas en su división
policial correspondiente.

Figura 6: Proceso Actual de Traspaso de Papeletas Físicas al SAT

Diagrama Funcional
Fase
Policía

Policía entrega
las papeletas
físicas registradas
SAT

Carga las papeletas físicas a sus

sistema

Fuente: Elaboración Propia

En la Figura N° 6 se observa el proceso actual de traspaso de papeletas

físicas al SAT, donde el policía entrega las papeletas físicas al SAT donde
se encargaran de fiscalizar las papeletas.

Figura 7: Proceso Actual de Traspaso de Papeletas Físicas al MTC

Diagrama Funcional
Fase
Policía

Policía entrega
las papeletas
físicas registradas
MTC

Carga las papeletas físicas a sus

sistema

17
 Fuente: Elaboración Propia

En la Figura N° 7 se observa el proceso actual de traspaso de papeletas

físicas al MTC, donde el policía entrega las papeletas físicas al MTC
donde se encargaran de cargar la información a sus Sistemas.

Figura 8: Proceso de Generación de duplicado de la Licencia de Conducir

Diagrama Funcional
Fase
Conductor

Conductor se
dirige a las oficinas
del Touring
Touring

Genera un duplicado
de la licencia de conducir

Fuente: Elaboración Propia

En la Figura N° 8 se observa el proceso de Generación de duplicado de la

Licencia de Conducir, donde para ello el conductor se dirige a las oficinas
del Touring, donde solicita el duplicado de su licencia de conducir, el
Touring le entrega una declaración jurada donde el conductor debe indicar
que no se le ha retenido la licencia, luego que el conductor haya declarado
el documento, el Touring le genera el duplicado de su licencia de conducir.
Pero no todos los conductores son sinceros al entregar la declaración
jurada debido a que en algunos casos lo hacen cuando la licencia fue
retenida. Mediante este procedimiento el conductor genera nuevamente su
licencia conducir, burlando a si a la acción de retención de su licencia de
conducir.

18
 1.3.2.2 Propuesta de la Solución

Teniendo en cuenta el alto índice de accidentes de tránsito y de percibir el

tráfico que se genera cuando se hace una intervención policial a un
vehículo se plantea un sistema web móvil para reducir el tiempo de
intervención al conductor y la tasa de accidentes de tránsito.

Se presenta la siguiente solución a la problemática:

El Diseño un prototipo de sistema web móvil multiplataforma que cubrirá

las siguientes funciones:

 Consultar el puntaje del conductor.

 Consultar si tiene el SOAT vigente.
 Consultar si el vehículo fue robado, según información de
SUNARP.
 Listar las sanciones de infracción. [ANEXO 1]
 Exponer la información a otros clientes que requieran la
información de los conductores (MTC, SAT, TOURING, ETC).
Ejemplo el Touring podría consultar la información del conductor
para tener conocimiento de que la persona tiene retenida la
licencia de conducir y prevenir que el conductor mienta en la
declaración jurada sobre su licencia que fue extraviada para
solicitar una renovación.
 Exponer la información de las papeletas impuestas para que el
SAT pueda fiscalizar.
 Registro de Papeleta por la infracción cometida por parte del
conductor.

Para la propuesta se tendrá que pedir autorización para acceder a la

información del MTC, SUNARP y del SAT, como es una información

19
 pública no se tendrá ningún inconveniente, según las autoridades del
INSUTRA (Instituto Superior de Transito) el Ministerio del Interior se podría
poner en contacto con las entidades correspondientes para pedir los
accesos correspondientes.

1.3.2.3 Alcance de la Solución

La solución podría ser implementada en la Policía de Tránsito de Lima

Metropolitana, donde se realizó las pruebas con los policías de la
Comisaria de Pamplona I, dicha solución estará en un entorno Web Movil
con el propósito de que sea multiplataforma, que va requerir el uso de
conexión a internet 3G como requisito mínimo, el cual tendrá las
siguientes funcionalidades:
 Se ingresara el DNI del conductor y la placa del vehículo, que
realizara las siguientes validaciones:
- Los puntos del conductor.
- El estado de su licencia (activa, retenida o vencida).
- Vigencia del SOAT.
- Estado del vehículo.
 Se registrara la papeleta donde el usuario (policía de tránsito) debe
ingresar los datos requeridos.
 Exponer la información de las papeletas impuestas para que el SAT
pueda fiscalizar.
 Exponer la información a otros clientes que requieran la información
de los conductores (MTC, SAT, TOURING, etc.).

Figura 9: Teléfono celular simulando una interfaz de reporte

20
 Simulación del Sistema

Policía

Policía solicita los

Policía consulta los datos del
documentos al
conductor y del vehículo
conductor
en su dispositivo móvil
Conductor

Conductor entrega sus documentos

Fuente: Elaboración Propia

En la figura N°9 se muestra la simulación del Sistema Web Movil, de la

intervención de un Policía de Tránsito a un conductor usando la
herramienta tecnológica donde el policía solicita los documentos al
conductor (Licencia de Conducir, Tarjeta de propiedad y SOAT), y
posteriormente se realiza la consulta, donde se ingresara los datos del
conductor y del vehículo.

21
2. Capitulo II: Fundamento Teórico

2.1 Antecedentes de Investigación

2.1.1 Sistema Unificado Nacional Automatizado de Movilidad e
Información – SUNAMI

La Policía Nacional de Colombia implemento en febrero del 2012 una

Estrategia Tecnológica de la Policía Nacional de Colombia con ayuda de su
Departamento de Telemática, desarrollaron muchos proyectos importantes
como el SUNAMI (Sistema Unificado Automatizado par la Movilidad de la
Información) que sirve para hacer consulta de documentos de las
personas, que son usadas en intervenciones a conductores obteniendo
información en el tiempo que se requiere obteniendo buenos resultados y
optimizando el tiempo con el que se podía intervenir a un conductor
(información verbal). [7]

Como también centrales telefónicas donde los policías se contactan con sus
radios que tienen un encriptación segura que solo los policías pueden
acceder a esa red para poder hacer consultas de los documentos de los
conductores y de los automóviles. [7]

22
 Figura 10: Central telefónica de la Policía de
Colombia para la consulta de documentos.

Fuente: Policía Nacional de Colombia [7]

Figura #6:
11: Teléfono celular con el sistema de la Policía de Colombia
Colombia ee impresora
impresora para
para
generar las papeletas.

Fuente: Policía Nacional de Colombia [7]

2.1.2 Sistema Integrado de Información sobre Multas y Sanciones por

Infracciones de Tránsito – SIMIT

SIMIT es un sistema que integra el registro de infracciones a nivel nacional

en la República de Colombia que fue implementada en el 2014 y
controla la no realización de trámites cuando el usuario posee deudas por
infracciones a las normas de tránsito.

23
 El sistema dispone de información oportuna a nivel local y nacional para el
control que ejercen las autoridades de tránsito.

Es el único sistema en el país que les permite a los usuarios realizar el

pago de sus multas en cualquier lugar del país, con el objeto de mejorar los
ingresos de los Municipios [8].

Figura 12: Esquema Operacional del SIMIT

Fuente: SIMIT [8]

En la Figura N° 12 se observa el Esquema Operacional del SIMIT, donde

los usuarios se acercan a un punto de atención al cliente SIMIT ubicado en
la Secretaria de Tránsito, para pagar sus deudas pendientes debido a que
cometieron una infracción de tránsito que fue impuesto por el policía de
carreteras o los agentes de tránsito. Donde el personal del SIMIT realiza la
consulta a su sistema y si el conductor tiene deudas pendientes deberá de
realizar el pago correspondiente en las entidades bancarias autorizadas.
24
 2.2 Marco Teórico
2.2.1 Herramientas de Integración

2.2.1.1 ETL (Extracción, Transformación y Carga)

Extract, Transform and Load (Extraer, transformar y cargar en castellano,

frecuentemente abreviado a ETL) es el proceso que permite a las
organizaciones mover datos desde múltiples fuentes, reformatearlos y
limpiarlos, y cargarlos en otra base de datos, data mart, o data
warehouse para analizar, o en otro sistema operacional para apoyar
un proceso de negocio.

Los procesos ETL también se pueden utilizar para la integración

con sistemas heredados. [9]

Extraer:

La primera parte del proceso ETL consiste en extraer los datos desde los
sistemas de origen. La mayoría de los proyectos de almacenamiento de
datos fusionan datos provenientes de diferentes sistemas de origen. Cada
sistema separado puede usar una organización diferente de los datos o
formatos distintos. Los formatos de las fuentes normalmente se
encuentran en bases de datos relacionales o ficheros planos, pero pueden
incluir bases de datos no relacionales u otras estructuras diferentes. La
extracción convierte los datos a un formato preparado para iniciar el
proceso de transformación.

25
 Una parte intrínseca del proceso de extracción es la de analizar los datos
extraídos, de lo que resulta un chequeo que verifica si los datos cumplen
la pauta o estructura que se esperaba. De no ser así los datos son
rechazados.

Transformar:

La fase de transformación aplica una serie de reglas de negocio o

funciones sobre los datos extraídos para convertirlos en datos que serán
cargados. Algunas fuentes de datos requerirán alguna pequeña
manipulación de los datos.

Cargar:

La fase de carga es el momento en el cual los datos de la fase anterior

(transformación) son cargados en el sistema de destino. Dependiendo de
los requerimientos de la organización, este proceso puede abarcar una
amplia variedad de acciones diferentes. En algunas bases de datos se
sobrescribe la información antigua con nuevos datos. Los data warehouse
mantienen un historial de los registros de manera que se pueda hacer una
auditoría de los mismos y disponer de un rastro de toda la historia de un
valor a lo largo del tiempo.

Existen dos formas básicas de desarrollar el proceso de carga:

Acumulación simple: La acumulación simple es la más sencilla y común, y

consiste en realizar un resumen de todas las transacciones comprendidas
en el período de tiempo seleccionado y transportar el resultado como una
única transacción hacia el data warehouse, almacenando un valor
calculado que consistirá típicamente en un sumatorio o un promedio de la
magnitud considerada.

26
 Rolling: El proceso de Rolling por su parte, se aplica en los casos en que
se opta por mantener varios niveles de granularidad (jerarquías). Para ello
se almacena información resumida a distintos niveles, correspondientes a
distintas agrupaciones de la unidad de tiempo o diferentes niveles
jerárquicos en alguna o varias de las dimensiones de la magnitud
almacenada (por ejemplo, totales diarios, totales semanales, totales
mensuales, etc.).

La fase de carga interactúa directamente con la base de datos de destino.

Al realizar esta operación se aplicarán todas las restricciones y triggers
(disparadores) que se hayan definido en ésta (por ejemplo, valores únicos,
integridad referencial, campos obligatorios, rangos de valores). Estas
restricciones y triggers (si están bien definidos) contribuyen a que se
garantice la calidad de los datos en el proceso ETL, y deben ser tomados
en cuenta.

2.2.1.2 Oracle Data Integrator

Oracle Data Integrator es la herramienta de integración de datos de

Oracle. Es la apuesta de Oracle en cuestiones de integración de datos y
sustituye a OWB (Oracle Warehouse Builder). Forma parte de la solución
OFM (Oracle Fusion Middleware) y está totalmente integrada con otras
soluciones Oracle relacionadas con la gestión de datos. [10]

Funcionalidades de integración de datos:

ODI simplifica bastante todas las tareas de integración y gestión de datos

caben destacar los siguientes puntos:

 Población y actualización entornos Data Warehouse: Ejecución de

procesos con alto volumen de datos, obteniendo excelentes tiempos
de respuesta. Actualización de data warehouses, data marts, cubos
OLAP y sistemas analíticos en general. Gestiona de forma
transparente las cargas totales o incrementales, considera

27
 dimensiones SCD (Slowly Changes Dimensions), asegura la
integridad y consistencia de datos y facilita la trazabilidad del dato
(origen del dato, detalle de transformaciones y destino del dato).
Procesos de integración de datos basados en datos de entrada,
procesos batch, eventos y ejecución de servicios.
 Arquitecturas Orientadas a Servicios (SOA): Permite desarrollar
servicios de integración de datos (acceso a datos, validaciones,
transformación, volcado de datos, etc.) para su posterior integración
de forma poco costosa en infraestructuras basadas en arquitecturas
SOA, dotando a esta infraestructura de capacidades para gestionar
altos volúmenes de datos, alto rendimiento en los procesos y
volcados de datos masivos.
 Master Data Management (MDM): Facilita la gestión de datos
maestros con funcionalidades para la sincronización de datos.
Permite la conexión entre los datos maestros y el Data Warehouse,
asegurando la integridad entre las dimensiones y jerarquías MDM y
las tablas de hechos del Data Warehouse. Actualización de MDM
data hubs (concentradores de datos con tablas de referencias
cruzadas a todos los sistemas fuente) para cada uno de los dominios
de los maestros de datos (ejemplo: cliente, producto, etc.).
Integración con procesos BPEL (Business Process Execution
Language) y los servicios webs compuestos por este lenguaje de
orquestación.
 Procesos de migración de datos: Gestiona volcados de datos
masivos entre sistemas antiguos y los nuevos sistemas de forma
eficiente, pudiendo incluir en el movimiento de datos
transformaciones complejas, así como la sincronización de datos
entre ambos sistemas durante su periodo de coexistencia.
Arquitectura E-LT:

ODI modifica el tradicional concepto ETL (Extract, Transform, Load),

pasando a E-LT (Extract – Load, Transform). La arquitectura E-LT extrae

28
 los datos de los sistemas fuente, los carga en base de datos y realiza
todas las transformaciones en la propia base de datos.

En el tradicional ETL el proceso de transformación puede ser realizado en

un entorno hardware y software diferente al de la base de datos de
destino, mientras que en un esquema E-LT la transformación y el volcado
se realizan en una misma plataforma hardware y software. Lógicamente
un esquema E-LT reduce el tráfico de datos, pero hay que dotar al motor
de la base de datos de destino de capacidades de transformación y
movimiento de datos potentes, capacidades que provee ODI. Así mismo,
ODI permite realizar dentro de la base de datos transformaciones
complejas al mismo nivel que el servidor que realiza la capa de
transformación en un ETL convencional.

Considerar igualmente que una arquitectura E-LT se realiza toda la

optimización de recursos (disco, memoria, proceso) en la base de datos, lo
cual permite una configuración del rendimiento más centralizada. La
propia ejecución de las transformaciones puede ser diferente en una
arquitectura y otra, ya que hay herramientas ETL que evalúan las
transformaciones registros a registro y en el caso E-LT se realiza por lotes
de registros. ODI permite combinar la potencia del motor de la base de
datos con las prestaciones hardware que Oracle puede ofrecer
alcanzando una arquitectura E-LT de alto rendimiento.

Alta productividad en el diseño de procesos de integración de datos:

ODI introduce un entorno de desarrollo basado en JDeveloper que reduce

los tiempos de desarrollo y permite diseñar de forma intuitiva procesos de
transformación y volcado de datos complejos. Nuevas funcionalidades
como ‘quick-edit’ implementan de forma sencilla actualizaciones masivas.

Uno de los principales objetivos de ODI es centrar a los desarrolladores y

a los usuarios de negocio en describir las transformaciones a realizar, sin

29
 necesidad de invertir mucho tiempo en los aspectos técnicos relativos a la
implementación de estas transformaciones.

ODI plantea al desarrollador un diseño declarativo más centrado en las

necesidades de transformación que en los procedimientos. Permite
centrarse en ‘qué hacer’, en lugar de ‘cómo hacer’. El diseñador describe
las fuentes origen y destino y los procesos de transformación e
integración, ODI genera los procedimientos y el código necesario para
implementarlos.

Alta disponibilidad y escalabilidad:

ODI se integra con la plataforma Oracle Fusion Middleware. En esta

plataforma ODI ofrece sus componentes como aplicaciones Java EE,
optimizados para aprovechar al máximo las capacidades de su servidor de
aplicaciones Oracle WebLogic. Los componentes ODI están provistos de
funcionalidades que permiten su despliegue en un entorno de alta
disponibilidad, escalabilidad y seguridad. Los componentes de ODI
desplegados en el servidor de aplicaciones WebLogic se benefician de las
funcionalidades de este en cuestiones relativas a escalabilidad, pooling de
conexiones JDBC y balanceo de carga de trabajo. Igualmente ODI puede
beneficiarse de las capacidades de trabajo de bases de datos en grupo
(clusters, grupos de máquinas) que permite Oracle RAC (Real Application
Clusters), con todas las capacidades que conllevan un motor de base de
datos de alta disponibilidad de estas características.

Gestión y administración centralizadas (consola ODI):

La consola de ODI se realiza en un entorno bajo un framework Ajax que

mejora la experiencia de usuario (ADF Oracle Application Development
Framework). Desde esta consola se pueden crear entornos de trabajo,

30
 realizar exports e imports de repositorios de datos, controlar procesos,
monitorizar sesiones, control y seguimiento de errores, diseñar procesos,
realizar informes de trazabilidad, etc.

Esta interfaz se integra con la Enterprise Manager Fusion Middleware

Control y permite a los administradores monitorizar no sólo los
componentes de integración de datos ODI, sino todos los componentes de
la plataforma Oracle Fusion Middleware.

ODI Knowledge Modules:

Los Knowledge Modules son el núcleo de la arquitectura ODI. Proveen a

la arquitectura Oracle de flexibilidad, modularidad y fácil ampliación.
Soportan plataformas de terceros, heterogéneas fuentes de datos y data
warehousing appliances. Los KM implementan los flujos de datos y
definen plantillas para generación de código involucrando diferentes
sistemas y plataformas.

Los KM permiten la creación de flujos de datos sin que la complejidad de

las reglas de transformación cambie su diseño. Por otro lado, son muy
específicos ya que los procesos y el código generado están orientados y
optimizados a la tecnología de base con la que se integran. ODI dispone
de una librería de módulos KM para adaptarlos a medida definiendo unas
mejores prácticas.

2.2.1.3 Oracle Service Bus

Oracle Service Bus está diseñado para conectarse, mediar y administrar

las interacciones entre servicios heterogéneos, aplicaciones tradicionales,
aplicaciones empaquetadas y múltiples instancias Enterprise Service Bus
(ESB) a través de una red de servicios para toda la empresa. [11]

Oracle Service Bus permite la integración de servicios controlados por la

configuración, con ruteo basado en identidades y contenido inteligente.
Mejora la productividad del desarrollador debido a la integración de

31
 servicios de código libre. Oracle Service Bus también brinda transporte
nativo para aplicaciones empaquetadas y planificación de recursos
empresariales líderes, junto con la conectividad a aplicaciones basadas en
el servidor e IBM WebSphere.

Oracle Service Bus brinda capacidades incorporadas para la virtualización

de servicios, Web Service Security (WS-Security) y el cumplimiento de
políticas en torno a la regulación y la agrupación de servicios a fin de
cumplir con los requerimientos de Confiabilidad, Disponibilidad y
Desempeño (RASP) y evitar la sobrecarga de servicios de back-end.
Oracle Service Bus está creado desde cero con soporte integral para
SOA, Java 2 Platform, Enterprise Edition (J2EE), y estándares como J2EE
Connector architecture (JCA), WS-Reliable Messaging y WS-Security.

2.2.1.4 Oracle SOA Suite

Oracle SOA Suite es un conjunto de software completo y con

funcionamiento permanente para la creación, implementación y
administración de una arquitectura orientada a servicios. Esto incluye el
desarrollo de aplicaciones orientadas a servicios, la integración de
sistemas de IT y aplicaciones orientadas a servicios y la administración de
procesos de negocio orientados a servicios. Se conecta a las
infraestructuras de IT heterogéneas y permite a las empresas adoptar
SOA de manera gradual. [12]

Los componentes de la suite se benefician con capacidades en común,

con inclusión de un solo modelo de administración e implementación,
herramientas consistentes, seguridad integral y administración de
metadatos unificados.

Oracle SOA Suite mejora la capacidad de la empresa tanto para predecir

los cambios —mejorando la visibilidad de lo que ocurre en el entorno de
los negocios, en tiempo real— como para responder a esos cambios —
permitiendo a las empresas desarrollar y optimizar los procesos de

32
 negocio rápidamente. Simplifica el entorno de IT al ser abastecido,
implementado, monitoreado y administrado como una sola infraestructura
cohesiva. Aprovecha las inversiones existentes al ser modular, abierto y
extensible.

Oracle SOA Suite consta de los siguientes componentes:

 Un administrador de procesos basado en BPEL para componer

servicios en los procesos de negocio.
 Una solución para el monitoreo de la actividad de los negocios a fin
de obtener visibilidad en tiempo real de las operaciones y el
desempeño de los servicios y procesos de negocio.
 Un motor de reglas de negocio para capturar y automatizar las
políticas de negocios.
 Oracle Service Bus de múltiples protocolos para conectarse a las
aplicaciones y rutiar los mensajes
 Conectividad a prácticamente todas las fuentes de datos, con
inclusión de las aplicaciones, bases de datos, colas, RFID y otros
dispositivos físicos, así como la integración de datos de gran
volumen y de alto desempeño.
 Oracle JDeveloper, un Entorno de Desarrollo Integrado (IDE) para
administrar, depurar, elaborar perfiles e implementar servicios.
 Una solución de seguridad y administración de servicios Web para
hacer cumplir las políticas de autenticación y autorización en torno a
los servicios
 Un registro de servicios para detectar y administrar el ciclo de vida
de los servicios.

2.2.2 Herramientas de Base de Datos y Modelamiento

33
 2.2.2.1 Oracle Database 11G Enterprise Edition

Oracle Database 11g Enterprise Edition es la base de datos en el centro

de la máquina de base de datos Oracle Exadata y Oracle Database
Appliance. Proporciona funciones completas para gestionar fácilmente el
procesamiento de transacciones más exigente, inteligencia de negocios y
aplicaciones de gestión de contenidos. [13]

Viene con una amplia gama de opciones para ampliar el número 1 del
mundo de bases de datos para ayudar a crecer su negocio y cumplir con
el desempeño de sus usuarios, la seguridad, la disponibilidad y las
expectativas de nivel de servicio.

Beneficios:

 Protege de fallo del servidor, el fracaso del sitio, errores humanos, y

reduce el tiempo de inactividad planificado.
 Asegura los datos y permite cumplir con el nivel de fila única de
seguridad, de grano fino de auditoría, cifrado de datos transparente,
y la recuperación total de datos.
 De alto rendimiento de almacenamiento de datos, procesamiento
analítico en línea, y la minería de datos.
 De alto rendimiento de almacenamiento de datos, procesamiento
analítico en línea, y la minería de datos.
 Fácilmente gestiona ciclo de vida completo de la información para la
mayor de las bases de datos.

2.2.2.2 Erwin Data Modeler

34
 Erwin Data Modeler es una herramienta de diseño de bases de datos que
te ayuda a generar, y mantener alta calidad y gran rendimiento en las
aplicaciones de bases de datos. Desde un modelo lógico de los
requerimientos de información y las reglas de negocio que definen tus
bases de datos al modelo físico optimizado por las características
específicas de tus bases de datos, Erwin Data Modeler te permite
visualizar la estructura, elementos clave y optimizar el diseño de tus bases
de datos. [14]

Erwin Data Modeler automáticamente genera tablas y cientos de líneas de

procedimientos almacenados y código trigger para las bases de datos. La
tecnología “complete-compare” te permite el desarrollo iterativo para que
tus modelos estén siempre sincronizados con tu base de datos.

Ventajas clave

 Fácil acceso a cualquier base de datos relacional.

 Comparación comprensiva entre el modelo de datos y la base de
datos
 Soporta la separación del modelo lógico y del físico.

2.2.3 IDE’s de Desarrollo

2.2.3.1 Eclipse

Eclipse es un programa informático compuesto por un conjunto de

herramientas de programación de código abierto multiplataforma para
desarrollar lo que el proyecto llama "Aplicaciones de Cliente Enriquecido",
opuesto a las aplicaciones "Cliente-liviano" basadas en navegadores. Esta
plataforma, típicamente ha sido usada para desarrollar entornos de
desarrollo integrados (del inglés IDE), como el IDE de Java llamado Java
Development Toolkit (JDT) y el compilador (ECJ) que se entrega como
parte de Eclipse (y que son usados también para desarrollar el mismo

35
 Eclipse). Sin embargo, también se puede usar para otros tipos de
aplicaciones cliente, como BitTorrent o Azureus. [15]

Eclipse es también una comunidad de usuarios, extendiendo

constantemente las áreas de aplicación cubiertas. Un ejemplo es el
recientemente creado Eclipse Modeling Project, cubriendo casi todas las
áreas de Model Driven Engineering.

Eclipse fue desarrollado originalmente por IBM como el sucesor de su

familia de herramientas para VisualAge. Eclipse es ahora desarrollado por
la Fundación Eclipse, una organización independiente sin ánimo de lucro
que fomenta una comunidad de código abierto y un conjunto de productos
complementarios, capacidades y servicios.

2.2.3.2 SQL Developer

Oracle SQL Developer es un entorno de desarrollo integrado gratuito que

simplifica el desarrollo y gestión de base de datos Oracle. SQL Developer
ofrece un desarrollo completo de extremo a extremo de las aplicaciones
PL / SQL, una hoja de cálculo para ejecutar consultas y scripts, una
consola de DBA para la gestión de la base de datos, una interfaz de
informes, una solución completa de modelado de datos y una plataforma
de migración para mover el bases de datos a Oracle. [16]

2.2.3.3 Jdeveloper

Developer es un entorno de desarrollo integrado desarrollado por Oracle

Corporation para los lenguajes Java, HTML, XML, SQL, PL/SQL,
Javascript, PHP, Oracle ADF, UML y otros.

Es un software propietario pero gratuito desde 2005.

Las primeras versiones de 1998 estaban basadas en el entorno JBuilder

de Borland, pero desde la versión 9i de 2001 está basado en Java, no
estando ya relacionado con el código anterior de JBuilder. [17]

36
 2.2.4 Servidor de Aplicaciones

2.2.4.1 Aplication Server

Un servidor de aplicaciones es un producto a base de componente que se

encuentra en el nivel medio de una arquitectura centrada en el servidor.
Proporciona servicios de middleware para mantener la seguridad y el
estado, junto con acceso a los datos y la persistencia [18].

Servidores de aplicaciones Java se basan en Java ™ 2 Platform,

Enterprise Edition (J2EE ™). J2EE utiliza un modelo distribuido de
múltiples niveles. Este modelo incluye generalmente una capa cliente, una
etapa intermedia, y un nivel EIS. El nivel de cliente puede ser una o más
aplicaciones o navegadores. La Plataforma J2EE se encuentra en el nivel
medio y consiste en un servidor web y un servidor EJB. (Estos servidores
son también llamados "contenedores".) No puede haber sub-niveles
adicionales en el nivel medio. El Sistema de Información Empresarial (SIE)
tiene las aplicaciones, archivos y bases de datos existentes.

Para el almacenamiento de los datos de negocio, la plataforma J2EE

requiere una base de datos que sea accesible a través de la API JDBC,
SQLJ, o JDO. La base de datos puede ser accesible a partir de
componentes web, Enterprise Beans y componentes cliente de aplicación.

37
 Figura 13: Arquitectura - Aplication Server

Fuente: Service Architecture [18]

2.2.5 Herramienta de Metodología

2.2.5.1 Trello

Trello es una web libre basada en aplicaciones de gestión de proyectos

realizados por Fog Creek Software. [19]

38
 Trello utiliza un paradigma para la gestión de proyectos conocidos como
Kanban, un método que había sido originalmente popularizado por Toyota
en la década de 1980 para la gestión de la cadena de suministro. Los
proyectos están representados por tablas, que contienen listas
(correspondientes a las listas de tareas). Las listas contienen cartas (que
corresponde a las tareas).

Las tarjetas se supone que deben pasar de una lista a otra (a través de
arrastrar y soltar), por ejemplo, que refleja el flujo de una función desde la
idea hasta la ejecución. Los usuarios pueden ser asignados a las tarjetas.

Los usuarios y las juntas pueden ser agrupados en las organizaciones.

Trello opera un freemium modelo de negocio, además de ser objeto de

subvenciones cruzadas de otros productos de software de Fog Creek. Un
servicio básico se proporciona de forma gratuita a través de un Business
Class pagado por el servicio se puso en marcha recientemente en 2013.

Características:

Trello tiene soporte limitado para etiquetas, en forma de seis etiquetas de

colores que pueden ser renombrados. Tarjetas aceptan comentarios,
archivos adjuntos, votos, fechas y listas de control debido. Trello tiene una
API.

2.2.6 Programación

2.2.6.1 Lenguaje de Programación

Un lenguaje de programación" es un lenguaje diseñado para describir el

conjunto de acciones consecutivas que un equipo debe ejecutar. Por lo

39
 tanto, un lenguaje de programación es un modo práctico para que los
seres humanos puedan dar instrucciones a un equipo [20].

Por otro lado, el término "lenguaje natural" define un medio de

comunicación compartido por un grupo de personas (por ejemplo: inglés o
francés).

Los lenguajes que los equipos usan para comunicarse entre ellos no
tienen nada que ver con los lenguajes de programación; se los conoce
como protocolos de comunicación. Se trata de dos conceptos totalmente
diferentes. Un lenguaje de programación es muy estricto.

El lenguaje utilizado por el procesador se denomina lenguaje máquina. Se

trata de datos tal como llegan al procesador, que consisten en una serie
de 0 y 1 (datos binarios).

El lenguaje máquina, por lo tanto, no es comprensible para los seres

humanos, razón por la cual se han desarrollado lenguajes intermediarios
comprensibles para el hombre. El código escrito en este tipo de lenguaje
se transforma en código máquina para que el procesador pueda
procesarlo.

El ensamblador fue el primer lenguaje de programación utilizado. Es muy

similar al lenguaje máquina, pero los desarrolladores pueden
comprenderlo.

2.2.6.1.1 Java

Java es la base para prácticamente todos los tipos de aplicaciones de

red, además del estándar global para desarrollar y distribuir aplicaciones
móviles, juegos, contenido basado en web y software de empresa. Con
más de 9 millones de desarrolladores en todo el mundo, Java le permite
desarrollar, implementar y utilizar de forma eficaz interesantes
aplicaciones y servicios. [21]

40
 Desde portátiles hasta centros de datos, desde consolas para juegos
hasta súper computadoras, desde teléfonos móviles hasta Internet, Java
está en todas partes.

 1,100 millones de escritorios ejecutan Oracle Java

 930 millones de descargas de Java Runtime Environment cada
año
 mil millones de teléfonos móviles ejecutan Java
 Se entregan 31 veces más al año teléfonos Java que Apple y
Android juntos
 El 100% de los reproductores de Blu-ray ejecutan Java
 Se fabrican 1400 millones de tarjetas Java cada año

Java se incluye en decodificadores, impresoras, juegos, sistemas de

navegación en vehículos, cajeros automáticos, terminales de loterías,
dispositivos médicos, estaciones de pago de aparcamientos y mucho
más.

Java ha sido probado, ajustado, ampliado y probado por toda una

comunidad de desarrolladores, arquitectos de aplicaciones y entusiastas
de Java. Java está diseñado para permitir el desarrollo de aplicaciones
portátiles de elevado rendimiento para el más amplio rango de
plataformas informáticas posible. Al poner a disposición de todo el mundo
aplicaciones en entornos heterogéneos, las empresas pueden
proporcionar más servicios y mejorar la productividad, las
comunicaciones y colaboración del usuario final y reducir drásticamente
el costo de propiedad tanto para aplicaciones de usuario como de
empresa. Java se ha convertido en un valor impagable para los
desarrolladores, ya que les permite:

 Escribir software en una plataforma y ejecutarla virtualmente en

otra.

41
  Crear programas que se puedan ejecutar en un explorador y
acceder a servicios Web disponibles.
 Desarrollar aplicaciones de servidor para foros en línea,
almacenes, encuestas, procesamiento de formularios HTML y
mucho más.
 Combinar aplicaciones o servicios que utilizan el lenguaje Java
para crear aplicaciones o servicios con un gran nivel de
personalización.
 Escribir aplicaciones potentes y eficaces para teléfonos móviles,
procesadores remotos, productos de consumo y prácticamente
cualquier otro dispositivo electrónico.

2.2.6.2 Web Services

Un servicio web (en inglés, Web Service o Web services) es una

tecnología que utiliza un conjunto de protocolos y estándares que sirven
para intercambiar datos entre aplicaciones. [22]

Distintas aplicaciones de software desarrolladas en lenguajes de

programación diferentes, y ejecutadas sobre cualquier plataforma, pueden
utilizar los servicios web para intercambiar datos en redes de
ordenadores como Internet.

La interoperabilidad se consigue mediante la adopción de estándares

abiertos. Las organizaciones OASIS y W3C son los comités responsables
de la arquitectura y reglamentación de los servicios Web.

Para mejorar la interoperabilidad entre distintas implementaciones de

servicios Web se ha creado el organismo WS-I, encargado de desarrollar
diversos perfiles para definir de manera más exhaustiva estos estándares.
Es una máquina que atiende las peticiones de los clientes web y les envía
los recursos solicitados.

42
 Ventajas de los servicios web

 Aportan interoperabilidad entre aplicaciones de software

independientemente de sus propiedades o de las plataformas sobre
las que se instalen.
 Los servicios Web fomentan los estándares y protocolos basados
en texto, que hacen más fácil acceder a su contenido y entender su
funcionamiento.
 Permiten que servicios y software de diferentes compañías
ubicadas en diferentes lugares geográficos puedan ser combinados
fácilmente para proveer servicios integrados.

Razones para crear servicios Web

 La principal razón para usar servicios Web es que se pueden

utilizar con HTTP sobre TCP (Transmission Control Protocol) en
el puerto 80. Dado que las organizaciones protegen sus redes
mediante firewalls -que filtran y bloquean gran parte del tráfico de
Internet-, cierran casi todos los puertos TCP salvo el 80, que es,
precisamente, el que usan los navegadores. Los servicios Web
utilizan este puerto, por la simple razón de que no resultan
bloqueados. Es importante señalar que los servicios web se pueden
utilizar sobre cualquier protocolo, sin embargo, TCP es el más
común.
 Otra razón es que, antes de que existiera SOAP, no había buenas
interfaces para acceder a las funcionalidades de otros ordenadores
en red. Las que había eran ad hoc y poco conocidas, tales
como EDI (Electronic Data Interchange), RPC (Remote Procedure
Call), u otras APIs.
 Una tercera razón por la que los servicios Web son muy prácticos
es que pueden aportar gran independencia entre la aplicación que
usa el servicio Web y el propio servicio. De esta forma, los cambios

43
 a lo largo del tiempo en uno no deben afectar al otro. Esta
flexibilidad será cada vez más importante, dado que la tendencia a
construir grandes aplicaciones a partir de componentes distribuidos
más pequeños es cada día más utilizada.
 Se espera que para los próximos años mejoren la calidad y
cantidad de servicios ofrecidos basados en los nuevos estándares.

2.2.6.3 Bridge Drivers

JDBC es un API (Application programming interface) que describe o define

una librería estándar para acceso a fuentes de datos, principalmente
orientado a Bases de Datos relacionales que usan SQL (Structured Query
Language). JDBC no sólo provee un interfaz para acceso a motores de
bases de datos, sino que también define una arquitectura estándar, para
que los fabricantes puedan crear los drivers que permitan a las
aplicaciones JAVA el acceso a los datos. [23]

El API JDBC se presenta como una colección de interfaces Java y

métodos de gestión de manejadores de conexión hacia cada modelo
específico de base de datos. Un manejador de conexiones hacia un
modelo de base de datos en particular es un conjunto de clases
que implementan las interfaces Java y que utilizan los métodos de registro
para declarar los tipos de localizadores a base de datos (URL) que pueden
manejar.

Para utilizar una base de datos particular, el usuario ejecuta su programa

junto con la biblioteca de conexión apropiada al modelo de su base de
datos, y accede a ella estableciendo una conexión; para ello provee el
localizador a la base de datos y los parámetros de conexión específicos. A
partir de allí puede realizar cualquier tipo de tarea con la base de datos a
la que tenga permiso: consulta, actualización, creación, modificación y
borrado de tablas, ejecución de procedimientos almacenados en la base
de datos, etc.

44
 2.2.7 Herramientas de Monitoreo

2.2.7.1 New Relic

New Relic es un sistema de monitoreo que permite tener control en tiempo

real de los recursos disponibles. [24]

Entre sus funcionalidades tenemos lo siguiente:

 Informes de Implementación: Permite ver la imagen antes y

después de la actuación de su aplicación cuando se ha desplegado
un cambio. Rápidamente permite salir de un cambio antes de que
afecte a los usuarios en la producción.
 Rastreo de Transacciones: Ofrece visibilidad profunda en la causa
de los problemas de rendimiento de aplicaciones hasta el más
mínimo detalle. Obtener acceso a los diagnósticos a nivel de
código, así como seguimientos de pila completo.
 Monitorizar Conexiones HTTP: Tiempos de respuesta, mensajes de
error, número de peticiones, etc.
 Monitorizar Errores: Crash report cuando en la aplicación se
produzca algún fallo tanto de ejecución como con la conexión a
nuestra API
 Fijar alertas sobre umbrales de datos de referencia: tiempos de
respuesta, errores de autenticación, etc.
 Estadísticas del rendimiento de la aplicación en distintos
dispositivos. Conociendo los tiempos de ejecución, el uso de la
memoria o la velocidad de red.
 Estadísticas de los usuarios según las distintas versiones de
software del Sistema Operativo.

45
 2.2.8 ISO 3166-1 ALFA-2

ISO 3166-1 como parte del estándar ISO 3166 proporciona códigos para los
nombres de países y otras dependencias administrativas. Fue publicado por
primera vez en 1974 por la Organización Internacional para la
Normalización (ISO, de la raíz griega que significa igual) y define tres
códigos diferentes para cada área.

Normalizaciones derivadas de este código son y serán: [25]

 ISO 3166-1 numérico, sistema de tres dígitos, idéntico al definido por

la División Estadística de las Naciones Unidas.
 ISO 3166-1 alfa-3, sistema de códigos tres letras.
 ISO 3166-1 alfa-2, sistema de códigos de dos letras. Tiene muchas
aplicaciones, la más notoria en los dominios de nivel superior
geográfico de Internet. Normalizaciones derivadas de este último
código son:
 ISO 3166-2, códigos referidos a subdivisiones tales como estados y
provincias.
 ISO 3166-3, sustitutos de los códigos del sistema alpha-2 que han
quedado obsoletos.
 ISO 4217, códigos para unidades monetarias.

A un país o territorio generalmente se le asigna un nuevo código alfabético

si su nombre cambia, mientras que se asocia un nuevo código numérico a
un cambio de fronteras. Se reservan algunos códigos en cada área, por
diversas razones.

46
 Tabla 1: Códigos ISO de los países
Código Numérico Código (3 Letras) Código (2 letras) Código ISO País
32 ARG AR (ISO 3166-2) Argentina
68 BOL BO (ISO 3166-2) Bolivia
76 BRA BR (ISO 3166-2) Brasil
152 CHL CL (ISO 3166-2) Chile
170 COL CO (ISO 3166-2) Colombia
218 ECU EC (ISO 3166-2) Ecuador
724 ESP ES (ISO 3166-2) España
840 USA US (ISO 3166-2) Estados Unidos
380 ITA IT (ISO 3166-2) Italia
484 MEX MX (ISO 3166-2) México
600 PRY PY (ISO 3166-2) Paraguay
604 PER PE (ISO 3166-2) Perú
858 URY UY (ISO 3166-2) Uruguay
862 VEN VE (ISO 3166-2) Venezuela

Fuente: http://es.wikipedia.org/wiki/ISO_3166-1 [25]

47
 2.3 Marco Conceptual

2.3.1 Modelo Conceptual

Figura 14: Modelo Conceptual

Fuente: Elaboración Propia

En la Figura N° 14 se muestra el “Modelo Conceptual”, donde se describe el

proceso. Donde el vehículo se detiene y el conductor entrega sus
documentos al Policía de Tránsito, el policía pasara a registrar la papeleta
al conductor por la infracción cometida,

2.3.2 DIVPOLTRAN (División de Policía de Tránsito):

La División de Policía de Tránsito (DIVPOLTRAN) como órgano altamente

especializado, es la encargada de hacer cumplir las leyes, fiscalizando su
cumplimiento, garantizando y regulando el tránsito en las vías
denominadas “Vías Rápidas” (vías expresas, corredores viales, vías
troncales, etc), asegurar el transporte automotor y ferroviario y la
prevención e investigación de accidentes de tránsito y el robo de vehículos;
a fin de proteger a la persona, los bienes públicos y privados; contribuyendo
al desarrollo económico y social del país con la participación ciudadana. [26]

La División de Policía de Tránsito, realizará estudios y análisis de la

problemática del tránsito, con el fin de controlar y contrarrestar el
48
 congestionamiento vehicular y disminuir el índice de accidentes de tránsito,
así como los accidentes y hechos delictivos en las vías férreas, optimizando
los servicios que se prestan a la comunidad.

Funciones de la DIVPOLTRAN:

 Planear, organizar, dirigir, controlar y ejecutar el cumplimiento de

las funciones policiales de Tránsito, así como las Leyes,
Reglamentos y Dispositivos en vigencia, por intermedio de sus
Organismos Ejecutivos.
 Planear, organizar, dirigir, controlar y ejecutar las actividades
asignadas a las Áreas de Administración de Personal, Inteligencia,
Operaciones, Instrucción y Logística.
 Mantener el libre tránsito de vehículos, pasajeros y carga en las
vías públicas, urbanas y férreas.
 Controlar el tránsito vehicular y dar seguridad en las vías urbanas y
vías férreas.
 Prevenir e investigar los accidentes de tránsito y el robo de
vehículos.
 Proponer al Comando Institucional, normas y directivas
relacionadas con la disminución de la problemática del tránsito y
seguridad vial.
 Mantener buenas relaciones con las Autoridades del sector público
y privado, para lograr la colaboración en el ejercicio de sus
funciones.

49
 Figura 15: Organigrama del Ministerio del Interior

Fuente: Ministerio del Interior [27]

50
 La DIVPOLTRAN es un área perteneciente a la Policía Nacional del Perú
(PNP) y la PNP pertenece al Ministerio del Interior como se muestra en la

Figura 16: Organigrama de la Policía Nacional del Perú

Figura N° 15.

Fuente: Policía Nacional del Perú [28]

51
 En la figura N°16 se visualiza el Organigrama de la Policía Nacional del
Perú, donde la dirección de la Policía de Tránsito se encuentra dentro de la
Dirección Ejecutiva de Transito y Seguridad Vial.

2.3.3 SAT

El SAT es un organismo público descentralizado de la Municipalidad

Metropolitana de Lima, con autonomía administrativa, económica,
presupuestaria y financiera; que tiene por finalidad organizar y ejecutar la
administración, fiscalización y recaudación de todos los ingresos tributarios
y no tributarios de la Municipalidad. En tal virtud, se encuentra facultado
para aprobar su organización interna [29].

Las funciones y responsabilidades del SAT son las siguientes:

 Promover la Política tributaria de la Municipalidad

 Individualizar al sujeto pasivo de las obligaciones tributarias
municipales.
 Determinar y liquidar la deuda tributaria
 Recaudar los ingresos municipales por concepto de impuestos,
contribuciones y tasas, así como multas de tránsito y multas
administrativas
 Fiscalizar el correcto cumplimiento de las obligaciones tributarias.
 Conceder aplazamiento o fraccionamiento de la deuda tributaria
 Resolver los reclamos que los contribuyentes presenten contra actos
de la administración tributaria provincial y de las administraciones
tributarias distritales.
 Realizar la ejecución coactiva para el cobro de las deudas tributarias,
considerando todas aquellas deudas derivadas de obligaciones
tributarias municipales, así como el cobro de multas y otros ingresos
de derecho público.

52
  Informar adecuadamente a los contribuyentes sobre las normas y
procedimientos que deben observar para cumplir con sus
obligaciones.
 Sancionar el incumplimiento de las obligaciones tributarias,
 Elaborar las estadísticas tributarias
 Desarrollar labores de consultorías, asesorías u otros similares de
apoyo para una eficiente gestión en la administración tributaria y/o no
tributaria celebrando convenios de cooperación técnica con
Municipalidades, Regiones o Entidades Públicas, con cargo a dar
cuenta al Concejo Metropolitano.
 Celebrar convenios de cooperación técnica con Municipalidades,
Regiones o Entidades públicas para encargarse de la administración,
y/o recaudación de ingresos tributarios y no tributarios, previa
aprobación del Concejo Metropolitano.
 Las demás que le asigne su estatuto que será aprobado por el
Concejo Metropolitano y que están compatibles con la finalidad de la
Institución. Al respecto el Reglamento de Organizaciones y
Funciones vigente establece la finalidad y funciones generales del
SAT en sus artículos 1° y 2°.

2.3.4 MTC

El Ministerio de Transportes y Comunicaciones del Perú es el órgano

del Estado Peruano que busca lograr un racional ordenamiento territorial
vinculado a las áreas de recursos, producción, mercados y centros
poblados, a través de la regulación, promoción, ejecución y supervisión de
la infraestructura de transportes y comunicaciones [30].

Las funciones y responsabilidades del MTC son las siguientes:

 Diseñar, normar y ejecutar la política de promoción y desarrollo en

materia de Transportes y Comunicaciones.
 Formular los planes nacionales sectoriales de desarrollo.

53
  Fiscalizar y supervisar el cumplimiento del marco normativo
relacionado con su ámbito de competencia.
 Otorgar y reconocer derechos a través de autorizaciones, permisos,
licencias y concesiones.
 Orientar en el ámbito de su competencia el funcionamiento de los
Organismos Públicos Descentralizados, Comisiones
 Sectoriales y Multisectoriales y Proyectos o entidades similares que
los sustituyan. 4
 Planificar, promover y administrar la provisión y prestación de servicios
públicos, de acuerdo a las leyes de la materia.
 Cumplir funciones ejecutivas en todo el territorio nacional directamente
o mediante proyectos especiales o entidades similares que los
sustituyan respecto a las actividades que se señalan en el presente
Reglamento de Organización y Funciones.

2.3.5 SUNARP

La SUNARP es un organismo descentralizado autónomo de Sector Justicia

y ente rector del Sistema Nacional de los Registros Públicos, y tiene entre
sus principales funciones y atribuciones el de dictar las políticas y normas
técnico - registrales de los registros públicos que integran el Sistema
Nacional, planificar y organizar, normar, dirigir, coordinar y supervisar la
inscripción y publicidad de actos y contratos en los Registros que
conforman el Sistema. [31]

2.3.6 Touring

El Touring una asociación sin fines de lucro fundada el 20 de mayo de 1924

con la finalidad de fomentar y servir al turismo, automovilismo y actividades
vinculadas para el beneficio del país, de la colectividad y en particular de
sus asociados.

La organización está construida en base a valores y políticas orientadas a la

calidad, garantía y seguridad. Tenemos más de 90 años de experiencia en

54
 la atención al asociado y en el 2008 hemos logrado la Certificación de
Calidad ISO 9001:2008, para los Servicios Integrales de Asistencia y
Central de Contactos, lo que nos permite distinguirnos en el mercado. [32].

Valores:

 Excelencia en la calidad del servicio, desarrollando una autentica

mística de calidad total.
 Orientación hacia la optimización de los procesos operativos y la
innovación en los servicios, basados en las Tecnologías de
Información.
 Potenciación del capital humano mediante una política orientada a
motivar y comprometer al personal para mantener un espíritu de
colaboración permanente, estableciendo una retribución salarial en
función a la creatividad, el esfuerzo y el buen desempeño laboral.
 Actividades enmarcadas en la proactividad y eficiencia comercial, así
como en la ética y en las Normas Legales vigentes.
 Somos una empresa de servicios. Tratemos tanto a los asociados y
colectivos como nos gustaría ser tratados.
 El trabajo en equipo unido a la vocación de servicio garantiza el éxito
en el desarrollo de nuestro servicio.
 Fomentamos la creatividad: No tenemos miedo al error, somos
agresivos en creatividad pero prudentes en la implementación.
 Ilusión y trabajo son la base de la buena gestión.

2.3.7 Sistema Web Movil

La web móvil es una tendencia creciente que se refiere a los usuarios que
acceden a las aplicaciones de Internet de forma inalámbrica y basada en la
Web a través de un dispositivo móvil, como un teléfono inteligente, Tablet o
PC personal. Se llama la Web móvil ya que los usuarios tienden a acceder
a él, mientras que en el ir y quieren tener acceso inmediato a la información,
como el correo electrónico, sitios de redes sociales o las compras de

55
 productos. Con el rápido crecimiento de la popularidad de los teléfonos
inteligentes habilitados para Web y Tablet PC, la web móvil está creciendo
exponencialmente [33].

Gracias a la funcionalidad avanzada de los modernos dispositivos móviles y

la conectividad más rápida, junto con aplicaciones diseñadas
específicamente para la web móvil y sitios web diseñados específicamente
para dispositivos móviles, la gente puede realizar una amplia gama de
actividades en sus dispositivos. Estos incluyen el acceso a correo
electrónico, leer periódicos y revistas , ir de compras y comprar artículos en
tiendas en línea , acceder a sitios de redes sociales , banca online, ver
videos en línea , comprobando los resultados deportivos , seguimiento de
los precios de acciones y muchos otros usos.

Los Sistemas Web multiplataforma se ejecutan directamente en cualquier

plataforma sin una preparación previa especial.

2.3.8 Sistemas Distribuidos

Un sistema distribuido es aquel en el que dos o más máquinas colaboran

para la obtención de un resultado. En todo sistema distribuido se establecen
una o varias comunicaciones siguiendo un protocolo prefijado mediante un
esquema cliente-servidor [34].

Por extensión, se puede aplicar el esquema cliente-servidor dentro de una

misma máquina, donde el proceso servidor y el proceso cliente son dos
procesos independientes que corren dentro de la misma instancia de
sistema operativo.

Es por tanto un elemento primordial para que haya un sistema distribuido, la

presencia de un medio físico de comunicación entre ambas máquinas, y
será la naturaleza de este medio la que marque en muchos casos la
viabilidad del sistema.

56
 Se clasifican los sistemas cliente servidor de acuerdo al nivel de abstracción
del servicio que se ofrece. Se distinguen tres componentes básicos de
software:

 Interacción con el usuario

 Lógica de Aplicación
 Repositorio de datos

Ventajas del uso de Sistemas Distribuidos: [35]

 Economía: Buena relación rendimiento/coste: Avances en

tecnología de microprocesadores y redes de área local.
 Alto rendimiento: Procesamiento paralelo.
 Soporte de aplicaciones inherentemente distribuidas: Por ejemplo:
empresa distribuida geográficamente
 Capacidad de crecimiento: Escalabilidad.
 Fiabilidad y disponibilidad: Tolerancia a fallos.
 Carácter abierto y heterogéneo: Estándares de interoperabilidad.
 Compartir recursos y datos.

2.3.9 SOA

La 'Arquitectura Orientada a Servicios de cliente' (en

inglés Service Oriented Architecture), es un concepto de arquitectura de
software que define la utilización de servicios para dar soporte a los
requisitos del negocio.

Permite la creación de sistemas de información altamente escalables que

reflejan el negocio de la organización, a su vez brinda una forma bien
definida de exposición e invocación de servicios (comúnmente pero no
exclusivamente servicios web), lo cual facilita la interacción entre diferentes
sistemas propios o de terceros. [36]

57
 SOA define las siguientes capas de software:

 Aplicaciones básicas - Sistemas desarrollados bajo cualquier

arquitectura o tecnología, geográficamente dispersos y bajo cualquier
figura de propiedad.
 De exposición de funcionalidades - Donde las funcionalidades de la
capa aplicativa son expuestas en forma de servicios (generalmente
como servicios web).
 De integración de servicios - Facilitan el intercambio de datos entre
elementos de la capa aplicativa orientada a procesos empresariales
internos o en colaboración.
 De composición de procesos - Que define el proceso en términos del
negocio y sus necesidades, y que varía en función del negocio.
 De entrega - donde los servicios son desplegados a los usuarios
finales.

SOA proporciona una metodología y un marco de trabajo para documentar

las capacidades de negocio y puede dar soporte a las actividades de
integración y consolidación.

Diseño y desarrollo de SOA:

La metodología de modelado y diseño para aplicaciones SOA se conoce

como análisis y diseño orientado a servicios. La arquitectura orientada a
servicios es tanto un marco de trabajo para el desarrollo de software como
un marco de trabajo de implementación. Para que un proyecto SOA tenga
éxito los desarrolladores de software deben orientarse ellos mismos a esta
mentalidad de crear servicios comunes que son orquestados por clientes o
middleware para implementar los procesos de negocio. El desarrollo de
sistemas usando SOA requiere un compromiso con este modelo en
términos de planificación, herramientas e infraestructura.

58
 Cuando la mayoría de la gente habla de una arquitectura orientada a
servicios están hablando de un juego de servicios residentes en Internet o
en una intranet, usando servicios web. Existen diversos estándares
relacionados a los servicios web. Incluyen los siguientes:

 XML
 HTTP
 SOAP
 REST
 WSDL

 UDDI

Hay que considerar, sin embargo, que un sistema SOA no necesariamente

utiliza estos estándares para ser "Orientado a Servicios" pero es altamente
recomendable su uso.

En un ambiente SOA, los nodos de la red hacen disponibles sus recursos a

otros participantes en la red como servicios independientes a los que tienen
acceso de un modo estandarizado. La mayoría de las definiciones de SOA
identifican la utilización de Servicios Web (empleando SOAP y WSDL) en
su implementación, no obstante se puede implementar SOA utilizando
cualquier tecnología basada en servicios.

Beneficios:

Los beneficios que puede obtener una organización que adopte SOA son:

 Mejora en los tiempos de realización de cambios en procesos.

 Facilidad para evolucionar a modelos de negocios basados en
tercerización.
 Facilidad para abordar modelos de negocios basados en
colaboración con otros entes (socios, proveedores).
 Poder para reemplazar elementos de la capa aplicativa SOA sin
disrupción en el proceso de negocio.

59
  Facilidad para la integración de tecnologías disímiles.

2.3.10 BPEL

BPEL también conocido como Business Process Execution Language es un

lenguaje diseñado por la organización OASIS la cual se encarga de definir
estándares a nivel mundial, Este lenguaje está definido en XML y está
diseñado para orquestar procesos de forma automática [37].

Se le llama Orquestar porque BPEL es el encargado de consumir varios

servicios en un orden especificado y realizar una función muy concreta.

Caso - Agencia de viaje: Imagínate que entras a una página de agencia de

viaje en la cual puedes comprar un paquete que incluye boletos de avión y
hotel. Lo único que tenemos que hacer nosotros es decir a donde queremos
con la fecha y la agencia de viaje nos arrojara los paquetes con un precio y
solo tenemos que pagar con nuestra tarjeta de crédito para que nuestra
reservación quede lista.

Una vez que confirmamos nuestra compra la agencia de viaje tendrá que
hacer algunas operaciones que no dependen de ella como seria reservar el
boleto de avión con la aerolínea, reservar los día del cuarto directamente
con el Hotel, Hacer un cargo por el porcentaje que gana la agencia por
realizar la venta y por ultimo guardar en el sistema de la agencia el registro
de la venta.

2.3.11 Enterprise Service Bus

En informática un bus de servicios de empresa (ESB) consiste en un

combinado de arquitectura de software que proporciona servicios
fundamentales para arquitecturas complejas a través de un sistema de
mensajes (el bus) basado en las normas y que responde a eventos. Los
desarrolladores normalmente implementan un ESB utilizando tecnologías
de productos de infraestructura de middleware que se basan en normas
reconocidas.

60
 Un ESB generalmente proporciona una capa de abstracción construida
sobre una implementación de un sistema de mensajes de empresa que
permita a los expertos en integración explotar el valor del envío de
mensajes sin tener que escribir código. Al contrario que sucede con la
clásica integración de aplicaciones de empresa (IAE) que se basa en una
pila monolítica sobre una arquitectura hub and spoke, un bus de servicio de
empresa se construye sobre unas funciones base que se dividen en sus
partes constituyentes, con una implantación distribuida cuando se hace
necesario, de modo que trabajen armoniosamente según la demanda [38].

Un ESB ofrece las siguientes funcionalidades:

 Transparencia de Ubicación: El ESB ayuda a desligar el consumidor

del servicio de la ubicación del proveedor del servicio. El ESB provee
una plataforma central para comunicarse con cualquier aplicación
requerida sin ligar el recibidor del mensaje con el que envía el
mensaje.
 Conversión de Protocolo de Transporte: Un ESB debe de tener la
capacidad de integrar de forma transparente a través de diferentes
protocolos de transporte tales como HTTP(s), JMS, FTP, SMTP, TCP,
etc.
 Transformación de Mensaje: El ESB brinda funcionalidad para
transformar mensajes desde un formato hasta otro formato basado en
estándares tales como XSLT y XPath.
 Ruteo de Mensajes: El ESB determina el destino de los mensajes
entrantes.
 Mejora del Mensaje: El ESB puede brindar funcionalidad para agregar
información faltante basada en los datos del mensaje de entrada.
 Seguridad: Autenticación, autorización, y funcionalidad de encriptación
se proveen a través del ESB para asegurar los mensajes entrantes.
Igualmente estas funcionalidades se aplican a mensajes salientes

61
 para satisfacer requerimientos de seguridad del proveedor del servicio
a consumir.
 Monitoreo y Administración: Un ambiente de monitoreo y
administración del ESB es fundamental para configurar el ESB para
que sea confiable y tenga un alto desempeño; al mismo tiempo, nos
permite monitorear la ejecución de los mensajes y su flujo dentro del
ESB.

La arquitectura distribuida del ESB, proporciona integración flexible de

servicios y aplicaciones distribuidas dentro de una arquitectura SOA,
combinando servicios de integración escalables independientemente y un
enrutamiento inteligente. Los clientes utilizan el ESB para reducir el tiempo
de ciclo del proceso, recopilar y difundir información y responder de manera
fiable a las condiciones comerciales a medida que se producen. El ESB
permite crear servicios en los que los arquitectos pueden manejar más
fácilmente la arquitectura SOA desde cualquier punto [39].

Figura 17: Arquitectura Enterprise Service Bus

Fuente: KAF Consulting [39]

2.3.12 Metodología

62
 Las metodologías de desarrollo de software son un conjunto de
procedimientos, técnicas y ayudas a la documentación para el desarrollo de
productos software.

Es como un libro de recetas de cocina, en el que se van indicando paso a

paso todas las actividades a realizar para lograr el producto informático
deseado, indicando además qué personas deben participar en el desarrollo
de las actividades y qué papel deben de tener. Además detallan la
información que se debe producir como resultado de una actividad y la
información necesaria para comenzarla [40].

Actualmente es imprescindible considerar los riesgos, aunque

habitualmente las empresas, no han sido concienciadas de los riesgos
inherentes al procesamiento de la información mediante ordenadores, a lo
que han contribuido, a veces, los propios responsables de informática, que
no han sabido explicar con la suficiente claridad las consecuencias de una
política de seguridad insuficiente o incluso inexistente. Por otro lado, debido
a una cierta deformación profesional en la aplicación de los criterios de
coste/beneficio, el directivo desconocedor de la informática no acostumbra
a autorizar inversiones que no lleven implícito un beneficio demostrable,
tangible y mensurable.

Las técnicas indican cómo debe ser realizada una actividad técnica
determinada identificada en la metodología. Combina el empleo de unos
modelos o representaciones gráficas junto con el empleo de unos
procedimientos detallados. Se debe tener en consideración que una técnica
determinada puede ser utilizada en una o más actividades de la
metodología de desarrollo de software. Además se debe tener mucho
cuidado cuando se quiere cambiar una técnica por otra

2.3.12.1 RUP

El Proceso Unificado Racional, Rational Unified Process (RUP), es un

proceso de desarrollo de software y junto con el Lenguaje Unificado de

63
 Modelado (UML), constituye la metodología estándar más utilizada para el
análisis, implementación y documentación de sistemas orientados a
objetos.

El RUP no es un sistema con pasos firmemente establecidos, sino que

trata de un conjunto de metodologías adaptables al contexto y
necesidades de cada organización, donde el software es organizado como
una colección de unidades atómicas llamados objetos, constituidos por
datos y funciones, que interactúan entre sí [41].

Características:

 Describir la organización, documentación, funcionalidad y

restricciones de un software.
 Forma disciplinada de asignar tareas y responsabilidades (quién
hace qué, cuándo y cómo)
 Pretende implementar las mejores prácticas en Ingeniería de
Software
 Desarrollo iterativo
 Administración de requisitos
 Uso de arquitectura basada en componentes
 Control de cambios
 Modelado visual del software
 Verificación de la calidad del software

Implementar los diferentes diagramas de UML, dando paso a la reducción

de tiempo a la hora de desarrollar un software.

Fases:

RUP se divide en 4 fases, dentro de las cuales se realizan varias

iteraciones según el proyecto y en las que se hace mayor o menor esfuerzo
en las distintas actividades (Zamora Salcedo, y otros, 2010). En las

64
 iteraciones de cada fase se hacen diferentes esfuerzos en diferentes
actividades:

a) Fase de Inicio (Inspección y Concepción):

El objetivo general de esta fase es establecer un acuerdo entre

todos los interesados acerca de los objetivos del proyecto. Esta
fase es significativamente primaria para el desarrollo de nuevo
software, ya que se asegura de identificar los riesgos relacionados
con el negocio y requerimientos. Para proyectos de mejora de
software existente esta fase es más breve y se centra en asegurar
que vale la pena y es posible, desarrollar el proyecto.

b) Fase de Elaboración:

El objetivo en esta fase es establecer la arquitectura base del

sistema para proveer bases estables para el esfuerzo de diseño e
implementación en la siguiente fase. La arquitectura debe abarcar
todas las consideraciones de mayor importancia de los
requerimientos y una evaluación del riesgo.

c) Fase de Construcción:

El objetivo de la fase de construcción es clarificar los requerimientos

faltantes y completar el desarrollo del sistema basados en la
arquitectura base. Vista de cierta forma esta fase es un proceso de
manufactura, en el cual el énfasis se torna hacia la administración de
recursos y control de las operaciones para optimizar costos, tiempo
y calidad.

65
 d) Fase de Transición:

Esta fase se enfoca en asegurar que el software esté disponible

para sus usuarios. Esta fase se puede subdividir en varias
iteraciones, además incluye pruebas del producto para poder hacer
el entregable del mismo, así como realizar ajuste menores de
acuerdo a ajuste menores propuestos por el usuario. En este punto,
la retroalimentación de los usuarios se centra en depurar el
producto, configuraciones, instalación y aspectos sobre utilización.

Ver Figura N°17 donde se observan las interacciones entre las

etapas de RUP.

Figura 18: Ciclo de vida de la Metodología RUP

Fuente: AnalisiDAID [41]

66
 2.4 Marco Metodológico
Scrum es un proceso en el que se aplican de manera regular un conjunto
de buenas prácticas para trabajar colaborativamente, en equipo, y obtener el
mejor resultado posible de un proyecto. Estas prácticas se apoyan unas a otras
y su selección tiene origen en un estudio de la manera de trabajar de equipos
altamente productivos. [42]

En Scrum se realizan entregas parciales y regulares del producto final,

priorizadas por el beneficio que aportan al receptor del proyecto. Por ello, Scrum
está especialmente indicado para proyectos en entornos complejos, donde se
necesita obtener resultados pronto, donde los requisitos son cambiantes o poco
definidos, donde la innovación, la competitividad, la flexibilidad y la productividad
son fundamentales.

Scrum también se utiliza para resolver situaciones en que no se está entregando

al cliente lo que necesita, cuando las entregas se alargan demasiado, los costes
se disparan o la calidad no es aceptable, cuando se necesita capacidad de
reacción ante la competencia, cuando la moral de los equipos es baja y la
rotación alta, cuando es necesario identificar y solucionar ineficiencias
sistemáticamente o cuando se quiere trabajar utilizando un proceso
especializado en el desarrollo de producto.

El proceso

En Scrum un proyecto se ejecuta en bloques temporales cortos y fijos

(iteraciones de un mes natural y hasta de dos semanas, si así se necesita).

67
 Cada iteración tiene que proporcionar un resultado completo, un incremento de
producto final que sea susceptible de ser entregado con el mínimo esfuerzo al
cliente cuando lo solicite.

Figura 19: Proceso de la metodología SCRUM

Fuente: Metodologías Ágiles [42]

El proceso parte de la lista de objetivos/requisitos priorizada del producto, que

actúa como plan del proyecto. En esta lista el cliente prioriza los objetivos
balanceando el valor que le aportan respecto a su coste y quedan repartidos en
iteraciones y entregas. De manera regular el cliente puede maximizar la utilidad
de lo que se desarrolla y el retorno de inversión mediante la replanificación de
objetivos del producto, que realiza durante la iteración con vista a las siguientes
iteraciones.

Actividades:

Planificación de la iteración

El primer día de la iteración se realiza la reunión de planificación de la iteración.

Tiene dos partes:

68
 1. Selección de requisitos (4 horas máximo). El cliente presenta al equipo la
lista de requisitos priorizada del producto o proyecto. El equipo pregunta al
cliente las dudas que surgen y selecciona los requisitos más prioritarios que se
compromete a completar en la iteración, de manera que puedan ser entregados
si el cliente lo solicita.

2. Planificación de la iteración (4 horas máximo). El equipo elabora la lista de

tareas de la iteración necesarias para desarrollar los requisitos a que se ha
comprometido. La estimación de esfuerzo se hace de manera conjunta y los
miembros del equipo se auto asignan las tareas.

Ejecución de la iteración

Cada día el equipo realiza una reunión de sincronización (15 minutos máximos).
Cada miembro del equipo inspecciona el trabajo que el resto está realizando
(dependencias entre tareas, progreso hacia el objetivo de la iteración,
obstáculos que pueden impedir este objetivo) para poder hacer las
adaptaciones necesarias que permitan cumplir con el compromiso adquirido. En
la reunión cada miembro del equipo responde a tres preguntas:

 ¿Qué he hecho desde la última reunión de sincronización?

 ¿Qué voy a hacer a partir de este momento?
 ¿Qué impedimentos tengo o voy a tener?

Durante la iteración el Facilitador se encarga de que el equipo pueda cumplir

con su compromiso y de que no se merme su productividad.

 Elimina los obstáculos que el equipo no puede resolver por sí

mismo.
 Protege al equipo de interrupciones externas que puedan afectar su
compromiso o su productividad.

Inspección y adaptación

69
 El último día de la iteración se realiza la reunión de revisión de la iteración.
Tiene dos partes:

1. Demostración (4 horas máximo). El equipo presenta al cliente los

requisitos completados en la iteración, en forma de incremento de
producto preparado para ser entregado con el mínimo esfuerzo. En
función de los resultados mostrados y de los cambios que haya habido
en el contexto del proyecto, el cliente realiza las adaptaciones
necesarias de manera objetiva, ya desde la primera iteración,
replanificando el proyecto.
2. Retrospectiva (4 horas máximo). El equipo analiza cómo ha sido su
manera de trabajar y cuáles son los problemas que podrían impedirle
progresar adecuadamente, mejorando de manera continua su
productividad. El Facilitador se encargará de ir eliminando los
obstáculos identificados.

70
 2.5 Marco Legal
2.5.1 Ley de Transparencia y Acceso a la Información Pública

Artículo 1º.- Alcance de la Ley

La presente Ley tiene por finalidad promover la transparencia de los actos

del Estado y regular el derecho fundamental del acceso a la información
consagrado en el numeral 5 del Artículo 2° de la Constitución Política del
Perú [43].

El derecho de acceso a la información de los Congresistas de la República

se rige conforme a lo dispuesto por la Constitución Política del Perú y el
Reglamento del Congreso.

Artículo 2º.- Entidades de la Administración Pública

Para efectos de la presente Ley se entiende por entidades de la

Administración Pública a las señaladas en el Artículo I del Título Preliminar
de la Ley Nº 27444, Ley del Procedimiento Administrativo General.

Artículo 3º.- Principio de publicidad

Todas las actividades y disposiciones de las entidades comprendidas en la

presente Ley están sometidas al principio de publicidad. Los funcionarios
responsables de brindar la información correspondiente al área de su
competencia deberán prever una adecuada infraestructura, así como la

71
 organización, sistematización y publicación de la información a la que se
refiere esta Ley.

En consecuencia:

1. Toda información que posea el Estado se presume pública, salvo las

excepciones expresamente previstas por el Artículo 15º de la
presente Ley.
2. El Estado adopta medidas básicas que garanticen y promuevan la
transparencia en la actuación de las entidades de la Administración
Pública.
3. El Estado tiene la obligación de entregar la información que
demanden las personas en aplicación del principio de publicidad. La
entidad pública designará al funcionario responsable de entregar la
información solicitada.

Artículo 4º.- Responsabilidades y Sanciones

Todas las entidades de la Administración Pública quedan obligadas a

cumplir lo estipulado en la presente norma.

Los funcionarios o servidores públicos que incumplieran con las

disposiciones a que se refiere esta Ley serán sancionados por la comisión
de una falta grave, pudiendo ser incluso denunciados penalmente por la
comisión de delito de Abuso de Autoridad a que hace referencia el Artículo
377° del Código Penal.

El cumplimiento de esta disposición no podrá dar lugar a represalias contra

los funcionarios responsables de entregar la información solicitada.

Artículo 5º.- Publicación en los portales de las dependencias públicas

Las entidades de la Administración Pública establecerán progresivamente,

de acuerdo a su presupuesto, la difusión a través de Internet de la siguiente
información:

72
 1. Datos generales de la entidad de la Administración Pública que
incluyan principalmente las disposiciones y comunicados emitidos, su
organización, organigrama, procedimientos, el marco legal al que
está sujeta y el Texto Único Ordenado de Procedimientos
Administrativos, que la regula, si corresponde.
2. La información presupuestal que incluya datos sobre los
presupuestos ejecutados, proyectos de inversión, partidas salariales
y los beneficios de los altos funcionarios y el personal en general, así
como sus remuneraciones.
3. Las adquisiciones de bienes y servicios que realicen. La publicación
incluirá el detalle de los montos comprometidos, los proveedores, la
cantidad y calidad de bienes y servicios adquiridos.
4. Actividades oficiales que desarrollarán o desarrollaron los altos
funcionarios de la respectiva entidad, entendiéndose como tales a los
titulares de la misma y a los cargos del nivel subsiguiente.
5. La información adicional que la entidad considere pertinente.

Lo dispuesto en este artículo no exceptúa de la obligación a la que se

refiere el Título IV de esta Ley relativo a la publicación de la información
sobre las finanzas públicas.

La entidad pública deberá identificar al funcionario responsable de la

elaboración de los portales de Internet.

Artículo 6º.- De los plazos de la implementación

1. Las entidades públicas deberán contar con portales en Internet en

los plazos que a continuación se indican:
2. Entidades del Gobierno Central, organismos autónomos y
descentralizados, a partir del 1 de julio de 2003.
3. Gobiernos Regionales, hasta un año después de su instalación.
4. Entidades de los Gobiernos Locales Provinciales y organismos
desconcentrados a nivel provincial, hasta un año desde el inicio del

73
 nuevo período municipal, salvo que las posibilidades tecnológicas y/o
presupuestales hicieran imposible su instalación.
5. Entidades de los Gobiernos Locales Distritales, hasta dos años
contados desde el inicio del nuevo período municipal, salvo que las
posibilidades tecnológicas y/o presupuestales hicieran imposible su
instalación.
6. Entidades privadas que presten servicios públicos o ejerzan
funciones administrativas, hasta el 1 de julio de 2003. Las
autoridades encargadas de formular los presupuestos tomarán en
cuenta estos plazos en la asignación de los recursos
correspondientes.

Artículo 7.- Legitimación y requerimiento inmotivado

Toda persona tiene derecho a solicitar y recibir información de cualquier

entidad de la Administración Pública. En ningún caso se exige expresión de
causa para el ejercicio de este derecho.

Artículo 8.- Entidades obligadas a informar

Las entidades obligadas a brindar información son las señaladas en el

artículo 2 de la presente Ley.

Dichas entidades identificarán, bajo responsabilidad de su máximo

representante, al funcionario responsable de brindar información solicitada
en virtud de la presente Ley. En caso de que éste no hubiera sido
designado las responsabilidades administrativas y penales recaerán en el
secretario general de la institución o quien haga sus veces.

Las empresas del Estado están sujetas al procedimiento de acceso a la

información establecido en la presente Ley.

Artículo 9.- Personas jurídicas sujetas al régimen privado que prestan

servicios públicos

74
 Las personas jurídicas sujetas al régimen privado descritas en el inciso 8)
del Artículo I del Título Preliminar de la Ley Nº 27444 que gestionen
servicios públicos o ejerzan funciones administrativas del sector público
bajo cualquier modalidad están obligadas a informar sobre las
características de los servicios públicos que presta, sus tarifas y sobre las
funciones administrativas que ejerce.

Artículo 10.- Información de acceso público

Las entidades de la Administración Pública tienen la obligación de proveer

la información requerida si se refiere a la contenida en documentos escritos,
fotografías, grabaciones, soporte magnético o digital, o en cualquier otro
formato, siempre que haya sido creada u obtenida por ella o que se
encuentre en su posesión o bajo su control.

Asimismo, para los efectos de esta Ley, se considera como información

pública cualquier tipo de documentación financiada por el presupuesto
público que sirva de base a una decisión de naturaleza administrativa, así
como las actas de reuniones oficiales.

Artículo 11.- Procedimiento

El acceso a la información pública se sujeta al siguiente procedimiento:

1. Toda solicitud de información debe ser dirigida al funcionario

designado por la entidad de la Administración Pública para realizar
esta labor. En caso de que éste no hubiera sido designado, la
solicitud se dirige al funcionario que tiene en su poder la información
requerida o al superior inmediato.
2. La entidad de la Administración Pública a la cual se haya presentado
la solicitud de información deberá otorgarla en un plazo no mayor de
siete (7) días útiles; plazo que se podrá prorrogar en forma
excepcional por cinco (5) días útiles adicionales, de mediar
circunstancias que hagan inusualmente difícil reunir la información

75
 solicitada. En este caso, la entidad deberá comunicar por escrito,
antes del vencimiento del primer plazo, las razones por las que hará
uso de tal prórroga, de no hacerlo se considera denegado el pedido.
En el supuesto de que la entidad de la Administración Pública no
posea la información solicitada y de conocer su ubicación y destino,
esta circunstancia deberá ser puesta en conocimiento del solicitante.
3. La denegatoria al acceso a la información se sujeta a lo dispuesto en
el segundo párrafo del artículo 13 de la presente Ley.
4. De no mediar respuesta en los plazos previstos en el inciso b), el
solicitante puede considerar denegado su pedido.
5. En los casos señalados en los incisos c) y d) del presente artículo, el
solicitante puede considerar denegado su pedido para los efectos de
dar por agotada la vía administrativa, salvo que la solicitud haya sido
cursada a un órgano sometido a superior jerarquía, en cuyo caso
deberá interponer el recurso de apelación para agotarla.
6. Si la apelación se resuelve en sentido negativo, o la entidad
correspondiente no se pronuncia en un plazo de diez (10) días útiles
de presentado el recurso, el solicitante podrá dar por agotada la vía
administrativa.
7. Agotada la vía administrativa, el solicitante que no obtuvo la
información requerida podrá optar por iniciar el proceso contencioso
administrativo, de conformidad con lo señalado en la Ley Nº 27584 u
optar por el proceso constitucional del Hábeas Data, de acuerdo a lo
señalado por la Ley Nº 26301.

Artículo 12.- Acceso directo

Sin perjuicio de lo dispuesto en el artículo anterior, las entidades de la

Administración Pública permitirán a los solicitantes el acceso directo y de
manera inmediata a la información pública durante las horas de atención al
público.

Artículo 13.- Denegatoria de acceso

76
 La entidad de la Administración Pública a la cual se solicite información no
podrá negar la misma basando su decisión en la identidad del solicitante.

La denegatoria al acceso a la información solicitada debe ser debidamente

fundamentada en las excepciones del Artículo 15 de esta Ley, señalándose
expresamente y por escrito las razones por las que se aplican esas
excepciones y el plazo por el que se prolongará dicho impedimento.

La solicitud de información no implica la obligación de las entidades de la

Administración Pública de crear o producir información con la que no cuente
o no tenga obligación de contar al momento de efectuarse el pedido. En
este caso, la entidad de la Administración Pública deberá comunicar por
escrito que la denegatoria de la solicitud se debe a la inexistencia de datos
en su poder respecto de la información solicitada. Esta Ley tampoco
permite que los solicitantes exijan a las entidades que efectúen
evaluaciones o análisis de la información que posean.

Si el requerimiento de información no hubiere sido satisfecho o si la

respuesta hubiere sido ambigua, se considerará que existió negativa tácita
en brindarla.

Artículo 14.- Responsabilidades

El funcionario público responsable de dar información que de modo

arbitrario obstruya el acceso del solicitante a la información requerida, o la
suministre en forma incompleta u obstaculice de cualquier modo el
cumplimiento de esta Ley, se encontrará incurso en los alcances del
Artículo 4 de la presente Ley.

77
3. Capítulo III: Desarrollo de la Aplicación

3.1 Modelamiento
3.1.1 Requerimientos Funcionales

 Sistema en línea.

Funcionará con conexión a internet.

 Registrar papeleta.

La aplicación podrá registrar la papeleta.

 Alta disponibilidad.

El servicio estará disponible las 24 horas del día.

 Seguridad de autentificación.

La autentificación deberá ser segura.

 Consultar Información.

El sistema podrá devolver en el momento que se hace la

consulta los datos como el de sus puntos, el estado de su SOAT
y la veracidad de sus datos.

 Consistencia de datos.

Los datos deberán ser consistentes, la aplicación no debe

permitir realizar modificaciones.

78
 3.1.2 Requerimientos no Funcionales

- Dispositivo móvil
 Conexión a internet 3G como mínimo.
 Sistema operativo móvil con navegador actualizado.
 Memoria RAM de 256 MB.
 Memoria de almacenamiento 4GB.
- Servidores

Los servidores deberán estar en un data center que debe de contar

con las mínimas condiciones (temperatura adecuada, alimentación
eléctrica, etc).

Aplicaciones:

 Servidor IBM System x3650 M4 7915 Intel Xeon E5-2680 .

 Procesador: Intel Xeon E5-2680 / 2.7 GHz ( 3.5 GHz ) ( 8
núcleos ).
 Memoria RAM: 32 GB.
 Disco Duro: 1 TB.
Base de Datos:
 Servidor IBM System x3650 M4 7915 Intel Xeon E5-2680 .
 Procesador: Intel Xeon E5-2680 / 2.7 GHz ( 3.5 GHz ) ( 8
núcleos ).
 Memoria RAM: 16 GB.
 Disco Duro: 10 TB.
Desarrollo y QA:
 Servidor IBM System x3650 M4 7915 Intel Xeon E5-2680.

79
  Procesador: Intel Xeon E5-2680 / 2.7 GHz (3.5 GHz ) ( 8
núcleos ).
 Memoria RAM: 32GB.
 Disco Duro: 200 GB.

Restauración:
 Servidor IBM System x3650 M4 7915 Intel Xeon E5-2680.
 Procesador: Intel Xeon E5-2680 / 2.7 GHz (3.5 GHz ) ( 8
núcleos ).
 Memoria RAM: 16 GB.
 Disco Duro: 1 TB.

3.1.3 Diseño de la Arquitectura

Figura 20: Integración de las bases de datos

SAT SUNARP Otros

MTC

WebService que
WebService
expone datos
que expondrá
para el SAT y
los datos
MTC

Información integrada
de la Polícia de
Tránsito

Fuente: Elaboración Propia

80
 En la Figura N° 20 se muestra la Arquitectura de “Integración de las Bases
de Datos”, donde la información se transmitirá de forma síncrona ya que se
alimenta de información del MTC y luego será expuesta para el SAT,
SUNARP, MTC y otros clientes.

Figura 21: Arquitectura de Acceso a datos

Fuente: Elaboración Propia

En la Figura N° 21 se muestra la Arquitectura de “Acceso a Datos”, donde la

información será consumida por un servicio, que consumirá a tablas de
base de datos.
Figura 22: Interfaz de Usuario

Fuente: Elaboración Propia

81
 En la Figura N° 22 se muestra la Arquitectura de “Interfaz de Usuario”,
donde los datos se expondrán mediante los servicios web.

Figura 23: Proceso de Soporte Técnico

Fuente: Elaboración Propia

En la Figura N° 23 se muestra el “Proceso de Soporte Ténico” que en caso

de tener problemas con la aplicación, por ejemplo si se pierde la conexión
podrán llamar al Call Center para poder solucionar el incidente.

82
 Figura 245: Arquitectura de la solución

Pagina Web Móvil.

Web Service -
Policia Dispositivo Móvil. SAT
Base de Datos
Integrada

GATEWAY BUS Servidor de Aplicaciones

Web Service

Web Service
- SUNARP
BD Policía.

Servidor de Integración

Web Service
- Otros

BD MTC

Fuente: Elaboración Propia

En la Figura N° 24 se propone la arquitectura orientada a servicios, esta

arquitectura nos dice que tenemos que tener nuestra información
centralizada e integrada. Para este proyecto vamos a usar herramientas de
ORACLE.

Teniendo las 2 base de datos que no se encuentran integradas, el servidor

de integración se encargara de procesar esta información para luego ser
normalizada y se insertada en nuestra base de datos integrada.

El desarrollo de la aplicación será publicada en el servidor de aplicaciones

como también los web Service, para luego ser orquestada por el BUS, para
luego salir a internet mediante el GATEWAY.

El policía desde un dispositivo móvil podrá acceder a una página web

donde esta podrá consumir la aplicación y esta los web Service.

Base de Datos Integrada:

La base de datos integrada será alimentada a partir de un proceso de

integración que será asíncrona, tanto como obtendrá los datos de las base

83
 de datos de las otras entidades, esta base de datos también tendrá que
alimentar en forma opuesta las otras base de datos.

Según el MTC finales del 2012 se registraron 543,602 licencias de conducir

[44], con esos datos observamos que al momento de la integración no se
tendrá problema. Para que la carga de datos sea más rápida usaremos
patrones de actualización, esto quiere decir que solo los que han sufrido
alteración o los nuevos registros serán lo que se actualizarán.

Tabla 2: Perú - Licencias de conducir por clase de emisión, 2008 - 2012

LICENCIAS DE CONDUCIR POR CLASE DE EMISION
AÑO Y MESES TOTAL
NUEVAS CANJE REVALIDACIONES RECATEGORIZACIONES RECARNETIZACION A-III DUPLICADOS

2008 470,506 108,508 1,396 237,386 36,230 - 86,986

2009 445,489 100,561 1,411 182,602 21,166 9,419 130,330
2010 527,232 111,970 1,574 258,077 22,105 14,146 119,360
2011 553,418 148,591 1,760 235,006 52,563 - 115,498
2012 543,602 163,774 2,065 194,972 67,007 - 115,784
Fuente: Dirección General de Transporte Terrestre [44]

84
 3.1.4 Diseño de da Base de Datos
Diseño Físico
Figura 25: Diseño Físico de la Base de Datos

85
 Fuente: Elaboración Propia

86
 Diseño Lógico
Figura 26: Diseño Lógico de la Base de Datos

87
 Fuente: Elaboración Propia

88
 Diccionario de Datos

CONDUCTOR
NUMEROIDENTIFICACION Número de DNI del conductor
PRIMERNOMBRE Primer nombre del conductor
SEGUNDONOMBRE Segundo nombre del conductor
PRIMERAPELLIDO Primer apellido del conductor
SEGUNDOAPELLIDO Segundo apellido del conductor
NOMBRECOMPLETO Nombre completo del conductor
FECHANACIMIENTO Fecha de nacimiento del conductor
GENERO Sexo del conductor
ESTADOCIVIL Situación civil actual del conductor
TELEFONO Número del teléfono del conductor
MOVIL Número de celular del conductor
DIRECCION Ubicación del domicilio del conductor
NUMEROLICENCIA Número de licencia de conducir del conductor
CONDICION Activo = A , Retenido = R
EMAIL Dirección electrónica del conductor
CLASE Tipo de licencia del conductor
Número de categoría de la licencia de
CATEGORIA conducir
FECHAEXPEDICION Fecha de emisión de la licencia de conducir
Fecha de expiración de la licencia de
FECHAREVALIDACION conducir
RESTRICCIONES Dificultades físicas
GRUPOSANGUINEO Grupo de sangre del conductor
FACTORSANGUNEO Factor de sangre del conductor
PUNTOS Número de puntos actuales del conductor
CODIGOISOPAIS Código alfabético del país de procedencia
CODIGOIDENTIFICA CION Código del tipo de identificación
CODIGOLICENCIA Código del tipo de licencia de conducir
FOTOGRAFIA Fotografía del Conductor

DIVISIONPOLICIAL
CODIGODIVIS ION Código del tipo de división del policía
DESCRIPCION Información de la división del policía
CODIGOISOPAIS Código alfabético del país de procedencia

89
 GRADOPOLICIAL
CODIGOGRADO Código del grado policial
DESCRIPCION Información del grado del policía
CODIGOISOPAIS Código alfabético del país de procedencia

IDENTIFICACION
DESCRIPCION Información de los tipos de identificación
CODIGO Código de identificación del conductor y policía
CODIGOISOPAIS Código alfabético del país de procedencia

IDENTIFICACIONPOLICIAL
DESCRIPCION Información de la identificación policial
CODIGO Código de identificación policial
CODIGOISOPAIS Código alfabético del país de procedencia

INFRACCION
CODIGOISOPAIS Código alfabético del país de procedencia
Tipo de infracción L = leve, G = grave, M = muy
TIPO grave
CODIGO Código del tipo de infracción
DESCRIPCION Información de la infracción
MULTA Monto de la infracción
MULTACONDSCTO Monto con descuento de la infracción
SANCION Multa es porcentaje de UIT
PUNTOS Número de puntos actuales del conductor
MEDIDAPREVENTIVA Acción para proceder

LICENCIACONDUCTOR
DESCRIPCION Información de la licencia de conducir
CODIGO Código del tipo de licencia de conducir
CODIGOISOPAIS Código alfabético del país de procedencia

90
 PAPELETA
NUMEROINFRACCION Número secuencial de la infracción
FECHAINFRACCION Día de la infracción
DIRECCION Dirección de la infracción
FIRMA Aceptación o Desaprobación de la infracción
OBSERVACION Descripción de la infracción
CODIGOISOPAIS Código alfabético del país de procedencia
Tipo de infracción L = leve, G = grave, M = muy
TIPO grave
CODIGO Código del tipo de infracción
NUMEROIDENTIFICACIONPOLI Número de DNI del policía
CODIGOIDENTIFICA CIONPOLI Número de identificación policial
CODIGODIVIS ION Código del tipo de división perteneciente del policía
CODIGOGRADO Código del grado policial
NROPLACA Número de placa del conductor
NUMEROIDENTIFICACIONCONDU Número de DNI del conductor
CODIGOIDENTIFICA CIONCONDU Código del tipo de identificación del conductor
CODIGOLICENCIA Código del tipo de licencia

91
 POLICIA
NUMEROIDENTIFICACION Número de DNI del policía
PRIMERNOMBRE Primer nombre del policía
SEGUNDONOMBRE Segundo nombre del policía
PRIMERAPELLIDO Primer apellido del policía
SEGUNDOAPELLIDO Segundo apellido del policía
NOMBRECOMPLETO Nombre completo del policía
FECHANACIMIENTO Fecha de nacimiento del policía
GENERO Sexo del policía
ESTADOCIVIL Situación civil actual del policía
TELEFONO Número del teléfono del policía
MOVIL Número de celular del policía
DIRECCION Ubicación del domicilio del policía
NUMEROIDENTIFICACIONPOLICIA Número de identificación policial
CONDICION Activo o Fuera de Servicio
EMAIL Dirección electrónica del policía
CODIGOISOPAIS Código alfabético del país de procedencia
CODIGOGRADO Código del tipo de grado del policía
CODIGODIVIS ION Código del tipo de división perteneciente del policía
CODIGOIDENTIFICA CION Código del tipo de identificación
CODIGOIDENTIFICA CIONPOLICIA Código del tipo de identificación policial

CODIGOISOPAIS
NUMEROIDENTIFICACION
CLAVE
CODIGOIDENTIFICA CION
USUARIO
Código alfabético del país de procedencia
Número de Identificación
Contraseña del policía
Código de Identificación

92
 VEHICULO
CODIGOISOPAIS Código alfabético del país de procedencia
NROPLACA Número de placa del vehículo
PARTIDAREGISTRAL Número de partida registral
TITULO Número del título de propiedad
FECHA Fecha de emisión del título de propiedad
CONDICION A= Activo, V= Vencido
TIPOPROPIETARIO Personal natural o jurídica
SA= Sociedad Anónima, SRL=Sociedad de Responsabilidad
DENOMINACION Limitada
PRIMERNOMBRE Primer nombre del propietario
SEGUNDONOMBRE Segundo nombre del propietario
PRIMERAPELLIDO Primer apellido del propietario
SEGUNDOAPELLIDO Segundo apellido del propietario
NOMBRECOMPLETO Nombre completo del propietario
FECHAADQ Fecha de emisión de la tarjeta de propiedad
EXPTARJETA Fecha de expiración de la tarjeta de propiedad
DOMICILIO Ubicación del domicilio del propietario
CLASE Clase del vehículo
MARCA Marca del vehículo
ANOFABRICACION Año de elaboración del vehículo
MODELO Modelo del vehículo
COMBUSTIBLE Tipo de combustible del vehículo
CARRECERIA Parte del vehículo donde reposan los pasajeros
COLORES Color del vehículo
NROMOTOR Número del motor del vehículo
CILINDROS Capacidad de cilindros del vehículo
NROSERIE Número de serie del vehículo
RUEDAS Cantidad de ruedas del vehículo
PASAJEROS Cantidad de pasajeros del vehículo
ASIENTOS Cantidad de asientos del vehículo
PESOBRUTO Peso total del vehículo
LONGITUD Medida horizontal del vehículo en cm
ALTURA Medida vertical del vehículo en cm
ANCHO Medida del ancho del vehículo en cm
CARGAUTIL Peso útil del vehículo
PESOSECO Peso del vehículo cuando se encuentra vacío

93
 3.1.5 Oracle Data Integration

Observamos que los motores de base de datos de las entidades

relacionadas son diferentes a ORACLE la herramienta ORACLE DATA
INTEGRATION nos permite de manera muy simple hacer la conexión, en la
siguiente imagen vamos a observar toda las base de datos a las que nos
podemos conectar. Figura 27: ODI – Arquitectura Física

Fuente: Oracle Data Integrator

El entorno de la herramienta nos permite crear una cadena de conexión con

solo tener los datos de autentificación, servidor, puerto y nombre de
servicio.

94
 Figura 28: ODI – Servidor de Datos

Fuente: Oracle Data Integrator

Figura 29: ODI - Controladores

Fuente: Oracle Data Integrator

Luego de tener las conexiones de las base de datos procedemos a

relacionar los datos de las otras base de datos como se muestra en la

95
 Figura N° 29 donde se integra la base de datos de MTC a la base de datos
integrada.

Figura 30: ODI – Integración

Fuente: Oracle Data Integrator

La integración se podrá realizar aproximadamente a las 2 a.m., como

observamos en la siguiente imagen la herramienta nos ayuda a hacer
planificaciones y que se realicen en el momento indicado.

Figura 31: ODI – Planificación

Fuente: Oracle Data Integrator

96
 3.2 Desarrollo

Nuestra herramienta para desarrollar la metodología Scrum será el Trello.

3.2.1 Metodología a Aplicar

En el presente trabajo se desarrollara con la metodología SCRUM para el

desarrollo del proyecto.

Este trabajo incluye un conjunto de iteraciones para el desarrollar el

proyecto, en donde se inicializan los primeros requerimientos para las
entregas de documentos frecuentes y continuos al dueño de producto
(Policía de Tránsito) en un mínimo tiempo donde este podrá ver la
dimensión completa del sistema y así realizar una mejora continua en el
sistema.

En el siguiente cuadro comparativo explicaremos porque utilizaremos la

metodología Scrum en vez de una metodología RUP.

Tabla 3: Comparación de Metodología SCRUM vs RUP

Metodología SCRUM Metodología RUP

 Colaboración directa con el cliente
 Mayor tiempo en la construcción de
software
 Menos tiempo en documentación
 Adaptación al cambio
 Respuesta al cambio
 Mitigación de Riesgos
 Se dan entregables en el transcurso del
proyecto.
 Menor tiempo en la construcción de
software.
 Mayor calidad del software
Fuente: Elaboración Propia
 Negociación de contratos
 Mayor tiempo en especificaciones
 Documentación exhaustiva
 El cambio en vez de beneficiar
puede ser una amenaza al
proyecto.
 Adaptación a un plan
 Mayor riesgo al fracaso.
 Entregable al final del proyecto.
 Mayor tiempo en la construcción de
software.
 Baja calidad del software si se
presentan cambios.

97
 3.2.2 Tabla de SCRUM
Figura 32: Pizarra Principal de SCRUM

Fuente: https://trello.com/b/E5llRajb/proyecto-tesis-policia-transito

En la Figura N° 32 mostramos nuestra pizarra principal, donde

desarrollaremos la metodología Scrum.
En nuestra primera columna “To do” es nuestro sprint de pendientes “Por
hacer”.
En nuestra segunda columna “Doing” es nuestro sprint de “Haciendo”.
En nuestra terca y última columna “Done” es nuestro sprint de “Hecho”.

98
 3.2.3 Sprint Done
Figura 33: Sprint Done (Hecho)

Fuente: https://trello.com/b/E5llRajb/proyecto-tesis-policia-transito

En la figura N° 33 se muestra el nuestro sprint “Done”, donde tenemos

todas las tareas realizadas y también nos podemos dar cuenta a quien se le
asignó.

99
 3.2.4 Aspectos Generales

Figura 34: Tarea – Aspectos Generales

Fuente: https://trello.com/c/ueovP27A/2-capitulo-i-aspectos-generales

Dentro de nuestra tarea “Aspectos Generales” tenemos nuestras actividades

a realizar.
En la Figura N° 34 vemos que tenemos tareas que ya se realizaron y que
fueron seleccionadas con el visto de completado.

100
 3.2.5 Tarea – Desarrollo de la Aplicación

Figura 35: Tarea – Desarrollo de la Aplicación

Fuente: https://trello.com/c/gerjOBhj/4-capitulo-iii-desarrollo-de-la-aplicacion

En la Figura N° 35 se muestra la tarea “Desarrollo de la Aplicación”

tenemos 5 actividades que fueron completados en su totalidad.
 Modelamiento. OK
 Desarrollo. OK
 Aplicación. OK
 Monitoreo. OK
 Mantenimiento. OK

101
 3.2.6 Modelamiento de Datos

Figura 36: Tarea – Modelamientos de datos

Fuente: https://trello.com/c/Nrtfl9q2/10-modelamiento-de-datos

En la Figura N° 36 se muestra la tarea “Modelamientos de datos” tenemos 5

actividades que fueron completados en su totalidad.
 Identificar datos canónicos. OK
 Establecer entidades. OK
 Establecer atributos. OK
 Establecer tipo de datos. OK
 Establecer las Relaciones. OK
También podemos observar en la sección “Members” que esta tarea está
asignado al Scrum Master (Luigy Terrazos) y el miembro del equipo de
Scrum (David Verastegui).

102
 3.2.7 Diseño de Interfaces
Figura 37: Tarea – Diseño de Interfaces

Fuente: https://trello.com/c/66ZjKxSL/9-diseno-de-interfaces

En la Figura N° 37 “Tarea de Diseño de interfaces” tenemos 9 actividades

que fueron completados en su totalidad.
 Escoger herramienta para el desarrollo. OK
 Desarrollo de interfaz de inicio de sesión. OK
 Desarrollo de Interfaz del Menú de opciones. OK
 Desarrollo de Interfaz de Consulta del conductor. OK
 Desarrollo de Interfaz de Consultar Vehículo. OK

103
  Desarrollo de Interfaz de Registrar Papeleta. OK
 Desarrollo de Interfaz de SOAT y SUNAT. OK
 Desarrollo de Interfaz de Listar Infracciones. OK
 Desarrollo de Interfaz Datos del Conductor. OK

3.3 Aplicación
3.3.1 Secuencia de Funcionamiento

3.3.1.1 Inicio de Sesión

Figura 38: Inicio de Sesión

104
 Fuente: Elaboración Propia

En la Figura N° 38 se muestra la interfaz de “Inicio de Sesión”, donde el

usuario (Policía de Tránsito) ingresa su usuario y su clave.

3.3.1.2 Menú

Figura 39: Menú

105
 Fuente: Elaboración Propia

En la Figura N° 39 se muestra la interfaz del Menú, donde se cuenta con

los módulos de Consulta de conductor, Consulta de Vehículo, Lista de
Infracciones, Cerrar Sesión y Ayuda Telefónica.

3.3.1.3 Lista de Infracciones

106
 Figura 40: Lista de Infracciones

Fuente: Elaboración Propia

En la Figura N° 40 se ingresa el texto “seguro” y el sistema devuelve las

infracciones que contiene en su descripción la palabra “seguro”.

107
 3.3.1.4 Consultar Vehículo

Figura 41: Consultar Vehículo

Fuente: Elaboración Propia

En la Figura N° 41 se muestra información del vehículo, tanto los datos de

SUNARP como los del SOAT.

108
 3.3.1.5 SUNARP

Figura 42: Información de SUNARP

Fuente: Elaboración Propia

En la Figura N° 42 se muestra información del vehículo y del propietario

del vehículo.

109
 3.3.1.6 SOAT
Figura 43: Información del SOAT

Fuente: Elaboración Propia

En la Figura N° 43 se muestra información del SOAT del vehículo, como la

compañía aseguradora, fecha inicio y fin de vigencia.

110
 3.3.1.7 Consultar Conductor

Figura 44: Consultar Conductor

Fuente: Elaboración Propia

En la Figura N° 44 se selecciona el tipo de documento, se ingresa el

número del documento y el número de placa.

111
 3.3.1.8 Validación de SOAT y SUNARP

Figura 45: Validación SOAT y SUNARP

Fuente: Elaboración Propia

Al momento de hacer la búsqueda del conductor se valida que su SOAT

esté vigente y si en SUNARP el vehículo figura como robado, en la Figura
N° 45 se muestra una alerta donde el SOAT del conductor esta vencido y
su vehículo figura como robado.

112
 3.3.1.9 Datos del Conductor

Figura 46: Datos del Conductor

Fuente: Elaboración Propia

En la Figura N° 46 se muestra los datos del conductor y también se

visualiza que actualmente tiene 80 puntos.

113
 3.3.1.10 Registrar Papeleta por el Movil

Fig
ura
47:
Reg
istra
r
Pap
elet
a

Fue
nte:
Elab
orac
ión
Pro
pia

E
n

l
a

F
i
g
ura N° 47 se registra papeleta donde se debe llenar todos los campos
requeridos, luego el sistema devuelve que “se registró correctamente la
papeleta”.

114
 3.3.1.11 Actualización de Puntos

Figura 48: Actualización de Puntos

Fuente: Elaboración Propia

En la Figura N° 48 se muestra que luego de haber registrado la infracción

los puntos del conductor se actualizaron.

115
 3.3.2 Web Services

3.3.2.1 Consultar Infracción

Figura 49: Consultar Infracción

Fuente: Elaboración Propia

En la Figura N° 49 se muestra el web service de “Consultar Infracción” que

expondrá el MTC.

116
 3.3.2.2 Consultar SOAT

Figura 50: Consultar SOAT

Fuente: Elaboración Propia

En la Figura N° 50 se muestra el web Service de “Consultar SOAT” que

expondrá el MTC.

3.3.2.3 Historial Conductor

Figura 51: Historial Conductor

Fuente: Elaboración Propia

117
 En la Figura N° 51 se muestra el web service de “Historial Conductor” que
se expondrá a las otras entidades para que la puedan consumir.

3.3.2.4 Listar Papeletas

Figura 52: Listar Papeletas

Fuente: Elaboración Propia

En la Figura N° 52 se muestra el web service de “Listar Papeletas” que se

expondrá a las otras entidades para que la puedan consumir.

3.3.2.5 Obtener Vehículo

Figura 53: Obtener Vehículo

Fuente: Elaboración Propia

118
 En la Figura N° 53 se muestra el web service de “Obtener Vehículo” que
se expondrá a las otras entidades para que la puedan consumir.

3.3.2.6 Registrar Papeleta

Figura 54: Registrar Papeleta

Fuente: Elaboración Propia

En la Figura N° 54 se muestra el web service de “Registrar Papeleta” que

se expondrá a las otras entidades para que la puedan consumir.

119
 3.3.2.7 Carga de Datos a otra Base de Datos a una Entidad
Externa

Figura 55 : Cargar Datos Entidad

Fuente: Elaboración Propia

En la Figura N° 55 se muestra el web Service de “CargarDatosEntidad”

que se expondrá para ser ejecutada cuando se requiera enviar los datos a
una base de datos de una entidad externa identificada (Acceso a la base
de datos).

120
 3.4 Monitoreo

Para Monitorear el “Sistema Web Movil” se optó por utilizar la herramienta New Relic.

Figura 56: Monitoreo del Servidor de Aplicaciones - WebLogic

Fuente: Elaboración Propia

En la Figura N° 56 se observa la interfaz de “New Relic”, el uso del servidor de aplicaciones. El pico que se observa se
debe al inició del WebLogic (Servidor de Aplicaciones), posterior a eso se observa ejecuciones pequeñas.

121
 Figura 57: Error – Servidor de Aplicaciones

Fuente: Elaboración Propia

En la Figura N° 57 se realizó una prueba, donde se deshabilito la Base de Datos para generar errores, en la parte
derecha se muestran los errores que sucedieron en el servidor de aplicaciones durante ese tiempo.

122
 Figura 58: Detalle de Problemas Críticos de la Base de Datos y el APP SERVER

Fuente: Elaboración Propia

En la Figura N° 58 observamos como la herramienta nos ayuda a ver el detalle del momento donde hubo problemas
críticos, en la parte izquierda corresponde a la Base de Datos donde se visualiza aproximadamente a las 19:20 pm un
pico alto, igualmente para el servidor de aplicaciones aproximadamente a las 19:42 pm donde se visualiza un pico alto.

123
 Figura 59: Reporte del Estado del Servidor de Aplicaciones y la Base de Datos

Fuente: Elaboración Propia

En la Figura N° 59 observamos el estado actual de cómo se encuentra el Servidor de Aplicaciones y la Base de Datos.

124
 Figura 60: Reporte de Aplicaciones

Fuente: Elaboración Propia

En la Figura N° 60 observamos los servicios como “PortConsultaMTC”, “PortPapeletasBSSOAP12” y entre otras que se
están ejecutando en el Servidor de Aplicaciones.

125
 Figura 61: Reporte del Servicio Consulta MTC

Fuente: Elaboración Propia

En la Figura N° 61 observamos el rendimiento del servicio de consulta “PortalConsultaMTC”.

126
 Figura 62: Reporte del Servicio "PapeletaBSSOAP12"

Fuente: Elaboración Propia

En la Figura N° 62 observamos el rendimiento del servicio “PapeletaBSSOAP12”, que es la que consulta a la base de
datos integrada.

127
 Figura 63: Reporte del Estado de la Máquina Virtual

Fuente: Elaboración Propia

En la Figura N° 63 observamos el estado de la máquina Virtual de Java, donde se visualiza el tamaño de la memoria en
uso.

128
 Figura 64: Reporte de Errores por Consulta

Fuente: Elaboración Propia

En la Figura N° 64 observamos los errores que sucedieron en el Servidor de Aplicaciones, en el rango de horas 19:24:14
- 19:38:14, donde sucedido 200 errores debido a la prueba de stress que realizamos.

129
 Figura 65: Configuración de Alerta del Servidor de Aplicaciones

Fuente: Elaboración Propia

En la Figura N° 65 observamos el panel donde se configura las alertas, por ejemplo si ahora la cantidad de errores
supera el 5% de peticiones se genera una alerta.

130
 3.5 Mantenimiento

El plan de mantenimiento se seguirá de la siguiente manera:

3.5.1 Mantenimiento de base de datos

Se realizara la actualización de las estadísticas de los objetos de la base de

datos para mejorar los planes de ejecución, usando el siguiente paquete
DBMS_STATS que permite generar y manejar las estadísticas para
manejar el optimizador basado en costos. Los procedimientos que
componen este paquete son:

 GATHER_INDEX_STATS: Las estadísticas de índices

 GATHER_TABLE_STATS: Estadísticas de tablas, columnas.
 GATHER_SCHEMA_STATS: Estadísticas de todos los objetos del
esquema
 GATHER_DATABASE_STATS: Estadísticas de todos los objetos de
la base de datos.
 GATHER_SYSTEM_STATS: Estadísticas del sistema sobre CPU y
I/O

Realizar planes de backup de las base de datos.

3.5.2 Mantenimiento de Servidores:

 Desfragmentación del disco duro cada cierto periodo.

 Realizar las actualizaciones del sistema operativo.
 Revisión periódica de la configuración de los Firewall.

3.5.3 Mantenimiento de Servidor de Aplicaciones

 Se realizara la limpieza de los logs generado por el servidor de

Aplicaciones.

131
4. Capítulo IV: Análisis de Costo Beneficio

4.1 Análisis de Costo

Para el desarrollo del prototipo utilizaremos las siguientes Herramientas

Tecnológicas:

Tabla 4: Herramientas Tecnológicas

Categoria Producto
Base de Datos Oracle Database
(Standard Edition)
Oracle Database
(Xpress Edition)
Middleware WebLogic Suite
API Gateway
Service Registry
SOA Suite for Oracle Middleware
Oracle Data Integrator
Service Bus
IDE’s de Desarrollo JDeveloper
Eclipse
SQLDeveloper
Modelador de Datos Erwin Data Modeler
Gestor de Tiempo y Trello
Avance.
Fuente: Elaboración Propia

Nuestro proyecto no nos brindara una rentabilidad económica, debido a que

obtendremos un beneficio social e intangible, lo que se busca no es generar un
mayor ingreso por registrar papeletas, sino reducir la tasa de accidentes de
tránsito generado por conductores imprudente.

132
 4.1.1 Viabilidad Técnica

Se definirá las características del recurso humano involucrado en el

proyecto, el software y el hardware que demandara la construcción de la
aplicación.
4.1.1.1 Identificación del Sistema

Título: Diseño de un prototipo para un sistema móvil de consulta y

registro de documentos de infracciones de tránsito.
4.1.1.2 Recursos Humanos

 Jefe de proyecto: (1)

 Arquitecto SOA: (1)
 Arquitecto de soluciones: (1)
 Analista QA: (1)
 Analista programador: (5)
 Analista de Integración: (1)
 Administrador de base de datos: (1)
 Administrador de middleware: (1)
 Documentador: (2)

133
 4.1.1.3 Recursos Hardware

Tabla 5: Recursos de Hardware

Descripción Función Virtualizado S. Operativo Especificaciones

Servidor de BUS NO Red Hat  Procesador 2.7 GHz - 3.5 GHz (
Aplicaciones Gateway (Oracle Linux) 8 núcleos ).
Servidor de  Memoria RAM: 32GB.
Aplicaciones  Disco Duro: 100 GB.

Servidor de Servidor de NO Red Hat  Procesador 2.7 GHz - 3.5 GHz (

Base de Datos BD (Oracle Linux) 2 núcleos ).
Servidor de
 Memoria RAM: 16GB.
Integración
 Disco Duro: 10 TB.

Servidor de Servidor de  Memoria RAM: 8GB. Red Hat  Procesador 2.7 GHz - 3.5 GHz (
Desarrollo y Desarrollo  Disco Duro: 100 GB. (Oracle Linux) 8 núcleos ).
QA
 Memoria RAM: 32GB.
Servidor de  Memoria RAM: 16GB.  Disco Duro: 200 GB.
QA  Disco Duro: 100 GB.
Servidor de Servidor de NO Red Hat  Procesador 2.7 GHz - 3.5 GHz (
Restauración Restauración (Oracle Linux) 8 núcleos ).
 Memoria RAM: 16 GB.
 Disco Duro: 10 TB.

Fuente: Elaboración Propia

Tabla 6: Listado de Servidores

#Servidores Descripción Especificaciones

1 Servidor de Aplicaciones  Servidor IBM System x3650 M4
7915 Intel Xeon E5-2680 .
 Procesador: Intel Xeon E5-2680 /
2.7 GHz ( 3.5 GHz ) ( 8 núcleos ).
 Memoria RAM: 32GB.
 Disco Duro: 1 TB.

1 Servidor de Base de  Servidor IBM System x3650 M4

Datos 7915 Intel Xeon E5-2680 .
 Procesador: Intel Xeon E5-2680 /
2.7 GHz ( 3.5 GHz ) ( 2 núcleos ).
 Memoria RAM: 16GB.
 Disco Duro: 10 TB.

134
 1 Servidor de Desarrollo y  Servidor IBM System x3650 M4
QA 7915 Intel Xeon E5-2680 .
 Procesador: Intel Xeon E5-2680 /
2.7 GHz ( 3.5 GHz ) ( 8 núcleos ).
 Memoria RAM: 32GB.
 Disco Duro: 200 GB.

1 Servidor de  Servidor IBM System x3650 M4

Restauración 7915 Intel Xeon E5-2680 .
 Procesador: Intel Xeon E5-2680 /
2.7 GHz ( 3.5 GHz ) ( 8 núcleos ).
 Memoria RAM: 16GB.
 Disco Duro: 1 TB.

Fuente: Elaboración Propia

4.1.1.4 Recursos Software

Tabla 7: Recursos de Software

# Software Categoría Producto Licencias Tipo

1 Base de Datos Oracle Database Licenciado Base de datos con todas las funciones disponibles de
(Standard Edition) Oracle.
1 Oracle Database Licenciado Base de datos para realizar las pruebas.
(Xpress Edition)
1 Middleware WebLogic Suite Licenciado Aplicación para administrar los servidores de
aplicaciones.
1 API Gateway Licenciado Herramienta para poder publicar a internet nuestros
servicios.
1 Service Registry Licenciado Repositorio donde se tendrá almacenado los WebService
con su descripción y uso
1 SOA Suite for Oracle Licenciado Herramienta que permite realizar la arquitectura
Middleware
1 Oracle Data Integrator Licenciado Herramienta para hacer ETL.
1 Service Bus Licenciado Herramienta para orquestar los WebService
1 IDE’s de JDeveloper Licenciado Herramienta para hacer el desarrollo de los WebService y
Desarrollo de la Aplicación
1 Eclipse Licenciado Herramienta para integrar con el OSB y realizar la
orquestación de los WebService
1 SQLDeveloper Licenciado Herramienta para hacer las consultas a la base de datos.

1 Modelador de Erwin Data Modeler Licenciado Herramienta para realizar el modelado de la base de
Datos datos y para exportar el script.
1 Gestor de Trello Licenciado Herramienta para manejar el proyecto con SCRUM
Tiempo y
Avance.
1 NewRelic Licenciado Herramienta para Monitoreo y Gestión de Aplicaciones
Web.

Fuente: Elaboración Propia

135
 4.1.2 Viabilidad Económica

4.1.2.1 Costo de Inversión

El costo de inversión consiste en la inversión total que deberá realizarse

para el desarrollo y la implementación del proyecto.

Jefe de Proyecto

 Definir el proyecto y evaluar sus necesidades.

 Redactar las especificaciones del proyecto.
 Calcular el costo del proyecto.
 Contratar al equipo según lo perfiles requeridos.
 Realizar seguimiento e informes del progreso del proyecto,
en términos de calidad, costo y plazos de entrega.

Tabla 8: Costo del Jefe del Proyecto

Meses Remuneración
Recurso Costo Total
Asignado Mensual
Jefe de Proyecto 7 S/. 10,000.00 S/. 70,000.00
Cantidad 1
S/. 70,000.00
Fuente: Elaboración Propia

Arquitecto SOA

 Definir el gobierno de SOA y procesos de funcionamiento de la

arquitectura.
 Definir patrón de desarrollo.

Tabla 9: Costo del Arquitecto SOA

Meses Remuneración
Recurso Costo Total
Asignado Mensual
Arquitecto SOA 3 S/. 6,000.00 S/. 18,000.00
Cantidad 1
S/. 18,000.00

Fuente: Elaboración Propia

136
 Arquitecto de Soluciones

 Estructurar una oficina de arquitectura.

 Diagnosticar necesidades tecnológicas.
 Formar un equipo interno que ayude a la difusión de buenas
prácticas en desarrollo
 Difundir el conocimiento técnico orientado a analizar, diseñar e
implementar arquitecturas técnicas para soluciones de
software.
 Definir tecnología de información que se utilizará, así como los
requerimientos de infraestructura necesarios para poder
atender las necesidades del cliente.
 Definir procedimientos, rutinas y/o funciones que formaran
parte del desarrollo del sistema.
 Definir arquitectura, diseño de iniciativas para el desarrollo de
productos de software y definiendo estándares
Arquitectónicos.
 Realizar pruebas técnicas y de integración.

Tabla 10: Costo del

Arquitecto de
Soluciones Meses Remuneración
Recurso Costo Total
Asignado Mensual
Arquitecto de Soluciones 2 S/. 8,000.00 S/. 16,000.00
Cantidad 1
S/. 16,000.00

Fuente: Elaboración Propia

137
 Analista de QA

 Validar y analizar el producto a través de pruebas de caja

negra, pruebas funcionales y no funcionales.
 Elaborar un plan de pruebas para los proyectos asignados
(pruebas manuales y/o automatizadas)
 Elaborar la definición de los casos de prueba en base a la lista
provista por Analista Programador y en base a los diagramas
de análisis
 Generar los casos de pruebas
 Realizar las pruebas de acuerdo al plan de pruebas (pruebas
funcionales, integrales, pruebas de caja blanca caja negra,
pruebas de stress, performance).
 Validación del funcionamiento del producto en condiciones
similares al uso real normal.
 Generar estándares de calidad para gestión de software
orientado al producto.

Tabla 11: Costo del Analista QA

Meses Remuneración
Recurso Costo Total
Asignado Mensual
Analista QA 2 S/. 4,000.00 S/. 8,000.00
Cantidad 1
S/. 8,000.00
Fuente: Elaboración Propia

138
 Analistas Programadores

 Responsable de las labores de construcción.

 Pruebas unitarias e integrales.

Tabla 12: Costo del Analista Programador

Meses Remuneración
Recurso Costo Total
Asignado Mensual
Programadores 5 S/. 3,500.00 S/. 87,500.00
Cantidad 5
S/. 87,500.00

Fuente: Elaboración Propia

Analista de Integración

 Definir los estándares de ETL

 Realizar el ETL de los datos
 Orquestación de servicios web.

Tabla 13: Costo del Analista de Integración

Meses Remuneración
Recurso Costo Total
Asignado Mensual
Analista de Integración 2 S/. 4,000.00 S/. 8,000.00
Cantidad 1
S/. 8,000.00
Fuente: Elaboración Propia

139
 Administrador de Base de Datos

 Optimización de recursos.
 Actualización de datos.
 Administrar el performance de la base de datos
 Tener un plan de contingencia sobre la recuperación de la
base de datos

Tabla 14: Costo del Administrador de Base de Datos

Meses Remuneración
Recurso Costo Total
Asignado Mensual
Administrador de Base de Datos 2 S/. 4,000.00 S/. 8,000.00
Cantidad 1
S/. 8,000.00
Fuente: Elaboración Propia

Administrador de Middleware

 Administrar la plataforma de integración.

Tabla 15: Costo

del
Meses Remuneración
Recurso Costo Total
Asignado Mensual
Administrador de Middleware 3 S/. 5,000.00 S/. 15,000.00
Cantidad 1
S/. 15,000.00

Administrador de Middleware

Fuente: Elaboración Propia

140
 Documentador

 Procesamiento técnico de archivos, bibliotecas o centros de

información.
 Documentación, apoyo en labores de atención y organización
de los archivos digitales y documentales de la empresa.

Tabla 16: Costo del Documentador

Meses Remuneración
Recurso Costo Total
Asignado Mensual
Documentador 2 S/. 2,500.00 S/. 5,000.00
Cantidad 1
S/. 5,000.00

Fuente: Elaboración Propia

Tabla 17: Costo Total de Recursos Humanos

Recurso Humano Costo Total

Jefe de Proyecto S/. 70,000.00
Arquitecto SOA S/. 18,000.00
Arquitecto de Soluciones S/. 16,000.00
Analista QA S/. 8,000.00
Programadores S/. 87,500.00
Analista de Integración S/. 8,000.00
Administrador de Base de
S/. 8,000.00
Datos
Administrador de Middleware S/. 15,000.00
Documentador S/. 5,000.00
S/. 235,500.00

Fuente: Elaboración Propia

141
 El costo total de los Recursos Humanos equivale al monto de S/. 235,500

Tabla 18: Costo Total de Recursos de Hardware

Precio
Hardware Cantidad Costo Total
Unitario
Servidor BUS
Servidor Gateway 1 S/. 25,250.00 S/. 25,250.00
Servidor Integración
Servidor de
Aplicaciones 1 S/. 90,000.00 S/. 90,000.00
Servidor de BD
Servidor de Desarrollo
1 S/. 25,250.00 S/. 25,250.00
Servidor de QA
Servidor de
1 S/. 37,500.00 S/. 37,500.00
Restauración
Laptops 20 S/. 4,000.00 S/. 80,000.00
S/. 258,000.00
Fuente: Elaboración Propia

El costo total de los Recursos de Hardware equivale al monto de S/. 258,000

Tabla 19: Costo Total de Recursos de Software

Precio
Software Cantidad Costo Total
Unitario
Oracle Database (Standard Edition) 1 S/. 103,250.00 S/. 103,250.00
Oracle Database (Xpress Edition) 1 S/. 0.00 S/. 0.00
WebLogic Suite 1 S/. 126,000.00 S/. 126,000.00
API Gateway 1 S/. 154,000.00 S/. 154,000.00
Service Registry 1 S/. 406,000.00 S/. 406,000.00
SOA Suite for Oracle Middleware 1 S/. 161,000.00 S/. 161,000.00
Oracle Data Integrator 1 S/. 420,000.00 S/. 420,000.00
Service Bus 1 S/. 64,400.00 S/. 64,400.00
JDeveloper 1 S/. 0.00 S/. 0.00
Eclipse 1 S/. 0.00 S/. 0.00
SQLDeveloper 1 S/. 0.00 S/. 0.00
Erwin Dara Modeler 1 S/. 13,424.00 S/. 13,424.00
Trello 1 S/. 200.00 S/. 200.00
NewRelic 1 S/. 1023.00 S/. 1023.00
S/. 1,449,297.00

142
 Fuente: Elaboración Propia

El costo total de los Recursos de Software equivale al monto de S/.

1,449,297.00.

Tabla 20: Costo Total de Inversión

Recursos Costo Total

Hardware S/. 258,000.00
Software S/. 1,449,297.00
Humanos S/. 235,500.00
Total S/. 1,942,797.00

Fuente: Elaboración Propia

El costo total de la Inversión equivale al monto de S/. 1, 942,797.00.

143
 4.2 Análisis de Beneficios

El desarrollo del proyecto generara impacto social e institucional, por el cual se

realizó la validación en la Comisaria de Pamplona I con el jefe de Tránsito
(Mayor Jaime Garcia). Como resultado de la visita se pudo corroborar los
requerimientos definidos en una reunión previa, donde se presentó el prototipo
del sistema para validar las funcionalidades, para ello se evidenció la
interacción realizada con el Mayor en el siguiente video que fue subido a
Youtube:

- https://www.youtube.com/watch?v=9aOENz4LF0A (link del video)

Impacto Social:

 Reducir la tasa de accidentes de tránsito.

 Reducción del flujo de transito debido a la disminución del tiempo
de intervención.
 Mejorar la calidad de vida del peatón.
 Aumento de conciencia del conductor.

Impacto Institucional:

 Mayor eficacia de los policías de tránsito.

 Mejora del proceso de generación de las papeletas.
 Mejora en la interacción de las entidades relacionadas.
 Mejora de la eficiencia administrativa de las comisarías y
entidades.

144
4.2.1 Cronograma de Actividades
Nombre de tarea Duración Comienzo Fin
APLICACIÓN MÓVIL 130 días lun 06/01/14 vie 04/07/14
ANÁLISIS 30 días lun 06/01/14 vie 14/02/14
CAPITULO I: Aspectos Generales 15 días lun 06/01/14 vie 24/01/14
Definición del Problema 4 días lun 06/01/14 jue 09/01/14
Objetivos 4 días vie 10/01/14 mié 15/01/14
Motivación y Justificación 7 días jue 16/01/14 vie 24/01/14
Hito 1: Documento de Introducción 0 días
ANÁLISIS DEL SISTEMA ACTUAL 15 días lun 27/01/14 vie 14/02/14
Recopilación de información 4 días lun 27/01/14 jue 30/01/14
Informe de recopilación de información 4 días vie 31/01/14 mie 05/02/14
Modelamiento del sistema actual 4 días jue 06/02/14 mar 11/02/14
Informe de análisis del sistema actual 3 días mie 12/02/14 vie 14/02/14
Hito 2: Documento del Proceso Actual 0 días
DISEÑO 30 días lun 17/02/14 vie 28/03/14
CAPITULO II: Fundamento Teórico 15 días lun 17/02/14 vie 07/03/14
Antecedentes de Investigación 3 días lun 17/02/14 mie 19/02/14
Marco Teórico 2 días jue 20/02/14 vie 21/02/14
Marco Conceptual 3 días lun 24/02/14 mie 26/02/14
Marco Metodológico 5 días jue 27/02/14 mie 05/03/14
Marco Legal 2 días jue 06/03/14 vie 07/03/14
Hito 3: Documento del Fundamento Teórico 0 días
CAPITULO III: Desarrollo de la Aplicación 15 días lun 10/03/14 vie 28/03/14
Modelamiento 2 días lun 10/03/14 mar 11/03/14
Desarrollo 3 días mie 12/03/14 vie 14/03/14
Aplicación 5 días lun 17/03/14 vie 21/03/14
Monitoreo 2 días lun 24/03/14 mar 25/03/14
Mantenimiento 3 días mie 26/03/14 vie 28/03/14
Hito 4: Documento del Desarrollo de la Aplicación 0 días
VIABILIDAD 10 días lun 31/03/14 vie 11/04/14
CAPITULO IV : Análisis de Costo Beneficio 10 días lun 31/03/14 vie 11/04/14
Análisis de Costo 5 días lun 31/03/14 vie 04/04/14
Análisis de Beneficios 4 días lun 07/04/14 jue 10/04/14
Análisis de Sensibilidad 1 día vie 11/04/14 vie 11/04/14
Hito 5: Documento de Análisis de Costo Beneficio 0 días
DESARROLLO 50 días lun 14/04/14 vie 20/06/14
INTEGRACION DE DATOS 10 días lun 14/04/14 vie 25/04/14
Definición de fuentes 2 días lun 14/04/14 mar 15/04/14
Definir reglas de integración 2 días mié 16/04/14 jue 17/04/14
Consolidación de datos internos 3 días vie 18/04/14 mar 22/04/14
Consolidación de datos externos 3 días mié 23/04/14 vie 25/04/14
Hito 6: Documento de definición de las fuentes 0 días
DESARROLLO DE LA APLICACIÓN MOVIL 20 días lun 28/04/14 vie 23/05/14
Desarrollo de interfaces graficas (GUI) 5 días lun 28/04/14 vie 02/05/14
Integración de aplicación con los servicios web 15 días lun 05/05/14 vie 23/05/14
Hito 7: Pantallazos de la GUI y ejecutables de la integración 0 días
PRUEBAS 15 días lun 26/05/14 vie 13/06/14
Pruebas unitarias 5 días lun 26/05/14 vie 30/05/14
pruebas integrales 10 días lun 02/06/14 vie 13/06/14
Hito 8: Informe de Pruebas 0 días
MEJORA CONTINUA 5 días lun 16/06/14 vie 20/06/14
DOCUMENTACION 10 días lun 23/06/14 vie 04/07/14

145
 Hito 9: Cierre del Proyecto 0 días

146
 4.3 Análisis de Sensibilidad

Para el presente Proyecto el Análisis de Sensibilidad no aplica debido a que es un Proyecto con un fin Social y no
Económico; sin embargo generara los siguientes beneficios:

En la Figura 66, se muestra las estadísticas de infracciones al reglamento Nacional de Tránsito por departamento,
donde se observa que en el departamento de Lima, en el año 2012 se generaron la mayor cantidad de infracciones
(2,276,390). (Anexo 2).

Figura 66: Estadísticas de Infracciones al reglamento Nacional de Tránsito, por Departamento - Perú

Infracciones de Tránsito 2009 2010 2011 2012 2013

1400 000

1200 000

1000 000

800 000

600 000

400 000

200 000

Fuente: INEI [45]

147
 Según lo conversado con el Mayor Jaime García de la comisaria de Pamplona I,
en el mes de Enero del 2015 se tuvo la siguiente información:

Número de intervenciones a las

semana 350
Número de intervenciones al día 50
Papeletas impuestas por día 15
Número de policías asignados por
intervención 5
Tiempo aprox. de intervención por
conductor (min). 6

Obteniendo los siguientes resultados:

Tiempo Aprox. Actual Tiempo Aprox. Con el Sistema

(min) (min)
Por intervención 6 3
Al día 300 150
A la semana 2100 1050
Tiempo reducido a la
semana 1050

Con el sistema propuesto se reducirá 1050 minutos en intervenciones, que se

puede asignar a otras actividades como el patrullaje para la seguridad
ciudadana.

Con el uso del sistema la productividad de los policías de tránsito se

incrementara, reduciendo en 50% el tiempo de intervención semanal, esto
genera un incremento de un 50% en intervenciones semanales en el mismo
tiempo que se toma con el procedimiento actual.

Número de papeletas
impuestas
Papeletas impuestas por día 15
Papeletas impuestas por
semana 75

148
 A la semana con el procedimiento actual se generan aproximadamente 75
papeletas que equivalen a 75 hojas usadas para emitir las papeletas. Con el
sistema propuesto se eliminará el uso de las hojas generando el ahorró en la
adquisición de las hojas.

Con el sistema propuesto se eliminara el procedimiento de envió de papeletas a

las sedes correspondientes, para que se puedan cargar a los sistemas del SAT
y MTC, generando la reducción de horas de los procesos administrativos de las
comisarías y entidades.

A nivel nacional existen 34 mil 805 efectivos policiales que laboran en

comisarías, la mayoría de ellos (9 mil 686) se encuentran en el Departamento de
Lima (ver Anexo 3), y además a nivel nacional existen 1mil 397 comisarías
donde en el departamento de Lima se cuenta con 176 comisarías [46]. Según
las pruebas de stress realizadas en nuestro servidor de desarrollo, el sistema
podría soportar hasta 1000 transacciones por segundo, debido a ello podemos
concluir que en un ambiente productivo con los requerimientos propuestos
nuestro proyecto podría ser fácilmente utilizado por todas las comisarías y
policías de tránsito de Lima Metropolitana.

149
5. Capítulo V: Conclusiones y Recomendaciones

5.1 Conclusiones

 Se validó el diseño del prototipo del Sistema Web Móvil.

 La propuesta reduce el alto índice de accidentes de tránsito.
 El modelo propuesto a nivel técnico es viable, debido a que cumple con los
requerimientos funcionales definidos.
 La propuesta reduce el tiempo de intervención vehicular, generando mayor
fluidez vehicular.
 Con el uso de la metodología ágil se logró reducir los tiempos de desarrollo
e incrementar la calidad del producto.
 Se logró validar el modelo de integración entre las entidades relacionadas.
 La aplicación es de fácil uso, con una interfaz gráfica muy intuitiva que
facilitara su entendimiento al Policía de Tránsito.

5.2 Recomendaciones

 La ejecución de este proyecto debería de ejecutarse a la brevedad para

reducir la tasa de accidentes.
 Se debe de usar la tecnología propuesta con los mínimos requerimientos
para su correcto funcionamiento.
 El uso de la arquitectura SOA debe de aplicarse en todas las entidades
relacionadas para una mejor integración entre estos sistemas distribuidos.
 Proporcionar la información integrada a otras entidades que la requieran.

150
Referencias:
[1] INEI – “Estadísticas de Seguridad Ciudadana – A Marzo 2012”
Perú, 49 p, Julio 2012
http://www.inei.gob.pe/web/NotaP rens a/Attach/14685.pdf

[2] INEI – “Estadísticas de Seguridad Ciudadana – A Marzo 2012”

Perú, 49 p, Julio 2012
http://www.inei.gob.pe/web/NotaP rens a/Attach/14685.pdf

[3] La República – “Siete peruanos mueren al día por accidentes de tránsito”

Perú, 4 de Diciembre del 2011
http://www.larepublica.pe/04-12-2011/siete-peruanos-mueren-al-dia-por-accidentes-de-
transito

[4] El Comercio – “Accidentes de Tránsito dejan más de 400 muertes en los últimos 4 años”
Perú, 14 de Octubre del 2012
http://elcomercio.pe/actualidad/1482587/noticia-accidentes-transito-dejan-mas-400-muertes-
ultimos-cuatro-anos

[5] Ministerio de Salud, Dirección General de Epidemología

http://bvs.per.paho.org/share/icaldero/libro-accidentes -de-transito.pdf

[6] Personal del INSUTRA (Instituto Superior de Transito)

[7] Estrategia Tecnológica de la Policía Nacional de Colombia – “SUNAMI”

Colombia, 15p, Febrero 2012
http://www.fundibeq.org/opencms/export/sites/default/PWF/downloads/gallery/methodology/le
arn/bestPractices/Policxa_Nacional_de_Colombia_-_B uena_prxctica.pdf

[8] SIMIT
https://consulta.simit.org.co/Simit/home/infraestructura.htm

[9] ETL - “Extracción, Transformación y Carga”

http://es.wikipedia.org/wiki/Extract,_transform_and_load

[10] Oracle - “Oracle Data Integrator 11g”

http://www.dataprix.com/blogs/juan-vidal/oracle-data-integrat or-11g

[11] Oracle – “Oracle Services Bus”

http://www.oracle.com/technetwork/es/middleware/soasuite/documentation/oracle-soa-suite-
427128-esa.pdf

[12] Oracle – “Oracle SOA Suite”

http://www.oracle.com/technetwork/es/middleware/soasuite/documentation/oracle-soa-suite-
427128-esa.pdf

[13] Oracle – “Oracle Database 11g Enterprise Edition”

http://www.oracle.com/us/products/database/enterprise-
edition/overview/index.html?ssSourceSiteId= ocomes

[14] Erwin Data Modeler

http://www.dimensionti.com/prod051.htm

151
 [15] Eclipse
http://es.wikipedia.org/wiki/Eclipse_(software)

[16] SQL Developer

http://www.oracle.com/technetwork/developer-tools/sql-developer/overview/index.html

[17] JDeveloper
http://es.wikipedia.org/wiki/JDeveloper

[18] Aplication Server - “Definición”

http://www.service-architecture.com/articles/application-
servers/application_server_definition.html

[19] Trello
http://en.wikipedia.org/wiki/Trello

[20] Lenguaje de Programación – “Definición y Origen”

http://es.kioskea.net/contents/304-lenguajes-de-programacion

[21] Java – “Conozca más sobre la tecnología Java”

http://www.java.com/es/about/

[22] Servicio Web – “Web Services”

https://es.wikipedia.org/wiki/Servicio_web

[23] JDBC – “¿Qué es JDBC?”

http://www.adictosaltrabajo.com/tutoriales/tutoriales.php?pagina=introjdbc

[24] New Relic

http://www.genbetadev.com/desarrollo-aplicaciones-moviles/new-relic-para-monitorizar-el-
rendimiento-y-las-conexiones-de-red-de-aplicaciones-moviles-android-e-ios

[25] ISO 3166-1

http://es.wikipedia.org/wiki/ISO_3166-1

[26] Policía Nacional del Perú – “División de Policía de Tránsito”

http://www.pnp.gob.pe/dirtepol/7dirtepol/transito/inicio.html

[27] Ministerio del Interior – “Organigrama del Ministerio del Interior”

https://www.mininter.gob.pe/admin/archivos/03122013060149_organigrama.jpg

[28] Policía Nacional del Perú – “Organigrama de la Policía Nacional del Perú”
https://www.pnp.gob.pe/organigrama.html

[29] Servicio de Administración Tributaria de Lima

http://www.sat.gob.pe/transparenciav2/pdf/SATDG001V1_2.pdf

[30] Ministerio de Transporte y Comunicaciones

http://www.mtc.gob.pe/portal/organizacion. htm

[31] SUNARP
https://www.sunarp.gob.pe/qSomos.asp?mnuid=2&mnusubid=1

[32] Touring
http://www.touringperu.com.pe/Default.asp#

152
 [33] Sistema Web Movil
http://ordenador.wingwit.com/Redes/wireless-networking/82160. html#.VCI6YPl5P 7w

[34] Sistemas Distribuidos “Definición”

https://www.google.com.pe/url?sa=t&rct=j&q=&esrc=s&source=web&cd=10&cad=rja&uact=8
&ved=0CFYQFjAJ&url=http%3A%2F%2Fdmi.uib.es%2F~bbuades%2Fsistdistr%2Fsistdistr.P
PT&ei=di4iVJr2C4eSgwTfnIDIAQ&usg=AFQjCNG8xn2m4UUz1n-
CKsq2orA7G_BivQ&sig2=SbE rWOBRao1NK2accgn7gg& bvm= bv.75775273,d. eXY

[35] Sistemas Distribuidos “Ventajas”

http://laurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/sod -introduccion-1pp. pdf

[36] SOA – “Arquitectura Orientada a Servicios”

http://es.wikipedia.org/wiki/Arquitectura_orientada_a_servicios

[37] BPEL – “Definición”

http://oscarblancarteblog.com/2014/07/15/que-es-bpel/

[38] Enterprise Service Bus “Definición y Funcionalidad”

http://icomparable.blogspot.com/2009/04/que-es-un-esb-enterprise-service-bus.html

[39] Enterprise Service Bus “Arquitectura”

http://kaf.com.mx/home/font-styles-mainmenu-54

[40] Metodología “Definición”

http://www.um.es/docencia/barzana/IAGP/Iagp2.html

[41] Metodología RUP

http://analisis1daid.wikispaces.com/Metodologia_RUP_UML

[42] Proyectos Ágiles – “¿Qué es SCRUM?”

http://www.proyectosagiles.org/que-es -scrum

[43] MTC - Transparencia

http://www.peru.gob.pe/normas/docs/LEY_27806.pdf

[44] Estadísticas del MTC

http://www.mtc.gob.pe/portal/ogpp/estudios.html

[45] INEI – Infracciones de Tránsito

http://www.inei.gob.pe/estadisticas/indice-tematico/seguridad-ciudadana/

[46] INEI – Número de Comisarias

http://www.inei.gob.pe/media/MenuRecursivo/censos/cenacomResultadosDefinitivos/libro.pdf

153
Anexos:
Anexo 1
Cod Infracción Grav. S/. Con Sanción Puntos Medida
descuen Preventiva
to*
G01 Adelantar o sobrepasar en forma Grave 304.00 51.68 M ulta 20
indebida a otro vehículo.
G02 No hacer señales, ni tomar las Grave 304.00 51.68 M ulta 20
precauciones para girar, voltear en U,
pasar de un carril de la calzada a otro
o detener el vehículo.
G03 Detener el vehículo bruscamente sin Grave 304.00 51.68 M ulta 20
motivo.
G04 No detenerse antes de la línea de Grave 304.00 51.68 M ulta 20
parada o antes de las áreas de
intersección de calzadas o no respetar
el derecho de paso del peatón.
G05 No mantener una distancia suficiente, Grave 304.00 51.68 M ulta 20
razonable y prudente, de acuerdo al
tipo de vehículo y la vía por la que se
conduce, mientras se desplaza o al
detenerse detrás de otro.
G06 No ubicar el vehículo con la debida Grave 304.00 51.68 M ulta 20
anticipación en el carril donde va
efectuar el giro o volteo.
G07 No conducir por el carril de extremo Grave 304.00 51.68 M ulta 20
derecho de la calzada un vehículo del
servicio de transporte público de
pasajeros o de carga o de
desplazamiento lento o un vehículo
automotor menor.
G08 No utilizar el carril derecho para Grave 304.00 51.68 M ulta 20
recoger o dejar pasajeros o carga.
G09 Retroceder, salvo casos indispensables Grave 304.00 51.68 M ulta 20
para mantener libre la circulación,
para incorporarse a ella o para
estacionar el vehículo.
G10 Incumplir las disposiciones sobre el Grave 304.00 51.68 M ulta 20
uso de las vías de tránsito rápido y/o
de acceso restringido.
G11 Circular, estacionar o detenerse sobre Grave 304.00 51.68 M ulta 20 Remoción del
una isla de encauzamiento, vehículo
canalizadora, de refugio o divisoria
del tránsito, marcas delimitadoras de
carriles, separadores centrales,
bermas, aceras, áreas verdes, pasos
peatonales, jardines o rampas para
minusválidos.
G12 Girar estando el semáforo con luz roja Grave 304.00 51.68 M ulta 20
y flecha verde, sin respetar el derecho
preferente de paso de los peatones.
G13 Conducir un vehículo con mayor Grave 304.00 51.68 M ulta 20
número de personas al número de
asientos señalado en la Tarjeta de
Identificación Vehicular, con
excepción de niños en brazos en los
asientos posteriores; y, llevar
pasajeros de pie en vehículos del
servicio público de transporte urbano

154
 de pasajeros si la altura interior del
vehículo es menor a 1.80 metros.
G14 Tener la puerta, capot o maletera del Grave 304.00 51.68 M ulta 20
vehículo abierta, cuando el vehículo
está en marcha.
G15 No utilizar las luces intermitentes de Grave 304.00 51.68 M ulta 20
emergencia de un vehículo cuando se
detiene por razones de fuerza mayor,
obstaculizando el tránsito, o no
colocar los dispositivos de seguridad
reglamentarios cuando el vehículo
queda inmovilizado en la vía pública.
G16 Conducir un vehículo por una vía en la Grave 304.00 51.68 M ulta 20
cual no está permitida la circulación o
sobre mangueras contra incendio.
G17 Conducir vehículos que tengan lunas o Grave 304.00 51.68 M ulta 20 Retención del
vidrios polarizados o acondicionados vehículo
de modo tal que impidan la visibilidad
del interior del vehículo, sin la
autorización correspondiente.
G18 Conducir un vehículo haciendo uso de Grave 304.00 51.68 M ulta 20
teléfono celular, radio portátil o
similar o cualquier otro objeto que
impida tener ambas manos sobre el
volante de dirección.
G19 Conducir un vehículo de la categoría M Grave 304.00 51.68 M ulta 20 Retención del
o N que carezca de vidrios de vehículo
seguridad reglamentarios o que su
parabrisas se encuentre deteriorado,
trizado o con objetos impresos,
calcomanías, carteles u otros
elementos en el área de barrido del
limpiaparabrisas y que impidan la
visibilidad del conductor o un vehículo
de la categoría L5 que contando con
parabrisas, micas o similares, tengan
objetos impresos, calcomanías,
carteles u otros elementos que
impidan la visibilidad del conductor.
G20 Conducir un vehículo que no cuenta Grave 304.00 51.68 M ulta 20 Retención del
con las luces y dispositivos vehículo
retrorreflectivos previstos en los
reglamentos pertinentes.
G21 Conducir un vehículo sin espejos Grave 304.00 51.68 M ulta 20 Retención del
retrovisores. vehículo
G22 Conducir un vehículo cuando llueve, Grave 304.00 51.68 M ulta 20 Retención del
llovizne o garue, sin tener operativo el vehículo
sistema de limpiaparabrisas.
G23 Conducir un vehículo del servicio de Grave 304.00 51.68 M ulta 20
transporte público urbano de
pasajeros con personas de pie, si la
altura interior del vehículo no supera
a 1,80 metros.
G24 Conducir un vehículo con el motor en Grave 304.00 51.68 M ulta 20
punto neutro o apagado.
G25 Conducir un vehículo sin portar el Grave 304.00 51.68 M ulta 20 Retención del
certificado del Seguro Obligatorio de vehículo
Accidentes de Tránsito o Certificado
Contra Accidentes de Tránsito, o que
éstos no correspondan al uso del
vehículo.

155
G26 Conducir un vehículo de la categoría M Grave 304.00 51.68 M ulta 20 Retención del
o N con la salida del tubo de escape vehículo
en la parte lateral derecha, de modo
tal que las emisiones o gases sean
expulsados hacia la acera por donde
circulan los peatones.
G27 Conducir un vehículo cuya carga o Grave 304.00 51.68 M ulta 20
pasajeros obstruya la visibilidad de los
espejos laterales.
G28 En vehículos de las categorías M y N, Grave 304.00 51.68 M ulta 20
no llevar puesto el cinturón de
seguridad y/o permitir que los
ocupantes del vehículo no lo utilicen
en los casos en que, de acuerdo a las
normas vigentes, exista tal obligación.
En vehículos automotores de la
categoría L5 no contar con cinturones
de seguridad para los asientos de los
pasajeros o no tener uno o más
soportes fijados a su estructura que
permitan a los pasajeros asirse de
ellos mientras son transportados.
G29 Circular en forma desordenada o Grave 304.00 51.68 M ulta 20
haciendo maniobras peligrosas.
G30 Circular transportando personas en la Grave 304.00 51.68 M ulta 20
parte exterior de la carrocería o
permitir que sobresalga parte del
cuerpo de la(s) persona(s)
transportada(s) en el vehículo.
G31 En las vías públicas urbanas, circular Grave 304.00 51.68 M ulta 20
en la noche o cuando la luz natural
sea insuficiente o cuando las
condiciones de visibilidad sean
escasas, sin tener encendido el
sistema de luces reglamentarias; o en
la red vial nacional y departamental o
regional, circular sin tener las luces
bajas encendidas durante las
veinticuatro (24) horas.
G32 Circular por vías o pistas exclusivas Grave 304.00 51.68 M ulta 20 Remoción del
para bicicletas. vehículo
G33 Circular transportando cargas que Grave 304.00 51.68 M ulta 20 Retención del
sobrepasen las dimensiones de la vehículo
carrocería o que se encuentren
ubicadas fuera de la misma; o
transportar materiales sueltos, fluidos
u otros sin adoptar las medidas de
seguridad que impidan su caída a la
vía.
G34 Remolcar vehículos sin las medidas de Grave 304.00 51.68 M ulta 20
seguridad.
G35 Usar luces altas en vías urbanas o Grave 304.00 51.68 M ulta 20
hacer mal uso de las luces.
G36 Compartir el asiento de conducir con Grave 304.00 51.68 M ulta 20
otra persona, animal o cosa.
G37 No reducir la velocidad al ingresar a Grave 304.00 51.68 M ulta 20
un túnel o cruzar un puente,
intersecciones o calles
congestionadas, cuando transite por
cuestas, cuando se aproxime y tome
una curva o cambie de dirección,

156
 cuando circule por una vía estrecha o
sinuosa, cuando se encuentre con un
vehículo que circula en sentido
contrario o cuando existan peligros
especiales con respecto a los peatones
u otros vehículos o por razones del
clima o condiciones especiales de la
vía.
G38 Transitar lentamente por el carril de Grave 304.00 51.68 M ulta 20
la izquierda, causando congestión o
riesgo o rápidamente por el carril de
la derecha.
G39 Aumentar la velocidad cuando es Grave 304.00 51.68 M ulta 20
alcanzado por otro vehículo que tiene
la intención de sobrepasarlo o
adelantarlo.
G40 Estacionar el vehículo en zonas Grave 304.00 51.68 M ulta 20 Remoción del
prohibidas o rígidas señalizadas o sin vehículo
las señales de seguridad
reglamentarias en caso de
emergencia.
G41 Estacionar o detener el vehículo sobre Grave 304.00 51.68 M ulta 20 Remoción del
la línea demarcatoria de intersección, vehículo
dentro de éstas o en el crucero
peatonal (paso peatonal).
G42 Estacionar frente a la entrada o salida Grave 304.00 51.68 M ulta 20 Remoción del
de garajes, estacionamientos vehículo
públicos, vías privadas o en las salidas
de salas, espectáculos, centros
deportivos en funcionamiento.
G43 Estacionar a una distancia menor de Grave 304.00 51.68 M ulta 20 Remoción del
cinco (5) metros de una bocacalle, de vehículo
las entradas de hospitales o centros
de asistencia médica, cuerpos de
bomberos o de hidrantes de servicio
contra incendios, salvo los vehículos
relacionados a la función del local.
G44 Estacionar a menos de tres (3) metros Grave 304.00 51.68 M ulta 20 Remoción del
de las puertas de establecimientos vehículo
educacionales, teatros, iglesias y
hoteles, salvo los vehículos
relacionados a la función del local.
G45 Estacionar a menos de veinte (20) Grave 304.00 51.68 M ulta 20 Remoción del
metros de un cruce ferroviario a nivel. vehículo
G46 Estacionar en zonas no permitidas por Grave 304.00 51.68 M ulta 20 Remoción del
la autoridad competente, a menos de vehículo
diez (10) metros de un cruce peatonal
o de un paradero de buses, así como
en el propio sitio determinado para la
parada del bus.
G47 Estacionar en lugar que afecte la Grave 304.00 51.68 M ulta 20 Remoción del
operatividad del servicio de vehículo
transporte público de pasajeros o
carga o que afecte la seguridad,
visibilidad o fluidez del tránsito o
impida observar la señalización.
G48 Estacionar un ómnibus, microbus, casa Grave 304.00 51.68 M ulta 20 Remoción del
rodante, camión, remolque, vehículo
semirremolque, plataforma, tanque,
tractocamión, tráiler, volquete o
furgón, en en vías públicas de zona

157
 urbana, excepto en los lugares que
habilite para tal fin la autoridad
competente, mediante la señalización
pertinente.
G49 Estacionar un vehículo de categoría M, Grave 304.00 51.68 M ulta 20
N u O a una distancia menor a un
metro de la parte delantera o
posterior de otro ya estacionado,
salvo cuando se estacione en diagonal
o perpendicular a la vía.
G50 Estacionar en los terminales o Grave 304.00 51.68 M ulta 20 Remoción del
estaciones de ruta, fuera de los vehículo
estacionamientos externos
determinados por la Autoridad
competente.
G51 Estacionar un vehículo automotor por Grave 304.00 51.68 M ulta 20 Remoción del
la noche en lugares donde, por la falta vehículo
de alumbrado público, se impide su
visibilidad, o en el día, cuando, por
lluvia, llovizna o neblina u otro factor,
la visibilidad es escasa, sin mantener
encendidas las luces de
estacionamiento.
G52 Estacionar un vehículo en vías con Grave 304.00 51.68 M ulta 20 Remoción del
pendientes pronunciadas sin asegurar vehículo
su inmovilización.
G53 Desplazar o empujar un vehículo bien Grave 304.00 51.68 M ulta 20
estacionado, con el propósito de
ampliar un espacio o tratar de
estacionar otro vehículo.
G54 Abandonar el vehículo en la vía Grave 304.00 51.68 M ulta 20 Internamiento
pública. del vehículo
G55 Utilizar la vía pública para efectuar Grave 304.00 51.68 M ulta 20 Remoción del
reparaciones, salvo casos de vehículo
emergencia.
G56 Recoger o dejar pasajeros fuera de los Grave 304.00 51.68 M ulta 20
paraderos de ruta autorizados, cuando
existan.
G57 No respetar las señales que rigen el Grave 304.00 51.68 M ulta 20
tránsito, cuyo incumplimiento no se
encuentre tipificado en otra
infracción.
G58 No presentar la Tarjeta de Grave 304.00 51.68 M ulta 20 Retención del
Identificación Vehicular, la Licencia vehículo
de Conducir o el Documento Nacional
de Identidad o documento de
identidad, según corresponda.
G59 Conducir un vehículo de categoría L, Grave 304.00 51.68 M ulta 20 Retención del
con excepción de la categoría L5, sin vehículo
tener puesto el casco de seguridad o
anteojos protectores, en caso de no
tener parabrisas; o permitir que los
demás ocupantes no tengan puesto el
casco de seguridad.
G60 Circular con placas ilegibles o sin Grave 304.00 51.68 M ulta 20 Retención del
iluminación o que tengan adherido vehículo
algún material, que impida su lectura
a través de medios electrónicos,
computarizados u otro tipo de
mecanismos tecnológicos que
permitan verificar la comisión de las

158
 infracciones de tránsito.
G61 No llevar las placas de rodaje en el Grave 304.00 51.68 M ulta 20 Retención del
lugar que corresponde. vehículo
G62 Incumplir con devolver las placas de Grave 304.00 51.68 M ulta 20
exhibición, rotativa o transitoria
dentro de los plazos establecidos en el
Reglamento de Placa Única Nacional
de Rodaje.
G63 Utilizar señales audibles o visibles Grave 304.00 51.68 M ulta 20 Retención del
iguales o similares a las que utilizan vehículo
los vehículos de emergencia o
vehículos oficiales.
G64 Conducir un vehículo cuyas Grave 304.00 51.68 M ulta 20 Retención del
características registrables o vehículo
condiciones técnicas han sido
modificadas, alteradas o agregadas,
atentando contra la seguridad de los
usuarios o por no corresponder los
datos consignados en la Tarjeta de
Identificación Vehicular con los del
vehículo.
G65 No ceder el paso a otros vehículos que Grave 304.00 51.68 M ulta 20
tienen preferencia.
G66 Seguir a los vehículos de emergencia y Grave 304.00 51.68 M ulta 20
vehículos oficiales para avanzar más
rápidamente.
G70 Detener el vehiculo sobre la Grave 304.00 51.68 M ulta 20
demarcación en el pavimento de la
señal "No bloquear cruce"
L01 Dejar mal estacionado el vehículo en Leve 152.00 25.84 M ulta 5
lugares permitidos.
L02 Estacionar un vehículo en zonas de Leve 152.00 25.84 M ulta 5 Remoción del
parqueo destinadas a vehículos que vehículo
transportan a personas con
discapacidad o conducidos por éstos.
L03 Utilizar el Permiso Especial de Leve 152.00 25.84 M ulta 5
Parqueo para Personas con
Discapacidad por parte de una persona
a la cual no le corresponde.
L04 Abrir o dejar abierta la puerta de un Leve 152.00 25.84 M ulta 5
vehículo estacionado, dificultando la
circulación vehicular.
L05 Utilizar el carril de giro a la izquierda Leve 152.00 25.84 M ulta 5
para continuar la marcha en cualquier
dirección que no sea la
específicamente señalada.
L06 Arrojar, depositar o abandonar Leve 152.00 25.84 M ulta 5
objetos o sustancias en la vía pública
que dificulten la circulación.
L07 Utilizar la bocina para llamar la Leve 152.00 25.84 M ulta 5
atención en forma inncesaria.
L08 Hacer uso de bocinas de descarga de Leve 152.00 25.84 M ulta 5
aire comprimido en el ámbito urbano.
M 01 Conducir con presencia de alcohol en M uy 3800.00 3800.00 M ulta y 0 Internamiento
la sangre en proporción mayor a lo Grave cancelación de la del Vehículo y
previsto en el Código Penal, o bajo los licencia de Retención de
efectos de estupefacientes, narcóticos conducir e la Licencia
y/o alucinógenos comprobado con el inhabilitación
exámen respectivo o por negarse al definitiva para
mismo y que haya participado en un obtener licencia
accidente de tránsito.

159
M 02 Conducir con presencia de alcohol en M uy 1900.00 1900.00 M ulta y 0 Internamiento
la sangre en proporción mayor a lo Grave suspensión de la del Vehículo y
previsto en el Código Penal, bajo los licencia de Retención de
efectos de estupefacientes, narcóticos conducir por tres la Licencia
y/o alucinógenos comprobada con el (3) años
examen respectivo o por negarse al
mismo.
M 03 Conducir un vehículo automotor sin M uy 1900.00 1900.00 M ulta e 0 Internamiento
tener licencia de conducir o permiso Grave inhabilitación del vehículo
provisional. para obtener
licencia de
conducir por tres
(3) años
M 04 Conducir vehículos estando la licencia M uy 3800.00 3800.00 M ulta y 0 Internamiento
de conducir retenida, suspendida o Grave suspensión de la del Vehículo y
estando inhabilitado para obtener licencia de Retención de
licencia de conducir. conducir por tres la Licencia
(3) años, si ésta
estuviese
retenida o multa
y cancelación
definitiva de la
licencia de
conducir, si la
licencia estuviere
suspendida
M 05 Conducir un vehículo con Licencia de M uy 1900.00 1900.00 M ulta y 70 Retención del
Conducir cuya clase o categoría no Grave suspensión de la vehículo y
corresponde al vehículo que conduce. licencia de retención de
conducir por un la licencia de
(1) año conducir
M 06 Estacionar en las curvas, puentes, M uy 912.00 912.00 M ulta 60 Remoción del
túneles, zonas estrechas de la vía, Grave vehículo
pasos a nivel, pasos a desnivel en
cambios de rasante, pendientes y
cruces de ferrocarril.
M 07 Participar en competencias de M uy 912.00 912.00 M ulta 60
velocidad en eventos no autorizados. Grave
M 08 Permitir a un menor de edad la M uy 912.00 912.00 M ulta 60 Retención del
conducción de un vehículo automotor, Grave vehículo
sin autorización o permiso provisional.
M 09 Conducir un vehículo con cualquiera M uy 912.00 912.00 M ulta 60 Remoción del
de sus sistemas de dirección, frenos, Grave vehículo
suspensión, luces o eléctrico en mal
estado, previa inspección técnica
vehicular.
M 10 Abastecer de combustible un vehículo M uy 456.00 77.52 M ulta 50
del servicio de transporte público de Grave
pasajeros con personas a bordo del
vehículo.
M 11 Conducir vehículos de las categorías M M uy 456.00 77.52 M ulta 50 Retención del
o N sin parachoques o dispositivo Grave vehículo
antiempotramiento cuando
corresponda; o un vehículo de la
categoría L5 sin parachoques
posterior, conforme a lo establecido
en el Reglamento Nacional de
Vehículos.
M 12 No detenerse al aproximarse a un M uy 456.00 456.00 M ulta 50
vehículo de transporte escolar Grave
debidamente identificado que está

160
 recogiendo o dejando escolares.
M 13 Conducir un vehículo con M uy 456.00 77.52 M ulta 50 Retención del
neumático(s), cuya banda de rodadura Grave vehículo
presente desgaste inferior al
establecido en el Reglamento Nacional
de Vehículos.
M 14 No detenerse al llegar a un cruce M uy 456.00 77.52 M ulta 50
ferroviario a nivel o reiniciar la Grave
marcha sin haber comprobado que no
se aproxima tren o vehículo
ferroviario, o cruzar la vía ferrea por
lugares distintos a los cruces a nivel
establecidos.
M 15 Circular produciendo contaminación M uy 456.00 77.52 M ulta 50 Retención del
en un índice superior a los límites Grave vehículo
máximos permisibles de emisión de
gases contaminantes.
M 16 Circular en sentido contrario al M uy 456.00 456.00 M ulta 50
tránsito autorizado. Grave
M 17 Cruzar una intersección o girar, M uy 456.00 456.00 M ulta 50
estando el semáforo con luz roja y no Grave
existiendo la indicación en contrario.
M 18 Desobedecer las indicaciones del M uy 456.00 77.52 M ulta 50
efectivo de la Policía Nacional del Grave
Perú asignado al control del tránsito.
M 19 Conducir vehículos sin cumplir con las M uy 456.00 77.52 M ulta 50 Retención del
restricciones que consigna la Licencia Grave vehículo
de Conducir.
M 20 No respetar los límites máximo o M uy 456.00 456.00 M ulta 50
mínimo de velocidad establecidos. Grave
M 21 Estacionar interrumpiendo totalmente M uy 456.00 456.00 M ulta 50 Remoción del
el tránsito. Grave vehículo
M 22 Detenerse para cargar o descargar M uy 456.00 77.52 M ulta 50 Remoción del
mercancías en la calzada y/o en los Grave vehículo
lugares que puedan constituir un
peligro u obstáculo o interrumpan la
circulación.
M 23 Estacionar o detener el vehículo en el M uy 456.00 456.00 M ulta 50 Remoción del
carril de circulación, en carreteras o Grave vehículo
caminos donde existe berma lateral.
M 24 Circular sin placas de rodaje o sin el M uy 456.00 77.52 M ulta 50 Retención del
permiso correspondiente. Grave vehículo
M 25 No dar preferencia de paso a los M uy 456.00 77.52 M ulta 50
vehíuclos de emergencia y vehículos Grave
oficiales cuando hagan uso de sus
señales audibles y visibles.
M 26 Conducir un vehículo especial que no M uy 456.00 77.52 M ulta 50 Retención del
se ajuste a las exigencias Grave vehículo
reglamentarias sin la autorización
correspondiente.
M 27 Conducir un vehículo que no cuente M uy 1900.00 1900.00 M ulta 50 Internamiento
con el certificado de aprobación de Grave del vehículo
inspección técnica vehicular.
M 28 Conducir un vehículo sin contar con la M uy 456.00 456.00 M ulta 50 Retención del
póliza del Seguro Obligatorio de Grave vehículo
Accidentes de Tránsito, o Certificado
de Accidentes de Tránsito, cuando
corresponda, o éstos no se encuentren
vigente.
M 29 Deteriorar intencionalmente, M uy 456.00 456.00 M ulta 50 Retención del
adulterar, destruir o sustraer las Grave vehículo

161
 Placas de exhibición, rotativa o
transitoria.
M 30 Usar las placas de exhibición, rotativa M uy 456.00 77.52 M ulta 50 Retención del
o transitoria fuera del plazo, horario o Grave vehículo
ruta establecida o cuando esta ha
caducado o ha sido invalidada.
M 31 Utilizar las placas de exhibición, M uy 456.00 456.00 M ulta 50 Retención del
rotativa o transitoria en vehículos a Grave vehículo
los que no se encuentren asignadas.
M 32 Tramitar u obtener duplicado, M uy 456.00 456.00 M ulta y 50 Retención de
recategorización, revalidación, canje Grave Suspensión de la la licencia
o nueva licencia de conducir de licencia de
cualquier clase, por el infractor cuya conducir por el
licencia de conducir se encuentre doble del tiempo
retenida, suspendida o cancelada o se que se
encuentre inhabilitado para encontraba
obtenerla. suspendida; o
multa y la
inhabilitación
definitiva del
conductor, si la
licencia de
conducir se
encontraba
cancelada o el
conductor estaba
inhabilitado
M 33 Operar maquinaria especial por la vía M uy 456.00 77.52 M ulta 50 Remoción del
pública. Grave vehículo
M 34 Circular produciendo ruidos que M uy 456.00 77.52 M ulta 50
superen los límites máximos Grave
permisibles.
M 35 Voltear en U sobre la misma calzada, M uy 456.00 77.52 M ulta 50
en las curvas, puentes, pasos a Grave
desnivel, vías expresas, túneles,
estructuras elevadas, cima de cuesta,
cruce ferroviario a nivel.
M 36 Transportar carga sin los dispositivos M uy 456.00 77.52 M ulta 50 Retención del
de sujeción o seguridad establecidos. Grave vehículo
M 37 Conducir y ocasionar un accidente de M uy .00 .00 Suspensión de la 50 Internamiento
tránsito con daños personales Grave licencia de del Vehículo y
inobservando las normas de tránsito conducir por un Retención de
dispuestas en el presente Reglamento. (1) año la Licencia
M 38 Conducir un vehículo para el servicio M uy .00 .00 Suspensión de la 0 Internamiento
de transporte público y ocasionar un Grave licencia de del Vehículo y
accidente de tránsito con daños conducir por tres Retención de
personales inobservando las normas de (3) años la Licencia
tránsito dispuestas por el presente
Reglamento.
M 39 Conducir y ocasionar un accidente de M uy .00 .00 Cancelación e 0 Internamiento
tránsito con lesiones graves o muerte Grave inhabilitación del Vehículo y
inobservando las normas de tránsito definitiva del Retención de
dispuestas en el presente Reglamento. conductor para la licencia
obtener una
licencia de
conducir

Anexo 2:

162
 INFRACCIONES AL REGLAMENTO NACIONAL DE TRÁNSITO REGISTRADAS
POR LA POLICÍA NACIONAL, SEGÚN DEPARTAMENTO, 2010 - 2013

Departamento 2010 2011 2012 2013

Total 949 079 1 738 360 2 276 390 1 753 920

Amazonas 5 003 5 360 10 018 9 086

Áncash 38 216 15 194 15 778 21 195
Apurímac 3 960 3 356 4 353 3 872
Arequipa 36 158 41 336 61 183 67 968
Ayacucho 6 211 9 237 15 596 19 250
Cajamarca 45 064 59 065 44 956 34 769
Callao 4 932 4 873 16 090 23 355
Cusco 71 586 156 983 151 942 158 254
Huancavelica 4 514 2 607 3 184 3 215
Huánuco 6 609 12 718 44 536 47 287
Ica 14 515 18 759 53 013 81 051
Junín 26 093 38 660 46 702 47 137
La Libertad 56 363 68 359 74 308 93 001
Lambayeque 51 483 93 044 115 427 68 289
Lima 435 216 1 004 534 1 287 005 734 330
Loreto 20 002 29 159 78 254 82 144
Madre de Dios 5 913 20 180 21 401 10 810
Moquegua 3 794 5 944 10 133 15 322
Pasco 2 159 2 422 3 776 3 426
Piura 60 920 81 029 101 266 109 390
Puno 9 015 12 892 22 752 19 412
San Martín 16 535 13 834 28 503 33 590
Tacna 8 984 14 893 20 289 16 437
Tumbes 10 499 11 227 30 686 29 043
Ucayali 5 335 12 695 15 239 22 287
Nota: Las infracciones al reglamento nacional de tránsito de parte de vehículos particulares incluyen: no respetar
señales de tránsito, desacato a la autoridad, pasar la luz roja, adelantar indebidamente, circular en sentido
contrario y voltear sin hacer señales. En el caso de los vehículos de servicio público, éste considera: detenerse
en paraderos no autorizados, modificar la ruta sin autorización, no expedir boletos, prestar servicio no autorizado y
no acatar orden policial, entre otros.

Anexo 3:

163
164