Autores - Huygens
Anuncio
Autores: Reingeniería, Tecnología y Comunicaciones, S.L. Calle Agustín de Foxá, 25 28036 Madrid De la edición: © Centro de Estudios Adams, Ediciones Valbuena, S.A. Doctor Esquerdo, 136, 7ª Planta 28007 Madrid www.adams.es ISBN: 978-84-9943-460-5 TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI ÍNDICE 1. INTRODUCCIÓN – PROCESOS DE SOFTWARE 1.1 Introducción a la Ingeniería del Software 1.2 Ciclos de vida y fases 1.2.1. Fases o etapas del ciclo de vida del software 1.2.2. Modelos de ciclos de vida 1.2.2.1 Modelo lineal o secuencial 1.2.2.2 Modelo en cascada mejorado 1.2.2.3 Modelos evolutivos 1.2.2.3.1 Modelo en espiral 1.2.2.3.2 Modelo incremental 1.2.3. Productos software 1.3 Procesos primarios y de soporte 1.4 Modelos de calidad 1.4.1. Gestión de la calidad 1.4.2. Aseguramiento de la calidad 1.4.3. Control de la calidad 1.4.4. Modelos de calidad de software 1.4.4.1 Modelo CMMI 1.4.4.2 Norma ISO 12207 1.4.4.3 Metrica3 1.4.4.4 Norma ISO 15504 1.4.5. Metodologías de trabajo Pág. 6 Pág. 9 Pág. 10 Pág. Pág. Pág. Pág. 13 14 15 17 Pág. 20 Pág. 21 Pág. 21 Pág. Pág. Pág. Pág. Pág. 22 24 25 27 28 Pág. 29 Pág. Pág. Pág. Pág. 29 30 31 32 Pág. 34 Pág. 35 Pág. Pág. Pág. Pág. Pág. 39 49 59 65 71 A BO LA NI Página 2 de 134 OM R 2. METODOLOGÍA DE PROCESOS ITIL 2.1 Definición 2.2 Introducción 2.2.1 Orígenes de ITIL 2.2.2 Características ITIL 2.2.3 Beneficios de ITIL 2.2.4 Ventajas e inconvenientes 2.3 Metodología y procesos 2.3.1 Ciclo de vida de la gestión de servicio de ITIL 2.3.2 Subprocesos 2.3.3 Componentes del ciclo de vida de servicio 2.3.3.1 Estrategia del servicio 2.3.3.2 Diseño del servicio 2.3.3.3 Transición del servicio 2.3.3.4 Operación del servicio 2.3.3.5 Mejora continua del servicio Pág. 4 VINCIT ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI 3. METODOLOGÍAS DE GESTIÓN PMI 3.1 Definición 3.2 Introducción 3.2.1 Orígenes de PMI 3.2.2 Características de PMI 3.2.3 Certificaciones de PMI 3.2.4 Estándares de PMI 3.3 Iniciación a PMBOK 3.3.1 Introducción 3.3.2 Estructura 3.3.3 Técnicas 3.4 Procesos 3.4.1 Introducción a los procesos 3.4.2 Procesos de dirección de proyectos 3.4.3 Grupo del proceso de iniciación 3.4.4 Grupo del proceso de planificación 3.4.5 Grupo del proceso de ejecución 3.4.6 Grupo del proceso de seguimiento y control 3.4.7 Grupo del proceso de cierre Pág. 73 Pág. Pág. Pág. Pág. 73 75 75 77 Pág. 78 Pág. 79 Pág. 81 Pág. Pág. Pág. Pág. Pág. Pág. Pág. 82 83 84 86 94 98 103 4. MODELOS Y NORMA CMMI 4.1 Definición 4.2 Introducción 4.2.1 Orígenes de CMMI 4.2.2 Representaciones de CMMI 4.2.2.1 Representación continua 4.2.2.2 Representación escalonada 4.2.2.3 Niveles para las representaciones continua y escalonada 4.3 Metodología 4.3.1 Áreas de procesos 4.3.2 Componentes 4.3.2.1 Componentes requeridos 4.3.2.2 Componentes esperados 4.3.2.3 Componentes informativos 4.3.3 Relaciones entre las áreas de proceso 4.3.3.1 Administración de procesos 4.3.3.2 Administración de proyectos 4.3.3.3 Soporte 4.3.3.4 Ingeniería Pág. Pág. Pág. Pág. GLOSARIO BIBLIOGRAFÍA LINKS Pág. 120 Pág. 131 Pág. 134 Pág. 106 Pág. 107 Pág. 108 Pág. 109 Pág. 110 Pág. 113 Pág. 113 Pág. 114 A LA NI BO R 115 116 117 118 OM Página 3 de 134 Pág. 105 VINCIT ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI 1. INTRODUCCIÓN – PROCESOS DE SOFTWARE 1.1 Introducción a la Ingeniería del Software El nacimiento de la Ingeniería del Software surge como respuesta al problema conocido como “crisis del software”. Este problema se identificó por primera vez en 1968, año en el que la organización OTAN desarrolló la primera conferencia sobre desarrollo de software, y en la que se acuñaron los términos “Crisis del Software” para definir los problemas que surgían en el desarrollo de sistemas de software, e “Ingeniería del Software” para describir el conjunto de conocimientos que existían en aquel estado inicial. La “Crisis del Software” tenía como consecuencia una baja productividad y calidad en el software desarrollado, provocado entre otras causas, por la rápida evolución del hardware, la falta de metodologías y técnicas, y un uso inadecuado de los recursos. Entre los síntomas que permitieron identificar este problema, destacan los siguientes: - Productividad de los desarrolladores: Baja en relación con la demanda. - Expectativas: Los sistemas no responden a las expectativas de los usuarios. - Fiabilidad: Los programas fallan a menudo. - Costes: Difíciles de predecir, a menudo sobrepasan lo esperado. - Mantenimiento: Modificación del software costosa y compleja. - Plazos: No se cumplen. - Eficiencia: No hay aprovechamiento óptimo de recursos. - Portabilidad: Difícil cambiar de plataforma. La necesidad de un enfoque de ingeniería en el desarrollo del software fue propuesta en la conferencia de la OTAN de 1968, en la que Fritz Bauer, definió por primera vez el término “Ingeniería del Software” como el establecimiento y uso de principios de ingeniería robustos, orientados a obtener software económico que sea fiable y funcione eficientemente sobre máquinas reales. En la actualidad, se considera la Ingeniería del Software como una nueva área de la ingeniería, que ofrece métodos y técnicas para desarrollar y mantener software de calidad, y la profesión de ingeniero informático es una de las más demandadas. BO NI A LA OM R La Ingeniería del Software trata áreas muy diversas de la informática y de las ciencias de la computación, aplicables a un amplio espectro de campos, tales como negocios, investigación científica, medicina o banca, entre otras muchas. VINCIT Página 4 de 134 ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI Los desafíos de la Ingeniería del Software son reducir el coste y mejorar la calidad del software, explotar y aprovechar el potencial proporcionado por el hardware, así como desarrollar y mantener software asegurando su calidad, fiabilidad y facilidad de uso. De una forma humorística se hace la siguiente comparación con otras ingenierías: - Ingeniería mecánica como buscar un gato negro en una habitación iluminada. - Ingeniería química como buscar un gato negro en una habitación oscura. - Ingeniería software como buscar un gato negro en una habitación oscura donde no hay ningún gato. - Ingeniería de sistemas como buscar un gato negro en una habitación oscura donde no hay gato y alguien dice ¡¡Lo encontré!! 1.2 Ciclos de vida y fases Podemos definir el ciclo de vida como el conjunto de fases por las que pasa el sistema que se está desarrollando, desde que nace la idea inicial hasta que el software es retirado o reemplazado. Un ciclo de vida debe llevar a cabo las siguientes tareas: - Determinar el orden de las fases del proceso software. - Establecer los criterios de transición para pasar de una fase a la siguiente. - Definir las entradas y salidas en cada fase. - Describir los estados por los que pasa el producto. - Describir las actividades a realizar para transformar el producto. - Definir un esquema que sirve como base para planificar, organizar, coordinar, desarrollar, … Al iniciar un proyecto, el responsable de la arquitectura de procesos debe realizar los siguientes pasos: Análisis de las circunstancias ambientales del proyecto. - Diseño del modelo específico de ciclo de vida para el proyecto (sobre las bases de los diseños más apropiados, para el desarrollo y la evolución del sistema de software). - Mapeo de las actividades sobre el modelo. - Desarrollo para la gestión del ciclo de vida del proyecto. A BO LA NI Página 5 de 134 OM R - VINCIT ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI 1.2.1 Fases o etapas del ciclo de vida del software El ciclo de vida del software está conformado por las siguientes etapas principales: Análisis: En esta etapa se debe entender y comprender de forma detallada cuál es la problemática a resolver, verificando el entorno en el cual se encuentra dicho problema. De esta forma se podrá obtener la información necesaria y suficiente para afrontar su respectiva solución. Esta etapa es conocida como la de “QUÉ” se va a solucionar. Podemos dividir la etapa de análisis, en tres subfases: Captura, análisis y especificación de requisitos: Durante esta subfase se adquieren, reúnen y especifican las características funcionales y no funcionales que deberá cumplir el futuro programa o sistema a desarrollar. La obtención de especificaciones a partir del cliente es un proceso humano muy interactivo e iterativo. Normalmente a medida que se captura la información, esta se analiza y realimenta con el cliente, refinándola, puliéndola y corrigiéndola si es necesario. Procesos, modelado y forma de elicitación de requisitos: Existen diversas formas, modelos y metodologías para elicitar, definir y documentar requerimientos. A continuación enumeramos el conjunto de tareas recomendadas para obtener la definición de lo que se debe realizar, los productos a obtener y las técnicas a emplear durante la actividad de elicitación de requisitos, en fase de Especificación de Requisitos Software: 1. Obtener información sobre el dominio del problema y el sistema actual. 2. Preparar y realizar las reuniones para elicitación/negociación. 3. Identificar/revisar los objetivos del usuario. 4. Identificar/revisar los objetivos del sistema. 5. Identificar/revisar los requisitos de información. 6. Identificar/revisar los requisitos funcionales. 7. Identificar/revisar los requisitos no funcionales. 8. Priorizar objetivos y requisitos. Clasificación e identificación de requerimientos: Se pueden identificar dos formas de requisitos: requisitos de usuario y requisitos de sistema. Ambos tipos de requisitos son lo mismo, pero con distinto nivel de detalle. Los requisitos de usuario son frases en lenguaje natural junto a diagramas con los servicios que el sistema debe proporcionar, así como las restricciones bajo las que debe operar. (Ejemplo: el sistema debe hacer ingresos) OM R Los requisitos de sistema determinan los servicios del sistema, pero con las restricciones en detalle, y sirven como contrato. (Ejemplo: Función ingreso: entrada código socio, código ejemplar. Salida: validación ingreso,…) NI BO A LA - VINCIT Página 6 de 134 ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI Podemos clasificar los requisitos de sistema en tres tipos: - Requisitos funcionales: Los requisitos funcionales describen los servicios que proporciona el sistema, la respuesta del sistema ante determinadas entradas y el comportamiento del mismo en situaciones particulares. - Requisitos no funcionales: Los requisitos no funcionales son restricciones de los servicios o funciones que ofrece el sistema. - Requisitos del dominio: Los requisitos del dominio se derivan del dominio de la aplicación y reflejan características de dicho dominio. Pueden ser funcionales o no funcionales. - Diseño: Una vez que se tiene la suficiente información del problema a solucionar, es importante determinar la estrategia que se va a utilizar para resolver el problema. Esta etapa es conocida bajo el “CÓMO” se va a solucionar. - Codificación: Partiendo del análisis y diseño de la solución, en esta etapa se procede a desarrollar el correspondiente programa que solucione el problema mediante el uso de una herramienta computacional determinada. Esta tarea la realiza el programador, siguiendo por completo las estrategias impuestas en el diseño, y considerando los requisitos funcionales y no funcionales especificados en la primera etapa. Durante la fase de programación, el código puede adoptar varios estados, dependiendo de la forma de trabajo y del lenguaje elegido: Código fuente: Es el escrito directamente por los programadores en editores de texto. Contiene el conjunto de instrucciones codificadas en algún lenguaje de alto nivel. - Código objeto: Es el código binario o intermedio resultante de procesar con un compilador el código fuente. El código objeto no existe si el programador trabaja con un lenguaje a modo de intérprete puro, ya que es el mismo intérprete el que se encarga de traducir y ejecutar línea por línea el código fuente, en tiempo de ejecución. - Código ejecutable: Es el código binario resultado de enlazar uno o más fragmentos de código objeto con las rutinas y bibliotecas necesarias. El código ejecutable, también conocido como código máquina, no existe si se programa a modo de intérprete puro. BO NI A LA OM R - VINCIT Página 7 de 134 ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI - Pruebas e integración: Los errores humanos dentro de la programación de los computadores son muchos y aumentan considerablemente con la complejidad del problema. Cuando se termina de escribir un programa de computador, es necesario realizar las debidas pruebas que garanticen el correcto funcionamiento de dicho programa bajo el mayor número de situaciones posibles a las que se pueda enfrentar. Entre las diversas pruebas que se le efectúan al software se pueden distinguir principalmente: - - Pruebas unitarias: Consisten en probar aquellas partes del software que tengan funcionalidades específicas y con cierto grado de independencia, a nivel de secciones, procedimientos, funciones y módulos. - Pruebas de integración: Se realizan una vez que las pruebas unitarias fueron concluidas exitosamente. Se intenta asegurar que el sistema completo, funcione correctamente al operar sus subsistemas en conjunto. Operación y mantenimiento: Una vez instalado un programa y puesto en marcha para realizar la solución del problema previamente planteado o satisfacer una necesidad, es importante mantener una estructura de actualización, verificación y validación que permitan a dicho programa ser de utilidad y mantenerse actualizado según las necesidades o requerimientos planteados durante su vida útil. Básicamente se pueden distinguir los siguientes tipos de cambios: - Perfectivos: Aquellos cambios que suponen una mejora en cualquier aspecto de la calidad interna del software: reestructuración del código, optimización del rendimiento y eficiencia,… - Evolutivos: Modificaciones, incluso eliminaciones, necesarias en el software para cubrir su expansión o cambio, según las necesidades del usuario. - Adaptativos: Modificaciones que afectan a los entornos en los que opera el sistema, como cambios de configuración del hardware, cambios en el software de base, en gestores de base de datos,... - Correctivos: Alteraciones necesarias para corregir errores de cualquier tipo en el producto software desarrollado. BO NI A LA OM R Todas las fases descritas anteriormente, deben ir acompañadas de una adecuada documentación de las mismas. La documentación es la guía o comunicación escrita en sus diferentes formas, ya sea en enunciados, procedimientos, dibujos o diagramas que se hace sobre el desarrollo de un programa. La importancia de la documentación radica en que a menudo un programa escrito por una persona, es modificado por otra. Por ello sirve para ayudar a comprender o usar un programa, o para facilitar futuras modificaciones. VINCIT Página 8 de 134 ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI La documentación se compone de tres partes: Documentación Interna: Son los comentarios o mensajes que se añaden al código fuente para hacer más claro el entendimiento de los procesos que lo conforman, incluyendo las precondiciones y las poscondiciones de cada función. Documentación Externa: Se define un documento escrito con los siguientes puntos: descripción del problema, datos del autor, algoritmo (diagrama de flujo o pseudocódigo), diccionario de datos y código fuente (programa). Manual de Usuario: Describe paso a paso la manera en que funciona el programa, con el fin de que el usuario lo pueda manejar para que obtenga el resultado deseado. 1.2.2 Modelos de ciclos de vida El modelo de proceso o modelo de ciclo de vida utilizado para el desarrollo del software, define el orden para las tareas o actividades involucradas, así como la coordinación, enlace y realimentación entre ellas. Entre los modelos más conocidos se pueden mencionar: Modelo lineal o secuencial, modelo en cascada y modelos evolutivos. 1.2.2.1 Modelo lineal o secuencial A continuación, mostramos un esquema de este tipo de modelo: Análisis Diseño Codificación Pruebas e integración BO NI A LA OM R Operación y mantenimiento VINCIT Página 9 de 134 ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI El modelo lineal o secuencial, también conocido como modelo en cascada puro, refleja un desarrollo marcado por la sucesión escalonada de las etapas que lo componen: requisitos, diseño, pruebas e integración. Es una visión del proceso de desarrollo de software como una sucesión de etapas que producen productos intermedios. Es necesario terminar por completo cada etapa para pasar a la siguiente. Este modelo, identificado ya a principios de la década de los 50, resulta muy rígido porque cada fase requiere como elemento de entrada el resultado completo de la anterior. Algún cambio durante la ejecución de una cualquiera de las etapas implicaría reiniciar desde el principio todo el ciclo completo, lo cual redundaría en altos costos de tiempo y desarrollo. Debido a sus limitaciones (no se permiten las iteraciones, los requisitos se congelan al principio del proyecto, no existe un producto “enseñable” hasta el final del mismo), este tipo de modelo solo resulta apropiado en los siguientes casos: o Para desarrollar nuevas versiones de sistemas ya veteranos en los que el desconocimiento de las necesidades de los usuarios, o del entorno de operación no plantea riesgos. o Para el desarrollo de sistemas pequeños, sin previsión de evolución a corto plazo. Pese a todo el modelo secuencial tiene un lugar muy importante en la Ingeniería del Software, y continúa siendo el más utilizado. 1.2.2.2 Modelo en cascada mejorado A continuación, mostramos un esquema del modelo en cascada con realimentación: Análisis Diseño Codificación Pruebas e integración BO NI A LA OM R Operación y mantenimiento VINCIT Página 10 de 134 ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI La siguiente figura corresponde a un esquema del modelo en cascada de refinamiento por pasos o mejora iterativa: Análisis Diseño Codificación Pruebas e integración Operación y mantenimiento En 1970 Winston Royce definió flujos de retorno sobre el modelo secuencial, dando lugar así al modelo en cascada mejorado. Este modelo refleja la necesidad de retornar con frecuencia desde una fase hacia las anteriores con la información generada al avanzar el desarrollo. Las representaciones más habituales de dicho modelo son las recogidas en las dos figuras anteriores. La primera de ellas permite el retorno únicamente entre una fase y la anterior, mientras que en la segunda, en cualquier fase puede surgir un retorno para modificar cualquiera de las anteriores. El modelo en cascada mejorado, como el secuencial, reconoce la importancia de disponer de unos requisitos y un diseño previo antes de comenzar con la codificación del sistema. Sin embargo, al mismo tiempo, se enfrenta al hecho de la dificultad que supone en la realidad, disponer de una documentación elaborada de requisitos y diseño antes de empezar a codificar, lo cual puede actuar como una barrera que bloquee el comienzo de la siguiente fase. Por estas razones el modelo no se ha hecho muy popular, y los equipos que lo aplican pueden caer en la tentación de comenzar con el diseño o incluso con la codificación, sin tener un conocimiento suficiente de los requisitos. Desventajas del modelo en cascada mejorado: Los cambios introducidos durante el desarrollo pueden confundir al equipo profesional en las etapas tempranas del proyecto. Si los cambios se producen en etapa madura (codificación o prueba) pueden ser catastróficos para un proyecto grande. o Al igual, que en el modelo lineal, el cliente debe tener paciencia ya que el software no estará disponible hasta muy avanzado el proyecto. Un error detectado por el cliente (en fase de operación) puede ser desastroso, implicando reinicio del proyecto, con altos costos. A BO LA NI Página 11 de 134 OM R o VINCIT ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI 1.2.2.3 Modelos evolutivos El software es un elemento que evoluciona con el tiempo. Los requisitos del usuario y del producto suelen cambiar conforme se desarrolla el mismo. Las fechas de mercado y la competencia hacen que no sea posible esperar a poner en el mercado un producto absolutamente completo, por lo que se debe introducir una versión funcional limitada. En esas u otras situaciones similares los desarrolladores necesitan modelos de progreso que estén diseñados para acomodarse a una evolución temporal o progresiva, donde los requisitos fundamentales son conocidos de antemano, aunque no estén lo suficientemente detallados. En el modelo secuencial y en cascada mejorado no se tiene en cuenta la naturaleza evolutiva del software, se plantea el mismo como un elemento estático con requisitos bien conocidos y definidos desde el inicio. Los evolutivos son modelos iterativos, que permiten desarrollar versiones cada vez más completas y complejas, hasta llegar al objetivo final deseado. La información acumulada en el desarrollo de cada sistema o versión, y durante su fase de operación, sirve para mejorar o ampliar los requisitos y el diseño del siguiente. A continuación, mostramos el esquema correspondiente a un modelo de ciclo de vida evolutivo: Análisis Diseño Codificación Análisis Pruebas e integración Diseño Sistema 1ª versión Operación y mantenimiento Codificación Pruebas e integración Operación y mantenimiento Análisis Diseño Sistema 2ª versión … Las circunstancias en las que este modelo puede resultar apropiado son: o Desconocimiento inicial de todas las necesidades operativas que serán precisas, generalmente por tratarse del desarrollo de un sistema que operará en un entorno nuevo. o Necesidad de que el sistema entre en operación en un plazo de tiempo inferior al necesario para diseñarlo y desarrollarlo de forma exhaustiva. o Necesidad de desarrollar sistemas en entornos cambiantes. A BO LA NI Página 12 de 134 OM R Dentro del grupo de los modelos evolutivos destacan el modelo en espiral y el modelo incremental. VINCIT ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI 1.2.2.3.1 Modelo en espiral El modelo en espiral fue propuesto inicialmente por Barry Boehm en 1988. Presenta un desarrollo evolutivo, en contraste con la linealidad de los modelos vistos anteriormente. En este tipo de modelo el software se construye en una serie de versiones incrementales, en las que las últimas iteraciones generan versiones cada vez más completas del sistema diseñado. BO NI A LA OM R A continuación, mostramos un esquema de este tipo de modelo: VINCIT Página 13 de 134 ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI El modelo se divide en un número de actividades de marco de trabajo, llamadas “regiones de tareas”. En la figura anterior, podemos distinguir 6 fases a lo largo del desarrollo: o Fase 1: Tareas requeridas para establecer la comunicación entre el cliente y el desarrollador. o Fase 2: Tareas inherentes a la definición de los recursos, tiempo y otra información relacionada con el proyecto. o Fase 3: Tareas necesarias para evaluar los riesgos técnicos y de gestión del proyecto. o Fase 4: Tareas para construir una o más representaciones de la aplicación software (prototipos, maquetas, simulaciones,…). o Fase 5: Tareas para construir la aplicación, instalarla, probarla y proporcionar soporte al usuario o cliente o Fase 6: Tareas para obtener la reacción del cliente, según la evaluación de lo creado e instalado en los ciclos anteriores. El modelo de ciclo de vida en espiral se usa en proyectos en los que se prevén riesgos. Utiliza las fases de los modelos tradicionales, pero se centra en la eliminación de errores y alternativas poco atractivas, y representa un enfoque dirigido a detectar y prevenir el riesgo en la estructuración y análisis del proceso software. De esta forma consigue evitar muchas dificultades. A pesar de las ventajas citadas anteriormente, este tipo de modelo consume muchos recursos, y las etapas y sus entradas y salidas no están claramente definidas. 1.2.2.3.2 Modelo incremental El modelo incremental es un tipo de modelo evolutivo que mitiga la rigidez del modelo en cascada, descomponiendo el desarrollo de un sistema en partes, para cada una de las cuales se aplica un ciclo de desarrollo. Bajo este modelo se entrega software por partes funcionales más pequeñas, pero reutilizables, llamadas incrementos. En general, cada incremento se construye sobre aquel que ya fue entregado. BO NI A LA OM R Su esquema es idéntico al de la figura correspondiente al modelo de ciclo de vida evolutivo, pero en lugar de generar un sistema completo en cada iteración, en este caso se genera un subsistema correspondiente a cada uno de los incrementos realizados. El momento de inicio de cada incremento es dependiente de varios factores: tipo de sistema, independencia o dependencia entre incrementos, capacidad y cantidad de profesionales involucrados en el desarrollo, etc. VINCIT Página 14 de 134 ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI Las ventajas que ofrece el modelo incremental son las siguientes: o El usuario dispone de pequeños subsistemas operativos que ayudan a perfilar mejor las necesidades reales del sistema en su conjunto. o El modelo produce entregas parciales en periodos cortos de tiempo, comparados con el tiempo necesario para la construcción del sistema en su conjunto, y permite la incorporación de nuevos requisitos que pueden no estar disponibles o no ser conocidos al iniciar el desarrollo. Por lo tanto, podemos concluir que el modelo incremental proporciona todas las ventajas del modelo en cascada realimentado, reduciendo sus desventajas sólo al ámbito de cada incremento. 1.2.3 Productos software A menudo el cliente no suele tener una idea clara de lo que quiere, o no sabe explicarlo bien. En otras ocasiones es el responsable del desarrollo el que no está seguro de la eficacia de un algoritmo, del enfoque a tomar en la interacción hombre-máquina, etc. Para ayudar a comprender y validar los requisitos de usuario, es posible desarrollar una serie de productos intermedios de prueba, tales como modelos o maquetas (prototipos). Un prototipo es una implementación parcial pero concreta de un sistema o una parte del mismo, que principalmente se crea para explorar cuestiones sobre aspectos muy diversos del sistema durante el desarrollo del mismo. Es un modelo o maqueta del sistema que se construye para comprender mejor el problema y sus posibles soluciones. El uso de los prototipos en el desarrollo de sistemas software no se limita a probar las interacciones que los usuarios deben realizar, sino que son útiles también para otras actividades que se realizan durante el proceso, como por ejemplo en la fase de recogida o análisis de requisitos, ya que amplían y mejoran la información necesaria para el desarrollo del sistema. A continuación enumeramos las principales características de los prototipos: Son formidables herramientas de comunicación entre todos los componentes del equipo de desarrollo y los usuarios. o Dan soporte a los diseñadores a la hora de escoger entre varias alternativas. o Permiten a los diseñadores explorar diversos conceptos del diseño antes de establecer los definitivos. o Permiten evaluar el sistema desde las primeras fases del desarrollo. o Son el primer paso para que ideas abstractas sean concretas, visibles y testables. o Mejoran la calidad y completitud de las especificaciones funcionales del sistema. BO NI A LA OM R o VINCIT Página 15 de 134 ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI A menudo el cliente no suele tener una idea clara de lo que quiere, o no sabe explicarlo bien. En otras ocasiones es el responsable del desarrollo el que no está seguro de la eficacia de un algoritmo, del enfoque a tomar en la interacción hombre-máquina, etc. La tabla siguiente recoge los tipos de prototipos más relevantes, y especifica las características de los mismos: Tipos de prototipos Prototipos de interfaz de usuario Prototipos funcionales (operacionales) Modelos de rendimiento Rápido o desechable Características Modelos de pantallas. Implementa algunas funciones, y a medida que se comprueba que son las apropiadas, se corrigen, refinan, y se añaden otras. Evalúan el rendimiento de una aplicación crítica. - Sirve para el análisis y validación de los requisitos. - Después se redacta la especificación del sistema y se desecha el prototipo - La aplicación se desarrolla siguiendo un paradigma diferente. Problema: Cuando el prototipo no se desecha, y termina convirtiéndose en el sistema final. Evolutivos - Comienza con un sistema relativamente simple que implementa los requisitos más importantes o mejor conocidos. - El prototipo se aumenta o cambia en cuanto se descubren nuevos requisitos. - Finalmente, se convierte en el sistema requerido. Actualmente, se usa en el desarrollo de sitios Web y en aplicaciones de comercio electrónico. NI A Página 16 de 134 OM R Desarrolla parcialmente todas las funciones. BO Horizontal Desarrolla completamente alguna de las funciones. LA Vertical VINCIT ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI 1.3 Procesos primarios y de soporte En primer lugar, vamos a estudiar algunos conceptos necesarios para comprender la explicación relativa a los procesos primarios y de soporte: - El proceso software es el conjunto de actividades que se realizan para la gestión, desarrollo, mantenimiento y soporte de los sistemas software. Incluye los actores que ejecutan las actividades, sus roles y los artefactos producidos. La finalidad de los procesos de Ingeniería del Software es facilitar el entendimiento y comunicación, dar soporte a la gestión y mejora de procesos, y proporcionar un soporte automatizado. Los procesos deben ser adecuados a la organización y tipo de proyectos. Para ello, hay que tener en cuenta distintos factores, como la naturaleza del trabajo, el dominio de la aplicación, la estructura del procesa de entrega (incremental, evolutivo, cascada,…) o la madurez de la organización. Como hemos dicho anteriormente, un proceso está compuesto por actividades, y a su vez, cada una de las actividades está compuesta por tareas. De esta forma la estructura de un proceso se podría representar como se refleja en la siguiente figura: PROCESO ACTIVIDAD 1 TAREA 1 BO NI A Página 17 de 134 OM R TAREA N LA TAREA 1 ACTIVIDAD N VINCIT ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI - Un modelo de proceso software es una representación abstracta del proceso software de una organización. Una organización puede definir su propia manera de producir software en base a sus características internas y las de sus clientes. - ISO: La Organización Internacional para la Estandarización o ISO, fue creada en 1947 y es el organismo encargado de promover el desarrollo de normas internacionales de fabricación, comercio y comunicación para todas las ramas industriales a excepción de la eléctrica y la electrónica. Su función principal es la de buscar la estandarización de normas de productos y seguridad para las empresas u organizaciones a nivel internacional. Las normas desarrolladas por ISO son voluntarias, comprendiendo que ISO es un organismo no gubernamental y no depende de ningún otro organismo internacional, por lo tanto, no tiene autoridad para imponer sus normas a ningún país. Dichas normas se conocen como Normas ISO, y su finalidad es la coordinación de las normas nacionales, en consonancia con el Acta Final de la organización mundial del comercio, con el propósito de facilitar el intercambio de información y contribuir con unos estándares comunes para el desarrollo y transferencia de tecnologías. Actualmente el uso de las normas ISO se va extendiendo y hay un gran interés en seguir las normas existentes porque desde el punto de vista económico reduce costes, tiempo y trabajo, junto con criterios de eficacia y de capacidad de respuesta a los cambios. Los procesos pueden dividirse en: - Primarios: Son aquellos en los que se originan los productos de una compañía. También conocidos como procesos de producción. - Secundarios: Dan soporte a los primarios, es decir, son procesos de soporte. - Terciarios: Son los procesos administrativos que dirigen y coordinan los procesos primarios y secundarios. La norma ISO 12207 define los siguientes procesos primarios en el ciclo de vida del software: Adquisición: Proceso global que sigue el adquiriente para obtener el producto. - Suministro: Proceso global que sigue el suministrador para proporcional el producto. - Desarrollo: Proceso empleado por el suministrador para el diseño, construcción y pruebas del producto. - Operación: Proceso seguido por el operador en el día a día para el uso del producto. - Mantenimiento: Proceso empleado para mantener el producto, incluyendo tanto los cambios en el propio producto como en su entorno de operación. BO NI A LA OM R - VINCIT Página 18 de 134 ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI El estándar 12207 identifica también, los procesos de soporte que pueden ser utilizados desde un proceso primario, o incluso desde otro proceso de soporte. Dichos procesos de soporte son: - Documentación: Actividades empleadas para registrar información específica empleada por otros procesos. - Gestión de la configuración: Actividades empleadas para mantener un registro de los productos generados en la ejecución de los procesos. - Aseguramiento de la calidad: Actividades empleadas para garantizar de forma objetiva que el producto y los procesos asociados son conformes a los requisitos documentados y a las planificaciones. - Verificación: Actividades empleadas para verificar el producto. - Validación: Actividades empleadas para validar el producto. - Reuniones de revisión: Reuniones empleadas por las dos partes para evaluar el estado del producto y de las actividades. - Auditorías: Actividades par determinar que el proyecto cumple con los requisitos, planes y contratos. - Resolución de problemas: Actividades para analizar y resolver problemas relativos al proyecto, sea cual sea su fuente y naturaleza. En el estándar 12207 se identifican también, los procesos que deben realizarse en el contexto de la organización que va a ejecutar el proyecto, es decir, los procesos administrativos. Normalmente, estos procesos se aplican de forma común sobre múltiples proyectos. De hecho las organizaciones más maduras los identifican e institucionalizan. Gestión: Describe las actividades de gestión de la organización, incluyendo también la gestión de proyectos. - Infraestructura: Actividades necesarias para que puedan realizarse otros procesos del ciclo de vida. Incluye entre otros el capital y el personal. - Mejora: Actividades realizadas para mejorar la capacidad del resto de procesos. - Formación. A BO LA NI Página 19 de 134 OM R - VINCIT ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI 1.4 Modelos de calidad La obtención de un software con calidad implica la utilización de metodologías o procedimientos estándares para el análisis, diseño, programación y prueba del software, que permitan unificar la filosofía de trabajo, para lograr así una mayor confiabilidad, mantenibilidad y facilidad de prueba. Un modelo de calidad de software es un conjunto de buenas prácticas para el ciclo de vida del software, enfocado en los procesos de gestión y desarrollo de proyectos. Los modelos de calidad de software indican qué hay que hacer, pero no cómo hacerlo, ya que la forma de llevarlos a cabo depende de las metodologías utilizadas y de los objetivos de negocio. La política establecida debe estar sustentada sobre tres principios básicos: tecnológico, administrativo y ergonómico. - El principio tecnológico define las técnicas a utilizar en el proceso de desarrollo del software. - El principio administrativo contempla las funciones de planificación y control del desarrollo del software. - El principio ergonómico define la interfaz entre el usuario y el ambiente automatizado. La elección de una buena política contribuye en gran medida a lograr la calidad del software, pero no la asegura. Para el aseguramiento de la calidad es necesario su control o evaluación. A continuación, estudiaremos tres conceptos clave relacionados con la calidad de un producto software, e interrelacionados entre sí: gestión de la calidad, control de la calidad y aseguramiento de la calidad. 1.4.1 Gestión de la calidad Se denomina gestión de la calidad a un conjunto de aspectos de la función de gestión que determinan y aplican la política de la calidad, los objetivos y las responsabilidades, y que lo realizan con medios como la planificación de la calidad, el control de la calidad y la mejora de la calidad. Dentro de la gestión de calidad se pueden distinguir: - Gestión de la calidad de software (Norma ISO 9000) - Política de calidad (Norma ISO 9000) BO NI A LA OM R La gestión de calidad se aplica normalmente a nivel de empresa. También puede haber una gestión de calidad dentro de la gestión de cada proyecto. VINCIT Página 20 de 134 ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI 1.4.2 Aseguramiento de la calidad El aseguramiento de la calidad del software incluye el conjunto de actividades planificadas y sistemáticas necesarias para aportar la confianza de que el producto software satisfará los requisitos de calidad dados. Y se diseña para cada aplicación antes de comenzar a desarrollarla. El aseguramiento de la calidad del software está presente en los siguientes elementos: - Métodos y herramientas de análisis, diseño, programación y prueba. Inspecciones técnicas formales en todos los pasos del proceso de desarrollo del software. Control de la documentación del software y de los cambios realizados. Procedimientos para ajustarse a los estándares. Registro de auditorías y realización de informes A continuación, enumeramos algunos métodos que forman parte del aseguramiento de la calidad: - Revisiones técnicas y de gestión para realizar una evaluación del producto. Inspección, para verificar si estamos construyendo el producto que realmente se pide. Pruebas, para validar el producto. Auditorías. 1.4.3 Control de la calidad El control de la calidad del software incluye un conjunto de técnicas y actividades de carácter operativo, utilizadas para verificar los requisitos relativos a la calidad, y centradas en mantener bajo control el proceso de desarrollo, y eliminar las causas de los defectos en las diferentes fases del ciclo de vida. En la siguiente figura representamos las estrategias de trabajo correspondientes al control de la calidad: CONTROL DE LA CALIDAD REVISIONES Y AUDITORÍAS NI BO OM R PROCESOS PRODUCTO FINAL Y ORGANIZACIONES A LA PRODUCTOS ENTREGABLES LABORATORIO DE CERTIFICACIÓN VINCIT Página 21 de 134 ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI 1.4.4 Modelos de calidad de software Como ya se ha mencionado anteriormente, un modelo de calidad de software es un conjunto de buenas prácticas para el ciclo de vida del software, enfocado en los procesos de gestión y desarrollo de proyectos. Existen varios modelos de calidad de software, a continuación se presentan algunos de ellos: CMMI: Diseñado por el Carnegie Mellon Software Engineering Institute (SEI), y orientado a la mejora de procesos en diferentes niveles de madurez. Norma ISO/IEC 12207: Diseñada por la International Organization for Standardization, y orientado al proceso del ciclo de vida del software. Metrica3: Empleada actualmente por la Administración Española en el desarrollo de software. Abarca desde la planificación estratégica de los sistemas, hasta su implantación. ISO 15504: Modelo para la mejora y evaluación de los procesos de desarrollo y mantenimiento de sistemas y productos de software. 1.4.4.1 Modelo CMMI El CMM - CMMI (Capability Maturity Model) 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 realizar para producir software. Los niveles CMM - CMMI son 5, a continuación se incluye una descripción de cada uno de ellos: Nivel 1 CMM - CMMI o inicial: Este es el nivel donde están todas las empresas que no tienen procesos. Los presupuestos se disparan, no hay control sobre el estado del proyecto, y el desarrollo de proyecto es completamente opaco. Nivel 2 CMM – CMMI o repetible: Quiere decir que el éxito de los resultados obtenidos se puede 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: NI BO OM R 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 A LA - VINCIT Página 22 de 134 ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI Nivel 3 CMM – CMMI o definido: Alcanzar este nivel significa que la forma de desarrollar proyectos está definida, es decir, que está establecida, documentada y existen métricas para la consecución de objetivos concretos. Los objetivos 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 La mayoría de las empresas que llegan al nivel 3 para aquí, ya que es un nivel que proporciona muchos beneficios y no ven la necesidad de ir más allá porque tienen cubiertas la mayoría de sus necesidades. Nivel 4 CMM – CMMI o cuantitativamente gestionado: 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 Nivel 5 CMM – CMMI u optimizado: 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 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. La implantación de un modelo de estas características es un proceso largo y costoso que puede costar varios años de esfuerzo. Aun así el beneficio obtenido para la empresa es mucho mayor que lo invertido. A BO LA NI Página 23 de 134 OM R En la unidad 4 de este manual se profundizará en el análisis de este modelo de calidad de software. VINCIT ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI 1.4.4.2 Norma ISO 12207 Como ya se ha mencionado antes, esta norma está orientada a los procesos de ciclo de vida del software de la organización ISO. Establece un proceso de vida para el software que incluye procesos y actividades que se aplican desde la definición de requisitos, pasando por la adquisición y configuración de los servicios del sistema, hasta la finalización de su uso. Como vimos en el apartado 1.3 del manual, los procesos de la norma ISO 12207 se clasifican en tres grandes grupos: Procesos principales: Los procesos principales de la norma ISO 12207 son los siguientes: - Procesos de apoyo: Los procesos de apoyo o soporte de la norma ISO 12207 son los siguientes: - Procesos de gestión: Los procesos de gestión de la norma ISO 12207 son los siguientes: - Gestión Infraestructura Mejora Formación OM R Documentación Gestión de la configuración Aseguramiento de calidad Verificación. Validación Revisión conjunta. Auditoría. Resolución de problemas NI BO Adquisición Suministro Desarrollo Explotación Mantenimiento A LA VINCIT Página 24 de 134 ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI 1.4.4.3 Métrica3 La metodología Métrica v3.0 ha sido desarrollada por el Ministerio para la administración pública española. Esta metodología propia está basada en el modelo de procesos del ciclo de vida de desarrollo ISO/IEC 12207, así como en la norma ISO/IEC 15504 SPICE, y está orientada a procesos. A continuación se citan sus principales elementos: Planificación de Sistemas de Información (PSI) Desarrollo de Sistemas de Información Estudio de Viabilidad del Sistema (EVS) Análisis del Sistema de Información (ASI) Diseño del Sistema de Información (DSI) Construcción del Sistema de Información (CSI) Implantación y Aceptación del Sistema (IAS) Mantenimiento de Sistemas de Información (MSI) Además de los elementos anteriores, esta metodología contiene las siguientes interfases: Gestión de Proyectos (GP) Seguridad (SEG) Aseguramiento de la Calidad (CAL) Gestión de la Configuración (GC) Las actividades propias de la interfaz de calidad en Métrica versión 3 están orientadas a verificar la calidad de los productos. En cada fase del proyecto se deberán llevar a cabo una serie de actividades que se enumeran a continuación: - EVS – CAL 1: Identificación de las propiedades de calidad del sistema informático. - EVS – CAL 2: Establecimiento del plan de aseguramiento de calidad. - EVS – CAL 3: Adecuación del plan de aseguramiento de calidad a la solución. Análisis del Sistema de Información (ASI) ASI – CAL 1: Especificación inicial del plan de aseguramiento de calidad. - ASI – CAL 2: Especificación detallada del plan de aseguramiento de calidad. - ASI – CAL 3: Revisión del análisis de consistencia. - ASI – CAL 4: Revisión del plan de pruebas. - ASI – CAL 5: Registro de la aprobación del análisis del sistema informático. OM R - NI BO Estudio de Viabilidad del Sistema (EVS) A LA VINCIT Página 25 de 134 ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI DSI – CAL 1: Revisión de la arquitectura del sistema informático. - DSI – CAL 2: Revisión de la especificación técnica del plan de pruebas. - DSI – CAL 3: Revisión de los requisitos de implantación. - DSI – CAL 4: Registro de la aprobación del diseño del sistema informático. Construcción del Sistema de Información (CSI) - CSI – CAL 1: Revisión del código. - CSI – CAL 2: Revisión de las pruebas. - CSI – CAL 3: Revisión de los manuales de usuario. - CSI – CAL 4: Revisión de la formación a usuarios. - CSI – CAL 5: Registro de la aprobación del sistema informático. Implantación y Aceptación del Sistema (IAS) - IAS – CAL 1: Revisión del plan de implantación. - IAS – CAL 2: Revisión de las pruebas de implantación. - IAS – CAL 3: Revisión de las pruebas de aceptación. - IAS – CAL 4: Revisión de las pruebas de mantenimiento. - IAS – CAL 5: Registro de la aprobación de la implantación del sistema informático. Mantenimiento de Sistemas de Información (MSI) - MSI – CAL 1: Revisión del mantenimiento. - MSI – CAL 2: Revisión del plan de pruebas de regresión. - MSI – CAL 3: Revisión de la realización de las pruebas de regresión. OM R - NI BO Diseño del Sistema de Información (DSI) A LA VINCIT Página 26 de 134 ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI 1.4.4.4 Norma ISO 15504 Como ya se explico en apartados anteriores, la norma ISO 15504 es un modelo para la mejora y evaluación de los procesos de desarrollo y mantenimiento de sistemas y productos software, que posee las siguientes características: Establece un marco para métodos de evaluación, no es un método o modelo en sí. Comprende: evaluación de procesos, mejora de procesos, determinación de capacidad. Está alineado con el estándar ISO/IEC 12207 que define los procesos del ciclo de vida del desarrollo, mantenimiento y operación de los sistemas de software. Posee equivalencia y compatibilidad con CMMI. ISO forma parte del panel elaborador del modelo CMMI y SEI mantiene la compatibilidad y equivalencia de ésta última con 15504. La norma tiene una arquitectura basada en dos dimensiones: de proceso y de capacidad de proceso. Desde la dimensión de proceso agrupa a los procesos en tres grupos que contienen cinco categorías de acuerdo al tipo de actividad: - Procesos primarios CUS: Cliente – Proveedor ENG: Ingeniería - Procesos de soporte SUP: Soporte - Procesos organizacionales MAN: Gestión ORG: Organización Para todos los procesos se definen los componentes: Identificador, Nombre, Tipo, Propósito, Salidas y Notas. Desde la dimensión de capacidad el modelo define una escala de 6 niveles para determinar la capacidad de cualquier proceso: NI BO OM R Nivel 0: Incompleto Nivel 1: Realizado Nivel 2: Gestionado Nivel 3: Establecido Nivel 4: Predecible Nivel 5: En optimización. A LA - VINCIT Página 27 de 134 ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI 1.4.5 Metodologías de trabajo A continuación, como introducción a los capítulos posteriores de este manual, mostraremos una tabla con un resumen de las características básicas de cada una de las metodologías de trabajo que se explicarán a lo largo del tutorial: - El modelo ITIL se aplica al ciclo de vida completo de TI. - El enfoque de ITIL para el manejo de cambio está orientado a garantizar la disponibilidad y operatividad del servicio. - Los entregables de un proyecto con el modelo PMBOK pueden ser producidos y gestionados también usando el modelo ITIL para gestión de servicios. P M - El enfoque de PMBOK respecto a la gestión de cambios es garantizar la calidad dentro I de la triple restricción que todo proyecto debe considerar: costo, tiempo, calidad y riesgos. - El modelo CMMI generalmente se aplica al desarrollo del servicio o infraestructura en TI (durante la implantación). C M - Posee actividades recomendadas para la gestión de la entrega de nuevos elementos M de software e infraestructura. I - Se centra en garantizar la calidad en el desarrollo de software. OM R T r a b a j o I T - Posee actividades recomendadas para la gestión de la entrega de nuevos elementos I de software e infraestructura. L - Se centra en garantizar la explotación del producto software. NI BO d e - Se enfoca en los procesos operacionales (post-implementación de un determinado servicio o infraestructura TI) A LA M e t o d o l o g í a s VINCIT Página 28 de 134 ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI 2. METODOLOGÍA DE PROCESOS ITIL 2.1 Definición La Biblioteca de Infraestructura de Tecnologías de Información, frecuentemente abreviada ITIL (Information Technology Infraestructure Library), es un set de documentos donde se describen los procesos requeridos para la gestión eficiente y efectiva de los Servicios de Tecnologías de Información dentro de una organización. Se considera un marco de trabajo para la Administración de Procesos de Tecnologías de la Información (a partir de ahora denominados TI), que reúne las mejores prácticas destinadas a facilitar la entrega de servicios. ITIL es una metodología que se basa en la calidad de servicio y el desarrollo eficaz y eficiente de los procesos que cubren las actividades más importantes de las organizaciones en sus Sistemas de Información y Tecnologías de Información. Garantizando así los niveles de servicio establecidos entre la organización y sus clientes. Esta metodología fue desarrollada a petición del Gobierno del Reino Unido a finales de los 80 y recoge las mejores prácticas en la gestión de los Sistemas de Información. Desde entonces se ha ido extendiendo su uso en toda la empresa privada, tanto multinacional como PYME, llegando a ser considerado un estándar de facto para la gestión de esta área de la empresa. El objetivo de ITIL es diseminar las mejores prácticas en la Gestión de Servicios de Tecnologías de Información. Esta metodología está especialmente desarrollada para reducir los costos de provisión y soporte de los servicios IT, al mismo tiempo de garantizar los requerimientos de la información en cuanto a seguridad, mantienen e incrementan sus niveles de fiabilidad, consistencia y calidad. ITIL brinda una descripción detallada de un número de prácticas importantes en TI, a través de una amplia lista de verificación, tareas, procedimientos y responsabilidades que pueden adaptarse a cualquier organización. También describe una aproximación sistemática y profesional a la Gestión de Servicios TI, haciendo énfasis en la importancia clave de cumplir con los requerimientos del negocio respetando los costos acordados. 2.2 Introducción 2.2.1 Orígenes de ITIL Durante los años 70, las Tecnologías de Información y los Sistemas de Información (TI/SI) se enfocaban específicamente al desarrollo y puesta en marcha de aplicaciones software, con el fin de obtener beneficios que servían al negocio como fuente para alcanzar una ventaja a nivel empresarial. Sin embargo, dichas aplicaciones debían ser administradas para aprovecharlas eficientemente, concentrando así todas las fuerzas en la entrega del servicio que brindaban al negocio. Es en este punto donde comienza a introducirse el concepto de Gestión del Servicio de Tecnologías de Información (ITMS). BO NI A LA OM R En los 80, la práctica de la gestión del servicio de TI se incrementó basándose en las expectativas futuras y el desarrollo tecnológico de las empresas. Esta práctica se inició con la implementación y el diseño de nuevas arquitecturas, plataformas y redes. Los empresarios vieron la necesidad de aprovechar las TI como fuente de apoyo para cumplir con la estrategia empresarial, reinterpretando la perspectiva de usar la gestión del servicio no sólo para las aplicaciones a desarrollar, sino también como un núcleo fundamental para tratar aspectos de la entrega del servicio que estas tecnologías brindaban al negocio. VINCIT Página 29 de 134 ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI Sin embargo, en el Reino Unido, se veía la necesidad de ir más allá en este campo, tratando de estandarizar y documentar de manera efectiva las mejores prácticas en cuanto a la gestión de los servicios que las TI y los SI prestan al negocio, con el fin de lograr que las organizaciones obtuvieran un mejor rendimiento y éxito en cuanto a la gestión del servicio. A esta documentación e interpretación de los servicios, el Reino Unido la llamó Biblioteca de Infraestructura de Tecnologías de Información (ITIL). La Biblioteca de Infraestructura de TI (ITIL) originalmente fue muy extensa, llegaron a ser más de 40 libros distribuidos a nivel nacional por toda Inglaterra. Sin embargo, a mediados de los 90 el término gestión de servicios aún era muy pobre, ya que no existía una documentación bien descrita y estándar de esta expresión. A mediados de los 90, y durante un periodo aproximado de 10 años, se llevó a cabo una revisión de ITIL, que se dio a conocer en el año 2004 y tuvo como resultado la versión 2 de ITIL, compuesta por un conjunto de 9 libros que se centraron en salvar la brecha existente entre las TI y el negocio, con una guía efectiva y especializada en los procesos requeridos para dar un mejor servicio en el ámbito de TI a todas las compañías. En el año 2004 la Oficina de Gobierno de Comercio del Reino Unido, comienza su tercera iniciativa de renovación de las mejores prácticas de la gestión del servicio que propone ITIL, como una necesidad urgente, debido a los altos avances y retos que están ocurriendo con las TI y los SI. De esta forma se implementa la tercera versión de ITIL llamada el ciclo de vida del servicio de ITIL. Hoy en día ITIL permanece como uno de los estándares más robustos a nivel mundial, pero a pesar de esto ha evolucionado y cambiado fuertemente tratando de alinearse a las necesidades de la empresa, pero conservando los conceptos fundamentales de la práctica. 2.2.2 Características de ITIL ITIL ofrece guías para la administración de los procesos de TI relacionados con: Planificación para la aplicación de los servicios de gestión: Plantea una guía para establecer una metodología de administración orientada a servicios. - Perspectiva de Negocio: Cubre el rango de elementos concernientes al entendimiento y mejora en la provisión de servicios de TI como una parte integral de los requerimientos generales del negocio. - Gestión de Aplicaciones: Se encarga del control y manejo de las aplicaciones operativas y en fase de desarrollo. - Gestión de Seguridad: Cubre los aspectos relacionados con la administración del aseguramiento lógico de la información. - Gestión de Infraestructuras: Cubre los aspectos relacionados con la administración de los elementos de la infraestructura. - Servicios de Soporte: Se orienta a asegurar que el usuario tenga acceso a los servicios apropiados para soportar las funciones de negocio. - Provisión de Servicios: Se orienta a detectar el servicio que la organización requiere del proveedor de TI a fin de brindar el apoyo adecuado a los clientes del negocio. A BO LA NI Página 30 de 134 OM R - VINCIT ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI A continuación, se detallan brevemente las características de las librerías que componen ITIL: - No propietaria: Los resultados finales no están basados en una simple persona u organización, sino en una vista de procesos particulares. - De dominio público: Cualquiera puede usarlo, es aceptado en todo el mundo como guía para administrar servicios de TI, aplicable a todos los sectores de la organización sin importar el tamaño de las mismas. - Conjunto de mejores prácticas: Es una colección de mejores prácticas orientadas a optimizar la infraestructura y servicios TI y alinearlos con los requerimientos del negocio. Prácticas que representan la experiencia de muchos profesionales TI. - De Facto Estándar: De lenguaje común, el modelo describe metas, actividades generales, recursos, entradas y salidas de varios procesos. - Acercamiento a la calidad: Asegura que los procesos cumplen con los requerimientos de ISO 9001 y BS 15000, siendo este último una normativa del Instituto de Estándares Británico, que describe códigos de prácticas para la gestión de servicios TI. 2.2.3 Beneficios de ITIL La propuesta de ITIL es la mejor utilización de los recursos de la organización, y define claramente hacia dónde deben ser dirigidos los recursos. De esta manera la empresa será más competitiva, porque estará en mejor posición para hacer cambios en su infraestructura de TI. Adicionalmente, ITIL optimiza la disponibilidad, confiabilidad y seguridad de toda la plataforma, facilitando también el aprendizaje de experiencias previas, lo que elimina el trabajo redundante. Por otra parte, los procesos y plazos de un proyecto se ven mejorados, porque estas metodologías involucran la definición de procedimientos estándares, ayudando así al desarrollo de servicios que satisfagan las demandas del negocio, clientes y usuarios. Los principales beneficios obtenidos por la implantación de la metodología ITIL son: Para el negocio: Incremento en la productividad del negocio: Mayor disponibilidad y fiabilidad de las Tecnologías de Información. o Mejora continua en la calidad de la prestación del servicio de las Tecnologías de Información, ya que, tiene en cuenta tanto las necesidades de la compañía como sus objetivos. o Reducción del riesgo de no cumplir los objetivos de negocio gracias a la capacidad de recuperación y a la consistencia de los servicios. o Mayor flexibilidad, y por lo tanto, mejor alcance de las acciones de la organización frente a cambios del entorno y el mercado. Posicionándose así en un soporte fiable para el negocio. o Soporte para los procesos de negocios y las tareas de toma de decisiones de TI, mediante la puesta en marcha de servicios basados en principios metodológicos y de calidad acordes con los requerimientos presentes y futuros de la compañía. BO NI A Página 31 de 134 OM R o LA - VINCIT ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI - - o Mejora en la satisfacción de los clientes, ya que se les asegura una mejora en la calidad del servicio entregado, Además el servicio puede ser representativamente medido, evaluado y gestionado. o Definición de funciones, roles y responsabilidades en el sector de los servicios. o Posibilidad de auditar el cumplimiento de las mejores prácticas. o Mejora en la satisfacción de los empleados y reducción de fluctuaciones de nivel de personal. o Incremento cualitativo en la seguridad, la disponibilidad y el rendimiento de los servicios de ITIL. Económicos: o Diseño de la infraestructura y servicios de las Tecnologías de Información a costos argumentados. o Reducción de los costos operativos de desarrollo, procedimientos e instrucciones de trabajo, al disponer, de un marco de trabajo definido Comunidad de usuarios de TI: o ITIL es comprensible e integral. o ITIL crea un vocabulario común. Esto comprende un amplio Glosario de Términos de TI simple de comprender que facilita la comunicación. 2.2.4 Ventajas e inconvenientes Entre el conjunto de ventajas que ofrece ITIL podemos diferenciar dos grupos, por un lado las ventajas de ITIL para los clientes y usuarios, y por otro las ventajas de ITIL para TI. A continuación, se enumeran las ventajas e inconvenientes más destacadas de este tipo de metodología: Ventajas de ITIL para los clientes y usuarios Mejora la comunicación con los clientes y usuarios finales a través de los diversos puntos de contacto acordados. Los servicios se detallan en lenguaje del cliente y con más detalles. Se maneja mejor la calidad y los costos de los servicios. La entrega de servicios se enfoca más al cliente, mejorando con ello la calidad de los mismos y la relación entre el cliente y el departamento de TI. Una mayor flexibilidad y adaptabilidad de los servicios. NI BO OM R A LA - VINCIT Página 32 de 134 ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI La organización TI desarrolla una estructura más clara, se vuelve más eficaz, y se centra más en los objetivos de la organización. La administración tiene un mayor control, se estandarizan e identifican los procedimientos, y los cambios resultan más fáciles de manejar. La estructura de procesos proporciona un marco para concretar de manera más adecuada los servicios de outsourcing. A través de las mejores prácticas de ITIL se apoya el cambio en la cultura de TI y su orientación hacia el servicio, y se facilita la introducción de un sistema de administración de calidad. ITIL proporciona un marco de referencia uniforme para la comunicación interna y con proveedores. Desventajas de ITIL Tiempo y esfuerzo necesario para su implementación. Que no se de el cambio en la cultura de las áreas involucradas. Que no se vea reflejada una mejora, por falta de entendimiento sobre procesos, indicadores y cómo pueden ser controlados. Que el personal no se involucre y se comprometa. La mejora del servicio y la reducción de costos puede no ser visible. Que la inversión en herramientas de soporte sea escasa. Los procesos podrán parecer inútiles y no se alcanzarán las mejoras en los servicios. OM R NI BO - Ventajas de ITIL para TI A LA - VINCIT Página 33 de 134 ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI 2.3 Metodología y procesos 2.3.1 Ciclo de vida de la gestión de servicio de ITIL Las prácticas de la gestión de servicios están formadas bajo dos focos importantes. El primero de ellos son las prácticas de la gestión de servicios de TI, es decir, el núcleo del de vida del servicio. El segundo son las prácticas complementarias que contienen situaciones reales sobre la gestión del servicio. En cuanto al núcleo del ciclo de vida del servicio, está formado por 5 componentes fundamentales, cada uno de los cuales contiene unos principios de servicio, procesos, roles y medidas de desempeño. En la figura siguiente, podemos observar un modelo del ciclo de vida de ITIL, con sus principales componentes: Como ya hemos mencionado anteriormente, y como se puede observar en la figura, ITIL propone 5 componentes fundamentales del ciclo de vida de servicio que proveen un conjunto de mejores prácticas que incluyen completamente al negocio y se alinean con las estrategias y objetivos de éste. El componente principal es la estrategia del servicio, que constituye una guía completa relacionada con la forma de ver la gestión de servicios, no solamente como una capacidad organizativa sino como una manera de llegar a la estrategia empresarial. - El segundo componente es el diseño del servicio. El diseño de servicio provee una guía para delinear y desarrollar servicios y prácticas para la gestión efectiva de los servicios. Cubre los principios de diseño y métodos para lograr los objetivos estratégicos. A BO LA NI Página 34 de 134 OM R - VINCIT ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI - El siguiente componente del ciclo de vida del servicio se encuentra en el mismo nivel del diseño del servicio, y es la transición del servicio. Ésta provee una guía para el desarrollo y la mejora de las habilidades para efectuar nuevos servicios o cambiarlos de operación. - Otro componente que se encuentra bajo el mismo nivel de servicios que tiene la transición del servicio y el diseño del servicio, es la operación del servicio. Este contiene las prácticas más efectivas de la gerencia de infraestructura y operaciones, incluyendo una guía eficiente sobre la entrega y el soporte de los servicios. - Finalmente, el último y más importante componente del ciclo de vida es la mejora continua del servicio. Ésta tiene una guía instrumental para la creación del valor de la empresa a través del mejor diseño, y la transacción y operación de los servicios. 2.3.2 Subprocesos Los 5 componentes a los que se ha hecho referencia en el apartado anterior, pueden ramificarse en diversos subprocesos, a continuación mostraremos una breve síntesis de los mismos: Manejo de Incidentes Su objetivo primordial es restablecer el servicio lo más rápido posible para evitar que el cliente se vea afectado, esto se hace con la finalidad de que se minimicen los efectos de la operación. Se dice que el proveedor se debe encargar de que el cliente no perciba todas aquellas pequeñas o grandes fallas que llegue a presentar el sistema. Este concepto se conoce como disponibilidad (que el usuario pueda tener acceso al servicio y que nunca se vea interrumpido). Para este proceso se tiene un diagrama que en cada una de sus fases maneja cuatro pasos básicos: propiedad, visualización, seguimiento y comunicación. A continuación, se enumeran las etapas que componen el proceso de manejo de incidentes, en el orden en el que se llevan a cabo: Detección del incidente (El sistema presenta alguna anomalía o fallo) Clasificación del incidente (Vemos si el error que se presenta es conocido o si nunca se ha presentado). Soporte inicial (El cliente llega a la mesa de servicio a solicitar ayuda, porque no sabe o no puede hacer algo) En caso de que el incidente sea conocido se hace el procedimiento de solicitud de servicio, es decir, se ejecutan los pasos a seguir según el manual de procedimientos para poder llegar a la solución de una forma viable y eficiente. Una vez que ya se le dio una solución al incidente por medio del manual de procedimientos se recurre a la documentación y contabilización del incidente. BO NI A Página 35 de 134 OM R Finalmente se hace una evaluación para ver si efectivamente el incidente se resolvió de forma satisfactoria, en caso afirmativo se da por cerrado. LA VINCIT ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI Si la solución planteada no es lo suficientemente eficiente o acertada para resolver el problema, se recurre a hacer una investigación y un diagnóstico de la situación. Una vez que se tiene todo el contexto analizado se recurre a la ejecución de la solución propuesta, y se hace un estudio para ver si el incidente es recuperable. Por último, se cierra el incidente y esta solución se documenta en una base de datos para que cuando se vuelva a presentar el mismo problema, este se resuelva de forma más fácil, rápida y eficiente. En la siguiente figura, se muestra un diagrama con los pasos llevados a cabo cuando se detecta un incidente: Manejo de problemas El objetivo de este proceso es prevenir y reducir al máximo los incidentes, por tanto esto nos conduce a una reducción en el nivel de incidencia. Por otro lado nos ayuda a proporcionar soluciones rápidas y efectivas para asegurar el uso estructurado de recursos. NI BO OM R En este proceso lo que se busca es que se pueda tener pleno control del problema, esto se logra dándole un seguimiento y una visualización al problema. A LA VINCIT Página 36 de 134 ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI El diagrama de este proceso es muy particular, ya que se maneja en dos fases: control del problema y control del error: En lo que respecta a la fase de control del problema, primero se tiene que identificar el problema en base a alguna sintomatología. Una vez hecho esto pasamos a la clasificación de los problemas (en este proceso al igual que en el proceso de manejo de incidentes tenemos que ver si es un problema conocido). En caso de ser conocido, se recurre al procedimiento de solicitud de servicio, donde se van a aplicar las soluciones de acuerdo al manual de procedimientos. En caso de no ser conocido se tendría que hacer una fase de investigación para analizar qué es lo que genera el problema, y más tarde hacer un diagnóstico. Tras tener un diagnóstico hemos de hacer un RFC (Request For Change o Solicitud de Cambio). Esta solicitud de cambio implica que se va a tener que implementar la solución y finalmente se va a hacer una evaluación para ver si se resolvió el problema de raíz. En caso de que sea válida esta solución se pasa a la documentación. Con lo que respecta a la segunda fase del modelo, el control del error se hace por medio de una identificación del error en general. Posteriormente se hace una especie de registro, y este va a servir para clasificar el mismo. Tras llevar a cabo la clasificación, se recurre a una evaluación del daño generado o que puede llegar a generar el error, con la finalidad de cuantificar los desperfectos que podría llegar a causar en caso de que prevalezca y no se solucione. NI BO OM R Posteriormente, se hace la resolución o corrección del error y se determina qué problemas están asociados al que ha sido detectado. A LA VINCIT Página 37 de 134 ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI Manejo de configuraciones Su objetivo es proveer con información real y actualizada de lo que se tiene configurado e instalado en cada sistema del cliente. Este proceso se mueve bajo cuatro vértices: Administración de cambios, Administración de liberaciones, Administración de configuraciones y Administración de procesos diversos. El nivel de complejidad de este modelo es alto, ya que influyen muchas variables, en su mayor parte dinámicas. Por tanto, al cambiar una o varias variables se afecta el sistema en general, lo que hace que sea muy difícil de manipular. Manejo de cambios El objetivo de este proceso es reducir los riesgos tanto técnicos, como económicos y de tiempo en el momento de la realización de los mismos. Este punto puede parecer muy fácil de seguir, pero en realidad no lo es, ya que entre etapa y etapa se da una fase de visualización para ver que no se han sufrido desviaciones de los objetivos. Primero vemos que tenemos un registro y clasificación del cambio que se tiene que hacer, después se pasa a la fase de visualización y planteamiento. Si el rendimiento es satisfactorio se da la aprobación del cambio, y en caso de que el rendimiento sea malo se pasa a la fase de re-ingeniería hasta que el proceso funcione adecuadamente. Se ejecutan las pruebas pertinentes para ver las capacidades del sistema, y una vez que el proceso está probado se da la autorización para su implementación. Ya implementado se comprueba que no haya tenido desviaciones y se ajusta a las necesidades actuales. Este último paso también se considera una revisión post-implementación. Manejo de entregas Su objetivo es planear y controlar exitosamente la instalación, bajo tres fases diferenciadas: Ambiente de desarrollo, Ambiente de pruebas de controladas y Ambiente real. Este proceso tiene un diagrama que marca la transición que se da, de acuerdo a los ambientes por los que se va llevando a cabo la evolución de todo el proceso. Es el punto en el que el usuario hace uso del servicio y no sabe que detrás del mismo, hay un sin fin de actividades y de decisiones que se tuvieron que tomar para llegar a este punto. NI BO OM R Este proceso es el más delicado, ya que en caso de haber fallos, el primero en detectarlos o percibirlos es el cliente. A LA VINCIT ADAMS Página 38 de 134 TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI 2.3.3 Componentes del ciclo de vida de servicio Como ya hemos mencionado en el apartado 2.3.1, ITIL propone 5 componentes fundamentales del ciclo de vida de servicio que proveen un conjunto de mejores prácticas que incluyen completamente al negocio y se alinean con las estrategias y objetivos de éste. En este apartado explicaremos y estudiaremos en profundidad cada uno de estos componentes. 2.3.3.1 Estrategia del servicio En el ciclo de vida del servicio de ITIL, la estrategia del servicio es la primera fase donde se ponen a prueba todas las capacidades y las habilidades de implementar servicios efectivos de TI, con el apoyo de los proveedores de servicios de la organización, cumpliendo con las estrategias de negocio. Constituye la base fundamental de medida de viabilidad y coste para poner en marcha los servicios de TI, a partir del retorno de la inversión, la utilidad efectiva en el tiempo y la verdadera importancia para el negocio. La estrategia del servicio tiene la responsabilidad junto con los gerentes de sistemas, del negocio y de TI, de generar decisiones actuales y futuras que sean efectivas y eficientes para la organización (desde las decisiones sobre el gasto en la inversión tecnológica, que dan como resultado los objetivos y metas del negocio, hasta aquellas que son de bienestar y crecimiento y se ven representadas en las utilidades de la empresa). BO NI A LA OM R De este modo, es muy importante estudiar e investigar la estrategia del servicio con el fin de generar los mejores resultados, colocando a prueba todas las necesidades estratégicas que requiere el negocio alineadas con las necesidades del servicio. Y buscando encontrar la mejor solución en cuanto a los costos de inversión, la viabilidad de la implementación, la garantía, la funcionalidad y el valor agregado. VINCIT Página 39 de 134 ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI El marco práctico que propone la estrategia del servicio consiste en una serie de conceptos que representan una guía a seguir por las organizaciones para generar una verdadera estrategia del servicio. Dichos conceptos son: La creación del valor Los activos del servicio Los tipos de proveedores del servicio Las capacidades, recursos y estructuras del servicio La definición del mercado del servicio El desarrollo de ofertas de servicio La gestión financiera Los portafolios del servicio La gestión de la demanda de servicios La evaluación del servicio El retorno de la inversión. Cada etapa del ciclo de vida del servicio de ITIL contiene una serie de conceptos relevantes, sostenidos en un marco de trabajo que posee un conjunto de procesos a seguir para una efectiva gestión de servicios de TI. Estos procesos y conceptos muestran al detalle el conjunto de mejores prácticas que debe alcanzar una organización para lograr una buena administración de servicios. A continuación, se detallan los conceptos fundamentales de la estrategia del servicio: - Evaluación Estratégica: Durante la elaboración e implementación de la estrategia del servicio, los proveedores de servicios deben tener cuidado con la estrategia actual que está siguiendo la organización. Primero el proveedor del servicio debe entender completamente cuáles son los servicios o formas del servicio más distintivos. Se debe distinguir el conjunto de servicios que son más relevantes para el proveedor del servicio, visualizando si esta serie de servicios también son importantes para la organización. El proveedor debe conocer también, cuáles de los servicios no pueden sustituirse fácilmente en el negocio y mucho menos para la gestión con los clientes. BO NI A LA OM R Asimismo, deberá tener claro cuáles son los servicios o el conjunto de servicios que son más rentables, y cuáles de los clientes o socios de capital están más satisfechos. VINCIT Página 40 de 134 ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI Por último, tendrá que preguntarse sobre cuáles de las actividades en la cadena de valor o el valor de la red son los más efectivos y distintivos, es decir, si las actividades de la cadena de valor utilizada por el negocio y el proveedor de servicios son verdaderamente efectivos en el tiempo y se distinguen de las demás actividades de los procesos del negocio. Las respuestas a estas preguntas son probablemente los patrones para seguir en las decisiones estratégicas futuras del negocio, formando la base de evaluación estratégica de la organización. Para una evaluación estratégica hay que tener presente que los proveedores del servicio pueden tener varios espacios del mercado y funcionar en muchos de estos. Por lo tanto, deben analizar su presencia a través de los distintos espacios del mercado con el fin de usar uno solo para la evaluación. La revisión de la estrategia incluye un estudio sobre el espacio de mercado, haciendo un análisis de fortalezas, debilidades, oportunidades y amenazas, es decir, un análisis estilo matriz DOFA (Debilidades, Oportunidades, Fortalezas y Amenazas). De la misma forma, los proveedores del servicio deben analizar el potencial del negocio basados en los servicios prestados y los espacios de mercado. Todos estos análisis constituyen un aspecto importante de dirección y liderazgo en la provisión de la gestión gerencial del proveedor de servicio. - Desarrollo de capacidades estratégicas: Para que una empresa pueda operar y crecer de manera exitosa a largo plazo, los proveedores del servicio deben tener la capacidad y habilidad de pensar y actuar de manera estratégica. El propósito de la estrategia del servicio es ayudar a que las organizaciones desarrollen sus capacidades y habilidades estratégicas. El logro de las metas y objetivos estratégicos debe enfocarse en el uso y la utilización de los activos estratégicos. Para el desarrollo de las capacidades estratégicas y la transformación de los servicios a activos estratégicos, ITIL necesita que el proveedor del servicio responda las siguientes preguntas sobre la gestión de los servicios: ¿Qué servicios se deben ofrecer? ¿Cómo diferencia el negocio las alternativas de competitividad? ¿Qué hace el negocio para crearle valor a los clientes? ¿Cómo se debe definir la calidad de los servicios? ¿Cómo se localizan efectivamente los recursos a través del portafolio de servicios? ¿Cómo se resuelven las demandas de conflicto como parte de los recursos? A BO LA NI Página 41 de 134 OM R VINCIT ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI Para responder tales preguntas es necesario un enfoque y conocimiento multidisciplinario. El conocimiento técnico de TI es necesario pero no suficiente. De esta manera, con las respuestas a algunas de las preguntas anteriormente enunciadas se puede obtener la lista de los servicios a transformar en activos estratégicos y se logra concluir qué capacidades estratégicas deben ser desarrolladas en el negocio. - Tipos de proveedores del servicio: Los proveedores del servicio son quienes ayudan a controlar las restricciones con los clientes propios y los recursos específicos. La relación entre los clientes y los proveedores del servicio varía de acuerdo con la especialización propia de cada cual. La estrategia del servicio define tres tipos de proveedores de servicio: Tipo de proveedor Descripción Tipo I: Este tipo de proveedor es un área de la organización que entrega los servicios a las unidades de negocio. Proveedor de Servicio Interno Tipo II: Proveedor de Partes de un Servicio El proveedor de servicio tipo I tiene la habilidad de acoplamiento con los clientes propios, disponiendo de los costos y los riesgos asociados a la conducción del negocio con las partes externas. En vez de utilizar ciertos servicios y funciones de áreas del negocio que no representan una ventaja competitiva para la organización, como finanzas, recursos humanos, logística, entre otros, estos son consolidados dentro de una unidad autónoma especial llamada unidad dividida de servicios (SSU). Con este modelo el proveedor permite el desarrollo de una estructura de gobierno en el cual la SSU puede centrarse en servir a las unidades del negocio como a los clientes directos. El proveedor de servicio tipo III es una organización externa al negocio que puede ofrecer un precio competitivo, además de manejar unos costos bajos en las unidades de negocio para consolidar así la demanda. NI A Página 42 de 134 OM R Para los clientes que requieren flexibilidad y menor costo en los servicios, el proveedor del servicio tipo III es el mejor en el establecimiento de éstos. Hoy en día, es muy común ver los tres tipos de proveedores de servicios con la combinación de las capacidades de cada uno para la gestión de servicios con los clientes. BO Proveedor de Servicio Externo Los ambientes del negocio competitivos requieren de organizaciones externas para flexibilizar las estructuras y los modelos de éste, además bajar los costos de ejecución en la organización. LA Tipo III: VINCIT ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI - Servicios como activos: Los activos de servicios poseen dos características principales: La utilidad La garantía La utilidad es tomada por la percepción del cliente, mientras la garantía es relativa al buen funcionamiento en el tiempo. Los recursos y las capacidades constituyen diferentes tipos de activos que cuando se combinan generan mayor productividad. Por lo tanto, las organizaciones usan tanto los recursos como las capacidades para generar servicios con gran valor. Los recursos son quienes están directamente en las entradas a producción, es decir, son las herramientas que generan los resultados productivos. Mientras que las capacidades, representan la habilidad de la organización para coordinar, controlar y desplegar los recursos para la producción y generación de valor al negocio. - Definir el espacio de mercado: Un espacio de mercado está definido por un conjunto de resultados del negocio que facilitan el exitoso comportamiento de éste por medio de los servicios. La oportunidad de facilitar aquellos resultados definidos en un espacio de mercado se consigue utilizando mecanismos de computación que generen ganancias para el negocio, como se muestra a continuación en los siguientes ejemplos: Los equipos de ventas son productivos con los sistemas de gestión de ventas por medio de computación inalámbrica. Las aplicaciones claves del negocio son monitoreadas y seguras. Los servicios de pagos en línea ofrecen más opciones para los compradores. Un espacio de mercado representa, por lo tanto, un conjunto de oportunidades para entregar valor a los clientes por medio de los proveedores del servicio a través de uno o varios servicios. - Portafolio del servicio: El portafolio del servicio representa el conjunto de compromisos e inversiones realizadas por el proveedor del servicio a través de los clientes y los espacios de mercado. También incluye los servicios de terceros, los cuales son una parte integral de los servicios ofrecidos a los clientes. (Es muy importante tener presente que algunos de los servicios con terceros son visibles a los clientes mientras otros son internos a la compañía) El portafolio del servicio representa todos los recursos comprometidos o aquellos que están siendo liberados en varias fases del ciclo de vida del servicio, ya que cada fase requiere recursos para la terminación de los proyectos, iniciativas y contratos. BO NI A LA OM R El portafolio del servicio debe tener la mezcla correcta de los servicios en el desarrollo de los espacios del mercado y del catálogo del servicio, para asegurar la viabilidad financiera del proveedor de servicio. VINCIT Página 43 de 134 ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI - Segmentación del servicio: La segmentación del servicio consiste en desarrollar y ejecutar servicios para generar un espacio de mercado en la organización y por supuesto en los clientes. El término segmentación representa un proveedor de servicio que está aumentando el futuro estratégico del negocio. El buen funcionamiento en general del proveedor del servicio depende totalmente de la segmentación. Igualmente, con la segmentación se da como resultado la implementación de nuevos servicios e ideas para mejorar la estrategia del servicio, el diseño y la mejora continua. Teniendo una buena gestión financiera, se garantiza en corto y largo plazo la financiación adecuada para la segmentación. - Catálogo del servicio: El catálogo del servicio pertenece a un subconjunto del portafolio del servicio que es visible a los clientes. El catálogo está formado por aquellos servicios que se encuentran totalmente activos en la fase de operación del servicio, y el conjunto de los servicios que han sido aprobados para facilitar los procedimientos sobre los procesos actuales y los que se quieren ejecutar a largo plazo. El catálogo del servicio es muy útil para el desarrollo adecuado de las soluciones de los clientes, desde el punto de vista de uno o más servicios. El conjunto de ítems pertenecientes al catálogo del servicio pueden ser configurados, conforme a los costos y al cumplimiento particular de las necesidades requeridas por la organización. Además, es una herramienta que pertenece a la estrategia del servicio y constituye una proyección virtual del proveedor del servicio actual y las necesidades presentes en la organización. - Outsourcing del servicio: En la actualidad el outsourcing es el movimiento que genera mayor actividad de creación de valor en las organizaciones tanto fuera como dentro de estas. Para el outsource los indicadores constituyen la actividad que determina las ganancias y resultados en la organización. Existen varios tipos de estructuras de Sourcing, entre las que se encuentran las siguientes: Estructura Interna (Tipo I): La provisión y la entrega de todos los servicios se lleva a cabo por cuenta del personal interno de la empresa. No se utiliza un enfoque estándar de la entrega del servicio a través de las unidades del negocio, además provee mayor control pero con un mayor límite de escala de términos. Parte del servicio (Tipo II): Constituye una unidad de negocio interna. A veces opera como un beneficio o como una pérdida. Su mecanismo de utilización es por cargos básicos, de manera que si el costo de recuperación no es usado, no hay un cargo de costo cobrado. Este tipo de estructura mejora la estandarización. BO NI A LA OM R VINCIT Página 44 de 134 ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI Outsourcing completo de un servicio: Constituye un simple contrato con un proveedor de servicio, a quien se le transfieren los activos para su uso. Es el tipo de estructura que provee la mejor escala sin limitar los términos de las capacidades, aunque parte de una alternativa difícil: entregar todos los activos de la empresa. Prime: Hay un contratista y un proveedor de servicio que gestiona la entrega de los servicios. El contratista es quien estipula qué vendedor de servicios primará sobre las otras clases de proveedores del servicio. Consorcio: Constituye un conjunto de proveedores del servicio que son explícitamente seleccionados por concurso, de acuerdo con los servicios que prestan. Todos los proveedores de servicios son requeridos en la reunión y cada uno debe presentar la interfaz de gestión definida sobre los servicios a entregar, cumpliendo completamente con las necesidades que no pueden ser satisfechas por proveedores de servicio de outsourcing. Este tipo de estructura provee las mejores habilidades en el control, más que la estructura prime. Existe riesgo, que es introducido por la competencia entre los proveedores. Outsourcing selectivo: Consiste en una colección de proveedores del servicio que se seleccionan de acuerdo con la gestión que proponen. Quien dirige la selección es el integrador del servicio. El término co-sourcing es un caso especial de outsourcing selectivo, puesto que el integrador mantiene los servicios internos o parte de los servicios con proveedores externos. Los proveedores socios de las organizaciones, utilizan estándares de enfoque internacional con el fin de reducir el riesgo de los servicios entregados por el Sourcing, usando específicamente ISO/IEC 20000 y otros. Las organizaciones de Sourcing buscan siempre lograr este tipo de certificaciones que constituyen la base sostenida para la entrega de los niveles de servicio. - Retorno de la inversión (ROI): El retorno de la inversión (ROI), es un concepto utilizado para cuantificar el valor de la inversión y la utilidad de la gestión empresarial. Es usado en gran medida en las compañías, pero no siempre aporta un enfoque preciso. Trata específicamente el área financiera de las organizaciones y se enfoca en el concepto más útil, el retorno de la inversión de capital ROIC mejorando el desempeño del negocio. BO NI A LA OM R En la gestión de servicios, el ROI y ROIC son usados como medidas sobre las capacidades de los activos comprados por la organización y la forma en que estos generan un valor adicional a la utilidad del negocio. VINCIT Página 45 de 134 ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI Matemáticamente hablando, consiste en la ganancia neta de la inversión dividida por el valor neto de los activos invertidos. El porcentaje resultante expresa si realmente hubo retorno de la inversión para poder ejecutar una renovación adicional del activo o para la eliminación del costo del activo en la gestión financiera: Ganancia de la Inversión (Neta) ROI = ---------------------------------------------------Valor de los activos invertidos (Neto) Si hay una eliminación del costo significa que la inversión fue totalmente útil para la organización, entonces está dando ganancias y se retribuyó el costo de la inversión en las utilidades. Si el porcentaje del ROI no da como resultado un retorno quiere decir que el activo no ha generado utilidades ni mucho menos ha retribuido la inversión inicial. La aplicación del ROI en la gestión de servicios puede tener diferentes resultados, que muchas veces no generan las respuestas correctas sobre el retorno de la inversión, puesto que las medidas de cuantificación son más complejas en términos de los tiempos de ejecución y vida de los servicios. - Gestión financiera: La gestión financiera consiste en una herramienta estratégica que provee la cuantificación del negocio y de TI en términos financieros, el valor de los servicios entregados por TI, el valor de los activos que apuntan a la provisión de los servicios y la calificación numérica operacional. Por tanto, una porción de la gestión financiera es trabajar con TI y el negocio para ayudar a identificar, documentar y acordar el valor de los servicios que está recibiendo la organización y aquellos establecidos en la modelación de la demanda y la gestión del servicio. Las organizaciones de TI están aumentando la incorporación de la gestión financiera, buscando una serie de características tales como: Ampliar las decisiones a tomar, implementar velocidad de cambio, impulsar la gestión del portafolio, generar control y cumplimiento financiero, control operacional y capturar y controlar el valor de los servicios. La meta de la gestión financiera es garantizar la financiación correcta para la entrega y el consumo de los servicios. - Valoración del servicio: Cuantificar el valor de los servicios en términos financieros es una tarea difícil de realizar puesto que son varios puntos específicos los que deben ser estudiados para obtener el verdadero valor de éstos. Se evalúan los siguientes costos y cargos de los servicios para generar el valor del servicio de la organización: BO NI A Página 46 de 134 OM R Costos en las licencias de hardware y software. Cargos por mantenimiento anual para hardware y software. Recursos personales usados en el soporte o el mantenimiento de un servicio. Utilidades, centro de datos u otros cargos característicos. Cargos por impuestos, capital o intereses. Costos de cumplimiento. LA VINCIT ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI La gestión financiera juega un papel de traducción entre los sistemas financieros corporativos y la gestión de los servicios. El resultado de esta traducción es obtener una generación de datos que alimenten directamente los procesos de planificación de la gestión financiera. Las funciones y las características de los sistemas de gestión financiera y gestión de servicios contienen: El registro de los servicios: A cada servicio se le asigna un costo de entrada, dependiendo de la definición de tal servicio. Los tipos de costos: Hay grandes categorías de niveles de gastos tales como hardware, software, los laborales, los administrativos. Clasificación del costo: Existe también clasificaciones dentro de los servicios que se diseñan con el propósito final de costearlos. Estos incluyen clasificaciones tales como: - Capital u Operacional: Es una clasificación que se aplica sobre las metodologías de conteo que son requeridas por el negocio y las agencias reguladoras de éste. - Directa o Indirecta: Esta designación determina cualquier costo que sería asignado directamente o indirectamente por un consumidor o servicio. - Fijo o Variable: Esta es una segregación de costos basada en los compromisos contractuales de tiempo o precio. La cuestión estratégica a lo largo de esta clasificación es que el negocio debe buscar optimizar los costos fijos de servicios y minimizar los variables de manera estable. - Unidades de costos: Una unidad de costo es la unidad identificada en los consumos tomados en consideración, por un servicio particular o un activo de servicio. - Dinámica de costo de variable: La dinámica de costo variable (VCD) pertenece a la gestión financiera y se centra en el análisis y entendimiento de una multitud de variables que impactan sobre los costos del servicio. Con esta dinámica, se pueden obtener los valores de costeo relativos, de los servicios o componentes de éstos. A continuación se presenta una lista de posibles variables sobre los componentes de costos de servicio, que podrían ser incluidos en este tipo de análisis dinámico de costo variable: NI BO OM R Número y tipos de usuarios. Número de licencias de software. Costo de operación del centro de datos. Mecanismos de entrega. Número y tipos de recursos. Costo de añadir una o más unidades de almacenamiento. Costo de añadir una o más licencias de usuario final. A LA VINCIT Página 47 de 134 ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI - Desarrollo organizacional: Cuando la gerencia de los negocios adopta una orientación basada en la gestión de servicios, se está generando una visión para la organización. Esta visión provee el modelo en el cual el personal de la compañía trabajará. Sin embargo, este cambio organizacional de orientación a la gestión de servicios no se hace de manera instantánea, sino que es complejo. En el diseño organizacional se deben tener presentes los elementos de escala, alcance y estructura, que son dependientes de los objetivos estratégicos, para que con el paso del tiempo, la organización probablemente impulse el diseño pertinente. A BO LA NI Página 48 de 134 OM R Hoy en día, es muy común pensar en jerarquías organizacionales realizadas en términos de funciones, producción, espacios de mercado, geográficos o de procesos. Las estructuras organizacionales para las estrategias de servicio se basan en los mismos términos, y son ejecutadas por la entrega y el soporte del portafolio del servicio contratado en un espacio de mercado dado. VINCIT ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI 2.3.3.2 Diseño del servicio Después de la estrategia del servicio, el diseño de servicio es la siguiente etapa en el ciclo de vida de ITIL, este ciclo no es lineal, sin embargo cada etapa describe una progresión lógica. Los conceptos claves del diseño de servicio giran alrededor del diseño y los procesos de los servicios, y las capacidades del servicio para conocer la demanda del negocio. Los principales elementos que ilustran los objetivos de esta etapa en el ciclo de vida, son: Aspectos del diseño de servicio Gestión del catálogo de servicios Requerimientos de servicios Modelos de diseño de servicio Gestión de la capacidad Gestión de la disponibilidad Gestión del nivel de servicio. A BO LA NI Página 49 de 134 OM R El principal objetivo del diseño de servicio es el diseño de servicios nuevos o cambiantes. Los requerimientos para estos nuevos servicios son extraídos del portafolio de servicios y cada requerimiento es analizado, documentado y acordado. El diseño de la solución es producido y comparado con las estrategias y restricciones de la estrategia del servicio para asegurar que cumple con las políticas de la organización. VINCIT ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI A continuación, se detallan los conceptos fundamentales del diseño del servicio: - El valor del negocio: Con un buen diseño de servicios es posible entregar calidad, bajo costo y asegurar que los requerimientos del negocio son conocidos. Los siguientes beneficios son resultados de unas buenas prácticas de diseño de servicios: Reducción del costo total: el costo total puede ser minimizado si todos los aspectos de los servicios, procesos y tecnología son diseñados apropiadamente e implementados contra el diseño. Mejora de la calidad del servicio: la calidad del servicio y su operación pueden ser incrementados. Mejora de la consistencia del servicio: dado que los servicios son diseñados dentro de las estrategias, arquitecturas y restricciones corporativas. Facilidad de implementación de los servicios nuevos o cambiados: desde la concepción del servicio se asegura que los servicios nuevos o cambiantes coincidan con las necesidades del negocio. Desempeño más efectivo de los servicios: con la incorporación y reconocimiento de la capacidad, financiamiento, disponibilidad y plan de continuidad de los servicios de TI. Mejora de la gobernabilidad de TI: con la implementación y comunicación de un conjunto de controles para una gobernabilidad de TI efectiva. Gestión de servicios y procesos de TI más efectiva: los procesos son diseñados con calidad óptima y costos efectivos. Información y toma de decisiones mejorada: métricas y medidas más integrales y efectivas, que permitirán una mejor toma de decisiones y una mejora continua de las prácticas de gestión de servicios, en la etapa de diseño del ciclo de vida del servicio. - Aspectos del diseño de servicios: Hay cinco aspectos de diseño que es necesario considerar: 1. El diseño de los servicios, incluyendo todos los requerimientos funcionales, recursos y capacidades necesarias y acordadas. 2. El diseño de la gestión de sistemas y herramientas del servicio, especialmente el portafolio de servicios. 3. El diseño de las arquitecturas tecnológicas y los sistemas de gestión requeridos para proveer el servicio. 4. El diseño de los procesos necesarios para el diseño, la transición, operación y mejora de servicios. BO NI A LA OM R 5. El diseño de métodos de medición y métricas de servicios. VINCIT Página 50 de 134 ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI Cada uno de los cinco aspectos anteriores debe llevar a cabo un acercamiento orientado a los resultados. Los resultados deseados y los resultados planeados deben ser definidos de forma que la entrega cumpla con las expectativas del cliente y los usuarios. Este acercamiento estructurado debe ser adoptado dentro de cada uno de los cinco aspectos para proporcionar calidad, consistencia y mejoramiento continuo a través de la organización. - Requerimientos de servicios: El diseño de servicios debe considerar el servicio, sus componentes constitutivos y sus interrelaciones, asegurando que el servicio es entregado de acuerdo con las expectativas del negocio en todas las áreas: La escalabilidad del servicio para cumplir con los requerimientos futuros y soportar a largo plazo los objetivos del negocio. Los procesos y las unidades de negocio soportados por el servicio. El servicio de TI de acuerdo con las funcionalidades y requerimientos del negocio. El servicio mismo y sus requerimientos de nivel de servicio (SLR) y acuerdos de nivel de servicio (SLA). Los componentes tecnológicos usados para desplegar y entregar el servicio, incluyendo la infraestructura, el ambiente, los datos y las aplicaciones. Los servicios, componentes y sus acuerdos de nivel de operación (OLA) soportados internamente. Los servicios y componentes soportados externamente y sus contratos de apoyo (UC), que a menudo tendrán sus propios horarios y acuerdos relacionados. Las medidas de desempeño y métricas requeridas. Los niveles de seguridad legislados o requeridos. Las actividades del proceso de diseño, son: Recolección de los requerimientos del negocio, análisis e ingeniería para asegurar que los requerimientos del negocio están claramente documentados y acordados. Diseño de servicios, tecnología, proceso, información y medidas de procesos apropiados para conocer los requerimientos del negocio. Revisión de todos los procesos y documentos contenidos en el Diseño de Servicios, incluyendo diseños, planes, arquitecturas y políticas. NI BO OM R Producción y mantenimiento de las políticas de TI y los documentos de diseño, incluyendo diseños, planes, arquitecturas y políticas. A LA VINCIT Página 51 de 134 ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI Revisión de todos los documentos de diseño y planeación para el desarrollo e implementación de estrategias de TI utilizando un conjunto de directrices, programa y planes de proyectos. Gestión y evaluación del riesgo de todos los procesos de diseño y entregables. Aseguramiento de la alineación los diseños del servicio con todas las políticas y estrategias de TI corporativas. - Opciones de modelo de entrega: Hay muchas estrategias de entrega que pueden ser usadas. Cada una tiene su propio conjunto de ventajas y desventajas, pero todas requieren algún nivel de adaptación y personalización para la situación que se está manejando. A continuación se presenta una lista de las principales categorías de estrategias de suministro: Insourcing: Utiliza recursos internos de la organización para el diseño, desarrollo, transición, mantenimiento, operación y/o soporte de los servicios nuevos, cambiados, revisados o las operaciones del centro de datos. Outsourcing: Utiliza recursos de una o varias organizaciones externas en un arreglo formal para proveer una porción bien definida de diseño, desarrollo, mantenimiento, operación y/o soporte de los servicios, incluyendo el uso de servicios desde Proveedores de servicio de aplicación (ASP). Co-Sourcing: Utiliza una combinación de insourcing y outsourcing, con un número de organizaciones trabajando juntas para proporcionar los elementos claves dentro del ciclo de vida. Generalmente incluye usar un número de organizaciones externas trabajando juntas para diseñar, desarrollar, mantener, operar y/o soportar una porción del servicio. Sociedad o Multi-Sourcing: Son acuerdos formales entre dos o más organizaciones que trabajan juntas para diseñar, desarrollar, mantener, operar y/o soportar servicios de TI. Este enfoque tiende a una asociación estratégica que apalanca la experiencia y las oportunidades de mercado. Outsourcing de los Procesos de Negocio (BPO): Utiliza acuerdos formales entre organizaciones en las que se reubican las funciones del negocio. En este caso, una organización provee y maneja todo el proceso de negocio o algunas funciones de las demás organizaciones en una ubicación de bajo costo, por ejemplo la contabilidad, la nómina o la operación de un call center. Provisión de servicio de aplicaciones (ASP): Son arreglos formales con una organización proveedora de servicio de aplicaciones (ASP) que entrega servicios compartidos sobre una red para la organización cliente. Las aplicaciones ofrecidas de esta forma son también denominadas como aplicaciones software on-demand. A través de los ASP la complejidad y el costo de software compartido puede ser reducido y proporcionado a organizaciones que no podrían justificar la inversión de otra forma. BO NI A LA OM R VINCIT Página 52 de 134 ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI Outsourcing de los procesos de conocimiento (KPO): Las organizaciones KPO proveen procesos basados en el dominio y experiencia en el negocio, en vez de experiencia en el proceso, y requieren habilidades especializadas y análisis avanzado. - Gestión del catálogo de servicios: Hay muchas estrategias de entrega que pueden ser usadas. Cada una tiene su propio conjunto de ventajas y desventajas, pero todas requieren algún nivel de adaptación y personalización para la situación que se está manejando. A través de los años, las organizaciones de infraestructura de TI han crecido y se han desarrollado, y es posible que después de un tiempo no reflejen una imagen exacta de todos los servicios actuales provistos o de los clientes de cada servicio. Para establecer una imagen precisa, es recomendable que se produzca y mantenga un portafolio de servicios de TI que contenga un Catálogo de Servicios para proveer un conjunto central preciso de información de todos los servicios, y para desarrollar una cultura enfocada en el servicio. El catálogo de servicios proporciona valor al negocio como fuente central de información de los servicios de TI entregados por la organización proveedora de servicios. Esto asegura que todas las áreas del negocio puedan ver una imagen precisa y consistente de los servicios de TI, sus detalles y su estado. Contiene el punto de vista del cliente para los servicios de TI en uso, la forma en que se usan, los procesos de negocio que habilitan y los niveles y la calidad del servicio que el cliente puede esperar de cada servicio. La gestión del catálogo de servicios incluye: Definición del servicio. Producción y mantenimiento de un catálogo de servicios preciso. Interfaces, dependencias y consistencia entre el catálogo de servicios y el portafolio de servicios. Interfaces y dependencias entre todos los servicios y los servicios soportados dentro del catálogo de servicios y el sistema de gestión de la configuración (CMS). Interfaces y dependencias entre todos los servicios, los componentes soportados y los Ítems de configuración (CI) dentro del catálogo de servicios y el CMS. El catálogo de servicios tiene dos aspectos: El catálogo de servicios del negocio: Es la vista del cliente del catálogo de servicios. El catálogo de servicios técnicos: Debe apuntar al catálogo de servicios del negocio y no formar parte de la vista del cliente. BO NI A LA OM R VINCIT Página 53 de 134 ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI - Gestión del nivel de servicio: La gestión de nivel de servicio (SLM) negocia, acuerda y documenta apropiadamente los servicios de TI con representantes del negocio. Además, visualiza y genera información de la habilidad del proveedor de servicios para entregar los niveles de servicio acordados. Los acuerdos de nivel de servicio (SLA) brindan un nivel de aseguramiento, o garantizan el cuidado del nivel de calidad de los servicios entregados por el proveedor al negocio. El éxito de la gestión de niveles de servicio (SLM) es muy dependiente de la calidad del portafolio de servicios, del catálogo de servicios y sus contenidos, porque ellos proporcionan la información necesaria para que los servicios sean administrados dentro del proceso de gestión de niveles de servicio. Los objetivos de la gestión de niveles de servicio SLM, son: Definir, documentar, acordar, visualizar, medir, reportar y revisar el nivel de los servicios de TI proporcionados. Proveer y mejorar las relaciones y comunicaciones con el negocio y los clientes. Asegurar objetivos específicos y medibles, que sean desarrollados para todos los servicios de TI. Visualizar y mejorar la satisfacción del cliente con la calidad del servicio entregado. Asegurar que TI y los clientes tengan expectativas claras, sin ambigüedad del nivel de servicio que va a ser entregado. Asegurar que sean implementadas medidas proactivas para mejorar los niveles de servicio entregados, siempre y cuando sus costos sean justificables. Hay varios tipos de SLA, incluyendo los siguientes: SLA basado en el servicio: En este caso un SLA cubre un servicio para todos los clientes. SLA basado en el cliente: Es un acuerdo con un grupo individual de clientes para cubrir todos los servicios que éstos usan. SLA multinivel: Algunas organizaciones han adoptado una estructura de SLA multinivel, es decir una estructura de varias capas de niveles. La redacción de los SLA debe ser clara y concisa sin dar lugar a ambigüedades. Comúnmente es de gran ayuda tener a una persona independiente, que no esté envuelta en la redacción, para que haga una lectura final. A BO LA NI Página 54 de 134 OM R Es recomendable que el SLA contenga un glosario, donde se definan todos los términos y se proporcione claridad en cualquier área de ambigüedad. VINCIT ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI - Gestión de la capacidad: La gestión de la capacidad es un proceso que se extiende a través del ciclo de vida del servicio. Un factor clave de éxito en la gestión de la capacidad es asegurar que sea considerado dentro de la etapa de diseño del servicio. La gestión de la capacidad es soportada inicialmente en la estrategia del servicio, donde las decisiones y el análisis de los requerimientos del negocio y los clientes, influencian el desarrollo de Patrones de Actividad del Negocio (PBA), Niveles de Servicio (LOS) y Paquetes de Nivel de Servicio (SLP). La gestión de la capacidad asegura que la capacidad y el desempeño de los servicios de TI y los sistemas coinciden con la demanda acordada con el negocio, con costos efectivos y puntualidad. Consiste esencialmente, en: Balancear los costos contra los recursos necesarios. Balancear el suministro contra la demanda. Los objetivos de la gestión de capacidad, son: - Producir y mantener un plan de capacidad apropiado y actualizado, que refleje las necesidades actuales y futuras del negocio. - Aconsejar y guiar a todas las demás áreas del negocio y a TI sobre todos los aspectos relacionados con la capacidad y el desempeño. - Asegurar que el desempeño del servicio coincida o supere los objetivos esperados, por medio de la gestión de desempeño y capacidad de los servicios y los recursos. - Asistir con el diagnóstico y la solución de incidentes, problemas relacionados con el desempeño y la capacidad. - Evaluar el impacto de todos los cambios en el plan de capacidad y el desempeño. - Asegurar que se implementen medidas proactivas para mejorar el desempeño de los servicios siempre y cuando tengan un costo razonable. - Gestión de la disponibilidad: La gestión de la disponibilidad es la ventana de la calidad del servicio al cliente del negocio. Un proveedor de servicios que no aplica esta sólida práctica y que no puede ofrecer estabilidad y confiabilidad del servicio nunca tendrá la lealtad de sus clientes. Los objetivos de la gestión de la disponibilidad (AM), son: Producir, mantener y actualizar un plan de disponibilidad adecuado que refleje las necesidades actuales y futuras del negocio. - Proporcionar consejo y guía a las demás áreas del negocio y a TI en los temas relacionados con la disponibilidad. A BO LA NI Página 55 de 134 OM R - VINCIT ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI - Asegurar que los logros de disponibilidad alcancen o excedan los objetivos acordados, por medio de la gestión del rendimiento disponible de los servicios y recursos. - Asistir con el diagnóstico y resolución de incidentes y problemas relacionados con la disponibilidad. - Evaluar el impacto de todos los cambios en el plan de disponibilidad, el desempeño y la capacidad de todos los servicios y recursos. - Asegurar que sean implementadas medidas proactivas para mejorar disponibilidad de los servicios siempre y cuando sus costos se justifiquen. la La gestión de la disponibilidad debe buscar continuamente cómo optimizar y mejorar proactivamente la disponibilidad de la infraestructura de TI, los servicios y la organización de soporte, para conseguir mejoras en la disponibilidad, con costos efectivos, que puedan entregar beneficios al cliente y al negocio. La gestión de la disponibilidad debe trabajar estrechamente con la gestión de incidentes y la gestión de problemas, en el análisis de todos los incidentes que causan falta de disponibilidad. - Gestión de la continuidad de los servicios de TI: La gestión de la continuidad del servicio de TI es la parte de la práctica de ITIL que evalúa el nivel de aseguramiento necesario para proteger los activos del servicio y tiene los pasos a seguir para recuperarlos ante un desastre. El objetivo de la gestión de la continuidad del servicio de TI (ITSCM) es soportar el proceso completo de gestión de la continuidad del negocio, asegurando que las instalaciones y técnicos de TI (incluyendo sistemas de computadoras, redes, aplicaciones, repositorios de datos, telecomunicaciones, ambiente, soporte técnico y mesa de servicios) puedan ser restablecidos dentro de las escalas de tiempo requeridas y acordadas. Los objetivos de la ITSCM, son: Mantener un conjunto de planes de continuidad del servicio de TI y planes de recuperación que soporten todos los planes de continuidad del negocio (BCP). - Completar el análisis de impacto del negocio (BIA) regularmente, para asegurar que todos los planes de continuidad son mantenidos en línea con los requerimientos, impacto y cambios del negocio. - Conducir evaluaciones de riesgo periódicas y ejercicios de gestión, en conjunto con el negocio, los procesos de gestión de la disponibilidad y los procesos de gestión de la seguridad. - Aconsejar y guiar a las demás áreas del negocio y de TI en todos los aspectos relacionados con continuidad y recuperación. - Garantizar que son puestos en marcha los mecanismos apropiados de continuidad y recuperación, para asegurar que los objetivos de continuidad acordados con el negocio son alcanzados o superados. A BO LA NI Página 56 de 134 OM R - VINCIT ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI - Evaluar el impacto de todos los cambios en los planes de continuidad y los planes de recuperación de TI. - Asegurar que se implementen medidas proactivas para mejorar la disponibilidad de los servicios siempre y cuando su costo sea justificable. - Negociar y acordar los contratos necesarios con los proveedores para que se suministre la capacidad necesaria de recuperación, y poder soportar así todos los planes de continuidad en conjunto con el proceso de gestión de proveedores. La continuidad del servicio es implementada y gestionada en cuatro etapas: 1. Iniciación: establecimiento de políticas, definición de alcance y términos de referencia, planeación de proyectos y asignación de recursos. 2. Requerimientos y estrategia: análisis del impacto en el negocio y evaluación del riesgo. 3. Implementación: ejecución de las medidas de reducción de riesgos, organización de las opciones de recuperación y prueba de los planes. 4. Operación futura: control de cambios de los planes de ITSCM, pruebas futuras. Un buen lugar para comenzar a evaluar las amenazas y riesgos son las funciones vitales del negocio. Las evaluaciones se deben realizar constantemente para asegurar que todos los cambios en los servicios o requerimientos del negocio, no afectan a la habilidad de los procesos de ITSCM para ser efectivos cuando sea necesario. - Gestión de la seguridad de la información: Las organizaciones crean valor a través de la propiedad intelectual que poseen y la usan para entregar productos y servicios. La protección del capital intelectual es una necesidad primaria del negocio y es cada vez más regulada por la ley. La tecnología hoy ofrece un potencial ilimitado para crear, reunir y acumular gran cantidad de información. Un proveedor de servicios es responsable de garantizar que la información del negocio está protegida de intrusiones, robos, pérdidas y accesos no autorizados. El propósito de la gestión de la seguridad de la información es proveer un enfoque para todos los aspectos de seguridad de TI y gestión de todas las actividades de seguridad de TI. BO NI A LA OM R La palabra información es usada como un término general que incluye almacenes de datos, bases de datos y meta datos. El objetivo de la seguridad de la información es proteger los intereses de aquellos que se apoyan en la información, los sistemas y las comunicaciones, de los resultados perjudiciales que provocan las fallas de disponibilidad, confidencialidad e integridad. VINCIT Página 57 de 134 ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI Para la mayoría de las organizaciones los objetivos de seguridad son alcanzados cuando: - La información es disponible y usable en el momento en que se requiere y los sistemas que la proveen pueden resistir apropiadamente a ataques y facilitan la recuperación o prevención de fallas (Disponibilidad). - La información es observada sólo por quienes tienen derecho a conocerla (Confidencialidad). - La información está completa, precisa y protegida contra modificaciones no autorizadas (Integridad). - Las transacciones del negocio, como los intercambios de información entre empresas o socios pueden ser de confianza (Autenticidad). La priorización de la confidencialidad, integridad y disponibilidad debe ser considerada en el contexto del negocio y de los procesos del negocio. La selección de medidas para el control de las amenazas depende de la importancia asignada a la información: Preventivas: las medidas de seguridad son usadas para prevenir la ocurrencia de incidentes de seguridad. Por ejemplo, la asignación de derechos de escritura a un grupo limitado de gente autorizada. - Reductivas: las medidas pueden ser tomadas para minimizar cualquier posible daño que pueda ocurrir, por ejemplo, la realización de backups regulares y el desarrollo, prueba y mantenimiento de planes de contingencia. - Detectivas: si los incidentes de seguridad ocurren, es importante descubrirlos tan pronto sea posible, por ejemplo, monitorear y asociar alertas a los procedimientos; otro ejemplo son los antivirus. - Represivas: las medidas son usadas para contrarrestar cualquier continuación o repetición de los incidentes de seguridad, por ejemplo, una cuenta o dirección de red es bloqueada después de varios intentos fallidos de registro. - Correctivas: los daños son reparados tan pronto como sea posible usando medidas correctivas, por ejemplo, la restauración del backup o volver a una situación previa de estabilidad (roll-back, back-out). BO NI A LA OM R - VINCIT Página 58 de 134 ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI 2.3.3.3 Transición del servicio La transición del servicio constituye la tercera etapa del ciclo de vida del servicio de ITIL, y es la encargada de vigilar y mejorar el conjunto de servicios que son ejecutados desde la fase de diseño del servicio. Para una exitosa implementación de la transición, se requiere del uso de la planificación, buscando siempre lograr los objetivos esperados en la ejecución. La transición del servicio satisface un conjunto de propósitos para cubrir de manera exitosa toda la gestión de los servicios en los negocios. Dichos propósitos consisten en: Planificar y gestionar la capacidad de los recursos requeridos. - Proveer un consistente y riguroso framework para evaluar la capacidad del servicio y el perfil del riesgo, antes de desplegar y liberar un nuevo servicio o uno que se encuentra en cambio. - Proveer conocimiento e información de calidad en la gestión de cambios, liberación y despliegue, de modo que puedan tomar decisiones efectivas en la liberación de los servicios. - Repetir los mecanismos de construcción e instalación que puedan ser usados para desplegar liberaciones en el ambiente de producción y prueba, además ser reconstruidos, si es requerido para un servicio de restaure. - Garantizar que los servicios pueden ser administrados, operados y soportados en concordancia con los requerimientos y las constantes específicas dentro de la etapa de diseño del servicio. BO NI A LA OM R - VINCIT Página 59 de 134 ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI De la misma manera, posee una serie de conceptos claves que contienen el conjunto de mejores prácticas para tener una eficiente gestión de los servicios de TI. Los conceptos son: Planificación de la transición, gestión del activo y configuración, gestión de la liberación y despliegue, gestión de cambios, validación y pruebas. Una efectiva transición del servicio puede mejorar significativamente la habilidad de los proveedores de servicio en la generación de altos volúmenes de cambio y liberación en los clientes. A continuación, se detallan los conceptos fundamentales de la transición del servicio: - Planificación y soporte de la transición: La estrategia de la transición del servicio define un enfoque en forma general para organizar la transición del servicio y localizar los recursos. Los aspectos a considerar, son: Propósitos, metas y objetivos de la transición del servicio. - El contexto. (Por ejemplo: El servicio al cliente, los portafolios contratados) - El alcance, las inclusiones y exclusiones. - Los estándares de aplicación, los acuerdos legales, regulatorios y los requerimientos contractuales. - Las organizaciones y los socios contenidos en la transición. - Framework para la transición del servicio. - El criterio. - Identificación de requerimientos y contenidos de los nuevos servicios o de aquellos que están siendo cambiados. - Las personas. - El enfoque. - Entregas desde las actividades de la transición incluyendo la documentación de cada etapa del ciclo de vida. - Planificación del hito. - Requerimientos financieros, presupuestos y financiación. BO NI A LA OM R - VINCIT Página 60 de 134 ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI Para verificar la calidad de los planes, la revisión deberá hacerse por anticipado a la liberación o despliegue de los servicios. Por lo tanto, el planificador debe indagar sobre el comportamiento general de los planes y características principales, haciéndose, entre otras, las siguientes preguntas: - ¿Son estos los planes de transición del servicio y liberación actuales? - ¿En los planes acordados y autorizados interactúan partes relevantes, es decir, el personal de soporte, de operaciones, los usuarios o los clientes? - ¿Los planes incluyen las fechas de liberación, las entregas y referencias para los cambios de requisitos, los errores conocidos y los problemas? - ¿Los planes tienen impacto en los aspectos de costos, organizacionales, técnicos y comerciales que han sido considerados? - ¿Los riesgos en los servicios generales y las operaciones de capacidad han sido evaluados? - ¿Qué circunstancias de cambio son necesarias para un enfoque de reforma? - ¿Qué reglas y guías de aplicación son relevantes para el servicio actual? - ¿Qué personas necesitan usar y tener el entendimiento de las habilidades de los requisitos en uso? - ¿Los cambios potenciales han sido identificados en las circunstancias del negocio? Con las respuestas a las preguntas anteriores se obtiene una revisión general específica sobre la calidad y la veracidad de los planes. En conclusión, la transición propia de la planificación y el soporte reducirían la necesidad de las medidas correctivas durante y después de la liberación en la operación en vivo. - Gestión del cambio: El propósito de los procesos de gestión del cambio es asegurar que los métodos y procedimientos estándares sean usados para el manejo eficiente y pleno de todos los cambios. Las metas de la gestión de cambios son: Responder a los clientes en los requerimientos de cambio del negocio para minimizar y reducir los incidentes y las interrupciones. - Responder al negocio y a TI, acerca de cuáles de los cambios en los servicios se alinearían con las necesidades del negocio. BO NI A LA OM R - VINCIT Página 61 de 134 ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI Las siete R’s de la gestión del cambio: Para una evaluación general de gestión de cambios, deberán ser respondidas las siguientes preguntas para visualizar el impacto de los cambios ejecutados dentro de la organización. Se llama las siete R’s de la gestión del cambio, porque las 7 preguntas contienen 7 palabras en idioma inglés donde su primera letra es R. En español el léxico de las palabras es distinto en algunos casos, sin embargo, el título es válido, debido a que ITIL es un marco de trabajo británico. Las preguntas son: o ¿Quién plantea el cambio? o ¿Cuál es la razón para el cambio? o ¿Cuál es el retorno requerido del cambio? o ¿Cuáles son los riesgos que contiene el cambio? o ¿Cuáles recursos son requeridos para entregar los cambios? o ¿Quién es el responsable de la construcción, pruebas e implementación del cambio? o ¿Cuál es la relación entre este cambio y otros cambios? Las solicitudes para cambios (RFC) son claves como fuentes de información sobre los cambios. Además, catalizan las actividades de los cambios, los revisan, los evalúan, los autorizan, los planean, los coordinan y los cierran en el momento necesario. Los tres modelos de cambio básicos son incluidos en la transición del servicio, y pueden ser adaptados para satisfacer las circunstancias organizacionales individuales y aquellas que son requeridas: Modelo de cambio estándar: Modelo usado para cambios pre autorizados de forma repetitiva, posee bajo riesgo. Este modelo a menudo es utilizado para los cambios de mantenimiento operacional de los servicios. - Modelo normal de cambio: El modelo completo para los cambios, que debe ir a través de la evaluación, autorización y el acuerdo con la tabla de anuncios de cambios CAB (tabla que contiene los avisos de cambios de los negocios, utilizada para soportar la autorización de los cambios y asistir a la gestión del cambio en la evaluación y priorización de los cambios) - Modelo de emergencia de cambio: Es un modelo reservado sólo para cambios de alto nivel crítico, requerido para restaurar las fallas de disponibilidad o fallas en los servicios de gran cobertura, que previene la falla que ocurre de forma inherente. BO NI A LA OM R - VINCIT Página 62 de 134 ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI - Gestión de activos y configuración: Los servicios son sistemas con niveles de interdependencia, en los cuales hay activos de servicio que tienen configuraciones específicas sobre las funciones claves de desempeño y los servicios de entrega. La falta de organización es la causa principal de la no eficiencia y efectividad de la gestión de los activos de la empresa, y se complica más, cuando los procesos de gestión de los activos del servicio soportan otros procesos de gestión del servicio. La meta es, por tanto, obtener una optimización del desempeño de los activos del servicio y de las configuraciones, con el fin de mejorar la eficiencia general del servicio, los costos y los riesgos que se generaría de una gestión de activos pobre. Los ítems de configuración: Un ítem de configuración (CI) es un activo, componente de servicio u otro ítem, el cual es o será puesto bajo control de la gestión de la configuración. Los CI’s pueden variar profundamente en complejidad, tamaño y tipo, y deben ser seleccionados usando el criterio de aceptación establecido. A continuación se muestra una variedad de CI’s, siguiendo las categorías que pueden ayudar a identificarlos. CI’s del ciclo de vida del servicio: Como los “Business Case”, los planes de gestión de servicios, los planes del ciclo de vida del servicio, el paquete de diseño del servicio, los planes de liberación y cambios, o los planes de pruebas. Son ítems que se preguntan sobre cómo serán entregados los servicios, qué beneficios serán los esperados, con qué costos y en qué periodo de tiempo. - Los CI’s del servicio: Son un conjunto de ítems basados en la gestión de servicios. - La organización de los CI’s: Los requerimientos regulatorios o de estatus también forman productos externos que requieren ser establecidos como partes de productos entre más de un grupo. - CI’s internos: Comprenden aquellos ítems que son entregados por proyectos individuales sobre los activos tangibles (centro de datos) y los activos intangibles, tales como el software que es requerido para entregar y mantener el servicio y la infraestructura. - CI’s externos: Son aquellos ítems que contienen los requerimientos externos del cliente, los acuerdos o los servicios de externos. - Interfaz de CI’s: La interfaz es requerida para la entrega final de los servicios a través de la interfaz del proveedor del servicio (SPI). BO NI A LA OM R - VINCIT Página 63 de 134 ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI - Gestión de liberación y despliegue: Las prácticas efectivas de la gestión de liberación y despliegue le permiten al proveedor de servicio generar un valor agregado al negocio por medio de la entrega del cambio con velocidad, menores costos y minimización del riesgo: El objetivo de la gestión de la liberación y despliegue es garantizar que: - Hay planes claros y coherentes de liberación y despliegue que permiten al cliente y al negocio cambiar los proyectos para alinear sus actividades con estos planes. - Un paquete de liberación sea construido, instalado, probado y desplegado eficientemente para un despliegue en grupo o un ambiente objetivo. - Un servicio nuevo o cambiado, los sistemas, la tecnología y la organización, son capaces de entregar los requerimientos de los acuerdos de servicio. - Las habilidades y el conocimiento son transferidos, además de soportados y mantenidos de acuerdo con las garantías requeridas y los niveles de servicio. - Hay un mínimo impacto en la producción de los servicios, las operaciones y el soporte de la organización. - Los clientes, los usuarios y el personal de la gestión del servicio están satisfechos con las prácticas y resultados de la transición del servicio. BO NI A LA OM R El objetivo general de la gestión de liberación y despliegue, es decidir el paquete de liberación más apropiado en cuanto al nivel de unidad de las liberaciones sobre cada activo o componente del servicio. VINCIT Página 64 de 134 ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI 2.3.3.4 Operación del servicio Los procesos bien planteados e implementados no serán provechosos si la operación diaria de estos no es conducida, controlada y gestionada apropiadamente. El propósito de la operación del servicio es coordinar y llevar a cabo las actividades y procesos requeridos para entregar y gestionar servicios en los niveles acordados con los usuarios del negocio y clientes. Es también responsable de la gestión futura de tecnología que es usada para entregar y soportar los servicios. - Gestión de eventos: Un evento constituye cualquier ocurrencia detectable que tiene un significado para la gestión de la infraestructura de TI, la entrega del servicio de TI o la evaluación del impacto sobre la desviación de los servicios. Los eventos son comúnmente notificaciones creadas por un servicio de TI, un ítem de configuración (CI) o una herramienta de monitoreo. El proceso de gestión de eventos está compuesto por una serie de pasos a seguir que comienza desde la ocurrencia, estudio y notificación de un evento hasta el cierre del mismo. La gestión de eventos puede ser aplicada a cualquier aspecto de la gestión de servicios que necesita ser controlado y que puede ser automatizado, como: - Ítems de configuración: Algunos CI son incluidos porque necesitan permanecer en un estado constante: por ejemplo, un switch en una red debe permanecer encendido. Otros CI deben ser incluidos porque su estado necesita cambiar frecuentemente y la gestión de eventos puede ser usada para automatizar estos. Por ejemplo, la actualización de un servidor de archivos. BO NI A Página 65 de 134 OM R Condiciones ambientales, por ejemplo detección de fuego y humo. LA - VINCIT ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI - Monitoreo de licencias de software para asegurar la utilización y distribución óptimas y bajo las leyes establecidas. - Seguridad: por ejemplo, detección de intrusos. - Rendimiento del servidor. - Gestión de incidentes: La gestión de incidentes incluye cualquier evento que interrumpa o que pueda interrumpir un servicio, como los eventos que son comunicados directamente por los usuarios, a través de la mesa de servicios, o mediante una interfaz entre la gestión de eventos y las herramientas de gestión de incidentes. Los incidentes también pueden ser reportados y/o registrados por el personal técnico. Muchos incidentes no son nuevos, es posible que estos ya hayan ocurrido y que se repitan otra vez, es por eso que muchas organizaciones encuentran útil predefinir modelos estándar de incidentes y aplicarlos a los incidentes apropiados cuando ocurran. Un modelo de incidente es una forma de predefinir los pasos que deben ser tomados para manejar un proceso que está tratando con un tipo particular de incidente, en una forma acordada. Las herramientas de soporte pueden ser usadas para gestionar el proceso requerido, esto asegurará que los incidentes estándar sean manejados en una forma predefinida y dentro de unas escalas de tiempo dadas. El modelo de incidentes debe incluir: Los pasos que deben ser tomados para manejar los incidentes y el orden cronológico en el que estos pasos deben ser tomados, con cualquier dependencia o co-proceso definido. El proceso de gestión de incidentes consiste en un conjunto de pasos que deben ser seguidos por la organización para que se haga una gestión efectiva de incidentes, estos pasos se detallan a continuación: Registro del incidente: Todos los incidentes deben ser completamente registrados con la fecha y hora, ya sea que provengan de una llamada telefónica a la mesa de servicios o sean detectados automáticamente por medio de una alerta de evento. - Categorización del incidente: Debe ubicar adecuadamente el incidente en una categoría dada, para que el tipo exacto de llamado sea atendido. Es importante que después se busquen tendencias de incidentes por tipo y frecuencia, para usarlas en la gestión de problemas, de proveedores y de otras actividades del sistema de gestión de TI. - Priorización de incidentes: La priorización puede ser normalmente determinada tomando en cuenta la urgencia del incidente. Frecuentemente puede ser medida por el número de usuarios afectados, sin embargo algunas veces la pérdida del servicio de un solo usuario puede tener mayor impacto en el negocio. - Diagnóstico inicial: Si el incidente ha sido enrutado por la mesa de servicios, el analista de la mesa de servicios debe llevar a cabo un diagnóstico inicial, tratando de identificar todos los síntomas del incidente y determinando exactamente qué está mal y cómo corregirlo. Es en esta etapa que los scripts de diagnóstico y la información de errores conocidos puede ser más valiosa, permitiendo un diagnóstico temprano y exacto. BO NI A LA OM Página 66 de 134 R - VINCIT ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI - - Escalado del incidente: o Escalado funcional: Tan pronto la mesa de servicios se da cuenta que no está capacitada para resolver el incidente por sí misma, o cuando los tiempos objetivos por resolución del primer punto han sido excedidos, el incidente debe ser escalado inmediatamente. o Escalado jerárquico: Si el incidente es de naturaleza grave, los administradores de TI deberán ser notificados para que tengan el conocimiento sobre lo que está sucediendo. Este tipo de escalado es también usado si los pasos de “investigación y diagnóstico” y “resolución y recuperación” toman mucho tiempo o presentan mucha dificultad. El escalado jerárquico debe continuar ascendiendo por la cadena de gestión hasta que los altos directivos sean conscientes y puedan estar preparados y tomar las acciones necesarias, como asignar recursos adicionales o involucrar a los proveedores. Investigación y diagnóstico: Incluye varias actividades que dependen del tipo de incidente, pero siempre deben realizarse las listadas a continuación: Establecer exactamente qué está mal. Comprender el orden cronológico de los eventos. Confirmar el impacto completo del incidente, incluyendo el número y rango de usuarios afectados. Identificar cualquier evento que pueda ser disparado por el incidente. Consultar incidentes o problemas previos grabados y/o bases de datos de errores conocidos, o registro de errores de fabricantes, proveedores o bases de conocimiento. - Resolución y recuperación: Cuando una solución potencial ha sido identificada debe ser aplicada y probada. Las acciones especificas que van a ser tomadas y la gente que estará implicada en la toma de acciones de recuperación puede variar, dependiendo de la naturaleza de la falla. - Cierre del incidente: La mesa de servicios debe verificar que el incidente está completamente resuelto, que los usuarios están satisfechos y que están de acuerdo con que el incidente sea cerrado. La mesa de servicios debe también verificar: Cierre de la categorización: Verificar y confirmar que el incidente inicial fue categorizado correctamente. o Revisión de la satisfacción del usuario: Llevar a cabo una llamada o una revisión por correo para un porcentaje acordado de incidentes. o Documentación del incidente: Perseguir cualquier detalle excepcional y asegurar que el incidente ha sido completamente documentado y que se ha almacenado correctamente, para tener un registro histórico completo con un nivel de detalle suficiente. o Problemas recurrentes o futuros: Determinar en conjunto con los grupos de resolución si el incidente puede volver a ocurrir y decidir si alguna acción preventiva es necesaria para evitarlo.. o Cierre formal: Cerrar formalmente el registro del incidente. BO NI A LA OM R o VINCIT Página 67 de 134 ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI - Gestión de problemas: ITIL define un “problema” como la causa desconocida de uno o más incidentes. La gestión de problemas es el proceso responsable de todos los problemas de gestión dentro del ciclo de vida. Los objetivos principales de la gestión de incidentes son prevenir problemas e incidentes resultantes de la ocurrencia de estos para eliminar incidentes recurrentes y minimizar el impacto de incidentes que no pueden ser prevenidos. Este proceso de gestión de problemas es descrito a continuación desde que el problema es identificado hasta que es cerrado: 1. Detección del problema 2. Registro del problema 3. Categorización del problema 4. Priorización del problema 5. Investigación y diagnóstico de problemas 6. Solución 7. Construcción de un registro de errores conocidos 8. Solución de problemas 9. Cierre del problema 10. Revisión del problema principal 11. Errores detectados en el ambiente de desarrollo - Gestión de acceso: La gestión de acceso es el proceso en el que se garantiza que los usuarios autorizados tengan derecho a usar el servicio, mientras se previene el acceso a los no autorizados. La gestión de acceso ejecuta la gestión de disponibilidad y seguridad de la información, permitiendo manejar la confidencialidad, disponibilidad, integridad de los datos y propiedad intelectual de la organización. La gestión de acceso asegura que un usuario tenga los permisos correctos para usar un servicio, pero no asegura que este acceso esté disponible todo el tiempo acordado (esto es responsabilidad de la gestión de disponibilidad). Es un proceso que es ejecutado por todas las funciones de gestión de aplicaciones y por los técnicos. Puede ser iniciada por una solicitud de servicio a través de la mesa de servicio. Para facilitar que la gestión de acceso proporcione los permisos adecuados, se utiliza un catálogo con todos los roles y servicios que soporta cada uno en la organización. Este catálogo de roles debe ser recopilado y mantenido por la gestión de acceso en conjunto con recursos humanos, y comúnmente es automatizado en las herramientas de directorio de servicios. A BO LA NI Página 68 de 134 OM R Dentro de la gestión de acceso es recomendable seguir el siguiente flujo: Solicitar el acceso, verificar, proporcionar permisos, monitorear el estado de identidad, registrar y rastrear el acceso, y eliminar o restringir permisos. VINCIT ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI - Funciones de la operación del servicio: Monitoreo y control Este ciclo es fundamental para la entrega, soporte y mejora de servicios. Es también importante mencionar que aunque este ciclo tiene lugar durante la operación del servicio, proporciona una base para establecer las estrategias, diseñar, probar servicios y alcanzar una mejora significativa. Los ciclos de monitoreo y control pueden ser usados para gestionar: - El rendimiento de actividades en un proceso o procedimiento: Cada actividad y sus resultados pueden ser potencialmente medidos para asegurar que los problemas con el proceso se han identificado, antes de que este sea completado. Por ejemplo, en la gestión de incidentes, la mesa de servicios monitorea si un equipo técnico ha aceptado un incidente en un tiempo específico. De lo contrario, el incidente es escalado. - Efectividad de un proceso o un procedimiento como un todo: En este caso, las actividades representan el proceso completo como una entidad simple. Por ejemplo, la gestión de cambios mide el éxito del proceso verificando si un cambio fue implementado a tiempo, de acuerdo con las especificaciones y dentro del presupuesto. - Rendimiento de un dispositivo: Por ejemplo, el tiempo de respuesta de un servidor bajo una carga de trabajo dada. - Rendimiento de una serie de dispositivos: Por ejemplo, el tiempo de respuesta del usuario final de una aplicación a través de la red. Mesa de servicios La mesa de servicios es una parte vital del departamento de TI de la organización y debe ser el único punto de contacto para los usuarios de TI. Además debe manejar todos los incidentes y solicitudes de servicios, usualmente utilizando herramientas de software especializadas para registrar y gestionar los eventos. El valor de una mesa de servicios efectiva no debe ser subestimado, una buena mesa de servicios puede compensar las deficiencias de la organización de TI, pero una mesa de servicios mala, o la falta de esta, puede dar una pobre impresión de una organización de TI. Por lo tanto, es muy importante que el personal adecuado sea usado en la mesa de servicios y que los gerentes de TI hagan el mejor esfuerzo para hacer la mesa de servicios un lugar atractivo para trabajar, todo para mejorar el rendimiento del personal. BO NI A LA OM R El objetivo principal de la mesa de servicios es restaurar los servicios a su operación normal para los usuarios, tan rápido como sea posible. Puede ser reparar una falla técnica, o puede involucrar el cumplimiento de una solicitud de servicio o la solución a una pregunta, cualquier cosa que sea necesaria para permitir al usuario retornar a su trabajo satisfactoriamente. VINCIT Página 69 de 134 ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI - Gestión de operaciones de TI: Las operaciones de TI pueden ser definidas como un conjunto de actividades, contenidas en el día a día de la infraestructura de TI, con el propósito de entregar servicios de TI en los niveles de servicio acordados para alcanzar los objetivos de negocio establecidos. El rol de la gestión de operaciones de TI es ejecutar las actividades y procedimientos requeridos para gestionar y mantener la infraestructura de TI, y entregar soporte a los servicios de TI en los niveles acordados. Los objetivos de la gestión de operaciones de TI, son: - Mantener el status quo para alcanzar estabilidad en los procesos y actividades de la organización diariamente. - Escrutinio regular y mejoras para alcanzar servicios mejorados a bajos costos y manteniendo la estabilidad. - Rápida aplicación de las habilidades operacionales para diagnosticar y resolver cualquier falla en la operación de TI. - Gestión de aplicaciones: La gestión de aplicaciones es responsable de la administración de las aplicaciones a través del ciclo de vida. Esta función es desempeñada por cualquier departamento, grupo o equipo contenido en la gestión y soporte de aplicaciones operacionales. Juega un importante papel en el diseño, pruebas y mejora de las aplicaciones que forman parte de los servicios de TI. Por esta razón puede estar involucrada en los proyectos de desarrollo, pero no equivale usualmente a los equipos de desarrollo de aplicaciones. - Operación de servicios y gestión de proyectos: Utilizando la gestión de proyectos para administrar actividades como la actualización de la infraestructura principal, el desarrollo de nuevos procedimientos o de cambios en los mismos, se pueden obtener los siguientes beneficios: Hay más visibilidad de qué se está haciendo y cómo se está haciendo, lo que facilita que otros grupos de TI y del negocio cuantifiquen las contribuciones realizadas por los equipos operativos. - Hace más fácil obtener recursos para los proyectos, cuyos costos tradicionalmente son difíciles de justificar. - Mayor consistencia y calidad mejorada. - Alcance de los objetivos, resultando en alta credibilidad para los equipos operativos. BO NI A LA OM R - VINCIT Página 70 de 134 ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI 2.3.3.5 Mejora continua del servicio La mejora continua del servicio (CSI) provee una guía práctica en la evaluación y el aumento de la calidad de los servicios, especialmente sobre los servicios de maduración de la gestión durante el ciclo de vida y los procesos. En la organización hay tres niveles donde se aplica CSI, la gestión de servicios de TI en general, el alineamiento continuo del portafolio de servicios de TI con las necesidades actuales y futuras del negocio, y la madurez de los procesos de TI requeridos para soportar los procesos de negocio. El propósito principal de CSI es alinear continuamente los servicios de TI para actualizar y cambiar las necesidades del negocio, identificando e implementando las mejoras para los servicios de TI que soportan dichos procesos. Estas mejoras en las actividades de soporte están enfocadas a todo el ciclo de vida del servicio de TI. El proceso de mejora puede ser resumido en seis pasos: 1. Comprender la visión bajo el entendimiento de los objetivos del negocio de alto nivel. La visión debe alinear el negocio con las estrategias de TI. 2. Evaluar la situación actual para obtener una visión exacta, imparcial e instantánea de la organización. Esta evaluación es la línea base del negocio, la organización, el personal, los procesos y la tecnología. 3. Entender y acordar las prioridades de mejora basadas en el profundo desarrollo de los principios definidos en la visión. A BO LA NI Página 71 de 134 OM R 4. Detallar el plan CSI para lograr servicios altos de calidad de provisión por la implementación de los procesos del ciclo de vida de gestión del servicio (ITSM). VINCIT ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI 5. Verificar que las medidas y las métricas estén actualizadas para garantizar que los hitos fueron logrados, que el proceso de cumplimiento es alto, y que los objetivos y las prioridades fueron encontradas por el nivel de servicios. 6. Finalmente, el proceso debe asegurar que la mejora de la calidad se haga mediante la evaluación de los cambios que vienen embebidos en la organización. Hay 4 términos usados comúnmente en la discusión de los resultados de la mejora del servicio, son: - Mejoras: Son los resultados que se comparan con el estado actual, muestran el aumento de las medidas sobre la métrica deseada o sobre la disminución de la métrica no deseada. Beneficios: Son las ganancias logradas a través de la realización de las mejoras, usualmente pero no siempre, son expresadas en términos monetarios. - Retorno de la inversión (ROI): La diferencia entre el beneficio logrado y la cantidad gastada para lograr que el beneficio esté expresado como un porcentaje. Lógicamente, uno debe gastar menos para ganar más. - Valor de la inversión (VOI): El valor extra creado para el establecimiento de los beneficios que incluyen los resultados no monetarios o de largo plazo. El ROI es un subcomponente del VOI. BO NI A LA OM R - VINCIT Página 72 de 134 ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI 3. METODOLOGÍAS DE GESTIÓN PMI 3.1 Definición El Project Management Institute (PMI) es una asociación de profesionales que practican la gerencia de proyectos como su profesión, y se dedica a: - Producir Estándares y otras publicaciones de Gerencia de Proyectos. - Proveer Educación en Gerencia de Proyectos. - Ofrecer oportunidades de Certificación. - Facilitar oportunidades de intercambio profesional. El Project Management Institute (PMI) está considerada la asociación profesional sin ánimo de lucro para la gestión de proyectos más grande del mundo, con más de 260.000 miembros en 171 países. Fue fundado a mediados de 1969 en Estados Unidos por cinco voluntarios, y desde entonces se fueron incorporando más miembros en distintos países, y realizaron distintos eventos para difundir el mejor uso de la disciplina. Según PMI la clave del éxito en la ejecución de un proyecto radica en un alto porcentaje en la adecuada planificación que se haga de él. Y la planificación se basa, a su vez, en la adecuada definición del alcance, el cual será el punto de partida para el 90% del resto de la planificación de ese proyecto. El resto de las fases de la administración de proyectos están llevadas por la ejecución del producto de esa planificación, incluso hasta el cierre ordenado del mismo. 3.2 Introducción 3.2.1 Orígenes de PMI PMI fue fundada en 1969 sobre la premisa de que había muchas prácticas administrativas que eran comunes a los proyectos en áreas de aplicación tan diversas como la construcción y la farmacéutica. Para la época del Simposio/Seminario de Montreal en 1976, la idea de que tales prácticas comunes podrían estar documentadas como “estándares” empezó a ser discutida de manera muy amplia. Esto llevó a su vez a considerar a la administración de proyectos como una profesión a parte. Sin embargo no fue hasta 1981, cuando la Junta de Directores de PMI aprobó un proyecto para desarrollar los procedimientos y conceptos necesarios para darle soporte a la profesión de la administración de proyectos. La propuesta del proyecto sugirió tres áreas de enfoque: Las características distintivas de una práctica en ejercicio (ética). - El contenido y estructura del cuerpo de conocimiento de la profesión (estándares). - El reconocimiento de los logros profesionales (acreditación). A BO LA NI Página 73 de 134 OM R - VINCIT ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI El proyecto se dio a conocer con el nombre de ESA (Grupo Administrativo de Ética, Estándares y Acreditación). Sus resultados fueron publicados en agosto de 1983, en un artículo especial, e incluían: - Un código de Ética más un procedimiento disciplinario. - Una línea de base de estándares consistente en seis áreas de conocimiento principales: Administración del Alcance, Administración de Costos, Administración de la Calidad, Administración de los Recursos Humanos, y Administración de las Comunicaciones. - Pautas tanto para la acreditación (reconocimiento de la calidad de los programas ofrecidos por instituciones educativas) como para la certificación (reconocimiento de los individuos como Gerentes de Proyectos). Este artículo sirvió posteriormente como la base inicial de los programas de Acreditación y Certificación de PMI. En 1984 se certificaron los primeros profesionales basados en el ESA, y la Junta Directiva de PMI aprobó un segundo proyecto relacionado con estándares para “capturar el conocimiento aplicado en la administración de proyectos dentro del marco conceptual existente en ESA”. Se reclutaron seis comités para abordar cada una de las seis áreas de conocimiento identificadas. Adicionalmente, fue programado un taller de trabajo como parte del Seminario/Simposio anual de 1985. Como resultado de estos esfuerzos, un documento actualizado fue aprobado por la junta de directores de PMI y publicado en agosto de 1986. Adicionalmente a la expansión y reestructuración del material original, el documento revisado incluyó tres nuevas secciones: El Marco Conceptual de la Administración de Proyectos: Se añadió para cubrir las relaciones entre el proyecto y su ambiente externo, y entre la administración del proyecto y la administración general. La Administración de Riesgo: Es una nueva área de conocimiento incorporada para aportar una mayor información sobre la administración de riesgos. La Administración de contratos: Es una nueva área de conocimiento incorporada para aportar una mayor información sobre la administración de contratos. BO NI A LA OM R Posteriormente, una variedad de cambios editoriales y correcciones fueron incorporados en el material, y la Junta Directiva de PMI los aprobó en marzo de 1987. El manuscrito final fue publicado como un documento a parte titulado “El Cuerpo de Conocimientos de la Administración de Proyectos” en agosto de 1987. VINCIT Página 74 de 134 ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI 3.2.2 Características de PMI Como ya hemos dicho anteriormente, según PMI la clave del éxito en la ejecución de un proyecto radica en gran medida en la adecuada planificación que se haga de él. Al iniciar el proyecto se debe comunicar a las partes involucradas el inicio del mismo, de forma que quede claro el rol de cada uno. En lo referente al alcance, realmente el PMI insiste mucho en una buena definición. Pone mucho énfasis en el tiempo y los costos. Si quienes utilizan este enfoque venden servicios, esta última característica es fundamental, ya que el costo es un elemento clave de su oferta. No obstante, en muchos proyectos más sencillos el tiempo y los costos no son necesariamente elementos clave. A continuación, se realiza la enumeración de las áreas de actuación del PMI: - Fija los estándares profesionales en Administración de Proyectos por medio de su “Guía para el Cuerpo de Conocimiento en Administración de Proyectos” o “A Guide to the PMBOK”. - Es líder en desarrollo de nuevos estándares para la profesión a nivel global. - Desarrolla y opera el sistema de certificación en Administración de Proyectos más reconocido en el mundo en este momento: Project Management Professional (PMP). - Crea y administra SIGs (Special Interest Groups) en diversas subdisciplinas. - Centraliza diversas áreas de investigación en la profesión de Administración de Proyectos. - Publica el PM Network, revista profesional mensual de Administración de Proyectos, y el Project Management Journal, una edición de artículos profesionales en forma trimestral. - Organiza congresos globales de Administración de Proyectos. 3.2.3 Certificaciones de PMI El PMI ofrece las siguientes certificaciones: Project Management Professional (Profesional de Gerencia de Proyectos): PMP® Certified Associate in Project Management (Asociado Certificado en Gerencia de Proyectos): CAPM® Programa de certificación para OPM3® ProductSuite Certificación de individuos para dirigir programas BO NI A LA OM R La certificación de PMP® asegura a un profesional y a las empresas que los contratan, que tiene los conocimientos fundamentales para practicar la profesión de Gerencia de Proyectos, mejorando las comunicaciones de la organización o con empresas asociadas. VINCIT Página 75 de 134 ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI Los gerentes de proyecto son responsables de todos los aspectos del proyecto a lo largo de su ciclo de vida, y dirigen los equipos de trabajo que llevan a cabo las diferentes funciones del proyecto. Son capaces de demostrar el conocimiento suficiente y la experiencia en metodologías de gerencia de proyecto. La certificación de CAPM está dirigida a los integrantes del equipo de proyectos, practicantes de gerencia de proyectos con poca experiencia y a estudiantes de grado o de postgrado. En cambio, la certificación PMP está dirigida principalmente a gerentes de proyectos o practicantes de gerencia de proyectos que supervisen un grupo o equipo de trabajo y que tengan un mínimo de experiencia. Es necesario aclarar que un candidato a PMP no debe tener necesariamente el título de gerentes de proyecto. Un cargo de líder o coordinador de proyectos son ejemplos válidos si cumple con los requisitos de la certificación. Las empresas a nivel mundial, están solicitando cada vez más, que sus gerentes de proyectos estén certificados como PMP. BO NI A LA OM R En la siguiente tabla podemos observar los requerimientos mínimos para optar a la certificación PMP®: VINCIT Página 76 de 134 ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI En la siguiente tabla podemos observar los requerimientos mínimos para optar a la certificación CAPM®: 3.2.4 Estándares de PMI Dentro del PMI se incluyen los estándares que se citan a continuación: PMBOK: Es la norma de Gerencia de Proyectos principal del PMI, y ha sido aceptada dentro del conjunto de normas de la American National Standard. Estudiaremos este estándar en profundidad en el apartado 3.3 de este manual. OPM3: Modelo Organizativo de Madurez en Gerencia de Proyectos. Incluye un sistema de evaluación e implementación de mejoras en las metodologías de Gerencia de Proyectos. El objetivo de OPM3 es establecer un modelo para lograr que las empresas u organizaciones maduren en los procesos de Gerencia de Proyectos. El modelo incluye tres etapas que evolucionan continuamente: 1. Conocimiento del modelo. 2. Evaluación del nivel de madurez actual de la organización. 3. Implementación de procesos y prácticas para incrementar la madurez de la organización. Se debe establecer un proceso de mejora continuo, para alcanzar con cada ciclo, un nivel superior de madurez. WBS: Estándar para realizar Estructuras Desagregadas de Trabajo. PMCD: Marco referencial de competencias en Gerencia de Proyectos. A BO LA NI Página 77 de 134 OM R VINCIT ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI EVM: Estándar de Prácticas de Gestión del Valor Ganado. Gerencia de Portafolios de Proyectos: Para aquellas organizaciones que desean organizarse a nivel estratégico con este sistema de gerencia. La gerencia de portafolios de proyectos surge de la escasez de recursos en las empresas, que ha hecho necesaria la selección cuidadosa de proyectos, acorde a su estrategia corporativa, y desechando los que carecen de importancia o valor para la empresa. Gerencia de Programas (multi-proyectos con un fin común): Para aquellas organizaciones que desarrollan más programas que proyectos individuales. BO NI A LA OM R En el siguiente diagrama podemos observar el resultado del proceso de estandarización de la Gerencia de Proyectos en el PMI: VINCIT Página 78 de 134 ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI 3.3 Iniciación a PMBOK 3.3.1 Introducción El PMBOK es una colección de procesos y áreas de conocimiento generalmente aceptadas como las mejores prácticas dentro de la gestión de proyectos. Es un estándar reconocido internacionalmente, que provee los fundamentos de la gestión de proyectos que son aplicables a un amplio rango de proyectos, incluyendo construcción, software, ingeniería, etc. La guía PMBOK (Project Management Body Of Knowledge) es el estándar de gestión de proyectos del PMI (Project Managment Institute) y está acreditado por ANSI (American nacional Standards Institute). Como ya hemos comentado anteriormente, PMI es una organización que atiende a las necesidades relacionadas con la gestión de los proyectos de los profesionales de cualquier disciplina tanto ingeniería como sanitaria farmacéutica o tecnológica, mientras que ANSI es un organismo para la coordinación y el uso de estándares en los Estados Unidos. En 1987 PMI publicó la primera versión de PMBOK en un intento de documentar y estandarizar la información y prácticas de gestión de proyectos generalmente aceptadas. Recientemente ha publicado la quinta versión, que proporciona una referencia básica para todos los interesados en la gestión de los proyectos, suministrando un léxico común y una estructura consistente en el campo de la gestión de los proyectos. El objetivo principal de la guía PMBOK es definir un subconjunto de buenas prácticas comúnmente aceptadas, entendiendo por tales que hay un acuerdo generalizado en que la correcta aplicación de estas habilidades, herramientas y técnicas pueden mejorar las posibilidades de éxito. Según PMI, buenas prácticas no significa que el conocimiento descrito sea aplicado uniformemente a todos los proyectos, sino que el equipo de proyecto debe ser responsable de determinar qué es lo apropiado para su proyecto. 3.3.2 Estructura La estructura de PMBOK se descompone en 3 secciones: El Marco conceptual de la dirección de proyectos: En esta sección se proporciona una estructura básica para entender los conceptos relacionados con la gestión de proyectos, ciclo de vida, estructuras organizativas y el entorno en el que se desarrolla la gestión de los proyectos. NI BO OM R Define lo que considera las 5 áreas de experiencia: habilidades interpersonales (comunicación, liderazgo, motivación, resolución de problemas, gestión de negociación y conflictos), habilidades en dirección general (gestión financiera, aprovisionamiento, marketing, legislación comercial, distribución, planificación estratégica, prácticas de salud y seguridad), en conocimiento del área de aplicación (departamentos funcionales, elementos técnicos, desarrollo de nuevos productos, grupo industrial al que se corresponde), conocimiento del cuerpo del conocimiento de dirección de proyectos (PMBOK), conocimiento del entorno del proyecto (entorno cultural y social, entorno político y entorno geográfico). A LA - VINCIT Página 79 de 134 ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI En cuanto al ciclo de vida, expone las características del ciclo de vida de un proyecto, con sus fases, y relaciones entre el ciclo de vida del proyecto y el ciclo de vida del producto. Especifica las funciones y relaciones de los stakeholders y el equipo de proyecto, así como la delimitación de responsabilidades. Finalmente, especifica las influencias organizativas con sus sistemas organizativos y los estilos, culturas y estructuras organizativas. - Norma para la dirección de procesos de un proyecto: En esta sección, describen: el proceso de dirección de proyectos, los grupos de procesos dirección de proyectos (inicio, planificación, ejecución, control y cierre), interacciones entre los procesos y el mapa de procesos (correspondencia de procesos de dirección de proyectos). se de las los En la siguiente imagen podemos ver un diagrama que representa el ciclo de vida de la administración de proyectos, según PMBOK: Áreas de conocimiento de la gestión de proyectos. En esta sección se describen detalladamente las 9 áreas de conocimiento: Gestión de la Integración del proyecto: en el que se incluyen todas las actividades y procesos que hay que realizar para identificar, combinar y coordinar los diversos procesos y actividades de gestión dentro de los grupos de gestión de procesos. o Gestión del alcance: que incluye los procesos para asegurar que el proyecto incluye todo el trabajo necesario y sólo el necesario, para completar el proyecto de forma satisfactoria. o Gestión del tiempo del proyecto: que incluye los procesos requeridos para finalizar el proyecto de forma completamente satisfactoria en el plazo previsto. o Gestión de costes del proyecto: que incluye los procesos necesarios para poder planificar, estimar, presupuestar y controlar los costes de forma que se pueda finalizar dentro de los costes planificados. o Gestión de la calidad del proyecto: donde se determinan las políticas de calidad, objetivos y responsabilidades de forma que el proyecto satisfaga las necesidades previstas. o Gestión de los recursos humanos: que se encarga de organizar y gestionar al equipo de proyecto, asignando los roles y responsabilidades correspondientes. o Gestión de la comunicación: cuyos procesos aseguran la generación temporal apropiada y la distribución, colección y almacenamiento de la información del proyecto. BO NI A Página 80 de 134 OM R o LA - VINCIT ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI o Gestión del riesgo: cuyos procesos realizan la planificación, identificación, análisis cualitativo y cuantitativo de los riesgos, así como la planificación de las medidas a adoptar y su control. o Gestión de adquisiciones: cuyos procesos incluyen la adquisición de productos, servicios o resultados necesarios y que siendo ajenos al equipo del proyecto son necesarios para el trabajo a realizar. A continuación, mostramos un esquema con las nueve áreas de conocimiento y 39 procesos de gestión de proyectos que propone PMBOK: 3.3.3 Técnicas PMBOK sugiere un amplio abanico de técnicas que incluye las técnicas de estimación y análisis de valor ganado, así como una gran cantidad de técnicas para la gestión de riesgo. La calidad queda garantizada con el uso de muchas técnicas para la planificación, control, aseguramiento y gestión de calidad. Recoge también las técnicas de descomposición tanto de la estructura organizativa como de la estructura de trabajos y de recursos. BO NI A LA OM R Entre las herramientas y técnicas que propone PMBOK, recomienda utilizar una metodología de dirección de proyectos que sirva para que un equipo de dirección del proyecto desarrolle y controle los cambios en cada uno de los procesos. VINCIT Página 81 de 134 ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI 3.4 Procesos (Guía PMBOK) 3.4.1 Introducción a los procesos Un proceso es un conjunto de acciones y actividades interrelacionadas realizadas para obtener un producto, resultado o servicio predefinido. Cada proceso se caracteriza por sus entradas, por las herramientas y técnicas que puedan aplicarse y por las salidas que se obtienen. El director del proyecto debe considerar los activos de los procesos de la organización y los factores ambientales de la empresa. Éstos se deben tener en cuenta para cada proceso, incluso si no están enumerados de manera explícita como entradas en las especificaciones del proceso. Los activos de los procesos de la organización proporcionan pautas y criterios para adaptar dichos procesos a las necesidades específicas del proyecto. Los factores ambientales de la empresa pueden restringir las opciones de la dirección de proyectos. Para que un proyecto tenga éxito, el equipo del proyecto debe: - Seleccionar los procesos adecuados requeridos para alcanzar los objetivos del proyecto. - Utilizar un enfoque definido que pueda adoptarse para cumplir con los requisitos. - Cumplir con los requisitos a fin de satisfacer las necesidades y expectativas de los interesados. - Equilibrar las demandas contrapuestas relativas al alcance, tiempo, costo, calidad, recursos y riesgo para producir el producto, servicio o resultado especificado. Los procesos del proyecto son ejecutados por el equipo del proyecto y, generalmente, se enmarcan en una de las siguientes dos categorías principales: Los procesos de dirección de proyectos aseguran que el proyecto avance de manera eficaz durante toda su existencia. Estos procesos incluyen las herramientas y técnicas involucradas en la aplicación de las habilidades y capacidades que se describen en las Áreas de conocimiento. Los procesos orientados al producto especifican y crean el producto del proyecto. Estos procesos normalmente son definidos por el ciclo de vida del proyecto y varían según el área de aplicación. El alcance del proyecto no puede definirse si no se cuenta con una comprensión básica acerca de cómo generar el producto especificado. La guía PMBOK describe únicamente los procesos de la dirección de proyectos. Si bien los procesos orientados al producto están fuera del alcance de esta norma, no deben ser ignorados por el director del proyecto. Los procesos de la dirección de proyectos y los procesos orientados al producto se superponen e interactúan a lo largo de la vida de un proyecto. BO NI A LA OM R Los directores del proyecto y sus equipos deben abordar cuidadosamente cada proceso, así como las entradas y salidas que lo constituyen. VINCIT ADAMS Página 82 de 134 TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI 3.4.2 Procesos de dirección de proyectos La dirección de proyectos es una tarea integradora que requiere que cada proceso del producto y del proyecto esté alineado y conectado de manera adecuada con los demás procesos, a fin de facilitar la coordinación. Normalmente, las acciones tomadas durante un proceso afectan a ese proceso y a otros procesos relacionados. Una dirección de proyectos exitosa incluye dirigir activamente estas interacciones a fin de cumplir con los requisitos del patrocinador, el cliente y los demás interesados. En determinadas circunstancias, será necesario repetir varias veces un proceso o conjunto de procesos para alcanzar el resultado requerido. Los proyectos existen en el marco de referencia de una organización y no pueden operar como un sistema cerrado. Requieren datos de entrada procedentes de la organización y del exterior, y producen capacidades que vuelven a la organización. Los procesos del proyecto pueden generar información para mejorar la dirección de futuros proyectos. Esta norma describe la naturaleza de los procesos de dirección de proyectos en términos de la integración entre los procesos, sus interacciones y los propósitos a los cuales sirven. Los procesos de dirección de proyectos se agrupan en cinco categorías conocidas como Grupos de Procesos de la Dirección de Proyectos: Grupo del Proceso de Iniciación: Aquellos procesos realizados para definir un nuevo proyecto o una nueva fase de un proyecto ya existente, mediante la obtención de la autorización para comenzar dicho proyecto o fase. Grupo del Proceso de Planificación: Aquellos procesos requeridos para establecer el alcance del proyecto, refinar los objetivos y definir el curso de acción necesario para alcanzar los objetivos para cuyo logro se emprendió el proyecto. Grupo del Proceso de Ejecución: Aquellos procesos realizados para completar el trabajo definido en el plan para la dirección del proyecto a fin de cumplir con las especificaciones del mismo. Grupo del Proceso de Seguimiento y Control: Aquellos procesos requeridos para dar seguimiento, analizar y regular el progreso y el desempeño del proyecto, para identificar áreas en las que el plan requiera cambios y para iniciar los cambios correspondientes. Grupo del Proceso de Cierre: Aquellos procesos realizados para finalizar todas las actividades a través de todos los grupos de procesos, a fin de cerrar formalmente el proyecto o una fase del mismo. BO NI A LA OM R VINCIT ADAMS Página 83 de 134 TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI En la siguiente figura, podemos observar un diagrama correspondiente a los grupos de procesos de la Dirección de Proyectos: Los grupos de procesos de la Dirección de Proyectos se vinculan entre sí a través de los resultados que producen. Los grupos de procesos rara vez son eventos diferenciados o únicos, sino que son actividades superpuestas que tienen lugar a lo largo de todo el proyecto. La salida de un proceso normalmente se convierte en la entrada para otro proceso o es un entregable del proyecto. El Grupo del Proceso de Planificación suministra al Grupo del Proceso de Ejecución el Plan para la Dirección del Proyecto y los documentos del proyecto y, conforme el proyecto avanza, a menudo exige actualizar el plan para la dirección del proyecto y dichos documentos. 3.4.3 Grupo del Proceso de Iniciación El Grupo del Proceso de Iniciación está compuesto por aquellos procesos realizados para definir un nuevo proyecto o una nueva fase de un proyecto ya existente, mediante la obtención de la autorización para comenzar dicho proyecto o fase. Dentro de los procesos de iniciación, se define el alcance inicial y se comprometen los recursos financieros iniciales. Se identifican los interesados internos y externos que van a interactuar y ejercer alguna influencia sobre el resultado global del proyecto. Si aún no fue nombrado, se seleccionará el director del proyecto. Esta información se plasma en el acta de constitución del proyecto y registro de interesados. Cuando el acta de constitución del proyecto recibe aprobación, el proyecto se considera autorizado oficialmente. A BO LA NI Página 84 de 134 OM R Los procesos de iniciación pueden ser realizados por procesos de la organización, del programa o del portafolio que son ajenos al alcance de control del proyecto. VINCIT ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI El Grupo del Proceso de Iniciación incluye los siguientes procesos de dirección de proyectos: - Desarrollar el Acta de Constitución del Proyecto: Desarrollar el Acta de Constitución del Proyecto es el proceso que consiste en desarrollar un documento que autoriza formalmente un proyecto o una fase, y en documentar los requisitos iniciales que satisfacen las necesidades y expectativas de los interesados. En proyectos de fases múltiples, este proceso se utiliza para validar o refinar las decisiones tomadas durante la repetición anterior del proceso Desarrollar el Acta de Constitución del Proyecto. A continuación se muestra una figura con las entradas y salidas correspondientes a este proceso: Identificar a los Interesados: Identificar a los Interesados es el proceso que consiste en identificar a todas las personas u organizaciones que reciben el impacto del proyecto, y en documentar información relevante relativa a sus intereses, participación e impacto en el éxito del proyecto. NI BO OM R A continuación se muestra una figura con las entradas y salidas correspondientes a este proceso: A LA - VINCIT ADAMS Página 85 de 134 TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI 3.4.4 Grupo del Proceso de Planificación El Grupo del Proceso de Planificación está compuesto por aquellos procesos realizados para establecer el alcance total del esfuerzo, definir y refinar los objetivos, y desarrollar la línea de acción requerida para alcanzar dichos objetivos. Los procesos de planificación desarrollan el plan para la dirección del proyecto y los documentos del proyecto que se utilizarán para llevarlo a cabo. A medida que se recopilan o se comprenden más características o informaciones sobre el proyecto, puede ser necesaria una mayor planificación. Los cambios importantes que ocurren a lo largo del ciclo de vida del proyecto generan la necesidad de reconsiderar uno o más de los procesos de planificación y, posiblemente, algunos de los procesos de iniciación. Esta incorporación progresiva de detalles al plan para la dirección del proyecto recibe generalmente el nombre de “planificación gradual”, para indicar que la planificación y la documentación son procesos repetitivos y continuos. El plan para la dirección del proyecto y los documentos del proyecto desarrollados como salidas del grupo de procesos de planificación, explorarán todos los aspectos del alcance, tiempo, costos, calidad, comunicación, riesgos y adquisiciones. El Grupo del Proceso de Planificación incluye los procesos de dirección de proyectos que se indican a continuación: Desarrollar el Plan para la Dirección del Proyecto: Desarrollar el Plan para la Dirección del Proyecto es el proceso que consiste en documentar las acciones necesarias para definir, preparar, integrar y coordinar todos los planes subsidiarios. El plan para la dirección del proyecto se convierte en la fuente primaria de información para determinar la manera en que se planificará, ejecutará, supervisará, controlará, y cerrará el proyecto. BO NI A Página 86 de 134 OM R A continuación se muestra una figura con las entradas y salidas correspondientes a este proceso: LA - VINCIT ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI - Recopilar Requisitos: Recopilar Requisitos es el proceso que consiste en definir y documentar las necesidades de los interesados a fin de cumplir con los objetivos del proyecto. A continuación se muestra una figura con las entradas y salidas correspondientes a este proceso: - Definir el Alcance: Definir el Alcance es el proceso que consiste en desarrollar una descripción detallada del proyecto y del producto. A continuación se muestra una figura con las entradas y salidas correspondientes a este proceso: NI BO OM R Crear la EDT (Estructura de Desglose del Trabajo): Crear la Estructura de Desglose del Trabajo es el proceso que consiste en subdividir los entregables y el trabajo del proyecto en componentes más pequeños y más fáciles de dirigir. A LA - VINCIT Página 87 de 134 ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI A continuación se muestra una figura con las entradas y salidas correspondientes a este proceso: - Definir las Actividades: Definir las Actividades es el proceso que consiste en identificar las acciones específicas a ser realizadas para elaborar los entregables del proyecto. A continuación se muestra una figura con las entradas y salidas correspondientes a este proceso: Secuenciar las Actividades: Secuenciar las Actividades es el proceso que consiste en identificar y documentar las relaciones entre las actividades del proyecto. BO NI A Página 88 de 134 OM R A continuación se muestra una figura con las entradas y salidas correspondientes a este proceso: LA - VINCIT ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI - Estimar los Recursos de las Actividades: Estimar los Recursos de las Actividades es el proceso que consiste en estimar el tipo y las cantidades de materiales, personas, equipos o suministros requeridos para ejecutar cada actividad. A continuación se muestra una figura con las entradas y salidas correspondientes a este proceso: - Estimar la Duración de las Actividades: Estimar la Duración de las Actividades es el proceso que consiste en establecer aproximadamente la cantidad de períodos de trabajo necesarios para finalizar cada actividad con los recursos estimados. A continuación se muestra una figura con las entradas y salidas correspondientes a este proceso: NI BO OM R Desarrollar el Cronograma: Desarrollar el Cronograma es el proceso que consiste en analizar el orden de las actividades, su duración, los requisitos de recursos y las restricciones del cronograma para crear el cronograma del proyecto. A LA - VINCIT Página 89 de 134 ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI A continuación se muestra una figura con las entradas y salidas correspondientes a este proceso: - Estimar Costos: Estimar Costos es el proceso que consiste en desarrollar una aproximación de los recursos monetarios necesarios para completar las actividades del proyecto. A continuación se muestra una figura con las entradas y salidas correspondientes a este proceso: Determinar el Presupuesto: Determinar el Presupuesto es el proceso que consiste en sumar los costos estimados de actividades individuales o paquetes de trabajo para establecer una línea base de costos autorizados. NI BO OM R A continuación se muestra una figura con las entradas y salidas correspondientes a este proceso: A LA - VINCIT Página 90 de 134 ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI - Planificar la Calidad: Planificar la Calidad es el proceso por el cual se identifican los requisitos de calidad y/o normas para el proyecto y el producto, y se documenta la manera en que el proyecto demostrará el cumplimiento con los mismos. A continuación se muestra una figura con las entradas y salidas correspondientes a este proceso: - Desarrollar el Plan de Recursos Humanos: Desarrollar el Plan de Recursos Humanos es el proceso por el cual se identifican y documentan los roles dentro de un proyecto, las responsabilidades, las habilidades requeridas y las relaciones de comunicación, y se crea el plan para la dirección de personal. A continuación se muestra una figura con las entradas y salidas correspondientes a este proceso: NI BO OM R Planificar las Comunicaciones: Planificar las Comunicaciones es el proceso para determinar las necesidades de información de los interesados en el proyecto y para definir cómo abordar las comunicaciones. A LA - VINCIT Página 91 de 134 ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI A continuación se muestra una figura con las entradas y salidas correspondientes a este proceso: - Planificar la Gestión de Riesgos: Planificar la Gestión de Riesgos es el proceso por el cual se define cómo realizar las actividades de gestión de riesgos para un proyecto. A continuación se muestra una figura con las entradas y salidas correspondientes a este proceso: Identificar Riesgos: Identificar Riesgos es el proceso por el cual se determinan los riesgos que pueden afectar el proyecto y se documentan sus características. NI BO OM R A continuación se muestra una figura con las entradas y salidas correspondientes a este proceso: A LA - VINCIT Página 92 de 134 ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI - Realizar Análisis Cualitativo de Riesgos: Realizar Análisis Cualitativo de Riesgos es el proceso que consiste en priorizar los riesgos para realizar otros análisis o acciones posteriores, evaluando y combinando la probabilidad de ocurrencia y el impacto de dichos riesgos. A continuación se muestra una figura con las entradas y salidas correspondientes a este proceso: - Realizar Análisis Cuantitativo de Riesgos: Realizar Análisis Cuantitativo de Riesgos es el proceso que consiste en analizar numéricamente el efecto de los riesgos identificados sobre los objetivos generales del proyecto. A continuación se muestra una figura con las entradas y salidas correspondientes a este proceso: NI BO OM R Planificar la Respuesta a los Riesgos: Planificar la Respuesta a los Riesgos es el proceso por el cual se desarrollan opciones y acciones para mejorar las oportunidades y reducir las amenazas a los objetivos del proyecto. A LA - VINCIT Página 93 de 134 ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI A continuación se muestra una figura con las entradas y salidas correspondientes a este proceso: - Planificar las Adquisiciones: Planificar las Adquisiciones es el proceso que consiste en documentar las decisiones de compra para el proyecto, especificar el enfoque e identificar posibles vendedores. A continuación se muestra una figura con las entradas y salidas correspondientes a este proceso: 3.4.5 Grupo del Proceso de Ejecución El Grupo del Proceso de Ejecución está compuesto por aquellos procesos realizados para completar el trabajo definido en el plan para la dirección del proyecto a fin de cumplir con las especificaciones del mismo. Este grupo de proceso implica coordinar personas y recursos, así como integrar y realizar las actividades del proyecto de conformidad con el plan para la dirección del proyecto. Durante la ejecución del proyecto, los resultados pueden requerir que se actualice la planificación y que se vuelva a establecer la línea base. Esto puede incluir cambios en la duración prevista de las actividades, cambios en la disponibilidad y productividad de recursos, así como en los riesgos no anticipados. BO NI A LA OM R Gran parte del presupuesto del proyecto se utilizará en la realización de los procesos del grupo de procesos de ejecución. VINCIT Página 94 de 134 ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI El grupo de procesos de ejecución incluye los siguientes procesos de dirección de proyectos: - Dirigir y Gestionar la Ejecución del Proyecto: Dirigir y Gestionar la ejecución del proyecto es el proceso que consiste en ejecutar el trabajo definido en el plan para la dirección del proyecto para cumplir con los objetivos del proyecto. A continuación se muestra una figura con las entradas y salidas correspondientes a este proceso: - Realizar Aseguramiento de Calidad: Realizar Aseguramiento de Calidad es el proceso que consiste en auditar los requisitos de calidad y los resultados obtenidos a partir de medidas de control de calidad, a fin de garantizar que se utilicen definiciones operacionales y normas de calidad adecuadas. A continuación se muestra una figura con las entradas y salidas correspondientes a este proceso: NI BO OM R Adquirir el Equipo del Proyecto: Adquirir el Equipo del Proyecto es el proceso para confirmar los recursos humanos disponibles y a formar el equipo necesario para completar las asignaciones del proyecto. A LA - VINCIT Página 95 de 134 ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI A continuación se muestra una figura con las entradas y salidas correspondientes a este proceso: - Desarrollar el Equipo del Proyecto: Desarrollar el Equipo del Proyecto es el proceso que consiste en mejorar las competencias, la interacción de los miembros del equipo y el ambiente general del equipo para lograr un mejor desempeño en el proyecto. A continuación se muestra una figura con las entradas y salidas correspondientes a este proceso: NI BO OM R Dirigir el Equipo del Proyecto: Dirigir el equipo del proyecto es el proceso que consiste en dar seguimiento al desempeño de los miembros del equipo, proporcionar retroalimentación, resolver problemas y gestionar cambios a fin de optimizar el desempeño del proyecto. A LA - VINCIT Página 96 de 134 ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI A continuación se muestra una figura con las entradas y salidas correspondientes a este proceso: - Distribuir la Información: Distribuir la Información es el proceso para poner la información relevante a la disposición de los interesados en el proyecto de acuerdo al plan establecido. A continuación se muestra una figura con las entradas y salidas correspondientes a este proceso: Gestionar las Expectativas de los Interesados: Gestionar las Expectativas de los Interesados es el proceso que consiste en comunicarse y trabajar en conjunto con los interesados para satisfacer sus necesidades y abordar los problemas conforme se presentan. BO NI A Página 97 de 134 OM R A continuación se muestra una figura con las entradas y salidas correspondientes a este proceso: LA - VINCIT ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI - Efectuar Adquisiciones: Efectuar Adquisiciones es el proceso que consiste en obtener respuestas de los vendedores, seleccionar un vendedor y adjudicar un contrato. A continuación se muestra una figura con las entradas y salidas correspondientes a este proceso: 3.4.6 Grupo del Proceso de Seguimiento y Control El grupo del Proceso de Seguimiento y Control está compuesto por aquellos procesos requeridos para supervisar, analizar y regular el progreso y el desempeño del proyecto, para identificar áreas en las que el plan requiera cambios y para iniciar los cambios correspondientes. El beneficio clave de este grupo de procesos radica en que el desempeño del proyecto se observa y se mide de manera sistemática y regular, a fin de identificar variaciones respecto del plan para la dirección del proyecto. El grupo de procesos de seguimiento y control también incluye: Controlar cambios y recomendar acciones preventivas para anticipar posibles problemas. Dar seguimiento a las actividades del proyecto, comparándolas con el plan para la dirección del proyecto y la línea base desempeño de ejecución del proyecto. Influir en los factores que podrían eludir el control integrado de cambios, de modo que únicamente se implementen cambios aprobados. BO NI A LA OM R Este seguimiento continuo proporciona al equipo del proyecto conocimientos sobre la salud del proyecto y permite identificar las áreas que requieren más atención. En proyectos de fases múltiples, el grupo de proceso de seguimiento y control coordina las fases del proyecto a fin de implementar acciones correctivas o preventivas, de modo que se cumpla con el plan para la dirección del proyecto. VINCIT Página 98 de 134 ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI El Grupo del Proceso de Seguimiento y Control incluye los siguientes procesos de dirección de proyectos: - Dar Seguimiento y Controlar el Trabajo del Proyecto: Dar Seguimiento y Controlar el Trabajo del Proyecto es el proceso que consiste en revisar, analizar y regular el avance a fin de cumplir con los objetivos de desempeño definidos en el plan para la dirección del proyecto. Dar Seguimiento implica realizar informes de estado, mediciones del avance y proyecciones. Los informes de desempeño suministran información sobre el desempeño del proyecto en lo relativo al alcance, cronograma, costos, recursos, calidad y riesgos, que puede utilizarse como entrada para otros procesos. A continuación se muestra una figura con las entradas y salidas correspondientes a este proceso: Realizar Control Integrado de Cambios: Realizar Control Integrado de cambios es el proceso que consiste en revisar todas las solicitudes de cambios, aprobar los cambios y gestionar los cambios a los entregables, a los activos de los procesos de la organización, a los documentos del proyecto y al plan para la dirección del proyecto. NI BO OM R A continuación se muestra una figura con las entradas y salidas correspondientes a este proceso: A LA - VINCIT Página 99 de 134 ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI - Verificar el Alcance: Verificar el Alcance es el proceso que consiste en formalizar la aceptación de los entregables del proyecto que se han completado. A continuación se muestra una figura con las entradas y salidas correspondientes a este proceso: - Controlar el Alcance: Controlar el Alcance es el proceso por el que se da seguimiento el estado del alcance del proyecto y del producto, y se gestionan cambios a la línea base del alcance. A continuación se muestra una figura con las entradas y salidas correspondientes a este proceso: NI BO OM R Controlar el Cronograma: Controlar el Cronograma es el proceso por el que se da seguimiento a la situación del proyecto para actualizar el avance del mismo y gestionar cambios a la línea base del cronograma. A LA - VINCIT Página 100 de 134 ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI A continuación se muestra una figura con las entradas y salidas correspondientes a este proceso: - Controlar Costos: Controlar costos es el proceso por el que se da seguimiento a la situación del proyecto para actualizar el presupuesto del mismo y gestionar cambios a la línea base de costo. A continuación se muestra una figura con las entradas y salidas correspondientes a este proceso: Realizar Control de Calidad: Realizar Control de Calidad es el proceso por el que se da seguimiento y se registran los resultados de la ejecución de actividades de control de calidad, a fin de evaluar el desempeño y recomendar cambios necesarios. NI BO OM R A continuación se muestra una figura con las entradas y salidas correspondientes a este proceso: A LA - VINCIT Página 101 de 134 ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI - Informar el Desempeño: Informar el Desempeño es el proceso de recopilación y distribución de información sobre el desempeño, incluidos informes de estado, mediciones del avance y proyecciones. A continuación se muestra una figura con las entradas y salidas correspondientes a este proceso: - Dar Seguimiento y Controlar los Riesgos: Dar Seguimiento y Controlar los Riesgos es el proceso por el cual se implementan planes de respuesta a los riesgos, se da seguimiento a los riesgos identificados, se da seguimiento a los riesgos residuales, se identifican nuevos riesgos y se evalúa la efectividad del proceso contra riesgos a través del proyecto. A continuación se muestra una figura con las entradas y salidas correspondientes a este proceso: BO NI A Página 102 de 134 OM R Administrar las Adquisiciones: Administrar las Adquisiciones es el proceso que consiste en gestionar las relaciones de adquisiciones, supervisar el desempeño del contrato y efectuar cambios y correcciones según sea necesario. LA - VINCIT ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI A continuación se muestra una figura con las entradas y salidas correspondientes a este proceso: 3.4.7 Grupo del Proceso de Cierre El Grupo del Proceso del Cierre está compuesto por aquellos procesos realizados para finalizar todas las actividades a través de todos los grupos de procesos de la dirección de proyectos, a fin de completar formalmente el proyecto, una fase del mismo u otras obligaciones contractuales. Este grupo de procesos, una vez completado, verifica que los procesos definidos se hayan completado dentro de todos los grupos de procesos a fin de cerrar el proyecto o una fase del mismo, según corresponda, y establece formalmente que el proyecto o fase del mismo ha finalizado. En el cierre del proyecto o fase, puede ocurrir lo siguiente: Obtener la aceptación del cliente o del patrocinador. Realizar una revisión tras el cierre del proyecto o la finalización de una fase. Registrar los impactos de la adaptación a un proceso. Documentar las lecciones aprendidas. Aplicar actualizaciones apropiadas a los activos de los procesos de la organización. Archivar todos los documentos relevantes del proyecto en el sistema de información para la dirección de proyectos para ser utilizados como datos históricos. Cerrar las adquisiciones. BO NI A LA OM R VINCIT Página 103 de 134 ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI El Grupo del Proceso de Cierre incluye los siguientes procesos de dirección de proyectos: - Cerrar el Proyecto o Fase: Cerrar el Proyecto o Fase es el proceso que consiste en finalizar todas las actividades a través de todos los grupos de procesos de dirección de proyectos para completar formalmente el proyecto o una fase del mismo. A continuación se muestra una figura con las entradas y salidas correspondientes a este proceso: Cerrar las Adquisiciones: Cerrar las Adquisiciones es el proceso de finalización de cada adquisición del proyecto. BO NI A Página 104 de 134 OM R A continuación se muestra una figura con las entradas y salidas correspondientes a este proceso: LA - VINCIT ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI 4. MODELOS Y NORMA CMMI 4.1 Definición La entidad responsable del modelo CMMI es el Software Engineering Institute (SEI) de la Universidad Carnegie Mellon, patrocinado por el Departamento de Defensa de los Estados Unidos. CMMI, que proviene de las siglas en inglés (Capability Maturity Model Integration), es un modelo para la mejora de procesos que proporciona a las organizaciones los elementos esenciales para que los mismos sean eficaces. Con el propósito de lograr la mejora de los procesos, CMMI provee: Una forma de integrar los elementos funcionales de una organización. Un conjunto de mejores prácticas basadas en casos de éxito probado de organizaciones experimentadas en la mejora de procesos. Ayuda para identificar objetivos y prioridades para mejorar los procesos de la organización, dependiendo de las fortalezas y debilidades de la organización que son obtenidas mediante un método de evaluación. Un apoyo para que las empresas complejas en actividades productivas puedan coordinar sus actividades en la mejora de los procesos. Un punto de referencia para evaluar los procesos actuales de la organización. La idea principal del modelo CMMI es la distinción entre empresas inmaduras y maduras. Tipo de organización Características Madura - Capacidad de gestión: desarrollo de software y procesos de mantenimiento. - Proceso de software difundido al equipo y planificado - Procesos modificables: pruebas piloto controladas y análisis de coste/beneficio - Roles y responsabilidades establecidos en el proyecto y la organización - Gestores: monitorización de la calidad de los productos y de los procesos - Planificaciones y presupuestos realistas: rendimientos históricos - Proceso disciplinado en el que todos los participantes entienden su valor, existiendo además la infraestructura necesaria para soportar el proceso BO NI A LA OM Página 105 de 134 R Inmadura - Procesos de software: improvisados o no respetados, en el caso de que existan - Planificación en función de los problemas - Presupuestos y planificación incumplidos - Sin base objetiva para evaluar la calidad o para resolver problemas - Inexistencia o reducción de las actividades de mejora de la calidad VINCIT ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI 4.2 Introducción 4.2.1 Orígenes de CMMI Tras su creación en 1984 el SEI comenzó la investigación para desarrollar un marco de mejora y evaluación de la calidad de las empresas desarrolladoras de software que prestaban servicios al Departamento de Defensa de los Estados Unidos. El resultado de la investigación se denominó "Capability Maturity Model for Software" (SWCMM), cuya versión 1.0 se publicó en Agosto de 1991. Posteriormente, como resultado de la retroalimentación generada por parte de la comunidad de software, se desarrollaron las versiones 1.1 publicada en 1993 y 2.0, la cual agregaba y modificaba una serie de elementos al vigente CMM v1.1, relacionados con alcanzar la institucionalización en la organización. Esta versión se completó en 1997 y se denominó “Software CMM, Version 2.0”, pero nunca fue publicada. SW-CMM es un modelo de madurez de capacidades desarrollado para los procesos relativos a la producción y mantenimiento de sistemas software. De esta forma el SW-CMM puede emplearse con dos finalidades: 1. Guía para mejorar procesos relativos a la producción y mantenimiento del software. 2. Criterio para determinar el nivel de madurez de una organización que produce y mantiene software. CMMI v1.2 corresponde a la tercera versión entregable del modelo CMMI, posterior a las versiones 1.02 (primera versión año 2000) y 1.1 (año 2002). Las versiones previas sirvieron como retroalimentación para que los propios usuarios, evaluadores y evaluados hicieran acotaciones sobre posibles mejoras, las cuales fueron estudiadas, refinadas y algunas incluidas en la versión 1.2. CMMI v1.2 para desarrollo. BO NI A LA OM R Junto con CMMI se desarrolló y publicó el método de evaluación “Assessment Requirements for CMMI” en el año 2000, el cual define los requerimientos considerados esenciales para realizar una evaluación de CMMI en una organización, y “Standard CMMI Appraisal Method for Process Improvement”, manual seguido por los evaluadores para medir el nivel de madurez de una organización. VINCIT Página 106 de 134 ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI 4.2.2 Representaciones de CMMI La representación usada en CMMI entrega una guía para efectuar las actividades de mejora de los procesos, y es utilizada en el método de evaluación. Según el modelo se tienen dos formas para mejorar los procesos: - Una forma es mejorar un proceso específico, o un conjunto de ellos, usando la Representación Continua. - La otra es la mejora de la organización completa según los procesos definidos y ocupados usando la Representación Escalonada o por Etapas. 4.2.2.1 Representación Continua La representación continua centra su actuación en la capacidad de los procesos. En dicho tipo de representación los procesos están organizados de una manera similar a la norma ISO/IEC 15504, la cual a su vez deriva de la norma ISO 9000. La representación continua se focaliza en la mejora de un proceso o un conjunto de ellos relacionados estrechamente con un área de proceso en que una organización desea mejorar, por lo tanto una organización puede ser certificada para un área de proceso en cierto nivel de capacidad. Existen seis niveles de capacidad por donde transitan los procesos asociados a un área de proceso, y cada nivel es construido sobre el nivel anterior. Es decir, para que un proceso alcance un nivel de capacidad necesariamente debe haber alcanzado el nivel anterior. BO NI A LA OM R A continuación, podemos observar el tipo de diagrama empleado en la representación continua: VINCIT Página 107 de 134 ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI 4.2.2.2 Representación Escalonada La representación escalonada centra su actuación en la madurez de la organización. En dicho tipo de representación los elementos están organizados siguiendo el esquema del CMM Software. En la representación escalonada o por etapas se ofrece un método estructurado y sistemático de mejora de procesos, que implica mejorar por etapas o niveles. Al alcanzar un nivel, la organización se asegura contar con una infraestructura robusta en términos de procesos para optar a alcanzar el nivel siguiente. Por lo tanto es una organización la que puede ser certificada bajo un nivel, en este caso llamado nivel de madurez. Según esta representación un nivel de madurez está compuesto por áreas de procesos en donde los objetivos asociados a ese nivel deben ser cumplidos para que la organización pueda certificarse en aquel nivel de madurez. Como se mencionó en el apartado 1.4.4.1 del tutorial, hay cinco niveles de madurez: inicial, repetible, definido, cuantitativamente gestionado y optimizado. A BO LA NI Página 108 de 134 OM R A continuación, podemos observar el tipo de diagrama empleado en la representación escalonada: VINCIT ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI 4.2.2.3 Niveles para las representaciones continua y escalonada Como ya se ha especificado en los subapartados anteriores, en función del tipo de representación empleada, el modelo CMMI propone una serie de niveles u otros. En la tabla que se muestra a continuación, se realiza una comparativa entre los niveles correspondientes a la representación continua y los niveles correspondientes a la representación escalonada: Representación Continua Nivel de Capacidad Incompleto Nivel 3 Nivel 4 Nivel 5 Inicial Un proceso es denominado “proceso realizado” cuando satisface todos los objetivos específicos del área de proceso. Soporta y permite el trabajo necesario para producir artefactos. En el nivel de madurez 1, la mayoría de los procesos son caóticos. La organización usualmente no provee un ambiente estable para soportar procesos. Repetible Repetible Un proceso es denominado “proceso repetible” cuando tiene la infraestructura base para apoyar el proceso. El proceso es planeado y ejecutado en concordancia con la política. Es visualizado, controlado y revisado. Es evaluado según la descripción del proceso. En el nivel de madurez 2 se ordena el caos. Las organizaciones se enfocan en tareas cotidianas referentes a la administración. Cada proyecto cuenta con una serie de procesos para llevarlo a cabo, los cuales son planeados y ejecutados de acuerdo con políticas establecidas. Definido Definido Un proceso denominado “proceso definido” es adaptado desde el conjunto de procesos estándares de la organización, de acuerdo a las guías de adaptación de la organización. Aporta artefactos, medidas, y otra información de mejora a los activos organizacionales. En el nivel de madurez 3, los procesos son caracterizados y entendidos, y son descritos estándares, procedimientos, herramientas y métodos. Cuantitativamente gestionado Cuantitativamente gestionado Un proceso denominado “proceso cuantitativamente gestionado” es controlado usando técnicas estadísticas y otra técnicas cuantitativas. Objetivos cuantitativos para la calidad y realización del proceso son establecidos y usados como criterios para manejar el proceso. En el nivel de madurez 4, la organización y proyectos establecen objetivos cuantitativos para medir la calidad y realización de los procesos, y los usa como criterios en el manejo de ellos. La calidad y realización de procesos son entendidos en términos estadísticos y son manejados durante todo el ciclo de vida del proceso. Optimizado Optimizado Un proceso denominado “proceso en optimización” se focaliza en la mejora continua del proceso realizado a través de mejoras incrementales y usando innovación tecnológica. En el nivel de madurez 5, una organización mejora continuamente sus procesos basándose en el conocimiento de las causas comunes de variación inherente en los procesos. NI A Página 109 de 134 OM R Nivel 2 Realizado BO Nivel 1 Un proceso es denominado “proceso incompleto” cuando uno o más objetivos específicos del área de proceso no son satisfechos. LA Nivel 0 Representación Escalonada Nivel de Madurez - VINCIT ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI 4.3 Metodología 4.3.1 Áreas de Procesos CMMI recoge prácticas para 22 áreas de procesos. Las áreas de procesos agrupan las actividades necesarias para la ejecución de los proyectos de ingeniería de sistemas y de software, y son ejecutadas de forma conjunta para conseguir una serie de objetivos. El modelo en su representación escalonada clasifica a las 22 áreas de proceso en aquellas cuya gestión es necesaria para lograr cada nivel de calidad. Mientras que el modelo en su representación continua las clasifica según la categoría a la que pertenecen: gestión de proyectos, ingeniería, soporte y gestión de procesos. Los objetivos genéricos asociados a un nivel de capacidad establecen lo que una organización debe alcanzar en ese nivel de capacidad. El logro de cada uno de esos objetivos en un área de proceso significa mejorar el control en la ejecución del área de proceso. Los objetivos específicos se aplican a una única área de proceso y localizan las particularidades que describen qué se debe implementar para satisfacer el propósito del área de proceso. En la siguiente tabla se muestra el nombre de las áreas de proceso junto con su abreviación, y el nivel de calidad y categoría a la que pertenecen: Soporte Análisis y Resolución de Decisiones (DAR) Soporte 3 Aseguramiento de la Calidad de Procesos y Productos (PPQA) Soporte 2 Definición de Procesos Organizacionales + IPPD (OPD+IPPD) Gestión de procesos 3 Desarrollo de Requerimientos (RD) Ingeniería 3 Entrenamiento Organizacional (OT) Gestión de procesos 3 Administración Cuantitativa de Proyectos (QPM) Gestión de proyectos 3 Ingeniería 2 Gestión de proyectos 3 Soporte 2 Administración de la Configuración (CM) Gestión de proyectos 3 Administración Integral de Proyecto + IPD (IPM+IPPD) Gestión de proyectos 3 Innovación y Despliegue Organizacional (OID) Gestión de procesos 5 Ingeniería 3 Soporte 2 Monitoreo y Control de Proyecto (PMC) Gestión de proyectos 2 Planificación de Proyecto (PP) Gestión de proyectos 2 Procesos Orientados a la Organización (OPF) Gestión de procesos 3 Rendimiento de Procesos Organizacionales (OPP) Gestión de procesos 4 Solución Técnica (TS) Ingeniería 3 Validación (VAL) Ingeniería 3 Verificación (VER) Ingeniería 3 Administración de Riesgos (RSKM) Integración de Producto (PI) Medición y Análisis (MA) OM Página 110 de 134 NI BO Administración de Requerimientos (REQM) A LA Administración de Acuerdos con Proveedores (SAM) Categoría R Análisis y Resolución Causales (CAR) Nivel de madurez 5 Área de proceso VINCIT ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI A continuación se hará una breve descripción de cada área de proceso citado en la tabla anterior: Análisis y Resolución Causales (CAR): Identifica la causa de defectos u otros problemas. Una vez identificados toma acciones correctivas para prevenir la ocurrencia de tales defectos o problemas en el futuro. - Análisis y Resolución de Decisiones (DAR): Proporciona un proceso estructurado de toma de decisiones que asegura que las alternativas se comparan con criterios establecidos y objetivos, para así tomar la mejor decisión posible. - Aseguramiento de Calidad de Procesos y Productos (PPQA): Proporciona un conjunto de prácticas con el objetivo de evaluar productos, servicios, procesos y sus artefactos relacionados. - Definición de Procesos Organizacionales (OPD): Establece y mantiene un conjunto de estándares tanto en procesos organizacionales como en ambientes de trabajo. - Desarrollo de Requerimientos (RD): Recopila las necesidades del cliente para convertirlas en requerimientos del producto esperado. - Entrenamiento Organizacional (OT): Permite a la gente de la organización obtener habilidades y conocimientos necesarios para que el trabajo realizado por ellos sea efectivo y eficiente. - Administración Cuantitativa de Proyectos (QPM): Maneja métricas cuantitativas de los procesos con el objetivo de alcanzar los objetivos de calidad establecidos. Además mediante el análisis de estos datos permite identificar oportunidades de mejora para los procesos. - Administración de Acuerdos con Proveedores (SAM): Gestiona la adquisición de productos de proveedores con los cuales exista un acuerdo formal. - Administración de Requerimientos (REQM): Gestiona los requerimientos del producto durante todo el ciclo de vida de él, identificando inconsistencias con los artefactos y planes de proyecto. - Administración de Riesgos (RSKM): Identifica riesgos del proyecto para evaluarlos, priorizarlos y gestionarlos y prevenir así su futura ocurrencia. - Administración de la Configuración (CM): Establece y mantiene la integridad y consistencia de los artefactos. - Administración Integral de Proyecto (IPM): Adapta el conjunto de procesos estándares de la organización a procesos llevados a cabo para un proyecto en particular. Además maneja a las partes interesadas involucradas en el proyecto. - Innovación y Despliegue Organizacional (OID): Selecciona y despliega mejoras incrementales e innovadoras que mejoran en cierta medida los procesos de la organización y tecnologías, para alcanzar los objetivos de calidad organizacional y de realización de procesos derivados de los objetivos de negocio de la organización. BO NI A LA OM R - VINCIT Página 111 de 134 ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI Integración de Producto (PI): Ensambla los componentes del producto para producir un producto más complejo manteniendo el cumplimiento de los requerimientos establecidos. - Medición y Análisis (MA): Establece métricas con el objetivo de entregar resultados objetivos que sirvan como base para tomar decisiones informadas y correctivas. - Monitoreo y Control de proyecto (PMC): Analiza el proyecto con el objetivo de establecer un control y evaluación según los planes establecidos, tomando acciones correctivas cuando es necesario. - Planificación de Proyecto (PP): Desarrolla y mantiene planes del proyecto, compromisos adquiridos por parte de los participantes, y gestiona las partes interesadas del proyecto. - Procesos Orientados a la Organización (OPF): Ayuda a mantener un entendimiento de los procesos por parte de los miembros de la organización. También ayuda a identificar posibles mejoras de los procesos, que son evaluadas y eventualmente implementadas. - Rendimiento de Procesos Organizacionales (OPP): Deriva objetivos cuantitativos de calidad y ejecución de lo procesos desde el conjunto de objetivos de negocio de la organización. - Solución Técnica (TS): Diseña, desarrollo e implementa soluciones para los requerimientos del producto establecido. - Validación (VAL): Demuestra que el producto, componentes del producto y artefactos corresponden a lo esperado para su uso. - Verificación (VER): Demuestra que el producto, componentes del producto y artefactos cumplen con los requerimientos establecidos. BO NI A LA OM R - VINCIT Página 112 de 134 ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI 4.3.2 Componentes Aunque los componentes son independientes de la representación elegida, se definirán de acuerdo al esquema propuesto por la Representación Escalonada. Un área de proceso está asociada a un nivel de madurez dentro de CMMI, y tiene además un conjunto de objetivos específicos y uno o varios objetivos genéricos asociados, dependiendo del nivel de madurez al cual pertenece el área de proceso. Los objetivos específicos y genéricos cuentan con un conjunto de prácticas específicas y genéricas respectivamente. CMMI define componentes requeridos, esperados e informativos. 4.3.2.1 Componentes Requeridos Son los componentes que obligatoriamente deben ser satisfechos y visiblemente implementados para poder cumplir con un área de proceso. Un componente requerido es usado en las evaluaciones para ayudar a determinar si un área de proceso es satisfecho. Existen dos componentes requeridos: - Objetivo Específico (SG): Los objetivos específicos se aplican a una única área de proceso y localizan las particularidades que describe que se deben implementar para satisfacer el propósito del área de proceso. Las SG son parte de un área de proceso. - Objetivo Genérico (GG): Los objetivos genéricos asociados a un nivel de capacidad establecen lo que una organización debe alcanzar en dicho nivel de capacidad. El logro de cada uno de esos objetivos en un área de proceso, significa mejorar el control en la ejecución de dicho área. Las GG tienen el objetivo de institucionalizar los procesos que implementan un área de proceso y son comunes a un conjunto de las mismas. 4.3.2.2 Componentes Esperados Son los componentes que pueden ser utilizados para alcanzar un componente requerido, es decir, se podrían implementar estos componentes o modificaciones válidas de ellos con el fin de alcanzar los objetivos genéricos o específicos. Los componentes esperados pueden ser utilizados como guías de mejora y de evaluación de procesos. Existen dos tipos de componentes esperados: Prácticas Específicas (SP): Una práctica específica es una actividad que se considera importante en la realización del objetivo específico al cual está asociado. Las prácticas específicas describen las actividades esperadas para lograr la meta específica de un área de proceso. - Prácticas Genéricas (GP): Una práctica genérica se aplica a cualquier área de proceso, porque puede mejorar el funcionamiento y el control de cualquier proceso. BO NI A LA OM R - VINCIT Página 113 de 134 ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI 4.3.2.3 Componentes Informativos Los componentes informativos sólo son una ayuda propuesta por el modelo CMMI para entender mejor los componentes requeridos y esperados. Existen los siguientes tipos de componentes informativos: Propósito Notas introductorias Referencias (son indicadores de otras áreas de proceso relacionadas que pueden aportar información adicional o más detallada) Nombres Tablas de relaciones práctica-objetivo Prácticas Productos típicos Subprácticas (una subpráctica es una descripción detallada que sirve como guía para la interpretación de una práctica genérica o específica) Ampliaciones de disciplina (contienen información relevante de una disciplina particular y relacionada con una práctica específica) Elaboraciones de prácticas genéricas (son guías de aplicación de la práctica genérica al área de proceso) A continuación, mostramos un diagrama correspondiente a la representación escalonada de los componentes del modelo CMMI: Nivel CMMI Área de Proceso Área de Proceso Propósito Metas específicas Metas genéricas Prácticas específicas Prácticas genéricas Subprácticas relacionadas Elaboración de prácticas genéricas NI A Página 114 de 134 OM R Subprácticas Áreas proceso BO Artefactos típicos Notas introductorias LA Área de Proceso VINCIT ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI 4.3.3 Relaciones entre las áreas de proceso Hay cuatro grupos o categorías de áreas de procesos que ayudan a guiar el proceso de mejora de la organización. Estos grupos están formados por áreas de proceso que se interrelacionan fuertemente y tienen características comunes asociadas a objetivos de negocio tradicionales. Estas categorías son las indicadas en la tabla correspondiente a las áreas de procesos, del capítulo 4.3.1 del manual: Administración de procesos Administración de proyectos Soporte Ingeniería 4.3.3.1 Administración de procesos Las áreas de gestión de procesos cubren las actividades de definición, planificación, recursos, desarrollo, implementación, monitorización, control, evaluación, medición y mejora de procesos. El modelo CMMI SE/SW incluye cinco áreas de proceso en gestión de procesos: - Definición de procesos Enfoque de procesos a la organización Formación Rendimiento de los procesos Innovación y desarrollo El diagrama que se muestra a continuación, resume las relaciones existentes entre las distintas áreas de proceso de la categoría señalada: R BO NI A LA OM Página 115 de 134 VINCIT ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI 4.3.3.2 Administración de proyectos Las áreas de procesos de gestión de proyectos cubren las actividades relacionadas con la planificación, monitorización y control del proyecto. El modelo CMMI SE/SW incluye seis áreas de proceso en gestión de proyectos: - Planificación de proyecto Monitorización y control de proyecto Gestión y acuerdos con proveedores Gestión integrada de proyecto Gestión de riesgos Gestión cuantificada de proyecto El diagrama que se muestra a continuación, resume las relaciones existentes entre las distintas áreas de proceso de la categoría señalada: Si observamos el diagrama anterior, podemos apreciar que hace referencia a 3 áreas de proceso recogidas en el apartado 4.3.1 del tutorial: Planificación del proyecto (PP), monitorización y control (PMC) y gestión y acuerdos con proveedores (SAM). El propósito del área planificación de proyecto es establecer y mantener planes que definan las actividades del proyecto. El propósito del área monitorización y control es proporcionar información sobre el progreso del proyecto, que permita tomar acciones correctivas cuando la ejecución del proyecto se desvía significativamente del plan. BO NI A LA OM Página 116 de 134 R El propósito del área gestión y acuerdos con proveedores es gestionar la adquisición de productos a proveedores según un acuerdo formal existente. VINCIT ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI 4.3.3.3 Soporte Las áreas de procesos de soporte cubren las prácticas que sirven de base para el desarrollo del producto y su mantenimiento. El modelo CMMI SE/SW incluye cinco áreas de proceso en soporte: - Gestión de la configuración Gestión de la calidad de procesos y productos Medición y análisis Análisis y resolución de decisiones Análisis y resolución de problemas El diagrama que se muestra a continuación, resume las relaciones existentes entre las distintas áreas de proceso de la categoría señalada: Si observamos el diagrama anterior, podemos apreciar que hace referencia a 3 áreas de proceso recogidas en el apartado 4.3.1 del tutorial: Administración de la configuración (CM), aseguramiento de la calidad de procesos y productos (PPQA) y medición y análisis (MA). El propósito del área administración de la configuración es establecer y mantener la integridad de todos los productos de trabajo, utilizando identificación de la configuración, control de la configuración, informes de estado de configuración y auditorías de la configuración. El propósito del área aseguramiento de la calidad de procesos y producto es proporcionar un entendimiento objetivo de los procesos y los productos del trabajo asociado. BO NI A LA OM R El propósito del área medición y análisis es desarrollar y mantener una capacidad para medir, utilizada para dar soporte a las necesidades de información de la gerencia. VINCIT Página 117 de 134 ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI 4.3.3.4 Ingeniería Las áreas de proceso de ingeniería cubren las prácticas de desarrollo y mantenimiento compartidas por diferentes disciplinas, como ingeniería de software e ingeniería de sistemas. El modelo CMMI SE/SW incluye seis áreas de proceso en ingeniería: - Desarrollo de requisitos Gestión de requisitos Soluciones técnicas Integración de producto Verificación Validación El diagrama que se muestra a continuación, resume las relaciones existentes entre las distintas áreas de proceso de la categoría señalada: Si observamos el diagrama anterior, podemos apreciar que hace referencia a 6 áreas de proceso recogidas en el apartado 4.3.1 del tutorial: Desarrollo de requerimientos (RD), gestión de requerimientos (REQM), solución técnica (TS), integración de productos (PI), verificación (VER) y validación (VAL). El propósito del área gestión de requerimientos es gestionar los requisitos del producto y de componentes del producto del proyecto e identificar inconsistencias entre los requisitos, los planes del proyecto y los resultados del trabajo. BO NI A LA OM Página 118 de 134 R El propósito del área desarrollo de requerimientos es producir y analizar los requisitos del cliente, del producto y de los componentes del producto. VINCIT ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI El propósito del área solución técnica es desarrollar, diseñar e implementar soluciones a los requisitos. El propósito del área integración de producto es ensamblar el producto asegurando que funciona apropiadamente y entregar el producto. El propósito del área verificación es asegurar que los resultados del trabajo seleccionado, cumplen los requisitos especificados. BO NI A LA OM R El propósito del área validación es demostrar que un producto o componente de producto satisface su uso previsto en el entorno previsto. VINCIT Página 119 de 134 ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI GLOSARIO Aceptación [Acceptance] Acuerdo formal que indica que un Servicio de TI, Proceso, Plan, u otro Entregable se han completado, es preciso, Confiable y cumple con los Requisitos especificados. Normalmente la Aceptación es precedida por una Evaluación o Prueba y es requerida antes de proceder con la siguiente fase de un Proyecto o Proceso. Actividad [Activity] Un conjunto de acciones diseñadas para alcanzar un resultado específico. Normalmente, las Actividades se definen como parte de Procesos o Planes, y se documentan en Procedimientos. Activo [Asset] Cualquier Recurso o Capacidad. Los Activos de un Proveedor de Servicio incluyen todo aquello que se pueda atribuir a la entrega del Servicio. Los Activos pueden ser de los siguientes tipos: Administrativos, Organizativos, de Proceso, de Conocimiento, Personas, Información, Aplicaciones, Infraestructura, y de Capital. Alcance [Scope] El límite, o grado, al que un Procedimiento de Proceso, Certificación, Contrato, etc. se aplica. Por ejemplo, el Alcance de la Gestión de Cambio puede incluir todos los Servicios TI Vivos y relatar Elementos de Configuración, el Alcance de un Certificado ISO/IEC 20000 puede incluir todos los Servicios de TI implementados desde un centro de datos en cuestión. Aplicación [Application] Programa que provee Funciones requeridas por un Servicio TI. Cada Aplicación podría ser parte de más de un Servicio TI. Una Aplicación se puede ejecutar en uno o más Servidores o Clientes. Ver Gestión de Aplicaciones, Portafolio de Aplicaciones. Auditoría [Audit] Inspección formal para verificar si un Estándar o un conjunto de Guías se está siguiendo, que sus Registros son precisos, o que las metas de Eficiencia y Efectividad se están cumpliendo. Una Auditoría la puede realizar tanto un grupo interno como uno externo Ver Certificación, Evaluación. British Standards Institution [British Standards Institution] (BSI) Organización de Estándares Nacionales del Reino Unido. Es responsable de crear y mantener los Estándares británicos. Bucle de Control de la Monitorización [Monitor Control Loop] BO NI A LA OM R Monitorización de la salida de una Tarea, Proceso, Servicio de TI o Elemento de Configuración; comparando dicha salida con un patrón predefinido; y tomando las acciones apropiadas en base a esta comparación. VINCIT Página 120 de 134 ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI Buena Práctica [Best Practice] Actividades o Procesos que se han usado con éxito por más de una Organización. ITIL es un ejemplo de Buenas Prácticas. Calidad [Quality] Característica de un producto, Servicio o Proceso para proporcionar su propio valor. Por ejemplo, un Componente hardware puede ser considerado de alta Calidad si rinde según lo esperado y proporciona la Fiabilidad requerida. La Calidad de un Proceso requiere la capacidad para medir su Eficacia y Eficiencia, o incluso para mejorarlas si resultase necesario. Ver también Sistema de Gestión de Calidad. Capacidad [Capacity] Rendimiento máximo que se puede obtener de un Elemento de Configuración o Servicio de TI en el cumplimiento de los Objetivos de Nivel de Servicio acordados. Para algunos tipos de CI, la Capacidad puede ser el tamaño o el volumen, por ejemplo en una unidad de disco. Certificación [Certification] Emisión de un certificado que acredita la Conformidad con un Estándar. La Certificación incluye una Auditoría formal realizada por un organismo independiente y Acreditado. El término Certificación también se usa para denotar la concesión de un certificado que acredita que una persona ha logrado una cualificación determinada. Ciclo de Vida [Lifecycle] Las diversas fases en la vida de un Servicio de TI, Elemento de Configuración, Incidente, Problema, Cambio etc. El Ciclo de Vida define las Categorías de cada Estado y las transiciones de Estado permitidas. Por ejemplo: - El Ciclo de Vida de una Aplicación incluye Requisitos, Diseñar, Construir, Desplegar, Operar, Optimizar. - El Ciclo de Vida Expandido del Incidente incluye Detectar, Responder, Diagnosticar, Reparar, Recuperar, Restaurar. - El Ciclo de Vida de un Servidor puede incluir: Pedido, Recibido, En Prueba, Real, Eliminado etc. Ciclo de Vida de Gestión del Servicio [Service Management Lifecycle] A BO LA NI Página 121 de 134 OM R Aproximación a la Gestión del Servicio de TI que pone énfasis la importancia de la coordinación y el Control a través de las diferentes Funciones, Procesos y Sistemas necesarios para gestionar el Ciclo de Vida total de los Servicios de TI. La aproximación del Ciclo de Vida de la Gestión del Servicio incluye la Estrategia, Diseño, Transición, Operación y Mejora Continua de los Servicios de TI. VINCIT ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI Cliente [Client] Término genérico que describe al Negocio o Cliente de Negocio. Por ejemplo Gestor de Clientes podría ser usado como sinónimo de Gerente de Cuenta. El término cliente también se usa para definir: - Un ordenador usado directamente por un Usuario, como por ejemplo un PC, un portátil, o una Estación de Trabajo - Parte de una Aplicación Cliente-Servidor que interactúa directamente con el Usuario. Por ejemplo un cliente de correo electrónico. Cliente [Customer] Alguien que compra bienes o Servicios. El Cliente de un Proveedor de Servicios TI es la persona o grupo que define y acuerda el Objetivo de Nivel de Servicio. El término Cliente –customer- es también informalmente usado para Usuario, por ejemplo: "Esta es una Organización focalizada en el Usuario". Componente [Component] Término genérico usado para definir una parte de algo más complejo. Por ejemplo, un Sistema de computación puede ser un Componente de un Servicio de TI, una Aplicación puede ser un Componente de una Unidad de Entrega. Los Componentes que necesitan ser gestionados son los Elementos de Configuración. Contrato [Contract] Un Acuerdo legalmente obligatorio entre dos o más partes. Control [Control] Un medio de gestión de Riesgo, asegurando que el Objetivo de Negocio es alcanzado, o asegurando que un Proceso es seguido. Ejemplos de Controles incluyen Políticas, Procedimientos, Roles, RAID, door-locks etc. Un control es llamado, algunas veces, Contramedida o medida de seguridad. Control también es un medio de gestionar el uso o comportamiento de un Elemento de Configuración, Sistema o Servicio TI. Declaración de requerimientos [Statement of requirements] Documento que contiene todos los Requerimientos para la compra de un producto o para un Servicio de TI nuevo o cambiado. Dependencia [Dependency] La resistencia directa o indirecta de un Proceso o Actividad sobre otro. Desarrollo [Development] A BO LA NI Página 122 de 134 OM R Proceso responsable de crear o modificar un Servicio TI o Aplicación. También usado para referirse al Rol o grupo a cargo del trabajo de Desarrollo. VINCIT ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI Efectividad [Effectiveness] Una medida de si los Objetivos de un Proceso, Servicio o Actividad han sido alcanzados. Un Efectivo Proceso o Actividad es uno que alcanza sus Objetivos acordados. Eficiencia [Efficiency] Una medida de si el correcto monto de recursos ha sido utilizado para la provisión de un Proceso, Servicio o Actividad. Un Eficiente Proceso alcanza sus Objetivos con el mínimo de cantidad de tiempo, dinero, gente u otros recursos. Ver KPI. Entorno [Environment] Un subconjunto de Infraestructura TI que es utilizada para un propósito particular. Por ejemplo: Entorno de Producción, Entorno de Prueba, Entorno de Desarrollo. Es posible para múltiples Entornos compartir Elementos de Configuración, por ejemplo Pruebas y Entornos de Producción pueden usar diferentes particiones en un único ordenador mainframe. También utilizado como un término de entorno físico para definir instalaciones, aire acondicionado, sistema eléctrico, etc. Entorno también es usado como término genérico para definir condiciones externas que influyen o afectan algo. Entregable [Deliverable] Algo que debe ser provisto para cumplir un compromiso en un Acuerdo de Nivel de Servicio o un Contrato. Entregable también es usado en forma más informal para una salida planeada de cualquier Proceso. Especificación [Specification] Definición formal de Requerimientos. Una Especificación puede usarse para definir Requerimientos Técnicos u Operacionales, y puede ser interna o externa. Muchos Estándares públicos consisten en un Código de Prácticas y una Especificación. La Especificación define el Estándar frente al que una Organización puede ser Auditada. Estándar [Standard] Requerimiento obligatorio. Por ejemplo ISO/IEC 20000 (estándar internacional), una configuración de seguridad interna estándar para Unix, o un estándar gubernamental acerca de como mantenerlos Registros financieros. El término estándar también se emplea para definir un Código de Prácticas o Especificación publicada por una Organización de Estándares como ISO o BSI. Estimación [Estimation] Uso de la experiencia para proporcionar una valor aproximados para una Métrica o Coste. La Estimación también se usa en Gestión de la Capacidad y Disponibilidad como el más económico y menos preciso método de Modelización. Evaluación [Evaluation] A BO LA NI Página 123 de 134 OM R Proceso responsable de evaluar un Servicio de TI nuevo o cambiado para asegurar que los Riesgos han sido gestionados y para ayudar a determinar si proceder con el Cambio. La evaluación es también usada para comparar el Resultado medio actual con el pretendido, o comparar una alternativa con otra. VINCIT ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI Evento [Event] Un cambio de estado significativo para la cuestión de un Elemento de Configuración o un Servicio de TI. El término Evento también se usa como Alerta o notificación creada por un Servicio de TI, Elemento de Configuración o herramienta de Monitorización. Los Eventos requieren normalmente que el personal de Operaciones de TI tome acciones, y a menudo conllevan el registro de Incidentes. Función [Function] Un equipo o grupo de personas y las herramientas que usan para llevar a cabo uno o más Procesos o Actividades. Por ejemplo el Centro de Servicio al Usuario. El término Función también tiene otros dos significados - El propósito de un Elemento de Configuración, Persona, Equipo, Proceso o Servicio de TI. Por ejemplo una Función del Servicio de Correo Electrónico puede ser almacenar y reenviar correos, una Función de un Proceso de Negocio puede ser enviar bienes a Clientes. - Realizar su propósito correctamente. “El ordenador funciona”. Gestión de la Configuración [Configuration Management] Proceso responsable de mantener información sobre los Elementos de Configuración requeridos para la provisión de un Servicio de TI, incluyendo las Relaciones entre ellos. Esta información se gestiona durante todo el Ciclo de Vida del CI. La Gestión de la Configuración forma parte de un Activo del Servicio global y del Proceso de Gestión de la Configuración. Gestión de la Seguridad de Información [Information Security Management] (ISM) (Diseño del Servicio) Proceso que asegura la Confidencialidad, Integridad y Disponibilidad de los Activos de una Organización, información, datos y Servicios de TI. La Gestión de la Seguridad de la información forma parte normalmente de la Gestión de la Seguridad de la Organización, la cual tiene un ámbito más amplio que las del Proveedor de Servicio de TI e incluye accesos a edificios, llamadas de teléfonos, etc para toda la Organización. Gestión de Problemas [Problem Management] Es el Proceso responsable del la gestión del Ciclo de Vida de todos los Problemas. El principal Objetivo de la Gestión de Problemas es la prevención de Incidentes, al igual que la reducción del Impacto de aquellos Incidentes que no haya sido posible prevenir. Grupo de Soporte [Support Group] Un grupo de personas con capacidades técnicas. Los grupos de soporte proporcionan el Soporte Técnico necesitado por todo el Proceso de Gestión del Servicio de TI. Ver Gestión Técnica. Habilidad [Capability] A BO LA NI Página 124 de 134 OM R Capacidad de una Organización, persona, Proceso, Aplicación, Elemento de Configuración o Servicio de TI para el desarrollo de una Actividad. Las Habilidades son Activos intangibles de una Organización. Ver Recurso. VINCIT ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI Impacto [Impact] Una medida del efecto de un Incidente, Problema o Cambio en los Procesos de Negocio. El Impacto está a menudo basado en como serán afectados los Niveles de Servicio. El Impacto y la Urgencia se emplean para asignar la Prioridad. Incidente [Incident] Interrupción no planificada de un Servicio de TI o reducción en la Calidad de un Servicio de TI. También lo es el Fallo de un Elemento de Configuración que no ha impactado todavía en el Servicio. Por ejemplo el Fallo de uno de los discos de un “mirror”. ISO 9000 Término genérico que se refiere a un conjunto de Estándares y Directrices para los Sistemas de Gestión de Calidad. ISO 9001 Estándar internacional para los Sistemas de Gestión de Calidad. Ver ISO 9000, Estándar. ISO/IEC 17799 Código de Práctica ISO para la Gestión de la Seguridad de la Información. Ver Estándar. ISO/IEC 20000 Especificación ISO y Código de Práctica para la Gestión de los Servicios de TI. ISO/IEC 20000 está alineado con las Mejores Prácticas ITIL. ISO/IEC 27001 Especificación ISO para la Gestión de la Seguridad de la Información. El Código de Práctica correspondiente es ISO/IEC 17799. Ver Estándar. ITIL [ITIL] Conjunto de Mejores Prácticas para la Gestión de Servicios de TI. ITIL es propiedad de la OGC y consiste en una serie de publicaciones que aconsejan sobre la provisión de Servicios de TI de Calidad, y sobre los Procesos y las instalaciones necesarias para soportarlos. Línea Base [Baseline] Una Referencia que se usa como punto de marca. Por ejemplo: - Una Línea Base de ITSM se puede usar como punto de partida para medir el resultado de un Plan de Mejora del Servicio - Una Línea Base de Rendimiento se puede usar para medir cambios en el Rendimiento de un Servicio TI en un periodo de tiempo. BO NI A LA OM Página 125 de 134 R - Una Línea Base de la Gestión de la Configuración puede servir para restablecer la Infraestructura TI en una Configuración conocida en caso de un fallo de un Cambio o de un Entregable VINCIT ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI Madurez [Maturity] Medida de la Fiabilidad, Eficiencia y Efectividad de un Proceso, Función, Organización etc. Los Procesos y Funciones más maduros están íntimamente alineados a los Objetivos de Negocio y a la Estrategia, y están soportados por un marco de trabajo para la mejora continua. Mantenibilidad [Maintainability] Medida de cómo de rápida y Efectivamente se puede restaurar un Elemento de Configuración o Servicio de TI a su funcionamiento normal después de un Fallo. La Mantenibilidad se mide y reporta frecuentemente como MTRS. El término Mantenibilidad se emplea también en el contexto de Desarrollo de Software o Desarrollo de Servicios de TI refiriéndose a la capacidad de ser Cambiado o Reparado fácilmente. Métrica [Metric] Algo que se mide y reporta para ayudar a gestionar un Proceso, Servicio de TI o Actividad. Ver KPI. Modelo [Model] Representación de un Sistema, Proceso, Servicio de TI, Elemento de Configuración etc. empleado para ayudar a entender o predecir comportamientos futuros. Modelo de Cambio [Change Model] (Transición del Servicio) Modo repetible de gestionar una Categoría particular de Cambio. Un Modelo de Cambio enumera los pasos específicos predefinidos que deberán ser seguidos para un Cambio perteneciente a esa Categoría. Los Modelos de Cambio deben ser muy simples, y que no requieran de aprobación (ej. Cambio de contraseña) o pueden ser muy complejos y que incluyan muchos pasos que requieran de aprobación (ej. Despliegue de una nueva versión de software). Ver Cambio Estándar, Comité de Cambios. Modelo de Integración de Madurez de la Capacidad [Capability Maturity Model Integration] (CMMI) (Mejora Continua del Servicio) El Modelo de Integración de Madurez de la Capacidad (CMMI) es una aproximación a la mejora de procesos desarrollada por el Software Engineering Institute (SEI) de la Carnegie Melon University. CMMI provee a las organizaciones de los elementos esenciales para la efectividad de los procesos. El modelo puede ser usado para habilitar la mejora de procesos a lo largo de un proyecto, una división, o una organización completa. CMMI ayuda a integrar funciones de la organización tradicionalmente separadas, fijar prioridades y objetivos en la mejora de procesos, guías para la calidad de los procesos, y proporcionar un punto de referencia para la evaluación de los procesos en curso. Modelo de Madurez de la Capacidad [Capability Maturity Model] (CMM) A BO LA NI Página 126 de 134 OM R (Mejora Continua del Servicio) El Modelo de Madurez de la Capacidad para el Software (también conocido como CMM y SW-CMM) es un modelo usado con el objeto de identificar las Mejores Prácticas para ayudar a incrementar la Madurez del Proceso. CMM fue desarrollado en el Software Engineering Institute (SEI) de la Carnegie Mellon University. En el año 2000, SW-CMM se actualizó como CMMI® (Modelo de Integración de Madurez de la Capacidad). El SEI ha dejado de mantener el modelo SW-CMM, sus métodos asociados de evaluación, y material de formación. VINCIT ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI Monitorización [Monitoring] Observación repetida de un Elemento de Configuración, Servicio de TI o Proceso para detectar Eventos y asegurarse de que se conoce el estado actual. Objetivo [Objective] El propósito o la intención definidos de un Proceso, una Actividad o una Organización en su totalidad. Los Objetivos se expresan generalmente como metas medibles. El término Objetivo se usa también de manera informal para querer decir Requisito. Ver Salida. Operaciones de TI [IT Operations] Actividades desempeñadas por Control de Operaciones de TI, incluyendo Gestión de Consolas, Planificación de Tareas, Backup y Restauración, y Gestión de Salida e Impresión. Operaciones de TI se utiliza también como sinónimo de Operación del Servicio. Optimizar [Optimise] Revisar, Planificar y solicitar Cambios orientados a la obtención de la máxima Eficacia y Eficiencia para un Proceso, Elemento de Configuración, Aplicación, etc. Organización [Organisation] Empresa, entidad legal o cualquier otra institución. Algunos ejemplos de Organizaciones que no son Empresas pueden ser la Organización Internacional de Estándares (ISO) o itSMF. El término Organización se utiliza también para referirse a cualquier entidad que disponga de Personal, Recursos y Presupuesto, como puede ser un Proyecto o una Unidad de Negocio. Organización Internacional de Estandarización [International Organization for Standardization] (ISO) La Organización Internacional de Estandarización (ISO) es el mayor desarrollador de Estándares del mundo. ISO es una organización no gubernamental que constituye una red de los Institutos de Estandarización nacionales de 156 países. Outsourcing [Outsourcing] Utilización de un Proveedor de Servicios Externo para la gestión de Servicios de TI. Ver también Service Sourcing, Proveedor de Servicio de Tipo III. PMBOK Estándar de Gestión de Proyectos mantenido y publicado por el Project Management Institute. PMBOK son las siglas de Project Management Body of Knowledge (Cuerpo de Conocimiento de Gestión de Proyectos). Política [Policy] A BO LA NI Página 127 de 134 OM R Documento formal que contiene las intenciones y expectativas de gestión. Las Políticas se utilizan para dirigir las decisiones, y asegurar un desarrollo e implementación coherente y apropiado de los Procesos, Estándares, Roles, Actividades, Infraestructura de TI, etc. VINCIT ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI Prioridad [Priority] (Transición del Servicio) (Operación del Servicio) Categoría empleada para identificar la importancia relativa de un Incidente, Problema o Cambio. La Prioridad se basa en el Impacto y la Urgencia, y es utilizada para identificar los plazos requeridos para la realización de las diferentes acciones. Por ejemplo, el SLA podría indicar que los Incidentes de Prioridad 2 deben ser resueltos en menos de 12 horas. Problema [Problem] (Operación del Servicio) Causa de uno o más Incidentes. En el momento en el que se crea el Registro del Problema, no es frecuente conocer su causa, por lo que es necesario realizar su investigación mediante el Proceso de Gestión de Problemas. Procedimiento [Procedure] Documento que contiene los pasos que se deben seguir para la realización de una determinada Actividad. Los Procedimientos se definen como partes de Procesos. Proceso [Process] Conjunto estructurado de Actividades diseñado para la consecución de un Objetivo determinado. Los Procesos requieren de una o más entradas y producen una serie de salidas, ambas previamente definidas. Un Proceso suele incorporar la definición de los Roles que intervienen, las responsabilidades, herramientas y Controles de gestión necesarios para obtener las salidas de forma eficaz. El Proceso podrá definir las Políticas, Estándares, Guías de Actuación, Actividades, y las Instrucciones de Trabajo que fueran necesarias. Proceso de Negocio [Business Process] Un Proceso que le pertenece y que lo conduce el Negocio. Un Proceso de Negocio contribuye a la entrega de un producto o Servicio para un Cliente del Negocio. Por ejemplo, un revendedor podría tener un Proceso de compra que ayuda a entregar Servicios a sus Clientes del Negocio. Muchos de los Procesos de Negocio están basados en Servicios TI. Programa [Programme] Conjunto de Proyectos y Actividades planificadas y gestionadas como una unidad para la obtención de unos Objetivos y Entregables comunes. Propietario de Servicio [Service Owner] Rol responsable de la entrega de un determinado Servicio de TI. Proveedor [Supplier] A BO LA NI Página 128 de 134 OM R Tercero responsable de suministrar bienes o Servicios que son necesarios para proporcionar Servicios de TI. Ejemplos de proveedores incluyen los vendedores de hardware y software, proveedores de redes y telecomunicaciones y Organizaciones de Outsourcing. Ver Contrato de Soporte, Cadena de Suministro. VINCIT ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI Proyecto [Project] Se trata de una Organización temporal, compuesta por personal y los Activos requeridos para la obtención de los Objetivos y Entregables necesarios. Cada Proyecto tiene un Ciclo de Vida que típicamente incluye Inicio, Planificación, Ejecución, Cierre etc. Prueba [Test] Una Actividad que verifica que un Elemento de Configuración, Servicio TI, Proceso, etc. cumple con sus Especificaciones o Requerimientos acordados. Ver Validación y Prueba del Servicio. Aceptación. Recurso [Resource] Término genérico que incluye Infraestructura de TI, personal, dinero o cualquier otra cosa que pueda ayudar a entregar un Servicio de TI. Se considera a los Recursos como el Activo de una Organización. Ver Capacidad, Activos de Servicio. Registro [Record] Un Documento que contiene el resultado u otro tipo de salida desde un Proceso o Actividad. Los registros son la evidencia de que una Actividad tuvo lugar, y podría ser en papel o formato electrónico. Por ejemplo, un informe de Auditoría, un Registro de Incidente, o los minutos de una reunión. Rendimiento [Performance] Medida de la respuesta obtenida por un Sistema, persona, equipo, Proceso, o Servicio TI. Requisito [Requirement] Una declaración formal de lo que se necesita. Por ejemplo: un Requisito de Nivel de Servicio, un Requisito de Proyecto, o los Entregables requeridos para un Proceso. Ver Declaración de Requisitos. Resolución [Resolution] Acción tomada para reparar la Causa Raíz de un Incidente o Problema o para implementar una Alternativa. En ISO/IEC 20000, el Proceso de Resolución es el grupo de Procesos que incluye la Gestión de Problemas e Incidentes. Restauración [Restore] Toma de acción para restaurar un Servicio de TI a los Usuarios tras Reparar y Recuperarse de un Incidente. Este es el Objetivo Primario de la Gestión de Incidentes. Revisión [Review] llevan a cabo en puntos predefinidos en el ciclo de vida, y especialmente tras la Clausura. El propósito de una Revisión es asegurarse de que todos los Entregables han sido provistos, e identificar oportunidades de mejora. Riesgo [Risk] Un posible Evento que podría causar daño o pérdidas, o afectar la habilidad de alcanzar Objetivos. Un Riesgo es medido por la probabilidad de una Amenaza, la Vulnerabilidad del Activo a esa Amenaza, y por el Impacto que tendría en caso que ocurriera. BO NI A LA OM R Página 129 de 134 VINCIT ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI Servicio [Service] Un medio de entregar valor a los Clientes facilitando Resultados que los Clientes quieren lograr sin la propiedad de Costes y Riesgos específicos. Servicio de Infraestructura [Infrastructure Service] Un Servicio de TI que no es usado directamente por el Negocio, pero que es requerido por el Proveedor de Servicio de TI de modo que pueda proporcionar otros Servicios de TI. Por ejemplo Servicios de Directorio, servicios de nombrado o servicios de comunicación. Servicio de Soporte [Supporting Service] Un Servicio que posibilita o mejora un Servicio Principal. Por ejemplo, un Servicio de Directorio o un Servicio de Respaldo. Servicio de TI [IT Service] Servicio proporcionado a uno o más Clientes por un Proveedor de Servicios de TI. Un Servicio de TI se basa en el uso de las Tecnologías de la Información y soporta los Procesos de Negocio del Cliente. Un Servicio de TI se compone de una combinación de personas, Procesos y tecnología y debería estar definido en un Acuerdo de Nivel de Servicio. Transacción [Transaction] Una Función discreta realizada por un Servicio de TI. Por ejemplo, transferir dinero de una cuenta bancaria a otra. Un transacción simple puede involucrar numerosas adiciones, borrados y modificaciones de datos. Bien todas se completan con éxito o ninguna es realizada. Transición [Transition] Un cambio de estado, correspondiente al movimiento de un Servicio de TI u otro Elemento de Configuración de un estado en su Ciclo de Vida a otro. Utilidad [Utility] Funcionalidad ofrecida por un Producto o Servicio para satisfacer una necesidad específica. La utilidad es a menudo resumida en “lo que hace”. Validación [Validation] Una Actividad que asegura que un Servicio de TI, Proceso, Plan u otro Entregable nuevo o cambiado satisface las necesidades del Negocio. La Validación asegura que los Requerimientos de Negocio son satisfechos incluso aunque estos sean cambiados desde su diseño original. Valoración del Servicio [Service Valuation] A BO LA NI Página 130 de 134 OM R Medición del Coste total que supone la prestación de un Servicio de TI, y el valor total que tiene ese Servicio de TI para el Negocio. La Valoración del Servicio se usa para facilitar el acuerdo acerca del valor del Servicio de TI entre el Negocio y el Proveedor de Servicios de TI. VINCIT ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI BIBLIOGRAFÍA Competisoft: mejora de procesos software para pequeñas y medianas empresas y proyectos Autor: Oktaba, Hanna Título: UNE 71044: 1999 Tecnología de la información. Procesos del ciclo de vida del software Autor: Sin autor Título: Control de procesos: implementación de una plataforma hardware/software para la experimentación en control digital directo, controladores PID y Fuzzy. Autor: Castillo Pérez, Esteban del Título: Entender ITIL V3: normas y mejores prácticas para avanzar hacia ISO 20000. Autor: Quesnel, J. Título: ITIL Autor: Shuja, Ahmad K. Título: ITIL release management Autor: Howard, Dave Título: ITIL lifecycle publication suite (Spanish translation) books Autor: Sin autor BO NI A LA OM R Título: VINCIT Página 131 de 134 ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI Título: Information security management with ITIL v3 Autor: Cazemier, Jacques A. Título: Guía de los fundamentos de la dirección de proyectos:(standards committee del PMI) Autor: Sin autor Título: Project management, planning and control:managing manufacturing projects to PMI, APM and BSI standards Autor: Lester, Albert Título: PMI-001 Questions and answer Autor: Sin autor Título: The PMI compendium of project management practices Autor: Sin autor Título: Process improvement and CMMI for systems and software Autor: Kenett, Ron S Título: CMMI:guía para la integración de procesos y mantenimiento de productos Autor: Chrissis, Mary Beth Título: Practical insight into CMMI Autor: Kasse, Tim construction and A BO LA NI Página 132 de 134 OM R engineering, VINCIT ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI CMMI:Capability Maturity Model Integration : a process improvement approach Autor: Kneuper, Ralf Título: Process improvement with CMMI(R) V1.2 and ISO standards Autor: Mutafelija, Boris Título: Interpreting the CMMI:a process improvement approach Autor: Margaret, Kulpa K. Título: Project management success with CMMI Autor: Persse, James R. Título: CMMI for outsourcing:guidelines for software, systems, and IT acquisition Autor: Hofmann, Hubert BO NI A LA OM R Título: VINCIT Página 133 de 134 ADAMS TUTORIAL DE METODOLOGÍAS DE TRABAJO: ITIL, PMI Y CMMI LINKS http://www.itil.org/en/vomkennen/itil/index.php http://www.itil-officialsite.com/home/home.asp http://www.itilcommunity.com/ http://www.itsmf.es/ http://es.wikipedia.org/wiki/Information_Technology_Infrastructure_Library ------------------------------------------------------------http://www.pmi.org/ http://www.pmi-mad.org/pmimsc/ http://es.wikipedia.org/wiki/Project_Management_Institute -----------------------------------------------------http://www.sei.cmu.edu/cmmi/ http://en.wikipedia.org/wiki/Capability_Maturity_Model_Integration ---------------------------------------------------http://www.liderdeproyecto.com/ BO NI A LA OM R http://www.ingenierosoftware.com/ VINCIT Página 134 de 134 ADAMS
