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

UNIVERSIDAD CSAR VALLEJO PIURA FACULTAD DE INGENIERA ESCUELA DE INGENIERA DE SISTEMAS Sistema de Control para las Tareas del
Servicio de Soporte Tcnico de la Oficina de Informtica de la Municipalidad Provincial de Piura mediante una Aplicacin Web
Proyecto de tesis Autor
Pino Chacn Jess Antonio Manuel
Asesor
Mg. Luis Velez Ubillus
Piura - Per
Universidad Csar Vallejo-Piura
Escuela Ingeniera Sistemas
(2011)
ASESORES DE TESIS
ASESOR METODOLGICO:
___________________
ASESOR ESPECIALISTA:
____________________
Ing. Noelia Saavedra Nizama
Sistema de Control para las Tareas del Servicio de Soporte Tcnico de la Oficina de Informtica de la Municipalidad Provincial de Piura mediante una Aplicacin Web
Jess Antonio Pino Chacn
INTRODUCCIN
El constante y permanente avance tecnolgico en el manejo de informacin con sistemas cada vez ms sofisticados debido al ambiente competitivo en que vivimos, todo esto tiene como consecuencia un notorio cambio para la Oficina de Informtica, redefiniendo sus objetivos y estrategias que le permitan cambiar la estructura de las vas de distribucin y redisear procesos para mejorar sus servicios, obtenindose la automatizacin de varios procesos del sistema de control para as minimizar las barreras del tiempo y distancia, facilitar el acceso a fuentes de informacin y potenciar el desarrollo de los servicios, adems 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 coordinacin de actividades. En la presente tesis, desarrollo e implementacin, se busca mejorar el sistema de control para las tareas del servicio de soporte tcnico, sumado al crecimiento de nuevas tcnicas, herramientas y filosofas orientadas a la optimizacin de los medios, teniendo como prioridad prevenir y reducir los riesgos suscitados en las tareas operativas y administrativas relacionadas con la conservacin y los servicios de mantenimiento que se brindan.
DEDICATORIA
El presente proyecto de investigacin se lo dedico a Dios y a mis padres por su comprensin y ayuda en todo momento. Mis padres me han enseado 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
AGRADECIMIENTO
Agradezco primeramente a Dios por haberme motivado para realizar el presente proyecto de tesis, agradezco tambin a mis padres por su apoyo incondicional y por estar siempre a mi lado, a mis maestros porque a travs de sus enseanzas lograron transmitirme sus conocimientos e inculcarme el deseo por la investigacin. El Autor
NDICE
N Pgina
INDICE DE GRAFICOS Y CUADROS

N Pgina
Cuadro N 001: Poltica Institucionales..........................................................................21 Grfico N 001: Organigrama de la Municipalidad Provincial de Piura......................23 Grfico N 002: Esquema general de un sistema..........................................................26 Grfico N 003: Esquema general de un sistema de control.......................................28 Grfico N 004: MVC de arquitectura Tipo 1 ..................................................................32 Grfico N 005: MVC de arquitectura Tipo 2 ..................................................................32 Grfico N 006: Gestin de Incidentes............................................................................40 Grfico N 007: Proceso de Gestin de Incidentes (resumen) ...................................41 Grfico N 008: Diagrama de Prioridades Del Incidente...............................................44 Grfico N 009: Proceso de Escalado de Incidentes.....................................................45 Grfico N 010: Procesos implicados en la Gestin de Incidentes.............................46 Grfico N 011: Interacciones y Funcionalidades de la Gestin de Problemas........47 Grfico N 012: Procesos Implicados en la Gestin de Problemas............................50 Grfico N 013: Control de Problemas............................................................................50 Grfico N 014: Control de Errores..................................................................................53 Grfico N 015: Metodologas de Desarrollo de Software............................................55 Grfico N 016: Dos Dimensiones de RUP.....................................................................57
Grfico N 017: Proceso Iterativo Incremental...............................................................59 Grfico N 018: Proceso FDD...........................................................................................64 Cuadro N 002: Indicadores de la Variable Dependiente..............................................67 Cuadro N 003: Indicadores, Tcnicas e Instrumentos de Recoleccin de Datos....74 Cuadro N 004: Cronograma de Actividades de la Tesis..............................................76 Cuadro N 005: Presupuesto de la Tesis........................................................................77
________________________________________________________
CAPITULO I: GENERALIDADES
________________________________________________________
1. GENERALIDADES DEL PROYECTO DE INVESTIGACION:

1.1. TTULO:
1.2. TIPO DE INVESTIGACIN:

EXPLICATIVA
1.3. REA DE INVESTIGACIN:

TECNOLOGICA
1.4. INSTITUCIN DONDE SE REALIZA LA INVESTIGACIN:

rea de Soporte Tcnico de la Municipalidad Provincial de Piura
1.5. AUTOR:
Jess Antonio Manuel Pino Chacn
1.6. ASESOR METODOLGICO:

1.7. ASESOR ESPECIALISTA:

Ing. Noelia Saavedra Nizama
1.8. DURACIN DEL PROYECTO DE INVESTIGACIN:

Inicio: Final: 29 de marzo del 2011 18 de diciembre del 2011
________________________________________________________
CAPITULO II: PLAN DE INVESTIGACION
________________________________________________________
2. PLAN DE LA INVESTIGACION:
2.1. DESCRIPCIN DE LA REALIDAD PROBLEMTICA:
El rea de Soporte Tcnico pertenece a la Oficina de Informtica y que a su vez esta pertenece a la Gerencia de Tecnologas y Sistemas de Informacin de la Municipalidad Provincial de Piura. Soporte Tcnico soluciona problemas de hardware, software, elctricos, electrnicos, telefnicos y de redes de la mayora de equipos que se encuentran en la municipalidad, se limita a estas actividades y no a proporcionar las polticas 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 Tcnico de la Oficina de Informtica 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 ms recursos se atienden de una manera inapropiada.
10
No se maneja informacin estadstica de los sucesos que acontecen en Soporte Tcnico. No existe un procedimiento adecuado de control y seguimiento en el rea de Soporte Tcnico, todo se hace manualmente. Soporte Tcnico no cuenta con un inventario propio. El rea de Soporte Tcnico 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 Informtica. El proceso de atenciones a los problemas que se presentan en las dependencias de la municipalidad es poco organizado. Se designa a Soporte Tcnico 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 tcnico es inadecuado. Los puntos de reposicin de Soporte Tcnico no estn definidos. La planificacin de tareas para el proceso del mantenimiento preventivo no es el adecuado. La planificacin 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 tcnico.
2.2. FORMULACIN DEL PROBLEMA: 2.2.1. Pregunta General:

11
Cmo influye una Aplicacin Web en el sistema de control de las tareas del servicio de Soporte Tcnico de la Oficina de Informtica de la Municipalidad Provincial de Piura?
2.2.2. Preguntas de Investigacin:

De qu manera influye una aplicacin web en la mejora de la organizacin y planificacin de tareas para el proceso del mantenimiento preventivo y correctivo? De qu manera influye una aplicacin web para que Soporte Tcnico cuente con un inventario propio para obtener y a la vez controlar una mayor cantidad de recursos? De qu manera influye una aplicacin web en la mejora del control y organizacin para los procesos de atenciones de problemas e incidentes? De qu manera influye una aplicacin web para que el rea de Soporte Tcnico tenga independencia para planificar operaciones y tareas administrativas y de mantenimiento?
2.2.3. Objetivo General:

Determinar cmo influye una Aplicacin Web en la mejora del Sistema de Control de las Tareas del Servicio de Soporte Tcnico de la Oficina de Informtica de la Municipalidad Provincial de Piura
2.2.4. Objetivos Especficos: Determinar de qu manera una Aplicacin Web mejora la

organizacin y la planificacin 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 Aplicacin Web permitir contar con

un inventario propio en Soporte Tcnico 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 Aplicacin Web incidir en la

optimizacin del control y la organizacin 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 Aplicacin Web permitir que el rea

de Soporte Tcnico tenga independencia para planificar operaciones y tareas administrativas y de mantenimiento.
2.3. JUSTIFICACIN E IMPORTANCIA DEL PROYECTO:

En vista de las necesidades del rea de Soporte Tcnico de la Municipalidad de Piura de llevar un mejor control en la atencin y solucin de problemas tcnicos 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 tambin un mejor manejo del Inventario que compete a la Oficina de Informtica ya que se podr saber que equipos son dados de baja y cules son los que hacen falta para tener un stock adecuado en nuestro inventario. Con este trabajo de investigacin se podr optimizar el tiempo horas hombre y se podrn atender una mayor cantidad de problemas que surjan en las diferentes oficinas de la Municipalidad de Piura y que en verdad necesiten la atencin de Soporte Tcnico dando soluciones rpidas y adecuadas a dichos problemas.
13
Justificacin Administrativa Este proyecto es una alternativa de solucin al problema de Control y Organizacin para el Mantenimiento de Equipos Informticos, cuyo desarrollo adems de fortalecer el logro ptimo de los objetivos institucionales, agiliza las actividades desarrolladas por el rea en la cual nuestra aplicacin web ser implementada. Justificacin Cientfica El trabajo es desarrollado en base al mtodo cientfico, que va desde la observacin del objeto de estudio hasta las conclusiones y recomendaciones. El producto final alcanzado, ser lo que justifique la investigacin. Justificacin Institucional Uno de los objetivos de la Municipalidad Provincial de Piura es mejorar la gestin administrativa y propiciar la descentralizacin de sus unidades y dependencias, mediante el uso de tecnologas de informacin. Para ello se implementar un nuevo sistema de informacin y/o control (aplicacin web) para satisfacer las necesidades del usuario y puedan desarrollar sus actividades eficientemente. Justificacin Social La implementacin del sistema de informacin y/o control (aplicacin web) mejorar la administracin de los recursos informticos para ofrecer servicios de calidad a la poblacin y en consecuencia mejorar la imagen institucional del Gobierno Regional de Piura. Justificacin Tecnolgica Como entes de investigacin y aprendizaje obtendremos nuevos conocimientos y experiencia como profesionales, mantenindonos a la vanguardia de los requerimientos de nuestro entorno y la adecuada capacitacin en cuanto a nuevas tecnologas de informacin se refiere. Puesto que una de las competencias exclusivas de la Municipalidad Provincial de Piura es promover la modernizacin, actualizacin e innovaciones tecnolgicas.
2.4. LIMITACIONES DEL PROYECTO:

El limitado acceso a informacin de los sistemas informticos que pueden servir de gua para el desarrollo de la presente investigacin.
14
El trabajo dinmico o poca disponibilidad del personal de Soporte Tcnico

limitar la informacin que se pueda obtener de ellos para el desarrollo de la presente aplicacin web. Los escasos recursos tecnolgicos que dispone el rea de soporte tcnico para el desarrollo del presente proyecto.
La aplicacin web a desarrollar ser independiente a la aplicacin web

institucional de la municipalidad.
La base de datos del sistema de inventario de la municipalidad de Piura

servir de gua y/o modelo para la base de datos de nuestro sistema de control (aplicacin web) para Soporte Tcnico.
2.5. MARCO REFERENCIAL CIENTIFICO: 2.5.1. Antecedentes: Antecedentes Locales:
Castro Arvalo, Manuel & Zapata Navarro, Jhon (Piura 2009), Sistema Informtico de Registro de Mantenimiento de Equipos de Cmputo del rea de Soporte del Centro de Informtica y Telecomunicaciones de la Universidad Nacional de Piura, presentan su tesis con la que obtuvieron los Ttulos Profesionales de Ingenieros de Sistemas en la Universidad Csar Vallejo Filial Piura. Castro & Zapata con este trabajo de investigacin buscan registrar cada uno de los mantenimientos que se les realiza a todos los equipos que llegan al rea de soporte y tambin buscan organizar y monitorear el inventario de todos los equipos de la Universidad Nacional de Piura.
15
Relacin: Esta tesis se toma en cuenta porque implementa un sistema informtico que se encarga de registrar datos detallados de los equipos de cmputo (inventario) y los mantenimientos que estos reciben, considerando tambin la respectiva organizacin y monitoreo, as como los beneficios que otorga. Salcedo Untiveros, Richard Orlando (Piura 2007), Anlisis, Diseo y Desarrollo del Mdulo Web para la Gestin y Control de Inventario de Bienes de la Oficina de Control Patrimonial de la Direccin Regional de Salud Piura, presenta su tesis con la que obtuvo el Ttulo Profesional de Ingeniero Informtico en la Universidad Nacional de Piura. Salcedo con este proyecto de tesis busca gestionar y controlar el inventario de bienes de la Direccin Regional de Salud Piura incluyendo los procesos de registro de bienes, verificacin del estado de los bienes, baja de bienes. Relacin: Esta tesis se toma en consideracin porque implementa un mdulo web que presenta entornos de trabajo correspondientes a cada rea de accin por usuario, relacionada con la gestin y control de inventario, as como las ventajas que este otorga.
Antecedentes Nacionales:
Vega Bustamante, Roco Olinda (Lima 2009), Anlisis, diseo e implementacin de un sistema de administracin de incidentes en atencin al cliente para una empresa de telecomunicaciones, presenta su tesis con la que obtuvo el Ttulo Profesional de Ingeniero Informtico en la Pontificia Universidad Catlica del Per. Vega con este proyecto de investigacin busca monitorear el tiempo de atencin de los casos que presente el cliente en una empresa de telecomunicaciones, de all que la presente tesis presenta el anlisis, desarrollo e implementacin de un sistema de administracin de incidentes en Atencin al Cliente para una empresa de telecomunicaciones. Relacin: Esta tesis se toma en consideracin porque implementa un sistema de administracin de incidentes que monitorea el tiempo de atencin de los casos que presente el cliente y de seguir la normativa establecida y las ventajas que esto otorga.
16
Santilln Pinedo, Karla & Tornero Mendoza, Ludver (Trujillo 2001), Sistema de Informacin de Control de Almacn de la Direccin Regional de Educacin de La Libertad DRELL, presentan su tesis con la que obtuvieron los Ttulos Profesionales de Ingenieros de Sistemas en la Universidad Csar Vallejo. Santilln & Tornero con este proyecto de tesis buscan mejorar la gestin del rea de almacn 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 trmites que se desarrollan, acceso directo y rpido a la informacin, distribucin gil y rpida de los artculos que piden los usuarios de la DRELL, monitoreo constante del stock de almacn, entre otros procesos mejorados que son propios de dicha rea. Relacin: Esta tesis se toma en cuenta porque implementa un sistema que centraliza la informacin de los equipos informticos, para un mejor control de almacn con los respectivos procesos que se llevan a cabo, para finalmente con la informacin brindada sirva de apoyo para nuevas adquisiciones.
Antecedentes Internacionales:
Pesntez Huerta, lvaro Eduardo (Guayaquil, Ecuador 2007), Elaboracin de un Plan de Mantenimiento Predictivo y Preventivo en Funcin de la Criticidad de los Equipos del Proceso Productivo de una Empresa Empacadora de Camarn, presenta su tesis con la que obtuvo el Ttulo Profesional de Ingeniero Industrial en la Escuela Superior Politcnica del Litoral. Pesantez con este trabajo de investigacin 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 tcnicos internos y/o externos de la empresa; as como tambin el detalle de cada equipo y cules sern las frecuencias de los diversos mantenimientos preventivos establecidos. Relacin: Esta tesis se toma en consideracin porque implementa un plan de mantenimiento predictivo y preventivo enfocado a brindar una gua confiable de los tipos y frecuencias de mantenimiento para los equipos, esta
17
gua servir como modelo para desarrollar los mdulos webs de mantenimiento predictivo, preventivo y correctivo de la aplicacin web a desarrollar. Espinoza Saavedra, Daniel (Valparaso, Chile 2004), Estudio del Sistema de Monitoreo y Registro de Inventarios de Compras y su Integracin Estratgica mediante el Control de Gestin, presenta su tesis con la que obtuvo el Grado de Magster en Gestin mencin Control en la Universidad de Valparaso. Espinoza con este proyecto de investigacin busca presentar las posibilidades que ofrece un modelo de control dentro de un sistema de inventarios de compras mediante la aplicacin de los conceptos constructivos de un cuadro de mando. Relacin: Esta tesis se toma en cuenta porque nos proporciona informacin importante sobre las posibilidades y riesgos de implementar un control de gestin en un inventario de compras y los beneficios que este otorga.
2.6. MARCO TEORICO: 2.6.1. MUNICIPALIDAD PROVINCIAL DE PIURA:

Misin, Visin y Objetivos de la Institucin: Misin Gobernar, conducir y liderar el desarrollo de la provincia, gestionando y promoviendo el desarrollo sostenible, integral y el bienestar humano, mediante acciones de concertacin institucional y de participacin de la sociedad civil organizada. [PEI MPP] Visin La Municipalidad Provincial de Piura al 2014, aplica una gestin moderna, eficiente y participativa, con creciente igualdad de oportunidades, sistema distrital democrtico, 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-econmico integral, sostenible y armnico, priorizando y planificando las necesidades del distrito y provincia de Piura. 2) Promover el bienestar del ciudadano con la adecuada prestacin de los servicios pblicos locales que satisfagan sus necesidades vitales de salubridad, vivienda, abastecimiento, seguridad, cultura, recreacin, transporte y comunicaciones. 3) Representar poltica y organizacionalmente a los vecinos en el Gobierno Local, mediante programas de participacin comunal y el ejercicio del derecho de peticin. 4) El Ejercicio de la Funcin Conciliadora. 5) Desarrollar programas sociales bsicos. 6) Promover el desarrollo econmico local mediante el impulso a las pequeas y micro empresas (PYMES), de acuerdo a las normas y polticas regionales y nacionales. 7) Brindar la infraestructura, apoyo, asesoramiento a los promotores y agentes del desarrollo econmico, facilitndoles el espacio fsico para sus actividades de acuerdo a la normatividad vigente. [ROF MPP] Polticas Generales de la Institucin: OBJETIVOS ESTRATEGICOS LINEAS POLITICAS OBJETIVO META La Municipalidad Provincial de Piura es Poltica N 01 Desarrollo Institucional una corporacin edil eficaz y eficiente que resuelve el 100 % de sus operaciones de manera moderna, gil y dinmica. La Municipalidad Provincial de Piura cuenta con una Red de Participacin Ciudadana Poltica N 02 Desarrollo Social dentro de mediante las la cual de ha su organizado el 100 % de Juntas Vecinales jurisdicciones competencia. La Municipalidad Provincial de Piura
19 Jess Antonio Pino Chacn
cuenta con una Red de Desarrollo Social que contribuye, concerta y monitorea el 100 % de los servicios de educacin, salud y trabajo. La Municipalidad Provincial de Piura Poltica N 03 Desarrollo Econmico y Financiero cuenta con un Sistema de Desarrollo Econmico y Financiero que le permite incrementar sus recursos en un 5 % anual. La Municipalidad Provincial de Piura es la Poltica N 04 Organizacin Territorial primera en el pas que logra delimitar y adecuar integralmente el 100 % de su territorio. Cuadro N 001: Poltica Institucionales Fuente: PEI MPP Actividades Principales de la Institucin: 1) Planificar integralmente el desarrollo local y el ordenamiento territorial, en el nivel provincial. 2) Promover permanentemente la coordinacin estratgica de los planes integrales de desarrollo de los distritos. Los planes referidos a la organizacin del espacio fsico y uso del suelo que emitan las municipalidades distritales debern sujetarse a los planes y las normas generales de la Municipalidad Provincial de Piura. 3) Promover, apoyar y ejecutar proyectos de inversin y servicios pblicos municipales que presenten objetivamente externalidades o economas de escala de mbito provincial; para cuyo efecto suscribir convenios con las respectivas municipalidades distritales. 4) Emitir las normas tcnicas generales, en materia de organizacin del espacio fsico y uso del suelo, as como sobre proteccin y conservacin del medio ambiente. 5) Proponer proyectos de ley, a travs de iniciativas legislativas. [ROF MPP] Organigrama de la Institucin:
20
Toda empresa cuenta en forma implcita o explcita con cierto juego de jerarquas 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 jerarquizacin y divisin de las funciones componentes de ella. Jerarquizar es establecer lneas de autoridad (de arriba hacia abajo) a travs de los diversos niveles y delimitar la responsabilidad de cada empleado ante solo un supervisor inmediato. Esto permite ubicar a las unidades administrativas en relacin con las que le son subordinadas en el proceso de la autoridad. El valor de una jerarqua bien definida consiste en que reduce la confusin 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
Grfico N 001: Organigrama de la Municipalidad Provincial de Piura Fuente: Municipalidad Provincial de Piura (MPP)
22
2.6.2. OFICINA DE INFORMATICA:

Misin, Visin, Objetivos y Metas de la Oficina de Informtica: Misin Promover el desarrollo y la utilizacin de un sistema de informacin moderno de acuerdo a las necesidades de los diferentes usuarios, proporcionando datos oportunos y de calidad en lo relativo a prevencin, atencin y control de los problemas informticos, elctricos y electrnicos contribuyendo a la mejora de la calidad de servicio de las diferentes dependencias de la Municipalidad Provincial de Piura. [ROF MPP] Visin Contar con la confianza y satisfaccin de nuestros Usuarios a travs de un sistema que proporcione informacin y servicios oportunos, seguros, y de calidad, brindando a sus necesidades respuestas integrales, rpidas y efectivas a travs de un equipo multidisciplinario con calidad humana, tcnica y profesional. [ROF MPP] Objetivos 1) Optimizar las necesidades de automatizacin de procesos. 2) Optimizar las necesidades de informacin de los usuarios finales. 3) Desarrollar los sistemas informticos, cuidando que cumplan con la ergonoma de interfase usuario mquina y los niveles de seguridad requeridos. 4) Implementar los sistemas informticos conjuntamente con los usuarios. 5) Mejorar el mantenimiento de los sistemas de informticos, 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 implementacin de los sistemas informticos. 7) Mejorar la administracin de los recursos humanos y equipos asignados a esta oficina. 8) Supervisar y emitir normas de uso y estandarizacin para el correcto funcionamiento y utilizacin de los equipos por parte de los usuarios. 9) Brindar el mantenimiento preventivo y correctivo de la infraestructura de red y de los equipos informticos. 10) Generar planes de mantenimiento y observar su cumplimiento. 11) Mejorar la administracin de la base de datos.
23
12) Implementar la infraestructura de telecomunicaciones para el ptimo funcionamiento de los sistemas informticos. [ROF MPP] Metas 1) Facilitar el desarrollo de la Corporacin Municipal mediante la implementacin de un Sistema de Comunicaciones y Tecnologas de Informacin durante el presente ao 2011 con un presupuesto de 30316.93 nuevos soles. 2) Gestionar y resolver el desarrollo de los medios eficientes de comunicacin simultnea entre las Juntas Vecinales y la Corporacin Municipal durante el presente ao 2011 con un presupuesto de 9603.50 nuevos soles. 3) Proporcionar las herramientas tecnolgicas que permitan una adecuada comunicacin y acceso a la informacin estadstica y difusin de convocatorias y logros de la Corporacin Municipal durante el presente ao 2011 con un presupuesto de 1240.50 nuevos soles. 4) Gestionar, programar, promover y resolver la implementacin del gobierno electrnico y adecuar el resultado progresivo de la organizacin territorial durante le presente ao 2011 con un presupuesto de 396.20 nuevos soles. 5) Disear procedimientos que simplifiquen mecanismos administrativos durante el presente ao 2011 con un presupuesto de 18441.61 nuevos soles. [POI MPP]
2.6.3. SOPORTE TECNICO:

Descripcin del rea de Negocio: El rea de Negocio es Soporte Tcnico, pertenece a la Oficina de Informtica y a su vez esta oficina pertenece a la Gerencia de Tecnologas y Sistemas de Informacin, se encarga de dar respaldo a los equipos electrnicos y elctricos que se encuentran dentro de la Municipalidad de Piura y en sus Unidades Orgnicas Externas. Soporte Tcnico, alberga equipos, materiales, herramientas y repuestos para que los usuarios o trabajadores de la Municipalidad de Piura soliciten servicios de atencin para solucionar problemas de hardware y software de los equipos electrnicos e informticos, problemas de equipos elctricos y problemas de equipos telefnicos.
24
Soporte Tcnico soluciona problemas de hardware, software, elctricos, electrnicos, telefnicos y de redes de la mayora de equipos que se encuentran en la municipalidad, se limita a estas actividades y no a administrar las polticas de seguridad y privacidad de la red de trabajo o dominio. Dada la diversidad de incidentes y solicitudes que pueden producirse en ST resultan difciles que las atenciones sean de manera oportuna dado que muchas veces estos problemas pueden ser solucionados de manera fcil por el usuario o trabajador de la municipalidad de Piura. [EL AUTOR]
2.6.4. SISTEMA DE CONTROL:

QU ES UN SISTEMA DE CONTROL? Segn Alvarez Brotons (2004): Un sistema dinmico 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 ningn tipo de control. El grfico 2 ilustra de un modo conceptual el funcionamiento de un sistema.
Grfico 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 manipulacin 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, segn un criterio preestablecido. Normalmente este criterio consiste en que la accin de control sobre las variables de entrada sea realizable, evitando comportamientos bruscos e irreales. 3. Ser fcilmente implementable y cmodo de operar en tiempo real con ayuda de un ordenador. Los elementos bsicos que forman parte de un sistema de control y permiten su manipulacin 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 accin que debe aplicarse para modificar las variables de control en base a cierta estrategia. - Actuador. Es el mecanismo que ejecuta la accin calculada por el controlador y que modifica las variables de control. El grfico 3 ilustra el esquema de funcionamiento de un sistema de control genrico.
26
Grfico N 003: Esquema general de un sistema de control Fuente: Alvarez Brotons
2.6.5. APLICACIN WEB:

En este inciso se darn a conocer algunos conceptos bsicos del contexto de este trabajo, con la finalidad de situar al problema dentro de un conjunto de conocimientos. Dentro de estos conocimientos se darn algunos conceptos acerca de patrones de diseo, dentro de ellos el patrn MVC, sus partes y caractersticas, despus se hablar acerca de los frameworks, un breve comparativo entre estos y los patrones de diseo y finalmente se hace un pequeo y breve anlisis de algunos otros frameworks para web existentes. Patrones de diseo Definicin e historia
Para comenzar es importante definir lo que un patrn de diseo es, aunque existen varias definiciones al respecto, un patrn de diseo es una solucin de calidad para un problema recurrente de diseo. Pero no son aplicables nicamente en el campo computacional, tambin existen patrones para varias actividades de la vida cotidiana, aunque con algunas diferencias pero tienen el mismo propsito 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].
27
Hay patrones que abarcan las distintas etapas del desarrollo; desde el anlisis hasta el diseo y desde la arquitectura hasta la implementacin. En el caso de los patrones computacionales un software estructurado, modulado posee una mejor calidad y es ms sencillo corregir errores, implementar mejoras y actualizaciones, ya que un software que posee algn patrn de diseo es ms sencillo de modificar que un software que no posee en absoluto un patrn. Pero Cmo se debe escoger el patrn adecuado?, esta es una pregunta un poco difcil de responder ya que la mayora de las actividades de desarrollo o produccin no se ajustan perfectamente a un patrn definido, por eso es importante llevar acabo un anlisis para poder visualizar cual ser el patrn que mejor se ajuste a las necesidades de desarrollo. En s "un patrn de diseo puede verse como una plantilla que puede ser aplicada en muchas situaciones diferentes" [Gamma, 1995], para dar una buena solucin. Los patrones se descubren como una forma indispensable de enfrentarse a la programacin a raz 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 diseo 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 diseo sino que cubran todo los que se entiende por ingeniera del software (desde el anlisis hasta la implementacin) [Gamma, 1995]. Elementos esenciales
En general un patrn tiene cuatro elementos esenciales: El nombre del patrn: que se utiliza para describir un problema de diseo, sus soluciones y sus consecuencias, en una palabra o dos. Este nombre ayuda a que sea ms sencillo de identificarlo, al hablar o escribir de l e incluso puede dar una idea general o una descripcin de dicho patrn. El problema: describe cuando aplicar el patrn, tambin puede incluir detalles especficos que se deben cumplir o problemas un poco ms detallados, los cuales en conjunto engloban el problema central a solucionar.
28
La solucin: describe los elementos que forman el diseo, sus relaciones, sus responsabilidades y sus colaboraciones. La solucin no describe un diseo o implementacin en particular ya que un patrn de diseo puede verse como una plantilla que se aplica a un problema especfico. Las consecuencias: son los resultados y desventajas de haber aplicado el patrn. Estas consecuencias implican un impacto en las caractersticas del sistema como: flexibilidad, portabilidad y extensin. Adems de que ayudan a medir el desempeo del sistema. Clasificacin
El grupo de GoF clasific los patrones en 3 grandes categoras basadas en su propsito: 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 instanciacin y ocultar los detalles de cmo 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 comunicacin e iteracin entre los objetos de un sistema. El propsito de este patrn es reducir el acoplamiento entre los objetos. Patrn de diseo Model View Controller (MVC) Una vez establecidas las bases de los patrones de diseo, se puede ya comenzar a hablar ms del patrn que se utiliz durante este trabajo: el patrn MVC. Estas son las siglas de Model View Controller, en espaol Modelo Vista Controlador. Esto tambin se ve reflejado en que cada una de estas palabras representa cada uno de los 3 componentes del patrn MVC. Cada parte juega un rol fundamental para la completa integracin del sistema.
29
Definicin e historia
"El propsito de este patrn es simplificar la implementacin de aplicaciones de acuerdo a las peticiones de los usuarios y los datos a desplegar" [Harrop, 2005]. La definicin un poco ms formal sera: MVC es un patrn de diseo de software que separa los datos de una aplicacin, la interfaz de usuario, y la lgica 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 mnimo impacto en el componente del modelo de datos o en los otros componentes del sistema. Este patrn cumple perfectamente el cometido de modularizar un sistema. El patrn MVC fue descrito por primera vez en 1979 por Trygve Reenskaug, quin trabajaba en Smalltalk en los laboratorios de investigacin de la Xerox. Este patrn se ve frecuentemente utilizado en aplicaciones web, donde la vista es la pgina HTML y el cdigo provee de datos dinmicos a la pgina. Las aplicaciones web complejas continan siendo ms difciles de disear que las aplicaciones tradicionales de escritorio, el patrn MVC se presenta como una solucin para ayudar a disminuir dicha complejidad. Componentes
Los 3 principales componentes del patrn 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 pgina web (HTML o JSP) que el navegador pueda desplegar. En s el propsito de la vista es convertir los datos para que al usuario le sean significativos y los pueda interpretar fcilmente. La vista no debe trabajar directamente con los parmetros del request, debe delegar esta responsabilidad al controlador. Controlador: es la parte lgica que es responsable del procesamiento y comportamiento de acuerdo a las peticiones (requests) del usuario, construyendo
30
un modelo apropiado, y pasndolo a la vista para su correcta visualizacin. En el caso de una aplicacin web Java en la mayora de los casos el controlador es implementado por un servlet. Tipos de patrones MVC
Actualmente existen dos tipos de patrn MVC: Servidor Web/Aplicacin
Grfico N 004: MVC de arquitectura Tipo 1 Fuente: Walls, 2005 Como se muestra en el Grfico 4 en el Tipo 1 de MVC las pginas JSP estn en el centro de la aplicacin, y contienen tanto la lgica de control como la de presentacin. Este tipo de arquitectura funciona de la siguiente manera: el cliente hace una peticin a una pgina JSP; se construye la lgica de la pgina, generalmente en objetos Java o como se les conoce en Ingls Plain Old Java Objects (POJOs) y se transforma el modelo para ser desplegado una vez ms. Servidor Web/Aplicacin
Grfico N 005: MVC de arquitectura Tipo 2 Fuente: Walls, 2005
31
En el modelo de Tipo 2 de MVC, que se aprecia en el Grfico 5, se puede observar que ya existe una clara separacin entre el controlador y la vista, ya que ahora es directamente el controlador quien recibe la peticin, 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 ms complejas, ya que para una aplicacin sencilla puede utilizarse el Tipo 1. La tecnologa JSP no es la nica que se puede emplear para las vistas, existen otro tipo de tecnologas que pueden servir como vistas. Frameworks Un framework es un trmino utilizado en la computacin en general, para referirse a un conjunto de bibliotecas, utilizadas para implementar la estructura estndar de una aplicacin. Todo esto se realiza con el propsito de promover la reutilizacin de cdigo, con el fin de ahorrarle trabajo al desarrollador al no tener que rescribir ese cdigo para cada nueva aplicacin que desee crear. Existen diferentes frameworks para diferentes propsitos, algunos orientados al desarrollo de aplicaciones web, otros para desarrollar aplicaciones multiplataforma, para un sistema operativo o lenguaje de programacin en especfico, entre otros. Segn Gamma, el framework determina la arquitectura de una aplicacin [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 colaboracin entre dichas clases y objetos. Todos estos parmetros son definidos por el framework, evitando que el usuario tenga que definirlos y se pueda enfocar en cosas especficas de su aplicacin. "El framework captura las decisiones de diseo que son comunes a su dominio de aplicacin" [Gamma, 1995]. Un framework no slo promueve la reutilizacin de cdigo sino tambin la reutilizacin de diseo. Un framework ayuda a que se desarrolle una aplicacin de una manera ms rpida, ya que se no pierde tiempo en algunos detalles de diseo que muchas veces quitan ms tiempo del que tomo construir en s la lgica de la aplicacin. Adems las aplicaciones que se construyen tienen estructuras similares, son ms fciles de mantener y consistentes para los usuarios. Pero esto tiene como consecuencia una mnima perdida de libertad en las cuestiones de diseo.
32
En algunas ocasiones un desarrollador tiene algunas dificultades para disear una aplicacin, esto todava es ms difcil 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 estndar, lo cual puede ser el xito o el fracaso del mismo, por eso se intenta crear frameworks lo ms extensibles y flexibles posibles, para que con algunos cambios mnimos 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 aplicacin, dependiendo de que tan drstico sea el cambio.
Relacin entre patrones de diseo y frameworks
Los frameworks utilizan un variado nmero de patrones de diseo, ya que as logran soportar aplicaciones de ms alto nivel y que reutilizan una mayor cantidad de cdigo, que uno que no utiliza dichos patrones. "Los patrones ayudan a hacer la arquitectura de los frameworks ms adecuada para muchas y diferentes aplicaciones sin necesidad de rediseo" [Gamma, 1995]. Por esta razn es importante que se documenten que patrones utiliza el framework para que los que se encuentren familiarizados con dichos patrones puedan tener una mejor visin y poder adentrarse en el framework ms fcilmente. Aunque muchas personas cometen el error de confundir a los frameworks con los patrones de diseo, segn los cuatro autores del libro "Design Patterns - Elements of Reusable" existen 3 diferencias fundamentales entre ellos [Gamma, 1995]: Los patrones de diseo son ms abstractos que los frameworks: el cdigo del framework se escribe una vez, en cambio cada vez que se requiere un patrn de diseo se debe de codificar con respecto a la aplicacin. Una fortaleza de los frameworks es que pueden ser escritos en un lenguaje de programacin, pueden ser reutilizados e incluso ejecutados, esto tambin podra considerarse una debilidad dependiendo del punto de vista (siempre y cuando no sean multiplataforma o se encuentre en diferentes versiones por lenguaje de
33
programacin), ya que estn enfocados a un slo lenguaje de programacin, en cambio un patrn de diseo puede ser aplicado a cualquier lenguaje de programacin, pero se tiene que reescribir desde cero. Los patrones de diseo son elementos arquitectnicos ms pequeos que los frameworks: un solo framework contiene varios patrones de diseo, pero jams es al contrario. Los patrones de diseo son menos especializados que los frameworks: existen frameworks con un dominio especfico, adems los patrones son un poco ms generales debido a que pueden ser utilizados en un mayor nmero de aplicaciones de varios tipos.
Frameworks para aplicaciones web

Actualmente existen algunos frameworks para desarrollar aplicaciones web, que es de las ramas ms importantes en las que se usan los frameworks. La mayora de ellos utilizan el patrn de diseo MVC del cual se habl previamente. Todos los frameworks tienen caractersticas especiales que los hacen nicos para sobresalir y poder seguir en el mercado, adems de poseer las siguientes caractersticas comunes [Johnson, 2003]: Utilizan un solo servlet que tiene la funcin de controlador, para toda la aplicacin 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 configuracin, generalmente escrita en un archivo XML, en donde se le indicar al servlet controlador, a travs de propiedades, a quien delegar la responsabilidad de atender la peticin entrante. Algunas veces esas propiedades estn 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 relacin con el nombre del archivo de la vista. El framework se encarga de realizar dicha conversin para poder obtener el nombre de la vista que se tiene que cargar para que sea desplegada. La implementacin de una vista con un nombre en particular puede cambiar sin afectar cdigo del controlador.
34
Cuando se va a desarrollar una aplicacin web, el desarrollador se debe fijar en si desea realizar una aplicacin extremadamente sencilla o si quiere desarrollar una verdadera aplicacin web, que tendr actualizaciones, correcciones y mejoras a futuro. Para esto es recomendable que se elija un framework de aplicacin web que utilice el patrn web MVC. Con el fin de que se pueda hacer la separacin entre los 3 elementos principales y pueda aprovechar todas las ventajas que brinda este patrn de diseo. Para poder aprovechar tambin las ventajas adicionales que brinda el framework para la integracin con otras herramientas u otros servicios. A continuacin se enlistan algunos de los frameworks para aplicaciones web ms populares: Struts, WebWork, Maverick y Spring, el framework sobre el cual se basa esta tesis, ser analizado con mayor detalle ms adelante en este documento. Este listado y anlisis sencillo de cada uno de estos frameworks se da con la razn de poder saber cuales son los frameworks contra los que compite Spring, dentro del mismo mbito, as como sus caractersticas principales, ventajas y desventajas. Struts
Struts es uno de los frameworks MVC ms 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 ao 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 accin. Struts es open source, por lo que no requiere licencia para su uso [Johnson, 2003]. Adems cumple una de las funcionalidades bsicas que se mencionaron acerca de los frameworks para aplicaciones web, ya que implementa un solo controlador (ActionServlet) que evala las peticiones del usuario mediante un archivo configurable (struts-config.xml) para poder dirigirlas a un action que procesa el request. El lenguaje de programacin que utiliza es Java, as como Java Beans como modelo. Algunas de las ventajas que Struts brinda son: que existe un variado nmero de trabajos y proyectos ya hechos lo que brinda un mayor nmero de ejemplos para
35
poder tomar un punto de partida y de referencia; otra ventaja es que brinda libreras de tags para HTML bastante tiles. Entre las desventajas de framework se puede observar que muchas veces puede ser difcil trabajar con los ActionForms, adems de que el proyecto posiblemente desaparezca en los aos venideros, otra de las desventajas de Struts es que muy ligado con la tecnologa JSP, por lo que muchas veces se dificulta integrarlo con alguna otra tecnologa para las vistas. Maverick
Este es otro framework MVC open source que existe en el mercado, pero a diferencia de los dems este no cuenta con sus propias libreras de tags. Sin embargo cumple con las funcionalidades tpicas 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 aplicacin web (web.xml). Maverick cuenta con un archivo XML en el que se guarda toda la configuracin del mismo (maverick.xml). Una caracterstica de Maverick es que nicamente acepta un solo controlador central y un archivo de configuracin por aplicacin web, lo que muchas veces al desarrollar aplicaciones ms grandes y complejas se puede volver confuso y difcil de configurar. [Johnson, 2003] Maverick es un framework mucho ms configurable que Struts, lo que brinda cierta flexibilidad, tambin incluye varias clases para poder extender y cambiar el flujo del trabajo o workflow en Ingls. 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 caracterstica interesante de Maverick es el bsico y fcil uso de la funcionalidad del dispatcher. Tambin es multiplataforma ya que ha sido adaptado para los lenguajes .NET y PHP. WebWork
Este es un framework ms reciente ya que fue lanzado a mediados del ao 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
36
nombre, no es puramente un framework para aplicaciones web. Adopta un acercamiento prctico que minimiza la dependencia del cdigo de la aplicacin de los conceptos web."[Johnson, 2003]. El framework WebWork est basado en el patrn de diseo de Comandos o CommandPattern. Cada accin es un comando, que es creado para manejar un request, sus propiedades son puestas de manera transparente, ya que cada accin es un Java Bean. WebWork cuenta, al igual que Struts y Spring con su propia librera de tags para JSP, las cuales ayudan a realizar distintas tareas de una manera ms gil, pero no es la nica tecnologa para vista que soporta, tambin incluye soporte para Velocity. Una de las ventajas de WebWork es que cuenta con una arquitectura simple y las clases son fciles de extender. Pero como todo, tiene sus desventajas, la creacin de una accin (action) por cada request puede llegar a ser algo confuso cuando no se tiene muchos datos en el request; impone el patrn de diseo Command en cada interaccin del usuario, ya sea bueno o malo utilizarlo en dicha interaccin; es difcil saber de que tipo son las excepciones que se lanzan. Como este framework es relativamente reciente no existe mucha documentacin y ejemplos al respecto lo que puede resultar a veces frustrante cuando se requiere buscar algn ejemplo o tutorial que pueda servir. Spring
Es un framework de aplicacin, que a diferencia de otros single-tier como Struts, Spring propone estructurar toda una aplicacin 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 solucin para poder disfrutar de los beneficios clave de J2EE, mientras que minimiza la complejidad encontrada en el cdigo de la aplicacin. [Johnson, 2005] Spring esta basado en la filosofa de que un framework debe proveer una gua hacia una buena prctica, es decir debe hacer la cosa correcta sencilla de hacer. Mezclando la correcta combinacin de flexibilidad y restriccin, la cual es la clave en el buen diseo de un framework.
37
Spring tambin cuenta con algunas de las caractersticas generales de los frameworks web, ya que cuenta con un mdulo para poder desarrollar aplicaciones web de manera sencilla, utilizando el patrn de diseo MVC antes mencionado. Contando con un controlador central (DispatcherServlet), adems de la capacidad de tener varios controladores secundarios para el procesamiento de cada una de las peticiones. Tambin se basa en el diseo de las clases extendiendo o implementando interfaces, lo cual es un mejor diseo orientado a objetos, ya que promueve la reutilizacin de cdigo. Adems Spring cuenta con algunos tags para las diferentes tecnologas para vista que existen. Las cuales tienen funciones diferentes como vincular formularios, validacin, despliegue de informacin, 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 mdulos de manera independiente. Cada uno esta enfocado en una tarea especfica, y algunos de ellos son para la integracin con alguna herramienta o incluso cuenta con la posibilidad de integrase con los otros frameworks mencionados anteriormente. Esto con el propsito de proponer la filosofa 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 desempeo y poder sacar as un mejor resultado y una aplicacin de mayor calidad. En conclusin cada framework tiene sus ventajas y desventajas, escoger uno es una decisin del desarrollador, dependiendo de sus necesidades y requerimientos, del tamao del proyecto a desarrollar, as como de su experiencia con tecnologas existentes que se integren fcilmente con el framework que haya elegido. Esto con el fin de aprovechar algunas tecnologas que estn enfocadas en un rea especfica, para que brinde una mejor y ms sencilla forma de llevar a cabo la tarea. Esta fue una de las razones por la cual se decidi incursar dentro de las caractersticas de Spring, y despus de un anlisis se llego a la conclusin de que es un buen framework que cumple con la mayora de las caractersticas, de las cuales otros frameworks escasean.
38
Una de las cuestiones que ha hecho a Spring evolucionar de manera muy rpida en tan poco tiempo, es que se han incrementando de una manera increble el nmero de proyectos que utilizan esta herramienta a travs del ltimo ao. Esto conlleva a que la cantidad de personas interesadas en este framework aumente, as como el soporte, el nmero de foros de opinin y la publicacin de un mayor nmero de libros y tutoriales.
2.6.6. GESTIN DE INCIDENTES:

Segn OSIATIS S.A. V2.0: Visin General La Gestin de Incidentes tiene como objetivo resolver cualquier incidente que cause una interrupcin en el servicio de la manera ms rpida y eficaz posible. La Gestin de Incidentes no debe confundirse con la Gestin 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 interrelacin entre ambas. Las propiedades y funcionalidades de la Gestin de Incidentes se resumen sucintamente en el siguiente grfico:
Grfico N 006: Gestin de Incidentes Fuente: OSIATIS S.A. V2.0

39
Introduccin y Objetivos Los objetivos principales de la Gestin de Incidentes son:
Detectar cualquiera alteracin en los servicios TI (Tecnologas de Informacin). Registrar y clasificar estas alteraciones. Asignar el personal encargado de restaurar el servicio segn 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 gestin de incidentes:
Grfico N 007: Proceso de Gestin 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 segn el libro de Soporte del Servicio de ITIL (Bibliotecas de Infraestructura de las Tecnologas de Informacin) un incidente es: Cualquier evento que no forma parte de la operacin estndar de un servicio y que causa, o puede causar, una interrupcin o una reduccin 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 concesin de nuevas licencias, cambio de informacin de acceso, etc. siempre que estos servicios se consideren estndar. Cualquier cambio que requiera una modificacin de la infraestructura no se considera un servicio estndar y requiere el inicio de una Peticin de Cambio (RFC) que debe ser tratada segn los principios de la Gestin de Cambios. Los principales beneficios de una correcta Gestin 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 monitorizacin del servicio. Optimizacin de los recursos disponibles. Una CMDB (Base de Datos de la Gestin de Configuraciones) ms precisa pues se registran los incidentes en relacin con los elementos de configuracin. Y principalmente: mejora la satisfaccin general de clientes y usuarios.
Por otro lado una incorrecta Gestin de Incidentes puede acarrear efectos adversos tales como: Reduccin de los niveles de servicio. Se dilapidan valiosos recursos: demasiada gente o gente del nivel inadecuado incidente. Se pierde valiosa informacin 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 gestin de sus incidentes. Las principales dificultades a la hora de implementar la Gestin de Incidentes se resumen en: trabajando concurrentemente en la resolucin del
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 operacin de los protocolos de clasificacin y escalado.
No estn bien definidos los niveles de calidad de servicio ni los productos soportados. Lo que puede provocar que se procesen peticiones que no se incluan en los servicios previamente acordados con el cliente.
Clasificacin del Incidente Es moneda frecuente que existan mltiples incidencias concurrentes por lo que es necesario determinar un nivel de prioridad para la resolucin de las mismas. El nivel de prioridad se basa esencialmente en dos parmetros:
Impacto: determina la importancia del incidente dependiendo de cmo ste afecta a los procesos de negocio y/o del nmero de usuarios afectados.
Urgencia: depende del tiempo mximo de demora que acepte el cliente para la resolucin del incidente y/o el nivel de servicio acordado en el SLA.
Tambin se deben tener en cuenta factores auxiliares tales como el tiempo de resolucin esperado y los recursos necesarios: los incidentes sencillos se tramitarn cuanto antes. Dependiendo de la prioridad se asignarn los recursos necesarios para la resolucin 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 funcin de la urgencia e impacto del incidente:
Grfico 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 algn superior que pueda tomar decisiones que se escapan de su responsabilidad. A este proceso se le denomina escalado. Bsicamente hay dos tipos diferentes de escalado:
Escalado funcional: Se requiere el apoyo de un especialista de ms alto nivel para resolver el problema. Escalado jerrquico: 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 ms recursos para la resolucin de un incidente especfico.
43
El proceso de escalado puede resumirse grficamente* como sigue:
* El escalado puede incluir ms niveles en grandes organizaciones, o por el contrario, integrar diferentes niveles en el caso de PYMES
Grfico N 009: Proceso de Escalado de Incidentes Fuente: OSIATIS S.A. V2.0 Proceso El siguiente diagrama muestra los procesos implicados en la correcta Gestin de Incidentes:
44
Grfico N 010: Procesos implicados en la Gestin de Incidentes Fuente: OSIATIS S.A. V2.0
2.6.7. GESTIN DE PROBLEMAS:

Segn OSIATIS S.A. V2.0:
Visin General Las funciones principales de la Gestin de Problemas son: o o o o Investigar las causas subyacentes a toda alteracin, real o potencial, del servicio TI. Determinar posibles soluciones a las mismas. Proponer las peticiones de cambio (RFC) necesarias para restablecer la calidad del servicio. Realizar Revisiones Post Implementacin (PIR) para asegurar que los cambios han surtido los efectos buscados sin crear problemas de carcter secundario. La Gestin 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 configuracin con el objetivo de prevenir incidentes incluso antes de que estos ocurran. Las interacciones y funcionalidades de la Gestin de Problemas se resumen sucintamente en el siguiente grfico:
Grfico N 011: Interacciones y Funcionalidades de la Gestin de Problemas Fuente: OSIATIS S.A. V2.0 Introduccin y Objetivos Como se explic en la seccin de Gestin de Incidentes, esta ltima tiene como exclusivo objetivo el restablecer lo ms rpidamente la calidad del servicio y no el determinar cules han sido los orgenes y causas del mismo.
46
Cuando algn tipo de incidente se convierte en recurrente o tiene un fuerte impacto en la infraestructura TI es la funcin de la Gestin de Problemas el determinar sus causas y encontrar posibles soluciones. Cabe diferenciar entre: Problema: causa subyacente, an 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 Gestin de Problemas figuran: o o o o o o Identificar, registrar y clasificar los problemas. Dar soporte a la Gestin de Incidentes proporcionando informacin y soluciones temporales o parches. Analizar y determinar las causas de los problemas y proponer soluciones. Elevar RFCs a la Gestin de Cambios para llevar a cabo los cambios necesarios en la infraestructura TI. Realizar un seguimiento post-implementacin de todos los cambios para asegurar su correcto funcionamiento. Realizar informes que documenten no slo los orgenes y soluciones a un problema sino que tambin sirvan de soporte a la estructura TI en su conjunto. o Analizar tendencias para prevenir incidentes potenciales.
Los principales beneficios de una correcta Gestin de Problemas:
o Un aumento de la calidad general de los servicios TI. o Se minimiza el nmero de incidentes. o Los incidentes se solucionan ms rpidamente y, generalmente, en la
primera lnea de soporte TI ahorrando recursos e innecesarios escalados.
o La documentacin desarrollada es de gran utilidad para la Gestin de la

Capacidad, Disponibilidad y Niveles de Servicio.
47
Las principales dificultades a la hora de implementar la Gestin de Problemas se resumen en: o Establecer una estrecha colaboracin entre la Gestin de Incidentes y la de Problemas. Sin sta la Gestin de Incidentes no dispondr de toda la informacin necesaria para la rpida solucin de los incidentes y la Gestin de Problemas carecer de la informacin 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 contratacin de personal especializado, aunque estos se vean sobradamente compensados por los beneficios derivados. Proceso Las principales actividades de la Gestin 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 Gestin de Cambios. Asimismo efecta la Revisin Post Implementacin de los mismos en estrecha colaboracin con la Gestin de Cambios. Y cuando la estructura de la organizacin lo permite, desarrollar una Gestin 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 Gestin de Problemas:
48
Grfico N 012: Procesos Implicados en la Gestin 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.
Grfico N 013: Control de Problemas Fuente: OSIATIS S.A. V2.0
49
El Control de Problemas se compone en esencia de tres fases: 1. Identificacin y Registro Una de las tareas principales de la Gestin de Problemas es identificar los mismos. Las principales fuentes de informacin 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 algn tipo de solucin 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 categora de problema.
o Anlisis de la infraestructura TI: en colaboracin con la Gestin de

Disponibilidad y de Capacidad, la Gestin 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 indicacin de la existencia de problemas subyacentes que no se hayan manifestado de forma explcita como incidentes. Todas las reas de la infraestructura TI deben colaborar con la Gestin de Problemas para identificar problemas reales y potenciales informando a sta de cualquier sntoma que pueda ser seal 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 especficos de los incidentes asociados sino ms bien en su naturaleza y posible impacto. El registro debe incorporar, entre otra, informacin sobre: o o o o o o Los CIs implicados. Causas del problema. Sntomas asociados. Soluciones temporales. Servicios involucrados. Niveles de prioridad, urgencia e impacto.
Estado: activo, error conocido, cerrado. 2. Clasificacin y Asignacin de Recursos
La clasificacin del problema engloba desde las caractersticas 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 configuracin (CIs) involucrados en el mismo. Un factor esencial es la determinacin 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 solucin del problema) como de su impacto (grado de deterioro de la calidad del servicio). Al igual que en la Gestin de Incidentes la prioridad puede cambiar en el curso del ciclo de vida del problema, por ejemplo, si se encuentra una solucin temporal al mismo que reduce considerablemente su impacto. Una vez clasificado y determinada su prioridad se deben de asignar los recursos necesarios para su solucin. Estos recursos deben ser suficientes para asegurar que los problemas asociados son tratados eficazmente y as minimizar su impacto en la infraestructura TI. 3. Anlisis y Diagnstico: Error conocido Los objetivos principales del proceso de anlisis son: o o Determinar las causas del problema. Proporcionar soluciones temporales a la Gestin 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 o Errores de procedimiento. Documentacin incorrecta.
51
o o
Falta de coordinacin entre diferentes reas. ...
Es tambin 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 informacin sobre errores conocidos aplicables al problema en cuestin. 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.
Grfico N 014: Control de Errores Fuente: OSIATIS S.A. V2.0
52
Identificacin y Registro de errores
El registro de los errores conocidos es de vital importancia para la Gestin de Incidentes pues debe llevar asociado, siempre que esto sea posible, algn tipo de solucin temporal que permita minimizar el impacto de los incidentes asociados. Anlisis y Solucin
Se deben investigar diferentes soluciones para el error evaluando en cada momento: o o o El posible impacto de las mismas en la infraestructura TI. Los costes asociados. 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 Gestin de Cambios. Una vez determinada la solucin ptima al problema y antes de elevar una RFC a la Gestin de Cambios han de tenerse en cuenta las siguientes consideraciones:
o
Es conveniente demorar la solucin? Ya sea porque se prevn cambios significativos en la infraestructura TI a corto plazo o por el escaso impacto del problema en cuestin.
Es la solucin temporal aportada suficiente para mantener unos niveles de calidad de servicios aceptable? Los beneficios justifican los costes asociados?
Sea cual sea la respuesta, todo la informacin sobre el error y su solucin 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 Gestin de Cambios la implementacin de los cambios de infraestructura propuestos.
53
Revisin Post Implementacin y Cierre
Antes de dar el problema por resuelto y cambiar su estado a cerrado se debe analizar el resultado de la implementacin de la RFC elevado a la Gestin 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 ms que todo un "conjunto de procedimientos, tcnicas y ayudas a la documentacin para el desarrollo de productos software. Una metodologa incluye la tarea construir modelo conceptual de datos. Para realizarlo, define un procedimiento y da a elegir entre una serie de tcnicas" [URJC 2006]. Entre las ms conocidas podemos mencionar las siguientes:
Grfico N 015: Metodologas de Desarrollo de Software

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 obligacin 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, bsicamente su objetivo se direcciona hacia "subir la calidad del software (en todas las fases por las que pasa) a travs de un mayor control sobre el proceso. Es labor del proceso de desarrollo definir quin debe hacer Qu, cundo y cmo debe hacerlo" [Patricio Letelier 2000]. En esta parte de la investigacin realizada hablaremos sobre algunas de las metodologas 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 artculo [Boehm, 1995] describe tres hitos crticos a ser utilizados en cualquier proyecto de forma de poder planificar y controlar el progreso del mismo, dando visibilidad a los stakeholders. Estos hitos estn 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 ingeniera (que componen los espirales del modelo en espiral) a las actividades de produccin (que componen la construccin en cascada del software). Su impacto en la industria del software ha sido tan importante que uno de los procesos ms 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 ms 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. Intercepcin (puesta en marcha). 2. Elaboracin (definicin, anlisis, diseo). 3. Construccin (implementacin). 4. Transicin (fin del proyecto y puesta en produccin). Se tiene que tener en cuenta que "en cada fase se ejecutarn una o varias iteraciones, las cuales estn debidamente explicadas en el Proceso Iterativo e Incremental. Pero a que se refiere con el proceso iterativo e incremental, se refiere ms que tono a la evolucin de prototipos ejecutables que se muestran a los usuarios y clientes [Rational Software Company 2001].
56
Grfico N 016: Dos Dimensiones de RUP Fuente: Introduccin a Rational Unified Process (RUP) - Patricio Letelier 2000 RUP define nueve actividades a realizar en cada fase del proyecto: 1. Modelado del negocio. 2. Anlisis de requisitos. 3. Anlisis y diseo. 4. Implementacin. 5. Test. 6. Distribucin. 7. Gestin de configuracin y cambios 8. Gestin del proyecto. 9. Gestin del entorno. Pero por otra parte tambin posee elementos o Workflows de apoyo entre los cuales tenemos [Patricio Letelier 2000]: Environment (Entorno). Project Management (Gestin del Proyecto). Configuration & Change Management (Gestin de Configuracin 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.
57
Conjuntos de Artefactos. o o o o o o o o o Business Modeling Set. Requirements Set. Analysis & Design Set. Implementation Set. Test Set. Deployment Set. Project Management Set. Configuration & Change Management Set. Environment Set.
Caractersticas 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 evolucin de prototipos ejecutables que se muestran a los usuarios y clientes. En el ciclo de vida iterativo a cada iteracin se reproduce el ciclo de vida en cascada a menor escala. Los objetivos de una iteracin se establecen en funcin de la evaluacin de las iteraciones precedentes. Las actividades se encadenan en una mini-cascada con un alcance limitado por los objetivos de la iteracin.
58
Grfico N 017: Proceso Iterativo Incremental
Fuente: Introduccin 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 Workfows. Los artefactos son el objetivo de cada actividad. Se basa en roles. UML. Muy organizativo. Mucha documentacin. XP (Extreme Programming) Programacin Extrema:
Es la primera metodologa gil y es la que le dio conciencia al movimiento actual de metodologas 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 tambin otro de los libros importantes de XP [Jeffries, 2001] en el que se bajaban los conceptos de Beck a la puesta en prctica 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 prctica que de su experiencia saba que trabajaba bien. Entonces, Beck decidi girar todas las perillas al mximo para ver que ocurra. As fue como dio inicio a XP. En la programacin 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. Diseo simple.
59
Los equipos de XP construyen software a un diseo simple. Comienzan simple, y con la prueba del programador y la mejora del diseo, la guardan de esa manera. Un equipo de XP mantiene el diseo satisfecho exactamente para la funcionalidad actual del sistema. No hay movimiento perdido, y el software es siempre listo para lo siguiente. El diseo 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 rpidas de diseo. Integracin continua. Los equipos de programacin extrema mantienen el sistema integrado completamente siempre. Los equipos de XP construyen pocas mltiples por da. (Un equipo de XP de cuarenta personas construye por lo menos ocho o diez veces por da). La integracin infrecuente conduce a los problemas senos en un proyecto del software. Se tiene que tener en cuenta que la integracin es crtica al momento del envo de cdigo, ya que el equipo no participa en ello, y se delega a menudo a la gente que no est al corriente del sistema entero. Codificacin de estndar. Los equipos de XP siguen un estndar comn de la codificacin, de modo que todo el cdigo en el sistema mire como si fuera escrito por un solo programador. Lo importante es que todo el cdigo parezca familiar. Mientras que el RUP intenta reducir la complejidad del software por medio de estructura y la preparacin de las tareas pendientes en funcin de los objetivos de la fase y actividad actual, XP, como toda metodologa gil, lo intenta por medio de un trabajo orientado directamente al objetivo, basado en las relaciones interpersonales y la velocidad de reaccin. XP intenta minimizar el riesgo de fallo del proceso por medio de la disposicin permanente de un representante competente del cliente a disposicin del equipo de desarrollo. Este representante debera estar en condiciones ue contestar rpida 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 codificacin del software en XP se produce siempre en parejas (dos programadores, un ordenador), por lo que se espera que la calidad del mismo
60
suba en el mismo momento de escribirlo. Al contrario que muchos otros mtodos, el cdigo pertenece al equipo en completo, no a un programador o pareja, de forma que cada programador puede cambiar cualquier parte del cdigo en cualquier momento si as lo necesita, dejndose en todo caso las mejoras orientadas al rendimiento para el final. Las parejas no se mantienen para todo el proyecto si no que rotan cclicamente 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 dems integrantes y con cada componente software, de forma que el conocimiento de la aplicacin 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 configuracin solo ser implementada cuando sea necesaria para cumplir los requerimientos. Se sigue un diseo evolutivo con la siguiente premisa: conseguir la funcionalidad deseada de la forma ms sencilla posible. Este diseo evolutivo hace que no se le de apenas importancia al anlisis como fase independiente, puesto que se trabaja exclusivamente en funcin de las necesidades del momento. Puntos Claves:

Ligero. Cercano al desarrollo. Se basa en UserStories. Fuerte comunicacin con el cliente. El cdigo fuente pertenece a todos. Programacin por parejas. Tests como base de la funcionalidad. Solo el mnimo de organizacin. Pobre en cuanto a documentacin. FDD (Desarrollo Manejado Por Rasgos):
Peter Coad es considerado uno de los referentes ms importantes dentro de la ingeniera de software. Coad ha sido uno de los principales pioneros detrs del movimiento de la orientacin a objetos y empez a trabajar con Ed Yourdon (uno
61
de los creadores del Anlisis Estructurado) a principios de los noventa, cuando este ltimo pidi ayuda a alguien de la comunidad de objetos para desarrollar una nueva metodologa, basada en el paradigma de OO. Posteriormente, Coad junto con Jeff De Luca y otros, participara en la creacin de FDD, una metodologa desarrollada alrededor del ao 1998 que presenta las caractersticas 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 definicin 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 tambin una jerarqua de features, siendo el eslabn superior el de feature set que agrupa un conjunto de features relacionadas con aspectos en comn del negocio. Por ltimo, establece el major feature set como el ms alto nivel de agrupacin de funcionalidad que abarca diferentes feature sets que contribuyen a proveer valor al cliente en relacin a un subdominio dentro del dominio completo de la aplicacin. Una de las ventajas de centrarse en las features del software es el poder formar un vocabulario comn que fomente que los desarrolladores tengan un dilogo fluido con los clientes, desarrollando entre ambos un modelo comn del negocio. Este tema ser tratado ms adelante en relacin al enfoque de las metodologas 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 iteracin. Cada proceso se divide en tareas y se da un criterio de comprobacin.
d) Disear por Rasgo. e) Construir por Rasgo.

OBJETIVOS Sintetizar un programa conforme a los rasgos requeridos.
62
En un desarrollo en trminos de FOP (Programacin Orientada a rasgos), los objetos se organizan en mdulos o capas conforme a rasgos. FDD esta pensado para proyectos con tiempo de desarrollo relativamente cortos (menos de un ao). Se basa en un proceso iterativo con iteraciones cortas (2 semanas aproximadamente) que producen un software funcional que el cliente y la direccin 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. Construccin de la lista de funcionalidades o rasgos. 3. Plan en base a las funcionalidades o rasgos a implementar. 4. Disear en base a las funcionalidades o rasgos. 5. Implementar en base a las funcionalidades o rasgos.
Grfico 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 segn va avanzando el proyecto, limitndose 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 funcin 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 tambin define mtricas para seguir el proceso de desarrollo de la aplicacin, tiles para el cliente y la direccin de la empresa, y que pueden ayudar, adems 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 organizacin. Existe una jerarqua dentro del equipo. El cdigo fuente tiene propietario. Los equipos varan en fncin de la funcionalidad a implementar. El conocimiento de la aplicacin se reparte a travs de trabajo en equipo y revisiones. Documentacin aceptable.
64
2.7. MARCO CONCEPTUAL:

Ttulo Sistema de Control para las Tareas del Servicio de Soporte Tcnico de la Oficina de Informtica de la Municipalidad Provincial de Piura mediante una Aplicacin Web Aplicacin Web. "La World Wide Web Internet han introducido a la poblacin en general en el mundo de la informtica. Compramos fondos de inversin colectivos y acciones, descargamos msica, vemos pelculas, obtenemos asesoramiento mdico, 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 Tcnico de la Oficina de Informtica de la Municipalidad Provincial de Piura. "Los sistemas de control y supervisin son una clase importante de sistemas de tiempo real. Verifican los sensores que proveen informacin del entorno del sistema y toman acciones" [SOMMERVILLE, 2002] con respecto al control que asumira soporte tcnico en sus tareas de mantenimiento en la Municipalidad Provincial de Piura. Metodologa Rational Unified Process (RUP). "Conjunto de actividades necesarias para transformar los requisitos de un usuario en un sistema software. Adems es un marco de trabajo genrico que puede especializarse para una gran variedad de sistemas software, para diferentes reas de aplicacin, diferentes tipos de organizaciones, diferentes niveles de aptitud y diferentes tamaos de proyecto" [Jacobson & Booch & Rumbaugh 2000].
65
2.8. HIPOTESIS:
La implementacin de una Aplicacin Web influye en el sistema de control de las tareas del servicio de Soporte Tcnico de la Oficina de Informtica de la Municipalidad Provincial de Piura.
2.9. VARIABLES E INDICADORES IMPLICADOS EN EL PROYECTO: Variable Independiente: Aplicacin Web:

El presente proyecto desarrollar una Aplicacin Web que va permitir al rea de Soporte Tcnico tener un mejor control y seguimiento de los procesos que se siguen para la solucin de los problemas que se presentan en las distintas oficinas de la Municipalidad de Piura. Esta mejora del Sistema de Informacin actual que presenta el rea de Soporte Tcnico permitir optimizar dichos procesos, siendo ms 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 Tcnico para el mantenimiento, reparacin y respaldo de los diversos equipos informticos y electrnicos, 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 Aplicacin Web a desarrollar permitir optimizar el desarrollo y ejecucin de dichas operaciones tcnicas a travs de un mejor control, administracin y organizacin.
Variable Interviniente:
Proceso Unificado de Racional (RUP): Es una metodologa del proceso de ingeniera de software que proporciona un enfoque disciplinado para asignar tareas y responsabilidades dentro de una organizacin del desarrollo y ser aplicada en la presente tesis.
66
Indicadores:
Nro
Indicador
Definicin Conceptual Tiempo que el tcnico demora en llegar a una solicitud de servicio.
Definicin Operacional
Unidad de Medida Minutos
Tcnica de Instrumentos Medicin de Medicin Observacin Gua de Observacin N 01 (Cronmetro) Anexo
I01 Tiempo para llegar a atender una Solicitud de Servicio.
SS =
S
i =1
Ss - Tiempo de Asistencia a la Solicitud de Servicio. S = Tiempo de traslado entre servicio. n = Cantidad total de Solicitudes de Servicio
I02 Tiempo para solucionar una solicitud de Servicio.
I03 Cumplimiento de un Tcnico en cuanto a los Servicios Asignados.
I04 Porcentaje de Servicio no atendidos.
n Es el tiempo que Ti el tcnico i =1 demora en TS = n solucionar una Ts = Tiempo de solucin solicitud de de Solicitudes de servicio. Servicio. T = Tiempo para realizar una Solucin 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 tcnico. cumplimiento de un tcnico 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.
Minutos
Observacin
Gua de Observacin N 02 (Cronmetro) Anexo
Porcentaje
Observacin
Gua de Observacin N 03 Anexo
Porcentaje
Observacin
Cuadro N 002: Indicadores de la Variable Dependiente Fuente: El Autor

67
Nro
Indicador
Definicin Conceptual
Unidad de Medida Unidad
Tcnica de Instrumentos Medicin de Medicin Observacin Gua de Observacin N 05 Anexo
I05 Solicitudes de Servicio Asignadas por Tcnico.
I06 Solicitudes de Servicio por oficina.
n Es el nmero de S S = St servicios t =1 asignados a St =servicio asignado por cada tcnico. tcnico. t =orden de servicio asignada al tcnico. Ss =Solicitudes de Servicio. n Es el nmero de S S = Si servicios i =1 solicitados por SS = Solicitudes de oficina. Servicios de Oficina. Si = Solicitudes de servicios de la Oficina especificada.
Unidad
Observacin
I07 Nmero de equipos internados.
n Son los equipos El = Gi que provienen i =1 de otra oficina y El=Nmero de Equipos que tienen que ser atendidos en de otro local. Gi=Guas de Salida. Soporte.
Unidad
Observacin
I08 Tiempo de bsqueda de historial tcnico.
Tiempo para buscar la informacin de mantenimiento (bitcora) de un equipo.
TB =
Ti
i =1
Minutos
Observacin
TB = Tiempo de Bsqueda T = Tiempo de Bsqueda de historial Tcnico. n = Cantidad total de bsquedas
I09 Tiempo de Emisin (entrega) de Documentos (Reportes, Guas de salida y/o Fichas Tcnicas).
Tiempo transcurrido para la entrega de la documentacin solicitada.
TED =
t
i =1
Minutos
i
Observacin
TED = Tiempo de Emisin. t = Tiempo de Entrega por documento. n = Cantidad total de documentacin
Cuadro N 002: Indicadores de la Variable Dependiente (continuacin) Fuente: El Autor

68
Nro
Indicador
Definicin Conceptual
Unidad de Medida Porcentaje
Tcnica de Instrumentos Medicin de Medicin Encuesta Cuestionario de Encuesta N 01 Anexo
I10 Nivel de satisfaccin del usuario.
n Medimos la Usi conformidad de i =1 los usuarios con NS = x100% n la herramienta a NS = Nivel de desarrollar. Satisfaccin. Us = Usuario Satisfecho. n = Cantidad total de usuarios
Cuadro N 002: Indicadores de la Variable Dependiente (continuacin) Fuente: El Autor
69
________________________________________________________
CAPITULO III: METODOLOGIA

________________________________________________________
70
3. METODOLOGIA:
3.1. TIPO DE ESTUDIO:
Los propsitos bsicos del paradigma cuantitativo en la investigacin socioeducativa consisten en realizar mediciones y predicciones exactas del comportamiento regular de grupos sociales. "Los positivistas buscan los hechos o causas de los fenmenos sociales con independencia de los estados subjetivos de los individuos" [Taylor y Bogdan, 1986], es decir buscan la objetividad. La bsqueda principal consiste en explicar las causas de los fenmenos, confrontar teora y praxis, detectar discrepancias, analizar estadsticamente, establecer conexiones y generalizaciones (abstracciones). [Sant'Anna, y Smith, 1983] sugieren que el paradigma cuantitativo se nutre de los supuestos filosficos del realismo, racionalismo, positivismo y de la epistemologa cientfica de Comte y el Crculo de Viena. La Investigacin Aplicada es aquel tipo de estudio cientfico orientado a resolver problemas de la vida cotidiana o a controlar situaciones prcticas. [Jos Padrn, 2006] La presente tesis est basada en el paradigma cuantitativo porque me va permitir recoger, procesar y analizar datos numricos sobre variables determinadas mediante mtodos estadsticos. La hiptesis formulada en esta investigacin se traduce en variables, las que a su vez se traducen en indicadores cuantificables. Esta es una investigacin aplicada porque se busca dar solucin a un problema a travs del desarrollo de una herramienta tecnolgica.
71
3.2. DISEO DEL ESTUDIO:

Para el presente proyecto de investigacin el diseo a utilizar ser cuasi experimental con Pre-test y Post-test y grupos intactos. [Hernandez, Fernndez, Baptista 2003] definen que en este tipo de diseo se ...manipulan deliberadamente, al menos, una variable independiente para observar su efecto y relacin con una o ms variables dependientes, slo 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 O2 X : Pre-test o Prueba Inicial : Post-test o Prueba Final : Variable Interviniente
Este diseo 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. POBLACIN Y MUESTRA:

Poblacin La poblacin tomada para el desarrollo de la presente tesis es el personal encargado del servicio que brinda el rea de Soporte Tcnico 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 Tcnico de la Oficina de Informtica de la Municipalidad de Piura. La cantidad de la muestra sern las 5 personas encargadas del servicio que brinda la dependencia en mencin, por lo tanto no es necesario aplicar una frmula para obtener la muestra.
72
3.4. MTODOS DE INVESTIGACIN:

Recoleccin de informacin de un estado inicial a travs de una prueba de entrada o pre-test. Posteriormente se aplicar una prueba de salida o post test con una medicin de los efectos que ha tenido la variable independiente. Y por ltimo se har una comparacin entre la informacin que se tuvo al inicio y al final.
3.5. TCNICAS E INSTRUMENTOS DE RECOLECCIN DE DATOS:

Tcnicas Las tcnicas de recoleccin de datos que se emplearn son: encuestas y observacin. Estas nos ayudarn a recoger informacin primordial para desarrollar el presente trabajo de investigacin o tesis que tiene por ttulo: Sistema de Control para las Tareas del Servicio de Soporte Tcnico de la Oficina de Informtica de la Municipalidad Provincial de Piura. Instrumentos Los instrumentos de recoleccin de datos para el desarrollo de la presente investigacin o proyecto de tesis son: las guas de observacin y cuestionarios de encuestas. A continuacin en el siguiente cuadro se presentan los indicadores con sus respectivas tcnicas e instrumentos de recoleccin de datos:
73
N
1 2 3 4 5 6 7 8 9 10
Indicadores
Tiempo para llegar a atender una Solicitud de Servicio. Tiempo para solucionar una solicitud de Servicio. Cumplimiento de un Tcnico en cuanto a los Servicios Asignados. Porcentaje de Servicio no atendidos. Solicitudes de Servicio Asignadas por Tcnico. Solicitudes de Servicio por oficina. Nmero de equipos internados. Tiempo de bsqueda de historial tcnico. Tiempo de Emisin (entrega) de Documentos (Reportes, Guas de salida y/o Fichas Tcnicas). Nivel de satisfaccin del usuario.
Tcnicas
Observacin Observacin Observacin Observacin Observacin Observacin Observacin Observacin Observacin Encuesta
Instrumentos
Gua de Observacin Gua de Observacin Gua de Observacin Gua de Observacin Gua de Observacin Gua de Observacin Gua de Observacin Gua de Observacin Gua de Observacin Cuestionario de Encuesta
Cuadro N 003: Indicadores, Tcnicas e Instrumentos de Recoleccin de Datos Fuente: El Autor
3.6. MTODOS DE ANLISIS DE DATOS:

Para analizar los datos recolectados se estudiarn los resultados organizados en cuadros estadsticos para determinar las principales tendencias de la informacin utilizando los porcentajes de los cuadros o de las aplicaciones estadsticas. Para el anlisis 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 distribucin del tiempo. A continuacin 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: Precio Total

S/. 50.00 S/. 200.00 S/. 10.00 S/. 25.00 S/. 10.00 S/. 5.00 S/. 200.00 S/. 200.00 S/. 100.00 S/. 400.00 S/. 25.00 S/. 10.00 S/. 60.00 S/. 400.00 S/. 200.00 S/. 1,895.00
Recursos
Memoria USB 4 GB Cartuchos de tinta para impresora Folder Manila A4
Cantidad
01 04 10 1 millar 10 10 ___ 200 horas ___ ___ 500 hojas 2 3 ___ ___
C/U
S/. 50.00 S/. 50.00 S/. 1.00 S/. 25.00 S/. 1.00 S/. 0.50 ___ S/. 1.00 ___ ___ S/. 0.05 S/. 5.00 S/. 20.00 ___ ___
Bienes
Papel A4 CDs de 700 MB Lapiceros Luz Elctrica Internet Telfono
Servicios
Movilidad Fotocopiado Anillados Empastados Personal de apoyo
Remuneraciones
Otros
Total
Cuadro N 005: Presupuesto de la Tesis Fuente: El Autor
4.3. FINANCIAMENTO: El presente proyecto de investigacin es autofinanciado por el autor ya que la Municipalidad Provincial de Piura no financia este tipo de investigaciones hechas por alumnos universitarios.
77
________________________________________________________
CAPITULO V: REFERENCIAS BIBLIOGRAFICAS

________________________________________________________
78
REFERENCIAS BIBLIOGRAFICAS
[lvarez Brotons, Espaa, 2004] Sistemas de Control, artculo publicado por en la Universidad Politcnica 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 Arvalo, Manuel & Zapata Navarro, Jhon (Piura 2009), Sistema Informtico de Registro de Mantenimiento de Equipos de Cmputo del rea de Soporte del Centro de Informtica y Telecomunicaciones de la Universidad Nacional de Piura. Universidad Csar 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 (Valparaso, Chile 2004), Estudio del Sistema de Monitoreo y Registro de Inventarios de Compras y su Integracin Estratgica mediante el Control de Gestin. Universidad de Valparaso. [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; Fernndez Collado, Carlos; Baptista Lucio, Pilar; Mxico 2003] Metodologa de la Investigacin. Mc Graw Hill.
79
[Johnson Rob, 2003] Expert One-on-One J2EE Design and Development. Indianapolis: Wrox Press. [Johnson Rob, mayo 2005] Introduction to the Spring Framework. [En lnea]. Disponible en: www.theserverside.com/articles/article.tss?l=SpringFramework [Jos Padrn G.] Bases del concepto de "Investigacin Aplicada"[en lnea]. Disponible en: http://padron.entretemas.com/InvAplicada/index.htm Metodologas de Desarrollo de Software (Espaa 2006), artculo publicado por la Universidad Rey Juan Carlos. Metodologa ITIL (Information Technologies Infraestructure Library) OSIATIS S.A. V2.0 Disponible en: http://itil.osiatis.es/Curso_ITIL/ [P. Letelier, Zaragoza, octubre 2000] Metodologas de Produccin de Software. Pesntez Huerta, lvaro Eduardo (Guayaquil, Ecuador 2007), Elaboracin de un Plan de Mantenimiento Predictivo y Preventivo en Funcin de la Criticidad de los Equipos del Proceso Productivo de una Empresa Empacadora de Camarn. Escuela Superior Politcnica del Litoral. Plan Estratgico Institucional (2009 2014), Municipalidad Provincial Piura (PEI-MPP) Plan Operativo Institucional (2011), Municipalidad Provincial de Piura (POIMPP) Reglamento de Organizacin 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), Anlisis, Diseo y Desarrollo del Mdulo Web para la Gestin y Control de Inventario de Bienes de la Oficina de Control Patrimonial de la Direccin Regional de Salud Piura. Universidad Nacional de Piura.
80
[Sant'Anna, F., 1983] Estratgias quantitativas e qualitativas de pesquisa educational: da ao a obser-vao participante. Educao e realidade. Santilln Pinedo, Karla & Tornero Mendoza, Ludver (Trujillo 2001), Sistema de Informacin de Control de Almacn de la Direccin Regional de Educacin de La Libertad DRELL. Universidad Csar Vallejo. [Smith, J., 1983] Quantitative versus qualitative research: An attempt to clarify the issue. Educational Researcher. [Sommerville, Ian, 2002] Ingeniera del Software. [Taylor, S. J. y Bogdan, R., 1986] Introduccin a los mtodos cualitativos de investigacin. La bsqueda de significados. Buenos Aires: Editorial Paids. Vega Bustamante, Roco Olinda (Lima 2009), Anlisis, diseo e implementacin de un sistema de administracin de incidentes en atencin al cliente para una empresa de telecomunicaciones. Pontificia Universidad Catlica del Per. [Walls Craig, 2005] et. al. Spring in Action. Greenwich: Manning Publications.
81
________________________________________________________
CAPITULO VI: ANEXOS

________________________________________________________
82
ANEXO 01 Gua de Observacin N 01 Tiempo para llegar a atender una solicitud de servicio. Instrucciones: En los das de observacin se tomarn la fecha y hora de inicio del pedido de atencin (solicitud de servicio) y la hora de llegada del tcnico a la dependencia municipal para atender la solicitud de servicio. Fecha de inicio de observacin: __/ __/ ___Hora de Inicio: _________ Nmero Hora de Inicio Hora de Llegada Tiempo Total (Min)
Tiempo Promedio Hora Final: _________Fecha de fin de observacin: __/ __/ _____ Observaciones: _________________________________________________________________ _________________________________________________________________ ___________________________________________________________ Observador Revisado Procesado Archivado
83
ANEXO 02 Gua de Observacin N 02 Tiempo para solucionar una solicitud de servicio. Instrucciones: En los das de observacin se tomarn la fecha y hora de inicio de la atencin a la solicitud de servicio por parte del tcnico y la hora de la finalizacin de dicha atencin. Fecha de inicio de observacin: __/ __/ ___Hora de Inicio: _________ Nmero Hora de Inicio Hora de Finalizacin Tiempo Total (Min)
84
ANEXO 03 Gua de Observacin N 03 Cumplimiento de un tcnico en cuanto a los servicios asignados. Instrucciones: En los das de observacin se tomarn las cantidades de los servicios atendidos por un tcnico y los que le han sido asignados a atender.
Fecha de inicio de observacin: __/ __/ ___Hora de Inicio: _________ Tcnico Cantidad Cantidad Porcentaje Solicitudes Solicitudes Cumplimiento Asignadas Atendidas
Hora Final: _________Fecha de fin de observacin: __/ __/ _____ Observaciones: _________________________________________________________________ _________________________________________________________________ ___________________________________________________________ Observador Revisado Procesado Archivado
85
ANEXO 04 Gua de Observacin N 04 Porcentajes de Servicios no Atendidos. Instrucciones: En los das de observacin se tomarn las cantidades de los servicios no atendidos y el total de las solicitudes de servicio. Fecha de inicio de observacin: __/ __/ ___Hora de Inicio: _________ Da Cantidad Solicitudes Cantidad Solicitudes no Atendidas Porcentaje Servicios no Atendidos
86
ANEXO 05 Gua de Observacin N 05 Solicitudes de Servicio Asignadas por Tcnico. Instrucciones: En los das de observacin se tomarn las cantidades de las solicitudes de los servicios asignados a un tcnico.
Fecha de inicio de observacin: __/ __/ ___Hora de Inicio: _________ Tcnico Cantidad Solicitudes Asignadas
87
ANEXO 06 Gua de Observacin N 06 Solicitudes de Servicio por Oficina. Instrucciones: En los das de observacin se tomarn las cantidades de las solicitudes de los servicios de oficinas especficas. Fecha de inicio de observacin: __/ __/ ___Hora de Inicio: _________ Oficina Cantidad Solicitudes Servicios
88
ANEXO 07 Gua de Observacin N 07 Nmero de Equipos Internados. Instrucciones: En los das de observacin se tomarn las cantidades de las guas de salida de los equipos de otras dependencias que han sido atendidos en el taller de Soporte Tcnico.
Fecha de inicio de observacin: __/ __/ ___ Hora de Inicio: _________ Da Cantidad de Equipos de Otra Dependencia
89
ANEXO 08 Gua de Observacin N 08 Tiempo de Bsqueda de Historial Tcnico. Instrucciones: En los das de observacin se tomarn la fecha y hora de inicio de la bsqueda del historial tcnico de un equipo y la hora de finalizacin de dicha bsqueda. Fecha de inicio de observacin: __/ __/ ___Hora de Inicio: _________ Nmero Hora de Inicio Hora de Finalizacin Tiempo Total (Min)
90
ANEXO 09 Gua de Observacin N 09 Tiempo de Emisin de Documentos. Instrucciones: En los das de observacin se tomarn la fecha y hora de inicio de la emisin de un documento (reportes, guas de salida y/o fichas tcnicas) y la hora de finalizacin o entrega de dicho documento. Fecha de inicio de observacin: __/ __/ ___Hora de Inicio: _________ Nmero Hora de Inicio Hora de Entrega Tiempo Total (Min)
91
ANEXO 10 Cuestionario de Encuesta N 01 Sistema de Control para las Tareas del Servicio de Soporte Tcnico de la Oficina de Informtica de la Municipalidad Provincial de Piura mediante una Aplicacin Web El presente cuestionario de encuesta ser desarrollado como gua para obtener el grado de satisfaccin del usuario de la aplicacin web. _________________________________________________________________ Marque con un crculo o un aspa su repuesta elegida. 1) Con la aplicacin web implementada se ha mejorado su actividad de trabajo?
a. Nada b. Poco c. Medianamente d. Mucho
2) La aplicacin web implementada es fcil de manejar?
a. b. c. d.
Nada Poco Medianamente Mucho
3) Con la aplicacin web implementada la informacin est disponible de forma inmediata?

92
4) La informacin que brindan los reportes de la aplicacin web son de utilidad para los usuarios del sistema?
Nada Poco Medianamente Mucho
5) Est usted satisfecho con la aplicacin web?
6) La aplicacin web implementada cumple con todos los requisitos solicitados?
93
7) Cul es su opinin general de la aplicacin web?
Gracias por su participacin
Este cuestionario de encuesta se mide de la siguiente forma:
Como para cada pregunta se presentan 4 opciones las cuales se asemejan (grado de medicin), una vez resueltas estas encuestas por el personal de Soporte Tcnico, se proceder al conteo de las letras para conocer cul de ellas ha obtenido mayor puntaje.
Si la mayor cantidad de las letras son:
PUNTUACIN a
GRADO DE SATISFACCIN Quiere decir que el usuario se

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

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

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

Uploaded by

Copyright:

Available Formats

UNIVERSIDAD CSAR VALLEJO PIURA FACULTAD DE INGENIERA ESCUELA DE INGENIERA DE SISTEMAS Sistema de Control para las Tareas del

Universidad Csar Vallejo-Piura

Escuela Ingeniera Sistemas

Jess Antonio Pino Chacn

Universidad Csar Vallejo-Piura

Escuela Ingeniera Sistemas

Jess Antonio Pino Chacn

Universidad Csar Vallejo-Piura

Escuela Ingeniera Sistemas

Jess Antonio Pino Chacn

Universidad Csar Vallejo-Piura

Escuela Ingeniera Sistemas

Jess Antonio Pino Chacn

Universidad Csar Vallejo-Piura

Escuela Ingeniera Sistemas

INDICE DE GRAFICOS Y CUADROS

Jess Antonio Pino Chacn

Universidad Csar Vallejo-Piura

Escuela Ingeniera Sistemas

Jess Antonio Pino Chacn

Universidad Csar Vallejo-Piura

Escuela Ingeniera Sistemas

1. GENERALIDADES DEL PROYECTO DE INVESTIGACION:

1.2. TIPO DE INVESTIGACIN:

1.3. REA DE INVESTIGACIN:

1.4. INSTITUCIN DONDE SE REALIZA LA INVESTIGACIN:

Jess Antonio Pino Chacn

Universidad Csar Vallejo-Piura

Escuela Ingeniera Sistemas

1.6. ASESOR METODOLGICO:

1.7. ASESOR ESPECIALISTA:

1.8. DURACIN DEL PROYECTO DE INVESTIGACIN:

CAPITULO II: PLAN DE INVESTIGACION

Jess Antonio Pino Chacn

Universidad Csar Vallejo-Piura

Escuela Ingeniera Sistemas

Jess Antonio Pino Chacn

Universidad Csar Vallejo-Piura

Escuela Ingeniera Sistemas

2.2. FORMULACIN DEL PROBLEMA: 2.2.1. Pregunta General:

Jess Antonio Pino Chacn

Universidad Csar Vallejo-Piura

Escuela Ingeniera Sistemas

2.2.2. Preguntas de Investigacin:

2.2.3. Objetivo General:

2.2.4. Objetivos Especficos: Determinar de qu manera una Aplicacin Web mejora la

Jess Antonio Pino Chacn

Universidad Csar Vallejo-Piura

Escuela Ingeniera Sistemas

Determinar de qu manera una Aplicacin Web permitir contar con

Determinar de qu manera una Aplicacin Web incidir en la

Determinar de qu manera una Aplicacin Web permitir que el rea

2.3. JUSTIFICACIN E IMPORTANCIA DEL PROYECTO:

Jess Antonio Pino Chacn

Universidad Csar Vallejo-Piura

Escuela Ingeniera Sistemas

2.4. LIMITACIONES DEL PROYECTO:

Jess Antonio Pino Chacn

Universidad Csar Vallejo-Piura

Escuela Ingeniera Sistemas

El trabajo dinmico o poca disponibilidad del personal de Soporte Tcnico

La aplicacin web a desarrollar ser independiente a la aplicacin web

La base de datos del sistema de inventario de la municipalidad de Piura

2.5. MARCO REFERENCIAL CIENTIFICO: 2.5.1. Antecedentes: Antecedentes Locales: