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

UNIVERSIDAD CÉSAR VALLEJO

PIURA

FACULTAD DE INGENIERÍA

ESCUELA DE INGENIERÍA DE SISTEMAS

“Sistema de Control para las Tareas del Servicio

de Soporte Técnico de la Oficina de Informática de

la Municipalidad Provincial de Piura mediante una

Aplicación Web”

Proyecto de tesis

Autor

Pino Chacón Jesús Antonio Manuel

Asesor

Mg. Luis Velez Ubillus

Piura - Perú

(2011)

Sistema de Control para las Tareas del Servicio de Soporte Técnico de la Oficina de Informática de la Municipalidad Provincial de Piura mediante una Aplicación Web

Universidad César Vallejo-Piura Escuela Ingeniería Sistemas

ASESORES DE TESIS

ASESOR METODOLÓGICO:

___________________


ASESOR ESPECIALISTA:

____________________

Ing. Noelia Saavedra Nizama

2 Jesús Antonio Pino Chacón



INTRODUCCIÓN

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

sistemas cada vez más sofisticados debido al ambiente competitivo en que

vivimos, todo esto tiene como consecuencia un notorio cambio para la Oficina de

Informática, redefiniendo sus objetivos y estrategias que le permitan cambiar la

estructura de las vías de distribución y rediseñar procesos para mejorar sus

servicios, obteniéndose la automatización de varios procesos del sistema de

control para así minimizar las barreras del tiempo y distancia, facilitar el acceso a

fuentes de información y potenciar el desarrollo de los servicios, además incide

favorablemente en la eficiencia operativa, la calidad de los servicios prestados, el

acercamiento con los usuarios o trabajadores que laboran en la municipalidad

provincial de Piura y la coordinación de actividades.

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

control para las tareas del servicio de soporte técnico, sumado al crecimiento de

nuevas técnicas, herramientas y filosofías orientadas a la optimización de los

medios, teniendo como prioridad prevenir y reducir los riesgos suscitados en las

tareas operativas y administrativas relacionadas con la conservación y los

servicios de mantenimiento que se brindan.





DEDICATORIA

El presente proyecto de investigación se lo

dedico a Dios y a mis padres por su

comprensión y ayuda en todo momento. Mis

padres me han enseñado a ser perseverante

para encarar las adversidades de la vida sin

perder nunca la fe y la esperanza ni

desfallecer en el intento de alcanzar nuestros

objetivos y metas.

El Autor



AGRADECIMIENTO

Agradezco primeramente a Dios por haberme motivado para realizar el presente

proyecto de tesis, agradezco también a mis padres por su apoyo incondicional y

por estar siempre a mi lado, a mis maestros porque a través de sus enseñanzas

lograron transmitirme sus conocimientos e inculcarme el deseo por la

investigación.

El Autor




ÍNDICE

Nº Página

CAPITULO I: Generalidades..............................................................................................9

1.1. Título....................................................................................................................10

1.2. Tipo de Investigación............................................................................................10

1.3. Área de Investigación............................................................................................10

1.4. Institución donde se realiza la Investigación...................................................10

1.5. Autor.....................................................................................................................10

1.6. Asesor Metodológico..........................................................................................10

1.7. Asesor Especialista............................................................................................10

1.8. Duración del Proyecto de Investigación...........................................................10

CAPITULO II: Plan de Investigación...............................................................................11

2.1. Descripción de la Realidad Problemática.........................................................12

2.2. Formulación del Problema.................................................................................13

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

2.2.2. Preguntas de Investigación...............................................................................13

2.2.3. Objetivo General.................................................................................................14

2.2.4. Objetivos Específicos.........................................................................................14

2.3. Justificación e Importancia del Proyecto ........................................................15

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

2.5. Marco Referencial Científico..............................................................................17

2.5.1. Antecedentes.......................................................................................................17

2.6. Marco Teórico......................................................................................................20

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

2.6.2 Oficina de Informática........................................................................................24

2.6.3. Soporte Técnico..................................................................................................25

2.6.4. Sistema de Control.............................................................................................26

2.6.5. Aplicación Web...................................................................................................28

2.6.6. Gestión de Incidentes.........................................................................................40

2.6.7. Gestión de Problemas........................................................................................46

2.6.8. Metodología de Desarrollo.................................................................................55

2.7. Marco Conceptual...............................................................................................65

2.8. Hipótesis..............................................................................................................66

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




ÍNDICE

Nº Página

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

3.1. Tipo de Estudio...................................................................................................71

3.2. Diseño del Estudio..............................................................................................72

3.3. Población y Muestra...........................................................................................72

3.4. Métodos de Investigación..................................................................................73

3.5. Técnicas e Instrumentos de Recolección de Datos........................................73

3.6. Métodos de Análisis de Datos...........................................................................74

CAPÍTULO IV: Administración........................................................................................75

4.1. Cronograma.........................................................................................................76

4.2. Presupuesto........................................................................................................77

4.3. Financiamiento....................................................................................................77

CAPÍTULO V: Referencias Bibliográficas......................................................................78

CAPÍTULO VI: Anexos.....................................................................................................82

ANEXO 01: Guía de Observación Nº 01 ........................................................................83

ANEXO 02: Guía de Observación Nº 02.........................................................................84








ANEXO 10: Cuestionario de Encuesta Nº 01.................................................................92




INDICE DE GRAFICOS Y CUADROS

Nº Página

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

Gráfico N° 001: Organigrama de la Municipalidad Provincial de Piura......................23

Gráfico N° 002: Esquema general de un sistema..........................................................26

Gráfico N° 003: Esquema general de un sistema de control.......................................28

Gráfico N° 004: MVC de arquitectura Tipo 1 .................................................................32

Gráfico N° 005: MVC de arquitectura Tipo 2 .................................................................32

Gráfico N° 006: Gestión de Incidentes...........................................................................40

Gráfico N° 007: Proceso de Gestión de Incidentes (resumen) ...................................41

Gráfico N° 008: Diagrama de Prioridades Del Incidente...............................................44

Gráfico N° 009: Proceso de Escalado de Incidentes....................................................45

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

Gráfico N° 011: Interacciones y Funcionalidades de la Gestión de Problemas........47

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

Gráfico N° 013: Control de Problemas...........................................................................50

Gráfico N° 014: Control de Errores.................................................................................53

Gráfico N° 015: Metodologías de Desarrollo de Software............................................55

Gráfico N° 016: Dos Dimensiones de RUP....................................................................57

Gráfico N° 017: Proceso Iterativo Incremental..............................................................59

Gráfico N° 018: Proceso FDD..........................................................................................64

Cuadro N° 002: Indicadores de la Variable Dependiente.............................................67

Cuadro N° 003: Indicadores, Técnicas e Instrumentos de Recolección de Datos....74

Cuadro N° 004: Cronograma de Actividades de la Tesis.............................................76

Cuadro N° 005: Presupuesto de la Tesis.......................................................................77




________________________________________________________

CAPITULO I:

GENERALIDADES

________________________________________________________




1. GENERALIDADES DEL PROYECTO DE INVESTIGACION:

1.1.TÍTULO:

“Sistema de Control para las Tareas del Servicio de Soporte Técnico de la Oficina

de Informática de la Municipalidad Provincial de Piura mediante una Aplicación

Web”

1.2.TIPO DE INVESTIGACIÓN:

“EXPLICATIVA”

1.3.ÁREA DE INVESTIGACIÓN:

“TECNOLOGICA”

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

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

1.5.AUTOR:

Jesús Antonio Manuel Pino Chacón

1.6.ASESOR METODOLÓGICO:


1.7.ASESOR ESPECIALISTA:

Ing. Noelia Saavedra Nizama

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

Inicio: 29 de marzo del 2011

Final: 18 de diciembre del 2011




________________________________________________________

CAPITULO II:

PLAN DE INVESTIGACION

________________________________________________________




2. PLAN DE LA INVESTIGACION:

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

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

esta pertenece a la Gerencia de Tecnologías y Sistemas de Información de la

Municipalidad Provincial de Piura.

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

electrónicos, telefónicos y de redes de la mayoría de equipos que se encuentran

en la municipalidad, se limita a estas actividades y no a proporcionar las políticas

de seguridad y privacidad de la red de trabajo o dominio.

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

Soporte Técnico de la Oficina de Informática de la Municipalidad Provincial de

Piura. De ello se derivan algunos subproblemas como:

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

cuando los problemas son complicados y requieren más recursos se atienden de

una manera inapropiada.

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

Técnico.

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

Soporte Técnico, todo se hace manualmente.

Soporte Técnico no cuenta con un inventario propio.

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

tareas administrativas y de mantenimiento en la municipalidad de Piura ya que

esto depende de la Oficina de Informática.

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

de la municipalidad es poco organizado.




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

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

municipalidad.

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

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

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

adecuado.

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

adecuado.

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

no es el mas conveniente para soporte técnico.

2.2.FORMULACIÓN DEL PROBLEMA:

2.2.1. Pregunta General:

¿Cómo influye una Aplicación Web en el sistema de control de las tareas del

servicio de Soporte Técnico de la Oficina de Informática de la Municipalidad

Provincial de Piura?

2.2.2. Preguntas de Investigación:

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

y planificación de tareas para el proceso del mantenimiento preventivo y

correctivo?

¿De qué manera influye una aplicación web para que Soporte Técnico

cuente con un inventario propio para obtener y a la vez controlar una mayor

cantidad de recursos?

¿De qué manera influye una aplicación web en la mejora del control y

organización para los procesos de atenciones de problemas e incidentes?




¿De qué manera influye una aplicación web para que el Área de Soporte

Técnico tenga independencia para planificar operaciones y tareas

administrativas y de mantenimiento?

2.2.3. Objetivo General:

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

Control de las Tareas del Servicio de Soporte Técnico de la Oficina de

Informática de la Municipalidad Provincial de Piura”

2.2.4. Objetivos Específicos:

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

organización y la planificación de tareas para el proceso del

mantenimiento preventivo y correctivo de los diferentes equipos de la

Municipalidad Provincial de Piura.

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

un inventario propio en Soporte Técnico para controlar y obtener una

mayor cantidad de recursos necesarios para las tareas de los

servicios que se realizan en la Municipalidad Provincial de Piura.

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

optimización del control y la organización para el proceso de

atenciones de problemas e incidentes que acontecen en las

dependencias de la Municipalidad Provincial de Piura.

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

de Soporte Técnico tenga independencia para planificar operaciones

y tareas administrativas y de mantenimiento.

2.3.JUSTIFICACIÓN E IMPORTANCIA DEL PROYECTO:




En vista de las necesidades del Área de Soporte Técnico de la Municipalidad de

Piura de llevar un mejor control en la atención y solución de problemas técnicos

que sufren los equipos de las diferentes áreas de la Municipalidad es que se

desarrolla el presente proyecto para beneficiar tanto a los usuarios de la

Municipalidad Provincial de Piura como a los trabajadores que laboran en el área

de ST.

Este proyecto abarcará también un mejor manejo del Inventario que compete a la

Oficina de Informática ya que se podrá saber que equipos son dados de baja y

cuáles son los que hacen falta para tener un stock adecuado en nuestro

inventario.

Con este trabajo de investigación se podrá optimizar el tiempo horas hombre y se

podrán atender una mayor cantidad de problemas que surjan en las diferentes

oficinas de la Municipalidad de Piura y que en verdad necesiten la atención de

Soporte Técnico dando soluciones rápidas y adecuadas a dichos problemas.

Justificación Administrativa

Este proyecto es una alternativa de solución al problema de Control y

Organización para el Mantenimiento de Equipos Informáticos, cuyo desarrollo

además de fortalecer el logro óptimo de los objetivos institucionales, agiliza las

actividades desarrolladas por el área en la cual nuestra aplicación web será

implementada.

Justificación Científica

El trabajo es desarrollado en base al método científico, que va desde la

observación del objeto de estudio hasta las conclusiones y recomendaciones. El

producto final alcanzado, será lo que justifique la investigación.

Justificación Institucional

Uno de los objetivos de la Municipalidad Provincial de Piura es mejorar la gestión

administrativa y propiciar la descentralización de sus unidades y dependencias,

mediante el uso de tecnologías de información. Para ello se implementará un

nuevo sistema de información y/o control (aplicación web) para satisfacer las

necesidades del usuario y puedan desarrollar sus actividades eficientemente.

Justificación Social




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

mejorará la administración de los recursos informáticos para ofrecer servicios de

calidad a la población y en consecuencia mejorar la imagen institucional del

Gobierno Regional de Piura.

Justificación Tecnológica

Como entes de investigación y aprendizaje obtendremos nuevos conocimientos y

experiencia como profesionales, manteniéndonos a la vanguardia de los

requerimientos de nuestro entorno y la adecuada capacitación en cuanto a nuevas

tecnologías de información se refiere. Puesto que una de las competencias

exclusivas de la Municipalidad Provincial de Piura es promover la modernización,

actualización e innovaciones tecnológicas.

2.4.LIMITACIONES DEL PROYECTO:

El limitado acceso a información de los sistemas informáticos que pueden

servir de guía para el desarrollo de la presente investigación.

El trabajo dinámico o poca disponibilidad del personal de Soporte Técnico

limitará la información que se pueda obtener de ellos para el desarrollo de la

presente aplicación web.

Los escasos recursos tecnológicos que dispone el área de soporte técnico

para el desarrollo del presente proyecto.

La aplicación web a desarrollar será independiente a la aplicación web

institucional de la municipalidad.

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

servirá de guía y/o modelo para la base de datos de nuestro sistema de control

(aplicación web) para Soporte Técnico.

2.5.MARCO REFERENCIAL CIENTIFICO:




2.5.1. Antecedentes:

Antecedentes Locales:

Castro Arévalo, Manuel & Zapata Navarro, Jhon (Piura – 2009), “Sistema

Informático de Registro de Mantenimiento de Equipos de Cómputo del Área

de Soporte del Centro de Informática y Telecomunicaciones de la

Universidad Nacional de Piura”, presentan su tesis con la que obtuvieron los

Títulos Profesionales de Ingenieros de Sistemas en la Universidad César

Vallejo – Filial Piura. Castro & Zapata con este trabajo de investigación

buscan registrar cada uno de los mantenimientos que se les realiza a todos

los equipos que llegan al área de soporte y también buscan organizar y

monitorear el inventario de todos los equipos de la Universidad Nacional de

Piura.

Relación: Esta tesis se toma en cuenta porque implementa un sistema

informático que se encarga de registrar datos detallados de los equipos de

cómputo (inventario) y los mantenimientos que estos reciben, considerando

también la respectiva organización y monitoreo, así como los beneficios que

otorga.

Salcedo Untiveros, Richard Orlando (Piura – 2007), “Análisis, Diseño y

Desarrollo del Módulo Web para la Gestión y Control de Inventario de Bienes

de la Oficina de Control Patrimonial de la Dirección Regional de Salud Piura”,

presenta su tesis con la que obtuvo el Título Profesional de Ingeniero

Informático en la Universidad Nacional de Piura. Salcedo con este proyecto

de tesis busca gestionar y controlar el inventario de bienes de la Dirección

Regional de Salud Piura incluyendo los procesos de registro de bienes,

verificación del estado de los bienes, baja de bienes.

Relación: Esta tesis se toma en consideración porque implementa un

módulo web que presenta entornos de trabajo correspondientes a cada área

de acción por usuario, relacionada con la gestión y control de inventario, así

como las ventajas que este otorga.

Antecedentes Nacionales:




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

implementación de un sistema de administración de incidentes en atención al

cliente para una empresa de telecomunicaciones”, presenta su tesis con la

que obtuvo el Título Profesional de Ingeniero Informático en la Pontificia

Universidad Católica del Perú. Vega con este proyecto de investigación

busca monitorear el tiempo de atención de los casos que presente el cliente

en una empresa de telecomunicaciones, de allí que la presente tesis

presenta el análisis, desarrollo e implementación de un sistema de

administración de incidentes en Atención al Cliente para una empresa de

telecomunicaciones.

Relación: Esta tesis se toma en consideración porque implementa un

sistema de administración de incidentes que monitorea el tiempo de atención

de los casos que presente el cliente y de seguir la normativa establecida y

las ventajas que esto otorga.

Santillán Pinedo, Karla & Tornero Mendoza, Ludver (Trujillo – 2001),

“Sistema de Información de Control de Almacén de la Dirección Regional de

Educación de La Libertad – DRELL”, presentan su tesis con la que

obtuvieron los Títulos Profesionales de Ingenieros de Sistemas en la

Universidad César Vallejo. Santillán & Tornero con este proyecto de tesis

buscan mejorar la gestión del área de almacén de la sede central de la

DRELL, en la cual se realizó un estudio para poder lograr los objetivos

institucionales de la misma, incluyendo eficiencia y eficacia en los trámites

que se desarrollan, acceso directo y rápido a la información, distribución ágil

y rápida de los artículos que piden los usuarios de la DRELL, monitoreo

constante del stock de almacén, entre otros procesos mejorados que son

propios de dicha área.

Relación: Esta tesis se toma en cuenta porque implementa un sistema que

centraliza la información de los equipos informáticos, para un mejor control

de almacén con los respectivos procesos que se llevan a cabo, para

finalmente con la información brindada sirva de apoyo para nuevas

adquisiciones.

Antecedentes Internacionales:




Pesántez Huerta, Álvaro Eduardo (Guayaquil, Ecuador – 2007),

“Elaboración de un Plan de Mantenimiento Predictivo y Preventivo en

Función de la Criticidad de los Equipos del Proceso Productivo de una

Empresa Empacadora de Camarón”, presenta su tesis con la que obtuvo el

Título Profesional de Ingeniero Industrial en la Escuela Superior Politécnica

del Litoral. Pesantez con este trabajo de investigación busca realizar un plan

de mantenimiento predictivo y preventivo de los equipos, el cual contendrá el

detalle del mantenimiento recomendado por los fabricantes y los técnicos

internos y/o externos de la empresa; así como también el detalle de cada

equipo y cuáles serán las frecuencias de los diversos mantenimientos

preventivos establecidos.

Relación: Esta tesis se toma en consideración porque implementa un plan

de mantenimiento predictivo y preventivo enfocado a brindar una guía

confiable de los tipos y frecuencias de mantenimiento para los equipos, esta

guía servirá como modelo para desarrollar los módulos webs de

mantenimiento predictivo, preventivo y correctivo de la aplicación web a

desarrollar.

Espinoza Saavedra, Daniel (Valparaíso, Chile – 2004), “Estudio del

Sistema de Monitoreo y Registro de Inventarios de Compras y su Integración

Estratégica mediante el Control de Gestión”, presenta su tesis con la que

obtuvo el Grado de Magíster en Gestión mención Control en la Universidad

de Valparaíso. Espinoza con este proyecto de investigación busca presentar

las posibilidades que ofrece un modelo de control dentro de un sistema de

inventarios de compras mediante la aplicación de los conceptos

constructivos de un cuadro de mando.

Relación: Esta tesis se toma en cuenta porque nos proporciona información

importante sobre las posibilidades y riesgos de implementar un control de

gestión en un inventario de compras y los beneficios que este otorga.

2.6.MARCO TEORICO:




2.6.1. MUNICIPALIDAD PROVINCIAL DE PIURA:

Misión, Visión y Objetivos de la Institución:

Misión

Gobernar, conducir y liderar el desarrollo de la provincia, gestionando y

promoviendo el desarrollo sostenible, integral y el bienestar humano, mediante

acciones de concertación institucional y de participación de la sociedad civil

organizada. [PEI – MPP]

Visión

La Municipalidad Provincial de Piura al 2014, aplica una gestión moderna,

eficiente y participativa, con creciente igualdad de oportunidades, sistema

distrital democrático, institucionalidad participativa, ámbitos urbano y rural

articulados, con hombres y mujeres emprendedoras y ciudades abiertas,

seguras, sostenibles, ordenadas, modernas y limpias. [PEI – MPP]

Objetivos

1) Conducir, promover y fomentar el desarrollo socio-económico integral,

sostenible y armónico, priorizando y planificando las necesidades del distrito y

provincia de Piura.

2) Promover el bienestar del ciudadano con la adecuada prestación de los

servicios públicos locales que satisfagan sus necesidades vitales de

salubridad, vivienda, abastecimiento, seguridad, cultura, recreación, transporte

y comunicaciones.

3) Representar política y organizacionalmente a los vecinos en el Gobierno

Local, mediante programas de participación comunal y el ejercicio del derecho

de petición.

4) El Ejercicio de la Función Conciliadora.

5) Desarrollar programas sociales básicos.

6) Promover el desarrollo económico local mediante el impulso a las pequeñas

y micro empresas (PYMES), de acuerdo a las normas y políticas regionales y

nacionales.

7) Brindar la infraestructura, apoyo, asesoramiento a los promotores y agentes

del desarrollo económico, facilitándoles el espacio físico para sus actividades

de acuerdo a la normatividad vigente. [ROF – MPP]




Políticas Generales de la Institución:

OBJETIVOS ESTRATEGICOS

LINEAS POLITICAS OBJETIVO META

Política N° 01

Desarrollo Institucional

La Municipalidad Provincial de Piura es

una corporación edil eficaz y eficiente que

resuelve el 100 % de sus operaciones de

manera moderna, ágil y dinámica.

Política N° 02

Desarrollo Social

La Municipalidad Provincial de Piura

cuenta con una Red de Participación

Ciudadana mediante la cual ha

organizado el 100 % de Juntas Vecinales

dentro de las jurisdicciones de su

competencia.


cuenta con una Red de Desarrollo Social

que contribuye, concerta y monitorea el

100 % de los servicios de educación,

salud y trabajo.

Política N° 03

Desarrollo Económico y

Financiero


cuenta con un Sistema de Desarrollo

Económico y Financiero que le permite

incrementar sus recursos en un 5 %

anual.

Política N° 04

Organización Territorial

La Municipalidad Provincial de Piura es la

primera en el país que logra delimitar y

adecuar integralmente el 100 % de su

territorio.

Cuadro N° 001: Política Institucionales

Fuente: PEI – MPP

Actividades Principales de la Institución:




1) Planificar integralmente el desarrollo local y el ordenamiento territorial, en el

nivel provincial.

2) Promover permanentemente la coordinación estratégica de los planes

integrales de desarrollo de los distritos. Los planes referidos a la organización

del espacio físico y uso del suelo que emitan las municipalidades distritales

deberán sujetarse a los planes y las normas generales de la Municipalidad

Provincial de Piura.

3) Promover, apoyar y ejecutar proyectos de inversión y servicios públicos

municipales que presenten objetivamente externalidades o economías de

escala de ámbito provincial; para cuyo efecto suscribirá convenios con las

respectivas municipalidades distritales.

4) Emitir las normas técnicas generales, en materia de organización del

espacio físico y uso del suelo, así como sobre protección y conservación del

medio ambiente.

5) Proponer proyectos de ley, a través de iniciativas legislativas. [ROF – MPP]

Organigrama de la Institución:

Toda empresa cuenta en forma implícita o explícita con cierto juego de

jerarquías y atribuciones asignadas a los miembros o componentes de la

misma. En consecuencia se puede establecer que la estructura organizativa

de una empresa es el esquema de jerarquización y división de las funciones

componentes de ella.

Jerarquizar es establecer líneas de autoridad (de arriba hacia abajo) a través

de los diversos niveles y delimitar la responsabilidad de cada empleado ante

solo un supervisor inmediato. Esto permite ubicar a las unidades

administrativas en relación con las que le son subordinadas en el proceso de

la autoridad. El valor de una jerarquía bien definida consiste en que reduce la

confusión respecto a quien da las órdenes y quien las obedece. Define como

se dividen, agrupan y coordinan formalmente las tareas en los puestos. [MPP]




Gráfico N° 001: Organigrama de la Municipalidad Provincial de Piura

Fuente: Municipalidad Provincial de Piura (MPP)




2.6.2. OFICINA DE INFORMATICA:

Misión, Visión, Objetivos y Metas de la Oficina de Informática:

Misión

Promover el desarrollo y la utilización de un sistema de información moderno

de acuerdo a las necesidades de los diferentes usuarios,

proporcionando datos oportunos y de calidad en lo relativo a prevención,

atención y control de los problemas informáticos, eléctricos y electrónicos

contribuyendo a la mejora de la calidad de servicio de las diferentes

dependencias de la Municipalidad Provincial de Piura. [ROF – MPP]

Visión

Contar con la confianza y satisfacción de nuestros Usuarios a través de un

sistema que proporcione información y servicios oportunos, seguros, y de

calidad, brindando a sus necesidades respuestas integrales, rápidas y

efectivas a través de un equipo multidisciplinario con calidad humana, técnica

y profesional. [ROF – MPP]

Objetivos

1) Optimizar las necesidades de automatización de procesos.

2) Optimizar las necesidades de información de los usuarios finales.

3) Desarrollar los sistemas informáticos, cuidando que cumplan con la

ergonomía de interfase usuario máquina y los niveles de seguridad requeridos.

4) Implementar los sistemas informáticos conjuntamente con los usuarios.

5) Mejorar el mantenimiento de los sistemas de informáticos, luego de estudiar

los requerimientos de los usuarios.

6) Planificar y administrar los proyectos, que se generan como consecuencia

de la necesidad del desarrollo e implementación de los sistemas informáticos.

7) Mejorar la administración de los recursos humanos y equipos asignados a

esta oficina.

8) Supervisar y emitir normas de uso y estandarización para el correcto

funcionamiento y utilización de los equipos por parte de los usuarios.

9) Brindar el mantenimiento preventivo y correctivo de la infraestructura de red

y de los equipos informáticos.

10) Generar planes de mantenimiento y observar su cumplimiento.

11) Mejorar la administración de la base de datos.




12) Implementar la infraestructura de telecomunicaciones para el óptimo

funcionamiento de los sistemas informáticos. [ROF – MPP]

Metas

1) Facilitar el desarrollo de la Corporación Municipal mediante la

implementación de un Sistema de Comunicaciones y Tecnologías de

Información durante el presente año 2011 con un presupuesto de 30316.93

nuevos soles.

2) Gestionar y resolver el desarrollo de los medios eficientes de comunicación

simultánea entre las Juntas Vecinales y la Corporación Municipal durante el

presente año 2011 con un presupuesto de 9603.50 nuevos soles.

3) Proporcionar las herramientas tecnológicas que permitan una adecuada

comunicación y acceso a la información estadística y difusión de

convocatorias y logros de la Corporación Municipal durante el presente año

2011 con un presupuesto de 1240.50 nuevos soles.

4) Gestionar, programar, promover y resolver la implementación del gobierno

electrónico y adecuar el resultado progresivo de la organización territorial

durante le presente año 2011 con un presupuesto de 396.20 nuevos soles.

5) Diseñar procedimientos que simplifiquen mecanismos administrativos

durante el presente año 2011 con un presupuesto de 18441.61 nuevos soles.

[POI – MPP]

2.6.3. SOPORTE TECNICO:

Descripción del Área de Negocio:

El Área de Negocio es Soporte Técnico, pertenece a la Oficina de Informática

y a su vez esta oficina pertenece a la Gerencia de Tecnologías y Sistemas de

Información, se encarga de dar respaldo a los equipos electrónicos y eléctricos

que se encuentran dentro de la Municipalidad de Piura y en sus Unidades

Orgánicas Externas.

Soporte Técnico, alberga equipos, materiales, herramientas y repuestos para

que los usuarios o trabajadores de la Municipalidad de Piura soliciten servicios

de atención para solucionar problemas de hardware y software de los equipos

electrónicos e informáticos, problemas de equipos eléctricos y problemas de

equipos telefónicos.




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

electrónicos, telefónicos y de redes de la mayoría de equipos que se

encuentran en la municipalidad, se limita a estas actividades y no a

administrar las políticas de seguridad y privacidad de la red de trabajo o

dominio.

Dada la diversidad de incidentes y solicitudes que pueden producirse en ST

resultan difíciles que las atenciones sean de manera oportuna dado que

muchas veces estos problemas pueden ser solucionados de manera fácil por

el usuario o trabajador de la municipalidad de Piura. [EL AUTOR]

2.6.4. SISTEMA DE CONTROL:

¿QUÉ ES UN SISTEMA DE CONTROL?

Según Alvarez Brotons (2004):

Un sistema dinámico puede definirse conceptualmente como un ente que recibe

unas acciones externas o variables de entrada, y cuya respuesta a estas acciones

externas son las denominadas variables de salida.

Las acciones externas al sistema se dividen en dos grupos, variables de control,

que se pueden manipular, y perturbaciones sobre las que no es posible ningún

tipo de control. El gráfico 2 ilustra de un modo conceptual el funcionamiento de un

sistema.

Gráfico N° 002: Esquema general de un sistema

Fuente: Alvarez Brotons




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

sistema de control es un tipo de sistema que se caracteriza por la presencia de

una serie de elementos que permiten influir en el funcionamiento del sistema. La

finalidad de un sistema de control es conseguir, mediante la manipulación de las

variables de control, un dominio sobre las variables de salida, de modo que estas

alcancen unos valores prefijados (consigna).

Un sistema de control ideal debe ser capaz de conseguir su objetivo cumpliendo

los siguientes requisitos:

1. Garantizar la estabilidad y, particularmente, ser robusto frente a

perturbaciones y errores en los modelos.

2. Ser tan eficiente como sea posible, según un criterio preestablecido.

Normalmente este criterio consiste en que la acción de control sobre las

variables de entrada sea realizable, evitando comportamientos bruscos e

irreales.

3. Ser fácilmente implementable y cómodo de operar en tiempo real con

ayuda de un ordenador.

Los elementos básicos que forman parte de un sistema de control y permiten su

manipulación son los siguientes:

- Sensores. Permiten conocer los valores de las variables medidas del sistema.

- Controlador. Utilizando los valores determinados por los sensores y la consigna

impuesta, calcula la acción que debe aplicarse para modificar las variables de

control en base a cierta estrategia.

- Actuador. Es el mecanismo que ejecuta la acción calculada por el controlador y

que modifica las variables de control.

El gráfico 3 ilustra el esquema de funcionamiento de un sistema de control

genérico.




Gráfico N° 003: Esquema general de un sistema de control

Fuente: Alvarez Brotons

2.6.5. APLICACIÓN WEB:

En este inciso se darán a conocer algunos conceptos básicos del contexto de este

trabajo, con la finalidad de situar al problema dentro de un conjunto de

conocimientos. Dentro de estos conocimientos se darán algunos conceptos

acerca de patrones de diseño, dentro de ellos el patrón MVC, sus partes y

características, después se hablará acerca de los frameworks, un breve

comparativo entre estos y los patrones de diseño y finalmente se hace un

pequeño y breve análisis de algunos otros frameworks para web existentes.

Patrones de diseño

Definición e historia

Para comenzar es importante definir lo que un patrón de diseño es, aunque

existen varias definiciones al respecto, un patrón de diseño es una solución de

calidad para un problema recurrente de diseño. Pero no son aplicables

únicamente en el campo computacional, también existen patrones para varias

actividades de la vida cotidiana, aunque con algunas diferencias pero tienen el

mismo propósito que en el ámbito computacional, proporcionar una base para

poder realizar una actividad, mejorando la calidad del producto que esa actividad

de como resultado [Freeman, 2004].




Hay patrones que abarcan las distintas etapas del desarrollo; desde el análisis

hasta el diseño y desde la arquitectura hasta la implementación. En el caso de los

patrones computacionales un software estructurado, modulado posee una mejor

calidad y es más sencillo corregir errores, implementar mejoras y actualizaciones,

ya que un software que posee algún patrón de diseño es más sencillo de

modificar que un software que no posee en absoluto un patrón. Pero ¿Cómo se

debe escoger el patrón adecuado?, esta es una pregunta un poco difícil de

responder ya que la mayoría de las actividades de desarrollo o producción no se

ajustan perfectamente a un patrón definido, por eso es importante llevar acabo un

análisis para poder visualizar cual será el patrón que mejor se ajuste a las

necesidades de desarrollo. En sí "un patrón de diseño puede verse como una

plantilla que puede ser aplicada en muchas situaciones diferentes" [Gamma,

1995], para dar una buena solución.

Los patrones se descubren como una forma indispensable de enfrentarse a la

programación a raíz del libro "Design Patterns - Elements of Reusable Software"

de Erich Gamma, Richard Helm, Ralph Jonson y John Vlissides, a partir de

entonces los patrones de diseño que aparecen en ese libro son conocidos como

los patrones de la pandilla de los cuatro (GoF, gang of four), y comienzan a

desarrollarse variaciones y nuevos patrones, en poco tiempo se multiplicaron por

100 y no se limitaban a patrones de diseño sino que cubrían todo los que se

entiende por ingeniería del software (desde el análisis hasta la implementación)

[Gamma, 1995].

Elementos esenciales

En general un patrón tiene cuatro elementos esenciales:

El nombre del patrón: que se utiliza para describir un problema de diseño, sus

soluciones y sus consecuencias, en una palabra o dos. Este nombre ayuda a que

sea más sencillo de identificarlo, al hablar o escribir de él e incluso puede dar una

idea general o una descripción de dicho patrón.

El problema: describe cuando aplicar el patrón, también puede incluir detalles

específicos que se deben cumplir o problemas un poco más detallados, los cuales

en conjunto engloban el problema central a solucionar.




La solución: describe los elementos que forman el diseño, sus relaciones, sus

responsabilidades y sus colaboraciones. La solución no describe un diseño o

implementación en particular ya que un patrón de diseño puede verse como una

plantilla que se aplica a un problema específico.

Las consecuencias: son los resultados y desventajas de haber aplicado el

patrón. Estas consecuencias implican un impacto en las características del

sistema como: flexibilidad, portabilidad y extensión. Además de que ayudan a

medir el desempeño del sistema.

Clasificación

El grupo de GoF clasificó los patrones en 3 grandes categorías basadas en su

propósito: creacionales, estructurales y de comportamiento [Gamma, 1995].

Creacionales: tratan con las formas de crear instancias de objetos. El objetivo de

estos patrones es de abstraer el proceso de instanciación y ocultar los detalles de

cómo los objetos son creados o inicializados.

Estructurales: Los patrones estructurales describen como las clases y objetos

pueden ser combinados para formar grandes estructuras y proporcionar nuevas

funcionalidades. Estos objetos adicionados pueden ser incluso objetos simples u

objetos compuestos.

Comportamiento: Los patrones de comportamiento ayudan a definir la

comunicación e iteración entre los objetos de un sistema. El propósito de este

patrón es reducir el acoplamiento entre los objetos.

Patrón de diseño Model View Controller (MVC)

Una vez establecidas las bases de los patrones de diseño, se puede ya comenzar

a hablar más del patrón que se utilizó durante este trabajo: el patrón MVC. Estas

son las siglas de Model View Controller, en español Modelo Vista Controlador.

Esto también se ve reflejado en que cada una de estas palabras representa cada

uno de los 3 componentes del patrón MVC. Cada parte juega un rol fundamental

para la completa integración del sistema.




Definición e historia

"El propósito de este patrón es simplificar la implementación de aplicaciones de

acuerdo a las peticiones de los usuarios y los datos a desplegar" [Harrop, 2005].

La definición un poco más formal sería: MVC es un patrón de diseño de software

que separa los datos de una aplicación, la interfaz de usuario, y la lógica de

control en tres componentes distintos de forma que las modificaciones al

componente de la vista, o a cualquier parte del sistema puedan ser hechas con un

mínimo impacto en el componente del modelo de datos o en los otros

componentes del sistema. Este patrón cumple perfectamente el cometido de

modularizar un sistema.

El patrón MVC fue descrito por primera vez en 1979 por Trygve Reenskaug, quién

trabajaba en Smalltalk en los laboratorios de investigación de la Xerox. Este

patrón se ve frecuentemente utilizado en aplicaciones web, donde la vista es la

página HTML y el código provee de datos dinámicos a la página. Las aplicaciones

web complejas continúan siendo más difíciles de diseñar que las aplicaciones

tradicionales de escritorio, el patrón MVC se presenta como una solución para

ayudar a disminuir dicha complejidad.

Componentes

Los 3 principales componentes del patrón MVC son:

Modelo: Representa los datos que el usuario está esperando ver, en algunos

casos el Modelo consiste de Java Beans.

Vista: es la responsable de transformar el modelo para que sea visualizada por el

usuario, ya sea en un archivo de texto normal o en una página web (HTML o JSP)

que el navegador pueda desplegar. En sí el propósito de la vista es convertir los

datos para que al usuario le sean significativos y los pueda interpretar fácilmente.

La vista no debe trabajar directamente con los parámetros del request, debe

delegar esta responsabilidad al controlador.

Controlador: es la parte lógica que es responsable del procesamiento y

comportamiento de acuerdo a las peticiones (requests) del usuario, construyendo




un modelo apropiado, y pasándolo a la vista para su correcta visualización. En el

caso de una aplicación web Java en la mayoría de los casos el controlador es

implementado por un servlet.

Tipos de patrones MVC

Actualmente existen dos tipos de patrón MVC:

Gráfico N° 004: MVC de arquitectura Tipo 1

Fuente: Walls, 2005

Como se muestra en el Gráfico 4 en el Tipo 1 de MVC las páginas JSP están en

el centro de la aplicación, y contienen tanto la lógica de control como la de

presentación. Este tipo de arquitectura funciona de la siguiente manera: el cliente

hace una petición a una página JSP; se construye la lógica de la página,

generalmente en objetos Java o como se les conoce en Inglés Plain Old Java

Objects (POJOs) y se transforma el modelo para ser desplegado una vez más.

Gráfico N° 005: MVC de arquitectura Tipo 2

Fuente: Walls, 2005


Servidor Web/Aplicación

Servidor Web/Aplicación



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

observar que ya existe una clara separación entre el controlador y la vista, ya que

ahora es directamente el controlador quien recibe la petición, prepara el modelo y

lo transforma para que sea desplegado en la vista. Este tipo de arquitectura MVC

es el que se utiliza para aplicaciones más complejas, ya que para una aplicación

sencilla puede utilizarse el Tipo 1. La tecnología JSP no es la única que se puede

emplear para las vistas, existen otro tipo de tecnologías que pueden servir como

vistas.

Frameworks

Un framework es un término utilizado en la computación en general, para referirse

a un conjunto de bibliotecas, utilizadas para implementar la estructura estándar de

una aplicación. Todo esto se realiza con el propósito de promover la reutilización

de código, con el fin de ahorrarle trabajo al desarrollador al no tener que rescribir

ese código para cada nueva aplicación que desee crear. Existen diferentes

frameworks para diferentes propósitos, algunos orientados al desarrollo de

aplicaciones web, otros para desarrollar aplicaciones multiplataforma, para un

sistema operativo o lenguaje de programación en específico, entre otros.

Según Gamma, el framework determina la arquitectura de una aplicación

[Gamma, 1995]. Este es un buen enfoque, ya que el framework se encarga de

definir la estructura general, sus particiones en clases y objetos, las

responsabilidades clave, así como la colaboración entre dichas clases y objetos.

Todos estos parámetros son definidos por el framework, evitando que el usuario

tenga que definirlos y se pueda enfocar en cosas específicas de su aplicación.

"El framework captura las decisiones de diseño que son comunes a su dominio de

aplicación" [Gamma, 1995]. Un framework no sólo promueve la reutilización de

código sino también la reutilización de diseño.

Un framework ayuda a que se desarrolle una aplicación de una manera más

rápida, ya que se no pierde tiempo en algunos detalles de diseño que muchas

veces quitan más tiempo del que tomo construir en sí la lógica de la aplicación.

Además las aplicaciones que se construyen tienen estructuras similares, son más

fáciles de mantener y consistentes para los usuarios. Pero esto tiene como

consecuencia una mínima perdida de libertad en las cuestiones de diseño.




En algunas ocasiones un desarrollador tiene algunas dificultades para diseñar una

aplicación, esto todavía es más difícil para el desarrollador del framework, ya que

desarrollar un framework requiere de muchos cuidados, porque cuando se lanza

uno nuevo, se espera que pueda servir para muchos tipos de aplicaciones pero

con arquitecturas y requerimientos similares. Es decir trata de englobar toda una

gamma de aplicaciones dentro de un solo estándar, lo cual puede ser el éxito o el

fracaso del mismo, por eso se intenta crear frameworks lo más extensibles y

flexibles posibles, para que con algunos cambios mínimos se pueda actualizar o

corregir. Las aplicaciones que se desarrollan a partir de un framework, está ligada

al mismo, por eso las aplicaciones deben de evolucionar y crecer al mismo tiempo

que crece el framework, ya que un cambio en alguna interfaz del mismo

significará un cambio de la aplicación, dependiendo de que tan drástico sea el

cambio.

Relación entre patrones de diseño y frameworks

Los frameworks utilizan un variado número de patrones de diseño, ya que así

logran soportar aplicaciones de más alto nivel y que reutilizan una mayor cantidad

de código, que uno que no utiliza dichos patrones. "Los patrones ayudan a hacer

la arquitectura de los frameworks más adecuada para muchas y diferentes

aplicaciones sin necesidad de rediseño" [Gamma, 1995]. Por esta razón es

importante que se documenten que patrones utiliza el framework para que los que

se encuentren familiarizados con dichos patrones puedan tener una mejor visión y

poder adentrarse en el framework más fácilmente.

Aunque muchas personas cometen el error de confundir a los frameworks con los

patrones de diseño, según los cuatro autores del libro "Design Patterns - Elements

of Reusable" existen 3 diferencias fundamentales entre ellos [Gamma, 1995]:

Los patrones de diseño son más abstractos que los frameworks: el código

del framework se escribe una vez, en cambio cada vez que se requiere un patrón

de diseño se debe de codificar con respecto a la aplicación. Una fortaleza de los

frameworks es que pueden ser escritos en un lenguaje de programación, pueden

ser reutilizados e incluso ejecutados, esto también podría considerarse una

debilidad dependiendo del punto de vista (siempre y cuando no sean

multiplataforma o se encuentre en diferentes versiones por lenguaje de




programación), ya que están enfocados a un sólo lenguaje de programación, en

cambio un patrón de diseño puede ser aplicado a cualquier lenguaje de

programación, pero se tiene que reescribir desde cero.

Los patrones de diseño son elementos arquitectónicos más pequeños que

los frameworks: un solo framework contiene varios patrones de diseño, pero

jamás es al contrario.

Los patrones de diseño son menos especializados que los frameworks:

existen frameworks con un dominio específico, además los patrones son un poco

más generales debido a que pueden ser utilizados en un mayor número de

aplicaciones de varios tipos.

Frameworks para aplicaciones web

Actualmente existen algunos frameworks para desarrollar aplicaciones web, que

es de las ramas más importantes en las que se usan los frameworks. La mayoría

de ellos utilizan el patrón de diseño MVC del cual se habló previamente. Todos los

frameworks tienen características especiales que los hacen únicos para sobresalir

y poder seguir en el mercado, además de poseer las siguientes características

comunes [Johnson, 2003]:

• Utilizan un solo servlet que tiene la función de controlador, para toda la

aplicación o gran parte de ella. Se configura el deployment descriptor "web.xml"

para que todas las URL's tengan que pasar forzosamente por dicho servlet.

Una configuración, generalmente escrita en un archivo XML, en donde se le

indicará al servlet controlador, a través de propiedades, a quien delegar la

responsabilidad de atender la petición entrante. Algunas veces esas propiedades

están indicadas de acuerdo a los URL's y de acuerdo al URL entrante es como se

delega la responsabilidad.

• Las vistas pueden tener nombres claves, sin necesidad que exista una relación

con el nombre del archivo de la vista. El framework se encarga de realizar dicha

conversión para poder obtener el nombre de la vista que se tiene que cargar para

que sea desplegada. La implementación de una vista con un nombre en particular

puede cambiar sin afectar código del controlador.




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

desea realizar una aplicación extremadamente sencilla o si quiere desarrollar una

verdadera aplicación web, que tendrá actualizaciones, correcciones y mejoras a

futuro. Para esto es recomendable que se elija un framework de aplicación web

que utilice el patrón web MVC. Con el fin de que se pueda hacer la separación

entre los 3 elementos principales y pueda aprovechar todas las ventajas que

brinda este patrón de diseño. Para poder aprovechar también las ventajas

adicionales que brinda el framework para la integración con otras herramientas u

otros servicios.

A continuación se enlistan algunos de los frameworks para aplicaciones web más

populares: Struts, WebWork, Maverick y Spring, el framework sobre el cual se

basa esta tesis, será analizado con mayor detalle más adelante en este

documento. Este listado y análisis sencillo de cada uno de estos frameworks se

da con la razón de poder saber cuales son los frameworks contra los que compite

Spring, dentro del mismo ámbito, así como sus características principales,

ventajas y desventajas.

Struts

Struts es uno de los frameworks MVC más utilizados, ya que fue uno de los

pioneros en el campo, fue creado por Craig McClanahan, creador del famoso

motor servlet Tomcat, ambos son distribuidos por Apache. Este framework fue

lanzado a mediados del año 2000, y a partir de esta fecha comenzó a tener

popularidad, y en la actualidad existen algunos componentes extra que se

adaptan a Struts, lo que le da un mayor campo de acción. Struts es open source,

por lo que no requiere licencia para su uso [Johnson, 2003].

Además cumple una de las funcionalidades básicas que se mencionaron acerca

de los frameworks para aplicaciones web, ya que implementa un solo controlador

(ActionServlet) que evalúa las peticiones del usuario mediante un archivo

configurable (struts-config.xml) para poder dirigirlas a un action que procesa el

request. El lenguaje de programación que utiliza es Java, así como Java Beans

como modelo.

Algunas de las ventajas que Struts brinda son: que existe un variado número de

trabajos y proyectos ya hechos lo que brinda un mayor número de ejemplos para




poder tomar un punto de partida y de referencia; otra ventaja es que brinda

librerías de tags para HTML bastante útiles. Entre las desventajas de framework

se puede observar que muchas veces puede ser difícil trabajar con los

ActionForms, además de que el proyecto posiblemente desaparezca en los años

venideros, otra de las desventajas de Struts es que muy ligado con la tecnología

JSP, por lo que muchas veces se dificulta integrarlo con alguna otra tecnología

para las vistas.

Maverick

Este es otro framework MVC open source que existe en el mercado, pero a

diferencia de los demás este no cuenta con sus propias librerías de tags. Sin

embargo cumple con las funcionalidades típicas mencionadas, como el de tener

un solo servlet controlador central como punto de entrada, el cual lleva el nombre

de Dispatcher, que está definido en el Deployment Descriptor de la aplicación web

(web.xml). Maverick cuenta con un archivo XML en el que se guarda toda la

configuración del mismo (maverick.xml). Una característica de Maverick es que

únicamente acepta un solo controlador central y un archivo de configuración por

aplicación web, lo que muchas veces al desarrollar aplicaciones más grandes y

complejas se puede volver confuso y difícil de configurar. [Johnson, 2003]

Maverick es un framework mucho más configurable que Struts, lo que brinda

cierta flexibilidad, también incluye varias clases para poder extender y cambiar el

flujo del trabajo o workflow en Inglés. Maverick es usualmente usado para crear

nuevos controladores que sean capaces de procesar nuevas peticiones. Los

controladores son Java Beans, y el framework pone de manera transparente las

propiedades de los beans.

Una característica interesante de Maverick es el básico y fácil uso de la

funcionalidad del dispatcher. También es multiplataforma ya que ha sido adaptado

para los lenguajes .NET y PHP.

WebWork

Este es un framework más reciente ya que fue lanzado a mediados del año 2002,

una de las personas que ha trabajado en este proyecto fue Rickard Oberg, quien

ha participado en proyectos como JBoss, entre otros. "WebWork, a pesar de su




nombre, no es puramente un framework para aplicaciones web. Adopta un

acercamiento práctico que minimiza la dependencia del código de la aplicación de

los conceptos web."[Johnson, 2003].

El framework WebWork está basado en el patrón de diseño de Comandos o

CommandPattern. Cada acción es un comando, que es creado para manejar un

request, sus propiedades son puestas de manera transparente, ya que cada

acción es un Java Bean.

WebWork cuenta, al igual que Struts y Spring con su propia librería de tags para

JSP, las cuales ayudan a realizar distintas tareas de una manera más ágil, pero

no es la única tecnología para vista que soporta, también incluye soporte para

Velocity.

Una de las ventajas de WebWork es que cuenta con una arquitectura simple y las

clases son fáciles de extender. Pero como todo, tiene sus desventajas, la creación

de una acción (action) por cada request puede llegar a ser algo confuso cuando

no se tiene muchos datos en el request; impone el patrón de diseño Command en

cada interacción del usuario, ya sea bueno o malo utilizarlo en dicha interacción;

es difícil saber de que tipo son las excepciones que se lanzan. Como este

framework es relativamente reciente no existe mucha documentación y ejemplos

al respecto lo que puede resultar a veces frustrante cuando se requiere buscar

algún ejemplo o tutorial que pueda servir.

Spring

Es un framework de aplicación, que a diferencia de otros single-tier como Struts,

Spring propone estructurar toda una aplicación de una manera consistente y

productiva, conjuntando lo mejor de cada uno de los frameworks single-tier para

crear una arquitectura coherente. En sí Spring ha surgido como una solución para

poder disfrutar de los beneficios clave de J2EE, mientras que minimiza la

complejidad encontrada en el código de la aplicación. [Johnson, 2005]

Spring esta basado en la filosofía de que un framework debe proveer una guía

hacia una buena práctica, es decir debe hacer la cosa correcta sencilla de hacer.

Mezclando la correcta combinación de flexibilidad y restricción, la cual es la clave

en el buen diseño de un framework.




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

frameworks web, ya que cuenta con un módulo para poder desarrollar

aplicaciones web de manera sencilla, utilizando el patrón de diseño MVC antes

mencionado. Contando con un controlador central (DispatcherServlet), además de

la capacidad de tener varios controladores secundarios para el procesamiento de

cada una de las peticiones.

También se basa en el diseño de las clases extendiendo o implementando

interfaces, lo cual es un mejor diseño orientado a objetos, ya que promueve la

reutilización de código. Además Spring cuenta con algunos tags para las

diferentes tecnologías para vista que existen. Las cuales tienen funciones

diferentes como vincular formularios, validación, despliegue de información, entre

otras.

Uno de los aspectos clave y ventajas de Spring, es que cuenta con una

arquitectura modularizada, y se pueden utilizar cada uno de estos módulos de

manera independiente. Cada uno esta enfocado en una tarea específica, y

algunos de ellos son para la integración con alguna herramienta o incluso cuenta

con la posibilidad de integrase con los otros frameworks mencionados

anteriormente. Esto con el propósito de proponer la filosofía de "no intentar

reinventar la rueda", la cual quiere decir que si ya existe en el mercado una

herramienta que realice una tarea de manera eficiente en un ámbito o área en

particular se debe conjuntar con Spring para llevar a cabo un mejor desempeño y

poder sacar así un mejor resultado y una aplicación de mayor calidad.

En conclusión cada framework tiene sus ventajas y desventajas, escoger uno es

una decisión del desarrollador, dependiendo de sus necesidades y

requerimientos, del tamaño del proyecto a desarrollar, así como de su experiencia

con tecnologías existentes que se integren fácilmente con el framework que haya

elegido. Esto con el fin de aprovechar algunas tecnologías que estén enfocadas

en un área específica, para que brinde una mejor y más sencilla forma de llevar a

cabo la tarea. Esta fue una de las razones por la cual se decidió incursar dentro

de las características de Spring, y después de un análisis se llego a la conclusión

de que es un buen framework que cumple con la mayoría de las características,

de las cuales otros frameworks escasean.




Una de las cuestiones que ha hecho a Spring evolucionar de manera muy rápida

en tan poco tiempo, es que se han incrementando de una manera increíble el

número de proyectos que utilizan esta herramienta a través del último año. Esto

conlleva a que la cantidad de personas interesadas en este framework aumente,

así como el soporte, el número de foros de opinión y la publicación de un mayor

número de libros y tutoriales.

2.6.6. GESTIÓN DE INCIDENTES:

Según OSIATIS S.A. V2.0:

Visión General

La Gestión de Incidentes tiene como objetivo resolver cualquier incidente que

cause una interrupción en el servicio de la manera más rápida y eficaz posible.

La Gestión de Incidentes no debe confundirse con la Gestión de Problemas, pues

a diferencia de esta última, no se preocupa de encontrar y analizar las causas

subyacentes a un determinado incidente sino exclusivamente a restaurar el

servicio. Sin embargo, es obvio, que existe una fuerte interrelación entre ambas.

Las propiedades y funcionalidades de la Gestión de Incidentes se resumen

sucintamente en el siguiente gráfico:

Gráfico N° 006: Gestión de Incidentes

Fuente: OSIATIS S.A. V2.0




Introducción y Objetivos

Los objetivos principales de la Gestión de Incidentes son:

Detectar cualquiera alteración en los servicios TI (Tecnologías de

Información).

Registrar y clasificar estas alteraciones.

Asignar el personal encargado de restaurar el servicio según se define

en el SLA (Acuerdo de Nivel de Servicio) correspondiente.

Esta actividad requiere un estrecho contacto con los usuarios, por lo que el Centro

de Servicios (Service Desk) debe jugar un papel esencial en el mismo.

El siguiente diagrama resume el proceso de gestión de incidentes:

Gráfico N° 007: Proceso de Gestión de Incidentes (resumen)


Aunque el concepto de incidencia se asocia naturalmente con cualquier

malfuncionamiento de los sistemas de hardware y software según el libro de

Soporte del Servicio de ITIL (Bibliotecas de Infraestructura de las Tecnologías de

Información) un incidente es:

“Cualquier evento que no forma parte de la operación estándar de un servicio y

que causa, o puede causar, una interrupción o una reducción de calidad del

mismo”.

Por lo que casi cualquier llamada al Centro de Servicios puede clasificarse como

un incidente, lo que incluye a las Peticiones de Servicio tales como concesión de




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

servicios se consideren estándar.

Cualquier cambio que requiera una modificación de la infraestructura no se

considera un servicio estándar y requiere el inicio de una Petición de Cambio

(RFC) que debe ser tratada según los principios de la Gestión de Cambios.

Los principales beneficios de una correcta Gestión de Incidentes incluyen:

Mejorar la productividad de los usuarios.

Cumplimiento de los niveles de servicio acordados en el SLA.

Mayor control de los procesos y monitorización del servicio.

Optimización de los recursos disponibles.

Una CMDB (Base de Datos de la Gestión de Configuraciones) más

precisa pues se registran los incidentes en relación con los elementos

de configuración.

Y principalmente: mejora la satisfacción general de clientes y usuarios.

Por otro lado una incorrecta Gestión de Incidentes puede acarrear efectos

adversos tales como:

Reducción de los niveles de servicio.

Se dilapidan valiosos recursos: demasiada gente o gente del nivel

inadecuado trabajando concurrentemente en la resolución del

incidente.

Se pierde valiosa información sobre las causas y efectos de los

incidentes para futuras reestructuraciones y evoluciones.

Se crean clientes y usuarios insatisfechos por la mala y/o lenta gestión

de sus incidentes.

Las principales dificultades a la hora de implementar la Gestión de Incidentes se

resumen en:

No se siguen los procedimientos previstos y se resuelven las

incidencias sin registrarlas o se escalan innecesariamente y/o

omitiendo los protocolos preestablecidos.




No existe un margen operativo que permita gestionar los “picos” de

incidencias por lo que éstas no se registran adecuadamente e impiden

la correcta operación de los protocolos de clasificación y escalado.

No están bien definidos los niveles de calidad de servicio ni los

productos soportados. Lo que puede provocar que se procesen

peticiones que no se incluían en los servicios previamente acordados

con el cliente.

Clasificación del Incidente

Es moneda frecuente que existan múltiples incidencias concurrentes por lo que es

necesario determinar un nivel de prioridad para la resolución de las mismas.

El nivel de prioridad se basa esencialmente en dos parámetros:

Impacto: determina la importancia del incidente dependiendo de cómo

éste afecta a los procesos de negocio y/o del número de usuarios

afectados.

Urgencia: depende del tiempo máximo de demora que acepte el cliente

para la resolución del incidente y/o el nivel de servicio acordado en el SLA.

También se deben tener en cuenta factores auxiliares tales como el tiempo de

resolución esperado y los recursos necesarios: los incidentes “sencillos” se

tramitarán cuanto antes.

Dependiendo de la prioridad se asignarán los recursos necesarios para la

resolución del incidente.

La prioridad del incidente puede cambiar durante su ciclo de vida. Por ejemplo, se

pueden encontrar soluciones temporales que restauren aceptablemente los

niveles de servicio y que permitan retrasar el cierre del incidente sin graves

repercusiones.

Es conveniente establecer un protocolo para determinar, en primera instancia, la

prioridad del incidente. El siguiente diagrama nos muestra un posible “diagrama

de prioridades” en función de la urgencia e impacto del incidente:




Gráfico N° 008: Diagrama de Prioridades Del Incidente


Escalado y Soporte

Es frecuente que el Centro de Servicios no se vea capaz de resolver en primera

instancia un incidente y para ello deba recurrir a un especialista o a algún superior

que pueda tomar decisiones que se escapan de su responsabilidad. A este

proceso se le denomina escalado.

Básicamente hay dos tipos diferentes de escalado:

Escalado funcional: Se requiere el apoyo de un especialista de más alto

nivel para resolver el problema.

Escalado jerárquico: Debemos acudir a un responsable de mayor

autoridad para tomar decisiones que se escapen de las atribuciones

asignadas a ese nivel, como, por ejemplo, asignar más recursos para la

resolución de un incidente específico.

El proceso de escalado puede resumirse gráficamente* como sigue:




* El escalado puede incluir más niveles en grandes organizaciones, o por el contrario, integrar diferentes niveles en el caso de PYMES

Gráfico N° 009: Proceso de Escalado de Incidentes


Proceso

El siguiente diagrama muestra los procesos implicados en la correcta Gestión de

Incidentes:




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


2.6.7. GESTIÓN DE PROBLEMAS:

Según OSIATIS S.A. V2.0:

Visión General

Las funciones principales de la Gestión de Problemas son:

o Investigar las causas subyacentes a toda alteración, real o potencial, del

servicio TI.

o Determinar posibles soluciones a las mismas.

o Proponer las peticiones de cambio (RFC) necesarias para restablecer la

calidad del servicio.

o Realizar Revisiones Post Implementación (PIR) para asegurar que los

cambios han surtido los efectos buscados sin crear problemas de carácter

secundario.

La Gestión de Problemas puede ser:

Reactiva: Analiza los incidentes ocurridos para descubrir su causa y propone

soluciones a los mismos.




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

con el objetivo de prevenir incidentes incluso antes de que estos ocurran.

Las interacciones y funcionalidades de la Gestión de Problemas se resumen

sucintamente en el siguiente gráfico:

Gráfico N° 011: Interacciones y Funcionalidades de la Gestión de Problemas


Introducción y Objetivos

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

exclusivo objetivo el restablecer lo más rápidamente la calidad del servicio y no el

determinar cuáles han sido los orígenes y causas del mismo.




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

impacto en la infraestructura TI es la función de la Gestión de Problemas el

determinar sus causas y encontrar posibles soluciones.

Cabe diferenciar entre:

Problema: causa subyacente, aún no identificada, de una serie de incidentes o un

incidente aislado de importancia significativa.

Error conocido: Un problema se transforma en un error conocido cuando se han

determinado sus causas.

Entre las funciones principales de la Gestión de Problemas figuran:

o Identificar, registrar y clasificar los problemas.

o Dar soporte a la Gestión de Incidentes proporcionando información y

soluciones temporales o parches.

o Analizar y determinar las causas de los problemas y proponer soluciones.

o Elevar RFCs a la Gestión de Cambios para llevar a cabo los cambios

necesarios en la infraestructura TI.

o Realizar un seguimiento post-implementación de todos los cambios para

asegurar su correcto funcionamiento.

o Realizar informes que documenten no sólo los orígenes y soluciones a un

problema sino que también sirvan de soporte a la estructura TI en su

conjunto.

o Analizar tendencias para prevenir incidentes potenciales.

Los principales beneficios de una correcta Gestión de Problemas:

o Un aumento de la calidad general de los servicios TI.

o Se minimiza el número de incidentes.

o Los incidentes se solucionan más rápidamente y, generalmente, en la

primera línea de soporte TI ahorrando recursos e innecesarios escalados.

o La documentación desarrollada es de gran utilidad para la Gestión de la

Capacidad, Disponibilidad y Niveles de Servicio.




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

resumen en:

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

de Problemas. Sin ésta la Gestión de Incidentes no dispondrá de toda la

información necesaria para la rápida solución de los incidentes y la

Gestión de Problemas carecerá de la información necesaria para

determinar, clasificar y resolver los problemas.

o Mantener actualizadas las bases de datos asociadas requiere un

compromiso por parte de todos los agentes implicados que

frecuentemente requiere un seguimiento cercano de los responsables de

la infraestructura TI.

o Aumento de los costes por la contratación de personal especializado,

aunque estos se vean sobradamente compensados por los beneficios

derivados.

Proceso

Las principales actividades de la Gestión de Problemas son:

Control de Problemas: se encarga de registrar y clasificar los problemas para

determinar sus causas y convertirlos en errores conocidos.

Control de Errores: registra los errores conocidos y propone soluciones a los

mismos mediante RFCs que son enviadas a la Gestión de Cambios. Asimismo

efectúa la Revisión Post Implementación de los mismos en estrecha colaboración

con la Gestión de Cambios.

Y cuando la estructura de la organización lo permite, desarrollar una Gestión de

Problemas Proactiva que ayude a detectar problemas incluso antes de que estos

se manifiesten provocando un deterioro en la calidad del servicio.

El siguiente diagrama muestra los procesos implicados en la correcta Gestión de

Problemas:




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


Proceso - Control de Problemas

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

conviertan en Errores Conocidos para que el Control de Errores pueda proponer

las soluciones correspondientes.

Gráfico N° 013: Control de Problemas





El Control de Problemas se compone en esencia de tres fases:

1. Identificación y Registro

Una de las tareas principales de la Gestión de Problemas es identificar los

mismos. Las principales fuentes de información utilizadas son:

o La base de datos de Incidentes: en principio cualquier incidente del que

no se conocen sus causas y que se ha cerrado mediante algún tipo de

solución temporal es potencialmente un problema. Sin embargo, se habrá

de analizar si este incidente es aislado o su impacto en la estructura TI

antes de elevarlo a la categoría de problema.

o Análisis de la infraestructura TI: en colaboración con la Gestión de

Disponibilidad y de Capacidad, la Gestión de Problemas debe analizar los

diferentes procesos y determinar en qué aspectos se debe reforzar los

sistemas y estructuras TI para evitar futuros problemas.

o Deterioro de los Niveles de Servicio: el descenso del rendimiento puede

ser una indicación de la existencia de problemas subyacentes que no se

hayan manifestado de forma explícita como incidentes.

Todas las áreas de la infraestructura TI deben colaborar con la Gestión de

Problemas para identificar problemas reales y potenciales informando a ésta de

cualquier síntoma que pueda ser señal de un deterioro en el servicio TI.

El registro de problemas es, en principio, similar al de los incidentes aunque el

énfasis debe hacerse no en los detalles específicos de los incidentes asociados

sino más bien en su naturaleza y posible impacto.

El registro debe incorporar, entre otra, información sobre:

o Los CIs implicados.

o Causas del problema.

o Síntomas asociados.

o Soluciones temporales.

o Servicios involucrados.

o Niveles de prioridad, urgencia e impacto.




o Estado: activo, error conocido, cerrado.

2. Clasificación y Asignación de Recursos

La clasificación del problema engloba desde las características generales de éste,

tales como si es un problema de hardware o software, que áreas funcionales se

ven afectadas y detalles sobre los diferentes elementos de configuración (CIs)

involucrados en el mismo.

Un factor esencial es la determinación de la prioridad del problema, que al igual

que en el caso de los incidentes, se determina tanto a partir de la urgencia

(demora aceptable para la solución del problema) como de su impacto (grado de

deterioro de la calidad del servicio).

Al igual que en la Gestión de Incidentes la prioridad puede cambiar en el curso del

ciclo de vida del problema, por ejemplo, si se encuentra una solución temporal al

mismo que reduce considerablemente su impacto.

Una vez clasificado y determinada su prioridad se deben de asignar los recursos

necesarios para su solución. Estos recursos deben ser suficientes para asegurar

que los problemas asociados son tratados eficazmente y así minimizar su impacto

en la infraestructura TI.

3. Análisis y Diagnóstico: Error conocido

Los objetivos principales del proceso de análisis son:

o Determinar las causas del problema.

o Proporcionar soluciones temporales a la Gestión de Incidentes para

minimizar el impacto del problema hasta que se implemente los cambios

necesarios que lo resuelvan definitivamente.

Es esencial tener en cuenta que no siempre el origen del problema es un error de

hardware o software. Es moneda frecuente que el problema este causado por:

o Errores de procedimiento.

o Documentación incorrecta.




o Falta de coordinación entre diferentes áreas.

o ...

Es también posible que la causa del problema sea un "bug" bien conocido de

alguno de las aplicaciones utilizadas. Por lo tanto es conveniente establecer

contacto directo con el entorno de desarrollo, en caso de aplicaciones

desarrolladas "en la casa", o investigar en Internet información sobre errores

conocidos aplicables al problema en cuestión.

Una vez determinadas las causas del problema éste se convierte en un Error

Conocido y se remite al Control de Errores para su posterior procesamiento.

Proceso - Control de Errores

Una vez que el Control de Problemas ha determinado las causas de un problema

es responsabilidad del Control de Errores el registro del mismo como error

conocido.

Gráfico N° 014: Control de Errores





Identificación y Registro de errores

El registro de los errores conocidos es de vital importancia para la Gestión de

Incidentes pues debe llevar asociado, siempre que esto sea posible, algún tipo de

solución temporal que permita minimizar el impacto de los incidentes asociados.

Análisis y Solución

Se deben investigar diferentes soluciones para el error evaluando en cada

momento:

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

o Los costes asociados.

o Sus consecuencias sobre los SLAs.

En algunos casos, en los que el impacto del problema puede tener consecuencias

graves en la calidad del servicio, pueden emitirse una RFC de emergencia para su

procesamiento urgente por la Gestión de Cambios.

Una vez determinada la solución óptima al problema y antes de elevar una RFC a

la Gestión de Cambios han de tenerse en cuenta las siguientes consideraciones:

o ¿Es conveniente demorar la solución? Ya sea porque se prevén cambios

significativos en la infraestructura TI a corto plazo o por el escaso impacto

del problema en cuestión.

o ¿Es la solución temporal aportada suficiente para mantener unos niveles

de calidad de servicios aceptable?

o ¿Los beneficios justifican los costes asociados?

Sea cual sea la respuesta, todo la información sobre el error y su solución se

registrará en las bases de datos asociadas. En el caso en el que se considere que

el problema necesita ser solucionado se emitirá una RFC. Será responsabilidad

de la Gestión de Cambios la implementación de los cambios de infraestructura

propuestos.




Revisión Post Implementación y Cierre

Antes de dar el problema por resuelto y cambiar su estado a “cerrado” se debe

analizar el resultado de la implementación de la RFC elevado a la Gestión de

Cambios (PIR).

Si los resultados de esta PIR son los deseados y se pueden cerrar todos los

incidentes relacionados con este problema se considera concluido el proceso y se

emiten los informes correspondientes.

2.6.8. METODOLOGIA DE DESARROLLO:

Estas son más que todo un "conjunto de procedimientos, técnicas y ayudas a la

documentación para el desarrollo de productos software. Una metodología incluye

la tarea construir modelo conceptual de datos. Para realizarlo, define un

procedimiento y da a elegir entre una serie de técnicas" [URJC 2006]. Entre las

más conocidas podemos mencionar las siguientes:

Gráfico N° 015: Metodologías de Desarrollo de Software




Fuente: Universidad Rey Juan Carlos (2006)

Pero dentro de esto se encuentra uno de los puntos clave que como futuros

ingenieros de sistemas estamos en la obligación de saberlo y poseerlo como uno

de nuestra cultura general profesional, se trata de lo que es un Proceso de

Desarrollo de Software. Pero que objetivo tiene un Proceso de Desarrollo de

Software, básicamente su objetivo se direcciona hacia "subir la calidad del

software (en todas las fases por las que pasa) a través de un mayor control sobre

el proceso. Es labor del proceso de desarrollo definir quién debe hacer Qué,

cuándo y cómo debe hacerlo" [Patricio Letelier 2000].

En esta parte de la investigación realizada hablaremos sobre algunas de las

metodologías de desarrollo de software existentes en la actualidad, entre las

principales tenemos a:

RUP (Rational Unified Process).

XP (Extreme Programming).

FDD, etc.

RUP (Rational Unified Process):

Fue el mismo Barry Boehm, autor del modelo de espiral del proceso de software,

quien en su artículo [Boehm, 1995] describe tres hitos críticos a ser utilizados en

cualquier proyecto de forma de poder planificar y controlar el progreso del mismo,

dando visibilidad a los stakeholders. Estos hitos están relacionados con las etapas

de avance que se van dando a lo largo de un proyecto de acuerdo al pasaje que

ocurre de las actividades de ingeniería (que componen los espirales del modelo

en espiral) a las actividades de producción (que componen la construcción en

cascada del software). Su impacto en la industria del software ha sido tan

importante que uno de los procesos más utilizados en la actualidad, el [RUP,

2002], los incorpora. Estos hitos son:

• Objetivos del Ciclo de Vida

• Arquitectura del Ciclo de Vida

• Capacidad Operacional Inicial




RUP es uno de los procesos más generales del los existentes actualmente, ya

que en realidad esta pensado para adaptarse a cualquier proyecto, y no tan solo

de software.

Un proyecto realizado siguiendo RUP se divide en cuatro fases:

1. Intercepción (puesta en marcha).

2. Elaboración (definición, análisis, diseño).

3. Construcción (implementación).

4. Transición (fin del proyecto y puesta en producción).

Se tiene que tener en cuenta que "en cada fase se ejecutarán una o varias

iteraciones, las cuales están debidamente explicadas en el Proceso Iterativo e

Incremental. Pero a que se refiere con el proceso iterativo e incremental, se

refiere más que tono a la evolución de prototipos ejecutables que se muestran a

los usuarios y clientes [Rational Software Company 2001].




Gráfico N° 016: Dos Dimensiones de RUP

Fuente: Introducción a Rational Unified Process (RUP) - Patricio Letelier 2000

RUP define nueve actividades a realizar en cada fase del proyecto:

1. Modelado del negocio.

2. Análisis de requisitos.

3. Análisis y diseño.

4. Implementación.

5. Test.

6. Distribución.

7. Gestión de configuración y cambios

8. Gestión del proyecto.

9. Gestión del entorno.

Pero por otra parte también posee elementos o Workflows de apoyo entre los

cuales tenemos [Patricio Letelier 2000]:

Environment (Entorno).

Project Management (Gestión del Proyecto).

Configuration & Change Management (Gestión de Configuración y

Cambios).

Artefactos:

Resultado parcial o final que es producido y usado durante el proyecto.

Son las entradas y salidas de las actividades.

Un artefacto puede ser un documento, un modelo o un elemento de

modelo.




Conjuntos de Artefactos.

o Business Modeling Set.

o Requirements Set.

o Analysis & Design Set.

o Implementation Set.

o Test Set.

o Deployment Set.

o Project Management Set.

o Configuration & Change Management Set.

o Environment Set.

Características Esenciales de RUP:

Proceso Dirigido por los Casos de Uso

Proceso Iterativo e Incremental

Proceso Centrado en la Arquitectura

Proceso Iterativo e Incremental:

El ciclo de vida iterativo se basa en la evolución de prototipos ejecutables

que se muestran a los usuarios y clientes.

En el ciclo de vida iterativo a cada iteración se reproduce el ciclo de vida

en cascada a menor escala.

Los objetivos de una iteración se establecen en función de la evaluación

de las iteraciones precedentes.

Las actividades se encadenan en una mini-cascada con un alcance

limitado por los objetivos de la iteración.

Gráfico N° 017: Proceso Iterativo Incremental




Fuente: Introducción a Rational Unified Process (RUP) - Patricio Letelier 2000

Puntos Claves:

Pesado.

Dividido en cuatro fases.

La fase se dividen en iteraciones.

El discurrir del proyecto se define en Workfíows. » Los artefactos son el

objetivo de cada actividad.

Se basa en roles.

UML.

Muy organizativo.

Mucha documentación.

XP (Extreme Programming) ó Programación Extrema:

Es la primera metodología ágil y es la que le dio conciencia al movimiento actual

de metodologías ágiles. De la mano de Kent Beck, XP ha conformado un extenso

grupo de seguidores en todo el mundo, disparando una gran cantidad de libros a

los que dio comienzo el mismo Beck en [Beck, 2000]. Inclusive Addison-Wesley

ha creado una serie de libros denominada The XP Series. Fue la misma gente del

proyecto C3 (Sistema Exhaustivo de Compensaciones de Chrysler) la que produjo

también otro de los libros importantes de XP [Jeffries, 2001] en el que se bajaban

los conceptos de Beck a la puesta en práctica en un proyecto.

La imagen mental de Beck al crear XP [Beck, 2000] era la de perillas en un tablero

de control. Cada perilla representaba una práctica que de su experiencia sabía

que trabajaba bien. Entonces, Beck decidió girar todas las perillas al máximo para

ver que ocurría. Así fue como dio inicio a XP.

En la programación extrema, cada contribuidor al proyecto es una parte integral

del "equipo entero". El equipo forma alrededor de un representante del negocio

llamado "el cliente", que se sienta con el equipo y trabaja con ellos diariamente.

Diseño simple.

Los equipos de XP construyen software a un diseño simple. Comienzan simple, y

con la prueba del programador y la mejora del diseño, la guardan de esa manera.

Un equipo de XP mantiene el diseño satisfecho exactamente para la funcionalidad




actual del sistema. No hay movimiento perdido, y el software es siempre listo para

lo siguiente.

El diseño en XP no es una cosa de una sola vez, es una cosa de todo el tiempo.

En donde los equipos se deben acostumbrar a sesiones rápidas de diseño.

Integración continua.

Los equipos de programación extrema mantienen el sistema integrado

completamente siempre. Los equipos de XP construyen épocas múltiples por día.

(Un equipo de XP de cuarenta personas construye por lo menos ocho o diez

veces por día). La integración infrecuente conduce a los problemas senos en un

proyecto del software. Se tiene que tener en cuenta que la integración es crítica al

momento del envío de código, ya que el equipo no participa en ello, y se delega a

menudo a la gente que no está al corriente del sistema entero.

Codificación de estándar.

Los equipos de XP siguen un estándar común de la codificación, de modo que

todo el código en el sistema mire como si fuera escrito por un solo programador.

Lo importante es que todo el código parezca familiar.

Mientras que el RUP intenta reducir la complejidad del software por medio de

estructura y la preparación de las tareas pendientes en función de los objetivos de

la fase y actividad actual, XP, como toda metodología ágil, lo intenta por medio de

un trabajo orientado directamente al objetivo, basado en las relaciones

interpersonales y la velocidad de reacción.

XP intenta minimizar el riesgo de fallo del proceso por medio de la disposición

permanente de un representante competente del cliente a disposición del equipo

de desarrollo. Este representante debería estar en condiciones ue contestar

rápida y correctamente a cualquier pregunta del equipo de desarrollo de forma

que no se retrase la tomar de decisiones, de ahí lo de competente.

La codificación del software en XP se produce siempre en parejas (dos

programadores, un ordenador), por lo que se espera que la calidad del mismo

suba en el mismo momento de escribirlo. Al contrario que muchos otros métodos,

el código pertenece al equipo en completo, no a un programador o pareja, de

forma que cada programador puede cambiar cualquier parte del código en




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

orientadas al rendimiento para el final. Las parejas no se mantienen para todo el

proyecto si no que rotan cíclicamente a lo largo del mismo, tanto en cuanto a los

componentes de la misma como en las partes del software que desarrollan, así

cada componente del equipo aprende como trabaja el resto. El objetivo ideal seria

que cada componente del equipo trabaje al menos una vez con cada uno de los

demás integrantes y con cada componente software, de forma que el

conocimiento de la aplicación completa lo posea el equipo entero y no unos pocos

miembros.

En XP se programará solo la funcionalidad que es requerida. Es decir, una gran

flexibilidad y capacidad de configuración solo será implementada cuando sea

necesaria para cumplir los requerimientos. Se sigue un diseño evolutivo con la

siguiente premisa: conseguir la funcionalidad deseada de la forma más sencilla

posible. Este diseño evolutivo hace que no se le de apenas importancia al análisis

como fase independiente, puesto que se trabaja exclusivamente en función de las

necesidades del momento.

Puntos Claves:

Ligero.

Cercano al desarrollo.

Se basa en UserStories.

Fuerte comunicación con el cliente.

El código fuente pertenece a todos.

Programación por parejas.

Tests como base de la funcionalidad.

Solo el mínimo de organización.

Pobre en cuanto a documentación.

FDD (Desarrollo Manejado Por Rasgos):

Peter Coad es considerado uno de los referentes más importantes dentro de la

ingeniería de software. Coad ha sido uno de los principales pioneros detrás del

movimiento de la orientación a objetos y empezó a trabajar con Ed Yourdon (uno

de los creadores del Análisis Estructurado) a principios de los noventa, cuando

este último pidió ayuda a alguien de la comunidad de objetos para desarrollar una

nueva metodología, basada en el paradigma de OO. Posteriormente, Coad junto




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

desarrollada alrededor del año 1998 que presenta las características de un

proceso ágil [Coad, 1998]. La misma derivó del trabajo de Coad sobre las Feature

Lists (Listas de Funcionalidades).

FDD se estructura alrededor de la definición de features que representan la

funcionalidad que debe contener el sistema, y tienen un alcance lo

suficientemente corto como para ser implementadas en un par de semanas. FDD

posee también una jerarquía de features, siendo el eslabón superior el de feature

set que agrupa un conjunto de features relacionadas con aspectos en común del

negocio. Por último, establece el major feature set como el más alto nivel de

agrupación de funcionalidad que abarca diferentes feature sets que contribuyen a

proveer valor al cliente en relación a un subdominio dentro del dominio completo

de la aplicación. Una de las ventajas de centrarse en las features del software es

el poder formar un vocabulario común que fomente que los desarrolladores

tengan un diálogo fluido con los clientes, desarrollando entre ambos un modelo

común del negocio. Este tema será tratado más adelante en relación al enfoque

de las metodologías ágiles en los productos entregados.

El FDD tiene cinco procesos. Los primeros tres se hacen al principio del proyecto

y son:

a) Desarrollar un Modelo Global.

b) Construir una Lista de los Rasgos.

c) Planear por Rasgo.

Los últimos dos se hacen en cada iteración. Cada proceso se divide en tareas y

se da un criterio de comprobación.

d) Diseñar por Rasgo.

e) Construir por Rasgo.

OBJETIVOS

Sintetizar un programa conforme a los rasgos requeridos.

En un desarrollo en términos de FOP (Programación Orientada a rasgos),

los objetos se organizan en módulos o capas conforme a rasgos.

FDD esta pensado para proyectos con tiempo de desarrollo relativamente cortos

(menos de un año). Se basa en un proceso iterativo con iteraciones cortas (2




semanas aproximadamente) que producen un software funcional que el cliente y

la dirección de la empresa pueden ver y monitor izar.

Un proyecto que sigue FDD se divide en 5 fases:

1. Desarrollo de un modelo general.

2. Construcción de la lista de funcionalidades o rasgos.

3. Plan en base a las funcionalidades o rasgos a implementar.

4. Diseñar en base a las funcionalidades o rasgos.

5. Implementar en base a las funcionalidades o rasgos.

Gráfico N° 018: Proceso FDD

Fuente: COAD, 1998

Las primeras tres fases ocupan gran parte del tiempo en las primeras iteraciones,

siendo las dos últimas las que absorben la mayor parte del tiempo según va

avanzando el proyecto, limitándose las primeras a un proceso de refinamiento.

El trabajo (tanto de modelado como de desarrollo) se realiza en grupo, aunque

siempre habrá un responsable último (arquitecto jefe o jefe de programadores en

función de la fase en que nos encontremos), con mayor experiencia, que tendrá la

última palabra en caso de no llegar a un acuerdo. Al hacerlo en grupo se consigue

que todos formen parte del proyecto y que los menos inexpertos aprendan de las

discusiones de los mas experimentados, y al tener un responsable último, se

asignan las responsabilidades que todas las empresas exigen.

FDD también define métricas para seguir el proceso de desarrollo de la aplicación,

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




de para conocer el estado actual del desarrollo, a realizar mejores estimaciones

en proyectos futuros.

Puntos Claves:

Ligero.

A medio camino entre el desarrollo y la organización.

Existe una jerarquía dentro del equipo.

El código fuente tiene propietario.

Los equipos varían en fúnción de la funcionalidad a implementar.

El conocimiento de la aplicación se reparte a través de trabajo en equipo y

revisiones.

Documentación aceptable.




2.7.MARCO CONCEPTUAL:

Título

“Sistema de Control para las Tareas del Servicio de Soporte Técnico de la Oficina de

Informática de la Municipalidad Provincial de Piura mediante una Aplicación Web”

Aplicación Web.

"La World Wide Web é Internet han introducido a la población en general en el

mundo de la informática. Compramos fondos de inversión colectivos y acciones,

descargamos música, vemos películas, obtenemos asesoramiento médico,

hacemos gestiones de diversos tipos como personales y corporativas…" [IEEE]

con respecto a la herramienta a producir en el presente proyecto.

Sistema de Control para las Tareas del Servicio de Soporte Técnico de la

Oficina de Informática de la Municipalidad Provincial de Piura.

"Los sistemas de control y supervisión son una clase importante de sistemas de

tiempo real. Verifican los sensores que proveen información del entorno del

sistema y toman acciones…" [SOMMERVILLE, 2002] con respecto al control que

asumiría soporte técnico en sus tareas de mantenimiento en la Municipalidad

Provincial de Piura.

Metodología Rational Unified Process (RUP).

"Conjunto de actividades necesarias para transformar los requisitos de un usuario

en un sistema software. Además es un marco de trabajo genérico que puede

especializarse para una gran variedad de sistemas software, para diferentes áreas

de aplicación, diferentes tipos de organizaciones, diferentes niveles de aptitud y

diferentes tamaños de proyecto" [Jacobson & Booch & Rumbaugh 2000].




2.8.HIPOTESIS:

La implementación de una Aplicación Web influye en el sistema de control de las tareas

del servicio de Soporte Técnico de la Oficina de Informática de la Municipalidad Provincial

de Piura.

2.9.VARIABLES E INDICADORES IMPLICADOS EN EL PROYECTO:

Variable Independiente:

Aplicación Web:

El presente proyecto desarrollará una Aplicación Web que va permitir al Área

de Soporte Técnico tener un mejor control y seguimiento de los procesos que

se siguen para la solución de los problemas que se presentan en las distintas

oficinas de la Municipalidad de Piura. Esta mejora del Sistema de Información

actual que presenta el Área de Soporte Técnico permitirá optimizar dichos

procesos, siendo más eficientes y reduciendo el tiempo de las atenciones.

Variable Dependiente:

Sistema de Control para las Tareas del Servicio:

El actual desarrollo de las tareas del servicio de Soporte Técnico para el

mantenimiento, reparación y respaldo de los diversos equipos informáticos y

electrónicos, se da de manera informal y sin documentar muchas de las

atenciones de los problemas e incidentes que ocurren en las diferentes

oficinas de la Municipalidad de Piura, es por estos motivos que la presente

Aplicación Web a desarrollar permitirá optimizar el desarrollo y ejecución de

dichas operaciones técnicas a través de un mejor control, administración y

organización.

Variable Interviniente:

Proceso Unificado de Racional (RUP):

Es una metodología del proceso de ingeniería de software que proporciona un

enfoque disciplinado para asignar tareas y responsabilidades dentro de una

organización del desarrollo y será aplicada en la presente tesis.




Indicadores:

Nro IndicadorDefinición Con-

ceptualDefinición Operacional

Unidad de Medida

Técnica de Medición

Instrumentos de Medición

I01 Tiempo para lle-gar a atender una Solicitud de Servi-cio.

Tiempo que el técnico demora en llegar a una solicitud de ser-vicio.

Ss - Tiempo de Asisten-cia a la Solicitud de Ser-vicio. S = Tiempo de traslado entre servicio.n = Cantidad total de So-licitudes de Servicio

Minutos Observación Guía de Ob-servación N° 01 (Cronó-

metro) Anexo

I02 Tiempo para solu-cionar una solici-tud de Servicio.

Es el tiempo que el técnico demo-ra en solucionar una solicitud de servicio.

Ts = Tiempo de solución de Solicitudes de Servi-cio. T = Tiempo para realizar una Solución de Servicio.n = Cantidad total de So-licitudes de Servicio


metro) Anexo

I03 Cumplimiento de un Técnico en cuanto a los Ser-vicios Asignados.

Porcentaje de solicitudes de servicios atendi-das por técnico.

SM= Porcentaje de cum-plimiento de un técnico de sus servicios asigna-dos. M = Solicitudes atendi-das. T = Total de Solicitudes de Servicios Asignados.

Porcentaje Observación Guía de Ob-servación N°

03 Anexo

I04 Porcentaje de Servicio no aten-didos.

Porcentaje de Solicitudes reali-zadas por el usuario que no han sido atendi-das por diversos motivos.

Sn = Porcentaje de Servicios no atendidos. Sna = Servicio no atendi-do. N = Total de Solicitudes.

Porcentaje Observación Guía de Ob-servación N°

04 Anexo

Cuadro N° 002: Indicadores de la Variable Dependiente

Fuente: El Autor






Unidad de Medida



I05 Solicitudes de Servicio Asigna-das por Técnico.

Es el número de servicios asigna-dos a cada téc-nico.

St =servicio asignado por técnico. t =orden de servicio asig-nada al técnico. Ss =Solicitudes de Servi-cio.

Unidad Observación Guía de Ob-servación N°

05 Anexo

I06 Solicitudes de Servicio por ofici-na.

Es el número de servicios solici-tados por ofici-na.

SS = Solicitudes de Servicios de Oficina.Si = Solicitudes de servi-cios de la Oficina especi-ficada.


06 Anexo

I07 Número de equi-pos internados.

Son los equipos que provienen de otra oficina y que tienen que ser atendidos en Soporte.

El=Número de Equipos de otro local. Gi=Guías de Salida.


07 Anexo

I08 Tiempo de bús-queda de historial técnico.

Tiempo para buscar la infor-mación de man-tenimiento (bitá-cora) de un equipo.

TB = Tiempo de Búsque-da T = Tiempo de Búsqueda de historial Técnico.n = Cantidad total de búsquedas


metro) Anexo

I09 Tiempo de Emi-sión (entrega) de Documentos (Re-portes, Guías de salida y/o Fichas Técnicas).

Tiempo transcu-rrido para la en-trega de la do-cumentación so-licitada.

TED = Tiempo de Emisión. t = Tiempo de Entrega por documento.n = Cantidad total de do-cumentación


metro) Anexo

Cuadro N° 002: Indicadores de la Variable Dependiente (continuación)

Fuente: El Autor






Unidad de Medida



I10 Nivel de satisfac-ción del usuario.

Medimos la con-formidad de los usuarios con la herramienta a desarrollar.

NS = Nivel de Satisfac-ción.Us = Usuario Satisfecho.n = Cantidad total de usuarios

Porcentaje Encuesta Cuestionario de Encuesta

N° 01Anexo

Cuadro N° 002: Indicadores de la Variable Dependiente (continuación)

Fuente: El Autor




________________________________________________________

CAPITULO III:

METODOLOGIA

________________________________________________________




3. METODOLOGIA:

3.1.TIPO DE ESTUDIO:

Los propósitos básicos del paradigma cuantitativo en la investigación socio-

educativa consisten en realizar mediciones y predicciones exactas del

comportamiento regular de grupos sociales. "Los positivistas buscan los hechos o

causas de los fenómenos sociales con independencia de los estados subjetivos

de los individuos" [Taylor y Bogdan, 1986], es decir buscan la objetividad. La

búsqueda principal consiste en explicar las causas de los fenómenos, confrontar

teoría y praxis, detectar discrepancias, analizar estadísticamente, establecer

conexiones y generalizaciones (abstracciones).

[Sant'Anna, y Smith, 1983] sugieren que el paradigma cuantitativo se nutre de los

supuestos filosóficos del realismo, racionalismo, positivismo y de la epistemología

científica de Comte y el Círculo de Viena.

“La Investigación Aplicada es aquel tipo de estudio científico orientado a resolver

problemas de la vida cotidiana o a controlar situaciones prácticas.” [José Padrón,

2006]

La presente tesis está basada en el paradigma cuantitativo porque me va permitir

recoger, procesar y analizar datos numéricos sobre variables determinadas

mediante métodos estadísticos.

La hipótesis formulada en esta investigación se traduce en variables, las que a su

vez se traducen en indicadores cuantificables.

Esta es una investigación aplicada porque se busca dar solución a un problema a

través del desarrollo de una herramienta tecnológica.




3.2.DISEÑO DEL ESTUDIO:

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

experimental con Pre-test y Post-test y grupos intactos.

[Hernandez, Fernández, Baptista – 2003] definen que en este tipo de diseño se

“...manipulan deliberadamente, al menos, una variable independiente para

observar su efecto y relación con una o más variables dependientes, sólo se

diferencian de los experimentos verdaderos en el grado de seguridad o

confiabilidad que pueda tenerse sobre la equivalencia inicial de los grupos”.

O1 – X – O2

O1 : Pre-test o Prueba Inicial

O2 : Post-test o Prueba Final

X : Variable Interviniente

Este diseño utiliza dos grupos: el experimental (que recibe el tratamiento) y el

grupo control (que no recibe el tratamiento). Los grupos son comparados en lapos

prueba para analizar si el tratamiento experimental tuvo un efecto sobre la

variable dependiente (O1 con O2). No se asignan los grupos ni por azar ni por

emparejamiento.

3.3.POBLACIÓN Y MUESTRA:

Población

La población tomada para el desarrollo de la presente tesis es el personal

encargado del servicio que brinda el área de Soporte Técnico a los

diferentes equipos de las dependencias de la Municipalidad de Piura.

Muestra

La muestra tomada para el desarrollo de la presente tesis es el personal

que labora en el área de Soporte Técnico de la Oficina de Informática de la

Municipalidad de Piura. La cantidad de la muestra serán las 5 personas

encargadas del servicio que brinda la dependencia en mención, por lo

tanto no es necesario aplicar una fórmula para obtener la muestra.




3.4.MÉTODOS DE INVESTIGACIÓN:

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

entrada o pre-test.

Posteriormente se aplicará una prueba de salida o post test con una medición de

los efectos que ha tenido la variable independiente.

Y por último se hará una comparación entre la información que se tuvo al inicio y

al final.

3.5.TÉCNICAS E INSTRUMENTOS DE RECOLECCIÓN DE DATOS:

Técnicas

Las técnicas de recolección de datos que se emplearán son: encuestas y

observación. Estas nos ayudarán a recoger información primordial para

desarrollar el presente trabajo de investigación o tesis que tiene por título:

“Sistema de Control para las Tareas del Servicio de Soporte Técnico de la

Oficina de Informática de la Municipalidad Provincial de Piura”.

Instrumentos

Los instrumentos de recolección de datos para el desarrollo de la presente

investigación o proyecto de tesis son: las guías de observación y

cuestionarios de encuestas.

A continuación en el siguiente cuadro se presentan los indicadores con sus

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




Nº Indicadores Técnicas Instrumentos

1Tiempo para llegar a atender una Solicitud de Servicio.

Observación Guía de Observación

2Tiempo para solucionar una solici-tud de Servicio.


3Cumplimiento de un Técnico en cuanto a los Servicios Asignados.


4Porcentaje de Servicio no atendi-dos.


5Solicitudes de Servicio Asignadas por Técnico.


6 Solicitudes de Servicio por oficina. Observación Guía de Observación

7 Número de equipos internados. Observación Guía de Observación

8Tiempo de búsqueda de historial técnico.


9Tiempo de Emisión (entrega) de Documentos (Reportes, Guías de salida y/o Fichas Técnicas).


10 Nivel de satisfacción del usuario. Encuesta Cuestionario de Encuesta

Cuadro N° 003: Indicadores, Técnicas e Instrumentos de Recolección de Datos

Fuente: El Autor

3.6.MÉTODOS DE ANÁLISIS DE DATOS:

Para analizar los datos recolectados se estudiarán los resultados organizados en

cuadros estadísticos para determinar las principales tendencias de la información

utilizando los porcentajes de los cuadros o de las aplicaciones estadísticas. Para

el análisis de datos se va a utilizar el software Microsoft Excel 2007.




________________________________________________________

CAPITULO IV:

ADMINISTRACION

________________________________________________________




4. ADMINISTRACION:

4.1.CRONOGRAMA DE ACTIVIDADES:

Para realizar el Cronograma de Gantt de las actividades a desarrollar en la

presente tesis hemos utilizado el software Microsoft Office Project 2007, el cual es

una herramienta que nos ayuda a realizar cronogramas de actividades para

diferentes tipos de proyecto. Este software ayuda a optimizar la distribución del

tiempo. A continuación en el cuadro Nº 4 se observa el cronograma del proyecto:

Cuadro N° 004: Cronograma de Actividades de la Tesis

Fuente: El Autor




4.2.PRESUPUESTO:

Recursos Cantidad C/UPrecio Total

Bienes

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

Servicios

Luz Eléctrica ___ ___ S/. 200.00

Internet 200 horas S/. 1.00 S/. 200.00

Teléfono ___ ___ 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

RemuneracionesPersonal de apoyo ___ ___ S/. 400.00

Otros ___ ___ S/. 200.00

Total S/. 1,895.00

Cuadro N° 005: Presupuesto de la Tesis

Fuente: El Autor

4.3.FINANCIAMENTO:

El presente proyecto de investigación es autofinanciado por el autor ya que

la Municipalidad Provincial de Piura no financia este tipo de investigaciones




hechas por alumnos universitarios.

________________________________________________________

CAPITULO V:

REFERENCIAS BIBLIOGRAFICAS

________________________________________________________





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

Universidad Politécnica de Catalunya.

[Beck, 2000] Beck, Kent, Extreme Programming Explained, Addison-Wesley The XP

Series.

[Boehm, noviembre 1995] Boehm, Barry W., Anchoring the Software Process, USC.

[Booch, 2000] Booch, Grady, Ivar Jacobson, James Rumbaugh, The Unified Modeling

Language User Guide, Addison-Wesley Object Technology Series.

Castro Arévalo, Manuel & Zapata Navarro, Jhon (Piura – 2009), “Sistema Informático

de Registro de Mantenimiento de Equipos de Cómputo del Área de Soporte del Centro de

Informática y Telecomunicaciones de la Universidad Nacional de Piura”. Universidad

César Vallejo – Filial Piura.

[Coad, 1998] Coad, Peter, Eric Lefebvre, Jeff De Luca, Feature-Driven Development,

Disponible en: http://www.cs.jhu.edu/~scott/oos/software/togetherj/help/Users-

Guide/Feature_Driven_Development.htm

Espinoza Saavedra, Daniel (Valparaíso, Chile – 2004), “Estudio del Sistema de

Monitoreo y Registro de Inventarios de Compras y su Integración Estratégica mediante el

Control de Gestión”. Universidad de Valparaíso.

[Freeman Elisabeth, 2004] et. al. Head First Design Patterns. California: O'Reilly Media.

[Gamma Erich, 1995] et. al. Design Patterns.Elements of Reusable Object-Oriented

Software. Boston: Addison-Wesley.

[Harrop Rob, 2005] et al. Pro Spring. Nueva York: Apress.

[Hernandez Sampieri, Roberto; Fernández Collado, Carlos; Baptista Lucio, Pilar;

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





[Johnson Rob, 2003] Expert One-on-One J2EE Design and Development. Indianapolis:

Wrox Press.

[Johnson Rob, mayo 2005] Introduction to the Spring Framework. [En línea].

Disponible en: www.theserverside.com/articles/article.tss?l=SpringFramework

[José Padrón G.] Bases del concepto de "Investigación Aplicada"[en línea].

Disponible en: http://padron.entretemas.com/InvAplicada/index.htm

Metodologías de Desarrollo de Software (España – 2006), artículo publicado por la

Universidad Rey Juan Carlos.

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

Disponible en: http://itil.osiatis.es/Curso_ITIL/

[P. Letelier, Zaragoza, octubre 2000] Metodologías de Producción de Software.

Pesántez Huerta, Álvaro Eduardo (Guayaquil, Ecuador – 2007), “Elaboración de un

Plan de Mantenimiento Predictivo y Preventivo en Función de la Criticidad de los Equipos

del Proceso Productivo de una Empresa Empacadora de Camarón”. Escuela Superior

Politécnica del Litoral.

Plan Estratégico Institucional (2009 – 2014), Municipalidad Provincial Piura (PEI-MPP)

Plan Operativo Institucional (2011), Municipalidad Provincial de Piura (POI–MPP)

Reglamento de Organización y Funciones, Municipalidad Provincial Piura (ROF-MPP)

[RUP, 2002] Rational Unified Process® Version 2002.05.00, Copyright © Rational

Software Corporation, All Rights Reserved.

Salcedo Untiveros, Richard Orlando (Piura – 2007), “Análisis, Diseño y Desarrollo del

Módulo Web para la Gestión y Control de Inventario de Bienes de la Oficina de Control

Patrimonial de la Dirección Regional de Salud Piura”. Universidad Nacional de Piura.


http://padron.entretemas.com/InvAplicada/index.htm




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

ação a obser-vação participante. Educação e realidade.

Santillán Pinedo, Karla & Tornero Mendoza, Ludver (Trujillo – 2001), “Sistema de

Información de Control de Almacén de la Dirección Regional de Educación de La Libertad

– DRELL”. Universidad César Vallejo.

[Smith, J., 1983] Quantitative versus qualitative research: An attempt to clarify the issue.

Educational Researcher.

[Sommerville, Ian, 2002] Ingeniería del Software.

[Taylor, S. J. y Bogdan, R., 1986] Introducción a los métodos cualitativos de

investigación. La búsqueda de significados. Buenos Aires: Editorial Paidós.

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

un sistema de administración de incidentes en atención al cliente para una empresa de

telecomunicaciones”. Pontificia Universidad Católica del Perú.

[Walls Craig, 2005] et. al. Spring in Action. Greenwich: Manning Publications.




________________________________________________________

CAPITULO VI:

ANEXOS

________________________________________________________




ANEXO 01

Guía de Observación Nº 01

Tiempo para llegar a atender una solicitud de servicio.

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

Fecha de inicio de observación: __/ __/ ___Hora de Inicio: _________

NúmeroHora de

InicioHora de Llegada

Tiempo Total (Min)

Tiempo Promedio

Hora Final: _________Fecha de fin de observación: __/ __/ _____

Observaciones: _____________________________________________________________________________________________________________________________________________________________________________________________

Observador

Revisado Procesado Archivado




ANEXO 02


Tiempo para solucionar una solicitud de servicio.

Instrucciones: En los días de observación se tomarán la fecha y hora de inicio de la atención a la solicitud de servicio por parte del técnico y la hora de la finalización de dicha atención.


Número Hora de Inicio Hora de FinalizaciónTiempo

Total (Min)

Tiempo Promedio


Observaciones: _____________________________________________________________________________________________________________________________________________________________________________________________

Observador





ANEXO 03


Cumplimiento de un técnico en cuanto a los servicios asignados.

Instrucciones: En los días de observación se tomarán las cantidades de los

servicios atendidos por un técnico y los que le han sido asignados a atender.


TécnicoCantidad

SolicitudesAsignadas

Cantidad Solicitudes Atendidas

PorcentajeCumplimiento


Observaciones: _____________________________________________________________________________________________________________________________________________________________________________________________

Observador





ANEXO 04


Porcentajes de Servicios no Atendidos.

Instrucciones: En los días de observación se tomarán las cantidades de los

servicios no atendidos y el total de las solicitudes de servicio.


DíaCantidad

Solicitudes

Cantidad Solicitudes

no Atendidas

PorcentajeServicios no Atendidos


Observaciones: _____________________________________________________________________________________________________________________________________________________________________________________________

Observador





ANEXO 05


Solicitudes de Servicio Asignadas por Técnico.

Instrucciones: En los días de observación se tomarán las cantidades de las

solicitudes de los servicios asignados a un técnico.


TécnicoCantidad

SolicitudesAsignadas


Observaciones: _____________________________________________________________________________________________________________________________________________________________________________________________

Observador





ANEXO 06


Solicitudes de Servicio por Oficina.


solicitudes de los servicios de oficinas específicas.


OficinaCantidad

SolicitudesServicios


Observaciones: _____________________________________________________________________________________________________________________________________________________________________________________________

Observador





ANEXO 07


Número de Equipos Internados.


guías de salida de los equipos de otras dependencias que han sido atendidos en

el taller de Soporte Técnico.

Fecha de inicio de observación: __/ __/ ___ Hora de Inicio: _________

DíaCantidad de

Equipos de Otra Dependencia


Observaciones: _____________________________________________________________________________________________________________________________________________________________________________________________

Observador





ANEXO 08


Tiempo de Búsqueda de Historial Técnico.

Instrucciones: En los días de observación se tomarán la fecha y hora de inicio de la búsqueda del historial técnico de un equipo y la hora de finalización de dicha búsqueda.


NúmeroHora de

InicioHora de

FinalizaciónTiempo

Total (Min)

Tiempo Promedio


Observaciones: _____________________________________________________________________________________________________________________________________________________________________________________________

Observador





ANEXO 09


Tiempo de Emisión de Documentos.

Instrucciones: En los días de observación se tomarán la fecha y hora de inicio de la emisión de un documento (reportes, guías de salida y/o fichas técnicas) y la hora de finalización o entrega de dicho documento.


NúmeroHora de

InicioHora de Entrega

Tiempo Total (Min)

Tiempo Promedio


Observaciones: _____________________________________________________________________________________________________________________________________________________________________________________________

Observador





ANEXO 10

Cuestionario de Encuesta Nº 01

“Sistema de Control para las Tareas del Servicio de Soporte Técnico de la Oficina de Informática de la Municipalidad Provincial de Piura mediante una

Aplicación Web”

El presente cuestionario de encuesta será desarrollado como guía para obtener el

grado de satisfacción del usuario de la aplicación web.

_________________________________________________________________

Marque con un círculo o un aspa su repuesta elegida.

1) ¿Con la aplicación web implementada se ha mejorado su actividad de tra-

bajo?

a. Nada

b. Poco

c. Medianamente

d. Mucho

2) ¿La aplicación web implementada es fácil de manejar?

a. Nada

b. Poco

c. Medianamente

d. Mucho

3) ¿Con la aplicación web implementada la información está disponible de

forma inmediata?

a. Nada

b. Poco

c. Medianamente

d. Mucho




4) ¿La información que brindan los reportes de la aplicación web son de utili-

dad para los usuarios del sistema?

Nada

Poco

Medianamente

Mucho

5) ¿Está usted satisfecho con la aplicación web?

a. Nada

b. Poco

c. Medianamente

d. Mucho

6) ¿La aplicación web implementada cumple con todos los requisitos solicita-dos?

a. Nada

b. Poco

c. Medianamente

d. Mucho

7) ¿Cuál es su opinión general de la aplicación web?

Gracias por su participación




Este cuestionario de encuesta se mide de la siguiente forma:

Como para cada pregunta se presentan 4 opciones las cuales se asemejan

(grado de medición), una vez resueltas estas encuestas por el personal de Sopor-

te Técnico, se procederá al conteo de las letras para conocer cuál de ellas ha

obtenido mayor puntaje.

Si la mayor cantidad de las letras son:

PUNTUACIÓN GRADO DE SATISFACCIÓN

aQuiere decir que el usuario se

encuentra Nada Satisfecho.

bQuiere decir que el usuario se

encuentra Poco Satisfecho.

cQuiere decir que el usuario se

encuentra Medianamente Satisfecho.

dQuiere decir que el usuario se

encuentra Muy satisfecho.


Documents

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