\chapter{Conclusiones}


\section{Aportaciones e impacto del proyecto}

{\it Efficiency Guardian} permite al usuario controlar la eficiencia de fragmentos específicos de código.
El control puede llevarse a cabo explícitamente, mediante una petición del desarrollador para controlar la eficiencia de cambios locales,
e implícitamente al confirmar cambios en el servidor gracias a su integración en {\it testfarm}.
El usuario puede comprobar el historico de cambios desde el interfaz web para detectar los que han alterado significativamente la eficiencia.
Además, podrá ser avisado mediante alarmas configurables por el propio usuario
cuando las alteraciones sobrepasen cierto umbral.
http://www.sport.es/
{\it Efficiency Guardian} se integra en el ciclo de desarrollo de {\it Extreme Programming}
debido a que usa conceptos y herramientas que ya se utilizan en {\it XP} ({\it xUnit}, casos de tests, test suites, {\it Refactoring}...).
Su integración permite controlar la variación de eficiencia causadas por la refactorización del código,
con lo cual, el código se desarrollará teniendo en cuenta el diseño y también la optimización.
% dgg: A parte de integrarse por que usa conceptos y herramientas, tambien se integra en el proceso de desarrollo enriqueciendolo. Comenta algo, si sabes de que hablo.
{\it Efficiency Guardian} usa y es software libre, se ha desarrollado siguiendo metodologías y herramientas {\it Open Source}.
%Enriquecimiento:
% 	- Integración en otras herramientas open source (testfarm)
% 	- ampliación del ciclo de desarrollo XP
% 	- Reconciliación de optimización con ingeniería de software
% 	- ...

%- impacto
%	- Comunidad open source
%	- usado actualmente
%	- con expectativas que lo use más gente
{\it Efficiency guardian}  tiene y va a tener impacto más allá del proyecto de final de carrera.
La herramienta presentada está siendo usada en proyectos del {\it Grupo de Tecnología musical} de la {\it Universitat Pompeu Fabra} como {\it CLAM} o {\it Essentia}.
Su uso en estos proyectos implica que la herramienta seguirá creciendo y se estabilizará 

Además, se ha informado de la existencia de {\it Efficiency Guardian} en la lista de correo de {\it Valgrind}.
El acogimiento fue satisfactorio y el interés mostrado se centró en su funcionalidad 
para una posible integración en Kcachegrind.

Finalmente, la herramienta es accesible desde {\it Sourceforge} \href{http://www.sourceforge.net}
con el que se espera involucrar a la comunidad {\it Open Source},
para que se use en diversos proyectos y este hecho aporte nuevas mejoras a la herramienta en cuanto a código, nuevas ideas,...


\section{Lecciones aprendidas}

Este proyecto me ha hecho crecer en varios aspectos como ingeniero informático
ya que he adquirido y/o ampliado conocimientos en los diferentes ámbitos del proceso de desarrollo.

Desarrollando con {\it Test Driven Development},
he ganado en visión a la hora de estructurar el código,
he agilizado mi ritmo de desarrollo,
me ha facilitado la búsqueda de errores funcionales,
me ha enseñado a plantearme la funcionalidad que quiero lograr antes de programarla
y, como al pasar un test, se verifica que el código testeado realiza su funcionalidad correctamente,
me ha aportado seguridad a la hora de programar.

Por otro lado, haber formado parte de un proyecto {\it Open Source} ha ampliado mis perspectivas de como puede llevarse a cabo un desarrollo
no sólo por haber conocido y usado una gran variedad de nuevas herramientas como
{\it Valgrind} \ref{sec:callgrind}, {\it CVS} \ref{sec:cvs}, {\it Python} \ref{sec:python}, {\it Apache}, {\it Mod Python} \ref{sec:apache}, {\it xUnit} \ref{sec:xunit}, {\it TestFarm} \ref{sec:testfarm} o {\it ploticus} \ref{sec:ploticus},
sino también por haber adquirido conocimiento más profundo de cómo se desarrolla en entornos {\it Open Source}.

El haber estado comunicado con una comunidad {\it Open Source} durante todo este tiempo, 
me ha aportado información y contactos útiles a la hora del desarrollo.
En definitiva me ha enseñado una nueva forma de trabajar en equipo.

Durante la elaboración de la memoria, he aprendido a buscar información, analizarla y sintetizar los conceptos clave.
Esta información ha sido obtenida desde diferentes tipos de fuentes.
La información teórica y conceptual ha sido extraída de {\it papers}, libros y páginas de Internet.
las {\it mailing lists} me han dado información a bajo nivel de las herramientas usadas.

Finalmente, he adquirido experiencia en la planificación y detección de riesgos.
Inicialmente obvié ciertas limitaciones de recursos cuya consideración en  el momento oportuno hubieran evitado costes en tiempo y esfuerzo.
Estos hechos han supuesto que sea más consciente de la importancia de una buena planificación de manera que, al planificar un nuevo proyecto, tenga en cuenta limitaciones temporales, de recursos y sea capaz de jerarquizar las tareas por orden de prioridad.

El hecho de haber extraído los requisitos del sistema preguntando a los futuros usuarios del software,
me ha hecho tener contacto directo con el usuario.


% dgg: En otras universidades se exige en las conclusiones un computo economico (en horas/persona)
% dgg: Creo que no vale la pena que lo hagas (y no es muy util si se hace a la brava), 
% pero estaria bien si pudieras concretizar un poco, que es lo que se ha extendido mas,
% como se han alterado tus previsiones. 
% Aunque quizas es mejor aun ponerlo en una seccion al final de 'diseño y desarrollo' 
% donde expliques como ha sido el proceso de desarrollo, que vaivenes han habido,
% las planificaciones y como has tenido que corregirlas
% y aqui poner solo las conclusiones y referenciar para atras.


%- Conocimientos adquiridos
%	- Uso de metodologías XP
%		- TDD
%		- Refactoring
%	- Metodologías open source
%		- Herramientas
%		- Comunicación con comunidad mediante mailing lists
%	- Analizar y sintetizar información
%		- papers
%		- libros
%		- mailing lists
%		- Entrevista usuarios
%	- Aprendizaje gradual de la planificación

\section{Líneas futuras}

Las tres líneas que deben seguir trabajándose en el futuro son sobre las limitaciones provocadas por el uso de {\it Valgrind}, ampliar la funcionalidad de la interfaz web y la creación de tests de eficiencia en otros lenguajes.

Debido a que Valgrind no es multiplataforma, hay sistemas operativos como Windows en los cuales no se puede ejecutar {\it EfficiencyGuardian}. 
Las opción más viable para remediar este problema es adaptar el parser {\it EfficiencyGuardian} a otra herramienta que permita la ejecución en Windows.

Respecto a la interfaz web, hay varios puntos a mejorar.
Por un lado, debido a que los listados de tests y alarmas pueden llegar a ser muy largos, debería ser posible que los listados sean desplegables, tanto por proyecto como por suite de tests de manera que sea más sencillo para el usuario encontrar un test concreto.

Por otro lado, el listado de tests únicamente muestra el valor de los ciclos ya que mostrar los 12 valores más la variación de eficiencia sería contraproducente para el usuario, ya que dificultaría la observación de los resultados.
Sin embargo, si que sería interesante que, al clickar sobre el test, se abriera un pop-up en el cual se mostraran todos los valores del test en concreto.
De esa manera, no sobrecargamos de valores la interfaz y podríamos tener conocimiento específico de cada uno de los tests.

También es una idea interesante poder notificar al usuario de las alarmas lanzadas por diferentes vías a parte de la interfaz web.
Una opción sería que los usuarios tuvieran la posibilidad de introducir su dirección de correo electrónico en una mailing list de manera que, cuando saltaran las alarmas de ciertos tests, el usuario fuera avisado mandándole un e-mail.

La creación de tests de eficiencia en otros lenguajes de programación es una idea interesante por dos motivos.
Primeramente, por la facilidad que implica cambiar los tests de eficiencia a otro lenguaje ya que {\it Valgrind} toma el binario para realizar el profiling y,por lo tanto, puede ejecutar el código de cualquier lenguaje que haya sido compilado. Ésto significa que realizar el cambio a otros lenguajes de programación se limita a crear la librería donde se crean los métodos {\it Start()} y {\it Stop()} en el lenguaje deseado y comprobar la estructura de los nombres mostrados en el fichero de salida de {\it Callgrind} por si hay que retocar el parser de {\it EfficiencyGuardian}.
El segundo motivo es que, si los tests de eficiencia están accesibles en más lenguajes, implica que habrá más gente dispuesta a utilizarlos y a involucrarse en el mantenimiento del proyecto, con lo cual, aseguraríamos la evolución de {\it EfficiencyGuardian}.

% (N) ---> necesario
% (I) ---> interesante implementarlo
%
% limitaciones Valgrind/Callgrind
% 	- plataforma
% 	- S.O
% 	- adaptación a otra herramienta similar para otra plataforma
%	
% Interfaz Web
% 	- Listado de tests
% 		- por orden de alteración de eficiencia (N)
% 		- Agrupados por suites
% 			- listado deplegable
% 	- Especificación valores del test (N)
% 	- Alarmas
%		- configuración alarmas
% 		- listado ordenado por tipo de alarma (N)
% 		- agrupados por suites
% 			- listado desplegable
% 		- Aviso vía mail   (I)	
% 		- aviso vía TestFarm (I)
% 	- graficos
% 		- visualización de progresion en ciclos (N)
% 		- visualizacion de progresión en resto de valores (It, Dr, Dw,...) (N)
%		- 'top 10' de los tests con mayor alteración de eficiencia

