11. *******TEMA DE DISCUSION*******

Ingeniería del Software Libre. Una visión alternativa a la ingeniería del software tradicional

INTRODUCCION:

Desde hace cuatro décadas, la ingeniería del software se ha venido consolidando como una rama importante dentro de la informática en busca de métodos de desarrollo y técnicas que permitan producir software de gran calidad con unos recursos limitados. Según la definición del IEEE, la ingeniería del software es "un enfoque sistemático y cuantificable al desarrollo, operación (funcionamiento) y mantenimiento del software: es decir, la aplicación de la ingeniería del software". [IEEE 1993]
A pesar de que la ingeniería del software ha conseguido indudablemente notables éxitos, también es cierto que ha sucumbido a lo que se ha venido a llamar la "crisis del software". Prueba de ello es que a día de hoy todavía sigue sin ser posible cuantificar con exactitud los plazos, costes, recursos humanos y técnicas que lleven a un desarrollo exitoso del software, tal y como otras ramas de la ingeniería en otros campos sí han sido capaces de hacer. Es más,incluso en algunos puntos de la ingeniería del software se puede observar una tendencia a retomar viejos caminos bajo nuevas fórmulas, como podemos ver con la incipiente expansión de las técnicas de programación evolutiva que se basan en gran parte en principios y técnicas conocidos y usados en la década de los 70. Argumentar que la ingeniería del software se encuentra estancada y falta de ideas es una consideración que, por lo tanto, podemos tomar como muy válida.

La crisis de la ingeniería del software tradicional
Uno de los grandes problemas de la ingeniería del software ha sido y es que no ha sabido adaptarse consecuentemente a su propia definición. Esto es algo que se puede considerar como una especie de traición a sí misma, a sus propios fundamentos. El enfoque sistemático y cuantificable ha tenido siempre como barreras las propias de las formas en las que el software se ha desarrollado y distribuido. El formato binario del software, la opacidad en los modelos de negocios, los secretos y barreras comerciales se encuentran entre las principales causas que han imposibilitado estudios cuantitativos y cualitativos a gran escala del software cuyos resultados pudieran ser verificados sistemáticamente por equipos de investigación independientes. Las "verdades" que han sido enunciadas son, con frecuencia, experiencias puntuales que han sido generalizadas y dadas por válidas ante la falta de alternativas. La propia forma de desarrollar,distribuir y comercializar software ha sido la que ha llevado a la ingeniería del software a la crisis. Y es aquí donde el software libre puede dar nuevos aires a la ingeniería del software. Desde hace más de una década, el software libre ha venido experimentando un gran auge en cuanto a uso, aceptación y, por supuesto, desarrollo. La implantación de Internet junto con las características de las licencias que "invitan" a todo el mundo a formar parte del equipo de desarrollo, han propiciado que a día de hoy no sólo podamos contar con el código fuente (un gran avance para su estudio en contraposición al del software propietario), sino tomar medidas de los archivos de las listas de correo donde viene plasmada la comunicación del proyecto, los repositorios de versiones gracias a los cuales podemos ver la evolución, etc. De todas estas fuentes se puede extraer una gran cantidad de información de interés, en la mayoría de casos incluso de manera automática. Por tanto, el software libre ofrece la oportunidad de conocer más a fondo el proceso de concepción de software, aportándonos nuevas evidencias y experiencias.
Podemos concluir que la apertura tanto del código como de la información asociada al proceso de desarrollo que ofrece el software libre es clave para que pueda ser analizado, estudiado y discutido de manera totalmente contrastable y abierta.

Ingeniería del software tradicional e ingeniería del software libre
Este nuevo enfoque de la ingeniería del software no es ni mucho menos contradictorio con el tradicional que todos conocemos; es más, se puede considerar que ambos son compatibles, incluso complementarios. Esto viene a significar que la nueva perspectiva puede ser utilizada para comparar dos técnicas de programación diferentes, ayudando a sacar conclusiones cuantitativas (e incluso cualitativas). Es muy probable que estos resultados puedan ayudar a mejorar esas técnicas, al mismo tiempo que nuevas técnicas pueden implicar nuevas medidas. No se trata de decir que lo que conocemos en la actualidad como ingeniería del software no sirve para nada o está condenado al fracaso, sino de abrir nuevos caminos y nuevas formas de proceder que, en paralelo con las ya existentes, amplíen nuestro conocimiento sobre los métodos de creación, funcionamiento y mantenimiento del software.
Y es que, como se discutirá a continuación, mediante el análisis del software libre se ganan una serie de factores que difícilmente ha podido conseguir la ingeniería del software tradicional. El primero de ellos es la vertiente temporal que se añade al análisis. Y es que no se puede olvidar que el proceso de creación de software ha cambiado según han cambiado los paradigmas tecnológicos, de educación, de programación,etc. Algo que se enunció hace 30 años puede ser muy válido en la actualidad (o no), aunque no cabe duda de que es muy probable que necesite ser adaptado e incluso mejorado. De la evolución histórica se puede sacar mucha e
interesante información, y no solamente de carácter técnico. Para muchas decisiones es de gran importancia saber los lenguajes de programación en alza, la evolución en cuanto a colaboradores de ciertos proyectos (por ejemplo, de proyectos que se dediquen a crear aplicaciones p2p), etc. Mediante un análisis temporal continuo estaremos en disposición de tener un termómetro permanente de lo que está ocurriendo en el mundo del software (libre).
Por otro lado, el análisis de software libre no plantea problemas de granularidad. La ingeniería del software se ha basado con frecuencia en el análisis de unos pocos proyectos de software debido en gran parte a la facilidad de acumular experiencias en entornos corporativos propios. COCOMO, un modelo de cálculo de costes y tiempos para proyectos software, es un claro ejemplo de esto, ya que fue creado en un departamento de la NASA a raíz de la experiencia en poco más de un centenar de proyectos. Mediante el uso de información extraída del software libre estamos capacitados para obtener un (nuevo) modelo del tipo "COCOMO", pero mucho más global (o dependiente del lenguaje de programación o de otras circunstancias) a la vez que más ajustado a la realidad actual. Incluso,añadiéndole la vertiente temporal como se ha indicado en el párrafo anterior, podríamos ver la evolución de este
modelo en el tiempo.
Tomando como analogía las ciencias económicas, podríamos decir que con el método COCOMO estamos hablando de un microanálisis. Por otra parte deberíamos tener, por tanto, el macroanálisis, que trataría de cuantificar y estudiar el software a gran escala. Este análisis ha sido históricamente ignorado por la ingeniería del software tradicional y es el software libre el que da la posibilidad de que se pueda ver la evolución de muchos parámetros. Así se facilitará información relevante a la hora de tomar decisiones en entornos empresariales y en proyectos de software libre.
Gracias a la ingeniería del software libre será posible, por consiguiente, medir un proyecto dentro de entornos cerrados(microanálisis) y globales (macroanálisis) de manera simultánea, lo que puede ser de gran ayuda para medir la salud del mismo. Por ejemplo, se podría analizar Evolution, el cliente de correo más completo del entorno GNOME, dentro del propio proyecto GNOME que engloba unos 200 proyectos y mil colaboradores y dentro del resto de software(libre) en general. Esto nos dará información desde dos puntos de vista que,enriquecerán el enfoque.

Concretamente, en entornos de software libre, no existe una forma “tradicional” de gestionar un proyecto. Un buen ejemplo de ello es el artículo de Eric S. Raymond, “La Catedral y el Bazar”, en el que se describe la forma tradicional de gestionar un proyecto como analogía de construir una catedral, y se compara la forma como se gestionan muchos proyectos de software libre al funcionamiento de un bazar.
[ver enlaces anexos]

Proyectos grandes de software libre, como el desarrollo del núcleo Linux o el servidor web Apache, están formados por un comité de gestión del proyecto (o una sola persona como dictador benevolente) que deciden los siguientes pasos que habrá que llevar a cabo en el proyecto, y que inmediatamente delegan en otras personas o equipos los cambios que hay que realizar para llegar a los objetivos. La aprobación de los cambios realizados o bien la incorporación de nuevas funcionalidades propuestas por los usuarios u otros desarrolladores sigue el proceso inverso hasta llegar al comité de aprobación que decide si se incorporan al proyecto o no.

---

Segunda entrega

---

Software libre e ingeniería del software libre

La ingeniería del software libre no sólo pretende ser beneficiosa
para la ingeniería del software; también lo pretende ser, en gran medida, para el software libre.
Si los cálculo de plazos y de costes en los proyectos de software estudiados tradicionalmente (en su gran mayoría de software propietario) son difícilmente cuantificables, en la actualidad en el mundo del software libre son prácticamente utópicos. En cierta medida, la ingeniería del software libre pretende desposeer de esa "magia" que parece que es intrínseca a los desarrollos de software libre y cuantificar unos parámetros que nos permitan predecir con exactitud costes, plazos y recursos humanos. Como consecuencia, aunque podemos considerar que en la actualidad el software libre adolece de estos métodos en contraposición a las formas de desarrollo tradicionales,pero también es cierto que no le falta precisamente potencial para que esta situación cambie en el futuro.
Igualmente pretende ser una forma de introducir las virtudes de la ingeniería del software en el desarrollo a veces demasiado anárquico de software libre. Será tarea de la ingeniería del software encontrar formas para que los desarrolladores de software libre produzcan software de gran calidad siguiendo paradigmas de creación, producción y mantenimiento que así lo certifiquen. Discusiones sobre la recomendación sobre si el software libre debería adoptar UML para la especificación de documentos, debería seguir metodologías evolutivas o formas de desarrollo que desemboquen en software con calidad ISO 9000, son interesantes pero van más allá de lo que este artículo pretende abarcar. Aún así en un futuro seránn parte indispensable dentro de la ingeniería del software libre.

La ingeniería del software libre también pretende acabar con muchas afirmaciones
pseudo-científicas, casi bordeando la fantasía, de muchos ensayos sobre software libre. A la vez se busca poner fin a muchas teorías especulativas y prejuicios fundamentados en apreciaciones propias y/u opiniones personales difícilmente contrastables y, generalmente, con escasa finalidad práctica. Estamos ante la posibilidad de analizar el pasado y el presente para poder predecir el futuro con mayor precisión. Las discusiones se deben basar en datos objetivos y
contrastables y no en elucubraciones o percepciones parciales de la realidad. Si retomamos el símil de la economía, lo que se está haciendo en demasiadas ocasiones es hablar de la economía de un país sin ni siquiera mirar los datos macroeconómicos. Esto, por lo que cualquier economista se llevaría las manos a la cabeza, es bastante común en la actualidad en las previsiones sobre las tendencias del software en general y del software libre en particular.
La ingeniería del software libre cuenta como objetivo a corto plazo poder realizar un análisis completo al desarrollo de software libre que permita indagar profundamente en los procesos que están involucrados, así como en las consecuencias que ciertas acciones tienen sobre el conjunto del desarrollo. Por otra parte, se pretende tener en un espacio de tiempo corto una adaptación de modelos de previsión de costes como lo es COCOMO en el software propietario.
En estos primeros pasos también se quiere llamar la atención de otros grupos de investigación para que se den cuenta de la importancia que puede llegar a tener y ayuden en el avance de la misma. Asimismo, muchos investigadores de los campos de la economía, sociología psicología seguro que pueden estar interesados en estudiar esta forma tan vanguardista de desarrollo software en la que no están del todo claras las relaciones sociales y económicas que se establecen.
Aunque hablar de objetivos a largo plazo en este momento puede parecer premeditado, me
atrevo a decir que, en mi opinión, la ingeniería del software libre tiene tanto que ofrecer que puede resultar una rama clave para sacar de la crisis a toda la ingeniería del software tradicional.
Utilizando símiles históricos, la situación que se vive en la actualidad en la generación de software libre concuerda con la que describió de la economía Adam Smith hace casi tres siglos.
Smith constató que existían unos parámetros económicos claros (oferta y demanda), unas
formas de interaccionar (transacciones) y consecuencias económicas palpables. Sin embargo,no entendía el modelo general que hacía que todo tuviera sentido y funcionara conjuntamente.
Lo que hacía que oferta y demanda cuadrasen era para él literalmente una "mano negra", que más tarde se dio a llamar mercado. Hoy en día todos los ciudadanos, aún sin comprenderlo completamente, tenemos más o menos una idea intuitiva de lo que es un mercado.
Gracias a la definición de mercado y a la investigación de los elementos que lo componen, las ciencias económicas han dado un paso de gigante que junto con la revolución industrial ha llevado a un bienestar en los países industrializados nunca imaginado.

En cierto sentido, esta situación se vive hoy en día en el software libre, donde nos encontramos con que existe una especie de "mano negra" que hace que mágicamente se genere software libre. Sin embargo, es necesario llegar a conocer con mayor profundidad las complejas interacciones para poder comprender lo que está sucendiendo y llegar a predecir el futuro.
También debe servir como punto de partida de acumulación de experiencia, ya que la ingeniería en realidad no es otra cosa que un conjunto de experiencias exitosas debidamente empaquetadas para poder ser reproducidas una y otra vez.

Hacia un sistema de medición y análisis de software libre
La medición y el análisis de datos relacionados con el desarrollo de software libre se hace imprescindible para alcanzar los objetivos que la ingeniería del software libre persigue.
Además, es de capital importancia que los procesos que se desarrollen puedan ser verificados por terceras personas, por lo que las herramientas utilizadas deberían tener una licencia de
software libre.
Para hacer la medición y el análisis lo más versátil posible, se han diferenciado varias etapas,tal y como se puede observar en la (gran) figura al final de este punto.
Es importante denotar que todos los datos provienen directa o indirectamente de parámetros y características de software libre. Esto se debe a que suelen ser accesibles gracias a que se tiende a seguir un modelo de desarrollo lo más abierto posible. Mediante el uso de varias herramientas independientes entre sí se pretende obtener los datos de diferentes fuentes.
Es importante que los resultados de las diferentes herramientas se almacenen en un formato intermedio e independiente de las mismas. De esta forma, la segunda fase se facilita sobremanera, ya que los datos almacenados en ese formato intermedio podrán analizarse convenientemente por medio de herramientas realizadas al efecto o, si es necesario, pueden ser fácilmente convertidos en otro tipo de formatos.
Mientras que el objetivo de la primera fase era extraer el mayor número de parámetros
cuantificables, la segunda fase es un terreno aún por explorar; desde el simple análisis directo de los datos hasta la utilización de complejos algoritmos estadísticos que permitan ir conociendo más a fondo el software libre.
Antes de mostrar pormenorizadamente las herramientas existentes para las cada una de las fases, se debe mencionar que aún cuando la arquitectura completa del sistema puede parecer compleja, esto no es así. Existe una gran modularidad e independencia y el "pegamento" que da sentido a todo esto es la capa donde viene especificado que los datos se almacenarán en un formato intermedio e independiente. Esto quiere decir que una aplicación de extracción de parámetros de código fuente es totalmente independiente de otra que toma datos debidos al
desarrollo distribuido. Es más incluso lo es de otra que también se encarga de estudiar el código fuente. Lo que debe preocupar a las aplicaciones es ofrecer sus resultados en el formato intermedio, haciendo uso de filtros si es conveniente realizar conversiones a otros formatos..

---

Tercera entrega

---

Extracción de datos (Primera fase)
El primer paso engloba agrupar, ordenar y analizar convenientemente el código fuente y los flujos de información existentes en los proyectos de software libre. La finalidad principal es conseguir que todo esto se haga lo más
automáticamente posible. En realidad, se pretende recabar todo tipo de información para poder ser analizada y estudiada detenidamente con posterioridad. Como se ve, se trata de un proceso iterativo, ya que los resultados de los primeros análisis nos dirán por dónde seguir buscando y cuáles deben ser los siguientes pasos lógicos dentro del estudio del software libre.

Código Fuente
El código fuente es, con diferencia, el mayor continente de información en cuanto al desarrollo de proyectos de software libre se refiere. De él se pueden extraer no sólo parámetros globales como el tamaño, el número de ficheros, sino que puede ser investigado con la finalidad de encontrar parámetros de participación (número de desarrolladores), de programación (lenguaje de programación, además de ofrecer la posibilidad de utilizar diferentes métricas de programación), de líneas de código (tanto lógicas como físicas), número de comentarios, etc. etc.

Una de las primeras aproximaciones existentes a día de hoy es el cálculo del número de líneas físicas de proyectos de software libre y el uso del modelo COCOMO (clásico) para obtener resultados en cuanto al tiempo, al coste y a los recursos humanos necesarios para su desarrollo. Evidentemente, este primer análisis se encuentra en una fase bastante primitiva, pero la correlación con otras fuentes permitirá mejorar (y/o adaptar) los resultados en el futuro.
Existe en la actualidad una gama de herramientas que permiten realizar parcialmente estas tareas. SLOCcount reconoce el lenguaje de programación utilizado, cuenta líneas de código (físicas) y hace una estimación aproximada de los costes y el tiempo que el desarrollo ha supuesto mediante el uso de COCOMO. Por su parte, CODD recorre todos los ficheros con código fuente y asigna autoría a las personas que lo han desarrollado. A estas dos aproximaciones habría que sumar la información que pueden proporcionar diferentes métricas de software.

CODD
CODD es una herramienta diseñada por Vipul Ved Prakash y Rishab Aiyer Ghosh que analiza el código fuente de los paquetes de software libre y asigna cuotas de autoría (en bytes) a los que han participado en el desarrollo. También ha sido diseñada e implementada para extraer y resolver dependencias entre paquetes como se verá a continuación.
CODD consta de una serie de procesos que han de ejecutarse de manera consecutiva y que guardan sus resultados en ficheros denominados codds (en minúsculas). Para cada paquete de software libre se generará un codd, que contendrá información sobre el mismo, ya sea extraida del propio paquete o de la correlación con codds de otros paquetes.

Al final del proceso, cada codd debería contener la siguiente información:
->nombre del paquete, generalmente más versión (p.ej. evolution-0.13)
->créditos de autoría (y bytes de contribución)
->archivos de código
->archivos de documentación
->interfaces
->código compartido
->implementaciones externas o no resueltas
->implementaciones resueltas
->metainformación

Es importante ver que los codds se crean en la primera iteración con información que extraen directamente de los paquetes. Como todos los resultados de los procesos intermedios se guardan en el mismo codd, no podremos saber a simple vista en qué paso dentro del algoritmo de CODD nos encontramos. La única forma de saber esto es por inspección del contenido del codd.
El proceso que sigue CODD para obtener estos datos es la que se muestra en la siguiente figura:



Extracción de ficheros: La subrutina init toma el paquete (o paquetes) que se le ha pasado por la línea de instrucciones, lo descomprime y explota si es necesario, e intenta identificar recursivamente el tipo de ficheros que contiene el paquete.

Selección de ficheros: Se toman los archivos de código, de documentación, interfaces e implementaciones no resueltas junto con su tamaño en bytes, su suma MD5 y su ruta relativa dentro del paquete. Esto se hace comparando las extensiones de los archivos del paquete.
CODD contiene una serie de arrays en los que están almacenadas las extensiones que pueden tener los archivos de código (p.ej. ".c" para C o ".pl" para Perl), de documentación, etc. CODD almacena como interfaces aquéllos archivos ".h" que tienen un archivo ".c" en el paquete (el algoritmo que se usa aquí depende parcialmente del lenguaje de programación que se esté analizando). Las llamadas a interfaces en archivos de código (p.ej. ".c" para C) que no tengan su correspondiente interfaz en el paquete (p.ej. ".h" para C) pasarán a englobar la categoría de implementaciones no resueltas, que en futuros pasos dará pie a la resolución de dependencias.

Base de datos de dependencias: En el tercer paso se crean dos bases de datos para encontrar código compartido y dependencias. En la primera, de nombre ’codefile_signatures’, se almacenan todas las sumas MD5 de los ficheros de código. Para ello, CODD se recorre todos los codds, mira en las entradas correspondientes a los ficheros de código y añade un par (suma MD5 y nombre de fichero, paquete). Del mismo modo insertará pares para los interfaces en la
base de datos de nombre ’interfaces’. En este caso, los pares son del tipo (nombre de fichero, paquete).

Código compartido: En el siguiente paso, CODD recorre otra vez todo los codds y mira si los archivos de código aparecen más de una vez en la base de datos (en realidad, si coinciden su nombre y su suma MD5). Si esto ocurre, el archivo se encuentra como mínimo en dos paquetes, por lo que se añadirá en la sección del codd dedicada al código compartido (’shared’) la siguiente información por cada paquete que también contenga el fichero: (fichero de código, ruta, MD5, tamaño) => nombre del paquete.

Resolución de dependencias: CODD realizará un proceso parecido al punto anterior para la resolución de dependencias. Buscará las implementaciones no resueltas en los codds y comparará sus sumas MD5 con las que hay en la base de datos de interfaces. Si hay coincidencia, el interfaz se borrará de la sección de interfaces no resueltas (’unresolved interfaces’) a la de interfaces resueltas (’resolved’). Además, se proporcionará una lista con todos los paquetes en los que está implementada.

Búsqueda de autores: Es entonces cuando CODD realiza la tarea que ha hecho que sea
conocido: la búsqueda de autoría (’ownergrep’). Para ello, recorre todos los ficheros de código y documentación cuya ruta está almacenada en cada codd y extrae, siguiendo ciertos algoritmos de comparación de patrones, a los autores. La información sobre los autores se almacenan en la sección de créditos (’credits’) del codd.

Resolución de código compartido: En la sección del código compartido (’shared’) del codd tenemos todavía ficheros y una lista de paquetes que también lo tienen. Como este fichero sólo puede ser asignado a un paquete, lo que hace CODD es buscar por su autor (’ownergrep’) en el propio fichero y asignarlo al paquete del cual el autor es el autor principal.
Los últimos bloques de la figura muestran que los codds deberán ser entonces transformados a un formato intermedio e independiente en XML a partir del cual se pueden realizar ya técnicas de análisis, correlación o clustering como veremos más adelante en este artículo. Como se puede ver de la figura, existe una herramienta de transformación de codds a SQL, que realiza también tareas de normalización de las tablas. Esta herramienta ha sido concebida para crear CODDWeb, una interfaz web para poder visualizar los resultados de CODD a través del navegador.

CODD es una herramienta muy potente, aunque tiene algunos puntos flacos. El más importante es que todavía no tiene ninguna forma de agrupar las diferentes formas en las que aparece un autor. Por ejemplo, Miguel de Icaza aparece varias veces con diferentes nombres o direcciones de correo. Aglutinar todas sus referencias en una única sería lo más correcto. En este sentido, se está creando una base de datos con relaciones 1 a N por autor.
Por otra parte, el proceso de ejecución de CODD no es lo más simple que podría ser. Carece de un buen sistema de configuración, hay que ejecutarlo como superusuario y la secuencia de procesos que hay que ejecutar no está agrupada bajo un único guión de shell, sino que hay que correrla de manera manual.

Intercambio de información directa entre desarrolladores
El intercambio más importante de información no incluido en el código corre a cargo de listas de correo electrónico, canales IRC y documentación. En el caso de las listas de correo-e, los mensajes son almacenados en archivos que deben ser analizados. En cuanto a la documentación y al IRC todavía no está muy claro lo que buscamos y sobre todo, cómo hacerlo de forma automática.
Para nuestro acometido existe una herramienta llamada MailListStats que analiza estadísticamente la participación en las listas de correo. Existen también herramientas que analizan las bitácoras de los canales IRC.

Herramientas de desarrollo distribuido
El desarrollo de software libre se basa en gran parte en unas herramientas que permiten sincronizarse con el trabajo de los diferentes desarrolladores del proyecto, de manera que la distribución geográfica no suponga un problema. Los
sistemas de control de versiones y los gestores de erratas (también usados ocasionalmente para tareas de planificación), se han convertido en herramientas imprescindibles para proyectos de software libre grandes, y no tan grandes. Estos
sistemas suelen registrar las interacciones con los desarrolladores y, por tanto, una vez que se consiguen estos registros puede monitorizarse de manera bastante sencilla todo el proceso de desarrollo.
El análisis de las bitácoras del CVS mediante la aplicación cvstat2 permite obtener información de la interacción de los desarrolladores con el repositorio. El análisis permite obtener datos por desarrollador, por proyecto y por fichero y todo esto de manera temporal. cvstat2 tiene integrado un interfaz web que permitirá por una parte que muchos proyectos puedan instalarlo fácilmente y ver sus estadísticas y por otra que exista una extracción de datos distribuida.
La otra fuente de información interesante en este punto es obteniendo datos de los sistemas de control de erratas como BugZilla. Del mismo se pueden ver la evolución de las erratas y las diferentes interacciones que existen.

Otras Herramientas
Además de las herramientas ya presentadas, existen otro tipo de herramientas que no entran en la clasificación que hemos seguido y que, por tanto, serán mostradas a continuación.
SFparser es una herramienta que rastrea sitios web que tengan el software de SourceForge instalado. Su acometido es tomar toda la información posible que existe, como por ejemplo los desarrolladores que participan, la categorización del proyecto, si tiene listas de correo y/o usa un repositorio CVS, etc. La misma idea subyace tras el guión FMparser, que realiza idénticas extracciones de Freshmeat. Otras aplicaciones o sitios que pueden ofrecer más datos son apt, el LSM o rpmgraph.

Datos de otras fuentes
A diferencia de los proyectos de software "tradicionales", con el software libre en muchos casos se desconocen los recursos humanos. La situación socio-laboral, económica, geográfica y cultural de los integrantes de los proyectos de software puede ser muy dispar y, a buen seguro, tiene repercusión en la forma en la que un proyecto de software evoluciona.
La forma tradicional para la obtención de estos datos ha sido mediante encuestas, que han permitido obtener una imagen de las personas que están detrás del desarrollo de software libre. El problema que éstas conllevan es que las grandes consultas suelen preservar el anonimato de los desarrolladores, por lo que su correlación con las fuentes presentadas con anterioridad se dificulta sobremanera. Para estudios pormenorizados, como sería en el caso de comunidades en torno a proyectos concretos (GNOME, KDE, Linux, Apache...), se podrían conseguir y estudiar datos sobre la situación laboral y personal de los desarrolladores. Esta información podría utilizarse en los microanálisis para ver el grado de participación de profesionales en el desarrollo, cómo se dividen las funciones, etc.

Formato intermedio e independiente
En un principio, se intentará que todas las herramientas utilizadas devuelvan los resultados en un formato intermedio e independiente de forma que se pueda aglutinarlos de manera sencilla aún proveniendo de diferentes herramientas. El
formato elegido debe ser muy flexible, ya que puede que en un futuro próximo se le añadan más parámetros. A día de hoy, lo mejor sería utilizar un formato XML o SQL, ya que cumplen todos los requisitos comentados con anterioridad y además permiten la compatibilidad hacia atrás.
También hay que tener en cuenta que los conversores de XML (SQL) a cualquier otro tipo de formato que se desee no serán muy difíciles de implementar. La conversión es muy importante, ya que se pretende utilizar en la medida de lo posible herramientas ya existentes en la segunda fase, por lo que una adaptación de los datos obtenidos en la primera fase al formato que estas herramientas requieran sería muy conveniente.

Análisis, procesado y visualización de los datos (Segunda fase)
Hemos visto que la primera fase trata la extracción de datos de diferentes fuentes para almacenarlos posteriormente en un formato intermedio que sea independiente de las fuentes y de las herramientas. Esta primera fase, aunque todavía incompleta, se encuentra mucho más madura que la fase que se va a presentar ahora. Parece bastante claro cuáles son las fuentes que se quieren investigar y sólo falta rellenar algunos huecos en las implementaciones para que se dé por acabada.
Una vez que tenemos los datos, se abre ante nosotros un mundo lleno de posibilidades. El volumen de datos del que
disponemos y la carencia de análisis hace que se puedan vislumbrar en un futuro próximo gran cantidad de estudios en lo que se refiere al análisis, procesado e interpretación de los resultados.
Existen varias formas de tomar los datos y analizarlos, aunque seguro que en los próximos tiempos se crearán más. La más elemental es proporcionar un simple interfaz web para poder visualizar los datos de manera tabular y/o gráfica.
Si los datos están en una base de datos, además se pueden ofrecer correlaciones y datos por proyecto o desarrollador.
El siguiente paso lógico es la utilización de herramientas de análisis estadístico que faciliten el estudio de grandes cantidades de datos, así como su correlación. Existen suites para la realización de estas tareas que pueden hacer todo esto un poco más fácil.
Yendo un poco más allá, cabe la posibilidad de realizar un análisis de clusters, ya sea de paquetes o de desarrolladores.
En este sentido se han hecho algunos esfuerzos en los últimos tiempos. Muestra de ello es la aplicación codd-cluster que toma datos de desarrolladores de CODD y crea agrupaciones de proyectos con desarrolladores en común de forma que se pueda llegar a encontrar interdependencias entre diferentes proyectos. Los clusters también pueden
ser utilizados para agruparlos según lenguajes de programación, tamaño, etc. Incluso tomando varios parámetros simultáneamente.

Conclusiones
Empezamos esta ponencia viendo los problemas que tiene la ingeniería del software tradicional, básicamente por su falta de análisis metódicos y sistemáticos. Hemos visto que el software libre cuenta con cualidades innatas para introducir métodos que permitan conocer más a fondo todos los parámetros que influyen en la generación del mismo.
Esta formalización es muy prometedora, ya que el software libre es mucho más difícil de cuantificar que la ingeniería del software tradicional. Por tanto, es probable que el conocimiento del desarrollo de software libre se pueda también dar solución a muchos problemas de la ingeniería del software tradicional. Hemos de recordar en este sentido, que se ha hecho hincapié en que el nuevo enfoque es totalmente complementario al tradicional.
Después de una introducción más bien teórica en la que se ha presentado una declaración de intenciones de la ingeniería del software libre, hemos visto una propuesta de metodología para recabar información de proyectos de software libre.
De esta inmensa cantidad de información se pretende extraer experiencias con éxito que puedan ser replicadas en otros desarrollos.
También se ha mostrado que existen una serie de herramientas para la extracción de datos de diversas fuentes, desde el propio código fuente hasta rastreando páginas web de portales de desarrollo de software. Los datos se almacenarán en un formato intermedio e independiente tanto de la fuente como de las herramientas, para que en una segunda fase, se puedan analizar, correlar, procesar y visualizar de diversas maneras. Esto último abre un campo de consecuencias difíciles de predecir, pero sin lugar a dudas muy ilusionante y prometedor.

ENLACES PRIMERA ENTREGA:
Catedral y el Bazar
Ingenieria del software en entornos de software libre

ENLACES SEGUNDA ENTREGA:
Ingenieria del software en entornos de software libre

ENLACES TERCERA ENTREGA:
La Ingeniería de Software Libre y sus Herramientas Aplicadas a Proyectos Informáticos