Ingeniería de Software II

Transcripción

1 Ingeniería de Software II Gestión de Configuración de Software: 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. Estatécnicaesvistaenunadelasprimerasclaseslamada 5dimensiones [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 dictanenlaclasede PlanDetalado [5]. Gestión de Configuración La misión de la Gestión de Configuración de Software (SCM 1 ) 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 encuentrendisponibles,laestrategiade releasing y baselining tienegranimportanciaen 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 1 de 11

2 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 Quality Control Manager Software Product Manager SCM Librarian Internal QA Software Tester 1 Software Tester 2 Software Developer 1 Software Architect Software Designer Software Analyst 1 Software Analyst 2 Software Developer 2 Software Developer 3 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 2 de 11

3 Ilustración 2: Proceso de Desarrollo Página 3 de 11

4 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 4 de 11

5 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? Página 5 de 11

6 Resolución de Práctica 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,esposibleplanearluego haciatrás (backwardplaning)lasfechasdetodas 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 equipodetrabajoylastareasasociadasehará basadaenactividades (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. Unaposiblenumeraciónquerespetestepatróndecronograma,siendo x elnúmerode 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 6 de 11

7 Resolución de Práctica... y el cronograma prototipo de cada etapa el siguiente: 06/2/8 Requerimientos Especificados X.0.a.2 06/2/3 (X-1).0 06/2/13 Diseño Detallado X.0.a.3 06/2/20 Alfa (Código Completo) X.0.a 06/2/23 Alfa Validada X.0.b.1 06/2/28 Beta (Candidato a Release) X.0.b 06/3/3 Release X.0 06/1/30 Conjunto de Requerimientos Cerrado X.0.a.1 Ene 06 Mar 06 y la estabilidad necesaria entre líneas de base la siguiente: Inicial: Carga del backlog o Estabilizar el conjunto de requerimientos de cambio que serán incluidos en la siguiente iteración. 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] 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. 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] o Controlar riesgos altos asociados al impacto estudiado en fase anterior. Página 7 de 11

8 Resolución de Práctica o Asegurar que la fase siguiente esté definida a nivel actividades y asignaciones realizables. 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] o Realizar las modificaciones especificadas sobre los productos de software. 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] 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) o Validaciónde super usuarios. o Pruebasde noimpacto. o Estudiarhalazgosyplanearcualeson posibles paralaiteraciónycuales cambios en última instancia no son implementables. Fase [X.0.b.1] a [X.0.b] 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. o Validación de usuarios referentes. Página 8 de 11

9 Resolución de Práctica o Pruebas de aceptación. o Construcción de plan detallado de instalación (plan de corte). Fase [X.0.b] a [X.0] o Ajustar últimos detalles sobre los hallazgos de las pruebas de aceptación. 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) Actividadesdecambioycontrolseafectandebidoartefactos cerados quedeben ser reabiertos. (4) Los niveles de estabilidad relacionados con el cronograma anterior se pierden debido a quelosnuevoscambiospodrían caer encualquieradelasetapasyadescritas. 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 9 de 11

10 Resolución de Práctica Ejercicio 11) Ejercicio 12) (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. La ventana mínima es de 1 semana. 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 changeset inthelarge. 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: 19/04/2006 merge cambios entre y /05/2006 merge cambios entre 2.0.b y /04/ /06/2006 Implementación de Change Set 3.0.a 02/06/2006 R /04/ /06/ /04/2006 R /04/2006 R /05/2006 R 3.0 (Fix 1) 04/04/ a.1 Conjunto de Requerimientos Cerrado Página 10 de 11

11 Referencia Bibliográfica SCM [1] Katherine Harvey - SumaryoftheSEIWorkshoponSCM, Tech.Report CMU/SEI-86-TR-5. Diciembre [2] B. White & G. Clemms - Software Configuration Management and Rational ClearCase,Addison Wesley, 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 dimensiones [4] K. Wiegers Creating a Software Engineering Culture, Cap. 2: Standing on Principle. Plan detallado [5] Steve McConell RapidDevelopment,"Cap 7 - Life Cycle Planning" Página 11 de 11