Cuando estamos desarrollando y dando mantenimiento a un producto de software, los cambios son inevitables, de hecho, son lo único que se mantiene constante dentro de un proyecto de desarrollo; ya sea porque el cliente necesita que se efectúen cambios, porque se cometieron errores, o simplemente porque el entorno en el que se desenvuelve el producto, evoluciona.La incorporación de esos cambios al software de forma descontrolada, frecuentemente provoca caos en los proyectos, retrasos en la entrega de los productos y problemas de calidad. Por ejemplo: sin una adecuada administración de cambios, nuestros compañeros de equipo pueden cambiar parte del diseño del aplicativo, olvidándose de comentarnos. Como resultado, nosotros escribiremos código que es incompatible con los cambios al diseño, lo cual, eventualmente requerirá que nosotros, o nuestros compañeros de equipo tengan que rehacer parte del trabajo.
Proceso de solicitud de cambios
Cualquier organización que desee administrar adecuadamente los cambios al software, se debe asegurar de que los cambios que se propongan se evalúen cuidadosamente, que las personas indicadas tomen decisiones sobre esos cambios, que los cambios se comuniquen oportunamente a todos los afectados, y que el proyecto incorpore los cambios de una forma disciplinada. Para conseguir esto es necesario contar con un proceso de solicitud de cambios.
El proceso de solicitud de cambios provee procedimientos formales para: registrar solicitudes de cambio; analizar la información del por qué es requerido el cambio, y el impacto que tendrá; y autorizar, rechazar o modificar la solicitud de cambio.
Las solicitudes de cambio pueden provenir de cualquier usuario o interesado, en cualquier punto del ciclo del software, e incluir una solución propuesta, prioridad e impacto, el cual debe ser analizado, aprobado y rastreado formalmente. Una solicitud de cambio puede originarse, por ejemplo, a partir de un defecto en el producto de software, de una petición de mejora o de un cambio a un requerimiento.
El proceso de solicitud de cambios nos permite dar seguimiento a las solicitudes de cambio y efectuar mediciones acerca de la actividad del cambio. Una vez que una solicitud es recibida, una evaluación técnica (análisis de impacto) se lleva a cabo para determinar qué modificaciones se requerirían y si la solicitud de cambio debe ser aprobada. Tener un buen entendimiento de las relaciones entre los elementos de software es importante para llevar acabo el análisis de impacto. Finalmente, una autoridad establecida evaluará todos los aspectos del cambio propuesto y, aprobará, modificará, rechazará o pospondrá dicho cambio. La autoridad para aprobar o rechazar los cambios generalmente se le conoce como comité de control de cambios.
Herramientas para automatizar la administración de cambios
El uso de herramientas puede ayudar a que el proceso de solicitud de cambios se ejecute de manera más eficiente; la automatización nos puede apoyar para iniciar solicitudes de cambio, hacer cumplir el flujo del proceso de cambios, capturar las decisiones del comité de control de cambios y obtener reportes acerca de la información del proceso. Sin embargo, no hay que olvidar que una herramienta no es un proceso. Emplear una herramienta para administrar los cambios de software nunca reemplazará a un proceso bien definido, que describa el contenido y la forma de procesar las solicitudes de cambio.
Para brindar un panorama más real sobre el tipo de funcionalidad que proveen las herramientas de administración de cambio, hemos escogido dos herramientas para estudiarlas: IBM Rational ClearQuest, y Microsoft Team Foundation Server. En las siguientes páginas presentamos nuestros comentarios al respecto.
IBM Rational ClearQuest
Es una herramienta con la que podemos crear, actualizar, administrar y dar seguimiento a solicitudes de cambio de acuerdo a las necesidades de nuestra organización.
En ClearQuest, toda solicitud de cambio debe tener un ciclo de vida definido, que describe el flujo posible de acciones y estados que puede seguir una solicitud. El diagrama de estados en la figura 1, muestra un ejemplo de ciclo de vida para una solicitud de cambio. ClearQuest puede manejar diferentes tipos de solicitud de cambio, cada una con un ciclo de vida diferente. Por ejemplo: una solicitud para un nuevo requerimiento debería manejarse de forma diferente que un registro de defectos. Es posible modificar los tipos de solicitud default y ajustarlos a las necesidades específicas de cada organización.
Figura 1. Ejemplo de ciclo de vida para una solicitud
Interfaz de usuario
Para visualizar y administrar las solicitudes de cambio, ClearQuest soporta diferentes tipos de cliente (Windows, Linux/Unix, Web). Al igual que con los ciclos de vida, cada tipo de solicitud puede tener interfaces de usuario diferentes. Por ejemplo: para generar un nuevo requerimiento, se requiere introducir información diferente que para registrar un nuevo defecto.
Figura 2. El cliente web permite gestionar una solicitud de cambio
En caso de que estemos en presencia de un escenario con equipos de trabajo distribuidos geográficamente, entonces es conveniente usar ClearQuest MultiSite, que permite la comunicación entre distintos repositorios a través de un esquema de replicamiento.
Reportes y métricas
Una solicitud de cambio de ClearQuest cuenta con una variedad de atributos: estado, tipo de cambio, severidad, prioridad, área afectada etcétera; que se almacena en un repositorio del que se puede extraer información sobre el progreso del proyecto a través de las consultas, gráficas y reportes. Estas métricas pueden ser de tres tipos:
•Distribución. Analiza el estado actual de un grupo de registros, por ejemplo: número de solicitudes asignadas y resueltas por desarrollador.
•Tendencia. Comportamiento de los registros durante un período de tiempo en específico, por ejemplo: áreas con mayor cantidad de solicitudes registradas durante en un trimestre.
•Tiempo. Indican cuánto tiempo ha permanecido un registro en un determinado estado, por ejemplo: número de solicitudes que han permanecido en el estado de registrada por más de un mes.
Figura 3. ClearQuest provee una gran variedad de reportes
Pros
•La versatilidad de ClearQuest permite utilizarla no sólo para administrar cambios, sino para resolver otro tipo de workflows.
•Tanto el cliente como el servidor de ClearQuest, están disponibles en diversos sabores de Windows, Unix y Linux. El repositorio de datos puede montarse en DB2, Oracle, SQL Server, SQL Anywhere, e incluso Access.
•La funcionalidad de auditorias nos permite saber qué campos de la forma se cambiaron, quién los cambió, cuándo y, en qué acción y estado.
•ClearQuest cuenta con funciones avanzadas de seguridad como soporte a firma electrónica para autenticación, y acceso a LDAP a través de SSL.
Contras
•La creación de reportes personalizados puede consumir tiempo, o parecer compleja si no se está familiarizado con SoDA o Crystal Reports.
ClearQuest es una solución muy poderosa y flexible. Sus capacidades pueden satisfacer las necesidades de incuso, las organizaciones más exigentes y complejas.
Microsoft Team Foundation Server (TFS)
Es una plataforma de colaboración, que permite administrar y dar seguimiento al avance y al estado del trabajo de los proyectos de software, en base a una serie de servicios Web y repositorios integrados. Por ello, su funcionalidad no se limita a la administración de cambios, sino que también incluye otras funciones como control de código, portales de proyecto, generación de builds, y guías para metodologías de desarrollo y modelos de mejora de procesos.
Team Explorer
Team Explorer es el cliente default para interactuar con TFS. Este es un componente que se ejecuta dentro de Visual Studio, aunque a través de herramientas de terceros también se puede ejecutar dentro de otros IDEs, como por ejemplo Eclipse. Team Explorer permite ver los diversos activos del proyecto (código fuente, modelos, reportes, etcétera).
Fig. 4 El Team Explorer como perspectiva dentro de Eclipse
Elementos de trabajo
TFS emplea el concepto de elemento de trabajo para dar seguimiento a la asignación y al estado del trabajo asociado al ciclo de desarrollo. Existen varios tipos de elementos de trabajo predefinidos, como por ejemplo: las solicitudes de cambio y los defectos. Team Foundation permite personalizar los campos de los elementos de trabajo y la forma cómo se presentan en la pantalla; así como el flujo de trabajo asociado a ellos.
Control de cambios en código
TFS también administra los cambios al código fuente, de forma tal que, en cualquier momento se pueda saber quién y qué modificó el código; y qué solicitudes de cambio, requerimientos y/o defectos están asociados a dicho cambio. Gracias a este control de código, es posible obtener una versión específica del proyecto, hacer ramificaciones (branch) o unir ramas (merge).
Figura 5. El Source Control Explorer permite la administración de cambio de código
Reportes
Team Foundation incluye un almacén de datos en el que se recopilan los datos operativos que provienen de los elementos de trabajo. Este almacén es empleado por los SQL Reporting Services para producir los reportes que correlacionan la información de elementos de trabajo, control de código fuente, resultados de pruebas, análisis de código y/o generaciones de producto.
Figura 6. Reportes automáticos listos para usarse
Orientación del proceso, plantillas de proceso y proyectos de equipo
Visual Studio Team System como familia de productos, tiene un enfoque hacia proceso. Provee guías acerca de roles, actividades, productos de trabajo y reportes personalizados, y mediante plantillas de proceso se puede definir la estructura de los elementos de trabajo, documentos base y las actividades que deberán realizarse como parte del proyecto.
Pros
•Team Foundation Server no se limita a la administración de cambios, sino que provee una plataforma completa para administrar el ciclo de vida de software. Esto se traduce en ahorro de dinero y esfuerzo, ya que evitamos la necesidad de integrar varios productos.
•Los elementos de trabajo de TFS también se pueden acceder desde Excel o Project.
Contras
•TFS sólo funciona sobre plataforma Windows.
•En algunas evaluaciones y comparativos que encontramos, se maneja que una de las limitaciones de TFS es su escalabilidad, ya que difícilmente soporta más de 500 usuarios concurrentes. Sin embargo, sabemos que para el grueso de las organizaciones en América Latina, esto no es un factor importante, ya que en dicha región, el grueso de las organizaciones de software tienen menos de 50 desarrolladores.
Conclusión
Al igual que la mayoría de los productos de Microsoft, TFS es una herramienta amigable y fácil de usar, orientada hacia la productividad, más que a la flexibilidad o la escalabilidad. TFS ofrece una gran relación precio-beneficio, ya que en un producto integrado y fácil de implantar, provee la funcionalidad requerida por la gran mayoría de los equipos de desarrollo de software.
- Log in to post comments