administraciÓn de proyectos · que se crean durante el proceso de software. 1) una base de datos...

Facultad de Estadística e Informática

ADMINISTRACIÓN DE PROYECTOS


Bibliografía

Pressman, R.S., Ingeniería del Software. Un enfoque práctico, quinta edición, 2002, España.

Sommerville I., Ingeniería de Software, Addison-Wesley, 6ª. Edición, 2002, México.


Agenda Unidad VII. 7. Control de cambios

◦ 7.1 Gestión de cambios ◦7.2 Administración de la configuración


VII. Control de cambios El arte de coordinar el desarrollo de software para minimizar [...] la confusión se llama administración de la configuración, que es el arte de identificar, organizar y controlar las modificaciones que se hacen al software que construirá un equipo de programación. La meta es maximizar la productividad al minimizar los errores.

Babich [Bab86]


VII. Control de cambios ¿Cuándo surge la confusión? Los cambios no se analizan antes de que se realicen.

Los cambios no se registran antes de que se implanten.

Los cambios no se reportan a quienes tienen necesidad de conocerlos

Los cambios no se controlan en forma que mejore la calidad y se reduzca el error.


Actividades sombrilla. Se aplican a lo largo del proyecto y ayudan a administrar y controlar el avance, la calidad, el cambio y el riesgo:

Seguimiento y control del

proyecto de software

Administración de riesgo

Aseguramiento de la calidad del software

Revisiones técnicas Medición

Administración de la

configuración del software

Administración de la

reutilización

Preparación y producción del producto del

trabajo


VII. Control de cambios La administración de la configuración del software (ACS) es una actividad sombrilla.

1) Identificar el cambio

2) Controlar el cambio

3) Garantizar que el cambio se implementó de manera adecuada y

4) Reportar los cambios a otros que puedan estar interesados.


VII. Control de cambios “Es muy fácil que un torrente de cambios descontrolados convierta en caos un proyecto de software bien estructurado”


VII. Control de cambios ¿Qué es la configuración del software? Son los ítems que comprenden toda la información producida como parte del

proceso de software.

Esta información que puede dividirse en tres categorías amplias:

1) Programas de cómputo (tanto en el nivel de fuente como en formatos ejecutables)

2) Productos de trabajo que describen los programas de cómputo (dirigidos a varios participantes) y

3) Datos o contenido (incluidos dentro del programa o externos a él).


VII. Control de cambios Un Item de Configuración del Software (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).


VII. Control de cambios Los ICS se organizan para formar objetos de configuración que puedan catalogarse con un solo nombre en la base de datos del proyecto.

Un objeto de configuración tiene un nombre y atributos, y está “conectado” con otros objetos mediante relaciones.


VII. Control de cambios Fuentes fundamentales de cambio: Nuevas condiciones empresariales o de mercado.

Nuevas necesidades de los accionistas demandan modificación a los datos producidos por los sistemas de información, a la funcionalidad que entregan los productos o a los servicios que ofrece un sistema basado en computadora.


VII. Control de cambios Fuentes fundamentales de cambio: La reorganización o crecimiento/reducción de la empresa produce

cambios en las prioridades proyectadas o en la estructura del equipo de ingeniería de software.

Restricciones presupuestales o de calendario causan una redefinición del sistema o del producto.


VII. Control de cambios Escenario de Administración de Configuración del Software

Gerente de Proyecto

• Garantizar que el producto se desarrolla dentro de cierto marco temporal.

• Elabora y difunde la lista de tareas para los ingenieros.

• Recopila estadísticas acerca de los componentes que hay en el sistema de software, tales como la información que determina cuáles componentes del sistema son problemáticos.

• Ve la AC como un mecanismo de auditoría

Gerente de Configuración

• Garantizar que se sigan los procedimientos y políticas para crear, cambiar y probar el código, así como hacer accesible la información acerca del proyecto.

• Crea mecanismos para: realizar peticiones oficiales de cambios, evaluarlos (mediante un Consejo de Control de Cambios que sea responsable de aprobar los cambios al sistema de software) y autorizarlos.

• Ve la AC como un mecanismo de control, rastreo y generación de políticas

Ingenieros de Software

• Su meta es trabajar eficazmente. • Comunicarse y coordinarse de manera

eficiente. • Usan herramientas que ayudan a construir

un producto de software consistente. • Ve la AC como mecanismo de control de

cambio, construcción y acceso

Producto pequeño de 15,000 líneas de código. Equipo de 6 personas.

Existen mecanismos para garantizar que, para componentes que experimentan cambios simultáneos, hay alguna forma de resolver los conflictos y la fusión de cambios. Se conserva una historia de la evolución de todos los componentes del sistema, una bitácora con las razones de los cambios y un registro de lo que realmente cambió.


VII. Control de cambios Escenario de Administración de Configuración del Software

El Cliente

El cliente usa el producto.

Sigue procedimientos formales para solicitar cambios y para indicar errores en el producto (Se encuentra bajo proceso de AC).

Ve la AC como un camino para garantizar la calidad.


VII. Control de cambios Elementos de un sistema de administración de la configuración: Elementos componentes: Archivos, bases de datos. Elementos de proceso: Acciones y tareas que definen un enfoque efectivo de

la gestión del cambio. Elementos de construcción: Herramientas que automatizan el ensamblaje

adecuado de componentes validados (es decir, la versión correcta). Elementos humanos: Conjunto de herramientas utilizados por el equipo de

software para implementar ACS efectiva.


VII. Control de cambios Líneas de referencia

Una especificación o producto que se revisó formalmente y con el que se estuvo de acuerdo, que a partir de entonces sirve como base para un mayor desarrollo y que puede cambiar sólo a través de procedimientos de control de cambio formal.


VII. Control de cambios Antes de que un ítem de configuración del software se convierta en línea de referencia, los cambios pueden realizarse rápida e informalmente.

Una vez establecida la línea de referencia, pueden realizarse cambios, pero debe aplicarse un procedimiento formal específico para evaluar y verificar cada uno de ellos


VII. Control de cambios Una línea de referencia es un hito en el desarrollo del software.

Una línea de referencia se marca al entregar uno o más ítems de configuración del software que se aprobaron como consecuencia de una revisión técnica.


VII. Control de cambios Por ejemplo:

1. Los elementos de un modelo de diseño se documentaron y revisaron.

2. Se encontraron y corrigieron errores.

3. Una vez que todas las partes del modelo se revisaron, corrigieron y luego aprobaron, el modelo de diseño se convierte en línea de referencia.

4. Los cambios adicionales a la arquitectura del programa (documentada en el modelo de diseño) pueden realizarse sólo después de que cada uno se evalúa y aprueba.


VII. Control de cambios Después de revisar y aprobar los ICS, se colocan en una base de datos del proyecto (también llamada librería de proyecto o repositorio de software).

Cuando un miembro de un equipo de ingeniería de software quiere hacer una modificación a un ICS que se ha convertido en línea de referencia, se copia de la base de datos del proyecto en el espacio de trabajo privado del ingeniero.

Sin embargo, este ICS extraído puede modificarse solamente si se siguen controles ACS


VII. Control de cambios


VII. Control de cambios El Repositorio ACS

Antes: Los ICS se mantenían en papel, recopilados en carpetas y almacenados en archiveros.

Era difícil encontrar un ICS.

Era muy desafiante determinar cuáles ítems cambiaban, cuándo y por quién.

Construir una nueva versión de un programa existente consumía mucho tiempo y era proclive al error

Describir relaciones detalladas y complejas entre los ítems de configuración era virtualmente imposible.


VII. Control de cambios El Repositorio ACS

Ahora: Los ICS se mantienen en una base de datos del proyecto, o repositorio. Repositorio “Cualquier cosa o persona que se considera como centro de

acumulación o almacenamiento”. El programador debía recordar la ubicación de toda la información relevante para un

proyecto de software. El repositorio es una “cosa”: una base de datos que actúa como el centro de acumulación y

de almacenamiento de la información de ingeniería de software. El papel de la persona (el ingeniero del software) es interactuar con el repositorio, usando las herramientas que se integran con él.


VII. Control de cambios El repositorio ACS

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.


VII. Control de cambios Características del repositorio ACS 1) integrarse con o directamente apoyar las funciones de administración del

proceso 2) apoyar reglas específicas que gobiernan la función ACS y los datos

mantenidos dentro del repositorio 3) proporcionar una interfaz hacia otras herramientas de ingeniería de

software 4) acomodar almacenamiento de objetos de datos sofisticados (por

ejemplo, texto, gráficos, video, audio).



El proceso ACS


VII. Control de cambios El repositorio ACS debe ofrecer apoyo a: Versiones

Rastreo de dependencia y gestión del cambio.

Rastreo de requerimientos

Administración de la configuración.

Ensayos de auditoría.


VII. Control de cambios Cinco tareas ACS (identificación, control de versión, control de cambio, auditoría de la configuración y reporte)


VII. Control de cambios ¿Cómo identifica un equipo de software los elementos discretos de una configuración de software?

¿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?


VII. Control de cambios ¿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?


VII. Control de cambios • ¿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?


VII. Control de cambios Identificación de objetos. Cada ICS se nombra y organiza usando el enfoque orientado a objetos.

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”


VII. Control de cambios Control de versión. 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.

1) Una base de datos de proyecto (repositorio).

2) Una capacidad de administración de versión que almacena todas las versiones

3) Una facilidad para elaboración que le permite recopilar todos los objetos de configuración relevantes

4) Rastreador de conflictos. permite al equipo registrar y rastrear el estado de todos los conflictos sobresalientes


Control de cambio.



VII. Control de cambios Auditoría de configuración

¿Cómo puede un equipo de software asegurarse de que el cambio se implementó adecuadamente?

1) Revisiones técnicas

2) Auditoría a la configuración del software.


VII. Control de cambios La revisión técnica se enfoca en la exactitud técnica del objeto de configuración que se modificó.

La auditoría hace y responde las siguientes preguntas:

1. ¿Se realizó el cambio especificado en la OCI (orden de cambio de ingeniería )? ¿Se incorporó alguna modificación adicional?

2. ¿Se llevó a cabo una revisión técnica para valorar la exactitud técnica?


VII. Control de cambios 3. ¿Se siguió el proceso del software y se aplicaron adecuadamente los estándares de ingeniería de software?

4. El cambio se “resaltó” en el ICS? ¿Se especificaron la fecha del cambio y el autor del cambio? ¿Los atributos del objeto de configuración reflejan el cambio?

5. ¿Se siguieron los procedimientos ACS para anotar, registrar y reportar el cambio?

6. ¿Los ICS relacionados se actualizaron adecuadamente?


VII. Control de cambios Reporte 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á?


VII. Control de cambios Reporte del estado de la configuración (REC). Cada vez que se aprueba un cambio se hace una entrada REC.

Cada vez que se lleva a cabo una auditoría de la configuración, los resultados se reportan como parte de la tarea REC.

La salida del REC puede colocarse en una base de datos en línea o en un sitio web, los desarrolladores de software o el personal de apoyo puedan acceder a la información


VII. Control de cambios Control de versiones: Fusion Forge

GNU Savannah

http://savannah.gnu.org

GitHub

https://github.com/

https://github.com/


GRACIAS POR SU ATENCIÓN

administraciÓn de proyectos · que se crean durante el proceso de software. 1) una base de datos...

Documents