Reglas de Negocio N1 Desarrollo Junio 20 de 2012 V1

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 001
Junio 2012
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
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 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. ..................................................................................................................................................... 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
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 2
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 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,
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 3
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 4 de 15
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
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 4
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 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
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 5
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 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
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 6
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 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.
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 7
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 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
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 8
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 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
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 9
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 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.
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 10
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 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
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 11
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 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
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 12
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 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.
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 13
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 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.
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 14
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 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.
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 15