II Informe Final - Josue Santamaria

Pgina 1
Instituto Tecnolgico de Costa Rica

Escuela de Ingeniera en Computacin

II Informe de la Prctica

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 #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


P g i n a 17 | 24


P g i n a 18 | 24


P g i n a 19 | 24


P g i n a 20 | 24


P g i n a 21 | 24

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.

Rojo: avance > 10%.
Amarillo: 5% <
avance < = 10%.
Verde: avance < =
5%.
Respons
able

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.

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.

Rojo: avance > 10%.
Amarillo: 5% <
avance < = 10%.
Verde: avance < =
5%.
Respons
able

Fecha de
inicio
planificada
03/02/
2014
Fecha de fin
planificada
30/05/ 2014
Fecha de
inicio real
03/02/
2014
Avance planificado:
56%
Avance real: 56%
Diferencia de
avance
0%:
Tareas de la semana
Tareas
planeadas


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


Tareas del
prximo
periodo


Datos generales
N
Informe
10 Semana 05 May 09 May Estado
Resumen
ejecutivo
de este
informe

Rojo: avance > 10%.
Amarillo: 5% <
avance < = 10%.
Verde: avance < =
5%.
Respons
able

Fecha de
inicio
planificada
03/02/
2014
Fecha de fin
planificada
06/06/ 2014
Fecha de
inicio real
03/02/
2014
Avance planificado:
65%
Avance real: 65%
Diferencia de
avance
0%:
Tareas de la semana
Tareas
planeadas


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.

II Informe Final - Josue Santamaria

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

II Informe Final - Josue Santamaria

Загружено:

Авторское право:

Доступные форматы

Pgina 1

Instituto Tecnolgico de Costa Rica

Вам также может понравиться