MANUAL DE REGLAS DE NEGOCIO ASOCIADAS AL PROCESO DESARROLLO DEL SERVICIO DE TI PERTENECIENTES AL MACRO PROCESO GESTIÓN DE TECNOLOGÍA DE INFORMACIÓN

Transcripción

1 Página 1 de 15 MANUAL DE REGLAS DE NEGOCIO ASOCIADAS AL PROCESO DESARROLLO DEL SERVICIO DE TI PERTENECIENTES AL MACRO PROCESO GESTIÓN DE TECNOLOGÍA DE INFORMACIÓN VERSIÓN 001 Junio 2012 Página 1

2 Página 2 de 15 Tabla de contenido INTRODUCCIÓN OBJETIVO GLOSARIO DE TÉRMINOS 1 REGLAS DE NEGOCIO PARA EL PROCESO DESARROLLO DEL SERVICIO DE TI Reglas relacionadas con la construcción, adquisición e integración del Servicio Reglas relacionadas con pruebas y validación Reglas relacionadas con liberación y estabilización de versiones Reglas relacionadas con gestión de cambios Reglas relacionadas con gestión de la configuración Página 2

3 Página 3 de 15 INTRODUCCIÓN Acorde con el Modelo Normativo Interno propuesto para las Empresas, mediante el cual se busca optimizar el manejo de la información, la efectividad en la toma de decisiones y facilitar la operación, corresponde al Subdirector de Tecnología de Información (STI-EPM) dictar las reglas de negocio para la Gestión de Tecnología de Información contando con una normativa interna que indique como se deben operar, sin desconocer las normas externas que impactan los mismos, es decir, tomando como referente las disposiciones legales y estatutarias de los sistemas y modelos de gestión. El Modelo Normativo Interno para su aplicación tiene en cuenta dos manuales, el primero contiene la política aprobada por la Junta Directiva de EPM y los lineamientos dictados por el Gerente General; el segundo manual relaciona las reglas de negocio definidas por el responsable del proceso que detallan o establecen la operación del proceso. Como parte del primer manual, la Junta Directiva en su sesión de febrero 01 de 2011, según Acta 1528 definió la política para la Gestión de Tecnología de Información en los siguientes términos: En EPM, la Gestión de Tecnología de Información habilita a la empresa para que disponga de la información requerida por los grupos de interés y se adapte oportunamente a los cambios generados por el entorno, sus procesos y la visión de negocio, usando como referencia la arquitectura empresarial y operando bajo un modelo de prestación de servicios con las mejores prácticas de mercado como una forma de apalancar la sostenibilidad y el crecimiento del negocio. Paso siguiente, el Gerente General el 31 de enero de 2012, según Decreto 1866 definió el Manual de lineamientos asociados al macroproceso gestión de tecnología de información, y como objetivo fundamental Establecer los Lineamientos Asociados al Macro proceso Gestión de Tecnología de Información, con el propósito de guiar la toma de decisiones en el marco de tecnología de información (TI en este documento) y la optimización y aprovechamiento de sus recursos. Y como parte del segundo manual, Bajo el entendido de que los lineamientos están en continua evolución, la Subdirección Tecnología de Información (STI-EPM) tiene, de acuerdo con el marco de gobierno definido para el Grupo Empresarial EPM (GE-EPM), la responsabilidad de crear los mecanismos de actualización y divulgación apropiados que permitan publicar y desarrollar estos lineamientos a través de reglas de negocio, Página 3

4 Página 4 de 15 procedimientos e instructivos., así como se contempló en el decreto 1866 de enero 31 de Este documento contiene el Manual de Reglas de Negocio asociadas a los lineamientos del proceso Desarrollo del servicio de TI y brinda elementos de referencia que facilitan la orientación y actuación de todos los servidores de EPM. OBJETIVO Establecer las Reglas de Negocio asociadas a los lineamientos del proceso Desarrollo del servicio de TI, con el propósito de establecer parámetros que califican y cuantifican criterios específicos para la actuación del personal en la operación de dichos procesos. GLOSARIO DE TÉRMINOS A continuación, se presenta la definición de los términos de TI que facilitan la comprensión del presente documento. CICLO DE VIDA DE SOFTWARE: Es un período de tiempo que se inicia cuando se concibe el producto software y finaliza cuando el producto software se retira de uso. Típicamente incluye: fase de requisitos, fase de diseño, fase de implementación, fase de pruebas, fase de instalación y liberación, fase de operación y mantención, y algunas veces, fase de retiro. Estas fases se pueden superponer o se puede ejecutar iterativamente. ARQUITECTURA DE UN SISTEMA SOFTWARE: La arquitectura de un sistema es el conjunto de decisiones significativas sobre la organización del sistema software; la selección de elementos estructurales y sus interfaces a través de los cuales se constituye el sistema; el comportamiento del sistema, como se especifica en las colaboraciones de esos elementos; la composición de esos elementos estructurales y de comportamiento en subsistemas progresivamente más grandes; el estilo arquitectónico que guía esta organización: los elementos estáticos y dinámicos y sus interfaces, su colaboración y su composición. SISTEMA SOFTWARE: Un sistema software es una colección de subsistemas organizados para lograr un propósito descrito por un conjunto de modelos que representan diferentes puntos de vista del sistema. Desde un enfoque de ciclo de vida, un sistema representa el Página 4

5 Página 5 de 15 elemento que se está desarrollando, visto desde diferentes dimensiones mediante diferentes modelos presentados en forma de diagramas. SUBSISTEMA: Un subsistema es un grupo de elementos, algunos de los cuales constituyen una especificación del comportamiento ofrecido por los otros subsistemas. MODELO: Un modelo es una abstracción semánticamente cerrada de un sistema, es decir, representa una simplificación completa y autoconsciente de la realidad, creado para comprender mejor el sistema, es decir, representa una simplificación completa y autoconsciente de la realidad, creado para comprender el sistema. VISTA: Una vista es una proyección de la organización y estructura de un modelo de un sistema en el contexto de su arquitectura. DIAGRAMA: Es la representación gráfica de un conjunto de elementos, el cual normalmente se muestra como un grafo de nodos (elementos) y arcos (relaciones). DIAGRAMAS ESTRUCTURALES DE UN SISTEMA SOFTWARE: Existen para especificar, construir y documentar los aspectos estáticos de un sistema software. Los aspectos estáticos de un sistema representan su esqueleto y su andamiaje, es decir, incluyen la existencia y ubicación de clases, interfaces, colaboraciones, componentes y nodos. Los aspectos estáticos de un sistema se representan mediante los diagramas siguientes: diagrama de clases, diagrama de objetos, diagrama de componentes, diagramas de despliegue. DIAGRAMA DE CLASES: Un diagrama de de clases presenta un conjunto de clases, interfaces y colaboraciones, y las relaciones entre ellas. Se utilizan para describir la vista de diseño estática o la vista de procesos estática de un sistema. Los diagramas de clase que incluyen clases activas se utilizan para cubrir la vista de procesos estática de un sistema. Los diagramas de clases son los diagramas más comunes en el modelado de sistemas orientados por objetos. Por último, un sistema se puede estructurar como un conjunto de subsistemas, donde un diagrama de subsistemas como un conjunto de clases del sistema. DIAGRAMAS DE OBJETOS: Un diagrama de objetos representa un conjunto de objetos y sus relaciones. Se utiliza para describir estructuras de datos, instantáneas de las instancias de los elementos que se encuentran en los diagramas de clases. Los diagramas de objetos cubren la Página 5

6 Página 6 de 15 vista de diseño estática o la vista de procesos estática de un sistema al igual que los diagramas de clase, pero desde la perspectiva de casos reales o prototípicos. DIAGRAMAS DE COMPONENTES: Un diagrama de componentes muestra un conjunto de componentes y sus relaciones. Los diagramas de componentes se utilizan para describir la vista de implementación estática de un sistema. Los diagramas de componentes se relacionan con los diagramas de clases en que un componente normalmente se corresponde con una o más clases, interfaces o colaboraciones. DIAGRAMAS DE DESPLIEGUE: Un diagrama de despliegue muestra un conjunto de nodos y sus relaciones. Los diagramas de despliegue se utilizan para describir la vista de despliegue estática de una arquitectura. Los diagramas de despliegue se relacionan con los diagramas de componentes en que un nodo normalmente incluye uno o más componentes. DIAGRAMAS DE COMPORTAMIENTO DE UN SISTEMA SOFTWARE: Se emplean para visualizar, especificar, construir y documentar los aspectos dinámicos de un sistema software. Los aspectos dinámicos de un sistema software se pueden ver como aquellos que representan sus partes mutables. Los aspectos dinámicos de un sistema software involucran cosas tales como el flujo de mensajes entre los componentes del sistema a lo largo del tiempo y el movimiento físico de los componentes en una red de telecomunicaciones. Los componentes dinámicos de un sistema software se representan mediante los diagramas siguientes: diagramas de casos de uso, diagramas de secuencia, diagramas de colaboración, diagramas de estados, diagramas de actividades. DIAGRAMAS DE CASOS DE USO: Un diagrama de casos de uso representa un conjunto de casos de uso y actores (un tipo especial de clase) y sus relaciones. Los diagramas de casos de uso se utilizan para describir la vista de casos de uso estática de un sistema. Los diagramas de casos de uso son especialmente importantes para organizar y modelar los comportamientos de un sistema. DIAGRAMAS DE INTERACCIÓN: Es el nombre que recibe el conjunto conformado por los diagramas de secuencia y diagramas de colaboración. DIAGRAMAS DE SECUENCIA: Un diagrama de secuencia es un diagrama de interacción que resalta la ordenación temporal de los mensajes. El diagrama de secuencia presenta el conjunto de objetos y los mensajes enviados y recibidos por ellos. Los objetos suelen ser Página 6

7 Página 7 de 15 instancias con nombre o anónimas de clases, pero también pueden representar instancias de otros elementos, tales como colaboraciones, componentes y nodos. Los diagramas de secuencia se utilizan para describir la vista dinámica de un sistema. Los diagramas de secuencia y colaboración son isomorfos, es decir, se puede convertir el uno en el otro sin pérdida de información. DIAGRAMAS DE COLABORACIÓN: Un diagrama de colaboración es un diagrama de interacción que resalta la organización estructural de los objetos que envían y reciben mensajes. Un diagrama de colaboración muestra un conjunto de objetos, enlaces entre esos objetos y mensajes enviados y recibidos por esos objetos. Los objetos normalmente son instancias con nombre o anónimas de clase, pero también pueden representar instancias de otros elementos, como colaboraciones, componentes y nodos. Los diagramas de colaboración se utilizan para describir la vista dinámica de un sistema. Los diagramas de secuencia se utilizan para describir la vista dinámica de un sistema. Los diagramas de secuencia y colaboración son isomorfos, es decir, se puede convertir el uno en el otro sin pérdida de información. DIAGRAMAS DE ESTADOS: Un diagrama de estados representa una máquina de estados, constituida por estados, transiciones, eventos, actividades. Los diagramas de estados se utilizan para describir la vista dinámica del un sistema. Son especialmente importantes para modelar el comportamiento de una interfaz, una clase o una colaboración. Los diagramas de estado resaltan el comportamiento dirigido por eventos de un objeto, lo que es especialmente útil al modelar sistemas reactivos. Los diagramas de secuencia se utilizan para describir la vista dinámica de un sistema. Los diagramas de estado y actividades son isomorfos, es decir, se puede convertir el uno en el otro sin pérdida de información. DIAGRAMA DE ACTIVIDADES: Un diagrama de actividades muestra el flujo de actividades en un sistema. Una actividad muestra un conjunto de actividades, el flujo secuencial o ramificado de actividades y los objetos que actúan y sobre los que se actúa. Los diagramas de actividades se utilizan para ilustrar la vista dinámica de un sistema. Además, estos diagramas son especialmente importantes para modelar la función de un sistema, así como para resaltar el flujo de control entre objetos. Los diagramas de estado y actividades son isomorfos, es decir, se puede convertir el uno en el otro sin pérdida de información. Página 7

8 Página 8 de 15 1 REGLAS DE NEGOCIO PARA EL PROCESO DESARROLLO DEL SERVICIO DE TI. 1.1 Reglas relacionadas con la construcción, adquisición e integración del Servicio. Reutilización de componentes. Durante las fases de diseño y construcción de cualquier producto software se debe analizar y evaluar los componentes software que ya existen en el mercado o en el repositorio de componentes de TI de la organización, con el fin de determinar la validez de su integración al producto software. Para los componentes a reutilizar se deberá validar sus atributos funcionales y no funcionales mediante demostraciones, pruebas de concepto, pruebas de verificación y validación o cualquier otro procedimiento válido adoptado en la industria del software y que haya sido avalado por la OTI. Implementación del servicio de TI. Toda nueva versión, total o parcial, de cualquier producto software, que hace parte de los servicios de TI en el catálogo de servicios de TI de EPM, debe ser especificada, analizada, diseñada y construida conforme a las metodologías y las prácticas de ingeniería de software incorporadas en el modelo de procesos de TI de EPM. La especificación, el análisis, el diseño y la construcción del producto software se deben documentar en las plantillas y formatos definidos en los proceso de TI de EPM. Adicionalmente, se debe elaborar la respectiva documentación técnica, de instalación y de uso del producto software, las cuales apoyarán la evolución y mantención del producto software durante la operación del servicio de TI. Implantación de paquetes software suministrados por terceros. Se debe buscar conservar la funcionalidad nativa del paquete software. Las adaptaciones incorporadas al paquete software por el fabricante se deben realizar cumpliendo los estándares recomendados por el fabricante, de tal forma que se garantice la evolución de la versión adaptada a las nuevas versiones estándar del fabricante. Las adaptaciones realizadas por EPM al paquete software deben seguir las metodologías y las prácticas de ingeniería de software incorporadas en el modelo de procesos de TI de EPM. Pruebas unitarias y pruebas de integración para los desarrollos a la medida. Durante la fase de construcción del producto software se deberán realizar pruebas Página 8

9 Página 9 de 15 unitarias y las pruebas de integración, en los ambientes de desarrollo, para poder validar que los componentes, módulos y subsistemas se construyen, se integran y funcionan de acuerdo a la arquitectura del producto software. Pruebas de sistema y pruebas de aceptación. Todo producto software, que se adquiera o desarrolle, se deberá someter a pruebas del sistema y pruebas de aceptación antes de su despliegue en los ambientes de producción. Despliegue de la solución: Para el despliegue de la solución en los ambientes de desarrollo, pruebas y producción se debe elaborar la documentación que se requiera para configurar dichos ambientes. Capacitación en el uso de los servicios de TI: La Organización de Tecnología de Información de EPM apoyará a la Unidad Aprendizaje Organizacional en la organización, planeación y programación del entrenamiento y la capacitación a los usuarios finales, a los analistas funcionales y a otros interesados en el uso de las funcionalidades que ofrecen los diferentes servicios de TI desplegados en los ambientes de pruebas y producción. El entrenamiento y la capacitación lo podrá realizar personal vinculado a EPM o personal vinculado con proveedores externos de servicios de capacitación. 1.2 Reglas relacionadas con pruebas y validación. Pruebas: Toda solución que se dé a una iniciativa o requerimiento de servicio o de cambio, se debe someter a pruebas, y las pruebas deben validar el cumplimiento de los requisitos funcionales y no funcionales, así como las reglas de negocio y las restricciones técnicas. Niveles de pruebas: Toda nueva versión, total o parcial, de cualquier producto software, que hace parte de los servicios de TI en el catálogo de servicios de TI de EPM, debe ser sometida a pruebas tempranas, pruebas unitarias, pruebas de integración, pruebas del sistema y pruebas de aceptación antes de autorizar su liberación y despliegue en los ambientes de producción de EPM. Cada uno de estos niveles de pruebas tiene como objetivo verificar y validar, a través del ciclo de vida de desarrollo del servicio de TI, que los productos software cumplen los requisitos Página 9

10 Página 10 de 15 funcionales, los requisitos no funcionales, las reglas de negocio y las restricciones técnicas. Plan de pruebas: La planeación, el diseño y la ejecución de los diferentes niveles de pruebas se deben documentar en un plan de pruebas y las plantillas y formatos de diseño de las pruebas, los cuales se utilizarán para realizar las labores de seguimiento y control de las pruebas. Igualmente, todo plan de pruebas se debe elaborar a partir de una estrategia de pruebas centrada en solucionar los riesgos genéricos del producto software e incluirá, entre otros, los objetivos de pruebas, los tipos y las técnicas de pruebas, una estructura de desglose del trabajo, las tareas principales de pruebas, las estimaciones del esfuerzo para realizar el trabajo de pruebas, el equipo de trabajo de las pruebas, los roles y las responsabilidades de los miembros del equipo de trabajo, las herramientas, los criterios de entrada/salida, los supuestos, los criterios de aceptación, las restricciones de las pruebas, y los indicadores de desempeño de las pruebas. Revisión de par: Los productos o servicios definidos deberán revisarse y aprobarse por parte de los revisores par seleccionados para tal fin. Las revisiones de par involucran una evaluación de los productos de trabajo realizada por los pares o colegas de trabajo con el fin de identificar y corregir de forma temprana defectos/faltas y áreas dónde se requiere mejorar la calidad de los productos de trabajo. La revisión de par utilizará los formatos del proceso de pruebas y las listas de chequeo de cada producto de trabajo. Un producto de trabajo podría ser, entre otros: la definición de un caso de negocio, una especificación de requisitos, un modelo de análisis, un modelo de diseño, el código fuente de un componente software, un diseño de una prueba, un manual de usuario, un manual de instalación, u otros documentos relacionados con la especificación, análisis, diseño, construcción y despliegue de dicho producto. Diseño y automatización de las pruebas: Se debe elaborar el análisis y diseño de las pruebas que permite traducir la estrategia de pruebas en condiciones de pruebas y casos de pruebas mediante la utilización de técnicas de diseño de pruebas. Opcionalmente, los casos de prueba se pueden automatizar. En cualquier caso, los responsables de las pruebas deberán aprobar el diseño de los casos de prueba y los guiones de prueba antes de proceder con su ejecución. Página 10

11 Página 11 de 15 Ambiente de pruebas y datos de pruebas. Se debe especificar, implementar, administrar y controlar la configuración del ambiente de pruebas durante el ciclo de vida del producto software. Igualmente, se debe crear, administrar y controlar los datos de pruebas genéricos y las bases de datos durante las pruebas acorde a la especificación de los casos de prueba y a los guiones de prueba diseñados. En cualquier caso, se debería tener un ambiente de pruebas para realizar las pruebas. Ejecución de las pruebas: Las pruebas deben validar que la captura, la transformación, el almacenamiento y la consulta de los datos se realiza mediante las funciones que ofrece el producto software, con el fin de asegurar la consistencia y la integridad de los datos conforme a las reglas de negocio y las reglas de seguridad aplicables a las arquitecturas de aplicaciones y de datos. Registro y reporte de defectos: Se deben registrar y reportar los defectos, faltas o errores detectados en la versión del producto software y sus componentes durante la ejecución de las pruebas para que se proceda a su corrección. Solución de defectos: Se debe solucionar los defectos, faltas o errores, inconsistencias o no conformidades encontradas en el producto software y sus componentes antes de su despliegue en los ambientes de producción. Seguimiento y control de las pruebas: Durante todo el proceso de pruebas se debe realizar el seguimiento y control al progreso de las pruebas y la validación y verificación de la calidad del producto software contra las estimaciones, los compromisos, los planes y las expectativas en el plan de pruebas; igualmente, se debe informar el progreso de las pruebas y la calidad del producto a los interesados, y se deben tomar las medidas de control preventivas y correctivas que se requieran hasta finalizar la ejecución de las pruebas que se planearon. Responsables de las pruebas: Los analistas funcionales, los usuarios finales y otros interesados de los negocios deben participar formalmente en las pruebas del sistema y las pruebas de aceptación de las nuevas versiones, totales o parciales, de los productos software, y en cualquier caso, la liberación y despliegue en los ambientes de producción debe ser avalada por el funcionario que ejerza el rol de analista funcional o de representante del cliente de TI. El personal responsable de la ejecución del proceso Página 11

12 Página 12 de 15 de pruebas debe tener las competencias que se requieren para desempeñar las responsabilidades de los diferentes roles en el proceso de pruebas. 1.3 Reglas relacionadas con liberación y estabilización de versiones. Liberación de Versiones: Se debe controlar que la liberación de nuevas versiones de los productos software de los servicios de TI, y el software de base o hardware instalado en el ambiente de producción, tengan la calidad necesaria y hayan cumplido con los procedimientos establecidos para ser puesto en operación. Para el caso de los desarrollos a la medida, se debe implementar la administración de las versiones de dichos desarrollos. Liberación del servicio de TI: La configuración de los ambientes de desarrollo, pruebas y producción debe realizarse con base a la vista de despliegue que está definida en términos de las arquitecturas tecnológicas, de aplicaciones y de datos, la cual se encuentra en el documento de arquitectura de software de cada servicio de TI. Para la operación del servicio de TI se deben proveer todos los productos software de instalación y la documentación técnica necesaria para la completa instalación, configuración y despliegue en dichos ambientes. Control de la configuración: Se debe tener un sistema de administración (conjunto de procesos, procedimientos y herramientas software) para realizar el control de los programas fuentes, el control de los cambios y el control de las versiones de los diferentes ítems de configuración de los diferentes servicios de TI. Se entiende por ítem de configuración cualquier elemento software base, software de aplicación, o documentación. Este sistema de administración debe permitir asegurar que la última versión de los programas fuentes es la que se utilizará en la implementación de la siguiente versión del producto software, y permitirá también asegurar que la versión del producto software liberada en los ambientes de producción, es la que probó, aceptó y avaló el funcionario que ejerció el rol de analista funcional o de representante del cliente de TI. La base de datos de configuración (CMDB) debe administrar toda la información relativa a las nuevas versiones de los diferentes ítems de configuración (hardware, software base, software de aplicación, documentación) que constituyen cualquier Página 12

13 Página 13 de 15 servicio de TI. Esta base de datos debe mantener actualizada las relaciones entre los diferentes ítems de las arquitecturas tecnológicas, de aplicaciones y de datos que conforman los ambientes de desarrollo, pruebas, y producción de cualquier servicio de TI en el catálogo de servicios de TI de EPM. 1.4 Reglas relacionadas con gestión de cambios Comité de Cambios: Para el manejo de Gestión de Cambios se conformará un Comité de Cambios (Change Advisory Board CAB), cuya responsabilidad es ayudar al Gestor de Cambios a asignar prioridad a los cambios y a decidir cuándo ejecutarlos utilizando el mecanismo definido. Condiciones para aprobación de cambios: Todos los cambios tienen unas condiciones de aprobación que dependen del tipo de cambio; estas condiciones están publicadas en el sitio web de cambios. Cambios urgentes: Todos los cambios urgentes deben ser aprobados por el Comité de Cambios de Emergencia. Horarios para la realización de los cambios: Los cambios estándar se pueden realizar en cualquier instante; los cambios de otros tipos, en las ventanas de cambios acordadas, las cuales se notifican vía memorando. Agenda de Cambios: El proceso de cambios debe definir y publicar una agenda de cambios en la cual aparecen los cambios aprobados por el Comité de Cambios Cambios que se revisan en el Comité de Cambios: Todos los cambios que cumplan con al menos uno de los criterios publicados en el sitio web de cambios deben ser revisados por el Comité de Cambios. Registro y clasificación de cambios: Todos los cambios realizados a los productos y servicios de TI deben ser registrados y clasificados en la herramienta definida para esto, con el fin de que sean planeados, evaluados, aprobados y de asignarles prioridad, tiempo y recursos. Página 13

14 Página 14 de 15 Análisis de impacto y evaluación de recursos: Todo cambio debe tener un análisis de impacto; un plan de trabajo en el cual estén todos los recursos necesarios para la ejecución de cambio; y un plan de marcha atrás Aprobación de cambios: Los cambios tienen diferentes niveles de aprobación dependiendo de la clasificación; los cambios menores o significativos pueden ser aprobados por el gestor de cambios; los cambios mayores, por jefes de la Organización Informática. Actualización de la CMDB: El proceso de administración de cambios debe asegurar la actualización de los ítems de configuración (IC) afectados por un cambio dado. Revisión post implementación: Luego de ser implementado un cambio que haya pasado por el Comité de Cambios, se le debe hacer un seguimiento para verificar su efectividad. 1.5 Reglas relacionadas con gestión de la configuración Plan de Configuración: Se debe contar con un plan de configuración que contemple todas las actividades del proceso. Líneas base: Cada solución y/o servicio que tenga un componente de TI deberá establecer líneas base de sus ICs de acuerdo al plan Gestión de la Configuración de tal manera que permita identificar sus versiones. Plan de Configuración: Todas las soluciones y/o servicios que tengan un componente de TI deben acogerse al plan de configuración estándar definido. En caso de tener una excepción debidamente justificada para acogerse a este, deberá proporcionar su propio plan para la Gestión de la Configuración respetando los lineamientos definidos por el proceso en la organización de TI. Ítems de configuración (IC): Cada ítem de configuración que será gestionado, tendrá definido un conjunto de atributos comunes y atributos específicos de acuerdo al plan de Gestión de Configuración definido. Página 14

15 Página 15 de 15 Herramientas del proceso: La Organización de TI debe disponer de las herramientas necesarias para el cumplimiento de las actividades definidas en el proceso Gestión de Configuración. Responsabilidad por la actualización de la información del CMS: Los jefes de estructura deben designar los agentes de configuración, los cuales son responsables de la actualización y mantenimiento de los ítems de configuración. Estos agentes deben contar con personal de respaldo (Personal idóneo responsable de mantener actualizados los ítems de configuración). Repositorio de ítems de configuración: Se dispondrá de un sistema de gestión de configuración (CMS) con los datos de los ítems de configuración de los servicios de TI y sus relaciones, los cuales deberán facilitar la evaluación del impacto de los cambios en los productos y/o servicios TI y disponer de inventarios actualizados del hardware y software de la organización. Control de los Ítems de configuración: Para tener el mapa de los componentes que forman un servicio de TI, se tendrá el control de los ICs hasta el nivel de unidades de configuración (CU) en cada una de las herramientas que soportan el proceso Gestión de la Configuración. Registro y auditoria de los servicios de TI en el CMS: Todas los componentes de los productos y/o servicios de TI, desarrollados o adquiridos, deben registrarse en el CMS y auditarse periódicamente para asegurar la confiabilidad de los datos que conforman los diferentes servicios de TI. Los agentes de configuración administrarán los ítems de configuración con el fin de asegurar su actualización y consistencia. Página 15