Proyecto Fin de Carrera - Universidad de...

Proyecto Fin de Carrera

AITForge:

Gestión de Proyectos Software

Autor: Antonio Domingo Lagares Alfaro

Titulación: Ingeniero de Telecomunicación (Plan 98)

Especialidad: Telemática

Año: 2005

Tutor: Antonio Estepa Alonso

AITForge: Gestión de Proyectos Software

Índice de contenido

1 Prefacio..................................................................................................................6

2 Portales de Desarrollo Colaborativo......................................................................7

2.1 Introducción a los Entornos Colaborativos....................................................8

2.1.1 Hosting de Proyectos de Software Libre (FOSPHost)...........................9

2.1.2 ¿Software Libre y Software de Fuentes Abiertas?...............................10

2.1.3 Prácticas deseables en Software Libre................................................11

2.1.4 El nacimiento de una nueva filosofía de trabajo...................................13

2.1.5 Objetivos de los sistemas libres de FOSPHost....................................14

2.1.6 Principales características de los sistemas FOSPHost........................16

Características intrínsecas..........................................................................16

Características de utilidad...........................................................................17

Características de usabilidad......................................................................18

Características contextuales.......................................................................19

2.1.7 FOSPHost administrados externamente y auto-administrados..........20

Ventajas de los sitios administrados externamente...................................20

Ventajas de los sitios auto-administrados..................................................21

2.1.8 FOSPHost con infraestructura y sin infraestructura.............................21

Propiedades de los sitios con infraestructura.............................................22

Propiedades de los sitios sin infraestructura..............................................22

2.1.9 Controversia entre libertad y seguridad................................................23

3 Comparativa de sistemas FOSPHost .................................................................26

3.1 GForge..........................................................................................................29

3.1.1 Historia..................................................................................................30

3.1.2 Herramientas.........................................................................................31

3.1.3 Requerimientos.....................................................................................36

3.1.4 Características como FOSPHost..........................................................37

3.2 Savane..........................................................................................................40

3.2.1 Historia..................................................................................................41

Antonio Domingo Lagares Alfaro 2


3.2.2 Herramientas.........................................................................................42

3.2.3 Requerimientos.....................................................................................46


3.3 PHProjekt......................................................................................................49

3.3.1 Historia..................................................................................................49

3.3.2 Herramientas.........................................................................................50

3.3.3 Requerimientos.....................................................................................56


3.4 Tabla comparativa........................................................................................59

3.5 Conclusiones................................................................................................64

4 Gestión de proyectos fin de carrera....................................................................66

4.1 Justificación..................................................................................................67

4.2 Análisis.........................................................................................................69

4.2.1 Visión global de la aplicación................................................................69

4.2.2 Requisitos de almacenamiento de información....................................72

4.2.3 Requisitos funcionales..........................................................................77

Casos de uso comunes a todos los usuarios.............................................77

Casos de uso para los usuarios registrados con cualquier rol...................82

Casos de uso para Profesores y Administradores.....................................86

Casos de uso para Administradores..........................................................98

Casos de uso para los alumnos...............................................................106

4.3 Comparativa de las posibles soluciones....................................................111

4.3.1 Gforge.................................................................................................112

Ventajas:...................................................................................................114

Inconvenientes:.........................................................................................114

4.3.2 J2EE....................................................................................................115

Ventajas:...................................................................................................116

Inconvenientes:.........................................................................................116

4.3.3 Elección de la herramienta a utilizar...................................................117

5 Diseño de una aplicación de gestión de PFC a partir de GForge....................118



5.1 Estudio del sistema GForge.......................................................................119

5.1.1 Arquitectura de GForge......................................................................119

Arquitectura del servidor GForge..............................................................120

Front-end...................................................................................................122

Back-end...................................................................................................122

5.1.2 Interfaz con el usuario: PHP...............................................................123

Capa de presentación...............................................................................124

Capa de lógica de negocio.......................................................................125

5.1.3 Sistema autónomo : Cron...................................................................126

5.1.4 Configuración de GForge....................................................................128

5.2 Diseño de un interfaz propia para AITForge..............................................130

5.2.1 Modelo de datos..................................................................................130

5.2.2 Arquitectura de la nueva vista............................................................133

5.2.3 Estructura de directorios.....................................................................136

5.3 Diseño del módulo de solicitud de proyectos............................................138

5.3.1 Seguridad: gestión de roles................................................................139

5.3.2 Gestión de estados de los proyectos.................................................141

5.3.3 Modelo de datos..................................................................................145

5.3.4 Arquitectura del módulo......................................................................146






5.4 Diseño de un módulo de generación de documentos...............................156

5.4.1 Modelo de datos..................................................................................156

5.4.2 Arquitectura.........................................................................................161








6 Batería de pruebas............................................................................................167

6.1 Nueva vista del sistema: AITForge............................................................168

6.1.1 Página principal...................................................................................168

6.1.2 Página inicial de un proyecto..............................................................169

6.1.3 Árbol de proyectos..............................................................................170

6.1.4 Registro de usuarios...........................................................................171

6.1.5 Página personal de usuario................................................................173

6.2 Módulo de solicitud de proyectos...............................................................175

6.2.1 Solicitud de proyecto...........................................................................175

6.2.2 Consulta de solicitudes y asignación de proyectos............................178

6.3 Módulo de documentos oficiales de la ESI................................................182

7 Bibliografía.........................................................................................................186

8 Anexo A.............................................................................................................188

8.1 ¿Qué es FPDF?.....................................................................................188

8.2 ¿Qué idiomas puedo usar?....................................................................190

8.3 ¿Y qué hay de la eficiencia?..................................................................190

8.4 ¿Cómo funciona?...................................................................................190


AITForge: Gestión de Proyectos Software Prefacio

1 Prefacio

“Y ahora... el proyecto fin de carrera”. Después de aprobar la última

asignatura de la titulación de Ingeniero de Telecomunicación, me encontraba en

disposición de comenzar mi proyecto fin de carrera. Disponía de todo el verano y

tenía la intención de que el proyecto no se alargase demasiado en el tiempo. Sin

embargo un hecho inesperado cambiaría repentinamente mi situación; mi

selección para comenzar prácticas en una empresa.

La realización de prácticas en empresas se está convirtiendo en la actualidad en

el principal medio de inserción laboral para los estudiantes de ingeniería a punto

de titularse. Estas practicas restan bastante tiempo a los alumnos, en concreto

para la realización del proyecto, requisito indispensable para obtener la titulación.

Mi trabajo durante seis meses en el desarrollo de aplicaciones web en la empresa

Sadiel S.A. me aportó conocimientos y experiencia en este tipo de proyectos, por

lo que pensé en aprovecharlos para la llevar a cabo mi PFC. En el área de

Telemática de la Escuela Superior de Ingenieros me propusieron una idea muy

interesante: el desarrollo de una aplicación web para la gestión de proyectos fin

de carrera. Implantar un sistema de este tipo suponía para mí un gran reto, ya que

facilitaría a los alumnos del área la realización de sus proyectos.

Tras cuatro meses de desarrollo y esfuerzo, concluyo mi proyecto fin de carrera,

agradeciendo su apoyo incondicional a mi familia y a mi pareja, que siempre han

estado ahí.


AITForge: Gestión de Proyectos Software Portales de Desarrollo Colaborativo

2 Portales de Desarrollo Colaborativo

Hasta hace unos años Internet ha sido considerada como una gran base de

datos de cobertura global más que como un medio para llevar a cabo un trabajo

concreto. En este contexto, las herramientas habituales como el correo electrónico

y las listas d distribución no son capaces de ofrecer un mayor soporte para la

realización de trabajos en grupo a través de la red. Actualmente son muchos los

frentes abiertos para desarrollar herramientas GroupWare que faciliten entornos

colaborativos de desarrollo software a través de Internet, ofreciendo a los usuarios

un amplio abanico de recursos para facilitar el trabajo en grupo.

En los últimos años, el desarrollo de software se ha convertido en una auténtica

carrera, en la que no sólo la capacidad de producción es el factor dominante, sino

que existen otros aspectos de igual o mayor peso como : colaboración,

organización, comunicación, reutilización, compendio de ideas... Cualquier

proyecto de cierta embergadura requiere la participación de varios desarrolladores

que colaboran entre sí para llevarlo a cabo. No obstante, los colaboradores de un

proyecto pueden encontrarse en diferentes lugares geográficos, incluso su

participación puede darse en diferentes fases temporales del proyecto. La

habilidad y destreza individual de cada uno de ellos no repercutirá favorablemente

en el proyecto si la comunicación del grupo no es eficiente. Por ello se hacen

imprescindibles herramientas robustas que faciliten el trabajo en grupo a través de

Internet, aportando un marco que permita tanto la administración de un proyecto

como el intercambio de información entre los miembros del mismo.


AITForge: Gestión de Proyectos Software Introducción a los Entornos Colaborativos

2.1 Introducción a los Entornos Colaborativos

El trabajo colaborativo se define como el proceso mediante el cual un

conjunto de individuos realizan actividades relacionadas con la finalidad de lograr

un objetivo específico, cumplir una meta o compartir una ideología común. Según

la teoría más reciente, el trabajo colaborativo persigue el desarrollo de

conocimientos compartidos, la aceleración de los flujos de información, la

coordinación de flujos de recursos para producir economías de costos y tiempos

en el desarrollo de los proyectos.

El palabra “proyecto” ha alcanzado un significado ambiguo en la actualidad, por

ello conviene recordar en este punto el concepto puritano del término: esfuerzo

temporal que se realiza para crear un producto o servicio único. En efecto un

proyecto tiene lugar en un espacio determinado en el tiempo con una fecha de

inicio y una fecha de fin, y es único en cuanto a que posee elementos o rasgos

que lo distinguen de los productos o servicios ya existentes. Administrar un

proyecto es mucho más que encontrar el camino crítico que conlleva a un buen

término, además exige la planificación temporal del mismo, el reparto de carga de

trabajo mediante la asignación de tareas, la notificación de éstas tareas a los

miembros del grupo de trabajo...

Por todo lo expuesto hasta el momento, se justifica la necesidad de portales

colaborativos que integren toda la funcionalidad necesaria para llevar a cabo la

gestión de proyectos y el trabajo en grupo a través de la web, de manera que

sean accesibles desde cualquier punto geográfico gracias a la globalidad de la red

Internet.



2.1.1 Hosting de Proyectos de Software Libre (FOSPHost)

Un FOSPHost1 consiste en un servidor que aporta la infraestructura

necesaria para facilitar y coordinar el desarrollo de proyectos de Software Libre o

de Fuentes Abiertas en Internet. Uno de los ejemplos de FOSPHost más

conocidos es SourceForge, un portal muy completo que proporciona multitud de

herramientas útiles para las comunidades de desarrollo. No obstante, un

FOSPHost puede consistir simplemente en una lista de distribución de correo o un

servidor FTP que permite la descargar los distintos componentes de un proyecto.

1 Free Open Source Project Host – Host para proyectos libres y de fuentes abiertas


Imagen 1: Trabajo en grupo a través de Internet


2.1.2 ¿Software Libre y Software de Fuentes Abiertas?

“Cuando alguien de otra universidad o compañía deseaba portar y usar un

programa, lo permitíamos con gusto” [OS]

Con estas palabras Richard M. Stallman, miembro del Instituto de Inteligencia

Artificial del MIT (Massashusetts Institute of Technology) y fundador del Proyecto

GNU, describe la actitud que posibilitó la aparición del Software Libre, allá por

1985. Stallman defiende y define una nueva filosofía basada en la libertad para

ejecutar, copiar, distribuir, estudiar, cambiar y mejorar el software. Estas ideas

quedaron plasmadas en el “Manifiesto GNU” [MGNU] y la Free Software

Foundation (FSF) fue creada poco después para coordinar el proyecto más

ambicioso, el sistema operativo GNU/Linux.

Las bases de esta nueva comunidad se pueden resumir en cuatro libertades de

los usuarios del software [FSGNU]:

• Libertad 0: La libertad de usar el programa, con cualquier propósito.

• Libertad 1: La libertad de estudiar cómo funciona el programa, y adaptarlo

a tus necesidades. El acceso al código fuente es una condición previa

para esto.

• Libertad 2: La libertad de distribuir copias, con lo que puedes ayudar a tu

vecino.

• Libertad 3: La libertad de mejorar el programa y hacer públicas las

mejoras a los demás, de modo que toda la comunidad se beneficie. El

acceso al código fuente es un requisito previo para esto.



La comunidad del Software Libre nace para luchar contra el denominado Software

Privativo, aquel cuyo uso, redistribución o modificación está prohibida, o requiere

la solicitud de autorización.

El término Software de Fuentes Abiertas (Open Source Software) aparece dentro

de la comunidad de habla inglesa, para evitar la ambigüedad del término

anglosajón “free” que se puede traducir como “gratuito” en lugar de “libre” [FSOS].

No obstante, en la gran mayoría de las ocasiones Software Libre y Software de

Fuentes Abiertas significan lo mismo.

2.1.3 Prácticas deseables en Software Libre

Un aspecto muy importante a tener en cuenta al plantear un proyecto de

Software Libre es la utilidad que dicha aplicación puede tener. En efecto, un

proyecto surge para satisfacer una necesidad concreta, bien porque no exista

ninguna otra solución o bien porque no sea accesible por motivos económicos o

legales. En previsión de que la necesidad detectada sea extensible a otras

comunidades, es muy conveniente promocionar y dar publicidad a un proyecto ya

que pueden aparecer colaboradores que decidan unirse al mismo.

Por otro lado, pese a que las motivaciones para el desarrollo libre van más allá de

lo económico, es necesario apostar por la calidad del producto. La mejor forma de

atraer a desarrolladores de todo el mundo y conseguir que se unan a la

comunidad del Software Libre es ofreciendo productos de calidad que puedan



competir y sustituir a los productos comerciales que habitualmente se han venido

usando. En la lucha Libre-Privativo no basta con ofrecer software gratis si éste no

alcanza las prestaciones ofrecidas por otro tipo de programas.

El desarrollo de Software Libre persigue el intercambio de conocimiento, la

sinergia de ideas, la reutilización y mejora del software de forma libre, sin

restricciones. No obstante, esa libertad para copiar, modificar y ampliar el código

fuente de un programa no es incompatible con la libre adopción de ciertas normas

de estilo y procedimientos estándar, que mejoran la calidad del software y facilitan

la labor para futuras revisiones. Por ello, el uso de métrica, patrones de diseño y

normas de codificación son prácticas que mejoran y hacen más competitivas las

herramientas libres.



2.1.4 El nacimiento de una nueva filosofía de trabajo

Con la puesta en marcha del Proyecto GNU para la elaboración de un

sistema operativo con licencia GPL2, son muchos los estudiantes de informática

que deciden incorporarse a la nueva filosofía libre y comienzan a colaborar. El

principal problema que se planteó en un principio fue el aprendizaje por parte de

los colaboradores de las bases teóricas de los sistemas operativos. El nuevo

sistema operativo se basaría en Unix, cuyo código no era accesible ya que se

trataba de software comercial sometido a restricciones bajo licencia de AT&T.

Ante esta situación Andrew Stuart Tanenbaum, profesor de la Universidad de

Vrije (Amsterdam) escribió el sistema operativo de tipo Unix llamado Minix, y un

libro3 en el que explicaba todos sus entresijos. Al ser de carácter pedagógico, el

sistema era deliberadamente sencillo y con escasa funcionalidad pero supuso un

punto de partida para sus estudiantes.

En 1991, el estudiante finlandés Linus Benedict Trovalds decidió aplicar lo

aprendido y escribir un nuevo núcleo que superase las limitaciones de Minix y que

fuese capaz de ejecutar las herramientas software generadas en el Proyecto

GNU.

Sin embargo, Linus no sólo se limitó a crear una nueva herramienta software sino

que comenzó una verdadera revolución en la forma de trabajar. Lo que comenzó

siendo un proyecto motivado por mera diversión personal adquiriría un gran

trascendencia gracias a que Trovalds decidió publicar su trabajo en Internet bajo

el nombre de Linux, poniéndolo a disposición de todo aquel que quisiera

estudiarlo y solicitando colaboración.

2 General Public License: Licencia creada por la Free Software Foundation y orientada

principalmente a los términos de libre distribución, modificación y uso de software.

3 Operating Systems: Design and Implementation [OSDI].



Lo revolucionario de Linux no está en su diseño ni en su filosofía (la Free Software

Foundation la predicaba desde hacía cinco años), sino en su metodología.

Efectivamente, hasta entonces el software se escribía en grupos cerrados y de

carácter vertical, hasta que Linus inaugura un nuevo modelo distribuido y abierto,

en el que cualquiera podía participar. Este modelo de programación se conoce

como modelo ”bazar” y durante los últimos años ha demostrado ser el más

eficiente y el que genera productos de más calidad.

2.1.5 Objetivos de los sistemas libres de FOSPHost

Los sistemas FOSPHost se caracterizan por una serie de objetivos comunes

para facilitar la cooperación de un grupo de trabajo. Los más destacados son:

• Facilitar la concurrencia y el desarrollo colaborativo del software.

• Habilitar el desarrollo distribuido para participantes de diferentes

localizaciones geográficas.

• Facilitar la comunicación entre los desarrolladores y permitir la

contribución al proyecto de participantes externos.

• Intercomunicar los diferentes roles de un proyecto (analistas, diseñadores,

programadores, comerciales...).

• Conseguir la mayor eficiencia posible en esa comunicación, mediante el

empleo de las herramientas de trabajo en grupo más actuales.



• Crear un sentimiento de comunidad entre los desarrolladores de un

proyecto.

• Mejorar los procedimientos de desarrollo software actuales.

Consecuentemente, al satisfacer los objetivos descritos arriba, aparecen un gran

número de beneficios inherentes a estos sistemas que se suman a las ventajas

propias que ofrecen estos sistemas de desarrollo. Entre estos beneficios

suplementarios se encuentran los siguientes:

• El proyecto software adquiere carácter mundial, ya que los

desarrolladores de Software Libre de todo el mundo tienen la posibilidad

de contribuir.

• Permiten a los desarrolladores modificar fácil y controladamente el código

fuente del proyecto, sin necesidad de ponerse en contacto con el

administrador del proyecto para realizar los cambios.

• El control de versiones evita posibles bifurcaciones no sincronizadas de

versiones de código fuente, permitiendo a los desarrolladores converger a

una única versión que incluya los diferentes cambios.



2.1.6 Principales características de los sistemas FOSPHost

En este apartado se describen la propiedades deseables de este tipo de

sistemas que, en los puntos posteriores, utilizaremos para realizar la comparativa

entre las distintas soluciones a estudiar.

Características intrínsecas

Estas propiedades se refieren a las tareas de gestión y a las capacidades

administrativas de los propios FOSPHost.

• La administración de los FOSPHost debe respetar los acuerdos de uso

con los usuarios del sistema, dotándolos de suficiente libertad para

trabajar.

• Cualquier entidad que quiera albergar un FOSPHost ha de conocer y

aceptar la responsabilidad que ello conlleva, comprometiéndose a

mantener el sistema libre de anomalías para asegurar que los proyectos

lleguen a buen término.

• Estos sistemas deben ser abiertos, y sus usuarios han de estar

informados de lo que ello supone.

• Hay que incidir en el carácter público de estos portales, proporcionando a

los usuarios tanta libertad como sea posible.

• El aumento del número de servidores o “mirrors” de un portal de desarrollo

incrementa la confianza de los usuarios para utilizarlo.



• Un FOSPHost he de mostrar información actualizada, de lo contrario corre

el peligro de caer en desuso.

• Empleo de técnicas y herramientas de actualidad, para atraer a los

desarrolladores y conseguir que apuesten por el portal.

Características de utilidad

La utilidad se refiere a la funcionalidad que aporta el sitio al desarrollo software.

Las cinco herramientas más importantes en la actualidad son:

• Repositorio de Código Fuente: servidores accesibles por los usuarios para

descargar las últimas versiones de los ficheros fuente del proyecto y subir

los cambios realizados de forma controlada. Existen varias herramientas

libres de gestión de código fuente, pero los más conocidos son CVS y

Subversion.

• Listas de distribución de correo electrónico: esta ha sido desde hace años

la herramienta más utilizada entre las comunidades de desarrollo para

trabajar y en la actualidad sigue siendo una de las más eficientes.

• Servidor web: una facilidad muy interesante para los grupos de desarrollo

consiste en disponer de una página web personalizada para cada

proyecto, de manera que en ella se pueda publicar toda la información

relacionada con los mismos.



• Foros: un portal de gestión de proyectos debe proporcionar la

infraestructura necesaria para alojar foros temáticos de discusión para los

proyectos, en los cuales los usuarios puedan “postear” sus dudas o dar

respuesta a las ya almacenadas.

• Gestión de tareas: esta herramienta es de vital importancia para la

correcta gestión de los proyectos ya que permite repartir las tareas de

forma centralizada, de forma que todos los usuarios puedan conocer qué

tareas se están realizando en cada momento y quienes las están llevando

a cabo.

Características de usabilidad

La usabilidad es la capacidad que la interfaz de estos portales tiene para

satisfacer al usuario en términos de eficiencia, facilidad de aprendizaje, tasa de

errores y severidad de los mismos.

Un FOSPHost debe cumplir con los siguientes requisitos de usabilidad:

• El portal debe ser fiable y estar disponible las veinticuatro horas del día.

• Las herramientas que proporcione deben ser efectivas y productivas al

mismo tiempo que fáciles de usar.

• Estas herramientas deben ser estándar y habitualmente utilizadas en el

desarrollo software.

• El sitio ha de ser actualizado frecuentemente.



Características contextuales

El contexto de un FOSPHost incluye los usuarios específicos de un sitio y el

campo concreto de desarrollo al que se dedican, las tareas y el entorno

sociocultural del sitio. Las características enmarcadas en esta categoría están

relacionadas con en su mayoría con prácticas de trabajo recomendadas y la

cultura existente en torno a una comunidad de desarrollo. Por tanto, estos

conceptos han de ser aplicados individualmente a cada comunidad específica.

• Flexibilidad para los participantes voluntarios.

• Divertimento, buen ambiente y colaboración.

• Mentalidad abierta y política de acceso para nuevos miembros.

• Predisposición para considerar nuevas ideas y aportaciones.

• Tolerancia, respeto y paciencia.

• Sentido de la responsabilidad.



2.1.7 FOSPHost administrados externamente y auto-administrados

Otra clasificación que se suele aplicar a los sistemas FOSPHost distingue

entre aquellos que permiten una mayor participación de los usuarios en tareas

administrativas y los que por el contrario reservan ese tipo de tareas para los

administradores del sitio [FOSPH].

En los sitios auto-administrados los usuarios pueden ajustar la configuración

interna de los servicios que el sistema provee para cada proyecto.

En cambio, en los sitos administrados externamente existe un conjunto fijo de

servicios con una configuración preestablecida por el administrador.

Ventajas de los sitios administrados externamente

• Son más fiables que los portales auto-administrados.

• La calidad y eficiencia de las herramientas suele ser mayor.

• El coste de lanzamiento de un nuevo proyecto de Software Libre es

menor.

• La carga de tareas de configuración respecto a los sitios administrados

individualmente es menor, por lo que permite a los desarrolladores

centrarse en tareas productivas.



Ventajas de los sitios auto-administrados

• Control sobre las herramientas ofrecidas por el portal y sobre su

configuración.

• Mayor flexibilidad.

• Mayor capacidad de adaptación a las necesidades concretas de cada

proyecto.

2.1.8 FOSPHost con infraestructura y sin infraestructura

Los portales administrados externamente pueden a su vez clasificarse en

sitios con infraestructura y sin infraestructura [FOSPH].

Los host con infraestructura son aquellos en los que la mayoría de la información

relacionada con los proyectos que hospedan se almacena en bases de datos y

proporcionan herramientas estándar para el desarrollo.

Por otro lado, en los sitios sin infraestructura no existen sistemas subyacentes de

base de datos sino que los usuarios construyen sus propias páginas HTML para

los proyectos. El portal se limita a actuar como servidor web sin aportar

funcionalidad extra alguna.



Propiedades de los sitios con infraestructura

• Formales.

• Ordenados.

• Énfasis en estructuración y arquitectura.

• Facilidad a la hora de navegar por distintos proyectos al tener todos la

misma estructura.

• Servidores pesados.

Propiedades de los sitios sin infraestructura

• Personales.

• Flexibles.

• Énfasis en las motivaciones individuales de los desarrolladores.

• Servidores más ligeros.



2.1.9 Controversia entre libertad y seguridad

La filosofía libre de los portales FOSPHost se fundamenta en la idea de crear

un marco de desarrollo de proyectos de Software Libre que, como se definió

anteriormente, llevan implícitas una serie de libertades para los usuarios finales de

los mismos.

Sin embargo, la fase de desarrollo de un proyecto libre ha de llevarse a cabo en

un entorno de trabajo que permita cierta seguridad. Los miembro de un proyecto,

que comparten el propósito y la determinación de llevarlo a buen puerto por el

bien de la comunidad, merecen contar con la seguridad de que su trabajo no se

verá perjudicado por agentes externos al proyecto.

Existe la necesidad de salvaguardar las contribuciones desinteresadas de los

desarrolladores frente a manos maliciosas o inexpertas que puedan echar a

perder horas y horas de duro trabajo. Por ello, es deseable que los portales

FOSPHost protejan en cierta medida el código fuente de los proyectos software,

restringiendo la modificación del mismo dentro del servidor a usuarios externos si

fuese necesario. Este hecho no viola en ningún modo el carácter libre del

software, ni siquiera supone la privacidad del código fuente ya que éste puede ser

accedido y descargado por cualquier visitante.

Entre las soluciones más habituales que incorporan los portales de hosting

tenemos:

• Logging.

• Grupos privados o semi-privados de desarrollo para evitar

“colaboraciones” indeseadas.



• Asignación de roles de usuario.

• Gestión de permisos.

• Redundancia de servidores.

• Aplicaciones distribuidas (Separación física de la aplicación servidora y los

datos de usuario).

Esta política de seguridad en los FOSPHost obliga inexorablemente a dotar a este

tipo de portales de mecanismos que permitan a los usuarios llegar a formar parte

de un proyecto como desarrollador. Las vías mas frecuentes para participar

activamente como desarrollador en un portal son:

• Participación en los foros de desarrollo, aportando ideas y soluciones.

• Colaboración en proyectos de “trainning” habilitados en el portal.

• Contacto con los miembros del proyecto mediante corro electrónico.

• Sistemas de puntuación de usuarios.

• Solicitud a los administradores del proyecto.

Formar parte de una comunidad de software libre y participar activamente en el

desarrollo que en ellas se lleva a cabo son actividades que enriquecen las

aptitudes y habilidades de los programadores. Sin embargo los beneficios de

estos portales van más allá del aspecto técnico, ya que fomentan el intercambio



cultural y colaboración entre personas de todo el mundo con un sentimiento

común, la pasión por el Software Libre.


AITForge: Gestión de Proyectos Software Comparativa de sistemas FOSPHost

3 Comparativa de sistemas FOSPHost

Desde que el mundo del Software Libre toma conciencia de la necesidad de

herramientas que faciliten la colaboración en el desarrollo de proyectos han

aparecido numerosos sistemas de FOSPHost desarrollados en diferentes

plataformas y tecnologías. La más conocida de ellas por ser la pionera en su

género es SourceForge, un portal de hosting de proyectos Software Libre creado

por VALinux4 en 1999.

Rápidamente SourceForge se convirtió en la referencia mundial y en la actualidad

ha superado el millón de usuarios y hospeda alrededor de 96.000 proyectos, de

los cuales se realizan más de 1.200.000 descargas cada día.

SourceForge supuso para el Software Libre una metodología de desarrollo

unificada y estándar basada en herramientas modernas. Antes de SourceForge,

dichas herramientas (informe de fallos, cvs, web, soporte, foros, encuestas,

noticias, etc) estaban disponibles de manera individual, pero pocos

desarrolladores las utilizaban conjuntamente, ya que tenían que configurar por sí

mismos las herramientas. SourceForge hizo la combinación de modo conveniente

tanto para nuevos desarrolladores, como para los más experimentados.

La segunda cosa importante que hizo SourceForge fue proporcionar este entorno

de desarrollo basado exclusivamente en Software Libre, en concreto en el

proyecto Alexandría5. De este modo, SourceForge no sólo proporcionó una

4 Actualmente VA Software Corporation

5 Alexandria: sistema colaborativo para el desarrollo de proyectos de Software Libre llevado a

cabo por The Apache Software Foundation



poderosa metodología a la comunidad del Software Libre, sino que además

demostró lo que se puede hacer con Software Libre, y fomentó su uso. Y como el

software de SourceForge era libre, cualquiera podría implementar un sitio web

similar. El software de SourceForge ha estado disponible para los desarrolladores

en cualquier lugar del mundo.

Debido a la gran utilidad de SourceForge, muchos desarrolladores de Software

Libre han incorporado el uso de estas herramientas, ajenos al trabajo necesario

para ponerlas a funcionar en conjunto, y serían reluctantes a volver al viejo modo

de hacer las cosas. Afortunadamente, han aparecido numerosos sucesores que

han tomado la misma filosofía y se presentan como grandes alternativas a

SourceForge. Entre estas alternativas se encuentran:

• GForge

• Savannah

• Savane

• PHProjekt

En agosto del 2001, VA Linux retrocedió en su política e introdujo software no libre

en el servidor de SourceForge [CRS]. Anunciando esto, Larry Augustin (CEO de

VA Linux) como justificación clamó que los usuarios de SourceForge.net

virtualmente no notarían ningún cambio. Sin embargo este cambio implicaba

mucho más: el servidor en el que se alojaban proyectos libres pasaba a

convertirse en privativo, situación que no dejaba de ser paradógica. En lugar de

un ejemplo excelente de Software Libre, SourceForge es ahora una demo de

software no libre que explota la actual VA Software.



Los desarrolladores de Software Libre, todavía son libres de utilizar el servidor de

SourceForge, pero no tienen la libertad de copiar, modificar, estudiar y distribuir el

software que corre dicho servidor; actualmente no existe la posibilidad de

descargar el código fuente actual de SourceForge, por lo que resulta imposible

crear un servidor propio que hospede SourceForge a menos que se adquieran los

derechos pertinentes.

No obstante la comunidad de software libre no podía quedarse de brazos

cruzados ante esta aberración, apareciendo una serie de proyectos que, partiendo

de la última versión accesible de SourceForge, han seguido mejorando y

ampliando su funcionalidad de forma paralela. Estos proyectos son tres de los

mencionados anteriormente: GForge, Savannah y Savane.

El hecho de que actualmente SourceForge sea software privativo lo excluye de

ser considerado en este proyecto fin de carrera, ya que sólo tienen cabida

soluciones de Software Libre. Por ello SourceForge queda fuera de esta

comparativa, dando paso a los proyectos libres que se basan en esta plataforma y

a otros proyectos de la misma naturaleza.


AITForge: Gestión de Proyectos Software GForge

3.1 GForge

GForge es un sistema para el desarrollo colaborativo dentro de la comunidad

del Software Libre. Provee de un sistema de desarrollo completamente

configurable, un sitio web para los proyectos y herramientas para facilitar la

comunicación entre los miembros de un equipo del desarrollo. Estas herramientas

proporcionadas por GForge permiten a miembros del equipo organizar su trabajo

de forma eficiente, favoreciendo la productividad y la calidad del software; además

permite la creación de una biblioteca de conocimiento, mantenida y actualizada

por todos y cada uno de los participantes.


Imagen 2: Esquema funcional de GForge


3.1.1 Historia

GForge es una bifurcación del código de SourceForge 2.61, la última versión

disponible vía CVS anónimo del famoso proyecto después de que VA Linux

decidiera cambiar su política. Tim Perdue fue principal propulsor del proyecto, un

antiguo desarrollador de SourceForge que en el año 2002 decidió tomar su propio

camino al discrepar con la nueva política de VA Linux. Según Perdue, la

bifurcación era necesaria para asegurar la disponibilidad de una versión estable

de fuentes abiertas del sistema base de SourceForge.

Con la creación de un portal propio para GForge6 se pone por primera vez en

práctica el nuevo código. Dicho portal está dedicado exclusivamente a hospedar

el propio GForge y algunos proyectos relacionados, sirviendo como demo para los

usuarios que decidan montar su propio sistema FOSPHost. A comienzos de 2005

el portal cuenta con casi 4000 usuarios y 9 proyectos en desarrollo [GF]. La

funcionalidad de GForge es importante no solamente para la comunidad de

fuentes abiertas, sino que puede ser utilizada incluso por la compañías privadas

como herramienta de trabajo.

La versión 4.0 de GForge fue lanzada el 24 de Octubre de 2004 y se espera la

actualización de los paquetes en el repositorio Debian para mediados de 2005, ya

que actualmente sólo se encuentran disponibles en su versión 3.21.

6 Actualmente se encuentra en la url: http://gforge.org



3.1.2 Herramientas

GForge destaca entre todos los sistemas de FOSPHost por el gran número

de herramientas y funcionalidades que integra. Este hecho y un trabajado módulo

de administración que dota a los administradores del sistema de gran capacidad

de gestión hacen de GForge uno de las opciones más interesantes.

Servidor web

Cada proyecto hospedado en un servidor basado en GForge dispone de un

dominio propio en el que publicar una página web personalizada. GForge genera

una página estándar para todos los proyectos cuando éstos son registrados,

permitiendo a los administradores de los mismos sustituirlas en cualquier

momento.

Control de versiones de código fuente

GForge proporciona un repositorio de gestión de código fuente (SCM) para

cada uno de los proyectos. Actualmente GForge soporta dos sistemas para el

control de versiones: CVS y Subversion.

El sistema integra CVSWeb para que los usuarios puedan navegar por el árbol de

directorios de los proyectos, así como visualizar y descargar los ficheros fuentes.



Los administradores de los proyectos pueden descargar el código fuente en un

tarball7 que se actualiza periódicamente.

Notificaciones por correo electrónico y mensajería instantánea

Los eventos de interés relacionados con los proyectos son notificados por

correo electrónico y por mensajería instantánea (protocolo jabber) a los

colaboradores.

Listas de correo

Para la gestión de las listas de distribución de correo electrónico GForge se

apoya en Mailman, aplicación desarrollada por el Proyecto GNU.

Foros de discusión

Esta aplicación proporciona el soporte necesario para gestionar discusiones

en línea para cada proyecto hospedado. Los administradores de proyectos

pueden definir varios foros temáticos. Éstos funcionarán como contenedores de

las discusiones que iniciarán los usuarios; otros usuarios pueden responder en las

discusiones ya comenzadas o empezar unas nuevas según lo crean

convenientes.

7 tarball: fichero generado como salida del comando tar de Linux que agrupa varios focheros en

uno solo y sin comprimier, almacenando también las rutas de cada uno. Habitualmente los

ficheros tar son a su vez comprimidos mediante gzip o bzip.



Publicación de noticias

El sistema permite a los usuarios publicar cualquier noticia relacionada con

cada proyecto, desplegando una lista con las más recientes en la página principal

del mismo. Además los administradores del sitio tienen la posibilidad de

promocionar las noticias más interesantes para que aparezcan en la página

principal del sistema.

Administrador de tareas

La asignación de tareas a los colaboradores de los proyectos así como el

control de su estado es una funcionalidad muy útil para los administradores.

GForge también permite generar el Diagrama de Gantt para cada proyecto,

utilidad bastante valiosa a la hora de documentar.

Gestión de bugs

El registro de errores es una herramienta de gran importancia para un grupo

de desarrollo software. GForge facilita el control de los bugs que se van

detectando a lo largo de la fase de desarrollo permitiendo a los colaboradores

registrar los errores y dar por cerrada su corrección.

Documentación

El sistema actúa como almacén documental, siendo posible subir



documentos relacionados con los proyectos, así como visualizarlos y

descargarlos. GForge además lleva un control de versiones para los documentos,

algo muy útil para los colaboradores dedicados a la documentación.

Estadísticas

GForge lleva un registro estadístico de los proyectos hospedados,

calculando periódicamente estadísticos muy ilustrativos como el porcentaje de

actividad, los proyectos más descargados... Esta información permite a los

usuarios conocer en todo momento los proyectos más activos del portal, en los

que foros y listas de correo estarán más actualizados. Por otro lado, también dará

fe de los proyectos abandonados o que hayan concluido su fase de desarrollo.

Árbol de proyectos

Herramienta que permite a los usuarios navegar por las diferentes categorías

en las que se clasifican los proyectos, facilitando la localización de éstos dentro

del portal.

Repositorio de recortes de código

GForge permite publicar trozos de código que los usuarios crean

interesantes y de utilidad para otros desarrolladores.



Registro de actividad

Los administradores del sistema tienen acceso a través de la aplicación al

registro de actividad, pudiendo conocer qué acciones se han llevado a cabo en la

aplicación, en qué momento y quién las ejecutó.

Encuestas

En cada proyecto se pueden elaborar encuestas personalizadas que los

usuarios pueden rellenar. De esta forma los administradores pueden conocer la

opinión general que los participantes tienen del proyecto y así mejorar el servicio

prestado.

Valoración de usuarios

Gforge ofrece a los administradores la posibilidad de valorar las habilidades

de los desarrolladores, algo muy útil a la hora de admitir nuevos participantes en

un proyecto.

Informes

La aplicación genera automáticamente informes periódicos que facilitan a los

administradores información acerca de la marcha del portal.



Soporte multilingüe

GForge está traducido en más de treinta idiomas y permite a los usuarios

configurar el lenguaje de la aplicación. Esta es una de las grandes ventajas de

GForge frente a sus competidores, y en la actualidad el trabajo de adaptación a

nuevos idiomas sigue su curso.

3.1.3 Requerimientos

GForge es un sistema desarrollado para correr en un servidor bajo el sistema

operativo Linux, aprovechando muchas de las herramientas que este S.O.

proporciona y por tanto, ligándose estrechamente a éste. No obstante este hecho

no supone ninguna limitación ya que se trata del sistema operativo libre por

excelencia, con licencia GPL y accesible para todo el mundo.

Un servidor GForge debe tener instalados los siguientes servicios sobre Linux:

• Apache Servidor web.

• PHP4 Servidor de páginas web dinámicas.

• PostgreSQL Sistema de Base de Datos.

• Exim4 Motor de correo electrónico.

• Mailman Servidor de listas de correo.



• CVS o Subversion Control de versiones

• OpenLDAP Servicio de directorio

Esta es la configuración mínima que un sistema debe tener para hospedar

GForge, que puede soportar hasta 450 usuarios y 150 proyectos en un equipo de

sobremesa. Obviamente la capacidad de esta plataforma se multiplica en

servidores más potentes.

3.1.4 Características como FOSPHost

Un sistema de hosting de proyectos de Software Libre basado en GForge

posee las características propias de los sistemas FOSPHost. Se trata de un

sistema muy robusto que garantiza a los usuarios un buen funcionamiento libre de

anomalías. Se trata por tanto de un sistema muy fiable, avalado por el gran

número de organismos que lo utilizan en todo el mundo y que ofrece las máximas

garantías a las organizaciones que sopesan la implantación de un FOSPHost.

GForge ha alcanzado un magnífico compromiso entre libertad y seguridad. Por un

lado permite a los participantes navegar por el por todos los proyectos

hospedados, por otro salvaguarda el trabajo de los grupos de desarrollo

combinado un sistema de logging con una eficiente gestión de roles. La

asignación de roles a los participantes de los proyectos permite una gran

flexibilidad a la hora de controlar los permisos que cada uno de ellos tiene en las

distintas áreas el proyecto. Lo habitual en otros sistemas es que sólo existan dos



tipos de usuarios para los proyectos: administradores y desarrolladores. En

GForge sin embargo es posible personalizar aún más los niveles de acceso de

cada desarrollador a cada una de las herramientas configurando distintos roles.

El gran número de herramientas y funcionalidades que proporciona hacen de

GForge un sistema con unas características de utilidad envidiables dentro de los

sistemas FOSPHost. Pero quizá la característica más importante de GForge en

cuanto a funcionalidad se refiere, sea la incorporación de soporte para plugins,

que lo convierte en un sistema con enormes posibilidades de ampliación. Esta

capacidad para incorporar nuevas herramientas de forma estandarizada ha sido

en muchas ocasiones el factor determinante para muchas organizaciones a la

hora de decantarse por un sistema de hosting.

En cuanto a las características de usabilidad, GForge es uno de los portales más

destacados entre los sistemas libres de su categoría. Factores como la facilidad

para navegar y acceder a las herramientas de trabajo, como el minucioso control

de errores hacen de éste un sistema fácil y cómodo de utilizar.

Una vez instalado y configurado, GForge se convierte en un sistema bastante

autónomo, delegando en el demonio cron8 de Linux la ejecución periódica de

procesos encargados de actualizar estadísticas, permisos de usuarios, categorías

de los proyectos... No obstante, para un correcto mantenimiento del sitio se

requiere la colaboración de al menos un administrador general, encargado de

realizar ciertas tareas y tomar decisiones como aceptar o rechazar nuevos

proyectos, publicar las noticias en la página principal del sitio y mantener los

parámetros de la aplicación.

GForge es un sistema con infraestructura y externamente administrado. El

sistema se basa en una aplicación web escrita en lenguaje PHP y un sistema de

8 Cron: demonio encargado de ejecutar procesos de forma periódica en los sistemas Linux.



información persistente sobre una base de datos PostgreSQL. GForge contempla

una arquitectura distribuida, con los distintos componentes (núcleo del sistema,

base de datos, servidor CVS, servidor de correo...) emplazados en diferentes

máquinas detrás de un mismo servidor Apache. No obstante todos estos

componentes pueden residir en el mismo equipo. La administración del sistema se

considera externa ya que es el administrador el que establece la configuración

global de la aplicación y las herramientas disponibles para los proyectos. Aún así,

se permite un amplio margen de maniobra a los administradores de los proyectos

para personalizar estas herramientas a su gusto y decidir si se utilizan o no.


AITForge: Gestión de Proyectos Software Savane

3.2 Savane

Savane es el sistema de hosting de proyectos de Software Libre basado en

web adoptado por el proyecto GNU para establecer su propio portal colaborativo

de desarrollo, GNU Development Platform. Proporciona herramientas muy útiles

para los colaboradores de proyectos software y cuenta con el apoyo de la más

importante comunidad del Software Libre, GNU.


Imagen 3: Logotipo del proyecto

Savane


3.2.1 Historia

Savane es la continuación del proyecto Savannah9, llevado a cabo por el

mismo grupo de desarrolladores y colaboradores que su predecesor. Este cambio

de denominación se produjo para desacoplar el nombre del proyecto software de

la plataforma de desarrollo software de GNU, llamada Savannah, que no es más

que una implantación de dicho proyecto. No obstante sólo supuso un cambio de

idioma ya que “Savane” es la traducción francesa del término inglés “Savannah”.

En un primer momento GNU no tenía la intención de que Savannah se convirtiese

en un proyecto software sino simplemente una instalación propia del software

SourceForge 2,0, para establecer su propia plataforma de desarrollo. Sin

embargo, poco después de que Savannah fuera instalada, SourceForge se

convirtió en software privativo. Puesto que las mejoras del código fuente se

hacían necesarias para que Savannah pudiese funcionar decentemente, un

equipo de entusiastas del Software Libre emprendieron la aventura de continuar

ellos mismos con el desarrollo del código original, creando una nueva bifurcación

paralela a la iniciada por el equipo de Tim Perdue (GForge). En un primer

momento, el nuevo proyecto recibió el nombre de la plataforma que lo hospedaba,

sin embargo por las razones arriba expuestas terminó denominándose Savane.

En Enero de 2004 con el nombre de Gna! Project10 la Free Software Foundation

francesa crea un nuevo portal de desarrollo colaborativo para hospedar el

proyecto Savane. En los primeros meses de 2005 esta comunidad cuenta con

más de 1900 usuarios y hospeda alrededor de 350 proyectos, entre ellos el propio

Savane [GNA].

9 La dirección del portal de desarrollo del proyecto GNU es http://savannah.gnu.org

10 Esta plataforma se encuentra en el dominio http://gna.org



Savannah continúa siendo el centro de desarrollo, distribución y mantenimiento

del software GNU, y cuenta con alrededor de 33700 proyectos y 2300 usuarios en

Marzo de 2005 [SVNH].

Existe un sitio paralelo, savannah.nongnu.org, donde también se hospedan

proyectos de Software Libre que no forman parte del proyecto GNU.

La última versión de Savane es la 1.0.5 y fue lanzada el 29 de Noviembre de

2005.

3.2.2 Herramientas

Savane apuesta por la sencillez y eficiencia de las herramientas en

detrimento de la variedad. El número de utilidades es menor que en otros

sistemas como GForge, pero estas destacan por ser muy prácticas y fáciles de

utilizar. Estas características facilitan el aprendizaje de los colaboradores y

disminuyen el tiempo de adaptación de éstos al entorno de trabajo, haciendo de

Savane una alternativa muy atractiva como sistema de FOSPHost.

A continuación se presentan las distintas herramientas que proporciona Savane,

resaltando las características específicas de cada una de ellas dentro de esta

aplicación.



Servidor web

Los proyectos disponen de un dominio para publicar sus propias páginas

web dentro del servidor Savane. Además se permite modificar el link de cada

proyecto para que apunte a un dominio externo. Savane no proporciona ningún

tipo de página estándar y son los administradores de cada proyecto los

encargados de elaborar el código HTML de las páginas y subirlo al servidor.

Control de versiones de código fuente

Savane proporciona un servidor de CVS para cada uno de los proyectos. La

aplicación permite al usuario navegar vía web por la estructura de ficheros de los

proyectos así como visualizar y descargar el código fuente.

Los visitantes tienen la posibilidad de descargar un tarball actualizado diariamente

con la estructura de directorios de los proyectos, algo que en GForge sólo le

estaba permitido a los administradores.

Notificaciones por correo electrónico

La aplicación permite el envío de emails entre los componentes de la

comunidad de desarrollo, integrando un servidor de correo electrónico en el

entorno de desarrollo.



Listas de correo

Savane al igual que GForge utiliza Mailman para gestionar las listas de

correo. Esta herramienta GNU proporciona una interfaz web de consulta y

administración de listas de distribución muy potente.

Foros de discusión

El módulo de foros de discusión de Savane permite la gestión de un solo foro

para cada proyecto. En estos foros se permite la creación de diferentes hilos de

discusión y la realización búsquedas parametrizadas de las participaciones de los

usuarios.

Gestión de bugs y parches

Ambas herramientas son similares a un foro de discusión, con sus mismas

características. Se pueden considerar como foros temáticos especializados en

bugs y parches para los proyectos, pero sin ninguna funcionalidad extra.


La gestión de noticias es muy similar a la de GForge, cambiando la interfaz

con la que se presentan. La filosofía en estos sistemas parte de la empleada en

el padre de ambos, SourceForge: cada proyecto tiene su propia lista de noticias y

el administrador del sitio puede promocionar estas noticias a la página principal.




Savane proporciona un módulo de gestión de tareas bastante simple pero

efectivo. El registro, el seguimiento y las modificaciones de las tareas se realiza de

forma sencilla y directa a través de la aplicación en modo texto, sin alardes

gráficos como los diagramas de Gantt de GForge . De hecho la interfaz empleada

es la misma que en los foros de discusión y la gestión de bugs y parches.

Área de descargas

Herramienta para descargar los ficheros relacionados con cada proyecto que

se encuentran almacenados en el servidor. Son los administradores de cada

proyecto los encargados de subir los ficheros y documentos para que éstos pasen

a estar disponibles para el resto de los usuarios.

Estadísticas

Savane proporciona estadísticas actualizadas acerca del servidor,

permitiendo mediante la interfaz web la selección del periodo a considerar. Entre

los parámetros considerados se encuentran:

• Porcentaje de nuevos usuarios registrados frente al total.

• Porcentaje de nuevos proyectos registrados frente al total.

• Porcentaje de programas software frente a proyectos de documentación y

administrativos.



• Porcentaje de nuevos participaciones en foros frente al total.

Listado de proyectos

El sistema de búsqueda de los proyectos registrados de Savane en mucho

más simple que el árbol de proyectos de GForge. Savane se limita a proporcionar

un listado con todos los proyectos, sin distinguir categorías ni estados de los

mismos. Esto supone un gran problema cuando el número de proyectos es

elevado, ya que obliga a los usuarios a recorrer toda la lista para encontrar

aquellos proyectos que les interesen.


Savane es una aplicación desarrollada para ser ejecutada sobre un sistema

operativo Linux, y hace uso de varios sistemas que han de ser instalados

previamente:

• Apache Servidor web.

• PHP4 Servidor de páginas web dinámicas.

• Perl Intérprete para scripts escritos en este lenguaje.

• MySQL Sistema de Base de Datos.



• Mailman Servidor de listas de correo.

• CVS Control de versiones


Savane puede considerarse como la alternativa simplificada a GForge, pero

no por ello es menos robusta. La sencillez y facilidad de uso de esta herramienta

la hacen muy atractiva para portales ligeros y eficientes. En cuanto a fiabilidad es

totalmente comparable a su hermano, ya que ambos se basan en la misma

arquitectura.

La política de acceso de Savane se basa en el registro de usuarios y proyectos en

el sistema. A su vez, los usuarios registrados pueden pasar a formar parte de un

proyecto, adquiriendo privilegios de desarrollador en el mismo. Los usuarios no

registrados pueden acceder a todos las secciones de los proyectos como

invitados, sin permisos para modificar el contenido de los mismos. Este sistema

no implementa un control de roles de usuarios tan refinado como GForge y se

limita a otorgar permisos de administrador de proyecto al usuario que lo registra y

privilegios de desarrollador al resto.

El hecho de que Savane haya apostado por la simplicidad para facilitar el trabajo

de los usuarios conlleva ciertas limitaciones: dificultad para navegar por la lista de

proyectos, baja capacidad de configuración en las herramientas, poca flexibilidad

para asignar permisos a los usuarios... No obstante, para algunos desarrolladores

esta sencillez resulta ventajosa, ya que reduce el tiempo de aprendizaje de las



herramientas y evita posibles fallos por la sobrecarga de funcionalidad.

Savane se encuadra dentro de los sistemas con infraestructura ya que como se

ha visto, se compone de un motor PHP encargado de proporcionar la interfaz para

los usuarios y de una base de datos MySQL como sistema de almacenamiento. Al

igual que GForge, este sistema hace uso de multitud de servicios Linux, obligando

a instalar este sistema operativo por debajo. MySQL es bastante simple, algo que

limita tecnológicamente a Savane frente a GForge. PostgreSQL permite la

ejecución de procedimientos almacenados escritos en PL/SQL11 así como el

lanzamiento de éstos mediante triggers12. Estas facilidades son aprovechadas por

GForge para delegar ciertas tareas en el sistema de base de datos, algo que en

Savane resulta imposible.

La administración del sistema puede considerarse mixta puesto que tanto el

administrador del sitio como los administradores de proyectos desempeñan

papeles importantes en la configuración. En efecto el administrador de un

proyecto decide qué herramientas utilizar, mientras que el administrador general

puede habilitar o deshabilitar las utilidades disponibles a nivel global del sitio.

En definitiva Savane es una plataforma bastante funcional y fácil de utilizar, sin

renunciar a la fiabilidad. Es cierto que en la actualidad cuenta con bastante

desventaja frente a GForge en cuanto al número de portales que lo utilizan, pero

es de esperar que la evolución del sistema equilibre la balanza a medio plazo.

11 Lenguaje procedural que amplía las capacidades del estándar SQL y poder definir secuencias

de control, de flujo y toma de decisiones.

12 Condiciones de disparo para la ejecución de procedimientos. Estas condiciones pueden ser por

ejemplo la inserción de una nueva tupla en una tabla, la violación de una restricción de clave

externa...


AITForge: Gestión de Proyectos Software PHProjekt

3.3 PHProjekt

PHProjekt es una herramienta colaborativa que proporciona la comunicación

y la gestión necesarias para el trabajo en grupo de equipos y compañías de

desarrollo software. Es una aplicación modular con licencia GPL para la

coordinación de actividades grupales e individuales, y permite además compartir

información y documentos vía Intranet o Internet.

3.3.1 Historia

PHProjekt está actualmente en su versión 4.2, y parece ser una aplicación

web bastante estable para uso GroupWare. El líder de este proyecto es Albrecht

Günther, que comenzó su desarrollo allá por 1999. Desde entonces el grupo de

trabajo ha ido mejorando y añadiendo nuevas funcionalidades al sistema

PHProjekt, alcanzando un resultado que hoy en día se presenta como una de las

mejores alternativas de Software Libre para el trabajo en grupo.


Imagen 4: Logotipo de PHProjekt


Sin embargo, este proyecto atraviesa una fase de incertidumbre ya que en la

actualidad la intensidad del de desarrollo ha disminuido preocupantemente.

Apenas existen tareas publicadas para mejorar el sistema, y el trabajo en curso no

se documenta. Por ejemplo, hay una propuesta de mejora para la sincronización

con PDAs fijado en el sitio web de PHProjekt13 desde hace meses, pero parece

que nadie está trabajando en ella. Si bien es verdad, existe una documentación

muy buena sobre la aplicación base que se puede descargar en inglés y alemán

desde la web oficial [PHPjKT].

3.3.2 Herramientas

En este apartado se comentan las diferentes herramientas proporcionadas

por PHProjekt a la comunidad de desarrolladores.

Calendario

Esta es una herramienta novedosa con respecto a los sistemas vistos

anteriormente. PHProjekt incorpora una herramienta de calendario muy sofisticada

que permite visualizar por pantalla las anotaciones de los usuarios para cada día,

semana o mes.

Además incorpora dos modos de funcionamiento: individual y grupo. En el modo

individual las anotaciones visualizadas corresponden a usuarios concretos

13 En la actualidad este sitio se encuentra en : http://www.phprojekt.com



mientras que en modo grupo se muestran las anotaciones comunes a todos los

usuarios pertenecientes a un proyecto.

Gestión de contactos

Esta utilidad permite mantener un almacén de contactos para cada usuario.

Es posible la importación y exportación de contactos en los formatos más

habituales, lo que hace compatible a PHProjekt con la mayoría de las aplicaciones

de contactos existentes.

Es posible ordenar y filtrar contactos, así como permitir o no al resto de miembros

de un grupo tener acceso al listado. Además esta herramienta está enlazada con

la anterior, siendo posible visualizar las anotaciones en el calendario de cada

contacto.

Notificaciones por correo electrónico

El sistema soporta el envío y recepción de mensajes de correo electrónico

de forma integrada. Soporta los protocolos POP3 e IMAP en recepción y utiliza

SMTP en transmisión. La aplicación permite adjuntar archivos en los formatos

ASCII y HTML a los mensajes a la hora de enviarlos, algo que ni GForge ni

Savane soportaban.

FAX y SMS



PHProjekt incorpora soporte para el envío de FAX a otros dispositivos y SMS

a dispositivos móviles de forma integrada a través del correo electrónico.

Árbol de proyectos

El usuaro puede navegar por un árbol de proyectos, ramificado en las

diferentes categorías y subcategorías de los proyectos.

Chat

La aplicación incorpora un módulo de IRC14 mediante el cuál los usuarios del

portal pueden mantener conversaciones en vivo a través del teclado y la pantalla

de su ordenador.

Foros de discusión

El sistema incorpora la gestión de foros de discusión en la que los

colaboradores pueden buscar publicaciones ordenadas por hilos, crear nuevos

hilos de discusión, así como responder a las cuestiones planteadas en los hilos ya

existentes.

La interfaz permite filtrar y paginar los posts de forma que el usuario pueda

acceder de forma rápida y cómoda a las discusiones de su interés.

14 Internet Relay Chat: Charla con retardo a través de Internet.




PHProjekt gestiona un histórico de noticias, permitiendo a los usuarios añadir

noticias nuevas al sistema. El administrador del portal es el encargado de elegir

las noticias que se publicarán en la página de inicio del sitio.


Utilidad que permite listar las tareas asignadas a cada usuario. Dichas tareas

pueden ser asignadas por usuarios con rol de administrador de proyecto al resto

de los miembros del grupo.

El sistema permite además la generación del diagrama de Gantt de cada

proyecto, una característica muy útil a la hora de realizar la planificación temporal

de un proyecto.

Gestión de peticiones

La aplicación ofrece la posibilidad a los usuarios de realizar peticiones o

plantear cuestiones en cada proyecto, de manera que el grupo de desarrolladores

tenga constancia de ellas y pueda responderlas.

Estadísticas

El sistema computa datos estadísticos de actividad para cada proyecto

individual. También se manejan datos generales del portal como : número de



usuarios, número de proyectos registrados, proyectos más activos...

Encuestas

Los usuarios tienen la posibilidad de valorar al resto de usuarios a través de

encuestas. Además el sistema permite la elaboración de encuestas

personalizadas para los proyectos.

Los administradores pueden listar los resultados de las votaciones, tanto los

actuales como los históricos. De esta forma los usuarios pueden promocionar y

adquirir cierto prestigio dentro de los portales gracias a la valoración del resto de

colaboradores.

Soporte multilingüe

Actualmente PHProjekt está disponible en veinticinco idiomas diferentes. Los

portales deben instalar individualmente el soporte para cada lenguaje, por lo que

sería necesario descargar y configurar 25 paquetes diferentes para proporcionar

el máximo de posibilidades.

Recordatorio

La aplicación informa a los usuarios mediante pequeñas ventanas

emergentes acerca de eventos o citas que van a tener lugar. Esta utilidad juega

un papel muy importante a la hora de evitar olvidos de los colaboradores.



Área de descargas

PHProjekt proporciona espacio en el servidor a cada proyecto para albergar

ficheros, tanto versiones de los programas como documentación. Permite la

estructuración en carpetas y el filtrado de los ficheros por categoría.

Notas

Los usuarios pueden almacenar notas personales en la aplicación de forma

sencilla. El sistema ofrece una vista rápida de todas las notas de forma que los

usuarios pueden consultarlas rápidamente.

Es posible enviar notas por correo electrónico a otros usuarios, así como no

restringir el acceso a las mismas a otros colaboradores.

Enlaces favoritos

Esta utilidad permite a los usuarios generar su propia lista de enlaces, la cuál

se muestra en la página personal de cada uno. Estos enlaces permiten a los

usuarios acceder de forma rápida a sus páginas web preferidas desde la

aplicación.




PHProjekt es una aplicación web escrita en lenguaje PHP y permite bastante

flexibilidad en cuanto a sistema de almacenamiento. Incorpora soporte para

diferentes bases de datos como MySQL, PostgreSQL, Oracle, Informix, Interbase

y MS-SQL. PHP así como MySQL, PostgreSQL e Interbase tienen licencia GPL

así como el propio PHProjekt, por lo que es posible configurar un sistema

totalmente de Software Libre.

PHProjekt al contrario que las soluciones FOSPHost vistas hasta el momento no

es dependiente del sistema operativo subyacente, ya que no está ligado a ningún

servicio proporcionado por los mismos. Por tanto es posible instalar PHProjekt en

diversos S.O. como Linux, Windows, Unix, OS/2, Solaris...

Asimismo es posible utilizar cualquier servidor HTTP que incorpore un intérprete

de scripts PHP4 como Apache, IIS, Samba, etc...

Por tanto los requisitos que ha de cumplir un servidor para ejecutar PHProjekt son

bastante flexibles:

• Servidor HTTP con intérprete PHP4.

• Base de datos SQL.

Existen dos entornos típicos de instalación de PHProjekt:

• LAMP (Linux/Apache/MySQL/PHP)

• WAMP (Windows/Apache/MySQL/PHP)



El primero de ellos es totalmente GPL mientras que el segundo, que incorpora

Windows como sistema operativo, no lo es.

Los usuarios han de disponer de un PC con conexión a Internet y un navegador

web capaz de soportar frames y JavaScript.


PHProjekt pertenece al grupo de aplicaciones denominadas de Groupware.

Este tipo de aplicaciones están orientadas a proporcionar un entorno para el

trabajo colaborativo en proyectos de carácter genérico. PHProjekt se centra sobre

todo en el aspecto comunicativo de la gestión de proyectos, suministrando un

gran número de herramientas para ello. También proporciona una herramienta de

calendario muy potente, encaminada a la gestión temporal.

Esta alternativa de Software Libre no es exactamente un FOSPHost ya que está

orientada a la gestión de proyectos en general, no al hospedaje de proyectos

software. En efecto, en PHProjekt se echan en falta algunas de las herramientas

fundamentales en todo FOSPHost como el control de versiones de código fuente

(SCM) o el servidor web, que sí están presentes en GForge y en Savane.

Esta limitación supone un gran inconveniente para las comunidades de desarrollo

software, ya que se ven obligadas a establecer un servidor CVS o Subversion que

trabaje de forma paralela a PHProjekt. De este modo se pierde la integración “all

in one” que caracteriza a los FOSPHost, disminuyendo así la capacidad de

PHProjekt para trabajar como uno de ellos.



Por otro lado, la funcionalidad del sistema es muy elevada en cuanto a la gestión

de grupos de trabajo gracias a las herramientas comunicativas que proporciona.

Chat, mensajería SMS, Fax... son utilidades que no aparecen en otras

aplicaciones y que se presentan como una gran novedad en este sistema. Puede

decirse que PHProjekt es la mejor herramienta de las estudiadas hasta el

momento en cuanto a gestión de la comunicación, pero carece de herramientas

específicas para el hospedaje de proyectos de desarrollo software.

Otra de las ventajas que presenta PHProjekt frente a sus competidores es la gran

flexibilidad que ofrece en cuanto a los sistemas subyacentes a la aplicación. La

compatibilidad con los sistemas de bases de datos más importantes y la

independencia con respecto al sistema operativo convierten a esta aplicación en

una alternativa muy interesante para ser implantada en servidores actualmente

activos.


AITForge: Gestión de Proyectos Software Tabla comparativa

3.4 Tabla comparativa

En este apartado se presenta una tabla que permite comparar de forma

rápida las principales características de las tres alternativas estudiadas en el

capítulo: Gforge, Savane y PHProjekt.

información general

GForge Savane PHProjekt

última versión 4.0.1 1.0.5 4.2

licencia GPL GPL GPL

sitio web gforge.org gna.org www.phprojekt.com

organización Grupo liderado por

Tim Perdue

Free Software

Foundation

Grupo liderado por

Albrecht Günther

nº de sitios que lo

utilizan

soporte

multilingüe

33 idiomas inglés/francés 25 idiomas

sistema operativo GNU/Linux GNU/Linux Flexible

base de datos PostgreSQL MySQL Flexible

lenguaje PHP4 PHP4 PHP4



características FOSPHost


infraestructura Si Si Si

administración Externa Externa/Mixta Externa

herramientas para usuarios y desarrolladores


información

general

Si Si Si

servidor web Si Si No

foros Si Si No

listas de correo Mailman Mailman No

notificaciones email, jabber email email, Fax, SMS

noticias SI Si No

tareas Si No Si

SCM CVS, Subversion CVS No

bugs Si Si No

parches No Si No

documentación DocManager FAC No

área de

descargas

Versión de ficheros CVS Si



IRC No No SI

fax No No Si

SMS No No Si

Wiki plugin No Si

encuestas Si No Si

estadísticas Si No Si

diagramas Gantt No Gantt

calendario No No Si (vCalendar)

contactos No No Si (vCard)

bookmarks No No Si

navegación Árbol de proyectos Listado Árbol de proyectos

búsquedas Si Si Si

herramientas para administradores de proyectos


selección de

herramientas

Si Si No

mantenimiento de

miembros

Si Si Si

upload Formulario HTTPS CVS por SSH FTP

crear foros Si No Si



crear listas de

correo

Si No No

categorizar

proyecto

Si No Si

exportar código

fuente

Descarga de tarball

diario de CVS

Descarga de tarball

diario de CVS

No soporta código

fuente

roles Si No No

acceso SSH Si Si No

herramientas para administradores del sitio


informes Si No No

estadísticas Si No Si

gestión de

herramientas

Si Si No

plugins Si No Paquetes

registro de

actividad

Si No Si

backup Servidor

secundario

No No

personalización




apariencia Themes No Skins

lenguaje Si No No

información

personal

Si Si Si

notas No No Si

valoración de

usuarios

Si No Si


AITForge: Gestión de Proyectos Software Conclusiones

3.5 Conclusiones

En este capítulo se ha desarrollado una comparativa de las distintas

soluciones de Software Libre disponibles para implantar un servidor FOSPHost.

Las aplicaciones comerciales han sido obviadas de dicha comparativa, ya que por

su naturaleza se escapan de los objetivos de este proyecto fin de carrera, que se

se centra en los sistemas de libre distribución.

En primer lugar se ha comprobado la existencia de distintas alternativas muy

competitivas para hospedar comunidades de desarrollo software y facilitar el

trabajo en grupo, que no tienen nada que envidiar a las soluciones comerciales.

Los sistemas que se han estudiado proporcionan gran fiabilidad y un abanico de

herramientas muy potentes para el desarrollo colaborativo de software. Otro

aspecto muy importante y que juega en favor del software libre es que el trabajo

de mejora y ampliación no cesa, garantizando a los usuarios la futura

disponibilidad de actualizaciones que incorporen nuevas tecnologías.

Las conclusiones extraidas del estudio de GForge, Savane y PHProjekt son muy

positivas en los tres casos, pero evidencian que la aptitudes características de

cada uno de ellos son bastante diferentes. Por este motivo a la hora de elegir una

alternativa para establecer un FOSPHost en una comunidad será necesario un

análisis exhaustivo de los requerimientos de cada caso en concreto, para de este

modo tomar la opción que mejor se adapte a esas necesidades.

GForge se presenta como el sistema más potente y completo para hospedar

proyectos software. La robustez de la aplicación y la funcionalidad de sus

herramientas ofrecen a los programadores un entorno ideal para llevar a cabo

proyectos de gran embergadura en los que la colaboración sea indispensable.


AITForge: Gestión de Proyectos Software Conclusiones

Por su parte, Savane es una aplicación más ligera también especializada en

proyectos software. Ofrece una serie de utilidades muy fáciles de utilizar que

aceleran el periodo de aprendizaje de los programadores; no obstante, se

presenta como un sistema muy fiable, que ha ganado la confianza de entidades

tan importantes como el propio proyecto GNU y la Free Software Foundation.

Finalmente PHProjekt es la herramienta más genérica, orientada a hospedar

grupos de trabajo de cualquier naturaleza, no necesariamente desarrollos

software. Enmarcada entre las aplicaciones denominadas de Groupware su

principal objetivo es facilitar las labores de comunicación y planificación de los

miembros de un proyecto, careciendo de utilidades específicas para la

programación.

Como apreciación final conviene señalar que la documentación es la gran

asignatura pendiente de este tipo de herramientas. La escasez de manuales o la

obsolescencia de los mismos convierten en arduas las tareas de instalación,

administración y uso de este tipo de sistemas. Se hace necesaria la colaboración

de personas desinteresadas que aporten a estos proyectos una documentación

profesional y actualizada, una labor que en muchas ocasiones se deja de lado por

ser bastante ingrata.

Desde aquí se hace un humilde llamamiento, para que aquellos lectores

interesados se animen a prestar su ayuda en proyectos de Software Libre, ya que

el beneficio de esta colaboración recaerá tanto en ellos mismos como en el resto

de esta admirable comunidad. Cualquier aportación será bien recibida, a que en

este tipo de proyectos son necesarias muchas facetas: planificación, análisis,

programación, documentación...


AITForge: Gestión de Proyectos Software Gestión de proyectos fin de carrera

4 Gestión de proyectos fin de carrera

A finales de 2004 el Área de Telemática de la Escuela Superior de

Ingenieros de la Universidad de Sevilla considera la posibilidad de crear un portal

web para la gestión de proyectos fin de carrera. Hasta ese momento, el desarrollo

de los proyectos del área sigue el procedimiento tradicional, bastante flexible para

los alumnos pero también algo confuso. Las dificultades evidentes a la hora de

emprender una nueva experiencia como es la realización de un proyecto, unidas a

cierta desinformación por parte de los alumnos sobre ciertos aspectos

administrativos pueden retrasar el trabajo del proyectando; en ocasiones éste

puede llegar a sentirse bastante desamparado.

Los proyectos son publicados generalmente en el tablón de anuncios del

departamento, con la excepción de algunos profesores que proporcionan alguna

información en sus páginas web personales. La expansión y globalidad que

Internet ha alcanzado en los últimos años marca la tendencia actual de las

organizaciones y particulares de publicar cualquier tipo de información en la Red,

de modo que ésta sea accesible para todos. De este modo, sería muy interesante

la creación de un sitio web en el que tuviesen cabida todas las noticias y eventos

relacionados con los proyectos que lleva a cabo el Área de Telemática. En la

actualidad no existe un servidor que centralice los proyectos fin de carrera

ofertados, en curso y terminados de forma que los alumnos puedan obtener toda

la información que necesiten.


AITForge: Gestión de Proyectos Software Justificación

4.1 Justificación

Las circunstancias que rodean a cada proyecto fin de carrera difieren mucho

de unos a otros, por lo que se hace necesaria una atención personalizada para

cada uno. En primer lugar, las características inherentes a cada proyecto como la

naturaleza o dificultad del mismo deben ser exhaustivamente consideradas para

que el proyecto sea realizable. Se hace necesario el establecimiento de objetivos

razonables que persigan la formación del alumno en lugar de fijar metas

demasiado ambiciosas que conviertan el proyecto fin de carrera en un obstáculo.

Por otro lado está la disponibilidad de alumnos y profesores, que en ciertas

ocasiones no es tan amplia como sería deseable. Asignaturas pendientes o

prácticas en empresas restan en ocasiones bastante tiempo a los proyectando,

impidiendo una dedicación plena al desarrollo del proyecto fin de carrera.

Asimismo, los apretados horarios de clase de los profesores pueden dificultar la

colaboración con los alumnos que se encuentran realizando sus proyectos.

Comenzando por la publicación en el tablón de anuncios y concluyendo con la

defensa por parte del alumno, la vida de un proyecto fin de carrera está

segmentada en una serie de fases lógicas que han de ser superadas. A lo largo

de este periodo, la comunicación entre alumno y tutor se hace indispensable para

el buen desarrollo del mismo. La ausencia de esta comunicación suele

desembocar en cierto abandono por parte del alumno, que por falta de orientación

puede perder la motivación.

Éstas y otras razones evidencian la necesidad de prestar la máxima atención y

dedicar todo el esfuerzo necesario para facilitar en lo posible el proceso de

desarrollo de los proyectos fin de carrera, tanto a alumnos como a profesores. Por

ello sería muy beneficioso la creación de una aplicación web que sirva como

punto de encuentro, mejore la comunicación entre los participantes y fomente el


AITForge: Gestión de Proyectos Software Justificación

trabajo en grupo.

Con dicha aplicación se pretende normalizar el desarrollo de las distintas fases de

los PFC, de modo que se facilite la colaboración de todas las partes implicadas. El

sistema comprendería todo en ciclo de vida de los proyectos, desde la oferta de

los mismos por parte del profesor hasta que son evaluados.


AITForge: Gestión de Proyectos Software Análisis

4.2 Análisis

En este apartado se procede a realizar un análisis de los requerimientos de

un aplicación software para la gestión de proyectos fin de carrera. Para ello se

utilizarán diferentes herramientas:

• UML (Lenguaje Unificado de Modelado)

• Tablas descriptivas

En primer lugar se obtendrá una visión global de la aplicación para adquirir una

primera aproximación a la funcionalidad del sistema. Posteriormente se efectuará

un análisis de los requisitos de almacenamiento de información que una

aplicación de este tipo precisa. Y por último se estudiarán uno por uno los casos

de uso15 que se detecten, subdividiendo de esta forma el problema global en

diferentes tares más simples.

4.2.1 Visión global de la aplicación

Una aplicación para la gestión de proyectos fin de carrera debe abarcar

todas las tareas relacionadas con el desarrollo de los proyectos: información,

15 Operación/tarea específica que se realiza en la aplicación tras una orden de algún agente

externo.



tareas administrativas, planificación, comunicación...

Serán necesarias herramientas que permitan la comunicación como: listas de

correos, foros, publicación de noticias... y utilidades específicas para el desarrollo

de cada proyecto como un CVS, ya que en la mayoría de ocasiones la

programación se verá implicada.

El sistema debe estar disponible en todo momento y desde cualquier lugar,

situación que recomienda una aplicación web, accesible a través de Internet. Por

consiguiente será necesario tener en cuenta los riesgos de seguridad que Internet

conlleva para cualquier aplicación y para sus usuarios.

Evidentemente la aplicación ha de ser multiusuario y debe ser capaz de albergar

muchos proyectos diferentes. Será necesario establecer qué información ha de

almacenar el sistema acerca de cada entidad, y controlar el acceso de los

usuarios a la información de los proyectos.

En cuanto a la vida temporal de un proyecto podemos definir a priori los siguientes

estados por los que pasa un proyecto.

• Proyecto en estudio

• Proyecto ofertado

• Proyecto asignado

• Proyecto en curso

• Proyecto pendiente de defensa

• Proyecto evaluado



Además, durante el periodo en el que el proyecto se encuentra en fase de

desarrollo sería interesante poder fijar diferentes hitos como por ejemplo:

• Fin de plazo de solicitudes

• Asignación

• Entrega de documentos

• Pruebas

• Defensa

• Evaluación


Imagen 5: Diagrama de estados de los proyectos.


Como es habitual en este tipo de aplicaciones de gestión, será necesario un

control de roles de acceso a la misma. En un principio podemos considerar cuatro:

• Administrador

• Profesor

• Usuario registrado

• Usuario no registrado

Estos roles dispondrán de diferentes funcionalidades dentro de la aplicación,

siendo algunas de éstas opciones comunes a todos. Algunos roles tendrán

restringido el acceso a ciertos módulos de la aplicación por motivos lógicos de

seguridad.

4.2.2 Requisitos de almacenamiento de información

Se establece aquí la información que el sistema debe almacenar para cada

una de las entidades implicadas:

• Usuarios

• Proyectos



• Tareas

• Roles

A continuación se presentan diferentes tablas con los requisitos de información

RI-xx.

RI-01 Información sobre usuarios

Descripción El sistema deberá almacenar la información correspondiente a

los usuarios del sistema.

Datos

concretos

• Id. único de usuarios

• Número del documento nacional de identidad

• Nombre y apellidos

• Login y password

• Teléfono de contacto

• Email

• Rol de usuario

• Fecha de alta como usuario

Intervalo

temporal

Sólo presente

Comentarios Ninguno



RI-02 Información académica

Descripción El sistema deberá almacenar información académica de los

usuarios del sistema.

Datos

concretos

• Titulación y especialidad

• Conocimientos

• Asignaturas pendientes

• Disponibilidad

• Comentarios

Intervalo

temporal

Sólo presente

Comentarios Ninguno



RI-03 Información sobre proyectos


los proyectos disponibles en el sistema. En concreto:

Datos

concretos

• Id. único del proyecto

• Título del proyecto

• Descripción

• Requisitos del alumno solicitante

• Duración

• Nota de evaluación

• Profesor tutor

• Alumno/s proyectista/s

• Estado del proyecto

• Hitos del proyecto

Intervalo

temporal

Pasado y presente

Comentarios Ninguno



RI-04 Información sobre roles


los posibles roles de los usuarios del sistema.

Datos

concretos

• Id. único del rol

• Denominación

Intervalo

temporal

Sólo presente

Comentarios Ninguno

RI-05 Información sobre estados de los proyectos


los posibles estados de los proyectos del sistema.

Datos

concretos

• Id. único del estado

• Denominación

Intervalo

temporal

Sólo presente

Comentarios Ninguno



RI-06 Información sobre hitos


los posibles hitos de los proyectos del sistema. En concreto:

Datos

concretos

• Id. único del hito

• Denominación

• Fecha del hito

Intervalo

temporal

Sólo presente

Comentarios Ninguno

4.2.3 Requisitos funcionales

En este punto vamos a estudiar los requisitos funcionales de la aplicación de

gestión de proyectos. Vamos a agrupar los distintos requisitos por roles,

comenzando por los casos de uso comunes a todos los perfiles. Posteriormente

se estudiarán los específicos para cada rol.

Casos de uso comunes a todos los usuarios

Aquí se detallan las funcionalidades accesibles pos cualquier usuario que



acceda mediante su navegador web a la página inicial de la aplicación.


Imagen 6: Diagrama de casos de uso para usuarios no registrados.


RF-01 Búsqueda de proyectos

Descripción El sistema permitirá a cualquier usuario realizar una búsqueda

de los proyectos fin de carrera disponibles en el sistema. Esta

búsqueda se realizará en base a unos criterios establecidos

por el propio usuario.

Flujo principal Paso Acción

1 El usuario solicita al sistema realizar una búsqueda

de proyectos.

2

El sistema solicita al usuario los criterios de

búsqueda.

3 El usuario indica los criterios de búsqueda.

4

El sistema muestra un listado con los proyectos

encontrados.

Flujo

secundario

Paso Acción

Precondiciones No hay

Poscondiciones

Importancia Vital

Comentarios Ninguno



RF-02 Consulta de proyectos

Descripción El sistema permitirá a cualquier usuario realizar una consulta

de los datos públicos de los proyectos. Estos datos serán: el

título, la descripción, los requisitos, la duración, el alumno

proyectista y el estado. Los datos privados (hitos) sólo serán

visibles por los actores relacionados directamente con el

proyecto.


1

El usuario solicita al sistema realizar una consulta de

un proyecto.

2 El sistema muestra los datos públicos del proyecto.

Flujo

secundario

Paso Acción

Precondiciones Realizar una búsqueda de proyectos (RF-01).

Poscondiciones

Importancia Vital

Comentarios Ninguno



RF-03 Registro de usuarios

Descripción El sistema deberá permitir a los usuarios registrarse en la

aplicación desde la página inicial. El rol de usuario será en

este caso “Usuario registrado”.


1 El usuario solicita al sistema el registro.

2 El sistema solicita información de registro al usuario.

3 El usuario proporciona la información al sistema.

4 El sistema registra al usuario en la aplicación.

Flujo

secundario

Paso Acción

4 Si el usuario ya existe en el sistema se cancela la

operación.

Precondiciones No hay

Poscondiciones

Importancia Recomendable

Comentarios Ninguno



RF-04 Login de usuarios

Descripción El sistema ha de permitir a los usuarios acceder a la aplicación

desde la página inicial introduciendo su login y su password.


1 El usuario solicita logarse en el sistema.

2 El sistema solicita el login y el password al usuario.

3 El usuario proporciona la información al sistema.

4

El sistema comprueba si el usuario es válido y

presenta la página principal con la información del

usuario..

Flujo

secundario

Paso Acción

4 Si el usuario no es válido se cancela la operación.

Precondiciones El usuario ha de estar registrado en el sistema (RF-03).

Poscondiciones El usuario tendrá acceso a la funcionalidad adicional que su

rol le permita.

Importancia Vital

Comentarios Ninguno

Casos de uso para los usuarios registrados con cualquier rol

A continuación se describen los casos de uso a los que un usuario tiene

acceso sólo si está registrado en el sistema. En este apartado se contemplan los



roles de “Usuario registrado”, “Profesor” y “Administrador”.


Imagen 7: Diagrama de casos de uso para usuarios registrados.


RF-05 Consulta de cuenta de usuario

Descripción El sistema deberá permitir a los usuarios registrados en el

sistema la consulta de sus datos personales.


1 El usuario solicita al sistema consultar sus datos.

2

El sistema muestra los datos del usuario en

cuestión.

Flujo

secundario

Paso Acción

Precondiciones Login (RF-04).

Poscondiciones

Importancia Vital

Comentarios Ninguno



RF-06 Modificación de datos de usuario

Descripción El sistema deberá permitir al usuario modificar sus datos

personales.


1 El usuario modifica sus datos y solicita al sistema

que los guarde.

2 El sistema realiza las modificaciones.

Flujo

secundario

Paso Acción

2 Si los nuevos datos coinciden con los de otro

usuario se cancela la operación.


Poscondiciones

Importancia Vital

Comentarios Ninguno



RF-07 Modificación de contraseña

Descripción El sistema deberá permitir al usuario cambiar su contraseña.


1 El usuario solicita al sistema el cambio de password.

2 El sistema solicita al usuario la nueva contraseña por

duplicado.

3 El usuario introduce la nueva contraseña.

4 El sistema modifica la contraseña del usuario.

Flujo

secundario

Paso Acción

4 Si los dos valores de la contraseña introducidos no

coinciden se cancela la operación.


Poscondiciones

Importancia Vital

Comentarios Ninguno

Casos de uso para Profesores y Administradores

Aquí se verán las distintas funcionalidades a las que tienen acceso estos dos

roles dentro de las aplicación. El rol de “Administrador” incluye el rol de “Profesor”.




Imagen 8: Diagrama de casos de uso para administradores y profesores


RF-08 Ofertar proyectos

Descripción El sistema permitirá al usuario con rol de profesor ofertar

proyectos fin de carrera, pasando a estar disponibles en el

sistema.


1 El profesor solicita al sistema realizar una oferta de

un proyecto.

2 El sistema solicita al profesor la información

relacionada con el proyecto.

3 El profesor facilita la información.

4 El sistema añade el proyecto en el estado

“Ofertado”.

Flujo

secundario

Paso Acción


Poscondiciones

Importancia Vital

Comentarios Ninguno



RF-09 Búsqueda de proyectos tutelados

Descripción El sistema permitirá a los profesores buscar sus proyectos.


1 El profesor solicita al sistema la búsqueda de sus

proyectos.

2 El sistema muestra un listado con los proyectos

tutelados por el profesor.

Flujo

secundario

Paso Acción


Poscondiciones


Comentarios Ninguno



RF-10 Consultar un proyecto tutelado

Descripción El profesor podrá consultar los datos públicos y privados de un

proyecto tutelado.


1 El profesor solicita al sistema realizar una consulta

de su proyecto.

2 El sistema muestra los datos públicos y privados del

proyecto.

Flujo

secundario

Paso Acción


Búsqueda de proyectos (RF-01) o Búsqueda de proyectos

tutelados (RF-09).

Poscondiciones

Importancia Vital

Comentarios Ninguno



RF-11 Modificar un proyecto tutelado

Descripción El sistema permitirá a los profesores buscar sus proyectos.


1 El profesor modifica los datos del proyecto

consultado y solicita al sistema que los actualice.

2 El sistema modifica los datos del proyecto en

cuestión.

Flujo

secundario

Paso Acción

Precondiciones Consulta de proyecto tutelados (RF-10).

Poscondiciones

Importancia Vital

Comentarios Ninguno



RF-12 Asignar un proyecto tutelado

Descripción El sistema deberá permitir al profesor asignar un proyecto a un

alumno que lo haya solicitado.


1 El profesor solicita al sistema la asignación de un

proyecto.

2 El sistema muestra un listado con los usuarios que

han solicitado el proyecto.

3 El profesor selecciona un alumno.

4 El sistema marca el proyecto como asignado.

Flujo

secundario

Paso Acción


Poscondiciones

Importancia Muy recomendable

Comentarios Ninguno



RF-13 Evaluar un proyecto tutelado

Descripción El sistema deberá permitir al profesor evaluar un proyecto

después de la defensa del mismo por parte del alumno.


1 El profesor solicita al sistema la evaluación de un

proyecto.

2 El sistema solicita al profesor la nota de evaluación.

3 El profesor proporciona esa nota.

4 El almacena la nota y establece el proyecto como

evaluado.

Flujo

secundario

Paso Acción


Asignación de proyecto tutelado (RF-12).

Poscondiciones

Importancia Vital

Comentarios Ninguno



RF-14 Añadir un hito

Descripción El sistema deberá permitir al profesor añadir un hito a un

proyecto tutelado por este.


1 El profesor solicita al sistema añadir un hito.

2 El sistema presenta la lista de hitos posibles.

3 El profesor selecciona un hito y la fecha del mismo.

4 El asocia el hito al proyecto.

Flujo

secundario

Paso Acción

4 Si el proyecto ya tiene asociado ese hito se cancela

la acción.


Poscondiciones


Comentarios Ninguno



RF-15 Modificar un hito

Descripción El sistema deberá permitir al profesor modificar la fecha de un

hito asociado a un proyecto.


1 El profesor solicita al sistema modificar un hito.

2 El sistema presenta el detalle del hito.

3 El profesor selecciona la nueva fecha.

4 El sistema modifica la fecha del hito.

Flujo

secundario

Paso Acción


Hito añadido (RF-14).

Poscondiciones


Comentarios Ninguno



RF-16 Eliminar un hito

Descripción El sistema deberá permitir al profesor eliminar un hito asociado

a un proyecto.


1 El profesor solicita al sistema eliminar un hito.

2 El sistema solicita confirmación.

3 El profesor confirma el borrado.

4 El sistema borra el hito del proyecto.

Flujo

secundario

Paso Acción

3 Si el profesor no confirma se cancela la acción.


Hito añadido (RF-14).

Poscondiciones


Comentarios Ninguno



RF-17 Eliminar un proyecto tutelado

Descripción El sistema deberá permitir al profesor eliminar un proyecto

tutelado por este.


1 El profesor solicita al sistema eliminar un proyecto.


3 El profesor confirma el borrado.

4 El sistema borra el proyecto.

Flujo

secundario

Paso Acción

3 Si el profesor no confirma se cancela la acción.


Poscondiciones

Importancia Vital

Comentarios Ninguno



RF-18 Enviar email a un alumno tutelado

Descripción El sistema permitirá al profesor enviar emails a los alumnos

que estén realizando uno de sus proyectos.


1 El profesor solicita al sistema el envío de email.

2 El sistema solicita al profesor el contenido del email.

3 El profesor introduce el mensaje que desee enviar al

alumno..

4 El sistema compone el email y lo envía.

Flujo

secundario

Paso Acción


Poscondiciones


Comentarios Ninguno

Casos de uso para Administradores

A continuación se describe la funcionalidad adicional que el sistema debe

permitir a los administradores. Entre otras, se encuentran las tareas de

mantenimiento de la aplicación que facilitan la modificación del comportamiento de

la aplicación en tiempo de ejecución.




Imagen 9: Diagrama de casos de uso para administradores.


RF-19 Añadir usuarios al sistema

Descripción El sistema deberá permitir al administrador agregar usuarios al

sistema, asignándoles cualquier rol.


1 El administrador solicita al sistema agregar un

usuario.

2 El sistema solicita los datos del nuevo usuario.

3 El administrador proporciona los datos.

4 El sistema agrega al nuevo usuario.

Flujo

secundario

Paso Acción

3 Si el usuario ya existe se cancela la acción.


Poscondiciones

Importancia Vital

Comentarios Ninguno



RF-20 Búsqueda de usuarios

Descripción El sistema deberá permitir al administrador realizar una

búsqueda de los usuarios del sistema en base a ciertos

criterios.


1 El administrador solicita al sistema realizar una

búsqueda.

2 El sistema solicita los criterios de la búsqueda.

3 El administrador proporciona esos criterios.

4 El sistema presenta un listado con los usuarios

encontrados.

Flujo

secundario

Paso Acción

3 Si el usuario ya existe se cancela la acción.


Poscondiciones

Importancia Vital

Comentarios Ninguno



RF-21 Consulta de datos de usuarios

Descripción El sistema deberá permitir al administrador consultar los datos

de los usuarios del sistema.


1 El administrador solicita al sistema consultar un

usuario.

2 El sistema muestra los datos del usuario.

Flujo

secundario

Paso Acción

Precondiciones Búsqueda de usuarios (RF-20).

Poscondiciones

Importancia Vital

Comentarios Ninguno



RF-22 Modificar datos de usuarios

Descripción El sistema deberá permitir al administrador modificar los datos

de los usuarios del sistema.


1 El administrador modifica los datos de un usuario y

solicita al sistema que los actualice.

2 El sistema realiza la modificación.

Flujo

secundario

Paso Acción

2 Si los nuevos datos coinciden con los de otro

usuario se aborta la operación.

Precondiciones Consulta de datos de usuarios (RF-21).

Poscondiciones

Importancia Vital

Comentarios Ninguno



RF-23 Eliminar usuarios del sistema

Descripción El sistema deberá permitir al administrador eliminar usuarios

del sistema.


1 El administrador solicita el borrado de un usuario.


3 El administrador confirma el borrado.

4 El sistema elimina el usuario.

Flujo

secundario

Paso Acción

3 Si el usuario no confirma o el usuario tiene un

proyecto asignado se cancela la acción.

Precondiciones Consulta de datos de usuarios (RF-21).

Poscondiciones

Importancia Vital

Comentarios Ninguno



RF-24 Modificar proyectos del sistema

Descripción El sistema deberá permitir al administrador modificar cualquier

proyecto del sistema.


1 El administrador modifica los datos de un proyecto y

solicita al sistema que los actualice.

2 El sistema realiza la modificación.

Flujo

secundario

Paso Acción


Consulta de proyectos (RF-02).

Poscondiciones


Comentarios Ninguno



RF-25 Eliminar proyectos del sistema

Descripción El sistema deberá permitir al administrador eliminar cualquier

proyecto del sistema.


1 El administrador solicita el borrado de un proyecto.


3 El administrador confirma el borrado.

4 El sistema elimina el proyecto.

Flujo

secundario

Paso Acción

3 Si el usuario no confirma se cancela la operación.



Poscondiciones

Importancia Vital

Comentarios Ninguno

Casos de uso para los alumnos

Los siguientes casos de uso son exclusivos de los usuarios del sistema con

el rol de ”Alumno”.




Imagen 10: Diagrama de casos de uso para los alumnos.


RF-26 Solicitud de proyectos

Descripción El sistema permitirá a un usuario registrado solicitar un

proyecto fin de carrera mediante el envío de un correo

electrónico al profesor responsable de ese proyecto.


1 El usuario solicita el proyecto desde la página de

detalle del mismo.

2 El sistema envía un email al tutor del proyecto,

donde aparecen los datos del usuario y el proyecto

solicitado.

Flujo

secundario

Paso Acción

2 Si el usuario ya ha solicitado un proyecto se aborta

el envío.



Poscondiciones


Comentarios Ninguno



RF-27 Consulta de proyecto propio

Descripción El sistema permitirá a un usuario consultar los datos del

proyecto que tiene asignado. En este caso se mostrarán tanto

los datos públicos como privados definidos en RF-02.


1 El usuario solicita al sistema realizar una consulta de

su proyecto.

2 El sistema muestra los datos públicos y privados del

proyecto.

Flujo

secundario

Paso Acción


Proyecto asignado (RF-12).

Poscondiciones


Comentarios Ninguno



RF-28 Envío de email al tutor del proyecto

Descripción El usuario podrá enviar un email desde la aplicación a su tutor

de proyecto.


1 El usuario solicita al sistema el envío de un email.

2 El sistema solicita al usuario el contenido del

mensaje.

3 El usuario introduce el mensaje que desea enviar al

tutor.

4 El sistema compone el email y lo envía.

Flujo

secundario

Paso Acción

Precondiciones Consulta de proyecto propio (RF-27).

Poscondiciones


Comentarios Ninguno


AITForge: Gestión de Proyectos Software Comparativa de las posibles soluciones

4.3 Comparativa de las posibles soluciones

En este punto se van a estudiar las distintas posibilidades planteadas para la

implementación de la aplicación de gestión de proyectos fin de carrera. Se

valorarán distintos aspectos como:

• Capacidad para solventar los requisitos funcionales descritos

anteriormente de forma óptima.

• Herramienta de libre distribución.

• Requisitos de sistema que se precisen en cada un de las soluciones.

• Ventajas e inconvenientes.

• Características adicionales

En este análisis vamos a considerar dos posibles soluciones:

• Gforge Se presenta como la solución más recomendable de entre

todas las estudiadas en el capítulo anterior para solventar los

requerimientos de una aplicación de gestión de proyectos fin de carrera.

• J2EE Entorno de programación Java que propone una excelente

arquitectura para desarrollar una aplicación web de cualquier tipo.



Ambas tecnologías son de libre distribución y existen multitud de herramientas

software que permiten trabajar con ellas.

Se procederá ahora a realizar un estudio detallado de cada una de ellas,

valorando individualmente sus posibilidades para desarrollar la aplicación de

gestión que tiene como objetivo este proyecto.

4.3.1 Gforge

Gforge es un portal que proporciona un entorno colaborativo para proyectos

software genéricos. Proporciona herramientas para que el equipo de trabajo

pueda colaborar en un mismo proyecto de forma coordinada. Entre las distintas

facilidades que provee este entorno se encuentran: foros de discusión, listas de

correo, sitio web para los proyectos, gestión de código fuente (SCM), etc...

Este proyecto Open Source con licencia GPL está basado en el sistema original

SourceForge.net, que tanto éxito ha tenido en la comunidad del software libre y

cuyo desarrollo se cerró en 2001.

Al ser Gforge un proyecto de fuentes abiertas, puede ser modificado y

personalizado para ajustarse a las necesidades puntuales de las comunidades de

desarrollo software.

Actualmente Gforge se encuentra en su versión 4.0, liberada el 24 de Octubre de

2004.

Los requisitos de sistema que precisa Gforge son:



• Sistema operativo Linux.

• PostgreSQL (Servidor de base de datos).

• Apache (Servidor web).

• PHP (Servidor de páginas web dinámicas).

• Openssl (Protocolo de seguridad para HTTP).

Esta es la configuración mínima que un sistema debe tener para hospedar Gforge,

que puede soportar hasta 450 usuarios y 150 proyectos en una sola CPU.

Gforge consiste básicamente en una aplicación web implementada con páginas

PHP y una base de datos PostgreSQL como sistema de almacenamiento. Los

módulos suplementarios se acoplan a esta configuración básica mediante ficheros

de configuración, y son accesibles vía web.

Los servicios proporcionados por Gforge a los usuarios son entre otros:

• Sitio web para los proyectos.

• Gestión de roles y permisos de los usuarios.

• Foros de discusión.

• Publicación de noticias.

• Listas de correo (Precisa instalación de Mailman).

• Administrador de tareas.



• Gestión de fuentes y versiones (Precisa instalación de un servidor CVS).

• Gestión de bugs.

• Documentación.

• Estadísticas.

Ventajas:

• Núcleo del sistema de gestión ya implementado. La personalización de

Gforge para la gestión de proyectos fin de carrera sería posible modificando

el código fuente del proyecto.

• Sistema ligero. Los requerimientos de sistema son bastante livianos.

Además Gforge corre sobre Linux, el sistema operativo libre más extendido.

• Amplio abanico de funcionalidad adicional para la gestión de la fase de

desarrollo de los proyectos.

Inconvenientes:

• Gforge está basado en una arquitectura de dos capas. Las páginas PHP

realizan las tareas de presentación, lógica de negocio y acceso a base de

datos. Esta arquitectura conlleva ciertos inconvenientes de mantenimiento y

escalabilidad de la aplicación.



4.3.2 J2EE

Java 2 Platform, Enterprise Edition (J2EE) es la edición empresarial de la

plataforma Java (Java platform). Es una plataforma completamente software, que

se ejecuta sobre las plataformas hardware existentes en el mercado. J2EE está

orientada al desarrollo de aplicaciones empresariales en este lenguaje.

Sobre esta plataforma sería posible la implementación de una aplicación web

específica para la gestión de proyectos fin de carrera en el departamento de

telemática.

Requisitos del sistema de esta solución:

• Sistema operativo Windows, Solaris, Unix o Linux.

• Servidor de aplicaciones J2EE (JBOSS es de libre distribución).

• Servidor de base de datos ()MySQL, PostgreSQL, Oracle...).

• Plataforma J2SE (J2SDK) de libre distribución de Sun MicroSystems.

En el desarrollo de esta aplicación se solventarían los distintos casos de uso

expuestos en el análisis de forma personalizada. El peso de programación sería

muy superior al de Gforge pero, a cambio, se obtendría una aplicación ajustada

perfectamente a las necesidades.



Ventajas:

• Un buen diseño de la aplicación, con una arquitectura multicapa y distribuida,

facilitaría mucho posteriores ampliaciones y mantenimientos. La separación

de tareas entre las distintas capas de la aplicación permite desacoplar

completamente el sistema, de modo que cada módulo puede modificarse

internamente sin que el resto se vea afectado. Existen frameworks como

Apache Jakarta Struts que facilitan enormemente el diseño de una aplicación

J2EE.

• Seguridad. El nivel de seguridad de la aplicación sería superior gracias a los

servicios proporcionados por J2EE.

• Escalabilidad. J2EE permite desarrollar sistemas altamente escalables y

capaces de adaptarse a las necesidades de carga mediante configuración en

ficheros XML de despliegue y sin necesidad de tocar el código.

• Personalización. Una aplicación específica satisface mejor las necesidades

primarias del sistema, ya que se diseña exclusivamente para ello.

• Robustez. El tratamiento de errores puede hacerse de forma mucho más

exhaustiva en J2EE, gracias al mecanismo de excepciones Java.

Inconvenientes:

• Esta solución consume más recursos hardware que la anterior.

• El tiempo de desarrollo es mayor.



4.3.3 Elección de la herramienta a utilizar

Después de valorar las ventajas e inconvenientes que presentan las distintas

alternativas barajadas, la herramienta elegida para desarrollar la aplicación de

gestión de proyectos fin de carrera para el Área de Telemática de la ESI es

GForge.

Los principales motivos que han llevado a la elección de GForge son;

• GForge proporciona un gran número de herramientas muy útiles para el

desarrollo de proyectos fin de carrera. Conseguir tal grado de

funcionalidad mediante la implementación de una aplicación específica en

J2EE conllevaría un gran coste en tiempo y recursos.

• Es una herramienta consolidada dentro de la comunidad de desarrollo de

Software Libre y cuenta con el aval de numerosos portales que la utilizan.

• Es la solución preferida por los responsables de este proyecto fin de

carrera.


AITForge: Gestión de Proyectos Software Diseño de una aplicación de gestión de PFCa partir de GForge

5 Diseño de una aplicación de gestión dePFC a partir de GForge

En este capítulo se abordará el diseño e implementación de una aplicación

de gestión de proyectos fin de carrera basada en GForge. En este diseño se

tendrán en cuenta los requerimientos detectados en el Capítulo 3, intentando

solventarlos por completo. El nombre con el que se denominará la nueva

aplicación será AITForge (Forge del Área de Ingeniería Telemática).

Se comenzará por un estudio detallado de la arquitectura de GForge para

posteriormente abordar modularmente la ampliación funcional del sistema, hasta

conseguir los objetivos establecidos en el análisis.

Para realizar el diseño se utilizarán diversas herramientas como diagramas UML y

modelos entidad-relación para las las tablas creadas en base de datos.


AITForge: Gestión de Proyectos Software Estudio del sistema GForge

5.1 Estudio del sistema GForge

En este apartado se procede a realizar un estudio de la arquitectura del

sistema GForge en su versión 4.0. Con dicha labor de inspección se pretende

adquirir una visión global de la aplicación, de forma que posteriormente pueda

abordarse su ampliación siguiendo las pautas de programación ya establecidas

por los desarrolladores del sistema original. De este modo se conseguirá ampliar

la funcionalidad de la aplicación sin modificar sensiblemente el núcleo de la

aplicación inicial, mediante la adición de módulos funcionales independientes.

Esta ampliación poco agresiva dará como resultado una aplicación de robustez y

fiabilidad totalmente equiparable a GForge, aprovechando todas las

características del conocido sistema de FOSPHost.

5.1.1 Arquitectura de GForge

Como se vio en el apartado 2.1.3, el sistema GForge se basa en una

aplicación web, accesible desde Internet. Como toda aplicación web, a muy alto

nivel se puede hablar de arquitectura Cliente/Servidor, en la que los usuarios

utilizan un navegador web como cliente e interactúan con un servidor remoto, en

este caso GForge.



En este tipo de arquitectura existe un servidor que se ejecuta permanentemente y

escucha las peticiones que recibe de los clientes. Una vez recibidas, estas

peticiones son procesadas por el servidor, elaborándose como resultado una

respuesta que es enviada al cliente. Por su parte, los clientes no tienen por qué

ejecutarse de forma permanente, al ser estos los que inician y terminan el diálogo

con el servidor.

En el caso de las aplicaciones web, el protocolo de comunicación utilizado es

HTTP, por lo que peticiones y respuestas enviadas entre el servidor y los clientes

han de seguir este protocolo.

Arquitectura del servidor GForge

El servidor GForge corre sobre un sistema operativo GNU/Linux y se

compone fundamentalmente de una interfaz implementada mediante páginas PHP

y un sistema de base de datos PostgreSQL. Además el sistema utliza una serie

de servicios que han de ser instalados en la máquina servidora y que se ejecutan

en Linux: Apache, LDAP, cron, SSH, FTP, Mailman, Exim4...


Imagen 11: Esquema de la arquitectura Cliente / Servidor


La arquitectura interna de GForge responde al paradigma de Front-end / Back-

end. En diseño de software, el front-end es la parte del software que interactúa

con el usuario y el back-end es la parte que procesa la entrada desde el front-end.

Este nivel de abstracción ayuda a mantener las diferentes partes del sistema

separadas. La idea general consiste en que el front-end sea el responsable de

recolectar los datos de entrada del usuario, que pueden llegar de diversas formas,

y procesarlos de manera que el back-end los pueda utilizar. La conexión del front-

end y el back-end se especifica como un tipo de interfaz que ambas partes han de

cumplir.


Imagen 12: Arquitectura de GForge


Front-end

En GForge el front-end está constituido por páginas web dinámicas escritas

en lenguaje PHP4, que se encargan de proporcionar la interfaz de usuario de la

aplicación. El servidor web Apache es el encargado de seleccionar la página a

servir en cada momento en función de la petición del cliente, interaccionando con

el intérprete PHP4 para generar el código HTML.

De esta forma el usuario interacciona con el sistema, siendo la información

almacenada en base de datos para su posterior procesado o recuperación.

Back-end

Por su parte, el back-end de GForge está formado por un conjunto de scipts

PHP y Perl, junto con una serie de procedimientos PL/SQL almacenados en la

base de datos PostgreSQL. El cron de Linux es el núcleo del back-end, que

periódicamente ejecuta los procesos encargados de actualizar el sistema en

función de la información introducida por el front-end en la base de datos.

Estos procesos se encargan de actualizar de forma periódica la configuración de

los distintos servicios como SSH, LDAP, CVS... De este modo se aislan ciertos

procesos críticos para el sistema de la interactuación con el usuario, aumentando

la fiabilidad y seguridad del servidor.



5.1.2 Interfaz con el usuario: PHP

Como se ha visto en el apartado anterior la aplicación GForge implementa la

interfaz de usuario mediante páginas PHP, que son interpretadas para generar el

código HTML que será enviado de vuelta al cliente, y que éste podrá visualizar a

través del navegador web.

PHP pese a no ser un lenguaje orientado a objetos (LOO) puro, si que aporta

suficientes características de éstos para poder realizar un diseño e

implementación basados en objetos. La capacidad para definir clases de objetos

fue aprovechada por los desarrolladores de GForge para estructurar de una forma

lógica el código de la aplicación, basándose en la encapsulación de variables y

métodos dentro de objetos.

En el diseño de GForge, la interfaz de usuario se divide en dos capas claramente

diferenciadas:

• Capa de presentación

• Capa de lógica de negocio



A continuación se describen cada una de ellas.

Capa de presentación

La primera de ellas, la capa de presentación, está constituida por páginas PHP

accesibles por parte de los usuarios. Estas páginas se encargan de generar las

vistas de los distintos módulos de la aplicación, realizando funciones que permiten

al usuario interactuar con el sistema:


Imagen 13: Arquitectura de capas


• Recolección de datos a través de formularios HTML

• Presentación de datos al usuario

• Control de flujo de páginas a mostrar

• Enlaces a los distintos módulos de la aplicación

Este conjunto de páginas PHP se disponen dentro de la estructura de directorios

que GForge genera en el servidor al ser instalado. Este directorio es la raíz de un

host virtual creado en el servidor web Apache, de forma que es accesible a través

desde el exterior. En concreto, la ruta del directorio por defecto en el sistema de

ficheros de Linux es la siguiente:

/usr/share/gforge/www/

Dentro de este directorio raíz, las páginas se estructuran en diferentes

subdirectorios, uno por cada módulo de la aplicación.

Capa de lógica de negocio

Por otro lado, la capa de lógica de negocio está formada por una serie de ficheros

que contienen scripts PHP, en los cuales se declaran las clases y funciones

utilizadas en la aplicación. Estas clases y funciones son las responsables

implementar la lógica de GForge, y son utilizadas desde las páginas PHP de la

capa de presentación. En esta capa se solventan tareas como:



• Control de sesiones

• Acceso a base de datos

• Soporte multilingüe

• Control de accesos y seguridad

• Acceso a los servicios subyacentes al sistema (Mailman, Exim4, CVS...)

Los ficheros correspondientes a esta segunda capa se dispones en el siguiente

directorio:

/usr/share/gforge/common/

Con esta separación se consigue un diseño bastante estructurado que facilita las

labores de mantenimiento de la aplicación. El código de las páginas PHP de

presentación queda bastante limpio, y se reduce al estrictamente necesario para

generar las páginas HTML.

5.1.3 Sistema autónomo : Cron

GForge hace uso del cron de Linux para ejecutar periódicamente ciertos

procesos de back-end que actualizan la información y la configuración del

sistema.



En el sistema operativo Linux, cron es un administrador regular de procesos en

segundo plano ("demonio") que ejecuta programas a intervalos regulares (por

ejemplo, cada minuto, día, semana o mes). Los procesos que deben ejecutarse y

la hora en la que deben hacerlo se especifican en el fichero “crontab” de cada

usuario del sistema. También es posible ejecutar procesos colocando ficheros con

el mismo formato que el “crontab” en la carpeta:

/etc/cron.d

En el proceso de instalación, GForge configura el cron para que ejecute ciertos

scripts PHP y Perl con diferentes intervalos de tiempo. Entre estos realizan tareas

vitales para el sistema como por ejemplo:

• Crear las carpetas en el sistema de ficheros correspondientes a los

nuevos usuarios y grupos del sistema.

• Crear los repositorios CVS para los proyectos.

• Actualizar las estadísticas del sistema.

• Configurar nuevos usuarios LDAP.

• Actualizar el árbol de proyectos.

• Crear listas de correo electrónico en Mailman.

• Envío de mensajes pendientes.

• Limpiar datos obsoletos de la base de datos.

• Generar el tarball diario del repositorio CVS de cada proyecto.



• Crear la página web por defecto de cada proyecto para que sea accesible

desde el exterior.

La ejecución de estos procesos suele realizarse de madrugada (hora local), para

evitar en lo posible sobrecargar el sistema en horas de trabajo.

5.1.4 Configuración de GForge

Otra de las ventajas que presenta GForge es la centralización de la

configuración del sistema en un solo fichero, cuya ruta en el sistema de ficheros

de Linux es:

/etc/gforge/local.inc

Se trata de un script PHP en el que se declaran e inicializan distintas variables

que serán utilizadas por el sistema. Entre los distintos aspectos que se pueden

configurar desde este fichero se encuentran:

• El nombre del dominio del sistema GForge. Esto permite redirigir las

peticiones HTTP desde una máquina a otra.

• El nombre de dominio de las máquinas servidoras de los diferentes

servicios: LDAP, servidor de correo, CVS, Mailman... De esta forma es

posible distribuir los diferentes servicios en distintas máquinas,

aumentando la capacidad de escalabilidad del sistema GForge.

Asignando el mismo nombre a todas las variables podemos hospedar todo

el sistema en la misma máquina.



• Configuración de acceso a la base de datos: usuario, contraseña nombre

de la base de datos, puerto y host donde ésta se encuentra.

• Contraseñas de los distintos servicios (Mailman, Jabber, LDAP).

• Configuración de parámetros específicos de los servicios: LDAP, Jabber

• Disponibilidad global de las distintas herramientas para los proyectos

hospedados.

• Configuración de las rutas donde se encuentran los ficheros de la

aplicación. Esta característica es muy útil para instalaciones

personalizadas.

• Parámetros de sesión como el tiempo de expiración o la clave.

• Configuración por defecto del sistema: nombre, idioma, zona horaria, país,

apariencia...

• Parámetros de seguridad: nivel de permisos, login forzado...

• Configuración de la caché (parámetros para cachear datos en memoria y

acelerar los accesos).

Con la edición de este fichero el administrador puede configurar la aplicación,

adaptándola a las necesidades particulares de cada portal. Esta configuración

puede hacerse “en caliente”, sin necesidad de parar en ningún modo la ejecución

de la aplicación.


AITForge: Gestión de Proyectos Software Diseño de un interfaz propia para AITForge

5.2 Diseño de un interfaz propia para AITForge

El primer paso en la adaptación de GForge para el Área de Telemática de la

ESI será la personalización de la apariencia de la aplicación. Al tratarse de una

aplicación web en PHP, se modificará el código HTML generado hasta conseguir

el aspecto deseado. Características como el color de fondo, el estilo de fuente o el

logotipo serán adaptados de forma homogénea en todas las vistas de la

aplicación.

Para llevar a cabo el diseño de una nueva interfaz y siguiendo la política de

mínimo impacto en el código de la aplicación, se tomará como referencia la

arquitectura de visas planteada en GForge. Dicha arquitectura aprovecha la

orientación a objetos del lenguaje PHP, permitiendo crear nuevas vistas (themes)

mediante la implementación de clases.

5.2.1 Modelo de datos

Para que una nueva vista pase a estar disponible en el sistema GForge es

necesario registrarla en la el medio de almacenamiento persistente. En la base de

datos PostgreSQL encontramos la tabla THEMES, cuyas entradas corresponden

a cada una de las vistas de la aplicación.

El modelo Entidad-Relación del módulo de vistas del sistema AITForge es el

siguiente:



En la siguiente tabla puede apreciarse la estructura de la tabla THEMES.

Tabla: THEMES

Campo Tipo Descripción

theme_id integer Identificador único de la vista.

dirname character varying(80) Directorio en el que se encuentra la clase

Theme de la vista.

fullname character varying(80) Nombre completo de la vista.

enabled boolean Indica si la vista se encuentra o no

habilitada.

Por tanto para dar de alta la nueva vista creada para AITForge será necesario

efectuar una inserción en la tabla THEMES con la siguiente información:


Imagen 14: Modelo ER para las vistas del sistema AITForge.


Campo Valor

theme_id 4

dirname ait

fullname AIT

enabled TRUE

La vista por defecto del sistema puede ser configurada por el administrador del

sistema editando el valor de la variable $sys_theme en el fichero de

configuración /etc/gforge/local.inc. Para establecer la nueva vista

como predeterminada asignaremos a dicha variable el valor 'ait' .

$sys_theme = ait;

Así mismo cada usuario registrado en el sistema podrá configurar su propia vista,

quedando dicha información almacenada en la tabla USERS de la base de datos.



Tabla: USERS


user_id integer Identificador único del usuario.

firstname character varying(60) Nombre de pila del usuario.

lastname character varying(60) Apellidos del usuario.

... ... ...

theme_id integer Identificador de la vista predeterminada del

usuario.

5.2.2 Arquitectura de la nueva vista

El diseño de una nueva vista se basa en la implementación de una clase

llamada Layout, que implementa métodos una serie de métodos que serán

llamados desde las páginas PHP. Éstos métodos generarán el código HTML

común en todas las páginas de la aplicación.



Para crear una nueva vista, bastará con crear una nueva clase de nombre Theme

que herede de la anterior. Sobreescribiendo los métodos de la superclase se

puede controlar el código HTML generado, y de esta forma personalizar estilos,

colores, imágenes...

Los métodos más importantes que se encuentran en la clase Layout y que hereda

Theme son los siguientes:


Imagen 15: Diagrama de clases UML de la vista de AITForge.


header ($params)

Este método genera el código HTML correspondiente a la cabecera que

presentan todas las páginas de la aplicación. Recibe un array de parámetros que

pueden, característica que dota al método una gran flexibilidad en cuanto al

número y el tipo de parámetros que puede recibir. De esta forma, en las distintas

implementaciones de vistas los parámetros que se le pasan al método no tienen

por qué coincidir.

En este método se realizan ciertas operaciones de gran importancia:

• Se define el estilo de la página (fuente, color de fondo...).

• Se ubica el logotipo y la información de interés que ha de aparecer en la

cabecera.

• Se llama a otros métodos de la clase para pintar ciertos elementos como:

campo de búsqueda, pestañas de navegación...

footer($params)

Este método compone el código HTML que constituirá el pié de las páginas

de la aplicación. Al igual que header recibe un array de parámetros.

En el pie de página se suelen ubicar logotipos con enlaces a las distintas

instituciones relacionadas con el portal. En el caso de AITForge se han colocado

links a la página oficial de la Escuela Superior de Ingenieros de la Universidad de

Sevilla y a la página oficial de GForge.



outerTabs($params)

Este método crea una tabla con los títulos y otra tabla con los enlaces de las

pestañas de navegación que serán pintadas en la cabecera. Mediante estas

pestañas los usuarios podrán moverse cómodamente entre las páginas más

destacables del sistema.

projectTabs($toptab, $group)

Crea dos tablas con los títulos y los enlaces de las pestañas de cada una de

las herramientas disponibles en los proyectos hospedados en el sistema. Recibe

como primer parámetro la pestaña seleccionada por defecto y como segundo

parámetro el identificador del proyecto al que se está accediendo en ese

momento.

5.2.3 Estructura de directorios

La nueva vista creada en el sistema implica la creación de los siguientes

directorios en el sistema de ficheros del servidor Linux:

/usr/share/gforge/www/themes/ait

Directorio en el que se encuentran los ficheros principales de la vista:



• Theme.class Script PHP en el que se define la clase Theme de la

vista.

• index_ait.php Página índice de la aplicación AITForge.

/usr/share/gforge/www/themes/ait/images

Directorio en el que se encuentran las imágenes de la vista AIT:

• Logotipo

• Imagen de fondo

• Bordes y esquinas

• Ribetes

/usr/share/gforge/www/themes/ait/images/ic

En este directorio se almacenan los iconos utilizados en la aplicación.

/usr/share/gforge/www/themes/ait/images/tabs

Directorio que contiene las distintas pestañas de navegación del sistema.


AITForge: Gestión de Proyectos Software Diseño del módulo de solicitud de proyectos

5.3 Diseño del módulo de solicitud de proyectos

Una de las carencias fundamentales de GForge para gestionar proyectos fin

de carrera es la gestión de solicitudes de proyectos por parte de los usuarios. Con

el diseño de un módulo de solicitudes de proyectos fin de carrera se solventarán

los casos de uso RF-08, RF-09, RF-12, RF-18, RF-26 y RF-28 detectados en el

análisis de requisitos del sistema.

Para llevar a cabo este módulo será necesario introducir en el sistema un nuevo

rol de acceso, el de profesor. El sistema permitirá a los usuarios realizar varias

operaciones sobre los proyectos, dependiendo de su rol de acceso:

• Los profesores podrán ofertar proyectos, así como acceder a un listado de

proyectos ofertados. Desde ahí tendrán acceso a los listados de alumnos

solicitantes de cada uno de los proyectos y podrán consultar sus datos

académicos y personales. Por último tendrán la posibilidad de asignar los

proyectos ofertados, siendo el evento notificando automáticamente al

alumno.

• Los alumnos podrán rellenar un formulario de solicitud para los proyectos

ofertados y ésta quedará registrada en el sistema. Las solicitudes serán

notificadas por correo electrónico al profesor tutor del proyecto solicitado.

El diseño se integrará en la arquitectura de GForge, de forma que este nuevo

módulo no implique incompatibilidades con nuevas versiones de la aplicación.



5.3.1 Seguridad: gestión de roles

En este nuevo módulo se precisa una gestión de roles que permita asignar a

los usuarios uno de los roles posibles de la aplicación para, de esta manera,

controlar los permisos de dichos usuarios dentro del sistema.

Como se definió en el análisis, los roles del sistema son:

• Administrador

• Profesor

• Usuario registrado

• Usuario no registrado

GForge ya cuenta con una gestión de permisos para tres tipos de usuarios:

administradores, usuarios registrados y usuarios no registrados. Por tanto será

necesario añadir el rol de profesor, de forma que se integre dentro de la aplicación

sin alterar el funcionamiento actual.

Para añadir el nuevo rol de profesor se tomará como modelo la gestión de

administradores, que consiste en la creación de un grupo de administradores. Los

usuarios pertenecientes a este grupo gozan de privilegios de administrador en el

sistema, siendo posible añadir nuevos administradores de forma análoga a como

se añaden usuarios a un proyecto normal.

Así pues, añadiremos la primera acción a llevar a cabo será añadir un nuevo

grupo de profesores en la tabla GROUPS de la base de datos PostgreSQL.



Tabla: GROUPS


group_id integer Identificador único del grupo.

group_name character varying(40) Nombre largo del grupo.

is_public integer Indica si el grupo es o no público.

status character(1) Indica si el grupo está activo (A).

unix_group_name character varying(30) Nombre con formato UNIX.

... ... ...

La nueva tupla contendrá los siguientes datos:

Campo Valor

group_id 5

group_name Teachers Group

is_public 0

status A

unix_group_name teacher

... ...

Para manejar el identificador del grupo de profesores en la aplicación se define

una nueva constante en el fichero de configuración /etc/gforge/local.inc :



$sys_teachers_group=5;

Para asignar a un usuario registrado el rol de profesor bastará con agregarlo al

grupo teacher a través de la propia aplicación. Así mismo para comprobar a

efectos de seguridad si un usuario tiene rol de profesor se tomará como referencia

dicho grupo.

Existe ya en GForge una función que realiza esta labor de comprobación de

pertenencia a un grupo. Dicha función se encuentra en el script PHP /

usr/share/gforge/common/include/session.php y su prototipo es el

siguiente:

session_require($req)

Esta función realiza una serie de comprobaciones sobre el usuario que ha

iniciado una sesión. Una de estas comprobaciones es si pertenece o no al grupo

cuyo identificador se le pasa como parámetro en un array.

5.3.2 Gestión de estados de los proyectos

Los estados posibles de un proyecto definidos en el análisis del sistema son

los enumerados a continuación:



• Proyecto en estudio

• Proyecto ofertado

• Proyecto asignado

• Proyecto en curso

• Proyecto pendiente de defensa

• Proyecto evaluado

El sistema GForge ya contempla estados para los proyectos, pero estos estados

se limitan a:

• Activo

• No activo

• Eliminado

Por tanto este tratamiento no se ajusta a las necesidades de un aplicación de

gestión de proyectos fin de carrera. La modificación de estos estados supondría

un cambio drástico en el funcionamiento del sistema ya que en su diseño no fue

prevista una posible ampliación del número de estados. Por este motivo se hace

necesario buscar una solución alternativa, que funcione de forma independiente y

conviva con la gestión de estados actual.



La solución tomada consiste en gestionar los estados de un proyecto como

categorías del árbol de proyectos de GForge. Este módulo de búsqueda de

proyectos permite agrupar proyectos en categorías jerárquicas que son

configurables por el administrador de la aplicación. De esta forma se añadiría una

nueva categoría padre denominada “Development Status”, de la que colgarían los

distintos estados de un proyecto:

Los profesores podrán cambiar el estado de los proyectos tutelados dentro del

módulo de administración de cada proyecto.

La adición de estos nuevos estados conlleva la modificación de la tabla

TROVE_CAT de la base de datos PostgreSQL.


Imagen 16: Rama de

estados de un proyecto


Tabla: TROVE_CAT


trove_cat_id integer Identificador único de la categoría.

parent integer Identificador de la categoría padre.

root_parent integer Identificador de la categoría raíz.

shortname character varying(80) Nombre corto de la categoría.

fullname character varying(80) Nombre largo de la categoría.

... ... ...

Las tuplas insertadas en esta tabla correspondientes a los estados de los

proyectos fin de carrera contendrán los siguientes datos:

trove_cat_id parent root_parent shortname fullname

6 0 0 developmentstatus Development Status

7 6 6 planning 1. Planning

8 6 6 offered 2. Offered

9 6 6 assigned 3. Assigned

10 6 6 incourse 4. In Course

11 6 6 todefend 5. To Defend

12 6 6 closed 6. Closed




Para este nuevo módulo será necesario la creación de una nueva tabla en el

almacenamiento persistente, la base de datos PostgreSQL. En dicha tabla se

almacenarán temporalmente los datos correspondientes alas solicitudes de los

proyectos.

A continuación se presenta el diagrama de Entidad-Relación:


Imagen 17: Modelo ER para el módulo de solicitud de proyectos


Como se ha anticipado, la relación de “Solicitud” es de cardinalidad n:n por lo que

dará origen a una nueva tabla de base de datos:

Tabla: PROJECT_APPLICATIONS


application_id integer Identificador único de la solicitud.

group_id integer Identificador del proyecto solicitado.

user_id integer Identificador del usuario solicitante.

knowledge_areas text Conocimientos del usuario relacionados con la

naturaleza del proyecto.

subjects_remaining integer Nº de asignaturas pendientes de aprobar por el

usuario.

hours_week integer Horas que el usuario disponible a la semana para

dedicar al proyecto.

comments text Comentarios que el usuario estime interesantes

para completar la solicitud.

application_date integer Fecha de la solicitud.

5.3.4 Arquitectura del módulo

Un nuevo módulo para la aplicación GForge conlleva la implementación



tanto de la capa de presentación como de la capa de lógica de negocio. En la

primera de ellas, la capa de presentación, se creará un nuevo paquete con las

páginas PHP implicadas la interfaz de usuario. En la segunda, la capa de lógica

de negocio, se situarán los scripts PHP que definan las clases y funciones que

implementan la lógica del módulo de solicitudes de proyectos.


Para la interfaz de usuario del nuevo módulo se creará un nuevo paquete

llamado apply compuesto por cuatro páginas PHP:

• index.php Página de entrada al módulo. Presenta una descripción de la

funcionalidad del módulo al usuario y proporciona enlaces a las distintas

vistas del módulo.

• new.php Presenta el formulario de solicitud de proyectos para que los

alumnos puedan registrar sus peticiones.

• admin/index.php Muestra el listado de solicitudes correspondientes a un

proyecto. De esta forma los profesores pueden navegar entre las distintas

solicitudes de un proyecto tutelado y consultar los datos de los alumnos

aspirantes.

• admin/index.php Presenta a los profesores la información

correspondiente a una solicitud de un proyecto. Así pueden valorarse las

aptitudes de los distintos alumnos solicitantes y asignar el proyecto desde

esta misma página.



Formulario de solicitud (new.php)

Los campos a rellenar por el alumno en el formulario de solicitud de peroyecto son

los siguientes:


Imagen 18: Flujo de vistas del módulo de solicitud de proyectos.


Campo Tipo (HTML) Obligatorio Descripción

Áreas de

conocimiento

TEXTAREA Si El usuario puede introducir sus

conocimientos relacionados con la

naturaleza del proyecto solicitado.

Asignaturas

pendientes

SELECT Si Nº de asignaturas pendientes de

aprobar por el alumno.

Horas

disponibles

por semana

SELECT Si Horas disponibles para dedicar al

proyecto fin de carrera por semana,

Comentarios TEXTAREA No Comentarios que el alumno considere

interesantes para completar la

solicitud.

Listado de solicitudes (admin/index.php)

La información mostrada en cada fila del listado de solicitudes de un proyecto es

la siguiente:

• Nombre del usuario.

• Fecha de solicitud.

• Asignaturas pendientes.

• Horas disponibles a la semana.



Desde este listado es posible consultar el detalle de datos de la solicitud.

Detalle de solicitud (admin/applyinfo.php)

La información mostrada en esta vista acerca de la solicitud de proyecto se

compone de los siguientes datos:

• Nombre completo del usuario solicitante.

• Nombre UNIX del usuario solicitante.

• Áreas de conocimiento.

• Nº de asignaturas pendientes.

• Horas disponibles a la semana.

• Comentarios.

Además se presenta un botón de tipo SUBMIT que permite asignar el proyecto fin

de carrera al usuario que realizó la solicitud consultada.

Enlace desde la aplicación al módulo de solicitudes

Para hacer accesible el módulo de solicitud de proyectos fin de carrera se añadirá

como una herramienta más en la página principal de los proyectos. De este modo

aparecerá una nueva pestaña con la etiqueta “Solicitud” sólo en el caso de que el

proyecto se encuentre en el estado “Ofertado”.



Para añadir esta nueva pestaña basta con modificar la clase Theme de la vista

AITForge diseñada para la aplicación. En concreto será necesario modificar la

función projectTabs($toptab, $group) , que es la encargada de generar

las pestañas con sus correspondientes enlaces.


Los ficheros involucrados en la capa de lógica de negocio del nuevo módulo se

incluirán en el paquete apply , dentro de /usr/share/gforge/common . Para

el diseño de este módulo se aplica el patrón Factoría (importado del mundo Java)

aprovechando la orientación a objetos de PHP.

El patrón Factoría es uno de los varios patrones creadores definidos por la GoF16.

La idea que se esconde detrás de este patrón es la de centralizar el sitio donde se

crean los objetos, normalmente donde se crean objetos de una misma "familia",

sin dar una definición clara de lo que nuestro software puede entender como

familia, como podría ser componentes visuales, componentes de la lógica del

negocio, o objetos concurrentes en el tiempo.

La clase factoría devuelve una instancia de un objeto según los datos que se le

pasan como parámetros. Para que la creación centralizada de objetos sea lo más

"útil y eficaz" posible, es de esperar que todos los objetos creados desciendan de

la misma clase o implementen el mismo interfaz (es decir, hagan una operación

similar pero de distintas formas), así podemos usarlos todos de la misma manera,

con los mismos métodos (gracias al polimorfismo), sin importarnos que clase

concreta estamos tratando en cada momento.

16 Gang of Four: denominación del conjunto de autores del libro "Design Patterns” [DP].



El diagrama de clases que implementa el patrón Factoría para este módulo es el

siguiente:

Las páginas PHP de la capa de presentación trabajarán con estas clases para

realizar las distintas operaciones solicitados por los usuarios. A continuación de

describe con algo más de detalle el funcionamiento de las clases anteriores:


Imagen 19: Diagrama de clases UML del módulo de solicitudes


Clase: Application

Esta clase representa en memoria a una solicitud de proyecto presente en el

sistema, es decir, mapea los datos de una tupla de base de datos en un objeto.

Realiza todas las operaciones de base de datos relacionadas con las solicitudes

de proyectos: inserción, modificación y eliminación.

Uno de sus métodos permite asignar un proyecto al usuario que lo ha solicitado.

Esta asignación implica una secuencia de acciones:

• Añadir al usuario como administrador del proyecto.

• Modificar el estado del proyecto de “Ofertado” a “Asignado”.

• Eliminar de base de datos el conjunto de solicitudes del proyecto.

• Enviar un correo de notificación al alumno asignado.

Además lleva a cabo otro tipo de operaciones como la validación de campos o el

envío de correos de notificación.

Clase: ApplicationFactory

Actúa como factoría de objetos Application, creando instancias de estos para que

sean utilizados desde cualquier punto de la aplicación. Por ejemplo, el método

que devuelve la lista de solicitudes de un proyecto se utiliza el la página que

muestra el listado de solicitudes.




Los ficheros implicados en el módulo de solicitud de proyectos se dividen a

grandes rasgos en dos grupos:


Ficheros que implementan la interfaz de usuario:

/usr/share/gforge/www/apply

Directorio que contiene las vistas principales del módulo. Son accesibles por todos

los usuarios. Los ficheros de este directorio son:

• index.php Página inicial del módulo.

• new.php Formulario de solicitud de proyecto.

/usr/share/gforge/www/apply/admin

Directorio en el que se encuentran las vistas administrativas del módulo. Son

accesibles sólo por el profesor tutor en cada proyecto:

• index.php Listado de solicitudes del proyecto.



• applyinfo.php Información de detalle de la solicitud y asignación.

/usr/share/gforge/www/apply/include

Directorio que contiene scripts PHP con funciones de presentación auxiliares:

• apply_utils.php Contiene funciones de generación de menús.


Ficheros relacionados con la funcionalidad del módulo:

/usr/share/gforge/common/apply

• Application.class Definición de la clase Application.

• ApplicationFactory.class Definición de la clase ApplicationFactory.


AITForge: Gestión de Proyectos Software Diseño de un módulo de generación dedocumentos

5.4 Diseño de un módulo de generación dedocumentos

La gestión de los documentos oficiales para los proyectos fin de carrera es

otro de los aspectos a automatizar a través de la aplicación AITForge. Existen

varios modelos de documentos oficiales relacionados con la solicitud y

adjudicación de proyectos fin de carrera que actualmente han de ser rellenados a

mano por los alumnos. El objetivo de este módulo es canalizar la generación de

documentos a través del sistema AITForge, normalizando el contenido de los

mismos.

Los documentos serán generados a partir de los datos personales y académicos

del alumno, así como con la información específica del proyecto solicitado o

adjudicado.

Esta documentación oficial será generada en formato PDF, por ser este formato

uno de los más extendidos para los documentos transmitidos por la red Internet.

Para la composición de documentos PHP mediante el lenguaje de programación

PHP se utilizará la librería FPDF, utilidad de Software Libre distribuida bajo

licencia GPL.


La información relacionada con los proyectos necesaria para la generación

de los documentos oficiales está ya disponible en la tabla GROUPS de la base de



datos del sistema. En cuanto a la información de los alumnos, la única carencia

del sistema actual son los datos académicos relacionados con la titulación y la

especialidad cursada. Por ello se hace necesario la modificación de la base de

datos para soportar el siguiente modelo de datos:

Del diagrama de Entidad-Relación de la Imagen 20 se deduce la necesidad de

añadir tres nuevas tablas en la base de datos del sistema:


Imagen 20: Modelo ER para el módulo de documentación.


Tabla: ESI_CAREERS


career_id integer Identificador único de la titulación.

career_title character varying(80) Título de la titulación.

Tabla: ESI_CAREER_SPECIALITY


speciality_id integer Identificador único de la especialidad.

career_id integer Identificador de la titulación a la que

pertenece.

speciality_title character varying(80) Título de la especialidad.

Tabla: ESI_USER_CAREER


user_id integer Identificador del usuario.

speciality_id integer Identificador de la especialidad.

career_id integer Identificador de la titulación

(Desnormalización para optimizar la

consulta SQL).

Los datos introducidos en las tablas ESI_CAREERS y



ESI_CAREER_SPECIALITY son los siguientes:

Tabla: ESI_CAREERS

career_id career_title

0 Ingeniero Industrial

1 Ingeniero de Telecomunicación

2 Ingeniero Químico

3 Ingeniero de Organización Industrial

4 Ingeniero de Automática y Electrónica Industrial

5 Ingeniero en Electrónica

6 Ingeniero Aeronáutico



Tabla: ESI_CAREER_SPECIALITY

speciality_id career_id career_title

0 0 Eléctrica

1 0 Mecánica

2 0 Organización

3 0 Química

4 1 Telemática

5 1 Señales y Comunicaciones

6 1 Electrónica de Comunicaciones

7 1 Telecontrol y Robótica

8 2 Industrial

9 2 Medio Ambiente

10 3 Gestión

11 3 Sistemas de Producción

12 4 Control de Procesos

13 4 Electrónica Industrial

14 4 Robótica

15 5 Microrobótica

16 5 Tecnología Electrónica

17 6 Aeronaves y Vehículos Espaciales

18 6 Producción Aeronáutica

19 6 Infraestructura del transporte Aéreo



5.4.2 Arquitectura

Análogamente al módulo de solicitud de proyectos, el diseño se dividirá en

dos partes: la capa de presentación y la capa de lógica de negocio.


En este módulo se incluye una vista que presenta el listado de los

documentos oficiales de la ESI disponibles en la aplicación. Como siempre se

pretende integrar el nuevo módulo en la aplicación GForge primitiva, causando el

menor impacto posible. Por ello, el acceso a este listado se realizará desde las

opciones de menú del módulo de documentación denominado Docman, que ya

incluye GForge.

En el paquete docman dentro del directorio /usr/share/gforge/www , se

añadirá una nueva página PHP, que genere la vista con el listado de documentos

oficiales:

• esi_docs.php Página de entrada al módulo. Presenta un listado de los

documentos oficiales disponibles desde la aplicación.

La entrada al módulo implica la modificación del fichero doc_utils.php del

paquete /usr/share/gforge/www/docman/include . En este fichero se

modifica la función encargada de generar el menú del módulo Docman, añadiendo

un nuevo enlace a esi_docs.php .



A efectos de seguridad, el módulo de documentos oficiales sólo será accesible por

el alumno proyectando al que le haya sido asignado el proyecto y al profesor tutor

del mismo. También tendrán acceso los administradores del sistema.

Por cada documento generado desde la aplicación tendremos una página PHP en

el paquete pdf del directorio /usr/share/gforge/www . En estas páginas se

hace uso de las clases de la capa de lógica de negocio diseñadas en el siguiente

apartado, para enviar al usuario el documento PDF generado dinámicamente.

• projectassign.php Página encargada de mostrar el

documento de asignaci de proyectos fin de carrera que el alumno ha de

presentar en la secretaría de la ESI.


El diseño de la arquitectura de clases que implementan la lógica de negocio


Imagen 21: Flujo de vistas del módulo de documentos.


se basará en la clase FPDF. Dicha clase se distribuye bajo licencia GPL y permite

la creación de documentos PDF desde el lenguaje de programación PHP. En el

Anexo A, se describe detalladamente la esta librería. Simplemente mencionar

aquí que se instala en el directorio /usr/share/fpdf del sistema de ficheros

de GNU/Linux.

Esta librería permite a su vez la creación de fuentes TrueType propias, por lo que

se ha generado una fuente para la aplicación AITForge, denominada “aitforge”.

El diagrama de clases correspondiente a este diseño es el siguiente:

En este diagrama se aprecia cómo la clase EsiPDF hereda directamente de


Imagen 22: Diagrama de clases UML del módulo de documentos.


FPDF, y por tanto adquiere toda su funcionalidad. En esta nueva clase se

implementan dos métodos abstractos de la superclase FPDF, que son llamados

automáticamente en cada página del documento PDF:

• Header() En él se crea la cabecera estándar de los documentos

oficiales de la ESI. Se incluyen los logotipos de la ESI y de la Universidad

de Sevilla.

• Footer() Genera el pie en cada una de las páginas del documento.

Además se implementan otra serie de métodos que serán comunes en todos los

documentos generados en el sistema como son:

Finalmente, tendremos una clase por cada uno de los documentos oficiales

generados desde la aplicación, que implementan la adquisición y presentación de

datos específicos de cada uno. Todos ellos heredan de la clase EsiPDF, y por

tanto adquieren toda su funcionalidad.


En este apartado se describe la distribución en directorios del sistema

operativo Linux de los distintos ficheros que conforman este módulo de

documentos oficiales.




/usr/share/gforge/www/docman

Directorio del módulo Docman que ya existía en GForge. En este directorio se

sitúa el nuevo fichero:

• esi_docs.php Página PHP que muestra el listado de documentos

oficiales de la ESI.

/usr/share/gforge/www/pdf

En este directorio se sitúan las páginas encargadas de generar y enviar los

distintos documentos:

• projectassign.php Página que genera el documento de saignación

de proyectos.


/usr/share/gforge/common/pdf

Directorio en el que se encuentran las clases implicadas en la generación de

documentos.

• EsiPDF.class Definición de la superclase EsiPDF. A su vez hereda de

la clase FPDF.



• ProjectAssignPDF.class Definición de la clase ProjectAssignPDF

que genera el documento de asignación de proyectos.

/usr/share/fpdf/font

Directorio en el que se encuentra la nueva fuente creada para AITForge.

• aitforge?.afm Ficheros de métrica de la fuente.

• aitforge?.pfb Ficheros de definición de la fuente.


AITForge: Gestión de Proyectos Software Batería de pruebas

6 Batería de pruebas

En este capítulo se realizarán un conjunto de pruebas de la funcionalidad de

la aplicación AITForge, recorriendo los diferentes módulos añadidos en este

proyecto fin de carrera. El objetivo de este protocolo de pruebas es asegurar el

correcto funcionamiento de la aplicación, así como comprobar que satisface los

requisitos establecidos en el análisis.

Durante las pruebas se realizaran capturas de pantalla de las distintas vistas que

constituyen los módulos. Dichas capturas se incluyen en este capítulo y servirán

como guía visual para los usuarios del sistema.


AITForge: Gestión de Proyectos Software Nueva vista del sistema: AITForge

6.1 Nueva vista del sistema: AITForge

6.1.1 Página principal

La primera de las modificaciones que la aplicación AITForge presenta con

respecto a su predecesora GForge es la apariencia.


Imagen 23: Pantalla principal de AITForge.


La pantalla principal del sistema presenta ahora una presentación del portal de

gestión de proyectos fin de carrera del Área de Telemática de la ESI. A grandes

rasgos destaca el nuevo logotipo creado para la ocasión, y los enlaces a la página

oficial de la Escuela Superior de Ingenieros y a

Las pestañas de navegación permiten al usuario recorrer cómodamente la

aplicación y la tabla de estadísticas situada en la parte izquierda muestra de forma

resumida los datos actualizados del sistema. Por último en la tabla inferior irán

apareciendo las noticias que el administrador del sistema estime más

interesantes.

6.1.2 Página inicial de un proyecto

En la siguiente vista, se puede observar la página inicial de un proyecto, que

presenta información general acerca del mismo. Las pestañas de navegación

permiten elegir las distintas herramientas que AITForge proporciona para los

proyectos.



6.1.3 Árbol de proyectos

El árbol de proyectos permite a los usuarios buscar proyectos por categorías y

estados (ofertado, asignado, en curso...). Es una forma rápida de consultar todos

los proyectos hospedados en AITForge, a través de la pestaña “Árbol de

proyectos”.


Imagen 24: Página inicial de un proyecto.


6.1.4 Registro de usuarios

En la página de registro los usuarios introducen sus datos personales para

darse de alta en la aplicación. De esta forma adquieren privilegios de usuarios

registrados como por ejemplo la solicitud de proyectos fin de carrera. A esta vista

se accede mediante el enlace “Nueva cuenta” de la página principal.


Imagen 25: Árbol de proyectos.


Una vez que el usuario se encuentra registrado en la aplicación puede entrar en el

sistema a través de la pantalla de login, accesible desde el enlace “Login” de la

pantalla principal.


Imagen 26: Página de registro de usuarios.


6.1.5 Página personal de usuario

En esta página el usuario tiene acceso a información personalizada como:

proyectos a los que pertenece, ficheros monitorizados, foros preferidos, tareas

asignadas...


Imagen 27: Página de login.



Imagen 28: Página personal de usuario.

AITForge: Gestión de Proyectos Software Módulo de solicitud de proyectos

6.2 Módulo de solicitud de proyectos

En este apartado se muestran las capturas de pantalla correspondientes al

módulo de solicitud de proyectos fin de carrera, incorporado como ampliación en

la aplicación AITForge.

Se realizará una prueba de solicitud de proyecto por parte de los alumnos y otra

prueba de asignación de proyectos por parte del profesor.

6.2.1 Solicitud de proyecto

Una vez que el alumno accede a la página inicial de un proyecto cuyo estado

sea “Ofertado”, el sistema mostrará entre las pestañas de herramientas una con el

título “Solicitud”. Pulsando sobre esta pestaña el alumno accede a la página inicial

del módulo de solicitud de proyectos.



Pulsando sobre la opción “Solicitar” el alumno accede al formulario de solicitud,

cuyos datos ha de rellenar antes de registrar la solicitud. Estos datos son de

carácter académico y servirán posteriormente al profesor para realizar una

primera valoración de los candidatos.


Imagen 29: Página inicial del módulo de solicitud de proyectos.


Una vez registrada la solicitud se informa al alumno, mediante una pantalla de

confirmación, del envío de un correo con los datos de su solicitud al tutor del

proyecto. Estos datos quedan además almacenados en base de datos.


Imagen 30: Formulario de solicitud de proyecto.


De esta forma el alumno queda a la espera de que el profesor se ponga en

contacto con él para concertar una entrevista o solicitarle información adicional.

6.2.2 Consulta de solicitudes y asignación de proyectos

El profesor tutor de un proyecto fin de carrera que se encuentra en estado

“Ofertado” puede desde la aplicación consultar las solicitudes que los alumnos

han realizado. Para ello debe acceder a la página inicial del proyecto, y desde ahí


Imagen 31: Página de confirmación de solicitud.


entrar en el módulo de solicitud. Desde la página inicial de este módulo ha de

pulsar sobre la opción “Administración” y de esta forma acceder al listado de

solicitudes del proyecto.

En este listado se muestran los nombres de los alumnos solicitantes junto con

algunos datos de interés. Pulsando sobre la opción “Ver detalles” de la fila de uno

de los alumnos del listados se accede al detalle de la solicitud.


Imagen 32: Listado de solicitudes de un proyecto.


Desde este detalle el tutor puede llevar a cabo la asignación del proyecto al

usuario en cuestión, desencadenándose el conjunto de acciones que dicha

asignación implica. Para ello bastará con pulsar sobre el botón “Asignar”.


Imagen 33: Detalle de la solicitud de un proyecto.


Una vez asignado el sistema presenta una pantalla de confirmación, donde se

informa al profesor del envío de un correo informativo al alumno.


Imagen 34: Pantalla de confirmación de asignación

AITForge: Gestión de Proyectos Software Módulo de documentos oficiales de la ESI

6.3 Módulo de documentos oficiales de la ESI

Este módulo permite la generación dinámica de documentos oficiales de la

ESI relacionados con la gestión de proyectos fin de carrera. Estarán disponibles

para los alumnos que tengan ya asignado un proyecto fin de carrera, y serán

rellenados automáticamente con los datos de dichos alumnos. Dos requisitos para

acceder a este módulo son estar registrado en la aplicación y tener asignado un

proyecto fin de carrera.

Un paso previo a la generación de un documento es el registro por parte de los

alumnos de cierta información académica, como son la titulación y la especialidad

cursadas. Para ello el alumno debe acceder a la página de registro de información

académica mediante la opción “Información académica” que se encuentra en la

página personal.



Una vez cumplimentado este paso, el alumno podrá navegar hasta la página

inicial de su proyecto fin de carrera, y pinchando en la pestaña “Documentos”

acceder al módulo de “docman” (gestión genérica de documentos).


Imagen 35: Página de registro de información académica.


Desde aquí, pulsando en la opción “Documentos oficiales de la ESI”, el alumno

accede a otra página que presenta un listado con los documentos oficiales

disponibles en ese momento.


Imagen 36: Página inicial de docman.


Por último, pinchando sobre el icono situado junto a alguno de los documentos de

la lista, el sistema generará un nuevo documento en formato PDF con los datos

del proyecto y del alumno registrado en la aplicación.


Imagen 37: Listado de los documentos oficiales de la ESI.

AITForge: Gestión de Proyectos Software Bibliografía

7 Bibliografía

Referencias bibliográficas

CRS: Cambio de rumbo en SourceForge (2002), Carlos Cortes Cortes

http://bulma.net/body.phtml?nIdNoticia=1165

DP: Design Patterns: Elements of Reusable Object-Oriented Software (),

Erich Gamma, Richard Helm, Ralph Johnson y John Vlissides,

Addison Wesley Professional, ISBN: 0-201-63361-2

FOSPH: A Corner for Research in Free/Open Source Project Hosting Sites

(2004), Haggen So http://www.ibiblio.org/fosphost/

FSGNU: The free software definition (1984), Richard M. Stallman

http://www.gnu.org/philosophy/free-sw.html

FSOS: Open Source and Free Software (1995), Richard M. Stallman

http://www.gnu.org/philosophy/free-software-for-freedom.html

GF: Sitio web oficial de GForge, Tim Perdue http://gforge.org

GNA: GNA! Sitio web oficial de desarrollo de proyectos FSF, Free Software

Foundation http://gna.org

MGNU: Manifiesto GNU (1985), Richard M. Stallman

http://www.gnu.org/gnu/manifesto.html


AITForge: Gestión de Proyectos Software Bibliografía

OS: Open Sources (1998), Richard M. Stallman, O'Reilly,

ISBN: 1-56592-582-3

OSDI: Operating Systems: Design and Implementation (1987), Andrew

Stuart Tanenbaum, Prentice Hall, ISBN: 0-13-638677-6

PHPjKT: Sitio oficial de PHProjekt (), Albrecht Günther

http://www.phprojekt.com

SVNH: Sitio oficial de desarrollo de proyectos GNU, GNU Project

http://savannah.gnu.org


AITForge: Gestión de Proyectos Software Anexo A

8 Anexo A

La librería FPDF consta de una clase escrita en lenguaje PHP, que aporta

métodos que permiten la creación dinámica de documentos PDF desde este

lenguaje de programación. Se distribuye como Software Libre bajo licencia GPL,

por lo que se convierte en una alternativa muy recomendable para generar

informes y otro tipo de documentos desde aplicaciones libres.

8.1 ¿Qué es FPDF?

FPDF es una clase escrita en PHP que permite generar documentos PDF

directamente desde PHP, es decir, sin usar la biblioteca PDFlib. La ventaja es

que, mientras PDFlib es de pago para usos comerciales, la “F” de FPDF significa

Free (gratis y libre): puede usted usarla para cualquier propósito y modificarla a su

gusto para satisfacer sus necesidades.

FPDF tiene otras ventajas: funciones de alto nivel. Esta es una lista de sus

principales características:

* Elección de la unidad de medida, formato de página y márgenes

* Gestión de cabeceras y pies de página



* Salto de página automático

* Salto de línea y justificación del texto automáticos

* Admisión de imágenes (JPEG y PNG)

* Colores

* Enlaces

* Admisión de fuentes TrueType, Type1 y codificación

* Compresión de página

FPDF no necesita de ninguna extensión para PHP (excepto la biblioteca zlib si se

va a activar la opción de compresión) y funciona con PHP4 y PHP5.

Los tutoriales le permitirán empezar rápidamente a usar FPDF. La documentación

completa (on line) se encuentra aquí y el área de descarga, aquí. Se recomienda

encarecidamente que lea las FAQ (o PMF: preguntas más frecuentes), que listan

las preguntas y problemas más comunes (especialmente los relacionados con los

navegadores).

Existe una sección de scripts que incluye algunas extensiones útiles (como

señaladores o rotaciones).

También existe admisión de GIF.



8.2 ¿Qué idiomas puedo usar?

La clase genera documentos en muchos otros idiomas aparte de los

europeos occidentales: europeo central, ciríloco, griego, báltico y tailandés, si se

dispone de fuentes TrueType o Type1 con el conjunto de caracteres adecuado. El

chino y el japonés también están admitidos.

8.3 ¿Y qué hay de la eficiencia?

Como es lógico, la velocidad de generación de un documento es menor que

con PDFlib. Sin embargo, la desventaja en cuanto a rendimiento es muy

razonable y se adecúa a la mayoría de los casos, a no ser que sus documentos

vayan a ser especialmente complejos o extensos.

8.4 ¿Cómo funciona?

En la web oficial del proyecto FPDF (www.fpdf.org), se proporciona un

completo soporte técnico para programadores en distintos idiomas (incluido el

castellano). Entre las secciones que pueden encontrarse en este sitio se

encuentran:



• tutoriales

• manual de programación

• foros

• FAQ

• Enlaces de interés


Proyecto Fin de Carrera - Universidad de...

Documents

Transcript of Proyecto Fin de Carrera - Universidad de...