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
