Aplicación web para la gestión de tareas siguiendo la metodología GTD
Abstract
El Trabajo Final de Grado tiene por finalidad ofrecer una solución que ayude a las personas a gestionar sus tareas tanto personales como empresariales de una manera más productiva. Actualmente este tipo de aplicaciones tienen mucho éxito. Se decidió que el desarrollo de esta aplicación fuera con la metodología Getting Things Done (GTD) ya que es una metodología que aumenta la productividad y reduce el estrés laboral. A día de hoy, no hay muchas aplicaciones que utilice esta metodología y las que la utilizan lo hace de una forma muy básica. Junto a esta metodología y guiándonos de la experiencia del tutor se intentó combinar esta metodología con controles de tiempo para mejorar aún más la productividad de las personas que utiliza dicho software. El resultado obtenido de este trabajo final de grado fue la base de una aplicación web para la gestión de tareas. El software creado es totalmente funcional, muy fácil de usar, muy intuitivo, y usa la filosofía Getting Things Done . Básicamente los objetivos principales conseguidos en este proyecto fueron: la gestión de usuarios. La gestión de tareas y proyectos. Aplicación de la metodología GTD. Control del tiempo productivo, e improductivo, interrupciones, temporizadores. La aplicación ha sido realizada como Trabajo Final de Grado en Ingeniería Informática, cumpliendo con todas las fases del desarrollo del software, para obtener un producto funcional que fuera aprobado por el tutor que haría el rol de potencial cliente. En el presente proyecto se ha seguido la metodología RUP, dirigida por casos de uso, iterativa e incremental. Para completar el proceso se ha realizado la elaboración de una lista de características, la especificación de los casos de uso, una fase de análisis, una de diseño, implementación y prueba. Las tecnologías utilizadas han sido, principalmente, Ruby On Rails, HTML5, CSS , AJAX y JAVASCRIPT. El objetivo a largo plazo es que esta solución pueda ser tomada como base de implementación, donde haciendo las mejoras necesarias se pueda poner en el mercado un gran software de gestión de tareas siguiendo la metodología GTD.
Full text
Memoria Trabajo Fin de Grado Escuela de Ingeniería Informática Universidad de Las Palmas de Gran Canaria Aplicación web para la gestión de tareas siguiendo la metodología GTD Autor: José Aythami Ramírez Medina Tutor: Javier Sánchez Pérez Las Palmas de Gran Canaria Diciembre 2013
Página 2 Agradecimientos Quisiera dar las gracias a todas aquellas personas que ha contribuido y propiciado que este proyecto haya salido adelante. En primer lugar a mi familia por estar siempre apoyándome y confiar en mí en todo momento. A mi tutor Javier Sánchez Pérez, por su inestimable ayuda, sin el cual este proyecto no hubiera sido posible . A mis amigos que han brindado su apoyo y ánimos y sin los que no estaría en donde estoy. Me gustaría dar un agradecimiento especial a mi amigo John Wu Wu, el cual me ha apoyado en todo momento a lo largo de este proyecto. ¡A todos, gracias!
Página 3
Página 4 Resumen El presente trabajo final de grado tiene por finalidad ofrecer una solución que ayude a las personas a gestionar sus tareas tanto personales como empresariales de una manera más productiva. Actualmente este tipo de aplicaciones tienen mucho éxito. Se decidió que el desarrollo de esta aplicación fuera con la metodología Getting Things Done (GTD), ya que es una metodología que aumenta la productividad y reduce el estrés laboral. A día de hoy, no hay muchas aplicaciones que utilicen esta metodología, y las que las utilizan lo hace de una forma muy básica. Junto a esta metodología y guiándonos de la experiencia del tutor se intentó combinar esta metodología con controles de tiempo para mejorar aún más la productividad de las personas que utiliza dicho software. El resultado obtenido de este trabajo final de grado fue la base de una aplicación web para la gestión de tareas. El software creado es totalmente funcional, muy fácil de usar, muy intuitivo, y usa la filosofía Getting Things Done. Básicamente los objetivos principales conseguidos en este proyecto fueron: - La gestión de usuarios - La gestión de tareas y proyectos - Aplicación de la metodología GTD - Control del tiempo productivo, e improductivo, interrupciones, temporizadores. La aplicación ha sido realizada como trabajo final de grado en ingeniería informática, cumpliendo con todas las fases del desarrollo del software; para obtener un producto funcional que fuera aprobado por el tutor que haría el rol de potencial cliente. En el presente proyecto se ha seguido la metodología RUP, dirigida por casos de uso, iterativa e incremental. Para completar el proceso se ha realizado la elaboración de una lista de características, la especificación de los casos de uso, una fase de análisis, una de diseño, implementación y prueba. Las tecnologías utilizadas han sido, principalmente, Ruby On Rails, HTML5, CSS , AJAX y JAVASCRIPT. El objetivo a largo plazo es que esta solución pueda ser tomada como base de implementación, donde haciendo las mejoras necesarias se pueda poner en el mercado un gran software de gestión de tareas siguiendo la metodología GTD.
Página 5
Página 6 Abstract This final work degree is intended to provide a solution that helps people manage their personal and business tasks in a more productive way. Currently these applications are very successful. It was decided to develope this application using the Getting Things Done (GTD) methodology that increases productivity and reduces stress. Today, there are not many applications that use this methodology and the ones which use it, only use it at very basic levels. Along with this methodology and the Project Tutor's experience and guidance, we aim to combine this methodology with time controls to enhance the productivity of people who use this software even further. As a result of this final work degree we obtained the basis for a web-based application for managing tasks. The software created is fully functional, easy to use, very intuitive and uses the Getting Things Done philosophy. Basically the main objectives achieved in this project are: - User management - The management of tasks and projects - Application of the GTD methodology - Control of productive and unproductive time, interruptions and timers. The application has been made as a final work degree in computer engineering, accomplishing with all the phases of software development, in order to get a functional product approved by the tutor who would act as a potential customer. In this project, the methodology followed was RUP, a case driven, iterative and incremental methodology. We have elaborated a list of features, a specification of use cases, an analysis phase, a design, implementation and testing in order to fully complete the process. The technologies used are, Ruby On Rails, HTML5, CSS, AJAX and Javascript. The long term objective is that this solution can be taken as a basis for future implementations, in which after providing the necessary improvements, can on the market a great task management software following the GTD methodology.
Página 7
Página 8 "El viaje más largo comienza con un primer paso" Proverbio chino "Yo antes pesaba que los grandes proyectos los hacían las grandes personas, y ahora me doy cuenta que los grandes proyectos hacen a las personas grandes Anónimo
Página 9
Página 16 etc. Si el estrés es muy intenso y se prolonga en el tiempo, puede llegar a producir enfermedades físicas y desórdenes mentales, en definitiva problemas de salud. Como se ha observado en las gráficas anteriores, actualmente el estrés supone un problema bastante serio, hay que intentar buscar medidas que ayuden o minimicen los efectos. Este estudio fue el punto de partida para buscar herramientas que ayuden a las personas a quitarse de encima algo de estrés y para ello se ha pensado en la filosofía GTD, que es una filosofía que ayuda a reducir el estrés laboral y personal. Se pensó que si se realiza una herramienta de gestión de tareas personales y laborales usando esta filosofía, se puede reducir en gran medida algo de estrés existente en la actualidad, y de esta forma ayudar positivamente a la sociedad. Por otro lado supondrá un impacto económico bastante grande, ya que este tipo de aplicaciones de gestión de tareas actualmente son de gran interés por las personas que conocen las ventajas de la productividad personal. Para finalizar existiría un impacto tecnológico, ya que actualmente no existe mucho software de este tipo que utilice la metodología GTD. 1.2 Motivación La motivación que determinó la realización de este proyecto final de grado tiene su origen en mi tutor Javier Sánchez Pérez, que me propuso realizar un trabajo final de grado en la creación de un software de ―gestión de tareas siguiendo la metodología GTD”, ya que actualmente este tipo de aplicaciones tiene mucho éxito. Junto a esta metodología y guiándonos de la experiencia que el tutor de este proyecto tiene en relación con software de este tipo, se intentará combinar esta metodología con controles de tiempos, para mejorar aún más la productividad de las personas que utilizan dicho software. Por otro lado, la evolución de las nuevas tecnologías y la aparición de nuevas plataformas de desarrollo ha proporcionado la motivación necesaria para indagar en el conocimiento de lenguajes de programación distintos a los usados durante la carrera. Las tendencias actuales del mercado, me llevó a querer conocer el entorno Ruby On Rails y a estudiar la posibilidad de aplicarlo en futuros proyectos. Así pues, la realización del proyecto final de grado se presentó como una oportunidad inmejorable de ampliar y profundizar en el proceso de especificación y diseño de un sistema. En dicho proceso se reflejará los artefactos usados en las fases que componen el ciclo de vida del software, implantando Ruby On Rails como tecnología de desarrollo.
Página 17 1.3 Objetivos El presente trabajo final de grado cuyo título es "Aplicación web para la gestión de tareas siguiendo la metodología GTD" pretende establecer una guía y base sólida que sustente la implementación de un sistema software. Este proyecto se inicia partiendo de una idea concebida tanto de mi tutor de proyecto como mía. Tras un estudio previo viendo software similares al que se desea realizar, y documentando nuestras ideas preconcebidas, decidimos que éste fuera mi trabajo final de grado. Dada la naturaleza de un trabajo final de grado, se pretende que el proyecto supere la frontera del análisis y diseño establecida por la metodología y se adentre en la implementación y construcción del sistema. Para poder realizar esta serie de propósitos, se establecen a modo de control ciertos objetivos de diferentes índoles. Los objetivos generales que se desea conseguir son los que aparecen en la siguiente lista: Mostrar las competencias adquiridas durante el proceso de formación del alumno. El proyecto final de grado sirve en cierta medida como validador de la capacidad del alumno para enfrentarse a un trabajo real del mercado laboral. Esta afirmación anterior conlleva la rápida asimilación de una tecnología y una constante evolución de las técnicas de diseño y programación. En el proyecto se han tenido que agregar conocimientos adquiridos durante la titulación como: Base de datos Programación Ingeniería del software Diseño de interfaces Otras.... El desarrollo del software es un proceso de aprendizaje continuo en donde debemos ser capaces de adaptarnos con facilidad. Aprender adaptarse ante los cambios que surgen de manera imprevistas durante el desarrollo del software. Potenciar el trabajo del equipo, aunque este proyecto es individual hay que hablar con el cliente para saber que se desea, en esta ocasión el cliente es mi tutor de proyecto, así que este proyecto es un trabajo de ambos. Aprender adaptarnos a metodologías ágil de desarrollo, documentando cada fase del proceso en cada momento. Los objetivos específicos que se desea conseguir son los que aparecen en la siguiente lista: Gestión de acceso de usuarios al sistema. Se controla la fase de registro y autenticación al sistema. Gestión de tareas. Se dará posibilidad al usuario de que pueda crear y gestionar sus tareas. Gestión de proyectos. Los usuarios del sistema podrán crear proyectos asociados a tareas o a otros proyectos.
Página 18 Gestión de interrupciones. Los usuarios subscritos al sistema podrán interrumpir y coordinar las interrupciones producidas cuando tienen una tarea en marcha. Gestión GTD. Las tareas serán gestionadas siguiendo la filosofía GTD. Construcción de una aplicación web mediante el uso de tecnologías como ruby and rails Utilización de sistema de control de versiones 1.4 Gestión de Tareas Como se ha mencionado anteriormente el presente proyecto es un software de gestión de tareas en donde se intentará organizar el trabajo tal y como describe David Allen el creador de Getting Things Done (GTD). David Allen en su libro “Organízate con eficacia” nos intenta demostrar que existe un sistema de organización del trabajo que nos permite liberar la mente de las tensiones que inhiben nuestra creatividad, y que nos hace más eficaces en todos los aspectos de la vida. David Allen sostiene que nuestra mente tiene una capacidad limitada para almacenar información y propone una serie de fórmulas prácticas para eliminar las tensiones e incrementar nuestra capacidad de trabajo y nuestro rendimiento. Organízate con eficacia se fundamenta en unas sencillas normas básicas de organización del tiempo, como por ejemplo la necesidad de determinar cuál es el siguiente paso a dar en cada uno de nuestros proyectos, o la regla de los dos minutos (si surge una tarea pendiente y se puede hacer en menos de dos minutos, debe hacerse inmediatamente). El sistema propuesto por Allen soluciona ansiedades y desconciertos, y nos permite transformar nuestro modo de trabajar y la manera de percibir nuestros retos cotidianos. Esta filosofía de vida tanto social como empresarial puede resultar en un principio caótica pero se ha demostrado en muchos estudios anteriores que realmente es una metodología que aumenta la productividad y reduce el estrés laboral. Por eso, y teniendo presente estas afirmaciones anteriores el presente trabajo final de grado usará esta increíble metodología de organización. La explicación de la metodología en sí se explicará en futuros apartados, el apartado concreto será el 5.1.1 1.5 Estructura del Documento El presente proyecto está bastante orientado a la rama de ingeniería del software en donde en cada capítulo incluye un marco teórico que respalda las diferentes secciones del documento. Se recomienda al lector que siga el flujo normal del documento. Antes de comenzar a leer el capítulo de implementación es requisito imprescindible haber leído los capítulos de tecnologías y herramientas usadas. La presente documentación está estructura de la siguiente manera:
Página 19 Estado del arte. En este capítulo se hará un estudio sobre los diferentes software encontrados similares a los de este trabajo final de grado. Intentaremos ver las características principales que ofrecen estos software y se buscarán las diferentes características que aportamos frente a los software actuales. Planificación de trabajo: En este capítulo se realizarán diferentes funcionalidades. En primer lugar, hablaremos sobre metodología seleccionada. En esta sección también incluirá el plan de trabajo usado, y analizaremos el presupuesto necesario para crear el trabajo final de grado. Herramientas y Tecnologías: En este capítulo se detallará las herramientas físicas y las tecnologías usadas para proceso de construcción de la aplicación propuesta. Desarrollo de la aplicación: En éste capítulo se describirá el proceso para la realización del trabajo final de grado. Empezaremos por conocer el dominio del problema y modelo de negocio. Una vez entendido el contexto de la aplicación se definirá cuál será la arquitectura de los requisitos más importantes. Tras este punto se hará el análisis de los casos de uso, así como de las operaciones que se realizaran. Continuaremos con el diseño creando los diferentes modelos de la arquitectura del sistema: diagrama de la arquitectura diagrama de clases diagrama de paquetes modelo de despliegue diseño de la base de datos Tras el diseño de la arquitectura lo implementaremos usando las tecnologías mencionadas, y realizaremos diferentes técnicas usadas para evaluar el software implementado. Anexos: En este Capítulo se detallará diferentes apartados para completar la memoria. Algunos de los apartados que nos encontraremos van a ser un manual de usuario para aprender cómo funciona el software. Analizaremos las diferentes competencias cubiertas en este trabajo final de grado. También veremos más en profundidad un apartado sobre metodologías usadas a día de hoy y aprenderemos la información que afecta a la legislación vigente sobre proyectos informáticos similares al TFG.
Página 20 Capítulo 2: Estado Actual del Arte El presente capítulo intentará introducir al lector en un breve estudio sobre aplicaciones similares encontradas actualmente en el mercado referente a este trabajo final de grado. Esta sección está organizada de la siguiente manera: 1. Listado de las aplicaciones encontradas en el mercado a día de hoy divididas en tres secciones diferentes: Aplicaciones generales Aplicaciones usando la filosofía GTD Aplicaciones en dispositivos móviles 2. Introducción de diferentes características que intentaremos estudiar en cada una de las aplicaciones que vamos a exponer. 3. Estudio de algunas de las aplicaciones encontradas para las tres categorías mencionadas anteriormente. 4. Comparación de nuestra aplicación con las anteriores estudiadas, veremos que características diferentes aportamos en comparación a las demás aplicaciones del mismo estilo. Para este estudio se han seleccionado una serie de 43 aplicaciones diferentes encontradas actualmente en el mercado. De las 43 listadas aquí analizaremos las tres primeras de cada bloque. Nombre del software General GTD Móvil 1. Pivotal tracker 2. Trello 3. teambox 4. Achievo 5. Clocking IT 6. Todoyu 7. WebCollab 8. EGroupWare 9. Redmine 10. Trac 11. Google Tasks 12. Mantis 13. Dotproject 14. Basecamp 15. ActiveCollab 16. Wunderlist 17. Groupcamp projects 18. Celoxis 19. Harvest 20. Mavanlink 1. Nirvana 2. Toodledo 3. Things 4. Famundo 5. Remember the milk 6. GTDagenda 7. Mytodos 8. Nexty 9. Vitalist 10. Todo.ly 11. Teux deux 12. Todoist 13. Toodledo 14. Things 15. Omnifocus 1. Google Keep 2. Evernote 3. Astrid 4. Colornote 5. Ak notepad 6. Catch notes 7. Wunderlist 8. Any.do 9. Remember the milk 10. Gtasks
Página 21 Las características que se intentará estudiar en cada una de las aplicaciones son las siguientes: Planificación Una de las tareas más comunes en el manejo de proyecto es la planificación de una serie de eventos. Algunas de las dificultades para la planificación de proyecto pueden ser: Eventos que dependen de la creación de otros eventos. Planear que las personas trabajen en las tareas requeridas. Asignar los recursos necesarios a las tareas. Manejo de las incertidumbres con las estimaciones de duración de ciertas tareas. Acomodar las tareas para cumplir con ciertos hitos. Manejar varios proyectos simultáneamente para cubrir los requerimientos. Provisión de la información Para poder justificar todo el tiempo que se emplea en utilizar el software de manejo de proyectos. Los requerimientos típicos entre los programas más comunes son: Listas de tareas por persona. Listas de planificación de recursos. Información del tiempo que las tareas requerirán para su terminación. Advertencia temprana de posibles riesgos para el proyecto. Información de la carga de trabajo y los días feriados o vacaciones para los empleados. Información histórica de cómo han progresado proyectos similares anteriormente desarrollados. Basado en el Web El software de la administración de proyectos se puede poner en ejecución con una Aplicación Web. De esta forma se accede a través de una Intranet o de una Extranet usando un web browser. Esto tiene varias ventajas y desventajas de aplicaciones web: Se puede acceder desde cualquier tipo de computadora sin la instalación de software. Facilidad del control de acceso. Naturalmente multiusuario. Solamente una instalación/versión de software para mantener. Originalmente es más lento para responder que las aplicaciones de escritorio. Capacidad gráfica más limitada que las aplicaciones de escritorios.
Página 22 A continuación, una vez estudiado los puntos que se intentará analizar en cada software. Se empezará a presentar cada software observando las características más interesantes de cada uno de ellos. 2.1 General 2.1.1 Pivotal Tracker Es un gestor de proyectos con una fuerte orientación a metodologías ágiles. Este programa se ejecuta en el navegador. Las tareas no se estiman en horas, sino en puntos que determinan tras un tiempo la velocidad del equipo. Se trata de un servicio gratuito, también en la nube, con posibilidad de crear múltiples proyectos y de asignarles personas con diversos roles. Las tareas se crean en la nevera (the Icebox) y se van organizando dinámicamente en función de parámetros variables, como los hitos definidos, el ritmo del equipo y las tareas pendientes.
Página 23 2.1.2 Teambox Es una plataforma segura de gestión de proyectos, que permite la colaboración entre equipos simplificando la comunicación en un entorno orientado a tareas. La comunicación dentro de la herramienta es totalmente virtual y social. Teambox posee un chat potente y amigable, y listas de tareas para estructurar todos los proyectos, así como conversaciones que puedes convertir en acciones.Las notas te permiten compartir documentación con tu equipo como si se tratara de un Wiki, generando una mayor inmersión por parte de todo el equipo en el proyecto. Este software dispone de un sistema de time tracking, permitiendo la gestión del tiempo de cada proyecto y tarea. Además permite la integración de archivos con Google Docs, Dropbox.., como si se tratara de una carpeta compartida.
Página 24 2.1.3 Trello Trello es un nuevo sistema creado para facilitar el trabajo y la colaboración entre miembros de un mismo grupo. La idea es permitir que cualquier líder vea lo que está haciendo su equipo en un momento determinado, ofreciendo para ello un panel de información bastante completo e intuitivo. Podemos asignar tareas a cualquier persona y usar el concepto de ―tarjeta‖ para cada proyecto, que incluye las conversaciones, actividades, archivos adjuntos, actualizaciones, etc. Para incluir una persona en una tarjeta específica, simplemente tenemos que arrastrarla y soltarla en la deseada.
Página 25 2.2 Getting Thing Done(GTD) 2.2.1 Nirvana Nirvana es una sólida opción para la gestión de tareas gracias a que permite una manipulación súper sencilla de su interfaz (con un espléndido uso del drag and drop a la cabeza) y sus funciones completísimas. Además de un diseño altamente intuitivo, Nirvana ofrece adición de tareas desde el correo electrónico, búsquedas rápidas, notificaciones externas, exportación, etc. Nirvana es un software que se accede a través de un navegador web, una característica importante es su facilidad del control de acceso.
Página 32 En estas circunstancias, un proceso puede ser estable. Sin este equilibrio de tecnologías, herramientas, personas y organización, el uso del proceso sería bastante arriesgado. Las secciones siguientes se abordarán los grupos metodológicos, se hará un balance de lo que nos puede aportar, y se decidirá por la que será la metodología elegida para nuestro trabajo final de grado. 3.1.2 Proceso Unificado de Desarrollo El Proceso Unificado de Desarrollo de Software (PUD) es una metodología propuesta por Ivar Jacobson, Grady Booch y James Rumbaugh para realizar desarrollo de software. Un proceso de desarrollo de software es el conjunto de actividades necesarias para transformar los requisitos de un usuario en un sistema software. El Proceso Unificado de Desarrollo Software es un marco de desarrollo de software que se caracteriza por: Estar dirigido por casos de uso: Está dirigido por casos de uso, porque con éstos se especifican las funcionalidades que el sistema proporciona al usuario, es decir, se utilizan para capturar los requisitos funcionales y para definir los contenidos de las iteraciones. La idea es que cada iteración tome un conjunto de casos de uso o escenarios y desarrolle todo el camino a través de las distintas disciplinas: diseño, implementación, prueba, etc. Centrado en la arquitectura: Asume que no existe un modelo único que cubra todos los aspectos del sistema. Por dicho motivo existen múltiples modelos y vistas que definen la arquitectura de software de un sistema. La analogía con la construcción es clara, cuando construyes un edificio existen diversos planos que incluyen los distintos servicios del mismo: electricidad, fontanería, etc. Es iterativo e incremental: Es un marco de desarrollo compuesto de cuatro fases denominadas Inicio, Elaboración, Construcción y Transición. Cada una de estas fases es a su vez dividida en una serie de iteraciones (la de inicio puede incluir varias iteraciones en proyectos grandes). Estas iteraciones ofrecen como resultado un incremento del producto desarrollado que añade o mejora las funcionalidades del sistema en desarrollo. Cada una de estas iteraciones se divide a su vez en una serie de disciplinas que recuerdan a las definidas en el ciclo de vida clásico o en cascada: Análisis de requisitos, Diseño, Implementación y Prueba. Aunque todas las iteraciones suelen incluir trabajo en casi todas las disciplinas, el grado de esfuerzo dentro de cada una de ellas varía a lo largo del proyecto.
Página 33 3.1.2.1 Fases del Proceso Por lo tanto, como se ha mencionado anteriormente el marco de desarrollo del proceso está compuesto de 4 fases que son: inicio, elaboración, construcción y transición. La etapa de inicio tiene como objetivo determinar la visión del proyecto y definir lo que se desea realizar. La etapa de elaboración es dónde se determina la arquitectura óptima del proyecto. Las etapas de construcción y transición tratan de obtener la capacidad operacional inicial y obtener el producto acabado. La figura 3.1 muestra las fases en el proceso de desarrollo unificado. A la izquierda de la misma aparecen las disciplinas o etapas a realizar durante el proceso de creación del software. Los objetivos de cada una de las disciplinas son: Modelado de negocio. Analizar y entender las necesidades del negocio para el cuál se está desarrollando el software. Requisitos. Proveer una base para estimar los costos y el tiempo de desarrollo del sistema. Análisis y diseño. Trasladar los requisitos analizados anteriormente a un sistema automatizado y desarrollar una arquitectura para el sistema. Implementación. Crear software que se ajuste a la arquitectura diseñada y que tenga el comportamiento deseado. Pruebas o test. Asegurarse de que el comportamiento requerido es correcto y que todo lo solicitado está presente. Instalación o despliegue. Producir distribuciones del producto y distribuirlo a los usuarios.
Página 34 Disciplina de soporte. Determinan las fases de control que son necesarias realizar durante el proyecto. Configuración y administración del cambio. Analizar todas las versiones del proyecto. Gestión del proyecto. Planifica los recursos que se deben emplear. Entorno o ambiente. Controlar todo el entorno que rodea a la producción de software 3.1.2.2 Ventajas y Desventajas del Rup A continuación se listan las ventajas y desventajas más relevantes en el Proceso Unificado de Desarrollo Software. Ventajas Desventajas Evaluación en cada fase que permite cambios de objetivos La evaluación de riesgos es compleja Iterativo e incremental Solo existen problemas de comunicación entre el ingeniero del software y el usuario Implementa las mejores prácticas de la ingeriería del software Excesiva flexibilidad para algunos proyectos Dirigido por caso de uso Se pone al cliente en una situación que puede ser incómoda para él Se reduce el riesgo y se tiene versiones operativas desde etapas tempranas. Cliente debe ser capaz de describir y entender a un gran nivel de detalle. Basado en la arquitectura 3.1.2.3. Elección de la Metodología En la actualidad, no hay una metodología universal para el desarrollo de software, sino un conjunto de metodologías en donde tienes que escoger la que mejor se adapte al sistema que quieres realizar. Antes de comenzar hay que aclarar que PUD aunque pueda aparentar ser una metodología ágil y muchas personas lo consideran ágil, ya que es una metodología de carácter adaptativo, iterativo, incremental y unificada no lo es. PUD no es una metodología ágil porque el trabajo que define implica liberaciones muy tardías en entornos de producción. Aunque PUD puede proporcionar feedback en todas las etapas, la respuesta al cambio no es ágil, ya que PUD sigue un marco de trabajo donde se le da gran importancia al proceso de desarrollo. Si los cambios se piden en la fase de transición, estos cambios se harían sobre la versión del producto en la que se ha trabajado durante el ciclo de vida, por lo que el esfuerzo necesario para hacer las modificaciones es mayor, y en consecuencia, el tiempo que tarda el usuario en poder disfrutar de ellos en el entorno de producción también es superior. Una vez aclarado este punto, la elección de la metodología planteada está en si elegimos una metodología tradicional o una metodología ágil.
Página 35 Como hemos observado en capítulos anteriores la metodología tradicional presenta cierta dificultades a la hora de realizar un proyecto, como por ejemplo: Fases previas pueden ser muy costosas dada la especificación de requisitos, análisis y diseño. Perdida de flexibilidad ante cambios Gran importancia en la documentación Desarrollo más lento Por otra lado la metodologías ágiles: Es especialmente definidos para proyectos con requisitos poco definidos o cambiantes usado para equipos pequeños Dada la naturaleza de este proyecto final de grado y sopesando ambas ramas metodológicas se decidió que la metodologías escogida sea PUD (proceso unificado de desarrollo). Los principales motivos de la elección han sido: Que sea un proceso guiado por la arquitectura (especificación de casos de uso) y trabajo junto al usuario final del software. Necesidad de formalizar el proceso con una buena documentación, puesto que proporciona los artefactos y modelos para ello. La metodología se complementará con UML para la descripción de los distintos diagramas del modelado. A ser un proyecto de una sola persona se considera que un proceso guidado iterativo, incrementa, y unificado es una buena opción para desarrollar el software dada la poca experiencia que en este caso posee el desarrollador. Para más información , exíste un anexo (D) como referencia a metodologías ágiles. 3.2. Planificación Temporal 3.2.1 Plan de Trabajo En relación al Plan de Trabajo a llevar a cabo, las etapas a cubrir durante el desarrollo del TFG propuesto fueron las siguientes: Propuesta y requisitos previos: Nos reunimos con nuestros tutor de proyecto para recopilar los requisitos que deberán tener nuestro trabajo de fin de grado para que sea lo suficientemente completo para pasar la aprobación del tribunal y en paralelo ir aprendiendo de forma exhausta el framework Ruby On Rails. Análisis de Requisitos: Una vez recopilada toda la información en las entrevistas con nuestros tutor, extraemos la información importante y la esquematizamos. Definimos, organizamos, cada uno de los requisitos que hayamos extraído y los desarrollamos de forma exhausta. En esta fase también describiremos los casos de
Página 36 uso, evitando en la medida de lo posible la redundancia de los mismos y maximizando la posibilidad de reutilizarlos. Diseño: En esta fase estudiaremos la mejor forma para incorporar la funcionalidad del sistema teniendo en cuenta que usaremos el framework de desarrollo de aplicaciones Ruby On Rails, con especial atención a que haremos uso del patrón Modelo-Vista-Controlador. Implementación: En esta fase codificaremos la aplicación para que sea funcional según hemos especificado en la fase de diseño; además, será necesario aprender la forma de utilizar de forma correcta el framework Ruby On Rails). En esta fase va incluida la creación de la estructuras necesarias para la interacción con el Sistema de Gestión de Bases de Datos (SGBD) . Pruebas: En este paso comprobaremos que la corrección del sistema que hemos desarrollado. En caso de encontrar algún fallo es el momento de solucionarlo y repetir las pruebas. Memoria: Toda la documentación que conforma esta memoria es el resultado de detallar cada uno de los documentos que hemos ido generando a través de la realización de la misma. Presentación: Creación y preparación de la presentación que mostraremos en la etapa de defensa ante el tribunal. 3.2.2 Diagrama de Gantt Una vez explicados los aspectos generales de la gestión del proyecto, procedemos a detallar la planificación del mismo. Para realizar la planificación se ha utilizado una herramienta básica en la rama de ingeniería del software; el diagrama de Gantt. El diagrama de Gantt es una popular herramienta gráfica utilizada para mostrar el tiempo previsto de esfuerzo para realizar un trabajo. A pesar de que, en principio, el diagrama de Gantt no indica las relaciones existentes entre actividades, la posición de cada tarea a lo largo del tiempo hace que se puedan identificar dichas relaciones e independencias. Fue Henry Laurence Gantt quien, entre 1910 y 1915, desarrolló y popularizó este tipo de diagrama en Occidente. En gestión de proyectos, el diagrama de Gantt se ha convertido en una herramienta básica con la finalidad de representar las diferentes unidades mínimas de trabajo y las fases, tareas y actividades programadas como parte de un proyecto. A groso modo, el diagrama está compuesto por un eje vertical donde se establecen las actividades que constituyen el trabajo que se va a ejecutar, y un eje horizontal que muestra en un calendario, la duración de cada una de ellas. En las siguiente página se muestra la figura que contiene la planificación del proyecto completo. La unidad de tiempo básica está expresada en días laborables teniendo en cuenta que cada día de trabajo corresponden a tres horas reales.
Página 37 Según el diagrama de Gantt , mostrado en la figura anterior, podemos decir que el proyecto realizado ha tenido una duración de 170 días, 555 horas, donde se han realizado las fases de diseño, análisis, implementación y documentación, además, de algunas reuniones presenciales con el tutor del proyecto. La tarea que ha durado más tiempo ha sido la de documentación puesto que se comenzó con el hito de 'inicio de proyecto' y finaliza al terminar el proyecto. También en la etapa de implementación nos ha llevado bastante tiempo, aunque si sumamos las etapas de análisis, diseño, implementación y prueba vemos que eso nos lleva un total de 250 horas dedicadas al prototipo. 3.3. Presupuesto En este apartado se va a mostrar de manera detallada el presupuesto desglosado del proyecto, especificando los diferentes gastos que han sido necesarios para su realización. 3.3.1 Resumen de Horas Dedicadas Basándonos en el diagrama de Gantt expuesto en apartados anteriores es posible obtener número de horas totales dedicadas al proyecto. Tabla resumen.- de las etapas con sus respectivas horas Etapas Dedicación (horas) Etapa 1. Propuesta y requisitos previos 20 Etapa 2.Analisis de requisitos 45 Etapa 3.Diseño 50 Etapa 4.Implementación 250 Etapa 5. Prueba 30 Etapa6.Documentación y presentación 160 Dedicación Total 555
Página 38 3.3.2 Resumen de Personal En la siguiente tabla se muestran los cargos correspondientes al personal informático cualificado para realizar las distintas tareas o actividades. Los salarios por hora están en consonancia con los salarios de empleados en empresas similares del sector. Todos los costes son calculados sin I.V.A. Cargo Número de horas Coste hora Total(€) Diseñador 50 25€ 1250 Ingenieros (Programadores) 250 20€ 5000 Responsable de documentación 160 17€ 2.720 8970 3.3.3 Resumen de Hardware En la siguiente tabla se muestran los equipos informáticos adquiridos con su coste de amortización durante el periodo que dura el proyecto. Todos los costes son calculados sin I.V.A Descripción Unidades Coste (€) Coste total (€) Ordenador intel core i5 1 800 800 Teclados logitech g15 1 30 30 Ratón Logitech Mx518 1 25 25 Monitor TFT LG L190TQ 1 100 100 Impresora hp 1 100 100 1055€ 3.3.4 Resumen de Software y Licencias En la siguiente tabla se muestran las herramientas software necesarias para el proyecto. Todos los costes son calculados sin I.V.A. Descripción Unidades Costes (€) Costes total (€) Microsoft office Profesional 2007 1 0 0 Editor Latex 1 0 0 Rails 1 0 0 Mozilla Firefox 1 0 0 Google Chrome 1 0 0
Página 39 Total 0 3.3.5 Resumen de Material Fungible En la siguiente tabla se muestra el material fungible que se estima necesario para la realización del proyecto, así como sus costes. En material de escritorio englobamos folios, bolígrafos, gomas, lápices, clips, carpetas, archivadores, recambios, grapadoras y demás material de oficina. Todos los costes son calculados sin I.V.A. 3.3.6 Resumen del Presupuesto Total En la siguiente tabla se muestra el sumatorio de los totales anteriormente calculados pero sin el I.V.A. incluido. A la suma de los costes le vamos a añadir un veinte por ciento en concepto de costes indirectos, lo cual equilibrará los riesgos del proyecto y aquellos otros valores que no se han tenido en cuenta al realizar el presupuesto. Descripción Costes totales(€) Material de escritorio variado 150 Recambios de impresora 100 Total 250€ Descripción Costes totales (€) Equipo de trabajo 10.275€ Amortización 120€ Subcontratación de tareas 0 Coste de funcionamiento 900€ Costes indirectos (20 %) 2.526€ Total 13821€
Página 40 Capítulo 4: Herramientas y Tecnologías 4.1 Tecnologías En este capítulo y el siguiente mencionaremos las herramientas y tecnologías que entran en juego durante todo el proceso de desarrollo del software. Se incluye estos capítulos antes de la fase de implementación debido a que partes de las tecnologías que se usan ya estaban planificadas antes de las fases de diseño e implementación. Las tecnologías que se expondrán a continuación son las siguientes: Ruby como lenguaje para la lógica de negocio HTML5 y CSS3 para la maquetación de vistas Javascript como lenguaje en lado del cliente JSON para el intercambio de datos MySQL como sistema de gestión de bases de datos 4.1.1 Ruby como Lenguaje para la Lógica Ruby es un lenguaje , interpretado, reflexivo y orientado a objetos. Fue creado por el programador japonés Yukihiro Matsumoto, quien comenzó a trabajar en Ruby en 1993, y lo presentó públicamente en 1995. Este lenguaje combina una sintaxis inspirada en Python y Perl y su implementación oficial es distribuida bajo una licencia de software libre. Como se ha mencionado Ruby es orientado a objetos: todos los tipos de datos son un objeto, incluidas las clases y tipos que otros lenguajes definen como primitivas (como enteros, booleanos y "nil"). Toda función es un método. Las variables siempre son referencias a objetos, no los objetos mismos. Ruby soporta herencia con enlace dinámico, A pesar de que Ruby no soporta herencia múltiple, se puede simular incluyendo todo los módulos que desees a una clase padre. Ruby ha sido descrito como un lenguaje de programacion multiparadigma: permite programación procedural (definiendo funciones y variables fuera de las clases haciéndolas parte del objeto raíz Object). Soporta reflexión y meta programación, además de soporte para hilos de ejecución gestionados por el intérprete. Ruby tiene tipado dinámico, y soporta polimorfismo de tipos (permite tratar a subclases utilizando la interfaz de la clase padre). Las características más importantes del lenguaje son : Rápido y sencillo: son innecesarias las declaraciones de variables, las variables no tienen tipo y la sintaxis es simple y consistente. Orientado a objetos. Cuatro niveles de ámbito de variable: global, clase, instancia y local. Manejo de excepciones, como Java y Python, para facilitar el manejo de errores. Iteradores y closures (pasando bloques de código). Expresiones regulares nativas Posibilidad de redefinir los operadores (sobrecarga de operadores). Recolección de basura automática. Ruby es fácilmente portable
Página 41 Tiene manejo de hilos independiente del sistema operativo. etc ... 4.1.2 Html5 y Css3 para la Maquetación de Vistas 4.1.2.1 Estructura con Html5 HyperText Markup Language (HTML) es el lenguaje con el que se escribe la estructura y la semántica del contenido de un documento Web. Permite describir la estructura y el contenido en forma de texto, además de complementar el texto con objetos tales como imágenes. Este lenguaje se escribe mediante etiquetas, que aparecen especificadas por corchetes angulares (<y >). Algunos ejemplos de elementos HTML son: <img>, <title>, <p> o <div>. La extensión utilizada para los archivos de formato HTML es.htm ó .html. HTML es un estándar internacional con especificaciones que son mantenidas por el World WideWeb Consortium. Es considerado un "estándar viviente" y está siempre técnicamente bajo construcción. La versión más actual de la especificación HTML se conoce como HTML5. HTML5 es la última versión de HTML y XHTML. El estándar HTML define un solo lenguaje que puede ser escrito usando la sintaxis de HTML, pero también usando la sintaxis más estricta de XML, y también se ocupa de las necesidades de las aplicaciones Web. El marcado estructural es el que describe el propósito del texto, aunque no define cómo severa el elemento. HTML5 no describe el estilo y formato del contenido, sólo el propio contenido y su significado. Para la capa de presentación se usa Cascading Style Sheets(CSS) del que se hablará más adelante. Cabe destacar que HTML permite incluir scripts, hojas de estilos o ficheros en javascript. HTML5 introduce muchas características actuales que permiten a los desarrolladores crear aplicaciones y sitios web con la funcionalidad, velocidad, rendimiento y experiencia de aplicaciones de escritorio. Las características que se introducen en HTML5: Multimedia y gráficos. El navegador se ha convertido en una plataforma de pleno derecho para los juegos, animaciones, películas, cualquier cosa gráfica de verdad. Características como: gráficos vectoriales (SVG y Canvas). API de audio rico y baja latencia de red de WebSockets API de gráficos y tecnologías que permiten crear una experiencia atractiva para los usuarios. Trabajo desconectado de la red. La API permite el uso de la web offline, es decir, aunque no exista conectividad, se podrán usar las aplicaciones en el navegador. Es posible gracias al caché de aplicaciones, su almacenamiento local, etc . Rendimiento. Permite que las aplicaciones web puedan rivalizar con las de escritorio debido a que los motores gráficos han mejorado sustancialmente. Fácil desarrollo. Permite orientar el desarrollo para más tipos de dispositivos con un menor esfuerzo. Seguridad. Las aplicaciones pasan a ser más seguras.
Página 48 Ha sido diseñado para mantenerse estable con grandes volúmenes de datos y transacciones. Es altamente escalable, tanto en la enorme cantidad de datos que puede manejar y en el número de usuarios concurrentes que puede administrar. Es multiplataforma (cuenta con versiones para sistemas operativos Unix y Windows). MYSQL no es sólo un sistema de base de datos de gran alcance capaz de usarse en las empresas, es todo una plataforma de desarrollo sobre la cual puedes desarrollar todo tipo de software que requieren un SGBDR de grandes capacidades. MySQL es un software es Open Source, esto significa que es posible para cualquiera usar y modificar el software. Cualquiera puede bajar el software MySQL desde internet y usarlo sin pagar nada. Si lo desea, puede estudiar el código fuente y cambiarlo para adaptarlo a sus necesidades. El software MySQL usa la licencia GPL (GNU General Public License), para definir lo que puede y no puede hacer con el software en diferentes situaciones. 4.1.6 Otras Tecnologías Relacionadas 4.1.6.1 Ajax El término AJAX fue publicado por Jesse James Garrett el 18 de Febrero de 2005. El término AJAX se puede traducir como (JavaScript asíncrono + XML). Ajax no es una tecnología en sí mismo. En realidad, se trata de varias tecnologías independientes que se unen. Las tecnologías que forman AJAX son: XHTML y CSS. Para crear una presentación basada en estándares. DOM. Para la interacción y manipulación dinámica de la presentación. XML, XSLT y JSON. Para el intercambio y la manipulación de información. XMLHttpRequest. Para el intercambio asíncrono de información. JavaScript. Para unir todas las demás tecnologías. Normalmente, el modelo clásico de las aplicaciones web funciona siguiendo el siguiente esquema: 1. Las acciones del usuario en la interfaz disparan un requerimiento HTTP al servidor web. 2. El servidor efectúa un proceso (recopila información, procesa números, hablando con varios sistemas propietarios), y le devuelve una página HTLM al cliente. Al realizar peticiones continuas al servidor, el usuario debe esperar a que se recargue la página con los cambios solicitados. Si la aplicación debe realizar peticiones continuas, la interacción con el usuario se convierte en algo molesto. AJAX permite mejorar completamente la interacción del usuario con la aplicación, evitando las recargas constantes de la página, ya que el intercambio de información con el servidor se produce en un segundo plano.
Página 49 Las aplicaciones construidas con AJAX eliminan la recarga constante de páginas mediante la creación de un elemento intermedio entre el usuario y el servidor. La nueva capa intermedia de AJAX llamada "Ajax Engine" mejora la respuesta de la aplicación, ya que el usuario nunca se encuentra con una ventana del navegador vacía esperando la respuesta del servidor. A continuación se muestra una imagen comparando ambos modelos el tradicional y usando AJAX: ¿Cómo se consigue intercambio de información? Como hemos mencionado anteriormente intercambio de información con el servidor se produce en un segundo plano. Las peticiones HTTP al servidor se sustituyen por peticiones JavaScript que se realizan al elemento encargado de AJAX. Las peticiones más simples no requieren intervención del servidor, por lo que la respuesta es inmediata. Si la interacción requiere una respuesta del servidor, la petición se realiza de forma asíncrona mediante AJAX. En este caso, la interacción del usuario no se ve interrumpida por recargas de página o largas esperas por la respuesta del servidor. A continuación se mostrará una imagen comparativa mostrando las aplicaciones web tradicionales con su interacción síncrona y la comunicación asíncrona de las aplicaciones creadas con AJAX :
Página 50
Página 51 4.2 Herramientas Las distintas fases de trabajo del proyecto están apoyadas por un uso de software específico para su desarrollo. Para el desarrollo de la aplicación se ha contado con un equipo formado por el tutor de proyecto y el propio desarrollador. Durante el proceso se diferencian dos fases que están estrechamente ligadas: 1. documentación y gestión. 2. desarrollo e implementación del proyecto. Cada una de estas fases ha requerido el uso de distintas herramientas para conseguir su objetivo. A continuación se enumeran detallando la sección en la que se encuentran en este documento y la versión utilizada durante su uso. 1. Para la documentación y gestión. Microsoft Office Word como procesador de texto—versión estable 2007 Sublime text 2 como editor de código—Versión 0.0.4 (1003) StarUML para realización de diagramas—Versión 5.0.2 Windows Balsamiq Mockups para diseño de prototipos de interfaces—Versión 2.1.1.9 Photoshop como editor de imágenes—Versión 12.0.4 (CS5) 2. Para el desarrollo e implementación del software se ha utilizado. Ruby on Rails como framework Ruby— Última versión estable jQuery como framework Javascript— Última versión estable Bootstrap como framework HTML5/CSS3—Versión 2.3 Git como sistema de control de versiones—Última versión estable 4.2.1 Recursos Físicos Usados Para dar cabida al conjunto de herramientas y tecnologías señaladas, se ha utilizado un soporte físico como equipo de trabajo con las siguientes características: Modelo. lenovo Z500 Procesador. Intel Core i5 . 2,60 GHz Memoria. 6 Gb DDR3 Gráficos. GeForce GT 740M Disco Duro. 438 Gb SATA Software. Windows 8 Conexión internet. Banda ancha 10Mb
Página 52 4.2.2 Microsoft Office Word Microsoft Office es una suite de oficina que abarca e interrelaciona aplicaciones de escritorio, servidores y servicios para los sistemas operativos Microsoft Windows y Mac OS. Microsoft Word es un software destinado al procesamiento de textos. Fue creado por la empresa Microsoft, y actualmente viene integrado en la suite ofimática Microsoft Office. Originalmente fue desarrollado por Richard Brodie para el computador de IBM bajo sistema operativo DOS en 1983. Las versiones actuales son Microsoft Office Word 2013 para Windows y Microsoft Office Word 2011 para Mac. Ha llegado a ser el procesador de texto más popular del mundo. Microsoft Office word usa la filosofía conocida como procesadores WYSIWYG, es decir, "lo que ves es lo que obtienes". 4.2.3 Sublime Text 2 como Editor de Código Sin lugar a duda la herramienta del software que más usamos los programadores es sin duda el editor de código, es por ello que es muy importante elegir un buen editor si queremos que nuestra productividad no sufra. Sublime Text es un editor de texto y editor de código fuente creado en Python. Se distribuye de forma gratuita, sin embargo no es software libre se puede obtener una licencia para su uso ilimitado, pero él no disponer de esta no genera ninguna limitación más allá de una alerta cada cierto tiempo. Algunas de las características más destacadas de este editor son: Minimapa: Consiste en una previsualización de la estructura del código, es muy útil para desplazarse por el archivo cuando se conoce bien la estructura de este. Multi Selección: Hace una selección múltiple de un término por diferentes partes del archivo. Multi Cursor: Crea cursores con los que podemos escribir texto de forma arbitraria en diferentes posiciones del archivo. Multi Layout: Trae siete configuraciones de plantilla podemos elegir editar en una sola ventana o hacer una división de hasta cuatro ventanas verticales o cuatro ventanas en cuadricula. Soporte nativo para infinidad de lenguajes: Soporta de forma nativa 43 lenguajes de programación y texto plano. Syntax Highlight configurable: El remarcado de sintaxis es completamente configurable a través de archivos de configuración del usuario. Búsqueda Dinámica: Se puede hacer búsqueda de expresiones regulares o por archivos, proyectos, directorios, una conjunción de ellos o todo a la vez. Auto completado y marcado de llaves: Se puede ir a la llave que cierra o abre un bloque de una forma sencilla. Soporte de Snippets y Plugins: Los snippets son similares a las macros o los bundles además de la existencia de multitud de plugins. Configuración total de Keybindings: Todas las teclas pueden ser sobrescritas a nuestro gusto. Acceso rápido a linea o archivo: Se puede abrir un archivo utilizando el conjunto de teclas Cmd+P en Mac OS X o Ctrl+P en Windows y Linux y escribiendo el nombre del mismo o navegando por una lista. También se puede ir a una línea utilizando los dos puntos ":" y el número de línea.
Página 53 Paleta de Comandos: Un intérprete de Python diseñado solo para el programa con el cual se puede realizar infinidad de tareas. Coloreado y envoltura de sintaxis: Si se escribe en un lenguaje de programación o marcado, resalta las expresiones propias de la sintaxis de ese lenguaje para facilitar su lectura. Pestañas: Se pueden abrir varios documentos y organizarlos en pestañas. Resaltado de paréntesis e indentación: Cuando el usuario coloca el cursor en un paréntesis, corchete o llave, resalta esta y el paréntesis, corchete o llave de cierre o apertura correspondiente. 4.2.4 Staruml para Realizar Diagramas StarUML es una herramienta para el modelamiento de software basado en los estándares UML (Unified Modeling Language) y MDA (Model Driven Arquitecture). StarUML en un principio era un producto comercial y actualmente es de licencia abierta. El software heredó todas las características de la versión comercial y poco a poco ha ido mejorando sus características para dar soporte completo al diseño UML, entre las cuales se encuentran: Diagrama de casos de uso Diagrama de clase Diagrama de secuencia Diagrama de colaboración. Diagrama de estado. Diagrama de actividad. Diagrama de componentes Diagrama de despliegue. Diagrama de composición estructural Otras funcionalidades de las que dispone el software son: Definir elementos propios para los diagramas, que no necesariamente pertenezcan al estándar de UML, La capacidad de generar código a partir de los diagramas y viceversa, actualmente funcionando para los lenguajes c++, c# y java. Generar documentación en formatos Word, Excel y PowerPoint sobre los diagramas. Patrones GoF (Gang of Four) , EJB (Enterprise JavaBeans) y personalizados. Plantillas de proyectos. Posibilidad de crear plugins para el programa. 4.2.5 Balsamig Mockups para Diseño de Prototipo de Interfaces Balsamiq Mockups es una herramienta que nos permite realizar fácilmente una representación esquemática o prototipo de la solución que llevaremos adelante, sin entrar en etapas posteriores como el diseño gráfico o la programación web. Gracias a esta herramienta, podemos comunicar rápidamente las propuestas de solución, sin invertir demasiada cantidad de tiempo en esta primera etapa. Podemos acordar con el cliente aspectos claves de la solución a desarrollar, como la distribución general de los elementos, sus jerarquías y la navegación de los mismos.
Página 54 Balsamiq Mockups nos provee de representaciones de todos los elementos utilizados para la construcción de una web: pantallas de navegadores, títulos, imágenes, etc. Dispone de más de 75 modelos ya definidos. Simplemente lo organizarlos en un documento y ya podemos tener una primera aproximación de la solución a desarrollar. 4.2.6 Photoshop como Editor de Imágenes Adobe Photoshop es una aplicación para la creación, edición y retoque de imágenes. Es desarrollado por la compañía Adobe Systems. Se lanzó originalmente para computadoras Apple, pero luego saltó a la plataforma Windows. Este programa se ha hecho muy popular, se ha convertido en un estándar en retoque fotográfico. Reconoce múltiples formatos de imágenes: PSD, PDD, PostScript, EPS, DCS, TIFF, BMP, GIF, JPEG, TIFF, PNG, PDF, ICO, RAW, entre otros. Photoshop en sus versiones iníciales trabajaba en un espacio formado por una sola capa, donde se podían aplicar toda una serie de efectos, textos, marcas y tratamientos. En la actualidad el software a mejorado bastante incluyendo un espacio de trabajo multicapa, inclusión de elementos vectoriales, gestión avanzada de color (ICM / ICC), tratamiento extensivo de tipografías, control y retoque de color, efectos creativos, posibilidad de incorporar plugins de terceras compañías, exportación para sitios web entre otros. Aunque el propósito principal de Photoshop es la edición fotográfica, éste también puede ser usado para crear imágenes, efectos, gráficos y más en muy buena calidad. 4.2.7 Ruby and Rails como Framework de Ruby Ruby on Rails, es una estructura de soporte para la programación web desarrollada en el lenguaje Ruby por David Heinemeier Hansson, como resultado del desarrollo de Basecamp. La primera versión del framework salió a la luz pública en julio de 2004, así que Ruby on Rails, es un framework muy reciente en comparaciones con otros soportes más consolidados. Para entender qué es Ruby on Rails, primero tenemos que conocer un poco en qué se apoya. Los dos principios fundamentales sobre los cuáles se apoya Ruby on Rails, son: No te repitas. No te repitas significa que las definiciones deberían hacerse una sola vez. Dado que Ruby on Rails es un framework de pila completa, los componentes están integrados de manera que no hace falta establecer puentes entre ellos. Por ejemplo, en ActiveRecord, las definiciones de las clases no necesitan especificar los nombres de las columnas; Ruby puede averiguarlos a partir de la propia base de datos, de forma que definirlos tanto en el código como en el programa sería redundante.
Página 55 Convenciones antes que configuración. Significa que el programador sólo necesita definir aquella configuración que no es convencional. Por ejemplo, si hay una clase Historia en el modelo, la tabla correspondiente de la base de datos es historias, pero si la tabla no sigue la convención (por ejemplo blogposts) debe ser especificada manualmente (set_table_name "blogposts"). Así, cuando se diseña una aplicación partiendo de cero sin una base de datos preexistente, el seguir las convenciones de Rails significa usar menos código, ya que el propio framework, por defecto, genera ciertos elementos. Las convenciones existentes en Rails han sido definidas por el grupo de desarrolladores con la intención de facilitar el desarrollo, pero eso no implica que dichas convenciones no se puedan redefinir y cada cual configurarlas de otra manera y a su medida. 4.2.7.1 Servicios Restful REST define un set de principios arquitectónicos por los cuales se diseñan servicios web haciendo foco en los recursos del sistema, incluyendo cómo se accede al estado de dichos recursos y cómo se transfieren por HTTP hacia clientes escritos en diversos lenguajes.REST emergió en los últimos años como el modelo predominante para el diseño de servicios. De hecho, REST logró un impacto tan grande en la web que prácticamente logró desplazar a SOAP y las interfaces basadas en WSDL por tener un estilo bastante más simple de usar. Principios de REST Una implementación concreta de un servicio web REST sigue cuatro principios de diseño fundamentales: 1. Utiliza los métodos HTTP de manera explícita. Una de las características claves de los servicios web REST es el uso explícito de los métodos HTTP. REST hace que los desarrolladores usen los métodos HTTP explícitamente de manera que resulte consistente con la definición del protocolo. Este principio de diseño básico establece una asociación uno-a-uno entre las operaciones de crear, leer, actualizar y borrar y los métodos HTTP. De acuerdo a esta asociación: Se usa POST para crear un recurso en el servidor Se usa GET para obtener un recurso Se usa PUT para cambiar el estado de un recurso o actualizarlo Se usa DELETE para eliminar un recurso 2. No mantiene estado. El no mantener estado mejora el rendimiento de los servicios web y simplifica el diseño e implementación de los componentes del servidor, ya que la ausencia de estado en el servidor elimina la necesidad de sincronizar los datos de la sesión con una aplicación externa, es decir, se deben enviar peticiones que incluyan todos los datos necesarios para cumplir el pedido, de manera que los componentes en los servidores intermedios puedan redireccionar y gestionar la carga sin mantener el estado localmente entre las peticiones.
Página 56 3. Expone URIs con forma de directorios. Las URIs representa una jerarquía,es decir, las URIs contiene una única ruta raíz, y va abriendo ramas a través de las subrutas para exponer las áreas principales del servicio. De acuerdo a esta definición, una URI no es solamente una cadena de caracteres delimitada por barras, sino más bien un árbol con subordinados y padres organizados como nodos. 4. Transfiere XML, JavaScript Object Notation (JSON), o ambos. La representación de un recurso en general refleja el estado actual del mismo y sus atributos al momento en que el cliente de la aplicación realiza la petición. La representación del recurso son simples. Esto podría ser una representación de un registro de la base de datos que consiste en la asociación entre columnas y tags XML, donde los valores de los elementos en el XML contienen los valores de las filas. O la representación de un recurso es una fotografía en el modelo de datos del sistema. 4.2.8 Jquery como Framework Javascripts jQuery es un framework de JavaScript, creada inicialmente por John Resig, que permite simplificar la manera de interactuar con los documentos HTML, manipular el árbol DOM, manejar eventos, desarrollar animaciones y agregar interacción con la técnica AJAX a páginas web. Es un software libre y de código abierto. Ofrece una serie de funcionalidades basadas en JavaScript que de otra manera requerirían de mucho más código, es decir, podemos obtener resultados en menos tiempo y espacio. Sus principales características: Selección de elementos DOM. Interactividad y modificaciones del árbol DOM, incluyendo soporte para CSS 1-3. Eventos. Manipulación de la hoja de estilos CSS. Efectos y animaciones. Animaciones personalizadas. AJAX. Soporta extensiones. Utilidades varias como obtener información del navegador, operar con objetos y vectores, funciones como trim() (elimina los espacios en blanco del principio y final de una cadena de caracteres), etc. Compatible con los navegadores Mozilla Firefox 2.0+, Internet Explorer 6+, Safari 3+, Liviano. El archivo del framework ocupa unos 56 KB (19KB en caso de enviarse de manera comprimida Estabilidad y buena documentación. Cuenta con un gran equipo de desarrolladores a cargo de mejoras y actualizaciones del framework.
Página 57 Su uso: jQuery consiste en un único fichero JavaScript que contiene las funcionalidades comunes de DOM, eventos, efectos y AJAX.La característica principal de la biblioteca es que permite cambiar el contenido de una página web sin necesidad de recargarla, mediante la manipulación del árbol DOM y peticiones AJAX. Para ello utiliza las funciones $() o jQuery(). Función $() La forma de interactuar con la página es mediante la función $(), un alias de jQuery(), que recibe como parámetro una expresión CSS o el nombre de una etiqueta HTML y devuelve todos los nodos (elementos) que concuerden con la expresión. Esta expresión es denominada selector en la terminología de jQuery. $("#tablaAlumnos"); // Devolverá el elemento con id="tablaAlumnos" $(".activo"); // Devolverá una matriz de elementos con activo Una vez obtenidos los nodos, se les puede aplicar cualquiera de las funciones que facilita la biblioteca. // Se elimina el estilo (con removeClass()) y se aplica uno nuevo (con addClass()) a todos los nodos con class="activo" $(".activo").removeClass("activo").addClass("inactivo"); O por ejemplo, efectos gráficos: // Anima todos los componentes con class="activo" $(".activo").slideToggle("slow"); Función jquery() Comúnmente antes de realizar cualquier acción en el documento con jQuery(), debemos percatarnos de que el documento esté listo. Para ello usamos $(document).ready();, de esta forma: $(document).ready(function() { //Aquí van todas las acciones del documento. }); 4.2.9 Bootstrap como Framework Html5 y Css3 Es un framework para el desarrollo de aplicaciones web desarrollo de Twitter. El framework presenta aspecto bastante limpio y construido sobre las tecnologías más modernas (HTML5, CSS3,Responsive Web Design). Gracias a la tecnología Responsive, permite que los sitios construidos con la ayuda de Bootstrap funcionen bien en ordenadores de escritorio, tabletas o teléfonos móviles.
Página 64 Figura 5.1.1.1.2.1 Algoritmo Getting Things Done imagen tomada de la web freshpathconsulting cuya URL de la imagen es http://freshpathconsulting.files.wordpress.com/2009/11/gtd.jpg Ejemplo: "Recoger un pedido importante en un almacén" ¿Necesitamos realizar una actividad para realizarla? Sí ¿Tenemos que hacerla nosotros? Sí ¿Nos lleva menos de dos minutos? No, no podemos hacerla en menos de 2 min Asignarle una carpeta (fase 3: Organizar) 5.1.1.1.3 Organizar Allen describe el conjunto de listas sugeridas que puedes usar para mantener un seguimiento de los elementos que esperan ser atendidos: Bandeja de entrada. Depositaremos todas las acciones o tareas que se nos presenten. En una segunda fase éstas se procesan, distribuyéndolas en el resto de carpetas del sistema, eliminándolas o archivándolas. Personalmente registro todas las ideas, problemas pendientes de resolución que se presenten, o potenciales proyectos a realizar. A pesar de ser una idea remota, la depósito en la bandeja de entrada, al procesarla ya lo enviaré a la lista Algún día, o abriré un nuevo proyecto definiendo las siguientes acciones a realizar. La cuestión es descargar nuestra mente para no perder ni un ápice de nuestra creatividad. Siguiente. Reservada para las acciones a realizar a corto plazo, durante el día o la semana. Se nutre tanto de tareas de la Entrada, como de las listas restantes. La única condición es que la acción se realice en breve. Para aumentar la eficiencia de la lista siguiente no hay que restringir a las listas base del sistema. Tenemos que pensar que si depositamos las acciones que pensamos realizar en la lista Siguiente es posible que no podamos realizarlas debido a limitaciones de materiales. No es una ubicación idónea o no disponer de las herramientas adecuadas puede obligarnos a aplazar las tareas. Para evitar encontrarnos en una situación de bloqueo como las mencionadas, crearemos un sistema paralelo de listas con nombres como Encargos, Oficina, Casa, Ordenador… Cada uno de ellos describe un emplazamiento, una herramienta o una actividad a realizar, en las que nos será útil tener agrupadas las acciones para poder realizar sin revisar todo el apartado de próximas acciones cada vez, sobre todo si administramos listas con una gran cantidad de puntos. En espera. Se enumeran los asuntos que necesitan la participación de un tercero para ser finalizados. Recibir una respuesta por correo, una llamada, una verificación de un trabajo realizado. Según nuestro trabajo puede quedar reducida en una anécdota, o si dependemos de terceras personas con frecuencia, convertirse en un punto de referencia. En cualquier caso tenemos que revisarla periódicamente según el uso: Diaria o superior si tiene un gran movimiento, o semanalmente si su uso es moderado.
Página 65 Proyectos. Abrimos una lista para cada uno de los proyectos en marcha. Consideremos un proyectos aquella tarea que consta de más de una acción física para ser completado, por lo tanto será fácil que acaben siendo numerosos. Es aconsejable eliminar las listas de proyectos al terminar la última acción. No debemos temer abrir listas de esta tipología, su gran número nos hará darse cuenta de la multitud de asuntos que tenemos entre manos. Algún día. es la lista donde se acumulan todas aquellas tareas y potenciales proyectos que no tienen fecha de entrega, que por falta de tiempo por el momento no se pueden realizar. Engloba un conjunto de acciones muy heterogéneo, desde migrar el blog hasta cambiar de coche, pasando por aprender francés. Para conservar su integridad dos consejos: No confundir Algún día con un cajón de sastre, si lo hacemos se acabará convirtiendo en un auténtico caos. No guardar tareas parcialmente realizadas o material de consulta, es mejor crear una carpeta para cada uno de los conceptos mencionados. Un calendario también es algo importante para llevar un seguimiento de tus citas y compromisos; sin embargo, Allen recomienda específicamente que el calendario se reserve para lo que él denomina "paisaje yermo" : cosas que se deben hacer obligatoriamente en un plazo específico, o reuniones y citas que han sido fijados en un momento en particular. La clave definitiva de la organización según GTD es el sistema recordatorio. La sugerencia de Allen es que mantengas un único sistema recordatorio ordenado alfabéticamente para hacer tan rápido y fácil como sea posible el hecho de almacenar y buscar la información que necesitas. 5.1.1.1.4 Revisar Las listas de acciones y recordatorios serán completamente inútiles si no las revisamos al menos diariamente o siempre que tengamos un momento libre. La disciplina GTD requiere que se revisen todas las acciones destacadas, proyectos e ítems ―en espera‖, asegurándose de que todas las tareas nuevas o eventos venideros están incluidos en el sistema y que estarán actualizado. La revisión consiste en: Revisar todo lo que tienes pendiente por ejemplo: correo electrónico que ha quedado pendiente de contestar o que se ha separado para releer y contestar con más calma. Hay que mirar el calendario y añadir a la lista para procesar todas las citas de la próxima semana. Procesar tu bandeja de entrada física , convirtiendo todos los documentos, citas, correspondencias en nuevas entradas en tu bandeja de entrada virtual del software seleccionado. Revisión de las lista base de GTD 1. Eliminar tareas que ya hemos realizado 2. Reorganizar las tareas cuando haya cambiado nuestra prioridades El cuarto paso es la clave para la mejora de nuestros hábitos productivos. En la parte final de la revisión evaluaremos las decisiones tomadas durante la semana en el ámbito productivo. Repasamos cada uno
Página 66 de los problemas y valoramos la solución aplicada, si ésta no ha sido del todo óptima proponemos una alternativa de cara a ir mejorando con el sistema. 5.1.2 Control de Tiempo Este capítulo describe un procedimiento y una forma de controlar y registrar la manera de gastar tu tiempo. También se dan ejemplos de los tipos de registros de tiempos a guardar. La formas de mejorar la calidad del trabajo comienza por entender lo que haces realmente. Esto significa que tiene que conocer las tareas que haces, cómo las haces y los resultados que obtienes. El primer paso en este proceso es definir las tareas y averiguar cuánto tiempo gastas en cada una de ellas. Para hacer esto, debes medir tu tiempo real. Este capítulo describe cómo medir el tiempo y anotarlo en una tabla. Cuando registre el tiempo recuerda que el objetivo es obtener datos de cómo trabajas realmente. La forma y el procedimiento utilizado para reunir los datos no es tan importante mientras los datos sean exactos y completos. 5.1.2.1 Control del Tiempo Cuando las personas hablan generalmente sobre lo que hacen, a menudo utiliza las horas como medida. Pero esto no es muy útil. La razón es porque tú, realmente, no dedicas una hora completa a algo. Por ejemplo en la figura de abajo mostramos un resumen de tiempos de 7 estudiantes tomando de un curso reciente en donde había que describir algún ejercicio de codificación relativamente pequeños. Estos ejercicios requiere una media de 4 a 6 horas cada uno, y los estudiantes tuvieron que controlar cuándo comenzaba y paraban su trabajo. Como puedes observar, el 90% de los períodos de trabajo de los 7 estudiantes fueron inferiores a una hora. Nota: El eje de las Y representa los periodos (% ) y el eje de la X representa las logitudes de los períodos de trabajo en minutos La cantidad típica de tiempo no interrumpido que los ingenieros dedican a sus tareas es generalmente inferior a una hora. Medir el trabajo en unidades de horas no proporcionará 010 20 30 40 0-14 15-29 30-44 45-59 60-74 75 -89 90-104
Página 67 el detalle necesario para posteriormente planificar y gestionar tu trabajo. Es mucho más fácil controlar el tiempo en minutos que en fracciones de una hora. Consideran, por ejemplo, los registros de tiempo que obtendrías si utilizases fracciones de hora. Las entradas serian números como 0,38 o 1,25 horas. Aunque las unidades de horas pueden ser más útiles en resúmenes mensuales o semanales, estas cantidades fraccionadas son difíciles de calcular y complicado de interpretar. Por ejemplo, en vez de poner 0,38 horas, es más fácil entender y de registrar en 23 minutos. Una vez que has decidido controlar el tiempo, es más fácil controlarlo en minutos que en horas. 5.1.2.2 Uso de Tabla de Registro de Tiempo Normalizada La siguiente tabla de ejemplo es utilizada para registra el tiempo. Estudiante:________________ Fecha_________________________ Profesor:__________________ Clases_________________________ Fecha Comien zo Fin Tiempo de interrupció n Tiempo Real Actividade s Comentario s C U Cuaderno de registro de tiempo La parte superior de la tabla, llamada cabecera tiene unos espacios para poner tu nombre, fecha de comienzo, el nombre del profesor y el nombre o numero de clase. Las columnas del cuerpo de la tabla son para registrar los datos de tiempos. cada periodo de tiempo se introduce en una línea de la siguiente forma: Fecha. La fecha de realización de alguna actividad, como asistir a clase o escribir un programa. Comienzo. La hora de comienzo de la actividad. Fin. La hora que termina de hacer la actividad. Interrupción. Cualquier pérdida de tiempo debida a interrupciones. Tiempo Real. El tiempo a cada actividad en minutos entre los tiempo de comienzo y fin menos el tiempo de interrupción Actividad. Nombre descriptivo para la unidad. Comentarios. Una descripción más completa de lo que están haciendo, el tipo de interrupción o cualquier cosa que podrían ser útil cuando posteriormente analice los datos de tiempo. C(completado).Rellenar esta columna cuando termines una tarea como leer un capítulo del libro de texto o escribir un programa U(unidades).El número de unidades de una tarea acabada. Un ejemplo de cómo rellanar la tabla de registro completo lo podemos ver a continuación.
Página 68 Estudiante: Estudiante Y Fecha: 05/10/2013 Profesor: Señor Z Clases: CS1 Fecha Com ienz o Fin Tiemp o de interru pción Tiem po Real Activida des Comentarios C U 05/10 9:00 9:50 50 Clase Clase 12:4 0 1:18 38 Cod. Ejercicio 1 2:45 3:53 10 58 Cod. Ejercicio 1 6:25 7:45 80 Texto Leer texto capítulo 1 y 2 x 2 06/10 11:0 6 12:19 6+5 62 Cod Ejercicio 1, descanso, charla x 1 07/10 9:00 9:50 50 Clase clase 1:15 2:35 3+8 69 Cod Ejercicio 2, descanso, charla x 1 4:18 5:11 25 28 Texto Texto capítulo 3,charla con maría x 1 08/10 6:42 9:04 10+6+1 2 114 Cod Ejercicio 3 x 1 09/10 9:00 9:50 50 Clase Clase 12:3 8 1:16 38 Texto Texto capítulo 4 10/10 9:15 11:59 5+3+22 134 Revisión Prepara examen, descanso, teléfono, charla Cuaderno de registro de tiempo Aquí el estudiante Y escribe su nombre y la fecha en que comienza a rellenar la tabla. También escribe el nombre del profesor y el nombre o número del curso. Cuando comenzó a guardar registro tiempo el día 9 de septiembre, registro en la parte superior izquierda. Su primera tarea fue asistir a clase de ip a las 9:00 AM. La clase duró hasta las 9:50, o sea un total de 50 minutos. La estudiante puso 9:00 en la columna de comienzo, 9,50 en la columna de fin y los 50 minutos de duración en la columna de tiempo real. A la derecha puso de la actividad en la columna denominada actividad. Finalmente, en la columna comentario, anotó lo que estaba haciendo. Como la estudiante Y continuo haciendo actividades durante varios días, anotó sus otras actividades para el curso de ip en la tabla de registro de tiempo. 5.1.2.3 Gestión de las Interrupciones Un problema común con el control de tiempo son las interrupciones. Es sorprendente la frecuencia con que somos interrumpidos por llamadas telefónicas, personas que quieren charlar , molestias ocasionales o la necesidad de descansar. La forma de gestionar las interrupciones en el cuaderno de registro de tiempo, consiste en anotarlas en la columna
Página 69 tiempo de interrupciones como se observa en la tabla siguiente la estudiante Y comenzó su trabajo de casa a las 11:06 del día 10 y paró a las 12:19.Durante dicho período, tuvo dos interrupciones, una de 6 minutos y otra de 5 minutos. El tiempo neto que dedicó a su trabajo de casa fue de 73 minutos menos 11 minutos de interrupción(tiempo improductivo),es decir un total de 62 minutos(tiempo productivo). La estudiante no solamente anotó estos tiempo en el cuaderno de registro de tiempos sino que también describió brevemente las interrupciones en la columna de comentarios. Una cosa que he encontrado útil es utilizar el cronómetro para controlar las interrupciones. Cuando me interrumpen, pongo en marcha el cronómetro y cuando estoy preparado para reanudar el trabajo, lo paro. Antes de comenzar a trabajar de nuevo, anoto el tiempo de interrupción en el cuaderno y pongo a cero el cronómetro. Encuentro esto más adecuado que apuntar el tiempo de inicio de cada interrupción. Puesto que el tiempo de las interrupciones no es tiempo de trabajo productivo, se debe controlar las interrupciones. Los datos de tiempos registrado pueden utilizarse para comprender con qué frecuencia se interrumpe tu trabajo. Las interrupciones no son solamente un despilfarro del tiempo, sino que rompe tu ritmo de pensamiento, llevándote a la ineficiencia y al error. Comprender como eres interrumpido te ayudará a mejorar la calidad y eficiencia de tu trabajo. 5.1.2.4 Control de Tareas Finalizadas Para controlar cómo gastar tu tiempo, necesitamos controlar los resultados producidos. Para la asistencia a clase o reuniones, por ejemplo, un registro de tiempo sería adecuado. Cuando desarrollas programas necesitas saber cuánto trabajo has realizado. Podrías calcular la productividad de la tarea. Un ejemplo podría ser cuanto tiempo necesitas para leer un capítulo de un libro o escribir un programa. Con este conocimiento podrás mejorar la planificación de tus futuros trabajos. Las columnas C y U de la derecha del cuaderno de registro de tiempo, te ayuda a identificar rápidamente el tiempo dedicado a las distintas tareas y lo que has hecho. Para rellenar la columna C comprueba cuando has terminado una tarea, por ejemplo el estudiante Y lee el libro desde 6:25 hasta las 7:45 el 5 octubre. Durante este tiempo completó la lectura de dos capítulos. Por ello puso una X en la columna C (complementado).Para anotar las unidades de trabajo acabadas, puso un 2 en la columna de U(unidades). Posteriormente cuando resumas tu trabajo de la semana rápidamente podrías ver estas columnas para encontrar los elementos acabados y cuánto tiempo ha dedicado. Para tener unos registro de tiempo exactos, es importante completar las columnas C y U cada vez que acabes una tarea que tengas resultados medibles. Si olvidas hacerlo, puedes fácilmente encontrar la información, pero es mucho más fácil rellenarlo en el momento que acabas la tarea.
Página 70 5.1.2.5 Resumen Semanal de Actividades Para hacer un plan de periodo, es importante entender cómo gastas tu tiempo. El primer paso es registrar tu tiempo utilizando el cuaderno de registro de tiempos. Después de reunir los datos de tiempos una semana o dos , empezarás a ver cómo empleas el tiempo. Puesto que los registro de tiempos son muy detallados para el propósito de la planificación, necesitas resumir los datos de una forma más útil. A continuación se muestra el formato de tiempo que son más adecuados para la planificación del período. Nombre: Fecha: 1 Tarea Total 2 Fecha 3 D 4 L 5 M 6 MI 7 J 8 V 9 S 10 totales 11 Tiempos y Medidas del Período Numero de Semanas(número anterior +1)__ 12 Resumen de las semanas anteriores 13 totales 14 Med. 15 Máx. 16 Mín 17 Resumen incluyendo la última semana 18 Total 19 Avg 20 Máx 21 Mín En la línea de 1-10 del resumen semanal de actividades, registras el tiempo que dedicas a cada actividad principal durante cada día de la última semana. en la parte inferior derecha desde la línea 13 a la 16 está la media el máximo y el mínimo que le dedicas a cada tarea durante la semana anterior al semestre. Desde la línea de la 18 a la 21 muestra el total la media, el máx., el min, de tiempo que le dedicas a cada trabajo definido para todo el semestre , incluyendo la última semana.
Página 71 5.1.2.6 Resumen de Tiempos Semanales Un ejemplo de resumen semanal de actividades se mostrará a continuación: La forma de rellenar la tabla es de la siguiente manera: 1. Anota tu nombre y fecha 2. Anota las categorías de actividades como cabecera de las columnas. 3. Escribe fecha en la columna fecha, anotando el domingo como primer día de la semana 4. Para cada día suma todos los minutos para cada actividad en los registro de tiempo y anota el resultado en la columna correspondiente. 5. Después de completar todas las casillas para cada día, se obtiene el total para cada día en la columna total. 6. Repite este proceso para cada día de la semana (filas 5 -9) 7. Calcular los totales semanales para cada tarea clasificada en la fila 10. 8. A continuación se obtiene el total de los tiempos de las actividades que aparece en la fila 10. 9. Por último suma los totales para comprobar que obtiene el mismo resultado. Si no fuera así , se debería volver a calcular el total de todos los días y de todas las tareas para localizar el error. Nombre: Estudiante Y Fecha: 05/10/2013 1 Tarea Clase Codificar Preparar leer Total 2 Fecha Programación Exámenes textos 3 D 96 80 176 4 L 50 69 28 147 5 M 114 114 6 MI 50 38 88 7 J 134 134 8 V 0 9 S 50 62 112 10 totales 150 341 134 146 771 11 Tiempos y Medidas del Período -Numero de Semanas(número anterior +1) 2 5.1.2.7 Calculo de los Tiempos y Media del Periodo Un resumen sencillo de tus tiempos semanales sería suficiente si estuvieras únicamente interesado en una semana , pero realmente está interesado en los tiempos medios, máximos y mínimos dedicados a esta tareas durante un semestre o año completo. Para mostrar cómo obtener estos datos, complementamos a continuación el resumen semana de actividades mostradas en la tabla siguiente. 1. Anota el total de semanas transcurridas. Comprueba la fila 11 del resumen semanal de actividades de semanas anteriores para ver cuantas semanas se tuvieron en cuenta.
Página 72 2. En las filas 13-16 de la tabla de la semana actual copia todas las entradas de la fila 18-21 de la tabla de la semana anterior 3. Suma los tiempos dedicados a cada tarea en la semana actual. En cada columna de la fila 18 anota el resultado de sumar las filas 13 y 10. 4. Calcula el tiempo medio dedicado semanalmente a cada tarea durante el semestre. En la fila 19 divide el valor de cada columna de la fila 18 por el número de semanas. 5. Para encontrar el mayor tiempo dedicado a una tarea durante una semana, calcula el valor máximo en la fila 20. comparando cada columna de la fila 15 con misma columna de la fila 10.Anota el valor mayor en la fila 20. 6. Para saber el tiempo que has dedicado a una tarea durante una semana, calcular el tiempo mínimo. Para calcular el valor mínimo de la columna 21, compara la columna de la fila 16 con la misma columna de la fila 10.Anota el valor más pequeño en la fila 21. 7. Observa que excepto para la primera semana, el tiempo total, máximo y mínimo serán diferentes. 12 Resumen de las semanas anteriores 13 totales 150 341 134 146 771 14 Med. 150 341 134 146 771 15 Máx. 150 341 134 146 771 16 Mín 150 341 134 146 771 17 Resumen incluyendo la última semana 18 Total 300 682 268 292 1542 19 Med 150 341 134 146 771 20 Máx 150 341 134 146 771 21 Mín 150 341 134 146 771 5.1.3 Lista de Características En este Apartado se pretende redactar una lista de todas aquellas características que tiene la aplicación web que vamos a realizar. 5.1.3.1 Roles de Usuarios En este paso realizaremos una clasificación de todos los posibles usuarios del sistema , es sólo una aproximación para identificar y asociar cada característica con cada uno de los usuarios. Los diferentes usuarios identificados inicialmente son: Usuarios registrados:Es el usuario que ya consta en las bases de datos del servicio y posee pleno control sobre el software que se le asigna desde el momento de su registro. Usuario no registrado (anónimo):Es el usuario que no se encuentra en el sistema, su única funcionalidad es ver la información de la página principal del sitio y poder registrarse en dicho sistema. Administrador del sitio: Es el rol de los usuarios que controlan el sitio web.
Página 73 5.1.3.2 Valores de Planificación Cada característica tiene también un conjunto de valores de planificación que son los incluidos a continuación: Código: Es el identificador de la característica. Se especifica como: LC + Categoría + Número. Nombre de las características. Descripción: Breve descripción de lo que comprende la característica. Prioridad: Se asigna una prioridad a cada una con el fin de determinar el orden en que se van a ir desarrollando. Las prioridades pueden ser: Muy Alta (81-100) Alta (61-80) Media (41-60) Baja (21-40) Muy Baja (1-20) Estado: Cada característica tiene un estado asociado que irá variando a medida que progrese el proyecto. Los estados pueden ser: Aceptado: La característica se desarrollará en esta versión del producto. Planificada: La característica ya ha sido planificada y se empezará a desarrollar en un plazo de tiempo corto. En desarrollo: Ya se está desarrollando. Finalizada: Se ha terminado de desarrollar. Postergada: No se desarrollará hasta una versión futura. Rechazada: Probablemente no se desarrollará en ninguna versión. Rol: El rol de usuario que puede usar la característica. Coste Estimado: el coste en una medida (tiempo, dinero, recursos) que conlleva realizar la característica. Riesgo: Cada característica puede tener asociado un riesgo que representa la dificultad para conseguir implementarla correctamente. Se utilizarán tres niveles: Crítico: Riego que se debe corregir lo antes posible. Significativo: Es un riesgo con cierta importancia que tendrá que ser mirando Rutinario: Riesgo con el nivel más bajo que contiene cada característica por defecto. 5.1.3.3 Catalogación de la Lista de Características Para una mayor facilidad en la catalogación, la lista de características está dividida por categorías que representan una aproximación a los módulos que compondrán el sistema. Debido a que la metodología que se usa es iterativa incremental, durante la primera iteración se desarrollarán aquellos requisitos con mayor prioridad y de estado aceptado. Al final del proceso,éstos requisitos pasarán a estar en estado finalizado para dar comienzo a la planificación de la siguiente iteración.
Página 80 LC-C9: Exportación de los diagramas o informes El sistema dará la posibilidad al usuario de que pueda exportar tanto los diagramas como los informes, la exportación podrá hacerse de forma directa a su ordenador o a traves de un medio de almacenamiento en la nube como puede ser dropbox,drive,box. PrioridadMedia (47) EstadoPostergada RolUsuarios registrado Coste Riesgo-Rutinario LC-C10: Importación de los diagramas o informes El sistema dará la posibilidad al usuario de que pueda importar tanto los diagramas como los informes, la importación podrá hacerse de forma directa desde su ordenador o a traves de un medio de almacenamiento en la nube como puede ser dropbox, drive, box. PrioridadMedia (46) EstadoPostergada RolUsuarios registrado Coste Riesgo-Rutinario LC-C11: Roles de usuarios por proyecto El sistema dará la posibilidad de asociar diferentes roles dentro de un proyecto a diferentes usuarios del sistema que esten asociado a un grupo de trabajo. PrioridadMedia (48) EstadoPostergada RolUsuarios registrado Coste Riesgo-Rutinario 5.1.3.3 .5-Gestión de Tiempo(E) LC-E1: Gestión contador de tiempo de interrupciones El usuario podrá gestionar sus interrupciones asociadas a las tareas realizando acciones como añadir, eliminar, buscar, o modificar dichas interrupciones. PrioridadMuy alta (97) Estado-Aceptado RolUsuarios registrado Coste RiesgoCrítico
Página 81 LC-E2: Ejecucción de interrupciones El sistema debe permitir al usuario gestionar el ciclo de vida de las interrupciones,usando para ellos un control de parada o retorno de la tarea previamente en marcha. PrioridadMuy Alta (96) EstadoAceptada RolUsuarios registrado Coste Riesgo-Crítico LC-·E3: Gestión de gráficos o informes de seguimiento de interrupciones Se le dará la posibilidad al usuario de que pueda gestionar informes o gráficos para el seguimiento de las interrupciones.La gestión estará compuesta por acciones de creación,edición,eliminación y listado de informes o gráficos. PrioridadMuy Alta (96) EstadoAceptada RolUsuarios registrado Coste Riesgo-Significativo LC-E4: Exportación de los diagramas o informes de interrupciones El sistema dará la posibilidad al usuario de que pueda exportar tanto los diagramas como los informes, la exportación podrá hacerse de forma directa a su ordenador o a traves de un medio de almacenamiento en la nube como puede ser dropbox,drive,box. PrioridadMedia (47) EstadoPostergada RolUsuarios registrado Coste Riesgo-Rutinario LC-E5: Importación de los diagramas o informes de interrupciones El sistema dará la posibilidad al usuario de que pueda importar tanto los diagramas como los informes, la importación podrá hacerse de forma directa desde su ordenador o a traves de un medio de almacenamiento en la nube como puede ser dropbox, drive, box. PrioridadMedia (46) EstadoPostergada RolUsuarios registrado Coste Riesgo-Rutinario
Página 82 LC-E6: Gestión de hoja de asistencias El sistema dará al usuario la posibilidad de que pueda gestionar hojas de asistencias de diferentes usuarios que estén relacionado con un grupo de trabajo.Las acciones de control serán las básicas:creación,modificación,eliminación,visualización PrioridadMedia (45) EstadoPostergada RolUsuarios registrado Coste Riesgo-Rutinario LC-E7: Gestión de eventos del día a través de de un calendario Se le dará la posibilidad al usuario de que pueda gestionar un calendario para las citas del día.Las gestión será una gestión básica de creación,modificación,eliminación,visualización PrioridadMuy Alta (96) EstadoAceptada RolUsuarios registrado Coste Riesgo-Significativo LC-E8: Alarma de fecha de vencimiento de tareas, proyectos o citas. El sistema dará al usuario aviso de vencimiento de tareas, proyectos o citas. PrioridadAlta (81) EstadoPlanificada RolUsuarios registrado Coste Riesgo-Significativo 5.1.3.3 .6Getting Things Done (GTD) (F) LC-F1: Colocación de tareas en carpeta inicial INBOX El usuario colocará toda tarea nueva, o proyecto creado en un proyecto padre inicial llamado INBOX cuyo simnolo será "/" representando la raiz de directorio de archivo de los sistemas operativos. PrioridadMuy alta (99) EstadoAceptada RolUsuarios registrado Coste Riesgo-Crítico
Página 83 LC-F2: Gestión del algoritmo GTD El usuario gestionará los proyectos y las tareas siguiendo la filosofía gtd para ello se dispondrá de funcionalidad como: resolución de tareas inferioes a 2 minutos, organización de tareas superiores a 2 minutos, aviso cada 24 horas de revisión de prioridades sobre las tareas. PrioridadMuy alta (98) EstadoAceptada RolUsuarios registrado Coste Riesgo-Crítico LC-F3:Filtrados de carpetas siguiendo la filosofía GTD El sistema dará la posibilidad al usuario de filtrar las tareas siguiendo la filosofía GTD de si una tarea esta en espera, no es importante, se tiene que hacer de inmediato etc. PrioridadMuy alta (98) EstadoAceptada RolUsuarios registrado Coste Riesgo-Crítico LC-F4:Asistente de gestión de la filosofía GTD El sistema dará la posibilidad al usuario de usar un asitente para aprender la filosofía GTD. PrioridadAlta (81) EstadoPlanificada RolUsuarios registrado Coste Riesgo-Significativo 5.1.3.3 .7Gestión de Colaboración de Equipos.(G) LC-G1: Construcción de equipo de trabajos Una de las funcionalidad de este software será que los usuarios puedan crear equipos de trabajos y autogestionarse . PrioridadBaja(39) EstadoPostergada RolUsuarios registrado Coste RiesgoRutinario
Página 84 LC-G2: Gestión de usuario en los equipos de trabajo El sistema dará la posibilidad de una gestión básica de usuario dentro de los equipos de trabajo. Las funcionalidades serán: edición de equipo,eliminación de equipos,Listado de personas que forman el equipo,permisos a los miembros del equipo,asi como roles entre los el personal del equipo. Prioridad-Baja(38) EstadoPostergada RolUsuarios registrado Coste RiesgoRutinario LC-G3: Gestión de archivos compartido en grupos de trabajos El sistema dará la posibilidad de una gestión básica de compartimiento de archivos Las funcionalidades serán: subir fichero,compartir fichero,descargar fichero Prioridad-Baja(37) EstadoPostergada RolUsuarios registrado Coste RiesgoRutinario LC-G4: Un administrador de versiones de archivos El sistema dará la posibilidad de un administrador de versiones de archivos básico, donde se almacene, datos como fecha de modificación, autor de la modificación, recuperación de una versión anterior Prioridad-Baja(36) EstadoPostergada RolUsuarios registrado Coste RiesgoRutinario LC-G5: Gestión de notas en grupo El sistema dará la posibilidad de una gestión básica de notas en grupo, las funcionalidades será postear notas en un tablón de anuncio, crearlas, editarlas, eliminarlas, responder una nota en particular etc. Prioridad-Baja(35) EstadoPostergada RolUsuarios registrado Coste RiesgoRutinario
Página 85 LC-G6: chat El sistema dará la posibilidad al usuario de que pueda chatear con las personas de un grupo de trabajo Prioridad-Baja(37) EstadoPostergada RolUsuarios registrado Coste RiesgoRutinario LC-G7: Correo electrónico Se le dará la posibilidad al usuario de que pueda envía correo electrónicos a los componentes del grupo o a cualquier persona simplemente usando nuestro entorno de correo electrónico. Prioridad-Baja(36) EstadoPostergada RolUsuarios registrado Coste RiesgoRutinario LC-G8: Notificaciones El software le dará al usuario una característica de notificaciones tanto para las notificaciones de grupo como para las notificaciones del software Prioridad-Baja(35) EstadoPostergada RolUsuarios registrado Coste RiesgoRutinario LC-G9: Video conferencia El usuario podrá realizar video conferencias con otros usuario que esté en su grupo de trabajo o esté almacenado en su agenda personal. Prioridad-Baja(34) EstadoPostergada RolUsuarios registrado Coste RiesgoRutinario LC-G10: foro Posibilidad que se le dará al usuario de poder crear un foro en donde pueda crear temas, subtemas, etc. Prioridad-Baja(36) EstadoPostergada RolUsuarios registrado Coste RiesgoRutinario
Página 86 LC-G11: wikis Posibilidad para crear wikis, páginas dentro de la wiki, creación de enlaces, etc. Prioridad-Baja(35) EstadoPostergada RolUsuarios registrado Coste RiesgoRutinario 5.1.3.3 .8Configuración(H) LC-H1: Cambiar el color de la página interna(work desk) Se le dará la posibilidad en esta sección de configurar varias cosas del entorno. En esta opción en particular será cambiar el color del escritorio de trabajo ( página interna principal ) Prioridad-Baja(39) EstadoPostergada RolUsuarios registrado Coste RiesgoRutinario LC-H2: Cambiar los datos de cuenta Aquí el usuario tendrá la posibilidad de cambiar los datos personales de su cuenta. Prioridad-Baja(38) EstadoPostergada RolUsuarios registrado Coste RiesgoRutinario LC-H3: Cambiar posición de menús Con esta opción el usuario podrá cambiar las posiciones de los menús a un distinto orden del preestablecido de base. Prioridad-Baja(37) EstadoPostergada RolUsuarios registrado Coste RiesgoRutinario LC-H4: Cambiar idiomas El usuario podrá cambiar a diferentes idiomas la página entera desde su contenido hasta sus herramientas. El software original vendrá con el idioma inglés de base. Prioridad-Baja(36) EstadoPostergada RolUsuarios registrado Coste RiesgoRutinario
Página 87 LC-H5: Activar notificaciones por correo El usuario podrá si lo desea activar las notificaciones por correo, en cuyo caso cuando la herramienta notificaciones tenga nuevas entradas se le mandará un correo al usuario con las notificaciones producidas. Prioridad-Baja(35) EstadoPostergada RolUsuarios registrado Coste RiesgoRutinario LC-H6: Ocultar cuenta de correo El usuario podrá ocultar su cuenta de correo electrónico para que otros usuario no la vean Prioridad-Muy baja(15) EstadoPostergada RolUsuarios registrado Coste RiesgoRutinario LC-H7: Cambiar zona horaria Al usuario se le dará la posibilidad de cambiar la zona horaria según le convenga. Prioridad-Muy baja(17) EstadoPostergada RolUsuarios registrado Coste RiesgoRutinario 5.1.3.3 .9Gestión de Pagos (I) LC-I1: Comprar un nuevo paquete de características para la aplicación El usuario podrá comprar nuevas características para el software de base. Al comprarlas se activará esta nuevas características con los cual ya podrá disfrutar de ellas. Prioridad-Muy baja(17) EstadoPostergada RolUsuarios registrado Coste RiesgoRutinario
Página 88 LC-I2: Comprar más espacio Se le dará la opción al usuario de comprar más espacio del preestablecido de base. El espacio preestablecido de base es de 1GB.(Espacio de cuenta gratuita) Prioridad-Muy baja(16) EstadoPostergada RolUsuarios registrado Coste RiesgoRutinario LC-I3: Pagar cuota mensual al software de pago(software con más opciones y espacio de base) Aquí el usuario tendrá la posibilidad de pagar por el espacio comprado. Además el usuario también podrá pagar en esta sección, la cuota mensual por la versión de pago(la versión de pago contiene todas las funcionalidades, y además se le concederá un espacio de 50GB) Prioridad-Muy baja(16) EstadoPostergada RolUsuarios registrado Coste RiesgoRutinario LC-I4: Gestión de forma de pago Se le dará la opción al usuario de poder pagar con diferentes opciones entre las que se encuentra, paypal, cuenta bancaria,tarjeta de crédito, o a través de tarjetas de dinero canjeables,etc. Prioridad-Muy baja(14) EstadoPostergada RolUsuarios registrado Coste RiesgoRutinario 5.1.3.3 .10Gestor para Creación de Documentos en Línea (J) LC-J1: Gestión de documentos en línea El sistema implementará un gestor de documentos en línea,podrás crear diferentes documentos en línea, modificarlos, eliminarlos, vizualizarlos Prioridad-Muy baja(14) EstadoPostergada RolUsuarios registrado Coste RiesgoRutinario
Página 89 LC-J2: Gestión de herramientas de formatos El sistema implementará un gestor de herramientas de formatos como por ejemplo: operaciones básicas cursiva, negrita, subrayado,color de texto, justificación de texto, insertar tablas, fotos, pie de página, márgenes, orientación, tamaño, columnas, temas predefinidos de fábrica. Prioridad-Muy baja(13) EstadoPostergada RolUsuarios registrado Coste RiesgoRutinario 5.1.3.3 .11Rastreos y Corrección de Bugs (K) LC-K1: Log de errores producidos en el programa Se creará un fichero de log de los errores producidos en el programa en el trascurso de su uso, también aparecerá un registros de los cambios o acciones realizadas por los usuarios que utilice el software Prioridad-Muy baja(10) EstadoPostergada RolUsuarios registrado Coste RiesgoRutinario LC-K2: Rastreo y corrección de bugs Se creará una característica para rastrear los posibles bugs que se han producidos en el software y no han aparecido en el fichero de log de errores generales.Además otra característica de corrección de errores para poder solucionar los errores producidos a lo largo del funcionamiento del software. Prioridad-Muy baja(9) EstadoPostergada RolUsuarios registrado Coste RiesgoRutinario LC-K3: Reportar bug a los administradores del software Se dará una característica de reportar a los creadores del software los bug encontrados, permitiendo así poder ayudar en futuras versiones del software. Prioridad-Muy baja(8) EstadoPostergada RolUsuarios registrado Coste RiesgoRutinario
Página 96 Como en el resto de paquetes que se detallarán en las próximas secciones, la estructura básica está compuesta por casos de uso denominados CRUD(create, read, update and delete). Los casos de uso que contiene este paquete son: Añadir tarea. Esta realización permite al usuario registrado crear una tarea en el sistema, creándose así tareas pendientes que tendrá que realizar. Lista de tareas y ver tareas. El listado de tareas contiene todos las tareas añadidas previamente por el usuario registrado. Accediendo a cada uno de ellas se permite ver la datos más específicos de cada una de las tareas . Modificar tarea. Esta realización permite al usuario registrado modificar los datos almacenados en el sistema de un tarea específico. Eliminar tarea. Este caso de uso está destinado a eliminar del sistema todos los datos asociados a una tarea . Buscar tarea. La realización permite que un usuario obtenga consultas sobre el listado total de tareas en el sistema. Se pueden usar las funciones de búsquedas específicas por nombre o filtrando por categoría de estados. Ejecucción de la tarea. El usuario podrá controlar en todo momento el estado en que se encuentra una tarea que puede ser: Empezar tarea. El usuario podrá empezar una tarea que deseé en ese momento empezará a contar el tiempo. Pausar tarea. El usuario podrá pausar una tarea especificando la interrupción asociada a dicha pausa. Retomar una tarea. El usuario podrá seguir con una tarea que había sido pausada Finalizar una tarea. El usuario podrá finalizar una tarea cuando haya terminado en ese momento dejará de contar el contador de tiempo.
Página 97 Paquete de gestión de tareas 5.2.2.1.4 Paquete de Gestión de Proyecto El paquete de gestión de proyectos junto con paquete de gestión de tareas son la base de esta aplicación. Dicho paquete de gestión de proyectos contiene los casos de uso relacionados con los proyectos diarios realizados por un usuario registrado. Añadir proyecto. Esta realización permite al usuario registrado añadir al sistema un proyecto, también al momento de crearlo puedes elegir el nivel donde colgará el proyecto dentro de un árbol de directorio. Lista de proyectos y ver proyectos. El listado de proyectos contiene todos los proyectos que se han realizado o se está realizando. Ver proyectos concede la posibilidad al usuario de ver los datos sobre el proyecto así como el listado de tareas que lo componen. Modificar proyecto. Desde esta realización permite al usuario registrado modificar los datos almacenados en el sistema de un proyecto específico. Eliminar proyecto. Dicha realización está destinada a eliminar del sistema todos los datos asociados a un proyecto —las tareas que lo componen también tendrán que ser eliminados haciendo uso de las realizaciones correspondientes—. Usuario registrado DCU-PGT Añadir tareas modificar tarea listar tareas buscar por estado buscar tarea Ver tareas buscar por nombre eliminar tarea Ejecucción de una tarea <<include>> <<include>>
Página 98 Paquete de gestión de proyectos 5.2.2.1.5 Paquete de Gestión de Interrupción El paquete de gestión de interrupciones contiene los casos de uso relacionados con los interrupciones diarios realizados por un usuario registrado sobre las tareas. Añadir interrupción. Esta realización permite al usuario registrado añadir al sistema una interrupción, también al momento de crearlo tienes que especificar el nombre y descripción de la interrupción, así como poner en marcha dicha interrupción. Terminar interrupción. Desde esta realización permite al usuario registrado terminar una interrupción generada a partir de una tarea. Empezar interrupción. Desde esta realización permite al usuario registrado empezar una interrupción generada a partir de una tarea. Usuario registrado DCU-PGP Añadir proyecto modificar proyecto listar proyecto Ver proyecto eliminar proyecto
Página 99 Paquete de gestión de interrupciones 5.2.2.1.6 Paquete de Gestión de Gtd El paquete de gestión de GTD contiene los casos de uso relacionados con los metodología GTD. Inbox. Todas las tareas y proyectos del sistema una vez creado será enviados a inbox la carpeta raíz del sistema. Algoritmo de gestión GTD. Con esta realiza el usuario podrá gestionar siguiendo el algoritmo gtd las tareas creadas. Distribución de las tareas en varios Estados. Con esta realización GTD distribuirá las tareas en diferentes estados de realización: Próximo. Incluimos las tareas que debes realizar cuanto antes Proyecto. Incluimos las tareas que implica realizar más de una acción En espera. Son las tareas que necesita la intervención de otra persona para ser realizada. Algún día: Son tareas que debemos hacer pero no son prioritarias. Revisión de prioridad y estados de las tareas . Con esta realización se permite al usuario que pueda revisar cada 24 horas las tareas, viendo si han cambiado la prioridad o el estado de dicha tarea. Usuario registrado DCU-PGI Añadir interrupciones Terminar interrupción Empezar interrupción
Página 100 Paquete de gestión de interrupciones 5.2.3 Especificación de los Casos de Uso La especificación, puede verse como un proceso de representación. Los requisitos se representan de manera que lleven al éxito de la implementación del software. Para cada realización se realizará una descripción del escenario principal como de cada uno de los escenarios asociados a una realización. Además, se indicará: ID como localizador del caso de uso. Actores que participan en la realización. Precondiciones que deben cumplirse para que se inicie la realización. Postcondiciones que deben cumplirse tras completar la realización, indicando de este modo en qué estado queda el sistema tras finalizar dicha realización. Cabe destacar que a la hora de especificar los casos de uso, se han tenido presentes los requisitos no funcionales obtenidos a partir de la lista de características inicial. Por otra parte, es importante decir que en una serie de realizaciones se definen relaciones de inclusión y extensión con otras realizaciones. Cuando se describa los flujos principales y alternativos de la realización, se especificarán los puntos de extensión de dicha realización indicando para cada uno de ellos la condición de activación. Usuario registrado DCU-PGGTD Algoritmos de gestión GTD Revisión de prioridadades y estados de la tarea Inbox Distribución de tareas en varios estados Próximo Proyecto En espera Algún día <<include>> <<include>> <<include>> <<include>>
Página 101 A continuación se muestran las especificaciones de los casos de uso detectados en el modelo: Especificación del caso de uso: Registrarse ID DCU-PGAG.01 Nombre Registrarse Descripción Realiza el registro en la aplicación de un usuario aún no registrado Actores Usuario no registrado Precondiciones --- Postcondiciones Se registra en el sistema usuario no registrado Flujo Normal de Eventos 1. El usuario no registrado selecciona la opción de registrarse 2. El sistema muestra un formulario de registro con los campos de: email y contraseña 3. El usuario no registrado rellena cada campo del formulario y pulsa el botón de enviar 4. El sistema valida los datos del formulario y registra al usuario. Las validaciones son: formato de email debe ser correcto; longitud mínima de contraseña; confirmar contraseña debe ser igual a contraseña. Flujo Alternativo 3.1. Si el usuario no rellena todos los campos del formulario, el sistema muestra un error y vuelve al paso 2 3.2. Si la contraseña insertada no es igual a la confirmación de contraseña, el sistema muestra un error y vuelve al paso 2 4.1. Si el sistema encuentra error en la validación de datos del formulario, muestra mensaje de error y vuelve al paso 2 Especificación del caso de uso registrarse Especificación del caso de uso: Identificarse ID DCU-PGAG.02 Nombre Identificarse Descripción Permite el acceso a un usuario a la aplicación Actores Usuario registrados Precondiciones Usuario tiene que estar registrado en el sistema Postcondiciones usuario accede al sistema Flujo Normal de Eventos 1.El usuario selecciona la opción de identificarse 2. El sistema muestra un formulario con los campos de identificación: email y contraseña 3. El usuario rellena los campos del formulario de identificación y pulsa el botón de enviar 4. El sistema valida los datos del formulario. Las validaciones son: formato de email correcto; par email-contraseña debe pertenecer a email registrado en la aplicación. 5. El sistema inicia una sesión en la aplicación para el usuario identificado 6. El sistema muestra la página de "work desk" del usuario identificado Flujo Alternativo 3.1. Si el usuario no rellena todos los campos del formulario, el sistema envía un mensaje de error y vuelve al paso 2 4.1. Si los datos de identificación no coinciden con el email y la contraseña de un usuario registrado, el sistema muestra un mensaje de error y vuelve al paso 2
Página 102 Especificación del caso de uso Identificarse Especificación del caso de uso: Contactar ID DCU-PGAG.03 Nombre Contact us Descripción Permite realizar la puesta en contacto de un usuario con un administrador Actores usuario no registrado Precondiciones --- Postcondiciones Mensaje de usuario entregado al administrador Flujo Normal de Eventos 1. El usuario selecciona la opción de contactar con administrador 2. El sistema muestra una página estática con la información de contacto y con un formulario con los campos de: nombre, email, mensaje 3. El entrenador rellena los campos del formulario y pulsa el botón de enviar 4. El sistema comprueba que se hayan rellenado todos los datos y envía la información al email de contacto del administrador Flujo Alternativo 4.1. Si el sistema detecta que no se han rellenado todos los campos del formulario, muestra un mensaje de error y vuelve al paso 2 4.2. Si el sistema detecta que el email no tiene una estructura correcta, muestra un mensaje de error y vuelve al paso 2 Especificación del caso de uso contactar Especificación del caso de uso: tour ID DCU-PGAG.04 Nombre tour Descripción Muestra una página estática como interfaz de entrada, con un tour de las características de la aplicación Actores Usuario no registrado Precondiciones --- Postcondiciones Se le muestra al usuario el tour de la aplicación Flujo Normal de Eventos 1. El usuario selecciona la opción de ver tour de la aplicación 2. El sistema muestra una página estática con toda la información acerca del tour de la aplicación Flujo Alternativo --- Especificación del caso de uso tour
Página 103 Especificación del caso de uso: FAQ ID DCU-PGAG.05 Nombre faq Descripción Muestra una página estática como interfaz de entrada, con las preguntas más típicas realizadas por los usuario de la aplicación. Actores usuario no registrado. Precondiciones --- Postcondiciones Se le muestra al usuario el faq de la aplicación Flujo Normal de Eventos 1. El usuario selecciona la opción de ver faq de la aplicación 2. El sistema muestra una página estática con toda la información acerca del faq de la aplicación Flujo Alternativo --- Especificación del caso de uso faq Especificación del caso de uso: blog ID DCU-PGAG.06 Nombre Blog Descripción Muestra una página estática como interfaz de entrada, con las noticias más importantes de la aplicación o eventos próximos. Actores Usuario no registrado, administrador Precondiciones --- Postcondiciones Se le muestra el blog de la aplicación Flujo Normal de Eventos 1. El usuario selecciona la opción de ver blog de la aplicación 2. El sistema muestra una página estática con toda la información acerca del blog de la aplicación Flujo Alternativo --- Especificación del caso de uso blog Especificación del caso de uso: Cerrar Sesión ID DCU-PGCP.01 Nombre Cerrar Sesión Descripción Finaliza la sesión iniciada tras identificarse un usuario registrado en el sistema. Actores Usuario registrado Precondiciones Usuario regsitrado identificado Postcondiciones Sistema finaliza la sesión del usuario Flujo Normal de Eventos 1. El usuario selecciona la opción de cerrar sesión 2. El sistema elimina la sesión iniciada por el usuario 3. El sistema redirecciona al entrenador a la página principal pública de la aplicación Flujo Alternativo --- Especificación del caso de uso cerrar sesión
Página 104 Especificación del caso de uso: Cancelar cuenta ID DCU-PGCP.02 Nombre Cancelar cuenta Descripción Permite que un usuario registrado que cancele su cuenta activa en la aplicación Actores Usuario registrado Precondiciones Usuario identificado Postcondiciones Eliminada del sistema la cuenta del usuario registrado Flujo Normal de Eventos 1. El usuario selecciona la opción cancelar cuenta 2. El sistema muestra un formulario para verificar que se quiere cancelar la cuenta 3. El sistema elimina la cuenta de ese usuario registrado Flujo Alternativo --- Especificación del caso de uso cancelar cuenta Especificación del caso de uso: Cambiar datos cuenta ID DCU-PGCP.03 Nombre Cambiar datos cuenta Descripción Permite que un usuario registrado que cambie la información de su cuenta asociada al sistema.Dicha información son email, contraseña. Actores Usuario registrado Precondiciones Usuario identificado en la aplicación Postcondiciones Información de cuenta usuario modificada Flujo Normal de Eventos 1. El usuario selecciona la opción de modificar cuenta 2. El sistema muestra un formulario con campos de su cuenta en modo de edición. 3. El usuario modifica los datos del formulario que desee y pulsa el botón para enviar el formulario 4. El sistema valida los campos y comprueba que los campos obligatorios estén cumplimentados 5. El sistema almacena los datos modificados en el perfil asignado al usuario Flujo Alternativo 1. Si el sistema detecta que no se han rellenado los campos obligatorios o hay un fallo de validación de datos, el sistema muestra un mensaje de error y vuelve al paso 2 Especificación del caso de uso cambiar datos cuenta
Página 105 Especificación del caso de uso: Lista de tareas ID DCU-PGT.01 Nombre Ver listar tareas Descripción Muestra el listado de los tareas insertados por un usuario en la aplicación Actores Usuario registrado. Precondiciones Usuario identificado en la aplicación Postcondiciones --- Flujo Normal de Eventos 1. El usuario selecciona la opción de ver lista de tareas 2. El sistema muestra el listado de todos las tareas pertenecientes al usuario registrado. Los datos que se deben mostrar son los de: nombre. Flujo Alternativo 2.1 Si el usuario no ha insertado ningún tarea en el sistema, el sistema muestra la carpeta raíz "INBOX" vacía Especificación del caso de uso ver lista de tareas Especificación del caso de uso: ver tarea ID DCU-PGT.02 Nombre Ver tarea Descripción Muestra una tarea específica perteneciente al usuario registrado Actores Usuario registrado Precondiciones Usuario está identificado y viendo el listado de tareas Postcondiciones --- Flujo Normal de Eventos 1. El usuario selecciona la tarea que quiere ver de la lista de tareas 2. El sistema muestra los datos pertenecientes a la tarea especificada Flujo Alternativo --- Especificación del caso de uso ver tarea
Página 112 Flujo Normal de Eventos 1. El usuario selecciona la opción de modificar del proyecto 2. El sistema muestra un formulario con los campos de nombre. 3. El usuario modifica alguno de los campos del formulario y pulsa el botón de modificar 4. El sistema valida los campos modificados. 5. El sistema almacena los datos del proyecto modificado y muestra el mensaje de proyecto modificado correctamente Flujo Alternativo 3.1. Si el usuario pulsa el botón de cancelar, ir a paso 3.2 3.2. El sistema no almacena los datos del proyecto y cancela todo el proceso 4.1. Si el sistema detecta que hay un fallo en la validación de los datos, muestra un mensaje de error y vuelve al paso 2 Especificación del caso de uso modificar proyecto Especificación del caso de uso: Eliminar proyecto ID DCU-PGP.05 Nombre Eliminar proyecto Descripción Elimina del sistema un proyecto perteneciente a un usuario registrado. Actores Usuario registrado Precondiciones Usuario identificado en la aplicación y viendo el proyecto específico a eliminar Postcondiciones Actualizado el listado de proyectos asociados al usuario registrado Flujo Normal de Eventos 1. El usuario selecciona la opción de eliminar proyecto 2. El sistema muestra un mensaje para confirmar la eliminación del proyecto 3. El usuario pulsa el botón de eliminar 4. El sistema elimina de la aplicación el proyecto especificado junto con las tareas pertenecientes al mismo Flujo Alternativo 3.1. Si el usuario pulsa el botón de cancelar, ir a paso 3.2 3.2. El sistema no elimina el proyecto de la aplicación, se cancela el proceso Especificación del caso de uso eliminar proyecto
Página 113 Especificación del caso de uso: Añadir interrupción ID DCU-PGI.03 Nombre Añadir interrupción Descripción Permite a un usuario registrado insertar una interrupción en una tarea especificada del sistema Actores Usuario registrado Precondiciones Usuario identificado en la aplicación Postcondiciones Actualizada la lista de interrupciones asociados a la tarea y al usuario registrado Flujo Normal de Eventos 1. El usuario selecciona la opción de añadir interrupción 2. El sistema muestra un formulario con los campos: nombre, descripción 3. El usuario inserta los valores para el nombre y la descripción 4. El sistema valida los campos y comprueba que los campos obligatorios estén cumplimentados. 5. El sistema almacena el registro del nueva interrupción y muestra un mensaje al usuario de " interrupción añadida correctamente" Flujo Alternativo 3.1. Si el usuario pulsa el botón de cancelar, ir a paso 3.2 3.2. El sistema no almacena el registro del interrupción y cancela todo el proceso 4.1. Si el sistema detecta que no se han rellenado los campos obligatorios o hay fallo de validación de datos, el sistema muestra un mensaje de error y vuelve al paso 2 Especificación del caso de uso añadir interrupción Especificación del caso de uso: Empezar interrupción ID DCU-PGI.06 Nombre Empezar interrupción Descripción Creación y comienzo contador del tiempo de la interrupción Actores Usuario registrado Precondiciones Usuario identificado en la aplicación Postcondiciones --- Flujo Normal de Eventos 1. El usuario selecciona crea la interrupción en una tarea específica 2. Se pone en marcha un contador de tiempo para contar el tiempo de interrupción Flujo Alternativo --- Especificación del caso de uso Empezar interrupción
Página 114 Especificación del caso de uso: Finalizar interrupción ID DCU-PGI.07 Nombre Finalizar interrupción Descripción Finaliza el contador de tiempo interrumpido Actores Usuario registrado Precondiciones Usuario identificado en la aplicación Postcondiciones --- Flujo Normal de Eventos 1. El usuario selecciona retomar una tarea específica 2. El sistema finaliza contador de tiempo asociado a la interrupción que estaba en marcha Flujo Alternativo --- Especificación del caso de uso finalizar interrupción Especificación del caso de uso: inbox ID DCU-PGGTD.01 Nombre inbox Descripción Carpeta raíz del sistema a donde va inicialmente todo proyecto o tarea creado por la aplicación. Actores Usuario registrado Precondiciones Usuario identificado en la aplicación Postcondiciones --- Flujo Normal de Eventos 1.El usuario se identifica en el sistema 2.El usuario entra en su "work desk" donde se le mostrará su carpeta raíz inbox. Flujo Alternativo 1.1 El usuario no se identificar correctamente y se queda en el punto 1 hasta que lo haga. Especificación del caso de uso de inbox Especificación del caso de uso: Algoritmo GTD ID DCU-PGGTD.02 Nombre Algoritmo GTD Descripción El sistema en toda tarea pone en marcha el algoritmo GTD para llevar la gestión de las tareas. Actores Usuario registrado Precondiciones Usuario identificado en la aplicación, y haber creado tareas almacenadas en inbox. Postcondiciones --- Flujo Normal de Eventos 1.Sacar de inbox tareas 2.Poner en marcha el algoritmo GTD para la gestión de las tareas Flujo Alternativo 1.1 No sacar tareas de inbox porque no hay ninguna en la carpeta. Especificación del caso de uso de Algoritmo GTD
Página 115 Especificación del caso de uso: Distribución de la tarea en varios estados ID DCU-PGGTD.03 Nombre Distribución de la tarea en varios estados Descripción Para tareas que tenemos que hacerlas nosotros que nos lleva más de 2 minutos hacerlas el sistema gestiona estas tareas asignándolas en una carpetas específicas. Actores Usuario registrado Precondiciones Usuario identificado en la aplicación y comienzo de algoritmo GTD Postcondiciones --- Flujo Normal de Eventos 1.El Algoritmo GTD identifica que la analiza la tarea 2.El algoritmo GTD observa que es una tarea que tenemos que hacer nosotros 3. El algoritmo GTD observa que la tarea nos lleva más de 2 minutos hacerla. 4.El algoritmo GTD decide distribuir la tarea a una carpeta en particular de un conjunto de carpetas con objetivos claros cada una de ellas. Flujo Alternativo 2.1 El algoritmo GTD observa que es una tarea que no tenemos que hacerla nosotros sino tenemos que delegarla en otra persona 3.1 El algoritmo GTD observa que la tarea se puede realizar en menos de 2 minutos. Puntos de Extensión 4.1. Si el usuario es distribuido a la carpeta próximo. Ver Caso de DCU-PGGTD.04 4.2. Si el usuario es distribuido a la carpeta proyecto. Ver Caso de DCU-PGGTD.05 4.3. Si el usuario es distribuido a la carpeta En espera. Ver Caso de DCU-PGGTD.06 4.4. Si el usuario es distribuido a la carpeta Algún día. Ver Caso de DCU-PGGTD.07 Especificación del caso de uso de distribución de la tarea en varios estados Especificación del caso de uso: Estado próximo ID DCU-PGGTD.04 Nombre Estado próximo Descripción Se incluye tareas que se debe realizar cuanto antes Actores Usuario registrado Precondiciones Usuario identificado en la aplicación y haber empezado analizar una tarea con el algoritmo GTD Postcondiciones --- Flujo Normal de Eventos 1.El algoritmo GTD decide después de analizar el la tarea con el algoritmo GTD ponerlo en la carpeta próximo debido a su prioridad. Flujo Alternativo 1.1 El algoritmo decide ponerlo en otra carpeta excluyendo la carpeta próximo. Especificación del caso de uso de próximo
Página 116 Especificación del caso de uso: Estado proyecto ID DCU-PGGTD.05 Nombre Estado proyecto Descripción Se incluye tareas que implican realizar más de una acción Actores Usuario registrado Precondiciones Usuario identificado en la aplicación y haber empezado analizar una tarea con el algoritmo GTD Postcondiciones --- Flujo Normal de Eventos 1.El algoritmo GTD decide después de analizar el la tarea con el algoritmo GTD ponerlo en la carpeta proyecto debido a que la tarea implica realizar más de una acción Flujo Alternativo 1.1 El algoritmo decide ponerlo en otra carpeta excluyendo la carpeta proyecto. Especificación del caso de uso de proyecto Especificación del caso de uso: Estado En espera ID DCU-PGGTD.06 Nombre En espera Descripción Son tareas que necesita la intervención de otra persona para ser realizada. Actores Usuario registrado Precondiciones Usuario identificado en la aplicación y haber empezado analizar una tarea con el algoritmo GTD Postcondiciones --- Flujo Normal de Eventos 1.El algoritmo GTD decide después de analizar el la tarea con el algoritmo GTD ponerlo en la carpeta En espera debido necesita la intervención de otra persona para ser realizada. Flujo Alternativo 1.1 El algoritmo decide ponerlo en otra carpeta excluyendo la carpeta en espera. Especificación del caso de uso de en espera Especificación del caso de uso: Algún día ID DCU-PGGTD.07 Nombre Algún día Descripción Son tareas que debemos hacer pero no son prioritarias Actores Usuario registrado Precondiciones Usuario identificado en la aplicación y haber empezado analizar una tarea con el algoritmo GTD Postcondiciones --- Flujo Normal de Eventos 1.El algoritmo GTD decide después de analizar el la tarea con el algoritmo GTD ponerlo en la carpeta Algún día debido a que son tareas que no son prioritarias Flujo Alternativo 1.1 El algoritmo decide ponerlo en otra carpeta excluyendo la carpeta Algún día. Especificación del caso de uso de Algún día
Página 117 Especificación del caso de uso: Revisión de prioridades y estado de las tareas ID DCU-PGGTD.08 Nombre Revisión de prioridades y estado de las tareas Descripción Cada 24 hora el sistema avisará al usuario para que revise sus tareas a ve si han cambiado las prioridades o los estados de las tareas y las sitúen en lugar correcto Actores Usuario registrado Precondiciones Usuario identificado en la aplicación y haber usado el algoritmo GTD para analizar tareas Postcondiciones --- Flujo Normal de Eventos 1.El sistema avisa con una alerta al usuario tras 24 hora 2.El usuario deberá para cada tarea revisar las prioridades y el estado Flujo Alternativo --- Especificación del caso de uso de Revisión de prioridades y estado de las tareas 5.2.4 Requisitos no Funcionales El sistema debe cumplir una serie de requisitos que son independiente de los objetivos principales del proyecto. Los requisitos no funcionales generales estarán enmarcados en los siguientes aspectos: La solución debe estar basada en web. La aplicación debe estar diseñada y desarrollada sobre la plataforma Ruby On Rails. Orientada a objetos. De fácil mantenimiento, uso de guías y patrones con especial énfasis en el patrón MVC, documentación y de fácil ubicación de componentes. Que permita y utilice reutilización de código. Además intentaremos que el software cumpla con un par de requisitos de apariencia como: Que las pantallas usen un estilo visual característico y que no moleste a la vista, siendo lo más agradable a la vista que se pueda .Se debe diseña la aplicación atendiendo a las reglas establecidas por HTML 5.x y CSS 3.x. Su simplicidad inicial debe ser lo más fácil posible. En cuanto a requisitos de usabilidad y accesibilidad se intentará que las interfaces del sistema sea lo más fáciles de utilizar que se pueda para ellos: Las interfaces estará formadas por pantallas muy ligeras con poca información simultánea. El sistema tendrá que poderse usar de forma intuitiva sin la necesidad de leer ningún manual de usuario. Se utilizará imágenes y iconos representativos para la información mostrada en las pantallas Evitaremos que en los formularios se pidan datos repetidos en otros formularios
Página 118 El sistema mostrará mensajes y textos descriptivos para que el usuario sepa en todo momento que requiere el sistema El sistema informará siempre del resultado de las operaciones realizadas. De éste modo el usuario tendrá certeza de que la operación realizada se ha producido del modo esperado. En cuanto a los requisitos de rendimiento y mantenibilidad se debe cumplir: El tiempo de respuesta del sistema para cualquier petición del usuario tiene que ser lo más pequeños posible que se pueda Debe contemplar requerimientos de confiabilidad y consistencia de los componentes de negocio ante recuperaciones. En caso de fallas de algún componente, no debe haber pérdida de información. El sistema debe ser mantenible. Su existencia está ligada a Ruby On Rails y, por tanto, debe ser fácil su actualización para poder seguir siendo funcional en las siguientes versiones del framework. Finalmente en cuanto a requisitos de seguridad y fiabilidad del sistema, se deben tener en consideración los siguientes criterios: Los usuarios deberán estar registrados y autentificados en el mismo. La información privada de cada usuario sólo podrá ser modificada por el propio usuario. El sistema deberá estar protegido contra el software malintencionado así como de usuarios malintencionados.
Página 119 5.3 Análisis El objetivo del análisis es comprender el problema y comenzar a desarrollar un modelo visual de lo que se está tratando de construir, independiente de la tecnología o lenguaje que utilicemos . El análisis se centra en identificar los objetos que forma el sistema, describiendo la realización de casos de uso y sirve como una abstracción del modelo de diseño. Básicamente el análisis consiste en traducir los requisitos funcionales en conceptos de software. El objetivo de hacerlo es conseguir una comprensión más precisa de los requisitos y una descripción de los mismos que sea fácil de mantener y que ayude a estructurar el sistema entero. El lenguaje que se utiliza en el análisis se basa en un modelo de análisis que nos ayudará a refinar los requisitos y a razonar sobre los aspectos internos del sistema. Durante el análisis, se identifican, de manera continua, nuevos paquetes del análisis, clases y requisitos comunes a medida que el modelo de análisis evoluciona, y los paquetes de análisis concretos continuamente se refinan y mantienen. A diferencia del modelo de casos de uso que captura la funcionalidad del sistema, el modelo de análisis da forma a la arquitectura para soportar las funcionalidades que en el modelo anterior se expresan. Sus características principales son: Proporciona un diseño preliminar, pues contiene paquetes que se usan para organizar el modelo de análisis en piezas más manejables, que representan abstracciones o subsistemas y una primera vista del diseño. Puede ayudar a descubrir una necesidad de clases adicionales. Proporciona una prueba de completitud a los casos de uso, antes de pasar al diseño. Proporciona un diseño preliminar de la arquitectura del sistema, denotando los paquetes de análisis de alto nivel. Por lo tanto para conseguir todo estas características este capítulo se organizará de la siguiente forma: 1. Realización de los casos usos. En esta apartado se aportará información de las interacciones que se producen internamente en el sistema entre los diferentes componentes que conforman su arquitectura usando para ello diagrama de colaboración. 2. Realización de los diagramas de clases. Se mostrarán las clases que interviene en los diagramas de colaboración, mostrando la relación que existe entre cada una de ellas. 3. Realización de los diagramas de paquetes. En esta sección se esbozará el modelo de análisis y la arquitectura mediante la identificación de paquetes, proporcionando así un medio para organizar el modelo de análisis en piezas más pequeñas y más manejables.
Página 120 5.3.1 Realización de los Casos de usos En esta sección se pretende aportar una descripción de las interacciones que se producen internamente en el sistema entre los diferentes componentes que conforman su arquitectura. Para ellos nos ayudaremos de los diagramas de interacción los cuales son diagramas que describen cómo grupos de objetos colaboran para conseguir algún fin. El objetivo de estos diagramas es mostrar objetos, así como los mensajes que se pasan entre ellos dentro del caso de uso, es decir, capturan el comportamiento de los casos de uso. Actualmente existe dos tipo de diagramas de interacción: diagramas de secuencia diagramas de colaboración. Se puede decir que un diagrama de colaboración es una forma alternativa al diagrama de secuencias a la hora de mostrar un escenario. Para este análisis del proyecto final de grado se ha decidido usar diagramas de colaboración. En cada diagrama de colaboración se identificarán 3 tipos de clases de análisis, ya que trabajamos en una arquitectura 3 capas. Boundary. Se utiliza para modelar la interacción entre el sistema y sus actores, es decir, una clase boundary sirve como medio de comunicación entre un actor y el correspondiente caso de uso. Representan ventanas, formularios, paneles, interfaces de comunicación, etc.. Entity. Se utiliza para modelar información que posee una vida larga y que es a menudo persistente. Están asociadas a algún fenómeno o concepto, como una persona, un objetivo del mundo real o un suceso del mundo real. Control. Representan coordinación, secuencia, transacciones y control de los objetos y se usan para encapsular el control de un caso de uso en concreto. UML utiliza como mecanismo para extender estas notaciones de clase los siguientes iconos: En este documento se detallan las principales colaboraciones relacionadas con los principales casos de uso descritos en el proyecto. Por tanto, se detallarán los diagramas de colaboración que hacen referencia a la gestión de actividades generales, gestión de tareas, gestión de proyectos, gestión de interrupciones, gestión de la filosofía GTD. 5.3.1.1 Colaboraciones para la Gestión del Acceso La primera de las colaboraciones es la referente al registro de usuarios en el sistema. Una vez que se finaliza el proceso de registro, el usuario pasa a formar parte de los actores "usuario Registrado".
Página 121 Seguido del proceso de registro, continúa el de identificación en la aplicación. El usuario registrado debe acceder al sistema con los datos que insertó en el formulario de registro. En caso de no ser así, fallará la validación. Si no hay ningún error, el controlador de sesión permitirá el inicio de sesión correctamente. Diagrama de colaboración para identificarse en el sistema :usuario no registrado IUPrincipalPública ControlRegistro Usuario Registrado IUMensaje IUFormRegistro IUWorkDesk 2:Solicita Registrarse 7:<<create>> +3:muestra interfaz 4:Rellenarform 8:Mensaje de éxito 9:Muestra Interfaz 5:Enviar form 6:Validar datos 1:Selecciona Registrarse :usuario registrado IUPrincipalPública Controlsesion SesionUsuarioIdentificado IUMensaje IUFormIdentificarse IUWorkDesk 2:Solicita identificarse 7:inicio de sesion +3:muestra interfaz 4:Rellenarform 8:Mensaje de éxito 9:Muestra Interfaz 5:Enviar form 6:Validar datos 1:Selecciona identificarse
Página 128 A medida que se van añadiendo proyectos al sistema, un usuarios está en disposición de ver un listado con los mismos . Diagrama de colaboración para ver listado de proyectos A continuación se muestra la colaboración para ver un proyecto. El usuario registrado solicita ver la datos de un proyecto determinado de la lista de proyecto. Esto es gestionado por el controlador, mostrando una interfaz con los datos pertinentes. Diagrama de colaboración para ver proyecto Tanto para la modificación como eliminación de un proyecto el proceso es muy similar. La salvedad es que uno muestra un formulario editable para poder actualizar la información y el otro elimina un registro concreto perteneciente al usuario registrado. :usuario registrado IUGestionProyecto ControlProyecto Proyecto IUListaProyecto 2:SolicitaVerListaDeProyecto 3:VerProyecto 5:Muestra Interfaz 6:Validar datos 1:IniciarGestionProyecto 6:VerListaProyecto 4:ListaProyecto :usuario registrado IUListaProyecto ControlProyecto Proyecto IUDatosProyecto 2:SolicitaProyecto 3:VerProyecto 5:Muestra Interfaz 6:Validar datos 1:SeleccionaProyecto 6:VerProyecto 4:DatosProyecto
Página 129 Diagrama de colaboración para modificar proyecto Diagrama de colaboración para eliminar proyecto 5.3.1.5 Colaboraciones para la Gestión de Interrupciones Empezaremos con el diagrama de añadir una nueva interrupción y se rellenan los datos del formulario mostrado, creando a entidad interrupciones :usuario registrado IUListaProyecto ControlProyecto Proyecto IUMensaje IUFormEditarProyecto 7:ModificarProyecto 3:Muestra interfaz 4:Rellenarform 9:Mensaje de éxito 5:Enviar form 6:Validar datos 1:SeleccionaEditarProyecto 8:operación éxitosa 10:operación fallida 11:Mensaje de error 2:SolicitaEditarProyecto :usuario registrado IUListaProyecto ControlProyecto Proyecto IUMensaje IUFormConfirmarEliminarProyecto 7:<<destroy>> 4:Muestra interfaz 5:ConfirmarEliminar 9:Mensaje de éxito 10:DenegarEliminar 6:ConfirmarEliminar 1:SeleccionaEliminarProyecto IUEliminarProyecto 2:SeleccionaEliminarProyecto 3:solicitaEliminarProyecto 8:operación éxitosa 11:DenegarEliminar
Página 130 Diagrama de colaboración para añadir interrupciones Los siguientes diagramas son para el control de estado de las interrupciones cuando quieres que empiece a contar el tiempo y cuando finaliza. Diagrama de colaboración empezar interrupción :usuario registrado IUGestionInterrupcion ControlInterrupcion Interrupcion IUMensaje IUFormAñadirInterrupcion 8:<<create>> 4:Muestra interfaz 5:Rellenarform 10:Mensaje de éxito 6:Enviar form 7:Validar datos 1:Selecciona identificarse IUAñadirInterrupcion 2:Selecciona añadirInterrupcion 3:seleccionaAñadirInterrupcion 9:operación éxitosa 11:operación fallida 12:Mensaje de error :usuario registrado IUListaTareas ControlInterrupción interrupcion IUFormInterrupcion 2:SolicitaEmpezarInterrupcionTarea 6:<<create>> 3:Muestra Interfaz 5:Validar datos 1:SeleccionaEmpezarInterrupción 4:RellenaForm 7:OperacionOk Mensaje 8:MensajeÉxito 9:OperacionError 9:MensajeError
Página 131 Diagrama de colaboración finalizar interrupción 5.3.1.6 Colaboraciones para la Gestión de Gtd Los diagramas asociados a la gestión GTD se exponen a continuación: Diagrama de colaboración inbox :usuario registrado IUListaTareas ControlInterrupción interrupcion 2:SolicitaFinalizarInterrupcion 6:finalizarInterrupcion 1:SeleccionaReanurarTarea 7:OperacionOk Mensaje 8:MensajeÉxito :usuario registrado IUInbox ControlGTD tarea IUListaTareas-Proyectos 3:TareaDeBusqueda 5:Muestra interfaz 1:MuestraInterfaz 2:SolicitaInbox Proyecto 4:ProyectoDeBusqueda
Página 132 Diagrama de colaboración de analisis del algortimo GTD Diagrama de colaboración distribucción de acciones de GTD Diagrama de colaboración de Revisión de tareas GTD :usuario registrado IUListaTareas ControlGTD IUtareProcesada 4:Muestra interfaz 1:MuestraInterfaz 2:SolicitaAnalizarTarea :usuario registrado IUOperaciónGTD ControlGTD tarea IUListaTareas-Proyectos 3:TareaDeBusqueda 5:Muestra interfaz 1:MuestraInterfaz 2:SolicitaPróximo Proyecto 4:ProyectoDeBusqueda 3:SolicitaProyecto 4:SolicitaEnEspera 5:SolicitaAlgúnDía :usuario registrado IUListaTarea ControlGTD tarea IUListaTareas-Proyectos 3:TareaDeBusqueda 5:Muestra interfaz 1:MuestraInterfaz 2:ReordenarEstado Proyecto 4:ProyectoDeBusqueda
Página 133 5.3.2 Realización de los Diagramas de Clases En este apartado se mostrarán las clases que han intervenido en los diagramas de colaboración, mostrando la relación que existe entre cada una de ellas a nivel de conceptos. Dichas clases Se han estructurado en base a los paquetes principales de la aplicación, y por sencillez de algunos requisitos, no se representarán la totalidad de las características de la aplicación. 5.3.2.1 Diagrama de Clase de Actividades Generales :usuario registrado IUPrincipalPública <<boundary>> ControlUser <<control>> SesionUsuarioIdentificado <<entity>> IUFormIdentificarseOK <<boundary>> IUFormIdentificarse <<boundary>> IUWorkDesk <<boundary>> usuario Controlsesión <<control>> usuarioRegistrado <<entity>> IUFormRegistro <<boundary>> IUFormRegistroOK <<boundary>>
Página 134 5.3.2.2 Diagrama de Clase de Gestión de perfil :usuario registrado IUPrincipal <<boundary>> ControlCuenta <<control>> IUFormDatosCuenta <<boundary>> CuentaSesión <<entity>> IUPerfil <<boundary>> IUConfirmaciónCarcelarCuenta <<boundary>> IUCuentaUsuario <<boundary>> IUMensajes <<boundary>>
Página 135 5.3.2.3 Diagrama de Clase de Gestión de Tareas :usuario registrado IUListaTareas <<boundary>> ControlTarea <<control>> Interrupciones <<entity>> IUFormEditarTarea <<boundary>> IUFormAñadirTarea <<boundary>> IUConfirmarEliminarTarea <<boundary>> tarea <<entity>> IUGestionTarea <<boundary>> IUAñadirTarea <<boundary>> IUDatosTareas <<boundary>> IUBuscarTarea <<boundary>> IUFormBuscar <<boundary>> IUFormEjecuccionTarea <<boundary>> IUMensajes <<boundary>>
Página 136 5.3.2.4 Diagrama de Clase de Gestión de Proyecto :usuario registrado IUListaProyecto <<boundary>> ControlProyecto <<control>> IUFormEditarProyecto <<boundary>> IUFormAñadirProyecto <<boundary>> IUConfirmarEliminarProyecto <<boundary>> Proyecto <<entity>> IUGestionProyecto <<boundary>> IUAñadirProyecto <<boundary>> IUDatosProyecto <<boundary>> IUBuscarProyecto <<boundary>> IUEliminarProyecto <<boundary>> IUMensajes <<boundary>>
Página 137 5.3.2.5 Diagrama de Clase de Gestión de Interrupción :usuario registrado IUListaInterrupción <<boundary>> ControInterrupción <<control>> IUFormAñadirInterrupción <<boundary>> Interrupción <<entity>> IUGestionInterrupción <<boundary>> IUAñadirInterrupción <<boundary>> IUDatosInterrupción <<boundary>> IUFormEjeccuciónInterrupcion <<boundary>> IUEjecucciónInterrupcion <<boundary>> IUMensajes <<boundary>>
Página 144 otro controlador. Así mismo, también es el encargado de manejar las sesiones y el flujo general de la aplicación. Action View. Es llamado por Action Controller. Renderiza una vista pedida por el usuario a través del navegador. Este módulo provee de mecanismos para el uso de: plantillas para generación de vistas; helpers que ayuden con la lógica y generación de HTML; métodos para representar la información en otros formatos. 3. Active Model. Define la interfaz entre los módulos de Action Pack y Active Record. 4. Active Record. Módulo usado para crear clases del modelo, los cuáles contienen la lógica de negocio, manejan las validaciones y relaciones, mapean objetos a tablas, y soporte para el uso de diferentes SGBD. 5. Active Resource. Se usa para manejar las conexiones entre los servicios RESTful y los objetos que controlan la lógica de negocio. Sigue el mismo principio que Active Record: el reducir la cantidad de código necesario para gestionar recursos. Active Resources mapea clases del modelo con recursos REST de la misma manera que Active Record lo hace entre clases de modelo y tablas de la base de datos. 6. Active Support. Es una colección de clases de soporte y librerías de extensión de Ruby que son útiles en el desarrollo sobre Rails. Incluyen un completo soporte para tratamiento de ristras, internacionalización, tratamiento de fechas/horas y testing. 7. Railties. Es el código del núcleo de rails que se encarga de construir nuevas aplicaciones. Es el responsable de la unión de todos los módulos anteriores. Además, se encarga de todo el proceso de bootstrapping, la interfaz de línea de comandos y proporciona generadores de código. Las vistas seleccionadas para analizar la arquitectura son: vista de módulos y vista de componentes. 1. La vista de módulos contiene los diagramas UML que representan la vista estática de todos los componentes.
Página 145 2. Vista de componentes muestra los diagramas con la arquitectura del sistema de forma dinámica, qué componentes existen en el momento de ejecución y cómo se comunican entre sí.
Página 146 5.4.2 Diagramas de Clases En la introducción se detalla brevemente el proceso seguido para definir la etapa de diseño de la aplicación. En este apartado en concreto, haremos referencia a los diagramas de clases. El propósito de este diagrama es el de representar los objetos fundamentales del sistema, es decir un diagrama de clase describe la estructura de un sistema mostrando sus clases, atributos y las relaciones entre ellos. Los diagramas de clases son utilizados durante el proceso de análisis y diseño de los sistemas, donde se crea el diseño conceptual de la información que se manejará en el sistema, y los componentes que se encargaran del funcionamiento y la relación entre uno y otro. Para realizar un diagrama de clases, como primer paso se necesita esbozar una o varias clases del diseño, dada la entrada en términos de clases de análisis o interfaces. Si tomamos una clase de diseño para que proporcione una interfaz los métodos utilizados es dependiente de la tecnología de interfaz específica que se utilice. En este caso en particular, al ser un dispositivo web y móvil hacia los que está orientado la aplicación y al usar HTML5/CSS3, los estereotipos deberían ser elementos relacionados con la clase, sin embargo para simplificar los diagramas de clase usaremos ((ActionView)) como estereotipo. Normalmente las aplicaciones necesita que se diseñe clases de entidades que represente información persistente, para ello existe el uso de tecnologías de base de datos. En Rails estas clases están relacionadas con((ActiveRecord)) y, en general, son denominadas clases del modelo. Cuando diseñamos las clase de control , estas clases son una tarea dedica ya que encapsulan secuencias o coordinación entre otros objetos del sistema. Lo que se hará será que todos los controladores que creemos hereden de Application Controller convirtiéndose este en el controlador padre de todos los demás controladores creados en la aplicación. Durante la construcción del diseño se ha tenido que asumir varias imposiciones de diseño marcadas por el entorno de desarrollo que hemos utilizado: Como se detalló en la arquitectura, la aplicación se apoya en el patrón MVC donde el controlador interactúa con el modelo y con las vistas. Todos los controladores heredan de Application Controller. Todos los modelos heredan de ActiveRecord::Base, encargada de mapear objetos con las tablas de la base de datos. ActiveRecord::Base contiene métodos para las validaciones de datos de los modelos. En los modelos se establece la lógica de negocio. Es decir, en los modelos es donde se realiza las asociaciones entre entidades. Todas las vistas serán renderizadas por el módulo Action View, incluyendo soporte para el uso de helpers de Rails. Existe correspondencia directa entre los nombres de las acciones (métodos de clase) de los controladores y las vistas asociadas.
Página 147 A continuación se mostrarán las principales clases que intervienen en la fase y que están apoyadas por la arquitectura del software: Diagrama de clase entre modelos PERSONA +first_name +last_name +avatar +email INTERRUPCIONES +name +description +duration +task_id +start_time +end_time TAREAS +task_name +priority +note PROYECTOS +project_title EVENTOS DEL CALENDARIO CONTROL DE TIEMPO ESTADOS DE GTD * 1 * 1 * 1 1 1 1 1 0..1 1
Página 148 Diagrama de clase MVC-User Users User <<ActiveRecord>> UsersControllers <<AplicationController>> Tasks Projects Interruption GTD <GEM> Devise statistics
Página 149 Diagrama de clase MVC-Task Tasks Task <<ActiveRecord>> Interruptión <<ActiveRecord>> TaskControllers <<ApplicationController>> +index() +Create() +edit() +update() +destroy() +new() index.html.erb <<ActionView>> Show.html.erb <<ActionView>> Edit.html.erb <<ActionView>> New.html.erb <<ActionView>> _form.html.erb <<ActionView>> * 1
Página 150 Diagrama de clase MVC-Project Project Proyecto <<ActiveRecord>> Task <<ActiveRecord>> ProjectControllers <<ApplicationController>> +index() +Create() +edit() +update() +destroy() +new() index.html.erb <<ActionView>> Show.html.erb <<ActionView>> Edit.html.erb <<ActionView>> New.html.erb <<ActionView>> _form.html.erb <<ActionView>> * 1
Página 151 Diagrama de clase MVC-Interruption 5.4.3 Diagramas de Secuencias Un diagrama de secuencia muestra la interacción de un conjunto de objetos en una aplicación a través del tiempo y se modela para cada caso de uso. El diagrama de secuencia contiene detalles de implementación del escenario, incluyendo los objetos y clases que se usan para implementar el escenario y mensajes intercambiados entre los objetos, es decir, capturan el comportamiento de los casos de uso. La secuencia de acciones en un caso de uso comienza: 1. Cuando un actor invoca el caso de uso mediante el envío de algún tipo de mensaje al sistema. 2. Se obtiene el mensaje del actor con algún objeto de diseño. 3. Después el objeto de diseño llama a algún otro objeto, y de esa manera los objetos implicados interactúan para realizar y llevar a cabo un caso de uso. En el diseño, es preferible representar esto con diagramas de secuencia, ya que el centro de atención principal es el encontrar secuencias de interacciones detalladas y ordenadas en el tiempo. Interruption Task <<ActiveRecord>> Interruptión <<ActiveRecord>> InterruptionControllers <<ApplicationController>> +index() +Create() +edit() +update() +destroy() +new() index.html.erb <<ActionView>> Show.html.erb <<ActionView>> Edit.html.erb <<ActionView>> New.html.erb <<ActionView>> _form.html.erb <<ActionView>> *1
Página 152 A continuación observaremos un ejemplo de iteración para la gestión de tarea. Con el fin de que el lector se sitúe en cómo interactúan los objetos entre sí, en este ejemplo se muestra algunos diagramas de secuencia para la gestión de tarea. Queda mencionar, que no se incluyen todos los diagrama de secuencia que cubren los casos de uso porque al usar el patrón MVC los diagramas de interacción que se generan son muy parecidos. La figura anterior muestra el diagrama de secuencia para ver tarea. El flujo de acción que se sigue es el siguiente: 1. Usuario registrado hace una petición para ver la lista de tareas. El actor interactúa con la vista enviando el mensaje de que quiere que se le muestre un listado con todos las tareas. 2. La vista de tarea hace una petición (ejecutar index) al controlador de tarea. La vista envía un mensaje al controlador para que éste ejecute el método index correspondiente al encargado de mostrar el listado de todos los entrenamientos del sistema. 3. Controlador envía mensaje a modelo de tarea pidiéndole que le devuelva un array con todos los entrenamientos que hay almacenados en la base de datos. 4. El modelo devuelve en una variable todos las tareas que pertenecen al usuario. 5. Controlador renderiza la vista correspondiente a ver tareas (index.html.erb). 6. Mostrada la vista al usuario registrado, éste selecciona la opción de ver una tarea en particular. : Vista tasks <<ActionView>> : Controlador task <<ActionController>> : Tasks <<ActiveRecord>> Usuario Registrado 1 : Ver todo los Tasks() 2 : Index() 3 : tasks.all() 4 : @task=tasks.all() 5 : Render index.html.erb() 6 : Selecciona task() 7 : Show() 8 : Task.find() 9 : @task= task.id() 10 : Render show.thml.erb() 11 : Ver task()
Página 153 7. Al pulsar sobre el elemento de interfaz, la vista envía el mensaje al controlador con la petición de que se ejecute la acción show. Usando el método POST, se envía el identificador del tarea que se quiere ver. 8. Capturado el identificador de la tarea que se desea ver, el controlador hace una búsqueda de este entrenamiento sobre el modelo. 9. El modelo devuelve en una variable la tarea correspondiente. 10. El controlador renderiza la vista para mostrar la tarea. Esta vista tiene acceso a las variables instanciadas en el controlador, por lo que dispone de los datos de la tarea que lo compone. A continuación se muestra el diagrama de interacción para modificar tarea. El flujo de interacciones es muy similar al explicado anteriormente. Sin embargo, una vez que se ha obtenido la tarea que se desea editar y se ha renderizando la vista edit.html.erb empiezan las variaciones. El usuario registrado modifica la tarea a través del formulario que aparece en la vista de editar. Sobre él se realizan las modificaciones necesarias, cambiando el contenido de cualquiera de los campos que lo conforman. Al pulsar enviar en la vista, ésta envía un mensaje de modificación "update" al controlador de tarea. El controlador tarea envía el mensaje a los modelos de tarea . Realizadas las modificaciones, se renderiza la vista de ver tarea (show.html.erb) con el mensaje de que la tarea ha sido modificada. : Vista tasks <<ActionView>> : Controlador task <<ActionController>> : Tasks <<ActiveRecord>> Usuario Registrado 1 : Ver todo los Tasks() 2 : Index() 3 : tasks.all() 4 : @task=tasks.all() 5 : Render index.html.erb() 6 : Selecciona task() 7 : edit() 8 : Task.find() 9 : @task= task.id() 10 : Render edit.thml.erb() 11 : Modificar task() 12 : Update() 13 : task.update_attributes() 14 : Render show.html.erb()