Desarrollo de una plataforma de colaboración entre …José Ignacio Martínez Castillejo Angel Luis...

José Ignacio Martínez Castillejo

Angel Luis Rubio García

Facultad de Ciencias, Estudios Agroalimentarios e Informática

Grado en Ingeniería Informática

2014-2015

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. Presentación Web

Autor/es

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

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

Desarrollo de una plataforma de colaboración entre ingenieros de software. Presentación Web, trabajo fin de grado

de José Ignacio Martínez Castillejo, 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.

RESUMEN

Este proyecto consiste en desarrollar una plataforma de colaboración entre ingenieros software, centrándose en la presentación web y la lógica de negocio.

Se trata de una aplicación conjunta entre 2 TFGs para imitar una situación de trabajo más real, debido a que uno es el back-‐end y el otro el front-‐end. Los trabajos parten de un análisis, un diseño y una base común que es la lógica de negocio. Este trabajo consiste en implementar la interfaz gráfica de la plataforma mediante JSP.

El colaborar con otra persona ha enriquecido y dificultado el resultado de esta plataforma.

ABSTRACT

This project consists to develope a platform for collaboration between software engineers, focusing on web presentation and business logic.

This is a joint application from 2 TFGs to imitate a situation more real work, due to one is the back-‐end and the other front-‐end. The works are based on analysis, design and common basis that is the business logic. This work consists to implement GUI platform using JSP.

To collaborate with another person has enriched and difficult result of this platform.

INDICE INDICE ............................................................................................................................................................. 1 1. INTRODUCCIÓN ................................................................................................................................... 1 2. DESARROLLO ....................................................................................................................................... 3 2.1. OBJETIVOS DEL TRABAJO ................................................................................................................................... 3

2.1.1. Alcance ......................................................................................................................................................... 3 2.1.2. Estructuración .......................................................................................................................................... 3 2.1.3. Organización .............................................................................................................................................. 3 2.1.4. Riesgos ......................................................................................................................................................... 4 2.1.5. Planificación inicial de tiempos ......................................................................................................... 4 2.1.6. Calendario inicial ..................................................................................................................................... 5

Fases del proyecto .......................................................................................................... 6 2.1.6.1.2.2. ANÁLISIS ..................................................................................................................................................................... 9

2.2.1. Filosofía de la plataforma ..................................................................................................................... 9 2.2.2. ¿Quiénes participan? .............................................................................................................................. 9 2.2.3. ¿Qué pueden hacer los usuarios? ................................................................................................... 10

Usuario externo ............................................................................................................. 10 2.2.3.1. Usuario registrado ....................................................................................................... 10 2.2.3.2. Administrador ............................................................................................................... 10 2.2.3.3.

2.2.4. ¿Qué funcionalidad tiene la aplicación? ...................................................................................... 11 Proyectos ......................................................................................................................... 11 2.2.4.1. Comentarios ................................................................................................................... 12 2.2.4.2. Etiquetas y el buscador .............................................................................................. 13 2.2.4.3. Imágenes .......................................................................................................................... 13 2.2.4.4. Área privada ................................................................................................................... 13 2.2.4.5.

2.2.5. ¿Dónde se aloja la aplicación? ......................................................................................................... 13 2.3. DISEÑO ...................................................................................................................................................................... 15

2.3.1. El entorno ................................................................................................................................................ 15 ¿Qué herramientas se van a utilizar? ................................................................... 15 2.3.1.1. ¿Cuáles son los lenguajes? ........................................................................................ 15 2.3.1.2.

2.3.2. La aplicación ........................................................................................................................................... 15 ¿Qué nos vamos a encontrar? ................................................................................. 15 2.3.2.1.

2.3.3. Los datos ................................................................................................................................................... 21 La base de datos ............................................................................................................ 21 2.3.3.1. ¿Cómo se almacenan los datos? ............................................................................. 22 2.3.3.2. ¿Cómo se gestionan los datos? ............................................................................... 22 2.3.3.3.

2.3.4. Estructura de la plataforma ............................................................................................................. 23 ¿Qué diseño se plantea? ............................................................................................ 23 2.3.4.1. ¿Cómo se dividirán los módulos del sistema? ................................................. 23 2.3.4.2.

2.3.5. Plan de pruebas ..................................................................................................................................... 24 2.4. IMPLEMENTACIÓN .............................................................................................................................................. 25

2.4.1. Resultado final ....................................................................................................................................... 25 2.4.2. Fragmentos de código ........................................................................................................................ 27

2.5. PLANIFICACIÓN FINAL ...................................................................................................................................... 31 2.5.1. Variación de tiempos .......................................................................................................................... 31 2.5.2. Variación de calendario ..................................................................................................................... 31

Fases .................................................................................................................................. 32 2.5.2.1.2.5.3. Segunda variación de tiempos ........................................................................................................ 33

3. CONCLUSIONES ................................................................................................................................ 35 3.1. Opinión del trabajo .............................................................................................................................................. 35 3.2. El tiempo .................................................................................................................................................................. 36 3.3. Futuras ampliaciones ......................................................................................................................................... 36 4. BIBLIOGRAFÍA .................................................................................................................................. 37

INTRODUCCIÓN

1

1. INTRODUCCIÓN El objetivo es desarrollar una plataforma para la compartición de proyectos y código (snippet) entre ingenieros del software y desarrolladores freelance. El trabajo consiste en construir una aplicación web donde se pueda desempeñar esa tarea.

Los usuarios podrán compartir sus proyectos finalizados, o ideas de proyectos en las que necesiten colaboración, pudiendo comentar y ayudar en los trabajos publicados por otros usuarios.

La idea surge en clase de Taller Transversal II, entre Alejandro Saéz Subero y José Ignacio Martínez Castillejo, cuando proponen realizar una aplicación para una comunicación y un seguimiento entre usuarios durante la realización del trabajo fin de grado. Tras un par de conversaciones se plantea enfocar la idea no solo en el ámbito universitario sino a nivel profesional.

Existen varias motivaciones para desarrollar este trabajo.

La primera es emular un entorno de trabajo muy similar al que existe en las empresas, ya que se busca una clara división del trabajo a desarrollar por cada persona, como si se tratase de departamentos independientes.

La segunda es utilizar lenguajes que no habíamos utilizado antes para el desarrollo de un portal web, como son HTML5 y Java.

El planteamiento hace ver que su desarrollo será más sencillo, pero aparecen otros problemas como la comunicación entre ambas partes, dedicar más tiempo en reuniones y tener que documentarse en gran medida.

DESARROLLO – OBJETIVOS DEL TRABAJO

3

2. DESARROLLO

2.1. OBJETIVOS DEL TRABAJO

2.1.1. Alcance El objetivo es un portal limpio e intuitivo con una buena usabilidad para fomentar la compartición de proyectos y código por parte de los usuarios registrados, y el acceso a la información por parte de cualquier usuario.

Los usuarios registrados podrán compartir sus proyectos finalizados, así como proyectos en mente, los denominaremos ideas, para las que necesiten colaboración. También podrán compartir código para poder ser reutilizado, y realizar comentarios a las peticiones de ayuda de otros usuarios.

Como parte principal contará con un buscador. Los proyectos subidos por los usuarios tendrán asignadas etiquetas, algunas obligatorias y otras insertadas por el usuario. Se desea que el usuario introduzca algunas palabras en el buscador para obtener una lista de proyectos relacionados con esa búsqueda.

La herramienta se autogestionará por los usuarios registrados, existiendo un administrador que controle el buen uso de esta.

2.1.2. Estructuración La aplicación se divide en las tres capas clásicas (persistencia, lógica de negocio y presentación). Se construirá un esqueleto de cada una de las tres capas, para ir añadiéndoles funcionalidad posteriormente.

La capa de presentación usará JSP, HTML5 y CSS3 como lenguajes. Utilizamos JSP y HTML5 con el objetivo de conocer estos lenguajes ya que consideramos que tienen características interesantes.

Para las demás capas se utilizará Java. Los autores del trabajo utilizamos este lenguaje en la anterior titulación, pero desde entonces no lo hemos utilizado y nos parece importante volver.

Se utilizará MySQL para la gestión de la base de datos. Lo relacionado con la creación y el diseño de la base de datos se detalla en un anexo.

2.1.3. Organización La aplicación a realizar va a estar dividida en dos TFGs, el back-‐end realizado por Alejandro, el front-‐end por José Ignacio y la lógica de negocio se desarrollará de forma común para ser utilizada por ambas partes.

Se decide seguir la metodología de trabajo SCRUM. 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. Es probable que este modo de funcionamiento provoque

DESARROLLO DE UNA PLATAFORMA DE COLABORACIÓN ENTRE

INGENIEROS DE SOFTWARE: PRESENTACIÓN WEB

4

que se tenga que trabajar más intensamente, pero pensamos que a cambio tiene ventajas como obligar a contrastar las diferentes ideas.

Tras superar las primeras fases de reuniones y dialogo, si éstas se realizan con éxito, durante las siguientes fases de construcción de la plataforma no será necesario reunirse, salvo una o dos veces al mes, para comprobar el avance. Concluida esta fase de trabajo en común se verán 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. Riesgos Para evitar retrasos en las planificaciones se tendrá un seguimiento casi constante con Alejandro al finalizar los sprints, y con el tutor en las reuniones.

El desconocimiento de alguno de los lenguajes puede ralentizar la evolución del trabajo, por lo que se han buscado manuales y libros donde obtener ayuda.

En caso de caer enfermo o lesionado durante la elaboración individual de la lógica de negocio puede conseguir que no se cumplan los plazos, teniendo que recuperar las horas modificación el calendario planificado.

Con idea de no perder código ni documentos, se tiene una planificación de copias de seguridad, incremental cada día que se realicen cambios y completa en cada uno de los sprints donde se juntan los desarrolladores. El repositorio de código cuenta con un control de versiones en caso de que falle la restauración de las copias de seguridad.

2.1.5. Planificación inicial de tiempos

Actividad Número de horas

Reuniones 15

Objetivos del proyecto 5

Formación 10

Análisis del esqueleto 30

Creación del esqueleto 40

Preparar servidor y el repositorio de código 25

Análisis de la lógica de negocio 30

Desarrollo de las funcionalidades individuales 85

Unificación 30

Documentación 25

Presentación 5

TOTAL 300


5

2.1.6. Calendario inicial 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

SEGUNDO CIERRE 01.02.2015 13.02.2015

DEFENSA 19.06.2014 31.06.2014

SEGUNDA DEFENSA 08.07.2015 15.07.2015

FEBRERO MARZO ABRIL MAYO

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

JUNIO ENERO 2015 FEBRERO 2015 JULIO 2015

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 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

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

REUNIÓN 1 17.02.2014

REUNIÓN 2 03.03.2014

REUNIÓN 3 17.03.2014

REUNIÓN 4 07.04.2014

REUNIÓN 5 05.05.2014

REUNIÓN 6 19.05.2014

REUNIÓN 7 05.06.2014

REUNIÓN 8 22.06.2015



6

Fases del proyecto 2.1.6.1.

2.1.6.1.1. DOP y planificación

El inicio oficial del proyecto es el día 17 de febrero de 2014, 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 documento. 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.1.6.1.2. Análisis

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 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á una su parte del análisis y posteriormente esta 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).

2.1.6.1.3. Creación del esqueleto.

Esta fase 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 más en la interfaz y Alejandro en la base de datos.

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

2.1.6.1.4. Lógica de negocio

Es la fase más extensa del trabajo, 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.

2.1.6.1.5. Unificación

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


7

dos sprints.

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

2.1.6.1.6. Cierre del proyecto

En esta fase se finaliza el trabajo, creando la documentación pendiente de realizar, así como uniendo cada uno de los documentos realizados en las fases previas.

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.

Existe una segunda fase de cierre y de presentación debido a que en el curso anterior no se superan todas las asignaturas de Seguridad Informática. Tras superar la asignatura en enero de 2015 se retoman estos dos apartados.

2.1.6.1.7. Defensa

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.

DESARROLLO – ANÁLISIS

9

2.2. ANÁLISIS

2.2.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 usuario 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 este uso, también se estudiará el caso.

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

2.2.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.



10

2.2.3. ¿Qué pueden hacer los usuarios? Cada usuario tiene unas funciones u otras dependiendo del tipo al que pertenezca:

Usuario externo 2.2.3.1.

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.

Usuario registrado 2.2.3.2.

Modificar cuenta: Puede modificar el correo electrónico y su password, pero nunca su alias ya que este actúa como identificador del usuario.

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.

Administrador 2.2.3.3.

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.


11

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 aquellos que considere oportuno, bien por desuso o por no corresponder o ser ofensivos.

2.2.4. ¿Qué funcionalidad tiene la aplicación? La información se divide en varios apartados, que tratan de hacer la plataforma lo mas usable posible.

Proyectos 2.2.4.1.

2.2.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 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. Este punto se explica más adelante en el presente documento.

-‐ 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.

2.2.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.



12

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.

2.2.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.

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

2.2.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.

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

2.2.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


13

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.

Etiquetas y el buscador 2.2.4.3.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 mi 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 tardaran en encontrar lo que buscan. Por ésta razón los administradores deben prestar atención al etiquetado.

Imágenes 2.2.4.4.Los proyectos completos, las ideas y las ayudas pueden ir acompañados de imágenes. El usuario puede decidir si desea subirlas y también el número de estas. 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.

Área privada 2.2.4.5.

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.

El funcionamiento del área privada se expone en detalle en el diseño de la aplicación.

2.2.5. ¿Dónde se aloja la aplicación? La plataforma se va a crear en localhost, ya que se considera más sencillo durante el periodo de construcción del sistema. Para ello, se utiliza XAMPP, un servidor de software libre, que



14

además es multiplataforma (X), lo cual es necesario ya que en la construcción de la plataforma se va a utilizar Windows y Mac.

XAMP contiene Apache (A) como servidor web y MySQL (M) como servidor de base de datos. También implementa los intérpretes para los lenguajes de script PHP y Perl (P), aunque éstos últimos no se van a utilizar en este proyecto.

Como ampliación se estudiará subir la aplicación a un servidor de aplicaciones web e intentar que la plataforma funcione de forma real y no solo a nivel local.

Los siguientes navegadores, Chrome 18, Firefox 12, Opera 11.60, Safari 5.1 y Explorer 9, soportan HTML5, en la mayoría de sus etiquetas.


15

2.3. DISEÑO

2.3.1. El entorno ¿Qué herramientas se van a utilizar? 2.3.1.1.

Se utilizará un equipo portátil MacBook Pro siendo utilizada la herramienta Eclipse para el desarrollo del código realizado durante la parte de implementación. Se plantea utilizar la herramienta Eclipse por mayor familiarización por ambas partes de esta. Aunque otras opciones fueron Aptana Studio y NetBeans.

Los navegadores que se utilizarán son Google Chrome, Mozilla Firefox, Internet Explorer y Safari. Los dos primeros navegadores son los mas utilizados actualmente a nivel mundial, y donde mayor número de etiquetas HTML5 funcionan. Los otros dos navegadores se pueden considerar de uso obligado, debido a que Explorer es la aplicación que usa Windows y Safari es el navegador de serie en los dispositivos de Apple.

¿Cuáles son los lenguajes? 2.3.1.2.Como ya se ha explicado en la introducción, los lenguajes utilizados para diseñar la aplicación son JSP, HTML5 y CSS3 para la capa de presentación, Java en la lógica de negocio y en las conexiones a la base de datos y MySQL para la base de datos.

2.3.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 (más adelante se muestran las características de ésta).

¿Qué nos vamos a encontrar? 2.3.2.1.Un portal con un alto y un ancho específico para evitar el scroll, teniendo en cuenta los tamaños actuales de los portátiles, laptops y monitores.

Se muestran algunas ventanas que podemos encontrarnos dependiendo el usuario. En caso de querer conocer una navegación más completa existe un anexo en formato psd.



16

2.3.2.1.1. Usuario externo

Figura 1 – Ventana home

La ventana de inicio (figura 1) se muestra de la siguiente manera: en el menú tendremos las opciones principales de la aplicación, desplegando el submenú como si fuese un acordeón, mostrando las opciones Hardware, Software y Redes. A la derecha de éste encontramos la opción de acceder al portal o registrarnos.

En los apartados de últimas ideas, peticiones de ayuda y último proyecto, siempre que hagamos clic en el título nos mostrará la información concreta. En caso de pulsar Leer más…, accederemos a la sección especificada (figura 2). Si pulsamos en un título seremos redireccionados a la ventana detalle de ese título (figura 3).

El título del portal, “PICA Snippet”, se origina al coger la primera letra de cada uno de los cuatro apartados o menús principales del portal. Se busco una relación correspondiente con el mundo de la informática, ya que la jerga utilizada que hace referencia a escribir líneas de código es picar código.

Al hacer clic en una sección del menú o buscar por alguna etiqueta se visualizará la ventana de navegación (figura 2).

En el pie solo mostraremos el copyright.


17

Figura 2 – Navegación usuario no registrado

En la ventana de navegación el menú pasa a ser la primera letra de cada sección, y haciendo clic mostrará el submenú en formato acordeón.

No se pierde el buscador, ya que se busca fomentar su uso. La cuadricula de descripción mostrará una descripción corta. Al hacer clic en documentación o imágenes se mostrará un slide para poder visualizar a un tamaño mas normal el documento o la galería de imágenes introducida, de la documentación se observará la portada y de las imágenes la primera imagen introducida por el usuario.

Todas las secciones contarán como máximo con tres proyectos por página, teniendo mayor espacio en las de ayuda y código ya que no cuentan con el campo documentación ni imagen.

La imagen siguiente representa la sección de proyectos, variando en las secciones de ayuda y código ya que no contarán con documentación ni con imágenes, al menos la sección código.

Figura 3 – Detalle de un proyecto visto por un usuario no registrado

Donde leemos descripción encontraremos los campos de información obligatoria, aparte de la descripción completa del proyecto.

En caso de querer registrarnos mostrará un formulario (figura 4) donde se puede leer la



18

filosofía de la plataforma y las condiciones de uso.

Figura 4 – Formulario registro

2.3.2.1.2. Usuario registrado

El usuario registrado puede descargar documentos, generar contenido en la aplicación y editar su perfil.

Figura 5 – Navegación usuario registrado

Podemos observar como se desplegará el menú dejando visible el nombre de la aplicación, al submenú se le añade la opción nuevo para generar el contenido en la pestaña deseada. A la derecha podemos acceder a configurar el perfil (figura 6) haciendo clic en el alias, o salir de la aplicación. En los proyectos e ideas aparecerá visible la opción de descargar, pudiendo seleccionar el documento que deseamos, en las ventanas de detalle.


19

Figura 6 – Datos perfil

Esta ventana será la que veremos al hacer clic en nuestro alias, mostrando nuestros datos y un listado con el contenido que hayamos creado en la aplicación, mostrando primero el último contenido añadido.

Al pulsar en modificar (figura 7) veremos un par de cuadros de texto para rellenar y modificar el campo deseado, el correo o la contraseña. En la columna campos se mostrarán los títulos (sirviendo de enlace a su ventana de detalle en caso de querer modificarlos), fecha de creación y sección a la que pertenecen. La columna llamada eliminar contiene un botón para realizar una petición de eliminación del contenido al administrador.

Figura 7 – Datos perfil (modificar)



20

2.3.2.1.3. Usuario administrador

Figura 8 – Navegación administrador

Como administrador podemos visualizar todos los listados, siendo el primero el de proyectos. La columna campos muestra quien lo ha realizado, su fecha, el título y el tipo (hardware, software o redes). Dependiendo la sección variarán los campos.

En la columna eliminar existirá un botón que tras pulsarlo pida confirmar que deseamos eliminar el contenido.


21

2.3.3. Los datos La base de datos 2.3.3.1.

2.3.3.1.1. Modelo Conceptual

Figura 9– Modelo conceptual

2.3.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.

De ésta tabla 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 proyecto que incluye la documentación y el código para descargar.

Idea, se utiliza para compartir una idea que un usuario ha tenido y comentarla, teniendo su creador la opción de subir la documentación que desee.

FragmentoCódigo permite que los usuarios suban fragmentos de código que hayan creado con la intención de que otras personas puedan beneficiarse de ello. Este código esta en formato descargable o para visualizar.

Ayuda, sirve para que los usuarios puedan solicitar ayuda con cualquier duda o



22

contratiempo que les surja.

De los usuarios solo se quiere conocer su correo electrónico. Además pueden introducir el Alias que deseen o utilizar su correo como alias. 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”. Gracias a ellas los proyectos pueden ser catalogados y la búsqueda de estos por parte del usuario es mucho más sencilla.

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

¿Cómo se almacenan los datos? 2.3.3.2.

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 almacenamiento especial:

-‐ Imágenes: En la base de datos tan solo se mantiene un enlace de esta. Los objetos están almacenados en una carpeta. En una hipotética ampliación lo estarían en el servidor. Se considera que ésta es la mejor opción de almacenaje debido a que las imágenes son demasiado pesadas para almacenar un gran número directamente en la base de datos. Además esto puede evitar problemas de compatibilidad de formato en la base de datos.

-‐ 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. Código también es almacenado como un enlace pero éste dirige a un zip 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 (sólo texto), mientras que para la parte descargable, llamada EnlaceCódigo, se almacena un enlace al igual que en los proyectos completos.

¿Cómo se gestionan los datos? 2.3.3.3.

2.3.3.3.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


23

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. 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.

2.3.3.3.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.

2.3.4. Estructura de la plataforma ¿Qué diseño se plantea? 2.3.4.1.

La arquitectura pensada es de cliente/servidor debido a que cubre las necesidades de la aplicación. Teniendo en cuenta que si no es posible ubicarlo en un servidor real, el que se utilizara será el localhost.

Se plantea de esta manera porque los usuarios que accedan a la aplicación desde sus equipos solicitarán servicios. El servidor será un mero gestor de BD.

La arquitectura dispondrá de dos niveles porque requiere poco procesamiento de datos, tendrá una BD centralizada en un servidor y relativamente estática, y se requiere un mantenimiento mínimo de la aplicación.

¿Cómo se dividirán los módulos del sistema? 2.3.4.2.Se dividirán cada una de las capas en el servidor por carpetas que especifiquen a que tipo pertenecen, siendo la carpeta “funciones” la utilizada para la capa de persistencia, “lógica”



24

donde se almacenen los archivos de la lógica de negocio y “presentación” donde se ubique la interfaz.

La comunicación entre los módulos se realizará con llamadas a funciones siendo en la presentación donde se recojan los datos para enviarlos a la lógica de negocio, al igual que sirva para mostrar los datos que reciba de esta al usuario, la lógica de negocio, comprobará los datos cuando sea preciso, enviando la información precisa a la capa de persistencia, esta última se encargará de la comunicación con la BD.

2.3.5. Plan de pruebas 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.

DESARROLLO – IMPLEMENTACIÓN

25

2.4. IMPLEMENTACIÓN

Se concreta y desarrolla una Lógica de Negocio común, capa independiente tanto de la interfaz como de qué sistema de almacenamiento de datos se utilizará en la Persistencia.

Con esto se quiere conseguir una separación clara de los trabajos y una separación en capas, de manera que se pueda trabajar con total independencia entre ambos TFG y reducir al mínimo los costes de solución de errores o de mejora del producto. Una vez creada esta capa, se sabe de forma clara lo que se debe hacer en cada una de las otras y la funcionalidad que se pide.

Lo siguiente es el desarrollo de la capa de presentación desconociendo en todo momento toda la funcionalidad existente hasta la reunión donde se unifique el proyecto. Mientras tanto se genera una capa de persistencia con una serie de datos para ir desarrollando las pruebas unitarias.

Por último al terminar la capas de presentación y persistencia se unirán dichas capas para obtener una aplicación final.

2.4.1. Resultado final Mostramos como quedan en un navegador algunas ventanas de la aplicación.

Figura 10 – Ventana de inicio.



26

Figura 11– Ventana de proyectos hardware

Figura 12 – Ventana de detalle de proyecto

Figura 13– Ventana de nuevo proyecto


27

Figura 14– Ventana de registro de usuario

2.4.2. Fragmentos de código En este apartado explicaremos un poco las características comunes que siguen casi todos los ficheros de la aplicación.

La cabecera de nuestras páginas tiene un alto contenido de tags para el posicionamiento en motores de búsqueda o posicionamiento SEO (Search Engine Optimization).



28

En el cuerpo destacamos la forma de incluir código desde otros archivos, como es el caso que vemos en la línea 39, donde insertamos el menú que vamos a utilizar en toda la aplicación para que si queremos hacer un cambio el día de mañana solo haya que hacerlo en un documento y no ir documento a documento buscando el código.

Las etiquetas utilizadas son las que recomienda HTML5 para estructurar la información del portal. Como es el caso de article o los listados para organizar la información dentro de las etiquetas nombradas antes.

El efecto de acordeón del menú viene heredado desde la hoja de estilo, como vemos en la línea 3 donde utilizamos el identificador “izq” y la clase “horizontal”. La forma de estructurarlo vuelve a ser mediante listados, ya que Google premia la posición siempre que se realice de dicha forma.


29

La hoja de estilo se ha documentado todo lo posible, porque se busca tener solo una para que la primera vez que se cargue la página cueste algo más, pero luego no sea necesario volver a cargarla ya que estará almacenada en la memoria caché. Si no se hiciese de esta forma sería imposible poder editar algo después.

Aquí está el ejemplo del menú, que se han mantenido los comentarios para saber que función tiene cada una de las clases que corresponden al identificador “izq”.

DESARROLLO – PLANIFICACIÓN FINAL

31

2.5. PLANIFICACIÓN FINAL

2.5.1. Variación de tiempos

Actividad Número de horas

Reuniones 25

Objetivos del proyecto 15

Formación 41

Análisis y diseño 40

Creación del esqueleto 30

Desarrollo de las funcionalidades individuales 107

Unificación 20

Documentación 13

Presentación 5

TOTAL 296

2.5.2. Variación de 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 PRESENTACIÓN 11.03.2014 05.06.2014

UNIFICACIÓN 06.06.2014 16.06.2014

CIERRE 17.05.2014 22.06.2014

SEGUNDO CIERRE 01.02.2015 22.02.2015

PRESENTACIÓN 23.06.2014 31.06.2014

SEGUNDA DEFENSA 08.07.2015 15.07.2015

REUNIÓN 1 17.02.2014

REUNIÓN 2 03.03.2014

REUNIÓN 3 17.03.2014

REUNIÓN 4 07.04.2014

REUNIÓN 5 12.05.2014

REUNIÓN 6 29.05.2014

REUNIÓN 7 05.06.2014

REUNIÓN 8 22.06.2015



32

FEBRERO 2014 MARZO 2014 ABRIL 2014 MAYO 2014

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

JUNIO FEBRERO 2015 JUNIO 2015 JULIO 2015

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

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

Fases 2.5.2.1.Se han producido variaciones en las fases del calendario las cuales se contaba que podían darse, aunque alguna otra ha necesitado de mayor urgencia para solucionarse.

2.5.2.1.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.5.2.1.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 planeado.

2.5.2.1.3. Lógica de negocio y presentación

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 centrara en la presentación y colaboración en la lógica de negocio. Con la lógica de negocio solo se realizan pequeñas puntualizaciones para aclarar qué funciones pertenecen a ella, pero mi mayor problema surge en la presentación. El lenguaje de HTML 5 no causa retrasos para generar las plantillas a utilizar, el gran retraso surge con JSP que aunque me documentaba no lograba los resultados esperados. Mi gran desconocimiento sobre la materia, y alguna asignatura pendiente, consigue que todo se retrase una semana y media, necesitando el apoyo del profesor de Programación de Aplicaciones Web y poder obtener algún resultado. Tras este retraso todo sigue el mismo ritmo y se retoma una continuidad normal.

2.5.2.1.4. Unificación

Para la fase de unificación se hace necesario el volver a trabajar en equipo. Conseguimos ahorrar tiempo en esta fase respecto a la planificación inicial al poder comunicarnos con

DESARROLLO – PLANIFICACIÓN FINAL

33

mayor frecuencia, que en la parte individual.

2.5.2.1.5. Cierre

Esta fase vuelve a ser individual. Como 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.

2.5.3. Segunda variación de tiempos Debido a suspender la asignatura de Seguridad Informática en el anterior curso el cierre y la defensa se ven modificados. La nueva fecha de cierre y de deposito es la correspondiente al curso 2014-‐2015, comprendida entre el 24 y 30 de junio.

CONCLUSIONES

35

3. CONCLUSIONES

3.1. Opinión del trabajo

La idea que nace para desarrollar este TFG es intentar romper moldes desarrollando un trabajo final común. Durante todo el curso en bastantes asignaturas existen los trabajos en equipo, queriendo así orientar a los estudiantes a la vida laboral. Y de ahí que nuestro reto sea el de evitar los TFG individuales, ya que el día de mañana, acabes donde acabes formarás parte de un equipo de trabajo.

En el desarrollo de este producto podemos diferenciar dos departamentos de una empresa, por un lado el departamento de desarrollo y por otro el de diseño. Aunque en esta ocasión tenemos una parte común que será la capa de lógica de negocio. Observando que una buena comunicación entre estas partes obtiene un mejor resultado.

Una cosa a tener en cuenta en el desarrollo del trabajo es que ambas partes utilizábamos equipos y sistemas operativos diferentes, teniendo desconocimiento de algunas utilidades de mi equipo Mac, dándonos a ambas partes algún conocimiento mas sobre este tipo de equipos.

Un TFG compartido parece algo fácil, que no existen retos, pero en verdad contiene mas dificultad. Por un lado el compromiso, no trabajas solo para ti, los plazos son comunes, tu trabajo puede perjudicar al de los demás, no es una entrega de prácticas que se puede aplazar. Por otro lado la comunicación, es muy importante saber expresarse y tener un buen tacto con el grupo de trabajo, ya que con un buen clima se obtienen mejores resultados. Y los roles, no nos olvidemos que en una empresa cada uno desempeña su papel y no se puede salir de este.

En este TFG me he encontrado con que las partes anteriores se han sabido llevar muy bien con Alejandro, ya que la relación iniciada en ITIG y en otras actividades extraescolares, hace que nuestro compromiso y comunicación sigan el mismo ritmo, al igual que tener un rol común ante Ángel Luis. Aunque el trabajo en equipo en las dos primeras partes ha hecho que nos cueste más realizar el análisis y el diseño en comparación con una persona individual, ya que las reuniones y los distintos puntos de vista alargan el tiempo de concretar las cosas.

El gran reto me ha surgido en mi parte individual. Me he encontrado con que JSP puede tener una asignatura entera y aun quedarían cosas que explicar, pero cuando lo proponemos, queremos hacer algo distinto a lo que estamos acostumbrados y probar cosas nuevas. Al querer ser autosuficiente para el desarrollo he aprendido que ante retos totalmente nuevos, necesito una breve explicación que me sirva de base.

Al intentar desarrollar una aplicación del tipo modelo-‐vista-‐controlador (MVC), forma idónea de trabajar JSP, necesito más tiempo que el planificado en un principio. Esto ralentiza el desarrollo de mi parte, teniendo que tomar como solución elaborar el portal como si de PHP se tratase.

En conclusión pienso que el resultado obtenido no se debe medir solo por el producto entregado, aunque normalmente sea la mejor forma de medirlo, sino por la forma de realizar el producto. El hecho de trabajar en equipo nos ha formado sobre ciertas cualidades nombradas antes, siendo mas valiosas por mi parte en la vida laboral. Dándole un valor añadido al trabajo por tener una forma mas real de realizar un producto.



36

3.2. El tiempo

Gracias a experiencias anteriores se ha realizado una previsión de tiempos más realista, dejando dos semanas de margen en la entrega. En realidad se supuso desde un primer momento que realizar un trabajo donde se desconocían partes de los lenguajes podría hacer que nuestro producto sufriese retrasos, y de ahí que se dejase un margen tan amplio.

Este retraso no lo llego a considerar un error, aunque hubiese sido un gran acierto el tener el producto terminado para la primera fecha establecida.

3.3. Futuras ampliaciones

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 ampliación de este proyecto sería su programación en modelo-‐vista-‐controlador (MVC), como por ejemplo Spring, para dejar de forma mas limpia los ficheros.

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.

BIBLIOGRAFÍA

37

4. BIBLIOGRAFÍA • John Freddy Vega & Christian Van Der Henst. Guía HTML5. El presente de la web.

Maestros del Web, 2011.

• Eric Freeman, Elisabeth Robson. Head First HTML5 Programming. Sebastopol (California) : O'Reilly, 2011

• Andrew Patzer. JSP : ejemplos prácticos. Madrid : Anaya Multimedia, 2002.

• Bryan Basham, Kathy Sierra, Bert Bates. Head first servlets & JSP. Sebastopol (California) : O'Reilly, 2004

ANEXOS 1. PERSISTENCIA ..................................................................................................................................... 1 1.1. TABLA USUARIO ...................................................................................................................................................... 1 1.2. TABLA PROYECTO .................................................................................................................................................. 1 1.3. TABLA PROY_COMPLETO .................................................................................................................................... 2 1.4. TABLA PROY_IDEA ................................................................................................................................................. 2 1.5. TABLA PROY_FRAGMENTO_CODIGO ............................................................................................................. 2 1.6. TABLA PROY_AYUDA ............................................................................................................................................. 2 1.7. TABLA COMENTARIO ............................................................................................................................................ 3 1.8. TABLA ETIQUETA ................................................................................................................................................... 3 1.9. TABLA IMAGEN ........................................................................................................................................................ 3 1.10.TABLA IMAGEN_PROYECTO ............................................................................................................................. 3 1.11.TABLA USUARIO_COMENTARIO .................................................................................................................... 4 1.12.TABLA USUARIO_PROYECTO ........................................................................................................................... 4 1.13.TABLA PROYECTO_COMENTARIO ................................................................................................................ 4 1.14.TABLA PROYECTO_ETIQUETA ........................................................................................................................ 4 2. PLAN DE PRUEBAS ............................................................................................................................. 5 2.1. PRUEBAS UNITARIAS ............................................................................................................................................ 5 2.2. PRUEBAS DE INTEGRACIÓN .............................................................................................................................. 5 3. ACTAS DE REUNIONES ...................................................................................................................... 7 3.1. REUNIÓN 1 ................................................................................................................................................................. 8 3.2. REUNIÓN 2 ................................................................................................................................................................. 9 3.3. REUNIÓN 3 .............................................................................................................................................................. 10 3.4. REUNIÓN 4 .............................................................................................................................................................. 11 3.5. REUNIÓN 5 .............................................................................................................................................................. 12 3.6. REUNIÓN 6 .............................................................................................................................................................. 13 3.7. REUNIÓN 7 .............................................................................................................................................................. 14 3.8. REUNIÓN 8 .............................................................................................................................................................. 15

ANEXO 1 – PERSISTENCIA

1

1. PERSISTENCIA Mostramos el modelo lógico realizado en el proyecto de Alejandro Sáez para entender mejor la base de datos del proyecto.

1.1. TABLA USUARIO

USUARIO Alias Clave Email AdminSI/NO Clave

El camp o 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/NO es un campo binario utilizado para saber si un usuario tiene privilegios de administrador o no. Modificable.

1.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.


2

1.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.

1.4. TABLA PROY_IDEA

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

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.

1.5. TABLA PROY_FRAGMENTO_CODIGO

PROY_FRAGMENTO_CODIGO IdProy EnlaceCódigo VerCódigo CE: Proyecto

EnlaceCódigo e s un enlace par a 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.

1.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


3

1.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.

1.8. TABLA ETIQUETA

Utilizada para almacenar las etiquetas que los usuarios crean.

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.

1.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.

1.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

ETIQUETA Nombre Contador Clave


4

1.11. TABLA USUARIO_COMENTARIO

Esta tabla relaciona a los usuarios con sus comentarios.

USUARIO_COMENTARIO Usuario Comentario CE: Usuario CE: Comentario

1.12. TABLA USUARIO_PROYECTO

Relaciona a los usuarios con los proyectos que suben.

USUARIO_PROYECTO Usuario Proyecto CE: Usuario CE: Proyecto

1.13. TABLA PROYECTO_COMENTARIO

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

PROYECTO_COMENTARIO Proyecto Comentario CE: Proyecto CE: Comentario

1.14. TABLA PROYECTO_ETIQUETA

Necesaria para emparejar etiquetas con sus proyectos.

PROYECTO_ETIQUETA Proyecto Etiqueta CE: Proyecto CE: Etiqueta

ANEXO 2 – PLAN DE PRUEBAS

5

2. PLAN DE PRUEBAS Como se explica en el apartado de diseño, se realizan pruebas unitarias y pruebas de integración.

Las pruebas unitarias se van realizando conforme se va implementando la aplicación, mientras que las de integración se realizan una vez las partes están construidas.

A priori, al tratarse de una aplicación realizada en equipo, donde por una parte se ha construido la lógica y la persistencia y por otro se ha diseñado y construido la capa de presentación se puede prever que las pruebas más costosas y con problemas serán las de integración. Por ello es imprescindible que cada una de las capas esté realizada con el mayor detalle posible y que las pruebas unitarias hayan sido realizadas con mucho detenimiento.

2.1. PRUEBAS UNITARIAS

Podría decir que estas pruebas son muy comunes ya que no en todos los navegadores la aplicación tenia la misma presencia, por lo que se abren tres navegadores simultáneos. Safari, Chrome y Firefox, son los navegadores usados para estas pruebas, no se utiliza Explorer debido a que la parte de presentación se desarrolla en un equipo con sistema operativo Macintosh. En ningún momento nos planteamos que la aplicación sea accesible desde un smarthphone o tablet.

Encuentro problemas para crear el efecto acordeón del menú, ya que es algo que pensábamos que podría ser visual. Empiezo buscando algún ejemplo javascript, pero tras perder casi tres días en algo tan nimio opto por desarrollarlo mediante css.

A la hora de generar el código JSP también me resulta difícil seguir la programación MVC de forma correcta. Siendo esto último lo que más tiempo me hace perder.

2.2. PRUEBAS DE INTEGRACIÓN

Estas pruebas se realizan en la recta final de la construcción, en el momento de unir las partes.

Se refieren a la prueba de todos los elementos unitarios que componen la aplicación en conjunto.

Para ello, una vez unidas las partes, se realizan diferentes pruebas:

• Se accede como un usuario común, como usuario registrado y como administrador. • Se crean proyectos de todo tipo, se eliminan y modifican. • Se dan de alta usuarios. • se realizan búsquedas y comentarios.

Los problemas encontrados en esta parte son escasos, en contra de lo que pensábamos inicialmente ya que se trataba de unir dos proyectos. Los fallos encontrados han sido en su mayoría muy leves, como por ejemplo errores al buscar la ruta del almacén de ficheros o imágenes.

También han aparecido errores debidos a la falta de entendimiento en alguna parte del análisis. El ejemplo más común ha sido el haber creado en persistencia un objeto de un tipo de dato y en la presentación esperarlo de otro tipo (la fecha en formato String o Date). Otro error

ANEXO 2 – PLAN DE PRUEBAS

6

más complicado pero solventado finalmente ha sido esperar en presentación la entrada de ficheros mediante el tipo File mientras que lógica y persistencia esperaban un String con la ruta para encargarse de procesarla.

Los errores aparecidos por culpa de un análisis imperfecto han sido los más complicados de reparar, aunque no han sido numerosos, lo que indica que el análisis fue bueno aunque no perfecto

ANEXO 3 – ACTAS DE REUNIONES

7

3. ACTAS DE REUNIONES A continuación se exponen las actas de las reuniones realizadas con el tutor:

En este documento se encuentran únicamente las actas de las reuniones que se han realizado de manera formal. No se ha levantado acta de las reuniones breves y prácticamente improvisadas como las visitas al despacho del tutor para la consulta de dudas.

Tampoco existen actas de las reuniones celebradas entre Alejandro Sáez y José Ignacio Martínez, numerosas al comenzar la aplicación y mucho menos frecuentes conforme avanzaba. Se trata de reuniones informales, semanales o cada dos semanas como se explica en el análisis y en la planificación, ya que hemos querido seguir de alguna manera la metodología Scrum.

En definitiva, se ha levantado acta de aquellas reuniones en las que se tomaron decisiones cruciales para el TFG.


8

3.1. REUNIÓN 1


9

3.2. REUNIÓN 2


10

3.3. REUNIÓN 3


11

3.4. REUNIÓN 4


12

3.5. REUNIÓN 5


13

3.6. REUNIÓN 6

Desarrollo de plataforma de colaboración entre ingenieros software

ACTA DE REUNIÓN Nº 6

Reunidos en el edificio Luis Vives, el día 29 de mayo de 2014, a las 10:00 horas, con la asistencia de Ángel Luis Rubio y José Ignacio se trató y acordó las siguientes cuestiones:

ORDEN DEL DÍA

1.- Demostración del desarrollo de la implementación. 2.- Preguntas.

DESARROLLO DE LA SESIÓN Y ACUERDOS ADOPTADOS

1.- Se realiza una demo con la presentación que defrauda al tutor ya que debiera estar más avanzada. 2.- Se pregunta al tutor sobre los plazos de presentación y entrega.


14

3.7. REUNIÓN 7



Reunidos en el edificio Luis Vives, el día 5 de Junio de 2014, a las 10:00 horas, con la asistencia de Ángel Luis Rubio, José Ignacio Martínez y Alejandro Sáez, se trató y acordó las siguientes cuestiones:

ORDEN DEL DÍA

1.- Prueba de la herramienta por parte del tutor. 2.- Comentarios del tutor sobre la aplicación. 3.- Pasos a seguir para el cierre del proyecto. 4.- Preguntas.


1.- El tutor prueba las partes funcionales de la aplicación, con moderado éxito ya que aún quedan bastantes partes por completar. 2.- Se acuerda con el tutor que ya no serán necesarias reuniones posteriores salvo que los alumnos lo soliciten, ya que no existen nuevos pasos que dar. 3.- El tutor expone los pasos a dar y los plazos para el cierre del proyecto y la entrega. 4.- No hay.


15

3.8. REUNIÓN 8



Reunidos en el edificio Luis Vives, el día 22 de junio de 2015, a las 18:00 horas, con la asistencia de Ángel Luis Rubio y José Ignacio se trató y acordó las siguientes cuestiones:

ORDEN DEL DÍA

1.- Comprobación de la memoria para su posterior impresión. 2.- Comentar el enfoque que se va a seguir en la presentación de la defensa. 3.- Preguntas.


1.- Tras la lectura el tutor comenta las faltas de ortografía a corregir. 2.- Al tutor le parece un planteamiento correcto el propuesto en la reunión.

Desarrollo de una plataforma de colaboración entre …José Ignacio Martínez Castillejo Angel Luis...

Documents

Transcript of Desarrollo de una plataforma de colaboración entre …José Ignacio Martínez Castillejo Angel Luis...