LA REUTILIZACION DE LIBRERIAS EN MOODLE: INCIDENCIA EN LA ESTIMACION DEL DESARROLLO DE UNA PLATAFORMA SIMILAR

Transcripción

1 LA REUTILIZACION DE LIBRERIAS EN MOODLE: INCIDENCIA EN LA ESTIMACION DEL DESARROLLO DE UNA PLATAFORMA SIMILAR Jorge Ramírez, Loraine Gimson, Gustavo Gil, Eduardo Fernández, David Romero, Daniel Arias, Adriana Vera, Ernesto Sanchez Consejo de Investigación de la UNSa. (CIUNSa) - Proyecto de investigación 1960 Universidad Nacional de Salta - Argentina RESUMEN En el CIDIA 1 se propuso la puesta en marcha de una plataforma educativa vía Web. Se planteó, la disyuntiva de adquirir el software necesario, desarrollarlo o adaptarlo a partir de software libre. Una consideración importante al momento de elegir la última alternativa fue el esfuerzo que supondría desarrollar una plataforma de este tipo, aún teniendo en cuenta la reutilización de componentes; las restricciones presupuestarias y de personal comunes en las universidades públicas otorgan especial relevancia a esta exploración. Como primer paso se decidió estimar el costo de desarrollar Moodle, el sistema de administración de aprendizaje vía Web más popular en el ámbito del software libre, centrándose en la valoración de la reutilización de código externo durante el desarrollo de la aplicación. En este trabajo se repasa la literatura existente relacionada con la estimación de costes en el ámbito de software libre, se justifica la utilización de COCOMO II como modelo de estimación según las características del producto y del desarrollo que supondría, se detalla cuáles son los componentes y librerías utilizados y su esfuerzo expresado en líneas de código y se realiza la estimación en base a un trabajo anterior. Finalmente, se presenta los resultados y las conclusiones provisionales alcanzadas. Palabras Claves: plataforma educativa, Moodle, COCOMO II, software libre, reutilización de componentes. 1 INTRODUCCIÓN En la Universidad Nacional de Salta, la Educación a Distancia mediante nuevas tecnologías cobra día a día mayor relevancia. En ese contexto, y teniendo en cuenta la experiencia llevada adelante por docentes de diversas disciplinas, el CIDIA se plantea la puesta en marcha de una plataforma educativa via Web. En su célebre ensayo there's no silver bullet, Brooks expresa que La solución más radical al problema de desarrollo de software es no desarrollarlo 2. Teniendo eso en mente, se propuso evaluar el costo que supondría el desarrollo de una plataforma educativa con las prestaciones de Moodle, el sistema de administración de aprendizaje vía Web más popular en el ámbito del software libre y de código abierto. Esta plataforma, además, cuenta con muchos usuarios en el ámbito de nuestra Universidad, lo que permite tomarla como referencia al momento de definir los requerimientos específicos. Esta mirada se justifica en que Moodle no sólo puede servir como referencia, sino también como base para el desarrollo que se pretende. La disponibilidad del código fuente permite que el dilema de construir vs. comprar tenga una nueva alternativa: adaptar. De hecho, como afirman Hissam y Weinstock del Instituto de Ingeniería de Software en Carnegie Mellon University, el software de código abierto (o libre) constituye una fuente de componentes a partir del cual desarrollar aplicaciones. El propio Moodle es un buen ejemplo de esta posibilidad. En su desarrollo se integraron librerías y componentes de diversos orígenes. En un trabajo anterior 3 se estimó el esfuerzo necesario para el desarrollo suponiendo que se partiera completamente desde cero; en esta ocasión el trabajo se centra en la reutilización presente en Moodle, con una intención doble: ajustar a las condiciones reales del diseño del sistema la estimación del esfuerzo requerido para su desarrollo total, y al mismo tiempo estudiar las características y la incidencia de la reutilización dentro de un proyecto amplio y de código abierto. De ese estudio se espera obtener elementos para el desarrollo que compete al propio CIDIA. El presente trabajo se organiza según el siguiente plan. En primer lugar, un repaso sobre la literatura existente relacionada con la estimación de esfuerzo en el ámbito de software libre y las conclusiones a las que se arribó en esos trabajos. En segundo lugar, una definición del por qué de la utilización de CO- COMO II como modelo de estimación de costos de acuerdo con las características del producto. Posteriormente, un análisis de la incidencia de la reutilización de librerías y componentes en Moodle. A continuación, una exposición brevemente de los criterios según los cuales se establecieron los modificadores de esfuerzo del modelo en cuestión y -por ende- los valores adoptados para cada uno de ellos. Finalmente, se presentan los resultados y las conclusiones provisionales alcanzadas. 1 Centro de Investigación y Desarrollo de Informática Aplicada de la Universidad Nacional de Salta - Argentina 2 The most radical possible solution for constructing software is not to construct it at all. 3 Partir de Moodle: Estimación del esfuerzo que insumiría el desarrollo de una plataforma similar - Presentado en las V Jornadas de Software Libre (JSL)

2 2 ANTECEDENTES Desde el año 2000 se han producido diversos trabajos en los que se propone estimar el costo de desarrollo de programas libres, bajo los supuestos habituales del desarrollo en un ámbito privativo (o propietario). En el año 2001 David A. Wheeler publicó la última versión de su trabajo estimando el costo de desarrollar la distribución de GNU/Linux Red Hat 7.1 a través del modelo COCOMO 81. Para ello, el autor desarrolló la herramienta SLOCCount para contar las líneas de código fuente en una gran variedad de lenguajes de programación. Allí concluye que el desarrollo de esta distribución costaría en el orden de los millones de dólares, demandando 8000 personas-año de tiempo de desarrollo. En la misma línea, González Barahona y otros estimaron el costo de Debian 2.2 utilizando la herramienta de Wheeler y el mismo modelo de estimación; esta distribución, una de las más grandes, incluye unas 55 millones de líneas de código, implicando un costo cercano a los millones de dólares. En marzo de este año, este grupo de investigación estimó el esfuerzo necesario para el desarrollo de Moodle desde cero, en el contexto específico del CIDIA. Se concluyó que el desarrollo demandaría 1024 personas/mes aproximadamente. 3 LA UTILIZACIÓN DE COCOMO II Se ha comprobado empíricamente que es prácticamente imposible disponer de una especificación de requisitos completa en las primeras etapas del desarrollo, para luego pasar a la etapa de diseño. La estimación de COCOMO 81 se basaba en los modelos de ciclo de vida en cascada, donde se suponía la viabilidad de esa especificación temprana. Hoy en día se adoptan los procesos de desarrollo iterativos 4 que son más coherentes con los que sucede en la realidad de la construcción de un software. El desarrollo de Moodle se corresponde con técnicas modernas que involucran la reutilización de software y el diseño orientado a objetos. Moodle incluye a librerías de amplia distribución (como ADOdb y GraphClass), así como editores de texto incrustados (HTMLArea) (véase además, el diseño de Moodle está orientado a su reutilización, constituyendo un factor de gran importancia a la hora de estimar el esfuerzo requerido. Cabe señalar, además, que el desarrollo en el ámbito del F/OSS presenta puntos de contacto con las metodologías ágiles, especialmente en cuanto a la elicitación y definición de requerimientos. Este conjunto de características hacen inadecuada la estimación mediante el modelo COCOMO '81. Se consideró también que COCOMO II propone un nuevo escenario de desarrollo considerando diferentes enfoques (como el de construcción de prototipos, el desarrollo por composición de componentes, el desarrollo iterativo, etc.) y, en particular, el enfoque Orientado a Objetos. Estas características resultan más apropiadas bajo la hipótesis de un desarrollo encarado por el propio equipo del CIDIA, permitiendo además- tomar en cuenta las condiciones específicas en que podría llevarse adelante el desarrollo dentro del propio instituto. COCOMO II toma en cuenta la reutilización de componentes de software, considerando tanto el esfuerzo que supone la selección, evaluación y eventual adaptación de código externo. Al mismo tiempo, permite valorar la reducción del esfuerzo total que puede suponer la reutilización. La siguiente ecuación muestra la fórmula para estimar el esfuerzo del proyecto de desarrollo. PM = m A. [ Size] RVOL ( 1+ ) 100 AT B ASLOC ATPROD Ec (1) ( AA+ SU+ 0.4 DM+ 0.3 CM+ 0.3 ) 100 AT IM Size= KNSLOC+ KASLOC Ec (2) Donde la descripción de los símbolos es la siguiente: A: Constante, comúnmente calibrada como 2.45 AA: Evaluación y asimilación AT: Pje de componentes que se traducen automáticamente ATPROD: Productividad de traducción automática B: Factor de escala RVOL: Pje de código descartado debido a requerimientos volátiles CM: Pje de código modificado DM: Pje de diseño modificado IM: Pje de integración y prueba modificado KASLOC: Tamaño del componente adaptado expresado en miles de líneas de código adaptadas del código fuente KNSLOC: Tamaño del componente expresado en miles de nuevas líneas de código fuente m: Multiplicador del esfuerzo PM: Esfuerzo estimado en personas/mes SU: Comprensión del software (cero si DM = 0 y CM = 0) 4 Algunos metodologistas dividen a los métodos iterativos actuales en livianos y pesados de acuerdo a la cantidad de soporte documental y administrativo de los mismos. Entre los métodos ligeros se encuadran Extreme Programming (XP), SCRUM, la familia de métodos Cristal, etc. Entre los métodos llamados pesados se encuentre RUP ( Proceso Unificado de Rational) cuyos autores son los creadores del estándar UML. 4.- EL PESO DE LA REUTILIZACIÓN 4.1 Contando las líneas de código La herramienta SLOCCount cuenta líneas de código; la casi totalidad está escrita en PHP, con algunos elementos en Perl y sh. A este cómputo faltaría agregar las líneas en

3 JavaScript, las cuales representan un porcentaje bajo, pero que resulta de interés al considerar el porcentaje de reutilización. Se utilizó la aplicación Practiline source code line counter para determinar el tamaño del código JavaScript total. De este modo se obtuvo que esta versión de Moodle incluye líneas. A esta suma se debe agregar código en C, debida a la utilización de la librería MimeTex. Esta librería se distribuye con Moodle en formato ejecutable, además del código fuente, con el objetivo de garantizar el carácter multiplataforma. Para este elemento, SLOCCount computa líneas de código. Será necesario considerar a continuación la incidencia de la reutilización en la estimación del tamaño. 4.2 Los componentes reutilizados En el sitio de Moodle, en la página mencionada anteriormente, se detalla la lista de librerías externas utilizadas por Moodle. Además, se reconoce cuáles han sufrido modificaciones para su incorporación a Moodle, en la tabla 1 se puede observar dicha información. Librería Función Mod Tamaño (SLOC) ADODB FPDF Biblioteca de abstracción de base de datos Biblioteca para crear archivos en formato PDF Graph Class Biblioteca para dibujar puntos, líneas, gráficos de barras, etc. html2text Script para convertir contenido en HTML en texto plano (PHP) 2034 (PHP) 1353 (PHP) 96 (PHP) HTMLArea Editor HTML online 1359 (PHP) (Perl) (JS) TinyMCE Editor HTML online 6835 (JS) (PHP) Kses mimetex Filtro XHTML que permite sólo ciertos atributos Filtro para convertir de Tex a GIF overlibmws Biblioteca para incorporar efectos DHTML 291 (PHP) (ANSI C) 605 (JS) mp3player Reproductor MP3 ActionScript PclZip Biblioteca para manipular archivos compri (PHP) Librería Función Mod Tamaño (SLOC) Bibliotecas PEAR PHP Markdown midos Zip Conjunto de biblioteca con utilidades PHP, como la escritura en formato CSV, presentaciones DHTML, envío de correo, etc. Conversor de formato Markdown a XHTML 5270 (PHP) 1127 (PHP) Snoopy Cliente de red en PHP 849 (PHP) Typo3 Clase para convertir entre juegos de caracteres 3104 Tabla1: Librerías externas utilizadas por Moodle [10] Considerando el total de las líneas de código contadas, se obtuvo: Total de líneas de Moodle: LDC Líneas de reuso sin modificaciones: LDC Líneas de reuso con modificaciones: LDC Total de líneas nuevas: LDC Total de líneas de reuso: LDC (37.48% del total) Porcentaje de componentes automáticamente trasladados: % Porcentaje de componentes reutilizados modificados: 15,92 % Se puede observar que las líneas de código reutilizadas modificadas representa sólo el 15,92% del reuso. Esto implica una reducción considerable del tamaño total, como se verá en la siguiente sección. 4.3 Tamaño con reutilización COCOMO II considera el tamaño total a partir de dos sumandos: la cantidad de líneas de código nuevas y las reutilizadas, considerando el trabajo que hubiera requerido la adaptación de ese código. Con el fin de realizar dicho cálculo, se consideró, para KNSLOC, KLDC, para KASLOC, KLDC, y respecto de AT:84.08% según lo que se detalló en la sección anterior. AA: 2 ya que la incorporación de estas librerías requieren en su mayoría de Búsqueda y documentación de Módulos Básicos. CM: 20 lo que representa el promedio estimado de las modificaciones de código requeridas. Dado que la documentación de COCOMO no especifica una técnica para determinar esta cantidad se estimó la proporción equivalente a escribir el código desde cero. DM: 0 al considerar que no hay modificaciones de diseño.

4 IM: 20 siendo pesimistas y debido a las mismas razones explicada en CM y las consideraciones que se detallan mas abajo. SU: 30 que es el valor nominal. De las librerías consideradas ninguna presenta grandes deficiencias en cuanto a su estructura y documentación aunque varían en cuanto a la cobertura de estas últimas. Los valores de CM, DM e IM estaban presentes en el modelo COCOMO original e indicaban la incidencia lineal de estos aspectos en el esfuerzo que requiere el desarrollo. Los valores de SU y AA, en cambio, inciden en forma no lineal. Para determinar los valores de estos factores, el equipo de investigación se concentró en las librerías que fueron modificadas. Estas son: GraphClass, HTMLArea, TinyMCE, HTML2text y PHPMarkdown. Como indicador de las dificultades de la integración, se consideraron los errores reportados en Moodle Tracker, el sistema de seguimiento y resolución de errores de que dispone el proyecto. La cantidad de errores reportados por cada uno de los componentes en cuestión es: HTMLArea, 91; GraphClass, 776. TinyMCE, 4; HTML2Text, 2; PHP Markdown, 5041 (Para todas las versiones al día 24 de julio de 2007). Con estos valores se obtuvo un tamaño de 197,04 KLDC que es significativamente menor que las 302,44 KLDC finales de Moodle. Con los supuestos del presente trabajo, el código modificado reutilizado supondría un esfuerzo equivalente a casi el 44% de escribirlo desde cero. Lo que es un indicativo del carácter pesimista de nuestra estimación. 4.4 Multiplicador de coste (M) Tal como se justifica en un trabajo anterior, se definió cada uno de los factores de coste. RCPX= bajo RUSE= alto PDIF= bajo SCED= nominal PERS= nominal PREX=alto FCIL= nominal El valor del multiplicador de coste obtenido es igual a Factores de Escala (B) De manera similar a los factores de coste, se explicó en un trabajo anterior los valores obtenidos para los factores de escala, cuyos valores fueron los siguientes Precedentes = alto Flexibilidad de desarrollo = nominal Arquitectura /Resolución de riesgos = nominal Cohesión del equipo = nominal Nivel de madurez = muy bajo El valor obtenido para B es de Volatilidad de los Requerimientos (RVOL) COCOMO II utiliza este porcentaje para ajustar el tamaño eficaz del producto. RVOL refleja la volatilidad de los requisitos en un proyecto; es el porcentaje de código desperdiciado debido a la volatilidad de los requisitos. En nuestro caso, dicho porcentaje es cero ya que se consideran fijos a los requerimientos, al basarse en una versión determinada de Moodle. 4.7 (ATPROD) Este valor depende de la tecnología y lenguaje de desarrollo. Moodle está desarrollado mayoritariamente con PHP y desde una perspectiva orientada a objeto. Se estimó en 1000 líneas de código por persona-mes en base a la experiencia de desarrollo de nuestro equipo. 4.8 Estimación del esfuerzo Con todos los valores definidos en las secciones anteriores se puede finalmente realizar la estimación del esfuerzo de desarrollo de Moodle considerando reutilización. El valor obtenido es de 924,24 pers/mes que es significativamente diferente a los 1358,64 pers/mes sin considerar reuso. 5 CONCLUSIONES A partir de esta estimación, se revela que el esfuerzo de desarrollo de un software como Moodle es enorme, tal como era de suponer. Si desde el CIDIA se quisiera llevarlo a cabo, se enfrentaría además a restricciones de personal; nuestro equipo de desarrollo está conformado únicamente por 8 personas. Realizando los cálculos de cuánto tiempo llevaría desarrollar este sistema desde cero entre 8 personas, insumiría casi 128 meses, lo que equivale a más de 10 años. La disyuntiva de comprar vs. construir tiene ahora un nuevo componente. Gracias a la disponibilidad del código abierto existe otra alternativa, la de adaptar. Se coincide con Hissam y Weinsctock, respecto de que el software de código abierto constituye una fuente de componentes a partir del cual desarrollar aplicaciones. Esta es la opción que se tiene en el CIDIA para poder atender la necesidad de contar con un entorno Web para la educación a distancia, adaptando el código disponible de Moodle. El esfuerzo de desarrollo se verá reducido drásticamente; nuestro siguiente paso es estimar realmente cuanto esfuerzo nos llevará realizar esta adaptación. REFERENCIAS [1] Boehm, B. Cost Models for future software life cycles processes: COCOMO 2.0. Annals of Software Engineering, [2] Wheeler, David A. More than a Gigabuck. Estimating GNU/Linux Size. Julio de [3] Spinelli, Diomidis y Szyperski, Clemens. How is Open Source Affecting Software Development?. IEEE Software. January/February [4] Hissam, Scott y Weinstock, Charles. Open Source Software: The Other Commercial Software. SEI-CMU [5] Brooks, Frederick. The Mythical Man Month, Aniversary Edition. Addison-Wesley, [6] González- Barahona et al. Counting Potatoes: The size of Debian

5 [7] De La Fuente Moya, Antonio. COCOMO v2 - Modelo de Estimaciones de Costes para proyectos software. Escuela Superior de Informática. Universidad de Castilla-La Mancha. Mayo 1999 [8] Goldman, Ron y Gabriel, Richard. Innovation Happens Elsewhere: Open Source as Business Strategy. Morgan Kaufman Publishers [9] Raymond, Eric. The Cathedral and the bazaar. [10] Créditos de Moodle- Ültimo acceso: 15/07/07 [11] Arquitectura de Moodle: Último acceso: 20/07/07