proyecto fin de carrera - iit · brindado. la entrega de este proyecto supone el fin de la etapa...

Autorizada la entrega del proyecto del alumno/a:

Enrique de Diego Ruiz

EL DIRECTOR DEL PROYECTO

Fernando Gómez González

Fdo.: ........................ Fecha: ....../ ....../ ......

Vo Bo del Coordinador de Proyectos

Susana Ortiz Marcos

Fdo.: ........................ Fecha: ....../ ....../ ...

PROYECTO FIN DE CARRERA

AUTOR: ENRIQUE DE DIEGO RUIZ

MADRID, JUNIO, 2011

Comparativa de ITIL v3 con COBIT 4.1 y

desarrollo de una aplicación ITIL para el

iPhone

UNIVERSIDAD PONTIFICIA COMILLAS

ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)

INGENIERO EN ORGANIZACIÓN INDUSTRIAL

I

COMPARATIVA DE ITIL v3 CON COBIT 4.1 Y DESARROLLO DE UNA APLICACIÓN PARA EL IPHONE

DEDICATORIA

A mis abuelos,

porque sin ellos no habría tenido lo mejor de mi vida:

mis padres.

II


AGRADECIMIENTOS

Quiero aprovechar, de nuevo, estas líneas para agradecer a mi familia, mi novia y mis

amigos la comprensión y el apoyo recibido durante estos años.

Primeramente quiero agradecer a mis padres todas las oportunidades que me han

brindado. La entrega de este proyecto supone el fin de la etapa universitaria y, aunque

acabar dos carreras no es tarea fácil, desde luego que sin ellos y sin su esfuerzo hoy no

estaría aquí. Gracias por vuestro cariño, por vuestro apoyo, por los ánimos en todos los

momentos, particularmente aquellos más complicados. ¡Muchísimas gracias por todo!

Muchas gracias Raquel, por haberme acompañado por toda esta etapa universitaria. Ha

sido una parte muy importante en mi vida, en la que siempre has estado conmigo.

Espero compartamos muchas más experiencias juntos.

A todos mis amigos, gracias, especialmente a Antonio, por tantos buenos momentos

compartidos desde la infancia hasta hoy.

Agradecer también a todos aquellos profesores que han despertado en mí una gran

inquietud y han hecho que nunca quiera dejar de aprender. Además, agradecer

especialmente a mi director, Fernando Gómez, el empujón inicial, y haber luchado por el

proyecto, así como por haber aportado muchas y brillantes ideas.

A todos una vez más, GRACIAS.

III


RESUMEN DEL PROYECTO

Las Tecnologías de la Información (TIC) constituyen en la actualidad uno de los

elementos clave para el mantenimiento de desarrollo de la actividad de la mayoría de las

organizaciones, sean estas entidades de actividad mercantil, o no, privadas o públicas.

Prácticamente todas las organizaciones están impactadas por las TIC, ya sea para

mejorar la productividad, ofrecer nuevos servicios apoyándose en estas tecnologías, etc.

Cada día aparecen nuevas posibilidades y las organizaciones no quieren quedarse

rezagadas.

Por otro lado, cada vez son más las regulaciones y legislaciones que afectan a las

organizaciones. Esto supone un reto para las mismas, teniendo que tener controlados

aquellos riesgos que puedan presentarse al utilizar alguna tecnología.

Actualmente existen dos guías de buenas prácticas en la industria de las TIC: ITIL

(colección de buenas prácticas originario del Reino Unido) y COBIT (conjunto de

mejores prácticas creado por ISACA), siendo ambas guías ampliamente utilizadas. En

este proyecto se abordan ambas, analizándolas en detalle, viendo cómo se

complementan y en qué se diferencian.

Además de estudiar dichas guías, se han entrevistado a varios expertos en el sector para

conocer su opinión acerca de la situación actual de las TIC en las organizaciones y de la

utilidad que ellos consideran que tienen las dos guías anteriormente mencionadas.

Asimismo, se realiza una aplicación – tutorial sobre ITIL para el teléfono multimedia de

Apple, el iPhone. El desarrollo de esta aplicación pretende poner a disposición de los

más de 50 millones de usuarios de iPhone una herramienta de consulta sobre ITIL, de

manera que puedan consultar un resumen de la guía, así como un glosario de términos

empleados en cualquier momento en dicho terminal. También se incluye en la aplicación

un módulo de tareas, donde cada usuario puede descargar a su terminal una lista de

tareas ITIL a realizar.

Para complementar a dicha aplicación, se desarrolla una página web en la que se

documenta el funcionamiento de la misma. Además, sirve como input al módulo de

tareas, donde cada usuario puede actualizar su fichero de tareas. La página web también

IV


presenta un sistema de foros donde se informará de las novedades y donde los usuarios

pueden consultar sus dudas. Con el objetivo de permitir el acceso a la página web desde

un equipo diferente a un ordenador de escritorio, se ha desarrollado también una página

web optimizada para el iPhone, de forma que pueda visualizarse información desde el

propio terminal.

Finalmente, se analiza el modelo de negocio de la Apple Store y se establece el precio de

venta de la aplicación. Este precio tiene en cuenta la valoración económica del proyecto,

así como la opinión de los expertos y un análisis de los precios de las aplicaciones que

actualmente están en venta en la tienda de Apple.

V


ABSTRACT

IT (Information Technology) is nowadays one of the key elements to maintain and

develop the activity of most organizations, either mercantile or not, private or public.

Almost all organizations are impacted by IT in some way or another. They could be used

to increase productivity, offer new services supported by these technologies, etc. Every

day new possibilities arise and organizations don’t want to lie behind.

Furthermore, organizations must comply with existing and new regulation (SOX, Basel

II, etc.). The use of these technologies must be compliant with these regulations and

organizations should be aware of the release of new ones. Thus, technologies should

support these regulations and increase the organization’s value.

Nowadays there are two good practices guidelines being used: ITIL (IT best practices

book collection, originated from the UK) and COBIT (best practices framework

developed by ISACA), both widely used. In this project both are approached, being

analyzed in detail, finding out where they complement and what their main differences

are. Apart from analyzing these guides, several experts in IT have been interviewed to

know their opinion about the current situation of IT in organizations as well as their

opinion about the usefulness of the two previously mentioned guides.

Likewise, an application is developed. This application is a tutorial about ITIL and it is

designed for the iPhone. This development aims to make available to the 50 million

iPhone owners a tool to gather information about ITIL anywhere anytime. The

application contains a summary of the ITIL books and a glossary. It also has a module

which enables users to download a to-do list.

To complement this application a website has also been developed. In this website users

can find several modules: a how-to module which explains them how to use the

application, a forum where news are announced and where users can ask for help and

finally the interface to upload new information for their to-do list.

A mobile version of this website has also been developed. It has been optimized for the

iPhone and it enables users to have access to some information from their own device.

VI


Finally, the AppStore business model is analyzed and a price for the application is fixed.

This price takes into account the economic assessment of the project, the experts’ input

and an analysis of the average prices currently present in the AppStore.

VII


ÍNDICE

DEDICATORIA .....................................................................................................................................................I AGRADECIMIENTOS .......................................................................................................................................... II RESUMEN DEL PROYECTO.............................................................................................................................. III ÍNDICE .............................................................................................................................................................. IV TABLA DE ILUSTRACIONES .............................................................................................................................. X

1. Introducción .................................................................................................................................. 1 1.1 MOTIVACIÓN ............................................................................................................................................ 4 1.2 OBJETIVOS ................................................................................................................................................. 4 1.3 RECURSOS EMPLEADOS ............................................................................................................................ 5

1.3.1 HARDWARE .................................................................................................................................. 5 1.3.2 SOFTWARE .................................................................................................................................... 5

2. ITIL .................................................................................................................................................... 7 2.1 INTRODUCCIÓN A ITIL ............................................................................................................................. 8 2.2 ITIL V2 .................................................................................................................................................... 10 2.3 ITIL V3 ................................................................................................................................................... 14

2.3.1 SERVICE STRATEGY ................................................................................................................... 20 2.3.2 SERVICE DESIGN ........................................................................................................................ 27 2.3.3 SERVICE TRANSITION ...................................................................................................... 31 2.3.4 SERVICE OPERATION ....................................................................................................... 35 2.3.5 CONTINUAL SERVICE IMPROVEMENT ............................................................................... 40

2.4 FUNCIONAMIENTO DEL CICLO DE VIDA DEL SERVICIO ......................................................................... 41 2.5 VENTAJAS E INCONVENIENTES DE ITIL PARA LOS CLIENTES Y LAS ORGANIZACIONES ..................... 43 2.6 GRUPOS DE TRABAJO QUE POTENCIAN ITIL ........................................................................................ 47

2.6.1 ITSMF ......................................................................................................................................... 47 2.6.2 OGC (CCTA) ............................................................................................................................. 47 2.6.3 EXIN ........................................................................................................................................... 48 2.6.4 ISEB ............................................................................................................................................ 49

3. ISACA ............................................................................................................................................. 50 3.1 INTRODUCCIÓN A ISACA ....................................................................................................................... 51 3.2 COBIT 4.1 .............................................................................................................................................. 53

3.2.1 MARCO DE TRABAJO DE COBIT 4.1 ........................................................................................ 55 3.2.2 MODELO GENÉRICO DE PROCESOS DE COBIT 4.1 ................................................................. 59 3.2.3 MODELO DEL MARCO DE TRABAJO DE COBIT 4.1 ................................................................ 66 3.2.4 ACEPTABILIDAD GENERAL DE COBIT 4.1 .............................................................................. 67

4. ITIL v3 vs COBIT 4.1 ................................................................................................................. 69 4.1 CONSIDERACIONES DE LOS EXPERTOS .................................................................................................. 70 4.2 RECOMENDACIONES DEL ITGI .............................................................................................................. 71 4.3 CONCLUSIÓN ............................................................................................................................................ 74

5. Desarrollo de la aplicación .................................................................................................... 77 5.1 INTRODUCCIÓN ....................................................................................................................................... 78 5.2 IDENTIFICACIÓN DE NECESIDADES ........................................................................................................ 79 5.3 ARQUITECTURA .................................................................................................................................... 100

5.3.1 PANTALLA ................................................................................................................................ 103 5.3.2 RED .......................................................................................................................................... 104 5.3.3 DESARROLLO DE APLICACIONES PARA EL IPHONE .............................................................. 105

5.4 DISEÑO EXTERNO ................................................................................................................................ 106 5.4.1 DISEÑO A ALTO NIVEL ............................................................................................................ 106

VIII


5.5 DIAGRAMAS UML ................................................................................................................................ 113 5.6 PROGRAMACIÓN ................................................................................................................................... 115

5.6.1 MAC OS X ............................................................................................................................... 116 5.6.2 IPHONE OS .............................................................................................................................. 116

5.6.2.1 COCOA TOUCH, APIS Y FRAMEWORKS DEL IPHONE OS .................................... 117 5.6.2.2 TIPOS DE APLICACIONES EXISTENTES PARA EL IPHONE OS X .......................... 117

5.6.3 OBJECTIVE-C ........................................................................................................................... 119 5.6.3.1 PARTICULARIDADES DEL LENGUAJE OBJECTIVE-C ............................................ 121

5.6.4 MODELO VISTA CONTROLADOR ............................................................................................ 124 5.6.4.1 MVC: OUTLETS Y ACTIONS .................................................................................. 125 5.6.4.2 DELEGATES Y PROTOCOLS ................................................................................... 125

5.6.5 CICLO DE VIDA DE UNA APLICACIÓN DEL IPHONE ................................................................ 127 5.6.6 XCODE ...................................................................................................................................... 129

5.6.6.1 HERRAMIENTAS ADICIONALES AL XCODE ........................................................... 131 5.6.7 DESARROLLO DE LA APLICACIÓN ........................................................................................... 133

5.6.7.1 MÓDULO GUÍA ITIL.............................................................................................. 133 5.6.7.2 MÓDULO GLOSARIO .............................................................................................. 134 5.6.7.3 MÓDULO ALTA TAREAS ITIL............................................................................... 136 5.6.7.4 MÓDULO ACERCA DE ............................................................................................ 137 5.6.7.5 NAVEGACIÓN DE LA APLICACIÓN ......................................................................... 139

5.6.8 DESARROLLO DE LA PÁGINA WEB ......................................................................................... 140 5.6.8.1 VERSIÓN ESCRITORIO ........................................................................................... 142

5.6.8.1.1 MÓDULO DE USO DE LA APLICACIÓN ................................................. 143 5.6.8.1.2 MÓDULO DE ALTA DE TAREAS ............................................................ 145 5.6.8.1.3 FORO WEB ............................................................................................ 146

5.6.8.2 VERSIÓN MÓVIL ..................................................................................................... 148 5.7 PRUEBAS DEL SISTEMA ........................................................................................................................ 150 5.8 IMPLANTACIÓN .................................................................................................................................... 154 5.9 MANTENIMIENTO ................................................................................................................................. 155

6. Establecimiento del precio de la aplicación .................................................................. 156 6.1 CONSIDERACIONES INICIALES Y LIMITACIONES ................................................................................ 157 6.2 MODELO DE NEGOCIO DE LA APPSTORE DE APPLE .......................................................................... 158 6.3 DISCUSIONES INICIALES ACERCA DEL PRECIO DE LA APLICACIÓN ................................................... 159 6.4 VALORACIÓN ECONÓMICA DEL PROYECTO ........................................................................................ 160

6.4.1 VALORACIÓN ECONÓMICA DEL PROYECTO INCLUYENDO TODOS LOS GASTOS ................... 162 6.4.2 VALORACIÓN ECONÓMICA DEL PROYECTO EXCLUYENDO BENEFICIOS ............................... 163

6.5 ANÁLISIS DE ESCENARIOS ................................................................................................................... 164 6.6 DECISIÓN FINAL ................................................................................................................................... 168

7. Plan de proyecto ...................................................................................................................... 169 7. PLAN DE PROYECTO ............................................................................................................................... 170

8. Conclusiones ............................................................................................................................. 171 8. CONCLUSIONES DEL PROYECTO ............................................................................................................. 172

9. Futuros desarrollos ................................................................................................................ 173 9. FUTUROS DESARROLLOS ....................................................................................................................... 174

10. Bibliografía ............................................................................................................................. 175 10. BIBLIOGRAFÍA ...................................................................................................................................... 176

10.1 LIBROS ...................................................................................................................................... 176 10.2 E-BOOKS ................................................................................................................................... 178 10.3 INTERNET ................................................................................................................................. 178

11. Anexos ...................................................................................................................................... 179

IX


11. ANEXOS ................................................................................................................................................. 180 11.1 CMMI........................................................................................................................................ 180 11.2 LEY SARBANES OXLEY ............................................................................................................. 183 11.3 BASILEA 2 ................................................................................................................................. 185

11.3.1 CASO DE ESTUDIO: SANTANDER CONSUMER BANK ............................................ 189 11.4 ENTREVISTAS ........................................................................................................................... 190 11.5 GLOSARIO ................................................................................................................................. 199

X


TABLA DE ILUSTRACIONES

Ilustración 1: ITIL v2, fuente OGC .......................................................................................................... 10

Ilustración 2: Relación de componentes ITIL v2 y v3 ..................................................................... 14

Ilustración 3: Ciclo de vida del servicio en ITIL v3. Fuente: OGC ............................................... 16

Ilustración 4: Elementos genéricos de los procesos. Fuente: ITIL v3 Foundation Complete Certification Kit 2009 .............................................................................................................. 18

Ilustración 5: Relación de Service Strategy con el negocio, las estrategias, políticas, recursos y objetivos del negocio. Fuente: OGC .................................................................................. 20

Ilustración 6: Aumentar la madurez de la gestión financiera mejorará los servicios y disminuirá los costes ................................................................................................................................... 22

Ilustración 7: Método para evaluar riesgos según la probabilidad y el impacto en IT. Fuente: The business of IT ........................................................................................................................ 23

Ilustración 8: Procesos y prácticas de Service Strategy ................................................................. 24

Ilustración 9: Catálogo de servicios ....................................................................................................... 25

Ilustración 10: El valor es la suma de la utilidad y la garantía .................................................... 26

Ilustración 11: Relación de Service Strategy con las otras fases del ciclo de vida .............. 26

Ilustración 12: Relación de Service Design con Service Strategy ............................................... 27

Ilustración 13: Relación entre los componentes de Service Design. Fuente: ITIL Version 3 at a Glance ........................................................................................................................................................ 28

Ilustración 14: Relación de Service Transition con Service Design y Service Strategy. Fuente: OGC ..................................................................................................................................................... 31

Ilustración 15: Componentes de Service Transition ....................................................................... 32

Ilustración 16: Esquema del proceso de un cambio en ITIL ........................................................ 33

Ilustración 17: Relación de Service Operation con otros procesos de ITIL. Fuente:OGC . 35

Ilustración 18: Relación entre las distintas partes de Service Operation ............................... 36

Ilustración 19: Sistema de gestión de conocimiento del servicio. ............................................. 37

Ilustración 20: Relación de CSI con los otros procesos de ITIL. Fuente: OGC ....................... 40

Ilustración 21: Proceso de mejora en siete pasos. Fuente: The business of IT. .................... 41

Ilustración 22: Funcionamiento del ciclo de vida del servicio .................................................... 42

Ilustración 23: Logo de itSMF .................................................................................................................. 47

XI


Ilustración 24: Logo de la OGC ................................................................................................................. 48

Ilustración 25: Logo de EXIN .................................................................................................................... 48

Ilustración 26: Logo de ISEB..................................................................................................................... 49

Ilustración 27: Logo de ISACA .................................................................................................................. 52

Ilustración 28: Interrelaciones entre los componentes de COBIT. Fuente: COBIT 4.1 ...... 54

Ilustración 29: Principio básico de COBIT. Fuente: COBIT 4.1 .................................................... 56

Ilustración 30: Modelo genérico de procesos de COBIT organizado en cuatro dominios 61

Ilustración 31: Gestión, control, almacenamiento y monitorización. Fuente: COBIT 4.1 . 66

Ilustración 32: Apartado genérico de COBIT 4.1. Fuente: COBIT 4.1 ....................................... 68

Ilustración 33: Convertir X en Y. Fuente: Aligning IT with the business. ................................ 75

Ilustración 34: DFD del modelo físico actual ..................................................................................... 85

Ilustración 35: DFD del modelo lógico actual .................................................................................... 86

Ilustración 36: DFD del modelo lógico nuevo .................................................................................... 97

Ilustración 37: iPhone 2G e iPhone 3G ................................................................................................. 99

Ilustración 38: iPad. Fuente: Apple ..................................................................................................... 100

Ilustración 39: Las dos orientaciones soportadas por el iPhone. Fuente: Apple .............. 102

Ilustración 40: Especificación HW del sistema .............................................................................. 105

Ilustración 41: Pantalla principal de la aplicación ........................................................................ 106

Ilustración 42: Pantalla de Guía ITIL de la aplicación ................................................................. 107

Ilustración 43: Visualización de un apartado de la Guía ITIL ................................................... 108

Ilustración 44: Pantalla del glosario de la aplicación .................................................................. 109

Ilustración 45: Pantalla de tareas ITIL .............................................................................................. 110

Ilustración 46: Navegación de la aplicación .................................................................................... 111

Ilustración 47: Diagrama UML de la aplicación ............................................................................. 113

Ilustración 48: Arquitectura del iPhone OS como un conjunto de capas ............................. 115

Ilustración 49: Ciclo de vida de una aplicación en el iPhone. Fuente: developer.apple.com/iphone ................................................................................................................ 126

Ilustración 50: Inicio de la aplicación XCode 3.1.3 ....................................................................... 128

Ilustración 51: Entorno de depuración del XCode ........................................................................ 129

XII


Ilustración 52: Pantalla principal del iphone con la aplicación ............................................... 131

Ilustración 53: Pantalla guía ITIL de la aplicación ........................................................................ 132

Ilustración 54: Vista del glosario de la aplicación ......................................................................... 133

Ilustración 55: Vista detallada del glosario de la aplicación ..................................................... 134

Ilustración 56: Vista de iTunes obteniendo el identifier de un iPhone ................................. 135

Ilustración 57: Módulo de tareas de la aplicación ......................................................................... 136

Ilustración 58: Módulo de Acerca De ................................................................................................. 137

Ilustración 59: Navegación de la aplicación .................................................................................... 138

Ilustración 60: Estructura de la aplicación Bloomberg en la AppStore en iTunes .......... 139

Ilustración 61: Pantalla principal de la aplicación ........................................................................ 141

Ilustración 62: Página web: apartado de uso de la aplicación ................................................. 142

Ilustración 63: Capturas de la aplicación.......................................................................................... 143

Ilustración 64: Alta de tareas en la página web ............................................................................. 144

Ilustración 65: Foros de la página web ............................................................................................. 145

Ilustración 66: Foro desde la página principal de la web .......................................................... 146

Ilustración 67: Inicio de la versión móvil de la página web ...................................................... 147

Ilustración 68: Vista de la página web versión móvil .................................................................. 148

Ilustración 69: Aplicación Instruments analizando una aplicación del iPhone ................. 152

Ilustración 70: Plan de proyecto .......................................................................................................... 169

Ilustración 71: Niveles CMMI ................................................................................................................ 182

Ilustración 72: Cronograma de Basilea II ......................................................................................... 185

Ilustración 73: Los tres pilares de Basilea II ................................................................................... 187

Ilustración 74: Afectados por el acuerdo de Basilea II. Fuente: Folleto divulgativo de Basilea II de la superintendencia de entidades financieras y cambiarias ........................... 188

1


1. Introducción

2


1. INTRODUCCIÓN

Hoy en día son muy pocas las organizaciones que no tienen ninguna relación con las

TIC.1 Todas tienen, en mayor o menor medida, informatizadas sus bases de datos de

clientes, implantados sistemas de gestión empresarial, automatizados sus sistemas de

compra, etc. Para muchas organizaciones, la información y la tecnología que la soporta

representan sus más valiosos activos, aunque con frecuencia son poco entendidos.

Algunas organizaciones reconocen los beneficios de las TIC y las utilizan para impulsar

el valor de la empresa. Estas organizaciones entienden y administran los riesgos

asociados, así como la dependencia crítica de muchos procesos de negocio en estas

tecnologías.

En general, podría decirse que a lo largo de los últimos años, las TIC han pasado de ser el

soporte de las organizaciones, para convertirse en el motor de las mismas.

Muchas organizaciones están empezando a preocuparse por adoptar mejores prácticas

de IT debido a que deben satisfacer la calidad, los requerimientos fiduciarios y de

seguridad de su información, así como de todos sus activos. Cada vez se promulgan más

leyes que las organizaciones (algunas en sectores específicos, como el financiero, todavía

son más extensas) deben cumplir. Ejemplos de estas leyes son LOPD, Basilea II,

Sarbanes-Oxley, entre muchas otras. Para conocer en detalle las implicaciones de estas

regulaciones, se recomienda leer los anexos 11.2 y 11.3 de este proyecto.

La dirección de la organización debe entender la situación de su arquitectura

empresarial para IT y decidir qué tipo de gobierno y de control debe aplicar. Es

imprudente creer que alguna de las guías o marcos de referencia son la panacea para la

gestión y gobierno de IT, ya que de la teoría a la práctica hay un camino casi infinito.

Tras un extenso período de estudio y conversaciones con miembros de varias

organizaciones, parece que disponer de una sencilla aplicación que informe sobre las

bondades de alguna guía de gestión de IT ayudaría en gran medida a paliar problemas y

ofrecer oportunidades de mejora.

1 Tecnologías de la Información y las comunicaciones. Término equivalente a IT

3


Debido al incesable número de ventas del Apple iPhone, la aplicación va a ser

desarrollada para este dispositivo. Estos teléfonos inteligentes gozan de una gran

capacidad de procesamiento de información, en un tamaño muy reducido, por lo que los

empleados de las organizaciones podrían sustituir sus actuales teléfonos por iPhones,

pudiendo llevar siempre a su disposición la aplicación que va a desarrollarse.

El proyecto está compuesto por varias partes:

Primeramente se analizan ITIL v3 y COBIT v4.1, explicándose los aspectos más

importantes de cada una de ellas, viendo después cómo se complementan y finalmente

verificando qué utilidad tienen para los expertos actuales en IT.

Posteriormente se explica el desarrollo de la aplicación, tomando como base los

comentarios de los expertos del sector de IT en España, teniendo en cuenta las

restricciones de programación del iPhone y siguiendo una metodología de desarrollo de

sistemas en cascada.

A continuación se valora económicamente el proyecto, se evalúa el modelo de negocio de

la Apple Store y se estima el precio óptimo de venta para la aplicación.

Finalmente, pueden encontrarse varios anexos, donde se comentan brevemente los

aspectos más importantes de las leyes Sarbanes-Oxley y Basilea II, el modelo de

evaluación de procesos CMMI y las entrevistas llevadas a cabo.

4


1.1 MOTIVACIÓN

La principal motivación para realizar este proyecto fue analizar más en detalle ITIL. Al

comenzar el proyecto se tenía una ligera idea del alcance que tenía esta guía y de la gran

ayuda que una pequeña aplicación podría tener para las organizaciones.

Se decidió ampliar el proyecto, comparando ITIL v3 con COBIT, para comprender qué

hacía única a cada guía, así como para estudiar el alcance de ambas guías en las

organizaciones actuales.

La idea de desarrollar la aplicación en un Apple iPhone se debe al gran número de

ventas de estos dispositivos y su amplísima penetración en el mercado. Asimismo, la

capacidad de desarrollo de software en estos dispositivos parece adecuada para crear

una aplicación que satisfaga las necesidades de las organizaciones.

El alcance potencial que tiene este proyecto es impresionante y se tiene la idea de que

es posible alcanzar grandes resultados implantando ITIL en todas las organizaciones.

1.2 OBJETIVOS

El objetivo de este proyecto es doble:

1. Analizar dos de las más importantes guías que existen en la actualidad (ITIL v3 y

COBIT v4.1), comprobando su estado actual en las organizaciones y descubriendo

potenciales puntos de implantación.

2. Realizar una pequeña aplicación basada en ITIL v3 para que el personal de una

organización tenga un mejor conocimiento de aquello que puede hacerse en caso

de que suceda un imprevisto, se desee aumentar la calidad de los servicios o

simplemente para que sirva de punto de apoyo para el personal, con la

nomenclatura y los procesos utilizados en IT.

5


1.3 RECURSOS EMPLEADOS

Para el desarrollo de este proyecto es necesario disponer de algunos recursos hardware

y software:

1.3.1 HARDWARE

Es necesario disponer de un ordenador Apple para el desarrollo de la aplicación. Para

este desarrollo en concreto se ha utilizado un MacBook Pro del año 2010.

Asimismo es necesario disponer de un terminal iPhone o iPod Touch para realizar las

pruebas finales. En este proyecto se ha utilizado un iPhone 4 del año 2010.

1.3.2 SOFTWARE

El software utilizado es numeroso y variado:

Xcode: es el entorno de desarrollo integrado de Apple, suministrado gratuitamente con

MacOSX. Trabaja conjuntamente con Interface Builder e incluye varios compiladores,

siendo capaz de trabajar con código C, C++, Objective-C y Java entre otros. Se ha

empleado la versión 4 del programa.

Interface Builder: es parte del entorno de desarrollo de Apple, permitiendo el rápido

desarrollo de interfaces para las aplicaciones.

Microsoft Office: Microsoft Word fue empleado para realizar la documentación del

proyecto, mientras que los cálculos necesarios serán realizados en Microsoft Excel. En

ambos casos, se ha utilizado la versión 2011 para Mac.

Microsoft Visio: empleado para realizar los diagramas del proyecto. Se ha utilizado la

versión 2010 para Windows.

Microsoft Project: empleado para realizar la planificación del proyecto. Se ha utilizado

6


la versión 2010 para Windows.

Keynote: es una aplicación para realizar presentaciones. Pertenece a la suite iWork de

Apple y se ha usado para realizar diseños a alto nivel y presentaciones del proyecto.

Balsamic Mockups: es una aplicación de diseño de interfaces de alto nivel

multiplataforma. Se ha utilizado la versión para Mac.

Taco HTML Edit: es un editor HTML que se ha empleado para el desarrollo de la página

web de la aplicación.

RapidWeaver: es un editor HTML con varios plugins optimizados al desarrollo de

páginas web móviles.

TextMate: es un editor de texto plano con soporte para múltiples lenguajes de

programación, entre los que cabe destacar Objective-C y HTML.

Adobe Photoshop CS5: es un editor avanzado de imágenes que ha sido empleado para

retocar alguna imagen antes de incorporarla al proyecto.

Parallels 6: se trata de un entorno de ejecución de sistemas operativos virtuales. Se ha

utilizado la versión 6 para Mac con el objetivo de ejecutar aplicaciones que sólo

funcionan para Microsoft Windows.

IconComposer: es un editor de iconos incorporado en el sistema operativo Mac OS X. Se

ha utilizado para generar los iconos de la aplicación

Instruments: es una aplicación incorporada en el sistema operativo Mac OS X que

monitoriza los recursos que se están empleando en cada momento por cada aplicación.

Transmit: es una aplicación FTP que se ha utilizado para trabajar con los ficheros del

servidor.

iPhoney: es un simulador del navegador web del iPhone para Mac OSX.

7


2. ITIL

8


2.1 INTRODUCCIÓN A ITIL

La necesidad de un marco de referencia para el gobierno de IT ha estado siempre

presente tanto como para los directivos de una organización, como para los

responsables directos de éstas. A lo largo de los últimos 20 años, se han ido publicando

“normas” o “buenas prácticas” para la gestión de la tecnología, desde distintos colectivos

empresariales, de IT y de asociaciones profesionales

En sus inicios, IT estaba básicamente enfocada en el desarrollo de aplicaciones. Durante

la década de los 80, mientras crecía la gestión de los servicios, también aumentaba la

dependencia de los negocios sobre IT. Se empezaba a necesitar un re-enfoque para una

alinear IT con los intereses de las empresas.

Al mismo tiempo, el gobierno del Reino Unido comenzó a documentar cómo las mejores

organizaciones gestionaban los servicios. A finales de los 80 y principios de los 90,

habían lanzado una serie de libros documentando un primer alcance a la gestión de los

servicios que necesitaban las empresas. Esta colección de libros fue denominada ITIL:

Information Technology Infrastructure Library.

La librería original creció hasta tener más de 40 libros y comenzó a ser de gran interés.

En 1991 se creó el ITIMF (IT Information Management Forum), con la intención de ser

un punto de encuentro entre los usuarios, donde éstos pudiesen intercambiar sus ideas.

Posteriormente, este foro cambió su nombre a itSMF, que en la actualidad tiene

miembros en todo el mundo.

En resumen, ITIL no es más que una colección de libros que informan de las mejores

prácticas en la industria de las TIC.

Al cabo de los años, la metodología ITIL, como conjunto de recomendaciones y mejores

prácticas en la gestión de los servicios de Tecnologías de la Información, se ha

convertido en un estándar de facto.

La librería sigue creciendo constantemente al ir documentándose mejores técnicas y

estableciéndose mejores prácticas.

Primeramente se va a realizar un breve análisis sobre ITIL v2, que ya ha quedado

reemplazada por la tercera versión. En la primera imagen del capítulo siguiente puede

9


verse “el rompecabezas” de ITIL, donde se muestran los siete elementos principales de

los libros de ITIL v2. Cada uno de ellos se conecta con los otros y hasta cierto punto se

superponen.

10


2.2 ITIL V2

Ilustración 1: ITIL v2, fuente OGC

Como se ve en la imagen superior, ITIL V2 estaba formado por siete libros, de los cuales

los dos primeros se consideraban los más importantes:

1 Service Support (Soporte de servicio)

Este libro se centra en asegurar que el cliente, externo o interno, recibe el servicio

adecuadamente, y que éste se gestiona internamente de la mejor manera posible. Cubre

los siguientes procesos:

Incident Management:

Problem Management

Change Management

Release Management

Configuration Management

11


2 Service Delivery (provisión del servicio)

Este libro trata todos los aspectos de la administración de los servicios de soporte y

mantenimiento que se prestan al cliente. El libro describe los servicios que necesita el

cliente y lo esencial para proporcionar esos servicios. Incluye los siguientes procesos:

Capacity Management

Availability Management

Service Continuity Management

Service Level Management

Financial Management

3 ICT Infrastructure Management (Gestión de la infraestructura IT)

De este libro caben destacar cuatro procesos principales:

Diseño y planificación: tiene como objetivo la creación y/o mejora de la solución de IT.

Tiene en cuenta el desarrollo y mantenimiento de las estrategias y proceso de IT para el

despliegue e implementación de las soluciones adecuadas de infraestructura de IT en

toda la organización.

Despliegue: su finalidad es la implementación y extensión del negocio y/o solución de IT

según se diseñó y planificó, con mínima interrupción en los procesos de negocio.

Operaciones: su objetivo es el mantenimiento diario de la infraestructura de IT. Tiene en

cuenta todas las actividades y medidas para permitir y/o mantener el uso pretendido de

la infraestructura de IT.

Soporte Técnico: tiene como finalidad la estructura y apuntalamiento de otros procesos

para garantizar los servicios entregados por la Gestión de Infraestructura de IT. Tiene en

cuenta el desarrollo del conocimiento para la evaluación y soporte de todas las

soluciones actuales y futuras de infraestructura de IT.

4 Planning to Implement Service Management (Planificación para la Implementación de

los Servicios de Gestión)

Este libro examina los problemas y tareas implicadas al planificar, implementar y

12


mejorar los procesos de Gestión de Servicio dentro de una organización. Se centra en los

aspectos clave a considerar cuando se planifica la implementación de la gestión de

servicio en IT. El principal objetivo es asegurar que los servicios de IT están alineados

con las necesidades del negocio.

La provisión de servicio en IT necesita compararse con las demandas actuales y

cambiantes rápidamente del negocio. El objetivo es mejorar continuamente la calidad

del servicio, alineado con los requisitos del negocio y efectivo en coste. Para ello, es

necesario considerar tres aspectos: las personas, los procesos de gestión de servicio

eficaces y eficientes y la infraestructura de IT en términos de herramientas y tecnología.

Además, estos tres aspectos sólo facilitarán la implementación de los objetivos si se

consideran junto con un mecanismo estructurado de alineamiento hacia los objetivos

concretos del negocio.

5 Application Management (gestión de aplicaciones)

Este libro trata el complejo aspecto de gestionar las aplicaciones desde la necesidad

inicial del negocio, a través del ciclo de vida de la Gestión de la Aplicación, hasta la

retirada.

6 The Business Perspective (perspectiva de negocio)

La perspectiva de negocio tiene como meta familiarizar a la dirección del negocio con los

componentes que sirven de base a la infraestructura de la Tecnología de la Información

necesarios para soportar sus procesos de negocio, de forma que se obtenga una

comprensión de los estándares y mejores prácticas de Gestión del Servicio.

7 Security Management (gestión de seguridad)

Este proceso toma como punto de partida a los procesos existentes de ITIL y les añade

actividades de gestión de seguridad. Este proceso, aunque es un proceso separado,

aparece integrado en el resto de procesos. El objetivo es gestionar un nivel definido de

seguridad para la información y servicios de IT, así como gestionar la reacción a

incidentes de seguridad.

De los siete libros mencionados, los dos primeros se consideraban los fundamentales:

13


Service Support y Service Delivery. En general, Service Support explicaba las mejores

prácticas para las actividades del día a día, mientras que Service Delivery lo hacía para

actividades futuras. Servían como guía para las organizaciones. Los otros cinco libros

tocaban pocos temas de ITIL y se consideraban complejos incluso por los propios

expertos de ITIL.

Por ello, ITIL sufrió un cambio importante a finales de 2007, con lo que se cambió el

nombre de V2 a V3. El cambio más notable fue la organización de los libros.

14


2.3 ITIL V3

ITIL v3 está estructurado de manera diferente a la versión 2. Todos los libros se centran

en la gestión del servicio. Contiene 5 volúmenes:

1.Service Strategy (Estrategia del servicio)

2.Service Design (Diseño del servicio)

3.Service Transition (Transición del servicio)

4.Service Operation (Operación del servicio)

5.Continual Service Improvement (Mejora continua del servicio)

Ilustración 2: Relación de componentes ITIL v2 y v3

Estos libros están ordenados de una manera mucho más práctica y, además, al reagrupar

y expandir cada tema, se han conseguido alinear los procesos de TI y las operaciones con

los resultados que se esperan en cada negocio. Para más información pueden

consultarse [OGC07a], [OGC07b], [OGC07c], [OGC07d], [OGC07e] y [OGC07f].

En el gráfico siguiente puede verse cómo se relacionan entre sí cada uno de los

componentes de ITIL. Aunque hay 5 fases, no están separadas, ni deben realizarse en un

orden en concreto. Cada parte afecta a las otras, creando un círculo continuo. Para esto,

es necesario que Continual Service Improvement (CSI) se incorpore a lo largo de todas

15


las otras fases.

Resumiendo mucho, el ciclo de vida sería el siguiente: (es importante destacar que la

mayoría de los procesos definidos no se ejecutan con sólo una vuelta del ciclo de vida)

Service Strategy: Determina las necesidades, prioridades, demandas e importancia

relativa para los servicios. Identifica el valor creado a través de los servicios y predice

los recursos financieros necesarios para diseñar, entregar y ofrecer soporte.

Service Design: Diseña la infraestructura, procesos y mecanismos de soporte necesarios

para cumplir con los requisitos de disponibilidad del cliente.

Service Transition: Confirma que cada servicio satisface los criterios técnicos y

funcionales necesarios para justificar la entrega del servicio al cliente.

Service Operation: Monitoriza la disponibilidad necesaria. Durante esta fase también se

resuelven los incidentes que afecten a la disponibilidad.

Continual Service Improvement: Coordina la recolección de datos, información y

conocimiento relacionados con la calidad y rendimiento de los servicios.

16


Ilustración 3: Ciclo de vida del servicio en ITIL v3. Fuente: OGC

Además de la consolidación de la librería en 5 libros, se han añadido con respecto a la

versión 2, 12 procesos y 3 nuevas funciones, todo ello con el objetivo de enfatizar la

gestión del servicio a través de todo el ciclo de vida del servicio, así como en crear valor

para el negocio en lugar de simplemente mejorar la ejecución de los procesos.

Como puede observarse en la imagen anterior, cada parte del ciclo de vida ejerce

influencia en las otras y requiere de las otras para recibir información y

retroalimentación. De esta manera, se asegura que aunque cambien las demandas de

negocio, los servicios pueden adaptarse para responder efectivamente a estos cambios.

Cabe destacar la importancia de las funciones y de los procesos en ITIL:

Según [OGC07a]: “Las funciones son unidades de organizaciones especializadas en

realizar ciertos tipos de trabajo y responsables de resultados específicos. Están

autocontenidas con las habilidades y recursos necesarios para su rendimiento y

resultados. Las habilidades incluyen métodos de trabajo internos a las funciones. Las

17


funciones tienen su propio cuerpo de conocimiento, que se acumula con la experiencia.

Esto provee estructura y estabilidad a las organizaciones.”

Las funciones típicamente definen roles, las autoridades asociadas a esos roles y las

responsabilidades de tener cierto rendimiento y resultados. Las funciones tienden a

optimizar sus métodos de trabajo de una manera local para enfocarse en los resultados.

Los procesos ayudan a evitar que las funciones tengan poca coordinación entre ellas.

Los procesos pueden definirse como un conjunto estructurado de actividades

coordinadas. Han sido diseñados para producir un resultado y entregar valor a los

clientes o stakeholders. Son ejemplos de sistemas cerrados porque proveen cambios y

transformaciones hacia una meta y usan retroalimentación para autocorregirse. Es

importante considerar el proceso en su totalidad y cómo cada proceso encaja con los

demás. Los procesos tienen las siguientes características:

Son medibles y están guiados por el rendimiento.

Tienen resultados específicos (un proceso existe para conseguir un resultado

específico)

Entregan su resultado a los clientes (o stakeholders)

Responden a un evento específico.

18


Inputs del proceso Outputs del proceso

Dueño del proceso

Documentación del

proceso

Política del proceso Objetivo del

proceso

Feedback del proceso

Dueño del proceso

Procecimientos del proceso

Actividades del proceso Métricas del proceso

Roles del proceso

Mejoras del

proceso

Recursos del

proceso

Capacidades del

proceso

Control del proceso

Proceso

Habilitadores del proceso

Incluyen informes y

revisiones de los procesos

Disparadores

Ilustración 4: Elementos genéricos de los procesos. Fuente: ITIL v3 Foundation Complete Certification Kit 2009

Las funciones y los procesos se relacionan entre sí. Una manera útil para definir roles y

responsabilidades es la matriz RACI2 (por sus siglas en inglés). Esta matriz se utiliza

generalmente para relacionar actividades con recursos, de manera que se asegura que

cada uno de los componentes del alcance está asignado a un individuo o a un equipo.

R viene de responsibility (responsabilidad): es aquella persona que realiza el

trabajo pero reporta a aquella persona que tiene “una A”. Es el responsable de la

realización de la tarea.

A viene de accountability (responsabilidad): responsable de que la acción se lleve

a cabo. Este rol implica propiedad y es quien debe asegurar que se ejecutan las

tareas.

C viene de consult (consulta). Este rol posee alguna información o capacidad

necesaria para terminar el trabajo. Se le informa y se le consulta información.

2 Responsible – Accountable –Consulted - Informed

19


(Comunicación bidireccional)

I viene de inform (información): función o posición que es informada después de

realizar la acción. (Comunicación unidireccional).

Hay un par de reglas que deben cumplirse: no más de una “A” por fila y por lo menos una

“R” por fila.

Actividad/Recurso Usuario 1 Usuario 2 Usuario 3 Usuario 4

Investigación R I I A

Planificación C A R I

Desarrollo A R

Verificación de errores I R A

Tabla 1: Ejemplo de una Matriz RACI

Existe una variación de la matriz RACI llamada matriz RASCI, donde la diferencia es la

adición de un nuevo rol, el de soporte.

En el caso de que en una matriz RACI existiese má de una R, el trabajo debería ser

subdividido a un nivel más bajo, usando una matriz RASCI.

20


2.3.1 SERVICE STRATEGY

Requisitos

Políticas

El negocio

Los clientes

Service Strategy

Estrategias

Objetivos de los requisitos

Requisitos y restricciones

Ilustración 5: Relación de Service Strategy con el negocio, las estrategias, políticas, recursos y objetivos del negocio. Fuente: OGC

En el núcleo del ciclo de vida del servicio, se encuentra Service Strategy (Estrategia de

Servicio), que provee una guía de cómo ver la gestión del servicio no sólo como una

habilidad de la organización, sino también como un activo estratégico. Según la guía

ITIL, las organizaciones deberían usar Service Strategy para establecer objetivos y

resultados esperados, así como para identificar, seleccionar y priorizar oportunidades.

Service Strategy trata sobre asegurar que las organizaciones estén en la posición de

soportar sus costes y riesgos asociados con sus portafolios de servicios.

El objetivo principal de Service Strategy es pararse a pensar por qué algo debe hacerse

antes de pensar cómo debe hacerse.

Los objetivos básicos de Service Strategy son:

Diseñar, desarrollar e implementar la gestión del servicio como un activo

estratégico y asistir al crecimiento de la organización.

Desarrollar la capacidad de la organización de IT para gestionar los costes y

riesgos asociados con sus portafolios de servicio.

Definir los objetivos estratégicos de la organización de IT.

Conseguir estos objetivos asegurarán a la organización una correcta comprensión de

cómo puede ayudar al crecimiento del negocio, a mejorar el rendimiento o cualquier

21


otra estrategia que desee ser desarrollada.

Se definen cuatro prácticas primarias:

1. Definición de mercado

Definición de quiénes serán los clientes para los servicios de IT.

2. Desarrollo de ofertas

Identificación de los servicios a ser ofertados a los clientes e iniciación de

proyectos para desarrollar estos servicios.

3. Preparación para la ejecución

Preparación de la organización IT para estar preparada para llevar a cabo de

manera satisfactoria la estrategia de servicio, incluyendo la identificación de los

CSF (critical success factors, factores críticos de éxito), el establecimiento de

objetivos, la priorización de iniciativas, promoción del crecimiento y

diferenciación de la organización de IT como proveedor de servicios.

4. Desarrollo estratégico de activos

Identificación de activos que pueden ser usados como bloques de construcción

para la creación de servicios y la iniciación de proyectos para desarrollar estos

activos.

Y se establecen cuatro actividades de soporte:

1. Demand Management (Gestión de la demanda)

El objetivo principal de Demand Management es asistir a los proveedores de

servicio de IT a entender e influenciar la demanda de servicios de los clientes y

provisionar a Capacity Management para que ésta sea capaz de satisfacer dicha

demanda.

Existen dos formas de influenciar o gestionar la demanda: la primera mediante

restricciones técnicas o físicas y la segunda mediante chargeback (cobro a los

usuarios por el servicio).

22


2. Financial Management (Gestión financiera)

El objetivo de Financial Management es proveer una administración efectiva en

términos de costes de los activos de IT, así como de los recursos financieros

utilizados al proveer servicios de IT.

Cuando se aplica de manera eficiente, Financial Management provee el

conocimiento y gestión de la distancia entre las perspectivas conflictivas entre las

oportunidades de negocio y las capacidades de la organización de IT. Hace que el

negocio sea más consciente en temas de IT y hace que IT esté más alineado con el

negocio.

Organización reactiva:

IT supone costes incontrolados

Centro de costes:

IT supone un gasto

Centro de rentabilidad:

IT supone un ROI positivo

Alineación de negocio:

IT contribuye a la estrategia de

negocio

Cre

cien

te m

adur

ez d

e la

ges

tión

finan

cier

a

Con

tabi

lidad

, cob

ro y

pre

supu

esto

s m

ejor

ados

May

or fo

co e

n IT

IL v

3

Mejores servicios a un menor

coste

Ilustración 6: Aumentar la madurez de la gestión financiera mejorará los servicios y disminuirá los costes

Existen tres actividades fundamentales para Financial Management:

Funding, encargado de predecir los requisitos futuros de fondos para

entregar los servicios acordados y monitorizar que dichos fondos se

adecuan a los presupuestos definidos.

IT Accounting: Permite a la organización de IT controlar cómo se gasta el

dinero.

23


Chargeback. Esta se trata de una actividad opcional y consiste en cobrar a

los clientes por el uso de los servicios de IT.

3. Risk Management (Gestión del riesgo)

Se identifican, evalúan y determinan las respuestas aceptables a los riesgos.

Como puede verse en la imagen siguiente, el riesgo está compuesto por dos

factores: impacto y probabilidad. Según sea el tamaño del impacto y la

probabilidad de éste de que ocurra, estará situado en un lugar u otro de la matriz.

Según esta posición habrá que mitigar este riesgo de una o otra manera,

empleando la cantidad de recursos adecuada para cada caso.

Riesgo bajo Riesgo bajo Riesgo significativo

Riesgo bajo Riesgo significativo Gran riesgo

Riesgo significativo Gran riesgo Riesgo máximo

Baja Media Alta

Bajo

Medio

Alto

IMP

AC

TO

PROBABILIDAD

Ilustración 7: Método para evaluar riesgos según la probabilidad y el impacto en IT. Fuente: The business of IT

24


4. Service Portfolio Management (Gestión del portafolio de servicios).

El objetivo principal es proveer la dirección estratégica y gestión de las

inversiones en Service Management de forma que continuamente se mantenga el

portafolio de servicios óptimo.

Definición de mercado

Preparación para la

ejecución

Desarrollo de activos

estratégicos

Desarrollo de ofertas

Gestión del portafolio de servicios

Gestión financiera Gestión de la demanda Gestión del riesgo

Prácticas de soporte

Ilustración 8: Procesos y prácticas de Service Strategy

Un portafolio de servicios describe los servicios de un proveedor en términos de

valor de negocio. Se usa este portafolio para articular las necesidades de negocio

y los proveedores de servicio respondiendo a esas necesidades. Es posible que un

proveedor de servicio tenga múltiples portafolios de servicio dependiendo en los

grupos de clientes que tenga.

Dentro del portafolio de servicios podemos encontrar estas tres categorías

diferentes:

25


Service Pipeline (servicios propuestos o en desarrollo).

Service Catalogue (servicios actuales o disponibles para el despliegue).

Servicios retirados (aquellos servicios que ya no se ofrecen).

Portafolio de servicios

Estado del servicio:

Definido

Analizado

Aprobado


Diseñado

Desarrollado

Construido

Probado

Desplegado

Operacional


Retirado

Service

pipeline

Catálogo

de servicios

Servicios

retirados

Ilustración 9: Catálogo de servicios

Para concluir el resumen de Service Strategy, remarcar que el resultado de Service

Strategy es crear valor. Históricamente proveedores y clientes han usado el precio como

el centro de la negociación, hecho que ha llevado constantemente experiencias negativas

para ambas partes. Para que cualquier proveedor de servicio actual triunfe, es esencial

establecer el valor antes de ponerle un precio al servicio. En ITIL, se define valor como la

suma de la utilidad y la garantía:

26


Utilidad

Garantía

VALOR

¿Preparado

para usarse?

¿Preparado

para su

propósito?

¿Suficientemente disponible?

¿Suficientemente capaz?

¿Suficientemente continuo?

¿Suficientemente seguro?

¿Se soporta el rendimento?

¿Se han eliminado las restricciones?

Ilustración 10: El valor es la suma de la utilidad y la garantía

En la imagen inferior pueden observarse las relaciones que tiene Service Strategy con las

otras cuatro fases del ciclo de vida.

Service Strategy

Continual Service Improvement

Service Operation

Service Transition

Service Design

Métricas de proceso, KPIs, Portafolios de servicio

Presupuestos IT, Objetivos estratégicos, Portafolios de servicio, PBA

Criterios de validación de servicio, Prioridades y riesgos de IT, Portafolio de requisitos

Modelos de servicio para el soporte, Portafolios de servicio,

Estrategias de gestión de la demanda, Presupuestos de IT

Ilustración 11: Relación de Service Strategy con las otras fases del ciclo de vida

27


2.3.2 SERVICE DESIGN

Requisitos

Políticas

El negocio

Los clientes

Service Strategy

Estrategias



Arquitecturas

Service Design

Soluciones de diseño

SDPs

Estándares

Ilustración 12: Relación de Service Design con Service Strategy

Service Design (diseño de servicios) es la etapa en el ciclo de vida de los servicios en la

cual se desarrolla un servicio nuevo o modificado y se prepara para la etapa de Service

Transition (transición de servicios). El objetivo principal de esta etapa es el diseño y

desarrollo del servicio. Esto incluye la definición de los requerimientos del servicio, el

diseño de una solución de servicio, evaluación de los proveedores alternativos y la

integración de los “activos de los servicios” en el servicio. Service Level Management

(Gestión del nivel de servicio) provee la interfaz a los clientes de IT en la recolección de

requisitos. Procesos de soporte como Availabilty Management, Capacity Management,

Information Security Management e IT Service Continuity Management se consultan

para asegurarse que el servicio estará a la altura.

Mientras el servicio progresa a través de esta etapa, el Service Catalog (catálogo de

servicios) se actualiza con la nueva información sobre el servicio, incluyendo cambios de

estatus en el servicio. Service Catalog es aquella parte del Service Portfolio que puede

ser visto por los clientes de IT. También es un instrumento de Service Level

28


Management para discutir con los clientes de IT sobre los nuevos requerimientos de

servicio.

El objetivo principal en el diseño de un servicio (nuevo o modificado) es satisfacer los

requisitos del negocio. Cada vez que se produce una nueva solución debe comprobarse

que se integrará y comunicará con los otros servicios existentes dentro de Service

Portfolio.

Capacity

Management

Information

Security

Management

IT Service

Continuity

Management

Availability

Management

Gestión de los proveedores

Definir

requisitos

Diseñar

soluciones

Evaluar

Soluciones

alternativas

Procurar

solución

Desarrollar

solución

Gestión del catálogo de servicios

Gestión del catálogo de servicios

Procesos de soporte

Garantía

Utilidad

Diseño

Ilustración 13: Relación entre los componentes de Service Design. Fuente: ITIL Version 3 at a Glance

Dentro de Service Design, pueden encontrarse los siguientes procesos:

1. Service Catalog Mangement (Gestión del Catálogo de Servicios)

Este proceso tiene como propósito proveer y gestionar un catálogo altamente

accesible de servicios de IT. Este catálogo debe estar permanentemente

mantenido y actualizado para garantizar que siempre contiene la información

correcta de aquellos servicios que se ofrecen actualmente. El catálogo de

servicios forma parte del portafolio de servicios y contiene dos partes: Catálogo

de servicios de negocio (orientad al cliente) y catálogo de servicios técnicos (para

29


uso interno, con lenguaje sencillo).

2. Service Level Management (Gestión del Nivel de Servicio)

Este proceso tiene como propósito asegurarse de que se provee el nivel de

servicio acordado a los clientes de IT. Asimismo, busca de manera proactiva e

implementa mejoras en los niveles de servicio entregados a clientes y usuarios.

3. Capacity Management (Gestión de la Capacidad)

La finalidad de este proceso es asegurar que existe una capacidad en todas las

áreas de IT justificable en coste y que satisface las necesidades actuales y futuras

del negocio. En resumen, trata de encontrar el balance entre recursos disponibles

y demanda.

4. Availability Management (Gestión de la disponibilidad)

Este proceso tiene como objetivo asegura que el nivel de servicio entregado en

todos los servicios satisface o supera las necesidades actuales y futuras del

negocio, siempre teniendo en cuenta el coste/beneficio.

5. IT Service Continuity Management (Gestión de la continuidad del Servicio de IT)

El objetivo de este proceso es asegurarse que los servicios de IT continuarán su

operación de acuerdo a un plan acordado. Este proceso asegurará que tras un

desastre, la infraestructura y los servicios IT podrán recuperarse dentro de un

marco de tiempo acordado.

6. Information Security Management (Gestión de la Seguridad de la Información)

Este proceso tiene como propósito alinear la seguridad de IT con la seguridad del

negocio, así como asegurarse de que la seguridad de la información se gestiona

de manera apropiada en todos los servicios y actividades de gestión de los

servicios.

7. Supplier Management (Gestión de los Proveedores)

El objetivo de este proceso es gestionar los proveedores de servicio para apoyar

los objetivos de niveles de servicio.

30


Asimismo, dentro de Service Design, pueden encontrarse otras prácticas:

1. Gestión de las aplicaciones

Gestiona el control de las aplicaciones a lo largo de todo su ciclo de vida, desde la

creación hasta su final y soporta procesos de negocio diseñando y manteniendo

aplicaciones para asistir a la entrega del servicio. Entre otras funciones, se tiene

que decidir si comprar o desarrollar software e identificar qué requisitos son

necesarios para mantener las aplicaciones.

2. Gestión de los datos y la información

Control, organización y disposición de los datos e información dentro de la

organización.

3. Diseño

Se explica la definición de un servicio de IT basado en los requisitos, diseño del

servicio e identificación, implementación del servicio para cumplir esos

requisitos.

4. Ingeniería de requerimientos

Se muestra la disciplina de coleccionar, organizar y priorizar los requisitos para

diseñar un CI (Configuration Item) o servicio.

5. Gestión del portafolio de servicios

Gestión de la lista de los servicios planificados, existentes y retirados.

Para más información sobre Service Design, se recomienda consultar [OGC07c].

31


2.3.3 SERVICE TRANSITION

Requisitos

Políticas

El negocio

Los clientes

Service Strategy

Estrategias



Arquitecturas

Service Design


SDPs

Estándares

Soluciones comprobadas

Service Transition

Planes de transición

SKMS

Ilustración 14: Relación de Service Transition con Service Design y Service Strategy. Fuente: OGC

Esta etapa prepara un servicio nuevo o modificado para que comience a estar operativo.

La actividad primaria que se realiza durante esta etapa es Transition Planning and

Support (la planificación y soporte de la transición).

Es probable que haya un gran número de RFC3 que llevarán a cabo los cambios (Change

Management – gestión de cambios) y de despliegue (Release and Deployment

Management – gestión de lanzamientos y despliegues).

Antes de mover un servicio a producción, debe haber un período de pruebas y validación

del servicio para asegurar su calidad. Para garantizar esta calidad, se utiliza un marco de

evaluación con el fin de determinar si un servicio está en un estado aceptable o si debe

3 Request for Change (petición de cambio)

32


ser modificado de alguna manera.

Mientras el servicio se prepara para producción, muchos activos e ítems de

configuración deben ser ensamblados y preparados. Debe guardarse una información

completa de todos estos ítems de configuración y activos, así como las relaciones entre

todos estos elementos.

Gestión de la

configuración

Configuración de

activos

Evaluación

Validación de servicio

y pruebas

Planificación y soporte de la transición

Procesos de información

Procesos de soporte

Gestión del lanzamiento

y despliegue

Gestión

De cambios

Gestión del

conocimiento

Gestión de la configuración y de activos de servicio

Ilustración 15: Componentes de Service Transition

Pueden encontrarse los siguientes procesos dentro de Service Transition:

1. Service Asset and Configuration Management

El objetivo de este servicio es controlar y monitorizar todos los CI para asegurar

la integridad.

2. Change Management (Gestión de cambios)

El objetivo de este servicio es gestionar todos los cambios en la infraestructura de

IT de una manera controlada.

Los cambios pueden surgir por varios motivos:

33


Proactivamente: Al buscar beneficios para el negocio (al reducir costes,

mejorar el servicio, mejorar la sencillez del soporte del servicio, etc.)

Reactivamente: Al resolver errores y adaptarse a las circunstancias

cambiantes.

Y los cambios deben ser gestionados para:

1. minimizar la exposición al riesgo

2. minimizar la severidad de cualquier impacto

3. acertar en el primer intento

Petición de

cambio

(RFC)

Cambio

guardado

Cambio

Cambio

`

Workstation

Ilustración 16: Esquema del proceso de un cambio en ITIL

3. Release and Deployment Management (Gestión del lanzamiento y despliegue)

El objetivo es construir, probar y entregar la capacidad de proveer los servicios

especificados por Service Design, así como cumplir los requisitos de los

stakeholders y conseguir los objetivos deseados.

4. Service Validation and Testing (Pruebas y validación del servicio)

El objetivo es asegurarse que un servicio nuevo o modificado mantendrá los

requisitos del cliente y que será útil para su propósito.

34


5. Transition Planning and Support (Soporte y planificación de la transición)

El objetivo de este servicio es planificar transiciones de servicio que aparecen en

cada etapa de un ciclo de vida de un servicio.

6. Knowledge Management (Gestión del conocimiento)

El objetivo es asegurarse de que la información correcta se provee a los roles

adecuados en el momento correcto.

Asimismo, dentro de Service Transition, se encuentran otras prácticas de menor

importancia:

1. Communications and Commitment Management

Práctica de proveer una comunicación efectiva a todas las partes afectadas en un

cambio

2. Organizational and Stakeholder Change Management

La práctica de gestionar procesos y cambios de cultura entre los stakeholders de

IT.

3. Stakeholder Management

La práctica de solucionar las necesidades y preocupaciones de los stakeholders

de los servicios de IT.

Para más información sobre Service Transition, se recomienda leer [OGC07d].

35


2.3.4 SERVICE OPERATION

Requisitos

Políticas

El negocio

Los clientes

Service Strategy

Estrategias



Arquitecturas

Service Design


SDPs

Estándares

Soluciones comprobadas

Service Transition


SKMS

Service Operation Servicios Operacionales

Ilustración 17: Relación de Service Operation con otros procesos de ITIL. Fuente:OGC

Durante esta etapa, el servicio se pone a disposición de IT y de los usuarios. Durante la

ejecución del servicio, éste se monitoriza para determinar los niveles de servicio, así

como para encontrar fallos operacionales. Estos últimos pueden aparecer como eventos

en la monitorización del servicio.

Los fallos que se encuentren cuando un servicio está en operación, pueden ser resueltos

en Event Management o podrían tener que ser escalados a Incident Management para

que sean resueltos por el personal del Service Desk. En cualquier caso, el evento se

guarda como una incidencia y el servicio se restaurará lo antes posible mediante un

workaround o otra solución.

Los fallos pueden ser detectados por los usuarios, que pueden contactar con el Service

Desk para comunicarles el fallo. El proceso de Incident Management se utiliza por el

Service Desk para restaurar el servicio lo antes posible.

Problem Management (gestión de problemas) apoya a Incident Management al buscar

36


patrones de incidentes y resolviendo las causas raíz de esos problemas. Este proceso

también busca proactivamente fallos no identificados previamente.

Los usuarios también pueden simplemente contactar con el Service Desk para llevar a

cabo acciones exentas de riesgo (service requests) que no pueden ser llevadas a cabo

por los usuarios o para solicitar acceso a servicios o activos de servicio (Access

Management).

Incident

Management

Problem

Management

Request

Fulfillment

Access

Management

Monitorización y control

Event

Management

Usuario

Service Desk

Ilustración 18: Relación entre las distintas partes de Service Operation

Los siguientes procesos forman parte de Service Operation:

1. Event Management (gestión de eventos)

El propósito de este proceso es identificar y resolver eventos de sistema que

representan fallos dentro de los ítems de configuración.

2. Incident Management (gestión de incidencias)

El propósito de este proceso es resolver todas las incidencias (incluyendo fallos,

preguntas reportadas por los usuarios o el personal técnico, o que hayan sido

detectadas de manera automática por herramientas de monitorización de

eventos).

37


3. Request Fulfillment

Este proceso tiene el propósito de procesar peticiones de servicio y peticiones de

información. Los servicios relacionados con los accesos los procesa Access

Management.

Este es un proceso crítico para el servicio al cliente. Los clientes pueden querer

utilizar los productos y/o servicios de una organización, pero si no hay un

proceso en funcionamiento para que los clientes expresen sus peticiones, la

organización no podrá satisfacerlas. ITIL realiza un fuerte énfasis en este proceso.

Cuando un cliente (potencial o actual) accede al catálogo de servicios, debería ser

capaz de utilizar el proceso de request fulfillment para adquirir los servicios a

través del catalogo de servicios directamente. Es importante remarcar que el

catálogo de servicios es únicamente una parte del portafolio de servicios de una

organización, pero es la que los clientes ven:

Service Knowledge Management System

Service Portfolio

(portafolio de servicios)

Service Pipeline

Servicios retirados

Catálogo de servicios

Parte vista

por los clientes


Definido

Analizado

Aprobado

Diseñado

Desarrollado

Construido

En pruebas

Desplegado

Operacional

Retirado

Ilustración 19: Sistema de gestión de conocimiento del servicio.

4. Problem Management (gestión de problemas)

El objetivo de este proceso es diagnosticar las causas raíces de los incidentes,

solicitar cambios que resolverán esas causas raíz y reducir el número de futuros

incidentes.

38


Problem Management es responsable de asegurar que la resolución de cada

problema se implementa a través de los procedimientos de control apropiados,

especialmente Gestión del Cambio y Gestión de Lanzamientos.

Asimismo, este proceso también mantiene información sobre los problemas y los

workarounds y resoluciones apropiados en cada situación, de manera que la

organización sea capaz de reducir el número e impacto de las incidencias a lo

largo del tiempo. Hay que destacar la fuerte relación que tiene este proceso con

Gestión del Conocimiento y herramientas como la Known Error Database, ya que

ambos la utilizan. También hay una gran relación entre Incident Management y

Problem Management, ya que utilizan las mismas herramientas y los mismos

sistemas de categorización, impacto y prioridad.

Este proceso añade mucho valor al negocio, ya que, al identificar soluciones

permanentes para los problemas, se reduce el número y tiempo de resolución de

las incidencias. Y esto lleva a un mayor tiempo de servicio y al buen

funcionamiento de sistemas críticos para el negocio.

5. Access Management (gestión de acceso)

El objetivo de este proceso es proveer los permisos adecuados a cada usuario de

un servicio. En muchas organizaciones se conoce a este proceso como Gestión de

Derechos o Gestión de Identidades.

Este procedimiento ejecuta las políticas y acciones definidas en Gestión de la

Seguridad y Gestión de la Disponibilidad. Permite a las organizaciones gestionar

la confidencialidad, disponibilidad e integridad de sus datos y propiedad

intelectual.

De menor importancia, en Service Operation también están presentes otras prácticas:

1. Facilities and Data Center Management

Gestión de la localización física donde se guardan los recursos de IT,

normalmente Data Centers.

39


2. Information Security Management and Service Operation

Aplicación de la política de seguridad durante las operaciones de servicio.

3. IT Operations

Operación y gestión de tipos específicos de recursos de tecnología. El apoyo para

estos recursos requiere pericia en diferentes ámbitos, como pueden ser

Mainframe Management, Server Management and Support, Network

Management, etc.

4. Monitoring and Control

Monitorización del ciclo de servicio y respuesta.

Para más información puede consultarse [OGC07e].

40


2.3.5 CONTINUAL SERVICE IMPROVEMENT

Requisitos

Políticas

El negocio

Los clientes

Service Strategy

Estrategias

Objetivos de los

requisitosRequisitos y

restricciones

Arquitecturas

Service Design


SDPs

Estándares

Soluciones

comprobadas

Service Transition


SKMS

Service Operation

Servicios Operacionales

Continual

Service Improvement

Planes y acciones

de mejora

Ilustración 20: Relación de CSI con los otros procesos de ITIL. Fuente: OGC

Durante esta etapa, la se recopilan datos y opiniones de los usuarios, clientes,

stakeholders, etc. para mejorar los servicios y su provisión. Para ello, se utiliza un

proceso de mejora en siete pasos que recoge datos, los analiza, ofrece recomendaciones

y las implementa.

Como apoyo para el proceso de mejora, Service Level Management recoge información

de los usuarios de IT y clientes y datos de la operación de los servicios. Finalmente,

todas las mejoras del servicio deben ser inspeccionadas para comprobar que satisfacen

las necesidades del negocio y proveen un retorno sobre la inversión.

El factor crítico de éxito para que Continual Service Improvement (CSI) tenga éxito es la

habilidad que la organización tenga para adoptar, implementar y mantener una cultura

de mejora contínua.

41


Identificar:

Visión, Estrategia, Objetivos Tácticos y

Objetivos Operativos

7. Implementar acciones correctivas

Identificar:



5. Analizar las relaciones entre los

datos. ¿Va todo de acuerdo al plan?

¿Se cumplen los objetivos? ¿Hay que

tomar alguna acción correctiva?

Identificar:



6. Presentar y usar la información,

planes de acción, etc.

4. Procesar los datos

¿Qué frecuencia tienen? ¿Qué formato?

3. Recoger los datos

¿Cómo? ¿Cuándo? ¿Quién?

Verificar la integridad de los datos

2. Definir qué puede medirse

1. Definir qué debería medirse

Objetivos

Ilustración 21: Proceso de mejora en siete pasos. Fuente: The business of IT.

En la imagen superior puede verse el mencionado proceso de mejora en siete pasos.

Para más información puede consultarse [OGC07f].

42


2.4 FUNCIONAMIENTO DEL CICLO DE VIDA DEL SERVICIO

Las cinco fases previamente definidas no están separadas, ni han de llevarse a cabo en

un orden particular. Cada fase afecta a las otras de forma que todas se afectan

mutuamente, formando un ciclo continuo. En la imagen siguiente puede verse cómo cada

fase alimenta a la siguiente y cómo se retroalimentan todas con el proceso de mejora

continua.

Service Strategy

Service Design

Service Transition

Service Operation

Continual Service

Improvement

Presupuestos de IT

Patrones de actividad de negocio

Información del portafolio de

servicios

Activos de negocio nuevos y modificados

Catálogo de servicio, SLAs, OLAs, Ucs

Criterios para pruebas y validaciones

Errores conocidos del desarrollo

Resultados de pruebas y validación

Autorización de cambios

Incidentes y problemas, eventos, solicitudes de servicio

Petición de cambio

Información proveniente de la monitorización de

infrastructuras

Mejoras de servicios y procesos

Ilustración 22: Funcionamiento del ciclo de vida del servicio

43


2.5 VENTAJAS E INCONVENIENTES DE ITIL PARA LOS CLIENTES Y LAS

ORGANIZACIONES

Kemmerling y Addy [KEMM04] listan las principales ventajas de ITIL para el

cliente/usuario, así como para la organización. También hablan de los problemas

potenciales que tiene la implantación de ITIL:

Ventajas de ITIL para el cliente/usuario:

La provisión de servicios de TI se orienta más al cliente y los acuerdos sobre la

calidad del servicio mejoran la relación entre el departamento de TI y el cliente

Se describen mejor los servicios, en un lenguaje más cómodo para el cliente, y con

mayor nivel de detalle.

Se manejan mejor la calidad y el coste del servicio

Mejora la comunicación con la organización de TI al acordar los puntos de

contacto.

Ventajas de ITIL para la organización:

La organización TI desarrolla una estructura más clara, se vuelve más eficaz y se

centra más en los objetivos corporativos.

La dirección tiene más control y los cambios resultan más fáciles de manejar.

Una estructura de proceso eficaz brinda un marco para concretar de manera más

adecuada la externalización de algunos de los elementos de los servicios de TI.

Seguir las mejores prácticas de ITIL alienta el cambio cultural hacia la provisión

de servicios y sustenta la introducción de un sistema de gestión de calidad

basado en las series ISO 9000.

ITIL establece un marco de referencia para la comunicación interna y la

comunicación con los proveedores, así como la estandarización y la identificación

de procedimientos.

44


Argumentos a favor de ITIL:

Enfoque estructurado: ITIL cubre todas las grandes áreas que conciernen a la

dirección de IT y debido a su enfoque estructurado y sistemático se asegura a la

dirección responsable de una mala organización de IT, que implementar ITIL

sentará, cuanto menos, las bases.

Buena base desde donde continuar: ITIL es un excelente punto de partida desde

donde construir el sistema de gestión de servicios de IT.

Puede usarse para ayudar a preservar pérdidas de conocimiento en la

organización: Al documentar todos los procesos y requisitos para todas las

actividades realizadas por IT, la marcha de empleados clave no será tan dañina

para la organización.

Naturaleza prescriptiva: Debido a esto no es necesario pensar demasiado. ITIL

ayuda a no tener que pensar cada situación y utilizar el juicio personal para

gestionar la organización.

Requiere que la gestión de IT revise de manera formal todos los procesos

desarrollados por sus equipos:. Esta profunda revisión ayuda a que los altos

cargos se involucren en todos los aspectos del negocio.

Terminología definida: Un uso consistente de terminología definida a través de

toda la industria promueve el entendimiento y simplifica la comunicación.

Probablemente éste sea uno de los mayores beneficios de ITIL.

Flexibilidad: Debido a que ITIL no es un marco de trabajo rígido, permite a las

organizaciones operar de maneras diferentes, manteniendo a su vez las

directrices generales de ITIL.

Problemas potenciales de ITIL y argumentos en contra:

Su introducción puede llevar tiempo y bastante esfuerzo, y supone un cambio de

cultura en la organización. Una introducción demasiado ambiciosa puede llevar a

la frustración porque nunca se alcanzan los objetivos.

45


Si la estructura de procesos se convierte en un objetivo en sí misma, la calidad del

servicio se puede ver afectada de forma adversa. En ese caso, los procedimientos

se transforman en obstáculos burocráticos que tratan de evitarse en lo posible. Si

ITIL se convirtiese en un fin en sí mismo implicaría que la mejora de servicios,

fiabilidad y satisfacción del usuario, pasarían a un segundo lugar.

Puede no haber progreso si existe falta de comprensión sobre lo que deben

proporcionar los procesos, cuáles son los indicadores de rendimiento y cómo se

controlan los procesos.

No se ven las reducciones de coste y la mejora en la provisión de los servicios.

Una implantación de éxito implica el compromiso del personal de todos los

niveles de la organización. Dejar el desarrollo de las estructuras de proceso a un

departamento de especialistas puede aislar al departamento de la organización y

puede fijar una dirección no aceptada por los otros departamentos.

Si hay poca inversión en las herramientas de soporte, los procesos pueden no

funcionar adecuadamente y el servicio no mejorará. Se pueden necesitar más

recursos y más personal si la organización se encuentra sobrecargada con las

actividades de rutina de la Gestión de Servicios de TI.

Reprime la creatividad: El hecho de que ITIL se sostenga sobre un marco de

trabajo de procesos de negocio implica que aquellos que lo implementen no

tendrán que pasar por las fases de desarrollo por ellos mismos. Aunque esto

suponga un gran ahorro de tiempo, también cohíbe la aparición de alguna

solución innovativa o creativa.

Añadir procesos ITIL a una infraestructura caótica de IT probablemente empeore

las cosas en lugar de mejorarla.

Carencia de estudios serios sobre la eficiencia y el valor de ITIL: Hasta la fecha no

ha habido ningún estudio a gran escala que identifique y pruebe los beneficios

que afirma ofrecer ITIL.

Seguir las “mejores prácticas” por definición implica “estar en la media”: Si todas

las organizaciones aceptasen ITIL y todos tuvieran “lo mejor” entonces “lo mejor”

se convierte en la media. A menos de que las organizaciones revisen

46


continuamente sus procesos y los mejoren para conseguir mejores resultados,

mayor nivel de servicio o menores costes, pronto estarán detrás de las demás

organizaciones (detrás de la media).

Crea barreras entre grupos funcionales: Las distinciones entre problemas e

incidentes marcados en ITIL no hacen más que empeorar las relaciones

intradepartamentales de las empresas. Existe un riesgo real de que las

organizaciones sólo se dediquen a resolver incidentes y no dediquen tiempo y/o

recursos a la resolución de problemas.

Falta de detalle en algunas áreas y exceso en otras: Probablemente la

participación de múltiples autores en la edición de ITIL sea la causa de que

ciertas áreas sean mucho más explícitas que otras.

47


2.6 GRUPOS DE TRABAJO QUE POTENCIAN ITIL

Actualmente existen un gran número de grupos que potencian ITIL en todo el mundo.

Caben destacar los siguientes:

2.6.1 ITSMF

Esta organización se autodefine como “Organización internacional independiente

reconocida, dedicada a la gestión de servicios de TI, que ejerce una gran influencia en el

desarrollo y promoción de un código estandarizado de mejores prácticas mundiales en

este ámbito y trabaja con un gran abanico de organismos gubernamentales.”

El itSMF es una red mundial de grupos de usuarios de IT que ofrecen las mejores

prácticas y guías basadas en estándares para la provisión de servicios de IT sin

compromisos con ningún proveedor. Trabaja en asociación con la OGC, el BSI, ISEB y

EXIN.

Ilustración 23: Logo de itSMF

2.6.2 OGC (CCTA)

OGC son las siglas de “Office of Government Commerce”, cuya traducción a castellano

quedaría como Oficina de Comercio del Gobierno (Británico). Es una oficina

independiente del Ministerio del Tesoro de Su Majestad del Reino Unido, que se

estableció para ayudar al gobierno a conseguir el máximo valor posible con sus

inversiones. La OGC trabaja con el gobierno central del Reino Unido, junto con otras

organizaciones del sector público para cumplir 6 objetivos básicos:

1. Entregar valor por dinero conseguido por terceras partes.

48


2. Entrega de proyectos para conseguir beneficios de tiempo, calidad y coste.

3. Maximizar el valor conseguido de los 30.000 millones de libras esterlinas

4. Ayudar a la sostenibilidad del gobierno y sus operaciones, incluyendo la

reducción de emisiones de CO2 en un 11.5% para 2011, a través de una mayor

gestión del rendimiento.

5. Ayudar a conseguir la entrega de futuras políticas del Gobierno

6. Mover la mejora de la capacidad del gobierno central en pagos, gestión de

proyectos y programas y gestión del estado a través del desarrollo de las

habilidades de las personas, procesos y herramientas.

La OGC es un patrocinador de mejores prácticas para gestión de proyectos, gestión del

riesgo y gestión de servicios. En gestión de servicios, es el patrocinador de ITIL

Ilustración 24: Logo de la OGC

2.6.3 EXIN

EXIN son las siglas de ExamenInstitut voor Informatica. Es una organización global e

independiente dedicada a proveer programas de certificación para: ISO 20000, ISO

27000, ITIL, MOF, ASL, BISL, TMAP y SCP.

Ilustración 25: Logo de EXIN

49


2.6.4 ISEB

ISEB son las siglas de Information Systems Examination Board. Es el cuerpo encargado

de los exámenes y parte de BCS, el instituto de IT. Inicialmente comenzó como un

acuerdo de colaboración entre el NCC (National Computing Centre) y BCS para la

creación de una certificación en análisis y diseño de sistemas para el entonces existente

SAEB (Systems Analysis Examination Board). En 1989 se desarrolló una nueva

cualificación en gestión de proyectos, lo que supuso el inicio de la expansión del

portafolio de certificaciones del SAEB. Esto provocó que se decidiese cambiar el nombre

de SAEB a ISEB.

Actualmente, ISEB provee cualificaciones en 8 grandes áreas de IT:

ITIL, pruebas de software, TI sostenible, análisis de negocio, desarrollo de sistemas,

gestión y soporte de proyectos, gobierno de IT, información de seguridad y los activos e

infraestructura de IT.

Ilustración 26: Logo de ISEB

50


3. ISACA

51


3.1 INTRODUCCIÓN A ISACA

ISACA son las siglas de Information Systems Audit and Control Association (Asociación

para la Auditoría y Control de Sistemas de Información). Esta asociación comenzó en

1967, cuando un pequeño grupo de personas con trabajos similares (controles de

auditoría en los sistemas computarizados que se estaban haciendo cada vez más críticos

para las operaciones de sus organizaciones respectivas) se sentaron a discutir la

necesidad de tener una fuente centralizada de información y guía en dicho campo. Se

fundó en 1969 y a día de hoy dispone de más de 86.000 miembros en más de 160 países.

Esta asociación es un líder reconocido en todo el mundo, que provee conocimiento,

comunidad y educación en seguridad y aseguramiento en sistemas de información.,

gobierno empresarial de TI y riesgos y cumplimiento relacionados con la TI. Los

miembros cubren una gran variedad de puestos profesionales relacionados con TI y

trabajan en casi todas la categorías de industrias. Uno de los puntos fuertes de ISACA es

su red de lo que ellos llaman capítulos (que pueden entenderse como delegaciones).

ISACA tiene capítulos en más de 70 países en todo el mundo, y dichos capítulos brindan

a sus miembros educación, recursos compartidos, promoción, etc.

El IT Governance Institute (Instituto de Gobierno de TI) es un organismo independiente

de investigación, sin fines de lucro, que provee una guía para la comunidad global de

negocios en asuntos relacionados con el gobierno de los activos de TI. Este instituto fue

establecido por ISACA en 1988 y ha creado COBIT, un conjunto de mejores prácticas

para el manejo de la información (COBIT es Control Objectives for Information and

related Technology).

COBIT apareció por primera vez en 1996 y recientemente ha sido publicada la última

versión, denominada 4.1. En esta última versión, COBIT tiene 34 objetivos de alto nivel

que cubren 318 objetivos de control clasificados en cuatro dominios: Planificación y

Organización, Adquisición e Implementación, Entrega y Soporte y Supervisión y

Evaluación.

COBIT 4 proporciona un marco de trabajo práctico por medio de procesos y dominios

que ayuda y sustenta al gobierno de IT proporcionando un marco de referencia que

asegure que:

52


IT esté alineada con el negocio.

Las TIC posibiliten la realización de la actividad del negocio al mismo tiempo

que contribuyen a la maximización de los beneficios.

Los recursos de IT (humanos y técnicos) son utilizados de forma responsable.

Los riesgos de IT son gestionados y dirigidos adecuadamente.

La gran ventaja de COBIT es su estructuración o esquema de presentación.

Simultáneamente puede visualizarse y tenerse una guía para algo tan importante para el

control interno como es la interrelación entre los objetivos de control de alto nivel y de

detalle, según su agrupación por actividades y según los requerimientos para estos

controles. Los controles internos constituyen un sistema que debe relacionarlos siempre

entre sí, en cuanto a sus objetivos, eficiencia y complementariedad en la mitigación de

riesgos, evitando su consideración aislada. Cualquier consideración aislada de los

controles distorsiona la utilidad y resultados de un proceso de análisis y evaluación de

riesgos.

Ilustración 27: Logo de ISACA

53


3.2 COBIT 4.1

COBIT se define como un compendio de buenas prácticas a través de un marco de

trabajo de dominios y procesos, que presenta las actividades en una estructura

manejable y lógica. Estas buenas prácticas están enfocadas fuertemente en el control y

menos en la ejecución.

El enfoque hacia procesos de COBIT se ilustra con un modelo de procesos, el cual

subdivide a TI en 34 procesos de acuerdo a las áreas de responsabilidad de planificar,

construir, ejecutar y monitorizar, ofreciendo una visión global de TI.

COBIT hace uso de tres conceptos:

1. Benchmarking de la capacidad de procesos de TI, expresada como modelos de

madurez, derivados del Modelo de Madurez de la Capacidad del Instituto de Ingeniería

del Software

2. Metas y métricas de los procesos de TI para definir y medir sus resultados y su

desempeño, basados en los Balanced Scorecard de Kaplan y Norton

3. Metas de actividades para controlar estos procesos, en base en los objetivos de control

detallados de COBIT.

COBIT da soporte al gobierno de TI al brindar un marco de trabajo que garantiza que:

TI está alineada con el negocio

TI habilita al negocio y maximiza los beneficios

Los recursos de TI se usan de manera responsable

Los riesgos de TI se administran apropiadamente

Todos los componentes de COBIT se relacionan, ofreciendo soporte para las necesidades

de gobierno, de administración, de control y de auditoría de los distintos interesados,

como puede verse en la figura siguiente:

54


Ilustración 28: Interrelaciones entre los componentes de COBIT. Fuente: COBIT 4.1

COBIT es un marco de referencia y un juego de herramientas de soporte que permiten a

la gerencia cerrar la brecha con respecto a los requerimientos de control, temas técnicos

y riesgos de negocio y comunicar ese nivel de control a los stakeholders. Los beneficios

de implantar COBIT como marco de referencia de gobierno sobre IT incluyen:

Mejor alineación, con base al enfoque de gerencia

Una visión, entendible para la gerencia, de lo que hace TI

Propiedad y responsabilidades claras, con base en su orientación de procesos

Aceptación general de terceros y reguladores

Entendimiento compartido entre todos los interesados, con lenguaje común.

A continuación, se explicará de una manera breve el marco de trabajo de COBIT, así

como todos los componentes esenciales organizados por los dominios de TI de COBIT y

los 34 procesos de TI.

55


3.2.1 MARCO DE TRABAJO DE COBIT 4.1

COBIT establece como su misión “Investigar, desarrollar, hacer público y promover un

marco de control de gobierno de TI autorizado, actualizado, aceptado

internacionalmente para la adopción por parte de las empresas y uso diario por parte de

los gerentes de negocio, profesionales de TI y profesionales de aseguramiento”.

Según ISACA, un marco de referencia de gobierno y control requiere servir a una

variedad de personal interno y externo a una organización, cada uno de los cuales tiene

necesidades específicas:

Interesados dentro de la empresa que tienen interés en generar valor de las

inversiones de TI

Interesados internos y externos que proporcionan servicios de TI

Interesados internos y externos con responsabilidades de control y riesgo

Un marco de referencia para el gobierno y control de TI, debe satisfacer las siguientes

especificaciones generales:

Brindar un enfoque de negocios que permita la alineación entre las metas de

negocio y TI

Establecer una orientación a procesos para definir el alcance y grado de

cobertura, con una estructura definida que permita una fácil navegación en el

contenido.

Ser generalmente aceptable al ser consistente con las mejores prácticas y

estándares de TI aceptados, y que se independiente de tecnologías específicas.

Proporcionar un lenguaje común, con un juego de términos y definiciones que

sean comprensibles en general para todos los interesados.

Ayudar a satisfacer requerimientos regulatorios, al ser consistente con

estándares de gobierno corporativo generalmente aceptados y con controles de

TI.

56


Como respuesta a loas necesidades descritas, COBIT se creó con las características

principales de ser orientado a negocios, orientado a procesos, basado en controles

impulsado por mediciones.

La orientación al negocio es el tema principal de COBIT. Está diseñado para ser utilizado

no sólo por proveedores de servicios, sino también y principalmente, como guía integral

para la gerencia y para los dueños de los procesos de negocio. El marco general de

COBIT puede verse en el gráfico siguiente:

Ilustración 29: Principio básico de COBIT. Fuente: COBIT 4.1

Para proporcionar la información que la empresa requiere para lograr sus objetivos, la

empresa requiere invertir en, y administrar y controlar los recursos de TI usando un

conjunto estructurado de procesos que provean los servicios que entregan la

información empresarial requerida.

El marco de trabajo COBIT ofrece herramientas para garantizar la alineación con los

requerimientos del negocio.

Están definidos siete criterios de información:

1. La efectividad tiene que ver con que la información sea relevante y pertinente a

los procesos del negocio, y se proporcione de una manera oportuna, correcta,

consistente y utilizable.

57


2. La eficiencia consiste en que la información sea generada con el óptimo de los

recursos

3. La confidencialidad se refiere a la protección de información sensible contra

revelaciones no autorizadas.

4. La integridad está relacionada con la precisión y completitud de la información,

así como su validez de acuerdo a los valores y expectativas del negocio.

5. La disponibilidad se refiere a que la información esté disponible cuando sea

requerida por los procesos del negocio en cualquier momento. También

concierne a la protección de los recursos y las capacidades necesarias asociadas.

6. El cumplimiento tiene que ver con acatar aquellas leyes, reglamentos y acuerdos

contractuales a los cuales está sujeto el proceso de negocios.

7. La confiabilidad se refiere a proporcionar la información apropiada para que la

gerencia administre la entidad y ejerza sus responsabilidades fiduciarias y de

gobierno.

Si se pretende que TI proporcione servicios de forma exitosa para dar soporte a la

estrategia de la empresa, debe existir una propiedad y una dirección clara de los

requerimientos por parte del negocio (el cliente) y un claro entendimiento para TI, de

cómo y qué debe entregar (el proveedor). Para que el cliente entienda las metas y los

Scorecard de TI, todos estos objetivos y sus métricas asociadas se deben expresar en

términos de negocio significativos para el cliente. Una vez que han sido definidas las

metas alineadas, éstas deben ser monitoreadas para garantizar que la entrega cumple

con todas las expectativas (logrado esto gracias a las métricas derivadas de las metas y

capturadas en el scorecard de TI). Para que el cliente pueda entender las metas de TI y el

scorecard de TI, todos estos objetivos y métricas asociadas deben expresarse en

términos de negocio significativos para el cliente.

Para responder a los requerimientos que el negocio tiene hacia TI, la empresa debe

invertir en los recursos requeridos para crear una capacidad técnica adecuada. Los

recursos de TI que se identifican en COBIT son:

Las aplicaciones incluyen tanto sistemas de usuario automatizados como

procedimientos manuales que procesan información.

58


La información son los datos en todas sus formas, de entrada, procesados y

generados por los sistemas de información, en cualquier forma en que sean

utilizados por el negocio

La infraestructura es la tecnología y las instalaciones que permiten el

procesamiento de las aplicaciones

Las personas son el personal requerido para planear, organizar, adquirir,

implementar, entregar, soportar, monitorizar y evaluar los sistemas y servicios

de información.

59


3.2.2 MODELO GENÉRICO DE PROCESOS DE COBIT 4.1

COBIT define todas las actividades de TI en un modelo genérico de procesos organizado

en cuatro dominios:

1. Planear y Organizar

Este dominio cubre las estrategias y las tácticas, y tiene que ver con identificar la

manera en que TI puede contribuir de la mejor manera al logro de los objetivos

del negocio.

PO1 Definir un Plan Estratégico de TI

PO2 Definir la Arquitectura de la Información

PO3 Determinar la Dirección Tecnológica

PO4 Definir los Procesos, Organización y Relaciones de TI

PO5 Administrar la Inversión en TI

PO6 Comunicar las Aspiraciones y la Dirección de la Gerencia

PO7 Administrar Recursos Humanos de TI

PO8 Administrar la Calidad

PO9 Evaluar y Administrar los Riesgos de TI

PO10 Administrar Proyectos

2. Adquirir e Implementar

Este dominio cubre las siguientes cuestiones. ¿Es probable que los nuevos

proyectos generen soluciones que satisfagan las necesidades del negocio? ¿Es

probable que los nuevos proyectos sean entregados a tiempo y dentro del

presupuesto? ¿Trabajarán adecuadamente los nuevos sistemas una vez sean

implantados? ¿Los cambios no afectarán a las operaciones actuales del negocio?

60


AI1 Identificar soluciones automatizadas

AI2 Adquirir y mantener software aplicativo

AI3 Adquirir y mantener infraestructura tecnológica

AI4 Facilitar la operación y el uso

AI5 Adquirir recursos de TI

AI6 Administrar cambios

AI7 Instalar y acreditar soluciones y cambios

3. Entregar y Dar Soporte

Este dominio cubre la entrega en sí de los servicios requeridos, lo que incluye la

prestación del servicio, la administración de la seguridad y de la continuidad, el

soporte del servicio a los usuarios, la administración de los datos y de las

instalaciones operativas.

DS1 Definir y administrar los niveles de servicio

DS2 Administrar los servicios de terceros

DS3 Administrar el desempeño y la capacidad

DS4 Garantizar la continuidad del servicio

DS5 Garantizar la seguridad de los sistemas

DS6 Identificar y asignar costos

DS7 Educar y entrenar a los usuarios

DS8 Administrar la mesa de servicio y los incidentes

DS9 Administrar la configuración

DS10 Administrar los problemas

DS11 Administrar los datos

61


DS12 Administrar el entorno físico

DS13 Administrar las operaciones

4. Monitorizar y evaluar

Todos los procesos de TI deben evaluarse de forma regular en el tiempo en

cuanto a su calidad y cumplimiento de los requerimientos de control.

ME1 Monitorizar y Evaluar el Desempeño de TI

ME2 Monitorizar y Evaluar el Control Interno

ME3 Garantizar el Cumplimiento Regulatorio

ME4 Proporcionar Gobierno de TI

Planear y Organizar

COBIT 4.1

Adquirir e Implementar Entregar y Dar Soporte Monitorizar y evaluar

Definir un Plán Estratégico de TI

Definir la Arquitectura de la

Información

Determinar la Dirección

Tecnológica

Definir los Procesos,

Organización y Relaciones de TI

Administrar la Inversión en TI

Comunicar las Aspiraciones y la

Dirección de la Gerencia

Administrar Recursos Humanos

de TI

Administrar la Calidad

Evaluar y Administrar los

Riesgos de TI

Administrar Proyectos

Identificar soluciones

automatizadas

Adquirir y mantener software

aplicativo

Adquirir y mantener

infraestructura tecnológica

Adquirir recursos de TI

Administrar cambios

Instalar y acreditar soluciones y

cambios

Facilitar la operación y el uso

Definir y administrar los niveles

de servicio

Administrar los servicios de

terceros

Administrar el desempeño y la

capacidad

Garantizar la seguridad de los

sistemas

Identificar y asignar costes

Educar y entrenar a los usuarios

Garantizar la continuidad del

servicio

Administrar la mesa de servicio y

los incidentes

Administrar la configuración

Administrar los datos

Administrar el ambiente físico

Administrar las operaciones

Administrar los problemas

Monitorizar y evaluar el

Desempeño de TI

Monitorizar y Evaluar el Control

Interno

Garantizar el Cumplimiento

Regulatorio

Proporcionar Gobierno de TI

Ilustración 30: Modelo genérico de procesos de COBIT organizado en cuatro dominios

62


COBIT ha identificado 34 procesos de TI generalmente usados y para cada uno de estos

34 procesos tiene un enlace a las metas de negocio y TI que soporta, información de

cómo se pueden medir las metas y quién es el responsable de ellas.

COBIT define objetivos de control para los 34 procesos, así como para el proceso general

y los controles de aplicación. El control puede definirse como las políticas,

procedimientos, prácticas y estructuras organizacionales diseñadas para brindar una

seguridad razonable que los objetivos de negocio se alcanzarán, y los eventos no

deseados serán prevenidos o detectados y corregidos.

La gerencia de operaciones usa los procesos para organizar y administrar las actividades

de TI en curso. COBIT brinda un modelo genérico de procesos que representa todos los

procesos que normalmente se encuentran en las funciones de TI, proporcionando un

modelo de referencia general y entendible para la gerencia de operaciones de TI y para

la gerencia de negocios. Para lograr un gobierno efectivo, los gerentes de operaciones

deben implementar los controles necesarios dentro de un marco de control definido

para todos los procesos de TI. Cada uno de los procesos de TI tiene un objetivo de

control de alto nivel y varios objetivos de control detallados. Los objetivos de control

detallados se identifican por dos caracteres que representan al dominio (Planear y

Organizar – PO, Adquirir e Implementar –AI, Entregar y dar Soporte – DS, Monitorizar y

Evaluar – ME) más un número de proceso y un número de objetivo de control. Además,

COBIT ofrece ejemplos ilustrativos para cada proceso:

Entradas y salidas genéricas

Actividades y guías sobre roles y responsabilidades en una matriz RACI

Metas de actividades clave

Métricas

Además de evaluar qué controles son requeridos, los dueños de los procesos deben

entender qué entradas requieren de otros procesos y qué requieren otros de sus

procesos.

El sistema de control interno afecta a tres niveles:

63


1. Dirección ejecutiva. Se fijan los objetivos de negocio, se establecen políticas y se

toman decisiones de cómo aplicar y administrar los recursos empresariales para

ejecutar la estrategia de la compañía.

2. Procesos de negocio. Se aplican controles para actividades específicas de negocio.

3. Actividades de servicio. TI proporciona servicios, por lo general de forma

compartida, por varios procesos de negocio, así como procesos operativos y de

desarrollo de TI que se proporcionan a toda la empresa, y mucha de la

infraestructura de TI provee un servicio común.

COBIT también intenta mostrar el estado de los sistemas de TI para decidir qué nivel de

administración y control debe proporcionar. Proporciona las siguientes herramientas:

1. Modelos de madurez que facilitan la evaluación por medio de benchmarking y la

identificación de las mejoras necesarias en la capacidad

2. Metas y mediciones de desempeño para los procesos de TI, que demuestran cómo

los procesos satisfacen las necesidades del negocio y de TI (balanced scorecard).

3. Metas de actividades para facilitar el desempeño efectivo de los procesos.

Modelos de madurez

Los modelos de madurez para la administración y el control de los procesos de TI se

basan en un método de evaluación de la organización, de tal forma que se pueda evaluar

a sí misma desde un nivel no existente (0) hasta un nivel optimizado (5). Para más

información puede verse el apartado 11.1 de este proyecto. Los niveles de madurez

están diseñados como perfiles de procesos de TI que una empresa reconocería como

descripciones de estados posibles y futuros. Utilizando los modelos de madurez

desarrollados para cada uno de los 34 procesos TI de COBIT, la gerencia podrá

identificar el desempeño real de la empresa, el estatus actual de la industria, el objetivo

de mejora de la empresa y el crecimiento requerido entre “cómo es” y “cómo será”. La

ventaja de un modelo de madurez es que es relativamente fácil para la dirección

ubicarse a sí misma en la escala y evaluar qué se debe hacer si se quiere desarrollar una

64


mejora.

Los niveles entre 0 y 5, junto con sus características principales, son los siguientes:

El nivel 0 (no existente) indica que hay una carencia completa de cualquier proceso

reconocible. La empresa no ha reconocido siquiera que existe un problema a resolver.

El nivel 1 (inicial) marca que existe evidencia de que la empresa ha reconocido que los

problemas existen y requieren ser resueltos. Sin embargo, no existen procesos estándar

(se definen procesos para resolver el problema individual). El enfoque general hacia la

administración es desorganizado.

El nivel 2 (repetible) muestra que se han desarrollado procesos hasta el punto en que se

siguen procedimientos similares en diferentes áreas que realizan la misma tarea. Se deja

la responsabilidad al individuo, siendo por tanto muy probable que se produzcan

errores.

El nivel 3 (definido) indica que los procedimientos se han estandarizado y documentado,

y se han difundido a través de entrenamiento. Sin embargo, se deja que el individuo

decida utilizar estos procesos, y es poco probable que se detecten desviaciones.

El nivel 4 (administrado) muestra que es posible monitorizar y medir el cumplimiento

de los procedimientos y tomar medidas cuando los procesos no estén trabajando de

forma efectiva. Los procesos están bajo constante mejora y proporcionan buenas

prácticas.

El nivel 5 (optimizado) marca que los procesos se han refinado hasta un nivel de mejor

práctica, se basan en los resultados de mejoras continuas y en un modelo de madurez

con otras empresas. TI se usa de forma integrada para automatizar el flujo de trabajo,

proporcionando herramientas para mejorar la calidad y la efectividad, haciendo que la

empresa se adapte de manera rápida.

El modelo de madurez es una forma de medir cómo de bien están desarrollados los

procesos administrativos (cómo son de capaces en la realidad). Habrá procesos y

sistemas críticos que requieran de una mayor administración de la seguridad que otros

que son menos críticos.

En resumen, los modelos de madurez brindan un perfil genérico de las etapas a través

65


de las cuales evolucionan las empresas para la administración y el control de los

procesos de TI. Los modelos de COBIT se enfocan en la capacidad y no necesariamente

en el desempeño. No son un número al cual hay que llegar, sino que fueron diseñados

para ser aplicables siempre, con niveles que brindan una descripción que una empresa

pueda reconocer como la mejor para sus procesos. El nivel correcto está determinado

por el tipo de empresa, por su medio ambiente y por la estrategia.

Medición del desempeño

Las metas y métricas COBIT se definen a tres niveles:

Las metas y métricas de TI que definen lo que el negocio espera de TI

Metas y métricas de procesos que definen lo que el proceso de TI debe generar

para dar soporte a los objetivos de TI

Métricas de desempeño de los procesos

Las metas están definidas de arriba abajo por lo que una meta de negocio determinará

varias metas de TI que la soporten. Una meta de TI se logra por un proceso o la

interacción de varios procesos. Por lo tanto, las metas de TI ayudan a definir las

diferentes metas de proceso. A su vez, cada meta de proceso requiere varias actividades,

estableciendo así las metas de actividad.

66


3.2.3 MODELO DEL MARCO DE TRABAJO DE COBIT 4.1

El marco de trabajo COBIT relaciona los requerimientos de información y de gobierno a

los objetivos de la función de servicios de TI. El modelo de procesos COBIT permite que

las actividades de TI y los recursos que las soportan sean administrados y controlados

basados en los objetivos de control de COBIT, y alineados y monitoreados usando las

metas y métricas de COBIT.

Ilustración 31: Gestión, control, almacenamiento y monitorización. Fuente: COBIT 4.1

67


3.2.4 ACEPTABILIDAD GENERAL DE COBIT 4.1

COBIT se basa en el análisis y armonización de estándares y mejores prácticas de TI

existentes y se adapta a principios de gobierno generalmente aceptados. Está

posicionado a un nivel alto, impulsado por los requerimientos del negocio. Cubre el

rango completo de actividades de TI, y se concentra en lo que se debe lograr (gobierno,

administración y control efectivos). Está diseñado para ser complementario y para ser

usado junto con otros estándares y mejores prácticas.

La implantación de las mejores prácticas debe ser consistente con el gobierno y marco

de control de la empresa, debe ser apropiada para la organización y debe estar integrada

con los otros métodos y prácticas que se utilicen.

El ITGI recomienda que COBIT se utilice al más alto nivel, brindando así un marco de

control general basado en un modelo de procesos de TI que debe ser aplicable en

general a toda empresa.

COBIT resulta de interés a:

1. Dirección ejecutiva: para obtener valor de las inversiones y para balancear las

inversiones en riesgo y control en un ambiente de TI con frecuencia

impredecible.

2. Gerencia del negocio: para obtener certidumbre sobre la administración y control

de los servicios de TI proporcionados internamente o por terceros.

3. Auditores: para respaldar sus opiniones y para proporcionar asesoría a la

gerencia sobre controles internos.

COBIT está orientado a los objetivos y al alcance del gobierno de TI, asegurando que su

marco de control sea integral y que sea aceptable para los consejos de administración,

para la dirección ejecutiva, auditores y reguladores.

En la figura siguiente puede observarse cómo se define cada proceso en COBIT. Para

cada uno de los procesos de TI de COBIT, se proporciona un objetivo de control de alto

nivel, junto con las metas y métricas clave en forma de cascada.

68


Ilustración 32: Apartado genérico de COBIT 4.1. Fuente: COBIT 4.1

69


4. ITIL v3 vs COBIT 4.1

70


4.1 CONSIDERACIONES DE LOS EXPERTOS

Después de haber analizado qué son ITIL v3 y COBIT 4.1 puede argumentarse si son

complementarias o excluyentes. Para llegar a la conclusión final se tendrá en cuenta la

opinión de varios expertos que trabajan actualmente en el mundo de Tecnologías de la

Información.

A estos expertos se les ha realizado una encuesta, dividida en dos partes. La primera

parte, compuesta por preguntas SÍ/NO nos ha permitido conocer hasta qué punto

conocen e implementan ITIL o COBIT las empresas. La segunda parte, con preguntas

abiertas y orientadas algunas preguntas para cada experto, han permitido conocer

aspectos concretos de cada negocio y sus opiniones particulares acerca de la utilidad de

las guías.

Los expertos que han sido entrevistados y han colaborado en la realización del proyecto

han sido:

1. Alejandro García Rembado, presidente de ISACA y director de auditoría

informática en Telefónica de España

2. Luis Escapa Cabezas, director de Innovación Operativa en British Telecom Global

Services España

3. Artemio Alcañiz Rodríguez, IT Business Manager de Ferrovial y ex Business

Manager de Isban y BBVANet.

Los resúmenes de estas entrevistas pueden encontrarse en el anexo 11.4 del proyecto.

71


4.2 RECOMENDACIONES DEL ITGI

El ITGI proporciona una serie de recomendaciones a tener en cuenta para implantar

alguna o ambas guías de buenas prácticas:

Priorizar

Para evitar implementaciones que pueden resultar costosas y sin un objetivo claro, las

organizaciones deben priorizar dónde y cómo utilizar los estándares y buenas prácticas.

Las organizaciones necesitan un plan de acción que encaje con sus necesidades y

circunstancias particulares. Es importante que se marque la dirección en que debe

actuarse, cosa que suele funcionar mucho mejor si los altos mandos de la organización

trabajan con el gobierno de IT en mente.

Estos altos mandos deberían asegurarse que tienen un marco de trabajo para el

gobierno de IT (por ejemplo COBIT) y un marco de trabajo para la gestión del servicio

(ITIL).

Planificar

Teniendo esto en cuenta, la dirección puede iniciar un plan de acción y /o

implementación. El inicio es lo más complicado, ya que puede o no suponer que la

implementación resulte o no positiva. Por ello, el ITGI sugiere que se sigan los siguientes

pasos:

Definir el marco de trabajo organizacional, en el que estén marcadas las

responsabilidades y objetivos.

Alinear la estrategia de TI con los objetivos del negocio. Para ello, lo

primero que hay que realizar es buscar y determinar qué objetivos de

negocio pueden ser soportados (o movidos) desde IT. Es preciso conocer

el entorno del negocio, qué riesgos desea la dirección tomar y la estrategia

del negocio. Con estos datos y gracias al uso conjunto de COBIT e ITIL

puede lograrse: La guía COBIT ayuda a definir los objetivos de IT y, usando

ITIL también, pueden definirse servicios y acuerdos de nivel de servicio

(SLA).

72


Entender y definir los riesgos. Entre otros, hay que considerar la

complejidad y tamaño del entorno de IT disponible y planificado y la

vulnerabilidad del mismo. Para ello COBIT tiene un proceso (P09) para la

gestión del riesgo. Asimismo, ITIL clarifica los riesgos operacionales.

Definir las áreas más afectadas por los riesgos. El marco de trabajo de

COBIT puede usarse para esto.

Analizar la capacidad actual e identificar fallos. Asimismo, hay que realizar

una evaluación de madurez para identificar dónde se necesitan mejoras

con más urgencia. Para ello, COBIT provee la base, soportado en mucho

más detalle por las mejores prácticas de ITIL

Desarrollar estrategas de mejora y decidir cuáles son los proyectos de

mayor prioridad que ayudarán a la gestión y gobierno de esas áreas

significativas. La decisión debe basarse en el beneficio potencial y facilidad

de implementación y debería enfocarse en aquellos procesos de IT que

sean considerados importantes y en las competencias básicas de la

organización.

Considerar apoyar los objetivos y prácticas de control de COBIT con una

mayor implicación de ITIL

Monitorizar resultados, establecer un mecanismo de “scorecard” para

monitorizar el rendimiento actual y monitorizar los resultados de las

nuevas mejoras teniendo en cuenta las siguientes consideraciones:

¿Soportarán las estructuras organizacionales la implementación

de la estrategia?

¿Están definidas las responsabilidades para la gestión del riesgo

en la organización?

¿Existen infraestructuras que faciliten y soporten la creación de

información vital para el negocio?

¿Se han comunicado de manera efectiva las estrategias y metas a

todos aquellos que necesiten saberlo en la organización?

73


Repetir los pasos 2 a 7 de manera regular

Evitar fallos

El ITGI informa de que hay algunas reglas (obvias pero prácticas) que la dirección

debería seguir para evitar fallos:

Tratar la iniciativa de implementación como un proyecto con una serie de fases

más que pasos a seguir uno detrás de otro sin relación alguna.

Recordar que la implementación también incluye cambios culturales y nuevos

procesos. Hay que permitir y motivar dichos cambios.

Asegurarse de que los objetivos también están claros

Recordar que las implementaciones de IT llevan su tiempo y que existe un

proceso de mejora continua.

Tratar de solucionar primero aquellas áreas donde sea más sencillo realizar

cambios y conseguir mejoras. Desde este punto, moverse “pasito a pasito”.

Conseguir que los puestos más altos de la empresa estén involucrados y que

conozcan los beneficios de invertir en IT.

Evitar que estas iniciativas se perciban sólo como burocracia.

Evitar tratar la implementación como una “lista de la compra” donde se van

marcando objetivos cumplidos y se olvida de ellos después.

74


4.3 CONCLUSIÓN

A modo de resumen puede decirse: “COBIT ayuda a definir qué debe hacerse e ITIL dice

cómo deben gestionarse los aspectos de gestión del servicio”.

Se identifica que COBIT puede usarse al más alto nivel e ITIL puede utilizarse para cubrir

áreas poco a poco, y puede complementarse perfectamente con el marco de trabajo de

COBIT.

Según las personas entrevistadas para este proyecto, aquellas empresas que no tengan

implantado nada, deberían comenzar poco a poco, nunca intentar abarcarlo todo de

golpe. COBIT debería ser utilizado como modelo para la organización, ayudando a

identificar qué debe hacerse para lograr los objetivos estratégicos de la empresa. ITIL

debería empezar a usarse poco a poco, comenzando a implementarlo en un proceso. Una

vez ITIL haya sido puesto en marcha en un proceso, pasar al siguiente, etc. Se confirma

que ambas guías son perfectamente complementarias y se recomienda su utilización,

tanto para empresas de nueva creación como para empresas ya en funcionamiento.

A aquellas organizaciones que ya tengan algún desarrollo en IT también se les

recomienda utilizar estas guías (aunque sólo sea como referencia) para evitar invertir en

proyectos sin futuro, y minimizar los riesgos de la organización. Asimismo, pueden

observar cómo realizan los procesos los “best-in-class” y aprender cómo mejorar.

IT está cambiando de ser el soporte de las organizaciones, a ser el motor de las mismas.

Por ello, es necesario que en todas las organizaciones se tenga conciencia de ello y se

hagan patentes los riesgos que puede tener una mala inversión en IT.

En todo caso, las organizaciones deben buscar una alineación de las tecnologías de la

información con el negocio. Debe conocerse el entorno en que opera cada organización,

qué riesgos se asumen por la misma y qué dirección debe tomarse para trazar una

estrategia corporativa. A partir de dicha estrategia, es posible trazar una estrategia más

específica de tecnologías de la información. Como puede verse en la imagen siguiente, el

objetivo final debería ser “convertir X en Y”. Llegar a un punto en el que las tecnologías

de la información fluyan junto con el negocio.

75


El n

egoci

o

Tecn

olo

gía

s de la

Info

rmació

n

Tecn

olo

gía

s de la

Info

rmació

n

El n

egoci

o

Ilustración 33: Convertir X en Y. Fuente: Aligning IT with the business.

Para conseguir esto, queda claro que ninguna guía, ni COBIT ni ITIL son la panacea que

conseguirá este resultado de manera mágica. La implementación de cualquiera de estas

guías implica cambios culturales. Esto implica que hay que motivar dichos cambios y

tener en consideración que dicha implementación lleva su tiempo. Es un proceso de

mejora continua.

Ahora bien, si hay que elegir por dónde empezar se ofrece a continuación una tabla

resumen de ITIL y COBIT para facilitar dicha decisión:

ITIL v3 COBIT 4.1

Centrado en la gestión del servicio Auditoría y control de sistemas de la

información

Estándar de facto para la gestión de

servicios informáticos

Conjunto de mejores prácticas para el

manejo de la información

Marco de referencia para la comunicación,

estandarización e identificación de

procedimientos

Enfoque en el control

Terminología común Armonización de estándares con las

mejores prácticas existentes

76


Implica el compromiso de toda la

organización

Enfoque a gerencia

Requiere inversión Busca la utilización óptima de los

recursos: humanos y técnicos

Modelo en 5 etapas Modelo de procesos en 4 dominios

Tabla 2: Comparativa de ITIL v3 con COBIT 4.1

Como puede apreciarse en la tabla superior, ambas guías resultan ser complementarias

y se recomienda la utilización de ambas. COBIT está orientado a la auditoría de sistemas

críticos para el negocio, mientras que ITIL es el estándar de facto para la gestión de

servicios informáticos.

En cualquier caso, tal y como se desprende de las entrevistas de los expertos, es

necesario resaltar una y otra vez que ninguna aplicación de estas guías va a suponer una

ventaja instantánea a aquella organización que la aplique. Sin embargo, sí que crea valor

a largo plazo, se minimizan los errores recurrentes, se tiene una terminología común,

etc. Asimismo, ayudan a alinear la estrategia de la organización con las tecnologías de la

información.

Estas guías no deben convertirse en un fin en sí mismo, sino que deben ayudar a

conseguir los objetivos planteados por la organización para la consecución de la

estrategia corporativa.

Asimismo, explicar una vez más que la experiencia dice que estas guías no deben

implantarse de golpe, sino poco a poco, entendiendo por qué se realiza cada acción y

siempre buscando la consecución de la estrategia corporativa.

77


5. Desarrollo de la aplicación

78


5.1 INTRODUCCIÓN

Para el desarrollo de la aplicación va a seguirse una metodología de desarrollo de

aplicaciones en cascada, basándose en [BARR01] Esta metodología divide el desarrollo

de una aplicación en varias partes, gracias lo cual se consigue trocear el problema e ir

abordándolo poco a poco.

Se inicia identificando qué necesidades no están cubiertas y qué se desea que la

aplicación tenga. Posteriormente se analiza la arquitectura donde se va a implementar la

aplicación y se realiza un análisis del diseño externo e interno de la misma. Con estos

datos, puede empezarse la fase de programación. Según se vayan teniendo distintas

versiones de la aplicación, pueden irse realizando pruebas e ir obteniendo feedback de

los usuarios.

Cuando la aplicación se encuentra finalizada, se implanta, que en este caso en concreto

supone la emisión de la aplicación a Apple para someterla a aprobación. En este

momento podríamos decir que el desarrollo de la aplicación ha finalizado, sin embargo,

no debería olvidarse el mantenimiento de la aplicación, que durará todo el tiempo que

esta aplicación esté disponible para descarga.

79


5.2 IDENTIFICACIÓN DE NECESIDADES

En esta etapa se define el problema a resolver y se fijan las normas a seguir para la

dirección del proyecto. Sirve como soporte a la petición que el cliente realiza para

determinar las pautas generales de sus necesidades y del contexto del sistema.

El objetivo principal es exponer el entorno global del problema en estudio,

especificando:

Objetivos del sistema: Son objetivos de tipo empresarial (no informático)

Alcance del sistema: Son las funciones del negocio a considerar dentro del alcance

del proyecto

Tipología de usuarios finales: Perfil de las personas a las que va dirigido el

producto final a obtener

Restricciones: Aquellos límites que puedan afectar al plan del proyecto y su

desarrollo.

Organización y funciones empresariales: Necesarias para conocer la organización

interna del cliente

Antecedentes: Cualquier información acerca de los motivos que han llevado a la

realización de este proyecto.

Toda esta información queda recogida en el Documento de Conceptos del Sistema, que

puede verse en la página siguiente:

80


Proyecto final de Carrera

Documento de Conceptos del Sistema

Diciembre 2009

Páginas: 4

1. OBJETIVOS DEL SISTEMA

Se pretende desarrollar una aplicación para los empleados de las organizaciones, que contendrá los aspectos más importantes de la guía ITIL de mejores prácticas del área de la gestión de servicios de IT.

Se pretende:

1. Mecanización de la guía ITIL.

2. Reducir los fallos en los sistemas de TI.

3. Mejorar la calidad de los servicios.

4. Proporcionar un punto de apoyo a todos los empleados para solucionar pequeños problemas que pueden salvar mucho tiempo y dinero.

5. Proporcionar el conocimiento a los miembros de la organización qué procesos existen y qué entradas y salidas tienen.

2. ALCANCE DEL SISTEMA

La construcción del sistema implica las funciones a continuación detalladas:

1. Consulta de datos

Tiene como objetivo dotar al sistema de la interfaz adecuada para poder ofrecer a los usuarios el acceso a través de terminales móviles que carecen de teclado (iPhone)

2. Escritura de datos

Tiene como objetivo permitir a los técnicos de la empresa añadir a la base de datos, nueva información que será útil para todos los empleados.

3. TIPOLOGÍA DE USUARIOS

Los usuarios potenciales de esta aplicación serán los empleados de una organización. La utilizarán tanto los técnicos, como el personal administrativo, como los directivos. Se pretende que todos utilicen esta aplicación en caso necesario, aunque sea probablemente el personal técnico y administrativo aquellas personas que más uso le den a la aplicación (los técnicos introduciendo nuevos datos y el resto

81


consultando). Para acotar el tipo de usuarios, consideraremos que el mayor número de usuarios potenciales serán el personal técnico de las grandes organizaciones, aunque en un futuro dicha aplicación pueda ser consultada por todo el personal.

4. RESTRICCIONES

Básicamente tenemos dos restricciones:

1. La aplicación va a ser empleada desde terminales iPhone. Esto implica que se carece de teclado para la entrada de datos. Asimismo, hay que lidiar con el SDK de Apple y sus propias restricciones de programación y de creación de aplicaciones. Entre otros, las aplicaciones del iPhone están limitadas por la memoria, la velocidad, el posible pago de tasas de tráfico de datos, el tamaño de la pantalla y la interfaz de entrada de datos (ausencia de teclado físico).

2. Se va a realizar una aplicación preparada para soportar varios idiomas, para que pueda ser utilizada no sólo en España, sino en todo el mundo. Hay que preparar a los dispositivos para que cambien de idioma en el menú del dispositivo. Por tanto, la programación tendrá que estar adecuada para soportar este requisito.

5. ORGANIZACIÓN Y FUNCIONES EMPRESARIALES

Vamos a considerar una organización generalista de los usuarios en las organizaciones. Normalmente, se observa un orden de jerarquía vertical, donde la alta dirección encabeza el organigrama y de ésta dependen las áreas fundamentales de la empresa (finanzas, marketing, operaciones y sistemas). Dentro de éstas, consideraremos personal técnico, operarios y administrativos.

a. Dirección general

b. Áreas de la empresa:

Finanzas

Operaciones

Marketing

Sistemas de Información

c. Personal

Administrativos

Operativos

Técnicos

82


6. ANTECEDENTES

Actualmente se producen muchos fallos en las empresas, que podrían ser evitados con un mínimo conocimiento de la guía ITIL. Asimismo, se dedican muchos recursos (económicos y temporales) a IT y luego no se optimizan los procesos, con lo que estos recursos no se aprovechan todo lo que podrían. Más aún, hoy en día hay que lidiar con muchas regulaciones externas que afectan a todas las empresas (Basilea II, Sarbanes-Oxley…). IT juega un papel muy importante, ya que canaliza toda la información en la empresa. Aquellas empresas que no tengan optimizados sus sistemas pueden estar desperdiciando recursos, pero, sobre todo podrían estar incumpliendo alguna de las leyes vigentes.

Tras haber entrevistado a varios expertos en el sector de IT, consideran que si los empleados pudieran consultar ITIL en tiempo real, podrían reducirse en gran medida el número de situaciones que llevan a desastres. Asimismo, es una manera de concienciar a los usuarios de la importancia que tiene IT hoy en día. IT ya no es más el soporte de las organizaciones, sino el motor.

83


5.3 ANÁLISIS DE REQUISITOS

El objetivo de esta fase es alcanzar un conocimiento suficiente del sistema. Es preciso

definir las necesidades, problemas y requisitos del usuario, para poder expresarlos más

adelante con modelos de procesos y datos.

El análisis de requisitos es la tarea que plantea qué debe hacer el sistema para cumplir

con las necesidades del negocio y los requisitos del usuario. Es por ello que se hace

hincapié sobre el qué debe hacer el sistema y no cómo debe hacerlo.

La metodología de análisis de requisitos realiza una subdivisión en varias actividades:

1. Reconocimiento del problema

2. Obtención del Modelo Físico Actual

3. Deducción del Modelo Lógico Actual

4. Creación de la lista de requisitos

5. Desarrollo del Modelo Lógico Nuevo

6. Revisión de la especificación

Se comenzará, pues, comprendiendo el contexto del sistema. Habrá que reconocer los

elementos básicos del sistema tal y como lo percibe el usuario.

1. Reconocimiento del problema

Para obtener una visión de conjunto sobre el problema, se analiza en detalle el

ámbito del proyecto, viendo qué unidades y qué funciones primarias de la

organización quedarán afectadas por la aplicación.

a. Ámbito del proyecto

Como ya se ha definido en detalle en la Identificación de Necesidades, se

tratará de mecanizar y automatizar la guía de mejores prácticas ITIL en

teléfonos Apple iPhone.

b. Unidades de la organización afectadas

84


Principalmente se encuentra que las siguientes unidades son las que se

verán afectadas con la implantación de la aplicación:

Áreas organizativas de la empresa

El personal técnico dejará de ser los únicos encargados de solucionar

problemas de IT

Sistemas informáticos existentes

Para un futuro desarrollo de nuevas versiones de esta aplicación se

requerirá utilizar ordenadores Apple. Esto implica que si se desea

realizar mantenimiento de la aplicación desde la organización, se

habrán de comprar equipos Apple, no siendo válidos los equipos con

otros Sistemas Operativos, como Windows o Linux. Con respecto al

sistema operativo de los equipos Apple, bastará que lleven instalado la

versión Mac OS X 10.4 (Tiger), aunque sí será necesario que cuenten

con la última versión del entorno de desarrollo para el iPhone (Xcode)

que a día de hoy la última versión es la 3.1.2. La última versión de

Xcode permite trabajar con las últimas librerías incluidas en el

firmware más reciente de los teléfonos.

Bases de Datos corporativas

Al igual que los sistemas informáticos, la BBDD deberá ser accedida

por el Xcode. Dependiendo de la organización y de qué sistemas tenga

implementados, puede ser posible que haya que realizar una

migración de la base de datos a los equipos Apple y gestionar desde

éstos la escritura y lectura de datos de los equipos.

2. Obtención del modelo físico actual

El modelo físico actual pretende recoger la problemática existente y los

requisitos necesarios para solventarla. Debe distinguir los principales procesos

del sistema y sus interfaces (flujos de datos y almacenamientos). Asimismo, el

modelo tendrá que tener una componente de especificación donde se describa

85


detalladamente los procesos de más bajo nivel que no se descomponen en otros.

1.

Determinar del

problema

Problema o incidencia

Problema o Incidencia

3.

Determinar a

quién informar



2.

Resolver el

problema


Problemas /

Incidencias

resueltos

4.

Escalar el

problema

5.

No hacer nada




Problemas

anteriores

Ilustración 34: DFD del modelo físico actual

En general, el proceso funciona actualmente de la siguiente manera:

Un empleado cualquiera de la organización se encuentra con un fallo, algo que no

funciona bien. Llámese problema o incidencia. En caso de que lo sepa resolver,

puede resolverlo o ignorarlo (en caso de que sea un fallo menor que no le cause

mayor problema). Si no lo sabe resolver, tendrá que escalar el problema. Sin

embargo, también puede suceder que el usuario no sepa a quién debe informar,

por lo que volvemos a “no hacer nada”. En el caso de que se sepa resolver el

problema, tanto por le usuario, como por la persona a la que le haya pasado el

problema, se guarda el problema en una BBDD para que en otras ocasiones se

86


pueda leer de esta BBDD información que ayude a resolver un problema futuro.

3. Deducción del modelo lógico actual

El modelo lógico actual se deduce del modelo físico actual, eliminando de éste las

características físicas y agrupando procesos físicos para deducir procesos lógicos.

Debe descubrirse lo esencial del sistema en estudio. Son procesos o funciones

esenciales hechos por raciones de negocio y no por razones tecnológicas.

Asimismo, son datos esenciales el conjunto mínimo de datos requerido para dar

soporte a las actividades esenciales.

1.

Determinar del

problema


Problema o Incidencia

3.

Determinar a

quién informar



2.

Resolver el

problema


Problemas /

Incidencias

resueltos

4.

Escalar el

problema

5.

No hacer nada




Problemas

anteriores

Ilustración 35: DFD del modelo lógico actual

87


Ocurre que en este caso, el modelo físico actual y el modelo lógico actual

coinciden: no existe ninguna plataforma tecnológica que pueda eliminarse, por lo

que, en resumen, ambos modelos coinciden.

4. Creación de la lista de requisitos

Esta lista es una relación de los requisitos expresados por el cliente, para su

nuevo sistema. Queda confeccionada a partir de las entrevistas con el cliente,

recogiéndose las características de cada requisito en una ficha específica.

Normalmente se realiza una división de los requisitos atendiendo a su naturaleza

y podemos encontrar tres tipos diferentes:

Funcionales, que atienden a características propias de las funciones de

negocio.

Operativos, que atienden al modo en que operará el sistema.

De prestaciones, que atienden a características adicionales o funciones de

menor prioridad.

A modo de resumen, los requisitos mínimos que debe tener son que la aplicación

a ser creada debe ser una aplicación completa ITIL, preparada para trabajar con

varios idiomas, con conectividad con aplicaciones desktop y que sea

perfectamente funcional en dispositivos Apple iPhone.

Para identificar formalmente cada requisito, se utilizará una Ficha de Requisito,

en las cuales se incluye la siguiente información:

Proyecto: nombre del proyecto

Jefe de Proyecto: nombre del autor de esta ficha (Jefe de Proyecto)

Fecha: fecha en la que se documentó el requisito

Versión: versión del documento

Estado: Borrador/Aceptado/Pendiente

88


Prioridad: Alta/Media/Baja

Página: número de páginas que incluye el requisito

Título: breve definición del requisito

Identificador: código por el cual se identifica a este requisito. El código

estará formado de la siguiente manera: X-YY, donde X puede tomar los

valores F,O,P, según el requisito sea Funcional, Operativo o de

Prestaciones. YY serán dos números que identifiquen unívocamente al

requisito.

Fuente: cliente o área de donde proviene este requisito

Categoría: Funcional/Operativo/de Prestaciones

Descripción: detalle del requisito

Medición: modo de medir el cumplimiento del requisito, para su posterior

validación. Pueden establecerse métricas o establecer el procedimiento de

validación del requisito por el cliente.

Beneficios: beneficios que esperan obtenerse con este requisito

Comentarios: información adicional, entre las que caben sugerencias de

solución a utilizar

Documentos relacionados: documentación existente que especifique las

condiciones del requisito

Requisitos relacionados: identificadores de aquellos requisitos que puedan

estar relacionados con éste

A continuación pueden verse todas aquellas fichas de requisito que han sido

utilizadas para el desarrollo de este proyecto.

89


IDENTIFICACIÓN

Proyecto: Desarrollo de una aplicación ITIL para el iPhone Jefe de Proyecto: Enrique de Diego REQUISITO

Fecha: 22/4/10 Versión: 0.1 Estado: Borrador Prioridad: Media Pág.: 2 Título: Preparación para que la aplicación soporte varios idiomas Identificador: P-01 Fuente: Cliente Categoría: de Prestaciones. Descripción: La aplicación deberá soportar castellano como idioma principal. Sin embargo, para futuros desarrollos, deberá estar preparada para incluir aquellos idiomas que sean necesarios. MEDICIÓN

La inclusión de nuevos idiomas en la aplicación deberá realizarse de forma sencilla y sin tener que modificar el código. En otras palabras, deberá evitarse que la programación esté “hardcoded” y deberá buscarse que cualquier persona sin demasiados conocimientos de programación sea capaz de añadir un nuevo lenguaje a la aplicación.

BENEFICIOS

La aplicación tiene un público objetivo muy grande y, aunque es intención comenzar a implementarla en empresas españolas, es probable que se muestre interés por ella desde ámbitos internacionales. Por ello, es fundamental que la aplicación esté preparada para incluir idiomas nuevos en el mínimo tiempo posible.

Asimismo, dentro de España, es posible que ciertas empresas deseen incluir en la aplicación aquellos otros idiomas co-oficiales en algunas Comunidades Autónomas: Galicia, País Vasco, Cataluña, Baleares o Comunidad Valenciana.

El principal beneficio es, por tanto, la escalabilidad de la aplicación y la facilidad de introducción de la aplicación en mercados internacionales.

COMENTARIOS/SOLUCIONES SUGERIDAS

Para que la traducción vaya de manera rápida, se propone utilizar tablas de sinónimos, por palabras o frases, que se alojen en la propia aplicación. Otra opción sería descargar un paquete de idiomas desde la red. Durante fases posteriores se decidirá cuál es la mejor opción.

DOCUMENTOS RELACIONADOS

N/A

REQUISITOS RELACIONADOS

O-02

90


IDENTIFICACIÓN


Fecha: 21/12/09 Versión: 0.1 Estado: Definitivo Prioridad: Media Pág.: 1 Título: Conectividad con aplicaciones Desktop Identificador: O-01 Fuente: Cliente Categoría: Operativo Descripción: En relación con el requisito de “inclusión de tareas ITIL”, se solicita que sea posible recibir en los dispositivos una actualización de las tareas. Esta actualización deberá venir desde una aplicación alojada en un equipo Desktop. MEDICIÓN

Deberá ser posible enviar información de nuevas tareas a la aplicación. Este envío de información podrá realizarse de la manera que se considere más conveniente: e-mail, SMS, tablas, etc. BENEFICIOS

El principal beneficio que se obtiene de este requisito es dotar a la aplicación de dinamismo. En el caso de que un empleado desee actualizar la lista de tareas ITIL, podrá comunicarse con el equipo Desktop y recibir de alguna manera una actualización de esta lista de tareas. De esta manera, se consigue que la aplicación, además de contener información estática, pueda recibir información de manera dinámica. COMENTARIOS/SOLUCIONES SUGERIDAS

La conectividad desktop deberá ser modelada para el módulo de tareas ITIL en la aplicación. Para ello habrá que buscar cuál es la manera idónea para recibir información.

Habrá que verificar que esta información se transmita de manera segura y que cada empleado reciba su información. Habrá que implementar algún tipo de medida sencilla de identificación del usuario en este módulo.


N/A


F-01

91


IDENTIFICACIÓN


Fecha: 12/6/09 Versión: 0.1 Estado: Definitivo Prioridad: Media Pág.: 1 Título: Máxima usabilidad en la aplicación Identificador: O-02 Fuente: Expertos Categoría: Operativo Descripción: La aplicación deberá funcionar de la manera más sencilla posible, facilitando en todo momento la navegación a los usuarios. Asimismo, deberá tener un “look-and-feel” elegante, pero discreto. MEDICIÓN

Durante el desarrollo de la aplicación se mostrará la aplicación a varios expertos y se tendrá en cuenta su opinión. Asimismo, durante las pruebas de usabilidad y manejo de la aplicación se depurarán aquellos detalles que no hayan quedado satisfechos. En general, la última palabra la tendrán los expertos a los que se ha encuestado varias veces durante el desarrollo de este proyecto. BENEFICIOS

Principalmente, los beneficiarios de este requisito serán los usuarios de la aplicación, que podrán utilizar la aplicación sin demasiada complicación. Colateralmente, el desarrollo de la aplicación también se ve beneficiado ya que un trabajo de optimización de la usabilidad desde el primer momento evitará retoques futuros en la aplicación así como quejas o dudas por parte de los usuarios. COMENTARIOS/SOLUCIONES SUGERIDAS

Se sugiere por parte de los expertos que la aplicación sea tan modular como sea posible. Asimismo, gracias a la experiencia de uso del iPhone, se conocen los aspectos intrínsecos a la navegación en las aplicaciones del mismo, donde la ausencia de teclado físico implica que en las pantallas del iPhone existan muchos botones, selectores de datos, campos de búsqueda, barras de navegación, etc.

Se propone por tanto, modular tanto como sea posible la aplicación, a la vez que se utilizan aquellos elementos que faciliten la navegación. DOCUMENTOS RELACIONADOS

N/A


O-03

92


IDENTIFICACIÓN


Fecha: 15/3/10 Versión: 0.3 Estado: Definitivo Prioridad: Media Pág.: 1 Título: Inclusión de “tareas ITIL” en la aplicación Identificador: F-01 Fuente: Cliente Categoría: Funcional Descripción: La aplicación contendrá un módulo en el que aparezcan tareas ITIL a realizar por el usuario de la aplicación. Estas tareas vendrán organizadas según el libro de ITIL donde se ubiquen: Service Design, Service Strategy, Service Transition, Service Operation y Continual Service Improvement. MEDICIÓN

Los usuarios tendrán a su disposición este módulo que incluirá aquellas tareas que deba realizar. Estas tareas estarán organizadas por el libro ITIL en el que aparezcan y darán información al usuario sobre qué es lo que debe hacer. Estas tareas podrán ser descargadas de una aplicación Desktop (ver requisito O-01). BENEFICIOS

Los beneficiarios de este requisito son los usuarios que tendrán en la aplicación un listado de las tareas que deban realizar.

Asimismo, la organización también se ve beneficiada al tener unos empleados más eficientes y autosuficientes gracias a esta aplicación. COMENTARIOS/SOLUCIONES SUGERIDAS

La aplicación deberá tener un módulo que contenga esta lista de tareas ITIL. Este módulo deberá ser accesible en cualquier momento desde cualquier parte de la aplicación.

Dentro de este módulo existirá la posibilidad de actualizar la lista de tareas para que el usuario pueda disponer de las mismas en el momento que él lo desee. DOCUMENTOS RELACIONADOS

N/A


O-01

93


IDENTIFICACIÓN


Fecha: 23/3/10 Versión: 1.1 Estado: Definitivo Prioridad: Alta Pág.: 2 Título: Funcionamiento óptimo en dispositivos iPhone/iPod Touch Identificador: O-03 Fuente: Cliente Categoría: Operativo Descripción: La aplicación está pensada para ser desarrollada en dispositivos Apple iPhone y Apple iPod Touch. Sin embargo, el iPad también tendrá la capacidad de utilizarla, aunque no de manera óptima. Habrá dos maneras de verla: una a escala y otra redimensionando la aplicación original.

En nuestro caso, interesa que sea en los iPhone e iPod Touch donde mejor funcionamiento tenga y no en el iPad porque gracias al reducido tamaño de los primeros, los empleados de las organizaciones podrán llevarse a todos los lados la guía ITIL. Asimismo, es más económico para las organizaciones dotar a los empleados de iPhones o iPod Touch que de iPad. MEDICIÓN

Después de programar la aplicación, habrá que realizar pruebas en los dispositivos reales para garantizar el óptimo uso de recursos: memoria, procesador, etc. Así como verificar que los tiempos de carga y manejo de la aplicación son los mínimos. BENEFICIOS

Al optimizar el desarrollo para las plataformas comentadas, se garantiza el mejor uso y experiencia del usuario posible. En el caso de que alguien desee utilizar esta aplicación en el iPad, existirá la posibilidad, pero no estará optimizada para esta plataforma. COMENTARIOS/SOLUCIONES SUGERIDAS

En el SDK de Apple habrá que configurar la aplicación para su uso en iPhone e iPod Touch. Para el iPad habría que realizar un desarrollo en paralelo. DOCUMENTOS RELACIONADOS

[WEB004]


O-02

94


IDENTIFICACIÓN


Fecha: 15/2/10 Versión: 0.2 Estado: Definitivo Prioridad: Media Pág.: 2 Título: Adecuación de la aplicación para usuarios con conocimiento (casi) nulo de ITIL Identificador: F-02 Fuente: Expertos Categoría: Funcional Descripción: El contenido de la aplicación deberá ser muy simple e intuitivo, de forma que los usuarios que desconozcan ITIL por completo no se sientan perdidos. Esto es un requisito que han solicitado varios de los expertos entrevistados. Un glosario de términos ayudará al usuario no ducho en el tema a familiarizarse con los conceptos. MEDICIÓN

Habrá que comprobar en las pruebas de usabilidad que los usuarios son capaces de navegar cómodamente por la aplicación e integrar los comentarios que realicen sobre la misma. Se intentará que las pruebas las realicen tanto como usuarios expertos como usuarios con desconocimiento total de ITIL. BENEFICIOS

Dado que el objetivo de este desarrollo es construir una aplicación que sea beneficiosa para el mayor número de usuarios, es fundamental que aquellos usuarios novatos puedan utilizarla sin problemas. COMENTARIOS/SOLUCIONES SUGERIDAS

Probablemente una de las soluciones más sencillas y elegantes sea incorporar un módulo a la aplicación en el que figure un glosario o diccionario de términos, de forma que en caso de duda, el usuario pueda acceder a este módulo y resolver su duda. DOCUMENTOS RELACIONADOS

N/A


O-02

95


IDENTIFICACIÓN


Fecha: 22/4/10 Versión: 0.1 Estado: Definitivo Prioridad: Alta Pág.: 1 Título: Desarrollo del manual del usuario sobre una página web. Identificador: P-02 Fuente: Cliente Categoría: de Prestaciones Descripción: El manual del usuario de la aplicación deberá estar recogido en una página web. Tras observar la previsualización de las aplicaciones en el AppStore, se solicita la creación de una página web que simule ese comportamiento. Esta página web tendrá que estar accesible a todo el mundo, por lo que habrá que buscar un dominio para la misma y un servidor donde alojarla. MEDICIÓN

Tras el desarrollo de la aplicación, habrá que diseñar la página web y mostrársela a los usuarios, para que verifiquen si tiene aquella información que consideran necesaria para el manejo de la aplicación.

BENEFICIOS

El poder conectarse desde cualquier equipo del mundo a Internet para visualizar el manual de la aplicación tiene un beneficio inmediato: resolución de consultas y dudas sin tener que portar el manual de la aplicación a todos los sitios.


Se propone realizar una página web con la tecnología que se considere apropiada, a la que pueda accederse públicamente. Asimismo, se propone la utilización de un dominio de primer nivel para facilitar a los usuarios recordar la dirección.


N/A


P-03

96


IDENTIFICACIÓN


Fecha: 22/4/10 Versión: 0.1 Estado: Definitivo Prioridad: Baja Pág.: 1 Título: Realización de una versión móvil de la página web del manual del usuario. Identificador: P-03 Fuente: Cliente Categoría: de Prestaciones Descripción: Junto con el requisito P-02 se propone también la creación de una versión ‘light’ de la página web. Esta versión light será a la que se acceda si el equipo no es un sobremesa, sino un iPhone/iPod Touch. Esta página web estará adaptada a la pantalla de los dispositivos anteriormente mencionados, por lo que no será una copia exacta a menor escala, sino una adaptación de la web de escritorio. MEDICIÓN

Al igual que con el requisito P-02, habrá que mostrar la web a los usuarios una vez que se haya desarrollado la aplicación, para que puedan ver si la información que contiene la web es suficiente para que utilicen de manera cómoda la aplicación.

BENEFICIOS

Esta versión Light de la web principal facilita a los usuarios consultar el manual de la aplicación desde cualquier parte del mundo, desde los iPhones o iPod Touch. En aquellas situaciones donde no se tenga acceso a un sistema de escritorio, será posible acceder con el navegador Web de los dispositivos a esta versión de la web para consultar aquella información que necesiten los usuarios.


Al conectarse desde un iPhone/iPod Touch, la página web deberá saber que se está accediendo con uno de estos terminales y redirigir a la versión ‘light’ de la web.


N/A


P-02

97


5. Desarrollo del modelo lógico nuevo

Todos aquellos requisitos expresados por el usuario son incorporados al modelo

lógico actual, lo que provocará la incorporación, eliminación y modificación de

objetos en el modelo. La manera óptima de abordar esta actividad es trabajar con

el modelo lógico actual de más bajo nivel, e ir remodelando los procesos,

subiendo de nivel y consolidando lo expresado en el modelo superior.

Tras analizar los requisitos pedidos por el usuario, puede verse cómo queda el

diagrama del modelo lógico nuevo:

1. Iniciar

aplicación

2. Determinar

módulo

3. Consultar

Guía ITIL

5. Consultar

módulo de

tareas ITIL

4. Consultar

glosario de

términos

6. Service

Strategy

7. Service

Design

8. Service

Transition

9. Service

Operation

10. Continual

Service

Improvement

11. Consultar

tareas

12. Actualizar

tareas

Tareas del

usuario

Glosario de

términos

2. Determinar

módulo

Ilustración 36: DFD del modelo lógico nuevo

Según puede apreciarse en el diagrama, el usuario iniciará la aplicación y elegirá

el módulo que desea utilizar entre:

Consultar el resumen de la guía ITIL

Consultar el glosario de términos

98


Consultar las tareas ITIL

En el módulo de resumen de ITIL, se accederá a vistas informativas de la

aplicación, no accediendo a ningún almacén de información

En el módulo del glosario de términos, se consultará un almacén de información:

el propio glosario de términos que estará incluido en la propia aplicación.

En el módulo de las tareas ITIL, se accederá a un almacén de información, que

será posible leer, pero también actualizar, sincronizando los cambios efectuados.

6. Revisión de la especificación

Una vez establecido el análisis de los requisitos, se realiza con varios de los

expertos una revisión de la especificación de requisitos.

Entre otras preguntas, se realizaron a los expertos las siguientes:

¿los objetivos y fines establecidos para el sistema son consistentes con los

objetivos y fines de la organización?

¿se han descrito todas las interfaces importantes de todos los elementos

del sistema?

¿se han definido el flujo, contenido y estructura de la información de forma

adecuada al dominio del problema?

¿son claros los diagramas? ¿puede cada uno de ellos utilizarse sin el texto

suplementario?

¿permanecen las funciones principales dentro del ámbito y se describen

adecuadamente cada una de ellas?

¿se han considerado requisitos alternativos?

¿existen inconsistencias, omisiones o redundancias?

Presentada esta información a los expertos, se aceptó como válida, por lo que se

procedió con el desarrollo de la aplicación.

99


5.3 ARQUITECTURA

En este proyecto, la arquitectura está definida, por lo que no resulta necesario realizar

ninguna comparativa entre posibles opciones. La aplicación se realizará para teléfonos

Apple iPhone e iPod Touch.

Los iPhones poseen las siguientes características:

Son un dispositivo con un peso de 135 gramos y tiene unas dimensiones de 115.5mm de

altura, 62.1mm de anchura y 12.3mm de profundidad. Posee una pantalla multitáctil de

3.5 pulgadas y una resolución de 480*320 píxeles a 163 ppi4. Tienen una memoria

interna que varía de 4 a 64 GB, según modelo.

El modelo 3G cuenta con un módulo GPS y el modelo 3GS además cuenta con brújula.

Todos los modelos tienen Wifi, y Bluetooth, así como la capacidad de operar en redes

GSM y EDGE, aunque sólo los últimos modelos pueden operar además en redes UMTS y

HDSPA, además de ser cuatribanda, con lo que su utilización podría ser a nivel global.

Este dispositivo posee una autonomía de 300h en espera y 12h de conversación.

El modelo 3GS se diferencia del modelo 3G anterior en la inclusión de un hardware

interno más potente (dobla la memoria y la velocidad del procesador del 3G).

En general, los iPod Touch tienen las mismas características técnicas que los iPhones,

excluyendo la función de teléfono. Para más información puede verse [WEB004].

Ilustración 37: iPhone 2G e iPhone 3G

4 Puntos por pulgada

100


Durante el desarrollo de este proyecto se produjo el lanzamiento del iPad, dispositivo

que también será capaz de correr la aplicación. El iPad es un tablet PC que fue

anunciado el 27 de enero de 2010 y puesto a la venta el 3 de abril de 2010. Este

dispositivo es similar en funciones al iPhone o iPod Touch y funciona sobre una versión

ligeramente modificada del sistema operativo. La interfaz de usuario ha sido rediseñada

para aprovechar el mayor tamaño de la pantalla (9,7 pulgadas) con resolución 1024x768

píxeles.

Esta pantalla también es multitáctil y cuenta con retroiluminación LED. Con respecto al

resto de hardware del iPad, encontramos muchas similitudes con el iPhone: Wi-Fi

(802.11a/b/g/n), Bluetooth 2.1+EDR, USB, altavoz, micrófono, acelerómetro y brújula,

así como los sensores de proximidad y luz ambiental.

Existen actualmente dos modelos de iPad, diferenciándose únicamente en la presencia o

no de conectividad 3G. El modelo con 3G requiere que se introduzca una tarjeta micro-

SIM para su funcionamiento.

Con respecto a la memoria interna, ambos dispositivos pueden conseguirse con

capacidades de 16, 32 o 64GB.

Ilustración 38: iPad. Fuente: Apple

101


Con el lanzamiento del iPad, Apple puso a disposición de los desarrolladores el sistema

operativo 4.0 BETA y el SDK para trabajar con dicho sistema. La gran ventaja que ofrece

el iPad es que es capaz de trabajar con aplicaciones realizadas para esta plataforma,

como reescalar las aplicaciones para iPhone/iPod Touch.

En conclusión, el iPad, también podrá utilizarse para la aplicación que va a desarrollarse,

aunque en principio no sea el sistema preferido.

A modo de resumen, los dispositivos que, a fecha de la presentación de este proyecto,

pueden utilizar la aplicación son:

iPhone 2G

iPhone 3G

iPhone 3GS

iPod Touch

iPad

102


5.3.1 PANTALLA

De todas las características del iPhone debe destacarse su pantalla. Con su resolución de

480*320 píxeles, es capaz de mostrar páginas web a escala total.

Asimismo, el iPhone es capaz de mostrar la salida por pantalla en dos orientaciones

diferentes: 480*320 y 320*480. Cada orientación tiene sus ventajas e inconvenientes,

por lo que cada aplicación deberá utilizar la que más convenga en cada caso. La

orientación vertical es idónea para trabajar con listas, la horizontal tiene una superficie

visible mayor.

Ilustración 39: Las dos orientaciones soportadas por el iPhone. Fuente: Apple

Asimismo, es importante destacar el soporte multitáctil del terminal, que permite la

manipulación por parte de los usuarios a través de diferentes gestos: un pellizco hace

zoom en la pantalla, girar los dedos rota la pantalla, etc.

103


5.3.2 RED

Las especificaciones de red son asimismo importantes, pues según qué terminal se

posea y en qué circunstancias se esté, será posible o no un tráfico de datos a una

velocidad aceptable para el usuario.

Básicamente existen dos métodos de conexión de red: por la red telefónica o por una red

inalámbrica (Wifi).

La velocidad de conexión a la red telefónica variará por dos aspectos: el tipo de terminal

que se utilice y el tipo de cobertura de red que haya en el momento de conexión.

El primer modelo de iPhone se conecta únicamente a través de GPRS o EDGE,

soportando una velocidad máxima de 220 kbps. Los modelos 3G y 3GS pueden

conectarse, además de por GPRS 5o EDGE6, a través de la red UMTS/HSDPA7,

consiguiendo velocidades de hasta varios Mbps.

Los iPod Touch no pueden conectarse a ninguna de las redes telefónicas anteriormente

mencionadas por carecer de conectividad telefónica.

Por otro lado, todos los dispositivos pueden conectarse a una red inalámbrica (Wifi)

siempre que se esté bajo su cobertura y se tengan privilegios de acceso. Bajo esta

conexión, la velocidad máxima será aquella que soporte la línea a la que esté conectado

el router Wifi, pudiendo llegar a un máximo teórico de 54Mbps.

Es importante tener en cuenta todas estas consideraciones para el desarrollo de

aplicaciones para estos dispositivos porque no en todo momento será posible acceder a

datos remotos y será necesario informar al usuario de esta circunstancia en caso de que

ocurra.

5 General Packet Radio Service

6 Enhanced Data Rates for GSM Evolution

7 Universal Mobile Telecommunications System, High-Speed Downlink Packet Access

104


5.3.3 DESARROLLO DE APLICACIONES PARA EL IPHONE

Para desarrollar la aplicación en teléfonos iPhone, es necesario programar en

ordenadores Apple. Es indiferente qué versión de Sistema Operativo lleven estos

ordenadores, con tal de que sea igual o superior a la 10.4.

Sin embargo, sí es necesario que la versión del entorno de desarrollo (Xcode) sea la

última, o por lo menos coincidente con la versión del firmware del teléfono.

A fecha de la realización de este proyecto, la versión en producción más reciente del

XCode es la 3.1.3, que se empleará para desarrollar la aplicación.

105


5.4 DISEÑO EXTERNO

El objetivo principal del Diseño Externo es transformar el modelo lógico del nuevo

sistema en un modelo físico a implementar sobre una plataforma hardware y software

específica. Cuando este modelo se haya completado, se pasará al Diseño Interno para

edificar sobre la plataforma elegida los pilares básicos del nuevo sistema mecanizado, la

arquitectura del software.

A partir de la plataforma tecnológica elegida en el Estudio de Arquitectura, en esta fase

quedarán completados los requisitos físicos del nuevo sistema, se diseñarán las entradas

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

modelo lógico de datos, a partir de los volúmenes y transacciones del sistema. Para

completar la definición del modelo físico, se le dota de procesos de control, seguridad y

auditabilidad.

Especificación hardware

iPhone / iPod Touch Servidor de actualizaciones

App Store

Ilustración 40: Especificación HW del sistema

Como puede verse en la imagen superior, la especificación hardware es bastante sencilla:

Una vez el usuario de la aplicación se ha descargado la aplicación de la AppStore, ésta

106


residirá en su teléfono y no se comunicará con el exterior salvo en el caso de que se

desee utilizar el módulo de tareas ITIL, en cuyo caso, tendrá que comunicarse con un

equipo remoto para descargarse las tareas que tenga pendientes.

5.4.1 DISEÑO A ALTO NIVEL

La aplicación estará compuesta por tres módulos:

Guía ITIL

Terminología

Tareas ITIL

A estos tres módulos se navega con una barra situada permanentemente en la parte

inferior de la aplicación.

Ilustración 41: Pantalla principal de la aplicación

107


Al iniciar la aplicación, mostrará unos momentos la imagen superior y el módulo de Guía

ITIL será el que se acceda por defecto al entrar. Este módulo contendrá un enlace a cada

uno de los libros de ITIL en forma de tabla. Haciendo clic en cada uno de los vínculos, se

navegará al libro correspondiente.

Dentro de este apartado podrá verse qué es lo que incluye cada libro: procesos, roles

etc., así como una descripción del libro y algún gráfico significativo.

Ilustración 42: Pantalla de Guía ITIL de la aplicación

108


Ilustración 43: Visualización de un apartado de la Guía ITIL

El módulo de terminología será aquel al que se acceda tras pulsar en la barra inferior el

segundo enlace. Este módulo contendrá un diccionario con información relacionada

sobre ITIL, COBIT, Tecnologías de la Información, etc. Este diccionario estará ordenado

alfabéticamente y, tras pulsar en el concepto que se desee, se navega a una pantalla que

explica qué es el término que se ha pulsado.

109


Ilustración 44: Pantalla del glosario de la aplicación

El tercer módulo de la aplicación es el de las tareas ITIL. En este módulo, que es

accesible siempre con la barra inferior de la aplicación, aparece una lista de aquellas

tareas ITIL que deba realizar el usuario. Estas tareas vienen clasificadas por aquellos

libros ITIL a los que pertenecen (por ejemplo, Gestión de cambios vendrá incluido

dentro del libro de Service Transition).

Para utilizar este servicio, habrá que configurarlo previamente y cuando el usuario lo

desee, podrá actualizar esta información. Para estas funciones, existirán dos botones en

la parte superior de la aplicación que llevarán o bien a la configuración del servicio o a la

actualización de los datos.

110


Ilustración 45: Pantalla de tareas ITIL

La navegación entre pantallas puede verse en la página siguiente:

Siempre que se arranca la aplicación, aparece la pantalla introductoria, para después

llevar a la pantalla de Guía ITIL con los enlaces a los cinco libros. Desde esta pantalla

puede navegarse directamente a Terminología o Tareas ITIL, o bien navegar hacia

alguno de los libros .

Independientemente de en qué módulo nos encontremos, siempre será posible navegar

a cualquiera de los otros módulos con la barra inferior. El objetivo principal de esta

decisión es que un usuario pueda estar leyendo información sobre ITIL dentro de alguno

de los libros e ir a consultar en Terminología un concepto que no tenga claro.

Posteriormente podrá volver a navegar hacia la guía ITIL y volver al libro donde se

encontraba leyendo.

111


Ilustración 46: Navegación de la aplicación

112


5.5 DIAGRAMAS UML

El lenguaje UML (Lenguaje unificado de modelado) es un lenguaje gráfico para

visualizar, especificar, construir y documentar un sistema. En UML 2.0 hay 13 tipos

distintos de diagramas, jerarquizados de la siguiente manera

Diagramas de Estructura: enfatizan en los elementos que deben existir en el sistema

modelado

De clases

De componentes

De objetos

De estructura compuesta

De despliegue

De paquetes

Diagramas de Comportamiento: enfatizan en lo que debe suceder en el sistema

modelado

De actividades

De casos de uso

De estados

Diagramas de Interacción (subtipo de diagramas de comportamiento): enfatizan sobre el

flujo de control y de datos entre los elementos del sistema modelado

De secuencia

De comunicación

De tiempos

De interacciones

De todos los tipos anteriormente mencionados, se analizará y utilizará el diagrama de

113


casos de uso.

Un caso de uso es una secuencia de interacciones que se desarrollarán en un sistema y

sus actores en respuesta a un evento que inicia un actor principal sobre el propio

sistema. Los diagramas de casos de uso sirven para especificar la comunicación y

el comportamiento de un sistema mediante su interacción con los usuarios y otros

sistemas. En otras palabras, es un diagrama que muestra la relación entre los actores y

los casos de uso en un sistema.

USUARIO

ADMINISTRADOR

DE TAREAS

Guía ITIL

Terminología

Tareas ITIL

Preparar

tareas ITIL

Aplicación ITIL

Ilustración 47: Diagrama UML de la aplicación

114


5.6 PROGRAMACIÓN

El objetivo de esta etapa es alcanzar la transformación del sistema en un conjunto de

programas que puedan ser ejecutados correctamente, bajo criterios de calidad. La

dificultad se halla en averiguar la mejor manera de realizar esta transformación, ya que

dependerá de varios factores, como el lenguaje de programación a utilizar, herramientas

y utilidades software disponibles y el equipo de programación.

Se tiene la necesidad de realizar una construcción de calidad, que obtenga resultados

fiables y que funcione eficientemente facilitando y disminuyendo el mantenimiento

futuro.

En esta etapa se inician las pruebas de software, de modo que el programador debe

garantizar que cada módulo funciona correctamente. No será suficiente compilar o

interpretar el lenguaje, sino que deberán probarse todas las circunstancias en el que el

programa pueda ejecutarse a fin de evitar sorpresas posteriores. El programa debe tener

control sobre su ejecución, de modo que en caso de anomalías él mismo debe auditarse e

informar de lo sucedido, para que bien él o la intervención humana tomen una decisión.

Finalmente, en base a los programas desarrollados y procedimientos de control, se

confeccionan los manuales o guías de usuario y de explotación del sistema.

El desarrollo de la aplicación se realizará en Objective-C para que funcione en el sistema

operativo del iPhone (iPhone OS), que es una edición del sistema operativo Mac OS X. En

los siguientes capítulos puede encontrarse una pequeña descripción de los sistemas

operativos y del lenguaje anteriormente mencionados, pero se recomienda la lectura de

[KOCH09] para una profundidad mayor.

115


5.6.1 MAC OS X

El Mac OS X es un sistema operativo desarrollado por Apple, que ha sido incorporado en

los ordenadores Macintosh desde el año 2002. Es el sucesor del Mac OS 9 y está basado

en UNIX basándose en las tecnologías desarrolladas por NeXT desde la década de los 80.

Actualmente la versión más reciente es la 10.6, más conocida como Snow Leopard.

5.6.2 IPHONE OS

El iPhone posee un sistema operativo MacOS en su interior, de hecho, es una versión

reducida y modificada de la versión de escritorio que llevan incorporado todos los

equipos de Apple.

UIKIT Foundation

OpenGL

ESQuartz Core Graphics Core Audio Open AL Media Player

Guía telefónicaCore

FoundationCore Location CFNetwork SQLite

Soporte para

XML

Utilidades del

sistemaNúcleo Mach

Cocoa Touch

Media

Core Services

Core OS (Darwin)

Ilustración 48: Arquitectura del iPhone OS como un conjunto de capas

La capa de Core OS es el nivel más bajo, aquella que tiene el Kernel. La capa de Core

Services tiene los frameworks que permiten manipular colecciones, streams, protocolos

de red, etc. La capa de Media posee los elementos multimedia: video y audio, así como

varias tecnologías para dibujar en 2D o 3D. La capa de Cocoa Touch es la más importante

y puede leerse acerca de ella en la página siguiente.

116


5.6.2.1 COCOA TOUCH, APIS Y FRAMEWORKS DEL IPHONE OS

Cocoa Touch es una evolución del Cocoa de Mac, en el que se han añadido características

para el soporte de la tecnología multitáctil.

Cocoa Touch es la capa más importante del iPhone OS, abarcando dos frameworks

fundamentales: UIKit y Foundation. Éstos forman la interfaz del usuario.

UIKit provee la infraestructura para la implementación de los gráficos, la estructura de

la aplicación, el control de los eventos, el manejo de la interfaz, la representación de las

vistas y los controles, así como el soporte de texto y contenido web.

Foundation define el acceso y manejo de objetos, provee acceso a los tipos de datos

primtivos, colecciones y servicios del sistema operativo.

5.6.2.2 TIPOS DE APLICACIONES EXISTENTES PARA EL IPHONE OS X

Apple define en su HIG8 (ver [WEB004]) tres tipos de aplicaciones para el iPhone, según

las características visuales, el comportamiento y la experiencia del usuario que se desee.

Estos tres tipos son:

1. Aplicaciones de productividad:

Estas aplicaciones permiten realizar tareas basadas en la organización y

manipulación de información detallada. Un ejemplo de este tipo de aplicación es el

gestor de correos electrónicos incorporados en el terminal (Mail).

Este tipo de aplicaciones ayudan al usuario en la tarea que desea realizar,

ayudándole a encontrar rápidamente aquello que busca, a realizar las acciones

necesarias de la manera más sencilla posible.

Típicamente, la interación con una aplicación de productividad consiste en organizar

una lista de elementos, añadir y borrar elementos de dicha lista y navegar a través de

8 Human Interface Guideline

117


sucesivos niveles de detalle hasta alcanzar el nivel apropiado donde realizar tareas.

Generalmente, este tipo de aplicaciones tienen múltiples vistas, mostrando una por

cada nivel de jerarquía. La interfaz suele ser simple y no demasiado customizada,

porque el objetivo está en la información y no en el entorno.

2. Aplicaciones de utilidad:

Este tipo de aplicaciones realizan una tarea sencilla que requiere un input mínimo

por parte del usuario. Puede citarse como ejemplo la aplicación del tiempo incluida

de serie en el terminal.

Las aplicaciones de utilidad son visualmente muy atractivas. Generalmente se

utilizan para consultar el estado de algo o buscar algún tipo de información, por lo

que ésta debe ser fácil de encontrar. Se tiende a organizar la información en una lista

plana de ítems, sin navegar por niveles de información. Cada vista ofrece el mismo

nivel de detalle de los datos, aunque éstos pueden venir de distintas fuentes.

3. Aplicaciones inmersivas:

Este tipo de aplicaciones ofrece un entorno a pantalla completa cuyo objetivo es

enriquecer la experiencia de usuario. Suelen utilizarse generalmente como ocio, sea

en un juego, viendo un video o realizando una tarea.

En este tipo de aplicaciones suele pasarse a segundo plano toda la interfaz del

dispositivo y se sustituye por la interfaz propia de la aplicación. Con esto se consigue

que el usuario se introduzca en el mundo de la aplicación.

Si bien este tipo de aplicaciones puede trabajar con mucha cantidad de información,

no se suele mostrar de forma que los usuarios naveguen por ella secuencialmente o

en varios niveles.

118


5.6.3 OBJECTIVE-C

El único lenguaje de programación válido para desarrollar aplicaciones en el iPhone OS

es Objective-C. Este lenguaje es un superconjunto diseñado por Apple del lenguaje de

programación.

El lenguaje de programación C fue diseñado en los laboratorios de AT&T en la década de

los 70 y Brad J. Cox diseñó Objective-C a principios de los 80. Estaba basado en

SmallTalk-80, un lenguaje de programación de la época. Objective-C se diseñó encima de

C, añadiendo al lenguaje C una extensiones para permitir la programación orientada a

objetos.

NeXT Software se hizo con la licencia de Objective-C en 1988 y desarrolló sus librerías y

un entorno de desarrollo denominado NEXTSTEP. En 1992, Objective-C recibió el apoyo

de la FSF (Free Software Foundation) y dos años más tarde, NeXT y Sun lanzaron una

especificación estandarizada del sistema NEXTSTEP, al que llamaron OPENSTEP. La

versión de la FSF se llamó GNUStep y la versión de Linux, LinuxSTEP.

En diciembre de 1996, Apple anunció la compra de NeXT Software y los entornos de

desarrollo NEXTSTEP/OPENSTEP se convirtieron en la base del nuevo sistema

operativo de Apple, OS X. La versión de este entorno de desarrollo se llamó Cocoa. Con

soporte incluido para desarrollar en Objective-C, herramientas de desarrollo como

Project Builder (o más adelante Xcode) e Interface Builder, Apple creó un entorno de

desarrollo de software tremendamente potente para Mac OS X.

En 2007, Apple lanzó una actualización del lenguaje que se llamó Objective-C 2.0. En ese

mismo año, se lanzó el iPhone y los desarrolladores solicitaron a Apple la posibilidad de

desarrollar aplicaciones para ese dispositivo revolucionario. En un principio, Apple

rechazó esa posibilidad (quería sólo que se desarrollasen aplicaciones web que

corriesen bajo Safari, su navegador web), aunque unos meses después Apple cambió de

opinión y anuncio que se podrían desarrollar aplicaciones nativas para el iPhone. Poco

tiempo después, se puso a disponibilidad de todo el mundo el SDK9 que permitía un

desarrollo rápido de aplicaciones. Este entorno de desarrollo permite a los

9 Entorno de desarrollo de software

119


programadores probar su código en el ordenador, sin tener que pasar la aplicación al

iPhone y probarla en el dispositivo real.

120


5.6.3.1 PARTICULARIDADES DEL LENGUAJE OBJECTIVE-C

Como se ha mencionado anteriormente, Objective-C es un lenguaje de programación

orientado a objetos, aunque conserva muchas características heredadas del lenguaje C,

entre las que pueden encontrarse:

Sentencias de control de flujo

Los tipos de datos fundamentales, estructuras y punteros

Conversiones implícitas y explícitas entre tipos

Los ámbitos de las variables: Globales, locales y estáticas

Las funciones y su sintaxis

Los ficheros de Objective-C poseen las siguientes extensiones:

.c Fichero de código en lenguaje C

.cc o .cpp Fichero de código en lenguaje C++

.h Fichero de cabecera en lenguaje C

.m Fichero de código en lenguaje Objective-C

.mm Fichero de código en lenguaje Objective-C++

.o Fichero compilado (código objeto)

Cada fichero en Objective C posee los siguientes apartados:

@interface

@implementation

@program

La sección @interface describe la clase, los componentes de la clase y sus métodos, la

121


sección @implementation contiene el código que implementa este código y la sección

@program contiene el código de programa.

Al definir una clase hay que realizar varias acciones. Hay que decirle al compilador quién

es la clase padre o superclase. Además hay que especificar qué tipo de datos se van a

guardar en los objetos de esta clase. Finalmente hay que definir qué tipo de operaciones

o métodos se pueden utilizar con los objetos de esta clase. Todo esto se realiza en la

sección @interface, compuesta de la siguiente manera:

@interface clase : superclase

{

variables

}

métodos

@end

Los métodos del interface serán, entre otros, los getters y setters, que permiten acceder

a los atributos de objeto.

La sección @implementation contiene el código de los métodos que se declararon en la

sección @interface. En esta sección se define el código que se declaró en la sección

anterior. La sección @implementation está compuesta de la siguiente manera:

@implementation clase

métodos

@end

La sección @program contiene el código para resolver el problema. Este código puede

estar dividido en varios archivos en caso de ser necesario, pero siempre tiene que haber

una rutina main, donde el programa empezará la ejecución:

int main (int argc, char *argv[])

{

NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];

…

[pool drain];

return 0;

122


}

Cabe destacar que en Objective C hay que solicitar memoria con alloc (allocate en

inglés). Al enviar este mensaje a la clase, se genera una nueva instancia de la clase y pone

a cero todas las variables del objeto. Asimismo, también hay que inicializar el objeto, que

se realiza con el mensaje init (initialize en inglés). También existe la posibilidad de

utilizar el mensaje new, que equivale a usar simultáneamente alloc e init.

Finalmente, al acabar el programa hay que liberar memoria. Esto se realiza con la línea

[pool drain] que libera el pool de memoria y los objetos asociados con él.

123


5.6.4 MODELO VISTA CONTROLADOR

Los diseñadores de Cocoa Touch se guiaron por el concepto de MVC, la manera más

lógica de dividir el código en una aplicación visual. El modelo MVC asegura la máxima

reusabilidad y divide la funcionalidad en tres categorías:

Modelo: clases que contienen los datos de la aplicación

Vista: hecho a partir de ventanas, controles y otros elementos que el usuario ve y

con los que puede interactuar.

Controlador: Enlaza el modelo y la vista. Es la lógica de la aplicación que decide

cómo manejar las acciones del usuario.

El desarrollo de aplicaciones en el iPhone requiere de dos partes muy diferenciadas,

para seguir el paradigma MVC. La primera es la programación que podríamos llamar

orientada a objetos pura, en la que se definen objetos, atributos, métodos, clases, etc.,

todo en el lenguaje Objective-C. La segunda consiste en “dibujar” la pantalla del iPhone.

Gracias a Interface Builder, podemos arrastrar componente a componente e ir

diseñando cada una de las pantallas que formen parte de nuestra aplicación. Una vez

diseñadas, hay que definir qué método es el responsable de cada uno de los

componentes que hemos diseñado. Desde Xcode vemos archivos .xib (XML NextStep

Interface Builder). Estos son los archivos que contiene la información del layout del

iPhone y que ,al intentar editar desde XCode, provocará la apertura automática

deInterface Builder.

En resumen, para desarrollar aplicaciones en el iPhone (cocoa Touch) se crean los

componentes de vista con Interface Builder. El modelo se diseña con clases en Objective-

C para contener los datos de la aplicación. Y el controlador serán también clases en

Objective-C, pero más concretamente serán subclases de controladores genéricos ya

existentes (por ejemplo UIViewController). Al heredar funcionalidad de estos

componentes, se ahorran muchas líneas de código al programar.

124


5.6.4.1 MVC: OUTLETS Y ACTIONS

Al crear controladores, Cocoa Touch introduce el concepto de outlets y actions.

Los outlets son un puntero que apunta a un objeto en el nib (NextStep Interface Builder).

Por ejemplo, si se tiene una etiqueta en la aplicación y se desea cambiar el texto de la

misma, es necesario declarar un outlet que apunte a dicha etiqueta para poder realizar

la acción deseada.

IBOutlet UIButton *boton;

Los actions (métodos de acción) son los métodos que se lanzan desde el nib. Por

ejemplo, cuando el usuario pulse un botón, se lanza un método de acción que ejecuta

cierto código.

-(IBAction) hacerAlgo;

5.6.4.2 DELEGATES Y PROTOCOLS

Cocoa Touch hace un uso extensivo de delegates, que son clases que adquieren la

responsabilidad de realizar ciertas cosas en representación de otro objeto.

La utilización de delegates permite a las aplicaciones implementar comportamiento

común sin tener que hacer subclases o, más aún, saber cómo funciona internamente

cada clase. Por ejemplo, si se tiene cierta parte de código que debe ejecutarse justo antes

de cerrar la aplicación, se implementaría el método applicationWillTerminate: en el

delegate de nuestra aplicación y se pondría el código que se desee que se ejecute aquí. El

utilizar delegates perminte no tener que hacer una subclase de UIApplication y, más aún,

no tener que saber si quiera cómo funciona internamente.

En Objective-C existen protocolos, que son, en funcionalidad idénticos a las interface en

Java o a las clases puras virtuales en C++. Al definir entre <> un protocolo, se está

obligando a implementar ciertos métodos.

Por ejemplo, considerando la siguiente línea de código:

125


@interface Fracciones: NSObject <Imprimir>

y un protocolo

@protocol Imprimir

-(void)imprimirPorPantalla;

@end

habrá que implementar en Fracciones el método imprimir.

126


5.6.5 CICLO DE VIDA DE UNA APLICACIÓN DEL IPHONE

Ilustración 49: Ciclo de vida de una aplicación en el iPhone. Fuente: developer.apple.com/iphone

Como puede verse en la imagen superior, el ciclo de vida de una aplicación en el iPhone

comienza cuando el usuario pulsa en el icono de la misma en la pantalla del terminal.

La aplicación debe tener un método main que será el primero que arranque. Desde este

método se irán cargando aquellos interfaces y módulos que sean necesarios para

empezar a trabajar con la aplicación. Una vez que el método

ApplicationDidFinishLaunching se haya ejecutado, la aplicación habrá terminado de

cargarse y el usuario podrá interactuar con ella.

La aplicación entonces estará a la espera de recibir algún tipo de input por parte del

usuario: tocar la pantalla, pinzar con los dedos, etc.

Si mientras la aplicación está en ejecución entrase una llamada entrante, la aplicación

congelaría su estado y se presentaría al usuario la información de que hay una llamada

entrando para que decida qué hacer con ella. Al finalizar esta llamada (o al rechazarla),

se vuelve al estado anterior de la aplicación. Este es el único caso en que la aplicación

guarda su estado y vuelve a él de manera automática

Una vez que el usuario haya terminado su tarea con la aplicación, pulsará el botón Home

127


del terminal. Esto provocará que se ejecute el método applicationWillTerminate y se

finalice la ejecución de la aplicación.

128


5.6.6 XCODE

Para la programación para el iPhone es necesario utilizar Xcode 3.1.3 (la última versión

disponible en el momento de escritura de este proyecto), que como se ha comentado

anteriormente, es el entorno de desarrollo de software proporcionado por Apple.

Ilustración 50: Inicio de la aplicación XCode 3.1.3

Como se puede ver en la imagen superior, al arrancar el entorno de desarrollo, se ofrece

la posibilidad de comenzar con una plantilla de programación para el iPhone. Esto es

muy útil ya que se comenzará a trabajar con ciertos ficheros ya creados y algunas líneas

de código disponibles.

Asimismo cabe destacar el avanzado entorno de depuración que posee esta herramienta.

Pueden habilitarse múltiples puntos de parada y ver qué valor tiene cada variable en ese

punto. Puede verse una imagen en la página siguiente.

129


Ilustración 51: Entorno de depuración del XCode

130


5.6.6.1 HERRAMIENTAS ADICIONALES AL XCODE

Adicionalmente al XCode, Apple provee otras aplicaciones que son muy útiles para

desarrollar aplicaciones.

Interface Builder:

Es la herramienta de desarrollo visual de la interfaz gráfica de las aplicaciones. Si bien

sería posible desarrollar una aplicación sin utilizar esta herramienta, gracias a ella se

generan interfaces visuales visualmente muy atractivas en poco tiempo.

Instruments:

Es una herramienta de depuración y análisis de las aplicaciones. Mide en tiempo real la

utilización de recursos que realiza la aplicación.

DashCode:

Se trata de una herramienta orientada al desarrollo web del iPhone. Su principal

finalidad es facilitar la tarea de escribir páginas que sean compatibles para el navegador

web del dispositivo (Safari).

iPhone Simulator:

Esta herramienta es un simulador del iPhone. Implementa la API entera del iPhone e

incluye algunas de las aplicaciones nativas del teléfono, como el navegador o los

contactos. Es necesario destacar que dentro de este simulador no funcionarán de

manera correcta las aplicaciones que hagan uso de funciones de GPS o de la cámara de

fotos.

131


5.6.7 DESARROLLO DE LA APLICACIÓN

Utilizando las herramientas anteriormente mencionadas y los requisitos solicitados para

la aplicación se procede a desarrollar la misma.

Como se mencionó previamente, la aplicación cuenta con tres módulos, uno con un

resumen de la guía ITIL, otro con el glosario y otro con el alta de tareas de la aplicación.

Asimismo, se ha incluido un módulo más llamado Acerca De con información de la

aplicación y el autor.

Ilustración 52: Pantalla principal del iphone con la aplicación

La aplicación se inicia al pulsar el botón ITIL tutorial de la imagen superior y se accede a

la pantalla que puede verse en la primera imagen de la página siguiente.

132


5.6.7.1 MÓDULO GUÍA ITIL

Ilustración 53: Pantalla guía ITIL de la aplicación

En la aplicación pueden verse los cuatro apartados en la barra inferior En la barra

superior puede seleccionarse de qué libro de los cinco se desea obtener información. Al

pulsar en cada elemento de esa barra se carga una vista con texto e imágenes que

resumen la información más importante de cada libro.

Esta vista tiene en todos los casos un tamaño mayor que el disponible en la pantalla, por

lo que se permite hacer scroll hacia arriba o abajo para seguir leyendo. En cualquier

caso, las dos barras permanecen fijas.

133


5.6.7.2 MÓDULO GLOSARIO

En este módulo puede verse una lista de aquellos conceptos que son relevantes en ITIL

y, más generalmente, en las TIC. Como puede verse en la imagen siguiente, el usuario

hace scroll hasta encontrar el término que desea obtener información.

Ilustración 54: Vista del glosario de la aplicación

Una vez seleccionado un término, el usuario puede decidir hacer clic para obtener

información. Puede darse la situación de que la información ya la obtenga en esta vista

por ser pequeña, pero normalmente accederá siempre a la información detallada que

134


puede verse en la imagen siguiente:

Ilustración 55: Vista detallada del glosario de la aplicación

En esta pantalla el usuario lee aquella información que le parece relevante y cuando

finalice puede navegar hacia atrás haciendo clic en el botón “Glosario” que se habilita en

la imagen barra superior. También podría navegar directamente hacia otro módulo de la

aplicación.

135


5.6.7.3 MÓDULO ALTA TAREAS ITIL

Cuando el usuario entra por primera vez en cada entrada a la aplicación, este módulo le

preguntará al usuario qué desea hacer, si descargar nuevas tareas o mantener las

actuales. En el caso de que desee mantener las actuales, entrará directamente en el

módulo informándole de qué tareas están pendientes.

Si, por otro lado, desea descargar nuevas tareas, el dispositivo se comunicará con el

servidor para consultar si hay una nueva versión del fichero de tareas asociado a ese

dispositivo. Esta asociación la realiza verificando la fecha del fichero .plist en el terminal

con la fecha de ese fichero en el servidor, asociado este al identifier, un código único que

distingue a cada terminal.

Este código se obtiene gracias a la propia API de Apple implementando el método

[[UIDevice currentDevice] uniqueIdentifier]. Esta línea obtiene un código de 40 cifras

hexadecimal que identifica unívocamente a cada dispositivo. Puede verse en la imagen

inferior que este código también lo utiliza iTunes para comunicarse con los servidores

de Apple e identificar a cada terminal.

Ilustración 56: Vista de iTunes obteniendo el identifier de un iPhone

136


Para que el usuario que desea descargar nuevas tareas disponga de esas nuevas tareas

alguien deberá darlas de alta en la página web. Podrá o bien ser el propio usuario o su

superior en una organización. Para enviar un nuevo fichero de tareas cada usuario

deberá estar dado de alta en la web, y rellenar un formulario con su usuario, contraseña,

identifier y el fichero de tareas a subir.

Ilustración 57: Módulo de tareas de la aplicación

137


5.6.7.4 MÓDULO ACERCA DE

Este es un módulo meramente informativo, donde se indica en la aplicación los datos del

desarrollador de la aplicación.

Ilustración 58: Módulo de Acerca De

138


5.6.7.5 NAVEGACIÓN DE LA APLICACIÓN

La aplicación está pensada para ofrecer un sencillo manejo al usuario, de forma que en

todo momento pueda navegar hacia un u otro módulo. Cuando vuelva a un módulo, éste

recordará en qué punto se había quedado el usuario antes de abandonarlo.

La aplicación siempre se inicia al pulsar el botón en la pantalla de aplicaciones del

iPhone y se termina pulsando el botón home del dispositivo. Por defecto, se carga

siempre el módulo de guía ITIL y la navegación entre pantallas puede verse en la imagen

inferior.

Ilustración 59: Navegación de la aplicación

139


5.6.8 DESARROLLO DE LA PÁGINA WEB

El manual de la aplicación se pondrá a disposición de los usuarios también en una

página web. Para realizar dicho manual, va a basarse en el aspecto que tiene la

previsualización de aplicaciones en el AppStore de iTunes. El objetivo es que la página

web sea muy funcional y llamativa, donde lo que predomine sea la información visual.

Ilustración 60: Estructura de la aplicación Bloomberg en la AppStore en iTunes

Como se requiere que el contenido del manual esté disponible desde cualquier parte del

mundo, primeramente se definirá el dominio de la aplicación. Actualmente se dispone

del dominio www.enriquedediego.com, el cual se usará para el desarrollo de esta página

web. Para no dañar el contenido actual, se ha habilitado el subdominio

pfc.enriquedediego.com para la realización de la página web.

Asimismo, se dispone de un servidor donde se alojarán los ficheros que compongan el

manual. Dicho servidor está compartido en www.dreamhost.com y deben destacarse las

siguientes características técnicas. Para más información ver [WEB005].

140


Tamaño de disco 500GB

Ancho de banda mensual 500GB

Usuarios FTP Ilimitados

Bases de datos MYSQL ilimitados

Soporte de PHP 5 incluido

Soporte de Perl incluido

Soporte de Phyton incluido

Soporte de Subversion incluido

Soporte SSL incluido

Soporte técnico 24/7 incluido

Garantía de 100% tiempo operativo incluido

CPanel incluido

Tabla 3: Características técnicas del servidor de la web

Se estableció anteriormente como requisito desarrollar dos versiones de la página web,

de forma que se llegue a una página diferente según el equipo con el que se acceda. Una

página estará diseñada para el navegador de un ordenador de sobremesa y otra para el

navegador del iPhone (Safari) y para aquellos navegadores de dispositivos que, por sus

propias restricciones no soporten una resolución grande.

La versión móvil de la página será meramente informativa, remitiendo al usuario que en

cuanto sea posible navegue a la versión completa de la página web.

141


5.6.8.1 VERSIÓN ESCRITORIO

La página web estará estructurada en dos zonas, un menú en la parte superior que

permita la navegación por los distintos apartados y una zona informativa bajo el menú.

Cabe destacar tres apartados importantes de la página web:

Un módulo de consulta, donde se puede ver el funcionamiento de la aplicación

Un módulo de alta de tareas, donde se puede emparejar un fichero .plist a un

identificador único de dispositivos Apple.

Un foro de consultas, habilitado para resolver posibles dudas de la aplicación.

Ilustración 61: Pantalla principal de la aplicación

142


5.6.8.1.1 MÓDULO DE USO DE LA APLICACIÓN

Este módulo posee una breve descripción de la aplicación y cómo utilizarla. Como puede

verse en la imagen inferior, en la página web se explica cada pantalla y cómo se utiliza.

Ilustración 62: Página web: apartado de uso de la aplicación

Junto con este módulo, puede entrarse también en capturas de la aplicación, el cual

realiza un pop-up en el que aparece una ventana por la cual puede navegarse

visualizando capturas de la aplicación, de manera similar a como se puede ver en la

AppStore.

143


Ilustración 63: Capturas de la aplicación

144


5.6.8.1.2 MÓDULO DE ALTA DE TAREAS

Este módulo se emplea para emparejar un identificador único de dispositivos Apple a un

fichero .plist. Cuando cada terminal desee descargar una nueva lista de tareas, verificará

contra el servidor su número de identificador y se descargará el fichero .plist

correspondiente al terminal. Para que el usuario sea aceptado por la página web,

previamente deberá haberse dado de alta en el foro.

Ilustración 64: Alta de tareas en la página web

145


5.6.8.1.3 FORO WEB

El foro se ha habilitado para permitir a los usuarios de la aplicación consultar dudas,

ralizar peticiones, etc. Asimismo, sirve para informar públicamente de novedades en la

web o en la aplicación.

El foro se ha desarrollado en la dirección pfc.enriquedediego.com/foro utilizando phpBB,

que es un sistema de foros gratuito basado en un conjunto de paquetes de código

programados en PHP. Este sistema está publicado bajo la licencia GPL, por lo que se

permite su utilización.

Asimismo, utiliza una base de datos MySQL que ha sido creada en el servidor donde está

alojado el foro.

El mantenimiento de este sistema de foros es sencillo y su personalización casi total. Por

ello se ha decidido utilizar este sistema.

En la imagen inferior pueden observarse los foros que actualmente están disponibles en

la página web: noticias, dudas, miscelánea e international.

En el primer foro sólo está habilitada la lectura de mensajes, mientras que en los otros

tres, está habilitada la lectura de mensajes para todo el público y la escritura de

mensajes para aquellos usuarios que previamente se registren en el foro.

Ilustración 65: Foros de la página web

Como puede verse en la imagen inferior, a través de la página web principal también se

ha permitido el acceso al foro.

146


Ilustración 66: Foro desde la página principal de la web

147


5.6.8.2 VERSIÓN MÓVIL

La versión de la página web habilitada para dispositivos móviles está realizada en

pfc.enriquedediego.com/móvil. En esta página web únicamente se realiza una descripción

de la aplicación y se invita al usuario a navegar a la versión de escritorio en cuanto le sea

posible para tener acceso a todas las funcionalidades.

Ilustración 67: Inicio de la versión móvil de la página web

148


Ilustración 68: Vista de la página web versión móvil

149


5.7 PRUEBAS DEL SISTEMA

Para garantizar la consistencia de la aplicación deben realizarse pruebas de:

1. Encadenamiento

Una vez comprobado el correcto funcionamiento de cada componente software,

estas pruebas garantizan la adecuada comunicación entre unos componentes y

otros.

En los subsistemas online, ya se han probado unitariamente tanto los programas

clientes como los servicios a los que llama, pero con las pruebas encadenamiento

se verificarán las comunicaciones y llamadas remotas de unos programas a otros.

2. Integración:

Una vez verificadas las llamadas entre módulos de la aplicación, se procede a

integrar todos sus componentes: bases de datos, ficheros, ventanas, programas,

módulos, transacciones, etc. Esta integración puede realizarse toda ella a la vez, o

por funciones de negocio hasta llegar a integrar todo el sistema.

Conforme se integra una función con sus interfaces de entrada, salida y externos,

se le somete a comprobar su funcionalidad respecto a los requisitos marcados.

Durante estas pruebas de funcionalidad, las herramientas permiten monitorizar

los recursos del sistema para medir y comprobar su rendimiento. Suelen

monitorizarse los recursos de CPU, memoria, disco, tráfico de red y bases de

datos. Como resultado de esta monitorización, se obtienen estadísticas y gráficas

que determinan el consumo de recursos por las transacciones y procesos de la

aplicación.

3. Explotabilidad:

Estas pruebas van encaminadas a determinar la facilidad que ofrece el sistema

para su explotación u operación.

150


4. Seguridad:

Las pruebas de seguridad verifican el correcto funcionamiento de os mecanismos

de seguridad (control de información confidencial, encriptado de información,

firewalls, proxies, directorios LDAP, etc.). En nuestra aplicación, esto queda fuera

del alcance, ya que la información que se maneja es de dominio público.

5. Sobrecarga:

La arquitectura del sistema se habrá definido para poder soportar un acceso

máximo de usuarios concurrentes, y un consumo de recursos adecuado para

evitar la caída del sistema ante la falta de dichos recursos. Deberán establecerse

los condicionantes de operación adecuados para que en los picos de sobrecarga el

sistema pueda continuar funcionando, aunque se degrade su rendimiento.

En nuestra aplicación en concreto, sólo podrá haber un usuario accediendo a la

vez a la aplicación. Sin embargo, es posible que se sobrecargue el dispositivo si se

intenta acceder a muchos datos simultáneamente y/o si el dispositivo está

realizando alguna otra tarea simultáneamente (descarga de correos electrónicos

o reproducción de música).

6. Recuperación:

Las pruebas de recuperación verifican el correcto funcionamiento de la

recuperación de la información. El sistema se habrá diseñado para que se genere

una copia de seguridad ante las actualizaciones que pueda sufrir la base de datos.

En base a esas copias de seguridad y los procesos diseñados al efecto, se podrá

reconstruir y recuperar esta información.

7. Regresión:

Dado que al subsanar un error de programación, pueden cometerse otros, suelen

151


volverse a repetir las pruebas donde intervinieron estos componentes para

verificar su funcionamiento correcto. Estas pruebas son las que se conocen como

de regresión.

8. Aceptación de Usuario:

Junto con las pruebas de usabilidad, estas pruebas son realizadas por el usuario

(desde el entorno de pruebas o el entorno de trabajo). El objetivo de estas

pruebas es validar el sistema desde el punto de vista funcional y operativo.

Generalmente utilizará el manual de Usuario para guiarse por la navegación del

sistema, según cada función de negocio. Esta aceptación significa únicamente la

conformidad del usuario con la aplicación desarrollada.

9. Usabilidad:

El objetivo de las pruebas de usabilidad es verificar la facilidad de uso del sistema

que el usuario debe manejar. Esta facilidad de uso se refiere al diseño de la

interfaz de usuario y al Manual de Usuario.

Durante estas pruebas puede formarse al personal que va a utilizar el nuevo

sistema, aunque el plan de formación puede realizarse en otras etapas.

Para todas estas pruebas Apple provee a los desarrolladores de Instruments, una

potentísima herramienta capaz de monitorizar los recursos de cualquier aplicación para

Mac o iPhone. Es capaz de analizar la memoria utilizada, qué procesos están corriendo

en la aplicación, qué fallos existen, etc.

152


Ilustración 69: Aplicación Instruments analizando una aplicación del iPhone

Para asegurar que los resultados de las pruebas de integración, explotabilidad,

sobrecarga y satisfacción dieran los resultados esperados, se realizaron estas pruebas

varias veces a lo largo del desarrollo de la aplicación. Se guardaron varias versiones de

los módulos y se desarrolló en paralelo todos los módulos.

Por otro lado, para garantizar que la aplicación satisface las necesidades de los usuarios

y que su usabilidad es buena, se mostró la aplicación y la página web a varios expertos

para recibir su aprobación.

153


5.8 IMPLANTACIÓN

Una vez realizadas todas las pruebas de la aplicación, se procede a su implantación. Para

ello, se somete a aprobación por parte de Apple la aplicación construida.

Una vez aprobada la aplicación, pasará a quedar publicada en la AppStore, disponible

para la descarga. Los usuarios deberán descargarla e instalarla en su terminal. Cuando

arranquen la aplicación podrán utilizar todas las funciones a excepción de las tareas

ITIL. Para poder utilizar este módulo, deberán haberse dado de alta en la página web,

identificando unívocamente su terminal y actualizando su lista de tareas.

La documentación de la aplicación podrán encontrarla en internet, pudiendo conectarse

desde su terminal o desde un ordenador de sobremesa.

154


5.9 MANTENIMIENTO

Aunque en la fase de implantación queda finalizado el desarrollo del sistema, es preciso

realizar una labor de mantenimiento. Una vez implantado el sistema podrían surgir

errores o situaciones anómalas que no aparecieron en las pruebas. En ese caso, se

procederá a subsanar dichos errores (mantenimiento correctivo).

Asimismo, también podría ocurrir que se decidiese ampliar la aplicación, decidiendo

que realizase más tareas, se comunique con más equipos, etc. En dicho caso, se realizaría

un mantenimiento adaptativo, por el que habría que realizar un nuevo acuerdo con el

cliente, estimar un nuevo precio para aquellas funciones nuevas, etc.

Por último, también habrá que contar con la opción de ofrecer al cliente soporte técnico,

de modo que si tiene alguna duda, o simplemente desea contactar con nosotros, pueda

hacerlo por medio de un help desk. Éste tiene el objetivo de asesorar al usuario final en

la utilización del sistema.

155


6. Establecimiento del precio de la aplicación

156


6.1 CONSIDERACIONES INICIALES Y LIMITACIONES

Es importante tener en cuenta que aunque la aplicación está destinada para uso

empresarial, no podrá ser comprada por volúmenes, ya que cada usuario deberá

descargarla desde iTunes de manera individual.

Asimismo, se encuentran algunas limitaciones para publicar las aplicaciones en la

AppStore, que podrían impactar en la aprobación de la misma:

Para poder publicar aplicaciones en la AppStore, es necesario darse de alta como

desarrollador de Apple.

No pueden utilizarse más frameworks que aquellos que ponga Apple a

disposición de los usuarios.

Las aplicaciones no podrán tener un tamaño superior a 2 gigabytes.

Apple se reserva el derecho a aceptar o rechazar cada aplicación.

157


6.2 MODELO DE NEGOCIO DE LA APPSTORE DE APPLE:

Al lanzar la versión 2.0 del firmware del iPhone, Apple habilitó el desarrollo de

aplicaciones nativas para el dispositivo. Para los desarrolladores existen dos maneras de

publicar la aplicación, pero en ambos casos se tendrá que dar de alta como desarrollador

de Apple.

Elegir que la aplicación sea gratuita. En este caso Apple pone a disposición de todos los

usuarios de iTunes dicha aplicación, de manera totalmente gratuita para el público y sin

costes para el desarrollador. Apple se encarga de pagar el ancho de banda necesario, el

espacio en el servidor, etc.

En el caso de que el desarrollador desee cobrar por la aplicación, él será el que decida

qué precio ponerle. Desde 0,79€ hasta 999€. De esta cantidad, el desarrollador recibirá

el 70% y Apple se quedará con el 30% restante. En este caso, también Apple se encarga

de pagar el ancho de banda o el espacio en el servidor.

Para desarrollar aplicaciones para el iPhone, es necesario descargar el SDK que Apple

pone a disposición del público en general. Tan sólo es necesario registrarse para

comenzar a descargar el entorno de desarrollo.

A día de hoy es únicamente posible instalar el SDK sobre un Sistema Operativo Mac OSX,

siendo el resto de plataformas inútiles para desarrollar estas aplicaciones.

Una vez se haya terminado de desarrollar la aplicación, para poder subirla a la AppStore,

es necesario adquirir una licencia de desarrollador de Apple:

1. Adquirir la licencia individual que tiene un coste de 79€/año

2. Adquirir la licencia empresarial con un coste de 229€/año

La diferencia entre ambas es que en la primera la aplicación se publica bajo el nombre

del desarrollador y en la segunda es el nombre de la empresa el que figura. Asimismo,

con la segunda opción es posible distribuir aplicaciones ‘in-house’: hasta 100 empleados

pueden trabajar de testers de la aplicación. Esta aplicación se distribuye internamente,

no teniendo que pasar por la AppStore.

158


6.3 DISCUSIONES INICIALES ACERCA DEL PRECIO DE LA APLICACIÓN

Durante el mes de abril de 2010 tuvo lugar en Seattle, Washington una conferencia de

desarrolladores de Apple. En esta conferencia, Jeffrey Hughes presentó un estudio sobre

el precio actual de las aplicaciones de la AppStore. El 24 de abril de 2010 el precio medio

de una aplicación era $3.04. Por otro lado, los juegos presentaban un precio medio de

$1.39, por lo que la media del precio total de todas las aplicaciones estaba en $2.79.

Asimismo, se presentaron otros datos importantes, como por ejemplo que cada día se

someten a aprobación 524 aplicaciones y 96 juegos. Tardan una media de 3.26 días en

ser aprobados y como máximo se ha tardado en aprobar una aplicación 50 días.

Finalmente comentan que hay 190.000 aplicaciones disponibles para descarga y 37.000

desarrolladores activos (que han sometido a aprobación al menos una aplicación).

Al ir la aplicación destinada a entorno empresarial, tendrá que tener un precio acorde.

Es un punto a tener en cuenta que actualmente no existe ninguna aplicación similar en la

AppStore. Esto tiene ventajas e inconvenientes claros. Como ventaja fundamental se

encuentra la exclusividad y la ventaja de ser pionero. Sin embargo, no es posible basarse

en el precio de otras aplicaciones para estimar el de la aplicación.

Tras consultar a varios expertos, la aplicación no debería tener un precio inferior a 10€.

El motivo de ello es que la aplicación no es susceptible a bajar de precio como otras

existentes en la tienda. Como ejemplo pueden ponerse los juegos que, tras un gran

número de descargas iniciales al precio de salida, éstas decrecen con el tiempo (al cesar

la novedad). Para incitar a las ventas, los desarrolladores de estas aplicaciones,

disminuyen el precio.

Por otro lado, consideran que una aplicación destinada a un entorno empresarial que

tenga un coste inferior al anteriormente mencionado da la sensación de aplicación de

“baja calidad”.

Para calcular el precio al que debería venderse la aplicación va a calcularse la valoración

económica del proyecto y después, teniendo en cuenta todas las consideraciones

iniciales se estimará el mejor precio para poner a la venta la aplicación.

159


6.4 VALORACIÓN ECONÓMICA DEL PROYECTO

Para calcular el valor económico de este proyecto se han tenido en cuenta dos factores

principales:

Inversión para darse de alta en la AppStore

Tiempo dedicado para el desarrollo de este proyecto

El motivo de tener en cuenta únicamente estos dos factores se debe a que ya se disponía

del equipo informático necesairo para desarrollar el proyecto. En caso de que no se

tuvieran, habría que añadir también el precio de un ordenador Apple y el de un iPhone o

iPod Touch para realizar las pruebas.

La inversión para darse de alta en la AppStore ya se ha mencionado: 79€/año. Para

calcular el coste de la aplicación van a realizarse unas pequeñas estimaciones.

El precio de venta de una aplicación se calcula como:

º * * * *Pv N h Kcpt Ceh Kg Gd

Donde:

Nºh representa el número de horas que se ha dedicado a desarrollar la aplicación,

Kcpt es un valor que oscila entre 2,1 y 2,5

Ceh representa el coste por hora del trabajador para la empresa

Kg es un valor que oscila entre 1,2 y 1,5

Gd es la suma de los gastos

Actualmente el salario bruto medio de un ingeniero informático recién titulado son

22.000€/año10.

Sumando a esta cantidad el 30% que la empresa paga a la Seguridad Social

(6.600€/año), tenemos que el coste anual del trabajador para la empresa son:

10 Estimación realizada analizando ofertas de trabajo para ingenieros informáticos superiores recién licenciados en la Comunidad de Madrid. Fuente: infojobs.net y monster.es

160


22.000€ 30%(22.000€) 28.600€

Se calcula que el número de horas aproximado por trabajador al año son

aproximadamente 1800.

Conocido el número de horas de trabajo al año se calcula el coste por hora del trabajador

para la empresa:

28.600€ /1.800 15,9€ /h h

Van a considerarse los valores mínimos de los valores Kcpt y Kg, por lo que tomarán,

respectivamente 2.1 y 1.2.

En el número de horas empleadas va a considerarse 300h, puesto que es el máximo

teórico que debería llevar el desarrollo de un proyecto final de carrera, si bien en este

caso el número de horas reales fue mayor.

El precio de venta será, por tanto:

º * * *Pv N h Kcpt Ceh Kg Gd

300 *2,1*15,9€ / 1,2*79€Pv h h

Pv = 10130,76€

161


6.4.1 VALORACIÓN ECONÓMICA DEL PROYECTO INCLUYENDO TODOS LOS

GASTOS

En el caso de que no se hubiese tenido el equipo apropiado, habría que modificar los

cálculos anteriores, incluyendo el coste de un ordenador Apple y un terminal iPhone o

iPod Touch:

Actualmente el ordenador más económico de Apple es un MacMini, que junto a una

pantalla puede conseguirse por 600€. Y el terminal más económico para probar la

aplicación es actualmente un iPod Touch de 16GB que puede conseguirse por 230€. Esta

información se ha obtenido de www.apple.com/es/store.

Por tanto, hay que añadir a los gastos de alta en la AppStore, estos otros:

º * * *Pv N h Kcpt Ceh Kg Gd

300 *2,1*15,9€ / 1,2* (79€ 600€ 230€)Pv h h

Pv = 11107,8€

162


6.4.2 VALORACIÓN ECONÓMICA DEL PROYECTO EXCLUYENDO BENEFICIOS

Va a calcularse un último precio de venta en el que se excluyen los beneficios. El objetivo

de esto será calcular el break-even más adelante.

Para excluir los beneficios de la fórmula anteriormente utilizada, va a prescindirse de los

valores K, por lo que la fórmula en este caso quedará de la siguiente manera:

º *Pv N h Ceh Gd

Asimismo, va a obviarse incluir el precio de un ordenador Apple o un terminal de

pruebas, teniendo únicamente en cuenta el precio del alta en la AppStore.

300 *15,9 79€Pv h

Pv = 4849€

163


6.5 ANÁLISIS DE ESCENARIOS

A continuación va a realizarse un análisis de escenarios en el que se van a simular

distintos precios y distinto volumen de descargas de la aplicación para calcular un

precio final para la aplicación y estimar el número de descargas necesarias para

recuperar la inversión realizada.

Suponiendo que se establece el precio de la aplicación en 5€:

Número de Descargas Anuales

Precio de la aplicación

Ingresos anuales

30% de ingreso para Apple

70% de ingresos

5 5,00 € 25,00 € 7,50 € 17,50 €

10 5,00 € 50,00 € 15,00 € 35,00 €

15 5,00 € 75,00 € 22,50 € 52,50 €

25 5,00 € 125,00 € 37,50 € 87,50 €

50 5,00 € 250,00 € 75,00 € 175,00 €

75 5,00 € 375,00 € 112,50 € 262,50 €

100 5,00 € 500,00 € 150,00 € 350,00 €

200 5,00 € 1.000,00 € 300,00 € 700,00 €

350 5,00 € 1.750,00 € 525,00 € 1.225,00 €

500 5,00 € 2.500,00 € 750,00 € 1.750,00 €

750 5,00 € 3.750,00 € 1.125,00 € 2.625,00 €

1000 5,00 € 5.000,00 € 1.500,00 € 3.500,00 €

1500 5,00 € 7.500,00 € 2.250,00 € 5.250,00 €

2000 5,00 € 10.000,00 € 3.000,00 € 7.000,00 €

3000 5,00 € 15.000,00 € 4.500,00 € 10.500,00 €

5000 5,00 € 25.000,00 € 7.500,00 € 17.500,00 €

7500 5,00 € 37.500,00 € 11.250,00 € 26.250,00 €

164


Suponiendo que la aplicación cuesta 10€:

Número de Descargas

Anuales

Precio de la

aplicación

Ingresos

anuales

30% de ingreso para

Apple

70% de

ingresos

5 10,00 € 50,00 € 15,00 € 35,00 €

10 10,00 € 100,00 € 30,00 € 70,00 €

15 10,00 € 150,00 € 45,00 € 105,00 €

25 10,00 € 250,00 € 75,00 € 175,00 €

50 10,00 € 500,00 € 150,00 € 350,00 €

75 10,00 € 750,00 € 225,00 € 525,00 €

100 10,00 € 1.000,00 € 300,00 € 700,00 €

200 10,00 € 2.000,00 € 600,00 € 1.400,00 €

350 10,00 € 3.500,00 € 1.050,00 € 2.450,00 €

500 10,00 € 5.000,00 € 1.500,00 € 3.500,00 €

750 10,00 € 7.500,00 € 2.250,00 € 5.250,00 €

1000 10,00 € 10.000,00 € 3.000,00 € 7.000,00 €

1500 10,00 € 15.000,00 € 4.500,00 € 10.500,00 €

2000 10,00 € 20.000,00 € 6.000,00 € 14.000,00 €

3000 10,00 € 30.000,00 € 9.000,00 € 21.000,00 €

5000 10,00 € 50.000,00 € 15.000,00 € 35.000,00 €

7500 10,00 € 75.000,00 € 22.500,00 € 52.500,00 €

165


Suponiendo que la aplicación quedase establecida en 20€:


Anuales

Precio de la

aplicación

Ingresos

anuales

30% de ingreso para

Apple

70% de

ingresos

5 15,00 € 75,00 € 22,50 € 52,50 €

10 15,00 € 150,00 € 45,00 € 105,00 €

15 15,00 € 225,00 € 67,50 € 157,50 €

25 15,00 € 375,00 € 112,50 € 262,50 €

50 15,00 € 750,00 € 225,00 € 525,00 €

75 15,00 € 1.125,00 € 337,50 € 787,50 €

100 15,00 € 1.500,00 € 450,00 € 1.050,00 €

200 15,00 € 3.000,00 € 900,00 € 2.100,00 €

350 15,00 € 5.250,00 € 1.575,00 € 3.675,00 €

500 15,00 € 7.500,00 € 2.250,00 € 5.250,00 €

750 15,00 € 11.250,00 € 3.375,00 € 7.875,00 €

1000 15,00 € 15.000,00 € 4.500,00 € 10.500,00 €

1500 15,00 € 22.500,00 € 6.750,00 € 15.750,00 €

2000 15,00 € 30.000,00 € 9.000,00 € 21.000,00 €

3000 15,00 € 45.000,00 € 13.500,00 € 31.500,00 €

5000 15,00 € 75.000,00 € 22.500,00 € 52.500,00 €

7500 15,00 € 112.500,00 € 33.750,00 € 78.750,00 €

166


Suponiendo que el precio fuesen 25€


Anuales

Precio de la

aplicación

Ingresos

anuales

30% de ingreso para

Apple

70% de

ingresos

5 25,00 € 125,00 € 37,50 € 87,50 €

10 25,00 € 250,00 € 75,00 € 175,00 €

15 25,00 € 375,00 € 112,50 € 262,50 €

25 25,00 € 625,00 € 187,50 € 437,50 €

50 25,00 € 1.250,00 € 375,00 € 875,00 €

75 25,00 € 1.875,00 € 562,50 € 1.312,50 €

100 25,00 € 2.500,00 € 750,00 € 1.750,00 €

200 25,00 € 5.000,00 € 1.500,00 € 3.500,00 €

350 25,00 € 8.750,00 € 2.625,00 € 6.125,00 €

500 25,00 € 12.500,00 € 3.750,00 € 8.750,00 €

750 25,00 € 18.750,00 € 5.625,00 € 13.125,00 €

1000 25,00 € 25.000,00 € 7.500,00 € 17.500,00 €

1500 25,00 € 37.500,00 € 11.250,00 € 26.250,00 €

2000 25,00 € 50.000,00 € 15.000,00 € 35.000,00 €

3000 25,00 € 75.000,00 € 22.500,00 € 52.500,00 €

5000 25,00 € 125.000,00 € 37.500,00 € 87.500,00 €

7500 25,00 € 187.500,00 € 56.250,00 € 131.250,00 €

Como quedó calculado en el punto 6.2.2, el coste del desarrollo de la aplicación sin

contar beneficios son 4849€.

Teniendo en cuenta que el número de descargas * 70% del precio debe ser igual a

4849€, puede calcularse que para conseguir esta cantidad, tendrían que producirse al

menos:

Número de descargas Precio

1386 5€

693 10€

462 15€

278 25€

167


6.6 DECISIÓN FINAL

Teniendo en cuenta los datos presentados en la conferencia de Seattle, la opinión de los

expertos y el análisis de escenarios, se ha decidido que la aplicación debería tener un

precio cercano a los 10€. Si bien es cierto que hay opiniones contradictorias acerca de

esta decisión, las pruebas del número de aplicaciones descargadas parecen tener un

mayor peso.

Como táctica de precio psicológico se utilizará el precio de 9.99€. A continuación puede

verse una estimación de los beneficios que se obtendrían de la aplicación según el

número de descargas teniendo en cuenta el precio decidido:

Número de Descargas Anuales

Precio de la aplicación

Ingresos anuales

30% de ingreso para Apple

70% de ingresos

5 9,99 € 49,95 € 14,99 € 34,97 €

10 9,99 € 99,90 € 29,97 € 69,93 €

15 9,99 € 149,85 € 44,96 € 104,90 €

25 9,99 € 249,75 € 74,93 € 174,83 €

50 9,99 € 499,50 € 149,85 € 349,65 €

75 9,99 € 749,25 € 224,78 € 524,48 €

100 9,99 € 999,00 € 299,70 € 699,30 €

200 9,99 € 1.998,00 € 599,40 € 1.398,60 €

350 9,99 € 3.496,50 € 1.048,95 € 2.447,55 €

500 9,99 € 4.995,00 € 1.498,50 € 3.496,50 €

750 9,99 € 7.492,50 € 2.247,75 € 5.244,75 €

1000 9,99 € 9.990,00 € 2.997,00 € 6.993,00 €

1250 9,99 € 12.487,50 € 3.746,25 € 8.741,25 €

1500 9,99 € 14.985,00 € 4.495,50 € 10.489,50 €

2000 9,99 € 19.980,00 € 5.994,00 € 13.986,00 €

2500 9,99 € 24.975,00 € 7.492,50 € 17.482,50 €

3000 9,99 € 29.970,00 € 8.991,00 € 20.979,00 €

3500 9,99 € 34.965,00 € 10.489,50 € 24.475,50 €

4000 9,99 € 39.960,00 € 11.988,00 € 27.972,00 €

4500 9,99 € 44.955,00 € 13.486,50 € 31.468,50 €

5000 9,99 € 49.950,00 € 14.985,00 € 34.965,00 €

6500 9,99 € 64.935,00 € 19.480,50 € 45.454,50 €

7000 9,99 € 69.930,00 € 20.979,00 € 48.951,00 €

8000 9,99 € 79.920,00 € 23.976,00 € 55.944,00 €

9000 9,99 € 89.910,00 € 26.973,00 € 62.937,00 €

10000 9,99 € 99.900,00 € 29.970,00 € 69.930,00 €

168


7. Plan de proyecto

169


7. PLAN DE PROYECTO

Ilustración 70: Plan de proyecto

Como puede verse en la imagen superior, el proyecto ha llevado aproximadamente un

año. Comenzando en el mes de julio de 2009, no se ha finalizado hasta finales de mayo

de 2010.

Asimismo, puede observarse que un gran número de tareas han sido realizadas en

paralelo. La razón de ello es que era necesario adquirir conocimiento sobre varios temas

no relacionados directamente: programación en Objective-C, estructura y contenido de

ITIL y COBIT, analizar qué regulaciones afectan a las organizaciones, etc.

Por otro lado, debido a que gran parte del proyecto ha sido realizado desde el

extranjero, era necesario avanzar por varios frentes para comunicar las mejoras al

proyecto en bloque.

Las entrevistas con los expertos se han llevado a cabo de manera continuada durante

todo el proyecto, puntualmente consultando dudas y aclarando conceptos. Aparte de

ésta, las otras tareas que mayor duración han llevado, han sido el aprendizaje en la

programación en Objective-C y la programación de la aplicación. Esto se debe que se

tenía un desconocimiento total del desarrollo de aplicaciones para esta plataforma y su

alta curva de aprendizaje que tiene.

170


8. Conclusiones

171


8. CONCLUSIONES DEL PROYECTO

El desarrollo del proyecto ha servido para conocer COBIT y profundizar en el

conocimiento de ITIL. Además, se ha descubierto que hay un potencial impresionante

para el desarrollo e implantación de estas guías en todas las organizaciones.

Se ha visto que ITIL es un conjunto de libros que informan de cómo proveer servicios de

Tecnologías de la Información de calidad. Por otro lado, COBIT, perteneciente a la

organización ISACA, es un marco de control de aceptación internacional como buena

práctica para el control de la información. Dentro de una organización se sitúa en un

nivel más alto que ITIL, pudiéndose simultanear ambas sin problemas, tal y como han

confirmado los directivos a los que se ha entrevistado.

En estas entrevistas ha quedado patente, además, que en España ITIL está en una etapa

algo más madura que COBIT, por lo que se vio más interesante centrarse en los procesos

ITIL a la hora de desarrollar la aplicación. Los expertos, altos cargos en organizaciones

de diferente índole, comentaron en qué situación se encontraban con respecto a ITIL y

COBIT, cuál se había introducido primero y por qué, qué dificultades habían encontrado

y cuál de las dos les parecía más interesante.

Los expertos comentaron que según quién sea la parte de la organización que más tire

habrá sido ITIL o COBIT aquella que se introdujese primeramente. Si la dirección de

sistemas fue la que más influencia ejerció, probablemente se habrá comenzado por ITIL,

mientras que la introducción de COBIT generalmente viene forzada por parte de los

auditores.

Por otro lado, comentaron que las dificultades principales a la hora de introducir desde

cero alguna de las dos guías, es el intento de realizarlo todo de golpe, lo que garantiza un

fracaso seguro. Para conseguir buenos resultados, todos los expertos coincidieron en

que la mejor manera de proceder es implementar los procesos poco a poco. Una vez que

los primeros procesos estén maduros, podrá pasarse al siguiente grupo de procesos y así

continuar hasta que la implementación esté completada.

En general, todos los expertos tenían un gran conocimiento de ITIL, mientras que no

todos sabían de la existencia de COBIT. De manera resumida, la percepción general de

estos directivos fue que ITIL dice cómo hay que realizar los procesos y COBIT verifica

172


que se están haciendo correctamente.

En la situación actual en la que nos encontramos, donde las comunicaciones y los

servicios forman parte de nuestras vidas a todas horas, cada vez son y serán más las

organizaciones que se decanten por utilizar servicios de otras o por desarrollar y poner

a disposición del mundo sus propios servicios. Para ello será de gran ayuda tener como

referencia estas guías de mejores procesos, como ITIL y herramientas como la

desarrollada.

El desarrollo de esta aplicación, cuyo desarrollo ha sido supervisado por varios expertos

en el tema, ayudará las organizaciones y personas interesadas a conocer qué es ITIL y

qué pueden hacer ellos para optimizar sus procesos.

Además, es muy probable que en un breve intervalo de tiempo se comience a ver a

consultoras asesorando a todo tipo de organizaciones a cómo transformar sus procesos

en procesos ITIL, optimizados y estandarizados. Ya hoy día empieza a crecer el número

de organizaciones interesadas en adquirir formación ITIL, por lo que es probable que

esta herramienta les ayude.

173


9. Futuros desarrollos

174


9. FUTUROS DESARROLLOS

Si bien la aplicación satisface las necesidades de un selecto grupo de personas, podría

darse el caso que el público en general necesite otro tipo de aplicación, más

funcionalidades para la misma, etc.

Por ello las futuras líneas de trabajo irán por analizar sobre el terreno qué opinión tiene

el público sobre la aplicación y la página web.

La integración de las tareas tiene muchos puntos de mejora, entre los que cabría

priorizar: guardar un histórico de las mismas, borrar y añadir tareas desde los

terminales, integrarlas con otra aplicación, etc.

Será importante verificar también que los futuros desarrollos de ITIL quedan recogidos

en nuevas versiones de la aplicación.

Asimismo, será interesante desarrollar versiones de esta aplicación para otras

plataformas. Actualmente acaba de ser presentado Android 3 y se prevé un crecimiento

potencial espectacular de los terminales que utilizarán el sistema operativo de Google.

La integración de esta aplicación con versiones de escritorio e incluso portar toda la

funcionalidad a la web podría ser otra línea de trabajos futuros.

Finalmente, la internacionalización de la aplicación es otro importante foco de mejora a

tener en cuenta. Actualmente la aplicación está preparada para soportar varios idiomas,

pero habrá que garantizar que la localización de la aplicación satisface los requisitos de

las organizaciones en los nuevos países donde se vaya a implantar.

175


10. Bibliografía

176


10. BIBLIOGRAFÍA

La bibliografía utilizada para este proyecto es amplia, por lo que se ha dividido la misma

según la fuente utilizada: libros, e-books o internet.

10.1 LIBROS

[BARR01] Barranco de Areba, Jesús: “Metodología del análisis estructurado de

sistemas”, Publicaciones de la Universidad Pontificia Comillas, 2001.

[ISAC10] ISACA, Madrid Chapter: “Marco para la Auditoría de los Sistemas de

Información”, ISACA Madrid Chapter, 2010.

[DUDN09] Dudney, Bill & Adamson, Bill: “iPhone SDK Development”, The

Pragmatic Bookshelf. 2009.

[KEMM04] Kemmerling, Georges & Pondman, Dick: “Gestión de Servicios TI, una

introducción a ITIL”, Van Haren Publishing, 2004.

[KOCH09] Kochan, Steven: “Programming in Objective-C 2.0”, Addison Weasley,

2009.

[LAMA09a] Lamarche, Jeff & Mark, David: “Beginning iPhone 3 Development:

Exploring the SDK”, Apress, 2009.

[LAMA09b] Lamarche, Jeff & Mark, David: “More iPhone 3 Development: Tacking

SDK 3”, Apress, 2009.

[LONG08] Long, Jong: “ITIL Version 3 at a Glance”, Springer, 2008.

[MART04] Martin, Rober: “UML para programadores JAVA”, Pearson Prentice

Hall, 2004.

[OGC07a] Office of Government Commerce: “ITIL v3. The Official introduction to

the ITIL Service Lifecycle”, United Kingdom for the Stationery Office,

177


2007.

[OGC07b] Office of Government Commerce: “ITIL v3. Service Strategy”, United

Kingdom for the Stationery Office, 2007.

[OGC07c] Office of Government Commerce: “ITIL v3. Service Design”, United


[OGC07d] Office of Government Commerce: “ITIL v3. Service Transition”, United


[OGC07e] Office of Government Commerce: “ITIL v3. Service Operation”, United


[OGC07f] Office of Government Commerce: “ITIL v3. Continual Service

Improvement”, United Kingdom for the Stationery Office, 2007.

[PILO09] Pilone, Dan & Pilone, Tracey: “Head First iPhone Development: A

Learner’s Guide to Creating Objective-C Applications for the iPhone”,

Oreilly, 2009.

[PIAT07] Piattini, Mario & Hervada, Fernando: “Gobierno de las Tecnologías y

los Sistemas de Información”, Ra-Ma, 2007.

[PIPE09] Piper, Ian: “Learn XCode Tools for MacOS X and iPhone Development”,

Apress, 2009.

[RYAN10] Ryan, Robert & Raducha-Grace, Tim: “The business of IT, how to

Improve Service and Lower Costs”, IBM Press, 2010.

[ZDZI08] Zdziarski, Jonathan: “iPhone Open Application Development”, Oreilly,

2008.

[ZDZI09] Zdziarski, Jonathan: “iPhone SDK Application Development”, Oreilly,

2009.

178


10.2 E-BOOKS

[ITGI07a] IT Governance Institute: “COBIT 4.1”, IT Governance Institute, 2007.

[ITGI07b] IT Governance Institute: “IT Control Objectives for Basel II”, IT

Governance Institute, 2007

[ITGI08a] IT Governance Institute: “Aligning COBIT 4.1, ITIL v.3 and ISO 27002

for business benefit”, IT Governance Institute, 2008.

[ITGI08b] IT Governance Institute: “COBIT Mapping: Mapping of ITIL v3 with

COBIT 4.1”, IT Governance Institute, 2008.

10.3 INTERNET

[WEB001] http://www.apple.com/es/iphone/specs.html “Especificaciones

oficiales del iPhone”

[WEB002] http://www.isaca.org “Página web oficial de ISACA”

[WEB003] http://www.itil-officialsite.com “Página web oficial de ITIL”

[WEB004] http://developer.apple.com/iphone “Página web oficial para el

desarrollo de aplicaciones para el iphone”

[WEB005] http://www.dreamhost.com “Hosting donde se encuentra alojado

[WEB006]”

[WEB006] http://pfc.enriquedediego.com “Documentación relacionada con la

aplicación”

[WEB007] http://pfc.enriquedediego.com/movil “Adaptación para dispositivos

móviles de la documentación relacionada con la aplicación”

http://www.apple.com/es/iphone/specs.html

http://www.isaca.org/

http://www.itil-officialsite.com/

http://developer.apple.com/iphone

http://www.dreamhost.com/

http://pfc.enriquedediego.com/

http://pfc.enriquedediego.com/movil

179


11. Anexos

180


11. ANEXOS

A continuación pueden encontrarse varios anexos al proyecto:

11.1 CMMI

Es un modelo de calidad del software que clasifica las empresas en niveles de madurez.

Estos niveles sirven para conocer la madurez de los procesos que se realizan para

producir software.

Los niveles CMM - CMMI son 5:

Inicial o Nivel 1 CMM - CMMI. Este es el nivel en donde están todas las empresas

que no tienen procesos. Los presupuestos se disparan, no es posible entregar el

proyecto en fechas…

Repetible o Nivel 2 CMM – CMMI. Quiere decir que el éxito de los resultados

obtenidos se pueden repetir. La principal diferencia entre este nivel y el anterior

es que el proyecto es gestionado y controlado durante el desarrollo del mismo. El

desarrollo no es opaco y se puede saber el estado del proyecto en todo momento.

Los procesos que hay que implantar para alcanzar este nivel son:

Gestión de requisitos

Planificación de proyectos

Seguimiento y control de proyectos

Gestión de proveedores

Aseguramiento de la calidad

Gestión de la configuración

Definido o Nivel 3 CMM - CMMI. Alcanzar este nivel significa que la forma de

desarrollar proyectos (gestión e ingeniería) esta definid. Con definida se quiere

decir que esta establecida, documentada y que existen métricas (obtención de

181


datos objetivos) para la consecución de objetivos concretos. Los procesos que hay

que implantar para alcanzar este nivel son:

Desarrollo de requisitos

Solución Técnica

Integración del producto

Verificación

Validación

Desarrollo y mejora de los procesos de la organización

Definición de los procesos de la organización

Planificación de la formación

Gestión de riesgos

Análisis y resolución de toma de decisiones

Cuantitativamente Gestionado o Nivel 4 CMM - CMMI. Los proyectos usan

objetivos medibles para alcanzar las necesidades de los clientes y la organización.

Se usan métricas para gestionar la organización. Los procesos que hay que

implantar para alcanzar este nivel son:

Gestión cuantitativa de proyectos

Mejora de los procesos de la organización

Optimizado o Nivel 5 CMM - CMMI. Los procesos de los proyectos y de la

organización están orientados a la mejora de las actividades. Mejoras

incrementales e innovadoras de los procesos que mediante métricas son

identificadas, evaluadas y puestas en práctica. Los procesos que hay que

implantar para alcanzar este nivel son:

Innovación organizacional

182


Análisis y resolución de las causas

Normalmente las empresas que intentan alcanzar los niveles 4 y 5 lo realizan

simultáneamente ya que están muy relacionados.

Nivel 0

Inexistente

Nivel de documentación, notoriedad y monitorización

Nivel 1

Inicial/Ad H

oc

Nivel 2

Repetible

Nivel 3

Proceso definido

Nivel 4

Gestionado y m

edible

Nivel 5

Optim

izado

Eficie

ncia

op

era

tiva

y d

e d

ise

ño

Ilustración 71: Niveles CMMI

183


11.2 LEY SARBANES OXLEY

La ley Sarbanes-Oxley, más conocida como Ley SOX, es una ley federal de Estados Unidos

que entró en vigencia el 30 de julio de 2002. También es conocida como el Acta de

Reforma de la Contabilidad Pública de Empresa y de Protección al Inversor. En gran

medida, la SOX fue provocada por el escándalo de Enron.

Enron era una empresa americana, un gigante de la energía con más de 111 mil millones

de dólares de ingresos. Debido a una serie de técnicas contables fraudulentas, que

fueron apoyadas por Arthur Andersen (su auditora) acabó quebrando y solicitando

protección por bancarrota a finales de 2001.

La parte más importante de la ley SOX establece una agencia (Public Company

Accounting Oversight Board o PCAOB como es mayormente conocida) que es la

encargada de revisar, regular, inspeccionar y disciplinar a las auditoras. También se

incluyen otras reformas como la evaluación y divulgación de la eficacia de los controles

internos, los auditores externos, la protección de los trabajadores y el aumento de penas

para la provisión intencionada o accidental de información financiera falsa.

De esta ley caben destacar otros puntos importantes:

- Requerimiento de que las compañías que cotizan en bolsa garanticen la veracidad de

las evaluaciones de sus controles internos en el informe financiero, así como que los

auditores independientes de estas compañías constaten esta transparencia y veracidad.

- Independencia de la empresa auditora

- Prohibición de préstamos personales a directores y ejecutivos

- Certificación de los informes financieros, por parte del comité ejecutivo y financiero de

la empresa.

La Ley Sarbanes-Oxley hace a los ejecutivos explícitamente responsables de establecer,

evaluar y monitorizar la efectividad de los controles internos en finanzas. Para la

mayoría de las organizaciones, IT es crucial para conseguir este objetivo (algunas optan

por sistemas ERP, otras por software más pequeño y personalizable). Esta situación

supone un reto para los profesiones de IT: las empresas –en particular los

184


departamentos de finanzas- necesitan información de IT para cumplir con los

requerimientos de la ley. Algunas de las áreas de responsabilidad para IT son:

Entender la organización interna y cómo se reportan los temas financieros

Alinear y mapear el entorno de IT que soporta el control interno junto con el

sistema de reporte al departamento de finanzas (y auditorías).

Identificar riesgos relacionados con esos sistemas de IT

Diseñar e implementar controles diseñados para mitigar los riesgos identificados

y monitorizarlos para su buen funcionamiento.

Documentar y probar los sistemas.

Asegurarse de que todos los controles están actualizados y cambiarlos cuando

corresponda (cambios en contabilidad o regulaciones, internas o externas).

Como se puede observar, no se trata de una tarea fácil y la implementación de la ley en

las empresas está siendo costosa en tiempo y dinero. Con respecto a IT, hay dos puntos a

tener en cuenta:

Prácticamente todas las compañías públicas tienen algún tipo de control sobre IT.

Aunque podrían ser totalmente informales y no tener (casi) ningún tipo de

documentación, controles sobre IT generalmente existen en seguridad y gestión de

cambios.

Muchas organizaciones han desarrollado procedimientos para cumplir con los requisitos

de la ley, pero a menudo la documentación es escasa (si existente), aunque los

procedimientos estén en curso.

El hecho de tener que cumplir con todas estas regulaciones supone en algunas industrias

(bancos, seguros, etc.) un cambio radical en la cultura y es un momento idóneo para

establecer mejoras en los sistemas de IT: diseño, documentación, control…

185


11.3 BASILEA 2

En 1968 se publicó el primero de los Acuerdos de Basilea, un conjunto de

recomendaciones para establecer un capital mínimo que debía tener una entidad

bancaria en función de los riesgos que afrontaba. Establecía una definición de “capital

regulatorio” compuesto por elementos que se agrupan en 2 categorías si cumplen

ciertos requisitos de permanencia, de capacidad de absorción de pérdidas y de

protección ante quiebra. Este capital debe ser suficiente para hacer frente a los riesgos

de crédito, mercado y tipo de cambio. Este acuerdo establecía un requerimiento mínimo

de capital basado únicamente en el riesgo de crédito. En 1996 se realizó una enmienda

para incorporar el riesgo de mercado (riesgo derivado de las fluctuaciones en los precios

de los activos con cotización, las tasas de interés y los tipos de cambio).

En 2004, el Comité de Basilea propuso un nuevo conjunto de recomendaciones basado

en tres pilares para solventar algunos puntos flacos que tenía la versión anterior (sobre

todo el hecho de que ignoraba la calidad crediticia y la diversa probabilidad de

incumplimiento de los distintos prestatarios).

Presentación del acuerdo definitivo

3ª Ronda Consultiva

2ª Ronda Consultiva

Propuesta de Basilea II

Principios básicos de supervisión bancaria

Riesgo de Mercado

Acuerdo original 1988

1996

1999

1999

2001

2001

2004

Cronograma de Basilea II

Ilustración 72: Cronograma de Basilea II

186


Los tres pilares en los que se basa son:

1) Cálculo de los requisitos mínimos de capital

Estos requisitos se calculan en base a los activos ponderados por su riesgo, con nuevos

criterios que reflejen de manera más ajustada el cambio en el perfil de riesgo de las

entidades.

Los riesgos a considerar son 3:

El primero es el riesgo de crédito. Se modifica el método estandarizado de forma que sea

similar al acuerdo vigente, pero introduciendo más categorías de riesgo y posibilidad de

evaluaciones de riesgo otorgadas por agencias externas. También se modifica el método

basado en calificaciones internas, proponiéndose dos variantes:

La básica (FIRB, donde los bancos estiman sólo la probabilidad de incumplimiento para

cada activo. Los otros indicadores y ecuaciones son provistos por el Comité de Basilea.

La avanzada (AIRB), donde los bancos estiman todos los indicadores cuantitativos que

requieren las ecuaciones desarrolladas por el Comité de Basilea.

El segundo riesgo es el de mercado, donde no se modifica el acuerdo vigente.

Y el tercer riesgo, el operativo, que se considera implícito en los otros riesgos del

Acuerdo Vigente.

2) El proceso de supervisión de la gestión de los fondos propios

Se le otorga un rol fundamental y se establecen 4 principios básicos:

1. Los bancos deberán contar con un proceso para evaluar la suficiencia de capital

total en función de su perfil de riesgo y con una estrategia de mantenimiento de

sus niveles de capital

2. Los supervisores deberán examinar las estrategias y evaluaciones internas de la

suficiencia de capital de los bancos así como la capacidad de estos para vigilar y

garantizar su cumplimiento y deberán intervenir cuando no queden satisfechos

con el resultado.

187


3. Los supervisores deberán esperar que los bancos operen por encima de los

coeficientes mínimos de capital y deberán tener la capacidad de exigirles que

mantengan capital por encima del mínimo.

4. Los supervisores deberán intervenir con prontitud para evitar que el capital

descienda por debajo de los mínimos y deberán exigir la inmediata adopción de

medidas correctivas.

3) Disciplina de mercado

Se establecen requerimientos de divulgación de la información con el objetivo de

permitir a los participantes del mercado evaluar el perfil de riesgo del banco.

Cálculo de los

requisitos mínimos de

capital

Proceso de supervisión

de los fondos propiosDisciplina de mercado

Pilar I Pilar 2 Pilar 3

Requisitos de capital

para el riesgo de crédito

Requisitos de capital

para el riesgo operativo

Revisión del procedimiento

de evaluación interna

Mayor rol supervisor

para los bancos centrales

Incremento de la disciplina

de mercado

Nuevos requisitos

para facilitar la

transparencia

Ilustración 73: Los tres pilares de Basilea II

El acuerdo de Basilea II debe ser aplicado a bancos internacionalmente activos, pero el

ámbito de aplicación es mayor que en el acuerdo de Basilea I.

188


Ilustración 74: Afectados por el acuerdo de Basilea II. Fuente: Folleto divulgativo de Basilea II de la superintendencia de entidades financieras y cambiarias

A finales del año 2010, se aprobó Basilea III, estableciendo medidas aún más restrictivas

que la versión anterior. Gobernadores de bancos centrales y reguladores cerraron un

acuerdo que forzará a los bancos a triplicar su capital de calidad. Algunas de las medidas

que se cerraron son:

Un capital estructural Tier 1 del 4.5% más un colchón de conservación de capital

del 2.5% que se suma al porcentaje anteriormente mencionado.

Se limita el apalancamiento del sector bancario.

189


11.3.1 CASO DE ESTUDIO: SANTANDER CONSUMER BANK

El 23 de noviembre de 2007 se publicó un caso de estudio de cómo ITIL y Basilea 2

habían sido implementados en Santander Consumer Bank, Monchengladbach.

Santander Consumer Bank AG (anteriormente CC-Bank AG) pertenece al Grupo

Santander, actualmente el primer banco europeo en capitalización bursátil.

Santander Consumer Bank tiene aproximadamente 1600 empleados y está situado en la

ciudad alemana de Monchengladbach.

Este banco estaba buscando software para implementar ITIL para los procesos de

gestión de los servicios de IT. El objetivo era utilizar las especificaciones de Basilea II,

que incluyen todos los procedimientos internos y sistemas para calcular el riesgo de

pérdida.

La solución fue construir un portal corporativo, para lo que se contó con Intrexx, un

portal de software del proveedor alemán United Planet. A día de hoy, todos los

componentes de infraestructura del banco se gestionan en este portal. Es posible

acceder de manera sencilla qué componente hardware es parte de qué proceso de IT. El

programa calcula automáticamente el riesgo de cada componente y comprueba si hay

suficiente backup disponible para minimizar el riesgo. Asimismo, es posible mostrar

información sobre los servicios de IT (apoyo, servicio, contratos de renting/leasing...). La

automatización conseguida ayuda asimismo a cumplir los requisitos de la ley Sarbanes

Oxley de una manera eficiente.

190


11.4 ENTREVISTAS

Para la realización de este proyecto, se ha contado con la colaboración de varios

expertos en el mundo de las Tecnologías de la Información. Se han mantenido varias

sesiones con dichos expertos en los que se han tratado los siguientes temas:

1) Estado de TI en las organizaciones

2) Conocimiento sobre guías de buen gobierno de TI

3) Impacto sobre las nuevas legislaciones en las empresas

4) Opinión sobre la utilidad de dichas guías

5) Sugerencias para el desarrollo de una aplicación/tutorial ITIL

6) Opinión sobre la aplicación final construida

Estas entrevistas se han ido llevando a cabo desde principios de julio 2009 hasta finales

de mayo de 2010 y para obtener lo máximo de las entrevistas se ha seguido una

metodología de adquisición del conocimiento:

Antes de comenzar con las entrevistas, se procedió a la lectura extensiva y exhaustiva de

documentación tanto de ITIL como de COBIT. Asimismo se diseñó a alto nivel la

aplicación y la navegación entre sus pantallas con el objetivo de que los expertos

pudiesen dar su opinión acerca de la misma.

Posteriormente se tuvieron unas primeras reuniones en las que se evaluó el estado de TI

en las organizaciones y la utilidad que consideran que tendría una aplicación para

mejorar la situación. Estas primeras reuniones estaban abiertas, no estructuradas,

aunque la orientación de las mismas sí estaba marcada. Gracias a esto, se adquirió un

punto de vista mucho más amplio y se conocieron varios aspectos internos del

funcionamiento de las compañías.

Más adelante, se tuvieron entrevistas estructuradas, en los que se intentó fijar las

cuestiones a tratar y el orden de las mismas. La razón para dejar estas entrevistas para

más adelante es que requieren de más conocimiento por parte del entrevistador, por lo

que tenía más sentido realizarlas una vez estuviese avanzado el proyecto.

191


Como conclusión de la metodología de adquisición del conocimiento, comentar que se

realizó un glosario de términos técnicos que puede verse en este proyecto, en el anexo

10.5.

Hay que destacar que a lo largo de todo el desarrollo se ha estado siempre en contacto

con al menos uno de los expertos, de forma que la aplicación sirviese al interés general

de las empresas.

Con el fin de sacar la máxima información posible, además de tomar notas durante las

entrevistas, se grabó el audio de las mismas e inmediatamente después se transcribieron

las ideas más importantes. En algún caso se encontró alguna incoherencia, para lo que se

estableció contacto de nuevo con el experto en cuestión para resolver la duda. Una vez

solventada, se corrigió la transcripción.

Finalizado este paso, se realizaron varios resúmenes, que pueden leerse a continuación.

Estos resúmenes están organizados por sesiones con expertos, de forma que figura el

contenido de todas las reuniones con ellos, de forma resumida y ordenada.

Los expertos que han colaborado en este proyecto han sido:

Alejandro Rembado (Presidente de ISACA, director de auditoría informática

corporativa de Telefónica)

Artemio Alcañiz Rodríguez (Project Manager IT Ferrovial, ex-Business Banking

Channel Manager)

Luis Escarpa Cabezas (Director de Innovación Operativa de BT Global Services)

Se comienza resumiendo las ideas que comentó D.Alejandro Rembado. Dado el

importante perfil de este experto, se va a dividir la entrevista en dos partes. En la

primera, intentó hablar únicamente como empleado de Telefónica y en la segunda como

presidente de ISACA. El motivo de dividir las reuniones desde esos dos puntos de vista

fue para intentar no alienar la opinión como empleado de Telefónica con las prácticas

que tienen lugar en ISACA, e intentar ser lo más objetivo posible sobre la posible utilidad

de las guías de gestión de gobierno de IT.

192


Intentando mantener el punto de vista de director de auditoría corporativa en

Telefónica se le preguntó acerca de la situación actual de Telefónica con respecto a los

sistemas informáticos y su integración. Destacar que la suma de las 394 filiales de la

empresa alcanzan actualmente más de 260.000 empleados en todo el mundo, con más

de 150.000 PC y 2500 grandes sistemas en funcionamiento. Telefónica está afectada por

los negocios globales, donde todo lo que aparezca en IT tiene impacto.

Se habló también sobre el hecho de que Telefónica integre a nuevas empresas en su

grupo (destacando sobre todo, O2). Este tipo de grandes operaciones implica un gran

trabajo en la unificación de servicios y es necesario tener los medios preparados para

acometerlas.

Hablando sobre las guías de mejores prácticas, se preguntó sobre el uso de las mismas

dentro de Telefónica y si, en particular, utilizan ITIL o COBIT. También se preguntó

acerca de lo que considera más importante para conseguir un buen gobierno de

sistemas. Alejandro comentó que se utilizan ambas. Concretamente utilizan COBIT para

temas de auditoría informática e ITIL para gestionar servicios.

Posteriormente se dialogó sobre la importancia de la información en Telefónica y de la

consciencia de los empleados sobre este hecho. Opinó que la información es el activo

fundamental de la empresa y puso como ejemplo que dentro de la empresa tienen

grupos de gestión del conocimiento. De estos grupos, cabe destacar un sistema de foros

de formación, donde el coordinador es el único que crea temas y el líder del

conocimiento, es un empleado destacado de la empresa que es un experto en el tema

que se trata en el foro. Los empleados formulan sus dudas y este experto está obligado a

compartir la información. En la empresa se considera que realizar una buena gestión del

conocimiento lleva a minimizar pérdidas de información y a optimizar el tiempo de sus

empleados.

Con respecto al desarrollo de la aplicación, desde la primera entrevista, D.Alejandro

Rembado consideró de tremenda utilidad una pequeña aplicación que pudiesen llevar

los empleados con las cuestiones fundamentales de ITIL. Según él mejoraría de manera

sustancial la situación en la empresa, en especial para aquellos empleados que

desconozcan qué es ITIL. Asimismo, decir que mantuvo un gran interés a lo largo de

todo el desarrollo del proyecto ofreciendo sugerencias de manera constante durante las

entrevistas mantenidas.

193


Cuando se le mostró la aplicación consideró que sería de gran utilidad, si bien opina que

habría que optimizar su funcionamiento una vez esté disponible. Habrá que escuchar las

opiniones del público y adecuarla a ello. Podría darse el caso de estar realizando una

aplicación muy básica o muy compleja.

En la segunda parte del resumen de entrevistas de D. Alejandro Rembado, se habló

principalmente de ISACA, desde su importantísimo puesto como presidente de la

organización.

Según él es importante destacar la posición de ISACA en España, que actualmente no

está demasiado implantada. A día de hoy existen tres capítulos (Madrid, Barcelona y

Valencia) que están poco integrados entre ellos, por desgracia. COBIT no goza de una

aceptabilidad general muy grande en España, aunque va creciendo año a año. Comenta

que fuera de nuestras fronteras, este crecimiento es mayor.

Sin embargo, ISACA sí está siendo muy reconocida por sus certificaciones CISM11 y

CISA12 , que demuestran a quien las obtiene su conocimiento en seguridad de la

información. Este reconocimiento que tiene la organización no es sólo a nivel nacional,

sino en todo el mundo.

Considera que COBIT 4.1 es compatible con ITIL v3 y que son completamente

complementarias. Ninguna soluciona los problemas de las organizaciones y hay que

saber qué se hace y por qué. Para ello ambas pueden ofrecer un punto de ayuda y las dos

son válidas.

Suponiendo una empresa de nueva creación, sugiere implementar COBIT poco a poco en

la estructura de la empresa. Al principio no superará los controles requeridos por la

guía, pero poco a poco los irá alcanzando

11 Certified Information Security Manager

12 Certified Information Security Auditor

194


Con D. Artemio Alcañiz, se mantuvieron varias entrevistas, todas ellas estando el

proyecto en un estado avanzado. Los principales temas que se trataron fueron la utilidad

de la aplicación en las empresas, la evolución del mercado de los smartphones y su

introducción masiva en las empresas y la compatibilidad de ambas guías.

Artemio evaluó la aplicación ya en un estado avanzado y proporcionó varias ideas para

la misma. Sobre todo, insistió en que la aplicación debería estar dirigida a un público

objetivo amplio, de forma que todo el personal de una organización pudiese

aprovecharse de ella. Consideró de gran importancia la inclusión de un glosario técnico,

ya no sólo de términos ITIL, sino de tecnologías de la información en general.

Artemio comentó la tremenda evolución que estaban teniendo los smartphones en las

organizaciones en los últimos años. Tanto en Ferrovial, como en ISBAN, es muy

abundante la presencia de estos terminales entre los empleados. El iPhone, por su parte,

aunque actualmente no está muy posicionado en los sectores empresariales, empieza a

abrirse hueco poco a poco. Por ello, considera que realizar la aplicación en el iPhone

puede suponer una excepcional manera de introducir ITIL en las organizaciones.

Con respecto a ambas guías Artemio comentó que él personalmente no conocía ninguna,

pero que por lo que había oído y por su propia experiencia, ambas parecen ser

compatibles. Según él la introducción de cualquier nueva práctica, política o guía en una

organización no es sencillo y debe realizarse con cuidado y sabiendo qué se está

haciendo. Si bien considera que estas guías deberían implementarse, enfatizó mucho en

que hay que hacerlo con precaución.

195


Con D. Luis Escarpa Director de Innovación Operativa en British Telecom Global

Services, se mantuvo una única entrevista en la que, basándose en las plantillas que

pueden verse al final del anexo, se obtuvo el punto de vista de un experto del sector con

más de 20 años de experiencia en IT.

La entrevista comenzó hablando sobre qué guías de buen gobierno o buenas prácticas

existen en British Telecom actualmente. Luis explicó que desconocía COBIT, pero que

ITIL estaba comenzando a ser implementado en la compañía. En el departamento de

operaciones ITIL sí se utiliza y muchos de los procesos de la compañía están basados en

esta guía. De hecho, está llevándose a cabo una reestructuración departamental en la

que, entre otras cosas, está procediéndose a utilizar el nombre que aparece en ITIL (por

ejemplo, Service Delivery ha pasado a llamarse Service Transition).

Luis continuó explicando cómo se introdujo ITIL en British Telecom. Al contrario de lo

que pudiera parecer en un primer momento, no procede como una norma desde el

Reino Unido, sino que se empieza a utilizar motu proprio en España. En la compañía se

utilizaba Lean Six Sigma como metodología de trabajo, basándose en Toyota y en los

sonados éxitos de su filosofía. Sobre septiembre de 2009, surge un proyecto de

unificación de procesos de la parte IT y TELCO de British Telecom Global Services. Al

analizar qué existe se observa que la parte IT tiene todos sus procesos relacionados con

la ISO 20000 (Estándar reconocido internacionalmente en la gestión de servicios IT).

Esta ISO está formada por dos partes: la especificación y el código de prácticas, el cual

está basado en ITIL v2. Como se ve la perfecta adecuación de los procesos de la ISO

20000 en la parte IT, se decide extrapolarlos a la parte TELCO. Poco a poco empieza a

conocerse ITIL y empiezan a interesarse por las diferencias entre ITIL v2 e ITIL v3. A

finales de año, gran parte de la plantilla de la compañía estaba recibiendo cursos sobre

ITIL v3 Foundations y un número importante de directivos estaban también recibiendo

los cursos de especialización de Service Strategy, Design, Transition y Operation.

A día de hoy la aceptabilidad no es total, pero sí es creciente. Como ejemplo, Recursos

Humanos y Marketing desconocen ITIL a día de hoy, mostrando cierta hostilidad y

resistencia al cambio.

Posteriormente, se habló sobre la hipótesis de implantar ITIL en una empresa de nueva

creación bajo dos supuestos: hacerlo de manera progresiva o total. Según Luis, es

prácticamente imposible hacerlo de manera total, ya que se estaría más tiempo

196


analizando procesos que realizando labores útiles para poner en funcionamiento la

empresa. Sin embargo, una implantación parcial sí que sería muy útil, bajo su punto de

vista. Considera que habría que empezar desarrollando un Service Catalog, para pasar

posteriormente a implantar los procesos de Service Asset & Configuration Management

y Change Management.

Si este mismo caso lo llevamos a una empresa en funcionamiento, ocurre más o menos

lo mismo: Es imposible implantar todo ITIL de golpe (más complicado todavía que en

una empresa de nueva creación), pero sí puede ganarse mucho implementando poco a

poco. Sin embargo, en este caso, quizás sería más recomendable empezar con Gestión de

Incidencias o Gestión de Problemas, porque son las dos prácticas que mejor se venden al

resto de la compañía (una reducción del X% en el número de incidencias y una

optimización de su gestión está bien visto de manera global).

Finalmente, se habló sobre la situación en España sobre ITIL. Tiene hoy en día un

impacto moderado, pero está creciendo día a día. Como dato a mencionar, en España hay

menos de 300 expertos ITIL, mientras que en el Reino Unido hay varios miles. En las

grandes empresas españolas sí está comenzando a tener cierta importancia, en especial

Aena, Telefónica y un gran número de compañías de seguros. Cabe destacar el hecho de

que HP, que tiene un número importante de personas en plantilla trabajando en España,

es una de las empresas que más implementado tiene ITIL en sus procesos, siendo

prácticamente total. Fuera de nuestras fronteras, Luis explica que en EEUU es donde

más crecimiento está teniendo actualmente ITIL.

197


A continuación se encuentran varias plantillas que se utilizaron para las entrevistas de

los expertos, para conocer de manera rápida ciertas cuestiones de vital importancia para

este proyecto.

PREGUNTAS SÍ/NO

Sí No N/A, NS/NC

¿Conoce ITIL?

¿Conoce COBIT?

¿Utilizan ITIL en

su empresa?

¿Utilizan COBIT en

su empresa?

¿Utilizan los

empleados de su

empresa

“smartphones”?

¿Tiene su empresa

un departamento

de IT?

Tabla 4: Preguntas SÍ/NO realizadas a los expertos

198


Preguntas 1-5 (1=totalmente en desacuerdo, 5=totalmente de acuerdo)

1 2 3 4 5 N/A

IT tiene un peso importante en su empresa

La ley SOX afecta en gran medida a su

empresa

La ley Basilea II afecta en gran medida a su

empresa

La implantación de IT en su empresa es

sencilla.

La información es el activo más importante

de su empresa.

Los trabajadores de su empresa consideran

a IT el motor de la organización

Las guías de mejores prácticas (ITIL, COBIT)

son importantes

Si los empleados de su empresa llevasen

consigo ITIL “en el bolsillo”, sería mucho

más sencillo implantar y mantener IT

IT es tan importante como finanzas,

marketing o producción

Los trabajadores de su empresa consideran

a IT el soporte de la organización

La importancia de IT en las empresas

seguirá creciendo año tras año

Conseguir que la alta dirección invierta en IT

es complicado en su empresa

Tabla 5: Preguntas 1-5 realizadas a los expertos

199


11.5 GLOSARIO DE TÉRMINOS

Access (acceso) Habilidad de hacer uso de un CI específico.

Actividad: Las medidas principales tomadas para operar el proceso COBIT.

Actual performance (rendimiento actual). Medida o evaluación de los efectos

pasados de un cambio implementado.

Administración de la configuración: El control de cambios realizados a un conjunto de

componentes de la configuración a lo largo del ciclo de vida del sistema.

Administración del desempeño: La capacidad de administrar cualquier tipo de

medición incluyendo mediciones de empleados, equipo, proceso, operativas o

financieras. El término denota un control de ciclo cerrado y la vigilancia periódica de la

medición.

Análisis de causa raíz: Proceso de aprendizaje a partir de las consecuencias,

típicamente de los errores y problemas. Arquitectura de la información—Ver

arquitectura de TI.

Arquitectura de TI: Un marco integrado para evolucionar o dar mantenimiento a TI

existente y adquirir nueva TI para alcanzar las metas estratégicas y de negocio de la

empresa.

Arquitectura empresarial para TI: Respuesta en la entrega de TI, provista por

procesos claramente definidos usando sus recursos (aplicaciones, información,

infraestructura y personas).

Arquitectura empresarial: Mapa de rutas tecnológicas orientada al negocio para el

logro de las metas y objetivos de negocio.

Asset (activo). Habilidad o recurso que es usado en la entrega de un servicio. Existen

muchos tipos de activos, entre otros: Activos de organización, de proceso, de

conocimiento, de personal…

Asset Management (gestión de activos). Proceso dentro de Service Asset and

Configuration Mangement (SACM) que trata con el inventario de todos los activos de

200


servicio.

Atención al usuario: El único punto de contacto dentro de la organización de TI para

los usuarios de los servicios prestados por TI.

Autenticación: El acto de verificar la identidad de un usuario y su elegibilidad para

acceder a la información computarizada. La autenticación está diseñada para proteger

contra conexiones de acceso fraudulentas.

Availability (disponibilidad). Habilidad de un ítem para realizar su función cuando se

le requiere.

Business Capacity Management (Gestión de la capacidad del negocio): Gestión de la

capacidad para servicios de negocio

Business Continuity (continuidad de negocio). Continuar a proveer servicios de

negocio después de un gran fallo.

Business Impact Analysis. (Análisis de impacto de negocio). Un alcance para

determinar aquellas funciones de negocio y dependencias que son vitales.

Business Service Catalog: Catálogo de servicios de negocio. Es la colección de los

servicios que directamente habilitan procesos que son parte del negocio

Capacidad: Contar con los atributos necesarios para realizar o lograr.

Capacity (Capacidad): Máxima transferencia que puede ser provista por un CI.

Capacity Management Information System: Sistema de información que contienen

todos los planes relacionados con la capacidad, análisis, información e informes.

Capacity Plan: (Plan de capacidad) Es un plan a largo plazo para proveer una

adecuada capacidad de servicio para cumplir los objetivos de nivel de servicio.

CEO: Director ejecutivo.

CFO: Director financiero.

Change assessment (evaluación de cambios). Evaluación de la petición de cambio

desde varios puntos de vista.

Change authorization (autorización de cambio). Aprobación de una petición de

201


cambio.

Change priority (prioridad de cambio). Orden en el cual las peticiones de cambio son

consideradas para autorización.

Change process model (Modelo de procesos de cambio). Flujos de trabajo

predeterminados para cambios que encajan dentro de plantillas determinadas.

Change record (registro de cambio). Registro de un cambio dentro de su ciclo de vida.

CI: Configuration Item (item de configuración)

CIO: Director de información [algunas veces Director de Tecnología (CTO, por sus siglas

en inglés)].

Classification (clasificación). Agrupamiento de tipos similares de incidentes en

categorías.

Cliente: Una persona o una entidad externa o interna que recibe los servicios

empresariales de TI

Comité estratégico de TI: Comité al nivel del Consejo Directivo para garantizar que el

consejo participe en las principales decisiones del tema de TI.

Component Capacity Management (Gestión de la capacidad de los componentes).

Gestión de la capacida para los ítems de configuración que realizan un servicio de IT.

Component Failure Impact Analisys (Análisis de impacto de fallo de

componentes). Análisis que se realiza para determinar cómo un fallo de un componente

afecta a los servicios de IT.

Componente de la configuración (CI): Componente de una infraestructura o un

artículo, como una solicitud de cambio, asociado con una infraestructura la cual está (o

estará) bajo el control de la administración de configuraciones. Los CIs pueden variar

ampliamente en complejidad, tamaño y tipo, desde un sistema completo (incluyendo

todo el hardware, software y documentación) hasta un solo módulo o un componente

menor de hardware.

Configuration baseline (línea base de configuración). Configuración de un conjunto

de CIs que se ha revisado y acordado.

202


Configuration Item (CI), Elemento de la infraestructura de IT que es gestionado como

parte de la entrega de un servicio, incluyendo personas, hardware, software,

instalaciones, acuerdos de nivel de servicio y documentación

Configuration Management (gestión de la configuración). Proceso que se encarga de

que los CI dentro de la infraestructura de IT están identificados y actualizados

Configuration Management Database (CMDB). Repositorio virtual de información

sobre los CI.

Configuration Management System (CMS). Sistema de bases de datos y herramientas

que gestionan información en múltiples CMBDs.

Configuration model (modelo de configuración). Dibujo de las relaciones entre CIs.

Continuidad: Prevenir, mitigar y recuperarse de una interrupción. Los términos

“planear la reanudación del negocio”, “planear la recuperación después de un desastre”

y “planear contingencias” también se pueden usar en este contexto; todos se concentran

en los aspectos de recuperación de la continuidad.

Continuity testing (Tests de continuidad). Realización de tests de planes de

continuidad para asegurarse de que funcionarán en caso de un gran fallo.

Control aplicativo: Un conjunto de controles integrados dentro de las soluciones

automatizadas (aplicaciones).

Control de accesos: El proceso que limita y controla el acceso a los recursos de un

sistema computacional; un control lógico o físico diseñado para brindar protección

contra la entrada o el uso no autorizados.

Control de detección: Un control que se usa para identificar eventos (indeseables o

deseados), errores u otras ocurrencias con efecto material sobre un proceso o producto

final, de acuerdo a lo definido por la empresa.

Control general: También control general de TI. Un control que se aplica al

funcionamiento general de los sistemas de TI de la organización y a un conjunto amplio

de soluciones automatizadas (aplicaciones).

Control Interno: Las políticas, procedimientos, practicas y estructuras organizacionales

203


diseñadas para brindar una garantía razonable de que los objetivos del negocio se

alcanzarán y de que los eventos indeseables serán prevenidos o detectados y corregidos

Control preventivo: Un control interno que se usa para prevenir eventos indeseables,

errores u otras ocurrencias que pudieran tener un efecto material negativo sobre un

proceso o producto final, de acuerdo a la organización.

Control: Las políticas, procedimientos, practicas y estructuras organizacionales

diseñadas para proporcionar una garantía razonable de que los objetivos del negocio se

alcanzarán y los eventos no deseados serán prevenidos o detectados

COSO: Comité de organizaciones patrocinadoras de la comisión Treadway. Estándar

aceptado a nivel internacional para el gobierno corporativo.

CSF: Factor crítico de éxito (FCE).

Data (datos). Hechos disjuntos sobre eventos.

DCO: Objetivos de control detallados. Los DCOs son componentes de un objetivo de

control en particular.

Declaración de auditoría: Documento que define el propósito, la autoridad y la

responsabilidad de la actividad de auditoría interna, aprobado por el consejo.

Definitive Media Library (DML – Librería de Software definitivo). Librería segura

que guarda versiones definitivas de todos los CI’s electrónicos.

Definitive Spares. Almacenamiento electrónico para los CI’s que están al mismo nivel

que los CI’s en fase de prueba o de ejecución.

Demand (Demanda) Uso deseado de un servicio o recurso de IT.

Desempeño: La implantación real o el logro de un proceso.

Deviation (desviación). Determinación sobre si el rendimiento actual es aceptable.

Diccionario de datos empresarial: El nombre, tipo, rango de valores, fuente, sistema

de registro, y autorización de acceso para cada elemento de datos utilizado en la

empresa. Indica cuáles programas aplicativos usan esos datos, de tal forma que cuando

se contemple una estructura de datos, se pueda generar una lista de los programas

afectados.

204


Diccionario de datos: Un conjunto de meta-datos que contiene definiciones y

representaciones de elementos de datos.

Directory services (servicios de directorio) Aplicación que registra los derechos

dados a cada identidad y permite realizar modificaciones a los derechos.

Directriz: La descripción de un modo particular de lograr algo, la cual es menos

prescriptiva que un procedimiento.

Dominio: Agrupación de objetivos de control en etapas lógicas en el ciclo de vida de

inversión en TI

Dueños de datos: Individuos, por lo general gerentes o directores, que tienen la

responsabilidad de la integridad, el uso y el reporte preciso de los datos computarizados

Early life support. (Apoyo en momento temprano de la vida). Periodo de atención

adicional y soporte para un servicio de IT inmediatamente después del despliegue.

Empresa: Un grupo de individuos que trabajan juntos para un fin común, por lo general

dentro del contexto de una forma organizacional, como una corporación agencia pública,

entidad de caridad o fondo.

Escalation (escalada). Hay dos tipos, funcional o jerárquica. Se utiliza para resolver

incidentes que no pueden ser resueltos con los recursos actuales.

Esquema de clasificación de datos: Un esquema empresarial para clasificar los datos

por factores tales como criticidad, sensibilidad y propiedad.

Estándar: Una práctica de negocio o producto tecnológico que es una práctica aceptada,

avalada por la empresa o por el equipo gerencial de TI. Los estándares se pueden

Implementar para dar soporte a una política o a un proceso, o como respuesta a una

necesidad operativa. Así como las políticas, los estándares deben incluir una descripción

de la forma en que se detectará el incumplimiento.

Evaluación por comparación (Benchmarking): Un proceso utilizado en

administración, en particular en la administración estratégica, en el cual las compañías

evalúan varios aspectos de sus procesos de negocio con respecto a las mejores prácticas,

por lo general dentro de su propia industria.

205


Event Correlation (correlación de eventos).

Event response (respuesta de eventos).

Fault Tree Analysis (Análisis de fallos en árbol). Análisis que indica una cadena de

eventos que lleva a un problema

Gobierno: El método por medio del cual una organización es dirigida, administrada o

controlada.

Human resource capacity (Capacidad e recursos humanos) Una parte de Capacity

Management que trata con la planificación y entrenamiento de los RRHH y sus efectos en

la capacidad del servicio.

Identity (identidad). Nombre de cada usuario o grupo.

Incidencia: Cualquier evento que no sea parte de la operación estándar de un servicio

que ocasione, o pueda ocasionar, una interrupción o una reducción de la calidad de ese

servicio (alineado a ITIL).

Incident models (modelos de indicentes). Modelos en los que se detalla qué camino

se ha llevado a cabo para la solución de un incidente.

Information (información) contexto para los datos.

Information Security Management System (ISMS, Sistema de gestión de seguridad

de la información). Sistma de información que contiene información sobre los

estándares de seguridad, políticas y procedimientos.

Information Security Policy (Política de seguridad de la información). Política

global para dirigir la seguridad de la información.

Infraestructura: La tecnología, los recursos humanos y las instalaciones que permiten

el procesamiento de las aplicaciones.

Invitation to Tender (ITT): Documento similar al Statement of Requirements.

ISO 17799: Código de práctica para la administración de la seguridad de la información

de la Organización Internacional para la Estandarización (ISO).

ISO 27001: Gestión de Seguridad de la Información- Especificación con guía para su uso;

206


la sustituta a la BS7799-2. Ideada para proporcionar los fundamentos en auditoria a

terceros e armonización con otros estándares, tales como ISO/IEC 9001 y 14001.

ISO 27001. Estándar internacional para certificar un ISMS.

ISO 9001:2000: Código de práctica para la administración de la calidad de la

Organización internacional para la Estandarización (ISO). El ISO 9001:2000 especifica

los requisitos para un sistema de administración de calidad para cualquier organización

que necesite demostrar su habilidad para ofrecer productos de manera consistente que

satisfagan al cliente, a los requisitos regulatorios aplicables y que desee aumentar la

satisfacción del cliente.

IT Service Continuity (Continuidad de servicio de IT). Continuación a proveer

servicios técnicos después de un gran fallo.

IT Service Continuity Plan (Plan de continuidad de servicio de IT). Plan para

restaurar servicios de IT después de un gran fallo.

IT: (TI) Tecnologías de la información. Son un conjunto de técnicas, desarrollos y

dispositivos que integran funcionalidades de almacenamiento, procesamiento y

transmisión de datos.

ITIL: Librería de Infraestructura de TI de la Oficina de Gobierno Gubernamental del

Reino Unido (OGC).Un conjunto de lineamientos sobre la administración y procuración

de servicios operativos de TI.

KGI: Indicador clave de meta.

Knowledge (conocimiento) Puntos de vista obtenidos por los individuos sobre

eventos concernientes sobre cómo sucedieron los eventos.

Knowledge Management Strategy (estrategia de gestión del conocimiento).

Políticas globales, gobierno, roles y procedimientos para la gestión del conocimiento.

Known Error (error conocido). Problema para el cual la causa raíz ha sido

determinada y se ha creado un workaround o resolución.

KPI: Indicador clave de desempeño.

Madurez: Indica el grado de confiabilidad o dependencia que el negocio puede tener en

207


un proceso, al alcanzar las metas y objetivos deseados.

Major indicents (gran incidente). Incidencia de tal magnitud que se trata de manera

individual.

Management of Risk (MOR, Gestión del riesgo). Metodología para evaluar el impacto

de los riesgos dentro de una empresa.

Marcador de puntuación balanceado: Un método para medir las actividades de una

empresa en términos de su visión y estrategias, proporcionando una vista rápida e

integral del desempeño del negocio a la gerencia. Es una herramienta administrativa

cuyo fin es medir un negocio desde las siguientes perspectivas: financiera, del cliente,

del negocio y del aprendizaje (Robert S. Kaplan y David Norton, 1992).

Marco de control: Una herramienta para los dueños de los procesos de negocio que

facilita la descarga de sus responsabilidades a través de la procuración de un modelo de

control de soporte.

Marco de trabajo: Ver Marco de control.

Matriz RACI: Ilustra quién es responsable, quién debe rendir cuentas, a quién se debe

consultar e informar dentro de un marco de trabajo organizacional estándar.

Métrica: Un estándar para medir el desempeño contra la meta.

Modelo de madurez de la capacidad (CMM): El modelo de madurez de la capacidad

para software (CMM), del Instituto de Ingeniería de Software (SEI), es un modelo

utilizado por muchas organizaciones para identificar las mejores prácticas, las cuales

son convenientes para ayudarles a evaluar y mejorarla madurez de su proceso de

desarrollo de software.

Objetivo de control: Una declaración del resultado o propósito que se desea alcanzar al

Implementar procedimientos de control en un proceso en particular.

OLA: Acuerdo a nivel operativo. Un acuerdo interno que cubre la prestación de servicios

que da soporte a la organización de TI en su prestación de servicios.

Operational Level Agreement (OLA) (Acuerdo de nivel operacional). Acuerdo con

un proveedor interno para proveer servicios dentro de unos niveles especificados.

208


Operational Level Agreement (OLA).

Organización: La manera en que una empresa está estructurada.

Performance (rendimiento). Resultados medibles de un recurso, CI o servicio.

Pilot (piloto). Despliegue de un servicio de IT o activo que está limitado por propósitos

de pruebas.

Plan de infraestructura tecnológica: Un plan para el mantenimiento y desarrollo de la

infraestructura tecnológica.

Plan estratégico de TI: Un plan a largo plazo, Ej., con un horizonte de tres a cinco años,

en el cual la gerencia del negocio y de TI describen de forma cooperativa cómo los

recursos de TI contribuirán a los objetivos estratégicos empresariales (metas)

Plan táctico de TI: Un plan a mediano plazo, Ej., con un horizonte de seis a dieciocho

meses, que traduzca la dirección del plan estratégico de TI en las iniciativas requeridas,

requisitos de recursos y formas en las que los recursos y los beneficios serán

supervisados y administrados

PMBOK: Cuerpo de conocimiento de administración de proyectos, un estándar para

administración de proyectos desarrollado por el Instituto de Administración de

Proyectos (PMI).

PMO: Director de administración de proyectos.

Política: Por lo general, un documento que ofrece un principio de alto nivel o una

estrategia a seguir. El propósito de una política es influenciar y guiar la toma de

decisiones presente y futura, haciendo que estén de acuerdo a la filosofía, objetivos y

planes estratégicos establecidos por los equipos gerenciales de la empresa. Además del

contenido de la política, esta debe describir las consecuencias de la falta de

cumplimiento de la misma, el mecanismo para manejo de excepciones y la manera en

que se verificará y medirá el cumplimiento de la política.

Portafolio: Una agrupación de programas, proyectos, servicios o activos seleccionados,

administrados y vigilados para optimizar el retorno sobre la inversión.

Práctica de control: Mecanismo clave de control que apoya el logro de los objetivos de

209


control por medio del uso responsable de recursos, la administración apropiada de los

riesgos y la alineación de TI con el negocio

Prácticas de administración clave: Las principales prácticas de administración que el

dueño del proceso debe realizar para alcanzar las metas del proceso

Predicted performance (rendimiento predicho). Medida o evaluación sobre los

efectos de un cambio futuro.

PRINCE2: Proyectos en un ambiente controlado, un método de administración de

proyectos que cubre la administración, el control y la organización de un proyecto

Priorization (priorización). Impacto relativo y urgencia de un incidente.

Proactive problem Management (Gestión de problemas proactivo) Búsqueda de

problemas potenciales antes de que sean reportados por otros procesos o funciones.

Problem (problema): Causa raíz de un grupo de incidentes relacionados.

Problem Model (modelo de problema): Flujo de trabajo predefinido para majear un

tipo específico de problema

Problema: Causa subyacente desconocida de uno o más incidentes

Procedimiento: Una descripción de una manera particular de lograr algo; una forma

establecida de hacer las cosas; una serie de pasos que se siguen en un orden regular

definido, garantizando un enfoque consistente y repetitivo hacia las actividades.

Proceso: Por lo general, un conjunto de procedimientos influenciados por las políticas y

estándares de la organización, que toma las entradas provenientes de un número de

fuentes, incluyendo otros procesos, manipula las entradas, y genera salidas, incluyendo a

otros procesos, para los clientes de los procesos. Los procesos tienen razones claras de

negocio para existir, dueños responsables, roles claros y responsabilidades alrededor de

la ejecución del proceso, así como los medios para medir el desempeño.

Programa aplicativo: Un programa que procesa los datos del negocio a lo largo de las

actividades, tales como la captura, actualización o consulta de datos. Contrasta con los

programas de sistemas, tales como un sistema operativo o un programa de control de

redes, y con los programas utilitarios, tales como copiar (copy) o clasificar (sort).

210


Programa: Una agrupación estructurada de proyectos independientes que incluye el

alcance completo del negocio, del proceso, de las personas, de la tecnología y las

actividades organizacionales que se requieren (tanto necesarias como suficientes) para

lograr un resultado de negocios claramente especificado.

Proveedor de servicios: Organización externa que presta servicios a la organización.

Proyecto: Un conjunto estructurado de actividades relacionadas con la entrega de una

capacidad definida a la organización (la cual es necesaria, aunque no suficiente para

lograr un resultado de negocios requerido) con base en un cronograma y presupuesto

acordado.

QMS: Sistema de administración de la calidad. Un sistema que describe las políticas y

procedimientos necesarios para mejorar y controlar los distintos procesos que al final

conducirán a un desempeño mejorado del negocio.

Reactive problem Management (gestión de problemas reactivo). Resolución de

problemas que han sido descubiertos por Incident Management o alguna otra fuente.

Recovery (recuperación). Devolución de un CI a su estado original después de su

resolución.

Release (lanzamiento, estreno). Grupo de cambios que han sido probados,

empaquetados y desplegados dentro de la infraestructura de IT al mismo tiempo.

Release and deployment model (modelo de lanzamiento y despliegue). Modelo

repetible o estándar para llevar a cabo un lanzamiento.

Reliability (fiabilidad). Tiempo que un ítem puede realizar su función sin

interrupciones.

Remediation (remedio) Plan a seguir si un cambio no es satisfactiorio.

Repair (reparación). Sustitución o arreglo de un CI.

Request for change (RFC, petición de cambio). Registro de un cambio propuesto.

Request model (modelo de petición). Flujo de trabajo predefinido para manejar un

tipo específico de petición de servicio.

Resistencia: La capacidad de un sistema o red para recuperarse de forma automática de

211


una interrupción, por lo general con un efecto reconocible mínimo.

Resolution (resolución). Encuentro de la causa raíz de un incidente o problema via

reparación o workaround.

Restoration (Restauración). Vuelta al funcionamiento normal de un CI o servicio

después de su restauración.

Riesgo: El potencial de que una amenaza específica explote las debilidades de un activo

o grupo de activos para ocasionar pérdida y/o daño a los activos. Por lo general se mide

por medio de una combinación del impacto y la probabilidad de ocurrencia.

Rights (derechos). Permisos dados a cada identidad.

Risk (riesgo). Ocurrencia potencial que podría causar pérdidas.

Risk Analysis (Análisis de riesgo). Determinar la vulnerabilidad a amenazas de

servicio en IT.

Risk categorization (categorización de riesgo). Evaluación del riesgo global de una

petición de cambio al negocio.

Risk Management formula (fórmula para la gestión del riesgo). Posibilidad *

impacto

SDLC: Ciclo de vida del desarrollo de sistemas. Las fases utilizadas en el desarrollo o

adquisición de un sistema de software. Las fases típicas incluyen al estudio de

factibilidad, el estudio de los requerimientos, la definición de requerimientos, el diseño

detallado, la programación, las pruebas, la instalación y la revisión post-implantación.

Secure library (Librería electrónica). Almacenamiento seguro para activos

electrónicos.

Secure store (almacenamiento seguro). Localización física que almacena activos de

IT.

Segregación/separación de tareas: Un control interno básico que previene y detecta

errores o irregularidades por medio de la asignación a individuos diferentes, de la

responsabilidad de iniciar y registrar las transacciones y la custodia de los activos.

Service Capacity Management (gestión de la capacidad de los servicios). Gestión de

212


la capacidad para los servicios de IT.

Service Catalog (Catálogo de servicios): Colección de los servicios de IT que

actualmente se provee a los clientes de IT.

Service Design Package (paquete de diseño de servicios). Especificaciones, modelos,

arquitecturas, diseños,planes y otros criterios de aceptación.

Service Design Package (paquete de diseño de servicios). Requisitos documentados

y diseño del servicio.

Service Knowledge Management System (Sistema de gestión del conocimiento del

servicio). Sistema global que abarca todos los sistemas de Información de la gestión del

servicio.

Service Level Agreement (SLA) (Acuerdo de nivel de servicio). Acuerdo negociado

entre el proveedor de servicios de IT y el cliente de IT, en el que se definen las

responsabilidades de cada parte concernientes a la entrega de un servicio de IT.

Service level Packaged (paquete de nivel de servicio). Nivel de utilidad y garantía

que acompaña a un paquete de diseño de servicios.

Service model (modelo de servicios). Boceto de la funcionalidad del servicio

Service Package (Paquete de servicios): Descripción en profundidad de un servicio

disponible a través del cátalogo de servicios.

Service Portfolio (Portafolio de servicios): Colección de todos los servicios de IT.

Service Provider (proveedor de servicios). Proveedor interno o externo de un

servicio de IT.

Service Rehearsal (Ensayo de servicio). Tipo de pruebas de servicio que incluye

probar el servicio tanto como sea posible antes de su despliegue.

Service request (petición de servicio). Cambio estándar que está virtualmente exento

de fallos.

Service retirement and cleanup (Retirada de servicio y limpieza) Servicios o activos

de servicio que pueden ser retirados como parte de una acción de despliegue.

213


Service transfer (transferencia de servicio). Transferencia de servicio de un

proveedor de servicios a otro.

Service: (Servicio) Una colección de sistemas de IT, componentes y recursos que

trabajan conjuntamente para proveer valor a los clientes de IT.

Single point of Failure (SPOF). Un Configuration Item que, cuando falla, puede causar

una incidencia

SLA: Acuerdo de nivel de servicio. Acuerdo por escrito entre un proveedor de servicios y

los usuarios del cliente, el cual documenta los niveles de servicio acordados para un

servicio prestado.

Snapshot (instantánea). Estatus de un conjunto de CIs en un momento en el tiempo.

Stakeholder. Cualquier parte que tenga interés en un servicio, configuration item, o

cualquier otro activo de IT que puede tener relación con un cambio.

Standard changes (cambios estándar). Cambio con riesgo muy bajo que está

preautorizado para ser implementado.

Statment of Requierements (comunicado de requisitos). Documento que identifica

todos los requisitos para un servicio o proyecto.

Supplier performance (rendimiento del proveedor). Nivel de servicio para los

proveedores. Si no se supera, los contratos con dicho proveedor se terminan.

Supplier Service Improvement Plan (Plan de mejora del servicio de los

proveedores). Extras que deben ser llevados a cabo por un proveedor para mejorar

niveles de servicio.

Suppliers and contracts Database. (Base de datos de proveedores y contratos).

Repositorio de información sobre los provedores y sus contratos.

Tablero de control: Una herramienta para establecer las expectativas de una

organización en cada nivel y para comparar de forma continúa el desempeño contra las

metas establecidas.

TCO: Coste total de la propiedad. En IT incluye: Coste original del ordenador y del

software, Actualizaciones de hardware y software, Mantenimiento, Soporte técnico

214


,Entrenamiento , Ciertas actividades desarrolladas por los usuarios.

Technical Service Catalog (Catálogo de servicio técnico): Colección de todos los

servicios de IT que soportan procesos de negocio.

Test model (modelo de pruebas). Modelo para cómo definir cada servicio.

Threshold (umbral). Un nivel operacional que, cuando se supera, causa una alerta o

acción.

TI: Tecnología de información.

Timescales (escalas de tiempo). Periodo en el tiempo en el que una incidencia debería

ser resuelta o escalada.

Tuning. Ajuste o manipulación de recursos de IT para realizar un mejor uso de los

recursos, incluyendo balances y optimización

Types of testing (tipos de pruebas). Varios aspectos en los que probar un servicio

(usabilidad, accesibilidad, rendimiento, disponibilidad, conformidad, remedio, etc.

Underpinning Contract (UC). Acuerdo con un proveedor externo para proveer

servicios dentro de unos niveles especificados.

Unintended effects (efectos no intencionados). Efectos secundarios de un cambio.

Usuario: Una persona que utiliza los sistemas empresariales.

Utilization (utilización). Uso de un recurso.

Validation (validación) Práctica de identificar que un CI nuevo o modificado satisface

las necesidades del negocio.

Verification (verificación). Práctica de identificar que un CI nuevo o modificado

satisface los requisitos.

Vital Business function (Funciones de negocio vitales) Funciones críticas de un

servicio de negocios.

Wisdom (sabiduría). Discernimiento concerniente a por qué los eventos sucedieron.

proyecto fin de carrera - iit · brindado. la entrega de este proyecto supone el fin de la etapa...

Documents