Desarrollo de un plan de soporte

UNIVERSIDAD SIMÓN BOLÍVAR

Ingeniería de la Computación

DESARROLLO DE UN ESCRITORIO DE AYUDA

PARA EL ÁREA DE SOPORTE TÉCNICO DE LA GERENCIA DE INFORMÁTICA

DEL INSTITUTO DE ESTUDIOS SUPERIORES DE ADMINISTRACIÓN

Por

EVELICE BEATRIZ GUIA CAÑIZALEZ

INFORME FINAL DE CURSOS EN COOPERACIÓN

Presentado ante la Ilustre Universidad Simón Bolívar

como Requisito Parcial para Optar al Título de

Ingeniero en Computación

Sartenejas, Marzo de 2005

ii

UNIVERSIDAD SIMÓN BOLÍVAR DECANATO DE ESTUDIOS PROFESIONALES

COORDINACIÓN DE INGENIERÍA DE LA COMPUTACIÓN

ACTA FINAL DE CURSOS EN COOPERACIÓN




Presentado por:


Este trabajo de cursos en cooperación ha sido aprobado en nombre

de la Universidad Simón Bolívar por el siguiente jurado examinador:

_______________________________________

Profesor Andreas Meier

Jurado

_______________________________________

Profesora Teresita Rojas

Tutor Académico

Sartenejas, 15/03/2005

iii




POR


RESUMEN

El IESA prosee un servicio de Helpdesk que pretende dar solución a los problemas del área

tecnológica. El registro de los incidentes de TI es llevado a cabo de forma manual a través de un archivo

Excel, lo que origina que el proceso dependa fundamentalmente del analista de soporte técnico. Además,

no existe en la organización un registro de las soluciones encontradas a los problemas presentados, por lo

que en muchos casos se repite el mismo trabajo de investigación para encontrar soluciones que habían

sido encontradas anteriormente. Es por esto que surgió la necesidad de crear un sistema que permita la

automatización del proceso de manejo de incidentes, generando a su vez una base de conocimientos que

capture, organice y haga mantenible en el tiempo las soluciones encontradas a los problemas presentados,

motivo por el cual se realizó el presente proyecto de pasantía.

El presente informe describe de manera detallada las actividades realizadas durante el desarrollo del

escritorio de ayuda para el área de soporte técnico del IESA. Los objetivos planteados fueron introducir las

mejores prácticas para el manejo de incidentes propuestas por ITIL, generar la base de conocimientos y

establecer métricas de procesos que permitieran tomar decisiones para mejorar el servicio.

La ejecución del proyecto fue gerenciada por la metodología de Gerencia de Proyectos, que divide el

proyecto 5 fases: definición, planificación, ejecución, control y seguimiento, y cierre. Para el desarrollo del

sistema, se adoptó el modelo RAD (Rapid Application Development), la cual permite desarrollar sistemas

en corto tiempo, haciendo uso de prototipos.

La aplicación fue desarrollada bajo la tecnología .NET, específicamente ASP.NET. La base de datos

con la que interactúan los módulos creados se desarrollo bajo el manejador de base de datos Oracle 8i.

Los resultados obtenidos fueron bastante satisfactorios para la Gerencia de Informática, ya que se

respetaron los estándares de la organización, se satisficieron las necesidades y requerimientos de los

usuarios y además se alcanzaron la mayoría de los objetivos planteados.

iv

DEDICATORIAS A mi Mamá.

A mi Papa.

A mi Hermana.

A mis Abuelas.

A mis Tíos y Primos.

v

AGRADECIMIENTOS

A mi mamá, por sus enseñanzas y apoyo incondicional. Por estar siempre a mi lado. Por su

esfuerzo y constancia para hacer de mi lo que soy.

A mi papá, por los consejos que me ha dado y porque junto a mamá me ha guiado durante los

momentos más difíciles de mi carrera y mi vida.

A Eliana, porque además de hermana ha sido mi amiga, estando siempre a mi lado.

A mis abuelas, por el cariño que me han dado y por estar siempre pendientes de mí.

A mis tíos y primos, por ayudarme y apoyarme, alentándome a seguir adelante.

A mis amigos y compañeros de estudios, por haberme acompañado en las buenas y en las malas,

durante el transcurso de la carrera.

A Julio César, por ser tan especial, por apoyarme en todo momento, por su gran ayuda y

comprensión.

Al Instituto de Estudios Superiores de Administración IESA, específicamente a la Gerencia de

Informática y Telecomunicaciones, y a Paola Adrianza, por brindarme la posibilidad de realizar este

proyecto y facilitarme la transición de lo académico a lo profesional.

A la Universidad Simón Bolívar, por la excelente educación que me ha brindado.

A Teresita Rojas, por su paciencia, dedicación y conocimientos brindados.

A todos aquellos que en algún momento hayan sido fuente de apoyo, comprensión o aliento.

A todos… Muchas Gracias!

vi

ÍNDICE GENERAL RESUMEN….. ............................................................................................................................................... iii DEDICATORIAS............................................................................................................................................ iv AGRADECIMIENTOS.....................................................................................................................................v ÍNDICE GENERAL......................................................................................................................................... vi ÍNDICE DE FIGURAS.................................................................................................................................. viii ÍNDICE DE TABLAS...................................................................................................................................... ix LISTA DE SÍMBOLOS Y ABREVIATURAS ....................................................................................................x CAPÍTULO I. INTRODUCCIÓN .....................................................................................................................1 CAPÍTULO II. PLANTEAMIENTO DEL PROBLEMA......................................................................................3

II.1. Situación Actual...................................................................................................................................3 II.2. Sistema a Desarrollar ..........................................................................................................................4 II.3. Beneficios para la organización...........................................................................................................5

CAPÍTULO III. ENTORNO EMPRESARIAL....................................................................................................6 III.1. Definición de la Empresa....................................................................................................................6 III.2. Estructura de la Empresa ...................................................................................................................6 III.3. Valores que definen la Cultura Corporativa ........................................................................................8

CAPÍTULO IV. MARCO TEÓRICO...............................................................................................................10 IV.1. Gestión del Conocimiento. ...............................................................................................................10 IV.2. Librería de Infraestructura de Tecnología de la Información (ITIL)...................................................10 IV.3. Escritorio de Servicio o Helpdesk.....................................................................................................12 IV.4. Gestión de Incidentes.......................................................................................................................13 IV.5. Gestión de Problemas......................................................................................................................14

CAPÍTULO V. METODOLOGÍA DE DESARROLLO....................................................................................16 CAPÍTULO VI. MARCO TECNOLÓGICO.....................................................................................................19

VI.1. Hardware..........................................................................................................................................19 VI.2. Tecnología de Software ...................................................................................................................19

VI.2.1. Plataforma .NET .......................................................................................................................19 VI.2.2. Internet Information Services (IIS) ............................................................................................20 VI.2.3. Visual Studio.NET.....................................................................................................................20 VI.2.4. Visual C#.NET ..........................................................................................................................21

VI.3. Manejador de Bases de Datos .........................................................................................................21 VI.4. Redes y Comunicación ....................................................................................................................21

VI.4.1. SharePoint Portal Server 2003. ................................................................................................21 VI.4.2. Exchange..................................................................................................................................22

CAPÍTULO VII. DESARROLLO DEL SISTEMA............................................................................................23 VII.1. Fase de Iniciación ...........................................................................................................................23 VII.2. Fase de Planificación ......................................................................................................................23 VII.3. Fase de Ejecución...........................................................................................................................23

VII.3.1. Modelo del Negocio .................................................................................................................24 VII.3.2. Etapa de Planificación de Requerimientos...............................................................................25 VII.3.3. Etapa de Diseño ......................................................................................................................36 VII.3.4. Etapa de Desarrollo .................................................................................................................47 VII.3.5. Etapa de Implantación .............................................................................................................56

vii

VII.4. Fase de Control y Seguimiento .......................................................................................................56 VII.5. Fase de Cierre ................................................................................................................................57

CAPÍTULO VIII. ANÁLISIS DE RESULTADOS ............................................................................................58 CAPÍTULO IX. CONCLUSIONES Y RECOMENDACIONES........................................................................60

IX.1. Conclusiones....................................................................................................................................60 IX.2. Recomendaciones ...........................................................................................................................61

REFERENCIAS BIBLIOGRÁFICAS..............................................................................................................62 BIBLIOGRAFÍA.............................................................................................................................................64 APÉNDICES …………..................................................................................................................................65

APÉNDICE A. MODELO CONCEPTUAL DE LA GESTIÓN DE INCIDENTES SEGÚN ITIL ...................66 APÉNDICE B. PLAN DE DESARROLLO DEL PROYECTO HELPDESK ................................................77 APÉNDICE C. ESPECIFICACIÓN DE REQUERIMIENTOS FUNCIONALES Y NO FUNCIONALES......82 APÉNDICE E. GLOSARIO DE TÉRMINOS ...........................................................................................100 APÉNDICE F. ESPECIFICACIÓN DE CASOS DE USO........................................................................103 APÉNDICE G. DIAGRAMAS DE SECUENCIA ......................................................................................133 APÉNDICE H. DICCIONARIO DE DATOS.............................................................................................144 APÉNDICE I. MAPAS DE NAVEGACIÓN..............................................................................................149 APÉNDICE J. MANUAL DE USUARIO ..................................................................................................150

viii

ÍNDICE DE FIGURAS Figura 1. Estructura Organizacional......................................................................................... 7

Figura 2. Las Capas de la Plataforma .NET………………………………………………………. 20

Figura 3. Interacción de los Componentes Tecnológicos……………………………………….. 22

Figura 4. Casos de Uso del Negocio………………………………………………………………. 25

Figura 5. Diagrama de Casos de Uso……………………………………………………………… 36

Figura 6. Especificación Caso de Uso: Iniciar Sesión……………………………………………. 37

Figura 7. Diagrama 4+1 vistas……………………………………………………………………… 38

Figura 8. Modelo Conceptual……………………………………………………………………….. 39

Figura 9. Modelo Entidad-Relación………………………………………………………………… 40

Figura 10. Modelo Relacional……………………………………………………………………… 41

Figura 11. Diagrama de Clases…………………………………………………………………….. 42

Figura 12. Arquitectura 3 Capas……………………………………………………………………. 44

Figura 13. Mapa de Navegación General…………………………………………………………. 47

Figura 14. Mapa de Navegación Completo del Sistema HelpDesk…………………………….. 48

Figura 15. Pagina de Inicio para Cliente…………………………………………………………… 49

Figura 16. Página de Registro de Incidentes para Clientes……………………………………... 50

Figura 17. Página de Registro de Evaluaciones………………………………………………….. 51

Figura 18. Página de Consulta de Incidentes…………………………………………………….. 51

Figura 19. Página de Inicio para Soporte………………………………………………………….. 52

Figura 20. Página de Registro de Incidentes para Soporte……………………………………... 53

Figura 21. Página de Actualización de Problemas……………………………………………….. 54

Figura 22. Página de Control de Solicitudes…………….......................................................... 54

Figura 23. Página de Actualización de Actividades Realizadas…........................................... 55

ix

ÍNDICE DE TABLAS TABLA 1. Resumen de Usuarios............................................................................................. 26

TABLA 2. Resumen de Stakeholders....................................................................................... 27

TABLA 3. Lista de Riesgos………………………………………………………………………….. 31

TABLA 4. Actores del Sistema................................................................................................. 33

TABLA 5. Cumplimiento de Objetivos Planteados................................................................... 58

x

LISTA DE SÍMBOLOS Y ABREVIATURAS

ADO.NET ActiveX Data Objects para .NET

ASP.NET Active Server Page para .NET

CLR Common Language Runtime (Máquina Virtual Común)

CU Casos de Uso

HTML HyperText Markup Language (Lenguaje de Marcas de Hipertexto)

IESA Instituto de Estudios Superiores de Administración

IIS Internet Information Services

ITIL Librería de Infraestructura de Tecnología de la Información

MSIL Microsoft Intermediate Language

RAD Rapid Application Development

RUP Rational Unified Process

SO Sistema Operativo

TI Tecnologías de la Información

UML Unified Modeling Language (Lenguaje unificado de modelaje)

VS.NET Visual Studio .NET

XML Extensible Markup Language (Lenguaje de Marcas Extensible)

CAPÍTULO I. INTRODUCCIÓN

Tradicionalmente las organizaciones de Tecnología de Información (TI) han estado enfocadas y

concentradas en la gestión de sus activos materiales y los aspectos técnicos, dejando olvidadas cosas tan

importantes como las personas, la tecnología, las mejoras en los procesos de negocio, las relaciones con

clientes, y en definitiva todo aquello que las rodea y les permite funcionar. En la actualidad, los negocios

tienen altas expectativas con respecto a la calidad de los servicios, es por ello que las organizaciones

deben enfocarse en la calidad de los servicios y mucho más orientado a los clientes.

El desarrollo de la gestión de los servicios de TI se ha basado en el reconocimiento, por parte de las

empresas, de su dependencia en dichos sistemas para satisfacer sus objetivos corporativos y cumplir con

las necesidades del negocio. Esta dependencia creciente conduce al aumento en los requisitos de calidad

de los servicios de TI.

La gestión de servicios de TI está relacionada con la planificación, implementación seguimiento y

control de la operación de dichos servicios y las infraestructuras sobre las que se soportan. Constituyen un

conjunto de procesos que cooperan entre si para asegurar la calidad del servicio de TI, y proporcionan un

marco general dentro del cual operan las distintas actividades individuales como el Help Desk (Escritorio de

Ayuda), la Gestión de Incidentes y Gestión de Problemas.

Este proyecto de pasantía consistió en desarrollar un Sistema de HelpDesk para la Gerencia

Informática del IESA, el cual permite a los usuarios administrar los incidentes presentados en el área de

soporte técnico, llevar el control de las solicitudes de servicio de TI y generar una base de conocimiento de

las soluciones a problemas presentados.

Para el desarrollo del sistema se adoptó el modelo Rapid Application Development (RAD), con la

finalidad de obtener mejores y más rápidos resultados, así como abarcar todos los aspectos relacionados

con la creación del sistema. Sin embargo, este modelo fue insertado dentro de la Gerencia de Proyectos,

que es una metodología que usa el IESA para administrar su cartera de proyectos.

La solución implementada, esta basada en arquitectura de tres capas, que permite dividir claramente

las actividades para cada capa, haciendo que el sistema sea escalable y mantenible.

La finalidad del sistema minimizar el impacto adverso de los Incidentes y Problemas sobre las

operaciones del negocio, que son causados por errores en la infraestructura de TI, asegurando que se

mantengan los mejores niveles posibles de calidad y disponibilidad.

Capítulo I. Introducción

2

El informe que se presenta a continuación contiene una descripción de las actividades realizadas y los

resultados obtenidos durante el proyecto de pasantía, y se encuentra estructurado por capítulos de la

siguiente forma:

• Capítulo II - Planteamiento del Problema. Se detallan los objetivos y los beneficios que se

quieren alcanzar con el proyecto.

• Capítulo III - Entorno Empresarial. Se describe la empresa en la cual se desarrollo el proyecto.

• Capítulo IV - Marco Teórico. Se exponen los fundamentos teóricos relacionados con el proyecto

de la pasantía.

• Capítulo V - Marco Metodológico. Se describen las metodologías utilizadas en el desarrollo del

proyecto.

• Capitulo VI - Marco Tecnológico. En este capítulo se describe la tecnología usada para el

desarrollo del proyecto.

• Capítulo VII - Desarrollo del Sistema. Se describen los artefactos correspondientes a cada una

de las fases de la metodología.

• Capítulo VIII - Análisis de Resultados. Se detallan los resultados obtenidos con respecto a los

objetivos planteados.

• Capítulo IX - Conclusiones y Recomendaciones. En este capítulo se presentan las conclusiones

y las recomendaciones obtenidas a lo largo del desarrollo del proyecto de pasantía.

En el siguiente capítulo se describe el planteamiento del problema sobre el cual se basa el

proyecto.

Capítulo II. Planteamiento del Problema

3

CAPÍTULO II. PLANTEAMIENTO DEL PROBLEMA

Este capítulo tiene como objetivo describir la situación actual de la empresa con respecto al servicio de

helpdesk, identificando las razones por las cuales se emprendió este proyecto. Además se presenta una

breve descripción del sistema a desarrollar, los objetivos generales y específicos planteados y los

beneficios que se pretenden alcanzar con el desarrollo del proyecto.

II.1. Situación Actual

La Gerencia de Informática y Telecomunicaciones del IESA posee un servicio de Helpdesk donde se

pretende dar solución a los problemas que puedan ocurrir en el área de TI. Actualmente el proceso de

registro del manejo de incidentes de soporte técnico es llevado a cabo mediante un archivo Excel, donde el

analista debe editar el archivo, agregando las solicitudes a medida que se presentan. Dicho archivo

almacena la información referente al solicitante y su solicitud, el estado de la misma, la solución dada y los

resultados de las encuestas realizadas a los solicitantes.

Las solicitudes de servicios y reportes de Incidentes se realizan personalmente, vía correo electrónico

y vía telefónica.

Para aplicar las encuestas, el analista debe enviarla vía correo electrónico al solicitante y luego

recolectar las respuestas para poder modificar el archivo Excel.

El problema fundamental de este esquema es que depende en un 100% del analista de Helpdesk, ya

que ninguna de las variables se carga automáticamente. Por ejemplo: la hora y fecha del requerimiento, la

hora y fecha de la solución, el envío de la encuesta, y las estadísticas, son algunos de los datos que se

podrían cargar de manera automática y así eliminar errores de omisión y de carga de datos. Por otra parte

los usuarios no tienen la posibilidad de consultar el estado de sus solicitudes y la gerencia de soporte

tecnológico no tiene estadísticas que le permitan acometer procesos claves para la mejora de los servicios

y hacer propuestas para reducción de costos de soporte, basada en datos reales.

Otro problema que se presenta actualmente, esta relacionado con la recopilación de las soluciones a

problemas comunes o conocidos. No existe un registro de cómo se deben solucionar problemas tipo, por lo

que la gerencia depende fuertemente de los analistas.


4

II.2. Sistema a Desarrollar

El sistema a desarrollar tiene la finalidad de permitir la automatización del proceso de manejo de

problemas e incidentes en el área de soporte técnico del departamento de informática. Para ello es

necesario llevar un registro de las solicitudes y los solicitantes. Además, se debe registrar el ciclo de vida

del incidente prestando especial atención al registro de la solución y la evaluación de la misma por parte

del solicitante mediante una encuesta vía correo electrónico. Debe manejar solicitudes de servicios y

reporte de incidentes vía Web, correo electrónico, vía telefónica y personalmente, así como generar

estadísticas de problemas tipo, además de permitir vistas de las solicitudes para usuarios finales, analistas

de soporte técnico y Gerencia General de Soporte Técnico. El sistema se desarrollará en ambiente Web,

respetando el estándar de diseño actual de la empresa, utilizando la metodología de gerencia de

proyectos, incorporando en el sistema los controles relacionados con la metodología ITIL para la atención

de incidentes; la cual contempla estándares de registro de incidentes, con formatos y procedimientos

asociados; y generación de reportes acorde a la información relevante para la gerencia.

Objetivos Generales

Automatizar el proceso de manejo de incidentes y atención al cliente de TI (toda la comunidad del

IESA), generando a su vez una base de conocimientos con las soluciones de problemas.

Generar métricas de los procesos que permitan la mejora continua de los mismos.

Apoyar los objetivos estratégicos de la empresa, relacionados con mejorar la calidad de servicio a

través de renovación de servicios estudiantiles y sistema de atención centralizada.

Incorporar al Helpdesk los conceptos y procesos de ITIL correspondientes al manejo de servicios,

incidentes y problemas del área de TI.

Objetivos Específicos

1. Desarrollar una aplicación en plataforma Web que maneje diferentes perfiles: cliente, soporte.

2. Incorporar un nuevo canal de comunicaciones con la gerencia, que permita la realización de

solicitudes de soporte vía Web, bien sea por fallas del servicio o por solicitud del mismo.

3. Generar una base de conocimientos de las soluciones a los problemas presentados, que será

explotada en una segunda fase del proyecto, que no es parte del alcance inicial de esta pasantía.

4. Incorporar un proceso de evaluación del servicio por parte del cliente, realizando las encuestas de

manera automática.


5

5. Diseñar e implementar un repositorio de datos que soporte las tareas a realizar por la aplicación.

6. Para el perfil cliente, permitir realizar el registro de incidentes y solicitudes a través de la aplicación,

consultar el estado de los mismos.

7. Para el perfil soporte, permitir el registro, modificación y consulta incidentes y solicitudes, y realizar

el registro de las soluciones encontradas a los problemas. Además, generar reportes estadísticos

de los problemas.

II.3. Beneficios para la organización

El desarrollo e implantación del proyecto HelpDesk traerá como consecuencia para la organización los

siguientes beneficios:

� Introducción de las mejores prácticas para los procesos de Gestión de Servicios de TI propuestas

por ITIL, lo cual permite mejorar la entrega y soporte de los servicios.

� Mejor información sobre los servicios que se prestan en la actualidad.

� Con la creación de una base de conocimientos, se convierte el conocimiento tácito de los

empleados en conocimiento explicito y perdurable en el tiempo, lo que hace que la organización

sea menos dependiente de sus empleados, y le permite llevar a cabo actividades de gestión de

conocimiento.

� Al automatizar los procesos se disminuye la carga de trabajo administrativo de los analistas de

soporte, permitiendo así que los mismos puedan enfocarse en prestar un mejor y más rápido

servicio, lo cual se traduce en aumento de la satisfacción laboral.

� Aumento en la satisfacción de los clientes.

Capítulo III. Entorno Empresarial

6

CAPÍTULO III. ENTORNO EMPRESARIAL

En este capítulo se describe la empresa en la cual se lleva a cabo el proyecto de pasantía, tomando en

cuenta su estructura organizacional y sus valores.

III.1. Definición de la Empresa

El Instituto de Estudios Superiores de Administración, IESA, es un centro académico privado, sin fines

de lucro, que presta un servicio público a toda la sociedad y es independiente de corrientes, grupos

económicos, políticos, religiosos o gubernamentales. [IESA, 2004]

Creado en 1965 y reconocido por la Presidencia de la República de Venezuela como Instituto

Universitario de Estudios Superiores en Administración (16 de marzo de 1976), el IESA se dedica a la

enseñanza de la gerencia, apoyándose en la investigación, tanto en administración como en otras

disciplinas, orientando su docencia hacia el desarrollo de la gerencia en organizaciones públicas y

privadas. [IESA, 2004]

En la actualidad, la institución ocupa un lugar distinguido dentro de las instituciones que componen el

sistema educativo nacional y dentro del ámbito mundial de las entidades académicas especializadas en

administración. Sin embargo, su mayor distinción ha sido la capacidad que posee para adaptar sus

enseñanzas a las necesidades nacionales, ampliando progresivamente la gama de programas y cursos de

desarrollo gerencial. Del mismo modo se ha enriquecido el programa de cursos ofrecidos a los ejecutivos

en áreas funcionales típicas de la administración (finanzas, mercadeo, contabilidad y producción). [IESA,

1990]

III.2. Estructura de la Empresa

El IESA como institución posee un modelo organizacional poco complejo, regido por dos principios

fundamentales: autonomía externa (independencia financiera e ideológica) y autonomía interna (múltiples

posibilidades de programación de sus actividades). Ambos sustentan y facilitan la participación de todos

sus miembros, y al mismo tiempo permiten una alta capacidad de adaptación y flexibilidad en la conducción

y operatividad de la institución. [IESA, 1990]

A continuación se presenta en la figura 1, el organigrama de la institución. Esta estructura es

considerada óptima para alcanzar los fines que persigue la empresa.


7

Figura 1. Estructura Organizacional [IESA, 2004]

.

El Consejo Directivo es la máxima autoridad del IESA y está integrado por un grupo de representantes

de instituciones públicas y privadas, y de personalidades vinculadas al área académica. En esta área la

máxima autoridad es el Consejo de Profesores, cuerpo que elige al Consejo Académico. [IESA, 2004]

La Dirección Académica es el órgano rector de los estudios de postgrado y Master del IESA, razón de

ser de las escuelas de negocios. Esta unidad tiene la responsabilidad de planificar, diseñar y actualizar, de

manera constante, todo lo relativo a la vida académica del Instituto, desde los programas de postgrado: El

Master y las especializaciones, hasta el desarrollo de los profesores, incluyendo el posicionamiento del

IESA en el ámbito académico internacional. [IESA, 2004]

La Dirección de Investigaciones se concibe como una unidad de servicio. En el ámbito externo, ofrece

a los clientes y patrocinantes la oportunidad de participar en el proceso de producción de conocimientos,

contribuyendo con aportes para la ejecución de proyectos de investigación, consultoría y publicaciones. En

el ámbito interno funciona como una unidad de servicio para la enseñanza, para la producción intelectual


8

de sus profesores y su posterior publicación, difusión y aplicación a situaciones reales, mediante proyectos

de consultoría. [IESA, 2004]

La Dirección de Investigaciones está constituida por:

• Unidad de Proyectos y Eventos.

• Unidad de Consultoría.

• Gerencia Editorial.

• Biblioteca “Lorenzo Mendoza Fleury”

• Gerencia de Comunicaciones Integradas.

• Gerencia de Informática y Telecomunicaciones.

La Gerencia de Informática y Telecomunicaciones desarrolla estrategias para adecuar los recursos

tecnológicos a las actividades docentes y administrativas del Instituto. De esta manera tiene la

responsabilidad de coordinar diversas actividades que generen impacto en la productividad de los procesos

gerenciales, de investigación y académicos que otorguen al Instituto una ventaja competitiva, mediante la

puesta en marcha de diversos proyectos de tecnología. [IESA, 2004] Es en esta unidad donde se ubica

organizacionalmente el pasante con la finalidad de desarrollar un Escritorio de Ayuda para el Soporte

Técnico de esta gerencia.

III.3. Valores que definen la Cultura Corporativa

La misión de la empresa es formar personas capaces de asumir posiciones de liderazgo, como

profesionales, gerentes o empresarios; para contribuir al éxito de las organizaciones privadas, públicas y

sin fines de lucro. De este modo, el Instituto genera procesos que constituyen un aporte al desarrollo de la

sociedad. [IESA, 2004]

La visión de la empresa es ser la opción preferida en formación gerencial por organizaciones y

estudiantes en Venezuela y América Latina, además de ser la escuela líder en investigación en gerencia,

con capacidad para aportar soluciones efectivas para las instituciones privadas y públicas en Venezuela y

América Latina. [IESA, 2004]

Los valores que definen la cultura corporativa de la institución se pueden ver desde dos puntos de

vista: Valores rectores de la conducta de la comunidad, que se refieren al comportamiento y trato entre los

participantes (estudiantes) y el personal administrativo y profesoral de la institución y los Principios rectores

del IESA, que son los que definen la cultura de la institución como un todo.

Valores rectores de la conducta de la comunidad: [IESA, 2004]


9

• Innovación, flexibilidad y adaptación.

• Petición y rendición de cuentas.

• Honestidad y cumplimiento de las normas.

• Solidaridad, disposición a contribuir al bienestar de otros y trato digno.

• Excelencia en cada una de sus actuaciones.

Principios rectores del IESA: [IESA, 2004]

• Cumplimiento cabal de la ley.

• Trato equitativo y justo de los integrantes de la comunidad.

• Búsqueda permanente del conocimiento y respeto por la diversidad de ideas y pluralidad de

culturas.

Capítulo IV. Marco Teórico

10

CAPÍTULO IV. MARCO TEÓRICO

El presente capítulo describe los fundamentos teóricos relacionados con el proyecto de la pasantía. El

objetivo principal es ubicar al lector dentro del ámbito del manejo de Incidentes y Problemas según ITIL.

Por otro lado, también se introducen los conceptos de Gestión del Conocimiento.

IV.1. Gestión del Conocimiento.

Antes de hablar sobre la gestión del conocimiento es necesario tener clara la definición de

conocimiento. El conocimiento es un conjunto integrado por información, reglas, interpretaciones y

conexiones puestas dentro de un contexto y de una experiencia, que ha sucedido dentro de una

organización, bien de una forma general o personal.

Ahora bien, una vez establecido el concepto de conocimiento, es posible adentrarse en el tema de la

Gestión del Conocimiento. Se puede decir que la Gestión del Conocimiento es el conjunto de procesos y

sistemas que permiten que el Capital Intelectual de una organización aumente de forma significativa,

mediante la gestión de sus capacidades de resolución de problemas de forma eficiente (en el menor

espacio de tiempo posible), con el objetivo final de generar ventajas competitivas sostenibles en el tiempo

[Carrión, 2004].

La gestión del conocimiento tiene como objetivo facilitar la publicación, y la localización del

conocimiento explícito, capturar y hacer permanente el conocimiento tácito y capturar y habilitar o facilitar el

acceso al conocimiento de las herramientas de negocio.[García, 2002]

Una base de conocimientos permite capturar el conocimiento tácito y convertirlo en conocimiento

explícito, de esta forma se asegura que todos los empleados tengan acceso a la información necesaria

para resolver los problemas y así disminuir su tiempo de respuesta. Con la revisión, agrupación y

aplicación del conocimiento disponible en la base de conocimientos, se obtiene un valor agregado del

mismo.

IV.2. Librería de Infraestructura de Tecnología de la Información (ITIL)

ITIL fue desarrollada al reconocer que las organizaciones dependen cada vez más de la TI para

alcanzar sus objetivos corporativos. Esta dependencia en aumento ha dado como resultado una necesidad

creciente de servicios TI de calidad que se correspondan con los objetivos del negocio, y que satisfaga los

requisitos y las expectativas del cliente. A través de los años, el énfasis pasó de estar sobre el desarrollo


11

de las aplicaciones TI a la gestión de servicios TI. La aplicación TI sólo contribuye a realizar los objetivos

corporativos si el sistema está a disposición de los usuarios y, en caso de fallos o modificaciones

necesarias, es soportado por mantenimiento y operaciones. [Van Bon, 2004]

ITIL proporciona una descripción detallada de una serie de buenas prácticas de TI, a través de una

amplia lista de roles, tareas, procedimientos y responsabilidades que pueden adaptarse a cualquier

organización de TI. [Van Bon, 2004]

La ITIL consiste en una serie de libros que ofrecen una guía para proporcionar servicios de TI de alta

calidad, así como los recursos del entorno necesarios para soportar las tecnologías de la información. Ha

sido utilizada en cientos de empresas de todo el mundo, lo que ha hecho que surja una filosofía ITIL común

en torno a las guías proporcionadas por estos libros. [Telindus, 2003] La vasta cantidad de temas cubiertos

por las publicaciones convierte ITIL en un elemento de referencia útil para fijar nuevos objetivos de mejora

para la organización de TI.

La ITIL describe los aspectos necesarios para organizar la Gestión de Servicios que está relacionada

con la entrega y soporte de los servicios de TI apropiados para los requerimientos de negocios de la

organización.

La Librería de Infraestructura de TI provee un conjunto completo, consistente y coherente de las

mejores prácticas para los procesos de Gestión de Servicios de TI, promoviendo un enfoque de calidad

para lograr la efectividad de los negocios y la eficiencia en el uso de Sistemas de Información. [ITIL, 2001]

Basándose en ITIL, es posible planificar los procesos comunes, con las referencias apropiadas de

unos con otros y como deben ser las líneas de comunicación entre ellos, y para cada uno de los procesos

de Gestión de Servicios, identificar objetivos, actividades, entradas, salidas y uno o más roles encargados

de llevar a cabo dichas actividades. Esta permitido asignar más de un rol a un individuo o asignar más de

un individuo a un rol.

ITIL comprende cinco elementos principales, donde cada uno de ellos se comunica y se superpone con

los cuatro restantes. Estos elementos son:

• Perspectivas de Negocio. Incluye:

- Gestión Continuidad del Negocio.

- Asociaciones y Outsourcing.

- Cambios para la supervivencia del negocio.

• Gestión de Aplicaciones.


12

• Presentación de Servicios de TI. Incluye:

- Gestión de Capacidad.

- Gestión Financiera para servicios de TI.

- Gestión de Disponibilidad.

- Gestión de Niveles de Servicio.

- Gestión de la Continuidad del Servicio.

- Gestión de las relaciones con los clientes.

• Soporte a los Servicios de TI. Incluye:

- Escritorio de Servicio (Service Desk).

- Gestión de Incidentes.

- Gestión de Problemas.

- Gestión de Configuración.

- Gestión de Cambios.

- Gestión de Release o Versiones.

• Gestión de Infraestructura. Incluye:

- Gestión de Servicios de Redes.

- Gestión de Operaciones.

- Gestión de Procesadores Locales.

- Instalación de Computadoras y Aceptación.

- Gestión de Sistemas.

El enfoque del proyecto de pasantía esta dirigido hacia el área de Soporte a los Servicios de TI,

básicamente en el Escritorio de Servicio, la Gestión de Incidentes y la Gestión de Problemas.

IV.3. Escritorio de Servicio o Helpdesk

Con la finalidad de cumplir tanto con los objetivos del Cliente como del Negocio, las organizaciones

buscan aplican un punto central de contacto para manejar los asuntos relacionados con el Cliente y el

Usuario.

El Escritorio de Servicio ofrece a todos los usuarios un punto de contacto único para la gestión y

resolución de sus problemas de TI. Extiende el rango de los servicios y ofrece un enfoque más global,

permitiendo la integración de los procesos de negocio a la infraestructura de Gestión de Servicio. [ITIL,

2001] Se encarga de manejar, coordinar y resolver Incidentes tan pronto como sea posible, asegurando


13

que ningún requerimiento es perdido, olvidado o ignorado. Pero no solo se encarga de manejar Incidentes,

Problemas y preguntas, sino que también provee una interfaz para otras actividades como Solicitudes de

Cambio, Gestión de Configuración, Gestión de Disponibilidad, etc.

Las características principales de un Escritorio de Servicio son:

- Representa el proveedor de servicio al Cliente y al Usuarios.

- Opera bajo el principio de que la satisfacción y la percepción del Cliente son críticas.

- Depende de la mezcla de personas, procesos y tecnología para entregar un servicio del negocio.

En términos generales, se puede esperar que la introducción de un Escritorio de Servicio produzca

beneficios para el negocio y para la provisión de soporte. Algunos de estos beneficios serían:

- Mejora del servicio al Cliente, su percepción y su satisfacción.

- Aumento de la accesibilidad a través de un solo punto de contacto, de comunicación, y de

información.

- Mejor calidad y tiempo de respuesta a los requerimientos del cliente.

- Mejoras en el trabajo en equipo y comunicación.

- Reducción del impacto negativo en el negocio.

- Mejoras en el manejo y control de la infraestructura.

- Uso mejorado los recursos de soporte de TI y aumento en la productividad del personal del

negocio.

- Un manejo de información más significativo para el soporte de decisión.

IV.4. Gestión de Incidentes

En la terminología de ITIL, un “Incidente” es definido como “cualquier evento que no forma parte de las

operaciones estándares de un servicio y que causa, o puede causar, una interrupción de, o reducción en,

la calidad de dicho servicio”. [ITIL, 2001]

El proceso de Gestión de Incidentes tiene como principal objetivo reestablecer el servicio normal de

operaciones tan rápido como sea posible y minimizar el impacto negativo sobre las operaciones de

negocio, asegurando que se mantengan los mejores niveles posibles de calidad y disponibilidad.

La mayoría de los departamentos de TI y grupos especialistas contribuyen con el manejo de Incidentes

en algún momento. El Escritorio de Servicio es el responsable de monitorear el proceso de resolución de

todos los Incidentes registrados (de hecho el Escritorio de Servicio es el dueño de todos los Incidentes).


14

Los Incidentes que no pueden ser resueltos por el Escritorio de Servicio deben ser asignados a un

grupo de especialistas. A menudo, estos grupos de especialistas, son llamados como grupos de segunda o

tercera línea de soporte, los cuales poseen más habilidades, tiempo u otros recursos para solventar

Incidentes.

Una solución o remedio (Work-around) debe ser establecido tan rápido como sea posible con la

finalidad de reestablecer el servicio a los Usuarios con la mínima interrupción de su trabajo. Después de la

resolución de la causa de un Incidente y el reestablecimiento del servicio afectado, el Incidente es cerrado.

La causa de un Incidente puede ser aparente, y dicha causa puede controlarse sin necesidad de una

investigación adicional. Cuando la causa fundamental de un Incidente no es identificable, entonces se debe

levantar un registro de Problema. Un problema, en efecto, es indicativo de un error desconocido en la

infraestructura. El procesamiento exitoso de un Problema, resultará en la identificación del error y será

convertido en un Error Conocido una vez que se haya desarrollado el Work-around.

Un Problema puede ocasionar múltiples Incidentes, y es posible que el Problema no sea diagnosticado

hasta que hayan ocurrido numerosos Incidentes. El manejo de Problemas es un poco diferente al manejo

de Incidentes y por lo tanto está cubierto por el proceso de Gestión de Problemas.

Para el caso particular del IESA, se pueden identificar como Incidentes que una impresora no funcione,

que no se pueda instalar una aplicación, etc.

IV.5. Gestión de Problemas

Un Problema es una condición a menudo identificada como resultado de múltiples Incidentes que

presentan síntomas comunes. Un Problema también puede ser identificado como un Incidente individual,

indicativo de un error individual cuya causa es desconocida pero cuyo impacto es significativo.

Un ejemplo muy común de Problemas que se pueden presentar son los ataques de virus, este tipo de

problemas puede generar un gran número de Incidentes, para los cuales no se conoce solución sino hasta

después de haber sido investigado a fondo.

El principal objetivo del proceso de Gestión de Problemas en minimizar el impacto adverso de los

Incidentes y Problemas sobre el negocio, que son causados por errores en la infraestructura de TI, y

prevenir la recurrencia de Incidentes relacionados con dichos errores.

Este proceso está constituido por dos subprocesos: el Control de Problemas que se enfoca en

transformar Problemas en Errores Conocidos, y el Control de Errores que se enfoca en resolver Errores


15

Conocidos estructuralmente. Un Error Conocido es una condición identificada por un diagnóstico exitoso de

la causa de un Problema y el subsiguiente desarrollo de un Work-around.

IV.5.1. Control de Problemas

El proceso de Control de Problemas está relacionado con el manejo de Problemas de forma eficiente y

efectiva. El objetivo es identificar la raíz de la causa y proporcionar el Escritorio de Servicio con la

información y sugerencia de un Work-around cuando esté disponible.

IV.5.2. Control de Errores

El Control de Errores cubre los procesos envueltos en el procesamiento de los Errores Conocidos

hasta que hayan sido eliminados. El objetivo del Control de Errores es estar en conocimiento de los errores

para monitorearlos y eliminarlos cuando sea posible.

Ya que el tema principal del proyecto HelpDesk es incluir las buenas prácticas de ITIL en la gestión de

incidentes y problema, en el Apéndice A, esta disponible la información más detallada sobre el Modelo

Conceptual de la Gestión de Incidentes en un HelpDesk tal y como lo define ITIL. [ITIL, 2001]

IV.5.3. Métricas de Proceso

Las métricas de procesos son algo más que una simple medida de algún “atributo” del proceso; una

métrica es una información que sirve para planificar, predecir y evaluar el estado de un proceso. Una

organización debe adoptar métricas para evaluar los procesos operativos de TI y para proveer un temprano

aviso de problemas que puedan socavar los niveles de servicio del negocio. Por ejemplo, los procesos de

Help Desk no efectivos pueden resultar en inconvenientes y pérdida de productividad si los usuarios deben

llamar repetidamente al Help Desk para reportar problemas que no son resueltos rápidamente.

A continuación se describe la metodología a seguir tanto para la gerencia del proyecto como para el

desarrollo del mismo.

Capítulo V. Metodología de Desarrollo

16

CAPÍTULO V. METODOLOGÍA DE DESARROLLO

El presente capítulo describe la metodología aplicada para el desarrollo del Proyecto Helpdesk. Se

especifican las fases en las cuales se divide la metodología, así como los entregables básicos de cada

una de ellas.

El desarrollo del sistema Helpdesk es gerenciado a través de la Metodología de Gerencia de

Proyectos, la cual es un estándar utilizado por el IESA para administrar su cartera de proyectos. Esta

metodología establece que los proyectos deben ser divididos en 5 etapas. Cada una de estas se completa

con la obtención de uno o más entregables. Un entregable es el resultado de un trabajo finalizado, como

por ejemplo, un diseño detallado o un prototipo. Estos entregables garantizan la comunicación efectiva

entre todos los involucrados, especialmente clientes.

A continuación se presentan detalladamente cada una de las fases establecidas por la metodología.

1. Iniciación

En esta etapa se debe realizar el resumen de proyecto que consiste en un documento explicativo que

contiene la descripción del problema u oportunidad, propósito y metas planteadas, objetivos y alcance

establecido, así como criterios que permitan verificar el éxito del proyecto.

2. Planificación

El entregable principal de esta etapa es el documento del plan de trabajo en el cual se especifican las

actividades a realizar, la secuencia de ejecución, los recursos y tiempos estipulados para cada una de

ellas, identificando las actividades críticas, es decir, aquellas que puedan repercutir de manera negativa en

el proyecto.

Esta etapa también incluye la formación del equipo de trabajo con la identificación de roles y

responsabilidades de cada uno de los miembros del equipo.

3. Ejecución

Se refiere a la ejecución del proyecto, y sus entregables están definidos en cada una de las fases

del proyecto específico.


17

4. Control y Seguimiento

Se debe llevar a cabo el control de cambios del proyecto, el cual implica un documento con la

descripción del cambio, impacto en tiempo y recursos, re-planificación y formalización de la aceptación del

cambio.

Además, se debe realizar el control de cronograma del proyecto y las reuniones de avance de

proyecto.

5. Cierre

Durante la última fase del proyecto, se debe realizar la evaluación por parte del cliente, el documento

de Aceptación de Entrega del proyecto, la documentación de las lecciones aprendidas, y la recopilación de

la documentación del proyecto, a través de una carpeta electrónica que contenga todos los documentos

generados en cada una de las fases.

Otro de los estándares impuestos por la organización para la ejecución del proyecto fue el Modelo

RAD (Rapid Application Development), el cual fue diseñado por James Martín y tiene como objetivo

disminuir radicalmente el tiempo necesario para diseñar e implementar sistemas de información. [Mendoza,

2002] El RAD cuenta con una participación intensa del usuario final en el diseño del sistema y el uso de

prototipaje el cual ayuda a los usuarios a visualizar y hacer ajustes al sistema.

El Rapid Application Development consta de 4 etapas, las cuales se describen a continuación:

a. Planificación de Requerimientos

La finalidad de esta fase es determinar cuales son los usuarios e interesados del sistema, para

poder conocer sus necesidades a través del levantamiento de la información y de esta forma establecer los

requerimientos funcionales y no funcionales del sistema.

b. Diseño

En esta fase se lleva a cabo el diseño del sistema y la construcción de un primer prototipo que será

evaluado por los usuarios del sistema. Dependiendo de los resultados, se realiza un refinamiento del

prototipo y el mismo es evaluado nuevamente. Este proceso iterativo, puede llevarse a cabo repetidas

veces, sin embargo, se debe tener cuidado de no caer en un ciclo que retarde el desarrollo del proyecto.

Se deben establecer límites en los requerimientos a cumplir.


18

c. Desarrollo

Durante esta fase básicamente se realiza la construcción del software a partir del prototipo

aprobado. Se deben realizar las pruebas al sistema según lo establecido en el plan de pruebas.

Luego de realizar las pruebas, se debe proporcionar adiestramiento a un grupo de usuarios y

ejecutar una prueba piloto para obtener retroalimentación por parte de los mismos.

En cuanto a la documentación del sistema, los entregables de esta fase deben ser el Manual del

Programador y el Manual de Usuario.

d. Implantación

Esta fase se concentra en proveer el adiestramiento masivo para los usuarios finales y la

implantación del producto en el ambiente de los mismos.

Este modelo de desarrollo sugerido por la institución posee algunas ventajas como son ahorro del

tiempo de desarrollo, estrecha correspondencia entre los requerimientos del usuario y las especificaciones

del sistema, y la rapidez de cambio en el diseño. Sin embargo, como todo modelo, también tiene

desventajas, siendo las más importantes la falta de apoyo para las tareas, actividades y artefactos así

como una propuesta arquitectónica para el sistema. Es por esto que surgió la necesidad de consultar otra

metodología (específicamente RUP - Rational Unified Process), la cual complementara el modelo RAD

sugerido por la institución.

Los aspectos tomados de RUP fueron los siguientes:

1. Para la etapa de Planificación de Requerimientos se decidió incluir la identificación de los riesgos

del sistema para establecer planes de mitigación y contingencia. El artefacto correspondiente es el Plan de

Riesgos.

2. Para la etapa de Diseño se decidió incluir la propuesta arquitectónica, la cual incluye modelo

conceptual, diseño lógico y físico de la base de datos, entre otros. El artefacto correspondiente

corresponde al documento de arquitectura.

3. También se tomó el enfoque de Casos de Uso que utiliza RUP para describir las funcionalidades

del sistema a partir de las interacciones con los usuarios.

Capítulo VI. Marco Tecnológico

19

CAPÍTULO VI. MARCO TECNOLÓGICO

En este capítulo se describen las diferentes herramientas utilizadas durante el desarrollo del proyecto

Helpdesk, tomando en cuenta aspectos de hardware, software, almacenamiento y comunicación.

VI.1. Hardware

Para el desarrollo del proyecto se contó con una computadora Pentium III con las siguientes

especificaciones:

- Procesador 733 Mhz.

- 128 MB de memoria RAM.

- Disco duro de 8 GB.

VI.2. Tecnología de Software

VI.2.1. Plataforma .NET

La plataforma .NET es una capa de software que se coloca entres el sistema operativo (SO) y el

programador, y que permite abstraer los detalles internos del SO. [Unai, 2002] Las características

fundamentales de .NET son: portabilidad pues puede ejecutarse en cualquier SO, multilenguaje porque

puede adaptar diversos lenguajes de programación e interoperabilidad entre diferentes trozos de código

escritos en diferentes lenguajes.

Microsoft define la plataforma .NET como "un entorno para la construcción, desarrollo y ejecución de

servicios Web y otras aplicaciones, que consta de 3 partes fundamentales: el Common Language Runtime,

las Framenwork Classes y ASP.NET"

El Common Language Runtime (CLR) es el entorno en el que se ejecutan las aplicaciones, las cuales

en lugar de compilarse a lenguaje de máquina, se compilan a un lenguaje intermedio llamado Microsoft

Intermediate Language (MSIL) que es el único lenguaje que entiende el CLR.

Las Framework Classes es un rico conjunto de clases, interfaces, tipos que simplifican y optimizan el

desarrollo de aplicaciones .NET además de proporcionar acceso a la funcionalidad del sistema. [Gracia,

2004]

ASP.NET es la parte más importante de la capa superior de la plataforma .NET. ASP.NET provee una

plataforma más robusta para el desarrollo de aplicaciones, y permite separar limpiamente la lógica de la

aplicación de la interfaz para que de esta forma el programador pueda centrarse exclusivamente en la


20

lógica de la aplicación. ASP.NET además incorpora los Servicios Web que permite a los desarrolladores

construir aplicaciones combinando recursos locales y remotos para una solución distribuida e integrada.

El sistema de Helpdesk fue desarrollado bajo ASP.NET y se utilizó ADO.NET que es un conjunto de

clases y proveedores de datos que permiten manipular bases de datos.

Figura 2. Las Capas de la Plataforma .NET

VI.2.2. Internet Information Services (IIS)

Para publicar las páginas Web creadas en ASP.NET, se utilizó Internet Information Services (IIS), el

cual es el servidor Web que provee Windows. Este servidor esta diseñado para publicar información tanto

en Internet, como en una Intranet. Adicionalmente IIS provee una plataforma que ofrece un alto rendimiento

para las aplicaciones creadas usando el Framework .NET de Windows, así como un completo nivel de

seguridad.

VI.2.3. Visual Studio.NET

La implementación y codificación del sistema se llevó a cabo en el ambiente provisto por Visual Studio

.NET que consiste en un paquete completo de herramientas de desarrollo suministrado por Microsoft para

ayudar a los desarrolladores a escribir de forma rápida y sencilla programas en la plataforma .NET. El


21

editor de Visual Studio .NET provee formas simples de generar código, llevar y quitar controles a las

páginas de forma fácil, compilar y construir la aplicación, etc. [Spider, 2004]

VI.2.4. Visual C#.NET

Como se mencionó anteriormente, una de las características fundamentales de la plataforma .NET es

el multilenguaje de la misma, es decir, la capacidad de adaptar diferentes lenguajes. El Visual Studio .NET

incluye los siguientes lenguajes: Visual Basic .NET, Visual C++ .NET, Visual C# .NET y Visual J# .NET.

Para la codificación del sistema se decidió utilizar Visual C# ya que es un lenguaje completo, orientado a

objetos, que se acopla perfectamente con el desarrollo Web y, además, es el que mejor se adapta a la

plataforma pues ha sido exclusivamente creado para trabajar sobre ella. [Unai, 2002]

VI.3. Manejador de Bases de Datos

Una base de datos es una serie de datos organizados y relacionados entre sí, los cuales son

recolectados y explotados por los sistemas de información de una empresa o negocio en particular.

Las bases de datos cuentan con un conjunto de programas conocido como Sistema Manejador de Base de

Datos (DMBS: Data Base Management System) el cual maneja todas las solicitudes formuladas por los

usuarios a la base de datos. Para el proyecto de Helpdesk, se utilizó el manejador de ORACLE, en su

versión 8i, el cual es un manejador de base de datos relacional que hace uso de los recursos del sistema

informático en todas las arquitecturas de hardware, para garantizar su aprovechamiento al máximo en

ambientes cargados de información. [Boso, 2003]

VI.4. Redes y Comunicación

VI.4.1. SharePoint Portal Server 2003.

Es una herramienta de colaboración que permite a las empresas desarrollar un portal inteligente que

conecta perfectamente usuarios, equipos y conocimiento para que las personas puedan aprovechar la

ventaja de compartir información relevante que les permita trabajar de una forma más eficiente a través de

los procesos empresariales. [Microsoft SharePoint, 2004]


22

VI.4.2. Exchange.

Para competir con éxito en el desafiante ambiente de negocios de hoy en día, las organizaciones

deben proporcionar a los trabajadores de la información eficientes formas de comunicarse y colaborar. El

correo electrónico actualmente es la tecnología de colaboración más ampliamente usada.

Exchange es el servidor de correo electrónico y colaboración de Microsoft diseñado para ayudar a los

negocios a comunicarse en forma más eficaz. Junto con la enriquecida funcionalidad de cliente

proporcionada por Microsoft Office Outlook, Exchange ofrece acceso móvil, remoto y de escritorio al correo

electrónico con avanzada seguridad y privacidad; alta confiabilidad y sorprendente rendimiento;

colaboración basada en el correo electrónico. [Microsoft Exchange, 2004]

Las características principales de Exchange son las siguientes:

• Seguridad y privacidad a través de listas de distribución restringidas a usuarios autentificados,

filtración para mensajes recibidos, virus scanning, permisos administrativos, transmisiones y envíos

restringidos entre otros.

• Ahorro de tiempo y mayor productividad con listas de distribución dinámicas, Exchange system

manager, herramientas para mover mensajes, etc.

Figura 3. Interacción de los componentes tecnológicos.

Capítulo VII. Desarrollo del Sistema

23

CAPÍTULO VII. DESARROLLO DEL SISTEMA

El presente capítulo tiene como finalidad presentar los resultados obtenidos la aplicar la metodología

definida para el desarrollo del Sistema Helpdesk, mostrando los artefactos elaborados en cada una de las

fases.

Como se explicó en el capítulo V, el IESA utiliza una metodología de Gerencia de Proyectos para llevar

un seguimiento del estado de los proyectos que se realizan. Esta metodología consta de 4 fases, según las

cuales se estructura este capítulo.

VII.1. Fase de Iniciación

Para cumplir con los objetivos de esta fase, se elaboró un documento llamado Plan de Proyecto según

el estándar de la empresa, el cual puede consultarse en el Apéndice B. En este documento de realiza el

planteamiento del problema y los objetivos del proyecto, por lo tanto sirvió de ayuda para la realización del

capítulo II del presente informe.

VII.2. Fase de Planificación

Durante esta fase se elaboró el Plan de Trabajo, que específica las actividades a realizar y los tiempos

estipulados para cada una de ellas. Esta información complementa el documento realizado en la fase de

definición y puede ser consultada en el Apéndice B.

VII.3. Fase de Ejecución

Según la metodología de Gerencia de Proyecto, esta fase se refiere a la ejecución del proyecto como

tal y se debe manejar independientemente cada proyecto, eligiendo la metodología de desarrollo de

sistemas más adecuada. Esta fase es medular en el proyecto, pues es en ella donde se llevan a cabo las

labores de ingeniería del producto. Para el proyecto Helpdesk, se seleccionó RAD y en esta sección se

explican los resultados obtenidos durante cada una de sus etapas.

Antes de comenzar con la etapa de planificación de requerimientos (primera etapa de RAD), es

importante comprender las actividades que se llevan a cabo en el negocio y de esta forma desarrollar un


24

sistema que de verdad permita cumplir los objetivos de la organización. Es por ello que, como un aporte

personal, se realizó un estudio del negocio en el cual se pretende insertar el nuevo sistema.

VII.3.1. Modelo del Negocio

El modelo de negocio permite modelar los procesos del negocio en estudio. Provee una vía para

expresar los procesos que se deben llevar a cabo para cumplir con los objetivos del negocio en términos

de actividades.

VII.3.1.1. Casos de Uso del Negocio

El modelo de casos de uso de negocio describe desde una perspectiva externa los procesos de

negocio.

El manejo eficiente de los incidentes reportados en el área de informática, tiene como principal objetivo

reestablecer el servicio normal de las operaciones que se vean afectadas por dichos incidentes. Esto se

logra mediante un proceso identificado durante esta fase, el cual se describe a continuación.

Lo primero que debe ocurrir es que algún miembro de la comunidad del IESA reporte, a través de los

medios disponibles, el incidente presentado; de esta forma el encargado de soporte lo registra y le da inicio

a la gestión de incidente.

Para comenzar, se debe investigar la causa del incidente para posteriormente encontrar una solución.

Esta solución puede implicar diferentes acciones como son acudir al sitio del incidente, aplicar

directamente la solución o contactar a los proveedores.

Un encargado de soporte acude al sitio del incidente cuando la solución encontrada requiere de

acciones que deben ser ejecutadas por la persona directamente en el lugar del hecho. Que una solución

sea aplicada directamente viene dado por el hecho de que la misma puede ser aplicada remotamente por

la persona de soporte o bien por la persona que reportó el incidente. Por último, es necesario contactar al

proveedor cuando se debe realizar algún reparo del equipo, cambiarlo o comprar uno nuevo.

Una vez solucionado el incidente, es importante confirmar la solución con el usuario que lo reportó, con

la finalidad de verificar su satisfacción. Adicionalmente, se le envía una encuesta para evaluar la

percepción del usuario en cuanto al servicio recibido.


25

Para la gerencia de informática es sumamente importante conocer el nivel de calidad del servicio

prestado, es por ello que se realizan periódicamente reportes estadísticos con el fin de tomar decisiones

que permitan mejorar el servicio.

Los actores del negocio identificados son el miembro de la comunidad, el encargado de soporte, el

proveedor y el gerente de informática.

En la Figura 4 se observa el diagrama correspondiente a los casos de uso del negocio.

Soporte

Proveedor

Miembro Comunidad

Gerente

Reportar Incidente

Registrar Incidente

Atender Reporte

Investigar Causa

Encontrar Solución

Acudir al Sitio

Contactar Proveedor

Aplicar Solución

Confirmar Solución

Enviar

Encuesta

Llenar Encuesta

Solicitar Reporte

Responder Solicitud

Evaluación del Incidente

Supervisar a los Soportes

Figura 4. Casos de Uso del Negocio

Luego de realizar el estudio del negocio, se procedió a llevar a cabo cada una de las etapas de RAD,

cuyos resultados se encuentran a continuación.

VII.3.2. Etapa de Planificación de Requerimientos

Según RAD, la primera etapa de desarrollo corresponde a la Planificación de Requerimientos, durante

la cual se realizaron reuniones, entrevistas y encuestas a los usuarios con la finalidad de establecer sus

necesidades y así definir los requerimientos del sistema.


26

VII.3.2.1. Determinación de Stakeholders y Usuarios

Luego de identificar los procesos de negocio, se procedió a identificar a los usuarios y stakeholders

(interesados) del sistema.

Los usuarios del sistema son los que interactúan directamente con el mismo. Pueden ser tanto

personas como otros sistemas.

Los Stakeholders de un sistema, son todos aquellos que poseen algún nivel de interés en el desarrollo

del mismo. Para el proyecto Helpdesk IESA, en general, los interesados son lo empleados que pertenecen

a la Gerencia de Informática y Telecomunicaciones, pues son los encargados de atender los incidentes que

se presentan en dicha área. Por otro lado, la comunidad del IESA también está interesada en este

desarrollo, pues les aportará beneficios y facilidades a la hora de reportar sus incidentes, y también son

stakeholders.

A continuación, se describen detalladamente cuáles son los usuarios y stakeholders del sistema

Helpdesk, mostrando una breve descripción de los mismos.

Resumen de Usuarios

Nombre Descripción

Cliente

Se refiere a la comunidad del IESA (estudiantes, egresados, empleados

administrativos, invitados, etc.) que utilizan el sistema para registrar y

consultar sus incidentes vía Web.

Soporte

Son los encargados del manejo de incidentes y problemas. Registran

incidentes de todos los clientes, reportados vía telefónica, por correo

electrónico o personalmente. Incluye a los analistas de soporte, analistas de

sistema y gerentes del área de informática.

Tabla 1. Resumen de Usuarios

Resumen de Stakeholders

Nombre Representante Descripción/Responsabilidad

Líder de Proyecto Paola Adrianza Supervisar el desarrollo y puesta en funcionamiento del

sistema.

Establecer hitos, entregables y plazos.


27

Gerente de

Informática

Nilzaris Cova Aprobar las decisiones propuestas.

Analista de Soporte Libia Bello Facilitar la información relevante sobre el manejo de

incidentes.

Evaluar el sistema.

Comunidad IESA Dulce Mogollón Empleada del departamento de Logística, evaluar el

sistema a través de la prueba piloto.

Tabla 2. Resumen de Stakeholders

VII.3.2.2. Necesidades de Usuarios

Las necesidades de los usuarios describen cuáles son los aspectos que ellos consideran deben ser

resueltos por el sistema. A continuación se describen las necesidades identificadas durante esta fase.

1. De la comunidad del IESA

1.1. Un medio más efectivo para registrar y consultar sus Incidentes.

1.2. Una manera sencilla de realizar la evaluación del servicio recibido.

2. De los analistas de soporte

2.1. Un método más efectivo que les permita llevar el control de los Incidentes reportados por la

comunidad.

2.2. Diversas formas de consultar los Incidentes, Errores Conocidos y Problemas.

2.3. Tener plasmadas las soluciones conocidas de forma que se comparta el conocimiento.

2.4. Facilitar la comunicación con el usuario para informar el estado de los incidentes.

2.5. Facilitar la asignación de Incidentes para su atención y posterior resolución.

2.6. Conocer las evaluaciones de los usuarios con respecto al servicio prestado.

2.7. Conocer las estadísticas de Incidentes, Errores Conocidos y Problemas, para poder tomar

decisiones de negocio.


28

VII.3.2.3. Requerimientos del Sistema

Basándose en las necesidades del usuario identificadas en el punto anterior, y en la información

recolectada mediante encuestas y entrevistas con los usuarios, se identificaron los requerimientos del

sistema.

Requerimientos Funcionales

R1. Manejar Incidentes

R1.1. Permitir el registro de Incidentes.

R1.2. Permitir la modificación de Incidentes.

R1.3. Permitir la consulta de Incidentes.

R1.3.1. Asociados a un analista.

R1.3.2. Asociados a un cliente.

R1.3.3. Por categoría.

R1.3.4. Por estado.

R1.3.5. Por fecha.

R1.3.6. Todos los incidentes.

R1.4. Generar notas de confirmación

R1.4.1. De creación del Incidente.

R1.4.2. De confirmación de solución del Incidente y encuesta.

R1.5. Generar notas de asignación

R1.5.1. De incidentes.

R1.5.2. De problemas.

R1.6. Enviar notas de confirmación al cliente.

R1.7. Enviar notas de asignación al analista.

R2. Manejar Problemas

R2.1. Generar el registro de Problemas.

R2.2. Permitir la modificación de Problemas.

R2.3. Permitir la consulta de Problemas.



R2.3.3. Por estado.


29

R2.3.4. Por fecha.

R2.3.5. Todos los problemas.

R2.4. Mantener la consistencia con los incidentes asociados.

R2.5. Llevar el registro del número de incidentes asociados.

R3. Manejar Errores Conocidos

R3.1. Generar el registro de Errores Conocidos.

R3.2. Permitir la modificación de Errores Conocidos.

R3.3. Permitir la consulta de Errores Conocidos.

R3.4. Mantener la consistencia con los incidentes y problemas asociados.


R4. Generar reportes

R4.1. Generar reportes estadísticos de Incidentes.

R4.2. Generar reportes estadísticos de Problemas.

R4.3. Permitir la visualización e impresión de los reportes.

R5. Manejar Evaluaciones

R5.1. Permitir el registro de evaluaciones.

R5.2. Permitir la consulta de evaluaciones.

R6. Manejar el acceso de usuarios

R6.1. Permitir el registro de usuarios.

R6.2. Permitir la modificación de usuarios registrados.

R6.3. Permitir la eliminación de usuarios registrados.

R6.4. Permitir el acceso a través de perfiles de usuarios.

R6.5. Iniciar sesión para un usuario válido.

R6.6. Cerrar sesión de un usuario.

R7. Tener comunicación con el Directorio Activo.

R8. Mostrar sugerencias de soluciones a Incidentes en caso de que existan.

R9. Manejar Solicitudes.

R9.1. Permitir el registro de solicitudes.

R9.2. Permitir la modificación de solicitudes.

R10. Permitir el control de las actividades realizadas.

R11. Permitir el registro de soluciones a problemas y errores conocidos.


30

Requerimientos No Funcionales

1. Requerimientos de seguridad:

1.1. Robustez.

1.2. Seguridad en Internet.

1.3. Límite de modificación.

2. Requerimientos de desempeño

2.1. Tiempos de respuesta.

3. Requerimientos de interfaz de usuario

3.1. Facilidad de uso.

3.2. Amigable.

3.3. Proporcionar ayuda.

4. Requerimientos de operación.

5. Requerimientos de respaldo y recuperación.

5.1. Tolerancia a fallas.

5.2. Disponibilidad.

6. Requerimientos de mantenibilidad.

6.1. Alta cohesión.

6.2. Bajo acoplamiento.

7. Requerimientos de desarrollo

7.1. Plataforma Web.

7.2. Intranet.

8. Requerimientos de documentación

8.1. Manual de Usuario.

8.2. Manual del Sistema.

En el Apéndice C se muestra detalladamente los requerimientos funcionales y no funcionales del

sistema Helpdesk. Para cada uno de los requerimientos se muestra una breve descripción. Para los

requerimientos funcionales se especifica la categoría y la prioridad del mismo. La categoría indica si la

función que satisface el requerimiento es oculta o evidente para el usuario mientras que la prioridad se

refiere al grado de importancia del requerimiento. Por otro lado, para los requerimientos no funcionales se

especifica la categoría del mismo, la cual indica si el requerimiento es opcional u obligatorio.


31

VII.3.2.4. Estudio Inicial de Riesgos

El estudio de los riesgos del sistema es un aspecto que no está considerado por RAD, por lo que fue

tomado de RUP como un aporte personal, debido a la importancia que representa identificar los factores

que puedan atentar contar el éxito del desarrollo. A continuación, en la tabla 3, se presentan los riesgos

identificados, los cuales indican las posibles situaciones que puedan afectar el desarrollo del proyecto.

Número Nombre Descripción

1 En cuanto a requerimientos y relación con

clientes y usuarios.

1.1 Cambios en los requerimientos.

Los clientes y usuarios realizan cambios constantes a los

requerimientos del sistema, ya sea por inclusión,

modificación o eliminación de requerimientos.

1.2 Requerimientos demasiado ambiciosos

para el tiempo disponible.

Los requerimientos del sistema no pueden ser cumplidos

en el tiempo establecido para el desarrollo del proyecto.

1.3 Expectativas irreales del cliente. Los clientes se crean expectativas que no se adaptan a la

realidad del producto desarrollado.

1.4 Poca disponibilidad de los usuarios

finales.

Los usuarios finales no están disponibles para realizar el

levantamiento de información y tienen poca o ninguna

participación en el desarrollo del sistema.

1.5 Rechazo del producto.

Una vez finalizado e implantado el producto, es rechazado

por los usuarios finales, debido a falta de entrenamiento,

miedo al cambio, etc.

2 En cuanto a la planificación, control y

seguimiento.

2.1 Planificación demasiado optimista.

La planificación de las actividades se realiza pensando que

todas las actividades se van a realizar sin dificultades y en

el tiempo exacto.

2.2 La planificación omite actividades

necesarias o las subestima.

Algunas actividades no se toman en cuenta durante la

planificación por considerarse innecesarias, o no se les

otorga la respectiva importancia.

2.3 Retrasos en la revisión de los avances del

proyecto.

La revisión, corrección y aceptación de los entregables se

realiza de forma muy lenta.


32

2.4 No se hace seguimiento de las tareas o

plan de actividades.

No se lleva un control de las actividades realizadas con

respecto a la programación establecida.

3 En cuanto a diseño e implementación.

3.1 Instalaciones de desarrollo no

disponibles.

No existen instalaciones (computadoras, redes,

herramientas de desarrollo, bases de datos, etc.) que

satisfagan las necesidades para establecer el ambiente de

desarrollo requerido por el proyecto.

4 En cuanto al uso de herramientas

4.1

La curva de aprendizaje para las

herramientas es más larga de lo

esperado.

La adopción de herramientas y tecnología nueva o

desconocida, puede resultar una labor larga y complicada

para el desarrollador.

Tabla 3. Lista de Riesgos.

El Apéndice D, corresponde al Plan de Riesgos, donde se indica con mayor detalle los riesgos

identificados. Para cada uno de ellos se muestra una breve descripción, magnitud, impacto y los

indicadores que permiten identificar la posible aparición del riesgo. Así mismo, se indican planes de

mitigación para reducir las posibilidades de aparición y planes de contingencia en caso de que el riesgo

aparezca.

VII.3.2.5. Modelo Inicial de Casos de Uso

Un modelo de casos de uso representa las funcionalidades del sistema a partir de las interacciones

con los usuarios, permitiendo identificar el comportamiento del sistema omitiendo su implementación.

Para representar las funcionalidades el sistema helpdesk, se realizó la identificación de actores y casos

de uso, así como la correspondencia entre ellos.

Actores del Sistema

Un actor del sistema representa las entidades externas que interactúan con el mismo, y son los

encargados de iniciar los casos de uso. Puede representar tanto personas como otros sistemas.

La tabla 4 muestra los actores identificados con una pequeña descripción de ellos.


33

Actor Descripción

Cliente Es la persona perteneciente a la comunidad del IESA que registra sus

incidentes vía Web. También se encargan de registrar las evaluaciones de

los incidentes.

Invitado Es una instancia del cliente y representa a la persona que no pertenece

directamente a la comunidad del IESA pero que eventualmente puede

registrar incidentes. Generalmente son personas que realizan cursos en la

institución.

Soporte Es la persona que pertenece a la gerencia de informática y se encarga del

manejo de incidentes, problemas y errores.

Coordinador Es una instancia del Soporte y representa a la persona encargada de recibir

los requerimientos de los clientes vía telefónica, correo y personalmente.

Además, está encargado de la asignación de incidentes y problemas a los

analistas.

Tabla 4. Actores del Sistema.

Casos de Uso

Un caso de uso define una secuencia de transacciones iniciadas por un actor y que constituye una

funcionalidad del sistema.

A continuación de muestra una lista de los casos de uso identificados, con una breve descripción.

1. General

1.1. Iniciar sesión: El usuario inicia su sesión en el sistema y tiene acceso a sus funcionalidades.

1.2. Cerrar sesión: El usuario finaliza su sesión y sale del sistema.

2. Manejar Incidentes

2.1. Registrar Incidente: El usuario introduce los datos solicitados para registrar un Incidente. El

usuario Cliente registra sus incidentes vía Web. EL usuario Soporte registra los Incidentes de

cualquier cliente reportados vía telefónica, correo electrónico o personalmente.

2.2. Modificar Incidente: El usuario modifica o complementa los datos del Incidente.

2.3. Consultar Incidente: El usuario consulta los Incidentes registrados en un período de tiempo. Esta

consulta puede estar clasificada por categoría, por estado, por cliente, por analista, por tipo, por


34

fecha y por prioridad. El Cliente solo puede consultar sus Incidentes, mientras que el Soporte

puede consultar todos los Incidentes.

2.4. Asignar Incidente: El usuario asigna un Incidente a otro usuario Soporte.

3. Manejar Problemas

3.1. Modificar Problema: El usuario modifica o complementa los datos del Problema.

3.2. Consultar Problema: El usuario consulta los problemas existentes. Esta consulta puede estar

clasificada por categoría, por estado, por encargado (persona que tiene asignado el problema y

debe solucionarlo), por fecha.

3.3. Asignar Problema: El usuario asigna un incidente a otro usuario tipo Soporte.

4. Manejar Errores Conocidos

4.1. Modificar Error Conocido: El usuario modifica o complementa los datos del Error Conocido.

4.2. Consultar Error Conocido: El usuario consulta los Errores Conocidos existentes. Esta consulta

puede estar clasificada por categoría, por fecha.

5. Manejar Evaluaciones

5.1. Registrar Evaluación: El usuario introduce los datos solicitados para realizar el registro de la

evaluación de un Incidente.

5.2. Consultar Evaluación: El usuario consulta los datos de la Evaluación realizada al Incidente.

6. Manejar Solicitudes

6.1. Registrar Solicitud: El usuario Helpdesk introduce los datos solicitados para realizar el registro de

los procedimientos que son considerados como solicitudes.

6.2. Modificar Solicitud: El usuario modifica los datos de las solicitudes registradas.

6.3. Consultar Solicitud: El usuario consulta los datos de las solicitudes registradas.

7. Manejar Soluciones

7.1. Registrar solución: El usuario introduce los datos necesarios para realizar el registro de una

solución para un Error Conocido.

7.2. Consultar solución: El usuario consulta los datos de las Soluciones registradas.

7.3. Buscar Solución: El usuario busca en la base de conocimientos una solución al incidente.

8. Control de Solicitudes

8.1. Registrar actividades realizadas: El usuario registra la actividad realizada para un incidente de tipo

solicitud.

8.2. Consultar actividades realizadas: El usuario consulta el estado de los incidentes de tipo solicitud.


35

9. Reportes

9.1. Generar reporte: El usuario puede generar reportes estadísticos de incidentes, errores y

problemas.

9.2. Imprimir reporte: El usuario puede imprimir el reporte generado.

10. Manejo de Usuarios

10.1. Crear Usuario: El usuario introduce los datos para registrar un nuevo usuario al sistema.

10.2. Modificar Usuario: El usuario modifica los datos de los usuarios del sistema.

10.3. Eliminar Usuario: El usuario elimina usuarios del sistema.

11. Manejar Categorías

11.1. Crear categoría: El usuario crea una nueva categoría de incidente.

11.2. Modificar categoría: El usuario modifica una categoría de incidente.

La figura 5 muestra el diagrama de casos de uso donde se especifica la interacción de los actores con

cada caso de uso. Para facilitar el entendimiento del diagrama, se agruparon por colores los casos de uso

relacionados.

Figura 5. Diagrama de Casos de Uso


36

VII.3.2.6. Glosario de Términos

El glosario de términos del sistema es un documento que permite definir todos aquellos conceptos

utilizados en el desarrollo del proyecto y que puedan resultar no familiares al lector de cualquiera de los

documentos presentados. Este documento se encuentra en el Apéndice E

Una vez culminada la Fase de Planificación de Requerimientos, se llevó a cabo la siguiente fase

establecida por la metodología RAD, denominada Etapa de Diseño.

VII.3.3. Etapa de Diseño

En esta sección se presentan los documentos, modelos y diagramas elaborados durante la segunda

etapa de desarrollo que corresponde a la Etapa de Diseño.

VII.3.3.1. Especificación de Casos de Uso

En la fase de diseño, la primera actividad realizada fue establecer la especificación de los casos de

uso, donde se muestran con mayor detalle la secuencia de eventos necesarios para completar un proceso.

En el Apéndice F se presenta la especificación de cada uno de los casos de uso, la cual incluye

actores principales, precondiciones y poscondiciones, referencias cruzadas y los cursos de eventos

normales y alternos. Un ejemplo de esta descripción se muestra en la figura 6.


37

Figura 6. Especificación Caso de Uso: Iniciar Sesión

Para facilitar la comprensión de los Casos de Uso del sistema, se elaboraron los Diagramas de

Secuencia, los cuales explican la comunicación de los actores con el sistema. Estos diagramas se pueden

observar en el Apéndice G.

VII.3.3.2. Arquitectura del Software

La arquitectura de un software es el diseño de más alto nivel de la estructura del sistema y tiene la

responsabilidad de definir los módulos principales del sistema y la interacción entre dichos módulos. Es el

resultado de acoplar un cierto número de elementos arquitecturales en alguna forma adecuada para

satisfacer los principales requerimientos de funcionalidad y rendimiento del sistema. Es por esto, que la

definición de la arquitectura representa la actividad más importante de la fase de diseño.


38

Estas abstracciones de diseño son materializadas en forma de diagramas para facilitar su visualización

y entendimiento. Para representar los diagramas se utilizó el lenguaje de modelado UML (Unified Model

Language).

La arquitectura del Sistema Helpdesk está representada por el “Modelo 4+1 Vistas” propuesto por

Kruchten en 1995. [Kruchten, 1995] Este modelo organiza la descripción de la arquitectura usando cinco

(5) vistas concurrentes, cada una de las cuales está dirigida a un conjunto específico de conceptos. Se

utilizan cuatro (4) vistas para exponer las decisiones de diseño y la quinta vista para ilustrar y validar dichas

decisiones.

En la siguiente figura se muestra la interacción entre las vistas: Lógica, Proceso, Desarrollo, Física y

Casos de Uso.

Figura 7. Diagrama 4+1 vistas.

VII.3.3.2.1. Vista Lógica

Esta vista soporta los requerimientos funcionales del sistema, describe lo que el sistema puede ofrecer

a los usuarios finales. [Kruchten, 1995]

Para esta vista se realizó el Modelo Conceptual, el Modelo Entidad – Relación y el Diagrama de

Clases.

VII.3.3.2.1.1. Modelo Conceptual

El Modelo Conceptual permitió identificar los conceptos significativos en el dominio del sistema y

representarlo gráficamente. Este modelo se muestra en la figura 8.


39

Figura 8. Modelo Conceptual.

VII.3.3.2.1.2. Modelo Entidad – Relación

Un Modelo Entidad Relación (ER) describe los datos como entidades, relaciones y atributos. La entidad

es el objeto básico del ER y representa a un objeto del mundo real que tiene existencia independiente, bien

sea físico o conceptual. Los atributos son las propiedades particulares que describen a las entidades.

Finalmente estas entidades con sus diferentes atributos tienen asociaciones entre sí las cuales son

representadas a través de relaciones. [Elmasri y Navathe, 1997]

Como en la actualidad el proceso de manejo de incidentes se lleva a cabo de forma manual, fue

necesario diseñar completamente la base de datos que permitiera almacenar de forma persistente la

información necesaria para soportar las funcionalidades del sistema (Casos de Uso) y de esta forma

satisfacer los requerimientos del mismo. En la figura 9 se muestra el Modelo ER elaborado.


40

Figura 9. Modelo Entidad-Relación

Luego de elaborar el modelo entidad relación, el mismo se tradujo a Modelo Relacional. El cual se

muestra en la figura 10. El modelo relacional representa la base de datos como una colección de

relaciones. Si visualizamos una relación como una tabla de valores, cada fila de la tabla representa una

colección de valores de datos relacionados entre sí. Dichos valores se pueden interpretar como hechos

que describen una entidad o un vínculo entre entidades del mundo real. [Elmasri y Navathe, 1997]


41

Figura 10. Modelo Relacional

En el Apéndice H se encuentra el Diccionario de Datos del Modelo Relacional en el cual se explica

detalladamente cada una de las entidades y sus atributos.

VII.3.3.2.1.3. Diagrama de Clases

El diagrama de clases describe gráficamente las especificaciones de las clases de software y de la

interfaces en una aplicación. Normalmente contiene la siguiente información: [Larman, 1999]

• Clases, asociaciones y atributos.

• Interfaces con sus operaciones y constantes.

• Métodos.

• Información sobre los tipos de atributos.

• Navegabilidad.


42

• Dependencias.

En la figura 11 se puede observar el diagrama de clases elaborado para el sistema HelpDesk.

Figura 11. Diagrama de Clases.


43

VII.3.3.2.2. Vista de Procesos

La vista de procesos describe la descomposición del sistema desde el punto de vista de hilos y

procesos. Toma en cuenta algunos requerimientos no funcionales, tales como rendimiento y disponibilidad,

apuntando a problemas de concurrencia y distribución, de integridad del sistema, de tolerancia a fallos, y

de cómo las abstracciones principales desde la vista lógica encajan dentro de la arquitectura de proceso.

[Kruchten, 1995]

El sistema HelpDesk está basado en tecnología Web, y los usuarios pueden acceder de forma

simultánea a la misma información; los encargados de manejar los aspectos de acceso a recursos y

recuperación de fallas son el servidor Web IIS y el manejador de base de datos quienes controlan y

atienden de manera transparente las peticiones y solicitudes realizadas por los usuarios. Es por tal motivo

que el problema de concurrencia no forma parte del estudio de este proyecto, y por lo tanto no es

necesario describir la vista de procesos.

VII.3.3.2.3. Vista de Desarrollo

Esta vista muestra el ambiente de funcionamiento del sistema y describe la organización estática del

software en el ambiente de desarrollo.

Para el Sistema Helpdesk se decidió implementar la arquitectura de Cliente/Servidor de Tres Capas,

con el fin de mantener cada componente tan separado como sea posible. Las capas que conforman esta

arquitectura son la de presentación, lógica de aplicación y repositorio de datos. A continuación se presenta

una descripción de cada una de estas capas:

Capa de Presentación: Agrupa elementos de software que tienen que ver con interfaces e interacción

con el usuario. Dado que el sistema esta concebido como una aplicación Web, esta capa está constituida

por páginas web HTML estáticas o dinámicas (ASPX). Algunas de ellas contienen funcionalidades locales

propias de interfaz implementadas en JavaScript.

Capa de Aplicación: Agrupa los elementos de software que automatizan o apoyan los procesos el

negocio que llevan a cabo los usuarios a través de la Capa de Presentación. Está constituida por una

colección de Clases de C# adecuadamente agrupadas en paquetes. Toda la funcionalidad, semántica y

validaciones del sistema están implementadas en esta capa.


44

Capa de Repositorio: Agrupa elementos que tienen que ver con el manejo de datos persistentes, que

en el caso particular de este sistema se encuentran en una Base de Datos implementada en el manejador

de Oracle 8i.

Adicionalmente se cuenta con un Mediador de Base de Datos, que es una clase de C# utilizada para

acceder de manera transparente a los datos y es el encargado de comunicar la capa de aplicación con la

de repositorio.

Figura 12. Arquitectura 3 Capas

VII.3.3.2.4. Vista Física (o Implantación)

Esta vista representa un mecanismo que permite comprender la distribución física del conjunto de

nodos del sistema, ilustrando la distribución de procesamiento a lo largo de dichos nodos y la ubicación

física de las instancias de componentes en la infraestructura concreta de producción.

Con esta vista se pretende describir los recursos de hardware y software necesarios para la

implantación del sistema. A continuación se presentan las recomendaciones de configuración para los

equipos del lado del cliente y del lado del servidor, tanto a nivel de software como de hardware.


45

Del lado del cliente:

Hardware:

• Procesador Pentium o superior.

• 32 Mb de memoria RAM.

• Modem de 56k o tarjeta de red con conexión a la red local.

Software:

• Windows 98 o superior.

• Internet Explorer 6.0

Del lado del servidor:

Hardware:

• Procesador Pentium III

• 256 Mb de memoria RAM.

• Tarjeta de red superior a 10 Mbps.

Software:

• Windows 2000 Server.

• Internet Information Services (IIS)

• Oracle 8i.

VII.3.3.2.5. Vista de Casos de Uso

Esta vista constituye la unión de las cuatro vistas descritas anteriormente. A través de ella se describen

los escenarios o casos de uso que representan una funcionalidad central o que abarca gran parte de la

arquitectura. Los Casos de Uso facilitan la identificación de las interfaces críticas, ayudan a concentrarse

en problemas concretos, además de demostrar y validar las otras vistas arquitecturales. Esta vista contiene

los casos de uso o escenarios claves para el desarrollo del sistema, y los diagramas de interacción (de

secuencia).

La vista de casos de uso es redundante en unión con la otras vistas (por eso es la vista “+1”), sin

embargo tiene dos propósitos principales: [Kruchten, 1995]

• Actuar como una guía para descubrir los elementos arquitectónicos durante el diseño de la

arquitectura.

• Actuar en el rol de validación e ilustración una vez que el diseño de la arquitectura haya

concluido.


46

En el presente proyecto se incluye el modelo de casos de uso del sistema que se encuentra en la

figura 5 de la fase de planificación de requerimiento. La descripción de los actores del sistema se

encuentra en la tabla 4 de planificación de requerimiento, y la descripción detallada de los casos de uso se

encuentra en el Apéndice F. Por otro lado, los diagramas de secuencia elaborados para el sistema

HelpDesk se presentan en el Apéndice G.

VII.3.3.3. Diseño Creativo

El proyecto a desarrolla es un sistema de Helpdesk para la Gerencia de Informática del IESA, por lo

que los usuarios del mismo serán los miembros de la comunidad de la empresa (incluye empleados,

profesores y estudiantes). Por esta razón se decidió que el sistema debe presentar la información de forma

sencilla, clara y concisa, con interfaces intuitivas y amigables, de forma tal que los usuarios se sientan

cómodos y familiarizados.

Para manejar el aspecto se seguridad y autentificación de usuarios, se decidió que el ingreso al

sistema se hará utilizando el mismo nombre de usuario y contraseña que utilizan actualmente los miembros

de la comunidad del IESA para conectarse a la Intranet, evitando así que los usuarios deben memorizar

diferentes nombres de usuario. Para facilitar aún más el ingreso al sistema, los usuarios no deben

proporcionar su nombre de usuario y contraseña cada vez que deseen ingresar al sistema, pues el sistema

lo tomará directamente del la máquina que hace la petición.

El diseño del sistema debe seguir los estándares del IESA en cuanto a colores, formato de las letras,

disposición y manejo de la información, entre otros. Los colores definidos por el estándar son azul claro y

blanco para todo el sitio, y letras en negro tipo Verdana. Se debe colocar el menú en el lado izquierdo de la

pantalla, ocupando ¾ de la misma aproximadamente, y toda la información en el lado derecho.

Para facilitar la navegabilidad del sistema, el menú no debe tener más de un nivel de profundidad y se

deben agrupar las funcionalidades similares como registros, consultas, etc. Además, se debe colocar titulo

a cada página, el cual indique en que sección del sistema se encuentra el usuario.

Para favorecer la mantenibilidad del sistema, las páginas y componentes se encuentran clasificados en

carpetas y se desarrollaron menús dinámicos de acuerdo a la funcionalidad del usuario dentro del sistema.

Debido a que el sistema debe ser lo más amigable y sencillo posible, es necesario que el lenguaje

utilizado en las páginas sea conocido por los usuarios. Este aspecto es un poco complicado de satisfacer

en el sistema HelpDesk ya que los términos utilizados deben corresponde con los expuestos por ITIL.


47

En la figura 13 se observa el mapa de navegación general de la aplicación, en el mismo se muestran la

opciones principales que tiene el usuario cuando accede la página inicial del sistema.

Figura 13. Mapa de Navegación General

VII.3.4. Etapa de Desarrollo

Siguiendo con el modelo RAD, durante la etapa de construcción se realiza la construcción del software

a partir del prototipo aprobado. En esta sección se presentan los artefactos obtenidos durante esta etapa,

los cuales son mapa de navegación, descripción del funcionamiento del sistema y el manual de usuario.

VII.3.4.1. Mapa de Navegación.

En base a la información recabada en las etapas anteriores, se procedió a realizar el Mapa de

Navegación Completo del Sistema HelpDesk. Este mapa tiene como finalidad mostrar como los usuarios

pueden navegar a través del sitio. En la figura 14 se presenta la navegación general de todos los usuarios

y en el Apéndice I el mapa de navegación fue dividido de acuerdo a los tipos de usuarios ya que cada uno

de ellos posee distintas funcionalidades.


48

Figura 14. Mapa de Navegación Completo del Sistema HelpDesk.

VII.3.4.2. Descripción del Funcionamiento del Sistema.

En esta sección se describe las funcionalidades del sistema que se encuentran actualmente

implementadas, utilizando como base las pantallas del sistema. El sistema está basado en perfiles de

usuario, y dependiendo del tipo de usuario que ingrese, ofrece diferentes funcionalidades. A continuación

se explican las funcionalidades disponibles para cada tipo de usuario.

VII.3.4.2.1. Funciones para Usuario Cliente

Los usuarios tipo Cliente son los miembros de la comunidad del IESA (profesores, estudiantes,

empleados administrativos), y para ellos el sistema presenta las siguientes funcionalidades:

• Registro y consulta de incidentes.

• Registro y consulta de evaluaciones.


49

Al ingresar a la página del sistema HelpDesk, los usuarios podrán observar en el lado izquierdo de la

pantalla, el Menú Principal, el cual permite acceder a las diferentes funcionalidades del sistema, y en el

lado derecho una pequeña lista de las actividades que puede realizar. En la figura 15 se muestra la página

de inicio.

Figura 15. Pagina de Inicio para Cliente

El sistema cuenta con dos módulos básicos, el Módulo de Registros y el Módulo de Consultas.

Módulo de Registros

En el módulo de Registros es posible realizar el registro de los incidentes que presenta el usuario en el

área de informática y el registro de la evaluación que realiza el usuario sobre el servicio de atención

recibido por parte del grupo de soporte técnico. En la figura 16 aparece la página de registro de incidentes.

Para el registro de incidente se solicitan los datos del usuario y las características del incidente. Se pueden

registrar incidentes de varios tipos: solicitudes y fallas, y para cada uno de ellos se solicita información

diferente pero siempre en la misma página.


50

Figura 16. Página de Registro de Incidentes para Clientes.

Luego de que el incidente reportado por el cliente sea resuelto por el grupo de soporte técnico, el

cliente debe llenar una evaluación del servicio recibido. En la figura 17 se muestra la página de registro de

evaluaciones.

Módulo de Consultas

En el módulo de consultas, los usuarios pueden observar todos los incidentes y evaluaciones que

hayan registrado en el sistema. Un ejemplo de la página de consulta se muestra en la figura 18. El usuario

puede configurar la búsqueda seleccionando las características del incidente que desea consultar.


51

Figura 17. Página de Registro de Evaluaciones.

Figura 18. Página de Consulta de Incidentes.

VII.3.4.2.2. Funciones para Usuario Soporte

Los usuarios tipo soporte son aquellos que pertenecen al grupo de informática (empleados

pertenecientes a la gerencia de informática) y que de alguna forma brindan el servicio de soporte técnico a

la comunidad del IESA. Existen varios niveles de soporte pero todos tienen acceso a las mismas

funcionalidades del sistema.


52

Al igual que los usuarios cliente, los usuarios soporte encuentran en la página de inicio el menú

principal del lado izquierdo y la lista de actividades que pueden realizar en el lado derecho de la pantalla.

En la figura 19, aparece la página de inicio para este tipo de usuarios.

Figura 19. Página de Inicio para Soporte.

El sistema cuenta con cuatro módulos principales: Registro, Consultas, Control de Actividades y

Administrativo. A continuación, se explicará en detalle como utilizar cada uno de estos módulos.

Módulo de Registros

A diferencia de los clientes, los usuarios soporte solo pueden realizar el registro de los incidentes que

son reportados por los clientes vía telefónica, por correo electrónico o personalmente. Los datos solicitados

al usuario soporte son mayores a los solicitados a los clientes y en la figura 20 se muestra la página de

registro de incidentes para los usuario soporte. El registro de Incidentes consta de dos partes obligatorias

que son Datos del Usuario y Datos del Incidente y una parte opcional que es Soluciones Sugeridas. Al final

de la página se muestra una lista con los incidentes registrados en el mes, que aún no han sido resueltos.

Módulo de Consultas

En el módulo de consultas, los usuarios pueden observar todos los incidentes y evaluaciones que

hayan registrado en el sistema, al igual que los usuarios Cliente, pero además se incluye la consulta de

Errores Conocidos y Problemas. El usuario puede configurar la búsqueda seleccionando las características


53

deseadas. A partir de la página de consulta el usuario puede seleccionar un error conocido o un problema y

actualizarlo. Un ejemplo de esto se muestra en la figura 21.

Figura 20. Página de Registro de Incidentes para Soporte.

Módulo de Control de Actividades

Este módulo permite llevar el control de las solicitudes hechas al grupo de soporte y consta de dos

partes. En la primera parte se muestra un cuadro que resume todos los incidentes pertenecientes a un tipo

de solicitud y en que actividad del procedimiento de la solicitud se encuentra. Además muestra el nombre

de la persona que ejecutó cada una de las actividades. En la figura 22 se muestra el cuadro para una

solicitud de instalación de equipo. La segunda parte del módulo consiste en la actualización de las

actividades realizadas para un incidente específico, es decir, registrar la persona que realizó alguna de las


54

actividades del procedimiento definido para la solicitud. En el momento en que se registra una actividad

como realizada, se envía automáticamente un correo electrónico al responsable de realizar la siguiente

actividad. En la figura 23 aparece la página de registro de actividades realizadas.

Figura 21. Página de Actualización de Problemas.

Figura 22. Página de Control de Solicitudes.

Incidente Responsable

Actividad


55

Figura 23. Página de Actualización de Actividades Realizadas.

Módulo Administrativo

Por último de presenta el Módulo Administrativo que contempla básicamente las actividades

administrativas del sistema como son el manejo de las categorías de clasificación de incidentes, problemas

y errores conocidos, el manejo de procedimientos de solicitudes y el manejo de usuarios.

VII.3.4.3. Estado Actual.

Actualmente, el sistema Helpdesk se encuentra parcialmente implementado, aproximadamente un 80%

de la aplicación, sin embargo, se continua con el desarrollo del proyecto y se estima que en dos meses y

medio el sistema esté totalmente implementado e implantado en la Gerencia de Informática del IESA,

estando a disposición de la comunidad de la empresa.

Para que los empleados de la Gerencia de Informática puedan aprovechar al máximo los servicios que

proporciona el sistema, de debe completar el desarrollo del mismo, al cual le falta el Módulo de Reportes.

Este módulo consiste en obtener estadísticas de forma tal que se puedan sacar conclusiones sobre el

comportamiento de la institución en cuanto a incidentes, y generar reportes que apoyen la toma de

decisiones por parte de la gerencia. Los problemas presentados, por los cuales no se implementó este

módulo, fue básicamente el hecho de que en la empresa no se cuenta con un formato definido para los


56

reportes, además de que su implementación requería del estudio de herramientas, el cual no fue

contemplado en un principio y no se pudo ajustar al tiempo total establecido para el desarrollo.

VII.3.4.4. Manual de Usuario.

El Manual del Usuario es un documento que permite comprender y aprender la navegación y utilización

de las diferentes páginas del sistema de una forma fácil y rápida.

Debido la gran cantidad de usuarios del sistema, se decidió colocar el manual en línea, con el fin de

que el mismo esté a disposición de todos, además de recortar gastos de impresión.

El manual desarrollado durante esta fase toma en cuenta todos los tipos de usuarios que pueden

acceder al sistema y todas las funcionalidades desarrolladas hasta el momento y puede ser consultado en

el Apéndice J. En el mismo se muestran las pantallas del sistema para guiar de forma al usuario hacia la

compenetración con el sistema de forma más sencilla.

VII.3.5. Etapa de Implantación

El objetivo de la etapa de implantación es poner en funcionamiento el sistema desarrollado. El proceso

de implantación incluye la instalación del sistema, la documentación del mismo y el adiestramiento a los

usuarios.

Como se explicó anteriormente, el sistema no se encuentra 100% funcional por lo que aún no se ha

podido llevar a cabo una instalación total del sistema, sin embargo, se está llevando a cabo una instalación

en paralelo. Una instalación en paralelo consiste en operar el nuevo sistema junto con el sistema anterior,

pero como la Gerencia de Informática del IESA no contaba con un sistema automatizado de registro de

incidente, el proceso se sigue llevando a cabo mediante un archivo Excel.

En cuanto al adiestramiento de usuarios, el mismo se llevó a cabo solo con los usuarios tipo soporte

que son los que en este momento están comenzando a utilizar el sistema, a través de pruebas piloto.

VII.4. Fase de Control y Seguimiento

Para llevar a cabo el control y seguimiento del desarrollo del proyecto, tal y como lo establece la

metodología de Gerencia de Proyectos, se llevaron a cabo las siguientes actividades:


57

• Reuniones semanales con el líder del proyecto para verificar los avances del proyecto y el

cumplimiento del plan de proyecto.

• Presentaciones sobre los avances del sistema a los usuarios tipo soporte, que son los usuarios

principales del sistema.

• Comunicación vía correo electrónico entre los integrantes del grupo de trabajo.

VII.5. Fase de Cierre

La fase de Cierre no se llevó a cabo ya que el proyecto aún no ha finalizado, sin embargo se realizó la

entrega de la carpeta electrónica con todos los artefactos obtenidos en cada una de las fases.

Capítulo VIII. Análisis de Resultados

58

CAPÍTULO VIII. ANÁLISIS DE RESULTADOS

El presente capítulo muestra un breve análisis de los resultados obtenidos una vez finalizado el

período de pasantía.

Luego de culminar el período de pasantía en el IESA, se obtuvo un sistema que se encuentra

implementado casi en su totalidad (85%), el cual cumple con los estándares de la institución y con los

requerimientos funcionales y no funcionales definidos en la etapa de Planificación de Requerimientos. Esto

podría indicar que se logró el objetivo principal del proyecto. Sin embargo, es de vital importancia

determinar si fueron alcanzados todos los objetivos específicos planteados durante la fase de Definición, es

por ello que a continuación se muestra una tabla que resume los objetivos del proyecto y la evidencia o no

de su cumplimiento.

Objetivos Específicos Evidencia de Cumplimiento

Desarrollar una aplicación en plataforma Web

� En el capítulo de Marco Tecnológico se explica que

para el desarrollo de la aplicación se utilizó la plataforma

.NET, la cual está definida como un entorno de desarrollo

para servicios Web. Además, en la descripción de la

arquitectura, realizada durante la etapa de diseño, se

explica que el sistema está basado en tecnología Web.

Manejar diferentes perfiles de usuarios.

� A través del diagrama y la especificación de los casos

de uso, realizados durante la etapa de diseño, se puede

observar que el sistema maneja dos tipos de usuario para

los cuales ofrece diferentes funcionalidades.

Incorporar un nuevo canal de comunicaciones

con la gerencia, que permita la realización de

solicitudes de soporte vía Web, bien sea por

fallas del servicio o por solicitud del mismo.

� Al desarrollar el sistema en ambiente Web, se

incorpora este nuevo mecanismo de comunicación. El

caso de uso Registra Incidente como Cliente, describe

como el cliente utiliza este mecanismo.

Capítulo VIII. Análisis de Resultados

59

Generar una base de conocimientos de las

soluciones a los problemas presentados.

� El proceso de trazabilidad entre incidente, problema,

error conocido explica como se genera esta base de

conocimientos. Con los casos de uso Modificar Problema,

Modificar Error Conocido y Registrar Solución se

evidencia como a medida que se resuelven los

incidentes, se va generando esta base de conocimientos.

Incorporar un proceso de evaluación del

servicio por parte del cliente, realizando las

encuestas de manera automática.

� Con caso de uso Registrar Evaluación, donde el actor

principal es el usuario Cliente, se evidencia el

cumplimiento de este objetivo.

Diseñar e implementar un repositorio de

datos que soporte las tareas a realizar por la

aplicación.

� En la fase de diseño se expone el modelo Entidad –

Relación que representa el diseño de la base de datos

que soporta las funcionalidades del sistema.

Para el perfil de cliente, permitir realizar el

registro de incidentes y solicitudes a través de

la aplicación, consultar el estado de los

mismos.

� Las funcionalidades que ofrece el sistema para este

perfil de usuario, muestran como los clientes pueden

realizar las actividades establecidas por este objetivo.

Para el perfil de soporte, permitir el registro,

modificación y consulta incidentes y

solicitudes, y realizar el registro de las

soluciones encontradas a los problemas.

Además, generar reportes estadísticos de los

problemas.

� Las funcionalidades disponibles para este perfil de

usuario, muestran como los soportes pueden realizar las

actividades establecidas por este objetivo.

� Con respecto a la generación de reportes, este es un

objetivo que no se logró alcanzar dado que el módulo de

reportes del sistema no fue implementado.

Tabla 5. Cumplimiento de Objetivos Planteados.

De los resultados expuestos, se puede concluir que el proyecto fue exitoso pues se lograron cumplir la

mayoría de los objetivos propuestos.

Capítulo IX. Conclusiones y Recomendaciones

60

CAPÍTULO IX. CONCLUSIONES Y RECOMENDACIONES

En este capítulo se exponen las conclusiones obtenidas una vez finalizado el desarrollo del proyecto y

culminado el período de pasantía, las cuales abarcan tanto el ámbito técnico como el organizacional y el

personal. Adicionalmente, se proponen ciertas recomendaciones que podrían aumentar los beneficios del

producto desarrollado.

IX.1. Conclusiones

• La introducción de los conceptos propuestos por la Librería de Infraestructura de Tecnología de

Información (ITIL) sobre la Gestión de Servicios, permitieron a la organización aplicar las mejores prácticas

para organizar la Gestión de Servicios y de esta manera aumentar la calidad de los mismos así como la

satisfacción de los clientes.

• El uso combinado de la metodología de Gerencia de Proyectos del IESA y el modelo RAD (Rapid

Application Development) para el desarrollo del proyecto permitió contemplar todos los aspectos

importantes para el desarrollo de sistemas. La Gerencia de Proyectos proveyó un enfoque disciplinario

para control de la evolución del proyecto y RAD permitió desarrollar el sistema en pequeñas actividades

que a la final darían como resultado un sistema completo e íntegro.

• La arquitectura definida para el sistema permite la escalabilidad del sistema y facilita la

mantenibilidad de cada uno de sus componentes.

• Visual Studio .NET y la plataforma .NET, proporcionan una completa herramienta, eficaz y

sofisticada, para diseñar, desarrollar, depurar e implementar aplicaciones seguras para Windows y bajo

plataforma Web, a la vez sólidas y fáciles de utilizar.

• Mediante la generación de la base de conocimientos, se introduce la gestión del conocimiento,

facilitando la publicación, y la localización del conocimiento explícito, y la captura del conocimiento tácito,

haciéndolo permanente en el tiempo.

• El sistema de HelpDesk desarrollado para la Gerencia de Informática del IESA, representa una

mejora significativa de los servicios que presta dicha gerencia en relación al soporte de los servicios de

informática, ya que además de recortar distancias entre los empleados de Informática y el resto de la

comunidad, permite automatizar los procesos que anteriormente se llevaban manualmente y consolidar

toda la información manejada en una base de datos que le diera persistencia a los datos.

Capítulo IX. Conclusiones y Recomendaciones

61

• El desarrollo de este proyecto significó una gran experiencia a nivel personal ya que no solo brindó la

oportunidad de poner en práctica los conocimientos adquiridos durante la carrera, sino también permitió el

aprendizaje de nuevas herramientas, tecnologías y lenguajes de programación. Además representó el

primer paso para entrar en contacto con el ámbito laboral.

IX.2. Recomendaciones

• Se recomienda primordialmente la culminación del Módulo de Reportes donde se generen todos los

reportes necesarios para proveer información relevante para la gerencia y que apoye las decisiones de

negocio. Para ello es fundamental que se defina el formato de los reportes así como los datos estadísticos

considerados como relevantes.

• El sistema en un futuro debería permitir el registro del horario de coordinación de cada uno de los

analistas de soporte para períodos determinados.

• Debido a los problemas metodológicos encontrados con el modelo RAD, se recomienda a la

institución adoptar RUP como metodología de desarrollo, ya que ésta captura las mejores prácticas del

desarrollo moderno de software, de manera que resulta muy ventajoso su uso para un gran rango de

proyectos. También se recomienda porque provee un enfoque disciplinario para asignar tareas y

responsabilidades y provee un camino metódico y sistemático para desarrollar, diseñar y validar una

arquitectura. Además, RUP asegura la producción de software de calidad, que reúna las necesidades de

los usuarios finales.

Referencias Bibliográficas

62

REFERENCIAS BIBLIOGRÁFICAS

1. [IESA, 2004] Instituto de Estudios Superiores Administrativos. Disponible en: http://www.iesa.edu.ve

2. [IESA, 1990] "IESA 25 Años, Fundación IESA"

3. [Carrion, 2004] Carrión, Juan. "Gestión del Conocimiento". Disponible es:

http://www.gestiondelconocimiento.com/conceptos_gestion_del_conocimiento.htm

4. [García, 2002] García Javier A. "Intranets wireless: colaboración y teletrabajo desde terminales

móviles". Disponible en: http://www.idg.es/iworld/articulo.asp?id=128888

5. [Van Bon, 2004] Van Bon, Jan. "Gestión de Servicios TI, una introducción a ITIL". Disponible en:

http://en-old.itsmportal.net/content/literatuur/boek/98.xml

6. [Telindus,2003] Telindus. "Servicios de Gestión". Disponible en:

http://www.telindus.es/soluciones+y+servicios/servicios+expertos/infraestructura+de+red/gestion/

7. [ITIL, 2001] The Stationery Office for OGC. "ITIL - The hey to Managing IT Services".

8. [Mendoza, 2002] Mendoza, Luis Eduardo. Sistemas de Información II, Teoría.

9. [Unai, 2002] Unai, Baigorri. "La Plataforma.Net ¿el futuro de la web?". Disponible en:

http://people.cs.uchicago.edu/~borja/pubs/revistaeside2002.pdf

10. [Gracia, 2004] Gracia, Joaquin. "Introducción al .NET Framework". Disponible en:

http://www.webestilo.com/aspnet/aspnet00.phtml

11. [Spider, 2004] DotNet Spider “Visual Studio .NET“. Disponible en:

http://www.dotnetspider.com/Technology/Tutorials/VisualStudio.aspx

12. [Roso, 2003] Roso, Jhon. "Base de Datos". Disponible en:

http://www.monografias.com/trabajos14/basededatos/basededatos.shtml#def

13. [Microsoft SharePoint, 2004] "Microsoft SharePoint Portal Server, La solución de portal de intranet".

Disponible en: http://www.microsoft.com/spain/servidores/sharepoint/sps03/default.asp

14. [Microsoft Excahge, 2004] "Características de Exchange Server 2003"Disponible en:

http://www.microsoft.com/spain/servidores/exchange/evaluacion/caracteristicas.asp

15. [Kruchten, 1995] Kruchten, Philippe. "Architectural Blueprints - The 4+1 View Model of Software

Architecture"

16. [Elmasri y Navathe, 1997] Elmasri, Ramez y Shamkant Navathe. “Sistemas de Bases de Datos.

Conceptos Fundamentales”. Pearson Education, México, 1997.

Referencias Bibliográficas

63

17. [Larman, 1999] Larman, Craig. “UML y Patrones. Introducción al análisis y diseño orientado a objetos”.

Prentice Hall, México, 1999.

Bibliografía

64

BIBLIOGRAFÍA

1. Blanco, Sergio. "Mono: La plataforma .NET libre", 2003.

2. Diana Lorentz. "Oracle 8i Server SQL Reference", 1997

3. Elmasri, Ramez y Shamkant Navathe. “Sistemas de Bases de Datos. Conceptos Fundamentales”.

Pearson Education, México, 1997.

4. Garlan David, Shaw Mary. "An Introduccion to Software Architecture".World Scientific Publishing

Company, Estados Unido, 1994

5. Hurtado, Sandra. "Representación de la Arquitectura de software usando UML", Universidad ICESI,

Colombia, 2000

6. IESA. "IESA 25 Años, Fundación IESA", Caracas, 1990

7. Kruchten, Philippe. "Architectural Blueprints - The 4+1 View Model of Software Architecture", 1995.

8. Larman, Craig. “UML y Patrones. Introducción al análisis y diseño orientado a objetos”. Prentice Hall,

México, 1999.

9. The Stationery Office for OGC. "ITIL - The hey to Managing IT Services", 2003.

10. Van Bon, Jan. "Gestión de ServiciosI, una introducción a ITIL", Van Haren Publishing, Holanda, 2004.

Internet:

1. es.gotdotnet.com

2. people.cs.uchicago.edu

3. sysdev.ucdavis.edu/WEBADM/document/rad_toc.htm

4. www.dotnetspider.com

5. www.gestiondelconocimiento.com

6. www.idg.es

7. www.iesa.edu.ve

8. www.microsoft.com

9. www.monografias.com

10. www.monohispano.org/tutoriales/csharp

11. www.telindus.es

12. www.webestilo.com

Apéndices

65

APÉNDICES

Apéndice A. Modelo Conceptual de la Gestión de Incidentes según ITIL

66

APÉNDICE A. MODELO CONCEPTUAL DE LA GESTIÓN DE INCIDENTES SEGÚN ITIL

El proceso de Gestión de Incidentes tiene como principal objetivo reestablecer el servicio normal

de operaciones tan rápido como sea posible y minimizar el impacto negativo sobre las operaciones de

negocio, asegurando que se mantengan los mejores niveles posibles de calidad y disponibilidad del

servicio. El manejo de los Incidentes se debe llevar a cabo siguiendo los siguientes pasos:

Figura A.1. Flujo del Manejo de Incidentes en el Helpdesk

1a

1b

1c

1d

1e

1f

1g

1h


67

1. Manejo de Incidentes

1a. Llamada de Usuario

Representa el proceso en el que el usuario se comunica con el Helpdesk para realizar un

requerimiento. Estas llamadas se pueden realizar de tres formas distintas: vía telefónica, vía correo

electrónico o personalmente. En un futuro, se pretende incluir una cuarta forma que sería vía Web.

Los requerimientos del usuario pueden ser básicamente de dos tipos: solicitud de servicios o

reporte de fallas. Ambos tipos de requerimientos serán considerados como Incidentes pues son eventos

que no forman parte de las operaciones estándares de un servicio y que causa, o puede causar, una

interrupción de, o reducción en, la calidad de dicho servicio.

1b. Registrar detalles básicos

Al momento de recibir la llamada, el analista debe crear un registro de Incidente con los detalles

básicos del mismo, el cual incluye:

- Un número de referencia, que debe ser único, generado automáticamente por el sistema.

- Fecha y hora de la llamada, generada y cargada por el sistema.

- Información del usuario que realiza la llamada. Se coloca el nombre y el resto de los datos, como

departamento y teléfono, se cargan del Directorio Activo.

- Vía de solicitud: telefónica, correo, personal, Web.

- Nota de aviso de creación del Incidente para el usuario.

- Estado del Incidente, lo cual refleja el estado actual dentro de su ciclo de vida. Los estados son:

nuevo, asignado, en espera por nosotros, en espera por proveedor, en espera por usuario,

resuelto, cerrado. Si el Incidente es registrado por el usuario, se coloca automáticamente como

nuevo.

- Descripción de los síntomas.

- Nombre del analista que registra la llamada, que se obtiene directamente de la sesión.


68

Este registro corresponde a la primera fase del ciclo de vida de un incidente, Detección y

Registro del Incidente, el cual se muestra en el paso 2a de la figura A.2.

Figura A.2. Ciclo de vida de un Incidente

Una vez registrado los detalles básicos, se pasa a la segunda fase del ciclo de vida, que se refiere

a la Clasificación del Incidente y el Soporte Inicial, donde se identifica la razón del Incidente y de ahí se

toma la acción de resolución correspondiente. Lo primero que se debe hacer es determinar el tipo de

Incidente: solicitudes de servicio o reportes de fallas y luego ubicarse en la categoría correspondiente.

Las categorías de incidente son las siguientes:

� Hardware

◦ Impresoras.

◦ Computadoras.

◦ Acceso.

◦ Partes

2a

2b

2c

2d

2e

2f


69

� Software

◦ Académico

◦ Office.

� Acceso

◦ Archivo.

◦ Correo.

◦ Intranet.

� Servicios de TI

◦ Cuentas

◦ Equipos

Es posible que existan más subcategorías para cada una de las categorías listadas anteriormente.

1c. Definir Prioridad

Luego de asignar la categoría, se procede a asignar el impacto y la urgencia del Incidente para así

determinar la prioridad del mismo. El impacto de un Incidente se refiere al número de personas que afecta.

La urgencia del problema es el punto hasta el cual una solución puede demorarse y no debe confundirse

con la prioridad la cual indica el orden relativo en el que deberían ser considerados En la siguiente tabla se

muestra la relación entre urgencia e impacto para definir la prioridad de un incidente.

Impacto

Urgencia Alto Medio Bajo

Alto 1 2 3

Medio 2 3 4

Bajo 3 4 5

Tabla A.1. Relación entre urgencia e impacto de un incidente

Los números de la tabla corresponden al nivel de prioridad del incidente, según la notación que

aparece en la tabla A2.

El nivel de prioridad es asignado automáticamente por el sistema dependiendo de los niveles de

urgencia e impacto asignados por el analista.


70

Nivel de Prioridad Descripción

1 Crítico

2 Alto

3 Medio

4 Bajo

5 Planificable

Tabla A. 2. Niveles de prioridad de un incidente

Posterior a la clasificación, el camino a seguir depende del tipo de incidente, si es una solicitud, se

pasa al se pasa punto 1d (que es análogo al 2c) de lo contrario de pasa al punto 1e, para así comenzar con

el soporte inicial.

1d. Seguir procedimientos específicos

Para la mayoría de las solicitudes, se tiene establecido uno o más procedimientos fijos, es decir,

una serie de pasos que se deben seguir para poder satisfacer la solicitud. El soporte inicial para las

solicitudes consiste en aplicar dichos procedimientos y luego saltar al paso 1h (análogo al 2e) que

corresponde a la clausura del incidente y será explicado más adelante.

En caso de que no existan procedimientos específicos para una solicitud, se debe enviar una nota

al gerente de servicios para definir si es un servicio nuevo, evaluarlo y establecer los procedimientos

acordes.

1e. Registrar detalles del Incidente

Para el resto de los Incidentes, los que no se refieren a solicitudes, se registran los detalles del

Incidente y se provee el soporte inicial, el cual se divide en cuatro caminos. En la figura A.3 se muestra

como es el flujo que se sigue dependiendo del resultado del “matching”


71

Figura A.3. Flujo del “matching” del incidente.

1. Incidente de Rutina

Primero, si el Incidente es de rutina, se sigue por el camino 1, donde la resolución puede ser

llevada a cabo por analista desde su punto de trabajo o bien indicada al usuario paso por paso.

2. Error Conocido

Si no es un incidente de rutina, se hace “match” del Incidente con la base de datos de Errores

Conocidos. Un Error Conocido es aquel para el cual se conoce su causa y tiene determinado un Work-

1

3

2

4


72

around (remedio temporal) o una solución permanente. Si se encuentra algún Error relacionado con el

Incidente, se toma el camino 2, proporcionándole al usuario el Work-around correspondiente, de manera

que pueda continuar con su trabajo aún cuando se degrade el nivel de servicio, mientras se logra

solucionar el incidente por completo.

En este punto se debe actualizar el registro del Error, aumentando el número de Incidentes

asociados y se deben actualizar o agregar nuevos campos al registro del incidente:

- Identificador del Error Conocido asociado.

- Modificar el tipo del Incidente. Se debe colocar en “Error Conocido”

- Modificar el estado del Incidente.

Luego, se extrae de la base de datos la acción que se debe tomar para solucionar el error. Si esta

acción no requiere soporte, entonces se ejecuta y se pasa a la quinta fase del ciclo de vida del incidente

(paso 2e) que corresponde a Resolución y Recuperación. De lo contrario, se le debe asignar el Problema

al Grupo de Soporte, cuya función se explicará más adelante.

3. Problema

Si el Incidente no está relacionado con algún Error Conocido, es decir, no hace “match” con la

base de datos, se busca entonces en la base de datos de Problemas. Si hay coincidencia, se continúa por

el camino 3.

En este punto se debe actualizar el registro del Problema, aumentando el número de Incidentes

asociados y se deben actualizar o agregar nuevos campos al registro del incidente:

- Identificador del Problema asociado.

- Modificar el tipo del Incidente. Se debe colocar en “Problema”

- Modificar el estado del Incidente.

Como el Incidente está asociado a un problema previamente identificado (probablemente por el

reporte de otro Incidente), solo se debe esperar a que la Gestión de Problemas consiga una solución para

el mismo.


73

4. Nuevo Problema

Por último, si el incidente no coincide con ninguna de las dos bases de datos, entonces se debe

crear un nuevo registro de Problema y comienza la Gestión de Problemas.

El objetivo principal de la Gestión de Problemas en minimizar el impacto adverso de los Incidentes

y Problemas sobre el negocio, que son causados por errores en la infraestructura de TI, y prevenir la

recurrencia de Incidentes relacionados con dichos errores. Consta de dos procesos básicos, el Control de

Problemas y el Control de Errores.

El proceso de Control de Problemas que se muestra en la figura A.4, corresponde a la tercera

fase del ciclo de vida del incidente llamada Investigación y Diagnosis.

Figura A.4. Control de Problemas.

El proceso de Control de Problemas está relacionado con el manejo de Problemas de forma

eficiente y efectiva. El objetivo es identificar la raíz de la causa y proporcionar al Helpdesk la información y

sugerencia de un Work-around cuando esté disponible.

4a

4b

4c

4d


74

4a. Identificación y registro del problema.

Cuando se tiene un nuevo problema, lo primero que se debe hacer es crear un registro de los

detalles del Problema, para ello se deben indicar los siguientes atributos:

- Un número de referencia, que debe ser único, generado automáticamente por el sistema.

- Fecha y hora del registro.

- Estado del Problema. Las categorías de estados son: no resuelto, en proceso, resuelto.

Inicialmente todo Incidente se registra automáticamente como “no resuelto”. Un problema tiene el

estado “cerrado” cuando se le ha encontrado solución y se ha convertido en error conocido

- Descripción de los síntomas.

- Lista de Incidentes asociados.

4b. Clasificación del Problema.

Ya registrado el Problema, se procede a clasificarlo. Para clasificar un problema, se llevan a cabo

básicamente los mismos pasos que para clasificar un Incidente: primero se le asigna una categoría, luego

se define el impacto y la urgencia para así determinar la prioridad.

Las categorías de los problemas son iguales a las identificadas para los incidentes:

Las escalas de urgencia, impacto y prioridad se muestran en las tablas A.1 y A.2.

Generalmente los valores de estos atributos vienen dados por el Incidente que origina el nuevo

registro de Problema, sin embargo, es posible cambiarlos.

4c. Investigación y Diagnóstico del problema.

Una vez clasificado el problema, se pasa a la investigación y diagnosis. Esta fase consiste en

identificar la causa del problema.

4d. Resolución y Cierre del Problema.

Cuando la solución haya sido encontrada, se debe modificar el estado del problema, colocándolo

en resuelto, agregar un atributo al registro que indique el Error Conocido con el cual se asociara el

problema e iniciar el proceso de Control de Errores. Esto se debe a que cuando la solución es

encontrada debe ser registrada e incluida en la base de datos de Errores Conocidos.


75

El proceso de Control de Errores se inicia cuando se ha encontrado una solución para un

problema y consiste en registrar el proceso de resolución para el error.

Los atributos para un registro de Error Conocido son los siguientes:

- Un número de referencia, que debe ser único.

- Fecha y hora del registro.

- Nombre del personal que lo registra.

- Categoría.

- Lista de Incidentes asociados.

- Lista de Problemas asociados.

- Síntomas.

- Proceso de resolución.

Una vez implementados los cambios para resolver el error, el estado del registro se coloca como

“cerrado”, finalizando proceso de Control de Errores para dar paso a finalización de la Gestión de

Incidentes.

Figura A.5. Control de Errores.


76

1f. Asignarlo a un grupo de soporte específico.

Como se menciono en el punto 1e, cuando el Helpdesk no está en la posibilidad de resolver el

Incidente, es necesario asignárselo a un grupo de soporte, que posea mayores habilidades, recursos y/o

privilegios que le permitan solucionar el problema. Este grupo es lo que se conoce como Soporte de

Segundo Nivel. Una vez que los grupos de soporte hayan solventado el incidente deben avisar al Helpdesk

para que este a su vez pueda informárselo al usuario.

1g. Proveer al usuario una solución.

Luego de terminada la Gestión de Problemas, ya se tiene una solución y se debe continuar con el

flujo del manejo de incidentes y comenzar la quinta fase del ciclo de vida del Incidente denominada

Resolución y Recuperación.

En esta etapa es donde se ejecutan las acciones para resolver el Incidente. Estas acciones

pueden provenir de los procedimientos para solicitudes, directamente de las bases de datos de errores

conocidos, o bien como resultado del proceso de investigación y diagnosis. Independientemente de la

fuente de donde provengan, las acciones deben incluirse en el registro del Incidente.

1h. Cerrar el Incidente.

El último paso del flujo de manejo de incidentes se corresponde con la sexta fase del ciclo de vida,

llamada Cierre o Clausura del Incidente, y se inicia una vez resuelto el problema. Consta de dos

actividades: confirmar telefónicamente con el usuario que el Incidente ha sido resuelto y colocar el estado

en “Resuelto”. Una vez confirmado, se coloca el Incidente como “Cerrado” y automáticamente se le envía

por correo electrónico una encuesta de evaluación.

El registro de la evaluación no está contemplado por ITIL como una actividad dentro del ciclo de vida del

Incidente, sin embargo, para el IESA es importante llevarlo a cabo.

Apéndice B. Plan de Desarrollo del Proyecto Helpdesk

77

APÉNDICE B. PLAN DE DESARROLLO DEL PROYECTO HELPDESK 1. Visión Global del Proyecto

1.1. Propósito

El proyecto de Helpdesk pretende implementar un sistema que permita la automatización del proceso

de manejo de servicios, problemas e incidentes en el área de soporte técnico del Departamento de

Informática.

1.2. Alcance

Generar los productos identificados por cada fase del proyecto logrando así un sistema funcional y en

proceso de integración a las actividades de la gerencia de soporte técnico.

1.3. Objetivos

El proyecto tiene como objetivos principales automatizar el proceso de manejo de requerimientos y

atención al cliente de TI (toda la comunidad del IESA), generando a su vez una base de conocimientos con

las soluciones de problemas; generar métricas de los procesos para permitir la mejora continua de los

mismos y planteamiento de metas; y apoyar los objetivos estratégicos de la empresa, relacionados con

mejorar la calidad de servicio a través de renovación de servicios estudiantiles y sistema de atención

centralizada.

1.4. Restricciones

El proyecto debe estar disponible para el 10 de Diciembre de 2004.

1.5. Entregables del Proyecto

- Marco conceptual del Servicio de Soporte Técnico basado en ITIL

- Plan de Desarrollo.

- Plan Manejo de Riesgos.

- Lista de Requerimientos del Sistema.

- Matriz de Evaluación de Requerimientos.

- Modelo de Casos de Uso.


78

- Diseño de Base de Datos.

- Diseño de Arquitectura.

- Plan de Manejo de Cambios.

- Prototipo.

- Manual del Programador.

- Manual del Usuario.

- Software Funcional.

1.6. Evolución del Plan de Desarrollo

Nombre de la Fase Fecha de Inicio Fecha de Culminación

Levantamiento de Información 16/08/2004 10/09/2004

Diseño 13/09/2004 15/10/2004

Desarrollo 18/10/2004 26/11/2004

Implantación 29/11/2004 10/12/2004

2. Organización del Proyecto

2.1. Estructura Organizacional

El equipo de trabajo para el proyecto está formado por un líder de proyecto y un desarrollador que

cumple con los roles de diseñador de aplicación, base de datos, interfaces y docmaster.

2.2. Interfaces Externas

El equipo del proyecto deberá trabajar con el equipo de analistas con la finalidad de reunir los

requerimientos, revisar prototipos y realizar las pruebas al sistema.


79

2.3. Roles y Responsabilidades

Rol Responsabilidad

Líder de Proyecto Administrar y coordinar las actividades a realizar.

Diseñador de

Aplicación

Tomar las decisiones de diseño de la aplicación Además,

es el responsable de integrar los diferentes módulos que

conforman la aplicación.

Diseñador de Base

de Datos

Diseñar la base de datos y la elaborar consultas eficaces

y eficientes para obtener la información requerida.

Diseñador de

Interfaz

Elaborar interfaces gráficas usables, fáciles de usar, que

interactúen de forma adecuada con el usuario.

Docmaster Elaborar los diferentes documentos que sustentan la

aplicación.

3. Manejo de Procesos

3.1. Estimaciones del Proyecto

La duración para el desarrollo del proyecto está establecida en 18 semanas, divididas en una semana

para la definición del marco conceptual, cuatro semanas para el levantamiento de información, cinco

semanas para el diseño, seis semanas para el desarrollo y dos semanas para la implantación.

La re-estimación vendrá dada en el caso tal en que los requerimientos cambien según v sean las

necesidades del cliente.

3.2. Plan de Proyecto

3.2.1. Planificación de Fases


80

3.2.2. Objetivos de las Fases

Levantamiento de Información: Desarrollar los requerimientos del sistema y se establecer los

riesgos del desarrollo del proyecto.

Diseño: Analizar los requerimientos y se diseñar la arquitectura del sistema y la base de datos.

Además, elaborar y evaluar un prototipo.

Desarrollo: Construir el software y realizar las pruebas del mismo.

Implantación: Realizar un adiestramiento masivo para los usuarios del sistema.

Levantamiento de Información

Diseño

Desarrollo

Implantación


81

3.2.3. Calendario del Proyecto

3.3. Monitoreo y Control del Proyecto

Se realizaran reuniones semanales entre el líder del proyecto y el desarrollador con la finalidad de

monitorear el avance del proyecto y planificar actividades según el calendario establecido.

Apéndice C. Especificación de Requerimientos Funcionales y No Funcionales

82

APÉNDICE C. ESPECIFICACIÓN DE REQUERIMIENTOS FUNCIONALES Y NO FUNCIONALES.

El presente documento muestra detalladamente los requerimientos funcionales y no funcionales

del sistema Helpdesk. Para cada uno de los requerimientos se muestra una breve descripción. Para los

requerimientos funcionales se especifica la categoría y la prioridad del mismo. La categoría indica si la

función que satisface el requerimiento es oculta o evidente para el usuario mientras que la prioridad se

refiere al grado de importancia del requerimiento. Por otro lado, para los requerimientos no funcionales se

especifica la categoría del mismo, la cual indica si el requerimiento es opcional u obligatorio.

Requerimientos funcionales

R1. Manejar Incidentes

R1.1. Permitir el registro de Incidentes.

Descripción: El sistema debe permitir que tanto el analista como el cliente puedan registrar

nuevos incidentes.

Categoría: Evidente.

Prioridad: Alta.

R1.2. Permitir la modificación de Incidentes.

Descripción: Los registros de incidentes deben poder ser modificados por el analista.


Prioridad: Alta.

R1.3. Permitir la consulta de Incidentes.


Descripción: Se deben listar los incidentes que hayan sido asignados a un analista

determinado.


Prioridad: Media.

R1.3.2. Asociados a un cliente.

Descripción: Se deben listar los incidentes que pertenezcan a un cliente determinado.


Prioridad: Media.


83


Descripción: Se deben listar todos los incidentes correspondientes a una categoría

determinada.


Prioridad: Alta.

R1.3.4. Por estado.

Descripción: Se deben listar todos los incidentes según el estado en el que se encuentran.


Prioridad: Alta.

R1.3.5. Por fecha.

Descripción: Se deben listar todos los incidentes según el mes de registro.


Prioridad: Alta.

R1.3.6. Todos los incidentes.

Descripción: Se deben listar todos los incidentes registrados.


Prioridad: Alta.

R1.4. Generar notas de confirmación

R1.4.1. De creación del Incidente.

Descripción: Se debe generar una nota que confirme el registro de un nuevo incidente.

Categoría: Oculto.

Prioridad: Alta.

R1.4.2. De confirmación de solución del Incidente y encuesta.

Descripción: Se debe generar una nota que permita confirmar con el cliente la solución del

incidente y la encuesta de evaluación asociada al incidente.

Categoría: Oculto.

Prioridad: Alta.


84

R1.5. Generar notas de asignación

R1.5.1. De Incidente.

Descripción: Se debe generar una nota avise la asignación de un incidente a un analista.

Categoría: Oculto.

Prioridad: Alta.

R1.5.2. De problemas.

Descripción: Se debe generar una nota avise la asignación de un problema a un analista.

Categoría: Oculto.

Prioridad: Alta.

R1.6. Enviar al cliente notas de confirmación.

Descripción: Se debe enviar al cliente, por correo electrónico, la nota de confirmación

generada.

Categoría: Oculto.

Prioridad: Media.

R1.7. Enviar notas de asignación.

Descripción: Se debe enviar al analista, por correo electrónico, la nota de asignación

generada.

Categoría: Oculto.

Prioridad: Media.

R2. Manejar Problemas

R2.1. Generar el registro de Problemas.

Descripción: El sistema debe permitir que el analista pueda crear nuevos registros de

problemas.

Categoría: Oculto.

Prioridad: Alta.

R2.2. Permitir la modificación de Problemas.

Descripción: Los registros existentes de problemas se deben poder modificar.


Prioridad: Alta.


85

R2.3. Permitir la consulta de Problemas.


Descripción: Se deben listar los problemas que hayan sido asignados a un analista

determinado.


Prioridad: Media.


Descripción: Se deben listar todos los problemas correspondientes a una categoría

determinada.


Prioridad: Alta.

R2.3.3. Por estado.

Descripción: Se deben listar todos los problemas según el estado en el que se encuentran.


Prioridad: Alta.

R2.3.4. Por fecha.

Descripción: Se deben listar todos los problemas según el mes de creación.


Prioridad: Alta.

R2.3.5. Todos los problemas.

Descripción: Se debe permitir la visualización de todos los registros de problemas..


Prioridad: Alta.

R2.4. Mantener la consistencia con los incidentes asociados.

Descripción: Cuando se realicen modificaciones en el registro de problemas, se debe

mantener consistencia con los registros de los incidentes asociados.

Categoría: Oculto.

Prioridad: Alta.


86


Descripción: Se debe mantener un registro del número de incidentes asociados a un problema

determinado.

Categoría: Oculto.

Prioridad: Media.

R3. Manejar Errores Conocidos

R3.1. Generar el registro de Errores Conocidos.

Descripción: El sistema debe permitir que el analista pueda crear nuevos registros de errores

conocidos.


Prioridad: Alta.

R3.2. Permitir la modificación de Errores Conocidos

Descripción: Los registros de existentes de errores conocidos se deben poder modificar.


Prioridad: Baja.

R3.3. Permitir la consulta de Errores Conocidos

Descripción: Se deben listar todos los registros de errores conocidos.


Prioridad: Media.

R3.4. Mantener la consistencia con los incidentes y problemas asociados.

Descripción: Cuando se realicen modificaciones en el registro de error conocido, se debe

mantener consistencia con los registros de los incidentes y los problemas asociados.

Categoría: Oculto.

Prioridad: Alta.


Descripción: Se debe mantener un registro del número de incidentes asociados a un error

conocido determinado

Categoría: Oculto.

Prioridad: Media.


87

R4. Generar reportes

R4.1. Generar reportes estadísticos de Incidentes.

Descripción: El sistema debe generar reportes estadísticos de los incidentes registrados.


Prioridad: Baja

R4.2. Generar reportes estadísticos de Problemas.

Descripción: El sistema debe generar reportes estadísticos de los incidentes registrados.


Prioridad: Baja.

R4.3. Permitir la visualización e impresión de los reportes.

Descripción: Los reportes generados deben poder visualizarse por pantalla. Además, deben

generarse en archivos Excel y poder imprimirse.


Prioridad: Baja.

R5. Manejar Evaluaciones

R5.1. Permitir el registro de evaluaciones.

Descripción: El sistema debe permitir que el cliente registre la evaluación al servicio recibido.

Categoría: Evidente

Prioridad: Alta.

R5.2. Permitir la consulta de evaluaciones.

Descripción: Se deben listar las evaluaciones realizadas por los clientes.


Prioridad: Alta.

R6. Manejar el acceso de usuarios

R6.1. Permitir el registro de usuarios

Descripción: El sistema debe permitir el registro de nuevos usuarios.


Prioridad: Alta.


88

R6.2. Permitir la modificación de usuarios registrados.

Descripción: Los datos de los usuarios registrados deben poder modificarse.


Prioridad: Media.

R6.3. Permitir la eliminación de usuarios registrados.

Descripción: Los usuarios registrados deben poder eliminarse.


Prioridad: Baja.

R6.4. Permitir el acceso a través de perfiles de usuarios.

Descripción: El sistema debe permitir usuarios con diferentes perfiles, como soporte y cliente.

Categoría: Oculto.

Prioridad: Alta.

R6.5. Iniciar sesión para un usuario válido.

Descripción: Permitir que un usuario registrado en el sistema inicie su sesión.


Prioridad: Alta.

R6.6. Cerrar sesión de un usuario.

Descripción: Permitir que el usuario finalice su sesión en el sistema.


Prioridad: Alta

R7. Tener comunicación con el Directorio Activo.

Descripción: Comunicarse con el directorio activo con la finalidad de extraer los datos necesarios.

Categoría: Oculto.

Prioridad: Alta

R8. Mostrar sugerencias de soluciones a Incidentes en caso de que existan.

Descripción: El sistema debe mostrar posibles soluciones a los incidentes, basándose en los síntomas

del incidente y su similitud con los errores conocidos registrados.


Prioridad: Baja.


89

R9. Manejar Solicitudes

R9.1. Permitir el registro de solicitudes

Descripción: El sistema debe permitir que el analista de soporte registre las actividades que

conforman los procedimientos de las solicitudes.


Prioridad: Alta.

R9.2. Permitir la modificación de solicitudes

Descripción: El sistema debe permitir la modificación de las solicitudes registradas.


Prioridad: Media.

R10. Permitir el control de las actividades realizadas por los analistas.

Descripción: El sistema debe permitir llevar el control de las actividades realizadas para cada uno de

los incidentes pertenecientes a un tipo de solicitud determinado además de registrar la persona que

realizó la actividad.


Prioridad: Alta

R11. Permitir el registro de soluciones a problemas y errores conocidos.

Descripción: El sistema debe permitir al usuario registrar las diferentes soluciones encontradas a los

problemas y a los errores conocidos.


Prioridad: Alta.

Requerimientos No Funcionales

1. Requerimientos de seguridad:

1.1. Robustez.

Descripción: Seguridad en los datos, estos solo pueden ser modificados en el tiempo por

usuarios autorizados.

Categoría: Obligatorio.


90

1.2. Seguridad en Internet.

Descripción: El sistema debe contar con sistemas de seguridad en Internet, para evitar los

posibles ataques durante la conexión.


1.3. Límite de modificación.

Descripción: Algunos datos no pueden ser modificados después de cumplir con determinadas

característica, por ejemplo, un incidente no puede ser modificado luego de cerrado.


2. Requerimientos de desempeño

2.1. Tiempos de respuesta

Descripción: El sistema debe proporcionar tiempos de respuesta relativamente cortos. El tiempo

promedio para registrar un incidente debe ser de 1 minuto.


2.2. Comunicación entre componentes

Descripción: La comunicación y coordinación entre los componentes del sistema deben ser

eficientes y efectivas, con la finalidad de mantener la consistencia en los datos.


3. Requerimientos de interfaz de usuario

3.1. Facilidad de uso

Descripción: La interfaz debe ser de fácil comprensión y fácil navegación.


3.2. Amigable.

Descripción: Cada vez que se realice una petición al sistema que implica una salida por pantalla,

esta debe ser amigable.

Categoría: Opcional.

3.3. Proporcionar ayuda.

Descripción: Deben existir menús de ayuda que faciliten el uso del sistema al usuario.



91

4. Requerimientos de operación

Descripción: El sistema necesita para funcionar 128 MB de memoria como mínimo, procesador

Pentium, manejador de base de datos ORACLE y Windows 2000 en adelante.


5. Requerimientos de respaldo y recuperación.

5.1. Tolerancia a fallas.

Descripción: El sistema debe tener soporte en caso de alguna falla. Servidor de respaldo.


5.2. Disponibilidad

Descripción: El sistema debe estar disponible para los usuarios, mínimo, durante el horario de

servicio. De lunes a viernes de 7 a.m. a 9 PM y sábados y domingo de 8 AM a 9 PM


6. Requerimientos de mantenibilidad

6.1. Alta cohesión

Descripción: Cada uno de los distintos módulos del sistema debe realizar una tarea específica y

claramente determinada.


6.2. Bajo acoplamiento

Descripción: Cada componente del sistema debe mantenerse lo más independientemente

posible de los demás componentes del mismo, permitiendo solo el pase de mensajes a través de

estos.


7. Requerimientos de desarrollo

7.1. Plataforma

Descripción: El sistema debe ser desarrollado en plataforma Web.



92

7.2. Intranet

Descripción: El sistema debe estar integrado a los estándares de la intranet de la institución.


8. Requerimientos de documentación

8.1. Manual de Usuario.

Descripción: El sistema debe estar debidamente documentado a través del Manual de Usuario.

Es necesario especificar como instalar el sistema y como manejarlo. Dicho manual debe estar

disponible tanto en formato impreso como en formato digital.


8.2. Manual del Sistema.

Descripción: Todas las decisiones de diseño, implementación deben ser debidamente

documentados en el Manual del Sistema. Debe contener los diferentes diagramas (clases,

secuencia, colaboración, etc). Dicho manual debe estar disponible tanto en formato impreso

como en formato digital.

Categoría: Deseable.

Apéndice D. Plan de Riesgos

93

APÉNDICE D. PLAN DE RIESGOS

1. Introducción

El presente documento muestra los riesgos que pueden surgir durante el desarrollo del proyecto

Helpdesk Debido a que es un proyecto de desarrollo de software, es necesario gestionar estos riesgos y

así tener a la mano en todo momento la información asociada a los mismos.

1.1. Propósito

Identificar los riesgos asociados al desarrollo del proyecto Helpdesk, con el objetivo de evitarlos o

minimizarlos, y reflejar las acciones que se deben tomar en caso de que se presenten.

1.2. Alcance

Los riesgos presentados en este documento abarcan todas las fases del proceso de desarrollo.

2. Riesgos

A continuación, se presentan detalladamente los riesgos identificados, los cuales indican las posibles

situaciones que puedan afectar el desarrollo del proyecto. Para cada uno de los riesgos se muestra una

breve descripción, magnitud, impacto y los indicadores que permiten identificar la posible aparición del

riesgo. Así mismo, se indican planes de mitigación para reducir las posibilidades de aparición y planes de

contingencia en caso de que el riesgo aparezca.

2.1. En cuanto a requerimientos y relación con clientes y usuarios.

2.1.1. Cambios en los requerimientos.

Descripción Los clientes y usuarios realizan cambios constantes a los requerimientos del

sistema, ya sea por inclusión, modificación o eliminación de requerimientos

Magnitud Alta

Impacto

• Aumento del esfuerzo requerido por parte del desarrollador.

• Redefinición del plan de desarrollo del proyecto.

• Retraso en las actividades lo que implica lentitud en el avance.


94

Indicadores

• El cliente no tiene claro lo que el sistema debe hacer o las funcionalidades

que debe tener.

• En las reuniones con el cliente se determina que algún requerimiento ya no

es necesario.

Estrategia de Mitigación

Obtener la mayor información posible sobre las necesidades de los clientes y

usuarios en la primera fase del proyecto y mostrar los avances al cliente de

forma tal que este conozca el estado de proyecto y las nuevas necesidades

que puedan surgir sean captadas lo antes posible.

Establecer un acuerdo con el cliente sobre los requerimientos en los que se

trabajará y justificar posibles retrasos del proyecto en caso de ocurrir algún

cambio de opinión por parte del cliente.

Plan de Contingencia

Planificar la ejecución de las nuevas actividades y la elaboración de nuevos

documentos con la finalidad de realizarlos en el menor tiempo posible

adaptándolas a la planificación original.

2.1.2. Requerimientos demasiado ambiciosos para el tiempo disponible.

Descripción Los requerimientos del sistema no pueden ser cumplidos en el tiempo

establecido para el desarrollo del proyecto.

Magnitud Alta

Impacto

• No se cumplen todos los requerimientos.

• Insatisfacción del cliente.

• Daño en la imagen del desarrollador.

Indicadores Ninguno


Realizar un estimado real del tiempo de desarrollo necesario para cumplir con

los requerimientos.

Dividir el proyecto en iteraciones o versiones, dejando para la primera iteración

los requerimientos básicos.


95

Plan de Contingencia

Realizar una reprogramación de las últimas fases del proyecto y llegar a un

acuerdo con los clientes sobre entregar al cliente un producto únicamente con

los requerimientos básicos en la fecha estipulada o por el contrario establecer

una nueva fecha de entrega en la cual sea posible cumplir con todos los

requerimientos.

2.1.3. Expectativas irreales del cliente.

Descripción Los clientes se crean expectativas que no se adaptan a la realidad del producto

desarrollado.

Magnitud Baja

Impacto • Insatisfacción del cliente con el producto terminado.

Indicadores • Los clientes piensan que el producto va a solucionar muchos más

problemas que aquellos para los que fue creado.

Estrategia de Mitigación Dejar claro al cliente cual es el problema o problemas a los cuales se pretende

dar solución con el producto.

Plan de Contingencia Ninguno

2.1.4. Poca disponibilidad de los usuarios finales.

Descripción Los usuarios finales no están disponibles para realizar el levantamiento de

información y tienen poca o ninguna participación en el desarrollo del sistema.

Magnitud Alta

Impacto • Las necesidades reales de los usuarios no son satisfechas por el software.

Indicadores • Semanas de poco trabajo en espera de disponibilidad de los usuarios.

• Cambios frecuentes y desorganizados de los requerimientos.

Estrategia de Mitigación Incentivar la realización de reuniones frecuentes con los usuarios.

Plan de Contingencia Ninguno


96

2.1.5. Rechazo del producto.

Descripción Una vez finalizado e implantado el producto, es rechazado por los usuarios

finales, debido a falta de entrenamiento, miedo al cambio, etc.

Magnitud Media

Impacto • Problemas con el levantamiento de información

• Demora en la implantación del sistema.

Indicadores

• Los usuarios se niegan a aportar información sobre las desventajas del

sistema actual.

• Los usuarios muestran continuo desacuerdo con el nuevo sistema.

• Los usuarios se niegan a utilizar el nuevo sistema.

Estrategia de Mitigación Involucrar a los usuarios en el proceso de desarrollo, mostrarle las ventajas del

nuevo sistema y realizar un adiestramiento masivo.

Plan de Contingencia Realizar la implantación del sistema de manera escalonada de forma tal que el

usuario se adapte lentamente al nuevo sistema.

2.2. En cuanto a la planificación, control y seguimiento.

2.2.1. Planificación demasiado optimista.

Descripción La planificación de las actividades se realiza pensando que todas las

actividades se van a realizar sin dificultades y en el tiempo exacto.

Magnitud Baja

Impacto • Exceso de trabajo del desarrollador para cumplir con la planificación.

• Retraso en la entrega del producto.

Indicadores • El tiempo de trabajo asignado a cada actividad es mínimo.

• La planificación no toma en cuenta demoras por ningún motivo.

Estrategia de Mitigación Durante la planificación, incluir tiempos de holgura para las actividades más

críticas o que requieran mayor esfuerzo.

Plan de Contingencia Redefinir el plan de trabajo.


97

2.2.2. La planificación omite actividades necesarias o las subestima.

Descripción Algunas actividades no se toman en cuenta durante la planificación por

considerarse innecesarias, o no se les otorga la respectiva importancia.

Magnitud Media

Impacto • Acumulación de trabajo para el desarrollador en el momento en que se deba

agregar una nueva tarea.

Indicadores • Necesidad de los resultados de la actividad omitida para continuar con las

demás actividades.


Identificar las entradas y salidas de cada actividad para verificar que se posee

toda la información necesaria para llevar a cabo todas las actividades incluidas

en la planificación.

Plan de Contingencia Incluir la actividad omitida, realizarla y modificar la planificación del resto del

proyecto según sea necesario.

2.2.3. Retrasos en la revisión de los avances del proyecto.

Descripción La revisión, corrección y aceptación de los entregables se realiza de forma muy

lenta.

Magnitud Media

Impacto • Retraso en las actividades que dependen de la revisión.

Indicadores Ninguno

Estrategia de Mitigación Establecer períodos razonables de evaluación en el plan de desarrollo del

proyecto.

Plan de Contingencia Comenzar la planificación de la siguiente fase a pesar de no tener el resultado

de la revisión anterior.

2.2.4. No se hace seguimiento de las tareas o plan de actividades.

Descripción No se lleva un control de las actividades realizadas con respecto a la

programación establecida.

Magnitud Baja


98

Impacto

• Se omiten ciertas actividades o quedan incompletas.

• Se intercalan actividades, es decir, se modifica el orden de ejecución de las

mismas.

Indicadores • Las actividades se realizan de forma desordenada.

Estrategia de Mitigación Chequear continuamente la planificación de las actividades y comprobar que

se realizan todas las actividades en el momento indicado.

Plan de Contingencia Ejecutar acciones que permitan colocarse al día con lo establecido en la

planificación.

2.3. En cuanto a diseño e implementación.

2.3.1. Instalaciones de desarrollo no disponibles.

Descripción

No existen instalaciones (computadoras, redes, herramientas de desarrollo,

bases de datos, etc.) que satisfagan las necesidades para establecer el

ambiente de desarrollo requerido por el proyecto.

Magnitud Alta

Impacto • Retraso en el inicio de la fase de construcción del producto.

• Retraso en aprendizaje de la(s) herramienta(s).

Indicadores • No se tiene claro el lugar destinado para el desarrollo.

Estrategia de Mitigación Solicitar continuamente que se tome la decisión de donde se va a instalar el

equipo desarrollo.

Plan de Contingencia Instalar la mayor cantidad posible de las herramientas necesarias en un equipo

portátil, para poder cambiar de lugar de trabajo sin graves complicaciones.

2.4. En cuanto al uso de herramientas

2.4.1. La curva de aprendizaje para las herramientas es más larga de lo esperado.

Descripción La adopción de herramientas y tecnología nueva o desconocida, puede resultar

una labor larga y complicada para el desarrollador.

Magnitud Media


99

Impacto

• Las estimaciones de trabajo son irreales.

• Retraso del proyecto.

• Aumento en el esfuerzo y dedicación por parte del desarrollador.

Indicadores • El desarrollador tiene problemas para utilizar las herramientas.


Planificar las actividades teniendo en cuenta el tiempo necesario para el

aprendizaje de la nueva tecnología.

Adquirir los conocimientos de la tecnología gradualmente para así disminuir el

impacto del cambio.

Plan de Contingencia Dedicar tiempo extra al estudio y práctica de la nueva tecnología.

Apéndice E. Glosario de Términos

100

APÉNDICE E. GLOSARIO DE TÉRMINOS

A

Artefacto: es un documento en el cual se presentan ciertos aspectos relacionados con el desarrollo de un

proyecto.

B

Base de Conocimiento: Captura del conocimiento de una persona para almacenarlo de manera

persistente, asegurando que todos los empleados tengan acceso a la información.

Browser: software que permite la visualización de las páginas de Internet, en código HTML, DHTML, Java,

VBScript, JavaScript y otros lenguajes de programación.

C

Categoría: Atributo que permite clasificar un incidente, solicitud, error conocido o problema.

Cliente: Se refiere a la comunidad del IESA (estudiantes, egresados, empleados administrativos, etc.)

E

Error Conocido: Cualquier incidente cuya causa ha sido investigada con anterioridad y para el cual existe

una o más soluciones conocidas.

Escalabilidad: Aquellos sistemas que tienen la capacidad y facilidad de ser incrementados en la medida

que sea necesario.

Escritorio de Ayuda: Ofrece a todos los usuarios un punto de contacto único para la gestión y resolución

de sus problemas de TI. Se encarga de manejar, coordinar y resolver incidentes tan pronto como sea

posible, asegurando que ningún registro es perdido, olvidado o ignorado.

Evaluación: Apreciación del cliente con respecto al servicio recibido para cada uno de sus incidentes.

G

Gestión de Conocimiento: Conjunto de procesos y sistemas que permiten que el Capital Intelectual de

una organización aumente de forma significativa, mediante la gestión de sus capacidades de resolución de

problemas de forma eficiente (en el menor espacio de tiempo posible), con el objetivo final de generar

ventajas competitivas sostenibles en el tiempo.


101

Gestión de Incidentes: Gerenciar los Incidentes para reestablecer el servicio normal de operaciones tan

rápido como sea posible y minimizar el impacto negativo sobre las operaciones de negocio, asegurando

que se mantengan los mejores niveles posibles de calidad y disponibilidad.

Gestión de Problemas: Gerenciar los problemas del área tecnológica para minimizar el impacto adverso

de estos sobre el negocio.

Gestión de Servicios: entrega y soporte de los servicios de TI apropiados para los requerimientos de

negocios de la organización, y se encarga de la planificación, implementación, seguimiento y control de la

operación de dichos servicios y la infraestructura sobre la que se soportan.

H

Helpdesk: Ver Escritorio de Ayuda.

I

Incidente: Cualquier evento que no forma parte de las operaciones estándares de un servicio y que causa,

o puede causar, una interrupción de, o reducción en, la calidad de dicho servicio.

Internet: es un gran conjunto de redes de computadores interconectadas. Es una red compuesta por

muchas redes.

ITIL (Information Technology Infrastructure Library): librería que proporciona un conjunto completo y

coherente de las mejores prácticas para el manejo de los servicios de TI, enfocándose hacia el logro de la

efectividad del negocio y la eficiencia en el uso de los sistemas de información.

M

Modelo: Toda estructura lógica que se utiliza para dar razón de un conjunto de fenómenos que guardan

entre sí ciertas relaciones.

Modularidad: Dícese de aquellos sistemas que están compuesto por un conjunto de módulos, en los

cuales se agrupan elementos de un mismo tipo.

P

Problema: aquel Incidente para el cual no se conoce la causa que lo origina ni una solución.

Procedimiento: Acción de proceder. Método, operación o serie de operaciones con que se pretende

obtener un resultado.


102

Proceso: Desarrollo o evolución de las fases sucesivas de un fenómeno. Métodos o sistema adoptado

para llegar a un determinado fin.

R

Reporte: Información estadística sobre el comportamiento de la organización con respecto a los incidentes

que ocurren en ella y el manejo de los mismos.

Requerimiento: Característica que debe estar presente en el sistema a desarrollar

S

Servidor: En informática, un servidor es un tipo de software que realiza ciertas tareas en nombre de los

usuarios. El término servidor también se utiliza para referirse al computador en el cual funciona ese

software.

Sistema: Conjunto de partes relacionadas entre sí, con el propósito de satisfacer un fin común. En el

contexto actual se refiere al sistema desarrollado para la Gerencia de Recursos Humanos del IESA.

Solicitud: Tipo de servicio que presta la gerencia, que posee un procedimiento fijo establecido para su

ejecución.

Solución: Procedimiento que resuelve un error conocido o un problema.

Soporte: Empleados de la Gerencia de Informática del IESA encargados de la gestión de incidentes y

problemas.

Software: programas o aplicaciones para ser usadas con una computadora.

U

Usuario: Persona que usa normal y ordinariamente alguna cosa. Dícese del que tiene derecho de usar una

cosa ajena con ciertas limitaciones. En nuestro caso esa cosa es el sistema desarrollado.

Apéndice F. Especificación de Casos de Uso

103

APÉNDICE F. ESPECIFICACIÓN DE CASOS DE USO

El presente documento muestra detalladamente los casos de uso (CU) identificados para el sistema

Helpdesk. Para cada uno de los casos de uso se especifica los actores principales que intervienen en él,

una breve descripción, precondiciones y poscondiciones. Además se especifican las referencias cruzadas y

requerimientos especiales, que permiten establecer la trazabilidad entre los requerimientos del sistema y

los casos de uso identificados. Por otro lado se describe el curso normal de eventos, que explica como el

actor interactúa con el sistema para ejecutar el CU, y los cursos alternos. Por último se presentan los

puntos de extensión del caso de uso que indican cuales casos de uso se pueden iniciar a partir de ese CU.

1. General

1.1. Iniciar Sesión

Actores Principales: Usuario (Cliente, Soporte)

Descripción: El usuario inicia su sesión en el sistema y tiene acceso a sus funcionalidades.

Precondición: Ninguna.

Poscondición: El usuario accede al sistema.

Referencias cruzadas: R6.4, R6.5, R7

Curso normal de eventos:

Acción del Actor Respuesta del Sistema

1. El caso de uso comienza cuando el usuario escribe el URL del sistema en la barra del browser.

2. El sistema solicita al usuario su nombre de usuario y contraseña.

3. El usuario introduce su nombre de usuario y contraseña

4. El usuario valida con el directorio activo los datos introducidos por el usuario.

5. El sistema muestra la página de bienvenida.

Cursos alternos:

• Paso 4: El sistema valida el usuario como invitado, y el mismo se loguea por primera vez.

4.1 Se le muestra la página para que se registre

• Paso 4: El sistema valida el usuario como invitado, y el mismo se ha logueado anteriormente.

4.1 Se le pide nombre y contraseña.


104

• Paso 4: Los datos del usuario son inválidos.

4.1 No se muestra la página de bienvenida y se le solicita de nuevo al usuario su nombre de

usuario y contraseña.

Puntos de extensión:

Registrar invitado.

1.2. Cerrar Sesión


Descripción: El usuario finaliza su sesión y sale del sistema.

Precondición: El usuario debe estar logueado en el sistema.

Poscondición: El usuario sale del sistema y se carga la página de servicios del IESA.

Referencias cruzadas: R.6, R6.6



1. El caso de uso comienza cuando el usuario selecciona la opción de salir.

2. Se carga la página de servicios del IESA

Cursos alternos:

Ninguno


Ninguno

2. Manejar Incidentes

2.1. Registrar Incidente

2.1.1. Como Cliente

Actor Principal: Usuario (Cliente).

Descripción: El Cliente introduce los datos solicitados para realizar el registro de Incidentes.

Precondición: El Cliente debe estar logueado en el sistema.

Poscondición: Se crea un nuevo Incidente y se envía una nota de confirmación al cliente.

Referencias cruzadas: R1.1


105



1. El caso de uso comienza cuando el Cliente selecciona la opción de Registrar/Incidente.

2. El sistema carga los datos disponibles del cliente.

3. El sistema solicita los datos del incidente: • Nombre del Incidente. • Tipo de Incidente. (Solicitud o Falla)

◦ Si es solicitud, solita el tipo de solicitud y la información necesaria para el tipo seleccionado.

◦ Si es falla, solicita los síntomas del incidente.

4. El Cliente ingresa los datos solicitados y presiona guardar.

5. El sistema genera un identificador para el incidente y almacena el nuevo incidente.

6. El sistema envía una nota de confirmación al cliente.

7. El sistema muestra en la lista de incidentes el nuevo incidente.

Cursos alternos:

• Paso 2: Los datos del cliente no están completos.

2.1 El cliente completa los datos que sean obligatorios.

• Paso 4: Es el primer incidente registrado por el cliente

4.1 El sistema almacena los datos del cliente en la base de datos.

• Paso 4: Los datos introducidos son incorrectos o incompletos.

4.1 El sistema informa al usuario los errores cometidos.


Ninguno

2.1.2. Como Soporte

Actor Principal: Usuario (Soporte).

Descripción: El usuario Soporte introduce los datos solicitados para realizar el registro de Incidentes.

Precondición: El usuario debe estar logueado en el sistema.

Poscondición: Se crea un nuevo Incidente y se envía una nota de confirmación al cliente.


106

Referencias cruzadas: R1.1, R8.



1. El caso de uso comienza cuando el usuario selecciona la opción de Registrar/Incidentes.

2. El sistema carga la pagina de registro de incidentes.

3. El usuario escribe el nombre de usuario de la persona que reporta el incidente (cliente) y hace click en la flecha. Si no se conoce el nombre completo, puede colocar incompleto.

4. El sistema busca en el directorio activo los usuarios y carga la lista de los nombres de usuario encontrados.

5. El usuario selecciona el nombre de usuario deseado.

6. El sistema carga los datos disponibles del cliente.

7. El sistema solicita los datos del incidente: • Nombre del Incidente. • Estado. • Tipo de Incidente. (Solicitud o Falla)

◦ Si es solicitud, solita el tipo de solicitud y la información necesaria para el tipo seleccionado.

◦ Si es falla, solicita los síntomas del incidente.

• Categoría. • Subcategoría. • Urgencia. • Impacto.

8. El usuario ingresa los datos solicitados y presiona guardar.

9. El sistema genera un identificador para el incidente y almacena el nuevo incidente.

10. El sistema envía una nota de confirmación al cliente.

11. El sistema muestra en la lista de incidentes el nuevo incidente y mantiene los datos del incidente además de mostrar el número de referencia asignado y la prioridad.


107

Cursos alternos:

• Paso 6: Los datos del cliente no están completos.

6.1 El usuario completa los datos que sean obligatorios.

• Paso 7: El estado seleccionado es diferente de nuevo.

7.1 Se inicia el caso de uso Asignar Incidente.

• Paso 8: Es el primer incidente reportado por ese cliente.

8.1 El sistema almacena los datos del cliente en la base de datos.



• Paso 10: El incidente registrado es de tipo Solicitud.

10.1 Se envía una nota al responsable de la primera actividad de la solicitud seleccionada.


Asignar incidente, Modificar incidente, Buscar solución.

2.2. Modificar Incidente

Actor Principal: Usuario (Soporte)

Descripción: El usuario modifica los datos de los incidentes registrados.


Poscondición: Se almacenan los cambios realizados al Incidente.

Referencias cruzadas: R1.2



1. El caso de uso comienza cuando el usuario selecciona la opción de Actualizar de la lista de incidentes luego de haber realizado una consulta o cuando hace click en el número de referencia del incidente en la lista de incidentes que aparece en la página de registro de incidentes.

2. El sistema cargar la página de registro de incidentes con los datos del incidente a modificar. Los datos que no pueden ser modificados aparecen inactivos.

3. El usuario realiza los cambios en los campos que desea modificar y presiona guardar.


108

4. El sistema valida los cambios realizados.

5. El sistema almacena los nuevos datos del Incidente.

6. El sistema regresa a la página de donde se inició el caso de uso.

Cursos alternos:

• Paso 4: Los cambios realizados son inválidos.

4.1 El sistema muestra un mensaje de error, el usuario realiza las correcciones necesarias y

presiona guardar.

• Paso 4: El usuario desea buscar solución al incidente.

4.1 El sistema muestra un mensaje de error, el usuario realiza las correcciones necesarias y

presiona guardar.


Asignar incidente, Buscar solución.

2.3. Consultar Incidente.


Descripción: El usuario consulta los datos de los Incidentes registrados.


Poscondición: Ninguna.

Referencias cruzadas: R1.3, R1.3.1, R1.3.2, R1.3.3, R1.3.4, R1.3.5, R1.3.6



1. El caso de uso comienza cuando el usuario selecciona la opción de Consultas/Incidente.


109

2. El sistema muestra las siguientes opciones de consulta:

• Por número de referencia. • Por analista. • Por categoría. • Por estado. • Por prioridad. • Por tipo. • Por fecha de registro.

Y el sistema muestra una lista de todos los incidentes no resueltos.

3. El usuario selecciona las opciones de búsqueda y oprime Buscar.

4. El sistema muestra los incidentes que satisfacen las opciones seleccionadas.

5. El usuario hace click en la palabra ver del incidente deseado.

6. El sistema muestra los datos correspondientes al incidente seleccionado.

Cursos alternos:

• Paso 2: Si el usuario es de tipo Soporte.

2.1 El sistema muestra una opción de búsqueda adicional que es Buscar por cliente.

• Paso 4: No hay incidentes registrados que cumplan las opciones de búsqueda.

4.1 El sistema muestra un mensaje y aparece la lista de incidentes vacía.

• Paso 5: El usuario no hace click en la palabra ver sino en la palabra actualizar.

5.1 Se inicia el caso de uso Modificar Incidente.

• Paso 6: El usuario hace click en la opción imprimir.

6.1 Se imprime el resumen de los datos del incidente.

• Paso 6: El usuario desea consultar otro incidente.

6.1 Hace click regresar y comienza de nuevo el caso de uso Consultar incidente.


Modificar incidente, Asignar incidente.

2.4. Asignar Incidente

Actores Principales: Usuario (Soporte)

Descripción: El usuario asigna el incidente a otro usuario Soporte.

Precondición: El usuario al que se le asigna el incidente debe estar registrado en el sistema.


110

Poscondición: El incidente es asignado al usuario y se le envía una nota de asignación.

Referencias cruzadas: R1.5, R1.5.1, R1.7.



1. El caso de uso comienza cuando el usuario cambia el estado del incidente a un estado diferente de nuevo o cuando cambia a la persona encargada del incidente. Esto puede ocurrir cuando se registra o modifica un incidente.

2. El sistema muestra la lista de las personas a las cuales se les puede asignar el incidente.

3. El usuario selecciona el nombre de usuario de la persona a la cual desea asignarle el incidente.

4. El usuario continúa registrando o modificando el incidente y presiona Guardar.

5. El sistema asigna el incidente a la persona seleccionada y le envía una nota de asignación.

6. El sistema regresa a la página donde se inició el caso de uso.

Cursos alternos:

• Paso 1: Se está registrando un incidente y el usuario no desea asignarlo.

1.1 El usuario coloca el estado del incidente como nuevo.


Ninguno.

3. Manejar Problemas

3.1. Modificar Problema


Descripción: El usuario modifica los datos de los problemas registrados.


Poscondición: Se almacenan los cambios realizados al Problema.

Referencias cruzadas: R2, R2.2, R2.4


111



1. El caso de uso comienza cuando el usuario selecciona la opción de Actualizar luego de haber realizado una consulta de Problemas.

2. El sistema muestra los datos del Problema.


4. El sistema almacena los nuevos datos del Problema.

5. El sistema regresa a la página de consulta de incidentes, donde se inició el caso de uso.

Cursos alternos:

• Paso 2: El Problema tiene estado Resuelto.

2.1 El sistema muestra un mensaje e inhabilita los datos modificables del Problema.

• Paso 3: Se modifica el estado del problema y se coloca como Resuelto.

3.1 Se inicia el caso de uso Registra solución para un problema.

3.2 El sistema genera un registro de error conocido con las mismas características del problema

(categoría, subcategoría, síntomas, solución).

3.3 Los incidentes asociados al problema se colocan como resueltos.

3.4 Se envían notas de evaluación a los clientes de los incidentes asociados.


Asignar Problema. Registrar solución.

3.2. Consultar Problema


Descripción: El usuario consulta los datos de los Problemas registrados.



Referencias cruzadas: R2, R2.3, R2.3.1, R2.3.2, R2.3.3, R2.3.4, R2.3.5.


112



1. El caso de uso comienza cuando el usuario selecciona la opción de Consultas/Problemas.


• Por número de referencia. • Por estado • Por categoría. • Por subcategoría. • Por analista. • Por fecha de registro.

Y el sistema muestra una lista de todos los problemas no resueltos.


4. El sistema muestra los problemas que satisfacen las opciones seleccionadas.

5. El usuario hace click en la palabra ver del problema deseado.

6. El sistema muestra los datos correspondientes al problema seleccionado.

Cursos alternos:

• Paso 4: No hay problemas registrados que cumplan las opciones de búsqueda.

4.1 El sistema muestra un mensaje y aparece la lista de problemas vacía.


5.1 Se inicia el caso de uso Modificar Problema.


6.1 Se imprime el resumen de los datos del problema.

• Paso 6: El usuario desea consultar otro problema.

6.1 Hace click regresar y comienza de nuevo el caso de uso Consultar problema.


Modificar Problema, Asignar problema, Registrar solución.

3.3. Asignar Problema

Actores Principales: Usuario (Soporte)

Descripción: El usuario asigna el problema a otro usuario Soporte.


113

Precondición: El usuario al que se le asigna el problema debe estar registrado en el sistema.

Poscondición: El problema es asignado al usuario y se le envía una nota de asignación.

Referencias cruzadas: R1.5, R1.5.2, R1.7.



1. El caso de uso comienza cuando el usuario cambia el estado del problema a asignado o cuando cambia a la persona encargada del problema. Esto puede ocurrir cuando se modifica un problema.

2. El sistema muestra la lista de las personas a las cuales se les puede asignar el problema.

3. El usuario selecciona el nombre de usuario de la persona a la cual desea asignarle el problema.

4. El usuario continúa modificando el problema y presiona Guardar.

5. El sistema asigna el problema a la persona seleccionada y le envía una nota de asignación.


Cursos alternos:

Ninguno.


Ninguno.

4. Manejar Errores Conocidos

4.1. Modificar Error Conocido


Descripción: El usuario modifica los datos de los errores conocidos registrados.


Poscondición: Se almacenan los cambios realizados al Error conocido.



114



1. El caso de uso comienza cuando el usuario selecciona la opción de Actualizar luego de haber realizado una consulta de Errores.

2. El sistema muestra los datos del Error conocido seleccionado.


4. El sistema almacena los nuevos datos del Error Conocido.

5. El sistema regresa a la página de consulta de errores conocidos, donde se inició el caso de uso.

Cursos alternos:

• Paso 3: El usuario desea registrar una nueva solución al error conocido.

3.1 Se inicia el caso de uso registrar solución.


Registrar solución.

4.2. Consultar Error Conocido


Descripción: El usuario consulta los datos de los Errores Conocidos registrados.



Referencias cruzadas: R3, R3.3



1. El caso de uso comienza cuando el usuario selecciona la opción de Consultas/Error Conocido.


115


• Por número de referencia. • Por categoría. • Por subcategoría. • Por fecha de registro.

Y el sistema muestra una lista de todos los errores conocidos del mes en curso.


4. El sistema muestra los errores conocidos que satisfacen las opciones seleccionadas.

5. El usuario hace click en la palabra ver del error conocido deseado.

6. El sistema muestra los datos correspondientes al error seleccionado.

Cursos alternos:

• Paso 4: No hay errores conocidos registrados que cumplan las opciones de búsqueda.

4.1 El sistema muestra un mensaje y aparece la lista de errores conocidos vacía.


5.1 Se inicia el caso de uso Modificar Error Conocido.


6.1 Se imprime el resumen de los datos del error conocido.

• Paso 6: El usuario desea consultar otro error conocido.

6.1 Hace click regresar y comienza de nuevo el caso de uso Consultar error conocido.


Modificar error conocido, Registrar solución.

5. Manejar Evaluaciones

5.1. Registrar Evaluación.

Actor Principal: Usuario (Cliente)

Descripción: El usuario realizar el registro de la evaluación del servicio recibido para un Incidente.

Precondición: El Incidente debe estar resuelto.

Poscondición: Se crea la evaluación asociada a un Incidente.



116



1. El caso de uso comienza cuando el usuario selecciona la opción de Registrar/Evaluación o cuando hace click en el link que se encuentra en la nota de confirmación de solución del incidente.

2. El sistema carga la lista de todos los incidentes sin evaluar que posee el usuario.

3. El sistema solicita ingresar los siguientes campos: • Número de referencia del incidente. • Tiempo de atención • Tiempo de solución. • Calidad de la solución. • Atención amable del analista. • Evaluación general. • Comentarios.


5. El sistema almacena los datos de la evaluación.

6. El sistema muestra en la lista de incidentes evaluados la nueva evaluación.

Cursos alternos:

• Paso 1: El usuario hace click en un link perteneciente a un incidente ya evaluado.

1.1 El sistema muestra un mensaje informando al usuario que el incidente ya fue evaluado.

• Paso 2: El usuario no tiene incidentes por evaluar.

2.1 El sistema muestra un mensaje informando al usuario que no tiene incidentes sin evaluar.


Ninguno.

5.2. Consultar Evaluación.

Actores Principal: Usuario (Cliente, Soporte).

Descripción: El usuario consulta los datos de la Evaluación realizada al Incidente.

Precondición: El incidente debe haber sido evaluado.




117



1. El caso de uso comienza cuando el usuario selecciona la opción de Consultas/Evaluación


• Por fecha de registro. Y el sistema muestra una lista de todos los incidentes evaluados en el mes en curso.


4. El sistema muestra los incidentes evaluados que satisfacen las opciones seleccionadas.

5. El usuario hace click en la palabra ver del incidente deseado.

6. El sistema muestra los datos de la evaluación correspondientes al incidente seleccionado.

Cursos alternos:

• Paso 2. El usuario que realiza la consulta es tipo Soporte.

2.1 El sistema agrega las siguientes opciones de consulta: Por número de referencia del incidente,

por cliente y por analista encargado del incidente.

• Paso 4: No hay incidentes evaluados que cumplan las opciones de búsqueda.

4.1 El sistema muestra un mensaje y aparece la lista de incidentes evaluados vacía.


6.1 Se imprime el resumen de los datos de la evaluación.

• Paso 6: El usuario desea consultar otra evaluación.

6.1 Hace click regresar y comienza de nuevo el caso de uso Consultar evaluación.


Ninguno.

6. Manejar Solicitudes.

6.1. Registrar Solicitud.


Descripción: El usuario introduce los datos solicitados para realizar el registro de los procedimientos que

son considerados como solicitudes.


118


Poscondición: Se crea un nuevo tipo de solicitud.

Referencias cruzadas: R9, R9.1.



1. El caso de uso comienza cuando el usuario selecciona la opción de Administrativo/Solicitud

2. El sistema solicita ingresar los siguientes campos: • Nombre corto de la solicitud. • Categoría. • Nombre de la acción y responsable. • Nombre del dato adicional.

3. El usuario ingresa los datos solicitados.

4. El usuario introduce el nombre de la acción, selecciona el responsable y presiona ok.

5. El sistema muestra en pantalla la acción y solicita el orden de ejecución de la acción.

6. El usuario coloca el orden de ejecución de la acción.

7. El usuario introduce el nombre del dato adicional y presiona ok.

8. El sistema muestra en pantalla el nombre del dato adicional.

9. El usuario presiona guardar.

10. El sistema almacena los datos de la solicitud.

11. El sistema muestra en la lista de solicitudes la nueva solicitud.

Cursos alternos:

• Paso 4. El usuario desea colocar más de una acción.

4.1 Se repiten los pasos 4, 5 y 6 tantas veces como acciones se deseen colocar.

• Paso 7. El usuario desea colocar más de un dato adicional.

7.1 Se repiten los pasos 7 y 8 tantas veces como datos se deseen colocar.

• Paso 9. El usuario desea eliminar una acción o un dato adicional.

9.1 El usuario hace click en eliminar en la lista de acciones o datos adicionales según sea el caso.


119


Modificar solicitud, Consultar solicitud.

6.2. Modificar Solicitud


Descripción: El usuario modifica los datos de las solicitudes registradas.


Poscondición: Se almacenan los cambios realizados a la Solicitud.




1. El caso de uso comienza cuando el usuario hace click en la palabra actualizar de una solicitud en la lista de solicitudes que aparece en la página de solicitudes.

2. El sistema carga la página de registro de solicitudes con los datos de la solicitud seleccionada.


4. El sistema almacena los nuevos datos de la Solicitud.

5. El sistema regresa a la página de solicitudes donde se inició el caso de uso

Cursos alternos:

Ninguno.


Consultar solicitud.

6.3. Consultar Solicitud.


Descripción: El usuario consulta los datos de las Solicitudes registradas.



Referencias cruzadas: R9.


120



1. El caso de uso comienza cuando el usuario hace click en la palabra ver de la lista de solicitudes luego de seleccionar la opción de Administrativo/Solicitud.

2. El sistema muestra en pantalla los datos de la solicitud seleccionada.

Cursos alternos:

• Paso 1: No hay solicitudes registradas.

1.1 El sistema muestra un mensaje y aparece la lista de solicitudes vacía.


2.1 Se imprime el resumen de los datos de la solicitud.

• Paso 2: El usuario desea consultar otra solicitud.

2.1 Hace click regresar y comienza de nuevo el caso de uso Consultar solicitud.


Ninguno.

7. Manejar Soluciones.

7.1. Registrar Solución.

7.1.1. Para un Problema


Descripción: El usuario introduce los datos necesarios para registrar una solución para un Problema.


Poscondición: Se crea la solución al problema.




1. El caso de uso comienza cuando el usuario modifica el estado de un problema y lo coloca como Resuelto.

2. El sistema solicita ingresar los siguientes campos:

• Responsable de la solución. • Procedimiento de la solución.


121


4. El sistema continúa con el caso de uso modificar problema que es donde se inicia este caso de uso.

Cursos alternos:

Ninguno.


Ninguno

7.1.2. Para un Error Conocido


Descripción: El usuario introduce los datos necesarios para registrar una solución para un Error Conocido.


Poscondición: Se crea una nueva solución para un Error Conocido.




1. El caso de uso comienza cuando el usuario modifica un error conocido y desea registrar una nueva solución para el mismo.

2. El sistema solicita ingresar los siguientes campos:

• Procedimiento de la solución. 3. El usuario ingresa los datos solicitados y presiona ok.

4. El sistema agrega la solución a la lista de soluciones del error.

5. El sistema continúa con el caso de uso modificar error conocido que es donde se inicia este caso de uso.

Cursos alternos:

• Paso 3: El usuario desea agregar más de una solución.

3.1 El usuario repite el paso 3 tantas veces como soluciones desee agregar.


Ninguno


122

7.2. Consultar Solución.


Descripción: El usuario consulta los datos de las Soluciones registradas

Precondición: Se debe consultar el problema o el error conocido para poder consultar sus soluciones.


Referencias cruzadas: R2.3, R3.3



1. El caso de uso comienza cuando el usuario consulta un problema o un error conocido.

2. El sistema muestra en el resumen de los datos, las soluciones correspondientes al problema o al error conocido que se consulta.

Cursos alternos:

Ninguno.


Ninguno.

7.3. Buscar Solución.


Descripción: El usuario busca en la base de conocimientos una solución al incidente.

Precondición: El incidente debe estar registrado.

Poscondición: El incidente puede ser asociado a un problema, a un error conocido o se puede generar un

nuevo registro de problema.

Referencias cruzadas: R2, R2.1, R2.5, R3, R3.5, R8.



1. El caso de uso comienza cuando en el caso de uso modificar incidente, el usuario oprime buscar solución.

2. El sistema muestra la lista de errores conocidos, y sus soluciones, que podrían darle solución al incidente según sus características.


123

3. El usuario selecciona el error conocido y la solución que desea y presiona Asociar Error.

4. El sistema asocia el incidente al error conocido seleccionado, registra la solución del incidente y coloca el incidente como resuelto.


Cursos alternos:

• Paso 2: No hay errores conocidos que correspondan con las características del incidente.

2.1 El sistema muestra la lista de problemas no resueltos que corresponda con las características

del incidente.

• Paso 2: No hay errores conocidos ni problemas no resueltos que correspondan con las características

del incidente.

2.1 El sistema muestra un mensaje informando al usuario que no hay soluciones sugeridas.

2.2 El usuario hace click en crear problema.

2.3 El sistema genera un nuevo registro de problema con las mismas características del incidente.

• Paso 3: El usuario no desea ninguna de las soluciones sugeridas.

3.1 El usuario hace click en buscar en problemas y comienza el caso de uso Buscar en Problemas.


Buscar en Problemas

7.3.1. Buscar en Problemas


Descripción: El usuario busca en la base de conocimientos una solución al incidente.

Precondición: El incidente debe estar registrado.

Poscondición: El incidente puede ser asociado a un problema o se puede generar un nuevo registro de

problema.

Referencias cruzadas: R2, R2.1, R2.5, R8



1. El caso de uso comienza cuando en el caso de uso buscar solución el usuario oprime Buscar en Problemas.


124

2. El sistema muestra la lista de problemas no resueltos que podrían estar relacionados con el incidente según sus características.

3. El usuario selecciona el problema deseado y presiona Asociar Problema.

4. El sistema asocia el incidente al problema seleccionado, y coloca el incidente como en proceso.


Cursos alternos:

• Paso 2: No hay problemas no resueltos que correspondan con las características del incidente.

2.1 El sistema muestra un mensaje informando al usuario que no hay soluciones sugeridas.



• Paso 3: El usuario no desea asociar el incidente a ninguno de los problemas sugeridos.




Ninguno.

8. Control de Solicitudes.

8.1. Registrar Actividades Realizadas.


Descripción: El usuario registra la actividad realizada para un incidente de tipo solicitud.

Precondición: Se debe haber creado un incidente de tipo solicitud.

Poscondición: Se registra la actividad realizada para un incidente y la persona que la realizó.




1. El caso de uso comienza cuando el usuario hace click en Actualizar en la lista de incidentes que aparece en la página Control de Actividades/Control de Solicitudes.


125

2. El sistema muestra los datos del cliente, del incidente y la lista actividades correspondientes al tipo de solicitud a la cual pertenece el incidente.

3. El usuario hace check en la actividad realizada, selecciona el nombre de la persona que realizó la actividad y presiona Guardar.

4. El sistema registra la actividad realizada y genera y envía una nota de aviso al responsable de ejecutar la siguiente actividad.


Cursos alternos:

• Paso 4: El usuario realizó la última actividad.

4.1 El sistema coloca el incidente como resuelto y envía una nota de confirmación de solución al

cliente del incidente.


Ninguno

8.2. Consultar Actividades Realizadas.


Descripción: El usuario consulta el estado de los incidentes de tipo solicitud.


Poscondición: Ninguna




1. El caso de uso comienza cuando el usuario selecciona en el menú principal la opción Control de Actividades/Control de Solicitudes.

2. El sistema muestra la lista de los tipos de solicitudes.

3. El usuario selecciona el tipo de solicitud deseado.

4. El sistema muestra un cuadro con las actividades correspondientes al tipo de solicitud, los incidentes registrados de ese tipo y el nombre de la persona que realizó cada actividad para cada incidente.


126

Cursos alternos:

Ninguno.


Ninguno

9. Manejar Reportes

9.1. Generar Reporte.


Descripción: El usuario puede generar reportes estadísticos de incidentes, errores y problemas.






1. El caso de uso comienza cuando el usuario selecciona en el menú principal la opción Reportes/Generar Reportes.

2. El sistema los tipos de reportes que se pueden generar.

3. El usuario selecciona el tipo de reporte deseado.

4. El sistema muestra los datos del reporte.

Cursos alternos:

Ninguno.


Imprimir reporte.

9.2. Imprimir Reporte.


Descripción: El usuario puede imprimir el reporte generado.

Precondición: Se debe haber generado el reporte.



127




1. El caso de uso comienza cuando el usuario oprime imprimir luego de generar el reporte.

2. El sistema imprime los datos del reporte.

Cursos alternos:

Ninguno.


Ninguno.

10. Manejar Usuarios

10.1. Crear Usuario.


Descripción: El usuario introduce los datos para registrar un nuevo usuario al sistema.


Poscondición: Se registra un nuevo usuario en el sistema.

Referencias cruzadas: R6, R6.1, R7



1. El caso de uso comienza cuando el usuario selecciona en el menú principal la opción Administrativo/Usuarios.

2. El sistema carga la página de registro de usuarios y solicita los siguientes datos:

• Nombre de usuario. • Nombre. • Apellido. • Correo Electrónico. • Departamento. • Cargo. • Teléfono (2). • Tipo de usuario


128

3. El usuario escribe el nombre de usuario de la persona que desea registrar y hace click en la flecha. Si no se conoce el nombre completo, se puede colocar incompleto.

4. El sistema busca en el directorio activo los usuarios y carga la lista de los nombres de usuario encontrados.


6. El sistema carga los datos disponibles del usuario que se registra.

7. El usuario selecciona el tipo de usuario.

8. El sistema solicita:

• Rol del usuario. • Nivel de soporte

9. El usuario introduce los datos solicitados y presiona guardar.

10. El sistema registra el nuevo usuario y carga nuevamente la página de registro de usuarios.

Cursos alternos:

• Paso 6: Los datos del nuevo usuario no están completos.

6.1 El usuario completa los datos que sean obligatorios.

• Paso 7: El tipo de usuario seleccionado es coordinador.

7.1 El sistema solicita los siguientes datos: Inicio y fin del periodo de coordinación y turno.




Ninguno.

10.2. Modificar Usuario.


Descripción: El usuario modifica los datos de los usuarios del sistema.


Poscondición: Se almacenan los datos modificados.



129




2. El sistema carga la página de registro de usuarios

3. El usuario escribe el nombre de usuario de la persona que desea modificar y hace click en la flecha. Si no se conoce el nombre completo, se puede colocar incompleto.

4. El sistema busca en la base de datos los usuarios y carga la lista de los nombres de usuario encontrados.


6. El sistema carga los datos del usuario a modificar.

7. El usuario realiza los cambios deseados y presiona guardar.

8. El sistema registra los cambios realizados y carga nuevamente la página de registro de usuarios.

Cursos alternos:

Ninguno.


Eliminar usuario.

10.3. Eliminar Usuario.


Descripción: El usuario elimina usuarios del sistema.

Precondición: El usuario debe estar registrado en el sistema.

Poscondición: El usuario es eliminado del sistema.



130




2. El sistema carga la página de registro de usuarios

3. El usuario escribe el nombre de usuario de la persona que desea eliminar y hace click en la flecha. Si no se conoce el nombre completo, se puede colocar incompleto.

4. El sistema busca en la base de datos los usuarios y carga la lista de los nombres de usuario encontrados.


6. El sistema carga los datos del usuario a eliminar.

7. El usuario presiona eliminar.

8. El sistema elimina los datos del usuario.

Cursos alternos:

Ninguno


Ninguno.

11. Manejar Categorías.

11.1. Crear Categoría.


Descripción: El usuario crea una nueva categoría para la clasificación de incidentes, problemas y errores

conocidos.


Poscondición: Se crea una nueva categoría.

Referencias cruzadas: Ninguna.


131



1. El caso de uso comienza cuando el usuario selecciona en el menú principal la opción Administrativo/Categorías.

2. El sistema carga la página de registro de categorías y solicita los siguientes datos:

• Nombre de la categoría. • Nombre de la subcategoría.

3. El usuario escribe el nombre de la categoría. Para la subcategoría escribe “general” y presiona ok.

4. El sistema muestra la lista con los nombres de las subcategorías.

5. El usuario verifica los nombres y presiona guardar.

6. El sistema registra la nueva categoría y carga nuevamente la página de registro de categorías.

Cursos alternos:

• Paso 3: El usuario desea agregar más subcategorías.

3.1 El usuario escribe el nombre de la subcategoría y presiona ok tantas veces como

subcategorías desee agregar.


Ninguno.

11.2. Modificar Categoría.


Descripción: El usuario modifica una categoría de incidente.

Precondición: La categoría debe estar registrada.

Poscondición: Se almacenan los cambios en la categoría.

Referencias cruzadas: Ninguna.



1. El caso de uso comienza cuando el usuario selecciona en el menú principal la opción Administrativo/Categorías.


132

2. El sistema carga la página de registro de categorías.

3. El usuario selecciona el nombre de la categoría que desea modificar.

4. El sistema muestra la lista con los nombres de las subcategorías.

5. El realiza los cambios deseados (puede agregar más subcategorías).

6. El sistema registra los cambios realizados y carga nuevamente la página de registro de categorías.

Cursos alternos:

Ninguno.


Ninguno.

Apéndice H. Diccionario de Datos

133

APÉNDICE G. DIAGRAMAS DE SECUENCIA

A continuación se presentan los diagramas de secuencias correspondientes al curso normal de eventos de cada uno de los casos de uso.


134

:Sistema

Usuario (Soporte)

ConsultarIncidente(codigoInc)

Pagina de Registro con los datos del incidente

TerminarModificacion()

Mensaje de confirmación

Diagrama de Secuencia de Modificar Incidente

modificarIncidente(estado, sintomas, categoria,

subcategoria, impacto, urgencia)


135


136


137


138

:Sistema

Usuario (Soporte)ConsultarSolicitud()

Lista de Solicitudes

SeleccionarSolicitud(codigoSolicitud)

Datos de la Solicitud

Diagrama de Secuencia de Consultar Solicitud

:SistemaUsuario (Soporte)

ModificarProblema(estado="resuelto")

RegstrarSolucion(responsable, procedimiento)

TerminarRegistro()

Mensaje de confirmación

Diagrama de Secuencia de Registrar Solución para un Problema

ConsultarProblema()

Datos del Problema


139


140


141


142


143


144

APÉNDICE H. DICCIONARIO DE DATOS

El Diccionario de Datos de una base de datos explica detalladamente cada una de las tablas

identificadas en el Modelo Relacional producto de la traducción del Modelo Entidad – Relación. Para cada

una de las tablas relacionales, se presenta una breve descripción de la misma y sus atributos. Los detalles

de los atributos contienen el nombre del atributo, si posee la restricción de no nulidad, el tipo de dato,

identificación de claves primarias y foráneas y la descripción de atributo.

Tabla Descripción Detalles

Usuario

Almacena la información básica de los usuarios del sistema.

Atributo No nulo Tipo Descripción

Usu_username � Varchar2(25)

Clave primaria. Identifica unívocamente cada usuario.

Usu_nombre � Varchar2(20) Nombre del usuario.

Usu_apellido � Varchar2(20) Apellido del usuario.

Usu_telefono � Char(11) Teléfono del usuario.

Usu_telefonocel Char(11) Teléfono celular del usuario.

Usu_depto � Varchar2(50) Departamento al cual pertenece el usuario.

Usu_correo � Varchar2(50) Correo electrónico del usuario.

Usu_tipo � Varchar2(10) Tipo de usuario.

Usu_login Varchar2(25) Login del usuario. Usu_passw Varchar2(15) Password del usuario.

Usu_motivo Varchar2(50) Motivo de la visita de un usuario a la empresa.

Usu_tipocliente Varchar2(10) Indica el tipo de cliente.

Usu_turno Varchar2(10) Turno de trabajo del usuario.

Usu_inicioperiodo Date Inicio del periodo de coordinación del usuario.

Usu_finperiodo Date Fin del periodo de coordinación del usuario.

Usu_tipohelpdesk Varchar2(15) Indica el tipo de usuario de soporte.

Usu_cargo � Varchar2(50) Cargo del usuario.

Usu_rol Varchar2(50) Rol del usuario dentro del sistema.

Usu_nivel Varchar2(20) Nivel de soporte al cual pertenece el usuario.

Categoría

Almacena las categorías de clasificación de incidentes, problemas y errores conocidos.


Cat_codigo � Number(2)

Clave primaria. Identifica unívocamente cada categoría.

Cat_nombre � Varchar2(15) Nombre de la categoría.

Cat_subcat Varchar2(15) Nombre de la subcategoría.


145

Causa_Incidente Almacena las causas que pueden originar un incidente.


Cau_codigo � Number(10)

Clave primaria. Identifica unívocamente cada causa de incidente.

Cau_nombre � Varchar2(30) Nombre de la causa del incidente.

Cau_tipo � Varchar2(10) Indica el tipo de causa de incidente.

Cau_fechareg � Date Indica la fecha de registro de la causa.

Cau_horareg � Char(5) Indica la hora de registro de la causa.

Cau_cat_codigo � Number(2)

Clave foránea hacia Categoría. Indica la categoría de la causa del incidente.

Cau_tipofalla Varchar2(15) Indica el tipo de falla a la cual corresponde la causa del incidente.

Cau_sintomas Varchar2(100) Indica los síntomas de la causa del incidente.

Cau_estadoprob Varchar2(10) Indica el estado de la causa_incidente tipo problema.

Cau_tiempoprob Varchar2(15)

Indica el tiempo que dura un problema desde que se crea hasta que se resuelve.

Cau_prob_error Number(10)

Clave foránea hacia Causa_incidente. Indica el error conocido que se genera cuando un problema se resuelve.

Cau_usu_resp Varchar2(25)

Clave foránea hacia Usuario. Indica el usuario responsable de resolver el problema

Prioridad

Almacena los niveles de prioridad para la atención de los incidentes.


Pri_codigo � Number(2)

Clave primaria. Identifica unívocamente cada nivel de prioridad.

Pri_nombre � Varchar2(15) Nombre de la prioridad.

Pri_impacto � Varchar2(10) Nivel de impacto del incidente.

Pri_urgencia � Varchar2(10) Nivel de urgencia del incidente

Incidente Almacena los registros de incidentes reportados.


Inc_codigo � Number(10)

Clave primaria. Identifica unívocamente cada incidente.

Inc_nombre � Varchar2(50) Nombre corto del incidente.

Inc_estado � Varchar2(10) Indica el estado del incidente.

Inc_sintomas � Varchar2(100) Indica los síntomas del incidente.

Inc_fehareg � Date Indica la fecha de registro del incidente.

Inc_horareg � Char(5) Indica la hora de registro del incidente.


146

Inc_formareg � Varchar2(15) Indica la forma en la cual el cliente reporta el incidente.

Inc_fechasol Date Indica la fecha en la que se soluciona el incidente.

Inc_fechaeva Date

Indica la fecha en la cual el cliente realiza la evaluación del incidente.

Inc_tipo � Varchar2(15) Indica el tipo de incidente.

Inc_usu_cliente � Varchar2(25) Indica el nombre del cliente que reporta el incidente.

Inc_usu_helpdesk Varchar2(25) Indica el nombre del usuario que registra el incidente.

Inc_cau_codigo Number(10)

Clave foránea hacia Causa_incidente. Indica el código de la causa del incidente.

Inc_pri_codigo Number(2) Clave foránea hacia Prioridad. Indica la prioridad del incidente.

Inc_cat_codigo Number(2) Clave foránea hacia Categoría. Indica la categoría del incidente

Inc_tiposolic Varchar2(30) Indica el tipo se solicitud a la cual pertenece el incidente.

Inc_solucion Number(5) Indica la solución del incidente.

Inc_horasol Char(5) Indica la hora de la solución del incidente.

Evaluación

Almacena las evaluaciones que realizan los clientes sobre el servicio recibido por cada incidente.


Eva_inc_codigo � Number(10)

Clave primaria. Clave foránea hacia Incidente. Indica a cual incidente pertenece la evaluación.

Eva_fecha � Date Indica a fecha de la evaluación.

Eva_tiempoatencion � Varchar2(20)

Indica la opinión del cliente con respecto al tiempo de atención del incidente.

Eva_tiemposolucion � Varchar2(20)

Indica la opinión del cliente con respecto al tiempo de solución del incidente.

Eva_calidadsolucion � Varchar2(20)

Indica la opinión del cliente con respecto a la calidad de la solución del incidente.

Eva_atencioncordial � Varchar2(20)

Indica la opinión del cliente con respecto a la atención cordial del analista de soporte.

Eva_evaluaciongen � Varchar2(20) Indica la evaluación general del incidente.

Eva_comentario Varchar2(250) Indica los comentarios del cliente sobre el servicio recibido.

Solución Almacena las soluciones de los


Sol_codigo � Number(5) Clave primaria. Identifica cada solución.


147

errores conocidos. Sol_descripcion � Varchar2(500) Indica la descripción de la solución.

Sol_usu_username � Varchar2(25) Indica el usuario que registra la solución.

Es_Solucion_De

Almacena la información que relaciona un error conocido con su solución.


Es_sol_codigo � Number(5)

Parte de la clave primaria. Clave foránea hacia Usuario. Indica el código de la solución.

Es_cau_codigo � Number(10)

Parte de la clave primaria. Clave foránea hacia Causa_incidente. Indica el código del error conocido.

Asigna

Almacena la información sobre los usuarios que asignan incidentes a otros usuarios.


Asi_usu_cod_asigna � Varchar2(25)

Parte de la clave primaria. Clave foránea hacia Usuario. Indica el usuario que asigna el incidente.

Asi_usu_cod_asignado � Varchar2(25)

Parte de la clave primaria. Clave foránea hacia Usuario. Indica el usuario al cual le fue asignado el incidente.

Asi_inc_codigo � Number(10)

Parte de la clave primaria. Clave foránea hacia Incidente. Indica el incidente asignado.

Asi_fecha � Date

Parte de la clave primaria. Indica la fecha de asignación del incidente.

Asi_hora � Char(5)

Parte de la clave primaria. Indica la hora de asignación del incidente.

Acción

Almacena la información sobre las acciones que corresponden al procedimiento de una solicitud.


Acc_cau_codigo � Number(10)

Parte de la clave primaria. Clave foránea hacia Causa_incidente. Indica la solicitud a la cual pertenece la acción.

Acc_nombre � Varchar2(50) Parte de la clave primaria. Indica el nombre de la acción.

Acc_responsable � Varchar2(50) Indica la persona responsable de ejecutar la acción.

Acc_orden � Number(2) Indica el orden en el cual debe ejecutarse la acción.


148

Inf_Solicitud

Almacena la información sobre los datos adicionales que son necesarios para una solicitud.


Inf_cau_codigo � Number(10)

Parte de la clave primaria. Clave foránea hacia Causa_incidente. Indica la solicitud a la cual pertenece el dato.

Inf_nombredato � Varchar2(30) Parte de la clave primaria. Indica el nombre del dato.

Inf_DatosSolicitud

Almacena la información sobre los datos adicionales de un incidente que sea de tipo solicitud.


Inf_datos_inc_codigo � Number(10)

Parte de la clave primaria. Clave foránea hacia Incidente. Indica el incidente al cual pertenece la información.

Inf_valordato � Varchar2(30) Parte de la clave primaria. Indica el valor del dato.

Inf_datos_nombredato � Varchar2(30) Indica el nombre del dato.

Proceso_Incidente

Almacena la información sobre las acciones de un incidente que sea de tipo solicitud.


Pro_inc_cod � Number(10)

Parte de la clave primaria. Clave foránea hacia Incidente. Indica el incidente al cual pertenece el proceso.

Pro_inf_cau_codigo � Number(10)

Parte de la clave primaria. Clave foránea hacia Acción. Indica la acción que se está realizando.

Pro_inf_nombre � Varchar2(100)

Parte de la clave primaria. Clave foránea hacia Acción. Indica el nombre de la acción.

Pro_realizada � Char(2) Indica si la acción fue realizada.

Pro_orden � Number(2) Indica el orden de la acción.

Pro_ejecutadapor Varchar2(50) Indica el nombre de la persona que realizó la acción.

Apéndice I. Mapas de Navegación

149

APÉNDICE I. MAPAS DE NAVEGACIÓN

Figura I.1. Mapa de Navegación para el usuario tipo Cliente.

Figura I.2. Mapa de Navegación para el usuario tipo Soporte.

Apéndice J. Manual de Usuario

150

APÉNDICE J. MANUAL DE USUARIO

¿Qué es el Sistema Helpdesk?

El Sistema Helpdesk es un software diseñado con la finalidad de ofrecer a todos los usuarios un

punto de contacto único para la gestión y resolución de problemas y servicios de TI. El sistema fue

desarrollado en ambiente Web para un fácil manejo debido a la familiaridad que en la actualidad mantienen

los usuarios con dicho ambiente.

A través del sistema HelpDesk, usted podrá:

• Realizar el registro de Incidentes (fallas y solicitudes) del área de informática, además de

consultarlos y actualizarlos.

• Manejar una base de datos de conocimiento que contenga la información sobre los Errores

Conocidos y sus soluciones.

• Llevar el seguimiento de las actividades que se llevan a cabo para cada solicitud.

• Realizar reportes estadísticos sobre el servicio de helpdesk.

El software está dirigido a la comunidad del IESA para facilitar el proceso de reporte de incidentes y a

los miembros del grupo de informática de dicha institución, para facilitar la gestión de incidentes.

¿Qué hace el Sistema Helpdesk?

El sistema está basado en perfiles de usuario y dependiendo del tipo de usuario que ingrese, ofrece

diferentes funcionalidades.

Para los miembros de la comunidad del IESA (profesores, estudiantes, empleados administrativos),

que de ahora en adelante se denominará "Cliente", el sistema presenta las siguientes funcionalidades:


• Registro y consulta de evaluaciones.


151

Para los miembros del grupo de informática (empleados pertenecientes a la gerencia de

informática) que de ahora en adelante se denominará "Soporte", el sistema tiene las siguientes

funcionalidades:


• Consulta de evaluaciones.

• Actualización y consulta de problemas.

• Actualización y consulta de errores conocidos.

• Registro y consulta de tipos de solicitudes.

• Control de las actividades correspondientes a cada solicitud.

¿Cómo funciona Helpdesk?

1. Acceso

Para ingresar al Sistema Helpdesk, haga doble click en el icono de Internet Explorer y a

continuación escriba en la barra de direcciones lo siguiente: http://servicios.iesa.edu.ve/helpdesk.

Si el sistema operativo de su PC es Windows XP, el sistema solicitará

User Name = dominio\nombre_de_usuario y Password = contraseña donde el dominio es IESACCS.

Si el sistema operativo es Windows 2000, el sistema solicitará la misma información pero de la

siguiente forma:


152

El sistema valida el usuario y muestra la página de inicio dependiendo el tipo de usuario al

cual pertenezca. A continuación de explicará como funciona el sistema para cada tipo de usuario.

2. Usuario tipo "Cliente"

La página de inicio del sistema para usuarios tipo Cliente se muestra a continuación en la figura 1.

Figura 1. Pagina de Inicio

En el lado izquierdo de la pantalla, se muestra el Menú de Navegación, el cual permite acceder a

las diferentes funcionalidades del sistema.

El sistema cuenta con dos módulos básicos, el de Registro y el de Consultas. A continuación, se

explicará en detalle como utilizar cada uno de estos módulos.


153

2.1. Módulo de Registro

El sistema permite realizar el registro de incidentes y de evaluaciones.

Registro de Incidentes

Haciendo click en Registros/Incidente, se visualizará la página que se observa en la figura 2, la

cual permite realizar el registro de incidentes.

Figura 2. Registro de Incidentes.

El registro de Incidentes consta de dos partes, los datos del usuario y los datos del incidente.


154

Los datos del usuario, se cargan automáticamente y deben completarse los datos que no

aparezcan y estén marcados como requeridos.1

Luego de llenar los datos del usuario, se procede a llenar los datos del incidente. Lo primero que

se debe colocar es un nombre corto que describa el incidente que se está reportando.

Como se mencionó anteriormente, los incidentes pueden ser de dos tipos: solicitudes o fallas. Una

solicitud se reporta cuando se requiere algún servicio por parte del grupo te apoyo tecnológico, como por

ejemplo, instalación de un equipo o creación de una cuenta. Por su parte, una falla se reporta cuando algún

servicio o recurso de informática no funciona correctamente, por ejemplo, una impresora que no funciona o

problemas con el correo electrónico.

Si se selecciona un incidente de tipo SOLICITUD, aparece la siguiente pantalla:

Figura 3. Tipo Solicitud

1 Los datos requeridos estas marcados con un (*)


155

Se debe seleccionar el tipo de solicitud que se desea reportar. Si el tipo de solicitud seleccionado

requiere de alguna información adicional, se desplegará debajo del tipo de incidente, un área para

introducir dicha información, como se muestra en la figura 4

Figura 6. Información adicional para la solicitud.

Toda la información requerida debe ser llenada.

Si se selecciona un incidente de tipo FALLA, aparece la siguiente pantalla:

Figura 5. Tipo Falla

En el recuadro de Descripción de Síntomas, se debe colocar una breve descripción del problema

presentado, por ejemplo, La impresora del piso 6 no imprime, se le atora el papel.

Una vez llenados todos los campos, haga click en el botón Guardar.


156

En el resumen de los incidentes que aparece al final de la página, se muestran todos sus

incidentes registrados. Las flechitas al lado de cada titulo indican que haciendo click en ellas, se ordena la

lista por ese campo.

Luego de guardar el incidente, el sistema le enviará un correo electrónico, confirmando el registro e

informándole el número de caso asignado al incidente, el cual le permitirá consultarlo en un futuro.

Registro de Evaluaciones

Haciendo click en Registros/Evaluación, se visualizará la página que se observa en la figura 6, la

cual permite realizar el registro de evaluaciones.

Figura 6. Registro de Evaluación

Primero, se debe seleccionar el número de referencia del incidente que se va a evaluar.

Posteriormente, se debe seleccionar para cada característica, la opción que usted considere más

adecuado de acuerdo al servicio recibido.

Por último se debe hacer click en el botón Guardar.


157

2.2. Módulo de Consultas

Consulta de Incidentes

Haciendo click en Consultas/Incidente, se visualizará la página que se observa en la figura 7, la cual

permite consultar todos sus incidentes.

Figura 7. Consulta de Incidentes

Puede realizar tres tipos de consultas diferentes:

• Por el número de referencia del incidente. Para este tipo de búsqueda, debe introducir el número

que se le fue asignado al incidente que desea consultar y colocar el mes en el que fue registrado.

Si no recuerda el mes, puede seleccionar “Todos”.

• Por estado.

• Por fecha de registro.

También se pueden realizar consultas combinadas.

Seleccione las opciones de búsqueda y haga click en "Buscar". La lista de incidentes aparecerá en

la parte inferior de la página en el área de "Resumen de Incidentes"


158

Si desea consultar la información completa de un incidente en particular, haga click en la palabra

“Ver” del incidente deseado, en la lista que aparece en la parte inferior de la página, y aparecerá una

pantalla como la que se muestra en la figura 8.

Figura 8. Detalle Incidentes

Aquí tendrá la opción de imprimir el resumen (1) o volver a la página anterior (2)

Consulta de Evaluaciones

Haciendo click en Consultas/Evaluación, se mostrará la página que se observa en la figura 9, la

cual permite consultar las evaluaciones registradas.

Puede consultar las evaluaciones según el mes de registro del incidente al cual corresponden.

Seleccione el mes y haga click en "Buscar".

Si desea consultar la información completa de una evaluación en particular, haga click en la

palabra “Ver” del incidente deseado, y aparecerá una página como la que se muestra a continuación en la

figura 10.

(1) (2)


159

Figura 9. Consulta de Incidentes.

Figura 10. Detalle de Evaluación


3. Usuario tipo "Soporte"

La página de inicio del sistema para usuarios tipo Soporte se muestra a continuación en la figura 11.

En el lado izquierdo de la pantalla, se muestra el Menú de Navegación, el cual permite acceder a

las diferentes funcionalidades.

El sistema cuenta con cuatro módulos principales: Registro, Consultas, Control de Actividades

y Administrativo. A continuación, se explicará en detalle como utilizar cada uno de estos módulos.

(1) (2)


160

Figura 11. Página de Inicio.

3.1. Módulo de Registro

Registro de Incidentes

Haciendo click en Registros/Incidente, se visualizará la página que se observa en la figura 12, la cual

permite realizar el registro de incidentes.

El registro de Incidentes consta de dos partes obligatorias que son Datos del Usuario y Datos del

incidente y una parte opcional que es Soluciones Sugeridas.

Datos del Usuario

Para llenar los datos del usuario, se escribe el nombre de usuario de la persona que reporta el

incidente2 y se hace click en la flecha de búsqueda. A continuación, se carga una lista de usuarios según el

nombre colocado (figura 14). Se selecciona el nombre deseado y automáticamente se cargan los datos del

usuario seleccionado, como se muestra en la figura 5. Los datos que no aparezcan y sean requeridos3,

deben completarse.

2 Si no se conoce el nombre de usuario completo, se puede escribir el inicio de dicho nombre y el sistema buscará todos los

usuarios que coincidan.

3 Los datos requeridos estas marcados con un (*)


161

Figura 12. Registro de Incidentes


162

Figura 13. Datos de Usuario

Figura 14. Selección de Usuario.

Figura 15. Carga de Datos


163

Luego de llenar los datos del usuario, se procede a llenar los datos del incidente.

Datos del Incidente

Figura 16. Datos del Incidente

Lo primero que se debe colocar es un nombre corto que describa el incidente que se está

reportando. El estado del Incidente se establece por defecto como "NUEVO", es decir que no ha sido

asignado. Este estado se puede cambiar a "EN PROCESO" o "EN ESPERA" y asignársele a un analista de

soporte. Observe la figura 17.

Figura 17. Cambio de Estado.


164

Para asignar el incidente, simplemente seleccione el nombre de usuario de la persona a la cual se

lo desea asignar.

Luego del estado, se debe determinar el tipo de incidente. Los incidentes pueden ser de dos tipos:

solicitudes o fallas. Una solicitud se reporta cuando se requiere un servicio de TI, como por ejemplo,

instalación de un equipo o creación de una cuenta. Por su parte, una falla es cuando algún servicio o

recurso de informática no funciona correctamente, por ejemplo, una impresora que no imprime o problemas

con el correo electrónico.

Si se selecciona SOLICITUD, aparece un campo para seleccionar el tipo de solicitud deseada,

como se muestra a continuación:

Figura 18. Cambio de Tipo de Incidente.

Se debe seleccionar el tipo de solicitud que se desea reportar. Si el tipo de solicitud seleccionado

requiere de alguna información adicional, se desplegará debajo del tipo de incidente, un área para

introducir dicha información, como se muestra en la figura 19.

Toda la información requerida debe ser llenada.


165

Figura 19. Datos adicionales de la solicitud.

Si por el contrario, se selecciona un incidente de tipo FALLA, la pantalla aparece de la siguiente

forma:

Figura 20. Cuadro de Síntomas.

En el recuadro de Descripción de Síntomas, se debe colocar una breve descripción del problema

presentado, por ejemplo, La impresora del piso 6 no funciona.

También se debe seleccionar la forma de contacto, que se refiere al medio que utilizó el usuario

para reportar su incidente.


166

Figura 21. Forma de Contacto.

Por último, se debe seleccionar Categoría, Subcategoría, Urgencia e Impacto del Incidente. Estos

pasos se resumen en la figura 22.

Figura 22.

Después de llenar todos los campos, se debe hacer click en el botón Guardar.

Una vez guardado el incidente, se le asigna un número de caso y una prioridad, y se muestra la

información como se aparece en la figura 23.


167

Figura 23. Información completa del incidente.

Luego de guardar el incidente, el sistema enviará un correo electrónico al usuario, confirmando el

registro e informándole el número de caso asignado al incidente, el cual le permitirá consultarlo en un

futuro.

Para registrar un nuevo incidente, se hace click en el botón "Nuevo Incidente".

Si se desea buscar soluciones sugeridas para el incidente, se hace click en el botón "Buscar

Solución".

Soluciones Sugeridas

Al hacer click en "Buscar Solución" se pueden obtener tres resultados distintos:

• Coincide con un Error Conocido:

El sistema compara los síntomas, la categoría y la subcategoría del incidente con los errores

conocidos registrados en el sistema, y si encuentra coincidencias, muestra la siguiente pantalla:


168

Figura 24. Solución sugerida: Error Conocido.

Para cada error existe una o más soluciones, que se pueden consultar en este momento para

escoger la más adecuada. Una vez seleccionada la solución, se hace check en la casilla de seleccione del

Error y se oprime el botón "Asociar". Estos pasos se ilustran en las figuras 25 y 26.

Al asociar un incidente a un error conocido, automáticamente se registra la solución y se coloca el

incidente con estado "Resuelto", se envía un correo al cliente indicándole que debe evaluar el servicio

recibido.

Figura 25. Selección de la solución adecuada.

Figura 26. Selección del Error y asociación con el incidente.


169

• Coincide con un Problema:

Si las sugerencias no son satisfactorias y se hace click en "Buscar en Problemas", o bien no se

consiguen errores que coincidan con las características del incidente, aparece una pantalla de la siguiente

forma:

Figura 27. Solución sugerida: Problema

Para asociar el incidente al problema, se selecciona el problema haciendo check en la casilla

correspondiente y se oprime el botón "Asociar". En este caso el incidente se quedará con estado "En

proceso", esperando la solución al problema.

• No hay coincidencias:

Si no se consiguen coincidencias con errores ni problemas con las características del incidente,

aparece una pantalla coma la que se muestra en la siguiente figura:

Figura 28. No hay sugerencias.

Para crear un problema nuevo, haga click en "Crear Nuevo Problema".

También se puede crear un problema nuevo si los problemas sugeridos no son satisfactorios,

haciendo click en el botón "Crear Nuevo Problema" de la figura 27.


170

Después de crear un problema, aparece el siguiente mensaje:

Figura 29. Creación de Problema.

3.2. Módulo de Consultas

Consulta de Incidentes

Haciendo click en Consultas/Incidente, se visualizará la página que se observa en la figura 30, la cual

permite consultar todos los incidentes.

Figura 30. Consulta de Incidentes


171

Puede realizar diferentes tipos de consultas. A continuación se explica una de ellas, la cual posee

cierta particularidad, para el resto simplemente se selecciona la opción deseada:

Para consultar por el número de referencia del incidente. Para este tipo de búsqueda, debe

introducir el número que se le fue asignado al incidente que desea consultar y colocar el mes en el que fue

registrado. Si no recuerda el mes, puede seleccionar “Todos”. También se pueden realizar consultas

combinadas.

Después de seleccionar las opciones de búsqueda, haga click en "Buscar" y se cargaran los

incidentes en la parte inferior de la página.

Si desea actualizar la información de un incidente en particular, haga click en la palabra

“Actualizar” del incidente deseado en la lista, y aparecerá la pantalla de registro de incidente con los datos

correspondientes al incidente seleccionado. (Ver figura 23).

Si desea consultar la información completa de un incidente en particular, haga click en la palabra

“Ver” del incidente deseado, en la lista que aparece en la parte inferior de la página, y aparecerá una

pantalla como la que se muestra en la figura 31.


172

Figura 31. Detalle Incidente.


Consulta de Evaluaciones

Haciendo click en Consultas/Evaluación, se mostrará la página que se observa en la figura 32, la

cual permite consultar las evaluaciones registradas.

(1) (2)


173

Figura 32. Consulta Evaluaciones

Puede consultar las evaluaciones según el número de incidente, el cliente, el analista que lo tiene

asignado y el mes de registro del incidente al cual corresponden. Seleccione las opciones de búsqueda y

presione "Buscar". La lista de evaluaciones se cargara en la parte inferior de la página.

Para consultar la información completa de una evaluación, haga click en la palabra “Ver” del

incidente, y aparecerá una página como la que se muestra a continuación:

Figura 32. Detalle Evaluación.

Aquí tendrá la opción de imprimir el resumen (1) o volver a la página anterior (2).

Consulta de Errores Conocidos

Haciendo click en Consultas/Error Conocido, se mostrará la página que se observa en la figura 33,

la cual permite consultar los errores conocidos registrados.

(1)


174

Figura 33. Consulta de Errores Conocidos.

Seleccione las opciones de búsqueda deseadas y luego haga click en "Buscar". La lista de errores

conocidos de cargará en la parte inferior de la pagina.

Para consultar los detalles de un error en particular, haga click en la palabra “Ver” del error

deseado y aparecerá la siguiente pantalla:

Figura 34. Detalle Error Conocido

Para actualizar los datos de un error en particular, haga click en “Actualizar” y aparecerá la

pantalla de registro de error, como se muestra en la figura 35.


175

Figura 35. Registro de Error Conocido.

Para agregar nuevas soluciones, escriba el procedimiento de la solución en el campo (A) y luego

presione "OK". La nueva solución aparecerá en la lista de soluciones.

Figura 36. Registro de nuevas soluciones.

Luego de realizar los cambios, oprima "Guardar".

(A)


176

Consulta de Problemas

Haciendo click en Consultas/Problema, se mostrará la página que se observa en la figura 37, la

cual permite consultar los problemas registrados.

Figura 37. Consulta Incidente

Seleccione las opciones de búsqueda deseadas y luego haga click en "Buscar". La lista de

problemas de cargará en la parte inferior de la pagina.

Si desea consultar la información completa de un problema en particular, haga click en la palabra

“Ver” del problema deseado, en la lista de problemas y aparecerá una pantalla como la que se muestra en

la figura 38.

Si desea actualizar la información de un problema en particular, haga click en la palabra

“Actualizar” del problema deseado y se mostrará la pantalla de registro de problema con los datos

correspondientes. Observe la siguiente figura 39.


177

Figura 38. Detalle Problema.

Figura 39. Registro Problema.

Se puede cambiar el estado del problema a "Asignado" y asignárselo a un analista (como se

muestra en la figura 40) o cambiarlo a "Resuelto" y registrar la solución (como se muestra en la figura 41).


178

Figura 40. Asignación de problema.

Figura 41. Registro de solución al problema.

Los problemas que han sido resueltos, no pueden ser modificados, por lo tanto, si hace click en la

palabra "Actualizar" (figura 37) de un problema resuelto, aparece la siguiente pantalla:


179

Figura 42. No se puede actualizar problema.

3.3. Módulo de Control de Actividades

Control de Solicitudes

Haciendo click en Control de Actividades/Control de Solicitudes, se mostrará la página que se

observa en la figura 43.

Figura 43. Control de Solicitudes

(A)


180

Seleccione el nombre de la solicitud que desea consultar (A), y aparecerá un cuadro donde se

representa la matriz de ejecución de cada actividad para cada incidente según el tipo de solicitud. Véase

figura 44.

Figura 44. Matriz de Ejecución.

Si se desea registrar la ejecución de una nueva actividad para un incidente, haga click en

"Actualizar" en el incidente deseado, en la lista que aparece al final de la página. Se mostrará la siguiente

página:

Figura 45. Actualización de Actividades.

Actividad

Responsable

Incidente


181

Marque con un check la actividad realizada4 y seleccione el nombre de la persona que la realizó,

como se muestra en la figura 46.

Figura 46. Actividad realizada. Selección de responsable.

3.4. Módulo Administrativo

Categorías

Haciendo click en Administrativo/Categorías, se mostrará la página que se observa en la figura 47.

Para registrar una nueva categoría, escriba el nombre de la categoría en el campo (A) y agregue

las subcategorías. Siempre que se cree una categoría nueva, se le debe agregar una subcategoría con el

nombre "general".

4 Las actividades deben realizarse en orden secuencial y una a la vez.


182

Figura 47. Registro de categorías.

Para agregar subcategorías, escriba el nombre de la subcategoría en el campo (B) y presione

"OK". Aparecerá un recuadro con la subcategoría agregada (figura 48). Repita este procedimiento para

cada subcategoría. Para finalizar, haga click en "Guardar". La nueva categoría aparecerá listada en el

resumen de categorías.

Figura 48. Registro de Subcategorías

(A)

(B)


183

En caso de que desee agregar nuevas subcategorías a las categorías existentes, seleccione la

categoría y repita el procedimiento de agregación de subcategorías explicado anteriormente.

Solicitudes

Haciendo click en Administrativo/Solicitudes, aparece la página que se observa en la figura 49, la

cual permite registrar la información necesaria para cada tipo de solicitud.

Figura 49. Registro de Solicitudes

Escriba el nombre se la solicitud en el campo (A) y seleccione la categoría y subcategoría a la cual

pertenecerá la solicitud (en el campo (B)).

Figura 50. Datos generales de la solicitud.

Para registrar las actividades que se deben llevar a cabo para cumplir la solicitud realice los

siguientes pasos:

(A) (B)

(C) (D)

(E)

(A) (B)


184

- Escriba el nombre de la actividad (campo (C)).

- Seleccione el nombre del rol responsable de ejecutar la actividad (campo (D)).

- Presione "OK"

Repita el mismo procedimiento para cada actividad.

A medida que registra las actividades, se irá llenando una lista. En caso de equivocación, puede

eliminar alguna de las actividades. Una vez registradas todas las actividades, se debe colocar el orden de

ejecución como se muestra en la figura 51. Este orden debe ser secuencial y no puede haber números

repetidos.

Figura 51. Procedimiento de la Solicitud

Algunas solicitudes pueden requerir que se registre información adicional, para ello, ingrese el

nombre de estos datos como se explica a continuación:

- Escriba el nombre del dato en el campo (E)

- Presione "OK".

Repita el procedimiento para cada dato necesario.

A medida que registra los datos, se irá llenando una lista. En caso de equivocación, puede eliminar

alguno de los datos. Observe la figura 52.

(C) (D)


185

Figura 52. Datos necesarios para la solicitud

Luego de llenar toda la información, haga click en "Guardar". La solicitud creada aparecerá en la

lista de Resumen de Solicitudes.

Si desea consultar la información completa de una solicitud en particular, haga click en la palabra

“Ver”, en la lista de solicitudes y aparecerá una pantalla como la que se muestra en la figura 53.

Figura 53. Detalle Solicitud.

Si desea actualizar la información de una solicitud, haga click en la palabra “Actualizar” de la

solicitud deseada y se mostrará la pantalla de registro de solicitud con los datos correspondientes. Observe

la siguiente figura.

(E)


186

Se pueden agregar nuevas actividades, cambiar el orden de ejecución de las mismas y agregar

nuevos datos requeridos. No se pueden eliminar las actividades y datos existentes.

Figura 54. Actualización de Solicitudes.

Usuarios

Haciendo click en Administrativo/Usuarios, aparece la página que se observa en la figura 55, la

cual permite registrar y actualizar la información de usuarios tipo "Soporte".


187

Figura 55. Registro de Usuarios

El nombre de usuario se carga de forma similar a como se cargan para el registro de incidentes,

escribiendo el nombre en el campo (A), haciendo click en la flecha de búsqueda y seleccionando el usuario

deseado. Llene todos los campos requeridos.

Seleccione el tipo de usuario y el sistema le solicitará información adicional como se muestra en

las figuras 56 y 57.

Figura 56. Selección del Tipo de Usuario.

(A)


188

Figura 57. Selección del Tipo de Usuario

Si se selecciona como tipo de usuario "Coordinador de Soporte Técnico", se le pedirá que indique:

fecha de inicio del periodo de coordinación, fecha de fin de periodo y el turno, como se muestra en la figura

58.

Figura 58. Tipo de usuario: " Coordinador de Soporte Técnico"

Al finalizar, haga click en "Guardar".


189

Para actualizar los datos de un usuario ya registrado, siga los mismos pasos como si lo fuera a

registrar como nuevo, a diferencia, el sistema cargará toda la información almacenada. Realice los

cambios y oprima "Guardar".

NOTA: Es fundamental que al empezar la jornada de trabajo, se seleccione un coordinador de

soporte técnico para el turno de la mañana y uno para el turno de la tarde. Además, se deben

cambiar el rol de los coordinadores del día anterior a "Analistas de Soporte Técnico"

Documents

Desarrollo de un plan de soporte