Herramienta para la Administración y Estimación Ágil de Desarrollo de Software
Mario R. MORENO SABIDO
Depto. de Sistemas y Computación, Instituto Tecnológico de Mérida Mérida, Yucatán 97118, México
y
Jorge BAROUDI PEREZMILICUA
Depto. de Sistemas y Computación, Instituto Tecnológico de Mérida Mérida, Yucatán 97118, México
RESUMEN
En este artículo se describe el desarrollo de una herramienta web que le permite a un equipo de desarrollo realizar y registrar estimaciones de tiempo y tamaño de un proyecto de software, y compararlas con el trabajo real realizado a lo largo del proceso de desarrollo por medio de un sistema de control de versiones. La herramienta SADEP (Sistema de Administración del Desarrollo y Estimación de Proyectos) fue desarrollada de tal forma que también permite a los desarrolladores y líderes de proyectos registrar avances sobre sus actividades diarias por medio de un Product Backlog (repositorio de productos), de tal manera que puedan crear una base histórica que sirva como base para futuras estimaciones de proyectos a desarrollar.
La herramienta fue desarrollada siguiendo la metodología de desarrollo ágil SCRUM. También se presentan los resultados obtenidos en la implementación de la misma. Por último, se mencionan las conclusiones a las que se llegaron al final de este trabajo.
Palabras Claves: Estimación de Proyectos de Software, Metodología de Desarrollo Ágil SCRUM, Generación de Código.
1. INTRODUCCIÓN
La estimación de un proyecto de software es una tarea difícil. A medida que los requerimientos son más complejos, la estimación del tamaño tiene que incluir nuevos factores de estimación propios del proyecto, y por ello resulta complicado crear modelos generales adecuados para la mayoría de los casos. Por otro lado, la experiencia en la metodología de desarrollo, y en la tecnología en la que se desarrolla difiere de persona a persona, por lo tanto, tomar datos de manera general puede llegar a ser inútil para calcular una estimación aproximada si no se cuenta con una madurez en el equipo de desarrollo, esto es, que se integren estándares para todas las actividades de la programación.
Si se desarrolla software en un entorno donde se domina la metodología y las tecnologías a usar, se pueden establecer cálculos para determinar un tamaño aproximado para cada elemento de la aplicación, y así determinar una estimación del tamaño final del proyecto que se va a desarrollar. En entornos
donde no existe una metodología bien definida, se realizan estimaciones con resultados cercanos a la realidad, si por lo menos se tiene una experiencia práctica en aplicaciones similares.
Para realizar una estimación de un proyecto, muchos equipos y organizaciones buscan definir un único proceso que generalice todo el desarrollo de software, pensando que si pudieran crear software de la misma manera, usando los mismos procesos, recursos y produciendo los mismos documentos, entonces sería mucho más fácil la administración y el aseguramiento de la calidad [1]. El problema es que los sistemas de software, la tecnología y las organizaciones difieren tanto, que cualquiera de los modelos que realmente definan el desarrollo de software con su amplia gama de variaciones se vuelve de poco uso práctico, a menos que se describa cada posible rol, actividad, salida y paso en detalle.
Son pocas las empresas encargadas del desarrollo de software que han alcanzado un nivel de madurez con respecto a los procesos y a las estimaciones que realizan, principalmente por los costos administrativos y el esfuerzo que representa dar seguimiento a todos los factores que forman parte del aseguramiento de la calidad. Sin embargo, gracias a metodologías con una visión ágil del desarrollo de software, la perspectiva ha ido cambiando poco a poco.
2. ESTIMACIÓN DE PROYECTOS DE SOFTWARE
La estimación es generalmente una aproximación o un cálculo especulativo de un resultado, basado normalmente en otras aproximaciones, especulaciones y otros datos inciertos e incompletos. Es la aplicación de una métrica para determinar el tamaño de un programa de software. La estimación de líneas de código puede hacerse utilizando un conteo manual y luego procesándolos como datos históricos para proyectos futuros, o también, haciendo una lista de los puntos de función que integran el proyecto y determinando un factor de complejidad para calcular el número de líneas de código final.
Los métodos de estimación deben consistir en procesos estructurados con la finalidad de facilitar el entrenamiento de los programadores en el proceso de estimación y las actividades de seguimiento y mejora de los procesos. La metodología de estimación también debe contemplar su uso en cualquier fase del proyecto; en el inicio del desarrollo se utiliza para establecer
planes, estrategias y costos, y a medida que se avanza en el ciclo de vida del proyecto se contemplan estimaciones para las nuevas características funcionales con los datos históricos dados por la retroalimentación constante.
La estimación es un concepto de la calidad de software que no sólo debe enfocarse al tamaño de la aplicación por mediciones derivadas de las líneas de código; debe considerarse realizar estimaciones para la documentación, reportes, archivos, pantallas de presentación, y de una forma más general, puede incluir estimaciones para puntos de vista generales como el impacto en otros proyectos, la mejora de los procesos internos de calidad y las manutenciones del software a desarrollar.
El proceso de estimar no se domina de manera inmediata en un equipo de desarrollo. De la misma forma, es muy difícil iniciar con métodos complejos de estimación (como la regresión lineal) si no se cuenta con la experiencia de métodos más simples. Es necesario que el equipo de desarrollo establezca un proceso de mejora continua sobre su proceso de estimación interactuando con más de un método de estimación y comparando los resultados [2].
3. METODOLOGÍA DE DESARROLLO ÁGIL SCRUM
SCRUM es una de las metodologías ágiles más conocidas para la gestión de proyectos. Se centra en aspectos como la flexibilidad en la introducción de cambios y nuevos requisitos durante el proyecto, el factor humano, el producto final, la colaboración con el cliente y el desarrollo incremental como formas de asegurar los buenos resultados en proyectos con requisitos muy cambiantes o cuando se exige, como es habitual, reducir los tiempos de desarrollo manteniendo una alta calidad.
Es aplicable en cualquier proyecto en el que exista una lista de funcionalidades o bloques de trabajo por realizar, un entorno complejo con requisitos cambiantes y un equipo de desarrollo asignado a dicha tarea.
Se basa en un enfoque iterativo, donde cada iteración se denomina Sprint. Al final de cada Sprint se obtiene un producto entregable que se va incrementando en sucesivos Sprints, priorizándose aquellos aspectos que aportan mayor funcionalidad y valor al dueño del producto (cliente).
El principio básico es que es muy difícil contar desde el inicio con un catálogo completo de funcionalidades, ya que los requisitos van surgiendo conforme el propietario del producto y los usuarios del mismo van haciendo sucesivas aportaciones. De esta manera, SCRUM plantea el desarrollo de sucesivas versiones ampliadas, todas ellas plenamente usables y evaluables por el usuario. Además, es una metodología especialmente indicada para pequeños equipos de desarrollo y se orienta a una entrega rápida de resultados y una alta flexibilidad [3]. En la Figura 1 se presenta el proceso de desarrollo de SCRUM.
Figura 1. Flujo del Proceso de Desarrollo con SCRUM.
4. DESCRIPCIÓN DE LA HERRAMIENTA
El sistema SADEP (Sistema de Administración del Desarrollo y Estimación de Proyectos) es una herramienta destinada a los líderes de proyectos de software y los programadores que integren equipos de trabajo registrando los avances sobre las actividades diarias de desarrollo y estimaciones de tiempo y de líneas de código donde sea conveniente.
Las actividades son agregadas a una lista llamada Product Backlog (Repositorio de Productos) que está definida en un formato basado en la metodología de desarrollo ágil SCRUM. En el caso de tener información de experiencias pasadas y resultados obtenidos del sistema de control de versiones, se podrán adaptar a la lista las estimaciones de líneas de código por actividad, las cuales se calificarán con el trabajo real toda vez que se marque la actividad como finalizada y se pueda obtener retroalimentación de los cambios realizados en el código fuente.
Debido a que cada usuario realiza su estimación con base en su experiencia y a los reportes de actividades similares con los cambios realizados en el código, la herramienta es capaz de reportar las mejores estimaciones con un margen de error predefinido, tanto en el tiempo (Estimación común por tiempo), como en líneas de código (Estimación basada en actualizaciones de código por programador).
La arquitectura de la aplicación está basada en clases que forman parte de capas con responsabilidades específicas, desde la interacción con la base de datos del sistema SADEP hasta la interfaz del usuario.
En la fase de administración de proyectos el líder de proyecto crea un nuevo proyecto para ser utilizado posteriormente para registrar las actividades y las estimaciones en el sistema.
En la fase de administración de actividades el líder de proyecto registra las actividades contempladas a una fecha determinada, y los programadores realizan la selección del tipo de estimación a realizar que puede ser por líneas de código, o en su defecto, por tiempo. También se seleccionan detalles de la actividad como las entradas y salidas esperadas, y posteriormente el porcentaje de avance durante el desarrollo de la actividad.
En la fase de administración de la estimación el programador que determine una estimación por líneas de código podrá enlazar los archivos de código fuente relacionados con la actividad de desarrollo, y de manera externa podrá consultar las herramientas cliente del control de versiones para alimentar dentro del sistema SADEP un total de líneas de código a modificar por archivo o general. Una vez terminada la actividad, la herramienta realiza el conteo real de líneas de código modificadas y establece el margen de error de la estimación. Es importante señalar que se debe indicar el número de revisión dado por el sistema de control de versiones una vez que se realiza la operación de actualización de código.
La figura 2 muestra las capas que conforman la estructura interna de la herramienta.
Figura 2. Arquitectura de la Herramienta SADEP.
Administración De Proyectos
El sistema SADEP cuenta con 3 actores principales: el administrador del sistema que alimenta los catálogos, el líder de proyecto y el programador. El líder de proyecto inicia las operaciones con el registro de un nuevo proyecto; para ello se requiere una descripción del proyecto y el enlace o ruta al repositorio de código CVS (Control Versioning System, Sistema de Control de Versiones). Este enlace con el CVS es muy importante ya que este sistema permitirá el control de versiones por medio del registro de todo el trabajo y los cambios en los ficheros (código fuente y la diversidad de documentos que formarán parte del proyecto).
CVS utiliza una arquitectura cliente-servidor: el servidor guarda las versiones del proyecto y su historial, los desarrolladores o clientes se conectan al servidor para sacar una copia completa del proyecto, trabajan con esa copia y más tarde registran sus cambios al servidor.
Administración De Actividades
La administración de actividades tiene inicio a partir de la creación de proyectos que realiza el líder de proyecto, seguida de la vinculación del mismo con uno o varios repositorios de productos (Product Backlog) que engloban actividades a realizar y que dan como resultado final un módulo, programa o sistema de valor directo para el cliente. En la figura 3 se ilustra el momento en donde ya se ha relacionado el proyecto
“SADEP” con el repositorio de productos “Modificación de interfaces para mejora de listados”.
Figura 3. Vinculación de un Product Backlog a un Proyecto.
Las actividades a realizar en el proyecto se dan de alta vinculándolas directamente con el repositorio de productos y seleccionando el tipo de actividad a realizar como actividad finita o cíclica. Finalmente se captura la descripción de la actividad e internamente se registra para dar inicio una vez que se agregue un status de la actividad (ver Figura 4).
Figura 4. Registro de Actividades en el Repositorio de Productos.
En la Figura 5 se presenta un ejemplo de la estructura interna de un Product Backlog en donde se puede observar el registro de las actividades del desarrollador, la estimación del esfuerzo de la actividad (en horas), el personal asignado a cada actividad (identificado por las iniciales), el porcentaje de avance (en este caso todas están aún por iniciarse), entre otras cosas. Los resultados de avance en trabajo real se pueden observar, tanto en el promedio de los porcentajes (columna B), como en la sumatoria de trabajo real de la columna G (comparándolo con la sumatoria de la estimación de la columna F).
Figura 5. Estructura Interna de un Product Backlog.
Para registrar las actividades se adaptó el formato definido por la metodología ágil SCRUM llamado Product Backlog [4]. En la especificación original de SCRUM se definen estimaciones de tiempo para finalizar cada actividad, se asignan recursos
humanos y se registran avances por medio de los Sprint Backlogs (Repositorio de Avances). Sin embargo, se creyó conveniente registrar el avance directamente en la lista y las entradas y salidas esperadas por actividad para llevar un control del resultado esperado, y así marcar las actividades con prioridades o asignarles un desarrollo secuencial.
Para agregar un mayor detalle sobre la actividad a desarrollar se agregan las entradas y salidas esperadas (I/O) y los recursos humanos que desarrollarán la actividad. Como alternativa, se puede clasificar la lista por número o niveles de prioridad para adaptarse a un plan estratégico, creado por el líder del proyecto para la entrega de resultados y compromisos hechos con el cliente.
Administración De La Estimación
El primer paso de esta fase es cuando el programador establece una estimación en líneas de código (LOC) que necesitará escribir por cada una de las actividades que fueron registradas en los repositorio de productos (ver Figura 6). Esta estimación es realizada en base a la experiencia de los programadores y el uso de herramientas de análisis sobre los datos históricos en proyectos similares.
Figura 6. Estimación de Líneas de Código por Actividad.
Una parte importante de la herramienta SADEP es que utiliza la generación de código de tal manera que se pueden obtener resultados de una manera rápida y eficaz en los proyectos de software a desarrollar. La generación de código permite mantener las buenas prácticas del diseño de clases. La herramienta que se utilizó para este proyecto es CodeSmith para aprovechar el avance que se tiene con las plantillas NetTiers en el ambiente laboral donde se realizaron las pruebas. Además, está enfocado principalmente a crear código en C# .Net que es el lenguaje con el que se realizó el SADEP. El código generado está basado en patrones de diseño tales como el Patrón de Acceso a Datos (DAO) que permite la interacción con diferentes Bases de Datos (diferentes arquitecturas o distribuidas), y el Patrón Proxy que sirve de intermediario entre capas para centralizar políticas de validación y seguridad, entre otros. Estos patrones están organizados en capas, donde cada clase cumple con una responsabilidad específica y delega o se comunica con las capas inmediatas.
Una vez que el programador termina de programar la actividad (o mas bien de adecuar el código fuente generado) y la marca la actividad como finalizada, el líder de proyecto puede realizar un cálculo automático del trabajo real (ver Figura 7). El trabajo real está definido en dos partes: El tiempo y las líneas de código; el tiempo trabajado es procesado internamente con base en las
horas empleadas en la actividad. Las líneas de código son calculadas automáticamente a través de la herramienta SADEP que interactúa con el repositorio de control de versiones, el cual provee de comandos específicos para la identificación de las modificaciones a los archivos de código fuente a través de las revisiones o actualizaciones que se realizan. Este cálculo requiere que se administre el repositorio de control de versiones para eliminar los archivos generados por herramientas (como el Visual Studio .Net) y que no son parte de las estimaciones que realizan los programadores. Otro medio para realizar un conteo real es establecer políticas donde el programador suba código fuente en una transacción de actualización y en otra transacción los archivos generados por herramienta. De esta forma se tendrán dos números de revisión diferentes, de los cuales solamente se registra en el SADEP el que interesa para el cálculo de trabajo real por líneas de código (LOC).
Figura 7. Cálculo del Trabajo Real.
5. IMPLEMENTACIÓN
Para implementar la herramienta SADEP se utilizó Visual Studio.Net 2005 y el lenguaje C# para aplicaciones web ASP.Net. La base de datos es SQL Server 2005 Express Edition y el SQL Serve 2005 Management Studio es la herramienta cliente para la creación y modificación de la base de datos.
La seguridad corre a cargo de la misma base de datos con la creación de roles (Database roles) y usuarios (logins). El servidor Web es Microsoft Internet Information Services (IIS) versión 6.0 donde se instaló la aplicación web y las diferentes capas de la aplicación. Se utilizaron componentes Telerik ASP.Net para mejorar las interfaces visuales de captura y listados.
Se integraron las herramientas de control de versiones Subversion y el cliente TortoiseSVN para realizar las consultas de trabajo real por revisión de cada programador en los proyectos de los cuales se tiene historial de líneas de código, y se utilizó la librería DotSVN para la interacción del sistema SADEP con el Subversion.
Otras herramientas utilizadas durante el desarrollo y mantenimiento de la aplicación como Apex SQL, Web Log Lite y SQL Effects Clarity son para tareas como auditoría, monitoreo de la aplicación web y normalización de cambios en base de datos de desarrollo y producción.
6. RESULTADOS
Como resultado de este trabajo se obtuvo una herramienta web que permite adoptar las buenas prácticas de desarrollo propuestas por las metodologías ágiles, junto con las estimaciones de tiempo y líneas de código. Esta herramienta se
desarrolló e implantó en la Dirección de Informática de la Secretaría de Hacienda del Estado de Q. Roo.
Para poder probarla fue necesario aplicarla en el desarrollo de proyectos reales. Existen proyectos finalizados en dicha dependencia y los resultados de utilizar la herramienta fueron satisfactorios debido a que proporcionó un valor agregado, ya que permitió a los programadores y jefes de proyectos realizar sus estimaciones, y además contar con esta información para llevar un mejor control del trabajo que se estaba desarrollando, y usar esta información como base para estimaciones de proyectos similares futuros.
Actualmente sigue siendo utilizada como un estándar por el personal de la Dirección de Informática para el desarrollo de proyectos de software.
En la Figura 8 se presentan los resultados obtenidos al utilizar la herramienta SADEP para calcular el trabajo real (tanto del tiempo de desarrollo, como de líneas de código) que se necesitó para el desarrollo de ciertas actividades de un proyecto en particular. Como se puede apreciar, al comparar las estimaciones de tiempo y de LOC con el trabajo real, los resultados obtenidos fueron satisfactorios.
Figura 8. Comparación de la Estimación con el Trabajo Real.
7. CONCLUSIONES
Las actividades de desarrollo de software que están ligadas al desarrollo incremental e iterativo no están exentas de realizar estimaciones de tiempo y de líneas de código para determinar tiempos de entrega aproximados a los usuarios.
Las metodologías ágiles como SCRUM han sido concebidas para establecer un equilibrio entre las necesidades de los usuarios y los tiempos de entrega de productos funcionales en períodos cortos agregando mayor funcionalidad a través de un desarrollo incremental e iterativo. Los integrantes de un equipo de desarrollo en un ambiente ágil pueden ser vistos como programadores acostumbrados a realizar cambios estructurales en el diseño del software y tomar esto como una actividad común en el quehacer diario del desarrollo de un proyecto debido a que se realiza una división granular de las actividades.
Los equipos de desarrollo de software que realicen el seguimiento de sus actividades por proyecto utilizando la herramienta SADEP, contarán con un valor agregado ya que contarán con información en tiempo real de los avances por cada programador. Dado el carácter ágil de las estimaciones y registro de detalles de actividades en la herramienta, se considera que los programadores liberarán tiempo en realizar reportes de avances a los directivos de sus áreas de trabajo.
El proceso de realizar estimaciones a través de la herramienta permite que cada programador realice estimaciones basadas en su experiencia y para actividades similares en proyectos de diferente contexto, toda vez que se realice una revisión de los proyectos históricos y las relaciones entre sus características funcionales.
Con la herramienta de seguimiento y estimación se reduce el costo de las comunicaciones entre las personas relacionadas con el proyecto debido a que el monitoreo de los avances se puede realizar en tiempo real por parte de los líderes de proyecto, jefes de área y directivos.
8. REFERENCIAS
[1] Palmer, R. y J. Felsing, (2002). A practical guide to Feature Driven Development. Ed. Prentice Hall PTR. [2] Humphrey, W., (1994). A discipline for Software
Engineering. Ed. Boston: Addison – Wesley.
[3] Gloger, B., (2008). “SCRUM Checklists” [En línea]. Disponible en:
http://www.infoq.com/books/scrum-checklists [Accesado el día 12 de Septiembre de 2008].
[4] Agile Software Development, (2008). “SCRUM – Simple Product Backlog” [En línea]. Disponible en:
http://agilesoftwaredevelopment.com/files/apostimages/Scr um/simple-product-backlog.png.%20UFC:%2002/12/2007
