Proyecto realizado por el alumno: JOSÉ LUIS TELLO MENESES.

Transcripción

1 Proyecto realizado por el alumno: JOSÉ LUIS TELLO MENESES. Fdo.: Fecha: / / Autorizada la entrega del proyecto cuya información no es de carácter confidencial El DIRECTOR DEL PROYECTO ANTONIO MELÉ DE JUAN. Fdo.: Fecha: / / Vº Bº del Coordinador de Proyectos EDUARDO ALCALDE LANCHARRO. Fdo.: Fecha: / /

2 ANÁLISIS Y GESTIÓN DE BACKLINKS. Autor: José Luis Tello Meneses. Director: Antonio Melé de Juan. Madrid. Septiembre 2011.

3 Agradecimientos. Agradezco infinitamente a mis padres y hermana por los grandes esfuerzos que han realizado para permitirme llegar a ser Ingeniero en Informática en ICAI. Su apoyo, paciencia y comprensión no tienen límites. Especial mención a Antonio Melé; gracias por ofrecerme este proyecto tan interesante, innovador y creativo. - I -

4 Análisis y Gestión de Backlinks. Autor: José Luis Tello Meneses. Director: Antonio Melé de Juan. Resumen. Actualmente el acceso a una página web se realiza, en la mayoría de los casos, a través de enlaces desde otras páginas web. A estos enlaces, conocidos como backlinks, no se les ha prestado demasiada importancia como medio de obtener datos estadísticos. Un backlink contiene multitud de datos interesantes encapsulados en el protocolo HTTP y en el protocolo de control de transmisión TCP/IP. A través de un análisis de las peticiones a una página web se pueden obtener gráficas, con sus correspondientes datos estadísticos, que informen sobre el tráfico en tiempo real de la página y permitan tomar decisiones sobre posicionamiento web, inversión publicitaria, seguridad y posicionamiento de contenidos. La importancia del proyecto reside en la creación de una capa middleware que permita el análisis de backlinks en tiempo real, con alta escalabilidad y sin comprometer el rendimiento de la web, utilizando para ello una base de datos no relacional. Palabras clave. Django, Backlink, Redis, tecnología Comet, capa middleware. Introducción. Una página web es la presentación digital de cualquier contenido que se desee aportar a la World Wide Web. Mediante cualquier navegador web se puede acceder a la información de una página web. Pero, qué ocurre cuando existe tal cantidad de información que los usuarios no son capaces de llegar al contenido - II -

5 que realmente les interesa sin haber pasado antes por otras cinco páginas web inútiles? Cómo pueden saber los propietarios de las páginas web si su información está llegando al público objetivo que les interesa? Existen varias formas de llegar a una página web: algunas veces se obtiene la dirección en un periódico, una revista o incluso se escucha por la radio o la televisión. Pero la inmensa mayoría de las veces se accede a ese contenido que llama la atención a través de un enlace llamado comúnmente link. Un link es un enlace que dirige a un navegador web a una página determinada. Se puede realizar la vinculación a la página pulsando directamente con el ratón. Se utiliza el término backlink en vez de link debido a que es como se denomina comúnmente en las técnicas de posicionamiento web, utilizadas en buscadores como Google, Yahoo! O Bing, entre otros. Los backlinks contienen mucha información sobre el usuario y su ubicación, tanto en el protocolo de aplicación HTTP como en el protocolo de red y transporte TCP/IP. El objetivo de este proyecto consiste en analizar y gestionar los backlinks que acceden a una página web. Mediante dicho análisis se podrán mejorar aspectos de la gestión de la página web como son el posicionamiento en buscadores, posicionamiento de contenidos, la seguridad de la propia página e incluso incrementar los posibles ingresos por publicidad. Existen servicios en Internet que realizar estadísticas sobre una página web propia. El más conocido de ellos es Google Analytics. Pero el gran problema de todos ellos es que no son capaces de ofrecer la información en tiempo real. Los datos no son fiables hasta pasadas 48 horas como mínimo. Esto supone un gran obstáculo en todos los objetivos que persigue el proyecto, sobre todo en el ámbito - III -

6 de la seguridad debido a que en pocos segundos se pueden producir ataques que comprometan la continuidad de una página web. Descripción del trabajo. La ejecución de la aplicación es transparente al usuario. Se trata de una capa middleware, una capa software entre el usuario y la página web que no afecta de manera alguna al usuario ni al rendimiento de la página web. Esta capa es gestionada por el propietario de la página web o el responsable del mantenimiento (webmaster). Figura 1 - Comunicaciones de la capa middleware. La aplicación trabaja en tiempo real. Realiza constantemente análisis de backlinks para gestionar los posibles problemas de seguridad de la página web y obtiene estadísticas fiables para tomar medidas en un corto periodo de tiempo. La - IV -

7 aplicación informará al responsable de los datos críticos que puedan comprometer a la accesibilidad y disponibilidad de la web. Por otro lado, la aplicación ha sido diseñada para que sea totalmente escalable. El almacenamiento de datos y estadísticas se realiza en memoria volátil hasta unos límites de espacio o tiempos prefijados. De esta manera se debilita el problema de la sobrecarga de los servidores. Esto se consigue mediante el uso de la base de datos no relacional Redis junto con la tecnología Comet, almacenándose la información únicamente cuando se superan los límites prefijados, en vez de almacenar constantemente en el servidor cada dato nuevo que se obtenga, pudiendo producir una reducción del rendimiento del servidor, llegando incluso a la saturación y la denegación del servicio. La aplicación ha sido desarrollada utilizando un lenguaje de alto nivel llamado Python, que le aporta la característica de ser multiplataforma. Python es un lenguaje interpretado el cuál se compila en el momento de la ejecución y es soportado por cualquier sistema operativo. La aplicación no tendrá problemas de compatibilidad en ningún servidor o plataforma operativa. Resultados. La capa middleware de Análisis y Gestión de Backlinks ha sido desarrollada correctamente y sus resultados cumplen los objetivos marcados al inicio del proyecto. El código desarrollado en el lenguaje Python junto con el framework Django es limpio y eficiente. La aplicación ha sido implantada en un banco de pruebas en el servidor, realizando diversas peticiones a la página web desde distintos enlaces para comprobar su capacidad de acceso a base de datos, encapsulamiento de los datos, conexión con Google Visualization y generación de gráficos. - V -

8 Figura 2 - Gráfico de accesos a contenidos cada hora. La gestión de la base de datos REDIS ha sido muy satisfactoria, al igual que las interfaces de administración en donde se muestran las gráficas producidas en tiempo real. Se han realizado todas las pruebas posibles para comprobar el rendimiento de la web y los posibles fallos que hubiera en el código fuente. Conclusiones. Como colofón de esta aplicación se puede destacar su gran aportación para el futuro de Internet. La gestión de backlinks ofrece muchas aportaciones en cuanto a materia de seguridad, posicionamiento e inversión. Internet, que crece de una manera desmesurada e incontrolada, necesita mecanismos de análisis para poder mejorar las sensaciones de los usuarios, centrar las búsquedas de la información relevante para los usuarios y desechar la información inútil. Mediante las estadísticas y los métodos de posicionamiento se puede conseguir un Internet más eficaz y eficiente. - VI -

9 Referencias. [HOLO09] La guía definitiva de Django Adrian Holovaty, Jacob Kaplan Anaya, [BECK07] Extreme programming Kent Beck. Embrace Change, [FISS08] [WEB001] Aplicaciones web 2.0 Wikis RSS - Marcela L. Fissore Lic. Gustavo A. Gómez Rodríguez. Ebook, Google Visualization API [WEB002] Documentación BBDD REDIS - VII -

10 Analysis and Management of Backlinks Author: José Luis Tello Meneses. Director: Antonio Melé de Juan. Abstract. Nowadays the access to a web page is done in most cases through links from other web pages. These links are known as backlinks, they have not been considered very important as a way of obtaining statistic data. A backlink contains a wide range of interesting information encapsulated in the HTTP protocol and also the transmission control TCP/IP protocol. Through an analysis of the petitions of a webpage we can obtain graphics with their correspondent statistic data which give us information instantly over the webpage and also allows us to make decisions over the positioning of the web itself, publicity investments, security and positioning of contents. The importance of this project relies on the creation of a middleware level which can allow us to analyze backlinks in real-time with a high scalability level and without compromising the webs performance by using a not related data base. Key Words. Django, Backlink, Redis, Comet technology, middleware level. Introduction. A webpage is the digital presentation of any content which is contributed to the World Wide Web. By using any web navigator you can gain access to the information of a webpage. But what happens when there is so much information that the users are not able to reach the content they are really interested in without previously passing through five useless web pages? How can the owners of these - VIII -

11 web pages know that their information is reaching that part of the public which is really interested? There are various forms to reach a web page: sometimes you obtain the website from a newspaper, a magazine or even hear it on the radio or television. But the vast majority of times that someone gains access to certain content that draws their attention it is through a connection commonly known as a link. A link is a connector which directs a web navigator to a certain web page. You can perform this connection to the page by just simply pressing on the mouse. The term backlink is used instead of link due to the fact that this is how commonly called in positioning web techniques used in web searchers such as Google, Yahoo! O Bing, among others. Backlinks contain a lot of information of the user and his location, it can be used in both the HTTP application protocol and the TCP/IP red and transport protocol. The main objective of this project consists in the analysis and management of those backlinks through which we gain access to a web page. Through this analysis we will be able to improve certain aspects of the web page s management as that of the positioning of searchers, positioning of contents, security measures of the web page itself and we will even be able to increase possible benefits for publicity. There are certain services on the Internet which gather statistics on a web site itself. The most famous one is Google Analytics. But they all have one defect which is that they are not able to offer information in real-time. Data is not reliable until after minimum 48 hours. This is a big obstacle for all the objectives this project seeks to complete. This is also an obstacle of the security aspect - IX -

12 because there can be attacks which could compromise the well being of a web site. Description. The execution of the application is transparent to the user. This is a middleware layer; it is a level of software between the user and the web page that does not affect in any possible way neither the user or the software we are dealing with. This layer is managed by the owner of the web page or the person responsible for maintenance (webmaster). Image 1 - Middleware communication. This application works in real-time. It constantly performs the analysis of backlinks to manage the possible problems concerning the security of the web page and it also obtains reliable statistics to make quick decisions of any type. The - X -

13 application will inform the person in charge of all the critical data which may compromise the web page s level of accessibility or availability. On the other hand, this application has been designed to be totally scalable. The storage of statistics data is done in a volatile memory until a set of prefixed space and time limits. This way the servers overload problem can be solved. This is possible thanks to the use of the non-related data base Redis together with the Comet technology which stores the information only once the prefixed limits have been overcome instead of constantly storing in the data base every new piece of data it may obtain reducing this way the performance rate of the server and risking a saturation or rejection of any kind of service. The application has been developed using a high level language called Python which adds to it the multiplatform feature. Python is an interpreted language which is compiled in the moment of execution and which is supported by any operative system. The application will not have any problems of compatibility with any server or operative platform whatsoever. Results. The middleware layer of Analysis and Management of Backlinks has been correctly developed and its results succeed in the objectives which were established at the beginning of the project. The code which was developed in the Python language together with Django framework is clean and efficient. The application has been implanted in a location of test storage in the server, performing various petitions to the web page from different links to check its capacity to access the data base, storage of data, connection with Google Visualization and graphics. - XI -

14 Image 2 - Chart hourly access to content. The management of the Redis data base is satisfactory as well as the administration interfaces where the graphics are shown in real-time. All the possible tests regarding the performance of the web have been taken to seek for any possible failures in the code source. Conclusion. As a colophon of this application we can highlight its big input for the future of Internet. The management of backlinks offers many inputs concerning security matters, positioning and investment. Internet grows hugely and rapidly so we need analysis mechanisms to be able to improve its accessibility for users. We need to focus our efforts on the searching of relevant information for user this way avoiding any kind of unnecessary information. Using statistics and positioning methods we can achieve in making Internet more efficient. - XII -

15 Bibliography. [HOLO09] La guía definitiva de Django Adrian Holovaty, Jacob Kaplan Anaya, [BECK07] Extreme programming Kent Beck. Embrace Change, [FISS08] [WEB001] Web applications 2.0 Wikis RSS - Marcela L. Fissore Lic. Gustavo A. Gómez Rodríguez. Ebook, Google Visualization API [WEB002] Documentation BBDD REDIS - XIII -

16 ÍNDICE DE LA MEMORIA Índice de la memoria Parte I Memoria...1 Capítulo 1 Introducción al Proyecto Introducción Situación Actual Motivación del Proyecto Objetivos Metodología / Solución Desarrollada Recursos / Herramientas Empleadas Recursos Hardware Recursos Software Capítulo 2 Estado del Arte Introducción Evolución de la Web: Web Evolución de los Buscadores Posicionamiento en Internet Teoría del Long Tail Seguridad de la Red Capítulo 3 Arquitectura del Proyecto Introducción Selección del Lenguaje de Programación Selección del Framework de Desarrollo XIV -

17 ÍNDICE DE LA MEMORIA 3.4 Protocolo HTTP Métodos de Petición HTTP Métodos de Respuesta HTTP Tecnología Comet Diferencias entre AJAX y COMET (Reverse AJAX) Base de Datos Redis Benchmark de Redis Configuración del Servidor REDIS Capa Middleware de la Aplicación Capítulo 4 Análisis Conceptual Modelo de Dominio Diagrama de Clases Descripción de Atributos Modelo de Casos de Uso Diagrama de Casos de Uso Descripción de Casos de Uso Diagramas de Secuencia Capítulo 5 Plan de Gestión del Proyecto Organización del Proyecto Estructura de División del Trabajo Descripción de los Paquetes de Trabajo Estructura Interna Responsabilidades Asignación de Recursos Planificación Estudio Económico Costes de Implantación Costes de Operación Costes Totales Capítulo 6 Conclusiones XV -

18 ÍNDICE DE LA MEMORIA 6.1 Conclusiones Capítulo 7 Bibliografía Bibliografía Referencias Web Parte II Manual de usuario Capítulo 1 Manual de usuario Manual de Usuario XVI -

19 ÍNDICE DE FIGURAS Índice de figuras Imagen 1 - Esquema de un Sprint Imagen 2 - Ejemplo de Burn Down Chart Imagen 3 - Ejemplo de folksonomía Imagen 4 - Lectores de feeds de RSS Imagen 5 - Cambios en la Web Imagen 6 - Futuro de la Web Imagen 7 - Logotipos de algunos buscadores jerárquicos Imagen 8- Posición de tecnologías SEO y SEM en Google Imagen 9- Principales contenidos SEO en una página web Imagen 10- Competitividad y coste según las keywords Imagen 11 - Infraestructura de un botnet Imagen 12 - Ataque DDoS con ordenadores zombis Imagen 13 - Petición de conexión SYN/ACK Imagen 14 - Campos del protocolo ICMP Imagen 15- Patrón de diseño MVC Imagen 16 - Ponderaciones de los lenguajes Imagen 17 - Porcentaje de carga de CPU Imagen 18 - Porcentaje de disponibilidad Imagen 19 - Tiempo de respuesta (segundos) Imagen 20 - Duración máxima de una transacción Imagen 21 - Número de transacciones servidas Imagen 22 - Cantidad de memoria principal utilizada XVII -

20 ÍNDICE DE FIGURAS Imagen 23 - Análisis ponderado de los atributos Imagen 24 - Modelo capas OSI Imagen 25 - Comunicación HTTP entre navegador y servidor Imagen 26 - Comunicación Web Síncrona Imagen 27 - Comunicación Web Asíncrona Imagen 28 - Tecnologías que implementa AJAX Imagen 29 - Ejemplo de módulo COMET entre navegador y servidor Imagen 30 - Diagrama de secuencia del XMLHttpRequest Imagen 31 - Ejemplo de tecnología COMET Imagen 32 - Tablas de una base de datos relacional Imagen 33 - Logotipos de diferentes bases de datos NoSQL Imagen 34 - Logotipo de base de datos REDIS Imagen 35 - Comunicaciones de la capa middleware Imagen 36 - Diagrama de casos de uso Imagen 37 - Diagrama de secuencia: petición HTTP Imagen 38 - Diagrama de secuencia: login administrador Imagen 39 - Diagrama de secuencia: actualización de estadísticas Imagen 40 - Diagrama de secuencia: actualización de estadísticas manuales Imagen 41 - Organigrama del proyecto Imagen 42 - Captura de prueba de estadísticas Imagen 43 - Captura de gráfico de estadísticas Imagen 44 - Captura de gráfico de estadísticas Imagen 45 - Captura de gráfico de estadísticas XVIII -

21 ÍNDICE DE TABLAS Índice de tablas Tabla 1 - Características de los lenguajes Tabla 2 Encabezados de petición del protocolo HTTP Tabla 3 - Encabezados de respuesta del protocolo HTTP Tabla 4 - Cabeceras opcionales del protocolo HTTP Tabla 5 - Códigos de estado del protocolo HTTP Tabla 6 - Porcentaje de operaciones SET en REDIS Tabla 7 - Porcentaje de operaciones GET en REDIS Tabla 8 -Porcentaje de operaciones PUSH en REDIS Tabla 9 - Porcentaje de operaciones POP en REDIS Tabla 10 - Comandos utilizados en la creación del servidor con REDIS Tabla 11 Paquete de trabajo Lanzamiento Tabla 12 Paquete de trabajo Reunión de lanzamiento Tabla 13 Paquete de trabajo Memoria del proyecto Tabla 14 Paquete de trabajo Control periódico Tabla 15 Paquete de trabajo Cierre Tabla 16 Paquete de trabajo Análisis de requisitos Tabla 17 Paquete de trabajo Diseño del sistema Tabla 18 Paquete de trabajo Diseño de la BBDD Tabla 19 Paquete de trabajo Diseño de la arquitectura web Tabla 20 Paquete de trabajo Diseño de Google Visualization Tabla 21 Paquete de trabajo Diseño de las interfaces XIX -

22 ÍNDICE DE TABLAS Tabla 22 Paquete de trabajo Diseño de los gráficos analíticos Tabla 23 Paquete de trabajo Desarrollo del sistema Tabla 24 Paquete de trabajo Desarrollo de la BBDD Tabla 25 Paquete de trabajo Desarrollo de compatibilidad Tabla 26 Paquete de trabajo Desarrollo del módulo HTTP Tabla 27 Paquete de trabajo Desarrollo de estadísticas y gráficos Tabla 28 Paquete de trabajo Manual de usuario Tabla 29 Paquete de trabajo 3 - Implementación y pruebas Tabla 30 Paquete de trabajo Pruebas unitarias Tabla 31 Paquete de trabajo Implementación Tabla 32 - Matriz de responsabilidades Tabla 33 - Duración de los paquetes de trabajo Tabla 34 - Total horas participante / Paquete de trabajo Tabla 35 - Coste total de implantación Tabla 36 - Coste total de operación Tabla 37 - Coste total XX -

23 Memoria Parte I MEMORIA - 1 -

24 Introducción al Proyecto Capítulo 1 INTRODUCCIÓN AL PROYECTO - 2 -

25 Introducción al Proyecto 1.1 INTRODUCCIÓN En este capítulo se realizará una introducción del proyecto. En el apartado 1.1 Situación Actual se expondrá cómo funciona actualmente Internet, qué tecnologías y herramientas son usadas para la mejora de rendimiento y cuál es su alcance. En el apartado 1.2 Motivación del proyecto se explicarán qué funcionalidades y mejoras produce la aplicación desarrollada en el entorno de Internet. En el apartado 1.3 Objetivos se describirán cuáles son los objetivos que pretende cubrir y conseguir el proyecto, hasta dónde llega su alcance y qué asunciones y restricciones presenta. La metodología aplicada para la consecución de los objetivos se describirá en el apartado 1.4 Metodología /Solución desarrollada. Finalmente, en el apartado 1.5 Recursos /Herramientas empleadas se expondrán los recursos hardware y las herramientas software que se han utilizado para desarrollar la aplicación y su posterior puesta en marcha

26 Introducción al Proyecto 1.2 SITUACIÓN ACTUAL La mayor red de información y comunicación de la historia tiene un nombre: Internet. Actualmente la cantidad de usuarios de Internet se acerca a los dos mil millones de personas entre los cinco continentes según el estudio realizado por Us Census Bareau. Cabe destacar que el crecimiento de usuarios en 10 años ( ) ha sido de un 446% y la tendencia sigue en aumento. Internet está formada por aproximadamente 5000 redes en todo el mundo y su medio de comunicación es el protocolo TCP/IP. Existen cerca de 100 variantes de dicho protocolo que permite la circulación de información a través de todas las redes de Internet. Los servicios disponibles en la red están en constante cambio y cada vez proliferan nuevas aplicaciones. Las últimas tecnologías como el DSL, la fibra óptica y el Wireless han posibilitado las conexiones a gran velocidad y la unión de las personas mediante videoconferencias, llamadas telefónicas gratuitas, redes sociales e intercambio de archivos como películas, álbumes de fotos, libros en formato electrónico (PDF) y cualquier tipo de documento digitalizado. Cada vez son más los dispositivos que se conectan a la red para intercambiar información. Antiguamente se asociaba el uso de Internet con ordenadores de sobremesa. Posteriormente aparecieron los ordenadores portátiles y las conexiones WIFI gracias a las cuales se podía trabajar a cierta distancia, normalmente 100 metros, desde el punto de acceso a Internet, el router. Actualmente, cualquier dispositivo de última generación dispone de acceso a Internet: desde teléfonos móviles (smartphones) cuyo acceso a la red lo realiza a través de Wireless o conexión 3G-4G vía satélite, hasta Tablets PC que se conectan a Internet para buscar información, actualizaciones de software, descarga de ebooks y contenidos multimedia, e incluso para realizar videoconferencias

27 Introducción al Proyecto Las empresas se han dado cuenta de que la red es un medio muy valioso para publicitarse. Internet es la única plataforma en ascenso de inversión publicitaria y es gracias al alto ROI que se consigue. Las páginas web cada vez están más segmentadas a un público objetivo y es más sencillo para las empresas saber en qué tipo de portales deben invertir. Las agencias publicitarias tienen mayor información de los perfiles de los usuarios por lo que pueden dirigir mejor los anuncios a los portales con mayor cuota de público objetivo. Existen varias formas de obtener ingresos por publicidad. Las más asentadas en el mercado son: o Coste por clics (CPC): el anunciante paga por las respuestas del usuario ante el anuncio, haciendo clic en él para poder facturarlo. De esta manera se asegura que el usuario está interesado en la información del anuncio. La gran ventaja de este sistema es que las empresas sólo pagan cuando obtienen resultados. Los grandes buscadores que incorporan este sistema de publicidad son Google, con su sistema AdWords, y Yahoo!, con su sistema AdSense. El problema es la gran competencia que surge entre los grandes patrocinadores. Cuando se realiza una búsqueda, se suelen utilizar palabras clave. Las empresas pagan cierta cantidad por las palabras clave que les interesan y aparecerán en las primeras posiciones las empresas que paguen mayor cantidad por clic en su enlace. De esta manera las empresas pequeñas se posicionan en puestos bajos o incluso no llegan a aparecer, por lo que, cada vez más, este sistema estará enfocado a las empresas con mayor poder económico

28 Introducción al Proyecto o Coste por impresión (CPI) o coste por mil impresiones (CPM): el anunciante paga por un número determinado de visualizaciones, es decir, que su anuncio aparezca en la pantalla de un usuario independientemente de que surja efecto en él. Normalmente el anuncio aparece en forma de banner o como una ventana flotante encima de una página web. La página controla el número de accesos a dicha página y mediante un contador avisa al anunciante de cuánto debe pagar. Las empresas deben decidir si la inversión en publicidad les beneficia o si, por el contrario, no es rentable. Cuando deciden apostar por el sistema coste por clics, deben decidir cuánto pagar por cada clic. Una manera es calculando el número de visitas que obtienen a través de los anuncios y las ventas que producen esos usuarios, es decir, cuánto gana de media la empresa por usuario que entra en su página. Según este cálculo se obtiene el máximo que debe pagar una empresa por cada clic que se realiza en su anuncio. Un tema relacionado con la inversión en publicidad es el posicionamiento de páginas web. El posicionamiento web utiliza las llamadas técnicas SEO para conseguir que una página web esté entre las primeras referencias cuando se utiliza un buscador. Es una forma de posicionarse y obtener visitas a medio plazo, mientras que con las técnicas de coste por clics o coste por impresión se obtienen visitas a corto plazo con una mayor inversión. No es necesario invertir en publicidad para obtener un buen posicionamiento en los principales buscadores como Google, Bing o Yahoo!. Se necesita estructurar el código de la página, su diseño y sus contenidos. Los principales puntos en los que trabaja las técnicas SEO son: - 6 -

29 Introducción al Proyecto o Redacción apropiada de los contenidos internos: se debe adaptar los contenidos de la web a cómo lo leen los buscadores. Es necesario definir bien las palabras clave de cada contenido. o Selección de los contenidos de las etiquetas meta: es importante el uso de cabeceras para definir la importancia de los contenidos. Los frames no son recomendables y las etiquetas no deben contener guiones bajos ni símbolos especiales. o Actualización de datos: los buscadores indexan mejor a las páginas que están en constante cambio. Una web que mantiene sus contenidos actualizados tendrá mejor posicionamiento en los buscadores. o Contenidos externos: consiste en redactar contenidos en otras páginas ya sean comentarios, noticias, reportajes e insertar en el pie una referencia hacia la propia página web a posicionar. o Link Building: el Page Rank es un medidor de importancia en las búsquedas. Para aumentarlo es necesario que otras páginas web enlacen a la web en cuestión pero, para que sea efectivo, dichas páginas también deben tener un buen resultado de Page Rank. o Ser famoso: una buena manera de posicionarse es haciendo que se hable de la página web. Es importante que la gente comente o critique contenidos de la página. También se pueden organizar concursos online para que los usuarios participen y aumente la popularidad de la web

30 Introducción al Proyecto o Offline: consiste en publicar en diferentes medios de soporte, como revistas, periódicos, noticiarios y asistir a conferencias y congresos. De este modo se consigue que el público acceda a la web o comente en blogs y referencie al sitio web. Por otra parte, la seguridad en Internet ha sido un tema muy tratado en los últimos años. Conforme el número de usuarios crece, las comunicaciones están cada vez más comprometidas. Cada vez más se transmite información personal por los dispositivos conectados a la red. Se envían datos de tarjetas de crédito para operaciones bancarias y compras online, la comunicación vía está a la orden del día e incluso las comunicaciones telefónicas son enrutadas por la red. Para asegurar la privacidad se han creado leyes y normas nacionales e internacionales que son actualizadas constantemente para responder ante los nuevos servicios que aporta Internet. Todo portal web debe tener unos mínimos de seguridad para no comprometer la información de los usuarios. Con la gran cantidad de información existente repartida entre millones de páginas web ha sido necesario crear sistemas eficaces de generación de estadísticas para poder tener un mejor control de accesibilidad a los datos que realmente interesan a los usuarios y mejorar la seguridad de los portales web

31 Introducción al Proyecto 1.3 MOTIVACIÓN DEL PROYECTO La motivación de este proyecto surge de la necesidad de mejorar el rendimiento general de Internet. Con tal cantidad de información, a los usuarios les supone un esfuerzo cada vez mayor encontrar la información que realmente les interesa. La aplicación desarrollada ayuda a los propietarios de las páginas web a mejorar su situación en la red. Mediante el análisis y gestión de backlinks es posible saber qué contenidos de la página son los más solicitados por los usuarios, y esto ayuda a posicionar mejor los contenidos dentro de la web para las futuras búsquedas de otros usuarios con las mismas inquietudes. Esto supone una mejora general en la red: los contenidos son posicionados en los primeros resultados de los buscadores y con ello la sensación de eficiencia de los usuarios incrementa. Los usuarios son capaces de acceder a la información que les interesa en menos tiempo y con menor esfuerzo. Mediante la realización de estadísticas analizando los datos de los backlinks se consigue incrementar el rendimiento de la publicidad. Los webmasters obtienen información real de qué portales en los cuales se anuncian están siendo rentables. Actualmente las páginas web concentran una cantidad de publicidad que resulta molesta y apabullante para los usuarios. Todos los banners publicitarios y las ventanas emergentes tienen un coste para los anunciantes. Gran cantidad de empresas no se molestan en saber si con esos anuncios están consiguiendo visitas del público objetivo al que se dirigen, y en consecuencia no saben si está siendo rentable dicha inversión. Analizando las estadísticas obtenidas de los backlinks se puede determinar qué portales están aportando beneficios a la web y considerar si es pertinente o no realizar una mayor inversión, y cuáles son los anuncios que se deben eliminar debido a que generan pérdidas

32 Introducción al Proyecto Otro aspecto notable a tener en cuenta es la seguridad en Internet. Conforme Internet crece y avanza para mejorar la calidad de vida de los usuarios, los servidores web almacenan información personal cada vez más comprometedora de los clientes. La seguridad cobra mayor importancia, obligando a las empresas que obtienen información a realizar procedimientos de salvaguarda mediante leyes estatales. El ataque más devastador para un servidor web en la actualidad es el denominado DoS o DDoS. Su cometido es producir la denegación del servicio del servidor, realizando una gran cantidad de peticiones que saturan las comunicaciones del servicio. Gracias a las estadísticas obtenidas a través del análisis del protocolo HTTP es posible detectar los picos de rendimiento anómalos del servidor y bloquear el ataque antes de que comprometa la continuidad del servicio. La cantidad de lenguajes de programación, gestión de bases de datos, frameworks, servidores web y tipos de comunicaciones es muy extensa. Durante la carrera se han estudiado los conceptos más relevantes y de mayor uso. Para el desarrollo y puesta en marcha de la aplicación se ha utilizado tecnologías ya conocidas, en las que se ha podido profundizar, y otras muchas tecnologías punteras que han nacido hace relativamente poco tiempo y que amplía el conocimiento de la Ingeniería Informática

33 Introducción al Proyecto 1.4 OBJETIVOS El análisis y gestión de backlinks pretende facilitar la administración de cualquier página web mediante la generación de estadísticas de los accesos que se producen en tiempo real. Los objetivos principales del middleware a desarrollar son: o Poder explotar información del tráfico web entrante en tiempo real a una página o aplicación web. o Calcular automáticamente la relevancia a lo largo del tiempo de las distintas páginas de una web en función del número de links entrantes, así como el número de fuentes de las que proviene el tráfico. o Analizar la evolución del tráfico en cada instante gracias a la implementación de la tecnología COMET. o Conseguir un sistema de estadísticas escalable con escrituras de datos sobre el tráfico web en un sistema de base de datos de baja latencia denominado REDIS. o Detectar ataques de seguridad de denegación del servicio (DoS o DDoS) en tiempo real a través de gráficas que muestren situaciones anómalas de incremento del tráfico web. o Facilitar la gestión del administrador de un portal web gracias a sistemas automatizados de posicionamiento de datos y generación de gráficas a través de Google Visualization

34 Introducción al Proyecto o Permitir que herramientas de Business Intelligence sirvan para explotar la información estadística en tiempo real en diversos sectores: en tiendas online ofrecer descuentos automáticos según la demanda o ajustar los precios según los stocks; en portales web de contenidos posicionar en la portada o zonas preferentes los contenidos más transitados o tops de noticias; en el sector de la publicidad online incrementar o reducir la inversión según la respuesta de los usuarios

35 Introducción al Proyecto 1.5 METODOLOGÍA / SOLUCIÓN DESARROLLADA La metodología que se ha seguido durante el desarrollo del proyecto ha sido la metodología SCRUM. Se trata de un proceso utilizado en entornos basados en desarrollo ágil del software. Esta metodología combina características propias de los modelos iterativos e incrementales. El modelo divide el tiempo de desarrollo en sprints. Cada sprint tendrá una duración de 30 días como máximo y se centrará en unos requisitos concretos que se deberán finalizar en dicho sprint. En cada sprint se trabaja con dos documentos esenciales: o Product Backlog: en este documento se detallan todos los requerimientos y detalles globales del desarrollo. Aparecen todos los módulos y especificaciones a desarrollar durante el ciclo de vida de la aplicación. Las funciones de esta lista deben ser tangibles y cualquier usuario podrá ver la funcionalidad una vez finalizado el módulo. o Sprint Backlog: este documento contiene los requerimientos y objetivos a conseguir en cada sprint. El equipo de trabajo decide cuántos de los módulos que aparecen en el Product Backlog pueden realizarse en el tiempo que dura un sprint. Los requerimientos se subdividen en tareas de 4 a 16 horas y deben producir un producto potencialmente usable. Esto permite seguir de forma clara los avances de las tareas programadas

36 Introducción al Proyecto La operativa de cada sprint es la siguiente: o Se desarrolla una reunión al comienzo de cada sprint en la cual se define el documento Sprint Backlog. o Cada día se realiza un test de no más de 15 minutos en el que se pone de manifiesto qué se ha conseguido y que se va a realizar. Se debe actualizar el Sprint Backlog y el diagrama de quemado (Burn Down Chart). o Se realizan reuniones informativas en las que se revisa el sprint finalizado y se realiza una retrospectiva de los problemas y forma de trabajar. o Se presenta el siguiente sprint volviendo a visualizar el Product Backlog. En la imagen 1 se muestra un ejemplo de la planificación de un sprint. Imagen 1 - Esquema de un Sprint

37 Introducción al Proyecto El diagrama de quemado o Burn Down Chart es una gráfica en la que se reflejan las tareas pendientes por hacer del Product Backlog al principio de cada Sprint. En ella se representan las tareas finalizadas, el esfuerzo remanente y las tareas pendientes. La línea que conecta los puntos de los sprints completados será descendente, excepto cuando se añada funcionalidad nueva, lo cual producirá picos ascendentes. En la imagen 2 se muestra un ejemplo de diagrama de quemado. Imagen 2 - Ejemplo de Burn Down Chart Las principales características de esta metodología son: o Proceso iterativo e incremental. o Focalización en desarrollar lo comprometido. o Importancia del desarrollo frente a la documentación

38 Introducción al Proyecto o Transparencia y visibilidad del proyecto. o Seguimiento constante de objetivos y requisitos. o Autogestión de las responsabilidades. Se ha decidido utilizar la metodología SCRUM frente a otras como por ejemplo el ciclo de vida en espiral, en cascada, iterativa o incremental debido a que reúne las mejores características de cada una de ellas. Es fácil de implantar y no se dedica mucho tiempo a documentar todos los procesos de gestión y desarrollo del proyecto. Una de las características que ha llevado a priorizar esta metodología es la sencillez que resulta implementar nuevas funcionalidades a la aplicación. El cliente, en este caso el Director del Proyecto, es capaz de añadir nuevas tareas o modificar algunos de los requisitos iniciales sin que se produzcan variaciones desmesuradas en la planificación del proyecto

39 Introducción al Proyecto 1.6 RECURSOS / HERRAMIENTAS EMPLEADAS En este capítulo se van a describir los recursos hardware y las herramientas software que se han utilizado para desarrollar la aplicación y su posterior puesta en marcha RECURSOS HARDWARE Para el desarrollo de la aplicación se ha trabajado con dos ordenadores y un servidor web: Ordenador portátil TOSHIBA SATELLITE A-110: Procesador: Intel CPU T2050 1,6 GHz. Velocidad del BUS: 800 MHz. Memoria RAM: 2 GB DDR2. Tarjeta Gráfica: Sapphire Radeon HD GB GDDR2. Disco Duro: 200 GB conexión SATA. Sistema Operativo: Windows XP Service Pack

40 Introducción al Proyecto Ordenador de sobremesa HP Serie G5200 Procesador: Intel Pentium E5500 2,8 GHz. Chipset: Intel G41 Express. Memoria RAM: 3 GB DDR3. Tarjeta Gráfica: Intel Graphics X4500HD. Disco Duro: 540 GB conexión SATA. Sistema Operativo: Windows 7 Home Premium 64 bits. Servidor WEB Linux: Procesador: Intel Core2Quad Q9300. Memoria RAM: 8 GB DDR2. Disco Duro: 750 GB conexión SATA. Ancho de Banda: GB. Uplink Port Speed 100 MB/sec. Sistema Operativo: Ubuntu Hardy 64 bits. 8 Direcciones IP

41 Introducción al Proyecto RECURSOS SOFTWARE El software y tecnologías utilizadas para el desarrollo de la aplicación han sido: Python: Lenguaje de programación de alto nivel con una sintaxis muy limpia que soporta orientación a objetos y se ejecuta por medio de un intérprete. Django: Framework escrito en Python que cumple el modelo vista controlador (MVC). Facilita el desarrollo de páginas web complejas y soporta bases de datos PostgreSQL, MySQL, Oracle o SQLite. Redis: Base de datos no relacional que tiene únicamente los campos clavevalor. Es como una tabla hash de grandes dimensiones especialmente rápida. Comet: Tecnología de comunicación asíncrona que mantiene abierto un canal de comunicación entre el cliente y el servidor, siendo el servidor el que avisa al cliente cuando ocurre un evento. NginX: Servidor en etapa beta con una configuración muy simple, con una alta escalabilidad y un bajo consumo de recursos. Google Visualization API: Interfaz de programación que permite realizar gráficos en formato JavaScript o FLASH. Los datos relevantes obtenidos de los backlinks serán enviados a Google Visualization para que realice las gráficas deseadas. Las tecnologías mencionadas anteriormente serán descritas detalladamente en el Capítulo 3 Arquitectura del Proyecto

42 Estado del Arte Capítulo 2 ESTADO DEL ARTE

43 Estado del Arte 2.1 INTRODUCCIÓN Para realizar el desarrollo del proyecto y que la aplicación tuviera éxito se ha tenido que estudiar la evolución de las tecnologías de Internet. El análisis de backlinks es una tarea que está en constante cambio debido a que las tecnologías en Internet se actualizan frecuentemente. Para conocer el alcance de la aplicación primero se debe investigar cómo funcionan las comunicaciones en la red. Cuando apareció la web, se trataba de un portal de información donde el contenido era estático, sufría pocas actualizaciones y la interacción con el usuario era prácticamente nula. Actualmente la red se caracteriza por la gran interacción que ofrece con el usuario. Los cibernautas son capaces de realizar casi cualquier actividad relacionada con aplicaciones de escritorio sin tener que instalar el paquete software necesario. Se trabaja en la burbuja de Internet, servicios que ofrecen los portales web para que los usuarios puedan trabajar desde cualquier dispositivo sin poseer el software. Los usuarios ya no sólo obtienen información, sino que actualizan y crean nueva información en las páginas web. A partir de considerar a Internet desde una perspectiva de recibir información a una perspectiva de interactuar con el usuario, se debe analizar la evolución de los buscadores, el aumento de la publicidad, la criticidad de la seguridad, las nuevas tecnologías incorporadas y otros aspectos que se describirán en este capítulo

44 Estado del Arte 2.2 EVOLUCIÓN DE LA WEB: WEB 2.0 La Web 2.0 representa la evolución que ha sufrido la web tradicional con el paso de los años. Se trata de un nuevo enfoque, dar prioridad al usuario final con aplicaciones web que facilitan la colaboración y el compartir información. Se intenta dar servicios en los portales web que reemplacen las aplicaciones de escritorio. La web en sus comienzos era un trozo de código en lenguaje HTML estático con información que no se actualizaba con frecuencia y la interacción con el usuario era mínima. Poco a poco, como cualquier servicio, los desarrolladores web se dieron cuenta de que lo realmente importante era establecer una comunicación continua con el usuario, que el usuario se sintiera parte de la web pudiendo comentar, criticar, votar e incluso que la web dependiera de sus conocimientos. El término Web 2.0 no es una tecnología en sí, es un conjunto de aplicaciones y páginas en Internet que utilizan la inteligencia colectiva para proporcionar servicios y aplicaciones interactivas donde el usuario controla los datos. Los usuarios son capaces de ubicar los contenidos de una web en diferentes lugares de su pantalla o decidir cuáles de los contenidos quieren que se muestren. La web también es inteligente, según el modo de uso de un usuario es capaz de seleccionar preferencias, ocultar datos y mostrar recomendaciones. La novedad de la versión 2.0 viene determinada por los nuevos usos y comunicaciones que aparecen como consecuencia de la referencia entre bases de datos a otros nuevos datos, llamados metadatos. Los metadatos son asociaciones de datos que hablan o referencian a otros datos. Estos proporcionan datos del tipo identificación, descripción, recuperación y organización. Esta información

45 Estado del Arte permite realizar múltiples funciones y son utilizadas en buscadores, portales personales, espacios virtuales, generación de nuevas bases de datos, redes sociales y portales internos. Las grandes bases de datos multimedia necesitan hacer uso de los metadatos para gestionar enormes volúmenes de información y resolver las peticiones con la mayor rapidez posible. La manera en la que los usuarios deciden etiquetar sus contenidos para que sea más sencillo que el resto de usuarios encuentren la información a través de buscadores se llama folksonomía. Los usuarios colaboran con la red de una manera que beneficia a todos: a los gestores de búsquedas para encontrar la información más rápida y a los usuarios para encontrar los contenidos eficazmente. La folksonomía es una manera de que la información de la red esté categorizada y ordenada de forma gratuita y sin necesidad de grandes gestores ni conocimientos. Se tiene en YouTube un ejemplo de web que utiliza las folksonomías. Cuando un usuario introduce un vídeo a YouTube se le da la oportunidad de introducir una serie de etiquetas con las que cualquier usuario que busque por esas palabras clave se le indexe a ese video, entre otros. Al introducir en el buscador de YouTube la palabra google le aparecerán cientos de resultados. Se puede comprobar que accediendo a uno de estos enlaces, si se consultan las etiquetas que contiene el video aparecerá dicha palabra clave. Consultando estas etiquetas se puede ayudar al usuario a concretar la búsqueda con términos relacionados

46 Estado del Arte Imagen 3 - Ejemplo de folksonomía Por otro lado, la Web 2.0 ha cambiado la tradicional tecnología pull. Esta tecnología describe el comportamiento que realiza la red ante el usuario: es el cibernauta el que demanda la información y el sistema sirve los contenidos solicitados. Pero, con el uso de los metadatos, el modo de actuar de Internet es a través de la tecnología push: es el sistema el que se encarga de despachar la información que piense que es interesante para el usuario. El sistema toma la iniciativa y muestra los contenidos según las preferencias del consumidor. Esta tecnología se implementa en las llamadas RSS (Rich Site Summary) utilizadas en los weblogs. Un RSS es un documento que contiene los metadatos de una página web concreta. En él se resume la información a la que representa, el enlace y el título. Cuando

47 Estado del Arte esta información sufre cambios el usuario es avisado a través de un programa denominado lector de feeds de RSS. El usuario ya no tiene que acceder a todas sus páginas favoritas para observar si se han publicado nuevas noticias o se han actualizado algunos contenidos. Los lectores de RSS avisan al cliente cuando se producen cambios, por lo que resulta más eficiente el tiempo dedicado a Internet por los usuarios. Actualmente existen lectores de RSS incorporados a los navegadores, por lo que no es necesario tener instalado un programa complementario. La tecnología push gana cada vez más terreno en la red en la medida que agrada a los usuarios al conocer de una manera más certera sus preferencias. Imagen 4 - Lectores de feeds de RSS Existen tecnologías que se utilizan actualmente para que las web evolucionen a la versión 2.0, pero no son una ciencia exacta. Cada webmaster utiliza la que cree más conveniente en su web para seguir innovando y estrechando las relaciones con los usuarios de la red

48 Estado del Arte Las tecnologías o aspectos más representativos son: o Introducir el modelo de aplicación de escritorio al modelo de aplicación web. o Utilizar el estándar XHTML. o Separación de la capa de diseño de la capa de contenido mediante la utilización de hojas de estilo (CSS). o Utilizar tecnología AJAX para la representación de contenidos asíncronos. o Utilizar tecnologías SEO para el posicionamiento de páginas web. o Liberar APIs o XML para que los usuarios puedan modificar las aplicaciones. o Dar control total a los usuarios en el manejo de su información. o Usar FLASH o FLEX en contenidos multimedia siempre que no comprometa la accesibilidad. o Sindicar contenidos para que los usuarios puedan manejar las aplicaciones RSS. o Usar lenguajes de programación que ayuden a crear webs dinámicas, como Python o Ruby. En la siguiente imagen se muestra un ejemplo de una manera gráfica los cambios producidos de la web 1.0 a una posible web

49 Estado del Arte Imagen 5 - Cambios en la Web 1.0 (fuente: blog.aysoon.com) En la Web 1.0 se observa como el webmaster genera y actualiza los contenidos de la web. Los usuarios de Internet acceden a la web y ven los contenidos, pero no son capaces de interactuar con la información y los datos. En cambio, en la imagen de la Web 2.0 además del webmaster, los usuarios de la web tienen la opción de contribuir con información. La web se enriquece de conocimientos y la responsabilidad del webmaster es permitir la mayor accesibilidad posible a los usuarios para que la página crezca, se actualice y tenga éxito. Todo usuario que lo desee será informado de las actualizaciones a través de los lectores de feeds de RSS para así no depender constantemente de una tecnología pull que obliga al usuario a acercarse a la web, sino de una tecnología push que acerca los contenidos a los consumidores. Para la realización de este proyecto se debe tener en cuenta todos los cambios producidos en el diseño y desarrollo de las nuevas páginas web 2.0. Al fin y al

50 Estado del Arte cabo todo se referencia mediante enlaces y mucha de la información de los usuarios se encuentra almacenada en los protocolos de los backlinks. Con el uso de las etiquetas, de la selección de contenidos por preferencias de los usuarios, los feeds o RSS, las tecnologías push dinámicas, las bases de datos enlazadas, los metadatos, se debe determinar el alcance de los enlaces que aumentará la cantidad de información que poseen. Para finalizar con este apartado, se puede observar la imagen 6 que contempla la evolución de la web pasada y las posibles web futuras con sus nuevas versiones. Imagen 6 - Futuro de la Web (fuente: radarnetworks.com) En las siguientes versiones que están por llegar, las bases de datos serán completamente semánticas, las búsquedas serán distribuidas y las páginas tendrán agentes personales que distribuirán totalmente la web de forma inteligente según el perfil del usuario

51 Estado del Arte 2.3 EVOLUCIÓN DE LOS BUSCADORES Un buscador o browser es una herramienta capaz de encontrar archivos almacenados en servidores web o servidores FTP. Los primeros buscadores datan a principio de los años 90. Estos buscadores utilizaban la tecnología Web Crawler que actualmente sigue siendo la tecnología usada por los principales buscadores de Internet, llamados buscadores jerárquicos. La tecnología Web Crawler inspecciona las páginas de la red de forma automatizada consultando una lista de URLs e identificando los hiperenlaces que se encuentran en las páginas. Los hiperenlaces los introduce en la lista de URLs y vuelve a realizar el mismo proceso. De esta manera va recorriendo la red visitando cada link que encuentra a su paso. A partir de aquí, se va recopilando información y creando nuevas listas o catálogos en base a un conjunto de reglas parseando las webs analizadas. Dado que la información en la red es de proporciones gigantescas, una única crawler no es capaz de analizar todos los enlaces. Se estima que una crawler es capaz de analizar un 15% de Internet. Por ello se especializar en diversas áreas y temáticas. Existen Crawlers que se dedican únicamente a recopilar imágenes, otras se dedican a enlaces, texto Posteriormente van procesando la información almacenada para mostrar los resultados pedidos por el usuario, como por ejemplo una resolución de imagen determinada

52 Estado del Arte Imagen 7 - Logotipos de algunos buscadores jerárquicos. El problema que surge de estos buscadores jerárquicos es que deben actualizar sus listados URL cada cierto tiempo. La información cambia en las webs y algunas páginas desaparecen o dan de baja los contenidos, por lo que los resultados de las búsquedas pueden estar obsoletos. Actualmente se trabaja en otros tres tipos de buscadores: Buscadores verticales de universo limitado: son buscadores especializados en áreas temáticas, en pequeños nichos de la red los que les facilita el acceso a la información de manera simplificada. Estos buscadores permiten a los usuarios encontrar resultados con contenido relevante sin demasiado volumen de información. Buscadores basados en conocimiento simbólico: utilizan teorías de la computabilidad y lógica matemática e intentan dar una única respuesta pero rica en detalle. Se encuentran a medio camino entre la web Wikipedia

53 Estado del Arte y los buscadores jerárquicos. Un ejemplo de este tipo de buscadores se encuentra en Wolfram ( Buscadores de información procedente de diálogos: es el tipo de buscador más novedoso. Estos buscadores analizan la información generada en los diálogos que se producen en la red en tiempo real. Por ejemplo, pueden buscar información que se estén comentando en redes sociales como Facebook, Tuenti, Twitter, Flickr Esta tecnología se encuentra en etapa beta, pero puede llegar a ser muy importante debido al auge actual de las redes sociales. Las tecnologías de los buscadores son un tema muy importante de analizar porque pueden tener un gran impacto en la aplicación. Los buscadores son la fuente de enlaces por excelencia. Los buscadores jerárquicos crean sus listados analizando los links que encuentran en la red. Cualquier cambio de tendencia implicaría realizar un nuevo desarrollo de la gestión de backlinks para poder obtener información detallada de los perfiles de los usuarios, desde qué portales acceden y cuál es su ubicación

54 Estado del Arte 2.4 POSICIONAMIENTO EN INTERNET El posicionamiento web, también llamado SEO (Search Engine Optimization) es el proceso de mejorar el volumen o calidad de tráfico a un sitio web desde los motores de búsqueda como Google, Yahoo! o Bing mediante resultados de búsqueda naturales, sin pagar u orgánicos. El uso de una serie de técnicas tiene como objetivo aparecer en los primeros resultados de los buscadores. La técnica complementaria al SEO es el Search Engine Marketing o SEM, que utilizan medios de pago para poder posicionar sus enlaces en las primeras posiciones de los motores de búsqueda. Se tratan de enlaces patrocinados que los buscadores incorporan a los resultados cuando el usuario introduce ciertas palabras clave que el patrocinador ha seleccionado y pagado por ello. Estos enlaces patrocinados se facturan por cada clic recibido por los usuarios, usando la técnica Coste por clic (CPC). En la imagen 8 se puede observar los contenidos posicionados con tecnologías SEO y con tecnologías SEM en el motor de búsqueda Google. El objetivo del análisis de backlinks es conseguir posicionar a la web en la zona destinada a SEO, sin necesidad de invertir capital para conseguirlo

55 Estado del Arte Imagen 8- Posición de tecnologías SEO y SEM en Google. La aplicación de técnicas SEO es un trabajo que implica al código de programación, de diseño y de contenidos. Los resultados obtenidos con estas técnicas alteran a la efectividad de los buscadores, por lo que existen condiciones de uso en las páginas web para no obtener mejores resultados realizando pequeñas trampas. Los motores de búsqueda analizan las webs para encontrar ciertos engaños y penalizan a las webs que los contienen, clasificándolos como spam o spamdexing. Para mejorar el posicionamiento de una página se siguen una serie de consejos o actividades descritas a continuación: o Creación de backlinks en páginas de temática relacionada que enlacen a la web a posicionar

56 Estado del Arte o Registro en directorios notables como Yahoo!, Furl, Páginas Amarillas o Dmoz. Estos directorios son gestionados por humanos, al contrario que los listados de árboles jerárquicos, por lo que se obtiene una mayor calidad de contenido pero de forma más lenta. o Presencia en foros: se debe dar prioridad a foros de temática similar, participando en las noticias o comentarios, añadiendo al final un alias con el link a la página web. Cuanto mayor sea la calidad del contenido aportado a los foros, mayor será el número de visitas y los buscadores le darán credibilidad a esos backlinks. o Participar en redes sociales: sitios como Myspace, Facebook, H5, Twitter son medios sencillos para obtener visitas a la web. Google da mucha importancia a los enlaces que encuentra en estas redes sociales para mejorar el posicionamiento. o Escribir artículos en portales web. Los artículos ayudan al posicionamiento y a aumentar el número de visitas. o Dar prioridad a la accesibilidad de la web. Los contenidos en Flash, JavaScript o Frames no permiten el rastreo por parte de los buscadores automáticos o crawlers. Estos contenidos son vistos como un espacio plano por el cual no se puede navegar, por lo que hay que evitarlos en la medida de lo posible. o Los títulos, descripciones y URIs son importantes para los buscadores. Lo primero que observan los motores de búsqueda son las palabras clave que

57 Estado del Arte se encuentran en estos apartados para posicionar la página. Los títulos no deben de tener más de 80 caracteres. o Los buscadores analizan la página web. Por eso hay que crear contenidos con frases en las que se indique qué servicios o productos ofrece la página y en qué le puede ayudar al cibernauta. o Crear un mapa ordenado en la propia página web. Cuando un buscador entre en la web, si se quiere que recorra todos los contenidos se deben enlazar a través de backlinks internos para que los robots automáticos localicen toda la información posible. El número de enlaces dentro de la web no debe ser superior a 100. Si esto fuera así, un buscador catalogaría la web como un portal de enlaces y lo penalizaría. o Evitar los enlaces a páginas web contenedoras de enlaces, spam, web sobre hacking, pornografía, técnicas malware y portales fraudulentos. Los portales que tengan contenido ilegal o poco ético son criticados y censurados por los buscadores. o Optimizar el rendimiento de la página web. La velocidad de carga de una web es importante para los buscadores. Hay que analizar la carga del servidor y el código HTML. Los contenidos multimedia pueden ser muy pesados, por lo que hay que evitarlos o comprimir las imágenes con gzip. o Utilizar el archivo robots.txt para controlar que las arañas (crawlers) de los motores de búsqueda indexen los contenidos de la página. Este documento puede permitir o denegar el acceso de los buscadores a los directorios que se desee

58 Estado del Arte A continuación se muestra en la imagen 9 con los contenidos SEO más representativos que debe incluir una web para un mejor posicionamiento en los principales motores de búsqueda. Imagen 9- Principales contenidos SEO en una página web (fuente: La aplicación desarrollada permitirá un mejor posicionamiento de las páginas web, analizando y gestionando los backlinks. Observando los backlinks desde los que se accede a la web es posible determinar qué contenidos son los más demandados por los usuarios. Mediante la aplicación de técnicas SEO al código y a los contenidos se puede cambiar la ubicación de los contenidos más concurridos para posicionarlo en zonas estratégicas de la web e insertarle nuevas palabras clave en su título y descripción para que los motores de búsqueda lo tomen como referencia y vaya escalando puestos en los resultados mostrados a los usuarios

59 Estado del Arte TEORÍA DEL LONG TAIL Posicionar palabras tan genéricas como dinero, ahorro, cine, amor o salud es una tarea imposible en la actualidad. Los resultados por cualquiera de estas palabras clave son de millones. Una página web sólo podrá posicionarse utilizando términos menores pero más concretos. La Ley de Pareto del 80/20 se puede extrapolar a las técnicas SEO. Esta Ley enuncia que el 80% de los beneficios lo aporta el 20% de los clientes de una empresa. En técnicas SEO se puede declarar que el 20% de las visitas proviene de usuarios con palabras clave de 1 a 3 términos. El resto de visitas (80%) proviene de usuarios que han utilizado más de 3 keywords. El coste de posicionarse de 1 a 3 palabras clave es muy alto debido a que existe una gran competencia. La Teoría de Long Tail recomienda utilizar 4 o más palabras para posicionarse, ya que suelen tener un retorno de la inversión (ROI) bastante mayor que pocos términos específicos. Un gran número de palabras clave generan más entradas a la web que las palabras clave principales. Las cadenas de búsqueda más largas producen resultados más segmentados y tanto los anunciantes como los usuarios lo empiezan a utilizar para enfocarse en lo que realmente les interesa. Los usuarios tienen más conocimientos y son capaces de realizar nuevas búsquedas más efectivas. En la imagen 10 se puede observar, haciendo referencia a la teoría del Long Tail, la competitividad y el coste asociado según los términos empleados para posicionar una página web. Cuando se intenta posicionar una única palabra, la competitividad de las agencias de publicidad es muy alta y el coste es muy alto. A

60 Estado del Arte medida que se posicionan más palabras clave juntas, la competitividad empieza a disminuir, hasta llegar a un punto de baja competitividad, donde los usuarios realizan una búsqueda más enfocada a lo que desean encontrar. Imagen 10- Competitividad y coste según las keywords (fuente: Mediante el análisis de backlinks es posible saber qué palabras clave están atrayendo a los usuarios, por lo que se puede aumentar la inversión en las palabras clave que sean efectivas y retirar las que no estén ayudando a atraer a usuarios interesados en la página

61 Estado del Arte 2.5 SEGURIDAD DE LA RED La década de los 90 fue el auge de los virus de propagación en Internet y sigue causando estragos actualmente. Grandes corporaciones se dedican a analizar los virus y detener su propagación por la red a través de antivirus y firewalls. Por medio de este software, las repercusiones de los ataques de antivirus producen cada vez menos impacto en los sistemas informáticos. A partir del año 2000 empezaron a surgir nuevas técnicas de spyware y phishing, cuyos objetivos son las suplantaciones de identidad. Son unos recursos de difícil detección y para contrarrestarlos se han creado nuevas tecnologías de cifrado y autenticación de identidad con certificados digitales para que los usuarios estén seguros a la hora de realizar operaciones importantes a través de Internet, como compras online, transferencias bancarias o envío de datos confidenciales. En la actualidad, los ataques que están produciendo quebraderos de cabeza a pequeñas y grandes empresas son los ataques DoS (Denial of Service) y DDoS (Distributed Denial of Service). Estos ataques producen la denegación del servicio del servidor atacado, produciendo la inaccesibilidad de todo usuario de la red al recurso web. La diferencia entre estos dos ataques radica en que el ataque DoS se suele realizar a través de un único equipo hardware, mientras que el ataque DDoS se realiza de manera conjunta con varios equipos que pueden ser infectados de manera que actúen como zombis sin que los propietarios conozcan la situación. Un ataque DDoS tiene como objetivo consumir el ancho de banda para colapsar los puertos de un servidor, provocando la saturación del mismo y denegando el acceso a los siguientes usuarios legítimos. La infraestructura que se suele utilizar en un ataque DDoS se denomina botnet

62 Estado del Arte La infraestructura botnet se compone de uno o varios usuarios atacantes que contaminan a otros ordenadores que no son de su propiedad para que actúen a favor de sus intenciones en un momento determinado. Estos ordenadores contaminados de denominan zombis, ya que actúan realizando una serie de actividades sin que el propietario sea consciente de ello. Todos los ordenadores son coordinados por servidores para que se realice un ataque de manera conjunta a un portal determinado. La clave de que un ataque sea efectivo es realizando infinitud de peticiones constantes durante un plazo corto de tiempo. De esta manera el servidor no es capaz de servir las respuestas a tiempo, llegando a un punto de saturación donde deniega el servicio a cualquier posible cliente. Imagen 11 - Infraestructura de un botnet. Las configuraciones botnets suelen trabajar a nivel de red TCP/IP pero, en sus últimos ataques, se están dando casos de comunicación a nivel de aplicación HTTP que provoca que sean más efectivos

63 Estado del Arte Uno de los últimos botnets, denominado TDL-4, se estima que ha infectado 4.5 millones de ordenadores para que actúen como zombis. Para Kaspersky, una de las mayores empresas de seguridad informática, es un botnet muy complejo y de difícil eliminación, que ha mejorado los algoritmos de cifrado de protocolos de comunicación para ser apenas detectable. La botnet está configurada para que arranque antes que el propio sistema operativo y se mantiene alejada de los programas malware que puedan perjudicarle. Con el caso del TDL-4 es posible hacerse una idea de la magnitud del problema de los ataques DDoS: ataques masivos, muy complejos, con comunicaciones cifradas y operando desde cualquier ubicación de la red sin que la mayoría de los atacantes sepan que lo están llevando a cabo. Imagen 12 - Ataque DDoS con ordenadores zombis

64 Estado del Arte Existen tres tipos de ataques DoS o DDoS utilizados actualmente para provocar la denegación de servicio de un servidor web: o Método de inundación por SYN (SYN Flood): uno o varios atacantes envían una serie de peticiones SYN al servidor hasta producir su saturación. Funciona bajo el protocolo TCP/IP. Cuando un usuario desea conectarse con un servidor, realiza una petición SYN. El servidor, en caso de aceptar la conexión, envía al usuario una respuesta SYN/ACK y se queda a la espera de recibir un ACK del usuario. En cuanto recibe el ACK del usuario, la conexión se da por aceptada. Imagen 13 - Petición de conexión SYN/ACK. Cuando se utiliza este ataque DoS o DDoS, los usuarios atacantes realizan muchas peticiones SYN cambiando el campo de dirección origen del protocolo TCP. De este modo, cuando el servidor responde

65 Estado del Arte con el mensaje SYN/ACK se mantiene esperando la respuesta ACK. Como la dirección origen no es verdadera, el mensaje no llega nunca y el servidor permanece consumiendo recursos y saturando el número de conexiones máximas, provocando la caída del sistema y su posterior denegación de servicio. o Método de inundación ICMP: mediante este método se intenta saturar el ancho de banda del servidor. Un atacante realiza un envío masivo de peticiones con el protocolo de control ICMP utilizando el atributo petición y respuesta de eco de un tamaño considerable. Cuando un servidor recibe este atributo, contesta con el mismo mensaje para informar de que está operativo y disponible. El problema surge si se realizan demasiadas peticiones de eco, lo que provoca una saturación de la red con tal cantidad de datagramas circulando desde y hacia el servidor. Imagen 14 - Campos del protocolo ICMP. o Método de inundación UDP: este método trabaja bajo el protocolo UDP/IP, se trata de un protocolo que no requiere conexión entre el usuario y el servidor. Para llevar a cabo este ataque, el usuario atacante establece la comunicación entre el servicio chargen propio y el servicio echo del servidor. El servicio chargen genera paquetes y los envía al servicio echo, el cuál reenvía los paquetes que recibe. Cuando el atacante envía paquetes, cambia los campos de dirección y

66 Estado del Arte puerto de origen. A consecuencia de esto, el servicio chargen del servidor reenvía paquetes de información a destinos no conocidos. Cuando se producen muchas peticiones, el ancho de banda se satura, provocando la denegación de servicio. Esta técnica es capaz de consumir el ancho de banda de una red entera debido a la cantidad ingente de paquetes que pueden ser enviados de unos ordenadores a otros. La aplicación que gestiona y analiza backlinks será capaz de desenmascarar los campos del protocolo HTTP y TCP/IP para obtener estadísticas relacionadas con los accesos y poder descubrir posibles intentos de ataques DoS o DDoS. Los campos relevantes serán seleccionados y enviados a la base de datos REDIS. Las estadísticas se generarán en tiempo real para que un administrador sea capaz de bloquear estos ataques antes de que la continuidad del servidor se vea comprometida. Google Visualization enviará las gráficas a la capa middleware en un breve espacio de tiempo para que el administrador sea capaz de analizar de forma rápida y eficaz los posibles violaciones de seguridad del portal

67 Arquitectura del Proyecto Capítulo 3 ARQUITECTURA DEL PROYECTO

68 Arquitectura del Proyecto 3.1 INTRODUCCIÓN En este capítulo se realizan las investigaciones necesarias para que el proyecto tenga éxito. Antes de comenzar a desarrollar la aplicación hay que analizar todas las tecnologías que se deben implantar para cumplir los objetivos y requisitos que va a incorporar la aplicación. Siempre que existan varias soluciones que satisfacen la arquitectura de la aplicación, se debe seleccionar la que proporcione un resultado óptimo, sea lo más sencilla posible y su estabilidad y escalabilidad ofrezcan los mejores rendimientos. La forma más idónea a la selección de alternativas es realizar una comparativa técnica por el método del Benchmarking. Con este método se enfrentan unas tecnologías con otras similares con el propósito de facilitar la selección de la herramienta o tecnología más adecuada para el proyecto. No sólo hay que comparar las especificaciones técnicas, sino que entran otros factores como la complejidad y el coste del uso de dichas tecnologías. En este proyecto prevalece el software libre sobre las herramientas que imponen comprar licencias de desarrollo y distribución

69 Arquitectura del Proyecto 3.2 SELECCIÓN DEL LENGUAJE DE PROGRAMACIÓN Para empezar a desarrollar el proyecto lo primero que se debe decidir es en qué lenguaje se va a programar el código fuente que sustente a la aplicación. Es una de las decisiones más importantes ya que la calidad del software final se verá afectada por el mismo. Los factores más relevantes a la hora de decidir qué lenguaje de programación utilizar son la capacidad de los algoritmos (lenguajes de alto nivel vs lenguajes de bajo nivel), el acoplamiento y cohesión del código, la facilidad de cooperación con otras tecnologías, la dificultad del desarrollo, el mantenimiento, la madurez del lenguaje y la calidad del código fuente final. El uso de lenguajes de alto nivel para desarrollos web es lo más recomendable en la actualidad, debido a la facilidad de las sentencias y los algoritmos, pensado en plasmar el código para que lo entiendan e interpreten antes las personas que los ordenadores. De esta manera se consigue que los desarrolladores vean de manera clara qué está realizando el código, y no cómo lo está procesando la CPU internamente. Las sentencias de alto nivel se caracterizan por ser muy sencillas; una línea de código escrita por un programador puede convertirse fácilmente en 10 instrucciones de bajo nivel, por lo que el código fuente de un desarrollo web es bastante menos extenso que el código de desarrollos de antaño realizados en lenguajes de bajo nivel

70 Arquitectura del Proyecto Existe una gran variedad de lenguajes de alto nivel: C#, Pearl, PHP, ADA, Fortran, Java Para este análisis se han seleccionado tres lenguajes que actualmente están siendo muy demandados en proyectos web, por su alta velocidad de desarrollo e interpretación, calidad de la documentación y facilidad de obtener soporte en entornos de desarrolladores de código libre. Los lenguajes seleccionados son Python, PHP y Ruby. A continuación se va a realizar un análisis de los tres lenguajes atendiendo a aspectos funcionales para valorar qué lenguaje es el más apropiado para el desarrollo de la aplicación. o Nivel de los algoritmos: Los lenguajes de programación basados en algoritmos de alto nivel se aproximan al lenguaje natural, logrando independencia de las máquinas que lo compilan y ejecutan. Cuanto más alto sea el nivel del lenguaje, mayor será el mantenimiento del código, será más sencillo encontrar errores y el tiempo de desarrollo disminuye considerablemente al contener en pocas líneas de código, gran cantidad de sentencias de código máquina una vez compilado por el sistema. Los costes de desarrollo disminuyen proporcionalmente con respecto a la complejidad interna de cada línea de código programada. o Complejidad de la sintaxis: Este apartado permite evaluar la capacidad necesaria de un programador para poder desarrollar un producto con un lenguaje de programación. Cuanto mayor es la complejidad de la sintaxis, los programadores deben estar más especializados en el código que desarrollan. Trabajar con sintaxis complejas implica un mayor coste de aprendizaje, pero también ofrece mejores implementaciones debido a que es posible trabajar a un menor nivel de programación que permite adaptar el código a especificaciones más internas sobre rendimiento, como, por

71 Arquitectura del Proyecto ejemplo, manejar registros cercanos a las ALU s o direcciones de memoria. En este proyecto prima la simplicidad del código, la fácil implementación, mantenimiento y reusabilidad. Cuanto menor sea la complejidad, menor será el coste de desarrollo. o Lenguaje orientado a objetos: La programación orientada a objetos, llamada comúnmente POO, se distingue por utilizar conexiones entre objetos creados a partir de clases con propiedades importantes sobre rendimiento y limpieza de código. Esta programación utiliza paradigmas tales como la herencia, el encapsulamiento, la abstracción, los eventos o el polimorfismo (redefinición de métodos). Los objetos se caracterizan por tener un estado, un comportamiento y un identificador ayudados por sus métodos, sus atributos, y sus constantes. Mediante el uso de métodos definidos en las APIs de los lenguajes es posible conectar objetos de diferentes lenguajes para que trabajen de forma común en diferentes funcionalidades de la aplicación. o Calidad y cantidad de librerías: Las librerías que incluyen los lenguajes de programación son trozos de código que realizan una funcionalidad específica. Estas librerías ayudan a los programadores a realizar partes de los requerimientos de la aplicación sin tener que empezar a desarrollar desde cero. Las librerías son utilizadas y mejoradas por los programadores, que las implementan en sus códigos y las modifican para adaptarlas a ciertos comportamientos. Un lenguaje que incorpore muchas librerías de calidad reduce el tiempo de desarrollo y permiten el concepto de caja negra mediante el cual un programador no se preocupa del código interno, sino del uso de las funciones internas identificando los parámetros de entrada y los resultados que se obtienen

72 Arquitectura del Proyecto o Madurez del lenguaje: Cuando un lenguaje es de reciente aparición se considera poco estable debido a la cantidad de errores y bugs internos que se pueden producir. Con el paso de los años se van corrigiendo los errores de código y compilación, aparecen nuevas versiones y el lenguaje puede definirse como estable. Es normal que muchos métodos se determinen como obsoletos cuando otros desarrolladores creen nuevos métodos que mejoren el rendimiento y produzcan salidas óptimas. La madurez del lenguaje es una característica importante a tener en cuenta en la elección del lenguaje con el que se va a desarrollar la aplicación a causa de un mejor mantenimiento, gestión de errores y soporte de la comunidad de desarrolladores. o Patrón MVC: El patrón de diseño Modelo-Vista-Controlador (MVC) describe la organización del código de una aplicación separando la funcionalidad por diferentes capas: la capa de datos, la capa de control y la capa de diseño. Se trata de un modelo que simplifica el desarrollo, ayuda al mantenimiento y al control de los eventos y accesos al código. La separación en capas permite realizar modificaciones en cualquiera de ellas sin que afecten al resto. Cualquier programador puede mejorar o corregir uno de los componentes sin saber cómo funcionan los demás con lo que se consigue que un programador no necesite grandes conocimientos de toda la aplicación, sino de la parte del código específico que se desea modificar

73 Arquitectura del Proyecto Imagen 15- Patrón de diseño MVC. En la imagen 15 se distinguen tres capas dentro de la aplicación web. La capa Modelo incluye las clases DAO (Data Access Object). Son las clases que permiten la comunicación con las bases de datos que interaccionen con la aplicación. La capa Control contiene el código propio de la aplicación que permite controlar el acceso a métodos, configuraciones internas, recibe eventos y modifica a la capa Vista y Modelo. La capa Vista se encarga de la interfaz que observan los usuarios durante la navegación. Controla los estilos utilizados, las personalizaciones de las ventanas, la navegación entre pantallas y el comportamiento ante situaciones indeseadas

74 Arquitectura del Proyecto A continuación se muestra en la Tabla 1 los resultados de los lenguajes Python, PHP y Ruby on Rails con respecto a las características declaradas anteriormente. Características / Lenguajes Nivel de los algoritmos Complejidad de la sintaxis PHP Python Ruby on Rails Alto nivel Alto nivel Alto nivel Alta Sencilla Sencilla POO Baja Alta Alta Cantidad de Gran Gran cantidad Pocas librerías librerías cantidad Madurez del lenguaje Alta Alta Baja Patrón MVC Código MVC sencillo de MVC sencillo de Spaghetti implementar implementar Tabla 1 - Características de los lenguajes. El código Spaghetti declarado en el lenguaje PHP hace referencia a una estructura compleja donde el control de flujo utiliza sentencias primitivas de saltos que resulta difícil de controlar para los desarrolladores

75 Arquitectura del Proyecto Se ha realizado otra estudio con un sistema de ponderaciones clasificando a cada característica con valores entre 1 y 3 para obtener de manera gráfica qué lenguaje obtiene los mejores resultados (ver imagen 16). Imagen 16 - Ponderaciones de los lenguajes. El lenguaje Python supera las características de PHP y Ruby on Rails debido a que ofrece los mayores valores de cada atributo asociado. Este lenguaje es el seleccionado para desarrollar el código de la aplicación

76 Arquitectura del Proyecto 3.3 SELECCIÓN DEL FRAMEWORK DE DESARROLLO Un framework es un conjunto de módulos que ofrece soporte a un lenguaje de programación. Incorpora librerías y funciones específicas para diferentes tipos de desarrollo. Con el fin de que el desarrollo en el lenguaje Python sea más estructurado, se realizará un análisis de los principales frameworks de desarrollo compatibles con el lenguaje de programación seleccionado. Las ventajas de utilizar un framework son: o No es necesario plantearse una nueva estructura global de la aplicación. Un framework aporta la estructura o esqueleto base de la aplicación para seguir un patrón Modelo-Vista-Controlador. o Un framework facilita la colaboración ya que contiene estándares de desarrollo que utilizan los programadores. Mejora el mantenimiento y la corrección de errores. o Existen muchas librerías y herramientas adaptadas al framework que agilizan la programación reutilizando código de otros programadores. Estas librerías han sido mejoradas a lo largo de su ciclo de vida por los desarrolladores para implantar funcionalidades nuevas y que las salidas sean eficientes. La realización del Benchmarking parte de seis frameworks compatibles con los lenguajes de programación seleccionados en el apartado anterior. Estos frameworks han sido probados en los mismos equipos hardware simulando a

77 Arquitectura del Proyecto usuarios realizando transacciones contra ellos. Los resultados de rendimiento son comparados en base a los siguientes parámetros: o Carga de la CPU: Este parámetro informa de los picos de rendimiento que crea en el centro de proceso de datos. Un framework debe mantener constante el rendimiento de la CPU para que no se produzcan denegaciones de servicio del servidor web por falta de capacidad de proceso. o Disponibilidad del servicio: Las páginas web deben tener una disponibilidad total todo el año. Los frameworks deben aportar módulos de soporte que permitan realizar modificaciones del código sin necesidad de parar el servicio. o Tiempo de respuesta: Cuando un usuario realiza una petición al servidor, éste tarda cierto tiempo en buscar los datos solicitados y cargar la vista para enviarla al navegador en código HTML. El tiempo de respuesta es un parámetro clave para saber el tiempo que espera el usuario en obtener un resultado. Cuanto mayor es el tiempo de respuesta, menor es el nivel de servicio servido. o Duración máxima de una transacción: Es un parámetro que se obtiene calculando la duración de una petición en momentos críticos del servidor. Permite conocer el tiempo de servicio en momentos de picos de rendimiento en el servidor web

78 Arquitectura del Proyecto o Total de transacciones servidas en un intervalo de tiempo: Cada framework es capaz de servir un determinado número de peticiones por segundo. Sabiendo la media de peticiones que realiza un usuario, se puede determinar la cantidad de usuarios que podrán acceder al servidor sin que se comprometa la estabilidad del sistema. o Uso de memoria: Los servidores web se seleccionan con una cantidad de memoria determinada. Es posible ampliar la memoria para conseguir una aplicación con alta escalabilidad, pero hay que analizar cuál es el uso que realizan los frameworks de la memoria por cada petición de usuario. Los frameworks utilizados para la comparativa del benchmarking son: Catalyst, Django, Ruby on Rails, Codelgniter, TurboGears y Symfony, además de un módulo incorporado a Django que mejora la velocidad de ejecución de código. El benchmarking ha sido realizado en un entorno con un servidor de las siguientes características: o Procesador: Intel Core 2 Duo. o Memoria RAM: 2 GB DDR2. o Uplink Port Speed: 100 Mbps. o Disco Duro: 750 GB SATA. o Servidor Web: Apache versión o Sistema Operativo: Ubuntu Hardy 8.04 LTS (Hardy Heron)

79 Arquitectura del Proyecto El primer análisis corresponde al apartado de carga de la CPU. En la imagen 17 se puede observar como el framework TurboGears supera el 50% de carga, por lo que la capacidad de la CPU puede verse afectada ante muchas peticiones de los usuarios. Symfony, Catalyst y Ruby on Rails se encuentran sobre el 40% de carga, pero siguen siendo unos valores altos. Los mejores resultados se obtienen con el framework Django y su variante Django con el módulo Psyco, el cuál obtiene un porcentaje de carga del 18%, un valor muy por debajo del resto de frameworks. Imagen 17 - Porcentaje de carga de CPU. El siguiente apartado a analizar es la disponibilidad que ofrecen los distintos frameworks, que permite la utilización de los mismos instantáneamente sin procesos erróneos inesperados

80 Arquitectura del Proyecto En la siguiente imagen se muestra como todos los módulos analizados tienen unos resultados excelentes, destacando Django con Psyco, TurboGears, Django y Catalyst con una disponibilidad total del 100%. Imagen 18 - Porcentaje de disponibilidad. Atendiendo al tiempo de respuesta y su relación con el nivel de servicio que se ofrece al usuario al tener que esperar un cierto tiempo para recibir información sobre la petición realizada, los frameworks Ruby on Rails y Codelgniter tiene un tiempo medio bastante deficiente, con 4 segundos y 2,6 segundos respectivamente. Django y su variante Django con Psyco sirven las peticiones HTTP en tiempo menor de medio segundo, un resultado excelente para ofrecen un buen nivel de servicio a los usuarios de las páginas web (ver imagen 19)

81 Arquitectura del Proyecto Imagen 19 - Tiempo de respuesta (segundos). Los resultados de la duración máxima de una transacción se pueden analizar observando la imagen 20. Los framework Codelgniter, Ruby on Rails, Symfony y TurboGears presentan unos resultados deficientes de 30 segundos. Un usuario, ante un caso tan desastroso, es capaz de abandonar la página pensando que se ha quedado inoperativa. Los mejores resultados los obtiene Django con una duración máxima entorno a los 10 segundos

82 Arquitectura del Proyecto Imagen 20 - Duración máxima de una transacción. Para determinar la cantidad de usuarios que podrán acceder al servidor sin que se comprometa la estabilidad del sistema se ha efectuado el análisis del total de transacciones servidas que es capaz de realizar un framework en un intervalo de tiempo. En la imagen 21 se muestra que Django y Django con un módulo Psyco obtienen resultados entre y transacciones, unos datos muy por encima del resto de frameworks. Symfony no supera las peticiones, un resultado muy pobre. Ruby on Rails y Codelgniter son frameworks que están por debajo de las transacciones, resultados mediocres si se pretende tener una alta escalabilidad en la aplicación de gestión de backlinks

83 Arquitectura del Proyecto Imagen 21 - Número de transacciones servidas. El último apartado a analizar es el referente al uso de memoria. Un alto uso de memoria compromete la estabilidad y la escalabilidad de la aplicación web. Los framework deben tener una gestión interna que minimice la utilización de la memoria dinámica. Analizando la imagen 22 se contempla como hay dos claros frameworks que necesitan de bastante memoria principal para dar respuesta a las peticiones de los usuarios; son Catalyst, que ha requerido de 100 GB, y Ruby on Rails, que ha utilizado 150 GB en todo el proceso de transacciones. Django obtiene la mejor muestra, en torno a los MB (10 GB)

84 Arquitectura del Proyecto Imagen 22 - Cantidad de memoria principal utilizada. Para finalizar con el análisis de los atributos de cada framework se ha realizado una gráfica utilizando el método de las ponderaciones con los valores desde 1 hasta 3 según sea el resultado de cada característica. En la imagen 23 se presenta el resumen final de las puntuaciones obtenidas por cada framework

85 Arquitectura del Proyecto Imagen 23 - Análisis ponderado de los atributos. Django, gracias a los buenos resultados conseguidos, se consolida como el framework más eficaz para ser usado, junto con el lenguaje de programación Python, en el desarrollo de la aplicación del proyecto

86 Arquitectura del Proyecto 3.4 PROTOCOLO HTTP Para el análisis de backlinks es imprescindible conocer el protocolo de comunicación de Internet HTTP. Casi la totalidad de la información que gestiona la aplicación procede de los campos o encabezados que incorpora este protocolo con información relevante de los usuarios y su ubicación en la red. El protocolo HTTP o HiperText Transfer Protocol se consolidó en 1990 con la publicación de la RFC 2616 (Request For Comments). A partir de la versión 1.0 permite la transferencia de mensajes con encabezados, que contienen información de los mensajes con la codificación MIME. MIME incluye la posibilidad de insertar documentos a un mensaje. De esta manera el explorador conoce de antemano cómo debe mostrar la información de respuesta, incorporando imágenes, vídeos, archivos de texto enriquecido, archivos comprimidos en formato.pdf o incluso archivos más complejos pertenecientes a AutoCad. La función del protocolo HTTP es permitir la comunicación y transferencia de archivos entre un navegador y un servidor web dirigido mediante una dirección URL. Este protocolo se utiliza en la última capa del modelo OSI, la capa de aplicación que interactúa con el sistema operativo cuando se realizan transferencias de archivos a través de la red. Además, el protocolo HTTP contiene todas las cabeceras del protocolo de transporte TCP y del protocolo de red IP

87 Arquitectura del Proyecto Imagen 24 - Modelo capas OSI. El protocolo de aplicación no guarda información sobre estados anteriores. Las aplicaciones web utilizan las cookies, en las cuales se almacena información de los usuarios en sus propios discos físicos y da lugar al concepto de sesión en navegadores web. Las cookies no poseen código ejecutable, únicamente contienen datos propios de los usuarios en donde se almacenan las páginas web visitadas. Mediante el uso de las mismas se controla los accesos privados dentro de una página web y características propias que el usuario desea, como configuraciones de interfaz o contenidos. En la imagen 25 se muestra la comunicación realizada a través del protocolo HTTP entre un navegador y un servidor web

88 Arquitectura del Proyecto Imagen 25 - Comunicación HTTP entre navegador y servidor. El cliente, a través del navegador web, solicita una petición al servidor web de un contenido. Esta petición se encuentra contenida en el protocolo HTTP. El servidor web decodifica las cabeceras, realiza las peticiones necesarias a las bases de datos donde se ubican los contenidos y vuelve a codificar la información creando los nuevos encabezados HTTP con la respuesta para su posterior envío al cliente. Desde el punto de vista de las comunicaciones, el protocolo HTTP trabaja sobre los servicios de conexión TCP/IP. Un proceso servidor escucha en un puerto de comunicaciones TCP (normalmente el puerto 80) y espera las solicitudes de conexión de los clientes. Cuando se ha realizado la conexión, el protocolo TCP se encarga de mantener la comunicación realizando un control de errores

89 Arquitectura del Proyecto Las principales características del protocolo HTTP son: o La comunicación entre el navegador y el servidor se realiza a partir de caracteres de 8 bits. De esta forma se puede transmitir cualquier tipo de documento respetando el formato original. o Permite la transferencia de cualquier archivo multimedia. Para que el navegador y el servidor lo interprete se utiliza el protocolo MIME. o Los principales métodos para dialogar con el servidor son denominados GET, POST y HEAD, cuya descripción se presenta en el apartado o En cada operación se puede recoger un único objeto. Las conexiones con el servidor son liberadas en cuanto finalice la operación. o Los objetos a tratar están identificados al final de la URL. En los siguientes apartados se especificarán los métodos de petición y de respuesta que utiliza el protocolo HTTP

90 Arquitectura del Proyecto MÉTODOS DE PETICIÓN HTTP A continuación se describen los métodos utilizados en las solicitudes desde el navegador al servidor web: o Método GET: Solicita el encabezado de un recurso solicitado. Transmite la información a través de la URI visible desde cualquier navegador, por lo que no es un método seguro. Se utiliza cuando los datos no comprometen al usuario. o Método HEAD: Al igual que el método GET, realiza la petición de un recurso. Su diferencia radica en que no solicita el cuerpo del mensaje, por lo que el servidor envía únicamente las cabeceras del protocolo. Suele ser útil para comprobar la validez de links y modificaciones recientes. o Método POST: Se utiliza para la creación de un nuevo recurso o la actualización de otros. Prepara al servidor para recibir información del cliente, habitualmente desde un formulario. o Método PUT: Registra cierta información que se envía al servidor. El recurso enviado es identificado en la URL desde el cliente. Si se crea un nuevo recurso, el servidor responde con el código 201 (creación). Si modifica algún contenido, contesta con el código 204 (vacío) o 200 (modificación realizada). o Método OPTIONS: Mediante este método se solicita al servidor de información sobre qué métodos están habilitados. Es útil para el cliente conocer las opciones y requisitos asociados a las capacidades del servidor

91 Arquitectura del Proyecto o Método DELETE: Indica al servidor que se desea borrar el recurso indicado en la URL. o Método TRACE: Es un método de diagnóstico en el que el navegador solicita al servidor que le envía una respuesta en la sección de entidad. Permite saber al cliente qué es lo que está recibiendo y analizando el servidor. Para que el cliente pueda pasar información adicional se utilizan cabeceras que se incluyen dentro del protocolo HTTP. En la tabla 2 se declaran las cabeceras más provechosas del protocolo. Tipo de encabezado Accept Accept-Charset Accept-Encoding Accept-Language Authorization Content-Encoding Content-Language Content-Length Content-Type Date Descripción Indica el tipo de contenidos que acepta el navegador. Tipo de caracteres que el navegador espera. Codificación de datos que el navegador acepta. Idioma que el navegador espera. Identificación del navegador. Tipo de codificación para el cuerpo de la petición. Tipo de idioma en el cuerpo de la petición. Indica la extensión del cuerpo. Indica el contenido del cuerpo. Fecha del comienzo de una petición

92 Arquitectura del Proyecto From Link Orig-URL Referer User-Agent Incluye la dirección de correo del usuario. Identifica el vínculo entre dos direcciones. Indica desde qué URL se originó la petición. Indica desde qué URL se realizó la solicitud. Contiene información del cliente, como el nombre, el navegador y el sistema operativo que utiliza. Tabla 2 Encabezados de petición del protocolo HTTP. Como se observará más adelante, los encabezados embebidos en el protocolo HTTP son una fuente de información indispensable para el éxito de la aplicación que analizará y gestionará los backlinks. Se debe prestar especial atención a los encabezados Orig-URL, Referer, Date y Authorization ya que contienen información vital para la generación de estadísticas. La decodificación de esta información aporta datos pertenecientes a los usuarios que se pueden utilizar para la segmentación de contenidos, la inversión en ciertas páginas con impacto en un gran público objetivo y la seguridad de los ataques a través de la red

93 Arquitectura del Proyecto MÉTODOS DE RESPUESTA HTTP La respuesta en el protocolo HTTP incluye una serie de líneas de código que el servidor web envía al cliente. Se compone de tres partes: o Línea de estado: esta línea contiene la información sobre la versión del protocolo usada y el estado de la solicitud en proceso. Se divide en tres campos separados por un espacio: Versión del protocolo utilizada. Código de estado. Significado del código. o Campos correspondientes a los encabezados de respuesta: son un conjunto de líneas opcionales que permiten aportar información añadida del servidor o de la respuesta. Cada línea está compuesta de: Nombre que califica el tipo de encabezado. Valor del encabezado. o Cuerpo de la respuesta: contiene los datos pedidos por el navegador. A continuación se presenta una tabla con los tipos de encabezados de respuesta que se utilizan en el protocolo (ver tabla 3)

94 Arquitectura del Proyecto Tipo de encabezado Allow Content-Encoding Content-Lenguage Content-Length Content-Location Content-MD5 Content-Type Date Expires Forwarded Last-Modified Location Server Descripción Métodos soportados por el recurso asignado por la URI. Especifica el tipo de codificación para el cuerpo de la respuesta. Tipo de idioma utilizado en el cuerpo de la respuesta. Indica el tamaño del contenido del mensaje. Información sobre la localización del recurso. Incorpora el resumen MD5 para comprobar la integridad del mensaje. Tipo de contenido en el cuerpo de la respuesta. Fecha de comienzo de transferencia de datos. Fecha límite de uso de los datos. Utilización de equipos intermediarios. Fecha de última modificación. Redireccionamiento a una nueva URL Atributos del servidor que envió la respuesta. Tabla 3 - Encabezados de respuesta del protocolo HTTP

95 Arquitectura del Proyecto En la tabla 4 se describen las principales cabeceras opcionales que puede incluir el servidor para añadir información sobre el recurso solicitado, la respuesta, o el propio servidor. Cabecera Descripción Age Location Tiempo transcurrido desde que se creó la respuesta. Redirecciona la petición a otra URI. Proxy-Authenticate Indica la autenticación ante un código 407. Public Retry-After Server Vary Warning WWW-Authenticate Informa de los métodos soportados por el servidor. Cuando un servidor no está disponible, da una fecha para volver a intentarlo. Incorpora información sobre el servidor que maneja las peticiones. Indica la existencia de varias respuestas. Aporta información adicional sobre el estado de las respuestas. Presenta la autenticación y los parámetros aplicables a la URI. Tabla 4 - Cabeceras opcionales del protocolo HTTP

96 Arquitectura del Proyecto El código de estado es un número de tres dígitos que informa del estado de la petición al servidor. Cuando una petición no puede ser atendida, informa de la causa al navegador. Los códigos de estado están divididos en cinco clases, definidos por el primer dígito del código: o Código 1xx: es un código de valor informativo. La petición se recibe y continúa el proceso. Se suele usar en servidores experimentales o en pruebas. o Código 2xx: informa de que la petición se ha realizado con éxito. Se ha recibido y aceptado. o Código 3xx: indica que se debe redireccionar a otra URL para conseguir los resultados. o Código 4xx: este código informa de que el cliente ha realizado una petición incorrecta que no se puede llevar a cabo. Suele producirse por errores sintácticos del navegador. o Código 5xx: indica un error del servidor, no es capaz de atender la petición que parece correcta al analizarla. Es fundamental interpretar los códigos de estado del servidor debido a que puede estar informando de posibles problemas internos que no le permitan

97 Arquitectura del Proyecto ofrecer el servicio a los navegadores. En la tabla 5 se exponen los códigos de estado más representativos. Código de estado Descripción 100 Continuar. 101 Cambio de protocolo. 200 Éxito. 201 Creado. 202 Aceptado. 203 Información no autoritativa. 204 Sin contenido. 205 Contenido restablecido 206 Contenido parcial. 300 Múltiples elecciones. 301 Movido permanentemente. 302 Movido temporalmente. 303 Ver otros. 304 No modificado. 305 Usar proxy. 400 Petición errónea. 401 No autorizado. 402 Pago requerido 403 Prohibido. 404 No encontrado

98 Arquitectura del Proyecto 405 Método no permitido. 406 No se puede aceptar. 407 Se requiere autenticación proxy. 408 Límite de tiempo de la petición. 409 Conflicto. 410 Gone. 411 Tamaño requerido. 412 Falla una precondición. 413 Contenido de la petición muy largo. 414 URI de la petición muy largo. 415 Campo media type requerido. 500 Error interno del servidor. 501 No implementado. 502 Puerta de enlace errónea. 503 Servicio no disponible. 504 Tiempo límite de la puerta de enlace. 505 Versión del protocolo HTTP no soportada. Tabla 5 - Códigos de estado del protocolo HTTP

99 Arquitectura del Proyecto 3.5 TECNOLOGÍA COMET Un administrador necesita analizar datos y estadísticas en tiempo real para comprobar que el servicio ofrecido a los navegadores está disponible y funciona correctamente. Habitualmente un navegador recibe información cuando la solicita. En cuanto recibe los contenidos a través del protocolo HTTP se cierra la conexión con el servidor. Pero esta forma de comunicación síncrona se está quedando obsoleta debido a las prestaciones que ofrece la implementación de sistemas de comunicación asíncrona en los servidores web y servidores de bases de datos. No es lógico que un administrador deba pedir al servidor los datos importantes para el análisis, ya que esta información puede cambiar de manera considerable de un segundo a otro. Suponiendo una web nacional de alcance medio con una media de accesos de visitas al día, el resultado es de casi 350 visitas por minuto. Este número es bastante considerable y las estadísticas varían mucho minuto a minuto. Un administrador, para un buen control de la web, debería estar realizando peticiones cada minuto. Como se puede intuir esta forma de comunicación no es eficiente en estos casos. Las tecnologías asíncronas realizan la comunicación sin que el usuario tenga que enviar ningún evento al navegador. Funciona de forma autónoma para calcular o actualizar contenidos de la web, realizando las peticiones al servidor sin síntomas visibles en la interfaz

100 Arquitectura del Proyecto Imagen 26 - Comunicación Web Síncrona. Imagen 27 - Comunicación Web Asíncrona. En la imagen 27 se puede apreciar cómo, a diferencia de la comunicación síncrona, el usuario no es el que envía el evento de petición de contenidos al servidor, sino que se encarga un módulo externo a la interfaz de enviar y recibir contenidos sin intervención del usuario

101 Arquitectura del Proyecto Existen dos tipos de comunicación asíncrona los cuales se diferencian en la conexión del canal de comunicación: o Sin conexión abierta: se utiliza mediante un módulo AJAX (Asynchronous JavaScript And XML). Este módulo se encarga de realizar peticiones al servidor para conocer si se han producido cambios. Estas peticiones permanecen en segundo plano, por lo que el usuario desconoce si está esperando nueva información, puede seguir navegando por los contenidos. Los módulos AJAX agrupan una serie de tecnologías representadas en la imagen 28. Imagen 28 - Tecnologías que implementa AJAX. o Con conexión abierta: cuando un navegador realiza una petición al servidor, la conexión no se cierra, sino que se mantiene abierta para que se produzca una transmisión de información constante sin necesidad de volver a crear el protocolo. Esta comunicación se implementa mediante el modelo Comet también llamado AJAX Push, Server Push o Reverse AJAX. La gran diferencia con el resto de tecnologías radica en que es el servidor el que se encarga de generar los eventos y enviar la información al navegador cuando se produzcan cambios. En el caso de que el cliente

102 Arquitectura del Proyecto solicite datos, el servidor no le responde con un bloque de datos, sino que espera a que se produzca un evento para enviarle información. Imagen 29 - Ejemplo de módulo COMET entre navegador y servidor. Existe un número creciente de aplicaciones web que empiezan a usar la tecnología COMET para actualizar datos en tiempo real. Algunos ejemplos son: o Resultados deportivos, tanto en páginas de información general como casas de apuestas. o Precios de stock de portales de compra online

103 Arquitectura del Proyecto o Páginas web dedicadas a temas económicos, como resultados de las acciones de la bolsa. o Comunicación entre usuarios en portales sociales. o Páginas gestoras de correo electrónico. La tecnología COMET se basa en que el servidor envía información al usuario o navegador sin que éste los solicite. El canal de comunicación permanece abierto una vez se realice la conexión, con lo que se reducen los tiempos de latencia en peticiones. El beneficio de esta tecnología está determinado por la eficiencia de no realizar peticiones cuando no existen cambios en el servidor. Se mejora el rendimiento en las transferencias, no saturando la red con peticiones del cliente y respuestas del servidor sin ningún resultado. Únicamente se transfieren datos por la red cuando se producen cambios en el servidor. COMET utiliza el método XMLHttpRequest para entregar los datos al cliente a través del protocolo HTTP

104 Arquitectura del Proyecto DIFERENCIAS ENTRE AJAX Y COMET (REVERSE AJAX) A continuación se van a presentar las diferencias más acusadas en cuanto al nivel conceptual y al nivel de implantación. Diferencias a nivel conceptual. Cuando la comunicación se realiza mediante AJAX, el cliente es el que maneja la interacción. El contexto y el contenido de la comunicación caduca en cuanto se realiza la petición y el servidor envía una respuesta. Mediante la tecnología COMET se evitan los retardos manteniendo una conexión HTTP y TCP/IP abierta, la cual es reutilizada durante toda la comunicación. El servidor transfiere información únicamente cuando existen cambios relevantes. Diferencias a nivel de implantación. Existen dos técnicas de implantación. La primera de ellas consiste en un pedido de larga duración donde se realiza una reconexión después de cada datagrama. La forma de codificarla es a través del XMLHttpRequest

105 Arquitectura del Proyecto Imagen 30 - Diagrama de secuencia del XMLHttpRequest. El otro método de implantación es utilizando la técnica Forever-Frame. Por medio de esta técnica el navegador recibe bloques de script y utiliza un renderizado progresivo. Es una técnica que permite una alta portabilidad y permite conexiones y dominios, utilizando elementos HTML IFRAME y reduciendo las latencias al

106 Arquitectura del Proyecto mínimo. Los datos se insertan de forma incremental desde el servidor al cliente. La conexión se cierra sólo cuando existe un error en los ciclos de conexión. Un ejemplo real de tecnología COMET se puede observar en la imagen 31, que corresponde a la página oficial de Bolsa y Mercados Españoles ( Los contenidos señalados son modificados automáticamente cuando se producen cambios en el servidor o en las bases de datos. El usuario no se percata de cuándo ni cómo suceden los cambios. Imagen 31 - Ejemplo de tecnología COMET

107 Arquitectura del Proyecto 3.6 BASE DE DATOS REDIS Según el uso que se le vaya a dar a una base de datos se debe seleccionar una base de datos relacional o una base de datos no relacional, también denominada base de datos de clave-valor. Una base de datos relacional facilita el desarrollo de una aplicación con una gran independencia de datos. El inconveniente se produce a la hora de representar estructuras de datos extensibles y complejos. Para desarrollar estas bases de datos primero se convierte el diagrama entidadrelación a tablas y posteriormente se normalizan para obtener un esquema óptimo. Las tablas se componen de tuplas (filas), columnas y restricciones (constraints) que definen las relaciones entre ellas. Para realizar consultas se realizan bajo el lenguaje SQL, que producen los resultados accediendo a una o varias tablas. Algunos lenguajes que trabajan con estas bases de datos son MySQL, Oracle, SQL Server o DB2. Imagen 32 - Tablas de una base de datos relacional

108 Arquitectura del Proyecto Las bases de datos relacionales son escalables, pero su complejidad aumenta cuando las bases de datos se reparten en varios nodos o servidores. Es muy complicado actualizar el hardware rápidamente ante un aumento de demanda en un breve espacio de tiempo. Cuando se habla de cientos o miles de nodos, la situación se convierte en insostenible. Las bases de datos relacionales se componen de multitud de funciones que no suelen ser usadas, desperdiciando recursos y rendimiento. En la imagen 32 se puede contemplar un ejemplo de tablas implementadas en una base de datos relacional. Cada tabla contiene su clave primaria y sus atributos. Además las tablas están relacionadas desde uno a n relaciones (un ciudadano tiene n vehículos, un vehículo tienen n sanciones ). Las bases de datos no relacionales priorizan la simplicidad y el rendimiento manejando los datos de forma estructurada pero no relacional. Están preparadas para manipular gran volumen de datos y proporcionan una alta escalabilidad. Estas bases de datos también son llamadas como orientadas a documentos, orientadas a Internet, orientadas a atributos, tablas hash distribuidas o bases de datos NoSQL (Not Only SQL). Imagen 33 - Logotipos de diferentes bases de datos NoSQL

109 Arquitectura del Proyecto Las características puras de las bases de datos clave-valor son: o Los dominios pueden ser asociados como tablas, pero no se define ningún esquema para un dominio. Un dominio es como un contenedor (llamado cabinet) en la que se meten elementos en su interior. o Los elementos son identificados por claves. Un elemento dado puede tener adjunto un conjunto dinámico de atributos. o En algunas implementaciones todos los atributos son cadenas de texto. En otras implementaciones se manejan atributos simples que reflejan tipo de código, como enteros y listas. o Ninguna relación es definida explícitamente entre dominios ni en el interior de un dominio. Las bases de datos clave-valor están orientadas a objetos o elementos. Todos los datos relevantes relacionados con un elemento están almacenados dentro del mismo elemento. Un dominio puede contener multitud de elementos diferentes. Los datos pueden estar duplicados entre los elementos de un dominio, pero se acepta debido a que el rendimiento es bastante superior a los costes provocados en disco ya que es un coste relativamente barato. Lo que se consigue con que un elemento contenga todos sus datos relevantes es un aumento de escalabilidad eliminando la necesidad de unir diferentes datos desde varias tablas realizando operaciones complejas como los joint del lenguaje SQL

110 Arquitectura del Proyecto Las necesidades de relaciones en bases de datos NoSQL son muy reducidas pero algunas relaciones son inevitables. Estas relaciones suelen presentarse en entidades centrales o comunes. Cuando existen tablas intermedias producidas por la relación entre dos tablas, el gestor de la base de datos no puede forzar la integridad de las relaciones. Es posible eliminar datos de las tablas sin que el gestor lo prohíba, por lo que la responsabilidad de la integridad queda en manos de la aplicación. Los datos son creados, actualizados y borrados usando llamadas a métodos de la API de la base de datos. Toda la lógica de aplicación y de integridad lógica de datos debe estar contenida en el propio código de la aplicación. El gran beneficio que aporta el almacenamiento clave-valor es la idoneidad para Internet. Su simplicidad permite una mejor escalabilidad que el almacenamiento relacional. En una aplicación web, donde se van a producir desde algunas consultas aisladas hasta millones de ellas según el alcance que tenga, las bases de datos no relacionales permiten almacenar en infinitos nodos o servidores los datos de forma dinámica sin que comprometa la escalabilidad o el rendimiento. Es posible mapear las estructuras de almacenamiento clave-valor para ser usadas en modelos relacionales, proceso conocido como mapeo de objetos a relacional. Esto es útil cuando se desea exportar ciertos datos de una aplicación a otra cuyo almacenamiento es relacional. Este proceso lo realizan ciertos gestores de bases de datos no relacionales, reduciendo los tiempos de desarrollo. Cuando un desarrollador trabaja con almacenamiento no relacional, debe comprometerse en codificar el código de la aplicación de manera que asegure la integridad y referencias cruzadas de los datos en el nivel más bajo. Como se ha citado anteriormente, las bases de datos no relacionales no aseguran la integridad,

111 Arquitectura del Proyecto por lo que es el desarrollador el responsable último de la buena gestión de los datos. Para realizar el proyecto se ha utilizado REDIS, una base de datos no relacional que aprovecha la memoria al máximo antes de utilizar el disco para obtener los mejores resultados en cuanto a velocidad y escalabilidad. Su código está escrito en C y C++, y dispone de una licencia BSD. REDIS tiene todo su conjunto de datos en memoria y cuando el número de registros llegue a un cierto valor definido por el administrador o supere cierto tiempo, los datos son escritos asíncronamente en disco. Esto le permite ser tan rápido como una base de datos en memoria, con la posibilidad de perder unos pocos datos si se produjera algún tipo de error. La base de datos REDIS soporta: o Administración de conexiones al servidor con autenticación. o Operaciones con cadenas tipo clave-valor. o Operaciones con claves: TTL, renombrado, expiración y tamaño total. o Operaciones atómicas sobre listas: operaciones push, pop, control de lista, tamaño de la lista. o Agrupación de claves en Sets. o Administración de múltiples bases de datos

112 Arquitectura del Proyecto o Ordenación de listas y Sets. o Comandos para el control de persistencia o Control remoto del servidor. Algunos clientes de REDIS son los lenguajes de programación Ruby, PHP, Python, Java, Pearl y Erlang. Estos lenguajes poseen módulos o frameworks que implementan funciones para trabajar con las bases de datos REDIS. Imagen 34 - Logotipo de base de datos REDIS

113 Arquitectura del Proyecto BENCHMARK DE REDIS Redis gestiona los datos o registros de una manera muy veloz. Es capaz de realizar operaciones por segundo. En un benchmark realizado por se han obtenido los siguientes resultados: Operaciones SET. % realizado Tiempo (milisegundos) 58.50% 0 ms % 1 ms % 2 ms % 3 ms % 6 ms. 100% 9 ms. Tabla 6 - Porcentaje de operaciones SET en REDIS. Con un total de 50 clientes realizando peticiones simultáneamente, REDIS consigue terminar peticiones en un segundo

114 Arquitectura del Proyecto Operaciones GET. % realizado Tiempo (milisegundos) 62.27% 0 ms % 1 ms % 2 ms. 100% 3 ms. Tabla 7 - Porcentaje de operaciones GET en REDIS. En la tabla 7 se muestra el porcentaje de operaciones GET realizadas por REDIS. En un segundo es capaz de gestionar peticiones. En 1.23 segundos ha realizado operaciones GET. Operaciones PUSH. % realizado Tiempo (milisegundos) 43.12% 0 ms % 1 ms % 2 ms % 3 ms % 9 ms. 100% 22 ms. Tabla 8 -Porcentaje de operaciones PUSH en REDIS

115 Arquitectura del Proyecto REDIS consigue realizar operaciones PUSH en un segundo. Para alcanzar las operaciones necesita 1.14 segundos. Operaciones POP. % realizado Tiempo (milisegundos) 54,83% 0 ms % 1 ms % 2 ms % 3 ms. 100% 9 ms. Tabla 9 - Porcentaje de operaciones POP en REDIS. REDIS realiza operaciones POP en 1,39 segundos. En un segundo es capaz de procesar peticiones. El benchmarking fue realizado en un equipo Linux de moderadas prestaciones con un procesador Xeon X3320 a una velocidad de reloj de 2.5 GHz. Estos resultados permiten que REDIS pueda ser utilizado para diferentes finalidades: o Como base de datos principal: REDIS es capaz de gestionar toda la información que administre una aplicación

116 Arquitectura del Proyecto o Como base de datos auxiliar: en algunos puntos de una aplicación pueden provocarse cuellos de botella debido a un pico de transacciones. Es estos casos es muy eficiente la base de datos REDIS dada su alta velocidad y escalabilidad. Los datos generales de la aplicación podrían administrarse en una base de datos principal, mientras que los procesos que utilicen muchos datos podrían gestionarse en una base de datos secundaria. o Como caché: es posible almacenar en memoria caché los datos reduciendo los ratios de latencia. Además REDIS aporta multitud de funcionalidades para mejorar la gestión del espacio en memoria

117 Arquitectura del Proyecto CONFIGURACIÓN DEL SERVIDOR REDIS Para que la aplicación de análisis y gestión de backlinks funcione de la manera más eficiente posible, con un uso adecuado de memoria y preparado para ser escalable ante una variabilidad alta de operaciones, se han utilizado ciertos comandos que se describen en la tabla 10. Comando appendonly databases flushall flushdb save maxmemory Descripción Utilizado en momentos críticos de la aplicación cuando se desea que no se pierda información bajo ningún concepto. El servidor llevará un registro de las operaciones realizadas para reconstruir la base de datos en caso de una caída del servidor. Identifica las bases de datos que gestionará REDIS. Controla el uso de memoria para cada base de datos. Por defecto, REDIS declara 16 bases de datos. Elimina todos los valores y claves de las bases de datos. Se realiza en validación y pruebas para volver a actuar sobre la base de datos vacía. Elimina todos los valores y claves de la base de datos que se está utilizando en ese momento. El resto de bases de datos se mantienen intactas. En este comando se declaran dos parámetros fundamentales: los segundos y cambios que se pueden realizar antes de escribir en memoria. Indica a REDIS cuál es el máximo de memoria que puede utilizar dinámicamente

118 Arquitectura del Proyecto monitor requirepass slaveof masterauth shutdown Identifica todas las acciones realizadas contra el servidor en tiempo real. Es útil para analizar los accesos y ver posibles accesos no autorizados. Se declara una contraseña para que sólo el administrador pueda acceder a la base de datos. Identifica al servidor maestro con los parámetros dirección IP y puerto. Indica la autenticación que usarán los servidores esclavos para conectarse con el servidor maestro. Sincroniza la información de la memoria con los datos del servidor y apaga el servidor. Tabla 10 - Comandos utilizados en la creación del servidor con REDIS

119 Arquitectura del Proyecto 3.7 CAPA MIDDLEWARE DE LA APLICACIÓN El análisis y gestión de backlinks se implementa bajo una capa middleware entre la aplicación web y los navegadores o clientes de la web. Una capa middleware funciona como una capa software de abstracción que tanto los clientes como los actuadores internos con la aplicación no son conscientes de su existencia. Esta capa contiene funcionalidad dedicada a los administradores para el análisis de las entradas a la web y la creación de gráficos y estadísticas que abarcan temas de posicionamiento y seguridad de la web. La capa middleware se encargará de mantener las comunicaciones síncronas y asíncronas con las bases de datos REDIS, implementando la tecnología Reverse AJAX para obtener los datos en tiempo real. Además, es la encargada de la comunicación con Google Visualization API, la cual realizará los gráficos estadísticos en formato FLASH y los enviará a la capa middleware para su posterior análisis por el administrador del sistema. Para analizar las entradas y salidas de los clientes a la web, la capa middleware interactuará con Google Analytics, un servicio muy potente que ofrece Google con objetivo de facilitar el análisis del tráfico de la web. Los datos enviados a Google Analytics son previamente mapeados por la capa middleware seleccionando los datos valiosos de los campos del protocolo HTTP. En la imagen 35 se expone de una manera genérica las comunicaciones entre la capa middleware, las bases de datos, y los servidores externos de Google

120 Arquitectura del Proyecto Imagen 35 - Comunicaciones de la capa middleware. Las principales ventajas que aporta la capa middleware de análisis y gestión de backlinks son las siguientes: o Independiza los entornos propietarios, por lo que simplifica el proceso de desarrollo de aplicaciones. No afecta a la página o aplicación web, siendo una capa externa y transparente con respecto al negocio principal. o Permite la interconectividad con diferentes servicios y sistemas de información. La comunicación se realiza con servicios de Google y con las bases de datos REDIS mediante tecnología COMET

121 Arquitectura del Proyecto o Proporciona un mayor control de negocio, centrándose en la capa todos los aspectos relacionados con las estadísticas e información dirigida al administrador. Muchas plataformas son gestionadas en un único punto, con lo que se consigue un mayor control y acotación del negocio. La capa middleware podría llegar a ser un inconveniente en cuanto a temas de rendimiento. La carga de memoria y CPU pueden crecer considerablemente. Estos aspectos han sido resueltos configurando el servidor de acceso a la base de datos REDIS con unos valores máximos que proporcionan la seguridad de continuidad de negocio

122 Análisis Conceptual Capítulo 4 ANÁLISIS CONCEPTUAL

123 Análisis Conceptual 4.1 MODELO DE DOMINIO DIAGRAMA DE CLASES En el siguiente diagrama se muestran todas las clases que operan con la aplicación y el servidor de base de datos. Al ser una base de datos no relacional, las relaciones entre clases son inexistentes, por lo que se muestra su identificador y los atributos que contiene. PageView requested_path referrer_domain TotalPageView path page_views search_engine search_term date_time browser ip country TotalSearches search_term page_views

124 Análisis Conceptual DailySearches search_term page_views date_time TotalReferrerDomain referrer_domain page_views date_time DailyReferrerDomain referrer_domain page_views date_time DailyReferrerCountry country page_views date_time TotalReferrerCountry country page_views date_time TotalReferrerBrowser browser page_views date_time

125 Análisis Conceptual DESCRIPCIÓN DE ATRIBUTOS El significado de los atributos contenidos en las clases del modelo no relacional es: o requested_path: ruta de acceso solicitada por el usuario. o referrer_domain: dominio desde donde el usuario accede a través de un enlace. o search_engine: motor de búsqueda utilizado por el usuario. o search_term: término utilizado por el usuario para iniciar una búsqueda. o date_time: fecha y hora en el que se produce el acceso. o browser: navegador web utilizado por el usuario. o ip: dirección IP del usuario. o country: país donde se encuentra el usuario que realiza la búsqueda. o path: URI del navegador web. o page_views: páginas visitadas por un usuario

126 Análisis Conceptual 4.2 MODELO DE CASOS DE USO En este apartado se documentarán los requerimientos funcionales del sistema. En el diagrama de casos de uso se muestran gráficamente las acciones que pueden realizar los actores y las relaciones entre ellos. Las acciones son unidades funcionales completas con sentido para algún actor. El actor único y primario será el administrador, el cual interactúa con el sistema para lograr ciertos objetivos. En el subapartado descripción de casos de uso se detalla cada acción realizada por el administrador, sin tener en cuenta aspectos de programación ni eventos que lancen la acción. Las restricciones y extensiones de los comportamientos serán descritas en el subapartado descripción detallada de casos de uso

127 Análisis Conceptual DIAGRAMA DE CASOS DE USO A continuación se muestra el diagrama de casos de uso del administrador. Debido a que la aplicación es una capa middleware entre un usuario y una página web, los clientes que acceden a una web no interactúan con el middleware, por lo que no disponen de casos de uso. Imagen 36 - Diagrama de casos de uso

128 Análisis Conceptual DESCRIPCIÓN DE CASOS DE USO El administrador será capaz de realizar las siguientes acciones contra la aplicación de análisis y gestión de backlinks: Login: Para la seguridad y privacidad de la web de estadísticas dedicada al análisis, el administrador debe loguearse a través de un usuario y contraseña. Estos datos se encuentran almacenados en la base de datos PostgreSQL del servidor. Consultar estadísticas: El administrador podrá consultar los gráficos generados a partir del protocolo HTTP siempre que la base de datos REDIS y el servicio de Google Visualization se encuentren activos. Forzar actualización: Cuando se obtengan gráficos indeseados o incoherentes, el administrador podrá solicitar las modificaciones a la base de datos REDIS, invirtiendo el flujo normal de actuación mediante la tecnología Reverse AJAX. Gestionar comandos de la base de datos REDIS: El administrador tendrá acceso a los comandos de configuración de la base de datos, pudiendo modificar los valores de tiempo de actualización y cantidad de memoria utilizada antes de realizar el push de información a memoria física. Estos valores son fundamentales en momentos críticos, como puede ser el tráfico intenso en un determinado periodo de tiempo

129 Análisis Conceptual Bloquear backlink: Cuando el administrador observe una situación peligrosa debido a un incremento desmesurado de los accesos a través de un enlace de una web, podrá esperar que se trate de un ataque DoS o DDoS. Debido a las graves consecuencias que puede provocar un ataque de denegación de servicio, el administrador puede bloquear los accesos a través desde ese enlace, denegando los paquetes de datos que en sus cabeceras lleven la dirección origen del atacante. Bloquear IP: Del mismo modo que el administrador puede bloquear un enlace web, podrá también bloquear una dirección IP concreta, con el fin de que el usuario que está accediendo demasiadas veces a un mismo contenido no provoque un exceso de tráfico en el servidor. De este modo se asegura la continuidad del servidor web

130 Análisis Conceptual 4.3 DIAGRAMAS DE SECUENCIA En este apartado se explicarán las relaciones entre los objetos de la aplicación desarrollada, mediante diagramas de secuencia. En estos diagramas se representarán tanto las clases que interaccionan entre ellas como los mensajes enviados entre distintas clases y capas. Cabe destacar que se ha utilizado la metodología UML para el desarrollo de dichos diagramas. En la imagen que aparece a continuación se muestra la petición que realiza un usuario a una página web para que muestre un contenido, ya sea a través de un enlace o backlink, o directamente desde la barra de direcciones de un navegador. La petición HTTP llega a la capa modelo, en donde la clase URLs analiza el tipo de petición y redirige la petición HTTP Request a la capa de control Middleware, que se encarga de seleccionar los datos significativos para las estadísticas y los envía a la base de datos REDIS con el objetivo de que los almacene de forma asíncrona mejorando el rendimiento de las comunicaciones con el servidor. Posteriormente el Middleware reenvía la HTTP Request a la capa vista adecuada a la petición del usuario. Los datos son cargados en la HTTP Response hacia la capa de control. Es la clase Middleware la que se encarga de enviar al usuario la página HTML con el contenido solicitado

131 Análisis Conceptual Imagen 37 - Diagrama de secuencia: petición HTTP. El administrador dispone de su propia página web desde donde analiza y gestiona las estadísticas. Por seguridad y privacidad, la interfaz está protegida mediante nombre de usuario y contraseña. Las relaciones entre clases se muestran en la imagen 38. Imagen 38 - Diagrama de secuencia: login administrador

132 Análisis Conceptual El administrador realiza una petición HTTP para obtener la entrada a la interfaz de estadísticas. La clase URLs reenvía la petición a la clase Vista para que envíe la página de login al administrador. Desde esta vista, el administrador introduce su usuario y password para que sea validado. La capa Vista se encarga de realizar la petición a la base de datos PostgreSQL donde se encuentran los datos de configuración del servidor. Si la validación resulta satisfactoria, se envía al administrador la interfaz de estadísticas. Las actualizaciones de estadísticas se obtienen en tiempo real sin que el administrador tenga que realizar peticiones al servidor de la aplicación. El diagrama de secuencia se muestra en la siguiente imagen. Imagen 39 - Diagrama de secuencia: actualización de estadísticas. La base de datos REDIS realiza un PUSH de la información que ha sido actualizada o modificada hacia la capa vista. Esta clase se encarga de realizar la conexión con el módulo de Google Visualization, el cual genera los gráficos y responde a la clase Vista con los nuevos gráficos en formato JavaScript o FLASH. La clase Vista se ocupa de sustituir los gráficos que han sido modificados en la página HTTP mediante la tecnología Reverse AJAX

133 Análisis Conceptual El administrador también tiene la posibilidad de actualizar la página web de estadísticas de forma manual. Su cometido es el aseguramiento de que la base de datos no se ha caído o se ha producido una saturación del servidor. La diferencia con la actualización automática radica en que el administrador realiza la petición síncronamente al servidor. En la siguiente imagen se muestra las relaciones entre las entidades y las clases. Imagen 40 - Diagrama de secuencia: actualización de estadísticas manuales

134 Plan de Gestión del Proyecto Capítulo 5 PLAN DE GESTIÓN DEL PROYECTO

135 Plan de Gestión del Proyecto 5.1 ORGANIZACIÓN DEL PROYECTO ESTRUCTURA DE DIVISIÓN DEL TRABAJO A continuación se muestra, mediante un gráfico, la Estructura de División del Trabajo (EDT), en el cual se descompone el proyecto en un conjunto de tareas manejables para obtener una visión detallada del alcance del proyecto y que permite monitorizar el progreso del proyecto con mayor facilidad. El EDT se descompone en: Tareas resumen: dan una visión de más alto nivel de los paquetes de trabajo. Las tareas resumen se pueden descomponer en otros paquetes para ofrecer un mayor detalle. Paquetes de trabajo: Identificado como WP (Work Package), es la actividad ejecutiva la cual no se puede descomponer en más niveles

136 Plan de Gestión del Proyecto

137 Plan de Gestión del Proyecto DESCRIPCIÓN DE LOS PAQUETES DE TRABAJO En las sucesivas tablas se detallarán los paquetes de trabajo y tareas resumen del proyecto, indicando las entradas necesarias, actividades que se realizan en cada módulo, las salidas que produce cada paquete de trabajo y datos de gestión del WP. Entradas: [WP 1.1] Lanzamiento. Actividades: Salidas: Gestión: Documento de requisitos técnicos. Plan interno de reunión de lanzamiento. Diagramas de secuencia. Actas de reunión. Manual de usuario. [WP 1.1.1] Reunión de lanzamiento. [WP 1.1.2] Memoria del Proyecto. Acta de reunión de lanzamiento. Estructura de División del Trabajo (EDT). Organigrama. Planificación del Proyecto. Memoria del Proyecto. Responsables: Director de Proyecto Planificación: 1ª semana. Duración: 102 horas. Tabla 11 Paquete de trabajo Lanzamiento

138 Plan de Gestión del Proyecto [WP 1.1.1] Reunión de lanzamiento. Entradas: Actividades: Salidas: Gestión: Documento de requisitos técnicos. Plan interno de reunión de lanzamiento. Planificación de las actividades. Generación del EDT. Definición del organigrama. Acta de reunión de lanzamiento. Estructura de División del Trabajo (EDT). Organigrama. Planificación del Proyecto. Responsables: Director de Proyecto. Planificación: 1ª semana. Duración: 17 horas. Tabla 12 Paquete de trabajo Reunión de lanzamiento. [WP 1.1.2] Memoria del Proyecto. Entradas: Actividades: Documento de requisitos técnicos. Actas de reunión. Información recopilada de bibliografía. Estructura de División del Trabajo (EDT). Organigrama. Planificación del Proyecto. Diagramas de secuencia. Manual de usuario. Redacción de la Memoria del Proyecto

139 Plan de Gestión del Proyecto Salidas: Gestión: Memoria Final del Proyecto Análisis y Gestión de Backlinks. Responsable: Jefe de Proyecto. Planificación: 2ª semana. Duración: 85 horas. Tabla 13 Paquete de trabajo Memoria del proyecto. [WP 1.2] Control periódico. Entradas: Actividades: Salidas: Gestión: Documento de requisitos técnicos. Actas de reunión. Planificación del Proyecto. Control de la planificación para obtener una idea general de cómo avanza el proyecto. Documento de reunión de seguimiento. Responsable: Jefe de Proyecto. Planificación: Repetitiva mensual. Duración: 20 horas. Tabla 14 Paquete de trabajo Control periódico

140 Plan de Gestión del Proyecto [WP 1.3] Cierre. Entradas: Actividades: Salidas: Gestión: Memoria del proyecto. Actas de reunión. Documentos de seguimiento. Contraste de los requisitos pedidos inicialmente contra las funcionalidades desarrolladas. Análisis de la calidad de la aplicación. Análisis de la calidad de la memoria. Anexo D cumplimentado con la aceptación del proyecto. Responsable: Director de Proyecto, Coordinador de Proyecto. Planificación: 49ª semana. Duración: 6 horas. Tabla 15 Paquete de trabajo Cierre. [WP 2.1] Análisis de requisitos. Entradas: Actividades: Salidas: Documento de requisitos técnicos. EDT. Planificación del Proyecto. Definir los requisitos técnicos de la aplicación. Definir el alcance y la escalabilidad Documento de descripción de los módulos a desarrollar

141 Plan de Gestión del Proyecto Gestión: Benchmarking de lenguajes y framework de desarrollo. Informes de cambios. Responsable: Jefe de Proyecto. Planificación: 2ª semana. Duración: 25 horas. Tabla 16 Paquete de trabajo Análisis de requisitos. [WP 2.2] Diseño del sistema. Entradas: Actividades: Salidas: Gestión: Documento de requisitos técnicos. EDT. [WP 2.2.1] Diseño de la BBDD. [WP 2.2.2] Diseño de la arquitectura web. [WP 2.2.3] Diseño de conexión con Google Visualization. [WP 2.2.4] Diseño de las interfaces. [WP 2.2.5] Diseño de los gráficos analíticos. Diagrama de Clases. Diagrama de Paquetes. Diagramas de Secuencia. Documento de diseño de las interfaces. Documento de diseño de los gráficos analíticos. Responsable: Jefe de Proyecto. Planificación: 2ª semana. Duración: 64 horas. Tabla 17 Paquete de trabajo Diseño del sistema

142 Plan de Gestión del Proyecto [WP 2.2.1] Diseño de la BBDD. Entradas: Actividades: Salidas: Gestión: Documento de requisitos técnicos. EDT. Selección de la base de datos a utilizar. Analizar la escalabilidad de la base de datos. Definir los objetos y atributos a manejar por la base de datos. Diagrama de Clases con las relaciones entre objetos. Descripción de los atributos que almacenará la base de datos. Diagrama de Paquetes. Responsable: Jefe de Proyecto. Planificación: 4ª semana. Duración: 15 horas. Tabla 18 Paquete de trabajo Diseño de la BBDD. [WP 2.2.2] Diseño de la arquitectura web. Entradas: Documento de requisitos técnicos. Actividades: Salidas: Selección del servidor web donde se alojará la aplicación web. Realización del Modelo-Vista-Controlador. Documento de los módulos a desarrollar. Documento de la interacción entre los módulos

143 Plan de Gestión del Proyecto Gestión: Diagramas de secuencia. Responsable: Jefe de Proyecto. Planificación: 7ª semana. Duración: 17 horas. Tabla 19 Paquete de trabajo Diseño de la arquitectura web. [WP 2.2.3] Diseño de conexión con Google Visualization. Entradas: Documento de requisitos técnicos. Documento de los módulos a desarrollar. Actividades: Salidas: Gestión: Análisis del API de Google Visualization. Diseño de la conexión del módulo de Google Visualization. Diseño del módulo de Google Visualization. Diagrama de secuencia de Google Visualization. Responsable: Jefe de Proyecto. Planificación: 11 ª semana. Duración: 7 horas. Tabla 20 Paquete de trabajo Diseño de Google Visualization. [WP 2.2.4] Diseño de las interfaces. Entradas: Documento de requisitos técnicos. Documento de los módulos a desarrollar. Diseño del módulo de Google Visualization

144 Plan de Gestión del Proyecto Actividades: Salidas: Gestión: Análisis de la accesibilidad de los usuarios. Análisis de la carga de red. Desarrollo de las interfaces dedicadas a la administración de las estadísticas. Documento de diseño de las interfaces. Responsable: Jefe de Proyecto. Planificación: 14 ª semana. Duración: 16 horas. Tabla 21 Paquete de trabajo Diseño de las interfaces. [WP 2.2.5] Diseño de los gráficos analíticos. Entradas: Documento de requisitos técnicos. Documento de los módulos a desarrollar. Diseño del módulo de Google Visualization. Documento de diseño de las interfaces. Actividades: Salidas: Gestión: Definir el tipo de gráficos a utilizar para el administrador. Definir el tiempo de refresco de los gráficos. Analizar la carga de red por cada cambio en las estadísticas. Definir las diferentes alertas para los cambios anómalos en las estadísticas. Documento de diseño de los gráficos analíticos. Responsable: Jefe de Proyecto. Planificación: 18 ª semana

145 Plan de Gestión del Proyecto Duración: 9 horas. Tabla 22 Paquete de trabajo Diseño de los gráficos analíticos. [WP 2.3] Desarrollo del sistema. Entradas: Diagrama de Clases con las relaciones entre objetos. Descripción de los atributos que almacenará la base de datos. Diagrama de Paquetes. Diagrama de secuencia de la base de datos. Diseño del módulo de Google Visualization. Diagrama de secuencia de Google Visualization. Documento de diseño de los gráficos analíticos. Información de códigos HTTP. Actividades: Salidas: Gestión: [WP 2.3.1] Desarrollo de la BBDD. [WP 2.3.2] Desarrollo de compatibilidad con Google Visualization. [WP 2.3.3] Desarrollo del módulo de análisis del protocolo HTTP. [WP 2.3.4] Desarrollo de estadísticas y gráficos. Módulo de BBDD de REDIS. Módulo de conexión con Google Visualization. Módulo de análisis de cabeceras HTTP. Módulo de visualización de gráficos. Responsable: Jefe de Proyecto. Planificación: 20 ª semana. Duración: 55 horas. Tabla 23 Paquete de trabajo Desarrollo del sistema

146 Plan de Gestión del Proyecto [WP 2.3.1] Desarrollo de la BBDD. Entradas: Actividades: Salidas: Gestión: Diagrama de Clases con las relaciones entre objetos. Descripción de los atributos que almacenará la base de datos. Diagrama de Paquetes. Diagrama de secuencia de la base de datos. Desarrollo del módulo de BBDD. Desarrollo de conexión con la base de datos REDIS. Generación de los campos con los atributos seleccionados. Módulo de BBDD de REDIS. Responsable: Jefe de Proyecto. Planificación: 20 ª semana. Duración: 20 horas. Tabla 24 Paquete de trabajo Desarrollo de la BBDD. Entradas: [WP 2.3.2] Desarrollo de compatibilidad con Google Visualization. Actividades: Salidas: Diseño del módulo de Google Visualization. Diagrama de secuencia de Google Visualization. Desarrollo del módulo de conexión con Google Visualization. Selección de los datos relevantes para la generación de estadísticas. Módulo de conexión con Google Visualization

147 Plan de Gestión del Proyecto Gestión: Responsable: Jefe de Proyecto. Planificación: 26 ª semana. Duración: 11 horas. Tabla 25 Paquete de trabajo Desarrollo de compatibilidad. Entradas: [WP 2.3.3] Desarrollo del módulo de análisis del protocolo HTTP. Actividades: Salidas: Gestión: Documento de diseño de los gráficos analíticos. Información de códigos HTTP. Análisis de las cabeceras del protocolo HTTP que aparecen de las peticiones de los clientes para obtener los datos relevantes. Módulo de análisis de cabeceras HTTP. Responsable: Jefe de Proyecto. Planificación: 31 ª semana. Duración: 11 horas. Tabla 26 Paquete de trabajo Desarrollo del módulo HTTP. [WP 2.3.4] Desarrollo de estadísticas y gráficos. Entradas: Actividades: Documento de diseño de los gráficos analíticos. Módulo de análisis de cabeceras HTTP. Generación de gráficos a través de estadísticas realizadas con los datos almacenados en REDIS y

148 Plan de Gestión del Proyecto Salidas: Gestión: enviando dichos datos a Google Visualization. Módulo de visualización de gráficos. Responsable: Jefe de Proyecto. Planificación: 33 ª semana. Duración: 13 horas. Tabla 27 Paquete de trabajo Desarrollo de estadísticas y gráficos. Entradas: [WP 2.4] Manual de usuario. Actividades: Salidas: Gestión: Descripción de los atributos que almacenará la base de datos. Documento de diseño de los gráficos analíticos. Información de códigos HTTP. Documento de diseño de las interfaces. Capturas de la aplicación. Documentar la forma de utilización de la aplicación para que cualquier administrador sea capaz de realizar el seguimiento de gráficas y estadísticas. Documentar las posibles alertas ante cambios anómalos en los datos. Manual de usuario. Responsable: Jefe de Proyecto. Planificación: 41 ª semana. Duración: 8 horas. Tabla 28 Paquete de trabajo Manual de usuario

149 Plan de Gestión del Proyecto [WP 3] Implementación y pruebas. Entradas: Actividades: Salidas: Gestión: Manual de usuario. Código fuente. [WP 3.1] Pruebas unitarias. [WP 3.2] Implementación. Documento de aprobación de productos. Aplicación web en funcionamiento. Responsable: Jefe de Proyecto. Planificación: 36ª semana. Duración: 12 horas. Tabla 29 Paquete de trabajo 3 - Implementación y pruebas. [WP 3.1] Pruebas unitarias. Entradas: Actividades: Salidas: Gestión: Manual de usuario. Código fuente. Instalar cada módulo desarrollado en un banco de pruebas para su validación. Documento de aprobación de productos. Responsable: Jefe de Proyecto. Planificación: 36 ª semana. Duración: 5 horas. Tabla 30 Paquete de trabajo Pruebas unitarias

150 Plan de Gestión del Proyecto [WP 3.2] Implementación. Entradas: Actividades: Salidas: Gestión: Código fuente. Realizar la instalación del producto completo en el servidor dedicado, con su correspondiente servidor de base de datos REDIS. Aplicación web en funcionamiento. Responsable: Jefe de Proyecto. Planificación: 38 ª semana. Duración: 7 horas. Tabla 31 Paquete de trabajo Implementación

151 Plan de Gestión del Proyecto ESTRUCTURA INTERNA El siguiente gráfico muestra el organigrama presente en el proyecto. Se utilizan diferentes niveles para mostrar la jerarquía de los participantes. El primer nivel representado tiene el derecho de la supervisión y coordinación de toda la aplicación final. Imagen 41 - Organigrama del proyecto

152 Plan de Gestión del Proyecto RESPONSABILIDADES A continuación se detallan las responsabilidades de cada rol asignado para el desarrollo del proyecto. La principal fuerza de trabajo es el análisis del diseño y la programación de la aplicación de análisis y gestión de backlinks. Como máximo responsable aparece la figura del Director de Proyecto. Director de Proyecto: o Definición de los requisitos de la aplicación. o Establecer los tiempos de programación de cada módulo. o Comprobar la funcionalidad de los módulos. o Comprobar aspectos de seguridad y accesibilidad de la aplicación. o Comprobar riesgos en comunicaciones y tráfico de datos. o Aprobación del proyecto. Coordinador de Proyecto: o Supervisión del análisis de la aplicación. o Supervisión de la documentación final del proyecto. o Establecer los tiempos de entrega. o Aprobación del proyecto. o Calificación de la documentación y la aplicación desarrollada

153 Plan de Gestión del Proyecto Asesor de programación Django: o Establecer requisitos mínimos del framework. o Acoplamiento de los módulos programados. o Comprobar funcionalidad con páginas webs reales. o Verificación y pruebas de la aplicación. Jefe de Proyecto: o Definir el alcance del proyecto. o Analizar y evaluar las necesidades del proyecto. o Redactar los requisitos del proyecto. o Calcular y justificar los costes de desarrollo. o Realizar el seguimiento del proyecto, plasmando la progresión en informes del Product Backlog y el Sprint Backlog. o Realizar el diagrama de quemado (Burn Down Chart) donde se representan los módulos finalizados. Programador: o Desarrollar los requisitos técnicos de la base de datos REDIS. o Desarrollar la interfaz de la aplicación. o Desarrollar los módulos específicos de la aplicación

154 Plan de Gestión del Proyecto Analista: o Diseñar la metodología a seguir para el desarrollo de la aplicación. o Diseñar los módulos específicos de la aplicación. o Diseñar la arquitectura de la capa middleware. o Diseñar las comunicaciones con la base de datos REDIS. o Diseñar los interfaces de la aplicación. o Diseñar las entradas y salidas de datos del sistema

155 Plan de Gestión del Proyecto ASIGNACIÓN DE RECURSOS A continuación se muestra una tabla con la matriz de responsabilidades. En ella se representan los paquetes de trabajo y los roles asignados para cada integrante del proyecto. D.P. C.P. A.D. J.P. P. A. [WP 1.1.1] E I E [WP 1.1.2] A-S A-S E E E [WP 1.2] E E [WP 1.3] A A E E [WP 2.1] E S E E E E [WP 2.2.1] A-S I I I E [WP 2.2.2] A-S I I I E [WP 2.2.3] A-S I I E [WP 2.2.4] A-S I I E [WP 2.2.5] A-S I I I E [WP 2.3.1] A S S E [WP 2.3.2] A S S E [WP 2.3.3] A S S E [WP 2.3.4] A S S E [WP 2.4] S A E E [WP 3.1] I I A-S E [WP 3.2] A I E Tabla 32 - Matriz de responsabilidades

156 Plan de Gestión del Proyecto Abreviatura Nombre Completo Abreviatura Descripción D.P. Director de Proyecto. A Acepta. C.P. Coordinador de Proyecto. S Supervisa. A.D. Asesor Django. E Ejecuta. J.P. Jefe de Proyecto I Es Informado. P. Programador. A. Analista

157 Plan de Gestión del Proyecto 5.2 PLANIFICACIÓN En el siguiente diagrama de Gantt se puede observar la planificación temporal del proyecto Análisis y Gestión de Backlinks. Se pueden apreciar tres grandes paquetes de trabajo distinguidos en el diagrama como barras horizontales de color gris: [WP 1] Gestión del proyecto. [WP 2] Desarrollo del proyecto. [WP 3] Implementación y pruebas. Además, se han distinguido los siguientes paquetes resumen con texto en color verde, para diferenciarlos de los paquetes de trabajo indivisibles. [WP 1.1] Lanzamiento. [WP 2.2] Diseño del sistema. [WP 2.3] Desarrollo del sistema

158 Plan de Gestión del Proyecto

159 Plan de Gestión del Proyecto Las duraciones de cada tarea, fecha de inicio, fecha de finalización, y tareas predecesoras se detallan en la siguiente tabla: Tabla 33 - Duración de los paquetes de trabajo

160 Plan de Gestión del Proyecto 5.3 ESTUDIO ECONÓMICO COSTES DE IMPLANTACIÓN Las horas totales dedicadas por cada integrante del proyecto, a cada rol asignado, se muestran en la siguiente tabla (datos detallados en la Tabla 32 y en el apartado Planificación): D.P. C.P. A.D. J.P. P. A. Total horas. [WP 1.1.1] [WP 1.1.2] [WP 1.2] [WP 1.3] [WP 2.1] [WP 2.2.1] [WP 2.2.2] [WP 2.2.3] [WP 2.2.4] [WP 2.2.5] [WP 2.3.1] [WP 2.3.2] [WP 2.3.3]

161 Plan de Gestión del Proyecto [WP 2.3.4] [WP 2.4] [WP 3.1] [WP 3.2] Total horas Tabla 34 - Total horas participante / Paquete de trabajo. En la tabla que se muestra a continuación se detalla el coste total de implantación. Total horas Coste / hora Total D.P C.P A.D J.P P A Total Implantación Tabla 35 - Coste total de implantación

162 Plan de Gestión del Proyecto COSTES DE OPERACIÓN En el desarrollo del proyecto se han utilizado diversas tecnologías, equipos hardware y medios de comunicación. En la siguiente tabla se muestra un resumen de los costes incurridos de operación. Descripción Coste Coste total. Servidor web dedicado. 99 /mes 990 Conexión ADSL. 25 /mes 250 Microsoft Office Ordenador portátil Toshiba* Ordenador sobremesa HP* Total Operación Tabla 36 - Coste total de operación. * Coste de un año sobre cinco de vida útil COSTES TOTALES Descripción Coste total. Costes de implantación Costes de operación Total Tabla 37 - Coste total

163 Conclusiones Capítulo 6 CONCLUSIONES

164 Conclusiones 6.1 CONCLUSIONES La capa middleware de Análisis y Gestión de Backlinks ha sido desarrollada correctamente y sus resultados cumplen los objetivos marcados al inicio del proyecto. El código desarrollado en el lenguaje Python junto con el framework Django es limpio y eficiente. La aplicación ha sido implantada en un banco de pruebas en el servidor, realizando diversas peticiones a la página web desde distintos enlaces para comprobar su capacidad de acceso a base de datos, encapsulamiento de los datos, conexión con Google Visualization y generación de gráficos. La gestión de la base de datos REDIS ha sido muy satisfactoria, al igual que las interfaces de administración en donde se muestran las gráficas producidas en tiempo real. Se han realizado todas las pruebas posibles para comprobar el rendimiento de la web y los posibles fallos que hubieran en el código fuente. Como colofón de esta aplicación se puede destacar su gran aportación para el futuro de Internet. La gestión de backlinks ofrece muchas aportaciones en cuanto a materia de seguridad, posicionamiento e inversión. Internet, que crece de una manera desmesurada e incontrolada, necesita mecanismos de análisis para poder mejorar las sensaciones de los usuarios, centrar las búsquedas de la información relevante para los usuarios y desechar la información inútil. Mediante las estadísticas y los métodos de posicionamiento se puede conseguir un Internet más eficaz y eficiente

165 Bibliografía Capítulo 7 BIBLIOGRAFÍA

166 Bibliografía 7.1 BIBLIOGRAFÍA [HOLO09] La guía definitiva de Django Adrian Holovaty, Jacob Kaplan- Moss. Anaya, [BECK07] Extreme programming Kent Beck. Embrace Change, [MART08] Python Guía de referencia. - Alex Martelli. Anaya [SCHR09] Webbots, spiders and screen scrapers - Michael Schrenk. Ebook, [FISS08] Aplicaciones web 2.0 Wikis RSS - Marcela L. Fissore Lic. Gustavo A. Gómez Rodríguez. Ebook,

167 Bibliografía 7.2 REFERENCIAS WEB [WEB001] RFC Protocolo de transferencia de hipertexto: [WEB002] RFC Protocolo de transferencia de hipertexto: [WEB003] Estadísticas mundiales de Internet: [WEB004] Google Visualization API: [WEB005] Documentación BBDD REDIS:

168 Manual de Usuario Parte II MANUAL DE USUARIO

169 Manual de Usuario Capítulo 1 MANUAL DE USUARIO

170 Manual de Usuario 1.1 MANUAL DE USUARIO En las sucesivas ventanas se mostrarán las interfaces de las que dispondrá el administrador de una página web. Mediante el análisis de las gráficas obtenidas a a partir de Google Visualization, el administrador podrá tomar medidas para proteger el servidor o cambiar el posicionamiento interno de contenidos. En la imagen 42 se muestra una captura de prueba. El acceso a la web se ha producido directamente desde la aplicación, siendo el dominio de llegada backlinks.zenxit.com. Como el usuario no ha accedido directamente desde un motor de búsqueda, los datos referentes a los términos de búsqueda aparecen como desconocidos. Para que aparezcan todos los datos es necesario crear una página web con su propio dominio e introducir en ella la capa middleware desarrollada. Imagen 42 - Captura de prueba de estadísticas