Herramienta informática para el monitoreo de errores de las aplicaciones web (página 2)
Su modelo y código permanece sincronizado en todo el ciclo de desarrollo.
Está disponible en múltiples versiones, para cada necesidad.
Es fácil de instalar y actualizar.
Transforma los diagramas de Entidad- Relación en tablas de base de datos.
Importación y exportación de ficheros XML (Lenguaje de Marcas Extensible, de sus siglas en inglés de eXtensible Markup Language).
Permite la reorganización de las figuras y conectores de los diagramas UML (20).
Lenguajes de desarrollo del lado del cliente
HTML 5
HTML5 (HyperText Markup Language, versión 5). HTML5 establece una serie de nuevos elementos y atributos que reflejan el uso típico de los sitios web modernos. Entre los nuevos atributos que se destacan se encuentran:
Tabla 1.1 Nuevos atributos del HTML5 (21)
Entre sus nuevas características se tiene que:
Incorpora etiquetas (canvas6 2D y 3D, audio, video) con codecs (codificador – decodificador) para mostrar los contenidos multimedia.
Etiquetas para manejar grandes conjuntos de datos. Permiten generar tablas dinámicas que pueden filtrar, ordenar y ocultar contenido en cliente.
Mejoras en los formularios. Nuevos tipos de datos y facilidades para validar el contenido sin Javascript.
Añade etiquetas para manejar la Web Semántica (Web 3.0) (21).
CSS3
CSS del inglés Cascading Style Sheets (hoja de estilo en cascada). CSS3 es un lenguaje usado para definir la presentación de un documento estructurado escrito en HTML o XML. El uso del CSS es para separar la estructura de un documento de su presentación. La información de estilo puede ser adjuntada como un documento separado o en el mismo documento HTML.
Para la propuesta de solución se usará el CSS3 ya que en diferencia a versiones anteriores, está dividida en varios documentos separados, llamados "módulos". Cada módulo añade nuevas funcionalidades a las definidas en CSS2, de manera que se preservan las anteriores para mantener la compatibilidad (22).
Java Script v9.7
Para el desarrollo de la propuesta de solución se utilizará JavaScript en su versión 9.7. Según Suárez "…es un lenguaje de programación utilizado para crear pequeños programas encargados de realizar determinadas acciones dinámicas dentro del ámbito de una página web. Técnicamente es un lenguaje de programación interpretado, por lo que no es necesario compilar los programas para ejecutarlos" (23). En otras palabras, los programas escritos con JavaScript se pueden probar directamente en cualquier navegador sin necesidad de procesos intermedios. Por otra parte pone a disposición del programador todos los elementos que forman parte de la página web, para que el mismo pueda acceder a ellos y modificarlos dinámicamente.
6 Canvas: un canvas es un lienzo de mapa de bits dependiente de la resolución de pantalla. http://www.desarrolloweb.com/articulos/guia-canvas-html5-desarrolladores.html.
Java Script se utiliza principalmente en su forma del lado del cliente, implementado como parte de un navegador web permitiendo mejoras en la interfaz de usuario y páginas web dinámicas.
Lenguaje de desarrollo del lado del servidor
PHP v5.4.24
PHP, es un lenguaje de código abierto muy popular, especialmente adecuado para el desarrollo web. Es un lenguaje multiplataforma, y tiene soporte para cualquiera de los principales sistemas operativos del mercado y para una gran variedad de gestores de bases de datos, dentro de los que incluye PostgreSQL. Además soporta la mayoría de los servidores web como el Apache (24). Está formado de un conjunto de símbolos y reglas tanto sintácticas como semánticas que especifican su estructura y el significado de sus elementos y expresiones. Cada lenguaje de programación tiene sus propias características, las cuales lo hacen más potente o más débil para determinada finalidad. El estudio de los mismos garantiza contar con los recursos apropiados para codificar la solución a desarrollar.
PHP es un lenguaje interpretado de propósito general ampliamente utilizado, diseñado especialmente para aumentar e incrementar el dinamismo de las páginas web y puede ser incrustado dentro de código HTML (HyperText Markup Language, Lenguaje de Marcado de Hipertexto por su traducción al español). Generalmente se ejecuta en un servidor web, tomando el código en PHP como su entrada y creando páginas web como salida al usuario final, por lo que PHP convierte una página estática en una dinámica. Puede ser desplegado en la mayoría de los servidores web y plataformas sin costo alguno. La nueva versión de PHP posee una serie de nuevas características como son:
Tecnología del lado del cliente
Para la propuesta de solución se usará como tecnología del lado del cliente: Ajax, acrónimo de Asynchronous JavaScript And XML (JavaScript asíncrono y XML), es una técnica de desarrollo web para crear aplicaciones interactivas. Es una tecnología asíncrona, ya que los datos adicionales se solicitan al servidor y se cargan en segundo plano sin interferir con la visualización ni el comportamiento de la página.
Ajax es una combinación de cuatro tecnologías ya existentes:
XHTML (o HTML) y Hojas de Estilos en Cascada (CSS) para el diseño que acompaña a la información.
Document Object Model (DOM) accedido con un lenguaje de guion por parte del usuario, especialmente implementaciones ECMAScript como JavaScript y JScript, para mostrar e interactuar dinámicamente con la información presentada.
El objeto XMLHttpRequest para intercambiar datos de forma asíncrona con el servidor web. En algunos frameworks y en algunas situaciones concretas, se usa un objeto iframe en lugar del XMLHttpRequest para realizar dichos intercambios.
XML es el formato usado generalmente para la transferencia de datos solicitados al servidor, aunque cualquier formato puede funcionar, incluyendo HTML pre-formateado, texto plano, JSON y hasta EBML.
Como el DHTML, LAMP o SPA, Ajax no constituye una tecnología en sí, sino que es un término que engloba a un grupo de éstas que trabajan conjuntamente (26).
Framework de desarrollo del lado del cliente
JQuery v1.9.1
El framework de desarrollo del lado del cliente que se utilizará en la propuesta de solución es el JQuery en su versión 1.9.1. JQuery es un framework de Javascript, es decir, sirve como base para la programación avanzada de aplicaciones con código JavaScript aportando una serie de funciones o códigos para realizar tareas habituales. Es una librería que se encarga de acceder a los objetos del DOM (Modelo en Objetos para la Representación del Documento) de un modo simplificado. Ofrece una infraestructura con la que se tiene mayor facilidad para la creación de aplicaciones complejas del lado del cliente. Permite agregar efectos a las páginas haciéndolas más interactivas y con una considerable disminución de código. Tiene una estructura que le da organización al proyecto y evita la implementación de funcionalidades comunes (27).
Twitter Bootstrap v2.2.2
Como framework de desarrollo CSS se utilizará Twitter Bootstrap en su versión 2.2.2. Twitter Bootstrap simplifica el proceso de creación de diseños web combinando CSS y JavaScript. La mayor ventaja es que posibilita crear interfaces que se adapten a los distintos navegadores, apoyándose en un framework potente con numerosos componentes web que ahorrarán mucho esfuerzo y tiempo. Bootstrap ofrece una serie de plantillas CSS y ficheros JavaScript que permiten integrar el framework de forma sencilla y potente en las aplicaciones web. Ofrece un diseño sólido usando estándares como CSS3/HTML5 (28).
Framework de desarrollo del lado del servidor
Symfony2, es un marco de desarrollo para PHP, desarrollado completamente con PHP5, diseñado para optimizar el desarrollo de las aplicaciones web. Separa la lógica de negocio, la lógica de servidor y la presentación de la aplicación web (Modelo – Vista – Controlador). Además, automatiza las tareas más comunes, permitiendo al desarrollador dedicarse por completo a los aspectos específicos de cada aplicación.
Una aplicación desarrollada con el marco de trabajo Symfony2, contará con código claro y organizado consistentemente. Symfony2 promueve la reutilización y permite a los nuevos desarrolladores ser productivos en el proyecto con mayor rapidez. El 100% del código que es escrito, es para la aplicación, pues no se necesita desarrollar o mantener servicios públicos de bajo nivel, tales como la carga automática de clases, el enrutado o la reproducción de controladores.
Proporciona acceso a librerías como Doctrine, además a plantillas, seguridad, formularios, validación y traducción. Permite que las URL sean totalmente flexibles gracias al componente Routing (enrutamiento). La arquitectura centrada en HTTP de Symfony2 le da acceso a herramientas, tal como la memoria caché HTTP (29).
Para el desarrollo de la propuesta de solución de empleará el framework Symfony en su versión
2.4.0 que trae consigo una serie de nuevas características como son:
Se ha añadido un nuevo componente llamado Expression Language.
Se ha introducido un nuevo servicio llamado request_stack y que reemplaza al servicio request. A partir de esta versión, se desaconseja el uso del objeto Request en los servicios y se recomienda utilizar en su lugar el objeto Request Stack.
Las plantillas Twig ahora permiten medir en detalle el tiempo que tardan en renderizar cada parte.
Ahora es mucho más fácil definir tus propios proveedores de usuarios y autenticadores y también puedes asociar firewalls a hosts (detalles).
Los logs de la aplicación ahora se pueden mostrar en la consola y también se han añadido muchas pequeñas mejoras a la consola.
Ahora es posible detener un proceso si lleva demasiado tiempo inactivo.
Se ha añadido un panel de depuración de formularios en la barra de depuración y se ha mejorado bastante el validador de imágenes (30).
Gestor de Base de Datos
Los Sistemas de Gestión de Bases de Datos (SGBD) (en inglés Database Management System, abreviado DBMS) son un tipo de software específico, dedicado a servir de interfaz entre la base de datos, el usuario y las aplicaciones que la utilizan. Existen muchos SGBD pero en su gran mayoría son sistemas propietarios entre los que se destacan: MySQL, Advantage Database, FileMaker, etc. También se encuentran SGBD disponible como Sistemas Libres como son: PostgreSQL, FileMaker, MySQL, etc.
Como gestor de base de datos para la solución propuesta se utilizará PostgreSQL en su versión
9.2.4. PostgreSQL es un SGBD Relacional orientada a objetos y libre, publicado bajo la licencia BSD. Algunas de las características de este sistema son:
Alta concurrencia.
Alta variedad de tipos nativos.
Claves Ajenas.
Disparadores.
Vistas.
Tipos de datos y operaciones geométricas.
Integridad transaccional.
Herencia de tablas.
Soporte para transacciones distribuidas.
Funciones (31).
Servidor Web
Un servidor web es un programa informático para procesar las aplicaciones del lado del servidor mediante conexiones que generan una respuesta desde las aplicaciones del lado del cliente.
El servidor web seleccionado para utilizar en la propuesta de solución es Apache en su versión 2.2.22.
Apache es un servidor web multiplataforma de código abierto, es el ejemplo de código libre de mayor éxito. Permite generar informes de errores HTTP y gestionar recursos para procesos hijos. El servidor Apache presenta entre otras características: mensajes de error altamente configurables, bases de datos de autenticación y negociado de contenido. Apache es un servidor altamente configurable de diseño modular. Es muy sencillo ampliar las capacidades del servidor web Apache, existen gran cantidad de módulos Apache disponibles para su utilización. Tiene una buena compatibilidad con el lenguaje PHP compartiendo muchas de sus características.
Principales características de Apache.
Fiabilidad: Alrededor del 90% de los servidores con más alta disponibilidad funcionan con Apache.
Gratuidad: Apache es totalmente gratuito, y se distribuye bajo la licencia Apache Software
License, favoreciendo la modificación del código.
Extensibilidad: Se pueden añadir módulos para ampliar las amplias capacidades de Apache. Existe una amplia variedad de módulos, que permiten generar contenido dinámico con PHP, Java, Perl, entre otros, además de monitorizar el rendimiento del servidor. Estos módulos pueden ser creados por cualquier persona con conocimientos de programación (32).
Entorno de desarrollo integrado
NetBeans v7.4
Un entorno de desarrollo integrado, llamado también IDE (sigla en inglés de Integrated Development Environment), es un programa informático compuesto por un conjunto de herramientas de programación. Un IDE es un entorno de programación que ha sido empaquetado como un programa de aplicación, es decir, consiste en un editor de código, un compilador, un depurador y un constructor de interfaz gráfica (GUI).
Para la propuesta de solución se seleccionó el IDE NetBeans en su versión 7.4. NetBeans es un entorno de desarrollo integrado, multiplataforma, de código abierto, permite a los desarrolladores crear rápidamente aplicaciones web, móviles y de escritorio con el uso de plataforma Java, PHP, JavaScript, Ajax, Groovy, Grails y C / C++. Es gratuito, tiene una gran comunidad de usuarios y desarrolladores en todo el mundo, proporciona herramientas de análisis estático para identificar y solucionar problemas comunes en código Java; además el IDE tiene editores y herramientas para XML, HTML, PHP, Groovy, Javadoc, JavaScript y JSP (33).
El IDE NetBeans 7.4 ofrece un rendimiento significativamente mejorado y mayor experiencia de codificación. La base en la que se sustenta su elección es que permite desarrollar aplicaciones utilizando el framework Symfony y ejecutar los comandos del mismo directamente desde la interfaz del IDE.
Servicios web
Existen múltiples definiciones sobre lo que son los Servicios Web, lo que muestra su complejidad a la hora de dar una adecuada definición que englobe todo lo que son e implican. Una posibilidad sería hablar de ellos como un conjunto de aplicaciones o de tecnologías con capacidad para interoperar en la Web. Estas aplicaciones o tecnologías intercambian datos entre sí con el objetivo de ofrecer servicios. Los proveedores ofrecen sus servicios como procedimientos remotos y los usuarios solicitan un servicio llamando a estos procedimientos a través de la Web (34).
Estos servicios proporcionan mecanismos de comunicación estándares entre diferentes aplicaciones, que interactúan entre sí para presentar información dinámica al usuario. Para proporcionar interoperabilidad y extensibilidad entre estas aplicaciones, y que al mismo tiempo sea posible su combinación para realizar operaciones complejas, es necesaria una arquitectura de referencia estándar.
En todo este proceso intervienen una serie de tecnologías que hacen posible esta circulación de información. Por un lado, estaría el Protocolo Simple de Acceso a Objetos o SOAP (siglas del inglés Simple Object Access Protocol). Se trata de un protocolo basado en XML, que permite la interacción entre varios dispositivos y que tiene la capacidad de transmitir información compleja. Los datos pueden ser transmitidos a través de HTTP, SMTP, etc. SOAP especifica el formato de los mensajes. El mensaje SOAP está compuesto por un "sobre" (envelope), cuya estructura está formada por los siguientes elementos: cabecera (header) y cuerpo (body).
Por otro lado se tiene Transferencia de Estado Representacional o REST (por sus siglas en inglés Representational State Transfer), es un estilo de arquitectura de software para sistemas distribuidos tales como la web, a diferencia de SOAP, se centra en el uso de los estándares HTTP y XML para la transmisión de datos sin la necesidad de contar con una capa adicional. Las operaciones (o funciones) se solicitarán mediante GET, POST, PUT y DELETE, por lo que no requiere de implementaciones especiales para consumir estos servicios. Además se podrá utilizar JSON en vez de XML como contenedor de la información (35).
Se determina utilizar REST dado a que sus características son más adaptables al entorno de desarrollo, siendo estas las siguientes:
Un bajo consumo de recursos.
Las instancias del proceso son creadas explícitamente.
El cliente no necesita información de enrutamiento a partir de la URI inicial.
Los clientes pueden tener una interfaz escuchadora (listener) genérica para las notificaciones.
Generalmente fácil de construir y adoptar.
Conclusiones del capítulo
La metodología de investigación posibilitó realizar el estudio del arte del objeto que se estudia. Luego del estudio realizado se pudo puntualizar los conceptos más importantes para dar cumplimiento al problema de la investigación que se realiza. Se pudo determinar que las herramientas similares no cumplen con las expectativas del problema creado en el Centro FORTES de la Facultad cuatro para la monitorización de aplicaciones web. Además, no cumplen con la política de utilización de software libre implementada en el país, no se ajustan a las condiciones económicas actuales y no realizan las tereas específicas para cumplir con la necesidad de la Plataforma.
El estudio de las herramientas para el desarrollo de la propuesta de solución estuvo apoyado en el criterio de selección de herramientas libres y competentes para la obtención del producto final con la calidad requerida.
Capítulo 2
Análisis y diseño
El presente capítulo detalla las fases de Exploración y Planificación definidas en el ciclo de vida de la metodología de desarrollo XP que posibilita describir la solución propuesta.
De igual forma se muestran los principios, prácticas y técnicas que sirven de guía para los desarrolladores, entre las que se destacan: HU, plan de iteraciones, plan de entrega y las tarjetas CRC (Clases, Responsabilidad y Colaboración).
Modelo de dominio
La metodología XP no utiliza el modelo de domino. A pesar de esto, se decide utilizar dicho modelo, con el fin de describir y limitar el alcance del dominio del problema. Este diagrama no se puede confundir con un modelo de clase de software, aunque puede ser utilizado como base para su construcción.
Se puede definir este modelo como una visualización de los conceptos del dominio en el mundo real, para realizar dicho modelo se necesita definir las clases conceptuales (solo las más significativas), así como las relaciones existentes entre ellas para brindan un mejor entendimiento del sistema. Las clases conceptuales son para representar de la manera más fácil posible y de forma adecuada las estructuras del lenguaje natural, se encargan de representar las entidades presentes en el dominio (ideas, objetos, personas, etc.) El modelo de dominio es una representación estática del sistema (36).
Para realizar un modelo de dominio se tienen los siguientes pasos:
Listar las clases conceptuales candidatas.
Representarlas clases en el modelo.
Añadir las asociaciones necesarias para registrar las relaciones que hay que mantener en memoria.
Figura 2.1 Modelo de dominio (elaboración propia)
En la Figura 2.1 se muestra el funcionamiento de un sistema de monitoreo de errores. El usuario interactúa con el sistema, el cual mediante la Interfaz de programación de aplicaciones o API (del inglés Application Programming Interface) de conexión se encarga de guardar todas las excepciones capturadas por un sistema de captura implementado en las aplicaciones web.
Descripción del modelo de dominio:
usuario:
El usuario será la persona que interactúe de forma dinámica con el sistema. Este debe estar previamente registrado por un miembro del grupo de administradores, deben estar asociados a una o más aplicaciones web que se monitoree por el sistema.
sistema_monitoreo:
El sistema de monitoreo se encargará de controlar los errores http de las aplicaciones que controla. Este sistema enviará a los desarrolladores un reporte completo desde la última notificación, de los errores ocurridos en las aplicaciones web que estos controlen.
API_conexión:
El API de conexión es una clase que tendrá tres funcionalidades. La primera de estas, se encargará de guardar los errores en un archivo local, otra funcionalidad reportará los errores que existan en el fichero y la otra funcionalidad es encargada de cambiar la contraseña del usuario de la aplicación que está registrado en el sistema de monitoreo.
sistema_captura_excepción:
Sistema encargado de capturar los errores que ocurren en las aplicaciones web, este sistema lo implementa cada aplicación.
aplicación:
Son las aplicaciones web, que hacen uso del sistema de monitoreo, para llevar un control de sus errores.
Propuesta de solución
Se propone desarrollar una solución informática que se encargue de monitorear los errores lanzados por las aplicaciones web. La propuesta de solución será capaz de integrarse con aplicaciones desarrolladas sobre el framework Symfony2. Una de las herramientas que se encuentra en desarrollo sobre el framework mencionado es "ZERA Support", con la cual se va a integrar la solución informática posibilitando hacer uso de su gestión de usuario. Debido a esto el sistema constará con restricciones de acceso, de acuerdo al rol que posee el usuario que interactúe con él. Existirán solo dos roles, el rol administrador y el rol usuario registrado. El usuario que cuente con el rol administrador, es el encargado del correcto funcionamiento del sistema y la gestión de las aplicaciones que serán monitoreadas. El sistema admitirá que exista más de un usuario con este rol. La persona que posea el rol usuario registrado, va a estar asociado a aplicaciones que se estén monitoreando y solo podrá obtener la información de los errores generados por estas.
El monitoreo será realizado haciendo uso de dos servicios web. El servicio reportar, se encarga de guardar los errores en el sistema, el cual requiere el envío de un token7 que se genera mediante el proceso de autenticación de las aplicaciones. Este proceso se realiza utilizando el servicio autenticación, el cual recibe un usuario y contraseña que se les crea a las aplicaciones que solicitan ser monitoreadas y solamente serán utilizados por los servicios web. La herramienta informática permitirá además la generación de reportes de los errores ocurridos, cumpliendo con determinados filtros especificados por el usuario como son: rango de fecha, tipo de error, aplicación o estado.
Uno de los requisitos para la utilización del servicio de monitoreo es que las aplicaciones web que se desea monitorear deben contar con un sistema de captura de errores previamente implementado, el cual debe ser reconfigurado para hacer uso de la API proporcionada por la propuesta de solución. La API REST como complemento de la propuesta de solución, es una clase php configurable, encargada de hacer uso de los servicios web brindados por la herramienta informática.
La interfaz gráfica será amigable y ofrecerá a los usuarios una fácil interacción con el sistema. La propuesta de solución estará dirigida a usuarios del equipo de desarrollo de la aplicación que se esté monitoreando.
A continuación se mencionan las principales funcionalidades que serán descritas posteriormente en las Historias de Usuario (HU).
Servicio REST.
API REST.
Adicionar aplicación.
Listar aplicaciones.
Eliminar aplicaciones.
Visualización detallada de las aplicaciones.
Listar errores.
Marcar errores como vistos.
Eliminar los errores.
Exportar reporte.
Generar reportes de errores en formato pdf y xls.
Generar reporte para notificación en formato pdf.
Visualización detallada de errores.
7 Token: Un token o también llamado componente léxico es una cadena de caracteres que tiene un significado coherente en cierto lenguaje de programación. http://www.alegsa.com.ar/Dic/token.php.
Administrar notificaciones.
Crear periodo de notificación.
Listar notificación.
Eliminar notificación.
Personas relacionadas con el sistema
Se define como personas relacionadas con el sistema a todas las personas que de una forma u otra van a interactuar con la aplicación, incluyendo a los que van a mantener el sistema (37).
Tabla 2.1 Personas relacionadas con el sistema
Personas relacionadas con el sistema | Justificación | |
Usuario registrado | Es la persona que se encuentra registrada en el sistema. El usuario registrado será el personal encargado del mantenimiento o parte del equipo de desarrollo de la aplicación con la cual estará relacionado en el sistema. Un usuario puede pertenecer a varias aplicaciones. Este usuario una vez autenticado tendrá acceso a ver los errores que generados por las distintas aplicaciones a las que pertenece. | |
Administrador | Es la persona autorizada para la gestión del sistema. Tiene todos los privilegios para acceder a todo el contenido del sistema. Es la persona encargada de adicionar las aplicaciones al sistema. | |
Historias de usuarios planificadas
Las historias de usuario son la técnica utilizada en XP para especificar los aspectos funcionales del software. Se realizó una por cada funcionalidad del sistema, se emplearon para hacer estimaciones de tiempo y para el plan de iteraciones. Cada HU se definió lo suficientemente comprensible y delimitada para que el programador pueda implementar en pocas semanas. Si la estimación es superior a las tres semanas, debe ser dividida en dos o más historias. Si es menos de una semana, se debe combinar con otra historia de usuario. Cada historia de usuario debe tener en algún momento pruebas de validación asociadas, lo que permitirá al desarrollador, y más tarde al cliente, verificar si la historia ha sido completada. Para los prototipos de interfaz de usuarios ver Anexo 1: Prototipos de interfaz de usuario.
Si el usuario es Administrador se mostrarán todos los errores que se han registrado en el sistema. Si el usuario es Usuario Registrado se mostrarán los errores pertenecientes a las Aplicaciones con las cuales está relacionado
Fase de planificación
Una vez definida cada una de las historias de usuarios se pasó a definir la estimación de esfuerzo necesario para realizar cada una de ellas.
La planificación se realizó basándose en el tiempo o el alcance. Al planificar por tiempo, se multiplicó el número de iteraciones por la velocidad del proyecto, determinándose cuantos puntos se pueden completar. Al planificar según el alcance, se dividió la suma de puntos de las historias de usuario seleccionadas entre la velocidad del proyecto, obteniendo el número de iteraciones necesarias para su implementación.
Tabla 2.12 Velocidad del proyecto
Iteración 1 | Iteración 2 | Iteración 3 | Iteración 4 | ||
Horas | 120,00 | 80,00 | 120,00 | 80,00 | |
Semas | 3 | 2 | 3 | 2 | |
Horas semanales | 40 | 40 | 40 | 40 | |
HU (velocidad del proyecto) | 2 | 3 | 3 | 2 | |
Estimación de esfuerzos por historia de usuario
Para la realización de la solución propuesta se realizó la estimación de esfuerzo la cual se presenta a continuación.
Tabla 2.13 Estimación de esfuerzos por historia de usuario
Nro. | Historia de Usuario | Puntos de estimación (semanas) | |||||||||
1 | Servicio REST | 1.5 | |||||||||
2 | Api REST | 1.5 | |||||||||
3 | Adicionar aplicación | 1 | |||||||||
4 | Listar aplicación | 0.5 | |||||||||
5 | Visualizar aplicación | 0.5 | |||||||||
6 | Listar errores | 1.5 | |||||||||
7 | Generar reporte | 1 | |||||||||
8 | Visualizar errores | 0.5 | |||||||||
9 | Adicionar notificaciones | 1.5 | |||||||||
10 | Listar notificaciones | 1.5 | |||||||||
Plan de Iteraciones
Las historias de usuarios seleccionadas para cada entrega son desarrolladas y probadas en un ciclo de iteración, de acuerdo al orden preestablecido.
Los elementos que deben tomarse en cuenta durante la elaboración del plan de iteraciones son las historias de usuario. Una vez identificadas las historias de usuario, se establecieron cuatro iteraciones para el desarrollo de la aplicación. En la selección de las historias de usuario a implementar se tuvo en cuenta la prioridad que estas presentan y la relación en cuanto a funcionalidad entre las mismas.
Iteración 1: en esta iteración se realizaron las historias de usuarios que hacen referencia al trabajo con el servicio REST debido a la dependencia que existe entre las demás historias de usuarios con respecto a ellas. Las historias de usuario seleccionadas fueron 1 – 2.
Iteración 2: en la segunda iteración se realizaron las historias de usuario 3 – 4 – 5, estas son las encargadas de realizar todas las funcionalidades del manejar aplicación.
Iteración 3: en esta iteración se realizaron las historias de usuario 6 – 7 – 8, estas son las encargadas de realizar operaciones sobre los errores, para la selección de esta iteración se tuvo en cuenta la dependencia que tienen estas historias de usuario con las realizadas en la iteración 1 y 2.
Iteración 4: en esta iteración se realizaron las historias de usuario 9 – 10, estas son las encargadas de realizar el manejar notificación. Para la selección de estas historias de usuario se tuvo en cuenta que las mismas sólo son funcionales si están implementadas las historias de usuario de las iteraciones anteriores.
Plan de duración de las iteraciones
Cada iteración va a estar conformada por las historias de usuarios seleccionadas por el cliente a implementar. En este plan se especifica detalladamente el orden de desarrollo de las historias de usuarios dentro de cada iteración así como la estimación completa de dicha iteración.
Tabla 2.14 Plan de duración de las iteraciones
Iteraciones | Orden de las HU a implementar | Duración (semanas) | |
1 |
| 3 | |
2 |
| 2 | |
3 |
| 3 | |
4 |
| 2 | |
Plan de entrega
El plan de entrega está compuesto por iteraciones de no más de tres semanas. En la primera iteración se puede intentar establecer una arquitectura del sistema que pueda ser utilizada durante el resto del proyecto. Esto se logra escogiendo las historias de usuario que fuercen la creación de esta arquitectura, sin embargo, esto no siempre es posible ya que es el cliente quien decide qué historias de usuario se implementarán en cada iteración (para maximizar el valor de negocio). Al final de la última iteración el sistema estará listo para realizarle las pruebas de software (38).
Tabla 2.15 Plan de entrega
Historia de Usuario | Entrega 1 | Entrega 2 | Entrega 3 | Entrega 4 | Entrega 5 | |
Servicio REST | v1.0 | Finalizado | ||||
API_REST | v1.0 | Finalizado | ||||
Adicionar aplicación | v1.5 | Finalizado | ||||
Listar aplicación | v1.5 | Finalizado | ||||
Visualizar aplicación | v2.0 | Finalizado | ||||
Listar errores | v2.3 | Finalizado | ||||
Visualizar errores | v2.5 | Finalizado | ||||
Generar reporte | v3.0 | Finalizado | ||||
Adicionar notificaciones | v4.0 | Finalizado | ||||
Listar notificaciones | v4.0 | Finalizado | ||||
Tarjetas CRC
Una tarjeta CRC (clase, responsabilidad y colaboración) representa una entidad del sistema, a la cual asigna responsabilidades y colaboraciones. El formato físico de las tarjetas CRC facilita la interacción entre clientes y equipo de desarrollo, y se ejecutan escenarios a partir de especificación de aspectos funcionales o historias de usuarios. De esta forma, van surgiendo las entidades del sistema junto con sus responsabilidades y colaboraciones (39).
Clase: Se refiere a las clases persistentes de sistema a desarrollar.
Responsabilidad: Función que realiza la clase dentro del sistema.
Colaboración: Relación que tiene la clase con otras clases persistentes del sistema.
Una de las principales piezas de diseño empleadas fueron las tarjetas CRC que no sólo sirven como columna vertebral de este, sino que también fueron la base del modelo Entidad-Relación, elaborado para modelar la base de datos. Cada tarjeta CRC se convirtió en un objeto, sus responsabilidades en métodos públicos y sus colaboradores en llamados a otras clases.
En XP el proceso de diseño es iterativo, por lo cual las tarjetas CRC no fueron creadas todas en la primera iteración. Las responsabilidades y los llamados fueron agregados al inicio de cada iteración, al igual que nuevas tarjetas CRC que fueron creadas de modo tal que el diseño se convirtió en un proceso dinámico que se adaptaba a las necesidades planteadas para el momento.
Luego de un estudio bibliográfico se determinó que XP no propone una estrategia para afrontar la implementación de las tarjetas CRC, por lo cual se creó una con la cual se garantizó el poder hacer las pruebas desde el mismo momento de la implementación. Primero fueron implementadas las clases que no hacía llamados a ninguna otra, luego se implementaron las que realizaban llamados a las clases ya implementadas. Aunque XP no tiene descrita una metodología para implementar un modelo de CRC, fue importante adoptar la estrategia antes expuesta, debido a que era la forma más cómoda para poder aplicar las pruebas en todo momento.
Modelo de datos
Un modelo de datos es una parte esencial en el proceso de modelado de una base de datos. Este es una estructura abstracta que documenta y organiza la información de los datos y las relaciones entre ellos. El propósito de un modelo de datos es, por una parte, representar los datos y por otra, ser comprensible. En él se describen los datos, las relaciones de datos y la semántica de los datos. A continuación en la Figura 2.2 se muestra el diagrama Entidad-Relación de la solución propuesta.
Figura 2.2 Diagrama Entidad-Relación
Conclusiones del capítulo
Las herramientas seleccionadas en el capítulo anterior demostraron ser consecuentes pues posibilitaron realizar el diseño de la aplicación. El estudio de la audiencia a la que va dirigida la solución delimitó que existen dos tipos de usuarios que interactúan con el sistema con diferentes niveles de acceso. Se definieron cuatro iteraciones que abarcan un total de diez historias de usuarios, que describen los aspectos principales a tener en cuenta para el desarrollo de la solución, brindando una visión futura de las funcionalidades a implementar.
Asociado a estas historias de usuarios se construyó el plan de entregas y siete tarjetas CRC que traducen los requerimientos a entidades a implementar para, de esta manera, pasar a la siguiente fase. Los principios, prácticas y técnicas propuestos por la metodología XP aportan los artefactos necesarios para la implementación de la solución.
Capítulo 3
Implementación y pruebas
En el proceso de desarrollo del software la fase de implementación es importante debido a que se desarrolla cada funcionalidad del sistema y se comprueba que se realizó exactamente lo que estaba propuesto.
La metodología utilizada en este trabajo tiene como fundamento del desarrollo de software, exigiendo que cada programador escriba las pruebas realizadas a su código de producción. Las pruebas se integran en el proceso de desarrollo y construcción del sistema. En este capítulo se describen las pruebas realizadas a la aplicación con el objetivo de verificar si se cumplieron las tareas de ingeniería planificadas para el desarrollo de la aplicación.
Patrones de diseño
Un patrón de diseño es una descripción de clases y objetos que se comunican entre sí y se adaptan para resolver un problema de diseño general en un contexto particular. Los patrones de diseño pretenden proporcionar catálogos de elementos reusables en el diseño de sistemas de software; evitar la reiteración en la búsqueda de soluciones a problemas ya conocidos y solucionados anteriormente; formalizar un vocabulario común entre los diseñadores y estandarizar el modo en que se realiza el diseño.
Cada patrón describe un problema que ocurre una y otra vez en nuestro ambiente, y luego describe el núcleo de la solución a ese problema, de forma tal que esa solución puede ser usada un millón de veces, sin hacerlo de la misma manera dos veces8.
GRASP
GRASP es un acrónimo por sus siglas en inglés General Responsibility Asignment Software Patterns, la asignación eficiente de responsabilidades a los componentes del software es la actividad más importante en el análisis y diseño orientado a objetos. De los patrones GRASP existentes se utilizaron cinco que se refieren a cuestiones y aspectos fundamentales del diseño: Experto, Creador, Controlador, Bajo Acoplamiento y Alta Cohesión (40).
Experto
El patrón Experto resuelve el siguiente problema: ¿Cuál es el principio general para asignar responsabilidades a los objetos? La solución a dicho problema se resuelve asignando una responsabilidad al experto en información, la clase que tiene la información necesaria para realizar la responsabilidad.
Un Experto es una clase que tiene toda la información necesaria para implementar una responsabilidad.
8 C. Alexander, "The Timeless Way of Building", 1979
Experto es uno de los patrones más utilizados al asignar responsabilidades, ya que expresa simplemente la intuición de que los objetos hacen cosas relacionadas con la información que poseen (41).
Entre los beneficios que provee el uso adecuado de este patrón, se encuentra el encapsulamiento de la información y la distribución del comportamiento del manejo de la información.
En la implementación de la propuesta de solución el uso de este patrón se evidencia por ejemplo, cuando es necesario renderizar las vistas para mostrarlas al usuario. En este caso las clases controladoras son las expertas en información y crean los formularios que permiten mostrar los campos requeridos en la vista.
Figura 3.1 Uso del patrón Experto y Creador en el controlador de Reportes
Creador
El patrón Creador resuelve el siguiente problema: ¿Quién debería ser el responsable de la creación de una nueva instancia de alguna clase? La solución a dicho problema es cuando B es un Creador de A si se asigna a la clase B la responsabilidad de crear una instancia de la clase A y si se cumple uno o más de los casos siguientes:
B agrega objetos de A; B contiene objetos de A;
B registra instancias de objetos de A;
B utiliza más estrechamente objetos de A;
B tiene los datos de inicialización que se pasarán a un objeto de A cuando sea creado (por lo tanto, B es un Experto con respecto a la creación de A).
El patrón Creador guía la asignación de responsabilidades relacionadas con la creación de objetos (una tarea común). La intención básica del patrón es encontrar un creador que necesite conectarse al objeto creado en alguna situación (41).
En el desarrollo de la propuesta de solución, la implementación de este patrón se evidencia cuando las clases controladoras crean los formularios ya que son las responsables de crear instancias de la clase Tipo (Type), también cuando la clase controladora crea las entidades que se van a asociar a un determinado formulario, ver Figura 3.1.
Bajo acoplamiento
El patrón Bajo acoplamiento resuelve el siguiente problema: ¿Cómo soportar bajas dependencias, bajo impacto del cambio e incremento de la reutilización? La solución a dicho problema es: Asignar una responsabilidad de manera que el acoplamiento permanezca bajo.
El acoplamiento es una medida de la fuerza con que un elemento está conectado a, tiene conocimiento de, confía en, otros elementos.
Un elemento con bajo (o débil) acoplamiento no depende demasiado de otros elementos.
El patrón Bajo Acoplamiento es un principio a tener en mente en todas las decisiones de diseño. Es un principio evaluativo que aplica un diseñador mientras evalúa todas las decisiones de diseño. El Bajo Acoplamiento soporta clases más independientes.
Entre sus beneficios se puede encontrar que no afectan los cambios en otros componentes; fácil de entender de manera aislada y conveniente para reutilizar (41).
Alta cohesión
El patrón alta cohesión resuelve el siguiente problema: ¿Cómo mantener la complejidad manejable? su solución se da en asignar una responsabilidad de manera que la cohesión permanezca alta. En cuanto al diseño de objetos, la cohesión (cohesión funcional) es una medida de la fuerza con la que se relacionan y del grado de focalización de las responsabilidades de un elemento. Una clase con baja cohesión hace muchas cosas no relacionadas, o hace demasiado trabajo:
Clases difíciles de entender; Difíciles de reutilizar; Difíciles de mantener;
Delicadas, constantemente afectadas por los cambios. Como regla empírica, una clase con alta cohesión tiene:
Un número relativamente pequeño de métodos, con funcionalidad altamente relacionada, No realiza mucho trabajo.
Colabora con otros objetos para compartir el esfuerzo si la tarea es extensa. No es conveniente recargar el trabajo o incluir funcionalidad en la clase que responde a los eventos del sistema (41). Este patrón tiene como beneficio que incrementa la claridad y facilita la comprensión del diseño además de que simplifica el mantenimiento y las mejoras; soporta a menudo bajo acoplamiento e incrementa la reutilización.
Controlador
El patrón Controlador resuelve el siguiente problema: ¿Quién debe ser el responsable de gestionar un evento de entrada del sistema? La solución a este problema es asignar la responsabilidad de recibir o manejar un mensaje de evento del sistema a una clase que representa una de las siguientes operaciones:
Representa el sistema global, dispositivo o subsistema (Controlador de Fachada);
Representa un escenario de caso de uso en el que tiene lugar el evento del sistema (controlador de Sesión de Caso de Uso).
Utilizar la misma clase controlador para todos los eventos del sistema en el mismo escenario de caso de uso;
Una sesión es una instancia de una conversación con un actor (41).
En la estructura que propone Symfony2 este patrón se evidencia dentro de la carpeta Controller que se encuentra en los paquetes de cada Bundle9. En esta carpeta se localizan las clases controladoras de la Herramienta para el monitoreo de las aplicaciones web, que son las responsables de implementar todas las funcionalidades pertenecientes a una interfaz de un componente determinado, reciben los datos del usuario y los utilizan de acuerdo a la acción solicitada.
Figura 3.2 Ejemplo de uso del patrón Controlador
9 Bundle: Un bundle no es más que un directorio que aloja todo aquello relativo a una funcionalidad determinada. Puede incluir clases PHP, plantillas, configuraciones, CSS"s y Javascript. http://juandarodriguez.es/tutoriales/tutorial-de-introduccion-a-symfony2/#bundles.
Patrones arquitectónicos
Modelo-Vista-Controlador (MVC)
Especifican un conjunto predefinido de subsistemas con sus responsabilidades y una serie de recomendaciones para organizar los distintos componentes. La propuesta de solución para el sistema hará uso del patrón Modelo – Vista – Controlador.
Modelo – Vista – Controlado (MVC)
Symfony basa su funcionamiento interno en la arquitectura MVC, utilizada por la mayoría de frameworks web. La utilización de dicho marco de trabajo para el desarrollo del producto conlleva a la implementación de este patrón. El siguiente esquema simplificado muestra el funcionamiento interno de Symfony (ver Figura 3.3) (42).
Figura 3.3 Esquema simplificado de la arquitectura interna de Symfony (42)
Cuando el usuario realiza una solicitud, internamente sucede lo siguiente:
1) El sistema de enrutamiento determina que Controlador está asociado con la página de que responde a la solicitud.
2) Symfony ejecuta el Controlador asociado a la solicitud.
3) El Controlador solicita al Modelo los datos de la petición.
4) Con los datos devueltos por el Modelo, el Controlador solicita a la Vista que cree una página mediante una plantilla y que inserte los datos del Modelo.
5) El Controlador entrega al servidor la página creada por la Vista.
Con Symfony se pueden llegar a hacer cosas muy complejas, pero el funcionamiento interno siempre es el mismo:
1) El Controlador manda y ordena.
2) El Modelo busca la información que se le pide.
3) La Vista crea páginas con plantillas y datos.
La arquitectura MVC proporciona ventajas, como la organización del código, la reutilización y la flexibilidad. Symfony toma lo mejor de la arquitectura MVC y la implementa de forma que el desarrollo de aplicaciones sea rápido y sencillo.
Uso de componentes de terceros
La complejidad de los sistemas computacionales actuales, ha llevado a buscar la reutilización del software existente. El desarrollo de software basado en componentes permite reutilizar piezas de código pre-elaborado que permiten realizar diversas tareas, conllevando a diversos beneficios como las mejoras a la calidad, la reducción del ciclo de desarrollo y el mayor retorno sobre la inversión. Para el desarrollo del Sistema de Monitorización de errores se utilizaron los siguientes componentes.
Plug-in DataTable.js
DataTable.js es un plug-in para la biblioteca jQuery Javascript. Es una herramienta flexible, en base a los fundamentos de la mejora progresiva, que se sumarán los controles avanzados de interacción a cualquier tabla HTML. Está desarrollada bajo una licencia totalmente gratuita10.
Librería AlivePDF.swc
AlivePDF.swc es una librería de código abierto, desarrollada con el fin de convertir a formato PDF, esta librería se emplea en el sistema para exportar los reportes que generan los usuarios11.
Bundle SpraedPDFGeneratorBundle
SpraedPDFGeneratorBundle genera documentos HTML a PDF. El paquete te da la oportunidad de agregar un encabezado y pie de página con mucha facilidad. Funciona con una pequeña biblioteca jar. Por lo que necesita para ejecutar Java en el servidor (Java 6 o posterior). El sistema lo utiliza para generar los reportes que son enviados por correo en las notificaciones a los diferentes usuarios12.
Bundle FosRestBundle
Este paquete proporciona varias herramientas para desarrollar rápidamente API RESTfull y aplicaciones con Symfony2. Las características incluyen13:
Una capa de la Vista para permitir la salida y formatear Controladores agnósticos.
Un cargador de ruta personalizada para generar siguientes convenciones REST de url.
Acepta negociación de formato de cabecera incluyendo el manejo de tipos MIME personalizados.
Decodificación REST de solicitud HTTP cuerpo y aceptar encabezados.
Controlador de excepciones para el envío de códigos de estado HTTP apropiadas.
10 Para más información consulte http://DataTables.net
11 Para más información consulte http://www.alivepdf.org/
12 Para obtener información visite http://www.spraed.com
13 Para más información visite http://symfohub.com/repo/FOSRestBundle/documentation
Desarrollo de las iteraciones Tareas de ingeniería
Las tareas de ingeniería se usan para describir las tareas que se realizan sobre el proyecto, estas pueden ser: desarrollo, corrección, mejora, etc. Estas tareas tienen relación con una historia de usuario; se especifica la fecha de inicio y fin de la tarea, se nombra al programador responsable de cumplirla y se describe que se tratara de hacer en la tarea (15).
Iteración 1
Iteración 2
Iteración 3
Iteración 4
Tabla 3.15 Tareas de Ingeniería 15: Eliminar notificaciones
Pruebas de software
Las pruebas de software, en inglés testing son los procesos que permiten verificar y revelar la calidad de un producto software. Son utilizadas para identificar posibles fallos de implementación, calidad, o usabilidad de un programa de ordenador o videojuego. Básicamente es una fase en el desarrollo de software consistente en probar las aplicaciones construidas.
Diseño de las pruebas
Después de un estudio bibliográfico se arribó a la conclusión de que la metodología XP propone un modelo inverso al propuesto por las metodologías tradicionales en cuanto a la fase de prueba se refiere, las últimas proponen la descripción y realización de las mismas al final del proyecto o finalización de cada módulo, la primera propone que lo primero a realizar es la descripción de las pruebas a pasar por el sistema (37).
Pruebas de integración
"La prueba de integración es una técnica sistemática para construir la estructura del programa mientras que, al mismo tiempo, se llevan a cabo pruebas para detectar error es asociados con la interacción. El objetivo es tomar los módulos probados mediante la prueba de aceptación y construir una estructura de programa que esté de acuerdo con lo que dicta el diseño" (43).
Luego de realizar las pruebas de integración del bundle Report en la aplicación "ZERA Support", se obtuvo como resultado el correcto funcionamiento de las HU.
Pruebas de aceptación
Luego del análisis bibliográfico se arribó a la conclusión que el objetivo de estas pruebas es verificar los aspectos funcionales, por este motivo, las propias funcionalidades del sistema son la principal fuente de información a la hora de construir las pruebas de aceptación.
Las pruebas de aceptación son creadas a partir de las historias de usuario. Durante una iteración la historia de usuario seleccionada en la planificación de iteraciones se convertirá en una prueba de aceptación.
Una prueba de aceptación es como una caja negra. Cada una de ellas representa una salida esperada del sistema. Es responsabilidad del cliente verificar la corrección de las pruebas de aceptación y tomar decisiones acerca de las mismas. La garantía de calidad es una parte esencial en el proceso de XP (43).
A continuación se muestran las pruebas de aceptación realizadas al sistema.
Tabla 3.16 Prueba de aceptación 1: Servicio REST
Tabla 3.17 Prueba de aceptación 2: Clase de conexión con las aplicaciones
Tabla 3.18 Prueba de aceptación 3: Gestionar aplicaciones
Tabla 3.19 Prueba de aceptación 4: Visualizar detalles de las aplicaciones
Tabla 3.20 Prueba de aceptación 5: Listar errores
Tabla 3.21 Prueba de aceptación 6: Opciones de los errores
Tabla 3.22 Prueba de aceptación 7: Filtrar errores
Tabla 3.23 Prueba de aceptación 8: Generar reportes
Tabla 3.24 Prueba de aceptación 9: Adicionar notificaciones
Tabla 3.25 Prueba de aceptación 10: Listar y eliminar notificaciones
Resultados de las pruebas
Gráfica 3.1 Resultados de las pruebas
En el transcurso de las iteraciones se le realizaron las pruebas de aceptación al sistema, se encontraron un total de veinticuatro no conformidades, de ellas tres fueron consideras significativas según su importancia en el negocio. Al concluir las iteraciones, el equipo de desarrollo dio solución a la totalidad de las no conformidades detectadas, priorizando las clasificadas en estado significativo.
Resultados obtenidos
Se ha creado un sistema que brinda a los desarrolladores la posibilidad de realizar monitoreo de los errores generados en las aplicaciones web. El sistema se encarga de notificar los reportes, garantizando así un constante control del estado de las aplicaciones. Con el uso del servicio "reportar" se establece la conexión entre el Sistema de monitoreo y las aplicaciones a controlar.
Conclusiones del capítulo
Se facilitó la implementación de la propuesta de solución como resultado del estudio bibliográfico y de las soluciones similares, que permitió la selección de las herramientas, tecnologías y lenguajes de programación adecuados.
Se constató que cada funcionalidad se corresponde con lo definido inicialmente por el cliente.
El análisis de las pruebas realizadas validó que las herramientas y metodologías seleccionadas para solucionar el Problema de la investigación es la correcta, pues la cantidad de no conformidades que prevalecen es las no significativas que son mínimas.
Conclusiones generales
La evolución de la presente investigación permitió la obtención de una herramienta para el monitoreo de errores en la aplicación web. Esta cumple con todos los aspectos funcionales básicos para su desarrollo, cumpliendo así con los objetivos trazados para alcanzar los resultados esperados.
Estos resultados permitieron concluir los siguientes enunciados:
La fundamentación teórica realizada en la investigación posibilitó justificar la selección de la metodología de desarrollo, los patrones de diseño, de arquitectura y las herramientas a utilizar para el desarrollo del sistema.
La herramienta para el monitoreo de aplicaciones web proporcionó la posibilidad de generar reportes de los errores, administrar las notificaciones y ofrecer un alto nivel de seguridad en la transferencia de los datos mediante el servicio REST.
La propuesta de solución al problema identificado contribuyó al logro del control constante de la calidad de las aplicaciones web.
Se comprobó la efectividad de la solución propuesta a partir de los resultados satisfactorios obtenidos en las evaluaciones internas realizadas por el proyecto, pues la totalidad de las no conformidades detectadas durante las iteraciones de pruebas definidas, fueron resueltas por el equipo de desarrollo.
Recomendaciones
Como parte del proceso de investigación y desarrollo de la aplicación, surgieron ideas que son recomendables tener en cuenta para el futuro mejoramiento de la solución propuesta. Entre ellas se señalan:
1. Se recomienda al cliente para posteriores versiones, adicionar retroalimentación a los errores con el fin de proveer a los desarrolladores de herramientas para una rápida solución de errores similares.
2. A la dirección del centro FORTES, generalizar el presente trabajo a los demás Centros de desarrollo de la UCI.
Referencias bibliográficas
1. Cabrera, A. M. C. 2006. Impacto de las TIC en la educación: un acercamiento desde el punto de vista de las funciones de la educación. ISSN 1575-9393.
2. Labrada, Sonia Morejón. 2011. El software educativo un medio de enseñanza eficiente. [En línea] http://www.eumed.net/rev/ced/29/sml.pdf.
3. Internet Assigned Numbers Authority. Hypertext Transfer Protocol (HTTP) Status Code Registry. [En línea] Internet Assigned Numbers Authority, 17 de febrero de 2014. www.iana.org/assignments/http-status-codes/http-status-codes.xhtml.
4. AltoNivel.com.mx. 3 herramientas para medir el desempeño de tu sitio. [En línea] http://www.altonivel.com.mx/33627-3-herramientas-para-medir-el-desempeno-de-tu-sitio.html.
5. ProgramaSoftware.com. Herramientas Alexa para sitios web. [En línea] http://www.programasoftware.com/herramientas-alexa-para-sitios-web/.
6. Baluart.net. Site24x7, para Monitorear Sitios Web. [En línea] 6 de marzo de 2007. http://www.baluart.net/articulo/site24x7-para-monitorear-sitios-web.
7. Herramientas 2.0. Herramientas Web 2.0 para el trabajo en competencias. [En línea] http://herramientas20.wordpress.com/category/herramientas-20/pagina-de-inicio/netvibes/.
8. ManageEngine. Funciones de monitoreo de redes. [En línea] 2013. http://www.manageengine.com.mx/network-monitoring/url-monitoring.html.
9. Dos ideas. Ágil. [En línea] http://www.dosideas.com/wiki/Desarrollo_Agil_De_Software.
10. Ecured. Metodologías de desarrollo de software. [En línea] http://www.ecured.cu/index.php/Metodologías_de_desarrollo_de_software.
11. Cohen, Mike. Una Introducción a Scrum. [En línea] Noviembre de 2013. http://www.dc.fi.udc.es/~cabalar/md/scrum.pdf.
12. Carnós, José H. (et. al.). 2003. Metodologías Ágiles en el Desarrollo de Software. Alicante – España : Grupo ISSI.
13. Palacio, J. 2007. Flexibilidad con Scrum, principios de diseño e implantación en campos Scrum. s.I. :SafeCreative.
14. Faculta de Informática, Cs. De la Comunicación y Téc. Especiales. Morón, Universidad. Metodologías Ágiles. [En línea] http://noqualityinside.com/nqi/nqifiles/Metodologias_Agiles.pdf.
15. Beck, Kent. 1999. Extreme Programming Explained: Embrace Change. s.l. : Addison- Wesley Pub Co.
16. Wikiudo. Metodologías SCRUM y XP. [En línea] http://wiki.monagas.udo.edu.ve/.
17. Wesley, Addison. Una explicación de la programación extrema. Aceptar el cambio.
18. Rumbaugh, James, J, I y Booch, Gragy. 2000. El Lenguaje Unificado de Modelado.
Madrid : s.n. pág. 528, Manual de Referencia. ISBN 84-7829-037-0.
19. Dpto. de Sistemas de Informáticos y Computación. Introducción a Herramientas CASE y System Architect. UNIVERSIDAD POLITÉCNICA DE VALENCIA.
20. UML CASE. UML CASE tool for software development. [En línea] http://www.visual- paradigm.com/product/vpuml/.
21. Franganillo, Jorge. HTML5: el nuevo estándar básico del web. [En línea] [Citado el: 29 de Enero de 2014.] http://thinkepi.net/html5-nuevo-estandar-basico-del-web.
22. W3C. HTML & CSS – W3C. [En línea] http://www.w3.org/standards/webdesign/htmlcss#whatcss.
23. Suárez Santos, Humberto y Verdecia Alá, Pedro Manuel. 2008. Arquitectura de Software General de Auditoría. La Habana : s.n. SN.
24. PHP.net. PHP Nuevas Caacterísticas-Manual. PHP.net. [En línea] [Citado el: 30 de Enero de 2014.] http://www.php.net/manual/es/migration54.new-features.php.
25. Lic. Pacheco Aguila, Yoandry. AJAX un nuevo acercamiento a las aplicaciones Web (página 2) – Monografias.com.
26. PHP.net. ¿Qué se puede hacer con PHP? PHP.net. [En línea] [Citado el: 20 de Enero de 2014.] http://www.php.net/manual/es/intro-whatcando.php.
27. Alvarez, Miguel Angel. Manual de Jquery. [En línea] 2010. [Citado el: 30 de Enero de 2014.] http://www.biblioteca-digital.net.ve/wordpress/wp- content/uploads/2010/07/manualjquery.pdf.
28. twitterBootstrap. Bootstrap. Bootstrap. [En línea] [Citado el: 15 de Nobiembre de 2013.] http://twitter.github.io/bootstrap/index.html.
29. Potencier, Fabien. Symfony 2.4.0 released – Symfony. [En línea] Diciembre de 2013. http://symfony.com/blog/symfony-2-4-0-released.
30. Symfony.es. Se publica Symfony 2.4.0. [En línea] http://symfony.es/noticias/2013/12/04/se- publica-symfony-240/.
 Página anterior | Volver al principio del trabajo | Página siguiente  |