Ingenier´ ıa Web Proyecto Proyecto de Desarrollo Desarrollo
Inge Ingeni nier er´ ´ıa ıa Info Inform rm´ ´ atica Universidad de C´ adiz Curso 2010-11 Juan Manuel Dodero & Daniel Molina 14 de marzo de 2011
´ Indice 1. Int Introducc roducci´ i´ on on
2
1.1. Descripci Descripci´on o´n del trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2. Tecno ecnolog log´´ıas web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3. Herrami Herramientas entas de desarroll desarrolloo . . . . . . . . . . . . . . . . . . . . . . . . . . . 2. An´ alisis de la aplicaci´ alisis on on
2 2 2 3
2.1. Modelo Modelo de de negoci negocioo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2. Requ Requisi isitos tos no funcion funcionales ales . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3. 2. 3. Cas Casos os de de uso uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3. M´ etod o de desarroll etodo desarrollo o
3 5 7 10
3.1. Fases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.2. 3. 2. Rol Roles es . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.3. Ent Entrega regable bless . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4. En Entrega trega y evaluac evaluaci´ i´ on on
12
4.1. Ev Evalu aluaci aci´on o´n . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1
Proyecto
1.
Ingenier´ıa Web
Introducci´ on
El proyecto consiste en el desarrollo de una aplicaci´on web a escala usando los m´etodos, t´ecnicas y herramientas de la Ingenier´ıa Web. El trabajo estar´ a organizado en equipos de m´ aximo cuatro personas, donde cada una de ellas debe desempe˜ nar varios roles. La formaci´on de los equipos de proyecto se notificar´ a al profesor de la asignatura. Las tecnolog´ıas web de base a emplear ser´ an Java Enterprise Edition (JEE) y Grails como framework de desarrollo web que facilite la implementaci´ o n de la aplicaci´ o n de acuerdo con la arquitectura Modelo-Vista-Controlador (MVC).
1.1.
Descripci´ on del trabajo
La aplicaci´ on web a desarrollar es una versi´on sencilla de una aplicaci´on web de consultas y reservas hoteleras. El sistema deber´ a permitir administrar las habitaciones y servicios de un hotel, realizar consultas y cancelaciones de reservas, y emitir las facturas correspondientes a la salida del cliente.
1.2.
Tecnolog´ıas web
Las tecnolog´ıas web a emplear para la implementaci´ on del proyecto quedan a elecci´ on del equipo de proyecto. Se recomienda el uso de Java y Grails como framework de desarrollo web que facilite la construcci´on de aplicaciones con arquitectura MVC (Model-ViewController) y el mapeo ORM (Object-Relational Mapping) siguiendo un patr´ on DAO (Data Access Objects).
1.3.
Herramientas de desarrollo
Grails, Spring y JEE
Se usar´ a Grails como framework de desarrollo web que facilite la implementaci´ o n de la aplicaci´on de acuerdo con la arquitectura Modelo-Vista-Controlador (MVC). Se usar´ an los elementos fundamentales de JEE (Java Enterprise Edition) y Spring framework sobre los que se sustenta Grails para el desarrollo de la arquitectura b´asica de la aplicaci´on. Si se utilizara otro framework distinto de desarrollo de aplicaciones web, su elecci´o n y uso deber´ an justificarse adecuadamente. Entorno de desarrollo
Como entorno de desarrollo se aconseja usar la u ´ltima versi´on de SpringSource Tool Suite (STS) o en su defecto Eclipse convenientemente configurado con los plugins necesarios. Se recomienda el uso de ant o maven , herramientas equivalentes a a los instrumentos tradicionales de construcci´ on (i.e. make) desde la l´ınea de comandos, aunque mucho m´ as intuitivas y flexibles para el desarrollo en Java. Permiten automatizar tareas habituales en el desarrollo de aplicaciones Java: configuraci´ on del entorno, compilaci´ on e interpretaci´ on de ficheros, generaci´ on de la documentaci´ on, ejecuci´ on de casos de prueba, etc.
Curso 2010-11
2
Proyecto
Ingenier´ıa Web
Pruebas
JUnit es un marco de trabajo para escribir casos de prueba cuya ejecuci´ on y comprobaci´ on puede realizarse de manera automatizada. JUnit es una biblioteca de Java, y sirve para codificar las pruebas unitarias de software en este mismo lenguaje. Tambi´en se recomienda el uso de selenium para las pruebas funcionales y de integraci´ on. Otras herramientas
A lo largo del proyecto se recomendar´ a el uso de otras herramientas para los diagramas de an´alisis, dise˜ nos, profiling, etc. Es potestativo del equipo de desarrollo emplear las herramientas con las que se encuentre m´as c´omodo, aunque se requiere que sean herramientas de software libre o con licencia de uso no restringida para educaci´ on.
2.
An´ alisis de la aplicaci´ on
Una cadena de hoteles necesita modernizar de sus sistemas de reserva y facturaci´ on. El objetivo es reemplazar sus antiguo sistema de reservas mainframe por una aplicaci´ on web desarrollada en lenguaje Java. La fase de an´alisis de los sistemas existentes ha permitido la elaboraci´on de un modelo de an´ alisis formado por el modelo de negocio y un modelo de sistema.
2.1.
Modelo de negocio
El modelo de negocio recoge una representaci´ o n del dominio en el cual se desarrolla el sistema. En el caso que nos contempla, el dominio del alojamiento. El modelo de negocio recoge las entidades fundamentales del dominio y las relaciones existentes entre las mismas, que se describen a continuaci´ on. Hotel
El Hotel es la unidad gestora. Es la responsable de atender las peticiones (reservas/cancelaciones) de los clientes, y es la encargada de presentarles la factura. Un hotel est´a compuesto de un conjunto de habitaciones, que alquila durante un plazo de d´ıas. Por motivos de simplificaci´ on, adem´as del listado de habitaciones, el Hotel poseer´ a un listado por cada d´ıa del n´ umero de habitaciones de cada tipo y categor´ıa libre. En el momento de la reserva no se asigna realmente ninguna habitaci´ on concreta, sino u ´ nicamente cuando llega el cliente.
Habitaci´ on Las habitaciones se distinguen por su n´ umero de camas (habitaci´ on individual o doble) y por la categor´ıa de la habitaci´ on. Adicionalmente, se podr´ a a˜nadir una cama suplementaria infantil con un peque˜ no coste. En funci´on de la categor´ıa se distinguen tres tipos: normal, business y alta. Cada categor´ıa implica un precio distinto, justificado por el espacio interno, por los servicios disponibles: televisi´on, ducha, etc., y por la calidad de las bebidas suministradas en el minibar.
Curso 2010-11
3
Proyecto
Ingenier´ıa Web
Consumibles A continuaci´on de detalla los servicios que se ofrecen al cliente y que incrementan la factura de la habitaci´ on. Consumo de bebidas del minibar. Llamadas telef´ onicas. Se cobrar´ a por minutos, utilizando una tarifa por minuto para llamadas nacionales y otra para llamadas internacionales. Las bebidas del minibar est´andar de una habitaci´ on son: Cuatro tercios de cerveza. Dos botellas de vino de litro. Cuatro botellas de agua. Cuatro latas de refresco (coca-cola, etc.). Cuatro bebidas alcoh´ olicas (whisky, ron, etc.) Cada tipo de cerveza posee un precio asociado, que depende de la categor´ıa de la habitaci´on. La categor´ıa determina la marca de las bebidas (a excepci´ on del agua o el refresco, que son equivalentes).
Facturas Al finalizar la estancia del cliente, se le suministrar´ a la factura en formato PDF, calculando el coste total de los servicios. El coste total se calcular´ıa: P reciototal
= P recioalojamiento + P reciotelefono + P reciominibar
P recioalojamiento
= dias · (P reciohabitacion · P reciocategoria )
donde: ser´ıa t´ıpicamente de 40 para habitaci´ o n, 70 para doble, y 10 euros adicionales por cama infantil. P reciohabitacion
P reciocategoria
ser´ıa 1 para categor´ıa normal, 1.3 para habitaci´ on business y 2.0 para
categor´ıa alta. Estos precios, sin embargo, deben ser configurables, pues a principios de a˜ no se recalculan en funci´ on del IPC.
Curso 2010-11
4
Proyecto
Ingenier´ıa Web
Reserva y cancelaciones Cada d´ıa cada habitaci´ on puede estar libre, ocupada , o reservada . Libre, la habitaci´on puede ser reservada. Ocupada, no puede ser reservada. Reservada, podr´ıa estar disponible si se cancelase la reserva. No puede reservarse.
S´olo se podr´a reservar con 2 meses de adelanto. Esto es un valor tambi´ en configurable de la aplicaci´on. Toda habitaci´ on reservada se podr´ a cancelar, con las siguientes compensaciones: sin coste, 5 d´ıas antes. 10 %, entre 5-2 d´ıas antes. 30 %, entre 47-24 horas antes. 100 %, en menos de 24 horas. Todos estos valores son asimismo par´ametros configurables de la aplicaci´ on. En el caso de una reserva para una persona, si no hubiese una habitaci´on individual, se le podr´ıa reservar una habitaci´ on doble al precio de una habitaci´on individual.
2.2.
Requisitos no funcionales
La aplicaci´on debe cumplir con una serie de requisitos no funcionales caracter´ısticos de las aplicaciones web, relativos a su arquitectura, seguridad, uso de est´ andares, interfaz de usuario y rendimiento y escalabilidad.
Curso 2010-11
5
Proyecto
Ingenier´ıa Web
Arquitectura
1. El sitio web de la aplicaci´ on deber´ a poderse explotar y administrar empleando cualquier navegador web. 2. Los datos de la aplicaci´ on deber´ an estar almacenados en un sistema gestor de bases de datos relacionales, sobre el cual puedan realizarse futuras consultas no previstas en la actualidad. 3. Todas las funcionalidades de la aplicaci´ on deber´ an estar accesibles, adem´ a s de a trav´es de la interfaz de usuario, a trav´ es de llamadas a servicios web que cumplan con la arquitectura ReST. Seguridad
1. Los datos de la aplicaci´ on solo podr´ an ser modificados por aquellas personas autorizadas para ello. Los perfiles de usuario de la aplicaci´on ser´an tres: administrador, usuario registrado en el hotel y usuario invitado. 2. El perfil de usuario invitado ser´a el que empleen los usuarios web que a´ u n no se hayan registrado para tener acceso a la apliaci´ on: consulta del calendario de reservas (sin datos sobre qui´enes han realizado ´estas) y registrarse en la aplicaci´ on. Una vez registrado, podr´ a hacer las operaciones disponibles como usuario registrado. 3. El perfil de usuario registrado tendr´ a acceso a un men´ u de operaciones que no incluya labores de administraci´ on. Las funcionalidades b´ asicas disponibles para los usuarios registrados son: realizaci´ on de una reserva (sin habitaci´ on asignada), cancelar una reserva, consumo de servicios —e.g. bebidas o tel´efono– (solo si el usuario ha ocupado ya su habitaci´ o n), emitir la factura (o una copia de ´esta si ya fue emitida) de la habitaci´on y de los servicios consumidos, consulta y reserva de una habitaci´on disponible. 4. El perfil de administrador tendr´a acceso a todas las operaciones que se pidan de la aplicaci´on (altas, bajas, modificaciones y consultas de todo tipo de entidades y relaciones del modelo de la aplicaci´ on: hotel, habitaciones, reservas, etc.), pudiendo desempe˜ nar adem´ as el papel de un usuario registrado normal emulando su rol. Est´ andares
La licencia de uso del software donde se aloje y con el que se realice la aplicaci´ on debe ser lo menos restrictiva posible, preferentemente software de c´ odigo abierto. La aplicaci´on deber´ a cumplir con los est´ andares marcados por el WWW Consortium (HTML 4.0 o superior, CSS 2.0, etc.) El sitio web deber´ a cumplir con las normas de accesibilidad para aplicaciones web (WAI 2.0) definidas por el WWW Consortium, debiendo cumplir como m´ınimo el nivel A.
Curso 2010-11
6
Proyecto
Ingenier´ıa Web
Interfaz de usuario
El sitio web deber´ a tener una estructura clara, ordenando el contenido y las funciones de la aplicaci´o n en pesta˜ nas o apartados que abarquen todas las funcionalidades disponibles, seg´ un el perfil de seguridad del usuario conectado. El sitio web deber´ a posibilitar la visualizaci´on de cualquier tipo de contenido multimedia (texto, gr´ aficos, v´ıdeos, etc.) en consonancia con la imagen corporativa de la empresa de gesti´ on hotelera. En los formularios de entrada, se valorar´ a la inclusi´on de elementos de interacci´ on as´ıncrona en la interfaz del cliente que mejoren la usabilidad de la aplicaci´ on. A trav´ es de su interfaz basada en servicios, el sitio web deber´ıa poder ser consultado a trav´ es de un dispositivo m´ ovil de interfaz reducida, diferente al de un navegador tradicional de un ordenador de sobremesa. Esto no quiere decir que deba desarrollarse la interfaz para un dispositivo m´ ovil, sino que la arquitectura de la aplicaci´on (basada en servicios ReST) debe estar preparada para ello. Rendimiento y escalabilidad
La base de datos deber´ a disponer de un pool de conexiones configurables en n´ umero para que la aplicaci´on sea escalable en funci´ on de los recursos hardware y software disponibles. Las peticiones as´ıncronas (AJAX) que se realicen a la aplicaci´ on deber´ an limitarse para no correr el riesgo de sobrecargar al servidor. Las peticiones concurrentes de acceso a la base de datos deben dejar a la aplicaci´ on en un estado consistente. En condiciones normales de utilizaci´ on de la red, las peticiones realizadas no deben superar nunca un tiempo m´ aximo, que vendr´a marcado por el tiempo que tarda en cargar el servlet controlador.
2.3.
Casos de uso
Este apartado es una especificaci´ on parcial de ejemplo de algunos casos de uso del sistema. La ingenier´ıa de los requisitos y el an´ alisis completo deber´a realizarse de acuerdo con los requisitos solicitados. Estos casos de uso deber´an implementarse para poder utilizar la aplicaci´ on tanto desde la conserjer´ıa del hotel como desde un portal web p´ ublico. Los casos de uso corresponden a la gesti´ on de las reservas, la llegada y salida de clientes del hotel, el consumo de sus servicios y la facturaci´on. Consulta de habitaci´ on disponible Descripci´ on Consulta si en el Hotel hay una (o varias) habitaciones, dado un periodo
de d´ıas. on, que podr´ıa ser un empleado en recepci´ on, o una Actores El usuario de la aplicaci´ posterior p´ agina web. Curso 2010-11
7
Proyecto
Ingenier´ıa Web
Flujo B´ asico :
Obtener todas las habitaciones disponibles para las fechas indicadas. Comprobar que haya suficientes disponibles de las categor´ıas indicadas. Flujo Alternativo :
Si desea una habitaci´ on individual, y no hay disponible pero s´ı una habitaci´ on doble, se considerar´ a disponible. Reserva de habitaci´ on disponible Descripci´ on Reserva si en el hotel hay una (o varias) habitaciones, dado un periodo de
d´ıas. on, que podr´ıa ser un empleado en recepci´ on, o una Actores El usuario de la aplicaci´ posterior p´ agina web. Flujo B´ asico :
Mostrar el coste de alojamiento estimado. Pedir confirmaci´ on al usuario. Si es que s´ı. marcar la habitaci´ on para las fechas indicada como reservada para esos d´ıas. Devolver al cliente un c´odigo de reserva. Flujo Alternativo :
Si no hab´ıa, indicarlo al usuario. Cancelar reserva
on. Descripci´ on Cancelar una reserva realizada con antelaci´ on, que podr´ıa ser un empleado en recepci´ on, o una Actores El usuario de la aplicaci´ posterior p´ agina web. Para cancelar una reserva, habr´ıa que identificarse con el c´odigo de reserva correspondiente. Flujo B´ asico :
Calcular el n´ umero de d´ıas que faltan para el d´ıa de la reserva. Calcular el coste en penalizaci´on. Cobrar el precio en la tarjeta de cr´edito (no implementar). Marcar la habitaci´ on como disponible.
Curso 2010-11
8
Proyecto
Ingenier´ıa Web
Llegada de un cliente con reserva Descripci´ on El cliente llega al hotel. Actores El cliente. Flujo B´ asico :
Se busca una habitaci´ on concreta y se marca como ocupada, asign´ andosela al cliente. Se reinicia el contador de llamadas desde la habitaci´on. Consumo de servicios
En estos casos de uso, el cliente decide beber una bebida del minibar o realizar una llamada telef´onica desde la habitaci´ on. A continuaci´ on se describe el caso de la llamada telef´onica, aunque el consumo de bebidas u otros servicios similares es an´ alogo. El pre-requisito de estos casos de uso es que el cliente haya ocupado previamente una habitaci´on del hotel (llegada del cliente con reserva). onica. Descripci´ on El cliente realiza una llamada telef´ Actores El cliente. Flujo B´ asico :
El cliente empieza la llamada, indicando si es nacional o internacional. El cliente habla por tel´efono. El cliente termina la llamda, calcul´andose el tiempo de duraci´on. Se incrementa el tiempo de la llamada a las anteriores. C´ alculo de la factura Descripci´ on Se calculan el precio total de la estancia y se presenta la factura al cliente. Actores El cliente. Flujo B´ asico :
Se calcula el tiempo total de llamadas. Se calcula el coste total de las llamadas realizadas. Se calcula el coste total de las bebidas consumidas por el cliente. Se calcula el coste total de la factura. Se devuelve al cliente la factura, detallando los costes por cada apartado.
Curso 2010-11
9
Proyecto
Ingenier´ıa Web
Salida del cliente Descripci´ on El cliente termina su estancia en el hotel. Actores El cliente. Flujo B´ asico :
Se presenta la factura (caso de uso anterior). Se inicializa el tiempo de llamadas de la habitaci´ on libre. Se reponen los contadores de las bebidas disponibles del minibar. Se marca la habitaci´ on como libre, increment´ andose el n´ umero de habitaciones libres del hotel.
3.
M´ etodo de desarrollo
El desarrollo del proyecto se realizar´a con el m´etodo SCRUM, un m´etodo a´gil de desarrollo, que estar´ a dividido en varias fases semanales, en las que participar´an una serie de roles de desarrolladores y se generar´ an unos entregables en forma de software y de documentos. Para la gesti´ on del proyecto se emplear´ a un espacio garuito creado con tal prop´ osito en assembla. Todos los miembros del equipo deber´ an abrir una cuenta, configurar y compartir el espacio y las herramientas de gesti´on del proyecto. Dicho espacio estar´ a como m´ınimo configurado con el sistema de control de versiones (svn ) y el sistema de gesti´ on y seguimiento de tareas e incidencias (tickets). Se recomienda que el administrador del proyecto cree un espacio de trabajo con una configuraci´on recomendada ( featured configuration ) m´ınima con los elementos anteriores. Tras la configuraci´ on del espacio del proyecto en assembla, se deber´ a invitar al profesor como observador (watcher ) de todo el material depositado en dicho espacio. Como wiki del proyecto se usar´a (mediawiki ), que estar´ a alojado en osl2.uca.es/wikiIW en lugar de en assembla.
3.1.
Fases
Cada fase del desarrollo vendr´ a delimitada por unos plazos de realizaci´on, seg´ un se indica en la tabla 1. Todos los roles desempe˜ nar´an su labor en cada una de las fases del proyecto. Cada fase durar´ a una semana y finalizar´ a con la entrega de una versi´ on del software y los documentos entregables, a depositar en la herramienta de gesti´ on del proyecto. El desarrollo del proyecto abarca aproximadamente 8 semanas, desde el 13 de abril de 2011 hasta el 8 de junio de 2011. Las entregas se producir´ an en las clases de los mi´ercoles. Sprint
0 1 2 3 4 5 6
Descripci´ on
Entrega
Planificaci´on y configuraci´on Consulta de habitaci´ on disponible Reserva de habitaci´on disponible Cancelar reserva Consumos (bebida/tel´efono) Llegada de cliente con reserva C´ alculo de factura y salida del cliente
13 abril 27 abril 4 mayo 11 mayo 18 mayo 25 mayo 1 junio
Cuadro 1: Planificaci´ on inicial del proyecto Curso 2010-11
10
Proyecto
Ingenier´ıa Web
En cada fase se debe haber completado una versi´ on de todos los entregables, incluyendo documentos y software. Los documentos se escribir´ an en el wiki del proyecto. El software se depositar´ a en el sistema de control de versiones svn o git del repositorio del proyecto en assembla . Las tareas involucradas en el desarrollo deben quedar registradas y convenientemente actualizadas como tickets del proyecto en assembla . Tambi´en se deber´ a completar la planificaci´ on de los sprints del proyecto en assembla y rellenar los informes scrum con las tareas realizadas en cada sprint.
3.2.
Roles
Los roles a desempe˜ nar por los miembros de un equipo de proyecto son los siguientes: Jefe de proyecto: planifica, controla y organiza el trabajo. Es el interlocutor v´ alido con el profesor, que actuar´ a como gerente del proyecto y origen de los requisitos de usuario. Arquitecto software : dise˜ na la arquitectura de los componentes, servidores de aplicaci´on, bases de datos, y de todos los sistemas software que intervengan en el despliegue de la aplicaci´on para ponerla en funcionamiento. Analista/programador : analiza, dise˜ na y codifica los componentes de software; dibuja diagramas de casos de uso, an´alisis y dise˜no; programa las clases en Java. Dise˜ nador de interfaz de usuario : analiza, dise˜ na y codifica la interfaz de usuario (clases de vista) en HTML y JavaScript. Codificador de pruebas : planifica, codifica y configura la ejecuci´ on de casos de prueba unitarias, funcionales y de integraci´ on. Administrador de base de datos : Analiza, dise˜na y mantiene el esquema de base de datos de la aplicaci´ on; ayuda en la codificaci´on de las clases de entidad que tengan que ver con el acceso a la base de datos Administrador de sistemas : Instala y configura los entornos de desarrollo, servidores y sistemas software de los que depende la aplicaci´on (base de datos, servidor web, servidor de aplicaciones, sistema de control de versiones, etc.)
3.3.
Entregables
La siguiente es una lista de los entregables (documentos y software) a generar. De todos los entregables se elaborar´ a y entregar´ a una versi´on en cada fase del desarrollo. El wiki de desarrollo del proyecto contendr´ a una descripci´on textual pormenorizada de todos los entregables completados en cada momento del desarrollo del proyecto. on y configuraci´ on : planificaci´on razonada de tiempos de desarrollo, reE1 Planificaci´ cursos humanos y roles, entregables, plazos e hitos, reuniones de proyecto, elecci´ on de tecnolog´ıas de desarrollo y frameworks, herramientas; Configuraci´ on del entorno de desarrollo (v.g. eclipse) y herramientas de desarrollo (v.g. ant, log4j, etc.), configuraci´on del sitio web de alojamiento del proyecto, incluyendo el sistema de control de versiones (v.g. svn), wiki del proyecto, seguimiento de tareas e incidencias (v.g. tickets), etc. Curso 2010-11
11
Proyecto
Ingenier´ıa Web
o n de requisitos y casos de uso del sistema; E2 Requisitos y arquitectura : especificaci´ arquitectura del sistema. alisis: diagramas UML que describan el modelo de an´ alisis. E3 Documento de an´ no: diagramas UML (clases, colaboraci´ on, actividad, etc.) que E4 Documento de dise˜ describan el modelo de dise˜ no. on de las clases del moE5 Casos de prueba : casos de prueba aplicados a la implementaci´ delo (pruebas unitarias), las funcionalidades de la aplicaci´ on (pruebas funcionales) y la integraci´ on de componentes (pruebas de integraci´ on), fichero build.xml (en caso de usar ant) o pom.xml (en el caso de usar maven) preparado para el lanzamiento de todas las pruebas. nada, descripci´ o n del diE6 Persistencia de datos : esquema de la base de datos dise˜ se˜no arquitect´ onico del mapeo objeto-relacional realizado y de los elementos del framework utilizados para su definici´ on. on : todo el c´odigo fuente programado; scripts necesarios para el desE7 Implementaci´ pliegue de la aplicaci´ on en los servidores, preparaci´ on de ficheros de log, creaci´ on y carga de la BD; fichero war con la aplicaci´ on preparada para su despliegue en el servidor de aplicaciones. on : Instrucciones de instalaci´on y despliegue de la aplicaE8 Instrucciones de instalaci´ ci´on, incluyendo el diagrama de despliegue de todos sus componentes.
4.
Entrega y evaluaci´ on
La entrega se producir´ a durante la clase del mi´ ercoles 8 de junio de 2011. Todos los documentos entregables ser´ an accesibles a trav´ es de un wiki de desarrollo, que se alojar´a y ser´ a compartido en el mediawiki del proyecto. Todos los entregables de texto deben incluirse en una u´nica p´agina del wiki. No se deben emplear enlaces para estructurar los entregables textuales en varias p´ aginas. El control de versiones se llevar´a a cabo a trav´es de las facilidades suministradas por el propio mediawiki.
4.1.
Evaluaci´ on
La evaluaci´ on del proyecto se realizar´ a en funci´on de la fase que se haya alcanzado. La evaluaci´ on del proyecto se realizar´ a en atenci´ on a los siguientes criterios: M´etodo (10 %): ejecuci´ on y seguimiento del m´etodo y la planificaci´ on, plazos de entregables, etc. Funcionamiento (10 %): correcto funcionamiento de las funcionalidades correspondientes a todos los casos de uso implementados; para comprobar el funcionamiento se emplear´ an los casos de prueba. Curso 2010-11
12
Proyecto
Ingenier´ıa Web
Requisitos no funcionales (10 %): cumplimiento de los requisitos no funcionales de la aplicaci´on. T´ecnicas (20 %): correcta aplicaci´ on de las t´ecnicas y patrones de desarrollo aplicadas a lo largo de las fases (MVC, ORM, etc.) Framework (10 %): correcto empleo de las facilidades proporcionadas por el framework de desarrollo web utilizado. Entregables (30 %): correcci´ on y entrega en plazo de los entregables accesibles a trav´es del wiki del proyecto (requisitos, an´ alisis, dise˜ no, pruebas, base de datos, implementaci´ on, despliegue) Herramientas (10 %): correcci´ on e intensidad de la utilizaci´on de las herramientas de gesti´on y desarrollo del proyecto (assembla, svn, trac, wiki, etc.) Se habilitar´ a en el campus virtual una r´ ubrica o instrumento de autoevaluaci´ on para llevar el control de la evaluaci´ on del proyecto. Cada grupo deber´ a llevar un control de la evaluaci´ on para cada fase del proyecto utilizando dicha r´ ubrica, auto-valorarse y discutir las valoraciones con el profesor al comienzo de la clase.
Curso 2010-11
13
