API PARA LA GENERACIÓN DE INTERFACES Y EVENTOS EN...

API PARA LA GENERACIÓN DE INTERFACES Y EVENTOS EN APLICACIONES DE

CORREO ELECTRÓNICO: MAILMANAGER.

LEIDY LORENA PULIDO MORALES

UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS

FACULTAD TECNOLÓGICA

TECNOLOGÍA EN SISTEMATIZACIÓN DE DATOS

BOGOTA D.C.

2018

2


CORREO ELECTRÓNICO.

LEIDY LORENA PULIDO MORALES

Trabajo de grado para optar por el título de “Tecnólogo en Sistematización de

Datos”

TUTOR

Ing. LUIS FELIPE WANUMEN

UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS

FACULTAD TECNOLÓGICA

TECNOLOGÍA EN SISTEMATIZACIÓN DE DATOS

BOGOTA D.C.

2018

3

Nota de aceptación

______________________________________________________

______________________________________________________

______________________________________________________

______________________________________________________

______________________________________________________

__________________________________________

Firma del Jurado

Msc. Norberto Novoa Torres

__________________________________________

Firma del Tutor

Ing. Luis Felipe Wanumen

4

Contenido LISTA DE TABLAS 7

LISTA DE ILUSTRACIONES 8

RESUMEN 9

ABSTRACT 10

INTRODUCCIÓN 11

1. FASE DE DEFINICIÓN, PLANEACIÓN Y ORGANIZACIÓN 12

1.1 TITULO 12

1.2 TEMÁTICA 12

1.3 PLANTEAMIENTO DEL PROBLEMA 12

1.3.1 Descripción 12

1.3.2 Formulación 13

1.4 ALCANCES – DELIMITACIONES 13

1.4.1 Alcances 13

1.4.2 Delimitaciones 14

1.4.2.1 Temporal 14

1.4.2.2 Técnica 14

1.5 OBJETIVOS 14

1.5.1 General 14

1.5.2 Específicos 14

1.6 JUSTIFICACIÓN 15

1.7 MARCO DE REFERENCIA 15

1.7.1 Estado del arte 15

1.7.1.1 Proyectos relacionados 15

1.7.1.1.1 Servicio de envío de correos electrónicos 15

1.7.2 Marco Teórico 19

1.7.2.1 Aplicación web 19

1.7.2.2 Servidor Web 20

1.7.2.3 hMailServer 20

1.7.2.4 HTML 21

1.7.2.5 CSS 21

1.7.2.6 JavaScript 22

1.7.2.7 Framework 22

5

1.7.2.8 API Rest 23

1.7.2.9 Maven 24

1.7.2.10 Base de datos 24

1.7.2.11 SGBD (Sistema Gestor de Bases de Datos) 25

1.7.2.12 PostgreSQL 26

1.8 MARCO METODOLÓGICO 27

1.8.1 SCRUM 27

1.8.1.1 El proceso 27

1.8.1.2 Planificación de la iteración 28

1.8.1.3 Ejecución de la iteración 28

1.8.1.4 Inspección y adaptación 29

1.9 FACTIBILIDAD 30

1.9.1 Económica y Técnica 30

1.9.2 Legal 32

2. FASE DE ANALISIS 33

2.1 Incertidumbre 33

2.1.1 Requerimientos informales 33

2.2 Descripción de las funcionalidades 34

3. HISTORIAS DE USUARIO 35

4. DEFINICIÓN Y PRIORIZACIÓN DEL PRODUCT BACKLOG 43

4.1 Creación del Product Backlog 43

4.2 Priorización del Product Backlog 43

4.3 Pila del Producto 43

5. SPRINT PLANNING 45

5.1 Sprint 1 45

5.2 Sprint 2 45

5.3 Sprint 3 45

6. SPRINT 1 48

6.1 Objetivos 48

6.2 Scrum Taskboard 48

6.3 Reunión de Revisión del Sprint 1 49

6.4 Cierre y entrega 49

7. SPRINT 2 50

6

7.1 Objetivos 50




8. SPRINT 3 52

8.1 Objetivos 52




9. FASE FINAL 54

10. CONCLUSIONES 55

11. BIBLIOGRAFÍA 56

7

LISTA DE TABLAS Tabla 1. Limitaciones técnicas. 14

Tabla 2. Factibilidad Económica - Recursos Humanos 31

Tabla 3. Factibilidad Económica - Recursos Técnicos 31

Tabla 4. Factibilidad Económica - Gastos Adicionales 32

Tabla 5. Total Proyecto 32

Tabla 6. Licencias de las herramientas de desarrollo 33

Tabla 7. Historias de Usuario 1 35

Tabla 8. Historia de Usuario 2 36












Tabla 20. Formato Product Backlog 43

Tabla 21. Priorización del Product Backlog 44

Tabla 22. Lista total de objetivos por Sprint 46

Tabla 23. Priorización del Product Backlog 48

Tabla 24. Backlog Sprint 1 48

Tabla 25. Scrum Taskboard Inicial – Sprint1 48

Tabla 26. Scrum Taskboard en Progreso – Sprint1 49

Tabla 27. Scrum Taskboard Terminado – Sprint1 49

Tabla 28. Backlog Sprint 2 50







8

LISTA DE ILUSTRACIONES

Ilustración 1. Proceso SCRUM. 30

Ilustración 2. Resultados de interfaces. 54

9

RESUMEN

El presente proyecto, se desarrolló con el objetivo principal de desarrollar una

herramienta API que permite automatizar la generación de código fuente necesario para

conectarse con servidores de correo y la programación de los eventos e interfaces

principales de correo electrónico, todo esto desde el móvil y en la web. Para lograr dicho

objetivo, se planteó, diseño y desarrollo un sistema en entorno web el cual cuenta con

los módulos de solicitud de información de protocolos e ubicación para realizar la

conexión con el servidor de correo hMailServer, solicitud de información de datos

necesarios para cada evento e interfaz.

La API se desarrolló sobre Java, haciendo uso de diferentes herramientas como el

framework Spark, PrimeFaces, Maven, JavaMailAPI, J-Interop, está basado en el patrón

de arquitectura de software REST y MVC (Modelo Vista Controlador), que separa la

lógica y los datos de la interfaz de usuario y permite una perfecta integración de proyectos

o servidores de correo.

Teniendo en cuenta las diferentes metodologías, el proyecto se realizó bajo la

metodología SCRUM la cual se pudo ajustar con facilidad al pequeño equipo de trabajo

y al corto tiempo del que se dispuso para el desarrollo de la solución.

Palabras clave: API, Web, Móvil, Java, Maven, hMailServer, SCRUM, JavaMailAPI, REST.

10

ABSTRACT

The present project was developed with the main objective of developing an API tool that

automates the generation of source code necessary to connect with mail servers and the

programming of main e-mail events and interfaces, all this from the mobile and in the

Web. To achieve this goal, a system was set up, designed and developed in a web

environment which has the information request modules of protocols and location to make

the connection to the mail server hMailServer, request information of necessary data for

each event and interface.

The API was developed on Java, making use of different tools such as the Spark

framework, PrimeFaces, Maven, JavaMailAPI, J-Interop, is based on the software

architecture pattern REST and MVC (Model View Controller), which separates logic and

the data of the user interface and allows a perfect integration of projects or mail servers.

Taking into account the different methodologies, the project was carried out under the

SCRUM methodology, which could be easily adjusted to the small work team and to the

short time available for the development of the solution.

Keywords: API, Web, Mobile, Java, Maven, hMailServer, SCRUM, JavaMailAPI, REST.

11

INTRODUCCIÓN

La presente tesis tuvo como objetivo desarrollar una herramienta API que permite él

envió de correo web y móvil, dejando la ardua tarea al prototipo para que el usuario

(programador) centre sus esfuerzos en el desarrollo de software no recurrente. Se hace

uso de todos los conocimientos y habilidades adquiridos durante el periodo de formación

tecnológica que se recibió en la misma.

Partiendo de lo anterior, se entró a analizar cuáles eran los procesos y desarrollos a los

que un programador hoy en día debe realizar en diferentes proyectos de trabajo,

encontrando que actualmente la mayoría de ellos como lo son eventos e interfaces de él

envió de correo se realizan de manera recurrente. A raíz de esto fue evidente encontrar

dificultades en el trabajo y en el desarrollo de optimas aplicaciones que estén

establecidas en un tiempo determinado.

Teniendo en cuenta la situación, se procedió a reunir la información de primera mano

para conocer, entender y establecer la posible solución que permitiera mejorar

drásticamente los procesos anteriormente descritos, llegando así a la conclusión de que

una herramienta API agilizaría el trabajo de los desarrolladores y permitiría contar con

datos fiables para su uso.

Siendo así, se propuso una solución API REST, una herramienta accesible y de fácil

manejo en la cual el usuario final (desarrollador) puede utilizar para cualquier proyecto

de correo electrónico. Todo esto bajo una estructura segura, en lo posible robusta y

escalable, ya que en un futuro se puede integrar más funcionalidades o más recursos a

la misma.

12

1. FASE DE DEFINICIÓN, PLANEACIÓN Y ORGANIZACIÓN

1.1 TITULO


CORREO ELECTRONICO.

1.2 TEMÁTICA

Desarrollar una herramienta API para automatizar el código necesario para conectarse con el servidor de correo y permitir él envió de correo electrónico, cuyo objetivo es la optimización del desarrollo de software tanto en espacios laborales como académicos, teniendo en cuenta los lineamientos de creación APIRest.

1.3 PLANTEAMIENTO DEL PROBLEMA

1.3.1 Descripción

El desarrollo de aplicaciones móviles y web en un comienzo no requería gran cantidad

de código fuente sin embargo hoy en día con las exigencias crecientes del mercado para

hacer aplicaciones que accedan a servidores de diversa índole y que permitan

conexiones usando tecnologías como los servicios web o descargas de contenido de

servidores streaming requieren herramientas con gran cantidad de código fuente que en

muchas ocasiones se puede parametrizar en un esquema lógico y que es factible

desarrollar por medio de un sistema que lo genere, permitiendo al usuario final

concentrarse más en los detalles de sistema o en el código no recurrente que en

generación de rutinas que se pueden realizar con una herramienta tipo asistente.

Actualmente existen diferentes APIS que contienen códigos extensos incorporando

diferentes funcionalidades y recursos extensos. No obstante, no siempre se utilizan todos

los recursos provocando una carga adicional en las aplicaciones. Muchas empresas de

desarrollo optan por comprar estas herramientas o en otro caso realizar el código

afectando la agilización y estimación optima que se debería tener en el campo de

desarrollo, por consiguiente, amplia el porcentaje de errores y la creación de código

innecesario.

El correo electrónico es una opción popular de comunicación. Este medio es rápido,

eficiente y sencillo de administrar; por ello es un medio que generalmente es integrado

en aplicaciones laborales u/o académicos. Existen diferentes eventos e interfaces en

cada una de las funcionalidades de este servicio de red, pero actualmente el servicio

13

más importante es él envió de correo puesto que es posible mandar todo tipo de

información.

La importancia de este medio de comunicación ha hecho crecer la necesidad de su

implementación y ejecución, se ha convertido en una dependencia en diferentes ámbitos.

Por ello se considera que el impacto de su uso afecta en los negocios empresariales y

personales.

En un marco de investigación es necesario profundizar en este planteamiento ya que la

creación de herramientas API debe ser más sencilla y puntual en cuanto a su

funcionamiento, logrando no solo un avance en el entorno de las aplicaciones, sino que

además será una gran estrategia de aplicación para personas que no tienen un alto grado

de conocimiento y experiencia desarrollando.

1.3.2 Formulación

¿Cómo diseñar y desarrollar una herramienta API que permita él envió de correo

electrónico que contribuya al desarrollo de aplicaciones móviles y web?

1.4 ALCANCES – DELIMITACIONES

1.4.1 Alcances

➢ La herramienta API estará conformado por dos módulos desarrollados para ser

manejados de forma intuitiva y lo más simples posibles, ayudando así a mejorar

el rendimiento y el manejo.

➢ El subsistema de escritura generara la lógica del subsistema de procesamiento

como archivo java o APK, así mismo si no es posible brindar esta opción, la

utilización de la API se realizará en la misma activándola con solo dos líneas de

código (importación e implementación)

➢ A nivel funcional, los diferentes subsistemas con los que contara la herramienta

API serán:

➢ Subsistema de solicitud de información del servidor de correo.

➢ Subsistema de procesamiento. ➢ Subsistema de escritura.

14

1.4.2 Delimitaciones

1.4.2.1 Temporal

El proyecto se realizó en un periodo de cuatro (5) meses, comprendidos desde el 20 de

noviembre de 2017 al 20 de marzo de 2018.

1.4.2.2 Técnica Tabla 1. Limitaciones técnicas.

Sistemas operativos Operable en todos

Plataforma de desarrollo NetBeans IDE 8.2

Lenguaje de Programación JAVA

Servidor de correo electrónico hMailServer

Motor base de datos PostgreSQL 9.6

1.5 OBJETIVOS

1.5.1 General

Desarrollar una herramienta API que permita automatizar la generación de código fuente

necesaria para interactuar o conectarse con servidor de correo desde la web o el móvil

y permitir el envió de correo electrónico. Con esto se pretende investigar si es posible la

conexión en el lado del servidor web necesario para comunicarse con servidores de

correo.

1.5.2 Específicos

➢ Construir un subsistema de solicitud e información del servidor de correo, en donde se captura la información que servirá de base para hacer la conexión con el servidor.

➢ Desarrollar un subsistema de procesamiento, el cual tiene toda la lógica de conexión con el servidor y genera el código fuente en lenguaje java que permite enviar correo electrónico.

15

➢ Implementar un subsistema de escritura que recogerá toda la lógica y localiza un

área en el disco duro para escribir en archivos con extensión java el código

generado.

➢ Implementar la API como una librería para su uso y ejecución si el anterior

subsistema no es posible de crear.

1.6 JUSTIFICACIÓN

El proyecto surge a raíz de la necesidad de brindar una herramienta que ayude al

desarrollo de aplicaciones web y móvil en el marco de envió de correo electrónico. En la

actualidad las empresas de desarrollo están en continuos cambios de desarrollo para el

crecimiento de sus negocios, siendo este uno de los motivos por el cual adquieren

diferentes estrategias para la elaboración de los proyectos.

De igual forma, la herramienta nace debido a que los costos en tiempo desarrollando

código recurrente son bastante altos, ya que tienen que personalizar cada uno de los

proyectos adecuadamente a los requerimientos del cliente. Por esto requiere solución,

ya que pueden usar el tiempo en procesos que requieran de más atención y tacto.

Por ello se propuso crear una API la cual permitirá autenticarse con el servidor

hMailServer (Protocolo SMTP) y realizar él envió de correo vía web o móvil. El servidor

está dotado de su propia base de datos creada en PostgreSQL en el cual se almacena

cambios que se realicen en el mismo, a su vez genera reportes de su funcionamiento

minuto a minuto lo cual ayuda a la creación de la herramienta.

En base a esto actualmente se propone que esta sea una estrategia para los

desarrolladores de software (emprendedores) o para las grandes empresas en Colombia

y en el mundo.

1.7 MARCO DE REFERENCIA

1.7.1 Estado del arte

1.7.1.1 Proyectos relacionados

1.7.1.1.1 Servicio de envío de correos electrónicos

16

Actualmente, en el mercado global se encuentran numerosas soluciones de software

referentes al email marketing, todas ellas con diferentes plataformas de desarrollo y

diferentes tecnologías. Sin embargo, todas estas soluciones tienen un antecedente muy

relacionado con los conceptos de API y envió de correo. Cada una de estas herramientas

ha sido diseñada con el fin de realizar envíos de correos electrónicos masivos.

Por lo tanto, después de haber realizado una búsqueda de diferentes soluciones que

cumplieran con las necesidades básicas y que sirvieran de guía para el proyecto se

decidió exponer las siguientes:

a. MAILJET1

Herramienta diseñada para enviar emails, la sólida infraestructura de entrega de Mailjet

permite que, cada mes, miles de millones de emails aterricen en las bandejas de

entradas. Ofrece un panel de control en tiempo real que facilita la navegación, el filtrado

y la resolución de problemas relativos a indicadores clave de rendimiento como

aperturas, clics, tasa de spam, tasa de cancelaciones de suscripción, entre otros.

Características:

➢ Wrappers, integración en un propio ecosistema. ➢ Trabaja diferentes lenguajes de programación, desde C# a JavaScript, pasando

por Ruby, Python, PHP, Java y Go. ➢ Soporte especializado API. ➢ Flujos de trabajo automatizados. ➢ A cada usuario hace entrega de claves API para la correcta integración con otros

proyectos. ➢ Email transaccional y de marketing.

b. MAILPRO2

Es una plataforma de emailing propiedad de la empresa suiza Saasco. MailPro ofrece

todas las funciones que una pequeña o mediana empresa necesitaría y su generador de

boletines automático. El objetivo del negocio es la entrega de correos electrónicos

utilizando los correos automáticos, principalmente ha sido creada para ver y exportar

archivos de correo electrónico de múltiples clientes basados en escritorio.

1 Mailjet. (2017). https://www.mailjet.com/. Recuperado el 19 de febrero de 2018, de

https://es.mailjet.com/email-api/

2 Mail Pro (2016). https://es.mailpro.com/. Recuperado el 19 de febrero de 2018, de

https://www.antevenio.com/blog/2017/04/los-mejores-software-para-envio-masivo-de-email/

17

MailPro ofrece un conjunto de características que lo hacen una de las mejores opciones

para enviar correos de forma eficiente.

Características:

➢ Programada para leer y mostrar el contenido del correo electrónico de 14 diferentes clientes de correo.

➢ Opción de búsqueda para seleccionar un correo electrónico en particular y los correos se pueden exportar en un formato diferente.

➢ Sistema operativo basado en Windows.

c. MDirector3 Es un software para envío masivo de email y especialista en delivery. Planifican desde

cero toda la estrategia de comunicación por email para que los envíos siempre entren en

bandeja de entrada. Dispone de las características que toda plataforma profesional de

email marketing debe incluir, como una serie de plantillas responsive para email

marketing y newsletter gratuitas. O un sistema de reporting en tiempo real con el que se

podrá conocer en todo momento como están funcionando multitud de elementos de

campañas o incluso la gestión automática de bajas y rebotes.

Características:

➢ Envíos automáticos. ➢ Comunicar por email y SMS marketing. ➢ Añadir una cookie a cada registro de la base de datos para hacer retargeting. ➢ Gestionar todos los canales de marketing digital en una sola herramienta.

d. Digitaleo4

Es un software para envio masivo de email que no necesita instalación y que no implica

ningún compromiso de duración del contrato ni de volumen en envio de campañas. Por

tanto, solo se factura el consumo real de cada canal que se utilice.

Características:

➢ Evaluaciones en tiempo real. ➢ Mejora continua.

➢ Servicio de atención al cliente. ➢ Asesoramiento personalizado. ➢ Copias de seguridad automáticas.

3 MDirector. (2015). https://www.mdirector.com/. Recuperado el 19 de febrero de 2018, de


4 Digitaleo. (2015). https://www.digitaleo.es/. Recuperado el 19 de febrero de 2018, de


18

➢ Integración de las reglas para cumplir con la protección de datos.

e. Mailchimp5

Mailchimp es el software para envio masivo de email más conocido en el mercado. Pero

tiene una gran carencia para determinados públicos: la plataforma y la atención al cliente

se realizan exclusivamente en inglés. Sin embargo, con este software para envio masivo

de correos electrónicos dispone de algunas características que ya son estándares.

Características:

➢ Diseño drag&drop que permite crear campañas de email marketing de manera

sencilla. ➢ Analíticas avanzadas para controlar campañas y hacer crecer un negocio. ➢ Conexión con las principales redes sociales. ➢ Automatización, herramientas para poder crear series de emails segmentadas

que se lanzan dependiendo del comportamiento de los usuarios.

En cuanto a lo referente a la generación de código, existen pocas alternativas en el

mercado actual que puedan ayudar a planificar, entre ellas encontramos:

f. Generador de código App Studio6

Herramienta para crear aplicaciones totalmente gratuitas y en línea con la que se puede

crear rápidamente aplicaciones de Windows y Windows Phone para publicar, comprobar

y compartir. Windows App Studio genera código fuente ya preparado para Visual Studio.

Características:

➢ Reportes ➢ Recordatorios de reservas ➢ Grupos de usuarios ➢ Limita y controla el uso de recursos con cuotas de uso ➢ Opcionalmente se puede configurar para aprobar la solicitud de reservas

5 Mailchimp. (2015). https://es.mailjet.com/feature/send-api/. Recuperado el 19 de febrero de 2018, de

https://es.mailjet.com/feature/send-api/ 6 Microsoft App Studio. (2014). https://appstudio.windows.com/es-esRecuperado el 19 de febrero de 2018, de

https://appstudio.windows.com/es-es

19

g. Generador de código java para código bytecode7 El código bytecode es un código que tiene la ventaja de ser ejecutado en variedad de plataformas y esto les da gran estabilidad a los sistemas. Sin embargo, la ejecución de código bytecode genera en las aplicaciones problemas de rendimiento en el sentido que, durante la ejecución, el código bytecode debe ser traducido a lenguaje de máquina. Por esta razón la herramienta se entrega como una opción tecnológica para aplicaciones que tienen código bytecode, de tal suerte que se pueda traducir este tipo de código en código nativo para una versión particular de java y de esta forma se acelere la ejecución cuando se ejecute el código generado. Requiere que se entregue como insumo de código. Esta es la diferencia con el generador propuesto, en el sentido que el generador de código java, que se plantea realizar no requiere que el usuario conozca los detalles de generación de código bytecode.

1.7.2 Marco Teórico

1.7.2.1 Aplicación web

En la Ingeniería de software se denomina aplicación web a aquellas aplicaciones que los

usuarios pueden utilizar accediendo a un Servidor web a través de Internet o de una

intranet mediante un navegador. En otras palabras, es una aplicación (Software) que se

codifica en un lenguaje soportado por los navegadores web en la que se confía la

ejecución al navegador.

Las aplicaciones web son populares debido a lo práctico del navegador web como cliente

ligero, a la independencia del Sistema operativo, así como a la facilidad para actualizar

y mantener aplicaciones web sin distribuir e instalar software a miles de usuarios

potenciales.

Es importante mencionar que una Página Web puede contener elementos que permiten

una comunicación activa entre el usuario y la información. Esto permite que el usuario

acceda a los datos de modo interactivo, gracias a que la página responderá a cada una

de sus acciones, como por ejemplo rellenar y enviar formularios, participar en juegos

diversos y acceder a gestores de base de datos de todo tipo8.

7 Bytecode. (2009). https://www.adictosaltrabajo.com/tutoriales/byte-code/. Recuperado el 19 de febrero de

2018, de https://www.adictosaltrabajo.com/tutoriales/byte-code/

8 Ecured. (2016). www.ecured.cu. Recuperado el 19 de febrero de 2018, de

https://www.ecured.cu/Aplicaci%C3%B3n_web

20

1.7.2.2 Servidor Web

Un servidor Web es un programa que utiliza el protocolo de transferencia de hiper texto,

HTTP (Hypertext Transfer Protocol), para servir los archivos que forman páginas Web a

los usuarios, en respuesta a sus solicitudes, que son reenviados por los clientes HTTP

de sus computadoras. Las computadoras y los dispositivos dedicados también pueden

denominarse servidores Web.

El proceso es un ejemplo del modelo cliente/servidor. Todos los equipos que alojan sitios

Web deben tener programas de servidor Web. Los principales servidores Web incluyen

Apache (el servidor Web más ampliamente instalado), Internet Information Server (IIS)

de Microsoft y nginx (que se pronuncia engine X) de NGNIX. Otros servidores Web

incluyen el servidor NetWare de Novell, el servidor Web de Google (GWS) y la familia de

servidores Domino de IBM.

Los servidores Web a menudo forman parte de un paquete más amplio de programas

relacionados con internet e intranet para servir correo electrónico, descargar solicitudes

de archivos de protocolo de transferencia de archivos (FTP) y crear y publicar páginas

Web. Las consideraciones al elegir un servidor Web incluyen cuán bien funciona con el

sistema operativo y otros servidores, su capacidad para manejar la programación del

servidor, las características de seguridad y las herramientas particulares de publicación,

motor de búsqueda y creación de sitios que vienen con él9.

1.7.2.3 hMailServer

hMailServer es un servidor de correo electrónico gratuito y de código abierto para

Microsoft Windows. Es utilizado por proveedores de servicios de Internet, empresas,

gobiernos, escuelas y entusiastas en todas partes del mundo.

Es compatible con los protocolos comunes de correo electrónico (IMAP, SMTP y POP3)

y se puede integrar fácilmente con muchos sistemas de correo web existentes. Tiene

una protección flexible de spam basada en puntajes y se puede conectar a su escáner

de virus para escanear todo el correo electrónico entrante y saliente.

hMailServer viene con una biblioteca COM que se puede usar para la integración con

otro software. Usando la biblioteca COM, es posible escribir scripts y aplicaciones

completas que utilicen las funciones en hMailServer. Por ejemplo, puede integrar

hMailServer en sus sistemas de TI actuales para que los nuevos empleados obtengan

automáticamente cuentas de correo electrónico. Tanto el administrador de hMailServer

9 Rouse, M. (diciembre de 2016). http://searchdatacenter.techtarget.com. Recuperado el 19 de febrero de 2018, de http://searchdatacenter.techtarget.com/es/definicion/Servidor-Web

http://searchdatacenter.techtarget.com/es/definicion/Servidor-Web

21

como el frontend PHP basado en la web utilizan la API COM para administrar el

servidor10.

1.7.2.4 HTML

HTML significa "Lenguaje de Marcado de Hypertexto" por sus siglas en inglés "HyperText

Markup Language", es un lenguaje que pertenece a la familia de los "lenguajes de

marcado" y es utilizado para la elaboración de páginas web. El estándar HTML lo define

la W3C (World Wide Web Consortium) y actualmente HTML se encuentra en su versión

HTML5.

Cabe destacar que HTML no es un lenguaje de programación ya que no cuenta con

funciones aritméticas, variables o estructuras de control propias de los lenguajes de

programación, por lo que HTML genera únicamente páginas web estáticas, sin embargo,

HTML se puede usar en conjunto con diversos lenguajes de programación para la

creación de páginas web dinámicas.

Básicamente el lenguaje HTML sirve para describir la estructura básica de una página y

organizar la forma en que se mostrará su contenido, además de que HTML permite incluir

enlaces (links) hacia otras páginas o documentos.

HTML es un lenguaje de marcado descriptivo que se escribe en forma de etiquetas para

definir la estructura de una página web y su contenido como texto, imágenes, entre otros,

de modo que HTML es el encargado de describir (hasta cierto punto) la apariencia que

tendrá la página web11.

1.7.2.5 CSS

CSS es un lenguaje de hojas de estilos creado para controlar el aspecto o presentación

de los documentos electrónicos definidos con HTML y XHTML. CSS es la mejor forma

de separar los contenidos y su presentación y es imprescindible para crear páginas web

complejas.

Separar la definición de los contenidos y la definición de su aspecto presenta numerosas

ventajas, ya que obliga a crear documentos HTML/XHTML bien definidos y con

significado completo (también llamados "documentos semánticos"). Además, mejora la

10 Alvares, M. A. (mayo de 2017). https://www.hmailserver.com. Recuperado el 19 de febrero de 2018, de

https://www.hmailserver.com/functionality 11 www.acercadehtml.com. (2015). http://www.acercadehtml.com. Recuperado el 19 de febrero de 2018, de

http://www.acercadehtml.com/manual-html/que-es-html.html

22

accesibilidad del documento, reduce la complejidad de su mantenimiento y permite

visualizar el mismo documento en infinidad de dispositivos diferentes.

Al crear una página web, se utiliza en primer lugar el lenguaje HTML/XHTML para marcar

los contenidos, es decir, para designar la función de cada elemento dentro de la página:

párrafo, titular, texto destacado, tabla, lista de elementos, etc.

Una vez creados los contenidos, se utiliza el lenguaje CSS para definir el aspecto de

cada elemento: color, tamaño y tipo de letra del texto, separación horizontal y vertical

entre elementos, posición de cada elemento dentro de la página, etc12.

1.7.2.6 JavaScript

JavaScript es un lenguaje de programación que se utiliza principalmente para crear

páginas web dinámicas.

Una página web dinámica es aquella que incorpora efectos como texto que aparece y

desaparece, animaciones, acciones que se activan al pulsar botones y ventanas con

mensajes de aviso al usuario.

Técnicamente, JavaScript es un lenguaje de programación interpretado, por lo que no es

necesario compilar los programas para ejecutarlos. En otras palabras, los programas

escritos con JavaScript se pueden probar directamente en cualquier navegador sin

necesidad de procesos intermedios.

A pesar de su nombre, JavaScript no guarda ninguna relación directa con el lenguaje de

programación Java. Legalmente, JavaScript es una marca registrada de la empresa Sun

Microsystems, como se puede ver en http://www.sun.com/suntrademarks/13.

1.7.2.7 Framework

El concepto framework se emplea en muchos ámbitos del desarrollo de sistemas

software, no solo en el ámbito de aplicaciones Web. Podemos encontrar frameworks para

el desarrollo de aplicaciones médicas, de visión por computador, para el desarrollo de

juegos, y para cualquier ámbito que pueda ocurrírsenos.

12 librosweb.es. (2015). http://librosweb.es. Recuperado el 19 de febrero de 2018, de

http://librosweb.es/libro/css/capitulo_1.html

13 librosweb.es. (2013). http://librosweb.es. Recuperado el 19 de febrero de 2018, de

http://librosweb.es/libro/javascript/capitulo_1.html

23

En general, con el término framework, nos estamos refiriendo a una estructura software

compuesta de componentes personalizables e intercambiables para el desarrollo de una

aplicación. En otras palabras, un framework se puede considerar como una aplicación

genérica incompleta y configurable a la que podemos añadirle las últimas piezas para

construir una aplicación concreta.

Los objetivos principales que persigue un framework son: acelerar el proceso de

desarrollo, reutilizar código ya existente y promover buenas prácticas de desarrollo como

el uso de patrones.

Un framework Web, por tanto, podemos definirlo como un conjunto de componentes (por

ejemplo, clases en java y descriptores y archivos de configuración en XML) que

componen un diseño reutilizable que facilita y agiliza el desarrollo de sistemas Web14.

1.7.2.8 API Rest

REST cambió por completo la ingeniería de software a partir del 2000. Este nuevo

enfoque de desarrollo de proyectos y servicios web fue definido por Roy Fielding, el

padre de la especificación HTTP y uno los referentes internacionales en todo lo

relacionado con la Arquitectura de Redes, en su disertación ‘Architectural Styles and the

Design of Network-based Software Architectures’. En el campo de las APIs, REST

(Representational State Transfer- Transferencia de Estado Representacional) es, a día

de hoy, el alfa y omega del desarrollo de servicios de aplicaciones.

En la actualidad no existe proyecto o aplicación que no disponga de una API REST para

la creación de servicios profesionales a partir de ese software. Twitter, YouTube, los

sistemas de identificación con Facebook… hay cientos de empresas que generan

negocio gracias a REST y las APIs REST. Sin ellas, todo el crecimiento en horizontal

sería prácticamente imposible. Esto es así porque REST es el estándar más lógico,

eficiente y habitual en la creación de APIs para servicios de Internet.

Buscando una definición sencilla, REST es cualquier interfaz entre sistemas que use

HTTP para obtener datos o generar operaciones sobre esos datos en todos los formatos

posibles, como XML y JSON. Es una alternativa en auge a otros protocolos estándar de

intercambio de datos como SOAP (Simple Object Access Protocol), que disponen de una

gran capacidad, pero también mucha complejidad. A veces es preferible una solución

más sencilla de manipulación de datos como REST15.

14 Gutiérrez, J. J. (2014). http://www.lsi.us.es. Recuperado el 19 de febrero de 2018, de

http://www.lsi.us.es/~javierj/investigacion_ficheros/Framework.pdf

15 Acedo, J. (04 de mayo de 2015). http://programacion.jias.es. Recuperado el 19 de febrero de 2018, de

https://bbvaopen4u.com/es/actualidad/api-rest-que-es-y-cuales-son-sus-ventajas

http://roy.gbiv.com/

http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm



https://es.wikipedia.org/wiki/Representational_State_Transfer

24

1.7.2.9 Maven

Maven es un framework de administración de proyectos; en otras palabras, una

herramienta que automatiza el proceso de construcción de un proyecto Java.

Provee un conjunto de estándares de construcción, un modelo de repositorio de

artefactos y un motor de software que administra y describe los proyectos. Por ejemplo,

teniendo en cuenta la naturaleza interdependiente de proyectos open source, Maven

permite normalizar ubicaciones para los archivos fuente, documentación y archivos

binarios, para proveer una plantilla común para la documentación de proyecto y

recuperar dependencias de proyecto de un repositorio compartido, de tal forma que el

proceso de construcción consume menos tiempo y es mucho más transparente.

Maven se utiliza en la gestión y construcción de software. Posee la capacidad de realizar

ciertas tareas claramente definidas, como la compilación del código y su empaquetado.

Es decir, hace posible la creación de software con dependencias incluidas dentro de la

estructura del JAR. Es necesario definir todas las dependencias del proyecto (librerías

externas utilizadas) en un fichero propio de todo proyecto Maven, el POM (Project Object

Model). Este es un archivo en formato XML que contiene todo lo necesario para que a la

hora de generar el fichero ejecutable de nuestra aplicación este contenga todo lo que

necesita para su ejecución en su interior.

Sin embargo, la característica más importante de Maven es su capacidad de trabajar en

red. Cuando definimos las dependencias de Maven, este sistema se encargará de ubicar

las librerías que deseamos utilizar en Maven Central, el cual es un repositorio que

contiene cientos de librerías constantemente actualizadas por sus creadores. Maven

permite incluso buscar versiones más recientes o más antiguas de un código dado y

agregarlas a nuestro proyecto. Todo se hará de forma automática sin que el usuario

tenga que hacer nada más que definir las dependencias16.

1.7.2.10 Base de datos

El término de bases de datos fue escuchado por primera vez en 1963, en un simposio

celebrado en California, USA. Una base de datos se puede definir como un conjunto de

información relacionada que se encuentra agrupada o estructurada.

Desde el punto de vista informático, la base de datos es un sistema formado por un

conjunto de datos almacenados en discos que permiten el acceso directo a ellos y un

conjunto de programas que manipulen ese conjunto de datos.

16 Ardissone, J. (15 de febrero de 2012). www.maestrosdelweb.com. Recuperado el 19 de febrero de 2018, de

http://www.chuidiang.org/java/herramientas/maven.php

25

Cada base de datos se compone de una o más tablas que guarda un conjunto de datos.

Cada tabla tiene una o más columnas y filas. Las columnas guardan una parte de la

información sobre cada elemento que queramos guardar en la tabla, cada fila de la tabla

conforma un registro17.

Características:

Entre las principales características de los sistemas de base de datos podemos

mencionar:

➢ Independencia lógica y física de los datos. ➢ Redundancia mínima.

➢ Acceso concurrente por parte de múltiples usuarios.

➢ Integridad de los datos.

➢ Consultas complejas optimizadas. ➢ Seguridad de acceso y auditoría.

➢ Respaldo y recuperación. ➢ Acceso a través de lenguajes de programación estándar.

1.7.2.11 SGBD (Sistema Gestor de Bases de Datos)

Un Sistema Gestor de Base de Datos (SGBD, en inglés DBMS: DataBase Management

System) es un sistema de software que permite la definición de bases de datos; así como

la elección de las estructuras de datos necesarios para el almacenamiento y búsqueda

de los datos, ya sea de forma interactiva o a través de un lenguaje de programación. Un

SGBD relacional es un modelo de datos que facilita a los usuarios describir los datos que

serán almacenados en la base de datos junto con un grupo de operaciones para manejar

los datos.

Los SGBD relacionales son una herramienta efectiva que permite a varios usuarios

acceder a los datos al mismo tiempo. Brindan facilidades eficientes y un grupo de

funciones con el objetivo de garantizar la confidencialidad, la calidad, la seguridad y la

integridad de los datos que contienen, así como un acceso fácil y eficiente a los mismos18.

17 Valdés, D. P. (26 de octubre de 2007). www.maestrosdelweb.com. Recuperado el 20 de febrero de 2018, de

http://www.maestrosdelweb.com/que-son-las-bases-de-datos/

18 EcuRed. (2017). https://www.ecured.cu. Recuperado el 20 de febrero de 2018, de

https://www.ecured.cu/Sistema_Gestor_de_Base_de_Datos

26

1.7.2.12 PostgreSQL

PostgreSQL es una de las opciones más interesantes en bases de datos relacionales

open-source. Michael Stonebraker inició el proyecto bajo el nombre Post Ingres a

mediados de los 80’s con la idea de solucionar problemas existentes en las bases de

datos en esa época. MySQL fue por mucho tiempo el motor más popular; pero hoy es

propiedad de Oracle y esto limita su evolución.

Es gratuito y libre, además de que hoy nos ofrece una gran cantidad de opciones

avanzadas. De hecho, es considerado el motor de base de datos más avanzado en la

actualidad. (Y Platzi tiene un Curso de PostgreSQL)

Una característica interesante de PostgreSQL es el control de concurrencias

multiversión; o MVCC por sus siglas en inglés. Este método agrega una imagen del

estado de la base de datos a cada transacción. Esto nos permite hacer transacciones

eventualmente consistentes, ofreciéndonos grandes ventajas en el rendimiento.

En Postgres no se requiere usar bloqueos de lectura al realizar una transacción lo que

nos brinda una mayor escalabilidad. También PostgreSQL tiene Hot-Standby. Este

permite que los clientes hagan búsquedas (sólo de lectura) en los servidores mientras

están en modo de recuperación o espera. Así podemos hacer tareas de mantenimiento

o recuperación sin bloquear completamente el sistema.

PostgreSQL aporta mucha flexibilidad a nuestros proyectos. Por ejemplo, nos

permite definir funciones personalizadas por medio de varios lenguajes. Algunos son:

➢ PL/pgSQL

➢ PL/Tcl

➢ PL/Perl

➢ PL/Python

➢ PL/PHP

➢ PL/Ruby

➢ PL/Java

Otra ventaja de PostgreSQL es que está disponible para muchas plataformas y ofrece

el código fuente desde el sitio oficial. Algunos de los builds oficiales son:

➢ Mac OS X

➢ Windows

➢ Solaris

➢ Red Hat

➢ Debian

➢ Ubuntu

http://www.postgresql.org/

https://en.wikipedia.org/wiki/Michael_Stonebraker

https://platzi.com/cursos/postgresql/

http://www.postgresql.org/docs/9.0/static/hot-standby.html

http://git.postgresql.org/gitweb/?p=postgresql.git;a=summary

http://www.postgresql.org/download/macosx/

http://www.postgresql.org/download/windows/

http://www.postgresql.org/download/solaris/

http://www.postgresql.org/download/linux/redhat/

http://www.postgresql.org/download/linux/debian/

http://www.postgresql.org/download/linux/ubuntu/

27

pgAdmin es la herramienta oficial para administrar nuestras bases de datos en

PostgreSQL19. Nos permite desde hacer búsquedas SQL hasta desarrollar toda nuestra

base de datos de forma muy fácil e intuitiva; directamente desde la interfaz gráfica.

1.8 MARCO METODOLÓGICO

1.8.1 SCRUM20

Scrum es un proceso en el que se aplican de manera regular un conjunto de buenas

prácticas para trabajar colaborativamente, en equipo, y obtener el mejor resultado posible

de un proyecto. Estas prácticas se apoyan unas a otras y su selección tiene origen en un

estudio de la manera de trabajar de equipos altamente productivos.

En Scrum se realizan entregas parciales y regulares del producto final, priorizadas por el

beneficio que aportan al receptor del proyecto. Por ello, Scrum está especialmente

indicado para proyectos en entornos complejos, donde se necesita obtener resultados

pronto, donde los requisitos son cambiantes o poco definidos, donde la innovación, la

competitividad, la flexibilidad y la productividad son fundamentales.

Scrum también se utiliza para resolver situaciones en que no se está entregando al

cliente lo que necesita, cuando las entregas se alargan demasiado, los costes se

disparan o la calidad no es aceptable, cuando se necesita capacidad de reacción ante la

competencia, cuando la moral de los equipos es baja y la rotación alta, cuando es

necesario identificar y solucionar ineficiencias sistemáticamente o cuando se quiere

trabajar utilizando un proceso especializado en el desarrollo de producto.

1.8.1.1 El proceso21

En Scrum un proyecto se ejecuta en bloques temporales cortos y fijos (iteraciones que

normalmente son de 2 semanas, aunque en algunos equipos son de 3 y hasta 4

semanas, límite máximo de feedback y reflexión). Cada iteración tiene que proporcionar

un resultado completo, un incremento de producto final que sea susceptible de ser

entregado con el mínimo esfuerzo al cliente cuando lo solicite.

19 Rouse, M. (enero de 2015). http://searchdatacenter.techtarget.com. Recuperado el 20 de febrero de 2018, de

https://platzi.com/blog/que-es-postgresql/

20 proyectosagiles.org. (2015). https://proyectosagiles.org. Recuperado el 20 de febrero de 2018, de

https://proyectosagiles.org/que-es-scrum/ 21 Ibíd.

http://www.pgadmin.org/

28

El proceso parte de la lista de objetivos/requisitos priorizada del producto, que actúa

como plan del proyecto. En esta lista el cliente prioriza los objetivos balanceando el valor

que le aportan respecto a su coste y quedan repartidos en iteraciones y entregas.

Las actividades que se llevan a cabo en Scrum son las siguientes:

1.8.1.2 Planificación de la iteración

El primer día de la iteración se realiza la reunión de planificación de la iteración. Tiene

dos partes:

➢ Selección de requisitos (4 horas máximo). El cliente presenta al equipo la lista de

requisitos priorizada del producto o proyecto. El equipo pregunta al cliente las

dudas que surgen y selecciona los requisitos más prioritarios que se compromete

a completar en la iteración, de manera que puedan ser entregados si el cliente lo

solicita.

➢ Planificación de la iteración (4 horas máximo). El equipo elabora la lista de tareas

de la iteración necesarias para desarrollar los requisitos a que se ha

comprometido. La estimación de esfuerzo se hace de manera conjunta y los

miembros del equipo se auto asignan las tareas.

1.8.1.3 Ejecución de la iteración

Cada día el equipo realiza una reunión de sincronización (15 minutos máximos). Cada

miembro del equipo inspecciona el trabajo que el resto está realizando (dependencias

entre tareas, progreso hacia el objetivo de la iteración, obstáculos que pueden impedir

este objetivo) para poder hacer las adaptaciones necesarias que permitan cumplir con el

compromiso adquirido. En la reunión cada miembro del equipo responde a tres

preguntas:

¿Qué he hecho desde la última reunión de sincronización?

¿Qué voy a hacer a partir de este momento?

¿Qué impedimentos tengo o voy a tener?

Durante la iteración el Facilitador (Scrum Master) se encarga de que el equipo pueda

cumplir con su compromiso y de que no se merme su productividad.

Elimina los obstáculos que el equipo no puede resolver por sí mismo.

Protege al equipo de interrupciones externas que puedan afectar su compromiso o su

productividad.

Durante la iteración, el cliente junto con el equipo refina la lista de requisitos (para

prepararlos para las siguientes iteraciones) y, si es necesario, cambian o replanifican los

29

objetivos del proyecto para maximizar la utilidad de lo que se desarrolla y el retorno de

inversión.

1.8.1.4 Inspección y adaptación

El último día de la iteración se realiza la reunión de revisión de la iteración. Tiene dos

partes:

➢ Demostración (4 horas máximo). El equipo presenta al cliente los requisitos

completados en la iteración, en forma de incremento de producto preparado para

ser entregado con el mínimo esfuerzo. En función de los resultados mostrados y

de los cambios que haya habido en el contexto del proyecto, el cliente realiza las

adaptaciones necesarias de manera objetiva, ya desde la primera iteración,

replanificando el proyecto.

➢ Retrospectiva (4 horas máximo). El equipo analiza cómo ha sido su manera de

trabajar y cuáles son los problemas que podrían impedirle progresar

adecuadamente, mejorando de manera continua su productividad. El Facilitador

se encargará de ir eliminando los obstáculos identificados22.

22 proyectosagiles.org. (2015). https://proyectosagiles.org. Recuperado el 20 de febrero de 2018, de

https://proyectosagiles.org/que-es-scrum/

30

Ilustración 1. Proceso SCRUM. Fuente: https://proyectosagiles.org/que-es-scrum/

1.9 FACTIBILIDAD

1.9.1 Económica y Técnica

La factibilidad económica del proyecto es la siguiente: en términos financieros se

necesitarán un equipo de cómputo, asesorías del tutor del proyecto, acceso a Internet,

paquete office y artículos de papelería para realizar el modelado del proyecto.

En las tablas que se presentaran a continuación se describe la factibilidad económica,

identificando los costos de papelería, hardware, software y recursos humanos necesarios

para la realización del proyecto.

Se dividió en tres aspectos, recursos humanos, recursos técnicos y otros recursos, la

distinción de los recursos humanos se presenta a continuación:


31

Tabla 2. Factibilidad Económica - Recursos Humanos

Tipo Descripción Valor-Hora

Cantidad Total Asumido por

Tutor (1)

Asesorías para la realización del

proyecto, referente a la metodología.

$ 60.000 Aproximadamente

40 horas $ 2.400.000 Universidad

Desarrolladores (1)

Dos programadores que realicen el desarrollo de la

solución.

$ 30.000 Aproximadamente

240 horas C/U $ 7.200.000

Estudiantes desarrolladores

del proyecto

Total Recursos Humanos $ 16.800.000

A continuación, se presentan los gastos en recursos técnicos que se ostentaron

durante el desarrollo del proyecto.

Tabla 3. Factibilidad Económica - Recursos Técnicos

cantidad Recurso Descripción Valor

Unitario Total

1 Equipo de computo

Computador de mesa con

procesador AMD doble núcleo,

8gb de memoria RAM, disco

duro de 500gb, monitor red de

19" y periféricos básicos.

Propiedad de uno de los

programadores.

$800,000 $800,000

Total Recursos Técnicos $800,000

Total recursos Técnicos asumidos por los estudiantes $700,000

Total recursos Técnicos asumidos por la Universidad $100,000

En la siguiente tabla se muestran los gastos adicionales que serán solventados por los

desarrolladores del proyecto.

32

Tabla 4. Factibilidad Económica - Gastos Adicionales

Cantidad Recurso Descripción Valor Total

1 Internet Internet banda ancha de 20 megas proveído en

la casa de uno de los desarrolladores (5 meses) $520,000

2 Papel Resmas de papel tamaño carta $18,000

Servicio

Energía

Eléctrica

Servicio de energía eléctrica consumido en las

viviendas de los dos desarrolladores $240,000

Otros

conceptos

Licencia Windows, Paquete Office, DVD,

memorias USB, fotocopias, impresiones,

muebles de oficina

$805,000

Costos

Imprevistos %10 del valor total de los gastos adicionales $182,300

Total Gastos adicionales asumidos totalmente por los estudiantes

desarrolladores del proyecto $1,765,300

Como se puede ver en la Tabla 5 el costo aproximado del proyecto es de $19.365.300 y

es factible económicamente dado que se cuenta con todas las herramientas necesarias

para el desarrollo total del proyecto.

Tabla 5. Total Proyecto

Recursos Humanos $ 16.800.000

Recursos Técnicos $800,000

Gastos adicionales $1,765,300

Total $19.365.300

1.9.2 Legal

El proyecto es factible legalmente ya que la herramienta API que se desarrollo fue

implementado con herramientas libres y los recursos para la construcción de la solución

fueron personales.

En la siguiente tabla se resumen las licencias correspondientes a las herramientas de

desarrollo que se utilizaron en el proyecto:

33

Tabla 6. Licencias de las herramientas de desarrollo

Recurso Licencia

Windows EULA

NetBeans GNU

PostgreSQL GNU General Public License

Maven Apache 2.0

hMailServer CPOL 1.02

2. FASE DE ANALISIS

2.1 Incertidumbre

En la primera reunión con el tutor y con un desarrollador senior, se recogieron los

requerimientos principales que debían conformar la herramienta API, para así tener una

visión del producto final y darles prioridad a los aspectos más relevantes de este.

2.1.1 Requerimientos informales

Necesito una herramienta API desde el cual se pueda interactuar u conecta con él

servidor hMailServer, realizar el envio de correo electrónico dependiendo de los

requerimientos del desarrollador, es decir si desea ciertas funcionalidades del evento:

➢ Generar el código pertinente para la conexión con el servidor hMailServer

utilizando la biblioteca COM y J-Interop como puente COM.

➢ Permitir realizar la consulta sobre os eventos e interfaces que se requieren en el

envio de correo vía web o móvil.

➢ Ingresar en una base de datos todos los elementos que hacen parte del servidor,

donde se guardaran los cambios que se realizan en el (por ejemplo, dominio, rutas

y cuentas).

➢ Poder generar o hacer uso de la API dependiendo de los requerimientos del

usuario final (Web o Móvil).

➢ Construir la API de manera escalable que facilite su uso. ➢ Desarrollar la herramienta con la arquitectura MVC de tal forma que más adelante

se pueda contribuir a su construcción y correcta infusión con otros programas .

34

2.2 Descripción de las funcionalidades

Con los requerimientos informales obtenidos y en conjunto del grupo de trabajo y el tutor,

se entró a especificar mejor cada aspecto o funcionalidad de la herramienta, generando

así un cuadro completo de Historias de Usuario.

35

3. HISTORIAS DE USUARIO

Tabla 7. Historias de Usuario 1

Enunciado de la Historia Criterios de aceptación

Identificador (ID) de la historia

Rol Característica / Funcionalidad

Razón / Resultado

Número (#) de

Escenario

Criterio de aceptación

(Titulo) Contexto Evento

HU01 Usuario

Ingresar los datos de

información del servidor de

correo electrónico

(hMailServer)

Paso de parámetros

para la conexión de

la herramienta

con el servidor de

correo.

1 No ingreso el

dominio correctamente

En caso de que olvide el dominio o le falte algún a

letra

Cuando se dé clic a procesar la

información, como se aclaró en el

documento, la herramienta funcionara con la veracidad de los

datos.

2 No el puerto a

utilizar correctamente

En caso de que olvide el puerto o este

no esté habilitado


información, como se aclaró en el

documento, la herramienta funcionara con la veracidad de los

datos.

3 No ingreso el

user correctamente

En caso de que no digite bien u olvide el usuario de

acceso


información, la herramienta funcionara con la veracidad de los

datos.

36

Tabla 8. Historia de Usuario 2





Razón / Resultado

Número (#) de

Escenario



HU03 Usuario Username hMailServe

Permitir la conexión

con el servidor

1 No ingresa

correctamente el username

No ingresa el username

Administrador del Servidor

correctamente

No permite hacer la conexión con la administración del

servidor de correo.

2 No existe el

username en el servidor

No creo el username

Administrador

Debe crear en el dominio una cuenta administradora del

servidor de correo para permitir la conexión.




Razón / Resultado

Número (#) de

Escenario



HU01 Usuario

Autenticar usuario y

contraseña (SMTP)

Envió de correo

1 Olvido

contraseña de acceso

En caso de que olvide la

contraseña de acceso

Cuando se dé clic en procesar la información, la herramienta

no validara, pero si mostrara el error de envió.

2 Olvido

usuario de acceso

En caso de que olvide el

usuario de acceso


no validara, pero si mostrara el error de envió.

37





Razón / Resultado

Número (#) de

Escenario



HU04 Usuario Dominio y protocolos

Permitir el envió de correo

electrónico

1 El dominio

no sirve

Cuando el dominio no tiene DNS u

MX

Se debe verificar que el dominio existe y funciona

perfectamente.

2 El protocolo

no autentica

Cuando no configuran el

protocolo en el servidor

Se debe configurar el protocolo, verificando: el puerto, la ruta, el

dominio y la dirección IP.





Razón / Resultado

Número (#) de

Escenario



HU05 Usuario Seguridad servidor

Envió de correo

1 No

estableció seguridad

No estableció seguridad en el protocolo

(SMTP)

Si no se establece seguridad lo mas probable es que la

herramienta falle.

2 Estableció seguridad opcional

Estableció seguridad y

autenticación opcional

Se debe establecer seguridad aprobada para que el código

funcione.

38





Razon / Resultado

Número (#) de

Escenario



HU06 Usuario Puerto Autenticar protocolo

SMTP

1 Estableció puerto 25 o

587

En caso de que establezca el puerto 25 o

587

Cuando se dé proceso al envió de correo se establecerá la

conexión y el correcto funcionamiento de la

herramienta API.

2 Estableció un puerto diferente

En caso de que establezca

un puerto diferente

Cuando se establece otro puerto diferente no se podrá

trabajar, puesto que por regla del protocolo se debe trabajar

con estos dos.





Razon / Resultado

Número (#) de

Escenario



HU07 Usuario

Establecer el host en los txt

de host de Windows con el

dominio

Envió de correo

1 No define el host para el

dominio

En caso de que no defina el host en el archivo de Windows

Cuando se dé el proceso de conectar con el servidor no será

posible.

2

No define el host para el dominio de

manera correcta

En caso de que defina de

manera incorrecta el

host

Cuando se de el proceso de conectar con el servidor no será

posible.

39




Rol Característica

/ Funcionalidad

Razón / Resultado

Número (#) de

Escenario



HU08 Usuario Envió de

correo con adjunto

Uso expresión

regular

1

Uso de taglib estableciendo adjunto como

verdadero

Cuando se implemente el uso de la librería y se

llame al parámetro de adjunto como "true"

Cuando se de clic en procesar la información, la herramienta enviar correos

con adjuntos.

2

Uso de taglib estableciendo adjunto como

falso

Cuando se implemente el uso de la librería y se

llame al parámetro de adjunto

como "false"

Cuando se de clic en procesar la información, la herramienta enviar correos

sin adjuntos.

40




Rol Característica

/ Funcionalidad

Razón / Resultado

Número (#) de

Escenario



HU09 Usuario

Envió de correo con

plantilla diferente

Uso expresión

regular

1

Uso de taglib

plantilla como "true"

Cuando implemente el

uso de la librería y se

llame al parámetro de plantilla como

"true"

Cuando se de clic en procesar la información, la herramienta

enviar los correos con plantillas elegidas por el

usuario.

2

Uso de taglib

plantilla como "false"

Cuando implemente el

uso de la librería y se

llame al parámetro de plantilla como

"false"


enviar los correos con la plantilla predefinida.

41




Rol Característica

/ Funcionalidad

Razón / Resultado

Número (#) de

Escenario



HU10 Usuario APK Móvil Envió de correo

1 Establecer

el envió vía móvil

Podrá utilizarse

como una API


implementara el envió vía móvil utilizándola de modo

API.

2

Establecer taglib

envió vía móvil

Podrá utilizarse como una

librería


implementara el envió vía móvil utilizándola de modo

librería.




Rol Característica

/ Funcionalidad

Razón / Resultado

Número (#) de

Escenario



HU11 Usuario WEB Envió de correo

1 Establecer

el envió vía web

Podrá utilizarse

como una API

Cuando se dé clic en procesar la información, la herramienta implementara el envió vía web

utilizándola de modo API.

2

Establecer taglib

envió vía web

Podrá utilizarse como una

librería

Cuando se dé clic en procesar la información, la herramienta implementara el envió vía web utilizándola de modo librería.

42




Rol Característica

/ Funcionalidad

Razón / Resultado

Número (#) de

Escenario



HU12 Usuario TagLib Implementación envió de correo

1 Implementación

de Librería

En caso de que desea

implementar como

librería

Cuando se desee implementar como

librería, en el manual del usuario se podrá visualizar que en dos líneas de código se

puede utilizar la herramienta

permitiendo ver los procesos de esta.




Rol Característica

/ Funcionalidad

Razón / Resultado

Número (#) de

Escenario



HU13 Usuario API Implementación envió de correo

1 Implementación

de API

En caso de que desea

implementar como API

Cuando se desee implementar como

API, en el manual del usuario se podrá

visualizar integrar a demás proyectos y se

puede utilizar la herramienta.

43

4. DEFINICIÓN Y PRIORIZACIÓN DEL PRODUCT BACKLOG

4.1 Creación del Product Backlog

Para la creación del product backlog se utilizó el siguiente formato, el cual contendrá las

historias de usuario a las cuales se les asignará un alias, un estimado de

dimensión/esfuerzo (DIAS), la iteración a la cual pertenecerá y el grado de prioridad:

Tabla 20. Formato Product Backlog

4.2 Priorización del Product Backlog

La priorización del Product Backlog se basó en la clasificación de las historias de

usuario según su:

➢ Funcionalidad y complejidad

➢ Que fueran independientes de otras historias de usuario ➢ Que en conjunto permitirán la creación de un entregable para el laboratorio.

4.3 Pila del Producto

Identificador (ID) de la Historia

Enunciado de la Historia Alias Dimensión/

Esfuerzo Iteración (Sprint)

Prioridad

1 Como un (Rol), necesito (Funcionalidad), con

la finalidad de (Resultado)

2

3

4

5

6

7

44

Tabla 21. Priorización del Product Backlog


Enunciado de la Historia Encargado

1

Cuando se dé clic en procesar la información, la herramienta no validara, pero si mostrara el error

de envió.

Leidy Pulido

2

Cuando se dé clic a procesar la información, como se aclaró en el documento, la herramienta

funcionara con la veracidad de los datos.

Leidy Pulido

3

Debe crear en el dominio una cuenta administradora del servidor de correo para

permitir la conexión.

Leidy Pulido

4 Se debe configurar el protocolo, verificando: el

puerto, la ruta, el dominio y la dirección IP. Leidy Pulido

5 Se debe establecer seguridad aprobada para

que el código funcione. Leidy Pulido

6

Cuando se establece otro puerto diferente no se podrá trabajar, puesto que por regla del

protocolo se debe trabajar con estos dos.

Leidy Pulido

7 Cuando se dé el proceso de conectar con el

servidor no será posible. Leidy Pulido

8 Cuando se dé clic en procesar la información, la

herramienta enviar correos con adjuntos. Leidy Pulido

9

Cuando se dé clic en procesar la información, la herramienta enviar los correos con plantillas

elegidas por el usuario.

Leidy Pulido

10

Cuando se dé clic en procesar la información, la herramienta implementara el envió vía móvil

utilizándola de modo librería.

Leidy Pulido

11

Cuando se dé clic en procesar la información, la herramienta implementara el envió vía web

utilizándola de modo librería.

Leidy Pulido

12

Cuando se desee implementar como librería, en el manual del usuario se podrá visualizar que en

dos limas de código se puede utilizar la herramienta permitiendo ver los procesos de

esta.

Leidy Pulido

45

13

Cuando se desee implementar como API, en el manual del usuario se podrá visualizar integrar a

demás proyectos y se puede utilizar la herramienta.

Leidy Pulido

5. SPRINT PLANNING

En la reunión del Sprint Plan Ning se llegó a la conclusión de que se harían 3 Sprint para

desarrollar la herramienta API en su totalidad.

También se definieron las historias de usuario que compondrían cada Sprint y se calculó

un tiempo estimado de desarrollo para cada historia y su nivel de prioridad. Con esto se

calculó también el tiempo de duración de cada Sprint.

Finalmente se asigna como “terminada” una tarea cuando esté completamente funcional

y no dependa de otras para su normal funcionamiento.

5.1 Sprint 1

➢ Historias asignadas: Interfaz usuario final, configuración de puertos y dominio,

instalación de servidor y configuración de este, creación de interfaz y conexión

con el servidor.

➢ Tiempo estimado: 20 días

5.2 Sprint 2

➢ Historias asignadas: Conexión lógica con el servidor, creación de plantillas java,

creación de expresiones regulares, compilación de lógica, generación de código

fuente java.


5.3 Sprint 3

➢ Historias asignadas: Recoge toda la lógica del subsistema de procesamiento,

localización de un área en el disco, implementación de la Tagle.


46

Tabla 22. Lista total de objetivos por Sprint

Orden Sprint T/H Ítem Historia Asignado a

1 1 12 Crear diagramas

de análisis

Antes de iniciar el proceso se crea diagramas de clases para el análisis de la arquitectura y

construcción de la herramienta.

Leidy Pulido

2 1 10 Crear

requerimientos

Crear una lista de los requerimientos de la

herramienta, enumerados, priorizados y con descripción.

Leidy Pulido

3 1 8 Crear historias de

usuario

Se deben crear las historias de usuario para ver los procedimientos que realiza la API en cada caso y en cada evento.

Leidy Pulido

4 1 8 Crear diagramas

de diseño

Se deben crear los diagramas del diseño de la herramienta: Diagramas de clases para el

diseño de interfaces y un diagrama de estados para

saber los estados que puede proporcionar la herramienta.

Leidy Pulido

5 1 2 Instalación y

configuración de hMailServer

Se debe instalar el servidor y configurar dominios y la

biblioteca COM.

Leidy Pulido

6 1 2 Realizar conexión

con el Servidor

Se debe crear una clase en java para realizar la conexión con el servidor y la biblioteca COM y el

puente COM: J-Interop.

Leidy Pulido

7 1 2 Crear interfaz de

solicitud de información

Se crea la interfaz en la que se captura la información que

servirá de base para la conexión con el servidor.

Leidy Pulido

8 1 2 Conectar servidor

con la herramienta

Se crea la conexión con el servidor.

Leidy Pulido

9 1 1 Configurar

puertos y dominio Se deben configurar puertos y

el dominio, DNS, MX. Leidy Pulido

10 2 60 Creación de plantillas en código java

Se crean las plantillas que será de ayuda para la generación de código fuente en lenguaje java.

Leidy Pulido

47

11 2 60 Creación de expresiones

regulares

Se crea esta técnica como complementación de los usos de interfaces y eventos para él

envió de correo electrónico.

Leidy Pulido

12 2 65 Generación de código fuente

Se genera el código fuente a partir de la creación de TagLib.

Leidy Pulido

13 2 48 Creación de

librería TAGLIB

Creación de la TagLib para la implementación de la API como

librería.

Leidy Pulido

14 2 40

Creación de plantillas de

interfaces para utilizar

Se crea diferentes interfaces de fronted para que el usuario

utilice en diversidad.

Leidy Pulido

15 2 40 Creación de eventos para

utilizar

Se crea diferentes eventos de fronted para que el usuario

utilice en diversidad.

Leidy Pulido

16 3 50 Compilación de código fuente

Se recoge toda la lógica y se compila para el uso de la

herramienta.

Leidy Pulido

17 3 50 Uso de la TagLib

Con el uso de la TagLib el uso de la herramienta es más

eficiente puesto que con dos líneas de código se activa la

misma.

Leidy Pulido

18 3 50 Pruebas de desarrollo

Se realizan diferentes pruebas de desarrollo para hacer más

sencillo el uso de esta.

Leidy Pulido

19 3 4 Implementación

de servidor web y móvil

Se implementa con el servidor web y móvil.

Leidy Pulido

20 3 60 Complementar documentación

Se realiza la documentación de cada Sprint en el documento

final.

Leidy Pulido

48

6. SPRINT 1

Para este Sprint se atendieron las historias de usuario 2, 3, 4, 1 y 5, con ellas se construyó

la pila de Sprint que conformara la primera parte de la aplicación al final de esta iteración.

6.1 Objetivos

Los objetivos por cumplir en este primer sprint son:

➢ Entregar interfaz para solicitud de información del servidor de correo electrónico.

➢ Entregar interfaz para las diferentes plantillas a manejar. En las reuniones de equipo se aclararon dudas respecto a diseño de interfaz, permisos

y datos a utilizar para el correcto funcionamiento de cada interfaz.

6.2 Scrum Taskboard

Haciendo uso de la Taskboard se asignaron las historias para cada ejecutor y se llevó

un control sobre las historias de usuario ya terminadas.

Tabla 23. Scrum Taskboard Inicial – Sprint1

HISTORIAS DE

USUARIO

PENDIENTES

EN PROGRESO TERMINADA

HISTORIA EJECUTOR

HU02

HU03

HU04

HU01

HU05

49

Tabla 26. Scrum Taskboard en Progreso – Sprint1

HISTORIAS DE USUARIO

PENDIENTES


HISTORIA EJECUTOR

HU02

HU03 LEIDY

HU04

HU01

HU05 LEIDY

Tabla 27. Scrum Taskboard Terminado – Sprint1

HISTORIAS DE USUARIO

PENDIENTES


HISTORIA EJECUTOR

HU02

HU03

HU04

HU01

HU05

6.3 Reunión de Revisión del Sprint 1

En reunión con el tutor, se presentan los resultados del primer Sprint donde se obtienen

las siguientes sugerencias:

➢ Usar tonos de color más claros para los avisos.

➢ Cambiar ubicación de algunos elementos de las interfaces.

6.4 Cierre y entrega

Una vez se cumplió con los objetivos del Sprint 1, se obtuvo respuesta de aceptación por

parte el tutor, con lo cual se dio por finalizado el Sprint 1 no sin antes haber realizado las

modificaciones sugeridas.

Se procede a dar inicio al Sprint 2.

50

7. SPRINT 2

Para este Sprint se atendieron las historias de usuario 6,7,8,9 y 10, con ellas se construyó

la pila de Sprint que conformara la segunda parte de la aplicación al final de esta

iteración.

7.1 Objetivos

Los objetivos por cumplir en este segundo sprint son:

➢ Entregar todas la interfaces y eventos desarrollados.

➢ Entregar conexión al servidor de correo electrónico hMailServer. ➢ Entregar las configuraciones y pruebas realizadas con el servidor y la conexión

establecida.

➢ Entregar las posibles viabilidades de poder generar el código.

➢ Entregar el código generado con las plantillas y las expresiones regulares. ➢ Entregar las plantillas que se utilizaron en el desarrollo de la herramienta.

➢ Entregar las expresiones regulares que se utilizaron en el desarrollo de la

herramienta.

En las reuniones de equipo se aclararon dudas respecto a diseño de interfaz, permisos,

validaciones y datos a utilizar para el correcto funcionamiento de cada interfaz.

7.2 Scrum Taskboard




HISTORIAS DE

USUARIO

PENDIENTES


HISTORIA EJECUTOR

HU06

HU07

HU08

HU09

HU10

51


HISTORIAS DE

USUARIO

PENDIENTES


HISTORIA EJECUTOR

HU06 LEIDY

HU07

HU08 LEIDY

HU09

HU10


HISTORIAS DE

USUARIO

PENDIENTES


HISTORIA EJECUTOR

HU06

HU07

HU08

HU09

HU10


En reunión con el representante de laboratorios y el coordinador de laboratorio, se

presentan los resultados del segundo Sprint donde se obtiene la aprobación completa

de este.



parte del tutor, con lo cual se dio por finalizado el Sprint 2.

Se procede a dar inicio al Sprint 3.

52

8. SPRINT 3

Para este Sprint se atendieron las historias de usuario 11, 12, y 13, con ellas se construyó

la pila de Sprint que conformara la tercera parte de la aplicación al final de esta iteración.

8.1 Objetivos

Los objetivos por cumplir en este tercer sprint son:

➢ Entregar la compilación de la lógica realizada en el subsistema de procesamiento.

➢ Entregar la compilación como API o como una librería.

En las reuniones de equipo se aclararon dudas respecto a diseño de interfaz, permisos

y datos a utilizar para el correcto funcionamiento de cada interfaz.

8.2 Scrum Taskboard




HISTORIAS DE

USUARIO

PENDIENTES


HISTORIA EJECUTOR

HU11

HU12

HU13

53


HISTORIAS DE

USUARIO

PENDIENTES


HISTORIA EJECUTOR

HU11 LEIDY

HU12

HU13 LEIDY


HISTORIAS DE

USUARIO

PENDIENTES


HISTORIA EJECUTOR

HU11

HU12

HU13


En reunión con el tutor, se presentan los resultados del tercer Sprint donde se obtiene

la aprobación completa de este.



parte del tutor con lo cual se dio por finalizado el Sprint 3.

Se procede a dar inicio a la fase final.

54

9. FASE FINAL

Una vez implementado y acoplado todo el proyecto, se realizaron pruebas en el aplicativo

y a continuación mostramos una de principales interfaces realizadas:

Ilustración 2. Resultados de interfaces

En este punto del proyecto, la herramienta API ha sido probado y aceptado por parte del

tutor. Se realizaron modificaciones pequeñas en cuanto interfaz.

55

10. CONCLUSIONES

➢ La metodología de desarrollo Scrum, resulto ser la mejor herramienta para el

desarrollo de este proyecto, ya que permitió desarrollarlo en el tiempo límite que

se tenía, en un orden coherente, ordenado y además permitió la constante

interacción con el cliente (desarrollador común).

➢ Las herramientas que se utilizaron para el desarrollo de la herramienta API,

generan un mayor conocimiento para mí como estudiante, complementando todas

las bases adquiridas durante nuestro periodo de formación.

➢ Trabajar en Java fue una gran experiencia, demostró ser un lenguaje simple, con

buen rendimiento y robusto, capaz de trabajar en conjunto con otros componentes

como hMailServer, el cual es un servidor simple y sencillo en cuanto a su uso.

➢ El uso del framework PrimeFaces y Spark definitivamente promueve el uso de

buenas prácticas de programación y permitió generar un código fácilmente

comprensible para los desarrolladores.

➢ El desarrollo de este proyecto brindo un gran soporte y confianza para investigar

más en este marco de la información en el grupo de investigación METIS.

➢ Gracias al desarrollo de este proyecto se prueba que es posible realizar una

herramienta de ayuda a la generación de código.

➢ Se contribuye con el marco de investigación del grupo METIS y se genera el

espacio para mejorar la herramienta con mejores avances tecnológicos.

56

11. BIBLIOGRAFÍA

Acedo, J. (04 de Mayo de 2015). http://programacion.jias.es. Recuperado el 19 de Febrero de 2018, de

http://programacion.jias.es/2015/05/web-%C2%BFque-es-el-framework-bootstrap-ventajas-

desventajas/

Alvarado, O. (2015). http://obedalvarado.pw. Recuperado el 19 de Febrero de 2018, de

http://obedalvarado.pw/sistema-de-control-de-inventario/

Alvares, M. A. (Mayo de 2014). www.desarrolloweb.com. Recuperado el 19 de Febrero de 2018, de

https://www.desarrolloweb.com/articulos/392.php

Ardissone, J. (15 de Febrero de 2012). www.maestrosdelweb.com. Recuperado el 19 de Febrero de

2018, de http://www.maestrosdelweb.com/curso-symfony2-introduccion-instalacion/

bookedscheduler. (2017). http://www.bookedscheduler.com/. Recuperado el 19 de Febrero de 2018, de

http://www.bookedscheduler.com/

CLASSROOMBOOKINGS. (2014). http://classroombookings.com. Recuperado el 19 de Febrero de 2018,

de http://classroombookings.com

Ecured. (2016). www.ecured.cu. Recuperado el 19 de Febrero de 2018, de

https://www.ecured.cu/Aplicaci%C3%B3n_web

EcuRed. (2017). https://www.ecured.cu. Recuperado el 20 de Febrero de 2018, de

https://www.ecured.cu/Sistema_Gestor_de_Base_de_Datos

glpi-project.org. (2014). http://glpi-project.org. Recuperado el 19 de Febrero de 2018, de http://glpi-

project.org/spip.php?lang=en

Gutiérrez, J. J. (2014). http://www.lsi.us.es. Recuperado el 19 de Febrero de 2018, de

http://www.lsi.us.es/~javierj/investigacion_ficheros/Framework.pdf

invgate. (2017). http://www.invgate.com. Recuperado el 19 de Febrero de 2018, de

http://www.invgate.com/es/assets/

kaumerwms. (2017). www.kaumerwms.com. Recuperado el 19 de Febrero de 2018, de

http://www.kaumerwms.com/

librosweb.es. (2013). http://librosweb.es. Recuperado el 19 de Febrero de 2018, de

http://librosweb.es/libro/javascript/capitulo_1.html

librosweb.es. (2015). http://librosweb.es. Recuperado el 19 de Febrero de 2018, de

http://librosweb.es/libro/css/capitulo_1.html

ocsinventory-ng. (2010). www.ocsinventory-ng.org. Recuperado el 19 de Febrero de 2018, de

http://www.ocsinventory-ng.org/en/

57

proyectosagiles.org. (2015). https://proyectosagiles.org. Recuperado el 20 de Febrero de 2018, de


Rouse, M. (Enero de 2015). http://searchdatacenter.techtarget.com. Recuperado el 20 de Febrero de

2018, de http://searchdatacenter.techtarget.com/es/definicion/MySQL

Rouse, M. (Diciembre de 2016). http://searchdatacenter.techtarget.com. Recuperado el 19 de Febrero

de 2018, de http://searchdatacenter.techtarget.com/es/definicion/Servidor-Web

Valdés, D. P. (26 de Octubre de 2007). www.maestrosdelweb.com. Recuperado el 20 de Febrero de

2018, de http://www.maestrosdelweb.com/que-son-las-bases-de-datos/

www.acercadehtml.com. (2015). http://www.acercadehtml.com. Recuperado el 19 de Febrero de 2018,

de http://www.acercadehtml.com/manual-html/que-es-html.html

API PARA LA GENERACIÓN DE INTERFACES Y EVENTOS EN...

Documents

Transcript of API PARA LA GENERACIÓN DE INTERFACES Y EVENTOS EN...