Subido por alonso_98915

Bastidas Parraga

Anuncio
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
3
OBJETIVOS.
1.3.1 Objetivos General
3
1.3.2 Objetivos Específicos
3
1.4
4
JUSTIFICACION E IMPORTANCIA.
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
7
SISTEMA DE HIPOTESIS
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
Documentario
expedientes registrados, emitidos
a
los
diferentes usuario interno
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-2007PCM, 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
CLIENTE
ES
Capa de Negocio
SERVIDOR DE
NEGOCIACION
Capa de Datos
SERVIDOR
DE BASE DE
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
ii.

Memoria 512Mb, recomendada 1Gb o más.

Disco con espacio de 5.2Gb (todas las aplicaciones)
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°
satisfacción de usuarios
de
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
Estadístico
gl
Shapiro-Wilk
Sig.
Estadístico
gl
Sig.
2006
,162
50
,002
,919
50
,002
2015
,156
60
,001
,911
60
,000
Dias para Atencion
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
Satisfacción Usuario Interno
50 (Mediana)
75
20
15,25
17,00
17,75
20
7,00
8,00
8,75
2015
Satisfacción Usuario Interno
2006
Rangos
N
Satisfacción Usuario Interno
Suma de
promedio
rangos
Rangos negativos
20a
10,50
210,00
Rangos positivos
0b
,00
,00
Empates
0c
Total
20
2006 - Satisfacción Usuario
Interno 2015
Rango
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
Sig. asintót. (bilateral)
-3,929b
,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
Satisfacción Usuario Interno
50 (Mediana)
75
20
15,25
17,00
17,75
20
7,00
8,00
8,75
2015
Satisfacción Usuario Interno
2006
80
Rangos
N
Satisfacción Usuario Interno
Suma de
promedio
rangos
Rangos negativos
20a
10,50
210,00
Rangos positivos
0b
,00
,00
Empates
0c
Total
20
2006 - Satisfacción Usuario
Interno 2015
Rango
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
-3,929b
Z
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
Pruebas de normalidad K-S
P(2006)
P(2015)
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
Días para Atención
N
Rango
Suma de
promedio
rangos
2006
50
68,12
3406,00
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
N
Perdidos
Porcentaje
N
Total
Porcentaje
N
Porcentaje
2006
50
100,0%
0
0,0%
50
100,0%
2015
60
100,0%
0
0,0%
60
100,0%
Dias para Atencion
87
Descriptivos
Periodo
Estadístico
Media
Error típ.
30,16
Límite inferior
22,24
Límite superior
38,08
3,939
Intervalo de confianza para la media al 95%
2006
Media recortada al 5%
29,57
Mediana
23,00
Varianza
775,688
Desv. típ.
27,851
Mínimo
-28
Máximo
84
Rango
112
Amplitud intercuartil
45
Asimetría
,394
,337
Curtosis
-,877
,662
9,60
,917
Días para Atención
Media
Límite inferior
7,77
Límite superior
11,43
Intervalo de confianza para la media al 95%
2015
Media recortada al 5%
9,13
Mediana
7,50
Varianza
50,447
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
Rangos
Rango
Suma de
promedio
rangos
20a
10,50
210,00
0b
,00
,00
negativos
Satisfacción Usuario Interno 2006 -
Rangos
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
Sig. asintót. (bilateral)
-3,929b
,000
a. Prueba de los rangos con signo de Wilcoxon
b. Basado en los rangos positivos.
90
ANEXO 3
Nro_Cas Periodo Orden
1
2015
5
2
2015
4
3
2015
5
4
2015
5
5
2015
4
6
2015
5
7
2015
6
8
2015
4
9
2015
5
10
2015
6
11
2015
5
12
2015
4
13
2015
5
14
2015
4
15
2015
4
16
2015
5
17
2015
4
18
2015
4
19
2015
4
20
2015
4
21
2015
4
22
2015
4
23
2015
3
24
2015
8
25
2015
5
26
2015
4
27
2015
5
28
2015
4
29
2015
5
Validacion de los datos del periodo 2006-2015
Fec_Ope
ID
Fec_Reg
Cod_Asu
ID_Est
Dias
19/01/2015
25 05/01/2015
18 25 14
12/01/2015
52 05/01/2015
16 25
7
09/01/2015
143 05/01/2015
47 25
4
13/01/2015
148 05/01/2015
58 25
8
12/01/2015
294 06/01/2015
58 25
6
12/01/2015
310 06/01/2015
47 25
6
19/01/2015
369 07/01/2015
58 25 12
13/01/2015
371 07/01/2015
18 25
6
09/01/2015
375 07/01/2015
58 25
2
21/01/2015
420 07/01/2015
58 25 14
26/01/2015
429 07/01/2015
18 25 19
02/02/2015
498 08/01/2015
15 25 25
14/01/2015
630 08/01/2015
47 25
6
19/01/2015
634 08/01/2015
18 25 11
12/01/2015
664 08/01/2015
58 25
4
21/01/2015
694 09/01/2015
18 25 12
15/01/2015
704 09/01/2015
18 25
6
16/01/2015
729 09/01/2015
18 25
7
12/01/2015
791 09/01/2015
58 25
3
15/01/2015
823 09/01/2015
47 25
6
15/01/2015
854 12/01/2015
58 25
3
15/01/2015
864 12/01/2015
18 25
3
26/01/2015
924 12/01/2015
18 25 14
19/01/2015
987 12/01/2015
18 25
7
15/01/2015 1081 13/01/2015
47 25
2
02/02/2015 1119 13/01/2015
15 25 20
29/01/2015 1156 13/01/2015
46 25 16
16/01/2015 1157 13/01/2015
58 25
3
26/01/2015 1173 13/01/2015
18 25 13
zalfa
zbeta
se1
se2
media1
media2
1.64
0.84
27,85
7,103
30,16
9,6
91
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
2015
2015
2015
2015
2015
2015
2015
2015
2015
2015
2015
2015
2015
2015
2015
2015
2015
2015
2015
2015
2015
2015
2015
2015
2015
2015
2015
2015
2015
2015
2015
2006
2006
5
4
4
5
3
4
4
5
4
5
4
4
4
4
5
4
5
4
4
5
4
5
5
5
7
5
4
3
5
4
4
5
1
21/01/2015 1178 13/01/2015
16/01/2015 1216 14/01/2015
23/01/2015 1235 14/01/2015
10/02/2015 1274 14/01/2015
15/01/2015 1323 14/01/2015
19/01/2015 1328 14/01/2015
19/01/2015 1376 15/01/2015
29/01/2015 1427 15/01/2015
16/01/2015 1433 15/01/2015
21/01/2015 1438 15/01/2015
23/01/2015 1486 15/01/2015
21/01/2015 1664 16/01/2015
29/01/2015 1699 16/01/2015
20/01/2015 1738 19/01/2015
02/02/2015 1803 19/01/2015
20/01/2015 1804 19/01/2015
18/02/2015 1811 19/01/2015
21/01/2015 1867 19/01/2015
21/01/2015 1875 19/01/2015
02/02/2015 1899 19/01/2015
02/02/2015 1977 20/01/2015
26/02/2015 2019 20/01/2015
04/02/2015 2095 20/01/2015
26/01/2015 2102 20/01/2015
10/02/2015 2150 21/01/2015
29/01/2015 2295 21/01/2015
06/02/2015 2404 22/01/2015
23/01/2015 2448 22/01/2015
03/02/2015 2478 22/01/2015
06/02/2015 2481 22/01/2015
16/02/2015 2485 22/01/2015
04/05/2006 10022 12/04/2006
18/08/2006 10030 13/01/2006
18
58
18
18
58
58
58
16
18
18
58
18
18
15
18
58
18
16
58
18
18
18
58
47
46
18
18
15
18
18
14
58
18
25
8
25
2
25
9
25 27
25
1
25
5
25
4
25 14
25
1
25
6
25
8
25
5
25 13
25
1
25 14
25
1
25 30
25
2
25
2
25 14
25 13
25 37
25 15
25
6
25 20
25
8
25 15
25
1
25 12
25 15
25 25
25 22
25 217
92
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
2006
2006
2006
2006
2006
2006
2006
2006
2006
2006
2006
2006
2006
2006
2006
2006
2006
2006
2006
2006
2006
2006
2006
2006
2006
2006
2006
2006
2006
2006
2006
2006
2006
4
14
2
2
2
2
4
3
2
2
2
3
3
2
2
2
2
2
2
4
2
2
2
2
2
3
2
2
2
2
2
2
3
12/04/2006
20/04/2006
14/04/2006
04/05/2006
05/05/2006
23/03/2006
23/02/2006
23/02/2016
17/02/2006
21/02/2006
25/02/2016
27/02/2006
27/02/2006
28/02/2006
17/04/2006
09/03/2006
09/03/2006
10/03/2006
17/04/2006
14/08/2006
11/08/2006
14/03/2006
17/03/2006
17/03/2006
17/03/2006
16/03/2006
16/03/2006
29/04/2006
05/04/2006
05/04/2006
11/04/2006
19/04/2006
19/04/2006
10033
10101
10104
10110
2710
4620
4166
2626
4379
4193
5542
5561
5827
4554
6472
1890
6300
1294
2205
20156
7246
7060
7200
2042
3401
7559
3299
8629
9381
5478
9320
9587
9230
18/01/2006
24/02/2006
24/02/2006
17/04/2006
20/02/2006
23/02/2006
14/02/2006
30/01/2016
15/02/2006
14/02/2006
25/02/2016
10/01/2006
20/02/2006
16/02/2006
06/03/2006
24/01/2006
03/03/2006
18/01/2006
26/01/2006
08/08/2006
14/03/2006
10/03/2006
13/03/2006
25/01/2006
07/02/2006
10/03/2006
06/02/2006
28/03/2006
30/03/2006
24/02/2006
04/04/2006
06/04/2006
03/04/2006
47
46
58
15
24
58
58
24
47
46
14
18
47
58
15
14
24
16
24
58
14
24
58
42
47
47
15
58
58
10
58
24
46
25 84
25 55
25 49
25 17
25 74
25 28
25
9
25 24
25
2
25
7
25
0
25 48
25
7
25 12
25 42
25 44
25
6
25 51
25 81
25
6
25 150
25
4
25
4
25 51
25 38
25
6
25 38
25 32
25
6
25 40
25
7
25 13
25 16
93
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
2006
2006
2006
2006
2006
2006
2006
2006
2006
2006
2006
2006
2006
2006
2006
2
2
2
3
2
2
2
3
7
2
8
2
2
4
4
21/04/2006 9870 11/04/2006
22/05/2006 7915 21/03/2006
27/04/2006 8164 22/03/2006
27/04/2006 9967 12/04/2006
07/11/2006 3273 06/02/2006
13/11/2006 5112 22/02/2006
02/05/2006 2038 23/02/2006
03/05/2006 2036 02/05/2006
04/06/2006 9514 04/05/2006
04/05/2006 11466 02/05/2006
10/05/2006 12246 04/05/2006
10/05/2006 12003 08/05/2006
16/05/2006 1205 17/01/2006
18/05/2006 2036 12/05/2006
18/05/2006 5188 07/03/2006
46
42
58
46
42
46
24
15
46
18
58
58
24
200
42
25 10
25 62
25 36
25 15
25 274
25 264
25 68
25
1
25 31
25
2
25
6
25
2
25 119
25
6
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
Nro_Cas
Periodo Orden
Fec_Ope
1
2015 5 19/01/2015
2
2015 4 12/01/2015
3
2015 5 09/01/2015
4
2015 5 13/01/2015
5
2015 4 12/01/2015
6
2015 5 12/01/2015
7
2015 6 19/01/2015
8
2015 4 13/01/2015
9
2015 5 09/01/2015
10
2015 6 21/01/2015
11
2015 5 26/01/2015
12
2015 4 02/02/2015
13
2015 5 14/01/2015
14
2015 4 19/01/2015
15
2015 4 12/01/2015
16
2006 5 04/05/2006
17
2006 1 18/08/2006
18
2006 4 12/04/2006
19
2006 14 20/04/2006
20
2006 2 14/04/2006
21
2006 2 04/05/2006
22
2006 2 05/05/2006
23
2006 2 23/03/2006
24
2006 4 23/02/2006
25
2006 3 23/02/2016
26
2006 2 17/02/2006
27
2006 2 21/02/2006
28
2006 2 25/02/2016
29
2006 3 27/02/2006
30
2006 3 27/02/2006
Prueba piloto de tiempos de respuesta del periodo 2006-2015
ID
25
52
143
148
294
310
369
371
375
420
429
498
630
634
664
10022
10030
10033
10101
10104
10110
2710
4620
4166
2626
4379
4193
5542
5561
5827
Fec_Reg
Cod_Asu
ID_EstDias
05/01/2015
18 25
14
05/01/2015
16 25
7
05/01/2015
47 25
4
05/01/2015
58 25
8
06/01/2015
58 25
6
06/01/2015
47 25
6
07/01/2015
58 25
12
07/01/2015
18 25
6
07/01/2015
58 25
2
07/01/2015
58 25
14
07/01/2015
18 25
19
08/01/2015
15 25
25
08/01/2015
47 25
6
08/01/2015
18 25
11
08/01/2015
58 25
4
12/04/2006
58 25
22
13/01/2006
18 25
217
18/01/2006
47 25
84
24/02/2006
46 25
55
24/02/2006
58 25
49
17/04/2006
15 25
17
20/02/2006
24 25
74
23/02/2006
58 25
28
14/02/2006
58 25
9
30/01/2016
24 25
24
15/02/2006
47 25
2
14/02/2006
46 25
7
25/02/2016
14 25
0
10/01/2006
18 25
48
20/02/2006
47 25
7
media
se1
9,6
6,28831
media
se2
42,8667
54,8399
zalfa
zbeta
se1
se2
media1
media2
1.64
0.84
6,28831115
54,8398534
9,6
42,8666667
96
ANEXO 6 Procesos mas comunes para atencion en la Municipalidad Provincial de Huancayo
Codasu
10
14
15
16
18
24
42
46
47
58
200
Detalle
CERTIFICACIONES Y/O CONSTANCIAS DIVERSAS- PARAMETROS URB.
CERTIFICADO NEGATIVO DE CATASTRO
VISACION DE PLANOS
CONFORMIDAD DE OBRA Y DECLARATORIA DE EDIFICACION
CERT. Y ASIGNACION DE NUMERACION DE FINCA
OCUPACION DE AREAS PUBLICAS
ANUNCIOS PUBLICITARIOS EVENTUALES- PERIFONEO
AUTORIZACION DE ROTURA DE PISTAS Y/O VEREDAS (PARA INSTALACION DE SERVICIOS PUBLICOS DE AGUA Y DESAGÜE)
REGULARIZACION DE HABILITACIONES URBANAS
LICENCIA DE CERCOS
SILENCIO ADMINISTRATIVO
97
Descargar