Plan de Trabajo Mai V 1.0

PROYECTO
MÓDULO DE ARCHIVO INTERNO
CP 0001 – 2005 / ONP
NUEVO SISTEMA DE TRÁMITE DOCUMENTARIO

(NSTD - MAI)
PLAN DE TRABAJO
ETAPA 1
GMD S.A. - ONP
Actualizado a
Octubre 2005
GMD-ONP.PL.01 PLAN DE TRABAJO
NSTD – Módulo de Archivo Interno
Historial de Revisiones
ESTADO RESPONSABLE DE
ÍTEM FECHA VERSIÓN EQUIPO AUTOR DESCRIPCIÓN (EN REVISIÓN / REVISIÓN Y/O
APROBADO) APROBACIÓN
01 25/07/2005 0.9 GMD-NSTD AKN Versión preliminar del Plan Revisado LPG
02 08/08/2005 0.9 GMD-NSTD AKN Revisión del Plan de Trabajo Revisado ECM
03 16/08/2005 0.9 GMD-NSTD AKN Revisión del Plan de Trabajo Revisado AZA
04 16/08/2005 0.9 GMD-NSTD AKN Revisión del Plan de Trabajo Revisado NEA
05 16/08/2005 0.9 GMD-NSTD AKN Revisión del Plan de Trabajo Revisado COR
06 23/08/2005 0.9 GMD-NSTD AKN Revisión del Plan de Trabajo Revisado ECM
07 26/09/2005 0.9 GMD-NSTD FOB Revisión del Plan de Trabajo Revisado AZA
08 26/09/2005 0.9 GMD-NSTD FOB Revisión del Plan de Trabajo Revisado COR
09 26/09/2005 0.9 GMD-NSTD FOB Revisión del Plan de Trabajo Revisado NEA
10 17/10/2005 0.9 GMD-NSTD FOB Revisión del Plan de Trabajo Revisado AZ
11 17/10/2005 0.9 GMD-NSTD FOB Revisión del Plan de Trabajo Aprobado ZAP
12 17/10/2005 0.9 GMD-NSTD FOB Revisión del Plan de Trabajo Aprobado NEA
13 20/10/2005 1.0 GMD-NSTD FOB Revisión del Plan de Trabajo Aprobado AZA
14 20/10/2005 1.0 GMD-NSTD FOB Revisión del Plan de Trabajo Aprobado COR
Revisión: 01 GMD - 2005 Página: 2 / 56

Autores: Revisión GMD:

AKN : Anna Karpova de Nuñez ECM : Enrique Camarena Mejía
FOB : Francisco Orosco Bailón LPG : Luis Pérez Godoy
Revisión ONP:
AZA : Alfonso Zuazo Arnao
NEA : Nathaly Espinoza Ascencio
COR : Claudia Oneeglio Repetto
ZAP : Zadi Anaya

TABLA DE CONTENIDOS
1. INTRODUCCIÓN.............................................................................................10
2. OBJETIVO DEL PLAN....................................................................................10
3. ANTECEDENTES...........................................................................................10
4. OBJETIVO DEL PROYECTO.........................................................................11
5. ALCANCE........................................................................................................11
6. DESCRIPCIÓN DEL SISTEMA.......................................................................13
6.1 PEDIDOS..............................................................................................14
6.1.1 PEDIDOS DE DOCUMENTOS.......................................................14
6.1.2 BANDEJA DE PEDIDO ARCHIVOS...............................................15
6.1.3 BANDEJA DE UNIDADES ORGANIZACIONALES........................15
6.1.4 BANDEJA DE SUPERVISORES....................................................15
6.1.5 CRUCE DE DOCUMENTOS..........................................................15
6.2 CONSULTAS DE DOCUMENTOS......................................................16
6.2.1 DOCUMENTOS..............................................................................16
6.2.2 HOJA DE LOTE..............................................................................16
6.2.3 HOJA DE RUTA..............................................................................16
6.3 INGRESO DE DOCUMENTOS.............................................................16
6.4 REPORTES DE ATENCIÓN.................................................................16
6.4.1 ATENCIÓN......................................................................................16
6.4.2 PROCESOS....................................................................................17
6.4.3 MOVIMIENTOS...............................................................................17
6.4.4 PERMANENCIA..............................................................................17
6.4.5 PRODUCCIÓN................................................................................18
6.4.6 GENERALES..................................................................................18
6.5 MOVILIZACIONES...............................................................................18
6.5.1 INMOVILIZAR DOCUMENTOS......................................................18
6.5.2 MOVILIZAR DOCUMENTOS..........................................................18
6.6 INVENTARIO........................................................................................19
6.7 MANTENIMIENTO................................................................................19
6.7.1 DOCUMENTOS..............................................................................19

6.7.2 RELOTIZACION..............................................................................19
6.7.3 OBSERVACIÓN..............................................................................19
6.7.4 TIPO DE PROCESO.......................................................................19
6.7.5 OPERACIÓN...................................................................................19
6.7.6 DESTINATARIOS............................................................................19
6.7.7 PARÁMETROS...............................................................................20
6.8 ADMINISTRACIÓN...............................................................................20
6.8.1 TIPOS DE DOCUMENTOS............................................................20
6.8.2 UBICACIÓN TOPOGRÁFICA.........................................................20
6.8.3 DEFINICIÓN DE ESTRUCTURA DE CÓDIGO DE BARRA PARA
CADA TIPO DE DOCUMENTO...............................................................20
6.8.4 TIEMPOS DE ATENCIÓN...............................................................20
6.8.5 NIVELES DE AUTORIZACIÓN.......................................................21
6.9 INTERFAZ CON SISTEMA DE PROCESOS JUDICIALES................21
6.10 MÓDULO DE SEGURIDAD.................................................................21
6.11 MÓDULO DE GENERACION DE CODIGO DE BARRAS..................21
6.12 MÓDULO DE ANEXADO DE DOCUMENTOS....................................21
7. ARQUITECTURA Y PLATAFORMA...............................................................22
7.1 ARQUITECTURA Y PLATAFORMA DEL MODELO ACTUAL...........22
7.2 ARQUITECTURA Y PLATAFORMA DEL MODELO PROPUESTO....23
7.3 PLATAFORMA DE DESARROLLO.....................................................28
7.4 PLATAFORMA DE IMPLEMENTACIÓN..............................................29
8. PLAN DEL PROYECTO..................................................................................30
8.1 FASE INICIAL O FASE DE INCEPCIÓN.............................................33
8.2 FASE DE ELABORACIÓN...................................................................34
8.3 FASE DE CONSTRUCCIÓN................................................................35
8.4 FASE DE TRANSICIÓN.......................................................................38
9. ORGANIZACIÓN DEL PROYECTO...............................................................38
9.1 ESTRUCTURA ORGANIZACIONAL...................................................38
9.2 ROLES Y FUNCIONES DEL EQUIPO DE TRABAJO........................40
9.3 REUNIONES DE CONTROL Y LÍNEAS DE COMUNICACIÓN..........44
10. CRONOGRAMA DE ACTIVIDADES...........................................................47

11. ENTREGABLES...........................................................................................47
11.1 INCEPCIÓN (INICIO)............................................................................47
11.2 ELABORACIÓN...................................................................................48
11.3 CONSTRUCCIÓN.................................................................................49
11.4 TRANSICIÓN........................................................................................50
12. ADMINISTRACIÓN DE RIESGOS...............................................................51
13. ACTIVIDADES DE CONTRAPARTE...........................................................53
14. CONTROL DE CAMBIOS DEL ALCANCE Y PLAN DEL PROYECTO....54
15. ANEXOS.......................................................................................................55

RESUMEN EJECUTIVO
La Oficina de Normalización Previsional (ONP), en el marco del Servicio de

Mantenimiento y Desarrollo del Nuevo Sistema de Trámite Documentario – NSTD y
Depuración de Base de Datos (Concurso Público Nº 0001-2005-ONP, el tipo de
proyecto: proyectos especiales y dentro de ellos corresponde al primer requerimiento
de este proyecto: Módulo de Archivo Interno) establece una serie de actividades
conducentes a satisfacer las necesidades operativas y de gestión requeridas por la
Gerencia de Desarrollo, encargada de brindar el apoyo tecnológico necesario en el
procesamiento de la información propia de los procesos institucionales.
Uno de los servicios previstos, es establecer un Plan para el desarrollo del Módulo de
Archivo Interno para que soporte los Procesos de Archivo en su integridad, el cual
consiste en un conjunto de actividades y recursos asociados que deben utilizarse para
asegurar el desarrollo de un software de alta calidad e integración de sistemas.
El presente proyecto de desarrollo del Módulo de Archivo Interno (MAI), tomará como
base el Módulo actual de Archivo Temporal (MAT). La funcionalidad actual del módulo
MAT se extenderá a la nueva solución y se trasladará a los otros archivos que se
incorporarán al MAI.
Para el desarrollo del MAI, módulo perteneciente al Nuevo Sistema de Trámite

Documentario (NSTD), se utilizará la Metodología de Desarrollo de Sistemas
propuesta por GMD y aprobada por ONP1, la cual está basada en los estándares del
Proceso Unificado de Desarrollo de Software (RUP) y utilizando el Lenguaje de
Modelamiento Unificado (UML).
El cumplimiento de las pautas establecidas en sus diferentes fases, permitirá asegurar

el desarrollo de un software de calidad y a la medida de la ONP. En cada fase se
entregará documentación relevante al desarrollo del sistema propuesto. El gráfico
consolida la lista de documentos entregables a ONP basados en la metodología RUP.
(Ver gráfico Lista de Entregables ONP-RUP).
1
La Metodología de Desarrollo de Sistemas es parte del documento “GMD-ONP.P.01
METODOLOGÍA DE ANÁLISIS, DISEÑO, DESARROLLO E INTEGRACIÓN DE SISTEMAS”
propuesto por GMD, como parte del servicio.

La metodología de desarrollo (RUP), implica cuatro fases: Incepción, Elaboración,

Construcción y Transición; cada una con un conjunto de entregables proporcionados a
lo largo de la ejecución del proyecto. En la siguiente tabla se resume los entregables
que se tendrá en el Módulo de Archivo Interno indicando la fase y el proceso al que
corresponde:
Gráfico Nº 01
El Módulo de Archivo será entregado en un período de tiempo de 11 meses, con la

participación de 4 especialistas informáticos: un analista de Sistemas, dos Analistas
Programadores y un documentador a tiempo parcial, que se irán incorporando al
proyecto según la programación establecida en el presente plan. La administración y
control del Proyecto estarán a cargo del Jefe de Sistemas y el Coordinador del
Proyecto de ONP.
El tiempo estimado de desarrollo del Módulo de Archivo Interno, supera lo considerado

en el Project Charter para la primera Etapa, debido a que se realizara un nuevo
desarrollo para el Módulo de Archivo Interno, implementación del Módulo de Anexado
de Documentos, se tendrá en consideración en el documento de análisis y diseño la

implementación del Módulo de Derivación de los documentos para los sistemas que no
cuentan con su propio módulo que permite derivar los documentos e interfaces
(actualización en línea en el NSTD) para aquellos sistemas que cuentan con módulo
de derivación, implementación del módulo de Generación de Códigos de Barra.
Migración de datos de archivo de Calificaciones y de Archivo de Procesos Judiciales.
Al finalizar este proyecto, la ONP dispondrá de un módulo que apoye la gestión de los
documentos de los Procesos de Archivo que se encuentren implementados,
facilitándoles su administración y seguimiento.

2.8.3.1INTRODUCCIÓN
El presente documento describe los lineamientos para el desarrollo del Módulo

de Archivo Interno (MAI), el cual permitirá contar con una herramienta con la
que se ejecutaran los procesos operativos relacionados al Proceso de Archivo
en su integridad.
2.8.3.2OBJETIVO DEL PLAN
Establecer los lineamientos para el logro del proyecto, considerando las

actividades, fechas de entrega y recursos asignados contemplados para el
desarrollo del sistema de acuerdo al plan de trabajo del Proyecto.
2.8.3.3ANTECEDENTES
La Gerencia de Desarrollo es el órgano de soporte responsable de brindar el

apoyo tecnológico necesario en el procesamiento de la información propia de
los procesos institucionales, así como desarrollar los planes y proyectos que
requiera la gestión de la ONP.
El Módulo de Archivo Temporal (MAT), está integrado y contenido en el Nuevo

Sistema de Trámite Documentario (NSTD). Es una herramienta preparada para
dar apoyo a la gestión del Archivo Temporal de Expedientes en Proceso de la
División de Calificaciones, que permite facilitar y/o automatizar las tareas de
recepción, registro, lotización, control topográfico, inventario, atención, pedidos
y consultas de expedientes que se encuentran en la custodia del Archivo
Temporal.
Debido a la política de integración de procesos, los diferentes archivos de la

Gerencia de Operaciones administrados de manera independiente serán
administrados por un único Proceso de Archivo, el cual deberá ser soportado
por un único sistema informático, de acuerdo a la política de integración de
sistemas.

El Módulo de Archivo Interno (MAI) del Sistema de Trámite Documentario del

Proceso de Pensionamiento, se constituirá en la herramienta con la que se
ejecutaran los procesos operativos relacionados al Proceso de Archivo antes
mencionado. En este marco, la ONP requiere que se amplíen las
funcionalidades del Módulo de Archivo Temporal, de manera tal que permita dar
soporte al Proceso de Archivo en su integridad.
La funcionalidad actual del módulo MAT se extenderá a la nueva solución y se

trasladará a los otros archivos que se integrarán al MAI.
Como parte de la integración de Archivos, el MAT dejará de dar soporte solo al

Archivo Temporal, convirtiéndose en soporte al Archivo Interno del Proceso de
Pensionamiento, por lo que se denominará Módulo de Archivo Interno – MAI.
2.8.3.4OBJETIVO DEL PROYECTO
El presente proyecto tiene como objetivo contar con un Módulo de Archivo

Interno integrado al Nuevo Sistema de Trámite Documentario (NSTD), que
permita administrar, custodiar y gestionar los documentos generados en los
procesos operativos de las áreas involucradas dentro del Proceso de Archivo
de su competencia.
2.8.3.5ALCANCE
El presente Proyecto considera el desarrollo del Módulo de Archivo Interno

(MAI), tomando como base las funcionalidades del MAT, a fin de que puedan
servir de referencia para el desarrollo de las funcionalidades requeridas.
El Proyecto considera la implementación del módulo en todos los archivos de
las divisiones de procesos operativos de ONP definiéndose las etapas
siguientes:
Etapa 1:
- Archivo de Calificaciones
- Archivo de Procesos Judiciales
Etapa 2:
- Archivo de Departamentales

- Archivo de Pensiones
- Archivo de Recaudación
Etapa 3:
- Archivo de Reconocimiento
El presente Plan de Trabajo considera la implementación de la etapa I, esto es

Archivo de Calificaciones y Archivo de Procesos Judiciales.
Se han tomado las siguientes consideraciones:
- El módulo de seguridad será utilizado del sistema NSTD.
- El flujo de documentos (derivaciones) será controlado por el módulo
correspondiente para cada documento. De requerir alguna adecuación de
dicho módulo, esta no forma parte del presente proyecto.
- Para Pensiones y Recaudaciones que no cuentan con su propio módulo
para derivar los documentos se desarrollará una opción de ingreso y salida
de documentos, que simula la derivación del y hacia el archivo interno en su
correspondiente etapa de desarrollo.
- La base de datos del Módulo de Archivo Interno contendrá la información
necesaria para identificar los diferentes tipos de documentos de cada
archivo.
- El MAI contará con la opción que permite generar el código de barras para
los documentos a ser administrados.
- La estructura del código de barras será parametrizable para cada tipo de
documento y definida por ONP. Esta será proveída según lo requerido en el
cronograma de trabajo.
- El MAI contará con la opción de registro del anexado de documentos a los
expedientes, el cuál tomará como base la opción actual del NSTD.
- El presente Proyecto considera la administración de documentos, control y
custodia, control topográfico, atención de los pedidos, inventario, reportes y
consultas.
- Integración con otros sistemas operativos de Archivos.
- Migración de data estructurada y validada. No es parte de este proyecto
realizar la depuración y/o tratamiento de información a migrar.
- No es parte de este proyecto el desarrollo de data entries, depuración de
datos de la información histórica modificación de programas asociados al
proceso de unificación y desunificación, así como otros asociados a

funcionalidad operativa de los procesos de ONP; sin embargo, se debe

realizar los procedimientos de actualización en las tablas de la base de
datos que corresponda cuando se ejecute alguna unificación en el módulo
de unificación.
- Dentro del modulo MAI se considera el control de las unificaciones para los
retornos de documentos.
- Instalación, configuración e implementación del software materia del
presente proyecto.
- Todas las actividades estarán soportadas por una adecuada asesoría,
capacitación y pruebas respectivas para una exitosa implementación de la
herramienta de desarrollo.
- Actualización de información de otros sistemas de trámite documentario
donde se lleve el control de documentos no administrados por el NSTD, sin
embargo, el desarrollo de los procedimientos de actualización en las bases
de datos de los sistemas externos al NSTD, deberán ser desarrollados por
el propio mantenimiento de cada sistema.
- No es parte del presente proyecto, los cambios en las funcionalidades de
los sistemas que van a interactuar con el NSTD para la gestión de archivo.
2.8.3.6DESCRIPCIÓN DEL SISTEMA
El Módulo de Archivo Interno permitirá realizar lo siguiente:

- Administrar la documentación de diversos archivos. Cada archivo podrá
declarar todos los tipos de documentos que serán administrados por el
archivo y tendrá su propio tipo de ordenamiento topográfico.
- Realizar el control y custodia de los documentos: el registro, solicitud de
pedido y atención de los documentos definidos por cada uno de los
archivos.
- Recibir y custodiar cualquier tipo de documento que sea necesario para el
trabajo dentro del Proceso de Archivo de cada una de las Divisiones
Usuarias, indicando a que archivo pertenece y el método de control de
archivo físico.
- Anexar los documentos recibidos a cada uno de los expedientes, así como
el control y gestión del proceso de anexado.

- Realizar automáticamente el control topográfico por cada archivo,

parametrizando para cada tipo de documentos los anaqueles que utilizará y
el tipo de distribución de cada documento.
- Considerará a los Expedientes como un tipo de documento.
- Generar, leer e imprimir el código de barras para los expedientes y
documentos a ser administrados. Se parametrizará la estructura del código
de barras para cada tipo de documento.
- Pedidos de documentos de acuerdo a los niveles de autorización definidos
para cada documento.
- Atención de pedidos para todos los documentos y expedientes que custodie
el Archivo, así como la administración de los tiempos de atención.
- Realizar las consultas necesarias, a través de reportes, para los informes
del archivo y aquellos que la ONP considere conveniente para el control del
mismo.
- Realizar el inventario físico de documentos y realizar el cruce de dicho
inventario con los registros almacenados en la BD.
- Programar los límites de atención diaria para cada División.
- Permitirá integración con otros sistemas de Archivo
En la fase de Incepción de la Metodología de Desarrollo de Sistemas, se

relevará la información que permita definir al detalle el alcance del Módulo a
implementar.
Los submódulos comprendidos son:
6.1 PEDIDOS
6.1.1 PEDIDOS DE DOCUMENTOS

Donde podrán realizar el pedido de uno o varios documentos de
cada archivo.
Permitirá realizar el pedido masivo, también unitario, cargando los
documentos desde un archivo Excel o pedido individual. Exportar
los resultados de procesamiento de la carga.

Se parametriza el tipo de documento que solicita cada usuario del

proceso y se parametriza la cantidad máxima de documentos que
pueden ser solicitados en un pedido y en un periodo de tiempo.
6.1.2 BANDEJA DE PEDIDO ARCHIVOS

Donde se realiza la atención de pedidos solicitados por los
usuarios clientes, como también la visualización de todos los
pedidos pendientes (avance de atención y programación) y
cancelación de los pedidos, la impresión de relación de los
pedidos, y el detalle de la hoja de pedido. Este módulo es a nivel
del administrador del archivo.
Para los documentos que son gestionados por el NSTD, la

atención de pedidos se realizará a través del Módulo de
Derivación, ya que este actualiza y descarga de manera
automática los documentos derivados; sin embargo para los
documentos no gestionados por el NSTD, la atención de pedidos
se realizará a través de la bandeja de pedidos.
6.1.3 BANDEJA DE UNIDADES ORGANIZACIONALES

Donde se visualizan los pedidos realizados por las UO, también
podrán ver sus documentos pendientes de atención y cancelación
de pedidos, como también la impresión de la relación de los
pedidos.
6.1.4 BANDEJA DE SUPERVISORES

Donde se visualizarán los pedidos realizados por el mismo usuario
y por otros usuarios, ver el detalle de los pedidos e imprimir la
relación de los pedidos.
Mostrará la información pero solo a modo de consulta.
6.1.5 CRUCE DE DOCUMENTOS

Permitirá realizar el cruce de los documentos que se encuentran en
un medio magnético con la data del Módulo de Archivo, con la
finalidad de determinar la situación de los documentos, si existen,

si están disponibles o no en el archivo. Para esto la data se cargará

desde un archivo Excel para ser procesada. Los resultados de
comparación se podrán exportar a Excel.
6.2 CONSULTAS DE DOCUMENTOS

Permitirá realizar las consultas a los documentos por cada Archivo.
6.2.1 DOCUMENTOS
Permitirá visualizar los datos y la ubicación de los documentos
además permitirá imprimir el código de barra.
6.2.2 HOJA DE LOTE

Permitirá visualizar e imprimir la hoja de lote que identificará al
paquete en su ubicación topográfica.
6.2.3 HOJA DE RUTA

Permitirá consultar e imprimir la hoja de atención y la hoja del
pedido en detalle.
6.3 INGRESO DE DOCUMENTOS

Permitirá los ingresos de documentos hacia el archivo en forma manual y
usando la lectora del Código de Barras. También permitirá la actualización
de los estados de los documentos ingresados.
6.4 REPORTES DE ATENCIÓN

Reportes necesario para los informes de cada Archivo.
Durante el proyecto también se pueden desarrollar nuevos reportes.
6.4.1 ATENCIÓN
Permitirán agrupar los Requerimientos de los Documentos y
mostrar la diferencia entre la cantidad solicitada y cantidad
atendida. Actualmente existen 3 reportes:

 Atención de los requerimientos por el nombre del pedido:

permitirá visualizar la relación de los pedidos atendidos por el
área.
 Atención de los requerimientos por el tipo: permitirá visualizar
los requerimientos de los documentos por el tipo de proceso.
 Detalle de derivación diaria: permitirá visualizar el detalle diario
de los pedidos derivados a lo largo de una semana.
6.4.2 PROCESOS
Permitirán agrupar los Movimientos de los Documentos según el
tipo: Ingresos, Retornos, Salidas y Lotizaciones. Actualmente
existen 4 reportes:
 Ingreso por día: muestra los ingresos de los documentos.
 Retornos por día: muestra los retornos de los documentos.
 Salidas por día: muestra las salidas de los documentos.
 Lotizaciones por día: muestra lotizaciones de los documentos.
6.4.3 MOVIMIENTOS
Permitirán agrupar los Movimientos de los Documentos por
diferentes criterios. Actualmente existen 3 reportes:
 Movimientos del motivo de espera por UO: permitirá visualizar
los movimientos motivo de espera por Unidades
Organizacionales.
 Movimientos por UO: permitirá visualizar los movimientos por
cada Unidad Organizacional.
 Resumen diario por motivo de espera: permitirá visualizar el
resumen diario por motivo de espera.
6.4.4 PERMANENCIA
Permitirán medir el tiempo de permanencia de los documentos
dentro del archivo. Actualmente existen 2 reportes:
 Detalle de permanencia de Expedientes: permite visualizar en
detalle la permanencia de los Expedientes.

 Permanencia de los Expedientes: permite visualizar la

permanencia de los Expedientes.
6.4.5 PRODUCCIÓN
Permitirán calcular la cantidad de movimientos realizados por los
usuarios. Actualmente existen 2 reportes:
 Reportes de Producción: permitirá visualizar la producción de
todos los turnos.
 Producción por Usuario: permitirá visualizar la producción por
Usuario.
6.4.6 GENERALES
Reportes diversos del Sistema. Actualmente existen 2 reportes:
 Documentos sin lotizar: permitirá visualizar los documentos sin
lotizar.
 Documentos Inmovilizados: permitirá visualizar los documentos
inmovilizados.
También se implementarán reportes determinados por el usuario de

cada División Usuaria en la fase de Incepción.
6.5 MOVILIZACIONES
6.5.1 INMOVILIZAR DOCUMENTOS

Donde el usuario podrá inmovilizar un grupo de documentos para
que solamente él pueda solicitarlos posteriormente. Para procesar
los documentos se realizará la carga de documentos a través de
una hoja de Excel o individualmente, ingresando el número de
documento. Los resultados del proceso podrán ser exportados a
Excel e impresos.

6.5.2 MOVILIZAR DOCUMENTOS

Podrán movilizar documentos (permitir que otros usuarios puedan
solicitar los documentos que se encontraban inmovilizados).
Permitirá que un documento inmovilizado esté nuevamente
disponible.
6.6 INVENTARIO
Donde el usuario podrá realizar una comparación entre los registros de la

Base de Datos (inventario lógico) y los de un archivo para cada tipo de
documento (inventario físico). Permitirá validar el Stock con un Inventario
tomado en un archivo Excel o TXT, realizar la carga del archivo, procesar
la carga, visualizar el resultado de cruce e imprimir el detalle.
Asimismo, emitirá un reporte de la cantidad de documentos existentes en

el archivo por tipo de documento, así como el detalle de los mismos.
6.7 MANTENIMIENTO
6.7.1 DOCUMENTOS
Donde el usuario podrá actualizar los datos de los documentos
(definidos por el Usuario de la Unidad Organizacional en la fase de
Incepción).
6.7.2 RELOTIZACION
Permitirá crear nuevos lotes de los documentos de un tipo y
también agregar más documentos dentro del mismo.
6.7.3 OBSERVACIÓN
Permitirá crear, modificar y eliminar una observación de un tipo del
documento.
6.7.4 TIPO DE PROCESO
Permitirá crear, modificar y eliminar un tipo de proceso.

6.7.5 OPERACIÓN
Permitirá crear, modificar y eliminar una operación.
6.7.6 DESTINATARIOS
Permitirá crear, modificar y eliminar un destinatario.
6.7.7 PARÁMETROS
Permitirá crear, modificar y eliminar los parámetros.
6.8 ADMINISTRACIÓN
Donde el usuario podrá parametrizar la creación de los nuevos
documentos, el método de control del archivo físico la asignación de la
ubicación topográfica para cada tipo del documento la parametrización de
la estructura del código de barras para cada tipo de documento,
parametrizar los límites de atención diaria para cada archivo según tipo de
documento, parametrización de los tiempos de atención y los niveles de
autorización para los pedidos.
6.8.1 TIPOS DE DOCUMENTOS

Permitirá parametrizar la creación de los nuevos tipos de
documentos para cada Archivo.
(Al declarar un nuevo tipo de documento dentro del MAI reconoce
todas las funcionalidades).
6.8.2 UBICACIÓN TOPOGRÁFICA

Permitirá parametrizar la asignación de la ubicación topográfica
para cada tipo del documento dependiendo del método de control
del archivo físico (definido por el Usuario de Unidad Organizacional
en la fase de Incepción).
Las asignaciones pueden ser unitarias o en lotes.
Permitirá el Ingreso de forma manual y automático.

6.8.3 DEFINICIÓN DE ESTRUCTURA DE CÓDIGO DE BARRA PARA CADA

TIPO DE DOCUMENTO
Permitirá parametrizar la estructura del código de barra para cada
tipo de documento.
6.8.4 TIEMPOS DE ATENCIÓN

Permitirá parametrizar los límites de atención diaria para cada
archivo, por tipo de documento.
6.8.5 NIVELES DE AUTORIZACIÓN

Permitirán parametrizar los usuarios que están autorizados para
realizar pedidos, por tipo de documento, volumen y archivo.
6.9 INTERFAZ CON SISTEMA DE PROCESOS JUDICIALES

El Módulo de Archivo Interno realizará la gestión de los documentos
dentro del Archivo, por lo tanto, para aquellos documentos donde la
gestión del trámite documentario se realice en el RCPJ. El MAI consultará
y actualizará dicho sistema para mantener el flujo entre el MAI y el RCPJ.
Para realizar la actualización en el RCPJ, se deberán elaborar los

procedimientos de actualización en el sistema, el cual deberá ser
realizado a través del mantenimiento del RCPJ.
6.10 MÓDULO DE SEGURIDAD

Con respecto a la Seguridad, el sistema permitirá guardar la información
del Usuario que registra, actualiza y elimina la información. El manejo de
control de acceso al Módulo de Archivo Interno estará bajo las
características de administración de la seguridad del NSTD. Para esto el
Usuario líder definirá los roles, perfiles y los accesos a los módulos.

6.11 MÓDULO DE GENERACION DE CODIGO DE BARRAS
El sistema permitirá generar e imprimir el código de barras para los

documentos a ser administrados.
6.12 MÓDULO DE ANEXADO DE DOCUMENTOS

El sistema permitirá anexar los documentos recibidos a cada uno de los
expedientes, así como el control y gestión del proceso de anexado.

2.8.3.7ARQUITECTURA Y PLATAFORMA
6.1ARQUITECTURA Y PLATAFORMA DEL MODELO ACTUAL

El modelo actual del MAT fue desarrollado bajo la Arquitectura de
Aplicaciones para WEB Struts.
Struts es un framework Java MVC (Model – View - Controller) para

desarrollo de aplicaciones Web basadas en JSP sobre la plataforma J2EE
(grupo de especificaciones y tecnologías diseñadas por SUN que permiten
la creación de aplicaciones empresariales), se puede ver en el Gráfico 02:
Gráfico Nº 02
El framework es un conjunto de componentes pre-fabricados que los

desarrolladores pueden usar, entender (herencia) o personalizar, por esta
razón el desarrollo no empieza de “cero”, sino sobre una base que ofrece
múltiples objetos que pueden ser re-usados.
Struts es una plataforma que permite dividir la lógica de la presentación

entre otras cosas. El Modelo MVC separa muy bien lo que es la gestión
del workflow de la aplicación, del modelo de objetos de negocio y de la
generación de interfaz.

Realmente lo que provee es un conjunto de clases y TAG-LIBS que

conforman el Controlador, la integración con el Modelo (o lógica de
negocio) y facilitan la construcción de Vistas.
El controlador ya se encuentra implementado por Struts, aunque si fuera

necesario se puede heredar y ampliar o modificar, y el workflow de la
aplicación se puede programar desde un archivo XML. Las acciones que
se ejecutan sobre el modelo de objetos de negocio se implementan
basándose en clases predefinidas por el framework. La generación de
interfaz se soporta mediante un conjunto de Tags predefinidos por Struts.
Separa claramente el desarrollo de interfaz del workflow y la lógica de
negocio permitiendo desarrollar ambas en paralelo.
Los componentes de control son los encargados de coordinar las

actividades de la aplicación, que van desde la recepción de datos del
usuario, las verificaciones de forma y la selección de un componente del
modelo a ser llamado. Por su parte los componentes del modelo envían al
control sus eventuales resultados y/o errores de manera de poder
continuar con otros pasos de la aplicación.
Las páginas JSP no tienen que incluir manejo de errores, mientras que los
elementos del control simplemente deciden sobre el paso siguiente a
seguir.
Para realizar el desarrollo bajo la arquitectura struts es necesario contar

con personal especializado. En el futuro se debe prever la capacitación del
personal a cargo del mantenimiento del Sistema.
6.2ARQUITECTURA Y PLATAFORMA DEL MODELO PROPUESTO
Con la finalidad de soportar los requerimientos de los usuarios y asegurar

el afinamiento y crecimiento del sistema, se recomienda la construcción de
un sistema distribuido de múltiples capas, usando herramientas y
tecnologías de componentes.

En una aplicación de estas características la interfaz visual, la lógica de

negocios y los datos son elementos conceptualmente separados.
Los componentes de la capa de presentación manejan la interacción con

el usuario y los requerimientos que éste hace a la aplicación llamando a
los componentes de la capa intermedia que se puede ver mejor en el
Gráfico Nº 03 Modelo Distribuido del Módulo de Archivo Interno.
Modelo Distribuido del Módulo de Archivo Interno (MAI)
Gráfico Nº 03
El Módulo de Archivo será desarrollado bajo una arquitectura que

corresponde a Sistemas Distribuidos (Aplicaciones Web) según el
estándar J2EE.
J2EE es un grupo de especificaciones y tecnologías diseñadas por SUN

que permiten la creación de aplicaciones empresariales.
Entre las especificaciones y tecnologías definidas tenemos:
 Acceso a base de datos (JDBC)
 Utilización de directorios distribuidos (JNDI)
 Funciones de correo electrónico (JavaMail)

 Componentes Web (JSP, Servlets, JavaBean)
Se puede ver en el Gráfico Nº 04 Arquitectura del NSTD para tener una

mejor idea de la arquitectura que se piensa manejar para el desarrollo del
Módulo de Archivo Interno.
Arquitectura del NSTD
Gráfico Nº 04
Para la implementación del Módulo de Archivo se considerará los

siguientes componentes:
 Capa de Presentación: Desde la cual se activará la aplicación, a través
de un explorador (paginas HTML, JSP, XML) y una dirección URL
asignada al Sistema.
 Capa de Negocios (Servidor Web): En el cual residirán las páginas
estáticas y dinámicas elaboradas para la aplicación y la lógica de
negocio (Servlet, JavaBean, Despachadores, controladores). Se utilizará
el servidor de publicaciones (Orarle 9ias) donde se implementara las
páginas (JSP) y los componentes de software (Servlet, JavaBean,
Despachadores, Controladores).
 Capa de Data: En el cual residirá la Base de Datos y los diferentes
objetos creados para el Sistema (tablas, índices, procedimientos

almacenados, funciones, vistas). Se utilizará el soporte brindado por el

Administrador de Base de Datos Oracle 9i.
Para el desarrollo de las Opciones (submódulos) del Módulo de Archivo se

utilizará el patrón MVC (Model – View- Controller), modelo que permite
separar adecuadamente los componentes de la aplicación facilitando el
entendimiento y el mantenimiento de la misma, se puede ver en el Gráfico
Nº 05:
Gráfico Nº 05
El Modelo está representado por las clases de negocios denominamos

beans, listas (list) y despachadores (Dispatcher). Son responsables de
manejar los datos y controlar todas sus transformaciones. La aplicación se
encarga de enlazar el Modelo y sus Vistas respectivas.
La Vista está conformada por las páginas servidoras (Java Server Pages)
responsables de visualizar los datos representados por el Modelo.
Generan una vista del Modelo y muestra los datos al usuario. Interactúa
con el Modelo a través de una referencia al propio Modelo.

El Controlador está conformado por los servlets y controladores, los

cuales reciben las peticiones de los usuarios (request) con los que
modifica el modelo.
JSP Servlet
Despachador
BD Negocio
Gráfico Nº 06
El Servlet atiende la solicitud e instancia la clase Despachadora y este a

su vez llama al método de la Clase de Negocio la cual realiza la consulta
a la base de datos.
6.3PLATAFORMA DE DESARROLLO
Las opciones (submódulos) del Módulo de Archivo Interno serán
desarrolladas en lenguaje de programación Java, lenguaje que permitirá

implementar el Sistema sin depender de la plataforma (Múltiples sistemas

operativos).
Para la implementación de los módulos se utilizará las siguientes

herramientas tecnológicas:
 Capa de Presentación (Cliente).
Propósito Producto
MS Internet Explorer 5 ó superior
HTML, XML, Java Script
JSP Servlet
Despachador
BD Negocio
Navegador
 Capa de Reglas de Negocios o Lógica del Sistema.
Propósito Producto

Lenguaje Java2 (JDK 1.3.1 o Superior)

Utilizado
Servidor Web y Oracle 9ias
Aplicaciones
IDE Desarrollado en Eclipse 3.0 o
Superior
Componentes de Aplicación:
Servlet
JSP
JavaBeans
XML
 Capa de Datos

Propósito Producto
Base de Datos Oracle 9i Enterprise Server.
 Herramientas Adicionales empleadas
Herramienta
Herramienta utilizada para el Modelamiento (RUP)
Rational Rose Enterprise Edition

Herramienta para Diseño lógico y físico de la Base Datos.
Erwin Data Modeler

Herramienta para la documentación del Proyecto.
Microsoft Office Word 2003
6.4PLATAFORMA DE IMPLEMENTACIÓN
Considerando las características de los estándares utilizados actualmente
por la ONP, se utilizará para la puesta en producción del Módulo de
Archivo lo siguiente:
 Servidor.
 Sistema de Gestión de Base de Datos Relacional Oracle 9i.
 Servidor de Aplicaciones - Oracle 9ias.

 Cliente.
 Sistema Operativo Windows 98/XP/2000.
 Browser (Explorer 5.0 o superior)
Se puede ver mejor en el Gráfico Nº 07 Plataforma de Implementación del

Módulo de Archivo Interno:
Plataforma de Implementación del Modulo de Archivo
Gráfico Nº 07
2.8.3.8PLAN DEL PROYECTO

Para la elaboración del presente proyecto, se utilizará la metodología de desarrollo
presentada por GMD y aprobada por la ONP (Metodología de análisis, diseño,
desarrollo e integración de sistemas; Plan de calidad en la construcción de
software).
La metodología propuesta divide el proceso de desarrollo en ciclos, teniendo un

producto al final de cada ciclo. Cada ciclo es dividido en fases y cada fase se
concluye con hitos de control.

En la siguiente tabla mostramos las fases con los principales hitos de control que
se tendrán en el desarrollo del Módulo de Archivo. En cada hito de control se
revisarán los requerimientos definidos para la fase, de tal manera que su
cumplimiento es determinante para continuar con la fase siguiente.
Fase Descripción Hitos

Incepción Durante la fase de Incepción se Modelo del Negocio
desarrollará el modelo de negocio del Documento Alcance
Módulo de Archivo (Use Case). funcional del Sistema
Se definirán los requisitos del sistema a Glosario de términos
desarrollar y se esbozará un plan del Plan de Iteración (todo el
proyecto de alto nivel. proyecto).
Al final de esta fase se tendrá
adecuadamente delimitado el alcance
funcional del sistema.
Elaboración En la fase de elaboración se analizarán Documento de Análisis y
los requerimientos a mayor detalle. Al Diseño del Sistema
finalizar la etapa de elaboración todos los Prototipo
casos de uso seleccionados deberán estar Plan de Iteración C1
analizados y diseñados. ajustado
Asimismo, el prototipo deberá probar la Documento de
factibilidad técnica de alto riesgo y los Implementación
requisitos de desempeño definidos para el Documentos
sistema. Actualizados
Construcción Durante la fase de construcción se La Capacidad Operacional

implementarán los casos de uso de los Releases
analizados y diseñados. Plan de Pruebas
Informe de pruebas
Plan de Iteración C2
Plan de Iteración T1
Documentos
Actualizados

Fase Descripción Hitos

Transición La fase de transición preparará el sistema La Versión 1.0 del Modulo
para su distribución e instalación. Se de Archivo
realizara migración de datos validados y Plan de Migración
estructurados de Archivos de Informe de migración
Calificaciones y Procesos Judiciales. Acta de prueba de
migración
Plan de Pruebas (de
usuario, de sistemas,
integrales, de esfuerzo)
Informe de Pruebas
Acta de Aprobación del plan
de pruebas
Plan de Implantación
Documento de autorización
de Pase a Producción
Plan de Capacitación
Manuales
En la siguiente tabla se muestra la cantidad de iteraciones planeada para cada

una de las fases y el tiempo de duración aproximado.
Fase No Iteraciones Inicio Fin

Incepción 1 Semana 1 Semana 6
Elaboración 1 Semana 5 Semana 14
Construcción 2 Semana 14 Semana 40
Transición 1 Semana 38 Semana 52
Por tanto se tendrá 5 iteraciones agrupadas en 4 fases generales. A

continuación se detalla el objetivo y la lista de actividades por iteración:
6.1 FASE INICIAL O FASE DE INCEPCIÓN
Iteración Preliminar
Objetivos
 Concebir el plan general del proyecto y lograr la aprobación por parte de los usuarios
de la División Usuaria y de la División de Proyectos.
 Identificación de las Necesidades de Usuario.

 Planeamiento y Administración del Proyecto.

Hitos Actividades
Modelo del  Administrar el alcance del proyecto
Negocio  Investigación amplia sobre los procesos de Archivo
 Realización de entrevistas con el usuario
 Conocer las funcionalidades del NSTD-MAT.
 Identificar las necesidades del usuario a partir del levantamiento de
información (analizar el problema).
 Identificar las características del negocio
 Construcción del Modelo de Negocio
 Identificación de los actores del negocio
 Identificación de los trabajadores del negocio
 Identificación de los casos de uso del negocio
 Elaboración del Diagrama de Actores y Trabajadores
 Elaboración del Diagrama de Casos de Uso del Negocio
 Descripción de los casos de uso del negocio
 Elaboración del Diagrama de Actividades
Alcance del  Investigación de temas relacionados al proyecto
Sistema  Plantear objetivos, alcances y descripción del sistema.
 Ajustar / refinar la definición del sistema
 Especificación de los Requerimientos
 Identificación de actividades a automatizar a partir de los diagramas
de actividades del negocio.
 Definir requerimientos en base a las necesidades del negocio
 Definir requerimientos de datos a migrar.
 Definir requerimientos no funcionales
 Construcción del Modelo de Sistema

 Identificación de los actores del sistema
 Identificación de los casos de uso del sistema
 Identificación de los paquetes
 Elaboración del Diagrama de Casos de Uso del Sistema por
paquete
 Descripción general de los casos de uso del sistema
 Priorización de la especificación de los casos de uso

Plan de  Identificar los artefactos concretos y medibles que serán

Iteraciones desarrollados o actualizados y las actividades necesarias para
lograrlo.
 Descomponer las actividades hasta llegar a sub-actividades con una
asignación y responsabilidad clara y una duración controlable.
 Realizar estimaciones para asignar duración y esfuerzo de cada
actividad
6.2 FASE DE ELABORACIÓN
Iteración E1
Objetivos
 Especificación Detallada de Requerimientos
 Desarrollar el análisis y diseño de los casos de uso
 Elaboración del prototipo del sistema
 Administración del Proyecto
Hitos Actividades
Documento de  Elaborar el cronograma de entrevistas para establecer con más
Análisis y detalle las necesidades de información descritas en la fase de
Diseño del incepción.
Sistema  Análisis de las interfaces con otros sistemas.
 Detallar los casos de uso seleccionados
 Construcción del Modelo de Objetos del Sistema
 Definición de las clases entidad, atributos y operaciones
 Elaboración del Diagrama de Clases de Análisis
 Construcción del Modelo de Diseño
 Realización de los casos de uso del sistema
 Elaboración del Diagrama de Secuencia
 Elaboración del Diagrama de Colaboración
 Elaboración del Diagrama de Clases de Diseño
 Identificación de las clases de diseño y sus operaciones
 Construcción del Modelo de Datos
 Elaboración del Diagrama Lógico de Datos
 Elaboración del Diagrama Físico de Datos
 Se definirá la arquitectura (Paquetes y las relaciones entre los

mismos).
Prototipo  Crear el ambiente de desarrollo.
 Se instalará y configurará la base de datos, el servidor de
aplicaciones y las estaciones de desarrollo.
 Construcción del Prototipo de Interfaz de Usuario
 Definición del menú principal del sistema
 Definición de las pantallas de cada caso de uso
 Elaborar el documento de revisión del prototipo.
Plan de  Designar los recursos, objetivos, cronograma de actividades y
Iteración C1 artefactos de la iteración C1.
Documento de  Elaborar el diagrama de componentes. Este diagrama captura la
Implementación estructura física de la implementación.
 Elaborar el diagrama de distribución. Este diagrama captura la
topología del hardware del sistema.
Documentos  Actualizar el documento de alcance del sistema vs2
Actualizados  Glosario de términos actualizado vs2
6.3 FASE DE CONSTRUCCIÓN
Dado que existe el requerimiento por parte de los usuarios de priorizar la

sistematización del Proceso de Archivo se ha decidido desarrollar el sistema
en 3 etapas de la siguiente manera:
 Etapa 1 (INTEGRACION DE ARCHIVO DE CALIFICACIONES Y

PROCESOS JUDICIALES) - Casos de uso correspondientes a los
procesos de Archivo de Calificaciones y Archivo de Procesos Judiciales.
Este se desarrollará en 2 iteraciones denominadas C1, C2.
 Etapa 2 (INTEGRACION DE ARCHIVO DE DEPARTAMENTALES,

ARCHIVO DE PENSIONES Y ARCHIVO DE RECAUDACIÓN) - Casos de
uso correspondientes a los procesos de Archivo de Departamentales,
Archivo de Pensiones y Archivo de recaudación. Esta etapa se
programara después de la culminación de la primera etapa.
 Etapa 3 (INTEGRACION DE ARCHIVO DE RECONOCIMIENTO) - Casos

de uso correspondientes a los procesos de Archivo de Reconocimiento.

Esta etapa se programara después de la culminación de la segunda

etapa.
Etapa 1
Iteración C1 – Gestión de Documentos
Objetivos
 Desarrollo de la iteración C1
 Entregar la iteración C1 para pruebas por el usuario.
Entregable Actividades
Iteración C1  Refinar el análisis y diseño de los casos de uso correspondientes.
(Código  Implementar los casos de uso correspondientes a la iteración C1
fuente,  Implementación del menú principal del sistema
Ejecutables,  Implementación de las precondiciones de los casos de uso
Compilado)  Implementación del flujo básico de los casos de uso
 Implementación del flujo alternativo de los casos de uso
 Implementación de las poscondiciones de los casos de uso.
 Realizar Pruebas unitarias.
Plan de  Planificar y diseñar las pruebas
Pruebas  Estimar los recursos necesarios para las pruebas
 Definir los casos de prueba
Iteración artefactos de la iteración C2.
Documentos  Actualizar el Documento de Implementación vs2
Actualizados  Actualizar el Documento de Análisis y Diseño vs2
 Actualizar documento alcance de sistema vs3
 Actualizar glosario de términos vs3
Iteración C2 – Interfase, Consultas y reportes

Objetivos
 Desarrollo de la iteración C2
 Entregar la iteración C2 para pruebas por el usuario.
Iteración C2  Refinar el análisis y diseño de los casos de uso correspondientes.
(Código  Implementar los casos de uso correspondientes a la iteración C2
fuente,  Implementación del menú principal del sistema
Ejecutables,  Implementación de las precondiciones de los casos de uso
Compilado)  Implementación del flujo básico de los casos de uso

 Implementación del flujo alternativo de los casos de uso

 Implementación de las poscondiciones de los casos de uso.
 Realizar Pruebas unitarias.
Plan de  Planificar y diseñar las pruebas
Pruebas
 Estimar los recursos necesarios para las pruebas
 Definir los casos de prueba
Iteración
artefactos de la iteración T1.
Documentos  Actualizar el Documento de Implementación vs3
Actualizados
 Actualizar el Documento de Análisis y Diseño vs3
 Actualizar documento alcance de sistema vs4
 Actualizar glosario de términos vs4
La iteración C1 comprende el desarrollo de los módulos relacionados con la

gestión de los documentos del Módulo de Archivo Interno.
La iteración C2 comprende el desarrollo de los módulos de Consultas,

Reportes y las interfases con otros sistemas operativos de los archivos
correspondientes a la etapa 1.
6.4 FASE DE TRANSICIÓN
Se ha decidido desarrollar la fase de transición del sistema de la primera

etapa de la siguiente manera:
 Se desarrollará en iteración T1.
 Los tiempos de duración de la iteración T1 están definidos en el
cronograma, donde requiere de participación activa del usuario
comprometido de ONP.
Etapa 1
Iteración T1 – Calificaciones – Procesos Judiciales
Objetivos
 Migración de la data de los Archivos de Calificaciones y Procesos Judiciales
 Pruebas Funcionales, Técnicas, Integrales, de esfuerzo.
Iteración T1  Listar fuentes de migración. Entrega de fuentes
 Entregar la Iteración T1 de la etapa 1 asegurando la aceptación del
mismo por parte de los usuarios finales.
Documentos  Plan de migración

 Informe de ejecución de la migración

 Elaboración del Plan de Pruebas
 Informe de ejecución de Pruebas
 Elaborar el plan de implantación de la iteración T1 de la etapa
1
 Elaborar el documento de autorización de pase a producción
 Plan de Capacitación
 Manuales
2.8.3.9ORGANIZACIÓN DEL PROYECTO
6.1 ESTRUCTURA ORGANIZACIONAL

La gestión del proyecto estará a cargo de Jefe de Sistemas del Proveedor y
del Coordinador del Proyecto de ONP y, el desarrollo del sistema a cargo de
un equipo de desarrollo del Proveedor. Así mismo como parte de la
estandarización y mejoramiento del proceso de desarrollo se contará con un
Analista de Base de Datos y un Analista de Control de Calidad para el
aseguramiento de la calidad del proceso de elaboración del software.
Los roles principales que se han considerado en la organización del proyecto
son los siguientes:
Personal administrativo
 Jefe de Sistemas
Personal Operativo
 Analista de Control de Calidad
 Analista de Base de Datos
 Analista de Sistemas
 Analista Programador 1
 Analista Programador 2
 Documentador
Según la estructura de la organización se irá incorporando recursos
necesarios según la fase en la cual se encuentre el proyecto, la organización

estructural del grupo del proyecto se puede ver en el Gráfico Nº 08 Estructura

Organizacional del grupo de Desarrollo.
Estructura Organizacional del grupo de Desarrollo
Jefe de Sistemas
(5%)
Analista de Control
de Calidad (15%)
Analista de Base de
Datos (10%)
Analista de Sistemas
(100%)
Documentador
(50%)
Analista Programador 1 Analista Programador 2
(100%) (100%)

Gráfico Nº 08
6.2 ROLES Y FUNCIONES DEL EQUIPO DE TRABAJO.
Las siguientes tablas describen los roles y las responsabilidades definidos en

la estructura organizacional.
Tabla Nº 01 Roles y Responsabilidades ONP

%
Nro. Rol Cant. Responsabilidad
Dedicación
01 Jefe de la 01 Patrocinar el Proyecto para alcanzar el
División de objetivo deseado.
5
Proyectos
Carmen López
02 Coordinador de 01 Coordinar con las áreas usuarias y con
Proyectos GMD las reuniones necesarias para 5
Alfonso Zuazo cumplir con los objetivos del Proyecto.
03 Coordinador de 01 Supervisar el cumplimiento estándar de
Sistemas desarrollo del sistema a desarrollarse.
5
Claudia
Oneeglio
04 Líder Usuario de 01 Brindar información a los
División de requerimientos funcionales de los
Calificaciones procesos de archivo y supervisar las 5
Zadí Anaya pruebas funcionales de la División de
Calificaciones
05 Líder Usuario de 01 Brindar información a los
División de requerimientos funcionales de los
Procesos procesos de archivo y supervisar las
5
Judiciales pruebas funcionales de la División de
Maria del Procesos Judiciales.
Carmen Núñez
Tabla Nº 02 Roles y Responsabilidades GMD

%
Dedicación
01 Jefe de 01  Supervisar en forma directa la 5
Sistemas ejecución del Plan detallado del
Enrique Proyecto.
Camarena  Administrar y controlar los recursos
que se asignen para el proyecto.
 Controla que el Proyecto se lleve a
cabo en los plazos previstos y con
la calidad adecuada.

%
Dedicación
02 Analista de 01  Establecer un Plan para la gestión 15
Control de de la calidad que permita asegurar
Calidad la calidad en el proceso de
Luís Pérez software.
Godoy  Analizar el control de calidad del
desarrollo del Proyecto.
(Revisor de  Proponer y optimizar puntos de
Requerimientos, control en el desarrollo del
Diseñador de Proyecto.
Pruebas y  Establecer las normas y estándares
Probador de de calidad pertinentes con el fin de
Sistema) garantizar la eficacia del desarrollo
del sistema.
 Realizar Auditorias de Calidad
durante el desarrollo del sistema.
 Determinar el plan de pruebas a
llevarse a cabo en el desarrollo del
sistema.
03 Analista de Base 01  Instalación, configuración, 10

de Datos afinamiento y administración del
Arturo Saravia Servidor de Base de Datos de
Desarrollo.
 Participar en el diseño e
implementación del modelo de
datos del aplicativo
 Participación en el Pase a
Producción del Sistema
04 Analista de 01  Participar y supervisar la ejecución 100
Sistemas del plan detallado del proyecto.
Responsable  Manejar adecuadamente la relación
Francisco con la contraparte técnica y los
Orosco Bailón usuarios.

%
Dedicación
 Identificar, diseñar, implementar y
(Arquitecto de dar soporte a los procesos y/o
Uses Cases, procedimientos que requieren
Especificador de mecanizarse o mejorarse.
Uses Cases,  Administrar y controlar los recursos
Revisor de que se le asignen para el
Requerimientos, cumplimiento de sus labores.
Arquitecto,  Supervisar que la documentación
Diseñador de del sistema esté debidamente
Uses Cases, actualizada.
Diseñador y  Sostener reuniones periódicas con
Diseñador de las áreas usuarias.
pruebas.)  Determinar y especificar los casos
de uso.
 Establece la estructura total de la
vista de la arquitectura.
 Verifica que los resultados de los
requerimientos sean conformes a la
vista del cliente
 Planea y conduce la revisión formal
del modelo de caso de uso.
 Responsable de la elaboración
detallada de los casos de usos
 Define las responsabilidades,
operaciones, atributos y relaciones
de las clases, y determina como
serán implementadas.
05 Analista 02  Participar en el diseño técnico del 100

Programador Sistema.
Roy Alonzo,  Efectuar la programación
Roosevelt Baca cumpliendo con los estándares.
 Elaborar la documentación técnica
del Sistema.

%
Dedicación
 Participar en la definición del
Documento Prototipo del Sistema.
 Realizar la Implementación del
Sistema.
 Responsable de realizar las
pruebas de los componentes los
cuales deben ajustarse a los
estándares del proyecto.
06 Documentador 01  Elaborar y/o actualizar los 50

Rosario Zevallos documentos relacionados con el
Desarrollo de Sistemas ( manual de
administración e instalación,
manual de especificación de
programas, manual de sistemas,
manual de usuario y otros que se
definan) atendiendo los estándares
establecidos por ONP.
 Informar al Analista de Sistemas
sobre el avance de las actividades
de actualización de manuales y
sobre problemas funcionales
encontrados durante la
actualización de la documentación
del Proyecto.
6.3 REUNIONES DE CONTROL Y LÍNEAS DE COMUNICACIÓN

Para el control de avances del proyecto y el cumplimiento del cronograma de
actividades se realizarán reuniones de trabajo las cuales deberán ser
definidas entre ONP y GMD (pudiendo ser éstas semanales o quincenales).
Comité de Sistemas:

Se reunirá semanalmente, con la finalidad de coordinar las acciones propias

del desarrollo, analizar los componentes del sistema y evaluar el avance de
resultados.
El Comité de Sistemas del Proyecto estará conformado:
Por ONP:
 Jefe de la División de Proyectos: Carmen López.
 Coordinador del Proyecto: Alfonso Zuazo.
 Coordinador de Sistemas: Claudia Oneeglio
 Líder Usuario de División de Calificaciones: Zadí Anaya
 Líder Usuario de División de Procesos Judiciales: Maria del Carmen
Núñez
Por GMD:
 Jefe de Sistemas: Enrique Camarena.
 Analista Funcional: Hector Henriquez
 Analista de Sistemas: Francisco Orosco Bailón
Responsabilidades del Comité de Sistemas

 Tomar las medidas correctivas necesarias, para corregir los retrasos y
problemas que hubieren en el Proyecto.
 Discernir las discrepancias y dudas que surjan durante el desarrollo del
proyecto e informar su decisión al equipo de trabajo. En caso de no existir
acuerdo de ambas partes, este Comité deberá elevar el tema al Comité
Operativo para que éste tome una decisión final.
 Debe resolver y/o aprobar o rechazar las solicitudes de modificación y/o
adaptación del plan del proyecto que el equipo de trabajo someta a su
consideración.
 Aprobar los documentos y entregables del proyecto.

Estructura Organizacional del Comité de Sistemas
Gráfico Nº 11
Se establecen las siguientes líneas de comunicación del proyecto:

 Cartas
Cualquier comunicación formal al interior del proyecto realizado se hará a
través de cartas las cuales tendrá la firma respectiva de los líderes de
proyecto definidos por ONP.
En el caso de GMD será el Gerente de Proyecto: José Gálvez.
Y en el caso de ONP será el Jefe de la División de Proyectos: Carmen
López
 Actas de Comité
Las reuniones serán documentadas a través de Actas de Reunión,
anotándose todos los acuerdos entre ONP y GMD.
 Correo Electrónico
Una parte de la comunicación formal al interior del proyecto se hará
través de correo electrónico que es correspondencia interna entre la ONP
y GMD que tiene el propósito de agilizar y comunicar algún aspecto
formal del proyecto.

 Informes
Los informes son acompañados por una carta a fin de detallar algún
punto específico.
 Cronograma de avances
Es un cronograma de actividades con fechas programadas y fechas de
ejecución que permite controlar el avance diario de actividades. Será
actualizado y presentado por GMD a ONP en los Comités de Sistemas
y/o cuando se solicite.
 Informes de Avance
En el informe de avances se indicara la situación real versus lo planeado,
indicando los retrasos y pronósticos para la siguiente semana o
quincena.
2.8.3.10 CRONOGRAMA DE ACTIVIDADES.

El tiempo empleado en la construcción de la etapa 1 es de 217 días hábiles. Se
puede ver en el Anexo 01 el detalle del Cronograma de Actividades del Modulo de
Archivo Interno. Todo cambio de Cronograma de actividades y Alcance serán
coordinados en Comité de Sistemas y aprobados por el Comité Operativo.
2.8.3.11 ENTREGABLES
Se considerará la entrega de los documentos tomando como base la metodología
propuesta por GMD para el presente Proyecto. Se puede ver en el Anexo 02 el
detalle de los entregables del Módulo de Archivo Interno.
A continuación se detallan los documentos y productos que se entregarán por

cada fase (El formato de cada uno de los documentos está planteado en la
metodología propuesta por GMD):
6.1 INCEPCIÓN (INICIO)

a) Plan de Trabajo del Proyecto
b) Cronograma de Reuniones con Usuarios

c) Documento de Modelo de Negocio. Este documento, nos permite

tener una visión del proceso del negocio, comprende los siguientes
puntos:
- Visión del negocio
- Diagrama de caso de uso de negocio
- Diagrama de actividad del negocio (actual y optimizado).
- Diagrama de Actores del negocio
d) Documento de Alcance del Sistema (Versión 1). Este
documento define qué se encuentra dentro y qué se encuentra
fuera del sistema a desarrollar. Contiene los requisitos a ser
considerados en el sistema y comprende los siguientes puntos:
- Lista de requerimientos funcionales y no funcionales.
- Especificación de casos de uso
- Catálogo de normas
e) Glosario de Términos (Versión 1). Este documento contendrá las
definiciones de términos propios del negocio
f) Plan de Iteración E1. En este documento se designarán los
recursos, objetivos, cronograma general de actividades y artefactos
de las iteraciones definidas.
6.2 ELABORACIÓN
a) Cronograma de Reuniones con Usuarios
b) Documento de Análisis y Diseño (Versión 1). Este documento
mostrará cómo el sistema será desarrollado en la fase de
implementación. Incluirá los siguientes puntos:
- Modelo de Caso de Uso
- Modelo de Clases
- Modelo de Comportamiento. En este modelo se considera
realizar los diagramas de actividad y los diagramas de estados.
- Modelo de Interacción. Se elaborarán los siguientes diagramas:
o Diagrama de secuencia
- Diagrama de interacción
- Modelo de Datos
o Modelo Entidad Relación E/R
o Diccionario de Datos

- Diseño de Interfaz de Usuario

- Descripción de Interfaz con otros sistemas
c) Documento de revisión de prototipo. En este documento se
especificará los acuerdos tomados luego de la revisión del
prototipo con los usuarios.
d) Documento de implementación. Este documento comprenderá el
Diagrama de Componentes y el Diagrama de Distribución.
e) Entrega de Estructura de Código de Barras por cada tipo de
Documento
f) Glosario de términos Actualizado (Versión 2)
g) Documento de Alcance del Sistema Actualizado (Versión 2)
h) Plan de la iteración C1
6.3 CONSTRUCCIÓN
Al finalizar la iteración C1 se entregarán los siguientes documentos:
a) Documento de Análisis y Diseño del Sistema Actualizado
(Versión 2).
b) Documento de Implementación (Versión 2).
c) Documento de alcance de sistema actualizado (Versión 3)
d) Glosario de términos actualizados (Versión 3)
e) Código fuente del Sistema y código compilado. Se incluye la
información de la Base de Datos Diseñada.
f) Plan de Pruebas.
g) Informe de pruebas. Este documento detalla el resultado de las
pruebas funcionales y de sistemas indicando los usuarios que
participaron en ellas y las observaciones que hubieran.
h) Plan de la iteración C2
Al finalizar la iteración C2 se entregarán los siguientes documentos:

a) Documento de Análisis y Diseño Sistema Actualizado (Versión
3).
b) Documento de Implementación (Versión 3).
c) Documento de alcance de sistema actualizado (Versión 4)
d) Glosario de términos actualizados (Versión 4)

e) Código fuente del Sistema y código compilado. Se incluye la

información de la Base de Datos Diseñada.
f) Plan de Pruebas.
g) Informe de pruebas. Este documento detalla el resultado de las
pruebas funcionales y de sistemas indicando los usuarios que
participaron en ellas y las observaciones que hubieran.
h) Plan de la iteración T1
6.4 TRANSICIÓN
Al finalizar la iteración T1 se entregarán los siguientes documentos:
a) Plan de migración
b) Entrega de la Información para Migración
c) Informe de las pruebas de migración. Este documento detalla el
resultado de las pruebas de migración de datos y de sistemas
indicando los usuarios que participaron en ellas y las
observaciones que hubieran.
d) Fuentes de migración
e) Plan de Pruebas. Este documento detalla el diseño de las pruebas
funcionales, de sistemas y de esfuerzo (simuladas y en vivo) que
se realizarán, los formatos a utilizar y los responsables de la
ejecución de las pruebas.
f) Informe de pruebas. En este documento se detallará los
resultados obtenidos de acuerdo al tipo de prueba: Funcionales,
Sistemas, Esfuerzo.
g) Plan de pase a QA y pase a Producción
h) Documento de Plan de Pase a QA y Pase a Producción.
i) Plan de capacitación
j) Informe de la capacitación
k) Plan de implantación.
l) Documento de autorización de pase a QA y a Producción
m) Entrega del código, fuentes y librerías
n) Manuales
- Manual del Sistema Actualizado
- Manual de Usuario Actualizado
- Administración e Instalación

2.8.3.12 ADMINISTRACIÓN DE RIESGOS
El alcance de la administración de riesgos comprende la identificación de los

eventos que pueden afectar el normal desarrollo del presente plan de trabajo.
Para el mejor entendimiento de la lista de riesgos a continuación se explicarán
los criterios utilizados para establecer los valores en el nivel de probabilidad y
en el nivel de impacto.
a) Nivel de probabilidad.
Consiste en la probabilidad de que ocurra el riesgo, los posibles valores
son: Baja, Media, Alta. En la siguiente tabla se muestra la correspondencia
entre el nivel de probabilidad y el rango de probabilidad:
Nivel de probabilidad Rango de

probabilidades
Baja 0% a 33%
Media 34% a 66%
Alta 67% a 100%
b) Nivel de impacto
Es cuanto representaría el riesgo en tiempo en el caso de que ocurriese.
Los posibles valores se explican en la siguiente tabla:
Nivel de impacto Tiempo de impacto

Bajo Atrasos de 1 día
Medio Atrasos de 2 a 3 días
Alto Atrasos de 4 a 7 días
Muy Alto Atrasos de 8 a más
días
A continuación se describe los posibles riesgos y las acciones preventivas

para evitar que se presenten así como las acciones correctivas en caso
ocurran para minimizar el impacto en la ejecución del plan de trabajo y el
cronograma de actividades.
Identificación de Riesgos
Ítems Descripción Nivel de Nivel de

Probabilidad Impacto
 Ausencia de algunos miembros Baja
R1 Media
involucrados del sistema a desarrollar.
 Pérdida de información Baja
R2 Alta
relacionada al desarrollo del sistema.
 Ausencia de los usuarios en las Baja
R3 Alta
reuniones.
 Falta de aprobación de algún Baja
R4 Alta
documento o hito.
 Ausencia del programador como Baja
R5 Media
recurso del equipo.
 Ausencia del analista como Baja
R6 Alta
recurso del equipo.
 Participación insuficiente de los Media
R7 Alta
usuarios
R8  Deficiencia en el análisis y diseño Alta Alta
 Deficiencia en el levantamiento de Alta
R9 Alta
información.
 Deficiencia en el modelo de Alta
R10 Alta
negocio
Acciones Preventivas
Riesgo Acción Observación

 Aviso previo de ausencia
temporal.
Ausencia de  Nombrar al personal de

algunos miembros reemplazo.
involucrados del Ninguna
sistema a  Transferencia de
desarrollar. conocimientos, información,
documentos y programas al
personal sustituto.
Pérdida de
información
 Respaldo diario y
relacionada al semanal de la información, Ninguna
desarrollo del
sistema. documentos y programas.
Acciones Correctivas
Riesgo Acción Observación

 Transferencia de
conocimientos al personal de Compromiso del
Ausencia de reemplazo, mediante la personal de

algunos miembros capacitación y entrega de transferir su
involucrados del
sistema a todos los documentos de conocimiento, en
desarrollar. trabajo, previa explicación del caso de dejar la
negocio. empresa.
 Restaurar la última copia Copias de respaldo

Pérdida de
de respaldo, realizando una de la información en
información
relacionada al copia y guardándolos en el CD’s y el dispositivo
desarrollo del
servidor. de almacenamiento
sistema.
del servidor.
2.8.3.13 ACTIVIDADES DE CONTRAPARTE

Es responsabilidad de la ONP lo siguiente:
- Designar al Líder(es) Usuario del Proyecto y al Líder Alterno
- Designar al o los usuarios responsables de realizar las pruebas de
sistema, de acuerdo con los planes que GMD presentará durante el
servicio.
- ONP deberá de asegurar la designación de los líderes usuarios, a través
de los cuales se coordinará la ejecución de las reuniones de coordinación
para la captura y validación de la información, así como la validación de
las pruebas funcionales.
- Participación activa de Usuarios
- La ONP a través de sus líderes usuarios deberá asegurar la asistencia de
los usuarios involucrados a todas las reuniones programadas en las
diversas etapas del proyecto de acuerdo con lo establecido en el
cronograma de trabajo.
- Durante esta etapa la ONP deberá evitar ausencias de los usuarios
involucrados por concepto de vacaciones, licencias, comisiones de
servicio, entre otros que ocasionen retrasos en el proyecto.
- Designar al coordinador de Proyecto o responsable de las coordinaciones
con GMD y que representará a la ONP en el Comité de Coordinación.

- Aprobar los entregables emitidos en cada fase del proyecto (Actas de

reunión, Documento de Alcance Funcional (requerimientos de
información), Documento de Análisis y Diseño) de acuerdo con el
cronograma del proyecto. Cualquier retraso ocasionado por la no-
aprobación de los entregables deberá ser evaluado por GMD y la ONP
para medir el impacto en el proyecto.
- Cualquier cambio que afecte a los requerimientos de información ya
definidos, se deberá de trabajar con un manejo de cambios, en el cual
GMD y la ONP deberán de evaluar el impacto y los costos que involucren
los cambios requeridos.
2.8.3.14 CONTROL DE CAMBIOS DEL ALCANCE Y PLAN DEL

PROYECTO
El alcance del Proyecto varía en las siguientes fases de desarrollo:
FASE DE INCEPCIÓN
Elaboración del documento alcance del sistema (vs1)
FASE DE ELABORACIÓN
Actualización del documento alcance del sistema (vs2)
FASE DE CONSTRUCCIÓN
Iteración C1
Iteración C2
Indicar como se va a realizar los cambios en el alcance, las aprobaciones de

ampliación se realizan en el comité de sistemas y/o comité operativo
dependiendo de la magnitud del cambio.
2.8.3.15 ANEXOS
ANEXO 01: CRONOGRAMA DETALLADO DE ACTIVIDADES

ANEXO 02: MATRIZ DE ENTREGABLES


Plan de Trabajo Mai V 1.0

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Plan de Trabajo Mai V 1.0

Încărcat de

Drepturi de autor:

Formate disponibile

PROYECTO

MÓDULO DE ARCHIVO INTERNO

CP 0001 – 2005 / ONP

NUEVO SISTEMA DE TRÁMITE DOCUMENTARIO

GMD S.A. - ONP

Revisión: 01 GMD - 2005 Página: 2 / 56

Autores: Revisión GMD:

Revisión: 01 GMD - 2005 Página: 3 / 56

Revisión: 01 GMD - 2005 Página: 4 / 56

Revisión: 01 GMD - 2005 Página: 5 / 56

Revisión: 01 GMD - 2005 Página: 6 / 56

La Oficina de Normalización Previsional (ONP), en el marco del Servicio de

Para el desarrollo del MAI, módulo perteneciente al Nuevo Sistema de Trámite

El cumplimiento de las pautas establecidas en sus diferentes fases, permitirá asegurar

Revisión: 01 GMD - 2005 Página: 7 / 56

La metodología de desarrollo (RUP), implica cuatro fases: Incepción, Elaboración,

El Módulo de Archivo será entregado en un período de tiempo de 11 meses, con la

El tiempo estimado de desarrollo del Módulo de Archivo Interno, supera lo considerado

Revisión: 01 GMD - 2005 Página: 8 / 56

Revisión: 01 GMD - 2005 Página: 9 / 56

El presente documento describe los lineamientos para el desarrollo del Módulo

2.8.3.2OBJETIVO DEL PLAN

Establecer los lineamientos para el logro del proyecto, considerando las

La Gerencia de Desarrollo es el órgano de soporte responsable de brindar el

El Módulo de Archivo Temporal (MAT), está integrado y contenido en el Nuevo

Debido a la política de integración de procesos, los diferentes archivos de la

Revisión: 01 GMD - 2005 Página: 10 / 56

El Módulo de Archivo Interno (MAI) del Sistema de Trámite Documentario del

La funcionalidad actual del módulo MAT se extenderá a la nueva solución y se

Como parte de la integración de Archivos, el MAT dejará de dar soporte solo al

2.8.3.4OBJETIVO DEL PROYECTO

El presente proyecto tiene como objetivo contar con un Módulo de Archivo

El presente Proyecto considera el desarrollo del Módulo de Archivo Interno

- Archivo de Procesos Judiciales

Revisión: 01 GMD - 2005 Página: 11 / 56

El presente Plan de Trabajo considera la implementación de la etapa I, esto es

Revisión: 01 GMD - 2005 Página: 12 / 56

funcionalidad operativa de los procesos de ONP; sin embargo, se debe

2.8.3.6DESCRIPCIÓN DEL SISTEMA

El Módulo de Archivo Interno permitirá realizar lo siguiente:

Revisión: 01 GMD - 2005 Página: 13 / 56

- Realizar automáticamente el control topográfico por cada archivo,

En la fase de Incepción de la Metodología de Desarrollo de Sistemas, se

6.1.1 PEDIDOS DE DOCUMENTOS

Revisión: 01 GMD - 2005 Página: 14 / 56

Se parametriza el tipo de documento que solicita cada usuario del

6.1.2 BANDEJA DE PEDIDO ARCHIVOS

Para los documentos que son gestionados por el NSTD, la

6.1.3 BANDEJA DE UNIDADES ORGANIZACIONALES

6.1.4 BANDEJA DE SUPERVISORES

6.1.5 CRUCE DE DOCUMENTOS

Revisión: 01 GMD - 2005 Página: 15 / 56

si están disponibles o no en el archivo. Para esto la data se cargará

6.2 CONSULTAS DE DOCUMENTOS

6.2.2 HOJA DE LOTE

6.2.3 HOJA DE RUTA

6.3 INGRESO DE DOCUMENTOS

6.4 REPORTES DE ATENCIÓN

Revisión: 01 GMD - 2005 Página: 16 / 56

 Atención de los requerimientos por el nombre del pedido:

Revisión: 01 GMD - 2005 Página: 17 / 56

 Permanencia de los Expedientes: permite visualizar la

También se implementarán reportes determinados por el usuario de