Tesis Mensajeria Masiva (1)

UNIVERSIDAD SIMON BOLIVARDECANATO DE ESTUDIOS PROFESIONALES

COORDINACION DE INGENIERIA DE LA COMPUTACION

SISTEMA DE ENVIO DE MENSAJERIA MASIVA MULTIPLATAFORMA

Por:Andres H. Marino O.

Realizado con la asesora de:Tutor Academico: Mara Angelica Perez de Ovalles

Tutor Industrial: Grisel D Alessio

PASANTIA LARGAPresentado ante la Ilustre Universidad Simon Bolvar

como requisito parcial para optar al ttulo deIngeniero en Computacion

Sartenejas, Enero de 2012

Resumen

El presente trabajo describe el desarrollo(analisis, diseno, implementacion y pruebas unitarias

y de integracion) del Sistema de Envo de Mensajera Multiplataforma, util para enviar infor-

macion a listas de distribucion, El sistema fue desarrollado en plataforma web, permitendole

a los usuarios poder registrarse, agregar suscriptores, gestionar listas sobre los suscriptores,

enviar alertas a estas listas, y recibir reportes.

Dicho sistema fue de beneficio para la empresa Ogangi, ya que permite facilitar sus ser-

vicios a sus clientes simplificando y unificando el proceso de Envo de SMS y Correos.

Actualmente, es necesario realizar pruebas de carga en el sistema para observar su rendi-

miento.

El sistema fue implementado en los lenguajes JSP, JavaScript, Java, ademas, utilizo Mo-

bile API, un sistema propietario de Ogangi, el cual se comunica mediante Servicios Web y

Servlets con la base de datos y los servidores para enviar la mensajera. Tambien posee niveles

de encriptamiento y seguridad, tales como protocolo HTTPS(Hypertext Transfer Protocol

Secure ) y se encripto cierta informacion con el algoritmo Sha-1, su desarrollo se llevo a cabo

bajo la metodolga RUP, en cuatro iteraciones.

iv

DEDICATORIA

A mi Madre.

v

Agradecimientos

A todas aquellas personas que de una u otra manera me han ayudado a lo largo de la

carrera, en especial a mi mama Luz Amparo Osorio y a Orlando Gonzales.

Indice general

Indice general VII

Indice de cuadros IX

Indice de figuras X

Lista de Abreviaturas XII

Introduccion 1

1. La empresa: Ogangi de Venezuela 3

1.1. Resena Historica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2. Vision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.3. Mision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.4. Estructura de la empresa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2. Marco Teorico 7

2.1. Arquitectura de capas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2. Servicio Web REST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.3. JQuery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.4. DataTables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3. Marco Metodologico 11

3.1. Rational Unified Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.1.1. Estructura de RUP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.1.2. Fases de RUP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.1.3. Fases y artefactos de RUP contemplados en el proyecto de pasanta . 14

3.1.3.1. Artefactos elaborados . . . . . . . . . . . . . . . . . . . . . 15

4. Desarrollo 16

4.1. Primera Iteracion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4.1.1. Extraccion de requerimientos . . . . . . . . . . . . . . . . . . . . . . 17

4.1.1.1. Estudio del Sistema MMC . . . . . . . . . . . . . . . . . . . 17

4.1.1.2. Estudio del Sistema siMple . . . . . . . . . . . . . . . . . . 18

4.1.2. Establecimiento de alcance y lmites del proyecto . . . . . . . . . . . 19

4.1.3. Eleccion de Herramientas a usar . . . . . . . . . . . . . . . . . . . . . 20

4.1.4. Elaboracion de los documentos de Vision del sistema, ERS y DAS . . 21

4.2. Segunda Iteracion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.2.1. Caso de Uso Registrar Usuario . . . . . . . . . . . . . . . . . . . . . . 27

4.3. Tercera Iteracion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.3.1. CU Modificar Listas . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.4. Cuarta Iteracion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.4.1. Enviar SMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

5. Conclusiones y recomendaciones 45

Bibliografa 47

A. Vision Del Sistema 49

B. Documento de Arquitectura 62

C. Especificaciones de Requerimientos del Sistema 80

viii

Indice de cuadros

3.1. Artefactos elaborados durante la pasanta . . . . . . . . . . . . . . . . . . . . 15

4.1. Narrativa CU Registrar Usuario . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.2. Narrativa CU Modificar Lista . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.3. Narrativa CU Enviar SMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

Indice de figuras

1.1. Organigrama Ogangi Corporation Diciembre 2011. Fuente: [Cor10] . . . . . . 5

3.1. Disciplinas y fases de RUP. Fuente: [ee11] . . . . . . . . . . . . . . . . . . . . 12

4.1. Caso de Uso Inicial. Fuente:Elaboracion propia . . . . . . . . . . . . . . . . . 19

4.2. Modelo de Dominio Inicial. Fuente:Elaboracion propia . . . . . . . . . . . . . 20

4.3. Vista de implementacion. Fuente:Elaboracion propia . . . . . . . . . . . . . . 21

4.4. Diagrama de componentes. Fuente:Elaboracion propia . . . . . . . . . . . . . 22

4.5. Caso de Uso primera iteracion. Fuente:Elaboracion propia . . . . . . . . . . 22

4.6. WAE primera iteracion. Fuente:Elaboracion propia . . . . . . . . . . . . . . 23

4.7. Caso de Uso segunda iteracion. Fuente:Elaboracion propia . . . . . . . . . . 25

4.8. WAE segunda iteracion. Fuente:Elaboracion propia . . . . . . . . . . . . . . 26

4.9. Interfaz Registrar Usuario. Fuente:Elaboracion propia . . . . . . . . . . . . 28

4.10. Diagrama de Secuencia Registrar Usuario. Fuente:Elaboracion propia . . . . 29

4.11. Caso de Uso tercera iteracion. Fuente:Elaboracion propia . . . . . . . . . . . 31

4.12. WAE tercera iteracion. Fuente:Elaboracion propia . . . . . . . . . . . . . . . 32

4.13. Interfaz Modificar Listas. Fuente:Elaboracion propia . . . . . . . . . . . . . . 33

4.14. Diagrama de Secuencia Modificar Listas. Fuente:Elaboracion propia . . . . . 35

4.15. Caso de Uso cuarta iteracion. Fuente:Elaboracion propia . . . . . . . . . . . 37

4.16. WAE cuarta iteracion, Fuente:Elaboracion propia . . . . . . . . . . . . . . . 38

4.17. Interfaz de Enviar SMS Paso 1. Fuente:Elaboracion propia . . . . . . . . . . 40




4.21. Diagrama de Secuencia Enviar SMS. Fuente:Elaboracion propia . . . . . . . 43

Lista de Abreviaturas

API Application Programming Interface (Interfaz de programacion de

aplicaciones)

CSS Cascading Style Sheets

CU Caso de Uso

DAS Documento de Arquitectura de Software

EGO Enterprise on the GO

ERS Documento de Especificacion de Requerimientos de Software

HTTP HyperText Transfer Protocol (Protocolo para Transferencia de Hi-

perTexto)

JDE Java Development Environment (Ambiente de Desarrollo Java)

JDK Java Development Kit (Equipo de Desarrollo Java)

JSP JavaServer Pages

MAPI Mobile API

MMC Mobile Master Control

REST Representational State Transfer (Transferencia de Estado Repre-

sentacional)xii

1RUP Rational Unified Process (Proceso Unificado de Rational)

SDK Software Development Kit (Kit de Desarrollo de Software)

SMS Short Message Service (Servicio de Mensajera Corta)

UI Unit Interface

URI Uniform Resource Identifier

URL Uniform Resource Locator (Localizador Uniforme de Recursos)

VS Documento de Vision del Sistema

WAE Web Application Extension

W3C World Wide Web Consortium

XML eXtensible Markup Language (Lenguaje de Marcas Extensible)

Introduccion

Con la utilizacion de las tecnologas de la informacion en cada vez mas aspectos de

nuestras vidas, se han diversificado las maneras de enviar informacion a las personas, en

formas rapidas y directas, tales como son los SMS o los correos electronicos; estas han ganado

terreno a la hora de informar a los usuarios de productos, facturas, informacion relevante,

como miscelanea, mantener comunicacion, entre otros. De manera rapida y sencilla.

Esto da muchas oportunidades a las companias, empresarios y emprendedores de abrir

una comunicacon directa con sus clientes; tal es el caso de un banco que quiere, notificar

a sus clientes que el corte de sus tarjetas de credito es en una fecha especfica, o enviar

2informacion pertinente acerca de un evento, entre otros. Existen pocas companias capaces de

ofrecer este tipo de servicios, no unifican el envio de informacion por ambas plataformas(SMS

y Correo Electronico), tampoco tienen un manejo sencillo de las listas de distribucion de los

clientes, y suelen ser engorrosas de manejar, editar, entre otros. sobrecargando el trabajo de

los usuarios.

Actualmente Ogangi de Venezuela, es una empresa que ofrece estos servicios, esta posee

dos sistemas para el envio de Alertas. Ante la necesidad de sus clientes de unificar estos

sistemas se decide crear un nuevo sistema EGO(Por sus siglas en ingles Enterprise on the

GO).

Este proyecto se concibe con la finalidad de crear un sistema Web, que facilite la gestion

de listas de distribucion, as como el envo de alertas a estas, concretamente debera poseer

las siguiente caractersticas:

Gestion se suscriptores

Gestion de listas de distribucion a partir de los suscriptores

Creacion, configuracion y envo de alertas a listas de distribucion por multiples plata-

formas (SMS, correo electronico).

Las limitaciones que poseen los sistemas actuales son: multiples listas, para poder enviar

las alertas, una lista por cada plataforma( SMS , correo electronico), las listas de distribucion

no son modificables, una vez cargadas en el sistema sus suscriptores no se pueden modificar.

Las ventajas de esta nueva aplicacion son la unificacion de las listas de distribucion,

posibilidad de edicion, tanto de los suscriptores como de las listas, as como posibilidad de

armar las listas de distribucion sobre los suscriptores existentes.

Captulo 1

La empresa: Ogangi de Venezuela

En este captulo se presenta una descripcion del entorno en el cual se desarrollo el proyecto

de pasanta en Ogangi de Venezuela C.A. Comprende la composicion corporativa, una breve

resena historica de la empresa, su mision y vision, as como la estructura organizacional, y

la ubicacion del pasante dentro de la misma.

1.1. Resena Historica

En el ano 2002, un grupo de ejecutivos provenientes de empresas como Bell Labs, 3Com

Corporation y The Walt Disney Company se agruparon para formar Ogangi Corporation

con una vision dirigida hacia la tecnologa movil. La empresa ha desarrollado innovaciones

tecnologicas que integran las plataformas de los diferentes operadores moviles en America,

incrementando de esta forma, los beneficios que ofrecen los equipos celulares en los negocios,

proveedores de contenidos, gobiernos y usuarios finales.

En Miami (EE.UU) se encuentra la sede administrativa y de alta gerencia de la empresa,

en Venezuela se encuentra el area operativa, ubicada en dos estados: Distrito Capital y

Merida. [Cor10].

41.2. Vision

La Vision de Ogangi Corporation es:

Generacion de nuevas oportunidades de ingresos para las empresas proveedoras de con-

tenidos y operadores moviles a traves de la gestion de nuevos contenidos a un enorme

mercado de usuarios moviles de manera rapida y economica.

Proveer soluciones para negocios y gobiernos en la busqueda de nuevas vas de comu-

nicacion hacia los receptores, de una forma efectiva y economica, como portales WAP,

mensajera de texto , entre otros.

Proveer opciones de entretenimiento a usuarios finales a traves de concursos, trivias,

portales WAP, entre otros.

Satisfacer necesidades y requerimientos de clientes y usuarios finales. [Cor10]

1.3. Mision

La mision de la empresa se define de la siguiente manera: Brindar soluciones de bajo

costo y efectivas que transformen la red de los operadores y los dispositivos moviles de los

usuarios en una plataforma interactiva de contenido. [Cor10]

1.4. Estructura de la empresa

Ogangi Corporation esta integrada por distintos departamentos con la finalidad de dis-

tribuir de forma eficiente las actividades correspondientes al proceso de negocio de la misma.

Actualmente, se tienen 5 departamentos en Ogangi: Desarrollo de Software, Ventas, Opera-

ciones e Infraestructura Tecnologica, Finanzas y Contenido. Ver figura 1.1

5Figura 1.1: Organigrama Ogangi Corporation Diciembre 2011. Fuente: [Cor10]

A continuacion se describe el departamento de Ogangi Corporation en el que se desa-

rrollo la pasanta. [pdDdAdOC10]. El departamento de Desarrollo Los miembros de este

equipo se encargan del desarrollo de software, ademas de solucionar cualquier requerimiento,

de ambito tecnologico, establecido por los clientes y por la empresa.

El desarrollo del proyecto fue bajo la tutela de la Ingeniero Grisel D Alessio, quien

forma parte de dicho departamento como Desarrollador Senior y Project Leader Manager.

La mision principal de este departamento es desarrollar software y aplicaciones a la medida

de los clientes.

El pasante Andres Marino cumplio la mision de desarrollar EGO (Enterprise on the

GO), un sistema propietario de Ogangi, que permite el envo de mensajera por multiples

6plataformas (SMS, Correo electronico) a listas de distribucion.

Una vez descrita la empresa, Vision y Mision de la misma, asi como el departamento en

el que se desarrollo el sistema, se sigue al captulo 2 en el cual se explican las bases teoricas,

y tecnologicas para el desarrollo de la pasanta.

Captulo 2

Marco Teorico

Este captulo presenta las bases teoricas que fundamentan el desarrollo del proyecto.

Principalmente se hace un enfoque en el tipo de arquitectura usada. Una arquitectura de

capas, los servicios Web REST, tambien tecnologas utilizadas como JQuery.

2.1. Arquitectura de capas

Segun Kappel [KG03] una arquitectura de N capas es aquella que permite organizar una

aplicacion Web en un numero arbitrario de capas. Tpicamente se consideran tres capas. La

capa de datos, que reune todos los aspectos del software que tienen que ver con el manejo

de los datos persistentes, la capa de negocio que reune todas las tareas, reglas y restricciones

que implementan y apoyan los procesos de negocio. Y finalmente, la capa de presentacion que

prepara el resultado de las peticiones en el formato de salida deseado; esta capa por lo general

reune todos los aspectos del software que tiene que ver con las interfaces y la interaccion con

los diferentes tipos de usuarios humanos.

8Segun Larman [Cra03] la idea esencial del modelo de capas es organizar la estructura

logica del sistema en distintas capas que tendran distintas responsabilidades pero que estaran

relacionadas de una manera cohesiva.

Algunas de las ventajas de esta arquitectura es que facilita la estandarizacion, permite la

contencion de cambios a una o pocas capas y en algunos casos garantiza la reutilizacion de

las capas conceptualizadas.

En este proyecto se decidio utilizar una arquitectura por capas, por su facilidad de reuti-

lizacion y mantenibilidad, tambien se usaron los servicios Web REST.

2.2. Servicio Web REST

REST(por sus siglas en ingles: Representational State Transfer). Es un estilo de arquitec-

tura para Web orientada al Software. A traves de este mecanismo se pueden ofrecer servicios

web para utilizar la web como una plataforma de computacion distribuda [RES11].

El termino REST inicialmente se refera a un conjunto de principios de arquitectura. En

la actualidad se usa en el sentido mas amplio para describir cualquier interfaz Web simple que

utiliza XML y HTTP, sin las abstracciones adicionales de los protocolos basados en patrones

de intercambio de mensajes como el protocolo de servicios Web SOAP.

Se pueden disenar sistemas de servicios Web de acuerdo con el estilo arquitectural REST

de Roy Fielding y tambien es posible disenar interfaces XMLHTTP de acuerdo con el estilo

de llamada a procedimiento remoto pero sin usar SOAP. Estos son los dos usos diferentes del

termino REST.

9Los sistemas que siguen los principios REST se llaman con frecuencia RESTful. REST

afirma que la Web ha disfrutado de escalabilidad como resultado de una serie de disenos

fundamentales clave: [RES11]

Un protocolo cliente/servidor sin estado: cada mensaje HTTP contiene toda la informa-

cion necesaria para comprender la peticion. Como resultado, ni el cliente ni el servidor

necesitan recordar ningun estado de las comunicaciones entre mensajes. Sin embargo, en

la practica, muchas aplicaciones basadas en HTTP utilizan cookies y otros mecanismos

para mantener el estado de la sesion (algunas de estas practicas, como la reescritura de

URLs, no son permitidas por REST).

Un conjunto de operaciones bien definidas que se aplican a todos los recursos de infor-

macion: HTTP en s define un conjunto pequeno de operaciones, las mas importantes

son POST, GET, PUT y DELETE. Con frecuencia estas operaciones se equiparan a

las operaciones CRUD que se requieren para la persistencia de datos, aunque POST no

encaja exactamente en este esquema.

Una sintaxis universal para identificar los recursos: en un sistema REST, cada recurso es

direccionable unicamente a traves de su URI (Por sus siglas en ingles Uniform Resource

Identifier).

El uso de hipermedios, tanto para la informacion de la aplicacion como para las transi-

ciones de estado de la aplicacion: la representacion de este estado en un sistema REST

son tpicamente HTML o XML. Como resultado de esto, es posible navegar de un recur-

so REST a muchos otros, simplemente siguiendo enlaces sin requerir el uso de registros

u otra infraestructura adicional.

Aparte de utilizar este tipo de servicios Web, tambien se utilizo del lado del cliente,

JQuery una librera de Java-Script.

10

2.3. JQuery

JQuery es una biblioteca de JavaScript rapida y concisa que simplifica el recorrido de

documentos HTML, el manejo de eventos, animacion, y las interacciones con Ajax para el

desarrollo Web rapido [Jqu11].

Este framework ha sido de gran utilidad para el manejo de funciones con JavaScript ya

que posee una cantidad de libreras con metodos ya implementados que ofrecen facilidad al

momento de ejecutar ciertas acciones por parte del Cliente en un ambiente Web. De este modo

se pudo realizar con rapidez la implementacion de una interfaz dinamica con validaciones

pertinentes.

2.4. DataTables

DataTables es un plug-in para la libreria de JQuery. Es una herramienta Open-Source,

muy fexible que permite interaccion avanzada con las tablas HTML, su manipulacion, crea-

cion, busqueda de informacion entre ellas, exportacion, entre otros, de manera dinami-

ca [Jar11].

Ahora se procede en el siguiente captulo a explicar la metodologa utilizada para desa-

rrollar el sistema.

Captulo 3

Marco Metodologico

El presente captulo tiene como objetivo dar a conocer los aspectos metodologicos en los

que se baso la ejecucion del proyecto de pasanta.

3.1. Rational Unified Process

Rational Unified Process (RUP) es una metodologa de desarrollo de software propuesta

por la empresa Rational, la cual se define como un proceso iterativo e incremental de desarrollo

de software que no consta de pasos firmemente establecidos sino que por el contrario, se

adapta al contexto y necesidades de cada organizacion [KR03].

3.1.1. Estructura de RUP

El Proceso Unificado de Rational es un proceso de la Ingeniera del Software. RUP provee

de un enfoque disciplinario para la asignacion de tareas y responsabilidades dentro de una

organizacion de desarrollo y su meta es asegurar la calidad en la produccion de software.

12

Segun [KR03], la estructura de RUP esta compuesta por dos dimensiones, una dinamica

y otra estatica. La primera division representa el aspecto dinamico del proceso y esta consti-

tuido por fases, iteraciones e hitos. La segunda dimension representa el aspecto estatico del

proceso y esta constituido por actividades, disciplinas, artefactos y roles.

La figura 3.1 muestra la arquitectura global de RUP. El eje horizontal representa la orga-

nizacion a lo largo del tiempo, la dimension dinamica, mientras que el eje vertical representa

la organizacion en terminos de contenido, la dimension estatica.

Figura 3.1: Disciplinas y fases de RUP. Fuente: [ee11]

13

3.1.2. Fases de RUP

RUP se conforma a traves de ciclos los cuales constituyen la vida de un producto. Cada

ciclo esta representado por cuatro fases: Inicio, Elaboracion, Construccion y Transicion las

cuales se detallaran brevemente a continuacion. Cada fase presenta sus propios criterios de

evaluacion los cuales deben ser revisados inmediatamente despues de su finalizacion, si los

criterios no son satisfechos se debe abandonar el desarrollo o realizar una reestructuracion

del proyecto.

La Fase de Inicio es la primera fase del proceso de desarrollo, tiene un conjunto de objetivos

bien definidos y se consideran concluidos con el hito: Objetivo del ciclo de vida. El objetivo

principal de esta fase es entender el alcance y objetivos del proyecto. En esta fase se identifica

la funcionalidad clave del sistema, a traves de la identificacion de los casos de uso mas crticos.

La Fase de Elaboracion provee direccion a los principales riesgos, se disena la arquitectura

del sistema de software que satisfaga los requerimientos, y se da refinamiento al plan de

proyecto. Los objetivos especficos de esta fase son:

Obtener un entendimiento mas detallado de los requerimientos.

Disenar, implementar, validar y generar una lnea base para la arquitectura.

Mitigar los riesgos esenciales y producir un plan de costos mas preciso.

De la Fase de Construccion el objetivo principal es la construccion del sistema. Su enfoque

principal es el desarrollo de los componentes y caractersticas del sistema que se ha disenado.

Esta fase se caracteriza por una gran actividad de codificacion. En proyectos de gran escala

suele tener varias iteraciones que dividen el conjunto de casos de uso con el fin de producir

varios prototipos.

14

Esta fase se considera finalizada cuando se han desarrollado todas las funcionalidades y se

produce un primer realease del software. Su conclusion esta marcada por el hito de Capacidad

Inicial de Operaciones.

De la Fase de Transicion el objetivo principal es la transicion del sistema del ambiente de

desarrollo al ambiente de produccion, haciendo que el sistema este disponible para el usuario,

dotandole de charlas de induccion, entrenamientos y manuales de usuario. Ademas se carac-

teriza por la ejecucion de pruebas beta por parte de los usuarios, lo que permitira validar las

expectativas de los usuarios en relacion con el producto implementado. Si todos los objetivos

son alcanzados, el hito Release de Producto se considera alcanzado y por tanto el ciclo de

desarrollo finaliza.

Finalmente, para el desarrollo de este proyecto se adopto la metodologa RUP, pero no se

realizo ninguna iteracion de Transicion.

3.1.3. Fases y artefactos de RUP contemplados en el proyecto de

pasanta

En la planificacion del proyecto de pasanta se contemplaron en su totalidad las primeras

tres fases de RUP: Inicio(una Iteracion), Elaboracion(una Iteracion)y Construccion(dos Ite-

raciones) con cuatro iteraciones. La iteracion de Transicion no se desarrollo, debido a que no

forma parte del objetivo general del proyecto la implantacion y puesta en produccion de la

solucion.

La metodologa RUP contempla la elaboracion de un conjunto de artefactos en cada

una de las fases; estos se pueden adaptar al contexto y necesidades de cada organizacion.

Partiendo de listado de estos artefactos, se acordo el subconjunto de entregables a elaborar

15

durante el proyecto de pasanta, adaptados al contexto del proyecto.

3.1.3.1. Artefactos elaborados

A continuacion, en la tabla 3.1, se presentan los artefactos que se decidieron elaborar en

cada fase de RUP.

Fase de InicioDocumento DescripcionVision del Sistema(VS) El documento de Vision permite analizar y de-

finir las necesidades del sistema a alto nivel.Especificacion de Requerimientos del Sistema(ERS) El documento de Requerimientos del Sistema

permite especificar los requerimientos funcio-nales y no funcionales del sistema.

Fase de ElaboracionDocumento DescripcionDocumento de Arquitectura del Software(DAS) El documento de Arquitectura del Software

proporciona una vision general de la arquitec-tura del sistema, a traves de diferentes vistas.Entre ellas estan vista de datos, vista de casosde uso, vista de implementacion, vista logicay vista de despliegue.

Fase de ConstruccionDocumento DescripcionManual de Usuario Describe las funcionalidades del sistema de

forma detallada, brindando asistencia a cual-quier usuario de la aplicacion.

Cuadro 3.1: Artefactos elaborados durante la pasanta

Finalmente despues de describir la metodologa a utilizar, numero de iteraciones contem-

pladas y tipo de las mismas, proseguimos con el captulo de Desarrollo en el cual se describe

como fue el desarrollo del proyecto.

Captulo 4

Desarrollo

En este captulo se describen los productos mas importantes generados durante la ejecu-

cion de todas las tareas realizadas para el desarrollo de este proyecto. Ademas, se explican

los problemas encontrados con sus respectivas soluciones y las decisiones de diseno tomadas

junto con sus razonamientos, el proyecto se desarrollo en cuatro iteraciones, a continuacon

se describe el desarrollo de cada iteracion, junto con los elementos elaborados en ellas.

4.1. Primera Iteracion

Esta iteracion tuvo una duracion de dos semanas, al iniciar el desarrollo del proyecto, en

Ogangi ya exista un sistema que cumpla la funcion de enviar mensajeria de texto a listas

de distribucion y otro a listas de correo electronico. Sin embargo, para poder desarrollar el

nuevo sistema se vio la necesidad de analizar los sistemas existentes para retomar sus puntos

fuertes y eliminar las fallas de diseno de ambos.

Esta primera iteracion contemplo la investigacion en la que se obtuvo la informacion

necesaria para definir el alcance de las iteraciones del proyecto.

17

Para poder definir de forma adecuada los lineamientos se llevaron a cabo las siguientes

tareas:

Extraccion de requerimientos.

Estudio del Sistema MMC.

Estudio del Sistema siMple.

Establecimiento de alcance y lmites del proyecto.

Eleccion de Herramientas a usar.

Elaboracion del diagrama de Casos de Uso inicial(se coloco en el Documento de Re-

querimientos del Sistema ERS) y del Modelo de Dominio(se coloco en el Documento

de Arquitectura de Software DAS).

Elaboracion de los documentos de Vision del sistema VS.

A continuacion se presenta el resultado de cada una de las actividades anteriormente

mencionadas:

4.1.1. Extraccion de requerimientos

En la presente seccion se describen los sistemas actuales, uno denominado MMC y el otro

demoninado siMple, estos son los sistemas que se utilizan para el envo de SMS y correos

electronicos.

4.1.1.1. Estudio del Sistema MMC

Ogangi cuenta con un sistema online llamado MMC(por sus siglas en ingles Mobile Mas-

ter Control) el cual sirve para enviar mensajes de texto y de correo electronico a listas de

18

distribucion. Este es un sistema que esta sobrecargado, tiene muchas funcionalidades repeti-

das, puesto que fue un sistema que crecio, desviandose de su vision original. A continuacion

algunas caracterstiscas que posee MMC:

Posee manejo de listas de distribucion a SMS y posee manejo de listas de distribucion

a correos electronicos, mas no integra ambas en una sola lista.

Posee facil configuracion de alertas, para enviar a las listas de distribucion

Esta implementado con un FrameWork llamado ECHO, el cual produce un codigo poco

reutilizable.

No posee manejo asincronico lo cual hace que se recargue la informacion cada vez que

se navega por algun elemento del sistema.

4.1.1.2. Estudio del Sistema siMple

Ogangi cuenta, ademas con un sistema Web llamado siMple, el cual ofrece un servicio que

permite a los usuarios intercambiar informacion va mensajes de texto Premium, envo masivo

de mensajes de texto, programar informacion, entre otras. A continuacion se presentan las

caractersticas principales que conforman el sistema siMple:

Es un sistema bastante dinamico con caractersticas desarrolladas en JQuery.

El sistema no posee un manejo intuitivo de las listas de distribucion.

El sistema posee un modulo de envo de alertas poco sencillo.

El sistema cuenta con un manejo de sesiones por usuario el cual permite a este admi-

nistrar de manera efciente y comoda las transacciones que desee mediante las funcio-

nalidades ofrecidas, con solo ingresar su correo y su contrasena.

19

4.1.2. Establecimiento de alcance y lmites del proyecto

En un principio se penso, abarcar todas las funcionalidades que posee MMC, Alertas,

Campanas, manejos de listas de distribucion, sin embargo por razones de tiempo, se tomo la

decision de que solo se abarcara los componentes de la gestion de usuarios, gestion de sus-

criptores, manejo de sesion, gestion de listas de distribucion, manejo de alertas y reportes.

No se contemplo el manejo de la gestion de campanas.

Se decidio que el sistema solo tendra dos tipos de usuario: Administrador, quien posee

control total del sistema, y Usuario, quien puede usar todos los modulos del sistema excep-

tuando el de usuarios. Se realizo el diagrama de casos de uso inicial, se muestra en la figura

4.1

Figura 4.1: Caso de Uso Inicial. Fuente:Elaboracion propia

Tamben se elaboro el Modelo de Dominio inicial. Ver figura 4.2

20

Figura 4.2: Modelo de Dominio Inicial. Fuente:Elaboracion propia

4.1.3. Eleccion de Herramientas a usar

Considerando el conjunto de requerimientos propuestos y conociendo los lenguajes me-

diante los cuales se realizara el sistema, se procedo a elegir las herramientas a utilizar para

un desarrollo rapido y efciente.

Como servidor Web se selecciono JBOSS ya que posee soporte de servlets, webServices y

JSPs ademas de contar con alta documentacion.

Como entorno de desarrollo de programacion se selecciono Eclipse ya que posee soporte

tanto para Java como para JSP, ademas ofrece un plugin especial para el desarrollo Web

dinamico integrado con JBOSS (JBOSS AS A TOOL) y control de versiones (CVS) que

permiten colocar el sistema en un repositorio que puede ser compartido por otros miembros

de la compana para la supervision y colocacion en servidores de prueba, ademas de las

herramientas para probar los servicios Web.

21

4.1.4. Elaboracion de los documentos de Vision del sistema, ERS

y DAS

En esta primera iteracion se elaboraron las primeras versiones de los documentos de VS,

ERS y DAS. definiendo los esquemas que se siguieron para el desarrollo del sistema.

Se decidio que se utilizara una arquitectura por capas, la cual permite facil mantenimiento

y reutilizacion, estas capas se definieron de la siguiente manera:

JSP: Es la que contiene el codigo en HTML, CSS y todo lo necesario para la capa de

presentacion del sistema

JS: Esta es la capa que contiene los archivos JQuery(JavaScript), en esta capa se de-

cidio realizar muchos de los chequeos de tipos y verificaciones de los campos, al igual

que la presentacion y carga de las tablas utilizadas para mostrar la informacion.

JSPLogic: Esta capa es la que se encarga de la logica del sistema, tambien realiza las

conexiones con Mobile API(MAPI), entre otras funciones.

Se procedio a elaborar el diagrama de la vista de implementacion, ver figura 4.3

Figura 4.3: Vista de implementacion. Fuente:Elaboracion propia

22

Asi como se realizo el diagrama de componentes, ver figura 4.4, para mas informacion

acerca de los componentes ver apendice B

Figura 4.4: Diagrama de componentes. Fuente:Elaboracion propia

Con el alcance mas preciso, se procedio con un refinamiento de los diagramas de Casos

de uso y modelo de dominio el cual evoluciono a un Diagrama de Diseno con notacion WAE,

ambos diagramas quedaron de la siguiente manera, ver figura 4.5 y 4.6, para mas informacion

ver apendice A y apendice B.

Figura 4.5: Caso de Uso primera iteracion. Fuente:Elaboracion propia

23

Figura 4.6: WAE primera iteracion. Fuente:Elaboracion propia

4.2. Segunda Iteracion

Esta iteracion tuvo una duracion de cuatro semanas. Se procedio con el refinamiento de

los documentos, as como el inicio de la implementacion del sistema. En el diagrama de los

casos de uso, as como en el diagrama de WAE se agrego todo lo relacionado con la Gestion

de suscriptores, en el documento ERS se detallaron todos los requerimientos para estos casos

de Uso; en el DAS se documentaron todos los diagramas de secuencia correspondientes a los

casos de uso realizados. Se implemento todo lo referente a la Gestion de la sesion, Gestion

de usuarios. y Gestion de suscriptores, se implementaron los siguientes casos de uso: Iniciar

24

Sesion, Ver Perfil, Modificar Perfil, Cerrar Sesion, Registrar Usuario, Seleccionar idioma, Lis-

tar Usuarios, Eliminar Usuarios, Crear Suscriptor, Cargar Suscriptor, Modificar Suscriptor,

Eliminar Suscriptor.

Se implementaron los siguientes archivos, en la capa JSP: index.jsp, main.jsp,profile.jsp,

suscriptor.jsp y user.jsp. Estos archivos contienen el HTML y CSS del sistema. En la capa JS:

index.js, profile.js, login.js, registration.js, suscriptor.js, user.js, logout.js. Estos archivos con-

tienen las mayoria de las verificaciones de los formularios y de los datos, asi como la carga en

tablas de la informacion de los suscriptores, tambien se encarga del pasaje de parametros a la

capa logica de manera asincronica y en la capa de JSP logico: loginLogic.jsp, logoutLogic.jsp,

registrationLogic.jsp, profileEditLogic.jsp, profileReviewLogic.jsp, userLoadLogic.jsp, user-

DeleteLogic.jsp, suscriptorLoadLogic.jsp, suscriptorAddLogic.jsp, suscriptorDeleteLogic.jsp,

suscriptorEditLogic.jsp. Estos archivos se encargan de recibir los parametros enviados por el

usuario, hacer las llamadas a MobileAPI (MAPI) el sistema que se encarga del envio de la

informacion, asi como el manejo de a Base de datos, y tambien de interpretar la respuesta

de MAPI. Tambien se implementaron las clases XML y Sha-1, una se encarga de leer los ar-

chivos XML que devuelve MAPI, y la otra clase se encarga del encriptamiento del password

del usuario.

A continuacion en las figuras 4.7 y 4.8 se presenta el diagrama WAE y el Diagrama de

casos de uso de la segunda iteracion:

25

Figura 4.7: Caso de Uso segunda iteracion. Fuente:Elaboracion propia

26

Fig

ura

4.8:

WA

Ese

gunda

iter

acio

n.

Fuen

te:E

lab

orac

ion

pro

pia

27

A manera de ejemplo, se describe la implementacion del CU Registrar Usuario, para

mayor detalle de los casos de uso realizos ver apendice B y apendice C.

4.2.1. Caso de Uso Registrar Usuario

En el caso de uso Registrar Usuario, el cual implica que en el sistema se pueden registrar

los usuarios, se determino que requera los siguientes campos:

Correo: Es un campo obligatorio, es el correo electronico del usuario, es del tipo alfa-

numerico.

Contrasena: Es un campo obligatorio, es la contrasena del usuario, es del tipo alfa-

numerico, con longitud mnima de 6, y maxima de 30.

Nombre: Es un campo obligatorio, es el nombre del usuario, es del tipo alfanumerico,

con longitud maxima de 100.

Codigo Zip: Es un campo obligatorio, es el codigo Zip del usuario, es del tipo numerico,

de longitud maxima de 10.

Categora del Negocio: Es un campo obligatorio, es la categora del tipo de negocio del

usuario, los valores posibles son: Arte y Entretenimiento, Automotriz, Servicios Em-

presariales y Profesionales, Accesorios y Ropa, Comunidad y Gobierno, Computacion y

Electronica, Construccion y Contratistas, Educacion, Alimentos y Restaurantes, Salud

y Medicina, Hogar y Jardinera, Industria y Agricultura, Legal y Financiero, Medios y

Comunicaciones, Cuidado Personal y Servicios, Bienes Races, Compras, Recreacion y

Deportes, Transporte y Turismo.

Sitio Web: Es un es obligatorio, es la pagina Web del usuario, es del tipo caracter, no

tiene longitud maxima.

28

Direccion: No es campo obligatorio, es la direccion del usuario, es del tipo caracter y

no tiene longitud maxima.

Contacto Principal: Es un campo obligatorio, es el contacto principal del usuario, es

del tipo caracter y no tiene longitud maxima.

Contacto Secundario: No es un campo obligatorio, es el contacto secundario del usuario,

es del tipo caracter y no tiene longitud maxima.

Descripcion del negocio: No es un campo obligatorio, es la descripcion del negocio del

cliente, es del tipo caracter y no posee longitud maxima.

Como reglas de negocio se requirio que la Constrasena tiene que codificarse segun el

algoritmo SHA-1. La figura 4.9 muestra la interfaz de RegistrarUsuario.

Figura 4.9: Interfaz Registrar Usuario. Fuente:Elaboracion propia

Seguido de esto se procedio con las especificaciones del caso de uso (CU), la narrativa y

la realizacion del diagrama de secuencia en el cual se pueden ver como se van conectando

29

los archivos y las solicitudes que se le hacen al sistema y las respuestas que se obtienen. Ver

tabla 4.1 y figura 4.10.

FLUJO BASICOACTOR SISTEMA1. Se ingresa en la pagina de inicio del sistemay le da click al boton de registrarse

2. Se muestra un formulario con los datos ne-cesarios para registrarse, indicando cuales sonobligatorios.

3. Se ingresan todos los datos solicitados y pre-siona el boton de Enviar.

4. Se verifica que los datos ingresados son co-rrectos. 5. Se registra el usuario en la base dedatos. 6. se muestra una alerta informando quela operacion es exitosa.

7. Se le da al boton de OK. 8. Se dirige a CU-2.FLUJOS ALTERNOS

ACTOR SISTEMA4. Se verifica que los datos ingresados no soncorrectos. 4.1. Se muestra un mensaje en lapantalla que informa el error en los datos in-gresados. 4.2 Se regresa al punto 3

Cuadro 4.1: Narrativa CU Registrar Usuario

Figura 4.10: Diagrama de Secuencia Registrar Usuario. Fuente:Elaboracion propia

30

Para la implementacion se utilizo la librera de Unit Interface (UI) de JQuery, la cual

contiene los dialogos que se pueden colocar como ventanas emergentes sin necesidad de tener

estas, en el formulario todos los chequeos de tipo, chequeo si es vacio, entre otros. Son

realizadas con JQuery, el cual permite que estas verificaciones se hagan a nivel del cliente y

no del servidor, optimizando el sistema. La comunicacion con la capa logica se realiza tambien

con JQuery mediante llamadas asincronicas lo cual evita la constante recarga de la pagina en

cada operacion, de la capa logica, que es la que se encarga de conectarse con MAPI, recibir

la respuesta e interpretartar usando la clase XML. Una vez se completo el proceso de la

implementacion se hicieron pruebas puntuales, con respecto a la funcionalidad e integracion.

4.3. Tercera Iteracion

En esta iteracion se procedio con el refinamiento de los documentos, y se continuo con

la implementacion del sistema. En el diagrama de los casos de uso, as como en el diagrama

de WAE se agrego todo lo relacionado con la Gestion de Listas, en el documento ERS se

describen todos los requerimientos para este caso de uso, en el DAS se documentaron todos los

diagramas de secuencias correspondientes a los casos de uso realizados. Se implemento todo

lo referente a la Gestion de la listas, as como se implementaron los siguientes casos de uso:

Crear Lista, Cargar Listas, Modificar Listas, Eliminar Listas.

Se implementaron los siguientes archivos, en la capa JSP: list.jsp. Este se encarga del

contenido HTML y CSS de las listas. En la capa JS: list.js. Este se encarga de manejar los

chequeos de tipo, asi como la carga de la tabla dinamica, entre otras cosas. Y en la capa

de JSP logico: listAddLogic.jsp, listLoadLogic.jsp, listModifyLoadLogic.jsp, listModifySave-

Logic.jsp, listDeleteLogic.jsp. Estos se encargan de hacer las llamadas correspondientes a

MAPI, as como interpretar su respuesta. Al igual que se tuvo que actualizar la clase XML

31

que se encarga de la lectura de los archivo XML que devuelve MAPI.

A continuacion se presenta el diagrama WAE y el Diagrama de casos de uso de la tercera

iteracion, Ver figura 4.11 y 4.12

Figura 4.11: Caso de Uso tercera iteracion. Fuente:Elaboracion propia

32

Fig

ura

4.12

:W

AE

terc

era

iter

acio

n.

Fuen

te:E

lab

orac

ion

pro

pia

33

Ahora se va a describir el proceso de desarrollo de un caso de uso implementado en esta

iteracion. Se selecciono Modificar Listas. Para mas informacion acerca de los casos de uso

desarrollados ver apendice B y apendice C.

4.3.1. CU Modificar Listas

En el caso de uso Modificar Listas, el cual implica que un usuario puede modificar las listas

de distribucion que posea incluyendo los suscriptores que pertenezcan a esta, se determino que

requeriria el siguiente campo:

Nombre: Es in campo obligatorio, este representa el nombre de la lista y es del tipo

alfanumerico.

Su interfaz se muestra en la figura 4.13

Figura 4.13: Interfaz Modificar Listas. Fuente:Elaboracion propia

34

Tambien se especifico que, el pasar suscriptores de una lista a otra, se podra hacer arras-

trando y soltando los suscriptores de una a la otra. Seguido de esto se procedio con las

especificaciones del CU, y la realizacion del diagrama de secuencia en el cual se pueden ver

como van conectando los archivos y las solicitudes que se le hacen al sistema y las respuestas

que se obtienen.

la figura 4.14 muestra su diagrama de secuencia y la tabla 4.2 muestra la narrativa

FLUJO BASICOACTOR SISTEMA1. Se le da click sobre el nombre de la lista amodificar.

2. Se despliega una pantalla con el nombre dela lista (sujeto a modificaciones), una lista dede los suscriptores pertenecientes y otra listade suscriptores no pertenecientes a dicha lista.

3. Se modifica el nombre si se quiere, al igualque se puede arrastrar los suscriptores de lalista de no pertenecientes hacia la lista de per-teneciente, y viceversa 4. se le da al boton desalvar.

5. Se procesan los datos y El sistema proce-sa los datos ingresados y salva en la BD 6. Semuestra una alerta con indicando que la ope-racion fue exitosa.

7. Se presiona el boton de OK 8. Se dirige al CU-13FLUJOS ALTERNOS

ACTOR SISTEMA4.1 Se presiona el boton de cancelar 4.2 Se redirige al CU-13.

Cuadro 4.2: Narrativa CU Modificar Lista

35

Fig

ura

4.14

:D

iagr

ama

de

Sec

uen

cia

Modifi

car

Lis

tas.

Fuen

te:E

lab

orac

ion

pro

pia

36

Al igual que para la iteracion anterior se utilizo utilizo la libreria Unit Interface (UI)

de JQuery, utilizando los dialogos y ventanas emergentes sin necesidad de tener estas, en el

formulario todos los chequeos de tipos, si es vacio. Son realizados con JQuery que permite que

estas verificaciones se hagan a nivel del cliente y no del servidor. Tambien se implemento la

llamada para listar los suscriptores pertenecientes y no pertenecientes a la lista, De esta

manera poder mostrarlos en los detalles en una ventana emergente, el manejo arrastrar

y soltar de las listas se hizo con JQuery , una vez lista las modificaciones a la lista al

darle al boton de .OK. La capa JS se encarga de extraer la informacion de la lista de

suscriptores pertenecientes que a su vez se conecta con la capa logica que se encarga de enviar

la informacion con los parametros necesarios a MAPI, y a su vez interpretar la respuesta de

este. Una vez finalizada la operacion se encarga de refrescar la tabla que contiene las listas

de distribucion.

4.4. Cuarta Iteracion

En esta iteracion se procedio con el refinamiento de los documentos, y se continuo con

la implementacion del sistema, en el diagrama de los casos de uso, as como en el diagrama

WAE se agrego todo lo relacionado con el envo de BroadCast y la Gestion de Reportes. En

el documento ERS se describen todos los requerimientos para estos casos de uso. En el DAS

se documentan los diagramas de secuencia correspondientes a los casos de uso realizados. Se

implementaron mas concretamente los siguientes casos de uso: Enviar Correo, Enviar SMS,

Listar Reportes.

Se implementaron los siguientes archivos, en la capa JSP: broadcast.jsp. En la capa JS:

broadcast.js y en la capa de JSP logico: broadcastListGroupLogic.jsp, broadcastSendLo-

gic.jsp, loadShortCodesLogic.jsp y alertSchedulesLoadLogic.jsp. Al igual que se tuvo que

37

actualizar la clase XML que se encarga de la lectura de los archivo XML que devuelve MA-

PI.

A continuacion se presenta el diagrama WAE y el Diagrama de casos de uso de la cuarta

iteracion, en las figuras 4.15 y 4.16

Figura 4.15: Caso de Uso cuarta iteracion. Fuente:Elaboracion propia

38

Fig

ura

4.16

:W

AE

cuar

tait

erac

ion,

Fuen

te:E

lab

orac

ion

pro

pia

39

Ahora se va a describir el proceso de desarrollo de un caso de uso implementado en

esta iteracion. Se selecciono Enviar SMS. Para mas informacion acerca de los casos de uso

realizados ver apendice B y apendice C

4.4.1. Enviar SMS

En el caso de uso Enviar SMS, el cual implica que en el sistema se pueden enviar SMS a

las listas de distribucion, se determino que requera los siguientes campos:

Ttulo: Es un campo obligatorio, es el ttulo del mensaje a enviar, es del tipo alfa-

numerico, y no tiene longitud maxima.

Texto: Es un campo obligatorio, es el texto del mensaje a enviar, es del tipo alfanumerico

ShortCode: Es un campo obligatorio, es la salida por la cual se enviara el SMS, es del

tipo numerico.

Lista: Es un campo obligatorio, es el nombre de la lista a la cual se desea enviar el

mensaje, es del tipo alfanumerico.

FechaDeInicio: Es un campo opcional, es la fecha en que se desea que se empiecen a

enviar los mensajes, es del tipo date.

Desde: Es un campo opcional, es la hora de inicio en la que se pueden enviar los SMS,

sigue el siguiente formato HHMMSS.

Hasta: Es un campo opcional, es la hora de fin en la que se pueden enviar los SMS,

sigue el siguiente formato HHMMSS.

DiasRestringidos: Es un campo opcional, son los das en los que no se pueden enviar

SMS, y los posibles valores son: Lun, Mar, Mie, Jue, Vie, Sab, Dom

40

La interfaz se muestra en las figuras 4.17, 4.18, 4.19 y 4.20

Figura 4.17: Interfaz de Enviar SMS Paso 1. Fuente:Elaboracion propia

41


42



43

Como regla de negocio se especifico que en el envio de broadCast la fecha de inicio del

envo fuese por medio de un calendario. A continuacion la tabla 4.3 muestra y la narrativa

la figura 4.21 muestra su diagrama de secuencia.

FLUJO BASICOACTOR SISTEMA1. Se selecciona el boton de broadcast delmenu.

2. Se despliega las listas disponibles a las quese le puede enviar el broadcast.

3. Se selecciona una lista y se le da al botonde siguiente.

4. Se despliega los campos de texto y titulo delbroadcast a enviar, tambien se despliega unalista de shortCodes disponibles.

5. Se ingresan los datos y se selecciona unshortCode, y se presiona el boton de siguiente.

6.Se despliega los campos de horas de restric-cion, hora y fecha de inicio del broadcast, dasrestringidos. Y despliega el boton de enviar.

7. Se elecciona las restricciones de horario, day fecha de inicio y le da enviar

8. El sistema enva el broadcast con las res-tricciones seleccionadas 9. Se enva una alertaindicando que la operacion fue exitosa.

10. Se presiona el boton de OK. 11. Se redirige a CU-19.FLUJOS ALTERNOS

ACTOR SISTEMA3.1 El usuario Cancela el broadCast. 3.1 Se redirige a CU-195.1 El usuario Cancela el broadCast. 5.1 Se redirige a CU-197.1 El usuario Cancela el broadCast. 7.1 Se redirige a CU-19

Cuadro 4.3: Narrativa CU Enviar SMS

Figura 4.21: Diagrama de Secuencia Enviar SMS. Fuente:Elaboracion propia

44

Tambien para la implementacion se utilizo la libreria Unit Interface (UI) de JQuery,

que tiene DaterPicker que permite en los campos de entrada colocar un calendario para

seleccionar fechas. Tambien se implemento una funcion que trajera las listas disponibles para

un suscriptor para que se pudiesen desplegar en un comboBox y este pueda seleccionar a

la que desea enviar el mensaje. Las validaciones se realizaron con JQuery permitiendo que

todas se hagan a nivel de cliente, y evitar que se realicen llamadas a MAPI con los parametros

incorrectos. Se decidio dividir el proceso en tres pasos, todos a nivel de cliente. En el primero

se coloca un asunto del mensaje y el texto a enviar. En el segundo paso, se selecciona la lista

de distribucion a la que se desea enviar el SMS, y en el tercer paso vienen las restricciones

de horario, as como la fecha de inicio. Despues cuando se le da al boton de enviar, la capa

logica se encarga de hacer las conexiones con MAPI, que se encarga de enviar el mensaje.

Seguido este paso se regresa a la pagina de alertas en la cual se muestra la tabla de Reportes.

Se hicieron pruebas puntuales y se enviaron mensajes a la lista de distribucion de manera

exitosa

Una vez finalizada la implementacion de todos los casos de uso, se finalizo la implemen-

tacion del sistema. Ahora pasamos a las conclusiones.

Captulo 5

Conclusiones y recomendaciones

Se desarrollaron todos los casos de uso requeridos por la empresa para el sistema. Se

cumplieron todos los objetivos propuestos al iniciar el desarrollo de la aplicacion. Se hicieron

pruebas unitarias funcionales y de integracion puntuales y se logro enviar exitosamente SMS

y correos electronicos, a las listas de distribucion. Mas concretamente se cumplieron los

siguientes objetivos.

Se desarrollaron los componentes para la gestion de suscriptores, tanto como la gestion

para las listas de distribucion.

Se desarrollaron los componentes para la creacion, configuracion y envo de alertas a

listas de distribucion.

Se desarrollaron los componentes para ver los reportes generados por las alertas.

La empresa Ogangi es una empresa que tiene una vision y un potencial de crecimiento

fuerte, ofrecio un ambiente de desarrollo y aprendizaje muy util para una persona que no

tiene experiencia en el campo laboral.

46

La tecnologa utilizada facilito el desarrollo de las aplicaciones, tecnologias como Jquery

que permiten desarrollar la funcionalidad a nivel de cliente, sin necesidad de sobrecargar

la funcionalidad del servidor. As su facilidad y la cantidad de libreras disponibles que se

encuentran en la red permitiendo al programador realizar un trabajo de manera mas comoda,

lo cual es altamente recomendado para desarrollar aplicaciones WEB.

La metodologa usada RUP, probo ser bastante util a la hora de adapartarse a cambios en

el flujo de desarrollo de los casos de uso, as como en la adaptabilidad a nuevos requerimientos.

Se recomienda continuar con el desarrollo de mas funcionalidades para la aplicacion tales

como: expandir el rango de las plataformas(blackberry, android, twitter, entre otros). Tambien

se recomienda hacer pruebas de carga. A pesar de tener buenos resultados en las pruebas del

sistema, es necesario observar el comportamiento ante cargas grandes de datos, y ver si es

necesaria la optimizacion en el manejo actual de las listas de distribucion.

Bibliografa

[Cor10] Ogangi Corporation. Folleto informativo de presentacion de ogangi corpo-

ration, 2010.

[Cra03] Larman Craig. Arquitectura de capas en sistemas de informacion. 2003.

[ee11] Rup en espanol. http://bannysolano.wordpress.com/2010/02/09/rup-en-

espanol, febrero 2010, Consultado el 01 de diciembre de 2011.

[Jar11] Allan Jardine. http://datatables.net/, Consultado el 01 de diciembre de

2011.

[Jqu11] Jquery. http://jquery.com/, Consultado el 01 de diciembre de 2011.

[KG03] SIEGFRIED Reich WERNER Retschitzegger KAPPEL Gerti, BIR-

GIT Proll. Web engineering: The discipline of systematic development of

web applications. 2003.

[KR03] Phillipe Kruchten and Pierre Robillard. Pedu:unified process for education.

2003.

[pdDdAdOC10] Informacion proveniente del Departamento de Administracion de Ogan-

gi Corporation. Ogangi corporation departamento de administracion, 2010.

48

[RES11] REST. http://wikipedia.org/wiki/representationalstatetransfer , febrero

2010, Consultado el 1 de diciembre de 2011.

Apendice A

Vision Del Sistema

Enterprise on the Go(EGO) Visin del Sistema

Versin 1.0

Enterprise on the Go(EGO) Versin: 1.0 Visin del Sistema Fecha: 15/08/2011

Confidencial Ogangi de Venezuela, 2012 Pg. 2 de 12

Historia de Revisiones Fecha Versin Descripcin Autor

15/08/11 1.0 Documento de Visin Andrs Mario



Visin del Sistema 1. Introduccin

1.1 Propsito+ El propsito de este documento es proveer una perspectiva amplia al lector sobre

el sistema EGO, as como tambin la definicin de las caractersticas y los propsitos que debe cumplir el sistema.

1.2 Alcance Este documento tiene como alcance el proyecto de sistema para Anlisis y

Visualizacin de Bitcoras de Seguridad: sus objetivos, paradigmas y propsitos.

1.3 Definiciones, Siglas y Abreviaciones

Stakeholders: Actores relacionados con el uso de la aplicacin. Representan a las partes interesadas.

AJAX: Asynchronous JavaScript And XML, refiere a JavaScript asncrono y XML es una tcnica de desarrollo web para crear aplicaciones interactivas o RIA (Rich Internet Applications). Estas aplicaciones se ejecutan en el cliente.

EGO: Enterprise on Go, sistema de envi masivo de mensajera mediante mltiples plataformas.

SMS: Short Message Service.

1.4 Referencias

Entendiendo el proceso de migracin. 1999. Microsoft TechNet. http://www.microsoft.com/latam/technet/articulos/199911/art03/default.aspx

Documento de Visin. 2007. Arca.

Http://www.openplans.org/projects/arca/documentode-visiA-n

1.5 Sntesis. Este documento est dividido en 10 secciones, entre las cuales destacan el

posicionamiento, la descripcin del usuario y del cliente, el resumen del producto, las caractersticas del producto, precedentes, requerimientos no funcionales, entre otros.

2. Posicionamiento

2.1 Oportunidades de Negocio Hasta la fecha, en Venezuela Ogangi posee dos sistema propietarios de envi



masivo de mensajera de texto SMS y correo electrnico, estos sistemas permiten a muchas empresas enviar informacin pertinente a todos sus clientes por estas vas.

La oportunidad del negocio es crear un sistema capaz de integrar dichos sistemas

en uno solo, de manera de tener un solo sistema que sirva para enviar mensajes a varias plataformas utilizando una lista de distribucin nica, y tambin mejorando el manejo de las listas de distribucin, esto lleva a mayor eficiencia a la hora de enviar de informacin a los clientes. De esta manera se genera un producto ms atractivo para los clientes.

En la realizacin del sistema Web queremos mantener ante todo la perspectiva del

cliente y procurar satisfacer sus necesidades, para as darle eficiencia a sus acostumbradas actividades, ofrecerles un mayor control y transparencia sobre el envo de la informacin.

2.2 Declaracin del Problema

El problema de los sistemas actuales

El problema que se tiene es que si un cliente quiere enviar mensaje tanto por la va del correo, como por la va del SMS tiene que cargar dos veces las listas de distribucin, el manejo de dichas listas puede ser engorroso, a falta de un sistema completamente integrado y automatizado que permita el envo masivo mensajera por varias plataformas.

Afecta a

A los clientes que utilizan los sistemas actuales.

Cuyo impacto es

Poca eficiencia a la hora de enviar mensajera masiva, proceso complejo.

Una solucin exitosa sera

Realizar un sistema que integre, los sistemas y funcionalidades existentes y que tengan una interfaz sencilla y amigable que optimice el proceso de envo de mensajera masiva.

2.3 Declaracin del Posicionamiento del Sistema

Para

Cualquier persona interesada en enviar mensajera masiva, por SMS o por Correo electrnico.

Quines Los usuarios tendrn la posibilidad de gestionar los envos de forma sencilla y eficiente.



EGO Es un sistema propietario Web de envo masivo de mensajera de texto por mltiples plataformas.

Qu

Dar mayor eficiencia a la hora de enviar mensajes de manera masiva, tambin manera la listas de distribucin de manera eficiente y ms amigable.

Se diferencia de En los sistemas propietarios actuales no existe alguno que integre envo de SMS y correos, tampoco existe un sistema Software libre que realice dichos envos.

Nuestro Producto

Ofrece un sistema de calidad, capaz de gestionar las listas de distribucin de manera sencilla y amigable, al igual que el envo masivo de mensajera, para el cual es necesario estas listas, tambin ofrecer reportes acerca de estos envos.

3. Descripciones de los Stakeholders y Usuarios

3.1 Demografa del Mercado Cualquier cliente de Ogangi, que este interesado en enviar informacin a sus

suscriptores, por SMS correo electrnico.

3.2 Resumen de Stakeholders

Nombre Descripcin Responsabilidades

Grisel D'Alessio Ingeniero de Software de la empresa Ogangi de Venezuela. Ocupa el cargo de desarrollador Senior, y lder de proyecto.

-Ayudar a definir el alcance del proyecto.

-Asegurar el cumplimiento de todos los objetivos.

-Revisar y aprobar la documentacin realizada tanto para la empresa desarrolladora como para los usuarios del sistema.

-Ayudar a validar los requerimientos y caractersticas del sistema.

-Proporcionar o facilitar toda la informacin requerida del negocio.

-Validar los requerimientos y diseo de la solucin mvil.

Desarrollador de Se encarga del diseo e implementacin del

Definir los requerimientos y realizar el diseo, anlisis y desarrollo del



EGO: Andrs Mario.

sistema. sistema, as como su implantacin y prueba.

Clientes de Ogangi, as como cualquier persona en Ogangi.

Cualquier persona interesada en usar el sistema EGO, para enviar informacin.

Se encarga del envo de informacin, y gestin de las listas de distribucin.

3.3 Resumen de los Usuarios

Nombre Descripcin Responsabilidades

Usuario El usuario registrado en el sistema EGO, Interesado en enviar informacin a sus clientes.

-Gestionar usuarios.

-Gestionar listas de distribucin.

-Enviar mensajera a las listas de distribucin.

-Consultar reportes.

Administrador Es el Sper usuario del sistema. Responsable del mantenimiento del sistema.

-Administrar clientes.

-Gestionar usuarios. -Gestionar listas de distribucin.

-Enviar mensajera a las listas de. Distribucin.


3.4 Ambiente Usuario

Todos los usuarios del sistema accedern a sus funcionalidades a travs de la Web, utilizando sus respectivos computadores. Esto permite portabilidad y evita el problema de configuracin de terminales. Una vez en la pgina del sitio, se presenta la interfaz principal del sistema. Los usuarios registrados pueden ser: usuarios o administrador

Los usuarios pueden gestionar los suscriptores de las listas de distribucin,

gestionar las listas de distribucin, observar reportes de envos de informacin, tanto como el envi de la informacin por mltiples plataformas.

El administrador posee un control total del sistema: Adems de los privilegios

del Usuario, puede gestionar los clientes, usuarios, listas de distribucin, envos de informacin y reportes..



Segn el tipo de usuario, se presentarn ventanas con la interfaz apropiada segn

sea el caso.

3.5 Perfil de los Interesados 3.5.1 Pasante Desarrollador de Ogangi

Representantes Andrs Mario.

Descripcin La pasante se encargar del diseo y desarrollo del SI, junto con el apoyo de su tutor industrial.

Tipo Conocimiento en lenguajes de programacin y metodologas de desarrollo.

Responsabilidad Analizar los requerimientos, disear, desarrollar, implantar y probar el sistema de informacin solicitado.

Criterios de xito

El xito es alcanzado si el proyecto de SI, es un sistema con una interfaz intuitiva y amigable, robusto, eficiente, portable, confiable.

Nivel de participacin

El pasante participa en el SI durante su elaboracin e implantacin. Posteriormente solo participar para labores de mantenimiento.

3.5.2 Clientes

Representantes Los diversos clientes de Ogangi.

Descripcin Entes encargados del envo de informacin a sus clientes. Tipo Cualesquiera.

Responsabilidad Analizar los requerimientos, disear, desarrollar, implantar y probar el sistema de informacin solicitado.

Criterios de xito

Que al utilizar el sistema, aumente la eficiencia de envo de informacin por mltiples plataformas.


Sern los usuarios finales de BM.

3.6 Perfil del Usuario

3.6.1 Usuario

Representante Cliente

Descripcin Una persona interesada en enviar informacin mediante mltiples plataformas.

Tipo Usuario.



Responsabilidad -Gestionar clientes. -Gestionar listas de distribucin.

-Enviar informacin a las listas de distribucin.


Criterios de xito

Que el usuario logre enviar la informacin que quiere transmitir a todos sus clientes por mltiples plataformas de manera eficiente.


Alta, estos usuarios son el corazn del sistema ya que es bsicamente el que provee la informacin requerida para la creacin de las listas de distribucin, como el envo de informacin a dichas listas.

3.6.2 Administrador

Representante Ogangi.

Descripcin Gerencia todas las operaciones realizadas por el SI. As como el mantenimiento del mismo.

Tipo Experto en los procesos de envo masivo de informacin mediante mltiples plataformas.

Responsabilidad -Administrar clientes. -Mantenimiento del Sistema.

Criterios de xito

Si la realizacin de su trabajo se puede lograr en menor tiempo que lo que toma actualmente, y de manera exitosa.


Alta, El Administrador de BM es el encardado del mantenimiento del SI, y que este preste un servicio optimo para los usuarios.

3.7 Necesidades de los Stakeholder o Usuarios

Necesidad

Prioridad Problema que origina la necesidad

Solucin Actual Soluciones Propuestas (Caractersticas Preliminares)

Gestionar Suscriptores Alta Actualmente no hay manera de modificar los suscriptores

Construir un mdulo en la aplicacin web que facilite la gestin de suscriptores

Gestionar Listas Alta Actualmente no existe manera de gestionar

Construir un mdulo en la aplicacin web que facilite la gestin



listas de listas Gestionar Broadcast Alta Construir un

mdulo en la aplicacin web que facilite el envo de broadcast

Gestionar Reportes Media Construir un mdulo en la aplicacin web que facilite la gestin de reportes

Gestionar Sesion Alta Construir un mdulo en la aplicacin web que facilite la gestin de sesin

Gestionar Usuarios Alta Construir un mdulo en la aplicacin web que facilite la gestin de usuarios

Intuitivo y Amigable Alta Construir el sistema con una interfaz intuitiva y amigable

Eficiente Alta Robusto Alta Construir el

sistema con el mejor manejo ante posibles fallas posibles

Seguro Alta Usar protocolos https, y algoritmos de encriptacin para ciertos datos

3.8 Alternativas y Competencias

Actualmente no existen sistemas en el mercado, ni propietarios ni de software libre que cumplan con los requisitos, por lo tanto no hay competencia.



4. Descripcin del Sistema

4.1 Perspectiva del Sistema EGO es un sistema de fcil uso y manejo, se desarrollar con la intencin de

simplificar la tarea del envi masivo de mensajera por mltiples plataformas, facilitar la gestin de las listas de suscriptores creadas para este fin, as como los suscriptores y gestionar sus respectivos reportes.

4.2 Resumen de Capacidades Tabla 4-1 Soporte de Sistema al Cliente

Beneficios

Caractersticas

Facilidad para gestionar suscriptores El sistema, facilita la insercin, modificacin y eliminacin de suscriptores.

Facilidad para gestionar listas El sistema, facilita la insercin, modificacin y eliminacin de listas.

Facilidad para gestionar Broadcast El sistema, facilita el envio de broadcast .

Facilidad para gestionar reportes El sistema facilita y genera automticamente los reportes sobre los broadcast

4.3 Aspectos asumidos y Dependencias Es indispensable que el usuario posea una conexin a Internet.

4.4 Costos y Precios N/A.

4.5 Licencias e Instalacin N/A.

5. Caractersticas del Sistema

Caracterstica Descripcin Prioridad

Gestin de Usuarios El administrador de EGO podr permitir el ingreso, modificacin, consulta y eliminacin

de clientes en el sistema.

Alta

Gestin de Suscriptores

El Cliente de EGO podr agregar, modificar, consultar y eliminar Usuarios con los cuales se crearan las listas de

Alta



distribucin necesarias para el envi de mensajera

Gestin de listas de distribucin

El Cliente de EGO podr agregar, modificar, consultar, y eliminar, Listas de distribucin en base a los Usuarios que este posea.

Alta

Envi Masivo de Mensajera

El Cliente podr enviar mensajes ya sea por va de mensajera de texto por correos electrnicos, a las listas de distribucin que posea dicho cliente, seleccionando configurando las restricciones pertinentes.

Alta

Estadsticas y reportes acerca de los envos de mensajera

El Cliente podr consultar los reportes generados por el sistema acerca de la difusin de los mensajes, status, etc.

Media

6. Restricciones El usuario debe poseer un navegador que soporte HTML5. El Lenguaje de programacin a utilizar ser JS,JSP (JavaServer Pages),Java.

7. Rangos de Calidad

Que el sistema posea una documentacin clara y precisa, una interfaz amigable e intuitiva, tiempo de respuesta minimos, robustez y niveles de seguridad.

8. Precedencia y Prioridad

La siguiente definicin de prioridades pertenecientes a las caractersticas del sistemapermitir conocer cuales habr que atender primero y cuales despus durante el desarrollo del proyecto.

1. Registro e identificacin del usuario en el sistema EGO. 2. Gestionar los usuarios pertenecientes a la listas de distribucin del sistema. 3. Carga, creacin, manipulacin y destruccin, de las listas de distribucin del

sistema. 4. Creacin y envo de mensajes de texto correos electrnicos a las listas de

distribucin. 5. Generacin de reportes acerca de los envos mensajes a las listas de distribucin.

9. Otros Requerimientos del Sistema

9.1 Estndares Aplicables EGO debe poder utilizarse en los sistemas operativos ms comunes en el

mercado, Incluyendo Software Libre. Los estndares de interfaz, robustez, portabilidad, eficiencia, las mejores prcticas de programacin sern aplicados.



9.2 Requerimientos del Sistema Se requiere un computador con conexin a Internet y un navegador que soporte

aplicaciones en AJAX y JavaScript.

9.3 Requerimientos de Desempeo El sistema debe cargar rpidamente en los navegadores y la apariencia debe ser

independiente del navegador.

9.4 Requerimientos del Ambiente La funcionalidad del sistema est condicionada al acceso al servicio de Internet.

10. Requerimientos de Documentacin

10.1 Manual de Usuario

El propsito del manual es asistir a los usuarios del Sistema EGO, ayudarlos a entender las funcionalidades de ste y de esta manera poder responder y atender cualquier inquietud que se presente sobre el funcionamiento o sobre el sistema como tal. El manual debe ser comprensible para el usuario y fcil de utilizar.

El manual debe tener respuestas a las preguntas y dudas ms frecuentes, dando

repuestas claras, acertadas y concisas sobre la temtica en cuestin, y en casos particulares, si es posible, presentar ejemplos de cmo se llevara a cabo una accin (como por ejemplo, registrar un usuario).

10.2 Guas de Instalacin, Configuracin y archivos Read Me A pesar de que no est contemplada la implantacin del sistema se crear una gua

sobre la instalacin del sistema en el servidor.

Apendice B

Documento de Arquitectura

Enterprise On the Go (EGO) Documento de la Arquitectura del Software

Versin

Enterprise on the GO(EGO) Versin: Documento de la Arquitectura de Software Fecha:

Confidencial Ogangi de Venezuela, 2012 Pgina 2 de 17

Historia de Revisin Fecha Versin Descripcin Autor

15/08/2011 1.0 4. Diagrama de casos de uso inicial.

5.1 Modelo de Dominio.

Andrs Mario

30/10/2011 2.0 Andrs Mario

15/11/2011 3.0 Andrs Mario

15/12/2011 4.0 Andrs Mario



Documento de la Arquitectura del Software

1. Introduccin

1.1 Propsito Se mostrar la arquitectura del sistema empleando el Modelo de las 4 + 1 vistas. En

cada una de las vistas se detallarn las decisiones que se tomaron respecto a ellas.

1.2 Alcance El documento presenta una descripcin detallada de la vista lgica y la arquitectura del

sistema, incluyendo diagrama de casos de uso, vista de despliegue, vista de implementacin y vista de datos.

1.3 Definiciones, Siglas, y Abreviaciones

JSP: JavaServer Pages (JSP) es una tecnologa Java que permite generar contenido dinmico para web, en forma de documentos HTML, XML o de otro tipo.

AJAX: Asynchronous JavaScript And XML, refiere a JavaScript asncrono y XML es una tcnica de desarrollo web para crear aplicaciones interactivas o RIA (Rich Internet Applications). Estas aplicaciones se ejecutan en el cliente.

EGO: Enterprise on the GO, sistema de envi masivo de mensajera mediante mltiples plataformas.

1.4 Referencias. Introduccin a la Arquitectura de Software. 1999. Microsoft msdn.

http://www.microsoft.com/spanish/msdn/arquitectura/roadmap_arq/intro.mspx#ESLAC Documento de visin. Documento de ERS.

1.5 Vista Global Este documento se basa en la representacin de arquitectura del sistema, para lo cual

se especifican cada una de las vistas: casos de uso, lgica, de procesos, de despliegue, de implementacin y de datos. Adicionalmente, contiene las restricciones del sistema con respecto a la arquitectura, sus metas, una breve descripcin de las dimensiones del producto, al igual que todo lo relacionado con el desempeo y calidad de plataformas y portabilidad, entre otros.

2. Representacin Arquitectnica Siguiendo la metodologa RUP, se va a implementar el modelo de 4 + 1 vistas de

Kruchten para el sistema EGO. A continuacin se describe en qu consiste cada una de estas vistas. Vista Lgica: Constituye el modelo conceptual del sistema a travs de los subsistemas,

clases e interfaces ms importantes y las relaciones entre estos componentes.

Vista de Proceso: En esta vista se muestra la concurrencia entre los procesos e hilos que conforman el sistema.



Vista de Implementacin: Es un resumen de la organizacin de los entregables y de los cdigos fuentes que se generan a partir de estos.

Vista de Implantacin: Lo constituye la distribucin del software en el hardware, as como

los requisitos funcionales a nivel de escalabilidad, confiabilidad y respuesta.

Vista de Casos de Uso: Est constituida por los casos de uso o escenarios del sistema. Se basa en las 4 vistas anteriores

3. Metas y Restricciones Arquitectnicas

Plataforma Tcnica: El sistema EGO es desarrollado con JSP como lenguaje de programacin y se encuentra en un servidor web, tambin utiliza WebServices. El servidor debe tener en consideracin posibles fallas de electricidad, con el fin que la aplicacin no cese su funcionamiento por culpa de stas.

Seguridad: Dado que distintos tipos de usuarios pueden acceder al sistema, es necesario

establecer niveles de privilegios, y por tanto establecer un sistema de acceso a sesiones mediante un login y un password, tambin tiene que estar implementado en un servidor con https, y nivel de encriptamiento de ciertos datos.

4. Vista de Casos de Uso



5. Vista Lgica

5.1 Visin general

5.2 Paquetes de Diseo Significativos Arquitectnicamente

5.3 Realizaciones de los casos de uso 5.3.1 Iniciar sesin



5.3.2 Registrar usuario

5.3.3 Ver perfil



5.3.4 Modificar Perfil

5.3.5 Listar Usuarios



5.3.6 Eliminar Usuarios

5.3.7 Agregar suscriptor



5.3.8 Cargar suscriptores

5.3.9 Modificar suscriptor



5.3.10 Eliminar suscriptor

5.3.11 Agregar lista



5.3.12 Cargar listas

5.3.13 Modificar listas



5.3.14 Eliminar listas

5.3.15 Enviar SMS



5.3.16 Enviar correo

5.3.17 Cargar Reportes

5.3.18 Cerrar sesin



6. Vista de Procesos N/A

7. Vista de Implantacin

8. Vista de Implementacin

8.1 Vista General



8.2 Capas Componente Archivos JS broadcast.js

credit.js forgotPassword.js list.js index.js main.js profile.js registration.js suscriptor.js login.js logout.js user.js

JSP index.jsp main.jsp user.jsp suscriptor.jsp list.jsp broadcast.jsp credit.jsp profile.jsp

JSP Logico alertSchedulesLoadLogic.jsp broadcastListGroupLogic.jsp broadcastSendLogic.jsp forgotPasswordLogic.jsp languageSetLogic.jsp listAddLogic.jsp listModifyLoadLogic.jsp listModifySaveLogic.jsp loadShortCodesLogic.jsp loginLogic.jsp logoutLogic.jsp profileChangePasswordLogic.jsp profileEditLogic.jsp profileReviewLogic.jsp suscriptorAddLogic.jsp suscriptorDeleteLogic.jsp SuscriptorEditLogic.jsp userLoadLogic.jsp userDeleteLogic.jsp registrationLogic.jsp userLoadLogic.jsp userDeleteLogic.jsp

XML Xml.java



9. Vista de Datos N/A

10. Tamao y Desempeo El desempeo se logro mediante:

1. validaciones en la capa de presentacin. 2. Uso moderado de memoria RAM.

11. Calidad Escalabilidad: El sistema debe poder soportar varias conexiones simultneamente, esto se

logra mediante el soporte de concurrencia del servidor Web.

Confiabilidad y disponibilidad: Es importante que el sistema se mantenga en funcionamiento las 24 horas, todos los das, para ello hay que garantizar que no caiga ante fallas de electricidad, etc. Esto se logra mediante instalaciones en la planta fsica en donde se van ubicar los servidores, as como mediante equipos (UPS, etc) que aseguren que el servicio se mantenga arriba incluso durante una falla elctrica.

Portabilidad: Debido al uso de JSP, JQuery,Ajax, WebServices, el sistema puede ser

migrado fcilmente a cualquier otro servidor en caso de ser necesario, ya que estas herramientas funcionan bajo cualquier sistema operativo.

Modificable y mejor manejo de fallas: El sistema EGO cuenta con una arquitectura basada en capas, lo cual facilita su modificacin y control de fallas.

Extensible: La arquitectura de tres capas tambin permite que el sistema sea extensible. A

la hora de ser necesaria la inclusin de una nueva funcionalidad al sistema, se puede implementar un nuevo componente e integrarlo a la arquitectura sistema.

Seguridad:Ego tiene que estar implementado en un servidor que posea https, y tambien la

informacin critica tiene que estar codifcada con el algoritmo de encriptacion SHA-1.

Apendice C

Especificaciones de Requerimientos

del Sistema

Enterprise on the GO(EGO) Requerimientos del Sistema

Versin 4.0

Enterprise on the Go(EGO) Versin: 4.0 Especificaciones de Requerimientos del Software Fecha: 15/12/2011

Confidencial Ogangi de Venezuela, 2012 Pgina 2

Historia de Revisiones Fecha Versin Descripcin Autor

24/09/2011 1.0 3.0 Casos de uso Inicial Andrs Mario

30/10/11 2.0 Caso de Uso Andrs Mario

15/11/11 3.0 Andrs Mario

15/12/11 4.0 Andrs Mario



Especificaciones de Requerimientos del Software

1. Introduccin 1.1 Alcance

El alcance de este documento es la Especificacin de los Requerimientos de Software para EGO tanto funcionales como no funcionales (especificaciones suplementarias), las cuales se encuentran asociadas a todos Casos de Uso definidos para el mismo

1.2 Definiciones, Acrnimos y Abreviaturas

JSP: JavaServer Pages (JSP) es una tecnologa Java que permite generar contenido dinmico para web, en forma de documentos HTML, XML o de otro tipo.

BD : Base de Datos AJAX: Asynchronous JavaScript And XML, refiere a JavaScript asncrono y XML es

una tcnica de desarrollo web para crear aplicaciones interactivas o RIA (Rich Internet Applications). Estas aplicaciones se ejecutan en el cliente.

EGO: Enterprise on the GO , sistema de envi masivo de mensajera mediante mltiples plataformas.

1.3 Referencias

Documento de Vision del Sistema.

Introduccin a la Arquitectura de Software. 1999. Microsoft msdn. http://www.microsoft.com/spanish/msdn/arquitectura/roadmap_arq/intro.mspx#ESLAC

MOBILETOOLS USER MANUAL v1.7

2. Especificaciones Funcionales 2.1.

ID requerimiento: Nombre del Requerimiento:



R-1 Registrar Usuarios

Descripcin del Requerimiento: 1. El sistema debe registrar los datos de los usuarios. 2. RN: La contrasea suministrada por el usuario debe ser codificada bajo el algoritmo

SHA-1.

3. Estructura de datos : Correo: Este campo es obligatorio, es el correo electrnico del usuario, del tipo

alfanumrico. Contrasea: Este campo es obligatorio, es la contrasea del usuario, del tipo

alfanumrico, longitud mnima de 6, y mxima de 30. Nombre, Este campo es obligatorio, es el nombre del usuario, del tipo alfanumrico,

longitud mxima de 100. Cdigo Zip: Este campo es obligatorio, es el cdigo Zip del usuario, es del tipo

numrico, de longitud mxima de 10. Categora del Negocio: Este campo es obligatorio, el la Categora del tipo de negocio

del usuario, los valores posibles son: Arte y Entretenimiento, Automotriz, Servicios Empresariales y Profesionales, Accesorios y Ropa, Comunidad y Gobierno, Computacin y Electrnica, Construccin y Contratistas, Educacin, Alimentos y Restaurantes, Salud y Medicina, Hogar y Jardinera, Industria y Agricultura, Legal y Financiero, Medios y Comunicaciones, Cuidado Personal y Servicios, Bienes Races, Compras, Recreacin y Deportes, Transporte y Turismo.

Sitio Web: Este campo es obligatorio, es la pagina web del usuario, es del tipo carcter, no tiene longitud mxima.

Direccin: Este Campo No es Obligatorio, es la direccin del usuario, el del tipo carcter y no tiene longitud mxima.

Contacto Principal: Este campo es obligatorio, es el contacto principal del usuario, es del tipo carcter y no tiene longitud mxima.

Contacto Secundario: Este campo no es obligatorio, es el secundario del usuario, es del tipo carcter y no tiene longitud mxima.

Descripcin del negocio: Este campo no es obligatorio, es la descripcin

Tesis Mensajeria Masiva (1)

Documents

Transcript of Tesis Mensajeria Masiva (1)