Goal

Examen reprobadoo
Configuration Management es una prctica para mantener consistentes las
aplicaciones que se tienen bajo control propio. Es decir, explica cmo los
cambios que se hacen afectan y son controlados a travs del ciclo de vida de la
aplicacin
El objetivo de este curso es que ustedes sean capaces de definir la
administracin de configuracin dentro de un proyecto, planearla y difundirla
en su equipo de trabajo, quienes debern conocerla y seguirla.
Agenda
Se hablar de la definicin de Configuration Management, su importancia,
relaciones principales, las prcticas ms crticas a realizar dentro de un
proyecto, tipos de Configuration Items, los ambientes bajo los cules se realiza
la configuracin y el flujo que siguen. Tambin se conocer cmo se integra un
producto, el plan de administracin de configuracin y las auditoras de la
administracin de la configuracin.
Qu significa Configuration Management? son la serie de procedimientos, de
checklist y templates que permiten controlar los cambios de aquellas cosas
consideradas como importantes para el proyecto y que son denominadas
Configuration Items. Al tomar un Configuration Item para controlarlo durante la
vida del proyecto, implica que todo cambio que se realice, as como las veces
que se de check-out check-in cada que se agreguen comentarios se tenga
el control absoluto del estatus de dichos cambios, por ejemplo: llega un change
request que pide cambios a 20 cosas; en todo momento y bajo cualquier
situacin al cliente podr informrsele del estatus de cambios. O en un AMS se
le dir cul es el estatus de su requerimiento y qu va a cambiar en cada
configuration item. La parte inicial y fundamental de Configuration
Management es identificar los configuration tems. Es decir, aquellas
caractersticas o productos que se tienen que controlar y verificar para poder
hacer un anlisis de impacto adecuado y propagar los cambios de la mejor
forma. De manera ms especfica, configuration item, configuration
identification y configuration control, son los elementos que integran toda
Administracin de Configuracin. Ya que es la disciplina en los procesos que
identifica y controla a los configuration tems. En conclusin desde el inicio del
proyecto se deben estipular aquellas cosas que requieren ser controladas, as
como el esquema y polticas bajo las que se vigilarn.
Definitions

A continuacin se analizar cmo se comportan los cuatro conceptos bsicos y

su relacin con lo mencionado hace unos momentos. Configuration status
accounting es el control de cada una de las solicitudes de cambio; y debe ser
capaz de dar reportes e informacin pertinente sobre lo que est pasando con
los configuration items. Es decir, conocer el estatus en el que se encuentran y
brindar detalles. Configuration audit, es un proceso digitalizado que debe
realizar el equipo en Kintana y es acerca del estatus y la estructura del
repositorio de informacin. Se encarga de revisar si el plan de configuracin
est siendo usado efectivamente. Tambin audita los configuration items para
saber si en el proyecto se estn controlando, identificando y promoviendo
adecuadamente. Ms adelante se analizarn las caractersticas que debe tener
la auditora de configuracin. Ya que es imposible creer que una auditoria es
efectiva si existen problemas de corrupcin de datos o prdida de informacin.
El principal objetivo o el minimo requerimiento del Configuration audit es
mantener la integridad del repositorio y garantizar que no tenga problemas.
Configuration baseline, es una etiqueta que identifica una serie de
configuration items como parte de un baseline o de una versin estable que
slo se modificar a travs de change request.
Conforme se realizan
cambios aprobados, se dice que se re-etiqueta, lo que lleva a un avance
llamado iteracin uno, y que se convierte en el baseline actual. Posteriormente
se generan ms cambios, ya sea por defectos encontrados en produccin, en
UAT o porque hay cambios de alcance que afectan el release que se hizo
dentro de la primera iteracin. Lo anterior quiere decir que se tiene un grupo
de cosas que representan un baseline y sobre ste se controlan cambios. Dicho
baseline puede ser por cada fase de requerimientos, de diseo, de primera
iteracin, de cdigo, etc. Al mismo tiempo es comn agregar baselines y
etiquetarlos de acuerdo al tollgate en el que se est, dentro de WBS.
Configuration control board, software configuration control board, change
control board, software change control board o application control board son
sinnimos para referirse a las personas responsables de aprobar los cambios a
un baseline o a una aplicacin. En ocasiones el lder de proyecto, junto con el
cliente pueden tener la autoridad para aceptar, aprobar y solicitar que se
realicen cambios dentro de una aplicacin o proyecto en desarrollo.
Importance of Configuration Management
La importancia de administrar adecuadamente la configuracin de una
aplicacin asegura la integridad del producto. Conforme se le da
mantenimiento a una aplicacin o, se implementan requerimientos en el caso
de un desarrollo, se generan ciertos cambios en el cdigo, en los
requerimientos, en los documentos de diseo o de anlisis. Al acumularse
estos cambios, se puede ocasionar deterioro en el producto, es decir, que el
documento de diseo no corresponde perfectamente a lo que hace el cdigo o
a lo que dice el documento de anlisis que debe de hacer. Tener un proceso de
Configuration Management permite que el proceso de mejora del proyecto

funcione y no tenga errores adicionales a los normales. Evita problemas al

realizar deployment, pasar a testing, cambiar versiones o reparar errores. La
administracin de la configuracin es tarea de todas las personas que trabajan
en el proyecto ya que todos tocan el cdigo, hacen el check-in, aaden
comentarios, etc. Configuration Management es responsable de hacer
baselines que probablemente tienen que ver con el release bimestral que tiene
la aplicacin, con el ltimo release que se acord con el cliente y con una serie
de enhacements o mejoras hechas al cdigo base de la aplicacin.
Generalmente cuando se presentan problemas de Configuration Management,
son detectados cuando las cosas ya no pueden repararse. De aqu, la
importancia no solo de generar respaldos, sino de mantener consistentes todos
los ambientes para lograr una verdadera administracin efectiva.
Configuration Management
Primary Relationships (Dependencies & Dependents)
Configuration Management se relaciona con las reas de proceso de CMMi por
ser una de las prcticas genricas. Esto quiere decir que cada una de las reas
de proceso de CMMi es evaluada en un assesment para indicar, como
organizacin, si se est o no institucionalizando determinada rea de proceso.
Una de las mediciones de institucionalizacin es que los entregables y
productos que generen las prcticas relacionadas con un rea de proceso,
estn bajo control de configuracin o bajo el control correcto. Las siguientes
reas de proceso de CMMi son la base de Configuration Management:Project
Planning (PP) significa tener siempre un plan de configuracin integrado con el
proyecto, de tal forma que no existan sorpresas y en el caso de tener algn
defecto, propagar las correciones del defecto adecuadamente en las diferentes
versiones. Project Monitoring and Control (PMC) es asegurarse de que lo que se
planea para Configuration Management efectivamente se lleva cabo. Un
ejemplo particular tiene que ver con las auditoras de configuracin. Las
preguntas que deben plantearse son: Se realizan las que se determinaron?,
Se hace una cada mes?, Las realizan las personas correctas?, Cunto
tiempo se le invierte? Tambin depende de Causal Analysis and Resolution
(CAR) para identificar qu mtodos se pueden utilizar para hacer un anlisis e
impacto correcto. En caso de presentarse algn problema se debe hacer un
RCA, que es un anlisis de causa raz, que asegura que un proceso tan
fundamental como el de Configuration Management no tenga fallas intrnsecas
al proceso. Configuration Management se relaciona estrechamente con el
Product Integration (PI) que es la habilidad para integrar el producto o
aplicacin que se est desarrollando en un AMS. En caso de tener un mal
Configuration Management, la aplicacin podra verse coartada y pudiera
ponerse en riesgo. Por eso se dice que este proceso se asemeja con las piezas
de lego, unas arriba de otras. Requirement Management significa llevar un
control estricto del estado de los requerimientos. Asi como entender

perfectamente la matriz de traceability o rastreabilidad de dichos

requerimientos a lo largo y ancho del proyecto o aplicacin. Requirement
Development, est ntimamente ligado a Requirement Management. Ya que los
requerimientos deben seguir un estricto control de configuracin, es decir,
desde que son requerimientos de negocio hasta que son uses cases detallados,
diagramas de colaboracin, diagramas de clase o cualquier tipo de diagramas
de UML. Measurement and Analysis se refiere a que las mediciones y los
resultados del proyecto deben estar bajo un control adecuado para asegurar
que la compaa aprenda de todos los errores y de lo que sucede en los
proyectos. Por ejemplo, que cada proyecto genere archivos de Excel y luego se
consolide de alguna forma para que, con el paso del tiempo, la configuracin
se tenga bajo control y como organizacin se tenga acceso a la informacin de
cada proyecto. En el caso de Softtek, la informacin est sumamente
controlada porque los proyectos estn en Kintana y usan un workflow estndar
para AMS. Y en desarrollos cuenta con un desglose de tareas o WBS que viene
de un tailoring de proceso estndar, y que es aprobado por TST y por el OL.
Cabe mencionar que en Kintanta diariamente se generan respaldos, actividad
que realiza la compaa. Sin embargo, lo que se espera de ustedes es que
guarden los configuration items como: los business review, las presentaciones
que se hagan al cliente, el cdigo, la documentacin, etc. Todo esto debe
guardarse en el repositorio de configuracin. Lo anterior para que en caso de
que haya una transicin de lderes o de alguien del equipo, la informacin est
disponible en forma efectiva y fcil de accesar.
Critical Practices
A continuacin se hablar de las prcticas. Pues la intencin de este curso es
dejar claramente identificadas, evaluadas y entendidas tres prcticas
principalmente.
1. Crear o liberar BASELINES y RELEASES
2. Realizar un Seguimiento a los CHANGE REQUEST
3. Realizar Auditorias a la CONFIGURACIN
Los BASELINE y RELEASE que se CREAN, siguen una serie de etapas para todo
aquel COMPONENTE desarrollado junto con los DOCUMENTOS que se
entregarn al cliente. Cada que se integra o libera una ENTREGA a produccin,
pasa a conformar un NUEVO BASELINE. Dicho BASELINE puede ser MEJORADO
de manera GRADUAL y se identificar a travs de RELEASE. El como se irn
CREANDO los BASELINE y RELEASE, debe estar regido por los ACUERDOS y
POLITICAS que determina el CLIENTE. Un ejemplo de cmo generar un
BASELINE, se reforzar cuando se toque el tema de Configuration
Environments Ambientes de Configuracin, y se hable de los distintos
ambientes que recorren los entregables para ser liberados a produccin. Los

Change Requests, son las peticiones de cambio a la funcionalidad u operacin

de una aplicacin. El tracking o seguimiento, se refiere a hacer el anlisis de
impacto que implica el requerimiento, apoyndose de elementos que ayuden a
rastrear, e identificar los componentes que el requerimiento deba afectar. As
como tomar las versiones correctas sobre las cuales se va a modificar,
asegurndose que nadie ms altere esos componentes hasta que sea liberado.
Esto ltimo se realiza a travs del procedimiento de DEMOTE y PROMOTE que
rige el proyecto. Dichos procedimientos se reforzaran a tocar el tema de
Configuration Environments.
Es NECESARIO que TODO proyecto lleve a cabo AUDITORIAS sobre la
administracin de configuracin que se haya definido. Es un punto de control
de lo ms delicado, puesto que es para ayudar a garantizar la INTEGRIDAD de
las ENTREGAS. Para finalizar este curso se reforzarn las AUDITORIAS al
Configuration Management. (Administracin de la configuracin)
Configuration Item Types
Existen dos tipos distintos de configuration items. El primero tiene que ver con
la aplicacin, es decir, el cdigo fuente, el cdigo ejecutable, el cdigo
compilado, el intermedio, el interpretado. Por ejemplo la estructura de la base
de datos, los scrips de stored procedures, los archivos de cdigo punto java,
archivos punto exe, etc. En otra categora se encuentra la documentacin de la
aplicacin, es decir, todos aquellos archivos de Word, Excel, o por ejemplo,
documentos en formato de rational, o de Start UML, o de alguna herramienta
de modelacin y lo que hacen estos archivos es identificar cmo se encuentran
los componentes, cul es el diseo, el use case y el anlisis. Tambin
identifican qu es lo que tiene que hacer la aplicacin y cmo tiene que hacerlo
por lo tanto estn totalmente ligados a lo que hace la aplicacin y parte de
Configuration management tiene que ver en cmo se mantienen a esos dos en
sincrona. Es decir, lo que realmente hace la aplicacin y lo que se est
documentado.
Configuration Environments
Se emplearn 5 ambientes distintos, sin embargo, es posible que se tenga un
nmero diferente de ambientes o una conformacin distinta en cada una de
sus aplicaciones. Se debe tomar en cuenta que si existe una separacin entre
el ambiente de produccin, el ambiente donde prueba el usuario y el ambiente
donde se hacen los cambios. Siempre existe un ambiente de desarrollo. En
algunos casos es la computadora del DEVELOPER, pero en caso de usar Citrix,
deber ser una computadora que est fuera del alcance del DEVELOPER. Por
otra parte, as como existe un ambiente de desarrollo, tambin debe haber una
ambiente donde se integre el cdigo y en el que se puedan hacer las pruebas
unitarias de la aplicacin ya integrada. Esto quiere decir que se debe tener la

capacidad de probar el funcionamiento de lo que se est modificando con el

resto de la aplicacin. Por ejemplo, en un ambiente web como Java, se puede
estar trabajando con un IDE o un ECLIPSE que sincroniza tu rea de trabajo con
la informacin del servidor del ambiente de desarrollo y cuando se realizan las
pruebas unitarias, se compila el cdigo y se usa la ltima versin que integra
los ltimos cambios. Esto es: Ambiente Integrado de Pruebas Unit Test
Integrated Environment. Con las versiones que se tienen, de ah hacia abajo, se
posee un ambiente de desarrollo que generalmente se convierte en ms de
uno. Por ejemplo, si se tiene ms de un DEVELOPER con la misma aplicacin,
cada quien tiene su workspace. Una vez hechas las pruebas, se va subiendo
hacia el ambiente de USER ACCEPTANCE, es decir, donde el UAT o el usurario lo
probar. En el caso de algunos clientes, ste puede ser el mismo ambiente de
staging, o puede ser distinto. En cuyo caso, el usuario prueba su proceso de
aplicacin y luego se pasa al staging. Aqu la gente de preproduccin o staging,
se encarga de que todo funcione perfectamente. Incluso si tienen sus casos de
prueba automatizados, pueden hacer pruebas de regresin a toda la
funcionalidad de la aplicacin para asegurarse de que lo que se cambio, o
modifico, no afecte el cdigo del resto de la aplicacin. Es decir, que el set
mnimo de casos de pruebas corra perfectamente y no impacte a ningn otro
componente de ejecucin. Posteriormente pasa al ambiente de produccin en
el que todos los usuarios lo utilizan
Configuration Item Flow Between Environments
En este diagrama se muestran de manera general los flujos entre los distintos
ambientes. Es decir, desde que el cdigo llega al ambiente de desarrollo, se
hacen modificaciones, se prueban, se autorizan y finalmente se suben a
produccin. Si se hacen modificaciones, primero deber realizarse un Demote
de Produccin Directo a desarrollo. Conforme se avance en las etapas de
verificacin y prueba del componente, se habla de un Promote, o Promocin,
porque se promueven cambios en los subsiguientes ambientes hasta que sea
liberado con la participacin de todas las personas que estn involucradas de
alguna forma en este ciclo, como se refleja en el Configuration Management.
Configuration Item Flow Between Environments
Source and compile code / System Related Documentation
Si se requiere hacer un cambio es necesario recurrir al ambiente de staging, lo
que supone que el cdigo en produccin concuerda perfectamente el ambiente
de staging
Se hace un check-out del baseline ubicado en el ambiente de staging. Luego se
pone en el ambiente de trabajo local, se desarrolla, se hacen pruebas, se
compila o lo que se requiera. Una vez terminado el cdigo se realiza el Promote
al ambiente donde se har el UNIT TESTING. Por ejemplo, en Java se har un

merge de lo que se tiene del ambiente de desarrollo con lo que se tienen del
ambiente donde se probar y en el que todas las aplicaciones estn corriendo.
Configuration Item Flow Between Environments
Source and compile code / Application Related Documentation
Posteriormente el cdigo pasa al ambiente donde se realizarn las pruebas de
usuario, tomando en cuenta que previamente se hizo el Unit Testing y el Peer
Review. De ah la importancia de que sea un ambiente distinto al del
DEVELOPER, para que el Peer Reviewer pueda verificar el cdigo y
adicionalmente hacer el testing apropiado sobre dicho ambiente. Se dice que
esa es la condicin indispensable para promover el ambiente de User
Acceptance Testing. Esto significa que si se hace un mantenimiento o un
enhacement y el usuario prueba la aplicacin, forzosamente se debe hacer un
Peer Review para hacer el testing, aplicar el checklist y asegurarse que todo
funcionar adecuadamente. Tpicamente ah existe una matriz de pruebas y
sus casos de pruebas o alguna variacin que permita a la persona que realizar
el Peer Review revisar el cdigo, la aplicacin y hacer la validacin para
corroborar que el cambio cumple con la necesidad del usuario. De ah la
importancia de la VALIDACIN, sobre todo cuando se realiza un AMS.
Configuration Item Flow between Environments
Source and compile code / Application Related Documentation
Si se detectan defectos o fallas durante el Peer Review, se hace un demote al
cdigo. Es decir, se regresa al ambiente de desarrollo y como parte del
Configuration Management, el componente es etiquetado con un estatus de
retrabajo. Esto con la finalidad de que la gente sepa que dicho componente,
mdulo, grupo de archivos o de objetos, est siendo retrabajado, evitando que
sea utilizado cuando an no est estable, lo que es distinto a cuando alguien
est agregando una nueva funcionalidad.
Configuration Item Flow between Environments
Source and compile code / Application Related Documentation
Una vez que se revisa la informacin, que el Peer Reviewer acepta los defectos
encontrados en los test cases y que el usuario ya dio su aprobacin, entonces
se pasa al ambiente de staging. Por lo tanto, se puede pasar al equipo de
preproduccin para iniciar con otras pruebas, con la regresin, con el anlisis
de performance o con lo que se esta planeando para dicha fase. Todo esto
tiene que ver con el ciclo de regresin, pruebas de performance y de
asegurarse que no le afecte a algn otro elemento que se tuviera en el
ambiente.

Configuration Item Flow between Environments

Source and compile code / Application Related Documentation

Qu sucede cuando el usuario no lo aprueba? se hace el demote al cdigo y

se vuelve al ambiente de desarrollo. As debe ser el proceso para evitar
problemas, no se puede regresar a los ambientes de prueba, luego hacer
cambios y posteriormente subirlos. Se deben agregar al checklist los defectos
que el usuario encontr en la Matriz de Pruebas. El Peer Reviewer tiene que
asegurar que los defectos encontrados por el cliente se arreglen en esta fase.
Asimismo, se debe asegurar que la forma en que el usuario lo prob y cmo lo
volver a probar, ser la misma. Sin embargo, siempre que sucede esto se
presenta un problema con el proceso, propiamente en la revisin de mtricas
semanales o metrics review. Aqu se deben buscar las causas raz de los
defectos encontrados.
Configuration Item Flow between Environments
Source and compile code / Application Related Documentation

Hasta este momento ya se pasaron las pruebas de UAT; los staging ya le dieron
el release y el cdigo est en produccin. De forma simplificada, este flujo
debe parecerse al procedimiento que se sigue en una nueva funcionalidad, en
un enhancement, un mantenimiento, etc. Es decir, desde que te piden algo
hasta que se termina y se sube a produccin. Esta conformacin de ambientes
tiene que estar perfectamente clara para cada una de sus aplicaciones. El
personal que atienda cada una de las aplicaciones debe tener dicha
conformacin clara, y saber qu ambientes existen, para saber en dnde se
realizar el Peer Review, el staging, etc. Todo esto se encuentra perfectamente
documentado en el Plan de Configuration Management Configuration
Management Plan. La idea es que cada integrante del equipo recurra a su
Configuration Management Plan para conocer a detalle sus aplicaciones. Este
plan puede ser nico en el PDP, Project Development Plan, a nivel proyecto, o
pueden ser varios vinculados al PDP, en el que cada uno tiene el detalle de
cada aplicacin. Por otra parte, el ciclo de la documentacin es muy similar ya
que conforme se van encontrando defectos, se debe ir arreglando la
documentacin. Es ms sencillo ya que hay dos ambientes, el local y el que se
tiene on site. En ste ltimo se encuentran el Visual Source Safe, el CVS o
cualquier otra herramienta de control de versiones. Cuando se presenta un
defecto puede tener dos posibles causas. La primera es que la aplicacin no
hace lo que est documentado, y la segunda es que lo que est documentado
y hace la aplicacin es incorrecto. En el primer caso ya no se tendra que

corregir la documentacin, mientras que en el segundo se tendra que corregir

tanto la aplicacin como la documentacin. Es importante que cuando se
hacen los Check-ins o Check-outs en el cdigo, o proyecto, se pongan los
comentarios de lo que se est haciendo o lo que se hizo para que puedan
rastrearse los defectos mayores que se han encontrado, o las cosas que estn
pasando. De esta forma, se busca evitar problemas de que alguien, meti o
saco cdigo que no debera, debido a que no estaba claro lo que se hizo en el
check-in en el check-out. Por ejemplo, si no se deja claro que se est
haciendo un retrabajo en un componente, alguien podra tomarlo e intentar
hacer un merge, pero se encontrara con que no funciona por lo que no podr
probar cuando lo integre en el Unit Test Environment. No podr realmente
probar su funcionalidad, o podra pensar que no est funcionando, cuando
probablemente el problema tuvo que ver con que uno de los componentes que
tom se estaba retrabajando. Los errores de retrabajo no siempre son fatales
pero debido a que se desconoce el estatus del componente, en ocasiones se
vuelve a hacer todo un enhacement o se reestructura. Tambin podra
plancharse el cdigo que no se debiera y no atender un release, una ventana
de release, y es que en estos momentos estamos entre Staging Environment
y el Environment Production.
Product Integration
Al inicio de este curso se mostr como Configuration Management se relaciona
con las diferentes prcticas y reas de proceso. Tambin debe tomarse en
cuenta que en el PDP hay un Procedimiento de Integracin Build Procedure.
Esto se refiere a cmo se integra el cdigo y se hace un deployment de la
aplicacin web; o cmo se integra el cdigo y se genera el release final de una
aplicacin cliente servidor; o lo que sea apropiado segn la tecnologa. Los
diferentes developers pueden estar haciendo o tocando diferentes piezas de
cdigo que despus se integraran, segn el Build Procedure. Pero tambin
puede darse el caso en el que puedan tocar la misma pieza, si existe un
procedimiento para hacer un merge, que sea adecuado y funcional en la
tecnologa que se esta empleando. Scripts Ant es una herramienta muy comn
para usar en estos casos Si estn usando Scripts Ant, Ant o Maven se les pide
compartirlo con la organizacin mediante un Process Improvement, ya que es
muy valioso conocer cmo se automatizaron las cosas en otros proyectos. Lo
que se tiene que hacer es levantar el Process Improvement en Kintana, subirlo
como ejemplo para que la gente pueda consultarlo y reutilizar parte de ese
script para generar uno nuevo en su proyecto. En resumen, la integracin de
productos consiste en tener un procedimiento de integracin y deployment,
esto puede estar automatizado por algunas herramientas, como Ant o Maven.
Disminuyendo as, el grado de detalle requerido en el procedimiento.
Configuration Management Plan

El Plan de Administracin de la Configuracin, Configuration Management

Plan es necesario por que cada producto ENTREGADO al cliente y cualquier
otro documento con informacin, relevante del proyecto, debe mantenerse
bajo un control de administracin de la configuracin. El Plan de Administracin
de la configuracin, debe ser definido por el administrador de la Configuracin
del Proyecto y deber documentarlo en el PDP, Project Development Plan.
Todas las reglas de Configuration Management que se vieron a lo largo de este
curso, estn reflejadas en cada una de las secciones que cubre el Configuration
Management Plan. En ste se describe quines revisan y autorizan cada unos
de los distintos entregables, que pueden ser personas, roles o reas. Tambin
se especifica qu herramientas se usar; qu mtodos de Identificacin, la
estructura del repositorio, los distintos ambientes de configuracin que
participarn en el proyecto, el Software, la Conectividad, el plan de respaldos y
el Plan de Recuperacin de Desastres. Por tanto, es INDISPENSABLE que todo
aquel que forme parte del equipo de trabajo del proyecto, lo CONOZCA, lo
ENTIENDA y lo SIGA.
Configuration Management Plan
Identification Methods
Esta seccin es una de las ms importantes, ya que se describen las
convenciones de nomenclatura o nombrado de los componentes o elementos
de informacin. Tambin se determinan las reglas bajo las que se realizar el
control de versiones y las convenciones de ETIQUETADO con el que el grupo
de entregables ser identificado.
Configuration Management Plan
Repository Structure
La seccin que define la estructura del repositorio, establece la mecnica ms
crtica del proyecto, ya que se especifican los pasos a seguir para la generacin
del REALESE a liberar al cliente en el BUILD PROCEDURE. Tambin se
especifican las dos mecnicas importantes que llambamos el DEMOTE y el
PROMOTE. El procedimiento para realizar el DEMOTE se documenta en la
seccin del CHECK-OUT PROCESS y los pasos para realizar el PROMOTE en el
CHECK-IN PROCESS. Estas dos secciones deben estar claramente
documentadas y completas, ya que formarn parte de un hbito de trabajo de
cada uno de los miembros del equipo.
Configuration Management Audit
Una vez que el proyecto ha comenzado a operar, es NECESARIO que cada MES
se realicen auditorias sobre la Administracin de Configuracin que lo rige. En
esta auditoria se debe tener claro quines son los participantes, y qu es lo

que se va a auditar. El REGISTRO, CONTROL y SEGUIMIENTO se realiza a travs

de la herramienta de Softtek, IT Governance Center, conocido como ITG, y
anteriormente como Kintana. En esta herramienta se documenta la auditora
en el Configuration Management Audit Request.
Configuration Management audit.
Who are the participants in the CM Audit?
El Project Leader ser el encargado registrar el Configuration Managment Audit
Request, y asignar a la persona que realizar la auditora. La persona
designada como AUDITOR, debe formar parte del equipo de trabajo. Sin
embargo, no puede ser el Configuration Manager ni el Project Leader. En caso
de que el proyecto sea muy pequeo, debe identificarse a una persona que
est familiarizada con proyectos que tengan un ambiente similar al nuestro,
para que pueda apoyar en la realizacin de una auditora objetiva. El Auditor
debe identificar, con el apoyo del Project Leader, a todos los que participan en
el proyecto y debe elegir a las personas necesarias para cuestionarlas y
corroborar que CONOCEN el Configuration Management Plan; es decir, que
saben dnde esta documentado, que lo ENTIENDEN, y que lo SIGUEN, esto
ltimo acompaado por EVIDENCIAS. Y en los casos que no se generen
reportes automticos que los avalen, se reconocen como evidencias vlidas
SCREENSHOTS, pantallazos de la informacin donde se refleje.
Configuration Management audit.
What is the Auditor is looking for?
Las secciones que cubre el Request de Auditoria son:
INFORMATION
Verifica que TODO el Equipo de Trabajo sepa dnde est
definido el Plan de la Configuracin, tanto el Project Leader como el Team
Member.
KNOWLEDGE
Trabajo.

Verifica que ese plan lo conoce y lo entiende el Equipo de

DOCUMENTS
Verifica que el Equipo de Trabajo identifica qu es lo que se
va a generar para cada FASE del proyecto
NAMING CONVENTIONS Verifica que el equipo de trabajo conozca las
nomenclaturas definidas a USAR en cada uno de los ELEMENTOS que se
generan en el proyecto.
PROJECT BASELINES
genere los BASELINES.
STRUCTURE OF THE

Verifica que el Equipo de Trabajo conozca y siga, o

REPOSITORY Verifica que el Equipo de Trabajo ENTIENDE la estructura del

repositorio y SIGUE la ESTRUCTURA, la NOMENCLATURA y los ACUERDOS de
ETIQUETADO. En esta seccin es NECESARIO que se agregue la EVIDENCIA en
Change Report to the Configuration tems, como se coment anteriormente a
travs de reportes que generen la misma herramienta, o bien, a travs de
SCREENSHOTS, o pantallazos donde se observe la evidencia.
AUTOMATED TOOLS

Verifica si hay Herramientas Actualizadas.

Con base al resultado de la Auditoria, pueden generarse los Action Item

Requests necesarios para corregir aquellas desviaciones identificadas en el
proyecto.
No podr CERRARSE el REQUEST de AUDITORIA, hasta que las acciones que se
formalizaron a travs de esos Action Item Requests se hayan realizado y
tambin se hayan CORREGIDO las DESVIACIONES que se identificaron en la
AUDITORIA.