Proyecto de Tesis Aplicacion Web Control Servicios Soporte Tecnico

UNIVERSIDAD CÉSAR VALLEJO
PIURA
FACULTAD DE INGENIERÍA
ESCUELA DE INGENIERÍA DE SISTEMAS
“Sistema de Control para las Tareas del Servicio

de Soporte Técnico de la Oficina de Informática de
la Municipalidad Provincial de Piura mediante una
Aplicación Web”
Proyecto de tesis
Autor
Pino Chacón Jesús Antonio Manuel

Asesor
Mg. Luis Velez Ubillus
Piura - Perú
(2011)
Universidad César Vallejo-Piura Escuela Ingeniería Sistemas
ASESORES DE TESIS
ASESOR METODOLÓGICO:
___________________
ASESOR ESPECIALISTA:
____________________
Ing. Noelia Saavedra Nizama
Sistema de Control para las Tareas del Servicio de

Soporte Técnico de la Oficina de Informática de la 2 Jesús Antonio Pino Chacón
Municipalidad Provincial de Piura mediante una
Aplicación Web
INTRODUCCIÓN
El constante y permanente avance tecnológico en el manejo de información con

sistemas cada vez más sofisticados debido al ambiente competitivo en que
vivimos, todo esto tiene como consecuencia un notorio cambio para la Oficina de
Informática, redefiniendo sus objetivos y estrategias que le permitan cambiar la
estructura de las vías de distribución y rediseñar procesos para mejorar sus
servicios, obteniéndose la automatización de varios procesos del sistema de
control para así minimizar las barreras del tiempo y distancia, facilitar el acceso a
fuentes de información y potenciar el desarrollo de los servicios, además incide
favorablemente en la eficiencia operativa, la calidad de los servicios prestados, el
acercamiento con los usuarios o trabajadores que laboran en la municipalidad
provincial de Piura y la coordinación de actividades.
En la presente tesis, desarrollo e implementación, se busca mejorar el sistema de

control para las tareas del servicio de soporte técnico, sumado al crecimiento de
nuevas técnicas, herramientas y filosofías orientadas a la optimización de los
medios, teniendo como prioridad prevenir y reducir los riesgos suscitados en las
tareas operativas y administrativas relacionadas con la conservación y los
servicios de mantenimiento que se brindan.

Aplicación Web
DEDICATORIA
El presente proyecto de investigación se lo

dedico a Dios y a mis padres por su
comprensión y ayuda en todo momento. Mis
padres me han enseñado a ser perseverante
para encarar las adversidades de la vida sin
perder nunca la fe y la esperanza ni
desfallecer en el intento de alcanzar nuestros
objetivos y metas.
El Autor

Aplicación Web
AGRADECIMIENTO
Agradezco primeramente a Dios por haberme motivado para realizar el presente

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

Aplicación Web
ÍNDICE
Nº Página
CAPITULO I: Generalidades............................................................................................9
1.1. Título................................................................................................................... 10
1.2. Tipo de Investigación...........................................................................................10
1.3. Área de Investigación..........................................................................................10
1.4. Institución donde se realiza la Investigación..................................................10
1.5. Autor................................................................................................................... 10
1.6. Asesor Metodológico........................................................................................10
1.7. Asesor Especialista...........................................................................................10
1.8. Duración del Proyecto de Investigación..........................................................10
CAPITULO II: Plan de Investigación..............................................................................11
2.1. Descripción de la Realidad Problemática........................................................12
2.2. Formulación del Problema................................................................................13
2.2.1. Pregunta General...............................................................................................13
2.2.2. Preguntas de Investigación..............................................................................13
2.2.3. Objetivo General................................................................................................14
2.2.4. Objetivos Específicos.......................................................................................14
2.3. Justificación e Importancia del Proyecto .......................................................15
2.4. Limitaciones del Proyecto................................................................................16
2.5. Marco Referencial Científico............................................................................17
2.5.1. Antecedentes.....................................................................................................17
2.6. Marco Teórico....................................................................................................20
2.6.1. Municipalidad Provincial de Piura........................................................................20
2.6.2 Oficina de Informática.......................................................................................24
2.6.3. Soporte Técnico................................................................................................25
2.6.4. Sistema de Control............................................................................................26
2.6.5. Aplicación Web..................................................................................................28
2.6.6. Gestión de Incidentes.......................................................................................40
2.6.7. Gestión de Problemas.......................................................................................46
2.6.8. Metodología de Desarrollo................................................................................55
2.7. Marco Conceptual.............................................................................................65
2.8. Hipótesis............................................................................................................ 66
2.9. Variables e Indicadores Implicados en el Proyecto........................................66

Aplicación Web
ÍNDICE
Nº Página
CAPITULO III: Metodología............................................................................................70

3.1. Tipo de Estudio..................................................................................................71
3.2. Diseño del Estudio............................................................................................72
3.3. Población y Muestra..........................................................................................72
3.4. Métodos de Investigación.................................................................................73
3.5. Técnicas e Instrumentos de Recolección de Datos........................................73
3.6. Métodos de Análisis de Datos..........................................................................74
CAPÍTULO IV: Administración.......................................................................................75
4.1. Cronograma.......................................................................................................76
4.2. Presupuesto.......................................................................................................77
4.3. Financiamiento..................................................................................................77
CAPÍTULO V: Referencias Bibliográficas.....................................................................78
CAPÍTULO VI: Anexos...................................................................................................82
ANEXO 01: Guía de Observación Nº 01 .......................................................................83
ANEXO 02: Guía de Observación Nº 02........................................................................84
ANEXO 10: Cuestionario de Encuesta Nº 01................................................................92
INDICE DE GRAFICOS Y CUADROS

Aplicación Web
Nº Página
Cuadro N° 001: Política Institucionales........................................................................21

Gráfico N° 001: Organigrama de la Municipalidad Provincial de Piura......................23
Gráfico N° 002: Esquema general de un sistema........................................................26
Gráfico N° 003: Esquema general de un sistema de control......................................28
Gráfico N° 004: MVC de arquitectura Tipo 1 ...............................................................32
Gráfico N° 005: MVC de arquitectura Tipo 2 ...............................................................32
Gráfico N° 006: Gestión de Incidentes.........................................................................40
Gráfico N° 007: Proceso de Gestión de Incidentes (resumen) ..................................41
Gráfico N° 008: Diagrama de Prioridades Del Incidente.............................................44
Gráfico N° 009: Proceso de Escalado de Incidentes...................................................45
Gráfico N° 010: Procesos implicados en la Gestión de Incidentes............................46
Gráfico N° 011: Interacciones y Funcionalidades de la Gestión de Problemas........47
Gráfico N° 012: Procesos Implicados en la Gestión de Problemas...........................50
Gráfico N° 013: Control de Problemas.........................................................................50
Gráfico N° 014: Control de Errores...............................................................................53
Gráfico N° 015: Metodologías de Desarrollo de Software...........................................55
Gráfico N° 016: Dos Dimensiones de RUP...................................................................57
Gráfico N° 017: Proceso Iterativo Incremental.............................................................59
Gráfico N° 018: Proceso FDD........................................................................................64
Cuadro N° 002: Indicadores de la Variable Dependiente............................................67
Cuadro N° 003: Indicadores, Técnicas e Instrumentos de Recolección de Datos....74
Cuadro N° 004: Cronograma de Actividades de la Tesis............................................76
Cuadro N° 005: Presupuesto de la Tesis......................................................................77

Aplicación Web
________________________________________________________
CAPITULO I:
GENERALIDADES
________________________________________________________
1. GENERALIDADES DEL PROYECTO DE INVESTIGACION:

Aplicación Web
1.1. TÍTULO:
“Sistema de Control para las Tareas del Servicio de Soporte Técnico de la Oficina
de Informática de la Municipalidad Provincial de Piura mediante una Aplicación
Web”
1.2. TIPO DE INVESTIGACIÓN:
“EXPLICATIVA”
1.3. ÁREA DE INVESTIGACIÓN:
“TECNOLOGICA”
1.4. INSTITUCIÓN DONDE SE REALIZA LA INVESTIGACIÓN:
“Área de Soporte Técnico de la Municipalidad Provincial de Piura”
1.5. AUTOR:
Jesús Antonio Manuel Pino Chacón
1.6. ASESOR METODOLÓGICO:
1.7. ASESOR ESPECIALISTA:
Ing. Noelia Saavedra Nizama
1.8. DURACIÓN DEL PROYECTO DE INVESTIGACIÓN:
Inicio: 29 de marzo del 2011

Final: 18 de diciembre del 2011

Aplicación Web
________________________________________________________
CAPITULO II:
PLAN DE INVESTIGACION
________________________________________________________
2. PLAN DE LA INVESTIGACION:

Aplicación Web
2.1. DESCRIPCIÓN DE LA REALIDAD PROBLEMÁTICA:
El área de Soporte Técnico pertenece a la Oficina de Informática y que a su vez

esta pertenece a la Gerencia de Tecnologías y Sistemas de Información de la
Municipalidad Provincial de Piura.
Soporte Técnico soluciona problemas de hardware, software, eléctricos,

electrónicos, telefónicos y de redes de la mayoría de equipos que se encuentran
en la municipalidad, se limita a estas actividades y no a proporcionar las políticas
de seguridad y privacidad de la red de trabajo o dominio.
El problema principal radica en el deficiente control de las tareas del servicio de

Soporte Técnico de la Oficina de Informática de la Municipalidad Provincial de
Piura. De ello se derivan algunos subproblemas como:
 El registro de atenciones se hace de manera manual y en algunas ocasiones

cuando los problemas son complicados y requieren más recursos se atienden de
una manera inapropiada.
 No se maneja información estadística de los sucesos que acontecen en Soporte

Técnico.
 No existe un procedimiento adecuado de control y seguimiento en el área de

Soporte Técnico, todo se hace manualmente.
 Soporte Técnico no cuenta con un inventario propio.
 El Área de Soporte Técnico no tiene independencia para planificar operaciones y

tareas administrativas y de mantenimiento en la municipalidad de Piura ya que
esto depende de la Oficina de Informática.
 El proceso de atenciones a los problemas que se presentan en las dependencias

de la municipalidad es poco organizado.
 Se designa a Soporte Técnico escasos recursos (hardware, software y

herramientas) en stock para atender los problemas que acontecen en la
municipalidad.

Aplicación Web
 El control del ingreso de requerimientos a soporte técnico es inadecuado.
 Los puntos de reposición de Soporte Técnico no están definidos.
 La planificación de tareas para el proceso del mantenimiento preventivo no es el

adecuado.
 La planificación de tareas para el proceso del mantenimiento correctivo no es el

adecuado.
 El registro y monitoreo del historial de cada equipo de la municipalidad de Piura

no es el mas conveniente para soporte técnico.
2.2. FORMULACIÓN DEL PROBLEMA:
2.2.1. Pregunta General:
¿Cómo influye una Aplicación Web en el sistema de control de las tareas del
servicio de Soporte Técnico de la Oficina de Informática de la Municipalidad
Provincial de Piura?
2.2.2. Preguntas de Investigación:
¿De qué manera influye una aplicación web en la mejora de la organización

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

Aplicación Web
¿De qué manera influye una aplicación web para que el Área de Soporte
Técnico tenga independencia para planificar operaciones y tareas
administrativas y de mantenimiento?
2.2.3. Objetivo General:
“Determinar cómo influye una Aplicación Web en la mejora del Sistema de

Control de las Tareas del Servicio de Soporte Técnico de la Oficina de
Informática de la Municipalidad Provincial de Piura”
2.2.4. Objetivos Específicos:
 Determinar de qué manera una Aplicación Web mejora la

organización y la planificación de tareas para el proceso del
mantenimiento preventivo y correctivo de los diferentes equipos de la
Municipalidad Provincial de Piura.
 Determinar de qué manera una Aplicación Web permitirá contar con

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

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

de Soporte Técnico tenga independencia para planificar operaciones
y tareas administrativas y de mantenimiento.
2.3. JUSTIFICACIÓN E IMPORTANCIA DEL PROYECTO:

Aplicación Web
En vista de las necesidades del Área de Soporte Técnico de la Municipalidad de

Piura de llevar un mejor control en la atención y solución de problemas técnicos
que sufren los equipos de las diferentes áreas de la Municipalidad es que se
desarrolla el presente proyecto para beneficiar tanto a los usuarios de la
Municipalidad Provincial de Piura como a los trabajadores que laboran en el área
de ST.
Este proyecto abarcará también un mejor manejo del Inventario que compete a la
Oficina de Informática ya que se podrá saber que equipos son dados de baja y
cuáles son los que hacen falta para tener un stock adecuado en nuestro
inventario.
Con este trabajo de investigación se podrá optimizar el tiempo horas hombre y se

podrán atender una mayor cantidad de problemas que surjan en las diferentes
oficinas de la Municipalidad de Piura y que en verdad necesiten la atención de
Soporte Técnico dando soluciones rápidas y adecuadas a dichos problemas.
Justificación Administrativa
Este proyecto es una alternativa de solución al problema de Control y
Organización para el Mantenimiento de Equipos Informáticos, cuyo desarrollo
además de fortalecer el logro óptimo de los objetivos institucionales, agiliza las
actividades desarrolladas por el área en la cual nuestra aplicación web será
implementada.
Justificación Científica
El trabajo es desarrollado en base al método científico, que va desde la
observación del objeto de estudio hasta las conclusiones y recomendaciones. El
producto final alcanzado, será lo que justifique la investigación.
Justificación Institucional
Uno de los objetivos de la Municipalidad Provincial de Piura es mejorar la gestión
administrativa y propiciar la descentralización de sus unidades y dependencias,
mediante el uso de tecnologías de información. Para ello se implementará un
nuevo sistema de información y/o control (aplicación web) para satisfacer las
necesidades del usuario y puedan desarrollar sus actividades eficientemente.
Justificación Social

Aplicación Web
La implementación del sistema de información y/o control (aplicación web)

mejorará la administración de los recursos informáticos para ofrecer servicios de
calidad a la población y en consecuencia mejorar la imagen institucional del
Gobierno Regional de Piura.
Justificación Tecnológica
Como entes de investigación y aprendizaje obtendremos nuevos conocimientos y
experiencia como profesionales, manteniéndonos a la vanguardia de los
requerimientos de nuestro entorno y la adecuada capacitación en cuanto a nuevas
tecnologías de información se refiere. Puesto que una de las competencias
exclusivas de la Municipalidad Provincial de Piura es promover la modernización,
actualización e innovaciones tecnológicas.
2.4. LIMITACIONES DEL PROYECTO:
 El limitado acceso a información de los sistemas informáticos que pueden

servir de guía para el desarrollo de la presente investigación.
 El trabajo dinámico o poca disponibilidad del personal de Soporte Técnico

limitará la información que se pueda obtener de ellos para el desarrollo de la
presente aplicación web.
 Los escasos recursos tecnológicos que dispone el área de soporte técnico

para el desarrollo del presente proyecto.
 La aplicación web a desarrollar será independiente a la aplicación web

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

servirá de guía y/o modelo para la base de datos de nuestro sistema de control
(aplicación web) para Soporte Técnico.
2.5. MARCO REFERENCIAL CIENTIFICO:

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

informático que se encarga de registrar datos detallados de los equipos de
cómputo (inventario) y los mantenimientos que estos reciben, considerando
también la respectiva organización y monitoreo, así como los beneficios que
otorga.
Salcedo Untiveros, Richard Orlando (Piura – 2007), “Análisis, Diseño y

Desarrollo del Módulo Web para la Gestión y Control de Inventario de Bienes
de la Oficina de Control Patrimonial de la Dirección Regional de Salud Piura”,
presenta su tesis con la que obtuvo el Título Profesional de Ingeniero
Informático en la Universidad Nacional de Piura. Salcedo con este proyecto
de tesis busca gestionar y controlar el inventario de bienes de la Dirección
Regional de Salud Piura incluyendo los procesos de registro de bienes,
verificación del estado de los bienes, baja de bienes.
Relación: Esta tesis se toma en consideración porque implementa un

módulo web que presenta entornos de trabajo correspondientes a cada área
de acción por usuario, relacionada con la gestión y control de inventario, así
como las ventajas que este otorga.
 Antecedentes Nacionales:

Aplicación Web
Vega Bustamante, Rocío Olinda (Lima – 2009), “Análisis, diseño e

implementación de un sistema de administración de incidentes en atención al
cliente para una empresa de telecomunicaciones”, presenta su tesis con la
que obtuvo el Título Profesional de Ingeniero Informático en la Pontificia
Universidad Católica del Perú. Vega con este proyecto de investigación
busca monitorear el tiempo de atención de los casos que presente el cliente
en una empresa de telecomunicaciones, de allí que la presente tesis
presenta el análisis, desarrollo e implementación de un sistema de
administración de incidentes en Atención al Cliente para una empresa de
telecomunicaciones.
Relación: Esta tesis se toma en consideración porque implementa un

sistema de administración de incidentes que monitorea el tiempo de atención
de los casos que presente el cliente y de seguir la normativa establecida y
las ventajas que esto otorga.
Santillán Pinedo, Karla & Tornero Mendoza, Ludver (Trujillo – 2001),

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

centraliza la información de los equipos informáticos, para un mejor control
de almacén con los respectivos procesos que se llevan a cabo, para
finalmente con la información brindada sirva de apoyo para nuevas
adquisiciones.
 Antecedentes Internacionales:

Aplicación Web
Pesántez Huerta, Álvaro Eduardo (Guayaquil, Ecuador – 2007),

“Elaboración de un Plan de Mantenimiento Predictivo y Preventivo en
Función de la Criticidad de los Equipos del Proceso Productivo de una
Empresa Empacadora de Camarón”, presenta su tesis con la que obtuvo el
Título Profesional de Ingeniero Industrial en la Escuela Superior Politécnica
del Litoral. Pesantez con este trabajo de investigación busca realizar un plan
de mantenimiento predictivo y preventivo de los equipos, el cual contendrá el
detalle del mantenimiento recomendado por los fabricantes y los técnicos
internos y/o externos de la empresa; así como también el detalle de cada
equipo y cuáles serán las frecuencias de los diversos mantenimientos
preventivos establecidos.
Relación: Esta tesis se toma en consideración porque implementa un plan

de mantenimiento predictivo y preventivo enfocado a brindar una guía
confiable de los tipos y frecuencias de mantenimiento para los equipos, esta
guía servirá como modelo para desarrollar los módulos webs de
mantenimiento predictivo, preventivo y correctivo de la aplicación web a
desarrollar.
Espinoza Saavedra, Daniel (Valparaíso, Chile – 2004), “Estudio del

Sistema de Monitoreo y Registro de Inventarios de Compras y su Integración
Estratégica mediante el Control de Gestión”, presenta su tesis con la que
obtuvo el Grado de Magíster en Gestión mención Control en la Universidad
de Valparaíso. Espinoza con este proyecto de investigación busca presentar
las posibilidades que ofrece un modelo de control dentro de un sistema de
inventarios de compras mediante la aplicación de los conceptos
constructivos de un cuadro de mando.
Relación: Esta tesis se toma en cuenta porque nos proporciona información

importante sobre las posibilidades y riesgos de implementar un control de
gestión en un inventario de compras y los beneficios que este otorga.
2.6. MARCO TEORICO:

Aplicación Web
2.6.1. MUNICIPALIDAD PROVINCIAL DE PIURA:
 Misión, Visión y Objetivos de la Institución:
Misión
Gobernar, conducir y liderar el desarrollo de la provincia, gestionando y
promoviendo el desarrollo sostenible, integral y el bienestar humano, mediante
acciones de concertación institucional y de participación de la sociedad civil
organizada. [PEI – MPP]
Visión
La Municipalidad Provincial de Piura al 2014, aplica una gestión moderna,
eficiente y participativa, con creciente igualdad de oportunidades, sistema
distrital democrático, institucionalidad participativa, ámbitos urbano y rural
articulados, con hombres y mujeres emprendedoras y ciudades abiertas,
seguras, sostenibles, ordenadas, modernas y limpias. [PEI – MPP]
Objetivos
1) Conducir, promover y fomentar el desarrollo socio-económico integral,
sostenible y armónico, priorizando y planificando las necesidades del distrito y
provincia de Piura.
2) Promover el bienestar del ciudadano con la adecuada prestación de los
servicios públicos locales que satisfagan sus necesidades vitales de
salubridad, vivienda, abastecimiento, seguridad, cultura, recreación, transporte
y comunicaciones.
3) Representar política y organizacionalmente a los vecinos en el Gobierno
Local, mediante programas de participación comunal y el ejercicio del derecho
de petición.
4) El Ejercicio de la Función Conciliadora.
5) Desarrollar programas sociales básicos.
6) Promover el desarrollo económico local mediante el impulso a las pequeñas
y micro empresas (PYMES), de acuerdo a las normas y políticas regionales y
nacionales.
7) Brindar la infraestructura, apoyo, asesoramiento a los promotores y agentes
del desarrollo económico, facilitándoles el espacio físico para sus actividades
de acuerdo a la normatividad vigente. [ROF – MPP]

Aplicación Web
 Políticas Generales de la Institución:
OBJETIVOS ESTRATEGICOS
LINEAS POLITICAS OBJETIVO META
La Municipalidad Provincial de Piura es
Política N° 01 una corporación edil eficaz y eficiente que
Desarrollo Institucional resuelve el 100 % de sus operaciones de
manera moderna, ágil y dinámica.
La Municipalidad Provincial de Piura
cuenta con una Red de Participación
Ciudadana mediante la cual ha
organizado el 100 % de Juntas Vecinales
Política N° 02 dentro de las jurisdicciones de su
Desarrollo Social competencia.
cuenta con una Red de Desarrollo Social
que contribuye, concerta y monitorea el
100 % de los servicios de educación,
salud y trabajo.
Política N° 03 cuenta con un Sistema de Desarrollo
Desarrollo Económico y Económico y Financiero que le permite
Financiero incrementar sus recursos en un 5 %
anual.
La Municipalidad Provincial de Piura es la
Política N° 04 primera en el país que logra delimitar y
Organización Territorial adecuar integralmente el 100 % de su
territorio.
Cuadro N° 001: Política Institucionales

Fuente: PEI – MPP
 Actividades Principales de la Institución:
1) Planificar integralmente el desarrollo local y el ordenamiento territorial, en el

nivel provincial.
2) Promover permanentemente la coordinación estratégica de los planes
integrales de desarrollo de los distritos. Los planes referidos a la organización

Aplicación Web
del espacio físico y uso del suelo que emitan las municipalidades distritales
deberán sujetarse a los planes y las normas generales de la Municipalidad
Provincial de Piura.
3) Promover, apoyar y ejecutar proyectos de inversión y servicios públicos
municipales que presenten objetivamente externalidades o economías de
escala de ámbito provincial; para cuyo efecto suscribirá convenios con las
respectivas municipalidades distritales.
4) Emitir las normas técnicas generales, en materia de organización del
espacio físico y uso del suelo, así como sobre protección y conservación del
medio ambiente.
5) Proponer proyectos de ley, a través de iniciativas legislativas. [ROF – MPP]
 Organigrama de la Institución:
Toda empresa cuenta en forma implícita o explícita con cierto juego de

jerarquías y atribuciones asignadas a los miembros o componentes de la
misma. En consecuencia se puede establecer que la estructura organizativa
de una empresa es el esquema de jerarquización y división de las funciones
componentes de ella.
Jerarquizar es establecer líneas de autoridad (de arriba hacia abajo) a través

de los diversos niveles y delimitar la responsabilidad de cada empleado ante
solo un supervisor inmediato. Esto permite ubicar a las unidades
administrativas en relación con las que le son subordinadas en el proceso de
la autoridad. El valor de una jerarquía bien definida consiste en que reduce la
confusión respecto a quien da las órdenes y quien las obedece. Define como
se dividen, agrupan y coordinan formalmente las tareas en los puestos. [MPP]

Aplicación Web
Gráfico N° 001: Organigrama de la Municipalidad Provincial de Piura

Fuente: Municipalidad Provincial de Piura (MPP)

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

Soporte Técnico de la Oficina de Informática de la
24 Jesús Antonio Pino Chacón
Aplicación Web
12) Implementar la infraestructura de telecomunicaciones para el óptimo

funcionamiento de los sistemas informáticos. [ROF – MPP]
Metas
1) Facilitar el desarrollo de la Corporación Municipal mediante la
implementación de un Sistema de Comunicaciones y Tecnologías de
Información durante el presente año 2011 con un presupuesto de 30316.93
nuevos soles.
2) Gestionar y resolver el desarrollo de los medios eficientes de comunicación
simultánea entre las Juntas Vecinales y la Corporación Municipal durante el
presente año 2011 con un presupuesto de 9603.50 nuevos soles.
3) Proporcionar las herramientas tecnológicas que permitan una adecuada
comunicación y acceso a la información estadística y difusión de
convocatorias y logros de la Corporación Municipal durante el presente año
2011 con un presupuesto de 1240.50 nuevos soles.
4) Gestionar, programar, promover y resolver la implementación del gobierno
electrónico y adecuar el resultado progresivo de la organización territorial
durante le presente año 2011 con un presupuesto de 396.20 nuevos soles.
5) Diseñar procedimientos que simplifiquen mecanismos administrativos
durante el presente año 2011 con un presupuesto de 18441.61 nuevos soles.
[POI – MPP]
2.6.3. SOPORTE TECNICO:
 Descripción del Área de Negocio:
El Área de Negocio es Soporte Técnico, pertenece a la Oficina de Informática

y a su vez esta oficina pertenece a la Gerencia de Tecnologías y Sistemas de
Información, se encarga de dar respaldo a los equipos electrónicos y eléctricos
que se encuentran dentro de la Municipalidad de Piura y en sus Unidades
Orgánicas Externas.
Soporte Técnico, alberga equipos, materiales, herramientas y repuestos para

que los usuarios o trabajadores de la Municipalidad de Piura soliciten servicios
de atención para solucionar problemas de hardware y software de los equipos
electrónicos e informáticos, problemas de equipos eléctricos y problemas de
equipos telefónicos.

Aplicación Web
Soporte Técnico soluciona problemas de hardware, software, eléctricos,

electrónicos, telefónicos y de redes de la mayoría de equipos que se
encuentran en la municipalidad, se limita a estas actividades y no a
administrar las políticas de seguridad y privacidad de la red de trabajo o
dominio.
Dada la diversidad de incidentes y solicitudes que pueden producirse en ST

resultan difíciles que las atenciones sean de manera oportuna dado que
muchas veces estos problemas pueden ser solucionados de manera fácil por
el usuario o trabajador de la municipalidad de Piura. [EL AUTOR]
2.6.4. SISTEMA DE CONTROL:
 ¿QUÉ ES UN SISTEMA DE CONTROL?
Según Alvarez Brotons (2004):
Un sistema dinámico puede definirse conceptualmente como un ente que recibe

unas acciones externas o variables de entrada, y cuya respuesta a estas acciones
externas son las denominadas variables de salida.
Las acciones externas al sistema se dividen en dos grupos, variables de control,

que se pueden manipular, y perturbaciones sobre las que no es posible ningún
tipo de control. El gráfico 2 ilustra de un modo conceptual el funcionamiento de un
sistema.
Gráfico N° 002: Esquema general de un sistema

Fuente: Alvarez Brotons

Aplicación Web
Dentro de los sistemas se encuentra el concepto de sistema de control. Un

sistema de control es un tipo de sistema que se caracteriza por la presencia de
una serie de elementos que permiten influir en el funcionamiento del sistema. La
finalidad de un sistema de control es conseguir, mediante la manipulación de las
variables de control, un dominio sobre las variables de salida, de modo que estas
alcancen unos valores prefijados (consigna).
Un sistema de control ideal debe ser capaz de conseguir su objetivo cumpliendo

los siguientes requisitos:
1. Garantizar la estabilidad y, particularmente, ser robusto frente a

perturbaciones y errores en los modelos.
2. Ser tan eficiente como sea posible, según un criterio preestablecido.
Normalmente este criterio consiste en que la acción de control sobre las
variables de entrada sea realizable, evitando comportamientos bruscos e
irreales.
3. Ser fácilmente implementable y cómodo de operar en tiempo real con
ayuda de un ordenador.
Los elementos básicos que forman parte de un sistema de control y permiten su

manipulación son los siguientes:
- Sensores. Permiten conocer los valores de las variables medidas del sistema.
- Controlador. Utilizando los valores determinados por los sensores y la consigna
impuesta, calcula la acción que debe aplicarse para modificar las variables de
control en base a cierta estrategia.
- Actuador. Es el mecanismo que ejecuta la acción calculada por el controlador y
que modifica las variables de control.
El gráfico 3 ilustra el esquema de funcionamiento de un sistema de control

genérico.

Aplicación Web
Gráfico N° 003: Esquema general de un sistema de control

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

existen varias definiciones al respecto, un patrón de diseño es una solución de
calidad para un problema recurrente de diseño. Pero no son aplicables
únicamente en el campo computacional, también existen patrones para varias
actividades de la vida cotidiana, aunque con algunas diferencias pero tienen el
mismo propósito que en el ámbito computacional, proporcionar una base para
poder realizar una actividad, mejorando la calidad del producto que esa actividad
de como resultado [Freeman, 2004].

Aplicación Web
Hay patrones que abarcan las distintas etapas del desarrollo; desde el análisis
hasta el diseño y desde la arquitectura hasta la implementación. En el caso de los
patrones computacionales un software estructurado, modulado posee una mejor
calidad y es más sencillo corregir errores, implementar mejoras y actualizaciones,
ya que un software que posee algún patrón de diseño es más sencillo de
modificar que un software que no posee en absoluto un patrón. Pero ¿Cómo se
debe escoger el patrón adecuado?, esta es una pregunta un poco difícil de
responder ya que la mayoría de las actividades de desarrollo o producción no se
ajustan perfectamente a un patrón definido, por eso es importante llevar acabo un
análisis para poder visualizar cual será el patrón que mejor se ajuste a las
necesidades de desarrollo. En sí "un patrón de diseño puede verse como una
plantilla que puede ser aplicada en muchas situaciones diferentes" [Gamma,
1995], para dar una buena solución.
Los patrones se descubren como una forma indispensable de enfrentarse a la

programación a raíz del libro "Design Patterns - Elements of Reusable Software"
de Erich Gamma, Richard Helm, Ralph Jonson y John Vlissides, a partir de
entonces los patrones de diseño que aparecen en ese libro son conocidos como
los patrones de la pandilla de los cuatro (GoF, gang of four), y comienzan a
desarrollarse variaciones y nuevos patrones, en poco tiempo se multiplicaron por
100 y no se limitaban a patrones de diseño sino que cubrían todo los que se
entiende por ingeniería del software (desde el análisis hasta la implementación)
[Gamma, 1995].
 Elementos esenciales
En general un patrón tiene cuatro elementos esenciales:
El nombre del patrón: que se utiliza para describir un problema de diseño, sus
soluciones y sus consecuencias, en una palabra o dos. Este nombre ayuda a que
sea más sencillo de identificarlo, al hablar o escribir de él e incluso puede dar una
idea general o una descripción de dicho patrón.
El problema: describe cuando aplicar el patrón, también puede incluir detalles

específicos que se deben cumplir o problemas un poco más detallados, los cuales
en conjunto engloban el problema central a solucionar.

Aplicación Web
La solución: describe los elementos que forman el diseño, sus relaciones, sus
responsabilidades y sus colaboraciones. La solución no describe un diseño o
implementación en particular ya que un patrón de diseño puede verse como una
plantilla que se aplica a un problema específico.
Las consecuencias: son los resultados y desventajas de haber aplicado el

patrón. Estas consecuencias implican un impacto en las características del
sistema como: flexibilidad, portabilidad y extensión. Además de que ayudan a
medir el desempeño del sistema.
 Clasificación
El grupo de GoF clasificó los patrones en 3 grandes categorías basadas en su

propósito: creacionales, estructurales y de comportamiento [Gamma, 1995].
Creacionales: tratan con las formas de crear instancias de objetos. El objetivo de

estos patrones es de abstraer el proceso de instanciación y ocultar los detalles de
cómo los objetos son creados o inicializados.
Estructurales: Los patrones estructurales describen como las clases y objetos

pueden ser combinados para formar grandes estructuras y proporcionar nuevas
funcionalidades. Estos objetos adicionados pueden ser incluso objetos simples u
objetos compuestos.
Comportamiento: Los patrones de comportamiento ayudan a definir la

comunicación e iteración entre los objetos de un sistema. El propósito de este
patrón es reducir el acoplamiento entre los objetos.
 Patrón de diseño Model View Controller (MVC)
Una vez establecidas las bases de los patrones de diseño, se puede ya comenzar
a hablar más del patrón que se utilizó durante este trabajo: el patrón MVC. Estas
son las siglas de Model View Controller, en español Modelo Vista Controlador.
Esto también se ve reflejado en que cada una de estas palabras representa cada
uno de los 3 componentes del patrón MVC. Cada parte juega un rol fundamental
para la completa integración del sistema.

Aplicación Web
 Definición e historia
"El propósito de este patrón es simplificar la implementación de aplicaciones de

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

usuario, ya sea en un archivo de texto normal o en una página web (HTML o JSP)
que el navegador pueda desplegar. En sí el propósito de la vista es convertir los
datos para que al usuario le sean significativos y los pueda interpretar fácilmente.
La vista no debe trabajar directamente con los parámetros del request, debe
delegar esta responsabilidad al controlador.
Controlador: es la parte lógica que es responsable del procesamiento y

comportamiento de acuerdo a las peticiones (requests) del usuario, construyendo
Aplicación Web
un modelo apropiado, y pasándolo a la vista para su correcta visualización. En el

caso de una aplicación web Java en la mayoría de los casos el controlador es
implementado por un servlet.
 Tipos de patrones MVC
Actualmente existen dos tipos de patrón MVC:
Servidor Web/Aplicación
Gráfico N° 004: MVC de arquitectura Tipo 1

Fuente: Walls, 2005
Como se muestra en el Gráfico 4 en el Tipo 1 de MVC las páginas JSP están en el

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

Fuente: Walls, 2005

Aplicación Web
En el modelo de Tipo 2 de MVC, que se aprecia en el Gráfico 5, se puede

observar que ya existe una clara separación entre el controlador y la vista, ya que
ahora es directamente el controlador quien recibe la petición, prepara el modelo y
lo transforma para que sea desplegado en la vista. Este tipo de arquitectura MVC
es el que se utiliza para aplicaciones más complejas, ya que para una aplicación
sencilla puede utilizarse el Tipo 1. La tecnología JSP no es la única que se puede
emplear para las vistas, existen otro tipo de tecnologías que pueden servir como
vistas.
 Frameworks
Un framework es un término utilizado en la computación en general, para referirse

a un conjunto de bibliotecas, utilizadas para implementar la estructura estándar de
una aplicación. Todo esto se realiza con el propósito de promover la reutilización
de código, con el fin de ahorrarle trabajo al desarrollador al no tener que rescribir
ese código para cada nueva aplicación que desee crear. Existen diferentes
frameworks para diferentes propósitos, algunos orientados al desarrollo de
aplicaciones web, otros para desarrollar aplicaciones multiplataforma, para un
sistema operativo o lenguaje de programación en específico, entre otros.
Según Gamma, el framework determina la arquitectura de una aplicación

[Gamma, 1995]. Este es un buen enfoque, ya que el framework se encarga de
definir la estructura general, sus particiones en clases y objetos, las
responsabilidades clave, así como la colaboración entre dichas clases y objetos.
Todos estos parámetros son definidos por el framework, evitando que el usuario
tenga que definirlos y se pueda enfocar en cosas específicas de su aplicación.
"El framework captura las decisiones de diseño que son comunes a su dominio de
aplicación" [Gamma, 1995]. Un framework no sólo promueve la reutilización de
código sino también la reutilización de diseño.
Un framework ayuda a que se desarrolle una aplicación de una manera más

rápida, ya que se no pierde tiempo en algunos detalles de diseño que muchas
veces quitan más tiempo del que tomo construir en sí la lógica de la aplicación.
Además las aplicaciones que se construyen tienen estructuras similares, son más
fáciles de mantener y consistentes para los usuarios. Pero esto tiene como
consecuencia una mínima perdida de libertad en las cuestiones de diseño.

Aplicación Web
En algunas ocasiones un desarrollador tiene algunas dificultades para diseñar una

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

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

cambio un patrón de diseño puede ser aplicado a cualquier lenguaje de
programación, pero se tiene que reescribir desde cero.
Los patrones de diseño son elementos arquitectónicos más pequeños que

los frameworks: un solo framework contiene varios patrones de diseño, pero
jamás es al contrario.
Los patrones de diseño son menos especializados que los frameworks:

existen frameworks con un dominio específico, además los patrones son un poco
más generales debido a que pueden ser utilizados en un mayor número de
aplicaciones de varios tipos.
 Frameworks para aplicaciones web
Actualmente existen algunos frameworks para desarrollar aplicaciones web, que

es de las ramas más importantes en las que se usan los frameworks. La mayoría
de ellos utilizan el patrón de diseño MVC del cual se habló previamente. Todos los
frameworks tienen características especiales que los hacen únicos para sobresalir
y poder seguir en el mercado, además de poseer las siguientes características
comunes [Johnson, 2003]:
• Utilizan un solo servlet que tiene la función de controlador, para toda la

aplicación o gran parte de ella. Se configura el deployment descriptor "web.xml"
para que todas las URL's tengan que pasar forzosamente por dicho servlet.
Una configuración, generalmente escrita en un archivo XML, en donde se le
indicará al servlet controlador, a través de propiedades, a quien delegar la
responsabilidad de atender la petición entrante. Algunas veces esas propiedades
están indicadas de acuerdo a los URL's y de acuerdo al URL entrante es como se
delega la responsabilidad.
• Las vistas pueden tener nombres claves, sin necesidad que exista una relación
con el nombre del archivo de la vista. El framework se encarga de realizar dicha
conversión para poder obtener el nombre de la vista que se tiene que cargar para
que sea desplegada. La implementación de una vista con un nombre en particular
puede cambiar sin afectar código del controlador.

Aplicación Web
Cuando se va a desarrollar una aplicación web, el desarrollador se debe fijar en si

desea realizar una aplicación extremadamente sencilla o si quiere desarrollar una
verdadera aplicación web, que tendrá actualizaciones, correcciones y mejoras a
futuro. Para esto es recomendable que se elija un framework de aplicación web
que utilice el patrón web MVC. Con el fin de que se pueda hacer la separación
entre los 3 elementos principales y pueda aprovechar todas las ventajas que
brinda este patrón de diseño. Para poder aprovechar también las ventajas
adicionales que brinda el framework para la integración con otras herramientas u
otros servicios.
A continuación se enlistan algunos de los frameworks para aplicaciones web más

populares: Struts, WebWork, Maverick y Spring, el framework sobre el cual se
basa esta tesis, será analizado con mayor detalle más adelante en este
documento. Este listado y análisis sencillo de cada uno de estos frameworks se
da con la razón de poder saber cuales son los frameworks contra los que compite
Spring, dentro del mismo ámbito, así como sus características principales,
ventajas y desventajas.
 Struts
Struts es uno de los frameworks MVC más utilizados, ya que fue uno de los
pioneros en el campo, fue creado por Craig McClanahan, creador del famoso
motor servlet Tomcat, ambos son distribuidos por Apache. Este framework fue
lanzado a mediados del año 2000, y a partir de esta fecha comenzó a tener
popularidad, y en la actualidad existen algunos componentes extra que se
adaptan a Struts, lo que le da un mayor campo de acción. Struts es open source,
por lo que no requiere licencia para su uso [Johnson, 2003].
Además cumple una de las funcionalidades básicas que se mencionaron acerca

de los frameworks para aplicaciones web, ya que implementa un solo controlador
(ActionServlet) que evalúa las peticiones del usuario mediante un archivo
configurable (struts-config.xml) para poder dirigirlas a un action que procesa el
request. El lenguaje de programación que utiliza es Java, así como Java Beans
como modelo.
Algunas de las ventajas que Struts brinda son: que existe un variado número de
trabajos y proyectos ya hechos lo que brinda un mayor número de ejemplos para

Aplicación Web
poder tomar un punto de partida y de referencia; otra ventaja es que brinda

librerías de tags para HTML bastante útiles. Entre las desventajas de framework
se puede observar que muchas veces puede ser difícil trabajar con los
ActionForms, además de que el proyecto posiblemente desaparezca en los años
venideros, otra de las desventajas de Struts es que muy ligado con la tecnología
JSP, por lo que muchas veces se dificulta integrarlo con alguna otra tecnología
para las vistas.
 Maverick
Este es otro framework MVC open source que existe en el mercado, pero a
diferencia de los demás este no cuenta con sus propias librerías de tags. Sin
embargo cumple con las funcionalidades típicas mencionadas, como el de tener
un solo servlet controlador central como punto de entrada, el cual lleva el nombre
de Dispatcher, que está definido en el Deployment Descriptor de la aplicación web
(web.xml). Maverick cuenta con un archivo XML en el que se guarda toda la
configuración del mismo (maverick.xml). Una característica de Maverick es que
únicamente acepta un solo controlador central y un archivo de configuración por
aplicación web, lo que muchas veces al desarrollar aplicaciones más grandes y
complejas se puede volver confuso y difícil de configurar. [Johnson, 2003]
Maverick es un framework mucho más configurable que Struts, lo que brinda

cierta flexibilidad, también incluye varias clases para poder extender y cambiar el
flujo del trabajo o workflow en Inglés. Maverick es usualmente usado para crear
nuevos controladores que sean capaces de procesar nuevas peticiones. Los
controladores son Java Beans, y el framework pone de manera transparente las
propiedades de los beans.
Una característica interesante de Maverick es el básico y fácil uso de la

funcionalidad del dispatcher. También es multiplataforma ya que ha sido adaptado
para los lenguajes .NET y PHP.
 WebWork
Este es un framework más reciente ya que fue lanzado a mediados del año 2002,
una de las personas que ha trabajado en este proyecto fue Rickard Oberg, quien
ha participado en proyectos como JBoss, entre otros. "WebWork, a pesar de su
Aplicación Web
nombre, no es puramente un framework para aplicaciones web. Adopta un

acercamiento práctico que minimiza la dependencia del código de la aplicación de
los conceptos web."[Johnson, 2003].
El framework WebWork está basado en el patrón de diseño de Comandos o

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

Spring propone estructurar toda una aplicación de una manera consistente y
productiva, conjuntando lo mejor de cada uno de los frameworks single-tier para
crear una arquitectura coherente. En sí Spring ha surgido como una solución para
poder disfrutar de los beneficios clave de J2EE, mientras que minimiza la
complejidad encontrada en el código de la aplicación. [Johnson, 2005]
Spring esta basado en la filosofía de que un framework debe proveer una guía
hacia una buena práctica, es decir debe hacer la cosa correcta sencilla de hacer.
Mezclando la correcta combinación de flexibilidad y restricción, la cual es la clave
en el buen diseño de un framework.

Aplicación Web
Spring también cuenta con algunas de las características generales de los

frameworks web, ya que cuenta con un módulo para poder desarrollar
aplicaciones web de manera sencilla, utilizando el patrón de diseño MVC antes
mencionado. Contando con un controlador central (DispatcherServlet), además de
la capacidad de tener varios controladores secundarios para el procesamiento de
cada una de las peticiones.
También se basa en el diseño de las clases extendiendo o implementando

interfaces, lo cual es un mejor diseño orientado a objetos, ya que promueve la
reutilización de código. Además Spring cuenta con algunos tags para las
diferentes tecnologías para vista que existen. Las cuales tienen funciones
diferentes como vincular formularios, validación, despliegue de información, entre
otras.
Uno de los aspectos clave y ventajas de Spring, es que cuenta con una
arquitectura modularizada, y se pueden utilizar cada uno de estos módulos de
manera independiente. Cada uno esta enfocado en una tarea específica, y
algunos de ellos son para la integración con alguna herramienta o incluso cuenta
con la posibilidad de integrase con los otros frameworks mencionados
anteriormente. Esto con el propósito de proponer la filosofía de "no intentar
reinventar la rueda", la cual quiere decir que si ya existe en el mercado una
herramienta que realice una tarea de manera eficiente en un ámbito o área en
particular se debe conjuntar con Spring para llevar a cabo un mejor desempeño y
poder sacar así un mejor resultado y una aplicación de mayor calidad.
En conclusión cada framework tiene sus ventajas y desventajas, escoger uno es

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

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

Según OSIATIS S.A. V2.0:
 Visión General
La Gestión de Incidentes tiene como objetivo resolver cualquier incidente que

cause una interrupción en el servicio de la manera más rápida y eficaz posible.
La Gestión de Incidentes no debe confundirse con la Gestión de Problemas, pues
a diferencia de esta última, no se preocupa de encontrar y analizar las causas
subyacentes a un determinado incidente sino exclusivamente a restaurar el
servicio. Sin embargo, es obvio, que existe una fuerte interrelación entre ambas.
Las propiedades y funcionalidades de la Gestión de Incidentes se resumen
sucintamente en el siguiente gráfico:
Gráfico N° 006: Gestión de Incidentes

Fuente: OSIATIS S.A. V2.0

Aplicación Web
 Introducción y Objetivos
Los objetivos principales de la Gestión de Incidentes son:
 Detectar cualquiera alteración en los servicios TI (Tecnologías de

Información).
 Registrar y clasificar estas alteraciones.
 Asignar el personal encargado de restaurar el servicio según se define
en el SLA (Acuerdo de Nivel de Servicio) correspondiente.
Esta actividad requiere un estrecho contacto con los usuarios, por lo que el Centro
de Servicios (Service Desk) debe jugar un papel esencial en el mismo.
El siguiente diagrama resume el proceso de gestión de incidentes:
Gráfico N° 007: Proceso de Gestión de Incidentes (resumen)

Aunque el concepto de incidencia se asocia naturalmente con cualquier

malfuncionamiento de los sistemas de hardware y software según el libro de
Soporte del Servicio de ITIL (Bibliotecas de Infraestructura de las Tecnologías de
Información) un incidente es:
“Cualquier evento que no forma parte de la operación estándar de un servicio y

que causa, o puede causar, una interrupción o una reducción de calidad del
mismo”.
Por lo que casi cualquier llamada al Centro de Servicios puede clasificarse como
un incidente, lo que incluye a las Peticiones de Servicio tales como concesión de

Aplicación Web
nuevas licencias, cambio de información de acceso, etc. siempre que estos

servicios se consideren estándar.
Cualquier cambio que requiera una modificación de la infraestructura no se

considera un servicio estándar y requiere el inicio de una Petición de Cambio
(RFC) que debe ser tratada según los principios de la Gestión de Cambios.
Los principales beneficios de una correcta Gestión de Incidentes incluyen:
 Mejorar la productividad de los usuarios.

 Cumplimiento de los niveles de servicio acordados en el SLA.
 Mayor control de los procesos y monitorización del servicio.
 Optimización de los recursos disponibles.
 Una CMDB (Base de Datos de la Gestión de Configuraciones) más
precisa pues se registran los incidentes en relación con los elementos
de configuración.
 Y principalmente: mejora la satisfacción general de clientes y usuarios.
Por otro lado una incorrecta Gestión de Incidentes puede acarrear efectos
adversos tales como:
 Reducción de los niveles de servicio.

 Se dilapidan valiosos recursos: demasiada gente o gente del nivel
inadecuado trabajando concurrentemente en la resolución del
incidente.
 Se pierde valiosa información sobre las causas y efectos de los
incidentes para futuras reestructuraciones y evoluciones.
 Se crean clientes y usuarios insatisfechos por la mala y/o lenta gestión
de sus incidentes.
Las principales dificultades a la hora de implementar la Gestión de Incidentes se

resumen en:
 No se siguen los procedimientos previstos y se resuelven las

incidencias sin registrarlas o se escalan innecesariamente y/o
omitiendo los protocolos preestablecidos.

Aplicación Web
 No existe un margen operativo que permita gestionar los “picos” de

incidencias por lo que éstas no se registran adecuadamente e impiden
la correcta operación de los protocolos de clasificación y escalado.
 No están bien definidos los niveles de calidad de servicio ni los
productos soportados. Lo que puede provocar que se procesen
peticiones que no se incluían en los servicios previamente acordados
con el cliente.
 Clasificación del Incidente
Es moneda frecuente que existan múltiples incidencias concurrentes por lo que es

necesario determinar un nivel de prioridad para la resolución de las mismas.
El nivel de prioridad se basa esencialmente en dos parámetros:
 Impacto: determina la importancia del incidente dependiendo de cómo

éste afecta a los procesos de negocio y/o del número de usuarios
afectados.
 Urgencia: depende del tiempo máximo de demora que acepte el cliente
para la resolución del incidente y/o el nivel de servicio acordado en el SLA.
También se deben tener en cuenta factores auxiliares tales como el tiempo de

resolución esperado y los recursos necesarios: los incidentes “sencillos” se
tramitarán cuanto antes.
Dependiendo de la prioridad se asignarán los recursos necesarios para la

resolución del incidente.
La prioridad del incidente puede cambiar durante su ciclo de vida. Por ejemplo, se
pueden encontrar soluciones temporales que restauren aceptablemente los
niveles de servicio y que permitan retrasar el cierre del incidente sin graves
repercusiones.
Es conveniente establecer un protocolo para determinar, en primera instancia, la

prioridad del incidente. El siguiente diagrama nos muestra un posible “diagrama
de prioridades” en función de la urgencia e impacto del incidente:

Aplicación Web
Gráfico N° 008: Diagrama de Prioridades Del Incidente

 Escalado y Soporte
Es frecuente que el Centro de Servicios no se vea capaz de resolver en primera

instancia un incidente y para ello deba recurrir a un especialista o a algún superior
que pueda tomar decisiones que se escapan de su responsabilidad. A este
proceso se le denomina escalado.
Básicamente hay dos tipos diferentes de escalado:
 Escalado funcional: Se requiere el apoyo de un especialista de más alto

nivel para resolver el problema.
 Escalado jerárquico: Debemos acudir a un responsable de mayor
autoridad para tomar decisiones que se escapen de las atribuciones
asignadas a ese nivel, como, por ejemplo, asignar más recursos para la
resolución de un incidente específico.
El proceso de escalado puede resumirse gráficamente* como sigue:

Aplicación Web
* El escalado puede incluir más niveles en grandes organizaciones, o por el contrario, integrar diferentes
niveles en el caso de PYMES
Gráfico N° 009: Proceso de Escalado de Incidentes
 Proceso
El siguiente diagrama muestra los procesos implicados en la correcta Gestión de

Incidentes:

Aplicación Web
Gráfico N° 010: Procesos implicados en la Gestión de Incidentes

2.6.7. GESTIÓN DE PROBLEMAS:
Según OSIATIS S.A. V2.0:
 Visión General
Las funciones principales de la Gestión de Problemas son:
o Investigar las causas subyacentes a toda alteración, real o potencial, del

servicio TI.
o Determinar posibles soluciones a las mismas.
o Proponer las peticiones de cambio (RFC) necesarias para restablecer la
calidad del servicio.
o Realizar Revisiones Post Implementación (PIR) para asegurar que los
cambios han surtido los efectos buscados sin crear problemas de carácter
secundario.
La Gestión de Problemas puede ser:
Reactiva: Analiza los incidentes ocurridos para descubrir su causa y propone

soluciones a los mismos.

Aplicación Web
Proactiva: Monitoriza la calidad de la infraestructura TI y analiza su configuración

con el objetivo de prevenir incidentes incluso antes de que estos ocurran.
Las interacciones y funcionalidades de la Gestión de Problemas se resumen

sucintamente en el siguiente gráfico:
Gráfico N° 011: Interacciones y Funcionalidades de la Gestión de Problemas

 Introducción y Objetivos
Como se explicó en la sección de Gestión de Incidentes, esta última tiene como

exclusivo objetivo el restablecer lo más rápidamente la calidad del servicio y no el
determinar cuáles han sido los orígenes y causas del mismo.

Aplicación Web
Cuando algún tipo de incidente se convierte en recurrente o tiene un fuerte

impacto en la infraestructura TI es la función de la Gestión de Problemas el
determinar sus causas y encontrar posibles soluciones.
Cabe diferenciar entre:
Problema: causa subyacente, aún no identificada, de una serie de incidentes o un

incidente aislado de importancia significativa.
Error conocido: Un problema se transforma en un error conocido cuando se han

determinado sus causas.
Entre las funciones principales de la Gestión de Problemas figuran:
o Identificar, registrar y clasificar los problemas.

o Dar soporte a la Gestión de Incidentes proporcionando información y
soluciones temporales o parches.
o Analizar y determinar las causas de los problemas y proponer soluciones.
o Elevar RFCs a la Gestión de Cambios para llevar a cabo los cambios
necesarios en la infraestructura TI.
o Realizar un seguimiento post-implementación de todos los cambios para
asegurar su correcto funcionamiento.
o Realizar informes que documenten no sólo los orígenes y soluciones a un
problema sino que también sirvan de soporte a la estructura TI en su
conjunto.
o Analizar tendencias para prevenir incidentes potenciales.
Los principales beneficios de una correcta Gestión de Problemas:
o Un aumento de la calidad general de los servicios TI.

o Se minimiza el número de incidentes.
o Los incidentes se solucionan más rápidamente y, generalmente, en la
primera línea de soporte TI ahorrando recursos e innecesarios escalados.
o La documentación desarrollada es de gran utilidad para la Gestión de la
Capacidad, Disponibilidad y Niveles de Servicio.

Aplicación Web
Las principales dificultades a la hora de implementar la Gestión de Problemas se

resumen en:
o Establecer una estrecha colaboración entre la Gestión de Incidentes y la

de Problemas. Sin ésta la Gestión de Incidentes no dispondrá de toda la
información necesaria para la rápida solución de los incidentes y la
Gestión de Problemas carecerá de la información necesaria para
determinar, clasificar y resolver los problemas.
o Mantener actualizadas las bases de datos asociadas requiere un
compromiso por parte de todos los agentes implicados que
frecuentemente requiere un seguimiento cercano de los responsables de
la infraestructura TI.
o Aumento de los costes por la contratación de personal especializado,
aunque estos se vean sobradamente compensados por los beneficios
derivados.
 Proceso
Las principales actividades de la Gestión de Problemas son:
Control de Problemas: se encarga de registrar y clasificar los problemas para

determinar sus causas y convertirlos en errores conocidos.
Control de Errores: registra los errores conocidos y propone soluciones a los

mismos mediante RFCs que son enviadas a la Gestión de Cambios. Asimismo
efectúa la Revisión Post Implementación de los mismos en estrecha colaboración
con la Gestión de Cambios.
Y cuando la estructura de la organización lo permite, desarrollar una Gestión de

Problemas Proactiva que ayude a detectar problemas incluso antes de que estos
se manifiesten provocando un deterioro en la calidad del servicio.
El siguiente diagrama muestra los procesos implicados en la correcta Gestión de

Problemas:

Aplicación Web
Gráfico N° 012: Procesos Implicados en la Gestión de Problemas

 Proceso - Control de Problemas
El principal objetivo del Control de Problemas es conseguir que estos se

conviertan en Errores Conocidos para que el Control de Errores pueda proponer
las soluciones correspondientes.
Gráfico N° 013: Control de Problemas


Aplicación Web
El Control de Problemas se compone en esencia de tres fases:
1. Identificación y Registro
Una de las tareas principales de la Gestión de Problemas es identificar los

mismos. Las principales fuentes de información utilizadas son:
o La base de datos de Incidentes: en principio cualquier incidente del que

no se conocen sus causas y que se ha cerrado mediante algún tipo de
solución temporal es potencialmente un problema. Sin embargo, se habrá
de analizar si este incidente es aislado o su impacto en la estructura TI
antes de elevarlo a la categoría de problema.
o Análisis de la infraestructura TI: en colaboración con la Gestión de
Disponibilidad y de Capacidad, la Gestión de Problemas debe analizar los
diferentes procesos y determinar en qué aspectos se debe reforzar los
sistemas y estructuras TI para evitar futuros problemas.
o Deterioro de los Niveles de Servicio: el descenso del rendimiento puede
ser una indicación de la existencia de problemas subyacentes que no se
hayan manifestado de forma explícita como incidentes.
Todas las áreas de la infraestructura TI deben colaborar con la Gestión de

Problemas para identificar problemas reales y potenciales informando a ésta de
cualquier síntoma que pueda ser señal de un deterioro en el servicio TI.
El registro de problemas es, en principio, similar al de los incidentes aunque el

énfasis debe hacerse no en los detalles específicos de los incidentes asociados
sino más bien en su naturaleza y posible impacto.
El registro debe incorporar, entre otra, información sobre:
o Los CIs implicados.

o Causas del problema.
o Síntomas asociados.
o Soluciones temporales.
o Servicios involucrados.
o Niveles de prioridad, urgencia e impacto.

Aplicación Web
o Estado: activo, error conocido, cerrado.

2. Clasificación y Asignación de Recursos
La clasificación del problema engloba desde las características generales de éste,

tales como si es un problema de hardware o software, que áreas funcionales se
ven afectadas y detalles sobre los diferentes elementos de configuración (CIs)
involucrados en el mismo.
Un factor esencial es la determinación de la prioridad del problema, que al igual

que en el caso de los incidentes, se determina tanto a partir de la urgencia
(demora aceptable para la solución del problema) como de su impacto (grado de
deterioro de la calidad del servicio).
Al igual que en la Gestión de Incidentes la prioridad puede cambiar en el curso del

ciclo de vida del problema, por ejemplo, si se encuentra una solución temporal al
mismo que reduce considerablemente su impacto.
Una vez clasificado y determinada su prioridad se deben de asignar los recursos

necesarios para su solución. Estos recursos deben ser suficientes para asegurar
que los problemas asociados son tratados eficazmente y así minimizar su impacto
en la infraestructura TI.
3. Análisis y Diagnóstico: Error conocido
Los objetivos principales del proceso de análisis son:
o Determinar las causas del problema.

o Proporcionar soluciones temporales a la Gestión de Incidentes para
minimizar el impacto del problema hasta que se implemente los cambios
necesarios que lo resuelvan definitivamente.
Es esencial tener en cuenta que no siempre el origen del problema es un error de

hardware o software. Es moneda frecuente que el problema este causado por:
o Errores de procedimiento.
o Documentación incorrecta.

Aplicación Web
o Falta de coordinación entre diferentes áreas.

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

es responsabilidad del Control de Errores el registro del mismo como error
conocido.
Gráfico N° 014: Control de Errores


Aplicación Web
 Identificación y Registro de errores
El registro de los errores conocidos es de vital importancia para la Gestión de

Incidentes pues debe llevar asociado, siempre que esto sea posible, algún tipo de
solución temporal que permita minimizar el impacto de los incidentes asociados.
 Análisis y Solución
Se deben investigar diferentes soluciones para el error evaluando en cada

momento:
o El posible impacto de las mismas en la infraestructura TI.

o Los costes asociados.
o Sus consecuencias sobre los SLAs.
En algunos casos, en los que el impacto del problema puede tener consecuencias
graves en la calidad del servicio, pueden emitirse una RFC de emergencia para su
procesamiento urgente por la Gestión de Cambios.
Una vez determinada la solución óptima al problema y antes de elevar una RFC a
la Gestión de Cambios han de tenerse en cuenta las siguientes consideraciones:
o ¿Es conveniente demorar la solución? Ya sea porque se prevén cambios

significativos en la infraestructura TI a corto plazo o por el escaso impacto
del problema en cuestión.
o ¿Es la solución temporal aportada suficiente para mantener unos niveles
de calidad de servicios aceptable?
o ¿Los beneficios justifican los costes asociados?
Sea cual sea la respuesta, todo la información sobre el error y su solución se

registrará en las bases de datos asociadas. En el caso en el que se considere que
el problema necesita ser solucionado se emitirá una RFC. Será responsabilidad
de la Gestión de Cambios la implementación de los cambios de infraestructura
propuestos.

Aplicación Web
 Revisión Post Implementación y Cierre
Antes de dar el problema por resuelto y cambiar su estado a “cerrado” se debe

analizar el resultado de la implementación de la RFC elevado a la Gestión de
Cambios (PIR).
Si los resultados de esta PIR son los deseados y se pueden cerrar todos los
incidentes relacionados con este problema se considera concluido el proceso y se
emiten los informes correspondientes.
2.6.8. METODOLOGIA DE DESARROLLO:
Estas son más que todo un "conjunto de procedimientos, técnicas y ayudas a la

documentación para el desarrollo de productos software. Una metodología incluye
la tarea construir modelo conceptual de datos. Para realizarlo, define un
procedimiento y da a elegir entre una serie de técnicas" [URJC 2006]. Entre las
más conocidas podemos mencionar las siguientes:
Gráfico N° 015: Metodologías de Desarrollo de Software

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

metodologías de desarrollo de software existentes en la actualidad, entre las
principales tenemos a:
 RUP (Rational Unified Process).

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

• Arquitectura del Ciclo de Vida
• Capacidad Operacional Inicial

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

Aplicación Web
Gráfico N° 016: Dos Dimensiones de RUP

Fuente: Introducción a Rational Unified Process (RUP) - Patricio Letelier 2000
RUP define nueve actividades a realizar en cada fase del proyecto:

1. Modelado del negocio.
2. Análisis de requisitos.
3. Análisis y diseño.
4. Implementación.
5. Test.
6. Distribución.
7. Gestión de configuración y cambios
8. Gestión del proyecto.
9. Gestión del entorno.
Pero por otra parte también posee elementos o Workflows de apoyo entre los
cuales tenemos [Patricio Letelier 2000]:
 Environment (Entorno).
 Project Management (Gestión del Proyecto).
 Configuration & Change Management (Gestión de Configuración y
Cambios).
Artefactos:
 Resultado parcial o final que es producido y usado durante el proyecto.
Son las entradas y salidas de las actividades.
 Un artefacto puede ser un documento, un modelo o un elemento de
modelo.

Aplicación Web
 Conjuntos de Artefactos.
o Business Modeling Set.
o Requirements Set.
o Analysis & Design Set.
o Implementation Set.
o Test Set.
o Deployment Set.
o Project Management Set.
o Configuration & Change Management Set.
o Environment Set.
Características Esenciales de RUP:

 Proceso Dirigido por los Casos de Uso
 Proceso Iterativo e Incremental
 Proceso Centrado en la Arquitectura
Proceso Iterativo e Incremental:

 El ciclo de vida iterativo se basa en la evolución de prototipos ejecutables
que se muestran a los usuarios y clientes.
 En el ciclo de vida iterativo a cada iteración se reproduce el ciclo de vida
en cascada a menor escala.
 Los objetivos de una iteración se establecen en función de la evaluación
de las iteraciones precedentes.
 Las actividades se encadenan en una mini-cascada con un alcance
limitado por los objetivos de la iteración.
Gráfico N° 017: Proceso Iterativo Incremental

Aplicación Web
Fuente: Introducción a Rational Unified Process (RUP) - Patricio Letelier 2000
Puntos Claves:
 Pesado.
 Dividido en cuatro fases.
 La fase se dividen en iteraciones.
 El discurrir del proyecto se define en Workfíows. » Los artefactos son el
objetivo de cada actividad.
 Se basa en roles.
 UML.
 Muy organizativo.
 Mucha documentación.
 XP (Extreme Programming) ó Programación Extrema:
Es la primera metodología ágil y es la que le dio conciencia al movimiento actual

de metodologías ágiles. De la mano de Kent Beck, XP ha conformado un extenso
grupo de seguidores en todo el mundo, disparando una gran cantidad de libros a
los que dio comienzo el mismo Beck en [Beck, 2000]. Inclusive Addison-Wesley ha
creado una serie de libros denominada The XP Series. Fue la misma gente del
proyecto C3 (Sistema Exhaustivo de Compensaciones de Chrysler) la que produjo
también otro de los libros importantes de XP [Jeffries, 2001] en el que se bajaban
los conceptos de Beck a la puesta en práctica en un proyecto.
La imagen mental de Beck al crear XP [Beck, 2000] era la de perillas en un tablero

de control. Cada perilla representaba una práctica que de su experiencia sabía
que trabajaba bien. Entonces, Beck decidió girar todas las perillas al máximo para
ver que ocurría. Así fue como dio inicio a XP.
En la programación extrema, cada contribuidor al proyecto es una parte integral

del "equipo entero". El equipo forma alrededor de un representante del negocio
llamado "el cliente", que se sienta con el equipo y trabaja con ellos diariamente.
Diseño simple.
Los equipos de XP construyen software a un diseño simple. Comienzan simple, y
con la prueba del programador y la mejora del diseño, la guardan de esa manera.
Un equipo de XP mantiene el diseño satisfecho exactamente para la funcionalidad
Aplicación Web
actual del sistema. No hay movimiento perdido, y el software es siempre listo para
lo siguiente.
El diseño en XP no es una cosa de una sola vez, es una cosa de todo el tiempo.
En donde los equipos se deben acostumbrar a sesiones rápidas de diseño.
Integración continua.
Los equipos de programación extrema mantienen el sistema integrado
completamente siempre. Los equipos de XP construyen épocas múltiples por día.
(Un equipo de XP de cuarenta personas construye por lo menos ocho o diez
veces por día). La integración infrecuente conduce a los problemas senos en un
proyecto del software. Se tiene que tener en cuenta que la integración es crítica al
momento del envío de código, ya que el equipo no participa en ello, y se delega a
menudo a la gente que no está al corriente del sistema entero.
Codificación de estándar.
Los equipos de XP siguen un estándar común de la codificación, de modo que
todo el código en el sistema mire como si fuera escrito por un solo programador.
Lo importante es que todo el código parezca familiar.
Mientras que el RUP intenta reducir la complejidad del software por medio de
estructura y la preparación de las tareas pendientes en función de los objetivos de
la fase y actividad actual, XP, como toda metodología ágil, lo intenta por medio de
un trabajo orientado directamente al objetivo, basado en las relaciones
interpersonales y la velocidad de reacción.
XP intenta minimizar el riesgo de fallo del proceso por medio de la disposición

permanente de un representante competente del cliente a disposición del equipo
de desarrollo. Este representante debería estar en condiciones ue contestar
rápida y correctamente a cualquier pregunta del equipo de desarrollo de forma
que no se retrase la tomar de decisiones, de ahí lo de competente.
La codificación del software en XP se produce siempre en parejas (dos

programadores, un ordenador), por lo que se espera que la calidad del mismo
suba en el mismo momento de escribirlo. Al contrario que muchos otros métodos,
el código pertenece al equipo en completo, no a un programador o pareja, de
forma que cada programador puede cambiar cualquier parte del código en

Aplicación Web
cualquier momento si así lo necesita, dejándose en todo caso las mejoras

orientadas al rendimiento para el final. Las parejas no se mantienen para todo el
proyecto si no que rotan cíclicamente a lo largo del mismo, tanto en cuanto a los
componentes de la misma como en las partes del software que desarrollan, así
cada componente del equipo aprende como trabaja el resto. El objetivo ideal seria
que cada componente del equipo trabaje al menos una vez con cada uno de los
demás integrantes y con cada componente software, de forma que el
conocimiento de la aplicación completa lo posea el equipo entero y no unos pocos
miembros.
En XP se programará solo la funcionalidad que es requerida. Es decir, una gran

flexibilidad y capacidad de configuración solo será implementada cuando sea
necesaria para cumplir los requerimientos. Se sigue un diseño evolutivo con la
siguiente premisa: conseguir la funcionalidad deseada de la forma más sencilla
posible. Este diseño evolutivo hace que no se le de apenas importancia al análisis
como fase independiente, puesto que se trabaja exclusivamente en función de las
necesidades del momento.
Puntos Claves:
 Ligero.
 Cercano al desarrollo.
 Se basa en UserStories.
 Fuerte comunicación con el cliente.
 El código fuente pertenece a todos.
 Programación por parejas.
 Tests como base de la funcionalidad.
 Solo el mínimo de organización.
 Pobre en cuanto a documentación.
 FDD (Desarrollo Manejado Por Rasgos):
Peter Coad es considerado uno de los referentes más importantes dentro de la

ingeniería de software. Coad ha sido uno de los principales pioneros detrás del
movimiento de la orientación a objetos y empezó a trabajar con Ed Yourdon (uno
de los creadores del Análisis Estructurado) a principios de los noventa, cuando
este último pidió ayuda a alguien de la comunidad de objetos para desarrollar una
nueva metodología, basada en el paradigma de OO. Posteriormente, Coad junto

Aplicación Web
con Jeff De Luca y otros, participaría en la creación de FDD, una metodología

desarrollada alrededor del año 1998 que presenta las características de un
proceso ágil [Coad, 1998]. La misma derivó del trabajo de Coad sobre las Feature
Lists (Listas de Funcionalidades).
FDD se estructura alrededor de la definición de features que representan la

funcionalidad que debe contener el sistema, y tienen un alcance lo
suficientemente corto como para ser implementadas en un par de semanas. FDD
posee también una jerarquía de features, siendo el eslabón superior el de feature
set que agrupa un conjunto de features relacionadas con aspectos en común del
negocio. Por último, establece el major feature set como el más alto nivel de
agrupación de funcionalidad que abarca diferentes feature sets que contribuyen a
proveer valor al cliente en relación a un subdominio dentro del dominio completo
de la aplicación. Una de las ventajas de centrarse en las features del software es
el poder formar un vocabulario común que fomente que los desarrolladores
tengan un diálogo fluido con los clientes, desarrollando entre ambos un modelo
común del negocio. Este tema será tratado más adelante en relación al enfoque
de las metodologías ágiles en los productos entregados.
El FDD tiene cinco procesos. Los primeros tres se hacen al principio del proyecto
y son:
a) Desarrollar un Modelo Global.
b) Construir una Lista de los Rasgos.
c) Planear por Rasgo.
Los últimos dos se hacen en cada iteración. Cada proceso se divide en tareas y
se da un criterio de comprobación.
d) Diseñar por Rasgo.
e) Construir por Rasgo.
OBJETIVOS
 Sintetizar un programa conforme a los rasgos requeridos.
 En un desarrollo en términos de FOP (Programación Orientada a rasgos),
los objetos se organizan en módulos o capas conforme a rasgos.
FDD esta pensado para proyectos con tiempo de desarrollo relativamente cortos
(menos de un año). Se basa en un proceso iterativo con iteraciones cortas (2

Aplicación Web
semanas aproximadamente) que producen un software funcional que el cliente y

la dirección de la empresa pueden ver y monitor izar.
Un proyecto que sigue FDD se divide en 5 fases:
1. Desarrollo de un modelo general.

2. Construcción de la lista de funcionalidades o rasgos.
3. Plan en base a las funcionalidades o rasgos a implementar.
4. Diseñar en base a las funcionalidades o rasgos.
5. Implementar en base a las funcionalidades o rasgos.
Gráfico N° 018: Proceso FDD

Fuente: COAD, 1998
Las primeras tres fases ocupan gran parte del tiempo en las primeras iteraciones,
siendo las dos últimas las que absorben la mayor parte del tiempo según va
avanzando el proyecto, limitándose las primeras a un proceso de refinamiento.
El trabajo (tanto de modelado como de desarrollo) se realiza en grupo, aunque

siempre habrá un responsable último (arquitecto jefe o jefe de programadores en
función de la fase en que nos encontremos), con mayor experiencia, que tendrá la
última palabra en caso de no llegar a un acuerdo. Al hacerlo en grupo se consigue
que todos formen parte del proyecto y que los menos inexpertos aprendan de las
discusiones de los mas experimentados, y al tener un responsable último, se
asignan las responsabilidades que todas las empresas exigen.
FDD también define métricas para seguir el proceso de desarrollo de la aplicación,

útiles para el cliente y la dirección de la empresa, y que pueden ayudar, además

Aplicación Web
de para conocer el estado actual del desarrollo, a realizar mejores estimaciones

en proyectos futuros.
Puntos Claves:
 Ligero.
 A medio camino entre el desarrollo y la organización.
 Existe una jerarquía dentro del equipo.
 El código fuente tiene propietario.
 Los equipos varían en fúnción de la funcionalidad a implementar.
 El conocimiento de la aplicación se reparte a través de trabajo en equipo y
revisiones.
 Documentación aceptable.

Aplicación Web
2.7. MARCO CONCEPTUAL:
Título
“Sistema de Control para las Tareas del Servicio de Soporte Técnico de la Oficina de
Informática de la Municipalidad Provincial de Piura mediante una Aplicación Web”
Aplicación Web.
"La World Wide Web é Internet han introducido a la población en general en el

mundo de la informática. Compramos fondos de inversión colectivos y acciones,
descargamos música, vemos películas, obtenemos asesoramiento médico,
hacemos gestiones de diversos tipos como personales y corporativas…" [IEEE]
con respecto a la herramienta a producir en el presente proyecto.
Sistema de Control para las Tareas del Servicio de Soporte Técnico de la

Oficina de Informática de la Municipalidad Provincial de Piura.
"Los sistemas de control y supervisión son una clase importante de sistemas de

tiempo real. Verifican los sensores que proveen información del entorno del
sistema y toman acciones…" [SOMMERVILLE, 2002] con respecto al control que
asumiría soporte técnico en sus tareas de mantenimiento en la Municipalidad
Provincial de Piura.
Metodología Rational Unified Process (RUP).
"Conjunto de actividades necesarias para transformar los requisitos de un usuario

en un sistema software. Además es un marco de trabajo genérico que puede
especializarse para una gran variedad de sistemas software, para diferentes áreas
de aplicación, diferentes tipos de organizaciones, diferentes niveles de aptitud y
diferentes tamaños de proyecto" [Jacobson & Booch & Rumbaugh 2000].

Aplicación Web
2.8. HIPOTESIS:
La implementación de una Aplicación Web influye en el sistema de control de las tareas

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

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

Es una metodología del proceso de ingeniería de software que proporciona un
enfoque disciplinado para asignar tareas y responsabilidades dentro de una
organización del desarrollo y será aplicada en la presente tesis.

Aplicación Web
 Indicadores:
Definición Unidad de Técnica de Instrumentos

Nro Indicador Definición Operacional
Conceptual Medida Medición de Medición
I01 Tiempo para Tiempo que el n Minutos Observación Guía de
llegar a atender técnico demora S i Observación
una Solicitud de en llegar a una SS  i 1 N° 01
Servicio. solicitud de n (Cronómetro)
servicio. Ss - Tiempo de Asistencia Anexo
a la Solicitud de Servicio.
S = Tiempo de traslado
entre servicio.
n = Cantidad total de
Solicitudes de Servicio
I02 Tiempo para Es el tiempo que n Minutos Observación Guía de
solucionar una el técnico Ti  Observación
solicitud de demora en TS  i 1
N° 02
Servicio. solucionar una n (Cronómetro)
solicitud de T s = Tiempo de solución Anexo
servicio. de Solicitudes de
Servicio.
T = Tiempo para realizar
una Solución de Servicio.
Solicitudes de Servicio
I03 Cumplimiento de Porcentaje de n Porcentaje Observación Guía de
un Técnico en solicitudes de Mi Observación
cuanto a los servicios SM  i 1
x100% N° 03
Servicios atendidas por T Anexo
Asignados. técnico. SM= Porcentaje de
cumplimiento de un
técnico de sus servicios
asignados.
M = Solicitudes
atendidas.
T = Total de Solicitudes
de Servicios Asignados.
I04 Porcentaje de Porcentaje de n Porcentaje Observación Guía de
Servicio no Solicitudes 
Snai Observación
atendidos. realizadas por el Sn  i 1
x100% N° 04
usuario que no N Anexo
han sido Sn = Porcentaje de
atendidas por Servicios no atendidos.
diversos Sna = Servicio no
motivos. atendido.
N = Total de Solicitudes.
Cuadro N° 002: Indicadores de la Variable Dependiente

Fuente: El Autor

Aplicación Web

I05 Solicitudes de Es el número de n Unidad Observación Guía de
Servicio servicios S S 
t 1
St Observación
Asignadas por asignados a N° 05
Técnico. cada técnico. St =servicio asignado por Anexo
técnico.
t =orden de servicio
asignada al técnico.
Ss =Solicitudes de
Servicio.
I06 Solicitudes de Es el número de n Unidad Observación Guía de
Servicio por servicios S S  Si
i 1
 Observación
oficina. solicitados por N° 06
oficina. S S = Solicitudes de
Anexo
Servicios de Oficina.
Si = Solicitudes de
servicios de la Oficina
especificada.
I07 Número de Son los equipos n Unidad Observación Guía de

equipos que provienen El 
i 1
Gi  Observación
internados. de otra oficina y N° 07
que tienen que El=Número de Equipos Anexo
ser atendidos en de otro local.
Soporte. Gi=Guías de Salida.
I08 Tiempo de Tiempo para n Minutos Observación Guía de

búsqueda de buscar la  Ti Observación
historial técnico. información de TB  i 1 N° 08
mantenimiento n (Cronómetro)
(bitácora) de un TB = Tiempo de Anexo
equipo. Búsqueda
T = Tiempo de Búsqueda
de historial Técnico.
búsquedas
I09 Tiempo de Tiempo n Minutos Observación Guía de
Emisión (entrega) transcurrido t i Observación
de Documentos para la entrega TED  i 1 N° 09
(Reportes, Guías de la n (Cronómetro)
de salida y/o documentación TED = Tiempo de Emisión. Anexo
Fichas Técnicas). solicitada. t = Tiempo de Entrega
por documento.
documentación
Cuadro N° 002: Indicadores de la Variable Dependiente (continuación)

Fuente: El Autor

Aplicación Web

I10 Nivel de Medimos la n Porcentaje Encuesta Cuestionario
satisfacción del conformidad de Usi  de Encuesta
usuario. los usuarios con NS  i 1
x100% N° 01
la herramienta a n Anexo
desarrollar. NS = Nivel de
Satisfacción.
Us = Usuario Satisfecho.
usuarios
Cuadro N° 002: Indicadores de la Variable Dependiente (continuación)

Fuente: El Autor

Aplicación Web
________________________________________________________
CAPITULO III:
METODOLOGIA
________________________________________________________
3. METODOLOGIA:
Aplicación Web
3.1. TIPO DE ESTUDIO:
Los propósitos básicos del paradigma cuantitativo en la investigación socio-

educativa consisten en realizar mediciones y predicciones exactas del
comportamiento regular de grupos sociales. "Los positivistas buscan los hechos o
causas de los fenómenos sociales con independencia de los estados subjetivos
de los individuos" [Taylor y Bogdan, 1986], es decir buscan la objetividad. La
búsqueda principal consiste en explicar las causas de los fenómenos, confrontar
teoría y praxis, detectar discrepancias, analizar estadísticamente, establecer
conexiones y generalizaciones (abstracciones).
[Sant'Anna, y Smith, 1983] sugieren que el paradigma cuantitativo se nutre de los

supuestos filosóficos del realismo, racionalismo, positivismo y de la epistemología
científica de Comte y el Círculo de Viena.
“La Investigación Aplicada es aquel tipo de estudio científico orientado a resolver

problemas de la vida cotidiana o a controlar situaciones prácticas.” [José Padrón,
2006]
La presente tesis está basada en el paradigma cuantitativo porque me va permitir

recoger, procesar y analizar datos numéricos sobre variables determinadas
mediante métodos estadísticos.
La hipótesis formulada en esta investigación se traduce en variables, las que a su

vez se traducen en indicadores cuantificables.
Esta es una investigación aplicada porque se busca dar solución a un problema a

través del desarrollo de una herramienta tecnológica.
3.2. DISEÑO DEL ESTUDIO:

Aplicación Web
Para el presente proyecto de investigación el diseño a utilizar será cuasi

experimental con Pre-test y Post-test y grupos intactos.
[Hernandez, Fernández, Baptista – 2003] definen que en este tipo de diseño se

“...manipulan deliberadamente, al menos, una variable independiente para
observar su efecto y relación con una o más variables dependientes, sólo se
diferencian de los experimentos verdaderos en el grado de seguridad o
confiabilidad que pueda tenerse sobre la equivalencia inicial de los grupos”.
O1 – X – O2
O1 : Pre-test o Prueba Inicial

O2 : Post-test o Prueba Final
X : Variable Interviniente
Este diseño utiliza dos grupos: el experimental (que recibe el tratamiento) y el

grupo control (que no recibe el tratamiento). Los grupos son comparados en lapos
prueba para analizar si el tratamiento experimental tuvo un efecto sobre la
variable dependiente (O1 con O2). No se asignan los grupos ni por azar ni por
emparejamiento.
3.3. POBLACIÓN Y MUESTRA:
 Población
La población tomada para el desarrollo de la presente tesis es el personal
encargado del servicio que brinda el área de Soporte Técnico a los
diferentes equipos de las dependencias de la Municipalidad de Piura.
 Muestra
La muestra tomada para el desarrollo de la presente tesis es el personal
que labora en el área de Soporte Técnico de la Oficina de Informática de la
Municipalidad de Piura. La cantidad de la muestra serán las 5 personas
encargadas del servicio que brinda la dependencia en mención, por lo
tanto no es necesario aplicar una fórmula para obtener la muestra.
3.4. MÉTODOS DE INVESTIGACIÓN:

Aplicación Web
Recolección de información de un estado inicial a través de una prueba de

entrada o pre-test.
Posteriormente se aplicará una prueba de salida o post test con una medición de
los efectos que ha tenido la variable independiente.
Y por último se hará una comparación entre la información que se tuvo al inicio y
al final.
3.5. TÉCNICAS E INSTRUMENTOS DE RECOLECCIÓN DE DATOS:
 Técnicas
Las técnicas de recolección de datos que se emplearán son: encuestas y

observación. Estas nos ayudarán a recoger información primordial para
desarrollar el presente trabajo de investigación o tesis que tiene por título:
“Sistema de Control para las Tareas del Servicio de Soporte Técnico de la
Oficina de Informática de la Municipalidad Provincial de Piura”.
 Instrumentos
Los instrumentos de recolección de datos para el desarrollo de la presente

investigación o proyecto de tesis son: las guías de observación y
cuestionarios de encuestas.
A continuación en el siguiente cuadro se presentan los indicadores con sus

respectivas técnicas e instrumentos de recolección de datos:

Aplicación Web
Nº Indicadores Técnicas Instrumentos
Tiempo para llegar a atender una

1 Observación Guía de Observación
Solicitud de Servicio.
Tiempo para solucionar una

solicitud de Servicio.
Cumplimiento de un Técnico en
cuanto a los Servicios Asignados.
Porcentaje de Servicio no
atendidos.
Solicitudes de Servicio Asignadas

por Técnico.
6 Solicitudes de Servicio por oficina. Observación Guía de Observación
7 Número de equipos internados. Observación Guía de Observación
Tiempo de búsqueda de historial

técnico.
Tiempo de Emisión (entrega) de
9 Documentos (Reportes, Guías de Observación Guía de Observación
salida y/o Fichas Técnicas).
10 Nivel de satisfacción del usuario. Encuesta Cuestionario de Encuesta
Cuadro N° 003: Indicadores, Técnicas e Instrumentos de Recolección de Datos

Fuente: El Autor
3.6. MÉTODOS DE ANÁLISIS DE DATOS:
Para analizar los datos recolectados se estudiarán los resultados organizados en

cuadros estadísticos para determinar las principales tendencias de la información
utilizando los porcentajes de los cuadros o de las aplicaciones estadísticas. Para
el análisis de datos se va a utilizar el software Microsoft Excel 2007.

Aplicación Web
________________________________________________________
CAPITULO IV:
ADMINISTRACION
________________________________________________________

Aplicación Web
4. ADMINISTRACION:
4.1. CRONOGRAMA DE ACTIVIDADES:
Para realizar el Cronograma de Gantt de las actividades a desarrollar en la

presente tesis hemos utilizado el software Microsoft Office Project 2007, el cual es
una herramienta que nos ayuda a realizar cronogramas de actividades para
diferentes tipos de proyecto. Este software ayuda a optimizar la distribución del
tiempo. A continuación en el cuadro Nº 4 se observa el cronograma del proyecto:
Cuadro N° 004: Cronograma de Actividades de la Tesis

Fuente: El Autor

Aplicación Web
4.2. PRESUPUESTO:
Precio
Recursos Cantidad C/U
Total
Memoria USB 4 GB 01 S/. 50.00 S/. 50.00
Cartuchos de tinta
04 S/. 50.00 S/. 200.00
para impresora
Folder Manila A4 10 S/. 1.00 S/. 10.00

Bienes
Papel A4 1 millar S/. 25.00 S/. 25.00
CD’s de 700 MB 10 S/. 1.00 S/. 10.00
Lapiceros 10 S/. 0.50 S/. 5.00
Luz Eléctrica ___ ___ S/. 200.00
Internet 200 horas S/. 1.00 S/. 200.00
Teléfono ___ ___ S/. 100.00
Servicios Movilidad ___ ___ S/. 400.00
Fotocopiado 500 hojas S/. 0.05 S/. 25.00
Anillados 2 S/. 5.00 S/. 10.00
Empastados 3 S/. 20.00 S/. 60.00
Personal de apoyo ___ ___ S/. 400.00

Remuneraciones
Otros ___ ___ S/. 200.00
Total S/. 1,895.00
Cuadro N° 005: Presupuesto de la Tesis

Fuente: El Autor
4.3. FINANCIAMENTO:
El presente proyecto de investigación es autofinanciado por el autor ya que

la Municipalidad Provincial de Piura no financia este tipo de investigaciones
hechas por alumnos universitarios.

Aplicación Web
________________________________________________________
CAPITULO V:
REFERENCIAS BIBLIOGRAFICAS
________________________________________________________

Aplicación Web
[Álvarez Brotons, España, 2004] Sistemas de Control, artículo publicado por en la

Universidad Politécnica de Catalunya.
[Beck, 2000] Beck, Kent, Extreme Programming Explained, Addison-Wesley The XP

Series.
[Boehm, noviembre 1995] Boehm, Barry W., Anchoring the Software Process, USC.
[Booch, 2000] Booch, Grady, Ivar Jacobson, James Rumbaugh, The Unified Modeling
Language User Guide, Addison-Wesley Object Technology Series.
Castro Arévalo, Manuel & Zapata Navarro, Jhon (Piura – 2009), “Sistema Informático
de Registro de Mantenimiento de Equipos de Cómputo del Área de Soporte del Centro de
Informática y Telecomunicaciones de la Universidad Nacional de Piura”. Universidad
César Vallejo – Filial Piura.
[Coad, 1998] Coad, Peter, Eric Lefebvre, Jeff De Luca, Feature-Driven Development,
Disponible en: http://www.cs.jhu.edu/~scott/oos/software/togetherj/help/Users-
Guide/Feature_Driven_Development.htm
Espinoza Saavedra, Daniel (Valparaíso, Chile – 2004), “Estudio del Sistema de

Monitoreo y Registro de Inventarios de Compras y su Integración Estratégica mediante el
Control de Gestión”. Universidad de Valparaíso.
[Freeman Elisabeth, 2004] et. al. Head First Design Patterns. California: O'Reilly Media.
[Gamma Erich, 1995] et. al. Design Patterns.Elements of Reusable Object-Oriented

Software. Boston: Addison-Wesley.
[Harrop Rob, 2005] et al. Pro Spring. Nueva York: Apress.
[Hernandez Sampieri, Roberto; Fernández Collado, Carlos; Baptista Lucio, Pilar;

México 2003] Metodología de la Investigación. Mc Graw Hill.

Aplicación Web
[Johnson Rob, 2003] Expert One-on-One J2EE Design and Development. Indianapolis:
Wrox Press.
[Johnson Rob, mayo 2005] Introduction to the Spring Framework. [En línea].
Disponible en: www.theserverside.com/articles/article.tss?l=SpringFramework
[José Padrón G.] Bases del concepto de "Investigación Aplicada"[en línea].

Disponible en: http://padron.entretemas.com/InvAplicada/index.htm
Metodologías de Desarrollo de Software (España – 2006), artículo publicado por la

Universidad Rey Juan Carlos.
Metodología ITIL (Information Technologies Infraestructure Library) – OSIATIS S.A. V2.0

Disponible en: http://itil.osiatis.es/Curso_ITIL/
[P. Letelier, Zaragoza, octubre 2000] Metodologías de Producción de Software.
Pesántez Huerta, Álvaro Eduardo (Guayaquil, Ecuador – 2007), “Elaboración de un

Plan de Mantenimiento Predictivo y Preventivo en Función de la Criticidad de los Equipos
del Proceso Productivo de una Empresa Empacadora de Camarón”. Escuela Superior
Politécnica del Litoral.
Plan Estratégico Institucional (2009 – 2014), Municipalidad Provincial Piura (PEI-MPP)
Plan Operativo Institucional (2011), Municipalidad Provincial de Piura (POI–MPP)
Reglamento de Organización y Funciones, Municipalidad Provincial Piura (ROF-MPP)
[RUP, 2002] Rational Unified Process® Version 2002.05.00, Copyright © Rational

Software Corporation, All Rights Reserved.
Salcedo Untiveros, Richard Orlando (Piura – 2007), “Análisis, Diseño y Desarrollo del
Módulo Web para la Gestión y Control de Inventario de Bienes de la Oficina de Control
Patrimonial de la Dirección Regional de Salud Piura”. Universidad Nacional de Piura.

Aplicación Web
[Sant'Anna, F., 1983] Estratégias quantitativas e qualitativas de pesquisa educational: da

ação a obser-vação participante. Educação e realidade.
Santillán Pinedo, Karla & Tornero Mendoza, Ludver (Trujillo – 2001), “Sistema de
Información de Control de Almacén de la Dirección Regional de Educación de La Libertad
– DRELL”. Universidad César Vallejo.
[Smith, J., 1983] Quantitative versus qualitative research: An attempt to clarify the issue.
Educational Researcher.
[Sommerville, Ian, 2002] Ingeniería del Software.
[Taylor, S. J. y Bogdan, R., 1986] Introducción a los métodos cualitativos de

investigación. La búsqueda de significados. Buenos Aires: Editorial Paidós.
Vega Bustamante, Rocío Olinda (Lima – 2009), “Análisis, diseño e implementación de

un sistema de administración de incidentes en atención al cliente para una empresa de
telecomunicaciones”. Pontificia Universidad Católica del Perú.
[Walls Craig, 2005] et. al. Spring in Action. Greenwich: Manning Publications.

Aplicación Web
________________________________________________________
CAPITULO VI:
ANEXOS
________________________________________________________

Aplicación Web
ANEXO 01
Guía de Observación Nº 01
Tiempo para llegar a atender una solicitud de servicio.

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

Número
Inicio Llegada (Min)
Tiempo Promedio
Hora Final: _________Fecha de fin de observación: __/ __/ _____
Observaciones:
_________________________________________________________________
_________________________________________________________________
___________________________________________________________
Observador
Revisado Procesado Archivado

Aplicación Web
ANEXO 02
Tiempo para solucionar una solicitud de servicio.

Instrucciones: En los días de observación se tomarán la fecha y hora de inicio de
la atención a la solicitud de servicio por parte del técnico y la hora de la
finalización de dicha atención.
Tiempo
Número Hora de Inicio Hora de Finalización
Total (Min)
Tiempo Promedio
Observaciones:
_________________________________________________________________
_________________________________________________________________
___________________________________________________________
Observador

Aplicación Web
ANEXO 03
Cumplimiento de un técnico en cuanto a los servicios asignados.

Instrucciones: En los días de observación se tomarán las cantidades de los
servicios atendidos por un técnico y los que le han sido asignados a atender.
Cantidad Cantidad
Porcentaje
Técnico Solicitudes Solicitudes
Cumplimiento
Asignadas Atendidas
Observaciones:
_________________________________________________________________
_________________________________________________________________
___________________________________________________________
Observador

Aplicación Web
ANEXO 04
Porcentajes de Servicios no Atendidos.

Instrucciones: En los días de observación se tomarán las cantidades de los
servicios no atendidos y el total de las solicitudes de servicio.
Cantidad Porcentaje
Cantidad
Día Solicitudes Servicios no
Solicitudes
no Atendidas Atendidos
Observaciones:
_________________________________________________________________
_________________________________________________________________
___________________________________________________________
Observador

Aplicación Web
ANEXO 05
Solicitudes de Servicio Asignadas por Técnico.

Instrucciones: En los días de observación se tomarán las cantidades de las
solicitudes de los servicios asignados a un técnico.
Cantidad
Técnico Solicitudes
Asignadas
Observaciones:
_________________________________________________________________
_________________________________________________________________
___________________________________________________________
Observador

Aplicación Web
ANEXO 06
Solicitudes de Servicio por Oficina.

solicitudes de los servicios de oficinas específicas.
Cantidad
Oficina Solicitudes
Servicios
Observaciones:
_________________________________________________________________
_________________________________________________________________
___________________________________________________________
Observador

Aplicación Web
ANEXO 07
Número de Equipos Internados.

guías de salida de los equipos de otras dependencias que han sido atendidos en
el taller de Soporte Técnico.
Fecha de inicio de observación: __/ __/ ___ Hora de Inicio: _________
Cantidad de
Día Equipos de Otra
Dependencia
Observaciones:
_________________________________________________________________
_________________________________________________________________
___________________________________________________________
Observador

Aplicación Web
ANEXO 08
Tiempo de Búsqueda de Historial Técnico.

la búsqueda del historial técnico de un equipo y la hora de finalización de dicha
búsqueda.

Número
Inicio Finalización (Min)
Tiempo Promedio
Observaciones:
_________________________________________________________________
_________________________________________________________________
___________________________________________________________
Observador

Aplicación Web
ANEXO 09
Tiempo de Emisión de Documentos.

la emisión de un documento (reportes, guías de salida y/o fichas técnicas) y la
hora de finalización o entrega de dicho documento.

Número
Inicio Entrega (Min)
Tiempo Promedio
Observaciones:
_________________________________________________________________
_________________________________________________________________
___________________________________________________________
Observador

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

trabajo?
a. Nada
b. Poco
c. Medianamente
d. Mucho
2) ¿La aplicación web implementada es fácil de manejar?
a. Nada
b. Poco
c. Medianamente
d. Mucho
3) ¿Con la aplicación web implementada la información está disponible de

forma inmediata?
a. Nada
b. Poco
c. Medianamente
d. Mucho
4) ¿La información que brindan los reportes de la aplicación web son de

utilidad para los usuarios del sistema?
 Nada
 Poco
 Medianamente
 Mucho
5) ¿Está usted satisfecho con la aplicación web?

Aplicación Web
a. Nada
b. Poco
c. Medianamente
d. Mucho
6) ¿La aplicación web implementada cumple con todos los requisitos

solicitados?
a. Nada
b. Poco
c. Medianamente
d. Mucho
7) ¿Cuál es su opinión general de la aplicación web?
Gracias por su participación
Este cuestionario de encuesta se mide de la siguiente forma:
Como para cada pregunta se presentan 4 opciones las cuales se asemejan

(grado de medición), una vez resueltas estas encuestas por el personal de
Soporte Técnico, se procederá al conteo de las letras para conocer cuál de ellas
ha obtenido mayor puntaje.
Si la mayor cantidad de las letras son:
PUNTUACIÓN GRADO DE SATISFACCIÓN

a Quiere decir que el usuario se

Aplicación Web
encuentra Nada Satisfecho.

Quiere decir que el usuario se
b
encuentra Poco Satisfecho.
c
encuentra Medianamente Satisfecho.
d
encuentra Muy satisfecho.

Aplicación Web

Proyecto de Tesis Aplicacion Web Control Servicios Soporte Tecnico

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Proyecto de Tesis Aplicacion Web Control Servicios Soporte Tecnico

Caricato da

Copyright:

Formati disponibili

UNIVERSIDAD CÉSAR VALLEJO

“Sistema de Control para las Tareas del Servicio

Pino Chacón Jesús Antonio Manuel

Mg. Luis Velez Ubillus

Sistema de Control para las Tareas del Servicio de

El constante y permanente avance tecnológico en el manejo de información con

En la presente tesis, desarrollo e implementación, se busca mejorar el sistema de

Sistema de Control para las Tareas del Servicio de

El presente proyecto de investigación se lo

Sistema de Control para las Tareas del Servicio de

Agradezco primeramente a Dios por haberme motivado para realizar el presente

Sistema de Control para las Tareas del Servicio de

Sistema de Control para las Tareas del Servicio de

CAPITULO III: Metodología............................................................................................70

INDICE DE GRAFICOS Y CUADROS

Cuadro N° 001: Política Institucionales........................................................................21

Sistema de Control para las Tareas del Servicio de

1. GENERALIDADES DEL PROYECTO DE INVESTIGACION:

Sistema de Control para las Tareas del Servicio de

1.2. TIPO DE INVESTIGACIÓN:

1.3. ÁREA DE INVESTIGACIÓN:

1.4. INSTITUCIÓN DONDE SE REALIZA LA INVESTIGACIÓN:

“Área de Soporte Técnico de la Municipalidad Provincial de Piura”

Jesús Antonio Manuel Pino Chacón

1.6. ASESOR METODOLÓGICO:

Mg. Luis Velez Ubillus

1.7. ASESOR ESPECIALISTA:

Ing. Noelia Saavedra Nizama

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

Inicio: 29 de marzo del 2011

Sistema de Control para las Tareas del Servicio de

Sistema de Control para las Tareas del Servicio de

2.1. DESCRIPCIÓN DE LA REALIDAD PROBLEMÁTICA:

El área de Soporte Técnico pertenece a la Oficina de Informática y que a su vez

Soporte Técnico soluciona problemas de hardware, software, eléctricos,

El problema principal radica en el deficiente control de las tareas del servicio de

 El registro de atenciones se hace de manera manual y en algunas ocasiones

 No se maneja información estadística de los sucesos que acontecen en Soporte

 No existe un procedimiento adecuado de control y seguimiento en el área de

 Soporte Técnico no cuenta con un inventario propio.

 El Área de Soporte Técnico no tiene independencia para planificar operaciones y

 El proceso de atenciones a los problemas que se presentan en las dependencias

 Se designa a Soporte Técnico escasos recursos (hardware, software y

Sistema de Control para las Tareas del Servicio de

 El control del ingreso de requerimientos a soporte técnico es inadecuado.

 Los puntos de reposición de Soporte Técnico no están definidos.

 La planificación de tareas para el proceso del mantenimiento preventivo no es el

 La planificación de tareas para el proceso del mantenimiento correctivo no es el

 El registro y monitoreo del historial de cada equipo de la municipalidad de Piura

2.2. FORMULACIÓN DEL PROBLEMA:

2.2.1. Pregunta General:

2.2.2. Preguntas de Investigación:

¿De qué manera influye una aplicación web en la mejora de la organización

Sistema de Control para las Tareas del Servicio de

2.2.3. Objetivo General:

“Determinar cómo influye una Aplicación Web en la mejora del Sistema de

2.2.4. Objetivos Específicos:

 Determinar de qué manera una Aplicación Web mejora la

 Determinar de qué manera una Aplicación Web permitirá contar con

 Determinar de qué manera una Aplicación Web incidirá en la

 Determinar de qué manera una Aplicación Web permitirá que el Área

2.3. JUSTIFICACIÓN E IMPORTANCIA DEL PROYECTO:

Sistema de Control para las Tareas del Servicio de