Clases Unidad 4

Unidad 4 – Configuración del Software
● Introducción
● El proceso de configuración del software
● Identificación de objetos
● Control de versiones
● Control de cambios
● Auditoría de la configuración
● Informes de estado
● Herramientas CASE
● Mejores prácticas
Unidad 4 – Configuración del Software
● Estándar IEEE 828-1998

● Auditoría informática
IS Unidad 4 Luis Nieto 2017 2
Unidad 4 – Introducción
● Característica del SW que diferencia su

construcción:
● Modificable infinitamente
● Cuando se construye SW los cambios son
inevitables, arriesgando la integridad del
producto (cambios sin control, despliegue de
componentes inconsistentes, etc. pueden
desestabilizar la calidad de la aplicación).
● Los cambios aumentan la confusión si:

● No se analizan antes de realizarlos
● No se registran antes de implementarlos
● No se comunican a los interesados
● No se controlan de manera que mejoren la
calidad y reduzcan los errores
● Esta dinámica genera la necesidad de contar con

una organización para controlar los cambios:
● Gestión de Configuración del Software
(GCS): actividad que se aplica durante todo el
proceso software.
● La misión de la GCS es custodiar la integridad de

los productos durante todo el ciclo de vida.
● El valor invertido en las tareas de GCS está
relacionado con el costo del producto vs. la
exposición al riesgo de obtener un producto
inestable.
● Como el cambio se puede producir en cualquier

momento, las actividades de la GCS sirven para:
● Identificar el cambio
● Controlar el cambio
● Garantizar que el cambio se implementa
adecuadamente
● Informar del cambio a todos aquellos que
puedan estar interesados.
● Diferencia entre mantenimiento y GCS:

● El mantenimiento es un conjunto de
actividades que se producen después que el
SW se entrega al cliente.
● La GCS es un conjunto de actividades de
seguimiento y control que se producen durante
todo el ciclo de vida.
● El resultado del proceso SW se puede dividir en 3

categorías:
● Programas
● Documentos
● Datos (internos o externos al programa)
● En el contexto de la GCS, a estos elementos se
los llama Elementos de Configuración de
Software (ECS).
● Un ECS es cualquier “cosa” puesta

explícitamente bajo control:
● Especificaciones
● Diseños
● Código
● Planes
● Pruebas
● Manuales
● Estándares
● Los ECSs se organizan como objetos de

configuración y se guardan en la BD del proyecto
con un nombre único.
● Un objeto de configuración tiene:
● Nombre
● Atributos
● “Conexión” a otros objetos
M o d e lo d e d a to s
E s p e c if ic a c ió n d e l d is e ñ o
D is e ñ o d e d a to s
D is e ñ o a rq u ite c tó n ic o
D is e ñ o d e m ó d u lo s
D is e ñ o d e in te rf a c e s
C o m p o n e n te N
E s p e c if ic a c ió n d e p ru e b a
D e s c rip c ió n d e la in te rf a z
P la n d e p ru e b a D e s c rip c ió n d e l a lg o rit m o
P ro c e d im ie n to d e p ru e b a
C a so s d e p ru e b a
C ó d ig o f u e n t e
● Una línea curva representa una relación de

composición:
● Modelo de datos y Componente N son
parte del objeto Especificación del diseño.
● Una línea recta representa una interrelación:
● Si se hace un cambio sobre el objeto Código
fuente, se puede determinar qué otros objetos
pueden verse afectados (Especificación de
prueba).
● A medida que progresa el proceso SW, el número

de ECSs crece rápidamente.
● Si cada ECS produjera otros ECSs, no habría
confusión. Pero, en el proceso entra en juego el
cambio, el cual se puede producir en cualquier
momento y por cualquier razón.
● Razones por las cuales se producen cambios:

● Nuevas condiciones comerciales que dictan los
cambios en los requisitos del producto.
● Nuevas necesidades del cliente que
incrementan la complejidad del SW.
● Reorganización del negocio provocando
cambios en las prioridades del proyecto o en la
estructura del equipo.
● Restricciones presupuestarias o de
planificación.
● GCS: conjunto de actividades desarrolladas para

gestionar los cambios a lo largo del ciclo de vida
del SW. Su objetivo es mantener la integridad del
producto, evaluar y controlar los cambios y hacer
el producto visible a todo el equipo.
● Línea Base: es un concepto de la GCS que

ayuda a controlar los cambios sin impedir
seriamente los cambios justificados.
● Línea base (IEEE):
● Especificación o producto revisado y acordado
formalmente, que sirve como base para un
desarrollo posterior y puede cambiarse
solamente a través de procedimientos
formales de control de cambios.
● Antes que un ECS se convierta en línea base, el

cambio se puede llevar a cabo rápida e
informalmente.
● Una vez que se establece una línea base, se
pueden llevar a cabo los cambios, pero se debe
aplicar un procedimiento formal para evaluar y
verificar cada cambio.
● Por ejemplo, los elementos de una especificación

de diseño se documentan y se revisan. Se
encuentran errores y se corrigen.
● Cuando todas las partes de la especificación se
han revisado, corregido y aprobado, la
especificación se convierte en línea base.
● A partir de este momento, sólo se podrán realizar
cambios futuros en la arquitectura del SW
(documentada en la especificación de diseño)
luego de haber sido evaluados y aprobados.
● La progresión de acontecimientos que conducen

a una línea base son:
● Las tareas de la IS producen uno o más ECSs.
● Una vez que un ECS se ha revisado y
aprobado, se coloca en una BD del proyecto.
● Cuando un miembro del equipo quiere hacer
modificaciones a un ECS transformado en línea
base, se copia de la BD a un área privada.
● Este ECS extraído puede modificarse sólo si se
siguen los controles de la GCS.
Unidad 4 – El proceso de CS
● La responsabilidad principal de la GCS es el

control de cambios.
● La GCS también es responsable de:
● La identificación de ECSs individuales y de las
distintas versiones del SW.
● Las auditorías para asegurar que los cambios
se desarrollan adecuadamente.
● La generación de informes sobre todos los
cambios realizados en la configuración.
● Preguntas que plantea la GCS:

● ¿Cómo identifica y gestiona una organización
las diferentes versiones del SW (y su
documentación)?
● ¿Cómo controla la organización los cambios
antes y después que el SW se distribuya al
cliente?
● ¿Quién tiene la responsabilidad de aprobar y
de asignar prioridades a los cambios?
● Preguntas que plantea la GCS:

● ¿Cómo se puede garantizar que los cambios se
llevan a cabo adecuadamente?
● ¿Qué mecanismos se usan para comunicar los
cambios?
● Estas preguntas llevan a la definición de 5 tareas:

● 1. Identificación de los objetos
● 2. Control de versiones
● 3. Control de cambios
● 4. Auditorías de configuración
● 5. Informes de estado
Unidad 4 – El proceso de CS:
Identificación de los objetos
● Decidir qué elementos se van a controlar:

● Planes del proyecto
● Especificaciones
● Diseños
● Programas
● Conjuntos de datos de prueba
● No todos los elementos están bajo el control de

configuración:
● Minutas de las reuniones de grupo
● Bosquejos de planes
● Propuestas
● Para controlar y gestionar los ECS, se debe
identificarlos y organizarlos mediante un nombre
único.
● Cada objeto tiene un conjunto de características

que lo identifican:
● Nombre: cadena de caracteres que identifica
al objeto sin ambigüedad.
● Descripción: lista de elementos que
identifican:
– El tipo de ECS (documento, programa, datos)
que está representado por el objeto.
– Un identificador del proyecto.
– La información de la versión y/o el cambio.
● Cada objeto tiene un conjunto de características

que lo identifican:
● Recursos: son "entidades que proporcionan,
procesan, referencian o son, de alguna otra
forma, requeridas por el objeto".
● Estado: en elaboración, finalizado, revisado,
aceptado.
● Fecha.
● El esquema de identificación debe tener en

cuenta que los objetos evolucionan a lo largo del
proceso SW.
● Para cualquier objeto se puede crear un grafo de
evolución, el cual describe la historia de los
cambios del mismo.
O b je to O b je to
1 .3 1 .4
O b je to O b je to O b je to
1 .0 1 .1 1 .2
O b je to O b je to
2 .0 2 .1
O b je to O b je to
1 .1 .1 1 .1 .2
● El objeto de configuración 1.0 pasa la revisión y

se convierte en el objeto 1.1.
● Algunas correcciones y cambios mínimos
producen las versiones 1.1.1 y 1.1.2, que van
seguidas de una actualización importante,
resultando el objeto 1.2.
● La evolución de objeto 1.2 sigue hacia 1.3 y 1.4,
pero, al mismo tiempo, una gran modificación del
objeto produce un nuevo camino de evolución, la
versión 2.0.
● Mediante la identificación de los objetos:

● Un desarrollador puede establecer las
referencias de todos los componentes,
documentos, casos de prueba de la versión
1.4.
● El departamento comercial puede saber los
clientes que en la actualidad tienen la versión
2.1.
● Se puede asegurar que los cambios en el
código fuente de la versión 2.1 han sido
reflejados en la documentación.
Unidad 4 – El proceso de CS: Control de
versiones
● Versión: instancia del sistema funcionalmente

distinta de otras del mismo sistema.
● Variante: instancia del sistema funcionalmente
idéntica a otras, pero distinta a nivel no
funcional.
versiones
O b je to O b je to
1 .3 1 .4
O b je t o O b je to O b je to
1 .0 1 .1 1 .2
O b je to O b je to
2 .0 2 .1
O b je to O b je t o
1 .1 .1 1 .1 .2 1
2 3
4 5
versiones
● Suponer que el componente 4 sólo se usa cuando

el SW se implementa para monitores color,
mientras que el componente 5 se usa cuando el
SW se implementa para monitores monocromo.
● Para la misma versión (2.1) se pueden definir 2
variantes:
● Componentes 1, 2, 3 y 4
● Componentes 1, 2, 3 y 5
versiones
● La relación entre los objetos de configuración y

los componentes, las variantes y las versiones se
pueden representar como un espacio
tridimensional.
V a ria n te s
O b je to
C o m p o n e n te s
IS Unidad 4 Luis Nieto 2017 V e rs io n e s 37
versiones
● Resumiendo:
● El control de versiones combina
procedimientos y herramientas para gestionar
las versiones de los objetos de configuración
creados durante el proceso SW.
● La GCS permite a un usuario especificar
configuraciones alternativas del SW mediante
la selección de versiones adecuadas.
cambios
● Mucho control de cambio crea problemas, poco

control de cambios crea otros problemas:
● Hay que preocuparse por el cambio porque una
pequeña perturbación en el código puede crear
un gran fallo en el producto (pero también
puede reparar un gran fallo o habilitar
capacidades nuevas).
cambios
● En un gran proyecto, el cambio incontrolado lleva

rápidamente al caos.
● Para estos proyectos, el control de cambios
combina los procedimientos humanos y las
herramientas automáticas para proporcionar un
mecanismo para el control de cambios.
cambios
1. Solicitar el pedido de cambios

2. Analizar la solicitud de cambios
3. Si el pedido de cambios es válido:
3.1 Evaluar cómo implementar los cambios
3.2 Evaluar los costos de los cambios
3.3 Registrar el pedido de cambios en la BD
3.4 Enviar el pedido a la autoridad de CC
cambios
3.5 Si se acepta el pedido de cambios:

Repetir
3.5.1 Hacer los cambios al software
3.5.2 Registrar los cambios
3.5.3 Evaluar la calidad del SW cambiado
Hasta (calidad del SW sea adecuada)
3.5.4 Crear nueva versión del sistema
cambios
3.6 Si no se acepta el pedido de cambios:

3.6.1 Rechazar el pedido de cambios
4. Si el pedido de cambios no es válido:
4.1 Rechazar el pedido de cambios
cambios
● Se hace un pedido de cambios y se evalúa para

calcular el esfuerzo técnico, los posibles efectos
secundarios, el impacto global sobre otras
funciones del sistema y sobre otros objetos de la
configuración.
● Los resultados de la evaluación se presentan a la
autoridad de control de cambios (una persona o
grupo que toma la decisión final del estado y la
prioridad del cambio).
cambios
● El objeto a cambiar es "dado de baja" de la BD

del proyecto; se realiza el cambio y se aplican las
actividades adecuadas de SQA.
● Luego, el objeto es "dado de alta" en la BD y se
usan los mecanismos de control de versiones
apropiados para crear la siguiente versión del SW.
cambios
● Los procesos de "alta" y "baja" implementan 2

elementos importantes del control de cambios:
● Control de acceso: gobierna los derechos
para acceder y modificar objetos de
configuración concretos.
● Control de sincronización: asegura que los
cambios en paralelo, realizados por personas
diferentes, no se sobrescriban mutuamente.
cambios
● De acuerdo con un pedido de cambio aprobado,

se da de baja un objeto de configuración.
● Una función de control de acceso comprueba que
quien hace la baja tiene la suficiente autoridad
para dar de baja el objeto, y el control de
sincronización bloquea el objeto en la BD del
proyecto, de forma que no se puedan hacer más
actualizaciones hasta que se haya reemplazado
con la nueva versión.
● Se modifica una copia del objeto de línea base,
denominada versión extraída.
cambios
● Tras la SQA y las pruebas apropiadas, se da de

alta la versión modificada del objeto y se
desbloquea el nuevo objeto de línea base.
● Antes que un ECS se convierta en una línea base,
sólo es necesario aplicar un control de cambios
informal: el que haya desarrollado el ECS en
cuestión podrá hacer cualquier cambio justificado
por el proyecto y por los requisitos técnicos.
cambios
● Una vez que el objeto ha pasado la RTF y ha sido

aprobado, se crea la línea base.
● Una vez que el ECS se convierte en una línea
base, aparece el control de cambios a nivel de
proyecto: ahora, para hacer un cambio, el
encargado del desarrollo debe recibir la
aprobación del gestor del proyecto (si el cambio
es "local") o de la autoridad de control de
cambios (si el cambio impacta en otros ECSs).
cambios
● El papel de la autoridad de control de cambios es

el de tener una visión general, o sea, evaluar el
impacto del cambio fuera del ECS en cuestión:
● ¿Cómo impactará el cambio en el HW?
● ¿Cómo impactará en el rendimiento?
● ¿Cómo alterará el cambio la percepción del
cliente sobre el producto?
● ¿Cómo afectará el cambio a la calidad y a la
fiabilidad?
Unidad 4 – El proceso de CS: Auditorías
de configuración
● La identificación, el control de versiones y el

control de cambios ayudan al equipo de
desarrollo a mantener un orden que, de otro
modo, llevaría a una situación caótica y sin
salida.
● ¿Cómo se puede asegurar que el cambio se ha
implementado correctamente?
de configuración
● Revisiones Técnicas Formales (RTF): se

centran en la corrección técnica del ECS que ha
sido modificado. Los revisores evalúan el ECS
para determinar la consistencia con otros ECSs,
las omisiones o los posibles efectos secundarios.
Se debe llevar a cabo una RTF para cualquier
cambio que no sea trivial.
● Auditorías de configuración: complementan
las RTFs al comprobar características que
generalmente no tienen en cuenta las mismas.
de configuración
● La auditoría plantea las siguientes preguntas:

● ¿Se ha hecho el cambio especificado?
● ¿Se incorporaron modificaciones adicionales?
● ¿Se realizó una RTF para evaluar la corrección
técnica?
● ¿Se siguió el proceso SW y se aplicaron
adecuadamente estándares?
de configuración
● La auditoría plantea las siguientes preguntas:

● ¿Se especificaron la fecha y autor del cambio?
● ¿Se actualizaron adecuadamente todos los
ECSs relacionados?
Unidad 4 – El proceso de CS: Informes
de estado
● La generación de informes de estado de la

configuración es una tarea de GCS que responde
a las siguientes preguntas:
● ¿Qué pasó?
● ¿Quién lo hizo?
● ¿Cuándo pasó?
● ¿Qué más se vio afectado?
de estado
● Se genera un informe de estado de configuración

(IEC):
● Cada vez que se asigna una nueva
identificación a un ECS, o se actualiza una
identificación.
● Cada vez que la autoridad de control de
cambios aprueba un cambio.
● Cada vez que se lleva a cabo una auditoría de
configuración.
de estado
● La salida del IEC se puede guardar en una BD de

forma que los encargados del desarrollo o del
mantenimiento del SW puedan acceder a esta
información.
● Además, se genera un IEC regularmente con
intención de mantener a los gestores y a los
profesionales al tanto de los cambios
importantes.
Unidad 4 – Herramientas CASE
● Los procesos de gestión de configuración por lo

general están estandarizados e involucran la
aplicación de procedimientos predefinidos.
● Cuando se construye SW un error en la gestión
de configuración puede implicar que el mismo no
trabaje de forma adecuada.
● Las herramientas CASE resultan esenciales para
la gestión de configuración, y se pueden
combinar para crear entornos de trabajo que
soporten todas las actividades.
Unidad 4 – Herramientas CASE
● Algunas herramientas:
● Bugzilla (herramienta que permite a los
miembros del equipo hacer el seguimiento de
errores).
● Subversion (SVN) (gestión de versiones).
Diseñado para reemplazar a CVS.
● Git (control de versiones).
● Team Foundation (herramienta para
administrar proyectos de SW durante todo su
ciclo de vida).
Unidad 4 – Mejores prácticas
● Para evitar problemas de configuración comunes,

y maximizar la productividad del equipo, al
implementar las herramientas y procesos de la
GCS, se deben definir:
● Qué prácticas emplear
● Qué políticas emplear
● Algunas buenas prácticas:

● Identificar y almacenar los artefactos en un
repositorio seguro.
● Controlar y auditar los cambios en los
artefactos.
● Organizar los artefactos con versiones en
componentes con versiones.
● Organizar los componentes y subsistemas con
versiones en subsistemas con versiones.
● Crear referencias en los hitos del proyecto.
● Algunas buenas prácticas:

● Registrar y seguir los pedidos de cambio.
● Mantener espacios de trabajo estables y
consistentes.
● Dar soporte a cambios concurrentes a los
artefactos y componentes.
● Integrar rápida y frecuentemente.
● Asegurar que las compilaciones de SW se
puedan reproducir.
● Identificar y almacenar los artefactos en un

repositorio seguro
● Para hacer GCS, se deben identificar los
artefactos que se someterán al control de
versión.
● Identificar significa poder encontrar cualquier
artefacto del proyecto o del sistema rápida y
fácilmente.
● Controlar y auditar los cambios en los

artefactos
● Después que se identifican los artefactos, y
que se almacenan en un repositorio, se debe
poder controlar quién puede modificarlos, así
como mantener un registro de las
modificaciones que fueron hechas, quién las
hizo, cuándo y por qué.
● Organizar los artefactos con versiones en

componentes con versiones
● Cuando hay muchos archivos y directorios en
un sistema, se hace necesario agruparlos en
objetos que representen una granularidad más
grande, para facilitar los problemas de gestión
y organización.
● Estos objetos pueden llamarse: paquetes,
módulos, componentes de desarrollo.
● Organizar los componentes y subsistemas

con versiones en subsistemas con versiones
● Para permitir la gestión de sistemas complejos,
se deben agrupar los componentes en
subsistemas, pudiendo incluir otros
subsistemas en la definición de un subsistema.
● Esta definición recursiva de un subsistema,
como una colección de componentes y
subsistemas compatibles, permite que los
sistemas muy complejos se definan, controlen
y administren jerárquicamente.
● Crear referencias en los hitos del proyecto

● Se deben registrar las versiones de todos los
artefactos y elementos que integran un
sistema o subsistema en momentos específicos
en el proyecto.
● Como mínimo, se deben crear estas
referencias en cada hito principal del proyecto.
● 3 razones para crear estas referencias:

–Reproducibilidad
– Trazabilidad
– Presentación de informes
● La reproducibilidad es la capacidad de
retroceder en el tiempo y reproducir una
versión dada de un sistema o un entorno de
desarrollo que existía antes.
● La trazabilidad une las necesidades, los planes

del proyecto, los casos de prueba y los
artefactos de SW.
● La presentación de informes permite consultar
el contenido de cualquier referencia y
comparar referencias.
● Registrar y seguir los pedidos de cambio

● La gestión de pedidos de cambio implica el
seguimiento de los mismos.
● Estos pedidos pueden resultar por defectos
encontrados por pruebas, defectos informados
por los clientes, pedidos de mejora o nuevas
ideas producidas internamente.
● Mantener espacios de trabajo estables y

consistentes
● El desarrollador requiere de herramientas y de
automatización para crear y mantener un
entorno estable de trabajo.
● Este mantenimiento consiste en la
sincronización de los cambios periódicamente
con otros miembros del equipo de modo que
resulte en un conjunto homogéneo de cambios
que sean de un nivel conocido de estabilidad.
● Dar soporte a cambios concurrentes a los

artefactos y componentes
● Idealmente, sólo una persona hará cambios a
un archivo por vez, o un único equipo trabajará
en un componente a la vez.
● Desafortunadamente, esto no siempre resulta
eficiente y práctico.
● El caso más evidente es cuando mantiene una
versión mientras se desarrolla la próxima.
● Las primeras herramientas de GCS obligaban a

los usuarios a serializar los cambios a archivos.
● Esto resultaba ineficiente:
– algunos desarrolladores quedaban
bloqueados esperando que los otros
completaran sus cambios.
– los desarrolladores bloqueados trabajaban
sobre una copia del archivo, modificándola
fuera del control de la herramienta.
● Este problema suele quedar expuesto cuando

un error vuelve a aparecer en la última
compilación de un sistema.
● Integrar rápida y frecuentemente

● Durante la integración, se descubrirán
problemas con las interfaces y malentendidos
en el diseño.
● Ambos problemas pueden tener un impacto
importante en la planificación, por lo que
resulta fundamental la integración temprana.
● Se deben planificar puntos de integración
temprano en el ciclo de vida, y continuar la
integración con frecuencia en el transcurso.
● Asegurar que las compilaciones de software

se puedan reproducir
● Frecuentemente es necesario saber cómo se
creó una compilación y lo que salió en su
construcción, para depurar un problema o
reproducir la misma compilación.
● Se deben establecer los procedimientos
apropiados para registrar quién hizo la
compilación, qué fue a cada ejecutable, la
máquina en la que se construyó, qué versión
de SO se ejecutaba en esa máquina, y las
opciones que se especificaron.
Unidad 4 – Estándares
● IEEE Std 828-1998: es un estándar que

presenta los contenidos mínimos de un plan de
GCS. Este plan puede ser un documento aislado o
formar parte de otro documento.
● IEEE Std 1042-1987: es una interpretación del
anterior. Además cuenta con ejemplos de planes.
Unidad 4 – Estándar IEEE 828-1998
● 1. Introducción
● 1.1 Propósito
● 1.2 Alcance
● 1.3 Definición de términos clave
● 1.4 Referencias
● 2. Gestión de la GCS
● 2.1 Organización
● 2.2 Responsabilidades GCS
● 2.3 Políticas, directivas y procedimientos
aplicables
● 3. Actividades de la GCS
● 3.1 Identificación de la configuración
–3.1.1 Identificación de ECSs
– 3.1.2 Nombrado de ECSs
– 3.1.3 Adquisición de ECSs
● 3.2 Control de la configuración
– 3.2.1 Pedido de cambios
– 3.2.2 Evaluación de cambios
– 3.2.3 Aprobación o desaprobación de
cambios
3.2.4 Implementación de cambios

–
● 3.3 Contabilidad de estado de configuración
● 3.4 Auditorias y revisiones de la configuración
● 3.5 Control de interfaz
● 3.6 Control de la subcontratación/compra
● 4. Planificaciones de la GCS
● 5. Recursos de la GCS
● 6. Mantenimiento del plan de GCS
● 1. Introducción: proporciona una visión

simplificada de la GCS.
● 1.1 Propósito: describe la necesidad del plan y
la audiencia.
● 1.2 Alcance: determina la aplicabilidad de la
GCS, limitaciones y supuestos en los que se basa
el plan. En particular debe incluir:
● Descripción del proyecto
● Identificación de los elementos de
configuración a los que se aplicará GCS
● Identificación de otro software a incluir en el

plan
● Relación de la GCS con el hardware o
actividades de configuración del sistema del
proyecto
● Grado de formalidad, profundidad de control y
porción del ciclo de vida al que se aplicará GCS
● Limitaciones, tales como restricciones de
tiempo, que se aplican al plan
● Supuestos que deberían tener impacto en el

costo, planificación o capacidad para
desarrollar las actividades de GCS definidas
(por ejemplo, cliente o disponibilidad de
herramientas)
● Términos clave
● Políticas, directivas, procedimientos,
estándares, terminología y documentos
relacionados
● 2. Gestión de la configuración software:

describe la asignación de responsabilidades y
autoridades a las actividades de GCS.
● 2.1 Organización: determina el contexto
organizativo en el que se aplica GCS:
● Unidades organizativas que participan o son
responsables de actividades de GCS en el
proyecto
● Papeles funcionales de estas unidades
organizativas dentro de la estructura del
proyecto
● Relaciones entre las unidades organizativas

● 2.2 Responsabilidades GCS: determina la
asignación de actividades a unidades
organizativas:
● Unidad organizativa
● Propósito y objetivos
● Miembros y afiliaciones
● Período de efectividad
● Alcance de la autoridad
● Procedimientos operativos
● 2.3 Políticas aplicables, directivas y

procedimientos: captura cualquier restricción
externa aplicable al plan GCS.
● 3. Actividades GCS: identifica todas las
funciones y tareas requeridas para gestionar la
configuración del sistema software.
● 3.1 Identificación de la configuración:
identifica, nombra y describe las características
de los ECSs.
● 3.1.1 Identificación de los ECSs: registra:

● Los elementos que deben ser controlados.
● Cómo van a ser mantenidos a lo largo del
proyecto.
● También se tiene en cuenta:
– El evento que crea la línea base.
– Los elementos que son controlados en la
línea base.
– Los procedimientos utilizados para
establecer y cambiar la línea base.
La autoridad requerida para aprobar

–
cambios.
● 3.1.2 Nombrado de ECSs: especifica un
sistema de identificación para asignar
identificadores únicos a cada ECS, así como sus
versiones y manipulación.
● 3.1.3 Adquisición de ECSs: identifica las
librerías utilizadas y la gestión del cambio de
dichas librerías.
● 3.2 Control de la configuración: gestiona el

cambio en líneas base
● 3.2.1 Petición del cambio: especifica los
procedimientos para pedir un cambio a una línea
base y la documentación necesaria. La
documentación incluye:
● Nombre y versión del ECSs a cambiar
● Nombre y organización del peticionario
● Fecha del pedido
● Indicación de urgencia
● Necesidad del cambio

● Descripción del cambio pedido
● Prioridad
● Clasificación
● Estado
● 3.2.2 Evaluación del cambio: especifica el
análisis requerido para determinar el impacto del
cambio propuesto y los procedimientos de
revisión del resultado de dicho análisis.
● 3.2.3 Aprobación o desaprobación del

cambio: identifica las autoridades del control de
cambios y el nivel de autoridad.
● 3.2.4 Implementación de cambios: especifica
las actividades para verificar e implementar los
cambios aprobados. La documentación a rellenar
después de cada cambio incluye:
● La petición de cambio asociada
● Los nombres y versiones de los elementos
afectados
● Fecha de verificación y responsable

● Fecha de entrega o instalación y responsable
● Identificador de la nueva versión
● Métricas de fallos
● Software de implementación del cambio
● Además, también se especifican la actividades
de planificación de entrega y control
● 3.3 Contabilidad de estado de

configuración: registran e informan del estado
de los ECSs. En particular informa sobre:
● Los ECSs que van a ser susceptibles de líneas
base e informes
● Los tipos de informes de contabilidad de
estado a generar y su frecuencia
● La información que va a ser recogida,
almacenada, procesada y hecha pública
● La manera de controlar el acceso al estado de
los datos
● Cómo mínimo, para cada ECS se debe informar

sobre:
Su versión inicial aprobada
–
– El estado de los cambios pedidos
– Estado de implementación de los cambios
aprobados
● 3.4 Auditorias de configuración y
revisiones: determinan si los ECSs pueden
convertirse en líneas base.
● El plan debe identificar las auditorias de

configuración y revisiones del proyecto, es
decir, en qué puntos se deben establecer
revisiones para obtener líneas bases. Para cada
auditoría o revisión planificada se debe definir:
– El objetivo
– El ECS a auditar o revisar
– La planificación
– Los procedimientos
– Los participantes
La documentación disponible para la revisión

–
o auditoria
– El procedimiento para grabar cualquier
deficiencia e informar de acciones
correctoras
– El criterio de aprobación, y las acciones
específicas tras la aprobación
● 3.5 Control de interfaz: coordinan los cambios
de ECSs con cambios a elementos externos al
plan. Para cada interfaz, se debe identificar:
● Su naturaleza
● Las organizaciones afectadas

● La manera de controlar los ECSs de la interfaz
● La manera de documentar e incluir en líneas
base los ECSs de la interfaz
● 3.6 Control de la subcontratación/compra:
controlan los ECSs que provienen del exterior.
Para cada ECS externo se debe identificar:
● Los requisitos GCS por parte de la empresa
externa
● La forma de controlar a la empresa externa
● Auditorias y revisiones de configuración a

practicar en la empresa externa
● La forma de probar y verificar los ECSs
externos antes de incluirlos en el proyecto
● Gestión de derechos reservados y regalías
● Participación de la empresa externa en el
proceso de GCS
● 4. Planificaciones GCS: establecen la
secuencia y coordinación para las actividades
GCS y para todos los eventos que afecten la
planificación del proyecto.
● 5. Recursos GCS: identifica las herramientas

software, técnicas, equipo, personal y formación
necesaria para la implementación de las
actividades GCS.
● 6. Mantenimiento del plan GCS: identifica las
actividades y responsabilidades necesarias para
garantizar una planificación continua de la GCS
durante todo el proyecto. Se debe identificar:
● El responsable de monitorear el plan
● La frecuencia de actualización
● Forma de evaluar y aprobar cambios al plan
● La forma de hacer e informar de los cambios al

plan
● Nombre y versión del ECSs a cambiar
● Nombre y organización del peticionario
● Fecha de petición
● Indicación de urgencia
● Necesidad del cambio
● Descripción del cambio pedido
● Prioridad
● Clasificación
● Estado
Unidad 4 – Auditoría informática
● Auditoría: actividad para determinar, por medio

de la investigación, la adecuación de los
procedimientos establecidos, instrucciones,
especificaciones, codificaciones y estándares u
otros requisitos, la adhesión a los mismos y la
eficiencia de su implantación.
● Tipos de auditoría:
● Financiera
● Organizativa
● De gestión
● Informática
● Auditoría informática: conjunto de técnicas,

actividades y procedimientos destinados a
analizar, evaluar, verificar y recomendar en
asuntos relativos a la planificación, control de
eficacia, seguridad y adecuación del servicio
informático en la empresa.
● Comprende un examen metódico, puntual y
discontinuo con vistas a mejorar en:
● Rentabilidad
● Seguridad
● Eficacia
● Requisitos de la auditoría informática:

● Debe seguir una metodología preestablecida
● Debe realizarse en una fecha precisa y fija
● Debe realizarse por personal externo al
servicio informático
● Objetivos de la auditoría informática:

● El control de la función informática
● El análisis de la eficiencia de los sistemas
informáticos
● La verificación del cumplimiento de normas y
estándares en este ámbito
● La revisión de la eficaz gestión de los recursos
informáticos
● Tipos de auditoría informática:

● Auditoría de la gestión: contratación de
bienes y servicios, documentación de los
programas, etc.
● Auditoría legal del Reglamento de
Protección de Datos: cumplimiento legal de
las medidas de seguridad exigidas por el
Reglamento de desarrollo de la Ley Orgánica
de Protección de Datos.
● Tipos de auditoría informática:

● Auditoría de las bases de datos: controles
de acceso, de actualización, de integridad y
calidad de los datos.
● Auditoría de la seguridad: referidos a datos
e información verificando disponibilidad,
integridad, confidencialidad y autenticación.
● Auditoría de la seguridad lógica:
comprende los métodos de autenticación de
los sistemas de información.
● En la realización de una auditoría informática el

auditor puede realizar las siguientes pruebas:
● Pruebas sustantivas: verifican el grado de
confiabilidad del SI. Se suelen obtener
mediante observación, cálculos, muestreos,
entrevistas, técnicas de examen analítico,
revisiones y conciliaciones. Verifican asimismo
la exactitud, integridad y validez de la
información.
● Pruebas de cumplimiento: verifican el grado

de cumplimiento de lo revelado mediante el
análisis de la muestra. Proporciona evidencias
de que los controles claves existen y que son
aplicables efectiva y uniformemente.

Clases Unidad 4

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

Clases Unidad 4

Cargado por

Copyright:

Formatos disponibles

Unidad 4 – Configuración del Software

● Estándar IEEE 828-1998

● Característica del SW que diferencia su

● Los cambios aumentan la confusión si:

● Esta dinámica genera la necesidad de contar con

● La misión de la GCS es custodiar la integridad de

● Como el cambio se puede producir en cualquier

● Diferencia entre mantenimiento y GCS:

● El resultado del proceso SW se puede dividir en 3

● Un ECS es cualquier “cosa” puesta

● Los ECSs se organizan como objetos de

● Una línea curva representa una relación de

● A medida que progresa el proceso SW, el número

● Razones por las cuales se producen cambios:

● GCS: conjunto de actividades desarrolladas para

● Línea Base: es un concepto de la GCS que

● Antes que un ECS se convierta en línea base, el

● Por ejemplo, los elementos de una especificación

● La progresión de acontecimientos que conducen

● La responsabilidad principal de la GCS es el

● Preguntas que plantea la GCS:

● Preguntas que plantea la GCS:

● Estas preguntas llevan a la definición de 5 tareas:

● Decidir qué elementos se van a controlar:

● No todos los elementos están bajo el control de

● Cada objeto tiene un conjunto de características

● Cada objeto tiene un conjunto de características

● El esquema de identificación debe tener en

● El objeto de configuración 1.0 pasa la revisión y

● Mediante la identificación de los objetos:

● Versión: instancia del sistema funcionalmente

● Suponer que el componente 4 sólo se usa cuando

● La relación entre los objetos de configuración y

● Mucho control de cambio crea problemas, poco

● En un gran proyecto, el cambio incontrolado lleva

1. Solicitar el pedido de cambios

3.5 Si se acepta el pedido de cambios:

3.6 Si no se acepta el pedido de cambios:

● Se hace un pedido de cambios y se evalúa para

● El objeto a cambiar es "dado de baja" de la BD

● Los procesos de "alta" y "baja" implementan 2

● De acuerdo con un pedido de cambio aprobado,

● Tras la SQA y las pruebas apropiadas, se da de

● Una vez que el objeto ha pasado la RTF y ha sido

● El papel de la autoridad de control de cambios es

● La identificación, el control de versiones y el

● Revisiones Técnicas Formales (RTF): se

● La auditoría plantea las siguientes preguntas:

● La auditoría plantea las siguientes preguntas:

● La generación de informes de estado de la

● Se genera un informe de estado de configuración

● La salida del IEC se puede guardar en una BD de

● Los procesos de gestión de configuración por lo

● Para evitar problemas de configuración comunes,

● Algunas buenas prácticas:

● Algunas buenas prácticas:

● Identificar y almacenar los artefactos en un

● Controlar y auditar los cambios en los

● Organizar los artefactos con versiones en

● Organizar los componentes y subsistemas

● Crear referencias en los hitos del proyecto

● 3 razones para crear estas referencias:

● La trazabilidad une las necesidades, los planes

● Registrar y seguir los pedidos de cambio