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 Ve-
ra, Ernesto Sanchez
loraine@cidia.unsa.edu.ar
Consejo de Investigación de la UNSa. (CIUNSa) - Proyecto de investigación 1960
Universidad Nacional de Salta - Argentina
RESUMEN
En el CIDIA1 se propuso la puesta en marcha de una platafor-
ma educativa vía Web. Se planteó, la disyuntiva de adquirir el
software necesario, desarrollarlo o adaptarlo a partir de softwa-
re 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 rele-
vancia a esta exploración. Como primer paso se decidió esti-
mar el costo de desarrollar Moodle, el sistema de administra-
ción de aprendizaje vía Web más popular en el ámbito del soft-
ware 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 esti-
mació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 estima-
ció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
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.”
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 plata-
forma, 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 referen-
cia, 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 In-
geniería de Software en Carnegie Mellon University, el softwa-
re de código abierto (o libre) constituye una fuente de compo-
nentes 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 diver-
sos orígenes. En un trabajo anterior3 se estimó el esfuerzo nece-
sario para el desarrollo suponiendo que se partiera completa-
mente 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 estima-
ción del esfuerzo requerido para su desarrollo total, y al mismo
tiempo estudiar las características y la incidencia de la reutiliza-
ció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 segun-
do 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 adop-
tados para cada uno de ellos. Finalmente, se presentan los resul-
tados y las conclusiones provisionales alcanzadas.
3
“Partir de Moodle: Estimación del esfuerzo que insumiría el desarro-
llo de una plataforma similar” - Presentado en las V Jornadas de
Software Libre (JSL)
 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 len-
guajes de programación. Allí concluye que el desarrollo de esta
distribución costaría en el orden de los 1.000 millones de dóla-
res, 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, impli-
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 ade-
lante el desarrollo dentro del propio instituto.
COCOMO II toma en cuenta la reutilización de componen-
tes 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.

[( ) ]
cando un costo cercano a los 2.000 millones de dólares.   AT  
.B  ASLOC⋅ 100 
PM = m⋅ A⋅ 1+
RVOL
⋅ Size +    Ec (1)
En marzo de este año, este grupo de investigación estimó el  ATPROD 
100
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.
 100− AT ( AA+ SU + 0.4 ⋅ DM + 0.3 ⋅ CM + 0.3 ⋅ IM)
Size= KNSLOC+ KASLOC⋅  ⋅ 
  100  100 
3 LA UTILIZACIÓN DE COCOMO II
Ec (2)
Se ha comprobado empíricamente que es prácticamente im-
Donde la descripción de los símbolos es la siguiente:
posible disponer de una especificación de requisitos completa
en las primeras etapas del desarrollo, para luego pasar a la etapa • A: Constante, comúnmente calibrada como 2.45
de diseño. La estimación de COCOMO 81 se basaba en los • AA: Evaluación y asimilación
modelos de ciclo de vida en cascada, donde se suponía la viabi- • AT: Pje de componentes que se traducen automáti-
lidad de esa especificación temprana. Hoy en día se adoptan los camente
procesos de desarrollo iterativos4 que son más coherentes con • ATPROD: Productividad de traducción automática
los que sucede en la realidad de la construcción de un software. • B: Factor de escala
• RVOL: Pje de código descartado debido a requeri-
El desarrollo de Moodle se corresponde con técnicas mo-
mientos volátiles
dernas que involucran la reutilización de software y el diseño
• CM: Pje de código modificado
orientado a objetos. Moodle incluye a librerías de amplia distri-
bución (como ADOdb y GraphClass), así como editores de • DM: Pje de diseño modificado
texto incrustados (HTMLArea) (véase • IM: Pje de integración y prueba modificado
http://docs.moodle.org/en/Credits); además, el diseño de Mood- • KASLOC: Tamaño del componente adaptado expre-
le está orientado a su reutilización, constituyendo un factor de sado en miles de líneas de código adaptadas del códi-
gran importancia a la hora de estimar el esfuerzo requerido. go fuente
Cabe señalar, además, que el desarrollo en el ámbito del F/OSS • KNSLOC: Tamaño del componente expresado en mi-
presenta puntos de contacto con las metodologías ágiles, espe- les de nuevas líneas de código fuente
cialmente en cuanto a la elicitación y definición de requeri- • m: Multiplicador del esfuerzo
mientos. Este conjunto de características hacen inadecuada la • PM: Esfuerzo estimado en personas/mes
estimación mediante el modelo COCOMO '81. • 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 encua-
dran 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 231.209 líneas de có-
digo; la casi totalidad está escrita en PHP, con algunos elemen-
tos en Perl y sh. A este cómputo faltaría agregar las líneas en
JavaScript, las cuales representan un porcentaje bajo, pero que Librería Función Mod Tamaño
resulta de interés al considerar el porcentaje de reutilización. (SLOC)
Se utilizó la aplicación Practiline source code line counter
para determinar el tamaño del código JavaScript total. De este midos Zip
modo se obtuvo que esta versión de Moodle incluye 14597
líneas. A esta suma se debe agregar código en C, debida a la Bibliotecas Conjunto de biblioteca 5270 (PHP)
utilización de la librería MimeTex. Esta librería se distribuye PEAR con utilidades PHP,
con Moodle en formato ejecutable, además del código fuente, como la escritura en
con el objetivo de garantizar el carácter multiplataforma. Para formato CSV, presen-
este elemento, SLOCCount computa 56632 líneas de código. taciones DHTML, en-
Será necesario considerar a continuación la incidencia de la vío de correo, etc.
reutilización en la estimación del tamaño.
PHP Mark- Conversor de formato Sí 1127 (PHP)
down Markdown a XHTML
4.2 Los componentes reutilizados
En el sitio de Moodle, en la página mencionada anterior-
mente, se detalla la lista de librerías externas utilizadas por Snoopy Cliente de red en PHP 849 (PHP)
Moodle. Además, se reconoce cuáles han sufrido modificacio-
nes para su incorporación a Moodle, en la tabla 1 se puede Typo3 Clase para convertir 3104
observar dicha información. entre juegos de caracte-
res
Librería Función Mod Tamaño
(SLOC)
Tabla1: Librerías externas utilizadas por Moodle [10]
ADODB Biblioteca de abstrac- 24087 (PHP) Considerando el total de las líneas de código contadas, se
ción de base de datos obtuvo:
Total de líneas de Moodle: 302.438 LDC
FPDF Biblioteca para crear 2034 (PHP) Líneas de reuso sin modificaciones: 95.292 LDC
archivos en formato Líneas de reuso con modificaciones: 18.055 LDC
PDF Total de líneas nuevas: 189091 LDC
Total de líneas de reuso: 113.347 LDC (37.48% del
Graph Class Biblioteca para dibujar Sí 1353 (PHP) total)
puntos, líneas, gráficos Porcentaje de componentes automáticamente trasla-
de barras, etc. dados: 84.08 %
Porcentaje de componentes reutilizados modificados:
html2text Script para convertir Sí 96 (PHP) 15,92 %
contenido en HTML en Se puede observar que las líneas de código reutilizadas mo-
texto plano dificadas representa sólo el 15,92% del reuso. Esto implica una
reducción considerable del tamaño total, como se verá en la
HTMLArea Editor HTML online Sí 1359 (PHP) + siguiente sección.
104 (Perl)
+7008 (JS)
4.3 Tamaño con reutilización
COCOMO II considera el tamaño total a partir de dos su-
TinyMCE Editor HTML online Sí 6835 (JS) +
mandos: la cantidad de líneas de código nuevas y las reutiliza-
173 (PHP)
das, considerando el trabajo que hubiera requerido la adapta-
ción de ese código. Con el fin de realizar dicho cálculo, se con-
Kses Filtro XHTML que 291 (PHP) sideró, para KNSLOC, 189.10 KLDC, para KASLOC, 113.35
permite sólo ciertos KLDC, y respecto de AT:84.08% según lo que se detalló en la
atributos sección anterior.
• AA: 2 ya que la incorporación de estas librerías requie-
mimeTex Filtro para convertir de 56632 (ANSI ren en su mayoría de Búsqueda y documentación de
Tex a GIF C) Módulos Básicos.
• CM: 20 lo que representa el promedio estimado de las
overlibmws Biblioteca para incor- 605 (JS) modificaciones de código requeridas. Dado que la do-
porar efectos DHTML cumentación de COCOMO no especifica una técnica
para determinar esta cantidad se estimó la proporción
mp3player Reproductor MP3 ActionScript equivalente a escribir el código desde cero.
• DM: 0 al considerar que no hay modificaciones de di-
PclZip Biblioteca para mani- 2420 (PHP) seño.
pular archivos compri-
 • 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 consi-
deradas ninguna presenta grandes deficiencias en cuan-
to 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 mode-
lo 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 modifica-
das. Estas son: GraphClass, HTMLArea, TinyMCE,
HTML2text y PHPMarkdown.
Como indicador de las dificultades de la integración, se con-
sideraron los errores reportados en Moodle Tracker, el sistema
de seguimiento y resolución de errores de que dispone el pro-
yecto. 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 pe-
simista 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
0.6993756
4.5 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 esca-
la, 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 1.17
4.6 Volatilidad de los Requerimientos (RVOL)
COCOMO II utiliza este porcentaje para ajustar el tamaño efi-
caz del producto. RVOL refleja la volatilidad de los requisitos
en un proyecto; es el porcentaje de código desperdiciado debi-
do a la volatilidad de los requisitos. En nuestro caso, dicho
porcentaje es cero ya que se consideran fijos a los requerimien-
tos, 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 desarro-
llo 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 de-
sarrollo 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. Rea-
lizando 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 desarro-
llar 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ásti-
camente; 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,
1995.
[2] Wheeler, David A. More than a Gigabuck. Estimating
GNU/Linux Size. Julio de 2002.
http://www.dwheeler.com/sloc.
[3] Spinelli, Diomidis y Szyperski, Clemens. How is Open
Source Affecting Software Development?. IEEE Software.
January/February 2004.
[4] Hissam, Scott y Weinstock, Charles. Open Source Soft-
ware: The Other Commercial Software. SEI-CMU
[5] Brooks, Frederick. The Mythical Man Month, Aniversary
Edition. Addison-Wesley, 1995.
[6] González- Barahona et al. Counting Potatoes: The size of
Debian 2.2. http://people.debian.org/~jgb/debian-
counting/counting-potatoes/
[7] De La Fuente Moya, Antonio. COCOMO v2 - Modelo de
Estimaciones de Costes para proyectos software. Escuela Su-
perior 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 Kauf-
man Publishers. 2005.
[9] Raymond, Eric. The Cathedral and the bazaar.
http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-
bazaar/.
[10] Créditos de Moodle- http://docs.moodle.org/en/Credits.
Ültimo acceso: 15/07/07
[11] Arquitectura de Moodle:
http://docs.moodle.org/es/Arquitectura_de_Moodle. Último
acceso: 20/07/07