Practicas de plan

Práctica de Gestión de Configuración

Página 1 de 11

Pablo Michelis

Ingeniería de Software II

Gestión de Configuración de Software: Práctica de Gestión de Configuración

Requisitos para la resolución de la práctica

El alumno debe haber asistido a la clase de Gestión de Configuración y de Gestión de Requerimientos.

Estamos también asumiendo que el alumno domina los principios de negociación de proyectos, principalmente la técnica del diagrama de Kiviat para determinar las variables de ajuste y las restricciones de un proyecto, de acuerdo a la visión de producto relevada al cliente. Esta técnica es vista en una de las primeras clases llamada “5 dimensiones” [4].

Por último, dado que parte de las decisiones que el líder de proyecto toma durante la elaboración de un plan de gestión de configuración se relacionan con el ciclo de vida del producto, es necesario que el alumno conozca temas de gestión del ciclo de vida que se dictan en la clase de “Plan Detallado” [5].

Gestión de Configuración

La misión de la Gestión de Configuración de Software (SCM1) es custodiar la estabilidad de los productos de software a lo largo del ciclo de vida del producto.

Para esto, es necesario acompañar la actividad de cambio a lo largo del ciclo de vida con actividades de control. También es necesario conocer a priori cuales son los artefactos que componen los productos de software que deben ser auditados de modo de asegurar la integridad del cambio a lo largo de la línea de base.

Dado que la estabilidad de los productos de software requiere que los mismos se encuentren disponibles, la estrategia de “releasing” y “baselining” tiene gran importancia en el momento de construir el plan de SCM. Objetivo de la Práctica

Como toda actividad relacionada con la gestión de los procesos de software, las disciplinas de SCM requieren planificación. Es el objetivo de esta práctica que el alumno ejercite en un proyecto prototípico, los conceptos necesarios para la construcción del plan SCM.

A partir de los ejercicios contenidos en el presente documento, el alumno se encontrará en condiciones de identificar las variables que deben ser estudiadas en un proyecto de desarrollo para la construcción del plan de SCM, y de algunas de las métricas que deben ser observadas de modo de asegurar que el contexto cambiante de un proyecto no comprometa la estabilidad de los productos de software que están siendo construidos.

1 SCM stands for Software Configuration Management.

A partir de aquí hablamos para los efectos de la práctica de gestión de configuración de software (y no de

Gestión de Configuración en general), puesto que no consideraremos cuestiones relacionadas con hardware y

firmware que son también vistas en clase pero para las cuales no estamos proponiendo ejercicios en esta

práctica.


Página 2 de 11

Pablo Michelis

Práctica

Parte A: SCM durante la construcción de software

Una organización es contratada para construir una aplicación para una entidad bancaria, tendiente a que los clientes puedan gestionar sus cuentas personales y puntos del programa de fidelidad, desde cajeros localizados en las sucursales del banco (AGC – Auto Gestión de Cuentas).

El enunciado de alcance del proyecto que ya se ha construido incluye un WBS donde se identifican los siguientes ítems de trabajo principales (segundo nivel definido):

0.0. AGC Software

1.0. Project Management

2.0. Software Quality Assurance

3.0. Software Configuration Management

4.0. Operations & Deployment

5.0. Software Product Engineering

5.1. Detailed Design

5.2. Code

5.3. Unit Test

5.4. Code Fix

6.0. Software System Engineering

6.1. Software Requirement Engineering

6.2. Architecture Design

6.3. Integration & Test

La organización del equipo de trabajo es la siguiente:

Project Manager

Software Product

Manager

Internal QA SCM Librarian Quality Control

Manager

Software Tester 1

Software Tester 2

Software Architect

Software Designer

Software Developer 1



Software Analyst 1

Software Analyst 2

Ilustración 1: Organigrama del proyecto

Dadas las condiciones de estabilidad del requerimiento, y por ser la calidad de la aplicación el driver del proyecto, es posible en casi todos los casos negociar costo y cronograma en los casos que de no hacerlo, la calidad se vea comprometida. Por este motivo se selecciona un ciclo de vida pure waterfall, cuyo proceso sigue el diagrama siguiente:


Página 3 de 11

Pablo Michelis

Ilustración 2: Proceso de Desarrollo


Página 4 de 11

Pablo Michelis

En base al diagrama de la ilustración 2:

1. Identificar las líneas de base mínimas que se deben establecer para gestionar la relación con el cliente.

2. Identificar las líneas de base adicionales que se deben establecer para la gestión interna del desarrollo del producto.

3. Proponga un esquema de numeración de versiones que sea consistente con la política de baselining que ha identificado en (1) y (2).

4. Proponga una arquitectura simple y un esquema de control de cambio relacionando con el proceso de la ilustración 2, usando los roles que considere desarrollan cada actividad según el organigrama de la ilustración 1. El resultado de esta actividad deberían ser tuplas de la forma:

<[habilitado | deshabilitado], componente SCM, etapa de ciclo de vida, rol del equipo de trabajo>

donde las mismas indican que es permitido o no el cambio de un determinado componente, por parte de un rol para una determinada etapa.

5. Proponga actividades de auditoría de configuración para asegurar la integridad de cada línea de base identificada en (1) y (2).

6. ¿Qué relación cree que existe entre las actividades de control de configuración que identificó en (4) y las actividades de auditoría identificadas en (5) a medida que avanzo sobre cada fase del ciclo de vida del producto?

7. Proponga estrategias de reporting (configuration status accounting) asociadas con las etapas y las actividades de control de calidad asociadas. identifique para cada actividad de construcción e integración, la actividad de control de calidad necesaria y cómo SCM reporting puede colaborar en optimizar estos procesos.

Parte B: SCM durante el mantenimiento y soporte del sistema de software

Una vez finalizado el proyecto se decide contratar a la misma organización para realizar el mantenimiento de la aplicación construida. A causa del comportamiento de los clientes con respecto al uso de la aplicación, existe una ventana semanal en la cual se pueden efectuar despliegues. Esta ventana se encuentra entre las 10pm de los días viernes y las 8am del sábado, esta franja horaria se encuentra motivada por el riesgo a que un determinado cliente requiera el servicio estando el mismo inhabilitado por actividades de mantenimiento.. Adicionalmente, es deseable que los despliegues sean realizados el primer fin de semana del mes debido a que estadísticamente se sabe que es el momento en el cual se registran menos accesos.

8. Bajo las mismas condiciones iniciales (calidad es un driver, mientras que el cronograma y el costo tienen cierto grado de libertad). Proponga una estrategia para la gestión de cambios sobre el producto instalado, y decida una posible estrategia para la gestión del backlog de requerimientos que se ajuste a la propuesta hecha por Ud. en la parte A de la práctica.

9. ¿Como impacta sobre lo decidido en (8) un requerimiento de emergencia? ¿Qué impacto tiene esto sobre la relación existente entre los elementos enumerados a continuación?

a. Release management.

b. Change request management + Backlog de requerimientos..


Página 5 de 11

Pablo Michelis

10. Proponga una estrategia de release management y change request management que contemple los cambios de emergencia. Construya un cronograma de releasing prototípico para el nuevo escenario que considere situaciones de más de un requerimiento de emergencia entre dos releases consecutivos.

11. ¿Cuál es la ventana de tiempo mínima entre releases de acuerdo a las condiciones de contexto descritas?

12. ¿Cómo impactaría un requerimiento de cambio que supere la ventana de tiempo que Ud estableció en (10)?

Parte C: SCM durante cambios en el contexto del proyecto de software

13. Detallar los cambios que se producirían en caso de utilizar un waterfall con overlapping.

14. Ídem (13) cuando el ciclo de vida es waterfall con subprojectos.

15. En base a lo visto anteriormente, ¿considera al ciclo de vida waterfall como una buena elección para este proyecto?

Resolución de Práctica


Página 6 de 11

Pablo Michelis

Parte B)

Ejercicio 8)

Gestión del Releases

La estrategia se basa en gestionar los cambios sobre una ventana de tiempo de tamaño fijo

(solución de time boxing). Esto ocurre porque a partir de ordenar las fechas de los

despliegues, es posible planear luego “hacia atrás” (backward planning) las fechas de todas

las actividades de construcción (micro cronograma de desarrollo). El hecho de trabajar con un

volumen fijo de carga en cada ventana permite proponer un solapamiento más eficiente para

las etapas que requieren diferentes roles, de modo que exista continuidad de trabajo para todas

las áreas de conocimiento..

La organización del equipo de trabajo y las tareas asociadas se hará “basada en actividades”

(ver [2] para más detalles). De este modo se compondrán change sets, que serán asociados a

un conjunto de actividades dentro de la ventana de tiempo definida.

Las actividades componen las siguientes grandes áreas de proceso (core process workflows):

1) Conjunto de Requerimientos Cerrado: Conjunto de cambios acordado.

2) Requerimientos Especificados: Especificación de cambios e impacto.

3) Diseño Detallado: Especificación de cambios posibles y estrategia de implementación.

4) Alfa (Código Completo): Versión inicial para revisión sobre primer nivel de referentes

de negocio (alfa version).

5) Alfa Revisada: Hallazgos de primer revisión de usuario.

6) Beta (Candidato a Release): Revisión definitiva para pasar prueba de aceptación.

7) Release.

Una posible numeración que respete este patrón de cronograma, siendo “x” el número de

siguiente release a ser liberado, es la siguiente:

(1) x.0.a.1

(2) x.0.a.2

(3) x.0.a.3

(4) x.0.a

(5) x.0.b.1

(6) x.0.b

(7) x.0



Página 7 de 11

Pablo Michelis

... y el cronograma prototipo de cada etapa el siguiente:

Ene 06 Mar 06

06/3/3Release

X.006/2/3

(X-1).0

06/1/30Conjunto de Requerimientos

Cerrado

X.0.a.1

06/2/28Beta (Candidato a

Release)

X.0.b

06/2/23Alfa Validada

X.0.b.1

06/2/20Alfa (Código

Completo)

X.0.a06/2/13Diseño Detallado

X.0.a.3

06/2/8Requerimientos

Especificados

X.0.a.2

y la estabilidad necesaria entre líneas de base la siguiente:

Inicial: Carga del backlog

Objetivo:

o Estabilizar el conjunto de requerimientos de cambio que serán incluidos en la

siguiente iteración.

Actividades:

o Carga de backlog de requerimientos y priorización.

o Extracción y análisis de requerimientos “preliminar”.

o Negociación sobre release en el cual serán implementados.

o Estimación de esfuerzo.

o Priorización de requerimientos de cambio.

Fase [X.0.a.1] a [X.0.a.2]

Objetivo:

o Estabilizar el impacto de los cambios en los productos de software.

o Reducir el riesgo que la ventana negociada no sea suficiente para la

implementación de los mismos.

Actividades:

o Extracción y análisis de requerimientos.

o Análisis de impacto.

o Especificación de requerimientos.

Fase [X.0.a.2] a [X.0.a.3]

Objetivo:

o Controlar riesgos altos asociados al impacto estudiado en fase anterior.



Página 8 de 11

Pablo Michelis

o Asegurar que la fase siguiente esté definida a nivel actividades y asignaciones

realizables.

Actividades:

o El esfuerzo de esta etapa se basa en diseñar los cambios en el software

tendientes a atender los requerimientos congelados en X.0.a.1.

o Debo negociar cambios que implican mayores riesgos o que tienen conflicto

con requerimientos más prioritarios para etapas posteriores.

o Debo ordenar el cronograma de implementación de modo de optimizar la

distribución y el uso de los recursos de desarrollo.

Fase [X.0.a.3] a [X.0.a]

Objetivo:

o Realizar las modificaciones especificadas sobre los productos de software.

Actividades:

o Modificar código.

o Realizar modificaciones sobre la documentación del software.

o Construir los procedimientos de despliegue.

o Realizar pruebas unitarias e integrales.

o Inspecciones de código.

Fase [X.0.a] a [X.0.b.1]

Objetivo:

o Asegurar que el 100% de código asociado con requerimientos funcionales ha

sido escrito.

o Asegurar que las funciones nuevas y las modificaciones sobre las funciones

existentes son factibles a nivel operativo.

o Asegurar que las funciones no incluidas en el impacto no hayan sido

modificadas (también por cuestiones de auditoría)

Actividades:

o Validación de “super” usuarios.

o Pruebas de “no impacto”.

o Estudiar hallazgos y planear cuales son “posibles” para la iteración y cuales cambios en última instancia no son implementables.

Fase [X.0.b.1] a [X.0.b]

Objetivo:

o Obtener una versión instalable que contenga el 100% del código escrito.

o Obtener procedimientos y herramientas de instalación de versión definitiva.

Actividades:

o Validación de usuarios referentes.



Página 9 de 11

Pablo Michelis

o Pruebas de aceptación.

o Construcción de plan detallado de instalación (plan de corte).

Fase [X.0.b] a [X.0]

Objetivo:

o Ajustar últimos detalles sobre los hallazgos de las pruebas de aceptación.

Actividades:

o Revisiones de línea de base (integridad de línea de base).

o Revisiones de plan de instalación.

o Pruebas de instalación.

Gestión del Backlog

Los grandes pasos para el proceso son:

1) Agrupar requerimientos más prioritarios de acuerdo a necesidades de cambio sobre los

productos de software componiendo change sets (micro organización de cambios).

2) Analizar impacto de cambios y estimar costo.

3) Decidir en qué relase es factible realizar los cambios. Negociar costos estimados y

cronograma propuesto con Solicitantes.

4) Ajustar cronograma de acuerdo a negociación. Posible reducción de change sets de

acuerdo a nuevas prioridades.

5) Organizar cronograma de actividades de desarrollo para ventana de tiempo del relase.

Ejercicio 9)

Change Request Management & Backlog Management

(1) Requerimientos negociados para siguiente release pueden verse afectados por

actividades no planeadas.

(2) Prioridades ya establecidas se ven afectadas por requerimientos nuevos.

Release Management

(3) Actividades de cambio y control se afectan debido a artefactos “cerrados” que deben ser reabiertos.

(4) Los niveles de estabilidad relacionados con el cronograma anterior se pierden debido a

que los nuevos cambios podrían “caer” en cualquiera de las etapas ya descritas.

Ejercicio 10)

Estrategia ante un incidente o requerimiento de emergencia:

(1) Establecer nuevo dead Branch indicando como Segundo dígito el numero de

incidente atendido para el release en producción (incidente y).

(2) Caracterizar escenario de emergencia (X.y.1)



Página 10 de 11

Pablo Michelis

(3) Merge de otras líneas cerradas de emergencia (X.y.2)

(4) Codificar cambios necesarios y probar (X.y.3)

(5) Realizar prueba de regresión e identificar hallazgos (X.y.3).

(6) Fix (X.y)

(7) Liberación.

(8) Registrar nuevo requerimiento para que sea atendido este requerimiento en

próximos releases.

Ejercicio 11)

La ventana mínima es de 1 semana.

Ejercicio 12)

Me veo en la necesidad de crear un nuevo branch que no será un dead branch, sino

que será en algún momento incorporado a la línea de base principal (main branch).

Para esto, debo gestionar actividades de integración (merge) ante cada release

intermedio. De este modo no se perderán los change set implementados en los releases

comprendidos entre el momento que hice el check-out y el momento que complete el

change set “in the large”.

La siguiente figura muestra un ejemplo donde tengo un release del main branch y otro

de un dead branch por una reparación de emergencia:

03/04/2006 05/06/2006

07/04/2006

R 2.0

05/05/2006

R 3.0

02/06/2006

R 3.0

04/04/2006

3.0.a.1

Conjunto de

Requerimientos Cerrado

04/05/2006

merge cambios

entre 2.0.b y 3.0

04/04/2006 - 02/06/2006

Implementación de Change Set 3.0.a

21/04/2006

R 2.1

(Fix 1)

19/04/2006

merge cambios

entre 2.1.3 y 3.0


Página 11 de 11

Pablo Michelis

Referencia Bibliográfica

SCM

[1] Katherine Harvey - “Summary of the SEI Workshop on SCM”, “Tech. Report

CMU/SEI-86-TR-5. Diciembre 1986.”.

[2] B. White & G. Clemms - “Software Configuration Management and Rational

ClearCase”, Addison Wesley, 2000. Capítulos 1 y 2.

[3] T. Leishman y D. Cook - “But I Only Changed One Line of Code!”,

CROSSTALK The Journal of Defense Software Engineering. Enero 2003.

5 dimensiones

[4] K. Wiegers – “Creating a Software Engineering Culture”, “Cap. 2: Standing on

Principle”.

Plan detallado

[5] Steve McConell – “Rapid Development”, "Cap 7 - Life Cycle Planning"

Practicas de plan

Documents

Transcript of Practicas de plan