Año

2010
PROYECTO

Sistema Integrado para la

Gestión del Armamento y
Munición Policial
SIGAMPOL
INTRODUCCION

El presente documento constituye el Proyecto del Sistema Integrado para la Gestión del
Armamento y Munición Policial (SIGAMPOL), a ser implementado en el año 2010. El
documento contiene el Plan General del Proyecto, con información de organización,
administración, logística, información técnica, metodología, estándares y arquitectura, y
constituye la guía base principal a seguir durante el desarrollo del proyecto.

OBJETIVO DEL NUEVO SISTEMA

El objetivo del nuevo Sistema Integrado para la Gestión del Armamento y Munición Policial es
el de integrar la información a nivel nacional, dar confiabilidad de información, rapidez de
atención y unidad de criterios en el manejo de la información.

ESTRATEGIA

El nuevo Sistema integrará la información referida al armamento y munición de la PNP que

obra en las Unidades y Subunidades a Nivel Nacional, teniendo como sede principal en Lima la
División de Armamento y Munición de la PNP, contemplando un diseño con visión global, que
permitirá establecer procedimientos estándares y herramientas similares. Asimismo,
posibilitará la consolidación automatizada de la información a nivel nacional, mediante
procedimientos informáticos, eliminando la manipulación de los datos con herramientas
externas al sistema, dando mayor seguridad y confiabilidad en el manejo de la información.

BENEFICIOS

Producto de la implementación y utilización del nuevo Sistema Integrado, se alcanzarán los

siguientes beneficios:
 Integración de Información.
 Rapidez de atención.
 Eliminar e impedir la existencia de información NO CONFIABLE, con datos digitados
erróneamente, datos faltantes, información redundante, registros duplicados, datos
migrados sin consistencia, datos irreales y datos incompletos.
 Estandarización de base de datos y de aplicaciones.
 Unificación de criterios entre las áreas en cuanto al manejo de la información.
 Consolidación de datos a nivel nacional.
 Descongestionamiento de la División de Armamento y Munición de la PNP.
 Mayor control del armamento y munición de la PNP en las diferentes Unidades y
Subunidades a Nivel Nacional.
 Eliminación del descontento del personal al tener mejores herramientas informáticas.
 Disposición de información en línea, lo que facilitará las decisiones a tiempo.
 Posibilidad de exponer la información a través de Internet mediante nuevos servicios
orientados a las mismas Unidades y Subunidades PNP, al Comando Institucional y al
ente rector de dicha información, la División de Armamento y Munición de la PNP.

La implementación del Proyecto del Sistema Integrado para la Gestión del Armamento y
Munición Policial debe ser un compromiso conjunto de los integrantes designados de la
Dirección de Telemática y los integrantes de la División de Armamento y Munición de la PNP,
así como un paso fundamental de la Institución en el camino de la modernidad, mejorando los
servicios en beneficio de los ciudadanos en todo el Perú, y contribuyendo valiosamente con la
construcción de una sociedad moderna, integrada y globalizada.

1
1. MODELAMIENTO DE LA SOLUCIÓN

Contenido de Módulos
 Gestión de armamento policial (contempla el registro, modificación, eliminación,
consulta).
 Gestión de la munición policial (contempla el registro, modificación, eliminación,
consulta).
 Gestión de asignación del armamento y munición policial en cada Unidad Policial a
Nivel Nacional (contempla el registro de movimientos entre unidades, asignaciones
al personal policial).
 Gestión de Lista de Revista del armamento y munición policial a Nivel Nacional
(contempla el registro de cambios de estado operativo, inoperativo, de baja).
 Gestión de Cuadros Estadísticos conforme a las necesidades actuales en tiempo real.
 Gestión de Reportes conforme a las necesidades actuales en tiempo real.

2. GENERACIÓN DE ARQUITECTURA DE SOLUCIÓN DE TRABAJO

2.1 COMPONENTES DE LA SOLUCION

 El desarrollo de la solución estará basado en tecnología .NET.
 La capa de presentación del portal será desarrollada con ASP.NET.
 La capa de acceso a datos será desarrollada con Microsoft Visual Basic .NET 2008.
 El servidor de base de datos será Microsoft SQL Server 2008.
 Así mismo, se desarrollarán Web Services para exponer determinadas
funcionalidades de los distintos módulos que conformarán el portal, así como para
enviar y recibir información con los demás sistemas, a través de XML.

2.2 ARQUITECTURA DE LA SOLUCIÓN

La arquitectura física de la solución se ve a continuación:

Además, al emplear Web Services:

 Hace posible el acceder, desde cualquier cliente, sistema operativo o dispositivo a la

información:

2
  Debido a lo anteriormente expuesto, los Web Services pueden interactuar con
diversas tecnologías y/o servicios. Es así que los clientes podrán acceder a los
servicios mediante protocolo SOAP sin importar el sistema operativo, a su vez los
clientes podrán recuperar la descripción de los servicios mediante el estándar WSDL
el cual describe los métodos disponibles de los servicios web, y el cliente también
interactúa con Directorio de Web Services (UDDI) que se encuentran disponibles,
este directorio contiene información acerca de los Web Services, como su ubicación,
capacidades entre otros.

3. CAPAS DE IMPLEMENTACIÓN

La aplicación será desarrollada en 4 capas:

 Capa de Interfaz de usuario,
 Capa de Lógica del Negocio,
 Capa de Acceso a Datos y
 Capa de Seguridad.

En la Capa de Interfaz de usuario, se subdividen en dos sub-capas, una encargada del

manejo HTML que es entregado a los navegadores del cliente (IExplorer, Netscape,
FireFox, Crome, etc), y otra sub-capa encargada del manejo de Servicios Web, usando
SOAP como protocolo de comunicación y XML como medio de transferencia de datos (ya
mostrados en la arquitectura del sistema). Estos servicios Web, interactúan con las
diferentes capas del sistema, interfaces HTML y puede interactuar con otras aplicaciones
que estén registradas (Aplication to Aplication).

En la Capa de Lógica del Negocio, encontramos las diferentes entidades y reglas del
negocio necesarias para la aplicación. Estas serán expuestas por los servicios Web.

3
En la Capa de Acceso a Datos, encontramos los diferentes componentes para acceder al
SGBD en este caso es el Microsoft SQL Server 2008; para esto se implementara una
factoría de clases que permitan crear posteriormente otros componentes que interactúen
con otros SGBD como por ejemplo ORACLE sin necesidad de mayores cambios.

En la Capa de Seguridad, se tendrán interfaces (Web Services) que permitan autenticar

tanto usuarios como aplicaciones permitidas y así estas puedan utilizar los diferentes
funcionalidades de los servicios Web.

Finalmente la interacción entre clientes (mediante web browsers), aplicativos (mediante

SOAP) y el sistema al desarrollar será como se ve a continuación:

4
4. LENGUAJE Y HERRAMIENTAS

a. Visual Studio .NET Team System

Visual Studio .NET proporciona a los programadores la herramienta más productiva
para generar aplicaciones de próxima generación para Microsoft Windows® y el
Web. Incluye funciones adicionales para diseñar, especificar y comunicar
arquitectura y funcionalidad de aplicaciones. Permite a los arquitectos de software y
a los programadores veteranos proporcionar una orientación y compartir las
mejores prácticas con el equipo de programación.

b. Diseño visual de aplicaciones y servicios Web XML

Visual Studio .NET Enterprise Architect proporciona compatibilidad total para el modelado de
bases de datos, incluidas vistas conceptuales, lógicas y físicas Crear y proporcionar una guía
de arquitectura

c. Generar aplicaciones y servicios Web XML

Visual Studio .NET es la referencia del sector para la productividad de los
programadores. Como plataforma de programación más actual, incluye diseñadores
visuales para Windows, el Web, datos y componentes basados en un servidor para
llevar a cabo las tareas del modo más eficaz. Basado en Microsoft .NET Framework,
Visual Studio .NET permite la creación y el uso sin problemas de servicios Web XML
para construir la Internet de la próxima generación.
d. Utilizar una plataforma de herramientas abierta
Visual Studio .NET proporciona una arquitectura abierta y ampliable que permite
integrar sin problemas herramientas, componentes y lenguajes de otros fabricantes
en el ambiente, proporcionando así a los programadores una amplia gama de
opciones para satisfacer requisitos empresariales.
e. Base de datos: Microsoft SQL Server 2008
Su funcionalidad se ajusta a las necesidades de este proyecto, además de ser un
estándar de facto en el mercado.
Microsoft SQL Server 2008 es el gestor de base de datos y herramienta de análisis
diseñada para construir la próxima generación de aplicaciones de Business
Intelligence.
f. Servicios de Análisis Integrales

El objetivo de los Servicios de Análisis de Microsoft® SQL Server™ 2008, es aportar

una plataforma exhaustiva para el análisis, que incluya características OLAP y data
mining.

Puede mezclar y comparar algoritmos y herramientas de Microsoft y de terceros

para personalizar aplicaciones de análisis.
Además, los Servicios de Análisis fueron planificados para administradores de base
de datos y desarrolladores de aplicaciones, más que para una audiencia élite de
expertos en estadísticas.

En la actualidad sin necesidad de tener una base sólida en Structured Query

Language (SQL) o en el sistema de desarrollo de Microsoft Visual Basic® .NET, un
usuario común debería ser capaz de comprender, utilizar y ampliar
programáticamente lo que los Servicios de Análisis ya ofrecen.

5
5. METODOLOGÍA DEL PROYECTO

5.1 ALCANCES DEL PROYECTO

Documento que describe lo que va a contemplar el sistema, punto por punto sin llegar a
descripciones detalladas

5.2 FASES DEL PROYECTO

Principales actividades y los entregables de cada una de las fases del modelo de
procesos de MSF:

Fase Actividades principales Entregable

Visión Definición de las expectativas Documento de

y alcance del proyecto Alcance
Desarrollo del documento de
alcance
Conformación de los grupos
de trabajo
Definición de las
responsabilidades de los
participantes

Planeación Definición de la especificación Especificación

funcional de la solución funcional
Definición del plan maestro Plan de trabajo
del proyecto detallado
Creación del calendario
general de actividades

Desarrollo Construcción de la solución de Componentes de la

acuerdo a la especificación solución
funcional Manuales
Definición de los Plan de pruebas
procedimientos de instalación
Desarrollo de los elementos
de educación a usuarios,
personal de soporte y
administración
Instalación de la
infraestructura
Pruebas Encontrar defectos Crear la estrategia de
Rastrear la causa y el efecto pruebas
Verificar que lo
construido se adapte
a las especificaciones
originales
Estabilización Pruebas de integración y Plan de arranque
compatibilidad de la solución Plan de contingencias
Pruebas de funcionalidad y de
estrés de la aplicación
Ajustes y afinación de la
infraestructura para lograr el

6
 rendimiento esperado

Implementación Liberación de la solución al Documentación

ambiente de producción técnica

5.3 EQUIPO DE TRABAJO SEGÚN MSF

El equipo de trabajo se organizará de acuerdo al modelo de equipos de MSF, dicho

modelo identifica los principales roles y responsabilidades para cada una de las etapas
del proyecto:

Principales habilidades y responsabilidades de cada rol:

Rol Enfocado a Habilidades Responsabilidades

Administración Satisfacción Buena Manejar las expectativas del

del Proyecto del Cliente
comunicación Cliente
Administrar Indicar las características de la
proyectos solución y las prioridades
Conocimiento del Realizar las entregas ejecutivas
negocio
Control del Seguimiento Administrar Administrar las especificaciones
Proyecto puntual del
proyectos Sincronizar calendarios de trabajo
proyecto
Conocer
Coordinar los equipos de trabajo
estándares de
sistemas Entregar el producto en tiempo
Identificar y
resolver
problemas críticos
Desarrollo Crear un Resolver problemas Diseñar las características
producto
confiable, Analizar, diseñar y Construir la funcionalidad de
robusto y a la programar acuerdo a las especificaciones
medida sistemas Estimar tiempos y esfuerzos
Conocimiento
técnico profundo
Pruebas Aseguramient Encontrar defectos Crear la estrategia de pruebas
o
de la calidad Rastrear la causa y Verificar que lo construido se

7
 el efecto adapte a las especificaciones
originales

Infraestructura Implantación Administrar Planear, administrar e implantar la

Y Logística no dolorosa y
proyectos infraestructura requerida
correcta
operación Conocimiento Brindar soporte técnico
técnico profundo Asegurar que la infraestructura
Experiencia en la adecuada esté en tiempo
escritura de
ambientes
operativos
Grupo usuario Satisfacción Conocimiento del Participar en la definición de los
del Usuario
negocio requerimientos de los usuarios
final
Carisma y Diseño de pruebas y capacitación
comunicación Diseño de la documentación
Escritura técnica

EQUIPO INTEGRANTES

Administración del proyecto Personal Policial designado por la Dirección de

Control del Proyecto Telemática de la PNP (DIRTEL-PNP).
Desarrolladores Diseño
Programación
Probadores
Infraestructura y Logística
Grupo Usuario

5.4 ADMINISTRACIÓN DE ALCANCE

Definir los requerimientos para asegurar que todos recursos y trabajo requerido sea
considerado para cumplir con los objetivos finales del proyecto. Su principal objetivo es
definir que está incluido y que no está en el alcance del proyecto.
 Definición de compromisos iniciales del proceso
 Definición de Alcances.
 Verificación de Alcances
 Control de Cambio

5.5 ADMINISTRACIÓN DE RIESGOS

 Análisis Inicial de que puede ir mal.

 Determinar riesgos de lo que se consideran importantes.

8
 ETAPAS DEL PROCESO DE ADMINISTRACION DE RIESGO

6. PERSONAL QUE INTERVIENE

LETRA PERSONA

A Personal Policial designado por la

B Dirección de Telemática de la PNP
C (DIRTEL-PNP).
D
E
F
G
H
I
J
K
L
M
N

9
7. ETAPAS Y ACTIVIDADES

Fase
Equivalente
Etapa del
Actividades Comprometidas Responsable en la
Proyecto
metodología
MSF
Organización a) Formación del equipo de trabajo,
distribución de competencias y A+B
responsabilidades.
b) Planificación de actividades a realizar. J+K
1. Levantamiento a) Entrega de software y licencias. A+B
y Análisis.
b) Levantamiento de procesos actuales. C+J+K+D
c) Levantamiento de Requerimientos del
C+J+K+D
Sistema.
d) Plan de trabajo de la etapa de diseño y J+K Visión
plan de construcción del prototipo.

e) Informe de estándares a ocupar (base

de datos, tablas, atributos, seguridad, J+E+D
codificación, otros.)
f) Informe de requerimiento de hardware
J+K+L
y software necesario para soportar el
sistema a desarrollar.
g) Revisión y Aprobación Etapa 1 A+B
2. Planeación a) Especificación de planes de manejo de Planeación
datos, plan de migración de datos
E+D+F+L
históricos, respaldo y recuperación de
datos.
3. Diseño de a) Definición y descripción detallada de Diseño
C+J+K+G
solución. sistemas.
b) Descripción funcional de sistemas y sus
G+J+K
respectivos módulos.
c) Modelo conceptual, diagramas y
J+K+G
descripción de la arquitectura.
d) Modelo de datos definitivos. D+G+J+K
e) Estructuras de datos. D+G+J+K
f) Especificaciones técnicas de sistemas,
G+H+J+K
módulos y aplicaciones.
g) Descripción de restricciones y
C+J+K+D+G
limitaciones del sistema.
h) Especificación de niveles de seguridad. I+F+J+E
i) Enlaces con otros sistemas. J+K+D
j) Trabajo con funciones y stored D+J+K+G
procedures existentes.
k) Descripción de perfiles de usuarios y
C+A+B+D+K
niveles de acceso a los sistemas.
l) Construcción prototipo. C+J+K+G+L
m) Revisión y Aprobación prototipo. A+B

10
 n) Diseño de la solución final. C+J+K+G+L
o) Aprobación del diseño de la solución. A+B
p) Especificación del plan de construcción. J+L
q) Diseño del plan de pruebas funcionales
para la etapa de desarrollo y de K
instalación de sistemas.
r) Diseño de la Web inicial a incorporar en
F+I
la Web.
s) Documentación técnica requerida. H
t) Revisión y Aprobación Etapa 2. A+B
3. Construcción a) Instalación de SW y configuración de Desarrollo
J+F
de sistema. equipos.
b) Construcción sistema. G+J+K+D+L
c) Construcción de formularios definidos. G+J+K+D+L
d) Construcción módulo reportes de
G+J+K+D+L
gestión.
e) Pruebas funcionales en etapa de Pruebas
G+J+K+D+L
construcción.
f) Contenido del plan de capacitación
para usuarios y Administradores de J+K+L+H
sistemas.
g) Plan de preparación e instalación de
F+I+J+K+L
sistemas.
h) Revisión y Aprobación Etapa 3. A+B
4. Marcha blanca a) Interconexión con sistemas internos y
E+F+I+M
con Clientes.
b) Migración, validación y normalización Estabilización
E+F+G
datos históricos.
c) Ejecución del plan de pruebas y
TODOS
marcha blanca.
C+G+J+K+D
d) Revisión para ajustes y mejoras.
+L
e) Capacitación de los módulos C+D+E+F+G
construidos. +H+J+K+L Implementaci
f) Entrega de Documentación del Sistema ón
H+N
construido.
g) Programas fuentes (bibliotecas,
H+N
rutinas, etc.).
h) Manuales de usuarios y administrador
H+N
en explotación.
J+D+K+I+E+
i) Instalación final de sistema.
F+L

j) Revisión y Aprobación Etapa 4. A+B

5. Mantenimiento. Soporte Post-

a) Término del proyecto. TODOS
Producción

a. Etapa 1 - Levantamiento de requerimientos.

11
 Durante esta etapa el equipo de desarrollo deberá realizar un detallado análisis de
procesos actuales relacionados con los procesos de la División de Armamento y
Munición de la PNP.

El equipo de desarrollo participará, en conjunto con grupo usuario, en entrevistas y

reuniones que permitan identificar los requerimientos del sistema. Con la
información obtenida propondrá las modificaciones, mejoras o correcciones que
estime.

Al finalizar esta actividad el equipo de desarrollo deberá entregar los resultados de

la etapa de análisis con al menos los siguientes productos esperados:

 Entrega de software y licencias.

 Levantamiento de procesos actuales.

 Levantamiento de requerimientos de sistemas.

 Informe de modo de interconexión de las Unidades y Sub unidades de la PNP a

nivel Nacional para la interacción con el Sistema Integrado para la Gestión del
Armamento y Munición Policial y el intercambio de información con los Sistema
de Personal de la Dirección de Recursos Humanos de la PNP (DIRREHUM-PNP).

 Modelo esquematizado de la solución diseñada, el cual permita ver claramente la

solución propuesta.

 Informe de requerimientos de hardware y software requeridos para el proyecto.

 Informe de estándares a aplicar durante todo el proyecto (metodología,

hardware, software, aplicaciones, base de datos, seguridad).

 Plan de trabajo para la construcción del prototipo y diseño de la solución que

indique plazos, etapas e hitos relevantes para su control y ejecución. La carta
Gantt presentada, debe estar basada en la carta Gantt original con las
correcciones correspondientes si proceden. Todas las cartas Gantt del proyecto,
deben considerar holguras necesarias para iterar al menos una vez en la
aprobación de cada una de las etapas. Las controles de avance serán
mensuales, esto implica que se deberán entregar documentos, productos o
cualquier comprometido aún cuando no se encuentren terminados.

Aceptación de la etapa.

Durante la ejecución de esta actividad, el personal de la Dirección de Telemática en

su conjunto revisará los levantamientos de procesos, diseños, informes y planes de
trabajo elaborados. Como resultado de lo anterior, se realizará las observaciones o
en caso contrario, la aprobación de la etapa. Esta actividad finalizada y aprobada
formalmente por el grupo de Administración del Proyecto, será prerrequisito para
continuar con la siguiente etapa.

b. Etapa 2 – Diseño de la solución.

Diseño de la solución.

En esta actividad el Equipo de Diseño del Grupo de Desarrollo deberá diseñar la

solución de acuerdo a los requerimientos definidos y aprobados.

12
Un aspecto relevante a considerar al momento del diseño será la utilización de
tecnologías livianas, que no recarguen innecesariamente a los usuarios con
aplicaciones, ejecutables o animaciones.

Al finalizar la etapa, el Equipo de Desarrollo entregará los documentos respectivos

con los siguientes productos:

 Especificaciones técnicas de la arquitectura de red que consideren

recomendaciones de adquisición o upgrade de infraestructura necesarios para la
correcta operación de los sistemas. Las modificaciones no deberán alterar
sustancialmente la arquitectura y plataforma existente a la fecha de
implementación del proyecto.

 Modelo de datos definitivos en caso de modificaciones, diagramas UML y otros.

Descripción de entidades y características de operación de ellos, diccionario de
datos.

 Especificaciones de las estructuras de datos que considere diccionario de datos,

dominio de datos, tablas, columnas, llaves, índices, objetos link u otras bases y
mapeo de entidades a tablas. El diseño se realizará respetando las normas y
estándares definidos en la etapa previa.

 Descripción de restricciones y limitaciones de los sistemas. Se debe describir

todo proceso o actividad que los sistemas no estén capacitados de realizar y que
puedan afectar su normal operación.

 Especificaciones de planes de manejo de datos, migración/carga de datos

históricos, respaldo y recuperación de datos, planes de contingencias.

 Especificaciones de niveles de seguridad, perfiles de usuarios, mecanismos de

autentificación y validación. Definir las tecnologías y dispositivos que permitan
garantizar que los datos, sistemas, ventanas y procesos, sean única y
exclusivamente accedidos por quienes tienen la autorización para hacerlo.

 Encriptación de datos u otros mecanismos de seguridad cuando sea necesario.

 Especificaciones del plan de construcción.

 Diseño del plan de pruebas funcionales para la etapa de desarrollo y de

instalación de sistemas.

 Diseño de página Web donde residirá la aplicación y su incorporación en la

página Web.

Aceptación del diseño.

En esta actividad, se presentará los diseños elaborados. Como resultado de ello, se

revisará y realizará, si corresponde, las modificaciones y observaciones a los diseños
y se los informará al personal de la Dirección de Telemática para que procedan a su
corrección. Una vez realizadas las modificaciones y si están ajustadas a lo solicitado,
se procederá a la aprobación del documento de diseño.

La documentación de modificaciones, observaciones y la aprobación se realizará

por escrito.

Construcción de prototipo.

13
 En esta actividad el equipo de desarrollo deberá elaborar el prototipo de la solución,
resultante del proceso de análisis, con el objeto de revisar el diseño de las páginas y
la navegación.

Al finalizar esta actividad el equipo de desarrollo entregará el siguiente producto:

 Prototipo de la solución. Los prototipos considerarán diseño de pantallas y

secuencia lógica de navegación, interfaz gráfica, estructura de menús,
estructura de ventanas, menús de ayuda, principales ventanas y formularios.

Aceptación de prototipo.

Durante la ejecución de esta actividad personal de la Dirección de Telemática

revisará el prototipo elaborado. Como resultado de ello, realizará las observaciones
al prototipo. Esta actividad, finalizada y aprobada por el grupo de Administración
del Proyecto, será prerrequisito para continuar con la siguiente actividad.

c. Etapa 3 – Construcción del sistema.

Construcción de sistemas.

Será responsabilidad del grupo de Administración del Proyecto y del Grupo de

Infraestructura y Logística dotar, preparar y reproducir un ambiente de desarrollo y
pruebas adecuados para la construcción de los sistemas, que permita verificar
codificación, datos, objetos, transferencia de datos, etc.

Como en todas las etapas del proceso, independiente de los hitos definidos como
entregables, se deben dejar disponibles mensualmente para revisión, todos los
borradores de documentos, aplicaciones generadas a la fecha y cualquier otro
producto definido.

Al finalizar la ejecución de esta actividad la Dirección de Telemática deberá haber

validado en conjunto con la División de Armamento y Munición de la PNP la
Estructura Organizativa y Funcional, todos los mecanismos, módulos y aplicaciones
construidos e implementados en el ambiente de desarrollo, evaluándose
funcionalidad y operación de cada una de las ventanas, formularios, procesos, etc.

Lo anterior implica la necesidad de capacitar al grupo de pruebas y contar con los

manuales de usuario y administrador.

Por tanto, al finalizar esta actividad se debe contar con los siguientes productos:

 Formularios, ventanas, menús, consultas, reportes, vistas, estructuras de datos,

procesos de datos y todo objeto o código fuente necesario para la correcta
operación, revisados y validados.

 Sistema construido de acuerdo a las especificaciones de diseño de la solución.

 Diseño del plan de pruebas funcionales para la etapa de puesta en producción.

 Entrega de informe y programa del plan de capacitación de usuario y

administrador de los sistemas.

14
  Tener al grupo de pruebas capacitado para realizar las funciones propias de la
etapa.

 Documentación del sistema desarrollado.

Pruebas internas funcionales y desempeño en ambiente de construcción.

Construidos los sistemas se aplicará un conjunto de pruebas funcionales que

permitan detectar posibles errores de codificación, previa a la etapa de instalación y
puesta en marcha de los sistemas y módulos. Las pruebas se realizarán en conjunto
con el personal de la División de Armamento y Munición de la PNP de cada sección
comprometida, de acuerdo al plan de pruebas solicitado en Diseño y Prototipo.

Será responsabilidad del personal de la Dirección de Telemática, corregir y reparar,

durante la ejecución de las pruebas funcionales, toda falla que implique corrección
de códigos, estructuras de base de datos, etc.

Modificaciones.

Si durante la fase de revisión y validación de la codificación se presentaran

diferencias respecto a las características de las interfaces, funcionalidades,
estructuras de datos con relación a las indicadas y establecidas en la actividad de
Diseño, será responsabilidad del Equipo de Desarrollo efectuar las modificaciones y
correcciones necesarias de acuerdo a las indicaciones.

Preparación e instalación de sistemas.

Se deberá preparar el ambiente de producción, considerando instalar y/o revisar el

hardware y software, reconfigurar si fuese necesario, teniendo enfocados los
requerimientos para mantener operativos los servicios dentro de las políticas ya
implementadas en los otros servidores, poblar o migrar datos, aseguramiento de
equipos, instalación de bases, sistemas y componentes.

Si durante la ejecución de esta actividad se requiriera reiniciar equipos, cambiar

parámetros de configuración, instalación de parches, archivos de sistemas,
modificación de grupos, perfiles de usuario, etc., será responsabilidad del Grupo de
Infraestructura y Logística garantizar la normal operación de la red de datos sin que
ellas interrumpan la normal operación de los sistemas y servicios.

d. Etapa 4 – Marcha blanca.

En esta etapa el personal de la Dirección de Telemática deberá considerar todas las

acciones para poner en funcionamiento el sistema construido. La marcha blanca
debe realizarse incluyendo algunos actores externos a la Dirección de Telemática,
los cuales junto con el personal que participe, deberá ser capacitado
adecuadamente entregándoles el manual de usuario, junto con otras herramientas
de auto-capacitación definidas para esta etapa.

Al finalizar esta etapa se entregará los informes respectivos con los siguientes
productos:

 Documentación final del sistema. Considerando manuales de usuario y de

administrador de sistemas y de bases de datos, documentación técnica
requerida según los estándares aplicados. Los manuales se entregarán en dos
copias físicas para revisión y en medio magnético para validación por parte del
personal de la Dirección de Telemática.

15
 Entrega de informe con Plan de instalación y transición de los sistemas para
revisión y aprobación por parte del personal de la Dirección de Telemática.

 Usuarios y administradores de los sistemas debidamente capacitados,

incluyendo usuarios externos a la Dirección de Telemática que formen parte del
proceso de marcha blanca.

 Marcha blanca realizada y aprobada.

 Interconexión con el Sistema generado y de los diferentes actores del proceso

(Web Services para Clientes de División de Armamento y Munición de la PNP;
envío, recepción, validación y carga de archivo XML de traspaso de datos).

 Plan de acción para la carga de datos históricos, si corresponde.

 Datos históricos debidamente validados y cargados, si corresponde.

 Sistema en régimen.

Esta actividad finalizada y aprobada formalmente por el Grupo de Administración del

Proyecto, será prerrequisito para continuar con la siguiente etapa.

Interconexión.

En esta actividad el personal de la Dirección de Telemática deberá realizar las

acciones necesarias para asegurar el buen funcionamiento de la interconexión con el
Sistema Integrado para la Gestión del Armamento y Munición Policial y las
aplicaciones de los diferentes actores de los procesos.

Migración, validación y normalización de datos históricos.

En esta actividad el Grupo de Infraestructura y Logística deberá cargar los datos

históricos que sean necesarios para la correcta operación de los sistemas
construidos. La carga o migración de datos se realizará de acuerdo al plan
establecido para este fin, procurando la normalización de la información a ser
trasladada.

Pruebas funcionales y desempeño en ambiente producción.

Instalados los sistemas y preparados los ambientes de producción por el personal de

la Dirección de Telemática se aplicarán y realizarán las pruebas funcionales de
acuerdo al plan de pruebas establecido en la etapa de diseño y prototipo, el cual
será validado por el grupo de pruebas.

Será responsabilidad del personal de la Dirección de Telemática corregir y reparar

durante la ejecución de las pruebas funcionales toda falla que implique pérdidas de
datos, caídas de equipos, caídas de servicios o toda otra contingencia que detenga o
interrumpa la normal operación de los equipos o servicios proporcionados por la
División de Armamento y Munición Policial.

Capacitación.

Durante la realización de esta actividad el personal de la Dirección de Telemática

realizará la capacitación de usuarios internos de División de Armamento y Munición
de la PNP. La capacitación deberá considerar al menos:
 16 horas cronológicas de capacitación para usuarios del sistema,

16
  16 horas para los administradores de red y sistemas.

La capacitación deberá contemplar talleres prácticos que permitan a los diversos

usuarios contar con los conocimientos suficientes para operar, administrar,
mantener los sistemas y bases de datos.

En dicha capacitación, se entregará material necesario para realizar dicha actividad

con éxito. Lo anterior incluye tener habilitada(s) la(s) sala(s) con el equipamiento
necesario y debidamente configurado.

La distribución y ubicación para la capacitación es la siguiente:

Grupo 1: Orientado a la administración del sistema, para personal de

informática.

Grupo 2: Orientado a usuarios del sistema, un usuario por cada módulo de

la Estructura Organizativa de División de Armamento y Munición de la PNP que
participen en la puesta en marcha.

Marcha Blanca.

Instalado cada sistema y preparado el ambiente de producción, con la participación

de algunas actores del proceso, pondrán en operación el sistema y módulos
iniciando un período de operación de marcha blanca.

Para tal efecto, las personas participantes de esta marcha blanca deben estar
adecuadamente capacitadas.

Durante este periodo, el personal de la Dirección de Telemática deberá proveer el

personal suficiente para corregir errores de código, ajustar parámetros, modificar
ventanas, vistas y reportes, asegurar conectividad, y permisos si así se requiriese.

Para la correcta ejecución de esta actividad se abrirá un sistema de Reporte de las

Fallas o Errores Encontrados, en el cual se registrará al menos:
 Descripción del error detectado,
 Fecha,
 Hora,
 Modificaciones o ajustes efectuados.

Esto debe ser sin perjuicio del desarrollo de otros sistemas en desarrollo paralelo.

Se identificarán tres categorías: fallas, anomalías e inconvenientes.

a) Se entenderá por falla cualquier evento que interrumpa o detenga la
operación de algún módulo, formulario, ventana, proceso, etc. Ésta deberá ser
corregida a la brevedad según se indica en el punto ‘Detección de fallas’.
b) Se entenderá por anomalía cualquier problema o error detectado en los
sistemas que no impida su funcionamiento.
c) Se entenderá por inconveniente cualquier comportamiento que signifique un
ingreso lento o pesado de la información, así como ausencia de ayudas mínimas.

Detectada una falla u anomalía de los sistemas, se informará al personal de la

Dirección de Telemática por medio del registro de eventos, correo electrónico u otro.

17
Detección de fallas.

Detectada y comunicada una falla de los sistemas, módulos, aplicaciones, etc., el

personal de la Dirección de Telemática tendrá un plazo máximo de 2 horas para dar
solución y dejar el sistema operativo.

Si la falla implicara una detención superior a 6 horas de algún módulo, la Marcha

blanca se extenderá en un día adicional para todos los sistemas y módulos.

Anomalías.

Toda anomalía comunicada al personal de la Dirección de Telemática deberá ser

resuelta en un plazo no superior a 48 horas a contar de la fecha y hora de
notificación de la misma.

Ajustes y mejoras al sistema.

Se podrá solicitar la ejecución de modificaciones a las ventanas, módulos,

programas y otros, ya existentes. Estos cambios pueden implicar agregar o
modificar funcionalidades (campos para datos, columnas en listados, botones que
ejecuten procesos, entre otros) no consideradas en las etapas de diseño y
construcción, pero, cuya necesidad sea detectada durante el proceso de pruebas y
marcha blanca del sistema.

Se entiende que dichas modificaciones son necesarias y que sin ellas, se verá
afectado el correcto desempeño de las funciones de los usuarios a los cuales está
dirigido el sistema.

Entrega final del proyecto.

Finalizada la Marcha blanca el personal de la Dirección de Telemática deberá

entregar toda la documentación del proyecto en su versión final, tanto en formato
impreso y electrónico.

Los documentos impresos deben venir en 2 copias y anillados, la documentación

electrónica va a venir en CD rotulado correctamente y en formatos acordados por el
personal de la Dirección de telemática para su correcta utilización posterior. Los
documentos esperados son:

- Documentos de control de proyecto: En este grupo se debe incorporar todo

aquel documento que permita conocer la evolución del proyecto desde el inicio,
avances, acuerdos y término del proyecto. Algunos ejemplo son: actas de
reuniones, documentos de trabajo, documentos aprobados, solicitudes y arreglo
de aplicaciones o procesos, riesgos del proyecto, administración de
requerimientos, cartas de aprobaciones de etapas, etc.

- Documentos y/o archivos de las aplicaciones desarrolladas: Corresponde a toda

aplicación fuente y ejecutable que forme parte del proyecto.

- Documentación técnica del sistema: Corresponde a todos los documentos

requeridos, que permita entregar a cualquier persona el conocimiento técnico
necesario para entender el sistema y dejarlo en condiciones de realizar
mantenciones.

18