David Hernandez PFC

Universidad Carlos III de Madrid
Escuela Politcnica Superior
Aplicacin Web para la gestin de empresas de voluntariado
Proyecto Fin de Carrera Ingeniera Tcnica Informtica
Autor: David Hernndez Ruiz Tutor: Fernando Paniagua Martn Julio 2009
Agradecimientos
A mi familia y a todos los que han colaborado en la realizacin del proyecto. A Fernando Paniagua por su paciencia infinita.
II
Resumen
La gestin de la informacin corporativa por parte de una empresa es una ardua y compleja tarea que normalmente se facilita a travs de aplicaciones de escritorio, orientadas hacia usuarios con poca experiencia y conocimiento sobre el manejo de bases de datos. Sin embargo, an existen empresas que no disponen de este tipo de aplicaciones o, disponiendo de ellas, desean gestionar dicha informacin a travs de tecnologas distintas, como puede ser Internet. Actualmente, se dispone de las tecnologas necesarias para poder llevar a cabo este tipo de desarrollos orientados a su publicacin en Internet, las cuales permiten crear sistemas capaces de interactuar con el usuario, gestionando los datos de una forma sencilla y amigable. Se permite as a un usuario sin el conocimiento necesario un manejo sencillo de la informacin, requiriendo un desarrollo previo por parte de personal cualificado. En este trabajo, se ha realizado el anlisis, diseo e implementacin de una aplicacin Web que facilite la gestin de la informacin de una empresa intermediaria que basa su actividad en el mercado de los seguros, dentro del mbito del voluntariado. La solucin tecnolgica elegida se ha desarrollado en Java, estando el soporte de datos delegado en un sistema gestor de bases de datos MySQL, siendo uno de los aspectos ms relevantes la realizacin de una sencilla interfaz de gestin. Como aadido, se ha incluido la generacin de correos y documentos PDF para agilizar el intercambio de informacin. El sistema se ha diseado pensando en la reusabilidad, con el fin de poder ser utilizado en posteriores aplicaciones con conceptos similares, sin dejar de cumplir todas las necesidades y requisitos que el proyecto requera.
III
IV
Abstract
The management of corporate information from a company is an arduous and complex task that would normally be provided through desktop applications, oriented towards users with little experience and knowledge of database management. However, there are still companies that do not have this kind of applications, or you have them, want to manage this information across different technologies, such as the Internet. Currently, you have the technologies necessary to carry out this type of developmentoriented publication on the Internet, which allow you to create systems capable of interacting with the user, managing the data in a simple and friendly. It allows a user without the need for a simple information, requiring a previously developed by qualified personnel. In this work, has done the analysis, design and implementation of a Web application that facilitates the information management basa an intermediary company that operates in the insurance market within the field of volunteerism. The technology solution chosen was developed in Java, while the data support a delegated management system MySQL, one of the most important aspects of conducting a simple management interface. In addition, has included the generation of PDF documents and emails to accelerate the exchange of information. The system is designed on reusability, to be used in subsequent applications with similar concepts, while fulfilling all the needs and requirements that the project required.
VI
ndice general
Introduccin.................................................................1
1.1 1.2 1.3 Motivacin del proyecto ........................................................................1 Objetivos ..................................................................................................3 Contenido de la memoria.......................................................................4
Estado del arte .............................................................6

2.1 2.1.1 2.2 2.2.1 2.2.2 2.3 2.3.1 2.3.2 2.3.3 2.3.4 2.3.5 2.3.6 2.3.7 2.3.8 Evolucin de las aplicaciones Web.......................................................6 Pasado y presente ...............................................................................6 Comercio electrnico .............................................................................8 Introduccin........................................................................................8 Evolucin y caractersticas del modelo B2B................................ 11 Conceptos tcnicos .............................................................................. 18 MVC .................................................................................................. 18 JAVA ................................................................................................. 19 SERVLETS ...................................................................................... 21 MySQL.............................................................................................. 23 JSP...................................................................................................... 23 APACHE TOMCAT...................................................................... 24 JavaMail............................................................................................. 24 IText .................................................................................................. 25
VII
2.4 2.4.1 2.4.2
Comparativa de las tecnologas disponibles ..................................... 25 Comparativa JSP y ASP.................................................................. 26 Comparativa PHP y JSP ................................................................. 27
Metodologa................................................................29
3.1 3.1.1 3.1.2 3.1.3 3.2 3.2.1 3.3 3.4 3.5 3.5.1 3.5.2 3.5.3 3.6 3.6.1 3.6.2 3.6.3 3.6.4 3.6.5 Modelo de Ciclo de vida Software..................................................... 29 Objetivos........................................................................................... 29 Elementos de un ciclo de vida....................................................... 30 Modelo Ciclo de vida software en Cascada ................................. 30 Plan de proyecto................................................................................... 32 Resumen del proyecto..................................................................... 32 Referencias ............................................................................................ 36 Definiciones .......................................................................................... 36 Organizacin del proyecto.................................................................. 37 Interfaces externas........................................................................... 37 Estructura interna............................................................................ 37 Responsabilidades y roles ............................................................... 38 Planes de proceso de gestin.............................................................. 40 Plan de estimacin........................................................................... 40 Plan de plantilla................................................................................ 40 Plan de compra de recursos ........................................................... 40 Plan aprendizaje personal ............................................................... 41 Plan de Trabajo ................................................................................ 42
VIII
3.6.6 3.6.7 3.6.8 3.7 3.7.1 3.7.2 3.7.3 3.7.4 3.8 3.8.1 3.8.2 3.8.3 3.8.4 3.8.5 3.8.6 3.8.7 3.8.8 3.8.9 3.9 3.9.1 3.9.2 3.9.3
Plan de Control................................................................................ 45 Plan de gestin de riesgo ................................................................ 46 Plan de cierre.................................................................................... 46 Planes de proceso tcnico................................................................... 46 Modelo de proceso.......................................................................... 46 Mtodos, herramientas y tcnicas ................................................. 48 Plan de infraestructura .................................................................... 49 Plan de aceptacin del producto ................................................... 49 Plan de proceso .................................................................................... 50 Plan de gestin de la configuracin .............................................. 50 Plan de validacin y verificacin ................................................... 51 Plan de documentacin .................................................................. 51 Plan de garanta de calidad ............................................................. 52 Revisiones y auditoras.................................................................... 54 Plan de resolucin de problemas................................................... 54 Plan de gestin de subcontratacin .............................................. 54 Plan de mejora del proceso ............................................................ 54 Planes adicionales ............................................................................ 55 Apndices .............................................................................................. 55 Apndice A (RBS) ........................................................................... 55 Apndice B (WBS) .......................................................................... 56 Apndice C (PBS)............................................................................ 57
IX
Anlisis ........................................................................62
4.1 4.2 Descripcin del sistema....................................................................... 62 Requisitos de Usuario y Sistema ........................................................ 64
Diseo .........................................................................72
5.1 5.1.1 5.1.2 5.2 5.2.1 5.3 5.3.1 5.3.2 5.4 5.4.1 5.4.2 5.5 5.5.1 5.6 Arquitectura .......................................................................................... 72 Arquitectura Cliente - Servidor...................................................... 73 Tipos de clientes y servidores ........................................................ 77 Diagrama de Casos de Uso................................................................. 78 Diagrama de Casos de Uso del sistema........................................ 81 Explicaciones de los Casos de Uso.................................................... 82 Casos de Uso Administrador ......................................................... 82 Casos de uso Asociacin ................................................................ 91 Modelo Entidad Relacin de la base de datos ................................. 96 Elementos......................................................................................... 96 Modelo Entidad Relacin de la base de datos............................. 99 Modelo Relacional de la base de datos............................................ 100 Explicacin de Entidades y Atributos de la BBDD ................. 101 Diagrama de clases............................................................................. 103
Desarrollo .................................................................107
6.1 6.2 Introduccin ....................................................................................... 107 Explicacin cdigo IText.................................................................. 108
6.3
Explicacin cdigo JavaMail ............................................................ 112
7 8
Pruebas......................................................................116 Conclusiones ............................................................127

8.1 8.2 8.3 Problemas encontrados al realizar el proyecto............................... 127 Objetivos ............................................................................................. 128 Conclusiones finales .......................................................................... 130
Trabajos futuros.......................................................131
Apndice A. Manual de instalacin................................133

A.1. Hardware y software necesario.............................................................. 133 A.1.1. Hardware........................................................................................... 133 A.1.1.1 Instalacin en un ordenador personal ........................................ 133 A.1.1.2 Instalacin en servidor Web......................................................... 133 A.1.2. Software............................................................................................. 134 A.1.2.1 Instalacin en un ordenador personal ........................................ 134 A.1.2.2 Instalacin en un servidor Web ................................................... 134 A.2. Instalacin de la aplicacin..................................................................... 134 A.2.1 Instalacin en un ordenador personal............................................ 134 A.2.2 Instalacin en un servidor web ....................................................... 142
Apndice B. Manual de usuario......................................144 Anexo I .............................................................................162
XI
Bibliografa.........................................................................163
XII
XIII
ndice de figuras
Ilustracin 2-1 Transmisin de documentos convencional............................................................16 Ilustracin 2-2 Transmisin de datos EDI .......................................................................................17 Ilustracin 2-3 Modelo Vista Controlador ........................................................................................19 Ilustracin 2-4 Diagrama Servlets.......................................................................................................22 Ilustracin 3-1 Ciclo de vida en cascada............................................................................................31 Ilustracin 3-2 Estructura interna.......................................................................................................38 Ilustracin 3-3 RBS...............................................................................................................................55 Ilustracin 3-4 WBS..............................................................................................................................56 Ilustracin 3-5 PBS Gestin................................................................................................................57 Ilustracin 3-6 PBS Pre-desarrollo .....................................................................................................58 Ilustracin 3-7 PBS Desarrollo ...........................................................................................................59 Ilustracin 3-8 PBS Post-desarrollo ...................................................................................................60 Ilustracin 3-9 PBS Soporte ................................................................................................................61 Ilustracin 5-1 Arquitectura cliente servidor .................................................................................74 Ilustracin 5-2 Diagrama casos de uso ..............................................................................................81 Ilustracin 5-3 Modelo entidad relacin BBDD ..............................................................................99 Ilustracin 5-4 Modelo relacional BBDD .......................................................................................100 Ilustracin 5-5 Diagrama de clases 1................................................................................................103 Ilustracin 5-6 Diagrama de clases 2................................................................................................104 Ilustracin 5-7 Diagrama de clases 3................................................................................................105
XIV
Ilustracin 5-8 Diagrama de clases 4................................................................................................106 Ilustracin 6-4 Cdigo insertar una imagen ....................................................................................110 Ilustracin 6-9 Cdigo enviar correo con adjunto .........................................................................114 Ilustracin 7-1 Prueba aadir asociacin.........................................................................................117 Ilustracin 7-2 Prueba validar asociacin ........................................................................................118 Ilustracin 7-3 Prueba modificar asociacin...................................................................................118 Ilustracin 7-4 Prueba aadir voluntarios .......................................................................................119 Ilustracin 7-5 Prueba aadir voluntarios incorrectos ..................................................................119 Ilustracin 7-6 Prueba consultar asociaciones ................................................................................121 Ilustracin 7-7 Prueba consultar voluntarios ..................................................................................121 Ilustracin 7-8 Prueba modificar asociacin...................................................................................122 Ilustracin 7-9 Prueba consultar voluntarios ..................................................................................123 Ilustracin 8-1 SO para Xampp........................................................................................................135 Ilustracin 8-2 Descargar Xampp.....................................................................................................136 Ilustracin 8-3 Proceso Instalcin Xampp......................................................................................136 Ilustracin 8-4 Ejecucin Xampp.....................................................................................................137 Ilustracin 8-5 Ventana principal navegacin Xampp ..................................................................138 Ilustracin 8-6 Men navegacin Xampp .......................................................................................139 Ilustracin 8-7 Crear una base de datos Xampp ............................................................................140 Ilustracin 8-8 Importar archivo en Xampp...................................................................................141 Ilustracin 8-9 Base de datosXampp ...............................................................................................141 Ilustracin 8-10 Directorios servidor...............................................................................................142 Ilustracin 8-11 Estructura directorios ftp......................................................................................143
XV
Ilustracin 8-12 Estructura directorios 2 ftp ..................................................................................143 Ilustracin 9-1 Pgina Bienvenida aplicacin..................................................................................145 Ilustracin 9-2 Inserccin datos aplicacin.....................................................................................145 Ilustracin 9-3 Pantalla principal administrador.............................................................................146 Ilustracin 9-4 Pantalla Alta asociacin administrador .................................................................147 Ilustracin 9-5 Pantalla modificar asociacin administrador........................................................147 Ilustracin 9-6 Pantalla seleccin asociacin a validar ..................................................................148 Ilustracin 9-7 Pantalla validacin asociacin ................................................................................148 Ilustracin 9-8 Pantalla baja asociacin ...........................................................................................149 Ilustracin 9-9 Pantalla eleccin asociacin a modificar...............................................................150 Ilustracin 9-10 Pantalla modificar asociacin administrador......................................................150 Ilustracin 9-11 Pantalla alta voluntarios administrador...............................................................151 Ilustracin 9-12 Pantalla confirmacin alta voluntarios administrador ......................................151 Ilustracin 9-13 Pantalla alta voluntarios desde archivo ...............................................................152 Ilustracin 9-14 Pantalla error alta voluntario desde archivo.......................................................152 Ilustracin 9-15 Pantalla seleccin asociacin baja de voluntario ...............................................153 Ilustracin 9-16 Pantalla baja de voluntarios ..................................................................................154 Ilustracin 9-17 Pantalla eleccin asociacin modificar voluntarios...........................................154 Ilustracin 9-18 Pantalla seleccin voluntario modificar ..............................................................155 Ilustracin 9-19 Pantalla modificar voluntario ...............................................................................155 Ilustracin 9-20 Pantalla consultar asociaciones ............................................................................156 Ilustracin 9-21 Pantalla asociaciones consultadas ........................................................................156 Ilustracin 9-22 Pantalla consultar voluntarios ..............................................................................157
XVI
Ilustracin 9-23 Pantalla voluntarios consultados..........................................................................157 Ilustracin 9-24 Pantalla principal asociacin.................................................................................158 Ilustracin 9-25 Pantalla modificar asociacin de asociacin.......................................................159 Ilustracin 9-26 Pantalla alta voluntario asociacin.......................................................................159 Ilustracin 9-27 Pantalla confirmacin alta voluntario asociacin ..............................................160 Ilustracin 9-28 Pantalla baja voluntario asociacin......................................................................160 Ilustracin 9-29 Pantalla consultar voluntarios asociacin ...........................................................161 Ilustracin 9-30 Pantalla voluntarios consultados asociacin ......................................................161 Ilustracin 0-31 Diagrama GANTT ................................................................................................162
XVII
ndice de tablas
Tabla 1 Lista de actividades.................................................................................................................39 Tabla 2 Presupuesto detallado de la aplicacin ................................................................................45 Tabla 3 Requisito 001...........................................................................................................................64 Tabla 4 Requisito 002...........................................................................................................................65 Tabla 5 Requisito 003...........................................................................................................................65 Tabla 6 Requisito 004...........................................................................................................................66 Tabla 7 Requisito 005...........................................................................................................................66 Tabla 8 Requisito 006...........................................................................................................................67 Tabla 9 Requisito 007...........................................................................................................................67 Tabla 10 Requisito 008.........................................................................................................................68 Tabla 11 Requisito 009.........................................................................................................................68 Tabla 12 Requisito 010.........................................................................................................................69 Tabla 13 Requisito 011.........................................................................................................................69 Tabla 14 Requisito 012.........................................................................................................................70 Tabla 15 Requisito 013.........................................................................................................................70 Tabla 16 Requisito 014.........................................................................................................................71 Tabla 17. Caso de Uso Alta asociacin..............................................................................................82 Tabla 18. Caso de Uso Validar asociacin ........................................................................................83 Tabla 19. Caso de Uso Baja asociacin..............................................................................................84 Tabla 20. Caso de Uso Modificar asociacin....................................................................................85
XVIII
Tabla 21. Caso de Uso Reenviar clave asociacin............................................................................85 Tabla 22. Caso de Uso Alta voluntario..............................................................................................86 Tabla 23. Caso de Uso Alta Voluntarios desde archivo..................................................................87 Tabla 24. Caso de Uso Baja voluntario..............................................................................................88 Tabla 25. Caso de Uso Fecha baja voluntario...................................................................................89 Tabla 26. Caso de Uso Modificar voluntario ....................................................................................89 Tabla 27. Caso de Uso Consultar asociaciones ................................................................................90 Tabla 28. Caso de Uso Consultar voluntarios ..................................................................................91 Tabla 29. Caso de Uso Modificar asociacin....................................................................................92 Tabla 30. Caso de Uso Alta voluntario..............................................................................................92 Tabla 31. Caso de Uso Baja voluntario..............................................................................................93 Tabla 32. Caso de Uso Fecha baja voluntario...................................................................................94 Tabla 33. Caso de Uso Consultar voluntarios ..................................................................................95 Tabla 34 Descripcin detallada de los atributos de Asociacin ...................................................101 Tabla 35 Descripcin detallada de los atributos de Voluntario ...................................................102 Tabla 36. Resultados de las pruebas.................................................................................................126
XIX
XX
1 Introduccin
En este primer captulo se explican las motivaciones que han llevado a la realizacin de este trabajo as como los objetivos fijados en el mismo. Por otra parte se detalla el contenido de la memoria, explicando los distintos apartados que la componen.
1.1 Motivacin del proyecto

La informacin siempre ha sido uno de los principales activos de las empresas y su gestin uno de los procesos ms importantes. Dichas empresas han utilizado desde libros de registro tradicionales hasta sistemas gestores de bases de datos como Oracle o MS-Access como sistemas de almacenamiento de datos, cada uno con sus caractersticas, pero todos con el mismo fin: llevar un control y clasificacin sobre aquella informacin de se desea guardar. Uno de los problemas de los sistemas antiguos es su capacidad y modo de recuperacin de la informacin. Pongamos un ejemplo de un organismo estatal, como puede ser el registro civil. Antiguamente la informacin de las partidas de nacimiento se almacenaba en libros de registro, clasificados alfabtica y cronolgicamente en estanteras cuya capacidad tena un lmite. Suponiendo el caso en el que alguien quiera acceder a esa informacin, deber dirigirse a la estantera correcta, y posteriormente al archivo concreto que guarde el libro de registro que contiene la partida deseada, lo que conlleva un tiempo innecesario en la era actual. En la actualidad este problema ya ha sido subsanado o est en proceso de serlo, mediante la utilizacin de bases de datos informatizadas. stas permiten almacenar tanta informacin como sea necesaria, lo que conlleva un ahorro importante de espacio fsico, as como proporciona facilidad y agilidad al proceso de consulta de las partidas de nacimiento. Todo ello supone una gran inversin inicial, pero una vez implantado, el ahorro de los costes es incalculable. En la actualidad, existen gran cantidad de casos como este, empresas que por unos u otros motivos no han actualizado su sistema de gestin de base de datos y siguen con sus antiguas tcnicas para almacenar la informacin.
Una de las motivaciones del proyecto, fue la peticin por parte de una empresa de seguros de la realizacin de una aplicacin. La funcin de esta empresa de seguros es la comercializacin de productos de seguros diseados especialmente para el mundo de la discapacidad y el tercer sector. Hasta ahora, esta empresa se encargaba de poner en contacto y administrar los voluntarios de las asociaciones ligadas a ella, con una sociedad de seguros, teniendo para ello que gestionar todos los contratos, certificados y dems documentos manualmente o a travs de ficheros anticuados. La solucin posible a este problema que la empresa presentaba, se plante hacia una mejora en los tiempos de generacin de documentos y altas de los voluntarios. Se quera informatizar estos procesos, y poder delegar ciertas tareas en las mismas asociaciones a las que pertenecan los voluntarios. A su vez, queran tener una base de datos donde almacenar toda la informacin sobre las asociaciones y voluntarios, y que, a travs de una sencilla interfaz, pudiesen gestionarla. La opcin era perfecta para realizar el desarrollo de una aplicacin Web: se trataba de una solucin muy buena para el problema que planteaban y daba la oportunidad de desarrollar por completo, de principio a fin, un proyecto realmente til y remunerado. El principal requisito por parte de la empresa era poder agilizar la emisin de certificados de los voluntarios dados de alta, ya que para ellos supona un gran gasto de tiempo, puesto que por cada voluntario dado de alta deban rellenar un documento Word y mandarlo a la direccin de contacto de la asociacin a la que perteneca el voluntario. Su base de datos estaba informatizada, pero consista en una carpeta dentro de uno de los ordenadores de la empresa, la cual contena un archivo de asociaciones y varios con los voluntarios de cada una, con un descontrol total en el modelo de datos. Otra de las peticiones era disponer de mdulos informatizados donde las asociaciones pudiesen gestionar sus propios voluntarios, descargando as la cantidad de trabajo realizada por esta empresa, ya que lo antes hacan ellos en un largo periodo de tiempo, ahora lo haran las asociaciones en unos minutos. El anlisis, diseo y desarrollo de un sistema Web que cumpla con las necesidades explicadas en este captulo ha constituido la motivacin de este trabajo fin de carrera.
1.2 Objetivos
Dadas las motivaciones expuestas en el anterior apartado, se desea realizar una aplicacin Web para, utilizando Internet como medio de difusin, cubra por completo las necesidades de la empresa demandante. El primer objetivo ser realizar una aplicacin segura y reutilizable a travs del patrn Modelo-Vista-Controlador (MVC), el cual permite implementar de manera independiente las diferentes capas que constituyen dicha aplicacin. Este modelo proporciona una organizacin del diseo del software que aporta independencia entre las capas del mismo (presentacin, control y modelo), lo cual permite aislar los problemas propios de cada capa y resolverlos sin tener en consideracin los dems. Por otra parte la independencia entre capas hace que sean fcilmente sustituibles, evitando dependencias y facilitando la reusabilidad. Como ya se ha indicado, el diseo de la aplicacin se basa en la utilizacin de dicho patrn MVC, que permite separar los datos de una aplicacin, la interfaz de usuario y la lgica de control en tres componentes distintos. Este patrn, est muy extendido en aplicaciones Web, donde la vista es una pgina en HTML, JSP, o cualquier otro lenguaje de programacin Web. El modelo es el sistema de gestin de la base de datos y la lgica de control, mientras que el controlador se har cargo decidir qu componente o componentes resuelve cada uno de los problemas, ya sea de lgica de negocio o de presentacin. Uno de los mayores problemas de los sistemas de gestin de bases de datos es la dificultad que tienen en su manejo, muchos de ellos resultan muy complejos para un usuario inexperto. Muestran una interfaz poco intuitiva y difusa, lo que dificulta an ms su aprendizaje. Hay que suponer que la mayora de los usuarios no tendrn conocimiento alguno sobre estos sistemas, y que lo que buscarn en ellos sern sencillez y claridad en su uso. As pues, el segundo objetivo, es acercar al usuario a travs de una sencilla interfaz, un sistema de gestin de base de datos, eliminando todo aquel proceso que pueda ser complicado y costoso para el usuario. La interfaz se programar en JSP, un lenguaje que permite generar contenido dinmico en las pginas Web. Ser el encargado tanto de recoger los datos introducidos por el usuario, como de mostrarlos por pantalla una vez procesados por el sistema. Se realizar lo ms intuitivo posible, buscando que el tiempo de aprendizaje sea muy bajo, ofreciendo al
usuario un manual de ayuda y gestionando todos aquellos errores que cometa en el uso de la aplicacin. La funcionalidad bsica de la aplicacin ser la siguiente: Gestionar las altas, bajas y modificaciones de las asociaciones Gestionar las altas, bajas y modificaciones de los voluntarios. Generar los certificados, contratos y correos necesarios para la gestin de los seguros. Consultar cualquier informacin referente a las asociaciones y voluntarios.
Finalmente, el ltimo objetivo y ms importante para el cliente, ser reducir lo mximo posible el tiempo de gestin de un voluntario o asociacin. El cliente busca que la aplicacin genere automticamente todo aquello que anteriormente tramitaban de una forma manual y costosa. La generacin de certificados se realizaba de uno en uno, teniendo que crear un nuevo archivo por cada voluntario, rellenarlo y enviarlo a la correspondiente direccin de correo. Igualmente pasaba con los contratos, libros de registro, etc.La aplicacin resolver de la manera ms eficiente posible estos problemas, liberando al usuario de esa carga extra de trabajo que conllevaba estos procesos.
1.3 Contenido de la memoria

En esta memoria se intenta reflejar el contenido del desarrollo de una aplicacin que trata de dar una solucin a un problema a un sistema de gestin de bases de datos. Se ensean tanto los contenidos tericos relaciones con el motivo de la aplicacin, como aquellos procesos concretos desarrollador para hacer efectivos los objetivos fijados inicialmente. La memoria est organizada en los siguientes apartados principales: Resumen: Introduccin a la situacin existente en la gestin de las bases de datos, as como una breve descripcin del trabajo realizado.
Motivacin del proyecto: Se explican las razones que han llevado a realizar este proyecto, por qu puede resultar til, y los posible problemas que puede solucionar. Objetivos: Declaracin de intenciones en la que se indican, de forma concreta, qu productos o conclusiones se desea obtener con la realizacin de este proyecto. Estado del Arte: En este apartado se presenta informacin relacionada con el trabajo. Se explica qu significan los conceptos y tecnologas concretas utilizadas. Tambin se muestra informacin relacionada con soluciones similares o alternativas. Metodologa: Basndose en los estndares mencionados posteriormente, se realiza este apartado. Forma parte de l tambin el ciclo de vida escogido para el desarrollo. Anlisis: Contiene la descripcin completa de la aplicacin, junto con los requisitos detallados que demanda el cliente. Diseo: Este apartado contiene todos los diseos que se han realizado para la aplicacin. Diseo de clases, diagramas de uso, etc. Desarrollo del Proyecto: Compuesto por un conjunto de apartados en los que se trata de explicar los procesos realizados, cmo funcionan y qu objetivos tienen. En estos apartados se detallan tcnicamente las soluciones encontradas as como los problemas surgidos durante el desarrollo y la forma en que estos se han solucionado. Pruebas: Se ha realizado una batera de pruebas formales y son presentadas en este apartado con el fin de certificar el correcto funcionamiento de los procesos desarrollados. Conclusiones y Trabajos Futuros: Indicaciones de cmo y en qu puede el proyecto evolucionar en etapas futuras. Manual de Instalacin: Gua de instalacin de la aplicacin. Manual de Usuario: En el manual de usuario se detalla la funcionalidad implementada en la aplicacin as como el modo en que se ha de utilizar. Bibliografa: Relacin de fuentes documentales ya sean libros, otros trabajos o recursos obtenidos de Internet.
2 Estado del arte

En este captulo se repasan los conceptos utilizados en la realizacin de la aplicacin. En primer lugar se expone una visin global del comercio electrnico as como la evolucin de estos ltimos aos en el desarrollo de aplicaciones Web. Posteriormente se explican brevemente las tecnologas utilizadas como Java, MySQL o JSP, as como otras secundaras que han resultado ser claves en el desarrollo. Se representan tambin otras soluciones alternativas para la realizacin de la aplicacin, exponiendo sus ventajas e inconvenientes si se hubiese adoptado cualquiera de ellas.
2.1 Evolucin de las aplicaciones Web

Se denomina una aplicacin Web a aquellas aplicaciones que permiten al usuario interactuar con ella a travs de un servidor Web, Internet o a travs de una intranet mediante una navegador. Su facilidad en el manejo, actualizacin y mantenimiento, las han convertido en la actualidad en unas de las aplicaciones mas populares y extendidas. Cabe destacar que una de las funciones ms importantes de estas aplicaciones es el intercambio de informacin de una manera activa con el usuario. El usuario interacta con la aplicacin, pudiendo acceder a todo tipo de informacin, como pueden ser blogs, tiendas online, webmail, etc.
2.1.1 Pasado y presente

En un principio, la Web era tan solo una coleccin de sencillas pginas estticas, donde poder obtener cierta informacin para su consulta o descarga. Ms tarde, el primer paso hacia la interactividad con el usuario fueron los Common Gateway Interface (CGI), que defina un mecanismo mediante el que se poda poner en contacto al usuario con el servidor, intercambiando informacin entre ellos. A da de hoy se sigue utilizando los CGI, puesto que supone una manera sencilla de programacin y dan total libertad para utilizarse con otro lenguaje de programacin.
Sin embargo, el funcionamiento de los CGI tienen un grave problema, cada vez que se recibe una peticin, el servidor debe lanzar un nuevo proceso para ejecutar el programa. Como la mayora de los CGI estaban escritos en lenguajes de programacin interpretados, Python, Perl, C, el servidor estaba sometido a una gran carga. Debido a esta situacin, se empiezan a desarrollar otras alternativas para solucionar este problema principal. Surgen dos vas: Se disean nuevos sistemas de ejecucin de mdulos mejor integrados con el servidor, evitando as, la instanciacin y ejecucin de varios programas. Se dota a los servidores de un intrprete de algn lenguaje de programacin para agilizar el proceso de ejecucin y reducir el intervalo de respuesta. Se experimenta as un incremento del nmero de arquitecturas y lenguajes que optan por alguna de estas dos vas que permitan desarrollar aplicaciones Web. Las ms tiles y utilizadas permiten mezclar dos sistemas, un lenguaje integrado que permita al servidor interpretas comandos incrustados en las pginas, y un sistema de ejecucin de programas mejor enlazado con el servidor para evitar los antiguos problemas de los CGI. En la actualidad, una de las ms potentes herramientas utilizadas para el desarrollo de aplicaciones Web es la seguida por Sun Microsystems, Java, que consta de dos componentes: Un lenguaje que permite la incrustacin de cdigo en las pginas HTML que el servidor convierte en programas ejecutables, JSP. Un mtodo que realiza una funcin similar a los CGI y muy ligado al servidor, obteniendo as un rendimiento muy superior, Java Servlet. Otro de los sistemas muy utilizado es el lenguaje PHP, que igualmente, permite incrustar cdigo en las pginas HTML con sintaxis derivada de C y Perl. Es una herramienta sencilla y potente, que en determinados desarrollos puede ser muy til.
2.2 Comercio electrnico

2.2.1 Introduccin
Los mtodos de comercio han ido evolucionando paralelamente a lo largo de la historia a la evolucin humana. A principios de los aos veinte, apareci en Estados Unidos la venta por catlogo, impulsado principalmente por empresas mayoristas. Consiste bsicamente en la venta de productos a travs de un catlogo donde se muestran las fotos de estos, suponiendo un sistema revolucionario para su poca. Mejoraba la compra de los clientes, los que podan elegir los productos a comprar desde su casa, sin presin alguna por parte del vendedor. Adems, supona una ampliacin Adems. Facilitaba la distribucin en zonas rurales, donde los clientes deban hacer un gran desplazamiento para visitar la tienda. La tarjeta de crdito supuso un gran impulso para este tipo de venta, permitiendo el anonimato entre cliente y servidor. A partir de los aos setenta, aparecen las primeras relaciones comerciales que utilizaban el ordenador para el intercambio de datos. No tena ningn estndar por lo que trataron de fijar alguno para realizar este intercambio, lo que trajo consigo una mejora en los procesos de fabricacin en el mbito privado. A mediados de 1980, gracias en gran parte a la televisin, surgi una nueva forma de distribucin de los catlogos, llamada venta directa. Se crea as un nuevo mtodo que permite mostrar los productos con un mayor realismo y dinamismo, pudiendo resaltas las caractersticas con mayor facilidad. La compra de estos productos se hacan mediante una linea telefnica y los pagos a travs de una tarjeta de crdito. En 1995, los pases integrantes del G7/G8, crean la iniciativa Un mercado global para PYMES, con el propsito de acelerar el uso del comercio electrnico entre las empresas. Ventajas para los clientes. Mejorar en la distribucin. El cliente puede ponerse en contacto directo con el proveedor del producto, evitando as a los intermediarios, por lo que los costos tienden a cero. Esta situacin puede llegar a reducir los canales de
comercializacin, permitiendo que su distribucin sea eficiente reduciendo sobrecostos. Tambin se reducen tiempos en las transacciones comerciales. Comunicaciones de mercadeo. Actualmente, la mayora de las empresas disponen de una pgina Web donde informar de los productos o servicios a sus clientes. Esta situacin potencia las relaciones con los clientes, traducindose en una facilidad de mercadeo y de soporte al cliente nunca imaginado. Los clientes pueden utilizar la Web las 24 horas del da, y estar contactados con el vendedor a travs de correo electrnico. Los sitios Web ms sencillos utilizan correo electrnico para establecer una comunicacin cliente-servidor. En otros sitios ms sofisticados, se utilizan formularios con el objeto de que desarrollen una relacin continua con la compaa. Beneficios operacionales. El uso de la Web, reduce tiempo, errores y sobrecostos. Los proveedores disminuyen sus costos al acceder directamente a la base de datos. Se facilitar la creacin de mercados y nuevos segmentos, especialmente en los geogrficamente remotos. Clasificacin del comercio electrnico El comercio electrnico puede dividirse en cuatro categoras segn sus entidades relacionadas. Compaa Compaa (B2B). Una compaa hace uso de una red para ponerse en contacto con sus proveedores y gestionar sus facturas y pagos correspondientes. Este tipo de comercio ha sido utilizado muchos aos a travs de EDI sobre redes privadas o de valor agregado. Compaa Cliente (B2C). El cliente realiza sus compras a travs de los sitios Web de las compaas. Este tipo ha tenido gran aceptacin debido a la existencia de grandes centros comerciales por todo Internet. Compaa Administracin (B2G). Se refiere a todas las transacciones llevadas a cabo entre las compaas y las organizaciones del gobierno. Todava esta en sus inicios, pero a medida que el gobierno empiece a hacer uso de este comercio, el comercio electrnico alcanzara su mayor potencial
9
Cliente Administracin (C2G). Aun no ha nacido, sin embargo, el gobierno tiene previsto esta expansin para efectuar interacciones electrnicas como seran pagos de asistencia social o devolucin de impuestos.
Riesgos Se pueden presentar los siguientes deficientes tanto por su naturaleza como de su tecnologa. Entorno empresarial y tecnolgico cambiante. Empresas y clientes quieten tener flexibilidad para cambiar de socios sociales, plataformas y redes. Una empresa como mnimo deber disponer de un ordenador con conexin a Internet. Si desea involucrarse ms, deber introducir un sistema como EDI con sus proveedores y/o una intranet con sus diversas sedes. Privacidad y seguridad. La mayora de los usuarios desconfa de las transacciones Web como canal de pago. Existen sistemas que funcionan correctamente para operaciones comerciales muy altas, sin embargo, los problemas se centran en las operaciones pequeas. Cuestiones legales, polticas y sociales. Validez de la firma, no repudio, legalidad de un contrato electrnico, etc.
Tecnologas empleadas El comercio electrnico utiliza un amplio rango de tecnologas.

Intercambio Electrnico de Datos (EDI-Electronic Data Interchange) Correo Electrnico (E-mail o Electronic Mail) Transferencia Electrnica de Fondos (EFT- Electronic Funds Transfer) Aplicaciones Internet: Web, News, Gopher, Archie Aplicaciones de Voz: Buzones, Servidores Transferencia de Archivos
10
Diseo y Fabricacin por Computadora (CAD/CAM) Multimedia Tableros Electrnicos de Publicidad Videoconferencia
2.2.2 Evolucin y caractersticas del modelo B2B

Al principio de los aos setenta, en Estados Unidos, las innovaciones como la Transferencia Electrnica de Fondos (EFT) y el Intercambio Electrnico de Datos (EDI), cambiaban la forma de operar de las grandes compaas, instituciones y algunas pequeas empresas. En los aos noventa, y con los primeros navegadores de Internet, permitan visionar pginas en formato HTML. El objetivo principal era publicar textos planos que permitan compartir informacin con usuarios en distintas ubicaciones geogrficas. En 1996, compaas estadounidenses dedicadas a los servicios de mensajera, comenzaron a llevar sus bases de datos a Internet, para beneficio de sus clientes, rompiendo con el paradigma de que dichas bases no deban salir de la compaa por motivos de seguridad. Los clientes comenzaron as a realizar y esperar envos, teniendo la posibilidad de conocer en tiempo real la ubicacin de sus paquetes. Fue asi como da comienzo una nueva forma de hacer negocios entre compaas, los modelos B2B del comercio electrnico, caracterizndose porque su aplicacin se realiza entre empresas. En el B2B, la empresa que compra puede utilizar los bienes o servicios para ofrecerlos al consumidor final, o bien para producir otro bien y ofrecerlo a otro mercado. Algunas de las aplicaciones de los sistemas B2B son las siguientes: Vender y distribuir productos a otros negocios. Llevar a cabo de forma sistemtica el suministro de bienes.
11
Proveer la logstica necesaria para colocar los productos correctos en un tiempo ptimo dentro de una organizacin.
Ofrecer un soporte de ejecucin de actividades de mercadotecnia y publicidad. Ofrecer el adecuado servicio para diferentes reas funcionales. Generar informacin para pronsticos.
Ventajas del modelo B2B. Permite automatizar las relaciones comerciales entre empresas (Proveedores y Compradores). Rapidez y seguridad en las comunicaciones. Integracin directa de los datos de la transaccin en los sistemas informticos de la empresa. Posibilidad de incrementar el nmero de de ofertas y demandas. No existe trato con el comprador o vendedor, por lo que no existen tratos de favor. Abaratamiento del proceso, agilizando el proceso de negociacin y reduciendo las visitas comerciales. Ventajas para el comprador Aumento de sus fuentes de suministro. Disminuye el plazo entre solicitud y recepcin. Reduce los costos por transaccin. Descienden las compras fuera de contrato. Aumento de control sobre el proceso de aprovisionamiento.
Ventajas para el proveedor Incremento de la base de clientes potenciales.
12
Aumento de la fidelidad de sus clientes gracias a la reduccin de barreras de salida.
Reduccin de la carga administrativa.
Seguridad en las transacciones B2B El importe unitario en las transacciones B2B es muy alto, lo que hace a este tipo de comercio online especialmente apetecible para piratas informticos. Es aqu donde se requieren productos de autenticacin fuertes que permitan dotar de la seguridad y flexibilidad a los mecanismos transaccionales de Internet. Para ello, los Cdigos de Conducta para el comercio electrnico B2B, deberan contener al menos: El mbito del cdigo de conducta. El cdigo habra de indicar quien ha participado en la elaboracin del mismo, adems de indicar, bajo qu formulas comerciales es aplicable. Informacin sobre el e-market. Para que las empresas puedan distinguir entre mercado acreditados y econmicamente solventes, se ha de facilitar a las mismas, informacin real acerca de los aspectos financieros y legales de cada mercado electrnico. Es fundamental el papel que juega la transparencia en este sentido. Informacin sobre los participantes. Podra vulnerar ciertas reglas sobre la competencia y las leyes del libre mercado, pero la informacin acerca de las empresas participantes es fundamental para acreditar cierto nivel de seguridad. Informacin sobre el modelo procedimental en las transacciones. Debera definir, cuando y como cada contrato es perfeccionado y que criterios son relevantes para concluir una transaccin. Informacin sobre el mecanismo de fijacin de precios. La claridad en este apartado ayudara a los participantes a eliminar potenciales preocupaciones acerca de practicas que puedan manipular los precios siempre y cuando las leyes referentes a la libertad del mercado sean respetadas.
13
Informacin sobre proteccin de la privacidad y confidencialidad. Se deberan incluir mecanismos que aseguren a los usuarios que la informacin personal proporcionada esta perfectamente asegurada de acuerdo con la Ley de Proteccin de Datos.
Informacin sobre frmulas de resolucin de conflictos. Es importante que se pueda acudir a un mecanismo alternativo de resolucin de conflictos en caso de un eventual conflicto, siendo tambin de gran importancia que se especifiquen los procedimientos a seguir.
Ley aplicable. Es importante que las partes hayan determinado con anterioridad bajo qu ley han de solucionar los posibles conflictos que surjan durante la transaccin.
2.2.2.1 Intercambio electrnico de documentos (EDI)

Con el fin de acreditar la validez legal y fiscal de los documentos intercambiados surge la opcin de utilizar EDI. EDI es el intercambio electrnico de datos entre sistemas de informacin, por medios electrnicos, de datos estructurados de acuerdo con normas de mensajes acordadas. A travs de EDI, las partes cooperan sobre un entendimiento claro y predefinido acerca de un negocio comn. Las interacciones tienen lugar por medio de aplicaciones informticas que actan como una interfaz con los datos locales, pudiendo intercambiar informacin comercial estructurada. EDI, establece como se estructuran los datos de los documentos electrnicos y define el significado comercial de cada elemento de datos. Para transmitir la informacin necesita un servicio de transporte adicional. EDI respeta en todo momento la autonoma de las partes involucradas. Los tpicos campos de aplicacin del EDI son el intercambio de informacin industrial, financiera, mdica, administrativa o cualquier otro tipo similar de informacin estructurada. Esta informacin, se estructura en unos formatos que pueden ser procesados por aplicaciones informticas.
14
La automatizacin de las interacciones por medio de EDI minimiza las transacciones sobre el papel y la intervencin humana, pudiendo incrementar la eficiencia de las tareas diarias y mejorar las relaciones con agentes externos. Los clientes potenciales de EDI son muchos, debido a que esta dirigido a empresas que se relacionan comercialmente. Sector Distribucin (Supermercados, Proveedores). Sector de las Automotrices (Terminales, Proveedores y Concesionarios). Sector Farmacutico (Farmacias, Laboratorios). Sector de la Administracin Publica. Sector del Transporte y Turismo.
Transmisin de documentos entre empresas El sistema tradicional en el que las empresas basan su transmisin de documentos, el papel, presenta dos grandes inconvenientes. En primer lugar, la lentitud. Documentos generados en potentes ordenadores que procesan informacin a gran velocidad, sufren retrasos por tener que procesarse de forma manual en las empresas de correos. Por este motivo, muchas empresas han sustituido el correo como medio de transmisin para enviar documentos, por el fax, lo que agiliza en buena medida la gestin. Sin embargo, existe otro problema, los diversos tipos de facturas, pedidos, hojas de precios, etc. Esta falta de normalizacin es causa de muchos errores administrativos. A continuacin se muestre el procedimiento convencional de transmisin de documentos administrativos entre empresas.
15
Sistema informatico cliente
Extrae datos e imprime
Documento impreso
Documento impreso
Captura datos y procesa
Sistema informtico proveedor
Ilustracin 2-1 Transmisin de documentos convencional
La primera empresa consulta la base de datos y extrae e imprime la informacin necesaria. Esta informacin, se enva por correo electrnico a la otra empresa, quien debe de introducir de nuevo los datos en su sistema informtico. En este sistema se producen redundancias, ya que los documentos que se imprimen en una empresa, son introducidos manualmente en el sistema informtico de la otra.
16
Servico de transporte
Empresas
Mensajes Servicios sociales EDI EDI Proveedores
Servicios medicos
Administrraci on publica
Ilustracin 2-2 Transmisin de datos EDI
Esta figura representa a grandes rasgos lo que supone implantar un sistema EDI. Consiste simplemente en implantar un procedimiento electrnico de transmisin de informacin. Las empresas se beneficiaran de este sistema con diversas formas de ahorro. En primer lugar un ahorro de tiempo, ya que la informacin viaja por redes de comunicacin. Y en segundo lugar, se producen menos errores, ya que el proceso esta completamente automatizado. Beneficios EDI Agilizacin de procesos comerciales. Disminucin de errores en los documentos. Disminucin de stocks debido a la facilidad de aplicacin de tcnicas just in time. Ahorro de costos de administracin. Mejora de la competitividad de la empresa que lo usa.
17
2.3 Conceptos tcnicos

2.3.1 MVC
Se trata de un patrn de arquitectura de software que divide en tres componentes la creacin de una aplicacin. Por un lado los datos (modelo), por otro la interfaz de usuario (vista) y finalmente la lgica de control (controlador). Modelo: Representacin especfica con la que el sistema interacta. Es el
responsable de acceder a la capa de almacenamiento de datos, define las reglas de negocio y lleva un registro de las vistas y controladores del sistema. Vista: Define la interfaz de usuario, mostrndole la informacin del modelo.
Recibe los datos del modelo y los muestra al usuario, tienen un registro de su controlador asociado y pueden ofrecer el servicio de actualizacin. Controlador: Responde a eventos y modifica la vista y el modelo. Recibe los
eventos de entrada y contiene las reglas de gestin de estos. El flujo de control suele seguir este procedimiento: El usuario interacta de alguna manera con el interfaz. El controlador recibe la peticin del usuario y la gestiona. El controlador accede al modelo y realiza la funcin requerida por el usuario
(actualizacin, modificacin.). La vista obtiene los datos y los muestra al usuario. La interfaz espera nuevas acciones por parte del usuario.
18
Ilustracin 2-3 Modelo Vista Controlador
2.3.2 JAVA
Lenguaje de programacin orientado a objetos desarrollado por Sun Microsystems. Permite una programacin ms sencilla que otros lenguajes orientados a objetos puesto que elimina herramientas de bajo nivel como puede ser la manipulacin directa de punteros o memoria. Generalmente es compilado en un bytecode, aunque es posible crear cdigo mquina nativo. En el tiempo de ejecucin, el bytecode es normalmente interpretado o compilado a cdigo nativo para la ejecucin, aunque tambin existen dispositivos hardwares capaces de ejecutarlo directamente. Sun Microsystems desarrollo en 1995 el compilador, la mquina virtual y las bibliotecas de clases, y desde entonces controla el desarrollo y la evolucin del lenguaje a travs del Java Community Process. La mayora de las tecnologas Java fueron liberadas entre el 2006 y 2007, convirtindose as prcticamente en su totalidad en software libre. Java fue diseado para ser:
19
Sencillo, orientado a objetos y familiar. Fcil de aprender para los desarrolladores, orientado a objetos por ser una tecnologa ms madura y mejor para los sistemas distribuidos y cliente/servidor, y familiar por mantener gran parecido con C++, eliminando bastantes de sus complejidades.
Distribuido. Java proporciona clases y herramientas para su uso en aplicaciones de red. Robusto y seguro. Robusto por simplificar la manipulacin directa de punteros y gestin de memoria, y seguro para operar en los entornos de red. Independiente de la arquitectura y portable. El compilador de Java genera un bytecode, formato de cdigo independiente de la plataforma, e interpretable por diversas plataformas de hardware y sistemas operativos. Portable por ser el mismo lenguaje en todas las plataformas, lo nico que diferencia a estas es su Java Virtual Machine.
Alto rendimiento. Java es un lenguaje interpretado, sin embargo, tiene en cuenta el rendimiento, y en las ltimas versiones a puesto a disposicin herramientas de optimizacin.
Interpretado, multi-hilo y dinmico. Interpretado por generar un bytecode ejecutable en cualquier mquina con Java Virtual Machine. Java soporta mltiples hilos de ejecucin. Proporciona mecanismos de carga dinmica y ejecucin en la fase de enlazado.
Permite generar varios tipos de aplicaciones: Aplicaciones autnomas. Applets. Programas incrustados en otras aplicaciones. Servlets. Componentes de la parte de servidor de Java EE, genera respuestas a las peticiones de los clientes (detallado ms adelante). Aplicaciones con ventanas. Usando la interfaz grfica de Java.
El diseo de Java ofrece varios entornos de funcionamiento, entre los que se encuentran: Dispositivos mviles y sistemas empotrados. En navegador web.
20
En sistemas de servidor. En aplicaciones de escritorio.
Para ejecutar Java, es necesario el JRE (Java Runtime Environment), que incluye la Java Vitual Machine y la Api. Esta incluida en cualquier versin de J2SE (Java 2 Estndar Edition), aunque si tan solo se quiere ejecutar la aplicacin Java, con el JRE ser suficiente, instala los plugins necesarios para su ejecucin en los navegadores y sistemas operativos. Para el desarrollo de aplicaciones, se necesita otro tipo de paquete, donde el J2SE es el ms usado, aunque existen otro tipo de paquetes que permiten el desarrollo de otro tipo de aplicaciones, ejemplo de ello son: Java SE. Edicin estndar de Java. Java EE. Aplicaciones distribuidas orientadas al entorno empresarial. Java ME. Dispositivos mviles, PDA, telfono Java FX. Permite crear aplicaciones dinmicas de nueva generacin. Cada una de ellas posee una API, conjunto de clases, interfaces y excepciones requeridas para el desarrollo de aplicaciones en cada plataforma. A su vez, tambin existen paquetes creados externos a los oficiales, pero que amplan el uso y desarrollo del lenguaje (JavaMail, IText). En cuanto a las crticas posibles del lenguaje, se pueden encontrar algunas: No es un lenguaje estrictamente orientado a objetos. El cdigo puede ser redundante en comparacin con otros lenguajes. No dispone de operadores de sobrecarga definidos por el usuario. Rendimiento algo bajo comparado con otros lenguajes.
2.3.3 SERVLETS
Los servlets son mdulos de Java que se ejecutan en el servidor o contenedor J2EE, expandiendo as las capacidades de los servidores Web. Se dice de ellos que son la siguiente
21
etapa de los CGI, ya que su funcin ms tpica es generar pginas web dinmicas a partir de los parmetros de la peticin que enve el navegador. Los servlets implementan la interfaz javax.servlet.Servlet, permitiendo interpretar objetos del tipo HttpServletRequest/Response, contenedores de la informacin de la pgina que ha invocado al servlet. HttpServletRequest representa el la comunicacin desde el cliente al servidor, mientras que HttpServletResponse representa la comunicacin inversa. El ciclo de vida del servlet se puede dividir en las siguientes fases: El cliente realiza una peticin. Si es la primera vez que se recibe la peticin, el servlet ejecutar el mtodo de inicio init(), inicializando las variables generales. Si no es la primera vez, cada peticin se convierte en un nuevo hilo. Dependiendo de la peticin, se ejecutar el mtodo doGet() o doPost(), generando el resultado a devolver. Finalmente el servlet eliminar todos los datos generados llamando al mtodo destroy().
Ilustracin 2-4 Diagrama Servlets
22
2.3.4 MySQL
MySQL es un sistema de gestin de base de datos relacional muy rpido, multihilo, multiusuario y robusto. Esta diseado para entornos de produccin crticos, con alta carga de trabajo. Consta de una doble licencia, una totalmente gratuita bajo los trminos de la licencia GNU Genral Public License u otra bajo una licencia comercial estndar de MySQL AB. Consulte. Las principales caractersticas son: Es un sistema de gestin de bases de datos. Es un sistema de gestin de base de datos relacionales. Es Open Source. El servidor de base de datos es muy rpido, fiable y fcil de usar. Trabaja en entornos cliente/servidor o incrustados. Existe una gran cantidad de software que utiliza este sistema.
Al ser una base de datos muy rpida en la lectura, es ideal para utilizarla en la creacin de aplicaciones web, muy utilizada en conjunto con PHP.
2.3.5 JSP
Es una tecnologa de Java orientada a la creacin de contenido dinmico para las pginas web. Se podran considerar como una manera alternativa y sencilla de construir servlets, adems de poder utilizarse como Vista, dentro del Modelo Vista Controlador, encargndose de recibir los parmetros desde el servlet y mostrndolos al usuario, y de recoger las peticiones del usuario y llevarlos al servlet. Al tratarse de una tecnologa Java, se puede utilizar en cualquier mquina siempre que tengan instalado la mquina Virtual de Java. Permite agregar etiquetas XML, llamadas acciones, adems de poder utilizar y crear bibliotecas de etiquetas JSP .
23
Un JSP es compilado a un programa en Java la primera vez que se invoca, de este programa se crea una clase que se ejecuta en el servidor como si se tratase de un servlet, siendo la diferencia con estos, que un JSP es una pgina Web con etiquetas y cdigo Java incrustado (script), mientras que un servlet es un programa que recibe peticiones y genera respuestas a partir de ellas.
2.3.6 APACHE TOMCAT

Tomcat es un servidor web capaz de soportar Servlets y JSP. Funciona como un contenedor de servlets, pero no como un servidor de aplicaciones, pudiendo dividir los contenedores en: Contenedores de Servlets independientes. Son una parte integral del servidor web. Sin embargo, no es lo ms comn, ya que la mayora de servidores no estn basados en Java. Contenedores de Servlets dentro de proceso. Es una combinacin de plugin para el servidor y una implementacin de contenedor Java. El plugin abre una maquina virtual de Java dentro del espacio de direcciones del servidor permitiendo que el contenedor se ejecute en l. Contenedores de Servlets fuera de proceso. Es una combinacin de plugin para el servidor y una implementacin del contenedor Java que se ejecuta es una mquina virtual de Java externa.
2.3.7 JavaMail
Adicionalmente al API Estndar de Java se puede encontrar esta expansin que permite el envo y recepcin de correos electrnicos. Este paquete es usado para crear programas del tipo MUA (Mail User Agent), cuya principal funcin es conectar con los programas MTA (Mail Tranfer Agent) para el envo y recepcin del correo.
24
Permite gestionar cualquier tipo de correo a travs de cualquier tipo de protocolo (POP, IMAP, SMTP, MIME), pudiendo crear mensajes de texto plano o HTML, adems de aadir imgenes, archivos adjuntos, etc.
2.3.8 IText
IText es una librera de Java con la que poder generar documentos PDF de forma dinmica, tanto en aplicaciones de escritorio como aplicaciones web. Algunas de las posibilidades que ofrece son: Generar dinmicamente documentos usando archivos XML o Bases de datos. Manipular documentos ya creados. Agregar ndices, nmeros de pgina, marcas de agua
2.4 Comparativa de las tecnologas disponibles

Actualmente, existe un gran abanico de posibilidades a la hora de afrontar un desarrollo Web. Todas ellas pretenden proporcionar caractersticas avanzadas a las pginas Web con el fin de cubrir las amplias necesidades de los usuarios, basndose en el esquema cliente-servidor. La navegacin Web ha evolucionado a pasos agigantados en los ltimos aos, haciendo que los diseadores y programadores requieran herramientas ms potentes, dejando a un lado los diseos estticos basados en HTML. El resultado de esta evolucin es la gran cantidad de herramientas que se pueden encontrar para crear pginas muy potentes y dinmicas (CGI, JSP, PHP, ASP) Breve Descripcin de cada tecnologa. CGI: Mediante el uso de los Common Gateway Interface, los desarrolladores pudieron acceder a un mundo nuevo donde poder crear aplicaciones del lado del servidor y acceder a ellas a travs de un navegador. Supuso un gran avance, pero su problema era su rendimiento, era demasiado bajo ya que cada acceso requera un nuevo proceso en el servidor.
25
PHP: Es un lenguaje desarrollado por Rasmus Lerdorf en 1984 como un CGI escrito en C, permitiendo la interpretacin de nmero limitados de comandos. Es de libre distribucin, y desde su versin 4 pasa a ser un lenguaje interpretado, bastante rpido. Es sencillo, sintaxis cmoda, pudindose instalar en servidores gratuitos y asocindose con MySQL proporciona una gran potencia a la hora de desarrollar pginas Web. Como principal inconveniente tiene varios Bugs de seguridad.
ASP: En 1996 Microsoft lanza ASP, con sintaxis y funcionamiento parecido a PHP, ofreciendo la ventaja de utilizar el concepto de objetos COM. Su principal problema es que solo permite su uso en plataformas Microsoft, limitando su portabilidad.
JSP: Usa cdigo HTML junto con cdigo Java, siendo parecido a los lenguajes anteriores, separando claramente qu es contenido y qu es presentacin. Reusa componentes basados en JavaBeans, y permite el uso de XML en los scripts.
Servltes: Mdulos de Java que se ejecutan en el servidor o contenedor JEE, expandiendo as las capacidades de los servidores Web. Se dice de ellos que son la siguiente etapa de los CGI, ya que su funcin ms tpica es generar pginas Web dinmicas a partir de los parmetros de la peticin que enve el navegador. Los CGI fueron los primeros en aparecer, siendo as los ms antiguos y desfasados. JSP, ASP y PHP, son lenguajes enfrentados entre s. PHP es gratuito, fcil y rpido. Est continuamente en revisin y actualizacin. Es de cdigo abierto y portable. ASP. Ni es portable, ni de cdigo abierto, ni gratis. Tiene soporte de Microsoft. JSP. Portable, no es de cdigo abierto, gratis y muy seguro.
2.4.1 Comparativa JSP y ASP

JSP es portable, por lo que se puede ejecutar en cualquier sistema operativo y servidor Web, al contrario de ASP, que solo permite su ejecucin en sistemas Microsoft y servidores muy concretos. JSP cuenta con una extensa API y comunidad Java. ASP tan solo cuenta con Microsoft para sus desarrollos.
26
JSP Y ASP utilizan una combinacin de TAGS y SCRIPTS para dar dinamismo a las pginas. JSP es independiente de la plataforma, los componentes son reutilizables tanto en Unix como Windows por ejemplo. ASP no lo permite. JSP utiliza como lenguaje Script Java, mientras que ASP utiliza VBScript o JScript. Java es mucho ms seguro, fcil y potente que el resto de los lenguajes Script. Si lo que se desea es disear son pequeas aplicaciones, los lenguajes Script son una posible alternativa, sin embargo, para aplicaciones grandes y bien estructuradas, la mejor opcin vuelve a ser Java. El uso de JSP se hace bastante claro respecto a ASP, siendo las dos ventajas ms
claras el uso de Java para la parte dinmica, y la portabilidad hacia otros sistemas operativos y servidores.
2.4.2 Comparativa PHP y JSP

Tanto JSP como PHP son portables. PHP es de cdigo abierto, mientras que JSP no. JSP permite crear nuevos TAGS mientras que PHP al igual que ASP no lo permite. Java sigue siendo mucho ms completo y estructurado que cualquier otro lenguaje Script. La orientacin a objetos en PHP an no es tan slida como en Java. Decantarse por uno de estos dos lenguajes es algo ms complicado, ya que no existen tantas diferencias y las ventajas de uno sobre otro no marcan una clara prioridad, sin embargo, Java es un lenguaje robusto, potente, bien estructurado, y de fcil comprensin, por lo que sera un posible motivo para decantarse por JSP. Finalmente, la eleccin elegida para el desarrollo del proyecto ha sido: Java. Se trata de un lenguaje de programacin multiplataforma, permite ser ejecutado en cualquier mquina, tan solo se debe tener la JVM. Es un lenguaje robusto y sencillo, con la ventaja de que se conoca previamente al inicio del
27
proyecto, por lo que el aprendizaje fue muy corto en este aspecto. Es ms fiable que otros lenguajes, y permite la gestin de excepciones de una manera sencilla, labor que en este proyecto ha tenido que ser tratada de una maneara exhaustiva. Jsp. La utilizacin de Jsp viene en gran parte originada por la eleccin de Java. Se trata de un lenguaje compuesto de HTML/XML y scripts de Java, integrndose perfectamente con este ltimo. En el proyecto, ha sido fundamental para la representacin de los datos y su recogida. Al igual que Java, es portable e independiente de la plataforma, y tiene un API mucho mayor que cualquier otro lenguaje posible a utilizar en este aspecto. MySQL. Es un sistema de gestin de base de datos relacional muy rpido, multihilo, multiusuario y robusto. Permite altas cargas de datos, y es totalmente gratuito. Existen varias API que permiten acceder a las bases de datos desarrolladas en MySQL.
28
3 Metodologa
Para la realizacin de esta seccin, se han utilizado los estndares IEEE-1058 y IEEE1074 como gua, sin ceirse con exactitud a la metodologa de cada uno.
3.1 Modelo de Ciclo de vida Software

Todo proyecto de ingeniera tiene unos fines ligados a la obtencin de un producto o servicio que es necesario generar a travs de diversas actividades. Algunas de estas actividades pueden agruparse en fases porque globalmente contribuyen a obtener un producto intermedio, necesario para continuar hacia el producto final y facilitar la gestin del proyecto. Al conjunto de fases empleadas se le denomina ciclo de vida. El ciclo de vida va unido al desarrollo del software, comprendiendo una seria de etapas que comprenden todas las actividades, desde el primer momento en el que se decide crear un nuevo producto, hasta el momento en el que se dispone a disposicin de los usuarios. Segn la normativo ISO 12207 1, el ciclo de vida software se define como Un marco de referencia que contiene los procesos, las actividades y las tareas involucradas en el desarrollo, la explotacin y el mantenimiento de un producto software, abarcando la vida del sistema desde la definicin de los requisitos hasta la finalizacin de su uso.
3.1.1 Objetivos
La definicin de un ciclo de vida facilita: El control sobre los tiempos necesarios para aplicar recursos de todo tipo Control del trabajo subcontratado Control de calidad, siempre que la separacin entre fases se haga corresponder con puntos en los que esta deba verificarse Para el desarrollo del proyecto, se ha escogido el ciclo de vida en cascada.
29
3.1.2 Elementos de un ciclo de vida

Un ciclo de vida esta compuesto por fases sucesivas compuestas a su vez por tareas planificables. Segn el modelo de ciclo de vida, se puede componer tambin de bucles de realimentacin, de manera que una misma fase pueda ser ejecutada ms de una vez a lo largo del proyecto. Para un adecuado control de la progresin del proyecto, es necesario especificar con precisin los productos intermedios que resultan de cada fase. Estos productos marcan los hitos entre las fases. Fases. Una fase es un conjunto de actividades relacionadas con un objetivo en el desarrollo del proyecto. Se construye agrupando tareas que pueden compartir un tramo determinado del tiempo de vida de un proyecto. La agrupacin temporal de tareas impone requisitos temporales correspondientes a la asignacin de recursos. Cada fase viene definida por un conjunto de elementos observables externamente, como son las actividades con las que se relacin, los datos de entrada, los datos de salir y la estructura interna de la fase. Entregables. Son los productos intermedios que generan las fases. Pueden ser materiales o inmateriales. Los entregables permiten evaluar la marcha del proyecto mediante comprobaciones de su adecuacin o no a los requisitos funcionales y de condiciones de realizacin previamente establecidos. Cada una de estas evaluaciones puede servir para la toma de decisiones a lo largo del desarrollo del proyecto.
3.1.3 Modelo Ciclo de vida software en Cascada

En el modelo de ciclo de vida en Cascada, el proceso de desarrollo de software es disciplinado y planeado, en el que la implementacin debe posponerse hasta que los objetivos se hayan comprendido. Se distinguen principalmente las siguientes fases:
30
Anlisis. Se analizan las necesidades de los usuarios finales, con el fin de determinar los objetivos a cubrir. En esta fase se crea una memoria llamada SRD (Documento de Especificacin de Requisitos), que contiene la especificacin completa de lo que el sistema debe hacer sin entrar en detalles.
Diseo. Se descompone y organiza el sistema en elementos que puedan elaborarse por separada, con el fin de aprovechar las ventajas del equipo de desarrollo. Se crea el documento SDD (Documento de Diseo de Software), que contiene la descripcin de la estructura global del sistema y detalla qu debe hacer cada una de sus partes, as como la combinacin con otras.
Codificacin. Bsicamente es la fase de programacin. Se desarrolla el cdigo fuente, haciendo uso de pruebas y ensayos para corregir posibles errores.
Integracin. Se ensamblan los elementos ya programadas para componer el sistema, comprobando el buen funcionamiento de este antes de pasar a su explotacin.
Mantenimiento. Fase destinada a corregir errores o introducir mejoras a lo largo de la explotacin del sistema. Se recoge en el Documento de Cambios.
Captura y Anlisis de Requisitos Diseo del sistema Implementacin y Pruebas Integracin y Pruebas Operacin y Mantenimiento
Ilustracin 3-1 Ciclo de vida en cascada
31
Es un modelo descendente, que exige para pasar a la siguiente fase exige la conclusin de la fase anterior correctamente. La salida de una fase es la entrada de la siguiente.
3.2 Plan de proyecto

3.2.1 Resumen del proyecto
3.2.1.1 Propsito, alcance y objetivos
El propsito del proyecto es realizar una aplicacin que permita la gestin de los voluntarios y asociaciones que hayan contratado a travs de la empresa alguno de los seguros ofrecidos por esta, facilitando la generacin de los certificados y correos pertinentes. A su vez, la empresa desea en un futuro desarrollar otra aplicacin con grandes similitudes a esta para gestionar seguros de aviacin. Para ello, el programa ser lo ms genrico posible para permitir los posibles proyectos futuros. La aplicacin tratar las siguientes necesidades: Gestin de las asociaciones. Debe gestionar todas las asociaciones contratantes de seguros a travs de la empresa. Se podrn realizar las siguientes acciones: Dar de alta una nueva asociacin. En un primer lugar se introducirn los datos disponibles de la asociacin. Una vez que esta valide la informacin, se proceder a dar de alta a la asociacin en el sistema. Modificar los datos de una asociacin. Se podr modificar cualquier dato de la asociacin, siempre y cuando esta este de acuerda. Dar de baja una asociacin. A peticin de la asociacin, se podr realizar su baja en el sistema. Consultar datos de las asociaciones. Se tendr acceso a cualquier dato de las asociaciones.
32
Gestin de voluntarios. Permitir la gestin de los voluntarios pertenecientes a las asociaciones previamente dadas de alta. Dar de alta voluntarios. Se facilitar el alta y la creacin de los certificados individuales de cada voluntario. Modificar informacin de los voluntarios. A peticin de la asociacin, se podr modificar cualquier campo de los voluntarios. Dar de baja voluntarios. Los voluntarios podrn ser eliminados en cualquier momento del sistema. Establecer fecha de vencimiento del seguro, fecha de baja. Cada voluntario tiene su fecha de baja o vencimiento del seguro contratado, teniendo que ser esta establecida por las asociaciones. Consultar datos de los voluntarios. Acceso total a los datos de los voluntarios pertenecientes a cada asociacin.
El alcance del proyecto agrupa las siguientes fases: Planificacin y requisitos Diseo Implementacin Integracin y pruebas
La aplicacin dispone de una pgina de ayuda donde poder consultar las acciones disponibles y el modo de ejecucin de cada una de ellas. Una vez entregada la aplicacin, se deber instalar en el servidor para su completo funcionamiento, y habiendo comprobado que no genera ningn tipo de error durante un tiempo determinado, se evitar el futuro mantenimiento de esta.
33
3.2.1.2 Restricciones y supuestos

Se determinan las siguientes restricciones y supuestos respecto a los diferentes campos, siendo los siguientes: Calendario: Como fecha lmite se establece diciembre del mismo ao, mes en el que vencen los seguros contratados y se deben realizar las siguientes plizas. Presupuesto: Se acuerda un presupuesto mximo de 2000 euros para la realizacin de todas las etapas del proyecto. Recursos: No se impone ninguna restriccin sobre los recursos a utilizar. Software propio reutilizado: El proyecto se realiza desde cero, por lo que no se utiliza software anterior. Tecnologas a contratar: No es necesario contratar ninguna, puesto que todas las utilizadas son software libre. Se pueden adquirir a travs de Internet, siendo las descargas y su posterior instalacin gratuitas. La aplicacin creada tendr como objetivo poder ser reutilizada para la creacin de otra aplicacin sobre seguros de aviacin. Deber ser instalada en un servidor que permita la utilizacin de JSP y MySQL. En relacin al software y hardware necesario por parte de la empresa para utilizar la aplicacin, con una conexin a Internet y un navegador es suficiente.
34
3.2.1.3 Entregables del proyecto

El proyecto est dirigido a un cliente final, el cual no nos pide ningn tipo de documentacin, tan solo que la aplicacin funcione y un manual de usuario para poder usarla sin ningn tipo de problemas. Por lo tanto, el resto de documentacin generada ser guardada para reutilizarla en futuros proyectos. Los entregables generados sern los siguientes: Cdigo fuente Cdigo ejecutable Base de datos Software de integracin Paquete del software Informacin sobre los mtodos de prueba Datos de prueba Software de prueba Anlisis funcional Anlisis de diseo Documentacin del manejo de la aplicacin y del funcionamiento
3.2.1.4 Horario y presupuesto

La planificacin del proyecto se basa en las tareas que se obtendrn del estndar IEEE 1074. Dicho estndar proporcionar las tareas a realizar, las cuales debern realizarse en el momento adecuado para cumplir con el calendario que se obtenga tras realizar la planificacin.
35
A cada tarea se le asignaran unos recursos para su correcto desarrollo, los cuales habrn sido estimados en el plan de proyecto, as como el presupuesto del proyecto, el staff necesario para cada fase y la duracin de las mismas.
Mirar anexos:
Anexo I: Diagrama Gantt Apndices A, B y C (RBS, WBS, PBS): RBS, WBS y PBS
3.3 Referencias
La lista de documentos que se han utilizado para el desarrollo de la aplicacin ha sido la siguiente: IEEE1074-2006 IEEE1058-1998
El resto de documentos esta listado en el capitulo Bibliografa.
3.4 Definiciones
GANTT Grfico ilustrativo sobre la planificacin de tareas y las relaciones de precedencia (orden) entre las mismas. HW Hardware. IEEE 1058 Estndar para la realizacin del Plan de Proyecto Software. IEEE 1074 Estndar para el desarrollo del Modelo de Procesos Software. PERT Grfico ilustrativo para realizar un seguimiento del proyecto y determinar el camino crtico.
36
RBS Resource Breakdown Structure Estructuracin de recursos SW Software. WBS Work Breakdown Structure Estructuracin de tareas
3.5 Organizacin del proyecto

3.5.1 Interfaces externas
En este proyecto no hay relacin con otras entidades (proveedores, contratistas). Por lo tanto no hay ninguna descripcin de las relaciones entre el proyecto y entidades externas. La nica organizacin con la que se interacta es con el cliente, del que se extraern los datos necesarios para realizar el proyecto, as como de los datos de la informacin que ellos manejan, para poder procesarla y traspasarla al modelo informtico. Al final de cada fase, se comprobar por parte del responsable de gestin de calidad, que se estn cumpliendo todos los planes definidos para el proyecto.
3.5.2 Estructura interna

Para este proyecto se necesitan las siguientes entidades para su correcto desarrollo. Un jefe de proyecto, que estar a cargo de los analistas, programadores y diseadores necesarios, en este caso tan solo uno. Un jefe de calidad, responsable del encargado de pruebas y del encargado de aseguramiento de calidad, en esta caso, la misma persona. La estructura queda de la siguiente manera:
37
Ilustracin 3-2 Estructura interna
3.5.3 Responsabilidades y roles

El equipo de proyecto es el siguiente: Jefe de Proyecto: Fernando Paniagua. Jefe de calidad: David Hernndez. Analista: David Hernndez. Programador: David Hernndez. Diseador: David Hernndez. Encargado de pruebas: David Hernndez. Encargado de aseguramiento de calidad: David Hernndez. A continuacin se muestra la lista de actividades junto con los componentes o reas del proyecto para determinar quien realiza cada una.
rea de Calidad 1.1.1 1.1.2 1.1.3 1.2.7
Jefe de Proyecto
Analista
Diseo y Programacin
38
1.3.2 2.1.1 2.1.2 2.1.4 2.2.1 2.2.2 2.2.3 2.3.1 2.3.2 2.3.3 2.3.4 3.1.1 3.1.2 3.1.3 3.2.1 3.2.2 3.2.3 3.2.4 3.3.1 3.3.2 3.3.3 4.1.1 4.1.2 4.1.3 5.1.1 5.1.4 5.1.5 5.1.6 5.1.7 5.3.1 5.3.2 5.4.1 5.4.2 5.4.3
Tabla 1 Lista de actividades
39
3.6 Planes de proceso de gestin

3.6.1 Plan de estimacin
Para la estimacin, se ha utilizado el diagrama Gantt (Mirar Anexo I). Este diagrama permite conocer las diferentes tareas a realizar a lo largo del tiempo total determinado. Tambin, permite conocer los costes de cada tarea y la persona encargada en desarrollarla. La revisin del diagrama ser constante durante el desarrollo del proyecto.
3.6.2 Plan de plantilla

Mirar Apendice WBS.
3.6.3 Plan de compra de recursos

Para el desarrollo del proyecto se necesita el siguiente hardware y software.
3.6.3.1 Software
Windows XP Profesional J2SE MySQL Microsoft Office XP Dreamweaver Netbeans Apache Tomcat Ninguna de ellas se debe adquirir, por lo que no supone un gasto para el cliente final, al igual que el Hardware utilizado.
3.6.3.2 Hardware
Ordenador de sobremesa Intel Core Duo 2.00 GHz., 1 Gb memoria RAM, 200 Gigas Disco Duro.
40
Para la instalacin de la aplicacin, se requerir un servidor que soporte las tecnologas JSP, Servlets y MySQL. Si el cliente dispone uno con estas caractersticas, la instalacin se realizar sobre este, si por el contrario el servidor es externo al cliente y hay que contratarlo, los gastos corrern a cargo del cliente. Si tampoco dispone de un dominio Web, se contratar junto con el servidor. Se estima que estos costes se situan en torno a los 100 150 euros, dependiendo del tipo de alojamiento, cantidad de cuentas de correo requeridas, capacidad de alojamiento, etc.
3.6.4 Plan aprendizaje personal

La plantilla consta de dos personas, las cuales ocupan varios puestos diferentes a la vez. El jefe de proyecto y calidad conoce todas las tecnologas que se van a utilizar, por lo que no necesita ninguna formacin adicional. Sin embargo, el otro componente del proyecto, encargado de la programacin, pruebas, anlisis, etc., no dispone de la formacin adecuada, por lo que deber aprender de forma autodidacta a utilizar las siguientes tecnologas: Servltes JSP MySQL Paquete JavaMail Paquete IText
Se da por hecho que domina el resto de software a utilizar. Complementariamente tambin aprender nociones bsicas sobre seguros, plizas, voluntariado, etc., con el fin de orientar la aplicacin de una forma ms adecuada hacia el cliente final. Esta formacin servir de gran ayuda para posibles proyectos futuros en los que se vuelvan a utilizar estas tecnologas.
41
3.6.5 Plan de Trabajo

3.6.5.1 Actividades
En este punto se especifican las actividades que se llevarn a cabo durante todo el proyecto, indicando de este modo el plan de trabajo que se intentar seguir para el desarrollo de la aplicacin. Para ello, se ha requerido la construccin de la Estructura de Desglose de Tareas (WBS) (Mirar Apndice B (WBS)). El WBS nos da una indicacin de las tareas que a ejecutar y su posicin dentro del ciclo de vida. Mirar anexos:
Anexo I: Diagrama Gantt Apndice B (WBS): WBS
3.6.5.2 Planificacin
La asignacin de horarios se ha realizado a travs de la aplicacin MS Project, mostrando las actividades requeridas para el desarrollo del proyecto junto con su correspondiente fecha y persona al cargo. Se modificaran fechas si fuese necesario, intentando que el impacto en el proyecto fuera el menor posible. Mirar anexo:
Anexo I: Diagrama Gantt
42
3.6.5.3 Adquisicin de recursos

El plan para adquisicin de recursos esta especificado en el Apndice A (RBS). No se adquirir en este proyecto ni servicio de transporte, instalaciones, servicios administrativos y de limpieza. Mirar anexo: Apndice A (RBS): RBS
3.6.5.4 Asignacin de presupuesto

A continuacin se muestra un desglose del coste de cada etapa. - Actividades previas 864 Euros - Gestin 1764 Euros - Anlisis 4401 Euros - Diseo 5676 Euros - Formacin personal 194 Euros - Implementacin 3826 Euros - Pruebas 1644 Euros - Instalacin Software 280 Euros - Aceptacin del Software 320 Euros - Distribucin documentacin 320 Euros
Total presupuesto: 19288 Euros
De una forma ms detallada y precisa, se muestra el coste en la siguiente tabla.
43
Tarea Crear cdigo ejecutable Identificar y analizar requisitos funcionales Desarrollar requisitos Ejecutar pruebas Disear base de datos Disear interfaces Diseo detallado Identificar ideas o necesidades Planificar gestin proyecto Priorizar e integrar requisitos Identificar requisitos Formular posibles propuestas Documentar la implementacin Implementar manual de usuario Ejecutar estimacin Concretar necesidades cliente Disear arquitectura Descomponer requisitos del sistema Integracin de partes del sistema Aceptacin del software Producir y distribuir documentacin Investigacin Elegir ciclo de vida Crear proceso ciclo de vida
Coste () 2024 1560 1280 1104 992 992 992 741.82 640 620 603.08 560 530.40 530.40 521.14 520 520 480 440 320 320 288 288 288
44
Bsqueda de integracin software Bsqueda de software de desarrollo Resultado de pruebas Instalacin del software Crear datos de prueba Definir y analizar requisitos SW Definir y analizar requisitos interfaz Formacin del personal Analizar arquitectura del sistema
285.60 280 280 280 260 240 240 192 60 TOTAL 19288.44
Tabla 2 Presupuesto detallado de la aplicacin
3.6.6 Plan de Control

3.6.6.1 Plan de control de requisitos
Se tendr que llevar a cabo un control de los requisitos durante todo el desarrollo del proyecto, con el fin de conocer si se estn cumpliendo los objetivos y necesidades marcados en un principio. El control ser llevado a cabo por los componentes del equipo de trabajo, ya que es posible que el desarrollo puede tener modificaciones en alguna de las etapas, aadiendo o eliminando actividades para un mejor desarrollo del proyecto. Las modificaciones no afectan a las restricciones impuestas anteriormente el diseo previo.
3.6.6.2 Plan de control de planificacin

Con el fin de controlar todos los tiempos, tanto de entrega como de plantilla, se crear un plan de control de cronograma que permitir gestionar de una manera eficiente y sencilla las fechas y horarios previstos durante todo el desarrollo.
45
As pues, se deber seguir rigurosamente el calendario que proporciona MS Project mediante el diagrama GANTT (Mirar Anexo I GANTT), mostrando claramente las fechas y das que se debe utilizar para cada actividad del proyecto. Es posible que se realicen modificaciones de fechas y entregas, as que este diagrama muestra una estimacin previa del calendario, pero a lo largo del desarrollo puede que se vuelva a tener que estimar.
3.6.6.3 Plan de control del presupuesto

No aplica.
3.6.6.4 Plan de control de calidad

No aplica.
3.6.6.5 Plan de informes

No aplica.
3.6.6.6 Plan de recoleccin de mtricas

No aplica.
3.6.7 Plan de gestin de riesgo

No aplica.
3.6.8 Plan de cierre

Al finalizar el proyecto, se propondr a la empresa contratante un servicio de mantenimiento con el fin de revisar el buen funcionamiento de la aplicacin, as como posibles modificaciones que se requieran.
3.7 Planes de proceso tcnico

3.7.1 Modelo de proceso
El modelo en el que se ha basado el desarrollo ha sido el IEEE 1074, el cual determinar el ciclo de vida en cascada elegido para el proyecto.
46
Consta de 4 fases: Captura y Anlisis de Requisitos: Se planifica el proyecto, abarcando el desarrollo software y todas las tareas de gestin del software. Se identifican las ideas y necesidades, se formulan aproximaciones al potencial del producto, se estudia la viabilidad. Se concretan los requisitos sobre el sistema mediante reuniones con el usuario Se establecen los requisitos hardware y software necesarios
Diseo del Sistema Se definen los requisitos software por parte del usuario, tales como requisitos funcionales, de interfaces y priorizarlos. Se define el organigrama del funcionamiento de la aplicacin. Se define el medio y forma del enlace entre el usuario y la aplicacin. Se disea un plan de pruebas para el buen funcionamiento de la aplicacin.
Implementacin Se codifica la aplicacin. Se realiza la incorporacin de todas las partes y mdulos de la aplicacin al sistema. Se crean los informes necesarios para el usuario.
Integracin y Pruebas Se lleva acabo la instalacin del software. Se realizan las pruebas definitivas para el correcto funcionamiento de la aplicacin, y el usuario da el visto bueno.
47
Se ofrece formacin para que los usuarios conozcan la aplicacin y su perfecto manejo.
3.7.2 Mtodos, herramientas y tcnicas

Las herramientas que se han utilizado para confeccionar el desarrollo de la planificacin del proyecto son las siguientes: Microsoft Project. Microsoft Word. Microsoft PowerPoint. NetBeans Lenguajes de programacin
Los lenguajes de programacin usados son: Java MySQL JSP
48
3.7.3 Plan de infraestructura

Hardware utilizado: Pentium Quad Core 2.40 GHz, 1 Gb RAM. Red ADSL 2 MB.
Software utilizado: Windows XP NetBeans Dreamweaver
Sistema anfitrin: - Pentium 4 1.60 GHz, 512 MB RAM. - Windows XP - Red ADSL
3.7.4 Plan de aceptacin del producto

Se debe dar al cliente la aplicacin dentro del plazo estimado. Una vez entregada, se le facilitarn las pruebas si fuese necesario, y habr un tiempo de prueba para ver el correcto funcionamiento de la aplicacin en el da a da. Si el cliente esta conforme con la aplicacin durante este tiempo, la venta se dar por cerrada, y comenzar el periodo de mantenimiento si as lo desean.
49
3.8 Plan de proceso

3.8.1 Plan de gestin de la configuracin
Se utilizar la herramienta CVS (Concurrent Versions System) que es una aplicacin informtica que implementa un sistema de control de versiones: mantiene el registro de todo el trabajo y los cambios en los ficheros (cdigo fuente principalmente) que forman un proyecto (de programa) y permite que distintos desarrolladores (potencialmente situados a gran distancia) colaboren. El modo en el que se nombran las versiones ser: v.XX.YY.ZZZZ, siendo: v: indicador de que es una versin XX: el nmero de la versin YY: el nmero de release ZZZZ: el nmero de parche Numerndose secuencialmente de la siguiente manera: En el caso de introducir un nuevo parche: v.XX.YY.ZZZZ+1 Si se introduce una nueva release para solucionar cualquier anomala o error del sitema: v.XX.YY+1.0000 Si se modifica la versin, aadindole nuevas funcionalidades, sera: v.XX+1.00.0000 Para la correcta utilizacin de sta herramienta, se tendrn almacenados en una base de datos las versiones de los distintos ficheros que formen el proyecto, al acceder a un fichero, ste se quedar bloqueado (a no ser que varias personas tengan que trabajar con los mismos archivos) hasta que el usuario vuelva a subirlo y realice el correspondiente control de cambios.
50
3.8.2 Plan de validacin y verificacin

El propio CVS permite que varios usuarios puedan sacar copias del proyecto al mismo tiempo. Posteriormente, cuando actualizan sus modificaciones, el servidor trata de acoplar las diferentes versiones. Si esto falla, por ejemplo debido a que dos clientes tratan de cambiar la misma lnea en un archivo en particular, entonces el servidor deniega la segunda actualizacin e informa al cliente sobre el conflicto, que el usuario deber resolver manualmente. Si la operacin de ingreso tiene xito, entonces los nmeros de versin de todos los archivos implicados se incrementan automticamente, y el servidor CVS almacena informacin sobre la actualizacin, que incluye una descripcin suministrada por el usuario, la fecha y el nombre del autor y sus archivos log. Se realizar con cada versin su correspondiente control de errores, realizando varias pruebas introduciendo en el sistema todos los posibles valores, esperados o no, y forzando a la aplicacin para comprobar su funcionamiento en situaciones lmite.
3.8.3 Plan de documentacin

Este plan hace referencia a toda la documentacin del proyecto software y a las entidades responsables de proporcionar la informacin de entrada y de generar y repasar los distintos documentos. Productos no entregables: no se entregan pero son necesarios para llevar a cabo la realizacin de la aplicacin. Son los siguientes: Especificacin de requisitos Documentacin de la organizacin (WBS, RBS, PBS, matriz de trazabilidad) Documentacin de la planificacin (diagrama Gantt) Documentacin del diseo Planes de prueba
Productos entregables: hacen referencia a toda la documentacin creada para la instalacin y el mantenimiento de la aplicacin, as como la documentacin de ayuda y de formacin para los usuarios que vayan a utilizarla. Son los siguientes
51
Cdigo fuente Manual de usuario Sistema de ayuda Documentacin de la configuracin Gua de mantenimiento
3.8.4 Plan de garanta de calidad

La calidad de un proyecto es una de las actividades ms importantes para determinar la entrega correcta del mismo, y se realiza a lo largo del ciclo de vida del proyecto. El propsito de este plan es determinar si un objeto es mejor, peor o igual que otro objeto de la misma especie. Para ello se atiende a dos conceptos: Tiene que satisfacer al cliente. Tiene que minimizar errores (aunque se debe tener en cuenta que en un proyecto software la existencia de errores nunca ser cero). La gestin de la calidad debe tener una concordancia con los requisitos funcionales y de rendimiento explcitamente establecidos con los estndares de desarrollo explcitamente documentados y con las caractersticas implcitas que se espera de todo software desarrollado profesionalmente. En resumen, la gestin de la calidad debe tener tres hechos bsicos: Plan de calidad => basado en los estndares. Reglas que han de cumplirse => son los requisitos de calidad. Aseguramiento de la calidad => llevado a cabo por el responsable de calidad.
Para asegurar la calidad de un proyecto se debe poder responder afirmativamente a una serie de preguntas sobre la aplicacin, cada una de las cuales est relacionada con uno de los siguientes once factores: Segn el punto de vista de la revisin:
52
o Facilidad de mantenimiento: El programa se puede arreglar con bastante facilidad. Tiene un valor medio. o Facilidad de prueba: A la aplicacin se le podrn pasar los programas de prueba con total normalidad. Tiene un valor alto. o Flexibilidad: Gracias a la modularidad del programa, ste tiene una alta flexibilidad. Tiene un valor alto. Segn el punto de vista de la transicin: o Interoperabilidad: El programa no se puede comunicar con otros sistemas. o Portabilidad: Siempre y cuando se cumplan los requisitos mnimos de instalacin de la aplicacin, sta se podr utilizar en diferentes mquinas. Tiene un valor medio. o Reusabilidad: La aplicacin se ha implementado de tal forma que garantiza su reusabilidad. Tiene un valor alto. Segn el punto de vista de la operacin: o Correccin: La aplicacin software debe cumplir los requisitos estipulados, por tanto, deber cumplir con la finalidad del producto. Tiene un valor alto. o Fiabilidad: Se intentar que el programa funcione de forma exacta todo el tiempo. Tiene un valor alto. o Eficiencia: Se intentar que la aplicacin se ejecute sobre el hardware lo mejor posible. Tiene un valor alto. o Integridad: No es una de las principales finalidades. Tiene un valor bajo. o Facilidad de uso: La aplicacin se podr ejecutar de forma sencilla, para que al cliente le resulte lo ms cmodo posible. Tiene un valor medio.
53
En resumen, el orden de prioridad de estos 10 factores para el plan de calidad de nuestro proyecto es el siguiente: 1. Correccin 2. Fiabilidad 3. Eficiencia 4. Facilidad de uso 5. Facilidad de mantenimiento 6. Facilidad de prueba 7. Flexibilidad 8. Reusabilidad 9. Portabilidad 10. Integridad
3.8.5 Revisiones y auditoras

No aplica.
3.8.6 Plan de resolucin de problemas

No aplica.
3.8.7 Plan de gestin de subcontratacin

No aplica.
3.8.8 Plan de mejora del proceso

No aplica.
54
3.8.9 Planes adicionales

No aplica .
3.9 Apndices
3.9.1 Apndice A (RBS)
Ilustracin 3-3 RBS
55
3.9.2 Apndice B (WBS)
Ilustracin 3-4 WBS 56
3.9.3 Apndice C (PBS)
Ilustracin 3-5 PBS Gestin 57
Ilustracin 3-6 PBS Pre-desarrollo
58
Ilustracin 3-7 PBS Desarrollo
59
Ilustracin 3-8 PBS Post-desarrollo
60
Ilustracin 3-9 PBS Soporte
61
4 Anlisis
4.1 Descripcin del sistema
La aplicacin consistir en la gestin de voluntarios pertenecientes a distintas asociaciones. Para ello, existir la figura de administrador, en este caso, la empresa que solicita la aplicacin. El administrador podr realizar las siguientes tareas con el fin de facilitar y controlar la gestin de la informacin: Podr dar de alta una asociacin introduciendo tanto los datos corporativos como el domicilio de esta. La aplicacin enviar un contrato que deber ser firmado y rellenado por la asociacin. Este, volver a ser enviado al administrador, que ser el encargado de validar los datos en la aplicacin. Si todo el proceso ha sido correcto, el sistema enviar un correo a la asociacin con los datos necesarios para ingresar en la aplicacin. En el caso de que una asociacin quiera darse de baja en el sistema, o bien caduque su fecha de efecto, el administrador se encargar de borrarla de la base de datos. Si la asociacin es eliminada, tambin lo sern sus voluntarios. Si la asociacin ha sido dada de alta con algn fallo en sus datos, el administrador podr modificarlos si as se requiere. Toda modificacin ser notificada tanto al correo de la asociacin como al correo de la persona de contacto dentro de esta. Si la asociacin pierde la clave o desea que se le reenve, ser el administrador el encargado de realizar este proceso. El administrador podr dar de alta a voluntarios, aunque este no sea su cometido. Deber rellenar los datos pertinentes y seleccionar la asociacin a la que pertenecen. Este proceso generar un correo con los certificados que ser enviado a la asociacin. A su vez, se enviar otro correo para notificar tanto al administrador como a la sociedad, de que el alta se ha realizado correctamente.
62
Si se desea realizar una carga masiva de voluntarios, el administrador ser quien se ocupe de ello. Se deber disponer de un archivo de texto con el formato correcto. Si hubiese algn fallo en el formato, se notificar por pantalla de los errores. De lo contrario, los voluntarios sern dados de alta en la asociacin indicada. En este caso, no se generan los certificados, ya que o bien esos voluntarios ya han sido registrados en la sociedad con anterioridad, o bien, se les enviar los certificados por otro medio.
En el caso de tener que dar de baja algn voluntario, la asociacin deber comunicrselo al administrador. Tambin, y aunque no sea tarea del administrador, se podr establece una fecha de baja para los voluntarios.
Si algn voluntario contiene algn error en sus datos, el administrador ser el encargado de modificarlos. Esta modificacin no ser notificada a la asociacin.
El administrador podr consultar en cualquier momento las asociaciones y voluntarios disponibles en la base de datos. La bsqueda se realizar a travs de un criterio de bsqueda definido por el administrador.
Las tareas a realizar por la asociacin son: Modificar los datos de la asociacin. Al igual que con el administrador, la asociacin podr modificar su datos. Toda modificacin se notificar por correo tanto a la persona de contacto de la asociacin, como al correo facilitado por la asociacin. Dar de alta a voluntarios. Ser la principal tarea de la asociacin, dar de alta a los voluntarios sin tener que informar al administrador. Debern rellenar los datos de los voluntarios, y si estos son correctos, se enviar un correo con los certificados correspondientes a cada uno de ellos al correo de la persona de contacto. Tambin, se informar al administrador y a la sociedad de los voluntarios aadidos. Dar de baja a los voluntarios. La asociacin podr dar de baja a los voluntarios cuando lo requieran. Tambin podrn establecer una fecha de baja para cualquiera de ellos.
63
Podrn consultar la informacin de los voluntarios y generar un libro de registro con los voluntarios consultados. El libro de registro tendr un formato adecuado para que tenga validez.
4.2 Requisitos de Usuario y Sistema

En esta seccin se presentan los requisitos de usuario que debern ser satisfechos por el sistema. Todos ellos son esenciales, por lo que se tendr que poner especial nfasis en completarlos.
Identificador Nombre Fuente Necesidad Prioridad Claridad Verificabilidad Estabilidad Descripcin
RUC-001
Versin
1.0
Restriccin de entrada a la aplicacin Cliente Esencial Deseable Opcional Alta Media Baja Alta Media Baja Alta Media Baja No puede sufrir modificaciones a lo largo del proyecto. La aplicacin deber constar de un sistema de validacin que a travs de un nombre de usuario y una clave especfica para cada usuario, permita el acceso a ella. Si alguna persona ajena al sistema pretende entrar, la aplicacin deber restringir el acceso informando por pantalla de la invalidez de sus datos. Igualmente, si un usuario intenta entrar y comete un error en la insercin de sus datos, la aplicacin le informar por pantalla de su error.
Tabla 3 Requisito 001
64
RUC-002
Versin
1.0
Eliminacin de los datos de voluntario Cliente Esencial Deseable Opcional Alta Media Baja Alta Media Baja Alta Media Baja No puede sufrir modificaciones a lo largo del proyecto. El sistema debe proceder a la eliminacin de los voluntarios pertenecientes a una asociacin cuando se elimine esta. Para ello, la aplicacin contar con un sistema que automticamente borre la informacin. Este proceso no debe generar ninguna notificacin al administrador del sistema.
RUC-003
Versin
1.0
Notificacin de modificacin de datos Cliente Esencial Deseable Opcional Alta Media Baja Alta Media Baja Alta Media Baja Puede sufrir modificaciones a lo largo del proyecto. Cuando tanto el administrador del sistema como el de una asociacin modifiquen la informacin referente a una asociacin, deber ser notificado va e-mail a los correos correspondiente. Se enviar un correo a la asociacin para que compruebe si los datos modificados son correctos. Se enviar otro correo al administrador de la asociacin, por si la modificacin hubiese sido incorrecta.
65
RUC-004 Envo de certificados Cliente
Versin
1.0
Esencial Deseable Opcional Alta Media Baja Alta Media Baja Alta Media Baja Puede sufrir modificaciones a lo largo del proyecto. Cuando el administrador del sistema o de una asociacin proceda a dar de alta a nuevos voluntarios, el sistema deber generar los certificados correspondientes a cada uno de ellos. Una vez generados todos, se adjuntan a un correo que ser enviado al administrador de la asociacin. Puede ser que los certificados se modifiquen a lo largo del desarrollo.
RUC-005 Envo de clave Cliente
Versin
1.0
Esencial Deseable Opcional Alta Media Baja Alta Media Baja Alta Media Baja No puede sufrir modificaciones a lo largo del proyecto. Si se diese el caso de que algn administrador de asociacin olvidase la clave de acceso al sistema, el administrador del sistema deber poder reenviar la clave por correo. La notificacin de la prdida de la clave deber ser notificada por un medio externo a la aplicacin, como puede ser mediante un correo electrnico o una llamada telefnica.
66
RUC-006 Fechas correctas Cliente
Versin
1.0
Esencial Deseable Opcional Alta Media Baja Alta Media Baja Alta Media Baja No puede sufrir modificaciones a lo largo del proyecto. La aplicacin debe comprobar que las fechas introducidas sean correctas y cumplan el formato establecido. Gran parte de la documentacin generada por el sistema depende de las fechas introducidas por los usuarios, por lo que hay que poner especial atencin en este apartado. El formato a seguir ser el siguiente: dd/mm/aaaa
RUC-007
Versin
1.0
Restriccin de la modificacin de voluntarios Cliente Esencial Deseable Opcional Alta Media Baja Alta Media Baja Alta Media Baja No puede sufrir modificaciones a lo largo del proyecto. Si el administrador de la asociacin desea modificar los datos de alguno de sus voluntarios, deber ponerse en contacto con el administrador del sistema, que ser el encargado de realizar los cambios pertinentes. Esta restriccin evita posibles modificaciones indeseadas en los datos de los voluntarios. Las modificaciones de los voluntarios no sern notificadas a ningn usuario.
67
RUC-008
Versin
1.0
Carga masiva de datos Cliente Esencial Deseable Opcional Alta Media Baja Alta Media Baja Alta Media Baja No puede sufrir modificaciones a lo largo del proyecto. Cabe la posibilidad que en el primer momento de puesta en marcha de la aplicacin, se deba hacer una carga masiva de datos a travs de ficheros. En este caso, la aplicacin debe de tener un sistema que garantice la carga de los voluntarios a travs de ficheros txt con el formato correcto, notificando aquellos errores que el fichero contenga antes de dar de alta ningn voluntario. Una vez realizada la carga masiva, esta opcin permanecer activa ya que es posible que alguna asociacin quiera enviar un archivo con todos sus voluntarios y delegar en el administrador la tarea de introducir los voluntarios.
RUC-009
Versin
1.0
Baja de las asociaciones Cliente Esencial Deseable Opcional Alta Media Baja Alta Media Baja Alta Media Baja No puede sufrir modificaciones a lo largo del proyecto. Las asociaciones no podrn darse de baja en la aplicacin a travs de su interfaz. Si desean darse de baja, debern notificarlo a travs de correo electrnico o cualquier otro medio al administrador del sistema, que una vez reciba la peticin, proceda a eliminar la asociacin de la base de datos.
68
RUC-010
Versin
1.0
Fechas de los voluntarios Cliente Esencial Deseable Opcional Alta Media Baja Alta Media Baja Alta Media Baja No puede sufrir modificaciones a lo largo del proyecto. Al dar de alta a los voluntarios, las fechas sern generadas o introducidas dependiendo del usuario que realice el proceso. Si se trata del administrador del sistema, la fecha de alta ser generada automticamente, correspondiendo con la fecha de alta en el sistema, mientras que la fecha de inicio quedar vaca a la espera de rellenarse por la asociacin. Si es el administrador de la asociacin quien realiza el proceso, deber introducir desde un primer momento la fecha de inicio, y al igual que antes, la fecha de alta corresponder a la de alta en el sistema.
RUC-011
Versin
1.0
Fecha de baja de los voluntarios Cliente Esencial Deseable Opcional Alta Media Baja Alta Media Baja Alta Media Baja Puede sufrir modificaciones a lo largo del proyecto. La fecha de baja de los voluntarios ser establecida por el administrador de la asociacin correspondiente. No es un proceso importante, ya que salvo rara vez, la fecha de baja corresponder con la fecha de efecto de la que disponga la asociacin ms un ao-
69
RUC-012
Versin
1.0
Bsqueda por campos Cliente Esencial Deseable Opcional Alta Media Baja Alta Media Baja Alta Media Baja Puede sufrir modificaciones a lo largo del proyecto. Las consultas incompletos. deben poder buscar a travs de parmetros
Si se introduce el principio de una palabra, se deben sacar todas las ocurrencias que contengan en su comienzo el parmetro a buscar. Esto se debe cumplir tanto para las bsqueda en asociaciones como en voluntarios Si se desea listar todos los voluntarios o asociaciones, debern dejarse en blanco los parmetros de bsqueda.
RUC-013 Libro de registro Cliente
Versin
1.0
Esencial Deseable Opcional Alta Media Baja Alta Media Baja Alta Media Baja No puede sufrir modificaciones a lo largo del proyecto. El sistema debe presentar un libro de registro con un formato establecido para que les sirva a las asociaciones como un libro de registro real. Se podr realizar un libro de registro de unos voluntarios escogidos mediante una bsqueda previa.
70
RUC-014
Versin
1.0
Contrato autorizacin Cliente Esencial Deseable Opcional Alta Media Baja Alta Media Baja Alta Media Baja No puede sufrir modificaciones a lo largo del proyecto. Al dar de alta una asociacin, se debe enviar un contrato al correo de esta, con el fin de que lo devuelva firmado y confirmando el alta en la base de datos de la aplicacin. La asociacin no podr usar el sistema hasta que enve el contrato junto con los datos personales que se requieren. Una vez recibida dicha informacin, el administrador pasara a validarla y enviar la contrasea de acceso al sistema.
71
5 Diseo
5.1 Arquitectura
La arquitectura de software es el diseo de ms alto nivel de la estructura de un sistema, programa o aplicacin, y tiene la responsabilidad de: Establecer los fundamentos para que analistas, programadores, diseadores, etc., trabajen en una lnea comn que permita alcanzar los objetivos marcados. Proporcionar patrones y abstracciones coherentes que permitan guiar la construccin del software para un sistema de informacin. Seleccionar y disear la estructura idnea en base a los objetivos y restricciones. Definir los mdulos principales. Definir las responsabilidades de cada modulo. Definir la interaccin entre los mdulos.
Proporciona as una visin abstracta de alto nivel, posponiendo el detalle de cada uno de los mdulos a pasos posteriores del diseo. La definicin oficial de arquitectura de software segn el estndar IEEE 1471-2000, es la siguiente: La Arquitectura del Software es la organizacin fundamental de un sistema formada por sus componentes, las relaciones entre ellos y el contexto en el que se implantan, y los principios que orientan su diseo y evolucin. El objetivo principal de la arquitectura del software es aportar los elementos necesarios para ayudar a la toma de decisiones, adems de aportar conceptos y el lenguaje comn para permitir la comunicacin entre los equipos que participen en el proyecto. Para ello, la arquitectura del software construye abstracciones en forme de diagramas.
72
No hay ningn estndar en cuanto a la forma y el lenguaje a utilizar en los diagramas, pero si existe un consenso en cuanto a la necesidad de organizar las abstracciones en vistas.
Existen al menos tres vistas fundamentales en cualquier arquitectura. Visin esttica. Describe que componentes tiene la arquitectura. Visin funcional. Describe que hace cada componente. Visin dinmica. Describe el comportamiento y la relacin que hay entre los componentes. Arquitecturas ms comunes Monoltica. El software se estructura en grupos funcionales muy acotados. Cliente Servidor. El software se reparte en dos elementos diferentes pero sin reparto claro de funciones. Arquitectura de tres niveles. Especializacin de la arquitectura cliente servidor, dividendo la carga en tres partes o capas, con un reparto claro de funciones. Capa para la presentacin, capa para el clculo y otra para el almacenamiento.
5.1.1 Arquitectura Cliente - Servidor

Esta arquitectura reparte el software en dos elementos, el cliente que realiza peticiones, y el servidor que le da respuesta. Esta idea se puede aplicar a programas que se ejecutan sobre una sola maquina, pero la forma ms eficiente es separando las partes a travs de una red de ordenadores, por lo que la capacidad de proceso esta repartida entre los clientes y los servidores. La separacin entre cliente servidor es una separacin lgica, donde el servidor puede ejecutarse tanto en una maquina como en varias. Ejemplos de tipos de servidores pueden ser, servidores web, servidores de archivos, de correo Cliente (Parte activa)
73
Demanda servicios a los servidores Se asume que cada peticin deber obtener respuesta Diseado para interactuar con el usuario final Pueden conectarse varios a servidores a la vez
Servidor (Parte pasiva) Espera las peticiones de los clientes Procesa esas peticiones y enva las respuestas Diseo orientado a maximizar la eficiencia Normalmente no interactan con el usuario final Aceptan conexiones desde un gran numero de clientes
Usuario Puesto de trabajo Seridor
Base de datos
Ilustracin 5-1 Arquitectura cliente servidor
74
Puesto de trabajo o cliente Una estacin de trabajo o computador conectado a una red, que le permite acceder y gestionar una serie de recursos, perfilndose como un puesto de trabajo universal. Favorece la flexibilidad y el dinamismo en las organizaciones. Servidores Una maquina que suministra una serie de servicios como Bases de Datos, Archivos, Comunicaciones Segn su especializacin pueden ser: Mainframes Miniordenadores Especializados
Una caracterstica importante es que los diferentes servicios pueden ser suministrador por uno o varios servidores. Existen tres capas dependiendo de su funcin dentro de la arquitectura. Capa de presentacin (interfaz de usuario). Interacciona con el usuario, presenta los datos y recibe las entradas. Capa de aplicacin (lgica de aplicacin). Responsable de las tareas propias de la aplicacin. Aplica las reglas del negocio sobre los datos y las entradas del usuario. Capa de datos (almacenamiento y acceso a datos). Responsable de la gestin y almacenamiento permanente de los datos. Cada tipo de sistema cliente servidor, distribuye estas capas de modo distinto entre los componentes existentes.
75
Ventajas Centralizacin del control. Todo se centra sobre el servidor, de forma que si algn programa cliente defectuoso o no autorizado no pueda daar el sistema. Facilita tambin la actualizacin de los datos y otros recursos. Escalabilidad. Tanto clientes o servidores, pueden aumentar su capacidad independientemente del resto, incluso pudiendo aadir nuevos nodos a la red. Fcil mantenimiento o encapsulacin. Al estar distribuidas las funciones entre varios ordenadores, es posible reparar, actualizar o migrar datos con mayor facilidad y sin que los clientes se vean afectados de una manera significativa. Seguridad. Existen tecnologas suficientes como para garantizar la seguridad en las transacciones. Desventajas Congestin del trfico. Si hay muchas peticiones a la vez por parte de los clientes, el servidor puede llegar a colapsarse si no las gestiona bien. Robustez. Si el servidor esta cado, las peticiones de los clientes no pueden ser satisfechas. Software y Hardware. Normalmente, se necesita un servidor potente para satisfacer el trabajo. Esta potencia, tiene un elevado coste respecto a software y hardware se refiere. El cliente no dispone de los recursos que existen en el servidor.
76
5.1.2 Tipos de clientes y servidores

Clientes ligeros No implementa ningn aspecto de la lgica de la aplicacin Acta como intermediario entre usuario y servidor. recoge entradas y las enva al servidor presenta datos y resultados del servidor
Apenas necesita recursos hardware Aumenta la complejidad del servidor Clientes basados en navegadores Web (Jsp, Asp) o capa de presentacin repartida entre servidor (genera HTML al vuelo) y cliente (navegador)
Aumento en los ltimos aos en el uso de clientes basados en navegador + soporte de interacciones complejas (java script, carga XML)
Clientes pesados Implementa casi toda la lgica de la aplicacin Realiza procesos sobres los datos antes de mandarlos al servidor Requiere equipos con capacidad de procesos y almacenamiento de datos Servidor sencillo
Clientes hbridos Implementacin de la lgica repartida entre cliente y servidor
77
Servidor de archivos Servidor donde se almacenan archivos y aplicaciones de productividad
Servidor de bases de datos Servidor donde se almacenan bases de datos, tablas, ndices, siendo uno de los servidores con mayor carga Servidor de transacciones Servidor que cumple o procesa todas las transacciones. Primero valida y luego genera un pedido al servidor de bases de datos Servidor de Groupware Servidor utilizado para el seguimiento de operaciones dentro de la red
Servidor de objetos Contiene objetos que deben estar fuera de la base de datos, imgenes, videos,
Servidores Web Permite transacciones a travs de un navegador. Es utilizado como comunicacin entre empresas a travs de Internet
5.2 Diagrama de Casos de Uso

El diagrama de casos de uso es una representacin grfica de parte o el total de los actores o casos de uso del sistema, representando la forma con el que los actores operan con el sistema, adems de la forma, tipo y orden en como los elementos interactan. El modelado de Casos de Uso es una tcnica sencilla y efectiva para el modelado de sistemas. Realmente no es una aproximacin a la orientacin a objetos, sino una forma de modelar los procesos. Forman parte del anlisis del sistema y no del diseo como cabra pensar.
78
Elementos de un diagrama Sistema Un sistema se representa mediante una caja junto con el nombre del sistema arriba o dentro de la caja, definiendo as a aplicacin que se quiere desarrollar., adems de estableciendo unos limites entre lo que es interno y lo que es externo al sistema. Caso de uso Un caso de uso es una descripcin de la secuencia de interacciones que se producen entre un actor y el sistema. Se representa por una elipse, y denota un requerimiento solucionado por el sistema. Cada caso de uso es una operacin completa desarrollada por los actores o por el sistema. El nombre de caso de uso debe reflejar la tarea especfica que el actor desea llevar a cabo usando el sistema. Actor Un actor es una entidad que utiliza alguno de los casos de uso del sistema. Se representa mediante un mueco acompaado de un nombre significativo. El actor interacta con el sistema enviando o recibiendo del sistema unos mensajes o intercambiando informacin con este. Un actor es algo con comportamiento, lo que se podra definir como un rol, que especifica que un actor no debe ser necesariamente una persona. Relaciones entre Casos de Uso Un Caso de uso, en principio, debera describir una tarea que tiene un sentido completo para el usuario. Sin embargo, hay ocasiones en las que es til describir una interaccin con un alcance menor como caso de uso. La razn para utilizar estos casos de uso no completos en algunos casos, es mejorar la comunicacin en el equipo de desarrollo, el manejo de la documentacin de casos de uso. Include Un caso de uso base incorpora explcitamente a otro caso de uso en un lugar especificado en dicho caso base. Es una simple relacin de inclusin, es decir, los
79
escenarios o situaciones posibles detalladas en un caso de uso estn incluidas en otro caso de uso. Extend Cuando un caso de uso base tiene ciertos puntos en los cuales, dependiendo de ciertos criterios, se va a realizas una interaccin adicional. El caso de uso que extiende describe un comportamiento opcional del sistema. Las secuencias alternas se modelan en casos de uso separados, los cuales estn relaciones con el caso de uso original mediante una relacin Extiende. Adems se suele utilizar para representar casos de uso que engloban a otros. Generalizacin Cuando un caso de uso definido de forma abstracta se particulariza por medio de otro caso de uso ms especifico. Al igual que en la herencia entre clases, el caso de uso hijo hereda las asociaciones y caractersticas del caso de uso padre. Tambin se puede dar entre actores.
80
5.2.1 Diagrama de Casos de Uso del sistema
Alta asociacin
Validar asociacin
Baja asociacin
Modificar asociacin
Modificar asociacin
Reenviar clave
Alta voluntario
Administrador
Alta voluntario Baja voluntario
Asociacin
Alta vol. archivo Fecha baja voluntario
Fecha Baja voluntario Consultar voluntarios
Baja voluntario
Modificar voluntario
Consultar asociacin
Consultar voluntarios
Ilustracin 5-2 Diagrama casos de uso
81
5.3 Explicaciones de los Casos de Uso

5.3.1 Casos de Uso Administrador
Nombre:
Alta asociacin
Descripcin: Dar de alta a una asociacin en el sistema. Actores: Administrador. Precondiciones: El administrador debe de estar dentro del sistema. Poscondiciones: Asociacin dada de alta en el sistema. Flujo Normal: El administrador pulsa la opcin Nueva Asociacin. El administrador rellena todos los campos necesarios para el alta de la asociacin. El sistema muestra de nuevo los datos por si hubiese algn fallo. El administrador acepta los datos. El sistema verifica que los campos estn correctamente introducidos. El sistema informa de la nueva alta. El sistema enva los correos correspondientes a la alta de asociacin. Flujo Alternativo: El sistema detecta incorrecciones en los campos introducidos. El sistema detecta que existe otra asociacin con el mismo CIF. Tabla 17. Caso de Uso Alta asociacin
82
Nombre:
Validar asociacin
Descripcin: Validar la asociacin en el sistema para que pueda gestionar ella misma los voluntarios. Actores: Administrador. Precondiciones: El administrador debe de estar dentro del sistema. Asociacin dada de alta en el sistema. Poscondiciones: Asociacin validada en el sistema. Flujo Normal: El administrador pulsa la opcin Validar Asociacin. El administrador rellena todos los campos necesarios para la validacin. El administrador acepta los datos. El sistema verifica que los campos estn correctamente introducidos. El sistema informa de la correcta validacin. El sistema enva el nombre de usuario y la clave a la asociacin. Flujo Alternativo: El sistema detecta incorrecciones en los campos introducidos. Tabla 18. Caso de Uso Validar asociacin
Nombre:
Baja asociacin
Descripcin: Dar de baja a una asociacin en el sistema. Actores: Administrador. Precondiciones:
83
El administrador debe de estar dentro del sistema. Poscondiciones: Asociacin dada de baja en el sistema. Flujo Normal: El administrador pulsa la opcin Baja Asociacin. El sistema muestra el listado de asociaciones disponibles en la base de datos. El administrador selecciona aquellas que desea dar de baja. El administrador acepta la seleccin. El sistema realiza la baja de las asociaciones. Flujo Alternativo: El administrador introduce el CIF de la empresa a dar de baja. EL sistema comprueba la existencia del CIF. Si existe, la da de baja, si no, informa de CIF inexistente. Tabla 19. Caso de Uso Baja asociacin
Nombre:
Modificar asociacin
Descripcin: Modificar los datos de la asociacin. Actores: Administrador. Precondiciones: El administrador debe de estar dentro del sistema. Poscondiciones: Asociacin modificada correctamente. Flujo Normal: El administrador pulsa la opcin Modificar Asociacin. El sistema muestra el listado de asociaciones disponibles en la base de datos. El administrador selecciona aquella que desea modificar. El administrador acepta la seleccin. El sistema muestra los datos de la asociacin. El administrador modifica aquellos que considere necesarios.
84
El administrador valida los cambios. El sistema comprueba que los cambios sean correctos. El sistema modifica los datos. El sistema enva los correos pertinentes con los cambios realizados. Flujo Alternativo:
El sistema detecta que hay datos incorrectos. Tabla 20. Caso de Uso Modificar asociacin
Nombre:
Reenviar clave asociacin
Descripcin: El administrador reenva la clave de acceso a la asociacin. Actores: Administrador. Precondiciones: El administrador debe de estar dentro del sistema. Poscondiciones: Clave reenviada. Flujo Normal: El administrador pulsa la opcin Modificar Asociacin. El sistema muestra el listado de asociaciones disponibles en la base de datos. El administrador selecciona aquella que desea modificar. El administrador acepta la seleccin. El sistema muestra los datos de la asociacin. El administrador pulsa la opcin Reenviar clave. El sistema reenva la clave al correo de la asociacin. Flujo Alternativo:
Tabla 21. Caso de Uso Reenviar clave asociacin
85
Nombre:
Alta voluntario
Descripcin: Dar de alta a uno o varios voluntarios en el sistema. Actores: Administrador. Precondiciones: El administrador debe de estar dentro del sistema. Poscondiciones: Voluntarios aadidos. Flujo Normal: El administrador pulsa la opcin Alta Voluntario. El sistema muestra las tablas donde dar de alta a los voluntarios y la lista de asociaciones. El administrador rellena los datos de los voluntarios. El administrador selecciona la asociacin en la que desea aadirlos. El sistema comprueba que los datos estn introducidos correctamente. El administrador valida los datos. El sistema realiza el alta de los voluntarios en la base de datos. El sistema informa tanto por correo como por pantalla de los voluntarios aadidos junto con sus certificados correspondientes. Flujo Alternativo: El sistema detecta fallos en los datos de los voluntarios. El sistema detecta voluntarios con el mismo NIF. El sistema informa que hay voluntarios que no se han dado de alta por tener el mismo NIF. Tabla 22. Caso de Uso Alta voluntario
Nombre:
Alta Voluntario desde archivo
Descripcin: Alta de voluntarios a travs de archivo externo. Actores:
86
Administrador. Precondiciones: El administrador debe de estar dentro del sistema. Poscondiciones: Alta de voluntarios.. Flujo Normal: El administrador pulsa la opcin Alta desde archivo. El sistema muestra el listado de asociaciones disponibles en la base de datos junto con el campo donde deber introducir la ubicacin del archivo. El administrador selecciona el archivo y la asociacin en la que realizar el alta. El administrador acepta la seleccin. El sistema comprueba que los voluntarios tengan el formato correcto. El sistema da de alta a los voluntarios en la base de datos. El sistema enva un correo con los voluntarios dados de alta. Flujo Alternativo: El sistema detecta incorrecciones en los datos de los voluntarios. El sistema informa detalladamente de los datos incorrectos por pantalla. El administrador corrige los datos en el archivo y vuelve al flujo normal. Tabla 23. Caso de Uso Alta Voluntarios desde archivo
Nombre:
Baja Voluntario
Descripcin: Da de baja a los voluntarios del sistema. Actores: Administrador. Precondiciones: El administrador debe de estar dentro del sistema. Poscondiciones: Baja de voluntarios.
87
Flujo Normal: El administrador pulsa la opcin Baja voluntarios. El sistema muestra las asociaciones disponibles en la base de datos. El administrador selecciona una de ellas. El sistema muestra los voluntarios pertenecientes a dicha asociacin. El administrador selecciona aquellos voluntarios que desea dar de baja. El administrador confirma la baja de los voluntarios. El sistema da de baja a los voluntarios. Flujo Alternativo: El sistema detecta que el administrador no ha seleccionado ningn voluntario. Tabla 24. Caso de Uso Baja voluntario
Nombre:
Fecha Baja Voluntario
Descripcin: Establece le fecha de baja de los voluntarios. Actores: Administrador. Precondiciones: El administrador debe de estar dentro del sistema. Poscondiciones: Fecha de baja modificadas. Flujo Normal: El administrador pulsa la opcin Baja voluntarios. El sistema muestra las asociaciones disponibles en la base de datos. El administrador selecciona una de ellas. El sistema muestra los voluntarios pertenecientes a dicha asociacin. El administrador selecciona aquellos voluntarios en los que desea establecer una fecha de baja. El administrador introduce una fecha de baja. El administrador confirma la seleccin. El sistema establece la fecha de baja correspondiente para los voluntarios elegidos. El sistema enva un correo con los voluntarios modificados y la fecha de baja establecida. Flujo Alternativo:
88
El sistema detecta que el administrador no ha seleccionado ningn voluntario. El sistema detecta que la fecha introducida no tiene el formato correcto. Tabla 25. Caso de Uso Fecha baja voluntario
Nombre:
Modificar Voluntario
Descripcin: Modifica la informacin de los voluntarios de la base de datos. Actores: Administrador. Precondiciones: El administrador debe de estar dentro del sistema. Poscondiciones: Datos del voluntario modificados. Flujo Normal: El administrador pulsa la opcin Modificar Voluntario. El sistema muestra las asociaciones disponibles en la base de datos. El administrador selecciona una de ellas. El sistema muestra los voluntarios pertenecientes a dicha asociacin. El administrador selecciona un voluntario para modificar. El sistema muestra los datos correspondientes a dicho voluntario. El administrador modifica los datos necesarios. El sistema comprueba que los datos establecidos son correctos. El sistema actualiza los datos del voluntario en la base de datos. Flujo Alternativo: El sistema detecta que los datos introducidos son incorrectos. Tabla 26. Caso de Uso Modificar voluntario
89
Nombre:
Consultar Asociaciones
Descripcin: Realiza una consulta de las asociaciones sobre la base de datos. Actores: Administrador. Precondiciones: El administrador debe de estar dentro del sistema. Poscondiciones: Flujo Normal: El administrador pulsa la opcin Modificar Voluntario. El sistema muestra un formulario con los campos de las asociaciones. El administrador rellena aquellos que considere necesarios para realizar la bsqueda. El sistema realiza la consulta y muestra por pantalla la informacin correspondiente a las asociaciones que cumplan los criterios de bsqueda. Flujo Alternativo: Tabla 27. Caso de Uso Consultar asociaciones
Nombre:
Consultar Voluntarios
Descripcin: Realiza una consulta de los voluntarios sobre la base de datos. Actores: Administrador. Precondiciones: El administrador debe de estar dentro del sistema. Poscondiciones:
90
Flujo Normal: El administrador pulsa la opcin Modificar Voluntario. El sistema muestra un formulario con los campos de los voluntarios. El administrador rellena aquellos que considere necesarios para realizar la bsqueda. El sistema realiza la consulta y muestra por pantalla la informacin correspondiente a los voluntarios que cumplan los criterios de bsqueda. Flujo Alternativo: Tabla 28. Caso de Uso Consultar voluntarios
5.3.2 Casos de uso Asociacin
Nombre:
Modificar asociacin
Descripcin: Modificar los datos de la asociacin. Actores: Asociacin. Precondiciones: La asociacin debe de estar dentro del sistema. Poscondiciones: Asociacin modificada correctamente. Flujo Normal: La asociacin pulsa la opcin Modificar Asociacin. El sistema muestra los datos de la asociacin. La asociacin modifica aquellos que considere necesarios. La asociacin valida los cambios. El sistema comprueba que los cambios sean correctos. El sistema modifica los datos.
91
El sistema enva los correos pertinentes con los cambios realizados. Flujo Alternativo:
El sistema detecta que hay datos incorrectos. Tabla 29. Caso de Uso Modificar asociacin
Nombre:
Alta voluntario
Descripcin: Dar de alta a uno o varios voluntarios en el sistema. Actores: Asociacin. Precondiciones: La asociacin debe de estar dentro del sistema. Poscondiciones: Voluntarios aadidos. Flujo Normal: La asociacin pulsa la opcin Alta Voluntario. El sistema muestra las tablas donde dar de alta a los voluntarios. La asociacin rellena los datos de los voluntarios. El sistema comprueba que los datos estn introducidos correctamente. La asociacin valida los datos. El sistema realiza el alta de los voluntarios en la base de datos. El sistema informa tanto por correo como por pantalla de los voluntarios aadidos junto con sus certificados correspondientes. Flujo Alternativo: El sistema detecta fallos en los datos de los voluntarios. El sistema detecta voluntarios con el mismo NIF. El sistema informa que hay voluntarios que no se han dado de alta por tener el mismo NIF. Tabla 30. Caso de Uso Alta voluntario
92
Nombre:
Baja Voluntario
Descripcin: Da de baja a los voluntarios del sistema. Actores: Asociacin. Precondiciones: La asociacin debe de estar dentro del sistema. Poscondiciones: Baja de voluntarios. Flujo Normal: La asociacin pulsa la opcin Baja voluntarios. El sistema muestra los voluntarios pertenecientes a la asociacin. La asociacin selecciona aquellos voluntarios que desea dar de baja. La asociacin confirma la baja de los voluntarios. El sistema da de baja a los voluntarios. Flujo Alternativo: El sistema detecta que la asociacin no ha seleccionado ningn voluntario. Tabla 31. Caso de Uso Baja voluntario
Nombre:
Fecha Baja Voluntario
Descripcin: Establece le fecha de baja de los voluntarios. Actores: Asociacin. Precondiciones: La asociacin debe de estar dentro del sistema.
93
Poscondiciones: Fecha de baja modificadas. Flujo Normal: La asociacin pulsa la opcin Baja voluntarios. El sistema muestra los voluntarios pertenecientes a la asociacin. La asociacin selecciona una de ellas. La asociacin selecciona aquellos voluntarios en los que desea establecer una fecha de baja. La asociacin introduce una fecha de baja. La asociacin confirma la seleccin. El sistema establece la fecha de baja correspondiente para los voluntarios elegidos. El sistema enva un correo con los voluntarios modificados y la fecha de baja establecida. Flujo Alternativo: El sistema detecta que la asociacin no ha seleccionado ningn voluntario. El sistema detecta que la fecha introducida no tiene el formato correcto. Tabla 32. Caso de Uso Fecha baja voluntario
Nombre:
Consultar Voluntarios
Descripcin: Realiza una consulta de los voluntarios sobre la base de datos. Actores: Asociacin. Precondiciones: La asociacin debe de estar dentro del sistema. Poscondiciones: Flujo Normal: La asociacin pulsa la opcin Modificar Voluntario. El sistema muestra un formulario con los campos de los voluntarios. La asociacin rellena aquellos que considere necesarios para realizar la bsqueda. El sistema realiza la consulta y muestra por pantalla la informacin correspondiente a los voluntarios que cumplan los criterios de bsqueda.
94
Flujo Alternativo: Tabla 33. Caso de Uso Consultar voluntarios
95
5.4 Modelo Entidad Relacin de la base de datos

El modelo entidad relacin es un modelo conceptual para la creacin de base de datos, propuesto en 1976 por Peter Chen. El objetivo de es modelo es poder visualizar los objetos que pertenecen a la base de datos como entidades, junto con sus atributos y relaciones. En el modelo, se pueden representar: los datos vistos como entidades atributos o caractersticas de dichas entidades relaciones entre ellas cierta semntica del problema ciertas restricciones
5.4.1 Elementos
Entidad Es un objeto del mundo real que es distinguible de todos los dems. Puede tratarse de cualquier tipo de objeto, persona, empresa, cosa, informe, etc. Las entidades se representan grficamente como rectngulos, apareciendo su nombre en el interior. Las entidades a su vez, tienen atributos o propiedades. Existen dos tipos de entidades, fuertes y dbiles. Una entidad fuerte es independiente de la existencia de otra, mientras que una entidad dbil depende de la existencia de otra. Atributos Los atributos describen propiedades que poseen cada entidad o relacin. Grficamente se representan mediante unos crculos unidos mediante lneas a los dems objetos. Cada atributo posee un conjunto de valores asociados llamado dominio. El dominio se define como los valores posibles que puede tomar dicho atributo.
96
Se pueden distinguir varios tipos de atributos: Simples o compuestos. Un atributo simple es aquel que tiene un solo componente, es decir, es indivisible en partes ms pequeas. Un atributo compuesto es un atributo que se puede dividir en otros pequeos con significado propio, y que mantienen una afinidad comn. Derivados. Un atributo derivado es aquel que representa un valor formado a partir del valor de uno o varios atributos. Monovalorados o multivalorados. Un atributo monovalorado es aquel que solo tiene un valor para cada ocurrencia de la entidad o relacin, como por ejemplo la altura en una persona. Un atributo multivalorado tiene por el contrario varios valores para cada ocurrencia de la relacin o entidad, como puede ser el nmero de hijos. Relacin Es una correspondencia o asociacin entre dos o ms entidades. Cada relacin describe su funcin mediante un nombre. Su representacin grfica es un rombo con el nombre en el interior. Las entidades que estn involucradas en una determinada relacin se denominan entidades participantes. El nmero de participantes en una relacin es lo que se denomina grado de la relacin. Por lo tanto, una relacin en l que participan dos entidades es una relacin binaria. Si son tres las entidades ser una relacin ternaria, etc. La cardinalidad es con la que una entidad participa en una relacin especfica el nmero mnimo y el nmero mximo de correspondencias en las que puede tomar parte cada ocurrencia de dicha entidad. La participacin de una entidad en una relacin es obligatoria (total) si la existencia de cada una de sus ocurrencias requiere la existencia de, al menor, una ocurrencia de la otra entidad participante. Si no, la participacin es opcional (parcial).
97
Identificador Es un atributo o conjunto de atributos que determina de modo nico cada ocurrencia de esa entidad. UN identificador de una entidad tiene que cumplir: 1.- No pueden existir dos ocurrencias de la entidad con el mismo identificador. 2.- Si se omite cualquier atributo del identificador, la condicin anterior deja de cumplirse. Toda entidad tiene al menos un identificador y puede tener varios identificadores alternativos. Las relaciones no tienen identificadores.
98
5.4.2 Modelo Entidad Relacin de la base de datos
CIF
Nombre
Pliza
Correo
Efecto
Persona de contacto DNI
Asociacin
Calle DOMICILIO Nmero Provincia Clave
Telfono
Correo contacto
Piso Cdigo Postal
Poblacin
DNI
Nombre Primer Apellido Segundo Apellido
Letra
Tiene
1:N
Inicio Actividad
Voluntario
Fecha Alta
Fecha Baja
Ilustracin 5-3 Modelo entidad relacin BBDD
99
5.5 Modelo Relacional de la base de datos

Este modelo ofrece una visin ms textual y esquemtica de cmo ser la base de datos. Esta basado en la lgica de predicados y en la teora de conjuntos. Actualmente es el modelo ms usado para resolver problemas reales y administrar datos dinmicamente.
Asociacin (CIF, Nombre, Pliza, Correo, Efecto, Persona de contacto, DNI, Telfono, Correo de contacto, Calle, Nmero, Piso, Letra, Cdigo Postal, Poblacin, Provincia) UC/DC
Voluntario (Cod_Asociacin, DNI, Nombre, Primer Apellido, Segundo Apellido, Inicio actividad, Fecha Alta, Fecha Baja)
Ilustracin 5-4 Modelo relacional BBDD
100
5.5.1 Explicacin de Entidades y Atributos de la BBDD

En este apartado se explican las diferentes tablas de las que se compone la base de datos, as como los atributos de cada una de ellas. Tabla Asociacin
Atributos Nombre Pliza Efecto CIF (PK) Calle Nmero Piso Letra Cdigo Postal Poblacin Provincia Correo Asociacin Persona NIF Telfono Correo Clave Tipo de datos VARCHAR (80) VARCHAR (80) DATE VARCHAR (10) VARCHAR (80) VARCHAR (3) VARCHAR (3) VARCHAR (2) VARCHAR (8) VARCHAR (60) VARCHAR (60) VARCHAR (120) VARCHAR (120) VARCHAR (11) VARCHAR (15) VARCHAR (120) VARCHAR (20) Nulo NO NO NO NO SI SI SI SI SI SI SI NO SI SI SI SI NO NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL Predeterminado Descripcin Nombre de la asociacin Pliza de la asociacin Fecha de efecto de la pliza CIF de la asociacin Calle de residencia Nmero de la calle Nmero de piso Letra de piso Cdigo postal de residencia Poblacin de la asociacin Provincia de la asociacin Correo de la asociacin Persona de contacto NIF de la persona Telfono de la persona Correo de la persona Clave de acceso
Tabla 34 Descripcin detallada de los atributos de Asociacin
101
Tabla Voluntario
Atributos Nombre Apellido 1 Apellido 2 DNI (PK) Fecha Inicio Fecha alta Fecha baja Asociacin (FK) Tipo de datos VARCHAR (60) VARCHAR (60) VARCHAR (60) VARCHAR (15) DATE DATE DATE VARCHAR (10) Nulo NO NO SI NO SI SI SI NO NULL NULL NULL NULL Predeterminado Descripcin Nombre del voluntario Primer apellido del voluntario Segundo apellido del voluntario DNI del voluntario Fecha de Inicio del seguro Fecha de alta en la aplicacin Fecha de baja del seguro CIF de la asociacin
Tabla 35 Descripcin detallada de los atributos de Voluntario
102
5.6 Diagrama de clases

class dominio PdfPageEventHelper Pdf
Corre o
BaseDatos
-_baseDat os
-_baseDat os Voluntario
Domicili o
-_domicilio
-_voluntario -_voluntario
Asociacion
-_asociacion -_asociacion GestorAsociacion Administrador
-_administrador GestorAdministrador
Ilustracin 5-5 Diagrama de clases 1
103
class serv lets HttpServlet Acceso HttpServlet CerrarSesion
dominio:: GestorAdministrador
dominio:: GestorAsociacion
104
class administrador HttpServlet AdministradorAltaAsociacion HttpServlet AdministradorAltaAsociacionConfirmar HttpServlet AdministradorAltaAsociacionValidar HttpServlet AdministradorAltaVoluntario
HttpServlet AdministradorAltav oluntarioConfirmar
HttpServlet AdministradorArchiv o
HttpServlet AdministradorBaj aAsociacion
HttpServlet AdministradorBaj aVoluntario
HttpServlet AdministradorBuscarAsociaciones
HttpServlet AdministradorBuscarVoluntarios
HttpServlet AdministradorModificarDatosAsociacion
HttpServlet AdministradorModificarDatosVoluntario
HttpServlet ImprimirV oluntariosConsultados
HttpServlet MostrarAsociaciones
HttpServlet MostrarAsociacionesBaj a
HttpServlet MostrarAsociacionesBuscarVoluntario
HttpServlet MostrarAsociacionesModificar
HttpServlet MostrarAsociacionesModificarVoluntario
HttpServlet MostrarAsociacionesValidar
HttpServlet MostrarAsociacionesVoluntarioArchiv o
HttpServlet MostrarAsociacionVoluntarioBaj a
HttpServlet MostrarDatosAsociacion
HttpServlet MostrarDatosAsociacionesValidar
HttpServlet MostrarDatosVoluntario
HttpServlet MostrarDatosVoluntarioModificar
HttpServlet MostrarVoluntariosModificar
dominio:: GestorAdministrador
105
class asociacion HttpServlet AsociacionAltaVoluntario HttpServlet AsociacionAltaVoluntarioConfirmar HttpServlet AsociacionBaj aVoluntario HttpServlet AsociacionBuscarVoluntarios
HttpServlet AsociacionModificaDatosVoluntario
HttpServlet AsociacionModificarDatosAsociacion
HttpServlet ImprimirVoluntariosConsultadosAsociacion
HttpServlet MostrarDatosAsociacionModificar
HttpServlet MostrarDatosVoluntarioAsociacion
HttpServlet MostrarVoluntariosAsociacionBaj a
dominio:: GestorAsociacion
106
6 Desarrollo
6.1 Introduccin
La fase de desarrollo corresponde con la implementacin y documentacin de la aplicacin. Para ello, en primer lugar se ha requerido la eleccin de una plataforma de desarrollo, en este caso, NetBeans, que permite que las aplicaciones sean desarrolladas a partir de un conjunto de componentes de software (mdulos). Una vez elegida la plataforma, el lenguaje de programacin estaba claro, Java. Se trata de un lenguaje ya conocido y muy utilizado en las aplicaciones Web. Adems, permite aadir nuevas libreras gratuitas, tales como IText o Javamail, utilizadas en el desarrollo de la aplicacin, y fundamentales para cubrir las necesidades requeridas. Ms adelante se vern algunos ejemplos del cdigo utilizado. Respecto a la documentacin, se ha ido realizando al mismo tiempo que la codificacin, evitando as posteriores revisiones al cdigo para ver cual era el funcionamiento de un mtodo. Se ha generado Javadoc sobre todos los mtodos programados para la aplicacin, creando as una pequea API en donde se explican brevemente el funcionamiento de cada uno de ellos. El tiempo de desarrollo ha sido algo superior al estimado en un principio. El principal motivo fue el aprendizaje paralelo que se iba haciendo de las nuevas libreras a utilizar, lo que produjo constantes pruebas y modificaciones en el cdigo hasta dar con el resultado esperado. Finalmente, el desarrollo del proyecto se llevo a cabo satisfactoriamente, cumpliendo todos los requisitos establecidos, e intentando generar un cdigo y una documentacin lo ms reutilizable y eficiente posible, con vistas a recuperar este desarrollo y utilizarlo como base a una ms que probable futura aplicacin.
107
6.2 Explicacin cdigo IText

A continuacin se exponen ciertas partes del cdigo utilizado para generar PDF a travs de los datos obtenidos de la Base de Datos. Crear un documento:
public void abrirDocumento() { this.doc = new Document(); try { PdfWriter.getInstance(this.doc, this.response.getOutputStream()); } catch (Exception e) { e.printStackTrace(); }
this.doc.open(); }
Ilustracin 6-1 Cdigo para crear un documento
En primer lugar se crea una instancia de la clase Document, que ser donde se ir aadiendo toda la informacin del documento. Una vez creado el documento, se crea una instancia de PdfWriter, que ser el encargado de escribir la informacin sobre el flujo de salida escogido. Si no se genera ninguna excepcin, se proceder a abrir el documento.
108
Establecer que el documento sea un PDF.:
this.response.setContentType("application/pdf");
Ilustracin 6-2 Cdigo para establecer formato de documento
Para crear un archivo PDF, debemos establecer que la salida, en este caso el documento, sea en formato PDF. Para ello se utiliza el objeto response, perteneciente a los Servlets, y encargado de la respuesta de la aplicacin. Crear una tabla y rellenarla:
PdfPTable t = new PdfPTable(2); PdfPCell c;= new PdfPCell(new Paragraph("\n" + " " + "\n" + "\n", time)); c.setBackgroundColor(Color.lightGray); c.setHorizontalAlignment(c.ALIGN_CENTER); t.addCell(c); VOLUNTARIOS
Ilustracin 6-3 Cdigo para crear una tabla
Para crear una tabla, primero se debe instanciar un objeto PdfTable, cuyo parmetro de construccin ser el nmero de columnas que se desean tener. Para rellenarla, se deben ir creando celdas, en este caso, PdfCell, aadiendo el contenido de la celda y el formato de fuente. Ms tarde, se definir el color de fondo y su alineacin.
109
Insertar una imagen:

URL au = new URL("http://www.flexibletree.com/images/mapfre.JPG"); Image ima = Image.getInstance(au); ima.setAlignment(ima.ALIGN_LEFT); ima.scalePercent(80, 80); ima.setAbsolutePosition(10, 750); document.add(ima);
Ilustracin 6-4 Cdigo insertar una imagen
Para insertar una imagen, en primer lugar se debe indicar la direccin donde se encuentra, en este caso, una direccin web. Posteriormente, se instancia un objeto imagen con la direccin anterior. Los siguientes mtodos, definen la situacin y el tamao de la imagen dentro del documento. Por ltimo, solo queda aadirla al documento.
Insertar un prrafo:
Paragraph p = new Paragraph(Parrafo, cou2); p.setAlignment(p.ALIGN_CENTER); document.add(p);
Ilustracin 6-5 Cdigo insertar un prrafo
Si se desea insertar un prrafo en el documento, se deber crear en primer lugar una instancia Prrafo, con el texto que se desea aadir y el tipo de letra en su constructor. Posteriormente, se podrn definir las caractersticas que se quieran del prrafo, en este caso, su alineacin. Y finalmente, aadirlo en el documento.
110
Crear un pie de pgina:
Rectangle page = document.getPageSize(); Font time2 = new Font(Font.HELVETICA, 6, Font.NORMAL); String parrafo1 = null; parrafo1 = " Corredura de Seguros."; PdfPTable foot = new PdfPTable(1); Paragraph p = new Paragraph(parrafo1, time2); p.setAlignment(p.ALIGN_CENTER); PdfPCell cell = new PdfPCell(p); cell.setBorderColor(Color.WHITE); cell.setHorizontalAlignment(cell.ALIGN_CENTER); cell.setVerticalAlignment(cell.ALIGN_CENTER); foot.addCell(cell); foot.setHorizontalAlignment(foot.ALIGN_CENTER); foot.setTotalWidth(page.getWidth() - document.leftMargin() - document.rightMargin()); writer.getDirectContent()); docWriter.setPageEvent(new Pdf());
Ilustracin 6-6 Cdigo insertar un pie de pgina
Esta tarea tal vez sea la que agrupa ms elementos a utilizar. Como se puede ver, hay un prrafo, que ser el que contenga el texto definido. Una celda donde meter el prrafo y poder recuadrarlo, perteneciente a la tabla PdfTable, la que definir en qu posicin debe ir el pie de pgina.
111
La ltima lnea, ser la que crear una nueva pgina y un nuevo pie de pgina cuando reciba un evento de docWriter.
6.3 Explicacin cdigo JavaMail

A continuacin se explican algunos fragmentos de cdigo utilizados para la creacin y envo de correos a travs de la librera JavaMail. Constructor de Correo:
public Correo(String host, String from) { this.props = new Properties(); this.props.setProperty("mail.smtp.host", host); this.props.setProperty("mail.smtp.starttls.enable", "true"); this.props.setProperty("mail.smtp.port", "25"); this.props.setProperty("mail.smtp.user", from); this.props.setProperty("mail.smtp.auth", "true");
Ilustracin 6-7 Cdigo constructor correo
En primer lugar, se debe crear un nuevo correo a travs de esto constructor, donde se definirn las propiedades requeridas para que el envo sea satisfactorio. Se deben establecer cinco propiedades, la primera de ellas ser el host del servidor de correos, que sern pasados como argumento junto con el remitente del correo, es decir, la direccin de correo desde la que se mandar. El resto de atributos sern especficos para cada servidor, en este caso, se utilizar el puerto 25, el servicio de autentificacin debe estar activo igual que starttls.
112
Enviar correo:
public void enviar(String to, String de, String asunto, String clave, String texto) throws Exception { try { Session session = Session.getDefaultInstance(this.props); MimeMessage message = new MimeMessage(session); message.setFrom(new InternetAddress(de)); message.addRecipient(Message.RecipientType.TO, new InternetAddress(to)); message.setSubject(asunto); message.setText(this._texto, "ISO-8859-1", "html"); Transport t = session.getTransport("smtp"); try { t.connect(this.props.getProperty("host"), de, clave); t.sendMessage(message, message.getAllRecipients()); } catch (Exception e) { throw new Exception("No se ha podido mandar el correo, correo incorrecto");} t.close();
Ilustracin 6-8 Cdigo enviar correo
Para poder enviar correos se debe crear en primer lugar una Session con las propiedades anteriormente definidas en el constructor. Posteriormente se crea el mensaje, con el paso de sesin en el constructor. Se definen en este objeto el remitente, destinatario, asunto, texto y formato de texto.
113
Finalmente, se crea un objeto transport con el nombre del protocolo a utilizar. Se establece la conexin mediante el nombre de usuario y la contrasea, y se enva el mensaje a los destinatarios seleccionados. Una vez acabado, se cierra la conexin. Enviar correo con archivo adjunto:
public Multipart incluirFichero(Multipart multipart, BodyPart messageBodyPart, Vector ficheros) throws Exception { int i = 0; ByteArrayOutputStream bs = null; while (i < ficheros.size()) { try { messageBodyPart = new MimeBodyPart(); bs = (ByteArrayOutputStream) ficheros.elementAt(i); messageBodyPart.setDataHandler(newDataHandler(new ByteArrayDataSource(bs.toByteArray(), "application/pdf"))); messageBodyPart.setFileName("documento" + i + ".pdf"); i++; multipart.addBodyPart(messageBodyPart); bs.reset(); } catch (Exception e) { throw new Exception("Error al incluir el fichero"); } } bs.close();
Ilustracin 6-9 Cdigo enviar correo con adjunto
114
Si se desea enviar archivos a travs de un correo, se debe crear un objeto que una el cuerpo del mensaje (MimeBodyPart) con el archivo que se quiere adjuntar (DataHandler. ByteArrayDataSource), especificando en este ultimo el tipo de documento que se quiere obtener, en este caso, un archivo PDF. Una vez instanciadas estas partes, se creara un ByteArrayOutputStream, el buffer de salida que contiene toda la informacin del archivo. El proceso de creacin de archivo se iterar tantas veces como archivos se quieran adjuntar, y en todas ellas los pasos a seguir sern los siguientes: Creacin del cuerpo del mensaje Se pasa al buffer de salida el contenido el fichero, obtenido a partir de un Vector. Se crea la clase que maneje los datos, DataHandler, pasandole como argumentos la informacin y el tipo de fichero. Se etiqueta el archivo mediante un nombre. Aade el cuerpo del mensaje al mensaje multiparte. Iteracin del bucle. Reset al buffer para prepararlo para la carga de nueva informacin.
Una vez se termine el bucle, el buffer se cerrar y se devolver el mensaje multiparte creado junto con los adjuntos requeridos.
115
7 Pruebas
Prueba 1 (P1). Escenario: Entrar en la aplicacin con un usuario y clave para administrador. Comprobar que se muestra el men correspondiente. Subprueba 1.1 (S1.1). Entrar en la aplicacin como una asociacin. Comprobar que se muestra el men correspondiente. Subprueba 1.2 (S1.2). Entrar en la aplicacin con un usuario o clave incorrecta. Comprobar que el sistema detecta que el acceso es errneo y que muestra por pantalla el error. Prueba 2 (P2). Escenario: Una vez dentro de la aplicacin como administrador, aadir una nueva asociacin en la base de datos. Comprobar que el proceso se ha realizado correctamente, junto con el envo de los correos pertinentes. A continuacin e muestran los datos utilizados.
116
Nombre: Prueba1 Nmero de pliza: 41235NK324 Efecto: 21-12-2008 CIF: 986986J Correo electrnico: pruebaproyecto@gmail.com Calle: Calle Mayor Nmero: 2 Piso: 4 Letra: D Cdigo Postal: 28960 Poblacin: Madrid Provincia: Madrid
Ilustracin 7-1 Prueba aadir asociacin
Subprueba 2.1 (S 2.1). Se introducen campos errneos, como una fecha de efecto incorrecta o campos obligatorios en blanco. Prueba 3 (P3). Escenario: Se validar una asociacin una vez recibida la confirmacin de la asociacin. Comprobar que se manda el correo de validacin a la asociacin junto con la clave Para ello, se utilizan los siguientes datos:
Persona de contacto: Pedro DNI: 32147886
117
Aplicacin Web para la gestin de empresas de voluntariado Telefono de contacto: 65698789 Correo de contacto: pedroprevigalia@gmail.com Ilustracin 7-2 Prueba validar asociacin
Subprueba 3.1 (S 3.1). Los datos introducidos contendrn algn error, como puede ser un error en el formato del DNI, o dejar vacio algn campo. El sistema debe gestionar estos errores y mostrar por pantalla los campos errneos.
Prueba 4 (P4). Escenario: Se proceder a dar de baja una asociacin. Comprobar que una vez que se borre la asociacin, se borran los voluntarios pertenecientes a ella. Subprueba 4.1 (S 4.1). No se marcar ninguna asociacin para borrar, por lo que se espera que el sistema una vez se intente validar dicha opcin, muestre un mensaje donde aparezca que no se ha marcado ninguna asociacin.
Prueba 5 (P5). Escenario: Modificar los datos de una asociacin Comprobar que se modifican correctamente. Nombre: Prueba 2 CIF: 9867897
Ilustracin 7-3 Prueba modificar asociacin
Subprueba 5.1 (S 5.1). Se modifican campos con valores incorrectos. Comprobar que el sistema notifica al usuario los errores cometidos en al insercin de los datos.
118
Subprueba 5.2 (S 5.2). Se reenviar la clave de acceso al correo de la persona de contacto dentro de la asociacin. Comprobar que le llega el correo junto con la clave.
Prueba 6 (P6). Escenario: Se procede a dar de alta a voluntarios dentro de una asociacin manualmente. Para ello, se rellenan voluntarios de prueba y se seleccionar una asociacin donde aadirlos. Comprobar que se dan de alta todos los voluntarios, y se envan los correos correspondientes junto con sus certificados. Nombre Primer apellido Segundo apellido DNI V1 A1 A1 12345698 V2 A2 A2 2345567 V3 A3 A2 2349890V
Ilustracin 7-4 Prueba aadir voluntarios
Subprueba 6.1 (S 6.1). Se introducirn campos incorrectos y vacios para dar de alta a los voluntarios. Si existe algn error, el sistema debe detectar antes de validar las incorrecciones, e indicar aquellos voluntarios que contienen fallos en sus campos. Nombre Primer apellido Segundo apellido DNI V1 A1 12345698 V2 A2 2345567 V3 A3 A2
Ilustracin 7-5 Prueba aadir voluntarios incorrectos
119
Prueba 7 (P7). Escenario: Dar de alta a los voluntarios a travs de un archivo de texto con un formato determinado. Comprobar que los voluntarios son aadidos correctamente y que se enva el correo correspondiente. Subprueba 7.1 (S 7.1). Se da de alta a los voluntarios a travs de un archivo. El formato del archivo no es el correcto, y los voluntarios tienen campos que no se corresponden. El sistema debe de sacar por pantalla los voluntarios errneos junto con los fallos de cada uno.
Prubea 8 (P8). Escenario: Dar de baja a voluntarios. Comprobar que se borran de la asociacin correspondiente y de la base de datos. Subprueba 8.1 (S 8.1). Establecer una fecha de baja para los voluntarios. Sealar aquellos voluntarios en los que se desee establecer la fecha de baja, y rellenar en el formato correcto la fecha. Subprueba 8.2 (S 8.2). Establecer una fecha de baja errnea. El sistema deber informar por pantalla al usuario del fallo del fallo de formato en la fecha.
Prueba 9 (P9). Escenario: Modificar los datos de algn voluntario. Seleccionar una asociacin y escoger a un voluntario para modificar sus datos. Comprobar que los cambios se efectan correctamente. Subprueba 9.1 (S 9.1). Modificar los datos de un voluntario por otros incorrectos. El sistema debe informar al usuario de los errores cometidos, y no dejar modificarlos hasta que todos sean correctos.
120
Prueba 10 (P10). Escenario: Consultar asociaciones a travs de unos parmetros de bsqueda. La salida debe ser un listado de las asociaciones con sus datos correspondientes que coincidan con los criterios buscados. A continuacin se muestran los parmetros usados.
Nombre: A CIF: 2 Provincia: Madrid Ilustracin 7-6 Prueba consultar asociaciones
El sistema debe mostrar todas aquellas asociaciones que comiencen por la letra a y su CIF empiece por 2. A su vez, se realiza el filtro por las asociaciones pertenecientes a la Comunidad de Madrid. Subprueba 10.1 (S 10.1). No se utilizar ningn parmetro de bsqueda. La aplicacin deber mostrar un listado completo de las asociaciones dadas de alta en el sistema.
Prueba 11 (P11). Escenario: Se realiza una consulta sobre la base de datos de voluntarios. Se escoge una asociacin y se establecen unos criterios e bsqueda para los voluntarios. El sistema debe mostrar un listado de los voluntarios que coincidan con los parmetros, tanto en su comienzo como en su totalidad.
Nombre: Antonio Fecha alta: 12-02-2003 Ilustracin 7-7 Prueba consultar voluntarios
La aplicacin mostrar todos los voluntarios que se llamen Antonio y su fecha de alta sea la establecida.
121
Subprueba 11.1 (S 11.1). Se seleccionar en la pestaa de asociaciones la opcin Todas. La aplicacin deber mostrar el listado completo de voluntarios que existen en todas las asociaciones.
Modo asociacin Prueba 12 (P12) Escenario: Modificar los datos pertenecientes a la asociacin. Se modifican ciertos parmetros con el fin de comprobar si el proceso de actualizacin se realiza correctamente. Los parmetros modificados son los siguientes: CIF: 2349789 Correo: segundapruebaproyecto@gmail.com Calle: Alfonso XIII
Ilustracin 7-8 Prueba modificar asociacin
La aplicacin modificar los parmetros correspondientes, y mostrar por pantalla si el proceso ha terminado. Subprueba 12.1. (S 12.1) Se intentan modificar ciertos parmetros por otros incorrectos. La aplicacin deber informar al usuario de los parmetros errneos, y no los actualizar hasta que todos ellos estn correctos.
Prueba 13 Escenario: Proceso de alta de los voluntarios para la asociacin. Se rellenan diferentes voluntarios para darlos de alta en la aplicacin. El sistema deber generar los correos y certificados correspondientes, y mostrar por pantalla los voluntarios que hallan sido correctamente almacenados.
122
Subprueba 13.1 (S 13.1) Se dar de alta a voluntarios con formato de campos incorrecto. La aplicacin deber detectar estos fallos, e informar al usuario de ello.
Prueba 14 (P14) Escenario: Proceso de bsqueda de voluntarios a partir de los parmetros deseados. La aplicacin deber mostrar un listado de los voluntarios que coincidan con los parmetros de bsqueda. A su vez, debe permitir generar un libro de registro en formato PDF del listado obtenido. Los parmetros usados son estos: Nombre: P Primer apellido: Gonzalez Fecha de alta: 12-01-2003
Ilustracin 7-9 Prueba consultar voluntarios
El sistema mostrar por pantalla un listado que contenga a los voluntarios cuyo nombre comience por P, su primer apellido sea Gonzlez y la fecha de alta sea el 12 de enero de 2003. Subprueba 14.1 (S 14.1) Se realizar una bsqueda sobre los voluntarios sin criterio de bsqueda. El sistema debe generar un listado con todos los voluntarios pertenecientes a la asociacin que lo consulta.
Resultado de las pruebas P1
123
S 1.1

S 1.2
P2
S 2.1
P3
S 3.1
P4
S 4.1
P5
S 5.1
S 5.2
P6
S 6.1
124
P7

S 7.1
P8
S 8.1
S 8.2
P9
S 9.1
P10
S 10.1
P11
S 11.1
P12
S 12.1
125
P13

Tabla 36. Resultados de las pruebas
S 13.1
P14
S 14.1
126
8 Conclusiones
En este apartado se detallan los problemas que han surgido en el desarrollo de la aplicacin, junto con los objetivos alcanzados y conclusiones finales.
8.1 Problemas encontrados al realizar el proyecto

Durante el tiempo que ha durado la realizacin del proyecto, han surgido numerosos problemas, gran parte propiciados por la inexperiencia en un desarrollo de este tipo. A continuacin se exponen los ms destacados junto con su solucin. El primer problema que surgi, fue el cambio de proyecto repentinamente. Siguiendo el mismo tipo de aplicacin Web del proyecto anterior, se tuvo que cambiar un desarrollo ya avanzado por otro completamente nuevo, aunque se pudo reutilizar gran parte del anterior. Los cambios retrasaron el tiempo estimado, hubo que recalcular todo de nuevo, pero se consider que el cambio sera beneficioso. Finalmente y tras acabar el proyecto, se puede decir que se acert al desarrollar esta aplicacin, se le ha dado un uso que seguramente la otra no hubiera tenido. Una vez decidida la aplicacin a realizar, el siguiente problema fue qu lenguajes utilizar. Previamente, para el otro proyecto se utilizaron herramientas como Java, Jsp o MySQL, y se deba tomar la decisin de optar por estas o plantearse el uso de otras nuevas. Debido a los conocimientos adquiridos anteriormente, se decidi optar por las herramientas del otro proyecto, y sin lugar a dudas, fue un acierto. Como se puede ver en apartados anteriores, el software utilizado es uno de los ms adecuados para el desarrollo Web, permitiendo gran flexibilidad y reutilizacin a la hora de programar. Disponen de una amplia documentacin va Internet, permitiendo un aprendizaje rpido, a travs de ejemplos y tutoriales.
127
El uso de Java en el desarrollo, permiti usar varias de sus libreras gratuitas, entre las que se encuentran Itext o JavaMail. Supuso un incremento en el tiempo de aprendizaje, aunque una vez dominadas, se pudo ver la potencia de la que disponan, permitiendo acortar el tiempo de programacin de la aplicacin. Uno de los principales problemas que ha tenido el proyecto, ha sido el cambio constante por parte del cliente de los requisitos de la aplicacin. Se realiz un primer anlisis de requisitos, especificado claramente por el cliente, pero a medida que el desarrollo iba avanzando, los requisitos fueron cambiando. Hubo que modificar gran parte de la aplicacin, ya que o bien el cliente no lo haba pensado bien en un principio, o bien al ver el resultado final se dio cuenta de los fallos que haba cometido. En todo momento se intento respetar el diseo y los requisitos que el cliente haba elegido. Todas estas modificaciones no hicieron ms que retrasar el tiempo de desarrollo. Finalmente, la aplicacin se dio por terminada, y actualmente, esta en periodo de mantenimiento. Por ltimo, destacar la laboriosa tarea que es instalar y configurar las aplicaciones necesarias para desarrollar el proyecto. Muchas de ellas si se configuran mal desde un principio, guardan los valores de instalacin cuando se desinstalan, por lo que hay que borrar ciertos archivos de configuracin para volver a empezar de cero. Sincronizarlas con el NetBeans supuso tambin una gran cantidad de tiempo, e incluso una vez aprendido el mtodo, sigue siendo una tarea nada fcil.
8.2 Objetivos
El principal objetivo de este proyecto fin de carrera, era crear una aplicacin que permitiese gestionar los seguros de los voluntarios pertenecientes a las distintas asociaciones que tienen contratadas sus plizas a travs de la empresa administradora. El sistema deba generar automticamente los certificados de cada asegurado, y emitirlo a la asociacin
128
correspondiente. Solo esta tarea, ya significaba un gran ahorro en tiempo y costes para la empresa administradora. Se podra asegurar que el principal objetivo del desarrollo se ha cumplido, pese al gran trabajo que ha supuesto, y que debido a factores tanto internos como externos, el tiempo estimado para el desarrollo del proyecto ha sido mayor de lo esperado. A continuacin se exponen los objetivos ms destacados. 1.- Realizar una herramienta que permita a la empresa administradora gestionar las altas, bajas y modificaciones de los asegurados. 2.- Almacenar en una base de datos externa a la empresa administradora, los datos de las asociaciones y asegurados, con el fin de tener en otro soporte de almacenamiento toda la informacin de la que disponen. 3.- El sistema deber contar con una interfaz sencilla e intuitiva, que permita a los usuarios utilizarla sin ninguna dificultad. 4.- La aplicacin debe ser capaz de generar todos los documentos pertinentes, contratos, certificados, listados, etc., y enviarlos o mostrarlos por pantalla segn proceda en cada tarea. 5.- El sistema debe de gestionar cualquier error o suceso inesperado que se registren al uso de la aplicacin. Deber informar al usuario e impedir que el proceso se realice cuando se produzca un fallo, ya sea causado por el usuario o por la aplicacin. 6.- Disear una aplicacin donde su mayor parte sea reutilizable en un futuro, bien para redisear una nueva y poder usarla como base para su realizacin, o bien para modificarla y que sirva para otras empresas que se dedican al mismo sector.
129
8.3 Conclusiones finales

Destacar en primer lugar el aprendizaje tanto personal como profesional que ha supuesto la realizacin de este proyecto. Se han adquirido numerosos conocimientos en diversas ramas de la informtica, hoy en da usadas por muchsimas empresas para el desarrollo de software. Entre ellas, cabe destacar las siguientes: Ingeniera del software. Desarrollo de aplicaciones Web. Diseo y desarrollo de bases datos sobre MySQL. Desarrollo en Java. Diseo de la interfaz en Jsp.
A su vez, se han desarrollado cualidades y aptitudes tanto personales como profesionales: Creatividad. Responsabilidad. Aprender a ser autodidacta en algunos aprendizajes. Aptitud para la resolucin de problemas. Constancia. Capacidad de organizacin. Capacidad de adaptacin. Paciencia.
130
9 Trabajos futuros
Tanto al comienzo como a medida que se iba desarrollando el proyecto, fueron surgiendo varias ideas y mejoras que a da de hoy an no se han realizado. A continuacin se exponen las que se han considerado ms interesantes y factibles en un futuro. Creacin de una nueva interfaz para el administrador, donde poder modificar toda la aplicacin. Para ello, se deberan programar ms funcionalidades de las que ahora tiene la aplicacin, para que el administrador desde su men, pueda activar o desactivar aquellas que considere necesarias dependiendo de la etapa en la que se encuentre la gestin. Alta de asociaciones realizada por ellas mismas. Actualmente, en la aplicacin solo pueden darse de alta asociaciones a travs del administrador. En un futuro se podra plantear el alta por parte de las asociaciones, que fuesen ellas mismas quienes rellenen sus propios datos, y que el administrador tan solo se encargase de validar el alta. Dar opcin en las tablas y listados de ordenarlos por el campo que el usuario desee. Esta requisito no ha sido exigido, ya que al administrador tan solo le interesa que los listados estn ordenados a travs del campo Primer apellido, sin embargo, sera una buena mejora implementar esta posibilidad, que, aunque en un principio no es imprescindible, si que puede facilitar bsquedas en algunos momentos. Ofrecer al asegurado la posibilidad de entrar en la aplicacin a consultar sus datos y fecha de vencimiento del seguro
131
Incluir un nuevo usuario en la aplicacin, el asegurado. A travs de un nombre y una clave generada dinmicamente para cada uno, ofrecer la posibilidad de consultar sus datos y fechas del seguro. Optimizar el acceso a la aplicacin mediante un Pull de conexiones. Actualmente, las conexiones por parte de los usuarios a la aplicacin se esta gestionando de una manera efectiva, creando y cerrando conexiones cuando se este usando la base de datos. Sin embargo, una mejora mas eficiente sera crear un Pull de conexiones, lo que dotara al sistema de una rapidez mucho mayor. Dotar a la aplicacin de una mejor interfaz. Se podra suprimir el diseo con frames, y optar por un diseo ms vistoso e intuitivo. Aunque el que se ha realizado cumple perfectamente con todo lo requerido, siempre queda un cierto grado de mejora que en este caso podra realizarse sin ningn problema. Ampliar la aplicacin ofreciendo la posibilidad de gestionar seguros areos. Esta fue una de las primeras mejoras que se planteo, ya que el cliente tena en mente estas dos aplicaciones. Habra que crear una nueva aplicacin, o modificar gran parte de la interfaz de esta para poder gestionar las dos a la vez. Esta mejora muy posiblemente acabe realizndose, puesto que, al igual que la aplicacin desarrollada, reducir el tiempo de gestin de los asegurados por parte de la empresa administradora.
132
Apndice A. Manual de instalacin

A.1. Hardware y software necesario.
A.1.1. Hardware
* El hardware necesario para instalar en la aplicacin depender de qu medio usemos para la instalacin. La aplicacin permite instalarse tanto en un ordenador local, instalando el software necesario para simular un servidor, o en un servidor que permita el acceso a los dems usuarios. En un principio, la aplicacin esta dirigida para instalarla en un servidor Web y poder usarla a travs de Internet. Por lo tanto a continuacin se explican los distintos requisitos para las diferentes instalaciones.
A.1.1.1 Instalacin en un ordenador personal

* Procesador Intel Core Duo 1.06 GHz superior. * Un mnimo de 512 Mb de memoria RAM. * 20 Mb de disco duro para la instalacin de la aplicacin. Si no se dispone las utilidades necesarias para poder utilizarla, se requerirn 280 Mb de disco duro.
A.1.1.2 Instalacin en servidor Web

* Procesador Intel Core Duo 2 Ghz superior. * Un mnimo de 1 Gb de memoria RAM. * 20 Mb de disco duro para la instalacin de la aplicacin.
133
A.1.2. Software
* Referente al software, tambin se dispone de dos posibilidades, dependiendo si la instalacin se realizar sobre un servidor o sobre un ordenador personal.
A.1.2.1 Instalacin en un ordenador personal

MySQL 5.1.30 Apache HTTPD 2.2.11 PhpMyAdmin 3.1.1 Navegador Sistema operativo Windows Xp o superior.
A.1.2.2 Instalacin en un servidor Web

* Apache Tomcat 5.5 o superior con Java * MySQL 5 o superior. * MySQL WebAdmin * Sistema operativo Windows Server o Linux.
A.2. Instalacin de la aplicacin.

A.2.1 Instalacin en un ordenador personal
Para la instalacin de la aplicacin en un ordenador personal se debe instalar el software correspondiente si este no esta instalado previamente en la mquina. Para ello, se puede optar por dos opciones, una muy sencilla, instalando un paquete que contiene todos los elementos necesarios para su ejecucin, o bien, una ms complicada instalando uno a uno los componentes. Se explicar con imgenes y sencillos pasos la instalacin del paquete entero, dejando libertad al usuario para la instalacin componente por componente.
Descarga del software necesario a travs de la siguiente pgina.
134
http://www.apachefriends.org/es/xampp.html
Se mostrar la siguiente pantalla, donde debemos elegir el sistema operativo donde queremos instalar el software.
Ilustracin 8-1 SO para Xampp
Una vez seleccionado el sistema operativo, se muestra la pantalla de descargas, donde se debe elegir el archivo Installer en la opcin XAMPP Windows 1.7.0.
135
Ilustracin 8-2 Descargar Xampp
Se descargar el archivo en la ruta indicada. Doble click en la aplicacin, y comenzar el proceso de instalacin.
Ilustracin 8-3 Proceso Instalcin Xampp
136
Siga las instrucciones de la instalacin hasta completarla. Una vez instalado, ejecuta Xampp si no se ha ejecutado automticamente.
Ilustracin 8-4 Ejecucin Xampp
Escriba en su navegador http://127.0.0.1. Aparecer la siguiente pantalla de bienvenida, donde deber escoger el lenguaje a utilizar.
137
Ilustracin 8-5 Ventana principal navegacin Xampp
Una vez escogido el idioma, se mostrar la siguiente pantalla, el panel de control, desde donde gestionar Xampp.
138
Ilustracin 8-6 Men navegacin Xampp
Se debe crear una nueva base de datos. Para ello, dirjase a phpMyAdmin, donde podr seleccionar dicha opcin. El nombre de la base de datos ser previgalia.
139
Ilustracin 8-7 Crear una base de datos Xampp
140
Una vez creada la base de datos, importamos el archivo que contiene los parmetros necesarios.
Ilustracin 8-8 Importar archivo en Xampp
Terminadas estas operaciones, ya esta montada la base de datos. Si todo ha salido correctamente, debe quedar una estructura igual que la de la imagen inferior.
Ilustracin 8-9 Base de datosXampp
141
Cree un directorio dentro de Mis Documentos, llamado NetBeansProyects, y dentro de este otro llamado Previgalia, que ser donde debe almacenar todo el contenido de la aplicacin, dejando la estructura interna de la aplicacin tal y como esta.
/build/ build.xml /dist/ /nbproyect/ /src/ /test/ /web/
Ilustracin 8-10 Directorios servidor
Si la instalacin ha sido satisfactoria y ha seguido los pasos correctamente, podr accedes a la aplicacin a travs de su navegador mediante la siguiente direccin: http://localhost:8080/Previgalia/
A.2.2 Instalacin en un servidor web
Si ya ha escogido el servidor web donde alojar la aplicacin, deber seguir los siguientes pasos para instalarla.
Siga los pasos de la instalacin en ordenador personal sobre la creacin de la base de datos. Para ello, deber acceder al panel de control que le ofrezca su servidor web.
142
Una vez creada, deber acceder al FTP de su pgina, donde dispondr de una estructura de directorios parecida a esta.
Ilustracin 8-11 Estructura directorios ftp
Dirjase al directorio httpdocs, donde deber copiar las carpetas que contiene la aplicacin.
Si estas carpetas no coincidiesen, la estructura que debe tener es la siguiente:
/httpdocs/ /httpdocs/images/ /httpdocs/WEB-INF/classes/com/previgalia/

Ilustracin 8-12 Estructura directorios 2 ftp
En el directorio principal, debern ir los archivos con formato .jsp. El directorio images contendr las imgenes de la aplicacin. El ltimo directorio, ser el que contenga los archivos compilados.
Finalmente, para acceder a la aplicacin, deber ingresar en el dominio que contrat.

143
Apndice B. Manual de usuario.

Consideraciones generales. En este aparatado se describen consideraciones que todo usuario debe tener en cuenta al usar la aplicacin. - El estado de la sesin pasar a inactivo si transcurren 30 minutos del ltimo uso de sesin. - Todo usuario deber desconectar la sesin una vez haya acabado de realizar las gestionar pertinentes. - Siempre que se desee, se puede consultar la ayuda en el men principal, si hubiese algn problema que con la ayuda no pudiese resolver, podr ponerse en contacto con el administrador en la direccin de correo que se facilita en la parte superior derecha. - La aplicacin esta testada en diversos navegadores, si por algn casual utiliza uno en el que la aplicacin no se visualizase correctamente, pngase en contacto con el administrador. - Tenga especial atencin en la insercin de datos, cualquier error que cometa le ser informado por pantalla para que puede resolverlo. - Si no le llegasen los correos que el sistema enva al realizar diversas acciones, mire en primer lugar en su buzn de correo en la carpeta Correo no deseado. Si an as no lo ha recibido, pngase en contacto con el administrador para que este lo pueda volver a enviar. - Algunos ficheros que el sistema genera tienen formato PDF, para visualizarlos correctamente, deber tener instalado Adobe Acrobat Reader.
144
Pgina de bienvenida
Pantalla de bienvenida para todos los usuarios del sistema. Para acceder se requiere un nombre de usuario y una contrasea, pulsando posteriormente sobre Iniciar sesin.
Ilustracin 9-1 Pgina Bienvenida aplicacin
Contrasea o usuario incorrecto Si el usuario o la contrasea es incorrecta, se mostrar este mensaje de error, teniendo que volver a introducir el usuario o la contrasea correctamente.
Ilustracin 9-2 Inserccin datos aplicacin
145
Modo Administrador
Men administrador Si el acceso ha sido correcto por parte del administrador, se le mostrar esta pantalla, donde tendr acceso a todas las opciones del men.
Ilustracin 9-3 Pantalla principal administrador
Gestionar Asociaciones Alta Asociacin Pantalla que permite al administrador comenzar el proceso de alta de una nueva asociacin. Para ello, en primer lugar deber acceder a la opcin Nueva Asociacin, donde introducir los datos correspondientes a esta. Una vez introducidos y validados por la asociacin, el administrador validar los nuevos datos y dar por completado el alta de la nueva asociacin.
146
Ilustracin 9-4 Pantalla Alta asociacin administrador
Nueva Asociacin El administrador deber rellenar los datos de la asociacin, siendo obligatorios aquellos campos que lo soliciten. Si algn dato es incorrecto se mostrar por pantalla el error oportuno. Una vez completados los campos, deber pulsar dar de alta, para posteriormente comprobar los datos introducidos y confirmarlos.
Ilustracin 9-5 Pantalla modificar asociacin administrador
Validar Asociacin Una vez completado el proceso anterior, la asociacin recibir la peticin de alta junto con los datos introducidos. Si todo esta correcto, informar de ello al administrador para que
147
este valide el proceso y complete le informacin que falta. Una vez validada, se envian el correspondiente usuario y contrasea a la asociacin. Esta primera pantalla muestra al administrador las asociaciones disponibles para su validacin.
Ilustracin 9-6 Pantalla seleccin asociacin a validar
Esta segunda pantalla, muestra la asociacin escogida junto con los campos a rellenar.
Ilustracin 9-7 Pantalla validacin asociacin
148
Baja Asociacin El administrador puede dar de baja a las asociaciones siempre y cuando estas lo hayan requerido, o bien la asociacin haya desaparecido. En cualquier caso, el sistema mostrar al administrador una lista con las asociaciones disponibles, para que elija aquellas que tengan que ser dadas de baja.
Ilustracin 9-8 Pantalla baja asociacin
Modificar Asociacin Si por algn motivo el administrador tuviese que modificar algn dato de una asociacin, se le mostrar una lista con las asociaciones disponibles, de la que deber escoger aquella que desee modificar. Una vez elegida, el sistema mostrar en pantalla todos los datos disponibles de la asociacin. El administrador modificar aquellos que estn incorrectos.
Esta ser la lista de asociaciones que ver el administrador.
149
Ilustracin 9-9 Pantalla eleccin asociacin a modificar
Una vez elegida, se muestran los datos. Si fuese necesario, se podr reenviar desde esta pantalla, la contrasea a la asociacin, siempre bajo peticin de esta. Para ello tan solo deber pulsar sobre el botn Reenviar Clave.
Ilustracin 9-10 Pantalla modificar asociacin administrador
150
Gestionar Voluntarios Alta Voluntario Para dar de alta a un voluntario, el administrador tendr que rellanar los campos obligatorios para cada voluntario, seleccionando una vez haya terminado, la asociacin en la que tienen que ser dados de alta. El sistema comprobar que no falta ningn dato, teniendo que confirmar el administrador dicha comprobacin. Pantalla de alta de voluntarios.
Ilustracin 9-11 Pantalla alta voluntarios administrador
Pantalla de confirmacin de los voluntarios.
Ilustracin 9-12 Pantalla confirmacin alta voluntarios administrador
151
Alta de voluntarios desde archivo Para simplificar y acelerar el proceso de alta, se permite al administrador la opcin de introducir en el sistema a voluntarios a travs de un fichero de texto con un formato determinado.
Ilustracin 9-13 Pantalla alta voluntarios desde archivo
Si hubiese algn error en los voluntarios que hay en el archivo, se mostrar la siguiente pantalla donde se informar de los errores que tiene cada voluntario.
Ilustracin 9-14 Pantalla error alta voluntario desde archivo
152
Baja voluntario Se muestra al administrador una lista de las asociaciones que contienen voluntarios a dar de baja. Este, selecciona una de ellas, a continuacin, el sistema carga en pantalla los datos de los voluntarios pertenecientes a la asociacin escogida. El administrador puede hacer dos acciones, o bien eliminar al voluntario de la base de datos, o bien establecer una fecha de baja para cada uno de los voluntarios seleccionados.
Pantalla de seleccin de asociacin.
Ilustracin 9-15 Pantalla seleccin asociacin baja de voluntario
Pantalla de baja de voluntarios.
153
Ilustracin 9-16 Pantalla baja de voluntarios
Modificar voluntario Pantalla que permite la modificacin de un voluntario. El administrador deber elegir la asociacin donde este el voluntario a modificar. Una vez elegida, deber seleccionar el voluntario, y una vez seleccionado, el sistema mostrar los datos de este para que puedan ser modificados.
Pantalla seleccin asociacin.
Ilustracin 9-17 Pantalla eleccin asociacin modificar voluntarios
154
Pantalla seleccin voluntario.
Ilustracin 9-18 Pantalla seleccin voluntario modificar
Pantalla datos del voluntario.
Ilustracin 9-19 Pantalla modificar voluntario
Consultas Consultar Asociaciones Si el administrador desea realizar una consulta sobre las asociaciones disponibles, deber rellanar aquellos campos por los cuales quiere que se realice el criterio de bsqueda.
155
Pantalla de consulta de asociaciones.
Ilustracin 9-20 Pantalla consultar asociaciones
Pantalla de lista de asociaciones.
Ilustracin 9-21 Pantalla asociaciones consultadas
156
Consultar voluntarios Permite realizar una bsqueda sobre los voluntarios introducidos en la base de datos. A su vez, el administrador puede solicitar un libro de registro sobre los voluntarios seleccionados presionando sobre el botn imprimir.
Pantalla de consulta de voluntarios.
Ilustracin 9-22 Pantalla consultar voluntarios
Pantalla de lista de voluntarios.
Ilustracin 9-23 Pantalla voluntarios consultados 157
Modo Asociacin
Men Asociacin Si el acceso ha sido correcto por parte de la asociacin, el sistema presentara en pantalla el siguiente men.
Ilustracin 9-24 Pantalla principal asociacin
Gestionar Asociacin Modificar asociacin Si la asociacin lo desea, podr modificar sus datos en cualquier momento. Se mostrar por pantalla la informacin que el sistema tiene sobre esta. Si se realiza alguna modificacin y esta es incorrecta, el sistema informa al usuario del dato errneo.
158
Ilustracin 9-25 Pantalla modificar asociacin de asociacin
Gestionar Voluntarios Alta voluntario El usuario deber rellenar los campos obligatorios de los voluntarios a dar de alta. Si hubiese algn error, se informar por pantalla de los datos incorrectos.
Pantalla alta voluntario.
Ilustracin 9-26 Pantalla alta voluntario asociacin
159
Pantalla de confirmacin alta de voluntarios.
Ilustracin 9-27 Pantalla confirmacin alta voluntario asociacin
Baja voluntario Pantalla que permite o bien eliminar a los voluntarios de la base de datos, o bien establecer una fecha de baja para los voluntarios seleccionados.
Ilustracin 9-28 Pantalla baja voluntario asociacin
160
Consultas Consultar voluntarios El usuario podr realizar bsquedas sobre la base de datos de voluntarios que contenga su asociacin. A su vez, y una vez realizada la bsqueda, podr imprimir por pantalla en formato de libro de registro su seleccin.
Pantalla de bsqueda.
Ilustracin 9-29 Pantalla consultar voluntarios asociacin
Pantalla que muestra los datos de los voluntarios.
Ilustracin 9-30 Pantalla voluntarios consultados asociacin
161
Anexo I
Ilustracin 0-1 Diagrama GANTT
162
Bibliografa
[1] Java Sun [http://java.sun.com/] [2] Sitio Web Apache [http://www.apache.org/] [3] Sitio Web Xampp. [http://www.apachefriends.org/es/xampp.html] [4] Sitio Web Itext [http://www.lowagie.com/iText/] [5] Sitio Web Javamail [http://java.sun.com/products/javamail/] [6] Tutorial programacin Servlets [http http://www.programacion.com/tutorial/servlets_basico/] [7] Tutorial avanzado Servlets [http://www.programacion.com/java/tutorial/servlets_jsp/] [8] Tutorial Itext [http://itextdocs.lowagie.com/tutorial/] [9] Tutorial Itext [http://javaboutique.internet.com/tutorials/iText/] [10] Tutorial Javamail. [http://www.programacion.com/java/tutorial/javamail/] [11] Tutorial Javamail con ejemplos [http://www.chuidiang.com/java/herramientas/javamail/enviar-correo-javamail.php] [12] Sitio web Netbeans. [http://www.netbeans.org/]
163
[13]
Sitio Web MySQL [http://www.mysql.com/]
[14]
Sitio Web Total Commander. [http://www.ghisler.com/]
[15]
Artculo comercio en Internet. [http://ols.uas.mx/PubliWeb/Articulos/MRL-Internet_y_comercio.pdf]
[16]
Artculo sobre EDI. [http://www.csae.map.es/csi/silice/Svaedi4.html]
[17]
Explicacin sobre B2B. [http://es.wikipedia.org/wiki/B2B]
[18]
Artculo sobre comercio electrnico. [http://es.wikipedia.org/wiki/Comercio_electr%C3%B3nico
[19]
Introduccin al comercio electrnico. [http://www.monografias.com/trabajos12/monogrr/monogrr.shtml]
[20]
Arquitectura orientada a servicios. [http://es.wikipedia.org/wiki/Arquitectura_orientada_a_servicios]
[21]
Evolucin del B2B. [http://www.wharton.universia.net/index.cfm?fa=viewArticle&ID=364]
[22]
B2B Marketing. [http://www.monografias.com/trabajos38/business/business3.shtml#ecommer]
[23]
Introduccin EDI. [http://www.monografias.com/trabajos/edi/edi.shtml]
[24]
Explicacin MVC. [http://es.wikipedia.org/wiki/Modelo_Vista_Controlador]
[25]
Utilizacin del MVC. [http://www.monografias.com/trabajos43/patron-modelo-vista/patron-modelovista.shtml]
164
[26]
Explicacin sobre JSP.. [http://es.wikipedia.org/wiki/Java_Server_Pages ]
[27]
Tutorial JSP. [http://geneura.ugr.es/~jmerelo/JSP/]
[28]
Tutorial JSP y Servlets. [http://www.programacion.com/java/tutorial/servlets_jsp/]
[29]
Sitio Web Mtrica V3 [http://www.csi.map.es/csi/metrica3/index.html]
[30]
Aplicaciones Web en Wikipedia [http://es.wikipedia.org/wiki/Aplicaci%C3%B3n_web]
[31]
Pasado, Presente y Futuro de las aplicaciones Web [http://www.slideshare.net/idumm/pasado-presente-y-futuro-de-las-aplicaciones-web
[32]
Desarrollo en Cascada Wikipedia. [http://es.wikipedia.org/wiki/Desarrollo_en_cascada /]
[33]
Ciclo de vida Software. [http://www.ia.uned.es/ia/asignaturas/adms/GuiaDidADMS/node10.html]
[34]
Sitio Web Previgalia. [http://www.previgalia.com/]
[35]
Api Java [http://java.sun.com/j2se/1.5.0/docs/api/]
[36]
Api JavaMail [http://java.sun.com/products/javamail/]
[37]
Api Itext [http://www.lowagie.com/iText/docs.html]
[38]
Arquitectura Cliente - Servidor [http://es.wikipedia.org/wiki/Cliente-servidor]
165
[39]
Definicin Arquitectura Cliente - Servidor. [http://www.monografias.com/trabajos24/arquitectura-cliente-servidor/arquitecturacliente-servidor.shtml]
[40]
Tutorial Dreamweaver. [http://www.programatium.com/dreamweaver.htm]
[41]
Tutorial NetBeans. [http://www.netbeans.org/kb/60/java/quickstart_es.html]
[42]
Sitio Web de Prosinet. [http://www.prosinet.com/]
166

David Hernandez PFC

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

David Hernandez PFC

Uploaded by

Copyright:

Available Formats

Universidad Carlos III de Madrid

Escuela Politcnica Superior

Aplicacin Web para la gestin de empresas de voluntariado

Proyecto Fin de Carrera Ingeniera Tcnica Informtica

Aplicacin Web para la gestin de empresas de voluntariado

Aplicacin Web para la gestin de empresas de voluntariado

Aplicacin Web para la gestin de empresas de voluntariado

Aplicacin Web para la gestin de empresas de voluntariado

Aplicacin Web para la gestin de empresas de voluntariado

Aplicacin Web para la gestin de empresas de voluntariado

Aplicacin Web para la gestin de empresas de voluntariado

Estado del arte .............................................................6

Aplicacin Web para la gestin de empresas de voluntariado

2.4 2.4.1 2.4.2

Aplicacin Web para la gestin de empresas de voluntariado

Aplicacin Web para la gestin de empresas de voluntariado

Aplicacin Web para la gestin de empresas de voluntariado

Explicacin cdigo JavaMail ............................................................ 112

Pruebas......................................................................116 Conclusiones ............................................................127

Apndice A. Manual de instalacin................................133

Apndice B. Manual de usuario......................................144 Anexo I .............................................................................162

Aplicacin Web para la gestin de empresas de voluntariado

Aplicacin Web para la gestin de empresas de voluntariado

Aplicacin Web para la gestin de empresas de voluntariado

Aplicacin Web para la gestin de empresas de voluntariado

Aplicacin Web para la gestin de empresas de voluntariado

Aplicacin Web para la gestin de empresas de voluntariado

Aplicacin Web para la gestin de empresas de voluntariado

Aplicacin Web para la gestin de empresas de voluntariado

Aplicacin Web para la gestin de empresas de voluntariado

Aplicacin Web para la gestin de empresas de voluntariado

1.1 Motivacin del proyecto

Aplicacin Web para la gestin de empresas de voluntariado

Aplicacin Web para la gestin de empresas de voluntariado

Aplicacin Web para la gestin de empresas de voluntariado

1.3 Contenido de la memoria

Aplicacin Web para la gestin de empresas de voluntariado

Aplicacin Web para la gestin de empresas de voluntariado

2 Estado del arte

2.1 Evolucin de las aplicaciones Web

2.1.1 Pasado y presente

Aplicacin Web para la gestin de empresas de voluntariado

Aplicacin Web para la gestin de empresas de voluntariado

2.2 Comercio electrnico

Aplicacin Web para la gestin de empresas de voluntariado

Aplicacin Web para la gestin de empresas de voluntariado

Tecnologas empleadas El comercio electrnico utiliza un amplio rango de tecnologas.

Aplicacin Web para la gestin de empresas de voluntariado

2.2.2 Evolucin y caractersticas del modelo B2B

Aplicacin Web para la gestin de empresas de voluntariado

Ventajas para el proveedor Incremento de la base de clientes potenciales.

Aplicacin Web para la gestin de empresas de voluntariado

Aumento de la fidelidad de sus clientes gracias a la reduccin de barreras de salida.

Reduccin de la carga administrativa.

Aplicacin Web para la gestin de empresas de voluntariado

2.2.2.1 Intercambio electrnico de documentos (EDI)

Aplicacin Web para la gestin de empresas de voluntariado

Aplicacin Web para la gestin de empresas de voluntariado

Sistema informatico cliente

Extrae datos e imprime

Captura datos y procesa

Sistema informtico proveedor

Ilustracin 2-1 Transmisin de documentos convencional