Proyecto de Tesis Aplicacion Web Control Servicios Soporte Tecnico

UNIVERSIDAD CSAR VALLEJO
PIURA
FACULTAD DE INGENIERA
ESCUELA DE INGENIERA DE SISTEMAS
Sistema de Control para las Tareas del Servicio
de Soporte Tcnico de la Oficina de Informtica de
la Municipalidad Provincial de Piura mediante una
Aplicacin Web
Proyecto de tesis
Autor
Pino Chacn Jess Antonio Manuel
Asesor
Mg. Luis Velez Ubillus
Piura - Per
(2011)
Universidad Csar Vallejo-Piura
Escuela Ingeniera Sistemas
ASESORES DE TESIS
ASESOR METODOLGICO:
___________________
ASESOR ESPECIALISTA:
____________________
Ing. Noelia Saavedra Nizama
Sistema de Control para las Tareas del Servicio de

Soporte Tcnico de la Oficina de Informtica de la
Municipalidad Provincial de Piura mediante una
Aplicacin Web
Jess Antonio Pino Chacn
INTRODUCCIN
El constante y permanente avance tecnolgico en el manejo de informacin con
sistemas cada vez ms sofisticados debido al ambiente competitivo en que
vivimos, todo esto tiene como consecuencia un notorio cambio para la Oficina de
Informtica, redefiniendo sus objetivos y estrategias que le permitan cambiar la
estructura de las vas de distribucin y redisear procesos para mejorar sus
servicios, obtenindose la automatizacin de varios procesos del sistema de
control para as minimizar las barreras del tiempo y distancia, facilitar el acceso a
fuentes de informacin y potenciar el desarrollo de los servicios, adems incide
favorablemente en la eficiencia operativa, la calidad de los servicios prestados, el
acercamiento con los usuarios o trabajadores que laboran en la municipalidad
provincial de Piura y la coordinacin de actividades.
En la presente tesis, desarrollo e implementacin, se busca mejorar el sistema de
control para las tareas del servicio de soporte tcnico, sumado al crecimiento de
nuevas tcnicas, herramientas y filosofas orientadas a la optimizacin de los
medios, teniendo como prioridad prevenir y reducir los riesgos suscitados en las
tareas operativas y administrativas relacionadas con la conservacin y los
servicios de mantenimiento que se brindan.

Aplicacin Web
DEDICATORIA
El presente proyecto de investigacin se lo
dedico a Dios y a mis padres por su
comprensin y ayuda en todo momento. Mis
padres me han enseado a ser perseverante
para encarar las adversidades de la vida sin
perder nunca la fe y la esperanza ni
desfallecer en el intento de alcanzar nuestros
objetivos y metas.
El Autor

Aplicacin Web
AGRADECIMIENTO
Agradezco primeramente a Dios por haberme motivado para realizar el presente
proyecto de tesis, agradezco tambin a mis padres por su apoyo incondicional y
por estar siempre a mi lado, a mis maestros porque a travs de sus enseanzas
lograron transmitirme sus conocimientos e inculcarme el deseo por la
investigacin.
El Autor

Aplicacin Web
NDICE
N Pgina
CAPITULO I: Generalidades............................................................................................9
1.1.
Ttulo................................................................................................................... 10
1.2.
Tipo de Investigacin...........................................................................................10
1.3.
rea de Investigacin..........................................................................................10
1.4.
Institucin donde se realiza la Investigacin..................................................10
1.5.
Autor................................................................................................................... 10
1.6.
Asesor Metodolgico........................................................................................10
1.7.
Asesor Especialista...........................................................................................10
1.8.
Duracin del Proyecto de Investigacin..........................................................10
CAPITULO II: Plan de Investigacin..............................................................................11

2.1.
Descripcin de la Realidad Problemtica........................................................12
2.2.
Formulacin del Problema................................................................................13
2.2.1. Pregunta General...............................................................................................13

2.2.2. Preguntas de Investigacin..............................................................................13
2.2.3. Objetivo General................................................................................................14
2.2.4. Objetivos Especficos.......................................................................................14
2.3.
Justificacin e Importancia del Proyecto .......................................................15
2.4.
Limitaciones del Proyecto................................................................................16
2.5.
Marco Referencial Cientfico............................................................................17
2.5.1. Antecedentes.....................................................................................................17
2.6.
Marco Terico....................................................................................................20
2.6.1. Municipalidad Provincial de Piura........................................................................20

2.6.2 Oficina de Informtica.......................................................................................24
2.6.3. Soporte Tcnico................................................................................................25
2.6.4. Sistema de Control............................................................................................26
2.6.5. Aplicacin Web..................................................................................................28
2.6.6. Gestin de Incidentes.......................................................................................40
2.6.7. Gestin de Problemas.......................................................................................46
2.6.8. Metodologa de Desarrollo................................................................................55
2.7.
Marco Conceptual.............................................................................................65
2.8.
Hiptesis............................................................................................................ 66
2.9.
Variables e Indicadores Implicados en el Proyecto........................................66

Aplicacin Web
NDICE
N Pgina
CAPITULO III: Metodologa............................................................................................70
3.1.
Tipo de Estudio..................................................................................................71
3.2.
Diseo del Estudio............................................................................................72
3.3.
Poblacin y Muestra..........................................................................................72
3.4.
Mtodos de Investigacin.................................................................................73
3.5.
Tcnicas e Instrumentos de Recoleccin de Datos........................................73
3.6.
Mtodos de Anlisis de Datos..........................................................................74
CAPTULO IV: Administracin.......................................................................................75

4.1.
Cronograma.......................................................................................................76
4.2.
Presupuesto.......................................................................................................77
4.3.
Financiamiento..................................................................................................77
CAPTULO V: Referencias Bibliogrficas.....................................................................78

CAPTULO VI: Anexos...................................................................................................82
ANEXO 01: Gua de Observacin N 01 .......................................................................83
ANEXO 02: Gua de Observacin N 02........................................................................84
ANEXO 10: Cuestionario de Encuesta N 01................................................................92
INDICE DE GRAFICOS Y CUADROS

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

Aplicacin Web
________________________________________________________
CAPITULO I:
GENERALIDADES
________________________________________________________
1. GENERALIDADES DEL PROYECTO DE INVESTIGACION:

Aplicacin Web
1.1. TTULO:
Sistema de Control para las Tareas del Servicio de Soporte Tcnico de la Oficina
de Informtica de la Municipalidad Provincial de Piura mediante una Aplicacin
Web
1.2. TIPO DE INVESTIGACIN:

EXPLICATIVA
1.3. REA DE INVESTIGACIN:

TECNOLOGICA
1.4. INSTITUCIN DONDE SE REALIZA LA INVESTIGACIN:

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

1.7. ASESOR ESPECIALISTA:

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

Inicio:
29 de marzo del 2011
Final:
18 de diciembre del 2011

Aplicacin Web
10
________________________________________________________
CAPITULO II:
PLAN DE INVESTIGACION
________________________________________________________
2. PLAN DE LA INVESTIGACION:

Aplicacin Web
11
2.1. DESCRIPCIN DE LA REALIDAD PROBLEMTICA:

El rea de Soporte Tcnico pertenece a la Oficina de Informtica y que a su vez
esta pertenece a la Gerencia de Tecnologas y Sistemas de Informacin de la
Municipalidad Provincial de Piura.
Soporte Tcnico soluciona problemas de hardware, software, elctricos,
electrnicos, telefnicos y de redes de la mayora de equipos que se encuentran
en la municipalidad, se limita a estas actividades y no a proporcionar las polticas
de seguridad y privacidad de la red de trabajo o dominio.
El problema principal radica en el deficiente control de las tareas del servicio de
Soporte Tcnico de la Oficina de Informtica de la Municipalidad Provincial de
Piura. De ello se derivan algunos subproblemas como:
El registro de atenciones se hace de manera manual y en algunas ocasiones
cuando los problemas son complicados y requieren ms recursos se atienden de
una manera inapropiada.
No se maneja informacin estadstica de los sucesos que acontecen en Soporte
Tcnico.
No existe un procedimiento adecuado de control y seguimiento en el rea de
Soporte Tcnico, todo se hace manualmente.
Soporte Tcnico no cuenta con un inventario propio.
El rea de Soporte Tcnico no tiene independencia para planificar operaciones y
tareas administrativas y de mantenimiento en la municipalidad de Piura ya que
esto depende de la Oficina de Informtica.
El proceso de atenciones a los problemas que se presentan en las dependencias
de la municipalidad es poco organizado.

Aplicacin Web
12
Se designa a Soporte Tcnico escasos recursos (hardware, software y

herramientas) en stock para atender los problemas que acontecen en la
municipalidad.
El control del ingreso de requerimientos a soporte tcnico es inadecuado.
Los puntos de reposicin de Soporte Tcnico no estn definidos.
La planificacin de tareas para el proceso del mantenimiento preventivo no es el
adecuado.
La planificacin de tareas para el proceso del mantenimiento correctivo no es el
adecuado.
El registro y monitoreo del historial de cada equipo de la municipalidad de Piura
no es el mas conveniente para soporte tcnico.
2.2. FORMULACIN DEL PROBLEMA:

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

De qu manera influye una aplicacin web en la mejora de la organizacin
y planificacin de tareas para el proceso del mantenimiento preventivo y
correctivo?
De qu manera influye una aplicacin web para que Soporte Tcnico
cuente con un inventario propio para obtener y a la vez controlar una mayor
cantidad de recursos?

Aplicacin Web
13
De qu manera influye una aplicacin web en la mejora del control y

organizacin para los procesos de atenciones de problemas e incidentes?
De qu manera influye una aplicacin web para que el rea de Soporte
Tcnico
tenga
independencia
para
planificar
operaciones
tareas
administrativas y de mantenimiento?
2.2.3. Objetivo General:

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

Determinar de qu manera una Aplicacin Web mejora la
organizacin y la planificacin de tareas para el proceso del
mantenimiento preventivo y correctivo de los diferentes equipos de la
Municipalidad Provincial de Piura.
Determinar de qu manera una Aplicacin Web permitir contar con
un inventario propio en Soporte Tcnico para controlar y obtener una
mayor cantidad de recursos necesarios para las tareas de los
servicios que se realizan en la Municipalidad Provincial de Piura.
Determinar de qu manera una Aplicacin Web incidir en la
optimizacin del control y la organizacin para el proceso de
atenciones de problemas e incidentes que acontecen en las
dependencias de la Municipalidad Provincial de Piura.
Determinar de qu manera una Aplicacin Web permitir que el rea
de Soporte Tcnico tenga independencia para planificar operaciones
y tareas administrativas y de mantenimiento.

Aplicacin Web
14
2.3. JUSTIFICACIN E IMPORTANCIA DEL PROYECTO:

En vista de las necesidades del rea de Soporte Tcnico de la Municipalidad de
Piura de llevar un mejor control en la atencin y solucin de problemas tcnicos
que sufren los equipos de las diferentes reas de la Municipalidad es que se
desarrolla el presente proyecto para beneficiar tanto a los usuarios de la
Municipalidad Provincial de Piura como a los trabajadores que laboran en el rea
de ST.
Este proyecto abarcar tambin un mejor manejo del Inventario que compete a la
Oficina de Informtica ya que se podr saber que equipos son dados de baja y
cules son los que hacen falta para tener un stock adecuado en nuestro
inventario.
Con este trabajo de investigacin se podr optimizar el tiempo horas hombre y se
podrn atender una mayor cantidad de problemas que surjan en las diferentes
oficinas de la Municipalidad de Piura y que en verdad necesiten la atencin de
Soporte Tcnico dando soluciones rpidas y adecuadas a dichos problemas.
Justificacin Administrativa
Este proyecto es una alternativa de solucin al problema de Control y
Organizacin para el Mantenimiento de Equipos Informticos, cuyo desarrollo
adems de fortalecer el logro ptimo de los objetivos institucionales, agiliza las
actividades desarrolladas por el rea en la cual nuestra aplicacin web ser
implementada.
Justificacin Cientfica
El trabajo es desarrollado en base al mtodo cientfico, que va desde la
observacin del objeto de estudio hasta las conclusiones y recomendaciones. El
producto final alcanzado, ser lo que justifique la investigacin.
Justificacin Institucional
Uno de los objetivos de la Municipalidad Provincial de Piura es mejorar la gestin
administrativa y propiciar la descentralizacin de sus unidades y dependencias,
mediante el uso de tecnologas de informacin. Para ello se implementar un

Aplicacin Web
15
nuevo sistema de informacin y/o control (aplicacin web) para satisfacer las
necesidades del usuario y puedan desarrollar sus actividades eficientemente.
Justificacin Social
La implementacin del sistema de informacin y/o control (aplicacin web)
mejorar la administracin de los recursos informticos para ofrecer servicios de
calidad a la poblacin y en consecuencia mejorar la imagen institucional del
Gobierno Regional de Piura.
Justificacin Tecnolgica
Como entes de investigacin y aprendizaje obtendremos nuevos conocimientos y
experiencia como profesionales, mantenindonos a la vanguardia de los
requerimientos de nuestro entorno y la adecuada capacitacin en cuanto a nuevas
tecnologas de informacin se refiere. Puesto que una de las competencias
exclusivas de la Municipalidad Provincial de Piura es promover la modernizacin,
actualizacin e innovaciones tecnolgicas.
2.4. LIMITACIONES DEL PROYECTO:

El limitado acceso a informacin de los sistemas informticos que pueden
servir de gua para el desarrollo de la presente investigacin.
El trabajo dinmico o poca disponibilidad del personal de Soporte Tcnico
limitar la informacin que se pueda obtener de ellos para el desarrollo de la
presente aplicacin web.
Los escasos recursos tecnolgicos que dispone el rea de soporte tcnico
para el desarrollo del presente proyecto.
La aplicacin web a desarrollar ser independiente a la aplicacin web
institucional de la municipalidad.
La base de datos del sistema de inventario de la municipalidad de Piura
servir de gua y/o modelo para la base de datos de nuestro sistema de control
(aplicacin web) para Soporte Tcnico.

Aplicacin Web
16
2.5. MARCO REFERENCIAL CIENTIFICO:

2.5.1. Antecedentes:
Antecedentes Locales:
Castro Arvalo, Manuel & Zapata Navarro, Jhon (Piura 2009), Sistema
Informtico de Registro de Mantenimiento de Equipos de Cmputo del rea
de Soporte del Centro de Informtica y Telecomunicaciones de la
Universidad Nacional de Piura, presentan su tesis con la que obtuvieron los
Ttulos Profesionales de Ingenieros de Sistemas en la Universidad Csar
Vallejo Filial Piura. Castro & Zapata con este trabajo de investigacin
buscan registrar cada uno de los mantenimientos que se les realiza a todos
los equipos que llegan al rea de soporte y tambin buscan organizar y
monitorear el inventario de todos los equipos de la Universidad Nacional de
Piura.
Relacin: Esta tesis se toma en cuenta porque implementa un sistema
informtico que se encarga de registrar datos detallados de los equipos de
cmputo (inventario) y los mantenimientos que estos reciben, considerando
tambin la respectiva organizacin y monitoreo, as como los beneficios que
otorga.
Salcedo Untiveros, Richard Orlando (Piura 2007), Anlisis, Diseo y
Desarrollo del Mdulo Web para la Gestin y Control de Inventario de Bienes
de la Oficina de Control Patrimonial de la Direccin Regional de Salud Piura,
presenta su tesis con la que obtuvo el Ttulo Profesional de Ingeniero
Informtico en la Universidad Nacional de Piura. Salcedo con este proyecto
de tesis busca gestionar y controlar el inventario de bienes de la Direccin
Regional de Salud Piura incluyendo los procesos de registro de bienes,
verificacin del estado de los bienes, baja de bienes.

Aplicacin Web
17
Relacin: Esta tesis se toma en consideracin porque implementa un

mdulo web que presenta entornos de trabajo correspondientes a cada rea
de accin por usuario, relacionada con la gestin y control de inventario, as
como las ventajas que este otorga.
Antecedentes Nacionales:
Vega Bustamante, Roco Olinda (Lima 2009), Anlisis, diseo e

implementacin de un sistema de administracin de incidentes en atencin al
cliente para una empresa de telecomunicaciones, presenta su tesis con la
que obtuvo el Ttulo Profesional de Ingeniero Informtico en la Pontificia
Universidad Catlica del Per. Vega con este proyecto de investigacin
busca monitorear el tiempo de atencin de los casos que presente el cliente
en una empresa de telecomunicaciones, de all que la presente tesis
presenta el anlisis, desarrollo e implementacin de un sistema de
administracin de incidentes en Atencin al Cliente para una empresa de
telecomunicaciones.
Relacin: Esta tesis se toma en consideracin porque implementa un
sistema de administracin de incidentes que monitorea el tiempo de atencin
de los casos que presente el cliente y de seguir la normativa establecida y
las ventajas que esto otorga.
Santilln Pinedo, Karla & Tornero Mendoza, Ludver (Trujillo 2001),
Sistema de Informacin de Control de Almacn de la Direccin Regional de
Educacin de La Libertad DRELL, presentan su tesis con la que
obtuvieron los Ttulos Profesionales de Ingenieros de Sistemas en la
Universidad Csar Vallejo. Santilln & Tornero con este proyecto de tesis
buscan mejorar la gestin del rea de almacn de la sede central de la
DRELL, en la cual se realiz un estudio para poder lograr los objetivos
institucionales de la misma, incluyendo eficiencia y eficacia en los trmites
que se desarrollan, acceso directo y rpido a la informacin, distribucin gil
y rpida de los artculos que piden los usuarios de la DRELL, monitoreo
constante del stock de almacn, entre otros procesos mejorados que son
propios de dicha rea.

Aplicacin Web
18
Relacin: Esta tesis se toma en cuenta porque implementa un sistema que

centraliza la informacin de los equipos informticos, para un mejor control
de almacn con los respectivos procesos que se llevan a cabo, para
finalmente con la informacin brindada sirva de apoyo para nuevas
adquisiciones.
Antecedentes Internacionales:
Pesntez Huerta, lvaro Eduardo (Guayaquil, Ecuador 2007),

Elaboracin de un Plan de Mantenimiento Predictivo y Preventivo en
Funcin de la Criticidad de los Equipos del Proceso Productivo de una
Empresa Empacadora de Camarn, presenta su tesis con la que obtuvo el
Ttulo Profesional de Ingeniero Industrial en la Escuela Superior Politcnica
del Litoral. Pesantez con este trabajo de investigacin busca realizar un plan
de mantenimiento predictivo y preventivo de los equipos, el cual contendr el
detalle del mantenimiento recomendado por los fabricantes y los tcnicos
internos y/o externos de la empresa; as como tambin el detalle de cada
equipo y cules sern las frecuencias de los diversos mantenimientos
preventivos establecidos.
Relacin: Esta tesis se toma en consideracin porque implementa un plan
de mantenimiento predictivo y preventivo enfocado a brindar una gua
confiable de los tipos y frecuencias de mantenimiento para los equipos, esta
gua servir como modelo para desarrollar los mdulos webs de
mantenimiento predictivo, preventivo y correctivo de la aplicacin web a
desarrollar.
Espinoza Saavedra, Daniel (Valparaso, Chile 2004), Estudio del
Sistema de Monitoreo y Registro de Inventarios de Compras y su Integracin
Estratgica mediante el Control de Gestin, presenta su tesis con la que
obtuvo el Grado de Magster en Gestin mencin Control en la Universidad
de Valparaso. Espinoza con este proyecto de investigacin busca presentar
las posibilidades que ofrece un modelo de control dentro de un sistema de
inventarios
de
compras
mediante
la
aplicacin
de
los
conceptos
constructivos de un cuadro de mando.

Aplicacin Web
19
Relacin: Esta tesis se toma en cuenta porque nos proporciona informacin

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

2.6.1. MUNICIPALIDAD PROVINCIAL DE PIURA:
Misin, Visin y Objetivos de la Institucin:
Misin
Gobernar, conducir y liderar el desarrollo de la provincia, gestionando y
promoviendo el desarrollo sostenible, integral y el bienestar humano, mediante
acciones de concertacin institucional y de participacin de la sociedad civil
organizada. [PEI MPP]
Visin
La Municipalidad Provincial de Piura al 2014, aplica una gestin moderna,
eficiente y participativa, con creciente igualdad de oportunidades, sistema
distrital democrtico, institucionalidad participativa, mbitos urbano y rural
articulados, con hombres y mujeres emprendedoras y ciudades abiertas,
seguras, sostenibles, ordenadas, modernas y limpias. [PEI MPP]
Objetivos
1) Conducir, promover y fomentar el desarrollo socio-econmico integral,
sostenible y armnico, priorizando y planificando las necesidades del distrito y
provincia de Piura.
2) Promover el bienestar del ciudadano con la adecuada prestacin de los
servicios pblicos locales que satisfagan sus necesidades vitales de
salubridad, vivienda, abastecimiento, seguridad, cultura, recreacin, transporte
y comunicaciones.

Aplicacin Web
20
3) Representar poltica y organizacionalmente a los vecinos en el Gobierno

Local, mediante programas de participacin comunal y el ejercicio del derecho
de peticin.
4) El Ejercicio de la Funcin Conciliadora.
5) Desarrollar programas sociales bsicos.
6) Promover el desarrollo econmico local mediante el impulso a las pequeas
y micro empresas (PYMES), de acuerdo a las normas y polticas regionales y
nacionales.
7) Brindar la infraestructura, apoyo, asesoramiento a los promotores y agentes
del desarrollo econmico, facilitndoles el espacio fsico para sus actividades
de acuerdo a la normatividad vigente. [ROF MPP]
Polticas Generales de la Institucin:
OBJETIVOS ESTRATEGICOS
LINEAS POLITICAS
OBJETIVO META
La Municipalidad Provincial de Piura es
Poltica N 01
una corporacin edil eficaz y eficiente que
Desarrollo Institucional
resuelve el 100 % de sus operaciones de

manera moderna, gil y dinmica.
La Municipalidad Provincial de Piura
cuenta con una Red de Participacin
Ciudadana
mediante
la
cual
ha
organizado el 100 % de Juntas Vecinales

Poltica 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 educacin,
salud y trabajo.
Poltica N 03
cuenta con un Sistema de Desarrollo
Desarrollo Econmico y
Econmico y Financiero que le permite
Financiero
incrementar sus recursos en un 5 %

anual.
La Municipalidad Provincial de Piura es la
Poltica N 04

Aplicacin Web
primera en el pas que logra delimitar y
21
Organizacin Territorial
adecuar integralmente el 100 % de su

territorio.
Cuadro N 001: Poltica Institucionales
Fuente: PEI MPP
Actividades Principales de la Institucin:

1) Planificar integralmente el desarrollo local y el ordenamiento territorial, en el
nivel provincial.
2) Promover permanentemente la coordinacin estratgica de los planes
integrales de desarrollo de los distritos. Los planes referidos a la organizacin
del espacio fsico y uso del suelo que emitan las municipalidades distritales
debern sujetarse a los planes y las normas generales de la Municipalidad
Provincial de Piura.
3) Promover, apoyar y ejecutar proyectos de inversin y servicios pblicos
municipales que presenten objetivamente externalidades o economas de
escala de mbito provincial; para cuyo efecto suscribir convenios con las
respectivas municipalidades distritales.
4) Emitir las normas tcnicas generales, en materia de organizacin del
espacio fsico y uso del suelo, as como sobre proteccin y conservacin del
medio ambiente.
5) Proponer proyectos de ley, a travs de iniciativas legislativas. [ROF MPP]
Organigrama de la Institucin:
Toda empresa cuenta en forma implcita o explcita con cierto juego de
jerarquas y atribuciones asignadas a los miembros o componentes de la
misma. En consecuencia se puede establecer que la estructura organizativa
de una empresa es el esquema de jerarquizacin y divisin de las funciones
componentes de ella.
Jerarquizar es establecer lneas de autoridad (de arriba hacia abajo) a travs
de los diversos niveles y delimitar la responsabilidad de cada empleado ante
solo un supervisor inmediato. Esto permite ubicar
a las unidades
administrativas en relacin con las que le son subordinadas en el proceso de

la autoridad. El valor de una jerarqua bien definida consiste en que reduce la
Aplicacin Web
22
confusin respecto a quien da las rdenes y quien las obedece. Define como
se dividen, agrupan y coordinan formalmente las tareas en los puestos. [MPP]

Aplicacin Web
23
Grfico N 001: Organigrama de la Municipalidad Provincial de Piura

Fuente: Municipalidad Provincial de Piura (MPP)
Aplicacin Web
24
2.6.2. OFICINA DE INFORMATICA:

Misin, Visin, Objetivos y Metas de la Oficina de Informtica:
Misin
Promover el desarrollo y la utilizacin de un sistema de informacin moderno
de
acuerdo
las
necesidades
de
los
diferentes
usuarios,
proporcionando datos oportunos y de calidad en lo relativo a prevencin,

atencin y control de los problemas informticos, elctricos y electrnicos
contribuyendo a la mejora de la calidad de servicio de las diferentes
dependencias de la Municipalidad Provincial de Piura. [ROF MPP]
Visin
Contar con la confianza y satisfaccin de nuestros Usuarios a travs de un
sistema que proporcione informacin y servicios oportunos, seguros, y de
calidad, brindando a sus necesidades respuestas integrales, rpidas y
efectivas a travs de un equipo multidisciplinario con calidad humana, tcnica
y profesional. [ROF MPP]
Objetivos
1) Optimizar las necesidades de automatizacin de procesos.
2) Optimizar las necesidades de informacin de los usuarios finales.
3) Desarrollar los sistemas informticos, cuidando que cumplan con la
ergonoma de interfase usuario mquina y los niveles de seguridad requeridos.
4) Implementar los sistemas informticos conjuntamente con los usuarios.
5) Mejorar el mantenimiento de los sistemas de informticos, luego de estudiar
los requerimientos de los usuarios.
6) Planificar y administrar los proyectos, que se generan como consecuencia
de la necesidad del desarrollo e implementacin de los sistemas informticos.
7) Mejorar la administracin de los recursos humanos y equipos asignados a
esta oficina.
8) Supervisar y emitir normas de uso y estandarizacin para el correcto
funcionamiento y utilizacin de los equipos por parte de los usuarios.
9) Brindar el mantenimiento preventivo y correctivo de la infraestructura de red
y de los equipos informticos.
10) Generar planes de mantenimiento y observar su cumplimiento.
11) Mejorar la administracin de la base de datos.
Aplicacin Web
25
12) Implementar la infraestructura de telecomunicaciones para el ptimo

funcionamiento de los sistemas informticos. [ROF MPP]
Metas
1)
Facilitar
el desarrollo
de la
Corporacin
Municipal
mediante
la
implementacin de un Sistema de Comunicaciones y Tecnologas de

Informacin durante el presente ao 2011 con un presupuesto de 30316.93
nuevos soles.
2) Gestionar y resolver el desarrollo de los medios eficientes de comunicacin
simultnea entre las Juntas Vecinales y la Corporacin Municipal durante el
presente ao 2011 con un presupuesto de 9603.50 nuevos soles.
3) Proporcionar las herramientas tecnolgicas que permitan una adecuada
comunicacin y acceso a la informacin estadstica y difusin de
convocatorias y logros de la Corporacin Municipal durante el presente ao
2011 con un presupuesto de 1240.50 nuevos soles.
4) Gestionar, programar, promover y resolver la implementacin del gobierno
electrnico y adecuar el resultado progresivo de la organizacin territorial
durante le presente ao 2011 con un presupuesto de 396.20 nuevos soles.
5) Disear procedimientos que simplifiquen mecanismos administrativos
durante el presente ao 2011 con un presupuesto de 18441.61 nuevos soles.
[POI MPP]
2.6.3. SOPORTE TECNICO:

Descripcin del rea de Negocio:
El rea de Negocio es Soporte Tcnico, pertenece a la Oficina de Informtica
y a su vez esta oficina pertenece a la Gerencia de Tecnologas y Sistemas de
Informacin, se encarga de dar respaldo a los equipos electrnicos y elctricos
que se encuentran dentro de la Municipalidad de Piura y en sus Unidades
Orgnicas Externas.
Soporte Tcnico, alberga equipos, materiales, herramientas y repuestos para
que los usuarios o trabajadores de la Municipalidad de Piura soliciten servicios
de atencin para solucionar problemas de hardware y software de los equipos
electrnicos e informticos, problemas de equipos elctricos y problemas de
equipos telefnicos.
Aplicacin Web
26
Soporte Tcnico soluciona problemas de hardware, software, elctricos,

electrnicos, telefnicos y de redes de la mayora de equipos que se
encuentran en la municipalidad, se limita a estas actividades y no a
administrar las polticas de seguridad y privacidad de la red de trabajo o
dominio.
Dada la diversidad de incidentes y solicitudes que pueden producirse en ST
resultan difciles que las atenciones sean de manera oportuna dado que
muchas veces estos problemas pueden ser solucionados de manera fcil por
el usuario o trabajador de la municipalidad de Piura. [EL AUTOR]
2.6.4. SISTEMA DE CONTROL:

QU ES UN SISTEMA DE CONTROL?
Segn Alvarez Brotons (2004):
Un sistema dinmico puede definirse conceptualmente como un ente que recibe
unas acciones externas o variables de entrada, y cuya respuesta a estas acciones
externas son las denominadas variables de salida.
Las acciones externas al sistema se dividen en dos grupos, variables de control,
que se pueden manipular, y perturbaciones sobre las que no es posible ningn
tipo de control. El grfico 2 ilustra de un modo conceptual el funcionamiento de un
sistema.
Grfico N 002: Esquema general de un sistema

Fuente: Alvarez Brotons

Aplicacin Web
27
Dentro de los sistemas se encuentra el concepto de sistema de control. Un

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

Aplicacin Web
28
Grfico N 003: Esquema general de un sistema de control

Fuente: Alvarez Brotons
2.6.5. APLICACIN WEB:

En este inciso se darn a conocer algunos conceptos bsicos del contexto de este
trabajo, con la finalidad de situar al problema dentro de un conjunto de
conocimientos. Dentro de estos conocimientos se darn algunos conceptos
acerca de patrones de diseo, dentro de ellos el patrn MVC, sus partes y
caractersticas, despus se hablar acerca de los frameworks, un breve
comparativo entre estos y los patrones de diseo y finalmente se hace un
pequeo y breve anlisis de algunos otros frameworks para web existentes.
Patrones de diseo
Definicin e historia
Para comenzar es importante definir lo que un patrn de diseo es, aunque

existen varias definiciones al respecto, un patrn de diseo es una solucin de
calidad para un problema recurrente de diseo. Pero no son aplicables
nicamente en el campo computacional, tambin existen patrones para varias
actividades de la vida cotidiana, aunque con algunas diferencias pero tienen el
mismo propsito que en el mbito computacional, proporcionar una base para
poder realizar una actividad, mejorando la calidad del producto que esa actividad
de como resultado [Freeman, 2004].
Aplicacin Web
29
Hay patrones que abarcan las distintas etapas del desarrollo; desde el anlisis
hasta el diseo y desde la arquitectura hasta la implementacin. En el caso de los
patrones computacionales un software estructurado, modulado posee una mejor
calidad y es ms sencillo corregir errores, implementar mejoras y actualizaciones,
ya que un software que posee algn patrn de diseo es ms sencillo de
modificar que un software que no posee en absoluto un patrn. Pero Cmo se
debe escoger el patrn adecuado?, esta es una pregunta un poco difcil de
responder ya que la mayora de las actividades de desarrollo o produccin no se
ajustan perfectamente a un patrn definido, por eso es importante llevar acabo un
anlisis para poder visualizar cual ser el patrn que mejor se ajuste a las
necesidades de desarrollo. En s "un patrn de diseo puede verse como una
plantilla que puede ser aplicada en muchas situaciones diferentes" [Gamma,
1995], para dar una buena solucin.
Los patrones se descubren como una forma indispensable de enfrentarse a la
programacin a raz del libro "Design Patterns - Elements of Reusable Software"
de Erich Gamma, Richard Helm, Ralph Jonson y John Vlissides, a partir de
entonces los patrones de diseo que aparecen en ese libro son conocidos como
los patrones de la pandilla de los cuatro (GoF, gang of four), y comienzan a
desarrollarse variaciones y nuevos patrones, en poco tiempo se multiplicaron por
100 y no se limitaban a patrones de diseo sino que cubran todo los que se
entiende por ingeniera del software (desde el anlisis hasta la implementacin)
[Gamma, 1995].
Elementos esenciales
En general un patrn tiene cuatro elementos esenciales:

El nombre del patrn: que se utiliza para describir un problema de diseo, sus
soluciones y sus consecuencias, en una palabra o dos. Este nombre ayuda a que
sea ms sencillo de identificarlo, al hablar o escribir de l e incluso puede dar una
idea general o una descripcin de dicho patrn.
El problema: describe cuando aplicar el patrn, tambin puede incluir detalles
especficos que se deben cumplir o problemas un poco ms detallados, los cuales
en conjunto engloban el problema central a solucionar.
Aplicacin Web
30
La solucin: describe los elementos que forman el diseo, sus relaciones, sus
responsabilidades y sus colaboraciones. La solucin no describe un diseo o
implementacin en particular ya que un patrn de diseo puede verse como una
plantilla que se aplica a un problema especfico.
Las consecuencias: son los resultados y desventajas de haber aplicado el
patrn. Estas consecuencias implican un impacto en las caractersticas del
sistema como: flexibilidad, portabilidad y extensin. Adems de que ayudan a
medir el desempeo del sistema.
Clasificacin
El grupo de GoF clasific los patrones en 3 grandes categoras basadas en su

propsito: creacionales, estructurales y de comportamiento [Gamma, 1995].
Creacionales: tratan con las formas de crear instancias de objetos. El objetivo de
estos patrones es de abstraer el proceso de instanciacin y ocultar los detalles de
cmo los objetos son creados o inicializados.
Estructurales: Los patrones estructurales describen como las clases y objetos
pueden ser combinados para formar grandes estructuras y proporcionar nuevas
funcionalidades. Estos objetos adicionados pueden ser incluso objetos simples u
objetos compuestos.
Comportamiento: Los patrones de comportamiento ayudan a definir la
comunicacin e iteracin entre los objetos de un sistema. El propsito de este
patrn es reducir el acoplamiento entre los objetos.
Patrn de diseo Model View Controller (MVC)
Una vez establecidas las bases de los patrones de diseo, se puede ya comenzar
a hablar ms del patrn que se utiliz durante este trabajo: el patrn MVC. Estas
son las siglas de Model View Controller, en espaol Modelo Vista Controlador.
Esto tambin se ve reflejado en que cada una de estas palabras representa cada
uno de los 3 componentes del patrn MVC. Cada parte juega un rol fundamental
para la completa integracin del sistema.
Aplicacin Web
31
Definicin e historia
"El propsito de este patrn es simplificar la implementacin de aplicaciones de

acuerdo a las peticiones de los usuarios y los datos a desplegar" [Harrop, 2005].
La definicin un poco ms formal sera: MVC es un patrn de diseo de software
que separa los datos de una aplicacin, la interfaz de usuario, y la lgica de
control en tres componentes distintos de forma que las modificaciones al
componente de la vista, o a cualquier parte del sistema puedan ser hechas con un
mnimo impacto en el componente del modelo de datos o en los otros
componentes del sistema. Este patrn cumple perfectamente el cometido de
modularizar un sistema.
El patrn MVC fue descrito por primera vez en 1979 por Trygve Reenskaug, quin
trabajaba en Smalltalk en los laboratorios de investigacin de la Xerox. Este
patrn se ve frecuentemente utilizado en aplicaciones web, donde la vista es la
pgina HTML y el cdigo provee de datos dinmicos a la pgina. Las aplicaciones
web complejas continan siendo ms difciles de disear que las aplicaciones
tradicionales de escritorio, el patrn MVC se presenta como una solucin para
ayudar a disminuir dicha complejidad.
Componentes
Los 3 principales componentes del patrn MVC son:

Modelo: Representa los datos que el usuario est esperando ver, en algunos
casos el Modelo consiste de Java Beans.
Vista: es la responsable de transformar el modelo para que sea visualizada por el
usuario, ya sea en un archivo de texto normal o en una pgina web (HTML o JSP)
que el navegador pueda desplegar. En s el propsito de la vista es convertir los
datos para que al usuario le sean significativos y los pueda interpretar fcilmente.
La vista no debe trabajar directamente con los parmetros del request, debe
delegar esta responsabilidad al controlador.
Controlador: es la parte lgica que es responsable del procesamiento y
comportamiento de acuerdo a las peticiones (requests) del usuario, construyendo
Aplicacin Web
32
un modelo apropiado, y pasndolo a la vista para su correcta visualizacin. En el

caso de una aplicacin web Java en la mayora de los casos el controlador es
implementado por un servlet.
Tipos de patrones MVC
Actualmente existen dos tipos de patrn MVC:

Servidor Web/Aplicacin
Grfico N 004: MVC de arquitectura Tipo 1

Fuente: Walls, 2005
Como se muestra en el Grfico 4 en el Tipo 1 de MVC las pginas JSP estn en el
centro de la aplicacin, y contienen tanto la lgica de control como la de
presentacin. Este tipo de arquitectura funciona de la siguiente manera: el cliente
hace una peticin a una pgina JSP; se construye la lgica de la pgina,
generalmente en objetos Java o como se les conoce en Ingls Plain Old Java
Objects (POJOs) y se transforma el modelo para ser desplegado una vez ms.
Servidor Web/Aplicacin
Grfico N 005: MVC de arquitectura Tipo 2

Aplicacin Web
33
Fuente: Walls, 2005

En el modelo de Tipo 2 de MVC, que se aprecia en el Grfico 5, se puede
observar que ya existe una clara separacin entre el controlador y la vista, ya que
ahora es directamente el controlador quien recibe la peticin, prepara el modelo y
lo transforma para que sea desplegado en la vista. Este tipo de arquitectura MVC
es el que se utiliza para aplicaciones ms complejas, ya que para una aplicacin
sencilla puede utilizarse el Tipo 1. La tecnologa JSP no es la nica que se puede
emplear para las vistas, existen otro tipo de tecnologas que pueden servir como
vistas.
Frameworks
Un framework es un trmino utilizado en la computacin en general, para referirse
a un conjunto de bibliotecas, utilizadas para implementar la estructura estndar de
una aplicacin. Todo esto se realiza con el propsito de promover la reutilizacin
de cdigo, con el fin de ahorrarle trabajo al desarrollador al no tener que rescribir
ese cdigo para cada nueva aplicacin que desee crear. Existen diferentes
frameworks para diferentes propsitos, algunos orientados al desarrollo de
aplicaciones web, otros para desarrollar aplicaciones multiplataforma, para un
sistema operativo o lenguaje de programacin en especfico, entre otros.
Segn Gamma, el framework determina la arquitectura de una aplicacin
[Gamma, 1995]. Este es un buen enfoque, ya que el framework se encarga de
definir la estructura general, sus particiones en clases y objetos, las
responsabilidades clave, as como la colaboracin entre dichas clases y objetos.
Todos estos parmetros son definidos por el framework, evitando que el usuario
tenga que definirlos y se pueda enfocar en cosas especficas de su aplicacin.
"El framework captura las decisiones de diseo que son comunes a su dominio de
aplicacin" [Gamma, 1995]. Un framework no slo promueve la reutilizacin de
cdigo sino tambin la reutilizacin de diseo.
Un framework ayuda a que se desarrolle una aplicacin de una manera ms
rpida, ya que se no pierde tiempo en algunos detalles de diseo que muchas
veces quitan ms tiempo del que tomo construir en s la lgica de la aplicacin.
Adems las aplicaciones que se construyen tienen estructuras similares, son ms
Aplicacin Web
34
fciles de mantener y consistentes para los usuarios. Pero esto tiene como
consecuencia una mnima perdida de libertad en las cuestiones de diseo.
En algunas ocasiones un desarrollador tiene algunas dificultades para disear una
aplicacin, esto todava es ms difcil para el desarrollador del framework, ya que
desarrollar un framework requiere de muchos cuidados, porque cuando se lanza
uno nuevo, se espera que pueda servir para muchos tipos de aplicaciones pero
con arquitecturas y requerimientos similares. Es decir trata de englobar toda una
gamma de aplicaciones dentro de un solo estndar, lo cual puede ser el xito o el
fracaso del mismo, por eso se intenta crear frameworks lo ms extensibles y
flexibles posibles, para que con algunos cambios mnimos se pueda actualizar o
corregir. Las aplicaciones que se desarrollan a partir de un framework, est ligada
al mismo, por eso las aplicaciones deben de evolucionar y crecer al mismo tiempo
que crece el framework, ya que un cambio en alguna interfaz del mismo
significar un cambio de la aplicacin, dependiendo de que tan drstico sea el
cambio.
Relacin entre patrones de diseo y frameworks
Los frameworks utilizan un variado nmero de patrones de diseo, ya que as

logran soportar aplicaciones de ms alto nivel y que reutilizan una mayor cantidad
de cdigo, que uno que no utiliza dichos patrones. "Los patrones ayudan a hacer
la arquitectura de los frameworks ms adecuada para muchas y diferentes
aplicaciones sin necesidad de rediseo" [Gamma, 1995]. Por esta razn es
importante que se documenten que patrones utiliza el framework para que los que
se encuentren familiarizados con dichos patrones puedan tener una mejor visin y
poder adentrarse en el framework ms fcilmente.
Aunque muchas personas cometen el error de confundir a los frameworks con los
patrones de diseo, segn los cuatro autores del libro "Design Patterns - Elements
of Reusable" existen 3 diferencias fundamentales entre ellos [Gamma, 1995]:
Los patrones de diseo son ms abstractos que los frameworks: el cdigo
del framework se escribe una vez, en cambio cada vez que se requiere un patrn
de diseo se debe de codificar con respecto a la aplicacin. Una fortaleza de los
frameworks es que pueden ser escritos en un lenguaje de programacin, pueden
ser reutilizados e incluso ejecutados, esto tambin podra considerarse una
Aplicacin Web
35
debilidad dependiendo del punto de vista (siempre y cuando no sean

multiplataforma o se encuentre en diferentes versiones por lenguaje de
programacin), ya que estn enfocados a un slo lenguaje de programacin, en
cambio un patrn de diseo puede ser aplicado a cualquier lenguaje de
programacin, pero se tiene que reescribir desde cero.
Los patrones de diseo son elementos arquitectnicos ms pequeos que
los frameworks: un solo framework contiene varios patrones de diseo, pero
jams es al contrario.
Los patrones de diseo son menos especializados que los frameworks:
existen frameworks con un dominio especfico, adems los patrones son un poco
ms generales debido a que pueden ser utilizados en un mayor nmero de
aplicaciones de varios tipos.
Frameworks para aplicaciones web

Actualmente existen algunos frameworks para desarrollar aplicaciones web, que
es de las ramas ms importantes en las que se usan los frameworks. La mayora
de ellos utilizan el patrn de diseo MVC del cual se habl previamente. Todos los
frameworks tienen caractersticas especiales que los hacen nicos para sobresalir
y poder seguir en el mercado, adems de poseer las siguientes caractersticas
comunes [Johnson, 2003]:
Utilizan un solo servlet que tiene la funcin de controlador, para toda la
aplicacin o gran parte de ella. Se configura el deployment descriptor "web.xml"
para que todas las URL's tengan que pasar forzosamente por dicho servlet.
Una configuracin, generalmente escrita en un archivo XML, en donde se le
indicar al servlet controlador, a travs de propiedades, a quien delegar la
responsabilidad de atender la peticin entrante. Algunas veces esas propiedades
estn indicadas de acuerdo a los URL's y de acuerdo al URL entrante es como se
delega la responsabilidad.
Las vistas pueden tener nombres claves, sin necesidad que exista una relacin
con el nombre del archivo de la vista. El framework se encarga de realizar dicha
conversin para poder obtener el nombre de la vista que se tiene que cargar para

Aplicacin Web
36
que sea desplegada. La implementacin de una vista con un nombre en particular

puede cambiar sin afectar cdigo del controlador.
Cuando se va a desarrollar una aplicacin web, el desarrollador se debe fijar en si
desea realizar una aplicacin extremadamente sencilla o si quiere desarrollar una
verdadera aplicacin web, que tendr actualizaciones, correcciones y mejoras a
futuro. Para esto es recomendable que se elija un framework de aplicacin web
que utilice el patrn web MVC. Con el fin de que se pueda hacer la separacin
entre los 3 elementos principales y pueda aprovechar todas las ventajas que
brinda este patrn de diseo. Para poder aprovechar tambin las ventajas
adicionales que brinda el framework para la integracin con otras herramientas u
otros servicios.
A continuacin se enlistan algunos de los frameworks para aplicaciones web ms
populares: Struts, WebWork, Maverick y Spring, el framework sobre el cual se
basa esta tesis, ser analizado con mayor detalle ms adelante en este
documento. Este listado y anlisis sencillo de cada uno de estos frameworks se
da con la razn de poder saber cuales son los frameworks contra los que compite
Spring, dentro del mismo mbito, as como sus caractersticas principales,
ventajas y desventajas.
Struts
Struts es uno de los frameworks MVC ms utilizados, ya que fue uno de los
pioneros en el campo, fue creado por Craig McClanahan, creador del famoso
motor servlet Tomcat, ambos son distribuidos por Apache. Este framework fue
lanzado a mediados del ao 2000, y a partir de esta fecha comenz a tener
popularidad, y en la actualidad existen algunos componentes extra que se
adaptan a Struts, lo que le da un mayor campo de accin. Struts es open source,
por lo que no requiere licencia para su uso [Johnson, 2003].
Adems cumple una de las funcionalidades bsicas que se mencionaron acerca
de los frameworks para aplicaciones web, ya que implementa un solo controlador
(ActionServlet) que evala las peticiones del usuario mediante un archivo
configurable (struts-config.xml) para poder dirigirlas a un action que procesa el
request. El lenguaje de programacin que utiliza es Java, as como Java Beans
como modelo.
Aplicacin Web
37
Algunas de las ventajas que Struts brinda son: que existe un variado nmero de
trabajos y proyectos ya hechos lo que brinda un mayor nmero de ejemplos para
poder tomar un punto de partida y de referencia; otra ventaja es que brinda
libreras de tags para HTML bastante tiles. Entre las desventajas de framework
se puede observar que muchas veces puede ser difcil trabajar con los
ActionForms, adems de que el proyecto posiblemente desaparezca en los aos
venideros, otra de las desventajas de Struts es que muy ligado con la tecnologa
JSP, por lo que muchas veces se dificulta integrarlo con alguna otra tecnologa
para las vistas.
Maverick
Este es otro framework MVC open source que existe en el mercado, pero a
diferencia de los dems este no cuenta con sus propias libreras de tags. Sin
embargo cumple con las funcionalidades tpicas mencionadas, como el de tener
un solo servlet controlador central como punto de entrada, el cual lleva el nombre
de Dispatcher, que est definido en el Deployment Descriptor de la aplicacin web
(web.xml). Maverick cuenta con un archivo XML en el que se guarda toda la
configuracin del mismo (maverick.xml). Una caracterstica de Maverick es que
nicamente acepta un solo controlador central y un archivo de configuracin por
aplicacin web, lo que muchas veces al desarrollar aplicaciones ms grandes y
complejas se puede volver confuso y difcil de configurar. [Johnson, 2003]
Maverick es un framework mucho ms configurable que Struts, lo que brinda
cierta flexibilidad, tambin incluye varias clases para poder extender y cambiar el
flujo del trabajo o workflow en Ingls. Maverick es usualmente usado para crear
nuevos controladores que sean capaces de procesar nuevas peticiones. Los
controladores son Java Beans, y el framework pone de manera transparente las
propiedades de los beans.
Una caracterstica interesante de Maverick es el bsico y fcil uso de la
funcionalidad del dispatcher. Tambin es multiplataforma ya que ha sido adaptado
para los lenguajes .NET y PHP.
WebWork

Aplicacin Web
38
Este es un framework ms reciente ya que fue lanzado a mediados del ao 2002,

una de las personas que ha trabajado en este proyecto fue Rickard Oberg, quien
ha participado en proyectos como JBoss, entre otros. "WebWork, a pesar de su
nombre, no es puramente un framework para aplicaciones web. Adopta un
acercamiento prctico que minimiza la dependencia del cdigo de la aplicacin de
los conceptos web."[Johnson, 2003].
El framework WebWork est basado en el patrn de diseo de Comandos o
CommandPattern. Cada accin es un comando, que es creado para manejar un
request, sus propiedades son puestas de manera transparente, ya que cada
accin es un Java Bean.
WebWork cuenta, al igual que Struts y Spring con su propia librera de tags para
JSP, las cuales ayudan a realizar distintas tareas de una manera ms gil, pero no
es la nica tecnologa para vista que soporta, tambin incluye soporte para
Velocity.
Una de las ventajas de WebWork es que cuenta con una arquitectura simple y las
clases son fciles de extender. Pero como todo, tiene sus desventajas, la creacin
de una accin (action) por cada request puede llegar a ser algo confuso cuando
no se tiene muchos datos en el request; impone el patrn de diseo Command en
cada interaccin del usuario, ya sea bueno o malo utilizarlo en dicha interaccin;
es difcil saber de que tipo son las excepciones que se lanzan. Como este
framework es relativamente reciente no existe mucha documentacin y ejemplos
al respecto lo que puede resultar a veces frustrante cuando se requiere buscar
algn ejemplo o tutorial que pueda servir.
Spring
Es un framework de aplicacin, que a diferencia de otros single-tier como Struts,

Spring propone estructurar toda una aplicacin de una manera consistente y
productiva, conjuntando lo mejor de cada uno de los frameworks single-tier para
crear una arquitectura coherente. En s Spring ha surgido como una solucin para
poder disfrutar de los beneficios clave de J2EE, mientras que minimiza la
complejidad encontrada en el cdigo de la aplicacin. [Johnson, 2005]

Aplicacin Web
39
Spring esta basado en la filosofa de que un framework debe proveer una gua
hacia una buena prctica, es decir debe hacer la cosa correcta sencilla de hacer.
Mezclando la correcta combinacin de flexibilidad y restriccin, la cual es la clave
en el buen diseo de un framework.
Spring tambin cuenta con algunas de las caractersticas generales de los
frameworks web, ya que cuenta con un mdulo para poder desarrollar
aplicaciones web de manera sencilla, utilizando el patrn de diseo MVC antes
mencionado. Contando con un controlador central (DispatcherServlet), adems de
la capacidad de tener varios controladores secundarios para el procesamiento de
cada una de las peticiones.
Tambin se basa en el diseo de las clases extendiendo o implementando
interfaces, lo cual es un mejor diseo orientado a objetos, ya que promueve la
reutilizacin de cdigo. Adems Spring cuenta con algunos tags para las
diferentes tecnologas para vista que existen. Las cuales tienen funciones
diferentes como vincular formularios, validacin, despliegue de informacin, entre
otras.
Uno de los aspectos clave y ventajas de Spring, es que cuenta con una
arquitectura modularizada, y se pueden utilizar cada uno de estos mdulos de
manera independiente. Cada uno esta enfocado en una tarea especfica, y
algunos de ellos son para la integracin con alguna herramienta o incluso cuenta
con la posibilidad de integrase con los otros frameworks mencionados
anteriormente. Esto con el propsito de proponer la filosofa de "no intentar
reinventar la rueda", la cual quiere decir que si ya existe en el mercado una
herramienta que realice una tarea de manera eficiente en un mbito o rea en
particular se debe conjuntar con Spring para llevar a cabo un mejor desempeo y
poder sacar as un mejor resultado y una aplicacin de mayor calidad.
En conclusin cada framework tiene sus ventajas y desventajas, escoger uno es
una
decisin
del
desarrollador,
dependiendo
de
sus
necesidades
requerimientos, del tamao del proyecto a desarrollar, as como de su experiencia

con tecnologas existentes que se integren fcilmente con el framework que haya
elegido. Esto con el fin de aprovechar algunas tecnologas que estn enfocadas
en un rea especfica, para que brinde una mejor y ms sencilla forma de llevar a
cabo la tarea. Esta fue una de las razones por la cual se decidi incursar dentro
Aplicacin Web
40
de las caractersticas de Spring, y despus de un anlisis se llego a la conclusin

de que es un buen framework que cumple con la mayora de las caractersticas,
de las cuales otros frameworks escasean.
Una de las cuestiones que ha hecho a Spring evolucionar de manera muy rpida
en tan poco tiempo, es que se han incrementando de una manera increble el
nmero de proyectos que utilizan esta herramienta a travs del ltimo ao. Esto
conlleva a que la cantidad de personas interesadas en este framework aumente,
as como el soporte, el nmero de foros de opinin y la publicacin de un mayor
nmero de libros y tutoriales.
2.6.6. GESTIN DE INCIDENTES:

Segn OSIATIS S.A. V2.0:
Visin General
La Gestin de Incidentes tiene como objetivo resolver cualquier incidente que
cause una interrupcin en el servicio de la manera ms rpida y eficaz posible.
La Gestin de Incidentes no debe confundirse con la Gestin de Problemas, pues
a diferencia de esta ltima, no se preocupa de encontrar y analizar las causas
subyacentes a un determinado incidente sino exclusivamente a restaurar el
servicio. Sin embargo, es obvio, que existe una fuerte interrelacin entre ambas.
Las propiedades y funcionalidades de la Gestin de Incidentes se resumen
sucintamente en el siguiente grfico:

Aplicacin Web
41
Grfico N 006: Gestin de Incidentes

Fuente: OSIATIS S.A. V2.0
Introduccin y Objetivos
Los objetivos principales de la Gestin de Incidentes son:
Detectar cualquiera alteracin en los servicios TI (Tecnologas de

Informacin).
Registrar y clasificar estas alteraciones.
Asignar el personal encargado de restaurar el servicio segn se define

en el SLA (Acuerdo de Nivel de Servicio) correspondiente.
Esta actividad requiere un estrecho contacto con los usuarios, por lo que el Centro
de Servicios (Service Desk) debe jugar un papel esencial en el mismo.
El siguiente diagrama resume el proceso de gestin de incidentes:

Aplicacin Web
42
Grfico N 007: Proceso de Gestin de Incidentes (resumen)

Aunque el concepto de incidencia se asocia naturalmente con cualquier
malfuncionamiento de los sistemas de hardware y software segn el libro de
Soporte del Servicio de ITIL (Bibliotecas de Infraestructura de las Tecnologas de
Informacin) un incidente es:
Cualquier evento que no forma parte de la operacin estndar de un servicio y
que causa, o puede causar, una interrupcin o una reduccin de calidad del
mismo.
Por lo que casi cualquier llamada al Centro de Servicios puede clasificarse como
un incidente, lo que incluye a las Peticiones de Servicio tales como concesin de
nuevas licencias, cambio de informacin de acceso, etc. siempre que estos
servicios se consideren estndar.
Cualquier cambio que requiera una modificacin de la infraestructura no se
considera un servicio estndar y requiere el inicio de una Peticin de Cambio
(RFC) que debe ser tratada segn los principios de la Gestin de Cambios.
Los principales beneficios de una correcta Gestin de Incidentes incluyen:
Mejorar la productividad de los usuarios.
Cumplimiento de los niveles de servicio acordados en el SLA.
Mayor control de los procesos y monitorizacin del servicio.
Optimizacin de los recursos disponibles.

Aplicacin Web
43
Una CMDB (Base de Datos de la Gestin de Configuraciones) ms

precisa pues se registran los incidentes en relacin con los elementos
de configuracin.
Y principalmente: mejora la satisfaccin general de clientes y usuarios.
Por otro lado una incorrecta Gestin de Incidentes puede acarrear efectos
adversos tales como:
Reduccin de los niveles de servicio.
Se dilapidan valiosos recursos: demasiada gente o gente del nivel

inadecuado
trabajando
concurrentemente en
la
resolucin
del
incidente.
Se pierde valiosa informacin sobre las causas y efectos de los

incidentes para futuras reestructuraciones y evoluciones.
Se crean clientes y usuarios insatisfechos por la mala y/o lenta gestin

de sus incidentes.
Las principales dificultades a la hora de implementar la Gestin de Incidentes se

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

incidencias sin registrarlas o se escalan innecesariamente y/o
omitiendo los protocolos preestablecidos.
No existe un margen operativo que permita gestionar los picos de

incidencias por lo que stas no se registran adecuadamente e impiden
la correcta operacin de los protocolos de clasificacin y escalado.
No estn bien definidos los niveles de calidad de servicio ni los

productos soportados. Lo que puede provocar que se procesen
peticiones que no se incluan en los servicios previamente acordados
con el cliente.
Clasificacin del Incidente

Es moneda frecuente que existan mltiples incidencias concurrentes por lo que es
necesario determinar un nivel de prioridad para la resolucin de las mismas.

Aplicacin Web
44
El nivel de prioridad se basa esencialmente en dos parmetros:
Impacto: determina la importancia del incidente dependiendo de cmo

ste afecta a los procesos de negocio y/o del nmero de usuarios
afectados.
Urgencia: depende del tiempo mximo de demora que acepte el cliente

para la resolucin del incidente y/o el nivel de servicio acordado en el SLA.
Tambin se deben tener en cuenta factores auxiliares tales como el tiempo de

resolucin esperado y los recursos necesarios: los incidentes sencillos se
tramitarn cuanto antes.
Dependiendo de la prioridad se asignarn los recursos necesarios para la
resolucin del incidente.
La prioridad del incidente puede cambiar durante su ciclo de vida. Por ejemplo, se
pueden encontrar soluciones temporales que restauren aceptablemente los
niveles de servicio y que permitan retrasar el cierre del incidente sin graves
repercusiones.
Es conveniente establecer un protocolo para determinar, en primera instancia, la
prioridad del incidente. El siguiente diagrama nos muestra un posible diagrama
de prioridades en funcin de la urgencia e impacto del incidente:

Aplicacin Web
45
Grfico 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 algn superior
que pueda tomar decisiones que se escapan de su responsabilidad. A este
proceso se le denomina escalado.
Bsicamente hay dos tipos diferentes de escalado:
Escalado funcional: Se requiere el apoyo de un especialista de ms alto

nivel para resolver el problema.
Escalado jerrquico: Debemos acudir a un responsable de mayor

autoridad para tomar decisiones que se escapen de las atribuciones
asignadas a ese nivel, como, por ejemplo, asignar ms recursos para la
resolucin de un incidente especfico.
El proceso de escalado puede resumirse grficamente* como sigue:

Aplicacin Web
46
* El escalado puede incluir ms niveles en grandes organizaciones, o por el contrario, integrar diferentes
niveles en el caso de PYMES
Grfico N 009: Proceso de Escalado de Incidentes

Proceso
El siguiente diagrama muestra los procesos implicados en la correcta Gestin de
Incidentes:

Aplicacin Web
47
Grfico N 010: Procesos implicados en la Gestin de Incidentes

2.6.7. GESTIN DE PROBLEMAS:

Segn OSIATIS S.A. V2.0:
Visin General
Las funciones principales de la Gestin de Problemas son:
o
Investigar las causas subyacentes a toda alteracin, real o potencial, del

servicio TI.
Determinar posibles soluciones a las mismas.
Proponer las peticiones de cambio (RFC) necesarias para restablecer la

calidad del servicio.
Realizar Revisiones Post Implementacin (PIR) para asegurar que los

cambios han surtido los efectos buscados sin crear problemas de carcter
secundario.
La Gestin de Problemas puede ser:

Reactiva: Analiza los incidentes ocurridos para descubrir su causa y propone
soluciones a los mismos.
Aplicacin Web
48
Proactiva: Monitoriza la calidad de la infraestructura TI y analiza su configuracin

con el objetivo de prevenir incidentes incluso antes de que estos ocurran.
Las interacciones y funcionalidades de la Gestin de Problemas se resumen
sucintamente en el siguiente grfico:
Grfico N 011: Interacciones y Funcionalidades de la Gestin de Problemas

Introduccin y Objetivos
Como se explic en la seccin de Gestin de Incidentes, esta ltima tiene como
exclusivo objetivo el restablecer lo ms rpidamente la calidad del servicio y no el
determinar cules han sido los orgenes y causas del mismo.

Aplicacin Web
49
Cuando algn tipo de incidente se convierte en recurrente o tiene un fuerte

impacto en la infraestructura TI es la funcin de la Gestin de Problemas el
determinar sus causas y encontrar posibles soluciones.
Cabe diferenciar entre:
Problema: causa subyacente, an no identificada, de una serie de incidentes o un
incidente aislado de importancia significativa.
Error conocido: Un problema se transforma en un error conocido cuando se han
determinado sus causas.
Entre las funciones principales de la Gestin de Problemas figuran:
o
Identificar, registrar y clasificar los problemas.
Dar soporte a la Gestin de Incidentes proporcionando informacin y

soluciones temporales o parches.
Analizar y determinar las causas de los problemas y proponer soluciones.
Elevar RFCs a la Gestin de Cambios para llevar a cabo los cambios

necesarios en la infraestructura TI.
Realizar un seguimiento post-implementacin de todos los cambios para

asegurar su correcto funcionamiento.
Realizar informes que documenten no slo los orgenes y soluciones a un

problema sino que tambin sirvan de soporte a la estructura TI en su
conjunto.
Analizar tendencias para prevenir incidentes potenciales.
Los principales beneficios de una correcta Gestin de Problemas:

o
Un aumento de la calidad general de los servicios TI.
Se minimiza el nmero de incidentes.
Los incidentes se solucionan ms rpidamente y, generalmente, en la

primera lnea de soporte TI ahorrando recursos e innecesarios escalados.
La documentacin desarrollada es de gran utilidad para la Gestin de la

Capacidad, Disponibilidad y Niveles de Servicio.

Aplicacin Web
50
Las principales dificultades a la hora de implementar la Gestin de Problemas se

resumen en:
o
Establecer una estrecha colaboracin entre la Gestin de Incidentes y la

de Problemas. Sin sta la Gestin de Incidentes no dispondr de toda la
informacin necesaria para la rpida solucin de los incidentes y la
Gestin de Problemas carecer de la informacin necesaria para
determinar, clasificar y resolver los problemas.
Mantener actualizadas las bases de datos asociadas requiere un

compromiso
por
parte
de
todos
los
agentes
implicados
que
frecuentemente requiere un seguimiento cercano de los responsables de

la infraestructura TI.
o
Aumento de los costes por la contratacin de personal especializado,

aunque estos se vean sobradamente compensados por los beneficios
derivados.
Proceso
Las principales actividades de la Gestin de Problemas son:
Control de Problemas: se encarga de registrar y clasificar los problemas para
determinar sus causas y convertirlos en errores conocidos.
Control de Errores: registra los errores conocidos y propone soluciones a los
mismos mediante RFCs que son enviadas a la Gestin de Cambios. Asimismo
efecta la Revisin Post Implementacin de los mismos en estrecha colaboracin
con la Gestin de Cambios.
Y cuando la estructura de la organizacin lo permite, desarrollar una Gestin de
Problemas Proactiva que ayude a detectar problemas incluso antes de que estos
se manifiesten provocando un deterioro en la calidad del servicio.
El siguiente diagrama muestra los procesos implicados en la correcta Gestin de
Problemas:

Aplicacin Web
51
Grfico N 012: Procesos Implicados en la Gestin 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.
Grfico N 013: Control de Problemas


Aplicacin Web
52
El Control de Problemas se compone en esencia de tres fases:

1. Identificacin y Registro
Una de las tareas principales de la Gestin de Problemas es identificar los
mismos. Las principales fuentes de informacin utilizadas son:
o La base de datos de Incidentes: en principio cualquier incidente del que

no se conocen sus causas y que se ha cerrado mediante algn tipo de
solucin temporal es potencialmente un problema. Sin embargo, se habr
de analizar si este incidente es aislado o su impacto en la estructura TI
antes de elevarlo a la categora de problema.
o Anlisis de la infraestructura TI: en colaboracin con la Gestin de

Disponibilidad y de Capacidad, la Gestin de Problemas debe analizar los
diferentes procesos y determinar en qu aspectos se debe reforzar los
sistemas y estructuras TI para evitar futuros problemas.
o Deterioro de los Niveles de Servicio: el descenso del rendimiento puede

ser una indicacin de la existencia de problemas subyacentes que no se
hayan manifestado de forma explcita como incidentes.
Todas las reas de la infraestructura TI deben colaborar con la Gestin de
Problemas para identificar problemas reales y potenciales informando a sta de
cualquier sntoma que pueda ser seal de un deterioro en el servicio TI.
El registro de problemas es, en principio, similar al de los incidentes aunque el
nfasis debe hacerse no en los detalles especficos de los incidentes asociados
sino ms bien en su naturaleza y posible impacto.
El registro debe incorporar, entre otra, informacin sobre:
o
Los CIs implicados.
Causas del problema.
Sntomas asociados.
Soluciones temporales.
Servicios involucrados.
Niveles de prioridad, urgencia e impacto.

Aplicacin Web
53
Estado: activo, error conocido, cerrado.

2. Clasificacin y Asignacin de Recursos
La clasificacin del problema engloba desde las caractersticas generales de ste,

tales como si es un problema de hardware o software, que reas funcionales se
ven afectadas y detalles sobre los diferentes elementos de configuracin (CIs)
involucrados en el mismo.
Un factor esencial es la determinacin de la prioridad del problema, que al igual
que en el caso de los incidentes, se determina tanto a partir de la urgencia
(demora aceptable para la solucin del problema) como de su impacto (grado de
deterioro de la calidad del servicio).
Al igual que en la Gestin de Incidentes la prioridad puede cambiar en el curso del
ciclo de vida del problema, por ejemplo, si se encuentra una solucin temporal al
mismo que reduce considerablemente su impacto.
Una vez clasificado y determinada su prioridad se deben de asignar los recursos
necesarios para su solucin. Estos recursos deben ser suficientes para asegurar
que los problemas asociados son tratados eficazmente y as minimizar su impacto
en la infraestructura TI.
3. Anlisis y Diagnstico: Error conocido
Los objetivos principales del proceso de anlisis son:
o
Determinar las causas del problema.
Proporcionar soluciones temporales a la Gestin de Incidentes para

minimizar el impacto del problema hasta que se implemente los cambios
necesarios que lo resuelvan definitivamente.
Es esencial tener en cuenta que no siempre el origen del problema es un error de

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

Aplicacin Web
54
Falta de coordinacin entre diferentes reas.
...
Es tambin posible que la causa del problema sea un "bug" bien conocido de
alguno de las aplicaciones utilizadas. Por lo tanto es conveniente establecer
contacto directo con el entorno de desarrollo, en caso de aplicaciones
desarrolladas "en la casa", o investigar en Internet informacin sobre errores
conocidos aplicables al problema en cuestin.
Una vez determinadas las causas del problema ste se convierte en un Error
Conocido y se remite al Control de Errores para su posterior procesamiento.
Proceso - Control de Errores
Una vez que el Control de Problemas ha determinado las causas de un problema
es responsabilidad del Control de Errores el registro del mismo como error
conocido.
Grfico N 014: Control de Errores


Aplicacin Web
55
Identificacin y Registro de errores
El registro de los errores conocidos es de vital importancia para la Gestin de

Incidentes pues debe llevar asociado, siempre que esto sea posible, algn tipo de
solucin temporal que permita minimizar el impacto de los incidentes asociados.
Anlisis y Solucin
Se deben investigar diferentes soluciones para el error evaluando en cada

momento:
o
El posible impacto de las mismas en la infraestructura TI.
Los costes asociados.
Sus consecuencias sobre los SLAs.
En algunos casos, en los que el impacto del problema puede tener consecuencias
graves en la calidad del servicio, pueden emitirse una RFC de emergencia para su
procesamiento urgente por la Gestin de Cambios.
Una vez determinada la solucin ptima al problema y antes de elevar una RFC a
la Gestin de Cambios han de tenerse en cuenta las siguientes consideraciones:
o
Es conveniente demorar la solucin? Ya sea porque se prevn cambios

significativos en la infraestructura TI a corto plazo o por el escaso impacto
del problema en cuestin.
Es la solucin temporal aportada suficiente para mantener unos niveles

de calidad de servicios aceptable?
Los beneficios justifican los costes asociados?
Sea cual sea la respuesta, todo la informacin sobre el error y su solucin se

registrar en las bases de datos asociadas. En el caso en el que se considere que
el problema necesita ser solucionado se emitir una RFC. Ser responsabilidad
de la Gestin de Cambios la implementacin de los cambios de infraestructura
propuestos.
Aplicacin Web
56
Revisin Post Implementacin y Cierre
Antes de dar el problema por resuelto y cambiar su estado a cerrado se debe

analizar el resultado de la implementacin de la RFC elevado a la Gestin de
Cambios (PIR).
Si los resultados de esta PIR son los deseados y se pueden cerrar todos los
incidentes relacionados con este problema se considera concluido el proceso y se
emiten los informes correspondientes.
2.6.8. METODOLOGIA DE DESARROLLO:

Estas son ms que todo un "conjunto de procedimientos, tcnicas y ayudas a la
documentacin para el desarrollo de productos software. Una metodologa incluye
la tarea construir modelo conceptual de datos. Para realizarlo, define un
procedimiento y da a elegir entre una serie de tcnicas" [URJC 2006]. Entre las
ms conocidas podemos mencionar las siguientes:
Grfico N 015: Metodologas de Desarrollo de Software

Aplicacin Web
57
Fuente: Universidad Rey Juan Carlos (2006)

Pero dentro de esto se encuentra uno de los puntos clave que como futuros
ingenieros de sistemas estamos en la obligacin de saberlo y poseerlo como uno
de nuestra cultura general profesional, se trata de lo que es un Proceso de
Desarrollo de Software. Pero que objetivo tiene un Proceso de Desarrollo de
Software, bsicamente su objetivo se direcciona hacia "subir la calidad del
software (en todas las fases por las que pasa) a travs de un mayor control sobre
el proceso. Es labor del proceso de desarrollo definir quin debe hacer Qu,
cundo y cmo debe hacerlo" [Patricio Letelier 2000].
En esta parte de la investigacin realizada hablaremos sobre algunas de las
metodologas de desarrollo de software existentes en la actualidad, entre las
principales tenemos a:
RUP (Rational Unified Process).
XP (Extreme Programming).
FDD, etc.
RUP (Rational Unified Process):
Fue el mismo Barry Boehm, autor del modelo de espiral del proceso de software,
quien en su artculo [Boehm, 1995] describe tres hitos crticos a ser utilizados en
cualquier proyecto de forma de poder planificar y controlar el progreso del mismo,
dando visibilidad a los stakeholders. Estos hitos estn relacionados con las etapas
de avance que se van dando a lo largo de un proyecto de acuerdo al pasaje que
ocurre de las actividades de ingeniera (que componen los espirales del modelo
en espiral) a las actividades de produccin (que componen la construccin en
cascada del software). Su impacto en la industria del software ha sido tan
importante que uno de los procesos ms utilizados en la actualidad, el [RUP,
2002], los incorpora. Estos hitos son:
Objetivos del Ciclo de Vida
Arquitectura del Ciclo de Vida
Capacidad Operacional Inicial

Aplicacin Web
58
RUP es uno de los procesos ms generales del los existentes actualmente, ya

que en realidad esta pensado para adaptarse a cualquier proyecto, y no tan solo
de software.
Un proyecto realizado siguiendo RUP se divide en cuatro fases:
1. Intercepcin (puesta en marcha).
2. Elaboracin (definicin, anlisis, diseo).
3. Construccin (implementacin).
4. Transicin (fin del proyecto y puesta en produccin).
Se tiene que tener en cuenta que "en cada fase se ejecutarn una o varias
iteraciones, las cuales estn debidamente explicadas en el Proceso Iterativo e
Incremental. Pero a que se refiere con el proceso iterativo e incremental, se
refiere ms que tono a la evolucin de prototipos ejecutables que se muestran a
los usuarios y clientes [Rational Software Company 2001].

Aplicacin Web
59
Grfico N 016: Dos Dimensiones de RUP

Fuente: Introduccin a Rational Unified Process (RUP) - Patricio Letelier 2000
RUP define nueve actividades a realizar en cada fase del proyecto:
1. Modelado del negocio.
2. Anlisis de requisitos.
3. Anlisis y diseo.
4. Implementacin.
5. Test.
6. Distribucin.
7. Gestin de configuracin y cambios
8. Gestin del proyecto.
9. Gestin del entorno.
Pero por otra parte tambin posee elementos o Workflows de apoyo entre los
cuales tenemos [Patricio Letelier 2000]:
Environment (Entorno).
Project Management (Gestin del Proyecto).
Configuration & Change Management (Gestin de Configuracin y
Cambios).
Artefactos:
Resultado parcial o final que es producido y usado durante el proyecto.
Son las entradas y salidas de las actividades.
Un artefacto puede ser un documento, un modelo o un elemento de
modelo.
Aplicacin Web
60
Conjuntos de Artefactos.
o
Business Modeling Set.
Requirements Set.
Analysis & Design Set.
Implementation Set.
Test Set.
Deployment Set.
Project Management Set.
Configuration & Change Management Set.
Environment Set.
Caractersticas Esenciales de RUP:

Proceso Dirigido por los Casos de Uso
Proceso Iterativo e Incremental
Proceso Centrado en la Arquitectura
Proceso Iterativo e Incremental:
El ciclo de vida iterativo se basa en la evolucin de prototipos ejecutables
que se muestran a los usuarios y clientes.
En el ciclo de vida iterativo a cada iteracin se reproduce el ciclo de vida
en cascada a menor escala.
Los objetivos de una iteracin se establecen en funcin de la evaluacin
de las iteraciones precedentes.
Las actividades se encadenan en una mini-cascada con un alcance
limitado por los objetivos de la iteracin.

Aplicacin Web
61
Grfico N 017: Proceso Iterativo Incremental
Fuente: Introduccin a Rational Unified Process (RUP) - Patricio Letelier 2000

Puntos Claves:
Pesado.
Dividido en cuatro fases.
La fase se dividen en iteraciones.
El discurrir del proyecto se define en Workfows. Los artefactos son el
objetivo de cada actividad.
Se basa en roles.
UML.
Muy organizativo.
Mucha documentacin.
XP (Extreme Programming) Programacin Extrema:
Es la primera metodologa gil y es la que le dio conciencia al movimiento actual

de metodologas giles. De la mano de Kent Beck, XP ha conformado un extenso
grupo de seguidores en todo el mundo, disparando una gran cantidad de libros a
los que dio comienzo el mismo Beck en [Beck, 2000]. Inclusive Addison-Wesley ha
creado una serie de libros denominada The XP Series. Fue la misma gente del
proyecto C3 (Sistema Exhaustivo de Compensaciones de Chrysler) la que produjo
tambin otro de los libros importantes de XP [Jeffries, 2001] en el que se bajaban
los conceptos de Beck a la puesta en prctica en un proyecto.
La imagen mental de Beck al crear XP [Beck, 2000] era la de perillas en un tablero
de control. Cada perilla representaba una prctica que de su experiencia saba
que trabajaba bien. Entonces, Beck decidi girar todas las perillas al mximo para
ver que ocurra. As fue como dio inicio a XP.
En la programacin extrema, cada contribuidor al proyecto es una parte integral
del "equipo entero". El equipo forma alrededor de un representante del negocio
llamado "el cliente", que se sienta con el equipo y trabaja con ellos diariamente.
Diseo simple.

Aplicacin Web
62
Los equipos de XP construyen software a un diseo simple. Comienzan simple, y

con la prueba del programador y la mejora del diseo, la guardan de esa manera.
Un equipo de XP mantiene el diseo satisfecho exactamente para la funcionalidad
actual del sistema. No hay movimiento perdido, y el software es siempre listo para
lo siguiente.
El diseo en XP no es una cosa de una sola vez, es una cosa de todo el tiempo.
En donde los equipos se deben acostumbrar a sesiones rpidas de diseo.
Integracin continua.
Los equipos de programacin extrema mantienen el sistema integrado
completamente siempre. Los equipos de XP construyen pocas mltiples por da.
(Un equipo de XP de cuarenta personas construye por lo menos ocho o diez
veces por da). La integracin infrecuente conduce a los problemas senos en un
proyecto del software. Se tiene que tener en cuenta que la integracin es crtica al
momento del envo de cdigo, ya que el equipo no participa en ello, y se delega a
menudo a la gente que no est al corriente del sistema entero.
Codificacin de estndar.
Los equipos de XP siguen un estndar comn de la codificacin, de modo que
todo el cdigo en el sistema mire como si fuera escrito por un solo programador.
Lo importante es que todo el cdigo parezca familiar.
Mientras que el RUP intenta reducir la complejidad del software por medio de
estructura y la preparacin de las tareas pendientes en funcin de los objetivos de
la fase y actividad actual, XP, como toda metodologa gil, lo intenta por medio de
un trabajo orientado directamente al objetivo, basado en las relaciones
interpersonales y la velocidad de reaccin.
XP intenta minimizar el riesgo de fallo del proceso por medio de la disposicin
permanente de un representante competente del cliente a disposicin del equipo
de desarrollo. Este representante debera estar en condiciones ue contestar
rpida y correctamente a cualquier pregunta del equipo de desarrollo de forma
que no se retrase la tomar de decisiones, de ah lo de competente.
La codificacin del software en XP se produce siempre en parejas (dos
programadores, un ordenador), por lo que se espera que la calidad del mismo
Aplicacin Web
63
suba en el mismo momento de escribirlo. Al contrario que muchos otros mtodos,

el cdigo pertenece al equipo en completo, no a un programador o pareja, de
forma que cada programador puede cambiar cualquier parte del cdigo en
cualquier momento si as lo necesita, dejndose en todo caso las mejoras
orientadas al rendimiento para el final. Las parejas no se mantienen para todo el
proyecto si no que rotan cclicamente a lo largo del mismo, tanto en cuanto a los
componentes de la misma como en las partes del software que desarrollan, as
cada componente del equipo aprende como trabaja el resto. El objetivo ideal seria
que cada componente del equipo trabaje al menos una vez con cada uno de los
dems integrantes y con cada componente software, de forma que el
conocimiento de la aplicacin completa lo posea el equipo entero y no unos pocos
miembros.
En XP se programar solo la funcionalidad que es requerida. Es decir, una gran
flexibilidad y capacidad de configuracin solo ser implementada cuando sea
necesaria para cumplir los requerimientos. Se sigue un diseo evolutivo con la
siguiente premisa: conseguir la funcionalidad deseada de la forma ms sencilla
posible. Este diseo evolutivo hace que no se le de apenas importancia al anlisis
como fase independiente, puesto que se trabaja exclusivamente en funcin de las
necesidades del momento.
Puntos Claves:
Ligero.
Cercano al desarrollo.
Se basa en UserStories.
Fuerte comunicacin con el cliente.
El cdigo fuente pertenece a todos.
Programacin por parejas.
Tests como base de la funcionalidad.
Solo el mnimo de organizacin.
Pobre en cuanto a documentacin.
FDD (Desarrollo Manejado Por Rasgos):
Peter Coad es considerado uno de los referentes ms importantes dentro de la

ingeniera de software. Coad ha sido uno de los principales pioneros detrs del
Aplicacin Web
64
movimiento de la orientacin a objetos y empez a trabajar con Ed Yourdon (uno

de los creadores del Anlisis Estructurado) a principios de los noventa, cuando
este ltimo pidi ayuda a alguien de la comunidad de objetos para desarrollar una
nueva metodologa, basada en el paradigma de OO. Posteriormente, Coad junto
con Jeff De Luca y otros, participara en la creacin de FDD, una metodologa
desarrollada alrededor del ao 1998 que presenta las caractersticas de un
proceso gil [Coad, 1998]. La misma deriv del trabajo de Coad sobre las Feature
Lists (Listas de Funcionalidades).
FDD se estructura alrededor de la definicin de features que representan la
funcionalidad
que debe contener
el sistema, y tienen un alcance lo
suficientemente corto como para ser implementadas en un par de semanas. FDD

posee tambin una jerarqua de features, siendo el eslabn superior el de feature
set que agrupa un conjunto de features relacionadas con aspectos en comn del
negocio. Por ltimo, establece el major feature set como el ms alto nivel de
agrupacin de funcionalidad que abarca diferentes feature sets que contribuyen a
proveer valor al cliente en relacin a un subdominio dentro del dominio completo
de la aplicacin. Una de las ventajas de centrarse en las features del software es
el poder formar un vocabulario comn que fomente que los desarrolladores
tengan un dilogo fluido con los clientes, desarrollando entre ambos un modelo
comn del negocio. Este tema ser tratado ms adelante en relacin al enfoque
de las metodologas giles en los productos entregados.
El FDD tiene cinco procesos. Los primeros tres se hacen al principio del proyecto
y son:
a) Desarrollar un Modelo Global.
b) Construir una Lista de los Rasgos.
c) Planear por Rasgo.
Los ltimos dos se hacen en cada iteracin. Cada proceso se divide en tareas y
se da un criterio de comprobacin.
d) Disear por Rasgo.
e) Construir por Rasgo.
OBJETIVOS
Sintetizar un programa conforme a los rasgos requeridos.

Aplicacin Web
65
En un desarrollo en trminos de FOP (Programacin Orientada a rasgos),

los objetos se organizan en mdulos o capas conforme a rasgos.
FDD esta pensado para proyectos con tiempo de desarrollo relativamente cortos
(menos de un ao). Se basa en un proceso iterativo con iteraciones cortas (2
semanas aproximadamente) que producen un software funcional que el cliente y
la direccin de la empresa pueden ver y monitor izar.
Un proyecto que sigue FDD se divide en 5 fases:
1. Desarrollo de un modelo general.
2. Construccin de la lista de funcionalidades o rasgos.
3. Plan en base a las funcionalidades o rasgos a implementar.
4. Disear en base a las funcionalidades o rasgos.
5. Implementar en base a las funcionalidades o rasgos.
Grfico N 018: Proceso FDD
Fuente: COAD, 1998

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

Aplicacin Web
66
discusiones de los mas experimentados, y al tener un responsable ltimo, se

asignan las responsabilidades que todas las empresas exigen.
FDD tambin define mtricas para seguir el proceso de desarrollo de la aplicacin,
tiles para el cliente y la direccin de la empresa, y que pueden ayudar, adems
de para conocer el estado actual del desarrollo, a realizar mejores estimaciones
en proyectos futuros.
Puntos Claves:
Ligero.
A medio camino entre el desarrollo y la organizacin.
Existe una jerarqua dentro del equipo.
El cdigo fuente tiene propietario.
Los equipos varan en fncin de la funcionalidad a implementar.
El conocimiento de la aplicacin se reparte a travs de trabajo en equipo y
revisiones.
Documentacin aceptable.

Aplicacin Web
67
2.7. MARCO CONCEPTUAL:

Ttulo
Sistema de Control para las Tareas del Servicio de Soporte Tcnico de la Oficina de
Informtica de la Municipalidad Provincial de Piura mediante una Aplicacin Web
Aplicacin Web.
"La World Wide Web Internet han introducido a la poblacin en general en el
mundo de la informtica. Compramos fondos de inversin colectivos y acciones,
descargamos msica, vemos pelculas, obtenemos asesoramiento mdico,
hacemos gestiones de diversos tipos como personales y corporativas" [IEEE]
con respecto a la herramienta a producir en el presente proyecto.
Sistema de Control para las Tareas del Servicio de Soporte Tcnico de la
Oficina de Informtica de la Municipalidad Provincial de Piura.
"Los sistemas de control y supervisin son una clase importante de sistemas de
tiempo real. Verifican los sensores que proveen informacin del entorno del
sistema y toman acciones" [SOMMERVILLE, 2002] con respecto al control que
asumira soporte tcnico en sus tareas de mantenimiento en la Municipalidad
Provincial de Piura.
Metodologa Rational Unified Process (RUP).
"Conjunto de actividades necesarias para transformar los requisitos de un usuario
en un sistema software. Adems es un marco de trabajo genrico que puede
especializarse para una gran variedad de sistemas software, para diferentes reas
de aplicacin, diferentes tipos de organizaciones, diferentes niveles de aptitud y
diferentes tamaos de proyecto" [Jacobson & Booch & Rumbaugh 2000].

Aplicacin Web
68
2.8. HIPOTESIS:
La implementacin de una Aplicacin Web influye en el sistema de control de las tareas
del servicio de Soporte Tcnico de la Oficina de Informtica de la Municipalidad Provincial
de Piura.
2.9. VARIABLES E INDICADORES IMPLICADOS EN EL PROYECTO:

Variable Independiente:
Aplicacin Web:
El presente proyecto desarrollar una Aplicacin Web que va permitir al rea
de Soporte Tcnico tener un mejor control y seguimiento de los procesos que
se siguen para la solucin de los problemas que se presentan en las distintas
oficinas de la Municipalidad de Piura. Esta mejora del Sistema de Informacin
actual que presenta el rea de Soporte Tcnico permitir optimizar dichos
procesos, siendo ms eficientes y reduciendo el tiempo de las atenciones.
Variable Dependiente:
Sistema de Control para las Tareas del Servicio:
El actual desarrollo de las tareas del servicio de Soporte Tcnico para el
mantenimiento, reparacin y respaldo de los diversos equipos informticos y
electrnicos, se da de manera informal y sin documentar muchas de las
atenciones de los problemas e incidentes que ocurren en las diferentes
oficinas de la Municipalidad de Piura, es por estos motivos que la presente
Aplicacin Web a desarrollar permitir optimizar el desarrollo y ejecucin de
dichas operaciones tcnicas a travs de un mejor control, administracin y
organizacin.
Variable Interviniente:
Proceso Unificado de Racional (RUP):
Es una metodologa del proceso de ingeniera de software que proporciona un
enfoque disciplinado para asignar tareas y responsabilidades dentro de una
organizacin del desarrollo y ser aplicada en la presente tesis.
Aplicacin Web
69
Indicadores:
Nro
Indicador
Definicin
Conceptual
Definicin Operacional
I01 Tiempo para

llegar a atender
una Solicitud de
Servicio.
Tiempo que el
tcnico demora
en llegar a una
solicitud de
servicio.
I02 Tiempo para

solucionar una
solicitud de
Servicio.
n
Es el tiempo que
Ti
el tcnico
i
1
demora en
TS
n
solucionar una
Ts = Tiempo de solucin
solicitud de
de Solicitudes de
servicio.
Servicio.
T = Tiempo para realizar
una Solucin de Servicio.
n = Cantidad total de
Solicitudes de Servicio
n
Porcentaje de
Mi
solicitudes de
i 1
servicios
SM
x100%
T
atendidas por
SM= Porcentaje de
tcnico.
cumplimiento de un
tcnico de sus servicios
asignados.
M = Solicitudes
atendidas.
T = Total de Solicitudes
de Servicios Asignados.
n
Porcentaje de
Snai
Solicitudes
i
1
realizadas por el
Sn
x100%
N
usuario que no
Sn = Porcentaje de
han sido
Servicios no atendidos.
atendidas por
Sna = Servicio no
diversos
atendido.
motivos.
N = Total de Solicitudes.
I03 Cumplimiento de
un Tcnico en
cuanto a los
Servicios
Asignados.
I04 Porcentaje de
Servicio no
atendidos.
SS
Si
Unidad de
Medida
Tcnica de Instrumentos
Medicin
de Medicin
Minutos
Observacin
Gua de
Observacin
N 01
(Cronmetro)
Anexo
Minutos
Observacin
Gua de
Observacin
N 02
(Cronmetro)
Anexo
Porcentaje
Observacin
Gua de
Observacin
N 03
Anexo
Porcentaje
Observacin
Gua de
Observacin
N 04
Anexo
i 1
Ss - Tiempo de Asistencia
a la Solicitud de Servicio.
S = Tiempo de traslado
entre servicio.
Solicitudes de Servicio
Cuadro N 002: Indicadores de la Variable Dependiente

Fuente: El Autor

Aplicacin Web
70
Nro
Indicador
I05 Solicitudes de
Servicio
Asignadas por
Tcnico.
Definicin
Conceptual
Unidad de
Medida
Medicin
de Medicin
n
Es el nmero de
S
St
servicios
S
t 1
asignados a
St =servicio asignado por
cada tcnico.
tcnico.
t =orden de servicio
asignada al tcnico.
Ss =Solicitudes de
Servicio.
n
Es el nmero de
S S Si
servicios
i 1
solicitados por
S
S = Solicitudes de
oficina.
Servicios de Oficina.
Si = Solicitudes de
servicios de la Oficina
especificada.
Unidad
Observacin
Gua de
Observacin
N 05
Anexo
Unidad
Observacin
Gua de
Observacin
N 06
Anexo
I07 Nmero de
equipos
internados.
n
Son los equipos
E
Gi
que provienen
l
i 1
de otra oficina y
que tienen que El=Nmero de Equipos
ser atendidos en de otro local.
Gi=Guas de Salida.
Soporte.
Unidad
Observacin
Gua de
Observacin
N 07
Anexo
I08 Tiempo de
bsqueda de
historial tcnico.
Tiempo para
buscar la
informacin de
mantenimiento
(bitcora) de un
equipo.
Minutos
Observacin
Gua de
Observacin
N 08
(Cronmetro)
Anexo
Minutos
Observacin
Gua de
Observacin
N 09
(Cronmetro)
Anexo
I06 Solicitudes de
Servicio por
oficina.
I09 Tiempo de
Emisin (entrega)
de Documentos
(Reportes, Guas
de salida y/o
Fichas Tcnicas).
Tiempo
transcurrido
para la entrega
de la
documentacin
solicitada.
TB
Ti
i 1
TB = Tiempo de
Bsqueda
T = Tiempo de Bsqueda
de historial Tcnico.
bsquedas
n
TED
t
i 1
TED = Tiempo de Emisin.

t = Tiempo de Entrega
por documento.
documentacin
Cuadro N 002: Indicadores de la Variable Dependiente (continuacin)

Fuente: El Autor

Aplicacin Web
71
Nro
Indicador
I10 Nivel de
satisfaccin del
usuario.
Definicin
Conceptual
n
Medimos la
Usi
conformidad de
i
1
los usuarios con
NS
x100%
n
la herramienta a
NS = Nivel de
desarrollar.
Satisfaccin.
Us = Usuario Satisfecho.
usuarios
Unidad de
Medida
Porcentaje
Medicin
de Medicin
Encuesta
Cuestionario
de Encuesta
N 01
Anexo
Cuadro N 002: Indicadores de la Variable Dependiente (continuacin)

Fuente: El Autor

Aplicacin Web
72
________________________________________________________
CAPITULO III:
METODOLOGIA
________________________________________________________
3. METODOLOGIA:
Aplicacin Web
73
3.1. TIPO DE ESTUDIO:

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

Aplicacin Web
74
Para el presente proyecto de investigacin el diseo a utilizar ser cuasi

experimental con Pre-test y Post-test y grupos intactos.
[Hernandez, Fernndez, Baptista 2003] definen que en este tipo de diseo se
...manipulan deliberadamente, al menos, una variable independiente para
observar su efecto y relacin con una o ms variables dependientes, slo se
diferencian de los experimentos verdaderos en el grado de seguridad o
confiabilidad que pueda tenerse sobre la equivalencia inicial de los grupos.
O1 X O2
O1
: Pre-test o Prueba Inicial
O2
: Post-test o Prueba Final
: Variable Interviniente
Este diseo utiliza dos grupos: el experimental (que recibe el tratamiento) y el

grupo control (que no recibe el tratamiento). Los grupos son comparados en lapos
prueba para analizar si el tratamiento experimental tuvo un efecto sobre la
variable dependiente (O1 con O2). No se asignan los grupos ni por azar ni por
emparejamiento.
3.3. POBLACIN Y MUESTRA:

Poblacin
La poblacin tomada para el desarrollo de la presente tesis es el personal
encargado del servicio que brinda el rea de Soporte Tcnico a los
diferentes equipos de las dependencias de la Municipalidad de Piura.
Muestra
La muestra tomada para el desarrollo de la presente tesis es el personal
que labora en el rea de Soporte Tcnico de la Oficina de Informtica de la
Municipalidad de Piura. La cantidad de la muestra sern las 5 personas
encargadas del servicio que brinda la dependencia en mencin, por lo
tanto no es necesario aplicar una frmula para obtener la muestra.

Aplicacin Web
75
3.4. MTODOS DE INVESTIGACIN:

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

Tcnicas
Las tcnicas de recoleccin de datos que se emplearn son: encuestas y
observacin. Estas nos ayudarn a recoger informacin primordial para
desarrollar el presente trabajo de investigacin o tesis que tiene por ttulo:
Oficina de Informtica de la Municipalidad Provincial de Piura.
Instrumentos
Los instrumentos de recoleccin de datos para el desarrollo de la presente
investigacin o proyecto de tesis son: las guas de observacin y
cuestionarios de encuestas.
A continuacin en el siguiente cuadro se presentan los indicadores con sus
respectivas tcnicas e instrumentos de recoleccin de datos:

Aplicacin Web
76
Indicadores
Tcnicas
Instrumentos
Tiempo para llegar a atender una

Solicitud de Servicio.
Observacin
Gua de Observacin
Tiempo para solucionar una

solicitud de Servicio.
Observacin
Gua de Observacin
Cumplimiento de un Tcnico en
cuanto a los Servicios Asignados.
Observacin
Gua de Observacin
Porcentaje de Servicio no
atendidos.
Observacin
Gua de Observacin
Solicitudes de Servicio Asignadas

por Tcnico.
Observacin
Gua de Observacin
Solicitudes de Servicio por oficina.
Observacin
Gua de Observacin
Nmero de equipos internados.
Observacin
Gua de Observacin
Tiempo de bsqueda de historial

tcnico.
Observacin
Gua de Observacin
Tiempo de Emisin (entrega) de

Documentos (Reportes, Guas de
salida y/o Fichas Tcnicas).
Observacin
Gua de Observacin
10
Nivel de satisfaccin del usuario.
Encuesta
Cuestionario de Encuesta
Cuadro N 003: Indicadores, Tcnicas e Instrumentos de Recoleccin de Datos

Fuente: El Autor
3.6. MTODOS DE ANLISIS DE DATOS:

Para analizar los datos recolectados se estudiarn los resultados organizados en
cuadros estadsticos para determinar las principales tendencias de la informacin
utilizando los porcentajes de los cuadros o de las aplicaciones estadsticas. Para
el anlisis de datos se va a utilizar el software Microsoft Excel 2007.

Aplicacin Web
77
________________________________________________________
CAPITULO IV:
ADMINISTRACION
________________________________________________________

Aplicacin Web
78
4. ADMINISTRACION:
4.1. CRONOGRAMA DE ACTIVIDADES:
Para realizar el Cronograma de Gantt de las actividades a desarrollar en la
presente tesis hemos utilizado el software Microsoft Office Project 2007, el cual es
una herramienta que nos ayuda a realizar cronogramas de actividades para
diferentes tipos de proyecto. Este software ayuda a optimizar la distribucin del
tiempo. A continuacin en el cuadro N 4 se observa el cronograma del proyecto:
Cuadro N 004: Cronograma de Actividades de la Tesis

Fuente: El Autor

Aplicacin Web
79
4.2. PRESUPUESTO:
Cantidad
C/U
Precio
Total
Memoria USB 4 GB
01
S/. 50.00
S/. 50.00
Cartuchos de tinta
para impresora
04
S/. 50.00
S/. 200.00
Folder Manila A4
10
S/. 1.00
S/. 10.00
1 millar
S/. 25.00
S/. 25.00
CDs de 700 MB
10
S/. 1.00
S/. 10.00
Lapiceros
10
S/. 0.50
S/. 5.00
Luz Elctrica
___
___
S/. 200.00
Internet
200 horas
S/. 1.00
S/. 200.00
Telfono
___
___
S/. 100.00
Movilidad
___
___
S/. 400.00
500 hojas
S/. 0.05
S/. 25.00
Anillados
S/. 5.00
S/. 10.00
Empastados
S/. 20.00
S/. 60.00
Personal de apoyo
___
___
S/. 400.00
Otros
___
___
S/. 200.00
Recursos
Bienes
Papel A4
Servicios
Fotocopiado
Remuneraciones
Total
S/. 1,895.00
Cuadro N 005: Presupuesto de la Tesis

Fuente: El Autor
4.3. FINANCIAMENTO:
El presente proyecto de investigacin es autofinanciado por el autor ya que
la Municipalidad Provincial de Piura no financia este tipo de investigaciones
hechas por alumnos universitarios.
Aplicacin Web
80
________________________________________________________
CAPITULO V:
REFERENCIAS BIBLIOGRAFICAS
________________________________________________________

Aplicacin Web
81
[lvarez Brotons, Espaa, 2004] Sistemas de Control, artculo publicado por en la
Universidad Politcnica de Catalunya.
[Beck, 2000] Beck, Kent, Extreme Programming Explained, Addison-Wesley The XP
Series.
[Boehm, noviembre 1995] Boehm, Barry W., Anchoring the Software Process, USC.
[Booch, 2000] Booch, Grady, Ivar Jacobson, James Rumbaugh, The Unified Modeling
Language User Guide, Addison-Wesley Object Technology Series.
Castro Arvalo, Manuel & Zapata Navarro, Jhon (Piura 2009), Sistema Informtico
de Registro de Mantenimiento de Equipos de Cmputo del rea de Soporte del Centro de
Informtica y Telecomunicaciones de la Universidad Nacional de Piura. Universidad
Csar Vallejo Filial Piura.
[Coad, 1998] Coad, Peter, Eric Lefebvre, Jeff De Luca, Feature-Driven Development,
Disponible en: http://www.cs.jhu.edu/~scott/oos/software/togetherj/help/UsersGuide/Feature_Driven_Development.htm
Espinoza Saavedra, Daniel (Valparaso, Chile 2004), Estudio del Sistema de
Monitoreo y Registro de Inventarios de Compras y su Integracin Estratgica mediante el
Control de Gestin. Universidad de Valparaso.
[Freeman Elisabeth, 2004] et. al. Head First Design Patterns. California: O'Reilly Media.
[Gamma Erich, 1995] et. al. Design Patterns.Elements of Reusable Object-Oriented
Software. Boston: Addison-Wesley.
[Harrop Rob, 2005] et al. Pro Spring. Nueva York: Apress.
[Hernandez Sampieri, Roberto; Fernndez Collado, Carlos; Baptista Lucio, Pilar;
Mxico 2003] Metodologa de la Investigacin. Mc Graw Hill.

Aplicacin Web
82
[Johnson Rob, 2003] Expert One-on-One J2EE Design and Development. Indianapolis:
Wrox Press.
[Johnson Rob, mayo 2005] Introduction to the Spring Framework. [En lnea].
Disponible en: www.theserverside.com/articles/article.tss?l=SpringFramework
[Jos Padrn G.] Bases del concepto de "Investigacin Aplicada"[en lnea].
Disponible en: http://padron.entretemas.com/InvAplicada/index.htm
Metodologas de Desarrollo de Software (Espaa 2006), artculo publicado por la
Universidad Rey Juan Carlos.
Metodologa ITIL (Information Technologies Infraestructure Library) OSIATIS S.A. V2.0
Disponible en: http://itil.osiatis.es/Curso_ITIL/
[P. Letelier, Zaragoza, octubre 2000] Metodologas de Produccin de Software.
Pesntez Huerta, lvaro Eduardo (Guayaquil, Ecuador 2007), Elaboracin de un
Plan de Mantenimiento Predictivo y Preventivo en Funcin de la Criticidad de los Equipos
del Proceso Productivo de una Empresa Empacadora de Camarn. Escuela Superior
Politcnica del Litoral.
Plan Estratgico Institucional (2009 2014), Municipalidad Provincial Piura (PEI-MPP)
Plan Operativo Institucional (2011), Municipalidad Provincial de Piura (POIMPP)
Reglamento de Organizacin y Funciones, Municipalidad Provincial Piura (ROF-MPP)
[RUP, 2002] Rational Unified Process Version 2002.05.00, Copyright Rational
Software Corporation, All Rights Reserved.
Salcedo Untiveros, Richard Orlando (Piura 2007), Anlisis, Diseo y Desarrollo del
Mdulo Web para la Gestin y Control de Inventario de Bienes de la Oficina de Control
Patrimonial de la Direccin Regional de Salud Piura. Universidad Nacional de Piura.

Aplicacin Web
83
[Sant'Anna, F., 1983] Estratgias quantitativas e qualitativas de pesquisa educational: da
ao a obser-vao participante. Educao e realidade.
Santilln Pinedo, Karla & Tornero Mendoza, Ludver (Trujillo 2001), Sistema de
Informacin de Control de Almacn de la Direccin Regional de Educacin de La Libertad
DRELL. Universidad Csar Vallejo.
[Smith, J., 1983] Quantitative versus qualitative research: An attempt to clarify the issue.
Educational Researcher.
[Sommerville, Ian, 2002] Ingeniera del Software.
[Taylor, S. J. y Bogdan, R., 1986] Introduccin a los mtodos cualitativos de
investigacin. La bsqueda de significados. Buenos Aires: Editorial Paids.
Vega Bustamante, Roco Olinda (Lima 2009), Anlisis, diseo e implementacin de
un sistema de administracin de incidentes en atencin al cliente para una empresa de
telecomunicaciones. Pontificia Universidad Catlica del Per.
[Walls Craig, 2005] et. al. Spring in Action. Greenwich: Manning Publications.

Aplicacin Web
84
________________________________________________________
CAPITULO VI:
ANEXOS
________________________________________________________

Aplicacin Web
85
ANEXO 01
Gua de Observacin N 01
Tiempo para llegar a atender una solicitud de servicio.
Instrucciones: En los das de observacin se tomarn la fecha y hora de inicio
del pedido de atencin (solicitud de servicio) y la hora de llegada del tcnico a la
dependencia municipal para atender la solicitud de servicio.
Fecha de inicio de observacin: __/ __/ ___Hora de Inicio: _________
Hora de
Inicio
Nmero
Hora de
Llegada
Tiempo Total
(Min)
Tiempo Promedio
Hora Final: _________Fecha de fin de observacin: __/ __/ _____
Observaciones:
_________________________________________________________________
_________________________________________________________________
___________________________________________________________
Observador
Revisado

Aplicacin Web
Procesado
86
Archivado
ANEXO 02
Tiempo para solucionar una solicitud de servicio.
Instrucciones: En los das de observacin se tomarn la fecha y hora de inicio de
la atencin a la solicitud de servicio por parte del tcnico y la hora de la
finalizacin de dicha atencin.
Nmero
Hora de Inicio
Hora de Finalizacin
Tiempo
Total (Min)
Tiempo Promedio
Observaciones:
_________________________________________________________________
_________________________________________________________________
___________________________________________________________
Observador
Revisado

Aplicacin Web
Procesado
87
Archivado
ANEXO 03
Cumplimiento de un tcnico en cuanto a los servicios asignados.
Instrucciones: En los das de observacin se tomarn las cantidades de los
servicios atendidos por un tcnico y los que le han sido asignados a atender.

Tcnico
Cantidad
Cantidad
Porcentaje
Solicitudes Solicitudes
Cumplimiento
Asignadas Atendidas

Observaciones:
_________________________________________________________________
_________________________________________________________________
___________________________________________________________
Observador
Revisado

Aplicacin Web
Procesado
88
Archivado
ANEXO 04
Porcentajes de Servicios no Atendidos.
Instrucciones: En los das de observacin se tomarn las cantidades de los
servicios no atendidos y el total de las solicitudes de servicio.
Da
Cantidad
Solicitudes
Cantidad
Solicitudes
no Atendidas
Porcentaje
Servicios no
Atendidos

Observaciones:
_________________________________________________________________
_________________________________________________________________
___________________________________________________________
Observador
Revisado

Aplicacin Web
Procesado
89
Archivado
ANEXO 05
Solicitudes de Servicio Asignadas por Tcnico.
Instrucciones: En los das de observacin se tomarn las cantidades de las
solicitudes de los servicios asignados a un tcnico.

Cantidad
Solicitudes
Asignadas
Tcnico

Observaciones:
_________________________________________________________________
_________________________________________________________________
___________________________________________________________
Observador
Revisado

Aplicacin Web
Procesado
90
Archivado
ANEXO 06
Solicitudes de Servicio por Oficina.
solicitudes de los servicios de oficinas especficas.
Cantidad
Solicitudes
Servicios
Oficina

Observaciones:
_________________________________________________________________
_________________________________________________________________
___________________________________________________________
Observador
Revisado

Aplicacin Web
Procesado
91
Archivado
ANEXO 07
Nmero de Equipos Internados.
guas de salida de los equipos de otras dependencias que han sido atendidos en
el taller de Soporte Tcnico.
Fecha de inicio de observacin: __/ __/ ___ Hora de Inicio: _________

Cantidad de
Equipos de Otra
Dependencia
Da

Observaciones:
_________________________________________________________________
_________________________________________________________________
___________________________________________________________
Observador
Revisado

Aplicacin Web
Procesado
92
Archivado
ANEXO 08
Tiempo de Bsqueda de Historial Tcnico.
la bsqueda del historial tcnico de un equipo y la hora de finalizacin de dicha
bsqueda.
Hora de
Inicio
Nmero
Hora de
Finalizacin
Tiempo Total
(Min)
Tiempo Promedio
Observaciones:
_________________________________________________________________
_________________________________________________________________
___________________________________________________________
Observador
Revisado

Aplicacin Web
Procesado
93
Archivado
ANEXO 09
Tiempo de Emisin de Documentos.
la emisin de un documento (reportes, guas de salida y/o fichas tcnicas) y la
hora de finalizacin o entrega de dicho documento.
Hora de
Inicio
Nmero
Hora de
Entrega
Tiempo Total
(Min)
Tiempo Promedio
Observaciones:
_________________________________________________________________
_________________________________________________________________
___________________________________________________________
Observador
Revisado

Aplicacin Web
Procesado
94
Archivado
ANEXO 10
Cuestionario de Encuesta N 01
Oficina de Informtica de la Municipalidad Provincial de Piura mediante una
Aplicacin Web
El presente cuestionario de encuesta ser desarrollado como gua para obtener el
grado de satisfaccin del usuario de la aplicacin web.
_________________________________________________________________
Marque con un crculo o un aspa su repuesta elegida.
1) Con la aplicacin web implementada se ha mejorado su actividad de
trabajo?
a.
b.
c.
d.
Nada
Poco
Medianamente
Mucho
2) La aplicacin web implementada es fcil de manejar?

a.
b.
c.
d.
Nada
Poco
Medianamente
Mucho
3) Con la aplicacin web implementada la informacin est disponible de

forma inmediata?
a.
b.
c.
d.
Nada
Poco
Medianamente
Mucho
4) La informacin que brindan los reportes de la aplicacin web son de

utilidad para los usuarios del sistema?
Nada
Poco
Medianamente
Mucho
5) Est usted satisfecho con la aplicacin web?

Aplicacin Web
95
a.
b.
c.
d.
Nada
Poco
Medianamente
Mucho
6) La aplicacin web implementada cumple con todos los requisitos

solicitados?
a.
b.
c.
d.
Nada
Poco
Medianamente
Mucho
7) Cul es su opinin general de la aplicacin web?
Gracias por su participacin

Este cuestionario de encuesta se mide de la siguiente forma:
Como para cada pregunta se presentan 4 opciones las cuales se asemejan
(grado de medicin), una vez resueltas estas encuestas por el personal de
Soporte Tcnico, se proceder al conteo de las letras para conocer cul de ellas
ha obtenido mayor puntaje.
Si la mayor cantidad de las letras son:
PUNTUACIN
a
Aplicacin Web
GRADO DE SATISFACCIN
Quiere decir que el usuario se
96
b
c
d

Aplicacin Web
encuentra Nada Satisfecho.

encuentra Poco Satisfecho.
encuentra Medianamente Satisfecho.
encuentra Muy satisfecho.
97

Proyecto de Tesis Aplicacion Web Control Servicios Soporte Tecnico

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Proyecto de Tesis Aplicacion Web Control Servicios Soporte Tecnico

Uploaded by

Copyright:

Available Formats

UNIVERSIDAD CSAR VALLEJO

Universidad Csar Vallejo-Piura

Escuela Ingeniera Sistemas

Sistema de Control para las Tareas del Servicio de

Jess Antonio Pino Chacn

Universidad Csar Vallejo-Piura

Escuela Ingeniera Sistemas

Sistema de Control para las Tareas del Servicio de

Jess Antonio Pino Chacn

Universidad Csar Vallejo-Piura

Escuela Ingeniera Sistemas

Sistema de Control para las Tareas del Servicio de

Jess Antonio Pino Chacn

Universidad Csar Vallejo-Piura

Escuela Ingeniera Sistemas

Sistema de Control para las Tareas del Servicio de

Jess Antonio Pino Chacn

Universidad Csar Vallejo-Piura

Escuela Ingeniera Sistemas

Institucin donde se realiza la Investigacin..................................................10

Duracin del Proyecto de Investigacin..........................................................10

CAPITULO II: Plan de Investigacin..............................................................................11

Descripcin de la Realidad Problemtica........................................................12

Formulacin del Problema................................................................................13

2.2.1. Pregunta General...............................................................................................13

Justificacin e Importancia del Proyecto .......................................................15

Limitaciones del Proyecto................................................................................16

Marco Referencial Cientfico............................................................................17

2.6.1. Municipalidad Provincial de Piura........................................................................20

Variables e Indicadores Implicados en el Proyecto........................................66

Sistema de Control para las Tareas del Servicio de

Jess Antonio Pino Chacn

Universidad Csar Vallejo-Piura

Escuela Ingeniera Sistemas

Diseo del Estudio............................................................................................72

Tcnicas e Instrumentos de Recoleccin de Datos........................................73

Mtodos de Anlisis de Datos..........................................................................74

CAPTULO IV: Administracin.......................................................................................75

CAPTULO V: Referencias Bibliogrficas.....................................................................78

INDICE DE GRAFICOS Y CUADROS

Jess Antonio Pino Chacn

Universidad Csar Vallejo-Piura

Escuela Ingeniera Sistemas

Sistema de Control para las Tareas del Servicio de

Jess Antonio Pino Chacn

Universidad Csar Vallejo-Piura

Escuela Ingeniera Sistemas

1. GENERALIDADES DEL PROYECTO DE INVESTIGACION:

Sistema de Control para las Tareas del Servicio de

Jess Antonio Pino Chacn

Universidad Csar Vallejo-Piura

Escuela Ingeniera Sistemas

1.2. TIPO DE INVESTIGACIN:

1.3. REA DE INVESTIGACIN:

1.4. INSTITUCIN DONDE SE REALIZA LA INVESTIGACIN:

1.6. ASESOR METODOLGICO:

1.7. ASESOR ESPECIALISTA:

1.8. DURACIN DEL PROYECTO DE INVESTIGACIN:

29 de marzo del 2011

18 de diciembre del 2011

Sistema de Control para las Tareas del Servicio de

Jess Antonio Pino Chacn

Universidad Csar Vallejo-Piura