Está en la página 1de 108

UNIVERSIDAD NACIONAL DEL CENTRO DEL PERÚ

ESCUELA DE POSGRADO

UNIDAD DE POSGRADO DE LA FACULTAD DE


INGENIERÍA DE SISTEMAS

TESIS
Desarrollo e Implementación del Sistema de Tramite
Documentario en la Municipalidad Provincial de
Huancayo para la atencion de expedientes.

PRESENTADA POR:
JAVIER BASTIDAS PARRAGA

Para optar el Grado Académico de:

Magister en Ingeniería de Sistemas


Con mención en
Gerencia de Tecnologías de Información y
Comunicaciones

Huancayo - Perú

2016
ASESOR

Mg. Richard Yuri Mercado Rivas

i
DEDICATORIA

A mis padres, a quienes amo y respeto, gracias a su ejemplo, apoyo, dedicación


y abnegado esfuerzo han sabido guiar mi vida, en el transcurso de mi carrera
profesional y en mi vida.

ii
AGRADECIMIENTO

A todas las personas que me han apoyado y de los cuales estoy infinitamente
agradecido y sigo creciendo en muchos aspectos importantes de mi vida y lo
seguiré haciendo en el transcurso de mi existencia.

iii
RESUMEN

Este trabajo de tesis denominada “Desarrollo e Implementación del Sistema de


Tramite Documentario en la Municipalidad Provincial de Huancayo para la
atención de expedientes” se realizó con el objetivo de mejorar la gestión de
trámite documentario, con especial énfasis en las consultas realizadas antes y
durante la tramitación de documentos de importancia presentados por los
ciudadanos y recepcionados por la Unidad de Trámite Documentario y Archivo.

Se investigó en la Municipalidad Provincial de Huancayo, Departamento Junín.


La zona pertenece al Distrito de Huancayo,. La afluencia de ciudadanos que
visitan directamente la Unidad de Trámite Documentario es en promedio
mensual de 4,000 personas, ya sea para consultas recepción o entrega de
documentos.

Las muestras usadas dentro de la investigación permitieron extraer información


de la problemática antes y después de la solución a implantar. La primera
población es en promedio calculada según la afluencia concurrida en el periodo
2006 de 3,856 por mes y del periodo 2015 de 4,434 por mes, se procedió a
procesar esta información para poder abstraer las necesidades y poder lograr
satisfacer estas necesidades como una alternativa de solución.

La presente investigación sobre el desarrollo del Sistema de Tramite


Documentario para procesar información, se concluye que los tiempos en
atención de expedientes se redujo en aproximadamente un 30% con respecto al
sistema anterior, además representa el primer estudio longitudinal documentado
referente al desarrollo de software que se realiza en la Municipalidad Provincial
de Huancayo – Junín.

iv
ABSTRACT

This dissertation entitled "Development and Implementation of the System of


Document Processing in the Provincial Municipality of Huancayo to the attention
of Records" was performed with the objective of improving the management of
documentary process, with special emphasis on consultations before and during
the processing of important documents submitted by citizens and received by the
Unit of Processing Documents and File.

This investigation was developed in the Provincial Municipality of Huancayo,


Junín. The area belongs to the District of Huancayo. The influx of citizens who
directly visit the Unit of Processing Documents and File is a monthly average of
4,000 people, either for consultation, receipt or delivery of documents.

The samples used in the research allowed the problem to extract information from
before and after the solution to be implemented. The first population is on average
calculated by the busy influx in the period 2006 to 3,856 per month and the period
2015 to 4,434 per month, we proceeded to process this information to abstracting
needs and to achieve these needs as an alternative solution.

This research on the development of Document Processing System for


processing information, it is concluded that the time care records was reduced by
approximately 30% compared to the previous system, also it represents the first
documented longitudinal study concerning the development of software that is
made in the Provincial Municipality of Huancayo, Junín.

v
INDICE

DEDICATORIA ii
AGRADECIMIENTO iii
RESUMEN iv
ABSTRACT v

INTRODUCCION 1

CAPITULO I
PLANTEAMIENTO DEL PROBLEMA

1.1 IDENTIFICACION Y DETERMINACION DEL PROBLEMA. 2

1.2 FORMULACION DEL PROBLEMA 3


1.2.1 Problema General 3
1.2.2 Problema Especifico 3

1.3 OBJETIVOS. 3
1.3.1 Objetivos General 3
1.3.2 Objetivos Específicos 3

1.4 JUSTIFICACION E IMPORTANCIA. 4


1.4.1 Justificación Teórica 4
1.4.2 Justificación Metodológica 4
1.4.3 Justificación Practica 6
1.4.4 Importancia 6

1.5 SISTEMA DE HIPOTESIS 7


1.5.1 Hipótesis. 7
1.5.2 Operacionalización de variables e indicadores de la hipótesis. 8

vi
CAPITULO II
MARCO TEORICO
2.1 INTRODUCCION 9
2.2 MARCO REFERENCIAL O ANTECEDENTES. 32
2.3 MARCO CONCEPTUAL. 34
2.4 MARCO LEGAL 37

CAPITULO III
METODOLOGIA
3.1 TIPO DE INVESTIGACION 39
3.2 DISEÑO DE LA INVESTIGACION 39
3.3 POBLACION Y MUESTRA 39
3.4 METODO DE INVESTIGACION 40
3.5 TECNICAS E INSTRUMENTOS DE RECOLECCION DE 40
DATOS
3.6 TECNICAS DE PROCESAMIENTOS DE DATOS 41
3.7 SELECCIÓN Y VALIDACION DE LOS INSTRUMENTOS DE 41
MEDICION

CAPITULO IV
DESARROLLO DEL SISTEMA DE TRÁMITE DOCUMENTARIO
4.1 ANTECEDENTES 43
4.2 ANALISIS DE LA SITUACION ACTUAL 45
4.3 MODELO DEL SISTEMA DE TRAMITE DOCUMENTARIO 50
4.4 DESARROLLO DEL SISTEMA DE TRAMITE 58

CAPITULO V:
RESULTADOS Y DISCUSION
5.1 PRESENTACION DE RESULTADOS 76
5.2 VALIDACION DE HIPOTESIS 77
5.3 DISCUSION DE RESULTADOS 80

vii
CONCLUSIONES 83
RECOMENDACIONES 84
REFERENCIAS BIBLIOGRAFICAS 85
ANEXOS 86

ANEXO N° 1 Resultados de Media de tiempos de expedientes 87


atendidos (Fuente SPS)
ANEXO N° 2 Resultados del Proceso de Encuesta (Fuente SPS) 90
ANEXO N° 3 Muestra de expedientes de los periodos 2006-2015 91
ANEXO N° 4 Encuesta de satisfacción sobre el sistema de tramite 95
documentario
ANEXO N° 5 Prueba piloto de tiempos de respuesta del periodo 96
2006-2015
ANEXO N° 6 Procesos más comunes de la oficina de tramite 97
documentario y su respectiva codificación

viii
ÍNDICE DE GRÁFICOS Y TABLAS

Figura N° 1 Diagrama de UML 23


Figura N° 2 Objetivos del UML 24
Figura N° 3 Diagrama de Casos de Uso 25
Figura N° 4 Diagrama de Objetos 26
Figura N° 5 Diagrama de Secuencia 27
Figura N° 6 Diagrama de Colaboración 28
Figura N° 7 Diagrama de Estados 29
Figura N° 8 Diagrama de Actividades 30
Figura N° 9 Diagrama de Componentes 31
Figura N° 10. Diagrama de Despliegue 32
Figura N° 11 Distribución de red e Internet 46
Figura N° 12 Pantalla principal de acceso al Sistema Anterior 47
Figura N° 13 Distribución de los archivos en el sistema anterior 48
Figura N° 14 El sistema anterior no trabaja en línea con las cajas 49
Figura N° 15 Flujo grama de expedientes del sistema anterior 50
Figura N° 16 Caso de Uso Validar Usuario 51
Figura N° 17 Caso de Uso Atención del Documento 52
Figura N° 18 Caso de Uso Registro de Documento 53
Figura N° 19 Caso de Uso Consulta de Información 54
Figura N° 20 Diagrama de Secuencia de Proceso de Registro 55
Figura N° 21 Diseño de Funcionamiento del Sistema 57
Figura N° 22 Diagrama de Base de Datos de Tramite Documentario 60
Figura N° 23 Acceso al Sistema 68
Figura N° 24 Menú Principal 69
Figura N° 25 Registro de Expedientes 70
Figura N° 26 Buscar Contribuyente 71
Figura N° 27 Reporte de expediente entregados 72
Figura N° 28 Reporte de Estado de Expediente 73
Figura N° 29 Código Fuente de Acceso al Sistema 74
Figura N° 30 Código Fuente de Registro de Expedientes 75
ix
Tabla N° 1 Media de tiempos en atención de expedientes. 76
Tabla N° 2 Satisfacción del usuario interno sobre el sistema 77
Tabla N° 3 Resultados de las pruebas, media de tiempos y rangos 81
de días para atención de expediente.
Tabla N° 4 Resultados de las pruebas de hipótesis. 82

x
INTRODUCCION

Hoy en día muchas empresas privadas y del estado no usan un software en el


desarrollo de sus sistemas de información debido a la falta de información que
tienen de estos, con grandes ventajas que proporciona el software de gestión,
una de las más importantes en la que se centran las Gerencias en la toma de
decisiones.

Otra de las causas de mayor relevancia es el miedo al cambio de herramientas


de desarrollo por parte de los desarrolladores y con ello se frenan muchas
ventajas en pro de desarrollo en la institución.

En este trabajo resalto la importancia del desarrollo ya que me permitió reforzar


mis conocimientos teóricos con experiencia práctica institucional, ya que ello ha
valido como instrumento de contraste en el aspecto práctico obteniendo
resultados favorables y conocimientos teóricos que posibilitan dar solución ante
los problemas presentados.

Por tanto, considero que le esfuerzo que he desplegado en el desarrollo de este


trabajo, ha merecido obtener el informe que ha ustedes presento, el mismo que
demuestra en las practicas la experiencia obtenida para planear soluciones
viables para la institución, por lo cual creo obtener su aprobación unánime.

Javier Bastidas Párraga

1
CAPITULO I:
PLANTEAMIENTO DEL PROBLEMA

1.1.- IDENTIFICACION Y FORMULACION DEL PROBLEMA.

Si es cierto que hoy en día los pobladores de nuestra ciudad, o incluso de


otras ciudades tienden a tener problemas, reclamos o permisos a la
institución máxima de dicha ciudad, en todo caso la Municipalidad
Provincial de Huancayo, por el cual llega un sin variar de documentos que
en mesa de partes se reciben.

La Municipalidad Provincial De Huancayo es una institución pública


encargada de velar por sus pobladores, escuchar sus demandas y
reclamos que necesite esta ciudad, con el fin de que su Alcalde, máxima
autoridad en dicha institución, haga caso a sus peticiones. Por ello la
Municipalidad tiene entre sus diversas áreas, tiene un área de trámite
documentario que pertenece a la Gerencia de Secretaria Municipal, en la
cual es el área que supervisa la recepción de documentos que llegasen a
la municipalidad para ser tramitados al área determinada. Lo cual luego
se hará el seguimiento respectivo por donde dicho documento tendrá que
ser sucedido según la jerarquía del organigrama de la Municipalidad y
después enviado al área encargada según lo solicitado en el documento.

Pero vemos a diario un gran detalle que a los pobladores les causa un
malestar, una incomodidad, el tiempo que demanda el procesar dichos
documentos en la Municipalidad, lo cual estos exigen que sea más
eficiente, y no sea el caso en la parte externa de la Municipalidad ya que
debido a ello también el mismo personal que labora en ella, son
perjudicados debido a esa demora que causa el procesamiento de
tramites documentarios, a nivel de todas las áreas que la conforman.
(Huancayo, s.f.)

2
1.2. FORMULACION DEL PROBLEMA.

1.2.1 Problema General:


- ¿Cómo influye el Desarrollo e Implementación del Sistema de Tramite
Documentario en la Municipalidad Provincial de Huancayo para la
atención de expedientes?
FFFFFF
1.2.2 Problema Específicas:
a.- ¿Cuáles son los procesos más comunes en las que el Desarrollo e
Implementación del Sistema de Tramite Documentario en la Municipalidad
Provincial de Huancayo mejorara la atención de expedientes?

b.- ¿Qué efectos produce el Desarrollo e Implementación del Sistema de


Tramite Documentario en la Municipalidad Provincial de Huancayo para la
atención expedientes?

1.3 OBJETIVO

1.3.1. Objetivo General

 Desarrollar e implementar el Sistema de Tramite Documentario en la


Municipalidad Provincial de Huancayo para la atención de expedientes.

1.3.2 Objetivo Especifico

 Diseñar las características que debe cumplir el Sistema de Trámite


Documentario en la Municipalidad Provincial de Huancayo para la
atención de expedientes.

 Implementar el lenguaje de programación Cliente-Servidor para el


desarrollo del Sistema de Tramite Documentario en la Municipalidad
Provincial de Huancayo para la atención de expedientes.

3
 Desarrollar un gestor de base de datos rápido y robusto (open source de
preferencia) para la administración de los datos de manera rápida.

 Establecer la diferencia en los días de respuesta al trámite documentario


de expedientes de la gerencia de desarrollo urbano en la Municipalidad
Provincial de Huancayo entre los periodos 2006 y 2015.

1.4. JUSTIFICACION E IMPORTANCIA.

1.4.1 Justificación Teórica


El desarrollo de un Sistema de Información de Trámite Documentario en la
Municipalidad Provincial de Huancayo, se justifica porque permitirá reducir el
tiempo de demora que existe en el proceso de trámite documentario en la
atención de expedientes, donde el encargado del departamento de trámite
documentario podrá realizar sus funciones de manera más eficiente
reduciendo así el tiempo de atención al ciudadano, y a la vez poder brindar
una mejor calidad de servicio.

1.4.2 Justificación Metodológica.


Científica Según los diferentes problemas observados, detectados, y
analizados en la Municipalidad Provincial de Huancayo, con relación al
sistema de Trámite Documentario, se optó por la implementación de un
Sistema de Trámite Documentario, el cual se desarrollará empleando
metodologías de desarrollo, normas establecidas por el Estado Peruano, y
estrategias de investigación. “Lo que hoy se llama método científico no es ya
una lista de recetas para dar con las respuestas correctas a las preguntas
científicas, sino el conjunto de procedimientos por los cuales se plantean los
problemas científicos y se ponen a prueba las hipótesis científica…” (Mario
Bunge, Publicación - 1995). Tecnológica El presente Proyecto estará
implementado bajo una Arquitectura de tres Capas, usando el lenguaje de
programación JAVA el cual es un lenguaje de programación orientado a
objetos desarrollado por la compañía Sun Microsystems , y está construido a
partir de lenguajes orientados a objetos anteriores, como C++, pero no

4
pretende ser compatible con ellos sino ir mucho más lejos, añadiendo nuevas
características como recolección de basura, programación multicapas y
manejo de memoria a cargo del lenguaje.

La compañía Sun describe el lenguaje Java como, “Simple, orientado a


objetos, distribuido, interpretado, robusto, seguro, de arquitectura neutra,
portable, de altas prestaciones, multitarea y dinámico según la universidad de
navarra (2000)

Una de sus características resaltantes es la portabilidad la cual es una de las


claves para el desarrollo de Java, es decir para lograr que las aplicaciones se
escriban una sola vez, sin la necesidad de modificarlas para que corran en
diferentes plataformas. Esta independencia se alcanza tanto a nivel de código
fuente (similar a C++) como a nivel de código binario. La solución adoptada
fue compilar el código fuente para generar un código intermedio (bytecodes)
igual para cualquier plataforma. La JVM (Máquina Virtual de Java2), donde
reside el intérprete Java, sólo tiene que interpretarlos. Se usará un Gestor de
Base de Datos MYSQL el cual permitirá la manipulación de los datos de
manera ágil, rápida, e interactiva con el usuario se usará también un entorno
de desarrollo o IDE (integrated development environment).

Jorge Sánchez (2004) para todo tipo de tecnologías Java e incluso permite la
codificación de programas en C, C++ y otros (aunque está pensado para Java)
llamado NetBeans, permitiendo integrar y manejar la información necesaria
para el control y seguimiento de expedientes de la Gestión de Trámite
Documentario en la Municipalidad Provincial de Huancayo. El presente
proyecto, tiene como intención contribuir al buen desempeño de la
Municipalidad Provincial de Huancayo, brindándoles una herramienta
Tecnológica que les permita realizar con más rapidez las actividades,
procesos y procedimientos ayudándoles así a mejorar la obtención, manejo,
orientación y dirección de la información. Las Municipalidades son
Instituciones del estado, con personería jurídica, facultada para ejercer el
gobierno de un distrito o provincia, promoviendo la satisfacción de las
necesidades de la población y el desarrollo de su ámbito. Están considerados
como la entidad que agrupa tres componentes interrelacionados: La

5
población, el territorio y la organización local. En tanto el Concejo Municipal,
constituye un órgano de gobierno municipal que cumple las funciones
normativas y de fiscalización, integrado por el alcalde (sa) y los(as)
regidores(as). La misión de la municipalidad está contenido en la Ley
Orgánica de Municipalidades (2003), que establece que su finalidad se define
en tres elementos: de los cuales se mencionará el 2do: Ser una instancia
promotora del desarrollo integral sostenible

1.4.3 JUSTIFICACION PRÁCTICA

El presente trabajo estará a disposición de la oficina de trámite documentario


y a la vez de las otras oficinas, gerencias y sub gerencias de la Municipalidad
Provincial de Huancayo, por ser un plataforma desarrollada en la modalidad
de Cliente-Servidor

Sera de mucha utilidad para la institución disponer de la información que


proporciona el Sistema de Tramite Documentario para la atención de
expedientes de manera rápida y segura

1.4.4 IMPORTANCIA

Es importante porque traerá consigo una serie de beneficios para la


Municipalidad Provincial de Huancayo, que van desde la mejora en el proceso
de atención de expedientes (control y seguimiento), y la reducción de tiempos
en la atención y también de costos en hardware y software.

1.5 SISTEMA DE HIPOTESIS


1.5.1 Hipótesis

1.5.1.1Hipótesis General

El Desarrollo e Implementación del Sistema de Tramite Documentario


en la Municipalidad Provincial de Huancayo influye positivamente en la
atención de expedientes.

6
1.5.1.2 Hipótesis Específica

1. Mejorará los procesos más comunes el Desarrollo e Implementación


del Sistema de Tramite Documentario en la Municipalidad Provincial
de Huancayo para la atención de expedientes.

2. El Desarrollo e Implementación del Sistema de Tramite Documentario


en la Municipalidad Provincial de Huancayo genera una mejor
satisfacción de los usuarios en la atención de expedientes.

1.5.2. Operacionalización de Variables en Indicadores de las Hipótesis

1.5.2.1 Variable Independiente:

Sistema de Trámite Documentario


Indicadores:
Media de tiempos de expedientes atendidos.
Grado de satisfacción del usuario interno

1.5.2.2 Variable Dependiente:


Cantidad de días en la atención de expedientes por proceso
.

Variable Definición Operacional Indicadores


Independiente El Sistema Documentario está
diseñado para llevar un adecuado Grado de
Sistema de registro, control, seguimiento y satisfacción del
Tramite respuestas a los diferentes usuario interno
Documentario expedientes registrados, emitidos
o derivados a las diversas oficinas,
jefaturas o áreas de la Institución.

Dependiente Se determinara el número de días Media de


de respuesta al proceso de trámite tiempos de
documentario estableciéndose expedientes

7
Atención de como la diferencia entre la fecha atendidos por
Expedientes de ingreso de la solicitud menos la proceso
de Tramite fecha de resultado de la solicitud
Documentario

8
CAPITULO II
MARCO TEORICO

2.1.- INTRODUCCION

A continuación se detalla cómo han ido evolucionando el proceso de


trámite documentario y los sistemas de información que lo apoyan. Donde
el hombre desde sus inicios ha ido plasmando sus actividades necesarias
para la realizar su trabajo donde estas generalmente se llevaban a cabo
en manuales o en cuadernos. En el transcurso del tiempo surgen los
sistemas de información aportando las herramientas necesarias para el
procesamiento de la información, permitiendo así un mayor desempeño
para quienes lo utilicen de manera adecuada.

2.1.2.- EVOLUCION HISTORICA DEL PROCESO DE TRÁMITE


DOCUMENTARIO

El hombre durante toda su historia ha tenido la necesidad de plasmar


todas sus actividades como expresión testimonial, sin importar el formato,
lenguaje o soporte. Para lo cual ha utilizado toda clase de materiales como
la piedra, el papiro, el papel.
En esta época surgieron varios problemas: Que los documentos pasen de
un lugar a otro por su frecuencia de uso o por su edad y valor de su
contenido. Que no se mande documentos de un sitio a otro o por otro
motivo de que en el que están ya no caben, ni se dejan de recibir en el
que les corresponde por la misma razón de falta de espacio.
La necesidad de que el manejo de los documentos este siempre en manos
de expertos en la materia de trámite de documentos. Podrán ser varios

9
archiveros de grado medio (ayudantes) bajo la dirección de un archivero
de grado superior, pero siempre uno de estos detrás de todos. Lo
fundamental es que el técnico este siempre en su puesto, sea cual sea el
momento vital del archivo.

Ahora con seguridad se puede decir que todas las instituciones cuentan
con la oficina comúnmente llamada “Mesa de partes”, es la unión de las
instituciones que se da por la documentación que se emite y recibe a diario
y cada vez es mayor.

En todo Organigrama se encuentra la oficina de mesa de partes o tramite


documentario, que es la encargada de velar por la custodia de la
documentación de toda la organización y de mantenerla en buen estado
hasta su archivo, incluso este proceso de archivamiento es una labor
crucial. Ahora también este proceso está siendo modernizado con el uso
de herramientas de tecnología de información para su mejor desempeño.

Evolución histórica de los sistemas de información de trámite


documentario

A principios de los sesenta, los empresarios dieron una tendencia a la


utilización de las computadoras, al percibir que las mismas llevarían una
gran revolución, la cual estamos viviendo actualmente y que ha sido
catalogada como la revolución informática.
Así pues, el avance tecnológico de la computación ha alterado la
cotidianidad de la sociedad y ha cambiado los modos de proceder e
inclusive de vivir, por cuanto se ha concebido a la computadora como una
herramienta indispensable para la realización de tareas y solución de
problemas, tanto así, que sin ella en la actualidad las actividades
colapsarían.
En las organizaciones modernas, el ingreso, creación y envió de
documentos es una tarea de ejecución diaria. La administración del flujo
de estos documentos y la ubicación de los mismos se ha convertido en
una tarea enorme, si no imposible.

10
En la gran mayoría de instituciones el trámite documentario se realiza de
forma manual, pero existen algunas instituciones estatales y privadas que
cuentan con sistemas de trámite documentario. La mayoría fueron
desarrollados por distintas empresas de software, generalmente estos
sistemas se dedican solo manejar el seguimiento de documentos dentro
de la institución, permitiendo así disminuir el tiempo promedio en el trámite
o atención de un documento, debido a que se eliminan tareas repetitivas,
se evitan olvidos y/o documentos extraviados, ubican rápidamente un
documento ya sea que se encuentre este en trámite o con su proceso
concluido y ya almacenado, ahorrando tiempo de búsquedas al no tener
que sumergirse en voluminosos archivos físicos para ubicar un
determinado documento.
Una de las direcciones de esta evolución ha sido el intento por automatizar
las actividades cotidianas con ayuda de Tecnologías de Información
(Information Technologies. IT’s; por sus siglas en inglés). Es así como las
organizaciones de diferentes sectores incorporan tecnología para la
realización de su proceso de trámite documentario con el fin de obtener
dicha automatización y mejorar los resultados en el proceso de trámite
documentario y objetivos del negocio.
Como consecuencia de lo anterior, las organizaciones actualmente
poseen sistemas de información de trámite documentario con el fin de
organizar, automatizar y ejecutar su proceso
.
2.1.3 LOS SISTEMAS EN LAS ORGANIZACIONES

Toda organización es un sistema social, cuya estructura refleja de qué


manera, ésta interactúa con el medio ambiente. En tanto es sistema,
dependen de los subsistemas que la componen y los condiciona, puesto
que les impone su propósito. Es útil reconocer estos subsistemas y cómo
interactúan entre sí, para poder juzgar la coordinación que es precisa
entre ellos y poder actuar con oportunidad e introducir los cambios
correspondientes.

(Sandoval, 2009)

11
2.1.4 SISTEMAS DE INFORMACIÓN

Como sistema, una organización transforma inputs de recursos, bienes,


información y servicios para obtener un producto. En su estructura se
reconocen tres grupos diferenciados

- Los sistemas que atienden a la captación y evolución de los recursos


fundamentales, en conexión con el entorno;

- Los sistemas que permiten la administración o gobierno del sistema


mayor u organización;

- Los sistemas que atienden al desarrollo de las tareas que son requeridas
por la actividad de la organización.

El procesamiento de los recursos, intersectando personal con


operaciones (definidas por los procedimientos), y aplicándose sobre los
otros recursos por medio de la tecnología, constituye la función de la
empresa agrupada en los sistemas operativos, cuya naturaleza
corresponde a las necesidades particulares de cada organización.

Todo el conjunto de recursos y operaciones, tiende a conformar


dinámicamente estructuras que son ajustadas también dinámicamente
por decisiones de la dirección. Esa dirección no se ejerce
espontáneamente, sino que está a su vez estructurada: El sistema de
Administración, o Sistema de Gobierno, que se compone de varios
sistemas corporativos, así llamados por tratarse de sistemas que afectan
a la totalidad de la organización. Estos son el Sistema Decisional, que
establece la mecánica por medio de la cual se toman las decisiones, el
Sistema de Información, que explicita la estructura a través de la cual se
captan y elaboran los datos, el Sistema de Planificación y Control, que
anticipan lo que ocurrirá con cierta probabilidad, y evalúan lo que ocurrió
realmente, y que constituyen los aspectos complementarios de la toma de
decisiones.

Las decisiones se toman juntando datos e informándose a través del


sistema de información, y otra vez a través del mismo se traducen en

12
órdenes o normas para la producción, que luego se transforman en
acciones.

El sistema de gobierno está ahí, para que las personas que dirigen una
organización puedan hacerlo sistemáticamente, que dispongan de
información organizada para evaluar factores dentro y fuera de la misma,
y para que el control de lo actuado sea tan eficaz, como sea posible.

La planificación es una toma de decisiones anticipada, pero, de hecho,


implica un sistema para realizarla. Como en ese sistema no se puede
prever todo, el control es necesario para la acción correctiva. El sistema
de información, obra como nexo entre ellos, al transformar decisiones en
acciones y los resultados de éstas en información de control de tareas de
este ciclo son las siguientes: un acontecimiento externo o interno (evento),
produce una excitación que da lugar a un registro de algunas de las
variables afectadas: Este se integra en un sistema que conjuntamente a
otros datos conforman lo que llamamos base de datos. Por medios
manuales, mecánicos o electrónicos, el repositorio (la base) es utilizado
para el procesamiento, dando así lugar a la información.

2.1.5.- INFORMACIÓN Y DATOS

Todas las mediciones que se hagan sobre variables observadas


constituyen datos. Claramente, estos carecen de valor si no se cuenta con
un contexto contra el cuál evaluarlos o contrastarlos. Al añadirle el
contexto se le da valor semántico al dato, es decir, se le elabora
adjuntándolo con otros datos, como mensaje. Pero el mensaje tampoco
interesa, es decir “informa”, si no hay motivo para conocerlo.

2.1.6 LOS DATOS COMO ACTIVO DE UNA ORGANIZACIÓN

Organización recoge y analiza datos. Estos datos son de diferentes


orígenes y responden a diferentes propósitos. Por ejemplo la contabilidad
de una empresa resume, habitualmente, los datos referidos a las
operaciones de la misma medidos en dinero corriente. Las empresas y las
organizaciones en general suelen también almacenar datos sobre sus
productos, servicios, clientes, agentes, contratistas, proveedores o

13
beneficiarios. Cada una de estas categorías significa un tipo distinto de
datos.

Las organizaciones, en tantos sistemas, tienen un propósito, fijado por las


decisiones determinativas del más alto nivel de conducción: El directorio
de la empresa. Pero no siempre las organizaciones se estructuran
eficientemente para cumplir con sus objetivos, y es notorio que algunas
hasta lo hacen manifiestamente mal. Un buen indicio del grado de
madurez de una organización en su gestión administrativa es el manejo
que realiza con los datos. En los últimos años, varias organizaciones que
llevaron a la práctica una reestructuración de sus sistemas administrativos
en torno a sus objetivos de información obtuvieron beneficios que las
colocaron delante de su competencia de manera decisiva, casi obligando
a aquella a dejar el mercado. Más que preconizar el monopolio, este
argumento pretende afirmar la importancia de la administración sabia de
los datos de una organización, aún en aquellos casos donde los objetivos
sólo pueden medirse en el terreno económico de manera mediata, como
en el caso de la salud pública.

Esto implica el reconocimiento, por parte del personal de las


organizaciones, de que los datos deben pertenecer a todas las funciones
de una organización. Las islas de información en las que es habitual que
se refugien los administradores medios y aún altos, impiden de manera
terminante la cooperación requerida para alcanzar este objetivo. Por
ejemplo, el gerente de producción de una planta fabril puede entender el
éxito de la empresa como la producción a capacidad plena, el de
relaciones laborales como el funcionamiento sin conflictos, el contador
como un balance fiscal positivo, y el financista o tesorero como un flujo de
caja afortunado. Cada uno tiene, entonces, sus propias necesidades de
información y su propia visión de la empresa u organización. Uniformar
esos criterios es tarea de Desarrollo Organizacional, pero las
consecuencias sobre los datos deben ser asumidas por el área de
sistemas mucho antes de que un programa de desarrollo organizacional,
pueda mostrar avances en ese sentido.

14
Claramente, tal como la organización reconoce que sus recursos
humanos, tecnológicos o logísticos requieren un nivel de especialización
en su administración, aun cuando su efecto sobre la empresa resulte
global, se debe reconocer que la administración de los datos de una
organización, dado el valor que éstos tienen para la misma, debe estar en
manos de una función especializada.

La utilidad de los datos de una empresa u organización, se materializa en


la toma de decisiones correcta y oportuna, en base a los datos que
conoce. Si éstos resultan poco seguros, imprecisos, inoportunos o
simplemente están fuera del alcance del que tiene que tomar la decisión,
el proceso de la misma resulta poco fiable, y la organización pierde
confianza en el sistema gubernamental, se vuelve rígida y poco manejable
y termina convirtiéndose en una burocracia.

El primer paso hacia los proyectos de reingeniería en las organizaciones


es reconocer la necesidad de la existencia de una función de
administración de datos en cada una de ellas. A partir de allí, el Sistema
Informático es la aplicación de técnicas de producción de sistemas
automatizados para el mantenimiento y la explotación de los datos como
activo de la Organización, o sea los que ésta tiene y genera.

2.1.7 EL PROYECTO DE SISTEMAS

Proyecto de Sistemas en una organización, es un conjunto de actividades


ya sea secuenciales o en paralelo, cuyo objetivo es producir un “producto”
informático que se incorpora a la estructura de los procesos de la
organización que lo gesta. De todos modos, un proyecto se caracteriza
por:

 Se ejecuta una sola vez;

 Tiene fecha de comienzo y de finalización;

 Tiene un presupuesto operativo;

 Atiende a uno o más procesos de la organización.

15
En este contexto, un proceso de la organización es un conjunto de
actividades de la misma cuyo objetivo es producir resultados definidos a partir
de datos de ingreso definidos. Estas actividades pueden tener lugar en
paralelo o ser secuenciales. Pueden involucrar el manejo de información, o
las acciones de personas. Una característica de los procesos es que se les
puede repetir, en condiciones normales, continuamente. También es posible
generar métodos alternativos para alcanzar los mismos objetivos.

El Proyecto de Sistemas de una organización trasciende al Proyecto de


Software, aunque lo origina. Generalmente, hacemos referencia a un
Proyecto de Sistemas cuando se pretende realizar alteraciones en la
estructura de trabajo de un área, pero como ésta se refleja profundamente en
su Sistema de Información, es éste el que resulta modificado. El Sistema de
Información de la organización transforma objetos reales en información. Los
administradores manipulan luego esos datos, o esa información, tal cual si
fueran los objetos reales, para provecho de la organización, teniendo en
cuenta los objetivos formulados en su creación y para la que se formuló la
estructura del sistema de información.

Los objetivos de la organización para la que trabajan escapan al gobierno de


los profesionales de sistemas como técnicos, pero, como administradores
que participan en las decisiones de esa organización, colaboran en su
formulación. Sin embargo, en cada área es el administrador especializado el
encargado de traducir las necesidades de información de la organización en
necesidades de información del sector. Es su responsabilidad que la
herramienta sea la adecuada.

El sistema de información de un área dada está conformado por flujos


formales e informales de datos. Tanto unos como otros son útiles y
necesarios, así como valiosos. Los flujos formales a menudo están
soportados (por lo menos en parte) por el conjunto de programas de software
de la base de datos y los que explotan o procesan esos mismos datos, pero
de todos modos siempre son más que la suma de estos programas, las
normas que los rigen, las personas que los utilizan, alimentan y controlan,
son parte del sistema. Además de los flujos formales, los informales aportan

16
abundante información, aun cuando los canales que recorra no estén
estructurados. No debe entenderse la informalidad como una característica
indeseable, sino más bien como una realidad de la vida, o una constante
física. Más aún, estos flujos informales brindan el contexto sin el cual nuestros
datos jamás pasarían a ser información.

Cuanto mejor definido estén esos objetivos, aún si eso demanda mucho
tiempo, tanto más grande es la probabilidad de éxito del proyecto.

Para definir sus objetivos, el usuario debe ser capaz de describir el


funcionamiento de su área con precisión, tanto el actual como el deseado.
Este es el diseño conceptual que le permite precisar sus objetivos respecto
de la aplicación de la computadora.

El proyecto puede fracasar si el sistema no tiene en cuenta los objetivos, lo


que es consecuencia de un diseño disonante, o si no realiza las funciones
que el diseño específico, es producto de un desarrollo deficiente. En cualquier
caso, el único que puede decidir qué información le debe brindar el sistema
de computadora, y si éste lo hace o no, es el usuario del sistema: no puede,
por lo tanto, delegar el diseño en el analista sin ejercer críticamente la
supervisión. Sus objetivos dependen de ello. Tampoco el desarrollo puede
ser delegado a ciegas, debe participar y supervisar donde le sea posible. De
hecho, el sistema de computadora es la herramienta que forja el
Departamento especializado para que el propio usuario pueda alcanzar sus
metas.

Es responsabilidad del usuario controlar y supervisar que la herramienta sea


la adecuada.

El usuario debe estar preparado para supervisar el plan de desarrollo de


punta a punta, asistido estrechamente por el profesional de sistemas, quien
se encargará de los detalles técnicos. Los resultados, y no las actividades,
deben ser la medida del éxito.

A la luz de todo lo expresado, el ciclo de vida de un proyecto de Sistemas


pertenece al área de los usuarios. Nace dentro de ella como necesidad para

17
alcanzar un objetivo, y culmina también dentro de ella como la herramienta
de cambio institucionalizada que permite un nuevo funcionamiento del área.

En general el Proyecto de Sistemas y el Proyecto del Sistema de Información


se manifiesta en la “traducción” en la jerga de Software y Sistemas a través
de una serie de señales, tan vagas generadas en un requerimiento tan simple
como “Quiero un sistema de Cuentas Corrientes”, o necesito que “La
Computadora me liquide comisiones”.

Sería ingenuo de parte de la gente de sistemas considerar estas solicitudes


tal como vienen., dado que las mismas esconden necesidades más
profundas. No siempre el mecanismo de planificación de la organización
funciona tan adecuadamente como para detectar con anticipación
necesidades de Información, y conformarlas en un plan de sistemas. El
profesional de sistemas, por lo tanto, debe prepararse para lo que sigue: en
realidad, el usuario que se ha acercado a expresar su solicitud está buscando
producir un cambio, dado que si estuviera satisfecho con las cosas como
están, no pediría nada. Para cambiar un sistema es necesario o bien cambiar
alguna de sus componentes o reorganizarlas de un modo diferente.

2.1.8 PLANEAMIENTO ESTRATÉGICO DE LA INFORMACIÓN

En estos tiempos de nuevas tecnologías y cambios constantes, la mayor


competencia en cualquier negocio hace que las empresas se apoyen cada
vez más en soluciones informáticas para llevar a cabo sus acciones, ya sea
para mantener su actividad como para permitir un crecimiento en sus
mercados específicos. Ante esta situación, aparecen constantes pedidos
sobre el área de sistemas, tanto en la figura de un departamento interno de
la organización, como el requerimiento apuntado a un proveedor externo,
para actividades de desarrollo, implementación y mantenimiento de sistemas
informáticos que provean soluciones a los problemas que la empresa u
organización debe afrontar.

Si este trabajo de aporte de sistemas, almacenamiento y procesamiento de


datos no se realiza dentro de un marco planificado con antelación, se está
tomando un camino con un único destino: el caos. El advenimiento de las

18
computadoras personales hizo que el poder del manejo de la información
pasara de los centros de cómputos al escritorio de cada persona en la
organización.

Esto trae aparejado ciertos problemas como, por ejemplo, la duplicación y


disparidad de datos en cada computadora. El área de sistemas de la empresa
pierde el control de qué, cómo, dónde y cuándo los datos son almacenados.
Si bien habrá un archivo de clientes, no es improbable pensar que dos
gerentes de producto tengan una planilla de cálculo con sus clientes, ya sean
los mismos o algunos potenciales, no incluidos en el conjunto de clientes
“oficiales” que surgen del sistema de facturación.

Por qué planificar

La planificación es una tarea que se lleva a cabo en numerosas actividades:


la construcción de una autopista, el desarrollo de una nueva aeronave
comercial, la aparición de un medicamento, etc. Durante mucho tiempo, las
organizaciones dieron preferencia al desarrollo de sistemas administrativos
que soportan el trabajo rutinario de la empresa en áreas tales como
contabilidad, sueldos, facturación y, últimamente, administración de
producción. Sin embargo, los datos generados por y para estos sistemas
pueden convertirse en información para ciertas posiciones, que sirva de
soporte a sus decisiones respecto del futuro del negocio. Además, una vez
que los sistemas administrativos (los cuales podemos llamar de base) estén
funcionando, se podrán destinar recursos a desarrollos particulares, que
están tomando cada vez más importancia en esta época y que se relacionan
con el cliente final: atención telefónica para consultas, toma de pedidos e
información por fax a pedido; soporte de tele marketing y seguimiento de
clientes; bases de datos y consultas para investigación y segmentación de
mercados, etc.

Esta avalancha de aplicaciones, si no se integran en un contexto apropiado,


dará lugar a la duplicación del almacenamiento de datos, redundancias
perjudiciales, superposición de actividades, mala asignación y uso de
recursos humanos y materiales, entre otros inconvenientes.

19
Para evitar tales situaciones, se impone que la empresa lleve a cabo un
planeamiento estratégico de la información. Lo llamamos estratégico pues
implica que será motivado por una estrategia, entendiendo con este concepto
a determinar las situaciones en la que se estará en distintas etapas de ese
plan. Además, para desarrollar el plan se asume que se usarán ciertas
tácticas: cómo se encarará cada una de esas etapas para lograr cada meta
intermedia. Respecto del desarrollo de software para una organización, será
un documento en el cual se establece qué se hará en el largo plazo (digamos,
3 a 5 años): se definen los sistemas informáticos necesarios para que la
empresa desarrolle su actividad en forma “normal”, es decir, coordinada e
íntegramente.

Entidades, clases de datos y sistemas

A partir del ciclo de vida de las funciones expresado en los párrafos


anteriores, hay que examinar las entidades mantenidas por la empresa. Los
datos de inventario son los más previsibles que aparezcan y se corresponden
con los archivos maestros de la empresa (típicamente clientes, proveedores,
productos, empleados, etc.). Luego es más fácil tratar con los datos
transaccionales. Quedan por último, los de planeamiento / estadísticas. Así
se obtienen los datos que se están manejando en cada etapa.

Agrupando ahora los datos comunes, logramos armar categorías de datos.


En este punto no se necesita conocer las entidades en particular sin ver los
grupos mayores, que llamaremos clases de datos. Los sistemas disponibles
en la empresa pueden clasificarse en rutinarios y no rutinarios. Dentro de
estos últimos podemos distinguir sistemas especiales (para investigación
operativa por ejemplo), de información y para soporte en la toma de
decisiones. En el caso de los sistemas especiales, se producen soluciones a
problemas bien estructurados y cerrados que pueden emplear archivos
derivados de otras bases de datos. Permiten experimentar con nuevas
metodologías de trabajo. Respecto de los sistemas de información, las
respuestas son no estructuradas, con consultas impredecibles y producen
gran cantidad de listados y reportes. Su objetivo es aportar información para
mejor toma de decisiones. Se basan en lenguajes de consultas amigables y

20
potentes. Los datos y consultas no son estructurados ni anticipados. No
automatizan las decisiones, sino que ayudan a tomarlas, mediante un
esquema de simulación. Pueden tener mucho procesamiento y en general
usan una base de datos propia (con mantenimiento a cargo del usuario).

Cada vez estamos más cerca de la etapa de diseño de los futuros


almacenamientos que serán la base de los sistemas a proponer en el plan de
información de la empresa. Dentro de esta etapa habrá que distinguir distintos
tipos de almacenamientos, archivos o bases de datos:

Archivos: independientes para cada aplicación. Surgen de hacer análisis


estructurado. Al haber más de un sistema, aparecen muchos archivos
independientes. Es un esquema fácil de implementar, pero con un alto costo
de mantenimiento. Un cambio en las aplicaciones propaga cambios en los
archivos. Es sencillo pero peligroso.

Bases de Datos Aplicaciones: para cada sistema creamos tablas. Hay


bases de datos independientes. Potenciamos lo anterior, siendo más caro de
implementar que él, pero más sencillo que el punto siguiente.

Base de Datos Clases: las tablas se crean independientes de la aplicación


y del lugar físico de uso. Se piensa en un gran repertorio de datos, que
necesita más tiempo para armado y depuración del modelo de datos, pero
conlleva un menor costo de mantenimiento. Conduce a desarrollos rápidos
porque los almacenamientos ya están implementados. Implica la figura de un
administrador de la base de datos y está pensado para altos volúmenes de
datos.

Base de Datos Información: se debe priorizar el acceso a los datos y


facilidades para consultas por parte de los usuarios finales. Son fáciles de
implementar, siendo más flexibles y cambiantes que las tradicionales bases
de datos. Pueden coexistir con el esquema anterior.

(Sandoval, 2009)

21
2.1.9 METODOLOGIA

La Metodología para el modelamiento se deberá utilizar obligatoriamente


diagramas UML (Unified Modeling Language); asimismo, la solución
informática deberá usar la metodología de trabajo, basada en la Norma
Técnica peruana 12207:2006. De igual manera se tomara en cuenta los
aspectos generales de la Metodología Métrica V3, para el desarrollo e
implementación de sistemas informáticos, tomando en consideración que
dicha metodología facilita la planificación, el control y seguimiento de los
proyectos, mejora del ratio coste / beneficio, optimiza la gestión de recursos,
facilita la comunicación entre los participantes y facilita la evaluación de los
proyectos.

2.1.9.1 UML (Unified Modeling Language)

Para el desarrollo de software orientado a objetos no basta usar un lenguaje


orientado a objetos. También se necesitará realizar un análisis y diseño
orientado a objetos. El modelamiento visual es la clave para realizar el
análisis. Desde los inicios del desarrollo de software han existido diferentes
metodologías para hacer esto del modelamiento, pero sin lugar a duda, el
Lenguaje de Modelamiento Unificado (UML) puso fin a la guerra de
metodologías.

2.1.9.2 Definición de UML

UML (Unified Modeling Language) es un lenguaje que permite modelar,


construir y documentar los elementos que forman un sistema software
orientado a objetos. UML entrega una forma de modelar cosas conceptuales
como lo son procesos de negocio y funciones de sistema, además de cosas
Concretas como lo son escribir clases en un lenguaje determinado,
esquemas de base de datos y componentes de software reusables. La
estandarización de un lenguaje de modelado es invaluable, ya que es la parte
principal del proceso de comunicación que requieren todos los agentes
involucrados en un proyecto informático. Si se quiere discutir un diseño con

22
alguien más, ambos deben conocer el lenguaje de modelado y no así el
proceso que se siguió para obtenerlo.

Figura N° 1 : Diagrama de UML

Fuente : Universidad Tecnológica del Perú Michael Raúl Valles Ojeda /


Oscar Taquiri Benavides

El UML es un lenguaje de modelado y no un método. La mayor parte de los


métodos consisten, al menos en principio, en un lenguaje y en un proceso
para modelar. El lenguaje de modelado es la notación (principalmente
gráfica) de que se valen los métodos para expresar los diseños. El proceso
es la orientación que nos dan sobre los pasos a seguir para hacer el diseño.
El lenguaje de modelado es la parte más importante del método, es la clave

23
para la comunicación; para poder analizar un diseño se necesita comprender
el lenguaje de modelado; no el proceso que se siguió para lograr el diseño.
(Valles Ojeda, 2010)

2.1.9.3 Características del UML

 Desplegar los límites de un sistema, sus principales funciones


mediante casos de uso y actores
 Representar la estructura estática de un sistema usando diagramas
de clases
 Modelar los límites de un objeto con diagramas de estados
 Mostrar la arquitectura de la implementación física con diagramas
componentes y de emplazamiento o despliegue.

2.1.9.4 Objetivos del UML

Los diagramas se utilizan para dar diferentes perspectivas del problema


según lo que nos interesa representar en un determinado momento, vale
decir que en algunos casos no es necesario representar los nueve diagramas.

Figura N° 2 : Objetivos del UML

Fuente : Universidad Tecnológica del Perú Michael Raúl Valles Ojeda / Oscar
Taquiri Benavides

24
2.1.9.5 Diagrama de Caso de Uso

Un caso Diagrama de Casos de Uso puede existir tanto a nivel del Modelo de
Negocio como en el nivel de Modelo de Construcción del Software. A nivel de
Negocio muestra el Caso de Uso del Negocio relacionado con los actores
internos y externos de negocio. A nivel de Sistema muestra la funcionalidad
total del Sistema Software que se construye. El Diagrama de Casos de Uso
a nivel de Sistema permite definir los privilegios del Sistema por actor,
teniendo en cuenta aspectos de auditoría al considerar el módulo de
identificación, como obligatorio.

Figura N°.3 : Diagrama de casos de uso

Fuente : Universidad Tecnológica del Perú Michael Raúl Valles Ojeda / Oscar Taquiri
Benavides

2.1.9.6 Diagrama de Objetos

Muestra un conjunto de objetos (instancias de las clases) y sus relaciones.


Modelan las instancias de elementos contendidos en los diagramas de
clases, es decir las ocurrencias de cada elemento que constituye una clase,
a cada uno de estos elementos se les llama objetos. Son como fotos
instantáneas de los diagramas de clases.
(Valles Ojeda, 2010)

25
Figura N° 4 : Diagrama de Objetos

Fuente : Universidad Tecnológica del Perú Michael Raúl Valles Ojeda / Oscar
Taquiri Benavides

2.1.9.7 Diagrama de Secuencia

Un diagrama de Secuencia muestra una interacción ordenada según la


secuencia temporal de eventos. En particular, muestra los objetos
participantes en la interacción y los mensajes que intercambian ordenados
según su secuencia en el tiempo. El eje vertical representa el tiempo, y en el
eje horizontal se colocan los objetos y actores participantes en la interacción,
sin un orden prefijado. Cada objeto o actor tiene una línea vertical, y los
mensajes se representan mediante flechas entre los distintos objetos. El
tiempo fluye de arriba abajo. Se pueden colocar etiquetas (como restricciones
de tiempo, descripciones de acciones, etc.) bien en el margen izquierdo o
bien junto a las transiciones o activaciones a las que se refieren.

26
Figura N° 5 : Diagrama de Secuencia

Fuente : Universidad Tecnológica del Perú Michael Raúl Valles Ojeda /


Oscar Taquiri Benavides

2.1.9.8 Diagrama de Colaboración

Un Diagrama de Colaboración muestra una interacción organizada


basándose en los objetos que toman parte en la interacción y los enlaces
entre los mismos (en cuanto a la interacción se refiere). A diferencia de los
Diagramas de Secuencia, los Diagramas de Colaboración muestran las
relaciones entre los roles de los objetos. La secuencia de los mensajes y los
flujos de ejecución concurrentes deben determinarse explícitamente
mediante números de secuencia. Los diagramas de colaboración permiten
mostrar mejor como se vinculan los objetos, a cambio de hacer más difícil
observar el orden de ejecución, pues enumeran los mensajes en lugar de
mostrar al tiempo como una dimensión, tal como lo hacen los diagramas de
secuencia.
(Valles Ojeda, 2010)

27
Figura N° 6 : Diagrama de Colaboración

Fuente : Universidad Tecnológica del Perú Michael Raúl Valles Ojeda / Oscar
Taquiri Benavides

2.1.9.9 Diagrama de Estado

Un Diagrama de Estados muestra la secuencia de estados por los que pasa


bien un caso de uso, bien un objeto a lo largo de su vida, o bien todo el
sistema. En él se indican qué eventos hacen que se pase de un estado a otro
y cuáles son las respuestas y acciones que genera. En cuanto a la
representación, un diagrama de estados es un gráfico cuyos nodos son
estados y cuyos arcos dirigidos son transiciones etiquetadas con los nombres
de los eventos. Capturan los cambios de estado que sufren los objetos en
respuesta a eventos. Los diagramas de clases y de objetos correspondientes,
sólo muestran los aspectos estáticos pero no muestran como son afectados
los objetos cuando ocurre algo. Sin embargo, estos comportamientos tienen
que implementarse mediante software y representarlos en algún sitio,
asegura que los desarrolladores no adivinen el comportamiento y produzcan
software que satisfaga los requerimientos.

28
Figura N° 7 : Diagrama de Estados

Fuente : Universidad Tecnológica del Perú Michael Raúl Valles Ojeda /


Oscar Taquiri Benavides

2.1.9.10 Diagrama de Actividad

Muestra la realización de operaciones para conseguir un objetivo. Presentan


una visión simplificada de lo que ocurre en un proceso, mostrando los pasos
que se realizan. Los diagramas de actividad, son una extensión de los
diagramas de estado. Los diagramas de estado resaltan los estados y
muestran las actividades que dan lugar a cambios de estado, mientras que
los diagramas de actividad, resaltan justamente las actividades.
Comúnmente los diagramas de actividad se utilizan en dos formas. En el
modelado de flujos de trabajo, haciendo hincapié en las actividades tal y
como son vistas por los actores que colaboran conel sistema, esto es,
modelando procesos de negocios. En el modelado de una operación,
utilizando los diagramas de actividad como diagramas de flujo para mostrar
detalles de un algoritmo, haciendo amplio uso de las condiciones y modelado
de procesos concurrentes.
(Valles Ojeda, 2010)

29
Figura N° 8 : Diagrama de Actividades

Fuente : Universidad Tecnológica del Perú Michael Raúl Valles Ojeda / Oscar
Taquiri Benavides

2.1.9.11 Diagrama de Componente

Los diagramas de componentes permiten visualizar las partes de un sistema,


mostrando las diversas formas en que pueden ensamblarse para construir
ejecutables. Un diagrama de componentes muestra las dependencias entre
componentes físicos de software, tales como archivos de código fuente,
binarios, de configuración, de instalación y desinstalación, ejecutables,
tablas, etc. Los diagramas de componentes modelan la vista estática de los
sistemas, es decir sólo los componentes y sus conexiones y no como
funcionan.

30
Figura N° 9 : Diagrama de Componentes

Fuente : Universidad Tecnológica del Perú Michael Raúl Valles Ojeda /


Oscar Taquiri Benavides

2.1.9.12 Diagrama de Despliegue

El diagrama de despliegue, modela la topología del hardware sobre el cual


correrá nuestra aplicación y nos indica en donde se ejecutará cada uno de
nuestros componentes; muestra las relaciones físicas entre los componentes
de software y el hardware de nuestro sistema. Los diagramas de despliegue
muestran la forma en que físicamente lucirá nuestro sistema, sólo deben
mostrarse los nodos y componentes que utilizarán en su versión ejecutable.
El término original para estos diagramas es deployment diagram que en
nuestro idioma ha sido traducido como diagramas de distribución,
emplazamiento, implantación o despliegue.
(Valles Ojeda, 2010)

31
Figura N° 10 : Diagrama de Despliegue

Fuente : Universidad Tecnológica del Perú Michael Raúl Valles Ojeda /


Oscar Taquiri Benavides

2.2. MARCO REFERENCIAL O ANTECEDENTES.

Para la realización del estudio del presente proyecto se revisó diversas fuentes
bibliográficas, con el propósito de investigar si existían proyectos similares al
presente. En base a los proyectos encontrados, cada uno aporta una perspectiva
diferente al proyecto que se va a llevar a cabo, donde algunos guardan relación
con la tecnología utilizada. A continuación se presentan los estudios realizados
que guardan relación con el presente proyecto:

Dorila Carrera en su tesis “Análisis y Diseño de un Sistema de Trámite de


Documentos de Pago a Proveedores Vía intranet”. Hace mención que la gran
mayoría de las empresas a lo largo de su actividad económica, realizara
adquisiciones de bienes y necesitara la prestación de diversos servicios, por este
motivo un proceso manual obliga que el documento físico deba ser enviado
sucesivamente a diversas oficinas para su respectiva revisión. Para ello propone

32
solucionar el problema planteado con un sistema de “Trámite de documentos de
pago a proveedores vía intranet”, que permita el registro, revisión, aprobación y
contabilización de los documentos de pago a proveedores, a través de un flujo
de aprobación organizado por niveles, que facilite el adecuado y oportuno
seguimiento por parte de las unidades involucradas de la institución y de los
proveedores, y a la vez cubrir las deficiencias existentes y proporcione
escalabilidad, que permita adaptarse a futuros requerimientos, y así incrementar
la satisfacción del cliente brindados por la universidad. De cierto modo sirve de
apoyo a la investigación en cuanto al diseño y el aplicar una tecnología para la
gestión de trámite documentario en la cual describe las operaciones que se
realizan en dichas instituciones.

Por otra parte Franco Huertas en su tesis “Mejora del tiempo de respuesta a los
remitentes de documentos mediante la aplicación de un sistema de trámite
documentario en una facultad” de la Universidad Nacional de Ingeniería (UNI),
propone mejorar el tiempo de respuesta a las consultas de los remitentes de
trámites mediante la aplicación de un sistema de trámite documentario, el área
en el que se desempeña es en una institución pública, la cual es totalmente
diferente a la entidad en la que se desarrolla el proyecto de investigación, pero
también busca solucionar los mismos problemas que se encuentran contenidos
en el proceso de trámite documentario de esta entidad pública. Dicho sistema
proporciona una forma de llevar a cabo la gestión automatizada de los procesos
involucrados en el trámite, y así facilita las actividades diarias del personal
involucrado.

A.- El sistema llamado Trámite Documentario en PRODUCE 2007, del ministerio


de la producción se realiza una búsqueda de los documentos ingresados o
número de correspondencias, se establece una fuente un tipo de documento y
un tipo de búsqueda, a su vez se realizan consultas de tipo gerencial y de tipo
individualizada en los últimos 3 años, teniendo como resultados la cantidad de
documentos por fecha ingresados por número y también de correspondencias
asciende 44253 24780 correspondientemente, se tomará como referencia el

33
modelo de negocio e interfaces ofrecidas en el sistema mencionado. (Ministerio
de la Producción (2007)
(Sandoval, 2009)

B.- El Sistema de Trámite Documentario Web, del Ministerio de Salud se realiza


una búsqueda por número de expediente, una vez ingresado se envía un
resumen por expedientes y movimientos, se describen observaciones
realizadas, el asunto respectivo, remitente, destinatario, a través de este sistema
se tomará como referencia el filtrado de datos para los usuarios (MINSA 2007).

C. El sistema de trámites denominado Servicio al Ciudadano por el portal del


Estado Peruano brinda información para poder realizar tramite de diferentes
tipos ya sea por poderes legislativo, judicial, ejecutivo, organizaciones
autónomas, gobiernos regionales y gobiernos locales del Perú, también brinda
un servicios en línea para consultas o pasos a realizar por trámite y la descarga
gratuita de formatos de diferentes instituciones, a través de este sistema se
tomará como referencia el filtrado de datos, interfaces, lógica del negocio. (Portal
del Estado Peruano-Publicado el 2007)

D. El Sistema de trámite denominado (SISDOC) Trámite Documentario del


Ministerio de Agricultura ofrece un servicio que permite realizar un seguimiento
vía Web del estado de los documentos que ingresan al MINAG (Sistema Interno
de Trámite Documentario), con el fin de optimizar los servicios brindados a
nuestros usuarios externos o internos a través de consultas directas, a la bases
de datos MINAG, utilizando algunos datos generales (número, remitente, fecha,
etc. De este se Sistema se extraerán el modelo de interfaces y la lógica de
negocio. (Ministerio de Agricultura 2007).
(Sandoval, 2009)

2.3. MARCO CONCEPTUAL.

Recepcionar y registrar toda la documentación que ingresa por Mesa de


Partes, dándole el proveído correspondiente.- Tramitar todos los expedientes
que se ha iniciado en

34
- Mesa de Partes:
Atención de consultas sobre el estado de los expedientes ingresados por
los administrados.

- Proceso de trámite documentario:


La unidad de Trámite Documentario y Archivo, es la encargada y responsable
de los trámites administrativos desde su ingreso en Mesa de Partes hasta su
terminación o resolución final. Siendo responsable de conservar la
documentación en forma clasificada y manteniendo la seguridad e
intangibilidad de los mismos. Sus funciones son las siguientes:

 Trámite Documentario: Es una proceso que permite a las organizaciones


tener el control de la ubicación física y estatus, actual y pasado de la
documentación que llega, fluye y se genera dentro de ellas; y en base a
estos datos mostrar estadísticas que permitan analizar pasos repetitivos
o que no agreguen valor y los cuellos de botella para mejorar los flujos de
los documentos dentro de la organización.

 Remitente: Persona que realiza un trámite documentario con una


determinada institución mediante una solicitud, memorando, invitación,
etc. Por tal motivo, posteriormente pedirá un servicio a la organización
para estar pendiente del estado del trámite documentario presentado.

 Mesa de Partes: Es una unidad organizacional, que es responsable de


realizar algunas acciones para cumplir con un procedimiento
administrativo determinado. Es decir, se encargará de Recepcionar los
trámites, registrarlos, darles mantenimiento, derivarlos a las
dependencias que corresponden y darle información oportuna a los
remitentes cuando hagan consultas.

 Dependencia: Es la persona a la cual va dirigida un trámite,


generalmente esta persona tiene a su cargo un área de la institución.

35
 Trámite: Es el objeto que un remitente presenta físicamente (impreso) o
virtualmente (digitalizado) a una mesa de partes. Este objeto puede tener
atributos como el nombre del remitente, el nombre del destinatario
(dependencia), y dirección del remitente, la fecha en la que se entrega el
trámite, el motivo o contenido del trámite, etc.

 Tiempo de proceso por trámite: Es el tiempo transcurrido desde que se


presenta un trámite hasta saber su resultado final. Por ejemplo, si es una
solicitud, desde su presentación hasta saber su aprobación o
desaprobación. Si es de otro tipo, desde su presentación hasta llegar a su
destinatario respectivo (dependencia).

 Tiempo de respuesta al solicitante: Es el tiempo que el encargado de


mesa de partes demora para satisfacer una consulta del solicitante.

 Trámites Documentarios en las Entidades: Un trámite documentario es la


acción de tramitar un documento o un conjunto de documentos para un
determinado propósito, ya que toda entidad o empresa tiene un conjunto
de trámites internos y externos. Los trámites documentarios se refiere a
como las entidades operaran sus servicios con el objetivo de lograr
atender los requerimientos de los usuarios.

 Sistema automatizado: La automatización es un sistema donde se


trasfieren tareas de producción, realizadas habitualmente por operadores
humanos a un conjunto de elementos tecnológicos.

 Registro: La palabra se utiliza en tecnologías de la información para definir


sistemas o elementos de sistemas que se encuentran físicamente
separados de una unidad central.

 Código Abierto: El software de código abierto (en inglés open source


software u OSS) es el software cuyo código fuente y otros derechos que
normalmente son exclusivos para quienes poseen los derechos de autor
son publicados bajo una licencia de software compatible con la Open

36
Source Definition o forman parte del dominio público. Esto permite a los
usuarios utilizar, cambiar, mejorar el software y redistribuirlo, ya sea en su
forma modificada o en su forma original.
(Sandoval, 2009)

2.4. MARCO LEGAL.

 Ley del Procedimiento Administrativo LEY Nº 27444

 La presente Ley regula las actuaciones de la función administrativa


Estado y el procedimiento administrativo común desarrollados en las
entidades.

 Artículo III.- Finalidad

 La presente Ley tiene por finalidad establecer el régimen jurídico aplicable


para que la actuación de la Administración Pública sirva a la protección
del interés general, garantizando los derechos e intereses de los
administrados y con sujeción al ordenamiento constitucional y jurídico en
general.

 Artículo IV.- Principios del procedimiento administrativo

1. El procedimiento administrativo se sustenta fundamentalmente en los


siguientes principios, sin perjuicio de la vigencia de otros principios
generales del Derecho Administrativo:

1.1. Principio de legalidad.- Las autoridades administrativas deben actuar


con respeto a la Constitución, la ley y al derecho, dentro de las facultades
que le estén atribuidas y de acuerdo con los fines para los que les fueron
conferidas.

37
1.2. Principio del debido procedimiento.- Los administrados gozan de
todos los derechos y garantías inherentes al debido procedimiento
administrativo, que comprende el derecho a exponer sus argumentos, a
ofrecer y producir pruebas y a obtener una decisión motivada y fundada
en derecho. La institución del debido procedimiento administrativo se rige
por los principios del Derecho Administrativo. La regulación propia del
Derecho Procesal Civil es aplicable sólo en cuanto sea compatible con el
régimen administrativo.
(Telecomunicaciones, 2007)

38
CAPITULO III:
METODOLOGIA

3.1 TIPO DE INVESTIGACION


La investigación realizada es de tipo exploratorio y descriptivo; ya que con la
información obtenida, se determinó con mayor amplitud la deficiencia en los
procesos de gestión de trámite documentario de la Municipalidad Provincial de
Huancayo, y por tal razón se dotará de una guía de procedimientos de control
interno y de un sistema informático integral que permita tener el control de la
ubicación física y lógica de la documentación que llega y fluye dentro de la
municipalidad, así como de la que se genera al interior de la misma.

3.2 DISEÑO DE LA INVESTIGACION


El diseño es el no experimental transaccional descriptivo, en este método se
observan los fenómenos tal como se dan en un contexto natural para su posterior
análisis, este diseño consiste en la recolección de datos y su propósito es
describir las variables y analizar su incidencia e interrelación en un momento
dado.

3.3 POBLACION Y MUESTRA

3.3.1. POBLACION
El total de expedientes es de 110 correspondientes a los periodos 2006 y 2015

3.3.2. MUESTRA
𝑁 = 𝐶𝑎𝑙𝑐𝑢𝑙𝑜 𝑑𝑒 𝑙𝑎 𝑓𝑜𝑟𝑚𝑢𝑙𝑎
𝑍∝ = 𝑁𝑖𝑣𝑒𝑙 𝑑𝑒 𝑐𝑜𝑛𝑓𝑖𝑎𝑛𝑧𝑎 = 1.64

39
𝑍𝛽 = 𝑃 𝑑𝑒 𝑝𝑟𝑢𝑒𝑏𝑎 = 0.84
𝜎 = 𝐷𝑒𝑠𝑣𝑖𝑎𝑐𝑖𝑜𝑛 𝐸𝑠𝑡𝑎𝑛𝑑𝑎𝑟 = 27.85
𝑋̅1 = 𝑀𝑒𝑑𝑖𝑎 1 = 9.6
𝑋̅2 = 𝑀𝑒𝑑𝑖𝑎 2 = 30.16
(𝑍∝ + 𝑍𝛽 )2 ∗ 2(𝜎)2
𝑁=
(𝑋̅1 − 𝑋̅2 )2

(1.64 + 0.84 )2 ∗ 2(27.85)2


𝑁=
(30.16 − 9.6)2

𝑁 = 22.57
Ver Anexo 1 (Muestra de Expedientes de los periodos 2006-2015)

3.4. METODO DE INVESTIGACION

En esta investigación se utilizó los siguientes métodos:


Descriptivo:
Donde se especifica todos los elementos del sistema de trámite documentario
como herramienta de gestión dirigido a los empleados del departamento de la
oficina de Tramite Documentario y Archivo General.
Inductivo:
Para deducir de la información de la muestra de la población de esta
investigación. Específicamente deducir información del sistema de trámite
documentario.

3.5. TECNICAS E INSTRUMENTOS DE RECOLECCION DE DATOS

Se usó las siguientes herramientas en la investigación:


3.5.1. Técnicas Directas
3.5.1.1. Observación Directa
Con esta técnica se obtuvo una visión más clara del problema y se
determinó la situación real de la Oficina de Tramite Documentario, en
relación al diseño del sistema en mención como herramienta de uso.

40
3.5.1.2. Entrevista sami estructurada
Este tipo de entrevista se caracteriza por la libertad para formular las
preguntas y respuestas bajo cierto grado de espontaneidad, cuyo objetivo
es obtener información de forma oral y personalizada sobre el acontecer
de los aspectos más importantes y relevantes de la oficina de trámite
documentario.

3.5.2 Técnicas Indirectas

La información documentaria permitió conocer el rol de la oficina de trámite


documentario sus procesos, funciones y objetivos de dicha oficina y los
documentos son:
- Plan estratégico institucional.
- Estructura orgánica.
- TUPA (Texto Único de Procedimientos Administrativos)
- Manual de obligaciones y funciones (MOF).
(Huancayo, s.f.)

3.6. TECNICAS DE PROCESAMIENTO DE DATOS

La base de datos del periodo 2006 estaba en tablas libres de fox pro 2.6 y la del
periodo 2015 en MYSQL, de ambas tablas se exporto una cantidad de 110
expedientes al Excel con el mismo estado de atendido, puesto que los
procedimientos son los mismos antes y ahora.
Posteriormente esa información se procesó con la herramienta denominada
SPS-21.

3.7. SELECCIÓN Y VALIDACION DE LOS INSTRUMENTOS DE


VALIDACION

41
Para determinar la validez del criterio de la prueba piloto, se tomó una muestra
de 15 expedientes del 2006 y de 15 expedientes del 2015, con los mismos
procesos.

𝑁 = 𝐶𝑎𝑙𝑐𝑢𝑙𝑜 𝑑𝑒 𝑙𝑎 𝑓𝑜𝑟𝑚𝑢𝑙𝑎
𝑍∝ = 𝑁𝑖𝑣𝑒𝑙 𝑑𝑒 𝑐𝑜𝑛𝑓𝑖𝑎𝑛𝑧𝑎 = 1.64
𝑍𝛽 = 𝑃 𝑑𝑒 𝑝𝑟𝑢𝑒𝑏𝑎 = 0.84
𝜎 = 𝐷𝑒𝑠𝑣𝑖𝑎𝑐𝑖𝑜𝑛 𝐸𝑠𝑡𝑎𝑛𝑑𝑎𝑟 = 54.83
𝑋̅1 = 𝑀𝑒𝑑𝑖𝑎 1 = 9.6
𝑋̅2 = 𝑀𝑒𝑑𝑖𝑎 2 = 42.86

(𝑍∝ + 𝑍𝛽 )2 ∗ 2(𝜎)2
𝑁=
(𝑋̅1 − 𝑋̅2 )2
(1.64 + 0.84 )2 ∗ 2(54.83)2
𝑁=
(42.86 − 9.6)2

𝑁 = 33.40

Ver Anexo 3 (Muestra de Expedientes de los periodos 2006-2015)

42
CAPITULO IV
DESARROLLO DEL SISTEMA DE TRAMITE DOCUMETARIO

4.1. ANTECEDENTES

De acuerdo a las funciones establecidas es la Ley N° 27972, “Ley Orgánica de


Municipalidades”, la Municipalidad Provincial del Huancayo debe formular y
ejecutar proyectos de inversión orientados a promover el desarrollo armónico y
sostenido del ámbito de su competencia, para tal efecto cuenta en su estructura
Orgánica, con la Secretaria Municipal, órgano responsable de la conducción del
proceso de gestión documentaria y la Oficina de Tramite Documentario
responsable de orientar el proceso de planificación y programación de
inversiones referidos a los procesos de modernización y fortalecimiento
institucional.

La Ley marco de Modernización de la Gestión del Estado, Ley N° 27658 en sus


literales d) y f) del artículo 5°, menciona que el proceso de modernización de la
gestión del Estado se sustenta fundamentalmente en mayor eficiencia en la
utilización de los recursos del Estado, por lo tanto, se elimina la duplicidad o
superposición de competencias, funciones y atribuciones entre Sectores y
Entidades o entre Funcionarios y Servidores; así como en la institucionalización
de la evaluación de la Gestión por Resultados, a través del uso de modernos
recursos tecnológicos, la planificación estratégica, la rendición pública y
periódica de cuentas y transparencia a fin de garantizar canales que permitan el
control de las acciones del Estado.

En marzo del 2007, a través de la promulgación del Decreto Supremo 027-2007-


PCM, se Define y Establece Las Políticas Nacionales de Obligatorio

43
Cumplimiento, la cual define doce políticas nacionales de obligatorio
cumplimiento para las entidades públicas. Entre ellas, la Política N° 10, relativa
a la simplificación administrativa que busca organizar un Estado moderno y
eficiente, orientado al servicio del ciudadano, simplificación que paralelamente
funcione como una estrategia de acercamiento del Estado a su población. Tal
política dispone que se brinden trámites y servicios administrativos valiosos y
oportunos a la ciudadanía, dando relevancia a la optimización de procesos.

La simplificación administrativa abarca todos los aspectos vinculados con el


desarrollo de procedimientos y servicios administrativos prestados en
exclusividad por las entidades públicas; como, la atención a la ciudadanía, el
sistema de gestión documental, el soporte informático de tramitación, el proceso
interno de tramitación de las solicitudes y adopción de decisiones o prestación
de los servicios, notificaciones, entre otros.

Es a partir de las normas antes citadas y de la Ley Orgánica del Poder Ejecutivo,
Ley N° 29158, considera la simplificación administrativa como un Subsistema
Administrativo del Estado, por lo que la Presidencia del Concejo de Ministros
(PCM) elabora la Política Nacional de Simplificación Administrativa, aprobada
mediante Secreto Supremo, N° 025-2010-PCM, en la cual se precisa en el
Objetivo 1: Generalizar la gestión por procesos en los procedimientos y los
servicios administrativos por medio de mecanismos definidos por el ente rector,
y la estrategia 3.1 Establecer accesos multicanal para los procedimientos y
servicios administrativos en función de su naturaleza, con énfasis en los canales
no presenciales; y en el Objetivo 2: Universalizar en forma progresiva el uso
intensivo de las tecnologías de la información y de la comunicación en las
distintas entidades públicas y promover la demanda de los servicios en línea por
la ciudadanía.

La PCM, luego de aprobar la Política Nacional de Simplificación Administrativa,


aprueba también el Plan Nacional de Simplificación Administrativa aprobado
por Resolución Ministerial, N° 228-2010-PAM, en el cual se precisan las acciones
necesarias, metas, indicadores, plazos y entidades públicas responsables de su
ejecución con la finalidad de facilitar la implementación de la política por parte de

44
las entidades públicas. Los objetos del Plan son generalizar la gestión por
procesos en los procedimientos y los servicios administrativos; universalizar en
forma progresiva el uso intensivo de las tecnologías de la información y de la
comunicación en las distintas entidades públicas; así como promover la
demanda de los servicios en línea por la ciudadanía.

En el citado Plan, de manera específica se señala en el Objetivo Estratégico de:


Universalizar en forma progresiva el uso intensivo de las tecnologías de la
información y de la comunicación en las distintas entidades públicas y promover
la demanda de los servicios en línea por la ciudadanía; en la estrategia y ampliar
la cobertura de accesos a herramientas tecnológicas en las instituciones del
Estado para la simplificación de los procedimientos y servicios administrativos,
se propones como una de sus acciones principales la acción de Implementación
de las firma digital y el expediente electrónico.
(Informatica, 2007)

El fortalecimiento de capacidades institucionales para mejorar la Gestión


Documentaria involucra acciones que en diversos aspectos redundan en el
beneficio del ciudadano, inversionista y comunidad en general, a partir de una
atención rápida y oportuna al administrado en la Municipalidad Provincial de
Huancayo.

La participación conjunta de la Municipalidad Provincial de Huancayo, sus


órganos municipales contribuirán a mejorar y fortalecer la gestión documentaria
en la institución; simplificación de trámites; rapidez y oportunidad de atención al
ciudadano; seguridad en la gestión de documentos, fácil acceso a documentos
entre otros.

4.2. ANALISIS DE LA SITUACION ACTUAL

Diagnostico
La Municipalidad Provincial de Huancayo posee una estructura orgánica
dependiendo del Manual de Organizaciones y Funciones (MOF) dentro
del cual existe la Subgerencia de Tecnologías de Información y

45
Comunicaciones (Ex Informática), responsable de la administración y
manejo de la información de la Municipalidad Provincial de Huancayo.
Las áreas y las oficinas carecen de este sistema de trámite documentario
por la existencia de diferentes proveedores de redes de Internet que se
encuentran instaladas en los diferentes pisos del palacio municipal.

Distribución de la red y acceso de internet de todo el palacio municipal


de la Municipalidad Provincial de Huancayo.

Figura N° 11 : Distribución de red e internet

Piso Red (Acceso a Internet y Red Local)


Sótano Explora 1 y Speedy 5000-1 ( Al 15% )
Primer Piso Explora 1
Segundo Piso Speedy 5000-1
Tercer Piso Explora 2
Cuarto Piso Explora 2
Quinto Piso Explora 2 y Speedy 5000-2 ( Al 15% )
Fuente Municipalidad Provincial de Huancayo
Elaboracion Propia

Explora (Paquete de datos (600 M) y telefonía fija y celular del proveedor


Claro)
Speedy (Paquete de datos (5000M al 10% de seguridad de conexión) y
telefonía fija y celular del proveedor Movistar)

Reseña del Sistema

El Sistema de Tramite Documentario que se encentraba operando en la


Municipalidad Provincial de Huancayo hasta el 2007 fue desarrollado en
una versión antigua del Foxpro para DOS, y viene funcionando desde el
año 1999, no habiendo sido modernizado con las nuevas plataformas

46
informáticas que permitan en tener un sistema visual, con mejor entorno
gráfico y que nos brinde mayor seguridad a los datos, encontrándose las
siguientes deficiencias:

Deficiencias:

1.- El acceso al sistema es forma directa, no tiene ningún un mecanismo de seguridad


(no pide password para acceso al sistema) (Ver. Figura 12)

Figura N° 12 : Pantalla principal de acceso al Sistema Anterior

Fuente Municipalidad Provincial de Huancayo


Elaboracion Propia

Este es el formulario de acceso principal al sistema de trámite documentario, fue


desarrollado en Foxpro 2.6 y la base de datos es también tablas libres del mismo
Foxpro.

47
2.- Las tablas que contienen los datos de los administrados se encuentran expuestas,
pudiendo ser modificados y/o eliminados por cualquier usuario que ingresa con su clave
de acceso al servidor de datos en este caso es NOVELL NETWARE(Ver. Fig.21)

Figura N° 13 : Distribución de los archivos en el sistema anterior

Fuente Municipalidad Provincial de Huancayo


Elaboracion Propia

En este grafico se muestran que las tablas libres de Foxpro están expuestas para
cualquier usuario que tiene algún tipo de acceso al sistema global de la Municipalidad
Provincial de Huancayo.

3.- El sistema de trámite documentario no trabaja en línea con las cajas de cobranza,
se tiene que hacer una liquidación de forma manual para cada caso (Ver. Fig.22).

48
Figura N° 14 : El sistema anterior de tramite no trabaja en línea con las cajas

Fuente Municipalidad Provincial de Huancayo


Elaboracion Propia

Este grafico muestra que no existe conexión de la oficina de trámite


documentario con las cajas recaudadoras de la municipalidad, a pesar de tener
una red de comunicaciones entre todas las computadoras.

5.- El sistema no permite realizar el seguimiento del expediente, el registro


computarizado solo se realiza cuando se hace recepción documento y se
asigna el número del expediente y el resto del control se realiza en forma
manual.(Ver. Figura N° 14)

49
Figura N° 15 : Flujo grama de ingreso de expedientes del sistema anterior

Fuente Municipalidad Provincial de Huancayo


Elaboracion Propia

Requerimientos Funcionales del Sistema Actual

Tiene
1. Registro de Expedientes.

No Tiene
1. Modificar y Editar registro de expedientes
2. Control y Seguimiento de Expedientes
3. Estado actual del expediente.

4.3 FORMULACION DEL MODELO DEL SISTEMA DE TRÁMITE

4.3’.1. CASOS DE USO

50
- VALIDAR USUARIO
Actor: Sistema

1.- El Usuario Ingresa a la Interfaz del Sistema.


2.- El Usuario Ingresa Información
3.- El Sistema Valida la Información.
4.- El Sistema Visualiza la Información deseada.

Figura N° 16 : VALIDAR USUARIO

Fuente : Desarrollado con StarUML


Elaboración Propia

Este caso de uso muestra como el usuario primero ingresa al sistema, luego
consulta registro e inscripción y después valida si el registro es correcto.

- ATENCION DEL DOCUMENTO


Actor: Usuario

1.- El Usuario Ingresa a la Interfaz del Sistema.


2.- El Usuario Ingresa Información
3.- El Sistema Valida la Información.
4.- El Sistema Registra la Información.
5.- El Sistema Visualiza mensaje de éxito

51
Figura N° 17 : ATENCION DEL DOCUMENTO

Fuente : Desarrollado con StarUML


Elaboración Propia

Es iniciado por el Administrativo quien deriva el documento al área de destino


y este a su vez analiza el documento para emitir una respuesta y la vez
actualizar el estado del documento.

- REGISTRO DEL DOCUMENTO


Actor: Usuario

1.- El Usuario Ingresa a la Interfaz del Sistema.


2.- El Usuario presiona botón de petición de consulta
3.- El Sistema visualiza opciones de consulta
4.- El Sistema valida la Información.
5.- El Sistema filtra la consulta deseada.
6,- El Sistema Visualiza la información deseada

52
Figura N° 18 : REGISTRO DEL DOCUMENTO

Fuente : Desarrollado con StarUML


Elaboración Propia

Este caso de uso es iniciado por el usuario quien entrega el documento y a


su vez es verificado por el Administrativo encargado, y hace los registros
correspondientes en caso de que todo este conforme y luego lo deriva al área
de destino.

- CONSULTAS DE INFORMACION
Actor: Usuario

1.- El Usuario Ingresa a la Interfaz del Sistema.


2.- El Usuario presiona Botón Consulta Tupa o Consulta no Tupa
3.- El Sistema Procesa la Información.
4.- Visualiza la información.

53
Figura N° 19 : CONSULTA DE INFORMACION

Fuente : Desarrollado con StarUML


Elaboración Propia

Este caso de uso es iniciado por el usuario donde realiza una consulta sobre el
estado del trámite presentado, después de realizar la consulta se procede a
informar al usuario.

4.3.2 SECUENCIA
Ingreso al Sistema
Ingresa Usuario y Password.
Valida información y perfil:
Ingresa al sistema para procesar datos.
Realiza Proceso de Registro:
Devuelve datos del registro.

54
Figura N° 20 : Diagrama de Secuencia de Proceso de Registro

Fuente : Desarrollado con StarUML


Elaboración Propia

4.3.4 ACTIVIDADES
- Registro de Procedimientos, Requisitos o Usuarios.
(Actor: Administrador del Sistema)
- Elimina de Procedimientos, Requisitos o Usuarios.
(Actor: Administrador del Sistema)
- Actualizar de Procedimientos, Requisitos o Usuarios.
(Actor: Administrador del Sistema)
- Buscar Procedimientos, Requisitos o Usuarios.
(Actor: Administrador del Sistema)

55
4.3.5 PLATAFORMA TECNOLÓGICA:

La solución de desarrollo del Sistema deberá ser implementada bajo una


arquitectura de 3 capas:

 Capa de Presentación:
Es la que ve el usuario (también de la denomina “capa de usuario”),
presenta el sistema al usuario, le comunica la información y captura la
información del usuario en un mínimo de proceso (realiza un filtrado previo
para comprobar que no hay errores de formato). Esta etapa se comunica
únicamente con la capa de negocio. También es conocida como interfaz
gráfica y debe tener la característica de ser “amigable” (entendible y fácil
de usar) para el usuario,

 Capa de Negocio:
Es donde residen los programas que se ejecutan, se reciben las peticiones
del usuario y que se envían las respuestas tras el proceso. Se denomina
capa de negocio (e incluso de lógica del negocio) porque es aquí donde
se establecen todas las reglas que deben cumplirse. Esta etapa se
comunica con la capa de presentación, para recibir las solicitudes y
presentar los resultados, y con la capa de datos, para solicitar al gestor de
base de datos almacenar o recuperar datos de él. También se consideran
aquí los programas de aplicación.

 Capa de Datos:
Es donde residen los datos y es la encargada de acceder a los mismos.
Está conformada por uno o más gestores de bases de datos que realizan
todo el almacenamiento de datos, reciben solicitudes de almacenamiento
o recuperación de información desde la capa de negocios.

Las ventajas de usar esta arquitectura son las siguientes:

 El desarrollo se puede llevar a cabo en varios niveles.


 Desarrollos paralelos (en cada capa).

56
 Aplicaciones más robustas debido al encapsulamiento.
 En caso que sobrevenga algún cambio, solo se ataca al nivel requerido
sin tener que revisar ente código mezclado.
 Mantenimiento y soporte más sencillo (es más sencillo cambiar un
componente que modificar un aplicación monolítica).
 Mayor flexibilidad (se pueden añadir nuevos módulos para dotar al
sistema de nueva funcionalidad).
 Alta escalabilidad. La principal ventaja de un aplicación distribuida bien
diseñada es su buen escalamiento, es decir, que puede manejar muchas
peticiones con el mismo rendimiento simplemente añadiendo más
hardware.
 El crecimiento es casi lineal y no es necesario añadir más código para
conseguir esta escalabilidad.

Figura N° 21 : Diseño de Funcionamiento del Sistema

Capa de Presentación Capa de Negocio Capa de Datos

SERVIDOR DE SERVIDOR
CLIENTE NEGOCIACION DE BASE DE
ES DATOS

Fuente : Desarrollado con StarUML


Elaboración Propia

57
 Modalidad: Cliente – Servidor y Web para consultas.
 Lenguaje de programación: Java y/o Visual Fox 9.0.
 IDE para aplicaciones Web: NetBeans, PHP o Visual Studio.
 Software de Servidor de Aplicaciones Web: Tomcat - Apache
 Navegador: Internet Explorer, Mozilla, Chrome.
 Gestor de base de datos: MYSQL SERVER
 Sistema Operativo de Servidores: Windows Server / Linux.
 Sistema Operativo de Clientes: Windows XP o superior.
 Protocolo de transporte / red utilizado: Se conecta con el protocolo
TCP/IP.
 Reportes del sistema: Soportados en formato EXCEL, PDF, HTML, TXT.

4.4 DESARROLLO DEL SISTEMA DE TRÁMITE.

1. INTRODUCCIÓN

El presente documento detalla los lineamientos y procedimientos para


estándares de programación en el área de desarrollo con su respectiva
escritura de código fuente, el cual está orientado a Visual Fox Pro 9 y MySql
Server 5.0 y sus posteriores Versiones.

Estas normas deben seguirse para todo Software desarrollado por la Sub
Gerencia de Informática y/o Terceros contratados por la Municipalidad
Provincial de Huancayo para el desarrollo de Software, a excepción que para
el desarrollo de algún proyecto se determine conveniente seguir otras
recomendaciones y/o normas las cuales deberán estar adjuntadas en la
documentación del proyecto.

2. OBJETIVO

El objetivo es garantizar la continuidad, la integración e interoperabilidad de


las diversas aplicaciones de la Municipalidad Provincial de Huancayo.

58
Asegurar la legibilidad del modelo de datos, inclusive para personas que no
están relacionadas con el ambiente informático, en etapas de análisis y
diseño.

Facilitar la portabilidad entre motores de bases de datos, plataformas y


aplicaciones.

Facilitar la tarea de los programadores en el desarrollo de los sistemas.

3. ALCANCE

El presente documento es de aplicación obligatoria por la Sub Gerencia de


Tecnologías de la Información y Comunicaciones TIC’S, de la Municipalidad
Provincial de Huancayo, así como, todo el personal contratado para
desarrollo de Software dentro de la Institución y todas las dependencias de
la Municipalidad Provincial de Huancayo.

4. BASE DE DATOS MYSQL SERVER

a. CRITERIOS GENERALES

La estandarización de SQL de desarrollo web pretende dar a conocer


las operaciones que se pueden realizar con SQL y que tienen una
aplicación directa con la creación de aplicaciones en red sin profundizar
más de lo estrictamente necesario.

El nombre de los objetos usados en la base de datos no debe exceder


a 16 caracteres.

b. INSTALACION

i. REQUERIMIENTOS DE HARDWARE

 Pentium IV o superior, 2.4Mhz, recomendado 1 Ghz o


más.

59
 Memoria 512Mb, recomendada 1Gb o más.
 Disco con espacio de 5.2Gb (todas las aplicaciones)

ii. REQUERIMIENTOS DE SOFTWARE

 Linux
 Windows 7
 Windows Server 2003
 Windows Server 2008
 Windows Server 2012
 Windows Server 2012 R2

c. DIAGRAMA DE BASE DE DATOS

Figura N° 22 : Diagrama de Base de Datos de Tramite Documentario

Fuente Municipalidad Provincial de Huancayo


Elaboracion Propia

60
5. PROCESO DE DESARROLLO

El proceso de desarrollo contiene las actividades y tareas del desarrollador.


El proceso contiene las actividades para el análisis de los requisitos, diseño,
codificación, integración, pruebas e instalación y aceptación relacionadas
con el software. El desarrollador gestiona el Proceso de Desarrollo al nivel
de proyecto siguiendo el Proceso de Gestión, que se emplea en este
proceso; establece una infraestructura bajo el proceso siguiendo el Proceso
de infraestructura adapta el proceso al proyecto siguiendo el Proceso de
Adaptación y gestionar el proceso a nivel de organización siguiendo el
Proceso de Mejora y el Proceso de Recursos Humanos.

Cuando el desarrollador es el suministrador del producto software


desarrollado, el desarrollador lleva a cabo el Proceso de Suministro. Lista de
actividades: Este proceso consta de las siguientes actividades:

1. Implementación del proceso.

2. Análisis de los requisitos del sistema.

3. Diseño de la arquitectura del sistema.

4. Análisis de los requisitos software.

5. Diseño de la arquitectura del software.

6. Diseño detallado del software.

7. Codificación y pruebas del software.

8. Integración del software.

9. Pruebas de calificación del software.

10. Integración del sistema.

11. Pruebas de calificación del sistema.

12. Instalación del software.

61
13. Apoyo a la aceptación del software.

1. Implementación del proceso

Esta actividad consta de las siguientes tareas:

a. El desarrollador deberá definir o seleccionar un modelo de ciclo de vida


apropiado al alcance, magnitud y complejidad del proyecto.

b. Para este caso el desarrollador ha elegido la metodología RUP, llamada


así por sus siglas en inglés Rational Unified Process, divide en 4 fases

Inicio, Elaboración, Construcción, Transición.

2. Análisis de los requisitos del sistema

Esta actividad consta de las siguientes tareas, que el desarrollador deberá


llevar a cabo o proporcionar apoyo, según requiera el contrato:

a. Deberá analizarse el uso específico previsto del sistema a ser desarrollado


para especificar los requisitos del sistema. Se deberá documentar la
especificación de los requisitos del sistema.

b. Los requisitos del sistema deberán evaluarse teniendo en cuenta los


criterios descritos en la norma. Se deberán documentar los resultados de las
evaluaciones.

3. Diseño de la arquitectura del sistema

a. Esta actividad consta de las siguientes tareas: a. Deberá establecerse la


arquitectura del sistema a alto nivel.

b. Deberá evaluarse la arquitectura del sistema y los requisitos para los


elementos teniendo en cuenta los criterios enumerados en la norma. Se
deberán documentar los resultados de las evaluaciones.

62
4. Análisis de los requisitos software Para cada elemento software esta
actividad consta de las siguientes tareas:

a. El desarrollador deberá establecer y documentar los requisitos software


descritos en la norma, incluyendo la especificación de las características de
calidad.

b. El desarrollador deberá evaluar los requisitos software teniendo en cuenta


los criterios enumerados en la norma. Se deberán documentar los resultados
de la evaluación.

c. El desarrollador deberá llevar a cabo revisiones conjuntas de acuerdo a la


norma.

5. Diseño de la arquitectura del software Para cada elemento software, esta


actividad consta de las siguientes tareas:

a. El desarrollador deberá transformar los requisitos para el elemento


software en una arquitectura que describa su estructura a alto nivel e
identifique los componentes software.

b. El desarrollador deberá desarrollar y documentar un diseño a alto nivel


para las interfaces externas al elemento software y para las interfaces entre
los componentes software del elemento software.

c. El desarrollador deberá desarrollar y documentar un diseño a alto nivel


para la BD.

d. Conviene que el desarrollador desarrolle y documente versiones


preliminares de la documentación de usuario.

e. El desarrollador deberá definir y documentar los requisitos preliminares de


pruebas y la planificación para la Integración del software.

f. El desarrollador deberá evaluar la arquitectura del elemento software y de


los diseños de su interfaz y base de datos teniendo en cuenta los criterios

63
enumerados en la norma. Se deberán documentar los resultados de las
evaluaciones.

g. El desarrollador deberá llevar a cabo revisiones conjuntas de acuerdo a


norma

6. Diseño detallado del software Para cada elemento software, esta actividad
consta de las siguientes tareas:

a. El desarrollador deberá preparar un diseño detallado para cada


componente software del elemento software.
b. El desarrollador deberá preparar y documentar un diseño detallado para
las interfaces externas al elemento software, entre los componentes software
y las unidades software.
c. El desarrollador deberá preparar y documentar el diseño detallado para la
BD.
d. El desarrollador deberá actualizar la documentación de usuario si es
necesario.
e. El desarrollador deberá definir y documentar los requisitos de prueba y
planificar la prueba de las unidades.
f. El desarrollador deberá actualizar los requisitos de prueba y el plan para la
Integración del software.
g. El desarrollador deberá evaluar el diseño detallado del software y los
requisitos de prueba teniendo en cuenta los criterios descritos en la norma.
h. Se deberán documentar los resultados de la evaluación.
i. El desarrollador deberá llevar a cabo revisiones conjuntas de acuerdo a
norma.

7. Codificación y pruebas del software

Para cada elemento software (o para cada elemento de configuración


software, si se ha identificado), esta actividad consta de las siguientes tareas:
a. El desarrollador deberá desarrollar y documentar cada unidad software y

64
base de datos y procedimientos de prueba y datos para probar cada unidad
software y base de datos.
b. El desarrollador deberá probar cada unidad software y base de datos
asegurando que satisfacen sus requisitos. Se deberán documentar los
resultados.
c. El desarrollador deberá actualizar la documentación de usuario si es
necesario.
d. El desarrollador deberá actualizar los requisitos de prueba y el plan para la
Integración del software.
e. El desarrollador deberá evaluar el código software y los resultados de las
pruebas teniendo en cuenta los criterios enumerados en la norma. Se
deberán documentar los resultados de las evaluaciones.

8. Integración del software

Para cada elemento software, esta actividad consta de las siguientes tareas:
a. El desarrollador deberá preparar un plan de integración para integrar las
unidades software y los componentes software en el elemento software.
b. El desarrollador deberá integrar las unidades software y los componentes
software y probarlos a medida que se agrupan de acuerdo al plan de
integración.
c. El desarrollador deberá actualizar la documentación de usuario si es
necesario.
d. El desarrollador deberá preparar y documentar, para cada requisito de
calificación del elemento software, un conjunto de pruebas, casos de prueba
(entradas, salidas, criterios de prueba), y. procedimientos de prueba para
llevar a cabo las Pruebas de Calificación del software.
e. El desarrollador deberá evaluar el plan de integración, el diseño, el código,
las pruebas. Los resultados de las pruebas y la documentación de usuario
teniendo en cuenta los criterios enumerados en la norma. Se deberán
documentar los resultados de las evaluaciones.
f. El desarrollador debería llevar a cabo revisiones conjuntas de acuerdo a
norma.

65
9. Pruebas de calificación del software

Para cada elemento software, esta actividad consta de las siguientes tareas:
a. El desarrollador deberá llevar a cabo pruebas de calificación de acuerdo a
los requisitos de calificación para el elemento software.
b. El desarrollador deberá actualizar la documentación de usuario si es
necesario.
c. El desarrollador deberá evaluar el diseño, el código, las pruebas, los
resultados de las pruebas y la documentación de usuario teniendo en cuenta
los criterios enumerados en la norma. Se deberán documentar los resultados.
d. El desarrollador deberá proporcionar soporte a las auditorías de acuerdo a
norma. Se deberán documentar los resultados de las auditorías. Si hardware
y software están bajo desarrollo o integración, las auditorías pueden
posponerse hasta las Pruebas de Calificación del Sistema.
e. Tras la terminación con éxito de las auditorías, si se llevan a cabo, el
desarrollador deberá actualizar y preparar el producto software entregable
para la Integración del Sistema, Pruebas de Calificación del Sistema,
Instalación del software o Apoyo a la Aceptación del software, como proceda.

10. Integración del sistema

Esta actividad consta de las siguientes tareas, que el desarrollador deberá


llevar a cabo o proporcionar apoyo tal como requiere el contrato.
a. Los elementos de configuración software deberán integrarse con los
elementos de configuración hardware, operaciones manuales, y otros
sistemas si es necesario, para formar el sistema. Se deberán documentar los
resultados de la integración y pruebas.
b. Se deberá desarrollar y documentar para cada requisito de calificación del
sistema, un conjunto de pruebas, casos de prueba (entradas, salidas,
criterios de prueba) y procedimientos de prueba para llevar a cabo las
Pruebas de Calificación del Sistema.
c. El sistema integrado deberá evaluarse teniendo en cuenta los criterios
dados por la norma. Se deberán documentar los resultados de las
evaluaciones.

66
11. Pruebas de calificación del sistema

Esta actividad consta de las siguientes tareas que el desarrollador deberá


llevar a cabo o proporcionar apoyo, tal como requiera el contrato.
a. Las pruebas de calificación del sistema deberán llevarse a cabo de acuerdo
a los requisitos de calificación especificados para el sistema.
b. El sistema deberá evaluarse teniendo en cuenta los criterios enumerados
por la norma. Se deberán documentar los resultados de las evaluaciones.
c. El desarrollador deberá proporcionar apoyo a las auditorías de acuerdo a
norma. Se deberán documentar los resultados de las auditorias.
d. Tras la terminación con éxito de las auditorías, si se han llevado a cabo, el
desarrollador deberá: Actualizar y preparar el producto software entregable
para la Instalación del software y el Soporte a la aceptación del software.

12. Instalación del software

Esta actividad consta de las siguientes tareas:


a. El desarrollador deberá preparar un plan para instalar el producto software
en el entorno de destino tal como se especifique en el contrato.
b. El desarrollador deberá instalar el producto software de acuerdo con el plan
de instalación.

13. Apoyo a la aceptación del software

Esta actividad consta de las siguientes tareas:


a. El desarrollador deberá proporcionar apoyo a las revisiones y pruebas de
aceptación llevadas a cabo por el adquiriente del producto software.
b. El desarrollador deberá completar y entregar el producto software tal como
se especifique en el contrato.
c. El desarrollador deberá proporcionar formación inicial y continuada; el
software es parte primordial en el desarrollo de tecnologías de información.

67
MODELO DEL SISTEMA DE TRÁMITE DOCUMENTARIO

Figura N° 23 : Acceso al Sistema

Fuente Municipalidad Provincial de Huancayo


Elaboracion Propia

En la Fig. N° 23, muestra el acceso general al sistema de tramite documentario,


donde se valida el usuario y la contraseña y además el nivel de acceso del
usuario otorgado por el administrador del sistema.

68
Figura N° 24 : Menú Principal

Fuente Municipalidad Provincial de Huancayo


Elaboracion Propia

En la Fig. N° 24, muestra el menú principal del sistema, después de validar si es


correcto el usuario que acceso al sistema, aquí se puede ver todas las bondades
del sistema, que entre los menús más resaltante están el de registro de
expediente externos y el estado del expediente, además de las consultas y
reportes.

69
Figura N° 25 : Registro de Expedientes

Fuente Municipalidad Provincial de Huancayo


Elaboracion Propia

En la Fig. N° 25, muestra el procedimiento de registro de expedientes, es un


formulario donde se registra con el dni del contribuyente, el procedimiento que
se va aplicar y la oficina donde se va a derivar el documento.

70
Figura N° 26 : Buscar Contribuyente

Fuente Municipalidad Provincial de Huancayo


Elaboracion Propia

En la Fig. N° 26, muestra la búsqueda de contribuyente a realizar el registro, si


es que no se encuentra el cliente se procede a un nuevo registro de
contribuyente con los datos que se extraen de su dni como número de dni,
apellidos y nombres, dirección que son los datos principales de un documento
único de identidad.

71
Figura N° 27 : Reporte de Expedientes Entregados

Fuente Municipalidad Provincial de Huancayo


Elaboracion Propia

En la Fig. N° 27, muestra el reporte de expedientes entregados a todas las


oficinas que atienden algún tipo de tramite documentario.

72
Figura N° 28 : Reporte de Estado de Expediente

Fuente Municipalidad Provincial de Huancayo


Elaboracion Propia

En la Fig. N° 28, muestra el reporte de estado del expediente, este tipo de reporte
se encuentra disponible en todas las oficinas del palacio municipal para que los
encargados de las áreas o gerencias estén enterados del estado del expediente.

73
Figura N° 29 : Código Fuente de Acceso al Sistema

Fuente Municipalidad Provincial de Huancayo


Elaboracion Propia

En la Figura N° 29, se muestra parte del código fuente del acceso al sistema, en
el cual se puede apreciar procedimientos y métodos que son parte del lenguaje
de programación, y que pertenece a la programación orientada a objetos.

74
Figura N° 30 : Código Fuente de Registro de Expedientes

Fuente Municipalidad Provincial de Huancayo


Elaboracion Propia

En la Figura N° 30, se muestra parte del código fuente para el registro de


expedientes, donde se usan métodos y procedimientos para generar el número
de expediente, numero de liquidación si es que el expediente tiene derecho de
pago y grabar el expediente para ser procesado por las oficinas a donde serán
derivados los expedientes.

75
CAPITULO V:
RESULTADOS Y DISCUSION

En el presente capitulo se expone la información obtenida de los 2 periodos en


mención, respecto a las variables consideradas en el capítulo uno, de esta forma
se muestra los resultados después de la implementación del sistema de tramite
documentario en la Municipalidad Provincial de Huancayo.

5.1. PRESENTACION DE RESULTADOS

5.1.1. Sistema de Trámite Documentario


- Con respecto al indicador Media de tiempos de expedientes atendidos,
la evaluación de esta variable ha sido con el objetivo de medir la cantidad
de días que demora un expediente en ser atendido, cuyo indicador
principal fue la media de tiempos de expedientes atendidos.

Tabla 1: Media de Tiempos en atención de expedientes

Periodo Media de Tiempos N° de Expedientes Rango de los


días para
atención de
expedientes
2006 30.16 50 68.12
2015 9.6 60 44.98
Fuente: Elaboración Propia

Se determinó que el tiempo de respuesta en la atención de expedientes


del 2006 con respecto al 2015 se disminuyó en 20.56 días y/o 31.83%.
(Ver Anexo 1)

76
- Con respecto al indicador Grado de satisfacción del usuario interno, se
tienen los datos de la apreciación de la utilidad del sistema de trámite,
presentándose los siguientes resultados:

Tabla 2: Satisfacción del usuario interno sobre el sistema de trámite


documentario

Periodo Medianas de las encuestas de N° de


satisfacción de usuarios Encuestas
2006 8 20
2015 17 20
Fuente: Elaboración Propia

Se determinó que la satisfacción del usuario en el 2015 es mayor que en


el 2006. (Ver Anexo 2)

5.2 VALIDACION DE HIPOTESIS

Respecto a la hipótesis especifica 1 que indica:

1.- Mejorará los procesos más comunes el Desarrollo e Implementación del


Sistema de Tramite Documentario en la Municipalidad Provincial de
Huancayo para la atención de expedientes.

Respecto a ello se tienen los siguientes datos:

H0: El Sistema de trámite Documentario no disminuye el número de días de


respuesta de los procesos más comunes en la Municipalidad Provincial de
Huancayo.

77
H1: El Sistema de trámite Documentario disminuye el número de días de
respuesta de los procesos más comunes en la Municipalidad Provincial de
Huancayo.

Pruebas de normalidad

Periodo Kolmogorov-Smirnova Shapiro-Wilk

Estadístico gl Sig. Estadístico gl Sig.

2006 ,162 50 ,002 ,919 50 ,002


Dias para Atencion
2015 ,156 60 ,001 ,911 60 ,000

a. Corrección de la significación de Lilliefors

NORMALIDAD
P- Valor (2006) = 0.02 < α =0.05
P- Valor (2015) = 0,000148 < α =0.05

CONCLUSIÓN:

La prueba de hipótesis estadística que se va a aplicar es de Mann-Whitney


debido a que la variable tiempo de respuesta no tiene una distribución normal
(p<=0.05)

Respecto a la hipótesis especifica 2 que indica:

2.- El Desarrollo e Implementación del Sistema de Tramite Documentario en


la Municipalidad Provincial de Huancayo genera una mejor satisfacción de
los usuarios en la atención de expedientes.

H0: El Sistema de trámite Documentario no mejora la satisfacción del usuario


interno en la atención de expedientes en la Municipalidad Provincial de
Huancayo.

78
H1: El Sistema de trámite Documentario mejora la satisfacción del usuario
interno en la atención de expedientes en la Municipalidad Provincial de
Huancayo.

PRUEBA DE SUMA DE RANGOS DE WILCOXON


Estadísticos descriptivos

N Percentiles

25 50 (Mediana) 75

Satisfacción Usuario Interno 20 15,25 17,00 17,75


2015
Satisfacción Usuario Interno 20 7,00 8,00 8,75
2006

Rangos

N Rango Suma de
promedio rangos

Rangos negativos 20a 10,50 210,00


Satisfacción Usuario Interno
Rangos positivos 0b ,00 ,00
2006 - Satisfacción Usuario
Empates 0c
Interno 2015
Total 20

a. Satisfacción Usuario Interno 2006 < Satisfacción Usuario Interno 2015


b. Satisfacción Usuario Interno 2006 > Satisfacción Usuario Interno 2015
c. Satisfacción Usuario Interno 2006 = Satisfacción Usuario Interno 2015

Estadísticos de contrastea

Satisfacción Usuario Interno 2006 -


Satisfacción Usuario Interno 2015

Z -3,929b
Sig. asintót. (bilateral) ,000

a. Prueba de los rangos con signo de Wilcoxon


b. Basado en los rangos positivos.

La prueba de suma de rangos de Wilcoxon revela una mejora en la


satisfacción del usuario interno en la atención de expedientes en la
Municipalidad provincial de Huancayo, z=-3.929, p<0.000085.

79
5.3 DISCUSION DE RESULTADOS

Respecto a la hipótesis especifica 2 que indica:

2.- El Desarrollo e Implementación del Sistema de Tramite Documentario en


la Municipalidad Provincial de Huancayo genera una mejor satisfacción de
los usuarios en la atención de expedientes.

H0: El Sistema de trámite Documentario no mejora la satisfacción del usuario


interno en la atención de expedientes en la Municipalidad Provincial de
Huancayo.

H1: El Sistema de trámite Documentario mejora la satisfacción del usuario


interno en la atención de expedientes en la Municipalidad Provincial de
Huancayo.

PRUEBA DE SUMA DE RANGOS DE WILCOXON


Estadísticos descriptivos

N Percentiles

25 50 (Mediana) 75

Satisfacción Usuario Interno 20 15,25 17,00 17,75


2015
Satisfacción Usuario Interno 20 7,00 8,00 8,75
2006

80
Rangos

N Rango Suma de
promedio rangos

Rangos negativos 20a 10,50 210,00


Satisfacción Usuario Interno
Rangos positivos 0b ,00 ,00
2006 - Satisfacción Usuario
Empates 0c
Interno 2015
Total 20

a. Satisfacción Usuario Interno 2006 < Satisfacción Usuario Interno 2015


b. Satisfacción Usuario Interno 2006 > Satisfacción Usuario Interno 2015
c. Satisfacción Usuario Interno 2006 = Satisfacción Usuario Interno 2015

Estadísticos de contrastea

Satisfacción Usuario Interno 2006 -


Satisfacción Usuario Interno 2015

Z -3,929b
Sig. asintót. (bilateral) ,000

a. Prueba de los rangos con signo de Wilcoxon


b. Basado en los rangos positivos.

La prueba de suma de rangos de Wilcoxon revela una mejora en la


satisfacción del usuario interno en la atención de expedientes en la
Municipalidad provincial de Huancayo, z=-3.929, p<0.000085.

5.3 DISCUSIÓN DE RESULTADOS

Según los estudios realizados, la Tabla N° 3 presenta los resultados


obtenidos de acuerdo a las siguientes pruebas:
Tabla N° 3
Periodo 2006 2016
Media de Tiempos 30.16 9.6
Rango de los días para 68.12 44.98
atención de expedientes
Elaboración: Propia

81
A su vez, la Tabla N° 4 expone los resultados de las pruebas de hipótesis

Tabla N° 4
P(2006) P(2015)
Pruebas de normalidad K-S 0.02 0,000148
Elaboración: Propia

La prueba de suma de rangos de Wilcoxon presenta los valores de: z=-3.929 y


p<0.000085

De acuerdo a los resultados obtenidos se concluye que existe una diferencia


significativa entre antes y después de la aplicación del sistema de trámite
documentario.

82
CONCLUSIONES

1.- Con respecto a los indicadores antes mencionados, se puede afirmar


que mejoró en gran medida la atención de expedientes, esto debido a que
una de las consecuencias del uso del nuevo sistema implica que los
trabajadores de la Unidad de Trámite Documentario procesen la
información más rápido y organizadamente, ya que ahora los usuarios
estarán informados del movimiento de sus documentos una vez ya
ingresados al sistema interno.
2.- El sistema de trámite documentario como herramienta de gestión ha
permitido reducir los tiempos en la atención de expedientes hasta en un
30%.
3.- Con el presente trabajo, se ratifica que el Sistema de Tramite
Documentario es la herramienta de gestión que facilita la atención de
expedientes
4.- Se determinó una mejora en la satisfacción del usuario interno al
comparar las medianas de las encuestas de satisfacción de los periodos
2006 y 2015 siendo esta diferencia significativa con un valor de Z= -3.929
y p=0.0001

83
RECOMENDACIONES

1.- La oficina de trámite documentario por medio de la Gerencia de


Secretaria Municipal debe continuar con la implementación del sistema en
todas las oficinas y/o áreas
2.- Se recomienda que así como la persona encargada del módulo de
consultas y además también todos los trabajadores de la Institución
puedan resolver cualquier tipo de consulta acerca de los servicios
brindados por la Institución teniendo en cuenta que el ciudadano, usuario,
contribuyente o concurrente, es el principal cliente.
3.- Se recomienda que la persona encargada de recepcionar los
documentos al momento en que le solicitan consultas por cualquier
motivo, lo derive al módulo de consultas, para evitar la congestión o
aglomeración de personas en la cola, las personas sean orientadas y
distribuidas de una forma adecuada para evitar quejas y demoras.

84
REFERENCIA BIBLIOGRAFICA

1. A. de Amescua Seco, L. G.-F. (1995). Ingenieria del Software de


Gestiòn: Analisis y Diseño de Aplicaciones. Editorial Paraninfo.

2. Boria, J. (1987). Ingenieria de Software. Buenos Aires-Argentina:


McGrawHill.

3. Huancayo, M. P. (s.f.). www.munihuancayo.gob.pe. Obtenido de


www.munihuancayo.gob.pe: www.munihuancayo.gob.pe

4. Informatica, O. N. (2007). www.ongei.gob.pe. Obtenido de


www.ongei.gob.pe

5. ONGEI. (2013). Plan Nacional de Gobierno Electronico 2013-2017.


Oficina Nacional de Gobierno Electronico e Informatica , 83.

6. Sandoval, C. A. (2009). Sistema web de consultas para la gestion de


tramite documentario de la Municipalidad Provincial de Sullana-Piura.
Sullana - Piura: Universidad Cesar Vallejo.

7. Telecomunicaciones, U. I. (2007). Normas ITU. Obtenido de


http://www.itu.int/: www.itu.int

8. Valles Ojeda, M. O. (2010). Proyecto de Fortalecimiento de Capacidades


para la Implementacion del Sistema de Tramite Documentario en la
Municipalidad del Callao. Lima: Universidad Tecnologica del Peru.

85
ANEXOS

86
ANEXO 1
Pruebas no paramétricas – Prueba de Mann-Whitney
Media de Tiempos de Expedientes Atendidos

Rangos

Periodo N Rango Suma de


promedio rangos

2006 50 68,12 3406,00

Días para Atención 2015 60 44,98 2699,00

Total 110

Estadísticos de contrastea

Días para
Atención

U de Mann-Whitney 869,000
W de Wilcoxon 2699,000
Z -3,794
Sig. asintót. (bilateral) ,000

a. Variable de agrupación: Periodo

Resumen del procesamiento de los casos

Periodo Casos

Válidos Perdidos Total

N Porcentaje N Porcentaje N Porcentaje

2006 50 100,0% 0 0,0% 50 100,0%


Dias para Atencion
2015 60 100,0% 0 0,0% 60 100,0%

87
Descriptivos

Periodo Estadístico Error típ.

Media 30,16 3,939

Límite inferior 22,24


Intervalo de confianza para la media al 95%
Límite superior 38,08

Media recortada al 5% 29,57

Mediana 23,00

Varianza 775,688

2006 Desv. típ. 27,851

Mínimo -28

Máximo 84

Rango 112

Amplitud intercuartil 45

Asimetría ,394 ,337

Curtosis -,877 ,662


Días para Atención
Media 9,60 ,917

Límite inferior 7,77


Intervalo de confianza para la media al 95%
Límite superior 11,43

Media recortada al 5% 9,13

Mediana 7,50

Varianza 50,447

2015 Desv. típ. 7,103

Mínimo 1

Máximo 28

Rango 27

Amplitud intercuartil 10

Asimetría ,857 ,309

Curtosis ,067 ,608

88
89
ANEXO 2
Pruebas no paramétricas – Prueba de Wilcoxon
Para dos muestras relacionadas (Procesa la Encuesta)

Estadísticos descriptivos

N Percentiles

25 50 (Mediana) 75

Satisfacción Usuario Interno 2015 20 15,25 17,00 17,75


Satisfacción Usuario Interno 2006 20 7,00 8,00 8,75

Rangos

N Rango Suma de
promedio rangos

Rangos 20a 10,50 210,00


negativos

Satisfacción Usuario Interno 2006 - Rangos 0b ,00 ,00


Satisfacción Usuario Interno 2015 positivos

Empates 0c

Total 20

a. Satisfacción Usuario Interno 2006 < Satisfacción Usuario Interno 2015


b. Satisfacción Usuario Interno 2006 > Satisfacción Usuario Interno 2015
c. Satisfacción Usuario Interno 2006 = Satisfacción Usuario Interno 2015

Estadísticos de contraste

Satisfacción Usuario Interno 2006 -


Satisfacción Usuario Interno 2015

Z -3,929b
Sig. asintót. (bilateral) ,000

a. Prueba de los rangos con signo de Wilcoxon


b. Basado en los rangos positivos.

90
ANEXO 3 Validacion de los datos del periodo 2006-2015

Nro_Cas Periodo Orden Fec_Ope ID Fec_Reg Cod_Asu


ID_Est
Dias
1 2015 5 19/01/2015 25 05/01/2015 18 25 14 zalfa 1.64
2 2015 4 12/01/2015 52 05/01/2015 16 25 7 zbeta 0.84
3 2015 5 09/01/2015 143 05/01/2015 47 25 4 se1 27,85
4 2015 5 13/01/2015 148 05/01/2015 58 25 8 se2 7,103
5 2015 4 12/01/2015 294 06/01/2015 58 25 6 media1 30,16
6 2015 5 12/01/2015 310 06/01/2015 47 25 6 media2 9,6
7 2015 6 19/01/2015 369 07/01/2015 58 25 12
8 2015 4 13/01/2015 371 07/01/2015 18 25 6
9 2015 5 09/01/2015 375 07/01/2015 58 25 2
10 2015 6 21/01/2015 420 07/01/2015 58 25 14
11 2015 5 26/01/2015 429 07/01/2015 18 25 19
12 2015 4 02/02/2015 498 08/01/2015 15 25 25
13 2015 5 14/01/2015 630 08/01/2015 47 25 6
14 2015 4 19/01/2015 634 08/01/2015 18 25 11
15 2015 4 12/01/2015 664 08/01/2015 58 25 4
16 2015 5 21/01/2015 694 09/01/2015 18 25 12
17 2015 4 15/01/2015 704 09/01/2015 18 25 6
18 2015 4 16/01/2015 729 09/01/2015 18 25 7
19 2015 4 12/01/2015 791 09/01/2015 58 25 3
20 2015 4 15/01/2015 823 09/01/2015 47 25 6
21 2015 4 15/01/2015 854 12/01/2015 58 25 3
22 2015 4 15/01/2015 864 12/01/2015 18 25 3
23 2015 3 26/01/2015 924 12/01/2015 18 25 14
24 2015 8 19/01/2015 987 12/01/2015 18 25 7
25 2015 5 15/01/2015 1081 13/01/2015 47 25 2
26 2015 4 02/02/2015 1119 13/01/2015 15 25 20
27 2015 5 29/01/2015 1156 13/01/2015 46 25 16
28 2015 4 16/01/2015 1157 13/01/2015 58 25 3
29 2015 5 26/01/2015 1173 13/01/2015 18 25 13 91
30 2015 5 21/01/2015 1178 13/01/2015 18 25 8
31 2015 4 16/01/2015 1216 14/01/2015 58 25 2
32 2015 4 23/01/2015 1235 14/01/2015 18 25 9
33 2015 5 10/02/2015 1274 14/01/2015 18 25 27
34 2015 3 15/01/2015 1323 14/01/2015 58 25 1
35 2015 4 19/01/2015 1328 14/01/2015 58 25 5
36 2015 4 19/01/2015 1376 15/01/2015 58 25 4
37 2015 5 29/01/2015 1427 15/01/2015 16 25 14
38 2015 4 16/01/2015 1433 15/01/2015 18 25 1
39 2015 5 21/01/2015 1438 15/01/2015 18 25 6
40 2015 4 23/01/2015 1486 15/01/2015 58 25 8
41 2015 4 21/01/2015 1664 16/01/2015 18 25 5
42 2015 4 29/01/2015 1699 16/01/2015 18 25 13
43 2015 4 20/01/2015 1738 19/01/2015 15 25 1
44 2015 5 02/02/2015 1803 19/01/2015 18 25 14
45 2015 4 20/01/2015 1804 19/01/2015 58 25 1
46 2015 5 18/02/2015 1811 19/01/2015 18 25 30
47 2015 4 21/01/2015 1867 19/01/2015 16 25 2
48 2015 4 21/01/2015 1875 19/01/2015 58 25 2
49 2015 5 02/02/2015 1899 19/01/2015 18 25 14
50 2015 4 02/02/2015 1977 20/01/2015 18 25 13
51 2015 5 26/02/2015 2019 20/01/2015 18 25 37
52 2015 5 04/02/2015 2095 20/01/2015 58 25 15
53 2015 5 26/01/2015 2102 20/01/2015 47 25 6
54 2015 7 10/02/2015 2150 21/01/2015 46 25 20
55 2015 5 29/01/2015 2295 21/01/2015 18 25 8
56 2015 4 06/02/2015 2404 22/01/2015 18 25 15
57 2015 3 23/01/2015 2448 22/01/2015 15 25 1
58 2015 5 03/02/2015 2478 22/01/2015 18 25 12
59 2015 4 06/02/2015 2481 22/01/2015 18 25 15
60 2015 4 16/02/2015 2485 22/01/2015 14 25 25
61 2006 5 04/05/2006 10022 12/04/2006 58 25 22
62 2006 1 18/08/2006 10030 13/01/2006 18 25 217 92
63 2006 4 12/04/2006 10033 18/01/2006 47 25 84
64 2006 14 20/04/2006 10101 24/02/2006 46 25 55
65 2006 2 14/04/2006 10104 24/02/2006 58 25 49
66 2006 2 04/05/2006 10110 17/04/2006 15 25 17
67 2006 2 05/05/2006 2710 20/02/2006 24 25 74
68 2006 2 23/03/2006 4620 23/02/2006 58 25 28
69 2006 4 23/02/2006 4166 14/02/2006 58 25 9
70 2006 3 23/02/2016 2626 30/01/2016 24 25 24
71 2006 2 17/02/2006 4379 15/02/2006 47 25 2
72 2006 2 21/02/2006 4193 14/02/2006 46 25 7
73 2006 2 25/02/2016 5542 25/02/2016 14 25 0
74 2006 3 27/02/2006 5561 10/01/2006 18 25 48
75 2006 3 27/02/2006 5827 20/02/2006 47 25 7
76 2006 2 28/02/2006 4554 16/02/2006 58 25 12
77 2006 2 17/04/2006 6472 06/03/2006 15 25 42
78 2006 2 09/03/2006 1890 24/01/2006 14 25 44
79 2006 2 09/03/2006 6300 03/03/2006 24 25 6
80 2006 2 10/03/2006 1294 18/01/2006 16 25 51
81 2006 2 17/04/2006 2205 26/01/2006 24 25 81
82 2006 4 14/08/2006 20156 08/08/2006 58 25 6
83 2006 2 11/08/2006 7246 14/03/2006 14 25 150
84 2006 2 14/03/2006 7060 10/03/2006 24 25 4
85 2006 2 17/03/2006 7200 13/03/2006 58 25 4
86 2006 2 17/03/2006 2042 25/01/2006 42 25 51
87 2006 2 17/03/2006 3401 07/02/2006 47 25 38
88 2006 3 16/03/2006 7559 10/03/2006 47 25 6
89 2006 2 16/03/2006 3299 06/02/2006 15 25 38
90 2006 2 29/04/2006 8629 28/03/2006 58 25 32
91 2006 2 05/04/2006 9381 30/03/2006 58 25 6
92 2006 2 05/04/2006 5478 24/02/2006 10 25 40
93 2006 2 11/04/2006 9320 04/04/2006 58 25 7
94 2006 2 19/04/2006 9587 06/04/2006 24 25 13
95 2006 3 19/04/2006 9230 03/04/2006 46 25 16 93
96 2006 2 21/04/2006 9870 11/04/2006 46 25 10
97 2006 2 22/05/2006 7915 21/03/2006 42 25 62
98 2006 2 27/04/2006 8164 22/03/2006 58 25 36
99 2006 3 27/04/2006 9967 12/04/2006 46 25 15
100 2006 2 07/11/2006 3273 06/02/2006 42 25 274
101 2006 2 13/11/2006 5112 22/02/2006 46 25 264
102 2006 2 02/05/2006 2038 23/02/2006 24 25 68
103 2006 3 03/05/2006 2036 02/05/2006 15 25 1
104 2006 7 04/06/2006 9514 04/05/2006 46 25 31
105 2006 2 04/05/2006 11466 02/05/2006 18 25 2
106 2006 8 10/05/2006 12246 04/05/2006 58 25 6
107 2006 2 10/05/2006 12003 08/05/2006 58 25 2
108 2006 2 16/05/2006 1205 17/01/2006 24 25 119
109 2006 4 18/05/2006 2036 12/05/2006 200 25 6
110 2006 4 18/05/2006 5188 07/03/2006 42 25 72

94
ANEXO 4: ENCUESTA SOBRE EL SISTEMA DE TRÁMITE DOCUMENTARIO

Gerencia/Sub gerencia y/o Área……………………………………………………

1.- Por favor indique su grado de satisfacción del sistema de trámite

a.- Excelente d.- Malo


b.- Bueno e.- Muy malo
c.- Regular

2.- Para usted. cuantos días demoraría un trámite documentario

a.- 6 Excelente d.- 24 Malo


b.- 12 Bueno e.- 30 Muy malo
c.- 18 Regular

3.- Considera útil el sistema de trámite

a.- Si

b.- No

4.- Recomendaría usted el sistema a otras trabajadores de la institución

a.- Si

b.- No

5.- Cual de las siguientes procesos del sistema considera lo más resaltante?

a.- Ágil d.- Regular


b.- Intuitivo e.- No sabe/no opina
c.- Fácil de usar

95
ANEXO 5 Prueba piloto de tiempos de respuesta del periodo 2006-2015

Nro_Cas
Periodo Orden
Fec_Ope ID Fec_Reg Cod_Asu
ID_EstDias
1 2015 5 19/01/2015 25 05/01/2015 18 25 14 media 9,6 zalfa 1.64
2 2015 4 12/01/2015 52 05/01/2015 16 25 7 se1 6,28831 zbeta 0.84
3 2015 5 09/01/2015 143 05/01/2015 47 25 4 se1 6,28831115
4 2015 5 13/01/2015 148 05/01/2015 58 25 8 se2 54,8398534
5 2015 4 12/01/2015 294 06/01/2015 58 25 6 media1 9,6
6 2015 5 12/01/2015 310 06/01/2015 47 25 6 media2 42,8666667
7 2015 6 19/01/2015 369 07/01/2015 58 25 12
8 2015 4 13/01/2015 371 07/01/2015 18 25 6
9 2015 5 09/01/2015 375 07/01/2015 58 25 2
10 2015 6 21/01/2015 420 07/01/2015 58 25 14
11 2015 5 26/01/2015 429 07/01/2015 18 25 19
12 2015 4 02/02/2015 498 08/01/2015 15 25 25
13 2015 5 14/01/2015 630 08/01/2015 47 25 6
14 2015 4 19/01/2015 634 08/01/2015 18 25 11
15 2015 4 12/01/2015 664 08/01/2015 58 25 4
16 2006 5 04/05/2006 10022 12/04/2006 58 25 22 media 42,8667
17 2006 1 18/08/2006 10030 13/01/2006 18 25 217 se2 54,8399
18 2006 4 12/04/2006 10033 18/01/2006 47 25 84
19 2006 14 20/04/2006 10101 24/02/2006 46 25 55
20 2006 2 14/04/2006 10104 24/02/2006 58 25 49
21 2006 2 04/05/2006 10110 17/04/2006 15 25 17
22 2006 2 05/05/2006 2710 20/02/2006 24 25 74
23 2006 2 23/03/2006 4620 23/02/2006 58 25 28
24 2006 4 23/02/2006 4166 14/02/2006 58 25 9
25 2006 3 23/02/2016 2626 30/01/2016 24 25 24
26 2006 2 17/02/2006 4379 15/02/2006 47 25 2
27 2006 2 21/02/2006 4193 14/02/2006 46 25 7
28 2006 2 25/02/2016 5542 25/02/2016 14 25 0
29 2006 3 27/02/2006 5561 10/01/2006 18 25 48
30 2006 3 27/02/2006 5827 20/02/2006 47 25 7
96
ANEXO 6 Procesos mas comunes para atencion en la Municipalidad Provincial de Huancayo

Codasu Detalle
10 CERTIFICACIONES Y/O CONSTANCIAS DIVERSAS- PARAMETROS URB.
14 CERTIFICADO NEGATIVO DE CATASTRO
15 VISACION DE PLANOS
16 CONFORMIDAD DE OBRA Y DECLARATORIA DE EDIFICACION
18 CERT. Y ASIGNACION DE NUMERACION DE FINCA
24 OCUPACION DE AREAS PUBLICAS
42 ANUNCIOS PUBLICITARIOS EVENTUALES- PERIFONEO
46 AUTORIZACION DE ROTURA DE PISTAS Y/O VEREDAS (PARA INSTALACION DE SERVICIOS PUBLICOS DE AGUA Y DESAGÜE)
47 REGULARIZACION DE HABILITACIONES URBANAS
58 LICENCIA DE CERCOS
200 SILENCIO ADMINISTRATIVO

97

También podría gustarte