Tesis Soporte

UNIVERSIDAD CSAR VALLEJO
PIURA
FACULTAD DE INGENIERA
ESCUELA DE INGENIERA DE SISTEMAS
Sistema de Conto! "aa !as Taeas de! Se#i$io
de So"ote T%$ni$o de !a O&i$ina de In&om'ti$a de
!a M(ni$i"a!idad Po#in$ia! de Pi(a mediante (na
A"!i$a$i)n *e+,
Po-e$to de tesis
A(to
Pino C.a$)n Jes/s Antonio Man(e!
Aseso
M01 L(is Ve!e2 U+i!!(s
Pi(a 3 Pe/
456778
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
Universidad Csar Vallejo-Piura Escuela ngeniera Sistemas
ASESORES DE TESIS

ASESOR METODOL9GICO:
;;;;;;;;;;;;;;;;;;;
Mg. Luis Velez Ubillus
ASESOR ESPECIALISTA:
;;;;;;;;;;;;;;;;;;;;
ng. Noelia Saavedra Nizama
2 Jess Antonio Pino Chacn
Aplicacin Web
INTRODUCCI9N
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
nformtica, 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.
E! A(to
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.
E! A(to
Aplicacin Web
NDICE
N Pgina
CAPITULO I: Generalidades............................................................................................ 9
7171 T<t(!o................................................................................................................... 10
7151 Tipo de nvestigacin........................................................................................... 10
71=1 rea de nvestigacin.......................................................................................... 10
71>1 Instit($i)n donde se ea!i2a !a In#esti0a$i)n..................................................10
71?1 A(to................................................................................................................... 10
71@1 Aseso Metodo!)0i$o........................................................................................ 10
71A1 Aseso Es"e$ia!ista........................................................................................... 10
71B1 D(a$i)n de! Po-e$to de In#esti0a$i)n..........................................................10
CAPITULO II: Plan de Investigacin..............................................................................11
5171 Des$i"$i)n de !a Rea!idad Po+!em'ti$a........................................................12
5151 Fom(!a$i)n de! Po+!ema................................................................................13
515171 Pe0(nta Genea!............................................................................................... 13
515151 Pe0(ntas de In#esti0a$i)n..............................................................................13
5151=1 O+Ceti#o Genea!................................................................................................ 14
5151>1 O+Ceti#os Es"e$<&i$os....................................................................................... 14
51=1 J(sti&i$a$i)n e Im"otan$ia de! Po-e$to .......................................................15
51>1 Limita$iones de! Po-e$to................................................................................16
51?1 Ma$o Re&een$ia! Cient<&i$o............................................................................17
51?171 Ante$edentes..................................................................................................... 17
51@1 Ma$o Te)i$o.................................................................................................... 20
51@171 Municipalidad Provincial de Piura........................................................................20
51@15 O&i$ina de In&om'ti$a....................................................................................... 24
51@1=1 So"ote T%$ni$o................................................................................................ 25
51@1>1 Sistema de Conto!............................................................................................ 26
51@1?1 A"!i$a$i)n *e+.................................................................................................. 28
51@1@1 Gesti)n de In$identes....................................................................................... 40
51@1A1 Gesti)n de Po+!emas....................................................................................... 46
51@1B1 Metodo!o0<a de Desao!!o................................................................................55
51A1 Ma$o Con$e"t(a!............................................................................................. 65
51B1 Di")tesis............................................................................................................ 66
51E1 Vaia+!es e Indi$adoes Im"!i$ados en e! Po-e$to........................................66
Aplicacin Web
NDICE
N Pgina
CAPITULO III: Metodologa............................................................................................70
=171 Ti"o de Est(dio.................................................................................................. 71
=151 DiseFo de! Est(dio............................................................................................ 72
=1=1 Po+!a$i)n - M(esta.......................................................................................... 72
=1>1 M%todos de In#esti0a$i)n.................................................................................73
=1?1 T%$ni$as e Inst(mentos de Re$o!e$$i)n de Datos........................................73
=1@1 M%todos de An'!isis de Datos..........................................................................74
CAPTULO IV: Administracin.......................................................................................75
>171 Cono0ama....................................................................................................... 76
>151 Pes("(esto....................................................................................................... 77
>1=1 Finan$iamiento.................................................................................................. 77
CAPTULO V: Reerencias !i"liogr#icas.....................................................................78
CAPTULO VI: Ane$os................................................................................................... 82
A%&'O (): G*a de O"servacin %+ () .......................................................................83
A%&'O (,: G*a de O"servacin %+ (,........................................................................84
A%&'O (-: G*a de O"servacin %+ (-........................................................................85
A%&'O (.: G*a de O"servacin %+ (.........................................................................86
A%&'O (/: G*a de O"servacin %+ (/........................................................................87
A%&'O (0: G*a de O"servacin %+ (0........................................................................88
A%&'O )(: C*estionario de &nc*esta %+ ()................................................................92
INDICE DE GRAFICOS G CUADROS
Aplicacin Web
N Pgina
C*adro %4 ((): Poltica Instit*cionales555555555555555555555555555555555555555555555555555555555555555555555555,)
Gr#ico %4 ((): Organigrama de la M*nici6alidad Provincial de Pi*ra5555555555555555555555,-
Gr#ico %4 ((,: &s7*ema general de *n sistema55555555555555555555555555555555555555555555555555555555,0
Gr#ico %4 ((-: &s7*ema general de *n sistema de control55555555555555555555555555555555555555,2
Gr#ico %4 ((.: MVC de ar7*itect*ra Ti6o ) 555555555555555555555555555555555555555555555555555555555555555-,
Gr#ico %4 ((/: MVC de ar7*itect*ra Ti6o , 555555555555555555555555555555555555555555555555555555555555555-,
Gr#ico %4 ((0: Gestin de Incidentes5555555555555555555555555555555555555555555555555555555555555555555555555.(
Gr#ico %4 ((1: Proceso de Gestin de Incidentes 8res*men9 5555555555555555555555555555555555.)
Gr#ico %4 ((2: :iagrama de Prioridades :el Incidente555555555555555555555555555555555555555555555..
Gr#ico %4 ((3: Proceso de &scalado de Incidentes555555555555555555555555555555555555555555555555555./
Gr#ico %4 ()(: Procesos im6licados en la Gestin de Incidentes5555555555555555555555555555.0
Gr#ico %4 ()): Interacciones ; <*ncionalidades de la Gestin de Pro"lemas55555555.1
Gr#ico %4 (),: Procesos Im6licados en la Gestin de Pro"lemas555555555555555555555555555/(
Gr#ico %4 ()-: Control de Pro"lemas5555555555555555555555555555555555555555555555555555555555555555555555555/(
Gr#ico %4 ().: Control de &rrores5555555555555555555555555555555555555555555555555555555555555555555555555555555/-
Gr#ico %4 ()/: Metodologas de :esarrollo de =ot>are5555555555555555555555555555555555555555555//
Gr#ico %4 ()0: :os :imensiones de RUP5555555555555555555555555555555555555555555555555555555555555555555/1
Gr#ico %4 ()1: Proceso Iterativo Incremental5555555555555555555555555555555555555555555555555555555555555/3
Gr#ico %4 ()2: Proceso <::55555555555555555555555555555555555555555555555555555555555555555555555555555555555555550.
C*adro %4 ((,: Indicadores de la Varia"le :e6endiente5555555555555555555555555555555555555555555501
C*adro %4 ((-: Indicadores? T@cnicas e Instr*mentos de Recoleccin de :atos55551.
C*adro %4 ((.: Cronograma de Actividades de la Tesis5555555555555555555555555555555555555555555510
C*adro %4 ((/: Pres*6*esto de la Tesis555555555555555555555555555555555555555555555555555555555555555555555511
Aplicacin Web
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
CAPITULO I:
GENERALIDADES
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
71 GENERALIDADES DEL PROGECTO DE INVESTIGACION:
Aplicacin Web
7171 TTULO:
"Sistema de Control para las Tareas del Servicio de Soporte Tcnico de la Oficina
de nformtica de la Municipalidad Provincial de Piura mediante una Aplicacin
Web
7151 TIPO DE INVESTIGACI9N:
"EXPLCATVA
71=1 HREA DE INVESTIGACI9N:
"TECNOLOGCA
71>1 INSTITUCI9N DONDE SE REALIIA LA INVESTIGACI9N:
"rea de Soporte Tcnico de la Municipalidad Provincial de Piura
71?1 AUTOR:
Jess Antonio Manuel Pino Chacn
71@1 ASESOR METODOL9GICO:
Mg. Luis Velez Ubillus
71A1 ASESOR ESPECIALISTA:
ng. Noelia Saavedra Nizama
71B1 DURACI9N DEL PROGECTO DE INVESTIGACI9N:
nicio: 29 de marzo del 2011
Final: 18 de diciembre del 2011
Aplicacin Web
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
CAPITULO II:
PLAN DE INVESTIGACION
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
51 PLAN DE LA INVESTIGACION:
Aplicacin Web
5171 DESCRIPCI9N DE LA REALIDAD PROJLEMHTICA:
El rea de Soporte Tcnico pertenece a la Oficina de nformtica y que a su vez
esta pertenece a la Gerencia de Tecnologas y Sistemas de nformacin 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 nformtica 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 nformtica.
El proceso de atenciones a los problemas que se presentan en las dependencias
de la municipalidad es poco organizado.
Aplicacin Web
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.
5151 FORMULACI9N DEL PROJLEMA:
515171 Pe0(nta Genea!:
Cmo influye una Aplicacin Web en el sistema de control de las tareas del
servicio de Soporte Tcnico de la Oficina de nformtica de la Municipalidad
Provincial de Piura?
515151 Pe0(ntas de In#esti0a$i)n:
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
De qu manera influye una aplicacin web en la mejora del control y
organizacin para los procesos de atenciones de problemas e incidentes?
De qu manera influye una aplicacin web para que el rea de Soporte
Tcnico tenga independencia para planificar operaciones y tareas
administrativas y de mantenimiento?
5151=1 O+Ceti#o Genea!:
"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
nformtica de la Municipalidad Provincial de Piura
5151>1 O+Ceti#os Es"e$<&i$os:
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
51=1 JUSTIFICACI9N E IMPORTANCIA DEL PROGECTO:
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 nventario que compete a la
Oficina de nformtica 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.
J(sti&i$a$i)n Administati#a
Este proyecto es una alternativa de solucin al problema de Control y
Organizacin para el Mantenimiento de Equipos nformticos, 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.
J(sti&i$a$i)n Cient<&i$a
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.
J(sti&i$a$i)n Instit($iona!
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
nuevo sistema de informacin y/o control (aplicacin web) para satisfacer las
necesidades del usuario y puedan desarrollar sus actividades eficientemente.
J(sti&i$a$i)n So$ia!
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.
J(sti&i$a$i)n Te$no!)0i$a
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.
51>1 LIMITACIONES DEL PROGECTO:
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
51?1 MARCO REFERENCIAL CIENTIFICO:
51?171 Ante$edentes:
Ante$edentes Lo$a!es:
Casto A%#a!oK Man(e! L Ia"ata Na#aoK J.on 4Pi(a M 566E8, "Sistema
nformtico de Registro de Mantenimiento de Equipos de Cmputo del rea
de Soporte del Centro de nformtica y Telecomunicaciones de la
Universidad Nacional de Piura, presentan su tesis con la que obtuvieron los
Ttulos Profesionales de ngenieros 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.
Re!a$i)n: 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.
Sa!$edo Unti#eosK Ri$.ad O!ando 4Pi(a M 566A8, "Anlisis, Diseo y
Desarrollo del Mdulo Web para la Gestin y Control de nventario 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 ngeniero
nformtico 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
Re!a$i)n: 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.
Ante$edentes Na$iona!es:
Ve0a J(stamanteK Ro$<o O!inda 4Lima M 566E8, "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 ngeniero nformtico 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.
Re!a$i)n: 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.
Santi!!'n PinedoK Na!a L Toneo Mendo2aK L(d#e 4T(Ci!!o M 56678,
"Sistema de nformacin 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 ngenieros 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
Re!a$i)n: 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.
Ante$edentes Intena$iona!es:
Pes'nte2 D(etaK H!#ao Ed(ado 4G(a-aO(i!K E$(ado M 566A8,
"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 ngeniero ndustrial 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.
Re!a$i)n: 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.
Es"ino2a Saa#edaK Danie! 4Va!"aa<soK C.i!e M 566>8, "Estudio del
Sistema de Monitoreo y Registro de nventarios de Compras y su ntegracin
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
Re!a$i)n: 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.
51@1 MARCO TEORICO:
51@171 MUNICIPALIDAD PROVINCIAL DE PIURA:
Misi)nK Visi)n - O+Ceti#os de !a Instit($i)n:
Misi)n
Gobernar, conducir y liderar el desarrollo de la provincia, gestionando y
promoviendo el desarrollo sostenible, integral y el bienestar humano, mediante
acciones de concertacin institucional y de participacin de la sociedad civil
organizada. [PE MPP]

Visi)n
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. [PE MPP]
O+Ceti#os
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
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]
Po!<ti$as Genea!es de !a Instit($i)n:
OJJETIVOS ESTRATEGICOS
LINEAS POLITICAS OJJETIVO META
Poltica N 01
Desarrollo nstitucional
La Municipalidad Provincial de Piura es
una corporacin edil eficaz y eficiente que
resuelve el 100 % de sus operaciones de
manera moderna, gil y dinmica.
Poltica N 02
Desarrollo Social
La Municipalidad Provincial de Piura
cuenta con una Red de Participacin
Ciudadana mediante la cual ha
organizado el 100 % de Juntas Vecinales
dentro de las jurisdicciones de su
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
Desarrollo Econmico y
Financiero
cuenta con un Sistema de Desarrollo
Econmico y Financiero que le permite
incrementar sus recursos en un 5 %
anual.
Poltica N 04
La Municipalidad Provincial de Piura es la
primera en el pas que logra delimitar y
Aplicacin Web
Organizacin Territorial adecuar integralmente el 100 % de su
territorio.
C(ado NP 667: Poltica nstitucionales
F(ente: PE MPP
A$ti#idades Pin$i"a!es de !a Instit($i)n:
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]
O0ani0ama de !a Instit($i)n:
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
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
G'&i$o NP 667: Organigrama de la Municipalidad Provincial de Piura
F(ente: Municipalidad Provincial de Piura (MPP)
Aplicacin Web
51@151 OFICINA DE INFORMATICA:
Misi)nK Visi)nK O+Ceti#os - Metas de !a O&i$ina de In&om'ti$a:
Misi)n
Promover el desarrollo y la utilizacin de un sistema de informacin moderno
de acuerdo a las necesidades de los diferentes usuarios,
proporcionando datos oportunos y de calidad en lo relativo a prevencin,
atencin y control de los problemas informticos, elctricos y electrnicos
contribuyendo a la mejora de la calidad de servicio de las diferentes
dependencias de la Municipalidad Provincial de Piura. [ROF MPP]
Visi)n
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]
O+Ceti#os
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) mplementar 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
12) mplementar 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
nformacin 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.
[PO MPP]
51@1=1 SOPORTE TECNICO:
Des$i"$i)n de! Hea de Ne0o$io:
El rea de Negocio es Soporte Tcnico, pertenece a la Oficina de nformtica
y a su vez esta oficina pertenece a la Gerencia de Tecnologas y Sistemas de
nformacin, 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
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]
51@1>1 SISTEMA DE CONTROL:
QRU ES UN SISTEMA DE CONTROLS
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.
G'&i$o NP 665: Esquema general de un sistema
F(ente: Alvarez Brotons
Aplicacin Web
Dentro de los sistemas se encuentra el concepto de sistema de control. Un
sistema de control es un tipo de sistema que se caracteriza por la presencia de
una serie de elementos que permiten influir en el funcionamiento del sistema. La
finalidad de un sistema de control es conseguir, mediante la 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
G'&i$o NP 66=: Esquema general de un sistema de control
F(ente: Alvarez Brotons
51@1?1 APLICACI9N *EJ:
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.
Patones de diseFo
De&ini$i)n e .istoia
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
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].
E!ementos esen$ia!es
En general un patrn tiene cuatro elementos esenciales:
E! nom+e de! "at)n: 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.
E! "o+!ema: 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
La so!($i)n: 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 $onse$(en$ias: 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.
C!asi&i$a$i)n
El grupo de GoF clasific los patrones en 3 grandes categoras basadas en su
propsito: creacionales, estructurales y de comportamiento [Gamma, 1995].
Cea$iona!es: 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.
Est($t(a!es: 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.
Com"otamiento: 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.
Pat)n de diseFo Mode! VieT Conto!!e 4MVC8
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 !ew "ontroller, 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
De&ini$i)n e .istoia
"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.
Com"onentes
Los 3 principales componentes del patrn MVC son:
Mode!o: Representa los datos que el usuario est esperando ver, en algunos
casos el Modelo consiste de #a$a %eans.
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 re&uest, debe
delegar esta responsabilidad al controlador.
Conto!ado: es la parte lgica que es responsable del procesamiento y
comportamiento de acuerdo a las peticiones 're&uests) del usuario, construyendo
Aplicacin Web
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.
Ti"os de "atones MVC
Actualmente existen dos tipos de patrn MVC:
G'&i$o NP 66>: MVC de arquitectura Tipo 1
F(ente: 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 ngls (la!n )ld #a$a
)*+e,ts (POJOs) y se transforma el modelo para ser desplegado una vez ms.
G'&i$o NP 66?: MVC de arquitectura Tipo 2
F(ente: Walls, 2005
Servidor Web/Aplicacin
Servidor Web/Aplicacin
Aplicacin Web
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.
FameToUs
Un framework es un trmino utilizado en la computacin en general, para referirse
a un conjunto de bibliotecas, utilizadas para implementar la estructura estndar de
una aplicacin. Todo esto se realiza con el propsito de promover la reutilizacin
de cdigo, con el fin de ahorrarle trabajo al desarrollador al no tener que rescribir
ese cdigo para cada nueva aplicacin que desee crear. Existen diferentes
frameworks para diferentes propsitos, algunos orientados al desarrollo de
aplicaciones web, otros para desarrollar aplicaciones multiplataforma, para un
sistema operativo o lenguaje de programacin en especfico, entre otros.
Segn Gamma, el framework determina la arquitectura de una aplicacin
[Gamma, 1995]. Este es un buen enfoque, ya que el framework se encarga de
definir la estructura general, sus particiones en clases y objetos, las
responsabilidades clave, as como la colaboracin entre dichas clases y objetos.
Todos estos parmetros son definidos por el framework, evitando que el usuario
tenga que definirlos y se pueda enfocar en cosas especficas de su aplicacin.
"El framework captura las decisiones de diseo que son comunes a su dominio de
aplicacin" [Gamma, 1995]. Un framework no slo promueve la reutilizacin de
cdigo sino tambin la reutilizacin de diseo.
Un framework ayuda a que se desarrolle una aplicacin de una manera ms
rpida, ya que se no pierde tiempo en algunos detalles de diseo que muchas
veces quitan ms tiempo del que tomo construir en s la lgica de la aplicacin.
Adems las aplicaciones que se construyen tienen estructuras similares, son ms
fciles de mantener y consistentes para los usuarios. Pero esto tiene como
consecuencia una mnima perdida de libertad en las cuestiones de diseo.
Aplicacin Web
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.
Re!a$i)n ente "atones de diseFo - rame>orAs
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 "atones de diseFo son m's a+sta$tos O(e !os rame>orAs: el cdigo
del framework se escribe una vez, en cambio cada vez que se requiere un patrn
de diseo se debe de codificar con respecto a la aplicacin. Una fortaleza de los
frameworks es que pueden ser escritos en un lenguaje de programacin, pueden
ser reutilizados e incluso ejecutados, esto tambin podra considerarse una
debilidad dependiendo del punto de vista (siempre y cuando no sean
multiplataforma o se encuentre en diferentes versiones por lenguaje de
Aplicacin Web
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 "atones de diseFo son e!ementos aO(ite$t)ni$os m's "eO(eFos O(e
!os &ameToUs: un solo framework contiene varios patrones de diseo, pero
jams es al contrario.
Los "atones de diseFo son menos es"e$ia!i2ados O(e !os &ameToUs:
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.
<rame>orAs "aa a"!i$a$iones Te+
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 de-lo.ment des,r!-tor "web.xml"
para que todas las URL's tengan que pasar forzosamente por dicho servlet.
Una configuracin, generalmente escrita en un archivo XML, en donde se le
indicar al servlet controlador, a travs de propiedades, a quien delegar la
responsabilidad de atender la peticin entrante. Algunas veces esas propiedades
estn indicadas de acuerdo a los URL's y de acuerdo al URL entrante es como se
delega la responsabilidad.
Las vistas pueden tener nombres claves, sin necesidad que exista una relacin
con el nombre del archivo de la vista. El framework se encarga de realizar dicha
conversin para poder obtener el nombre de la vista que se tiene que cargar para
que sea desplegada. La implementacin de una vista con un nombre en particular
puede cambiar sin afectar cdigo del controlador.
Aplicacin Web
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.
St(ts
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 o-en sour,e,
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 a,t!on que procesa el
re&uest. El lenguaje de programacin que utiliza es Java, as como Java Beans
como modelo.
Algunas de las ventajas que Struts brinda son: que existe un variado nmero de
trabajos y proyectos ya hechos lo que brinda un mayor nmero de ejemplos para
Aplicacin Web
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.
Ma#ei$U
Este es otro framework MVC o-en sour,e 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 /!s-at,0er, que est definido en el /e-lo.ment /es,r!-tor 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 ngls. 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 *eans.
Una caracterstica interesante de Maverick es el bsico y fcil uso de la
funcionalidad del d!s-at,0er. Tambin es multiplataforma ya que ha sido adaptado
para los lenguajes .NET y PHP.
*e+*oU
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
Aplicacin Web
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
"ommand(attern. Cada accin es un comando, que es creado para manejar un
re&uest, 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 'a,t!on) por cada re&uest puede llegar a ser algo confuso cuando
no se tiene muchos datos en el re&uest1 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.
S"in0
Es un framework de aplicacin, que a diferencia de otros s!ngle2t!er como Struts,
Spring propone estructurar toda una aplicacin de una manera consistente y
productiva, conjuntando lo mejor de cada uno de los frameworks s!ngle2t!er para
crear una arquitectura coherente. En s Spring ha surgido como una solucin para
poder disfrutar de los beneficios clave de J2EE, mientras que minimiza la
complejidad encontrada en el cdigo de la aplicacin. [Johnson, 2005]
Spring esta basado en la filosofa de que un framework debe proveer una gua
hacia una buena prctica, es decir debe hacer la cosa correcta sencilla de hacer.
Mezclando la correcta combinacin de flexibilidad y restriccin, la cual es la clave
en el buen diseo de un framework.
Aplicacin Web
Spring tambin cuenta con algunas de las caractersticas generales de los
frameworks web, ya que cuenta con un mdulo para poder desarrollar
aplicaciones web de manera sencilla, utilizando el patrn de diseo MVC antes
mencionado. Contando con un controlador central (DispatcherServlet), adems de
la capacidad de tener varios controladores secundarios para el procesamiento de
cada una de las peticiones.
Tambin se basa en el diseo de las clases extendiendo o implementando
interfaces, lo cual es un mejor diseo orientado a objetos, ya que promueve la
reutilizacin de cdigo. Adems Spring cuenta con algunos tags para las
diferentes tecnologas para vista que existen. Las cuales tienen funciones
diferentes como vincular formularios, validacin, despliegue de informacin, entre
otras.
Uno de los aspectos clave y ventajas de Spring, es que cuenta con una
arquitectura modularizada, y se pueden utilizar cada uno de estos mdulos de
manera independiente. Cada uno esta enfocado en una tarea especfica, y
algunos de ellos son para la integracin con alguna herramienta o incluso cuenta
con la posibilidad de integrase con los otros frameworks mencionados
anteriormente. Esto con el propsito de proponer la filosofa de "no intentar
reinventar la rueda", la cual quiere decir que si ya existe en el mercado una
herramienta que realice una tarea de manera eficiente en un mbito o rea en
particular se debe conjuntar con Spring para llevar a cabo un mejor desempeo y
poder sacar as un mejor resultado y una aplicacin de mayor calidad.
En conclusin cada framework tiene sus ventajas y desventajas, escoger uno es
una decisin del desarrollador, dependiendo de sus necesidades y
requerimientos, del tamao del proyecto a desarrollar, as como de su experiencia
con tecnologas existentes que se integren fcilmente con el framework que haya
elegido. Esto con el fin de aprovechar algunas tecnologas que estn enfocadas
en un rea especfica, para que brinde una mejor y ms sencilla forma de llevar a
cabo la tarea. Esta fue una de las razones por la cual se decidi incursar dentro
de las caractersticas de Spring, y despus de un anlisis se llego a la conclusin
de que es un buen framework que cumple con la mayora de las caractersticas,
de las cuales otros frameworks escasean.
Aplicacin Web
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.
51@1@1 GESTI9N DE INCIDENTES:
Segn OSATS S.A. V2.0:
Visi)n Genea!
La Gestin de ncidentes tiene como objetivo resolver cualquier incidente que
cause una interrupcin en el servicio de la manera ms rpida y eficaz posible.
La Gestin de ncidentes 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 ncidentes se resumen
sucintamente en el siguiente grfico:
G'&i$o NP 66@: Gestin de ncidentes
F(ente: OSATS S.A. V2.0
Aplicacin Web
Intod($$i)n - O+Ceti#os
Los objetivos principales de la Gestin de ncidentes son:
Detectar cualquiera alteracin en los servicios T (Tecnologas de
nformacin).
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:
G'&i$o NP 66A: Proceso de Gestin de ncidentes (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 TL (Bibliotecas de nfraestructura de las Tecnologas de
nformacin) 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.
Aplicacin Web
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 ncidentes incluyen:
Mejorar la productividad de los usuarios.
Cumplimiento de los niveles de servicio acordados en el SLA.
Mayor control de los procesos y monitorizacin del servicio.
Optimizacin de los recursos disponibles.
Una CMDB (Base de Datos de la Gestin de Configuraciones) ms
precisa pues se registran los incidentes en relacin con los elementos
de configuracin.
Y principalmente: mejora la satisfaccin general de clientes y usuarios.
Por otro lado una incorrecta Gestin de ncidentes 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 ncidentes se
resumen en:
Aplicacin Web
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.
C!asi&i$a$i)n de! In$idente
Es moneda frecuente que existan mltiples incidencias concurrentes por lo que es
necesario determinar un nivel de prioridad para la resolucin de las mismas.
El nivel de prioridad se basa esencialmente en dos parmetros:
Im"a$to: determina la importancia del incidente dependiendo de cmo
ste afecta a los procesos de negocio y/o del nmero de usuarios
afectados.
U0en$ia: 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.
Aplicacin Web
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:
G'&i$o NP 66B: Diagrama de Prioridades Del ncidente
Es$a!ado - So"ote
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:
Es$a!ado &(n$iona!: Se requiere el apoyo de un especialista de ms alto
nivel para resolver el problema.
Es$a!ado Ce'O(i$o: 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.
Aplicacin Web
El proceso de escalado puede resumirse grficamente* como sigue:
* El escalado puede incluir ms niveles en grandes organizaciones, o por el contrario, integrar diferentes
niveles en el caso de PYMES
G'&i$o NP 66E: Proceso de Escalado de ncidentes
Po$eso
El siguiente diagrama muestra los procesos implicados en la correcta Gestin de
ncidentes:
Aplicacin Web
G'&i$o NP 676: Procesos implicados en la Gestin de ncidentes
51@1A1 GESTI9N DE PROJLEMAS:
Segn OSATS S.A. V2.0:
Visi)n Genea!
Las funciones principales de la Gestin de Problemas son:
o nvestigar las causas subyacentes a toda alteracin, real o potencial, del
servicio T.
o Determinar posibles soluciones a las mismas.
o Proponer las peticiones de cambio (RFC) necesarias para restablecer la
calidad del servicio.
o Realizar Revisiones Post mplementacin (PR) para asegurar que los
cambios han surtido los efectos buscados sin crear problemas de carcter
secundario.
La Gestin de Problemas puede ser:
Aplicacin Web
Rea$ti#a: Analiza los incidentes ocurridos para descubrir su causa y propone
soluciones a los mismos.
Poa$ti#a: Monitoriza la calidad de la infraestructura T 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:
G'&i$o NP 677: nteracciones y Funcionalidades de la Gestin de Problemas
Intod($$i)n - O+Ceti#os
Como se explic en la seccin de Gestin de ncidentes, 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
Cuando algn tipo de incidente se convierte en recurrente o tiene un fuerte
impacto en la infraestructura T es la funcin de la Gestin de Problemas el
determinar sus causas y encontrar posibles soluciones.
Cabe diferenciar entre:
Po+!ema: causa subyacente, an no identificada, de una serie de incidentes o un
incidente aislado de importancia significativa.
Eo $ono$ido: 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 dentificar, registrar y clasificar los problemas.
o Dar soporte a la Gestin de ncidentes proporcionando informacin y
soluciones temporales o parches.
o Analizar y determinar las causas de los problemas y proponer soluciones.
o Elevar RFCs a la Gestin de Cambios para llevar a cabo los cambios
necesarios en la infraestructura T.
o Realizar un seguimiento post-implementacin de todos los cambios para
asegurar su correcto funcionamiento.
o Realizar informes que documenten no slo los orgenes y soluciones a un
problema sino que tambin sirvan de soporte a la estructura T en su
conjunto.
o Analizar tendencias para prevenir incidentes potenciales.
Los principales beneficios de una correcta Gestin de Problemas:
o Un aumento de la calidad general de los servicios T.
o Se minimiza el nmero de incidentes.
o Los incidentes se solucionan ms rpidamente y, generalmente, en la
primera lnea de soporte T ahorrando recursos e innecesarios escalados.
o La documentacin desarrollada es de gran utilidad para la Gestin de la
Capacidad, Disponibilidad y Niveles de Servicio.
Aplicacin Web
Las principales dificultades a la hora de implementar la Gestin de Problemas se
resumen en:
o Establecer una estrecha colaboracin entre la Gestin de ncidentes y la
de Problemas. Sin sta la Gestin de ncidentes no dispondr de toda la
informacin necesaria para la rpida solucin de los incidentes y la
Gestin de Problemas carecer de la informacin necesaria para
determinar, clasificar y resolver los problemas.
o Mantener actualizadas las bases de datos asociadas requiere un
compromiso por parte de todos los agentes implicados que
frecuentemente requiere un seguimiento cercano de los responsables de
la infraestructura T.
o Aumento de los costes por la contratacin de personal especializado,
aunque estos se vean sobradamente compensados por los beneficios
derivados.
Po$eso
Las principales actividades de la Gestin de Problemas son:
Conto! de Po+!emas: se encarga de registrar y clasificar los problemas para
determinar sus causas y convertirlos en errores conocidos.
Conto! de Eoes: 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 mplementacin 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
G'&i$o NP 675: Procesos mplicados en la Gestin de Problemas
Po$eso 3 Conto! de Po+!emas
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.
G'&i$o NP 67=: Control de Problemas
Aplicacin Web
El Control de Problemas se compone en esencia de tres fases:
71 Identi&i$a$i)n - Re0isto
Una de las tareas principales de la Gestin de Problemas es identificar los
mismos. Las principales fuentes de informacin utilizadas son:
o La +ase de datos de In$identes: 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 T
antes de elevarlo a la categora de problema.
o An'!isis de !a in&aest($t(a 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 T para evitar futuros problemas.
o Deteioo de !os Ni#e!es de Se#i$io: 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 T 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 T.
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 Cs implicados.
o Causas del problema.
o Sntomas asociados.
o Soluciones temporales.
o Servicios involucrados.
o Niveles de prioridad, urgencia e impacto.
Aplicacin Web
o Estado: activo, error conocido, cerrado.
51 C!asi&i$a$i)n - Asi0na$i)n de Re$(sos
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 (Cs)
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 ncidentes 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 T.
=1 An'!isis - Dia0n)sti$o: Eo $ono$ido
Los objetivos principales del proceso de anlisis son:
o Determinar las causas del problema.
o Proporcionar soluciones temporales a la Gestin de ncidentes para
minimizar el impacto del problema hasta que se implemente los cambios
necesarios que lo resuelvan definitivamente.
Es esencial tener en cuenta que no siempre el origen del problema es un error de
hardware o software. Es moneda frecuente que el problema este causado por:
o Errores de procedimiento.
o Documentacin incorrecta.
Aplicacin Web
o Falta de coordinacin entre diferentes reas.
o ...
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 nternet 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.
Po$eso 3 Conto! de Eoes
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.
G'&i$o NP 67>: Control de Errores
Aplicacin Web
Identi&i$a$i)n - Re0isto de eoes
El registro de los errores conocidos es de vital importancia para la Gestin de
ncidentes pues debe llevar asociado, siempre que esto sea posible, algn tipo de
solucin temporal que permita minimizar el impacto de los incidentes asociados.
An'!isis - So!($i)n
Se deben investigar diferentes soluciones para el error evaluando en cada
momento:
o El posible impacto de las mismas en la infraestructura T.
o Los costes asociados.
o Sus consecuencias sobre los SLAs.
En algunos casos, en los que el impacto del problema puede tener consecuencias
graves en la calidad del servicio, pueden emitirse una RFC de emergencia para su
procesamiento urgente por la 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 T a corto plazo o por el escaso impacto
del problema en cuestin.
o Es la solucin temporal aportada suficiente para mantener unos niveles
de calidad de servicios aceptable?
o Los beneficios justifican los costes asociados?
Sea cual sea la respuesta, todo la 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
Re#isi)n Post Im"!ementa$i)n - Ciee
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 (PR).
Si los resultados de esta PR 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.
51@1B1 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:
G'&i$o NP 67?: Metodologas de Desarrollo de Software
Aplicacin Web
F(ente: 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 4Rationa! Uni&ied Po$ess8:
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 nicial
Aplicacin Web
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. ntercepcin (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 terativo e
ncremental. 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
G'&i$o NP 67@: Dos Dimensiones de RUP
F(ente: ntroduccin 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. mplementacin.
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
Conjuntos de Artefactos.
o Business Modeling Set.
o Requirements Set.
o Analysis & Design Set.
o mplementation Set.
o Test Set.
o Deployment Set.
o Project Management Set.
o Configuration & Change Management Set.
o Environment Set.
Caractersticas Esenciales de RUP:
Proceso Dirigido por los Casos de Uso
Proceso terativo e ncremental
Proceso Centrado en la Arquitectura
Proceso terativo e ncremental:
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
G'&i$o NP 67A: Proceso terativo ncremental
F(ente: ntroduccin a Rational Unified Process (RUP) - Patricio Letelier 2000
P(ntos C!a#es:
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.
VP 4EWteme Po0ammin08 ) Po0ama$i)n EWtema:
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]. nclusive 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.
DiseFo sim"!e1
Aplicacin Web
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.
Inte0a$i)n $ontin(a1
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.
Codi&i$a$i)n de est'nda1
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
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.
P(ntos C!a#es:
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 4Desao!!o ManeCado Po Ras0os8:
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
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.
OBJETVOS
Sintetizar un programa conforme a los rasgos requeridos.
Aplicacin Web
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. mplementar en base a las funcionalidades o rasgos.
G'&i$o NP 67B: Proceso FDD
F(ente: 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
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.
P(ntos C!a#es:
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
51A1 MARCO CONCEPTUAL:
T<t(!o
"Sistema de Control para las Tareas del Servicio de Soporte Tcnico de la Oficina de
nformtica de la Municipalidad Provincial de Piura mediante una Aplicacin Web
A"!i$a$i)n *e+1
"La World Wide Web nternet 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." [EEE]
con respecto a la herramienta a producir en el presente proyecto.
Sistema de Conto! "aa !as Taeas de! Se#i$io de So"ote T%$ni$o de !a
O&i$ina de In&om'ti$a de !a M(ni$i"a!idad Po#in$ia! de Pi(a1
"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." [SOMMERVLLE, 2002] con respecto al control que
asumira soporte tcnico en sus tareas de mantenimiento en la Municipalidad
Provincial de Piura.
Metodo!o0<a Rationa! Uni&ied Po$ess 4RUP81
"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
51B1 DIPOTESIS:
La implementacin de una Aplicacin Web influye en el sistema de control de las tareas
del servicio de Soporte Tcnico de la Oficina de nformtica de la Municipalidad Provincial
de Piura.
51E1 VARIAJLES E INDICADORES IMPLICADOS EN EL PROGECTO:
Vaia+!e Inde"endiente:
A"!i$a$i)n *e+:
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 nformacin
actual que presenta el rea de Soporte Tcnico permitir optimizar dichos
procesos, siendo ms eficientes y reduciendo el tiempo de las atenciones.
Vaia+!e De"endiente:
Sistema de Conto! "aa !as Taeas de! Se#i$io:
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.
Vaia+!e Inte#iniente:
Po$eso Uni&i$ado de Ra$iona! 4RUP8:
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
Indi$adoes:
No Indi$ado
De&ini$i)n
Con$e"t(a!
De&ini$i)n O"ea$iona!
Unidad de
Medida
T%$ni$a de
Medi$i)n
Inst(mentos
de Medi$i)n
I67 Tiempo para
llegar a atender
una Solicitud de
Servicio.
Tiempo que el
tcnico demora
en llegar a una
solicitud de
servicio.

n
S
S
n
i
i
S
=
=
1

S
s
- Tiempo de Asistencia
a la Solicitud de Servicio.
S = Tiempo de traslado
entre servicio.
n = Cantidad total de
Solicitudes de Servicio
Minutos Observacin Gua de
Observacin
N 01
(Cronmetro)
Anexo
I65 Tiempo para
solucionar una
solicitud de
Servicio.
Es el tiempo que
el tcnico
demora en
solucionar una
solicitud de
servicio.

n
T
T
n
i
i
S
=
=
1

3
s
= Tiempo de solucin
de Solicitudes de
Servicio.
3 = Tiempo para realizar
una Solucin de Servicio.
Solicitudes de Servicio
Observacin
N 02
(Cronmetro)
Anexo
I6= Cumplimiento de
un Tcnico en
cuanto a los
Servicios
Asignados.
Porcentaje de
solicitudes de
servicios
atendidas por
tcnico.

% 100
1
x
T
M
S
n
i
i
M
=
=
SM= Porcentaje de
cumplimiento de un
tcnico de sus servicios
asignados.
M = Solicitudes
atendidas.
T = Total de Solicitudes
de Servicios Asignados.
Porcentaje Observacin Gua de
Observacin
N 03
Anexo
I6> Porcentaje de
Servicio no
atendidos.
Porcentaje de
Solicitudes
realizadas por el
usuario que no
han sido
atendidas por
diversos
motivos.

% 100
1
x
N
Sna
S
n
i
i
n
=
=
S
n
4 Porcentaje de
Servicios no atendidos.
Sna = Servicio no
atendido.
5 4 Total de Solicitudes.
Porcentaje Observacin Gua de
Observacin
N 04
Anexo
C(ado NP 665: ndicadores de la Variable Dependiente
F(ente: El Autor
Aplicacin Web
No Indi$ado
De&ini$i)n
Con$e"t(a!
Unidad de
Medida
T%$ni$a de
Medi$i)n
Inst(mentos
de Medi$i)n
I6? Solicitudes de
Servicio
Asignadas por
Tcnico.
Es el nmero de
servicios
asignados a
cada tcnico.

=
=
n
t
t S
S S
1
S
t
=servicio asignado por
tcnico.
t =orden de servicio
asignada al tcnico.
Ss =Solicitudes de
Servicio.
Unidad Observacin Gua de
Observacin
N 05
Anexo
I6@ Solicitudes de
Servicio por
oficina.
Es el nmero de
servicios
solicitados por
oficina.

=
=
n
i
i S
S S
1
SS = Solicitudes de
Servicios de Oficina.
Si = Solicitudes de
servicios de la Oficina
especificada.
Observacin
N 06
Anexo
I6A Nmero de
equipos
internados.
Son los equipos
que provienen
de otra oficina y
que tienen que
ser atendidos en
Soporte.

=
=
n
i
i l
G E
1
El=Nmero de Equipos
de otro local.
Gi=Guas de Salida.
Observacin
N 07
Anexo
I6B Tiempo de
bsqueda de
historial tcnico.
Tiempo para
buscar la
informacin de
mantenimiento
(bitcora) de un
equipo.

n
T
T
n
i
i
B
=
=
1
TB = Tiempo de
Bsqueda
T = Tiempo de Bsqueda
de historial Tcnico.
bsquedas
Observacin
N 08
(Cronmetro)
Anexo
I6E Tiempo de
Emisin (entrega)
de Documentos
(Reportes, Guas
de salida y/o
Fichas Tcnicas).
Tiempo
transcurrido
para la entrega
de la
documentacin
solicitada.

n
t
T
n
i
i
ED
=
=
1
TED = Tiempo de Emisin.
t = Tiempo de Entrega
por documento.
documentacin
Observacin
N 09
(Cronmetro)
Anexo
C(ado NP 665: ndicadores de la Variable Dependiente (continuacin)
F(ente: El Autor
Aplicacin Web
No Indi$ado
De&ini$i)n
Con$e"t(a!
Unidad de
Medida
T%$ni$a de
Medi$i)n
Inst(mentos
de Medi$i)n
I76 Nivel de
satisfaccin del
usuario.
Medimos la
conformidad de
los usuarios con
la herramienta a
desarrollar.

% 100
1
x
n
Us
N
n
i
i
S
=
=
NS = Nivel de
Satisfaccin.
Us = Usuario Satisfecho.
usuarios
Porcentaje Encuesta Cuestionario
de Encuesta
N 01
Anexo
C(ado NP 665: ndicadores de la Variable Dependiente (continuacin)
F(ente: El Autor
Aplicacin Web
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
CAPITULO III:
METODOLOGIA
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
=1 METODOLOGIA:
Aplicacin Web
=171 TIPO DE ESTUDIO:
Los propsitos bsicos del paradigma cuantitativo en la investigacin socio-
educativa 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 nvestigacin 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.
=151 DISEXO DEL ESTUDIO:
Aplicacin Web
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 nicial
O2 : Post-test o Prueba Final
X : Variable nterviniente
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.
=1=1 POJLACI9N G MUESTRA:
Po+!a$i)n
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.
M(esta
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 nformtica 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
=1>1 MTODOS DE INVESTIGACI9N:
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.
=1?1 TCNICAS E INSTRUMENTOS DE RECOLECCI9N DE DATOS:
T%$ni$as
Las tcnicas de recoleccin de datos que se emplearn son: encuestas y
observacin. Estas nos ayudarn a recoger informacin primordial para
desarrollar el presente trabajo de investigacin o tesis que tiene por ttulo:
"Sistema de Control para las Tareas del Servicio de Soporte Tcnico de la
Oficina de nformtica de la Municipalidad Provincial de Piura.
Inst(mentos
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
C(ado NP 66=: ndicadores, Tcnicas e nstrumentos de Recoleccin de Datos
F(ente: El Autor
=1@1 MTODOS DE ANHLISIS 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.
NY Indi$adoes T%$ni$as Inst(mentos
1
Tiempo para llegar a atender una
Solicitud de Servicio.
Observacin Gua de Observacin
2
Tiempo para solucionar una
solicitud de Servicio.
3
Cumplimiento de un Tcnico en
cuanto a los Servicios Asignados.
4
Porcentaje de Servicio no
atendidos.
5
Solicitudes de Servicio Asignadas
por Tcnico.
6 Solicitudes de Servicio por oficina. Observacin Gua de Observacin
7 Nmero de equipos internados. Observacin Gua de Observacin
8
Tiempo de bsqueda de historial
tcnico.
9
Tiempo de Emisin (entrega) de
Documentos (Reportes, Guas de
salida y/o Fichas Tcnicas).
10 Nivel de satisfaccin del usuario. Encuesta Cuestionario de Encuesta
Aplicacin Web
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
CAPITULO IV:
ADMINISTRACION
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
Aplicacin Web
>1 ADMINISTRACION:
>171 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:
C(ado NP 66>: Cronograma de Actividades de la Tesis
F(ente: El Autor
Aplicacin Web
>151 PRESUPUESTO:
Re$(sos Cantidad CZU
Pe$io
Tota!
Jienes
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
Papel A4 1 millar S/. 25.00 S/. 25.00
CD's de 700 MB 10 S/. 1.00 S/. 10.00
Lapiceros 10 S/. 0.50 S/. 5.00
Se#i$ios
Luz Elctrica ___ ___ S/. 200.00
nternet 200 horas S/. 1.00 S/. 200.00
Telfono ___ ___ S/. 100.00
Movilidad ___ ___ S/. 400.00
Fotocopiado 500 hojas S/. 0.05 S/. 25.00
Anillados 2 S/. 5.00 S/. 10.00
Empastados 3 S/. 20.00 S/. 60.00
Rem(nea$iones
Personal de apoyo ___ ___ S/. 400.00
Otros ___ ___ S/. 200.00
Tota! S/. 1,895.00
C(ado NP 66?: Presupuesto de la Tesis
F(ente: El Autor
>1=1 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
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
CAPITULO V:
REFERENCIAS JIJLIOGRAFICAS
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
Aplicacin Web
[H!#ae2 JotonsK Es"aFaK 566>\ Sistemas de Control, artculo publicado por en la
Universidad Politcnica de Catalunya.
[Je$UK 5666\ Beck, Kent, Extreme Programming Explained, Addison-Wesley The XP
Series.
[Joe.mK no#iem+e 7EE?\ Boehm, Barry W., Anchoring the Software Process, USC.
[Joo$.K 5666\ Booch, Grady, var Jacobson, James Rumbaugh, The Unified Modeling
Language User Guide, Addison-Wesley Object Technology Series.
Casto A%#a!oK Man(e! L Ia"ata Na#aoK J.on 4Pi(a M 566E8, "Sistema nformtico
de Registro de Mantenimiento de Equipos de Cmputo del rea de Soporte del Centro de
nformtica y Telecomunicaciones de la Universidad Nacional de Piura. Universidad
Csar Vallejo Filial Piura.
[CoadK 7EEB\ Coad, Peter, Eric Lefebvre, Jeff De Luca, Feature-Driven Development,
Disponible en: http://www.cs.jhu.edu/~scott/oos/software/togetherj/help/Users-
Guide/Feature_Driven_Development.htm
Es"ino2a Saa#edaK Danie! 4Va!"aa<soK C.i!e M 566>8, "Estudio del Sistema de
Monitoreo y Registro de nventarios de Compras y su ntegracin Estratgica mediante el
Control de Gestin. Universidad de Valparaso.
[Feeman E!isa+et.K 566>\ et. al. Head First Design Patterns. California: O'Reilly Media.
[Gamma Ei$.K 7EE?\ et. al. Design Patterns.Elements of Reusable Object-Oriented
Software. Boston: Addison-Wesley.
[Dao" Ro+K 566?\ et al. Pro Spring. Nueva York: Apress.
[Denande2 Sam"ieiK Ro+eto] Fen'nde2 Co!!adoK Ca!os] Ja"tista L($ioK Pi!a]
M%Wi$o 566=\ Metodologa de la nvestigacin. Mc Graw Hill.
Aplicacin Web
[Jo.nson Ro+K 566=\ Expert One-on-One J2EE Design and Development. ndianapolis:
Wrox Press.
[Jo.nson Ro+K ma-o 566?\ ntroduction to the Spring Framework. [En lnea].
Disponible en: www.theserverside.com/articles/article.tss?l=SpringFramework
[Jos% Pad)n G1\ Bases del concepto de "nvestigacin Aplicada"[en lnea].
Disponible en: http://padron.entretemas.com/nvAplicada/index.htm
Metodo!o0<as de Desao!!o de So&tTae 4Es"aFa M 566@8, artculo publicado por la
Universidad Rey Juan Carlos.
Metodo!o0<a ITIL (nformation Technologies nfraestructure Library) OSATS S.A. V2.0
Disponible en: http://itil.osiatis.es/Curso_TL/
[P1 Lete!ieK Iaa0o2aK o$t(+e 5666\ Metodologas de Produccin de Software.
Pes'nte2 D(etaK H!#ao Ed(ado 4G(a-aO(i!K E$(ado M 566A8, "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.
P!an Estat%0i$o Instit($iona! 4566E M 567>8, Municipalidad Provincial Piura (PE-MPP)
P!an O"eati#o Instit($iona! 456778, Municipalidad Provincial de Piura (POMPP)
Re0!amento de O0ani2a$i)n - F(n$iones, Municipalidad Provincial Piura (ROF-MPP)
[RUPK 5665\ Rational Unified Process Version 2002.05.00, Copyright Rational
Software Corporation, All Rights Reserved.
Sa!$edo Unti#eosK Ri$.ad O!ando 4Pi(a M 566A8, "Anlisis, Diseo y Desarrollo del
Mdulo Web para la Gestin y Control de nventario de Bienes de la Oficina de Control
Patrimonial de la Direccin Regional de Salud Piura. Universidad Nacional de Piura.
Aplicacin Web
[Sant^AnnaK F1K 7EB=\ Estratgias quantitativas e qualitativas de pesquisa educational: da
ao a obser-vao participante. Educao e realidade.
Santi!!'n PinedoK Na!a L Toneo Mendo2aK L(d#e 4T(Ci!!o M 56678, "Sistema de
nformacin de Control de Almacn de la Direccin Regional de Educacin de La Libertad
DRELL. Universidad Csar Vallejo.
[Smit.K J1K 7EB=\ Quantitative versus qualitative research: An attempt to clarify the issue.
Educational Researcher.
[Somme#i!!eK IanK 5665\ ngeniera del Software.
[Ta-!oK S1 J1 - Jo0danK R1K 7EB@\ ntroduccin a los mtodos cualitativos de
investigacin. La bsqueda de significados. Buenos Aires: Editorial Paids.
Ve0a J(stamanteK Ro$<o O!inda 4Lima M 566E8, "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.
[*a!!s Cai0K 566?\ et. al. Spring in Action. Greenwich: Manning Publications.
Aplicacin Web
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
CAPITULO VI:
ANEVOS
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
Aplicacin Web
ANEVO 67
G(<a de O+se#a$i)n NY 67
Tiem"o "aa !!e0a a atende (na so!i$it(d de se#i$io1
Inst($$iones: 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 nicio: _________
N/meo
Doa de
Ini$io
Doa de
L!e0ada
Tiem"o Tota!
4Min8
Tiem"o Pomedio
Hora Final: _________Fecha de fin de observacin: __/ __/ _____
Observaciones:
_________________________________________________________________
_________________________________________________________________
___________________________________________________________
O+se#ado
Revisado Procesado Archivado
Aplicacin Web
ANEVO 65
G(<a de O+se#a$i)n NY 65
Tiem"o "aa so!($iona (na so!i$it(d de se#i$io1
Inst($$iones: 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.
N/meo Doa de Ini$io Doa de Fina!i2a$i)n
Tiem"o
Tota! 4Min8
Tiem"o Pomedio
Observaciones:
_________________________________________________________________
_________________________________________________________________
___________________________________________________________
O+se#ado
Aplicacin Web
ANEVO 6=
G(<a de O+se#a$i)n NY 6=
C(m"!imiento de (n t%$ni$o en $(anto a !os se#i$ios asi0nados1
Inst($$iones: 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.
T%$ni$o
Cantidad
So!i$it(des
Asi0nadas
Cantidad
So!i$it(des
Atendidas
Po$entaCe
C(m"!imiento
Observaciones:
_________________________________________________________________
_________________________________________________________________
___________________________________________________________
O+se#ado
Aplicacin Web
ANEVO 6>
G(<a de O+se#a$i)n NY 6>
Po$entaCes de Se#i$ios no Atendidos1
Inst($$iones: En los das de observacin se tomarn las cantidades de los
servicios no atendidos y el total de las solicitudes de servicio.
D<a
Cantidad
So!i$it(des
Cantidad
So!i$it(des
no Atendidas
Po$entaCe
Se#i$ios no
Atendidos
Observaciones:
_________________________________________________________________
_________________________________________________________________
___________________________________________________________
O+se#ado
Aplicacin Web
ANEVO 6?
G(<a de O+se#a$i)n NY 6?
So!i$it(des de Se#i$io Asi0nadas "o T%$ni$o1
Inst($$iones: En los das de observacin se tomarn las cantidades de las
solicitudes de los servicios asignados a un tcnico.
T%$ni$o
Cantidad
So!i$it(des
Asi0nadas
Observaciones:
_________________________________________________________________
_________________________________________________________________
___________________________________________________________
O+se#ado
Aplicacin Web
ANEVO 6@
G(<a de O+se#a$i)n NY 6@
So!i$it(des de Se#i$io "o O&i$ina1
solicitudes de los servicios de oficinas especficas.
O&i$ina
Cantidad
So!i$it(des
Se#i$ios
Observaciones:
_________________________________________________________________
_________________________________________________________________
___________________________________________________________
O+se#ado
Aplicacin Web
ANEVO 6A
G(<a de O+se#a$i)n NY 6A
N/meo de EO(i"os Intenados1
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 nicio: _________
D<a
Cantidad de
EO(i"os de Ota
De"enden$ia
Observaciones:
_________________________________________________________________
_________________________________________________________________
___________________________________________________________
O+se#ado
Aplicacin Web
ANEVO 6B
G(<a de O+se#a$i)n NY 6B
Tiem"o de J/sO(eda de Distoia! T%$ni$o1
la bsqueda del historial tcnico de un equipo y la hora de finalizacin de dicha
bsqueda.
N/meo
Doa de
Ini$io
Doa de
Fina!i2a$i)n
Tiem"o Tota!
4Min8
Tiem"o Pomedio
Observaciones:
_________________________________________________________________
_________________________________________________________________
___________________________________________________________
O+se#ado
Aplicacin Web
ANEVO 6E
G(<a de O+se#a$i)n NY 6E
Tiem"o de Emisi)n de Do$(mentos1
la emisin de un documento (reportes, guas de salida y/o fichas tcnicas) y la
hora de finalizacin o entrega de dicho documento.
N/meo
Doa de
Ini$io
Doa de
Ente0a
Tiem"o Tota!
4Min8
Tiem"o Pomedio
Observaciones:
_________________________________________________________________
_________________________________________________________________
___________________________________________________________
O+se#ado
Aplicacin Web
ANEVO 76
C(estionaio de En$(esta NY 67
Sistema de Conto! "aa !as Taeas de! Se#i$io de So"ote T%$ni$o de !a
O&i$ina de In&om'ti$a de !a M(ni$i"a!idad Po#in$ia! de Pi(a mediante (na
A"!i$a$i)n *e+,
El presente cuestionario de encuesta ser desarrollado como gua para obtener el
grado de satisfaccin del usuario de la aplicacin web.
_________________________________________________________________
Marque con un crculo o un aspa su repuesta elegida.
1) Con la aplicacin web implementada se ha mejorado su actividad de
trabajo?
a. Nada
b. Poco
c. Medianamente
d. Mucho
2) La aplicacin web implementada es fcil de manejar?
a. Nada
b. Poco
c. Medianamente
d. Mucho
3) Con la aplicacin web implementada la informacin est disponible de
forma inmediata?
a. Nada
b. Poco
c. Medianamente
d. 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
a. Nada
b. Poco
c. Medianamente
d. Mucho
6) La aplicacin web implementada cumple con todos los requisitos
solicitados?
a. Nada
b. Poco
c. Medianamente
d. Mucho
7) Cul es su opinin general de la aplicacin web?
Ga$ias "o s( "ati$i"a$i)n
Este cuestionario de encuesta se mide de la siguiente forma:
Como para cada pregunta se presentan 4 opciones las cuales se asemejan
(grado de 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:
PUNTUACI9N GRADO DE SATISFACCI9N
a Quiere decir que el usuario se
Aplicacin Web
encuentra Nada Satisfecho.
b
Quiere decir que el usuario se
encuentra Poco Satisfecho.
c
encuentra Medianamente Satisfecho.
d
encuentra Muy satisfecho.

Tesis Soporte

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Tesis Soporte

Diunggah oleh

Hak Cipta:

Format Tersedia

UNIVERSIDAD CSAR VALLEJO

Anda mungkin juga menyukai