desarrollo de un plan de soporte
DESCRIPTION
Desarrollo de un plan de soporteTRANSCRIPT
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
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
Presentado por:
EVELICE BEATRIZ GUIA CAÑIZALEZ
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
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
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.
Capítulo II. Planteamiento del Problema
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.
Capítulo II. Planteamiento del Problema
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.
Capítulo III. Entorno Empresarial
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
Capítulo III. Entorno Empresarial
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]
Capítulo III. Entorno Empresarial
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
Capítulo IV. Marco Teórico
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.
Capítulo IV. Marco Teórico
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
Capítulo IV. Marco Teórico
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).
Capítulo IV. Marco Teórico
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
Capítulo IV. Marco Teórico
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.
Capítulo V. Metodología de Desarrollo
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.
Capítulo V. Metodología de Desarrollo
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
Capítulo VI. Marco Tecnológico
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
Capítulo VI. Marco Tecnológico
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]
Capítulo VI. Marco Tecnológico
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
Capítulo VII. Desarrollo del Sistema
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.
Capítulo VII. Desarrollo del Sistema
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.
Capítulo VII. Desarrollo 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.
Capítulo VII. Desarrollo del Sistema
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.
Capítulo VII. Desarrollo del Sistema
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.1. Asociados a un analista.
R2.3.2. Por categoría.
R2.3.3. Por estado.
Capítulo VII. Desarrollo del Sistema
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.
R3.5. Llevar el registro del número de incidentes 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.
Capítulo VII. Desarrollo del Sistema
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.
Capítulo VII. Desarrollo del Sistema
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.
Capítulo VII. Desarrollo del Sistema
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.
Capítulo VII. Desarrollo del Sistema
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
Capítulo VII. Desarrollo del Sistema
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.
Capítulo VII. Desarrollo del Sistema
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
Capítulo VII. Desarrollo del Sistema
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.
Capítulo VII. Desarrollo del Sistema
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.
Capítulo VII. Desarrollo del Sistema
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.
Capítulo VII. Desarrollo del Sistema
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.
Capítulo VII. Desarrollo del Sistema
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]
Capítulo VII. Desarrollo del Sistema
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.
Capítulo VII. Desarrollo del Sistema
42
• Dependencias.
En la figura 11 se puede observar el diagrama de clases elaborado para el sistema HelpDesk.
Figura 11. Diagrama de Clases.
Capítulo VII. Desarrollo del Sistema
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.
Capítulo VII. Desarrollo del Sistema
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.
Capítulo VII. Desarrollo del Sistema
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.
Capítulo VII. Desarrollo del Sistema
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.
Capítulo VII. Desarrollo del Sistema
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.
Capítulo VII. Desarrollo del Sistema
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.
Capítulo VII. Desarrollo del Sistema
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.
Capítulo VII. Desarrollo del Sistema
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.
Capítulo VII. Desarrollo del Sistema
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.
Capítulo VII. Desarrollo 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
Capítulo VII. Desarrollo del Sistema
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
Capítulo VII. Desarrollo del Sistema
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
Capítulo VII. Desarrollo del Sistema
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
Capítulo VII. Desarrollo del Sistema
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:
Capítulo VII. Desarrollo del Sistema
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
Apéndice A. Modelo Conceptual de la Gestión de Incidentes según ITIL
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.
Apéndice A. Modelo Conceptual de la Gestión de Incidentes según ITIL
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
Apéndice A. Modelo Conceptual de la Gestión de Incidentes según ITIL
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.
Apéndice A. Modelo Conceptual de la Gestión de Incidentes según ITIL
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”
Apéndice A. Modelo Conceptual de la Gestión de Incidentes según ITIL
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
Apéndice A. Modelo Conceptual de la Gestión de Incidentes según ITIL
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.
Apéndice A. Modelo Conceptual de la Gestión de Incidentes según ITIL
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
Apéndice A. Modelo Conceptual de la Gestión de Incidentes según ITIL
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.
Apéndice A. Modelo Conceptual de la Gestión de Incidentes según ITIL
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.
Apéndice A. Modelo Conceptual de la Gestión de Incidentes según ITIL
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.
Apéndice B. Plan de Desarrollo del Proyecto Helpdesk
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.
Apéndice B. Plan de Desarrollo del Proyecto Helpdesk
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
Apéndice B. Plan de Desarrollo del Proyecto Helpdesk
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
Apéndice B. Plan de Desarrollo del Proyecto Helpdesk
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.
Categoría: Evidente.
Prioridad: Alta.
R1.3. Permitir la consulta de Incidentes.
R1.3.1. Asociados a un analista.
Descripción: Se deben listar los incidentes que hayan sido asignados a un analista
determinado.
Categoría: Evidente.
Prioridad: Media.
R1.3.2. Asociados a un cliente.
Descripción: Se deben listar los incidentes que pertenezcan a un cliente determinado.
Categoría: Evidente.
Prioridad: Media.
Apéndice C. Especificación de Requerimientos Funcionales y No Funcionales
83
R1.3.3. Por categoría.
Descripción: Se deben listar todos los incidentes correspondientes a una categoría
determinada.
Categoría: Evidente.
Prioridad: Alta.
R1.3.4. Por estado.
Descripción: Se deben listar todos los incidentes según el estado en el que se encuentran.
Categoría: Evidente.
Prioridad: Alta.
R1.3.5. Por fecha.
Descripción: Se deben listar todos los incidentes según el mes de registro.
Categoría: Evidente.
Prioridad: Alta.
R1.3.6. Todos los incidentes.
Descripción: Se deben listar todos los incidentes registrados.
Categoría: Evidente.
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.
Apéndice C. Especificación de Requerimientos Funcionales y No Funcionales
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.
Categoría: Evidente.
Prioridad: Alta.
Apéndice C. Especificación de Requerimientos Funcionales y No Funcionales
85
R2.3. Permitir la consulta de Problemas.
R2.3.1. Asociados a un analista.
Descripción: Se deben listar los problemas que hayan sido asignados a un analista
determinado.
Categoría: Evidente.
Prioridad: Media.
R2.3.2. Por categoría.
Descripción: Se deben listar todos los problemas correspondientes a una categoría
determinada.
Categoría: Evidente.
Prioridad: Alta.
R2.3.3. Por estado.
Descripción: Se deben listar todos los problemas según el estado en el que se encuentran.
Categoría: Evidente.
Prioridad: Alta.
R2.3.4. Por fecha.
Descripción: Se deben listar todos los problemas según el mes de creación.
Categoría: Evidente.
Prioridad: Alta.
R2.3.5. Todos los problemas.
Descripción: Se debe permitir la visualización de todos los registros de problemas..
Categoría: Evidente.
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.
Apéndice C. Especificación de Requerimientos Funcionales y No Funcionales
86
R2.5. Llevar el registro del número de incidentes asociados.
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.
Categoría: Evidente.
Prioridad: Alta.
R3.2. Permitir la modificación de Errores Conocidos
Descripción: Los registros de existentes de errores conocidos se deben poder modificar.
Categoría: Evidente.
Prioridad: Baja.
R3.3. Permitir la consulta de Errores Conocidos
Descripción: Se deben listar todos los registros de errores conocidos.
Categoría: Evidente.
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.
R3.5. Llevar el registro del número de incidentes asociados.
Descripción: Se debe mantener un registro del número de incidentes asociados a un error
conocido determinado
Categoría: Oculto.
Prioridad: Media.
Apéndice C. Especificación de Requerimientos Funcionales y No Funcionales
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.
Categoría: Evidente.
Prioridad: Baja
R4.2. Generar reportes estadísticos de Problemas.
Descripción: El sistema debe generar reportes estadísticos de los incidentes registrados.
Categoría: Evidente.
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.
Categoría: Evidente.
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.
Categoría: Evidente.
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.
Categoría: Evidente.
Prioridad: Alta.
Apéndice C. Especificación de Requerimientos Funcionales y No Funcionales
88
R6.2. Permitir la modificación de usuarios registrados.
Descripción: Los datos de los usuarios registrados deben poder modificarse.
Categoría: Evidente.
Prioridad: Media.
R6.3. Permitir la eliminación de usuarios registrados.
Descripción: Los usuarios registrados deben poder eliminarse.
Categoría: Evidente.
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.
Categoría: Evidente.
Prioridad: Alta.
R6.6. Cerrar sesión de un usuario.
Descripción: Permitir que el usuario finalice su sesión en el sistema.
Categoría: Evidente.
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.
Categoría: Evidente.
Prioridad: Baja.
Apéndice C. Especificación de Requerimientos Funcionales y No Funcionales
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.
Categoría: Evidente.
Prioridad: Alta.
R9.2. Permitir la modificación de solicitudes
Descripción: El sistema debe permitir la modificación de las solicitudes registradas.
Categoría: Evidente.
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.
Categoría: Evidente.
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.
Categoría: Evidente.
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.
Apéndice C. Especificación de Requerimientos Funcionales y No Funcionales
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.
Categoría: Obligatorio.
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.
Categoría: Obligatorio.
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.
Categoría: Obligatorio.
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.
Categoría: Obligatorio.
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.
Categoría: Obligatorio.
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.
Categoría: Opcional.
Apéndice C. Especificación de Requerimientos Funcionales y No Funcionales
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.
Categoría: Obligatorio.
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.
Categoría: Obligatorio.
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
Categoría: Obligatorio.
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.
Categoría: Obligatorio.
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.
Categoría: Opcional.
7. Requerimientos de desarrollo
7.1. Plataforma
Descripción: El sistema debe ser desarrollado en plataforma Web.
Categoría: Obligatorio.
Apéndice C. Especificación de Requerimientos Funcionales y No Funcionales
92
7.2. Intranet
Descripción: El sistema debe estar integrado a los estándares de la intranet de la institución.
Categoría: Obligatorio.
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.
Categoría: Obligatorio.
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.
Apéndice D. Plan de Riesgos
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
Estrategia de Mitigación
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.
Apéndice D. Plan de Riesgos
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
Apéndice D. Plan de Riesgos
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.
Apéndice D. Plan de Riesgos
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.
Estrategia de Mitigación
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
Apéndice D. Plan de Riesgos
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
Apéndice D. Plan de Riesgos
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.
Estrategia de Mitigación
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.
Apéndice E. Glosario de Términos
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.
Apéndice E. Glosario de Términos
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.
Apéndice F. Especificación de Casos de Uso
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
Actores Principales: Usuario (Cliente, Soporte)
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
Curso normal de eventos:
Acción del Actor Respuesta del Sistema
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
Puntos de extensión:
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
Apéndice F. Especificación de Casos de Uso
105
Curso normal de eventos:
Acción del Actor Respuesta del Sistema
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.
Puntos de extensión:
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.
Apéndice F. Especificación de Casos de Uso
106
Referencias cruzadas: R1.1, R8.
Curso normal de eventos:
Acción del Actor Respuesta del Sistema
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.
Apéndice F. Especificación de Casos de Uso
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 8: Los datos introducidos son incorrectos o incompletos.
8.1 El sistema informa al usuario los errores cometidos.
• 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.
Puntos de extensión:
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.
Precondición: Ninguna.
Poscondición: Se almacenan los cambios realizados al Incidente.
Referencias cruzadas: R1.2
Curso normal de eventos:
Acción del Actor Respuesta del Sistema
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.
Apéndice F. Especificación de Casos de Uso
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.
Puntos de extensión:
Asignar incidente, Buscar solución.
2.3. Consultar Incidente.
Actores Principales: Usuario (Cliente, Soporte)
Descripción: El usuario consulta los datos de los Incidentes registrados.
Precondición: Ninguna.
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
Curso normal de eventos:
Acción del Actor Respuesta del Sistema
1. El caso de uso comienza cuando el usuario selecciona la opción de Consultas/Incidente.
Apéndice F. Especificación de Casos de Uso
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.
Puntos de extensión:
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.
Apéndice F. Especificación de Casos de Uso
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.
Curso normal de eventos:
Acción del Actor Respuesta del Sistema
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.
Puntos de extensión:
Ninguno.
3. Manejar Problemas
3.1. Modificar Problema
Actor Principal: Usuario (Soporte)
Descripción: El usuario modifica los datos de los problemas registrados.
Precondición: Ninguna.
Poscondición: Se almacenan los cambios realizados al Problema.
Referencias cruzadas: R2, R2.2, R2.4
Apéndice F. Especificación de Casos de Uso
111
Curso normal de eventos:
Acción del Actor Respuesta del Sistema
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.
3. El usuario realiza los cambios en los campos que desea modificar y presiona guardar.
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.
Puntos de extensión:
Asignar Problema. Registrar solución.
3.2. Consultar Problema
Actor Principal: Usuario (Soporte)
Descripción: El usuario consulta los datos de los Problemas registrados.
Precondición: Ninguna.
Poscondición: Ninguna.
Referencias cruzadas: R2, R2.3, R2.3.1, R2.3.2, R2.3.3, R2.3.4, R2.3.5.
Apéndice F. Especificación de Casos de Uso
112
Curso normal de eventos:
Acción del Actor Respuesta del Sistema
1. El caso de uso comienza cuando el usuario selecciona la opción de Consultas/Problemas.
2. El sistema muestra las siguientes opciones de consulta:
• 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.
3. El usuario selecciona las opciones de búsqueda y oprime Buscar.
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.
• 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 Problema.
• Paso 6: El usuario hace click en la opción imprimir.
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.
Puntos de extensión:
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.
Apéndice F. Especificación de Casos de Uso
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.
Curso normal de eventos:
Acción del Actor Respuesta del Sistema
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.
6. El sistema regresa a la página donde se inició el caso de uso.
Cursos alternos:
Ninguno.
Puntos de extensión:
Ninguno.
4. Manejar Errores Conocidos
4.1. Modificar Error Conocido
Actor Principal: Usuario (Soporte)
Descripción: El usuario modifica los datos de los errores conocidos registrados.
Precondición: Ninguna.
Poscondición: Se almacenan los cambios realizados al Error conocido.
Referencias cruzadas: R3, R3.2, R3.4
Apéndice F. Especificación de Casos de Uso
114
Curso normal de eventos:
Acción del Actor Respuesta del Sistema
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.
3. El usuario realiza los cambios en los campos que desea modificar y presiona guardar.
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.
Puntos de extensión:
Registrar solución.
4.2. Consultar Error Conocido
Actor Principal: Usuario (Soporte)
Descripción: El usuario consulta los datos de los Errores Conocidos registrados.
Precondición: Ninguna.
Poscondición: Ninguna.
Referencias cruzadas: R3, R3.3
Curso normal de eventos:
Acción del Actor Respuesta del Sistema
1. El caso de uso comienza cuando el usuario selecciona la opción de Consultas/Error Conocido.
Apéndice F. Especificación de Casos de Uso
115
2. El sistema muestra las siguientes opciones de consulta:
• 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.
3. El usuario selecciona las opciones de búsqueda y oprime Buscar.
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.
• 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 Error Conocido.
• Paso 6: El usuario hace click en la opción imprimir.
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.
Puntos de extensión:
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.
Referencias cruzadas: R5, R5.1
Apéndice F. Especificación de Casos de Uso
116
Curso normal de eventos:
Acción del Actor Respuesta del Sistema
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.
4. El usuario ingresa los datos solicitados y presiona guardar.
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.
Puntos de extensión:
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.
Poscondición: Ninguna.
Referencias cruzadas: R5, R5.2
Apéndice F. Especificación de Casos de Uso
117
Curso normal de eventos:
Acción del Actor Respuesta del Sistema
1. El caso de uso comienza cuando el usuario selecciona la opción de Consultas/Evaluación
2. El sistema muestra las siguientes opciones de consulta:
• Por fecha de registro. Y el sistema muestra una lista de todos los incidentes evaluados en el mes en curso.
3. El usuario selecciona las opciones de búsqueda y oprime Buscar.
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.
• Paso 6: El usuario hace click en la opción imprimir.
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.
Puntos de extensión:
Ninguno.
6. Manejar Solicitudes.
6.1. Registrar Solicitud.
Actor Principal: Usuario (Soporte)
Descripción: El usuario introduce los datos solicitados para realizar el registro de los procedimientos que
son considerados como solicitudes.
Apéndice F. Especificación de Casos de Uso
118
Precondición: Ninguna.
Poscondición: Se crea un nuevo tipo de solicitud.
Referencias cruzadas: R9, R9.1.
Curso normal de eventos:
Acción del Actor Respuesta del Sistema
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.
Apéndice F. Especificación de Casos de Uso
119
Puntos de extensión:
Modificar solicitud, Consultar solicitud.
6.2. Modificar Solicitud
Actor Principal: Usuario (Soporte)
Descripción: El usuario modifica los datos de las solicitudes registradas.
Precondición: Ninguna.
Poscondición: Se almacenan los cambios realizados a la Solicitud.
Referencias cruzadas: R9, R9.2
Curso normal de eventos:
Acción del Actor Respuesta del Sistema
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.
3. El usuario realiza los cambios en los campos que desea modificar y presiona guardar.
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.
Puntos de extensión:
Consultar solicitud.
6.3. Consultar Solicitud.
Actor Principal: Usuario (Soporte)
Descripción: El usuario consulta los datos de las Solicitudes registradas.
Precondición: Ninguna.
Poscondición: Ninguna.
Referencias cruzadas: R9.
Apéndice F. Especificación de Casos de Uso
120
Curso normal de eventos:
Acción del Actor Respuesta del Sistema
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.
• Paso 2: El usuario hace click en la opción imprimir.
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.
Puntos de extensión:
Ninguno.
7. Manejar Soluciones.
7.1. Registrar Solución.
7.1.1. Para un Problema
Actor Principal: Usuario (Soporte)
Descripción: El usuario introduce los datos necesarios para registrar una solución para un Problema.
Precondición: Ninguna.
Poscondición: Se crea la solución al problema.
Referencias cruzadas: R11.
Curso normal de eventos:
Acción del Actor Respuesta del Sistema
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.
Apéndice F. Especificación de Casos de Uso
121
3. El usuario ingresa los datos solicitados y presiona guardar.
4. El sistema continúa con el caso de uso modificar problema que es donde se inicia este caso de uso.
Cursos alternos:
Ninguno.
Puntos de extensión:
Ninguno
7.1.2. Para un Error Conocido
Actor Principal: Usuario (Soporte)
Descripción: El usuario introduce los datos necesarios para registrar una solución para un Error Conocido.
Precondición: Ninguna.
Poscondición: Se crea una nueva solución para un Error Conocido.
Referencias cruzadas: R11.
Curso normal de eventos:
Acción del Actor Respuesta del Sistema
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.
Puntos de extensión:
Ninguno
Apéndice F. Especificación de Casos de Uso
122
7.2. Consultar Solución.
Actor Principal: Usuario (Soporte)
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.
Poscondición: Ninguna.
Referencias cruzadas: R2.3, R3.3
Curso normal de eventos:
Acción del Actor Respuesta del Sistema
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.
Puntos de extensión:
Ninguno.
7.3. Buscar Solución.
Actor Principal: Usuario (Soporte)
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.
Curso normal de eventos:
Acción del Actor Respuesta del Sistema
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.
Apéndice F. Especificación de Casos de Uso
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.
5. El sistema regresa a la página donde se inició el caso de uso.
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.
Puntos de extensión:
Buscar en Problemas
7.3.1. Buscar en Problemas
Actor Principal: Usuario (Soporte)
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
Curso normal de eventos:
Acción del Actor Respuesta del Sistema
1. El caso de uso comienza cuando en el caso de uso buscar solución el usuario oprime Buscar en Problemas.
Apéndice F. Especificación de Casos de Uso
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.
5. El sistema regresa a la página donde se inició el caso de uso.
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.
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 asociar el incidente a ninguno de los problemas sugeridos.
3.1 El usuario hace click en crear problema.
3.2 El sistema genera un nuevo registro de problema con las mismas características del incidente.
Puntos de extensión:
Ninguno.
8. Control de Solicitudes.
8.1. Registrar Actividades Realizadas.
Actor Principal: Usuario (Soporte)
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ó.
Referencias cruzadas: R10.
Curso normal de eventos:
Acción del Actor Respuesta del Sistema
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.
Apéndice F. Especificación de Casos de Uso
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.
5. El sistema regresa a la página donde se inició el caso de uso.
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.
Puntos de extensión:
Ninguno
8.2. Consultar Actividades Realizadas.
Actor Principal: Usuario (Soporte)
Descripción: El usuario consulta el estado de los incidentes de tipo solicitud.
Precondición: Ninguna.
Poscondición: Ninguna
Referencias cruzadas: R10.
Curso normal de eventos:
Acción del Actor Respuesta del Sistema
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.
Apéndice F. Especificación de Casos de Uso
126
Cursos alternos:
Ninguno.
Puntos de extensión:
Ninguno
9. Manejar Reportes
9.1. Generar Reporte.
Actor Principal: Usuario (Soporte)
Descripción: El usuario puede generar reportes estadísticos de incidentes, errores y problemas.
Precondición: Ninguna.
Poscondición: Ninguna.
Referencias cruzadas: R4, R4.1, R4.2
Curso normal de eventos:
Acción del Actor Respuesta del Sistema
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.
Puntos de extensión:
Imprimir reporte.
9.2. Imprimir Reporte.
Actor Principal: Usuario (Soporte)
Descripción: El usuario puede imprimir el reporte generado.
Precondición: Se debe haber generado el reporte.
Poscondición: Ninguna.
Apéndice F. Especificación de Casos de Uso
127
Referencias cruzadas: R4, R4.3
Curso normal de eventos:
Acción del Actor Respuesta del Sistema
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.
Puntos de extensión:
Ninguno.
10. Manejar Usuarios
10.1. Crear Usuario.
Actor Principal: Usuario (Soporte)
Descripción: El usuario introduce los datos para registrar un nuevo usuario al sistema.
Precondición: Ninguna.
Poscondición: Se registra un nuevo usuario en el sistema.
Referencias cruzadas: R6, R6.1, R7
Curso normal de eventos:
Acción del Actor Respuesta del Sistema
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
Apéndice F. Especificación de Casos de Uso
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.
5. El usuario selecciona el nombre de usuario deseado.
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.
• Paso 9: Los datos introducidos son incorrectos o incompletos.
9.1 El sistema informa al usuario los errores cometidos.
Puntos de extensión:
Ninguno.
10.2. Modificar Usuario.
Actor Principal: Usuario (Soporte)
Descripción: El usuario modifica los datos de los usuarios del sistema.
Precondición: Ninguna.
Poscondición: Se almacenan los datos modificados.
Referencias cruzadas: R6, R6.2
Apéndice F. Especificación de Casos de Uso
129
Curso normal de eventos:
Acción del Actor Respuesta del Sistema
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
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.
5. El usuario selecciona el nombre de usuario deseado.
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.
Puntos de extensión:
Eliminar usuario.
10.3. Eliminar Usuario.
Actor Principal: Usuario (Soporte)
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.
Referencias cruzadas: R6, R6.3
Apéndice F. Especificación de Casos de Uso
130
Curso normal de eventos:
Acción del Actor Respuesta del Sistema
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
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.
5. El usuario selecciona el nombre de usuario deseado.
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
Puntos de extensión:
Ninguno.
11. Manejar Categorías.
11.1. Crear Categoría.
Actor Principal: Usuario (Soporte)
Descripción: El usuario crea una nueva categoría para la clasificación de incidentes, problemas y errores
conocidos.
Precondición: Ninguna.
Poscondición: Se crea una nueva categoría.
Referencias cruzadas: Ninguna.
Apéndice F. Especificación de Casos de Uso
131
Curso normal de eventos:
Acción del Actor Respuesta del Sistema
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.
Puntos de extensión:
Ninguno.
11.2. Modificar Categoría.
Actor Principal: Usuario (Soporte)
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.
Curso normal de eventos:
Acción del Actor Respuesta del Sistema
1. El caso de uso comienza cuando el usuario selecciona en el menú principal la opción Administrativo/Categorías.
Apéndice F. Especificación de Casos de Uso
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.
Puntos de extensión:
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.
Apéndice H. Diccionario de Datos
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)
Apéndice H. Diccionario de Datos
135
Apéndice H. Diccionario de Datos
136
Apéndice H. Diccionario de Datos
137
Apéndice H. Diccionario de Datos
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
Apéndice H. Diccionario de Datos
139
Apéndice H. Diccionario de Datos
140
Apéndice H. Diccionario de Datos
141
Apéndice H. Diccionario de Datos
142
Apéndice H. Diccionario de Datos
143
Apéndice H. Diccionario de Datos
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.
Atributo No nulo Tipo Descripción
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.
Apéndice H. Diccionario de Datos
145
Causa_Incidente Almacena las causas que pueden originar un incidente.
Atributo No nulo Tipo Descripción
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.
Atributo No nulo Tipo Descripción
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.
Atributo No nulo Tipo Descripción
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.
Apéndice H. Diccionario de Datos
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.
Atributo No nulo Tipo Descripción
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
Atributo No nulo Tipo Descripción
Sol_codigo � Number(5) Clave primaria. Identifica cada solución.
Apéndice H. Diccionario de Datos
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.
Atributo No nulo Tipo Descripció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.
Atributo No nulo Tipo Descripción
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.
Atributo No nulo Tipo Descripción
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.
Apéndice H. Diccionario de Datos
148
Inf_Solicitud
Almacena la información sobre los datos adicionales que son necesarios para una solicitud.
Atributo No nulo Tipo Descripción
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.
Atributo No nulo Tipo Descripción
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.
Atributo No nulo Tipo Descripción
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 incidentes.
• Registro y consulta de evaluaciones.
Apéndice J. Manual de Usuario
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:
• Registro y consulta de incidentes.
• 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:
Apéndice J. Manual de Usuario
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.
Apéndice J. Manual de Usuario
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.
Apéndice J. Manual de Usuario
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 (*)
Apéndice J. Manual de Usuario
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.
Apéndice J. Manual de Usuario
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.
Apéndice J. Manual de Usuario
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"
Apéndice J. Manual de Usuario
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)
Apéndice J. Manual de Usuario
159
Figura 9. Consulta de Incidentes.
Figura 10. Detalle de Evaluación
Aquí tendrá la opción de imprimir el resumen (1) o volver a la página anterior (2)
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)
Apéndice J. Manual de Usuario
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 (*)
Apéndice J. Manual de Usuario
161
Figura 12. Registro de Incidentes
Apéndice J. Manual de Usuario
162
Figura 13. Datos de Usuario
Figura 14. Selección de Usuario.
Figura 15. Carga de Datos
Apéndice J. Manual de Usuario
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.
Apéndice J. Manual de Usuario
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.
Apéndice J. Manual de Usuario
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.
Apéndice J. Manual de Usuario
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.
Apéndice J. Manual de Usuario
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:
Apéndice J. Manual de Usuario
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.
Apéndice J. Manual de Usuario
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.
Apéndice J. Manual de Usuario
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
Apéndice J. Manual de Usuario
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.
Apéndice J. Manual de Usuario
172
Figura 31. Detalle Incidente.
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 32, la
cual permite consultar las evaluaciones registradas.
(1) (2)
Apéndice J. Manual de Usuario
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)
Apéndice J. Manual de Usuario
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.
Apéndice J. Manual de Usuario
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)
Apéndice J. Manual de Usuario
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.
Apéndice J. Manual de Usuario
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).
Apéndice J. Manual de Usuario
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:
Apéndice J. Manual de Usuario
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)
Apéndice J. Manual de Usuario
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
Apéndice J. Manual de Usuario
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.
Apéndice J. Manual de Usuario
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)
Apéndice J. Manual de Usuario
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)
Apéndice J. Manual de Usuario
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)
Apéndice J. Manual de Usuario
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)
Apéndice J. Manual de Usuario
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".
Apéndice J. Manual de Usuario
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)
Apéndice J. Manual de Usuario
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".
Apéndice J. Manual de Usuario
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"