entregable e3 proyecto de especificación de …proyecto de especificación de aplicaciones grupo i...

Proyecto de Especificación de Aplicaciones Grupo I Tutor: Aureli Soria Frisch Tercera Entrega

Blog: http://grupoi.wordpress.com · E-mail: grupo [email protected] Manuel Gallego Rebollo * Ignasi de Llorens * Octavio Moreno Muñoz * Jara Pascual Soldevilla *

Jose Maria Martínez López

Entregable E3 Proyecto de Especificación de

Aplicaciones

Grupo I


Blog: http://grupoi.wordpress.com · E-mail: grupo [email protected]

2

Índice

1. Servidores ...............................................................................................................................................5

1.1Definición de Análisis de requisitos ...............................................................................................5 1.2 Requisitos no-funcionales ..............................................................................................................5

1.2.1Hardware necesario ....................................................................................................................5 1.2.2 Software necesario.....................................................................................................................5 1.2.3 Mantenimiento del sistema.........................................................................................................6 1.2.4 Usabilidad...................................................................................................................................6 1.2.5 Herramientas necesarias............................................................................................................6 1.2.6 Interoperabilidad entre sistemas ................................................................................................6 1.2.7 Disponibilidad y ancho de banda................................................................................................6

1.3 Requisitos funcionales ....................................................................................................................7 1.3.1 Casos de uso .............................................................................................................................7 1.3.2 Diccionario de datos...................................................................................................................8 1.3.3 Diagramas de secuencia ............................................................................................................9

1.4 Arquitectura global ........................................................................................................................21 1.4.1 Identificación de los servidores principales ..............................................................................21 1.4.2 sistemas operativos & lenguajes ..............................................................................................25 1.4.3 Diseño de la estructura de red .................................................................................................26 1.4.4 Tecnología de distribución........................................................................................................27

1.5 Tecnología de voz sobre IP ...........................................................................................................29 2. Codificación audiovisual ......................................................................................................................31

2.1 Introducción ...................................................................................................................................31 2.2 Descripción del algoritmo .............................................................................................................31

2.2.1 Funcionamiento........................................................................................................................31 2.2.2 Tamaño de la ventana..............................................................................................................33 2.2.3 Pseudo código del algoritmo ....................................................................................................33

2.3 Usos Reales ....................................................................................................................................34 2.4 Modos de uso del algoritmo LZ77 en nuestro proyecto .............................................................34 2.5 Código del programa elaborado ...................................................................................................35 2.6 Ejemplos sobre el programa .........................................................................................................38 2.7 Dudas surgidas en el seminario ...................................................................................................40

3. Base de datos ........................................................................................................................................42 3.1 Copias de seguridad ......................................................................................................................42 3.2 DTD, XML y XML Schema ..............................................................................................................43

3.2.1 Definición..................................................................................................................................43 3.2.2 Cómo se hizo ...........................................................................................................................43 3.2.3 Como lo definimos en nuestra base de datos ..........................................................................43 3.2.4 Comparativa de XMLS con DTD ..............................................................................................53

3.3 RSS y metadatos ............................................................................................................................54 3.3.1 Uso de metadatos en nuestro proyecto....................................................................................54 3.3.2 RSS (Really Simple Sindication) ..............................................................................................55 3.3.3 Uso de RSS en nuestro proyecto .............................................................................................55

4. Interfaz de usuario ................................................................................................................................56 4.1 Contacto con Universidades y ONG's ..........................................................................................56 4.2 Justificación de la elección de los profesores y ON Gs entrevistados ......................................57 4.3 Experiencia del trato recibido .......................................................................................................58 4.4 Cómo hacemos una entrevista .....................................................................................................60 4.5 Informe de los puntos comunes de ambas comunidades ..........................................................60 4.6 Informe de los puntos innovadores para nuestro proy ecto .......................................................61 4.7 Entrevistas ......................................................................................................................................62

4.7.1 Entrevistas en la comunidad universitaria ................................................................................62 4.7.2 Entrevistas en las organizaciones no gubernamentales...........................................................73 4.7.3 Entrevistas externas................................................................................................................82

5. Seguridad ..............................................................................................................................................84 5.1 Objetivos del entregable ................................................................................................................84 5.2 Definición de los conceptos utilizados en este entr egable ........................................................84

5.2.1 Comunicación segura...............................................................................................................84 5.2.2 PKI (Public Key Infraestructure) ...............................................................................................84 5.2.3 Kerberos...................................................................................................................................84 5.2.4 Detección de intrusos...............................................................................................................85 5.2.5 Identificación y autentificación de usuarios y servidores ..........................................................86



3

5.2.6 3DES simétrico.........................................................................................................................86 5.2.7 Comunicación administrador y servidores RSA .....................................................................86 5.2.8 Encriptación Base de datos......................................................................................................87 5.2.9 HTTPS......................................................................................................................................87

5.3 Criterios utilizados para la especificación de las tecnologías ...................................................88 5.3.1 Justificación del uso PKI en gestión de claves .........................................................................88 5.3.2 Justificación del uso Kerberos para el Control de Acceso........................................................89 5.3.3 Justificación de Detección de intrusos......................................................................................89 5.3.4 Justificación del uso Identificación y autentificación de usuarios y servidores en el servidor...90 5.3.5 Justificación de la utilización de 3DES simétrico......................................................................91 5.3.6 Justificación de la utilización de RSA para la comunicación administrador y servidores........91 5.3.7 Justificación de la Encriptación de la Base de datos................................................................91 5.3.8 Justificación de la utilización de HTTPS...................................................................................91

5.4 Desarrollo de la arquitectura de seguridad .................................................................................92 5.4.1 Clasificación de los elementos de la figura 1...........................................................................92 5.4.2 Requisitos de seguridad y sus tecnologías más adecuadas para nuestro proyecto ................92 5.4.3 Tabla resumen de todas las tecnologías necesarias para nuestro portal, con sus servicios de seguridad y la capa OSI dónde se encuentran..................................................................................93 5.4.4 Desarrollo de cómo lo aplicamos la tecnología elegida a cada elemento ................................96

6. Bibliografía ..........................................................................................................................................100 6.1 Servidores......................................................................................................................................100 6.2 Codificación....................................................................................................................................100 6.3 Base de datos ................................................................................................................................100 6.4 Interfaz de usuario .........................................................................................................................101 6.5 Seguridad.......................................................................................................................................101



4



5

1. Servidores

1.1Definición de Análisis de requisitos El análisis de requerimientos es la primera etapa de un proyecto software, en ella se tratan de definir las condiciones o capacidades necesarias para uno o varios usuarios con el fin de solucionar un problema o conseguir un objetivo. Para la creación global del sistema se necesita comprender todos los objetivos y necesidades del usuario. En primer lugar, hemos de especificar el comportamiento externo del sistema desde el punto de vista del usuario, en forma de requisitos. La determinación de los requerimientos se haya en base a la experiencia, de hablar con los usuarios finales sobre sus necesidades y / o analizando un sistema software existente. Los requerimientos de usuario se pueden expresar en lenguaje natural, organizados por categorías. También existen lenguajes formales como OCL (dentro de la especificación UML), que permiten expresar los requerimientos de una forma más concisa y no ambigua. Hay dos tipos de requerimientosrequerimientosrequerimientosrequerimientos: funcionales (QUE debe hacer el sistema), y no no no no funcionalesfuncionalesfuncionalesfuncionales (otros requisitos sobre el entorno (sistema operativo, sistema gestor de base de datos, sistema de archivos), ergonómicos (interfaz gráfica, etc.), de rendimiento, de tiempo, formato de entrega, etc.).* *Fuente: Microsoft Ibérica, SRL.

1.2 Requisitos no-funcionales A continuación haremos una pequeña descripción de los requerimientos no-funcionales que nuestro portal cubrirá, algunos de estos como el tipo de hardware y software especifico escogido y el porqué de esta decisión será extensamente desarrollado en el apartado de arquitectura global.

1.2.1Hardware necesario Hemos creído que por motivos de división de carga utilizaremos varias máquinas para el soporte de los dístenlos softwares servidores, en vez de que estén todos en la misma máquina. De esta forma en caso de que el servidor de video caiga el servidor de aplicaciones-web pueda continuar dando HTML de nuestro portal.

1.2.2 Software necesario Un servidor de aplicaciones-web que implemente las especificaciones de los servlets y de JavaServer Pages (JSP) que también hará de servidor web con soporte de servlets y JSPs con una capacidad recibir peticiones de documentos HTML necesarios para una página web, con sus usuarios, sus perfiles y sus proyectos. Un servidor webmail para los usuarios que hayan sido seleccionados para el proyecto y un servidor de vídeo para presentar los vídeos de los proyectos.



6

1.2.3 Mantenimiento del sistema Un servicio técnico de 24 horas para solucionar los problemas de la página web, y las quejas de los usuarios. Las 24 horas las hemos elegido porque el sistema va a ser utilizado a la vez en cualquier parte del mundo, y tiene que estar operativo de noche en España cuando es de día en Canadá y viceversa.

1.2.4 Usabilidad Se usará para intercomunicar la comunidad universitaria con el mundo de las ONGs a nivel internacional. Por eso, tanto una comunidad como la otra podrá proponer proyectos que se desarrollen en cualquier parte del mundo, sea de la índole que sea. Y para que ello funcione, se utilizará el portal web como un flujo de trabajo de los proyectos para que se organicen en sus tareas tanto los profesores como los responsables de las ONGs.

1.2.5 Herramientas necesarias Las herramientas que se pongan en el portal web tienen que tener las acciones claras, sencillas, bien definidas y ser de fácil manejo. Se incluirán manuales de ayuda lógicos y didácticos. Una de las herramientas estrella del portal web serán las descargas multimedia, dónde a partir de la tecnología adecuada se podrán ver videos en tiempo real. Y por otro lado la herramienta más práctica y útil serán las herramientas que ayuden a nuestro sistema a ser un sistema más seguro, eso quiere decir, a evitar que entren intrusos, software malicioso, etc.

1.2.6 Interoperabilidad entre sistemas Nuestro sistema tiene que verse y tratarse en cualquier sistema operativo, y en cualquier sistema. Para ello haremos que sea ínter operable.

1.2.7 Disponibilidad y ancho de banda Para calcular un ancho de banda aproximado, antes debemos decidir cuantas conexiones simultaneas podremos atender como máximo, en nuestro caso serán 10, teniendo en cuenta que estas consumirán unos 55Kbytes/s como máximo (nos parece suficiente para descargar vídeos que es lo que necesita más recursos), 10*55Kbytes/s=550Kbytes/s � 4400Kbps = 4,4Mbps. Cada archivo de vídeo ocupará como máximo 10Mbytes, 10000Kbytes/55Kbytes/s=181s. La descarga de un vídeo de tamaño máximo en nuestro sistema se realizará aproximadamente en 3 minutos.



7

1.3 Requisitos funcionales

1.3.1 Casos de uso

Figura 1. Casos de uso de nuestro sistema.



8

1.3.2 Diccionario de datos Comentarios: Directrices y pautas relacionadas con el proyecto y se publican en el área, y por los miembros del área. (Repuestas y afirmaciones). Acceden profesores y responsables de ONG. Consultas: Dudas sobre el proyecto que se publican en el área referente al proyecto. Los miembros del área. (Preguntas, y dudas y respuestas = foro). Acceden todos. Noticias: Son avisos que se escriben en la pagina principal del portal. Las escriben los coordinadores y responsables. Y las pueden leer todos. Búsqueda: Todas las personas que entren en el portal podrán realizar una búsqueda de todo lo publicado en la web. Se podrá buscar por fecha, área, nivel de urgencia y por palabras relacionadas. Suscripción áreas: Todas las personas que son usuarios registrados del portal se deben suscribir a las áreas que les sean afines para trabajar y estar al tanto de los proyectos de dichas áreas. Propuestas: Los coordinadores de las ONGs y los profesores coordinadores hacen las propuestas de proyectos, y las pueden ver todos los que están subscritos a las áreas que pertenece el proyecto. Notas de prensa: Los coordinadores de las ONGs y los profesores coordinadores son los encargados de hacer breves informes sobre los proyectos y colgarlos en el portal para que la prensa o cualquier persona tenga una idea de los proyectos y actividades que se hacen en el portal. Gestión de proyectos: Se trata de la coordinación de los proyectos. Tiene el deber de hacer las siguientes tareas: Asignar el proyecto a profesores y alumnos que previamente o no lo han solicitado; Evaluar el proyecto, y ver de que área se trata; Asignar tareas del proyecto a profesores y alumnos. Debate-> propuestas: Esta es una acción previa a la propuesta oficial de un proyecto. Es un debate de propuestas, comentarios, contra-propuestas entre la comunidad universitaria y los responsables de las ONGs. Intervienen los profesores coordinadores y los responsables ONGs. Evaluación de proyectos: Esta función será hecha tanto por los profesores coordinadores como por los responsables de la ONGs, y se encarga de evaluar los proyectos con tareas como ver si se siguen las directrices, ver si se cumple el planning y el timming del proyecto, como se va gestionando y ejecutando el proyecto. Log-in: Esta función la hacen todas las personas que están subscritas al portal web para entrar dentro de su área, y poderse identificar y trabajar en el portal. Mantenimiento: Esta función la hace el administrador del portal web, y tiene las tareas siguientes; Programación de la página web; Gestión de las bases de datos; Gestionar los foros y los debates, borrando contenidos, mensajes, noticias, etc.; Actualizar el



9

interfaz de la web con novedades; Gestionar las áreas de las ingenierías de proyectos; Gestionar la actualización de las propuestas y las consultas. Gestión de usuarios: Esta función la hace el administrador del portal web, y tiene las tareas siguientes; Dar de alta y de baja a los usuarios del portal; Gestionar y / o modificar el perfil; Gestionar los passwords.

1.3.3 Diagramas de secuencia A continuación vamos a ver los distintos casos de uso relacionados con los distintos actores donde los rectángulos son las entidades, las flechas son acciones en las que encima se menciona el tipo de acción y las flechas curvas hacen referencia a la repetición de determinadas acciones:

Figura 2. Secuencia dar de alta.

En esta acción el administrador accede a la opción ‘dar de alta’, rellena un formulario para dar acceso al nuevo usuario y la BBDD se actualiza.



10

Figura 3. Secuencia dar de baja.

En esta acción el administrador accede a la opción ‘dar de baja’, rellena un formulario para anular al usuario y la BBDD se actualiza.

Figura 4. Secuencia gestión de contraseñas.

En esta acción el administrador ‘gestiona contraseñas’ y se encarga de comprobar mediante un sencillo programa que las contraseñas de acceso a la web cumplen los



11

requisitos mínimos de seguridad, para ello las testeará y las que no cumplan estos requisitos serán modificadas avisando convenientemente al usuario de este cambio. La BBDD también se actualizará.

Figura 5. Secuencia gestión de foros.

En esta acción el administrador gestiona los foros / debates que haya en el portal. Podrá elegir entre varias opciones (moderar, eliminar, añadir…) y se actualizará la página principal.

Figura 6. Secuencia gestión del perfil de usuario.

En esta acción el administrador ‘gestiona perfiles’ de usuarios, es decir que puede realizar diversas acciones sobre el perfil del usuario indicado modificando, añadiendo o eliminando campos de ese perfil. La BBDD se actualizará convenientemente.



12

Figura 7. Secuencia de gestión de proyectos.

En esta acción el administrador puede gestionar los proyectos por áreas temáticas y realizar diversas acciones sobre ellos. La BBDD se actualizará convenientemente.

Figura 8. Secuencia de gestión de las bases de dato s.

En esta acción el administrador podrá gestionar las distintas BBDD, añadiendo, modificando o eliminando campos o información de las tablas.



13

Figura 9. Secuencia de programador web.

En esta acción el administrador podrá acceder a una serie de opciones de edición de la página web sin que ésta deje de funcionar. Antes de actualizarla se realizarán pruebas de correcto funcionamiento y sólo en el momento de actualización, la página no estará disponible durante un tiempo limitado, avisando previamente a los usuarios.

Figura 10. Secuencia de login.

Esta es una acción común a todos los usuarios con acceso permitido e indica el procedimiento a la hora de acceder al portal.



14

Figura 11. Secuencia de logout.

Tal como indica el nombre, esta acción servirá para salir del sistema y es una acción común en todos los usuarios del portal.

Figura 12. Secuencia de búsqueda.

Esta acción también es común a todos los usuarios del portal, estén dados de alta o no y sirve para realizar búsquedas sobre los proyectos que se están llevando a cabo.



15

Figura 13. Secuencia de comentarios.

Esta acción es propia de los coordinadores, tanto de universidad como de ONG y consiste en que pueden realizar diferentes acciones (incluida la edición) sobre los comentarios de un proyecto dentro de un área. La información deberá actualizarse. El resto de usuarios con login sólo pueden hacer la acción de visualizar estos comentarios, sin posibilidad de modificarlos.

Figura 14. Secuencia de consultas.

Esta es una acción común a todos los miembros del portal. Podrán realizar consultas por áreas temáticas y dentro de ellas, de los proyectos.



16

Figura 15. Secuencia de debate de las propuestas.

Esta es una acción exclusiva de los coordinadores, en la que una vez lanzada una propuesta de proyecto se podrán poder en contacto para debatirla y tomar decisiones sobre ella. El siguiente paso será evaluarla.

Figura 16. Secuencia de evaluación de proyectos KO. Acción propia de los coordinadores donde se toma la decisión de evaluar la propuesta o no, en este caso si la propuesta no sigue adelante se eliminará de la BBDD.



17

Figura 17. Secuencia de evaluación de proyectos OK.

Acción propia de los coordinadores donde se toma la decisión de evaluar la propuesta o no, en este caso si la propuesta sigue adelante se actualizará la BBDD y se continuará con la gestión del proyecto.

Figura 18. Secuencia de gestión de proyectos.



18

Acción propia de los coordinadores donde se editará la propuesta, se informará a los asociados de que hay un nuevo proyecto y éstos podrán apuntarse mediante un formulario. Los coordinadores deciden quién hará el proyecto y una vez elegidos se repartirán las tareas entre ellos.

Figura 19. Secuencia de notas de prensa.

Esta sección es exclusiva de los coordinadores que podrán decidir si enviar un aviso a la prensa una vez se haya editado un proyecto y éste esté en marcha.

Figura 20. Secuencia de inserción de noticias KO.



19

Sección exclusiva de coordinadores donde podrán editar noticias sobre la evolución de los proyectos, por ejemplo. En este caso si la edición es incorrecta se vuelve a la página de edición.

Figura 21. Secuencia de inserción de noticias OK.

Sección exclusiva de coordinadores donde podrán editar noticias sobre la evolución de los proyectos, por ejemplo. En este caso si la edición es correcta se va a la página de noticias. El resto de usuarios solo tendrán acceso como observadores, es decir, sólo pueden realizar la acción visualizar noticia, debiendo escoger el área y el proyecto previamente. Como vamos a ver en el siguiente diagrama de secuencias.



20

Figura 22. Secuencia de noticias.

Figura 23. Secuencia de propuestas.



21

Esta sección es exclusiva de los coordinadores, donde podrán acceder a varias opciones para modificar la información relativa a los proyectos. Una vez esta información se haya actualizado el resto de usuarios podrá acceder a su visualización eligiendo el área temática y la propuesta concreta.

Figura 24. Secuencia de suscripción a un área.

Esta sección es común para todos los usuarios que estén dados de alta por parte del administrador y en ella podrán suscribirse a las distintas áreas en las que estén interesados participar.

1.4 Arquitectura global

1.4.1 Identificación de los servidores principales 1.4.1.1 Servidor de video Software: Darwin Streaming Server Creemos que como desarrolladores de aplicaciones nos es atractivo el poder tener un software servidor de video streaming en open source. Así que el único servidor existente en Internet es el denominado Darwin Streaming Server que permite poner la tecnología QuickTime Streaming Server a nuestra disposición (realmente es la versión del QuickTime Streaming Server para Open source). Utilizando el código fuente Darwin Streaming Server tenemos total libertad de poder construir productos servidores para cualquier plataforma, con la capacidad de difundir contenido QuickTime en modo stream a través de redes utilizando los protocolos estándar RTP y RTSP. Por tanto tenemos todas las ventajas de utilizar QuickTime Streaming Server que son:



22

• Quicktime es el estándar más portable creado en mucho tiempo • QuickTime Streaming requiere un servicio especial, pero cualquier Mac que

utilice OS y Quicktime Pro puede ser configurado como un QuickTimeServer. • Quicktime permite configurar el video en pequeños streams que realmente se

descargan y se ejecutan de forma simultánea sin ningún tipo de retraso. El rendimiento varía en función del rendimiento del Web Server.

• Permite compartir datos entre usuarios de Mac y PC. • Incorpora el apple Skip-Protection para evitar la congestión de la red. • Permite la creación de propias PlayList • El nuevo Embed Tag Feature permite insertar un clip QuickTime directamente

en el código HTML. Aunque podamos elegir plataforma creemos que al estar desarrollado por apple es mucho más potente con el sistema operativo MAC OS X Server. Aunque hayamos elegido la versión open source en vez de la comercial, ésta puede correr por OS X server, pero no dispondremos en este caso de las herramientas mejoradas administración y gestión de media de QuickTime Streaming Server. Pero de todas formas podremos programar el Darwin Server según nuestras necesidades, pudiendo crear todo tipo de herramienta. Debido a que utilizaremos el código abierto de QuickTime Streaming Server de apple (Darwin) y el sistema operativo OS X Server también de apple tendremos muchas ventajas de integración de dos software desarrollados por la misma empresa:

• Capacidad para servir 1.000 flujos (streams) simultáneos de audio y vídeo hacia conexiones con velocidades de tipo módem.

• Modelo de licencia sencillo, sin ningún tipo de cargo de licencia “por stream”.

• Soporte de los protocolos de streaming estándar RTP y RTSP.

• Fácil configuración, por medio de un sencillo instalador disponible en la web de

Apple.

• Posibilidad de mejorar el código continuamente, gracias a la comunidad de desarrollo de open source para la mejora continúa de Darwin.

• Quicktime es el estándar más portable creado en mucho tiempo

Compatibilidad con estándares QuickTime, la primera tecnología para crear, reproducir y emitir multimedia por Internet, es totalmente compatible con los estándares multimedia mundiales más recientes, entre ellos H.264, MPEG-4 y 3GPP. Igualmente, QuickTime Streaming Server es compatible con la emisión de archivos H.264, MPEG-4 y 3GPP de forma nativa, para que tu contenido pueda disfrutarse con cualquier reproductor multimedia estándar para Mac o Windows, así como con numerosos dispositivos compatibles como móviles y descodificadores digitales. También te permite ofrecer archivos a clientes MP3 estándar mediante protocolos compatibles con Icecast sobre HTTP. Con QuickTime Streaming Server estás seguro de llegar al máximo público posible.

Hardware: Xserver Hemos pensado que al utilizar el software de apple por motivos de integración, así que también utilizaremos una máquina de apple. Estas son las características básicas:



23

• Dos procesadores Xeon de Intel con doble núcleo de 64 bits a 2GHz (hasta

3GHz). • Bus frontal a 1,33 GHz y 4MB (hasta 16 MB) de memoria caché compartida de

nivel 2 por procesador. • 1GB (hasta 4 GB) de memoria (módulos DIMM DDR2 a 667MHz con ECC y

memoria intermedia). • Disco duro Serial ATA de 80GB (hasta 750 GB) a 7.200rpm. • Tarjeta gráfica incorporada Radeon X1300 de ATI con 64MB (hasta 256MB) de

RAM. • Edición sin límite de clientes de Mac OS X Server 10.4. • Precio 4000 €

Fotografía 1. Xserver. Motivos de la decisión

• El Xserver incluye un servidor web Apache. • Xserver ofrecer más de 5.000 conexiones por segundo con WebBench. • La compatibilidad de serie con la tecnología Secure Sockets Layer (SSL). • Cifrado de 128 bits de alto nivel (infraestructura de clave pública (PKI)

utilizando certificados digitales X.509). • Robusta implementación de Java 2, optimizada para su uso en servidores, y su

compatibilidad total con JSP, Servlets de Java, SOAP y XML-RPC. • Utilización de Mac OS X Server (versiones open source Darwin) que permite

albergar aplicaciones J2EE de alto rendimiento, como JBoss, Tomcat y Axis de Apache.

• Los cimientos de código abierto UNIX. Aunque la posibilidad de albergar un servidor de aplicaciones como el tomcat no es primordial en este aparato ya que utilizamos otro hardware de soporte a nuestro



24

servidor de aplicaciones puede ser de gran ayuda para poder hacer una división de cargas de nuestro portal. 1.4.1.2 Servidor de aplicaciones

Software: Tomcat

Hemos decidido integrar en un mismo software el servidor web (servidor de contenido estático html), el servidor de aplicaciones (un plugin para Servlets/JSP) y utilizaremos como servidor de correo el servidor web, ya haremos un web-mail, con lo que el cliente sólo necesitará usar el navegador. Se le considera un servidor de aplicaciones. Funciona como un contenedor de servlets desarrollado bajo el proyecto Jakarta en la Apache Software Foundation. Tomcat implementa las especificaciones de los servlets y de JavaServer Pages (JSP) de Sun Microsystems.

Tomcat también es un servidor web con soporte de servlets y JSPs. Incluye el compilador Jasper, que compila JSPs convirtiéndolas en servlets. El motor de servlets de Tomcat a menudo se presenta en combinación con el servidor web Apache. Tomcat puede funcionar como servidor web por sí mismo. En sus inicios, existió la percepción de que el uso de Tomcat de forma autónoma era sólo recomendable para entornos de desarrollo y entornos con requisitos mínimos de velocidad y gestión de transacciones. Hoy en día ya no existe esa percepción, y Tomcat es usado como servidor web autónomo en entornos con alto nivel de tráfico y alta disponibilidad. Dado que Tomcat fue escrito en Java, funciona en cualquier sistema operativo que disponga de la máquina virtual.

Operación del Servidor Web (Tomcat Cooperar con Apache Web Server) Usaremos un servidor web, como Apache, para servir el contenido estático del portal, y usen Tomcat como un plugin para Servlets/JSP. Para poder integrar el servidor web al servidor de aplicaciones el servidor web necesita realizar unas operaciones específicas, ya que además de esperar peticiones de un cliente http tiene que añadir un contenedor de servlets. Entones realiza: Cargar la librería del adaptador del contenedor de servlets e inicializarlo (antes de servir peticiones). Cuando llega una petición, necesita chequear para ver si una cierta petición pertenece a un servlet, si es así necesita permitir que el adaptador tome el control y lo maneje. Por otro lado el adaptador necesita saber qué peticiones va a servir, usualmente basándose en algún patrón de la URL requerida, y dónde dirigir estas peticiones. Servidor webmail Hemos pensado que la manera más fácil y cómoda para un usuario de gozar del servicio de correo electrónico es con acceso web, ya que es la forma más extendida y usada en los últimos tiempos (Hotmail, gmail, yahoo, etc.). De esta forma, usando webmail los usuarios se conectan a una página que les brinda acceso a sus mensajes como si estuvieran en su Terminal, con todas las funcionalidades que se esperan de un cliente de correo normal. De esta forma la conexión al servidor por parte del usuario sería realizada por el navegador. Para poder dotar a nuestro servidor web de la funcionalidad de webserver instalaremos el software SquirrelMail contenida en los ports de FreeBSD 4.9-STABLE. Ahora tenemos un servidor web que soporta peticiones de mails. Pero estas peticiones tienen que ser enviadas a un servidor de correo que soporte el protocolo SMTP, ya que es el protocolo que usan los servidores de correo para comunicarse entre ellos. De esta forma podrá comunicarse con nuestro servidor de correo. No nos tenemos que



25

preocupar por los protocolos POP o IMAP ya que serán implementados por nuestro servidor de correo. En cualquier caso, los protocolos SMTP/POP/IMAP son inseguros en cuanto a que los mensajes viajan en claro por la red, es decir, es fácil obtener nuestros mensajes y contraseñas. Para ello añadiremos una capa SSL, para ofrecer más seguridad. Por lo tanto tenemos que instalar SquirrelMail al servidor web apache en conjunto con el módulo de SSL para proveer la seguridad necesaria cuando se necesita transmitir información sensible a través de la red. Pasos que debemos seguir:

1. SquirrelMail esta desarrollado en PHP, así que necesitamos incluir el módulo correspondiente en apache.

2. Ahora solo necesitamos instalar un servidor de correo IMAP que

intercomunicará nuestro Webmail con nuestro servidor de correo. 3. Instalación de SquirrelMail, de forma rápida y sencilla gracias a los ports del

sistema de FreeBSD.

4. Configuración del nuestro dominio y de nuestro servidor de correo.

5. Activar un dominio SSL en apache para que forcemos a nuestros usuarios a utilizar el servicio de webmail únicamente a través del protocolo seguro de http.

6. Para lograr esta funcionalidad webmail debe estar definido en el DNS del

dominio apuntando a la misma IP que www. Ahora los usuarios deberán utilizar forzosamente https://webmail.dominioportal para acceder a los servicios de correo desde la web.

1.4.1.3 Servidor de correo Requisitos que va ha cumplir nuestro servidor de correo

• Independencia de los usuarios de sistema y las cuentas de correo electrónico. • Un dominio principal donde se crean cuentas de correo. • Múltiples dominios virtuales con redirecciones a las cuentas del dominio

principal. • Autenticación a través de SASL (Simple Autenticación and Security Layer), con

métodos de texto plano o login. • Transporte seguro del tráfico mediante TLS. • Acceso a los buzones por IMAP sobre SSL y por webmail. • Filtrado de correo en el servidor a través de Sieve. • Filtros antivirus y antispam. • Listas de correo.

Utilizaremos como servidor IMAP el software Cyrus IMAP y para ofrecer seguridad el software Cyrus SASL, que correrán sobre el sistema Debian GNU/Linux y como agente usaremos Postfit.

1.4.2 sistemas operativos & lenguajes Lenguaje que usamos en nuestros servidores será Java, y con multiplataforma para que se puede ver el portal desde cualquier sistema operativo.



26

1.4.3 Diseño de la estructura de red Nuestro diseño de la estructura de la red se basa en tener tres bases de datos con sus correspondientes gestores de base de datos Oracle, que es el gestor que elegimos en la parte de Base de datos, una de las bases de datos es especial para los correos electrónicos que se envían entre los miembros del grupo. Otra base de datos para toda la información referente a los usuarios, como por ejemplo sus datos personales, sus comentarios, sus propuestas, o sea todo lo que ha hecho y posee el usuario. Por último tendremos una base de datos multimedia que es dónde guardaremos todos los proyectos en su totalidad, su documentación en formato texto, las fotografías, y los videos. El acceso a las bases de datos por medio de los servidores estará controlado por un corta fuego, ya que la información que está guardada y gestionada en la base de datos no tiene que ser fácilmente accesible por nadie, porque se trata de información confidencial. Tendremos otro corta fuegos entre el acceso a Internet de nuestro sistema y nuestros dos servidores que serán uno para aplicaciones, aplicaciones web, y aplicaciones de webmail, otro para correo electrónico y otro servidor para video. La arquitectura que vamos a ver en la figura 1 se basa en la arquitectura de funcionamiento J2EE, dónde todos los datos se guardan en las bases de datos, el procesado de la información en los servidores, y a través de Internet es cuando se presenta al usuario en forma de portal web. Por tanto en los servidores solamente se almacenarán los datos más utilizados por nuestros usuarios del portal. Hemos decidido utilizar dos firewalls, uno en el front-end, para proteger la entrada a nuestro sistema, y otro firewall en el back-end. El motivo de este último es porque en nuestras bases de datos tendremos datos de una criticidad muy alta sobre las ONGs (como por ejemplo patentes, información sobre estandarizaciones, etc.). Así pues, un posible atacante que intente acceder a nuestro sistema, deberá pasar el primer firewall, y para acceder a nuestros datos críticos será bloqueado por el primer firewall o, en el caso de que este falle, en el segundo.



27

Figura 25. Estructura de nuestra arquitectura de ser vidores de nuestro portal web.

1.4.4 Tecnología de distribución Tenemos a nuestra disposición varias tecnologías de distribución como son Java RMI, CORBA, DCOM, y Web Services. Buscamos una tecnología que sea multiplataforma para que pueda trabajar con varios sistemas operativos, y nos interesa que sea programada en lenguaje Java porque nos resulta más cómodo, ya que el lenguaje Java nos permite implementar en programación todos nuestros pensamientos creativos del desarrollo del portal web. Según estas primeras premisas de todas las tecnologías que hemos nombrado ya podemos desechar DCOM, ya que no es multiplataforma, solamente trabaja con Windows, y no sabemos a priori el sistema operativo que utilizan nuestros usuarios del portal, y además el lenguaje en el que se programa es C#. Otra de las tecnologías que podemos descartar es CORBA ya que esta tecnología de distribución es más



28

apropiada para estructuras en que se tiene que trabajar con sistemas muy distintos a la vez, como pueda ser una estructura bancaria con cajeros automáticos, ordenadores de la sucursal, y servidores bancarios. Nuestro portal es un servidor que a través de una página web se da a conocer a Internet, y a los usuarios. Y los usuarios desde sus ordenadores interactúan con nuestro portal sin necesidad de ningún sistema especial intermediario. La batalla queda por tanto entre Java RMI y Web Services, a simple vista Web Services parece más estupendo para nuestro portal porque trabaja con el protocolo http, trabaja con XML, tiene seguridad y cumple las primeras premisas que nos impusimos, pero si queremos programar todo nuestro portal en Java, la opción más confortable es Java RMI, que además aporta la ventaja que podemos trabajar con la arquitectura J2EE. Por lo tanto la tecnología que vamos a hacer servir va a ser Java RMI, con la arquitectura J2EE siguiente:

Figura 26. Arquitectura J2EE para nuestro portal web .

1.4.4.1 Java RMI en nuestro proyecto RMI nos permite interactuar entre diferentes aplicaciones Java, y permite a un método, o clase poder ser llamado remotamente, diseñar procedimientos en nuestro portal de estar manera nos aporta interoperabilidad a nuestro proyecto, y fue uno de los requisitos no funcionales que definimos anteriormente. Una de las cosas que tenemos que saber es que Java RMI pertenece a JDK, y que cualquier plataforma que tenga acceso a JDK tendrá acceso a cualquier procedimiento que definamos en nuestro portal. La interoperabilidad comenzará a ser útil en nuestro proyecto a medida que nuestro portal web crezca y tengamos que anexarle nuevos sistemas a nuestra arquitectura. Hacer más extensible y más ínter operable a nuestro portal requerirá de una sólida base en Java para poder utilizar sistemas distribuidos con Java RMI.



29

Java RMI para nuestro portal sería una colección de objetos que interactuarían entre sí, solicitando y proporcionando servicios mediante el intercambio de mensajes, por lo que se ajusta bastante bien a nuestro portal que tiene que intercambiar mensajes con varios clientes que se harían a través de objetos remotos. Nuestro portal se basaría en que los clientes obtendrían referencias a uno o más objetos remotos, e invocaría a sus métodos por medio de RMI de Java, que es la tecnología que proporciona los utensilios que hacen que el cliente y el servidor se comuniquen.

Figura 27. Aplicación distribuida de Java RMI.

Utilizamos el servicio de nombres rmiregistry para obtener referencias de objetos remotos. El cliente busca el objeto remoto utilizando su nombre como argumento e invoca algún método que necesite. Usamos un servidor web para cargar códigos de operación, de clientes a servidores y de servidores a clientes, mediante el empleo de cualquier protocolo URL, que consiste en no activar un objeto hasta que se invoca alguno de sus métodos. La URL proporciona un apuntador a cualquier objeto que sea accesible desde cualquier máquina conectada a Internet. Como los objetos son accesibles de diferentes maneras (ftp, http, gopher, file, etc.) la URL indica el método de acceso que se debe utilizar para obtener el objeto deseado. Así nosotros utilizaremos RMI para contactar con nuestros diferentes servidores que cada uno tendrá sus objetos específicos dependiendo de su uso, y nuestros servidores se conectarán con nuestros usuarios a través de objetos remotos.

1.5 Tecnología de voz sobre IP Para poder ofrecer servicio de telefonía IP en nuestro portal web utilizaremos la aplicación skype. Ya que de esta forma podremos utilizar la infraestructura de este, por lo que nos despreocupamos de la instalación de ningún servidor de VoIP así como la configuración de ningún protocolo. De esta forma solo tenemos que integrar a nivel de aplicación el programa Skype con nuestro portal. Todo esto a través de la API de Skype, que es totalmente gratuita y multiplataforma (Windows, Mac OS X, Linux). Nuestro portal tendrá una interfície hacia skype donde el usuario podrá ver quien esta conectado en ese momento y podrá realizar un establecimiento de llamada con el usuario elegido. Todo esto se hará con la interfaz grafica del usuario del portal. Por lo tanto todos los usuarios del portal deberán tener una cuenta skype, ésta se abrirá por



30

el administrador en el momento en que el usuario se registre en el portal. Entonces lo que nuestro portal hará será abrir una sesión Skype de forma automática cada vez que un usuario entre en el portal, de esta forma podremos ofrecer una lista de los usuarios que se encuentren conectados al portal en ese momento. Además la clave de acceso del usuario al portal será la misma utilizada para abrir la sesión con Skype, así el usuario podrá abrir sesión con Skype aunque no entre en el portal ya que también conocerá su cuenta Skype, por lo que el acceso será directamente con Skype, en este caso nuestro portal también agregará este usuario a la lista de usuarios en conexión del mismo. Como curiosidad para la mensajería instantánea el protocolo Skype 5 nos proporciona emoticones tanto para los Skype’s para Linux, Mac y Windows.

Para poder desarrollar Skype dentro de nuestro portal utilizaremos la herramienta que nos proporciona el developer.skype.com que es Skype4Java, el cual es una librería que representa Skype API como objetos, con propiedades, comandos, eventos y notificaciones usando Java. Como hemos dicho al principio de este documento nuestro lenguaje de programación va a ser Java por tanto esta librería es perfecta para implementar Skype en nuestro portal. Además esta librería permite el uso de Eclipse que es el programa que utilizamos nosotros para programar. A continuación hacemos un listado de los contenidos de Skype Public API 2.0 Reference Guide:

• Overview of the Skype API

• Using the Skype API on Windows

• Using the Skype API on Linux

• Using the Skype API on Mac

• Skype protocol

• Skype API reference

o Commands

o Objects

o Managing object properties

o Managing general parameters

o Notifications

o Error codes

• Release notes



31

2. Codificación audiovisual

2.1 Introducción Los creadores de este algoritmo fueron Abraham Lempel y Jacob Ziv. En 1977 publicaron un artículo en el que explicaron las bases del método de compresión basada en diccionarios. Al año siguiente, crearon otro artículo el cual explicaba una serie de variaciones del primero. Estos dos algoritmos creados en los años 1977 y 1978 son conocidos hoy en día como LZ77 y LZ78 respectivamente. LZ77, es un algoritmo LossLess (compresión de datos sin pérdidas). Los compresores basados en algoritmos “lossless” se utilizan cuando la información a comprimir es crítica y no se puede perder información, como por ejemplo en los archivos ejecutables, tablas de bases de datos, o cualquier tipo de información que no admita pérdida. A partir del LZ77 y el LZ78, surgieron varias modificaciones, como por ejemplo el LZW que es una variación del LZ78. Este último no utiliza ventana deslizante. Y el LZSS que es una variación del LZ77. Uno de los problemas que puede tener LZ77 es el diseño del tamaño del buffer. Y el espacio de búsqueda esta limitado a un pequeño subconjunto de los símbolos ya procesados con anterioridad. Podríamos decir que Lempel Ziv 77 es un algoritmo asimétrico, ya que la compresión es lenta pues se debe realizar el proceso de búsqueda y comparación de secuencias. Por el contrario la descompresión es más rápida ya que la descodificación se realiza buscando el índice de la secuencia en el diccionario. Evidentemente la búsqueda de las secuencias coincidentes debe ser lo más rápida posible, y es por eso que las versiones optimizadas del algoritmo se preocupan de tener un mejor acceso al buffer utilizando árboles, tablas de hash y memoria asociativa de hardware. LZ77 y LZ78 son algoritmos de compresión por diccionario. LZ77 puede realizar las compresiones y descompresiones más rápidamente que el LZ78, aunque el LZ78 permite comprimir secuencias más largas ya que su diccionario es mayor. Por estos motivos, el LZ77 debería aplicarse para compresiones de mensajes cortos y el LZ78 para mensajes de mayor longitud.

2.2 Descripción del algoritmo

2.2.1 Funcionamiento La idea fundamental de este método es utilizar una cadena de entrada. El codificador mantendrá una ventana respecto a la cadena entrada y cambia la entrada en la ventana de derecha a izquierda a medida que los símbolos se van codificando. El método esta basado en una ventana deslizante, la cual esta dividida en dos partes, la parte izquierda se llama el buffer de búsqueda (search buffer), mientras que la arte derecha se denomina buffer de adelantamiento (lookahead buffer) Buffer de búsqueda (search buffer)� esta parte es el diccionario o la historia que incluye los símbolos que han sido introducidos y codificados recientemente.



32

Buffer de adelantamiento (lookahead buffer)�Esta parte contiene el texto de la parte que se está codificando. El algoritmo LZ77 mantiene un registro de los últimos caracteres procesados de la entrada pero no construye un diccionario explícito. En cada instante el algoritmo está procesando un punto de la entrada, los n caracteres anteriores forman la historia del algoritmo ó ventana, lo que equivale al diccionario. En cada paso, la secuencia de símbolos que comienza en el punto actual de la entrada se busca en la ventana. Si se encuentra una coincidencia en la ventana que se considere lo suficientemente larga, en la salida se sustituye la cadena coincidente por un par que indica el desplazamiento hacia atrás y la longitud de la cadena coincidente. Como los pares desplazamiento-longitud ocupan menos que la cadena coincidente, se obtiene compresión. Si no se encuentra una coincidencia, la salida es una copia literal de la entrada. A continuación, se avanza la posición actual (y consecuentemente la ventana) la longitud de la coincidencia si la hubo, o bien un símbolo si no hubo coincidencia. El hecho de ir desplazando la ventana sobre la entrada hace que este algoritmo se denomine, como hemos dicho anteriormente, de ventana deslizante.

Figura 27. Descripción de la ventana.

El codificador escanea el buffer de búsqueda hacia atrás (de derecha a izquierda), buscando una coincidencia con el símbolo de entrada “X” en el buffer de mirar más allá. Se encuentra con un símbolo igual al de la entrada, la cual estará una distancia o una distancia o una distancia o una distancia o desplazamiendesplazamiendesplazamiendesplazamientotototo. El codificador sigue buscando más coincidencias con una longitud de una longitud de una longitud de una longitud de repetición mayor, repetición mayor, repetición mayor, repetición mayor, el codificador selecciona la coincidencia más larga, o si son todas de la misma longitud, selecciona la última que encuentra. Seleccionando la última coincidencia, en lugar de la primera, simplifica el programa ya que solo tiene que guardar la última coincidencia encontrada. En general, una marca LZ77 tiene tres partes:

(Desplazamiento, Longitud, Próximo Símbolo en el Buff er de mirar más allá) Este formato se escribe en el Archivo de Salida (Archivo Comprimido) y la ventana se mueve a la derecha el tamaño de la longitud más una posición para el próximo símbolo. Si la búsqueda hacia atrás, no encuentra ninguna coincidencia, se escribe un marca LZ77 con cero en el desplazamiento y longitud, y con el símbolo que no ha coincidido. Está es también una razón para que la marca tenga un tercer componente. Las marcas con desplazamiento y longitud nulas son comunes al principio de un trabajo de compresión cuando el buffer de búsqueda está vacío o casi vacío. Veamos un ejemplo concreto:

Paso 1: El compresor mira si el carácter a codificar existe en su diccionario, en este caso el carácter a no existe en el diccionario todavía, al no haber



33

codificado anteriormente este carácter. <0,0,a> El 0,0 indica que no existe este carácter en el diccionario. Paso 2: Al igual que en el paso numero 1, el carácter b no está en el diccionario por lo que no comprimirá este carácter. Paso 3: El carácter a codificar en este caso será el a, el cual si que estará en el diccionario del codificador y dentro de la ventana de los caracteres procesados. Por tanto en este caso será <2,1,c> esto nos indica que 2 posiciones antes ha aparecido el carácter y que la longitud es de 1, además incluye el siguiente carácter, en este caso el carácter c. Paso 4: En el siguiente paso el codificador mediante el diccionario creado con las caracteres ya codificados localiza que la secuencia de caracteres aba ya ha sido codificada anteriormente y que por tanto puede ser comprimida. <4,3,EOF> indica que 4 posiciones antes ha aparecido la cadena de caracteres (de longitud 3) a codificar .El EOF indica que no hay más caracteres ha codificar.

Imagen 28. Ejemplo de funcionamiento interno del al goritmo.

2.2.2 Tamaño de la ventana Uno de los aspecto más importantes a definir en este algoritmo es el tamaño de la ventana que se utilizará, evidentemente cuando mayor sea el tamaño de la ventana mayor será también las compresión, ya que la probabilidad de encontrar un coincidencia más larga en el diccionario será más elevada. Un posible inconveniente de definir el tamaño de la ventana grande es que necesitaremos más cantidad de bits para codificar el valor de desplazamiento. Además, como sabemos las coincidencias más cortas son las más probables, y deberíamos ahorrar bits en la codificación de los valores de desplazamiento y longitud de las coincidencias más probables. Estos problemas hacen que el dimensionado de la ventana sea una cuestión importante. Un tamaño típico es el que asigna 12 bits para el desplazamiento (ventana de 4096 bits) y una longitud con un máximo de 4 bits (15bytes de coincidencia máxima), lo que hacen un total de 16bits.

2.2.3 Pseudo código del algoritmo Codificación Comprimir (x) Se ha comprimido x [1…n-1] Mientras quede por leer Buscar i<n y L lo mayor posible tal que x[n…n+L+1] = x[i…i+L+1] Output n-1, L, x[n+L] Decodificación Descomprimir (y)



34

En cada momento se ha descomprimido el trozo x[1…n-1] Mientras quede por leer Sacar (i,L,s) Para k:=0…L-1 x[n+k]:= x[n+k]

No hay problema si n-i-k > n-1 Fin

2.3 Usos Reales El algoritmo LZ77 es utilizado en sistemas de compresión de archivos. Como por ejemplo GZIP, que usa un variación del LZ77 y un codificador Huffman. Este es muy usado en Unix/Linux (es gratuito) y es similar a ZIP aunque solo comprime o descomprime archivos de forma individual. Normalmente se comprimía con GZIP archivos .TAR o .GZ. LZ77 también es utilizado en el sistema de compresión WINRAR (que es la versión con interfaz grafica) o RAR (que es la versión de línea de comandos). Este sistema se puede utilizar tanto sobre la plataforma Linux como en Windows. En este tipo de compresor se utiliza LZSS que es una derivada del LZ77. LZSS permite cambiar el tamaño de la ventana deslizante de 64Kb a 4Mb. La longitud mínima de la secuencia que se considera como emparejamiento es de 2 y se usan códigos especiales para mejorar la codificación de los desplazamientos repetidos y también se utiliza la codificación de Huffman. En los sistemas de compresión ARJ también se utiliza LZ77. Las características principales de ARJ son que se puede llegar a obtener mejores ratios que los algoritmos de compresión ZIP, a cambio de ser más lento. ARJ realiza la compresión en dos fases, en la primera se utiliza el LZSS y en la segunda se utiliza la compresión de Huffman. ARJ permite usarse desde MS-DOS hasta Windows XP. LZ77 también es utilizado en algunos sistemas de compresión de información de mensajes SMS. El proceso de envío de un mensaje SMS consta de dos fases principales. En la segunda fase se le aplica una compresión binaria, para lo cual el primer paso consiste en transformar la cadena de texto del mensaje en un array de bytes. La librería que proporciona esa compresión está basada en la compresión de datos sin pérdida basada en el código de Huffman y el algoritmo LZ77. La ventaja de esto, es que los mensajes se pueden comprimir para que al almacenarlos en el móvil ocupen menos espacio, i la descompresión se realiza de una manera rápida para poder mostrar el mensaje al abrirlo.

2.4 Modos de uso del algoritmo LZ77 en nuestro proy ecto LZ77 que permite reducir el tamaño de los archivos sin reducir su calidad incluso imágenes de 16 millones de colores se pueden reducir más si reducimos la profundidad para reducir más el tamaño de la imagen. El modelo LZ77 es muy usado porque es fácil de implementar y es bastante eficiente. Se usa para es el caso de los archivos MP3, PNG, JPG, GIF, etc. El algoritmo LZ77 realiza las siguientes acciones que se pueden aplicar a nuestro proyecto de las siguientes maneras:

� Comprimir las imágenes estáticas que utilizamos, y los archivos de audio que guardamos en nuestras bases de datos.

� Comprimir la información que guardamos en la base de datos de usuarios, y de la base de datos de los proyectos.



35

� Comprimir los mensajes cortos como comentarios, avisos, intervenciones en el foro, datos personales.

La compresión ayuda a explotar el limitado ancho de banda de los canales de comunicación y recursos de almacenamiento. Y la criptografía se emplea en autentificación y protección de derechos reservados (por ejemplo en digital watermarking), así como aplicaciones tradicionales para incrementar sustancialmente la seguridad de datos. La combinación de ambas técnicas permite incrementar eficiencia y seguridad en la transmisión o almacenamiento de la información. Con las dos técnicas de compresión y de encriptado se consigue: • Transmisión de imágenes seguras usando encriptado de datos comprimidos. • Reconocimiento de patrones en conjuntos de datos comprimidos o encriptados,

señales o imágenes con aplicaciones de búsqueda en base de datos de imágenes. • Uso de compresión de datos para acelerar el procesamiento de imágenes,

reconocimiento de patrones automatizado o visualización de grandes conjuntos de datos.

Aplicando dichas técnicas a nuestro proyecto podemos conseguir:

o Reducir los costes de almacenamiento. o Optimizar la búsqueda de imágenes en nuestra base de datos. o Almacenar toda la información de los proyectos tanto en texto como en

imágenes y publicarlo rápidamente. o Junto con la seguridad que ofrece la criptografía podemos enviar

documentos del proyecto por correo electrónico. o Administrar nuestra base de datos de proyectos de universidades o Visualizar grandes conjuntos de datos como son nuestros proyectos

íntegros.

2.5 Código del programa elaborado A continuación introducimos el código fuente del programa elaborado en Java por el grupo I, que representa la codificación lz77. Por motivos de complejidad y tiempo el programa realiza la codificación de palabras y no realiza la decodificación, como veremos el los ejemplos que veremos en el siguiente punto el programa funciona correctamente en la mayoría de casos, aunque como veremos existen algunos casos para los cuales no se produce la salida esperada. A parte del código fuente (color azul) comentamos el programa (color rojo) de manera que el programa pueda entenderse de manera adecuada. Es importante destacar que la elaboración del programa nos ha ayudado a entender el funcionamiento en el que se basa el algoritmo estudiado, y que no ha sido fácil elaborarlo al ser difícil gestionar la recursividad y los diversos casos. La recursividad se ha utilizado para comprobar cuando no sólo coinciden una letra, de manera que si al coincidir una letra es imprescindible mirar si el siguiente carácter también coincide. Además del código fuente que adjuntamos también existe un applet que muestra gráficamente el funcionamiento de lz77 así como la salida de la codificación, es importante tener en cuenta que el tamaño del búfer en el applet puede ser cambiado por el usuario mientras que en nuestro programa el tamaño del búfer esta fijado en 4. Este applet no ha sido elaborado por el grupo, sino que se utiliza como soporte y por lo que es importante dejar claro que no es propiedad nuestra el applet.



36

Podemos ver el applet en la siguiente página Web:

• http://projects.hudecof.net/diplomovka/online/ucebnica/applets/AppletLZ77.html import java.io.*; public class lemp{ static int poscodstatica=0; public static void main(String[] args) { //definimos tamaño del buffer de 4

int buffer =4; System.out.println("<-----Bienvenido al programa de codificacion lz77 grupoi----->");

System.out.println(""); System.out.println("El tamaÃ±o del buffer es de 4"); System.out.println(""); //Inicialización de variables //El variable resultado consta de

//variable[0] indica el numero de posiciones anteriores donde se //encuentra la coincidencia

//variable[1] indica la longitude de la coincidencia //variable[2] indica la próxima letra a codificar

//variable[3] tiene valor 0 si la coincidencia es de un solo carácter y //valor 1 si la coincidencia es de má de un caracter

int posbufer=0; int poscod=0; int [] resultado = new int [4]; int posindice=0; String linea=""; int valor=0; linea=args[0]; int [] cadena=new int [linea.length()]; //Guardamos la palabra a codificar en un array for (int w=0;w<linea.length();w++){ cadena[w]=linea.charAt(w);} System.out.println("La cadena a codificar es : "+linea); System.out.println(""); //Bucle que mira cada una de las letras de la palabra a codificar for (int i=0;i<=cadena.length;i++){ //Llamada al método mira búfer resultado=mirabufer(posbufer,poscod,resultado,cadena,posindice);

//Si forma parte de una transacción incremento la posición a //variable[]codificar la longitud de la coincidencia, sino //incremento 1 if(resultado[3]==1){

poscod=poscod+resultado[1]+1; poscodstatica=poscod+resultado[1]+1;} else{ poscod++; poscodstatica++;} posindice=posbufer;

//Sólo incrementaremos la posicion del buffer si la posición a codificar es más grande que el tamaño del buffer if(poscod>=buffer){

posbufer++;} if(resultado[0]<resultado[1]){ resultado[1]--; poscod--;



37

} //Imprimos el resultado en forma de carácter System.out.print("<"); for (int j=0;j<2;j++){ System.out.print(resultado[j]+",");} int res=resultado[2]; char c=(char)res; System.out.print(c+">"); valor=resultado[2]; resultado[3]=0;resultado[2]=0;resultado[1]=0;resultado[0]=0; i=poscod; } if(valor!=36){ System.out.println("<0,0,$>");} System.out.println(""); System.out.println("FINAL"); }

//Función recursiva que mira si la letra a codificar ha aparecido anteriormente, recibiendo //como parámetros las posición del buffer, la posición a codificar, la cadena a //codificar, y un índice static int[] mirabufer(int posbufer,int poscod,int [] resultado, int[]cadena, int posindice){

int bufer=4; //Si es la primera letra codificamos sin mirar el buffer

if(poscod==0){ resultado[0]=0; resultado[1]=0; resultado[2]=cadena[poscod]; poscod++; posindice=0; return(resultado);}

//Comprobamos si coincide la posición a codificar con la posición del índice del buffer

if(cadena[posindice]==cadena[poscod]){ //Como coincide rellenamos la variable resultado con los valores //correspondientes.

resultado[0]=poscod-posbufer; resultado[1]=resultado[1]+1; //Si es la ultima posición devolvemos el resultado

//Si es el ultimo carácter a codificar ponemos el carácter dolar $(36) if(poscod==cadena.length-1){

resultado[2]=36; return(resultado);} else{ resultado[2]=cadena[poscod+1];}

if(poscod>poscodstatica&&poscodstatica!=0){ return(resultado); }

//Aumentamos la posición del índice y la posición a codificar y //volvemos a llamar a la función mira buffer para comprobar si la //siguiente letra también coincide.

posindice++; poscod++; resultado[3]=1; mirabufer(posindice,poscod,resultado,cadena,posindice); } //Entraremos cuando no coincida la posición else{



38

posindice++; if(resultado[3]==1){ return(resultado); }

//Entraremos en el if cuando el índice habrá recorrido //todas las posiciones del buffer, por lo que ponemos el los //valores en la variable resultado y devolvemos la variable //al método principal

if(posindice==poscod){ resultado[0]=0; resultado[1]=0; if(poscod==cadena.length-1){ resultado[2]=cadena[poscod]; return(resultado); } resultado[2]=cadena[poscod]; return(resultado); } mirabufer(posindice,poscod,resultado,cadena,posindice); } return(resultado); } }

2.6 Ejemplos sobre el programa A continuación mostramos algunos ejemplos con lo que veremos el funcionamiento del programa elaborado por el grupo. Ejemplo 1 En este caso introduciremos la palabra codificación. <0,0,c>, <0,0,o>,<0,0,d>,<0,0,i>,<0,0,f>,<0,0,a>,<0,0,n> indica que estos caracteres no han aparecido anteriormente o se encuentra fuera del tamaño del búfer por lo que no se pueden comprimir. <2,1,c> Notamos que el carácter i ha aparecido 2 posiciones antes y que la longitud de la coincidencia es de 1. También se incluye la c, de manera que estamos codificando 2 letras. <2,1,i> Indica que la c ha aparecido 2 posiciones antes y que la longitud de la coincidencia es de 1. También se incluye la i.

Figura 29. Prueba del programa con la palabra codificación .



39

Ejemplo 2 En este caso codificamos la palabra Manuel y como vemos no hay coincidencia alguna, por lo que vemos que la compresión no se produce.

Figura 30. Prueba del programa con la palabra Manuel . Ejemplo 3 Si introducimos manuele vemos que la ultima e al mirar en el búfer encontrará la coincidencia, por lo que sitúa la coincidencia 2 posiciones antes, con una longitud 1, el carácter $ indica que se ha finalizado con la codificación.

Figura 31. Prueba del programa con la palabra manuele. Ejemplo 4 En este caso vamos un paso más allá ya que las 2 últimas letras se repiten y por tanto se puede indicar que la coincidencia ha ocurrido. <2,2,$> indica que en el momento de codificar la última él comprueba que la letra e aparecido dos posiciones antes, pero además comprueba que la siguiente posición también coincide por lo que la longitud de la coincidencia en este caso es de 2.

Figura 32. Prueba del programa con la palabra manuele1.



40

Ejemplo 5 Prueba con la palabra pepe.

Figura 33. Prueba del programa con la palabra pepe.

Ejemplo 6 En el caso en el que probamos un caso extremo como puede ser la cadena aaaaaaaaaa vemos como no obtenemos la salida esperada ya que nos muestra que <3,5,a> tres posiciones antes a ocurrido un coincidencia de 5 caracteres por lo que no puede ser ya que como máximo podríamos obtener un coincidencia de 3 en esta caso, ya que nos situaríamos en la letra que estamos codificando.

Figura 34. Prueba del programa con la palabra aaaaaaaaaa.

2.7 Dudas surgidas en el seminario En este apartado se han incluido los comentarios y preguntas realizadas por lo demás grupos. Se incluyen también las respuestas para poder explicar las dadas surgidas en la presentación. Preguntas

1. Posible modificación dinámica del tamaño de la ventana deslizante para poder mejorar la eficiencia

2. Donde se realiza la compresión para los mensajes SMS 3. Como se implementa y que recursos necesitará utilizar el algoritmo en el móvil

4. En que grado se aplicara el algoritmo en nuestro proyecto Respuestas

1. El algoritmo LZ77 no permite la variación del tamaño de la ventana deslizante, es posible que algunas de sus versiones variadas puedan realizar este proceso. Si se pudiera realizar, este proceso seria muy costo, ya que para determinar el tamaño de la ventana, previamente se debe haber echo una



41

lectura completa del texto para poder decidirlo, con lo que conllevaría mas tiempo y mas recursos.

2. Cada Terminal móvil, posee un sistema para descomprimir los mensajes SMS que se reciben. Este sistema consiste en un programa que realiza la compresión del texto basándose en una librería que implementa el algoritmo de Fuman y el LZ77.

3. En principio, los recursos que necesita el móvil son los propios recursos que necesitaría para poder ejecutar este programa de descompresión. En un principio, se utiliza el LZ77 para poder conseguir una descompresión rápida.

4. Todavía no hemos decidido concretamente donde aplicarlo, pero lo mas probable es que lo apliquemos principalmente para realizar compresiones sobre texto, y en los casos donde se necesiten una alta velocidad de descompresión.



42

3. Base de datos

El entregable de Bases de Datos se compone por las partes que realizamos en los entregables anteriores que no eran correctas y que han sido modificadas.

3.1 Copias de seguridad Existen tres tipos de copias de seguridad que podemos aplicar a nuestros datos de nuestras bases de datos:

Copia total: Se trata de realizar una copia completa de todos los datos principales del sistema. El problema de esta es que ocupa mucho espacio. Copia diferencial: Se trata de realizar la copia de aquellos datos que hayan sido modificados respecto a una copia anterior, comparando el contenido de cada copia. El problema de este tipo de copia es que para restaurarla antes se debe restaurar una copia total anterior a esta, con lo que conlleva a un elevado tiempo de restauración. Copia incremental: Trata de realizar una copia de aquellos datos modificados desde una copia incremental anterior. Para poder restaurar una copia de este tipo, antes se debe restaurar todas las copias incrementales totales. El problema en este caso, se produciría en caso de perdida de una copia intermedia, ya que no se podría restaurar completamente. Puede pasar también que se estén copiando archivos cuyo contenido no haya sido modificado ya que realiza la actualización a partir de la comparación de las fechas de modificación.

Seguidamente especificamos que tipos de copias de seguridad realizamos para cada tipo de datos de nuestras bases de datos:

Proyectos: Para los datos almacenados en las bases de datos relacionados con los proyectos (texto, imágenes, archivos adjuntos, etc.) primero se realizará una copia total de todos, y a partir de esta, se realizaran copias incrementales cuando se detecte que ha cambiando la ultima fecha de modificación del proyecto. Información usuarios: Para la información de los usuarios (que serán archivos de texto donde se contemplaran los datos personales de cada usuario, como puede ser su nombre, dirección, correo, etc.) realizaremos también una copia total inicial, y en base a las modificaciones que se vayan realizando en cada perfil de usuario, se irán realizando copias diferenciales (ya que se realizará la copia cuando se haya cambiando algún campo del perfil del usuario). Comentarios sobre proyectos: Igual que en todos los datos, al principio también realizaremos una copia de seguridad total. Cuando se modifiquen alguno de esos comentarios realizaremos una copia diferencial (nos basaremos en las modificaciones del contenido de los comentarios). Aplicamos una copia de seguridad de este tipo porque consideramos que los comentarios de los proyectos también son importantes para poder tomar decisiones sobre la realización de estos. Consultas sobre proyectos: Consideramos que para las consultas de los proyectos no será necesario realizar copias de seguridad ya que no son datos importantes, que influyan en los proyectos.



43

3.2 DTD, XML y XML Schema

3.2.1 Definición Es una definición de un documento XML, en este documento definición podemos especificar las restricciones de las estructura del documento XML. El documento DTD puede ser interno o externo, es decir si incluimos la definición dentro del documento XML o incluimos la definición en un documento a parte. En este último caso se tendría que referenciar dentro del XML al documento DTD de la siguiente manera: <!DOCTYPE nombre_raíz SYSTEM “nombre_dtd.dtd”> Un DTD describe los elementos, atributos y valores permitidos para cada elemento admisibles dentro del XML. Una de las partes más importantes del DTD es que verifica los datos, y hace que el documento XML sea válido. En la siguiente tabla 1 vemos resumidas las propiedades de un DTD más importantes.

DTD especifica DTD describe

• Un formato de datos

• Formato común de datos entre aplicaciones

• Verificación los datos al intercambiarlos

• Verificación un mismo conjunto de datos

• Elementos: cuáles son las etiquetas permitidas y cuál es el contenido de cada etiqueta

• Estructura: en qué orden van las etiquetas en el documento

• Anidamiento: qué etiquetas van dentro de cuáles

Tabla 1. Características de los documentos DTD.

3.2.2 Cómo se hizo Para la definición del tipo de datos vimos que era más simple conceptualmente hablando diseñar un DTD, ya que para nuestra base de datos era el más adecuado, porque nos podemos basar en el documento XML, que es el documento dónde se clasifican las etiquetas que en el DTD las definimos.

3.2.3 Como lo definimos en nuestra base de datos Definimos todas las etiquetas del documento XML dentro de la definición del DTD como ELEMENT porque las etiquetas del documento XML no tienen atributos con valor. Si fuera el caso tendríamos a parte del ELEMENT un ATTLIST de la etiqueta. Clasificamos las agrupaciones de las definiciones de ELEMENT según las etiquetas que definimos en el documento XML. Primero ponemos la etiqueta principal como ELEMENT y sus atributos como objetos de una clase de dicha etiqueta. Por ejemplo: <!ELEMENT Busqueda (id_busqueda+, titulo?, descripción?, nivelurgencia?, id_area?, id_usuario?)> <!ELEMENT id_busqueda (#PCDATA)> <!ELEMENT titulo (#PCDATA)> <!ELEMENT id_tarea (#PCDATA)> En esta secuencia de DTD podemos observar que hemos definido los atributos de Búsqueda, como objetos de clase. Para cada atributo definimos su frecuencia con los



44

símbolos “+,?,*,|” que determinan si es obligatorio (+), si es opcional (?), si es opcional y puede haber más de un símbolo(*), y si es una opción entre varias (|). En la siguiente línea del DTD definimos cada uno de los objetos, si un objeto no se define después de haberlo indicado es porque ya se ha definido anteriormente, por esta razón es práctico el DTD porque solamente hace falta definir cada objeto una vez. En nuestro caso los objetos son de tipo #PCDATA o de tipo #EMPTY en el caso de los objetos opcionales. Hemos clasificado de la siguiente manera las etiquetas que forman parte de la etiqueta principal Portal: <!ELEMENT Portal <!ELEMENT Organización… <!ELEMENT Usuarios… <!ELEMENT Proyecto… <!ELEMENT ComentarioConsulta… <!ELEMENT Tarea… <!ELEMENT Búsqueda… <!ELEMENT Área… <!ELEMENT Propuesta… <!ELEMENT Aviso… Seguidamente mostramos nuestro DTD realizado:

<!ELEMENT portal (Organizacion,Usuarios,Proyecto,ComentarioConsulta,Tarea,Busqueda,Area,Propuesta,Aviso)> <!ELEMENT Organizacion (id_organizacion+,nombre+,telefono*,direccion?,email+,ONG?,Universidad?)> <!ELEMENT id_organizacion (ONG|Universidad)> <!ELEMENT ONG (id_ong)> <!ELEMENT id_ong (#PCDATA)> <!ELEMENT Universidad (id_universidad)> <!ELEMENT id_universidad (#PCDATA)> <!ELEMENT nombre (#PCDATA)> <!ELEMENT telefono (#PCDATA)> <!ELEMENT direccion (#PCDATA)> <!ELEMENT email (#PCDATA)> <!ELEMENT Usuarios (id_usuario+,id_organizacion+,nombre+,apellidos+,password+,email+,area+,rango+,CoordinadoresUniversidad?,ProfesoresUniversidad?,AlumnosUniversidad?,CoordinadoresONG?,ResponsablesONG?,VoluntariosONG?)> <!ELEMENT id_usuario (CoordinadoresUniversidad|ProfesoresUniversidad|AlumnosUniversidad|CoordinadoresONG|ResponsablesONG|VoluntariosONG)> <!ELEMENT CoordinadoresUniversidad (id_coordinador)> <!ELEMENT id_coordinador (#PCDATA)> <!ELEMENT ProfesoresUniversidad (id_profesor)> <!ELEMENT id_profesor (#PCDATA)> <!ELEMENT AlumnosUniversidad (id_alumno)> <!ELEMENT id_alumno (#PCDATA)> <!ELEMENT CoordinadoresONG (id_coordinador)> <!ELEMENT ResponsablesONG (id_responsable)> <!ELEMENT id_responsable (#PCDATA)> <!ELEMENT VoluntariosONG (id_voluntario)> <!ELEMENT id_voluntario (#PCDATA)> <!ELEMENT apellidos (#PCDATA)>

45

<!ELEMENT password (#PCDATA)> <!ELEMENT area (#PCDATA)> <!ELEMENT rango (#PCDATA)>

<!ELEMENT Proyecto (id_proyecto+,area+,nombre+,descripcion+,comentarios*,nivelurgencia+,id_usuario+)> <!ELEMENT id_proyecto (#PCDATA)> <!ELEMENT descripcion (#PCDATA)> <!ELEMENT comentarios (#PCDATA)> <!ELEMENT nivelurgencia (#PCDATA)> <!ELEMENT ComentarioConsulta (id_con+,descripcion+,id_usuario+,fecha*,nivelurgencia+)> <!ELEMENT id_con (#PCDATA)> <!ELEMENT fecha (#PCDATA)> <!ELEMENT Tarea (id_tarea+,descripcion+,id_usuario+,id_proyecto+)> <!ELEMENT id_tarea (#PCDATA)> <!ELEMENT Busqueda (id_busqueda+,titulo?,descripcion?,nivelurgencia+,id_area?,id_usuario?)> <!ELEMENT id_busqueda (#PCDATA)> <!ELEMENT titulo (#PCDATA)> <!ELEMENT id_area (#PCDATA)> <!ELEMENT Area (id_area+,nombre+,descripcion+)> <!ELEMENT Propuesta (id_Usuario+,id_propuesta+,area+,descripcion+,fecha*,nivelurgencia+,CoordinadoresUniversidad?,ProfesoresUniversidad?,ResponsablesONG?,CoordinadoresONG?)> <!ELEMENT id_Usuario (CoordinadoresUniversidad|ProfesoresUniversidad|ResponsablesONG|CoordinadoresONG) > <!ELEMENT id_propuesta (#PCDATA)> <!ELEMENT Aviso (id_Usuario+,id_aviso+,texto+,fecha*)> <!ELEMENT id_aviso (#PCDATA)> <!ELEMENT texto (#PCDATA)>

A continuación, mostramos nuestro XML realizado

<?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE portal SYSTEM "er.dtd"> <portal> <Organizacion> <id_organizacion> <Universidad> <id_universidad></id_universidad> </Universidad> <!-- <ONG> <id_ong></id_ong> </ONG>

46

--> </id_organizacion> <nombre></nombre> <telefono></telefono> <direccion></direccion> <email></email> </Organizacion> <Usuarios> <id_usuario> <AlumnosUniversidad> <id_alumno></id_alumno> </AlumnosUniversidad>  </id_usuario> <id_organizacion> <Universidad> <id_universidad> </id_universidad> </Universidad>  </id_organizacion> <nombre></nombre> <apellidos></apellidos> <password></password> <email></email> <area></area> <rango></rango> </Usuarios> <Proyecto> <id_proyecto></id_proyecto> <area></area> <nombre></nombre> <descripcion></descripcion> <comentarios></comentarios> <nivelurgencia></nivelurgencia> <id_usuario> <AlumnosUniversidad> <id_alumno></id_alumno> </AlumnosUniversidad>  </id_usuario> </Proyecto> <ComentarioConsulta> <id_con></id_con> <descripcion></descripcion> <id_usuario> <AlumnosUniversidad> <id_alumno></id_alumno> </AlumnosUniversidad>

47

 </id_usuario> <fecha></fecha> <nivelurgencia></nivelurgencia> </ComentarioConsulta> <Tarea> <id_tarea></id_tarea> <descripcion></descripcion> <id_usuario> <AlumnosUniversidad> <id_alumno></id_alumno> </AlumnosUniversidad>  </id_usuario> <id_proyecto></id_proyecto> </Tarea> <Busqueda> <id_busqueda></id_busqueda> <titulo></titulo> <descripcion></descripcion> <nivelurgencia></nivelurgencia> <id_area></id_area> <id_usuario> <AlumnosUniversidad> <id_alumno></id_alumno> </AlumnosUniversidad>  </id_usuario> </Busqueda> <Area> <id_area></id_area> <nombre></nombre> <descripcion></descripcion> </Area> <Propuesta> <id_Usuario> <ProfesoresUniversidad> <id_profesor></id_profesor> </ProfesoresUniversidad>  </id_Usuario> <id_propuesta></id_propuesta> <area></area> <descripcion></descripcion> <fecha></fecha> <nivelurgencia></nivelurgencia>

48

</Propuesta> <Aviso> <id_Usuario> <ProfesoresUniversidad> <id_profesor></id_profesor> </ProfesoresUniversidad>  </id_Usuario> <id_aviso></id_aviso> <texto></texto> <fecha></fecha> </Aviso> </portal>

Y este es nuestro XML Schema: <?xml version="1.0" encoding="UTF-8" standalone="no"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified"> <xs:import namespace="http://www.w3.org/XML/1998/namespace"/> <xs:element name="portal"> <xs:complexType> <xs:sequence> <xs:element ref="Organizacion"/> <xs:element ref="Usuarios"/> <xs:element ref="Proyecto"/> <xs:element ref="ComentarioConsulta"/> <xs:element ref="Tarea"/> <xs:element ref="Busqueda"/> <xs:element ref="Area"/> <xs:element ref="Propuesta"/> <xs:element ref="Aviso"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="Organizacion"> <xs:complexType> <xs:sequence> <xs:element ref="id_organizacion" maxOccurs="unbounded"/> <xs:element ref="nombre" maxOccurs="unbounded"/> <xs:element ref="telefono" minOccurs="0" maxOccurs="unbounded"/> <xs:element ref="direccion" minOccurs="0"/> <xs:element ref="email" maxOccurs="unbounded"/> <xs:element ref="ONG" minOccurs="0"/> <xs:element ref="Universidad" minOccurs="0"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="id_organizacion"> <xs:complexType> <xs:choice> <xs:element ref="ONG"/> <xs:element ref="Universidad"/> </xs:choice> </xs:complexType> </xs:element>



49

<xs:element name="ONG"> <xs:complexType> <xs:sequence> <xs:element ref="id_ong"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="id_ong"> <xs:complexType mixed="true"/> </xs:element> <xs:element name="Universidad"> <xs:complexType> <xs:sequence> <xs:element ref="id_universidad"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="id_universidad"> <xs:complexType mixed="true"/> </xs:element> <xs:element name="nombre"> <xs:complexType mixed="true"/> </xs:element> <xs:element name="telefono"> <xs:complexType mixed="true"/> </xs:element> <xs:element name="direccion"> <xs:complexType mixed="true"/> </xs:element> <xs:element name="email"> <xs:complexType mixed="true"/> </xs:element> <xs:element name="Usuarios"> <xs:complexType> <xs:sequence> <xs:element ref="id_usuario" maxOccurs="unbounded"/> <xs:element ref="id_organizacion" maxOccurs="unbounded"/> <xs:element ref="nombre" maxOccurs="unbounded"/> <xs:element ref="apellidos" maxOccurs="unbounded"/> <xs:element ref="password" maxOccurs="unbounded"/> <xs:element ref="email" maxOccurs="unbounded"/> <xs:element ref="area" maxOccurs="unbounded"/> <xs:element ref="rango" maxOccurs="unbounded"/> <xs:element ref="CoordinadoresUniversidad" minOccurs="0"/> <xs:element ref="ProfesoresUniversidad" minOccurs="0"/> <xs:element ref="AlumnosUniversidad" minOccurs="0"/> <xs:element ref="CoordinadoresONG" minOccurs="0"/> <xs:element ref="ResponsablesONG" minOccurs="0"/> <xs:element ref="VoluntariosONG" minOccurs="0"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="id_usuario"> <xs:complexType> <xs:choice> <xs:element ref="CoordinadoresUniversidad"/> <xs:element ref="ProfesoresUniversidad"/> <xs:element ref="AlumnosUniversidad"/> <xs:element ref="CoordinadoresONG"/> <xs:element ref="ResponsablesONG"/> <xs:element ref="VoluntariosONG"/>



50

</xs:choice> </xs:complexType> </xs:element> <xs:element name="CoordinadoresUniversidad"> <xs:complexType> <xs:sequence> <xs:element ref="id_coordinador"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="id_coordinador"> <xs:complexType mixed="true"/> </xs:element> <xs:element name="ProfesoresUniversidad"> <xs:complexType> <xs:sequence> <xs:element ref="id_profesor"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="id_profesor"> <xs:complexType mixed="true"/> </xs:element> <xs:element name="AlumnosUniversidad"> <xs:complexType> <xs:sequence> <xs:element ref="id_alumno"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="id_alumno"> <xs:complexType mixed="true"/> </xs:element> <xs:element name="CoordinadoresONG"> <xs:complexType> <xs:sequence> <xs:element ref="id_coordinador"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="ResponsablesONG"> <xs:complexType> <xs:sequence> <xs:element ref="id_responsable"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="id_responsable"> <xs:complexType mixed="true"/> </xs:element> <xs:element name="VoluntariosONG"> <xs:complexType> <xs:sequence> <xs:element ref="id_voluntario"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="id_voluntario"> <xs:complexType mixed="true"/> </xs:element> <xs:element name="apellidos">



51

<xs:complexType mixed="true"/> </xs:element> <xs:element name="password"> <xs:complexType mixed="true"/> </xs:element> <xs:element name="area"> <xs:complexType mixed="true"/> </xs:element> <xs:element name="rango"> <xs:complexType mixed="true"/> </xs:element> <xs:element name="Proyecto"> <xs:complexType> <xs:sequence> <xs:element ref="id_proyecto" maxOccurs="unbounded"/> <xs:element ref="area" maxOccurs="unbounded"/> <xs:element ref="nombre" maxOccurs="unbounded"/> <xs:element ref="descripcion" maxOccurs="unbounded"/> <xs:element ref="comentarios" minOccurs="0" maxOccurs="unbounded"/> <xs:element ref="nivelurgencia" maxOccurs="unbounded"/> <xs:element ref="id_usuario" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="id_proyecto"> <xs:complexType mixed="true"/> </xs:element> <xs:element name="descripcion"> <xs:complexType mixed="true"/> </xs:element> <xs:element name="comentarios"> <xs:complexType mixed="true"/> </xs:element> <xs:element name="nivelurgencia"> <xs:complexType mixed="true"/> </xs:element> <xs:element name="ComentarioConsulta"> <xs:complexType> <xs:sequence> <xs:element ref="id_con" maxOccurs="unbounded"/> <xs:element ref="descripcion" maxOccurs="unbounded"/> <xs:element ref="id_usuario" maxOccurs="unbounded"/> <xs:element ref="fecha" minOccurs="0" maxOccurs="unbounded"/> <xs:element ref="nivelurgencia" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="id_con"> <xs:complexType mixed="true"/> </xs:element> <xs:element name="fecha"> <xs:complexType mixed="true"/> </xs:element> <xs:element name="Tarea"> <xs:complexType> <xs:sequence> <xs:element ref="id_tarea" maxOccurs="unbounded"/> <xs:element ref="descripcion" maxOccurs="unbounded"/> <xs:element ref="id_usuario" maxOccurs="unbounded"/>



52

<xs:element ref="id_proyecto" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="id_tarea"> <xs:complexType mixed="true"/> </xs:element> <xs:element name="Busqueda"> <xs:complexType> <xs:sequence> <xs:element ref="id_busqueda" maxOccurs="unbounded"/> <xs:element ref="titulo" minOccurs="0"/> <xs:element ref="descripcion" minOccurs="0"/> <xs:element ref="nivelurgencia" maxOccurs="unbounded"/> <xs:element ref="id_area" minOccurs="0"/> <xs:element ref="id_usuario" minOccurs="0"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="id_busqueda"> <xs:complexType mixed="true"/> </xs:element> <xs:element name="titulo"> <xs:complexType mixed="true"/> </xs:element> <xs:element name="id_area"> <xs:complexType mixed="true"/> </xs:element> <xs:element name="Area"> <xs:complexType> <xs:sequence> <xs:element ref="id_area" maxOccurs="unbounded"/> <xs:element ref="nombre" maxOccurs="unbounded"/> <xs:element ref="descripcion" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="Propuesta"> <xs:complexType> <xs:sequence> <xs:element ref="id_Usuario" maxOccurs="unbounded"/> <xs:element ref="id_propuesta" maxOccurs="unbounded"/> <xs:element ref="area" maxOccurs="unbounded"/> <xs:element ref="descripcion" maxOccurs="unbounded"/> <xs:element ref="fecha" minOccurs="0" maxOccurs="unbounded"/> <xs:element ref="nivelurgencia" maxOccurs="unbounded"/> <xs:element ref="CoordinadoresUniversidad" minOccurs="0"/> <xs:element ref="ProfesoresUniversidad" minOccurs="0"/> <xs:element ref="ResponsablesONG" minOccurs="0"/> <xs:element ref="CoordinadoresONG" minOccurs="0"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="id_Usuario"> <xs:complexType> <xs:choice> <xs:element ref="CoordinadoresUniversidad"/> <xs:element ref="ProfesoresUniversidad"/> <xs:element ref="ResponsablesONG"/> <xs:element ref="CoordinadoresONG"/>



53

</xs:choice> </xs:complexType> </xs:element> <xs:element name="id_propuesta"> <xs:complexType mixed="true"/> </xs:element> <xs:element name="Aviso"> <xs:complexType> <xs:sequence> <xs:element ref="id_Usuario" maxOccurs="unbounded"/> <xs:element ref="id_aviso" maxOccurs="unbounded"/> <xs:element ref="texto" maxOccurs="unbounded"/> <xs:element ref="fecha" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="id_aviso"> <xs:complexType mixed="true"/> </xs:element> <xs:element name="texto"> <xs:complexType mixed="true"/> </xs:element> </xs:schema>

3.2.4 Comparativa de XMLS con DTD Un esquema XML (XML schema) es algo similar a un DTD, es decir, define qué elementos puede contener un documento XML, cómo están organizados, y qué atributos y de qué tipo pueden tener sus elementos, pero la utilización de schemas ofrece nuevas posibilidades en el tratamiento de los documentos. Los schemas describen el contenido y la estructura de la información, pero de una forma más precisa. Los esquemas indican tipos de datos, número mínimo y máximo de ocurrencias y otras características más específicas. La ventaja de utilizar los schemas con respecto a los DTDs son:

• Usan sintaxis de XML, al contrario que los DTDs. • Permiten especificar los tipos de datos. • Son extensibles (esto es, permite crear nuevos elementos).

Por ejemplo, un schema nos permite definir el tipo del contenido de un elemento o de un atributo, y especificar si debe ser un número entero, una cadena de texto, una fecha, etc. Los DTDs permiten definir texto como PCDATA. Las limitaciones de la DTD son las siguientes:

• Posee un lenguaje propio de escritura lo que ocasiona problemas a la hora del aprendizaje, pues no sólo hay que aprender XML, sino también conocer el lenguaje de las DTDs.

• Para el procesado del documento, las herramientas y analizadores (parsers) empleados para tratar los documentos XML deben ser capaces de procesar también las DTDs.

• No permite el uso de namespaces y estos son muy útiles ya que permiten definir elementos con igual nombre dentro del mismo contexto, siempre y cuando se anteponga un prefijo al nombre del elemento.



54

• Tiene una tipología para los datos del documento extremadamente limitada, pues no permite definir el que un elemento pueda ser de un tipo número, fecha, etc. sino que sólo presenta variaciones limitadas sobre cadenas.

• El mecanismo de extensión es complejo y frágil ya que está basado en sustituciones sobre cadenas y no hace explicitas las relaciones, es decir, que dos elemento que tienen definido el mismo modelo de contenido no presentan ninguna relación.

Estos problemas son superados gracias a la especificación de XML Schema, ya que los esquemas permiten un lenguaje mucho más expresivo y un intercambio de información mucho más robusto.

3.3 RSS y metadatos

3.3.1 Uso de metadatos en nuestro proyecto

• Contenido: Para guardar proyectos enteros

o tipo de proyecto: ingeniería civil, etc. o incluye video: S/N o incluye fotografías: S/N o Nombre del autor: nombre apellido. o Tipo de letra utilizado: Arial o Tamaño de la letra utilizada: 12

• Viabilidad Mutable

o Número páginas del documento: X pags. o Han incluido páginas?: S/N o Fecha última modificación: DD/MM/AA

Inmutables

o Nombre del fichero: nombre

• Función Simbólicos

o Número de líneas: 178 líneas. o Número de ficheros de video: 3 videos. o Número de fotografías: 78 fotografías.

Lógicos

o Resumen breve de lo que trata el documento: trata de la transformación…

o Índice del documento: índice. o Número de personas que trabajan en el documento: 7 personas.

Subsimbólicos

o Formato del documento: JPG, DOC. o Plataformas en las que se puede ver el fichero: Linux, Windows.

• Técnicos para el comportamiento del sistema

o Información de seguridad: contraseñas, documentación HW y SW y seguimiento de tiempos de respuesta

• Administrativos para el manejo y administración de recursos de información



55

o Adquisición de información: búsquedas, consultas, comentarios, proyectos, avisos, notas de prensa

o Localización de información: documentación y adjuntos de los proyectos (p.v. coordinadores/administradores)

• Preservación para el manejo y preservación de información

o Estado de los recursos: información multimedia, VoIP

3.3.2 RSS (Really Simple Sindication) RSS forma parte de la familia XML desarrollado para sitios que actualizan con frecuencia su información Ventajas: Permite consultar gran cantidad de fuentes sin necesidad de visitar la web Podemos clasificar las noticias por fuentes, temas ... Actualización inmediata de las noticias que se hayan producido en el sitio web Inconvenientes: Requiere de un software (agregador) para poder visualizar las noticias.

3.3.3 Uso de RSS en nuestro proyecto A través de RSS nuestro portal permitirá a sus usuarios

o Visualizar nuevos proyectos que se hayan podido introducir en el portal o Consultar las diferentes noticias respecto a las ONG’s o a las

Universidades De esta manera nuestros usuarios mediante un agregador no necesitarán conectarse a el portal web para poder consultar nuevas noticias o proyectos



56

4. Interfaz de usuario

4.1 Contacto con Universidades y ONG's Para poder realizar los encuentros para hacer las entrevistas primero enviamos un correo electrónico a cada una de las personas que habíamos seleccionado. A las personas que conocíamos hablamos directamente con ellas para quedar en una cita, y así poder realizar la entrevista. Mas tarde si no nos habían respondido a la petición del correo electrónico llamábamos por teléfono hasta conseguir cita, en algunos casos tuvimos que presentarnos sin cita previa debido a la moratoria concretamente de algunas organizaciones. Los correos electrónicos que enviamos a las ONGS y a los profesores para solicitar una cita fueron los siguientes:

Buenos días, Escribimos este correo electrónico desde la Universitat Pompeu Fabra, concretamente desde la escuela superior politécnica. Estamos realizando un proyecto final de carrera para aunar las ONGs con el mundo universitario. Se trata de un portal web que se utilizaría para que las ONGs propongan proyectos que necesitan realizar, y que la comunidad universitaria se encargará de estudiar y desarrollar. Este portal esta orientado para que se trabaje conjuntamente alumnos, voluntarios, profesores, miembros de la ONG, coordinadores de proyectos por parte de las ONGs y de la universidad. (Cualquier ONGs, y cualquier universidad a nivel nacional en principio) Estamos en una parte del proyecto en que es necesario un estudio etnográfico de las personas que van a utilizar potencialmente el portal web. Por tanto nos gustaría poder concertar una entrevista con un responsable de Médicos sin Fronteras para establecer cómo hacemos las diversas entrevistas y observaciones de trabajo que necesitamos para llevar a término nuestro estudio. Esperamos vuestra respuesta, Jara Pascual 654 89 35 02 Octavio Moreno 651 88 25 73 Tutora responsable: Raquel Navarro Prieto [email protected]

Buenos días, Escribimos este correo electrónico desde la Universitat Pompeu Fabra, concretamente desde la escuela superior politécnica. Estamos realizando un proyecto final de carrera para aunar las ONGs con el mundo universitario. Se trata de un portal web que se utilizaría para que las ONGs propongan proyectos que necesitan realizar, y que la comunidad universitaria se encargará de estudiar y desarrollar. Este portal esta orientado para que se trabaje conjuntamente alumnos, voluntarios, profesores, miembros de la ONG, coordinadores de proyectos por parte de las ONGs y de la universidad. (Cualquier ONGs, y cualquier universidad a nivel nacional en principio) Estamos en una parte del proyecto en que es necesario un estudio etnográfico de las personas que van a utilizar potencialmente el portal web. Por tanto nos gustaría poder



57

concertar una entrevista contigo para hacer las diversas entrevistas y observaciones de trabajo que necesitamos para llevar a término nuestro estudio. Esperamos vuestra respuesta, Jara Pascual 654 89 35 02 Octavio Moreno 651 88 25 73 Tutora responsable: Raquel Navarro Prieto [email protected]

4.2 Justificación de la elección de los profesores y ONGs entrevistados Para realizar el estudio etnográfico escogimos a dos personas por cada perfil y por cada comunidad para tener una referencia más exacta de cómo trabajan cada uno. Elegimos a profesores que estaban relacionados directamente con nosotros, o habían estado relacionados para así no tener el muro del rechazo en frente de un estudio etnográfico. En cuanto a las organizaciones tuvimos que elegir a aquellas con las que mantuvimos buena relación antes de comenzar las entrevistas, ya que no conocíamos a nadie dentro de ellas para que nos abrieran las puertas y con quien podríamos aplicar relaciones de confianza. Elegimos a dos profesores coordinadores de la universidad Pompeu Fabra, a dos profesores de la universidad Pompeu Fabra, y a dos alumnos de doctorado, uno de la universidad Pompeu Fabra y otro de la universidad Politécnica de Cataluña. En cuanto a la comunidad de las organizaciones no gubernamentales, escogimos a Médicos sin fronteras, UNICEF e Ingenieros sin fronteras. Un coordinador responsable de Médicos sin fronteras, y una coordinadora responsable de Ingenieros sin fronteras. Dos miembros de Ingenieros sin fronteras y un voluntario de Médicos sin fronteras, y de Ingenieros sin fronteras. Y una voluntaria de Amnistía internacional con la que teníamos un contacto previo al estudio. Para tener la perspectiva de la gestión del portal Web, tuvimos una entrevista con un administrador de la empresa Tyco Electronics AMP España y otro de GrupoConstant. Después de entablar conversaciones con UNICEF que parecía que estaban muy interesados, nos decidimos a ir a verles en persona. Cuál fue nuestra sorpresa que al explicarles de nuevo el proyecto, nos empezaron a dar largas, y finalmente no nos dejaron ver o hacerles una entrevista de cómo trabajaban. Se sintieron amenazados por invasión de la intimidad y nos echaron de malas formas, diciendo que ya nos llamarían. Cuando llegamos a casa para analizar la información que habíamos recopilado de otras organizaciones recibimos un correo electrónico de UNICEF en el que se nos decía que no habría una reunión. El correo electrónico recibido es el siguiente:

De : Maria Mur <[email protected]>

À: [email protected], [email protected] Date : 14 nov. 2006 16:11 Objet : solicitud de información estudio etnográfico

Apreciados Jara y Octavio,

Muchas gracias por vuestro mail del pasado día 8. Lamento informaros que no podemos proporcionaros esta información ya que, dentro de nuestras funciones, no se contempla hacer estudios etnográficos. De todos modos, me permito informaros que existe un portal web www.tupatrocinio.com, que contempla los extremos sobre los que hacéis referencia.



58

Un saludo.

Maria Mur Duat

Coordinadora autonòmica de programes

UNICEF-Comitè de Catalunya

Mallorca, 346

08013 Barcelona

Telèf. 34 93 451 56 74

Fax 34 93 453 15 65

[email protected]

Per a cada infant,

Salut, Educació, Igualtat, Protecció

AIXÍ FEM AVANÇAR LA HUMANITAT

4.3 Experiencia del trato recibido Después de haber realizado todas las entrevistas que se habían planeado, llevaremos a cabo un breve informe sobre la experiencia durante estas entrevistas y el trato recibido por parte de los participantes en este estudio. Empezaremos por la experiencia: La verdad es que en un primer momento nos pareció algo difícil de realizar, ya que le hecho de tener que hacer entrevistas formales nos asustaba un poco. Pero después de hablarlo y resolver dudas nos pusimos manos a la obra. Lo primero que hicimos fue escribir un guión de presentación de nosotros y del proyecto que estamos llevando a cabo. Una vez escrito lo enviamos por e-mail, a los perfiles elegidos. Una vez recibidas las respuestas sobre las citas concertadas fuimos visitándolos. Este paso, nos ha resultado una experiencia bastante agradable y muy enriquecedora, ya que el trato directo con la persona nos ha proporcionado una visión de realidad. Recogida toda la información pasamos a realizar un análisis de los distintos informes realizados con tal de encontrar puntos en común entre los perfiles que nos ayuden a crear la interfaz que más se ajuste a las necesidades de los usuarios. Esto lo veremos en el informe que presentamos posteriormente. Respecto al trato recibido podemos clasificarlo en dos tipos: Bueno Malo Empezaremos por los buenos y dentro de este perfil encontramos:

Miembros Universitarios: este grupo ha tenido un trato bastante directo y con un grado de implicación bastante importante en el proyecto. Han respondido rápidamente a nuestra propuesta de entrevista y la información que nos han dado ha resultado ser de gran ayuda para caracterizar la interfaz de los perfiles. Además de un comportamiento muy amigable y sincero.



59

Médicos Sin Fronteras: esta ONG hemos ubicarla en este perfil porque a pesar de que en primera instancia se mostraron reticentes a concedernos una entrevista, pudimos hablar con el responsable de las Delegaciones de Aragón, Baleares y Cataluña. Tuvimos que explicarle de qué iba el proyecto porque pensaba que no era la persona adecuada para atendernos, de ahí la reticencia. Durante la entrevista el trato recibido fue bastante bueno, con cierto interés por el proyecto y con respuestas llenas de información. Una vez terminada la entrevista, nos mostró las áreas de las distintas secciones que tiene la sede y esto nos ayudó a la hora de definir el ambiente y puesto de trabajo. Ingenieros Sin Fronteras: este caso es un poco parecido al anterior pero la reticencia fue mayor y después de una larga conversación para encontrar al menos a 2 personas, porque la mayoría nos daban excusas, conseguimos realizar nuestras entrevistas. Desconocemos el motivo de la falta de colaboración posterior pero la verdad es que se limitaron a contestarnos las preguntas escuetamente sin facilitarnos ninguna información adicional que pudiera ayudarnos. Entendemos el esfuerzo que para ellos también supone y por eso le hemos clasificado aquí.

Voluntarios y usuarios externos a las organizaciones y a las universidades: Nos han mostrado más facilidad, y amabilidad que el resto de perfiles. Les comentábamos el proyecto y estaban encantados de ayudarnos, debido a que son voluntarios o usuarios externos hemos tenido que hacer las entrevistas en sus lugares de trabajo o en cafeterías.

Ahora en el perfil de los malos encontramos: UNICEF: respecto a esta ONG debemos decir que no hemos recibido ningún tipo de colaboración, ya que desde un principio ni siquiera contestaron a nuestro e-mail de propuesta ni a nuestras llamadas. Decidimos presentarnos en su sede de la C/Mallorca. Una vez allí nos atendió una comercial que nos pasó con una responsable de área. Le comentamos el proyecto que estamos llevando a cabo y nos dice que no recuerda haber recibido ningún correo, pero nos pide los datos para buscarlo. De todas formas desde un primer momento se mostraron muy empeñados en no concedernos la entrevista y ponían trabas de cualquier tipo. Finalmente optamos por marcharnos y cuál fue nuestra sorpresa que al llegar a casa y abrir nuestros correos, habíamos recibido un e-mail de la responsable que nos atendió diciéndonos que si queríamos información visitáramos su página Web.

Médicos Sin Fronteras: hemos decidido a última hora incluir a esta ONG dado que la persona con la que contactamos para la entrevista, que no fue la que entrevistamos, nos ha enviado un correo diciéndonos que no hace falta que les informemos de cómo va el proyecto porque no están interesados y que como hemos salido tan contentos con la información que necesitábamos no es necesario tampoco que les ‘molestemos’ con más dudas que podamos tener. Esta semana a última hora hemos solucionado este inconveniente, e incluso hemos recibido mas ayuda por parte de sus voluntarios.



60

4.4 Cómo hacemos una entrevista Antes de ir in situ a hacer la entrevista nos hemos hecho un guión de toda la información que teníamos que recopilar. Para cada uno de los puntos estuvimos mirando si era un punto para observar o un punto adecuado para preguntar en una entrevista. A partir de estas valoraciones creamos un modelo de entrevista para los perfiles de ambas comunidades y un guión para la observación. La observación la hacíamos mientras estábamos en medio de la entrevista. Al finalizar cada entrevista, siempre preguntábamos a nuestros perfiles si nos querían comentar alguna cosa más que no aparecía dentro de las preguntas de la entrevista, y hablábamos de forma distendida con el perfil para así sacar más información. Con los miembros de la comunidad universitaria las entrevistas han sido mucho más largas y productivas que con los miembros de las organizaciones, ya que en el mundo de las ONGs parece que llevan un elevado nivel de estrés. Y tenían poco tiempo para dedicarnos. Suponemos que si hubiéramos tenido más tiempo para dedicarlo al estudio etnográfico, hubiéramos hecho un proceso de acercamiento a las organizaciones de una forma mucho más lenta y no tan agresiva como la que hemos realizado ahora. A los usuarios externos, a los administradores de sistemas y a los voluntarios se les ha variado el numero de preguntas, se les hacen las mismas pero en menor cantidad porque vemos que no es lógico a un usuario “de la calle” hacerle las misma preguntas que ha un coordinador de un proyecto. A este tipo de perfil le hemos tenido que hacer las entrevistas en sus lugares de trabajo, o en cafeterías, por tanto no tenemos observación de su ambiente de trabajo. Antes de comenzar una entrevista nos presentamos, presentamos el proyecto, y establecemos una pequeña conversación. Somos amables y corteses a la hora de hacer las preguntas, y todas las preguntas no las hacemos en el orden del guión, sino como van surgiendo a lo largo de la conversación. El tiempo aproximado de hacer una entrevista con toda la información es de una hora para el caso de la comunidad universitaria y de media hora para las organizaciones. La observación hemos visto que no la podemos hacer sentándonos toda la mañana con nuestros perfiles, sino mientras realizamos la entrevista. Esto ocurre porque se sienten incómodos los perfiles si les observas sin preguntar nada, y piensan que pierden el tiempo si estamos nosotros allí. El tiempo dedicado a una entrevista es más comprensible que el tiempo que se dedica a la observación. Hemos pensado que si queremos obtener más información de cada uno de las organizaciones tendríamos que hacernos pasar como voluntarios de cada una de ellas durante un periodo de tiempo de un mes mínimo. A continuación escribimos el formato de entrevista y de observación realizadas a todos nuestros perfiles, y como siguiente apartado anexamos todas las entrevistas realizadas. Al final de este documento de interfaz de usuario se hace una conclusión de los puntos interesantes de cada comunidad que pueden ser aplicables a nuestro portal.

4.5 Informe de los puntos comunes de ambas comunida des

• La mayoría dependen del correo electrónico • En las universidades la jerarquía no tiene tanta importancia como en las ONGs. • Todos disponen de conexión a Internet y de ordenador en sus puestos de

trabajo. La mayoría también tienen ordenador personal. • La mayoría tienen un nivel medio-alto de informática.



61

• Todos a excepción de uno, trabajan en entorno Windows. • Casi todos disponen de más de una cuenta de correo. • Utilizan mucho el teléfono, pero no Skype. • Pocos utilizan videoconferencias o programas como MSN Messenger como

medio de comunicación. • Usan un sw básico. • La mayoría tienen unos puestos de trabajo bien acondicionados y

aproximadamente un 50% disponen de luz natural. • Muchas comunicaciones en inglés y lenguaje claro pero con matices técnicos. • Muchos de ellos tienen colaboradores externos, ya sean voluntarios o

estudiantes en doctorado. • Trabajan mucho en la oficina pero en casa también suelen hacerlo. • Un 50% se desplaza al extranjero para reuniones o trabajos. • Ninguno se ha encontrado con problemas graves de accesibilidad a Internet.

4.6 Informe de los puntos innovadores para nuestro proyecto

• Idea de skype dentro de nuestro portal es muy bien recibida porque así se disminuye el gasto de teléfono por satélite si se aprovecha la conexión a Internet para llamar.

• No se pondría servidor de correo dentro del portal porque es una limitación para los que trabajan en más de un proyecto y ya tiene su cuenta de correo.

• Un indicador dentro del portal para decir que un documento está siendo utilizado a modo de lectura, escritura, etc. Para evitar que personas a la vez lo modifiquen, y se forme un caos.

• Un correo que redireccione a un correo personal existente. • Tener toda la documentación sin restricciones subida al portal Web. Así el

portal ayudaría a tener toda la documentación disponible en cualquier lugar y momento.

• Haya un modelo de formulario común para hacer el presupuesto del coste del proyecto. Para que todos se puedan comparar de la misma forma.

• Todo en inglés y con terminología tecnológica. • Propuesta de cambio de nombre de AREA, a SECCIÓN. Tal y como se llaman

las áreas en las organizaciones no gubernamentales. • El portal debería tener todos los codecs y algoritmos necesarios para hacer las

conversiones inmediatamente de un formato a otro de documentación. • Que aparezcan en el apartado del perfil, las tareas que tiene asignadas, con su

nivel de urgencia.



62

4.7 Entrevistas

4.7.1 Entrevistas en la comunidad universitaria J.I.: Profesor Coordinador UPF. R.T.: Profesor Coordinador UPF. G.P.: Profesora UPF. A.U.: Profesor UPC. X.A.: Alumno de Doctorado. B. P.: Alumno de Doctorado. Adjuntaremos en estas preguntas nuestro perfil de Administrador. C.R.: Administrador de Tyco Electronics AMP España. M.C.: Administrador GrupoConstant. 1.- Definición de tareas desde que se levanta hasta que termina el día. J.I.: Mira el correo, va al baño. Escribe tesis en casa. Tiene dos ordenadores fijos, uno en casa y otro en la universidad. Trabaja con un disco duro portátil que lleva de un sitio a otro. Reuniones. Artículos. No tiene rutina fija. Hace trabajo en la universidad y en casa independientemente. R.T.: Después de desayunar, se desplaza hasta su puesto de trabajo y lee su correo electrónico. Se prepara la clase magistral. Después de las clases, según lo previsto en el correo se dedica a hacer unas tareas u otras. Normalmente trabaja tanto en su despacho pero también lo hace en casa. G.P.: Planificar las clases. Depende de la urgencia se dedica a un proyecto u otro. Una vez vestida mira el correo. Trabaja en casa con el portátil o en la UNI. En la universidad tiene un ordenador fijo, y se pasa la información con USB. Depende de la rutina es cuando trabaja en casa. A.U.: No se le ha hecho esta pregunta. X.A.: Llevar al niño a la guardería. Dar clases en la Pompeu. Preparar las clases para el día siguiente de la Pompeu. Comer. Hacer el doctorado toda la tarde, y toda la noche, porque depende de si su jefe está en otro país y se tiene que comunicar con él a horas insospechadas. Nota: Trabaja con 3 cuentas de correo diferentes (una para upc, otra para upf, y otra personal) por tanto la idea de tener otra cuenta de correo especial para proyectos no le gusta nada. Comenta que lo mejor sería un redireccionamiento del correo para así él filtra los mensajes que le interesan. B.P.: Mira el correo nada mas levantare, desayuna y se va al despacho. Alli pasa todo el dia, sale para comer, y luego en casa si tiene algo urgente lo hace, sino no. C.R.: Se levanta y va al trabajo, allí mira Internet. Y en casa no suele hacer nada de la empresa. M.C.: Normalmente, después de desplazarse hasta la oficina, los pasos que sigue son los siguientes:

• revisión de los backups. • lectura del correo para ver que hay de nuevo.



63

• planificación en función de lo que había de ayer y lo que haya nuevo. • leer el gmail, mirar el barrapunto.com, meneame.net y digg.com • ponerse manos a la obra.

2.- Cuando te dan un proyecto nuevo ¿Cómo lo planteas? ¿Qué guión sigues? J.I.: No hay predefinido, por contacto con él, te dicen el tema/ necesidad. Aprender del tema. Cuanto cuesta. Si hay bases escritas. Te puedes poner en contacto con las empresas. Convocatorias públicas de proyectos (vía e-mail), servicio de recerca de la universidad. Proyectos que nosotros ofrecemos. Surgen proyectos de los foros en los que participan, por ejemplo i2cat. Informan al jefe del departamento (Miquel Oliver); Construyes una propuesta pública formal (un contrato, cómo pagarán, como lo entregamos, etc.) Si no hay bases, tenemos que hacer reuniones y charlas. Formando un equipo. Si aceptas haces una planificación de tiempo y de recursos. Buscar gente. Hacemos reuniones de seguimiento que se reparte el trabajo. El cliente dice cuando se termine el proyecto, y pone las fechas de los hitos. R.T.: Cuando recibe una propuesta de proyecto, nos comenta su forma de actuar, es la siguiente: Lectura de la propuesta análisis de requisitos dudas y sugerencias definición de responsables y tareas reuniones periódicas desarrollo del proyecto. Nos comenta que el planteamiento es muy poco jerárquico, sólo aparenta haber jerarquía en las reuniones formales. G.P.: Le asignan la parte de trabajo que le toca. Se lee muchos artículos sobre el proyecto para documentarse. Luego se documenta técnicamente sobre lo que le asignan, para ver lo que han hecho, o hacen los otros sobre lo que vas a hacer. Así aprovecha al máximo lo que los otros saben. Luego empieza a hacer su parte. Todos los proyectos están financiados por 3 años. Hay cuotas e hitos. A.U.: Intento analizar que se necesita. Analizo si tengo los conocimientos necesarios para afrontarlo. Si no los tengo, busco los colaboradores adecuados. Analizo el balance entre carga de trabajo y recursos económicos / humanos. Hago un plan de trabajo que satisfaga el balance estudiado antes de empezar el proyecto. X.A.: Hay un tiempo de hoja en blanco, dónde se apuntan ideas. Luego lo revisa el jefe, y cuando está todo concretado se hace un plan de trabajo. Cuando ya se tiene hecho el plan de trabajo, se hace un calendario con los objetivos y las fechas. Que a veces no se cumplen, y vienen las protestas por parte del jefe. Si hay un cambio en el proyecto, o se ve que no funciona, se cambia el plan de trabajo y el calendario. Es muy flexible. La investigación no se termina nunca, porque si no se demuestra que no es viable matemáticamente, se sigue investigando y mejorando el proyecto. Se suelen poner objetivos, pero en cuanto los alcanzas, continúas con más ganas hacia otro objetivo. B.P.: Se organiza el tiempo, y la planificación muy bien para cumplir con las fechas y no tener que hacerlo todo en el último momento. Se lo divide por prioridad. C.R.: Anota todo lo que necesita, habla con quien tenga que hablar, y empieza a hacer los trabajos que sean para hacer el proyecto. M.C.: Para empezar me planteo las posibles opciones en plan “brain storming”. Luego hago critica de lo que se me ha ocurrido para ver cual es la mejor opción en base a



64

cosas como si lo podré integrar con otras cosas, complejidad, etc. A partir de ahí se estructura un “guión” a partir del cual se van haciendo las tareas. 3.- ¿Qué rol obtienes dentro de cada proyecto? (Coordinador, jefe, proyectista, investigador…) J.I.: Variable (UNI). Depende de la experiencia. Hacer tareas específicas. Jefe de proyecto. Su experiencia laboral; Telefónica I+D, Retevisión (sistemas de información- jefe de área) e Indra (jefe de grandes proyectos). R.T.: Esta persona nos comenta que su rol es el de jefe de proyecto después de pasar por otras categorías. G.P.: Depende del proyecto tiene un rol. Ahora de responsable de un grupo de investigación. Luego de ser proyectista. Hay jefe y luego paquetes de trabajo. A.U.: Project manager. X.A.: Normalmente le asignan proyectos. También se ha dado el caso en el que pueden solicitar hacer un proyecto a la unión europea. En ese caso se rellena un formulario, y se adjunta un informe de cuatro mil páginas. Normalmente el mismo se asigna las tareas a realizar, se las pasa al jefe para que las revise y si están conformes, empiezan a realizarlas. B.P.: De alumna de doctorado. Le asignan tareas de proyectos, aunque en las reuniones puede aportar ideas. C.R.:Siempre el de administrador de sistemas de la empresa. M.C.: En el curro donde estoy ahora, todos, por que el proyecto lo llevamos entre yo y mi único compañero. 4.- ¿Siempre trabajas en el proyecto en el despacho, o trabajas desde casa, o te desplazas a dónde se tiene que aplicar el proyecto? J.I.: Trabaja en casa y en la universidad. Utiliza el transporte público. Se desplaza a un país, a través de la uni. Depende del proyecto viajas mucho, si es fuera todo fuera, sino es puntual. Es entonces cuando se lleva el ordenador portátil. Sobretodo mirar el correo electrónico. Las imágenes y los audiovisuales depende del país no se verán bien. Utiliza office, más correo electrónico a todos los lados. R.T.: Normalmente lo hace desde la oficina y a veces desde casa. En el caso de que los proyectos se hagan fuera de Barcelona se desplaza a la localidad correspondiente llevando consigo un portátil. G.P.: Puede trabajar tanto en su casa como en la oficina, y cada cierto tiempo se desplaza hacia alguna ciudad de Europa para mantener relaciones con el resto de ‘partners’, sobre la evolución del proyecto. A.U.: Normalmente desde el despacho. En el tipo de proyectos en los que trabajo, se suelen celebrar reuniones en casa de los diferentes partners. Si se tiene que hacer alguna implementación especifica en algún centro, como montar servidores, se suele desplazar el jefe de proyectos (yo) y algún técnico.



65

X.A.: Trabaja siempre desde su portátil, porque trabaja en la UPC, en la UPF y en casa indistintamente. Hace los proyectos desde su portátil sea de dónde sean. Su portátil tiene wireless, y grabadora de dvd. Si tiene que hacer grandes cálculos utiliza el servidor de cálculo de la U. Politécnica de Cataluña. En la UPF le dejan un ordenador comunitario que va lentísimo, se trata de un pentium III. Como profesor de la UPF trabaja siempre a través del campus global. No se ha encontrado nunca limitaciones porque siempre lleva consigo el portátil. B.P.: Siempre en el despacho, aunque puntualmente en casa. Debido a que tiene un buen despacho. C.R.: En la empresa. M.C.: Normalmente el proyecto se implementa en la oficina y voy a la oficina cada día. Si el proyecto tiene que ver con alguna delegación hay que ir. La Web que le estoy haciendo a un italiano la hago desde donde pueda mientras tenga conexión a Internet. 5.- ¿Qué nivel de informática tienes? ¿Tipo de software que utilizas normalmente en los proyectos? Características del equipo informático que utilizas, y de la conexión a Internet (diferentes lugares, distintas conexiones). J.I.: Manager Project. Lector de correo Outlook. Útil para la agenda de contactos, sobretodo para un jefe de proyectos. Word. Power point, excel (software libre). Todos estos programas son para la toma de decisiones, que normalmente la hace el jefe de proyecto. Utiliza en el PC Windows, más el disco duro extraíble. R.T.: Esta persona tiene un nivel de informática alto y normalmente utiliza el siguiente sw: MS Project Paquete de programas Office o sus versiones en sw libre Tanto en su despacho como en casa, nos comenta que tiene un pc de sobremesa y dado sus conocimientos, consideramos que de potentes características. Transporta la información con memoria USB. G.P.: Word. Lenguaje C, Java. No es obligado utilizar programas, sino que lo puedes implementar con el que quieras. E-mail con el outlook. (paquetes específicos de software). Se potencia el software libre. El portátil se lo trae a la universidad a veces. Internet, ADSL wi-fi. En la universidad utiliza cable. A.U.: Nivel informático alto. Utilizamos herramientas corporativas de gestión de proyectos. Son herramientas web basadas en un saap. Dichas herramientas permiten gestionar las horas utilizadas por los diferentes miembros del equipo, los recursos económicos utilizados, etc. Características del equipo informático que utilizamos: Ordenador personal desktop de gama media. Conexión a Internet de alta velocidad >10 Mbps Conexión a algún servidor de pruebas Linux para poder probar futuros sistemas X.A.: Windows, Office (word, Outlook), Visual C, Logia Works, y el correo de la UPF a través de Oracle (que dice que va mal, y lento). En casa utiliza ADSL con router WI-FI de Jazztel. Y en la UPF y UPC con la red corporativa de 10Mbps.



66

B.P.: Muy alto. Trabajo normalmente con linux, y a veces con windows. Los programas con los que trabaja son de software libre. Tiene portatil, y se lo lleva a todos los sitios, tanto a casa, como a la universidad. C.R.: Tiene un nivel de informática altísimo debido a que se encarga de la administración de los sistemas de una empresa de componentes electrónicos. Tienen servidores para trabajar con ellos, y pc de último momento. (no quiere decir nada mas por confidencialidad) M.C.: Nivel master, En cuanto al sw normalmente son estructuras cliente-servidor con bases de datos de por medio. La interfaz últimamente suelo hacerla en Web o sea que el tema acaba siendo lo que se llama plataforma LAMP (Linux, Apache, Misal, PHP) aunque la mayoría de veces uso java en vez de php. Normalmente uso conexiones ADSL. En casa, o en casa de amigos. 6.- ¿Qué medios utilizas para comunicarte con el resto de colaboradores del proyecto? J.I.: Comunicación Base de documentación compartida con todos. Muy importante moodle, blog, sistema de red compartida. Conjunto de directorios compartidos para poderlos compartir con la gente. Wiki para compartirlo todo. Una red compartida para el cliente, y otra para la gente del proyecto. Grupos Mismos de la universidad. Si el proyecto es fuera, el grupo cambia. R.T.: A la hora de comunicarse con otros colaboradores para intercambiar información, nos comenta que utiliza mucho el correo electrónico o herramientas más informales como el MSN Messenger, pero sólo en casos de confianza extrema. Para comunicarse con el personal, normalmente usará el correo pero si se trata de temas delicados utiliza el teléfono. G.P.: PLONE para comunicarse con el grupo de trabajo. Ella primero se identifica con un user y password. Es una especie de blog comunitario, donde se cuelgan las entregas. Y aquí puedes descargar todo el material necesario. No usa teléfono para comunicarse con los de su grupo. E-mail blogs, en persona con los de aquí. Y utiliza skype con una persona de Grecia. Se dicen lo que se tienen que hacer, encuestas, presentaciones de otros grupos en los congresos de todo el proyecto conjunto. A.U.: Teléfono corporativo, Skype, Messenger corporativo (basado en jabber). Reuniones en salas dedicadas, Audio-conferencias con el resto de partners exteriores a la empresa. X.A.: Normalmente con e-mail para los partners de los proyectos. Con algunos utiliza Skype o Messenger. Aunque poco porque o no tienen buen nivel de inglés, o no les gusta chatear prefieren el correo electrónico. Sin embargo él ve muy útil la mensajería instantánea para trabajar. B.P.: Email sobretodo, con todos los que participan en el proyecto. Hay algunas veces que hacemos videoconferencias para aclarar asuntos porque estamos muy separados. C.R.: Por email nos repartimos el trabajo, y se contesta todo por email. El teléfono fijo también lo usamos mucho. M.C.: Cuando son en la oficina, nos hablamos cara a cara por que compartimos despacho. Si no, uso correo electrónico o si cabe la posibilidad mensajería instantánea (google talk, msn o skype).



67

7.- ¿Las personas con las que trabajas están en la misma universidad? ¿Tratas con colaboradores internacionales? J.I.: Tratas con gente de otros países, sobretodo universidad. Todo se hace por e-mail. Todo por email no se puede hacer, hay cosas que se tienen que hacer por teléfono o presencial. El email viene bien para evitar viajes, y la videoconferencia en ocasiones. R.T.: En los proyectos en los que participa ahora sí. En algún proyecto ha mantenido contacto con colaboradores internacionales. G.P.: Cada 3 meses se reúnen en lugares de los partners (Sttugart, Trento, etc.)Se encargan de que haya conexión perfecta en las conferencias. No se ha encontrado ninguna limitación. A.U.: La mayoría de mis colaboradores están en mi mismo edificio. El proyecto cuenta con partners internacionales. X.A.: Todos los que trabajan con él en el proyecto están fuera, por ejemplo en Lisboa, Renhs(Francia), Hannover y Milano. Normalmente todos pertenecen a universidades. Todos se comunican en inglés y debido a que no todos tienen el mismo nivel utilizan mayoritariamente el e-mail. Cada 3 meses hacen una meeting del proyecto en alguna de las universidades, que se combinan con viajes puntuales para investigar y estudiar sobre le proyecto en casa de alguno de los miembros del grupo. Cada año se hacen presentaciones en conferencias sobre el trabajo que vas haciendo. B.P.: No. Están repartidos por el mundo, aunque mayoritariamente, Chile, USA, y Espana. C.R.: Todos en el mismo departamento. M.C.: N/C. 8.- Definición de la jerarquía del departamento. J.I.: Poca jerarquía dentro del grupo. R.T.: En el departamento, nos comenta que prácticamente no existe jerarquía. G.P.: Nos comenta que en su departamento no hay una jerarquía formalizada. A.U.: Gerente, Jefe División, Jefe de proyectos (yo), Ingeniero I+D, Ingenieros, Técnicos (becarios). X.A.: Hay un jefe de proyecto, y los demás están en la misma jerarquía. B.P.: Director, manager, partner, profesores, y doctorados. C.R.: Director, gerente, los trabajadores, y los estudiante en practicas. M.C.: Un jefe, por debajo Dani y por debajo yo. 9.- Definición de la jerarquía a la hora de hacer los proyectos.



68

J.I.: La jerarquía de proyectos casi no existe pero que normalmente trabajan siempre los mismos teniendo colaboradores extranjeros o grupos afines a la UPF, que pueden ir variando. R.T.: Lo mismo nos dice de la jerarquía de proyectos, que casi no existe pero que normalmente trabajan siempre los mismos aunque nos comenta que los doctorados pueden cambiar. G.P.: Depende del proyecto. Departamento de tecnología, hay luego minería de datos, procesado de imagen. Y cada grupo que hace proyectos solicita proyectos al departamento. A.U.: La misma. Es una jerarquía rígida. X.A.: Se formulan jerarquías temporales para cada trabajo en concreto. Depende de los conocimientos, puede ser responsable de un trabajo y reparte las tareas. B.P.: Se mantiene la jerarquia establecida siempre. Aunque en los brainstroming del principio de los proyectos cualquier persona puede ofrecer ideas para las soluciones, en las reuniones no hay jerarquia, pero a la hora de trabajar si. C.R.: En el trabajo esta la jerarquía del departamento. Director, gerente, y los trabajadores. M.C.: Un jefe, por debajo Dani y por debajo yo. 10.- Definición del uso del lenguaje dentro de los proyectos. (Cómo llaman a cada cosa). J.I.: Jerga técnica. Aspectos para entender todos; Costes, presupuestos, plazos. R.T.: Dentro de los proyectos, nos comenta que utiliza la jerga técnica correspondiente al desarrollo de proyectos pero que lo acompaña de un lenguaje sencillo. G.P.: Partners (miembro del equipo de un mismo grupo de investigación, UPF, Philiphs, etc). Todo en inglés. Work-pakage. Project. Deliverables. E-mail. Responsable. A.U.: Castellano e inglés. Partner, Project, Manager, Project Manager. X.A.: El lenguaje es en inglés, y tienen palabras comunes que siempre se nombran y se utilizan en todas las reuniones. Por ejemplo: deriverable, work package, Project, Project manager, Project coordinator, European Union. En cuanto a temas económicos también tienen un lenguaje cotidiano como; budget (presupuesto), Papers, Journal Papers, Conference Papers, Conference, Procedings (artículos que se han presentado en una conferencia), partner. B.P.: En ingles todo. El castellano solamente lo utiliza para comunicarse entre los del mismo despacho, y con personas personalmente. Los emails todos en ingles. Las palabras más usadas: Project, Manager, work package, partner. C.R.: Todo en castellano. Admin, torre, rack, pc, base de datos, netmeeting, virus. M.C.: Por su nombre. Si se desconoce se adjudica uno de mutuo acuerdo.



69

11.- Si has viajado a algún país para hacer un proyecto. ¿Has observado algún tipo de limitación? (conexión Internet, ordenadores, ayudas, taxis, personas) J.I.: No se ha encontrado nada. Echa de menos a su mujer. En la Europa occidental todo funciona bien. R.T.: No. G.P.: Hasta el momento no y nos comenta que en lo referente a la conexión a Internet, siempre se organiza de manera que los participantes en el proyecto pueden disponer de alguna conexión para poder trabajar durante los días en que se lleven a cabo las reuniones internacionales. A.U.: Dificultad a la hora de intercambiar presentaciones… versiones de powerpoint, interconexión de dispositivos USB etc. Falta de herramientas para compartir documentos e ideas. X.A.: Paga todo él en los viajes, y luego se lo paga la UPC ya que el doctorado lo está haciendo allí. Coge taxis sin problemas. Siempre se mira que haya conexión a Internet en todas las conferencias en las universidades dónde se queda. Aunque se ha encontrado que en algún hotel no hay conexión a Internet. Se ha encontrado limitaciones en estados unidos respecto a la moneda, y los controles de las aduanas. B.P.: Si he viajado sobretodo a Sudamerica, y en las ciudades donde he ido no he encontrado problema con Internet. Si hay alguna manifestación algún problema de transporte, sino no. C.R.: No he viajado. M.C.: Estuve en Portugal una vez haciendo una migración y la verdad es que los colaboradores locales dejaban bastante que desear. La tecnología, en general, como aquí. 12.- Fecha de nacimiento, y edad aproximada de tus colaboradores. J.I.: Nació el 11 de octubre de 1963 Cuenca. La gente tiene una media de edad menor que la del jefe de proyecto. Tanto profesores como becarios de doctorado. R.T.: Normalmente trabaja con gente de menor o igual edad que él. G.P.: Edad media 40 años. Hay de todo. A.U.: Entre los 30 y los 50. X.A.: Más o menos la edad ronda los 25-30 años para los doctorados y profesores, y los 40 para arriba para los seniors y jefes de proyecto. Hay una franja de edad delimitada por la profesión; tipo Doctorado – Profesor – Jefe de proyectos. B.P.: Todos los que están en los proyectos con ella hay una gran variedad. Porque los jefes son de 42-47 anos, y los demás de 30 a 40 anos. C.R.: de 30- 45 anos.



70

M.C.: Normalmente siempre han sido mayores que yo. Alrededor de 30 años. 13.- ¿Utilizas becarios para la ejecución de los proyectos? ¿Cómo trabajan? (desde su casa, con su propio ordenador, etc.) J.I.: Depende de lo que haya que hacer, hay veces que no. Profesores y becarios de doctorado, los doctorados tienen una mesa en un despacho, pero los estudiantes no. Trabajan en la zona común con sus portátiles. Mientras se haga el trabajo, da igual dónde lo hagan. Nota: Para hacerle la entrevista muy bien, y para dudas todo lo que queramos, pero para observarle mientras trabaja se siente incómodo. R.T.: Sí, se ayuda de alumnos que hacen doctorados. Trabajan según las tareas asignadas por el responsable. G.P.: Si se puede si, sobretodo becarios. Alumnos de doctorado. Tienen un despacho. Se dan pequeñas tareas que les sirven para la tesis. No aparecen como que están oficialmente en el proyecto, pero colaboran y ayudan. A.U.: Sí. Trabajan en el mismo edificio con un ordenador de características ligeramente inferiores al del resto de empleados. Misma conexión a Internet y capacidades de comunicación. X.A.: Puede tener estudiantes del PFC, y los puede usar para lo que quiera (estos estudiantes no cobran, y no se les puede exigir) Algunos departamentos les dan portátiles, si tienen, y otros no. Hay unas aulas de ordenadores que pueden utilizar los alumnos de proyectos. Suelen trabajar desde casa o desde la universidad. B.P.: De momento no le han dejado contratar o utilizar becarios para ayudarle en los trabajos, pero le encantaría. C.R.: Si, a veces, la empresa ha contratado a estudiantes en practicas, y hacen tareas similares a las del administrador. Es para dar soporte en los puntos de mas trabajo. M.C.: No, pero no le importaría. Guión de la observación 1.- Observar limitaciones del usuario (limitaciones físicas). J.I.: Ninguna. R.T.: Ninguna. G.P.: Ninguna. A.U.: Ninguna. X.A.: Ninguna.



71

2.- Observar todo lo que hace el usuario cuando empieza el proyecto (llama a alguien, toma notas, cualquier cosa) J.I.: Conectar el disco duro. Es adicto a mirar el correo. R.T.: Los pasos serían los siguientes: Desayuna se desplaza a su despacho prepara y da la clase trabaja en el proyecto función de lo indicado en el correo. G.P.: Visita el Web Plone, lee el correo y se informa en revistas, artículos y libros. 3.- Observar el ambiente de trabajo, su despacho, luz, situación de la mesa, del ordenador, si esta limpio y ordenador, si tiene libros y estanterías…) J.I.: Despacho superficial, artificial, sin libros, tres estantes y un PC. Despacho impersonal. Normalmente hay 2 personas en el despacho. Hay visitas de profesores que son de empresa y vienen con sus portátiles y se instalan donde pueden para trabajar. R.T.: En su despacho compartido observamos: 2 mesas Su propio equipo de sobremesa con pantalla plana 1 teléfono 2 estanterías con libros Tiene una luz siempre encendida por lo que le llega poca luz solar G.P.: Comparte despacho con un chico del grupo. Luz artificial, no tienen luz natural y la piden. Tiene una pared acristalada que entra luz de un pasillo también interior. Inglés para técnicos. Móvil con proyectos no utiliza. Imprime los trabajos y hace anotaciones, los subraya. Antes de leerlos en el PC. Todo muy limpio, y PC ordenados. Las estanterías con libros. Documentación la saca de Internet, no va a la biblioteca. Donde saca artículos novedosos, de revistas especializadas. Si fuera preciso libros. La universidad está suscrita a muchas revistas. Reuniones, y se imprime lo enviado por email y se lee. Y se escribe en los márgenes las dudas para luego discutirlas. Diferentes necesidades de comunicación entre universidades. Y de universidad a la ong. Comentarios: E-mail al PLONE no se usa. Para eso está el correo particular que es menos engorroso. Trabajar en un mismo documento tiene que tener un indicado de que alguien lo esta modificando, o leyendo y mientras no se puede hacer nada. Que este documento este en el blog. El responsable integra todas las partes. Trabajar online es importante. Solo se pueden leer los documentos que están en el blog, sino no se puede y cada uno sigue una línea de investigación. Se hacen reuniones para aclarar conceptos. Las reuniones son de 3 tipos: 1 vez /año con todos. 3 veces / año con el work package. Y a menudo con la gente de aquí. Son como congresos, que se fijan objetivos para el siguiente punto. Se hace brainstroming. Es mejor verse 2 días que no hacer una videoconferencia. Los foros son un refuerzo pero es mejor un contacto presencial. Los gastos de los congresos los costea la empresa que financia el proyecto. A.U.: Con luz solar. Despacho amplio y muy ordenado. Las estanterías con libros técnicos. Y papeles archivados. En el teléfono móvil tiene implementado Skype para aprovechar las wireless de Barcelona para llamar por teléfono a través de Internet.



72

X.A.: Tiene un despacho temporal que comparte con diez profesores más por ser alumno de doctorado, y es el tercer despacho que le asignan. Tuvo que poner un cartel en una pared para indicar bien el número de despacho. Por esta razón no utiliza mucho el despacho, solamente para recibir a los alumnos de la Pompeu Fabra y para guardar toda la documentación propia del profesor. La luz que le llega de una amplia ventana es natural y con una planta en medio del tragaluz. A parte también tiene luz artificial de fluorescentes. En el despacho hay 7 ordenadores pentium III viejos. Y no hay sitio para escribir, ni mesas para trabajar. Por esta razón utiliza el ordenador portátil propio. Está todo muy limpio. Para hablar de las cosas comunes y de su trabajo habla en castellano, pero utiliza palabras inglesas para denominar usos del proyecto. Tiene solamente móvil personal, que no está relacionado con el trabajo ni los proyectos. B.P.: Se trata de un despacho con mucha luminosidad solar. Todo esta acristalado, y hay plantas por las esquinas. Es un despacho muy amplio donde hay varias mesas para alumnos de doctorado muy amplias y bastante separas entre si. La mesa esta llena de papeles pero ordenados. Tiene estanterías con libros de su especialidad. Nota: Nos dice que es mucho más rápido el skype o Messenger para entender cosas del proyecto que el e-mail. 4.- Observar el equipo informático, y el material de trabajo que utiliza. J.I.: Fijo. Pantalla plana. Teclado, ratón y caja negros. Todo limpio sin papeles, todo muy ordenado. Se nota que trabaja en casa y que el despacho es de paso. 5.- Fijarse en el lenguaje que utiliza para denominar a las cosas comunes, y no comunes. J.I.: Lenguaje coloquial, lenguaje técnico para el proyecto. Pero entre ellos del grupo hablan de PELAS, para referirse al dinero. 6.- Observar si utiliza más el teléfono móvil, el teléfono fijo o el ordenador para comunicarse. J.I.: No tiene móvil. El e-mail lo responde cuando quiere. En la empresa si utilizó móvil y ahora no quiere ser molestado. Está en 2 proyectos LocalRed con presupuesto. 22@Bcn. Enfrascado. Nos recomienda: inglés, el módem, no hay banda ancha en los pueblos remotos. Francés y Español. R.T.: Nos dice que lo que más utiliza es el correo pero que si se trata de temas delicados puede utilizar Skype, el teléfono.



73

4.7.2 Entrevistas en las organizaciones no gubernam entales T.L.: Responsable de las delegaciones de Aragón, Cataluña e Islas Baleares de Médicos Sin Fronteras. T.M.: Coordinadora de proyectos para Enginyers sense fronteras. D.P.: Coordinador en Enginyers sense fronteras. L.D.: Miembro en Enginyers sense fronteras. E.C.: Miembro en Enginyers sense fronteras. E.G.: Voluntaria de Amnistía Internacional y de Foyer Notre Dame des Sans-Abri R.M.: Voluntario de Medicos sin fronteras. 1.- Definición de tareas desde que se levanta hasta que termina el día. T.L.: Esta persona no tiene unas tareas diarias planificadas dado que realiza muchos viajes entre Aragón, Baleares y Cataluña. Pero a pesar de todo el correo electrónico es lo primero que hace o intenta hacer cada mañana. Los e-mails marcan sus tareas. T.M.: Esta persona lo primero que hace es desayunar, mira las noticias y va hacia la oficina. Una vez allí mira su correo electrónico y la agenda programada para ese día. Su función principal es la de estar actualizado sobre las desgracias que ocurren en el mundo, informar de ello y coordinar algunas de las acciones logísticas. D.P.: Una vez ha desayunado, se desplaza a la oficina, allí consulta su correo y su agenda personal y después se prepara las tareas previstas. L.D.: Antes de ir hacia la oficina consulta su agenda personal (PDA), mira las tareas previstas y en función de ello coge un material u otro. Se desplaza hasta el lugar de tarea, que normalmente es la oficina y allí trabaja en las tareas previstas. E.C.: No le hemos hecho esta pregunta. E.G.: En algún momento del día mira la web para ver la información de la organización, y observa sobretodo si hay algún avance, alguna novedad. Si hay un proyecto nuevo que le interesa entonces se apunta. También mira ofertas de trabajo para trabajar en la organización. (Anmistia internacional) R.M.: Al ser un jubilado, lo que hace durante el día es ayudar a sus hijos con los nietos, llevarlos a la escuela, y recogerlos. Mientras va al casal de la Caixa a ver a sus amigos. Por la tarde es cuando va a Medicos sin fronteras y ayuda como contable. 2.- Cuando te dan un proyecto nuevo ¿Cómo lo planteas? ¿Qué guión sigues? T.L.: Evaluación en el terreno de la necesidad. Bien puede venir la necesidad de los equipos que trabajan en países, o de agencias como la ONU que informan de catástrofes o epidemias, etc. A partir de ahí se hace una exploratoria (a la que se envían 2 ó 3 expertos y experimentados médicos) para evaluar si realmente hay una necesidad y el nivel de urgencia. Si es afirmativa la necesidad se hace una propuesta de proyecto, y vemos si otras organizaciones nos pueden ayudar. Se buscan los recursos necesarios, los equipos, y el presupuesto para realizar dicho proyecto. También hay un momento de búsqueda de recursos propios existentes. Se evalúa el proyecto con un nivel de urgencia y se realiza. Si se trata de una emergencia como el suman, entonces se aplican los protocolos de urgencia, y solamente trabaja la unidad de Emergencias.



74

El resto de departamentos trabaja para dar cobertura y coordinación para todo lo que pasa en la delegación y para el departamento de operaciones que es quien ejecuta los proyectos. T.M.: En cuanto a la coordinación logística lo que hace cuando recibe un proyecto es leerlo y planificar el equipamiento y material necesario para llevar a cabo el proyecto. Una vez decidido lo que hace es enviar la orden para que organicen la partida del material. Dentro de la cadena de proyecto se ubicaría en la tercera acción: Se tiene una necesidad se evalúa sobre el terreno con un pequeño grupo exploratorio de 2 o 3 personas se envía a MSF y se evalúa si la respuesta es positiva se prepara una propuesta de proyecto (personal, presupuesto, operaciones…) En este caso el guión está muy claro, pero en casos de emergencia o desastres naturales todo se realiza casi sin tiempo. D.P.: Una vez recibida la propuesta de proyecto lo primero que hace es leerlo y luego sigue otros pasos como, analizar la información, definir objetivos, plazos de entrega, recursos necesarios y personal necesario. L.D.: Se lee el proyecto, define unos objetivos, unas tareas y asigna un personal a cada tarea. Periódicamente mantiene reuniones con los participantes en el proyecto y si trabaja con colaboradores internacionales, que suele ocurrir una vez cada mes, el coordinador se va turnando entre los países colaboradores. E.C.: Primero se hace un estudio de si se puede realizar el proyecto en la zona. Qué necesidades cubre el proyecto. Y un proyecto se piensa siempre a una temporada larga de trabajo y por tanto se mira qué haya contrapartes en la zona (asociaciones locales que hagan el mismo trabajo que ISF) para ver que recursos se necesitan de verdad. Se ejecutan pruebas pilotos para comenzar a desarrollar un proyecto. E.G.: Normalmente le dan una tarea, y cuando tiene un rato, normalmente el fin de semana la hace, a veces en sus ratos libres. Hay veces le mandan la tarea por correo postal y otras por correo electrónico. La última tarea que ha hecho es transcribir cartas. R.M.: Dentro de la organización se encarga de hacer las tareas de soporte al departamento de contabilidad. Les ayuda en tareas de ordenador, y en ideas que puede aportar por su experiencia de contable. Cuando le dan la tarea, mira como se tiene que hacer, y luego como la puede mejorar. 3.- ¿Qué rol obtienes dentro de cada proyecto? (Coordinador, jefe, proyectista, investigador…) T.L.: Es el jefe de proyectos siempre. T.M.: Para este caso, la persona es responsable de logística. D.P.: Dentro de los proyectos realizados hasta el momento, su rol ha sido jefe de proyectos y luego ya pasó a coordinador de proyectos. L.D.: Dentro de los proyectos realizados hasta el momento, su rol ha sido coordinador de proyectos. E.C.: Responsable del proyecto aunque también se implica a la hora de hacer tareas.



75

E.G.: Para Amnistía internacional es voluntaria, y para Foyer Notre Dame des Sans-Abri fue coordinadora en Lyón organizando un encuentro con niños franceses y niños desalojados, a parte de una exposición con obras de artes que hicieron los niños desalojados (sin comerciar con ello) R.M.: Tiene el rol de ayudante, de ir haciendo las tareas que le mandan. Aunque no le exigen responsabilidades profesionales, el lo hace de una manera muy eficaz. 4.- ¿Siempre trabajas en el proyecto en el despacho, o trabajas desde casa, o te desplazas a dónde se tiene que aplicar el proyecto? T.L.: Suele viajar a otras delegaciones como Zaragoza, Palma de Mallorca. Por esta razón utiliza el portátil con WI-FI, dónde tiene acceso al correo mediante la webmail de MSF, y Lotus notes. Como sistema operativo utiliza el Windows, y el office. Ahora empiezan a utilizar el SAP para cubrir los sistemas de información de finanzas y recursos humanos. T.M.: Normalmente sí, aunque alguna vez lo haga en casa. D.P.: Normalmente hasta la oficina se desplaza mediante transporte público, puede trabajar en casa ocasionalmente y para reuniones con otras organizaciones se desplaza a la ciudad donde vaya a celebrarse el meeting de socios. L.D.: Normalmente trabaja en la oficina, aunque en ocasiones trabaja en casa y para las reuniones con otras organizaciones se desplaza a la ciudad donde vaya a celebrarse el meeting. E.C.: Desde el despacho de la organización, y desde casa. Si está destinada a algún proyecto entonces si que viaja al país, sino lo hace todo desde Barcelona. E.G.: Para Anmistia internacional trabaja desde casa, algunas veces sin ordenador, y otras con. Para Foyer Notre Dame des Sans-Abri trabaja en la sede sin ordenador. R.M.: Siempre trabaja en la mesa que le asignan en la organización dentro del departamento de contabilidad. Tiene un ordenador, un teléfono y todo el material que necesite para llevar a cabo las tareas que le piden. 5.- ¿Qué nivel de informática tienes? ¿Tipo de software que utilizas normalmente en los proyectos? Características del equipo informático que utilizas, y de la conexión a Internet (diferentes lugares, distintas conexiones). T.L.: Nivel medio alto y dispone de un portátil con wifi para realizar sus tareas. Lo que más utiliza es el correo (Lotus Notes) y el Office, todo ello en entorno Windows. T.M.: Nivel medio, dispone de un portátil con wifi para realizar sus tareas en la oficina. En casa tiene un pc de sobremesa y transporta la información con una tarjeta de memoria. Lo que más utiliza es el correo (Lotus Notes), SAP y el Office, todo ello en entorno Windows. D.P.: Tiene un nivel medio-alto, utiliza sw aplicable a entorno Windows, como es el paquete Office y el Acrobat Reader. Tiene un ordenador portátil en la oficina con grabadora, conexión wifi y ADSL de 20Mbps. En casa tiene un pc de sobremesa con conexión ADSL de 1Mbps. L.D.: Tiene un nivel medio, trabaja en entorno Windows con el paquete Office.



76

Tiene un ordenador portátil en la oficina con grabadora, conexión wifi y ADSL de 20Mbps, que es el que se entrega a cada uno de los trabajadores en la ONG. En casa no tiene pc. E.C.: Outlook, Office, Windows. Los equipos informáticos son muy diversos hay desde la última tecnología en portátiles, como en ordenadores fijos, como hay pentium III con pantalla de tubo. Hay conexión a Internet por medio de ADSL que no es WI-FI. E.G.: Tiene un nivel de informática bastante alto. Si trabaja con el ordenador trabaja con Word, y con un programa de fotografías. Sino trabaja sin ordenador. R.M.: Tiene un nivel de informática básico, pero se apunta a cursos de informática que da los casales de la Caixa. Trabaja en la organización con un ordenador fijo, con windows. La conexión es WI-FI. 6.- ¿Qué medios utilizas para comunicarte con el resto de colaboradores del proyecto? T.L.: Normalmente se comunican por correo electrónico, porque así pueden mandar documentos. A parte tiene móvil de Médicos sin fronteras. T.M.: Lo que más utiliza en su trabajo diario es el correo y el teléfono. D.P.: La mayoría de las veces utiliza el correo electrónico pero también realiza reuniones periódicas con los colaboradores. L.D.: La mayoría de las veces utiliza el correo electrónico pero también realiza conversaciones telefónicas con colaboradores externos. E.C.: Se comunican por correo electrónico, y por teléfono. E.G.: Utiliza normalmente el teléfono, las cartas de correo postal, y el correo electrónico. R.M.: Se comunica a través del correo electrónico, y en persona. Ya que no sale de la organización. 7.- ¿Las personas con las que trabajas están en la misma universidad? ¿Tratas con colaboradores internacionales? T.L.: Con las personas con las que trabaja son de fuera el 90%, y el resto de Barcelona. También se trabaja con grupos de apoyo de otras organizaciones, y se crean equipos de trabajo. T.M.: La mayoría de las personas con las que trabaja se encuentran en la sede central aunque también se comunica con los trabajadores enviados y con los responsables de los almacenes. D.P.: Normalmente sí pero en alguna ocasión mantiene contactos con coordinadores de sedes de otros países. L.D.: Sí aunque también mantiene reuniones con coordinadores de sedes de otros países. E.C.: Se trabaja tanto con personas de otras organizaciones, como con universitarios de distintas universidades, como con voluntarios. Las organizaciones pueden ser del



77

país dónde vamos a hacer los proyectos, como de aquí. Camerún, Argentina, El Salvador, Etiopía. E.G.: Trata con colaboradores internacionales depende de donde este, si esta en Canadá trabaja con personas de Francia, o de España. También con personas que están en el mismo lugar que ella. R.M.: Suele trabajar, como voluntario, solamente con las personas que están dentro del edificio de la organización. Al estar en el departamento de contabilidad nunca ha tenido que contactar con personas de fuera del país, a veces si con personas de otras delegaciones españolas. 8.- Definición de la jerarquía del departamento. T.L.: Se rige por una jerarquía muy fuerte y sujeta por protocolos de funcionamiento. Hay flexibilidad solamente en momentos distendidos que puedes hablar con otros cargos, pero a la hora de trabajar se rige por una jerarquía fija, ya que es la forma de funcionar perfectamente. T.M.: Se define como el de una empresa, con distintos departamentos y varios responsables dirigidos por un responsable de sede. Todo está muy organizado y profesionalizado. D.P.: Su estructura es similar a la de una empresa, con sus distintos departamentos. L.D.: Su estructura es similar a la de una empresa, con sus distintos departamentos y su responsable de sede. E.C.: Hay un responsable de departamento, y los demás trabajadores. A parte de las aportaciones temporales y puntuales de los voluntarios. E.G.: Los voluntarios entre si no se conocen la gran mayoría, y tampoco la jerarquía de como trabajan desde arriba. Porque las tareas o actividades te las mandan por correo postal o electrónico. En Foyer Notre Dame des Sans-Abri la jerarquía estaba compuesta por una directora del centro que era psicóloga, 3 psicólogos a su cargo, y dos estudiantes. R.M.: Dentro del departamento de contabilidad hay un jefe de todo el departamento, dos gerentes, y 5 trabajadores. A parte de los voluntarios que son 3. 9.- Definición de la jerarquía a la hora de hacer los proyectos. T.L.: Como hemos explicado antes al tener un guión de proyecto muy claro, cada uno sabe donde se ubica. T.M.: Como hemos explicado antes al tener un guión de proyecto muy claro, cada uno sabe donde se ubica. D.P.: A la hora de la realización de proyectos, después de haber estudiado el caso y definido las tareas, la jerarquía está muy clara y cada uno conoce su función en la realización del proyecto (Coordinador, responsable, voluntario, proyectista…) L.D.: Nos comenta que la jerarquía en un proyecto, a pesar de estar muy clara y cada uno saber donde ubicarse, tiene un perfil bastante llano.



78

E.C.: Hay un responsable para cada proyecto, que se elige entre los miembros del departamento de proyectos. Y los estudiantes, los voluntarios, y el personal contratado se encargan de hacer las tareas que reparte el responsable. E.G.: Es la misma respuesta que la anterior. R.M.: Siempre es la misma. 10.- Definición del uso del lenguaje dentro de los proyectos. (Cómo llaman a cada cosa). T.L.: Jerga especializada en medicina. Lenguaje de nomenclaturas específicas de los departamentos REUCO (celda de operaciones). Se habla en castellano y en inglés. Por ejemplo él depende del departamento de operaciones, como todo MSF. Existe una unidad de seguimiento para el nivel de urgencia, y así tener previsiones de alertas y necesidades. Si existe una alerta en 24horas se consigue llegar hasta el lugar. Se evalúa y se mira si con la sección española se cubre la necesidad. T.M.: Utilizan jerga específica, acrónimos ( reuco o teluco ) y suelen comunicarse en castellano o en inglés. D.P: Tienen una jerga técnica común en los proyectos, pero normalmente se comunican con un lenguaje plano, sencillo y en varios idiomas, castellano, catalán e inglés. L.D.: Tienen una jerga técnica común en los proyectos, pero normalmente se comunican con un lenguaje sencillo y en castellano e inglés. E.C.: Sectores, planificación, programas, contraparte, proyecto, responsable, incidencias (que es la sensibilización de la sociedad). Su idioma es el castellano porque trabajan mucho con Sudamérica, y puntualmente el inglés. E.G.: Se habla en distintas lenguas, Árabe, Francés, Ingles, Español. Y las palabras que más suelen utilizar son: Proyecto, actividad, tarea, tema o nombre del proyecto (exposición, cartas, encuentro). R.M.: Se habla en castellano para denominar los trabajos que se hacen para dentro de la organización, y se habla en ingles a veces para referirse a asuntos externos. 11.- Si has viajado a algún país para hacer un proyecto. ¿Has observado algún tipo de limitación? (conexión Internet, ordenadores, ayudas, taxis, personas) T.L.: Nos comenta la principal, falta de cobertura para móvil. Tienen que hacer conexiones vía satélite. T.M.: No, dado que su perfil no exige desplazamientos. D.P.: Hasta ahora no se ha encontrado con ninguna limitación. L.D.: En ocasiones se encuentra que no dispone de cobertura para el móvil o la conexión a Internet no ofrece mucha velocidad. E.C.: En los países dónde trabaja ingenieros sin fronteras no hay agua, ni electricidad. Se vive con los mínimos recursos para hacer el proyecto. Pero ya se sabe a lo que se



79

va. Por eso las limitaciones están asumidas. Para comunicarnos utilizamos la telefonía por satélite. Se suele trabajar con asociaciones que están en los países de trabajo. E.G.: Siempre trabaja como voluntaria desde su ciudad, pero si le dijeran de viajar a otro país lo aria. R.M.: Como voluntario no ha viajado a otro pais. Los que viajan de Medicos sin fronteras son contratados. 12.- Fecha de nacimiento, y edad aproximada de tus colaboradores. T.L.: La media es de 30 - 35 años con puntas de más jóvenes y más mayores. T.M.: Rondan los 30. D.P.: La media de sus colaboradores es alrededor de los 30 años. L.D.: La media de sus colaboradores es alrededor de los 30 años. E.C.: Los trabajadores de ESF es bastante joven, una media de 30 años. La mayoría son personas que han terminado la carrera hace poco tiempo. E.G.: Normalmente se trabaja con personas jóvenes de la misma edad entre 25-30 anos. La responsable del centro, o de los proyectos suelen tener una media de 45 anos. R.M.: Las personas contratadas son jóvenes de unos 30 anos, pero los voluntarios van desde jubilados, hasta estudiantes muy jóvenes. 13.- ¿Utilizas becarios para la ejecución de los proyectos? ¿Cómo trabajan? (desde su casa, con su propio ordenador, etc.) T.L.: Las personas trabajan cobrando y se llaman expropiados los que van a los países a trabajar. Suelen cobrar un año sobre el terreno, tienen una responsabilidad de profesional, con seguridad social y seguro. Los voluntarios están en las sedes o en las delegaciones. Apoyan a las delegaciones y no cobran, por tanto no se les exige una responsabilidad. Todos los voluntarios tienen un puesto de trabajo, con mesas, ordenadores, teléfono, aunque a veces compartan alguno. T.M.: No, utiliza voluntarios para la organización del material. D.P.: En los proyectos colaboran voluntarios que ofrecen ayuda en cualquiera de los niveles de la jerarquía. L.D.: En los proyectos colaboran voluntarios que ofrecen ayuda en cualquiera de los niveles de la jerarquía. E.C.: Los voluntarios son estudiantes de ingeniería que trabajan gratuitamente para la organización. Tienen que trabajar desde casa en sus propios ordenadores, y si fuera el caso compartir mesa temporalmente con algún miembro de la organización. Se aprovechan los proyectos fines de carrera que hacen los estudiantes para obtener nuevos recursos y necesidades para luego aplicarlos a los países que lo necesitan. E.G.: Si necesita ayuda se la pide a amigos suyos que hacen las tareas desde su casa y con sus propios medios.



80

R.M.: Para realizar el trabajo de voluntario, solamente soy yo. Aunque a veces otros voluntarios nos ayudamos mutuamente. Guión de la observación (Los voluntarios no los hemos observado en su lugar de trabajo sino que hemos hecho la entrevista en una cafetería) 1.- Observar limitaciones del usuario (limitaciones físicas). T.L.: Marcas de quemaduras en el brazo izquierdo. 2.- Observar todo lo que hace el usuario cuando empieza el proyecto (llama a alguien, toma notas, cualquier cosa) T.L.: Usan el guión explicado anteriormente. T.M: Lo definido en la segunda pregunta de la entrevista. D.P.: Lectura de la documentación análisis de la información definición de objetivos definición de tareas asignación de tareas Reuniones periódicas para control de la evolución del proyecto. L.D.: Lectura de la documentación definición de objetivos definición de tareas asignación de tareas Reuniones periódicas para control del proyecto, pueden ser reuniones con personal internacional o de la misma sede. 3.- Observar el ambiente de trabajo, su despacho, luz, situación de la mesa, del ordenador, si esta limpio y ordenador, si tiene libros y estanterías…) T.L.: Despacho ordenado, con mesa y con ordenador. Hay otros despachos que tienen ordenadores fijos, pero la mayoría son portátiles. Edificio muy luminoso con luz solar, con claraboyas. Todos los espacios dan a un patio de trabajo, con balcones que son oficinas todo con cristales y da una sensación de pureza, luminosidad y belleza increíbles. Todo está en silencio y hay un buen ambiente de trabajo. Las salas de reuniones también son con cristales transparentes. Cuando trabajan fuera de España en países con problemas se comunican a través de teléfono por satélite, o por internet por satélite. No hacen muchas llamadas para economizar. Los ordenadores y el mobiliario es todo nuevo, y las estanterías están todas muy ordenadas. La persona a la que hemos entrevistado tenía una quemadura considerable en el brazo izquierdo. Y varios médicos que nos hemos encontrado durante la visita tenían cicatrices profundas. T.M: Amplia sala con mesas grandes, con espacio para ordenadores (portátil o de sobremesa) y para escribir. Ventana amplia por donde entra bastante luz natural. D.P.: Despacho de tamaño medio, con una mesa amplia con sitio para portátil, impresora y sitio para escribir. Recibe bastante luz solar.



81

Tiene una estantería con abundante documentación sobre los proyectos desarrollados o en desarrollo. L.D.: Despacho de tamaño medio, con una mesa amplia para portátil e impresora. Poca luz solar. Tiene una estantería con abundante documentación sobre los proyectos desarrollados o en desarrollo. E.C.: Se trata de un piso sin arreglar bastante antiguo, dónde todas las habitaciones transformadas en despachos desembocan en una habitación central dónde está el recibidor, que son los responsables de administración y de comunicación de la organización. El mobiliario es viejo, y más o menos se puede decir que está ordenado. Tienen un montón de papeles y archivadores repartidos por todas las mesas y estanterías. Tienen problemas con el teléfono y hasta hace dos días no pudimos contactar con ellos vía telefónica. La luz con la que trabajan es luz natural ya que todo el piso es exterior. La pintura de las paredes y de las puertas está gastada. En el suelo hay una moqueta vieja. Los ordenadores con los que trabajan el 75% son viejos, y funcionan lentamente. Viven fundamentalmente de subvenciones del estado, y de otras organizaciones. 4.- Observar el equipo informático, y el material de trabajo que utiliza. T.L.: Portátil HP de 2 años de antigüedad. Básicamente ese es su material, además de fotocopiadora e impresora. T.M: Portátil HP de 2 años de antigüedad. Es el ordenador que tienen por defecto todos los trabajadores. D.P.: Se ha comentado en preguntas anteriores. L.D.: Se ha comentado en preguntas anteriores. 5.- Fijarse en el lenguaje que utiliza para denominar a las cosas comunes, y no comunes. T.L.: Lo que se refleja en la entrevista. T.M: Lo que se refleja en la entrevista. D.P.: También se ha tratado en apartados anteriores. L.D.: También se ha tratado en apartados anteriores. 6.- Observar si utiliza más el teléfono móvil, el teléfono fijo o el ordenador para comunicarse. T.L.: Lo que más, para trabajar, el correo electrónico. T.M: Lo que más, para trabajar, el teléfono, Internet y SAP para realizar los encargos.



82

D.P.: Sobre todo usa el correo pero también utiliza el teléfono para conversaciones críticas. L.D.: Sobre todo usa el correo pero también utiliza el teléfono para conversaciones críticas.

4.7.3 Entrevistas externas J.R.: Usuario externo trabajador en prácticas de Hewlett Packard Spain. E.S.: Usuario externo trabajador de Laboratorios Anabiol. 1.- Definición de tareas desde que se levanta hasta que termina el día. J.R.: Por la mañana cuando se levanta mira el correo, los periódicos deportivos en internet, y utiliza internet para buscar información que le piden en el trabajo. También se baja trabajos de la universidad, descarga películas, música, juegos. Mira internet por la mañana y por la noche mas tiempo que en otra parte del día. E.S.: Algunas veces me conecto al mediodía para ver la prensa y el correo electrónico, y luego a última hora de la tarde miro el correo, busco trabajo, y después miro cosas lúdicas como youtube. 2.- ¿Siempre te conectas cuando trabajas, o desde casa? J.R.: En el trabajo, en casa y en la universidad. Pero con más frecuencia y tiempo en casa. E.S.: Al mediodía desde el trabajo, y por la tarde desde casa. 3- ¿Qué nivel de informática tienes? ¿Tipo de software que utilizas normalmente en las actividades? Características del equipo informático que utilizas, y de la conexión a Internet (diferentes lugares, distintas conexiones). J.R.: Tiene un nivel medio de informática. Programa en C++, Office, Bases de datos en el trabajo. Sistema operativo Windows, Explorer, mozilla. Utiliza bastante el messenger, software para visionar videos y el photoshop para retocar fotografías. Tiene un ordenador de unos cinco anos de antigüedad, con ADSL a 1 MB de Telefónica. E.S.: Tiene e nivel de informática “el justo para sobrevivir”. Windows, Word, Explorer. Tiene un pentium IV nuevo con pantalla plana, con impresora y altavoces muy bien colocados dónde puede ver películas. 4.- ¿Qué medios utilizas para comunicarte con el resto de las personas? J.R.: Se comunica a menudo por teléfono móvil, luego por messenger y por e-mail poco. E.S.: Habitualmente correo electrónico, y ocasionalmente el Messenger. Y el teléfono móvil normalmente.



83

5.- ¿Las personas con las que te comunicas están en tu misma ciudad? ¿Tratas con personas internacionales? J.R.: Los compañeros con los que establece comunicación son todos de España, de su propia ciudad la mayoría, salvo excepciones de amigos o parientes que viven fuera de la ciudad. (Almería, Sevilla, Asturias) E.S.: Algunas están en la misma ciudad, pero la gran mayoría estáis desperdigados por España. No se relaciona con personas que viven fuera de España. 6.- Definición del uso del lenguaje dentro del entorno de internet. (Cómo llaman a cada cosa). J.R.: Utiliza el uso común de internet como por ejemplo: Web, Mail, Messenger, Iconos, Descargar, Anime (series manga), Virus, Troyanos, Pop-ups, Música. E.S.: Meil, Yutub, correo electrónico, messenger, páginas web, enlace, link, bajar, subir. 7.- Si has viajado a algún país para hacer alguna actividad. ¿Has observado algún tipo de limitación? (conexión Internet, ordenadores, ayudas, taxis, personas) J.R.: Cuando ha viajado nunca se ha conectado a internet. E.S.: Nunca se ha conectado a internet fuera del país. 8.- Fecha de nacimiento, y edad aproximada de las personas con las que contactas por internet.. J.R.: Misma edad que el de media, sobre unos 23 anos. E.S.: La media de edad es de 27 años.



84

5. Seguridad

5.1 Objetivos del entregable En el primer entregable nos encargamos de analizar las principales vulnerabilidades de nuestro sistema y especificar unos requerimientos para nuestro sistema. A partir de aquí, como vimos en el anterior documento (entrega dos), pudimos definir una serie de tecnologías que podrían ser utilizadas para cumplir con los requerimientos especificados. Es en este entregable donde debemos especificar cuales son las tecnologías que utilizaremos en nuestro sistema y por que hemos elegido esa tecnología y no otra de las que cumplían con los requerimientos. Además definiremos las características necesarias para implementar la seguridad en nuestro sistema de las tecnologías escogidas.

Tabla 2. Requisitos de seguridad

5.2 Definición de los conceptos utilizados en este entregable

5.2.1 Comunicación segura Nos referimos con que el sistema cumple con todos los servicios de seguridad disponibles, como son autentificación, confidencialidad, no repudio del mensaje, integridad, y control de acceso.

5.2.2 PKI (Public Key Infraestructure) Una PKI incluye una o varias autoridades de registro para certificar la identidad de los usuarios, una o varias autoridades de certificación que emitan los certificados de clave pública; un repositorio de certificados, accesible vía Web u otro medio, donde se almacenen los certificados; las listas de revocación de certificados (CRL), donde se listan los certificados suspendidos o revocados; y, por supuesto, los propios certificados.

5.2.3 Kerberos Como sabemos kerberos no solamente provee autenticación de usuario y servidor, sino que también controla el acceso a el servidor a usuarios que sean legítimos y que tengan autorización para acceder a cierta información.



85

Figura 35. Arquitectura Kerberos.

Como vemos en el dibujo una vez que se ha producido la autenticación el cliente puede enviar al servidor una solicitud con el ticket correspondiente, será entonces cuando el servidor final verificará que el ticket corresponde a ese usuario, y que ese usuario es realmente quien dice ser, si todo funciona de manera correcta, el usuario tendrá acceso a los servicios del servidor.

5.2.4 Detección de intrusos La detección de intrusos se puede realizar a partir de la caracterización anómala del comportamiento y del uso que hacen de los recursos del sistema. Este tipo de detección pretende cuantificar el comportamiento normal de un usuario. Para una correcta distinción hay que tener en cuenta las tres distintas posibilidades que existen en un ataque, atendiendo a quién es el que lo lleva a cabo:

• Penetración externa. Que se define como la intrusión que se lleva a cabo a partir un usuario o un sistema de computadores no autorizado desde otra red.

• Penetraciones internas. Son aquellas que se llevan a cabo por usuarios internos que no están autorizados al acceso.

• Abuso de recursos. Se define como el abuso que un usuario lleva a cabo sobre unos datos o recursos de un sistema al que está autorizado su acceso.

La idea central de este tipo de detección es el hecho de que la actividad intrusiva es un subconjunto de las actividades anómalas aunque idealmente el conjunto de actividades anómalas es el mismo conjunto de actividades intrusivas, de todas formas esto no siempre es así:

• Intrusivas pero no anómalas. Se les denomina falsos negativos y en este caso la actividad es intrusiva pero como no es anómala no se consigue detectarla. Se denominan falsos negativos porque el sistema erróneamente indica ausencia de intrusión.

• No intrusivas pero anómalas. Se denominan falsos positivos y en este caso la actividad es no intrusiva, pero como es anómala el sistema decide que es intrusiva. Se denominan falsos positivos, porque el sistema erróneamente indica la existencia de intrusión.

• Ni intrusiva ni anómala. Son negativos verdaderos, la actividad es no intrusiva y se indica como tal.

• Intrusiva y anómala. Se denominan positivos verdaderos, la actividad es intrusiva y es detectada.

Los primeros no son deseables, porque dan una falsa sensación de seguridad del sistema y el intruso en este caso puede operar libremente en el sistema. Los falsos



86

positivos se deben de minimizar, en caso contrario lo que puede pasar es que se ignoren los avisos del sistema de seguridad, incluso cuando sean acertados. Los detectores de intrusiones anómalas requieren mucho gasto computacional, porque se siguen normalmente varias métricas para determinar cuánto se aleja el usuario de lo que se considera comportamiento normal.

5.2.5 Identificación y autentificación de usuarios y servidores Es un servicio de autenticación desarrollado por el Proyecto Athena del MIT. Se basa en un entorno distribuido en el cual los usuarios y sus workstations desean acceder a servicios y servidores distribuidos a través de una red. Dónde los servidores restringen el acceso a usuarios autorizados y puede autenticar peticiones de servicios. La autentificación que utiliza Kerberos se basa en la verificación de los identificadores de las entradas a nuestra red del portal. Por tanto Kerberos utiliza passwords de usuarios para verificar su identificación, estos passwords se mandan encriptados a través de la red.

5.2.6 3DES simétrico Como hemos podido observar en los requerimientos de nuestro sistema, es necesario que el router de nuestro sistema encripte la información con el fin de que esta no pueda ser fácilmente legible o modificada, evidentemente existen muchos algoritmos de encriptación, los algoritmo más utilizados son DES, 3DES, y AES la mayoría de los router que ofrecen encriptación son capaces de encriptar con estos algoritmos, por lo que tendremos que decidir qué algoritmo utilizamos.

• 3DES: Es un algoritmo de cifrado de bloques implementado a partir de DES, básicamente realiza las mismas operaciones que DES pero lo hace 3 veces y con claves distintas de manera que mejora las características de DES. Poco a poco este algoritmo esta siendo menos utilizado ya que no se considera totalmente seguro.

• AES: Hasta el momento es uno de los algoritmos de cifrado de bloques más seguros. AES tiene un tamaño de bloque fijo de 128 bits y con tamaños de clave de 128, 192 o 256 bits. Las transformaciones se realizan sobre una matriz de estado, una matriz 4x4, los coeficientes de la cual son bytes.

5.2.7 Comunicación administrador y servidores RSA Es evidente que dentro de nuestro sistema también puede haber intrusiones por lo que la comunicación entre el administrador y los servidores debe ser totalmente segura. Además el servidor debe comprobar que a información que recibe ha sido creada por el administrador, y viceversa el administrador debe saber que la Información que recibe es realmente de los servidores. Por eso es necesario utilizar un algoritmo de clave asimétrica como RSA. La generación de claves de RSA se produce de la siguiente manera, (ejemplo).

• Se seleccionan dos números primos, p=7, y q=17. • Se calcula el parámetro n=pxq=7x17=119 • Se calcula φ(n)=(p-1) (q-1)=96

• Seleccione un entero positivo e tal que el tales que e y φ(n) sean primos entre si. En nuestro ejemplo e=5.

• Encontrar d tal que de=1mod 96 y d<96. Para nuestro ejemplo d =77, ya que 77x5=385=4x96+1



87

Las claves resultantes son:

• KU={e,n}={5,119} • KR={d,n}={77,119}

Encriptación Plaintext: M<n Ciphertext: C=Me (mod n) Desencriptación Plaintext C Ciphertext: M=Cd (mod n)

Como podemos pensar también es importante definir el tamaño de n, de manera que nuestro sistema sea seguro.

5.2.8 Encriptación Base de datos Uno de los aspectos importantes a la hora de almacenar los passwords en la base de datos es utilizar un algoritmo MAC para poder mantenerlos de manera segura en la base de datos, para el almacenamiento de los passwords se ha decidido hacer mediante un algoritmo HMAC. HMAC es un mecanismo para la autenticación de mensajes mediante funciones criptográficas de "hash". HMAC puede utilizarse con cualquier función criptográfica de hash iterativa; por ejemplo, MD5, SHA-1, junto con una clave secreta compartida. La capacidad criptográfica de HMAC depende de las propiedades de la función de hash definida

Donde: h, es la función de hash K, es un clave secreta añadida con una cantidad de 0’s extras m, es el mensaje a autenticar opad=0x5c5c5c5c5c5c…5c5c5c ipad=0x363636363636…363636

5.2.9 HTTPS El protocolo seguro de transferencia de hipertexto (S-HTTP, Secure HyperText Transfer Protocol) es el protocolo usado para transacciones seguras en la Web.



88

HTTPS provee una variedad amplia de mecanismos para tener prevista confidencialidad, autenticación, e integridad. El sistema HTTPS utiliza un cifrado basado en las Secure Socket Layers (SSL) para crear un canal cifrado (cuyo nivel de cifrado depende del servidor remoto y del navegador utilizado por el cliente) más apropiado para el tráfico de información sensible que el protocolo HTTP. A diferencia de HTTP, HTTPS trabaja por defecto por el puerto 443 TCP, y antes de enviar los datos realiza algunas acciones previas.

• Para hacer esta negociación, el cliente, envía al servidor las opciones de cifrado, compresión y versión de SSL junto con algunos bytes aleatorios llamados Challenge de Cliente.

• El servidor, escoge las opciones de cifrado, compresión y versión de SSL entre las que ha ofertado el cliente y le envía su decisión y su certificado.

• Ambos negocian la clave secreta llamada master secret y usando esta clave, la Challenge de Cliente y las opciones pactadas se envían la información encriptada de tal manera que de ser interceptada no se puede descifrar.

5.3 Criterios utilizados para la especificación de las tecnologías Utilizamos como criterio que las comunicaciones sean lo más seguras posibles. Si tenemos que elegir entre tecnologías y algoritmos, escogeremos la más robusta, y los sistemas más impenetrables. Como comunicación segura nos referimos que el sistema cumple con todos los servicios de seguridad disponibles, como son autentificación, confidencialidad, no repudio del mensaje, integridad, y control de acceso.

5.3.1 Justificación del uso PKI en gestión de clave s En nuestro portal y en nuestra definición de la infraestructura vamos a utilizar PKI como base para nuestra gestión de las claves, porque es la infraestructura en la que se basa la utilización de claves públicas para el cifrado de mensajes entre dos sistemas. Como vamos a trabajar con sistemas que no conocemos, como son el caso de los ordenadores de las organizaciones no gubernamentales y de las distintas universidades tenemos que garantizar que dos certificados generados por dos sistemas desarrollados por AC (autoridad de certificación) distintas sean mutuamente compatibles, para así verificar con éxito las cadenas de certificación y que no se invalide todo el esquema de PKI. En nuestro caso que nos basamos en Internet, PKI es de uso obligado. Porque es la única forma conocida actualmente de prestar confianza a los actores de las relaciones telemáticas que no se conocen entre ellos, tanto entre organizaciones, entre universidades distintas, como entre las universidades y organizaciones que serán todas de forma nacional e internacional por Internet. La confianza en un grupo de AC (autoridad de certificación) como VeriSign, SCS o como Camerfirma, ipsCA, FNMT, ACE o FESTE en España que hace que las entidades involucradas puedan fiarse unas de otras, a pesar de no existir contacto físico ni vínculo previo entre las partes. SSL es el estándar que funciona con éxito junto las tecnologías de clave pública en escenarios de seguridad descentralizados como Internet, que es nuestro caso.



89

5.3.2 Justificación del uso Kerberos para el Contro l de Acceso Una de las características más importantes a la hora de elegir kerberos en nuestro sistema es la unificación del cumplimiento de diversos requerimientos que teníamos definidos. Por lo que podemos, como hemos dicho antes, autenticar servidor y usuario y además controlar el acceso al servidor a los usuarios correspondientes.

5.3.3 Justificación de Detección de intrusos Dado que hoy día existen una gran cantidad de mecanismos y de conocimientos de intrusión consideramos que es necesaria la utilización de un SDI (Sistemas de Detección de Intrusos) en nuestra sede, ya que esto nos ayudará a evitar problemas como instalar un sniffer, troyanos, leer mails ajenos, etc. Y en caso de ser un pirata malicioso puede causar desastres en el sistema, como sería modificar páginas Web, borrar archivos o mails, producir un DoS (Denial of Service), cambiar passwords de usuarios legítimos, etc. Esto lo evitaremos gracias a que estos sistemas basan su funcionamiento en la recolección y análisis de información de diferentes fuentes, que luego utilizan para determinar la posible existencia de un ataque o penetración de intrusos. En caso de que exista la suficiente certeza de la detección de un incidente, el SDI alertará al administrador o personal de seguridad, para que tome acciones al respecto. Otras implementaciones más complejas son capaces de ir más allá de la notificación de un posible ataque, es decir pueden ejecutar acciones automáticas que impidan el desarrollo de éste. Los SDI pueden clasificarse en base a varios aspectos:

• Método de detección • Tipo de monitoreo y forma de recolección • Análisis de la información

Según el método de detección, los hay de detección de mal uso y detección de anomalías. El modelo de detección de mal uso consiste en observar cualquier proceso que intente explotar los puntos débiles de un sistema en específico. Una ventaja de este método es que permite centralizar las labores de detección en el conjunto de firmas que posee el SDI, minimizando así, la carga de procesamiento del sistema. Muchos productos comerciales utilizan este enfoque e inclusive periódicamente proporcionan actualizaciones de éstas firmas. Consideramos que este modelo de detección se adapta a nuestras necesidades ya que no nos cargará el sistema y podremos ofrecer toda la calidad a nuestros usuarios, sobre todo en aspectos del servidor de vídeo o en la VoIP. En cambio, el modelo de detección de anomalías se basa en constantemente monitorear el sistema para así detectar cualquier cambio en los patrones de utilización o el comportamiento del mismo. Si algunos de los parámetros monitoreados sale de su regularidad, el sistema generará una alarma que avisará al administrador de la red sobre la detección de una anomalía. Este tipo de detección es bastante compleja, debido a que la cuantificación de los parámetros a observar no es sencilla y a raíz de esto, se pueden presentar los siguientes inconvenientes:

• Pueden generarse falsas alarmas si el ambiente cambia repentinamente, por ejemplo, cambio en el horario de trabajo.

• Un atacante puede ir cambiando lentamente su comportamiento para así engañar al sistema.



90

Según el tipo de monitoreo, hay SDI con detección orientada al host o detección orientada a la red. El modelo orientado al host se basa en el monitoreo y análisis de información, que refleja el estado del host donde éste reside. La mayoría de la información que este tipo de sistema recopila es obtenida a través del sistema operativo del host. Esto último causa complicaciones debido a que la información que se procesa no contiene registros del comportamiento, de bajo nivel, de la red. Los SDI que utilizan el modelo orientado a red, fundamentan su monitoreo en información recolectada de la red. Generalmente, ésta información es capturada mediante mecanismos de "sniffing" que consiste en habilitar la interfaz de red en modo promiscuo para que así capture todos los paquetes que reciba, incluso aquellos que no le han sido destinados. En base a este mecanismo, se pueden definir patrones o firmas de ataques, según la estructura, información y ocurrencia de los paquetes. Por ello, creemos que nuestro SDI debe monitorear en este modo ya que así podremos tener identificados los distintos perfiles de usuarios, lo cual nos puede servir de ayuda para detectar otras intrusiones.

Consideramos que nuestro SDI debe cumplir los requisitos siguientes:

• Debe ejecutarse continuamente sin intervención o supervisión de un operador humano.

• Debe ser confiable, lo suficiente como para ejecutarse en background, pero no debe ser una caja negra, es decir, que su funcionamiento interno pueda ser examinado.

• Debe ser capaz de tolerar fallas, en el sentido de que pueda sobrevivir a una caída del sistema, sin tener que reconstruir su base de datos de conocimientos al reiniciarse.

• El sistema debe tener capacidad de auto monitorearse para asegurar su correcto funcionamiento.

• Debe ser ligero, es decir su ejecución no debe cargar al sistema de una manera tal que le impida ejecutar otras tareas con relativa normalidad

• Debe observar desviaciones del comportamiento estándar. • Debe poder adaptarse al comportamiento cambiante del sistema, es decir, si la

configuración del sistema cambia, el SDI se adaptará. • Debe ser difícil de engañar.

5.3.4 Justificación del uso Identificación y autent ificación de usuarios y servidores en el servidor Hemos seleccionado Kerberos para la identificación y autentificación de usuarios y servidores para asegurar que los passwords nunca se envíen a través de la red desencriptados. Para que de esta manera eliminamos las amenazas de la interceptación de los paquetes de passwords en la red. Y porque creemos que es muy útil para una comunicación segura tener un servidor común que identifique a cada usuario que entra a cada uno de nuestros servicios que dan nuestros servidores para tomar la información del portal.



91

5.3.5 Justificación de la utilización de 3DES simét rico Como sabemos el algoritmo de encriptación DES esta casi totalmente en desuso ya que no es totalmente fiable, por lo que no nos decantaremos por este algoritmo. Respecto al algoritmo 3DES sabemos que mejora considerablemente DES, aunque se cree que no es del todo fiable actualmente. AES por el contrario es el algoritmo más utilizado y se cree que más seguro y como hemos visto ofrece encriptación de bloques a128 bits y la clave puede ser de 128, 192 o 256 bits.

5.3.6 Justificación de la utilización de RSA para l a comunicación administrador y servidores A la hora de elegir el algoritmo RSA hemos tenido en cuenta la peculiaridad de este sistema en cuanto a la generación de las claves y hemos visto que utiliza la aritmética modular. Además por el momento se considera RSA como un algoritmo fiable siempre y cuando se especifiquen longitudes de los parámetros adecuados como veremos más adelante.

5.3.7 Justificación de la Encriptación de la Base d e datos HMAC es un algoritmo MAC utilizado en muchos casos para el manejo de claves y almacenamiento de las mismas de una manera considerablemente simple, por esto se ha decidido utilizar HMAC para el almacenamiento de las claves en la base de datos correspondiente.

5.3.8 Justificación de la utilización de HTTPS Dado que para acceder a nuestro portal es necesaria la identificación, hemos considerado oportuno aplicar este protocolo de seguridad a nivel de aplicación, ya que debemos tener un control de la gente que accede y que su acceso se realice de una forma segura, para evitar que algún individuo, de forma malintencionada, pueda hacerse pasar por uno de los usuarios autorizados. Otro motivo para aplicar este protocolo en nuestro portal es que necesitamos confidencialidad, para mantener en secreto la identidad de los comunicadores, e integridad, para que la comunicación se haga sabiendo quienes son verdaderamente los interlocutores y el servidor y así tener toda la información cifrada y fuera del alcance de cualquier persona.



92

5.4 Desarrollo de la arquitectura de seguridad En esta figura 1 se puede ver la arquitectura que hemos diseñado para nuestro sistema de seguridad. Y en la tabla siguiente vemos los elementos que tenemos en nuestra arquitectura, que más adelante diseccionaremos para poner las tecnologías de seguridad apropiadas para nuestro sistema del portal Web.

Figura 36. Arquitectura del sistema.

5.4.1 Clasificación de los elementos de la figura 1

Usuarios externos

Terminales - workstations

Router

Router wireless

Sede de la administración del portal

Base de datos

Firewall a la base de datos

Servidores (Aplicaciones, Web, correo, streaming)

Firewall de los servidores

Router

ONGs

Terminales – workstations

Firewall

Router

Universidad


Firewall

Router

5.4.2 Requisitos de seguridad y sus tecnologías más adecuadas para nuestro proyecto

Requisito de seguridad Opciones de tecnologías

Tecnología

Seleccionada



93

Gestión de claves PKI

Kerberos para los servidores PKI

Control de acceso Kerberos para servidores

LDAP para PCs Kerberos

Detección de intrusos y virus IDS para servidores, PCs, todos.

IDS

Identificación y autentificación de usuarios y servidores

Kerberos sobre PKI para servidores

Y para nuestros usuarios Kerberos

Kerberos

Encriptación Router 3DES simétrico

PC admin. RSA publica

Servidores RSA publica

Base de datos HMAC

AES

RSA

HMAC

Tratamiento de datos HTTPS

SSL HTTPS

5.4.3 Tabla resumen de todas las tecnologías necesa rias para nuestro portal, con sus servicios de seguridad y la capa OSI dónde se encuentran

Localización Elementos Requisitos de seguridad Tecnologías Servicios de

seguridad Capa OSI

Terminales - workstations

Detección de intrusos y virus

Comunicación segura*

Control de acceso

IDS

Kerberos

Integridad

Autenticación

Física

Enlace

Física

Enlace

Router

Encriptación AES Confidencialidad

Autenticación

Integridad

Enlace

Usuarios externos

Router wireless


Autenticación

Integridad

Enlace



94




Control de acceso

IDS

Kerberos

Integridad

Autenticación

Física

Enlace

Física

Enlace

Firewall


Control de acceso

Kerberos

Autenticación

Física

Enlace

ONGs

Router


Autenticación

Integridad

Enlace




Control de acceso

IDS

Kerberos

Integridad

Autenticación

Física

Enlace

Física

Enlace

Firewall

Control de acceso

Kerberos Autenticación Física

Enlace

Universidad

Router


Autenticación

Integridad

Enlace

Base de datos

Control de acceso

Encriptación

Kerberos

HMAC

Autenticación

Autenticación

Integridad

Física

Enlace

Física

Enlace

Firewall a la base de datos


Control de acceso

Kerberos

Autenticación

Física

Enlace

Sede de la administración del portal

Servidores (Aplicaciones, Web, correo, streaming)



Gestión de claves

Control de

IDS

PKI

Integridad

Integridad

Autenticación

Confidencialidad

Física

Enlace

Enlace



95

acceso

Identificación y autentificación de usuarios y servicios

Encriptación

Kerberos

Kerberos

RSA

Autenticación

Autenticación

Confidencialidad

Autenticación

Integridad

Física

Enlace

Física

Enlace

Enlace

Firewall de los servidores


Control de acceso


Kerberos

Kerberos

Autenticación

Autenticación

Física

Enlace

Física

Enlace

Router


Autenticación

Integridad

Enlace

PC-Administración



Gestión de claves

Control de acceso


Encriptación

IDS

Kerberos

PKI

Kerberos

RSA

Integridad

Autenticación

Integridad

Autenticación

Confidencialidad

Autenticación

Confidencialidad

Autenticación

Integridad

Física

Enlace

Física

Enlace

Enlace

Física

Enlace

Enlace



96

5.4.4 Desarrollo de cómo lo aplicamos la tecnología elegida a cada elemento

5.4.4.1 Cómo implementamos PKI gestión claves dentro de nuestro sistema (Servidores y PC Administrador) Nosotros podemos adoptar el modelo que nuestro servidor ofrezca servicios de certificación. Para así certificar a cada miembro que se registra en nuestro portal Web. Cómo la identificación en nuestro portal se hace de forma segura, bajo el protocolo https, podemos asegurar que los datos que nos llegan para certificarlos son correctos. Además para asegurar el no repudio, implantamos firma digital en nuestra PKI para sellar y certificar cada mensaje que se envía a nuestro servidor para publicarlo en el portal. Este uso requiere de la existencia de unas autoridades de certificación (CA) que afirmen, mediante los correspondientes certificados de servidor, que éstos son quienes dicen ser antes del establecimiento de ese canal seguro. Para poder realizar este proceso adquirimos certificados de servidor a partir de SCS (Service Certificate Server Project) y así podemos contar con las siguientes características para nuestros usuarios respecto a la gestión de calves: Los certificados emitidos en el servicio SCS son reconocidos por todos los principales navegadores, clientes de correo, etc., sin necesidad de que el usuario descargue e instale el certificado raíz de la CA que los emitió. Los certificados de servidor se realizarán exclusivamente para el establecimiento de canales cifrados. La persona de la comunidad universitaria o de la organización no gubernamental deberá proporcionar los nombres de las máquinas para las que se solicita la emisión de un certificado de servidor SCS. Podemos decir que cada servidor que tenemos y en el PC del administrador, tendrá un certificado SCS.

5.4.4.2 Cómo implementamos Kerberos como control de acceso en nuestro sistema Como hemos dicho anteriormente a partir del ticket el servidor final puede decidir si finalmente este usuario tiene acceso al sistema, y además a partir de aquí poder definir el tipo de acceso, es decir si un determinado usuario tiene acceso a determinadas partes de la aplicación dependiendo del usuario. Por ejemplo en los perfiles de usuarios que hemos especificado en nuestro portal cada uno de ellos puede llevar a cabo una serie de acciones diferentes dependiendo del la identidad de la persona.

5.4.4.3 Cómo implementamos SDI en nuestro sistema Tal y como se presenta nuestro sistema, el SDI debe situarse en nuestra sede central y analizará los elementos que allí se encuentran:

• Base de datos • Firewall a la base de datos • Servidores (Aplicaciones, Web, correo, streaming) • Firewall de los servidores • Router



97

Una primera elección como IDS sería el software IDS a2 , ya que entre sus principales características destaca que analiza programas sin la necesidad de que posean firma, observa cualquier programa que se encuentre activo y lo detiene si el mismo muestra alguna actividad sospechosa y se lo comunica al usuario, y puede detectar los siguientes tipos de malware:

• Mail gusanos • Backdoors • Backdoors con Lógica de Conexión Reversa (LAN Bypass) • Spyware/Adware • HiJackers • Marcadores (Dialers) • Administración Remota

Además, el IDS a² puede monitorear y detener las siguientes acciones:

• Instalación de nuevos drivers y servicios • Cualquier tipo de manipulación de procesos como inyección-DLL, inyección de

código, parches, finalizaciones, etc. • Instalación de nuevos BHOs (Asistentes de Objetivos de Navegadores) • Cambios a su configuración de su navegador

Otro software a tener en cuenta sería el IDS/IPS de Bull, que además de proporcionar características similares a IDS a², trabaja en multiplataformas.

5.4.4.4 Cómo implementamos la Identificación y autentificación de usuarios y servidores dentro de nuestro sistema (Firewalls, servidores y PC administrador) Para que funcione de una forma efectiva Kerberos en nuestro portal tendremos que trabajar con Kerberos en todos nuestros servidores. De momento tenemos 3 servidores en nuestro diseño del portal, por tanto en cada uno de ellos y en cada una de las aplicaciones que tenemos que mandar passwords o los utilizan, se mandarán encriptados. Para que todo funcione correctamente con Kerberos necesitamos una sincronización de reloj entre los ordenadores que trabajan, nuestros servidores y la red. Para asegurarnos que las entradas DNS y de los hosts en nuestra red son correctas. Con Kerberos vamos a utilizar los passwords para autenticar sin mandarlo por la red o Internet. Sabemos que en nuestra arquitectura tenemos una base de datos de usuarios con un apartado de la base de datos para Kerberos, dónde guarda las passwords encriptados de los usuarios del portal, pero no solamente guardamos los passwords de los usuarios sino también dicha parte de la base de datos contiene claves para todos los servicios que ofrece nuestra red para nuestro portal. Para utilizar Kerberos con nuestro firewalls de la arquitectura que hemos definido al principio, tenemos que diferenciar entre los distintos tipos de tráfico, porque depende del tráfico habilitaremos unos puertos u otros. Normalmente estos puertos serán números menores que 1024, y serán tanto UDP como TCP, como por ejemplo el 749 para el administrador del portal, el 88 para permitir peticiones salientes TCP, 2015 para los servicios de login de Kerberos.



98

5.4.4.5 Cómo implementamos AES en nuestro sistema Como hemos avanzado anteriormente AES es un de los algoritmos de cifrado de clave simétrica más utilizados actualmente, debido a su robustez y ya que por el momento no se conocen ataques que puedan comprometer la seguridad del algoritmo hemos elegido este algoritmo para la encriptación de los datos. También es importante definir el tamaño de la clave que utilizaremos. Como sabemos nuestro sistema almacenará información sobre diversos proyectos, por lo que la mayoría de la información a transmitir no es del todo crítica, por esto definimos que una longitud de clave de 128bits será suficiente para encriptar los datos.

5.4.4.6 Cómo implementamos RSA en nuestro sistema Como hemos dicho anteriormente debemos definir una longitud de n para que nuestro sistema sea lo suficientemente robusto. Actualmente esta recomendado que la longitud de n sea como mínimo de 2048bits, ya que si el valor de n no es lo suficientemente elevado el valor de n podría ser factorizado por un conjunto de computadoras. Por lo tanto, si n es suficientemente grande el algoritmo RSA es seguro Por lo que a la hora de definir el valor de n hemos considerado que el valor mínimo antes especificado ya es suficiente, es decir n=2048bits.

5.4.4.7 Cómo implementamos HMAC en nuestro sistema Como hemos dicho en la definición del algoritmo no basta con decir que utilizaremos un HMAC para el almacenamiento de claves sino que también debemos especificar cual es la función de hash que utilizaremos (MD5, SHA-1, RIPEMD-160) SHA-1: Algoritmo hash 1 de seguridad. Algoritmo que toma un mensaje con una longitud inferior a 264 bits y genera un mensaje resumido de 160 bits. El mensaje resumido proporciona seguridad contra ataques de colisión e inversión. MD5: (Message Digest 5). Algoritmo que toma un mensaje de entrada de longitud arbitraria y genera una salida con formato de huella digital de 128 bits o mensaje resumido. Esta pensado para las aplicaciones de firma digital, en las que un archivo de gran tamaño debe comprimirse de forma segura antes de codificarlo. El algoritmo hash que utilizaremos a la hora de implementar el HMAC será SHA-1, a pesar de que como vemos la longitud de entrada en MD5 es variable y por tanto no estaríamos sujetos a la longitud de la entrada, pero creemos que el tamaño de la entrada no limita nuestro sistema. Uno de los puntos clave a la hora de elegir SHA-1 es que se considera más fuerte a los denominados brute force attacks. Además se ha podido observar que MD5 es vulnerable a ataques criptoanalíticos, mientras que para SHA-1 se desconoce que sea vulnerable a este ataque. Respecto a la simplicidad ambos algoritmos son simples de implementar y por tanto no ha supuesto un aspecto importante en la elección del algoritmo SHA-1.

5.4.4.8 Cómo implementamos HTTPS en nuestro sistema



99

Dado que en nuestro sistema utilizaremos servidores Tomcat, debemos tener en cuenta que JSSE viene incluido en Tomcat desde la versión 1.4 y sólo debemos activar la opción de uso de https. Normalmente el servidor Web lo envía todo en texto plano y es la configuración apropiada la que nos proporciona las características deseables en https. Otro aspecto a tener en cuenta es que el servidor Web manda la clave pública, lo cifra con la privada y el usuario desencripta con la pública Si el usuario encripta con la privada y el servidor desencripta con la pública y no tiene suficientes recursos computacionales no podrá llevarse a cabo el acceso a los recursos. Para la implementación de https en nuestro sistema lo que deberemos hacer se resume en los pasos siguientes:

• Instalar el certificado de llave pública y privada en el servidor Web • Configurar los recursos para requerir el acceso mediante SSL • El cliente envía una petición HTTP estándar • El servidor Web lee los archivos de configuración y determina si el recurso al

que se quiere acceder recae en un directorio protegido. Entonces el servidor sólo puede dar acceso a los usuarios conocidos.

• El servidor responde con un mensaje HTTP 401 Authorization Required Response.

• El navegador del cliente muestra el certificado, que deberá aceptar el cliente, y los campos de Usuario y Contraseña que deberá rellenar el cliente, además de mostrar el nombre del host al que se conecta.

• El cliente reenvía la petición con los campos obligatorios completos. • El servidor compara la información enviada por el cliente en su lista de usuarios

y contraseñas. Sigue estos pasos: o Usuario y contraseña válidos � El servidor envía el contenido o Autorización falla � El servidor reenvía el mensaje HTTP 401

Authorization Required Response. o Cliente cancela transacción � El navegador muestra un mensaje de

error.



100

6. Bibliografía

6.1 Servidores • Java RMI

http://www.revista.unam.mx/vol.2/num1/art3/ http://www.osmosislatina.com/java/rmi.htm

• Programa gráficos LanFlow

• http://developer.skype.com • https://developer.skype.com/Docs/ApiDoc • www.apple.com • http://store.apple.com/Apple/WebObjects/spainstore.woa/6364042/wo/8S5KrAQQMzUL

2Dk2KfkqTyMdVIn/0.PSLID?mco=D52CEE75&nclm=XserveIntel • http://developer.apple.com/opensource/server/streaming/) • Programa Diagrama de casos de uso: Visual UML • Programa Diagramas de secuencia: DIA 0.94

6.2 Codificación • Monografia técnicas y aplicaciones de la teoria de compresión de datos. Ubeimar

Grisales Serna. Julio 2005. http://gpsis.utp.edu.co/omartrejos/descargas/Proy%20Tecnicas%20de%20Compresion.pdf

• Articulo extraído de la página Web de Winrar http://winrar.com.es/soporte/articulo/23?query=lz77

• Página Web de la universidad de Alicante. Temario sobre la Teoría de la información y de la Codificación del 2003 http://www.dccia.ua.es/dccia/inf/asignaturas/TIC/Material/Tecnicas%20de%20compresion/Tecnicas%20de%20compresion.htm#_Toc30247271

• Diseño y construcción de un sistema de telemedicina en Chile. Alejandro Woywood

Wijnant. Septiembre 1998. http://www2.ing.puc.cl/~iic3686/tesis/Extracto%20Tesis%20AW%20-%20Representacion%20y%20Compresion%20de%20la%20informacion.pdf

• MoviForms: XForms para teléfonos móviles . C. Fernandez, D. Iglesia, C. Escudero. Universidad de A Coruña. Julio 2005. http://w3.iec.csic.es/URSI/articulos_gandia_2005/articulos/NC2/226.pdf

• http://www.infor.uva.es/~jadiego/files/tesis.pdf • http://webdiis.unizar.es/~elvira/LZ.pdf • http://www.gedlc.ulpgc.es/docencia/seminarios/cd/Diccionarios/tsld019.htm • http://www.exa.unicen.edu.ar/catedras/teoinfo/apuntes/compresion06.pdf

http://www.doschivos.com/trabajos/progra/405.htm

6.3 Base de datos

• http://www.hipertexto.info/documentos/dtds.htm CASTILLO, Carlos. DTD y Schemas. Tejedores del Web.

• http://www.tejedoresdelweb.com/307/article-2147.html Advanced Quality Solutions. XML Schema y DTDs.

• http://www.programacion.com/tutorial/schemaydtd/ DTD. Apuntes de clase de Rafael Páez. Octubre 2006.



101

6.4 Interfaz de usuario

• Etnografia. Metodos de investigacion. Martyn Hammersley, Paul Atkinson. 2 ed. Paidos.

• Contextual Interview and Analysis of contextual user data. Raquel Navarro Prieto. Apuntes de clase de Interfaz de Usuario. Octubre 2006.

6.5 Seguridad • IDS

http://www.symantec.com/region/mx/smallbusiness/articles/LAM_intrusion.html http://es.tldp.org/Manuales-LuCAS/doc-unixsec/unixsec-html/node280.html http://www.bull.es/security/IDS.htm http://www.emsisoft.com/es/software/ids/

• PKI http://www.iec.csic.es/CRIPTonOMICon/susurros/susurros11.html Cryptography and network security. Principles and practices. William Stallings. Tercera edición. http://www.jnsa.org/mpki/ http://www.evolucy.com/esp/digital_identity.html

• Certificados http://www.terena.nl/activities/tf-emc2/scs.html

• Soporte de Managed PKI para SSL http://www.verisign.es/support/mpki-for-ssl-support/page_es_es_dev029657.html

• Kerberos Cryptography and network security. Principles and practices. William Stallings. Tercera edición. Configuring Your Firewall to Work With Kerberos V5 http://web.mit.edu/Kerberos/krb5-1.5/krb5-1.5.1/doc/krb5-admin/Configuring-Your-Firewall-to-Work-With-Kerberos-V5.html

• HTTPS http://www.programacionweb.net/articulos/articulo/?num=411 http://java.sun.com/products/jsse/INSTALL.html



102

entregable e3 proyecto de especificación de …proyecto de especificación de aplicaciones grupo i...

Documents