desarrollo de una plataforma de colaboración entre ... · plataforma de colaboración entre...

Alejandro Sáez Subero

Angel Luis Rubio García

Facultad de Ciencias, Estudios Agroalimentarios e Informática

Grado en Ingeniería Informática

2013-2014

Título

Director/es

Facultad

Titulación

Departamento

TRABAJO FIN DE GRADO

Curso Académico

Desarrollo de una plataforma de colaboración entre ingenieros de software. Persistencia relacional

Autor/es

© El autor© Universidad de La Rioja, Servicio de Publicaciones, 2014

publicaciones.unirioja.esE-mail: [email protected]

Desarrollo de una plataforma de colaboración entre ingenieros de software.Persistencia relacional, trabajo fin de grado

de Alejandro Sáez Subero, dirigido por Angel Luis Rubio García (publicado por la Universidad de La Rioja), se difunde bajo una Licencia

Creative Commons Reconocimiento-NoComercial-SinObraDerivada 3.0 Unported. Permisos que vayan más allá de lo cubierto por esta licencia pueden solicitarse a los

titulares del copyright.

Plataforma de colaboración entre ingenieros software: persistencia relacional

3

Índice

1. Resumen/abstract ........................................................................................................ 5

1.1. Resumen .................................................................................................................... 5

1.2. Abstract ..................................................................................................................... 5

2. Introducción ................................................................................................................. 7

2.1. Alcance ...................................................................................................................... 7

2.1.1. ¿Qué se va a hacer? ......................................................................................................... 7

2.1.2. ¿Por qué se va a hacer?.................................................................................................... 7

2.1.3. ¿Cómo se va a hacer? ....................................................................................................... 7

2.1.4. Estructuración y organización .......................................................................................... 8

2.2. Planificación inicial ..................................................................................................... 9

2.2.1. Calendario ........................................................................................................................ 9

2.2.2. Fechas y plazos ............................................................................................................... 10

2.2.3. Metodología y reuniones ............................................................................................... 13

2.2.4. División del trabajo ........................................................................................................ 13

3. Análisis ....................................................................................................................... 15

3.1. Filosofía de la plataforma ......................................................................................... 15

3.2. ¿Quiénes participan? ................................................................................................ 16

3.3. ¿Qué pueden hacer los usuarios? .............................................................................. 16

3.3.1. Usuario externo .............................................................................................................. 16

3.3.2. Usuario registrado .......................................................................................................... 16

3.3.3. Administrador ................................................................................................................ 17

3.4. ¿Qué tiene la aplicación? .......................................................................................... 17

3.4.1. Proyectos ........................................................................................................................ 18

3.4.2. Comentarios ................................................................................................................... 19

3.4.3. Etiquetas y buscador ...................................................................................................... 20

3.4.4. Imágenes ........................................................................................................................ 20

3.4.5. Área privada ................................................................................................................... 21

3.5. ¿Dónde se aloja la aplicación? .................................................................................. 21

4. Diseño ........................................................................................................................ 23


4

4.1. La estructura ............................................................................................................ 23

4.1.1. ¿Qué diseño se plantea? ................................................................................................ 23

4.1.2. ¿Cómo se van a dividir los módulos del sistema? .......................................................... 23

4.2. La aplicación ............................................................................................................ 24

4.2.1. ¿Qué nos vamos a encontrar? ....................................................................................... 24

4.3. Los datos.................................................................................................................. 26

4.3.1. La Base de Datos ............................................................................................................ 26

4.3.2. ¿Cómo se organizan los datos?: Modelo Lógico ............................................................ 27

4.3.3. ¿Cómo se almacenan los datos? .................................................................................... 31

4.3.4. ¿Cómo se gestionan los datos? ...................................................................................... 32

4.4. El plan de pruebas .................................................................................................... 33

4.4.1. ¿Qué plan de pruebas se va a seguir? ............................................................................ 33

5. Implementación .......................................................................................................... 35

5.1. El entorno ................................................................................................................ 35

5.2. Generación del código .............................................................................................. 36

6. Planificación final ........................................................................................................ 37

6.1. Calendario ............................................................................................................... 37

6.2. Variación de tiempos ................................................................................................ 38

7. Valoración y lecciones aprendidas ............................................................................... 41

7.1. Valoración del trabajo .............................................................................................. 41

7.2. El trabajo en equipo ................................................................................................. 42

7.3. Los tiempos .............................................................................................................. 43

7.4. Futuras ampliaciones ............................................................................................... 43

8. Bibliografía ................................................................................................................. 45


5

1. Resumen/abstract

1.1. Resumen

El presente documento pretende mostrar el proceso de creación de la plataforma de colaboración entre ingenieros software, en su parte de persistencia y lógica de negocio. Se compone del análisis de ésta, el diseño, la base de datos, las pruebas realizadas y la planificación de tiempos, así como del resultado real en tiempos. También incluye las conclusiones personales.

La aplicación ha sido ideada por José Ignacio Martínez y Alejandro Sáez. A diferencia del desarrollo tradicional de los TFGs de manera individual, en este caso se decide a partir de una única aplicación hacer dos trabajos, aunque ello supone un esfuerzo extra de colaboración y discusión. Además, se trata de una práctica más cercana a la realidad, ya que en el mundo empresarial, el desarrollo de estos productos no se realiza de forma individual. También es necesario un esfuerzo a la hora de saber diferenciar las partes ya que a pesar de todo, deben ser dos TFGs diferentes y en todo lo posible independientes.

1.2. Abstract

This document intends to show the process of construction the platform for collaboration between software engineers on the side of business logic and persistence. Include the analysis, design, database, tests and planning times as well as the actual result as times. Also includes the personal conclusions.

The application has been created by José Ignacio Martinez and Alejandro Sáez. Unlike traditional development of TFG´s individually in this case is decided by a single application to do two works even if it means extra effort of collaboration and discussion. In addition, it is a practice closer to the reality, because in the workplace the development of these products is not made individually. It is also necessary an extra effort to know when to split the parts of the product and that nevertheless must be two different TFG´s and as far as possible independents.


7

2. Introducción

2.1. Alcance

2.1.1. ¿Qué se va a hacer?

La finalidad de este proyecto es construir una aplicación web orientada a desarrolladores e ingenieros de software, así como cualquier profesional o aficionado a la informática que desee realizar un proyecto o recibir ayuda con sus ideas.

Se pretende construir una plataforma en la que los usuarios publiquen sus proyectos e ideas, bien con la intención de darse publicidad o para colaborar con otros usuarios que tengan problemas.

Los usuarios podrán compartir sus proyectos finalizados así como ideas para las que necesiten colaboración, además tendrán la posibilidad de comentar y criticar los trabajos publicados.

2.1.2. ¿Por qué se va a hacer?

Surge la idea de realizar una aplicación web común entre José Ignacio Martínez y Alejandro Sáez a partir de las asignaturas Taller Transversal II y Profesión de Ingeniero en Informática, en las que se nos habla a los alumnos de la necesidad de una plataforma con la que mantener el contacto y colaborar durante la realización del proyecto ya que en ese periodo habitualmente los alumnos dejan de relacionarse al no haber clase.

En ese instante, pensamos que sería interesante la realización de una aplicación web de colaboración, pero mirando más allá de la propia Universidad.

2.1.3. ¿Cómo se va a hacer?

La aplicación a realizar va a estar dividida en dos TFGs, por un lado José Ignacio Martínez se encargará de la capa de presentación mientras que Alejandro Sáez se encargara de la parte de persistencia y lógica de negocio.

Se decide trabajar de éste modo desde un primer momento ya que surge la idea en común tras cursar varias asignaturas en el primer cuatrimestre del presente curso, en las cuales se


8

menciona numerosas veces la necesidad de una plataforma en la que los alumnos colaboren mientras realizan su proyecto. A partir de entonces se comienza a trabajar para encontrar el modo de construir una aplicación conjunta pero en dos TFGs diferentes, ya que las normas así lo exigen.

Una vez reunidos con el tutor y expuesta la idea, se decide seguir la metodología de trabajo Scrum, de la que se habla más adelante. De este modo, se apuesta desde el principio por el trabajo colaborativo, lo cual creemos que puede aportar un valor extra si bien es un riesgo ya que deben diferenciarse claramente ambos trabajos.

Para trabajar de este modo, se exige reunirse muy a menudo durante la primera fase, ya que deben ponerse todos los puntos en común y llegar a los acuerdos necesarios para que la aplicación pueda llegar a funcionar. Resulta un trabajo bastante extenso y duro, ya que cada miembro parte con unas ideas diferentes y otros puntos de vista aunque reunión tras reunión se consigue crear una línea común que se verá plasmada en el análisis y diseño del producto.

Apostamos por esta forma de trabajo ya que experiencias anteriores y presentes, tanto a nivel académico como deportivo y personal nos indican que en la inmensa mayoría de casos es la forma de trabajar. Además, a nivel profesional, la manera más habitual de trabajo en ingeniería de software es colaborativo, por ello, ésta experiencia puede añadir valor al título.

Tras superar las primeras fases de reuniones y dialogo, si éstas se han realizado con éxito, durante las siguientes fases de construcción de la plataforma no se hace necesario reunirse salvo una o dos veces al mes para comprobar el avance. Concluida esta fase de trabajo en común pueden verse los frutos de la colaboración. De éste modo, esta metodología se convierte en una autoevaluación, en la que si todo concuerda y no existen dudas de una parte respecto a la otra, sabremos que el trabajo anterior se realizó correctamente.

Finalmente, cada una de las partes deberá volver a juntarse para cerrar el proyecto, y es en éste momento en el que se verá si cada miembro ha trabajado en la parte individual.

2.1.4. Estructuración y organización

La aplicación se dividirá en las tres capas clásicas, persistencia, lógica de negocio y presentación.

Inicialmente, siguiendo el consejo de nuestro tutor Ángel Luis Rubio, se construirá un esqueleto al que posteriormente, se irá dotando de funcionalidad.

Se va a utilizar Java, debido al deseo de conocer el lenguaje más en profundidad ya que desde varios años atrás en diversas asignaturas no hemos vuelto a utilizarlo.

Supone una dificultad añadida ya que nos enfrentamos en el primer caso a una versión nueva de HTML, la cual desconocemos, y en el segundo, con Java, a un lenguaje que no estamos habituados a utilizar en la actualidad.


9

Se va a utilizar la metodología Scrum, aunque no de forma estricta ya que está pensada para grupos de trabajo formados por al menos tres personas.

Se realizarán sprints semanales, salvo alguna excepción en la que serán de dos semanas, obteniendo un entregable concreto al finalizar cada uno de ellos. Al final de cada sprint, nos reuniremos los dos miembros del equipo para comprobar el avance, los problemas y posibles retrasos, y para establecer los objetivos del siguiente sprint.

También se realizarán reuniones con el tutor cada uno, dos o tres sprints, según la dificultad o necesidad de la misma. La previsión es de seis o siete reuniones.

2.2. Planificación inicial

2.2.1. Calendario

Fase del proyecto Inicio Final

D.O.P. 17.02.2014 25.02.2014

ANÁLISIS 26.02.2014 11.03.2014

ESQUELETO 12.03.2014 25.03.2014

LÓGICA DE NEGOCIO 26.03.2014 13.05.2014

UNIFICACIÓN 14.05.2014 27.05.2014

CIERRE 28.05.2014 05.06.2014

PRESENTACIÓN 19.06.2014 01.07.2014

REUNIÓN 1 17.02.2014 REUNIÓN 5 05.05.2014

REUNIÓN 2 03.03.2014 REUNIÓN 6 19.05.2014

REUNIÓN 3 17.03.2014 REUNIÓN 7 05.06.2014

REUNIÓN 4 07.04.2014


10

FEBRERO MARZO ABRIL MAYO JUNIO JULIO

L M X J V S D

1 2

3 4 5 6 7 8 9

10 11 12 13 14 15 16

17 18 19 20 21 22 23

24 25 26 27 28

L M X J V S D

1 2

3 4 5 6 7 8 9

10 11 12 13 14 15 16

17 18 19 20 21 22 23

24 25 26 27 28 29 30

31

L M X J V S D

1 2 3 4 5 6

7 8 9 10 11 12 13

14 15 16 17 18 19 20

21 22 23 24 25 26 27

28 29 30

L M X J V S D

1 2 3 4

5 6 7 8 9 10 11

12 13 14 15 16 17 18

19 20 21 22 23 24 25

26 27 28 29 30 31

L M X J V S D

1

2 3 4 5 6 7 8

9 10 11 12 13 14 15

16 17 18 19 20 21 22

23 24 25 26 27 28 29

30

L M X J V S D

1 2 3 4 5 6

7 8 9 10 11 12 13

14 15 16 17 18 19 20

21 22 23 24 25 26 27

28 29 30 31

2.2.2. Fechas y plazos

El proyecto se divide en siete fases bien diferenciadas:

1) DOP y planificación.

2) Análisis.

3) Creación del esqueleto.

4) Lógica de negocio.

5) Unificación.

6) Cierre.

7) Presentación.

A continuación se explican con detalle cada una de las fases:

1) DOP y planificación

El inicio oficial del proyecto es el día 17 de Febrero, fecha de la primera reunión con el tutor y de comienzo del Documento de Objetivos. Durante esta fase que se prolonga hasta el 25 de Febrero se establecen los objetivos a lograr y se realiza la planificación entre la que se encuentra este apartado. Se marca la división del trabajo y las partes que cada miembro del equipo realizará.

En esta fase se obtiene como entregable principal el Documento de Objetivos del Proyecto.

2) Análisis

Se inicia el 26 de febrero y finaliza el 11 de Marzo. Consta de dos partes. Una primera de análisis individual y otra de puesta en común de las partes.

En esta fase se debe crear en primer lugar una versión “a papel y boli” de la interfaz de la plataforma y de la Base de Datos. Se establece el alcance y los requisitos, así como la


11

tecnología y el entorno a utilizar. También se definen los tipos de usuarios posibles y sus roles para la aplicación.

Cada uno de los participantes en el proyecto realizará su parte del análisis y posteriormente ésta se pondrá en común para corregir los problemas que pudieran aparecer para obtener una versión definitiva.

Los entregables previstos en esta fase son: el diseño de la interfaz, el diseño de la Base de Datos y el análisis del entorno (aplicación, usuarios y tecnología).

3) Creación del esqueleto.

Esta fase se inicia el 11 de Marzo y finaliza el 25 del mismo mes.

Se divide en dos partes. La primera y más extensa consistente en la creación del esqueleto, y la segunda, la subida al FTP del mismo.

Este esqueleto, se compone de una interfaz sin funcionalidad y de la Base de Datos. Se crea de esta forma para, posteriormente, ir dotándola de funcionalidad.

En este punto el trabajo continúa realizándose de forma conjunta, si bien José Ignacio se centra en la interfaz y Alejandro en la Base de Datos.

El principal entregable en esta fase es el esqueleto de la aplicación.

4) Lógica de negocio

Es la fase más extensa del trabajo: se inicia el 26 de Marzo y finaliza el 13 de Mayo.

Esta es la parte en la que la aplicación obtiene funcionalidad una vez creado el esqueleto.

Comienza realizando un análisis de la Lógica de negocio, en el que cada miembro analiza su parte. Tras ello, el trabajo se realiza de forma individual, dividido en tres sprints, al final de cada uno de los cuales se realizara la correspondiente reunión.

Los entregables para esta fase son, el análisis de la Lógica de negocio y la Lógica de negocio.

5) Unificación

Este periodo se prolonga del 14 al 27 de Mayo.

Tras realizar cada miembro su parte de la Lógica de negocio, se unen ambas para obtener una versión definitiva de la aplicación que se presentará en el TFG. Esta parte se dividirá en dos sprints.

El entregable fundamental de esta fase es la aplicación tal y como se presentará.

6) Cierre del proyecto

En esta fase que va desde el 28 de Mayo hasta el 5 de Junio, se finaliza el trabajo, creando la documentación pendiente de realizar, así como uniendo cada uno de los documentos realizados en las fases previas.


12

Puesto que cada fase tendrá unos entregables mínimos concretos, además de otros posibles que vayan surgiendo, en este periodo se deberá unir el puzle con aquello que formará parte del Documento final y aquello que no será necesario o pueda formar parte de los anexos.

En este apartado, cada miembro diseñara su propio Documento tomando lo que considere necesario.

El entregable es la Documentación definitiva.

7) Presentación

Esta fase, pendiente de asignación de tiempos, depende de la fecha exacta de presentación del TFG, aún por determinar.

Cada miembro del grupo, realizará su propia presentación. El entregable es la presentación.

La división de tiempos esperada es la siguiente:

Actividad Número de horas

Establecimiento de objetivos 15

Análisis y diseño 30

Creación del esqueleto 30

Preparar servidor y el repositorio de código 6

Análisis de la lógica de negocio 9

Desarrollo de la lógica de negocio 110

Unificación 36

Presentación 20

Reuniones 25

Formación 14

Cierre de Documentación 5

Total 300


13

2.2.3. Metodología y reuniones

Se realizarán sprints cuya duración depende de la fase en la que se encuentre el producto. Para cada sprint se establece una meta para cada miembro, que debe cumplirse para que el trabajo llegue a buen puerto. La duración de cada sprint depende de la carga de trabajo asignada. Por ejemplo, para el análisis, los sprints son semanales, pero para la creación de la lógica de negocio, los sprints se hacen cada dos semanas, ya que el volumen de trabajo es mayor y tampoco es interesante sobrecargarse con reuniones innecesarias. Al finalizar cada sprint, se realiza una reunión de control entre los miembros del equipo para comprobar lo avanzado y marcar los objetivos para la siguiente carrera. Estas reuniones, están previstas en martes o jueves.

El correcto funcionamiento de esta metodología se basa en el interés común de los miembros, ya que si uno de ellos falla en sus entregas o no cumple con sus cargas en el sprint, lastra al resto de miembros y pone en peligro la consecución de los objetivos.

Por otra parte, se realiza otro tipo de sprints con el tutor, estos cada dos o tres semanas. Finalizan con una reunión en la que se comentan los avances y problemas, así como las posibles mejoras o correcciones que el tutor crea conveniente. A cada una de estas reuniones, se acudirá con un orden del día para lograr que sean lo más útiles posible. Las fechas de estas reuniones se han marcado en el calendario y la previsión inicial es que sean 7, aunque la fecha exacta o el número pueden variar según necesidades.

2.2.4. División del trabajo

Para completar las 300 horas requeridas para el TFG, la dedicación semanal debe ser de unas 17 horas por semana, algo a priori, sencillo de lograr. No obstante, ambos miembros del equipo trabajamos en horario de mañana de 8:00 a 15:00 hasta finalizar el mes de Mayo, además de otras obligaciones inexcusables la mayoría de las tardes y fines de semana, relacionadas con el deporte o las clases en el caso de José Ignacio. Por ello, el esfuerzo para obtener este tiempo es mayor del que se puede apreciar a simple vista y se debe aprovechar cada instante de tiempo disponible para ello.


15

3. Análisis

3.1. Filosofía de la plataforma

La primera pista para conocer la filosofía de ésta aplicación se encuentra en el título del proyecto: “Plataforma de Colaboración…”.

Esta aplicación trata de ser una ayuda y un lugar de encuentro para desarrolladores, ingenieros de software y aquellas personas interesadas en la creación de software, hardware o cualquier proyecto relacionado con la informática.

Los usuarios pueden compartir sus creaciones de la manera que ellos deseen, bien un fragmento o bien su proyecto completo. Por otra parte también pueden descargar los proyectos o el código de otros usuarios.

La idea más importante es que los usuarios colaboren unos con otros, pidiendo ayuda en aquellos momentos en que tengan dudas pero ofreciendo también sus conocimientos y ayuda cuando sean otros los que tengan alguna dificultad.

Además, pretende ser un lugar de creación de ideas, donde éstas surjan sin ningún tipo de censura, siempre y cuando no resulten ofensivas a los demás. Esto puede dar lugar a grandes ideas partiendo de otras pequeñas gracias a la participación y colaboración de otras personas.

En definitiva se basa en la buena voluntad, en recibir y a cambio dar y por ello no se van a establecer mecanismos de control o de traza que indiquen si un usuario solo se dedica a la descarga de ficheros, aunque los administradores entenderán que si un éste no participa con comentarios ni sube código o proyectos está abusando de la plataforma y únicamente la utiliza para la descarga con lo que será dado de baja. Además, si se reciben repetidas quejas de que un usuario hace éste uso, también se estudiará el caso.

No se desean usuarios que únicamente tengan una cuenta para obtener información y no aportar.


16

3.2. ¿Quiénes participan?

Hay tres tipos de usuarios: los externos, los registrados y administradores.

Los usuarios externos son visitantes sin ningún privilegio y por tanto no existe ningún mecanismo de identificación para ellos.

Los usuarios registrados y los administradores tienen un alias, una contraseña y una dirección de correo.

Al registrar un nuevo usuario, éste debe introducir obligatoriamente una dirección de correo y una clave. El alias se generará a partir de la dirección de correo en el caso de que no introduzca nada, además actuará de identificador del usuario no pudiendo modificarlo posteriormente.

3.3. ¿Qué pueden hacer los usuarios?

Cada usuario tiene unas funciones u otras dependiendo del tipo al que pertenezca:

3.3.1. Usuario externo

Visualizar el portal: Los usuarios no registrados pueden ver los proyectos, código, peticiones de ayuda, ideas y comentarios que los usuarios registrados suban. Sin embargo, no tienen la posibilidad de descargarse código o proyectos, ni de comentar mientras no se registren.

Realizar búsquedas: Pueden utilizar el buscador como cualquier otro usuario mediante los tags (el funcionamiento del buscador y los tags se explica en un apartado posterior).

Crear nueva cuenta (registrarse): Accede a un formulario para darse de alta como usuario de la aplicación.

3.3.2. Usuario registrado

Modificar cuenta: Puede modificar el correo electrónico y su password, pero nunca su alias ya que este actúa como identificador del usuario. Acerca de la gestión de la contraseña se habla en el diseño de la aplicación.


17

Gestionar publicación: Un usuario registrado puede subir proyectos así como modificarlos (por ejemplo si desea cambiar un documento que ha subido puede quitarlo y poner otro). Lo mismo ocurre con los fragmentos de código.

También puede abrir una petición de ayuda en la que consulte una duda que le haya surgido. Y de la misma manera, tiene la posibilidad de crear una nueva idea.

Solicitar: El usuario puede solicitar que se elimine una publicación suya o incluso la eliminación de su cuenta. También tiene la posibilidad de reclamar el cierre de una petición de ayuda o de una idea que él haya creado si piensa que ya no hay nada más que aportar.

No se desea que los usuarios puedan eliminar directamente una publicación, ya que ello puede suponer un uso indebido de la herramienta, por ejemplo utilizándolo a modo de almacén de código o como simple copia de seguridad. Tampoco es conveniente la eliminación automática de las cuentas ya que podría darse un uso contrario a la filosofía de la plataforma como crearse una cuenta para descargarse un proyecto y a continuación eliminarla.

En cuanto al cierre de ayudas e ideas, el administrador debe estudiar la conveniencia de cerrarla ya que puede continuar siendo de utilidad a otros usuarios que aún puedan aportar en ella.

Un usuario registrado también puede descargar un proyecto, generar etiquetas o tags y realizar comentarios.

3.3.3. Administrador

Eliminar cuenta de usuario: Se puede eliminar por solicitud del usuario o por incumplimiento de la filosofía de la plataforma. Aunque primero el administrador se pondrá en contacto con el usuario para estudiar el caso.

Eliminar publicación: Cualquier tipo de publicación, bien por petición de un usuario o bien por considerarse invalida.

Cerrar: El administrador puede cerrar una petición de ayuda o una idea si ha sido solicitado por el usuario o si considera que ya no tiene utilidad.

Gestionar etiquetas: El administrador puede ver las etiquetas existentes y modificar o eliminar aquellas que considere oportuno, bien por desuso o por no corresponder o ser ofensivos.

3.4. ¿Qué tiene la aplicación?

La información se divide en varios apartados, que tratan de hacer la plataforma lo mas usable posible.


18

Existirán cuatro tipos diferentes de proyectos que el usuario podrá manejar: Proyectos completos, Ideas, Código y Ayuda (PICA). Ésta es la parte central de la plataforma, que da nombre a la misma, para la que se piensa en utilizar el juego de palabras resultante de las iniciales de los proyectos. Además, PICA se asocia a la acción de clicar sobre los objetos. De éste modo surge la idea de llamarle PICASnippet.

3.4.1. Proyectos

3.4.1.1. Completo

Son proyectos que los usuarios pueden subir o descargarse. Cada uno decide si desea subir su aplicación finalizada o tan solo una versión de ella. Cada usuario debe valorar si desea darse a conocer, vender su producto o simplemente ofrecer algo desinteresadamente.

De cada uno de estos proyectos se muestra:

Título. Es obligatorio.

Descripción. El proyecto debe tener una descripción obligatoriamente. Hay una corta para mostrar en la portada y otra larga.

Un documento: Contiene lo que el usuario desee (un manual, el análisis, la documentación completa…). Hay que subirlo de forma obligada ya que para eso es un proyecto completo, con todas sus partes.

Fichero con el código en formato ZIP (tal como se obtendría tras exportarlo en un editor) en donde el propietario puede añadir lo que desee, como por ejemplo un ejecutable de su aplicación. Obligatorio.

El propietario del proyecto. Es un campo opcional, donde el usuario puede introducir un nombre distinto al alias. Por ejemplo un usuario que ha subido un proyecto tal vez desee que en él aparezca su nombre real y no su alias. En caso de no introducir nada, se muestra de forma automática su alias.

Las etiquetas asignadas por el propietario. Cada proyecto tiene al menos una etiqueta de forma obligatoria.

Imágenes. Un proyecto puede tener imágenes o no, según el deseo del usuario.

Comentarios: Los que los usuarios puedan haber hecho. Si los hay, se muestran siempre.

Fecha de publicación. Se genera de forma automática en el momento de publicar.

3.4.1.2. Idea

Un usuario puede tener una idea o una aplicación en proyecto para la que necesita ayuda o colaboración. En este apartado el usuario explica su idea o incluso puede subir un documento exponiendo su idea (un documento de objetivos p.e.) o código.


19

Los usuarios interesados en ello, pueden comentar la idea y ponerse en contacto con el usuario que la publicó.

Finalmente, cuando el promotor decide que ya tiene a los compañeros necesarios para su idea, puede solicitar el cierre de la misma para que nadie más la comente.

De cada idea se ve:

Título, descripción, propietario, comentarios, imágenes, etiquetas y fecha, que son iguales que en el proyecto completo.

Un documento que el usuario desee. A diferencia que en el completo, aquí no es obligatorio introducirlo.

Un indicador que habilite o deshabilite los comentarios para la idea.

3.4.1.3. Código

Los usuarios suben fragmentos de código o snippets, que pueden ser de utilidad a otras personas.

Este apartado contiene:

Título, descripción, fecha, etiquetas y comentarios. Que funcionan igual que en los casos anteriores.

El código: Con versión para ver online y para descargar (previo registro). Es obligatorio en ambos casos, aunque el usuario decide si introduce el mismo código en ambos. Por ejemplo podría querer poner solo un pequeño fragmento para visualizar y un trozo más grande para descargar.

3.4.2. Comentarios

Los usuarios, siempre que estén registrados, pueden realizar comentarios.

3.4.2.1. De ayuda

Existe un apartado destinado a que los usuarios pidan ayuda: desde una duda compleja que les ha surgido en su proyecto hasta una simple conexión a la BD que se les resiste… cualquier necesidad de ayuda o consejo que surja debe plasmarse aquí.

De una petición de ayuda se muestra:

Autor, título y fecha. Funcionan de la misma manera que en los casos anteriores.

Exposición de la duda. Es una descripción de la duda. Su funcionamiento es el mismo que las descripciones de los proyectos.


20

Imagen. Las peticiones de ayuda pueden tener imágenes si el usuario lo desea. No son obligatorias.

3.4.2.2. De respuesta o comentario simple

Esto es cualquier comentario realizado a un proyecto o a una idea o código, así como una respuesta a una petición de ayuda. Basta con estar registrado para poder hacer comentarios.

Cada comentario contiene:

Autor. A diferencia de los casos anteriores, un comentario de éste tipo solo muestra el alias.

Texto. Es el comentario que el usuario hace. Obviamente no puede estar vacío.

Fecha. Se genera automáticamente.

3.4.3. Etiquetas y buscador

Cada proyecto puede tener un número indeterminado de etiquetas o tags.

Al menos tendrá uno obligatorio: hardware, software o redes, en referencia a la tipología del proyecto. A partir de ahí el usuario podrá crear y asignar tantos como desee, teniendo en cuenta que deben ser descriptivos de su aplicación si quiere que la gente la vea.

Por ejemplo, una buena idea de etiqueta puede ser “PHP” si la aplicación se ha hecho con ese lenguaje.

Las etiquetas son el mecanismo por el cual los usuarios clasifican sus proyectos. Por ello, las búsquedas se realizan mediante tags. Un usuario puede introducir en el buscador uno o varios nombres de etiquetas y éste le devuelve todos aquellos que contengan dichos tags.

Es importante un etiquetado correcto ya que el buscador no realiza consultas nada más que por este campo. Un etiquetado correcto dará como resultado búsquedas muy precisas y los usuarios apenas tardarán en encontrar lo que buscan. Por ésta razón los administradores deben prestar atención al etiquetado.

3.4.4. Imágenes

Los proyectos completos, las ideas y las ayudas pueden ir acompañados de imágenes. El usuario decide si desea subirlas y también el número de éstas. Estas imágenes pueden mostrar cualquier cosa relacionada con el proyecto. Por ejemplo pueden ser imágenes de casos de uso, pantallazos de la interfaz o cualquier cosa que el usuario desee mostrar.


21

3.4.5. Área privada

Los usuarios registrados tienen una zona privada desde la que pueden gestionar sus Proyectos: modificar ficheros, cambiar datos de su cuenta o solicitar la eliminación de alguno de ellos.

Los administradores también disponen de un espacio privado desde donde gestionar la aplicación. Es similar al de los usuarios, con el añadido de que pueden gestionar los datos de éstos desde ahí, así como modificar o eliminar tags. Otra función disponible para los administradores, es la creación de nuevos usuarios administradores.

3.5. ¿Dónde se aloja la aplicación?

La aplicación va a ser desarrollada en localhost, ya que a la hora de realizar diferentes pruebas y cambios durante la fase de construcción va a ser más cómodo. A pesar de existir servidores web de muy diferentes tipos (desde gratuitos y con espacio más limitado hasta los de pago e ilimitados), alojar tanto la aplicación como la base de datos en un servidor de ese tipo durante la construcción del producto solo causaría problemas y retrasos debido a la necesidad de estar continuamente realizando modificaciones.

Una vez tomada la decisión de crear la aplicación en localhost, se observa la necesidad de encontrar una plataforma válida para Windows y Mac, ya que la parte del desarrollo correspondiente a José Ignacio Martínez se va a realizar en Mac y la parte de Alejandro Sáez en Windows. Se elige XAMPP que cumple el requisito de ser multiplataforma y contiene Apache y MYSQL como servidor web y gestor de bases de datos respectivamente.

Posteriormente, una vez finalizado el TFG se estudiará la posibilidad de mantener la aplicación en un servidor web en la nube.

La plataforma se va a ser soportada con garantías por los navegadores a partir de Chrome 18, Firefox 12, Opera 11.60, Safari 5.1 y Explorer 9.


23

4. Diseño

4.1. La estructura

4.1.1. ¿Qué diseño se plantea?

La arquitectura a seguir es la clásica cliente/servidor. Se plantea de esta manera porque los usuarios que accedan a la aplicación desde sus equipos solicitarán servicios.

La plataforma requiere poco procesamiento de datos. La base de datos está centralizada y es relativamente estática, ya que no se van a estar produciendo cambios constantemente. El mantenimiento de la aplicación va a ser mínimo, si bien el control de los administradores sí debe ser mayor.

4.1.2. ¿Cómo se van a dividir los módulos del sistema?

Se va a seguir la metodología de tres capas: Persistencia, lógica de negocio y presentación. La capa de persistencia conectará directamente con la base de datos. La capa de presentación contiene la interfaz, que será lo que el usuario maneje siendo totalmente transparente para él lo que se encuentre por debajo. La capa de lógica de negocio actúa de conexión entre ambas capas.

La comunicación entre los módulos se realiza con llamadas a funciones siendo en la presentación donde se recogen los datos para enviarlos a la lógica de negocio. La lógica de negocio, comprueba los datos, enviando la información precisa a la capa de persistencia. Esta última se encargará de la comunicación con la BD.

Una de las razones por las que se elije esta forma de trabajo es la facilidad que proporciona para una futura ampliación de la funcionalidad, además de ayudar a la corrección de errores sin necesidad de realizar grandes modificaciones.


24

4.2. La aplicación

El manejo de la aplicación tiene que ser en todo momento intuitivo. Para ello se busca diseñar una interfaz que resalte las partes fundamentales del sistema.

Como ya se explica en el análisis, los usuarios sin registrar son simples visitantes, que pueden “ver pero no tocar” mientras que los usuarios registrados pueden comentar, subir y descargar.

4.2.1. ¿Qué nos vamos a encontrar?

A continuación se muestran unas imágenes de cómo será la aplicación una vez construida. Si bien la capa de presentación no corresponde a éste TFG, puede ser de utilidad para hacerse una idea de la presencia que tendrá.

Figura 1 – Ventana home

La ventana de inicio (figura 1) se muestra de la siguiente manera: en el menú tenemos las opciones principales: Hardware, Software y Redes. A la derecha de éste aparece la opción de acceder al portal o registro.

En los apartados de últimas ideas, peticiones de ayuda y último proyecto, siempre que se haga clic en el título se mostrará la información concreta. En caso de pulsar Leer más…, se verá la información completa del proyecto elegido.

Esta ventana de inicio solo se muestra una vez, tras acceder a cualquier otro apartado ya aparecerá de nuevo.


25

Figura 5 – Navegación usuario registrado

Así verá un usuario registrado la aplicación una vez que haya clicado sobre un tipo de proyecto.


26

4.3. Los datos

4.3.1. La Base de Datos

4.3.1.1. Modelo Conceptual

4.3.1.2. Descripción de la Base de Datos

La parte central de la Base de Datos son los proyectos. Éste es un nombre genérico para referirse a todos los elementos que los usuarios pueden compartir.

Del objeto proyecto heredan los cuatro tipos de elementos que los usuarios van a manejar en la aplicación, como son Completo, Idea, Código y Ayuda.

Completo es un objeto que hereda de proyecto que incluye enlaces a documentación y código para descargar.


27

Idea, hereda de proyecto y contiene un campo documentación donde el usuario sube aquellos documentos que desea compartir. Tambien tiene un campo binario para dejar la idea abierta o cerrada.

FragmentoCódigo hereda de proyecto y contiene un enlace al código para descargar y otro campo en el que se muestra el código. De éste modo el código puede verse o descargarse.

Ayuda, hereda de proyecto y los usuarios tan solo hacen comentarios. Tiene un campo Abierta/Cerrada para permitir o denegar comentarla.

De los usuarios solo se conoce el correo electrónico. Además pueden introducir el Alias que deseen o en caso contrario asignársele uno automaticamente. Se sabe si es administrador o no gracias al campo binario AdminSI/NO.

Imágenes almacena los enlaces a las imágenes que los usuarios deseen mostrar en sus proyectos.

Las etiquetas son otra parte importante de la plataforma. Los usuarios pueden generar las que deseen y los diferentes proyectos son etiquetados con ellas. Cada uno debe tener una etiqueta de forma obligatoria, a elegir entre “Software”, “Hardware” o “Redes”. Cada etiqueta contiene un contador para conocer las más utilizadas.

Los comentarios son una entidad que almacena el Id, el texto y la fecha. Tambien se guarda el alias del usuario que lo a realizado. Estos comentarios pertenecen en todo momento a un usuario concreto y van dirigidos a un solo proyecto.

4.3.2. ¿Cómo se organizan los datos?: Modelo Lógico

4.3.2.1. Tabla Usuario

USUARIO

Alias Clave Email AdminSI/NO

Clave

El campo Alias actúa como clave primaria, no puede repetirse. En caso de estar ya utilizado, se pedirá al usuario que introduzca otro. 20 caracteres alfanuméricos. No se modifica. (Se explica en un apartado posterior su funcionamiento)

Clave es la contraseña que cada usuario utiliza para acceder al sistema. 20 caracteres alfanuméricos. Puede modificarse.

Email es la dirección de correo de cada usuario. 30 caracteres alfanuméricos. Es modificable.

AdminSI/NOes un campo binario utilizado para saber si un usuario tiene privilegios de administrador o no. Modificable.


28

4.3.2.2. Tabla Proyecto

PROYECTO

Id Título DescCorta DescLarga Fecha NombreUsuario

Clave

Id es el identificador único de proyecto. Es un número autogenerado.

Título es el nombre que recibe un proyecto. Es alfanumérico de hasta 50 caracteres. Se puede cambiar.

DescLarga es la descripción que el usuario introduce. Puede contener hasta 2000 caracteres y es modificable.

DescCorta la introduce el usuario opcionalmente y en caso de no hacerlo se almacena de forma automática tomando los primeros 320 caracteres de DescLarga y se utiliza en la vista previa del proyecto.

Fecha almacena la fecha en que se introduce un proyecto. Se genera de forma automática y no se puede variar.

NombreUsuario se utiliza para almacenar el nombre del usuario si este desea introducirlo. A un usuario puede interesarle que en un proyecto concreto (si él lo considera muy bueno por ejemplo) aparezca su nombre real, ya que como usuario solo se conoce el alias.

4.3.2.3. Tabla Proy_Completo

Esta tabla almacena la información sobre los proyectos completos.

PROY_COMPLETO

IdProy Documentación Código

CE: Proyecto

IdProy es la clave extranjera que identifica un proyecto.

Documentación guarda un enlace para descargar la documentación que el usuario haya subido. Puede modificarse el contenido.

Código es un enlace para descargar el fichero con el código, ejecutable, etc.… que el usuario haya subido. Es modificable.

4.3.2.4. Tabla Proy_Idea

Esta tabla almacena la información sobre Ideas que los usuarios crean.


29

PROY_IDEA

IdProy Documentación Abierta/Cerrada

CE: Proyecto

IdProy y Documentación actúan igual que en la tabla ProyCompleto.

Abierta/Cerrada es un campo binario que indica si pueden realizarse comentarios a esta idea o no.

4.3.2.5. Tabla Proy_Fragmento_Codigo

PROY_FRAGMENTO_CODIGO

IdProy EnlaceCódigo VerCódigo

CE: Proyecto

EnlaceCódigo es un enlace para descargar un fichero con el código que el usuario ha subido. Es opcional y se puede modificar.

VerCódigo contiene el código que el usuario desee introducir. Es un campo alfanumérico de hasta 1000 caracteres. Puede ser modificado y es opcional.

4.3.2.6. Tabla Proy_Ayuda

PROY_AYUDA

IdProy Abierta/Cerrada

CE: Proyecto

Abierta/Cerrada actúa de la misma manera que en la tabla Proy_Idea

4.3.2.7. Tabla Comentario

En esta tabla se almacenan los comentarios que realizan los usuarios.

COMENTARIO

Id Texto Fecha

Clave

Id es un identificador del comentario. Es una cadena numérica autogenerada.

Texto es el texto del comentario. Puede contener hasta 320 caracteres y no se modifica.

Fecha es un campo que se genera de forma automática al crear el comentario.


30

4.3.2.8. Tabla Etiqueta

Utilizada para almacenar las etiquetas que los usuarios crean.

ETIQUETA

Nombre Contador

Clave

Nombre es la clave y nombre de la etiqueta. No pueden existir dos etiquetas iguales. Cadena con un máximo de 20 caracteres alfanuméricos. No puede modificarse.

Contador sirve para conocer cuantas veces se ha utilizado una etiqueta. Necesario a la hora de mostrar las etiquetas más utilizadas. Podría obtenerse sumando en tiempo real las apariciones de la etiqueta en los proyectos pero por eficiencia se ha decidido almacenarla, ya que así solo habrá que sumar o restar 1 al contador cada vez.

4.3.2.9. Tabla Imagen

Esta tabla almacena las imágenes que los usuarios incluyen en sus proyectos.

IMAGEN

Id EnlaceImg

Clave

Id es el identificador de las imágenes. Es un numero autogenerado.

EnlaceImg es el enlace a la imagen que está almacenada en el servidor. Se puede modificar.

4.3.2.10. Tabla Imagen_Proyecto

Esta tabla relaciona las imágenes con los proyectos a los que pertenecen.

IMAGEN_PROYECTO

Imagen Proyecto

CE: Imagen CE: Proyecto

4.3.2.11. Tabla Usuario_Comentario

Esta tabla relaciona a los usuarios con sus comentarios.


31

USUARIO_COMENTARIO

Usuario Comentario

CE: Usuario CE: Comentario

4.3.2.12. Tabla Usuario_Proyecto

Relaciona a los usuarios con los proyectos que suben.

USUARIO_PROYECTO

Usuario Proyecto

CE: Usuario CE: Proyecto

4.3.2.13. Tabla Proyecto_Comentario

Sirve para relacionar un comentario con el proyecto al que pertenece.

PROYECTO_COMENTARIO

Proyecto Comentario

CE: Proyecto CE: Comentario

4.3.2.14. Tabla Proyecto_Etiqueta

Necesaria para emparejar etiquetas con sus proyectos.

PROYECTO_ETIQUETA

Proyecto Etiqueta

CE: Proyecto CE: Etiqueta

4.3.3. ¿Cómo se almacenan los datos?

Según el tipo de datos, su almacenamiento es diferente. Mientras que unos se guardan directamente en la base de datos, de otros solo se conserva un enlace al lugar donde se encuentra el objeto.

Los datos correspondientes a usuarios, etiquetas y comentarios se almacenan directamente en la base de datos, ya que son solo texto. A continuación hablamos de otros campos que si requieren un almacenaje especial:


32

Imágenes: En la base de datos tan solo se mantiene un enlace a la imagen. Los objetos están almacenados en una carpeta en local. Se considera que ésta es la mejor opción de almacenaje debido a que las imágenes son demasiado pesadas para almacenar un gran numero directamente en la base de datos. Además esto puede evitar problemas de compatibilidad de formato en la base de datos. El usuario puede guardar una imagen directamente de internet sin necesidad de descargarla, introduciendo su dirección.

De los proyectos, las descripciones, títulos y fechas también se almacenan en la base de datos. En el caso de los proyectos completos, la documentación es un enlace a un fichero que se encuentra en una carpeta al igual que las imágenes. Código también es almacenado como un enlace pero éste dirige a un fichero comprimido que contiene el código del proyecto.

Para las ideas la documentación se almacena como en los anteriores.

Finalmente, para los snippets (o fragmentos de código), se almacena en la base de datos la parte de código que el usuario desea copiar para mostrar tal cual (solo texto), mientras que para la parte descargable, llamada EnlaceCódigo se almacena un enlace al igual que en los proyectos completos.

4.3.4. ¿Cómo se gestionan los datos?

4.3.4.1. Seguridad y privacidad

Se trata de almacenar la menor información posible de los usuarios. Para ello tan solo se requiere una dirección de correo, una clave y un alias.

Dirección de correo electrónico: Esta dirección no se va a mostrar en público en ningún momento, tan solo es visible para el usuario propietario, dentro de su perfil, y para los administradores. El usuario es libre de publicar su correo en un comentario.

Clave: Gracias a HTML5, el tratamiento de claves se simplifica. Existe una etiqueta llamada Keygen que genera un par de claves pública y privada al enviar el formulario. Al servidor únicamente se envía la clave pública. Se puede elegir el algoritmo aunque por defecto se asume RSA.

En la base de datos solo se almacena el hash de la contraseña, de esto se encarga la lógica de negocio. En el caso de que un usuario pierda su contraseña podrá solicitar otra que será enviada a su correo, pero nadie podrá devolverle su antigua clave ya que el sistema no la almacena y a partir del hash es casi imposible obtenerla. Se utiliza como algoritmo de resumen MD5.

Alias: El usuario tiene la opción de introducir el que desee, pero también puede dejar el campo en blanco al registrarse. En ese caso se le asigna uno de forma automática, compuesto por los 4 primeros caracteres de su dirección de correo electrónico (siempre antes de la “@”) más un numero aleatorio.


33

4.3.4.2. Creación y eliminación de datos

Como ya se ha comentado en apartados previos, la inserción de nuevos proyectos, ideas, snippets, peticiones de ayuda, comentarios y etiquetas, únicamente está activa para los usuarios registrados. Éstos pueden introducir tantos como deseen, además de realizar las modificaciones de las que se ha hablado en ellos.

Para eliminar estos datos en cambio, deben solicitarlo, y será el administrador el que lo haga.

Para el cierre de ideas y peticiones de ayuda, los usuarios deberán realizar igualmente la solicitud y el administrador tendrá que tomar la decisión valorando si aún se puede aportar más o no. El hecho de ser cerrada una idea o petición no significa que se elimine y desaparezca de la base de datos. Continúa existiendo ya que puede resolver dudas a otros usuarios con el mismo problema aunque no puede ser comentada.

Los administradores tienen el permiso exclusivo de eliminar cualquier proyecto, así como de eliminar usuarios. Además pueden crear nuevos usuarios con permisos de administración.

4.4. El plan de pruebas

4.4.1. ¿Qué plan de pruebas se va a seguir?

Se van a realizar diferentes tipos de pruebas:

Unitarias: Se van a realizar sobre cada módulo por separado. Tantas como sea necesario, para comprobar el funcionamiento de cada módulo de forma independiente.

De integración: Una vez finalizados cada uno de los módulos, durante la fase de integración, se realizan estas pruebas, para comprobar que todo funciona de forma conjunta.

De las pruebas realizadas, se muestran los detalles en el anexo correspondiente.


35

5. Implementación

5.1. El entorno

Para la creación de la aplicación se han utilizado diferentes herramientas que se exponen a continuación:

- XAMPP

- Eclipse: Se utiliza la versión más reciente de Eclipse: Eclipse Standard/SDK Kepler Release. La razón de utilizar Eclipse es únicamente la familiaridad con esta plataforma. También se barajan otras opciones como NetBeans o Aptana, pero finalmente son descartadas en beneficio de éste.

- Navegadores cómo Mozilla Firefox, Google Chrome, Internet Explorer y Safari.

Las razones de utilizar estos navegadores son, en el caso de Internet Explorer, que es el navegador predeterminado de Windows y aunque está cayendo en desuso pensamos que aún es muy utilizado.

En cuanto a Safari, se utiliza ya que es el propio de Macintosh, y José Ignacio utiliza dicho Sistema Operativo. Además, esto puede dar mayor valor a nuestra aplicación al hacerla apta para un mayor número de navegadores.

El uso de Firefox y Chrome, no necesita de explicación. Se entiende que actualmente son los navegadores por excelencia.


36

5.2. Generación del código

Se comienza por la Lógica de Negocio, capa independiente tanto de la interfaz como de qué sistema de almacenamiento de datos se utilizará en la Persistencia. Esto se hace así por dos razones: La primera es conseguir una separación clara de los TFGs así como una distribución del trabajo. La segunda es conseguir la separación en capas, de manera que se pueda trabajar con total independencia y reducir al mínimo los costes de solución de errores o de mejora del producto. Una vez creada esta capa, se sabrá de forma clara lo que se debe hacer en cada una de las otras y la funcionalidad que se pide.


37

6. Planificación final

6.1. Calendario

Fase del proyecto Inicio Final

D.O.P. 17.02.2014 25.02.2014

ANÁLISIS Y DISEÑO 26.02.2014 25.03.2014

ESQUELETO 26.03.2014 10.04.2014

LÓGICA DE NEGOCIO Y PERSISTENCIA

11.04.2014 26.05.2014

PAUSA (ACTUALIZACIONES Y CORRECCIONES)

27.05.2014 05.06.2014

UNIFICACIÓN 06.06.2014 16.06.2014

CIERRE 17.06.2014 20.06.2014

PRESENTACIÓN 21.06.2014 01.07.2014

REUNIÓN 1 17.02.2014 REUNIÓN 5 12.05.2014

REUNIÓN 2 03.03.2014 REUNIÓN 6 26.05.2014

REUNIÓN 3 17.03.2014 REUNIÓN 7 05.06.2014

REUNIÓN 4 07.04.2014


38

FEBRERO MARZO ABRIL MAYO JUNIO JULIO

L M X J V S D

1 2

3 4 5 6 7 8 9

10 11 12 13 14 15 16

17 18 19 20 21 22 23

24 25 26 27 28

L M X J V S D

1 2

3 4 5 6 7 8 9

10 11 12 13 14 15 16

17 18 19 20 21 22 23

24 25 26 27 28 29 30

31

L M X J V S D

1 2 3 4 5 6

7 8 9 10 11 12 13

14 15 16 17 18 19 20

21 22 23 24 25 26 27

28 29 30

L M X J V S D

1 2 3 4

5 6 7 8 9 10 11

12 13 14 15 16 17 18

19 20 21 22 23 24 25

26 27 28 29 30 31

L M X J V S D

1

2 3 4 5 6 7 8

9 10 11 12 13 14 15

16 17 18 19 20 21 22

23 24 25 26 27 28 29

30

L M X J V S D

1 2 3 4 5 6

7 8 9 10 11 12 13

14 15 16 17 18 19 20

21 22 23 24 25 26 27

28 29 30 31

6.2. Variación de tiempos

Se han producido una serie de variaciones en los plazos, algunas de ellas esperadas e incluso previstas aunque también ha habido algunos cambios debidos a la morfología del proyecto con los que no se contaba.

1) Análisis y diseño

En primer lugar, en el calendario original se programó un diseño breve, incluido en cuanto a plazos en el análisis, ya que se pensó realizarlo en dos fases: primero en el momento de la construcción del esqueleto y más tarde al comenzar a crear la lógica de negocio. Sin embargo, tras alguna reunión y por consejo del tutor se decidió realizar una fase de diseño convencional, evitando dificultades y pérdidas de tiempo innecesarias. Por esta razón, la fase de análisis se amplió convirtiéndose en fase de análisis y diseño. Si bien aparecen juntas, el diseño no comenzó hasta finalizar el análisis.

2) Esqueleto

Los tiempos en la construcción del esqueleto se mantienen, ya que aunque se comenzó más tarde, una vez iniciado, el coste de tiempo fue el ideado.

3) Lógica de negocio y persistencia

Tras esta fase, vuelve el trabajo individual, en el que ninguno de los miembros tenemos más contacto que una reunión cada dos semanas y las reuniones ya programadas con el tutor. Mi parte se centrará en la persistencia y la lógica de negocio, abarcando una parte más amplia en cuanto a trabajo, si bien la parte de José Ignacio es algo desconocido y por ello debe dedicar un alto número de horas a la formación antes de comenzar a crear la capa de interfaz.

4) Pausa y mejoras

Tras finalizar la fase de lógica y persistencia, con un retraso de alrededor de una semana y media, debo permanecer semi-ocioso durante los siguientes diez días, ya que la siguiente fase


39

en el calendario es la unificación y José Ignacio aún debe finalizar la interfaz. Esta tardanza por su parte se debe a que el tiempo dedicado al proyecto ha sido menor que en mi caso, al estar cursando dos asignaturas mientras yo estaba libre de ellas. En este periodo aprovecho para cerrar la documentación pendiente además de realizar mejoras en el código y crear nuevas funcionalidades que a día de hoy quedan sin uso pero pueden ser necesarias en futuras ampliaciones (nuevas listas, posibilidad de modificación y obtención de datos a los que actualmente el usuario no tendría acceso, optimización de funciones…).

5) Unificación

Una vez superado este bache, se comienza con fase de unificación, para la cual se hace necesario el volver a trabajar en equipo. Conseguimos ahorrar tiempo en esta fase respecto a la planificación inicial gracias en parte a la mayor implicación de José Ignacio una vez finalizadas las clases.

6) Cierre

La fase de cierre vuelve a ser completamente individual. Mucho más breve de lo esperado, ya que en el tiempo transcurrido entre la unificación y la finalización de la persistencia pude dedicarme a ir cerrando flecos.

De esta forma, gracias a que en la planificación inicial se estableció un margen de dos semanas entre la fecha finalización del trabajo y la fecha de depósito se ha conseguido llegar dentro de los plazos académicos, si bien no dentro de nuestros plazos.

Los tiempos finales son los siguientes:

Actividad Número de horas

Establecimiento de objetivos 15

Análisis y diseño 40

Creación del esqueleto 30

Preparar servidor y base de datos 12

Desarrollo 125

Unificación 20

Presentación 9

Reuniones 25

Formación 18

Total 294


41

7. Valoración y lecciones aprendidas

7.1. Valoración del trabajo

La valoración de los resultados obtenidos así como de lo obtenido gracias a este TFG no es sencillo de valorar. En este apartado entraremos exclusivamente en lo tangible, en el resultado que se puede observar con la aplicación y la documentación en la mano.

En primer lugar, una vez que la idea comienza a tomar forma, se debe elegir la plataforma en la que se desarrollaría y las primeras opciones son PHP y JavaScript. La razón es que ambos alumnos cursamos la antigua I.T.I.G. y conocíamos el lenguaje ya que entre otras cosas nuestros respectivos proyectos fueron en esta plataforma.

En opinión personal, entiendo que volver a utilizar una herramienta que ya conocíamos restaría valor a nuestro currículo y no resultaría tan interesante. Por ello intento imponer con éxito Java como lenguaje principal, ya que si bien es cierto que lo habíamos utilizado en varias asignaturas durante la carrera, ya hacía más de dos años que no lo tocaba. Además se trata del segundo lenguaje más utilizado actualmente por detrás de C.

Otra razón para la elección de Java en este TFG es la diferencia que suponía respecto al anterior PFC, al tratarse de un lenguaje orientado a objetos.

El resultado obtenido con las plataformas elegidas pienso que ha sido muy positivo, además de resultar bastante entretenido y sencillo de encontrar los errores. Pienso que esta experiencia añade valor al futuro currículum, ya que permite no partir de cero con Java.


42

7.2. El trabajo en equipo

Desde hace bastantes años soy entrenador de equipos infantiles de balonmano y gracias a ello he aprendido más de lo que cualquier escuela podría enseñar y entre esas cosas está que el grupo siempre añade valor al individuo, por ello, el rendimiento de cada individuo dentro de un grupo es mayor que fuera de él, especialmente cuando el objetivo se siente como propio.

La idea de trabajar en equipo, también supone un reto, ya que requiere un esfuerzo especial al inicio para hacer que el grupo funcione, sin embargo, cuando pensamos en éste proyecto creemos que a pesar de este hándicap podríamos conseguir un resultado muy potente.

En mi opinión, la educación actual debe estar encaminada al trabajo en equipo, ya que en el mundo laboral la inmensa mayoría de puestos de trabajo requieren de la colaboración y la interacción con otras personas. Sería difícil de imaginar un equipo de desarrollo en el que los miembros no se comunicaran y cada uno hiciera lo que creyera mejor sin saber si su pieza encajará con la del compañero, o peor, si cada miembro intentara abarcar todas las piezas del puzle que es por ejemplo el desarrollo de un videojuego.

Por ello pienso que el trabajo realizado en bastantes asignaturas de esta carrera está orientado de forma correcta, y que los TFGs deben seguir el mismo camino.

Volviendo al TFG propio, no ha sido sencillo el trabajar en equipo porque durante los primeros meses el tiempo de dedicación fue muy reducido ya que ambos miembros compatibilizamos trabajo con estudios. Además José Ignacio continuaba teniendo dos asignaturas mientras yo estaba libre de ellas.

Por otro lado, al tratarse de dos TFGs individuales, la parte de trabajar en equipo se redujo al análisis y diseño de la aplicación, lo que nos llevo más tiempo del esperado al necesitar de bastantes reuniones para encontrar los puntos comunes. Tras ello, se realiza un esqueleto de la aplicación y ya no se volverá a trabajar en equipo hasta la unificación de las partes de la aplicación, una fase más breve de lo esperado ya que en las primeras fases comunes conseguimos realizar un trabajo bastante bueno en mi opinión.

Finalmente, pienso que el resultado obtenido es una experiencia más de trabajo en equipo, positiva y que será más positiva aún en el futuro cuando necesite de las habilidades que se adquieren con esta forma de trabajo como mejora en la comunicación, la negociación, la organización o la planificación de tiempos contando con otras partes. En definitiva, una experiencia más real de la que puede resultar un TFG clásico.


43

7.3. Los tiempos

En este trabajo, he sabido administrar mejor los tiempos y hacer una previsión más realista gracias a no tratarse del primer TFG (o PFC).

Si bien es cierto que ha habido variaciones en el tiempo previsto inicialmente, no han sido graves y se dejo para ello un margen del que hemos podido echar mano. Estas variaciones las achaco principalmente al hecho de ser un proyecto que en parte dependía de la labor del otro miembro del equipo. No considero esto algo negativo, sino una experiencia absolutamente necesaria y por ello, positivo.

7.4. Futuras ampliaciones

Al tratarse de dos trabajos con un único producto como objetivo, existe un gran margen de mejora o ampliación de las funcionalidades, varias de las cuales ya están creadas en lógica y persistencia aunque sin uso en la actual versión como se expone en el apartado de Implementación.

La primera de estas ampliaciones, es la idea que ha rondado en la cabeza desde antes de iniciar el TFG, hacer de esto algo más que un trabajo que tras su presentación quede guardado en un cajón para siempre. Se desea buscar la forma de hacer que la aplicación funcione en un entorno real, para ello llegado el momento se buscaran opciones como alojarlo en servidores gratuitos y buscar publicidad o alguna manera de darlo a conocer. Una vez esté funcionando, se verá si alguna de las partes existentes (proyectos completos, fragmentos de código, ideas y ayudas) no funciona para orientar la aplicación hacia aquello que los usuarios demanden.

Otra vía de trabajo es que los usuarios puedan contactar en tiempo real dentro de la aplicación, volviendo con ello a la idea original de “red social” de colaboración entre ingenieros software o informáticos aficionados.


45

8. Bibliografía

Se han utilizado una serie de ayudas, tanto en formato digital como en papel.

En formato digital:

- https://www.java.com/es/ Pagina oficial de java con descargas, manuales y documentación.

- http://docs.oracle.com/javase/7/docs/api/ API de Java.

- http://www.adictosaltrabajo.com/ Página con tutoriales diversos.

- http://lineadecodigo.com/ Otra página con tutoriales.

Se han utilizado otras webs de ayuda de forma puntual, para resolver pequeñas dudas, buscando a través de Google.es.

En papel:

- Database Administration: The complete guide to practices and procedures (Craig S. Mullins)

- Diseño de bases de datos: Problemas resueltos (Adoración de Miguel, Paloma Martínez, Elena Castro, José Mª Cavero, Dolores Cuadra, Ana Mª Iglesias, Carlos Nieto)


47

desarrollo de una plataforma de colaboración entre ... · plataforma de colaboración entre...

Documents