Oferta de Trabajos Fin de Máster propuestos por los profesores
para este curso

Presentación

 

El Trabajo Fin de Máster es una asignatura de 15 créditos ECTS, de carácter obligatorio y duración semestral, ubicada en el segundo semestre, del Máster Universitario de Investigación en Ingeniería de Software y Sistemas Informáticos.

Esta asignatura está dirigida a realizar un trabajo de especialización e iniciación a la investigación, en las líneas propias del Máster, que supondrá para los estudiantes una complementación final de las competencias adquiridas en el resto de asignaturas cursadas mediante, por un lado, una recapitulación y aplicación especializada de sus contenidos y, por otro, una aproximación a la actividad investigadora.

En esta asignatura, el alumno debe adquirir las competencias necesarias para plantear y desarrollar un trabajo de investigación, de profundización e implementación original, bajo la dirección de alguno de los profesores del Máster, que actuará de Director.  Para establecer el tema del trabajo, el alumno debe contactar con el profesor de la asignatura más cercana, tanto a las líneas de trabajo ofrecidas como a sus intereses formativos, y consensuar con él los objetivos y el plan de trabajo de su Trabajo Fin de Máster. Aunque cada trabajo se enmarca en una línea de investigación determinada (próximo a alguna asignatura del Máster), el objetivo de esta asignatura no es sólo la profundización en algún aspecto de dicha línea, sino el de la adquisición de competencias complementarias que tienen que ver con la capacidad de relacionar los contenidos de las asignaturas cursadas en el Máster, la perspectiva global de los aprendizajes adquiridos, para elaborar nuevas soluciones a los problemas planteados.

Toda la Titulación está orientada al objetivo de incrementar las capacidades, habilidades y destrezas de los estudiantes para mejorar algo, algún ‘artefacto’ que, en el itinerario de Ingeniería de Software (o asignaturas CFF), estará relacionado con la producción de software y, en el itinerario de Ingeniería de Sistemas Informáticos (o asignaturas complementarias), lo estará con el espectro de aplicación de dichos sistemas informáticos o alguno de sus componentes. Pero en la asignatura Trabajo Fin de Máster, el objetivo fundamental del trabajo es que el estudiante muestre sus capacidades y destrezas para mejorar algo, para aportar un valor cualitativo y sustancial a un objeto. Ese ‘artefacto’, objetivo de la mejora, puede ser un sistema software (se mejora algún aspecto de sus prestaciones y cualidades, de su elaboración, de la gestión de su desarrollo o de la de su comportamiento, etc.) o algún aspecto de un componente hardware o de un sistema informático. Pero también puede ser de índole metodológico, procedimental o un tratamiento ‘teórico’ de alguno de los elementos anteriores. Por otro lado, aunque ésta sea una titulación de naturaleza tecnológica, en ningún caso puede estar exenta del rigor científico. Puesto que no se puede soslayar que “la mejora” de algo, cualquier cosa que se aporte para dicha mejora, debe estar justificada, contrastada y verificada; bien sea empíricamente (en condiciones de experimentación bien definidas, controladas y repetibles) o mediante la demostración formal. En este sentido se realizará dirección y la evaluación del trabajo fin de Máster.

En la modalidad de Trabajo Fin de Máster Tipo A (Trabajo específico propuesto por un profesor), los profesores que imparten docencia en cada asignatura TFdM, ofrecen una temática específica que se corresponde con la línea, de su adscripción, que se enumera a continuación. Este trabajo puede ser realizado por uno o varios alumnos, a discreción del profesor que lo propone.

Muy importante: la especificidad de estos trabajos se refiere a las líneas de investigación o su aplicación. En general, los enunciados propuestos no se deben considerar como ejercicios concretos, de desarrollo único; si no como la demarcación de un abanico de posibilidades en torno a unos objetivos de trabajo localizados. Por este motivo, la valoración de la proximidad de las propuestas del alumno respecto a la línea planteada por el profesor (tipo A o tipo B), queda supeditada al acuerdo entre ambos.

El alumno interesado en realizar uno de estos trabajos (o cercanos a estas líneas) deberá ponerse en contacto con el profesor correspondiente y preguntar si el trabajo se encuentra disponible o ya ha sido asignado a otro alumno y realizar la tramitación de la documentación necesaria con una antelación mínima de un cuatrimestre respecto a la convocatoria del acto de defensa a la que piensa presentarse.

Los Trabajos Fin de Máster propuestos —sobre alguna de estas líneas de investigación— son:

Como se puede observar, estas líneas de trabajo se corresponden con las asignaturas del plan de estudios y las que proponen temas más específicos son 2/3 de ellas.

Tal como se especifica en el Reglamento del TFM, en todos los casos, como resultado del trabajo fin de master, el documento principal que se deberá entregar es una memoria explicativa que incluirá, al menos, los siguientes apartados en el 'cuerpo del trabajo':

A continuación, se especifica la presentación y el planteamiento de cada temática propuesta:

Gen Móvil: generador automático de aplicaciones móviles.

 

La utilización de dispositivos móviles de todo tipo se ha extendido en los últimos años marcando la tendencia actual del desarrollo tecnológico. Cada corto periodo de tiempo recibimos dispositivos con nuevos recursos y características: mejores procesadores, elementos físicos más resistentes y flexibles, más capacidad sensorial... Toda esta gran oferta de dispositivos se encuentra sin embargo limitada por unos pocos sistemas operativos que están disponibles. Cada plataforma aporta su propio entorno de desarrollo que favorece y aprovecha las mejores características de cada una de ellas. Y a la vez los diferencia.

Así se ha introducido el concepto de "porting app" para definir todas las operaciones necesarias para conseguir que una aplicación de una plataforma funcione en otra. En general los desarrollos actuales se caracterizan por ser muy poco portables debido al esfuerzo de diferenciación que han realizado las cuatro grandes plataformas – iPhone, RIM, WindowsPhone y Android – utilizando mecanismos diferentes de programación. Y son escasos los trabajos que han abordado el tema del desarrollo multiplataforma debido al alto coste y al cambio constante en las plataformas.

Las aplicaciones móviles pueden estructurarse básicamente en tres capas: la capa de datos, la de usuario y la de proceso. La capa de datos se encarga de la gestión de información tanto de forma local como por web y, aunque similar en cuanto a las funciones que realiza en las diferentes plataformas, existen diferencias sutiles en la forma de gestionar la información (sobre todo la gestión de dispositivos). La capa de usuario representa el elemento característico de cada entorno, en donde más se ha puesto el énfasis de la diferencia no sólo entre plataformas sino incluso en dispositivos que siguen una misma plataforma. La capa de proceso es la más complicada de tratar puesto que intervienen tanto los lenguajes de programación específicos como el uso de las librerías nativas de cada plataforma

El Trabajo Fin de Master, consistirá en construir un generador automático de aplicaciones móviles (GENMOVIL) utilizando alguno de los mecanismos básicos de generación automática de código. Las aplicaciones existentes como RhoMobile, MoSync o Appcelerator proponen mecanismos de solución basados en el uso de múltiples APIs que intentan homogeneizar diferentes recursos de las plataformas. El objetivo del proyecto será el análisis, diseño y construcción de un generador que permita la creación de aplicaciones multiplataforma de forma automática. El generador puede centrarse en una de las tres capas básicas de las aplicaciones móviles o puede centrarse en un generador completo sobre un subconjunto de las plataformas existentes.

Como resultados del proyecto se deberá entregar:

Si está interesado en la temática de este trabajo, puede contactar con el profesor: Ismael Abad Cardiel.

Volver

Mejoras con el diseño

 

Dentro de la línea del Desarrollo de Software y de las Arquitecturas Software, la orientación de los trabajos está relacionada con la gestión, en el diseño arquitectónico, de los atributos cualitativos de un sistema y su incorporación en las herramientas de análisis, evaluación y soporte para la toma de decisiones en el desarrollo arquitectónico; teniendo en cuenta su relación con los objetivos de negocio de la organización. En el SEI hay bastante documentación para el estudio al respecto. En concreto, el libro de base que se utiliza en los cursos del SEI sobre esto es “Software Architecture in Practice”, 2nd Edition, by Len Bass, Paul Clements, and Rick Kazman. Ed. Addison-Wesley. Es muy recomendable hacerse con él. Hay algún ejemplar en la biblioteca. A grandes rasgos, la tesis fundamental es que, a la hora de diseñar la arquitectura de un producto, los requisitos funcionales son menos importantes que las restricciones globales, los requisitos de calidad –atributos cualitativos- y su imbricación en los objetivos de negocio de la organización.

El diseño arquitectónico está muy vinculado al conocimiento del área de negocio y del dominio del desarrollo y a la experiencia del arquitecto. ¿Cómo se puede incorporar este conocimiento, junto con los atributos cualitativos, a la hora de diseñar arquitecturas de manera sistemática? De ello habla el libro “Software Architecture in Practice” y los que aparecen en el artículo Relating Business Goals to Architecturally Significant Requirements for Software Systems. Esto nos daría las pautas para tomar decisiones a la hora de elegir entre una u otra arquitectura. Ahora bien, este planteamiento sigue siendo muy abstracto y poco práctico para el arquitecto que se vería obligado a evaluar —si quiere ser sistemático— una explosión combinatoria de arquitecturas posibles. La solución está en cómo se representa la arquitectura, las tácticas —útiles para tener en cuenta los atributos cualitativos y los objetivos del negocio y evitar el recorrido exhaustivo del árbol de arquitecturas— y una herramienta para asistencia en la toma de decisiones.

Quede entendido, por tanto, que el ámbito y el objetivo de esta línea de trabajos es la mejora, sustancial y medible, de un software o desarrollo concreto mediante las modificaciones en su diseño. El Trabajo Fin de Máster, podría centrarse en la aplicación e implementación de los planteamientos arquitectónicos anteriores a un caso concreto y a través de una herramienta. Existen varias herramientas de ese tipo —o análogas—, pero son propietarias. El SEI, para el ámbito educativo, ha desarrollado la herramienta ArchE, que ha utilizado en sus cursos en años anteriores, aunque ya no hacen más desarrollos sobre ella. Su funcionamiento —en Windows®— se basa en el sistema experto JESS —para el cual hay que solicitar licencia educativa; aunque se puede usar la mía—, ambos sobre la plataforma de desarrollo Eclipse, MySql y el servidor de comunicación xmlBlaster. Todo el sistema se ha instalado y funcionado, sin problemas, en un SO de 32 bits. Otros compañeros también lo han instalado e, incluso, han desarrollado un nuevo ‘marco de razonamiento’, en cursos pasados. Se puede aprovechar su experiencia.

En definitiva, el contenido del trabajo versa sobre:

Y, con ese horizonte, el trabajo y su memoria explicativa debe incluir, como mínimo, los apartados descritos más arriba, en el epígrafe de presentación.

Es en el ámbito del diseño o rediseño del sistema software que se afronta mejorar, donde tiene cabida el uso de la herramienta ArchE o cualesquiera otras accesibles para el estudiante; así como las técnicas y metodologías de desarrollo que estime más adecuadas para alcanzar los objetivos con éxito.

Además, en el caso de utilizar la herramienta ArchE, las directrices para su manejo serían:

Es necesario insistir en que en todos los casos, tanto si se usa ArchE como si no, habrá que justificar la procedencia y el empleo de los criterios rigurosos aplicados a las modificaciones del diseño que han llevado a obtener la mejora; y medir su alcance o demostrar su obtención.

Si está interesado en la temática de este trabajo, puede contactar con el profesor: José Félix Estívariz López.

Volver

Análisis Automático de Modelos de Configuración de Software

 

En ocasiones, se requiere desarrollar programas informáticos adaptables a un amplio abanico de situaciones. Por ejemplo, los sistemas operativos suelen ser muy configurables para que puedan funcionar en hardware con distintas prestaciones y de distintos fabricantes. Una situación similar se da en el ámbito de las líneas de producto software, que automatizan la producción de programas muy similares mediante el ensamblado y parametrización de gran número de componentes software.

Para gestionar la enorme flexibilidad de este tipo de programas y, en particular, las dependencias e incompatibilidades entre sus componentes, suele emplearse algún tipo de lenguaje de configuración. Por ejemplo, el kernel de Linux usa el lenguaje kconfig, el sistema operativo para sistemas empotrados eCos utiliza CDL, las líneas de producto software suelen utilizar diagramas de características(†), etc.

Estos modelos de configuración suelen contar con cientos, e incluso miles, de componentes interrelacionados, y su análisis puede facilitar la estimación de costes del software [5] y la detección de cierto tipo de errores [1, 4]. Por ejemplo, puede haber componentes que, debido a su incompatibilidad con otros componentes, no puedan aparecer en ninguna configuración válida. Evidentemente, desarrollar y mantener tales componentes es un gasto inútil.

La estrategia que suele emplearse para analizar automáticamente los modelos de configuración consiste en traducirlos a lógica booleana. Después, las fórmulas resultantes se analizan con herramientas genéricas de lógica, como, por ejemplo, librerías para Diagramas de Decisión Binarios (Binary Decision Diagrams, BDDs) [3].

Este esquema puede plantear problemas de escalabilidad, ya que el BDD que codifica un modelo de configuración puede alcanzar un tamaño exponencial respecto al número de componentes. Para evitar estos problemas, se debe analizar detenidamente el modelo y realizar una traducción a medida, como la propuesta en [6].

El trabajo fin de master consistirá en desarrollar, para alguno de los modelos de configuración de los sistemas operativos descritos en [2], una traducción a BDD procesable por la librería BuDDy(‡). La memoria explicativa del trabajo debe incluir, como mínimo, los apartados descritos más arriba, en el epígrafe de presentación.

REFERENCIAS

[1] David Benavides, Sergio Segura, and Antonio Ruiz-Cortés. Automated analysis of feature models 20 years later: a literature review. Information Systems, 35(6), 2010.

[2] T. Berger, S. She, R. Lotufo, A. Wasowski, and K. Czarnecki. Variability modeling in the systems software domain. gsdlab-tr 2012-07-06, version 2. Technical report, Generative Software Development Laboratory, University of Waterloo, http://gsd.uwaterloo.ca/tr/vm-2012-berger, 2012.

[3] Randal E. Bryant. Symbolic boolean manipulation with ordered binary-decision diagrams. ACM Comput. Surv., 24(3):293–318, 1992.

[4] R. Heradio, D. Fernández-Amorós, J.A. Cerrada, and C. Cerrada. Supporting commonality-based analysis of software product lines. IET Software, 5(6):496 –509, dec. 2011.

[5] Ruben Heradio, David Fernández-Amorós, Luis Torre-Cubillo, and Alberto Pérez García-Plaza. Improving the accuracy of coplimo to estimate the payoff of a software product line. Expert Systems with Applications, 39(9):7919 – 7928, 2012.

[6] Nina Narodytska and Toby Walsh. Constraint and variable ordering heuristics for compiling configuration problems. In Proceedings of the 20th International Joint Conference on Artifical Intelligence, pages 149–154, San Francisco, CA, USA, 2007. Morgan Kaufmann Publishers Inc.

Si está interesado en la temática de este trabajo, puede contactar con el profesor: Rubén Heradio Gil.


(†) La web http://www.splot-research.org/ alberga un repositorio público de diagramas de características.

(‡) BuDDy es una librería de código abierto para BDDs disponible en http://sourceforge.net/projects/buddy/.


Volver

Analizador/Generador Automático de Vulnerabilidades/Malusos (Exploits)

 

Partiendo de los conocimientos adquiridos en la asignatura de Desarrollo de Software Seguro y de un lenguaje de programación, una versión de compilador, un sistema operativo y un entorno de desarrollo concreto que el alumno deberá seleccionar, se trata de realizar un Analizador Automático de Vulnerabilidades y posterior Generador Automático de Malusos (Exploits) para programas fuentes en el lenguaje seleccionado.

Objetivos del Trabajo:

  1. Aplicar técnicas análisis estático de código fuente para detectar el mayor número de vulnerabilidades posibles de las estudiadas en la asignatura de Desarrollo de Software Seguro.

  2. Encontrar patrones de maluso (exploits) que permitan generar programas de ataque a las vulnerabilidades detectadas anteriormente.

  3. Probar los resultados obtenidos con algunos programas fuentes de código abierto disponibles.

La pauta de trabajo será la que se sugiere en el artículo "AEG: Automatic Exploit Generation" que se encuentra en el anexo de esta propuesta (ver este enlace).

Como resultado del trabajo fin de master se deberá entregar lo siguiente:

Si está interesado en la temática de este trabajo, puede contactar con el profesor: José Antonio Cerrada Somolinos (jcerrada@issi.uned.es).

Volver

Mejoras de los motores físicos: ODE y Bullet

 

Un motor físico, parte fundamental de cualquier simulador de robots, es un software que proporciona los mecanismos necesarios para simular de forma aproximada algunos sistemas físicos, tales como la dinámica del cuerpo rígido.

Con este trabajo fin de máster se pretende realizar un estudio de las posibilidades de los dos motores físicos gratuitos principales: ODE y bullet, y plantear y evaluar posibles mejoras de los mismos en la simulación de la dinámica del cuerpo rígido.

Como resultado del trabajo fin de master se deberá entregar lo siguiente:

Si está interesado en este trabajo, póngase en contacto con el profesor: Juan José Escribano Ródenas (jjescri@issi.uned.es)

Volver

Super-3D: Mejora de la representación de superficies tridimensionales.

 

El trabajo está orientado a desarrollar una mejora o un nuevo método más eficiente que los existentes para la representación de una superficie tridimensional.

La realización de este trabajo conlleva la elaboración y presentación de una memoria explicativa que debe incluir, como mínimo, los apartados descritos más arriba, en el epígrafe de presentación.

Para considerar el trabajo con una calificación excelente deberá hacerse una propuesta de comunicación de resultados en inglés, con la posibilidad de ser enviada a una publicación. Este trabajo de comunicación de resultados deberá realizarse bajo supervisión del equipo docente de la asignatura.

Si está interesado en este trabajo, póngase en contacto con el profesor: Sebastián Rubén Gómez Palomo (sgomez@issi.uned.es)

Volver