Una mejor organización para los procesos de Desarrollo de Software

Transcripción

1 Una mejor organización para los procesos de Desarrollo de Software Informe Final Ingeniería de Software Avanzada Dr. Marcello Visconti 22 de Junio de 2004 Angelo Cabrera M Carol Chamblas R

2 INTRODUCCION 3 PROGRAMACION EXTREMA 4 INTEGRACION CONTINUA 5 ELEMENTOS DE LA INTEGRACION CONTINUA 6 INTEGRACION CONTINUA Y PRODUCTIVIDAD 7 INTEGRACION CONTINUA Y CALIDAD 8 ENTREGAS PEQUEÑAS 10 ENTREGAS PEQUEÑAS Y PRODUCTIVIDAD 10 ENTREGAS PEQUEÑAS Y CALIDAD 11 APLICACION DE PRACTICAS ANALIZADAS 12 CONCLUSIONES 14 REFERENCIAS 15

3 INTRODUCCION El desarrollo de software incluye no sólo la creación y prueba de código fuente, si no que engloba un sinnúmero de factores, cada uno con una importancia distinta, pero que en definitiva, afectan al resultado final. Es por esto que al desarrollar software, es necesario contemplar éstos factores, lo que de no ser así, podría provocar un resultado desastroso. Uno de los principales problemas detectados en el desarrollo de software, se centra en clientes y usuarios y la comunicación con los desarrolladores, donde se aprecia que muchas veces no están bien definidos los requerimientos necesarios. Además, y debido muchas veces a pobres desarrollos, clientes y usuarios paulatinamente comienzan a perder el interés en el software solicitado. Como consecuencia de esto, muchas veces el desarrollo no es terminado. Otro de los problemas presentados frecuentemente se concentra en la dificultad que presenta un sistema al momento de reunir sus funcionalidades en un todo, pues es común que, al incluir nuevo código a una versión, éste no sea compatible con el ya existente, provocando errores difíciles de solucionar e incitando una pérdida de tiempo importante. Debido a éstos y muchos otros problemas detectados, han sido creadas diversas metodologías de desarrollo, dentro de las cuales las llamadas ágiles representan las tendencias actuales, centrándose principalmente en la obtención de un producto final a tiempo, de calidad y apegado a los requerimientos planteados. Programación Extrema (XP, según su sigla del inglés Extreme Programming) es la metodología ágil de mayor uso en la actualidad, la que provee ciertas prácticas a seguir, sin delimitar demasiado el desarrollo a una planificación, como en el caso de las metodologías tradicionales. Integración continua y pequeñas entregas, son dos de las doce prácticas establecidas en XP, las cuales se enfocan principalmente en factores relacionados con la obtención de frecuentes versiones estables del sistema desarrollado, evitando problemas como por ejemplo, la dificultad de sincronización de un equipo grande (o no presencial) de desarrollo, los problemas inherentes a muchas funcionalidades reunidas bajo un mismo sistema, clientes indecisos o desinteresados, además de prevenir la tardía detección de errores, garantizando su total resolución. Es cierto que, para obtener resultados óptimos es recomendado acatar todas las normas establecidas por una metodología de desarrollo, en el caso de XP, principalmente por sus doce prácticas claramente diferenciadas (aunque no desvinculadas), es posible adoptar sólo algunas de éstas, logrando excelentes resultados. Un factor importante en la amplia difusión y uso de XP, es que esta metodología fue esencialmente creada y diseñada por desarrolladores, por lo que se consideraron y resolvieron problemas reales y no teóricos.

4 PROGRAMACION EXTREMA Esta metodología corresponde a la más utilizada en la actualidad de las llamadas ágiles ó livianas, las cuales se enfocan en las personas (miembros de equipos desarrolladores) y los resultados. Aunque estas metodologías no son restrictivas como las tradicionales, si realzan la importancia de mantener una cierta disciplina durante el proceso, pues en caso contrario, es muy difícil asegurar la obtención de buenos resultados. Dentro de las libertades que se permiten, se puede señalar la posibilidad de dilatar la toma de decisiones, disponiendo de todos los antecedentes relevantes para esto, lo que se observa claramente en la participación del cliente durante el desarrollo, pues éste muchas veces cambia de parecer, o no tiene realmente claros sus requerimientos al plantear la necesidad de un software. Son tres los tópicos que se consideran dentro de ésta metodología. Estos son: Control empírico del proceso: evaluar cómo se están desarrollando en la práctica los procesos planificados. Comportamiento adaptativo: adecuar la planificación a la situación real, considerando desde cambios de fechas, y formas de realizar procesos, hasta incluir, o excluir funcionalidades al software. Auto-organización: Considerar como válidos los aportes y sugerencias efectuados por todos los miembros del equipo de desarrollo, eludiendo formalismos extremos y compartiendo experiencias aplicadas a la situación real. XP propone doce prácticas, las cuales se clasifican en cuatro categorías: Proceso continuo o Integración continua. o Pequeñas entregas. o Refactorización. Retroalimentación o Desarrollo guiado por pruebas. o Programación por parejas. o Taller de Planificación. o Cliente presente. Comunicación o Diseño simple. o Estándares de codificación. o Propiedad colectiva del código. o Metáfora del sistema. Bienestar o Semana de cuarenta Horas. En las secciones siguientes, se analizarán dos de estas prácticas, ambas pertenecientes a la categoría de proceso continuo: integración continua y pequeñas entregas.

5 INTEGRACION CONTINUA Un factor importante que determina el éxito de un sistema de software es la velocidad con la que el sistema se adapta a los requerimientos. Otro factor a considerar es la velocidad a la cual un sistema puede proveer una nueva funcionalidad. Además, es importante para la calidad de un sistema obtener una respuesta lo más temprana posible sobre la estabilidad y el valor que el cliente le da al sistema. La programación extrema dirige éstas y otras preguntas hacia integración continua, la cual forma parte de las 12 Prácticas de XP. Este término describe la integración inmediata y recurrente de tareas completas dentro del sistema. Una tarea terminada, de manera general, consiste tanto en nuevas unidades de pruebas y funcionalidades, como en modificaciones del código fuente. La funcionalidad del sistema se divide en piezas pequeñas (tareas), las cuales, a medida que son terminadas y probadas, deben ser agregadas al núcleo activo del sistema. Típicamente esto se hace de tal manera que los programadores trabajen al mismo tiempo en diferentes tareas. Cuando una tarea ha concluido, se ingresan las modificaciones del código dentro de una máquina encargada de la integración. Estos cambios, que incluirán las unidades de prueba asociadas a ellos y estarán inmediatamente disponibles a los otros programadores. Como esta integración ocurre varias veces en un corto período de tiempo (varias veces en un día, por ejemplo), se conduce a la integración casi inmediata de las modificaciones del código fuente o nuevos módulos. Cada versión del sistema que se hace disponible al equipo debe haber completado satisfactoriamente todos los tests de aceptación, como también debe haber implementado exitosamente los tests de unidad. Dicho de otra manera, una versión estable del sistema se encuentra disponible inmediatamente. Debido a los cortos tiempos entre integraciones es que se ha elegido el nombre integración continua para esta metodología. Esto contrasta con muchos de los procesos tradicionales, donde la integración es mucho menos frecuente, con lo que puede ser muy difícil obtener un sistema estable al realizar los cambios. Los puntos importantes a considerar son: Realizar la integración una o más veces durante el día. Mantención de un repositorio de datos, desde donde fácilmente sea posible obtener una copia completa, tanto de código fuente, como de los conjuntos de pruebas y las versiones anteriores del sistema. Automatizar el proceso de construcción del sistema, de manera que con sólo un comando éste se compile desde el código fuente. Automatizar el proceso de pruebas. Asegurar que en cualquier momento es posible obtener una versión estable del sistema.

6 Una tarea se integrará si y sólo si ésta a satisfecho un conjunto de pruebas correspondientes, tanto de unidad, como de aceptación del sistema completo. ELEMENTOS DE LA INTEGRACION CONTINUA Los elementos que componen la práctica Integración Continua, pueden clasificarse como se presenta a continuación. Lo mejor es más frecuente Si se integra sólo ocasionalmente, el proceso de integración puede ser un ejercicio complicado. Entonces surge la idea de que hacerlo más frecuente es mucho más trabajo. Sin embargo, incluso en proyectos grandes, es posible realizar varias integraciones en un mismo día. Esto se debe a que el esfuerzo de integración es exponencialmente proporcional a la cantidad de tiempo entre cada una de las integraciones, es decir, integrar una vez a la semana es equivalente a integrar una vez al día, pero 25 veces. Construcción exitosa Una construcción exitosa debe incluir los siguientes elementos: Los últimos códigos fuentes fueron revisados por el sistema de administración de configuración. Todos los archivos fueron compilados desde cero. Los archivos resultantes son enlazados y bien ubicados para su ejecución. Se enciende el sistema, y un conjunto de pruebas deben corren sobre él. Si todos los pasos anteriores se ejecutaron sin ningún error o intervención humana y todas las pruebas fueron aprobadas, entonces se tiene una construcción exitosa. Un solo repositorio de código fuente Para que el proceso de integración se realice más fácilmente, cada desarrollador debe poder acceder al código fuente completo, de tal forma que, en una máquina limpia (nueva dentro del proceso de construcción del sistema), se pueda conectar a la red, descargar todos los archivos y, con un simple comando obtener todo el código. La solución para este planteamiento es mantener un sistema de administración de configuración que controle todos los cambios y versiones del código fuente. Scripts de automatización de construcciones Los scripts de automatización permiten ahorrar gran cantidad de tiempo a los desarrolladores, realizando los pasos de construcción de un entregable automáticamente. Además, reduce el tiempo de construcción compilando solamente el código que ha sido modificado. Otra característica que poseen los scripts de automatización es que permiten obtener diferentes tipos de construcciones basándose en el mismo código

7 fuente. Así, puede obtenerse una construcción con varios conjuntos de pruebas, sin pruebas de ningún tipo, o construcciones que apunten a variados objetivos. Código de autoprueba Pese a que los compiladores pueden detectar muchos problemas de codificación, existen muchos otros que consiguen pasar inadvertidos. Es por ello que la disciplina de automatización de pruebas es tan importante. XP divide las pruebas en dos grupos: pruebas de unidad y pruebas de aceptación. Las primeras son diseñadas por los desarrolladores y prueban clases individuales o un pequeño conjunto de clases. Las pruebas de aceptación en cambio, son utilizadas para probar el sistema completo. El principio básico del código de autoprueba es que los desarrolladores escriban, al momento de terminar una fracción de código, las pruebas necesarias para éste. Incluso, se utiliza un método en el cual se escribe primero la prueba y luego la funcionalidad que se desea implementar. De esta forma, cada vez que se compila se ejecuta el código de testing, el cual permite detectar inmediatamente una falla producida en la codificación. La construcción maestra La construcción maestra consiste en la construcción automática disponible para todo el equipo de desarrollo. Este proceso que involucra el trabajo de todo el equipo de desarrollo permite detectar los problemas de integración tempranamente. Para realizar la construcción maestra generalmente se tiene una máquina dedicada exclusivamente a ello. Esta máquina corre el proceso de construcción continuamente, encontrándose en estado de espera entre una y otra. Cuando encuentra cambios en el código, realiza la nueva construcción y luego informa a todos los desarrolladores el estado de ésta. Revisión Es importante que los desarrolladores integren regularmente. pueden seguir algunos pasos: Para ello se Sincronizar con el sistema administrador de configuración. Actualizar los archivos que requieran cambios. Resincronizar los archivos modificados con el repositorio central. Ejecutar las pruebas necesarias sobre los archivos actualizados. Subir los nuevos archivos al repositorio. Es recomendable para cada desarrollador realizar una revisión completa al menos una vez al día, para evitar conflictos de sincronización y actualización de archivos que se encuentren fuera de la fecha de trabajo. INTEGRACION CONTINUA Y PRODUCTIVIDAD Los métodos ágiles se basan en procesos muy disciplinados. De hecho, muchas de estas prácticas están lo suficientemente definidas como para ser incorporadas precisamente en las herramientas de desarrollo. Marcos de

8 pruebas de unidad, herramientas de integración continua, y ambientes de refrabicación de software comprenden un nuevo conjunto de herramientas de desarrollo que permiten crear un software de mayor calidad y rápidamente. Los estudios han demostrado una y otra vez que el impacto más grande en la productividad de software son las personas. Sorprendentemente, los métodos ágiles son el primer conjunto de prácticas de ingeniería de software que se basan en la manera en que las personas actualmente desarrollan software. Una integración continua ahorra tiempo total de integración, mientras que permite una mayor productividad a los programadores, y reduce el tiempo gastado en la detección y reparación de bugs de integración. Basándose en datos anecdóticos, se puede decir que la integración continua convierte el infierno de la integración prácticamente en un evento inexistente. Una de las claves de productividad es el aspecto de la automatización, debido a que el trabajo repetitivo realizado por desarrolladores es reemplazado por simples comandos, además de que es posible transformar complejos procesos en tareas de muy baja dificultad. En el caso de la integración continua la automatización es de gran importancia, al momento de implementar su operación. Esto radica en que sólo se deben dedicar tiempo y esfuerzos una sola vez, al momento de crear el proceso automatizado, y no cada vez que se requiere realizar estas tareas. Esto principalmente se ve reflejado en la actualización de código fuente, como también en la obtención de versiones, tanto nuevas como antiguas. INTEGRACION CONTINUA Y CALIDAD La integración continua produce un software de calidad, ya que ofrece a los desarrolladores la posibilidad de una respuesta inmediata prácticamente en cualquier momento, permitiendo a la vez realizar mejoras en el software. Siguiendo esta misma línea, no es poco común ver a un equipo de trabajo seguir un largo proceso de construcción e instalación de varios días en el sistema de pruebas, sólo para descubrir que el entregable no satisface ni siquiera la primera y más básica prueba. La integración continua atrapa estos problemas tempranamente y genera entregables mucho más confiables y predecibles. Cuando se implementan cambios en el software, los problemas de integración deben ser enfocados a algún punto determinado. Direccionar los problemas de integración de software en el momento en que se desarrolla, es mucho menos costoso y produce resultados de más alta calidad que al esperar que un entregable formal es creado y falla. La integración continua ayuda a establecer un pensamiento de equipo, donde si la construcción falla, es prioridad de todo el equipo repararla. Tradicionalmente, la construcción de entregables frecuentemente integra cambios de código por primera vez, causando problemas en la construcción que se dejan al responsable de ella lidiar con ellos. Muchas veces el ingeniero

9 constructor termina removiendo funcionalidades para obtener un desempeño adecuado. Incorporando las actividades de integración ya mencionadas en etapas tempranas del proceso, más características del software requerido se incluyen en la construcción final, mientras que el esfuerzo termina típicamente siendo un esfuerzo de equipo.

10 ENTREGAS PEQUEÑAS Un entregable puede ser definido como una versión del software desarrollado, la cual debe poseer un cierto nivel de estabilidad. La idea central de ésta práctica de XP, es la generación de versiones a medida que se añaden nuevas funcionalidades al sistema, mientras que el tiempo entre cada una puede variar desde un día, a dos semanas. Esta frecuencia es recomendada para que cada nuevo entregable inserte un pequeño número de funcionalidades con respecto a la versión inmediatamente anterior. Las ventajas que proporciona ésta práctica son muchas y muy diversas. La más fácilmente detectable es la de disponer inmediatamente de una versión estable que incluya todo el trabajo realizado hasta el momento. Otra ventaja que esta práctica entrega es la posibilidad de revisar en conjunto con el cliente del producto, las funcionalidades ya implementadas (si esto es exactamente lo que se requiere), y las que aún faltan por desarrollar. La importancia de esto radica en la baja complejidad que significa realizar un cambio, ya sea quitar o modificar funcionalidades. Lo anterior, implícitamente permite mantener una continua comunicación con el cliente, además de que éste observe cómo el software evoluciona, y su interés no disminuya, si no que al contrario aumente. También se transforma en una tarea más fácil lidiar con clientes indecisos, o que no tienen claras sus necesidades. Otra ventaja que proporciona esta práctica se refiere a la posibilidad de realizar pruebas sobre el sistema completo, pudiendo realizarlas no sólo desarrolladores, si no que también clientes, usuarios y otras personas externas al desarrollo, para así asegurar la calidad del producto. ENTREGAS PEQUEÑAS Y PRODUCTIVIDAD Las ventajas antes descritas proporcionan muchas instancias que aportan a la productividad del equipo de desarrollo. Como antes se mencionó, al contar frecuentemente con nuevas versiones, la modificación de funcionalidades no se convierte en una tarea complicada, situación que puede presentarse tanto por detección de errores, como por cambios en los requerimientos del sistema por parte del cliente, o simplemente por la decisión de realizar cambios en la forma de realizar los procesos mismos de las funcionalidades. Además, al ser frecuente la generación de nuevos entregables, esto se convierte en un proceso recurrente, sin requerir esfuerzos considerables como ocurriría al intentar integrar un alto número de funcionalidades, evitando una importante pérdida de tiempo por ésta razón. Junto a esto, se asegura que todas las funcionalidades son compatibles entre sí, evitando un gran número de errores y el esfuerzo requerido para resolverlos. Un punto importante de este enfoque, es que el re-trabajo (realizar más de una vez una misma tarea) se minimiza al máximo, con lo que se obtiene un buen rendimiento de los desarrolladores.

11 Debido a lo anterior, los miembros del equipo de desarrollo del proyecto utilizan mejor su tiempo, aumentando considerablemente su productividad y permitiendo la generación de un software en menor tiempo que el requerido al no adoptar esta práctica. ENTREGAS PEQUEÑAS Y CALIDAD La calidad de un software depende de varios factores, donde quizás el objetivo más importante es la ausencia de errores durante la ejecución del producto. El adoptar la práctica de realizar pequeñas versiones refuerza fuertemente el desarrollo de un software de calidad. El mantener constantemente versiones estables del sistema asegura la calidad de éste, debido a que cada funcionalidad añadida al generar un nuevo entregable debe ser probada por separado, y luego inmersa en el sistema completo, evitando la aparición de errores indetectados, como también errores de gran complejidad. Si se considerara la generación de pocos entregables, por ejemplo un prototipo inicial, un entregable en la mitad del desarrollo y uno final, la tarea de probar sólo cada escenario frecuente se convierte en interminable, a lo que deben sumarse la totalidad de escenarios posibles, la tarea se transforma en algo imposible, incluso en un software pequeño. Pero al construir versiones recurrentemente, y realizar las pruebas necesarias para aceptar dicha versión como estable, el proceso de pruebas se divide, disminuyendo considerablemente su complejidad, con lo que además, se asegura realizar las pruebas bajo muchos escenarios distintos. Debido a lo anterior, la generación de numerosos entregables, durante el proceso de desarrollo de software permite un control constante de fallas y errores, evitando largos períodos de reparación, lo que generalmente da lugar a nuevos y numerosos errores, los que muchas veces no son detectados a tiempo.

12 APLICACION DE PRACTICAS ANALIZADAS La integración continua es aplicable en diferentes ambientes de desarrollo. Sin embargo, pese a que los principios se mantienen invariables, la implementación de esta práctica puede variar considerablemente, debido a la influencia de varios aspectos, tales como el lenguaje, plataforma, tamaño y ubicación del equipo, entre otros. En este caso, se presentará la implementación en ambiente Windows/COM para un proyecto de desarrollo en Visual C++. Más frecuente es mejor Al desarrollar proyectos en C++, este elemento es de vital importancia, debido que si no se realizan integraciones frecuentes, el proceso de integración se torna muy complicado, debido especialmente al amplio uso de dependencias en este tipo de proyectos. Por esto, para poder implementar integración continua apropiadamente, es necesario implementar un administrador de dependencias. Construcción Exitosa En el caso de C++, una construcción exitosa está determinada por: La construcción de todos los binarios, La revisión de todos los archivos fuentes en el repositorio de código fuente, Todos los binarios deben haber sido compilados y enlazados de tal manera que estén listos para su carga, Los objetos COM deben estar registrados en el sistema operativo, La base de datos (en este caso SQL 2000) debe ser construida desde cero y poblada con datos de prueba, Todos los servicios externos deben estar listos, y Todas las pruebas de unidades deben haber sido aprobadas en un 100%. Si todos los pasos anteriores se completan sin errores o fallas, entonces se tiene una construcción exitosa. Un solo repositorio de código fuente Debido a que C++ utiliza una gran cantidad de librerías y binarios (conocidos como SDK, software development kit) para poder desarrollar aplicaciones, en vez de ubicar dichas librerías en el repositorio central, es mejor contar con ellas en cada máquina en que se desee realizar una construcción limpia. Así, un equipo básico está configurado de la siguiente manera: Microsoft Visual Studio Versión 6 Visual Studio Service Pack 4 Versión actual del Microsoft Platform SDK Versión actual del Microsoft XML Parser SDK Versión actual del Microsoft XML Parser.

13 Construcción del Código Para la construcción del código, se debieron tomar varias restricciones existentes: Los desarrolladores usaban MS DevStudio IDE para el desarrollo y la construcción. El desarrollo se realizaba usando el asistente ATL el cual generaba archivos de proyectos complejos, y plantillas de código (template) que después era utilizado en el IDE. Era necesaria una solución rápida. Estas restricciones llevaron a la decisión de utilizar scripts para MSDev, el cual permite crear el árbol de código fuente completo, y utilizar el IDE para configurar el proyecto y sus dependencias. Esto además permite que los desarrolladores continúen utilizando el IDE para la construcción del software. Finalmente, para manejar las dependencias se utilizó la herramienta CruiseControl, el cual es un marco de trabajo mucho más flexible y completo que los scripts mencionados anteriormente. Código de autoprueba Como marco de trabajo de pruebas de unidad, se escogió la herramienta CPPUnit, el cual está orientado específicamente para proyectos basados en C++. Construcción Automatizada Para la construcción automatizada se utilizaron las herramientas Ant y CruiseControl, las cuales permiten monitorear el repositorio de código, construir los componentes, construir la base de datos, probar el código, y comunicar el estado de la construcción a través de un Sitio Web y vía . Para manejar el repositorio de código, se utilizó la herramienta StarTeam, cuya API se integra perfectamente con DevStudio. Concluyendo, se puede decir que lo mejor que se puede hacer al momento de adoptar la técnica de integración continua, es utilizarla desde el inicio del proyecto. Puede que en un comienzo se requiera mucho trabajo para poner todo el sistema de automatización, pruebas, repositorio y configuración de máquinas en marcha, pero ese gasto es mucho menor comparado con el que se requiere para implementar esta práctica en la mitad de un proyecto. Las herramientas utilizadas, especialmente CruiseControl, permiten liberar gran parte del costo de implementación y utilización de la integración continua, ya que maneja adecuadamente los procesos de automatización y construcción de software. Finalmente, se puede decir que, dada la variedad de proyectos de software existentes, lo que se debe tener en cuenta al adoptar esta práctica (y cualquier otra práctica de XP) es mantener los principios de ella, para así poder obtener los máximos beneficios de su implementación.

14 CONCLUSIONES Debido a la gran cantidad de beneficios que las prácticas de XP proveen para el desarrollo de software, es altamente recomendable su utilización, contribuyendo en gran medida para mejorar la productividad del equipo de desarrollo y aumentar la calidad del producto final. Además, las metodologías ágiles permiten mayor libertad en la toma de decisiones, al contrario que las tradicionales. Dala la importante relación existente entre integración continua y entregas pequeñas, es altamente recomendable la adopción de ambas técnicas a la vez, ya que ambas permiten, en conjunto, mejorar en gran medida la productividad de desarrolladores, en el caso de integración continua, e involucrar al cliente y mejorar la calidad de software en el caso de entregas pequeñas. Sin embargo, son muchos los aspectos que estas dos prácticas no consideran dentro del proceso de desarrollo de software, por lo que es necesario realizar un análisis específico del proyecto a desarrollar, para intentar manejar los factores restantes. Finalmente, es importante destacar que, cada proyecto es distinto, por lo cual, se requieren métodos diferentes en cada caso, por lo que se recomienda realizar un análisis enfocado específicamente al desarrollo requerido.

15 REFERENCIAS CruiseControl: CPPUnit: