A mi familia, a las personas que han confiando en mí, y a ... TI de manera eficaz y con un coste...

SERVICE DESK BASADO EN ITIL PARA LA PYME

I

A mi familia,

a las personas que han confiando en mí,

y a ti, por tu apoyo. Gracias por echarme ese cabl e.


II

Mi más sincero agradecimiento a todas las personas que han hecho

posible que este proyecto final de carrera que hoy tienes en tus manos,

sea una realidad.

Gracias a mi directora de proyecto por confiar en m í, al coordinador de

proyectos por su trabajo y, a todas aquellas person as que se han

cruzado en mi vida universitaria, amigos, compañero s y profesores,

por aportar vuestro granito de arena.


III

Resumen

El objetivo de este proyecto es desarrollar una herramienta de Service Desk

basado en el estándar ITIL adaptado a las necesidades de la PYME.

CHM Service Desk proporcionará un único punto de contacto entre los

usuarios y clientes, con las tecnologías de la información, incluye todo lo

necesario para iniciar la gestión de los servicios de tecnología de la

información (TI), lo cual redunda en una mayor productividad y un mejor

servicio para los usuarios finales.

CHM Service Desk es una solución que ofrece en un paquete integrado, la

gestión de incidencias, de las soluciones y el conocimiento, de los clientes,

del inventario, las compras y la gestión de los Acuerdos de Nivel de Servicio

(ANS).

Todo ello gracias a su entorno gráfico, agradable e intuitivo, que facilita su

uso y, el acceso a las diferentes funciones a través del menú principal y, los

botones situados en la barra de herramientas.

Estas secciones son las siguientes:

� Inicio (Vista global), permite conocer el estado actual. Las incidencias:

abiertas, cerradas y en curso.

� Incidencias, permite abrir y gestionar las incidencias introducidas en el

sistema.

� Clientes, recoge toda la información referente al cliente que comunica

la incidencia, así como su número de Acuerdo de Nivel de Servicio

firmado.


IV

� Soluciones, es una base de datos de consulta de soluciones básicas y

soluciones de incidencias resueltas clasificadas por categorías.

Permitiendo así compartir el conocimiento, ahorrando tiempo a otros

técnicos.

� Inventario. Es necesario conocer el parque informático, las estaciones

de trabajo y los activos hardware y software para la resolución de una

incidencia. Además de la propia gestión del inventario.

� Compras, facilita la creación y gestión de las ordenes de compras, las

cuales deben ser aprobadas o rechazadas por los responsables, para

su posterior incorporación al inventario del cliente.

� Acuerdos de Nivel de Servicios (ANS). De cada uno de los clientes se

necesita tener previamente firmados los contratos denominados

Acuerdos de Nivel de Servicio o ANS, que establecen las condiciones

del nivel de soporte. Este módulo permite conocer las partes que

intervienen, las fechas de inicio y finalización y, acceder al documento

si esta digitalizado, por ejemplo en formato .pdf, .doc o .txt.

� Informes, es necesario conocer el estado actual del sistema y realizar

un posterior análisis, para la toma de decisiones. Por ello este módulo

le permite generar informes en pantalla y/o impresos.

La programación de esta aplicación ha sido realizada con Microsoft Visual

Basic 6, un lenguaje de programación visual y orientado a eventos.

El sistema gestor de la base de datos relacional es Microsoft Access.


V

Abstract The aim of this project is to develop a Service Desk tool based on the

standard ITIL to the necessities of the small and medium size business.

CHM Service Desk will provide an only meeting point between the users and

the clients, with the information technologies (IT). Including everything what

it’s needed to manage the internal processes, which results in greater

productivity and better service for end users.

CHM Service Desk is a solution that offers in an integrated package, the

management of incidences, the solutions and the knowledge, the clients, the

management of the inventory, the purchases and the management of the

Level Services Agreement (LSA).

All of it thanks to its graphical and pleasant graphical user interface (GUI),

that facilitate its use and the access to the different functions through main

menu, and the buttons located in the tool bar.

The programming of this application has been made with Microsoft Visual

Basic 6, a visual and oriented language to events.

The managing system of the relational database is Microsoft Access.


VI

Capítulo 1: Introducción al proyecto .....................1

1.1 Introducción .................................................................................................................... 1 1.2 Objetivos......................................................................................................................... 6 1.3 Ámbito y alcance ............................................................................................................ 7 1.4 Metodología .................................................................................................................. 10

Capítulo 2: Gestión de Servicios TI ..................... 11

2.1 Modelos de gestión de TI ............................................................................................. 13 2.2 Los Clientes .................................................................................................................. 17 2.3 Implementar la Gestión de Servicio.............................................................................. 19 2.4 Calidad.......................................................................................................................... 21 2.5 Los Procesos ................................................................................................................ 25 2.6 Las Tareas.................................................................................................................... 28

Capítulo 3: Introducción a ITIL .......................... 30

3.1 Ventajas y Desventajas ................................................................................................ 32 3.2 Organizaciones............................................................................................................. 34 3.3 Los Libros ..................................................................................................................... 36 3.4 Los Procesos ITIL......................................................................................................... 39 3.4.1 Soporte del Servicio ............................................................................................ 39 3.4.2 Provisión del Servicio .......................................................................................... 40 3.4.3 La perspectiva de negocio................................................................................... 42 3.4.4 Gestión de la infraestructura TI ........................................................................... 42 3.4.5 Planificación de la implementación de la gestión de servicios............................ 43 3.4.6 Gestión de Aplicaciones ...................................................................................... 43 3.4.7 Gestión de la Seguridad ...................................................................................... 44 3.5 La función Service Desk............................................................................................... 45

Capítulo 4: Desarrollo de “CHM Service Desk” ...... 51

Capítulo 5: Identificación de necesidades ............ 53

5.1 Objetivos del sistema ................................................................................................... 54 5.2 Alcance del sistema...................................................................................................... 55 5.3 Tipología de usuarios finales........................................................................................ 58 5.4 Restricciones ................................................................................................................ 59 5.5 Organización empresarial............................................................................................. 59 5.6 Antecedentes................................................................................................................ 60

Capítulo 6: Análisis de requisitos ....................... 62

6.1 Ámbito del proyecto...................................................................................................... 62 6.2 Contexto general del sistema....................................................................................... 64 6.3 Unidades organizativas afectadas................................................................................ 65 6.4 Funciones primarias afectadas..................................................................................... 66 6.5 Modelo del Sistema Actual ........................................................................................... 67 6.6 Lista de requisitos......................................................................................................... 68 6.8 Modelo Lógico del Nuevo Sistema............................................................................... 87 6.8 Modelo Conceptual de Datos ....................................................................................... 91


VII

Capítulo 7: Diseño arquitectura técnica ............... 94

7.1 Diagrama de presentación ........................................................................................... 95 7.2 Especificación de los componentes básicos ................................................................ 97 7.2.1 Hardware necesario de nueva adquisición ......................................................... 99 7.2.2 Software necesario de nueva adquisición......................................................... 100 7.3 Arquitectura Cliente/Servidor...................................................................................... 101 7.4 Evaluación de las alternativas .................................................................................... 103 7.4.1 Parámetros a valorar ......................................................................................... 103 7.4.2 Matrices de evaluación...................................................................................... 106 7.4.3 Valoración de las alternativas............................................................................ 110 7.4.4 Selección de la alternativa................................................................................. 113 7.5 Planificación del proyecto........................................................................................... 114

Capítulo 8: Diseño externo ............................. 116

8.1 Modelo Físico del Nuevo Sistema.............................................................................. 116 8.1.1 Fronteras de mecanización ............................................................................... 118 8.1.2 Especificación de procesos ............................................................................... 120 8.1.3 Diseño del Interfaz de usuario........................................................................... 124 8.1.4 Estimación de volúmenes de información......................................................... 146 8.1.5 Procesos de control y seguridad ....................................................................... 147 8.2 Modelo Lógico de Datos............................................................................................. 150 8.3 Elaboración de los planes .......................................................................................... 154 8.3.1 Plan de pruebas ................................................................................................ 154 8.3.2 Plan de formación.............................................................................................. 155 8.3.3 Plan de implantación ......................................................................................... 155 8.3.4 Plan de conversión ............................................................................................ 156

Capítulo 9: Diseño interno .............................. 158

9.1 Subsistema batch ....................................................................................................... 160 9.1.1 Cuadernos de carga .......................................................................................... 162 9.2 Subsistema online ...................................................................................................... 164 9.3 Menús y pantallas....................................................................................................... 165

Capítulo 10: Programación ............................. 167

10.1 Manual de usuario .................................................................................................... 169 10.1.1 Introducción ..................................................................................................... 171 10.1.1.1 Objeto de la aplicación ...................................................................... 171 10.1.1.2 Ámbito de la aplicación ..................................................................... 172 10.1.2 Descripción general del sistema ..................................................................... 175 10.1.2.1 Entorno de la aplicación .................................................................... 175 10.1.2.2. Perfiles de usuario............................................................................ 176 10.1.3 Funcionalidades .............................................................................................. 177 10.1.3.1 Instalación de la aplicación ............................................................... 177 10.1.3.2 Ejecución de la aplicación ................................................................. 181 10.1.3.3 Desinstalación de la aplicación ......................................................... 182 10.1.4 Funciones principales...................................................................................... 184

Capítulo 11: Pruebas ..................................... 192

11.1 Entorno de pruebas .................................................................................................. 193 11.2 Tipos de pruebas...................................................................................................... 194


VIII

Capítulo 12: Implantación ............................... 197

12.1 Pruebas de implantación .......................................................................................... 197

Conclusiones .............................................. 199

Bibliografía ................................................. 201

Anexos ...................................................... 203

A.1. Valoración económica ........................ 204

A.2. Glosario .......................................... 208


1

Capítulo 1: Introducción al proyecto

1.1 Introducción

La información es el recurso más importante que cualquier empresa posee y

tiene que dirigir. Es su fuente principal de negocio. Sin embargo, no ha sido

hasta recientes años, mediante la automatización de su gestión, cuando se

han convertido en una herramienta imprescindible y clave para las

empresas. El impacto sobre los procesos del negocio de las tecnologías de

la información (TI) es hoy en día, innegable. De ahí la importancia que tiene

la gestión de Servicios TI.

Mientras que hasta los años 70 la mayor preocupación estaba en la mejora y

desarrollo de nuevo hardware y, hasta bien entrados los 80, este interés era

por el desarrollo del software, la última década del pasado siglo se ha

centrado en la gestión de los servicios.

Sin embargo, la pequeña y mediana empresa (PYME), es mucho más

numerosa que las grandes empresas o corporaciones que siguen un modelo


2

tradicional jerárquico, con grandes dificultades para adaptarse al cambio en

los mercados que ha producido el impacto de las TI sobre ellas.

Se considerarán pequeñas y medianas empresas a toda entidad,

independientemente de su forma jurídica que ejerza una actividad

económica, distinguiéndose entre:

� Pequeña empresa, aquella que tenga una plantilla inferior a 50

trabajadores y, una cifra anual de negocios o balance general no

superior a 10 millones de Euros.

� Mediana empresa, aquella que tenga una plantilla inferior a 250

trabajadores y, una cifra anual de negocios no superior a 50 millones

de euros.

� Y una empresa grande o multinacional, al resto.

La relación entre tecnología y PYME ha sido durante años distante.

Acontecimientos como el “Efecto 2000” y “el euro” no consiguieron atraer el

interés de la mayoría de las PYME españolas.

En todos los sectores de la actividad económica se detectan cambios cada

vez más fuertes, que modifican la forma de trabajar y competir. En este

sentido, lo importante no son las tecnologías en sí, sino su integración en la

empresa.


3

A finales de la década de los 80, nace ITIL, Information Technology

Infrastructure Library, que podría ser traducido como la biblioteca de la

infraestructura de las tecnologías de la información. Desarrollada por el

Reino Unido dentro del departamento llamado OGC (Office of Government

Commerce), antiguamente conocida como CCTTA (Central Computer and

Telecommunications Agency). El objetivo era desarrollar una propuesta para

que los ministerios y oficinas del sector público del Reino Unido utilizaran el

recurso TI de manera eficaz y con un coste eficiente.

ITIL es un conjunto de las mejores prácticas de TI, que pueden adaptarse a

cualquier empresa u organización. Su implementación en la pequeña y

mediana empresa para optimizar la infraestructura de la tecnología de la

información y los servicios, alineándolos con los objetivos de la empresa,

aporta notables beneficios.

Basándose en ITIL se han desarrollado sistemas para la Gestión de

Servicios TI, por grandes corporaciones como HP, Microsoft, IBM y, muchas

otras.

En soporte de servicio se encuentra el Service Desk, que debe ser el único

punto de contacto entre los clientes, usuarios y, el servicio de TI, para todas

las incidencias, problemas, solicitudes de servicios, necesidades, preguntas,

quejas, comentarios y cambios relacionados con las TI.


4

Cuando un servicio se ha interrumpido, el objetivo de algunos procesos es

restaurar el servicio, tal y como lo realizan el soporte de segunda y tercera

línea, asistiendo en la resolución, mientras el Service Desk retiene control

administrativo de la incidencia. Siendo el Service Desk es responsable de un

evento de servicio de principio a fin.

El Service Desk, también proporciona un nexo común para otras actividades

tal como solicitudes de cambio, acuerdos de nivel de servicio, licencias de

software, Gestión de Nivel de Servicio, Gestión de la Configuración, Gestión

de la Disponibilidad, Gestión Financiera de los Servicios de TI y Gestión de

Continuidad del Servicio de TI.

En las organizaciones podemos encontrar Service Desk Local, es práctico

pero cuando se dispone de múltiples sucursales puede duplicar habilidades

y recursos, es en consecuencia más costoso.

Service Desk Central, todas las solicitudes de servicio están registradas en

una localización física central. Si tiene múltiples localizaciones, tener un

servicio de soporte central tiene como costes operacionales reducidos, visión

global de gestión consolidada y el uso mejorado de recursos disponibles.

La falta de una guía básica e introductoria, ha supuesto un impedimento en

la adopción de ITIL como referencia estándar. Este proyecto no pretende ser


5

dicha guía, pero si ofrecer una ayuda para la mejora de la gestión de los

servicio de TI, impulsado por una de las funciones básica, el Service Desk.

El desarrollo de esta herramienta software basada en ITIL, para la pequeña

y mediana empresa, se justifica ante la necesidad de un software de gestión

del soporte de servicio. Pudiendo ser utilizada en un Service Desk local o

central, dando soporte a la propia PYME y/o a terceros.


6

1.2 Objetivos

� Objetivos del proyecto:

� Mejorar la gestión de servicios TI en la PYME.

� Motivar la adopción de ITIL como referencia estándar.

� Desarrollar una aplicación Service Desk.

� Desarrollar una guía/ayuda para el cliente.

� Objetivos de la función de Service Desk:

� Proveer un único punto de contacto con los usuarios y clientes.

� Facilitar la restauración de un servicio con un impacto mínimo

hacia los procesos de negocios y respetando las prioridades del

mismo.

� Mejorar los conocimientos al usuario de los servicios TI.

� Objetivos de la herramienta Service Desk:

� Conocer el estado actual del servicio TI.

� Gestionar las incidencias.

� Gestionar de soluciones mediante procedimientos o incidencias

ya cerradas.

� Conocer el inventario, estaciones de trabajo, hardware y software.

� Realizar pedidos a proveedores.

� Control de los Acuerdos de Nivel de Servicio (ANS).

� Generación de informes.


7

1.3 Ámbito y alcance

El proyecto consiste en satisfacer la necesidad actual de una herramienta

software basada en ITIL, para la pequeña y mediana empresa, para la

gestión del soporte de servicio.

Esta herramienta Service Desk, proporcionará un único punto de contacto

entre los usuarios y clientes, con las tecnologías de la información.

La aplicación dispondrá de un entorno gráfico, agradable e intuitivo, que

facilitara su uso.

La aplicación de Gestión Service Desk facilitará a través de los diferentes

menús y, botones de la barra de herramientas el acceso a las diferentes

secciones:

� Inicio (Vista global), permitirá conocer el estado actual de las

incidencias: abiertas, cerradas y en curso.

� Incidencias, permitirá abrir y gestionar nuevas incidencias.

� Nueva solicitud.

• Estado: Abierto, Cerrado o En curso.

• Modo: Llamada telefónica, e-mail, formulario, etc.


8

• Técnico: (a quien se le asigna la incidencia).

• Cliente: Nombre, ID, teléfono, email, etc.

• Prioridad: Normal, Alta, Baja, Media.

• Categoría: General, Hardware, Internet, Impresoras,

Software.

• Titulo.

• Descripción.

� Solicitudes abiertas.

� Solicitudes cerradas.

� Solicitudes en curso.

� Soluciones (Base de datos de consulta). Tras resolver una solicitud se

pude adjuntar su referencia en la base de datos, por categorías como:

� General.

� Hardware.

� Red.

� Internet.

� Software.


técnicos.


9

� Inventario, permite conocer el parque informático y los activos.

� Estaciones de trabajo: Nombre, modelo, fabricante, número de

serie, configuración de la red local, etc.

� Activos: Hardware y Software. Producto, número de serie,

proveedor, precio, etc.

� Compras. Conocer los proveedores con los que se tienen acuerdos y,

realizar un documento de solicitud de compra.

� Nuevo pedido a proveedor.

� Nuevo Proveedor.

� Contratos (ANS). Es necesario controlar los Acuerdos de Nivel de

Servicios firmados para conocer las partes que intervienen y las fechas

de inicio y finalización.

� Informes, permite generar informes en pantalla y/o impresos, que

permitan conocer el estado actual y, realizar un posterior análisis.


10

1.4 Metodología

Para el desarrollo del ciclo de vida estándar del sistema se empleará la

metodología Yourdon, siguiendo las siguientes etapas: Identificación de

necesidades, Análisis de requisitos, Diseño de la arquitectura técnica,

Diseño externo, Diseño interno, Programación, Pruebas, Implantación y

Mantenimiento.

Se utilizaran diagramas de flujo para modelar los procesos y diagramas

entidad relación para modelar los datos, que tras su normalización se

incluirán en la base de datos relacional de Microsoft Access.

La futura arquitectura de la aplicación será cliente-servidor.

Se emplearan diagramas HIPO, JCL para representar los subsistemas batch

y diagramas STC para los subsistemas on-line.

Se emplearan herramientas CASE como Easy case. Para la realización de

diagramas, Microsoft Visio, Microsoft Powerpoint y, para la planificación,

Microsoft Project.

Programación principal de la herramienta Service Desk se realizará con

Visual Basic 6, un lenguaje de alto nivel orientado a eventos. Se realizarán y

se adjuntarán los debidos planes y pruebas.


11

Capítulo 2: Gestión de Servicios TI

¿Qué es la Gestión de Servicios de las TI?. Estas son algunas definiciones

que pueden darse a este concepto:

“El arte de gestionar el sector de Tecnologías de la Información y

Comunicación (TIC) completo de una organización, su infraestructura y sus

actividades así como un conjunto coherente de procesos dirigidos a la

provisión de servicios a la organización”, según World Class IT Service

Management Guide 2000.

“Conjunto de procesos que cooperan para asegurar la calidad de servicios

conectados y vivos, de acuerdo a los niveles de servicios acordados con el

cliente, sobrepuestos a los dominios de gestión como la gestión de

Sistemas, la gestión de redes y el desarrollo de Sistemas y a otros muchos

dominios de procesos como la gestión de los cambios, la gestión de activos

y la gestión de los problemas”, definición de Gartner Group para ITSM.

“La Gestión de Servicios TI es la planificación, el desarrollo, la entrega y, el

soporte de los servicios TI para la empresa. Une el negocio y la tecnología

(departamento TI), a través de la facilitación de la comunicación y la creación

de una asociación de y para el negocio”.


12

Las empresas y organizaciones son cada día más dependientes de las TI

para satisfacer sus objetivos corporativos y necesidades de negocios.

A menudo, un departamento de TI tan sólo se dedica a la entrega de

productos, no considerará los objetivos de la empresa como los suyos

propios, sino que se consideran a sí mismas tan solo como un proveedor de

productos.

Como en cualquier otra industria, los clientes quieren mucho más, quieren la

entrega de un servicio y, no de productos. Esto es un reto para la

organización de TI porque hasta ahora sólo tenían que entregar productos,

nada más. Además de esto, tienen que entregar un servicio constante y

estable, que tiene que estar disponible 24 horas y 365 días.

Por todo esto, las TI deben ser vistas como una parte integral de la empresa,

estrechamente integradas con los objetivos de la empresa.


13

2.1 Modelos de gestión de TI

Las grandes organizaciones y los principales proveedores se están gastando

mucho dinero en desarrollar sus propios marcos de referencia para la

gestión de Servicios TI. Muchas de estas aproximaciones que están

surgiendo están muy relacionadas con las mejores prácticas definidas por

ITIL. Cada marco de trabajo tiene sus propias ventajas dependiendo de la

situación en la que se aplique.

Normalmente todos estos modelos de Gestión de Servicios toman ITIL como

base para realizar un desarrollo que agrande el modelo, acaparando

procesos que no llegan a estar descritos en ITIL. Por ello es necesaria la

ampliación de las mejores prácticas de ITIL para alcanzar un modelo de

gestión razonable. Esto está reconocido dentro del propio mundo de ITIL,

que ha acogido el PD0005, el Código de Prácticas para la Gestión de

Servicio TI del Instituto de Estándares Británico y, que está completamente

basado en ITIL.


14

Los principales modelos de gestión de TI que han sido desarrollados en los

últimos años son:

• ASL (Application Service Library).

Ofrece un modelo de referencia para la gestión de aplicaciones.

• BDM (IT-enabled Business Development and Management

Methodology).

Un método para la gestión, el desarrollo, el mantenimiento y el uso de

las infraestructuras de la información.

• BiOOlogic.

Un innovador modelo de Gestión de Servicios TI para el desarrollo y

la mejora de las organizaciones de gestión de Sistemas TI, basado en

la orientación a objetos.

• CobiT (Control objectives for information and related Technology).

La implementación de los procesos de gestión TI de ISACA para la

auditoria de sistema de información.

• eTOM (enhanced Telecom Operations Map).

Sirve como anteproyecto para la dirección de procesos y como punto

inicial para el desarrollo e integración de sistemas de soporte a los

negocios y a las operaciones (BSS y OSS).

• IMM (IT Management Model).

Es el modelo para el establecimiento de la gestión de Sistema TI a

todos los niveles de Turnkiek, una empresa holandesa de consultoría.


15

• IPW (Introducing Process-oriented Working Methods).

Es el modelo de procesos de Quint Wellington Redwood y KPN

Telecom, en el que la mayoría de los procesos fundamentales de ITIL

están incluidos.

• ISM (Integrated Service Management).

Como proveer un conjunto de servicios separados, de un mismo

proveedor, como un servicio integrado, manteniendo los principios

generales de la gestión de servicios TI.

• ISPL (Information Services Procurement Library).

Ofrece un Nuevo estándar europeo independiente para la gestión del

abastecimiento TI.

• MSP (Managerial Step-by-Step Plan).

Es la aproximación a la gestión TI tal y como se enseña en la

Universidad de Tecnología de Delft.

• ITPM (IT Process Model ).

Es la aproximación basada en modelos que utiliza IBM en todo el

mundo.

• MIP (Managing the Information Provision).

Explica como los requerimientos de información de los procesos de

negocio pueden ser trasladados a la provisión de servicios TI.

• R2C (Regulation, Control and Continuity).

La metodología de gestión de TI de Roccade.


16

• RPM (Recursive Process Management).

Modelo especialmente útil para las fusiones, grandes

reorganizaciones o como vehículo para un cambio de cultura.

• SIMA (Standard Integrated Management Approach).

La aproximación creada y usada por InterProm para el diseño de la

gestión y seguridad de infraestructuras TI abiertas y multi-vendedor.

• ITIL (IT Infrastructure Library).

Es el modelo reconocido como estándar para la organización de los

procesos de gestión de los sistemas TI a nivel mundial.

• HP IT Service Management Reference Model.

Es la visión de Hewlett Packard de cómo organizar la gestión TI

basado en ITIL.

• MOF (Microsoft Operations Framework).

Es el modelo de referencia para la gestión de operaciones

desarrollado por Microsoft, basado completamente en los

fundamentos de ITIL.


17

2.2 Los Clientes

Lo primero es llevar a cabo una investigación de mercado para averiguar

qué quieren en realidad los clientes y qué comprarán. ¿Qué quieren los

clientes de los servicios TI?

• Especificación.

Los clientes quieren saber, por adelantado, qué se va a recibir. Los

clientes no compran productos, compran servicios (soluciones).

• Conformidad.

Los clientes quieren saber cuándo lo podrán recibir y estar satisfechos

de que cumplirá su requisito de negocio.

• Constancia.

Quieren que sea igual cada vez que acudan a por más.

• Valor por su dinero.

El precio que pagan deber ser justo por el producto o servicio que

reciben.

• Comunicación.

Quieren que se les diga lo que reciben, cuándo, cómo y qué hacer

con ello.

La Gestión de Relaciones con el cliente TI es la encargada de asegurar que

existan buenas y eficaces relaciones con los clientes, a nivel estratégico,

táctico y operativo.


18

El usuario es el empleado que utiliza los servicios TI para sus actividades

diarias, percibe la TI como una herramienta para mejorar y simplificar su

trabajo.

Los directivos, la perciben la función TI como una gran inversión y, están

interesados en maximizar el retorno de su inversión.

El cliente es el propietario del servicio TI, mediante la firma del acuerdo de

Nivel de Servicio (ANS).


19

2.3 Implementar la Gestión de Servicio

La Gestión de Servicio trata de la entrega y el apoyo de los servicios de TI

que cumplen los requisitos de negocio de la organización. Gestión de

Servicio se basa en implementar procesos, preferiblemente con la

orientación de una guía como ITIL que proporciona un conjunto

comprensivo, consistente y coherente de prácticas óptimas para los

procesos de Gestión de Servicio, promocionando un enfoque de calidad a

alcanzar efectividad y eficacia en el uso de los sistemas informáticos.

Los procesos de ITIL tienen la intención de ser implementados para que

apoyen pero no dicten los procesos de negocio de una organización.

Los proveedores de servicio de TI alcanzarán mejorar la calidad de servicio,

pero a la vez estarán intentando reducir costes o, al menos, mantener costes

al nivel actual.

El enfoque de Gestión de Servicio para ITIL es una nueva manera de

pensar, pero no debe implementarse porque ahora mismo esté de moda. Si

no se entiende por qué se está implementando ITIL, no tendrá éxito.


20

La implementación de la metodología de la Gestión de Servicio, aportará a la

empresa beneficios tales como:

• Mejor calidad del servicio.

• Procedimientos de Continuidad de Servicio de TI.

• Visión más clara de la capacidad actual de TI.

• Mejor información de servicios actuales.

• Mayor flexibilidad y adaptabilidad dentro de los servicios

• Los empleados más motivados.

• Mayor satisfacción de cliente por entregar el servicio que se espera.

• Mejoras en seguridad, exactitud, velocidad…

• Reducción de los costes operativos.

• Incremento de los márgenes de beneficio, es mucho más barato

vender a un cliente existente, que rondar a uno nuevo.

• El personal trabajara de forma más efectiva como equipos.

• La calidad de servicio mejorará constantemente.

• El departamento de TI se hará más eficaz en soportar las

necesidades del negocio.

La importancia y el impacto de estos beneficios variarán entre las diferentes

empresas.


21

2.4 Calidad

Una dependencia creciente llevan a necesidades crecientes para servicios

de TI de calidad. La manera en la que una empresa dirige sus procesos para

entregar servicios de calidad está especificada por su departamento de

Gestión de Calidad.

El sistema de gestión de calidad define la estructura de la organización, roles

y responsabilidades, políticas, procedimientos, procesos, estándares y

recursos necesarios para la entrega de servicios de calidad de TI.

Sin embargo, un sistema de gestión de calidad sólo funcionará como debe si

dirección y personal están comprometidos a alcanzar sus objetivos.

“La calidad es el conjunto de características de un producto o servicio que

influyen en la satisfacción de las necesidades explicitas” (ISO-8402).

Para la mejora de calidad, Deming propuso el Ciclo o Círculo de Deming

(Figura 2.1), un modelo simple y eficaz para controlar la calidad. Las cuatro

etapas clave son Planificar, Hacer, Comprobar y Actuar. Después de las

cuatro etapas viene una fase de consolidación, que evita que el Círculo

“ruede cuesta abajo”. La fase de consolidación permite a la organización

darse cuenta de lo que ha ocurrido y asegurar que las mejoras se asienten.


22

Figura 2.1 Círculo de Deming.

De la filosofía de W. Edwards Deming sobre gestión estableciendo calidad,

productividad y posición competitiva formuló catorce puntos de atención para

directores. Algunos de estos puntos referentes a Gestión de Servicio, son:

• Derribar barreras entre departamentos (mejorar comunicaciones y

dirección).

• Los directores deben aprender sus responsabilidades y asumir

liderazgo (mejorar los procesos requiere compromiso desde arriba,

buenos líderes motivan a las personas a mejorarse y por lo tanto la

imagen de la empresa).

• Mejorar constantemente (un enfoque orientado a los procesos es

clave para alcanzar este objetivo).

• Instalar educación y auto mejora (aprender y mejorar habilidades

ha sido el enfoque de Gestión de Servicio durante años).


23

• Formación en el puesto de trabajo (“Training on the Job”).

• Transformación de los trabajos de todas las personas.

Para asegurar la calidad, establece un conjunto de medidas y

procedimientos que utiliza la empresa para tener certeza que los servicios

proporcionados cumplen con las expectativas del cliente y con los acuerdos

establecidos.

La serie ISO 9000, es una sistema de calidad que cumple con los

estándares ISO (Organización Internacional para la Estandarización),

relacionando responsabilidades, procedimientos y recursos para implantar la

gestión de calidad.

Algunas empresas exigen a sus abastecedores estar en posesión del

certificado ISO 9001 o ISO 9002, que prueba que el abastecedor tiene un

sistema de calidad adecuado y que un auditor independiente evalúa su

efectividad periódicamente. El certificado ISO no otorga garantía absoluta

sobre la calidad del servicio que provee su poseedor, sin embargo, indica

que el abastecedor toma en serio el compromiso de calidad.

Las empresas requieren la alineación entre el negocio y TI, siendo la calidad

requerida desde la dirección.


24

Los diferentes aspectos de gestión del compromiso se recogen en los

Modelos de Calidad Total (TQM). En Europa se utiliza el EFQM y en

Norteamérica el MBNQA.


25

2.5 Los Procesos

La Gestión de Servicio se basa en procesos. Un proceso es un conjunto de

actividades lógicas relacionadas para obtener un objetivo (resultado).

Las ventajas de los procesos son:

• En un proceso se describen los objetivos (resultados) y la forma en

los que se alcanzan.

• Para cada proceso, se define la inversión (input) y el rendimiento

(output) que se necesitan para alcanzar el objetivo y cuáles son las

cosas que otros procesos necesitan para alcanzar los suyos

(resultado).

• Se describe una organización entera en distintos procesos, que

pueden ser monitorizados uno a uno. Al monitorizarlos en varias

partes pequeñas de una gran organización, se obtiene mejor

resultado que monitorizar la totalidad.

• Se hace a las personas responsables de su eficiencia, efectividad

y del resultado de su proceso, como resultado de ello no sólo se

monitoriza sino que se controla la organización.


26

• Se puede mejorar la organización porque se puede relacionar el

resultado a un modelo que se tiene (si se monitoriza) y se pueden

discutir las maneras de mejorar las actividades en un proceso para

alcanzar el modelo si no se ha conseguido.

• Se pueden crear mejores roles y responsabilidades, al dividir las

responsabilidades para evitar conflictos de interés.

• Las actividades que tienen que ser ejecutadas en distintas

organizaciones pero que atañen a un resultado, pueden ser

controladas mejor si hay un proceso.

Los procesos son el más alto nivel de definir sus actividades y son la mayor

parte del tiempo un estándar de toda la organización.

Los procedimientos (instrucciones de trabajo) son más detallados y

describen exactamente quién ejecuta ciertas actividades en un proceso. Los

procedimientos pueden variar de departamento en departamento y de

actividad en actividad. Por ejemplo, en el proceso de cambio se exige que

cada cambio será solicitado por un RFC (Solicitud de Cambio), pero la

información que se debe adjuntar con este RFC puede ser distinta para el

departamento A y, para el departamento B. Al igual que la información para

un cambio de categoría 1 puede ser distinta que la información de un cambio

de categoría 2.


27

La mayoría de organizaciones están estructuradas en departamentos. El

personal de TI que ejecuta distintas actividades en un proceso es parte de

ese departamento. Por ejemplo si se quiere resolver una incidencia se

dispondrá de primera línea de soporte, segunda, tercera y especialista.

La figura 2.2 muestra el modelo de proceso basado en la metodología ITIL.

Figura 2.2 Modelo de Proceso ITIL.


28

2.6 Las Tareas

Cada proceso puede descomponerse en una serie de tareas.

Para cada tarea, habrá Inversiones (Inputs) y Rendimientos (Outputs).

Cada tarea será ejecutada por un rol, este puede ser un ser humano o

realizado por software. Si es una persona, entonces habrá una serie de

competencias que un individuo necesita para llevar a cabo ese rol.

La ejecución del rol está regida por un conjunto de normas. Estas irán desde

las más sencillas, hasta las más complejas.

A menudo, un proceso abarcará varios límites de organización, por lo tanto,

es importante que cada proceso tenga un propietario.

El propietario del proceso es responsable de la definición del mismo, que

debe ser tratado como un Componente de una Infraestructura (CI). Los CI

pueden variar mucho en complejidad, tamaño y tipo, desde un sistema

(incluido todo el hardware, software y la documentación) a un módulo suelto

o un componente de hardware menor, sujeto al proceso de control de

Cambio normal.


29

El dueño del proceso es el responsable de asegurar que todas las personas

involucradas en la ejecución del proceso estén informadas de cualquier

Cambio que ocurra.

ITIL, es la mejor orientación para la Gestión de Servicios TI, describe las

relaciones entre las actividades en los procesos, que son relevantes en una

empresa, no dictando el tipo de organización.


30

Capítulo 3: Introducción a ITIL

Las siglas de ITIL se corresponden con “Information Technology

Infrastructure Library”, que puede ser traducido como la biblioteca de la

infraestructura de las tecnologías de la información. Fue desarrollada a

finales de 1980 por el Reino Unido dentro del departamento llamado OGC

(Office of Government Commerce), antiguamente conocido como CCTTA

(Central Computer and Telecommunications Agency), como una propuesta

para que los ministerios y oficinas del sector público del Reino Unido

utilizaran el recurso TI de manera eficaz y con un coste eficiente.

ITIL nació de una colección de las mejores prácticas del sector de TI, que

pueden adaptarse a cualquier empresa u organización, independientemente

de su tamaño o de su sector, como base de consulta, educación y soporte

de herramientas software.

La Gestión de Servicios TI dirige la provisión y el soporte de los servicios TI

adaptados a las necesidades de cada empresa. Por ello, ITIL fue creado

para comunicar las mejores prácticas en la Gestión de Servicios TI de forma

metódica y coherente. Basado en un planteamiento de calidad de servicio y

en el desarrollo eficiente y eficaz de los procesos.

ITIL describe en primer lugar lo que debe incluirse en la Gestión de Servicios

TI, para dotarla de servicios TI de calidad acorde con la demanda.


31

ITIL se ha convertido en el estándar mundial de facto en la Gestión de

Servicios TI. Basándose en ella se han desarrollado sistemas para la

Gestión de Servicios TI, por grandes corporaciones como HP, Microsoft, IBM

y, muchas otras. Su estructura base ha demostrado ser útil para las

organizaciones en todos los sectores a través de su adaptación y adopción

como base para consulta, educación y soporte de herramientas de software.

Las empresas reconocen ser cada vez más dependientes de las

Tecnologías de la Información para alcanzar sus objetivos corporativos.

A través de los años, el énfasis pasó de estar sobre el desarrollo de las

aplicaciones TI a la gestión de servicios TI. Esta dependencia en aumento

ha dado como resultado una necesidad creciente de servicios informáticos

de calidad que se correspondan con los objetivos del negocio y, que

satisfaga los requisitos y las expectativas del cliente.

Las TI sólo contribuyen 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 los procesos de mantenimiento y operaciones.

Hoy, ITIL es conocido y utilizado mundialmente. Pertenece a la OGC, pero

es de libre utilización.


32

3.1 Ventajas y Desventajas

La adopción de ITIL, presentará:

Ventajas para los clientes/usuarios:

� La entrega de Servicios TI de calidad y orientados más al cliente,

mejoran la relaciones entre el departamento TI y el cliente.

� Se describen los servicios y detalles en un lenguaje más simplificado

para el cliente.

� Se mejora la calidad y se reduce el coste del servicio.

� Se mejora la comunicación a través de los puntos de contacto

acordados.

Ventajas para la organización:

� Una estructura más clara, más eficaz y centrada en los objetivos

corporativos.

� La dirección tiene mayor control.

� Los cambios resultas más sencillos.

� Facilita la introducción del sistema de gestión de calidad basado en

ISO 9000.


33

Desventajas:

� Su introducción puede llevar tiempo y esfuerzo.

� Supone un cambio en la cultura de la organización.

� Pueden no verse los progresos, si estos no se controlan.

� Su implementación implica el compromiso del personal a todos los

niveles.

� La falta de inversión en herramientas software de soporte, harán que

los procesos no funcionen.

Las desventajas, se pueden superar. ITIL fue desarrollada por las notables

ventajas que aporta y, las buenas prácticas, a prevenir o solventar tales

problemas o situaciones, en caso de que aparezcan.


34

3.2 Organizaciones

� OGC (Antigua CCTA)

ITIL fue un producto de la CCTA, la Agencia Central de Computación y

Telecomunicaciones del gobierno del Reino Unido.

En abril de 2001, la OGC, Office of Government Comerse, absorbió a la

CCTA, es la propietaria de ITIL. Publican gran cantidad de libros escritos por

profesionales y expertos de Reino Unido y de otros países, de distintas

compañías de diferentes sectores, promoviendo las mejores practicas,

haciendo el mejor uso de las TI y otros instrumentos.

� ITSMF

El Information Technology Service Management Forum, conocido

anteriormente como ITIMF, es el único grupo de usuarios reconocido e

independiente dedicado a la Gestión de Servicios TI. Es propiedad de sus

miembros y son ellos quienes operan. Contribuyen con las mejores prácticas

y estándares a nivel internacional.

La primera filial de itSMF, se fundo en el Reino Unido en 1991, el siguiente

fue el itSMF Holandés en noviembre de 1993. Ahora existen filiares en

Francia, Alemania, Bélgica, Austria, Canadá, Estados Unidos y Australia,

que cooperan internacionalmente con itSMF Internacional. Actualmente no

tienen filial en España.


35

El objetivo es el intercambio de información y experiencias, que permitan a

las empresas y organizaciones mejorar en los servicios de TI. Organizan,

seminarios, conferencias y publican también libros. Ello contribuye al

desarrollo y actualización de ITIL.

� EXIN y ISEB

La función holandesa EXIN, Exameninstituut loor Informatica y, la inglesa

ISEB, Information Systems Examination Borrad, han desarrollado junto con

la OGC, un sistema de certificación profesional de ITIL. Consta de tres

niveles:

� Foundation Certificate en Gestión de Servicios TI.

� Practitioner Certificate en Gestión de Servicios TI.

� Manager Certificate en Gestión de Servicios TI.

Los cerificados están dirigidos a profesionales que deben realizar tareas de

mayor importancia dentro de la organización, conocedoras de ITIL y, sus

elementos principales.


36

3.3 Los Libros

Los libros ITIL describen como los procesos, una vez identificados, pueden

ser optimizados y como su interrelación puede ser mejorada. Explican

también como formalizar los procesos dentro de una organización, definir

objetivos y determinar cuanto costará conseguirlos, ofreciendo una

terminología unificada.

ITIL no es un método, sino que ofrece un marco de trabajo para planificar los

procesos, los roles y las actividades más frecuentes, indicando como se

relacionan entre sí.

Se basa en la necesidad de proporcionar servicios de calidad, haciendo

énfasis en la relación con el cliente. La organización deberá cumplir con los

acuerdos, lo que implica tener una buena relación con los clientes y los

abastecedores.

ITIL se inspira en los sistemas de calidad, como la serie ISO 9000 y, los

marcos de trabajo de calidad total como EFQM. Lo que facilita el camino

para la obtención de la certificación ISO.

En el nacimiento de ITIL a finales de 1980, constaba inicialmente de 10

libros que cubrían las dos principales áreas de Soporte del Servicio y

Provisión del Servicio. Estos libros centrales fueron más tarde soportados


37

por 40 libros complementarios que cubrían una numerosa variedad de

temas, desde el cableado hasta la gestión de la continuidad del negocio.

Con el tiempo ITIL presentaba un planteamiento algo anticuado, así a partir

del año 2000, se llevo a cabo una revisión de la biblioteca. En esta revisión,

ITIL ha sido reestructurado para hacer más simple el acceder a la

información necesaria para administrar sus servicios.

ITL ha sido actualizado, los libros centrales se han agrupado en dos,

cubriendo las áreas de Soporte del Servicio y Provisión del Servicio,

eliminándose repeticiones y mejorando su cohesión.

Actualmente ITIL se encuentra agrupado bajo 7 publicaciones, disponibles

tanto en libro como en CD. Cada una de estas publicaciones describe un

conjunto principal de procesos de Gestión de Servicios TI.


38

Cada uno de los siete elementos principales de de ITIL, se conecta con otros

seis y, en ocasiones se superponen, tal y como muestra la figura 3.1.

Figura 3.1 Puzzle ITIL.

Los siete elementos son:

� Soporte el Servicio (2000).

� Provisión del Servicio (2001).

� Gestión de la Seguridad (1999).

� Gestión de Infraestructuras TI (2002).

� Gestión de Aplicaciones (2002).

� Planificación para Implementar la Gestión de Servicios (2002).

� Perspectiva de Negocio (2004).


39

3.4 Los Procesos ITIL

A continuación se especifican brevemente todos y cada uno de los siete

elementos que forman los procesos ITIL.

3.4.1 Soporte del Servicio

Se centra en asegurar como el cliente puede tener acceso a los servicios

adecuados para soportar las funciones de negocio. Cubre los siguientes

temas:

� Gestión de incidencias.

� Gestión de problemas.

� Gestión de la configuración.

� Gestión de cambios.

� Gestión de versiones.

� Y la función Service Desk.

También cubre las interacciones necesarias entre estas y otra disciplinas

fundamentales de la gestión de servicios y, actualiza las mejores prácticas

para reflejar los cambios recientes en la tecnología y las prácticas de

negocio.


40

3.4.2 Provisión del Servicio

Los proveedores de servicios deben ofrecer a los usuarios un adecuado

soporte, la entrega de servicios cubre todos los aspectos que se deben tener

en cuenta. El propósito de la entrega de servicios es las principales

relaciones entre todos los procesos de gestión de servicios y de

infraestructura, describiendo los servicios que el cliente necesita y como

proporcionar dichos servicios. Cubre los siguientes temas:

� Gestión de niveles de servicio.

� Gestión Financiera de los Servicios TI.

� Gestión de la capacidad.

� Gestión de la continuidad.

� Gestión de la disponibilidad.

� Gestión de relaciones con clientes TI.


41

La figura 3.2 muestra la complejidad de la interrelación entre los procesos de

Soporte y Provisión, estando ambos procesos conectados por la función

Service Desk, que se detalla más adelante.

Figura 3.2 Soporte del servicio y Provisión del servicio.


42

3.4.3 La perspectiva de negocio

Presta atención al conocimiento de la provisión de servicios TI integrados a

la gestión del negocio. Los temas tratados cubren la gestión de la

continuidad de negocio, el outsourcing y asociaciones, supervivencia a los

cambios y la transformación de las prácticas de negocio a través del cambio

radical. Cubre los siguientes temas:

� Gestión de la continuidad de negocio.

� Outsourcing y asociaciones.

� Cambios para la supervivencia.

� Adaptación del negocio a los cambios radicales.

3.4.4 Gestión de la infraestructura TI

La gestión de la infraestructura cubre la gestión del servicio de red, la

gestión de las operaciones, la gestión de los procesadores locales, la

aceptación e instalación de los ordenadores y por primera vez, la gestión de

los sistemas. Cubre los siguientes temas:

� Gestión del servicio de redes.

� Gestión de las operaciones.

� Gestión de centros distribuidos.

� Aceptación e instalación de los ordenadores.

� Gestión de los sistemas.


43

3.4.5 Planificación de la implementación de la gest ión de

servicios

Explica los pasos necesarios para identificar como una organización puede

esperar beneficiarse de ITIL y, como que hacer para recoger estos

beneficios. Cubre el siguiente tema:

� Proceso de mejorar continua.

3.4.6 Gestión de Aplicaciones

Cubre el ciclo de vida del desarrollo de Software, expandiendo los asuntos

tratados en el soporte del ciclo de vida del software y en las pruebas de los

servicios TI. También como responder eficazmente ante los cambios de

negocio, haciendo hincapié en la definición de requisitos y la implementación

de soluciones que satisfagan al cliente. Cubre los siguientes temas:

� Soporte del ciclo de vida del software.

� Prueba de los servicios TI.


44

3.4.7 Gestión de la Seguridad

Esta es una de las nuevas guías introducidas tras la revisión de ITIL y

explica los procesos de gestión de la seguridad con la gestión de servicios

TI. Se centra en el proceso de implementación de los requisitos de seguridad

identificados en los acuerdos de niveles de servicio, más que en la

consideración de las políticas de seguridad para el negocio.


45

3.5 La función Service Desk

La función Service Desk, o Centro de Servicios es para el usuario el único

punto de contacto con la organización TI, donde encontrará a la persona

correcta para ayudarle con su consulta. Esta función, es un departamento y,

no un proceso, que realiza un importante papel en la gestión de servicios TI.

Tal y como se ilustraba en la figura 3.2 Soporte del servicio y Provisión del

servicio, en la que se muestra la complejidad de la interrelación entre los

procesos de Soporte y Provisión, estando ambos procesos conectados por

la función Service Desk.

El Service Desk, incluye al departamento más conocido como Help Desk o

Centro de Soporte, que solo se dedican al proceso de gestión de

incidencias.

Objetivos del Service Desk:

� Proveer un único punto de contacto con los usuarios y clientes.

� Facilitar la restauración de un servicio con un impacto mínimo hacia

los negocios del usuario dentro de un nivel y respetando las

prioridades del negocio.

� Mejorar los conocimientos al usuario de los servicios TI.


46

Actividades del Service Desk:

� Recibir comunicaciones, primer enlace con el cliente.

� Registrar y seguir las solicitudes.

� Administrar el ciclo de vida de una solicitud (abierta, en curso y

cerrada).

� Mantener a los clientes informados.

� Hacer una valoración inicial de la petición, intentando resolverla o

remitirla a otra persona, que pueda atenderla.

� Controlar los Acuerdos de Nivel de Servicio (ANS).

� Planear una comunicación y un cambio de niveles de servicio a corto

plazo hacia los clientes.

� Proveer la gestión de información y recomendaciones para el

mejoramiento del servicio.

� Identificación de los problemas.


47

Procesos ITIL implicados:

� Gestión de Incidencias . Es el proceso principal. El Service Desk

registra y monitoriza las solicitudes del usuario de incidencias.

� Gestión de Problemas . Cuando se desconoce la causa raíz de una

incidencia y, esta se puede repetir.

� Gestión de Versiones y Gestión de Cambios . El Service Desk es

responsable de la instalación del software y hardware y, del parque

informático.

� Gestión de Configuraciones . Para la resolución de incidencias, se

deben conocer los detalles del recurso TI afectado.

� Gestión de los Niveles de Servicio . El Service Desk informará a los

clientes sobre los productos que tienen soporte y, de los servicios a

los cuales tienen derecho.


48

La figura 3.3 muestra la interrelación de los procesos ITIL implicados en

la función service desk.

Figura 3.3 Procesos implicados en el Service Desk.

La estructura del Service Desk se fundamente en su accesibilidad, los

usuarios deben conocer como contactar con el centro de soporte, cuando

tengan alguna duda o necesiten ayuda.

Se puede dar soporte con procedimientos basados en cuestionarios de

preguntas frecuentes (FAQ) y, listas de respuestas (cheklist).


49

Se pueden utilizar diversos canales de comunicación, llamadas telefónicas y

correos electrónicos, son los frecuentes, pudiéndose utilizar también chats,

faxes, etc.

El service desk se divide en líneas de soporte, más avanzas en cada nivel

para la resolución de las incidencias más complejas.

Los modelos estructurales de Service Desk son:

� Service Desk Local. Tradicionalmente, las empresas han creado centros

de soporte locales en cada una de sus ubicaciones. Dando la sensación

de cercanía y proximidad al cliente. En cambio, la gestión del mismo se

hace más compleja.

� Service Desk Centralizado. El Service Desk Local es práctico pero por

sus múltiples localizaciones puede duplicar habilidades y recursos, luego

es costoso. En el Service Desk Central todas las solicitudes de servicio

están registradas en una localización física central.


50

Si una empresa tiene múltiples localizaciones (sucursales), tener un servicio

de soporte central tiene mayores ventajas como:

• Costes operacionales reducidos.

• Visión global de gestión consolidada.

• Uso mejorado de recursos disponibles.

Algunos de los servicios tienen que ser soportados en cada localización. Por

ello, se recomienda la combinación de Desks Centrales y Locales.

� Service Desk Virtual. La situación física del Service Desk y los servicios

asociados son inmateriales, debido a la tecnología de las

telecomunicaciones empleada. El Service Desk puede ser accedido

desde cualquier lugar del mundo.


51

Capítulo 4: Desarrollo de “CHM Service Desk”

Para el desarrollo de la herramienta software “CHM Service Desk”, que

aborda el presente proyecto, se empleará en ciclo de vida de la metodología

Yourdon, denominado lineal o en cascada.

Siguiendo las siguientes etapas: Identificación de necesidades, Análisis de

requisitos, Diseño de la arquitectura técnica, Diseño externo, Diseño interno,

Programación, Pruebas, Implantación y Mantenimiento, tal y como se ilustra

en la figura 4.1.

Figura 4.1 Etapas del ciclo de vida.


52

5. Identificación de necesidades


53

Capítulo 5: Identificación de necesidades

En este capítulo se define el problema a resolver y se fijan las normas para

la dirección del proyecto, exponiendo el contexto global del problema,

elaborado con la colaboración de nuestro cliente, por medio de la técnica de

la entrevista complementada con cuestionarios.

Esta etapa corresponde con la realización del Documento de Conceptos del

Sistema, en el cual se definen:

� Objetivos de tipo empresarial del sistema.

� Alcance del sistema.

� Topología de usuarios finales.

� Restricciones de tiempo, económicas, tecnológicas, legales, etc.

� Organización empresarial del cliente.

� Antecedentes que han motivado la realización de este proyecto.


54

5.1 Objetivos del sistema

1. Establecer un punto de contacto único para los usuarios de TI.

2. Emplear un estándar en la gestión de servicios TI, como ITIL.

3. Conocer el estado actual del servicio TI.

4. Gestionar y monitorizar las incidencias de los usuarios.

5. Conocer las soluciones a problemas frecuentes de las TI.

6. Conocer el parque informático, las estaciones de trabajo, el hardware y

software del que se dispone.

7. Poder realizar pedidos a proveedores de TI.

8. Establecer y gestionar Acuerdos de Nivel de Servicios establecidos.

9. Generaran informes para el análisis.

10. Extrapolar la gestión de servicios TI a terceros (clientes).


55

5.2 Alcance del sistema

El proyecto va ha satisfacer la necesidad actual de una herramienta software

basada en ITIL, para la pequeña y mediana empresa, para la de gestión del

servicio TI.

Esta herramienta Service Desk, proporcionará un único punto de contacto

entre los usuarios y clientes, con las tecnologías de la información.

La aplicación dispondrá de un entorno gráfico, agradable e intuitivo, que

facilitara su uso.

CHM Service Desk facilitará a través de los diferentes menús y, botones de

la barra de herramientas, acceso a las diferentes secciones.

Para el cumplimiento de los anteriores objetivos, el sistema realizará las

siguientes funciones:

� Permitir conocer el estado actual de las incidencias: abiertas,

cerradas y en curso, en una vista global en el inicio.

� Gestionar las incidencias, permitirá abrir y gestionar todas las

incidencias.


56

� De cada incidencia se conocerá su:

� Estado: abierto, en curso o Cerrado.

� La vía por la cual se comunicó: Llamada telefónica, e-mail,

formulario, etc.

� El técnico al cual se le asigna la resolución de la incidencia.

� Los datos del usuario/cliente que la realiza: Nombre,

identificador, teléfono, email, etc.

� La prioridad asignada a la incidencia en base a los Acuerdos

de Nivel de Servicio: alta, normal, media y baja.

� La categoría de la incidencia: General, Hardware, Internet,

Impresoras, Software, etc.

� Y la descripción breve y concisa facilitada por el usuario.

� Disponer de una base de datos de consulta de soluciones, en base a

las incidencias ya resultas. Permitiendo así compartir el conocimiento

y ahorrar tiempo a otros técnicos.

� Conocer el parque informático y los activos de que dispone el usuario.



� Activos: Hardware y Software: Producto, número de serie,



57

� Conocer los proveedores con los que se tienen acuerdos y, facilitar la

realización de un documento de solicitud de compra.

� Controlar los Acuerdos de Nivel de Servicios firmados,

para conocer las fechas de inicio y finalización de los

mismos y, las partes que intervienen.

� Generar informes en pantalla y/o impresos, que permitan

conocer el estado actual y, realizar un posterior análisis.


58

5.3 Tipología de usuarios finales

Los clientes del software de la herramienta Service Desk para los cuales se

desarrolla este proyecto, determinan su uso principal a tres perfiles:

Técnicos de soporte : Encargados principalmente de la gestión y resolución

de incidencias. Divididos en las diferentes líneas de soporte de organización

para la resolución de incidencias según su grado de especialización.

Responsable de TI : Encargado de las TI en la empresa, quien controlará la

correcta gestión de las incidencias, su reasignación, supervisara el estado

actual y analizará la información que la aplicación le proporcione, para la

toma de decisiones. Controlara también los Acuerdos de Nivel de Servicio.

Responsable de compras en TI: esta función se vera facilitada gracias a

que la aplicación permitirá conocer los proveedores con los que se tienen

acuerdos y, facilitar la realización de un documento de solicitud de compra.


59

5.4 Restricciones

Le presente proyecto no tiene restricciones económicas especificadas. Las

restricciones referidas al tiempo para el desarrollo del proyecto están

especificadas y se controlan con la planificación del mismo. No existen otras

restricciones considerables.

5.5 Organización empresarial

La figura 4.1 muestra el organigrama que la empresa cliente del proyecto ha

facilitado, ilustrando las partes que se verán afectadas en la organización:

Figura 4.1 Organigrama.


60

5.6 Antecedentes

La empresa cliente dedica su principal línea de negocio a la formación a

particulares y empresas. Iniciara en breve su nueva línea de negocio de

consultaría en TI, dedicándose áreas como proyectos, seguridad, Web y

soporte técnico. A esta última área va dirigido el proyecto. Inicialmente para

el soporte de la gestión de servicios de TI en la propia empresa y, después a

clientes de la empresa que soliciten sus servicios.


61

6. Análisis de requisitos


62

Capítulo 6: Análisis de requisitos

El objetivo de esta etapa es alcanzar un conocimiento suficiente del sistema,

definiendo las necesidades, problemas y requisitos del usuario, para

expresarlo mediante los modelos de procesos y de datos.

6.1 Ámbito del proyecto

El ámbito del proyecto especifica de manera breve partiendo de los objetivos

señalados en el Documento de Conceptos del Sistema, las funciones

principales de negocio a mecanizar.

1. Para establecer un punto de contacto único para los usuarios de TI, se

establecerán diversos medios de comunicación para alcanzarlo.

Recepción de llamadas telefónicas, faxes, formularios vía email, sesiones

de Chat, etc.

2. Para que el sistema permita conocer el estado actual del servicio TI, se

empleará una interfaz grafica de usuario sencilla.

3. Para la gestión y monitorización de las incidencias, estás se almacenaran

en una base de datos relacional.

4. Para permitir conocer las soluciones a los problemas más frecuentes, se

elabórala un almacén de cocimientos, donde cada problema puede

apuntar a una incidencia solucionada.


63

5. Para conocer el parque informático del cliente, las estaciones de trabajo,

el hardware y software del que se dispone, se registrará toda la

información en la base de datos.

6. Para facilitar la realización de pedidos a proveedores de TI con los que

se tienen acuerdos, los proveedores se registraran en la base de datos y

se facilitará la impresión del documento de pedidos de compras.

7. Para permitir conocer y gestionar los Acuerdos de Nivel de Servicios

establecidos, estos se registrarán en la base de datos, permitiendo

fundamentalmente conocer el periodo de vigencia del contrato y las

condiciones básicas.

8. Para la generación de informes que facilitarán el análisis, el sistema

dispondrá de un amplio conjunto de informes.

9. Para alcanzar que la herramienta CHM Service Desk, permita extrapolar

la gestión de servicios TI a terceros clientes, está permitirá no solo

gestionar el servicio del propietario de la herramienta, si no que además

permitirá gestionar el servicio de sus clientes.


64

6.2 Contexto general del sistema

El contexto general del Sistema se representa mediante un diagrama de

presentación, con símbolos y figuras, donde se muestra la interacción del

sistema con el usuario, con otros sistemas manuales o mecanizados, tal y

como se muestra en la figura 4.2.

Figura 4.2 Contexto.


65

6.3 Unidades organizativas afectadas

La visual 4.3 muestra las áreas organizativas de la empresa afectadas por el

nuevo sistema.

Figura 4.3 Unidades organizativas afectadas.

� Administración . Encargada de la gestión de clientes, facturación y

cobros a los mismos.

� Responsable TI . Gestión y control de los Acuerdos de Nivel de

Servicios establecidos con los clientes. Control de la gestión de

incidencias, supervisión del estado actual, apoyado por los informes

del sistema.

� Técnicos de soporte . Gestión y resolución de incidencias.


66

6.4 Funciones primarias afectadas

Las funciones primarias afectadas por la mecanización, se obtienen tras

asociar las funciones a las unidades de la organización, e identificar así las

personas a entrevistar inicialmente, que puede representarse mediante una

matriz de Funciones-Áreas como la mostrada a continuación.

Áreas

Funciones

Administración Dirección TI

Responsable TI

Técnicos Soporte Compras

Gestión de clientes y usuarios

++ - + + -

Gestión ANS - + ++ + -

Control inventario - - - + -

Gestión de incidencias - - ++ ++ -

Pedidos a proveedores - + ++ - ++

Figura 4.4 Matriz Unidades organizativas afectadas.

++ : Más implicado + : Implicado - : Menos implicado

En la tabla se muestran las áreas y las funciones primarias de este proyecto,

en la cual, determinadas áreas dependiendo de la función influyen de

manera más o menos decisiva indicado con los siguientes símbolos, el

desarrollo del proyecto.


67

6.5 Modelo del Sistema Actual

Como ya se indico en la sección 4.1.6 Antecedentes, perteneciente a la

etapa de Identificación de necesidades, no existe ninguna aplicación o

sistema de características similares a la del sistema a desarrollar. Ya que el

cliente del proyecto como ya se ha comentado, abrirá en su empresa una

nueva línea de negocio dedicada a la consultaría de TI, con un área de

soporte técnico, entre otras. La herramienta Service Desk a desarrollar

permitirá la gestión de su servicio de TI y el de sus clientes.

Por este motivo no se ha analizado, ni desarrollado la documentación del

proyecto referente al Modelo Físico y Lógico del Sistema Actual (MFSA y

MLSA).


68

6.6 Lista de requisitos

La lista de requisitos es una relación de los requisitos expresados por el

cliente del proyecto, para la realización del nuevo sistema: CHM Service

Desk.

Se recoge cada requisito es una ficha específica, siendo estos requisitos

clasificados en: funcionales, operativos, de prestaciones, de seguridad y

fiabilidad.

Todos ellos son coherentes con los objetivos del sistema indicados en el

apartado 4.1.1 Objetivos del sistema, mostrándose en las páginas siguientes

cada uno de los requisitos en detalle.


69

HOJA DE REQUISITOS IDENTIFICACIÓN: PROYECTO: Service Desk Basado en ITIL para la PYME DIRECCIÓN DEL PROYECTO: Lourdes Viana López. JEFE DEL PROYECTO: José Manuel González Martín REQUISITO:

Fecha: 4/12/2006 Versión: 1.0 Estado: Aprobado

Prioridad: Alta

Titulo: Instalación guiada Identificador: RQ01 Categoría: Funcional DESCRIPTOR DEL REQUISITO: La instalación de la aplicación se realizará a través de un asistente, fácil e intuitivo. MEDICIÓN: El tiempo de instalación será inferior a 5 minutos. BENEFICIOS: El usuario no tendrá que copiar los archivos, ni registrar las librerías del sistema (dlls). El asistente se encargará de ello. REQUISITOS RELACIONADOS: COMENTARIOS / SOLUCIONES SUGUERIDAS: Se facilitará al usuario la aplicación en un CD-ROM, con auto-arranque, que ejecuta el asistente de instalación.


70



Prioridad: Media

Titulo: Cuadro de mandos Identificador: RQ02 Categoría: Funcional DESCRIPTOR DEL REQUISITO: Al inicio de la aplicación, se visualizará en primer lugar un cuadro de mandos que resume la situación actual del estado de las incidencias, permitiendo conocer las incidencias que actualmente se encuentran abiertas, cerradas y en curso. MEDICIÓN: BENEFICIOS: Facilita conocer las incidencias que están pendientes de ser cerradas y, conocer de un vistazo el estado actual del servicio. REQUISITOS RELACIONADOS: COMENTARIOS / SOLUCIONES SUGUERIDAS:


71



Prioridad: Media

Titulo: Sección incidencias Identificador: RQ03 Categoría: Funcional DESCRIPTOR DEL REQUISITO: Permitirá conocer el estado de todas las incidencias, gestionarlas y abrir nuevas incidencias a través del formulario. MEDICIÓN: BENEFICIOS: Gestionar en una sección todas las opciones relacionadas con las incidencias. REQUISITOS RELACIONADOS: RQ04 COMENTARIOS / SOLUCIONES SUGUERIDAS:


72



Prioridad: Media

Titulo: Apertura de incidencias Identificador: RQ04 Categoría: Funcional DESCRIPTOR DEL REQUISITO: La apertura de nuevas incidencias se realizará rellenando un formulario en el que se indicará el canal, técnico de soporte al que se le asigna inicialmente su resolución, los datos del usuario/cliente, la prioridad asignada, la categoría a la que pertenece y su descripción. MEDICIÓN: BENEFICIOS: Facilitar la introducción de nuevas incidencias. REQUISITOS RELACIONADOS: RQ03 COMENTARIOS / SOLUCIONES SUGUERIDAS:


73



Prioridad: Media

Titulo: Sección soluciones Identificador: RQ05 Categoría: Funcional DESCRIPTOR DEL REQUISITO: Esta base de conocimiento, permite que tras la resolución de una incidencia, su identificador se adjunte a la categoría a que pertenece, para posteriores consulta por parte de otros técnicos. MEDICIÓN: BENEFICIOS: Compartir el conocimiento entre los técnicos, facilitando la resolución de incidencias ya resultas anteriormente. REQUISITOS RELACIONADOS: COMENTARIOS / SOLUCIONES SUGUERIDAS: Inicialmente se pueden incluir las incidencias más frecuentes, a modo de procedimientos de resolución para los técnicos y, las incidencias más complejas.


74



Prioridad: Media

Titulo: Sección inventario Identificador: RQ06 Categoría: Funcional DESCRIPTOR DEL REQUISITO: Permitirá conocer el parque informático y los activos (hardware y software) relacionados con las incidencias. MEDICIÓN: BENEFICIOS: La descripción de las estaciones de trabajo que forman el parque informático y de sus activos, es una información clave para la resolución de incidencias y la detección de la causa de las mismas. REQUISITOS RELACIONADOS: RQ07 y RQ08 COMENTARIOS / SOLUCIONES SUGUERIDAS:


75



Prioridad: Media

Titulo: Estaciones de trabajo Identificador: RQ07 Categoría: Funcional DESCRIPTOR DEL REQUISITO: Permitirá dar de alta las estaciones de trabajo del parque informático y conocer la descripción de las mismas en cuanto a su nombre, modelo, fabricante, numero de serie, configuración de la red local, etc. MEDICIÓN: BENEFICIOS: Facilitar la resolución de incidencias y la detección de la causa de las mismas. REQUISITOS RELACIONADOS: RQ06 y RQ08 COMENTARIOS / SOLUCIONES SUGUERIDAS:


76



Prioridad: Media

Titulo: Activos Identificador: RQ08 Categoría: DESCRIPTOR DEL REQUISITO: Conocer el hardware y software que forman el parque informático en detalle en base al nombre del producto, número de serie, proveedor, precio, etc. MEDICIÓN: BENEFICIOS: Facilitar la resolución de incidencias y la detección de la causa de las mismas. REQUISITOS RELACIONADOS: RQ06 y RQ07 COMENTARIOS / SOLUCIONES SUGUERIDAS:


77



Prioridad: Media

Titulo: Sección compras Identificador: RQ09 Categoría: Funcional DESCRIPTOR DEL REQUISITO: Conocer los proveedores con los que se tienen acuerdos y facilitar la realización de documento de solicitud de compra. MEDICIÓN: BENEFICIOS: Facilitar la realización de documento de solicitud de compra. REQUISITOS RELACIONADOS: RQ10 COMENTARIOS / SOLUCIONES SUGUERIDAS:


78



Prioridad: Media

Titulo: Proveedores Identificador: RQ10 Categoría: Funcional DESCRIPTOR DEL REQUISITO: Conocer y dar de alta a nuevos proveedores. MEDICIÓN: BENEFICIOS: Facilitar el encontrar los datos de contacto de los proveedores. REQUISITOS RELACIONADOS: RQ09 COMENTARIOS / SOLUCIONES SUGUERIDAS:


79



Prioridad: Media

Titulo: Acuerdos de Nivel de Servicio (ANS) Identificador: RQ11 Categoría: Funcional DESCRIPTOR DEL REQUISITO: Permitirá dar de alta los contratos por Acuerdos de Nivel de Servicio, junto con su información básica, para su posterior consulta al inicio de la resolución de las incidencias de los clientes. MEDICIÓN: BENEFICIOS: Permitirá conocer los acuerdos firmados, las partes que intervienen y, las fechas de inicio y finalización de los acuerdos. REQUISITOS RELACIONADOS: COMENTARIOS / SOLUCIONES SUGUERIDAS: A través de los Acuerdos de Nivel de Servicio, se permite extrapolar el uso del sistema a usuarios terceros, fuera de la organización, es decir, los clientes. La gestión de los Acuerdos de Nivel de Servicio, permiten conocer el tipo de servicio ofrecido en relación a la resolución de incidencias.


80



Prioridad: Media

Titulo: Sección Informes Identificador: RQ12 Categoría: Funcional DESCRIPTOR DEL REQUISITO: Permitirá la obtención de informes basados en los datos de la resolución de incidencias, gracias a los informes predefinidos que posee la aplicación. MEDICIÓN: BENEFICIOS: Conocer y analizar el estado del servicio TI. REQUISITOS RELACIONADOS: COMENTARIOS / SOLUCIONES SUGUERIDAS:


81



Prioridad: Alta

Titulo: Control de acceso Identificador: RQ13 Categoría: Seguridad DESCRIPTOR DEL REQUISITO: Al inicio de la aplicación se solicitará un usuario y contraseña, que identifique de forma inequívoca al técnico de soporte. MEDICIÓN: BENEFICIOS: Permitirá conocer y analizar el rendimiento de cada técnico en materia de resolución de incidencias al responsable de TI. REQUISITOS RELACIONADOS: COMENTARIOS / SOLUCIONES SUGUERIDAS:


82



Prioridad: Media

Titulo: Menús desplegables Identificador: RQ14 Categoría: Fiabilidad DESCRIPTOR DEL REQUISITO: La información referente al estado de la incidencia, el canal, la prioridad y la categoría, se seleccionará a través de un menú desplegable. MEDICIÓN: BENEFICIOS: Mantener la integridad de la información y su veracidad. REQUISITOS RELACIONADOS: COMENTARIOS / SOLUCIONES SUGUERIDAS:


83



Prioridad: Media

Titulo: Base de datos Identificador: RQ15 Categoría: Operativo DESCRIPTOR DEL REQUISITO: El sistema gestor de la base de datos relacional será Microsoft Access. MEDICIÓN: BENEFICIOS: Permitirá al responsable de TI facilitar su explotación. REQUISITOS RELACIONADOS: COMENTARIOS / SOLUCIONES SUGUERIDAS:


84



Prioridad: Alta

Titulo: Interfaz gráfico Identificador: RQ16 Categoría: Presentación DESCRIPTOR DEL REQUISITO: Interfaz grafico agradable al usuario, fácil e intuitivo. MEDICIÓN: BENEFICIOS: Facilitar el acceso a las funciones de negocio a través de las barras de menús y botones. En un entorno gráfico conocido por el usuario. REQUISITOS RELACIONADOS: COMENTARIOS / SOLUCIONES SUGUERIDAS:


85


Fecha: 4/12/2006 Versión: 1.0 Estado: Rechazado

Prioridad: Baja

Titulo: Asesor ITIL Identificador: RQ17 Categoría: Funcional DESCRIPTOR DEL REQUISITO: Facilitar una guía de consulta y ayuda al usuario, ofreciendo información sobre el modelo de gestión ITIL. MEDICIÓN: BENEFICIOS: Permitiría establecer relaciones con nuevos clientes que soliciten información ante la necesidad de un Service Desk en su organización. REQUISITOS RELACIONADOS: COMENTARIOS / SOLUCIONES SUGUERIDAS:


86

6.7 Listado de funciones lógicas del nuevo sistema

Las funciones lógicas que se representan en el modelo lógico del nuevo

sistema son las siguientes:

1. Introducir usuario y contraseña.

2. Validar.

3. Solicitar servicio.

4. Ejecutar aplicación.

5. Presentación.


87

6.8 Modelo Lógico del Nuevo Sistema

A continuación se muestran el nivel 0 (nivel contextual) y el nivel 1 (nivel

conceptual) del modelo lógico del nuevo sistema.

Nivel contextual:

Flujos de datos:

� Usuario y contraseña: Identifican inequívocamente al los técnicos de

soporte y al responsable de TI el acceso al sistema.

� Rechazo: No se pueden autenticar al usuario, negándole el acceso al

sistema.

� Incidencia: Acontecimiento que sobreviene en el curso del negocio,

que interrumpe o reduce el servicio.


88

� Servicio: Solicitud de una ejecución por parte del usuario de una

acción.

� Resultado por pantalla: Presentación gráfica como resultado de la

solicitud de un servicio.

� Informe: Presentación impresa como resultado de la solicitud de un

servicio.


89

Nivel conceptual:

Flujos de datos:

� Usuario y contraseña: Identifican inequívocamente al los técnicos de

soporte y al responsable de TI el acceso al sistema.

� Rechazo: No se pueden autenticar al usuario, negándole el acceso al

sistema.

� Valido: El usuario ya identificado accede al sistema.

� Servicio: Solicitud de una ejecución por parte del usuario de una

acción.

� Resultado por pantalla: Presentación gráfica como resultado de la

solicitud de un servicio.


90

� Informe: Presentación impresa como resultado de la solicitud de un

servicio.

Almacenes:

� Usuarios: Este almacén contiene los datos de acceso como usuario,

contraseñas y privilegios de acceso.

� Clientes: Contiene toda la información relativa a los clientes.

� Incidencias: Contiene la descripción completa de cada una de las

incidencias registradas.

� Inventario: Contienen información relativa al parque informático,

estaciones de trabajo, hardware y software.

� ANS: Contiene información relativa de los Acuerdos de Nivel de

Servicio establecidos.

� Compras: Contiene información de los proveedores con los que se

tienen establecidos acuerdos comerciales.


91

6.8 Modelo Conceptual de Datos

Partiendo de la información de los flujos de datos y de los almacenes del

modelo lógico del nuevo sistema derivaron tras el proceso de normalización

en la estructura que muestra el siguiente diagrama entidad relación:

Figura 4.5 Diagrama Entidad-Relación.


92

A continuación se definen las entidades del modelo:

USUARIOS = {Usuario + contraseña + grupo} = E.Usuario.

CLIENTES = {Id + nombre + telefono + email + departamento} = E.Clientes.

INCIDENCIA = {Id + estado + canal + prioridad + tecnico + categoría + titulo +

descripción} = E.Incidencia.

INVENTARIO = {Id + tipo + nombre + proveedor + precio} = E.Inventario.

ANS = {Id + fecha_inicio + fecha_fin + parte} = E.ANS.

COMPRAS = {Id + proveedor + contacto} E.Compras


93

7. Diseño arquitectura técnica


94

Capítulo 7: Diseño arquitectura técnica

Este capítulo tiene como objetivo definir las posibles soluciones de

arquitectura que satisfagan tanto los requisitos del usuario, como las

restricciones de diseño impuestas.

Para ello, se han definido posibles soluciones alternativas, las cuales se las

somete a un estudio de viabilidad y se elige la más adecuada, para ser

desarrollada e finalmente implementada.

En esta fase de diseño de la arquitectura técnica se realizan cuatro

actividades fundamentalmente:

� Especificar la tecnología hardware, software y de comunicaciones de

cada alternativa a estudiar.

� Evaluar cada una, en sus aspectos estratégicos, organizativos,

operativos, técnicos y económicos.

� Seleccionar una alternativa y detallar sus fronteras de mecanización.

� Elaborar la planificación general del proyecto.


95

7.1 Diagrama de presentación

En este apartado se muestra un diagrama de representación del sistema con

los usuarios y la base de datos.

Todos los equipos, estaciones de trabajo y servidores se encontraran

interconectados en una red de área local.

La aplicación empleada para el registro de incidencias comunicadas por los

clientes, trabaja contra un servidor que contiene la base de datos donde se

almacena toda la información.

Figura 4.6 Diagrama de presentación.


96

El responsable de TI tiene acceso con la aplicación a los datos alojados en

el servidor para la relación de consultas e informes.

Los usuarios disponen de acceso seguro a Internet para la realización de

accesos remotos, consultas y recepción de incidencias vía chat o mediante

el correo electrónico.


97

7.2 Especificación de los componentes básicos

En primer lugar se identifican y definen las distintas alternativas que pueden

servir como soluciones viables para satisfacer los requisitos definidos y las

necesidades del usuario.

La arquitectura del proyecto está compuesta por componentes hardware,

software y de comunicaciones.

En este apartado se realizará una especificación detallada de cada uno de

los posibles componentes que se pondrán encontrar en las alternativas.

� Software

� Sistemas Operativos

PC Cliente:

• Windows XP Professional

• Windows Vista Business

• SuSE (Linux)

Servidor:

• Windows Server 2003

• SuSE Linux Enterprise Server


98

� Lenguajes de programación

• Visual Basic

• Java

� Hardware

� Estaciones de trabajo (PC)

� Servidor


99

7.2.1 Hardware necesario de nueva adquisición

Las estaciones de trabajo (PCs) que emplearan los técnicos de soporte y el

responsable de TI para la explotación del sistema CHM Service Desk

deberán cumplir los siguientes requisitos:

� Microprocesador Intel Pentium IV 1.5 GHz o superior.

� Memoria RAM de 512 MB.

� Disco duro de 10 GB.

� Tarjeta de sonido.

� Unidad de CD-ROM.

� Una tarjeta gráfica Super VGA (SVGA).

� Monitor, teclado y ratón.

Las necesidades que pretende cubrir el servidor, donde se almacena la base

de datos, debe cumplir los siguientes requisitos:

� Microprocesador Intel Xeon de núcleo cuádruple 2,66 GHz.

� Memoria RAM de 16 GB SDRAM.

� Almacenamiento de 6 TB.

� Unidad de CD-ROM o DVD-ROM.

� Una tarjeta gráfica Super VGA (SVGA).

Permitiendo así el acceso de 50 a 100 usuarios simultáneamente y, el

aprovechamiento de las necesidades de almacenamiento de datos.


100

7.2.2 Software necesario de nueva adquisición

Dependiendo de la alternativa que se seleccione como óptima, será

necesaria la adquisición de un sistema operativo u otro, que marcará los

componentes software compatibles que cubren las necesidades planteadas

y los requisitos expuestos por el cliente.


101

7.3 Arquitectura Cliente/Servidor

En el desarrollo del Sistema CHM Service Desk, se empleará una

arquitectura tipo cliente/servidor.

Esta arquitectura consiste básicamente en que un programa, el cliente,

realiza peticiones a otro programa, el servidor, que elabora y envía una

respuesta.

Este tipo de arquitectura distribuye los componentes de la aplicación y entre

los clientes y los servidores. La capacidad de proceso está repartida entre

los clientes y los servidores, aunque son más importantes las ventajas de

tipo organizativo, debidas a la centralización de la gestión de la información y

la separación de responsabilidades, lo que facilita el diseño del sistema.

La separación entre cliente y servidor es una separación de tipo lógico,

donde el servidor no se ejecuta necesariamente sobre una sola máquina, ni

es necesariamente un sólo programa.

Una disposición muy común son los sistemas multicapa, en los que el

servidor se descompone en diferentes programas que pueden ser

ejecutados por diferentes computadoras, aumentando así el grado de

distribución del sistema.


102

La arquitectura cliente/servidor sustituye a la arquitectura monolítica, en la

cual los terminales están conectados a un gran ordenador o mainframe, en

la que no hay distribución ni a nivel físico, ni a nivel lógico.

Las ventajas que presenta la arquitectura cliente/servidor son:

� Centralización del control. Los accesos, recursos y la integridad de los

datos son controlados por el servidor de forma que un programa

cliente no autorizado no pueda tener acceso y/o dañar el sistema.

� Escalabilidad. Se puede aumentar la capacidad de clientes y

servidores por separado.

� Reducción del tráfico de red.


103

7.4 Evaluación de las alternativas

Para realizar una correcta evaluación de las alternativas, es necesario que

se encamine la determinación de estas hacia el modo de operar del usuario

final, al tipo de arquitectura tecnológica a usar y a los usuarios finales.

7.4.1 Parámetros a valorar

Se presentan dos alternativas para la implementación de CHM Service Desk,

la primera en arquitectura para entornos Windows y, la segunda para

entornos Linux.

A continuación se especifican cada una de las alternativas explicadas con

anterioridad, incluyendo los componentes software y hardware de cada una.


104

ESPECIFICACIÓN ALTERNATIVA-1 TÍTULO: Entornos Windows CÓDIGO: A001 ANTECEDENTES: Los usuarios del sistema requieren un interfaz gráfico familiar y amigable. Los técnicos y administradores del sistema requieren un entorno Windows, de fácil administración y configuración. REQUISITOS: La alternativa cumple con los requisitos hardware óptimos para la implementación del sistema CHM Service Desk, así como con los requisitos especificados y exigidos por el cliente. NECESIDADES HARDWARE: Son las especificadas anteriormente, que satisfacen las necesidades del sistema y cumplen con los requisitos exigidos. NECESIDADES SOFTWARE: Los sistemas operativos para las estaciones de trabajo clientes será Windows XP Professional y los servidores Windows Server 2003. También se recomienda el software ofimático de Microsoft Office 2002 y, el uso de otras aplicaciones como el cliente de correo incluido en el sistema operativo. Además de la implantación de un plan director de seguridad.


105

ESPECIFICACIÓN ALTERNATIVA-2 TÍTULO: Entornos Linux CÓDIGO: A002 ANTECEDENTES: Los usuarios del sistema requieren un interfaz gráfico familiar y amigable. Se requieren conocimientos avanzados por parte de los técnicos del sistema para su administración y configuración. REQUISITOS: La alternativa cumple con los requisitos hardware óptimos para la implementación del sistema CHM Service Desk. Respecto a los requisitos especificados por el cliente, el sistema gestor de base de datos no podrá ser Microsoft Access, siendo en este caso la base de datos de la suite ofimática OpenOffice, que emplea un sistema gestor de bases de datos HSQL. NECESIDADES HARDWARE: Son las especificadas anteriormente, que satisfacen las necesidades del sistema y cumplen con los requisitos exigidos. NECESIDADES SOFTWARE: Los sistemas operativos para las estaciones de trabajo clientes será SuSE (Linux) y los servidores SuSE Linux Enterprise Server. También se recomienda el software ofimático de OpenOffice y, el uso de otras aplicaciones como el cliente de correo incluido en el sistema operativo. Además de la implantación de un plan director de seguridad.


106

7.4.2 Matrices de evaluación

La evaluación de las diferentes alternativas propuestas para el sistema CHM

Service Desk se realizará en base a cuatro aspectos, una evaluación

organizativa, operativa, técnica y económica.

Para analizar la evaluación de las distintas alternativas, se utilizará una

matriz de evaluación organizativa, donde se recoge y se puntúa las

diferentes características y parámetros de cada uno de los aspectos a

estudiar.

7.4.2.1 Evaluación organizativa, operativa y técnic a

� Evaluación organizativa:

� Incorporación a la organización de los recursos humanos necesarios

para el proceso de negocio.

� Incorporación necesaria de un responsable de TI.

� Incorporación de un grupo mínimo de técnicos de soporte.

� Incorporación de administradores de sistema.

� Incorporación de nuevas normativas para el uso del sistema,

directivas, políticas de seguridad, etc.


107

� Evolución operativa:

� Seguridad de la información. Confidencialidad, integridad y

disponibilidad.

� Facilidad de gestión.

� Fiabilidad.

� Evolución técnica:

� Licencias software.

� Software libre.

� Portabilidad.


108

7.4.2.2 Evaluación económica

La evaluación económica está basada en la viabilidad, que considera lo

obtenido como la inversión o gasto en el sistema. Un estudio detallado del

factor económico se realiza en base al llamado análisis de coste/beneficio.

En él se marcarán los costes del proyecto y se contrastarán con los

beneficios que aportará el sistema.

Existen beneficios tangibles, aquellos que se pueden valorar directamente y

por tanto cuantificar, como por ejemplo, aumento de número de incidencias

cerradas y, beneficios intangibles, aquellos cuyos valores no se pueden

precisar y son resultado de juicios subjetivos, como por ejemplo la

efectividad en base a la imagen corporativa.

Con los costes y beneficios cuantificados de alguna manera, se determina la

rentabilidad del proyecto mediante consideraciones de amortización, tiempo

requerido para recuperar el dinero invertido en el sistema.

Por ello, es suficiente con valorar los costes tangibles, que están

generalmente asociados al desarrollo del sistema.


109

Los costes a analizar son los siguientes:

� Costes de implantación:

� Costes de desarrollo en recursos humanos, como programadores,

jefe de proyecto, coordinador de proyecto y director del proyecto.

� Costes de formación en el lenguaje de programación.

� Costes de formación para los usuarios finales del sistema.

� Costes de puesta en marcha tras el desarrollo del sistema.

� Costes de tecnología:

� Costes hardware para la adquisiciones de nuevos equipos, incluidos

los costes instalación y de mobiliario necesario.

� Costes software en licencias para el uso de aplicaciones comerciales.

� Costes en comunicación para la red de área local.

� Costes de operacionales:

� Costes de los sistemas de almacenamiento de información.

� Costes de seguridad.

� Costes de mantenimiento y de actualización del sistema.


110

7.4.3 Valoración de las alternativas

Una vez mencionadas las evaluaciones a analizar, se realiza una matriz de

evaluación organizativa, especificando el concepto de cada grupo de

parámetros y los criterios seguidos a la hora de calificarlo.

Cada característica a analizar se referencia en la matriz con un número y, se

le asigna un valor o peso entre 1 y 3, siendo 3 el valor más alto y, 1 el más

bajo, dependiendo de la importancia que tenga dicho factor en el sistema

CHM Service Desk.

ALTERNATIVA 1 ALTERNATIVA 2 NUMERO PARÁMETRO PESO PESO

ORGANIZATIVOS 1.1 Responsable de TI 3 3 2.1 Técnicos de soporte 3 3 2.3 Administradores de sistema 3 2

3.4 Incorporación de nuevas normativas

3 3

OPERATIVOS 2.1 Seguridad 3 2 2.2 Facilidad de gestión 3 2 2.3 Fiabilidad 2 1

TÉCNICOS 3.1 Licencias software 1 3 3.2 Portabilidad 1 2 22 21

Figura 4.7.


111

ORGANIZATIVOS OPERATIVOS TÉCNICOS

ALTERNATIVA 1 12 8 2 ALTERNATIVA 2 11 5 5

Figura 4.8.

12

8

2

11

5 5

0

2

4

6

8

10

12

Alternativa 1 Alternativa 2

Organizativos Operativos Tecnicos

Figura 4.9.

1211

8

5

2

5

0

2

4

6

8

10

12

Organizativos Operativos Técnicos



112

De manera similar a la matriz de evaluación organizativa, la matriz de evaluación de costes recoge por grupos cada uno de los costes estimables.

En esta matriz, se anotan los costes reales estimados o esperados de cada

parámetro para cada una de las alternativas, obteniéndose como suma de

ellos el valor del coste total de cada alternativa propuesta.

La matriz de evaluación de costes para este sistema es la siguiente:


COSTES DE IMPLANTACIÓN Desarrollo 30.000 30.000 Formación 1.000 2.000 Puesta en marcha

1.100 1.300

COSTES DE TECNOLOGÍA Hardware 4.000 4.000 Software 3.000 0 Comunicaciones 500 500

COSTES OPERACIONALES Almacenamiento 10.000 10.000 Seguridad 2.500 2.000 Mantenimiento 800 1.000

COSTES TOTALES

52.900 50.800

Figura 4.10.


113

7.4.4 Selección de la alternativa

A la vista de los datos reflejados por la matriz de evaluación organizativa se

puede observar la diferencia al ponderar cada una de las alternativas por

separado.

En este caso en lo que respecta a los factores organizativos, ambas

alternativas están prácticamente al mismo nivel, superando la alternativa 1 a

la 2, por un punto de diferencia.

En relación a aspectos operativos, la alternativa 1 supera nuevamente a la

alternativa 2, con un índice de dispersión bajo.

Finalmente, en aspectos técnicos, es la alternativa 2, quien supera a la

alternativa 1.

Respecto a los factores económicos, no existen diferencias significativas

entre ambas alternativas, compensándose los costes de licencias con los

costes de formación y mantenimiento.


114

7.5 Planificación del proyecto

Una planificación estimada con la que se ha determinado las distintas fases

del proyecto de aplicación es la siguiente:

La planificación del proyecto se basa el cálculo del comienzo, duración y

finalización de las tareas en un calendario laboral del año 2006 y 2007,

suprimiéndose los fines de semana y festivos como días laborables.

Nombre de la tarea Duración Comienzo Finalización

1 Identificación de necesidades 15 días 23/10/06 10/11/06 2 Documento conceptos del sistema - 10/11/06 10/11/06 3 Reunión final de fase - 10/11/06 10/11/06 4 Análisis de requisitos 30 días 13/11/06 22/12/06 5 Entrega MFSA - 22/12/06 22/12/06 6 Entrega MLSA - 22/12/06 22/12/06 7 Entrega lista de requisitos - 22/12/06 22/12/06 8 Entrega MLNS - 22/12/06 22/12/06 9 Entrega MCD - 22/12/06 22/12/06

10 Reunión final de fase - 22/12/06 22/12/06 11 Diseño de arquitectura técnica 15 días 25/12/06 12/01/07 12 Reunión final de fase - 12/01/07 12/01/07 13 Diseño externo 20 días 15/01/07 09/02/07 14 Modelo nuevo - 09/02/07 09/02/07 15 Reunión final de fase - 09/02/07 09/02/07 16 Diseño interno 20 días 12/02/07 09/02/07 17 Reunión final de fase - 09/03/07 09/02/07 18 Programación 60 días 12/03/07 01/06/07 19 Reunión final de fase - 01/06/07 01/06/07 20 Pruebas 7 días 04/06/07 12/06/07 21 Resultados pruebas implantación - 12/06/07 12/06/07 22 Reunión final de fase - 12/06/07 12/06/07 23 Implantación 7 días 13/06/07 21/06/07 24 Reunión final de fase - 21/06/07 21/06/07 25 Mantenimiento 3 días 22/06/07 26/06/07


115

8. Diseño externo


116

Capítulo 8: Diseño externo

Este en este capítulo se parte de la alternativa elegida en el capítulo anterior

de Diseño de la Arquitectura Técnica, en esta fase se completarán los

requisitos físicos del nuevo sistema, se diseñarán las entradas y salidas, se

completará la especificación de los procesos del modelo y se elaborará el

modelo lógico de datos, a partir de las transacciones que realice el sistema.

A fin de completar la definición del modelo físico, se le dota de procesos de

control y, seguridad, necesarios para una instalación mecanizada. Por lo

tanto, el conocimiento del nuevo sistema aumentará considerablemente en

esta etapa y se podrá definir la estrategia a seguir en los planes de

formación, la conversión de los datos, las pruebas del sistema y su

implantación.

8.1 Modelo Físico del Nuevo Sistema

Partiendo del Modelo Lógico del Nuevo Sistema, junto con las

especificaciones de la alternativa escogida en la etapa de Diseño de

arquitectura técnica.


117

Se realizaran en esta nueva etapa las siguientes actividades:

� Establecer las fronteras de mecanización , que indican que

procesos deben realizarse manualmente y cuáles mediante

ordenador.

� Determinar los diferentes tipos de procesos y, especificaros (por

lotes, on-line, cliente, servicio web, su frecuencia y la situación física

donde se procesa: servidor, estaciones cliente, etc).

� Diseñar las entradas y salidas del sistema , son las ventanas,

informes, formularios y ficheros.

� Estimar los volúmenes de información para el desarrollo del

modelo lógico de datos.

� Definir los procesos de control y seguridad.

Con ello, se obtendrá el Modelo Físico del nuevo sistema.


118

8.1.1 Fronteras de mecanización

En la fase de Diseño de arquitectura técnica se especificaron las alternativas

de implementación del sistema sobre una plataforma tecnológica, así como

las características técnicas, organizativas y operativas de la solución a

desarrollar.

Ahora se pueden determinar qué procesos formarán parte del modelo físico

del nuevo sistema. Esta tarea, puede realizarse partiendo de los diagramas

de flujo de datos del modelo lógico nuevo sistema. En su nivel conceptual,

se establecieron con anterioridad las fronteras de mecanización para el

sistema.


119

El modelo lógico del nuevo sistema considerado en la fase de Análisis de

requisitos es el siguiente:


120

8.1.2 Especificación de procesos

La descripción de los procesos realizada en el Modelo lógico del nuevo

sistema tiene en consideración la lógica de negocio, ahora a partir de las

fronteras de mecanización, los procesos adquieren la característica de ser

manuales o automáticos.

Esta revisión de procesos será una actividad a realizar durante todo el

desarrollo del modelo físico, pudiendo haber cambios dinámicamente debido

a la incorporación de nuevos procesos.

A continuación se muestra las especificaciones de los procesos.


121

PROCESO - 1

Proceso: Introducir usuario y contraseña.

Localización: Cliente. Categoría del proceso: Online, Cliente/Servidor. Tipo de proceso: Manual. Frecuencia: Aperiódica.

Descripción: Cada usuario del sistema debe identificarse con un nombre de usuario y contraseña. Registrándose la fecha y hora de inicio de sesión en el sistema.

PROCESO - 2

Proceso: Validar.

Localización: Servidor. Categoría del proceso: Online, Cliente/Servidor. Tipo de proceso: Automático. Frecuencia: Aperiódica.

Descripción: Comprueba que el usuario y su contraseña son aceptados en el sistema, asignándoles los privilegios de acceso según la categoría del perfil. En caso contrario, el sistema rechaza la entrada del usuario al sistema.


122

PROCESO - 3

Proceso: Solicitar servicio.

Localización: Servidor. Categoría del proceso: Online, Cliente/Servidor. Tipo de proceso: Manual. Frecuencia: Aperiódica.

Descripción: Este proceso se basa en la apertura de la aplicación propiamente dicha, para que el usuario solicite información y los servicios que desee al sistema CHM Service Desk.

PROCESO - 4

Proceso: Ejecutar aplicación.

Localización: Servidor de datos. Categoría del proceso: Online, Cliente/Servidor. Tipo de proceso: Manual. Frecuencia: Aperiódica.

Descripción: El usuario solicitara al sistema realizar funciones mediante el uso de los menús y los diferentes botones.


123

PROCESO - 5

Proceso: Presentación.

Localización: Cliente. Categoría del proceso: Online, Cliente/Servidor. Tipo de proceso: Automática. Frecuencia: Aperiódica.

Descripción: Este proceso muestra al usuario por pantalla o bien, por impresora, la información solicitada que fue elaborada en el proceso anterior.


124

8.1.3 Diseño del Interfaz de usuario

A continuación se muestra el diseño de los diferentes elementos de entrada

al sistema, como pantallas o ventanas, formularios y ficheros maestros,

especificando sus características y validaciones.

El interfaz de usuario se basa en la realización de pantallas e informes, para

facilitar la interacción de usuario con el sistema empleándose barras menús

y barras de botones, conformando un interfaz grafico de usuario (GUI),

intuitivo y amigable.

Se procede por lo tanto al diseño de cada una de las pantallas y a la

especificación del contenido de ambas.


125

CÓDIGO: 00.

IDENTIFICACIÓN CÓDIGO: 00. NOMBRE: SPLASH INICIAL. DESCRIPCIÓN Se muestra una imagen, durante la carga inicial de la aplicación. VALIDACIÓN No existen validaciones en esta pantalla. TABLAS O FICHEROS UTILIZADOS En esta pantalla no se utiliza ninguna tabla ni ficheros de datos.


126

CÓDIGO: 01.

IDENTIFICACIÓN CÓDIGO: 01. NOMBRE: LOGGING. DESCRIPCIÓN Autenticar la entrada del usuario en la aplicación, comprobando los derechos del grupo al que pertenece (Administrador o usuario). Registra la fecha, hora, grupo y estado de los accesos válidos e inválidos. VALIDACIÓN Solo permite el acceso a usuarios registrados. TABLAS O FICHEROS UTILIZADOS Utiliza la base de datos ACL y, las tablas de ingreso_contraseña y contraseñas.


127

CÓDIGO: 02.

IDENTIFICACIÓN CÓDIGO: 02. NOMBRE: MENU PRINCIPAL. DESCRIPCIÓN Desde el menú principal se tiene acceso a todas las funciones de la aplicación, excepto a las que están deshabilitadas por pertenecer por derechos de acceso al grupo de administradores. VALIDACIÓN Antes de abandonar la aplicación, se pide confirmación al usuario. TABLAS O FICHEROS UTILIZADOS: Utiliza la base de datos CHM.


128

CÓDIGO: 03.

IDENTIFICACIÓN CÓDIGO: 03. NOMBRE: INCIDENCIAS. DESCRIPCIÓN Permite la gestión completa del ciclo de vida de las incidencias. Permite añadir, modificar, eliminar, buscar y solucionar una incidencia. La fecha, hora y técnico, se asignan automáticamente. VALIDACIÓN Antes de eliminar un registro, se pide confirmación al usuario. TABLAS O FICHEROS UTILIZADOS: Utiliza la base de datos CHM.


129

CÓDIGO: 04.

IDENTIFICACIÓN CÓDIGO: 04. NOMBRE: CLIENTES. DESCRIPCIÓN Gestión completa de los registros de clientes. Permite conocer los datos principales de los clientes y numero de Acuerdo de Nivel de servicio establecido. Permitiendo añadir, modificar, eliminar, buscar los registros. VALIDACIÓN Antes de eliminar un registro, se pide confirmación al usuario. TABLAS O FICHEROS UTILIZADOS: Utiliza la base de datos CHM.


130

CÓDIGO: 05.

IDENTIFICACIÓN CÓDIGO: 05. NOMBRE: SOLUCIONES. DESCRIPCIÓN La gestión de soluciones, permite a los técnicos cerrar las incidencias, asignando solución con incidencia. Facilitar compartir el conocimiento entre los técnicos. VALIDACIÓN Antes de eliminar un registro, se pide confirmación al usuario. TABLAS O FICHEROS UTILIZADOS: Utiliza la base de datos CHM.


131

CÓDIGO: 06.

IDENTIFICACIÓN CÓDIGO: 06. NOMBRE: INVENTARIO. DESCRIPCIÓN La gestión del inventario, permite conocer el parque informático del cliente y es una fuente de información valiosa para los técnicos en materia de resolución de incidencias. VALIDACIÓN Antes de eliminar un registro, se pide confirmación al usuario. TABLAS O FICHEROS UTILIZADOS: Utiliza la base de datos CHM.


132

CÓDIGO: 07.

IDENTIFICACIÓN CÓDIGO: 07. NOMBRE: COMPRAS. DESCRIPCIÓN Facilita la creación del documento de compras. El propietario, la fecha y estado (pendiente) se asignan automáticamente. Solo los usuarios del grupo administrador pueden cambiar el estado de la orden (aprobada o rechazada). VALIDACIÓN Antes de eliminar un registro, se pide confirmación al usuario. Para continuar con la orden su estado debe ser aprobado. TABLAS O FICHEROS UTILIZADOS: Utiliza la base de datos CHM.


133

CÓDIGO: F0.

IDENTIFICACIÓN CÓDIGO: 11. NOMBRE: INFORME COMPRAS. DESCRIPCIÓN Facilita la creación del documento de compras, exportando los datos introducidos del registro a formato MS Word (.doc) .


134

CÓDIGO: 08.

IDENTIFICACIÓN CÓDIGO: 08. NOMBRE: ACUERDOS DE NIVEL DE SERVICIO (ANS). DESCRIPCIÓN Permite conocer los ANS suscritos por el cliente. Además se puede indicar donde se encuentra el contrato (localización) y si está digitalizado, puede abrirse desde la aplicación. VALIDACIÓN Antes de eliminar un registro, se pide confirmación al usuario. TABLAS O FICHEROS UTILIZADOS: Utiliza la base de datos CHM. Ficheros digitalizados como contratos (ANS).


135

CÓDIGO: 09.

IDENTIFICACIÓN CÓDIGO: 09. NOMBRE: CONFIGURACIÓN – PERMISOS. DESCRIPCIÓN Gestión de usuarios y permisos de la aplicación. VALIDACIÓN Antes de añadir, modificar, eliminar o guardar un registro, se pide confirmación al usuario. TABLAS O FICHEROS UTILIZADOS: Utiliza la base de datos ACL.


136

CÓDIGO: 10.

IDENTIFICACIÓN CÓDIGO: 10. NOMBRE: CONFIGURACIÓN – USUARIOS. DESCRIPCIÓN Listado de usuarios que tienen acceso al sistema, incluyendo su contraseña y grupo al que pertenecen. VALIDACIÓN No existen validaciones en esta pantalla. TABLAS O FICHEROS UTILIZADOS: Utiliza la base de datos ACL.


137

CÓDIGO: 11.

IDENTIFICACIÓN CÓDIGO: 10. NOMBRE: CONFIGURACIÓN – LOG. DESCRIPCIÓN Registro de entrada de los usuarios a la aplicación. Identificando al usuario, grupo, fecha y hora del acceso valido o invalido. VALIDACIÓN No existen validaciones en esta pantalla. TABLAS O FICHEROS UTILIZADOS: Utiliza la base de datos ACL.


138

CÓDIGO: 12.

IDENTIFICACIÓN CÓDIGO: 12. NOMBRE: INFORMES. DESCRIPCIÓN Menú de informes reservado a usuarios del grupo de administradores.


139

CÓDIGO: F1.

IDENTIFICACIÓN CÓDIGO: F1. NOMBRE: INFORME DE INCIDENCIAS. DESCRIPCIÓN Informe resumen de las incidencias del sistema, clasificadas por estado y prioridad. Incluye un diagrama de sectores.


140

CÓDIGO: F2.

IDENTIFICACIÓN CÓDIGO: F2. NOMBRE: INFORME DE CLIENTES. DESCRIPCIÓN Informe resumen con los datos principales de todos los clientes.


141

CÓDIGO: F3.

IDENTIFICACIÓN CÓDIGO: F3. NOMBRE: INFORME DE CLIENTES. DESCRIPCIÓN Informe resumen de la base de datos de soluciones.


142

CÓDIGO: F4.

IDENTIFICACIÓN CÓDIGO: F4. NOMBRE: INFORME DE INVENTARIO. DESCRIPCIÓN Informe resumen de la base de datos de inventario.


143

CÓDIGO: F5.

IDENTIFICACIÓN CÓDIGO: F5. NOMBRE: INFORME DE LOS ACUERDOS DE NIVEL DE SERVICIO. DESCRIPCIÓN Informe resumen de la base de datos de ANS.


144

CÓDIGO: F6.

IDENTIFICACIÓN CÓDIGO: F6. NOMBRE: INFORME DE VENDEDORES. DESCRIPCIÓN Informe resumen de la base de datos de vendedores.


145

CÓDIGO: F7.

IDENTIFICACIÓN CÓDIGO: F7. NOMBRE: INFORME DE LOG DE ACCESOS AL SISTEMA. DESCRIPCIÓN Informe resumen de los accesos realizados al sistema, indicando nombre, usuario, grupo, fecha, hora y estado del acceso.


146

8.1.4 Estimación de volúmenes de información

La información de volúmenes persigue dos objetivos, el primero de ellos es

poder dimensionar el tipo de transacciones que pueden, ajustando el modelo

a las necesidades físicas de la aplicación.

Las transacciones que conlleven un mayor número de accesos a la base de

datos, serán las más críticas.

Además este estudio de volúmenes indicará si los procesos definidos en el

modelo lógico están bien diseñados respectos de los datos que manejan.

El segundo objetivo que se persigue en este análisis es la obtención de la

información acerca de las diferentes entidades del modelo de datos, a fin de

realizar un diseño lógico de estos.

Así, puede descubrirse la necesidad de crear nuevas claves o identificadores

que resten tiempo en los programas aunque ello conlleve aumentar la

información redundante y por tanto, la ocupación en disco.

Para realizar el estudio se parte del modelo lógico o físico de procesos, del

modelo de datos, del ciclo de vida de las entidades y de los diseños de

entrada.


147

8.1.5 Procesos de control y seguridad

En la etapa de Análisis de requisitos no se especificaron controles en la

explotación del sistema, tras la mecanización se hace posible su inclusión.

Los procesos de control y seguridad se incluyen dentro de alguno de los

procesos existentes o se integran en nuevos procesos dentro del modelo

físico.

Pare realizar un análisis completo del sistema deben estudiarse los

siguientes procesos:

� Controles destinados a preservar la integridad de los datos.

� Seguridad de la información y del acceso.

� Procedimiento de recuperación de la información.

� Realizar un histórico de la información.


148

8.1.5.1 Procesos de control

Este tipo de procesos son aquellos que de acuerdo al estudio de la

aplicación deben cumplirse por restricciones impuestas por los requisitos a

cumplir o bien por circunstancias detectadas en algún un momento del ciclo

de vida del sistema.

Entre las mediadas de control que preservan la integridad de la información

se pueden citar:

� Registro de logging de los usuarios que acceden a la aplicación.

� Control de registros leídos frente a registros grabados.

� Algoritmos que relacionen registros leídos, tratados y rechazados.

� Controles derivados de la utilización del sistema de base de datos:

lectura y escritura.

� Control de los archivos instalados durante el proceso de instalación

de la aplicación.

Estos procesos de control deben incorporarse al sistema, siendo

automáticos como el proceso de logging, o bien de forma manual, bajo la

supervisión del usuario.

De esta manera se podrá mantener la integridad de los datos y facilitar su

recuperación.


149

8.1.5.2 Procesos de seguridad

Este tipo de procesos o procedimientos están relacionados con la seguridad

de los datos y la privacidad de la información.

Entre las mediadas de seguridad que preservan la integridad de los datos de

la aplicación se descomponen en cuatro categorías:

� Seguridad de datos en su gestión: Asegurar que los datos de salida

del sistema sean utilizados por aquellos a los que van dirigidos, los

usuarios: técnicos de soporte y responsable de TI.

� Seguridad de la confidencialidad de la información: Para el

cumplimiento de LOPD vigente en la actualidad la información de

carácter personal es únicamente accesible por personal autorizado y,

su acceso es registrado.

� Seguridad del propio sistema: Asegurar la disponibilidad del sistema

antes caídas provocadas por el hardware o el software.

� Seguridad de la red de comunicaciones: El acceso al sistema solo es

posible si la conexión con la base de datos a través de la red esta

disponible.


150

8.2 Modelo Lógico de Datos

El modelo lógico establece la estructura de los datos con los que trabajan los

procesos de la aplicación, sin tener en cuenta los recursos físicos utilizados.

Estas estructuras se componen de relaciones o tablas en el modelo

relacional, donde las columnas representan atributos y las filas el conjunto

de ocurrencias de cada relación.

El modelo lógico se encarga de completar la información recabada en el

modelo conceptual:

� Entidades de datos.

� Atributos.

� Claves de la entidad.

� Relaciones entre entidades.

Para la realización del Modelo Lógico de Datos se necesitan cada una de las

definiciones de las entidades que intervienen en el Diagrama

Entidad/Relación y, de las relaciones entre ellas.


151

A continuación se detalla el Diagrama Entidad/Relación obtenido en la etapa

del análisis de requisitos.

Figura 4.5 Diagrama Entidad-Relación.


152

A continuación se detallan cada una de las entidades y relaciones más

relevantes que constituyen el diagrama entidad/relación, detallando en cada

una de ellas sus atributos y las claves principales según la normalización

establecida para ello.

� Entidades:

USUARIOS = {Usuario + contraseña + grupo} = E.Usuario.

CLIENTES = {Id + nombre + telefono + email + departamento} =

E.Clientes.

INCIDENCIA = {Id + estado + canal + prioridad + tecnico + categoría +

titulo + descripción} = E.Incidencia.

INVENTARIO = {Id + tipo + nombre + proveedor + precio} = E.Inventario.

ANS = {Id + fecha_inicio + fecha_fin + parte} = E.ANS.

COMPRAS = {Id + proveedor + contacto} = E.Compras.


153

� Relaciones:

COMUNICA = {Id_Cliente + Id_Incidencia}.

FIRMA = {Id_Cliente + Id_ANS}.

POSEE = {Id_Cliente + Id_Inventario}.

SOMUNISTRADO = {Id_Compra + Id_Inventario}.


154

8.3 Elaboración de los planes

La etapa de Diseño Externo finaliza con la preparación de la estrategia de

los planes de pruebas, conversión, formación e Implementación.

Estos planes son finalmente completados en la fase siguiente de Diseño

Interno, estableciéndose las pautas generales de ellos en esta fase, sobre

todo de cara a la preparación de las fases de Pruebas y de Implantación.

8.3.1 Plan de pruebas

La estrategia del plan de pruebas, establece los diferentes tipos de pruebas

a realizar para comprobar la integridad y funcionalidad del software

generado, en la fase de Pruebas.

Así mismo, debe establecerse si fuese necesario un entorno especifico para

la realización de las pruebas, los procedimientos de migración a este entorno

y los equipos que realizarán dichas pruebas.

� Realizar pruebas a todos los componentes de la aplicación, su tiempo

medio de ejecución, respuesta y de acceso.

� Comprobar la navegabilidad de la aplicación.

� Realizar mediciones de ocupación del espacio de almacenamiento

mínimo necesario y las necesidades de la memoria.


155

� Obtener la aprobación del cliente.

� Repetición de las pruebas ante la realización de un cambio, anomalía

o deficiencia detectada en la aplicación.

8.3.2 Plan de formación

El del plan de formación establece la estrategia de formación a realizar

dirigida a los diferentes usuarios finales del sistema, en cuanto a la

operación del sistema, su administración y mantenimiento.

� Elaboración del anexo: Guía de Instalación, aun que el instalador de

la aplicación es un sencillo asistente, se acompaña de un manual de

instalación paso a paso.

8.3.3 Plan de implantación

La estrategia del plan de implantación, establece la política a seguir para

poner en marcha el sistema, el tipo de implantación a seguir y, los procesos

a realizar ante a marcha atrás en caso de detectarse anomalías o

complicaciones.

� Coordinación a la hora de instalar tanto el hardware como el software.


156

� Realización de las operaciones pertinentes para que el cambio se

desarrolle adecuadamente.

8.3.4 Plan de conversión

El plan de conversión establece los procesos necesarios para la puesta en

marcha del sistema y para la conversión de formatos de ficheros o

documentos de entrada/salida que van a ser utilizados por el sistema.

Debe tenerse en cuenta que se puede aprovechar tanto datos, como

software y hardware del sistema actual para convertirlos al nuevo sistema.

� Prever la escalabilidad del sistema con el fin de adecuarlo a las

necesidades del sistema.

� Conversión de los documentos de entrada o salida.


157

9. Diseño interno


158

Capítulo 9: Diseño interno

Este en este capítulo se identifican y diseñan los diversos componentes

software del sistema, describiendo detalladamente sus especificaciones

físicas.

Dependiendo de la arquitectura elegida para el sistema final, estos

componentes pueden tener una naturaleza muy diversa. Con la ayuda del

Modelo Físico de Procesos realizado en la etapa de Diseño Externo, se

podrán reunir todas aquellas funciones de negocio de nivel más detallado

según su tipología de procesos, estructurar el sistema en un conjunto de

subsistemas.

El subsistema batch afecta a los procesos de la aplicación que precisen un

orden secuencial de ejecución. Para la realización y representación de este

subsistema se utilizará la técnica del diagrama HIPO, derivando los

diagramas de flujo de datos obtenidos en la fase de análisis de requisitos

hacia dicho diagrama.

El subsistema online recoge aquellos procesos de la aplicación que no se

realicen bajo un orden secuencial de ejecución, procesándose de manera

aleatoria a petición del usuario final de la aplicación. Para la representación y

análisis de este subsistema se utilizará el diagrama de cuadros estructurado

o STC.


159

También, en esta fase, se desarrollarán las especificaciones de cada uno de

los programas y de sus módulos.


160

9.1 Subsistema batch

El subsistema batch está constituido por todas las funciones de negocio que

precisan un orden secuencial de ejecución y vayan a procesarse bajo una

frecuencia que puede ser periódica (como la actualización de la información)

o aperiódica (como la ejecución de la aplicación).

Estas funciones han sido diseñadas en el Modelo Físico de Procesos, donde

sus componentes son flujos de datos, almacenes y procesos. Mediante la

derivación del DFD de la función en un diagrama HIPO, estos componentes

darán lugar a los ficheros y programas que se diseñarán y se especificarán

unitariamente.

Para la realización del diagrama HIPO y los procedimientos catalogados se

necesita partir del diagrama del Modelo lógico del nuevo sistema para

comprender las funciones y procesos que desempeña la aplicación.


161

El modelo lógico del nuevo sistema es:

Una vez realizado ese estudio, se dota a los procesos de una secuencialidad

para obtener los diagramas HIPO, los cuales se incorporan en los cuadernos

de carga que se muestran a continuación.


162

9.1.1 Cuadernos de carga

IDENTIFICACIÓN CÓDIGO: P2. NOMBRE: VALIDAR. DESCRIPCIÓN Proceso que identifica al usuario que desea acceder a la aplicación, validando o rechazando su entrada y registrado el acceso. El proceso realizará una conexión a la base de datos de usuarios y contraseñas para verificar su autenticidad y comprobar sus permisos de usuario. DIAGRAMA DFD

DIAGRAMA HIPO


163

IDENTIFICACIÓN CÓDIGO: P3. NOMBRE: SOLICITAR SERVICIO. DESCRIPCIÓN Proceso que gestiona la solicitud de servicios a la aplicación. DIAGRAMA DFD

DIAGRAMA HIPO


164

9.2 Subsistema online

El subsistema online está constituido por aquellas funciones de negocio que

no se realizan bajo un orden secuencial de ejecución y además se procesan

de manera aleatoria a petición del usuario.

Para la realización, del diagrama de cuadros estructurado y el análisis de

transformación y transacción se necesita el DFD del Modelo Físico de

procesos para comprender las funciones de negocio que se desempeñan en

esta aplicación.

Una vez identificados los procesos que no son secuenciales y que ejecuta el

usuario de forma aleatoria, se realiza el diagrama de cuadros estructurado o

STC.


165

9.3 Menús y pantallas

El diseño de diagrama de diálogos para la navegación del usuario en la

aplicación es el siguiente:


166

9. Programación


167

Capítulo 10: Programación

Este en este capítulo se alcanzará la transformación de la aplicación en un

conjunto de formularios que puedan ser ejecutados correctamente, bajo los

criterios de calidad estudiados y analizadas durante el ciclo de desarrollo de

la aplicación.

Para la realización de la aplicación se ha elegido un lenguaje visual y

orientado a eventos como es Microsoft Visual 6.0.

Al realizar la codificación de la aplicación en el lenguaje de programación

anteriormente mencionado, se tendrán en cuenta los procesos que debe

cumplir según el modelo lógico del nuevo sistema, estudiado en la fase de

estudio de la arquitectura y los cuadernos de carga diseñados en la fase

anterior, diseño interno.

Al terminar el análisis de esta fase se incluirá un manual de usuario que

incluirá el ámbito y entorno de la aplicación, los perfiles de los usuarios

finales y funcionamiento de la aplicación.

Durante la fase de programación se realizaron las pruebas unitarias, las

cuales consisten en comprobar la funcionalidad del sistema, de acuerdo con

las especificaciones de los cuadernos de carga. Para ello se han usado las


168

herramientas de depuración o debugger que incluye el entorno de desarrollo

de Microsoft Visual 6.0.

Para facilitar la instalación de la aplicación CHM Service Desk se ha se ha

empleado la herramienta de Asistente para empaquetado y distribución, la

cual viene incorporada en el paquete de aplicaciones Microsoft Visual Basic

6, por lo que se ha diseñado un asistente de instalación fácil e intuitivo.


169

10.1 Manual de usuario

A continuación se muestra el manual de usuario que se ha realizado para la

aplicación CHM Service Desk.

La realización de este manual, esta orientada a las funciones de la

aplicación que puede realizar el usuario final sobre cada uno de los controles

que se le presentan en cada formulario, no obstante algunos de estos

controles pueden estar desactivados en función de los privilegios del usuario

en función del grupo al cual pertenezca.


170

MANUAL DE USUARIO


171

10.1.1 Introducción

CHM Service Desk es una herramienta de gestión Service Desk basado en

el estándar ITIL adaptado a las necesidades de la PYME.

10.1.1.1 Objeto de la aplicación

CHM Service Desk es una solución que ofrece en un paquete integrado, la

gestión de incidencias, del conocimiento atreves de las soluciones, de sus

clientes, de la gestión del inventario, las compras y la gestión de los

Acuerdos de Nivel de Servicio (ANS).

Gracias sus potentes informes dispondrá de toda la información necesaria

como conocer el estado del servicio.

CHM Service Desk proporcionará un único punto de contacto entre los

usuarios y clientes, con las tecnologías de la información, incluye todo lo que

necesita para gestionar sus procesos de informática interna, lo cual redunda

en mayor productividad y mejor servicio para usuarios finales.

Todo ello gracias a su entorno gráfico, agradable e intuitivo, que facilita su

uso.


172

10.1.1.2 Ámbito de la aplicación

La aplicación de Gestión Service Desk facilitará a través de los diferentes

menús y, botones de la barra de herramientas, acceso a las diferentes

secciones:

� Inicio (Vista global), permite conocer el estado actual de las

incidencias: abiertas, cerradas y en curso.

� Incidencias, permitirá abrir y gestionar nuevas incidencias.

� Nueva solicitud.

• Estado: abierta, Cerrada o en curso.

• Modo: Llamada telefónica, e-mail, formulario, Chat, etc.

• Técnico: (a quien se le asigna la incidencia).

• Cliente: Nombre, ID, teléfono, etc.

• Prioridad: normal, alta, baja o Media.

• Categoría: General, Hardware, Internet, Impresoras,

Software, etc.

• Titulo.

• Descripción.


173

� Clientes, recoge toda la información relativa a los clientes que informan

de las incidencias.

� Soluciones (base de datos de consulta), tras resolver una solicitud se

pude adjuntar su referencia en la base de datos por categorías como:

� General.

� Hardware.

� Red.

� Internet.

� Software.


técnicos.

� Inventario, Conocer el parque informático los activos.



� Activos: Hardware y Software: Producto, número de serie,



174

� Compras, permite conocer los proveedores con los que se tienen

acuerdos y, realizar un documento de solicitud de compra.

� Nuevo pedido a proveedor.

� Nuevo Proveedor.

� Contratos (ANS), permite controlar los Acuerdos de Nivel de Servicios

firmados, para conocer las partes que intervienen y, las fechas de inicio

y finalización.

� Informes, permite generar informes en pantalla y/o impresos, que

posibilitan conocer el estado actual y, realizar un posterior análisis.

� Configuración, permite la gestión de usuarios en el sistema, asignar

permisos a los usuarios y conocer el LOG de los accesos al sistema.


175

10.1.2 Descripción general del sistema

10.1.2.1 Entorno de la aplicación

Para poder ejecutar la aplicación se deberá cumplir con los requisitos

mínimos indicados para desarrollos de Microsoft Visual Studio 6.0.

Estos requisitos mínimos son:

� Ordenador Pentium 90MHz o superior.

� Disco duro con espacio mínimo disponible de 80Mb.

� Una tarjeta de vídeo soportada por Windows.

� 32 MB de memoria.

� Microsoft Windows 95/98/XP/Vista, o Windows NT/2000 o superior.

� Microsoft Internet Explorer versión 4.01 o superior.

La aplicación utiliza objetos y componentes que no son del tipo estándar y

por lo tanto requieren su correspondiente archivo OCX o DLL.

Estos archivos se incluyen con en el instalador de la aplicación para que

pueda funcionar correctamente. El resto de los componentes que utiliza la

aplicación y que son estándar están instalados y registrados en el sistema,

ubicados en la carpeta “System 32” dentro de la carpeta Windows, en

cualquiera de sus versiones del sistema operativo Microsoft Windows.


176

10.1.2.2. Perfiles de usuario

Existen dos grupos de usuarios inicialmente, grupo de usuarios y grupo de

administradores.

Los usuarios pertenecientes al grupo usuarios tienen deshabilitadas

únicamente funciones propias de administración o configuración, estas son:

� Acceso a informes de CHM Service Desk.

� Configuración: Permisos, Listado de usuarios y Log de accesos al

sistema.

� Cambiar el estado de una orden de compra pendiente a aprobada o

rechazada.


177

10.1.3 Funcionalidades

10.1.3.1 Instalación de la aplicación

Para proceder a la instalación de la aplicación se debe ejecutar la aplicación

Instalar.exe, haciendo doble clic en su icono.

Antes de iniciar la instalación, se recomienda cerrar todas las aplicaciones

que se estén ejecutando para llevar a cabo una correcta instalación.

Es necesario esperar a que se copien los archivos necesarios para iniciar el

asistente de instalación.

Una vez iniciado el asistente, se pulsa aceptar para continuar.


178

A continuación se permite cambiar el directorio de destino predeterminado

(C:\Archivos de programa\CHM, por otro. Se pulsa en el icono para

continuar.


179

Ahora se puede cambiar si se desea el nombre por defecto del grupo de

programa de la aplicación.

Una vez pulsado el botón de Continuar, el instalador comenzará a instalar la

aplicación en el directorio que se especificó anteriormente.


180

Una vez realizada la copia de archivos, la instalación habrá finalizado.

La aplicación CHM Service Desk, esta lista para ser ejecutada.


181

10.1.3.2 Ejecución de la aplicación

Para poder ejecutar se debe hacer clic en el icono de la aplicación en la ruta

que se especificó durante el periodo de instalación, generalmente:

Inicio > Programas > CHM Service Desk > CHM Service Desk.


182

10.1.3.3 Desinstalación de la aplicación

Desinstalar la aplicación CHM Service Desk es muy sencillo, se siguen los

siguientes pasos.

Hacer clic en:

Inicio > Configuración > Panel de control > Agregar o quitar programas

Se busca y se selecciona la aplicación: CHM Service Desk.

Se pulsa en el botón Cambiar o quitar.


183

El asistente se auto ejecutará preguntado si se desea quitar la aplicación.

Se pulsa en Sí, y se comienzan a eliminar los componentes instalados en el

equipo de forma automática.

Finalmente un mensaje informará de que se ha eliminado la aplicación.

Se pulsa en el botón “Aceptar” para finalizar.


184

10.1.4 Funciones principales

� Spash inicial.


185

� Logging.

� Introducir su nombre de usuario y contraseña.

� Se recuerda que todos los accesos tanto validos como inválidos son

registrados por el sistema.

� Nota: se debe comprobar si tiene activado o no el Bloqueo de

Mayúsculas al introducir los datos para el acceso.


186

� Inicio (Vista global).

� Desde aquí puede acceder a las diferentes funciones de la aplicación.

� Para actualizar la rejilla y conocer el estado actual de las incidencias:

Abiertas, Cerradas y En curso, se emplea el menú desplegable y el

botón Filtrar.

� El grafico se actualizará automáticamente con cada acción de filtrado.


187

� Incidencias.

� Gestión completa de las incidencias introducidas en el sistema.

� El número de incidencia, la fecha actual, la hora y el técnico se asignan

automáticamente.

� Se recomienda utilizar los menús desplegables.

� Se asigna cada incidencia con el cliente con las comunica.

� Se debe pedir el número de inventario si es necesario al cliente.


188

� Clientes.

Recoge toda la información relativa del cliente que comunica la

incidencia, así como su número de Acuerdo de Nivel de Servicio firmado.

� Soluciones.

Es una base de datos de consulta de soluciones básicas y soluciones de

incidencias resueltas clasificadas por categorías.


técnicos.

� Inventario.

Es necesario conocer el parque informático, las estaciones de trabajo y

los activos hardware y software para la resolución de una incidencia.

Además de la propias gestión del inventario.


189

� Compras.

Facilita la creación y gestión de las ordenes de compras, las cuales

deben ser aprobada o rechazadas por los responsables, para su

posterior incorporación al inventario del cliente.

� Acuerdos de Nivel de Servicios (ANS).

De cada uno de los clientes necesita tener firmados los contratos

denominados Acuerdos de Nivel de Servicio o ANS, que establecen las

condiciones del nivel de soporte.

Este módulo para conocer las partes que intervienen, las fechas de inicio

y finalización y, acceder al documento si esta digitalizado, por ejemplo

en formato .pdf, .doc o .txt.

� Informes.

Es necesario conocer el estado actual del sistema y realizar un posterior

análisis, para la toma de decisiones.

Por ello este módulo le permite generar informes en pantalla y/o

impresos.


190

� Configuración.

Este ultimo módulo permite la gestión de usuarios en el sistema, asignar

los permisos a los usuarios, en función de sus características,

impidiendo en el acceso a secciones reservadas a los administradores u

otros cargos de responsabilidad.

También se puede acceder al LOG de accesos al sistema, el cual

registra la fecha, hora y, estado de todos los accesos o intentos de

acceso realizados al sistema, tanto válidos como inválidos.


191

11. Pruebas


192

Capítulo 11: Pruebas

Este en este capítulo, una vez ya desarrollados y probados cada uno de los

programas y componentes que forman la aplicación CHM Service Desk,

deben realizarse una serie de pruebas para conseguir integrar todo el

sistema, de acuerdo al Plan de Pruebas establecido en la etapa de Diseño

Interno.

Así, el objetivo global de esta fase es someter al sistema desarrollado y a

sus componentes, a una serie de verificaciones encaminadas a garantizar un

nivel de fiabilidad aceptable.

Esta fase es crítica y debe por tanto ser planificada, diseñada y realizada

con el mismo rigor y control con el que se ha realizado el desarrollo del

sistema. Si los resultados de las pruebas son satisfactorios, se procederá a

la aceptación de las mismas y a la implantación del sistema, pero en caso

contrario habrá que subsanar las anomalías encontradas, es decir, volver al

diseño o a la codificación realizada.


193

11.1 Entorno de pruebas

En el plan de pruebas se estableció la necesidad de incorporar un entorno

adecuado donde ejecutar las pruebas del software. Este entorno debía tener

una arquitectura hardware y software similar o idéntica al entorno final de la

aplicación.

El entorno de las pruebas suele adaptarse y configurarse antes de la

realización de cada tipo de prueba.

En cuanto a la información personal a utilizar para realizar las pruebas

deben observarse las leyes vigentes al respecto, para no violar la

confidencialidad de la información de tipo personal.

El equipo de pruebas podrá estar formado por personas ajenas al proyecto,

de modo que se pueda realizar un mejor control de calidad.

El equipo de pruebas utilizará las herramientas necesarias en cada caso,

para realizar cada prueba. Con un monitor se comprobará el volumen de

accesos al acceder a la base de datos y la ocupación en disco de todo el

sistema.


194

11.2 Tipos de pruebas

Durante las etapas de Programación, Pruebas del sistema e Implantación se

realizarán diversas pruebas, cada una con diferentes objetivos y

dependiendo del software fabricado, se les someterán a unas pruebas o a

otras.

En esta etapa se realiza el bloque de pruebas más complejo, para

comprobar la funcionalidad y el rendimiento exigido en los requisitos de esta

aplicación.

Para ello, previamente se habrán realizado las pruebas unitarias de cada

uno de los componentes software y, posteriormente se volverán a realizar

pruebas de carga, pero ahora ya sobre el entorno final de ejecución.

Los diversos tipos de pruebas que suelen realizarse en esta etapa son:

� Pruebas de encadenamiento: verifican las llamadas entre componentes.

� Pruebas de integración: verifican la funcionalidad de todo el sistema

integrado y, el rendimiento de los recursos utilizados.

� Pruebas de explotabilidad: verifican la correcta operación del sistema.

� Pruebas de seguridad: verifican los aspectos de seguridad exigidos en

los requisitos del sistema.


195

� Pruebas de sobrecarga: verifican el correcto comportamiento del sistema

ante los estados de estrés en los que puede verse envuelto.

� Pruebas de recuperación: verifican la capacidad del sistema para

recuperar información o incidencias anómalas.

� Pruebas de regresión: verifican el correcto comportamiento del sistema

ante la modificación de alguno de sus componentes.

� Pruebas de aceptación de usuario: certifican, por parte de los usuarios, la

funcionalidad y rendimiento del sistema, de acuerdo con los requisitos

establecidos.

� Pruebas de usabilidad: certifican, por parte de los usuarios, la

manejabilidad y amigabilidad del sistema.


196

12. Implantación


197

Capítulo 12: Implantación

Este en este capítulo una vez probada la integridad del software del sistema

y especificada su instalación y configuración, se debe transferir el software

producido, para llevar a cabo la explotación del sistema.

Esta transferencia debe prever la migración del software a cada uno de los

equipos de los usuarios finales.

12.1 Pruebas de implantación

De acuerdo con el Plan de implantación y el Manual de instalación se

procede a desplegar el software base y de aplicación a las máquinas de

cada uno de los usuarios finales que van a utilizar esta aplicación.

Una vez instalado el software se realizarán dos pruebas, unas de ellas

tienen como objetivo certificar el correcto funcionamiento de la aplicación, es

decir, que todos los programas se desarrollen con normalidad y que

permitan que la aplicación sea tratada por el usuario.

La otra prueba necesaria es la aceptación final del usuario, que desde su

ordenador certificará el correcto funcionamiento del sistema de acuerdo a los

requisitos necesarios establecidos y al Manual de Usuario.


198

Superadas estas pruebas el sistema ya se podrá ir instalando en cada uno

de los ordenadores de los usuarios finales.


199

Conclusiones

Como capítulo final, tras haberse realizado todo el análisis, el desarrollo, la

programación y documentación del proyecto, se llega a una serie de

conclusiones finales.

Primera, CHM Service Desk es una herramienta de Service Desk basado en

el estándar ITIL adaptado a las necesidades de la PYME.

Segunda, CHM Service Desk proporciona un único punto de contacto entre

los usuarios y clientes, con las tecnologías de la información, incluye todo lo

que se necesita para gestionar los procesos, lo cual redunda en una mayor

productividad y mejor servicio para los usuarios finales.

Tercera, CHM Service Desk es una solución que ofrece en un paquete

integrado, la gestión de incidencias, del conocimiento atreves de las

soluciones, de sus clientes, de la gestión del inventario, las compras y la

gestión de los Acuerdos de Nivel de Servicio (ANS).

Cuarta, el lenguaje de programación Visual Basic es un lenguaje visual y

sencillo, que permite a su vez realizar complejas y potentes aplicaciones.


200

Quinta , este proyecto implica la aplicación teórica y práctica de todos los

conocimientos aprendidos durante la carrera, como ingeniero técnico en

informática de gestión.


201

Bibliografía

[BARR01] Barranco de Areba, J., “Metodología del análisis de sistemas”,

Universidad Pontificia de Comillas, Madrid 2001.

[AMES95] Antonio de Amescua, "Ingeniería del software de gestión:

análisis y diseño de aplicaciones", Paraninfo, 1995

[SOMM05] Sommerville, I., traducción de Alfonso Galipienso, M. I.,

“Ingeniería del software”, Pearson Addison Wesley, Madrid

2005.

[PRES96] Roger Pressman, "Ingeniería del software: un enfoque

práctico", McGraw Hill, 1996.

[SANT98] Martín Santos Pérez, "Normas de Presentación de tesis,

tesinas y proyectos", Universidad Pontificia de Comillas, 1998

[ALCA92] Eduardo Alcalde Lancharro, "Metodología de la programación",

McGraw Hill, 1992.

[CEBA99] Ceballos Sierra, F. J., “Microsoft Visual Basic. Curso de

programación”, Ra-Ma, Madrid 1999.


202

[CHAR99] Charte Ojeda, F., “Visual Basic 6”, Anaya Multimedia, Madrid

1999.

[AITK99] Aitken, P. G., “Visual Basic 6: manual completo de

programación”, Paraninfo, Madrid 1999.

[PERE02] Pérez-Campanero Atanasio, J. A., Morera Pascual, J. M.,

“Conceptos de sistemas operativos”, Universidad Pontificia de

Comillas, Madrid 2002.

[JANV04] Jan van Bon, “Gestión de Servicios TI, una introducción”,

Madrid 2004.

[OGC01] OGC/ The Stationery Office, “Service Delivery”, London 2001.

[OGC01] OGC/ The Stationery Office, “Service Support”, London 2001.

[COLI04] Colin Rudd, “World Class IT Service Management Guide

An Introductory Overview of ITIL”, London 2004.


203

Anexos


204

A.1. Valoración económica

El objetivo de esta valoración es conceder al proyecto de un valor económico

total y realizar una estimación de la implantación del mismo.

La valoración económica del proyecto incluye las horas de trabajo y

desarrollo, el software empleado y las licencias software necesarias.

El coste de las horas empleadas para la realización del proyecto se ha

estimado a partir de los salarios medios de un analista júnior y un

programador júnior.

Puesto Salario Horas Total

Analista júnior 60 €/hora 160 h 9.600 €

Programador júnior 40 €/hora 200 h 8.000 €

Los costes de la licencia software para el desarrollo de la aplicación con

Microsoft Visual Basic 6.0 son:

Nombre Versión Precio

Visual Basic 6.0 2.400 €


205

Los costes de obtención de las diferentes licencias software para la

realización de la documentación son:

Nombre Versión Precio

Microsoft Office 2002 744 €

El paquete ofimático, Microsoft Office 2002 contiene las siguientes

aplicaciones:

� Microsoft Office Word 2002.

� Microsoft Office Excel 2002.

� Microsoft Office Access 2002.

� Microsoft Office PowerPoint 2002.

� Microsoft Office Project 2002.

� Microsoft Office Visio 2002.

� Microsoft Office Outlook 2002.


206

Los costes de un ordenador personal para el desarrollo del proyecto

proveído por “Dell España”, con las siguientes características:

� Sistema operativo: Windows XP Home Edition / Professional Edition.

� Procesador: Intel Pentium IV (3,4 GHz, 2x2 MB de caché de nivel 2 y

bus frontal lateral a 800 MHz).

� Tarjeta gráfica: PCI Express de hasta 256 MB de Nvidia, GeForce

7800GTX.

� Almacenamiento: Hasta 1000 GB.

� Conexión de red: 10/100/1000 Ethernet integrada.

Nombre Precio

Ordenador Personal 700 €


207

A continuación se resumen todos los costes anteriores en la siguiente tabla,

para conocer el coste total del proyecto:

Concepto Precio

Analista júnior 9.600 €

Programador júnior 8.000 €

Visual Basic 6.0 2.400 €

Microsoft Office 2002 744 €

Ordenador Personal 700 €

TOTAL 21.444 €


208

A.2. Glosario

Termino Descripción Proceso .AAF Ver Análisis de Árbol de Fallos. Disponibilidad .CI Ver Artículo de Configuración. Configuración .CIS Ver Artículo de Configuración de Software. Difusión .DHS Ver Almacén Definitivo de Hardware. Difusión .AIFC Análisis de Impacto de Fallos de

Componentes. Disponibilidad

.OLA Ver Acuerdo de Nivel Operacional. SLM

.SLA Ver Acuerdo de Nivel de Servicio. SLM

.CDB Ver Base de Datos de Capacidad. Capacidad

.DSL Ver Biblioteca Definitiva de Software. Difusión

.CMDB Ver Base de Datos de Gestión de Configuración.

Configuración

.ITIL La Biblioteca de Infraestructura de TI de CCTA – un conjunto de directrices de la gestión y provisión de servicios de TI operacionales.

Todos

.CCU Ver Centro de Costes de Unidades. Financiera

.CS Ver Contrato Subyacente o contrato. Disponibilidad

.FGSIT Foro de Gestión de Servicios TI, Grupo de Usuarios de ITIL.

Todos

.GAC Ves Gestión de Relación de Negocio. CRM

.GCN / BCM Gestión de Continuidad de Negocio. Continuidad

.GNS / SLM Ver Gestión de Nivel de Servicio. SLM

.IPWTM Implementación de un proceso Workflow Orientado, un modelo de proceso Creado por Quint Wellington Redwood y Dutch Telecom (KPN) Stadia Model que describe vencimientos, cómo medirlos y cómo realizarlos, para los distintos procesos de BITI. Ver www.quintgroup.com para un artículo completo en inglés.

Todos

.ISEB Información System Examination Borrad (UK), que administra y concede los premios de cualificaciones de TI incluidos FC en Gestión de Servicio TI.

Todos

.CAB Ver Junta de Asesoramiento de Cambios. Cambios

.CAB / EC Ver Junta de Asesoramiento de Cambios Comité de Emergencia.

Cambios

.CRAMM Método de Gestión y Análisis de Riesgo CCTA.

Todos


209

.FSC Programación Adelantada de Cambios. Cambios

.SLR Ver Requisitos de Nivel de Servicio. SLM

.PIR Ver Revisión Post Implementación. Problemas

.RFC Ver Solicitud de Cambio. Cambios

.SPOF Ver Sólo Punto de Fallo. Disponibilidad

.TIC

La convergencia de Tecnología de Información, Telecomunicaciones y Tecnologías de Data Networking en una sola tecnología.

Todos

.MTTR Ver Tiempo Medio de Reparación. Disponibilidad

.MTBF Ver Tiempo Medio Entre Fallos. Disponibilidad

.MTBSI Ver Tiempo Medio Entre Incidencias de Sistema.

Disponibilidad

Actividad de BCM

Una acción o serie de acciones como parte del proceso de BCM.

Continuidad

Acuerdo de Nivel Operacional

Un acuerdo interno cubriendo la entrega de servicios, que soporta la suministración de TI en la entrega de sus servicios.

SLM

Acuerdo de nivel de servicio

Acuerdo escrito entre un proveedor de servicios y el cliente que documentan los niveles de servicio cordados para un servicio.

SLM

Acuerdo Recíproco

2 organizaciones que utilizan infraestructura compatible se proporcionan una a la otra recusrsos de TI en una emergencia.

Continuidad

Acuerdos de Standby

Las gestiones necesarias para que haya bienes disponibles, que se han identificado, como repuestos de no estar disponibles los bienes primarios tras un trastorno de negocio. Típicamente, estos incluyen alojamiento, sistemas de TI y redes, telecomunicaciones y a veces personas.

Continuidad

Administración de TI

La parte de la organización encargada de desarrollar y entregar los servicios TI .

Todos

Almacén Definitivo de Hardware ADH

El área para el almacenaje seguro de repuestos definitivos de hardware. Estos son componentes de repuesto y montajes que se mantienen al mismo nivel que los sistemas comparativos del entorno vivo.

Difusión

Amenaza Un evento que podría ocurrir y que podría degradar el funcionamiento de un componente o servicio.

Disponibilidad


210

Amenaza Un evento que podría ocurrir y que podría degradar el funcionamiento de un componente o servicio.

Continuidad

Análisis de Árbol de Fallos

Técnica para analizar la disponibilidad de un sistema.

Disponibilidad

Análisis de Impacto

La identificación de procesos de negocio críticos y, el daño o pérdida potencial que puede causar a una organización un trastorno de esos procesos. Al Análisis de impacto de negocio identifica la forma en que tomará la pérdida o daño, cómo es probable que escale ese grado de pérdida o daño con el tiempo tras una incidencia; la plantilla, facilidades y servicios mínimos necesarios para permitir a los procesos de negocio continuar operando a un nivel mínimo aceptable; y el tiempo dentro del cual deberían ser recuperados. El tiempo dentro del cual se debe alcanzar la plena recuperación de los procesos de negocio también se identifica.

Cambios

Análisis de Riesgo

La identificación y valoración de bienes y amenazas; la evaluación de vulnerabilidades y riesgos considerando las amenazas a los bienes.

Disponibilidad

Análisis de Riesgo

La identificación y valoración de bienes y amenazas; la evaluación de vulnerabilidades y riesgos considerando las amenazas a los bienes.

Continuidad

Análisis de Varianza

Una varianza es la diferencia entre coste, programado, presupuestado o estándar y coste actual (o ingresos). Análisis de varianza es un análisis de los factores que han causado la diferencia entre los estándares predeterminados y los resultados reales. Varianzas pueden ser desarrolladas específicamente relacionadas a las operaciones realizadas en añadidura a las arriba mencionadas.

Financiera

Año Financiero El año financiero es el periodo contable que cubre 12 meses consecutivos. En el sector público este año financiero generalmente coincidirá con el año fiscal, que va desde el 1 Abril hasta el 31 Marzo.

Financiera


211

Artículo de Configuración (CI)

Componente de una infraestructura – o un artículo, tal como una Solicitud de Cambio, asociado con una infraestructura – que es (o estará) bajo el control de Gestión de Configuración. CI’s pueden variar mucho en complejidad, tamaño y tipo- desde un sistema entero (incluido todo el hardware, software y documentación) a un módulo suelto o un componente de hardware menor.

Configuración

Artículo de Configuración de Software (SCI)

Como “Artículo de Configuración” excluyendo hardware y servicios.

Difusión

Asíncrono / Síncrono

Asíncrono en el sentido de comunicaciones es la habilidad de transmitir cada carácter como una unidad auto contenida de información, sin información adicional en el tiempo. Este método de transmisión a veces se llama Start / Stop. Trabajar de forma síncrona conlleva el uso de la información se hace en bloques. La transmisión síncrona es normalmente más eficiente que el método asíncrono.

Tecnología

Atributo Característica de un CI sostenida en la CMDB.

Configuración

Auditoria Una prueba para asegurar que una función o proceso funciona de acuerdo a las prescripciones.

Todos

Auto asegurar Una decisión de soportar las pérdidas que podrían resultar de un trastorno al negocio opuesto a asegurar el riesgo de forma extra

Continuidad

Autoridad de Cambio

Un grupo al que se le da la autoridad para aprobar Cambio, por ejemplo por la junta de proyectos. A veces se refiere a ello, como la Junta de Configuración.

Cambios

Base de Datos de Capacidad CDB

Una base de Datos que contendrá toda la información necesitada por todos los sub procesos dentro de la Gestión de capacidad.

Capacidad

Base de Datos de Gestión de Configuración (CMDB)

Una base de datos, que contiene todos los detalles relevantes de cada CI y detalles de las relaciones importantes entre CI.

Configuración


212

Biblioteca Definitiva de Software SDL

La biblioteca en la que las versiones autorizadas definitivas de todos los CI de software se almacenan y protegen. Es una biblioteca física o repositorio donde se sitúan copias maestras de versiones de software. Esta área lógica puede en realidad consistir de uno o más bibliotecas de software físicas o almacenes de archivos. Deberían estar separados de las áreas de desarrollo y almacén de archivos de pruebas. Las BDS también pueden incluir un almacén físico para guardar copias maestras de software incorporado de fuera P. ej. a prueba de fuego. Sólo software autorizado debería ser aceptado en la SDL, controlado de forma estricta por Gestión de Cambio y Difusión. La SDL existe no directamente por las necesidades del proceso de Gestión de Configuración, pero como base común para los procesos de Gestión de Difusión y Gestión de Configuración.

Difusión

Biblioteca de Software

Una colección controlada de SCI diseñados para mantener los de tipo y estatus similar juntos y segregados de los distintos, para ayudar en el desarrollo, operación y mantenimiento.

Difusión

Bien Asset. Componente de un proceso de negocio. Bienes pueden incluir personas, alojamiento, sistemas informáticos, redes, historiales en panel, máquinas de fax, etc.

Configuración

Cambio La añadidura, modificación o eliminación de hardware de línea base o soportado, network, software, aplicación, entorno, sistema, construcción de desktop o documentación asociada.

Cambios

Cambio Urgente

Un cambio que debido a la importancia crítica para el negocio de una Incidencia se ha de implementar con urgencia.

Cambios

Canal Canal es la conexión física de la CPU a un mecanismo de I/O, normalmente un controlador, o de hecho otro CPU.

Cambios


213

Capitalización Muchas organizaciones eligen identificar sus gastos mayores como Capital, haya un bien sustancial o no, para reducir el impacto en el año financiero actual de tal gasto y a esto se refiere como Capitalización. El artículo más común para aplicar a esto es software, sea desarrollado de forma interna o adquirido.

Financiera

Carga de Trabajo

Las Cargas de Trabajo dentro del contexto de Modeling de Gestión de Capacidad son un conjunto de predicciones que detallan el uso de recursos estimados a lo largo de los horizontes de planning acordados. Las cargas de trabajo generalmente representan aplicaciones de negocio discretas y se pueden subdividir más allá en tipos de trabajo (interactivo, de tiempo compartido, lote).

Capacidad

Cargo diferencial

Cobrar a clientes de negocio distintas tarifas por el mismo trabajo, típicamente para bajar la demanda o para generar rentas para capacidad obrante. Esto también se puede utilizar para incitar a funcionamiento off peca o de noche.

Financiera

Cargo Duro Descriptivo de una situación donde, dentro de una organización, los fondos actuales son transferidos del cliente a la organización de TI como pago de la entrega de servicios de TI.

Financiera

Catálogo de Servicio

Extractos escritos de servicios de TI, niveles de defecto y opciones.

SLM

Categoría Clasificación de un grupo de Artículos de Configuración, Documentos de Cambio o problemas.

Configuración


Cambios


Incidencias


Problemas


214

Centro de Beneficio

TI se gestiona como un negocio con objetivos de beneficio.

Financiera

Centro de Coste

TI tiene un presupuesto y hay cobro suave de servicios específicos; trata de un coste de inputs y outputs.

Financiera

Centro de Coste de Utilidad (CCU)

Un centro de coste para la provisión de servicios de soporte a otros centros de coste.

Financiera

Ciclo Vital Una serie de estados, conectados por transiciones permitidas. El ciclo vital representa un proceso de aprobación de Artículos de Configuración, Informes de Incidencias, Informes de Problemas y documentos de Cambio.

Configuración


Cambios


Incidencias


Problemas

Ciclo Vital de BCN

El conjunto completo de actividades y procesos necesarios para gestionar la continuidad de negocio-individuo en cuatro etapas.

Continuidad

Ciclo Vital de Una Incidencia

Todas las Actividades desde el momento que ocurre una incidencia hasta el momento en el que se cierra la incidencia.

Incidencias

Cierre Cuando el Cliente está satisfecho de que una incidencia se ha resuelto.

Incidencias


215

Clasificación Proceso de agrupar formalmente Artículos de Configuración por tipo, por ejemplo software, hardware, documentación, entorno, aplicación.

Configuración

Clasificación Proceso de formalmente identificar incidencias, problemas y errores conocidos por origen, síntomas y causa

Cambios

Clasificación Proceso de formalmente identificar incidencias, problemas y errores conocidos por origen, síntomas y causa.

Incidencias

Clasificación Proceso de formalmente identificar incidencias, problemas y errores conocidos por origen, síntomas y causa.

Problemas

Cliente Recipiente del servicio; normalmente la Gestión del Cliente tiene la responsabilidad del coste del servicio, o directamente a través de cobros o indirectamente en términos de la necesidad de negocio demostrable.

Todos

Cliente Inteligente

El comprador (como distinto al proveedor) de servicios. El término a menudo se usa con relación a la externalización (outsourcing) de las TI.

SLM

Cobros El proceso de establecer cobros con respecto de unidades de negocio y, creando las estructuras relevantes para recuperación de los clientes.

Financiera

Computer Arded Systems Engineering

Una herramienta de programación de software. Proporciona ayuda en el planning, análisis, diseño y documentación de software de ordenador.

Todos

Conciencia de Seguridad

La medida en que una organización es consciente de su situación de seguridad.

Seguridad

Construcción La etapa final de producir una configuración utilizable. El proceso conlleva coger uno o más artículos de Configuración de input y procesarlos (construirlos) para crear uno o más artículos de Configuración por ejemplo compilar y cargar software.

Configuración

Contabilidad de Estatus

Proceso que graba el estado de un AC en cualquier momento dado.

Configuración


216

Contabilidad de TI

El conjunto de procesos que permiten a la organización de TI contabilidad completamente la manera en la que se gasta su dinero (en particular la habilidad de identificar costes por cliente, servicio, actividad) Normalmente, conlleva el uso de registros y debería ser supervisado por alguien formado en Contabilidad.

Financiera

Contrato Documento entre dos entidades (dos proveedores externos) con existencia legal separada.

Disponibilidad

Contrato Documento entre dos entidades (dos proveedores externos) con existencia legal separada.

SLM

Contrato Subyacente

Un contrato con un proveedor externo cubriendo la entrega de servicios que soporta la administración de TI en la entrega de sus servicios.

Disponibilidad

Control de Cambio

El procedimiento para asegurar que todos los Cambios son controlados, incluidos la sumisión, análisis, toma de decisiones, aprobación, implementación y post implementación del Cambio.

Cambios

Control de Errores

Control de errores cubre los procesos involucrados en progresando Errores Conocidos hasta que se eliminan con la implementación exitosa de un Cambio bajo el control del proceso de Gestión de Cambios. El objetivo de control de errores es ser consciente de los errores, monitorizarlos y eliminarlos cuando sea plausible y el coste justificable.

Problemas

Control de Configuraciones

Actividades que comprenden el control de Cambios a Artículos de Configuración tras establecer formalmente sus documentos de configuración. Incluye la evaluación, coordinación, aprobación o rechazo de Cambios. La implementación de Cambios incluye Cambios, desviaciones y renuncias que impactan en la configuración.

Configuración


217

Control de Problemas

El proceso de control de Problemas trata del manejo de Problemas de manera efectiva y eficiente. El objetivo de control de problemas es identificar la causa de raíz, como los CI’s responsables y, proporcionar al Service Desk de información y asesoramiento de los Workarounds cuando se puede.

Problemas

Control de Procesos

El proceso de planear y regular, con el objetivo de realizar el proceso de manera efectiva y eficiente.

Todos

Controlador de Caché de Disco

Los controladores de Caché de Disco tienen memoria, que se utiliza para almacenar bloques de datos, que se han leído de los mecanismos de disco conectados a ellos. Si un I/O (E/S) consecutiva requiere el expediente que está todavía residente en la memoria de caché, se recogerá de ahí, evitando así otro I/O (E/S) físico.

Tecnología

Coste La cantidad de gastos (actuales o de noción) incurridos en, o atribuibles a una actividad específica o unidad de negocio.

Financiera

Coste Aporcionado

Un coste que comparten un número de unidades de negocio (un coste indirecto). Este coste se debe repartir entre estas unidades de forma equiparable

Financiera

Coste Asignado Un coste que se puede identificar directamente con una unidad de negocio.

Financiera

Costes Capitales

Típicamente aquellos aplicables a los bienes físicos (sustanciales) de la organización. Tradicionalmente, esto era el alojamiento y maquinaria necesaria para producir el producto de la empresa. Costes capitales son la adquisición o mejora importante de bienes fijos, por ejemplo, equipamiento informático (construcción y planta y a menudo también referidos como costes de una sola vez).

Financiera

Coste Directo Un coste, que se incurre y, que se puede localizar de lleno a un producto, servicio, centro de coste o departamento. Esto es un coste asignado. Costes Directos son materiales directos, sueldos directos y gastos directos.

Financiera


218

Coste Entero Coste Entero es el coste total de todos los recursos utilizados al suministrar un servicio es decir, la suma de los costes directos de producir el output, una parte proporcional de los costes generales y cualquier gasto de venta y distribución. Tanto costes de efectivo y de noción (no efectivo) deberían ser incluidos, incluyendo el coste de capital. Calculado como el coste total de propiedad, incluida la depreciación / renovación prevista).

Financiera

Coste Estándar Un cálculo predeterminado de cuántos costes deberían estar bajo las condiciones de trabajo especificadas. Se calcula de la evaluación del valor de elementos de coste y correlaciona las especificaciones técnicas y la cuantificación de materiales, mano de obra y otros costes a los precios y/o salarios que se esperan aplicar durante el periodo en el que se tiene intención de usar el coste estándar. Sus propósitos principales son proporcionar bases de control mediante contabilidad de varianza, para la valoración de trabajo en progreso y para fijar precios de venta.

Financiera

Coste Indirecto Un coste indirecto es un coste incurrido al hacer un producto proporcionando un servicio o llevando un centro de costes o departamento, pero que no se puede rastrear directamente o totalmente al producto, servicio o departamento, porque ha sido incurrido para un número de centros de coste o unidades de coste. Estos costes son aprocionados a las unidades de coste coste / coste. También se refieren a los costes indirectos como Overheads o Gastos Generales.

Financiera

Coste de Ingresos

También llamado coste continuada, el valor disminuye con el uso, tal como papel o salarios. Normalmente es un coste variable.

Financiera

Coste Marginal El coste variable de producir una unidad extra de producto o servicio. Esto es, el coste que se habría evitado si la unidad / servicio no se hubiera producido / proporcionado.

Financiera


219

Costes Operacionales

Aquellos resultantes de día a día de la sección de Servicios de TI, por ejemplo los costes de Personal, mantenimiento de hardware y electricidad y, relacionado a pagos repetidos cuyos efectos se pueden medir dentro de un marco de tiempo corto, normalmente menos que el año financiero de 12 meses.

Financiera

Coste de Oportunidad (o coste verdadero)

El valor de un beneficio sacrificado a favor de un curso de acción alternativo. Ese es el coste de utilizar recursos en una operación particular expresado en términos de sobreponer al beneficio que se podría derivar al mejor uso alternativo de esos recursos.

Financiera

Coste Primo El coste total de los materiales directos, mano de obra directa y gastos directos. El término coste primo se restringe comúnmente a costes de producción directa así que no incluye costes directos de marketing o investigación y desarrollo.

Financiera

Coste de Recurso

Este término se utiliza para describir la cantidad de recursos de máquina que consumirá una tarea dada. Este recurso normalmente se expresa en segundos para la CPU o el número de I/Os para un mecanismo de disco o cinta.

Financiera

Coste de Unidad

Costes de unidad son costes distribuidos para el uso de componentes individuales para establecer el coste d unidad. Por ejemplo, se pueden entender, que si la caja de papel de 1000 vale £10, entonces obviamente una hoja cuesta 1 penique. De forma similar, si una CPU cuesta £1 mill por año y se usa para procesar 1,000 trabajos en ese año, cada trabajo cuesta £1,000.

Financiera


220

Coste de Unidad de Recurso

La unidad de recurso puede ser calculada en una base de coste estándar para identificar el coste esperado (estándar) para usar un recurso en particular. Como recursos informáticos vienen en muchas formas, las unidades se tienen que establecer por agrupaciones lógicas. Ejemplos son: a) tiempo de CPU o instrucciones, b) I/Os de disco, c) líneas impresas, d) transacciones de comunicación.

Financiera

Costing El proceso de identificar los costes de negocio y de desglosarlos y relacionarlos con las varias actividades del negocio.

Financiera

Costing the Absorción

Un principio mediante el cual costes tanto fijos como variables se asignan a unidades de coste y gastos totales son absorbidos de acuerdo con el nivel de actividad. El término se puede aplicar donde se asignan costes de producción o costes de todas las funciones.

Financiera

Costing Estándar

Una técnica que utiliza estándares de costes e ingresos para los propósitos de control mediante análisis de varianza.

Financiera

Costing de Plena Absorción

Un principio donde los costes fijos y variables son asignados a unidades de coste y los costes generales son absorbidos de acuerdo a los niveles de actividad.

Financiera

Datos de Referencia

Información que soporta los planes y listas de acción, tales como nombres y direcciones o inventarios, que llevan índices dentro del plan.

Todos

Dependencia La dependencia, o directa o indirecta, de un proceso o actividad de otro.

Todos


221

Depreciación La depreciación es la pérdida de valor de un bien debido a su uso y/o el paso de tiempo. El cargo de depreciación anual en cuentas representa la cantidad de bienes capitales en el periodo contable. Se carga en las cuentas de costes para asegurar que el coste del equipamiento capital se refleje en los costes de unidad de los servicios proporcionados utilizando el equipo. Hay varios métodos de calcular la depreciación para el periodo, pero la Tesorería normalmente recomienda el uso de validación de coste de bienes actual como base para el cargo de depreciación.

Financiera

Service Desk El único punto de contacto dentro de la administración de TI para usuarios de servicios de TI.

Service Desk

Difusión Una colección de CI nuevos y/o cambiados, que se prueban e introducen al entrono vivo juntos.

Difusión

Difusión Completa

Todos los componentes de la unidad de Difusión son construidos, probados, distribuidos e implementados juntos – Ver también “Difusión Delta”.

Difusión

Difusión Delta Una Difusión Delta, o parcial, es la que incluye sólo esos CI dentro de la unidad de Difusión que han cambiado de hecho o son nuevas desde la última Difusión Delta o completa. Por ejemplo, si la unidad de Difusión es el programa, una Difusión Delta contiene sólo esos módulos que han cambiado, o son nuevos desde la última difusión completa del programa o la última difusión Delta de los módulos-ver también “Difusión Completa”.

Difusión

Difusión de Emergencia

Una difusión implementada urgentemente. Mayoritariamente, por una incidencia pendiente.

Difusión

Difusión de Paquete

Un número de unidades de difusión empaquetadas junas.

Difusión

Discounting Discounting es ofrecer a los clientes tasas reducidas para el uso de recursos off peca (fuera de horas punta) (ver también Sobretasar).

Financiera


222

Disponibilidad Habilidad de un componente o servicio para realizar su función requerida en un instante dado a lo largo de un período dado de tiempo. Normalmente se expresa como el ratio de disponibilidad, es decir la proporción de tiempo que el servicio está disponible realmente para uso de los Clientes dentro de las horas de servicio acomodadas.

Disponibilidad

Dispositivos de Estado Sólido

Los Discos de estado sólido son mecanismos de memoria a los que se les hace aparecer como mecanismos de disco. Las ventajas de tales mecanismos son que los tiempos de servicio son mucho más rápidos que los discos reales ya que no hay tiempo de búsqueda o latencia. La desventaja principal es que son mucho más caros.

Tecnología

Documentación de Configuración

Documentos que definen requisitos, diseño de sistema, construcción, producción y verificación de un artículo de configuración.

Configuración

Documento de Cambio

Solicitud de Cambio, formulario de control de Cambio, orden de Cambio, expediente de Cambio.

Cambios

Downtime El tiempo en el que un servicio acordado no está disponible.

Disponibilidad

Downtime El tiempo en el que un servicio acordado no está disponible.

Incidencias

Dúplex (completo y medio)

Un canal/línea duplex completa permite la transmisión simultánea en ambas direcciones. Canal/línea duplex media es capaz de transmitir en ambas direcciones, pero sólo en una dirección a la vez.

Tecnología

Echoing (EI) Echoing (eco) es un reflejo de la señal transmitida de la parte receptora, un método visual de detección de error en la que la señal del mecanismo originario se enlaza de nuevo a ese mecanismo para que se pueda mostrar.

Tecnología

Efectividad de coste

Asegurar que hay un equilibrio adecuado entre la calidad de servicio por un aparte y el precio por otra. Cualquier inversión que aumenta los costes de proporcionar servicios de TI siempre debería resultar en la mejora de calidad o cantidad de servicio.

Todos


223

Elementos de Coste

Las partes constituyentes de costes de acuerdo a los factores sobre los que se incurren con materiales, mano de obra y gastos.

Financiera

Emulación de Terminal

Una emulación de terminal se alcanza al ejecutar software en un mecanismo inteligente, típicamente un PC o puesto de trabajo, que permite a ese mecanismo funcionar como terminal interactiva conectada al sistema host. Ejemplos de tal software de emulación incluyen IBM 3270BSC o SNA, ICL C03 o Digital VT100.

Tecnología

Enfoque de Fortaleza

Local de TI tan a pruebas de desastre como sea posible.

Continuidad

Entorno Una colección de hardware, software, comunicaciones de red y procedimientos que trabajan juntos para proporcionar un tipo discreto de servicio informático. Puede haber uno o más entornos en una plataforma física. Un entorno tiene rasgos únicos y características que dictan cómo se administran en maneras similares pero distintas.

Difusión

Entorno Live Building

(Parte del) sistema informático utilizado para construir difusiones de software para uso en vivo

Difusión

Entorno de Software

Software utilizado para soportar la aplicación tal como el sistema operativo, sistema de gestión de base de datos, herramientas de desarrollo, compliadores y, software de aplicaciones.

Difusión

Entorno de Test Build

(Parte de) sistema informático utilizado para construir difusiones de software para testing de aceptación operacional.

Difusión

Entorno de Test (Parte de) sistema informático utilizado para construir difusiones de software para testing de aceptación operacional.

Difusión

Entorno Vivo (Parte del) sistema informático utilizada para usar software en uso vivo.

Difusión

Equipo de Recuperación de Negocio

Un grupo definido de Personal con un rol definido y un rango suborinado de acciones para facilitar la recuperación de una función o proceso de negocio.

Continuidad


224

Error Conocido Una Incidencia o Problema del cual no se conoce la causa de raíz y para el cual se ha identificado un Workaround temporal o una alternativa permanente. Si existe un caso de negocio, un RFC se hará, pero, en cualquier caso permanece como Error Conocido hasta que se arregle permanentemente con un Cambio.

Problemas

Escala Funcional

Escala o Referencia a más u otros conocimientos.

Incidencias

Escalada Jerárquica

Escalada a un nivel más alto en la jerarquía.

Incidencias

Escenario de Impacto

Descripción del tipo de impacto en el negocio que podría seguir un trastorno de negocio. Normalmente, estará relacionado con el proceso de negocio y siempre se referirá a un periodo de tiempo, p.ej. atención al cliente no podrá operar durante dos días.

Incidencias

Estructura de Árbol

En estructuras de datos, una serie de nodos conectados sin ciclos. Un nodo se denomina la raíz y es el punto de partida de todas las rutas, otros nodos denominados hojas terminan las rutas.

Tecnología

Estructura de Configuración

Una jerarquía de todos los Cl que constituyen una configuración.

Configuración

Evaluación de Inversión Capital

El proceso de evaluar la inversión propuesta en bienes fijos específicos y los beneficios que se pueden obtener de su adquisición. Las técnicas utilizadas en la evaluación se pueden resumir como métodos de no descuento (es decir, simplemente, reembolso), beneficio en capital empleado y métodos de flujo de efectivo de descuento (es decir, beneficio, valor presente neto y reembolso descontado).

Financiera

Expediente de Cambio

Un expediente conteniendo detalles de qué AC se ven afectados por un cambio autorizado (programado o implemententado) y cómo.

Cambios


225

Fallo de Hard (hard fault)

Fallos de hard (hard faults) describen la situación en un sistema de memoria virtual cuando la página requerida de códigos o datos, que está utilizando un programa, he sido redistribuida por el sistema operativo para otro propósito. Esto significa que otra parte de la memoria se debe encontrar para alojar el código o datos y, conllevará la lectura/escritura física de páginas al archivo de páginas.

Tecnología

Fallo de Página Una interrupción de programa que ocurre cuando una página activa se refiere a una página que está marcada “no en memoria real”.

Tecnología

Fallo de Soft (Soft Fault)

Un fallo de soft describe la situación en un sistema de memoria virtual cuando el sistema operativo ha detectado que una página de código o datos se tenía que reutilizar, es decir está en una lista de páginas “libres” pero en realidad está todavía en la memoria. Se rescata y devuelve al servicio.

Tecnología

Fase de Alerta La primera fase del plan de continuidad de negocio en el que se activan los procedimientos de emergencia y evaluaciones de daños.

Continuidad

Fase de Invocación y Recuperación

La segunda fase del plan de continuidad de negocio en el que se activan los procedimientos de emergencia y evaluaciones de daños.

Continuidad

Fiabilidad Habilidad de un componente de entregar una funcionalidad deseada durante un periodo de tiempo dado y bajo ciertas condiciones.

Disponibilidad

Flujo de Efectivo Descontado

Una evaluación de los flujos de efectivo netos futuros generados por un proyecto capital al descontarlos a su valor de hoy día. Los dos métodos más comúnmente utilizados son: a) método de rédito, por el que el cálculo determina la Tasa Interna de rendimiento TIR en forma de porcentaje b) método de valor presente neto (VPN), en el que la tasa de descuento se elige y la respuesta es una cantidad de dinero.

Financiera


226

Función de Negocio

Una unidad de negocio dentro de una organización, por ejemplo un departamento , una división, una sucursal.

Todos

Garantía Los procesos mediante los cuales una organización puede verificar la exactitud e integridad de su Gestión de Capacidad de Negocio.

Continuidad

Gasto Absorbido

Gasto general que, por medio de las tasas de absorción, se incluye en los costes de productos específicos o servicios vendibles, en un periodo de tiempo dado. Gasto infla o sobre absorbido. La diferencia entre coste general incurrido y coste general absorbido: se puede dividir en sus dos partes constituyentes a propósito de controles

Financiera

Gateway Un gateway es equipamiento, que se utiliza para hacer nexo entre (interface) redes para que una terminal en una red pueda comunicar con servicios o una terminal de otra.

Tecnología

Gestión de Atención al Cliente TI

Ver Gestión de Relación de Negocio. CRM

Gestión de Bienes

La Gestión de Bienes. Configuración

Gestión de Cambios

Proceso de controlar Cambios a una infraestructura o a cualquier aspecto de los servicios, de manera controlada, permitiendo cambios aprobados con un trastorno mínimo.

Cambios

Linea de Base Instantánea del estado de un CI (CMDB) y CI relacionados en un punto en el tiempo.

Configuración

Listas de acción Acciones definidas, asignadas a equipos de recuperación e individuales, dentro de las fases de un plan. Estos son soportados por datos de referencia.

Todos

Llamada Un contacto con el Service Desk. Service Desk Logro de Servicio

Los niveles de servicio que realmente entregan la administración de TI al cliente con una duración de vida limitada.

SLM

Mando, Control y comunicaciones

Los procesos mediante los cuales una organización retiene coordinación general de su esfuerzo de recuperación durante la invocación de planes de recuperación de negocio.

Continuidad


227

Marco de Plan de Recuperación de Negocio

Una plantilla de plan de recuperación de negocio ( o conjunto de planes) producidos para permitir que la estructura y contenido propuesto sean acordados antes de producirse el plan de recuperación de negocio.

Continuidad

Medida de Reducción de Riesgo

Medidas tomadas para reducir la probabilidad de que ocurra un trastorno de negocio (como opuesto a planear la recuperación después de un trastorno).

Disponibilidad

Medida de Reducción de Riesgo

Medidas tomadas para reducir la probabilidad de que ocurra un trastorno de negocio (como opuesto a planear la recuperación después de un trastorno).

Continuidad

Modeling Una actividad para predecir el comportamiento de sistemas informáticos bajo un volumen y variedad de trabajo dados.

Capacidad

Modeling Simulado

Modeling Simulado como implica el nombre, emplea un programa, que simula el procesamiento de ordenador al describir en detalles la ruta de un trabajo o transacción. Puede dar resultados extremadamente precisos. Desgraciadamente, exige una gran cantidad de tiempo y esfuerzo del modeling. Es más beneficioso en sistemas extremadamente grandes o críticas de tiempo donde el margen de error es muy pequeño.

Capacidad

Monitorización El registro y guardar de la utilización de cada recurso y servicio en una base continuada para asegurar el uso óptimo de los recursos de hardware y software, que se puedan alcanzar los niveles acordados de servicio y que los volúmenes de negocio son los esperados.

Capacidad

Multiplexor Los multiplexor dividen canales de datos en dos o más canales de datos fijos de velocidad más baja.

Tecnología

Nivel de CI El nivel de detalle de un CI. Configuración Nivel de madurez/ Hito

Ver IPWTM. El grado hasta el cual las actividades y procesos de BCM se han convertido en práctica habitual dentro de una organización.

Todos


228

Nivel de Seguridad

El nivel en el que se ha asegurado una organización.

Seguridad

Numeración de Difusión

La política que determina cómo se deben numerar difusiones. El número de una difusión.

Difusión

Objetivo Externo

Una de las medidas contra las cuales se compara un servicio de TI entregado, expresado en términos de negocio del cliente.

Financiera

Objetivo Interno Una de las medidas contra la que procesos de soporte para el servicio de TI se comparan, normalmente expresada en términos técnicos relacionados directamente con el servicio subyacente que se mide.

SLM

Objetivo de Recuperación de negocio

El tiempo deseado dentro del cual los procesos de negocio se deben recuperar y el Personal, bienes y servicios mínimos requeridos durante este tiempo.

Continuidad

Ocupación de Almacén

Ocupación de Almacén es una unidad de medida definida que se usa para equipo de tipo almacén para medir su uso. El valor de la unidad equivale al número de bytes guardados.

Capacidad

Outsourcing El proceso por el cual las funciones realizadas por la organización son subcontratadas para la operación por parte de la organización a terceros.

SLM

Overheads (Gatos generales)

El total de materiales, sueldos y gastos indirectos.

Financiera

Package Assembly /Disassembly Device

Un mecanismo de paquete de montaje / desmontaje que permite terminales que no tienen un interface adecuado para la conexión directa de una red de paquetes conmutados para acceder a tal red. Un PAD convierte datos a/de paquetes y maneja configuración de llamadas y direccionamiento.

Tecnología


229

Paginamiento (swapping)

La reacción del sistema operativo a memoria real insuficiente: los paginamientos ocurren cuando se percibe que demasiadas tareas compiten por recursos limitados. Es el movimiento físico de una tarea completa (p.ej. todas las páginas de memoria real de un espacio de dirección se pueden mover de una vez del almacén principal al almacén auxiliar).

Tecnología

Paging (Paginado)

Paging (paginado) es el I/O (E/S) necesario para leer de y escribir a los dispositivos de paging: se necesita memoria real (no virtual) para procesar datos. Con memoria real insuficiente, el sistema operativo escribe páginas viejas al disco y lee nuevas páginas del disco para que los datos e instrucciones requeridas estén en la memoria real.

Tecnología

PD0005 Título alternativo para la publicación BSI “El Código de Práctica para Gestión de servicio de TI”.

Todos

Perfil de Recurso

El Perfil de Recurso describe los costes totales de recursos, que se consumen por una transacción online individual, lote o programa. Normalmente, se expresa en términos de segundos CPU, número de I/Os y utilización de memoria.

Capacidad

Phantom Line Error

Un error de linea fantasma es un error de comunicación informado por un sistema informático, que no se detecta con equipo de monitorización en red. A menudo es causado por cambios a circuitos y equipo en red (p.ej. circuitos de redireccionamiento a escala física en una red de columna) mientras la comunicación de datos está en progreso.

Tecnología

Plan de Calidad de servicio

El plan escrito y especificación de objetivos internos diseñados para garantizar los niveles de servicio acordados.

SLM

Plan de Contingencia

Plan detallando las acciones y procedimientos a seguir en caso de un desastre importante.

Continuidad


230

Plan de Gestión de Configuración

Documento marcando la organización y procedimientos para la Gestión de Configuración de un producto específico, proyecto, sistema, grupo de soporte o servicio.

Configuración

Planes de Recuperación de Negocio

Documentos describiendo los roles, las responsabilidades y acciones necesarias para resumir los procesos de negocio tras un trastorno de negocio.

Continuidad

Planning de Capacidad

Proceso para proporcionar planes e informes para cubrir cargas de negocio actuales y futuras.

Capacidad

Planning de Contingencia

Planning para afrontar ocurrencias no deseadas que pueden ocurrir más tarde. Tradicionalmente, el término se ha utilizado para referirse a planning de la recuperación de sistemas de TI más que procesos enteros de negocio.

Continuidad

Planning de Recuperación de Desastre

Una serie de procesos que se centran sólo en procesos de recuperación, principalmente en respuesta a desastres físicos que se contienen dentro de BCM.

Continuidad

Política de Difusión

La política que determina cómo se deben tratar las difusiones. Engloba tamaño, numeración y frecuencia.

Difusión

Poner Precio (Pricing)

La política que determina cómo se valoran unidades cargables.

Financiera

Presupuestar Budgeting. El proceso de predecir y controlar el gasto de dinero dentro de la empresa y consiste en un ciclo de negociación periódica para fijar presupuestos (normalmente anual) y la monitorización diaria de los presupuestos actuales.

Cost

PRINCE2 El método estándar del gobierno de Reino Unido para gestión de proyecto.

Todos

Prioridad Secuencia en la que se necesita resolver una Incidencia o Problema, basado en el impacto y la urgencia.

Incidencias

Prioridad Secuencia en la que se necesita resolver una Incidencia o Problema, basado en el impacto y la urgencia.

Problemas

Problema Causa subyacente desconocida de una o más Incidencias.

Problemas


231

Procedimiento Una serie conectada de acciones, actividades, realizadas por agentes, lo suficientemente detallada para que un agente tenga claro qué ha de hacer.

Todos

Proceso Una serie de acciones, actividades, cambios, etc. realizados por agentes con la intención de satisfacer un propósito o alcanzar un gol.

Todos

Proceso de BCM

Un conjunto de actividades con entregables definidos formando una parte discreta del ciclo vital de la BCM.

Continuidad

Proceso de negocio

Un grupo de actividades de negocio apropiadas por una organización con el fin de conseguir un objetivo común. Procesos típicos de negocio incluyen recibir pedidos, servicios de marketing, venta de productos, entrega de servicios, distribución de productos, facturación de servicios, contabilización de dinero recibido. Un proceso de negocio normalmente dependerá de varias funciones de negocio, rara vez operará de forma aislada, es decir, otros procesos de negocio dependerán de él y él dependerá de otros procesos.

Todos

Programa Una colección de actividades y poyectos que colectivamente implementan un nuevo requisito corporativo o función.

Tecnología

Programa de Mejora de Servicio

Un proyecto formal encargado dentro de una organización para identificar e introducir mejoras mesurables dentro de un área específica o proceso de trabajo.

Todos

Programación Adelantada de Cambios

Contiene detalles de todos los cambios aprobados para implementación y sus fechas de implementación propuestas. Se debería acordar con los clientes y el negocio, Gestión de Nivel de servicio, el Service Desk y Gestión de Disponibilidad. Una vez acordados, el Service Desk debería comunicar a la comunidad de Usuarios en general cualquier downtime programado adicional que surja de implementar los cambios, utilizando los métodos más efectivos disponibles.

Cambios

Proveedor de servicio

Organización externa que suministra servicios o productos a clientes.

Disponibilidad


232

Puente (bridge) Un puente es el equipamiento y las técnicas utilizadas para ligar circuitos unos a los otros para asegurar el mínimo daño de transmisión.

Tecnología

Punto Único de Fallo

Un componente que causará la no-disponibilidad de un servicio cuando falle.

Disponibilidad

Recuperabilidad La habilidad de un sistema de recuperarse. Este término combina sostenibilidad, serviciabilidad y resistencia.

Disponibilidad

Recuperación Gradual

Anteriormente llamado Standby Frío, es aplicable a organizaciones que no necesitan la restauración inmediata de procesos de negocio y pueden funcionar por un periodo de hasta 72 horas o más sin el re establecimiento de las facilidades plenas de IT. Esto puede incluir la provisión de alojamiento vacío completamente equipado con electricidad, controles de entorno e infraestructura de cableado de red local, conexiones de telecomunicaciones y disponible en una situación de desastre para que una organización pueda instalar su propio equipo informático.

Continuidad

Recuperación Inmediata

Anteriormente llamado Standby Caliente, proporciona la inmediata restauración de servicios tras un incidente irrecuperable. Es importante distinguir entre la definición anterior de “standby caliente” y “recuperación inmediata”. Standby caliente típicamente se refiere a disponibilidad de servicios dentro de un marco de tiempo corto tal como 2 a 4 horas mientras que recuperación inmediata implica la disponibilidad instantánea de los servicios.

Tecnología

Recuperación Intermedia

Anteriormente llamado “Warm Standby”, conllevará típicamente el reestablecimiento de los sistemas y servicios críticos dentro de un plazo de 24 a 72 horas y, será utilizado por organizaciones que necesitan recuperar las facilidades de IT dentro de un periodo de tiempo predeterminado para prevenir de impactos al proceso de negocio.

Continuidad


233

Recursos El término recursos se refiere a los medios que necesita la sección de Servicios de IT para proporcionar a los clientes los servicios requeridos. Los recursos son típicamente equipo de ordenador y relacionado, software, facilidades o organizacional (personas).

Capacidad

Registro El registro inicial y continuado de un CI. Configuración Registro El registro inicial y continuado de una

llamada. Service Desk

Registro de Cambio

Un registro de Solicitudes para Cambio surgidos durante el proyecto, mostrando información de cada Cambio, su evaluación, qué decisiones se han tomado y su estatus actual, por ejemplo: Surgido, Revisado, Aprobado, Implementado y Cerrado.

Cambios

Requisito de Nivel de Servicio

Requisitos, expresados por el cliente que son inputs a las negociaciones hacia los SLA

SLM

Resistencia Habilidad de un servicio de continuar cuando uno o más de sus componentes han fallado.

Disponibilidad

Resolución Acción que resolverá una Incidencia. Esto puede ser un Workaround.

Incidencias

Restauración de Servicio

El momento que un cliente ha confirmado que el servicio se puede volver a utilizar otra vez tras una incidencia o contingencia.

Disponibilidad

Restauración de Servicio

El momento que un cliente ha confirmado que el servicio se puede volver a utilizar otra vez tras una incidencia o contingencia.

Continuidad

Revisión Post Implementación

Una revisión para ver si el cambio ha conseguido lo que tenía que conseguir.

Cambios

Revisión Post Implementación

Una revisión para ver si el cambio que debería resolver el problema ha conseguido de hecho resolver el problema.

Problemas

Riesgo Una medida de la exposición a la que puede estar sujeta una organización. Esta es una combinación de la probabilidad de que ocurra un trastorno de negocio y la posible pérdida que pueda resultar de tal trastorno o de negocio.

Disponibilidad


234

Riesgo Una medida de la exposición a la que puede estar sujeta una organización. Esta es una combinación de la probabilidad de que ocurra un trastorno de negocio y la posible pérdida que pueda resultar de tal trastorno o de negocio.

Continuidad

Rol Un conjunto de responsabilidades, actividades y autorizaciones.

Todos

Roll in roll out (RIRO)

RIRO es un término que se utiliza en algunos sistemas para describir intercambios.

Tecnología

Rollout El momento o período en el que se implementa un sistema o conjunto de sistemas. Este término normalmente se usa cuando se implementan múltiples sistemas en distintos momentos.

Difusión

Rotacional Position Sensing

RPS es una facilidad que se emplea en la mayoría de los mainframes y en algunos mini ordenadores. Cuando se ha iniciado una búsqueda el sistema puede liberar la ruta del disco al controlador para el uso de otro disco mientras espera los datos requeridos bajo las cabezas de lectura/escritura (latencia). Esta facilidad normalmente mejora el rendimiento general del sistema I/O (E/S).

Tecnología

Sección de seguridad

LA sección en el SLA que describe el nivel de seguridad necesario.

Seguridad

Sección de Seguridad

La sección en el SLA que describe el nivel de seguridad necesario.

SLM

Seguridad Confidencialidad, Integridad y Disponibilidad de CI.

Seguridad

Servicios Servicios son los entregables de la sección de Servicios de IT tal y como los perciben los clientes; los servicios no consisten meramente poner a disposición de los clientes los recursos informáticos.

Todos

Servicios de IT Servicios son los entregables de la sección de Servicios de IT tal y como los perciben los clientes; los servicios no consisten meramente poner a disposición de los clientes los recursos informáticos.

Todos


235

Sistema Un conjunto integrado que consiste en uno o más de los procesos, hardware, software, facilidades y personas que proporciona una capacidad de satisfacer una necesidad expresada u objetivo.

Todos

Sistema de Memoria Virtual

Se desarrollaron los sistemas de memoria virtual para aumentar el tamaño de la memoria al añadir una capa de almacenamiento auxiliar, que reside en el disco.

Tecnología

Sizing de aplicación

El proceso que estima los requisitos de recursos para soportar un cambio de aplicación propuesto o una nueva aplicación, para asegurar que alcanza sus niveles de servicio requerido.

Capacidad

Sobre tasar Sobretasar es cobrar a los usuarios de negocio una tasa Premium por utilizar recursos en horas punta.

Financiera

Solicitud de Cambio (RFC)

Formulario, o pantalla, utilizada para registrar detalles de una solicitud de cambio o cualquier CI dentro de una infraestructura o a procedimientos y artículos asociados con la infraestructura.

Cambios

Solicitud de Servicio

Cada incidencia que no es un fallo dentro de la infraestructura de IT.

Service Desk

Soporte de Primera Línea

A menudo, se refiere a los departamentos y grupos de soporte (especialistas) distintos al Service Desk como grupos de soporte de segunda –o tercera- línea, teniendo más habilidades especialistas, tiempo y otros recursos para resolver incidencias. A este respecto, el Service Desk sería soporte de primera línea.

Incidencias

Soporte de Segunda Línea

A menudo, se refiere a departamentos y grupos de soporte (especialistas) distintos al Service Desk, como grupos de soporte de segunda o tercera línea, teniendo más habilidades especialistas, tiempo u otros recursos para resolver incidencias. A este respecto, el Service Desk sería soporte de primera línea.

Service Desk


236

Soporte de Tercera Línea

A menudo, se refiere a departamentos y grupos de soporte (especialistas) distintos al Service Desk, como grupos de soporte de segunda o tercera línea, teniendo más habilidades especialistas, tiempo u otros recursos para resolver incidencias. A este respecto, el Service Desk sería soporte de primera línea.

Incidencias

Sostenibilidad Habilidad de un componente o servicio para volver a un estado en el que la funcionalidad deseada se volverá a proporcionar.

Disponibilidad

Specsheet Especifica en detalle lo que quiere el cliente (externo) y qué consecuencias esto tiene para el proveedor de servicio (interno) tal como los recursos requeridos y habilidades.

SLM

Standby Frío Ver “Recuperación Gradual”. Continuidad

Standby Caliente

Ver “Recuperación Inmediata”. Continuidad

Standby Templado

Ver “Recuperación Inmediata”. Continuidad

Súper Usuario En algunas organizaciones, es común utilizar Usuarios “expertos” (comúnmente conocidos como Súper Usuarios o Usuarios Expertos) para tratar con problemas o consultas de soporte de primera línea. Típicamente, esto es en áreas de aplicación específicas, o situaciones geográficas, donde no hay el requerimiento de empleados de soporte a tiempo completo. Este recurso valioso sin embargo, se debe coordinar y utilizar de manera cuidadosa.

Service Desk

Terminal I/O (E/S)

Terminal I/O (E/S) es un mecanismo online de lectura de o escritura a tal como un VDU o impresora remota.

Tecnología

Trashing Una condición en un sistema de almacenamiento virtual donde una promoción excesiva de tiempo de CPU se pasa en mover datos entre el almacén principal y auxiliar.

Tecnología


237

Tiempo de búsqueda

Tiempo de búsqueda ocurre cuando las cabezas de lectura/escritura no están posicionadas en la pista correcta. Describe el tiempo transcurrido tardado en mover las cabezas a la pista correcta.

Tecnología

Tiempo de Espera

Tiempo de espera ocurre cuando el mecanismo, que desea utilizar un programa y,a está ocupado. E programa por lo tanto tendrá que esperar e una cola para obtener el servicio de ese mecanismo.

Tecnología

Tiempo Medio entre Fallos

Tiempo medio entre la restauración de servicio tras una incidencia y que ocurra otra incidencia.

Disponibilidad

Tiempo Medio entre Incidencias de Sistema

Tiempo medio entre ocurrencias de incidencias.

Disponibilidad

Tiempo Medio de Reparaciones

Downtime medio entre la ocurrencia de una incidencia y la restauración del servicio/sistema.

Disponibilidad

Tiempo de Transferencia de datos

Tiempo de transferencia de datos es la cantidad de tiempo que tarda un bloque o sector de datos en ser leído de o escrito a un mecanismo de I/O (E/S), tal como un disco o cinta.

Tecnología

Tiempo Transcurrido

Tiempo desde el principio del inicio de una incidencia, mientras que no se resuelva todavía.

Disponibilidad

Unidad Cargable

Unidades de Trabajo de negocio a los que pueden atribuir cobros.

Financiera

Unidad de Coste

La unidad de coste es una unidad de coste funcional que establece coste estándar por elemento de carga de trabajo, basado en los ratios de actividad calculados convertidos a ratio coste.

Financiera

Unidad de Difusión

El nivel al que software de un tipo dado se difunde normalmente.

Difusión

Unidad de Negocio

Un segmento de la entidad de negocio por la que tanto se reciben ingresos como se causan o controlan gastos, utilizándose tales ingresos y gastos para evaluar el rendimiento segmental.

Todos

Unidad de Trabajo de

Trabajo de Software es un término genérico pensado para representar una base común.

Capacidad


238

Software en la que todos los cálculos para el uso de carga de trabajo y la capacidad de recursos IT se basan. Una unidad de trabajo de software para el equipo de tipo I/O equivale al número de bytes transferidos; y para procesadores centrales se basa en el producto de electricidad y tiempo-cpu.

Urgencia Medida de importancia crítica para el negocio de una Incidencia o Problema basado en el impacto y en las necesidades del Cliente.

Incidencias

Urgencia Medida de importancia crítica para el negocio de una Incidencia o Problema basado en el impacto y en las necesidades del Cliente.

Problemas

Usuario La persona que utiliza el servicio a diario. Service Desk

Usuario Experto Ver “Súper Usuario”. Service Desk

Usuario final Ver “Usuario”. Service Desk

Utilización de Porcentaje

Utilización de porcentaje describe la cantidad de tiempo que un mecanismo de hardware está ocupado en periodo de tiempo dado. Por ejemplo, si la CPU está ocupado 1800 segundos en un período de una hora, su utilización se dice que es de un 50%.

Capacidad

Variante CI con la misma funcionalidad que otro CI pero diferente en algún detalle pequeño.

Configuración

Ventana de Servicio

Horas/tiempos en los que un servicio está disponible.

Disponibilidad

Ventana de Servicio

Horas/tiempos en los que un servicio está disponible.

SLM

Verificación Proceso que asegura que la CMDB y los CI físicos están sincronizados

Configuración

Versión Una instancia identificada de un Artículo de Configuración dentro de una estructura de desglose de un producto o en la estructura de configuración para el propósito de localizar y auditar el historial del cambio. También se utiliza para Artículos de Configuración de Software para definir una identificación específica difundida en desarrollo para edición, revisión o modificación, test o producción.

Configuración


239

Versión Una instancia identificada de un Artículo de Configuración dentro de una estructura de desglose de un producto o en la estructura de configuración para el propósito de localizar y auditar el historial del cambio. También se utiliza para Artículos de Configuración de Software para definir una identificación específica difundida en desarrollo para edición, revisión o modificación, test o producción.

Difusión

VSI (Visual Storage Interrupt)

VSI (Virtual Storage Interrupt) es un término ICL VME para un fallo de página.

Tecnología

Vuelta a Fase normal

La fase dentro de un plan de recuperación de un negocio que reestablece operaciones normales.

Continuidad

Vulnerabilidad La mediad en la que se verá afectado un componente o un servicio por una amenaza.

Disponibilidad

Vulnerabilidad La mediad en la que se verá afectado un componente o un servicio por una amenaza.

Continuidad

Waterline El nivel más bajo de detalle relevante al cliente.

SLM

Workaround Método de evitar una Incidencia o Problema, o desde un arreglo temporal o de una técnica que significa que el Cliente no depende de un aspecto particular del servicio que se sabe tiene un problema.

Incidencias

Date post:	25-Apr-2020
Category:	Documents
Upload:	others
View:	0 times
Download:	0 times

A mi familia, a las personas que han confiando en mí, y a ... TI de manera eficaz y con un coste...

Documents