GRUPO

INDICE

1- Introducción

2- Desarrollo técnico

3- Gestión del proyecto

4- Conclusiones

5- Demostración

Introducción - presentación

Miembros:

Jose Luis Outón (Coordinador)

Jon Ander Zapirain (Secretario)

Oskar Yanguas

Jorge Martín

Diego Lizarbe

Lander Nava

Alex Diaz

Desarrollo técnico

2.1- Captura de requisitos

2.2- Análisis

2.3- Arquitectura del sistema

2.4- Diseño

2.5- Implementación

2.6- Pruebas

2.7- Plan de implantación

2.1- Captura de requisitos

Casos de uso del administrador:

2.1- Captura de requisitos

Identificar usuario:Permite a un usuario identificarse frente al sistema Multiplan. El Usuariointroduce su identificador y contraseña.

Gestionar Tipo Excursión:Permite gestionar los Tipos de Excursión del Sistema Multiplan: bien para crear uno nuevo, bien para copiar uno existente como para eliminarlo.

Crear y Copiar Tipo de Excursión:Permite generar tipos de excursión NUEVOS y sus excursiones asociadas.

Gestionar Excursiones:Permite consultar y anular excursiones del Tipo de Excursión seleccionado.

Planificar Excursiones:Permite anular las excursiones programadas para ese día.

2.2- Análisis

Caso de uso PLANIFICAR EXCURSIONES

Diagrama de secuencia:

2.3- Arquitectura del sistema y elección tecnológica

Interfaz de usuario:

JSP = JAVA + HTML.

Utilización de formularios HTML para enviar y procesar información.

Método GET:Enviar y recibir la información de los formularios.

Capa de negocio:

JAVA, ésta se encarga de hacer de intermediaria entre la interfaz de usuario y la capa de acceso a la base de datos.

Se tratan los datos obtenidos de la BD.

2.3- Arquitectura del sistema

Capa de base de datos:

MySQL

Utilizando JDBC en JAVA para comunicarnos con la capa de gestión de datos.

Obtener/modificar la información de la base de datos

Se utilizan procedimientos almacenados.

2.4 - Diseño

Caso de uso PLANIFICAR EXCURSIONES

ExcursionesHoy():listaInformacionExcursion

2.5 – Implementación

public boolean conectar(){boolean resultado=true;try {

//Cargamos el puente JDBC => MysqlSystem.out.println("Intentando cargar el conector...");Class.forName("com.mysql.jdbc.Driver");//Intentamos conectarnos a la base de Datos en este caso una base llamada tempSystem.out.println("Conectando a la base...");//con = DriverManager.getConnection("jdbc:mysql://10.227.131.23/multiplan","diego", "diego");con = DriverManager.getConnection(direccion, usuario, contrasena);con.setAutoCommit(false);System.out.println("Conexion a BD establecida");System.out.println();

} catch (ClassNotFoundException e) {e.printStackTrace();

}catch (SQLException e){resultado=false;

}finally{return resultado;

}}

2.5 – Implementación

public String validarPass(String u) throws SQLException{String resultado=null;String sql="{CALL getPass(?)}";CallableStatement s= con.prepareCall(sql);s.setString(1, u);ResultSet r=s.executeQuery();if(r.next()){

resultado=r.getString("usuario.pass");}r.close();s.close();

return resultado;}

Llamada a una transacción y uso del ResulSet:

2.5 – Implementación

Implementación de una transacción:

public void confirmar(Vector<Integer> ids){

GestorBD g=GestorBD.obtenerGestoBD();g.conectar();try {

g.confirmarhoy(ids);g.commit();

}catch (SQLException e){

g.rollback(); e.printStackTrace();

}finally{

g.desconectar();System.out.print("desconectado");

}}

2.6 – Plan de Implantación

-HARDWARE:

SERVIDOR: Es necesario como mínimo un servidor que soportará el Servidor de Base de datos asícomo el servidor Web. También pueden ir por separado.

CLIENTES: Las necesidades Hardware del servicio para cliente son muy bajas.

CONEXIÓN: La carga de tráfico que genera el sistema es relativamente baja por loque con una conexión a Internet estándar seria más que suficiente para utilizar laaplicación de una forma ágil.

-SOFTWARE:

SERVIDOR:1. S.O: Linux o Windows. Cualquiera de estos 2 sistemas operativos tieneversiones gratuitas de los programas recomendados.

2. Servidor Web: Apache, servidor Web con licencia GPL, multiplataforma y quese ha convertido en el principal servidor utilizado.

3. Servidor Base Datos: Nuestra elección tecnológica ha sido MySQL por lasmismas razones que el servidor Web, seguridad, agilidad y multiplataforma.

CLIENTE: La elección de este software corresponderá al cliente.

3-Gestión del Proyecto

3.1 - Método de Trabajo

3.2 - Incidencias relevantes

3.3 - Horas planificadas vs. horas reales; desglose por iteraciones.

3.1- Método de trabajo

Para gestionar el proyecto hemos ido realizando reuniones (normalmente una por semana), para “discutir” aspectos del mismo. En estas reuniones la forma de llegar a un acuerdo ha sido por consenso de todos los miembros del grupo.

Cada miembro del grupo realiza una parte de la tarea que haya que hacer en ese momento y después se pondrá en común en una reunión de grupo.

En la segunda iteración hemos divido el grupo en 2 subgrupos excepto en la ultima entrega que cada miembro del grupo se ha encargado de hacer un caso de uso completo.

3.2 - Incidencias relevantes

En principio el grupo estaba formado por 6 miembros pero tras la realización del DOP se incorporó un miembro mas por causas ajenas a nuestra voluntad.

Otro problema ha sido conseguir reunirnos todos un mismo día y a una hora determinada, ya que cada uno es de un lugar diferente (Pamplona, Beasain, Zumarraga …). Intentamos solucionar este problema mediante Internet, con el uso de una cuenta de gmail y un blog.

A la hora de juntar los trabajos de cada uno ha habido más conflictos de los esperados. Lo que esperábamos que fuese cosa de una hora escasa a veces a supuesto muchas horas de estrés y trabajo continuo.

CONSEJO: más organización y comprensión del problema.

3.3-Horas planificadas VS horas reales

Total

0:00:00

60:00:00

120:00:00

180:00:00

240:00:00

300:00:00

360:00:00

420:00:00

480:00:00

540:00:00

600:00:00

660:00:00

720:00:00

780:00:00

840:00:00

Diferencia esfuerzo Planificado y Real

Esfuerzo planificado total

Esfuerzo real Total

3.3-Procesos Tácticos y Operativos

Procesos Tácticos Procesos Operativos

00:00

06:00

12:00

18:00

24:00

30:00

36:00

42:00

48:00

54:00

60:00

66:00

72:00

78:00

84:00

Procesos Tácticos Vs Operativos por Persona

Jose Luis Outón

Jorge Martín

Jon Ander Zapirain

Oscar Yanguas

Diego Lizarbe

Alexander Diaz

Lander Nava

3.3-Esfuerzo total por persona

00:00

06:00

12:00

18:00

24:00

30:00

36:00

42:00

48:00

54:00

60:00

66:00

72:00

78:00

84:00

90:00

96:00

102:00

108:00

114:00

Esfuerzo total

Jose Luis Outón

Jorge Martín Jon Ander Zapirain

Oscar Yanguas

Diego Lizarbe Alexander Diaz

Lander Nava

4 – Conclusiones

Puntos que consideramos mejorables:

• Añadir la opción de visualizar la página en varios idiomas. Consideramos que es una opción útil en un producto real. Por ejemplo, además de en castellano, en Inglés, Catalán y Vasco.

• Mayor seguridad con la base de datos y las contraseñas.

• Aspecto: por ser nuestra primera aplicación de este estilo, no tenemos mucha experiencia, y ahora, tras terminarla, creemos que podríamos mejorarlo para una mejor visualización de la aplicación. La forma de presentarlo podría mejorarse para que al cliente le resultase más vistoso.

Otros aspectos:

• Uso de herramientas de libre distribución: con ellas podríamos conseguir un producto más abierto y de gran calidad.

• Creemos que hemos tenido que desarrollar partes de la práctica sin tener referencias al respecto, lo que ha dificultado en gran medida poder realizarlas.

4 – Conclusiones

Consideramos que la carga de horas de la aplicación ha sido excesiva, ya que la realización de este proyecto ha hecho que dediquemos menos horas a otras asignaturas.

También habría que decir que ha sido de las pocas asignaturas que realmente nos van a ayudar en nuestro futuro laboral.

Estamos muy orgullosos del resultado de nuestro esfuerzo, reflejado en la siguiente demostración.