II Informe de prctica de especialidad para optar por el ttulo de Ingeniero en Computacin con el grado acadmico de Bachillerato
Josu Santamara Agero
Cartago Marzo, 2014
P g i n a 2 | 24
Contenido Introduccin ............................................................................................................................................ 3 Modelo de diseo.................................................................................................................................... 4 Arquitectura del sistema ...................................................................................................................... 4 Partes del sistema ............................................................................................................................ 5 Componentes y servicios ..................................................................................................................... 7 Diseo de base de datos .................................................................................................................... 11 Plan de trabajo ...................................................................................................................................... 13 Anlisis de los riesgos ............................................................................................................................ 14 Informes de Avance ............................................................................................................................... 15 Informe de Avance #1 ........................................................................................................................ 15 Informe de Avance #2 ........................................................................................................................ 16 Informe de Avance #3 ........................................................................................................................ 17 Informe de Avance #4 ........................................................................................................................ 18 Informe de Avance #5 ........................................................................................................................ 19 Informe de Avance #6 ........................................................................................................................ 20 Informe de Avance #8 ........................................................................................................................ 21 Informe de Avance #9 ........................................................................................................................ 22 Informe de Avance #10 ...................................................................................................................... 23
P g i n a 3 | 24
Introduccin
El presente documento pretende informar a las autoridades pertinentes del Instituto Tecnolgico de Costa Rica el avance de la Prctica de Especialidad realizada por el estudiante Josu Santamara Agero en la empresa Intelligent Sense S.A. Este documento consta del segundo informe realizado por el estudiante sobre su proyecto de prctica, presentando el diseo del sistema, as como el plan de trabajo establecido para la realizacin del mismo.
Se presenta el modelo de diseo del sistema de COES S.A. En dicho modelo se expone el diagrama de arquitectura del sistema, explicando detalladamente las capas del sistema. Al tratarse de una plataforma web, la arquitectura del sistema se basa en una arquitectura de sistema distribuido, la que se presenta ms adelante. Cada una de las capas del sistema es detallada, con el objetivo de que el lector de este documento pueda comprender para que se usa cada una de ellas y cul es su funcin primordial en el sistema.
Con esta arquitectura se busc una solucin ptima a nivel de generacin de cdigo y de otras variables como lo son la escalabilidad, la mantenibilidad del sistema y una estructura eficiente del mismo.
Posteriormente, se presentan y se explican los componentes y servicios usados en el sistema, que en nuestro caso se trata de las tecnologas utilizadas para la construccin de la aplicacin, as como las libreras utilizadas para una mejor experiencia para el usuario final.
Todas las libreras utilizadas tienen respaldo, ya sea por una comunidad de cdigo abierto, o por una empresa desarrolladora que posee un producto a nivel comercial al cual le dan soporte. Cabe destacar que se buscaron las mejores prcticas, tanto a nivel de cdigo como en el uso de dichas libreras, siempre se investig a fondo cada una de ellas y que otras opciones se posean para la labor a desarrollar.
Tambin se presenta el diagrama de base de datos, en el cual el lector podr informarse de qu manera se est guardando la informacin persistente del sistema. A pesar de que la base de datos de Mongo es documental y no relacional, se hizo un esfuerzo en generar un diagrama que represente dicha base de datos, a travs de las posibles relaciones a presentar en el sistema de COES.
Luego, se presenta el anlisis de riesgos para el proyecto, en este aspecto cabe resaltar que no se han estimad que hayan grandes y gran cantidad de riesgos para el proyecto, debido a la metodologa con que se desarrolla el mismo. Al tratarse de una metodologa gil como SCRUM, el cliente del proyecto (COES) posee un contacto fluido y al menos una vez por semana con el equipo encargado de desarrollar el proyecto, esto genera que el cliente pueda otorgar una retroalimentacin oportuna y a tiempo de la generacin de funcionalidades en el sistema, por lo que lo que se entregue al finalizar el proyecto, ya va a ser de conocimiento total del cliente.
P g i n a 4 | 24
Modelo de diseo
El modelo de diseo es una herramienta de comunicacin, para establecer de una manera sencilla la forma en que se desarrolla el proyecto, y la comunicacin entre los componentes o mdulos del sistema. El modelo de diseo se basa en la frase divide y vencers, ya que se trata de agarrar todo un problema grande (el sistema) en pequeos problemas que sean ms fciles de solucionar. Entonces, el modelo de diseo nos ayuda a identificar dichos pequeos problemas en unidades ms simples. El modelo de diseo posee un Anlisis Orientado a Objetos (AOO) y utiliza conceptos del entorno para dividir el espacio del problema. A continuacin se presenta el modelo de diseo del sistema de COES.
Arquitectura del sistema La arquitectura del sistema indica la estructura, funcionamiento e interaccin entre las partes del software. La arquitectura del software es un nivel de diseo que hace foco en aspectos ms all de los algoritmos y estructuras de datos de la computacin; el diseo y especificacin de la estructura global del sistema es un nuevo tipo de problema. La Arquitectura del Software es el diseo de ms alto nivel de la estructura de un sistema. Una arquitectura de software se selecciona y disea con base en objetivos (requerimientos) y restricciones. Los objetivos son aquellos prefijados para el sistema de informacin, pero no solamente los de tipo funcional, tambin otros objetivos como la mantenibilidad, flexibilidad e interaccin con otros sistemas de informacin. Las restricciones son aquellas limitaciones derivadas de las tecnologas disponibles para implementar sistemas de informacin. Unas arquitecturas son ms recomendables de implementar con ciertas tecnologas mientras que otras tecnologas no son aptas para determinadas arquitecturas, para el caso del sistema de COES, la arquitectura est orientada para una plataforma web. La arquitectura de software define, de manera abstracta, los componentes que llevan a cabo alguna tarea de computacin, sus interfaces y la comunicacin entre ellos. La arquitectura debe ser implementada en una arquitectura fsica, que consiste simplemente en determinar qu computadora tendr asignada cada tarea. En la figura 1 podemos observar la arquitectura del sistema planteada y desarrollada para el sistema de COES. En esta figura, podemos observar la labor de cada parte del sistema y la tecnologa de la cual se hace uso. Posteriormente se explicar en detalle la labor de cada parte de la arquitectura del sistema.
P g i n a 5 | 24
Partes del sistema Debido a los requerimientos de COES y al tratarse de una plataforma web, COES es un sistema distribuido, esto es, que el sistema opera en distintos computadores o dispositivos. Para el caso de COES, existe un servidor web, que denominaremos backend de ahora en adelante. En el backend se encuentra el servidor web publicado a travs de NodeJs, los endpoints, los implementors, funciones utilitarias del sistema, los modelos de la base de datos, y la base de datos. Luego, existe otra capa mayoritaria, que es la capa de cliente que continuaremos llamando frontend. El frontend es la parte del software en la que interacta el usuario final con el sistema, contiene todas las Styles - scss Scripts AngularJS (Controllers, directives, factories, filters, providers, services) Views AngularJS, html U t i l s
-
j s
Frontend S e r v e r
-
N o d e J s
A p p . j s
Implementors - js Endpoints routes-config.js Models - mongoose MongoDB U t i l s
-
j s
Backend Figura 1 Arquitectura del sistema de COES P g i n a 6 | 24
pantallas a mostrar (Vistas) y su respectiva lgica (controladores), as como el estilo de cada una de las pantallas. Para realizar la comunicacin entre el frontend y el backend, se utilizan llamadas REST, que son llamadas a travs de jQuery Ajax, en donde se puede enviar informacin al servidor o, por el contrario, obtener informacin desde el servidor. A continuacin se detalla cada una de las capas en el backend y del frontend. Backend
Server Es la capa en la que se establece un servidor y se hace visible para el mundo de la World Wide Web (www). A travs de la tecnologa empleada de NodeJs se pone en funcionamiento el sistema y se configuran los aspectos generales del mismo, como por ejemplo la direccin web, el puerto de salida, la conexin con la base de datos, el tipo de autenticacin que se usa, entre otras cosas. Endpoints Los endpoints son puntos de acceso al backend, ya que en el backend se encuentra los datos persistentes del sistema (base de datos), es necesario la comunicacin contina y fluida entre el frontend y el backend. En los endpoints se determinan rutas, donde se establecen cules son las rutas para otorgar datos, cuales son las rutas para actualizar datos y cuales para salvar datos, esto para cada una de las funcionalidades del sistema. Por ejemplo se tiene un endpoint para obtener los usuarios, otro para actualizar datos de un usuario, y otro para salvar los usuarios. Cabe destacar que solo navegadores con una sesin establecida entre el frontend y el backend, pueden tener acceso a estas rutas, esto por motivos de seguridad del sistema y que no cualquiera pueda accesar la informacin y/o manipularla. Implementors Es la parte lgica del backend, aqu se procesa la informacin a enviar al frontend, de acuerdo a lo requerido para cada funcionalidad, tambin se establece que hacer con la informacin enviada desde el frontend, ya sea prepararla para guardarla en la base de datos o actualizar algn dato existente en dicha base de datos. Si la informacin enviada o a enviar requiere un clculo extra o un acomodo en especial, es en esta capa del backend es donde se realiza dicha tarea. Utils Esta capa es visible para todos los archivos presentes en el backend, en esta capa estn presente rutinas y datos comunes para distintas partes del backend. Esta capa se genera con la intencin de no duplicar el cdigo generado para mismas tareas en distintas secciones, esto mejora la mantenibilidad del sistema, ya que de existir un problema con alguna rutina global del sistema, es ms sencillo tener que arreglar dicha rutina en un solo archivo, a tener que buscar por todos los archivos y arreglar el problema existente. Models En esta capa del sistema se establecen cules son los datos de cada uno de los collections de la base de datos. A travs de mongoose (se explicar en la siguiente seccin) se crean las estructuras de datos, de P g i n a 7 | 24
que tipo es cada uno de los campos y otras caractersticas, como por ejemplo, si el campo es requerido o no, o si el campo tiene un valor por defecto o no. Base de datos Es el lugar en donde se almacenan los datos del sistema de manera que no se pierda informacin, y esta informacin est disponible para COES en cualquier instante. Para efectos de este sistema se utiliza la base de datos documental de MongoDB, la cual ahondaremos un poco ms en la siguiente seccin. Frontend
Views Son las pantallas con las que interacta el usuario final del sistema, aqu se establecen cada una de las interfaces de usuario a travs de cdigo html (web) y de la librera creada por google, AngularJs, que explicaremos ms adelante. Styles Aqu se establece la esttica de cada una de las pantallas desarrolladas. Como una analoga, las hojas de estilo son como el maquillaje que utiliza una mujer bien arreglada, se establecen colores, tamaos, se acomodan aspectos visuales, entre otras cosas. Se hace uso de sass, que es un compilador de css para crear un cdigo ms entendible y mejor estructurado. Utils Esta capa es visible para todos los archivos presentes en el frontend, en esta capa estn presente rutinas y datos comunes para distintas partes del frontend. Esta capa tiene la mismas intencin que la capa de Utils del backend, mejorar la mantenibilidad del sistema. Scripts Es la parte lgica del rea del frontend, aqu se realizan los clculos y procesamiento de datos introducidos por el usuario, as como los datos a mostrar al usuario. Esta es la capa que se comunica con el backend a travs de las llamadas REST. En esta capa podemos encontrar una divisin entre los archivos que posee, basados en la estructura que posee AngularJs para las distintas tareas ejecutadas en las vistas. Estos submodulos son los controllers (comunicacin directa con las vistas), los filters (usados para filtrar datos y validaciones de enrada y salida), los directives (usados para crear componentes especiales en el html), factories (funciones genricas que pueden ser inyectadas en los controladores, son clases singleton) y los services (usados para ordenar las llamadas REST de una mejor manera, y no distribuidas por todo el cdigo).
Componentes y servicios Para esta seccin, es necesario manejar el trmino librera de software, el cual se detalla a continuacin. Una librera de software est definida como un conjunto de implementaciones funcionales, codificadas en un lenguaje de programacin, que ofrece una interfaz bien definida para la funcionalidad que se invoca. En otras palabras, una librera es un software desarrollado por terceros que ofrece alguna funcionalidad P g i n a 8 | 24
especfica. Las libreras se enfocan en una sola funcionalidad, con el objetivo de brindar dicha funcionalidad de manera eficiente y eficaz. Dada esta explicacin, el uso de libreras simplifica el desarrollo de software, ya que algunas ofrecen interfaces de comunicacin con las distintas tecnologas en uso, y otras ofrecen rutinas ya creadas, con las que el programador puede hacer uso a travs de una llamada a dichas rutinas, en lugar de tener que generar mltiples lneas de cdigo para dicho objetivo. A continuacin se presenta una lista de libreras y tecnologas usadas en el proyecto, dando una descripcin de que realiza cada uno de los componentes. NodeJS NodeJs, es un entorno de programacin en la capa del servidor basado en el lenguaje de programacin Javascript, con I/O de datos en una arquitectura orientada a eventos. Fue creado con el enfoque de ser til en la creacin de programas de red altamente escalables, como por ejemplo, servidores web. Se usa en el backend del sistema. Node.js incorpora varios mdulos bsicos compilados en el propio binario, como por ejemplo el mdulo de red, que proporciona una capa para programacin de red asncrona y otros mdulos fundamentales, como por ejemplo Path, FileSystem, Buffer, Timers y el de propsito ms general Stream. Es posible utilizar mdulos desarrollados por terceros, ya sea como archivos ".node" precompilados, o como archivos en javascript plano. Los mdulos Javascript se implementan siguiendo la especificacin CommonJS para mdulos, utilizando una variable de exportacin para dar a estos scripts acceso a funciones y variables implementadas por los mdulos. Los mdulos de terceros pueden extender node.js o aadir un nivel de abstraccin, implementando varias utilidades middleware para utilizar en aplicaciones web, como por ejemplo los frameworks connect y express. EspressJS Espress.js es un framework de desarrollo de aplicaciones web minimalista y flexible para Node.js. Est inspirado en Sinatra, adems es robusto, rpido, flexible y muy simple. Entre otras caractersticas, ofrece Router de URL (Get, Post, Put), facilidades para motores de plantillas (Jade, EJS, JinJS), Middeleware via Connect y un buen test coverage. En general, ExpressJs monta el ambiente para la creacin de proyectos con NodeJS, adems de ayudar con la instalacin de dependencias y otras libreras tiles en el uso de NodeJS. Grunt Grunt.js es una librera JavaScript que nos permite configurar tareas automticas y as ahorrarnos tiempo en nuestro desarrollo y despliegue de aplicaciones webs. Con un simple fichero JS llamado Gruntfile, indicamos las tareas que queremos automatizar con un simple comando y las escribimos en l en formato JSON. Grunt posee diversos plugins para tareas especfica. Estas libreras nos permite vigilar cambios que se realicen en determinados directorios para as actuar y ejecutar la tarea que se desea, preprocesar hojas de estilo y convertirlo a CSS, minificar el CSS y ejecutar instrucciones por lnea de comandos respectivamente. P g i n a 9 | 24
Grunt ayuda con la estructura del proyecto, adems de que permite configurar un servidor donde se hacen deploy del sistema, minimizando los scripts y los archivos css, con el objetivo de tener un ambiente listo de produccin de una manera muy sencilla y a travs de comandos muy simples en consola. Se usa en el backend del sistema. Mongoose Mongoose proporciona una solucin en lnea recta, basada en esquemas para modelar los datos de aplicacin e incluye una funcin de conversin de tipos, validacin, generacin de consultas, ganchos de lgica de negocios y ms, todo esto para la base de datos de MongoDB. Mongoose es una librera de MongoDB que establece esquemas para los collections en la base de datos, ayuda a tener mayor control sobre lo que es permitido en un collection y que no. Maneja informacin de cada collection como cantidad de datos y el tipo de datos en cada uno de ellos. Se usa en el backend del sistema. Passport Passport es el intermediario de autentificacin para el Node. Est diseado para servir a un propsito singular, autenticar las sesiones. Al escribir mdulos, la encapsulacin es una prioridad a nivel de seguridad, y Passport ofrece esta funcionalidad a la aplicacin. Esta separacin de intereses mantiene un cdigo limpio y fcil de mantener. En las aplicaciones web modernas, la autenticacin se puede tomar una variedad de formas. Tradicionalmente, los usuarios se conectan al proporcionar un nombre de usuario y contrasea. Con el auge de las redes sociales, inicio de sesin nico mediante un proveedor OAuth como Facebook o Twitter se ha convertido en un mtodo de autenticacin popular. Servicios que exponen una API a menudo requieren credenciales basadas en token para proteger el acceso. Pasaporte reconoce que cada aplicacin tiene requisitos de autenticacin nicas. Los mecanismos de autenticacin, conocidas como estrategias, se empaquetan como mdulos individuales. Las aplicaciones pueden elegir qu estrategias emplean, sin crear dependencias innecesarias. Passport es usado en el backend del sistema para mantener las sesiones creadas entre frontend y backend. Estas sesiones brindan seguridad a la informacin del sistema, no permitiendo que usuarios annimos tenga acceso a la misma. Socket.io Socket.IO es una biblioteca JavaScript para aplicaciones web en tiempo real. Consta de dos partes, una biblioteca de cliente que se ejecuta en el navegador, y una biblioteca en el servidor para NodeJs. Ambos componentes tienen una API casi idntica. Socket.IO utiliza principalmente el protocolo WebSocket, pero si es necesario se repliegue en varios otros mtodos, tales como tomas de Adobe Flash, JSONP de votacin y AJAX sondeo largo, mientras que proporciona la misma interfaz. A pesar de que se puede utilizar simplemente como un contenedor para WebSocket, proporciona muchas ms caractersticas, incluyendo la radiodifusin a mltiples tomas de corriente, el almacenamiento de datos asociados con cada cliente, y asincrnica de entrada y salida. P g i n a 10 | 24
Esta librera es de gran ayuda con el chat usado en el sistema de COES, ya que mantiene la comunicacin entre los distintos equipos y sesiones en tiempo real. Se usa en el backend del sistema. Q Q promise es una librera de javascript que ayuda en el manejo de la sincronizacin de las promesas realizadas en dicho lenguaje. Permite el manejo de los promises tanto de manera sncrona como asncrona, as como la facilidad de ejecutar varios hilos no dependientes al mismo tiempo. Se usa tanto en el backend como en el frontend del sistema. Si una funcin no puede devolver un valor o lanzar una excepcin sin bloquear, puede devolver una promesa en su lugar. Una promesa es un objeto que representa el valor de retorno o de la excepcin lanzada que la funcin puede llegar a ofrecer. Una promesa tambin puede ser utilizada como un proxy para un objeto remoto para superar la latencia. AngularJS AngularJS es un framework de JavaScript de cdigo abierto, mantenido por Google, que ayuda con la gestin de lo que se conoce como aplicaciones de una sola pgina. Su objetivo es aumentar las aplicaciones basadas en navegador con capacidad de Modelo Vista Controlador (MVC), en un esfuerzo para hacer que el desarrollo y las pruebas sean ms fciles. La biblioteca lee en HTML que contiene atributos de las etiquetas personalizadas adicionales, entonces obedece a las directivas de los atributos personalizados, y une las piezas de entrada o salida de la pgina a un modelo representado por las variables estndar de JavaScript. Los valores de las variables de JavaScript se pueden configurar manualmente, o recuperados de los recursos JSON estticas o dinmicas. Angular es usado en el frontend del sistema, para generar las pantallas de la aplicacin de un modo dinmico y estilizado. Todas las pantallas de COES, as como las plantillas generadas hacen uso de AngularJS.
Pgina 11
Diseo de base de datos
P g i n a 12 | 24
Pgina 13
Plan de trabajo
El plan de trabajo del proyecto es la lnea de tiempo a seguir para el sistema en general. Se realiza una planeacin de duracin del proyecto de acuerdo a los requerimientos del sistema, realizando una lista de tareas a realizar y ordenndolas en orden de ejecucin, luego se asignan responsabilidades para cada una de las tareas y se calcula el tiempo que tomara el cumplir con dicha tarea. A travs de la suma de estos tiempos y el establecimiento del orden a ejecutar, se obtiene la fecha de finalizacin del proyecto. Para el proyecto de COES, el nico recurso asignado para el desarrollo del sistema es el practicante Josu Santamara, al cual se le asignaron las tareas de desarrollo del sistema, y realizando el clculo de dichas tareas con el Project Manager del proyecto (Rodrigo Nez), se estima que el mismo esta para finalizar el viernes 6 de junio. Segn la planeacin realizada y el trabajo desarrollado hasta el momento, el proyecto no ha sufrido de atrasos, por lo que se mantiene en pie la fecha de finalizacin del mismo. A continuacin se presenta el cronograma de las tareas y el progreso realizado hasta el momento a travs del siguiente enlace al archivo en Microsoft Project. Gantt.mpp
P g i n a 14 | 24
Anlisis de los riesgos
La administracin del riesgo es un mtodo formal y sistemtico de administracin que se concentra en la identificacin y control de reas o eventos que tienen el potencial para causar cambios no deseados. Es el proceso sistemtico de identificar, analizar y responder al riesgo de un proyecto. Incluye maximizar la probabilidad y consecuencias de eventos positivos y minimizar la probabilidad y consecuencias de eventos negativos. A continuacin se presentan los riesgos detectados para el proyecto de COES, as como su impacto y la probabilidad de que sucedan. Tambin se expone las estrategias a seguir para disminuir o evitar del todo la probabilidad del riesgo
Nombre Categora Posible causa Impac- to Probabi- lidad que ocurra Exposi- cin ante el riesgo Estrategia de evasin Estrategia de mitigacin Estrategia de contingencia No aceptacin final del proyecto Tecnolgico, personas El proyecto no cumple las expectativas 1 0,05 0,05 Entregables cada 15 das para que el cliente visualice e interacte con el sistema, y as pueda brindar sus crticas y posibles mejoras Reuniones va skype a diario con el cliente para explicarle el estado del proyecto Desarrollar un producto de calidad de acuerdo a lo requerido por el cliente No entender el funcionar del sistema Personas Los usuarios finales del sistema no comprenden como funciona 0,75 0,1 0,075 Anlisis de usabilidad realizado por Intelligent Sense Solicitar a los usuarios sus expectativas del nuevo sistema, y hacer que ellos colaboren en la construccin del diseo Apegarse a realizar lo establecido por la analista de usabilidad P g i n a 15 | 24
Informes de Avance
Informe de Avance #1
P g i n a 16 | 24
Informe de Avance #2
P g i n a 17 | 24
Informe de Avance #3
P g i n a 18 | 24
Informe de Avance #4
P g i n a 19 | 24
Informe de Avance #5
P g i n a 20 | 24
Informe de Avance #6
P g i n a 21 | 24
Informe de Avance #8 Datos generales
N Informe
08 Semana 21 Mar 25 Abr
Estado Resumen ejecutivo de este informe
Se realizaron correcciones en la navegabilidad del sistema con respecto a lo establecido por el cliente en las reuniones SCRUM. Se continuo con la implementacin del sistema de envos masivos de correos, realizndose la investigacin pertinente de la conexin con el servicio sendgrid para el envi de correos, adems de la definicin y desarrollo del algoritmo de seleccin de armado de los correos a enviar.
Fecha de inicio planificada 03/02/ 2014 Fecha de fin planificada 30/05/ 2014 Fecha de inicio real 03/02/ 2014 Fecha de fin real 30/05/ 2014 Avance planificado: 56% Avance real: 56% Diferencia de avance (Planificado - Real) 0%: Tareas de la semana Tareas planeadas
Correcciones en la navegabilidad de los mdulos desarrollados a la fecha. Investigacin de la interfaz con el servicio de envo de correos masivos usado por COES. Implementacin del algoritmo de seleccin de correos a enviar y la creacin de dichos correos.
Tareas realizadas
Correcciones en la navegabilidad de los mdulos desarrollados a la fecha. Investigacin de la interfaz con el servicio de envo de correos masivos usado por COES. Implementacin del algoritmo de seleccin de correos a enviar y la creacin de dichos correos.
Tareas pendientes Ninguna
Tareas del prximo periodo
Implementar la interfaz con el servicio de envo de correos masivos sendgrid. Otorgar una manera de que se puedan manejar varias plantillas para los distintos clientes de COES. P g i n a 22 | 24
Implementar proceso que ejecute algoritmo de creacin de los correos segn los horarios definidos.
Informe de Avance #9 Datos generales
N Informe
09 Semana 28 Abr 02 May
Estado Resumen ejecutivo de este informe
Se realizaron mejoramientos al sistema segn reuniones SCRUM con el encargado del proyecto, en este caso particular, se decidi cambiar la lgica del sistema con respecto al armado de los correos a enviar a los clientes de COES. Se decidi generar la informacin respecto al correo en el momento de guardar un artculo, que el sistema genera todas las tablas necesarias donde debera incluirse dicho artculo.
Fecha de inicio planificada 03/02/ 2014 Fecha de fin planificada 30/05/ 2014 Fecha de inicio real 03/02/ 2014 Fecha de fin real 30/05/ 2014 Avance planificado: 56% Avance real: 56% Diferencia de avance (Planificado - Real) 0%: Tareas de la semana Tareas planeadas
Implementar la interfaz con el servicio de envo de correos masivos sendgrid. Otorgar una manera de que se puedan manejar varias plantillas para los distintos clientes de COES. Implementar proceso que ejecute algoritmo de creacin de los correos segn los horarios definidos.
Tareas realizadas
Cambios respecto al algoritmo de seleccin de artculo a enviar. Generacin de hashtables en la base de datos de MongoDB para facilitar la bsqueda de dichos artculos. Implementacin de shortcuts con teclado en el mdulo de artculos.
P g i n a 23 | 24
Tareas pendientes
Implementar la interfaz con el servicio de envo de correos masivos sendgrid. Otorgar una manera de que se puedan manejar varias plantillas para los distintos clientes de COES. Implementar proceso que ejecute algoritmo de creacin de los correos segn los horarios definidos.
Tareas del prximo periodo
Implementar la interfaz con el servicio de envo de correos masivos sendgrid. Otorgar una manera de que se puedan manejar varias plantillas para los distintos clientes de COES. Implementar proceso que ejecute algoritmo de creacin de los correos segn los horarios definidos.
Informe de Avance #10 Datos generales N Informe 10 Semana 05 May 09 May Estado Resumen ejecutivo de este informe
Fecha de inicio planificada 03/02/ 2014 Fecha de fin planificada 06/06/ 2014 Fecha de inicio real 03/02/ 2014 Fecha de fin real 06/06/ 2014 Avance planificado: 65% Avance real: 65% Diferencia de avance (Planificado - Real) 0%: Tareas de la semana Tareas planeadas
Implementar la interfaz con el servicio de envo de correos masivos sendgrid. Otorgar una manera de que se puedan manejar varias plantillas para los distintos clientes de COES. Implementar proceso que ejecute algoritmo de creacin de los correos segn los horarios definidos.
Tareas realizadas
P g i n a 24 | 24
Se implement la interfaz que permite la comunicacin con el servicio de envo de correos masivos usado por la empresa COES, en este caso, el servicio sendgrid. Se crearon plantillas web por defecto para la estructura de los correos electrnicos a enviar a los clientes de COES, estas plantillas estn disponibles para ser modificadas por la empresa COES de ser necesario. Se cre el proceso que est leyendo los horarios de envo de correos y preparando dichos correos a enviar segn la hora actual, en esta tarea se realiz bastante lgica del sistema, para evitar la duplicidad de correos enviados a un cliente, y garantizarse que los artculos siempre le lleguen al cliente de COES.
Tareas pendientes
Ninguna
Tareas del prximo periodo
Crear el servicio para que el supervisor de COES autorice los envos de correos masivos segn el horario. Realizar mltiples pruebas al sistema de envo de correos realizado a la fecha, para garantizar que funcione correctamente.