Resultados de la investigación de Apache HTTP Server

Siguiendo la metodología detallada en la sección 3, en primer lugar, se ha realizado una investigación de las características de la comunidad de Apache Http Server, detalladas anteriormente. En segundo lugar, se ha llevado a cabo una investigación del sistema de gestión de errores (Bugzilla) y la lista de correo de la comunidad, con el fin de encontrar las prácticas de la Ingeniería de Requisitos en esta comunidad (véase más información en el Apéndice B, sección 10.12 y 10.13).

A partir de estas dos investigaciones sobre las características encontradas de la comunidad y la investigación de las diferentes infraestructuras, se han obtenido los siguientes resultados, dando lugar a la contestación de las preguntas formuladas en la sección 3.1.

Con el objetivo de realizar una lectura fácil de ésta memoria, se recuerda la pregunta formulada junto con su correspondiente respuesta.

- RQ 1: ¿Cuáles son los principales procesos de la Ingeniería de Requisitos llevados a cabo por las comunidades OSS?

Con el fin de obtener el conocimiento sobre los principales procesos utilizados por la comunidad de Apache Http Server para gestionar los requisitos, se han contestado las preguntas más específicas, las cuales se detallan seguidamente:

- RQ 1.1: ¿Cómo obtienen los requisitos del software que realizan las comunidades open source?

En la comunidad de Apache Http Server no existe, referente a lo investigado, ningún método de obtención de requisitos, como hemos podido estudiar en la Ingeniería de Requisitos tradicional. La obtención de requisitos procede de las necesidades directas de los desarrolladores que realizan el sistema Apache Http Server y de los usurarios finales que lo utilizan.

- RQ 1.2: ¿Cuáles son las principales fuentes de requisitos (desarrolladores, clientes, usuarios)?

Según las participaciones observadas en el estudio de Http Server Development Main Discussion List, las principales fuentes de donde proceden los requisitos son las propias necesidades que un desarrollador considera que hace falta en el proyecto de la comunidad y de sus usuarios finales. En el estudio de los mensajes observados, durante un periodo de tiempo determinado, en la Http Server Development Main Discussion List, la mayoría de participantes son desarrolladores (10 participantes) y usuarios finales (7 participantes).

- RQ 1.3: ¿Qué porcentaje de requisitos viene a través de cada fuente?

Según el estudio de los mensajes observados en la lista de correo, comentada en la anterior pregunta, la gran mayoría de mensajes con propuestas de requisitos

Estado de la práctica de la Ingeniería de Requisitos en proyectos de Software Open Source

116

entre un periodo determinado, han sido enviados por los desarrolladores del servidor (71.42%) y de sus usuarios finales (28.58%).

- RQ 1.4: ¿De qué forma las comunidades elicitan y priorizan los requisitos (la toma de decisiones, establecimiento de prioridades)?

En la comunidad de Apache Http Server, existe un responsable del proyecto. Sin embargo, según los datos obtenidos de los estudios de sus infraestructuras, no podemos decir que este líder de proyecto participe en la toma de decisiones final sobre el proyecto de la comunidad. En este caso, los encargados de la toma de decisiones sobre la gestión de los requisitos son el resto de miembros que forman la comunidad, es decir, los desarrolladores y usuarios finales.

En el caso del estudio de la HTTP Server Development Main Discussion List, se ha observado que los usuarios no tienen una forma de dar prioridad y votar una propuesta de un requisito o nueva idea, simplemente lo pueden hacer enviando un mensaje de apoyo sobre ese requisito al mismo tema del foro. En cambio, el bugzilla si que ofrece la posibilidad de introducir una prioridad a la incidencia o nuevo requisito introducido. De esta forma los contribuidores, desarrolladores y el administrador del proyecto pueden tener constancia de las necesidades prioritarias de los usuarios finales.

- RQ 1.5 ¿Cómo se gestionan las peticiones de funcionalidades en la comunidad?

A través del estudio de las infraestructuras de la comunidad, si que existe forma de que los participantes establezcan votos en los requisitos definidos por la comunidad a través del Bugzilla. Sin embargo no se ha encontrado ningún tipo de documentación relacionada con la escritura formal de los requisitos del sistema, sino que estos requisitos los gestionan a través del bugzilla, el cual es accesible a nivel mundial.

Por otra parte, la comunidad genera la utilización de software gracias a la información que proporciona a través de su página principal o a través del repositorio de Ohloh.net en el cual acceden muchos usuarios interesados en el software de desarrollo open source.

- RQ 1.6: ¿Qué prácticas de Ingeniería de Requisitos tradicional se observan? ¿Es posible identificar otras?

En este proyecto no he visto ninguna evolución de la forma de obtener los requisitos como en la Ingeniería de Requisitos tradicional. La mayoría de los procesos o actividades relacionadas con el desarrollo de la comunidad, junto con los procesos de la Ingeniería de Requisitos se realizan en línea a través de Internet. En este caso, la comunidad pone a disposición diversas infraestruc- turas con el fin de establecer las relaciones de trabajo entre los participantes de la comunidad para poder desarrollar el software.

Capítulo 4

117 - RQ2: ¿Cuáles son los principales medios o infraestructuras utilizadas por

comunidades OSS para gestionar los requisitos?

Con el fin de obtener el conocimiento sobre los principales medios o infraestructuras utilizadas por la comunidad de Apache Http Server para gestionar los requisitos, se han contestado las preguntas más específicas, las cuales se detallan seguidamente: - RQ 2.1: ¿Cuáles son las principales infraestructuras para gestionar los

requisitos? (Ej. Listas de correo, grupos de noticias, sistemas de gestión de errores).

Tal y como podemos observar en la Tabla 12, Apache Http Server proporciona una serie de infraestructuras que utilizan para el desarrollo y gestión del proyecto de la comunidad. De todas estas infraestructuras, las principales utilizadas para la obtención de requisitos son el sistema de gestión de errores, las listas de mails, los archivos de mails y las conferencias realizadas por los miembros de la comunidad. Por este motivo, con el fin de encontrar alguna práctica de la gestión de requisitos, se ha realizado un estudio sobre la lista de mail llamada Apache HTTP Server Development Main Discussion List, y el sistema de gestión de errores (Bugzilla).

Primeramente, en el estudio sobre la Apache HTTP Server Development Main Discussion List, se ha observado que sus participantes la utilizan para informar de las necesidades, problemas o errores que tienen con las diferentes versiones que van publicando sobre el proyecto Apache Http Server. Además, también la utilizan para anunciar nuevas versiones del software de la comunidad y anunciar los meetings o conferencias que se van a realizar. Pero realmente los requisitos no los discuten en la lista de correo sino que utilizan el sistema de gestión de errores, llamado Bugzilla, para realizar nuevas propuestas de requisitos e informar de errores en las diferentes versiones del software de Apache Http Server.

- RQ 2.2: ¿Cómo son los requisitos analizados, diseñados (UML, RUP, MDA, MOF, otros) y documentados?

En esta comunidad no he encontrado ninguna información sobre el análisis, diseño y documentación de los requisitos en la web. Además, tampoco he encontrado ninguna explicación de cómo realizan el análisis de requisitos y si utilizan alguna aplicación para el diseño de dichos requisitos. Simplemente, con esta investigación he encontrado como realizan de forma online, los participantes de la comunidad, la obtención de requisitos, su gestión y la gestión de errores.

119

Capítulo 5

5

Análisis de los resultados obtenidos

n esta sección se muestra un resumen de los resultados obtenidos en la sección 4 junto con el análisis global de estos resultados.

5.1 Resumen de los datos obtenidos

Al principio de esta tesis de máster, se planteó el siguiente objetivo:

“Comprender y caracterizar los procesos e infraestructuras utilizadas por comunidades OSS para la elicitación y gestión de requisitos”.

A partir de este objetivo, se ha desarrollado un estudio sobre siete comunidades OSS, en el cual se ha podido observar el tipo de liderazgo, las formas o prácticas de trabajo que realizan al desarrollar respectivamente sus proyectos, así como ver las formas de elicitar y gestionar los requisitos y las infraestructuras utilizadas para poder llevar a cabo toda la gestión de los requisitos. Seguidamente, se va a proceder a la comprobación de los resultados obtenidos en la recopilación de información sobre las 7 comunidades OSS investigadas en esta tesis. Para ello, se han desarrollado las siguientes tablas de resultados, las cuales se adjuntan seguidamente:

- Tabla 13: Resultados de los tipos de liderazgo observados en cada comunidad OSS, según las métricas detalladas en la sección 2.4.1.

- Tabla 14: Resultados de las prácticas de trabajo observadas en cada comunidad OSS, según las métricas detalladas en la sección 2.4.1.

- Tabla 15: Datos obtenidos de las diferentes características relacionadas con la gestión de requisitos observados en cada comunidad OSS, detallados en la sección 4.

Estado de la práctica de la Ingeniería de Requisitos en proyectos de Software Open Source

120

Comunidades   Liderazgo  Observaciones 

Firebug  Organización o  dictador benevolente  (2)  Al tratarse de un proyecto a nivel académico, la comunidad es liderada por dos dictadores que definen un  calendario formal para el proyecto, y realizan la toma de decisiones final, aunque exista una participación en el  proceso de toma de decisiones por parte de los alumnos que desarrollan el proyecto.  Git  Organización o  dictador benevolente  (2)  Git es una comunidad que desarrolla un proyecto liderado por un director, en este caso Junio C Hamano. Sin  embargo, los desarrolladores y contribuidores pueden estar implicados en todas las fases del proceso de diseño  y toma de decisiones realizadas a través de la lista de correo.  Trac  Comunidad con  principios comunes y  reglas formales   (3)  Trac es una comunidad con una organización de gobierno formal liderada por un director de proyectos. Sin  embargo, los desarrolladores, contribuyentes y usuarios finales son los encargados de tomar las decisiones  sobre las funcionalidades del software desarrollado a través de las infraestructuras que pone a disposición la  comunidad.  jQuery UI  Líder   +   organización formal   (5)  La comunidad de jQuery UI está formada por una organización estructurada y liderada por un director de  proyectos. Sin embargo, a pesar de esta organización, los usuarios, desarrolladores y contribuidores del  proyecto toman parte de la fase de la toma de decisiones del proyecto, ya que dichas decisiones son tomadas a  través de las infraestructuras de la comunidad, como son el foro, la wiki y el sistema de gestión de errores, los  cuales utilizan para votar y discutir informalmente los requisitos de las funcionalidades a desarrollar. En este  caso, por eso he catalogado el liderazgo con una nueva dimensión, en este caso 5.  Free Rapid Downloader  Organización o  dictador benevolente  (2)  FreeRapid Downloader es una comunidad formada por un grupo de estudiantes que desarrolla un proyecto  liderado por un director de proyectos llamado Vity. Sin embargo, aunque la última decisión la tenga el director  de proyecto, los desarrolladores y contribuidores también pueden estar implicados en todas las fases del  proceso de diseño y toma de decisiones realizadas a través de las infraestructuras de la comunidad.  Camino  Líder   +   organización formal   (5)  La comunidad de Camino está formada por una organización estructurada y liderada por un director de  proyectos. Sin embargo, a pesar de esta organización, los desarrolladores y contribuidores del proyecto toman  parte de la fase de la toma de decisiones del proyecto, ya que dichas decisiones son tomadas a través de las  infraestructuras de la comunidad, como son la wiki y el sistema de gestión de errores, los cuales utilizan para  votar y discutir informalmente los requisitos de las funcionalidades a desarrollar. En este caso, por eso he  catalogado el liderazgo con una nueva dimensión, en este caso 5.  Apache HTTP Server  Comunidad con  principios comunes y  reglas formales   (3)  Apache Http Server es una comunidad con una organización de gobierno formal liderada por un director de  proyectos. Sin embargo, también clasifico con un 3 el tipo de liderazgo, ya que los desarrolladores,  contribuyentes son los encargados de tomar las decisiones sobre las funcionalidades del software desarrollado a  través de las infraestructuras que pone a disposición la comunidad, como por ejemplo el Bugzilla y la lista de  correo.