Frontend y Visualización

Evolución y Gestión de la ConfiguraciónGrado de Ingeniería del Software

Número de grupo (Opera): 10 Tutor: David Benavides

Enlace de proyecto en projETSII: https://projetsii.informatica.us.es/projects/t6xqetftwntyzke2yd4

Enlace wiki:https://1984.lsi.us.es/wiki-egc/index.php/Frontend_y_visualizaci%C3%B3n_de_resultados

1

Integrantes del equipo:

Barquero Sauci, Valentín (valentinbarquero@gmail.com)Bellido Millán, Miguel A. (migbelmil@alum.us.es)Llamas García, Moisés (moillagar@alum.us.es)Martín Rodrigo, Daniel (danmarrod@alum.us.es)Sánchez Navarro, Daniel (dansannavl@alum.us.es)

AUTOEVALUACIÓN

Dedicación en el proyecto en cada uno de los entregables.

Alumno Entregable 1 Entregable 2 Final

Barquero Sauci, Valentín

Bellido Millán, Miguel A.

Llamas García, Moisés

Martín Rodrigo, Daniel

Sánchez Navarro, Daniel

0% = No he podido participar y por tanto debo aceptar tener un cero en el entregable.

50% = He trabajado aproximadamente la mitad que mis compañeros y por tanto merezco la mitad de la nota del trabajo.

100% = He trabajado como el que más y merezco la nota dada al trabajo.

HISTORIAL DE VERSIONES

2

Fecha Versión Detalles Participantes

27/11/2015 1.0 Versión inicial Daniel Martín Rodrigo

16/12/2015 1.1 Realizados la introducción, resumen y gestión del código fuente

Moisés Llamas García

Índice General3

1 Resumen.................................................................................................................. 5

2 Introducción.............................................................................................................5

3 Diario de grupo........................................................................................................5

3.1 Lorem................................................................................................................5

3.2 Ipsum.................................................................................................................5

4 Relación de Hitos.....................................................................................................6

5 Descripción del sistema...........................................................................................6

5.1 Descripción General..........................................................................................7

5.2 Descripción Técnica...........................................................................................7

5.3 Planificación......................................................................................................7

6 Elementos de Control..............................................................................................7

7 Entorno de Desarrollo..............................................................................................7

8 Gestión del código fuente........................................................................................7

9 Gestión de la construcción e integración continua.................................................8

10 Gestión del cambio, incidencias y depuración........................................................8

11 Gestión de liberaciones, despliegue y entregas......................................................8

12 Gestión de la variabilidad........................................................................................8

13 Mapa de herramientas............................................................................................8

14 Conclusiones............................................................................................................8

Referencias......................................................................................................................9

Índice de Tablas4

Tabla 1: Relación de Hitos..............................................................................................10

Índice de FigurasIlustración 1: Arquitectura de Agora@US........................................................................7Ilustración 2: Estructura Organizativa..............................................................................9

5

1 Resumen

6

En el presente docoumento se detalla toda la información acerca del subsitema Frontend y Visualización de resultados. Dicho subsistema pertenece al proyecto Agora@US, aplicación que ofrece un servicio de votaciones de forma segura online.

Este subsistema se realizará con la finalidad de aprender a trabajar en grupo y llevar una gestion de la configuracion del proyecto mencionado anteriormente, que se llevará a cabo dentro de la asignatura Evolución y Gestión de la Configuración, incluida en la titulacion de Grado de Ingeniería del Software.

El sistema Agora@us es un proyecto que se divide en varios subsitemas, de forma que tanto el desarrollo como la gestión del código se realiza de forma independiente en cada subsitema. En nuestro caso, el subsistema a desarrollar es el de Frontend y Visualización de resultados, cuyo objetivo es comunicarse con los subsistemas de Recuento y Moodificación de Resultados, para procesar los datos y posteriormente, visualizarlos para informar al usuario de los resultados de las votaciones.

Las herraminetas usadas para el trabajo son las siguientes:

o Gestión del proyecto: Projetsii.o Gestión de la construcción: Maven, usado para la compilación.o Gestión del código fuente: Git, repositorio de codigo que ofrece un servicio

de control de versiones y centralización del código. o Gestion de despliegue: Openshift, usado para desplegar la aplicación.o Gestión de la calidad: Google CodePro Analytic, herramienta gratuita

ofrecida por Google para mejorar la calidad del software.

7

2 IntroducciónEn esta sección se presenta la arquitectura que tiene el proyecto Agora@US y a continuación, se describe el funcionamiento del subsistema Frontend y Visualización de resultados y de los subsistemas de los que depende.

2.1 Qué es Agora@USPara aprender a realizar la evolución y gestión de un código, se decidió usar

Agora@US, proyecto que surge como ejemplo para aprender la integración entre los subsistemas que forman esta aplicación.

Para el presente curso, cada subsistema debe de obtener el código realizado en el curso 2014/2015, evolucionarlo añadiendo nuevas funcionalidades y/o detectando y corrigiendo errores, integrando finalmente todos los subsistemas obteniendo de nuevo el mismo proyecto realizado en el curso 2014/2015, pero con nuevas funcionalidades y reduciendo los errores a nivel de codificación que se produjeron en el año pasado.

A continuación se muestran los subsistemas que se acordaron el pasado año y a los cuales, la clase debía de adaptarse:

Ilustración 1: Arquitectura de Agora@US

8

2.2 Frontend y Visualización de resultados

Nuestro grupo es el encargado de desarrollar el subsitema de Frontend y Visualización de resultados, cuyo propósito es recibir los recuentos de los votos de las distintas votaciones o referéndums para almacenarlos en una base de datos propia y posteriormente visualizarlos en forma de gráficas, para que el usuario de manera rápida e intuitiva pueda comprobar los resultados de las votaciones.

El recuento de votos (mencionado anteriormente) es realizado por los subsistemas de Modificación de resultados y Recuento de Votos, que se coordinan entre ellos para ofrecer la información adecuada a traves del subsitema de Recuento de Votos.

Desde principios del proyecto, nuestro grupo llegó al acuerdo con el grupo de Recuento de Votos de que la comunicación entre los dos subsitemas sería a traves del uso de API REST, por lo que los datros sería enviados como un JSON con formatos distintos, dependiendo de la API en cuestión.

2.3 Tecnología

Referente a las tecnologías, nos encontrabamos que el código heredado correspondiente a los subsistemas que nuestro grupo debía de desarrollar era diferente. Por un lado, el subsitema de Frontend de Resultados utilizaba el framework Spring e Hibernate mientras que el subsitema de Visualización de Resultados había desarrollado su proyecto usando HTML y JavaScript.

Por tanto, la primera decisión que debe de tomar el grupo es como desarrollar el proyecto que se nos planteaba. Había tres opciones:

Evolucionar el código de ambos subsistemas usando los frameworks usados en el anterior curso.

Migrar el código del subsistema de Frontend de Resultados al framework de Visualización de Resultados.

Migrar el código del subsistema de Visualización de Resultados al framework de Frontend de Resultados.

La primera opcion rapidamente fue descartada, ya que aunque es una opción viable, no estimamos que fuera la mejor opción, puesto que debíamos de integrarnos entre nosotros mismo, además que con el resto de subsistemas. Por tanto, la cuestión era hacia que framewok realizamos la migración.

Finalemente, se realizó la migración del código del subsistema de Visualización de Resultados al framework Spring e Hibernate.

9

10

3 Diario de grupo(Incluirlo en documento aparte)

3.1 LoremLorem ipsum dolor sit amet, consectetuer adipiscing elit. Maecenas porttitor congue massa. Fusce posuere, magna sed pulvinar ultricies, purus lectus malesuada libero, sit amet commodo magna eros quis urna.

Nunc viverra imperdiet enim. Fusce est. Vivamus a tellus.

3.2 IpsumPellentesque habitant morbi tristique senectus et netus et malesuada fames ac turpis egestas. Proin pharetra nonummy pede. Mauris et orci.

Aenean nec lorem. In porttitor. Donec laoreet nonummy augue.

Suspendisse dui purus, scelerisque at, vulputate vitae, pretium mattis, nunc. Mauris eget neque at sem venenatis eleifend. Ut nonummy.

Ilustración 2: Estructura Organizativa

4 Relación de Hitos

Fecha Nombre

11

Equipo 10

P.Manager 5

P.Manager 4

P.Manager 3

P.Manager 2

P.Manager 1

23 de Noviembre 2015 Revisión 01

02 de Diciembre 2015 Revisión 02

09 de Diciembre 2015 Revisión 03

14 de Diciembre 2015 Revisión 04

07 de Enero 2016 2015 Revisión 05

Tabla 1: Relación de Hitos

5 Descripción del sistemaSe explicará el sistema desarrollado desde un punto de vista funcional. Se hará una descripción tanto descriptiva como técnica de sus componentes y su relación con el resto de subsistemas. Habrá una sección que enumere explícitamente cuáles son los cambios que se han desarrollado para el proyecto. En otra sección se presentará la planificación del trabajo y qué tareas se han hecho. Haciendo hincapié en el reparto de tareas. Tenga muy en cuenta lo expresado en la sección 2.2.2 en cuánto a división de tareas.

5.1 Descripción General

5.2 Descripción Técnica

5.3 PlanificaciónPlanificación y Tareas. Hacer hincapié en el reparto de tareas y tener en cuenta el siguiente punto:

“Todos los componentes del equipo deben ser desarrolladores en el proyecto. No se puede dividir el equipo para que unos hagan desarrollo y otros hagan documentación por ejemplo. Para poder poner en práctica los conocimientos debe todo el mundo ser desarrollador/a y trabajar en paralelo. Se podrá cargar más en una persona u otra la parte de desarrollo pero en ningún caso se podrá quitar a alguien de esta labor”.

6 Elementos de ControlSe enumerarán cuáles son los elementos que estarán bajo gestión de la configuración y cómo se va a gestionar la configuración de cada uno de ellos. Es decir, se explicitará la primera tarea de identificación de los Configuration Items (CI) que definan la base line.

12

Ilustración 4:Java

Ilustración 3: VirtualBox

7 Entorno de DesarrolloA continuación, se detallan el entorno que hemos usado, además de otras

herramientas complementarias al entorno de desarrollo. Es importante prestar atención a las versiones instaladas, pues de lo contrario, no se puede asegurar el correcto funcionamiento de la aplicación.

7.1 Máquina VirtualEl equipo de desarrollo ha querido simular al máximo el entorno de desarrollo

que se encontrará en una empresa profesional. Es por ello que todo el trabajo ha sido desarrollado en una máquina virtual. Esto tiene una serie de ventajas, como que no desperdiciamos los recursos de nuestra máquina física. En cualquier momento, si necesitamos asignarle más recurso para la realización del proyecto, podremos asignárselos.

La máquina virtual usada para este proyecto ha sido VirtualBox, en la que debemos de instalar la versión 4.2 o superior. Podemos descargarnos esta máquina virtual desde su página oficial (https://www.virtualbox.org/wiki/Downloads).

7.2 JavaNecesitamos de un compilador Java. Para ello, vamos a usar JDK en su versión 1.7, el cual lo podemos encontrar en la siguiente página (http://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html?ssSourceSiteId=otnes)

13

Ilustración 6: Importando Maven

7.3 EclipseDebido a la gran familiarización de todos los desarrolladores con el entorno de desarrollo Eclipse, se ha decidido usar Eclipse, en su versión Eclipse Indigo. Lo podemos encontrar para descargárnoslo desde su página oficial (https://www.eclipse.org/downloads/)

Ilustración 5: Eclipse

7.4 MavenEsta herramienta es usada para la construcción de nuestro proyecto, en el cual

se encontrarán todas las dependencias que son necesarias para el desarrollo de éste. Maven lo podemos integrar con nuestro entorno de desarrollo mediante un plugin que se encuentra dentro del Marketplace de eclipse. Los pasos para instalar y configurar este plugin son los siguientes:

1. Debemos de dirigirnos a la página oficial de Maven (https://maven.apache.org/download.cgi) y descargarnos su última versión. Una vez descargado, debemos de descomprimir el paquete en el lugar que consideremos más adecuado.

2. Desde eclipse, debemos acceder al menú “Windows>Preference”, escribimos “maven” y seleccionamos en el submenú que nos aparece “Installation”. Nos mostrará la versión de maven que instalamos en el paso anterior. Debemos de seleccionar la versión de maven que descargamos en el paso anterior.

14

Ilustración 6: Importando Maven

Como podemos ver, se nos ha seleccionado el archivo setting.xml. Este archivo contiene la configuración global del entorno. En el siguiente paso veremos cómo configurar nuestro propio setting.xml

3. En el mismo submenú, debemos de seleccionar el apartado “User Setting”, para configurar el arhivo setting.xml con la configuración que deseemos.

Ilustración 7: Configuración del archivo setting.xml

4. Configuración del archivo pom.xml. Este archivo será el que contenga todas las dependencias que necesitemos para desarrollar el proyecto. Para ello, basta con ver el repositoriode maven (http://repo1.maven.org/maven2/) y ver qué dependencias tiene y añadir las dependencias de la forma: <dependency>

<groupID>…..</ groupID ><artefactID>….</artefactID><version>…</version><scope>….</scope>

</dependency>Nota: el scope puede ser compile, test o runtime, dependiendo de en qué fase queremos tener disponible la dependencia.

Ilustración 8: Maven

15

7.5 EGitEGit es un plugin, que podemos encontrar en el Marketplace de eclipse y sirve

para poder usar el repositorio de git, dentro del IDE eclipse, sin tener que usar la consola.

Para instalar esta herramienta, debemos de seguir lo siguientes pasos:

1. En el menú de eclipse, debemos de seleccionar “Help> Install New Software” y en buscador poner http://dowload.eclipse.org/egit/updates-2.3#sthash.Dv02tyGo0dpuf y seleccionar “Eclipse Git Tem Provider” y as continuación, seleccionamos “Next”

Ilustración 9: Instalación EGit

2. Una vez que tenemos descargado el plugin, debemos de conectarnos a nuestro repositorio de nuestra cuenta de git, para realizar nuestro primer “git clone” y poder empezar a trabajar en nuestro repositorio local. 2.1 Colocar la vista de git en nuestro entorno de desarrollo. Para ello, en el

menú, seleccionamos “Windows>Show View” y seleccionamos Git Repositories

16

Ilustración 10: Añadir vista de Git

2.2 Añadir un repositorio existente en Git. Para realizar este paso tendremos que realizar:- Añadir la URL de nuestro repositorio de Github- Añadir el correo y la contraseña de nuestro usuario de Github

Ilustración 11: Clonando un repositorio existente

17

7.6 MySQLPara almacenar los datos de las encuestas que son recibidos por el subsistema de

recuento, el equipo de desarrollo ha decidido usar una base de datos conocida, como es MySQL, en su versión 5.5. La podemos descargar en el siguiente enlace: (https://dev.mysql.com/downloads/windows/installer/5.5.html)

Para configurar la base de datos solo debemos de crear una instancia, a la que llamaremos localhost y crear una cuenta de administrador cuyas credenciales son:

- Usuario: root- Contraseña: V3rY=$tR0nG=P@$$w0rd$

Una vez que tenemos nuestra cuanta de administrador, el siguiente es un script para crear la base de datos. El script es el siguiente:

Ilustración 12: Creación de base de datos

Una vez que la base de datos ha sido creada, en el panel donde se encuentran las bases de datos podremos ver como se ha creado una nueva con el nombre “egc-frontend”.

Ilustración 13: MySQL

18

7.7 TomcatTomcat es un servidor de aplicaciones. Está muy bien integrado con eclipse, es por ello por lo que el equipo de desarrollo estimó oportuno usar este servidor. La versión que vamos a usar es la 7.0 y la podemos descargar desde el siguiente enlace (https://tomcat.apache.org/download-70.cgi). Los pasos para la instalación es la siguiente:

1. Buscar el servidor tomcat (previamente descargado y descomprimido en la carpetas elegida). Para ello, debemos de dirigirnos a Windows>preferences>servers>runtime enviroments:

Ilustración 14: Configuración Tomcat

19

2. Hacemos click en “add” y seleccionamos “Apache Tomcat v7.0” y pulsamos el botón “next”, en lo que tendremos que seleccionar la carpeta donde instalamos tomcat en el paso 1 y luego pulsaremos el botón “finish”

Ilustración 15: Configuración Tomcat II

3. Cuando tenemos el servidor iniciado, debemos de comprobar que el puerto usado es el correcto. Para ello, hacemos doble click en “Tomcat v7.0 Server” en la vista de servidores y seleccionamos el puerto como 8080 que es el que utiliza por defecto.

Ilustración 16: Apache Tomcat

20

8 Gestión del código fuente

A la hora de gestionar el código fuente, existen varias herramientas gratuitas que pueden ser de gran utilidad. Primero, lo más importante sería elegir una herramienta en la cual, podamos crear tareas, asignarles un recurso y además, tener un espacio común de comunicación entre los integrantes del equipo.

8.1 Gestores de proyectos Projetsii: es una herramienta online, con la que el equipo se encuentra muy

familiarizado, debido al uso de la herramienta a lo largo de la carrera. Esta herramienta puede ser de gran ayuda a la hora de gestionar los recursos necesarios para este proyecto, y además, gestionar y planificar las tareas, crear diagramas de Gantt, foros, repositorio de código…

GitHub: es una herramienta en la que el grupo no está muy familiarizado, aunque si se conoce las funciones básicas como gestionar tareas del proyecto, uso de su wiki, un gestor de incidencias y un repositorio de código.

El equipo estimó que la planificación es una de las fases más importantes a la hora de abordar un proyecto software como este, por lo que sería necesario usar cuantas herramientas sean oportunas para una mejor planificación. Por consiguiente, se usó projetsii para la creación y asignación de tareas y también se usaría github para gestionar las incidencias, pues usaremos su repositorio de código para alojar el código del proyecto, y se consideró más cómodo usar dicho gestor de incidencias.

8.2 Gestión del códigoComo se mencionó en el apartado anterior, para la gestión del código el equipo

decidió utilizar la herramienta Git, herramienta muy potente, la cual se integra perfectamente con nuestro entorno de desarrollo, en este caso eclipse.

Tras varias sesiones prácticas llevadas a cabo en la asignatura de Evolución y Gestión de la Configuración, rápidamente el equipo se dio cuenta que trabajar directamente sobre la rama master no era lo más recomendable, si no que debían de crearse ramas, en función de la funcionalidad que se fuera a desarrollar en ese momento y mantener en la rama master siempre una versión estable del proyecto.

En primer lugar, en el repositorio se encuentra la rama “Master”. En ella, siempre se mantiene una versión estable del proyecto, por si en alguna ocasión, se pide algún entregable que no esté provisto en el grupo.

Se creará una rama a partir de la rama “Master” y nunca sobre una rama que no sea esta. En esta nueva rama se experimentará nuevas funcionalidades propuestas para el proyecto o la integración de nuevas bibliotecas que supongan un cambio importante sobre la arquitectura de la aplicación.

21

Para la unión de ramas, se realizará cuando la rama sobre la que se está investigando este integrada la nueva funcionalidad y/o nueva librería y este cambio no puede afectar a la funcionalidad del proyecto.

A continuación, con el objetivo de explicar de forma gráfica para aclarar posibles dudas, se adjunta una imagen, representando lo antes mencionado sobre el proceso de creación y/o unión de ramas.

Ilustración 17: Creación de ramas

8.3 Procedimientos para trabajar con el control de versiones

8.3.1 Pautas para realizar un commitSe decidió de crear un procedimiento común a la hora de realizar los commits, de

forma que se estableció un convenio entre los integrantes del grupo a fin de que al leer el título y descripción de un commit que sea de otro miembro del equipo, fuese lo más claro posible. Los pasos a seguir son los siguientes:

1. Título del commit. Este debe de empezar por una palabra clave en mayúsculas que hará referencia al tipo de cambio que se trata:

i. ADICIÓN[título del commit]ii. CORRECCIÓN[título del commit]iii. APIGET[título del commit]iv. PERSISTENCIA[título del commit]v. CONFIGURACIÓN[título del commit]vi. DESPLIEGUE[título del commit]

2. Una vez especificado el tipo de cambio, en la parte de [título del commit] se expondrá con un poco más de detalle el cambio lógico que supone dicho commit, sin superar los 80 caracteres.

3. Por último, se añadirá una descripción detallada que responda al porqué del cambio y que explique en qué consiste.

22

8.3.2 Pautas a la hora de crear una incidenciaSe decidió un procedimiento común para todos los integrantes del grupo, a fin

de detallar lo máximo posible una incidencia para que no dé lugar a confusiones por parte de los demás usuarios. Los pasos a seguir son los siguientes:

1. Indicar los pasos a seguir para reproducir el problema.2. Una vez llegado a donde se produce el error, indicar que error se

devuelve3. Explicar con el máximo detalle posible cual es el resultado esperado.4. Indicar la versión del software utilizado de desarrollo y sistema

operativo.

8.3.3 Gestión de conflictosA la hora de gestionar los conflictos que Git no puede resolver de manera

automática, se definió un procedimiento a seguir, para minimizar en la manera de lo posible. Al ser un equipo con una cantidad considerable de personas trabajable, es inevitable que aparezcan futuros conflictos en el código que se deba de solucionar de manera manual.

En primer lugar, se definió un procedimiento para la interacción con el repositorio:

1. git clone. Esto se realizaría solo la primera vez, para obtener en local el código que hubiera en el repositorio.

2. Modificar los ficheros oportunos.3. git pull para actualizar la versión en local.4. git add con los ficheros quye se quiern incluir en el commit.5. git commit. Esto se realizaría utilizando el procedimiento previamente definido

(ver pautas para realizar un commit).6. git push, de la rama sobre la que se esté trabajando.

Tras definir estos pasos a seguir, se tomaron otras medidas con herramientas que faciliten la comunicación entre los integrantes. Para ello, se usó la aplicación web Slack, ya que unifica varios servicios que no oferce otras herramientas y es usado por la mayoría de las empresas para su comunicación interna (para más información, visitar https://slack.com/).

Como último recurso, se acordó que si seguidos estos pasos se produce algún conflicto, el desarrollador al que le aparezca dicho conflicto será el encargado de resolverlo.

8.4 RolesDurante el desarrollo del trabajo, podemos diferenciar los siguientes roles:

Coordinador: persona con capacidad para tomar decisiones sobre todos los miembros del equipo, encargado de la comunicación con el resto de coordinadores de los demás subsistemas y de solucionar los conflictos entre los miembros del grupo en caso de que existiesen).

23

Desarrollador: persona de realizar el código fuente que le han sido asignadas, tomando las decisiones de cuando crear una rama, cuando hacer merge, push, etc.Todos los integrantes tienen el rol de desarrollador, incluso el coordinador.

8.5 Sintaxis del código fuentePara la sintaxis del código fuente hemos usando la aprendida a lo largo de la titulación de Ingeniería Informática-Ingeniería del Software.

“En este apartado se detalla la política que se ha seguido a la hora de escribir el código fuente, con el fin de homogeneizar la sintaxis utilizada.

En primer lugar, los nombres de todas las clases empiezan por mayúscula, y en caso de tener más de una palabra, cada una de las que siguen a la primera también empezarán con mayúsculas.

Por otro lado, los servicios y los repositorios relacionados con las entidades del dominio se denominarán siguiendo el esquema NombreEntidadService yu NombreEntidadRepository respectivamente.

En lo que respecta a los métodos de cada clase, éstos comienzan con minúscula, pero en el caso de que tengan más de una palabra, de la segunda en adelante comienzan con mayúscula.

Por último, para la estructura general del código se ha seguido el esquema de programación indentada usando tabulaciones.”1

1 Para la sintaxis del codigo fuente, esta se ha recogido de la documentación del grupo Frontend de Resultados del curso 2014-2015

8.6 Ejercicio8.6.1 Enunciado

Tras realizar la integración de los subsistemas y se establece en la rama “Master” un versión estable de dicho proyecto. Se desea añadir una nueva funcionalidad al sistema heredado. La nueva funcionalidad consiste en permitir a los usuarios realizar donaciones a la aplicación Agora@US mediante la plataforma de pagos seguros Paypal.

En primer lugar, se debe crear una nueva rama sobre la rama Master, que se denominará “DevelopmentPaypal”. Una vez que la rama está creada, debemos de trabajar sobre dicha rama durante el desarrollo y finalmente, cuando la nueva

24

funcionalidad este completamente desarrollada, unir la rama “DevelopmentPaypal” a la rama Master.

8.6.2 Solución

Creación de la nueva rama “DevelopmentPaypal”o $ git branch DevelopmentPaypal

Cambio a la rama “DevelopmentPaypal”o $ git checkout DevelopmentPaypal

Enviar rama al servidoro $ git push origin DevelopmentPaypal

Commit de los cambios realizadoso $ git commit –a

Enviar cambios realizados a la copia del servidoro $ git push

Cambios a la rama “Master”o $ git checkout DevelopmentPaypal

Inserción de la nueva característica a la rama “Master”o $ git merge DevelopmentPaypal

9 Gestión de la construcción e integración continua

Similar al apartado anterior se definirán los procesos que se usan a la hora de construir el proyecto, ¿qué herramientas se usan? ¿Cómo se usan? ¿Cada cuánto tiempo se realiza una construcción del proyecto? ¿Qué mecanismos IC se usan? ¿Cómo?, etcétera.

25

10 Gestión del cambio, incidencias y depuración

Dado el tipo de proyecto que se va a abordar, evolucionar un código heredado a une versión en la que incluya nuevas funcionalidades, el cambio es un hecho de que va a ocurrir. Además, al ser un proyecto en el que está dividido en varios subsistemas el cual, deben de integrarse, todo ello es sinónimo que en el futuro surgirán problemas

Por todo ello, es importante mantener definido una serie de pautas para realizar un cambio o como crear una incidencia y tener procedimientos de depuración para conseguir un código lo más correcto posible.

10.1 Gestión del cambioEn el presente documento, procedimos a explicar de forma breve como se

procedería en el caso que fuera necesario. En concreto, se hizo referencia al procedimiento para crear una rama (ver procedimiento).

Por otro lado, en la herramienta usada para la gestión del proyecto (projetsii), el desarrollador correspondiente deberá de asignarse la tarea correspondiente a la que vaya a realizar, que podrá ser, realizar una nueva funcionalidad (siguiendo los pasos de creación de ramas descritos anteriormente) o realizar una parte de la documentación, la cual deberá de explicar en la tarea el tiempo dedicado y en que versión de la documentación se realizó.

10.2 Gestión de incidenciasEs importante definir una serie de pautas a la hora de realizar una incidencia.

Esta es vista por todos los miembros del equipo, incluso por los miembros que están desarrollando otro subsistema. Para ello, con anterioridad se definió una pautas a seguir a la hora de crear una incidencia (ver pautas).

Las incidencias son creadas mediante la herramienta GitHub, en la opción “issues”, opción muy útil ya que al crear la incidencia, se envía una notificación al correo electrónico de todos los miembros que estén en dicho repositorio.

26

Ilustración 18: Creación de incidencia

Una vez que una incidencia ha sido resuelta, debe de cerrarse, quedando registrada en un historial de incidencias, que puede ser consultado por cualquier miembro del equipo, para posibles aclaraciones de futuras incidencias. A continuación se muestra una imagen del historial de incidencias, la cual podemos ver que podemos aplicar diversos tipos de filtros, que será de gran utilidad a la hora de listar cierpos tipos de incidencias.

Ilustración 19: Historial de incidencias

10.3 Gestión de depuraciónCuando existe una incidencia, es necesario solucionarla con la mayor brevedad

posible. Para tener claro que hay que hacer, es necesario definir un proceso para que cualquier persona, sin conocer el código que intenta corregir el error pueda resolverlo.

El primer paso es identificar la incidencia y cual es el motivo por el que se está produciendo. Para ello, es necesario reproducir los pasos descritos en la incidencia, para llegar al error.

Dado que el error puede ser de dos motivos, existen dos procedimientos a seguir:

1. Si el error es de ejecución, el procedimiento sería el estudio de la traza de errores mostrada, con el fin de reconocer el origen del fallo.

27

2. Si el error es de tipo lógico, se usará el depurador de Java, mediante puntos de ruptura.

Una vez que el error se ha corregido, debe de realizarse diferentes pruebas de modo que se pueda asegurar que el error ha sido corregido completamente.

10.4 Ejercicios10.4.1 Ejercicio 110.4.1.1 Enunciado

Se tiene una versión totalmente funcional de la aplicación, y se quiere que esta esté desplegada en Internet. Esta tarea es asignada a un desarrollador, que tras varios intentos, crea una incidencia debido a que obtiene un error que no tiene la capacidad de solucionar. Otro desarrollador, lee la incidencia y decide ayudarle con su error, hasta que consigue solucionarlo y que finalmente, la aplicación quede desplegada en Internet.

10.4.1.2 Solución El primer desarrollador, tras varios intentos, es incapaz de solucionar la tarea

que se le fue asignada, por lo que decide crear una incidencia.

Ilustración 20: Creación de incidencia

Otro desarrollador, al ver la notificación en su correo electrónico decide ver todas las incidencias que hay para poder ayudar a este desarrollador. Tras estudiar la traza arrojada, finalmente identifica el error, corrigiéndolo y finalmente, reportando como ha solucionado el error, cerrando la incidencia.

Ilustración 21: Cerrar incidencia

28

10.4.2 Ejercicio 210.4.2.1 Enunciado

Se desea añadir una nueva funcionalidad a la aplicación. Esta funcionalidad es usar la librería AngularJS, para mejorar de esta forma el HTML.

10.4.2.2 SoluciónEn primer lugar, es el coordinador del grupo quien decide si se lleva a cabo la

incorporación de la nueva funcionalidad, analizando el impacto que tendría el proyecto, analizando los posibles riesgos que puedan surgir, llegando finalmente a la conclusión si se hace o no.

Si el coordinador opta por añadir la nueva funcionalidad, este deberá de crear la tarea y/o subtareas correspondientes para la realización de dicha funcionalidad, asignándole a dicha tareas los recursos que él estime necesarios.

El desarrollador al que le has sido asignada la tarea, deberá de crear una rama correspondiente, uniéndola finalmente cuando la tarea asignada esté desarrollada completamente.

29

11 Gestión de liberaciones, despliegue y entregas

¿Qué elementos del proyecto son “entregables”? ¿Cómo se generan? ¿Cómo se identifican? ¿Cómo se gestiona la publicación, la liberación y entrega? ¿Dónde se entrega? ¿Qué roles existen en la entrega? ¿Qué mecanismos de despliegue se definen? ¿Qué procesos? ¿Qué plataformas? ¿Qué herramientas?

12 Gestión de la variabilidad¿Qué mecanismos se usan? ¿Qué mecanismos se podrían usar? ¿En qué niveles se gestiona la variabilidad?

13 Mapa de herramientasDebe dar un esquema de cómo se conectan las herramientas que se usan en el proyecto, qué relaciones tienen o qué relaciones propondría añadir. No olvide explicar bien el mapa de herramientas. Se trata del mapa de herramientas de gestión de la configuración. El mapa de herramientas que se usen para el desarrollo (como bases de datos u otros) no es necesario que aparezca aquí.

14 ConclusionesEnunciar conclusiones en 2 o 3 párrafos y no más de una página.

Referencias

[1] Wiki EGC. https://1984.lsi.us.es/wiki-egc/index.php/2015/2016

[2] J. Webber, S. Parastatidis y I. Robinson. REST in Practice: Hypermedia and Systems Architecture. O'Reilly Media. 2010.

30