El trabajo de tesis presenta el diseño de un prototipo para un sistema móvil que permite a la policía consultar y registrar infracciones de tránsito en tiempo real, facilitando la toma de decisiones. Utiliza una arquitectura SOA para integrar información del Ministerio de Transportes y Comunicaciones (MTC) y la Superintendencia Nacional de Aduanas y de Administración Tributaria (SAT), implementándose con una metodología ágil (Scrum). Su objetivo es reducir el índice de accidentes de tránsito mediante una herramienta eficiente que proporcione datos relevantes durante las intervenciones a conductores.

1. UNIVERSIDAD TECNOLÓGICA DEL PERÚ
FACULTAD DE INGENIERÍA INDUSTRIAL Y DE SISTEMAS
CARRERA PROFESIONAL: INGENIERÍA DE SISTEMAS
TÍTULO:
“DISEÑO DE UN PROTOTIPO PARA UN SISTEMA MÓVIL DE
CONSULTA Y REGISTRO DE DOCUMENTOS DE INFRACCIONES DE
TRÁNSITO”
AUTORES:
 LA ROSA FIGUEROA, ALEJANDRO ELOY
 TERRAZOS LUNA, LUIGY BENEDICTO
DOCENTE:
 PAPA QUIROZ, ERICK ALEX
LIMA – PERÚ
2013

2. II
ÍNDICE GENERAL
(Informe de tesis)
INDICE GENERAL…...………………………………………………………………………..II
DEDICATORIA………………………….…………………………………………..…..…III, IV
AGRADECIMIENTO………………………………………………………………………..….V
RESUMEN……………………………………………………………………………………...VI
ABSTRACT……………………………………………………………………………………VII
INTRODUCCIÓN………………………………………………………………………….....VIII
1. CAPÍTULO I: INTRODUCCIÓN
1.1. Planteamiento del problema…...………………………………………………………..IX
1.2. Motivación y justificación…...………………………………………………………...…XII
1.3. Antecedentes de la Investigación…...………………………………………………...XIII
1.4. Objetivos…...………………………………………………………………..……….…XVII
1.5. Contribuciones del trabajo…...…………………………………………………….….XVII
2. CAPÍTULO II: MARCO TEÓRICO.
2.1. Marco Metodológico…...…………………………………………………………….....XIX
2.2. Marco Tecnológico…...………………………………………………………………..XXV
2.3. Marco Metodológico del modelo de validación…...……………..………………...XXXI
3. CAPÍTULO III: DISEÑO DE LA SOLUCIÓN
3.1. Metodología a aplicar………………………………………………………………..XXXV
3.2. Análisis del problema……………………………………………………………………...L
3.3. Diseño de la propuesta………………………………………………………………….LII
4. CAPÍTULO IV: VALIDACIÓN DEL MODELO
4.1. Instrumentos y técnicas
4.2. Diseño del prototipo
4.3. Viabilidad del proyecto
5. CAPÍTULO V: CONCLUSIONES Y RECOMENDACIONES.
5.1. Conclusiones
5.2. Recomendaciones
REFERENCIAS
APÉNDICES
ANEXOS

3. III
DEDICATORIA
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 mi
hermano por ser un gran ejemplo y sus
consejos, 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 de
tesis Luigy por brindarme la oportunidad
de formar parte de este equipo.
Alejandro E. La Rosa Figueroa

4. IV
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 Alejandro por
soportar la presión y por dar toda la
dedicación para nuestro proyecto. Como
también a la familia de MLV Contadores,
donde di mi primer paso en hacer proyectos
muy interesantes, a la familia de Mi Farma
donde pase poco tiempo pero aprendí
mucho y también a la familia de Belcorp
donde cada día aprendo más.
Luigy B. Terrazos Luna

5. V
RESUMEN
El presente trabajo de tesis "Diseño de un prototipo para un sistema
móvil de consulta y registro de documentos de infracciones de tránsito"
fue realizado con el fin de crear un prototipo de un sistema móvil para la
policía y que pueda comprobar que teniendo la información en el tiempo
de intervención al conductor pueda tomar una buena decisión.
Para nuestra arquitectura de datos usaremos SOA integrando la
información de las entidades relacionadas (MTC y SAT) con la policía
(PNP), y para el desarrollo del prototipo utilizaremos como metodología
de desarrollo de software una metodología ágil (SCRUM).
Nuestra plataforma será un entorno web móvil y funcionará en cualquier
dispositivo móvil, que será programado con el lenguaje Java, y
aplicando las buenas prácticas, como también las pruebas unitarias y
accederemos a los datos mediante Servicio Web.

6. VI
ABSTRACT
The present thesis work "Design of a prototype for mobile system
consultation document traffic violations" was performed in order to
create a prototype of a mobile system for police and you can see that
having the information in time intervention the driver can make a good
decision.
For our data we will use SOA architecture integrating information related
entities (MTC and SAT) Police (PNP), and for use as prototype
development methodology software development an agile methodology
(SCRUM).
Our platform will be a mobile web environment and work on any mobile
device, which is programmed with the Java language, and applying best
practices, as well as unit testing and will access data using Web
Services.

7. VII
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 Erick Papa Quiroz por sus correcciones
y dedicación para seguir con nuestros objetivos.
A los jurados de tesis los cuales nos ayudan a ver
nuestros errores y a pulir nuestras ideas.

8. VIII
CAPÍTULO I: 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
que cuando comete una infracción y es intervenido por un policía solo se atina a
seguir registrando la infracción mas no tomar la medida correspondiente como
sancionarlo por sobrepasar los puntos permitidos para conducir y esto se debe a
que no cuentan con ninguna herramienta que les pueda ayudar.
Para esto se plantea diseñar un sistema móvil de consultas donde esté conectado
a la base de datos del Ministerio de Transportes y Comunicaciones (MTC) para
obtener el historial de infracciones, los puntos que tiene en ese momento, el
estado de su licencia y si esta licencia en verdad es la original.
También esté conectado al Servicio de Administración Tributaria (SAT) para ver si
el vehículo que está conduciendo tiene deudas de tributos o que tenga alguna
contradicción de información con la tarjeta de propiedad.
Este sistema ayudaría a los policías de tránsito a prevenir accidente futuros ya que
con la información a tiempo se podría tomar la medida correspondiente y no
esperar a que la cifras de accidentes de tránsito sigan en aumento.

9. IX
1.1PLANTEAMIENTO 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) [1], 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) [2], 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”) [3].
Figura #1: Número de Accidentes en Perú – (Trimestre 2010 – 2012)
Fuente: Instituto Nacional de Estadística e Informática - INEI.
Y es cuando sucede un accidente donde se dan cuenta que el conductor tenía
muchas papeletas en su historial y nunca le quitaron la licencia de conducir.
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.

10. X
La intervención del policía al conductor se realiza de la siguiente manera:
- Se le pide el DNI y la licencia de conducir, ahí 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, ya que no todo los policías
se encuentran en la capacidad de afirmar que los documentos sean
verdaderos, para esto tiene 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 alguna deuda de tributos que la haya
pagado.
- 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) [4]
ocasionando que se formen colas de automóviles y generar tráfico, con una
herramienta como la propuesta de podría reducir el tiempo ya que solo con el
DNI y el Nro. de placa del automóvil podría obtener toda la información para
poder registrar la multa.
Al no tener el historial de cada conductor no se tiene un registro correcto de
multas, en el caso de que el conductor haya salido rápido de su casa y
olvidado la licencia de conducir, al ser detenido por un policía este podría
registrar el incidente y para como “Ley de la duda”, a la segunda que suceda
lo mismo se generaría la multa al conductor sin reclamo alguno ya que el
conductor esta consiente de que se le dio una oportunidad y no aprendió la
lección.

11. XI
Figura #2: Diagrama de Causa – Efecto “Accidentes de Tránsito”
Descripción: Representación gráfica de los factores tecnológicos probables que generan
accidentes de tránsito.
Fuente: Elaboración Propia

12. XII
1.2MOTIVACIÓN Y JUSTIFICACIÓN
1.2.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 e incluso que no cuentan con brevete porque se les retuvo
anteriormente.
A este problema se le suma la falta de herramientas que no cuentan los
policías para descubrir si un conductor tiene papeletas vencidas y que
siguen imprudentemente manejando y causando accidentes de tránsito que
muchas veces acaban en tragedias mortales.
1.2.2 JUSTIFICACIÓN:
El diseño de este sistema tendrá el propósito de disminuir la tasa de
accidentes de tránsito y disminuir la tasa de mortalidad.
Se busca la integración de las bases de datos del MTC y SAT con la PNP.
Se anhela presentar este proyecto al congreso para que se pueda obtener
fondos y poder desarrollarse, ya que se necesitan de muchos factores
económicos y de permisos para acceder a la información del MTC y del
SAT.

13. XIII
1.3ANTECEDENTES DE LA INVESTIGACIÓN
1.3.1 SISTEMA UNIFICADO NACIONAL AUTOMATIZADO DE MOVILIDAD
E INFORMACIÓN – SUNAMI
La Policía Nacional de Colombia dio 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). [5]
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. [5]
Figura #3: Central telefónica de la Policía de Colombia para la consulta de documentos.
Fuente: Policía Nacional de Colombia [5]

14. XIV
Figura #4: Teléfono celular con el sistema de la Policía de Colombia e impresora para
generar las papeletas.
2
Fuente: Policía Nacional de Colombia [5]

15. XV
1.3.2 ADMINISTRACIÓN DEL REGISTRO DE DENUNCIAS DE LA
COMISARIA PNP - LA VICTORIA, A TRAVÉS DE UN DE UN SISTEMA DE
INFORMACIÓN CON METODOLOGÍA RUP, PARA LA CLASIFICACION Y
MEJORA DEL SERVICIO A LA COMUNIDAD
En el presente trabajo de tesis ha utilizado como herramienta metodológica
UML y como herramienta de sistematización a RUP para la elaboración de
diagramas por otro lado, las herramientas que se utilizaran serán: Visual
Studio .Net y Base de Datos en SQL Server para el desarrollo del sistema, de
tal forma el sistema permita la flexibilidad y agilización en los procesos de
registros de denuncias y a su vez la obtención de datos estadísticos,
presentación del mapa del delito en un entorno real, con estadísticas reales y
complejas de datos cuantitativos y descriptivos y en tiempo real a partir de
una base de datos a través de una interfaz tecnológico-virtual para ser
utilizado en las dependencias policiales. [6]
Su objetivo principal se basa en la administración del registro de denuncias
de la comisaria PNP de La Victoria, a través de un Sistema de Información
con metodología RUP, para la clasificación y mejora en el servicio a la
comunidad. [6]
Tiene objetivos específicos los siguientes:
a) Establecer los principales indicadores relacionados con la lucha contra
la criminalidad, a nivel de las operaciones policiales.
b) Modelar los datos necesarios involucrados en el registro de las
denuncias, para diseñar del modelo a realizar.
c) Modelar los datos de los denuncias a través de la metodología RUP
d) Diseñar de la estructura del Sistema de Registros de Denuncias, que
permita mejorar los procesos en la comisaria.
e) Diseñar e implementar la base de datos del sistema a implantar.
f) Evaluar del estudio económico costo – beneficio para determinar la
factibilidad de implementar un sistema de información. [6]

16. XVI
La metodología a utilizar es RUP:
Fase de inicio:
El propósito general en esta fase es establecer los objetivos para el ciclo
de vida del producto software a implementar. Durante esta fase se
definirá el modelo del negocio y el alcance del proyecto. Se identificaran
todos los actores y casos de uso. [6]
Modelado del Negocio:
El modelado del negocio es un modelo que provee la vista estática de la
estructura de la organización y una vista dinámica dentro de los procesos
de la organización, el primer flujo de trabajo o disciplina de la
metodología RUP, y consiste en conocer la estructura y la dinámica de
la organización, así como conocer los problemas actuales e identificar
mejoras dentro de la organización.
Para lograr estos objetivos, el modelado de negocio describirá como
desarrollar una visión de la nueva organización, basado en esta visión se
definirán procesos, roles y responsabilidades de la institución por medio
de un Modelo de Casos de Uso del Negocio. Los artefactos del modelo
de negocio servirán como entrada y referencia para la definición de los
requerimientos del sistema. [6]
Herramientas Tecnológicas utilizadas:
a. Windows Server
b. Internet Information Server (IIS)
c. Visual Studio 2005
d. .Net Framework
e. Microsoft SQL Server 2005
f. Visual Basic. Net
g. Microsoft Chart Controls
h. Libraries API
i. Rational Rose [6]

17. XVII
1.4 OBJETIVOS
1.4.1 OBJETIVO GENERAL
 Diseño de un prototipo de sistema móvil para presentar como solución al
alto índice de accidentes de tránsito
1.4.2 OBJETIVOS ESPECÍFICOS
 Integrar las base de datos de las entidades del MTC y del SAT.
 Normalizar la información luego de integrar las bases de datos.
 Brindar una herramienta tecnológica para poder reducir tiempos y recursos.
 Utilización de una metodología ágil para el desarrollo del prototipo de
software.
 Validación del modelo propuesto.
1.5 CONTRIBUCACIONES DEL TRABAJO
1.5.1 PROPUESTA DE LA SOLUCIÓN:
Teniendo en cuenta las tasas de accidentes de tránsito que son muy altas y
observando el tráfico que se genera cuando se hace una intervención a un
vehículo, se plantea una solución para reducir el tiempo y tasa de accidentes
de tránsito generado por diversos factores diseñando un sistema móvil para
hacer consultas en el tiempo requerido.
Se presenta la siguiente solución a la problemática:
- Diseño un prototipo de sistema móvil que será desarrollado en el lenguaje
de programación JAVA para sistemas operativos móviles
- Usar metodologías agiles para plantear la forma de trabajar.
- La arquitectura del sistema será entorno web, para no sobre cargar el
celular y poder acceder de celulares de gama baja , las especificaciones
mínimas del celular serán las siguientes:
 Conexión a internet.
 Sistema operativo móvil con navegador actualizado.
 Memoria RAM de 256 MB.
 Memoria de almacenamiento 4GB.

18. XVIII
Para la propuesta se tendrá que pedir autorización para acceder a la base de
datos del MTC y del SAT, como es una información pública no se tendrá
ningún inconveniente y según las autoridades del INSUTRA el Ministerio del
Interior se pondría poner en contacto con las entidades correspondientes
para pedir el acceso.
1.5.2 ALCANCE DE LA SOLUCIÓN:
Este proyecto está orientado a la Policía de Tránsito de Lima Metropolitana y
funcionara de la siguiente manera:
- Se ingresar el DNI de la persona y nos retornara el historial de papeletas
del conductor, los puntos actuales, y el estado de su licencia.
- Se ingresara la placa del vehículo y retornara el estado de los vehículos
como si está al día con los impuestos.
Figura #5: Teléfono celular con SO Android simulando una interfaz de reporte
Fuente: Elaboración Propia

19. XIX
CAPÍTULO II: MARCO TEÓRICO
2.1 MARCO TEÓRICO
2.1.1 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. [7]
La VII-DIRTEPOL a través de 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 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. [7]
FUNCIONES DE LA DIVPOLTRAN:
1. 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.
2. Planear, organizar, dirigir, controlar y ejecutar las actividades asignadas
a las Áreas de Administración de Personal, Inteligencia, Operaciones,
Instrucción y Logística.
3. Mantener el libre tránsito de vehículos, pasajeros y carga en las vías
públicas, urbanas y férreas.
4. Controlar el tránsito vehicular y dar seguridad en las vías urbanas y vías
férreas.
5. Prevenir e investigar los accidentes de tránsito y el robo de vehículos.
6. Proponer al Comando Institucional, normas y directivas relacionadas
con la disminución de la problemática del tránsito y seguridad vial.
7. Mantener buenas relaciones con las Autoridades del sector público y
privado, para lograr la colaboración en el ejercicio de sus funciones. [7]

20. XX
2.1.2 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.
[8]
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. [8]
 1,100 millones de escritorios ejecutan Oracle Java
 930 millones de descargas de Java Runtime Environment cada año
 3 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. [8]
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: [8]
 Escribir software en una plataforma y ejecutarla virtualmente en otra
 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. [8]

21. XXI
2.1.3 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. [9]
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. [9]
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. [9]
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. [9]

22. XXII
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: [9]
 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. [9]
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. [9]
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.
 Facilidad para la integración de tecnologías disímiles. [9]

23. XXIII
2.1.4 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. [10]
2.1.4.1 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. [10]
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. [10]
2.1.4.2 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. [10]

24. XXIV
2.1.4.3 CARGA
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. [10]
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. [10]
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.). [10]
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. [10]

25. XXV
2.2 MARCO TECNOLÓGICO
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. [11]
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. [11]
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. [11]
Fácilmente gestiona ciclo de vida completo de la información para la mayor de las
bases de datos.
2.2.2 JDBC
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. [12]

26. XXVI
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. [12]
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. [12]
2.2.3 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. [13]
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. [13]
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. [13]
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. [13]

27. XXVII
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. [13]
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. [13]
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. [13]
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 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. [13]
Se espera que para los próximos años mejoren la calidad y cantidad de
servicios ofrecidos basados en los nuevos estándares. [13]

28. XXVII
I
2.2.4 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. [14]
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 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. [14]
 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. [14]
 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. [14]

29. XXIX
 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. [14]
Arquitectura E-LT:
ODI modifica el tradicional concepto ETL (Extract, Transform, Load), pasando
a E-LT (Extract – Load, Transform). La arquitectura E-LT extrae los datos de
los sistemas fuente, los carga en base de datos y realiza todas las
transformaciones en la propia base de datos. [14]
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. [14]
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. [14]
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
necesidad de invertir mucho tiempo en los aspectos técnicos relativos a la
implementación de estas transformaciones. [14]

30. XXX
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. [14]
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. [14]
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,
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. [14]
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. [14]
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. [14]

31. XXXI
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. [14]
2.2.5 ORACLE SOA
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. [15]
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. [15]
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 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: [15]
• 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 rutear 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. [15]

32. XXXII
• 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. [15]
2.2.6 ORACLE SERVICES 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. [16]
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 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. [16]
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. [16]

33. XXXII
I
2.2.7 ERWIN DATA MODELER
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. [17]
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. [17]
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. [17]
2.2.8 JUSTINMIND PROTOTYPER 5.5.0
Justinmind Prototyper es una herramienta de creación de prototipos de
software y de alta fidelidad web wireframes. Se ofrece capacidades que se
encuentran típicamente en las herramientas de creación de diagramas como
arrastrar y soltar la colocación, re-tamaño, el formato y la exportación /
importación de widgets. Además, cuenta con funciones para anotar los
widgets y la definición de las interacciones, como enlaces, animaciones,
vinculando condicionales, cálculos, simulación de controles de pestañas,
mostrar / ocultar los elementos de base de datos y simulación. Hay soporte
para simulación de alta fidelidad de aplicaciones dinámicas de Internet.
Justinmind Prototyper se puede generar prototipos y especificaciones HTML
de Microsoft Word. [18]
De alta fidelidad de Prototipos
El programa crea de alta fidelidad prototipos un paso antes de la primera
versión de una aplicación móvil o sitio web. El prototipo se puede utilizar para
mostrar carretes y propósitos de prueba. Justinmind Prototyper se puede
utilizar para crear prototipos y simulaciones de software sin ningún tipo de
codificación, lo que permite a los no programadores a participar en el
proyecto. [18]

34. XXXI
V
2.3 MARCO METODOLÓGICO DEL MODELO DE VALIDACIÓN
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. [19]
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. [19]
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. [19]
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).
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. [19]

35. XXXV
Figura #6: Proceso de la metodología SCRUM.
Fuente: Metodologías Ágiles [19]
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. [19]
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:
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. [19]
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. [19]

36. XXXV
I
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: [19]
 ¿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? [19]
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. [19]
Inspección y adaptación
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. [19]
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. [19]

37. XXXV
II
3. CAPÍTULO III: DISEÑO DE LA SOLUCIÓN
3.1 METODOLOGÍA A APLICAR
En el presente trabajo se describe de la metodología SCRUM para nuestro
desarrollo de software, basado en las consultas de documentos de infracciones de
tránsito.
Este trabajo incluye un conjunto de procedimiento de ciclo vida interactiva e
incremental para el proyecto de sistema móvil, en donde se inicializan los primeros
requerimientos para las entregas de documentos frecuentes y continuos al dueño
de producto en un mínimo tiempo donde este podrá ver la dimensión completa del
sistema y así realizar mejora continua en el sistema.
En el siguiente cuadro comparativo explicaremos porque utilizaremos la
metodología Scrum en vez de una metodología RUP.
Cuadro #1: Comparación de Metodología SCRUM vs RUP
Metodología SCRUM Metodología RUP
 Colaboración directa con el
cliente
 Negociación de contratos
 Mayor tiempo en la construcción
de software
 Mayor tiempo en
especificaciones
 Menos tiempo en documentación  Documentación exhaustiva
 Adaptación al cambio  El cambio en vez de beneficiar
puede ser una amenaza al
proyecto.
 Respuesta al cambio  Adaptación a un plan
 Mitigación de Riesgos  Mayor riesgo al fracaso.
 Se dan entregables en el
transcurso del proyecto.
 Entregable al final del proyecto.
 Menor tiempo en la construcción
de software.
 Mayor tiempo en la construcción
de software.
 Mayor calidad del software  Baja calidad del software si se
presentan cambios.
Fuente: Elaboración Propia

38. XXXV
III
3.2 HERRAMIENTA PARA DESARROLLAR LA METODOLOGÍA SCRUM
Nuestra herramienta para desarrollar la metodología Scrum será el Trello.
3.2.1 TABLA DE SCRUM
Figura #7: Pizarra Principal de Scrum.
Fuente: www.trello.com
En nuestra figura #7 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”.

39. XXXI
X
3.2.2 SPRINT DONE
Figura #8: Sprint Done (Hecho)
Fuente: www.trello.com
En nuestro sprint “Done” tenemos todas las tareas realizadas y también nos
podemos dar cuenta a quien se le asignó.

40. XL
3.2.2.1 CORRECIÓN DE LA DOCUMENTACIÓN
Figura #9: Tarea – Corrección de la Documentación
Fuente: www.trello.com
Dentro de nuestra tarea “Corrección de la documentación” tenemos nuestras
actividades a realizar.
En esta figura #9 vemos que tenemos tareas que ya se realizaron y que
fueron seleccionadas con el visto de completado.

41. XLI
3.2.2.2 INDUCCIÓN DEL NUEVO INTEGRANTE
Figura #10: Tarea – Inducción de nuevo integrante
Fuente: www.trello.com
En nuestra segunda tarea “Inducción de nuevo integrante” tenemos 7
actividades que fueron completados en su totalidad.
- Inducción sobre documentación de la primera parte del Proyecto. OK
- Cambios y mejoras propuestas. OK
- Inducción en arquitectura. OK
- Comentarios y posibles mejoras. OK
- Inducción sobre SCRUM. OK
- Inducción sobre SOA. OK
- Inducción sobre las herramientas a usar. OK

42. XLII
3.2.2.3 MODELAMIENTOS DE DATOS
Figura #11: Tarea – Modelamientos de datos
Fuente: www.trello.com
En nuestra tarea “Modelamientos de datos” tenemos 4 actividades que
fueron completados en su totalidad.
- Identificar datos canónicos. OK
- Establecer entidades. OK
- Establecer atributos. OK
- Establecer tipo de datos. OK
También podemos observar en la sección “Members” que esta tarea esta
asignado al Scrum Master (Luigy Terrazos) y el miembro del equipo de
Scrum (Alejandro La Rosa).

43. XLIII
3.2.2.4 DISEÑO DE INTERFACES
Figura #12: Tarea – Diseño de Interfaces
Fuente: www.trello.com
En nuestra tarea “Diseño de interfaces” tenemos 8 actividades que fueron
completados en su totalidad.
- Escoger herramienta para el desarrollo. OK
- Desarrollo de interfaz de inicio de sesión. OK
- Desarrollo Interfaz del menú de opciones. OK
- Desarrollo Interfaz de búsqueda del conductor. OK
- Desarrollo Interfaz de historial del conductor. OK
- Desarrollo Interfaz de búsqueda del vehículo. OK
- Desarrollo Interfaz de detalle del vehículo. OK
- Desarrollo Interfaz de Registrar Papeleta. OK

44. XLIV
3.2.3 SPRING DOING
Figura #13: Tarea – Diseño de Interfaces
Fuente: www.trello.com
En nuestro sprint Doing tenemos las tareas que estamos realizando y también
quienes las están realizando.
- Desarrollo del Capítulo 3. Pendiente
- Desarrollo dela Integración de las Bases de datos. Pendiente

45. XLV
3.2.3.1 DESARROLLO DEL CAPÍTULO 3
Figura #14: Tarea – Diseño de Interfaces
Fuente: www.trello.com
En nuestra tarea “Diseño de Interfaces” tenemos 3 actividades se encuentran
realizando y que están a la espera de la confirmación de terminado.
- Metodología a aplicar. Pendiente
- Análisis del problema. Pendiente
- Diseño de la propuesta. Pendiente

46. XLVI
3.2.3.2 DESARROLLO DE LA INTEGRACIÓN DE LAS BASES DE DATOS
Figura #15: Tarea – Desarrollo de integración de las bases de datos
Fuente: www.trello.com
En nuestra tarea “Desarrollo de integración de las bases de datos” tenemos 3
actividades, 2 de ellas están realizadas y 1 se encuentra realizando y a la
espera de la confirmación de terminado.
- Conectar remotamente a los servidores. OK
- Diseño de patrón de actualización. OK
- Diseño de plan de carga. Pendiente

47. XLVII
3.2.4 SPRINT TO DO
Figura #16: Spring To Do
Fuente: www.trello.com
En nuestro sprint To Do nos indica las próximas tareas que deberíamos realizar.
- Desarrollo del capítulo 4. Por hacer
- Desarrollo de la aplicación. Por hacer

48. XLVII
I
3.2.4.1 DESARROLLO DEL CAPÍTULO 4
Figura #17: Tarea – Desarrollo del capítulo 4
Fuente: www.trello.com
En nuestra tarea “Desarrollo del capítulo 4” tenemos 3 actividades que se
deben realizar y que aún no están comenzadas.
- Instrumentos y Técnicas. Por hacer
- Diseño del Prototipo. Por hacer
- Viabilidad del Proyecto. Por hacer

49. XLIX
3.2.4.2 DESARROLLO DE LA APLICACIÓN
Figura #18: Tarea – Desarrollo de la aplicación
Fuente: www.trello.com
En esta figura tenemos 2 actividades generales con sus sub-actividades
respectivamente.
 Desarrollo de las web service. Por hacer
- Seleccionar herramienta a usar.
- Desarrollo de las web services.
- Pruebas de las web services.
- Despliegue de las web services.
 Desarrollo de la aplicación Por hacer
- Desarrollo de la aplicación
- Integración con los web services.
- Pruebas de la aplicación.
- Despliegue de la aplicación.

50. L
3.2 ANÁLISIS DEL PROBLEMA
Para explicar el análisis del problema utilizaremos nuestra figura #2, un Diagrama
de Ishikawa:
Figura #19: Diagrama de Ishikawa
Descripción: Representación gráfica de los factores tecnológicos probables que generan
accidentes de tránsito.
Fuente: Elaboración Propia
3.2.1 Áreas involucradas
a. Policía Nacional del Perú (PNP)
b. Ministerio de Transportes y Comunicaciones (MTC)
c. Servicio de Administración Tributaria (SAT)
3.2.2 Causas
- En nuestro diagrama de Ishikawa tenemos como primer problema que
la Policía Nacional del Perú (PNP) no cuenta con una herramienta
tecnológica de consulta y registro de infracciones de tránsito para para
la intervención de malos conductores que generan accidentes de
tránsito.
- La falta de integración de las bases de datos del MTC y del SAT
hacen posible que no se cuente con una información integrada y
normaliza que le sirva a la policía para realizar su trabajo
eficientemente.

51. LI
Figura #20: Falta de Integración de las BD de la PNP, MTC y SAT.
Fuente: Elaboración Propia
3.2.3 Consecuencias
- Según las estadísticas arrojadas por el INEI esta tendencia de
accidentes de tránsito siguen en aumento, la falta de acciones para
frenar y detener el problema hace que estemos en un incremente de
accidentes con consecuencias mortales.
3.2.4 Delimitaciones
- Nuestro proyecto tiene como prioridad la implementación en la Policía
Nacional del Perú en Lima.
3.2.5 Diagnostico
- La PNP necesita contar con una herramienta tecnológica (Sistemas
Móvil) que le permita consultar el estado de las infracciones de tránsito
y registrar la infracción en el momento ocurrida la falta.
PNP
Policía Nacional del Perú
SAT
Servicio de
Administración Tributaria
MTC
Ministerio de Transportes y
Comunicación

52. LII
3.3 DISEÑO DE LA PROPUESTA
3.3.1 Diseño de la Arquitectura
Figura #21: Integración de las bases de datos
Fuente: Elaboración Propia
Figura #22: Arquitectura de Acceso a datos
Fuente: Elaboración Propia

53. LIII
Figura #23: Interfaz de Usuario
Fuente: Elaboración Propia
Figura #24: Proceso de Soporte Técnico
Fuente: Elaboración Propia

54. LIV
Figura #25: Arquitectura de la solución
Fuente: Elaboración Propia
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 3 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.

55. LV
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
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
[20], 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 actualizaron.

56. 3.3.2 DISEÑO DE LA BASE DE DATOS
3.3.2.1 DISEÑO LÓGICO
Figura #26: Diseño Lógico de la Base de Datos
Fuente: Elaboración Propia

57. 3.3.2.2 DISEÑO FÍSICO
Figura #27: Diseño Físico de la Base de Datos
Fuente: Elaboración Propia

58. LVIII
3.3.2.3 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 #28: ODI – Arquitectura Física
Fuente: Oracle Data Integrator

59. LIX
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.
Mostramos en la siguiente imagen la etapa de conexión:
Figura #29: ODI – Servidor de Datos
Fuente: Oracle Data Integrator
Figura #30: ODI - Controladores
Fuente: Oracle Data Integrator

60. LX
Luego de tener las conexiones de las base de datos procedemos a relacionar
los datos de las otras base de datos, en la siguiente imagen se integra la
base de datos de MTC a la base de datos integrada.
Figura #31: ODI – Integración
Fuente: Oracle Data Integrator
La integración se realizara en la madrugada 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 #32: ODI – Planificación
Fuente: Oracle Data Integrator

61. LXI
REFERENCIAS
[1] INEI – “Estadísticas de Seguridad Ciudadana – A Marzo 2012”
Perú, 49 p, Julio 2012
http://www.inei.gob.pe/web/NotaPrensa/Attach/14685.pdf
[2] 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
[3] 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
[4] Personal del INSUTRA (Instituto Superior de Transito)
[5] 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_-_Buena_prxctica.pdf
[6] Lenin Enrique Quispe Perez – “Administración del registro de denuncias de La Comisaria
PNP - La Victoria, A través de un de un sistema de información con metodología Rup, para
la clasificacion y mejora del servicio a la comunidad.”
Perú, 117p, 2012
www.cip.org.pe/imagenes/temp/tesis/43429822.doc
[7] Policía Nacional del Perú – “División de Policía de Tránsito”
http://www.pnp.gob.pe/dirtepol/7dirtepol/transito/inicio.html
[8] Java – “Conozca más sobre la tecnología Java”
http://www.java.com/es/about/
[9] SOA – “Arquitectura Orientada a Servicios”
http://es.wikipedia.org/wiki/Arquitectura_orientada_a_servicios
[10] ETL - “Extracción, Transformación y Carga”
http://es.wikipedia.org/wiki/Extract,_transform_and_load
[11]Oracle – “Oracle Database 11g Enterprise Edition”
http://www.oracle.com/us/products/database/enterprise-
edition/overview/index.html?ssSourceSiteId=ocomes
[12] JDBC – “¿Qué es JDBC?”
http://www.adictosaltrabajo.com/tutoriales/tutoriales.php?pagina=introjdbc
[13] Servicio Web – “Web Services”
https://es.wikipedia.org/wiki/Servicio_web
[14] Oracle - “Oracle Data Integrator 11g”
http://www.dataprix.com/blogs/juan-vidal/oracle-data-integrator-11g

62. LXII
[15] Oracle – “Oracle SOA Suite”
http://www.oracle.com/technetwork/es/middleware/soasuite/documentation/oracle-soa-suite-
427128-esa.pdf
[16] Oracle – “Oracle Services Bus”
http://www.oracle.com/technetwork/es/middleware/soasuite/documentation/oracle-soa-suite-
427128-esa.pdf
[17] Erwin Data Modeler
http://www.dimensionti.com/prod051.htm
[18] Justinmind Prototyper
http://en.wikipedia.org/wiki/Justinmind_Prototyper
[19] Proyectos Ágiles – “¿Qué es SCRUM?”
http://www.proyectosagiles.org/que-es-scrum
[20] Estadísticas del MTC
http://www.mtc.gob.pe/portal/ogpp/estudios.html