UNIVERSIDAD LOYOLA [INGENIERIA EN SISTEMAS]

AUDITORIA Y SISTEMAS DE SEGURIDAD Pgina 1

POLITICAS Y NORMAS EN EL CONTROL DE CAMBIOS
DE SOFTWARE
CAMBIOS EN EL SOFTWARE
Visin General
Vivimos en una poca de continuos cambios. Tendemos a asociar la idea de cambio con la de
progreso, y aunque esto no sea necesariamente as, es evidente que toda "evolucin a mejor"
requiere necesariamente de un cambio.
Sin embargo, es moneda frecuente encontrarse con gestores de servicios TI que an se rigen por
el lema: "si algo funciona, no lo toques". Y aunque bien es cierto que el cambio puede ser fuente de
nuevos problemas, y nunca debe hacerse gratuitamente sin evaluar bien sus consecuencias,
puede resultar mucho ms peligroso el estancamiento en servicios y tecnologas desactualizados.
Las principales razones para la realizacin de cambios en la infraestructura TI son:
Solucin de errores conocidos.
Desarrollo de nuevos servicios.
Mejora de los servicios existentes.
Imperativo legal.
El principal objetivo de la Gestin de Cambios es la evaluacin y planificacin del proceso de
cambio para asegurar que, si ste se lleva a cabo, se haga de la forma ms eficiente, siguiendo los
procedimientos establecidos y asegurando en todo momento la calidad y continuidad del servicio.

Introduccin y Objetivos

El objetivo primordial de la Gestin de Cambios es que se realicen e implementen adecuadamente
todos los cambios necesarios en la infraestructura y servicios TI garantizando el seguimiento de
procedimientos estndar.
La Gestin de Cambios debe trabajar para asegurar que los cambios:

Estn justificados.
Se llevan a cabo sin perjuicio de la calidad del servicio TI.
Estn convenientemente registrados, clasificados y documentados.
Han sido cuidadosamente testeados en un entorno de prueba.
Se ven reflejados en la CMDB.

Pueden deshacerse mediante planes de "retirada del cambio" (back-outs) en caso de un incorrecto
funcionamiento tras su implementacin.
Los principales beneficios derivados de una correcta gestin del cambio son:

Se reduce el nmero de incidentes y problemas potencialmente asociados a todo cambio.
Se puede retornar a configuraciones estables de manera sencilla y rpida en caso de que
el cambio tenga un impacto negativo en la estructura TI.
Se reduce el nmero de "back-outs" necesarios.
Los cambios son mejor aceptados y se evitan "tendencias inmovilistas".
Se evalan los verdaderos costes asociados al cambio y por lo tanto es ms sencillo
valorar el retorno real a la inversin.
La CMDB est correctamente actualizada, algo imprescindible para la correcta gestin del
resto de procesos TI.
Se desarrollan procedimientos de cambio estndar que permiten la rpida actualizacin de
sistemas no crticos.

UNIVERSIDAD LOYOLA [INGENIERIA EN SISTEMAS]

AUDITORIA Y SISTEMAS DE SEGURIDAD Pgina 2

Actividades consideradas dentro del proceso de control de cambios de software:
Identificar la necesidad del cambio.
Realizar la solicitud de cambio.
Evaluar la solicitud
Generar un informe del cambio donde se decide si la solicitud es aceptada, rechazada o
postergada.
Si la solicitud es aceptada se deber incluir el requerimiento dentro del alcance del
proyecto.
Se genera la orden de cambio.
Se realiza el cambio el cual es revisado, se reconstruye la versin de la solucin del
proyecto, se realizan las pruebas tcnicas y de usuario necesarias para el proceso, y se
pone en marcha la nueva versin del software.
Proceso de control de cambios

IDENTIFICACIN DE UN CAMBIO
Se pueden identificar cambios durante la ejecucin de las actividades consideradas en cualquiera
de las fases establecidas para el desarrollo de la solucin del proyecto.
UNIVERSIDAD LOYOLA [INGENIERIA EN SISTEMAS]

AUDITORIA Y SISTEMAS DE SEGURIDAD Pgina 3

Un cambio solicitado podr impactar aspectos del proyecto como:
Alcance
Costos
Tiempo
Recurso Humano
SOLICITUD DE CAMBIO
Una vez sea identificado el cambio se deber realizar la solicitud formalmente.
La solicitud se deber realizar de manera escrita, por correo electrnico o con el apoyo de
una herramienta informtica y deber contener mnimo la siguiente informacin:
Nombre del Proyecto: Nombre con el que se identifica el proyecto.
Fecha: Fecha en la que se solicita el cambio.
Solicitado Por: Nombre de la persona que realiza la solicitud de cambio.
Cambio Solicitado: Descripcin del requerimiento sobre el cual se realizara el cambio o
del nuevo requerimiento a desarrollar.
Tipo de Cambio: Se clasificar el cambio solicitado en alguno de los siguientes tipos:
Tipo Descripcin
Extensin
Adicin de nuevas funcionalidades a un requerimiento planteado en el documento de
alcance del proyecto.
Adaptacin
Modificacin a un requerimiento considerado dentro del alcance de la solucin del
proyecto y que tiene como objeto satisfacer cambios en el entorno o reglamentaciones.
Mejora
Modificacin a un requerimiento considerado dentro del alcance de la solucin del
proyecto, con el fin de mejorar el desempeo del aplicativo o mejor ergonoma en su
uso.
Nuevo
Inclusin de un nuevo requerimiento no considerado dentro del alcance inicial y que
implica la realizacin de un aplicativo o mdulo nuevo.

Justificacin del Cambio: Se deber dar una descripcin de la razn que origina la solicitud
del cambio.
UNIVERSIDAD LOYOLA [INGENIERIA EN SISTEMAS]

AUDITORIA Y SISTEMAS DE SEGURIDAD Pgina 4

Documento Soporte del Cambio Solicitado: En caso de aplicar, se anexa el documento o
documentos que soportan la solicitud y una breve descripcin del contenido de estos.
EVALUACIN DEL IMPACTO DEL CAMBIO SOLICITADO
La evaluacin de los cambios se realiza con el fin de medir el impacto que se pueda generar al
proyecto durante su desarrollo.
IMPLEMENTACION
Aunque la Gestin de Cambios NO es la encargada de implementar el cambio, algo de lo que se
encarga habitualmente la Gestin de Versiones, si lo es de supervisar y coordinar todo el proceso.
En la fase de desarrollo del cambio se deber monitorizar el proceso para asegurar que:
Tanto el software desarrollado como el hardware adquirido se ajustan a las
especificaciones predeterminadas.
Se cumplen los calendarios previstos y la asignacin de recursos es la adecuada.
El entorno de pruebas es realista y simula adecuadamente el entorno de produccin.
Los planes de "back-out" permitirn la rpida recuperacin de la ltima configuracin
estable.
Si es posible, debe permitirse el acceso restringido de usuarios al entorno de pruebas para que
realicen una valoracin preliminar de los nuevos sistemas en lo que respecta a su:
Funcionalidad.
Usabilidad.
Accesibilidad.

La opinin de los usuarios debe ser tomada en cuenta y la RFC debe ser revisada en caso de que
se encuentren objeciones justificadas al cambio (debe tenerse en cuenta la resistencia habitual al
cambio por parte de cierto tipo de usuarios).
Los clientes y proveedores no deben percibir el cambio como algo inesperado. Es funcin tanto de
la Gestin de Cambios como del Service Desk mantener informados a los usuarios de los futuros
cambios y, dentro de lo posible, hacerles partcipes del mismo:
Escuchando sus sugerencias.
Comunicando las ventajas asociadas.
Aclarando sus dudas y dando soporte cuando ello sea necesario: la percepcin de mejora
debe ser compartida por usuarios y clientes

ENTREGA Y VALIDACIN DEL CAMBIO
Los aspectos claves a validar en el cambio son:
Se ha desarrollado e implementado el cambio requerido adecuadamente.
La documentacin relacionada con el cambio se encuentra actualizada.
El cambio de versin es aplicado y es consistente con el desarrollo del cambio.
Pruebas de Usuario Aprobacin y Cierre del Cambio
Aprobacin y cierre de Cambio.- Una vez se hayan validado todos los entregables del cambio
requerido se proceder a la aprobacin y cierre segn corresponda. Esta aprobacin y cierre se
formalizar a travs de una comunicacin mediante un acta de reunin.
UNIVERSIDAD LOYOLA [INGENIERIA EN SISTEMAS]

AUDITORIA Y SISTEMAS DE SEGURIDAD Pgina 5

POLITICA DE CONTROL DE CAMBIOS DE SOFTWARE
Como ejemplo pudimos obtener las polticas del control de cambios del Ministerio de Viviendas y
Urbanismo del gobierno de CHILE, donde se detalla lo siguiente:
RESUMEN
El MINVU ha decidido que todo cambio al estado de la infraestructura computacional, debe ser
efectuado sin afectar la integridad, confidencialidad de los datos y la continuidad de los servicios.
PROPOSITO
Esta poltica establece las reglas que regula el proceso de cambio en la infraestructura
computacional del MINVU.
ALCANCE
Se aplica a todo cambio que se realice en hardware, infraestructura de comunicaciones, software
bsico, aplicativos, sitios Web y Bases de Datos residentes en el centro de cmputo de la sub
secretaria.
POLITICA
1. Consideraciones generales.
1.1. Cualquier cambio de hardware, software bsico y Sistemas Aplicativos que se requiera
efectuar en el ambiente de Produccin, necesariamente debe considerar los siguientes
aspectos:
1.1.1. Antes del proceso de cambio se debe:
1.1.1.1. Desarrollar una planificacin detallada de cada una de las etapas,
incluyendo la definicin de respaldos previos, recursos necesarios para el
proceso de cambio, conjunto de pruebas pre y post instalacin,
capacitacin de usuarios, criterios de xito o aceptacin, as como
tambin un plan de vueltas atrs. Dependiendo de la complejidad del
cambio, debe ser apoyado con un checklist para facilitar la verificacin de
la actividad.
1.1.1.2. Coordinar el cambio con las reas involucradas o propietarias de los
sistemas afectados, para que se efectu durante periodos de baja carga de
trabajo.
1.1.1.3. Solicitar la correspondiente autorizacin.
1.1.2. Durante el proceso de cambio se debe:
1.1.2.1. Contar siempre con la colaboracin o contacto directo con los fabricantes
del software o empresas de soporte relacionadas.
1.1.2.2. Mantener habilitado el mximo de detalle en la funcin de registros de
auditoria relacionado con el cambio.
1.1.3. Posterior al cambio efectuado, se requiere necesariamente:
UNIVERSIDAD LOYOLA [INGENIERIA EN SISTEMAS]

AUDITORIA Y SISTEMAS DE SEGURIDAD Pgina 6

1.1.3.1. Registrar el cambio en los sistemas de control correspondientes.
2. Cambios de hardware.
2.1. El departamento de ingeniera debe planificar y solicitar al rea de redes y sistemas
y/o a una tercera parte, los cambios de hardware que se requieren por mejoras o
reparaciones ante fallas.
2.2. En el caso de participacin de terceras partes, ellas deben ser controladas por el rea
de redes y sistemas.
3. Cambios de Software bsicos.
3.1. Los cambios producidos a nivel de software bsico, deben cumplir los siguientes
requisitos:
3.1.1. Los cambios deben ser programados de preferencia para los fines de semana
o das no hbiles o fuera del horario de oficina.
3.1.2. No se debe instalar actualizaciones sin verificar su autenticidad, integridad y
evaluacin de posible impacto a los sistemas aplicativos.
3.1.3. Una etapa previa posible de considerar, es la instalacin de la actualizacin en
un ambiente aislado de prueba, con el objeto de realizar un chequeo al
funcionamiento.
4. Cambios en los Sistemas Aplicativos.
4.1. Los cambios a los sistemas aplicativos existentes y/o nuevos sistemas, deben
considerar los siguientes aspectos:
4.1.1. Ser analizado y probado previamente en los ambientes de Desarrollo y Test.
4.1.2. Los datos de prueba deben ser concordantes con lo que se contiene en
ambiente de Produccin. Estos deben ser preservados para permitir pruebas
repetitivas, en lo posible los datos para prueba y desarrollo deben
corresponder a un subconjunto representativo de informacin de produccin.
4.1.3. Para los sistemas nuevos y de funcin critica, deben realizarse pruebas tales
como volumen, stress, rendimiento, almacenamiento, integracin de
sistemas, seguridad y recuperacin ante errores.
4.1.4. Contar con la aprobacin del usuario lder.
4.1.5. Generar la documentacin necesaria definida para hacer entrega del cambio
de Produccin.
4.1.6. Documentar detalladamente os cambios introducidos al sistema, de manera
de facilitar la capacitacin de los usuarios. Esta capacitacin debe realizarse
tan cerca de la salida a Produccin como sea posible, de tal manera de
disminuir el olvido de los usuarios.
4.1.7. Si el sistema aplicativo es un desarrollo externo, se debe contar con el apoyo
del personal de la empresa proveedora del sistema.
5. Cambios mayores en Sistemas Aplicativos.
5.1. Los cambios mayores a los sistemas aplicativos existentes o nuevos, que afecten a la
institucin de manera transversal, deben considerar:
UNIVERSIDAD LOYOLA [INGENIERIA EN SISTEMAS]

AUDITORIA Y SISTEMAS DE SEGURIDAD Pgina 7

5.1.1. La incorporacin de un equipo de personas al proyecto, con el propsito de
registrar y documentar las diferencias a nivel de perfiles, datos, programas,
interfaces usuarias para el sistema antiguo y nuevo.
5.1.2. Planificar y ejecutar la capacitacin del personal afectado.
5.1.3. Apoyar la salida de produccin de sistema, incorporndose a la mesa de ayuda
o constituyendo una mesa de ayuda especial.
6. Cambios de Emergencia.
7.1. Se debe establecer un proceso definido y controlado para los cambios de emergencia.
Este proceso debe considerar el registro post modificacin de la informacin asociada
y su correspondiente aprobacin.

BIBLIOGRAFIA:
http://sudeban.gob.ve/uploads/-B/Xk/-BXkhYa2byi_i86ER0hlxw/Normativa-2011-04-
28.pdf
http://es.scribd.com/doc/2023909/manual-de-politicas-y-normas-de-seguridad-
informatica#download
http://www.lsi.us.es/docencia/get.php?id=2468
https://www.bancard.com.py/docs/ResumenPoliticaSI.pdf