CAPÍTULO 22: ADMINISTRACIÓN DE LA CONFIGURACIÓN DEL SOFTWARE

Cuando se construye software de computadoras, el cambio es inevitable. Y el cambio aumenta el nivel de confusión cuando los miembros de un equipo de software trabajan en un proyecto.
22.1 ADMINISTRACIÓN DE LA CONFIGURACIÓN DEL SOFTWARE
1. La salida del proceso de software es información que puede dividirse en tres categorías amplias:
  1. 1) programas de cómputo (tanto en el nivel de fuente como en formatos ejecutables),
  2. 2) productos de trabajo que describen los programas de cómputo (dirigidos a varios participantes)
  3. 3) datos o contenido (incluidos dentro del programa o externos a él). Los ítems que comprenden toda la información producida como parte del proceso de software se llaman colectivamente configuración del software.
2. 22.1.2 Elementos de un sistema de administración de la configuración
  1. En su exhaustivo artículo acerca de la administración de la configuración del software, Susan Dart [Dar01] identifica cuatro elementos importantes que deben existir cuando se desarrolla un sistema de administración de la configuración:
    1. Elementos componentes:
      1. s: conjunto de herramientas acopladas dentro de un sistema de administración de archivos (por ejemplo, base de datos) que permite el acceso a cada ítem de configuración del software, así como su gestión.
    2. Elementos de proceso:
      1. colección de acciones y tareas que definen un enfoque efectivo de la gestión del cambio (y actividades relacionadas) para todos los elementos constituyentes involucrados en la administración, ingeniería y uso del software
    3. Elementos de construcción
      1. conjunto de herramientas que automatizan la construcción de software al asegurarse de que se ensambló el conjunto adecuado de componentes validados (es decir, la versión correcta)
    4. Elementos humanos
      1. conjunto de herramientas y características de proceso (que abarcan otros elementos AC) utilizados por el equipo de software para implementar ACS efectiva.
  2. 22.1.3 Líneas de referencia
    1. El cambio es un hecho de vida en el desarrollo de software. Los clientes quieren modificar los requerimientos. Los desarrolladores quieren cambiar el enfoque técnico. Los gerentes quieren modificar la estrategia del proyecto
  3. 22.1.4 Ítems de configuración del software
    1. Ya se definió un ítem de configuración del software como la información que se crea como parte del proceso de ingeniería de software. En última instancia, un ICS podría considerarse como una sola sección de una gran especificación o como un caso de prueba en una gran suite de pruebas. De manera más realista, un ICS es todo o parte de un producto de trabajo (por ejemplo, un documento, toda una suite de casos de prueba o un componente de programa nominado)
22.2 EL REPOSITORIO ACS
1. En los primeros días de la ingeniería de software, los ítems de configuración del software se mantenían como documentos en papel (¡o tarjetas perforadas!), colocadas en carpetas de papel o de anillos, y se almacenaban en archiveros metálicos.
2. 22.2.1 El papel del repositorio
  1. El repositorio ACS es el conjunto de mecanismos y estructuras de datos que permiten a un equipo de software administrar el cambio en forma efectiva. Proporciona las funciones obvias de un moderno sistema de administración de base de datos, al asegurar integridad, posibilidad de compartir e integración de datos. Además, el repositorio ACS proporciona un centro para la integración de herramientas de software, es fundamental en el flujo del proceso de software y puede reforzar la estructura y el formato uniforme para los productos que son resultado de la ingeniería de software.
3. 22.2.2 Características y contenido generales
  1. Las características y el contenido del repositorio se entienden mejor al observarlo desde dos perspectivas: qué debe almacenarse en él y qué servicios específicos proporciona.
4. 22.2.3 Características ACS
  1. Para apoyar el ACS, el repositorio debe tener un conjunto de herramientas que proporcionan apoyo a las siguientes características:
    1. Versiones.
      1. Conforme avanza el proyecto, se crearán muchas versiones (sección 22.3.2) de productos resultantes individuales. El repositorio debe guardar todas estas versiones para permitir la administración efectiva de los productos liberados y, a los desarrolladores, regresar a versiones anteriores durante las pruebas y la depuración.
    2. Rastreo de dependencia y gestión del cambio.
      1. El repositorio administra una amplia variedad de relaciones entre los elementos de datos almacenados en él. En éstos se incluyen relaciones entre entidades y procesos empresariales, entre las partes de un diseño de aplicación, entre componentes de diseño y la arquitectura de información de la empresa, entre elementos de diseño y entregables, etcétera. Algunas de estas relaciones son meras asociaciones, y otras son dependencias o relaciones obligatorias.
    3. Rastreo de requerimientos.
      1. Esta función especial depende de la administración de vínculos y ofrece la capacidad de rastrear todos los componentes de diseño y construcción, así como entregables que resulten de una especificación de requerimientos determinada (rastreo hacia adelante). Además, proporciona la capacidad de identificar qué requisito genera algún producto de trabajo determinado (rastreo hacia atrás).
    4. Administración de la configuración.
      1. Una instalación de administración de la configuración sigue la pista a una serie de configuraciones que representa hitos de proyecto específicos o liberaciones de producción
    5. Ensayos de auditoría.
      1. Un ensayo de auditoría establece información adicional acerca de cuándo, por qué y quién realiza los cambios. La información acerca de la fuente de los cambios puede ingresarse como atributos de objetos específicos en el repositorio.
5. 22.3 EL PROCESO ACS
  1. El proceso de administración de la configuración del software define una serie de tareas que tienen cuatro objetivos principales
    1. 1) identificar todos los ítems que de manera colectiva definen la configuración del software
    2. 2) administrar los cambios a uno o más de estos ítems
    3. 3) facilitar la construcción de diferentes versiones de una aplicación
    4. 4) garantizar que la calidad del software se conserva conforme la configuración evoluciona con el tiempo.
    5. • ¿Cómo identifica un equipo de software los elementos discretos de una configuración de software?
      1. •¿Cómo gestiona una organización las muchas versiones existentes de un programa (y su documentación) de manera que permita que el cambio se acomode eficientemente?
        ¿Cómo controla una organización los cambios antes y después de que el software se libera a un cliente?
        • ¿Quién tiene la responsabilidad de aprobar y clasificar los cambios solicitados?
        • ¿Cómo puede garantizarse que los cambios se realizaron adecuadamente?
        • ¿Qué mecanismo se usa para enterar a otros acerca de los cambios que se realizaron?
        Estas preguntas conducen a la definición de las cinco tareas ACS (identificación, control de versión, control de cambio, auditoría de la configuración y reporte) que se ilustran en la figura 22.4.
  2. 22.3.1 Identificación de objetos en la configuración del software
    1. Para controlar y administrar ítems de configuración del software, cada uno debe nombrarse por separado y luego organizarse usando un enfoque orientado a objetos. Es posible identificar dos tipos de objetos [Cho89]: básicos y agregados.
      1. Un objeto básico es una unidad de información que se crea durante el análisis, el diseño, el código o la prueba.
        Por ejemplo, un objeto básico puede ser una sección de una especificación de requerimientos, parte de un modelo de diseño, código fuente para un componente o una suite de casos de prueba que se utilice para ejercitar el código
        como ComponentN y UMLClassDiagramN
      2. Un objeto agregado es una colección de objetos básicos y de otros objetos agregados.
        Por ejemplo, un DesignSpecification es un objeto agregado. Conceptualmente, puede vérsele como una lista nominada (identificada) de punteros que especifican objetos agregados
        como ArchitecturalModel y DataModel,
      3. Cada objeto tiene un conjunto de características distintivas que lo identifican de manera única: un nombre, una descripción, una lista de recursos y una “realización”
    2. 22.3.2 Control de versión
      1. El control de versión combina procedimientos y herramientas para administrar diferentes versiones de objetos de configuración que se crean durante el proceso de software.
        Un sistema de control de versión implementa o se integra directamente con cuatro grandes capacidades:
        1) una base de datos de proyecto (repositorio) que almacena todos los objetos de configuración relevantes,
        3) una facilidad para elaboración que le permite recopilar todos los objetos de configuración relevantes y construir una versión específica del software.
        3) una facilidad para elaboración que le permite recopilar todos los objetos de configuración relevantes y construir una versión específica del software.
        Además, los sistemas de control de versión y de control de cambio con frecuencia implementan una capacidad de rastreador de conflictos (también llamado rastreador de errores) que permite al equipo registrar y rastrear el estado de todos los conflictos sobresalientes asociados con cada objeto de configuración
        Para lograr esto, se aplica un enfoque de modelado de sistema. El modelo del sistema contiene
        1) una plantilla que incluye una jerarquía de componente y un “orden de construcción” para los componentes que describen cómo debe construirse el sistema,
        2) reglas de construcción
        3) reglas de verificación.
      2. 22.3.3 Control de cambio
        El control del cambio es vital. Pero las fuerzas que lo hacen necesario también lo hacen desconcertante.
        Bach reconoce que se está frente a un acto de equilibrio. Mucho control del cambio y se crearán problemas. Muy poco y se crearán otros problemas. Para un gran proyecto de software, el cambio descontrolado conduce rápidamente al caos. Para tales proyectos, el control del cambio combina procedimientos humanos y herramientas
        22.3.4 Auditoría de configuración
        La identificación, control de versión y control del cambio ayudan a conservar el orden en lo que de otro modo sería una situación caótica y fluida.
        22.3.5 Reporte de estado
        El reporte del estado de la configuración (en ocasiones llamado contabilidad de estado) es una tarea ACS que responde las siguientes preguntas:
        1) ¿Qué ocurrió?
        2) ¿Quién lo hizo
        3) ¿Cuándo ocurrió?
        4) ¿Qué más se afectará?
        22.4 ADMINISTRACIÓN DE LA CONFIGURACIÓN PARA WEBAPPS
        Si usted es miembro de un equipo webapp, debe abrazar el cambio. Más aún, un equipo ágil típico se abstiene de todas las cosas que parecen ser pesadas, burocráticas y formales. La administración de la configuración del software con frecuencia se ve (aunque incorrectamente) como poseedora de estas características
        22.4.1 Conflictos dominantes
        Las estrategias generales para la administración de la configuración del software (ACS) descritas en este capítulo son aplicables, pero las tácticas y las herramientas deben adaptarse para conformarse a la naturaleza única de las webapps. Cuando se desarrollan tácticas para la administración de la configuración de una webapp, deben considerarse cuatro conflictos [Dar99].
        Contenido.
        Personas.
        Escalabilidad.
        Políticas.
        22.4.2 Objetos de configuración de webapps
        Los objetos de la webapp pueden identificarse (con nombres de archivo asignados) en cualquier forma que sea adecuada para la organización. Sin embargo, se recomiendan las siguientes convenciones para asegurar la conservación de la compatibilidad entre plataformas: los nombres de archivo deben limitarse a 32 caracteres de longitud, deben evitarse nombres con mayúsculas mezcladas o todos con mayúsculas, así como subrayar los nombres de los archivos.
        22.4.3 Administración de contenido
        El uso más común de un sistema de administración de contenido ocurre cuando se construye una webapp dinámica.
        El subsistema de recopilación. El contenido se deriva de datos e información que debe crearse o adquirirse por un desarrollador de contenido. E
        El subsistema de administración. Una vez que existe el contenido, debe almacenarse en un repositorio, catalogarse para adquisición y uso posterior y etiquetarse p
        El subsistema de publicación. El contenido debe extraerse del repositorio, convertirse a una forma que sea manejable para su publicación y formatearse de modo que pueda transmitirse a navegadores en el lado cliente. E
        22.4.4 Administración del cambio
        Para implementar administración de cambio efectiva dentro de la filosofía “codifica y ve” que continúa dominando el desarrollo web debe modificarse el proceso de control de cambio convencional. Cada cambio debe categorizarse en una de cuatro clases
        Clase 1: un cambio de contenido o función que corrige un error o aumenta el contenido o funcionalidad locales
        Clase 2: un cambio de contenido o función que tiene un impacto sobre otros objetos de contenido o componentes funcionales
        Clase 3: un cambio de contenido o función que tiene un amplio impacto a través de una web app (por ejemplo, extensión de funcionalidad trascendental, significativo aumento o reducción en contenido, grandes cambios requeridos en navegación)
        Clase 4: un gran cambio de diseño (por ejemplo, un cambio en diseño de interfaz o enfoque de navegación) que inmediatamente será notable para una o más categorías de usuario
        22.4.5 Control de versión
        Conforme una webapp evoluciona a través de una serie de incrementos, pueden existir al mismo tiempo algunas versiones diferentes
        22.4.6 Auditoría y reporte
        Es posible crear un reporte de bitácora completo de modo que todos los miembros del equipo web tengan una cronología de los cambios hechos en un periodo definido.
INTEGRANTES
1. MILLAN LUGO JOSE OCTAVIO
2. José Alfonso Pech Magaña
3. Gerardo Alain Salazar Tamay

Next up

CAPÍTULO 22: ADMINISTRACIÓN DE LA CONFIGURACIÓN DEL SOFTWARE

Description

Resource summary

Similar

	Created by Octavio Jose over 6 years ago