Iterable 4 (17/11/2014)

Asistentes

Propuesta de Integración

Tras la propuesta de creación de un repositorio común por parte de un miembro del grupo de otro subsistema, en concreto Autenticación, nuestra propuesta para integrarnos con los distintos subsistemas con los que estamos relacionados y de forma general para el resto, teniendo en cuenta los principios de integración de Martin Fowler es la siguiente:

• Mantener un único repositorio de código fuente → Se cumple ya que se utiliza el repositorio común, en el cual cada subsistema tiene una rama asignada en la que trabajar. Dicho repositorio se encuentra alojado en Git en la siguiente dirección: https://github.com/EGC-1415-Repositorio-compartido/repvoting
• Automatizar la construcción del proyecto → Debido al desconocimiento de las tecnologías usadas por otros subsistemas,no se cumple.
• Hacer que la construcción del proyecto ejecute sus propios tests → Cada subsistema realizará test unitarios para comprobar la correcta funcionalidad y detectar posibles errores.
• Entregar los cambios a la línea principal todos los días → No se cumple la realización de “commit” cada día, pero sí siempre que se añada una nueva funcionalidad válida o se realicen cambios.
• Construir la línea principal en la máquina de integración → En una máquina, ir haciendo los merge de manera secuencial, es decir, cada rama por separado. De esta forma en dicha máquina se irá probando cada combinación de las ramas hasta completar la construcción, que quedará alojada en la máquina.
• Mantener una ejecución rápida de la construcción del proyecto → Al haber distintas tecnologías, estimamos que la construcción de todos los subsistemas será de 45 minutos. Por tanto, no se considera rápida.
• Probar en una réplica del entorno de producción → Mediante una máquina virtual, se simulará en el entorno donde se hará uso de la aplicación Agora@US para hacer pruebas de rendimiento, fiabilidad y funcionalidad de la aplicación en un estado estable y “final”. Entendiendo como final que responde correctamente a la funcionalidad requerida a falta de pruebas en el entorno donde se usará.
• Hacer que todo el mundo pueda obtener el último ejecutable de forma fácil → No se cumple debido a la multitud de tecnologías distintas con las que está construido cada subsistema, no habrá un único ejecutable.
• Publicar qué está pasando → Se cumple ya que todos los desarrolladores tienen acceso a cada subsistema y puede ver fallos, comentarios de las subidas, etc, en definitiva, se tiene un estada actualizado del proyecto en general.
• Automatizar el despliegue → Cada subsistema generará scripts y artefactos de forma que para realizar la integración en los distintos entornos (desarrollo, pruebas y producción) se realice el despliegue de forma sencilla.

Entorno de integración

Cada subsistema deberá llevar lo necesario para que su proyecto arranque y permita integrarse con los otros subsistemas con los que esté relacionado. En nuestro caso, Creación/Administración de Censos, será necesario la base de datos MySQL 5.5, servidor Tomcat y IDE de desarrollo Eclipse..

Una vez se haya puesto todo en la máquina, la cual será la utilizada como máquina de integración (5º principio de Martin Fowler: Construir la línea principal en la máquina de integración), se procederá a integrar cada subsistema de forma ordenada y coherente. No se podrá integrar un nuevo subsistema hasta que el anterior no haya sido probado y comprobado el correcto funcionamiento.

Estética de la aplicación

Como cada grupo tendrá su estilo, podríamos votar el que más guste y adaptar todos los subsistemas a ese. En caso de que no se haya desarrollado ningún estilo, podrán votar igualmente para poder aplicarlo al suyo, de esta forma, los subsistemas no desentonarán.

Orden de integración para todos los grupos (general)

El orden de integración propuesto es, en nuestra opinión, según la complejidad de integración, dejando para el final los subsistemas que no requieren integración y en primer lugar el subsistema el cual necesita integrarse ó es integrado por una gran cantidad. Es decir, se intentará montar la base funcional de la aplicación como la autenticación, creación de votaciones y censos y por último se dejará la parte más visual. Con este orden se pretende dejar la aplicación tras la integración con una mínima funcionalidad.

1. Autenticación
2. Creación/Administración de censos
3. Creación/administración de votaciones
4. Cabina de votación
5. Almacenamiento de votos
6. Sistema de modificación de resultados
7. Verificación
8. Recuento
9. Frontend de Resultados
10. Visualización de resultados
11. Deliberaciones

Orden de integración para Creación/Administración de censos

1. Creación/administración de votaciones
2. Autenticación
3. Cabina de votación
4. Deliberaciones