Memoria Proyecto - Susana

“Administración de la configuración en el
desarrollo del Software – Sistema para

Laboratorio de Alimentos y Bebidas (SLAB)”
Memoria de Proyecto
Que para obtener el título de
Lic. En Sistemas de Información
Administrativa
Presenta
Susana Elizabeth Lizárraga Coronado
Guaymas, Sonora; Agosto 2010

ii
2
ÍNDICE
Pág.
Agradecimientos.......................................................................................................... iii
Dedicatorias ................................................................................................................ iv
CAPÍTULO I .................................................................................................................5
I. INTRODUCCIÓN ......................................................................................................5
1.1 Antecedentes .............................................................................................5
1.2 Definición del Problema .............................................................................8

1.3 Justificación ...............................................................................................9
1.4 Objetivo .....................................................................................................9
CAPÍTULO II ..............................................................................................................10
II. MÉTODO................................................................................................................10
2.1 Marco Teórico .........................................................................................10
2.1.1 ¿Por qué es importante la Administración de Configuración?...........10
2.1.2 Tres reglas simples para la administración de configuración ............11

2.1.3 ¿Qué es la administración de la configuración? ................................12
2.1.4 Objetivos de la administración de configuración................................14
2.1.5 Terminología......................................................................................14
2.1.6 Proceso de administración de configuración .....................................16
2.1.7 Beneficios del proceso de gestión de configuración ..........................21
2.1.8 ¿Lo que hace difícil la administración de configuración? ..................22
2.2 Caso Práctico ...........................................................................................24
III.RESULTADOS .......................................................................................................45
IV.CONCLUSIONES ..................................................................................................51
V.BIBLIOGRAFÍA ......................................................................................................52
3iii
Agradecimientos
Primeramente agradezco a Dios por haberme dado las herramientas necesarias para
mantenerme en este proyecto y sobre todo por darme las fuerzas necesarias cada mañana
durante 4 años para poder concluir un ciclo importantísimo en mi vida personal y profesional.
Igualmente deseo hacer un reconocimiento a mi asesor Mtro. Roberto Limón Ulloa por todo
el apoyo brindado en este lapso y especialmente por la amistad y compañerismo que otorga
sinceramente, por su tiempo y consejos, gracias. A mi revisor Mtro. Marco A. Tellechea R. por
ser un excelente coordinador y siempre estar al tanto de sus alumnos.
Este trabajo no se hubiera podido concluir sin el apoyo incondicional de mi familia, mis
padres, hermanas, sobrinos y cuñado que siempre confiaron en mí, ahora más que nunca se
que estarán orgullosos de que llegue el último título universitario a “la pared del éxito”.
Por último quiero hacer mención de agradecimiento a mis amigos, compañeros y la mejor
amiga que alguien puede tener, Eliana, gracias amiga por ser esa amiga tan especial para mí,
por siempre mostrar tu mejor lado y apoyarme en todo sin importar que sea bueno o malo,
gran parte de esto te pertenece a ti también.
4 iv
Dedicatorias
Este trabajo va dedicado especialmente a mis padres y hermanas, que sin su ayuda nada de
esto hubiera sido posible. Gracias por todo el apoyo que me brindaron a lo largo de estos 4
años de vida universitaria, por estar al pendiente de mis actividades y ser esencialmente mi
fuente de inspiración, gracias hermanas por ser el mejor ejemplo a seguir. Como olvidar a mis
pequeños grandes amores Andrea y Raulito que siempre estuvieron ahí para endulzarme la
vida en los momentos más difíciles. Gracias Miguel por estar para mí incondicionalmente.
5
CAPÍTULO I
I. INTRODUCCIÓN
1.1 Antecedentes
En la actualidad realizar un Software no es simplemente comenzar a codificar,

terminar el sistema y entregarlo al cliente; hacer un sistema de verdad va mas allá de
cualquier codificación, ya que se debe de involucrar inicialmente al cliente, quien
viene a manifestar todas sus necesidades para que consecuentemente estas sean
6
satisfechas al concluir su demanda. Sin embargo, estos requerimientos deben de

quedar plasmados para trabajar en base a ellos o poder hacer modificaciones en un
futuro. La administración de la configuración del Software viene a brindar este común
entendimiento entre necesidades del usuario y las actividades que estarán
plasmadas en los elementos de configuración. Entendiendo estos últimos como un
documento producido o adquirido, que por sus características es distinguible de los
demás y cuya evolución interesa administrar.
La motivación de realizar este trabajo nace instantáneamente después de concluir la

práctica profesional NOVUTEK, en donde se desempeñó por un periodo de dos
semestres el papel de Administración de la Configuración del Proyecto, en este lapso
se desarrolló un sistema denominado SLAB – Sistema para Laboratorio de Alimentos
y Bebidas. En el cual, desde su inicio hasta concluir la primera fase de elaboración
este fue documentado.
El propósito de la administración de la configuración radica esencialmente en

establecer y mantener la integridad de todos los datos y documentos que vayan
surgiendo en el ciclo de vida del Software; esto significa controlar los cambios que
vayan surgiendo, aprobar documentos, actualizar datos, evitar duplicidad de
información y sobre todo controlar errores. Dentro de la práctica profesional
NOVUTEK, desde un principio se tuvo un acercamiento con el cliente para que este
brindara rápidamente sus necesidades en forma de requerimientos, en donde al
instante todo esto se fue documentado en los respectivos elementos de
configuración que iban saliendo conforme se avanzaba con el proyecto; todos estos
formatos se encontraban dentro de un Repositorio, el cual es un sitio centralizado en
donde se mantenían y almacenaba la información de manera digital, beneficiando de
gran forma el acceso a toda la información necesaria para la creación del Software.
Sin embargo, para poder ingresar al repositorio se asignaron cuentas de usuario
individualmente.
7
Un cambio puede ocurrir en cualquier momento y por cualquier razón. Dentro de la

misma práctica profesional solían ocurrir improvisadamente, e incluso cuando ya se
había avanzado demasiado en un formato, debido en varias ocasiones a petición del
cliente, ya que conforme se avanzaba un poco más en el proceso de elaboración
estos entendían más las importancia que se le debía de dar al trabajo que se
desempeñaba en las prácticas profesionales. Para que un cambio se pudiera
efectuar era necesario que el practicante lo solicitara por medio de una Solicitud de
Cambio (SCAM) en el cual debía de comunicarse el por qué del cambio y hacerlo
llegar a las personas responsables para autorizar y aprobar dicho cambio. Dentro del
repositorio existía una carpeta para el control de la configuración y dentro de esta se
encontraba la de solicitud de cambios en donde se graban estos formatos.
Al finalizar cada etapa, en donde solo se pudo documentar la fase de inicio y

elaboración, era necesario realizar el documento denominado Reporte de Estatus de
la Configuración (RESCO), el cual permitía al equipo de trabajo saber en qué etapa
estaban, qué tanto habían realizado y qué se permanecía haciendo. El administrador
de la configuración debía de conocer muy bien este documento y sobre todo saber
cómo llenarlo, sin que se olvidara anexar ningún formato ya registrado en el
repositorio.
Con el fin de lograr una excelente comunicación entre los integrantes de trabajo, es
necesario ir realizando cada documento sin excepción alguna, ya que esto contribuye
a la buena organización y principalmente se conoce que es lo que está aportando
cada quien en el desarrollo del Software. Otra ventaja que se presenta por medio de
la administración de la configuración es en el momento de presentar auditorías; en la
práctica profesional se logró auditar la primera fase del ciclo de vida del Software, en
donde los hallazgos encontrados se pudieron manipular fácilmente gracias a la
administración de la configuración del proyecto, sin embargo, existieron ciertos
conflictos en la actualización de varios documentos.
8
1.2 Definición del problema
Cuando se desarrolla un Software este parte de las necesidades que expone el

cliente ante el equipo de trabajo que lo va a desarrollar, pero conforme pasa el
tiempo estas a su vez van transformándose y siendo aun más exigentes. Cuando no
se aplica la administración de la configuración para el desarrollo de un Software es
fatal. Los cambios y/o modificaciones no se pueden evitar, es por eso que la gestión
de la configuración se presenta como una serie de actividades para controlar los
cambios que se puedan generar a lo largo del ciclo de vida del proyecto.
Dentro de la práctica profesional NOVUTEK, constantemente se generaban cambios
en las revisiones, que llevaban a modificaciones en los elementos de configuración,
adiciones en los documentos ya producidos y errores en versiones. Todo esto porque
el cliente al principio no entendía la importancia que representaba mantener los
elementos de configuración actualizados e incluso dejaban en segundos términos
aprobar dichos documentos. Estaba fuera del alcance de los practicantes en
mantener los documentos actualizados y aprobados ya que de primera instancia no
se obtenía respuesta del cliente.
Los cambios, renovaciones o modificaciones son inevitables en el ciclo de vida del

Software y sobre todo si se tiene un cliente exigente que tiene grandes expectativas
con el resultado. Por ello sería conveniente informales en la primera reunión de la
importancia que implica este departamento dentro del desarrollo del Software, ya que
por medio de todos estos documentos es como se le va dando forma al producto, y
sin autorizaciones del cliente no se puede seguir avanzando y esto implica pérdida
de tiempo y esfuerzo humano.
¿Cómo obtener una Administración de Configuración de proyectos de Software

siguiendo reglas y parámetros de nivel mundial?
9
1.3 Justificación
El principal provecho que se obtiene al elaborar este proyecto consiste en dar a

conocer cuál es la importancia y el beneficio que ofrece cada uno de los elementos
de configuración que se deben de elaborar al momento de comenzar un producto de
Software. Se logrará también concientizar al cliente, para que este sea más proactivo
y participe mas con este departamento denominado Administración de la
Configuración del proyecto, aunque este no sea totalmente a la vista de los usuarios
es el medio por donde se van obteniendo y dando resultados, contribuyendo de igual
forma en el ahorre de costos, tiempo y espacio.
1.4 Objetivo
Aplicar una correcta Administración de Configuración de proyectos para un desarrollo

de producto de Software bajo estándares de calidad y procesos internacionales.
10
CAPÍTULO II
II. MÉTODO
2.1 Marco Teórico
2.1.1 ¿Por qué es importante la Administración de Configuración?
Hoy en día las TI son un conjunto de redes informáticas integradas que poseen
complejidad y sofisticación. Incluso el ambiente más simple, apoyando solamente
11
algunas aplicaciones empresariales, requiere atención a las configuraciones para

mantener las aplicaciones y el hardware funcionando correctamente.
Los gerentes de las empresas han observado que el 60 por ciento de los impactos
del servicio es debido a problemas de configuración. Más allá de la frustración
personal asociada con tener que resolver los incidentes relacionados con la
configuración, existen también graves impactos relacionados con las empresas
derivadas de una pobre gestión de configuración.
En el nivel más obvio, los problemas de configuración pueden causar fallos

relacionados con el sistema. Los sistemas claves o servicios pueden simplemente
dejar de trabajar, o su funcionamiento perceptiblemente puede degradar, haciendo
que la productividad de los trabajadores de negocios se caiga o se llegue incluso a
una paralización completa. Cuando los sistemas operativos y aplicaciones no se
mantienen al día con claves de seguridad, pueden llegar a ser vulnerables a
violaciones de seguridad y exponer a su organización a los piratas informáticos y
otros responsables de daño interno o externo.
En un nivel menos obvio, si los sistemas se mantienen en un estado estable pero no

corriente por mucho tiempo pueden llegar a ser con eficacia imposibles de ponerse al
día. Esto puede afectar grandemente la agilidad del negocio de la organización. Los
viejos sistemas necesitarán ser sustituidos, costando dólares del presupuesto y
potencialmente años valiosos de tiempo. Estos sistemas anticuados pueden también
impedirle tomar ventaja de nuevo software y hardware para mejorar sus operaciones
empresariales.
2.1.2 Tres reglas simples para la administración de configuración
• Regla 1. Mantenga el Control; Tiene que mantener el control de los elementos

de configuración y de la forma que cambian. Si pierde el control, su proceso
no tiene ningún valor.
12
• Regla 2. Utilice la tecnología; El manual de gestión de la configuración

puede resultar imposible. Usted necesita utilizar tecnología para ayudar a
descubrir, registrar, y a mantener la información de configuración.
• Regla 3. La administración de configuración hace que otras cosas sucedan;

La ejecución de la gerencia de configuración por sí mismo es una pérdida de
tiempo. El programa de gestión de la configuración debe permitir el cambio de
incidentes, problemas, y programas de liberación de gestión si desea ver un
cambio.
2.1.3 ¿Qué es la administración de la configuración?
La Gestión de la configuración del software es uno de los aspectos importantes que

se deben tener en cuenta al momento de planear el desarrollo de sistemas
informáticos.
El arte de coordinar el desarrollo de software para minimizar la confusión, se
denomina administración de configuración. La meta es maximizar la productividad
minimizando los errores. Es una actividad de autoprotección que se aplica durante el
proceso del software. Sirve para identificar el cambio, controlar el cambio, garantizar
que el cambio se implemente adecuadamente e informar del cambio a todos aquellos
que puedan estar interesados.
La administración de configuración, es el proceso que ofrece una visión lógica de la

infraestructura de TI y servicios mediante la identificación, mantenimiento y
verificación de las versiones y el estado de los elementos de configuración
existentes. Dentro de esta definición, un elemento de configuración (ECO) es
cualquier componente que está bajo el control de, y es supervisado por, el proceso
de gestión de la configuración.
13
La Biblioteca de Infraestructura de Tecnologías de Información (ITIL) y el estándar

ISO 20000 han escrito extensamente sobre las mejores prácticas para la
administración de configuración, y mencionan tres consejos que hay que seguir:
• Mantener el control: Para que la gerencia de configuración tenga cualquier

clase de vida útil en sus operaciones, debe mantener control sobre sus
elementos de configuración y estar continuamente actualizados. Una vez que
su proceso de configuración llega a ser añejo, pierde valor.
• Seguimiento de los elementos de configuración correctos: Si intenta

seguirle la pista a todo, probablemente fracasara. Es de vital importancia
escoger los elementos de configuración que necesita y puede seguir.
• Crear un repositorio: Para hacer todas las maravillas de la administración de

configuración, debe tener un repositorio de elementos de configuración. Sin él,
su programa no será sostenible. ITIL define un repositorio como la base de
datos de la gestión de configuración. Sin importar qué acercamiento tendrá
con el repositorio de la configuración, necesita contar con uno.
La administración de la configuración se realiza desde que comienza el proyecto

hasta que termina e involucra la recolección y el mantenimiento de toda la
información sobre hardware y software de los sistemas que se usen. Forma parte de
un proceso más general de gestión de la calidad del software, de hecho, la misma
persona o grupo que se encarga de la calidad del software puede encargarse
también de este apartado. La finalidad de todo esto es tener controlados todos los
cambios que se hacen sobre el software y tener toda la información necesaria en el
momento del mantenimiento.
• Diferencia entre mantenimiento del software y configuración del

software: Mantenimiento son actividades de ingeniería del software que se
14
producen después de que se haya entregado, mientras que configuración son

actividades de seguimiento y control, mientras se sigue desarrollando el
software.
2.1.4 Objetivos de la administración de configuración
Los objetivos son los siguientes:
• Evaluar y mantener la integridad de los productos.

• Evaluar y controlar los cambios.
• Facilitar la visibilidad sobre el producto.
La integridad en este contexto es:
• Saber exactamente lo que se ha entregado al cliente

• Saber el estado y contenido de las líneas base y elementos de configuración
Las actividades a realizar para conseguir los objetivos son:
• Identificación de la configuración.
• Control de cambios de la configuración.
• Generación de informes de estado.
• Auditoría de la configuración.
2.1.5 Terminología
• Artefacto: se define como un producto terminado, como el código o el

ejecutable, pero más habitualmente se refiere a la documentación generada a
lo largo del desarrollo del producto en lugar del producto en sí.
15
• Cambio: adición, modificación o borrado de algún elemento de una línea

base.
• Configuración: término genérico usado para describir un grupo de elementos

de configuración que funcionan de forma conjunta para entregar un producto o
un servicio. La configuración se usa también para describir el establecimiento
de parámetros de uno o más elementos de configuración.
• Control de configuración: actividades que comprenden el control de los

cambios sobre elementos de configuración. Esto incluye la evaluación,
coordinación, aprobación o rechazo de los cambios. La implementación de los
cambios incluye los propios cambios, desviaciones y excepciones que pueden
impactar a la configuración.
• Gestión de cambios: proceso responsable de controlar el ciclo de vida de

todos los cambios.
• Gestión de configuración: proceso cuyo propósito es establecer y mantener

la integridad de los productos y servicios desarrollados.
• Elemento de configuración (CI): un conjunto de productos de trabajo que

van a permanecer bajo gestión de configuración y considerado como una
entidad dentro del proceso de gestión de configuración.
• Línea base: Se define como línea base a una especificación o producto que
se ha revisado y sobre los que se ha llegado a un acuerdo que de ahí en
adelante sirve como base para un desarrollo posterior y que puede cambiarse
solamente a través de procedimientos formales de control de cambios. (O sea
es la base desde la que vamos a desarrollar nuestro sistema, esa base está
bien y listo).
16
• Revisiones: Se define revisión como una versión que se construye sobre otra
versión anterior. El término revisión generalmente se asocia a la noción de
corrección de errores, esto es, hacer cambios a un programa que corrigen
solo errores en el diseño lógico pero no afectan las capacidades funcionales
documentadas, dado que ningún requerimiento ha cambiado.
• Variante: nueva versión de un elemento que será añadida a la configuración

sin reemplazar una versión anterior.
• Versión: Una versión es una instancia de un elemento de Configuración. El

término se usa para señalar a un elemento de Configuración del software que
tiene un conjunto definido de características funcionales.
2.1.6 Proceso de administración de configuración
La administración de configuración da respuesta a las siguientes cuestiones:
• ¿Cómo identifica y gestiona una organización las muchas versiones existentes

de un programa (y su documentación) de forma que se puedan introducir
cambios eficientemente?
• ¿Cómo controla la organización los cambios antes y después de que el
software sea distribuido al cliente?
• ¿Quién tiene la responsabilidad de aprobar y de asignar prioridades a los
cambios?
• ¿Cómo podemos asegurar que los cambios se han llevado a cabo
adecuadamente?
• ¿Qué mecanismos se usan para avisar a otros de los cambios realizados?
17
Estas cuestiones se resuelven en las cuatro tareas de las que consta la

administración de la configuración:
1. Identificación. Se trata de establecer estándares de documentación y un

esquema de identificación de documentos.
2. Control de cambios. Consiste en la evaluación y registro de todos los
cambios que se hagan de la configuración de software.
3. Auditorías de configuraciones. Sirven, junto con las revisiones técnicas
formales para garantizar que el cambio se ha implementado correctamente.
4. Generación de informes. Consiste en informar acerca del estado de los
componentes de un producto y de las solicitudes de cambio, recogiendo
estadísticas acerca de la evolución del producto.
1. Identificación de la configuración
La tarea de identificación de la Gestión de Configuraciones tiene tres objetivos:
• Definir una estructura de documentación organizada de un modo inteligible y

predecible. Es decir, dar un formato.
• Proporcionar métodos para revisiones y añadir los cambios conforme se
producen. (Identificar cada documento para la revisión y los cambios).
• Relacionar los cambios con “quién, qué, cuándo, porqué, cómo” para facilitar
el control.
El proceso de identificación de la configuración es el siguiente:
• La tarea de identificación empieza con la definición de los elementos de la

configuración del software representativos de los productos en cada línea
base establecida. El formato, los contenidos y los mecanismos de control para
toda la documentación son definidos para enlazar la información cuando la
jerarquía de la configuración se despliega.
18
• Se asignan identificadores apropiados a todos los programas, documentos y

periféricos, usando un esquema numerado que proporciona información sobre
el elemento de la configuración del software.
• Finalmente, la identificación debe facilitar el control de cambios, para
acomodar actualizaciones y modificaciones.
La configuración software se mantiene durante la vida del sistema software. Se

establecen bibliotecas y ayudas de referencia como soporte a las configuraciones
generadas.
Pueden aplicarse tres enfoques fundamentales al control de la documentación:
1. Todos los documentos software y otros elementos de cada configuración son

mantenidos como parte de una biblioteca de esquema/documentación de
ingeniería ya establecida.
2. Se establece una librería de software especial para todas las configuraciones
software.
3. Se establece una librería de software on-line, soportada por un procesador de
textos y facilidades de recuperación de documentos accedidos por terminales
de computadora.
2. Control de Cambios
El control de cambios es un mecanismo para la evaluación y aprobación de los
cambios hechos a elementos de la configuración software durante el ciclo de vida.
Pueden establecerse tres distintos tipos de control:
1. Control individual, antes de aprobarse un nuevo elemento.

2. Control de Gestión (u organizado), conduce a la aprobación de un nuevo
elemento.
3. Control formal, se realiza durante el mantenimiento.
19
• Control individual (o informal)

Cuando un elemento de la configuración está bajo control individual, el técnico
responsable cambia la documentación como se requiere. Aunque se mantiene un
registro informal de revisiones, tales registros no se ponen generalmente en el
documento. El control individual se aplica durante las etapas más importantes del
desarrollo del documento y se caracteriza por los cambios frecuentes.
• Control de gestión
Implica un procedimiento de revisión y aprobación para cada cambio propuesto en la
configuración. Como en el control individual, el control a nivel de proyecto ocurre
durante el proceso de desarrollo pero es usado después de que haya sido aprobado
un elemento de la configuración software. Este nivel de control de cambios se
caracteriza por tener menos cambios que el control individual. Cada cambio es
registrado formalmente y es visible para la gestión.
• Control de cambios formal

Ocurre durante la fase de mantenimiento del ciclo de vida software (el producto ya
está implantado). El impacto de cada tarea de mantenimiento se evalúa por un
Comité de Control de Cambios (CCC), el cual aprueba las modificaciones de la
configuración software.
El Comité de Control de Cambios (CCC)

El CCC es el "órgano de gobierno" para todos los problemas relacionados con la
GCS. En general, la CCC está compuesta por los miembros de las organizaciones de
usuarios/pedidores de cambios y de desarrolladores.
Para pequeños proyectos, el CCC puede estar formado por uno de los
representantes de los usuarios, requeridores de cambios y desarrolladores. Para
grandes proyectos, el CCC puede estar organizado en una jerarquía que trate los
problemas del sistema, del hardware y del software por separado.
20
El CCC puede llegar a formar parte del desarrollo del proyecto de software y hacer
las siguientes tareas:
1. Analizar el impacto de cambios "revolucionarios" en el sistema, usando para

asesorarse, las disciplinas técnicas que se requieran.
2. Categorizar y dar prioridad a los cambios conforme son pedidos y aprobados.
3. Intervenir en los conflictos entre disciplinas y organizaciones que surgen para
ser cambiados.
4. Garantizar que las propiedades de mantenimiento de registro y contabilización
se cumplan.
3. Auditorías de Configuraciones
¿Cómo podemos asegurara que el cambio se implementó correctamente? Con

revisiones técnicas formales y auditorias de configuración del software. Las
revisiones técnicas se centran en la corrección técnica del elemento de configuración
que ha sido modificado. Se deben llevar a cabo para cualquier cambio que no sea
trivial. Una auditoria de configuración complementa la revisión técnica al comprobar
características que generalmente no tiene en cuenta la revisión, se plantea y
responde las siguientes preguntas:
• ¿Se ha hecho el cambio especificado?

• ¿Se llevo una revisión técnica?
• ¿Se ha seguido el proceso del software y se han aplicado los estándares de
ingeniería del software?
• ¿Se han resaltado los cambios en el ECS?
• ¿Se han seguido procedimientos de GCS para señalar el cambio, registrarlo y
divulgarlo?
• ¿Se han actualizado todos los ECS relacionados?
21
4. Generación de Reportes
Responde a las siguientes preguntas:
• ¿Qué paso?
• ¿Quién lo hizo?
• ¿Cuándo paso?
• ¿Qué más se afecto?
Básicamente se encarga de producir los informes para todos los cambios y cosas
que se le hagan al software por cada uno de los desarrolladores, así todos están al
tanto de lo que se va haciendo, de esta forma se evita el síndrome de la mano
izquierda ignora lo que hizo la derecha, y un desarrollador va a cambiar lo que otro
ya hizo.
2.1.7 Beneficios del proceso de gestión de configuración
La gestión de la configuración es una forma efectiva y eficiente de gestionar y

comunicar los cambios en líneas base y elementos de configuración a lo largo del
ciclo de vida.
A continuación se resaltan algunos beneficios de la implementación del proceso de

gestión de configuración para la organización.
• Asegurar la correcta configuración del software.

• Proporcionar la capacidad de controlar los cambios.
• Reducir los sobreesfuerzos causados por los problemas de integridad.
• Garantizar que todo el equipo trabaja sobre una misma línea base de
productos.
22
¿Qué puede ocurrir si no se realiza una gestión de configuración efectiva?
Existe un riesgo alto de entregar al cliente la versión incorrecta del producto:
• Versión con errores

• Versión con cambios que no han sido probados
• Versión que no puede reproducirse
Podríamos llegar a encontrarnos en las siguientes situaciones:
“¿Cuál es la versión que tiene el cliente?”

“No puedo reproducir el problema en mi versión”
“¿Qué ha ocurrido con la corrección que hice el mes pasado?”
“¿Está corregido el error también en esa versión?”
Si no se realiza una buena gestión de configuración puede ocurrir que no podamos

disponer de un inventario completo de los componentes del sistema cuando
necesitemos, que haya que realizar re-trabajo durante las pruebas porque los
componentes que probemos no sean los que debieran, o que no se pueda recuperar
una línea base anterior para realizar mantenimiento. Todo ello conlleva una pérdida
de dinero y recursos.
2.1.8 ¿Lo que hace difícil la administración de configuración?
Mas allá de las dificultades iniciales con el alcance de los programas y el apoyo de
las organizaciones, hay otros atributos inherentes de los sistemas de hoy que
realmente dificultan la problemática.
• Sistemas Integrados: mientras que los sistemas llegan a ser más integrados,
un nuevo conjunto de elementos de configuración se desarrollan. El software
intermedio viene a ser un elemento crítico para facilitar la correcta ejecución
23
de las transacciones. La mala gestión de configuración a este nivel puede

causar problemas significativos.
• Arquitectura Orientada a Servicios (SOA): La razón de que una arquitectura
SOA funcione bien es que se consolida un conjunto de funciones comunes a
muchas aplicaciones en un único servicio. Si una configuración del servicio de
SOA y sus relaciones no se manejan bien, muchas porciones de la
infraestructura de TI pueden recibir el impacto.
• Malas Configuraciones: Muchas veces los departamentos de TI despliegan
configuraciones malas o inestables. Las malas configuraciones pueden tener
un efecto dominó que se extienden a muchos otros sistemas en el conectado
mundo de TI.
24
2.2 Caso Práctico
El documento denominado Plan de Administración de la Configuración del

Software (PACS), se toma como caso práctico para efectos de este trabajo, el cual
se irá detallando y explicando tal cual su estructura, a lo largo de este capítulo.
1 Introducción
La implementación de la administración de la configuración del software será llevado

a cabo por tres organismos funcionales:
• Administrador de la configuración del proyecto (ACP)

• Comité de control de cambios
• Administrador global de la configuración (AGC)
1.1 Propósito
Este documento está diseñado para asistir a los miembros del proyecto en el
entendimiento de cómo la administración de la configuración del software será
conducida en el proyecto. Éste define y detalla los roles y responsabilidades para la
administración de la configuración del software y el proceso de cambios que será
conducido en el proyecto.
1.2 Alcance
El alcance de este plan está limitado al proyecto SLAB – Almacén y Caja.
1.3 Material de referencia

Referencia Descripción
[PAPS] Plan de administración de proyecto de software
[PASCAS] Plan de aseguramiento de la calidad de software
[F_CALENDA Calendario de trabajo del proyecto
25
RIO]
[G_GLB] Guía de líneas base y convenciones de configuración
[G_GRESCO] Guía de reporte de estatus de la configuración
[PR_PAC] Procedimiento de administración de cambios
2 Identificación de la configuración del Software
2.1 Identificación de los elementos de configuración
2.1.1 Identificación de los elementos de configuración de

documentos
Los nombres de los archivos físicos de cada documento están establecidos de

acuerdo con el siguiente estándar:
No. Estándar
1 proyId_docId_verId
2 proyId_docId_fechaId
3 proyId_docpadreId_docId_fechaId
4 proyId_docId_faseId
5 proyId_docId
6 proyId_docId_nu
7 proyId_docId_docIdrev
8 proyId_docId_cuId_verId
26
Donde,
Identificad Descripción Estándar Ejemplo
or
proyId Identificador de proyecto YYYZZZZ ITS0001
docId Identificador de documento Refiérase a la LREQ
sección
“identificación de
fases”
verId Identificador de versión 0.0.0 1.0.0
fechaId Identificador de fecha AAAAMMDD 20070101
docpadreI Identificador del documento Refiérase a la PACS
d padre sección
“identificación de
fases”
faseId Identificador de las fases Inicio Inicio
Elaboración
Construcción
Despliegue
nu Número consecutivo 01, 02, 03… 01
cuId Identificador del caso de uso: 01 Iniciales de 01ME
número consecutivo e iniciales nombre del caso de
del nombre del caso de uso uso
docIdrev Identificador del documento o Refiérase a la ECU
código al que se le realiza la sección
revisión entre colegas “identificación de
fases”
Los ECOs que son administrados bajo una herramienta de configuración y que
tienen el estándar 1 <proyId_docId_verId> la versión no se llevará en el nombre del
documento, ya que la herramienta es la que la administra, pero será llevado en el pie
de página y en la hoja de revisiones si dicho documento la incluye.
Si se repiten los nombres de los documentos en una misma carpeta dentro del
repositorio, al nombre del documento se le debe agregar el identificador nu que
corresponde a un número consecutivo (el número consecutivo se agregará solo al
nombre, no aplica para el pie de página). Esto aplica para cualquier estándar de
nombramiento.
27
Ejemplo: fsw0014_minuta_20070301_01, fsw0014_minuta_20070301_02,

fsw0014_minuta_20070301_03.
La siguiente tabla cubre los elementos de configuración (ECO) específicos para el

proyecto, contiene el identificador del documento, ruta donde se ubica dentro del
repositorio del proyecto y el estándar por el que es nombrado el documento. El
estándar usado en cada uno de los ECO está especificado en la columna
“Estándar”. Las rutas en color rojo indican que el ECO aún no existe en el repositorio
del proyecto, pero al momento de crearse se colocará en dicha ruta.
Productos bajo estricto control de configuración, son aquellos que una vez
puestos en línea base, su versión debe ser controlada a través del uso de etiquetas
y atributos (línea base) o bien administrados bajo el procedimiento de administración
de cambios [PR_PAC] una vez que estén en línea base y requieran modificaciones;
estos productos serán identificados con un asterisco (*).
Productos bajo uso de herramienta, son aquellos que serán llevados en una
herramienta y por lo tanto no usarán formatos para generarlos; estos productos
serán identificados con un asterisco (*) y se eliminará el DocId, ruta y estándar.
Elementos de configuración
Productos
Productos
bajo estricto
Nombre DocId Ruta Estándar bajo uso de
control
herramienta
configuración
Administración\Calidad
Análisis a posteriori F_APOS \\10.2.60.90\ITS00027\
Calidad\Análisis a 4
posteriori
Lista de verificación de L_LVACF \\10.2.60.90\ITS00027\c
auditoría de configuración alidad\auditorias\acf\list 2
física a de verificación
Lista de verificación de L_LVAPR \\10.2.60.90\its00027\ca
auditoría de proyecto lidad\auditorias\apr\lista 2
de verificación
Lista de verificación de L_LVACP \\10.2.60.90\its00027\ca
auditoría de cierre de lidad\auditorias\auditorí
2
proyecto a de cierre\lista de
verificación
28
Productos
Productos
bajo estricto
control
herramienta
configuración
Reporte de auditoría F_RPTA \\10.2.60.90\its00027\ca
(configuración física) UDITORI lidad\auditorias\acf\repo
A rte de 3
auditoría\Calidad\Audito
rias
(proyecto) UDITORI lidad\auditorias\apr\repo 3
A rte de auditoría
(cierre de proyecto) UDITORI lidad\auditorias\auditorí
3
A a de cierre\reporte de
auditoría
Lista de verificación de L_LVETC \\10.2.60.90\its00027\ca
estimación de tareas y lidad\listas de
calendario verificación\Estimacione 2
s de Tareas y
Calendario
Lista de verificación del L_LVPAP \\10.2.60.90\its00027\ca
PAPS S lidad\listas de 2
verificación\PAPS
Lista de verificación del L_LVPAC \\10.2.60.90\its00027\ca
PACS S lidad\listas de 2
verificación\PACS
Lista de verificación de L_LVVISI \\10.2.60.90\its00027\ca
VISION ON lidad\listas de 2
verificación\VISIÓN
Lista de verificación del L_LVRE \\10.2.60.90\its00027\ca
libro de requerimientos Q lidad\listas de 2
verificación\LREQ
Lista de verificación de L_LVFINI \\10.2.60.90\its00027\ca
fase de inicio CIO lidad\listas de
2
verificación\Fase de
Inicio
Lista de verificación de L_LVFEL \\10.2.60.90\its00027\ca
fase de elaboración ABORAC lidad\listas de
2
ION verificación\Fase de
Elaboración
Lista de verificación de L_LVFC \\10.2.60.90\its00027\ca
fase de construcción ONSTRU lidad\listas de
2
CCION verificación\Fase de
Construcción
Lista de verificación de L_LVFDE \\10.2.60.90\its00027\ca
fase de despliegue SPLIEGU lidad\listas de 2
E verificación\Fase de
29
Productos
Productos
bajo estricto
control
herramienta
configuración
Despliegue
Libro de métricas F_LMET \\10.2.60.90\its00027\ca
5
lidad\lmet
Formato de preparación F_PREP \\10.2.60.90\its00027\ca
de revisión ARACIO lidad\revisiones entre
7
NREV colegas\preparación de
revisión
Revisión entre colegas F_REVC \\10.2.60.90\its00027\ca
OLEGAS lidad\revisiones entre
7
colegas\revisión entre
colegas
Administración\Comunicación
Bitácora de asuntos del F_BITAC \\10.2.60.90\its00027\co
proyecto ORA municación\bitácora de 2
asuntos
Agenda de reunión F_AGEN \\10.2.60.90\its00027\co
(proyecto) DA municación\proyecto\ag 2
endas
Minutas del proyecto F_MINUT \\10.2.60.90\its00027\co

A municación\proyecto\mi 2
nutas
Correos electrónicos del \\10.2.60.90\its00027\co
proyecto municación\proyecto\cor
reos
Agenda de reunión F_AGEN \\10.2.60.90\its00027\co
(cliente) DA municación\cliente\agen 2
das
Minutas del cliente F_MINUT \\10.2.60.90\its00027\co
A municación\cliente\minu 2
tas
Correos electrónicos del \\10.2.60.90\its00027\co
cliente municación\cliente\corre
os
Administración\Configuración
Reporte de estatus de la F_RESC \\10.2.60.90\its00027\co
4
configuración O nfiguración\resco
Solicitudes de cambio F_SCAM \\10.2.60.90\its00027\co
6
nfiguración\scam
Solicitudes de F_SOLIC \\10.2.60.90\its00027\co
configuración física ITUDESC nfiguración\Solicitudes 6
F de Configuración Física
Administración\Información del cliente
30
Productos
Productos
bajo estricto
control
herramienta
configuración
Carta de liberación F_CART \\10.2.60.90\its00027\ad
ALIB ministración\carta de 2
liberación
Encuesta de satisfacción F_ENCU \\10.2.60.90\its00027\ad
del cliente ESTA ministración\encuesta 2
de satisfacción
Administración\Monitoreo y control
Reporte de avance de F_RPTP \\10.2.60.90\its00027\co
proyecto ROYECT municación\reportes de 2
O avance
Administración\Planes del proyecto
Evaluación de la iteración F_EVAL \\10.2.60.90\its00027\pl
UA anes del 2
proyecto\Evalúa
Estimación del proyecto F_ESTP \\10.2.60.90\its00027\pl
ROYECT anes del 1 *
O proyecto\Estimaciones
Cuestionario de ciclo de F_CCV \\10.2.60.90\its00027\pl
vida anes del
2
proyecto\Cuestionario
de Ciclo de Vida
Formato de adaptación F_ADA \\10.2.60.90\its00027\pl
anes del
1 *
proyecto\Formato de
Adaptación
Plan de administración de F_PACS \\10.2.60.90\its00027\pl
la configuración del anes del 1
software (PACS) proyecto\PACS
Plan de administración de F_PAPS \\10.2.60.90\its00027\pl
proyectos de software anes del proyecto\PAPS 1
(PAPS)
Herramienta de F_PARIS \\10.2.60.90\its00027\pl
administración de riesgos H anes del 1
(PARISH) proyecto\PARISH
Plan de aseguramiento de F_PASC \\10.2.60.90\its00027\pl
la calidad del software AS anes del 1
(PASCAS) proyecto\PASCAS
Plan de comunicación del F_COMU \\10.2.60.90\its00027\pl
proyecto NICACIO anes del proyecto\Plan 1
N de Comunicación
Plan de integración F_PINT \\10.2.60.90\its00027\pl
anes del proyecto\Plan 1 *
de Integración
31
Productos
Productos
bajo estricto
control
herramienta
configuración
Calendario de trabajo del F_CALE \\10.2.60.90\its00027\pl
proyecto NDARIO anes del proyecto\Plan
1
(cascada/iteración) de Iteración y
Calendario
Plan de pruebas del F_PPRS \\10.2.60.90\its00027\pl
sistema anes del proyecto\Plan 1 *
de Pruebas
Plan de administración de F_RECU \\10.2.60.90\its00027\pl
recursos del proyecto RSOS anes del proyecto\Plan 1
de Recursos
Administración\Toma de decisiones
Matriz de análisis de F_MAD \\10.2.60.90\its00027\D
decisión ecisiones\Matriz de 2
Análisis
Reporte ejecutivo de F_RED \\10.2.60.90\its00027\D
decisiones ecisiones\Reporte 2
Ejecutivo
Directorio de trabajo
Administrador de \\10.2.60.90\its00027\dir
aseguramiento de calidad _trabajo\AAC
(AAC)
Administrador de la \\10.2.60.90\its00027\dir
configuración del proyecto _trabajo\ACP
(ACP)
Administrador de base de \\10.2.60.90\its00027\dir
datos _trabajo\Administrador
de BD
Analista de sistemas \\10.2.60.90\its00027\dir
_trabajo\Analista
Administrador de \\10.2.60.90\its00027\dir
proyectos (AP) _trabajo\AP
Arquitecto \\10.2.60.90\its00027\dir
_trabajo\Arquitecto
Diseñador \\10.2.60.90\its00027\dir
_trabajo\Diseñador
Diseñador gráfico \\10.2.60.90\its00027\dir
_trabajo\Diseñador
Gráfico
Integrador \\10.2.60.90\its00027\dir
_trabajo\Integrador
Ingeniero de pruebas (IP) \\10.2.60.90\its00027\dir
32
Productos
Productos
bajo estricto
control
herramienta
configuración
_trabajo\IP
Ingeniero de software (IS) \\10.2.60.90\its00027\dir
_trabajo\IS
Ingeniería\Analisis
Visión F_VISIO \\10.2.60.90\its00027\pl
N anes del 1 *
proyecto\Visión
Reglas de Negocio F_REGL \\10.2.60.90\its00027\pl
AS anes del
1 *
proyecto\Reglas de
Negocio
Modelo de análisis F_MODE \\10.2.60.90\its00027\pl
LOANALI anes del
1 *
SIS proyecto\Modelo de
Análisis
Glosario F_GLO \\10.2.60.90\its00027\pl
anes del 1 *
proyecto\Glosario
Libro de requerimientos F_LREQ \\10.2.60.90\its00027\pl
(LREQ) anes del 1 *
proyecto\LREQ
Especificaciones de F_ECU \\10.2.60.90\its00027\pl
casos de uso (ECU) anes del 8 *
proyecto\LREQ\ECU
Priorización de Casos de F_PCU \\10.2.60.90\its00027\plan
Uso es del 1
proyecto\LREQ\PCU
Matriz de rastreabilidad F_MARE \\10.2.60.90\its00027\pl
de requerimientos anes del 1
(MARE) proyecto\MARE
Ingeniería\Arquitectura
Arquitectura de software F_ARQUI \\10.2.60.90\its00027\pl
TECTUR anes del 1 *
A proyecto\Arquitectura
Ingeniería\Despliegue
Release \\10.2.60.90\its00027\pl
anes del
*
proyecto\Unidad de
Distribución\Release
Notas de liberación F_NLIB \\10.2.60.90\its00027\pr
uebas\notas de 2
liberación
33
Productos
Productos
bajo estricto
control
herramienta
configuración
Ingeniería\Diseño
Diseño de software F_DISEÑ \\10.2.60.90\its00027\pl
O anes del
1 *
proyecto\Diseño de
Software
Ingeniería\Implementación
Código fuente \\10.2.60.90\its00027\C
*
ódigo\Código Fuente
Build \\10.2.60.90\its00027\pl
anes del
*
proyecto\Unidad de
Distribución\BUILD
Ingeniería\Pruebas
Diseño y resultado de F_DRPR \\10.2.60.90\its00027\pr
pruebas (aceptación) UEBAS uebas\aceptación\diseñ
2
o y resultado de
pruebas
Documento de aceptación F_ACEP \\10.2.60.90\its00027\pr
de pruebas (aceptación) TACION uebas\aceptación\acept 2
PR ación de pruebas
pruebas (funcionales) UEBAS uebas\funcionales\diseñ
2
o y resultado de
pruebas
de pruebas (funcionales) TACION uebas\funcionales\acept 2
pruebas (integración) UEBAS uebas\integración\diseñ
2
o y resultado de
pruebas
de pruebas (integración) TACION uebas\integración\acept 2
Lista de verificación de L_LVPU \\10.2.60.90\its00027\pr
pruebas unitarias uebas\unitarias\Lista de 9
Verificación PU
Inicio
Propuesta \\10.2.60.90\its00027\ad
ministración\propuesta
Contrato \\10.2.60.90\its00027\ad
ministración\contrato
34
Productos
Productos
bajo estricto
control
herramienta
configuración
Ficha técnica F_FICHA \\10.2.60.90\its00027\ad
TEC ministración\Ficha 2
Técnica
Tabla 2.1 Elementos de configuración
2.1.2 Identificación de los elementos del paquete de datos técnico
Elemento Descripción
Libro de requerimientos Contiene la descripción de los
requerimientos del cliente.
visión Contiene la descripción detallada de los
objetivos del cliente con el proyecto.
Glosario Contiene los tecnicismos empleados en el
proyecto.
Reglas del Negocio Contiene las actividades que puede
realizar el usuario, y las condiciones para
el buen manejo del sistema.
Especificaciones de Describe detalladamente las interacciones
casos de uso entre el cliente y el sistema.
Modelo de Análisis Muestra los diagramas elaborados para el
análisis general del sistema
Matriz de rastreabilidad Identifica las relaciones de los casos de
de requerimientos uso con feautures, reglas del negocio,
objetivos y necesidades.
Diseño de Software Contiene los diseños detallados de cada
uno de los elementos que deben de
implementarse.
Contiene el diseño arquitectónico de la
Arquitectura de software
solución propuesta.
35
2.2 Documentos Físicos
Elementos de Ubicación Medio de Accesan

configuración acceso
Formatos Portafolio del N/A AP y AS

AP
3 Proceso de Cambios
3.1 Proceso de cambios
Consultar el procedimiento de administración de cambios [PR_PAC] cuando surja

una solicitud de cambio (SCAM).
Los cambios que se generen en los planes de trabajo deben señalarse en la hoja de
revisiones del mismo documento, de manera que sea fácil identificar las mejoras que
se le hayan practicado. Agregándose tantas filas como sean necesarias para cada
uno de los cambios que afecten el artefacto.
Así mismo se definen ciertos criterios bajo los cuales se estará administrando los
cambios a los productos de trabajo:
• El cambio será originado por una SCAM proveniente del cliente o propuesta
por algún integrante del equipo de trabajo del proyecto
• Los cambios al artefacto serán ejecutados por el responsable asignado para

ejecutar la SCAM o por el dueño del documento
• Una vez liberada la línea base de un artefacto, será afectada solo si el cambio
a realizar esta bien sustentado con el responsable de ejecutarla
Las SCAM que se presenten durante el proyecto seran concentradas en la base de

datos de solicitudes de cambio (BDSCAM) a través de la cual se administra la
ejecución y ciere de las mismas.
36
3.2 Comité de control de cambios
La función del comité de control de cambios es:
• Asegurar que cada cambio en la línea base es adecuadamente considerado

por todas las partes involucradas
• Asegurar que cada cambio es autorizado antes de que este sea

implementado
• Reunirse como un grupo para revisar y autorizar o rechazar las peticiones de

cambio, oficialmente cerrar las SCAM implementadas y aprobar la liberación
de productos
El cómite de control de cambios convocado para el análisis de la SCAM será

conformado en relación a la complejidad, relevancia y campo de acción bajo el que
se este presentando la SCAM.
El AP realizará el análisis inicial de la SCAM, si el impacto que esta proyecte sobre

el proyecto es mayor se convocara al cómite de control de cambios con los roles que
intervengan directamente con la solución de la SCAM
Los roles participantes dentro del cómite de control de cambios son:
• Administrador de proyectos (AP)
• Análista de sistemas
• Administrador de la configuración de proyecto (ACP)
• Ingeniero de software (IS)
• Ingeniero de pruebas (IP)
• Líder Técnico
Los roles del comité de control de cambios son asignados como sigue:
• El Administrador de proyectos será encargado de dirigir la mecánica de la

junta
37
• El Administrador de la Configuración de Proyecto (ACP) y Analista de

Sistemas son encargados de revisar las SCAM y de aportar las mejoras
En el caso de SCAM mayores que necesiten la aprobación de recursos adicionales y

staff, necesitarán ser revisadas en presencia del gerente de producción.
4 Repositorio
4.1 Datos electrónicos
4.1.1 Estructura de directorio y Permisos
Servidor VOB Usuario Permisos Descripción
PPG06 Leer, Acceso a todo el

Ejecutar, repositorio.
escribir
Ejecutar, repositorio
escribir
escribir
ITS000
\\10.2.60.90 PPG09 Leer, Acceso a todo el
27
escribir

Ejecutar, repositorio.
Escribir
38
El proyecto deberá usar la estructura de directorio como se muestra abajo:
Nivel 0 Nivel 1 Nivel 2 Nivel 3 Nivel 4

ITS00027
Administración
Carta de
Liberación
Contrato
Encuesta de
Satisfacción
Propuesta
Ficha Técnica
Calidad
Análisis a
Posteriori
Auditoría
ACF
Lista de
Verificación
Plan de Acción
Reporte de
Auditoría
APR
Lista de
Verificación
Plan de Acción
Reporte de
Auditoría
Auditoría de
Cierre
Lista de
Verificación
Plan de Acción
Reporte de
Auditoría
Listas de
Verificación
Estimaciones de
Tareas y
Calendario
39

Fase
Construcción
Fase Despliegue
Fase Elaboración
Fase Inicio
LREQ
PACS
PAPS
VISIÓN
Código
Código Fuente
Liberaciones
LMET
Revisiones entre
Colegas
Comunicación
Bitácora de
Asuntos
Cliente
Agendas
Correos
Minutas
Proyecto
Agendas
Correos
Minutas
Reportes de
Avance
Configuración
RESCO
SCAM
Solicitudes de
Configuración
Física
Dir_Trabajo
AAC
40

ACP
Administrador de
BD
Analista
AP
Arquitecto
Diseñador
Diseñador
Gráfico
Integrador
IP
IS
Planes del Proyecto
Arquitectura
Cuestionario de
Ciclo de Vida
Diseño de
Software
Estimaciones
Evalúa
Formato de
Adaptación
Glosario
LREQ
ECU
MARE
Modelo de
Análisis
PACS
PAPS
PARISH
PASCAS
Plan de
Comunicación
Plan de
Integración
Plan de Iteración
41

y Calendario
Plan de Pruebas
Plan de Recursos
Reglas de
Negocio
Unidad de
Distribución
Release
Build
Visión
Pruebas
Aceptación
Aceptación de
Pruebas
Diseño y
Resultado de
Pruebas
Funcionales
Aceptación de
Pruebas
Diseño y
Resultado de
Pruebas
Integración
Aceptación de
Pruebas
Diseño y
Resultado de
Pruebas
Notas de
Liberación
Unitarias
Lista de
Verificación PU
Decisiones
Matriz de
Análisis
Reporte
Ejecutivo
42

Código
Código Fuente
Liberaciones
Tabla 4.1 Estructura de directorio del repositorio
El directorio del proyecto deberá contener lo siguiente:
Repositorio del proyecto (subdirectorios bajo el directorio que almacena los ECOs
listados en la sección “Identificación de los elementos de configuración”). Los
subdirectorios residen en el servidor del repositorio.
Nombre del servidor de archivos \\10.2.60.90
Dirección IP del servidor de \\10.2.60.90

archivos
Ruta(s) Se tiene acceso mediante una

carpeta compartida en el servidor
Grupo(s) de red ITSON
Estructura Refiérase a la tabla 4.1
Tabla 4.2 Estructura de directorio, ruta y localidad del repositorio
Los directorios de trabajo del proyecto son los directorios de trabajo para los
miembros del equipo de trabajo del proyecto SLAB Almacén - Caja. Nada de lo que
esté en estos directorios debe ir bajo control de versión.
43
Las reglas para los directorios de proyecto son las siguientes:
• Cada miembro del proyecto tiene su propio directorio de trabajo y son libres
de configurarlo de acuerdo a sus necesidades
• Los ECOs correspondientes a correos del directorio "Comunicación" no

siguen ninguna convención de nombramiento
Todos los ECOs del proyecto y la documentación del cliente en forma electrónica
deberán ser almacenados en el repositorio del proyecto.
5 Estatus de la configuración
5.1 Auditorías de configuración
Auditoría de la configuración física (ACF) deberán ejecutarse en el proyecto como se

especifique en el calendario de trabajo.
Los procedimientos de acción para su realización están definidos en la guía de

auditoría de la configuración física (GACF).
La auditoría se realizará al finalizar la primera iteración del proyecto.
5.2 Reporte de estatus de la configuración
El reporte de estatus de la configuración (RESCO) deberá ser generado por el ACP.

Consultar la guía de reporte de estatus de la configuración [G_GRESCO] para más
información.
El reporte de estatus de la configuración de este proyecto será realizado al término

de cada fase del proyecto.
6 Procedimiento y Requerimientos de respaldo
El respaldo con toda la información del proyecto se irá realizando en el equipo

proporcionado por prácticas tanto como en el equipo portátil del ACP, además la
44
documentación física, incluyendo las carpetas del proyecto y la información

proporcionada por el cliente, en un área segura.
Nombre del proyecto Requerimientos de respaldo

SLAB Almacén - Caja Se realizarán respaldos semanalmente
Tabla 6.1 Requerimientos de respaldo
45
III. RESULTADOS
Con el objetivo de lograr una administración de configuración con estándares y

parámetros de calidad internacional se trabajó bajo la metodología RUP (Proceso
Unificado Racional) la cual se apoya en el modelo de calidad CMMI en su nivel 3 de
madurez. En la práctica profesional NOVUTEK se laboró siguiendo estos
reglamentos por el periodo del primer semestre de prácticas el cual se trabajo con
vinculación a la empresa NOVUTEK.
A lo largo de ese periodo se fueron elaborando documentos que surgían de acuerdo

a la fase en que se encontraba el sistema; en donde primeramente se analizaron los
requisitos que demandaba el cliente y es ahí de donde parte todo el proceso del
ciclo de vida del software.
46
Imagen de la distribución de carpetas dentro del Repositorio
Gráfica que muestra las carpetas con mayor actividad en el desarrollo del
sistema SLAB – Almacén y Caja en el transcurso del primer semestre de
desarrollo del mismo.
47
Como se muestra en la gráfica anterior, la mayor concentración de movimientos se

realizó en la Carpeta de comunicación y planes del proyecto; en donde la primera
almacenaba todas aquellas aprobaciones que se iban generando para que los
artefactos quedaran en línea base, tanto por parte de los integrantes del equipo
como del cliente. En términos generales comunicación contiene gran cantidad de
imágenes de correos electrónicos como evidencia de que se aprobó algún
documento. Sin embargo la carpeta denominada planes del proyecto se subdivide en
aproximadamente en 22 carpetas más, las cuales contienen artefactos de suma
importancia.
A continuación unas imágenes de correos electrónicos en donde se aprobaba

algún artefacto por los integrantes del proyecto.
Aprobación del documento Plan de Recursos en su línea base.

48
Aprobación del glosario en su línea base.
A continuación unas imágenes de correos electrónicos en donde se aprobaba

algún artefacto por el cliente.
Aprobación del Libro de Requerimientos por parte del cliente.

49
La carpeta llamada Planes del proyecto es considerada como la más importante en

todo el desarrollo del sistema por lo que se realizo un análisis amplio.
La gráfica muestra la cantidad de artefactos que se mantuvieron en movimiento, ya

sea por modificación de versiones, evolución de borrador a línea base, acumulación
de documentos, etc. Todo esto en el primer semestre de desarrollo de SLAB –
módulos almacén y caja.
Se detecta que la subcarpeta LREQ mantuvo una amplia actividad de artefactos

debido al gran impacto que constituía al desarrollo del sistema, ya que en esa
carpeta se almacenaron los requerimientos del software, es decir las necesidades
que tenía el cliente y todos los requerimientos que demandaban al mismo;
Consecuentemente este fue un trabajo amplio para el analista del sistema quien tuvo
que desglosar estas necesidades y plasmarlas en los documentos, trayendo como
consecuencias varias modificaciones por parte del mismo cliente.
50
El repositorio tuvo aproximadamente 330 artefactos a lo largo del primer semestre de

desarrollo del sistema SLAB en su módulo almacén y caja, en el cual primeramente
existieron las versiones en borrador de la mayoría de los documentos que después
pasaron por varias revisiones y aprobaciones para convertirse en líneas base.
El buen trabajo en equipo e integración del mismo contribuyo esencialmente a que

no se movieran los documentos si no era necesario y no conservar documentos
repetidos o parecidos. Trabajar bajo la metodología RUP ayudo bastante ya que el
Administrador del Proyecto determinaba que una actividad debía de realizarse en un
periodo determinado y esto contribuida a trabajar en tiempo y formar, y así evitar un
atraso en el desarrollo del software. Ya que RUP se divide en 4 etapas; Inicio (define
el alcance del proyecto), Elaboración (definición, análisis, diseño), Implementación y
Transición (fin del proyecto y puesta en producción).
51
IV. CONCLUSIONES
La respuesta obtenida al problema planteado en este trabajo fue exitosa ya que se

logro involucrar al cliente en todo el proceso del Software y principalmente se
desarrolló un Sistema denominado Sistema para Laboratorio de Alimentos y
Bebidas SLAB – módulo almacén y caja. Cumpliendo estándares y parámetros de
nivel internacional; gracias a la metodología RUP apoyada por el modelo de calidad
CMMI en su nivel 3 de madurez, el cual se define como “proceso definido”, el cual se
interpreta como un proceso establecido, documentado y que existen métricas
(obtención de datos objetivos) para la consecución de objetivos concretos. Es decir
todos y cada uno de los artefactos que se fueron almacenando en el repositorio por
el periodo del primer semestre de desarrollo de SLAB.
Existen limitaciones tales como el llenado de la documentación e incluso reuniones

con el cliente, sin embargo se pudieron cubrir debido al gran trabajo en equipo y al
apoyo que se dio entre los practicantes, y el cliente consecuentemente contribuyo de
manera positiva y respondió con gran satisfacción al trabajo realizado.
El software que se concluyó será de gran ayuda a la Carrera de Turismo ya que

contribuirá a la certificación de la misma.
Toda la documentación que se almacenó del software será de suma importancia en

un futuro ya que si se desea hacer una modificación o adición al sistema, solo será
necesario analizar estos artefactos y dar solución a un posible conflicto.
52
V. BIBLIOGRAFÍA
Anónimo. Gestión de Configuración. (Control de versiones, configuración y cambios).

Consultada el 14 de Julio del 2010.
(Ver http://lml.ls.fi.upm.es/ep/versiones.html)
Anónimo. Gestion de la Configuracion del Software. Consultada 14 de Julio del 2010.
(Ver http://www.geronet.com.ar/?p=90)
Anónimo. Gestión de la Configuración del Software. Consultada el 28 de Junio del

2010.
(Ver http://www.ual.es/~rguirado/posi/Tema5-Apartado5.pdf)
Anónimo. Understanding Configuration Management According to Its Purpose.

Consultada el 12 de Julio del 2010.
(Ver http://ezinearticles.com/?Understanding-Configuration-Management-
According-to-Its-Purpose&id=564304)
Sun Microsystems. Best-Practice Recommendations. Configuration Management.

Consultada el 14 de Junio del 2010.
(Ver http://www.sun.com/emrkt/sunspectrum/configurationwhitepaper.pdf)

Memoria Proyecto - Susana

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Memoria Proyecto - Susana

Cargado por

Copyright:

Formatos disponibles

“Administración de la configuración en el

desarrollo del Software – Sistema para

Susana Elizabeth Lizárraga Coronado

Guaymas, Sonora; Agosto 2010

1.2 Definición del Problema .............................................................................8

2.1.2 Tres reglas simples para la administración de configuración ............11

En la actualidad realizar un Software no es simplemente comenzar a codificar,

satisfechas al concluir su demanda. Sin embargo, estos requerimientos deben de

La motivación de realizar este trabajo nace instantáneamente después de concluir la

El propósito de la administración de la configuración radica esencialmente en

Un cambio puede ocurrir en cualquier momento y por cualquier razón. Dentro de la

Al finalizar cada etapa, en donde solo se pudo documentar la fase de inicio y

1.2 Definición del problema

Cuando se desarrolla un Software este parte de las necesidades que expone el

Los cambios, renovaciones o modificaciones son inevitables en el ciclo de vida del

¿Cómo obtener una Administración de Configuración de proyectos de Software

El principal provecho que se obtiene al elaborar este proyecto consiste en dar a

Aplicar una correcta Administración de Configuración de proyectos para un desarrollo

2.1 Marco Teórico

2.1.1 ¿Por qué es importante la Administración de Configuración?

algunas aplicaciones empresariales, requiere atención a las configuraciones para

En el nivel más obvio, los problemas de configuración pueden causar fallos

En un nivel menos obvio, si los sistemas se mantienen en un estado estable pero no

2.1.2 Tres reglas simples para la administración de configuración

• Regla 1. Mantenga el Control; Tiene que mantener el control de los elementos

• Regla 2. Utilice la tecnología; El manual de gestión de la configuración

• Regla 3. La administración de configuración hace que otras cosas sucedan;

2.1.3 ¿Qué es la administración de la configuración?

La Gestión de la configuración del software es uno de los aspectos importantes que

La administración de configuración, es el proceso que ofrece una visión lógica de la

La Biblioteca de Infraestructura de Tecnologías de Información (ITIL) y el estándar

• Mantener el control: Para que la gerencia de configuración tenga cualquier

• Seguimiento de los elementos de configuración correctos: Si intenta

• Crear un repositorio: Para hacer todas las maravillas de la administración de

La administración de la configuración se realiza desde que comienza el proyecto

• Diferencia entre mantenimiento del software y configuración del

producen después de que se haya entregado, mientras que configuración son

2.1.4 Objetivos de la administración de configuración

Los objetivos son los siguientes:

• Evaluar y mantener la integridad de los productos.

La integridad en este contexto es:

• Saber exactamente lo que se ha entregado al cliente

Las actividades a realizar para conseguir los objetivos son:

• Artefacto: se define como un producto terminado, como el código o el

• Cambio: adición, modificación o borrado de algún elemento de una línea

• Configuración: término genérico usado para describir un grupo de elementos

• Control de configuración: actividades que comprenden el control de los

• Gestión de cambios: proceso responsable de controlar el ciclo de vida de

• Gestión de configuración: proceso cuyo propósito es establecer y mantener

• Elemento de configuración (CI): un conjunto de productos de trabajo que

• Variante: nueva versión de un elemento que será añadida a la configuración

• Versión: Una versión es una instancia de un elemento de Configuración. El

2.1.6 Proceso de administración de configuración

La administración de configuración da respuesta a las siguientes cuestiones:

• ¿Cómo identifica y gestiona una organización las muchas versiones existentes

Estas cuestiones se resuelven en las cuatro tareas de las que consta la

1. Identificación. Se trata de establecer estándares de documentación y un

• Definir una estructura de documentación organizada de un modo inteligible y

El proceso de identificación de la configuración es el siguiente:

• La tarea de identificación empieza con la definición de los elementos de la

• Se asignan identificadores apropiados a todos los programas, documentos y

La configuración software se mantiene durante la vida del sistema software. Se

Pueden aplicarse tres enfoques fundamentales al control de la documentación:

1. Todos los documentos software y otros elementos de cada configuración son