Sidpol - Cervantes Joaquin Huanambal Christian
Sidpol - Cervantes Joaquin Huanambal Christian
Rights info:eu-repo/semantics/openAccess
FACULTAD DE INGENIERÍA
AUTORES
Código 200912117, Joaquín Benito D’ Jesús Cervantes Moreno
Código 200910808, Christian Huanambal Torres
ASESOR
Chumpitaz Avedaño, Max
p ág . 2
Agradecimientos
A Edgar Díaz, excelente maestro, que con su paciencia y enseñanza nos brindó un mejor
panorama de la investigación y a mejorar muchos detalles importantes de este proyecto, es por ello
que lo consideramos como uno de los pocos maestros por excelencia.
A Rosario Villalta, Jimmy Armas y Víctor Parasi, a quienes les dedicamos los mismos honores
por el gran aporte que hacen a la educación universitaria y que como alumnos fuimos testigos.
p ág . 3
Resumen Ejecutivo
El propósito de este proyecto es realizar una mejora al sistema actual de denuncias para la Policía
Nacional del Perú siguiendo las normas y leyes establecidas en el Código Procesal Penal, ante esta
situación surge el proyecto: “Mejora del sistema SIDPOL para la Policía Nacional del Perú”.
Para la validación del modelo se tomó como referencia al Ministerio del Interior, órgano
administrativo que ejerce las funciones del gobierno interior y de la policía a través de los órganos
policiales y no policiales, de la misma forma para mantener y restablecer el orden interno
democrático y el orden público.
Para realizar la mejora al sistema de denuncias de la Policía Nacional del Perú (PNP) se toman en
cuenta cuatro enfoques de la Arquitectura Empresarial, las cuales son Negocio, Aplicaciones,
Datos y Tecnológico. Cada uno de estos enfoques tiene un objetivo: El primero identifica y
optimiza los procesos internos de denuncia de la PNP; el segundo enfoque permite mostrar la
estructura de las interfaces para las aplicaciones que serán desarrolladas posteriormente por la
PNP; en el tercer enfoque modela un diseño base de datos correctamente estructurado y definido.
Por último, el cuarto enfoque se debe considerar y mapear todos los componentes de la
infraestructura tecnológica que cuenta actualmente la PNP.
Finalmente, el proyecto tiene como resultado final una propuesta económica de la implementación
del sistema de denuncias policial para la PNP considerando que todos los componentes
tecnológicos identificados en la Arquitectura Tecnológica estén bajo una nueva infraestructura
tecnológica la cual sea soportada y perdure en el tiempo.
p ág . 4
Abstract
The purpose of this project is to improve the current system of complaints for the Peruvian
National Police following the norms and laws established in the Code of Criminal Procedure, in
view of this situation arises the project: "Mejora del sistema SIDPOL para la Policía Nacional del
Perú". For the validation of the model, the Ministry of the Interior, an administrative authority to
exercises the functions of the internal government and the police through police and non-police
bodies, was taken as a reference in the same way to maintain and restore democratic internal
order, public order.
In order to improve the complaints system of the Peruvian National Police (PNP), we are taken
four approaches to Enterprise Architecture, which are Business, Applications, Data and
Technology, are taken into account. Each of these approaches has an objective: the first identifies
and optimizes the internal complaint processes of the PNP; The second approach allows to show
the structure of the interfaces for the applications that will be developed later by the PNP; In the
third approach it models a correctly structured and defined database design. Finally, the fourth
approach must be considered and mapped all the components of the technological infrastructure
that the PNP currently has.
Finally, the final result of the project is a sensible economic for the implementation of the police
complaint system for the PNP, considering that all the technological components identified in the
Technological Architecture are under a new technological infrastructure that is supported and will
last in time.
p ág . 5
TABLA DE CONTENIDO
Agradecimientos ................................................................................................................................ 3
Resumen Ejecutivo ............................................................................................................................ 4
Abstract .............................................................................................................................................. 5
Introducción ..................................................................................................................................... 22
CAPITULO 1 Descripción del Proyecto ....................................................................................... 24
1.1 Objeto de Estudio................................................................................................................... 25
1.2 Dominio del Problema ........................................................................................................... 26
1.3 Planteamiento de la Solución ................................................................................................. 27
1.4 Objetivos del Proyecto ........................................................................................................... 27
1.4.1 Objetivo General ............................................................................................................. 27
1.4.2 Objetivos Específicos...................................................................................................... 27
1.5 Indicadores de Éxito .............................................................................................................. 28
1.6 Planificación del Proyecto ..................................................................................................... 28
1.6.1 Alcance ........................................................................................................................... 29
1.6.2 Elaboración de la Estructura de desglose de trabajo y diccionario ................................. 29
1.6.3 Plan de Gestión del Tiempo ............................................................................................ 33
1.6.4 Plan de Gestión de Recursos Humanos .......................................................................... 33
1.6.5 Plan de Comunicaciones .................................................................................................37
1.6.6 Plan de Gestión de Riesgos ............................................................................................. 40
CAPITULO 2 Achievments of The Students Outcomes ............................................................... 43
2.1 Student Outcome “A” ............................................................................................................ 44
2.2 Student Outcome “B” ............................................................................................................ 45
2.3 Student Outcome “C” ............................................................................................................ 46
2.4 Student Outcome “D” ............................................................................................................ 47
2.5 Student Outcome “E” .............................................................................................................48
2.6 Student Outcome “F” ............................................................................................................. 49
2.7 Student Outcome “G” ............................................................................................................ 51
2.8 Student Outcome “H” ............................................................................................................ 51
2.9 Student Outcome “I” .............................................................................................................. 52
2.10 Student Outcome “J”............................................................................................................ 52
2.11 Student Outcome “K” .......................................................................................................... 52
p ág . 6
2.12 Comisión de Computación - CAC (j) .................................................................................. 52
CAPITULO 3 Marco Teórico ........................................................................................................ 57
3.1 Definición de Arquitectura de Aplicaciones .......................................................................... 58
3.2 Definición de Arquitectura de Datos ..................................................................................... 58
3.3 Definición de Arquitectura de Negocio ................................................................................. 58
3.4 Definición de Arquitectura de Redes ..................................................................................... 59
3.5 Definición de Arquitectura Empresarial ................................................................................ 59
3.6 Definición de BPMN ............................................................................................................. 60
3.7 Definición de EBM ................................................................................................................ 61
3.8 Definición de Framework Zachman ...................................................................................... 62
3.9 Definición de la herramienta Bizagi ...................................................................................... 63
3.10 Definición de metodología EUP .......................................................................................... 64
CAPITULO 4 Estado del Arte ....................................................................................................... 65
4.1 Revisión de Literatura ............................................................................................................ 66
4.2 Aplicaciones de Arquitectura Empresarial en entidades Gubernamentales y empresas
privadas ........................................................................................................................................ 67
4.2.1 Aplicación de Arquitectura Empresarial en Entidades del Gobierno ............................. 67
4.2.2 Aplicación de Arquitectura de Tecnología de Información en los Gobiernos de América
de Norte .................................................................................................................................... 68
4.2.3 Aplicación de Arquitectura Empresarial en empresas Privadas ..................................... 70
CAPITULO 5 Desarrollo del proyecto .......................................................................................... 72
5.1 Arquitectura de Negocio de SIDPOL .................................................................................... 73
5.1.1 Información de la Empresa – PNP .................................................................................. 73
5.1.2 Diagrama de Objetivo ..................................................................................................... 78
5.1.3 Diagrama Organizacional ............................................................................................... 80
5.1.4 Mapa de Procesos ........................................................................................................... 82
5.1.5 Justificación de Procesos y Objetivos ............................................................................. 84
5.1.6 Modelo de dominio ......................................................................................................... 87
5.1.7 Proceso de denuncia........................................................................................................ 90
5.1.8 Reglas de negocio ......................................................................................................... 124
5.1.9 Mapeo Actor - Proceso .................................................................................................126
5.1.10 Mapeo de Entidad - Proceso ....................................................................................... 128
5.1.11 Matriz de Asignación de Responsabilidades .............................................................. 135
5.1.12 Descomposición Funcional ......................................................................................... 137
p ág . 7
5.1.13 PM - Portafolio de Proyectos ...................................................................................... 143
5.1.14 Diagrama de Paquete .................................................................................................. 144
5.1.15 Malla Relacional por Caso de Uso.............................................................................. 148
5.1.16 Mapeo Proceso – Producto ......................................................................................... 148
5.1.17 Mapeo Proceso – Producto ......................................................................................... 149
5.1.18 Estimación de Esfuerzo...............................................................................................153
5.1.19 Cuadro Control............................................................................................................ 180
5.2 Arquitectura de Aplicaciones de SIDPOL ........................................................................... 185
5.2.1 Matriz Recibe - Envía ................................................................................................... 185
5.2.2 Especificación de Servicios .......................................................................................... 186
5.2.3 Servicios de Aplicación, Negocios y Técnicos ............................................................. 208
5.2.4 Portafolio de Servicios .................................................................................................. 210
5.2.5 Navegabilidad ............................................................................................................... 213
5.2.6 Control de Accesos ....................................................................................................... 215
5.2.7 Interfaces de Usuarios ................................................................................................... 217
5.3 Arquitectura de datos de SIDPOL ....................................................................................... 235
5.3.1 Modelo lógico ............................................................................................................... 235
5.3.2 Modelo Físico ............................................................................................................... 237
5.3.3 Especificación de modelo de datos ............................................................................... 239
5.3.4 Mapa producto - tabla ................................................................................................... 241
5.4 Arquitectura tecnológica de SIDPOL .................................................................................. 243
5.4.1 Diagrama de componentes ............................................................................................ 243
5.4.2 Diagrama de Despliegue ...............................................................................................244
5.4.3 Especificación diagrama de despliegue ........................................................................ 246
5.4.4 Diagrama de red ............................................................................................................ 248
5.5 Plan de implementación ....................................................................................................... 253
5.5.1 Marco Teórico ...............................................................................................................253
5.5.2 Posicionamiento ............................................................................................................ 253
5.5.3 Organización del Proyecto ............................................................................................ 258
5.5.4 Fases e hitos del proyecto ............................................................................................. 264
5.6 Plan de Continuidad ............................................................................................................. 266
5.6.1 Introducción .................................................................................................................. 266
5.6.2 Propuesta económica .................................................................................................... 266
5.6.3 Capacitación .................................................................................................................. 268
p ág . 8
5.6.4. Riesgos y mitigación .................................................................................................... 269
5.6.5 Proyectos de continuidad .............................................................................................. 271
CAPITULO 6 Gestión del Proyecto ............................................................................................ 272
6.1 Producto final .......................................................................................................................273
6.2 Gestión del Tiempo .............................................................................................................. 273
6.3 Gestión de los Recursos Humanos .......................................................................................282
6.4 Gestión de las Comunicaciones ........................................................................................... 283
6.4.1 Comunicaciones del proyecto .......................................................................................283
6.4.2 Procedimiento para la resolución de polémicas ............................................................ 284
6.5 Gestión de los Riesgos .........................................................................................................284
6.5.1 Lista de Responsabilidades ...........................................................................................284
6.5.2 Seguimiento y Control de Riesgos ................................................................................ 285
6.6 Lecciones aprendidas ...........................................................................................................286
Conclusiones .................................................................................................................................. 287
Recomendaciones .......................................................................................................................... 288
Glosario .......................................................................................................................................... 289
Siglario ........................................................................................................................................... 293
Bibliografía .................................................................................................................................... 295
Anexo 1: Acta de compromiso de confidencialidad ...................................................................... 296
Anexo 2: Certificado de aprobación por parte de la empresa virtual Quality Service .................. 297
Anexo 3: Documentos del ciclo 2015-01....................................................................................... 298
Anexo 4: Documentos del ciclo 2016-01....................................................................................... 327
Anexo 5: Clasificador único de denuncias y ocurrencias .............................................................. 357
p ág . 9
Lista de Tablas
p ág . 1 0
Tabla 20 - Tabla de Stakeholders del proceso “Flagrancia delictiva” 110
p ág . 1 1
Tabla 42 – Relaciones Prioridad “Proceso de denuncias” 134
p ág . 1 2
Tabla 64 –UAW Estadísticas Parte I 157
p ág . 1 3
Tabla 86 – UUCP Consulta Denuncia 168
p ág . 1 4
Tabla 108 – Servicio de negocio “RegistrarArma! 194
p ág . 1 5
Tabla 130 –Resumen Servicios 210
p ág . 1 6
Lista de Ilustraciones
Ilustración 9: EUP: Extensión del RUP para reflejar el ciclo de vida completo de un sistema 64
p ág . 1 7
Ilustración 21 - Definición de proceso AS IS “Proceso de Seguridad General” 92
p ág . 1 8
Ilustración 43 - Distribución de trabajo “Denuncias ciudadano” 179
p ág . 1 9
Ilustración 65 – Policía 7 227
p ág . 2 0
Ilustración 87 – Reuniones Profesor Gerente 2015-01 277
p ág . 2 1
Introducción
La Policía Nacional del Perú (PNP) es una institución tutelar del Estado dependiente del
Ministerio del Interior, creada para garantizar el orden interno, la investigación de delitos, el libre
ejercicio de los derechos fundamentales de las personas y el normal desarrollo de las actividades
ciudadanas. Es profesional y jerarquizada. Sus integrantes representan la ley, el orden y la
seguridad en toda la República y tienen competencia para intervenir en todos los asuntos
relacionados con el cumplimiento de su finalidad fundamental.
Por ello, este documento se ha dividido en 6 capítulos. El primer capítulo En este capítulo se
describe a la organización a la cual va dirigida el proyecto, los problemas, las causas, la propuesta
de solución y los indicadores de éxito. Asimismo, se menciona los planes de gestión relacionados
al tiempo, recursos humanos, comunicaciones y riesgos.
El tercer capítulo contiene los elementos conceptuales que sirve como soporte para el desarrollo
del proyecto, que consiste en un análisis de los requerimientos funcionales del sistema actual de
denuncia policial, diseño del proceso de denuncia policial automatizada, la propuesta de las
funciones de negocio integradas y el plan de continuidad apoyado en la Arquitectura empresarial.
p ág . 2 2
El cuarto capítulo, contiene el estado del arte de la mejora del proceso de denuncias del sistema
SIDPOL para la Policía Nacional Del Perú. Este capítulo brinda el estudio del conocimiento
existente relacionado a la problemática planteada en este trabajo, así como las soluciones
propuestas por otros autores donde se ha realizado la búsqueda, análisis y filtrado de artículos
científicos relacionados a este proyecto.
El quinto capítulo, describe el análisis de los requerimientos funcionales con que cuenta el sistema
actual de denuncia policial de la PNP, el diseño del proceso de denuncia automatizado con el
apoyo de la Arquitectura de Negocio, la propuesta de las funciones de negocio integradas a través
de una cartera de proyecto que permita cubrir las necesidad del negocio y la propuesta de un plan
de continuidad para garantizar la operación y soporte del sistema de denuncia con el fin de
optimizar las funcionalidades del sistema SIDPOL para que sea soportado a nivel nacional.
El sexto capítulo describe la gestión del proyecto, donde se evalúa si el resultado corresponde con
el alcance que se planteó al inicio del proyecto, es decir si el desarrollo de la arquitectura
empresarial se realizó según los planes de gestión, tales como el análisis de la gestión del tiempo,
comunicaciones, recursos humanos y los riesgos.
p ág . 2 3
CAPITULO 1 Descripción del Proyecto
p ág . 2 4
1.1 Objeto de Estudio
La Policía Nacional del Perú es una institución del Estado creada para garantizar el orden interno,
el libre ejercicio de los derechos fundamentales de las personas y el normal desarrollo de las
actividades ciudadanas. Es profesional y jerarquizada. Sus integrantes representan la ley, el orden
y la seguridad en toda la República y tienen competencia para intervenir en todos los asuntos que
se relacionan con el cumplimiento de su finalidad fundamental.
p ág . 2 5
1.2 Dominio del Problema
En esta sección se definirán los problemas que afrontan actualmente la Policía Nacional del Perú y el
ciudadano peruano por los cuales se está dando el desarrollo de este proyecto.
En el siguiente cuadro se muestran los problemas que poseen junto con sus respectivas causas:
Problema Causas
Los efectivos policiales trabajan de manera Falta de estándares y metodología para la definición
excesiva con documentos físicos. de procesos (causa asociada a un método).
No existe un control del trabajo en el El sistema actual no tiene una estadística de las
sistema de denuncias. denuncias resueltas/pendientes/abiertas.
Elaboración Propia
Según la información del cuadro anterior, hemos determinado que el principal problema es que el
84.8% de ciudadanos en el Perú no denunciaron el hecho delictivo y el uso excesivo de
documentos físicos en las comisarías, junto con la falta de estándares y metodología para la
definición de procesos. Es por esto, que durante el proyecto se darán oportunidades de mejora a
las actividades del proceso de denuncias en la PNP.
p ág . 2 6
1.3 Planteamiento de la Solución
Para darle solución a los problemas identificados en el punto anterior, se plantea el diseño de la
Arquitectura Empresarial, la cual se tomará 3 de los 4 enfoques (Negocio, Aplicaciones y Datos).
El enfoque de Negocio consigue modelar y optimizar los procesos que posee una empresa. Con
ello, cada área cuenta con sus procesos ordenados e integrados, dándole calidad al negocio.
Por otra parte, el enfoque de Aplicaciones permite tener mapeados los servicios que interactúan
con los procesos de negocio. A su vez, las interfaces de usuario muestran el panorama en el cual
los futuros usuarios del sistema navegarían.
Asimismo, el enfoque de Datos muestra la organización de todos los datos que se almacenaran a
partir de la información que se agregue mediante las interfaces.
OE3. Proponer funciones de negocio integradas que cubran las necesidades del negocio.
OE4. Proponer un plan de continuidad que garantice la operación y soporte del proyecto.
p ág . 2 7
1.5 Indicadores de Éxito
Los indicadores de éxito que justifican el cumplimiento de los objetivos mencionados
anteriormente se presentan a continuación.
Indicador Objetivo
Descripción
de éxito específico
Elaboración propia
p ág . 2 8
1.6.1 Alcance
-En reunión de equipo de proyecto, tanto el gerente profesor, el cliente y los jefes de proyecto
definirán el enunciado del alcance de proyecto, el cual servirá como base.
•El alcance del proyecto se definirá en base a las necesidades presentadas por el jefe de proyecto.
El desarrollo de las necesidades brindadas por el cliente debe abarcar un plazo no mayor de 2
ciclos.
•Se deberá tener reuniones con los interesados en el proyecto para poder definir las fases, en las
cuales se desarrollará el mismo.
•Se debe organizar un cronograma con entregables semanales, el cual se deberá validar por el
cliente y el profesor gerente de IT Consulting.
•Se definirá los hitos del proyecto que se cumplirán, los objetivos tanto generales como
específicos del proyecto y los indicadores de éxito de los mismos.
•También es necesario definir las restricciones que el proyecto tendrá, sea por motivos técnicos,
sociales, tiempo, etc.
p ág . 2 9
• Se deberá definir todas las fases que el proyecto abarcará, es decir desde la concepción de la
idea, la planificación, la ejecución y el cierre del proyecto.
• Así como se definen las fases del proyecto, se deberán definir las actividades que estarán
dentro de cada una de estas fases.
• Todas las actividades deben tener una fecha de inicio y una fecha de fin establecida, de manera
que sea posible gestionar el avance del proyecto semana a semana.
• Se deberá definir los entregables contemplados en el proyecto, y todas las actividades que
contribuyeron para su construcción y validación.
• Las reuniones con los stakeholders también son actividades que deben ser contempladas en el
EDT ya que forman parte vital del mismo, por la regulación de tiempos y acuerdos
establecidos.
• La estructura del EDT debe ser de manera jerárquica y respetando el orden de las actividades y
así, el avance del proyecto será iterativo.
• Cada actividad dentro del EDT, presenta un responsable o dueño de la tarea quien será la
persona encargada de empezar y concluir de manera exitosa esa actividad.
• El proceso de elaboración de los documentos de gestión del proyecto también deberá ser
considerado en forma de actividades propias del proyecto.
• Es necesario tener en cuenta los días feriados o patrios dentro del cronograma, ya que así se
podrá gestionar de mejor manera los tiempos para la elaboración de los entregables.
• Luego de seleccionar las herramientas, se deben definir los entregables por cada fase del
proyecto, para este caso:
- LA PRIMERA FASE, inicio del proyecto, está compuesta básicamente por el siguiente
entregable:
- Project Charter
- LA SEGUNDA FASE, planificación del proyecto, cuenta con los entregables propios
para la gestión del proyecto, tales como:
- Diccionario EDT
p ág . 3 0
- Lecciones Aprendidas
- Matriz de Riesgos
- Matriz de Trazabilidad
- Matriz RAM
- Registro de Interesados
• EBM:
- Definición de procesos
- Diagrama de objetivos
- Diagrama Organizacional
- Glosario
- Mapeo de Procesos
- Modelo de Dominio
- Reglas de Negocio
- Stakeholders
• PM
- Cuadro de Control
p ág . 3 1
- Estimación de Esfuerzo
• SOA
- Diagrama de integración
- DRS
• Especificación de Servicios
- Portafolio de Servicios
- Portafolio de entidades
- Coreografías
- Orquestas
- LA CUARTA FASE, cierre del proyecto, se encuentra compuesto por los entregables
correspondientes a la culminación del proyecto.
• Memoria
• Poster de proyecto
• Lecciones aprendidas
• Luego de identificados los entregables por fase, estos se documentarán con la plantilla
designada “Diccionario EDT”.
p ág . 3 2
• Sobre cada paquete de trabajo se identifican y especifican en la plantilla anteriormente
indicada, las siguientes características:
- Se realiza la descripción del trabajo, para colocar todas las actividades necesarias para
cumplir con el entregable.
- Se establecen los requerimientos de calidad o las métricas a ser usadas para verificar el
entregable
• Posterior a la elaboración del diccionario EDT por el jefe de proyecto y asistente de proyecto,
se realiza una validación junto con el gerente profesor de la empresa de línea y el cliente del
proyecto, a fin de obtener su aprobación antes de la presentación al comité para su evaluación
y entrega de puntos de mejora.
p ág . 3 3
Ilustración 2: Organigrama actual de la Empresa IT-Consulting
Elaboración propia
1.6.4.2. Responsabilidades
La responsabilidad de cada rol que participa en el desarrollo del proyecto se detalla en el siguiente
documento:
- Matriz RAM
Gerente General IT-Consulting: Rol correspondiente al gerente profesor de la empresa virtual IT-
Consulting, encargado de establecer y cumplir los objetivos principales de la empresa IT-
Consulting; con respecto a la participación en el proyecto, el gerente profesor realizará las
siguientes funciones:
- Realizar un seguimiento del proyecto con el fin de evaluar si se cumple con lo estipulado
de acuerdo al cronograma establecido.
p ág . 3 4
- Brindar comentarios y observaciones de los entregables realizados para su mejora y
levantamiento antes de la presentación de estos al cliente y comité.
Fase –
Nivel de Tipo Cantidad Total de Horas de Costo Hora del
Entregable del
Experiencia / (Interno/ personal participación en el personal requerido
Proyecto
Conocimiento Externo) requerido proyecto (S/.)
requerido
Cliente de Interno Todas las fases 1 30 horas 1
Proyecto
390 horas –
Todas las
Jefe de Interno Todas las fases 1 1
Proyecto 1 horas
disponibles
390 horas –
Todas las
Jefe de Interno Todas las fases 1 1
Proyecto 2 horas
disponibles
p ág . 3 5
Recurso
Asignados Interno Ejecución 1 90 horas 1
TDP2
Analista de Interno Control 1 45 horas 1
QS
Tabla 3: Estimación de participación de recursos humanos
Elaboración propia
Durante las semanas de desarrollo de proyecto se definirán 4 días laborales de 3 horas cada uno,
siendo en promedio 12 horas a la semana. Los días martes y jueves se realizarán las actividades en
el horario de clase de 4:00pm a 7:00pm en el campus Monterrico de la Universidad Peruana de
Ciencias aplicadas (UPC). Los días viernes y sábados, la hora variará según la agenda realizada
cada semana, luego de la correspondiente revisión del avance de proyecto.
Fuera de los días de trabajo establecidos para el proyecto se podrán realizar avances, sin embargo,
todo avance deberá ser reportado para el seguimiento, respetando las actividades programadas en
el cronograma de proyecto.
- Presencia de disputas personales graves entre los integrantes del proyecto y el personal de
apoyo.
p ág . 3 6
1.6.5 Plan de Comunicaciones
- Registro de Interesados
- Hay una solicitud de cambio aprobada o acción correctiva que impacte los requerimientos
o necesidades de información de los Stakeholders.
La actualización del Plan de Gestión de Comunicaciones deberá seguir los siguientes pasos:
p ág . 3 7
1.6.5.3. Guías para eventos de comunicación
- Se manejará una agenda para cada reunión de acuerdo a los temas de interés a tratarse, así
como también las tareas pendientes de reuniones anteriores. Para este caso, se debe tener
en cuenta el entregable a realizar según el diccionario EDT.
- Se cuenta con un horario específico para cada reunión, sin embargo, será necesario
confirmar/recordar la reunión vía correo electrónico un día antes como máximo.
- En caso se deba postergar una reunión, se deberá justificar y además acordar el nuevo día
de esta.
- Al finalizar cada reunión se deberá recopilar lo tratado, resaltando los acuerdos para
posteriormente elaborar el acta de reunión.
- Todas las actas de reunión deberán ser firmadas por el jefe de proyecto, asistente de
proyecto y gerente general o cliente, respectivamente.
- Todo correo electrónico al cliente debe ser copiado a todo el equipo de proyecto; en
especial a gerente, jefe, asistente de proyecto
- Los correos electrónicos entre el gerente de la empresa y el cliente, deberá ser enviado por
el jefe de proyecto para establecer un estándar en la conexión.
• Actividad: Son un conjunto de tareas necesarias para alcanzar una Práctica de Gobierno o
Gestión.
p ág . 3 8
• Arquitectura de Aplicaciones: Arquitectura conformada por las interfaces que va tener la
Arquitectura Empresarial y que luego se busca pasar a una aplicación propiamente dicha.
• EBM: Disciplina del EUP cuyo objetivo principal es el modelamiento empresarial del
negocio.
• EUP: Variación extendida del RUP (Rational Unified Process) creado por Scoot W.
Amber y Larry Constantine en el año 2000.
p ág . 3 9
• PA02: Nombre abreviado del proyecto “Mejora del sistema SIDPOL para la Policía
Nacional del Perú”
• Proceso: Conjunto de prácticas que manipula entradas y produce salidas, como productos y
servicios.
• Project Charter: Entregable del proyecto, donde se declara el alcance del mismo, los hitos
y aspectos que se contemplará en el desarrollo de proyecto.
Probabi
# Riesgo Impacto Estrategia de mitigación
lidad
1 Baja disponibilidad del cliente 10% Muy baja Tener continua comunicación
con el cliente y planificar las
p ág . 4 0
Probabi
# Riesgo Impacto Estrategia de mitigación
lidad
reuniones.
2 La comunicación realizada va
Modificación del alcance del proyecto
permitir que el cliente siempre
Causa: Mejorar la definición de objetivos 30% Baja
esté al tanto de la información
y finalidad del proyecto.
desarrollada
p ág . 4 1
Probabi
# Riesgo Impacto Estrategia de mitigación
lidad
9 Contactar continuamente al
Mala elaboración e información de la cliente externo y pedirle
30% Baja
situación actual de la empresa información real sobre la
empresa.
p ág . 4 2
CAPITULO 2 Achievments of The Students Outcomes
En este capítulo se describe los resultados obtenidos del proyecto alineado y validado con los
Students Outcomes.
p ág . 4 3
2.1 Student Outcome “A”
APLICA CONOCIMIENTOS DE MATEMÁTICAS, CIENCIAS, COMPUTACIÓN E
INGENIERÍA
• Justificación: Aplicación de datos estadísticos del último censo de comisarias 2015 del INEI
para el análisis y la toma de decisiones. Asimismo, es aplicado para el desarrollo de la
estimación de tiempos y el costo del proyecto.
- El desarrollo del plan de implementación, para mayo detalle favor de revisar el punto 5.5
Plan de implementación.
p ág . 4 4
2.2 Student Outcome “B”
ANALIZA PROBLEMAS, IDENTIFICANDO Y DEFINIENDO LOS REQUERIMIENTOS
NECESARIOS PARA SU SOLUCIÓN.
• Justificación: Se realizó un análisis del sistema actual de denuncias policial para identificar
las necesidades en relación con los requerimientos del policía y el ciudadano.
p ág . 4 5
- El Project chárter del proyecto “Mejora del Sistema SIDPOL para la policía nacional del
Perú”, se adjunta evidencia del proyect charter por parte del cliente Edgar Díaz Amaya.
• Justificación: Diseño del proceso de denuncia policial para mejorar las funcionalidades del
sistema de denuncias, soportado a nivel nacional.
- La aprobación del desarrollo de la memoria del proyecto “Mejora del Sistema SIDPOL
para la policía nacional del Perú”, considerando el desarrollo del proyecto y plan de
implementación como puntos claves del proyecto.
p ág . 4 6
2.4 Student Outcome “D”
PARTICIPA EN EQUIPOS MULTIDISCIPLINARIOS DESARROLLANDO SUS
TAREAS CON PROFESIONALES DE DIFERENTES ESPECIALIDADES O DOMINIOS
DE APLICACIÓN.
- Las actas de reunión con el profesor gerente Max Chumpitaz de la empresa IT-Consulting.
p ág . 4 7
- Las actas de reunión con el cliente profesor Edgar Díaz Amaya.
- El acta de reunión con el profesor Jimmy Armas quien es parte del comité.
Para mayor detalle y evidencia revisar el anexo 3 y 4, los cuales hacen referencia a las actas de
reunión con los especialistas en las materias detalladas en líneas arriba firmadas durante los ciclos
académicos 2015-01 y 2016-01.
- El punto 1.6 Planificación de proyecto, 1.4 Objetivos del proyecto, 1.3 Planteamiento dela
solución del proyecto “Mejora del Sistema SIDPOL para la policía nacional del Perú”.
p ág . 4 8
2.6 Student Outcome “F”
PROPONE SOLUCIONES A PROBLEMAS DE INGENIERÍA CON
RESPONSABILIDAD PROFESIONAL Y ÉTICA.
• Justificación: Para el análisis del diseño del proceso de denuncias y su propuesta económica,
se tuvieron en cuenta aspectos éticos y morales en cuanto al resguardo, protección y
confidencialidad de los datos e información empresarial de la empresa.
p ág . 4 9
• Los entregables del proyecto que se alinean al student outcome son:
- Diseño del proceso de denuncia policial, el cual se puede validar en el punto 5.1.
Arquitectura de Negocio SIDPOL.
- Propuesta económica del proyecto “Mejora del Sistema SIDPOL para la policía nacional
del Perú”.
p ág . 5 0
2.7 Student Outcome “G”
COMUNICA IDEAS O RESULTADOS DE MANERA ORAL O ESCRITA CON
CLARIDAD Y EFECTIVIDAD.
- Las actas de reunión con el profesor gerente Max Chumpitaz de la empresa IT-Consulting.
- El acta de reunión con el profesor Jimmy Armas quien es parte del comité.
Para mayor detalle y evidencia favor revisar el anexo 3 y 4, los cuales hacen referencia a las actas
de reunión de los resultados obtenidos de manera progresiva durante los ciclos académicos 2015-
01 y 2016-01
- Los entregables de las Arquitectura tecnológica, ver punto 5.4 Arquitectura Tecnológica
de SIDPOL.
p ág . 5 1
2.9 Student Outcome “I”
RECONOCE LA NECESIDAD DE MANTENER SUS CONOCIMIENTOS
ACTUALIZADOS.
• Justificación: Para la elaboración de este proyecto se tuvo que analizar e investigar acerca del
proceso de denuncia policial y su relación con las nuevas tendencias que se dejó como
continuidad. Por otra parte, se elaboró un documento de investigación sobre lo recabado
sustentándolo frente a otras propuestas.
• Justificación: Para el desarrollo del proyecto se utilizó las disciplinas del EUP: EBM, PM, AE
y PMBOK para la gestión del proyecto. Asimismo, se investigó sobre los artefactos
pertenecientes a la disciplina EUP.:
p ág . 5 2
Cnel. Luis Chávez – Director de la Dirección de Informática (DIRINFOR), para mayor
detalle revisar los puntos 5.5 Plan de Implementación.
p ág . 5 3
p ág . 5 4
• Cartera de proyectos. - como parte de la continuidad del proyecto se deja como constancia tres
proyectos de continuidad del proyecto “Mejora del Sistema SIDPOL para la policía nacional
del Perú”, lo cuales son:
- Desarrollo de una aplicación web que permita realizar un análisis predictivo en tiempo real
de los delitos cometidos en el Perú.
p ág . 5 5
p ág . 5 6
CAPITULO 3 Marco Teórico
En este capítulo se da una breve descripción sobre la situación actual dentro de la Policía
Nacional del Perú y los procesos que se realiza a los diferentes tipos de denuncias, además se
define conceptos más importantes para comprender la importancia sobre una arquitectura
empresarial para el negocio de las empresas. Se presenta información sobre las cuatro
arquitecturas que forman parte de este proyecto. A su vez, se explica brevemente la metodología
utilizada para el proyecto, la herramienta Bizagi para el modelado de procesos de negocio y el
framework Zachman.
p ág . 5 7
3.1 Definición de Arquitectura de Aplicaciones
Arquitectura de Aplicaciones es aquel esquema con el cual se analiza el conjunto de aplicaciones
integradas requeridas para satisfacer las necesidades de negocio, incluyendo el existente y el
planificado inventario, mapa de ruta de aplicaciones y componentes. Su objetivo es responder a
preguntas como:
¿Cuál es el valor estratégico de cada una de las aplicaciones en el portfolio de aplicaciones de TI?
¿Cuáles son las nuevas aplicaciones requeridas para satisfacer las necesidades de negocio? ¿Cómo
están las aplicaciones desde un punto de vista funcional y técnico? ¿Cuáles son las
interdependencias y la interoperabilidad necesarias entre aplicaciones?1
¿Cuál son los tipos, localizaciones y tiempos de información requeridos para alcanzar los
principales objetivos en los procesos y planes de negocio de la compañía? ¿Qué tipos de
información se necesita compartir? ¿En qué estado está el dato operacional e informacional?2
1
JUAN CARLOS RAMOS SENÍN
2
JUAN CARLOS RAMOS SENÍN
p ág . 5 8
¿Tiene la compañía planes de desarrollar nuevas líneas de producto, reducir coste operacional, o
incrementar la calidad y satisfacción de sus clientes? ¿Cuáles son los problemas u oportunidades
de negocio más comunes?3
¿Cuál es la guía prescriptiva para una arquitectura segura que permita aplicaciones en Internet?
¿Qué características técnicas deben tener los servidores y comunicaciones?4
3
JUAN CARLOS RAMOS SENÍN
4
JUAN CARLOS RAMOS SENÍN
p ág . 5 9
empresa. Dicha representación se realiza a través de modelo que permitan más adelante alinear las
reglas de negocio con las tecnologías de información existentes actualmente.
Elaboración Propia
5
CORPORACIÓN SYBVEN
p ág . 6 0
organizaciones a adaptarse a las nuevas circunstancias comerciales internas y B2B (Business to
Business) rápidamente.6
6
BPMN
7
Cfr. Ambler 2005: 35
p ág . 6 1
Ilustración 6: Flujo de trabajo del EBM
8
ZACHMAN
p ág . 6 2
Ilustración 7: Vista del Framework ZACHMAN
9
BIZAGI
p ág . 6 3
3.10 Definición de metodología EUP
EUP tiene como objetivo mostrar el ciclo de vida completo de un sistema, es por esto que extiende
el ciclo de vida del RUP. Esta extensión se basa en incluir las disciplinas de operación y soporte,
así como también agregar dos nuevas fases, las cuales son producción y retiro. Es así como el
EUP muestra desde la creación de la primera versión de un sistema hasta su retiro10
Ilustración 9: EUP: Extensión del RUP para reflejar el ciclo de vida completo de un sistema
10
Cfr. Ambler 2005: 31
p ág . 6 4
CAPITULO 4 Estado del Arte
En este capítulo se presenta una breve descripción sobre el estado del arte de la mejora del
sistema SIDPOL de la Policía Nacional del Perú. Un estudio del conocimiento existente
relacionado a la problemática planteada en este trabajo, así como las soluciones propuestas por
otros autores donde se ha realizado la búsqueda, análisis y filtrado de artículos científicos
relacionados a este proyecto.
p ág . 6 5
4.1 Revisión de Literatura
En este capítulo, se detallará el estado del arte del proyecto que tiene como propósito presentar
una propuesta de implementar una arquitectura empresarial que permita la mejora funcional del
sistema SIDPOL ya sea para su flujo de procesos y rendimiento a nivel de sistema, en base al
diagnóstico de los procesos de denuncias que se involucran en las comisarías de Lima y propone
la Dirección de Informática para su mejora. Para el proyecto de mejora del SIDPOL, el estado del
arte comprenderá las fases de la Arquitectura Empresarial aplicadas de manera exitosa en
empresas Privadas, de los gobiernos internacionales y entender que es el proceso de denuncia.
Según Lorraine Green Mazerolle et al (1998) identifica los desafíos que enfrentan los
departamentos de policía que tratan de poner en práctica sistemas de mapeo computarizado del
crimen. La primera parte del documento destaca la importancia de los departamentos de policía
que identifican "usuarios finales" primarias y luego el diseño de sistemas que realizan las tareas
específicas a las necesidades de sus usuarios finales. Según Steven D. Levitt (1998) los estudios
empíricos que utilizan data sobre el delito denunciado a la evaluación de las políticas de reducción
de crimen será subestimar la verdadera efectividad de estas políticas que puedan afectar el flujo
constante del mapeo de procesos. Según CentrePiece Winter (2007) la adopción de la tecnología
de la información por la policía departamentos en los Estados Unidos es un relativamente reciente
fenómeno. Antes de 1987, a menos de 2% de la 2200 de EE.UU. departamentos de policía con
menos de 100 empleados utilizan computadoras. Y recientemente, en 2003, sólo el 40% de la
policía departamentos tenían terminales de computadoras móviles lo cual requiere un mejor
mapeo de los procesos involucrados a futuro que estarán creciendo y no podrá ser soportados si no
se cuenta con un marco de trabajo apropiado.
Según Daniel Zeng (2003) el desarrollo y evaluación de un sistema prototipo destinado a abordar
el seguimiento de la información y el intercambio de desafíos en el dominio de aplicación de la
p ág . 6 6
ley. Nuestro sistema, llamado Agente COPLINK, está diseñado para proporcionar automática de
filtrado de información y funcionalidades de monitoreo, recalcando constantemente que aplicar
una arquitectura de negocio fue fundamental para identificar y representar los procesos a trabajar
para el desarrollo de este prototipo de mejor para los agentes policiales.
p ág . 6 7
de seguridad y compartir información con otras redes a nivel nacional con el fin de eludir nuevos
ataques y minimizar los daños. Esto es de suma importancia en las comunidades más pequeñas y
empresas donde uno no siempre tiene acceso a conocimientos especializados en materia de
seguridad; es por eso que tratamos de proporcionar una ''Expert in a Box” en el que existe el
conocimiento de seguridad, única para cada sistema, dentro del propio sistema en la forma de una
comunidad de agentes, como se muestra en la Figura.
p ág . 6 8
de Drogas en varios terrenos norteamericanos, básicamente apuntando al territorio de la Ciudad de
Nueva Jersey (NJ). Finalmente, como instancia final o etapa del proyecto es aplicar un marco de
trabajo que da como preguntas el Cómo, Qué, Quien, Cuando y Donde ya que llegar a Planificar e
implementar capacidad de Informática concedes bastante poder por lo que se debe realizar un
marco de trabajo dentro de cada agencia policial para poder usar la herramienta y poder observar
la interacción final de las interfaces.
Finalmente, la construcción de menús personalizados que son fáciles de usar y que permiten a los
funcionarios para llevar a cabo búsquedas y consultas que se ajustan a sus actividades de
resolución de situaciones de un tercer desafío para los departamentos de policía que contemplan
sistemas de mapeo de crimen edificio para su uso a nivel de calle. Los tipos más comunes de las
investigaciones, que se pueden construir con facilidad, deben encajar con el tipo de información
que los oficiales de línea deben facilitar sus esfuerzos para resolver problemas. Sistemas
personalizados construidos deben adaptarse a cambios de vez en cuando y ser adaptables a través
de una serie de esfuerzos para resolver problemas. Por ejemplo, los detectives en una unidad de
crímenes violentos deben hacer diferentes tipos de preguntas de un sistema de cartografía de
p ág . 6 9
narcos. Del mismo modo, un oficial de latido está interesado en la realización de búsquedas de
todo un tipo diferente de cualquiera de narcos o detectives del escuadrón del crimen violento.
Por otro lado, los sistemas de mapas computarizados tienen mucho que ofrecer a los
departamentos de policía, ya sea un departamento de policía decide implementar capacidades de
mapeo del delito con la PC para su uso a nivel de calle o desarrollar capacidades de mapeo más
temáticos para el análisis de la delincuencia o la planificación de políticas, la presentación gráfica
de los datos de delincuencia proporciona un medio para identificar, analizar y comunicar los
problemas, prioridades y los planes de una manera rápida y fácil. El poder del crimen mapeo, sin
embargo, es mucho mayor cuando los departamentos de policía invierten recursos en la
planificación, pruebas piloto, y resolver los problemas logísticos desde el principio 11.
11
Cfr. Green, Belluci y Gajewski
12
Cfr. López, Farías, Castañeda
p ág . 7 0
Finalmente, podemos concluir que la Arquitectura Empresarial aplicada tanto a empresa privadas
o entendidas del gobierno permite tener un mejor alineamiento el objetivos estratégicos que se
plantean toda organización entidad del gobierno para tener una mejora no sólo del sistema a
implementar si no una mejor comunicación en los usuarios de los sistemas y el cliente o ciudadano
con el fin de optimizar tareas que durante un largo tiempo no se ha presentado una mejora para
alinearlas a las necesidades de la entidad gubernamentales o empresas privadas.
p ág . 7 1
CAPITULO 5 Desarrollo del proyecto
El este capítulo muestra la ejecución del análisis, diseño y la mejora del sistema SIDPOL
aplicando la Arquitectura Empresarial, basado en el uso del framework Zachman, sobre el cual se
ha elaborado los artefactos de la Arquitectura de Negocio, Aplicaciones, Datos y Tecnológico que
ayudan a realizar una correcta Arquitectura Empresarial. Para realizar estos artefactos se ha
generado documentación con mayor detalle donde se explica el desarrollo de cada uno. Asimismo,
se muestra ordenadamente cual es la secuencia para realizar cada artefacto ya que es un flujo
dependiente para el desarrollo de cada Arquitectura.
p ág . 7 2
5.1 Arquitectura de Negocio de SIDPOL
EBM
El año de 1821, el Libertador Don José de San Martín, atendiendo al consejo ciudadano de la
época, con fines de organización y por necesidad propia, se crea la "GUARDIA CIVICA”, con la
finalidad de mantener el orden público. Teniendo como Inspector General a Don José Bernardo
Tagle y Portocarrero, Marqués de Torre Tagle, quien posteriormente ejercía el Supremo Gobierno,
con el título de Supremo Delegado (19 de enero al 21 de agosto 1822).
Al dictar Don José de San Martín la Primera Carta Magna, se establece la creación de tres
Ministerios: el de gobierno y Relaciones Exteriores, el de Guerra y Marina; y el de Hacienda.
En lo referente a la Fuerza Armada y Policía, articulaba así: "Constituyen las Fuerzas Armadas de
tierra, el Ejército de línea, la Milicia Cívica y la Guardia de Policía, Priorizando la Milicia Cívica
la cual se encargará de mantener la seguridad pública entre los límites de cada Provincia"(Artículo
168 de la Primera Constitución del Perú).
Durante el mandato de Don Simón Bolívar Palacios, el 07 de enero de 1825 se crea la Guardia
Nacional, en base de personal licenciado del ejército, organizado bajo un sistema netamente
militar. El 09 de diciembre de 1826, se expide la Constitución Vitalicia, en uno de cuyos artículos
se especificaba que la función policial se independizaba del gobierno municipal (que era rezago de
la época virreinal), pasando al Ministerio de gobierno por intermedio de las Prefectura e
Intendencias.
El 20 de enero de 1827 se creó el Primer Reglamento de Policía, durante el gobierno del Mariscal
Don Andrés de Santa Cruz Calaumana (Presidente del Quinto Consejo de Gobierno de la
República Peruana).
El Mariscal Andrés de Santa Cruz dispondría la acción policial por todo el territorio a través de los
Serenos.
p ág . 7 3
En 1851 asume la Presidencia de la República el General don José Rufino Echenique Benavente.
Es así como el 14 de abril de 1852, se reorganiza las Fuerzas de Policía en un solo cuerpo Policial
que se denominaría GENDARMERIA. A la letra el artículo 1o del decreto Supremo en referencia
dice: "Todos los cuerpos de Policía de Serenos y vigilantes, se reunirán en uno solo, con nombre
de Gendarmería, se empleará exclusivamente en mantener la seguridad pública".
Asimismo, en el 2do artículo este dispositivo legal expresaba la independencia de este cuerpo
Policial del Ministerio de Gobierno y Policía.
El batallón de Gendarmeres Número Uno, tomaría como sede el Cuartel santa Ana, en la ex calle
Sacramento, aledaña a la Plaza Italia, Barrios Altos, hoy convertido en un Centro Escolar. Es este
el batallón que dio origen a la Guardia Republicana (07 de agosto de 1919).
Don Manuel Pardo y Lavalle asume la presidencia el 02 de agosto de 1872, siendo una de sus
primeras acciones Reorganizar las Fuerzas Policiales. Subdividiéndolas en tres grandes campos:
Durante esta gestión gubernamental se contrató una Misión Española, con la finalidad de impulsar
las antiguas fuerzas de Policía, es así que un 03 de Julio de 1922, se crea la Escuela Nacional de
Policía. Con la finalidad de "La organización de un Cuerpo de Guardia Civil, a igualdad de
España, Sobre la base de la Gendarmeria de entonces. Otro Cuerpo de Seguridad y Orden Público
a base de la Guardia Civil, y crea un Cuerpo de Investigación y Vigilancia., con los elementos
aprovechables de la Sección de Investigaciones de la entonces Intendencia de Policía".
p ág . 7 4
La Escuela de Policía se inauguró el primero de noviembre de 1922.
En 1949, siendo Presidente de la República el General Don Manuel Apolinario Odría Amoretti, se
eleva el CIVI a la categoría de dirección General.
A partir de entonces, la Nación Peruana ve configurarse tres cuerpos policiales con misión y
funciones específicas: La Guardia Civil del Perú, La Policía de Investigaciones del Perú y la
Guardia Republicana del Perú.
Como ente de apoyo fue creada la Sanidad de Policía, mediante Resolución Suprema del 04 de
diciembre de 1924.Un cambio importante se produjo en 1985, cuando el Supremo Gobierno
dispuso la reorganización de las Fuerzas Policiales mediante la Ley de Bases Nº 371, la misma
que entre otras medidas, estableció un Comando único y un solo Centro de Estudios para la
preparación de oficiales policías, y una Escuela de preparación para guardias. Creación DE LA
PNP. 1988
El 28 de julio de 1985, asume el gobierno Constitucional del país, el doctor Alan Ludwig Gabriel
García Pérez, dándose los primeros pasos de los que significara en un futuro, no muy lejano, la
integración de las Fuerzas de Policía en una sola Institución. Se promulga la nueva Constitución
p ág . 7 5
Política del Perú, en la misma que, por primera vez en la Historia del Perú, se reconoce la
finalidad de la policía peruana que, se precisa, es mantener el Orden Interno.
Al afianzarse la política de Integración Policial, en este mismo período presidencial y por Ley N"
24949, un 06 de diciembre de 1988 se establece una modificatoria en la Constitución Política,
creándose la Policía Nacional del Perú, asumiendo este nuevo ente policial la Organización y
Funciones de las Instituciones primigenias, GC, GR y PIP, con todos sus derechos y obligaciones,
dándose inicio as a una nueva etapa en la historia Policial Peruana, involucrada en la problemática
socio - económica, cada vez más complicada, agudizada por el fenómeno del narcoterrorismo y su
secuela escalofriante y sangrienta., adoptando el lema: “Dios, Patria y Ley”. Las décadas de los 80
y 90, han sido etapas de duras pruebas para el profesionalismo policial que tuvo que enfrentar
exitosamente graves alteraciones del Orden Interno, provocadas por el narcotráfico, el terrorismo
y la delincuencia organizada. Son logros históricos el haber contribuido a la derrota de las
organizaciones terroristas: Movimiento Revolucionario Túpac Amaru (MRTA) y Sendero
Luminoso, así como la desarticulación de organizaciones internacionales de narcotraficantes;
acciones que han merecido el reconocimiento de la comunidad nacional e internacional. El nuevo
milenio encuentra a la Policía Nacional del Perú comprometida en un vigoroso proceso de cambio
para adecuar su organización a las exigencias de una sociedad postmoderna, encaminada hacia su
progreso social y económico.
5.1.1.1 Visión
Policía moderna, eficiente y cohesionada al servicio de la sociedad y del Estado, comprometida
con una cultura de paz, con vocación de servicio y reconocida por su respeto irrestricto a la
persona, los derechos humanos, la Constitución y las leyes, por su integración con la comunidad,
por su honestidad, disciplina y liderazgo de sus miembros.
5.1.1.2 Misión
La Policía Nacional del Perú es una institución del Estado que tiene por misión garantizar,
mantener y restablecer el orden interno, prestar protección y ayuda a las personas y a la
comunidad, garantizar el cumplimiento de las leyes y la seguridad del patrimonio público y
privado, prevenir, investigar y combatir la delincuencia; vigilar y controlar las fronteras; con el
propósito de defender a la sociedad y a las personas, a fin de permitir su pleno desarrollo, en el
marco de una cultura de paz y de respeto a los derechos humanos.
p ág . 7 6
5.1.1.3 Cronología
Se crea la
Guardia Se dicta El Presidente
Nacional y Decreto La fuerza Piérola fija Durante el
Durante el El Presidente
ese mismo Se refundiendo regular de por Decreto gobierno del
gobierno del Ramón
año la reorganiza el en la Policía se la Presidente
Presidente Castilla
Guardia de cuerpo de Gendarmería divide en distribución Leguía se
Orbegoso reorganiza la
Policía, Serenos y todos los Guardia Civil de crea la
reaparecen Guardia
formando Vigilantes. cuerpos y Comisarías y Guardia
los Serenos. Nacional.
parte de las policiales de Gendarmería. fuerzas de la Republicana.
Fuerzas la República. policía.
Armadas.
El servicio Se reorganizan
de Sanidad las FF.PP.
Se crea la
Se crea el se La Guardia integradas por
Escuela de La Policía de
La Guardia Cuerpo de desarrolla Republicana la Guardia Civil,
la Guardia Investigaciones
Civil de Investigación de la mano recibe su Se crea la la Policía de
Civil y adopta
España es y Vigilancia, con la Bandera de Sección Investigaciones
Policía de autonomía
contratada años más Policía, la Guerra y Femenina y la Guardia
la propia y crea
para tarde cual en adopta el de la Republicana;
República la Escuela
reorganizar asumiría el 1924 pasa lema Escuela de nombrándoseles
con el lema Nacional de
a la Policía lema: a formar "Honor, Vigilantes. un Comando
"El Honor Investigación
Peruana. "Honor y parte del Lealtad y Único y
es su Policial.
Lealtad". Cuerpo de Disciplina" creándose un
Divisa".
Seguridad solo Centro de
creándose Estudios.
más tarde
p ág . 7 7
la Dirección
de Sanidad
de
Gobierno y
Policía.
El propósito del diagrama de objetivos es representar los objetivos del negocio. Estos se muestran
a través de jerarquías; es decir, primero se muestra el objetivo principal y de ahí los específicos.
p ág . 7 8
Ilustración 13: Organigrama de la Policía Nacional del Perú
Elaboración Propia
5.1.3 Diagrama Organizacional
En este documento se presenta el diagrama de la organización, aquí se representa la estructura
organizacional de la Policía Nacional del Perú. Esta estructura soporta los procesos que se han
identificado en el mapa de macro procesos.
ORGANIGRAMA DE LA PNP
p ág . 8 1
• Proyectos:
- Frentes Policiales
- Regiones Policiales
El propósito de este artefacto es dar un primer alcance sobre cuáles son los procesos en los que se
busca alcanzar una optimización, mediante la implementación de tecnologías de información; y
por tanto, cuáles serán analizados a profundidad para conocer su ciclo de vida, los actores que
intervienen y las actividades y eventos que forman parte de éstos.
p ág . 8 2
Ilustración 15 : Mapa de Procesos de la PNP
Elaboración propia
5.1.5 Justificación de Procesos y Objetivos
El artefacto Justificación de Procesos – Objetivos es el diagrama que permite identificar la
correspondencia existente entre los objetivos de la empresa minera cliente y los procesos
identificados en ella, para que se logre conocer cuáles son los procesos que ayudan a cumplir o
apoyar a cada objetivo.
El diagrama consiste en una tabla de dos entradas donde cada columna es un proceso identificado
(diferentes colores para cada uno de los procesos identificados) y cada fila es un objetivo de la
PNP. Una “X” significa que el proceso identificado apoya a lograr el objetivo mapeado. Es
importante recordar que los objetivos justificados corresponden al último nivel del diagrama de
objetivos, entendiéndose que los objetivos de mayor jerarquía siguen el mismo comportamiento de
sus sub-objetivos.
5.1.5.1. Propósito
El propósito de este documento es identificar de manera general qué procesos aportan valor para
lograr cumplir con los objetivos identificados de una pequeña empresa minera, para luego
priorizar dichos procesos de acuerdo a la cantidad de objetivos mapeados. Esto se realiza con la
finalidad de evaluar si es que los procesos que se están ejecutando apoyan el logro de la meta
propuesta (objetivo general).
5.1.5.2. Alcance
El alcance de este documento se ve acotado a los objetivos planteados por la PNP y por el cliente
asignado por el Comité de Proyectos.
Objetivo 06 x x x x
Objetivo 07 x x x x
Objetivo 08 x
Objetivo 09 x x x x
Objetivo 10 x x
Objetivo 11 x x
Objetivo 12
Objetivo 13 x x
Objetivo 14 x x x x x
Objetivo 15
Objetivo 16
Objetivo 06 x x x x
Objetivo 07 x x
Objetivo 08 x x
Objetivo 09 x
Objetivo 10 x x x
Objetivo 11
Objetivo 12 x x
Objetivo 13 x x
Objetivo 14 x x x x
Objetivo 15 x x
Objetivo 16 x
STAKEHOLDERS INTERNOS
Stakeholder Descripción
Elaboración propia
El propósito de este artefacto es conocer las entidades (lugares, cosas o conceptos) con los cuales
cuenta todos los procesos a desarrollar en el presente proyecto.
p ág . 8 7
• Modelo dominio de denuncia.
Elaboración Propia
Elaboración propia
p ág . 8 8
• Descripción de entidades
N° Entidades Descripción
p ág . 8 9
arma implicada en una ocurrencia o denuncia.
Elaboración propia
p ág . 9 0
Ilustración 18 – Definición de proceso AS IS “Ocurrencia”
Elaboración propia
Elaboración propia
p ág . 9 1
Ilustración 20 – Definición de proceso AS IS “Proceso buenas costumbres”
Elaboración propia
Elaboración propia
p ág . 9 2
Ilustración 22 - Definición de proceso AS IS “Proceso Orden publica”
Elaboración propia
Elaboración propia
p ág . 9 3
Ilustración 24 - Definición de proceso AS IS “Proceso de ocurrencia”
Elaboración propia
Elaboración propia
p ág . 9 4
Ilustración 26 - Definición de proceso AS IS “Proceso caso de delitos”
Elaboración propia
p ág . 9 5
Ilustración 27 - Definición de proceso AS IS “Proceso de denuncia”
Elaboración propia
El proceso de “Dependencia Policial” permite fortalecer la actuación policial con miras a efectuar
controles de identidad dentro del marco de los principios de necesidad, razonabilidad,
proporcionalidad y respeto a la persona humana.
El propósito de este artefacto es describir los roles, stakeholders, entradas, salidas y procesos del
proceso de “Dependencia Policial” a fin de proporcionar un mejor entendimiento del mismo.
• Declarativa
Este proceso permite fortalecer la actuación policial con miras a efectuar controles de identidad
dentro del marco de los principios de necesidad, razonabilidad, proporcionalidad y respeto a la
persona humana.
p ág . 9 6
• Roles
Los roles de la empresa que intervienen en el presente proceso serán detallados en el siguiente
cuadro, en el cual se menciona el nombre del Rol, su respectiva descripción y el área funcional a
la que pertenece.
Responsable de
Efectivo policial encargado de tipificar
comisaria / Unidad Comisaría
la denuncia
Especializada
Elaboración propia
• Stakeholders
Todos los involucrados en el presente proceso y sus respectivas descripciones son mencionados a
continuación.
STAKEHOLDERS DESCRIPCIÓN
p ág . 9 7
defunciones, divorcios y otros que modifican el estado
civil.
En el siguiente recuadro se menciona la entrada que tendrá el proceso, una breve descripción y el
encargado de elaborar el mismo.
ENCARGADO DE
Entrada DESCRIPCIÓN
ELABORACIÓN
p ág . 9 8
• Salida del proceso
• Caracterización
Necesidad de Responsable de
elaborar un acta Se registra la necesidad de elaborar un comisaria /
- Inicio
de intervención acta de intervención policial Unidad
policial Especializada
3 Libro de Registro Mantener al Implicado(s) El retenido no podrá ser ingresado a una Responsable de
de Control de sospechoso en la celda o calabozo. No podrá ser comisaria /
p ág . 9 9
Identidad Policial comisaria mantenido en contacto con otras Unidad
personas detenidas. Especializada
Responsable de
Presunto Se reconoce al implicado de un hecho comisaria /
9 Peruana Flagrancia delictiva
implicado delictivo Unidad
Especializada
p ág . 1 0 0
En caso el retenido fuere un extranjero,
el efectivo policial deberá realizar Responsable de
Coordinar con la Entidad inmediatamente las coordinaciones con comisaria /
10 Extranjero
entidad procedente procedente las instituciones correspondientes Unidad
(Consulados, Embajadas, Migraciones, Especializada
etc.) a fin de agotar su identificación.
Necesidad de Intervención en
elaborar un acta flagrancia y Se le interviene al implicado en flagrancia
13 Flagrancia Efectivo Policial
de intervención garantía de delictiva se le garantiza sus derechos
policial derechos
Poner al/los
Se pone a disposición del efectivo policial
14 Flagrancia detenidos/s a Implicado(s) Efectivo Policial
a los implicados
disposición
Consolidar actas
Acta levantadas y Se procede a consolidar las actas
15 Implicado(s) levantadas y Efectivo Policial
evidencias levantadas y evidencia recolectada
evidencias
Verificar
Acta levantadas y Acta levantadas y Se valida la conformidad de las actas y
16 conformidad de las Efectivo Policial
evidencias evidencias evidencias
actas y evidencia
Notificación de Facilitar los medios Medio de Se facilita al implicado los medios para
19 Efectivo Policial
implicado(s) para que el/los comunicación acreditar su identidad o para comunicar a
detenidos/s pueda su familia o persona que indique sobre su
p ág . 1 0 1
comunicarse retención.
Registrar la
detención en el Cuaderno de
Medio de Se registra la detención de los implicados
20 cuaderno de detenidos en la Efectivo Policial
comunicación en el cuaderno de detenidos
detenidos en la comisaria
comisaria
Permitir que el
Cuaderno de
detenido se Se procede a brindar la entrevista entre
21 detenidos en la Implicado(s) Efectivo Policial
entreviste con su el abogado defensor y el implicado
comisaria
abogado defensor
Brindar toda la
El efectivo policial brinda toda la
información y Información y
22 Implicado(s) información de lo sucedido al abogado Efectivo Policial
documentación al documentación
defensor
abogado defensor
Reunir la
información
Declaración de Información del Recopilación de la información obtenida y
24 necesaria y enviarla Efectivo Policial
detenido detenido se envía al Ministerio Público
al Ministerio
Público
Necesidad de
El denunciante tiene que brindar su
elaborar un acta Brindar Documento de
25 documento de identificación para que la Denunciante
de intervención identificación identidad
denuncia sea válida
policial
Tomar las
Efectivo policial registra la denuncia de
27 Denuncia declaraciones del Denuncia Efectivo Policial
acuerdo a lo detallado por el denunciante
denunciante
p ág . 1 0 2
Por parte del efectivo policial tiene que
Investigar la Información del
29 Atesta Policial verificar que lo declarado por el Efectivo Policial
declaración detenido
denunciante sea válido
Información del
Fin - Fin del proceso de Dependencia Policial Efectivo Policial
detenido
p ág . 1 0 3
• Definición del proceso: Control de identidad policial
El propósito de este artefacto es describir los roles, stakeholders, entradas, salidas y procesos del
proceso de “control de identidad policial” a fin de proporcionar un mejor entendimiento del
mismo.
• Declarativa
Este proceso tiene por finalidad la identificación personal realizado por efectivos policiales en la
vía pública o en cualquier otro lugar donde se realice dicho requerimiento, cuando resulte
necesario para prevenir un delito u obtener información útil para la averiguación de un hecho
punible. Para tal efecto el efectivo policial podrá realizar las comprobaciones pertinentes.
• Roles
Los roles de la empresa que intervienen en el presente proceso serán detallados en el siguiente
cuadro, en el cual se menciona el nombre del Rol, su respectiva descripción y el área funcional a
la que pertenece.
p ág . 1 0 4
• Stakeholders
Todos los involucrados en el presente proceso y sus respectivas descripciones son mencionados a
continuación.
STAKEHOLDERS DESCRIPCIÓN
En el siguiente recuadro se menciona la entrada que tendrá el proceso, una breve descripción y el
encargado de elaborar el mismo.
p ág . 1 0 5
ENCARGADO DE
Salida DESCRIPCIÓN
ELABORACIÓN
Elaboración propia
• Caracterización
Necesidad de iniciar
Se registra la necesidad de tener una
- Inicio una intervención Efectivo Policial
intervención policial
policial
p ág . 1 0 6
Carnet Extranjería / requerido identidad documentos de identidad entregados
Efectivo Policial
Pasaporte
Devolución de
Documento de Documento de Se procede a devolver el documento
10 documento de Efectivo Policial
identidad identidad de identidad a los implicados
identidad
p ág . 1 0 7
• Diagrama del proceso
El propósito de este artefacto es describir los roles, stakeholders, entradas, salidas y procesos del
proceso de “Flagrancia Delictiva” a fin de proporcionar un mejor entendimiento del mismo.
• Declarativa
Este proceso tiene por finalidad fortalecer la actuación policial durante la detención en flagrancia
delictiva, con estricto respeto del derecho de defensa.
• Roles
Los roles de la empresa que intervienen en el presente proceso serán detallados en el siguiente
cuadro, en el cual se menciona el nombre del Rol, su respectiva descripción y el área funcional a
la que pertenece.
• Stakeholders
Todos los involucrados en el presente proceso y sus respectivas descripciones son mencionados a
continuación.
STAKEHOLDERS DESCRIPCIÓN
En el siguiente recuadro se menciona la entrada que tendrá el proceso, una breve descripción y el
encargado de elaborar el mismo.
p ág . 1 1 0
Salida DESCRIPCIÓN Encargado de Elaboración
• Caracterización
Se registra la
necesidad de
Se registra la necesidad de
- Inicio identificar la Efectivo Policial
identificar la flagrancia delictiva
flagrancia
delictiva
Se registra la
necesidad de
Identificar la flagrancia Flagrancia Se identifica al implicado en un acto
identificar la Efectivo Policial
delictiva delictiva delictivo
flagrancia
1 delictiva
Registro de
Realizar registro personal Se realiza el registro de los
Implicados datos de los Efectivo Policial
del detenido implicados del hecho delictivo
3 implicados
p ág . 1 1 1
Declaración
Recibir declaración del Se registra la declaración del
Implicados del Efectivo Policial
sospechoso implicado o implicados
7 sospechoso
Declaración del
Examen de Se deriva a los implicados del hecho
sospechoso Examinar por Médico
médico delictivo al médico legista de la Efectivo Policial
Legista
legista dependencia policial
9
Notificación
Acta de Se notifica al fiscal de turno lo
Notificar al Fiscal de Turno al fiscal de Efectivo Policial
resultados sucedido del hecho delictivo
11 turno
Lugar de
Notificación al Se verifica y valida los hechos de
Ir al lugar de los hechos hecho Efectivo Policial
fiscal de turno proceso identificado
12 delictivo
Acta del
Lugar de hecho Realizar acta del lugar de lugar del Se registra un acta del lugar del
Efectivo Policial
delictivo los hechos hecho hecho delictivo
13 delictivo
p ág . 1 1 2
• Diagrama del proceso
El proceso de “Gestionar escena del delito” permite identificar espacios físicos y zonas adyacentes
donde se ha cometido el hecho delictivo, es decir es la fuente de investigación para los efectivos
policiales y fiscales para reconstruir los hechos o encontrar más pistas.
El propósito de este artefacto es describir los roles, stakeholders, entradas, salidas y procesos del
proceso de “Gestionar escena del delito” a fin de proporcionar un mejor entendimiento del mismo.
• Declarativa
Este proceso permite fortalecer la actuación policial y fiscal, para garantizar una adecuada
protección, aislamiento, procesamiento y cierre de la escena del delito e incrementar de manera
potencial las probabilidades del esclarecimiento del hecho delictuoso, y que determinen
negativamente el caso.
• Roles
Los roles de la empresa que intervienen en el presente proceso serán detallados en el siguiente
cuadro, en el cual se menciona el nombre del Rol, su respectiva descripción y el área funcional a
la que pertenece.
Todos los involucrados en el presente proceso y sus respectivas descripciones son mencionados a
continuación.
STAKEHOLDERS DESCRIPCIÓN
En el siguiente recuadro se menciona la entrada que tendrá el proceso, una breve descripción y el
encargado de elaborar el mismo.
Encargado de
Entrada DESCRIPCIÓN
Elaboración
p ág . 1 1 5
Salida DESCRIPCIÓN Encargado de
Elaboración
• Caracterización
Se registra la
necesidad de la
protección,
Se registra la necesidad de identificar
- Inicio aislamiento, Denunciante
la flagrancia delictiva
procesamiento y
cierre de la escena
del delito
Se registra la
necesidad de la
Declarar
protección, El denunciante declara toda la
información
1 aislamiento, denuncia información necesaria para el registro Denunciante
relevante de un
procesamiento y de la denuncia
hecho delictivo
cierre de la
escena del delito
Brindar
documento de El denunciante tiene que brindar su
identificación para
2 denuncia identidad / identificación para que la denuncia Denunciante
el registro de la
denuncia sea válida
denuncia
p ág . 1 1 6
denunciante, así como toda
información que sea necesaria.
p ág . 1 1 7
escena.
Tomar las
previsiones del Implica que el efectivo policial debe
Efectivo
10 Escena del delito caso para no Escena del delito velar que no se contamine la escena
Policial
contaminar la del hecho delictivo.
escena
p ág . 1 1 8
• Diagrama del proceso
El propósito de este artefacto es describir los roles, stakeholders, entradas, salidas y procesos del
proceso de “Registro Personal e Incautación” a fin de proporcionar un mejor entendimiento del
mismo.
• Declarativa
Este proceso permite fortalecer la actuación policial durante el registro e incautación en el proceso
de búsqueda de pruebas, actividades de prevención e intervenciones en flagrancia delictiva.
• Roles
Los roles de la empresa que intervienen en el presente proceso serán detallados en el siguiente
cuadro, en el cual se menciona el nombre del Rol, su respectiva descripción y el área funcional a
la que pertenece.
• Stakeholders
Todos los involucrados en el presente proceso y sus respectivas descripciones son mencionados a
continuación.
STAKEHOLDERS DESCRIPCIÓN
En el siguiente recuadro se menciona la entrada que tendrá el proceso, una breve descripción y el
encargado de elaborar el mismo.
Encargado de
Entrada DESCRIPCIÓN
Elaboración
• Caracterización
p ág . 1 2 1
ENTRADA ACTIVIDAD SALIDA DESCRIPCIÓN RESPONSABLE
Se registra la
necesidad del
Se registra la necesidad del registro de
- Inicio registro de Efectivo Policial
personal e incautación
personal e
incautación
Informar al
Se procederá a informar al detenido la
detenido de la
Fiscal de Turno Implicado causa, el motivo de su detención y el Efectivo Policial
causa y motivo de
delito que se le atribuye.
4 detención
p ág . 1 2 2
• Diagrama del proceso
El propósito de este artefacto es mencionar todas las reglas de negocio que rigen la empresa.
p ág . 1 2 5
Código Entidad Descripción Tipo
a otra comisaria
El propósito de este artefacto es identificar la participación de los actores en cada proceso, con el
fin de analizar la carga, importancia o grado en el que es imprescindible. De esta manera, luego, se
procede, a realizar la priorización tanto de los actores como de los procesos.
• Proceso denuncia/ocurrencia
Comisario X 1
Efectivo
X X X X X 5
Policial
Sospechoso X X X X X 5
Denunciante X X 2
Testigo X X X 3
p ág . 1 2 6
Control de Gestionar Registro
Dependencia Flagrancia
Actor Identidad escena del Personal e Total
Policial Delictiva
Policial delito Incautación
Abogado
X X 2
Defensor
Fiscal de
X X X 3
Turno
Total 3 6 4 5 3 21
La priorización de procesos permite identificar los procesos con una mayor participación y de esta
manera poder asignarle su respectiva prioridad respecto al número de actores que participan en
ellas.
En el siguiente gráfico se listarán los procesos, el número de relaciones en que participa el proceso
con los actores y la prioridad que recibe frente a otros procesos.
Control de Identidad
Procesos Prioridad
Policial
Dependencia Policial 6 1
Flagrancia Delictiva 4 3
p ág . 1 2 7
Fuente: Elaboración propia
• Priorización de actores
En el siguiente gráfico se lista los actores, el número de relaciones en que participa el proceso con
los sub-procesos y la prioridad que recibe frente a otros actores.
Comisario 1 4
Efectivo Policial 5 1
Sospechoso 5 1
Denunciante 2 3
Testigo 3 2
Abogado Defensor 2 3
Fiscal de Turno 3 2
p ág . 1 2 8
El mapeo de entidades – procesos se ha subdividido en cada uno de los macro-procesos
para que puedan visualizarse de una mejor manera.
• Proceso de Denuncia:
Gestionar
Proceso Dependencia Flagrancia Registro Personal
escena del Total
Policial Delictiva e Incautación
delito
Entidad
Delito X X X X 4
Denuncia X X X X 4
Implicados X X X X 4
Tipo de
X X X X 4
implicados
Comisaria X X X 3
Formalidad X X X 3
Sección X X X 3
Libro X X X 3
Ubicación X X X X 4
Vehículo X X X 2
Armas X X X 2
Especies X X X 2
Acta de
X X X 3
Registro
p ág . 1 2 9
Documento
X X 1
Resultado
Encuesta de
X X X X 4
Satisfacción
Total 15 11 10 13 49
• Proceso de Ocurrencia:
Delito X X X X X 5
Ocurrencia X X X X X 5
Implicados X X X X X 5
Tipo de
X X X X X 5
implicados
Comisaria X X X X 4
Formalidad X X X 3
Sección X X X 3
Libro X X X 3
Ubicación X X X X X 5
p ág . 1 3 0
Vehículo X X 2
Armas X X 2
Especies X X 2
Acta de
X X X X 4
Registro
Documento
X X 2
Resultado
Encuesta de
X X X X X 5
Satisfacción
Interviniente
X X X X X 5
(CIP)
Total 10 16 12 8 14 60
• Priorización de Entidades:
La priorización de las entidades de los procesos de denuncia/ocurrencia se obtuvo del análisis del
artefacto Mapeo Entidades – Procesos. Esta priorización permite identificar que entidades
participan en un mayor número de procesos, de esta manera dándole su relevancia y por lo tanto
su prioridad con respecto a las demás.
En el siguiente gráfico se listarán las entidades, el número de relaciones en que participa la entidad
con los sub-procesos y la prioridad que recibe frente a otras entidades. Cabe resaltar que la
prioridad se realizará en cada proceso por separado.
p ág . 1 3 1
• Proceso de Denuncias:
Delito 4 1
Denuncia 4 1
Implicados 4 1
Tipo de implicados 4 1
Ubicación 4 1
Encuesta de Satisfacción 4 1
Comisaria 3 2
Formalidad 3 2
Sección 3 2
Libro 3 2
Acta de Registro 3 2
Vehículo 2 3
Armas 2 3
Especies 2 3
Documento Resultado 1 4
p ág . 1 3 2
• Proceso de Ocurrencia:
Delito 5 1
Ocurrencia 5 1
Implicados 5 1
Tipo de implicados 5 1
Encuesta de Satisfacción 5 1
Interviniente (CIP) 5 1
Ubicación 5 1
Comisaria 4 2
Acta de Registro 4 2
Formalidad 3 3
Sección 3 3
Libro 3 3
Vehículo 2 4
Armas 2 4
Especies 2 4
Documento Resultado 2 4
p ág . 1 3 3
• Priorización de Entidades
La priorización de los procesos de los macro-procesos se obtuvo del análisis del artefacto Mapeo
Entidades – Procesos. Esta priorización permite identificar que procesos se relacionan en un
mayor número con las entidades, de esta manera dándole su relevancia y por lo tanto su prioridad
con respecto a los demás.
En el siguiente gráfico se listarán los procesos, el número de relaciones en que participa el proceso
con las entidades y la prioridad que recibe frente a otros procesos. Cabe resaltar que la prioridad se
realizará en cada macro-proceso por separado.
- Proceso de Denuncias:
Dependencia Policial 15 1
Flagrancia delictiva 11 3
- Proceso de Ocurrencia:
Dependencia Policial 16 1
Flagrancia delictiva 12 3
p ág . 1 3 4
Gestionar escena del delito 8 5
A continuación, se define la leyenda que será utilizada en la matriz de doble entrada para mostrar
la relación entre los procesos y las áreas funcionales de la empresa.
• Recibe (R): Cuando un área recibe información (documento, mensaje y/o datos) de un proceso.
• Apoya (A): Cuando un área entrega información (documento, mensaje y/o datos) a un proceso.
• Modifica (M): Cuando un área modifica la información (documento, mensaje y/o datos) que se
encuentra dentro de un proceso.
El propósito es identificar la relación de cada proceso respecto del área que modifica, recibe o
envía información necesaria para la correcta ejecución del proceso.
CONTROL BÚSQUEDA DE
GESTIONAR
DE PRUEBAS Y DEPENDENCIA
DIRECCIÓN ESCENA DEL
IDENTIDAD FLAGRANCIA CONTROLES POLICIAL
DELITO
POLICIAL DELICTIVA PREVENTIVOS
Dirección de
RA R - RAM -
Planeamiento
Estratégico
p ág . 1 3 5
Policial
Dirección de
Asesoramiento - - RAM RA RAM
Operativo
Dirección de
Asesoramiento - - - - RAM
Administrativo
Dirección de
Investigación y - - - RAM -
Desarrollo
Dirección de
Asesoramiento en
- - - RA -
Derechos
Humanos
Dirección
Ejecutiva de - - - - R
Administración
DIREPLAP - R - R -
DIREJEPER - - - RA -
Dirección
Ejecutiva de
RA - - - RA
Infraestructura y
Equipamiento
DIREASJUR - - - RA -
Dirección RA RA RA RA RA
Ejecutiva de
p ág . 1 3 6
Apoyo al Policía
Dirección
Ejecutiva de
- - - - -
Educación y
Doctrina
DIREICAJ - RA - RA -
DIRJOFE - RA - - -
DIREJSEGCIU R - RAM - -
DIREJANDRO - - RA - -
DIREJCOTE - - RA - -
DIREJSEVI R - - RA -
DIREJTURMA - - - - -
El propósito del presente documento es documentar las agrupaciones de las actividades según un
fin común para su futura automatización.
p ág . 1 3 7
• ANALISIS DE LA DESCOMPOSIÓN FUNCIONAL
p ág . 1 3 8
registro de Anotar a las personas ubicadas en el lugar
pertenencia del
Perennizar la escena de delito
detenido
p ág . 1 3 9
armas por serie Proteger la escena de delito
p ág . 1 4 0
Permite generar
Generar Reportes
el reporte
G14 Nominal por Se toma la información necesaria
nominal por la
región
región del Perú
p ág . 1 4 1
• DIAGRAMA DE DESCOMPOSICIÓN FUNCIONAL
El propósito es obtener un sistema integrado a partir de las funciones de negocio que se han
identificado en la descomposición funcional.
NUEVA DENUNCIA
Registrar Personas
Registrar Vehículos
Registrar Armas
Registrar Especies
Gestionar Contenido
CONSULTA GENERAL
Consultar Personas
Consultar Armas
Consultar Vehículos
REGISTRAR RESULTADO
Gestionar Detenidos
REPORTES
ESTADÍSTICAS
DENUNCIAS CIUDADANO
CONSULTA DE DENUNCIA
COPIA DE CERTIFICADOS
El diagrama de paquetes de primer nivel es el conjunto de relaciones que existe entre los módulos,
éstos representan el software y la dependencia de uno y otro.
p ág . 1 4 4
Ilustración 34 – Diagrama de paquete de primer nivel
El diagrama de paquetes de segundo nivel es el conjunto de relaciones que existe entre los
productos software y la dependencia de uno y otro.
p ág . 1 4 5
Ilustración 35 – Diagrama de paquete de segundo nivel
El diagrama de paquetes de tercer nivel es el conjunto de relaciones que existe entre las funciones de negocios o llamados casos de uso.
El propósito del diagrama de paquetes es integrar a nivel funcional los casos de uso e identificar las relaciones dependientes de cada una.
El propósito es ver las funcionalidades de un módulo y sus dependencias con las funcionalidades
de otros módulos.
Flagrancia Delictiva
Producto \ Proceso
Incautación
Total
Nueva Denuncia x x x X x 5
Consulta General X x 2
Registrar Resultado x X 2
Reportes x X 2
Estadísticas x X 2
Denuncias Ciudadano x 1
Consulta de denuncia x 1
Copia de certificado x x 2
Total 3 5 2 5 2 17
p ág . 1 4 9
Funcionalidad previa apoya a cierta Función de negocio y ésta precede a una funcionalidad
posterior. Este resultado nos ayudará a implementar de forma más eficiente el Cuadro de Control
de Aplicaciones.
El propósito de este artefacto es identificar las dependencias de las funciones de negocio que se
van a implementar.
DENUNCIAS
Fuente: Elaboración Propia
1 Nueva Denuncia
1 Registrar Personas
Gestionar Documento
1 Registrar Vehículos CU-6 Gestionar Contenido 3
Resultado
1 Registrar Armas
1 Registrar Especies
p ág . 1 5 0
2 Consulta General
3 Registrar Resultado
4 Reportes
p ág . 1 5 1
5 Estadísticas
2 Consultar Personas
2 Consultar Vehículos
6 Denuncias Ciudadano
7 Consulta de denuncia
p ág . 1 5 2
8 Copia de certificados
Karner identifica las funciones de negocio del proyecto, los actores que participan y clasifica cada
uno según su complejidad: simple, promedio y complejo. A partir de ello, calcula puntos de caso
de uso sin ajustar y luego puntos de caso de uso ajustados tomando en consideración los factores
técnicos y de entorno. Finalmente, se calcula el total de horas por hombre.
En este punto se obtiene el valor del Unadjusted Actor Weigth (UAW). Para ello debemos definir
una tabla que nos ayudará a obtener el valor del UAW. En la siguiente tabla tenemos las siguientes
columnas:
- Complejidad: nivel de complejidad que tienen los actores que están presentes en el
producto.
p ág . 1 5 3
- Total: La cantidad multiplicada por el peso da el total. Por ejemplo, si hay 5 actores
simples, y sabiendo que el peso es de 1, el total seria la multiplicación de ambos valores,
es decir, 5.
Nueva Denuncia
ACTORES COMPLEJIDAD
Denunciante Complejo
Comisario Promedio
Testigo Complejo
Sospechoso Complejo
Simple 0 1 0
Promedio 1 2 2
Complejo 4 3 12
UAW 14
p ág . 1 5 4
Consulta General
ACTORES COMPLEJIDAD
Simple 0 1 0
Promedio 0 2 0
Complejo 1 3 3
UAW 3
Registrar Resultado
ACTORES COMPLEJIDAD
Comisario Complejo
p ág . 1 5 5
TIPO DE ACTOR CANTIDAD PESO TOTAL
Simple 0 1 0
Promedio 1 2 2
Complejo 2 3 6
UAW 8
Reportes
ACTORES COMPLEJIDAD
Comisario Complejo
Simple 0 1 0
Promedio 1 2 2
Complejo 1 3 3
UAW 5
p ág . 1 5 6
Estadísticas
Actores Complejidad
Comisario Promedio
Simple 0 1 0
Promedio 1 2 2
Complejo 1 3 3
UAW 5
Denuncias Ciudadano
ACTORES COMPLEJIDAD
Denunciante Complejo
p ág . 1 5 7
Tipo de
Cantidad Peso Total
Actor
Simple 0 1 0
Promedio 0 2 0
Complejo 1 3 3
UAW 3
Consulta de denuncia
ACTORES COMPLEJIDAD
Denunciante Complejo
Simple 0 1 0
Promedio 0 2 0
Complejo 2 3 6
UAW 6
p ág . 1 5 8
Copia de certificados
ACTORES COMPLEJIDAD
Denunciante Complejo
Simple 0 1 0
Promedio 0 2 0
Complejo 1 3 3
UAW 3
Objetivo: Clasificar las funciones de negocio según las transacciones que se podrían realizar.
En este punto obtenemos el Unadjusted Use Case Weigth (UUCW). Para ello debemos definir una
tabla conformada por las siguientes columnas:
- Cantidad: La cantidad de Casos de uso que hay por cada tipo de caso de uso.
- Total: La multiplicación del peso (Ponderación) y la cantidad de casos de uso por cada
tipo de caso de uso
p ág . 1 5 9
- Simple: Caso de Uso de 1 a 3 transacciones
Nueva Denuncia
Simple 0 5 0
Promedio 1 10 10
Complejo 5 15 75
UUCW 85
p ág . 1 6 0
Consulta General
Simple 3 5 15
Promedio 0 10 0
Complejo 0 15 0
UUCW 15
Registrar Resultado
# DE
TIPO TRANSACCIONES PONDERACIÓN TOTAL
Simple 1 5 5
p ág . 1 6 1
Promedio 1 10 10
Complejo 0 15 0
UUCW 15
Reportes
Simple 0 5 0
Promedio 3 10 30
Complejo 0 15 0
UUCW 30
p ág . 1 6 2
Estadísticas
# DE
TIPO TRANSACCIONES PONDERACIÓN TOTAL
Simple 1 5 5
Promedio 0 10 0
Complejo 0 15 0
UUCW 5
Denuncias Ciudadano
Simple 0 5 0
Promedio 0 10 0
p ág . 1 6 3
Complejo 1 15 15
UUCW 15
Consulta de denuncia
# DE
TIPO TRANSACCIONES PONDERACIÓN TOTAL
Simple 2 5 10
Promedio 0 10 0
Complejo 0 15 0
UUCW 10
Copia de certificados
p ág . 1 6 4
Gestionar Copia de certificados Promedio
# DE
TIPO TRANSACCIONES PONDERACIÓN TOTAL
Simple 0 5 0
Promedio 1 10 10
Complejo 0 15 0
UUCW 10
El cálculo de los Puntos Caso de Uso (UUCP) se da sumando los valores anteriores obtenidos
(UAW y UUCW). Se sigue este esquema:
Nueva Denuncia
14 + 85 = 99
Por lo tanto, los puntos de casos de uso sin ajustar son igual a
99.
Consulta General
p ág . 1 6 5
UAW + UUCW = UUCP
3 + 15 = 18
Por lo tanto, los puntos de casos de uso sin ajustar son igual a
18.
Registrar Resultado
8 + 15 = 23
Por lo tanto, los puntos de casos de uso sin ajustar son igual a
23.
Reportes
5 + 30 = 35
Por lo tanto, los puntos de casos de uso sin ajustar son igual a
35.
p ág . 1 6 6
Tabla 83 – UUCP Reportes
Estadísticas
5 + 5 = 10
Por lo tanto, los puntos de casos de uso sin ajustar son igual a
10.
Denuncias Ciudadano
3 + 15 = 18
Por lo tanto, los puntos de casos de uso sin ajustar son igual a
18.
p ág . 1 6 7
Consulta de denuncia
6 + 10 = 16
Por lo tanto, los puntos de casos de uso sin ajustar son igual a
16.
Copia de certificados
3 + 10 = 13
Por lo tanto, los puntos de casos de uso sin ajustar son igual a
13.
Objetivo: Se procede a ajustar los puntos de casos de uso. Para ello es necesario tener cuenta las
consideraciones técnicas.
p ág . 1 6 8
La ponderación se estima dependiendo de la qué tan alto es el factor descrito. Este varía de 0 a 5,
donde 0 significa "nada" y 5 "totalmente". Por ejemplo, si el producto software va a tener una alta
facilidad de cambio (T9), tendríamos que poner una ponderación de 4 o 5 (muy alta o completa).
El TFactor (TF) se obtiene sumando toda la fila del total de la tabla. Esta variable se usa en la
siguiente fórmula para obtener el TCF:
CALIFICACIÓN
FACTOR DESCRIPCIÓN PESO TOTAL
(1 AL 5)
T1 Sistema Distribuido 4 2 8
T2 Tiempo de Respuesta 3 2 6
T4 Procesamiento Complejo 3 1 3
T5 Reusabilidad 3 1 3
T8 Portabilidad 2 2 4
T9 Facilidad de cambio 1 1 1
T10 Concurrencia 4 1 4
T11 Seguridad 5 1 5
T13 especial 2 1 2
Entrenamiento
p ág . 1 6 9
requerido
Total
General 44.5
(TF)
Tabla 88 - TFC
Resultado: Se debe considerar que a todos los productos tienen el mismo TFC.
• Factor de Entorno
Objetivo: Se procede a ajustar los puntos de casos de uso. Para ello es necesario tener cuenta las
consideraciones del entorno.
Para obtener el EF, se obtiene una variable llamada EFactor con el mismo plan con el que se
obtuvo el TFactor, con la suma ponderada de los siguientes factores de la siguiente tabla:
Para obtener él TE, se suma el total de la columna Total. Ese será el valor de TE, el cual se usa en
la siguiente fórmula para obtener el EF:
CALIFICACIÓN (1
FACTOR DESCRIPCIÓN PESO TOTAL
AL 5)
Familiaridad con la
F1 5 1.5 7.5
metodología
Experiencia en la
F2 4 0.5 2
aplicación
p ág . 1 7 0
F4 Capacidad de análisis 5 0.5 2.5
F5 Motivación 5 1 5
F6 Requisitos estables 5 2 10
Trabajadores a tiempo
F7 2 -1 -2
parcial
Total General
27
(EFactor)
Resultado: Se debe considerar que existen productos que tiene ligeramente el EF con mayor
consideración.
Nueva Denuncia
UCP = 61.03845
Consulta General
p ág . 1 7 1
UCP = 18 * 1.045 * 0.59
UCP = 11.0979
Registrar Resultado
UCP = 14.18065
Reportes
UCP = 21.57925
Estadísticas
UCP = 6.1655
Denuncias Ciudadano
UCP = 11.0979
p ág . 1 7 2
Consulta de denuncia
UCP = 9.8648
Copia de certificados
UCP = 8.01515
Nueva Denuncia
p ág . 1 7 3
Hombres
Consulta General
Registrar Resultado
Reportes
Estadísticas
Denuncias Ciudadano
p ág . 1 7 4
Cantidad de Días / Hombres = 13.872375 Días / Hombres
Consulta de denuncia
Copia de certificados
Objetivo: Una vez identificado el tiempo en el que una persona tardaría en realizar el proyecto se
procede a analizar las posibilidades de distribución del trabajo.
Nueva Denuncia
p ág . 1 7 5
Ilustración 38 – Distribución de trabajo “Nueva denuncia”
x= 76,30 horas/hombre
Resultado: El producto “Nueva Denuncia” se puede realizar en 76,30 horas con ocho personas.
Consulta General
p ág . 1 7 6
Ilustración 39 Distribución de trabajo “Consulta general”
x= 36,99 horas/hombre
Resultado: El producto “Consulta General” se puede realizar en 36,99 horas con tres personas.
Registrar Resultado
x= 35,45 horas/hombre
p ág . 1 7 7
Resultado: El producto “Registrar Resultado” se puede realizar en 35,45 horas con cuatro
personas.
Reportes
x= 35,97 horas/hombre
Resultado: El producto “Reportes” se puede realizar en 35,97 horas con seis personas.
Estadísticas
x= 61,655 horas/hombre
p ág . 1 7 8
x= 61,66 horas/hombre
Resultado: El producto “Estadísticas” se puede realizar en 61,66 horas con una persona.
Denuncias Ciudadano
x= 55,49 horas/hombre
Resultado: El producto “Denuncias Ciudadano” se puede realizar en 55,49 horas con dos
personas.
Consulta de denuncia
p ág . 1 7 9
2x= 98,648
horas/hombre
x= 49,32 horas/hombre
Resultado: El producto “Consulta de denuncia” se puede realizar en 49,32 horas con dos personas.
Copia de certificados
2x= 80,151
horas/hombre
x= 40,08 horas/hombre
Resultado: El producto “Copia de certificados” se puede realizar en 40,08 horas con dos personas.
El propósito de este artefacto es poder establecer los tiempos de realización de las aplicaciones
establecidas en el Tablero de Control de Aplicaciones, las etapas de desarrollo, las aplicaciones
p ág . 1 8 0
que se desarrollaran dentro de cada una de ella y el tiempo específico necesario para concluir cada
aplicación.
• Cuadro de Control
p ág . 1 8 1
Denuncias
Registrar denuncias - delito menor
Ciudadano DN.DC.CU01
De las estimaciones de esfuerzo se obtienen las horas hombre para la elaboración de los casos de
uso de los productos a realizar:
p ág . 1 8 2
DN.RR.CU02 141.807 35,45
Las horas/hombre del caso de uso mostrado en la tabla anterior son calculadas partiendo de las
posibilidades de distribución en las estimaciones de esfuerzo. Cabe recalcar que en las
posibilidades de distribución se asignan “x” multiplicado por un número el cual depende la
complejidad de los casos de usos (simple, promedio, complejo) descritos en el mismo documento.
Por lo tanto, las horas/hombre se calcularon como:
∑ 𝑋𝑋
h/h del caso de uso = (𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶 𝑑𝑑𝑑𝑑 𝑥𝑥 𝑑𝑑𝑑𝑑𝑑𝑑 𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐 𝑑𝑑𝑑𝑑 𝑢𝑢𝑢𝑢𝑢𝑢)
𝑈𝑈𝑈𝑈𝑈𝑈 ∗ 10
Luego, teniendo las posibilidades de distribución de trabajo considerando los casos de uso de
todos los productos y sus dependencias según el tablero de control de aplicaciones se obtiene el
siguiente cuadro de control de proyectos en los cuales los casos de uso de una misma columna se
pueden realizar en paralelo tomando el mayor de las horas/hombre de los casos de uso como
tiempo de desarrollo de los casos de uso.
p ág . 1 8 3
Para la división de las etapas se consideró la cantidad de casos de uso paralelos a realizar. Para la
etapa 1 una cantidad de casos de uso mayor o igual a 3 a 5 casos de uso. En la etapa 2 se tiene de 4
casos de uso en paralelo. En etapa 3 se tienen hasta 1 a 2 casos de uso en paralelo. Esta
distribución afecta en la cantidad de personas necesarias para desarrollar los casos de usos
paralelos de cada etapa.
CUENTAS
CONFIGURACIÓN
DN.CD.CU02
76,30 h/h 50,87 h/h 50,87 h/h 61,66 h/h 40,08 h/h 35,97 h/h
p ág . 1 8 4
Del cuadro de control de proyectos se obtiene que la duración del proyecto es 315,75 horas.
Considerando que en un mes se trabajan 20 días y 8 horas cada día se obtiene que el tiempo total
también se puede expresar como 1,9735 meses.
Analizar, de forma más clara, el posible flujo de información que pueda existir entre los productos
y definir los servicios de aplicación.
Denuncias Ciudadano
Consulta de denuncia
Copia de certificados
Registrar Resultado
Consulta General
Nueva Denuncia
ATRIBUTOS
PRODUCTO
Estadísticas
SERVICIO
Reportes
CodigoModalidad X X X X X X X X
VerTipodeDelito
NombreModalidad X X X X X X X X
CodigoFormalidad X X X X X X X X
ObtenerFormalidad
NombreFormalida
Nueva
d X X X X X X X X
Denunc
ia
CodigoLibro X X X X X X X X
ObtenerLibro
NombreLibro X X X X X X X X
CodigoSección X X X X X X X X
ObtenerSección
NombreSección X X X X X X X X
p ág . 1 8 5
Codigo Ubicación X X X X X X X X
ObtenerCodigoLugarDen
uncia
NombreDistrito X X X X X X X X
CodigoTipoImplica
do X X X X X X X X
VerTipodeImplicado
NombreTipoImplic
ado X X X X X X X X
• Servicios de Aplicación
Código SA0001
Tipo Aplicación
CodigoModalidad
Entradas
Materia
p ág . 1 8 6
Salidas Nombre de la modalidad
Código SA0002
Tipo Aplicación
CodigoFormalidad
Entradas
NombreFormalidad
Salidas NombredelaFormalidad
Código SA0003
Tipo Aplicación
p ág . 1 8 7
Nueva Denuncia, Consulta General, Registrar Resultado, Reportes,
Clientes Estadísticas, Denuncias Ciudadano, Consulta de denuncia, Copia de
certificados
CodigoLibro
Entradas
NombreLibro
Código SA0004
Tipo Aplicación
CodigoSección
Entradas
NombreSección
p ág . 1 8 8
Código SA0005
Tipo Aplicación
Codigo Ubicación
Entradas
NombreDistrito
Código SA0006
Tipo Aplicación
Entradas CodigoTipoImplicado
p ág . 1 8 9
NombreTipoImplicado
• Servicios de Negocio
Código SN0001
Tipo Negocio
CodigoImplicado, CodigoTImplicado
Edad, Sexo
Salidas -
p ág . 1 9 0
Código SN0002
Tipo Negocio
CodigoImplicado, CodigoTImplicado
Edad, Sexo
Salidas -
UPDATE Implicado
Código SN0003
Tipo Negocio
(…)
p ág . 1 9 1
Salidas -
Código SN0004
Tipo Negocio
(…)
Salidas -
UPDATE Vehiculo
Código SN0005
p ág . 1 9 2
Tipo Negocio
(…)
Salidas -
Código SN0006
Tipo Negocio
(…)
Salidas -
UPDATE Especie
p ág . 1 9 3
Código SN0005
Tipo Negocio
Salidas -
Código SN0006
Tipo Negocio
(…)
Salidas -
UPDATE Arma
p ág . 1 9 4
Fuente: Elaboración Propia
Código SN0005
Tipo Negocio
(…)
Salidas -
Código SN0006
Tipo Negocio
(…)
p ág . 1 9 5
Salidas -
UPDATE Denuncia
• Servicios Técnicos
Código ST0001
Tipo Técnico
Código Comisaria
Entradas
Código Región
p ág . 1 9 6
Código ST0002
Tipo Técnico
Código ST0003
Tipo Técnico
p ág . 1 9 7
SELECT CodDenCiudadano FROM Denuncia WHERE
Sentencia SQL
CodDenCiudadano, FechaDenuncia, Lugar denuncia… = (…);
Código ST0004
Tipo Técnico
CodigoCIP
Nombre
Entradas
Apellidos
Cargo
p ág . 1 9 8
Código ST0005
Tipo Técnico
CodImplicado
TipoDocumento
Entradas NumDocumento
ApellidoPaterno
ApellidoMaterno
Código ST0006
Tipo Técnico
CodPlaca
Entradas
CodMotor
p ág . 1 9 9
Salidas Información del vehículo implicado
Código ST0007
Tipo Técnico
CodArma
Serie
Entradas
Calibre
Color
p ág . 2 0 0
Código ST0008
Tipo Técnico
Código ST0009
Tipo Técnico
CodDelito
Entradas
CodDenuncia
p ág . 2 0 1
Salidas Reporte de denuncias por delito.
SELECT CodDelito
Sentencia SQL
FROM Arma WHERE CodDelito,
CodDenuncia… = (…);
Código ST0010
Tipo Técnico
CodDelito
Entradas
TipoSección
SELECT CodDelito
Sentencia SQL
FROM Arma WHERE CodDelito, TipoSección…
= (…);
p ág . 2 0 2
Código ST0011
Tipo Técnico
CodDelito
Entradas
Ubicación
SELECT CodDelito
Sentencia SQL
FROM Arma WHERE CodDelito, Ubicacion… =
(…);
Código ST0012
Tipo Técnico
p ág . 2 0 3
CodDelito
Entradas CodDenuncia
CodIncidencia
SELECT CodDelito
Sentencia SQL
FROM Arma WHERE CodDelito, CodDenuncia,
CodIncidencia… = (…);
Código ST0013
Tipo Técnico
CodDelito
Entradas CodCIP
Nombres
p ág . 2 0 4
SELECT CodDelito
Sentencia SQL
FROM Arma WHERE CodDelito, CodCIP,
Nombres… = (…);
Código ST0014
Tipo Técnico
CodDelito
Entradas TipoDocumento
CodDocumento
SELECT CodDelito
Sentencia SQL
FROM Arma WHERE CodDelito,
TipoDocumento, CodDocumento… = (…);
p ág . 2 0 5
Código ST0015
Tipo Técnico
CodDenuncia
Entradas TipoDelito
CodDelito
SELECT CodDelito
Sentencia SQL
FROM Arma WHERE CodDelito,
TipoDocumento, CodDocumento… = (…);
Código ST0016
Tipo Técnico
Entradas CodDenuncia
p ág . 2 0 6
CodComisaria
Ubicación
SELECT CodDenunia
Sentencia SQL
FROM Arma WHERE CodDenunia,
CodComisaria, Ubicacion… = (…);
Código ST0017
Tipo Técnico
CodDenuncia
Entradas
TipoDocumento
SELECT CodDenunia
Sentencia SQL
FROM Arma WHERE CodDenunia,
TipoDocumento, Ubicación… = (…);
p ág . 2 0 7
5.2.3 Servicios de Aplicación, Negocios y Técnicos
El Portafolio de Servicios lista todos los servicios que se consumen. Este artefacto permite
identificar las cantidades de servicios que maneja cada uno de los módulos de la empresa.
Identificar todos los servicios de Negocio, Técnicos y de Aplicación que consume un producto.
p ág . 2 0 8
ActualizarPersonaDesaparecidas Negocio Denuncia Policial
p ág . 2 0 9
Resumen:
Identificar todos los servicios de Negocio, Técnicos y de Aplicación que consume un producto.
VerTipodeImplicado
Se muestra la lista del tipo de implicado en
p ág . 2 1 0
la denuncia
ObtenerEfectivoPolicial
Se muestra la información del efectivo
policial que realizó la denuncia
17
Servicio Técnico
p ág . 2 1 1
implicado en la denuncia
TOTAL 37
p ág . 2 1 2
5.2.5 Navegabilidad
El artefacto Navegabilidad permite conocer la relación que hay entre las interfaces que maneja el
sistema. Este artefacto tiene como input al artefacto User Interfaces o Interfaces de Usuario, en
base a las interfaces desarrolladas es que se tiene que ver la relación que se tiene entre ellas y
mostrar cual lleva a la otra para continuar el flujo del proceso.
El propósito del artefacto Navegabilidad es reflejar la interacción que se tiene entre las interfaces
para poder completar los flujos de los procesos del negocio mediante el sistema.
p ág . 2 1 3
Ilustración 46 – Mapa de Navegabilidad
Identificar todas las interfaces de usuario con los actores que pueden realizar alguna acción sobre
ellas.
• Matriz de Acceso:
Leyenda
R=Registrar
A=Actualizar
V=Visualizar
Permisos
Gestionar Documento
Todos V -
Registrar IU_DN_010 Resultado
Resultado
IU_DN_011 Gestionar Detenidos Todos V -
Generar Búsquedas de
V Todos -
IU_DN_012 Detenidos
Generar Búsqueda de
Reportes Todos V -
IU_DN_013 Persona Detenida
Generar Estadísticas de
Estadísticas Todos R -
IU_DN_015 denuncia
Consultar personas
V V V
Consulta de IU_DN_017 desaparecidas
denuncia
IU_DN_018 Consultar personas buscadas V V V
p ág . 2 1 6
5.2.7 Interfaces de Usuarios
El artefacto IUCP define la forma de construcción del producto software a través de prototipos que
muestren las funciones de negocio automatizadas y la navegabilidad entre ellas.
• CIUDADANO
Ilustración 47 – Ciudadano 1
p ág . 2 1 7
Ilustración 48 – Ciudadano 2
Ilustración 49 - Ciudadano 3
p ág . 2 1 8
Ilustración 50 - Ciudadano 4
Ilustración 51 - Ciudadano 5
p ág . 2 1 9
Ilustración 52 – Ciudadano 6
Ilustración 53 – Ciudadano 7
p ág . 2 2 0
Ilustración 54 – Ciudadano 8
p ág . 2 2 1
Ilustración 55 – Ciudadano 9
Ilustración 56 –Ciudadano 10
p ág . 2 2 2
Ilustración 57 – Ciudadano 11
p ág . 2 2 3
Ilustración 58 – Ciudadano 12
• EFECTIVO POLICIAL
Ilustración 59 – Policía 1
p ág . 2 2 4
Ilustración 60 – Policía 2
Ilustración 61 – Policía 4
p ág . 2 2 5
Ilustración 62 – Policía 3
Ilustración 63 – Policía 5
p ág . 2 2 6
Ilustración 64 – Policía 6
Ilustración 65 – Policía 7
p ág . 2 2 7
Ilustración 66 – Policía 8
Ilustración 67 – Policía 9
p ág . 2 2 8
Ilustración 68 – Policía 10
Ilustración 69 – Policía 11
p ág . 2 2 9
Ilustración 70 – Policía 12
Ilustración 71 – Policía 13
p ág . 2 3 0
Ilustración 72 – Policía 14
Ilustración 73 – Policía 15
p ág . 2 3 1
Ilustración 74 – Policía 16
Ilustración 75 – Policía 17
p ág . 2 3 2
Ilustración 76 – Policía 18
Ilustración 77 – Policía 19
p ág . 2 3 3
Ilustración 78 – Policía 20
Ilustración 79 – Policía 21
p ág . 2 3 4
Ilustración 80 – Policía 22
5.3.1.1 Descripción
Para desarrollar las funcionalidades de software en la arquitectura empresarial necesitamos
obtener una visión de la relación entre los objetos físicos y documento de toda la empresa y en
este caso de la cadena de suministro. De esta forma se reconocen las dependencias entre los
objetos reales de la empresa y se priorizan aquellas entidades de mayor importancia
5.3.1.2 Propósito
El modelo de dominio nos ayuda a entender las dependencias y modelado de las entidades, así
como las relaciones entre ellas. Este artefacto nos sirve como base para desarrollar las clases con
funciones y atributos que se desarrollarán en las funcionalidades para la aplicación
5.3.1.3 Alcance
El alcance de este artefacto es identificar y especificar el modelo lógico de datos de la Empresa
p ág . 2 3 5
5.3.1.4 Modelo lógico
p ág . 2 3 6
5.3.2 Modelo Físico
5.3.2.1. Descripción
El Modelo de Datos Relacional muestra la dependencia entre tablas que se da según los datos que
comparten, como llaves primarias, llaves foráneas. Se muestran relaciones de tablas que inclusive
pertenecen a diferentes propietarios
5.3.2.2. Propósito
El propósito de este artefacto es mostrar las relaciones que existen entre la información que se
maneja en la empresa y así poder determinar qué grupo de datos o tablas son los críticos y, por
tanto, importantes. Asimismo, representas los datos que maneja el sistema de información
5.3.2.3. Alcance
El alcance de este artefacto es representar físicamente la estructura y la organización de los datos
del negocio.
p ág . 2 3 7
Ilustración 82 - Modelo físico del proyecto
5.3.3.1. Descripción
La Especificación de Modelo de Datos muestra las tablas del producto seleccionado y
especificando el tipo de tabla, producto propietario, descripción, clave primaria y la clave foránea.
En el caso del tipo de tabla habrá cuatro opciones, primero, Maestra la cual se refiere a que cada
registro se identifica con un único código. Por otro lado, el tipo Sub-Maestra es aquel que cada
registro se identifica con un código único y por el código del padre. Además, el tipo de tabla
histórica se refiere a los registros que no se pueden identificar por un código único, pero si por
otros campos heredados. Por último, el tipo de tabla general se refiere a la identificación de
registros por códigos únicos y aplica a más de una función
5.3.3.2. Propósito
En base al modelo de datos, se procederá a describir las entidades, en la cual se mencionará el tipo
de tabla, producto propietario, descripción, clave primaria y clave foránea que pertenecen al
proceso de denuncias
5.3.3.3. Alcance
La Especificación de Modelo de Datos es un artefacto que depende del Modelo Lógico
Registra información de
Ubicación SubMaestra Denuncia Policial las ubicaciones de las CodUbicacion -
denuncias
Registra la información
CodigoComisari
Comisaria Maestra Denuncia Policial de las comisarias a nivel -
a
nacional.
Contiene el tipo de
Formalidad Maestra Denuncia Policial formalidad el cual fue CodFormalidad -
emitida la denuncia
Registra la información
IntervinienteCIP Maestra Denuncia Policial CodCIP CodComisaria
del efectivo policial
CodArmas
CodVehiculo
CodLibro
CodSeccion
realizada por el
Denuncia Maestra Denuncia Policial CodDenuncia CodComisaria
ciudadano o el efectivo
policial. CodTDenuncia
CodUbicacion
CodFormalidad
CodDelito
CodEspecie
Contiene el registro de
TipoImplicado Maestra Denuncia Policial CodTImplicado CodImplicado
los tipos de implicados.
p ág . 2 4 0
una denuncia.
Registra la información
de las especies
Especie SubMaestra Denuncia Policial CodEspecie -
encontradas en el acto
delictivo.
Registra la información
de vehículos
Vehiculo SubMaestra Denuncia Policial CodVehiculo -
encontrados en el acto
delictivo.
Registra la información
de las armas
Arma SubMaestra Denuncia Policial CodArma -
encontrados en el acto
delictivo.
Registra la información
Doc_Resultado SubMaestra Denuncia Policial
procesada del delito.
5.3.4.1. Descripción
El Mapeo Producto – Tabla muestra las tablas del producto seleccionado y especifica si la tabla es
de escritura o lectura. Las tablas son agrupadas por el tipo de tabla, ya sea “Maestras” o “Sub
Maestras”. En el caso del tipo de tabla habrá dos opciones, primero, Maestra la cual se refiere a
que cada registro se identifica con un único código. Por otro lado, el tipo Sub-Maestra es aquel
que cada registro se identifica con un código único y por el código del padre
5.3.4.2. Propósito
En el Mapeo Producto -Tabla, se procederá a especificar si las tablas maestras y sub maestras se
pueden escribir o solo leer para cada producto a las que pertenecen.
p ág . 2 4 1
5.3.4.3. Alcance
El Mapeo Producto – Tabla es un artefacto que depende de la Especificación de Modelo de Datos
DENUNCIA
PRODCUCTO
POLICIAL
Maestra Formalidad L
Maestra TipoDenuncia L
Maestra TipoImplicado L
p ág . 2 4 2
SubMaestra Vehiculo E/L
5.4.1.1. Descripción
El artefacto Diagrama de Componentes ayuda a poder identificar los componentes lógicos que se
requerirán para el funcionamiento del sistema. Estos componentes se deben de clasificar en base a
los productos que se van a desarrollar. Alguno de los componentes lógicos a tomar en cuenta son:
tablas, librerías tanto internas como externas, interfaces, etc. Entre estos mismos componentes,
hay una relación que se tiene que mostrar para su entendimiento, así como que tablas alimentan
que librería y qué librerías alimentan a tales interfaces, entre otros casos. A partir de este
diagrama, es que se podrá identificar que componentes lógicos son los que se van a desplegar
5.4.1.2 Propósito
El propósito del artefacto Diagrama de Componentes es identificar los componentes lógicos que
se van a desplegar para el funcionamiento correcto del sistema
5.4.1.3. Alcance
El alcance del artefacto Diagrama de Componentes es determinar la parte lógica requerida para el
funcionamiento del sistema.
37 37
SIDPOL_Especificació SIDPOL_DiagramaCo
p ág . 2 4 3
5.4.2 Diagrama de Despliegue
5.4.2.1. Descripción
El diagrama de despliegue describe la arquitectura física del sistema durante la ejecución, en
términos de: procesadores, dispositivos, componentes de software: nodos (Router y switch).
Además, describe la topología del sistema: la estructura de los elementos de hardware y el
software que ejecuta cada uno de ellos.
5.4.2.2. Propósito
El propósito de este artefacto es el poder visualizar la interacción entre los nodos de la empresa
5.4.2.3. Alcance
A través del Diagrama de Despliegue se visualizará la interacción entre los nodos del Producto de
denuncias con los demás productos dentro del módulo principal de denuncias
p ág . 2 4 4
Ilustración 83- Diagrama de despliegue
5.4.3.1. Descripción
La Especificación de Despliegue es un artefacto perteneciente a la Arquitectura Empresarial. Se
encuentra en la arquitectura de Redes. Este artefacto representa las especificaciones que el
diagrama de despliegue va a tener. Estas especificaciones son todos los dispositivos físicos
llamados nodos donde en cada nodo se establece el protocolo de comunicación. De igual manera,
en cada nodo se especifica el modelo y marca, y lo que despliega
5.4.3.2. Propósito
Analizar y detallar de una forma más clara todo lo que el diagrama de despliegue va a contener ya
sea todos los nodos necesarios como sus respectivas especificaciones
5.4.3.3. Alcance
En este artefacto se presenta la especificación de cada nodo del diagrama de despliegue de la
arquitectura de redes perteneciente Al sistema de denuncia policial de la PNP.
p ág . 2 4 7
Switch necesario para realizar las
Switch Cisco Switch Comisaria conexiones entre los servidores y
los routers
Es un enrutador o encaminador
que nos sirve para interconectar
redes de ordenadores y que
Router Cisco Router Comisaria actualmente implementan puertas
de acceso a internet como son los
router para ADSL, los de Cable o
3G.
Representa a la cantidad de
computadoras correspondientes al
Terminal Computadora Comisaria
proceso de denuncias dentro de
una comisaria
5.4.4.1. Descripción
Es una representación esquemática de las interacciones de los dispositivos de una red. Un
diagrama de red muestra los dispositivos que se permiten en una red, tales como routers y
switches, así como los dispositivos que acceden a la red, tales como PC. Un diagrama de red
indicará típicamente también subdivisiones de una red en subredes
p ág . 2 4 8
5.4.4.2. Propósito
Mostrar todos los dispositivos incluidos en la red de la empresa y cómo interactúa entre sí
5.4.4.3. Alcance
A través del Diagrama de Red se visualizará la interacción entre los dispositivos que pertenecerán
a la red del producto de denuncias con los demás productos dentro del módulo principal de
denuncia
p ág . 2 4 9
Ilustración 84 – Diagrama de red – Sistema de denuncia PNP
p ág . 2 5 0
Ilustración 85 – Gabinete SIDPOL
p ág . 2 5 1
Ilustración 86 – Componentes del diagrama de despliegue
5.5.1.1. Introducción
La implementación de un sistema integrado para la administración, control y consolidación del
sistema de denuncias policial, sustituirá los procesos manuales por procesos automatizados,
procesos que actualmente aumentan el riesgo operativo día a día, aumentando el tiempo de trabajo
por denuncia y el cumplimiento de las denuncias pendientes.
Con la creación de los planes de gestión de este proyecto, se pretende llevar una adecuada
planificación del mismo, la cual fortalezca la administración de sistema de denuncias policial.
5.5.2 Posicionamiento
El propósito del este proyecto, es a través de los Productos Software de Denuncias Policial y
ciudadana, es el de controlar, administrar y asegurar la información de todas las transacciones
realizadas por ambos actores, automatizando la mayor cantidad de actividades de los procesos
involucrados.
5.5.2.2 Objetivos
Objetivo General: Diseñar el proceso de denuncia policial que permita mejorar las
funcionalidades del sistema SIDPOL para que sea soportado a nivel nacional.
Objetivo Específico 1: Analizar los requerimientos funcionales del sistema actual de denuncia
policial de la PNP.
Objetivo Específico 3: Proponer funciones de negocio integradas que cubran las necesidades del
negocio.
Objetivo Específico 4: Proponer un plan de continuidad que garantice la operación y soporte del
proyecto.
p ág . 2 5 4
5.5.2.3 Indicadores de éxito
- El cliente deberá tener dominio del tema sobre su división y el proceso de denuncias.
p ág . 2 5 5
- No se requiere ningún desarrollo adicional a los mencionados como parte del alcance del
proyecto. Si se detectase la necesidad de un desarrollo nuevo durante la ejecución del
proyecto, este será tratado como un adicional
- Las pruebas y validaciones deberán ser realizadas y respondidas por los usuarios dentro de
un plazo máximo de 3 días a menos que se acuerde un plazo diferente al momento de
generarse la necesidad de la información. De lo contrario, se sobreentiende la aprobación
de los mismos al vencimiento del plazo establecido
- TI-CONSULTING no se hace responsable de los atrasos que puedan originarse por parte
de DIRINFOR-PNP ya sea por demoras en definiciones, pruebas, validaciones y toda
interacción que afecte el cumplimiento de los plazos y alcance acordados. De requerirse
más tiempo por estos motivos, se tratará como tiempo adicional facturable
p ág . 2 5 6
5.5.2.6 Restricciones
RESTRICCIONES DESCRIPCIÓN
p ág . 2 5 7
5.5.3 Organización del Proyecto
REMUNERACIÓN
ROL RESPONSABILIDADES
MENSUAL
p ág . 2 5 8
Evaluar y hacer seguimiento a los avances
del proyecto.
p ág . 2 5 9
Encargado de realizar el desarrollo de
software siguiendo el ciclo de vida del
software.
5.5.3.2 Responsabilidades
Stakeholders Necesidades
p ág . 2 6 0
Proveedores de Empresas seleccionadas para proveer el software a adquirir.
Software
Recurso Humano
ROL Cantidad
Jefe de Proyecto 1
Shadow (DIRINFOR) 1
Gestor de Desarrollo 1
Analista de Pruebas 2
Analista de Desarrollo 4
Analista de Infraestructura 1
Analista de Negocio 2
Documentador 1
Capacitador 1
Recursos Hardware:
Recursos Software:
p ág . 2 6 1
• Microsoft Office 2010 o más reciente
- Microsoft Word
- Microsoft Excel
- Microsoft Project
• Adobe Reader
• Google Drive
p ág . 2 6 2
está alojada bajo una plataforma virtual
VMWARE. Tiene como característica
Windows Server 2012 Enterprise y IIS
7.
Representa a la cantidad de
computadoras correspondientes al
Terminal Computadora proceso de Contabilidad. Cantidad: 2.
Una para el jefe de Contabilidad y otra
para el asistente
Impresora
Impresora La impresora multifuncional permitirá
Multifuncional imprimir los estados financieros y los
p ág . 2 6 3
reportes asociados en el área
5.5.3.4 Facilidades
La empresa cliente deberá brindar las facilidades posibles, respetando las limitaciones de
seguridad, para el acceso a la información por parte de la Dirección de Informática, todos los
usuarios involucrados en el desarrollo deberán tener permisos de administración con equipos
licenciados para la realización de su labor. Los procesos de negocio deberán ser entregados al jefe
de proyecto para su correspondiente análisis y validación de requerimientos funcionales.
FASE I: Diagnóstico
Se realizará una evaluación de los procesos de negocio y determinar el verdadero impacto que
tiene sobre la mala gestión de la información y la carencia de algún sistema propio.
p ág . 2 6 4
FASE II: Elaboración de la documentación soporte
Se realiza el análisis de los documentos existentes en la empresa frente a los requisitos de las
normas a las cuales apunta como referentes de buenas prácticas.
- Formación
- Difusión/Comunicación
5.5.4.1 Cronograma
De manera ordenada se pasa a detallar el cronograma del proyecto y su correspondiente
subdivisión orientada al mismo desde el entendimiento del negocio hasta la implementación de un
Sistema Integrado.
- Fase Inicial: Abarca las tareas donde se delimita el alcance y se elabora el acta
constructiva.
- Fase de Planificación: compendio de actividades que permiten la generación del plan del
proyecto, el estudio de mercado y el proceso licitatorio.
- Fase de Ejecución: contempla las tareas requeridas para la generación de los entregables y
la ejecución del plan del proyecto. Abarca la implementación del sistema.
- Fase de Seguimiento: comprende las tareas de control del proyecto, como reuniones de
seguimiento.
p ág . 2 6 5
Fase de Cierre: alcanza las tareas de cierre del proyecto tanto administrativo como contractual,
previa revisión de los criterios de aceptación del proyecto.
5.6.1 Introducción
En el contenido de este punto se realizó una investigación real del mercado laboral para poder
considerar los costos de la implementación y continuidad del proyecto.
p ág . 2 6 6
COSTO DE IMPLEMENTACIÓN
Análisis
Diseño
Desarrollo
Pruebas Integrales
Proyecto / Fases
Documentación
Capacitación
Online Support
24 hrsx 7
Holiday Covered
Computadora + Modem
Hardware
p ág . 2 6 7
Resultado de la propuesta económica:
Notas:
• Forma de pago:
• No se incluyen gastos de transporte, viaje, estadía, para sites fuera de Lima Metropolitana en
Lima, Perú. No incluye licenciamiento de cualquier otro software.
5.6.3 Capacitación
Se considera la presencia de un KEY USER durante el proceso de implementación del Sistema
Integrado en la sede lima. Éste será junto con el equipo encargado de la implementación quien
sirva de apoyo y soporte a los usuarios finales del Sistema. Adicionalmente, se realizará una
capacitación con usuarios finales de distintas regiones del país al concluir el Proyecto a fin de
fortalecer sus conocimientos en cuanto a procesos y gestión de la información. Así como la
explotación de datos y reportes a la dirección.
p ág . 2 6 8
5.6.4. Riesgos y mitigación
PROBABILID IMPACT
# RIESGO ESTRATEGIA DE MITIGACIÓN
AD O
p ág . 2 6 9
PROBABILID IMPACT
# RIESGO ESTRATEGIA DE MITIGACIÓN
AD O
p ág . 2 7 0
5.6.5 Proyectos de continuidad
Se realizó una investigación de posibles proyectos de continuidad para la cartera de proyecto los
cuales están alineados al mismo objetivo del proyecto Mejora del sistema de SIDPOL para la
Policía Nacional del Perú
• Objetivo General: Desarrollar e implementación una aplicación que permita brindar los
principales servicios de una denuncia al ciudadano.
• Nombre: Desarrollo de una aplicación nativa para Smartphone de registro de denuncias del
ciudadano.
• Objetivo General: Desarrollar e implementación una aplicación que permita brindar los
principales servicios de una denuncia al ciudadano.
• Nombre: Desarrollo de una aplicación web que permita realizar un análisis predictivo en
tiempo real de los delitos cometidos en el Perú.
• Objetivo General: Desarrollo de una solución web de análisis predictivo que permita al
efectivo policial predecir los delitos a nivel nacional.
p ág . 2 7 1
CAPITULO 6 Gestión del Proyecto
En este capítulo se presenta la gestión del proyecto, donde se evalúa si el resultado corresponde
con el alcance que se planteó al inicio del proyecto, es decir si la Arquitectura Empresarial del
sistema SIDPOL se realizó según los planes de gestión tales como el análisis de la gestión del
tiempo, comunicaciones, recursos humanos y los riesgos. Por último, se menciona las lecciones
aprendidas que se han presentado durante el desarrollo del proyecto.
p ág . 2 7 2
6.1 Producto final
El producto final consta de una propuesta económica de la implementación del nuevo sistema de
denuncia policial a nivel nacional. Este proyecto está basado en la metodología EUP que está
conformada por las siguientes disciplinas Enterprise Business Modeling, Portafolio Managment y
Enterpirse Architecture.
Para el desarrollo de la Arquitectura Empresarial del SIDPOL se ha tenido que desarrollar las
cuatro Arquitectura que la conforman: Arquitectura de Negocios basada en la disciplina del EBM,
Arquitectura de Aplicaciones basándonos en la mejora de los servicios por terceros, negocio,
aplicación y técnicos, Arquitectura de Datos se ha realizado la toma de datos posible y realizar el
modelado de datos para el sistema y por último la Arquitectura Tecnología en lo cual nos hemos
basado en el diseño de la infraestructura tecnológica que actualmente cuenta.
Finalmente, para la validación de los entregables ha pasado por la revisión de la empresa Quality
Service para poder realizar la presentación final la cual consiste en un modelo funcional de la
propuesta del nuevo SIDPOL.
p ág . 2 7 3
Plan de gestión del riesgo - (Matriz de riesgos)
Plan de gestión de personal - (Matriz de RAM)
Matriz de comunicaciones
Aprobación de Plan de gestión de comunicaciones
los planes de
Semana 02-06 Diccionario
Planificación gestión de del EDT
Información de la Empresa
Diagrama de objetivos
Diagrama organizacional
Presentación
parcial de la Semana 07-12 Mapa de Procesos
Justificación de Procesos y objetivos
disciplina EBM
Stakeholders
Modelo de Dominio
Entrega de
certificado de Semana 15 Certificado de Plan de Gestión - EBM
QS
Procesos de Denuncia
Ejecución
Reglas de Negocio
Presentación
Mapeo de Actor - Proceso
final de la Semana 16-20
Mapeo de Entidad - Proceso
disciplina EBM
Matriz RAM
Descomposición Funcional
p ág . 2 7 4
Portafolio de Proyecto
Diagrama de Paquetes
Presentación y
Malla relacional
aprobación de
Semana 21-24 Mapeo Proceso de negocio - Producto
la disciplina
Tablero de Aplicaciones
PM
Estimación de Esfuerzo
Cuadro de control de proyectos
Aprobación de
la arquitectura
de Negocios Acta de reunión sobre la Arquitectura de
Semana 25
por parte del Negocio
cliente de la
DIRINFOR
Especificación de Servicios
Servicios de Aplicación
Aprobación de
Servicios de Negocio
la Arquitectura
Semana 26-29
de Servicio Técnicos
Aplicaciones Portafolio De Servicios
Servicios Terceros
Navegabilidad
Control de accesos
Interfaz de Usuario – ICUPS
Modelo Lógico
Diagrama de Componentes
p ág . 2 7 5
Diagrama de Despliegue
Diagrama de Red
Control
Entrega de
Certificado de Semana 33 Certificado de Arquitectura de Negocios,
QS Aplicación, Datos y Tecnológico
Presentación de
Paper al Semana 33 Constancia de aprobación
congreso
Cierre
Presentación y
Sustentación de
Semana 34 Memoria
la Memoria de
Proyecto Final
A continuación, se muestra las curvas de los avances reales y planificados de los entregables
realizados durante el periodo del proyecto. En cada ilustración mostrada a continuación se tiene
dos curvas las cuales han sido marcadas de diferente color mostrando los avances Planificados
versus lo que realmente ha sucedido semana a semana.
p ág . 2 7 6
Ilustración 87 – Reuniones Profesor Gerente 2015-01
Comentarios:
Las reuniones con el profesor gerente en el 2015-01 tuvo una diferencia entre el planificado con el
real, debido a que inicialmente, no se concretó el alcance del proyecto, por lo que se tuvo que
asistir a reuniones constante con el cliente externo y el profesor cliente.
p ág . 2 7 7
Ilustración 88- Reuniones Profesor Cliente 2016-01
Comentarios:
Debido a las reuniones con el cliente externo y las visitas constantes a la comisaria, las reuniones
con el Profesor cliente en las primeras semanas fueron pocas.
p ág . 2 7 8
Ilustración 89 – Reuniones Profesor Gerente 2016-01
Comentarios: Se asistió a todas las reuniones planificadas por el profesor gerente en este ciclo.
p ág . 2 7 9
Ilustración 90 – Reuniones Profesor Cliente 2016-01
Comentarios: Se asistió sin falta a todas las reuniones planificadas por el profesor cliente. De
manera presencial y virtual
p ág . 2 8 0
Porcentaje de avance del proyecto 2015-01
100.00%
100.00%
88.71%
90.00%
78.10% 94.13%
80.00%
67.72% 83.30%
70.00%
57.79% 73.14%
% de avance
60.00%
48.98% 63.21%
50.00% 41.31% 53.72%
40.00% 34.09%
45.37%
27.54%
30.00% 21.22% 38.15%
15.35% 31.38%
20.00% 10.61% 25.28%
6.55% 19.41%
10.00% 0.90% 2.93% 14.00%
0.00% 9.71%
6.09%
0.90% 2.93%
Semanas
Planificado Real
Comentarios: El porcentaje de avance en el ciclo 2015-01 tuvo una ligera diferencia debido a que
en las primeras reuniones aún no se definía el alcance del proyecto, por lo que minimizó el tiempo
para elaborar los entregables.
p ág . 2 8 1
Ilustración 92 – Avance del proyecto 2016-01
Comentarios: Debido a que en el ciclo 2016-1 se consideró adicionar algunos entregable, hubo un
desfase de tiempo en el proyecto.
• Jefe de proyecto: Este rol ha sido compartido por dos alumnos del curso de Taller de Proyecto,
Christian Huanambal Torres y Joaquín Cervantes.
p ág . 2 8 2
• Recurso de Apoyo: Este rol ha sido compartido por el alumno del Curso de Taller de
Desempeño de Proyecto, Henry Paullet.
Para el desarrollo del proyecto se tuvo que entregar el cronograma a los recursos de apoyo para
que puedan entregar las tareas asignadas en las fechas correspondientes y de esta manera evitar
que suceda imprevisto con los tiempos de los recursos. El cronograma sirvió para que los recursos
tomen sus medidas de precaución y puedan cumplir con el proyecto. Asimismo, los recursos
fueron asignamos por la empresa virtual Quality Services que se encarga de supervisar la calidad
de los entregables del proyecto y la empresa virtual IT-Consulting que se encarga de gestionar
diversos proyectos.
• Registro de Interesados.
p ág . 2 8 3
6.4.2 Procedimiento para la resolución de polémicas
Código de Acciones de
Descripción Involucrados Criticidad Responsable Fecha Resultado
Polémica Solución
Se presentaron
problemas Se realizó una
Cnel. Luis
para definir el reunión de
Chávez
alcance del inmediato con Christian
Retamozo
CP001 proyecto tanto Media los Huanambal 01-04-2015 Exitoso
por parte del involucrados Torres
Cliente – Edgar
cliente y la para definir el
Díaz
empresa alcance
asociada.
- Luis Chávez (cliente): Que se cumplan sus necesidades como cliente en base a los
objetivos del proyecto planteados.
p ág . 2 8 4
6.5.2 Seguimiento y Control de Riesgos
Los miembros del proyecto se comprometen con las actividades listadas que se presentan a
continuación:
- Los miembros del proyecto están obligados a realizar un constante seguimiento a los
riesgos que se han identificado que impactan en el desarrollo del proyecto.
- Los Jefe de Proyecto, tienen por responsabilidad, actuar de manera inmediata si algún
riesgo se activa y revisar así el Excel del registro de riesgos del proyecto.
- Para controlar el riesgo, se deben tener registradas las medidas preventivas y actualizarlas
si e cuentan con más acciones específicas para no retrasar el avance del proyecto.
- Se debe dar seguimiento a los controles identificados para mitigar el impacto del riesgo.
- Los jefes del proyecto tienen el deber de supervisar de manera continua los riesgos
identificados.
p ág . 2 8 5
6.6 Lecciones aprendidas
- Se debe manejar un alcance bien definido al inicio del proyecto y se debe procurar no
hacerle mayores cambios para que el desarrollo y el tiempo planificado para el proyecto
no varíe.
- El framework Zachman es un conjunto de buenas prácticas que puede ser aplicado a una
entidad pública como la Policía Nacional del Perú.
- Como parte del desarrollo del proyecto es de suma importancia realizar reuniones con el
profesor cliente y cliente de la empresa a trabajar una vez por semana de esta forma
aseguras un avance del proyecto alineado a los requerimientos planteados y se resuelva las
dudas cada vez que se presenten.
- En conjunto con el cliente profesor se ha revisado de manera concurrente los riesgos que
pueda presentarse durante el desarrollo del proyecto aplicando y evidenciando los planes
de mitigación y así evitar que estos riesgos se presentaran en la etapa final del proyecto.
- Una lección que se ha aprendido es en tener definidos desde un inicio los objetivos del
proyecto, lo cual implicó trabajar y definirlo con el apoyo de uno de los integrantes del
comité y el profesor cliente, dando como resultado un correcto inicio de desarrollo del
proyecto.
p ág . 2 8 6
Conclusiones
• Se elaboró un diagrama de red que facilita las interacciones de los 135 componentes
identificados en la Arquitectura Tecnológica.
p ág . 2 8 7
Recomendaciones
• Se deberá tener un mejor control del tiempo del proyecto, para no tener inconvenientes con los
objetivos propuestos ni con el alcance del proyecto.
• Se deberá velar por un equipo de proyecto que realice sus actividades de manera organizada y
sin contratiempos.
• Se deberá tener una comunicación constante con la empresa durante todo el proceso de
recolección de información, realizar los controles de cambios con anticipación antes de pasar a
la fase de implementación.
• Durante la fase de implementación, la DIRINFOR-PNP. deberá brindar todo el apoyo que sea
necesario hacia las personas encargadas del proyecto a implementar.
• Realizar una investigación respecto a las metodologías y marcos de trabajo que se ajusten a las
necesidades de la empresa en estudio, considerando el alcance, tiempo y recursos con los que
se cuenten.
• Revisar y validar la estimación de tiempo para la construcción de cada uno de los casos de uso
por desarrollar, y con ello, las actividades tendrán una holgura de tiempo ante cualquier
eventualidad que se presente durante el desarrollo del proyecto.
• Promover mayor participación de los recursos de la empresa virtual QA para que estos
conozcan acerca del proyecto y facilite sus labores sobre validación.
• Realizar un estudio respecto a los recursos tecnológicos que existen en el mercado, con el fin
de identificar y adquirir aquellos recursos que se adecúen a las necesidades del cliente.
p ág . 2 8 8
Glosario
Arquitectura de datos: Arquitectura conformada por los datos que se manejan en la empresa y
son parte fundamental de ella.
p ág . 2 8 9
E
EBM: Disciplina del EUP cuyo objetivo principal es el modelamiento empresarial del negocio.
Entidad: Objetos que representan a la organización en una estructura de la base de datos, los
cuales tienen datos respetivos.
Metodología: Conjunto de procedimientos que se sigue a fin realizar las acciones propias de una
investigación.
Proyecto: Es un esfuerzo que se genera bajo diversos recursos de inicio y fin, con un conjunto de
actividades.
p ág . 2 9 0
Programa: Es un conjunto de proyectos.
PM: Reúne todos los proyectos de TI, agrupados en programas, de manera que estos se
encuentren integrados y alineados a los objetivos estratégicos de la empresa.
PMBOK: Es una guía elaborada para la dirección de proyectos basada en las buenas prácticas
generalmente aceptadas y experimentadas.
Requerimiento Técnico: Es una necesidad a nivel de software, estas pueden ser funcionales y no
funcionales.
p ág . 2 9 1
RUP: Es una metodología de desarrollo de software adaptables al contexto y necesidades de cada
organización.
Servidor: Es un nodo que forma parte de una red, del cual ayuda a brindar información al
negocio.
p ág . 2 9 2
Siglario
p ág . 2 9 3
RAM (Responsibility Assigment Matrix): Matriz de Asignación de Responsabilidades
p ág . 2 9 4
Bibliografía
p ág . 2 9 5
Anexo 1: Acta de compromiso de confidencialidad
p ág . 2 9 6
Anexo 2: Certificado de aprobación por parte de la empresa
virtual Quality Service
p ág . 2 9 7
Anexo 3: Documentos del ciclo 2015-01
p ág . 2 9 8
p ág . 2 9 9
p ág . 3 0 0
p ág . 3 0 1
p ág . 3 0 2
p ág . 3 0 3
p ág . 3 0 4
p ág . 3 0 5
p ág . 3 0 6
p ág . 3 0 7
p ág . 3 0 8
p ág . 3 0 9
p ág . 3 1 0
p ág . 3 1 1
p ág . 3 1 2
p ág . 3 1 3
p ág . 3 1 4
p ág . 3 1 5
p ág . 3 1 6
p ág . 3 1 7
p ág . 3 1 8
p ág . 3 1 9
p ág . 3 2 0
p ág . 3 2 1
p ág . 3 2 2
p ág . 3 2 3
p ág . 3 2 4
p ág . 3 2 5
p ág . 3 2 6
Anexo 4: Documentos del ciclo 2016-01
p ág . 3 2 7
p ág . 3 2 8
p ág . 3 2 9
p ág . 3 3 0
p ág . 3 3 1
p ág . 3 3 2
p ág . 3 3 3
p ág . 3 3 4
p ág . 3 3 5
p ág . 3 3 6
p ág . 3 3 7
p ág . 3 3 8
p ág . 3 3 9
p ág . 3 4 0
p ág . 3 4 1
p ág . 3 4 2
p ág . 3 4 3
p ág . 3 4 4
p ág . 3 4 5
p ág . 3 4 6
p ág . 3 4 7
p ág . 3 4 8
p ág . 3 4 9
p ág . 3 5 0
p ág . 3 5 1
p ág . 3 5 2
p ág . 3 5 3
p ág . 3 5 4
p ág . 3 5 5
p ág . 3 5 6
Anexo 5: Clasificador único de denuncias y ocurrencias
TIPO SUB TIPO MODALIDAD
DENUNCIAS ESPECIALES PERDIDA DE DOCUMENTO PERDIDA DE DOCUMENTO
PERDIDA DE ESPECIES
CONSTATACION POLICIAL
EFECTUADA CONSTATACION POLICIAL EFECTUADA
p ág . 3 5 7
APOYO PRESTADO APOYO PRESTADO
OPERATIVO GIGANTE
OPERATIVO IMPACTO
OPERATIVO OTROS
p ág . 3 5 8
MENOR EXTRAVIADO MENOR EXTRAVIADO (DESAPARECIDO)
MUERTE REPENTINA MUERTE REPENTINA
PERSONA EXTRAVIADA PERSONA EXTRAVIADA
p ág . 3 5 9
MUERTE POR EXPLOSION MUERTE POR EXPLOSION
MUERTE POR OBJETO PUNZO
CORTANTE MUERTE POR OBJETO PUNZO CORTANTE
USURPACION USURPACION
APROPIACION ILICITA APROPIACION DE PRENDA
APROPIACION ILICITA COMUN
APROPIACION IRREGULAR
SUSTRACCION DE BIEN PROPIO
EXTORSION CHANTAJE
EXTORSION SIMPLE
DELITOS INFORMATICOS DELITO INFORMATICO
RECEPTACION RECEPTACION
HURTO FRUSTRADO DE GANADO
ROBO DE GANADO
DAÑOS DAÑO SIMPLE
p ág . 3 6 0
CHOQUE CON DAÑOS MATERIALES
CHOQUE CON DAÑOS MATERIALES Y
LESIONES
CHOQUE FRONTAL
CHOQUE LATERAL
CHOQUE MULTIPLE
CHOQUE POR ALCANCE
CHOQUE POR EMBISTE
CHOQUE POR RASPADA
CHOQUE SEGUIDO DE INCENDIO
CHOQUE Y FUGA
ATROPELLO ATROPELLO
ATROPELLO FATAL
ATROPELLO SEGUIDO DE CHOQUE
ATROPELLO Y FUGA
DESPISTE DESPISTE
DESPISTE CON ATROPELLO FATAL
DESPISTE CON DAÑOS MATERIALES
DESPISTE CON LESIONES
DESPISTE SEGUIDO DE ATROPELLO
CAIDA DE PASAJEROS CAIDA DE PASAJEROS
CAIDA DE PASAJEROS CON ATROPELLO
CAIDA DE PASAJEROS CON ATROPELLO
FATAL
ESPECIALES ESPECIALES
VOLCADURA VOLCADURA CAMPANA
VOLCADURA CON DAÑOS MATERIALES
VOLCADURA CON LESIONES
VOLCADURA CON RESULTADO FATAL
VOLCADURA CON RESULTADO FATAL Y
LESIONES
VOLCADURA SEGUIDA DE CHOQUE
VOLCADURA TONEL
INCENDIO INCENDIO
INCENDIO CON LESIONES
INCENDIO CON MUERTE
CONSUMIR ALIMENTOS SABIENDO QUE NO
FALTAS FALTAS CONTRA EL PATRIMONIO
PUEDE PAGAR
DAÑOS MATERIALES
FALTAS CONTRA EL PATRIMONIO
HURTO SIMPLE
p ág . 3 6 1
LESIONES
MALTRATO SIN LESION
FALTAS CONTRA LA TRANQUILIDAD FALTAS CONTRA LA TRANQUILIDAD
PUBLICA PUBLICA
FALTAS CONTRA LAS BUENAS FALTAS CONTRA LAS BUENAS
COSTUMBRES COSTUMBRES
FALTAS CONTRA LA SEGURIDAD
PUBLICA FALTAS CONTRA LA SEGURIDAD PUBLICA
LEY DE PROTECCIÓN FRENTE A
VIOLENCIA FAMILIAR VIOLENCIA FAMILIAR (LEY 26260 AMENAZA GRAVE
25/06/97)
COACCION GRAVE
DAÑO FISICO
DAÑO FISICO Y PSICOLOGICO
DAÑO PSICOLOGICO
MALTRATO SIN LESION
REGLAMENTO NACIONAL
DE TRANSITO (D.S Nº 016, GRAVES G1
025 Y 029-2009-MTC)
G10
G11
G12
G13
G14
G16
G17
G18
G19
G20
G21
G24
G25
G27
G28
G29
G3
G30
G31
G33
G38
G4
G40
G47
G48
G5
p ág . 3 6 2
G54
G56
G57
G58
G59
G60
G61
G63
G64
G66
G8
MUY GRAVES M1
M11
M13
M14
M16
M17
M18
M19
M2
M21
M22
M24
M25
M26
M27
M28
M3
M30
M31
M35
M4
M5
M6
M8
LEVES L1
L4
L5
L7
p ág . 3 6 3
FABRICACION, SUMINISTRO O TENENCIA
DE MATERIALES PELIGROSOS (ARMAS,
EXPLOSIVOS)
PELIGRO POR MEDIO DE INCENDIO O
EXPLOSION
SUSTRACCION O ARREBATO DE ARMAS DE
FUEGO EN GENERAL
ADULTERACION DE SUSTANCIAS O BIENES
SALUD PUBLICA DESTINADOS A USO PUBLICO
COACCION AL CONSUMO DE DROGA
COMERCIALIZACION O TRAFICO DE
PRODUCTOS NOCIVOS
CONTAMINACION DE AGUAS O
SUSTANCIAS DESTINADAS AL CONSUMO
EJERCICIO ILEGAL DE LA MEDICINA
INDUCCION O INSTIGACION AL CONSUMO
DE DROGA
MICROCOMERCIALIZACION DE DROGAS
POSESION NO PUNIBLE
PROMOCION O FAVORECIMIENTO AL
TRAFICO ILICITO DE DROGAS
PROPAGACION DE ENFERMEDAD
PELIGROSA O CONTAGIOSA
TRAFICO ILICITO DE DROGAS
TRAFICO ILICITO DE INSUMOS QUIMICOS Y
PRODUCTOS
USO DE PRODUCTOS TOXICOS O
PELIGROSOS
VENTA DE MEDICINAS ADULTERADAS
MEDIOS DE TRANSPORTE, ATENTADO CONTRA LOS MEDIOS DE
COMUNICACIONES Y OTROS TRANSPORTE COLECTIVO O DE
SERVICIOS PUBLICOS COMUNICACION
ATENTADO SOBRE LA SEGURIDAD COMUN
VIDA, EL CUERPO Y LA
LESIONES LESIONES
SALUD (DELITO)
LESIONES CULPOSAS
LESIONES GRAVES
LESIONES LEVES
LESIONES LEVES POR VIOLENCIA FAMILIAR
LESIONES PRETERINTENCIONALES CON
RESULTADO FORTUITO
HOMICIDIO FEMINICIDIO
HOMICIDIO CALIFICADO - ASESINATO
HOMICIDIO CULPOSO
HOMICIDIO POR PAF
HOMICIDIO SIMPLE
PARRICIDIO
TENTATIVA
ABORTO ABORTO CON MUERTE SUBITA
p ág . 3 6 4
ABORTO CONSENTIDO
ABORTO PRETERINTENCIONAL
ABORTO SENTIMENTAL
ABORTO SIN CONSENTIMIENTO
ABORTO TERAPEUTICO
AUTOABORTO
TENTATIVA
EXPOSICION A PELIGRO O
ABANDONO DE PERSONAS EN EXPOSICION O ABANDONO PELIGROSO
PELIGRO
OMISION DE AUXILIO O AVISO A
AUTORIDAD
OMISION DE SOCORRO Y EXPOSICI0N A
PELIGRO
p ág . 3 6 5
OFENSAS AL PUDOR PUBLICO EXHIBICIONES Y PUBLICACIONES OBSENAS
PORNOGRAFIA INFANTIL
VIOLACION DE LA LIBERTAD DE
VIOLACION DE LA LIBERTAD DE EXPRESION
EXPRESION
VIOLACION DE LA LIBERTAD DE
REUNION PERTURBACION DE REUNION PUBLICA
ABUSO DE AUTORIDAD
ABUSO DE AUTORIDAD CONDICIONANDO
ILEGALMENTE LA ENTREGA DE BIENES Y
SERVICIOS
COBRO INDEBIDO
COHECHO ACTIVO GENERICO
COHECHO PASIVO ESPECIFICO
CONCUSION
CORRUPCION ACTIVA DE FUNCIONARIO
DENEGACION O DEFICIENTE APOYO
POLICIAL
OMISION, REHUSAMIENTO O DEMORA DE
ACTOS FUNCIONALES
EJERCICIO ARBITRARIO DE DERECHO
ADMINISTRACION DE JUSTICIA (JUSTICIA POR PROPIA MANO
EVASION MEDIANTE VIOLENCIA
FAVORECIMIENTO A LA FUGA
FUGA EN ACCIDENTE DE TRANSITO
OBSTRUCCION DE LA JUSTICIA
OMISION DE DENUNCIA
p ág . 3 6 6
DISTRIBUIR DROGA EN PEQUEÑA
CANTIDAD DIRECTO A CONSUMO
DISTRIBUIR DROGA EN PEQUEÑAS
CANTIDADES O A CONSUMO INDIVIDUAL
ESCASA CANTIDAD DE DROGA, MATERIA
PRIMA PARA FABRICACION O AFIN
PROMOVER, ETC. GRUPO DE PERSONAS
DEDICADAS AL TID EN PAIS EXTRANJERO.
TID COMETIDO EN BANDA O EN CALIDAD
DE AFILIADO A BANDA
TID COMETIDO EN INTERIOR DE ESCUELA,
ESTABLECIMIENTO DE SALUD, ETC.
ATENTADOS CONTRA LA PATRIA
INDUCCION A LA FUGA DE MENOR
FAMILIA (DELITO) POTESTAD
INSTIGACION O PARTICIPACION DE MENOR
EN PANDILLAJE PERNICIOSO
SUSTRACCION DE MENOR
ABANDONO DE MUJER GESTANTE Y EN
OMISION DE ASISTENCIA FAMILIAR
SITUACION CRITICA
OMISION DE PRESTACION DE ALIMENTOS
MENOR INFRACTOR DE LA MENOR INFRACTOR DE LA LEY
MENOR INFRACTOR DE LA LEY PENAL
LEY PENAL PENAL
p ág . 3 6 7
ARROJAR OBJETOS EN VIA PUBLICA QUE
AFECTEN LIBRE TRANSITO O CAUSEN
DAÑOS MINIMOS
CONDUCTOR O COBRADOR DE TRANSP. DE
SERV. PUBLICO QUE FALTA RESPETO A LOS
PASAJEROS
EXHIBIR INDEBIDAMENTE ARMA DE FUEGO
EN LUGAR PUBLICO
MODIFICAR, REMOVER, ETC. SEÑAL DE
TRANSITO O COLOCAR LETREROS U OTROS
TRANQUILIDAD PUBLICA
(DELITO) CONTRA LA HUMANIDAD DESAPARICION COMPROBADA
DISCRIMINACION
DELITOS DE INTERMEDIACION ONEROSA
PAZ PUBLICA DE ORGANOS Y TEJIDOS
DISTURBIOS
DISTURBIOS AGRAVADA
ADOLESCENTE INFRACTOR ATENTAR CONTRA LA VIDA DE LAS
DE LA LEY PENAL PANDILLAJE PERNICIOSO PERSONAS
CAUSAR LESIONES GRAVES EN PERSONAS
(INFRACCION AGRAVADA)
LESIONAR LA INTEGRIDAD FISICA DE LAS
PERSONAS
VIOLACION DE MENORES DE EDAD
OTROS JUDICIAL JUDICIAL
ADMINISTRATIVO ADMINISTRATIVO
PROCESO INVESTIGATORIO PROCESO INVESTIGATORIO
DEUDA DEUDA
LEY ORGANICA DE ELECCIONES (LEY NO EXIGIR DNI CON CONSTANCIA DE
VOLUNTAD POPULAR 26859 01/10/97) SUFRAGIO POR NOTARIO O AFIN
HUMANIDAD (DELITO) CONTRA LA HUMANIDAD DESAPARICION FORZADA
PENALIDAD PARA DELITOS DE CAUSAR DAÑOS EN BIENES PUBLICOS O
TERRORISMO TERRORISMO (D.LEY 25475 PRIVADOS
p ág . 3 6 8
CONFIANZA Y LA BUENA FE
LIBRAMIENTOS INDEBIDOS LIBRAMIENTOS INDEBIDOS
EN LOS NEGOCIOS (DELITO)
DELITOS TRIBUTARIOS DELITOS TRIBUTARIOS PRUEBA DELITOS TRIBUTARIOS PRUEBA
LEY PENAL TRIBUTARIA (DEG. 813
20/04/96) DEFRAUDACION TRIBUTARIA
ORDEN ECONOMICO ABUSO DEL PODER ECONOMICO ABUSO DEL PODER ECONOMICO
(DELITO)
PATRIMONIO CULTURAL DESTRUIR, ALTERAR, EXTRAER BIENES
BIENES CULTURALES
(DELITO) CULTURALES
p ág . 3 6 9