- Jefe de Proyecto/Scrum Master/Arquitecto Software
- Es el interlocutor válido con el profesor, que actuará como gerente del proyecto y origen de los requisitos de usuario.
- Diseña la arquitectura de los componentes, servidores de
aplicación, bases de datos, y de todos los sistemas software que
intervengan en el despliegue de la aplicación para ponerla en
funcionamiento.
- Coordinación del proyecto, planificación ágil, asignación de tareas, gestión de la Wiki.
- Planifica, controla y organiza el trabajo.
- Analista/Ingeniero de Requisitos
- Análisis de requisitos y diseño, casos de uso, diagramas de robustez, diagramas de secuencia
- Administrador de sistemas:
- Instala y configura los entornos de desarrollo, servidores y
sistemas software de los que depende la aplicación (base de datos,
servidor web, servidor de aplicaciones, sistema de control de versiones,
etc.)
- Analiza, diseña y mantiene el esquema de base de datos de la
aplicación; ayuda en la codificación de las clases de entidad que tengan
que ver con el acceso a la base de datos
- Diseñador de interfaz de usuario
- Gurú balsamiq, maquetación CSS, gestión interfaces
- Analiza, diseña y codifica la interfaz de usuario (clases de vista) en HTML y JavaScript.
- Codificador de pruebas
- Planifica, codifica y configura la ejecución de casos de prueba unitarias, funcionales y de integración.
- Analista/Programador
- Codifica los componentes de software; programa las clases en Groovy
- Implementación MVC Grails/Groovy, gestión de plugins
| Participante
| Rol
|
| Carlos M. Cornejo Crespo
| Jefe de Proyecto/Scrum Master/Arquitecto Software
|
| Antonio Falcón Aragón
| Analista/Ingeniero de Requisitos
|
| Antonio Fco. Martín Romero
| Administrador de sistemas
|
| Jose Luis Falcón Ramírez
| Diseñador de interfaz de usuario/Integración con la Vista
|
| Antonio Fco. Martín Romero
| Codificador de pruebas
|
| Carlos Villegas Núñez
| Analista/Programador/Gurú GRails
|
Entregable 1 - Planificación y configuración
En cada sprint el trabajo del equipo de desarrollo se va a organizar
en un conjunto de tareas, que identificarán cada unas de las
funcionalides a implementar. A continuación se definen:
ScrumMaster - Gestiona la planificación de tareas y asume
responsabilidades de estudio/integración con plugins/funcionalidades que
surgen de otras tareas. Gestión de documentación.
- Planificar tareas
- Documentación/Entregables
Análisis - Identifica necesidades UML en el análisis y dirige el modelado guaido por casos de uso
- Casos de Uso
- Diagramas de Robustez
- Diagramas de Secuencia
Integración con la Vista
- Maquetación Balsamiq
- Integración HTML/GSP
- Estudio de taglibs y layout SiteMesh
- Maquetación CSS
Implementación - Da cuerpo al diseño con Grails, generando las estructuras de datos necesarias en cliente y lógica de negocio.
- Domain/Controller/Services/Hibernate mapping
Pruebas - Recopila todas la pruebas software aplicables al proyecto.
- Pruebas Unitarias.
- Pruebas Integración.
- Pruebas Funcionales.
Capa de acceso a BD - Da soporte a la capa de acceso a datos con MySQL. Genera scripts de startup y actualiza la BD.
- Scripts actualización del DDL/DML/DCL
- Creación startup bash.
Reuniones
Reunión del día 19/04/2011
Contexto:
Videoconferencia con skype y duración 1.5h.
Participantes:
- José Luis Falcón Ramírez
- Antonio Falcón Aragón
- Carlos M. Cornejo Crespo
- Antonio Fco. Martín Romero
- Carlos Villegas Núñez
Temas tratados:
Hemos repasado el conjunto de tareas que nos hemos asignado.
Hemos solucionado algunas dudadas referentes al uso de los tickets y
funcionamiento de assembla.
Hemos decido subir los fuentes de:
También hemos comentado la necesidad de subir las capturas en png de
los casos de uso, maquetaciones y robustez que se añadirán a la wiki.
Hemos configurado el plug-in Subversive SVN Connectors del IDE Eclipse.
Instalación del plugin de authentication
Reunión 11/05/2011
Contexto:
Reunión informal en clase durante 30 mins.
Participantes:
- José Luis Falcón Ramírez
- Antonio Falcón Aragón
- Carlos M. Cornejo Crespo
- Antonio Fco. Martín Romero
- Carlos Villegas Núñez
Durante la reunión hemos hablado de la necesidad de completar las
tareas para evitar dependencias entre componentes, y de esta forma cada
compañero puede ir avanzando sin verse afectado por la demora.
Después hemos repasado la planificación, tras introducir cambios en la tipología de tickets/finalización tickets padre.
También se trató de los problemas de versionado con las
herramientas proporcionadas con el IDE SSTS. Se han detectado
comportamientos que retrasan el trabajo.
Entregable 2 - Requisitos y arquitectura
En esta sección se define la estructura del sistema que comprende los
elementos software con sus propiedades visibles y no software, además
de las relaciones de dichos elementos, mediante sus respectivas
interfaces.
Arquitectura Física
La arquitectura física no es más que la asignación de los componentes
software necesarios para el correcto funcionamiento del sistema, sobre
elementos hardware. En nuestro caso, observemos el siguiente diagrama de
despliegue.
En la imagen anterior abstraemos el funcionamiento de nuestra aplicación, identificando tres módulos atómico como son:
- El WAR de la aplicación
- El servidor de despligue, en este caso un Tomcat
- Servidor de Bases de Datos, como puede ser MySQL
Hardware Recomendado
- CPU: Cualquier arquitectura x86
- Memoria RAM: 2GB
- HDD: 320GB
Software Base
- SSOO: Windows XP/7/Ubuntu/Linux
- Máquina Virtual de Java, superior a 1.5
- MySQL Server 5
- Tomcat 5.5
- Navegador Web: Firefox 4, Chrome 10, IE 8
Arquitectura Lógica
La arquitectura lógica especifica la forma en que los artefactos
software son unidades de composición, para que mediante la combinación
de todos ellos se consiga implementar los requisitos del sistema.
Integración con log4j
En esta sección repasaremos como configurar log4j con nuestro proyecto grails.
Archivos a modificar:
grails-app/conf/Config.groovy
log4j = {
appenders {
console name: 'stdout', layout: pattern(mineIs: '%d{yyyy-MM-dd HH:mm:ss} %-5p [%c{2}] %m%n')
rollingFile name:'mineIs', file: "../loggy.log", append: true,
layout: pattern(conversionPattern: '%d{yyyy-MM-dd HH:mm:ss} %-5p [%c{2}] %m%n')
}
info mineIs:'milog', additivity:false
}
Añadimos el ámbito de log o cargamos logger dentro de class
Entregable 3 - Documento de análisis
Casos de Uso
Consulta Habitación Disponible
Caso de Uso: Consultar Habitación/es Disponible/s.
Descripción: El sistema comprueba si existen habitaciones disponibles
según un período de días establecido.
Precondición:
Postcondición: El sistema procesa la operación según indicaciones del usuario
y muestra por pantalla las habitaciones disponibles.
Escenario Principal:
1. El sistema solicita los siguientes datos al usuario: Fecha Entrada,
Fecha Salida, Nº Habitaciones, NºAdultos, NºNiños.
2. El actor Usuario introduce los datos y pulsa en Consultar Disponibilidad.
3. El sistema comprueba que el rango de fechas sea válido.
4. El sistema comprueba que hay suficientes habitaciones disponibles
para esa categoría, en ese período de fechas.
5. El sistema muestra un listado de las habitaciones disponibles.
Flujos Alternativos:
3a. Si el rango de fechas no es válido:
1. El sistema muestra el error y se reinicia el Caso de Uso.
4a. Si no hay habitaciones disponibles de esa categoría:
1. El sistema comprueba la disponibilidad de habitaciones con
diferente categoría en ese rango de fechas.
2. El sistema muestra un listado con las habitaciones.
*a. En cualquier momento el cliente cancela la consulta:
1. El sistema reinicia el Caso de Uso.
Reserva de Habitación
Caso de Uso: Reservar Habitación/es.
Descripción: El sistema realiza la reserva de la habitación seleccionada,
según el rango de fechas establecido.
Precondiciones:
* La habitación seleccionada debe estar disponible en las fechas indicadas.
* El usuario debe estar registrado en el sistema.
Postcondición: El sistema procesa la operación y entrega al usuario el Código
de la reserva realizada.
Escenario Principal:
1. El sistema muestra la habitación y el coste final para la estancia
seleccionada.
2. El actor Usuario acepta la reserva.
3. El sistema establece el estado de la habitación en Reservada para esos días.
4. El sistema devuelve al cliente el código y los detalles de la reserva.
Flujos Alternativos:
2a. Si el usuario no acepta la reserva:
1. Se reinicia el Caso de Uso.
3a. Si el proceso de reserva falla:
1. El sistema muestra el error y se reinicia el Caso de Uso..
*a. En cualquier momento el usuario decide cancelar la reserva:
1. El sistema reinicia el Caso de Uso.
Cancelar Reserva
Caso de Uso: Cancelar Reserva.
Descripción: El sistema comprueba si el usuario ha realizado una reserva
con antelación y la cancela, aplicando el coste de penalización adecuado.
Precondición:
* El usuario está registrado en el sistema.
* El usuario ha realizado una reserva, y tiene el código de la misma.
Postcondición:
* El sistema cancela la reserva
* Se cobra al cliente el coste de penalización, en caso de haberlo.
Escenario Principal:
1. El actor Usuario solicita la cancelación de la reserva.
2. El sistema comprueba el nº de días que faltan hasta el día reservado.
3. El sistema calcula el coste de penalización.
4. El sistema realiza el cobro sobre la tarjeta de crédito del usuario.
5. El sistema cancela la reserva y vuelve a marca la habitación como Disponible.
Flujos Alternativos:
2a-5a. Si el proceso falla:
1. El sistema muestra el error y se reinicia el Caso de Uso.
*a. En cualquier momento el cliente cancela la operación:
1. Se reinicia el Caso de Uso.
Realizar Llamada Telefónica
Caso de Uso: Realizar Llamada Telefónica.
Descripción: El cliente realiza una llamada telefónica.
Precondición: El cliente ocupa una habitación del hotel.
Postcondición: El sistema calcula la duración y el coste de la llamada.
Escenario Principal:
1. El cliente comienza la llamada indicando si es nacional o internacional.
2. El cliente habla por teléfono.
3. El cliente termina la llamada.
4. El sistema calcula la duración de la llamada y el coste total de la misma.
Consumir Bebida
Caso de Uso: Consumir Bebida/s.
Descripción: El cliente consume una bebida del minibar.
Precondición: El cliente ocupa una habitación del hotel.
Postcondición: El sistema calcula el coste de las consumiciones que el
cliente ha realizado.
Escenario Principal:
1. El cliente elige el tipo de bebida que va a tomar.
2. El cliente consume la bebida.
3. El sistema calcula el coste de la consumición, dependiendo del tipo de
bebida y de la categoría de la habitación.
Llegada de Cliente
Caso de Uso: Llegada de Cliente.
Descripción: El cliente llega al hotel.
Precondición: El cliente ha realizado la reserva de la habitación previamente.
Postcondición: El sistema asigna la habitación determinada al cliente, marcando
su estado como ocupado.
Escenario Principal:
1. El sistema solicita los datos del cliente.
2. El cliente facilita los datos al sistema.
3. El sistema busca una habitación concreta, según la reserva del usuario, y
la marca como ocupada, asignándosela al cliente.
4. El sistema reinicia el contador de llamadas de la habitación.
Flujo Alternativo:
2a. Los datos son erróneos:
1. El sistema reinicia el C.U.
2b. El cliente no ha realizado reserva
1. Finaliza el C.U, quedando sin efecto sobre el sistema.
3a. El proceso falla:
1. Se reinicia el C.U.
4a. El proceso falla
1. Se reinicia el C.U.
Calcular Factura
Caso de Uso: Calcular Factura.
Descripción: Se calcula el precio total de la estancia y se presenta la
factura al cliente.
Precondición: El cliente tiene asociada una reserva y ocupa una habitación
del hotel.
Postcondición: Se presenta la factura al cliente.
Escenario Principal:
1. Se calcula el coste total de las llamadas realizadas.
2. Se calcula el coste total de las bebidas consumidas.
3. Se calcula el coste total de la factura (reserva, llamadas, bebidas).
4. Se devuelve al cliente la factura, detallando los costes por apartados.
Flujo Alternativo
1-4a. El proceso falla:
1. Se reinicia el C.U.
Salida de Cliente
Caso de Uso: Salida de Cliente.
Descripción: El cliente termina su estancia en el hotel.
Precondición: Se ha realizado la facturación al cliente.
Postcondición: Se eliminan los datos de reserva del cliente.
Escenario Principal:
1. Se presenta la factura.
2. Se inicializa el tiempo de llamadas de la habitación.
3. Se reponen las bebidas del minibar.
4. Se marca la habitación como libre, incrementándose el número de
habitaciones libres del hotel.
Flujo Alternativo
1-4a. El proceso falla:
1. Se reinicia el C.U.
Entregable 4 - Documento de diseño
Diagrama de Clases
Con el siguiente diagrama queremos representar el comportamiento
estático de nuestro sistema, identificando aquellas relaciones entre
entidades que se correspondan con la realidad a implementar.
Diagramas de Secuencia
A continuación se muestran la relación de diagramas de secuencia enmarcados en las necesidades de diseño de cada Sprint.
Sprint 1 - Consulta Habitación Disponible
Sprint 2 - Diagrama de Secuencia de Reserva de Habitación
Sprint 3 - Diagrama de Secuencia de Cancelar Reserva
Sprint 4 - Diagramas de Secuencia de Consumiciones
Realizar Llamada Telefónica
Consumir Bebida
Sprint 5 - Diagrama de Secuencia de Llegada de Cliente
Sprint 6 - Diagrama de Secuencia de Calcular Factura
Sprint 7 - Diagrama de Secuencia de Salida de Cliente
Diagramas de Robustez
Sprint 1 - Consulta Habitación Disponible
Sprint 2 - Reserva de Habitación
Sprint 3 - Cancelar Reserva
Sprint 4 - Realizar Consumiciones
Realizar Llamada Telefónica
Consumir Bebida
Sprint 5 - Llegada de Cliente
Sprint 6 - Calcular Factura
Sprint 7 - Salida de Cliente
Mockups Interfaces
Página principal
Sprint 1 - Consulta Habitación Libre
Sprint 1 - Consulta Habitación Libre Alternativo
Sprint 2 - Reserva
Sprint 2 -Reserva Realizada
Sprint 3 -Cancelar Reserva
Sprint 4: Consumos
Sprint 5: Llegada de Cliente
Sprint 6: Facturación
Entregable 5 - Casos de prueba
