Análisis de la gestión de configuración de software aplicada al modelo de espiral

Transcripción

1 Análisis de la gestión de configuración de software aplicada al modelo de espiral Abstract No hay nada permanente, excepto el cambio Heráclito ( A.C.)- Grecia Fernandez, Sebastian Osso, Mariano UNLaM Universidad Nacional de La Matanza - Pcia. Bs. As. - Argentina Srfernandez@dsmsoft.com.ar Mosso@dsmsoft.com.ar 2010 El presente artículo describe el proceso de gestión de configuración del software (GCS) para procesos que adopten el ciclo de vida en espiral con el propósito de visualizar rápidamente cómo una adecuada gestión de configuración puede complementar de la mejor manera posible este modelo de ciclo de vida en particular. El mismo esta compuesto por una introducción teórica para comprender tanto el modelo en espiral como la gestión de configuración. Finalmente se expone una gestión de configuración adecuada brindando una solución práctica para este modelo. Palabras clave: análisis, gestión de configuración, ciclo de vida, modelo espiral. 1. Introducción Durante el transcurso del presente artículo haremos un análisis de cómo aplicar de una forma adecuada la gestión de configuración del software (GCS) al modelo de proceso espiral. Si bien ambos conceptos estan claramente definidos por varios autores, no existe tan claramente una técnica o metodología de cómo combinar ambos conceptos. Debido a esto se analizara dicha situación en el presente artículo. Se definirá como se implementaran las líneas base, como se seleccionaran los ECS para cada una de las líneas base y como se aplicara una gestión de cambios de forma práctica para este ciclo de vida. En la sección 2 se introducirán los temas de gestión de configuración y modelo de espiral. Luego en la sección 3 se definirá un método adecuado de cómo aplicar la GCS al modelo de espiral. Finalmente en la sección 4 se presenta la conclusión del articulo y en las secciones 5 y 6 las citas y bibliográficas consultadas. Pagina 1

2 2. Marco Teórico 2.1. La gestión de configuración del software (GCS) En el desarrollo de software los cambios, debidos principalmente a modificaciones de requisitos y fallos, son inevitables. Además en la gran mayoría de los casos los cambios al software estan debidamente justificados. Normalmente se trabaja en equipo por lo que es preciso llevar un control y registro de los cambios con el fin de reducir errores, aumentar la calidad y evitar los problemas que pueda acarrear una incorrecta sincronización en dichos cambios, al afectar a otros elementos del sistema o a las tareas realizadas por otros miembros del equipo de proyecto. Según Babich, el arte de coordinar el desarrollo de software para minimizar la confusión se denomina Gestión de Configuración. Es el arte de identificar, organizar, y controlar las modificaciones que sufre el software que construye un equipo de programación. El objetivo es maximizar la productividad minimizando los errores. [1] Según el Standard de la IEEE [2] la GCS cuenta con cuatro tareas fundamentales: la Identificación de la configuración, tarea en la cual debe obtenerse la información y los futuros productos que el proceso generará, denominados Elementos de configuración del software (ECS); el Control de los cambios, la cual especificará como los distintos ECS serán gestionados durante su evolución; la Generación de Informes de Estado, para comunicar el estado del proyecto; y la Auditoría de la Configuración, con la cual se validara que se cumplan con los objetivos deseados. Con Gestión, nos referiremos al control de la evolución y los cambios de la configuración del software. Y con Configuración del Software nos referiremos al conjunto de toda la información utilizada, y todos los productos generados por un proyecto. A ésta información y productos los llamaremos Elementos de Configuración del Software (ECS), y serán nuestra unidad de trabajo durante el proceso. Si cada elemento de configuración simplemente condujera a otros elementos habría poca confusión. Por desgracia, otra variable entra en el proceso: el cambio. Este puede ocurrir en cualquier momento, por cualquier razon [3]. De hecho, la primera ley de la ingeniería de sistemas [4] afirma: no importa donde se encuentre en el ciclo de vida del sistema, el sistema cambiara y el deseo de cambiarlo persistirá a lo largo de todo el ciclo de vida El modelo espiral El modelo en espiral del proceso del software (Figura 1) fue originalmente propuesto por Boehm [5]. Más que representar el proceso del software como una secuencia de actividades con retrospectiva de una actividad a otra, se representa como una espiral. Cada ciclo en la espiral representa una fase del proceso del software. Así, el ciclo más interno podría referirse a la viabilidad del sistema, el siguiente ciclo a la definición de requerimientos, el siguiente ciclo al diseño del sistema, y así sucesivamente. Pagina 2

3 Como puede verse en la Figura 1, el avance angular representa el progreso del desarrollo, en tanto que el desplazamiento radial desde el centro hacia fuera indica el incremento de los costos de desarrollo en forma acumulativa. Cada ciclo de la espiral se divide en cuatro sectores [6]: 1. Definición de objetivos: Para esta fase del proyecto, se definen los objetivos específicos. Se identifican las restricciones del proceso y el producto, y se traza un plan detallado de gestión. Se identifican los riesgos del proyecto. Dependiendo de estos riesgos, se planifican estrategias alternativas. 2. Evaluación y reducción de riesgos: Se lleva a cabo un análisis detallado para cada uno de los riesgos identificados del proyecto. Se definen los pasos para reducir dichos riesgos. Por ejemplo, si existe el riesgo de tener requerimientos inapropiados, se puede desarrollar un prototipo del sistema. 3. Desarrollo y validación: Después de la evaluación de riesgos, se elige un modelo para el desarrollo del sistema. Entre los modelos a elegir, se encuentran el prototipado evolutivo, en modelo en cascada, etc. 4. Planificación: El proyecto se revisa y se toma la decisión de si se debe continuar con el próximo ciclo del espiral. Si se decide continuar, se debe planificar la siguiente fase del proyecto. Una diferencia importante entre el modelo en espiral y los otros modelos del proceso software, es que éste considera de una forma explícita el riesgo. En el modelo en espiral, no existen fase fijas como la especificación o el diseño. Este modelo puede contener otros modelos. Por ejemplo, la construcción de un prototipo se utiliza para resolver las dudas en los requerimientos y así reducir el riesgo. Figura 1. Modelo en espiral Pagina 3

4 3. Como aplicar la GCS al modelo espiral 3.1. Como disponer las líneas base El primer paso para poder efectuar la actividad de identificación de la configuración consistió en definir cuáles iban a ser los hitos, dentro del proceso de desarrollo. Algunos de esos hitos, los más relevantes para el proyecto, se transformaran en líneas base y el hito previamente establecido formara parte de la línea base ya sea como un ECS o como parte del mismo. La primer línea base, se fija una vez terminado el sector de gestión de riesgos de la tercera Fase. Este será el punto de partida de todo el resto del proceso, por lo tanto cualquier revisión a las dos primeras fases, deberá ser solicitada y aprobada o rechazada mediante un procedimiento formal de solicitud de cambios. Cabe destacar que, dado el foco puesto en el análisis de riesgo realizado en las dos primeras fases, y las validaciones consensuadas con el cliente o usuario, debería estar minimizada o fuertemente acotada la posibilidad de cambios en la especificación de requisitos, sumando otro motivo al establecimiento de la línea base en este punto. La segunda línea base se propone fijarla una vez aceptados los documentos de diseño, durante la cuarta fase. Dichos documentos se modificarán permanentemente durante la iteración, pero dado que condicionan la arquitectura del sistema y el desarrollo posterior, creemos necesario darle cierta formalidad a cualquier modificación propuesta sobre ellos. Por último, la tercera línea base se constituye una vez validado con el cliente el producto software. La importancia de esta línea base es servir de punto de partida para futuras entregas, versiones del producto para otras plataformas, manuales, comercialización del mismo en sus diferentes maneras. También consideramos que un número excesivo de líneas base resulta contraproducente para el proyecto, dado que cada una de ellas implica un costo de mantenimiento importante. El hecho de que cada una de ellas, para ser modificada, requiera un procedimiento formal, puede derivar en pérdida de flexibilidad del proyecto ante las solicitudes de cambios del cliente, volviéndose demasiado rígido. Decidimos incluir entre la segunda y tercera línea base dos hitos intermedios, es decir, dos puntos de control semiformales inmediatamente después del diseño detallado. La idea es permitir cambios de forma ágil al código desarrollado en base a las pruebas de integración y aceptación, sin la necesidad de pasar por el comité de control de cambios. Estos cambios lógicamente no conllevan modificaciones funcionales del proyecto, sino que tienen relación con mejoras del tipo performance o estéticas. Pagina 4

5 Hitos Lineas Base H1: Informe de viabilidad. H2: aprobación de los requisitos por parte del cliente. H3: Finalización de desarrollo. H4: Resultados de pruebas unitarias e integradoras. LB1: Línea base funcional (requisitos) LB2: Línea base de desarrollo (diseño preliminar y detallado) LB3: Línea base de producto (implementación) Figura 2. Lineas base aplicadas al modelo espiral Línea Base Hito 3.2. Selección de los ECS A continuación se listaran los elementos de configuración de software (ECS) que se consideraron adecuados para este modelo de ciclo de vida. Definimos que la cantidad de elementos no debe ser muy elevado (14) ya que el modelo por si mismo tiene un alto hincapié en el análisis, al agregarle más documentación asociada seria poco práctico y generaría un proceso demasiado burocrático. Además mantener muchos Pagina 5

6 elementos de configuración es costoso y podría llegar a ser inmanejable a nivel administrativo. Por otra parte seleccionamos los ECS necesarios para no perder visibilidad sobre el producto. 1. Línea base funcional - LB1: a. Plan de desarrollo de software b. Especificación de requisitos c. Descripción de interfaces (con usuarios y con otros sistemas, si fuera necesario) d. Matriz de riesgos de requisitos 2. Línea base de desarrollo - LB2: a. Diagrama de contexto (restricciones - limites del sistema) b. Documentos de diseño preliminar (modelo lógico de datos, diseño de las interfaces) c. Documentos de diseño detallado (diseño de la arquitectura, diseño detallado de los subsistemas, diagrama entidad relación, modelo de componentes) d. Planificación del desarrollo. e. Matriz de riesgos de diseño 3. Línea base de producto - LB3: a. Planificación de las pruebas unitarias e integradoras. b. Codigo fuente c. Manual de usuario e instalación. d. Documento de herramientas case utilizado en el desarrollo (compiladores, bibliotecas, componentes, entornos de programación, etc.) e. Matriz de riesgos de implementación 3.3. Como implementar una configuración adecuada Las actividades que se realizaran durante esta etapa tienen como principal objetivo establecer y mantener la integridad de los productos generados durante el proyecto de desarrollo de software y a lo largo de todo el ciclo de vida del producto así como también evaluar y controlar los cambios sobre ellos Identificar los ECS Consiste en identificar inequívocamente a cada uno de los ECS así como también hacer referencia al proyecto, la versión, la fase del ciclo de vida a la cual se corresponde. Tomando en cuenta esto decidimos que una forma adecuada de hacer la identificación es como se muestra en la figura 3 Pagina 6

7 Figura 3. Identificación de los ECS Definición de las bibliotecas En la presente propuesta creímos conveniente la utilización de las siguientes bibliotecas de software: Gestión de cambios Biblioteca de trabajo: Esta es el área de trabajo local para desarrollo donde se realiza la codificación y pruebas unitarias, por ende aquí los cambios son informales y no requieren ningún tipo de aprobación formal. Biblioteca de soporte al proyecto: Aquí se almacenaran los ECS aprobados y transferidos desde cada una de las bibliotecas de trabajo. Los cambios en este repositorio serán semiformales. Biblioteca Maestra: Este es el repositorio que almacenara las distintas versiones releases de los ECS. Los elementos de esta biblioteca se encuentran sujetos a un control de cambios formal y estricto. Biblioteca de backups: el contenido de esta biblioteca no esta sujeto a la gestión de configuración, por lo que no estan permitidos los cambios en este repositorio. En la presente propuesta el mecanismo sugerido para realizar el control de cambios, es el siguiente: 1. El nivel de cambios informal se aplicará de acuerdo a lo establecido en la Gestión de Configuración tradicional. Dichas modificaciones se gestionarán de la forma habitual, mediante herramientas de registración de incidentes y versionado de software, no requiriendo evaluaciones ni aprobaciones formales. Pagina 7

8 Este tipo de cambios se realizaran sobre los ECS que aun no formen parte de una línea base preestablecida, por ejemplo el codigo fuente antes de que forme parte de la línea base de producto. 2. El nivel de cambios semiformal, representado en nuestro esquema por los hitos mencionados en el apartado anterior, implicará una registración de las solicitudes en un documento específico, debiendo ser las mismas evaluadas y eventualmente aprobadas por el Project leader Los cambios semi-formales se efectuaran sobre los ECS que ya pasaron por una revisión técnica formal y forman parte de una línea base. 3. Para la aplicación del control de cambios formal deberá utilizarse el siguiente proceso: Se presenta una Solicitud de Cambio ante el Comité de Control de Cambios. La misma debe contener obligatoriamente el motivo del cambio, que es lo que debe cambiarse, quien lo solicita y una descripción clara del problema. Un integrante del Comité de Control de Cambios decide si se acepta o rechaza la solicitud. En caso de ser aceptada, se procede a evaluar su impacto, esfuerzo estimado, costo, y se emite un Informe de Cambios. Se presenta el Informe al Comité de Control de Cambios. Si es aceptado se genera una Orden de Cambio, la cual describe el cambio a realizar, las restricciones que deben respetarse, y los criterios de revisión y auditoría. Se realiza el cambio, para ello se toma la última versión del/los elemento/s de configuración involucrados, es decir, la de la línea base correspondiente y se generan nuevas versiones de los mismos. Una vez finalizado el cambio, se certifica que el mismo haya sido efectuado correctamente de acuerdo a las normas y estándares establecidos, pasando el mismo a integrar la línea base correspondiente. Los cambios formales se aplican sobre los ECS que forman parte de la Biblioteca Maestra El Comité de Control de Cambios estará formado por personas pertenecientes a todas la partes interesadas en el desarrollo del proyecto. En proyectos pequeños el CCC está integrado por el Software Architect y/o el Project Manager junto con un Representante del Cliente. En proyectos grandes, el número de integrantes suele elevarse, incluyendo a responsables de QA, Project Leaders, Analistas de Riesgo, Implementadores Informes de estado Pagina 8

9 4. Conclusión El objetivo de la generación de informes de estado es mantener a los gestores y a los desarrolladores al tanto de los cambios más importantes que se produzcan en el software. La generación de los informes depende de la organización, así como su periodicidad y nivel de detalle. Los productos de esta actividad son los registros e informes. Los mínimos exigidos por el presente enfoque serán los siguientes: Registro de solicitudes de cambio (Documento de Solicitud de Cambios): el mismo servirá como base para la posterior generación de informes. Incluirá, al menos, la siguiente información, quedando librado a criterio de la organización el resguardo de contenido extra: 1. Código de la Solicitud de Cambio 2. Título 3. Descripción del problema 4. Descripción breve de la solución 5. Impactos previstos Informe de estado de los cambios: resumen del estado en que se encuentran todas las solicitudes de cambio registradas durante un determinado período de tiempo. El mismo se generará a pedido del cliente, o del Project manager en el momento que se desee. No tiene previsto una frecuencia predefinida. Inventario de elementos de configuración: su objetivo es ofrecer visibilidad sobre el contenido de los ECS, permitiendo ver en que versión se encuentran actualmente, fecha de última modificación, usuario responsable, etc. El presente documento muestra una forma adecuada de aplicar la gestión de configuración del software a un modelo en espiral explotando las características de dicho modelo y haciendo hincapié en sus fortalezas. Se definieron los elementos de configuración mas adecuados para este modelo y se aplico la configuración de forma tal que se complemente correctamente el proceso siguiendo este modelo. Pagina 9

10 5. Referencias Bibliográficas [1] Babich W.A., Software Configuration Management, Addison Wesley, 1986 [2] ANSI/IEEE IEEE Guide to Software Configuration Management - [3] Pressman, Roger S, Ingeniería del software. Un enfoque practico - Sexta Edición, McGraw - Hill, 2006 [4] Bersoff, E.H., V.D. Henderson y S.G. Siegel, Software configuration Managment, Prentice Hall, [5] Boehm, B.W., A Spiral Model of Software Development and Enhancement, IEEE Computer, Vol. 21, Nro. 5, Mayo 1988 [6] Sommerville Ian, Ingeniería del software Séptima Edición, Pearson Addison Wesley, Bibliografías consultadas Pressman, Roger S, Ingeniería del software. Un enfoque practico - Sexta Edición, McGraw - Hill, 2006 Sommerville Ian, Ingeniería del software Séptima Edición, Pearson Addison Wesley, 2004 Mon A., La gestión de configuración del software, Ingeniería de software - Universidad Nacional de la Matanza, 2009 Pagina 10