Proyecto de Tesis - Aplicación Web Control Servicios Soporte Técnico

UNIVERSIDAD CÉSAR VALLEJO PIURA FACULTAD DE INGENIERÍA ESCUELA DE INGENIERÍA DE SISTEMAS “Sistema de Control para las Tareas del Servicio de Soporte Técnico de la Oficina de Informática de la Municipalidad Provincial de Piura mediante una Aplicación Web” Proyecto de tesis Autor Pino Chacón Jesús Antonio Manuel

Asesor Mg. Luis Velez Ubillus

Piura - Perú

Universidad César Vallejo-Piura

Escuela Ingeniería Sistemas

(2011)

ASESORES DE TESIS

ASESOR METODOLÓGICO:

___________________ Mg. Luis Velez Ubillus

ASESOR ESPECIALISTA:

____________________ Ing. Noelia Saavedra Nizama

Sistema de Control para las Tareas del Servicio de Soporte Técnico de la Oficina de Informática de la Municipalidad Provincial de Piura mediante una Aplicación Web

2

Jesús Antonio Pino Chacón



INTRODUCCIÓN El constante y permanente avance tecnológico en el manejo de información con sistemas cada vez más sofisticados debido al ambiente competitivo en que vivimos, todo esto tiene como consecuencia un notorio cambio para la Oficina de Informática, redefiniendo sus objetivos y estrategias que le permitan cambiar la estructura de las vías de distribución y rediseñar procesos para mejorar sus servicios, obteniéndose la automatización de varios procesos del sistema de control para así minimizar las barreras del tiempo y distancia, facilitar el acceso a fuentes de información y potenciar el desarrollo de los servicios, además incide favorablemente en la eficiencia operativa, la calidad de los servicios prestados, el acercamiento con los usuarios o trabajadores que laboran en la municipalidad provincial de Piura y la coordinación de actividades. En la presente tesis, desarrollo e implementación, se busca mejorar el sistema de control para las tareas del servicio de soporte técnico, sumado al crecimiento de nuevas técnicas, herramientas y filosofías orientadas a la optimización de los medios, teniendo como prioridad prevenir y reducir los riesgos suscitados en las tareas operativas y administrativas relacionadas con la conservación y los servicios de mantenimiento que se brindan.


3




DEDICATORIA El presente proyecto de investigación se lo dedico a Dios y a mis padres por su comprensión y ayuda en todo momento. Mis padres me han enseñado a ser perseverante para encarar las adversidades de la vida sin perder nunca la fe y la esperanza ni desfallecer en el intento de alcanzar nuestros objetivos y metas. El Autor Sistema de Control para las Tareas del Servicio de Soporte Técnico de la Oficina de Informática de la Municipalidad Provincial de Piura mediante una Aplicación Web

4




AGRADECIMIENTO Agradezco primeramente a Dios por haberme motivado para realizar el presente proyecto de tesis, agradezco también a mis padres por su apoyo incondicional y por estar siempre a mi lado, a mis maestros porque a través de sus enseñanzas lograron transmitirme sus conocimientos e inculcarme el deseo por la investigación. El Autor


5




ÍNDICE Nº Página

INDICE DE GRAFICOS Y CUADROS Nº Página Cuadro N° 001: Política Institucionales..........................................................................21 Gráfico N° 001: Organigrama de la Municipalidad Provincial de Piura......................23 Gráfico N° 002: Esquema general de un sistema..........................................................26 Gráfico N° 003: Esquema general de un sistema de control.......................................28 Gráfico N° 004: MVC de arquitectura Tipo 1 ..................................................................32 Gráfico N° 005: MVC de arquitectura Tipo 2 ..................................................................32 Gráfico N° 006: Gestión de Incidentes............................................................................40 Gráfico N° 007: Proceso de Gestión de Incidentes (resumen) ...................................41 Gráfico N° 008: Diagrama de Prioridades Del Incidente...............................................44 Gráfico N° 009: Proceso de Escalado de Incidentes.....................................................45 Gráfico N° 010: Procesos implicados en la Gestión de Incidentes.............................46 Gráfico N° 011: Interacciones y Funcionalidades de la Gestión de Problemas........47 Gráfico N° 012: Procesos Implicados en la Gestión de Problemas............................50 Gráfico N° 013: Control de Problemas............................................................................50 Gráfico N° 014: Control de Errores..................................................................................53 Gráfico N° 015: Metodologías de Desarrollo de Software............................................55 Gráfico N° 016: Dos Dimensiones de RUP.....................................................................57 Sistema de Control para las Tareas del Servicio de Soporte Técnico de la Oficina de Informática de la Municipalidad Provincial de Piura mediante una Aplicación Web

6




Gráfico N° 017: Proceso Iterativo Incremental...............................................................59 Gráfico N° 018: Proceso FDD...........................................................................................64 Cuadro N° 002: Indicadores de la Variable Dependiente..............................................67 Cuadro N° 003: Indicadores, Técnicas e Instrumentos de Recolección de Datos....74 Cuadro N° 004: Cronograma de Actividades de la Tesis..............................................76 Cuadro N° 005: Presupuesto de la Tesis........................................................................77

________________________________________________________

CAPITULO I: GENERALIDADES ________________________________________________________ Sistema de Control para las Tareas del Servicio de Soporte Técnico de la Oficina de Informática de la Municipalidad Provincial de Piura mediante una Aplicación Web

7




1. GENERALIDADES DEL PROYECTO DE INVESTIGACION: 1.1. TÍTULO: “Sistema de Control para las Tareas del Servicio de Soporte Técnico de la Oficina de Informática de la Municipalidad Provincial de Piura mediante una Aplicación Web”

1.2. TIPO DE INVESTIGACIÓN: “EXPLICATIVA”

1.3. ÁREA DE INVESTIGACIÓN: “TECNOLOGICA”

1.4. INSTITUCIÓN DONDE SE REALIZA LA INVESTIGACIÓN: “Área de Soporte Técnico de la Municipalidad Provincial de Piura”


8




1.5. AUTOR: Jesús Antonio Manuel Pino Chacón

1.6. ASESOR METODOLÓGICO: Mg. Luis Velez Ubillus

1.7. ASESOR ESPECIALISTA: Ing. Noelia Saavedra Nizama

1.8. DURACIÓN DEL PROYECTO DE INVESTIGACIÓN: Inicio:

29 de marzo del 2011

Final:

18 de diciembre del 2011

________________________________________________________

CAPITULO II: PLAN DE INVESTIGACION


9




________________________________________________________

2. PLAN DE LA INVESTIGACION: 2.1. DESCRIPCIÓN DE LA REALIDAD PROBLEMÁTICA: El área de Soporte Técnico pertenece a la Oficina de Informática y que a su vez esta pertenece a la Gerencia de Tecnologías y Sistemas de Información de la Municipalidad Provincial de Piura. Soporte Técnico soluciona problemas de hardware, software, eléctricos, electrónicos, telefónicos y de redes de la mayoría de equipos que se encuentran en la municipalidad, se limita a estas actividades y no a proporcionar las políticas de seguridad y privacidad de la red de trabajo o dominio. El problema principal radica en el deficiente control de las tareas del servicio de Soporte Técnico de la Oficina de Informática de la Municipalidad Provincial de Piura. De ello se derivan algunos subproblemas como:  El registro de atenciones se hace de manera manual y en algunas ocasiones cuando los problemas son complicados y requieren más recursos se atienden de una manera inapropiada. Sistema de Control para las Tareas del Servicio de Soporte Técnico de la Oficina de Informática de la Municipalidad Provincial de Piura mediante una Aplicación Web

10




 No se maneja información estadística de los sucesos que acontecen en Soporte Técnico.  No existe un procedimiento adecuado de control y seguimiento en el área de Soporte Técnico, todo se hace manualmente.  Soporte Técnico no cuenta con un inventario propio.  El Área de Soporte Técnico no tiene independencia para planificar operaciones y tareas administrativas y de mantenimiento en la municipalidad de Piura ya que esto depende de la Oficina de Informática.  El proceso de atenciones a los problemas que se presentan en las dependencias de la municipalidad es poco organizado.  Se designa a Soporte Técnico escasos recursos (hardware, software y herramientas) en stock para atender los problemas que acontecen en la municipalidad.  El control del ingreso de requerimientos a soporte técnico es inadecuado.  Los puntos de reposición de Soporte Técnico no están definidos.  La planificación de tareas para el proceso del mantenimiento preventivo no es el adecuado.  La planificación de tareas para el proceso del mantenimiento correctivo no es el adecuado.  El registro y monitoreo del historial de cada equipo de la municipalidad de Piura no es el mas conveniente para soporte técnico.

2.2. FORMULACIÓN DEL PROBLEMA: 2.2.1. Pregunta General: Sistema de Control para las Tareas del Servicio de Soporte Técnico de la Oficina de Informática de la Municipalidad Provincial de Piura mediante una Aplicación Web

11




¿Cómo influye una Aplicación Web en el sistema de control de las tareas del servicio de Soporte Técnico de la Oficina de Informática de la Municipalidad Provincial de Piura?

2.2.2. Preguntas de Investigación: ¿De qué manera influye una aplicación web en la mejora de la organización y planificación de tareas para el proceso del mantenimiento preventivo y correctivo? ¿De qué manera influye una aplicación web para que Soporte Técnico cuente con un inventario propio para obtener y a la vez controlar una mayor cantidad de recursos? ¿De qué manera influye una aplicación web en la mejora del control y organización para los procesos de atenciones de problemas e incidentes? ¿De qué manera influye una aplicación web para que el Área de Soporte Técnico

tenga

independencia

para

planificar

operaciones

y

tareas

administrativas y de mantenimiento?

2.2.3. Objetivo General: “Determinar cómo influye una Aplicación Web en la mejora del Sistema de Control de las Tareas del Servicio de Soporte Técnico de la Oficina de Informática de la Municipalidad Provincial de Piura”

2.2.4. Objetivos Específicos:  Determinar de qué manera una Aplicación Web mejora la organización y la planificación de tareas para el proceso del mantenimiento preventivo y correctivo de los diferentes equipos de la Municipalidad Provincial de Piura.


12




 Determinar de qué manera una Aplicación Web permitirá contar con un inventario propio en Soporte Técnico para controlar y obtener una mayor cantidad de recursos necesarios para las tareas de los servicios que se realizan en la Municipalidad Provincial de Piura.

 Determinar de qué manera una Aplicación Web incidirá en la optimización del control y la organización para el proceso de atenciones de problemas e incidentes que acontecen en las dependencias de la Municipalidad Provincial de Piura.

 Determinar de qué manera una Aplicación Web permitirá que el Área de Soporte Técnico tenga independencia para planificar operaciones y tareas administrativas y de mantenimiento.

2.3. JUSTIFICACIÓN E IMPORTANCIA DEL PROYECTO: En vista de las necesidades del Área de Soporte Técnico de la Municipalidad de Piura de llevar un mejor control en la atención y solución de problemas técnicos que sufren los equipos de las diferentes áreas de la Municipalidad es que se desarrolla el presente proyecto para beneficiar tanto a los usuarios de la Municipalidad Provincial de Piura como a los trabajadores que laboran en el área de ST. Este proyecto abarcará también un mejor manejo del Inventario que compete a la Oficina de Informática ya que se podrá saber que equipos son dados de baja y cuáles son los que hacen falta para tener un stock adecuado en nuestro inventario. Con este trabajo de investigación se podrá optimizar el tiempo horas hombre y se podrán atender una mayor cantidad de problemas que surjan en las diferentes oficinas de la Municipalidad de Piura y que en verdad necesiten la atención de Soporte Técnico dando soluciones rápidas y adecuadas a dichos problemas.


13




Justificación Administrativa Este proyecto es una alternativa de solución al problema de Control y Organización para el Mantenimiento de Equipos Informáticos, cuyo desarrollo además de fortalecer el logro óptimo de los objetivos institucionales, agiliza las actividades desarrolladas por el área en la cual nuestra aplicación web será implementada. Justificación Científica El trabajo es desarrollado en base al método científico, que va desde la observación del objeto de estudio hasta las conclusiones y recomendaciones. El producto final alcanzado, será lo que justifique la investigación. Justificación Institucional Uno de los objetivos de la Municipalidad Provincial de Piura es mejorar la gestión administrativa y propiciar la descentralización de sus unidades y dependencias, mediante el uso de tecnologías de información. Para ello se implementará un nuevo sistema de información y/o control (aplicación web) para satisfacer las necesidades del usuario y puedan desarrollar sus actividades eficientemente. Justificación Social La implementación del sistema de información y/o control (aplicación web) mejorará la administración de los recursos informáticos para ofrecer servicios de calidad a la población y en consecuencia mejorar la imagen institucional del Gobierno Regional de Piura. Justificación Tecnológica Como entes de investigación y aprendizaje obtendremos nuevos conocimientos y experiencia como profesionales, manteniéndonos a la vanguardia de los requerimientos de nuestro entorno y la adecuada capacitación en cuanto a nuevas tecnologías de información se refiere. Puesto que una de las competencias exclusivas de la Municipalidad Provincial de Piura es promover la modernización, actualización e innovaciones tecnológicas.

2.4. LIMITACIONES DEL PROYECTO:  El limitado acceso a información de los sistemas informáticos que pueden servir de guía para el desarrollo de la presente investigación. Sistema de Control para las Tareas del Servicio de Soporte Técnico de la Oficina de Informática de la Municipalidad Provincial de Piura mediante una Aplicación Web

14




 El trabajo dinámico o poca disponibilidad del personal de Soporte Técnico limitará la información que se pueda obtener de ellos para el desarrollo de la presente aplicación web.  Los escasos recursos tecnológicos que dispone el área de soporte técnico para el desarrollo del presente proyecto.

 La aplicación web a desarrollar será independiente a la aplicación web institucional de la municipalidad.

 La base de datos del sistema de inventario de la municipalidad de Piura servirá de guía y/o modelo para la base de datos de nuestro sistema de control (aplicación web) para Soporte Técnico.

2.5. MARCO REFERENCIAL CIENTIFICO: 2.5.1. Antecedentes: •

Antecedentes Locales:

Castro Arévalo, Manuel & Zapata Navarro, Jhon (Piura – 2009), “Sistema Informático de Registro de Mantenimiento de Equipos de Cómputo del Área de Soporte del Centro de Informática y Telecomunicaciones de la Universidad Nacional de Piura”, presentan su tesis con la que obtuvieron los Títulos Profesionales de Ingenieros de Sistemas en la Universidad César Vallejo – Filial Piura. Castro & Zapata con este trabajo de investigación buscan registrar cada uno de los mantenimientos que se les realiza a todos los equipos que llegan al área de soporte y también buscan organizar y monitorear el inventario de todos los equipos de la Universidad Nacional de Piura.


15




Relación: Esta tesis se toma en cuenta porque implementa un sistema informático que se encarga de registrar datos detallados de los equipos de cómputo (inventario) y los mantenimientos que estos reciben, considerando también la respectiva organización y monitoreo, así como los beneficios que otorga. Salcedo Untiveros, Richard Orlando (Piura – 2007), “Análisis, Diseño y Desarrollo del Módulo Web para la Gestión y Control de Inventario de Bienes de la Oficina de Control Patrimonial de la Dirección Regional de Salud Piura”, presenta su tesis con la que obtuvo el Título Profesional de Ingeniero Informático en la Universidad Nacional de Piura. Salcedo con este proyecto de tesis busca gestionar y controlar el inventario de bienes de la Dirección Regional de Salud Piura incluyendo los procesos de registro de bienes, verificación del estado de los bienes, baja de bienes. Relación: Esta tesis se toma en consideración porque implementa un módulo web que presenta entornos de trabajo correspondientes a cada área de acción por usuario, relacionada con la gestión y control de inventario, así como las ventajas que este otorga.

•

Antecedentes Nacionales:

Vega Bustamante, Rocío Olinda (Lima – 2009), “Análisis, diseño e implementación de un sistema de administración de incidentes en atención al cliente para una empresa de telecomunicaciones”, presenta su tesis con la que obtuvo el Título Profesional de Ingeniero Informático en la Pontificia Universidad Católica del Perú. Vega con este proyecto de investigación busca monitorear el tiempo de atención de los casos que presente el cliente en una empresa de telecomunicaciones, de allí que la presente tesis presenta el análisis, desarrollo e implementación de un sistema de administración de incidentes en Atención al Cliente para una empresa de telecomunicaciones. Relación: Esta tesis se toma en consideración porque implementa un sistema de administración de incidentes que monitorea el tiempo de atención de los casos que presente el cliente y de seguir la normativa establecida y las ventajas que esto otorga. Sistema de Control para las Tareas del Servicio de Soporte Técnico de la Oficina de Informática de la Municipalidad Provincial de Piura mediante una Aplicación Web

16




Santillán Pinedo, Karla & Tornero Mendoza, Ludver (Trujillo – 2001), “Sistema de Información de Control de Almacén de la Dirección Regional de Educación de La Libertad – DRELL”, presentan su tesis con la que obtuvieron los Títulos Profesionales de Ingenieros de Sistemas en la Universidad César Vallejo. Santillán & Tornero con este proyecto de tesis buscan mejorar la gestión del área de almacén de la sede central de la DRELL, en la cual se realizó un estudio para poder lograr los objetivos institucionales de la misma, incluyendo eficiencia y eficacia en los trámites que se desarrollan, acceso directo y rápido a la información, distribución ágil y rápida de los artículos que piden los usuarios de la DRELL, monitoreo constante del stock de almacén, entre otros procesos mejorados que son propios de dicha área. Relación: Esta tesis se toma en cuenta porque implementa un sistema que centraliza la información de los equipos informáticos, para un mejor control de almacén con los respectivos procesos que se llevan a cabo, para finalmente con la información brindada sirva de apoyo para nuevas adquisiciones.

•

Antecedentes Internacionales:

Pesántez Huerta, Álvaro Eduardo (Guayaquil, Ecuador – 2007), “Elaboración de un Plan de Mantenimiento Predictivo y Preventivo en Función de la Criticidad de los Equipos del Proceso Productivo de una Empresa Empacadora de Camarón”, presenta su tesis con la que obtuvo el Título Profesional de Ingeniero Industrial en la Escuela Superior Politécnica del Litoral. Pesantez con este trabajo de investigación busca realizar un plan de mantenimiento predictivo y preventivo de los equipos, el cual contendrá el detalle del mantenimiento recomendado por los fabricantes y los técnicos internos y/o externos de la empresa; así como también el detalle de cada equipo y cuáles serán las frecuencias de los diversos mantenimientos preventivos establecidos. Relación: Esta tesis se toma en consideración porque implementa un plan de mantenimiento predictivo y preventivo enfocado a brindar una guía confiable de los tipos y frecuencias de mantenimiento para los equipos, esta Sistema de Control para las Tareas del Servicio de Soporte Técnico de la Oficina de Informática de la Municipalidad Provincial de Piura mediante una Aplicación Web

17




guía servirá como modelo para desarrollar los módulos webs de mantenimiento predictivo, preventivo y correctivo de la aplicación web a desarrollar. Espinoza Saavedra, Daniel (Valparaíso, Chile – 2004), “Estudio del Sistema de Monitoreo y Registro de Inventarios de Compras y su Integración Estratégica mediante el Control de Gestión”, presenta su tesis con la que obtuvo el Grado de Magíster en Gestión mención Control en la Universidad de Valparaíso. Espinoza con este proyecto de investigación busca presentar las posibilidades que ofrece un modelo de control dentro de un sistema de inventarios

de

compras

mediante

la

aplicación

de

los

conceptos

constructivos de un cuadro de mando. Relación: Esta tesis se toma en cuenta porque nos proporciona información importante sobre las posibilidades y riesgos de implementar un control de gestión en un inventario de compras y los beneficios que este otorga.

2.6. MARCO TEORICO: 2.6.1. MUNICIPALIDAD PROVINCIAL DE PIURA:  Misión, Visión y Objetivos de la Institución: Misión Gobernar, conducir y liderar el desarrollo de la provincia, gestionando y promoviendo el desarrollo sostenible, integral y el bienestar humano, mediante acciones de concertación institucional y de participación de la sociedad civil organizada. [PEI – MPP] Visión La Municipalidad Provincial de Piura al 2014, aplica una gestión moderna, eficiente y participativa, con creciente igualdad de oportunidades, sistema distrital democrático, institucionalidad participativa, ámbitos urbano y rural


18




articulados, con hombres y mujeres emprendedoras y ciudades abiertas, seguras, sostenibles, ordenadas, modernas y limpias. [PEI – MPP] Objetivos 1) Conducir, promover y fomentar el desarrollo socio-económico integral, sostenible y armónico, priorizando y planificando las necesidades del distrito y provincia de Piura. 2) Promover el bienestar del ciudadano con la adecuada prestación de los servicios públicos locales que satisfagan sus necesidades vitales de salubridad, vivienda, abastecimiento, seguridad, cultura, recreación, transporte y comunicaciones. 3) Representar política y organizacionalmente a los vecinos en el Gobierno Local, mediante programas de participación comunal y el ejercicio del derecho de petición. 4) El Ejercicio de la Función Conciliadora. 5) Desarrollar programas sociales básicos. 6) Promover el desarrollo económico local mediante el impulso a las pequeñas y micro empresas (PYMES), de acuerdo a las normas y políticas regionales y nacionales. 7) Brindar la infraestructura, apoyo, asesoramiento a los promotores y agentes del desarrollo económico, facilitándoles el espacio físico para sus actividades de acuerdo a la normatividad vigente. [ROF – MPP]  Políticas Generales de la Institución: OBJETIVOS ESTRATEGICOS LINEAS POLITICAS OBJETIVO META La Municipalidad Provincial de Piura es Política N° 01

una corporación edil eficaz y eficiente que

Desarrollo Institucional

resuelve el 100 % de sus operaciones de manera moderna, ágil y dinámica. La Municipalidad Provincial de Piura cuenta con una Red de Participación Ciudadana

mediante

la

cual

ha

organizado el 100 % de Juntas Vecinales Política N° 02

dentro

Desarrollo Social

competencia. La Municipalidad Provincial de Piura


19

de

las

jurisdicciones

de

su




cuenta con una Red de Desarrollo Social que contribuye, concerta y monitorea el 100 % de los servicios de educación, salud y trabajo. La Municipalidad Provincial de Piura Política N° 03

cuenta con un Sistema de Desarrollo

Desarrollo Económico y

Económico y Financiero que le permite

Financiero

incrementar sus recursos en un 5 % anual. La Municipalidad Provincial de Piura es la

Política N° 04

primera en el país que logra delimitar y

Organización Territorial

adecuar integralmente el 100 % de su territorio. Cuadro N° 001: Política Institucionales Fuente: PEI – MPP

 Actividades Principales de la Institución: 1) Planificar integralmente el desarrollo local y el ordenamiento territorial, en el nivel provincial. 2) Promover permanentemente la coordinación estratégica de los planes integrales de desarrollo de los distritos. Los planes referidos a la organización del espacio físico y uso del suelo que emitan las municipalidades distritales deberán sujetarse a los planes y las normas generales de la Municipalidad Provincial de Piura. 3) Promover, apoyar y ejecutar proyectos de inversión y servicios públicos municipales que presenten objetivamente externalidades o economías de escala de ámbito provincial; para cuyo efecto suscribirá convenios con las respectivas municipalidades distritales. 4) Emitir las normas técnicas generales, en materia de organización del espacio físico y uso del suelo, así como sobre protección y conservación del medio ambiente. 5) Proponer proyectos de ley, a través de iniciativas legislativas. [ROF – MPP]  Organigrama de la Institución:


20




Toda empresa cuenta en forma implícita o explícita con cierto juego de jerarquías y atribuciones asignadas a los miembros o componentes de la misma. En consecuencia se puede establecer que la estructura organizativa de una empresa es el esquema de jerarquización y división de las funciones componentes de ella. Jerarquizar es establecer líneas de autoridad (de arriba hacia abajo) a través de los diversos niveles y delimitar la responsabilidad de cada empleado ante solo un supervisor

inmediato.

Esto permite

ubicar

a las

unidades

administrativas en relación con las que le son subordinadas en el proceso de la autoridad. El valor de una jerarquía bien definida consiste en que reduce la confusión respecto a quien da las órdenes y quien las obedece. Define como se dividen, agrupan y coordinan formalmente las tareas en los puestos. [MPP]


21




Gráfico N° 001: Organigrama de la Municipalidad Provincial de Piura Fuente: Municipalidad Provincial de Piura (MPP) Sistema de Control para las Tareas del Servicio de Soporte Técnico de la Oficina de Informática de la Municipalidad Provincial de Piura mediante una Aplicación Web

22




2.6.2. OFICINA DE INFORMATICA:  Misión, Visión, Objetivos y Metas de la Oficina de Informática: Misión Promover el desarrollo y la utilización de un sistema de información moderno de

acuerdo

a

las

necesidades

de

los

diferentes

usuarios,

proporcionando datos oportunos y de calidad en lo relativo a prevención, atención y control de los problemas informáticos, eléctricos y electrónicos contribuyendo a la mejora de la calidad de servicio de las diferentes dependencias de la Municipalidad Provincial de Piura. [ROF – MPP] Visión Contar con la confianza y satisfacción de nuestros Usuarios a través de un sistema que proporcione información y servicios oportunos, seguros, y de calidad, brindando a sus necesidades respuestas integrales, rápidas y efectivas a través de un equipo multidisciplinario con calidad humana, técnica y profesional. [ROF – MPP] Objetivos 1) Optimizar las necesidades de automatización de procesos. 2) Optimizar las necesidades de información de los usuarios finales. 3) Desarrollar los sistemas informáticos, cuidando que cumplan con la ergonomía de interfase usuario máquina y los niveles de seguridad requeridos. 4) Implementar los sistemas informáticos conjuntamente con los usuarios. 5) Mejorar el mantenimiento de los sistemas de informáticos, luego de estudiar los requerimientos de los usuarios. 6) Planificar y administrar los proyectos, que se generan como consecuencia de la necesidad del desarrollo e implementación de los sistemas informáticos. 7) Mejorar la administración de los recursos humanos y equipos asignados a esta oficina. 8) Supervisar y emitir normas de uso y estandarización para el correcto funcionamiento y utilización de los equipos por parte de los usuarios. 9) Brindar el mantenimiento preventivo y correctivo de la infraestructura de red y de los equipos informáticos. 10) Generar planes de mantenimiento y observar su cumplimiento. 11) Mejorar la administración de la base de datos. Sistema de Control para las Tareas del Servicio de Soporte Técnico de la Oficina de Informática de la Municipalidad Provincial de Piura mediante una Aplicación Web

23




12) Implementar la infraestructura de telecomunicaciones para el óptimo funcionamiento de los sistemas informáticos. [ROF – MPP] Metas 1)

Facilitar

el

desarrollo

de

la Corporación

Municipal

mediante

la

implementación de un Sistema de Comunicaciones y Tecnologías de Información durante el presente año 2011 con un presupuesto de 30316.93 nuevos soles. 2) Gestionar y resolver el desarrollo de los medios eficientes de comunicación simultánea entre las Juntas Vecinales y la Corporación Municipal durante el presente año 2011 con un presupuesto de 9603.50 nuevos soles. 3) Proporcionar las herramientas tecnológicas que permitan una adecuada comunicación

y acceso

a la información

estadística

y difusión de

convocatorias y logros de la Corporación Municipal durante el presente año 2011 con un presupuesto de 1240.50 nuevos soles. 4) Gestionar, programar, promover y resolver la implementación del gobierno electrónico y adecuar el resultado progresivo de la organización territorial durante le presente año 2011 con un presupuesto de 396.20 nuevos soles. 5) Diseñar procedimientos que simplifiquen mecanismos administrativos durante el presente año 2011 con un presupuesto de 18441.61 nuevos soles. [POI – MPP]

2.6.3. SOPORTE TECNICO:  Descripción del Área de Negocio: El Área de Negocio es Soporte Técnico, pertenece a la Oficina de Informática y a su vez esta oficina pertenece a la Gerencia de Tecnologías y Sistemas de Información, se encarga de dar respaldo a los equipos electrónicos y eléctricos que se encuentran dentro de la Municipalidad de Piura y en sus Unidades Orgánicas Externas. Soporte Técnico, alberga equipos, materiales, herramientas y repuestos para que los usuarios o trabajadores de la Municipalidad de Piura soliciten servicios de atención para solucionar problemas de hardware y software de los equipos electrónicos e informáticos, problemas de equipos eléctricos y problemas de equipos telefónicos. Sistema de Control para las Tareas del Servicio de Soporte Técnico de la Oficina de Informática de la Municipalidad Provincial de Piura mediante una Aplicación Web

24




Soporte Técnico soluciona problemas de hardware, software, eléctricos, electrónicos, telefónicos y de redes de la mayoría de equipos que se encuentran en la municipalidad, se limita a estas actividades y no a administrar las políticas de seguridad y privacidad de la red de trabajo o dominio. Dada la diversidad de incidentes y solicitudes que pueden producirse en ST resultan difíciles que las atenciones sean de manera oportuna dado que muchas veces estos problemas pueden ser solucionados de manera fácil por el usuario o trabajador de la municipalidad de Piura. [EL AUTOR]

2.6.4. SISTEMA DE CONTROL:  ¿QUÉ ES UN SISTEMA DE CONTROL? Según Alvarez Brotons (2004): Un sistema dinámico puede definirse conceptualmente como un ente que recibe unas acciones externas o variables de entrada, y cuya respuesta a estas acciones externas son las denominadas variables de salida. Las acciones externas al sistema se dividen en dos grupos, variables de control, que se pueden manipular, y perturbaciones sobre las que no es posible ningún tipo de control. El gráfico 2 ilustra de un modo conceptual el funcionamiento de un sistema.

Gráfico N° 002: Esquema general de un sistema Fuente: Alvarez Brotons


25




Dentro de los sistemas se encuentra el concepto de sistema de control. Un sistema de control es un tipo de sistema que se caracteriza por la presencia de una serie de elementos que permiten influir en el funcionamiento del sistema. La finalidad de un sistema de control es conseguir, mediante la manipulación de las variables de control, un dominio sobre las variables de salida, de modo que estas alcancen unos valores prefijados (consigna). Un sistema de control ideal debe ser capaz de conseguir su objetivo cumpliendo los siguientes requisitos: 1. Garantizar la estabilidad y, particularmente, ser robusto frente a perturbaciones y errores en los modelos. 2. Ser tan eficiente como sea posible, según un criterio preestablecido. Normalmente este criterio consiste en que la acción de control sobre las variables de entrada sea realizable, evitando comportamientos bruscos e irreales. 3. Ser fácilmente implementable y cómodo de operar en tiempo real con ayuda de un ordenador. Los elementos básicos que forman parte de un sistema de control y permiten su manipulación son los siguientes: - Sensores. Permiten conocer los valores de las variables medidas del sistema. - Controlador. Utilizando los valores determinados por los sensores y la consigna impuesta, calcula la acción que debe aplicarse para modificar las variables de control en base a cierta estrategia. - Actuador. Es el mecanismo que ejecuta la acción calculada por el controlador y que modifica las variables de control. El gráfico 3 ilustra el esquema de funcionamiento de un sistema de control genérico.


26




Gráfico N° 003: Esquema general de un sistema de control Fuente: Alvarez Brotons

2.6.5. APLICACIÓN WEB: En este inciso se darán a conocer algunos conceptos básicos del contexto de este trabajo, con la finalidad de situar al problema dentro de un conjunto de conocimientos. Dentro de estos conocimientos se darán algunos conceptos acerca de patrones de diseño, dentro de ellos el patrón MVC, sus partes y características, después se hablará acerca de los frameworks, un breve comparativo entre estos y los patrones de diseño y finalmente se hace un pequeño y breve análisis de algunos otros frameworks para web existentes.  Patrones de diseño •

Definición e historia

Para comenzar es importante definir lo que un patrón de diseño es, aunque existen varias definiciones al respecto, un patrón de diseño es una solución de calidad para un problema recurrente de diseño. Pero no son aplicables únicamente en el campo computacional, también existen patrones para varias actividades de la vida cotidiana, aunque con algunas diferencias pero tienen el mismo propósito que en el ámbito computacional, proporcionar una base para poder realizar una actividad, mejorando la calidad del producto que esa actividad de como resultado [Freeman, 2004]. Sistema de Control para las Tareas del Servicio de Soporte Técnico de la Oficina de Informática de la Municipalidad Provincial de Piura mediante una Aplicación Web

27




Hay patrones que abarcan las distintas etapas del desarrollo; desde el análisis hasta el diseño y desde la arquitectura hasta la implementación. En el caso de los patrones computacionales un software estructurado, modulado posee una mejor calidad y es más sencillo corregir errores, implementar mejoras y actualizaciones, ya que un software que posee algún patrón de diseño es más sencillo de modificar que un software que no posee en absoluto un patrón. Pero ¿Cómo se debe escoger el patrón adecuado?, esta es una pregunta un poco difícil de responder ya que la mayoría de las actividades de desarrollo o producción no se ajustan perfectamente a un patrón definido, por eso es importante llevar acabo un análisis para poder visualizar cual será el patrón que mejor se ajuste a las necesidades de desarrollo. En sí "un patrón de diseño puede verse como una plantilla que puede ser aplicada en muchas situaciones diferentes" [Gamma, 1995], para dar una buena solución. Los patrones se descubren como una forma indispensable de enfrentarse a la programación a raíz del libro "Design Patterns - Elements of Reusable Software" de Erich Gamma, Richard Helm, Ralph Jonson y John Vlissides, a partir de entonces los patrones de diseño que aparecen en ese libro son conocidos como los patrones de la pandilla de los cuatro (GoF, gang of four), y comienzan a desarrollarse variaciones y nuevos patrones, en poco tiempo se multiplicaron por 100 y no se limitaban a patrones de diseño sino que cubrían todo los que se entiende por ingeniería del software (desde el análisis hasta la implementación) [Gamma, 1995]. •

Elementos esenciales

En general un patrón tiene cuatro elementos esenciales: El nombre del patrón: que se utiliza para describir un problema de diseño, sus soluciones y sus consecuencias, en una palabra o dos. Este nombre ayuda a que sea más sencillo de identificarlo, al hablar o escribir de él e incluso puede dar una idea general o una descripción de dicho patrón. El problema: describe cuando aplicar el patrón, también puede incluir detalles específicos que se deben cumplir o problemas un poco más detallados, los cuales en conjunto engloban el problema central a solucionar. Sistema de Control para las Tareas del Servicio de Soporte Técnico de la Oficina de Informática de la Municipalidad Provincial de Piura mediante una Aplicación Web

28




La solución: describe los elementos que forman el diseño, sus relaciones, sus responsabilidades y sus colaboraciones. La solución no describe un diseño o implementación en particular ya que un patrón de diseño puede verse como una plantilla que se aplica a un problema específico. Las consecuencias: son los resultados y desventajas de haber aplicado el patrón. Estas consecuencias implican un impacto en las características del sistema como: flexibilidad, portabilidad y extensión. Además de que ayudan a medir el desempeño del sistema. •

Clasificación

El grupo de GoF clasificó los patrones en 3 grandes categorías basadas en su propósito: creacionales, estructurales y de comportamiento [Gamma, 1995]. Creacionales: tratan con las formas de crear instancias de objetos. El objetivo de estos patrones es de abstraer el proceso de instanciación y ocultar los detalles de cómo los objetos son creados o inicializados. Estructurales: Los patrones estructurales describen como las clases y objetos pueden ser combinados para formar grandes estructuras y proporcionar nuevas funcionalidades. Estos objetos adicionados pueden ser incluso objetos simples u objetos compuestos. Comportamiento: Los patrones de comportamiento ayudan a definir la comunicación e iteración entre los objetos de un sistema. El propósito de este patrón es reducir el acoplamiento entre los objetos.  Patrón de diseño Model View Controller (MVC) Una vez establecidas las bases de los patrones de diseño, se puede ya comenzar a hablar más del patrón que se utilizó durante este trabajo: el patrón MVC. Estas son las siglas de Model View Controller, en español Modelo Vista Controlador. Esto también se ve reflejado en que cada una de estas palabras representa cada uno de los 3 componentes del patrón MVC. Cada parte juega un rol fundamental para la completa integración del sistema. Sistema de Control para las Tareas del Servicio de Soporte Técnico de la Oficina de Informática de la Municipalidad Provincial de Piura mediante una Aplicación Web

29



•


Definición e historia

"El propósito de este patrón es simplificar la implementación de aplicaciones de acuerdo a las peticiones de los usuarios y los datos a desplegar" [Harrop, 2005]. La definición un poco más formal sería: MVC es un patrón de diseño de software que separa los datos de una aplicación, la interfaz de usuario, y la lógica de control en tres componentes distintos de forma que las modificaciones al componente de la vista, o a cualquier parte del sistema puedan ser hechas con un mínimo impacto en el componente del modelo de datos o en los otros componentes del sistema. Este patrón cumple perfectamente el cometido de modularizar un sistema. El patrón MVC fue descrito por primera vez en 1979 por Trygve Reenskaug, quién trabajaba en Smalltalk en los laboratorios de investigación de la Xerox. Este patrón se ve frecuentemente utilizado en aplicaciones web, donde la vista es la página HTML y el código provee de datos dinámicos a la página. Las aplicaciones web complejas continúan siendo más difíciles de diseñar que las aplicaciones tradicionales de escritorio, el patrón MVC se presenta como una solución para ayudar a disminuir dicha complejidad. •

Componentes

Los 3 principales componentes del patrón MVC son: Modelo: Representa los datos que el usuario está esperando ver, en algunos casos el Modelo consiste de Java Beans. Vista: es la responsable de transformar el modelo para que sea visualizada por el usuario, ya sea en un archivo de texto normal o en una página web (HTML o JSP) que el navegador pueda desplegar. En sí el propósito de la vista es convertir los datos para que al usuario le sean significativos y los pueda interpretar fácilmente. La vista no debe trabajar directamente con los parámetros del request, debe delegar esta responsabilidad al controlador. Controlador: es la parte lógica que es responsable del procesamiento y comportamiento de acuerdo a las peticiones (requests) del usuario, construyendo Sistema de Control para las Tareas del Servicio de Soporte Técnico de la Oficina de Informática de la Municipalidad Provincial de Piura mediante una Aplicación Web

30




un modelo apropiado, y pasándolo a la vista para su correcta visualización. En el caso de una aplicación web Java en la mayoría de los casos el controlador es implementado por un servlet. •

Tipos de patrones MVC

Actualmente existen dos tipos de patrón MVC: Servidor Web/Aplicación

Gráfico N° 004: MVC de arquitectura Tipo 1 Fuente: Walls, 2005 Como se muestra en el Gráfico 4 en el Tipo 1 de MVC las páginas JSP están en el centro de la aplicación, y contienen tanto la lógica de control como la de presentación. Este tipo de arquitectura funciona de la siguiente manera: el cliente hace una petición a una página JSP; se construye la lógica de la página, generalmente en objetos Java o como se les conoce en Inglés Plain Old Java Objects (POJOs) y se transforma el modelo para ser desplegado una vez más. Servidor Web/Aplicación

Gráfico N° 005: MVC de arquitectura Tipo 2 Fuente: Walls, 2005


31




En el modelo de Tipo 2 de MVC, que se aprecia en el Gráfico 5, se puede observar que ya existe una clara separación entre el controlador y la vista, ya que ahora es directamente el controlador quien recibe la petición, prepara el modelo y lo transforma para que sea desplegado en la vista. Este tipo de arquitectura MVC es el que se utiliza para aplicaciones más complejas, ya que para una aplicación sencilla puede utilizarse el Tipo 1. La tecnología JSP no es la única que se puede emplear para las vistas, existen otro tipo de tecnologías que pueden servir como vistas.  Frameworks Un framework es un término utilizado en la computación en general, para referirse a un conjunto de bibliotecas, utilizadas para implementar la estructura estándar de una aplicación. Todo esto se realiza con el propósito de promover la reutilización de código, con el fin de ahorrarle trabajo al desarrollador al no tener que rescribir ese código para cada nueva aplicación que desee crear. Existen diferentes frameworks para diferentes propósitos, algunos orientados al desarrollo de aplicaciones web, otros para desarrollar aplicaciones multiplataforma, para un sistema operativo o lenguaje de programación en específico, entre otros. Según Gamma, el framework determina la arquitectura de una aplicación [Gamma, 1995]. Este es un buen enfoque, ya que el framework se encarga de definir la estructura general, sus particiones en clases y objetos, las responsabilidades clave, así como la colaboración entre dichas clases y objetos. Todos estos parámetros son definidos por el framework, evitando que el usuario tenga que definirlos y se pueda enfocar en cosas específicas de su aplicación. "El framework captura las decisiones de diseño que son comunes a su dominio de aplicación" [Gamma, 1995]. Un framework no sólo promueve la reutilización de código sino también la reutilización de diseño. Un framework ayuda a que se desarrolle una aplicación de una manera más rápida, ya que se no pierde tiempo en algunos detalles de diseño que muchas veces quitan más tiempo del que tomo construir en sí la lógica de la aplicación. Además las aplicaciones que se construyen tienen estructuras similares, son más fáciles de mantener y consistentes para los usuarios. Pero esto tiene como consecuencia una mínima perdida de libertad en las cuestiones de diseño. Sistema de Control para las Tareas del Servicio de Soporte Técnico de la Oficina de Informática de la Municipalidad Provincial de Piura mediante una Aplicación Web

32




En algunas ocasiones un desarrollador tiene algunas dificultades para diseñar una aplicación, esto todavía es más difícil para el desarrollador del framework, ya que desarrollar un framework requiere de muchos cuidados, porque cuando se lanza uno nuevo, se espera que pueda servir para muchos tipos de aplicaciones pero con arquitecturas y requerimientos similares. Es decir trata de englobar toda una gamma de aplicaciones dentro de un solo estándar, lo cual puede ser el éxito o el fracaso del mismo, por eso se intenta crear frameworks lo más extensibles y flexibles posibles, para que con algunos cambios mínimos se pueda actualizar o corregir. Las aplicaciones que se desarrollan a partir de un framework, está ligada al mismo, por eso las aplicaciones deben de evolucionar y crecer al mismo tiempo que crece el framework, ya que un cambio en alguna interfaz del mismo significará un cambio de la aplicación, dependiendo de que tan drástico sea el cambio.

•

Relación entre patrones de diseño y frameworks

Los frameworks utilizan un variado número de patrones de diseño, ya que así logran soportar aplicaciones de más alto nivel y que reutilizan una mayor cantidad de código, que uno que no utiliza dichos patrones. "Los patrones ayudan a hacer la arquitectura de los frameworks más adecuada para muchas y diferentes aplicaciones sin necesidad de rediseño" [Gamma, 1995]. Por esta razón es importante que se documenten que patrones utiliza el framework para que los que se encuentren familiarizados con dichos patrones puedan tener una mejor visión y poder adentrarse en el framework más fácilmente. Aunque muchas personas cometen el error de confundir a los frameworks con los patrones de diseño, según los cuatro autores del libro "Design Patterns - Elements of Reusable" existen 3 diferencias fundamentales entre ellos [Gamma, 1995]: Los patrones de diseño son más abstractos que los frameworks: el código del framework se escribe una vez, en cambio cada vez que se requiere un patrón de diseño se debe de codificar con respecto a la aplicación. Una fortaleza de los frameworks es que pueden ser escritos en un lenguaje de programación, pueden ser reutilizados e incluso ejecutados, esto también podría considerarse una debilidad dependiendo del punto de vista (siempre y cuando no sean multiplataforma o se encuentre en diferentes versiones por lenguaje de Sistema de Control para las Tareas del Servicio de Soporte Técnico de la Oficina de Informática de la Municipalidad Provincial de Piura mediante una Aplicación Web

33




programación), ya que están enfocados a un sólo lenguaje de programación, en cambio un patrón de diseño puede ser aplicado a cualquier lenguaje de programación, pero se tiene que reescribir desde cero. Los patrones de diseño son elementos arquitectónicos más pequeños que los frameworks: un solo framework contiene varios patrones de diseño, pero jamás es al contrario. Los patrones de diseño son menos especializados que los frameworks: existen frameworks con un dominio específico, además los patrones son un poco más generales debido a que pueden ser utilizados en un mayor número de aplicaciones de varios tipos.

 Frameworks para aplicaciones web Actualmente existen algunos frameworks para desarrollar aplicaciones web, que es de las ramas más importantes en las que se usan los frameworks. La mayoría de ellos utilizan el patrón de diseño MVC del cual se habló previamente. Todos los frameworks tienen características especiales que los hacen únicos para sobresalir y poder seguir en el mercado, además de poseer las siguientes características comunes [Johnson, 2003]: • Utilizan un solo servlet que tiene la función de controlador, para toda la aplicación o gran parte de ella. Se configura el deployment descriptor "web.xml" para que todas las URL's tengan que pasar forzosamente por dicho servlet. Una configuración, generalmente escrita en un archivo XML, en donde se le indicará al servlet controlador, a través de propiedades, a quien delegar la responsabilidad de atender la petición entrante. Algunas veces esas propiedades están indicadas de acuerdo a los URL's y de acuerdo al URL entrante es como se delega la responsabilidad. • Las vistas pueden tener nombres claves, sin necesidad que exista una relación con el nombre del archivo de la vista. El framework se encarga de realizar dicha conversión para poder obtener el nombre de la vista que se tiene que cargar para que sea desplegada. La implementación de una vista con un nombre en particular puede cambiar sin afectar código del controlador.


34




Cuando se va a desarrollar una aplicación web, el desarrollador se debe fijar en si desea realizar una aplicación extremadamente sencilla o si quiere desarrollar una verdadera aplicación web, que tendrá actualizaciones, correcciones y mejoras a futuro. Para esto es recomendable que se elija un framework de aplicación web que utilice el patrón web MVC. Con el fin de que se pueda hacer la separación entre los 3 elementos principales y pueda aprovechar todas las ventajas que brinda este patrón de diseño. Para poder aprovechar también las ventajas adicionales que brinda el framework para la integración con otras herramientas u otros servicios. A continuación se enlistan algunos de los frameworks para aplicaciones web más populares: Struts, WebWork, Maverick y Spring, el framework sobre el cual se basa esta tesis, será analizado con mayor detalle más adelante en este documento. Este listado y análisis sencillo de cada uno de estos frameworks se da con la razón de poder saber cuales son los frameworks contra los que compite Spring, dentro del mismo ámbito, así como sus características principales, ventajas y desventajas. •

Struts

Struts es uno de los frameworks MVC más utilizados, ya que fue uno de los pioneros en el campo, fue creado por Craig McClanahan, creador del famoso motor servlet Tomcat, ambos son distribuidos por Apache. Este framework fue lanzado a mediados del año 2000, y a partir de esta fecha comenzó a tener popularidad, y en la actualidad existen algunos componentes extra que se adaptan a Struts, lo que le da un mayor campo de acción. Struts es open source, por lo que no requiere licencia para su uso [Johnson, 2003]. Además cumple una de las funcionalidades básicas que se mencionaron acerca de los frameworks para aplicaciones web, ya que implementa un solo controlador (ActionServlet) que evalúa las peticiones del usuario mediante un archivo configurable (struts-config.xml) para poder dirigirlas a un action que procesa el request. El lenguaje de programación que utiliza es Java, así como Java Beans como modelo. Algunas de las ventajas que Struts brinda son: que existe un variado número de trabajos y proyectos ya hechos lo que brinda un mayor número de ejemplos para Sistema de Control para las Tareas del Servicio de Soporte Técnico de la Oficina de Informática de la Municipalidad Provincial de Piura mediante una Aplicación Web

35




poder tomar un punto de partida y de referencia; otra ventaja es que brinda librerías de tags para HTML bastante útiles. Entre las desventajas de framework se puede observar que muchas veces puede ser difícil trabajar con los ActionForms, además de que el proyecto posiblemente desaparezca en los años venideros, otra de las desventajas de Struts es que muy ligado con la tecnología JSP, por lo que muchas veces se dificulta integrarlo con alguna otra tecnología para las vistas. •

Maverick

Este es otro framework MVC open source que existe en el mercado, pero a diferencia de los demás este no cuenta con sus propias librerías de tags. Sin embargo cumple con las funcionalidades típicas mencionadas, como el de tener un solo servlet controlador central como punto de entrada, el cual lleva el nombre de Dispatcher, que está definido en el Deployment Descriptor de la aplicación web (web.xml). Maverick cuenta con un archivo XML en el que se guarda toda la configuración del mismo (maverick.xml). Una característica de Maverick es que únicamente acepta un solo controlador central y un archivo de configuración por aplicación web, lo que muchas veces al desarrollar aplicaciones más grandes y complejas se puede volver confuso y difícil de configurar. [Johnson, 2003] Maverick es un framework mucho más configurable que Struts, lo que brinda cierta flexibilidad, también incluye varias clases para poder extender y cambiar el flujo del trabajo o workflow en Inglés. Maverick es usualmente usado para crear nuevos controladores que sean capaces de procesar nuevas peticiones. Los controladores son Java Beans, y el framework pone de manera transparente las propiedades de los beans. Una característica interesante de Maverick es el básico y fácil uso de la funcionalidad del dispatcher. También es multiplataforma ya que ha sido adaptado para los lenguajes .NET y PHP. •

WebWork

Este es un framework más reciente ya que fue lanzado a mediados del año 2002, una de las personas que ha trabajado en este proyecto fue Rickard Oberg, quien ha participado en proyectos como JBoss, entre otros. "WebWork, a pesar de su Sistema de Control para las Tareas del Servicio de Soporte Técnico de la Oficina de Informática de la Municipalidad Provincial de Piura mediante una Aplicación Web

36




nombre, no es puramente un framework para aplicaciones web. Adopta un acercamiento práctico que minimiza la dependencia del código de la aplicación de los conceptos web."[Johnson, 2003]. El framework WebWork está basado en el patrón de diseño de Comandos o CommandPattern. Cada acción es un comando, que es creado para manejar un request, sus propiedades son puestas de manera transparente, ya que cada acción es un Java Bean. WebWork cuenta, al igual que Struts y Spring con su propia librería de tags para JSP, las cuales ayudan a realizar distintas tareas de una manera más ágil, pero no es la única tecnología para vista que soporta, también incluye soporte para Velocity. Una de las ventajas de WebWork es que cuenta con una arquitectura simple y las clases son fáciles de extender. Pero como todo, tiene sus desventajas, la creación de una acción (action) por cada request puede llegar a ser algo confuso cuando no se tiene muchos datos en el request; impone el patrón de diseño Command en cada interacción del usuario, ya sea bueno o malo utilizarlo en dicha interacción; es difícil saber de que tipo son las excepciones que se lanzan. Como este framework es relativamente reciente no existe mucha documentación y ejemplos al respecto lo que puede resultar a veces frustrante cuando se requiere buscar algún ejemplo o tutorial que pueda servir. •

Spring

Es un framework de aplicación, que a diferencia de otros single-tier como Struts, Spring propone estructurar toda una aplicación de una manera consistente y productiva, conjuntando lo mejor de cada uno de los frameworks single-tier para crear una arquitectura coherente. En sí Spring ha surgido como una solución para poder disfrutar de los beneficios clave de J2EE, mientras que minimiza la complejidad encontrada en el código de la aplicación. [Johnson, 2005] Spring esta basado en la filosofía de que un framework debe proveer una guía hacia una buena práctica, es decir debe hacer la cosa correcta sencilla de hacer. Mezclando la correcta combinación de flexibilidad y restricción, la cual es la clave en el buen diseño de un framework. Sistema de Control para las Tareas del Servicio de Soporte Técnico de la Oficina de Informática de la Municipalidad Provincial de Piura mediante una Aplicación Web

37




Spring también cuenta con algunas de las características generales de los frameworks web, ya que cuenta con un módulo para poder desarrollar aplicaciones web de manera sencilla, utilizando el patrón de diseño MVC antes mencionado. Contando con un controlador central (DispatcherServlet), además de la capacidad de tener varios controladores secundarios para el procesamiento de cada una de las peticiones. También se basa en el diseño de las clases extendiendo o implementando interfaces, lo cual es un mejor diseño orientado a objetos, ya que promueve la reutilización de código. Además Spring cuenta con algunos tags para las diferentes tecnologías para vista que existen. Las cuales tienen funciones diferentes como vincular formularios, validación, despliegue de información, entre otras. Uno de los aspectos clave y ventajas de Spring, es que cuenta con una arquitectura modularizada, y se pueden utilizar cada uno de estos módulos de manera independiente. Cada uno esta enfocado en una tarea específica, y algunos de ellos son para la integración con alguna herramienta o incluso cuenta con la posibilidad de integrase con los otros frameworks mencionados anteriormente. Esto con el propósito de proponer la filosofía de "no intentar reinventar la rueda", la cual quiere decir que si ya existe en el mercado una herramienta que realice una tarea de manera eficiente en un ámbito o área en particular se debe conjuntar con Spring para llevar a cabo un mejor desempeño y poder sacar así un mejor resultado y una aplicación de mayor calidad. En conclusión cada framework tiene sus ventajas y desventajas, escoger uno es una

decisión

del

desarrollador,

dependiendo

de

sus

necesidades

y

requerimientos, del tamaño del proyecto a desarrollar, así como de su experiencia con tecnologías existentes que se integren fácilmente con el framework que haya elegido. Esto con el fin de aprovechar algunas tecnologías que estén enfocadas en un área específica, para que brinde una mejor y más sencilla forma de llevar a cabo la tarea. Esta fue una de las razones por la cual se decidió incursar dentro de las características de Spring, y después de un análisis se llego a la conclusión de que es un buen framework que cumple con la mayoría de las características, de las cuales otros frameworks escasean.


38




Una de las cuestiones que ha hecho a Spring evolucionar de manera muy rápida en tan poco tiempo, es que se han incrementando de una manera increíble el número de proyectos que utilizan esta herramienta a través del último año. Esto conlleva a que la cantidad de personas interesadas en este framework aumente, así como el soporte, el número de foros de opinión y la publicación de un mayor número de libros y tutoriales.

2.6.6. GESTIÓN DE INCIDENTES: Según OSIATIS S.A. V2.0:  Visión General La Gestión de Incidentes tiene como objetivo resolver cualquier incidente que cause una interrupción en el servicio de la manera más rápida y eficaz posible. La Gestión de Incidentes no debe confundirse con la Gestión de Problemas, pues a diferencia de esta última, no se preocupa de encontrar y analizar las causas subyacentes a un determinado incidente sino exclusivamente a restaurar el servicio. Sin embargo, es obvio, que existe una fuerte interrelación entre ambas. Las propiedades y funcionalidades de la Gestión de Incidentes se resumen sucintamente en el siguiente gráfico:

Gráfico N° 006: Gestión de Incidentes Fuente: OSIATIS S.A. V2.0 Sistema de Control para las Tareas del Servicio de Soporte Técnico de la Oficina de Informática de la Municipalidad Provincial de Piura mediante una Aplicación Web

39




 Introducción y Objetivos Los objetivos principales de la Gestión de Incidentes son:

•

Detectar cualquiera alteración en los servicios TI (Tecnologías de Información).

•

Registrar y clasificar estas alteraciones.

•

Asignar el personal encargado de restaurar el servicio según se define en el SLA (Acuerdo de Nivel de Servicio) correspondiente.

Esta actividad requiere un estrecho contacto con los usuarios, por lo que el Centro de Servicios (Service Desk) debe jugar un papel esencial en el mismo. El siguiente diagrama resume el proceso de gestión de incidentes:

Gráfico N° 007: Proceso de Gestión de Incidentes (resumen) Fuente: OSIATIS S.A. V2.0 Aunque el concepto de incidencia se asocia naturalmente con cualquier malfuncionamiento de los sistemas de hardware y software según el libro de Soporte del Servicio de ITIL (Bibliotecas de Infraestructura de las Tecnologías de Información) un incidente es: “Cualquier evento que no forma parte de la operación estándar de un servicio y que causa, o puede causar, una interrupción o una reducción de calidad del mismo”.


40




Por lo que casi cualquier llamada al Centro de Servicios puede clasificarse como un incidente, lo que incluye a las Peticiones de Servicio tales como concesión de nuevas licencias, cambio de información de acceso, etc. siempre que estos servicios se consideren estándar. Cualquier cambio que requiera una modificación de la infraestructura no se considera un servicio estándar y requiere el inicio de una Petición de Cambio (RFC) que debe ser tratada según los principios de la Gestión de Cambios. Los principales beneficios de una correcta Gestión de Incidentes incluyen: •

Mejorar la productividad de los usuarios.

•

Cumplimiento de los niveles de servicio acordados en el SLA.

•

Mayor control de los procesos y monitorización del servicio.

•

Optimización de los recursos disponibles.

•

Una CMDB (Base de Datos de la Gestión de Configuraciones) más precisa pues se registran los incidentes en relación con los elementos de configuración.

•

Y principalmente: mejora la satisfacción general de clientes y usuarios.

Por otro lado una incorrecta Gestión de Incidentes puede acarrear efectos adversos tales como: •

Reducción de los niveles de servicio.

•

Se dilapidan valiosos recursos: demasiada gente o gente del nivel inadecuado

trabajando

concurrentemente

en

la

resolución

del

incidente. •

Se pierde valiosa información sobre las causas y efectos de los incidentes para futuras reestructuraciones y evoluciones.

•

Se crean clientes y usuarios insatisfechos por la mala y/o lenta gestión de sus incidentes.

Las principales dificultades a la hora de implementar la Gestión de Incidentes se resumen en:


41



•


No se siguen los procedimientos previstos y se resuelven las incidencias sin registrarlas o se escalan innecesariamente y/o omitiendo los protocolos preestablecidos.

•

No existe un margen operativo que permita gestionar los “picos” de incidencias por lo que éstas no se registran adecuadamente e impiden la correcta operación de los protocolos de clasificación y escalado.

•

No están bien definidos los niveles de calidad de servicio ni los productos soportados. Lo que puede provocar que se procesen peticiones que no se incluían en los servicios previamente acordados con el cliente.

 Clasificación del Incidente Es moneda frecuente que existan múltiples incidencias concurrentes por lo que es necesario determinar un nivel de prioridad para la resolución de las mismas. El nivel de prioridad se basa esencialmente en dos parámetros:

•

Impacto: determina la importancia del incidente dependiendo de cómo éste afecta a los procesos de negocio y/o del número de usuarios afectados.

•

Urgencia: depende del tiempo máximo de demora que acepte el cliente para la resolución del incidente y/o el nivel de servicio acordado en el SLA.

También se deben tener en cuenta factores auxiliares tales como el tiempo de resolución esperado y los recursos necesarios: los incidentes “sencillos” se tramitarán cuanto antes. Dependiendo de la prioridad se asignarán los recursos necesarios para la resolución del incidente. La prioridad del incidente puede cambiar durante su ciclo de vida. Por ejemplo, se pueden encontrar soluciones temporales que restauren aceptablemente los niveles de servicio y que permitan retrasar el cierre del incidente sin graves repercusiones.


42




Es conveniente establecer un protocolo para determinar, en primera instancia, la prioridad del incidente. El siguiente diagrama nos muestra un posible “diagrama de prioridades” en función de la urgencia e impacto del incidente:

Gráfico N° 008: Diagrama de Prioridades Del Incidente Fuente: OSIATIS S.A. V2.0  Escalado y Soporte Es frecuente que el Centro de Servicios no se vea capaz de resolver en primera instancia un incidente y para ello deba recurrir a un especialista o a algún superior que pueda tomar decisiones que se escapan de su responsabilidad. A este proceso se le denomina escalado. Básicamente hay dos tipos diferentes de escalado:

•

Escalado funcional: Se requiere el apoyo de un especialista de más alto nivel para resolver el problema.

•

Escalado jerárquico: Debemos acudir a un responsable de mayor autoridad para tomar decisiones que se escapen de las atribuciones asignadas a ese nivel, como, por ejemplo, asignar más recursos para la resolución de un incidente específico.


43




El proceso de escalado puede resumirse gráficamente* como sigue:

* El escalado puede incluir más niveles en grandes organizaciones, o por el contrario, integrar diferentes niveles en el caso de PYMES

Gráfico N° 009: Proceso de Escalado de Incidentes Fuente: OSIATIS S.A. V2.0  Proceso El siguiente diagrama muestra los procesos implicados en la correcta Gestión de Incidentes:


44




Gráfico N° 010: Procesos implicados en la Gestión de Incidentes Fuente: OSIATIS S.A. V2.0

2.6.7. GESTIÓN DE PROBLEMAS: Según OSIATIS S.A. V2.0:

 Visión General Las funciones principales de la Gestión de Problemas son: o

Investigar las causas subyacentes a toda alteración, real o potencial, del servicio TI.

o

Determinar posibles soluciones a las mismas.

o

Proponer las peticiones de cambio (RFC) necesarias para restablecer la calidad del servicio.

o

Realizar Revisiones Post Implementación (PIR) para asegurar que los cambios han surtido los efectos buscados sin crear problemas de carácter secundario.

La Gestión de Problemas puede ser:


45




Reactiva: Analiza los incidentes ocurridos para descubrir su causa y propone soluciones a los mismos. Proactiva: Monitoriza la calidad de la infraestructura TI y analiza su configuración con el objetivo de prevenir incidentes incluso antes de que estos ocurran. Las interacciones y funcionalidades de la Gestión de Problemas se resumen sucintamente en el siguiente gráfico:

Gráfico N° 011: Interacciones y Funcionalidades de la Gestión de Problemas Fuente: OSIATIS S.A. V2.0  Introducción y Objetivos Como se explicó en la sección de Gestión de Incidentes, esta última tiene como exclusivo objetivo el restablecer lo más rápidamente la calidad del servicio y no el determinar cuáles han sido los orígenes y causas del mismo.


46




Cuando algún tipo de incidente se convierte en recurrente o tiene un fuerte impacto en la infraestructura TI es la función de la Gestión de Problemas el determinar sus causas y encontrar posibles soluciones. Cabe diferenciar entre: Problema: causa subyacente, aún no identificada, de una serie de incidentes o un incidente aislado de importancia significativa. Error conocido: Un problema se transforma en un error conocido cuando se han determinado sus causas. Entre las funciones principales de la Gestión de Problemas figuran: o

Identificar, registrar y clasificar los problemas.

o

Dar soporte a la Gestión de Incidentes proporcionando información y soluciones temporales o parches.

o

Analizar y determinar las causas de los problemas y proponer soluciones.

o

Elevar RFCs a la Gestión de Cambios para llevar a cabo los cambios necesarios en la infraestructura TI.

o

Realizar un seguimiento post-implementación de todos los cambios para asegurar su correcto funcionamiento.

o

Realizar informes que documenten no sólo los orígenes y soluciones a un problema sino que también sirvan de soporte a la estructura TI en su conjunto.

o

Analizar tendencias para prevenir incidentes potenciales.

Los principales beneficios de una correcta Gestión de Problemas:

o Un aumento de la calidad general de los servicios TI. o Se minimiza el número de incidentes. o Los incidentes se solucionan más rápidamente y, generalmente, en la primera línea de soporte TI ahorrando recursos e innecesarios escalados.

o La documentación desarrollada es de gran utilidad para la Gestión de la Capacidad, Disponibilidad y Niveles de Servicio.


47




Las principales dificultades a la hora de implementar la Gestión de Problemas se resumen en: o

Establecer una estrecha colaboración entre la Gestión de Incidentes y la de Problemas. Sin ésta la Gestión de Incidentes no dispondrá de toda la información necesaria para la rápida solución de los incidentes y la Gestión de Problemas carecerá de la información necesaria para determinar, clasificar y resolver los problemas.

o

Mantener actualizadas las bases de datos asociadas requiere un compromiso

por

parte

de

todos

los

agentes

implicados

que

frecuentemente requiere un seguimiento cercano de los responsables de la infraestructura TI. o

Aumento de los costes por la contratación de personal especializado, aunque estos se vean sobradamente compensados por los beneficios derivados.

 Proceso Las principales actividades de la Gestión de Problemas son: Control de Problemas: se encarga de registrar y clasificar los problemas para determinar sus causas y convertirlos en errores conocidos. Control de Errores: registra los errores conocidos y propone soluciones a los mismos mediante RFCs que son enviadas a la Gestión de Cambios. Asimismo efectúa la Revisión Post Implementación de los mismos en estrecha colaboración con la Gestión de Cambios. Y cuando la estructura de la organización lo permite, desarrollar una Gestión de Problemas Proactiva que ayude a detectar problemas incluso antes de que estos se manifiesten provocando un deterioro en la calidad del servicio. El siguiente diagrama muestra los procesos implicados en la correcta Gestión de Problemas:


48




Gráfico N° 012: Procesos Implicados en la Gestión de Problemas Fuente: OSIATIS S.A. V2.0  Proceso - Control de Problemas El principal objetivo del Control de Problemas es conseguir que estos se conviertan en Errores Conocidos para que el Control de Errores pueda proponer las soluciones correspondientes.

Gráfico N° 013: Control de Problemas Fuente: OSIATIS S.A. V2.0


49




El Control de Problemas se compone en esencia de tres fases: 1. Identificación y Registro Una de las tareas principales de la Gestión de Problemas es identificar los mismos. Las principales fuentes de información utilizadas son:

o La base de datos de Incidentes: en principio cualquier incidente del que no se conocen sus causas y que se ha cerrado mediante algún tipo de solución temporal es potencialmente un problema. Sin embargo, se habrá de analizar si este incidente es aislado o su impacto en la estructura TI antes de elevarlo a la categoría de problema.

o Análisis de la infraestructura TI: en colaboración con la Gestión de Disponibilidad y de Capacidad, la Gestión de Problemas debe analizar los diferentes procesos y determinar en qué aspectos se debe reforzar los sistemas y estructuras TI para evitar futuros problemas.

o Deterioro de los Niveles de Servicio: el descenso del rendimiento puede ser una indicación de la existencia de problemas subyacentes que no se hayan manifestado de forma explícita como incidentes. Todas las áreas de la infraestructura TI deben colaborar con la Gestión de Problemas para identificar problemas reales y potenciales informando a ésta de cualquier síntoma que pueda ser señal de un deterioro en el servicio TI. El registro de problemas es, en principio, similar al de los incidentes aunque el énfasis debe hacerse no en los detalles específicos de los incidentes asociados sino más bien en su naturaleza y posible impacto. El registro debe incorporar, entre otra, información sobre: o

Los CIs implicados.

o

Causas del problema.

o

Síntomas asociados.

o

Soluciones temporales.

o

Servicios involucrados.

o

Niveles de prioridad, urgencia e impacto.


50



o


Estado: activo, error conocido, cerrado. 2. Clasificación y Asignación de Recursos

La clasificación del problema engloba desde las características generales de éste, tales como si es un problema de hardware o software, que áreas funcionales se ven afectadas y detalles sobre los diferentes elementos de configuración (CIs) involucrados en el mismo. Un factor esencial es la determinación de la prioridad del problema, que al igual que en el caso de los incidentes, se determina tanto a partir de la urgencia (demora aceptable para la solución del problema) como de su impacto (grado de deterioro de la calidad del servicio). Al igual que en la Gestión de Incidentes la prioridad puede cambiar en el curso del ciclo de vida del problema, por ejemplo, si se encuentra una solución temporal al mismo que reduce considerablemente su impacto. Una vez clasificado y determinada su prioridad se deben de asignar los recursos necesarios para su solución. Estos recursos deben ser suficientes para asegurar que los problemas asociados son tratados eficazmente y así minimizar su impacto en la infraestructura TI. 3. Análisis y Diagnóstico: Error conocido Los objetivos principales del proceso de análisis son: o

Determinar las causas del problema.

o

Proporcionar soluciones temporales a la Gestión de Incidentes para minimizar el impacto del problema hasta que se implemente los cambios necesarios que lo resuelvan definitivamente.

Es esencial tener en cuenta que no siempre el origen del problema es un error de hardware o software. Es moneda frecuente que el problema este causado por: o

Errores de procedimiento.

o

Documentación incorrecta.


51




o

Falta de coordinación entre diferentes áreas.

o

...

Es también posible que la causa del problema sea un "bug" bien conocido de alguno de las aplicaciones utilizadas. Por lo tanto es conveniente establecer contacto directo con el entorno de desarrollo, en caso de aplicaciones desarrolladas "en la casa", o investigar en Internet información sobre errores conocidos aplicables al problema en cuestión. Una vez determinadas las causas del problema éste se convierte en un Error Conocido y se remite al Control de Errores para su posterior procesamiento.  Proceso - Control de Errores Una vez que el Control de Problemas ha determinado las causas de un problema es responsabilidad del Control de Errores el registro del mismo como error conocido.

Gráfico N° 014: Control de Errores Fuente: OSIATIS S.A. V2.0


52



•


Identificación y Registro de errores

El registro de los errores conocidos es de vital importancia para la Gestión de Incidentes pues debe llevar asociado, siempre que esto sea posible, algún tipo de solución temporal que permita minimizar el impacto de los incidentes asociados. •

Análisis y Solución

Se deben investigar diferentes soluciones para el error evaluando en cada momento: o

El posible impacto de las mismas en la infraestructura TI.

o

Los costes asociados.

o

Sus consecuencias sobre los SLAs.

En algunos casos, en los que el impacto del problema puede tener consecuencias graves en la calidad del servicio, pueden emitirse una RFC de emergencia para su procesamiento urgente por la Gestión de Cambios. Una vez determinada la solución óptima al problema y antes de elevar una RFC a la Gestión de Cambios han de tenerse en cuenta las siguientes consideraciones: o

¿Es conveniente demorar la solución? Ya sea porque se prevén cambios significativos en la infraestructura TI a corto plazo o por el escaso impacto del problema en cuestión.

o

¿Es la solución temporal aportada suficiente para mantener unos niveles de calidad de servicios aceptable?

o

¿Los beneficios justifican los costes asociados?

Sea cual sea la respuesta, todo la información sobre el error y su solución se registrará en las bases de datos asociadas. En el caso en el que se considere que el problema necesita ser solucionado se emitirá una RFC. Será responsabilidad de la Gestión de Cambios la implementación de los cambios de infraestructura propuestos. Sistema de Control para las Tareas del Servicio de Soporte Técnico de la Oficina de Informática de la Municipalidad Provincial de Piura mediante una Aplicación Web

53



•


Revisión Post Implementación y Cierre

Antes de dar el problema por resuelto y cambiar su estado a “cerrado” se debe analizar el resultado de la implementación de la RFC elevado a la Gestión de Cambios (PIR). Si los resultados de esta PIR son los deseados y se pueden cerrar todos los incidentes relacionados con este problema se considera concluido el proceso y se emiten los informes correspondientes.

2.6.8. METODOLOGIA DE DESARROLLO: Estas son más que todo un "conjunto de procedimientos, técnicas y ayudas a la documentación para el desarrollo de productos software. Una metodología incluye la tarea construir modelo conceptual de datos. Para realizarlo, define un procedimiento y da a elegir entre una serie de técnicas" [URJC 2006]. Entre las más conocidas podemos mencionar las siguientes:

Gráfico N° 015: Metodologías de Desarrollo de Software Sistema de Control para las Tareas del Servicio de Soporte Técnico de la Oficina de Informática de la Municipalidad Provincial de Piura mediante una Aplicación Web

54




Fuente: Universidad Rey Juan Carlos (2006) Pero dentro de esto se encuentra uno de los puntos clave que como futuros ingenieros de sistemas estamos en la obligación de saberlo y poseerlo como uno de nuestra cultura general profesional, se trata de lo que es un Proceso de Desarrollo de Software. Pero que objetivo tiene un Proceso de Desarrollo de Software, básicamente su objetivo se direcciona hacia "subir la calidad del software (en todas las fases por las que pasa) a través de un mayor control sobre el proceso. Es labor del proceso de desarrollo definir quién debe hacer Qué, cuándo y cómo debe hacerlo" [Patricio Letelier 2000]. En esta parte de la investigación realizada hablaremos sobre algunas de las metodologías de desarrollo de software existentes en la actualidad, entre las principales tenemos a:  RUP (Rational Unified Process).  XP (Extreme Programming).  FDD, etc. •

RUP (Rational Unified Process):

Fue el mismo Barry Boehm, autor del modelo de espiral del proceso de software, quien en su artículo [Boehm, 1995] describe tres hitos críticos a ser utilizados en cualquier proyecto de forma de poder planificar y controlar el progreso del mismo, dando visibilidad a los stakeholders. Estos hitos están relacionados con las etapas de avance que se van dando a lo largo de un proyecto de acuerdo al pasaje que ocurre de las actividades de ingeniería (que componen los espirales del modelo en espiral) a las actividades de producción (que componen la construcción en cascada del software). Su impacto en la industria del software ha sido tan importante que uno de los procesos más utilizados en la actualidad, el [RUP, 2002], los incorpora. Estos hitos son: • Objetivos del Ciclo de Vida • Arquitectura del Ciclo de Vida • Capacidad Operacional Inicial


55




RUP es uno de los procesos más generales del los existentes actualmente, ya que en realidad esta pensado para adaptarse a cualquier proyecto, y no tan solo de software. Un proyecto realizado siguiendo RUP se divide en cuatro fases: 1. Intercepción (puesta en marcha). 2. Elaboración (definición, análisis, diseño). 3. Construcción (implementación). 4. Transición (fin del proyecto y puesta en producción). Se tiene que tener en cuenta que "en cada fase se ejecutarán una o varias iteraciones, las cuales están debidamente explicadas en el Proceso Iterativo e Incremental. Pero a que se refiere con el proceso iterativo e incremental, se refiere más que tono a la evolución de prototipos ejecutables que se muestran a los usuarios y clientes [Rational Software Company 2001].


56




Gráfico N° 016: Dos Dimensiones de RUP Fuente: Introducción a Rational Unified Process (RUP) - Patricio Letelier 2000 RUP define nueve actividades a realizar en cada fase del proyecto: 1. Modelado del negocio. 2. Análisis de requisitos. 3. Análisis y diseño. 4. Implementación. 5. Test. 6. Distribución. 7. Gestión de configuración y cambios 8. Gestión del proyecto. 9. Gestión del entorno. Pero por otra parte también posee elementos o Workflows de apoyo entre los cuales tenemos [Patricio Letelier 2000]:  Environment (Entorno).  Project Management (Gestión del Proyecto).  Configuration & Change Management (Gestión de Configuración y Cambios). Artefactos:  Resultado parcial o final que es producido y usado durante el proyecto. Son las entradas y salidas de las actividades.  Un artefacto puede ser un documento, un modelo o un elemento de modelo. Sistema de Control para las Tareas del Servicio de Soporte Técnico de la Oficina de Informática de la Municipalidad Provincial de Piura mediante una Aplicación Web

57




 Conjuntos de Artefactos. o

Business Modeling Set.

o

Requirements Set.

o

Analysis & Design Set.

o

Implementation Set.

o

Test Set.

o

Deployment Set.

o

Project Management Set.

o

Configuration & Change Management Set.

o

Environment Set.

Características Esenciales de RUP:  Proceso Dirigido por los Casos de Uso  Proceso Iterativo e Incremental  Proceso Centrado en la Arquitectura Proceso Iterativo e Incremental:  El ciclo de vida iterativo se basa en la evolución de prototipos ejecutables que se muestran a los usuarios y clientes.  En el ciclo de vida iterativo a cada iteración se reproduce el ciclo de vida en cascada a menor escala.  Los objetivos de una iteración se establecen en función de la evaluación de las iteraciones precedentes.  Las actividades se encadenan en una mini-cascada con un alcance limitado por los objetivos de la iteración.


58




Gráfico N° 017: Proceso Iterativo Incremental

Fuente: Introducción a Rational Unified Process (RUP) - Patricio Letelier 2000 Puntos Claves:  Pesado.  Dividido en cuatro fases.  La fase se dividen en iteraciones.  El discurrir del proyecto se define en Workfíows. » Los artefactos son el objetivo de cada actividad.  Se basa en roles.  UML.  Muy organizativo.  Mucha documentación. •

XP (Extreme Programming) ó Programación Extrema:

Es la primera metodología ágil y es la que le dio conciencia al movimiento actual de metodologías ágiles. De la mano de Kent Beck, XP ha conformado un extenso grupo de seguidores en todo el mundo, disparando una gran cantidad de libros a los que dio comienzo el mismo Beck en [Beck, 2000]. Inclusive Addison-Wesley ha creado una serie de libros denominada The XP Series. Fue la misma gente del proyecto C3 (Sistema Exhaustivo de Compensaciones de Chrysler) la que produjo también otro de los libros importantes de XP [Jeffries, 2001] en el que se bajaban los conceptos de Beck a la puesta en práctica en un proyecto. La imagen mental de Beck al crear XP [Beck, 2000] era la de perillas en un tablero de control. Cada perilla representaba una práctica que de su experiencia sabía que trabajaba bien. Entonces, Beck decidió girar todas las perillas al máximo para ver que ocurría. Así fue como dio inicio a XP. En la programación extrema, cada contribuidor al proyecto es una parte integral del "equipo entero". El equipo forma alrededor de un representante del negocio llamado "el cliente", que se sienta con el equipo y trabaja con ellos diariamente. Diseño simple.


59




Los equipos de XP construyen software a un diseño simple. Comienzan simple, y con la prueba del programador y la mejora del diseño, la guardan de esa manera. Un equipo de XP mantiene el diseño satisfecho exactamente para la funcionalidad actual del sistema. No hay movimiento perdido, y el software es siempre listo para lo siguiente. El diseño en XP no es una cosa de una sola vez, es una cosa de todo el tiempo. En donde los equipos se deben acostumbrar a sesiones rápidas de diseño. Integración continua. Los equipos de programación extrema mantienen el sistema integrado completamente siempre. Los equipos de XP construyen épocas múltiples por día. (Un equipo de XP de cuarenta personas construye por lo menos ocho o diez veces por día). La integración infrecuente conduce a los problemas senos en un proyecto del software. Se tiene que tener en cuenta que la integración es crítica al momento del envío de código, ya que el equipo no participa en ello, y se delega a menudo a la gente que no está al corriente del sistema entero. Codificación de estándar. Los equipos de XP siguen un estándar común de la codificación, de modo que todo el código en el sistema mire como si fuera escrito por un solo programador. Lo importante es que todo el código parezca familiar. Mientras que el RUP intenta reducir la complejidad del software por medio de estructura y la preparación de las tareas pendientes en función de los objetivos de la fase y actividad actual, XP, como toda metodología ágil, lo intenta por medio de un trabajo orientado directamente al objetivo, basado en las relaciones interpersonales y la velocidad de reacción. XP intenta minimizar el riesgo de fallo del proceso por medio de la disposición permanente de un representante competente del cliente a disposición del equipo de desarrollo. Este representante debería estar en condiciones ue contestar rápida y correctamente a cualquier pregunta del equipo de desarrollo de forma que no se retrase la tomar de decisiones, de ahí lo de competente. La codificación del software en XP se produce siempre en parejas (dos programadores, un ordenador), por lo que se espera que la calidad del mismo Sistema de Control para las Tareas del Servicio de Soporte Técnico de la Oficina de Informática de la Municipalidad Provincial de Piura mediante una Aplicación Web

60




suba en el mismo momento de escribirlo. Al contrario que muchos otros métodos, el código pertenece al equipo en completo, no a un programador o pareja, de forma que cada programador puede cambiar cualquier parte del código en cualquier momento si así lo necesita, dejándose en todo caso las mejoras orientadas al rendimiento para el final. Las parejas no se mantienen para todo el proyecto si no que rotan cíclicamente a lo largo del mismo, tanto en cuanto a los componentes de la misma como en las partes del software que desarrollan, así cada componente del equipo aprende como trabaja el resto. El objetivo ideal seria que cada componente del equipo trabaje al menos una vez con cada uno de los demás integrantes y con cada componente software, de forma que el conocimiento de la aplicación completa lo posea el equipo entero y no unos pocos miembros. En XP se programará solo la funcionalidad que es requerida. Es decir, una gran flexibilidad y capacidad de configuración solo será implementada cuando sea necesaria para cumplir los requerimientos. Se sigue un diseño evolutivo con la siguiente premisa: conseguir la funcionalidad deseada de la forma más sencilla posible. Este diseño evolutivo hace que no se le de apenas importancia al análisis como fase independiente, puesto que se trabaja exclusivamente en función de las necesidades del momento. Puntos Claves: 

Ligero.



Cercano al desarrollo.



Se basa en UserStories.



Fuerte comunicación con el cliente.



El código fuente pertenece a todos.



Programación por parejas.



Tests como base de la funcionalidad.



Solo el mínimo de organización.



Pobre en cuanto a documentación. •

FDD (Desarrollo Manejado Por Rasgos):

Peter Coad es considerado uno de los referentes más importantes dentro de la ingeniería de software. Coad ha sido uno de los principales pioneros detrás del movimiento de la orientación a objetos y empezó a trabajar con Ed Yourdon (uno Sistema de Control para las Tareas del Servicio de Soporte Técnico de la Oficina de Informática de la Municipalidad Provincial de Piura mediante una Aplicación Web

61




de los creadores del Análisis Estructurado) a principios de los noventa, cuando este último pidió ayuda a alguien de la comunidad de objetos para desarrollar una nueva metodología, basada en el paradigma de OO. Posteriormente, Coad junto con Jeff De Luca y otros, participaría en la creación de FDD, una metodología desarrollada alrededor del año 1998 que presenta las características de un proceso ágil [Coad, 1998]. La misma derivó del trabajo de Coad sobre las Feature Lists (Listas de Funcionalidades). FDD se estructura alrededor de la definición de features que representan la funcionalidad

que debe contener

el sistema,

y tienen

un alcance

lo

suficientemente corto como para ser implementadas en un par de semanas. FDD posee también una jerarquía de features, siendo el eslabón superior el de feature set que agrupa un conjunto de features relacionadas con aspectos en común del negocio. Por último, establece el major feature set como el más alto nivel de agrupación de funcionalidad que abarca diferentes feature sets que contribuyen a proveer valor al cliente en relación a un subdominio dentro del dominio completo de la aplicación. Una de las ventajas de centrarse en las features del software es el poder formar un vocabulario común que fomente que los desarrolladores tengan un diálogo fluido con los clientes, desarrollando entre ambos un modelo común del negocio. Este tema será tratado más adelante en relación al enfoque de las metodologías ágiles en los productos entregados. El FDD tiene cinco procesos. Los primeros tres se hacen al principio del proyecto y son:

a) Desarrollar un Modelo Global. b) Construir una Lista de los Rasgos. c) Planear por Rasgo. Los últimos dos se hacen en cada iteración. Cada proceso se divide en tareas y se da un criterio de comprobación.

d) Diseñar por Rasgo. e) Construir por Rasgo. OBJETIVOS  Sintetizar un programa conforme a los rasgos requeridos.


62




 En un desarrollo en términos de FOP (Programación Orientada a rasgos), los objetos se organizan en módulos o capas conforme a rasgos. FDD esta pensado para proyectos con tiempo de desarrollo relativamente cortos (menos de un año). Se basa en un proceso iterativo con iteraciones cortas (2 semanas aproximadamente) que producen un software funcional que el cliente y la dirección de la empresa pueden ver y monitor izar. Un proyecto que sigue FDD se divide en 5 fases: 1. Desarrollo de un modelo general. 2. Construcción de la lista de funcionalidades o rasgos. 3. Plan en base a las funcionalidades o rasgos a implementar. 4. Diseñar en base a las funcionalidades o rasgos. 5. Implementar en base a las funcionalidades o rasgos.

Gráfico N° 018: Proceso FDD

Fuente: COAD, 1998 Las primeras tres fases ocupan gran parte del tiempo en las primeras iteraciones, siendo las dos últimas las que absorben la mayor parte del tiempo según va avanzando el proyecto, limitándose las primeras a un proceso de refinamiento. El trabajo (tanto de modelado como de desarrollo) se realiza en grupo, aunque siempre habrá un responsable último (arquitecto jefe o jefe de programadores en función de la fase en que nos encontremos), con mayor experiencia, que tendrá la última palabra en caso de no llegar a un acuerdo. Al hacerlo en grupo se consigue que todos formen parte del proyecto y que los menos inexpertos aprendan de las


63




discusiones de los mas experimentados, y al tener un responsable último, se asignan las responsabilidades que todas las empresas exigen. FDD también define métricas para seguir el proceso de desarrollo de la aplicación, útiles para el cliente y la dirección de la empresa, y que pueden ayudar, además de para conocer el estado actual del desarrollo, a realizar mejores estimaciones en proyectos futuros. Puntos Claves:  Ligero.  A medio camino entre el desarrollo y la organización.  Existe una jerarquía dentro del equipo.  El código fuente tiene propietario.  Los equipos varían en fúnción de la funcionalidad a implementar.  El conocimiento de la aplicación se reparte a través de trabajo en equipo y revisiones.  Documentación aceptable.


64




2.7. MARCO CONCEPTUAL: Título “Sistema de Control para las Tareas del Servicio de Soporte Técnico de la Oficina de Informática de la Municipalidad Provincial de Piura mediante una Aplicación Web” Aplicación Web. "La World Wide Web é Internet han introducido a la población en general en el mundo de la informática. Compramos fondos de inversión colectivos y acciones, descargamos música, vemos películas, obtenemos asesoramiento médico, hacemos gestiones de diversos tipos como personales y corporativas…" [IEEE] con respecto a la herramienta a producir en el presente proyecto. Sistema de Control para las Tareas del Servicio de Soporte Técnico de la Oficina de Informática de la Municipalidad Provincial de Piura. "Los sistemas de control y supervisión son una clase importante de sistemas de tiempo real. Verifican los sensores que proveen información del entorno del sistema y toman acciones…" [SOMMERVILLE, 2002] con respecto al control que asumiría soporte técnico en sus tareas de mantenimiento en la Municipalidad Provincial de Piura. Metodología Rational Unified Process (RUP). "Conjunto de actividades necesarias para transformar los requisitos de un usuario en un sistema software. Además es un marco de trabajo genérico que puede especializarse para una gran variedad de sistemas software, para diferentes áreas de aplicación, diferentes tipos de organizaciones, diferentes niveles de aptitud y diferentes tamaños de proyecto" [Jacobson & Booch & Rumbaugh 2000].


65




2.8. HIPOTESIS: La implementación de una Aplicación Web influye en el sistema de control de las tareas del servicio de Soporte Técnico de la Oficina de Informática de la Municipalidad Provincial de Piura.

2.9. VARIABLES E INDICADORES IMPLICADOS EN EL PROYECTO:  Variable Independiente:  Aplicación Web: El presente proyecto desarrollará una Aplicación Web que va permitir al Área de Soporte Técnico tener un mejor control y seguimiento de los procesos que se siguen para la solución de los problemas que se presentan en las distintas oficinas de la Municipalidad de Piura. Esta mejora del Sistema de Información actual que presenta el Área de Soporte Técnico permitirá optimizar dichos procesos, siendo más eficientes y reduciendo el tiempo de las atenciones.

 Variable Dependiente:  Sistema de Control para las Tareas del Servicio: El actual desarrollo de las tareas del servicio de Soporte Técnico para el mantenimiento, reparación y respaldo de los diversos equipos informáticos y electrónicos, se da de manera informal y sin documentar muchas de las atenciones de los problemas e incidentes que ocurren en las diferentes oficinas de la Municipalidad de Piura, es por estos motivos que la presente Aplicación Web a desarrollar permitirá optimizar el desarrollo y ejecución de dichas operaciones técnicas a través de un mejor control, administración y organización.

 Variable Interviniente:  Proceso Unificado de Racional (RUP): Es una metodología del proceso de ingeniería de software que proporciona un enfoque disciplinado para asignar tareas y responsabilidades dentro de una organización del desarrollo y será aplicada en la presente tesis. Sistema de Control para las Tareas del Servicio de Soporte Técnico de la Oficina de Informática de la Municipalidad Provincial de Piura mediante una Aplicación Web

66




 Indicadores:

Nro

Indicador

Definición Conceptual

Definición Operacional

I01 Tiempo para llegar a atender una Solicitud de Servicio.

Tiempo que el técnico demora en llegar a una solicitud de servicio.

I02 Tiempo para solucionar una solicitud de Servicio.

n Es el tiempo que Ti el técnico i =1 demora en TS = n solucionar una T = Tiempo de solución s solicitud de de Solicitudes de servicio. Servicio. T = Tiempo para realizar una Solución de Servicio. n = Cantidad total de Solicitudes de Servicio n Porcentaje de Mi solicitudes de i =1 servicios SM = x100% T atendidas por SM= Porcentaje de técnico. cumplimiento de un técnico de sus servicios asignados. M = Solicitudes atendidas. T = Total de Solicitudes de Servicios Asignados. n Porcentaje de Snai Solicitudes i =1 realizadas por el Sn = x100% N usuario que no Sn = Porcentaje de han sido Servicios no atendidos. atendidas por Sna = Servicio no diversos atendido. motivos. N = Total de Solicitudes.

I03 Cumplimiento de un Técnico en cuanto a los Servicios Asignados.

I04 Porcentaje de Servicio no atendidos.

n

SS =

∑S i =1

Unidad de Medida

Técnica de Instrumentos Medición de Medición

Minutos

Observación

Guía de Observación N° 01 (Cronómetro) Anexo

Minutos

Observación


Porcentaje

Observación

Guía de Observación N° 03 Anexo

Porcentaje

Observación


i

n

Ss - Tiempo de Asistencia a la Solicitud de Servicio. S = Tiempo de traslado entre servicio. n = Cantidad total de Solicitudes de Servicio

∑

∑

∑

Cuadro N° 002: Indicadores de la Variable Dependiente Fuente: El Autor Sistema de Control para las Tareas del Servicio de Soporte Técnico de la Oficina de Informática de la Municipalidad Provincial de Piura mediante una Aplicación Web

67



Nro

Indicador

I05 Solicitudes de Servicio Asignadas por Técnico.




Unidad de Medida

Técnica de Instrumentos Medición de Medición

n Es el número de S = St servicios S t =1 asignados a St =servicio asignado por cada técnico. técnico. t =orden de servicio asignada al técnico. Ss =Solicitudes de Servicio. n Es el número de S = Si servicios S i =1 solicitados por SS = Solicitudes de oficina. Servicios de Oficina. Si = Solicitudes de servicios de la Oficina especificada.

Unidad

Observación


Unidad

Observación


I07 Número de equipos internados.

n Son los equipos E = Gi que provienen l i =1 de otra oficina y que tienen que El=Número de Equipos ser atendidos en de otro local. Gi=Guías de Salida. Soporte.

Unidad

Observación


I08 Tiempo de búsqueda de historial técnico.

Tiempo para buscar la información de mantenimiento (bitácora) de un equipo.

Minutos

Observación


Minutos

Observación


I06 Solicitudes de Servicio por oficina.

I09 Tiempo de Emisión (entrega) de Documentos (Reportes, Guías de salida y/o Fichas Técnicas).

∑

∑

∑

Tiempo transcurrido para la entrega de la documentación solicitada.

n

TB =

∑ Ti i =1

n

TB = Tiempo de Búsqueda T = Tiempo de Búsqueda de historial Técnico. n = Cantidad total de búsquedas n

TED =

∑t i =1

i

n

TED = Tiempo de Emisión. t = Tiempo de Entrega por documento. n = Cantidad total de documentación

Cuadro N° 002: Indicadores de la Variable Dependiente (continuación) Fuente: El Autor Sistema de Control para las Tareas del Servicio de Soporte Técnico de la Oficina de Informática de la Municipalidad Provincial de Piura mediante una Aplicación Web

68



Nro

Indicador

I10 Nivel de satisfacción del usuario.




n Medimos la Usi conformidad de i =1 los usuarios con NS = x100% n la herramienta a NS = Nivel de desarrollar. Satisfacción. Us = Usuario Satisfecho. n = Cantidad total de usuarios

∑

Unidad de Medida Porcentaje

Técnica de Instrumentos Medición de Medición Encuesta

Cuestionario de Encuesta N° 01 Anexo

Cuadro N° 002: Indicadores de la Variable Dependiente (continuación) Fuente: El Autor


69




________________________________________________________

CAPITULO III: METODOLOGIA ________________________________________________________


70




3. METODOLOGIA: 3.1. TIPO DE ESTUDIO: Los propósitos básicos del paradigma cuantitativo en la investigación socioeducativa consisten en realizar

mediciones

y predicciones exactas

del

comportamiento regular de grupos sociales. "Los positivistas buscan los hechos o causas de los fenómenos sociales con independencia de los estados subjetivos de los individuos" [Taylor y Bogdan, 1986], es decir buscan la objetividad. La búsqueda principal consiste en explicar las causas de los fenómenos, confrontar teoría y praxis, detectar discrepancias, analizar estadísticamente, establecer conexiones y generalizaciones (abstracciones). [Sant'Anna, y Smith, 1983] sugieren que el paradigma cuantitativo se nutre de los supuestos filosóficos del realismo, racionalismo, positivismo y de la epistemología científica de Comte y el Círculo de Viena. “La Investigación Aplicada es aquel tipo de estudio científico orientado a resolver problemas de la vida cotidiana o a controlar situaciones prácticas.” [José Padrón, 2006] La presente tesis está basada en el paradigma cuantitativo porque me va permitir recoger, procesar y analizar datos numéricos sobre variables determinadas mediante métodos estadísticos. La hipótesis formulada en esta investigación se traduce en variables, las que a su vez se traducen en indicadores cuantificables. Esta es una investigación aplicada porque se busca dar solución a un problema a través del desarrollo de una herramienta tecnológica.


71




3.2. DISEÑO DEL ESTUDIO: Para el presente proyecto de investigación el diseño a utilizar será cuasi experimental con Pre-test y Post-test y grupos intactos. [Hernandez, Fernández, Baptista – 2003] definen que en este tipo de diseño se “...manipulan deliberadamente, al menos, una variable independiente para observar su efecto y relación con una o más variables dependientes, sólo se diferencian de los experimentos verdaderos en el grado de seguridad o confiabilidad que pueda tenerse sobre la equivalencia inicial de los grupos”. O1 – X – O2 O1

: Pre-test o Prueba Inicial

O2

: Post-test o Prueba Final

X

: Variable Interviniente

Este diseño utiliza dos grupos: el experimental (que recibe el tratamiento) y el grupo control (que no recibe el tratamiento). Los grupos son comparados en lapos prueba para analizar si el tratamiento experimental tuvo un efecto sobre la variable dependiente (O1 con O2). No se asignan los grupos ni por azar ni por emparejamiento.

3.3. POBLACIÓN Y MUESTRA:  Población La población tomada para el desarrollo de la presente tesis es el personal encargado del servicio que brinda el área de Soporte Técnico a los diferentes equipos de las dependencias de la Municipalidad de Piura.  Muestra La muestra tomada para el desarrollo de la presente tesis es el personal que labora en el área de Soporte Técnico de la Oficina de Informática de la Municipalidad de Piura. La cantidad de la muestra serán las 5 personas encargadas del servicio que brinda la dependencia en mención, por lo tanto no es necesario aplicar una fórmula para obtener la muestra. Sistema de Control para las Tareas del Servicio de Soporte Técnico de la Oficina de Informática de la Municipalidad Provincial de Piura mediante una Aplicación Web

72




3.4. MÉTODOS DE INVESTIGACIÓN: Recolección de información de un estado inicial a través de una prueba de entrada o pre-test. Posteriormente se aplicará una prueba de salida o post test con una medición de los efectos que ha tenido la variable independiente. Y por último se hará una comparación entre la información que se tuvo al inicio y al final.

3.5. TÉCNICAS E INSTRUMENTOS DE RECOLECCIÓN DE DATOS:  Técnicas Las técnicas de recolección de datos que se emplearán son: encuestas y observación. Estas nos ayudarán a recoger información primordial para desarrollar el presente trabajo de investigación o tesis que tiene por título: “Sistema de Control para las Tareas del Servicio de Soporte Técnico de la Oficina de Informática de la Municipalidad Provincial de Piura”.  Instrumentos Los instrumentos de recolección de datos para el desarrollo de la presente investigación o proyecto de tesis son: las guías de observación y cuestionarios de encuestas. A continuación en el siguiente cuadro se presentan los indicadores con sus respectivas técnicas e instrumentos de recolección de datos:


73



Nº


Indicadores

Técnicas

Instrumentos

1

Tiempo para llegar a atender una Solicitud de Servicio.

Observación

Guía de Observación

2

Tiempo para solucionar una solicitud de Servicio.

Observación


3

Cumplimiento de un Técnico en cuanto a los Servicios Asignados.

Observación


4

Porcentaje de Servicio no atendidos.

Observación


5

Solicitudes de Servicio Asignadas por Técnico.

Observación


6

Solicitudes de Servicio por oficina.

Observación


7

Número de equipos internados.

Observación


8

Tiempo de búsqueda de historial técnico.

Observación


9

Tiempo de Emisión (entrega) de Documentos (Reportes, Guías de salida y/o Fichas Técnicas).

Observación


10

Nivel de satisfacción del usuario.

Encuesta

Cuestionario de Encuesta

Cuadro N° 003: Indicadores, Técnicas e Instrumentos de Recolección de Datos Fuente: El Autor

3.6. MÉTODOS DE ANÁLISIS DE DATOS: Para analizar los datos recolectados se estudiarán los resultados organizados en cuadros estadísticos para determinar las principales tendencias de la información utilizando los porcentajes de los cuadros o de las aplicaciones estadísticas. Para el análisis de datos se va a utilizar el software Microsoft Excel 2007.


74




________________________________________________________

CAPITULO IV: ADMINISTRACION ________________________________________________________


75




4. ADMINISTRACION: 4.1. CRONOGRAMA DE ACTIVIDADES: Para realizar el Cronograma de Gantt de las actividades a desarrollar en la presente tesis hemos utilizado el software Microsoft Office Project 2007, el cual es una herramienta que nos ayuda a realizar cronogramas de actividades para diferentes tipos de proyecto. Este software ayuda a optimizar la distribución del tiempo. A continuación en el cuadro Nº 4 se observa el cronograma del proyecto:

Cuadro N° 004: Cronograma de Actividades de la Tesis Fuente: El Autor


76




4.2. PRESUPUESTO:

Cantidad

C/U

Precio Total

Memoria USB 4 GB

01

S/. 50.00

S/. 50.00

Cartuchos de tinta para impresora

04

S/. 50.00

S/. 200.00

Folder Manila A4

10

S/. 1.00

S/. 10.00

1 millar

S/. 25.00

S/. 25.00

CD’s de 700 MB

10

S/. 1.00

S/. 10.00

Lapiceros

10

S/. 0.50

S/. 5.00

Luz Eléctrica

___

___

S/. 200.00

Internet

200 horas

S/. 1.00

S/. 200.00

Teléfono

___

___

S/. 100.00

Movilidad

___

___

S/. 400.00

500 hojas

S/. 0.05

S/. 25.00

Anillados

2

S/. 5.00

S/. 10.00

Empastados

3

S/. 20.00

S/. 60.00

Personal de apoyo

___

___

S/. 400.00

Otros

___

___

S/. 200.00

Recursos

Bienes Papel A4

Servicios

Fotocopiado

Remuneraciones Total

S/. 1,895.00

Cuadro N° 005: Presupuesto de la Tesis Fuente: El Autor

4.3. FINANCIAMENTO: El presente proyecto de investigación es autofinanciado por el autor ya que la Municipalidad Provincial de Piura no financia este tipo de investigaciones hechas por alumnos universitarios. Sistema de Control para las Tareas del Servicio de Soporte Técnico de la Oficina de Informática de la Municipalidad Provincial de Piura mediante una Aplicación Web

77




________________________________________________________

CAPITULO V: REFERENCIAS BIBLIOGRAFICAS ________________________________________________________


78




REFERENCIAS BIBLIOGRAFICAS [Álvarez Brotons, España, 2004] Sistemas de Control, artículo publicado por en la Universidad Politécnica de Catalunya. [Beck, 2000] Beck, Kent, Extreme Programming Explained, Addison-Wesley The XP Series. [Boehm, noviembre 1995] Boehm, Barry W., Anchoring the Software Process, USC. [Booch, 2000] Booch, Grady, Ivar Jacobson, James Rumbaugh, The Unified Modeling Language User Guide, Addison-Wesley Object Technology Series. Castro Arévalo, Manuel & Zapata Navarro, Jhon (Piura – 2009), “Sistema Informático de Registro de Mantenimiento de Equipos de Cómputo del Área de Soporte del Centro de Informática y Telecomunicaciones de la Universidad Nacional de Piura”. Universidad César Vallejo – Filial Piura. [Coad, 1998] Coad, Peter, Eric Lefebvre, Jeff De Luca, Feature-Driven Development, Disponible en: http://www.cs.jhu.edu/~scott/oos/software/togetherj/help/UsersGuide/Feature_Driven_Development.htm Espinoza Saavedra, Daniel (Valparaíso, Chile – 2004), “Estudio del Sistema de Monitoreo y Registro de Inventarios de Compras y su Integración Estratégica mediante el Control de Gestión”. Universidad de Valparaíso. [Freeman Elisabeth, 2004] et. al. Head First Design Patterns. California: O'Reilly Media. [Gamma Erich, 1995] et. al. Design Patterns.Elements of Reusable Object-Oriented Software. Boston: Addison-Wesley. [Harrop Rob, 2005] et al. Pro Spring. Nueva York: Apress. [Hernandez Sampieri, Roberto; Fernández Collado, Carlos; Baptista Lucio, Pilar; México 2003] Metodología de la Investigación. Mc Graw Hill.


79




REFERENCIAS BIBLIOGRAFICAS [Johnson Rob, 2003] Expert One-on-One J2EE Design and Development. Indianapolis: Wrox Press. [Johnson Rob, mayo 2005] Introduction to the Spring Framework. [En línea]. Disponible en: www.theserverside.com/articles/article.tss?l=SpringFramework [José Padrón G.] Bases del concepto de "Investigación Aplicada"[en línea]. Disponible en: http://padron.entretemas.com/InvAplicada/index.htm Metodologías de Desarrollo de Software (España – 2006), artículo publicado por la Universidad Rey Juan Carlos. Metodología ITIL (Information Technologies Infraestructure Library) – OSIATIS S.A. V2.0 Disponible en: http://itil.osiatis.es/Curso_ITIL/ [P. Letelier, Zaragoza, octubre 2000] Metodologías de Producción de Software. Pesántez Huerta, Álvaro Eduardo (Guayaquil, Ecuador – 2007), “Elaboración de un Plan de Mantenimiento Predictivo y Preventivo en Función de la Criticidad de los Equipos del Proceso Productivo de una Empresa Empacadora de Camarón”. Escuela Superior Politécnica del Litoral. Plan Estratégico Institucional (2009 – 2014), Municipalidad Provincial Piura (PEI-MPP) Plan Operativo Institucional (2011), Municipalidad Provincial de Piura (POI–MPP) Reglamento de Organización y Funciones, Municipalidad Provincial Piura (ROF-MPP) [RUP, 2002] Rational Unified Process® Version 2002.05.00, Copyright © Rational Software Corporation, All Rights Reserved. Salcedo Untiveros, Richard Orlando (Piura – 2007), “Análisis, Diseño y Desarrollo del Módulo Web para la Gestión y Control de Inventario de Bienes de la Oficina de Control Patrimonial de la Dirección Regional de Salud Piura”. Universidad Nacional de Piura.


80




REFERENCIAS BIBLIOGRAFICAS [Sant'Anna, F., 1983] Estratégias quantitativas e qualitativas de pesquisa educational: da ação a obser-vação participante. Educação e realidade. Santillán Pinedo, Karla & Tornero Mendoza, Ludver (Trujillo – 2001), “Sistema de Información de Control de Almacén de la Dirección Regional de Educación de La Libertad – DRELL”. Universidad César Vallejo. [Smith, J., 1983] Quantitative versus qualitative research: An attempt to clarify the issue. Educational Researcher. [Sommerville, Ian, 2002] Ingeniería del Software. [Taylor, S. J. y Bogdan, R., 1986] Introducción a los métodos cualitativos de investigación. La búsqueda de significados. Buenos Aires: Editorial Paidós. Vega Bustamante, Rocío Olinda (Lima – 2009), “Análisis, diseño e implementación de un sistema de administración de incidentes en atención al cliente para una empresa de telecomunicaciones”. Pontificia Universidad Católica del Perú. [Walls Craig, 2005] et. al. Spring in Action. Greenwich: Manning Publications.


81




________________________________________________________

CAPITULO VI: ANEXOS ________________________________________________________


82




ANEXO 01 Guía de Observación Nº 01 Tiempo para llegar a atender una solicitud de servicio. Instrucciones: En los días de observación se tomarán la fecha y hora de inicio del pedido de atención (solicitud de servicio) y la hora de llegada del técnico a la dependencia municipal para atender la solicitud de servicio. Fecha de inicio de observación: __/ __/ ___Hora de Inicio: _________ Hora de Inicio

Número

Hora de Llegada

Tiempo Total (Min)

Tiempo Promedio Hora Final: _________Fecha de fin de observación: __/ __/ _____ Observaciones: _________________________________________________________________ _________________________________________________________________ ___________________________________________________________ Observador Revisado


Procesado

83

Archivado




ANEXO 02 Guía de Observación Nº 02 Tiempo para solucionar una solicitud de servicio. Instrucciones: En los días de observación se tomarán la fecha y hora de inicio de la atención a la solicitud de servicio por parte del técnico y la hora de la finalización de dicha atención. Fecha de inicio de observación: __/ __/ ___Hora de Inicio: _________ Número

Hora de Inicio

Hora de Finalización

Tiempo Total (Min)



Procesado

84

Archivado




ANEXO 03 Guía de Observación Nº 03 Cumplimiento de un técnico en cuanto a los servicios asignados. Instrucciones: En los días de observación se tomarán las cantidades de los servicios atendidos por un técnico y los que le han sido asignados a atender.

Fecha de inicio de observación: __/ __/ ___Hora de Inicio: _________ Técnico

Cantidad Cantidad Porcentaje Solicitudes Solicitudes Cumplimiento Asignadas Atendidas

Hora Final: _________Fecha de fin de observación: __/ __/ _____ Observaciones: _________________________________________________________________ _________________________________________________________________ ___________________________________________________________ Observador Revisado


Procesado

85

Archivado




ANEXO 04 Guía de Observación Nº 04 Porcentajes de Servicios no Atendidos. Instrucciones: En los días de observación se tomarán las cantidades de los servicios no atendidos y el total de las solicitudes de servicio. Fecha de inicio de observación: __/ __/ ___Hora de Inicio: _________ Día

Cantidad Solicitudes

Cantidad Solicitudes no Atendidas

Porcentaje Servicios no Atendidos



Procesado

86

Archivado




ANEXO 05 Guía de Observación Nº 05 Solicitudes de Servicio Asignadas por Técnico. Instrucciones: En los días de observación se tomarán las cantidades de las solicitudes de los servicios asignados a un técnico.

Fecha de inicio de observación: __/ __/ ___Hora de Inicio: _________ Cantidad Solicitudes Asignadas

Técnico



Procesado

87

Archivado




ANEXO 06 Guía de Observación Nº 06 Solicitudes de Servicio por Oficina. Instrucciones: En los días de observación se tomarán las cantidades de las solicitudes de los servicios de oficinas específicas. Fecha de inicio de observación: __/ __/ ___Hora de Inicio: _________ Cantidad Solicitudes Servicios

Oficina



Procesado

88

Archivado




ANEXO 07 Guía de Observación Nº 07 Número de Equipos Internados. Instrucciones: En los días de observación se tomarán las cantidades de las guías de salida de los equipos de otras dependencias que han sido atendidos en el taller de Soporte Técnico.

Fecha de inicio de observación: __/ __/ ___ Hora de Inicio: _________ Cantidad de Equipos de Otra Dependencia

Día



Procesado

89

Archivado




ANEXO 08 Guía de Observación Nº 08 Tiempo de Búsqueda de Historial Técnico. Instrucciones: En los días de observación se tomarán la fecha y hora de inicio de la búsqueda del historial técnico de un equipo y la hora de finalización de dicha búsqueda. Fecha de inicio de observación: __/ __/ ___Hora de Inicio: _________ Hora de Inicio

Número

Hora de Finalización

Tiempo Total (Min)



Procesado

90

Archivado




ANEXO 09 Guía de Observación Nº 09 Tiempo de Emisión de Documentos. Instrucciones: En los días de observación se tomarán la fecha y hora de inicio de la emisión de un documento (reportes, guías de salida y/o fichas técnicas) y la hora de finalización o entrega de dicho documento. Fecha de inicio de observación: __/ __/ ___Hora de Inicio: _________ Hora de Inicio

Número

Hora de Entrega

Tiempo Total (Min)



Procesado

91

Archivado




ANEXO 10 Cuestionario de Encuesta Nº 01 “Sistema de Control para las Tareas del Servicio de Soporte Técnico de la Oficina de Informática de la Municipalidad Provincial de Piura mediante una Aplicación Web” El presente cuestionario de encuesta será desarrollado como guía para obtener el grado de satisfacción del usuario de la aplicación web. _________________________________________________________________ Marque con un círculo o un aspa su repuesta elegida. 1) ¿Con la aplicación web implementada se ha mejorado su actividad de trabajo?

a. Nada b. Poco c. Medianamente d. Mucho

2) ¿La aplicación web implementada es fácil de manejar?

a.

Nada

b.

Poco

c.

Medianamente

d.

Mucho

3) ¿Con la aplicación web implementada la información está disponible de forma inmediata? Sistema de Control para las Tareas del Servicio de Soporte Técnico de la Oficina de Informática de la Municipalidad Provincial de Piura mediante una Aplicación Web

92





4) ¿La información que brindan los reportes de la aplicación web son de utilidad para los usuarios del sistema?



Nada



Poco



Medianamente



Mucho

5) ¿Está usted satisfecho con la aplicación web?


6) ¿La aplicación web implementada cumple con todos los requisitos solicitados?


93





7) ¿Cuál es su opinión general de la aplicación web?

Gracias por su participación

Este cuestionario de encuesta se mide de la siguiente forma:

Como para cada pregunta se presentan 4 opciones las cuales se asemejan (grado de medición), una vez resueltas estas encuestas por el personal de Soporte Técnico, se procederá al conteo de las letras para conocer cuál de ellas ha obtenido mayor puntaje.

Si la mayor cantidad de las letras son:

PUNTUACIÓN a Sistema de Control para las Tareas del Servicio de Soporte Técnico de la Oficina de Informática de la Municipalidad Provincial de Piura mediante una Aplicación Web

GRADO DE SATISFACCIÓN Quiere decir que el usuario se 94



b c d



encuentra Nada Satisfecho. Quiere decir que el usuario se encuentra Poco Satisfecho. Quiere decir que el usuario se encuentra Medianamente Satisfecho. Quiere decir que el usuario se encuentra Muy satisfecho.

95


Proyecto de Tesis - Aplicación Web Control Servicios Soporte Técnico

Recommend Documents