manual de reglas de negocio asociadas al … -reglas de negocio n1... · diagramas de secuencia y...

ESTRUCTURA NORMATIVA DE EMPRESAS PÚBLICAS DE MEDELLÍN E.S.P.

REGLAS DE NEGOCIO ASOCIADAS AL PROCESO DESARROLLO DEL SERVICIO DE TI

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 Junio 2012

Página 1

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 2 de 15



Página 2

Tabla de contenido

INTRODUCCIÓN

OBJETIVO

GLOSARIO DE TÉRMINOS

1 REGLAS DE NEGOCIO PARA EL PROCESO DESARROLLO DEL SERVICIO DE

TI. ..................................................................................................................................................... 8

1.1 Reglas relacionadas con la construcción, adquisición e integración del Servicio. .............. 8

1.2 Reglas relacionadas con pruebas y validación. ........................................................................ 9

1.3 Reglas relacionadas con liberación y estabilización de versiones. ..................................... 12

1.4 Reglas relacionadas con gestión de cambios ......................................................................... 13

1.5 Reglas relacionadas con gestión de la configuración ............................................................ 14



Página 3 de 15



Página 3

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 4 de 15



Página 4

procedimientos e instructivos.”, así como se contempló en el decreto 1866 de enero 31 de

2012.

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 5 de 15



Página 5

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 6 de 15



Página 6

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 7 de 15



Página 7

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 8 de 15



Página 8

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 9 de 15



Página 9

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 10 de 15



Página 10

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 11 de 15



Página 11

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 12 de 15



Página 12

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 13 de 15



Página 13

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 14 de 15



Página 14

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 15 de 15



Página 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.

manual de reglas de negocio asociadas al … -reglas de negocio n1... · diagramas de secuencia y...

Documents