|

Instituto Politécnico Nacional

Unidad Profesional Interdisciplinaria en Ingeniería, Ciencias Sociales y

Administrativas

Gestión de la configuración del software

Fuentes Aguilar Hugo Galindo González Adrián

García Martínez Marco Antonio Martínez Alonso Jair Israel

Coordinador: García Martínez Marco Antonio

Jueves 19 de Marzo del año 2014

Índice

Propósito de la Gestión de Configuración de Software Roles en el SCM Algunas terminologías Configuration item Versión Variante Baseline Directorios SCM Revisión Liberación Herramientas para la gestión de configuración de software Conclusión Fuentes:

Introducción Con el transcurso de la evolución de los sistemas informáticos, se ha encontrado que cada vez estos se vuelven más complejos y cambiantes con el paso del tiempo, obligando a quienes se ven involucrados en el desarrollo de dichos sistemas a seguir una estructuración organizacional que permite el avance ágil de dichos desarrollo que no solo brinda calidad sino también tiene un alto impacto en la tasa de errores producidos, a lo largo de este documento, encontraremos las bases que orientarán al alumno hacia una mejor comprensión y acercamiento a la gestión de configuración de software un proceso que hoy en día en cualquier proyecto de desarrollo de software se encuentra implícito.

Propósito de la Gestión de Configuración de Software Constantemente se presentan problemas al desarrollar un software debido a la complejidad que este puede llegar a obtener, encontrarse frente a un software que se encuentra en constante cambio junto a un gran equipo de trabajo puede ser uno de ellos, así también como las diferentes versiones que pueden encontrarse en dicho software lo cual representa que podremos encontrar desde una versión de software que corre en una máquina específica hasta en un diferente sistema operativa, por ello surge la necesidad de tener coordinación y orden, la necesidad de la gestión de configuración de software que es capaz de manejar software que evoluciona constantemente y mantener control de los costos involucrados en este. El propósito principal de la gestión de configuración de software es planear, organizar, controlar y coordinar la identificación, almacenamiento y cambio del software a través de su desarrollo, integración y transferencia. Podemos decir que para cada proyecto se deberá establecer un SCM (Software Configuration Management). El SCM se encarga de asegurar en grandes rasgos lo siguiente:

Los elementos del software puedan ser identificados. Que el software es construido en módulos de componentes. Que cada componente del software sea accesible y se encuentre disponible. Que los componentes del sistema nunca se pierdan, por cualquier

circunstancia. Que cada cambio en el software sea documentado y aprobado. Que ningún cambio sea perdido. Que siempre exista la posibilidad de regresar a una versión previa. Que se almacena un historial de cambios, para así poder descubrir ¿Que?,

¿Quien?, ¿Como? y ¿Cuando? se ha realizado dicho cambio. Dentro del SCM existen diferentes roles a cubrir y el administrador de proyecto es el responsable de organizar la SCM, este requiere una precisa identificación de cada elemento del sistema, el control, su estatus y el monitoreo del progreso, así como también la capacidad de definir los diferentes roles que son ejercidos en el SCM

El SCM tiene un gran impacto sobre la calidad ya que esta es primordial para un eficiente desarrollo y mantenimiento, ya que asegura que el software nunca tendra ningun tipo de percance, por lo general una mala configuración de software representa amenazas que pueden llegar a retrasar o incluso congelar un proyecto.

Roles en el SCM Administrador de Configuración Es el responsable de identificar todos los “Configuration items”, él es el encargado de definir los procesos para desarrollo y releases. Miembro de control de cambios Es el responsable de aprobar o reprobar cambios sugeridos. Desarrollador Es el encargado de ejecutar cambios que han sido aprobados y también las

actividades normales de desarrollo. El desarrollador revisa los cambios y resuelve conflictos. Auditor Responsable de la selección y evaluación de avances para el release final y

asegurarse de la consistencia y que el software se encuentre completo para dicho release Entonces formalmente como ha sido definido en ANSI/IEEE Std 610.12­1990, es la disciplina de aplicar direción técnica y administrativas para:

Identificar y documentar las características funcionales y físicas de los elementos de configuración.

Controlar cambios en esas características. Mantener un historial de cambios en procesos e implementaciones

Estándar ANSI/IEEE Std 610.12-1990 Ricardo Guzmán (2012) menciona lo siguiente:

El estándar IEEE 828 define la información mínima requerida para llevar un Plan de Gestión de la Configuración del Software Administración GCS (¿Quien?) Identifica las responsabilidades y autoriza llevar a cabo las actividades planeadas Matriz de responsabilidades Organización Responsabilidades Políticas, directivas y procedimientos aplicables.Impacto y efecto Actividades GCS (¿Qué?) Identifica toda actividad para ser realizada en la aplicación del proyecto Son 6 las actividades definidas por el estándar

Identificación de la configuración (Referenciar, identificar y Biblioteca) Elementos de la configuración Identificadores Únicos Biblioteca de la configuración Control de configuración (Control de cambio y versiones) Requerimientos Evaluación Aprobación o Desaprobación Implementación

Seguimiento de estatus y revisiones (Reportes)

Definir EC para su seguimiento Tipo de reporte y frecuencia Cantidad de información extraída, almacenada, procesada y reportada. Cantidad de accesos a usuarios de reportes

Auditoría de configuración (Revisiones)

Objetivo Elementos de Control Calendario Procedimiento Participantes Documentación Criterios

Control de interfaces (Control de Interactividad con elementos externos e internos)

Naturaleza de la interfaz Organización involucrada Cantidad de código, documentación y datos en interfaz deben ser

controlados Cantidad en control de interfaz están aprobados y liberados en una línea

base específica Control de proveedores / arrendadores (Control sobre derechos de autor)

Software Subcontratado Software Adquirido

Cronograma GCS(¿Cuándo?)

Identifica la coordinación requerida de las actividades de GCS con el resto de las actividades en el proyecto

Secuencia Dependencia Hitos y eventos Fechas Absolutas y relativas Fechas Inicio y conclusión

Recursos GCS(¿Cómo?)

Identifica las herramientas y fuentes físicas y humanas necesarias para la ejecución del Plan

Herramientas de software Técnicas Equipo Personal Entrenamiento

Mantenimiento del plan GCS

Identifica como el Plan será conservado durante sus efectos Responsable para monitorear el Plan Frecuencia de actualizaciones

realizadas Cantidad de modificaciones para el Plan a evaluar y aprobar Cantidad de modificaciones para el Plan a realizar y publicar

Algunas terminologías Para el entendimiento de todo lo referente a la configuración de software introduciremos el significado de ciertas terminologías, que si bien no son tecnicismos muy complejos, si pueden inferirse definiciones erróneas de las mismas. Además trataremos éstos ejemplos de terminologías están regidos por el estándar IEEE.

Configuration item Iniciaremos definiendo “Configuration item”; puede ser un agregado de hardware, software o ambos. Se le establece a la gestión de la configuración y su rol es de entidad única en el proceso de gestión de la configuración. También puede ser un agregado de otros CIs (Configuration items) estructurados por jerarquías.

Selección de CIs:

Requirement Analysis Document (RAD) System Design Document (SDD) Object Design Document (ODD) Unit tests Source code Input data and data bases Test data Support software (parte del producto)

En la parte del software no sólo se trata de segmentos de código de programa, sino también de todo tipo de documentos que conlleve desarrollo, estos pueden ser:

Todo tipo de archivos de código Controladores para pruebas Documentos de análisis o diseño Manuales desarrollador o usuario Configuraciones del sistema (Versión del compilador usado).

Incluso en algunos sistemas, también se incluye “configuration item” del hardware (CPU, frecuencia de velocidad de buses). Los encargados de definir los “Configuration Item” son los Managers de configuración (Configuration Managers en Inglés). Para identificar CIs: Se tiene identificador en cada CI (SCM06). Él mismo contiene nombre , tipo y versiones atribuidas del CI. Se debe asegurar que todos los identificadores son únicos.

Un ejemplo estructurados de CIs:

Versión Se le denomina versión a las publicación o re­publicación de un configuration item relacionado con una completa compilación o recopilación del elemento. Debido a lo mismo cada versión tiene su funcionalidad

Variante El término le es acuñado a CIs que tienen casi la misma funcionalidad pero diferentes aspectos como :

Ambiente del hardware Protocolos de comunicación Lenguaje del usuario

Las variantes, también, pueden ser desarrolladas para detectar problemas de software. Su Usabilidad es temporaria y serán eliminadas o descontinuadas una vez arreglado el problema.

Baseline Son CIs que se revisan y aprueban formalmente, y se les establece una rutina que se implementara su futuro desarrollo. Solo se pueden cambiar con un control formal de procedimientos de cambio. Éste término sólo se usa para sistemas completos, a pesar de que cualquier CI aprobado en un sistema puede ser llamado “Baseline”.

Directorios SCM De estos directorios podemos discernir :

Directorio del programador (Librería dinámica de IEEE); que sirve para contener entidades de software modificadas o creadas ye indica que el espacio de trabajo del programador sólo él lo controla.

Directorio Maestro (Librería controlada de IEEE); que maneja baselines actuales y los cambios hechos a ellas., su entrada es controlada y debe autorizarse su cambio.

Repositorio de software (librería estática de IEEE) : es el archivo para las diferentes baselines que se liberan y son de uso general.

Revisión Es la corrección de los errores ubicados en el diseño y código sin afectar la funcionalidad documentada.

Liberación Se dice de la distribución formal de alguna versión aprobada.

Actividades del SCM

La división de las actividades del se dividen de la siguiente forma:

http://www.inf.utfsm.cl/~visconti/iia431/Documentos/scm.pdf Identificación de la configuración: Consiste en identificar la estructura del producto, sus componentes y tipos, hacerlos únicos y accesibles de alguna manera. Esto se hace en dos actividades: Identificación de los ítems de configuración. Documentación. La documentación deberá seguir un esquema de identificación adecuada y de esta manera mantener la trazabilidad de los documentos. Dentro de estos se debe incluir, historial de revisiones del mismo, quien la realizó, un resumen detallando los cambios y quien los aprueba. Nomenclatura de los ítems de configuración Para la nomenclatura se utilizará la numeración de versiones, identificando con tres dígitos, un ejemplo seria: V 1.2.3., donde el primer dígito (1) Indica la versión del software, cambiando el segundo dígito, siempre que se agregue una función nueva(2) y un tercer dígito cuando se incluyan nuevos fix o correcciones.

Control de la configuración. Diseñar un formulario de solicitud de cambio Este formulario debe especificar los procedimientos para solicitar un baseline y la información que debe ser documentada:

Nombre (s) y version (s) del CI donde aparece el problema. Nombre y dirección del redactor Fecha de la petición Indicar la urgencia Indicar que se necesita cambiar Descripción del cambio solicitado

Evaluación de las solicitudes de cambio Una vez que fue ingresada una nueva solicitud, se evalúa la prioridad asignada, el análisis de impacto, verificando los recursos necesarios para la resolución de la solicitud. Se estima según corresponda a un fix o una nueva funcionalidad, en qué release se puede incluir, comunicando fecha estimada en la que el release estará disponible. Aprobación o Rechazo de los cambios. Esta sección del SCMP describe la organización de la tarjeta de control de configuración. (CCB) La CCB:

puede ser individual o grupal. Tiene múltiples niveles y estos son posibles dependiendo de la complejidad del

proyecto. para los proyectos pequeños un nivel de CCB es suficiente.

Esta sección del SCMP también indica el nivel de autoridad de la CCB y su responsabilidad.

En particular, el SCMP debe especificar cuando se invoca el CCB. Implementando los cambios. Esta sección del SCMP especifica las actividades de verificación y la implementación de un cambio aprobado. Una solicitud de cambio completo debe contener la siguiente información:

La solicitud de cambio (s) original Los nombres y las versiones de los elementos de configuración afectados Fecha de verificación y responsable Identificador de la nueva versión lanzamiento o fecha de instalación y la parte responsable

Esta sección también debe especificar las actividades de:

Archivamiento, completado las solicitudes de cambio Planificación y control de versiones ¿Cómo coordinar múltiples cambios? ¿Cómo añadir nuevos CIs a la configuración? ¿Cómo ofrecer una nueva baseline?

Informe de estado. Esta sección del SCMP debe contener los siguientes factores.

¿Qué elementos han de ser objeto de informes de datos de referencia y los cambios?

¿Qué tipos de informes contables de estado se generarán? ¿Cuál es su frecuencia?

¿Cómo es la información que se recopile, almacene y reportado?

¿Cómo es el acceso a los datos de estado de gestión de la configuración controlada?

Auditorías y revisiones Esta sección del SCMP identifica auditorías y revisiones para el proyecto. Una auditoría determina para cada elemento de configuración si tiene las características físicas y funcionales requeridas. Una revisión es una herramienta de gestión para el establecimiento de una baseline. Para cada auditoría o revisión el plan tiene que definir:

Objetivo Los elementos de configuración que se examinan El calendario para el examen Los procedimientos para la realización del examen Los participantes por puesto de trabajo La documentación requerida Procedimiento para las deficiencias de grabación y cómo corregirlos Criterios para la aprobación

Herramientas para la gestión de configuración de software

La Gestión de la Configuración del Software (SCM) es un conjunto de actividades diseñadas para identificar y definir los elementos en el sistema que probablemente cambien, controlando el cambio de estos elementos a lo largo de su ciclo de vida, estableciendo relaciones entre ellos, definiendo mecanismos para gestionar distintas versiones de estos elementos, y auditando e informando de los cambios realizados. Establecer y mantener la integridad de los productos de software a través del ciclo de vida del proceso de software. Los requerimientos del sistema siempre cambian durante su desarrollo y su uso, y se tienen que incorporar estos requerimientos en nuevas versiones del sistema. ¿Por qué es importante? Los cambios incontrolados aplicados a un proyecto de software lo llevan al fracaso.

Hay varias herramientas para la gestión de software como lo son: RCV Revision Control System o RCS es una implementación en software del control de versiones que automatiza las tareas de guardar, recuperar, registrar, identificar y mezclar versiones de archivos.

RCS es útil para archivos que son modificados frecuentemente, por ejemplo programas informáticos, documentación, gráficos de procedimientos, monografías y cartas. RCS también puede ser utilizado para manejar archivos binarios, pero con eficacia y eficiencia reducidas.

RCS fue inicialmente desarrollado en la década de 1980 por Walter F. Tichy mientras estaba en la Purdue University. Actualmente es parte del Proyecto GNU aunque es mantenido por la Purdue University.

CVS Concurrent Versions System o simplemente CVS, también conocido como Concurrent Versioning System, es una aplicación informática que implementa un sistema de control de versiones: mantiene el registro de todo el trabajo y los cambios en los ficheros (código fuente principalmente) que forman un proyecto (de programa) y permite que distintos desarrolladores (potencialmente situados a gran distancia) colaboren. CVS se ha hecho popular en el mundo del software libre.

Características:

CVS utiliza una arquitectura cliente­servidor: un servidor guarda la(s) versión(es) actual(es) del proyecto y su historial. Los clientes se conectan al servidor para sacar una copia completa del proyecto. Esto se hace para que eventualmente puedan trabajar con esa copia y más tarde ingresar sus cambios con comandos GNU.

Típicamente, cliente y servidor se conectan utilizando Internet, pero con el sistema CVS el cliente y servidor pueden estar en la misma máquina. El sistema CVS tiene la tarea de mantener el registro de la historia de las versiones del programa de un proyecto solamente con desarrolladores locales. Originalmente, el servidor utiliza un sistema operativo similar a Unix, aunque en la actualidad existen versiones de CVS

en otros sistemas operativos, incluido Windows. Los clientes CVS pueden funcionar en cualquiera de los sistemas operativos más difundidos.

Actualmente existen muchas versiones de CVS implantadas en los diferentes sistemas operativos.

Perforce Sistema de control de versiones comercial, propietario y centralizado desarrollado por Perforce Software, Inc.

Funciona en modo cliente/servidor. El servidor gestiona una base de datos central que contiene uno o más repositorios (depots) con versiones de los ficheros. Los clientes importan los ficheros del repositorio a su taller de trabajo (workspace) para trabajar en ellos, y posteriormente los devuelven modificados agrupados en listas de cambio. La conexión se realiza mediante TCP usando protocolos propietarios de RPC y streaming.

Es posible configurar un conjunto de servidores en cluster, establecer un par de servidores trabajando en modo master/réplica, y bien configurar un broker que establezca reglas direccionamiento al servidor adecuado para los clientes.

Para aquéllos sitios remotos donde el ancho de banda es una limitación, el proxy de Perforce media entre los clientes y el servidor y almacena las revisiones de ficheros frecuentemente transmitidas. De este modo se reduce la demanda de ancho de banda en servidor y la red.

Características:

El servidor mantiene la historia completa de los metadatos y de los ficheros En servidor mantiene la historia completa de la historia de revisiones de

ficheros ramificados, renombrados, movidos, copiados y borrados El cliente realiza la fusión de ficheros a tres bandas (three­way text file

merging), realiza seguimiento de fusiones y previene las revisiones mediante detección de ancestro común

El cliente hace presentaciones gráficas de diferencias, fusiones y herramientas de reconciliación

Se presenta una visión gráfica de históricos y ramificaciones

El interfaz administrativo funciona de modo gráfico Soporte para control distribuido de versiones Listas de cambio: los ficheros modificados pueden agruparse y manejarse

como unidades lógicas Modificaciones atómicas: al servidor hace que las listas de cambio se

actualicen de manera indivisible Aparcamiento: se puede almacenar temporalmente el trabajo en curso para

cambiar de tarea Soporte para ficheros ASCII, Unicode, binario, enlaces simbólicos, específicos

de Mac y UTF­16 Soporta internacionalización y localización Expansión de palabras clave estilo RCS Compresión de ficheros para transmisión y almacenamiento Un servidor Unix o Windows soporta clientes en cualquier sistema operativo Disparadores de eventos en el servidor SDK para integración con sistemas externos Envío de alertas de cambios mediante RSS o email Replicación de ficheros y metadatos Gestor para implementación de políticas locales, restricción de comandos o

redirección a servidores alternativos Paso de ficheros a histórico para liberar espacio en disco

Conclusión Durante el proceso de construcción de software, los cambios son inevitables. Estos provocan confusión e incertidumbre, sobre todo cuando no se han analizado o pronosticado correctamente. La finalidad de la gestión y configuración del software es conocer la estructura de procesos y herramientas para aplicar dentro de la construcción del software que nos ayudan a controlar los cambios. Es importante considerar ciertas modificaciones que pueden ocurrirle al software dentro de todo proceso de ingeniería para asegurar su control y calidad.Además el SCM nos ayuda a darle mantenimiento al software pues se documenta todo cambio, todo proceso que este realiza, ayudando a realizar un mantenimiento más fluido y más sencillo.

Fuentes: Universidad de Zurich [Documento en línea] 2004, Pearson education [Zurich, Alemania] <> https://docs.google.com/file/d/0B58NZe9A7DSaTnZUTVVmeHNJMzQ/edit [Consulta: 17­03­2014] Guzman, R.. (2012). IEEE 828 Plan de Gestión de la Configuración de Software. Marzo 18 del año 2014, de Academia.edu Sitio web: http://www.academia.edu/1742459/IEEE_828_Plan_de_Gestion_de_la_configuracion_de_Software ESA Board for Software Standardisation and Control (BSSC) [Documento en línea] Marzo 1995, European space agency [Paris, Francia] <> https://docs.google.com/file/d/0B58NZe9A7DSaQUpZWVZnY0x5QU0/edit [Consulta: 17­03­2014] No especificado. (2011). Gestión de configuración del software. No especificado, de No especificado Sitio web: http://www.slideshare.net/JohanPrevotR/gestion­de­la­configuracion­del­software­10471407 No especificado. (No especificado). Gestión de configuración del software. No especificado, de No especificado Sitio web: http://www.kybele.etsii.urjc.es/docencia/IS4/2013­2014/Material/IS4.11.12.Tema.VIII.Gesti%C3%B3n%20Configuraci%C3%B3n.pdf