• No se han encontrado resultados

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

N/A
N/A
Protected

Academic year: 2021

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

Copied!
95
0
0

Texto completo

(1)

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

(2)

(2011)

ASESORES DE TESIS

ASESOR METODOLÓGICO:

___________________

Mg. Luis Velez Ubillus

ASESOR ESPECIALISTA:

____________________

(3)

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.

(4)

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.

(5)

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.

(6)

Í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

(7)

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

(8)

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:

(9)

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:

(10)

________________________________________________________

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.

(11)

 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:

(12)

¿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.

(13)

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.

(14)

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.

(15)

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.

(16)

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.

(17)

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

(18)

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

(19)

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

Política N° 01

Desarrollo Institucional

La Municipalidad Provincial de Piura es una corporación edil eficaz y eficiente que resuelve el 100 % de sus operaciones de manera moderna, ágil y dinámica.

Política N° 02 Desarrollo Social

La Municipalidad Provincial de Piura cuenta con una Red de Participación Ciudadana mediante la cual ha organizado el 100 % de Juntas Vecinales dentro de las jurisdicciones de su competencia.

(20)

cuenta con una Red de Desarrollo Social que contribuye, concerta y monitorea el 100 % de los servicios de educación, salud y trabajo.

Política N° 03

Desarrollo Económico y Financiero

La Municipalidad Provincial de Piura cuenta con un Sistema de Desarrollo Económico y Financiero que le permite incrementar sus recursos en un 5 % anual.

Política N° 04

Organización Territorial

La Municipalidad Provincial de Piura es la primera en el país que logra delimitar y 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:

(21)

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]

(22)

Gráfico N° 001: Organigrama de la Municipalidad Provincial de Piura Fuente: Municipalidad Provincial de Piura (MPP)

(23)

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.

(24)

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.

(25)

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

(26)

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.

(27)

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].

(28)

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.

(29)

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.

(30)

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

(31)

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:

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.

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

Servidor Web/Aplicación

(32)

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.

(33)

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

(34)

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.

(35)

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

(36)

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

(37)

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.

(38)

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.

(39)

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

(40)

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”.

(41)

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:

(42)

• 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.

(43)

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.

(44)

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:

(45)

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.

(46)

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.

Referencias

Documento similar