sistema para control de incentivos a los empleados de dhl express mexico

ESTUDIOS CON RECONOCIMIENTO DE VALIDEZ OFICIAL SEP

NÚMERO 972142 DE FECHA 10 DE JUNIO DE 1997

SISTEMA PARA CONTROL DE INCENTIVOS A LOS EMPLEADOS DE DHL

EXPRESS MÉXICO

TESIS

QUE PARA OBTENER EL TÍTULO DE

INGENIERO EN COMPUTACIÓN

PRESENTA:

EDUARDO CASILLAS MARCA

ASESOR: M.C.C EUGENIO JACOBO HERNÁNDEZ VALDELAMAR

MÉXICO, D.F. ABRIL 2009

II

Esta obra está bajo una licencia Reconocimiento-No comercial-Sin obras derivadas 2.5 México de Creative Commons. Para ver

una copia de esta licencia, visite http://creativecommons.org/licenses/by-nc-nd/2.5/mx o envíe una carta a Creative Commons,

171 Second Street, Suite 300, San Francisco, California 94105, USA.

III

Resumen

Esta tesis trata sobre el desarrollo de un sistema de software dentro del ámbito laboral,

implantado en la empresa de mensajería express DHL.

Con el objetivo de captar nuevos clientes potenciales y aumentar su cartera activa, DHL

implementó un programa de incentivos para sus empleados. A partir del flujo de trabajo de este

programa, se obtuvo un documento de requerimientos que fue la base para emprender el

diseño y construcción de un sistema de automatización y comunicación para el programa a fin

de aumentar su eficiencia y por ende su rentabilidad.

El desarrollo se llevó a cabo siguiendo una configuración de la metodología RUP (Rational

Unified Process), haciendo uso del análisis y diseño orientado a objetos, así como de una serie

de buenas prácticas y patrones de diseño para agilizar el proceso y optimizar la solución.

Este documento plasma el flujo de acontecimientos llevados a cabo con el objetivo de

desarrollar un sistema de software empresarial, experimentados desde el punto de vista del

líder de proyecto e identificando los diversos factores que intervienen en su entorno, como el

cliente y el grupo de trabajo, que determinan el éxito de un buen sistema.

IV

A Dios, por permitirme llegar hasta aquí y seguir adelante.

A mis padres, por ser los mentores de mi vida.

A mis hermanos, por ser mis mejores ejemplos.

A Liz, por enseñarme que los obstáculos se pueden superar, sin importar su magnitud.

A Jack, por su siempre incondicional y desinteresado apoyo.

A mis amigos Chars, Julio, Mario y Robert, por levantarme en cada tropiezo.

A mis compañeros, profesores y personal de la Fundación, por compartir y enriquecer mi

formación académica y profesional.

Mi trabajo y esfuerzo de cada día está dedicado a todos ustedes.

V

Índice de contenido

Introducción ................................................................................................................................................................... 1

Antecedentes ............................................................................................................................................................. 2

Planteamiento del problema ..................................................................................................................................... 3

Objetivo ..................................................................................................................................................................... 4

Propósito ................................................................................................................................................................... 4

Justificación ............................................................................................................................................................... 5

Alcance ...................................................................................................................................................................... 5

Metodología .............................................................................................................................................................. 6

Metodología de investigación ............................................................................................................................... 7

Metodología de desarrollo de la solución ............................................................................................................ 8

Capítulo I Marco Conceptual .......................................................................................................................................... 9

I.1 Objetivo y propósito del trabajo ......................................................................................................................... 10

I.2 Objetivo y propósito del sistema ........................................................................................................................ 10

I.2.1 Desarrollar .................................................................................................................................................. 10

I.2.2 Estudiar ....................................................................................................................................................... 10

I.2.3 Documentar ................................................................................................................................................ 10

I.2.4 Aplicar ......................................................................................................................................................... 11

I.2.5 Establecer .................................................................................................................................................... 11

I.2.6 Dirigir........................................................................................................................................................... 11

I.3 El Proceso de negocio del desarrollo de sistemas de software .......................................................................... 11

I.4 El desarrollo como un sistema ............................................................................................................................ 12

I.5 El contexto alrededor del desarrollo .................................................................................................................. 13

Capítulo II Marco Teórico ............................................................................................................................................. 15

II.1 Sistemas de software ......................................................................................................................................... 16

II.2 Ingeniería de software ....................................................................................................................................... 17

II.2.1 Almacenamiento de información .............................................................................................................. 18

II.3 Metodologías para el desarrollo rápido de aplicaciones ................................................................................... 19

II.4 Análisis y diseño orientado a objetos ................................................................................................................ 20

II.5 Patrones de diseño ............................................................................................................................................ 22

II.5.1 Inyección de dependencias ........................................................................................................................ 23

II.5.2 Objetos de acceso a datos ......................................................................................................................... 24

II.6 Antipatrones de diseño...................................................................................................................................... 25

VI

II.6.1 Otros antipatrones ..................................................................................................................................... 27

II.7 Resumen ............................................................................................................................................................ 27

Capítulo III Marco Contextual ....................................................................................................................................... 29

III.1 Introducción ...................................................................................................................................................... 30

III.2 DHL en el mundo .............................................................................................................................................. 30

III.3 DHL en México .................................................................................................................................................. 31

III.4 Los servicios de DHL .......................................................................................................................................... 32

III.5 Necesidades del cliente .................................................................................................................................... 33

III.6 Los beneficios esperados de la solución ........................................................................................................... 35

Capítulo IV Flujo de Trabajo LEADs y Requerimientos del Sistema .............................................................................. 37

IV.1 La fase de Inicio del proyecto ........................................................................................................................... 38

IV.2 Flujo de trabajo LEADs ...................................................................................................................................... 39

IV.2.1 El pipeline de LEADs .................................................................................................................................. 41

IV.3 Casos de uso iniciales ....................................................................................................................................... 42

IV.4 Requerimientos funcionales del sistema .......................................................................................................... 44

IV.5 Requerimientos no funcionales del sistema..................................................................................................... 46

IV.6 Restricciones ..................................................................................................................................................... 48

IV.7 Resumen ........................................................................................................................................................... 48

Capítulo V Análisis y Diseño de la Solución .................................................................................................................. 50

V.1 La fase de Elaboración del proyecto .................................................................................................................. 51

V.2 Arquitectura del sistema ................................................................................................................................... 52

V.2.1 Arquitectura contextualizada .................................................................................................................... 53

V.3 Diseño de datos ................................................................................................................................................. 54

V.3.1 Diccionario de datos de entrada ................................................................................................................ 55

V.3.2 Diccionario de datos del sistema ............................................................................................................... 59

V.4 Diseño funcional ................................................................................................................................................ 62

V.4.1 Secuencia de negocio ................................................................................................................................ 62

V.4.2 El negocio como una máquina de estados ................................................................................................ 63

V.4.3 Integración de la funcionalidad con la arquitectura del sistema ............................................................... 65

V.4.4 Modelo estático del sistema ...................................................................................................................... 66

V.4.5 Reglas de acceso a la base de datos .......................................................................................................... 68

V.4.6 Reglas de negocio ...................................................................................................................................... 69

V.4.4 Uso de las reglas de negocio en la capa de presentación .......................................................................... 72

VII

V.5 Diseño de Interfaces de usuario ........................................................................................................................ 73

V.5.1 Mapa del sitio ............................................................................................................................................ 73

V.5.2 Plantilla de diseño gráfico .......................................................................................................................... 76

V.6 Resumen ............................................................................................................................................................ 76

Capítulo VI Construcción e Implantación del micrositio LEADs .................................................................................... 78

VI.1 Las fases de Construcción y Transición del proyecto ....................................................................................... 79

VI.2 Plataforma y herramientas de desarrollo ......................................................................................................... 80

VI.2.1 Plataforma de desarrollo Microsoft .NET 2.0 ........................................................................................... 80

VI.2.2 Persistencia de datos con NHibernate ...................................................................................................... 81

VI.2.3 Consistencia de componentes con Spring.NET Framework ..................................................................... 81

VI.2.4 Bitácora de registros con Log4Net ............................................................................................................ 82

VI.2.5 Control de versiones con SubVersion ....................................................................................................... 82

VI.2.6 Otras herramientas de desarrollo ............................................................................................................. 83

VI.3 Organización y despliegue del sistema ............................................................................................................. 84

VI.3.1 El proyecto CentralMedia.Dhl.Leads ........................................................................................................ 85

VI.3.2 El proyecto Web ....................................................................................................................................... 86

VI.4 La construcción del software ............................................................................................................................ 88

VI.5 Esquema de pruebas del sistema ..................................................................................................................... 90

VI.6 Características del servidor y protocolo de instalación .................................................................................... 91

VI.7 Resumen ........................................................................................................................................................... 92

Capítulo VII Resultados ................................................................................................................................................. 94

VII.1 Recopilación de experiencias y resultados ...................................................................................................... 95

VII.2 La experiencia con el cliente ........................................................................................................................... 95

VII.3 Resultados ..................................................................................................................................................... 100

VII.3.1 Versión 1.0 ............................................................................................................................................. 100

VII.3.2 Versión 1.1 ............................................................................................................................................. 101

VII.4 Trabajos a futuro ........................................................................................................................................... 103

VII.4.1 Mejoras al producto .............................................................................................................................. 103

VII.4.2 Extrapolación de buenas prácticas ........................................................................................................ 104

Conclusiones ............................................................................................................................................................... 105

Bibliografía y obras electrónicas................................................................................................................................. 107

Anexos ........................................................................................................................................................................ 110

Anexo A Catálogo de patrones de diseño orientado a objetos .................................................................................. 111

VIII

Patrones de creación ............................................................................................................................................. 112

Patrones estructurales ........................................................................................................................................... 113

Patrones de comportamiento ............................................................................................................................... 116

Anexo B Diccionario de entrada de datos del micrositio ........................................................................................... 120

SUSPECTS ............................................................................................................................................................... 121

DEVELOPMENT LEADS ........................................................................................................................................... 121

CUSTOMERS ........................................................................................................................................................... 122

OPPORTUNITIES ..................................................................................................................................................... 122

ACCOUNTS ............................................................................................................................................................. 123

24 Meses ................................................................................................................................................................ 123

Empleados – Extracto de COMET .......................................................................................................................... 124

Empleados – Recursos Humanos ........................................................................................................................... 124

Anexo C Diccionario de datos del sistema .................................................................................................................. 126

Diagrama Entidad-Relación ................................................................................................................................... 127

PERSONA ................................................................................................................................................................ 128

USUARIO ................................................................................................................................................................ 128

EJECUTIVO ............................................................................................................................................................. 128

EMPLEADO ............................................................................................................................................................. 129

AREA ...................................................................................................................................................................... 129

BITACORA .............................................................................................................................................................. 129

BITACORA_INGRESO .............................................................................................................................................. 129

INDUSTRIA ............................................................................................................................................................. 129

ESTADO_PIPELINE .................................................................................................................................................. 130

ESTADO .................................................................................................................................................................. 130

EVENTO .................................................................................................................................................................. 130

EVENTO_CUENTA .................................................................................................................................................. 130

EVENTO_LEAD ....................................................................................................................................................... 130

CUENTA .................................................................................................................................................................. 131

LEAD ....................................................................................................................................................................... 131

CONFIGURACION ................................................................................................................................................... 132

NOTICIA ................................................................................................................................................................. 132

Anexo D Diagramas del diseño del sistema ampliados .............................................................................................. 133

Diagrama de la máquina de estados ..................................................................................................................... 134

IX

Mapa del sitio ........................................................................................................................................................ 135

Anexo E Solicitud de cambio para la versión 1.1 ........................................................................................................ 136

X

Índice de figuras

Figura 1: Imágenes de la campaña Reactivator: Rise of The Sales. ................................................................................ 3

Figura 2: Fases, Disciplinas e Iteraciones de RUP. .......................................................................................................... 7

Figura 1-1: Proceso de negocio del desarrollo de sistemas de software. .................................................................... 12

Figura 1-2: El proceso de desarrollo de software como un sistema. ........................................................................... 13

Figura 1-3: Factores que influyen en el desarrollo de software. .................................................................................. 14

Figura 2-1: Fases y funciones del proceso de desarrollo de sistemas. ......................................................................... 17

Figura 2-2: Proceso de desarrollo general para una base de datos. ............................................................................ 18

Figura 2-3: Las vistas de UML. ...................................................................................................................................... 21

Figura 2-4: Ejemplo de inyección de dependencias. .................................................................................................... 24

Figura 2-5: Utilización del objeto de acceso a datos. ................................................................................................... 25

Figura 2-6: Ejemplo de un antipatrón de diseño. ......................................................................................................... 26

Figura 2-7: Patrón de diseño de Fachada. .................................................................................................................... 26

Figura 2-8: Resumen del marco teórico. ...................................................................................................................... 27

Figura 3-1: Expansión global de DHL hasta 1988. ......................................................................................................... 30

Figura 4-1: Fases de RUP - Inicio. .................................................................................................................................. 38

Figura 4-2: Flujo de trabajo leads. ................................................................................................................................ 40

Figura 4-3: Pipeline de leads. ........................................................................................................................................ 41

Figura 4-4: Diagrama de casos de uso. ......................................................................................................................... 43

Figura 5-1: Fases de RUP - Elaboración. ....................................................................................................................... 51

Figura 5-2: Representación de una arquitectura multicapa. ........................................................................................ 52

Figura 5-3: Arquitectura contextualizada del sistema. ................................................................................................. 53

Figura 5-4: Esquema de datos de entrada al sistema. .................................................................................................. 55

Figura 5-5: Datos de entrada de SUSPECTS. ................................................................................................................. 56

Figura 5-6: Datos de entrada de DEVELOPMENT LEADS. ............................................................................................. 56

Figura 5-7: Datos de entrada de CUSTOMERS. ............................................................................................................. 57

XI

Figura 5-8: Datos de entrada de OPPORTUNITIES. ....................................................................................................... 57

Figura 5-9: Datos de entrada de ACCOUNTS. ............................................................................................................... 58

Figura 5-10: Datos de entrada del archivo 24 meses. .................................................................................................. 58

Figura 5-11: Datos de entrada de empleados desde COMET. ...................................................................................... 59

Figura 5-12: Datos de entrada de empleados por RH. ................................................................................................. 59

Figura 5-13: Diagrama entidad-relación de la BD del sistema. .................................................................................... 60

Figura 5-14: Diagrama de secuencia del programa leads. ............................................................................................ 62

Figura 5-15: Diagrama de estados de leads. ................................................................................................................. 64

Figura 5-16: Integración de la funcionalidad con la arquitectura del sistema. ............................................................ 66

Figura 5-17: Diagrama de clases. .................................................................................................................................. 67

Figura 5-18: Interfaces de objetos de acceso a datos. ................................................................................................. 68

Figura 5-19: Interfaz del DAO para entidades. ............................................................................................................. 69

Figura 5-20: Plantilla para el reporte gráfico de leads. ................................................................................................ 70

Figura 5-21: Interfaces de servicios de la capa de negocio. ......................................................................................... 73

Figura 5-22: Mapa del sitio. .......................................................................................................................................... 74

Figura 5-23: Diseño gráfico de la plantilla del micrositio. ............................................................................................ 77

Figura 6-1: Fases de RUP – Construcción. ..................................................................................................................... 79

Figura 6-2: Fases de RUP - Transición. .......................................................................................................................... 80

Figura 6-3: Estructura de despliegue del proyecto centralmedia.Dhl.Leads. ............................................................... 85

Figura 6-4: Estructura de despliegue del proyecto Web. ............................................................................................. 87

Figura 7-1 Diagrama entidad-relación de la versión 1.1. ............................................................................................ 102

XII

Índice de tablas

Tabla 2-1: Clasificación de los patrones de diseño. ...................................................................................................... 23

Tabla 3-1: La red de DHL. .............................................................................................................................................. 31

Tabla 4-1: Requerimientos funcionales del sistema. .................................................................................................... 44

Tabla 4-2: Requerimientos de usabilidad del sistema. ................................................................................................. 46

Tabla 4-3: Requerimientos de confiabilidad del sistema. ............................................................................................ 47

Tabla 4-4: Requerimientos de seguridad del sistema. ................................................................................................. 47

Tabla 4-5: Requerimientos de desempeño del sistema. .............................................................................................. 47

Tabla 4-6: Requerimientos de documentación del sistema. ........................................................................................ 48

Tabla 4-7: Actividades realizadas en la fase de diseño. ................................................................................................ 49

Tabla 5-1: Actividades realizadas en la fase de Elaboración. ....................................................................................... 77

Tabla 6-1: Actividades realizadas en la fase de Construcción. ..................................................................................... 93

Tabla 6-2: Actividades realizadas en la fase de Transición. .......................................................................................... 93

Introducción

2

Antecedentes

Central Media es una agencia de comunicación que por medio de diversas herramientas ofrece

soluciones para actividades de comunicación interna, publicidad ATL (Above The Line) y BTL

(Below The Line)1 y capacitación. Cuenta con cuatro divisiones de negocio.

• Diseño gráfico, donde se desarrolla diseño editorial, imagen corporativa, material P.O.P.

(Point Of Purchase, tales como banners, posters y etiquetas) y otros anuncios

publicitarios dirigidos a medios masivos. Tiene clientes como Sony, el Tecnológico de

Monterrey, Nextel, Lancôme y Disney.

• Producción Audiovisual se enfoca en la producción de audio, video, fotografía y

modelado 3D. Sus clientes son AIWA, Banco Azteca y ONU entre otros.

• En Elaboración de Contenidos se genera contenido para CD-ROM, páginas web, sistemas

y autoría de DVDs, guiones para radio y televisión, medios impresos, campañas de

comunicación y documentación corporativa. Tiene clientes como Profuturo, IBOPE,

Grupo IUSA y Televisa.

• Desarrollo Interactivo, donde se realiza la producción de CD-ROMs, páginas web,

autorías de DVD y sistemas. Cuenta con clientes como DELL, Heineken, L’Oreal, Parisina y

la Fundación Alejo Peralta. Dentro de esta área fue desarrollado el proyecto que en este

trabajo se describe.

Desarrollo Interactivo ha tenido diversos contactos con DHL. El más reciente fue el desarrollo de

un sistema para automatizar el flujo de trabajo del programa Reactivator (Figura 1 [MAVERICK,

2008]), diseñado como parte de una campaña de ventas interna para reactivar cuentas de

1 El término ATL hace referencia a la publicidad sobre medios masivos de comunicación (TV y radio, entre otros),

mientras que BTL se refiere a la publicidad sobre medios no masivos (congresos y promociones, entre otros).

3

clientes inactivas por más de seis meses, donde el personal del área de Televentas más efectivo

para dichos fines es recompensado con productos promocionales y reconocimiento público.

Figura 1: Imágenes de la campaña Reactivator: Rise of The Sales.

DHL confía en Central Media por esta y otras experiencias exitosas, así como los sistemas que

han sido desarrollados por la agencia y publicados con fines de promoción para sus clientes.

Planteamiento del problema

La empresa de mensajería DHL Express maneja, a nivel mundial, un programa de incentivos

basado en comisiones para sus empleados que consiste en lo siguiente: cualquier empleado de

esta empresa, y particularmente los repartidores (denominados couriers) pueden proponer

nuevos clientes para dicha empresa a través de un formato conocido como LEAD format o

simplemente LEAD2, donde anotan tanto los datos del prospecto como los suyos, y lo entregan

al área de Televentas. Los LEADs son registrados en el ERP3 de DHL (llamado COMET) e ingresan

en un proceso conocido como pipeline de LEADs, que va desde la primera llamada que se realiza

desde el área de Televentas hacia el prospecto, hasta que se abre la cuenta o el prospecto

rechaza la propuesta. En caso de que se abra la cuenta y el cliente realice cinco envíos o el

2 El término LEAD se obtiene del vocablo en inglés para ventas Sales Lead, que se traduce como Cliente Potencial. A

lo largo del documento se utiliza la palabra LEAD al igual que se utilizó durante el proyecto por ser la expresión estilada en DHL para referirse al formato de inscripción al programa. 3 Un ERP (Enterprise Resource Planning) es un sistema de información que integra diversos procesos relacionados a

las operaciones de una empresa.

4

equivalente por una facturación de $1,000.00 en el transcurso de un mes (con lo que se

considera un LEAD exitoso), DHL paga al empleado que ingresó el LEAD un incentivo de $200.00.

El proceso en sí no es muy complicado, sin embargo, en México, a pesar de que los LEADs son

registrados en COMET para mantenerlos en la base de datos, el sistema no incluye un proceso

para manejar el programa de incentivos citado anteriormente, y por lo tanto, todo el proceso el

realizado a mano.

Esto ha sido causa de varios problemas como son:

• Errores al discernir a qué empleados pagar y cuáles no.

• Lentitud al realizar cálculos.

• Incertidumbre al responder a los empleados cuando preguntan por qué sus LEADs no

han sido pagados.

Todo ello se resume en que los empleados han perdido la confianza en el programa y por lo

tanto, han dejado de ingresar LEADs, privando a DHL de una gran fuente de clientes recurrentes.

Contribución para optimizar el programa de incentivos.

Plantear una solución requiere un conocimiento profundo del flujo de trabajo, que únicamente

se puede obtener de entrevistas con el personal de DHL, dado que no se encuentra

debidamente documentado. Implementarla, requerirá la utilización de recursos para desarrollos

a nivel empresarial.

Objetivo

Desarrollar un sistema basado en web para automatizar los procesos de administración de

incentivos para los empleados de la empresa de mensajería DHL Express México, aplicando una

metodología de desarrollo orientada a objetos y reutilización de componentes para lograr un

resultado rápido y expedito.

Propósito

• Estudiar, documentar y, en su caso corregir el flujo de trabajo referente al programa de

incentivos LEADs.

5

• Aplicar una configuración de baja ceremonia del proceso RUP para mostrar su utilización

en el desarrollo de un sistema empresarial real.

• Establecer una arquitectura ejecutable multicapa basada en marcos de trabajo que

permita la modularización del sistema e impulse la reutilización de sus componentes.

• Dirigir los esfuerzos de un grupo de trabajo hacia la realización de un sistema a la

medida para cubrir una necesidad específica.

Justificación

La solución planteada para cubrir la necesidad de DHL consiste en un micrositio para incluir en

la Intranet de la empresa, que automatice el flujo de trabajo referente al programa de

incentivos LEADs.

El sistema estará basado en una lista de requerimientos entregada por la empresa de

mensajería, donde se plantean los puntos que como mínimo debe cubrir el sistema para lograr

su objetivo, además de los beneficios que se obtendrán mediante su utilización.

Este software resolverá una necesidad específica de la empresa. Sin embargo, sus componentes

podrán ser reutilizados en futuros desarrollos por parte del proveedor gracias a la

modularización que se le dará.

Como tal, el trabajo incluirá los aspectos técnicos de la aplicación, pero se enfocará a describir

una experiencia real de acercamiento con el cliente (en este caso DHL), desde el comienzo del

desarrollo, pasando por los acontecimientos más importantes e influyentes para la solución

propuesta y terminando con un análisis de dicho software para explorar sus capacidades y

determinar su reusabilidad para otros proyectos.

Alcance

Se encuentra dentro del alcance de este proyecto el completo desarrollo de un sistema de

información para automatizar el flujo de trabajo comentado anteriormente. Dicho sistema

deberá ser implementado y montado en un servidor dentro de la Intranet de DHL. Alcances y

restricciones puntuales de la herramienta a desarrollar serán definidos por el cliente en etapas

tempranas del desarrollo.

6

Se encuentra dentro del alcance del trabajo presentar al lector los procedimientos y tecnologías

empleados para el desarrollo de un sistema de nivel empresarial real, de manera que la

experiencia adquirida en este trabajo pueda ser consultada y aprovechada por los estudiantes

de la Fundación para el enriquecimiento de su formación profesional.

Metodología

Para la realización de este trabajo de tesis se llevará a cabo en primer lugar el desarrollo del

sistema mismo y a continuación se elaborará el documento.

El desarrollo del sistema incluirá las siguientes tareas:

• Reuniones con el cliente, dentro de sus oficinas, con los siguientes objetivos:

o Levantamiento de requerimientos.

o Análisis del software.

o Presentación de las propuestas de solución.

o Instalación en servidores de ambiente de pruebas y producción.

• Reuniones con el cliente, dentro de la consultoría, con el objetivo de realizar pruebas en

ambiente de desarrollo.

• Reuniones con el equipo de trabajo, dentro de la consultoría, con los siguientes

objetivos:

o Análisis de requerimientos.

o Análisis de software.

o Desarrollo de la arquitectura.

o Integración de resultados.

• Construcción del software, desglosado en las siguientes actividades:

o Construcción de la base de datos.

o Construcción de la capa de acceso a datos.

o Construcción de la capa de negocio.

o Construcción de la capa de vista o presentación.

Por otra parte, la elaboración del documento de tesis incluirá las siguientes:

7

• Integración de los artefactos generados durante el proceso de desarrollo del sistema.

• Investigación documental concerniente al desarrollo de sistemas de software, utilizando

libros impresos y referencias electrónicas (e-books y sitios web).

• Redacción del documento.

Metodología de investigación

La metodología de investigación que se utilizará para el desarrollo del proyecto será:

• Documental, ya que se deberá revisar y estudiar la documentación existente acerca del

programa de incentivos que tiene el personal de DHL.

• De campo, ya que gran parte de la información que se requiere no se encuentra

documentada y existe la necesidad de obtenerla directamente de los trabajadores de la

empresa de mensajería.

• Aplicada, ya que, luego de recabar la información necesaria, se aplicarán los procesos en

un sistema de información que será implementado en los servicios del cliente.

Figura 2: Fases, Disciplinas e Iteraciones de RUP.

8

Metodología de desarrollo de la solución

El sistema será desarrollado bajo la metodología RUP (Rational Unified Process).

RUP es un proceso de ingeniería de software bien definido y bien estructurado. Define quién es

responsable de qué, y cómo y cuándo se deben realizar determinadas tareas. Asimismo, provee

una estructura bien definida para el ciclo de vida de los proyectos de software, articulando

claramente hitos esenciales y puntos de decisión.

La metodología RUP divide el ciclo de vida de un proyecto de software en cuatro fases con flujos

de trabajo iterativos, como se muestra en la Figura 2 [KREBS, 2008].

Capítulo I

Marco Conceptual

10

“No tiene ningún sentido ser preciso cuando ni siquiera sabes de lo que estás hablando.”

John Von Neumann (1903 – 1957)

I.1 Objetivo y propósito del trabajo

Plasmar los acontecimientos más relevantes sucedidos durante el proceso de desarrollo de un

sistema de software, relatando su evolución a través de las diversas fases de la metodología

planteada.

En el documento se describen los factores y el conjunto de prácticas y herramientas utilizado

para alcanzar los objetivos del sistema, puntualizados a continuación.

I.2 Objetivo y propósito del sistema

I.2.1 Desarrollar

Desarrollar un sistema de información implica un proceso estructurado que va desde la

concepción de la idea, pasa por las etapas de análisis, diseño, construcción (o programación) y

pruebas y termina con la implementación del mismo.

Este capítulo, a partir del punto número tres, muestra los factores que en mayor medida

influyen en este proceso.

I.2.2 Estudiar

El flujo de trabajo del programa de incentivos será cuidadosamente analizado para lograr su

correcta comprensión y poder llevar a cabo un desarrollo que beneficie al cliente.

I.2.3 Documentar

El programa es conocido por los empleados de DHL y coordinado por personas que mantienen

la información sobre el flujo del mismo en su cabeza. Sin embargo, no existen documentos

11

referentes al mismo, por lo que se deberán generar los archivos necesarios para su explicación y

entendimiento.

I.2.4 Aplicar

El proceso de desarrollo unificado de software (RUP) define una extensa cantidad de artefactos

y actividades. Sin embargo, de estas se deben adoptar únicamente las que sean relevantes en

cada proyecto determinado, de manera que la metodología ayude a agilizar el proceso y no a

entorpecerlo. Aplicar una configuración de baja ceremonia de RUP fomenta la producción de

software funcional en vez de crear una documentación excesiva. [KROLL, 2003]

I.2.5 Establecer

Muchos riesgos en un proyecto están asociados con la arquitectura, especialmente cuando se

desarrolla la primera generación de una aplicación [KROLL, 2003]. Por ello, es necesario

desarrollar una arquitectura ejecutable bien estructurada que facilite la construcción del

sistema.

I.2.6 Dirigir

El desarrollo será llevado a cabo en conjunto por un grupo de trabajo, encabezado por un líder

de proyecto, que deberá guiar a los integrantes del equipo, encaminando sus intenciones y

esfuerzos hacia el logro de los objetivos del sistema.

I.3 El Proceso de negocio del desarrollo de sistemas de software

Como proceso de negocio (Figura 1-1) el desarrollo de sistemas de software:

• Tiene una meta, que consiste en la automatización de procesos para hacerlos más

eficientes y eficaces.

• Tiene entradas específicas, un requerimiento o una necesidad.

• Tiene una salida específica, que consiste en una solución informática.

• Utiliza recursos, como los recursos humanos, financieros y tecnológicos del proveedor.

• Tiene una serie de actividades que deben ser realizadas en un orden específico, conocida

como metodología de desarrollo.

• Puede afectar a más de una unidad organizacional.

Figura 1-1:

• Crea valor para el cliente, optimizando sus propios recursos a través de la solución

• Tiene un evento generador, un contrato que se da entre cliente y proveedor.

I.4 El desarrollo como un sistema

Este proceso de negocio puede a su vez, visualizarse como

negra que a partir de ciertas entradas genera una salida. En este caso, las entradas involucran,

aunque no están limitadas a:

• Un flujo de trabajo, es decir, una parte del proceso de negocio del cliente que se

requiere automatizar.

• Información sobre sistemas que utiliza el cliente y que puedan influir sobre la realización

del software. Estos pueden ser internos o externos.

• Bases de datos existentes a las que se deba tener acceso mediante la solución.

• Una especificación técnica que complementa la información sobre el flujo de trabajo,

indicando las necesidades del cliente para construir el software. Esta puede basarse en

políticas o limitaciones tecnológicas.

• El contexto del cliente, que puede afectar al desarrollo mediante sus decisiones.

• El contexto del proveedor, con el mismo impacto que el contexto del cliente.

: Proceso de negocio del desarrollo de sistemas de software.

Crea valor para el cliente, optimizando sus propios recursos a través de la solución

Tiene un evento generador, un contrato que se da entre cliente y proveedor.

El desarrollo como un sistema

Este proceso de negocio puede a su vez, visualizarse como un sistema (Figura 1


jo de trabajo, es decir, una parte del proceso de negocio del cliente que se

Información sobre sistemas que utiliza el cliente y que puedan influir sobre la realización

del software. Estos pueden ser internos o externos.

s existentes a las que se deba tener acceso mediante la solución.

Una especificación técnica que complementa la información sobre el flujo de trabajo,


aciones tecnológicas.

El contexto del cliente, que puede afectar al desarrollo mediante sus decisiones.

El contexto del proveedor, con el mismo impacto que el contexto del cliente.

12

Crea valor para el cliente, optimizando sus propios recursos a través de la solución

Tiene un evento generador, un contrato que se da entre cliente y proveedor.

Figura 1-2); una caja


jo de trabajo, es decir, una parte del proceso de negocio del cliente que se

Información sobre sistemas que utiliza el cliente y que puedan influir sobre la realización

s existentes a las que se deba tener acceso mediante la solución.

Una especificación técnica que complementa la información sobre el flujo de trabajo,


El contexto del cliente, que puede afectar al desarrollo mediante sus decisiones.

El contexto del proveedor, con el mismo impacto que el contexto del cliente.

Figura 1-

Las entradas se juntan para dar lugar al proceso de desarrollo de software, que involucra la

metodología a seguir, la arquitectura tecnológica (estrechamente relacionada a la especificación

técnica) necesaria para dicho seguimiento y

optimizar el proceso.

I.5 El contexto alrededor del desarrollo

Los contextos del cliente y proveedor están dados por una serie de factores que influyen en

desarrollo del software (Figura 1

El cliente aporta una serie de requerimientos que engloba sus necesidades al principio del

proyecto y se convierte en el guía para que el proveedor construya el software adecuado

cubrir dichos requerimientos.

Por su parte, dentro del proveedor, el líder de proyecto da seguimiento a los lineamientos del

cliente, aportando sus ideas y conocimientos y dirigiendo a un grupo de trabajo que ejecuta las

Metodología

Flujo de trabajoSistemas

internos y externos

-2: El proceso de desarrollo de software como un sistema.



técnica) necesaria para dicho seguimiento y una serie de buenas prácticas necesarias para

El contexto alrededor del desarrollo

Los contextos del cliente y proveedor están dados por una serie de factores que influyen en

Figura 1-3).


proyecto y se convierte en el guía para que el proveedor construya el software adecuado

cubrir dichos requerimientos.



Solución informática

Arquitectura Buenas prácticas

internos y Bases de datosEspecificación

técnicaContexto del

cliente

13



una serie de buenas prácticas necesarias para

Los contextos del cliente y proveedor están dados por una serie de factores que influyen en el


proyecto y se convierte en el guía para que el proveedor construya el software adecuado para



Buenas prácticas

Contexto del proveedor

instrucciones del líder. Este

empresa y decisiones del jefe del líder de proyecto.

Figura 1

Durante los próximos capítulos del presente

proceso aplicado al proyecto de automatización del programa de incentivos LEADs

instrucciones del líder. Este contexto puede estar limitado por la tecnología, políticas de la

empresa y decisiones del jefe del líder de proyecto.

Figura 1-3: Factores que influyen en el desarrollo de software.

los próximos capítulos del presente documento, se plasma el seguimien

de automatización del programa de incentivos LEADs

14

contexto puede estar limitado por la tecnología, políticas de la

el seguimiento de este

de automatización del programa de incentivos LEADs.

Capítulo II

Marco Teórico

16

“¿Para qué repetir los errores antiguos, habiendo tantos errores nuevos que cometer?”

Bertrand Russell (1872 – 1970)

II.1 Sistemas de software

El diccionario de la lengua de la Real Academia Española define un sistema como un conjunto de

cosas que relacionadas entre sí ordenadamente contribuyen a determinado objeto.

Contextualizando esta definición, es posible decir que un sistema informático es un conjunto

estructurado de unidades de hardware y de software que se agrupan para llevar a cabo un

proceso o flujo de trabajo determinado.

El hardware proporciona el equipo necesario para que la operación se realice, mientras que el

software define los pasos a seguir de dicha operación. Cuando el desarrollo implica únicamente

este último aspecto, se habla de un sistema de software.

El desarrollo de sistemas de software es una práctica multidisciplinaria que puede ser llevada a

cabo bajo diversos enfoques a diferentes niveles.

Desde el punto de vista metodológico, debe considerarse el proceso de ingeniería de software

que se seguirá para obtener un producto de calidad apegado a las necesidades del cliente y el

tipo de metodología que se utilizará; desde el punto de vista de la elaboración del sistema, se

deben tomar en cuenta el tipo de arquitectura con que será desarrollado el software y los

patrones de diseño a seguir; desde el punto de vista de la construcción del sistema, se debe

tomar en cuenta la tecnología que será utilizada para ejecutar la arquitectura y el diseño

planteado en el producto final.

Lo anterior, junto con los enfoques administrativos, de ventas y logísticos, entre otros,

constituye el proceso de desarrollo de un sistema. Cada uno de los puntos mencionados, que

son los que nos conciernen en este proyecto, será explicado a nivel teórico en este capítulo.

17

II.2 Ingeniería de software

El Instituto de Ingenieros Eléctricos y Electrónicos, conocido como IEEE por sus siglas en inglés

(Institute of Electrical and Electronic Engineers) define la ingeniería de software como la

aplicación de un acercamiento sistematizado, disciplinado y cuantificable al desarrollo,

operación y mantenimiento del software [IEEE, 1990]. Este acercamiento nos ayudará a resolver

problemas de la vida real haciendo uso de habilidades de análisis y síntesis para transformar las

necesidades de los usuarios en requerimientos, y nos dará la pauta para transformar dichos

requerimientos en el diseño de un sistema de software, para finalmente implementarlo en un

producto que podrá ser probado e instalado para cubrir las necesidades del usuario.

El periodo durante el cual el producto de software es concebido, diseñado, implementado,

utilizado y finalmente se vuelve obsoleto, se conoce como ciclo de vida del software.

Conceptualmente, el ciclo de vida incluye fases de concepto, requerimientos, diseño,

implementación, pruebas, instalación, operación y mantenimiento y en algunos casos,

obsolescencia.

Figura 2-1: Fases y funciones del proceso de desarrollo de sistemas.

Como ejemplo, en la Figura 2-

software de gran escala siguiendo un proceso de ingeniería. El proyecto mostrado comienza con

el estudio e implementación del

vez en unidades. Concluido el diseño, se procede al desarrollo de las unidades, que conforman

los componentes, que en conjunto satisfacen los requerimientos del sistema que será liberado.

II.2.1 Almacenamiento de información

Una de las tareas básicas que todo sistema de información realiza es el almacenamiento de

datos. Esta por lo general se efectúa a través de una o varias bases de datos

estructurados de datos relevantes a

Independientemente de la metodología utilizada para el desarrollo del sistema, es necesario

llevar a cabo el desarrollo de la base de datos, que en general se divide en las cuatro fases

mostradas en la Figura 2-2 [CHURCHER, 2007

Figura 2-

La ventaja del acercamiento que será utilizado para el desarrollo de

permite encajar directamente las fases de este proceso.

-1 [NAUR, 1969] se observa la línea de tiempo para un proyecto de


el estudio e implementación del diseño del sistema, que lo divide en componentes, y estos a su



1 Almacenamiento de información


datos. Esta por lo general se efectúa a través de una o varias bases de datos

estructurados de datos relevantes a una solución específica.



CHURCHER, 2007]

-2: Proceso de desarrollo general para una base de datos.

La ventaja del acercamiento que será utilizado para el desarrollo de este proyecto es que

permite encajar directamente las fases de este proceso.

18

[NAUR, 1969] se observa la línea de tiempo para un proyecto de


diseño del sistema, que lo divide en componentes, y estos a su




, es decir, conjuntos



este proyecto es que

19

II.3 Metodologías para el desarrollo rápido de aplicaciones

Las metodologías para Desarrollo Rápido de Aplicaciones (RAD por sus siglas en inglés: Rapid

Application Development) ofrecen distintos tipos de acercamiento para la Ingeniería de

Software, es decir, establecen una serie de lineamientos para agilizar el desarrollo de software.

Las metodologías clasificadas en este ámbito se caracterizan por ser:

• Incrementales, es decir, que se enfocan en generar pequeños ejecutables del software

en ciclos cortos para obtener una retroalimentación rápida y continua.

• Cooperativos, incentivando el trabajo en conjunto entre el cliente y el desarrollador, así

como administrando el trabajo en equipo.

• Directos, ya que son fáciles de aprender y modificar por su buena documentación.

• Adaptativos, pues permiten cambios en el desarrollo de software, incluso de último

momento.

El objetivo es implementar soluciones simples que reduzcan la carga de documentación

necesaria y la complejidad para dar seguimiento al ciclo de vida del software, en el menor

tiempo posible, a través de la definición de tres elementos clave:

• Procesos, que son las fases del ciclo de vida.

• Roles y responsabilidades de cada integrante del equipo de desarrollo.

• Prácticas, es decir, actividades para cada uno de los roles definidos.

En la actualidad, existen varias metodologías RAD, como Extreme Programming (XP), SCRUM y

RUP, y muchas más surgen y son desechadas rápidamente. Sin embargo, gran parte de los

desarrolladores de software se muestra escéptica a la aplicación de estos métodos, ya que son

demasiado mecanísticos para ser utilizados en detalle [ABRAHAMSSON, 2002]. Es por ello que

cada desarrollador debe elegir una configuración de la metodología, utilizando solamente las

partes de la misma que agreguen un valor significativo al proyecto. A pesar de esto no existe

ninguna técnica o procedimiento para el practicante que permita elegir una metodología para

obtener los mayores beneficios en determinadas circunstancias [ABRAHAMSSON, 2002], por lo

20

que dicha elección dependerá de la experiencia y conocimiento sobre cada metodología de la

persona encargada del proyecto.

II.4 Análisis y diseño orientado a objetos

Durante los últimos 20 años, uno de los paradigmas más populares para llevar a cabo las fases

de análisis y diseño de un sistema ha sido la orientación a objetos, que propone modelar la

realidad a través de un conjunto de objetos que interactúan entre sí.

En este ámbito, un objeto es una entidad discreta, con límites bien definidos y con identidad,

que encapsula el estado y comportamiento [RUMBAUGH, 2000]. Dicho de otra manera, un

objeto es una entidad del mundo real, ya sea física o meramente conceptual, que se compone

de tres elementos básicos.

• Estado, que define las propiedades de un objeto, como el color, el tamaño y la

capacidad.

• Comportamiento, que representa las acciones que el objeto puede realizar, como

moverse, procesar y comer.

• Identidad, que cualifica a un objeto como único, distinguiéndolo de los demás, incluso

cuando estos tengan el mismo estado y comportamiento.

Los objetos pueden agruparse por propiedades en común y comportamiento similar (métodos)

en lo que se conoce como clases.

Una clase es una descripción de un conjunto de objetos que comparten los mismos atributos,

operaciones, métodos, relaciones y comportamiento [RUMBAUGH, 2000], es decir, la

abstracción de una entidad, que define sus características. Se puede pensar en una clase como

un molde, donde cada objeto es instancia de una clase en particular.

Para describir modelos orientados a objetos, se tiene el Lenguaje de Modelado Unificado,

conocido como UML por sus siglas en inglés: Unified Modeling Language, un lenguaje de

modelado visual que se usa para especificar, visualizar, construir y documentar artefactos de un

sistema de software [RUMBAUGH, 2000]. UML permite describir un mismo modelo desde

diferentes vistas que presentan información relevante para necesidades específicas. Entre estas

vistas encontramos:

• La vista estática, que describe las clases del modelo y sus relaciones, sin tomar en

cuenta el comportamiento

• La vista de casos de uso

los usuarios u otros sistemas, llamados

• La vista de la máquina de estados

sus estados y las transacciones entre los mismos en un cierto periodo

• La vista de actividades

la descripción de la vista de la máquina de estados

• La vista de interacción

objetos que desempeñan distintos roles dentro de las interacciones del sistema

2-3 D).

• La vista física, que modela la estructura del sistema desde un enfoque de

implementación, definiendo la organización de sus componentes

• La vista de gestión del modelo

conjunto de paquetes

que presentan información relevante para necesidades específicas. Entre estas

, que describe las clases del modelo y sus relaciones, sin tomar en

cuenta el comportamiento (Figura 2-3 A).

La vista de casos de uso, que modela la funcionalidad del sistema y su interacción con

los usuarios u otros sistemas, llamados actores (Figura 2-3 B).

La vista de la máquina de estados, que describe el ciclo de vida de un objeto a través de

sus estados y las transacciones entre los mismos en un cierto periodo

La vista de actividades, que describe el flujo de una operación concreta, particularizando

la descripción de la vista de la máquina de estados (Figura 2-3 C).

La vista de interacción, que muestra el flujo de control del modelo a través de diversos

objetos que desempeñan distintos roles dentro de las interacciones del sistema

, que modela la estructura del sistema desde un enfoque de

implementación, definiendo la organización de sus componentes (Figura 2

La vista de gestión del modelo, que describe la organización del modelo como un

(Figura 2-3 F).

Figura 2-3: Las vistas de UML.

21

que presentan información relevante para necesidades específicas. Entre estas

, que describe las clases del modelo y sus relaciones, sin tomar en

ue modela la funcionalidad del sistema y su interacción con

, que describe el ciclo de vida de un objeto a través de

sus estados y las transacciones entre los mismos en un cierto periodo (Figura 2-3 C).

, que describe el flujo de una operación concreta, particularizando

, que muestra el flujo de control del modelo a través de diversos

objetos que desempeñan distintos roles dentro de las interacciones del sistema (Figura

, que modela la estructura del sistema desde un enfoque de

Figura 2-3 E).

, que describe la organización del modelo como un

22

Cada vista es representada por un diagrama distinto que, por estar basado en una

especificación común, es fácil de entender por especialistas y usuarios finales.

II.5 Patrones de diseño

Para facilitar la reutilización de estrategias y diseños orientados a objetos que han sido exitosos,

existen los llamados patrones de diseño. Estos patrones definen lineamientos a seguir para dar

solución a algún problema común de diseño de software. Cada patrón describe un problema que

ocurre una y otra vez en nuestro ambiente, y luego describe la base de la solución a ese

problema, de tal manera que pueda ser usado un millón de veces nuevamente, sin tener que

hacerlo de la misma manera dos veces [GAMMA, 1995]. Sin embargo los patrones de diseño no

definen bibliotecas de clases o código específico para utilizar dentro de las implementaciones de

los sistemas, por lo cual, lo que fomentan no es la reutilización de código, sino de la solución

específica para un problema específico, ya que cada patrón es desarrollado con base en la

experiencia de haber demostrado su efectividad para resolver problemas comunes de diseño

orientado a objetos.

En general, los patrones de diseño se definen mediante plantillas que describen los siguientes

elementos:

• Nombre del patrón

• El problema o la situación donde es aplicable el patrón.

• La solución al problema planteado, descrita en prosa, con diagramas y/o pseudocódigo.

• Las consecuencias positivas o negativas que pueda tener la utilización del patrón.

Cada patrón es independiente de los demás, pero pueden relacionarse y actuar en conjunto

para conformar el diseño de un sistema completo.

Los patrones pueden clasificarse de acuerdo a su propósito y de acuerdo a su ámbito, como se

muestra en la Tabla 2-1.

Los patrones mostrados en la tabla fueron los primeros en ser documentados, a mediados de la

década de los 90. En el anexo A se encuentra una descripción de los patrones mencionados

conforme a la plantilla especificada anteriormente. A partir de entonces, nuevos patrones han

23

surgido para ayudar a los desarrolladores de software. Dos de estos nuevos patrones serán

utilizados durante el proyecto: la inyección de dependencias y los objetos de acceso a datos. En

las siguientes secciones se explicarán estos patrones, dada su importancia en el trabajo.

Tabla 2-1: Clasificación de los patrones de diseño.

Propósito

Patrones de creación Patrones

estructurales Patrones de

comportamiento

Ámbito

Clase

Fábrica de métodos (Factory Method)

Adaptador (Adapter) Intérprete (Interpreter)

Plantilla de métodos (Template

Method)

Objeto

Fábrica abstracta (Abstract Factory)

Adaptador (Adapter) Cadena de mando (Chain of

Responsibility)

Constructor (Builder) Puente (Bridge) Instrucción (Command)

Prototipo (Prototype) Compuesto (Composite) Iterador (Iterator)

Singular (Singleton) Decorador (Decorator) Mediador (Mediator)

Fachada (Façade) Memoria (Memento)

Peso ligero (Flyweight) Observador (Observer)

Representante (Proxy) Estado (State)

Estrategia (Strategy)

Visitante (Visitor)

II.5.1 Inyección de dependencias

El patrón de Inyección de Dependencias (DI por sus siglas en inglés Dependency Injection, o en

ocasiones también llamado Inversion of Control IoC) intenta disolver las dependencias entre

objetos para fomentar la reusabilidad de diseños e incluso de código fuente.

La solución radica en resolver las dependencias de cada clase (atributos) generando los objetos

cuando se arranca la aplicación y luego inyectarlos en los demás objetos que los necesiten a

través de métodos set o bien a través del constructor, pero estos objetos se instancian una vez,

se guardan en una factoría4 y se comparten por todos los usuarios [GONZALEZ, 2006].

De esta manera, si la clase A tiene como atributo un objeto de la clase B, y la clase B requiere

muchas sentencias para su inicialización, diferentes para cada una de sus instancias, la lógica de

inicialización de B queda fuera de A, permitiendo que sea utilizada por ella misma y otras clases,

como muestra la Figura 2-4.

4 Se utiliza el término factoría, citando al autor original, para referirse a una fábrica de objetos.

24

Figura 2-4: Ejemplo de inyección de dependencias.

En este ejemplo, las clases A, C y D dependen de la clase B. Su lógica de inicialización queda en

un archivo de configuración externo, donde a su vez se inicializan las clases dependientes, que

pueden ser inyectadas en otras clases de ser necesario. Este servicio es manipulado en el

proyecto del micrositio con la plataforma Spring.NET Framework.

Este patrón debe ser utilizado con cuidado, ya que si las clases inyectadas no se utilizan en

ningún momento, es posible que se tengan instancias de objetos que únicamente ocupen

memoria innecesaria en el host del sistema.

II.5.2 Objetos de acceso a datos

Por lo general, cuando un ingeniero de software se encuentra desarrollando el diseño de un

sistema que requiere persistencia de datos, se encuentra con la problemática de acceso a datos.

La fuente de información puede ser un archivo de texto plano, una base de datos relacional, una

base de datos orientada a objetos, un archivo separado por comas, etc. Desafortunadamente la

interfaz de acceso ofrecida por cada tipo de fuente es diferente, incluso si son bases de datos

del mismo tipo, ya que depende del proveedor. Es común que esta restricción influya en el

diseño del sistema, sobre todo si este interactúa con más de una fuente de información, de

manera que este diseño queda atado a la implementación, perdiendo capacidad de

reutilización.

Para resolver este conflicto, se ha propuesto como patrón el uso de objetos de acceso a datos

(DAO por sus siglas en inglés: Data Access Object).

A

BC

D

<object id="b" type="B">

<property name="propiedad_a_inicializar_1" ref="5">

<property name="propiedad_a_inicializar_2" ref="x">

<property name="propiedad_a_inicializar_n" ref="valor">

<object/>

...

<object id="a" type="A">

<property name="B" ref="b">

<object/>

<object id="c" type="C">


<object/>

<object id="d" type="D">


<object/>

Archivo de configuración

25

El patrón Data Access Object:

• Separa la interfaz cliente de la fuente de datos de su mecanismo de acceso.

• Adapta un API de acceso a una fuente de datos a una interfaz cliente.

El patrón DAO permite a los mecanismos de acceso cambiar independientemente del código

que utiliza los datos [SUN, 2002]. Es decir, un DAO es la implementación específica de una clase

con mecanismos de acceso a datos que expone una interfaz común, separando la

implementación del diseño del sistema, como muestra la Figura 2-5 [SUN, 2008].

En el diseño del micrositio, se utilizarán interfaces de DAOs que serán implementadas en su

mayoría utilizando NHibernate, de manera que el mismo pueda ser reutilizado para proyectos

de desarrollo futuros.

Figura 2-5: Utilización del objeto de acceso a datos.

II.6 Antipatrones de diseño

Así como los patrones de diseño proveen guías para desarrollar soluciones simples y elegantes a

problemas comunes, también han sido definidos los llamados antipatrones de diseño: la

descripción de una solución comúnmente utilizada a un problema y que genera consecuencias

negativas [BROWN, 1998]. Se puede decir que estas guías indican cómo no hacer las cosas y las

consecuencias que puede acarrear el incurrir en una mala práctica.

Para ejemplificar, imaginemos un sistema estructurado en subsistemas, en el que las clases

cliente deben acceder a las clases de un subsistema. Esto puede ser resuelto realizando las

llamadas directamente de las clases cliente a las clases del subsistema, como se muestra en la

Figura 2-6.

Este diseño es considerado un antipatrón, dado que la cantidad de llamadas de las clases cliente

a las clases internas del subsistema generaría una gran dependencia entre ellas, haciéndolo

difícilmente reutilizable.




Figura 2-6: Ejemplo de un antipatrón de diseño.

Figura 2-7: Patrón de diseño de Fachada.

26




Por otro lado, puede utilizarse el patrón

el subsistema, de manera que las clases cliente solamente acceden a esta. (

Este patrón es de hecho utilizado en el diseño del sistema planteado más adelante.

II.6.1 Otros antipatrones

Aunque los antipatrones se encuentran fuera del alcance de este trabajo, se mencionan a

continuación otras categorías de antipatrones que es importante estudiar para no incurrir en

malas prácticas.

• Antipatrones de desarrollo de s

código muerto (lava flow

entre otros.

• Antipatrones de arquitectura de software

dependiente de algún producto de software

sistemas (stovepipe system

• Antipatrones de gestión de proyectos de software

conflictivas dentro del proyecto

(Project mismanagement

II.7 Resumen

La propuesta de solución a la necesidad del cliente que concierne a éste trabajo será

desarrollada a través de un proceso de

mediante una metodología RAD (específicamente RUP, de la manera en que se explica en el

Metodología RAD

Por otro lado, puede utilizarse el patrón Fachada, con el que se crea una interfaz unificada para

subsistema, de manera que las clases cliente solamente acceden a esta. (Figura 2




Antipatrones de desarrollo de software, como la generación de clases gigantes (

flow), y el diseño no orientado a objetos (functional

Antipatrones de arquitectura de software, como la generación de una arquitectura

gún producto de software (vendor lock-in) y el aislamiento entre

stovepipe system), entre otros.

Antipatrones de gestión de proyectos de software, como mantener personas

conflictivas dentro del proyecto (corncob), la falta de administración en el

mismanagement), entre otros.

Figura 2-8: Resumen del marco teórico.


desarrollada a través de un proceso de ingeniería de software, que será llevado a cabo


Ingeniería de Software

Análisis y Diseño Orientado a Objetos

Buenas prácticas

Patrones de diseño

27

, con el que se crea una interfaz unificada para

Figura 2-7)




, como la generación de clases gigantes (blob),

functional decomposition),

, como la generación de una arquitectura

) y el aislamiento entre

, como mantener personas

), la falta de administración en el proyecto


ingeniería de software, que será llevado a cabo


28

Capítulo IV), llevando los requerimientos a través de un análisis orientado a objetos para

obtener un diseño basado en buenas prácticas y dar al usuario una solución simple y robusta en

un corto plazo.

Capítulo III

Marco Contextual

30

“Encuentro imposible conocer las partes sin el conocimiento del todo, como imposible es conocer el todo sin el conocimiento de las partes”

Blaise Pascal (1623 – 1662)

III.1 Introducción

A continuación se presenta al lector a la empresa cliente, sus funciones en México y el mundo, y

la problemática que desea resolver con la solución planteada en este proyecto, ubicando la

herramienta a desarrollar en su contexto de manera que la misma se adapte a las necesidades

propias de DHL.

III.2 DHL en el mundo

DHL fue fundada en el año de 1969 por Adrian Dalsey, Larry Hillblom y Robert Lynn, quienes

dieron nombre a la empresa con las iniciales de sus respectivos apellidos. Los fundadores

comenzaron a enviar personalmente documentos por avión desde San Francisco hasta Honolulu,

comenzando las inspecciones aduaneras de la carga antes del arribo efectivo del envío, lo que

redujo drásticamente el tiempo de espera en puerto [DPWN, 2005].

Figura 3-1: Expansión global de DHL hasta 1988.

La compañía se extendió rápidamente y para el año de 1988, DHL ya contaba con destinos en

170 países, extendiendo su alcance a la entrega de paquetes, no sólo documentos, con un

31

personal de 160,000 empleados realizando más de 165,000 embarques por noche (Figura 3-1

[DPWN, 2005]).

Diez años más tarde, la Deutsche Post World Net (DPWN), servicio postal y logístico originario de

Alemania, comenzaba a invertir en acciones de DHL. Para principios de 2002 se convertiría en el

principal accionista de la empresa y finalmente, a finales de ese mismo año, el 100% de la

compañía sería propiedad de DPWN.

Dentro de los hitos más recientes y relevantes en la historia de DHL se encuentran la adopción

del rojo y amarillo como colores corporativos en 2003 y la adquisición de la empresa de

logística Exel con una inversión de 5.5 billones de euros, que redituó en 251 millones de euros

en tan solo 6 meses.

Hoy en día, DHL cuenta con una de las más grandes redes a nivel mundial de envíos Express y

logística

Tabla 3-1: La red de DHL.

Número de empleados Alrededor de 285,000

Número de oficinas Alrededor de 6,500

Número de concentradoras, almacenes y terminales Más de 450

Número de puertos de salida 240

Número de aviones 420

Número de vehículos 76,200

Número de países y territorios Más de 220

Envíos por año Más de 1,500 millones

Cobertura de destinos 120,000

III.3 DHL en México

DHL llegó a México en 1976 para ubicar al país como un destino más para la entrega de los

documentos generados en el extranjero [DPWN, 2008-1]. Entre 1979 y 1980 comenzó su

operación formal, permitiendo a los mexicanos realizar envíos de documentos y paquetería al

mundo a través de su red internacional, y para 1990 fue la primera compañía en introducir su

operación en Cuba y promover la comunicación entre la isla y el resto del mundo a través de

México [DPWN, 2008-1].

32

En la actualidad, DHL Express México cuenta con un personal directo de 3,000 empleados y

otros 1,000 de manera indirecta, ofreciendo sus servicios a lo largo de la república mexicana con

centros de transferencia en la ciudad de México, Guadalajara y Monterrey; y de México para el

mundo desde la ciudad de México, Saltillo, Guadalajara y Mérida, con una red de 1,800

repartidores trabajando con más de 1,400 vehículos terrestres y 12 vuelos dedicados

nacionales.

III.4 Los servicios de DHL

En México, DHL ofrece servicios internacionales de envíos express, transporte terrestre, envíos

aéreos y marítimos, y logística, a través de 3 divisiones de negocio:

• DHL Express ofrece los servicios de mensajería express, paquetería y carga. A nivel

nacional, realiza entrega de documentos y paquetes desde 70kg hasta 250kg en

diferentes modalidades de tiempo, como son: Entrega garantizada 8:30am, Entrega

garantizada 10:30am, Día Definido 2 a 3 días y Retorno de Documentos y Paquetes. A

nivel internacional, cuenta con los servicios de Exportación e Importación Express, en los

que permite enviar y recibir paquetes y mercancía de alto volumen.

• DHL Global Forwarding ofrece servicios de logística así como envíos aéreos y marítimos

alrededor del mundo con el transporte internacional conocido como Customer Program

Management (CPM) a nivel de embarque, de orden de compra o producto o bien,

servicio personalizado, así como Manejo de Órdenes de Compra, Gestión de Proveedor

Líder De Logística (LLP), Manejo de Proveedores, Manejo de Eventos de Cadenas de

Suministros, Manejo de Transporte y Consolidación de proveedores.

• DHL Exel Supply Chain administra la cadena de suministros buscando la optimización de

los procesos, la reducción de tiempos, la visibilidad de la operación, el rastreo de los

productos, la eficiencia y la agilidad [DPWN, 2008-2]. Se enfoca en ofrecer servicios de

logística, es decir, maneja los métodos necesarios para llevar a cabo la organización de la

empresa cliente.

33

III.5 Necesidades del cliente

Debido a la manera en que se maneja el flujo de trabajo del programa de incentivos (expuesto

como planteamiento del problema de este trabajo), gran parte de la responsabilidad recae

sobre el área de Televentas, principalmente en los puestos más altos. El gerente de dicha área

desea agilizar el proceso mediante un micrositio que sea incluido en la página web de la Intranet

de DHL. Para ello, entregó un listado con los siguientes requerimientos:

• Mostrar el status de cada LEAD.

• Catorcena en la que fue pagado.

• Número de nómina a quien le fue pagado.

• Opción de contactar al administrador de LEADs por e-mail, en el cual el visitante pueda

enviar dudas o sugerencias al administrador del programa LEADs.

• Visualizar reportes (sólo directores y gerentes).

• Actualizar información vía remota.

• Tener un apartado de noticias y/o mensajes importantes.

• Conocer el status del LEAD ingresando su folio.

• Conocer el status del LEAD ingresando el número de nómina del empleado.

• Reportes gerenciales (ingresando e-mail de personas autorizadas, el administrador del

micrositio podrá manipular los accesos)

o Reportes gráficos

� Reportes gráficos del pipeline de LEADs

� Reportes gráficos de status de LEADs.

o Número de cuentas aperturadas al LEAD.

o Revenue YTD5 de cuentas aperturadas por producto y todos los productos.

o Envíos YTD de cuentas aperturadas por producto y todos los productos.

o Kilos YTD de cuentas aperturadas por producto y todos los productos.

o Venta mensual promedio.

o Envíos mensuales promedio.

5 Revenue Year To Day se refiere a la utilidad generada de un año a la fecha.

34

o Kilos mensuales promedio.

o Reporte al corte del mes de los LEADs que han cumplido la condición de pago (5

envíos o $1,000.00 en un mes) y no han sido pagados.

o Convertion Rate.

o Fuentes actuales generadoras de LEADs.

o Cuentas aperturadas.

o Cuentas aperturadas por canal.

• Conocer todas y cada una de las cuentas aperturadas por el programa.

• Poder dar parámetros de fechas de lo que requiere la información.

• Canal de venta donde está asignado el LEAD.

• Ejecutivo de cuenta donde está asignado el LEAD.

• Cuentas aperturadas: a qué canal de venta y ejecutivo de cuenta ha sido asignado el

LEAD.

• Al ingresar el número de nómina debe indicar:

o Número de LEAD formats ingresados.

o Fecha en que se generó el LEAD.

o LEADs exitosos (que han cumplido la condición).

o LEADs no exitosos (no han cumplido la condición).

o Causa de por qué el LEAD no ha sido exitoso (amarrado al comentario de COMET,

como puede ser “no tiene potencial para la cuenta”, “no está interesado”, etc.)

o Paso del pipeline en que se encuentra el LEAD.

o Potential Revenue.

o Potential Revenue de LEADs no exitosos.

• Conteo de visitas al micrositio

o Por mes.

o Quiénes lo han visitado.

o Para entrar deberán ingresar su número de nómina.

• Debe generar el pago de LEADs a recursos humanos, siempre y cuando cumplan con la

condición.

35

• El administrador del programa LEADs debe tener una opción donde pueda manipular las

condiciones de pago de un LEAD, es decir, actualmente la condición es 5 envíos y/o

$1,000.00 dentro de un mismo mes, pero en esta opción se podrán cambiar dichos

parámetros.

• El micrositio deberá estar basado en SharePoint para ser montado en la Intranet de DHL.

III.6 Los beneficios esperados de la solución

El cliente desea que se desarrolle una herramienta de control de LEADs para obtener los

siguientes beneficios:

• Completa automatización de los procesos.

• Transparencia total en la información.

• Eliminar las solicitudes manuales de información de varias fuentes, en las que se

depende de la disponibilidad de terceros.

• Información online actualizada al momento de ser solicitada.

• Acceso a reportes de forma inmediata.

• Eliminación de cualquier proceso manual, que actualmente llegan a tomar hasta 30

horas hombre.

• Conocer el status de todos y cada uno de los LEADs.

• Al conocer el status de venta, el ejecutivo de cuenta podrá actuar de forma inmediata

para elevar el revenue de los LEADs que no han cumplido las condiciones para ser

pagados.

• Cualquier persona interesada en el programa podrá conocer el status de todos y cada

uno de los LEADs.

• El supervisor de Televentas podrá enfocarse a las actividades reales del puesto y no

gastar tiempo en reporteos de varias fuentes.

• Pagar en tiempo y forma los LEADs.

• Con todo lo anterior se obtendrá una credibilidad en el programa.

36

Los requerimientos de la sección anterior, así como los beneficios que debe brindar la

herramienta a desarrollar, serán analizados para generar un documento de requerimientos

formal del sistema, como se verá en el capítulo siguiente.

Capítulo IV

Flujo de Trabajo LEADs y Requerimientos del Sistema

38

“A ningún hombre debe obligársele a hacer el trabajo que puede hacer una máquina.”

Henry Ford (1863 – 1947)

IV.1 La fase de Inicio del proyecto

La lista de requerimientos entregada inicialmente por el cliente fue revisada y comentada en

varias sesiones de preguntas y respuestas para reunir los requerimientos del sistema, que

describen las funciones que debe cumplir, los requisitos no funcionales, características del

diseño y otros elementos necesarios para propiciar una descripción completa y comprensiva de

los requisitos para el software a desarrollar. En este capítulo se muestra al lector la evolución de

los requerimientos del cliente en un documento formal de requerimientos como un artefacto de

RUP, correspondiendo a la primera fase: Inicio (Figura 4-1).

Figura 4-1: Fases de RUP - Inicio.

39

IV.2 Flujo de trabajo LEADs

En esta sección se explicará el flujo de trabajo del programa LEADs actual para tener un

entendimiento completo del mismo y de esta manera trasladarlo a un documento de

requerimientos que servirá de base para el análisis y diseño del sistema.

El seguimiento del flujo fue obtenido de diversas reuniones con el cliente y posteriormente se

documentó, ya que los empleados conocen el programa, pero no está especificado por escrito.

Los couriers son empleados de DHL que salen a la calle a repartir la mercancía enviada por la

empresa de mensajería. Ellos se encuentran en contacto directo con los clientes y pueden

percatarse de aquellos a quienes sería favorable abrirles una cuenta para realizar envíos con

cierta regularidad, exportar o importar mercancía, u obtener algún servicio de los que ofrece la

compañía.

En este caso, el empleado registra al cliente como un nuevo prospecto mediante un LEAD

format, anotando sus datos en él, y lo ingresa al área de Televentas.

El encargado de Televentas genera un archivo de Excel con los datos de los prospectos que le

fueron entregados mediante LEAD formats y deposita esta información en COMET. El prospecto

se convierte entonces en un SUSPECT o en un DEVELOPMENT LEAD, dependiendo de si es la

primera cuenta que se abre para el cliente o es una petición de una nueva cuenta para un

cliente existente, respectivamente.

El LEAD es asignado a un ejecutivo de cuenta por el encargado de Televentas, y se convierte en

un CUSTOMER. El ejecutivo puede aceptar o rechazar el LEAD. En caso de ser rechazado, el LEAD

se asignará a otro ejecutivo. Cuando un ejecutivo acepta llevar el seguimiento de un LEAD, éste

se convierte en un OPPORTUNITY. En este punto, el ejecutivo comienza la promoción de la

apertura de la cuenta con el cliente, a través del proceso conocido en DHL como pipeline de

LEADs, que será explicado en detalle más adelante.

El cliente puede aceptar o rechazar la propuesta, y su decisión es notificada por el ejecutivo de

cuenta al encargado de Televentas, quien genera un reporte del estado de cada uno de los

LEADs en curso para actualizarlo en COMET.

40

Figura 4-2: Flujo de trabajo LEADs.

Por su parte, para las cuentas aperturadas a través de LEADs, el área de Administración de

Ventas genera semanalmente el reporte 24 Meses desde su sistema llamado IBS, que muestra la

actividad de cada cuenta hasta 24 meses antes de la fecha en que se crea el archivo y lo entrega

en el área de Televentas. Mediante este archivo, el encargado de Televentas debe ser capaz de

discernir aquellas cuentas generadas por LEADs que han cumplido con las condiciones de pago,

41

cotejarlo con la base de datos de sus empleados, y generar un reporte de los empleados que

deben ser remunerados para enviarlo vía correo electrónico al área de Recursos Humanos, que

se encargará de depositar el incentivo en la nómina del empleado.

El flujo de trabajo puede verse de manera gráfica en la Figura 4-2.

IV.2.1 El pipeline de LEADs

El pipeline de LEADs define el comportamiento de un cliente mediante los estados mostrados en

la Figura 4-36. Su seguimiento es llevado a cabo por el ejecutivo de cuenta cuando realiza la

promoción de la apertura de una cuenta.

Figura 4-3: Pipeline de LEADs.

Los primeros siete estados se presentan en la siguiente manera:

1. Potential Opportunity es el estado para aquellos LEADs apenas registrados como una

posible oportunidad de cuenta.

2. En el estado First Contact, el área de Televentas realiza el primer contacto con el cliente

para promocionar la apertura de la cuenta.

3. Un LEAD en estado de Proposal ha recibido la propuesta formal por parte de DHL para

realizar sus envíos con la compañía, pero no ha dado una respuesta.

4. Cuando el cliente acepta la propuesta, pasa al estado de Agreed Shipping.

6 En la figura, se muestran los nombres de los estados en español únicamente como referencia, ya que durante el

desarrollo se utilizaron los términos en inglés.

42

5. Pueden pasar días desde el “sí” del cliente hasta que firma el contrato. Al firmarlo, se

convierte en un ACCOUNT y pasa al estado del pipeline de Implemented.

6. Cuando el cliente con la cuenta implementada realiza su primer envío, pasa al estado

First Consignment y comienza a ser administrado en el archivo 24 Meses.

7. Para más de un envío y durante todo el mantenimiento de la cuenta, el LEAD se

considera en estado Shipped to Profile. Un LEAD en First Consignment o Shipped to

Profile es candidato a ser un LEAD exitoso, cumpliendo las condiciones para ser pagado.

Los últimos dos estados se refieren a LEADs que no han podido seguir en el proceso por una de

las siguientes razones:

8. Unable to Gain se refiere a los LEADs cuyas negociaciones para abrir una cuenta no han

sido exitosas.

9. Future Opportunity es cuando el prospecto no sigue con el proceso pero deja el campo

abierto para futuras negociaciones.

IV.3 Casos de uso iniciales

Con el objetivo de entender mejor las necesidades del cliente respecto al sistema, y que al

mismo tiempo el cliente aprobara los requerimientos para continuar con el desarrollo, se

elaboró un diagrama de casos de uso inicial.

Los casos de uso definen de forma gráfica y escrita los requerimientos funcionales del sistema,

incluyendo algunos requerimientos no funcionales.

El diagrama de la Figura 4-4 muestra los actores y funciones principales del sistema.

En este caso contamos con 4 actores:

• Administrador funcional, que se encargará de gestionar el contenido de las noticias y/o

mensajes importantes, controlar el acceso al sitio para otros administradores

funcionales y superusuarios, actualizar la información de las bases de datos de COMET e

IBS, visualizar los reportes generados por la herramienta y consultar el status de cada

LEAD. El rol será desempeñado por el gerente de Televentas de DHL.

43

• Superusuario, que tendrá el acceso restringido únicamente a la visualización de reportes

y la consulta del status de los LEADs. Las personas que desempeñen este rol serán

asignadas por el administrador funcional, y está pensado para los supervisores de cada

área.

• El actor Empleado DHL es cualquier persona que tenga acceso a la Intranet de DHL, ya

que no requerirá autenticación en el sistema. Este podrá consultar el status de los LEADs

y contactar al administrador mediante un formulario en el micrositio que enviará la

información al correo electrónico del administrador funcional.

• Administrador técnico, que no tendrá injerencia sobre las funciones del sistema, pero se

encargará de dar mantenimiento al servidor de residencia de la aplicación para

garantizar su funcionamiento. Este rol es completamente responsabilidad del cliente y

queda fuera del alcance del software del sistema.

Figura 4-4: Diagrama de casos de uso.

Administrador funcional

Administrador técnico

Superusuario

Empleado DHL

Micrositio LEADs

Gestionar contenido

Registrar

administradores funcionales y

superusuarios

Actualizar

información

Visualizar reportes

Consultar status

de LEADs

Contactar al

administrador

44

IV.4 Requerimientos funcionales del sistema

Los requerimientos funcionales de un sistema describen los servicios que se espera que éste

provea. En esta sección se describe lo que el sistema tiene que hacer, los factores que afectan el

producto y satisfacen los requerimientos. El flujo de trabajo estudiado, la lista de

requerimientos entregada por el cliente y el diagrama de casos de uso inicial fueron las

herramientas para la obtención de este nuevo listado.

Tabla 4-1: Requerimientos funcionales del sistema.

ID Nombre Prioridad Características

R01 Micrositio para

Intranet Alta

Desarrollar un sistema a manera de micrositio para

introducir en la Intranet de DHL. El sistema será instalado

en el servidor “avión-cl” de DHL, el cual cuenta con arreglos

de discos duros que garantizan la capacidad de almacenaje

y la persistencia de la información.

R02 Registro de LEADs Alta

El sistema generará y actualizará de manera automática los

registros de LEADs conforme a la información contenida en

un archivo extracto de COMET, como se describe en el

requerimiento R07.

R03 Reporteo Gerencial Alta

Los directores/gerentes y administradores tendrán acceso

a los siguientes reportes, que deberán ser filtrados por

fecha:

• Reporte gráfico del pipeline de LEADs.

• Reporte gráfico de status de LEADs.

• Número de cuentas aperturadas al LEAD.

• LEADs que han abierto cuentas pero no han

cumplido con las condiciones de pago.

• Convertion Rate.

• Fuentes actuales generadoras de LEADs.

• Cuentas aperturadas.

• Cuentas aperturadas por canal.

45


R04 Consulta de Status

de LEADs Media

Los empleados de DHL podrán consultar el status de sus

LEADs introduciendo una de las siguientes:

• El folio del LEAD.

• Su número de nómina.

Los administradores y superusuarios podrán a su vez

imprimir una consulta del status de LEADs por estaciones.

R05 Control de Usuarios Media El administrador funcional podrá conceder y restringir

acceso a directores/gerentes y otros administradores.

R06

Control de

condiciones de

pago

Media

El administrador podrá manipular la cantidad de envíos y el

monto mínimo al mes para que sea pagado un LEAD, así

como su vigencia, es decir, el tiempo en el que los

parámetros anteriores deben cumplirse antes de que el

LEAD se dé de baja.

R07 Actualización de

Información Alta

La información se actualizará mediante extractos de

COMET y el condensado de 24 meses, que involucran las

diferentes etapas desde que se origina el LEAD hasta que

cumple las condiciones para ser pagado. Esta información

debe incluir:

• Número de LEAD formats ingresados.

• Fecha de ingreso del LEAD.

• Fecha de pago.

• LEADs exitosos y no exitosos.

• Causa de fallo del LEAD.

• Potencial de revenue.

• Canal de venta y ejecutivo de cuenta donde está

asignado el LEAD.

• Número de nómina a quien fue pagado.

R08 Pago a Recursos

Humanos Alta

El sistema debe generar un reporte de los LEADs que deben

ser pagados y enviarlo a manera de correo electrónico. El

administrador funcional del sistema deberá ser capáz de

46


R08 Pago a Recursos

Humanos (cont.) Alta

gestionar los destinatarios de dicho correo, así como los

campos del layout de salida del reporte.

R09 Noticias y Mensajes

Importantes Media/Alta

El sistema deberá contar con un módulo administrable de

noticias y/o mensajes importantes, el cual deberá soportar

imágenes.

R10 Contacto Media/Alta

Los empleados de DHL podrán contactar al administrador a

través del micrositio con dudas o sugerencias. El

administrador recibirá los mensajes en su correo

electrónico.

R11 Contador de Visitas Baja

El sitio debe incluir un contador de visitas que reporte el

número de visitas por mes y qué usuarios registrados lo

han visitado.

R12

Envío del Status de

LEAD por Correo

Electrónico

Baja Los empleados que hayan registrado LEADs recibirán un

correo informativo cada vez que cambie su status.

IV.5 Requerimientos no funcionales del sistema

Los requerimientos no funcionales complementan a los funcionales, describiendo características

que debe tener el sistema sin referirse a la propia funcionalidad. Estos requerimientos suelen

ser limitantes en el desarrollo del software.

Para el proyecto en cuestión, se identificaron los siguientes requerimientos no funcionales,

divididos en requerimientos de usabilidad (Tabla 4-2), confiabilidad (Tabla 4-3), seguridad (Tabla

4-4), desempeño (Tabla 4-5) y documentación (Tabla 4-6).

Tabla 4-2: Requerimientos de usabilidad del sistema.


U01 Fácil Aprendizaje Media/Alta La curva de aprendizaje del sistema debe ser muy pequeña.

47

Tabla 4-3: Requerimientos de confiabilidad del sistema.


C01 Tolerancia a Fallas Media/Alt

a

El sistema debe ser capaz de recuperarse de errores

presentados de manera automática y/o mostrar el

procedimiento a seguir para corregirlos.

C02 Disponibilidad Alta El sistema debe estar disponible 24/7.

Tabla 4-4: Requerimientos de seguridad del sistema.


S01 Ingreso de Usuarios Alta

Tendrán acceso al sistema solamente administradores

funcionales y superusuarios registrados. Los reportes de

status de LEADs documentados en R04 serán de acceso

libre a cualquier persona que tenga acceso a la Intranet de

DHL.

Tabla 4-5: Requerimientos de desempeño del sistema.


D01 Host del Sistema Alta

Para garantizar el mejor desempeño del sistema, el

servidor donde será instalado deberá contar con las

siguientes características mínimas:

• Doble procesador Intel Xeon 2.80 GHz

• 2 GB de RAM.

• Microsoft Windows Server 2003 Enterprise Edition

Service Pack 1.

• Microsoft SQL Server 2000.

• .NET Framework 2.0

48

Tabla 4-6: Requerimientos de documentación del sistema.


DOC01 Manual de

mantenimiento Media/Alta

Al finalizar el desarrollo se deberá entregar la

documentación necesaria para permitir el mantenimiento

del sistema.

DOC02 Manual de usuario Alta El sistema deberá contar con un manual de usuario.

IV.6 Restricciones

Junto con los requerimientos, se entregó un listado de restricciones que deben ser tomadas en

cuenta durante el desarrollo del sistema, y que también responden a necesidades específicas

del cliente.

• El sistema deberá ser desarrollado como una aplicación web.

• Los datos deberán ser almacenados en una base de datos SQL Server 2000.

• El sistema deberá estar basado en la plataforma de desarrollo .NET 2.0.

• El diseño del sistema no incluirá conectividad con otros sistemas de manera directa.

IV.7 Resumen

Durante la fase de inicio se mantuvieron reuniones con el cliente con el objetivo de entender el

alcance del proyecto y las necesidades del negocio, construyendo así los requerimientos del

sistema. La primera reunión se llevó a cabo el día 5 de diciembre de 2006, donde se presentaron

los requerimientos del sistema. Sin embargo, el proyecto dio inicio formalmente a principios de

enero de 2007, cuando el presupuesto para el desarrollo fue aprobado por DHL.

Esta fase tuvo una duración aproximada de 28 horas, divididas en casi tres meses, dada la

disponibilidad por parte del cliente de concertar reuniones para el levantamiento de

requerimientos.

Las actividades realizadas se muestran en la Tabla 4-7.

49

Tabla 4-7: Actividades realizadas en la fase de diseño.

Actividad realizada Horas efectivas de trabajo

Levantamiento de requerimientos con el cliente 20

Análisis de la información y generación de requerimientos 8

En el siguiente capítulo, se realizará un análisis profundo de los requerimientos para diseñar el

sistema.

Capítulo V

Análisis y Diseño de la Solución

51

“Yo no hice nada por accidente, ni tampoco fueron así mis invenciones; ellas vinieron por el trabajo.”

Thomas Alva Edison (1847 – 1931)

V.1 La fase de Elaboración del proyecto

Una vez concluida la fase de Inicio se dio paso al análisis de los requerimientos y diseño de la

aplicación, lo que se conoce como fase de Elaboración en el proceso de desarrollo RUP (Figura

5-1).

Figura 5-1: Fases de RUP - Elaboración.

En este capítulo se muestra el diseño que refleja el análisis de los requerimientos del sistema,

así como la implementación de los modelos de información, funcional y de comportamiento,

dividido en los artefactos Arquitectura de Software y Diseño del Sistema, que han sido

entregados al cliente.

Estos artefactos permiten traducir los requerimientos analizados del sistema en una

representación del software, que inicialmente da una visión del mismo y tras posteriores

refinamientos conduce a una representación de diseño muy cercana al código fuente. Son

instrumentos utilizados por los clientes para comprender el funcionamiento del sistema, así

como por los desarrolladores, quienes deben seguir los lineamientos planteados en los

artefactos para lograr el objetivo

V.2 Arquitectura del sistema

El diseño del sistema se basa en el patrón de arquitectura multicapa. Su objetivo es la

simplificación y escalabilidad del software, ya que a cada nivel se le confía una misión simple, lo

que permite que la aplicación sea escalable y pueda ampliarse con mayor facilidad en caso de

que el negocio así lo requiera. El escenario más simple de una arquitectura multicapa se

muestra en la Figura 5-2.

Figura 5

• Capa de presentación

comunica y captura la información realizando un procesamiento mínimo

comúnmente consiste de un filtrado previo para comprobar que no existen errores de

formato. Esta capa se comunica únicamente con la capa de negocio.

• Capa de negocio: En esta capa residen los programas que se ejecutan, recibiendo

peticiones del usuario y enviando las respuestas tras el proceso. Se denomina

negocio o lógica del negocio

deben cumplirse. La capa de negocio se comunica con la capa de presentación para

recibir solicitudes y entr

almacenen o recuperen datos.

• Capa de datos: Se encarga de hacer persistente toda la información. Suministra y

almacena información para la capa de negocio.



artefactos para lograr el objetivo del sistema.

Arquitectura del sistema



ción sea escalable y pueda ampliarse con mayor facilidad en caso de


Figura 5-2: Representación de una arquitectura multicapa.

Capa de presentación: En esta capa superior, se presenta el sistema al usuario, le

comunica y captura la información realizando un procesamiento mínimo


formato. Esta capa se comunica únicamente con la capa de negocio.

: En esta capa residen los programas que se ejecutan, recibiendo

o y enviando las respuestas tras el proceso. Se denomina

lógica del negocio, pues aquí es donde se establecen todas las reglas que


recibir solicitudes y entregar resultados, y con la capa de datos, para solicitar que se

almacenen o recuperen datos.

: Se encarga de hacer persistente toda la información. Suministra y

almacena información para la capa de negocio.

Capa de presentación

Capa de negocio

Capa de datos

52





ción sea escalable y pueda ampliarse con mayor facilidad en caso de


: En esta capa superior, se presenta el sistema al usuario, le

comunica y captura la información realizando un procesamiento mínimo, que


: En esta capa residen los programas que se ejecutan, recibiendo

o y enviando las respuestas tras el proceso. Se denomina capa de

, pues aquí es donde se establecen todas las reglas que


egar resultados, y con la capa de datos, para solicitar que se

: Se encarga de hacer persistente toda la información. Suministra y

Estas tres capas residirán en una

este marco de trabajo se unen formando parte de la arquitectura. Dichos componentes pueden

o no estar ligados y participar en más de una de las capas.

Trabajar con esta arquitectura reportará los s

• Extensibilidad, pues permitirá añadir nueva funcionalidad modificando en la menor

medida de lo posible el código.

• Modularidad, ya que se definirá un conjunto de componentes que ofrecen servicios,

cuyas interfaces serán publicadas y de

• Reciclaje, pues favorece la reutilización de los servicios disponibles.

• Por ser una arquitectura

productos comerciales y proveedores de servicios de desarrollo.

V.2.1 Arquitectura contextualizada

Con base en los requerimientos obtenidos en la fase de Inicio, se diseñó una arquitectura

ejecutable basada en estándares y buenas prácticas, representada en la

Figura 5

Estas tres capas residirán en una única plataforma de hardware. Los distintos componentes de


o no estar ligados y participar en más de una de las capas.

Trabajar con esta arquitectura reportará los siguientes beneficios:

, pues permitirá añadir nueva funcionalidad modificando en la menor

medida de lo posible el código.

, ya que se definirá un conjunto de componentes que ofrecen servicios,

cuyas interfaces serán publicadas y descubiertas por otros componentes.

, pues favorece la reutilización de los servicios disponibles.

Por ser una arquitectura basada en estándares y portabilidad, será independiente de

productos comerciales y proveedores de servicios de desarrollo.

.1 Arquitectura contextualizada


ejecutable basada en estándares y buenas prácticas, representada en la Figura 5

Figura 5-3: Arquitectura contextualizada del sistema.

53

única plataforma de hardware. Los distintos componentes de


, pues permitirá añadir nueva funcionalidad modificando en la menor

, ya que se definirá un conjunto de componentes que ofrecen servicios,

scubiertas por otros componentes.

, será independiente de


Figura 5-3.

54

En la figura se aprecian dos niveles para la capa de datos. El nivel inferior representa las bases

de datos que serán utilizadas, mientras que el nivel superior representa las operaciones que se

llevarán a cabo para procesar la información de las bases de datos de IBS y COMET a la base de

datos del micrositio.

En la capa de negocio se incluirán las operaciones para administración de LEADs, generación de

reportes, procesamiento de correos electrónicos, administración de cuentas de usuario y demás

implementaciones de operaciones para cubrir los requerimientos planteados.

La capa de presentación o vista, servirá como interfaz para la entrada de datos de usuario al

sistema, presentación de reportes, noticias y mensajes importantes, mostrando todo aquello

que el usuario deba ver en pantalla.

V.3 Diseño de datos

El impacto de los datos sobre la estructura del programa y la complejidad funcional, hace que el

diseño de datos tenga una gran influencia en la calidad del software. Los conceptos de

ocultamiento de información y de abstracción de datos conforman la base de los métodos de

diseño de datos.

Se consideran los siguientes principios para la especificación de datos:

• Se deben desarrollar y revisar las representaciones del flujo y contenido de datos,

identificando los objetos y buscando alternativas.

• Identificar las estructuras de datos y operaciones que se deben realizar sobre ellas.

• Establecer y realizar un diccionario de datos para definir el diseño de los datos y del

programa.

• El diseño de los datos debe ser descendente, desde referencias generales y

especificándose en detalle en niveles inferiores.

• La representación de una estructura de datos debe ser conocida por los módulos que

hagan uso directo de los contenidos de la estructura (ocultamiento de información y

acoplamiento de datos).

55

• El uso de una biblioteca de plantillas de estructuras de datos (tipos abstractos de datos)

pueden reducir el trabajo de especificación y diseño de datos.

• El lenguaje de programación elegido debe soportar la estructura de datos desarrollada.

V.3.1 Diccionario de datos de entrada

Los datos definidos en el BRS (Business Requirement Statement, documento entregado por DHL)

han sido acotados conforme a las necesidades del sistema y se presentan en este apartado.

Dichos datos serán leídos por el sistema desde extractos de los sistemas COMET e IBS (Figura 5-

4).

Figura 5-4: Esquema de datos de entrada al sistema.

Se mantendrá el control de cada LEAD en base al campo GSFA (General Sales Force

Automatization) Customer ID, presente en todas las tablas utilizadas.

A continuación se presentan las tablas7 en el orden en que serán buscados por el sistema los

registros de LEADs, con una breve descripción de la base de datos y su representación en un

7 Durante el desarrollo se utilizó el término bases de datos para denominar a las tablas mostradas en esta sección,

pues con esta terminología eran conocidas por el cliente. Estas en realidad, son tablas que pertenecen a bases de datos más grandes, gestionadas por sus respectivos sistemas.

Sistema LEADs

COMETIBS

24 Meses

SUSPECTS

DEVELOPMENT LEADS

CUSTOMERS

OPPORTUNITIES

ACCOUNTS

Empleados

56

diagrama Entidad-Relación. La descripción particular de los datos de cada tabla puede

encontrarse en el anexo B.

V.3.1.1 SUSPECTS

La tabla SUSPECTS es controlada por COMET. Define los LEADs ingresados para clientes nuevos y

se considera el primer paso en el seguimiento del programa (Figura 5-5).

Figura 5-5: Datos de entrada de SUSPECTS.

V.3.1.2 DEVELOPMENT LEADS

La tabla DEVELOPMENT LEADS trabaja de manera paralela a la de SUSPECTS, siendo también el

primer paso en el seguimiento de los LEADs pero en este caso, para nuevas cuentas de clientes

existentes (Figura 5-6).

Figura 5-6: Datos de entrada de DEVELOPMENT LEADS.

V.3.1.3 CUSTOMERS

La tabla CUSTOMERS es también manejada por COMET y almacena información referente a los

LEADs en estado de PROSPECT (Figura 5-7).

57

Figura 5-7: Datos de entrada de CUSTOMERS.

V.3.1.4 OPPORTUNITIES

En esta tabla controlada por COMET se almacena la información referente a los LEADs una vez

que ingresan en el proceso de calificación para la generación del pago del incentivo

correspondiente (Figura 5-8).

Figura 5-8: Datos de entrada de OPPORTUNITIES.

V.3.1.5 ACCOUNTS

La tabla ACCOUNTS es el último extracto de COMET utilizado para el seguimiento de LEADs, y a

su vez representa el último estado de los LEADs (Figura 5-9).

58

Figura 5-9: Datos de entrada de ACCOUNTS.

V.3.1.6 24 Meses

El archivo conocido como 24 meses es un extracto de IBS que denota el comportamiento de

cada cuenta.

Dicho extracto es generado cada semana y muestra las actividades de las cuentas a partir de 24

meses antes de la fecha en que se genera (Figura 5-10).

Figura 5-10: Datos de entrada del archivo 24 meses.

V.3.1.7 Tablas de empleados

Durante el proceso de seguimiento de LEADs se manejan dos tablas de empleados diferentes.

Por una parte, una tabla manejada por COMET que almacena datos de las personas que

administran las cuentas (Figura 5-11).

59

Figura 5-11: Datos de entrada de empleados desde COMET.

Además, el departamento de Recursos Humanos genera un extracto en formato de Excel que

contiene los datos de los empleados a los que serán pagados los incentivos (Figura 5-12).

Figura 5-12: Datos de entrada de empleados por RH.

V.3.2 Diccionario de datos del sistema

El diagrama de la base de datos (Figura 5-13) muestra la estructura base del sistema a nivel de

datos8.

8 El mismo diagrama se puede encontrar ampliado en el anexo C.

60

Figura 5-13: Diagrama entidad-relación de la BD del sistema.

Es conocido como diagrama E-R (Entidad-Relación) ya que muestra un esquema de los objetos

que serán utilizados y la manera en que se relacionan.

A continuación se describe el contenido de cada tabla, dejando las descripciones de cada campo

en el anexo C.

V.3.2.1 PERSONA

Denota la abstracción de una persona con sus datos comunes.

V.3.2.2 USUARIO

Almacena los usuarios registrados (administradores y superusuarios) que tienen acceso al

sistema.

V.3.2.3 EJECUTIVO

Datos sobre los empleados que cumplen la función de ejecutivo de cuentas para los LEADs.

V.3.2.4 EMPLEADO

Guarda información acerca de los empleados provistos por RH para el pago de LEADs.

V.3.2.5 AREA

Áreas a las que pertenecen los empleados y que por lo tanto se consideran áreas generadoras

de LEADs.

61

V.3.2.6 BITACORA

Guarda una bitácora de los sucesos más importantes en el uso del sistema.

V.3.2.7 BITACORA_INGRESO

Indica cuando un registro de bitácora se refiere al ingreso de un usuario registrado.

V.3.2.8 INDUSTRIA

Almacena información acerca de las industrias en las que trabajan los clientes con cuentas

aperturadas para de esa forma conocer cuáles son las industrias más importantes en este

aspecto.

V.3.2.9 ESTADO_PIPELINE

Tabla de sólo lectura que almacena información sobre los estados del pipeline de LEADs.

V.3.2.10 ESTADO

Tabla de sólo lectura que almacena información sobre los estados de un LEAD.

V.3.2.11 EVENTO

Tabla de sólo lectura que almacena los nombres de los eventos importantes que pueden

presentarse para una cuenta o un LEAD.

V.3.2.12 EVENTO_CUENTA

Eventos sucedidos para una cuenta en particular.

V.3.2.13 EVENTO_LEAD

Eventos sucedidos para un LEAD en particular.

V.3.2.14 CUENTA

Información sobre cuentas aperturadas.

V.3.2.15 LEAD

Información sobre los LEADs que se ingresan en COMET y que son candidatos para generar

incentivos.

62

V.3.2.16 CONFIGURACION

Guarda las configuraciones del sistema que son administrables, como las condiciones del pago

de LEADs.

V.3.2.17 NOTICIA

Almacena las noticias y mensajes importantes que serán mostrados al usuario.

V.4 Diseño funcional

El diseño funcional del sistema define los detalles algorítmicos del mismo. El equipo de

desarrollo basará su trabajo en los algoritmos definidos aquí.

V.4.1 Secuencia de negocio

El diagrama de secuencia del negocio (Figura 5-14) muestra los diferentes actores involucrados

en el sistema y sus relaciones a través de los procesos que regulan el negocio. El mismo ha sido

creado a partir del flujo de negocio en el capítulo IV.

Figura 5-14: Diagrama de secuencia del programa LEADs.

El siguiente listado muestra una explicación de la secuencia de negocio mostrada en el

diagrama.

1. Un empleado de DHL (generalmente un Courier) llena un formato conocido como LEAD

format con los datos de un prospecto y lo lleva al área de Adquisiciones de DHL. Un

encargado dentro de esta área registra el LEAD format en COMET.

63

2. COMET notifica del nuevo registro a un calificador. En este paso, el prospecto es

insertado en la tabla SUSPECTS. Si el prospecto se refiere a una nueva cuenta para un

cliente existente, se registra en DEVELOPMENT LEADS.

3. El calificador determina si el LEAD es o no apto para continuar con el proceso. Este

notifica al sistema COMET su decisión.

4. Si el LEAD ha sido calificado como apto para continuar, COMET encomienda la

administración de la cuenta a un ejecutivo de cuenta.

5. El ejecutivo puede decidir no aceptar la administración del LEAD, en cuyo caso lo

descarta y la secuencia regresa al paso 4.

6. En caso de que el ejecutivo acepte el LEAD, toma control sobre el mismo para

inspeccionar su comportamiento. En este momento el LEAD es eliminado de la tabla de

SUSPECTS y se inserta en la tabla de CUSTOMERS (PROSPECT).

7. Cuando el LEAD entra en el primer estado del pipeline (ver sección V.3.2), se elimina de

la tabla CUSTOMERS y se inserta en la tabla OPPORTUNITIES para administrar su

comportamiento dentro de este proceso.

8. El prospecto realiza su primer envío (paso 6 del pipeline) y se genera entonces una

cuenta para el nuevo cliente. El LEAD es eliminado de la tabla OPPORTUNITIES e

insertado en la tabla ACCOUNTS. A partir de este momento se inspecciona el

comportamiento de la cuenta mediante el 24 meses.

V.4.2 El negocio como una máquina de estados

Definir el negocio como una máquina de estados nos permite realizar un mapa para determinar

en qué estado se encontrará la información más relevante de nuestro sistema en un momento

dado y cuál es el estado siguiente.

Esta máquina de estados muestra el flujo de la información sobre los LEADs a través de las

tablas de COMET (que aparecen en color obscuro con letras claras en el diagrama de la Figura 5-

15) y el pipeline (que se muestra con colores claros y letras obscuras). Un diagrama ampliado se

muestra como referencia en el anexo D.

64

Figura 5-15: Diagrama de estados de LEADs.

Se explica el comportamiento de la información según los estados descritos en el diagrama a

continuación:

1. El LEAD es registrado ya sea en la tabla SUSPECTS o DEVELOPMENT LEADS dependiendo

del tipo de cliente al que se refiera (un cliente nuevo o un cliente existente,

respectivamente).

2. En cualquier caso, cuando el LEAD es aceptado por un ejecutivo de cuenta, se registra

como PROSPECT.

3. El LEAD se registra en la tabla OPPORTUNITIES.

3.1. El LEAD entra en el primer estado del pipeline.

3.2. Se realiza el primer contacto con el cliente. Si el prospecto se muestra

interesado en abrir una cuenta y convertirse en un cliente, entra al segundo

estado del pipeline. En caso contrario, pasa al estado 5 ó 6 dependiendo de su

situación9.

9 Estas referencias indican los pasos en la lista. Los números de estos pasos en el pipeline son: 8 para Unable to Gain

y 9 para Future Opportunity.

65

3.3. El prospecto recibe la propuesta y se sigue el mismo flujo que en el paso 3.2.

3.4. El cliente acepta la propuesta y se le abre una nueva cuenta.

4. El LEAD se registra en la tabla ACCOUNTS.

4.1. La nueva cuenta es implementada y el prospecto se convierte en cliente. Este

puede cambiar su decisión y entrar en los estados 5 ó 6.

4.2. Se realiza el primer envío por parte del cliente. Si después del envío el cliente

decide cancelar su cuenta, entra en los estados 5 ó 6.

4.3. La cuenta se comienza a administrar en el 24 meses. A partir de entonces se

comienzan a calificar los LEADs contra las condiciones de pago para generar

los incentivos correspondientes.

5. El LEAD pasa a este estado cuando las negociaciones para abrir una cuenta no han sido

exitosas.

6. El LEAD pasa a este estado cuando el prospecto no sigue con el proceso pero deja el

campo abierto para futuras negociaciones.

V.4.3 Integración de la funcionalidad con la arquitectura del sistema

Los usuarios del sistema interactúan con documentos ASPX a través de una PC. Los documentos

obtendrán servicios del servidor web por medio de la Intranet de DHL a través de una fachada

que ofrecerá los servicios de la capa de negocio. Dichos servicios, a su vez, utilizarán objetos de

acceso a datos (DAOs) para consultar o introducir información en las bases de datos.

El flujo se describe gráficamente en la Figura 5-16.

66

Figura 5-16: Integración de la funcionalidad con la arquitectura del sistema.

V.4.4 Modelo estático del sistema

El diagrama de clases (Figura 5-17) muestra el modelo del sistema en una representación

orientada a objetos.

67

Figura 5-17: Diagrama de clases.

Este diagrama define el modelo estático del sistema a desarrollar y se encuentra estrechamente

ligado a su base de datos.

68

V.4.5 Reglas de acceso a la base de datos

El acceso a la base de datos se realizará únicamente desde la capa de datos, utilizando para ello

interfaces de DAOs (Data Access Objects).

Existirán en esta capa las interfaces e implementaciones definidas en el diagrama de la Figura 5-

18.

Figura 5-18: Interfaces de objetos de acceso a datos.

IEntidadDao se encargará de tareas comunes de acceso a la base de datos para todas las clases

del modelo estático, denominadas entidades.

69

La Figura 5-19 muestra los métodos de este DAO10, que contienen operaciones para insertar,

actualizar, eliminar y obtener entidades. Los demás DAOs se encargarán del acceso a la base de

datos para el tipo específico de objetos que indica su nombre, con métodos declarados

similarmente.

Figura 5-19: Interfaz del DAO para entidades.

En el siguiente capítulo se expone el detalle de las opciones tecnológicas de implementación de

estas interfaces.

V.4.6 Reglas de negocio

Las reglas de negocio resuelven los requerimientos funcionales definidos en el capítulo IV. El

cumplimiento de las reglas de negocio permitirá que el cliente obtenga la herramienta que

necesita, cumpliendo con el requerimiento R01.

V.4.6.1 Registro de LEADs (R02)

El sistema recibirá los archivos de las tablas en formato de Excel. Los datos serán enviados a la

capa de datos para que sean insertados en la base del sistema.

Se trabajará con un único archivo de Excel separado por hojas, cada hoja representando una de

las tablas de datos de entrada.

V.4.6.2 Reportes gerenciales (R03)

En este apartado se definen los reportes que el sistema deberá generar y los datos requeridos

para cada uno de ellos.

10

Algunos métodos sobrecargados de esta interfaz se han omitido por claridad en la imagen.

70

V.4.6.2.1 Reporte gráfico del pipeline de LEADs y Reporte gráfico de status de LEADs

El requerimiento para ambos reportes se cumplirá mediante una gráfica de barras en la que la

información estará amoldada como muestra la Figura 5-20.

Figura 5-20: Plantilla para el reporte gráfico de LEADs.

Cada barra representa un estado del pipeline, y su altura está definida por la cantidad de LEADs

que se encuentran en dicho estado. La escala a la izquierda de la gráfica define estas cantidades.

Cada uno de los puntos en la gráfica representa el total de ingreso potencial para los LEADs en

cada uno de los estados del pipeline, definidos por la escala a la derecha de la gráfica.

Los reportes siguientes deberán ser generados a partir de este.

V.4.6.2.2 Número de cuentas aperturadas al LEAD

Cada vez que un LEAD es consultado, el sistema calculará el número de cuentas aperturadas al

mismo.

Esta información se obtiene a partir del extracto de COMET ACCOUNTS. Las cuentas que hayan

sido generadas por un mismo LEAD tendrán el mismo LEAD originator.

V.4.6.2.3 LEADs que han abierto cuentas pero no han cumplido con las condiciones de pago

El sistema diferencia entre los LEADs que han cumplido las condiciones de pago y los que no con

una bandera booleana. Dicha bandera comienza en false cuando el LEAD es generado y pasa a

true cuando ha cumplido las condiciones.

71

Los LEADs que hayan abierto al menos una cuenta y tengan esta bandera en false deberán ser

mostrados en este reporte.

V.4.6.2.4 Convertion Rate

El Convertion Rate se obtendrá del porcentaje de LEADs en el sexto estado del pipeline (es decir,

cuentas que hayan realizado su primer envío) contra el total de los LEADs registrados.

V.4.6.2.5 Fuentes actuales generadoras de LEADs

Las fuentes o áreas generadoras de LEADs se definen por las áreas en que laboran los

empleados. El conjunto de áreas definidas se guardará en una lista como las fuentes actuales

generadoras de LEADs.

V.4.6.2.6 Cuentas aperturadas y Cuentas aperturadas por canal

Las cuentas aperturadas son LEADs que han llegado al sexto paso del pipeline y se encuentran

en el 24 meses. El filtro se puede hacer en relación al canal de los empleados.

V.4.6.3 Consulta de status de LEADs (R04)

En la sección de Consulta el usuario contará con un campo de texto, un par de casillas de opción

denominadas Folio y Número de nómina y un botón Aceptar.

En el campo de texto el usuario insertará su número de nómina o el folio del LEAD que desea

consultar, seleccionando la opción correspondiente.

Al presionar Aceptar, el sistema buscará en la base de datos los LEADs relacionados a la

información introducida por el usuario mediante el método sobrecargado obtenerLeads() del

ServicioLeads.

V.4.6.4 Control de usuarios (R05)

El control de usuarios se llevará a cabo mediante un ABC (Altas – Bajas – Cambios) en la sección

Usuarios.

V.4.6.5 Control de condiciones de pago (R06)

Las condiciones de pago se almacenarán en la base de datos como registros en la tabla

CONFIGURACION y serán administrables desde la sección Configurar.

72

V.4.6.6 Actualización de información (R07)

La información será obtenida a partir del layout de datos de entrada entregado por la agencia a

DHL. Este será leído desde la capa de datos mediante el DAO de Excel (IExcelDao).

V.4.6.7 Pago a recursos humanos (R08)

La frecuencia con que se genere el reporte, los destinatarios y los campos que deberá contener

el layout de salida se almacenarán como registros en la tabla de CONFIGURACION y serán

administrables desde la sección Configurar.

V.4.6.8 Noticias y mensajes importantes (R09)

La sección de administración de noticas y mensajes importantes contendrá un editor en línea

HTML WYSIWYG (What You See Is What You Get), desde el cual podrán actualizar la información

de los mensajes y noticias, que se almacenará como texto HTML en la tabla NOTICIA de la base

de datos.

V.4.6.9 Contacto (R10)

La sección de Contacto contará con un campo para escribir comentarios a una dirección de

administrador denominada en la tabla CONFIGURACION, que a su vez será administrable desde

la sección Configuración.

V.4.6.10 Contador de visitas (R11)

El contador de visitas aumentará en cada visita a la página principal, y su valor se almacenará

como un registro en la tabla CONFIGURACION.

V.4.6.11 Envío del status de LEADs por correo electrónico (R12)

Se almacenará el correo electrónico de los empleados con el objetivo de enviar un correo cada

vez que se actualice la información en el sistema (es decir, que se cargue un documento de

datos nuevo) y los LEADs correspondientes cambien de estado.

V.4.4 Uso de las reglas de negocio en la capa de presentación

La capa de negocio proveerá interfaces a servicios que cumplirán con todas las reglas de

negocio, de manera que en la capa de presentación no se codifique ninguna de estas reglas.

73

Los servicios están contenidos en lo que conocemos como fachada, un frente para la capa de

negocio dentro de la capa de presentación. Esto se muestra en la Figura 5-2111.

Figura 5-21: Interfaces de servicios de la capa de negocio.

V.5 Diseño de Interfaces de usuario

V.5.1 Mapa del sitio

El mapa del sitio prototipo se muestra como diagrama en la Figura 5-22, que se puede encontrar

ampliada en el anexo D. Por claridad, la figura sólo se muestra a tres niveles.

Cabe aclarar que los usuarios tendrán acceso a las páginas de su nivel y todas las de los niveles

inferiores, es decir:

• El Administrador tendrá acceso a su área y a las de Superusuario y Empleado.

11

Los nombres de los métodos de los servicios, así como sus implementaciones, se han omitido en el diagrama por motivos de claridad.

• El Superusuario tendrá acceso a su área y a la del Empleado.

• El Empleado sólo tendrá acceso a su área.

La única excepción es el formulario de ingreso, que al no tener sentido mostrarlo para los

usuarios ya ingresados, se mostrará en su lugar un botón

V.5.1.1 Inicio: DHL LEADs

La pantalla de inicio mostrará

sección de Noticias y Mensajes

personalizará mostrando su nombre de usuario.

V.5.1.2 Administrador

Meramente informativo en el diagrama, se muestra para definir los puntos del mapa que serán

accesibles únicamente para los administradores.

Inicio: DHL LEADs

El Superusuario tendrá acceso a su área y a la del Empleado.

El Empleado sólo tendrá acceso a su área.


se mostrará en su lugar un botón Salir para cerrar su sesión.

Figura 5-22: Mapa del sitio.

mostrará información acerca del programa de incentivos, generada en la

icias y Mensajes. Si el usuario que la visita es un usuario registrado, se

personalizará mostrando su nombre de usuario.


para los administradores.

Inicio: DHL LEADs

Administrador

Catálogos

Noticias y Mensajes

Configuración

Bitácora

Superusuario

Reportes

Mi configuración

Empleado

Consulta de estado

Contacto

Ingresar

74


para cerrar su sesión.

información acerca del programa de incentivos, generada en la

. Si el usuario que la visita es un usuario registrado, se


75

V.5.1.3 Catálogos

El administrador podrá ingresar a esta sección para tener acceso a los catálogos de datos del

sistema para empleados, áreas, ejecutivos de cuenta y usuarios. En este último catálogo, tendrá

la opción de crear nuevos usuarios para conceder acceso a las áreas restringidas del micrositio.

V.5.1.4 Noticias y mensajes

Contendrá el módulo de administración de noticias y mensajes importantes que deberán ser

mostrados en el micrositio. Guiará al usuario a través de formularios para crear nuevas noticias

o mensajes, editar existentes o ver el archivo histórico de las mismas.

V.5.1.5 Configuración

Contendrá opciones que permitirán cambiar las configuraciones del sistema: condiciones de

pago de incentivos, correos del personal de Recursos Humanos que debe recibir la información

de los LEADs exitosos, los correos del personal que debe recibir la información de contacto de

los visitantes al micrositio y el módulo de actualización de información. Este último mostrará al

administrador un cuadro de texto para introducir la ruta del archivo de Excel donde se

encuentra la información de los extractos de las tablas de DHL. Junto a este cuadro de texto, un

botón denominado Explorar para buscar en un cuadro de diálogo dicho archivo, y un botón

Actualizar para subir el archivo y comenzar la actualización de información.

V.5.1.6 Bitácora

Muestra un listado de los eventos que han ocurrido en el sistema y, en su caso, el usuario que

generó dicho evento.

V.5.1.7 Superusuario


accesibles únicamente por los administradores y superusuarios.

V.5.1.8 Reportes

Muestra un listado de los reportes descritos en el diseño funcional.

V.5.1.9 Mi configuración

Permitirá al usuario registrado cambiar su perfil y contraseña.

76

V.5.1.10 Empleado


accesibles para empleados de DHL o cualquier usuario que visite el micrositio.

V.5.1.11 Consulta de estado

Formulario que pedirá al usuario un número de folio de LEAD o un número de nómina para

mostrarle el estado del (o los) LEAD correspondiente.

V.5.1.12 Contacto

Formulario que permitirá al usuario escribir dudas, comentarios o inquietudes y enviarlas

directamente a los correos definidos en las configuraciones.

V.5.1.13 Ingresar

Formulario de ingreso para los usuarios registrados. A este podrán ingresar los empleados de

manera directa con un botón, o serán redirigidos al mismo cuando intenten ingresar a una

página que requiera un permiso de mayor nivel que el suyo.

V.5.2 Plantilla de diseño gráfico

El sistema contará con una página maestra que servirá como plantilla para todas las páginas que

compondrán el micrositio del programa de incentivos. Ésta deberá ajustarse al diseño gráfico

mostrado en la Figura 5-23.

El texto mostrado en la imagen es únicamente un ejemplo y no determina el contenido de

ninguna página en específico.

V.6 Resumen

Con la especificación de requerimientos terminada, se procedió a generar un diseño para el

sistema, basado en una arquitectura multicapa y patrones de diseño para hacerlo

completamente modular y reutilizable.

Para la correcta generación del documento de diseño, durante esta fase se llevaron a cabo

reuniones con el cliente en las que se presentaron las reglas de negocio que debería cumplir el

sistema en desarrollo.

77

Figura 5-23: Diseño gráfico de la plantilla del micrositio.

La fase de Elaboración del sistema tuvo una duración aproximada de 56 horas divididas en poco

menos de un mes, realizando las siguientes actividades.

Tabla 5-1: Actividades realizadas en la fase de Elaboración.


Levantamiento de las reglas de negocio con el cliente 18

Análisis de la información 15

Diseño del sistema 15

Desarrollo de arquitectura ejecutable 8

El capítulo siguiente centra su atención en las fases de Construcción y Transición del proyecto,

es decir, las decisiones que se tomaron acerca de la infraestructura tecnológica del sistema, que

llevaron a su programación y finalmente a un periodo de pruebas e instalación en los servidores

de DHL.

Capítulo VI

Construcción e implantación del micrositio LEADs

79

“En los momentos de crisis, sólo la imaginación es más importante que el conocimiento”.

Albert Einstein (1879 – 1955)

VI.1 Las fases de Construcción y Transición del proyecto

El diseño del sistema muestra los lineamientos que deben seguirse para construir el sistema.

Una vez que este artefacto llega a su primera versión, se procede a elegir las herramientas que

serán utilizadas para la programación de la aplicación, lo que corresponde a la fase de

Construcción del proceso de desarrollo RUP (Figura 6-1).

Figura 6-1: Fases de RUP – Construcción.

En la primera parte del presente capítulo se describen las decisiones que condujeron a

desarrollar el proyecto con ciertas herramientas; en la segunda una descripción del modelo de

despliegue del sistema y la administración de la configuración del micrositio, que corresponde a

la fase de Transición del proceso RUP (Figura 6-2).

80

Figura 6-2: Fases de RUP - Transición.

VI.2 Plataforma y herramientas de desarrollo

La fase de construcción de un sistema, es decir, su programación, debe ser la más ágil de todas,

por una razón muy importante: el cliente espera ver resultados, y desafortunadamente, es

precisamente durante esta fase que todo el trabajo se realiza sentado a la computadora.

El análisis y el documento de diseño sirven para guiar a los programadores a través de un

modelo que agilice su trabajo. Sin embargo, en el desarrollo de sistemas empresariales, los

diseños suelen ser muy complejos, tanto que sería imposible intentar implementarlos por

completo antes de que el cliente requiera algún avance.

Es por ello que existen plataformas y herramientas de desarrollo que pueden ser utilizadas para

facilitar el trabajo. En esta sección se examinan las herramientas que serán utilizadas durante la

programación del sistema.

VI.2.1 Plataforma de desarrollo Microsoft .NET 2.0

El marco de trabajo que soportará todo el proyecto será .NET, utilizando ASP.NET con scripts en

lenguaje C# y una DLL (Dynamic Link Library) escrita en el mismo lenguaje.

La decisión fue tomada basándose, por una parte, en el requerimiento del cliente, con el

objetivo de que la herramienta se hospedara en un servidor con Microsoft Windows Server

81

2003, y por otra parte en la experiencia que el equipo de desarrollo ha tenido en otros trabajos

utilizando .NET.

VI.2.2 Persistencia de datos con NHibernate

Una gran cantidad de aplicaciones necesita acceder a datos persistentes. Generalmente se

trabaja con bases de datos relacionales por representar un paradigma establecido y bien

entendido para almacenar información. Sin embargo, existe una falta de acoplamiento entre los

objetos que son usados por una aplicación y los conceptos (las tablas, columnas y tipos de

datos) de una base de datos.

La persistencia de objetos y el acceso a datos se hará a través del Framework NHibernate. Las

características de NHibernate, que lo hacen la mejor alternativa para el mecanismo de

persistencia de nuestro proyecto son:

• Modelo de programación orientado a objetos, con posibilidad de polimorfismo,

herencia, composición y colecciones.

• Capacidad para cualquier nivel de granularidad gracias a las numerosas estrategias de

mapeo entre tablas y objetos.

• Sin necesidad de compiladores externos o modificación de clases al momento de

compilarlas.

• Sin penalización de rendimiento debido a que puede usarse con caches externos y

clusters.

• Soporte para transacciones, ya sea comenzadas por NHibernate o con NHibernate

participando en ellas. En cualquier caso, NHibernate puede remover y reasociar objetos

expulsados de la transacción, además de encargarse del bloqueo de registros.

VI.2.3 Consistencia de componentes con Spring.NET Framework

En los últimos años ha habido un creciente interés en el desarrollo de aplicaciones más ligeras,

con mayor desempeño, de fácil mantenimiento, y sin penalización alguna de infraestructura o

robustez. Este interés ha ganado fuerza debido a los numerosos productos comerciales y libres

llamados lightweight containers, que habilitan la total separación de código de ensamblaje

entre componentes y código de plomería (por ejemplo, el código de apertura de conexiones,

82

cierre de sesiones, comienzo de transacciones, búsqueda de objetos, creación de objetos, carga

de configuraciones y búsqueda de propiedades, entre otros), permitiendo que el desarrollador

solo escriba código que satisfaga los requerimientos de negocio. Dicho código se define en un

archivo XML de configuración que es bastante sencillo de escribir, y para los cuales ya existen

IDEs12 con los que se pueden crear. Este archivo es llamado application context.

VI.2.4 Bitácora de registros con Log4Net

Existe la necesidad en aplicaciones y componentes de enviar en tiempo de ejecución

información a bitácoras. Sin embargo hay muchos APIs13 para bitácoras y es difícil escoger uno

de ellos.

La librería a utilizar para bitácoras es Log4Net, una interfaz ultra delgada entre diferentes

librerías de bitácoras que permite quitar las dependencias de compilación y de ejecución de

dichas librerías.

VI.2.5 Control de versiones con SubVersion

El software para control de versiones provee la administración de cambios y versiones del

código fuente.

La herramienta a utilizar para cumplir con este objetivo de la arquitectura es SVN, el cual cuenta

con una excelente documentación y una muy buena integración con los IDEs más populares.

Las ventajas de SVN sobre otras herramientas similares son:

• SVN utiliza una base de datos, Berkley DB, para el repositorio. Esta característica implica

que con SVN se puede tener accesos concurrentes y actualizaciones atómicas. Una

actualización atómica se refiere al hecho de que si la actualización no es completada o es

interrumpida, el repositorio no queda en estado inconsistente.

• SVN soporta por diseño renombrar y mover archivos y directorios.

12

Integrated Development Environment, o Ambiente Integrado de Desarrollo en español, es un conjunto de herramientas que facilitan la programación o escritura de código al programador. Algunos ejemplos son: Visual Studio, Eclipse y NetBeans. 13

Application Programming Interface, o Interfaz de Programación de Aplicaciones en español, es un conjunto de funciones específicas para una cierta tarea almacenadas en una librería de clases.

83

• SVN funciona sobre HTTP14, por lo que no es necesario abrir puertos en el firewall.

El software cliente a utilizar para revisar los repositorios es Tortoise SVN, de la comunidad Open

Source Tigris.

Algunas de las características más importantes de este producto son:

• Operación vía Web.

• Navegación de directorios en el repositorio.

• Revisión del contenido de los archivos.

• Revisión de diferencias entre versiones de un archivo.

• Búsquedas por autor, fecha, ramas, archivos y comentarios.

• Proporciona reportes, estadísticas y gráficas de la historia de los archivos.

Los programadores tendrán asignadas ciertas implementaciones, que actualizarán en el servidor

cada vez que las terminen, y se realizará un respaldo del repositorio de versiones a cada entrega

satisfactoria con el cliente.

VI.2.6 Otras herramientas de desarrollo

Para cubrir ciertos requerimientos de la capa de presentación en un corto tiempo, se ha

decidido utilizar las herramientas que a continuación se describen.

El componente WebChart para ASP.NET permite la creación de gráficas en diferentes estilos

(gráfica de líneas, de columnas, de áreas, de pie, etc.) que son rendereadas15 en imágenes con

formato PNG, JPG y GIF, entre otros. Este componente será utilizado para generar los reportes

gráficos de LEADs y pipeline de LEADs, mostrando una vista en miniatura de las gráficas cuando

el usuario ingrese en la página de reportes gráficos y una vista ampliada de cada gráfica al pulsar

sobre la misma. Además, las gráficas serán almacenadas en el servidor durante una semana a

partir de la fecha de creación de manera que se encuentren disponibles por FTP para el

administrador del sitio, y posteriormente serán eliminadas por el mismo componente.

14

HyperText Transfer Protocol, o Protocolo de Transferencia de Hipertexto, es el conjunto de estándares definidos para la comunicación en la Web. 15

La palabra Render se refiere al proceso de convertir la información almacenada y procesada en la computadora en una imagen visible para los usuarios.

84

La suite de componentes Obout ofrece controles para generar interfaces de usuario dinámicas

fácil y rápidamente. La paquetería consta de 20 herramientas para generar, entre otros,

calendarios, hojas de cálculo, botones y marcos. En el caso particular del micrositio, se utilizará

el componente HTML Editor para brindar al usuario una interfaz de diseño de noticias y

mensajes importantes estilo WYSIWYG (What You See Is What You Get). Este editor cuenta con

varias ventajas contra la creciente competencia que existe en Internet:

• El código generado por el editor es el mismo cuando se utiliza en diferentes

navegadores.

• Se puede crear estilos CSS para guardar y cargar con el editor, de manera que el usuario

pueda acceder a ellos rápidamente.

• Algunas características pesadas del componente se cargan únicamente cuando son

utilizadas por primera vez, permitiendo que el tamaño de la página y el tiempo necesario

para mostrarla se reduzca.

• La interfaz es personalizable, con lo que se le puede aumentar la funcionalidad para

cargar imágenes al servidor (de manera que el requerimiento R09 se cumpla por

completo).

El Tigra Menu es un componente para generar menús de navegación en sitios web mediante

JavaScript, de gran compatibilidad y muy ligero. Este será utilizado para generar los menús que

verán los distintos usuarios de manera dinámica, obteniendo su configuración de archivos XML,

uno por cada tipo de usuario.

VI.3 Organización y despliegue del sistema

El código fuente del micrositio se encuentra dividido en dos proyectos de Visual Studio 2005

unificados en una misma solución. El proyecto CentralMedia.Dhl.Leads es una librería de clases

que contiene la lógica de las reglas de acceso a base de datos, las reglas de negocio del sistema,

la implementación del modelo estático y algunos componentes comunes utilizados en la capa

de presentación, mientras que el proyecto Web incluye los archivos ASPX que serán mostrados

al usuario con llamadas a la DLL, así como los archivos necesarios para mostrar el micrositio al

usuario.

En esta sección se describe la organización de ambos proyectos.

VI.3.1 El proyecto CentralMedia.Dhl.Leads

El proyecto se encuentra dividido en 4 carpetas como muestra la

Negocio y Vista.

La carpeta Datos contiene en su raíz las clases ExcepcionDeDatos.cs, que define un modelo de

excepciones particulares para los errores ocurridos en la capa de

fábrica de sesiones para acceso a la base de datos que inicializa la configuración de NHibernate

utilizando mapeos XML de las clases del modelo estático definidas en el archivo Datos.xml.

Contiene también dos carpetas nombr

contiene las interfaces de los DAOs que serán expuestas a la capa de negocio, y la carpeta

Implementación contiene, como su nombre lo indica, la implementación de cada una de estas

interfaces, indicando en el nombre de cada clase la tecnología utilizada: JakartaExcelDao,

NHibernateEntidadDao, etc.

Figura 6-3: Estructura de despliegue del proyecto CentralMedia.Dhl.Leads.

La carpeta Modelo contiene las clases que conforman el m

se muestra en la Figura 5-17, en el capítulo V.

Datos

Implementación

Interfaz

En esta sección se describe la organización de ambos proyectos.

.1 El proyecto CentralMedia.Dhl.Leads

El proyecto se encuentra dividido en 4 carpetas como muestra la Figura 6

contiene en su raíz las clases ExcepcionDeDatos.cs, que define un modelo de

excepciones particulares para los errores ocurridos en la capa de datos, y SessionFactory.cs, una



Contiene también dos carpetas nombradas Interfaz e Implementación. La carpeta Interfaz



n el nombre de cada clase la tecnología utilizada: JakartaExcelDao,

: Estructura de despliegue del proyecto CentralMedia.Dhl.Leads.

contiene las clases que conforman el modelo estático del sistema tal como

, en el capítulo V.

CentralMedia.Dhl.Leads

Modelo

Entidad

Negocio

Implementación

Interfaz

85

Figura 6-3: Datos, Modelo,

contiene en su raíz las clases ExcepcionDeDatos.cs, que define un modelo de

datos, y SessionFactory.cs, una



. La carpeta Interfaz



n el nombre de cada clase la tecnología utilizada: JakartaExcelDao,

: Estructura de despliegue del proyecto CentralMedia.Dhl.Leads.

odelo estático del sistema tal como

Vista

Web

86

Dentro de la carpeta Negocio se encuentran las clases que definen los servicios ofrecidos por la

capa de negocio hacia la capa de vista y que hacen uso de las interfaces expuestas en la capa de

datos. Las carpetas Interfaz e Implementación funcionan de manera homóloga a las de la capa

de datos, y de la misma manera se define en la raíz de la carpeta Negocio la clase

ExcepcionDeNegocio, para describir los errores ocurridos en este nivel. En la raíz también se

encuentra la clase UtilidadesDeNegocio, que contiene métodos de uso común en la capa de

negocio, así como la interfaz e implementación de la fachada que proveerá los diferentes

servicios que definen las reglas de negocio del sistema a la capa de presentación.

En la carpeta Vista se definen componentes que serán utilizados por los archivos ASPX de la

capa de presentación. La clase PaginaMaestra será heredada por cualquier página maestra

contenida en el proyecto Web, para incluir la funcionalidad de Spring.NET. De la misma manera,

la clase Pagina será heredada por todas las páginas del micrositio. Esta última incluye

definiciones de la fachada que provee los servicios de negocio, las credenciales del usuario de

sesión, el rol mínimo con que debe contar el usuario para poder acceder a la página, y un URL

de ingreso, al que será redirigido el usuario en caso de no contar con el rol mínimo. Se incluye

también un componente de etiquetas HTML para codificar y decodificar cadenas en formato

HTML antes de mostrarlas, la clase UtilidadesDeVista, que contiene métodos estáticos de uso

común en la capa de presentación, y la clase TigraMenuItems con la que se configura el menú

de JavaScript de manera dinámica mediante archivos XML, dependiendo del rol de usuario de

sesión.

VI.3.2 El proyecto Web

El proyecto Web contiene los archivos que serán instalados en el servidor. Su estructura se

muestra en la Figura 6-4.

La carpeta ASPTreeView contiene archivos de funcionalidad y estilo del componente

ASPTreeView de la suite de Obout, utilizado por el HTML Editor para mostrar menús de

selección.

La carpeta aspx contiene todos los archivos ASPX que serán accesados por los usuarios,

divididos por subcarpetas en los roles mínimos que podrán ingresar a las mismas:

Administrador, Superusuario y Empleado. Todas las páginas ASPX han sido desarrolladas como

clases parciales, utilizando la característica

la funcionalidad inherente de la página de su representación en el navegador.

Figura 6

Dentro de Bin se encuentran todas las librerías de clases utilizadas por el proyecto, incluyendo

el compilado de CentralMedia.Dhl.Leads y las DLLs de Spring.NET y NHibernate.

La carpeta config contiene los archivos XML de configuración para NHibernate (Datos.xml),

Spring.NET (Negocio.xml y Vista.xml) y Log4Net (Log4Net.xml). La subcarpeta

todos los mapeos de NHibernate de las clases del modelo estático a la base de datos del

sistema.

La carpeta estilo contiene archivos CSS de estilos que son utilizados po


clases parciales, utilizando la característica Code Behind de la plataforma .NET 2.0 para separar


Figura 6-4: Estructura de despliegue del proyecto Web.

se encuentran todas las librerías de clases utilizadas por el proyecto, incluyendo


contiene los archivos XML de configuración para NHibernate (Datos.xml),

ng.NET (Negocio.xml y Vista.xml) y Log4Net (Log4Net.xml). La subcarpeta


contiene archivos CSS de estilos que son utilizados por los archivos ASPX.

Web

ASPTreeView

aspx

Administrador

Superusuario

EmpleadoBin

config Mapeos

estilo

logs

media

menu

scripts

usuarios

WebCharts

87


de la plataforma .NET 2.0 para separar


se encuentran todas las librerías de clases utilizadas por el proyecto, incluyendo


contiene los archivos XML de configuración para NHibernate (Datos.xml),

ng.NET (Negocio.xml y Vista.xml) y Log4Net (Log4Net.xml). La subcarpeta Mapeos incluye


r los archivos ASPX.

88

La carpeta logs guarda archivos de texto generados por Log4Net con bitácoras para registro de

sucesos en el proyecto CentralMedia.Dhl.Leads, en NHibernate y Spring.NET.

En la carpeta media se guardan los medios (imágenes, animaciones, videos, etc.) utilizados por

los archivos ASPX, así como los cargados al servidor por los usuarios para las noticias y mensajes

importantes.

En la carpeta menú se almacenan los archivos de configuración XML para generar el menú de

manera dinámica por roles (Administrador.xml, Superusuario.xml y Empleado.xml).

La carpeta scripts contiene archivos de JavaScript de uso común en la aplicación, como el menú

y funciones para generar ventanas emergentes.

La carpeta usuarios contiene el archivo menú.aspx, utilizado por los archivos contenidos en la

carpeta aspx para generar el menú.

En la carpeta WebCharts se almacenarán las gráficas generadas por el componente de reportes

gráficos. El administrador técnico de la aplicación se encargará de dar acceso mediante FTP a

esta carpeta al administrador funcional para descargar los reportes generados.

VI.4 La construcción del software

Para comenzar la construcción del sistema, se tradujo el diagrama Entidad-Relación del diseño a

un script SQL ejecutable para generar la base de datos en el servidor de desarrollo.

Paralelamente, se creó el repositorio de SVN en el mismo servidor para que los desarrolladores

pudieran trabajar siempre con la última versión funcional del sistema en su propia estación de

trabajo, tomando como primera versión la solución con los proyectos de código fuente vacíos.

La escritura de código comenzó configurando una solución que contuviera los proyectos que

conforman el sistema:

1. Proyecto con el código correspondiente a las capas de datos y negocio, modelo estático

y componentes de la capa de presentación. Los archivos se encuentran en una carpeta

de nombre CentralMedia.Dhl.Leads y serán compilados como una librería de clases, que

será transferida a la carpeta Bin del segundo proyecto.

89

2. Proyecto con el código correspondiente a la capa de presentación. Los archivos se

encuentran en una carpeta de nombre Web.

Una vez compilada la solución, los archivos a transferir al servidor son los de la carpeta Web.

A continuación, se agregaron los elementos de la arquitectura, integrando los DLLs necesarios y

configurando la aplicación mediante la generación de los archivos Web.config (para establecer

los valores de configuración del directorio y subdirectorio virtuales, reemplazando los valores

del archivo Machine.config, que aplica para todo el servidor, garantizando que los valores

requeridos sean adecuados), Global.asax (que contiene código para responder a eventos de

nivel de aplicación provocados por ASP.NET o por módulos http, utilizado en este caso para

disparar la inicialización y configuración de Log4Net) y Log4Net.xml (archivo con las

configuraciones de Log4Net: los archivos que serán utilizados para almacenar los registros de

bitácora y su tamaño máximo, entre otros). En esta misma versión, se crearon los archivos de

configuración vacíos Datos.xml (contexto de la aplicación para la capa de datos), Negocio.xml

(contexto de la aplicación para la capa de negocio) y Vista.xml (contexto de la aplicación para la

capa de presentación).

Una vez que se tuvo la arquitectura ejecutable del sistema montada, se comenzó a escribir el

código fuente, creando las clases del modelo estático siguiendo el diagrama establecido en el

diseño y, terminando las clases, sus respectivos mapeos de NHibernate en archivos XML

separados. Se creó la fábrica de sesiones para la base de datos como una clase en la capa de

datos del proyecto DLL, heredando la clase LocalSessionFactoryObject del módulo de

NHibernate para Spring.NET e inyectándole los mapeos y el proveedor de la base de datos (que

incluye la cadena de conexión) mediante el contexto de la aplicación de la capa de datos. Para

terminar de montar lo que sería la base del sistema, se escribieron las interfaces de los DAOs y

servicios, basándose en los nombres de los módulos descritos en el diseño del sistema. A cada

programador se le encargó la implementación de uno o varios métodos de dichas interfaces,

comenzando así con la parte fuerte de la programación. Con el objetivo de probar

tempranamente la funcionalidad del sistema, la primera implementación fue el acceso a

archivos de Excel mediante Jakarta, un proyecto de código abierto de la fundación Apache para

90

acceso a este formato. Las pruebas se realizaron con archivos de datos de LEADs reales

provistos por el cliente. A continuación se implementó el acceso a la base de datos mediante

llamadas simples a NHibernate, seguido de los servicios de la capa de negocios y páginas ASPX

de prueba para dichos servicios. En este momento se comenzó a implementar la capa de

presentación que el usuario vería más adelante.

Se implementó el diseño gráfico de las interfaces en un archivo HTML, que posteriormente se

convertiría en la página maestra. Los primeros ASPX en ser implementados, cuando la página

maestra fue terminada, fueron los de registro de usuarios, con los que se ingresaron a la base

de datos dos usuarios que serían utilizados por los desarrolladores para realizar pruebas,

seguidos de las páginas necesarias para el ingreso de usuarios registrados y para recuperación

de contraseñas perdidas. Estas últimas requerirían el uso del servidor SMTP para enviar correos

con las nuevas contraseñas a los usuarios, por lo que de manera paralela se implementó el

módulo de Contacto.

El menú dinámico se implementó a continuación, generando distintos botones para los

diferentes roles.

Los archivos de prueba fueron modificados para incluir el diseño y funcionalidad de la página

maestra, obteniendo así el módulo de actualización de información completo, que fue probado

con los módulos de consulta de estado y reportes, implementados después.

Por último, las secciones de noticas y mensajes importantes, así como los reportes gráficos,

fueron implementadas por un mismo programador mientras los demás escribían el código

fuente descrito anteriormente, debido a la complejidad de los componentes de reuso.

VI.5 Esquema de pruebas del sistema

Las pruebas del sistema comenzaron a realizarse muy temprano durante la construcción del

micrositio, en un ambiente de desarrollo. El sistema fue a su vez publicado en Internet a través

del servidor web del equipo de desarrollo para que el cliente tuviera acceso a él y pudiera

probarlo en cualquier momento, y los archivos fueron actualizados con cada nueva versión

implementada por los programadores.

91

Mientras la funcionalidad era implementada, los mismos programadores realizaban pruebas

utilizando el sistema en secciones escritas por sus compañeros. Una vez asegurados de que no

existieran errores, se avisaba al cliente para que este pudiera probarlo o asignar a un usuario

para este fin.

Con el objetivo de efectuar pruebas con datos reales para el módulo de actualización de

información, se pidió al cliente un archivo de los datos que sirven de entrada al sistema.

Durante la construcción del sistema, estos datos fueron ligeramente manipulados para eliminar

información inservible y que podría causar ruido durante el desarrollo.

El sistema terminado fue instalado en dos servidores de pruebas de DHL, donde los usuarios

reales comenzaron a utilizarlo, actualizando la información desde los mismos archivos utilizados

por el equipo de desarrollo, esta vez sin modificaciones.

Todos los errores encontrados eran reportados vía correo electrónico al líder de proyecto, quien

los documentaba en una lista que sería asignada a los programadores.

Cuando el cliente estuvo satisfecho del funcionamiento de la aplicación, se mudó el sistema al

ambiente de producción de DHL.

VI.6 Características del servidor y protocolo de instalación

El micrositio es capaz de correr en un servidor con las siguientes características mínimas:

• Doble procesador Intel Xeon o compatible a 2.8GHz.

• 2GB de memoria RAM.

• 25MB de disco duro para la instalación de archivos del sistema. Espacio adicional es

requerido para la generación de reportes gráficos, carga de medios al sistema y registros

de la base de datos.

• Microsoft .NET Framework 2.0.

• Microsoft SQL Server 2000.

• Microsoft Windows Server 2003 con IIS 6 o superior.

• Microsoft Visual J# Redistributable Package versión 2.0.

92

Para realizar una instalación manual de la aplicación se deben seguir los siguientes pasos:

1. Copiar los archivos del proyecto Web a la carpeta de instalación en el servidor.

2. Configurar el archivo Datos.xml de la carpeta config con los datos de conexión a la base

de datos, sustituyendo los valores en la cadena de conexión.

<property name=”ConnectionString” value=”Data Source=SERVIDOR_DE_BASE_DE_DATOS; Database=NOMBRE_BASE_DE_DATOS; User ID=USUARIO_DE_BASE_DE_DATOS; Password=CONTRASEÑA_DE_USUARIO; Trusted_Connection=True”/>

3. Configurar el archivo Negocio.xml de la carpeta config con los datos de acceso a correo

electrónico mediante SMTP, sustituyendo los valores mostrados:

<property name=”ServidorSmtp” value=”URL_SERVIDOR” /> <property name=”PuertoSmtp” value=”NUMERO_PUERTO” /> <property name=”RequerirAutenticacionSmtp” value=”true” /> <property name=”DireccionDelSistema” value=”DIRECCION_DE_CORREO” /> <property name=”UsuarioSmtp” value=”USUARIO_DE_CORREO” /> <property name=”ContrasenaSmtp” value=”CONTRASEÑA_DE_CORREO” />

4. Crear la base de datos en el servidor y ejecutar el script leads.sql para generar las tablas

y los datos iniciales.

5. Crear la aplicación en el servidor IIS desde la carpeta virtual (la carpeta de instalación).

6. Configurar la aplicación como exclusión del servidor SharePoint para que esta sea

manejada exclusivamente por el servidor IIS.

VI.7 Resumen

En la fase de construcción el sistema fue programado sobre la arquitectura diseñada en la fase

de elaboración, en base a los lineamientos establecidos en el documento de diseño.

Las tareas realizadas se muestran en la Tabla 6-1 como módulos, incluyendo en su mayoría las

subtareas de desarrollo de la capa de datos, negocio y presentación, así como sus pruebas en

ambiente de desarrollo. El tiempo mostrado es la suma de los esfuerzos de todo el equipo de

desarrollo, quienes en un plazo de 2 meses concluyeron la fase de construcción, cumpliendo un

total de 178 horas de trabajo efectivas.

93

Tabla 6-1: Actividades realizadas en la fase de Construcción.


Diseño de interfaz gráfica 10

Adaptación de la interfaz para web 10

Módulo de Contacto 5

Gestión de usuarios 18

Módulo de Noticias y Mensajes Importantes 20

Módulo de Catálogos 15

Módulo de Actualización de Información 30

Módulo de Configuraciones 8

Módulo de Reportes 25

Reporte Gráfico de LEADs 10

Módulo de Bitácora 4

Módulo de mensajería para correos electrónicos 8

Durante la fase de Transición se realizaron las pruebas del sistema en versión beta16,

corrigiendo los errores y defectos encontrados por los usuarios.

Esta fase final tuvo una duración aproximada de 23 horas, cumplidas en un lapso de un mes. Las

actividades realizadas se muestran en la Tabla 6-2.

Tabla 6-2: Actividades realizadas en la fase de Transición.


Pruebas de instalación en servidores de pruebas 10

Pruebas de usuario al sistema 12

Instalación en el servidor de producción 1

16

Se refiere a una versión del producto terminado preliminar a su lanzamiento. Se considera la última etapa de pruebas.

Capítulo VII

Resultados

95

“Experiencia es el nombre que la gente da a sus errores”.

Oscar Wilde (1854 – 1900)

VII.1 Recopilación de experiencias y resultados

Este capítulo final se divide en tres partes.

La primera parte es un relato personal del autor de la experiencia proveedor-cliente desde la

perspectiva del líder de proyecto de sistemas, trabajando desde una fábrica de software (la

agencia).

En la segunda sección se verán los resultados obtenidos en la versión 1.0 de la aplicación, que

cumplió con el objetivo inicial del proyecto, y la manera en que el diseño propuesto ayudó a

liberar rápidamente la versión 1.1, basada en un requerimiento adicional del cliente durante la

fase de transición.

Finalmente, una descripción de los trabajos a futuro impulsados por el proyecto actual,

mencionando algunas mejoras que podrían implementarse en el micrositio, así como la

capacidad de aplicación de los métodos y técnicas utilizados en futuros desarrollos.

VII.2 La experiencia con el cliente

El inicio del proyecto fue el día 6 de diciembre de 2006, cuando el cliente entregó la lista de

requerimientos que fue la base para comenzar el desarrollo.

La idea era comenzar a generar el plan de desarrollo y el documento de requerimientos en los

días subsecuentes a la reunión mencionada. No obstante, el inicio formal del proyecto se

demoró hasta mediados de enero por cuestiones administrativas. El presupuesto entregado por

la agencia no había sido aprobado por DHL y por lo tanto no se tenía autorización para

continuar. Esto fue motivo de una llamada desconcertante la segunda semana de enero de

parte del cliente que preguntaba por los avances del proyecto. Se le explicó la situación y ese

96

mismo día tomó las acciones necesarias para que el presupuesto fuera aprobado y el desarrollo

pudiera comenzar.

Inicialmente, por parte de DHL se asignaron 2 personas para llevar el seguimiento del proyecto:

el gerente de Televentas como líder de proyecto del negocio, y un empleado de IT para servicio

al cliente (el líder técnico), para dar seguimiento a los detalles técnicos. Por su parte, el gerente

de Adquisiciones y experto en el flujo de trabajo de LEADs daría su apoyo para realizar el

modelado del negocio.

Para comenzar, se realizó una reunión en la que el gerente de Adquisiciones explicó el pipeline

de LEADs y, por otra parte, se comentó con el líder técnico que para dar inicio al proyecto era

necesario un documento de requerimientos y que, la agencia como proveedor, podría

adaptarse a cualquiera que fuera su forma de trabajar, ya fuera que ellos dentro de DHL

generaran el documento, que se realizara en la agencia con la información adquirida hasta ese

momento, o que se realizara en conjunto entre el cliente y el proveedor. El líder técnico

respondió que él contaba con ciertos documentos relacionados con los requerimientos del

nuevo sistema y que los enviaría al día siguiente para organizar después una reunión en la que

se escribieran los requerimientos iniciales. Pasaron tres días y los documentos no llegaban, así

que se le envió un correo para solicitárselos nuevamente, explicando que sin ellos no se podría

continuar con el desarrollo. La respuesta fue bastante inesperada, pues no mencionaba los

documentos requeridos, en contraparte, preguntaba por los avances que se hubieran realizado

en la agencia.

La situación se expuso ante el director general de la agencia, quien comprendió lo que estaba

sucediendo, y se acordó escribir un documento de requerimientos en el menor tiempo posible

para enviarlo, a pesar de que el trato había sido generarlo conforme a los documentos que no

fueron recibidos.

El día siguiente, a primera hora de la mañana, se envió el documento generado, que fue

aprobado por el cliente y se convirtió en la versión 0.1 del documento oficial de requerimientos

para el proyecto.

97

Siguió una etapa de entrevistas con el cliente para detallar los requerimientos, donde se

presentaron principalmente dos problemas. En primer lugar, la disponibilidad tanto del cliente

como del proveedor para reunirse tan seguido como hubiera sido lo ideal para concluir

rápidamente con lo que se denominó fase de inicio del proyecto. En segundo lugar, hubo

cambios internos en DHL y el liderato del proyecto pasó a manos del gerente de Adquisiciones,

además de que localizar al líder técnico de DHL para revisar los detalles técnicos de los

requerimientos fue prácticamente imposible desde entonces y hasta el final del proyecto.

Este último detalle tuvo como repercusión que, como el proyecto no podía ser detenido, se tuvo

que seguir adelante asumiendo que las decisiones de la agencia (que a fin de cuentas eran

responsabilidad del líder de proyecto) eran adecuadas.

La versión 1.0 del documento de requerimientos se concretó en los últimos días de febrero.

Cabe recalcar que uno de los requerimientos era que el sistema debía ser compatible con

SharePoint 2003 para poder integrarse a la Intranet de DHL, donde finalmente residiría el nuevo

sistema. El líder de proyecto no contaba con experiencia en el uso de SharePoint ni en el

desarrollo de aplicaciones compatibles con el mismo. Consultó entonces con un compañero de

la oficina, quien anteriormente había desarrollado un sistema integrado a SharePoint, para

preguntar si la arquitectura del sistema tendría alguna restricción por tener que ser compatible

con este servidor de aplicaciones. El respondió que el desarrollo de la aplicación en la que él

estuvo involucrado, se llevó a cabo como cualquier otro desarrollo en ASP.NET y finalmente sólo

se agregaron las ligas en SharePoint.

El desarrollo continuó con la fase de Elaboración, donde se obtuvo el diseño del sistema en base

a los requerimientos y reuniones con el cliente que se tuvieron durante esta fase. Ya con el

diseño creado, se estableció la arquitectura ejecutable del sistema en un proyecto de Visual

Studio 2005 y fue montado en el repositorio SVN de la empresa, de manera que todos los

programadores pudieran descargarlo, implementar el sistema y aplicar los cambios realizados

de una manera segura e integrada.

Para la implementación del sistema participaron dos programadores, además del líder de

proyecto. Durante las dos primeras semanas de esta etapa, el líder tuvo que delegar toda la

98

responsabilidad sobre la programación a ellos, dado que otro proyecto que también estaba

dirigiendo, comenzó una fase intensa de pruebas por parte del cliente y había varios errores que

necesitaban atención. Se entregó la documentación existente hasta el momento a los

programadores y les se les explicaron sus tareas, confiando que, aunque no pudiera supervisar

el desarrollo durante algún tiempo, este siguiera su curso. Sin embargo, pasadas las dos

semanas, cuando por fin descargó los cambios a su computadora y revisó el código fuente, no

había nada funcional, e incluso muchos de los procesos estaban mal definidos.

La corrección de estas fallas demoró otras dos semanas, cuando empezó a presentarse cierta

presión por parte del cliente para ver al menos una parte del sistema funcionando.

Afortunadamente, paralelo a la programación del sistema se llevó a cabo el desarrollo de las

interfaces de usuario por parte del diseñado web que apoyó al equipo de desarrollo, así que,

aunque no se mostró un sistema funcional, se mostró el layout de la aplicación final, y permitió

que el desarrollo continuara sin contratiempos.

El sistema siguió siendo construido, teniendo varias reuniones para revisar avances y lograr que

el sistema funcionara tal cual las necesidades reales del cliente.

La construcción de la aplicación estaba en sus últimas etapas, y llegó el día en el que se tenía

que instalar en un servidor para ser probado por personal de DHL como versión beta.

La idea original era instalarlo en el servidor de la agencia en una etapa de pruebas muy

temprana para que pudieran acceder a través de Internet, luego instalarlo en un servidor de

pruebas dentro de la Intranet de DHL, que sería una réplica exacta del servidor de producción y

finalmente, cuando se hubiera validado como un sistema apto para ello, se migraría a

producción. El inconveniente fue que el servidor de la agencia comenzó a presentar problemas

con los servicios de aplicaciones y mucha de la funcionalidad del sistema se veía entorpecida.

La situación fue explicada al cliente, quien ofreció otro servidor (propio) para instalar la

aplicación y realizar las primeras pruebas. De esta manera, se instaló el sistema en dicho

servidor exitosamente.

99

Más adelante, el sistema debía ser instalado en el servidor de pruebas de DHL. Para ello se

requería el apoyo del personal técnico de la misma empresa, no obstante, y como se describió

anteriormente, la persona que iba a estar apoyando en esa parte desertó el proyecto en sus

inicios. El gerente de Adquisiciones de DHL consiguió que se asignara otra persona, que acababa

de incorporarse a su empresa.

Dado que esta persona no tenía ningún conocimiento sobre el sistema, hubo que explicárselo

desde el principio, lo cual retrasó la instalación. Cuando finalmente se presentó la instalación en

el servidor de pruebas, se dieron varios errores fatales. El proceso de instalación no pudo ser

terminado ese día, y el equipo se dedicó a investigar la razón de estos errores. Era la primera

vez que se presentaban, ya que el sistema, en otros ambientes, funcionaba perfectamente. Se

encontró que se debía precisamente a un problema de compatibilidad de ASP.NET 2.0 con

SharePoint. La noticia causó gran revuelo, puesto que, por cuestiones de tiempo y dinero, no

podía reiniciarse la construcción de la aplicación en otra plataforma en caso de que no se

encontrara una solución. Ya que no tenía experiencia en el tema, el líder de proyecto contactó

con el administrador de SharePoint de DHL para llegar juntos a una solución, pero se encontró

con que no existía un administrador, y las únicas personas que podrían haber apoyado eran

precisamente las dos con las que se había tenido contacto en la parte de soporte técnico.

Después de mucho investigar en Internet, la respuesta que se recibió en un foro fue que el sitio

donde residiría la aplicación debía ser excluido del servidor de aplicaciones de SharePoint, junto

con las respectivas instrucciones paso a paso. Estas instrucciones fueron realizadas y el sistema

por fin quedó funcionando en el servidor de pruebas.

Se dejó en pruebas durante algún tiempo, en el cual, como era de esperarse, surgieron detalles

que debieron ser corregidos, aunque por fortuna, fueron todos muy pequeños.

Finalmente, después de una serie de pruebas exhaustivas dentro de DHL, se instaló el sistema

en el servidor de producción sin mayores contratiempos, contemplando aquellas circunstancias

que resultaron anteriormente en una instalación fallida en el servidor de pruebas.

100

Actualmente, el software es utilizado por una buena parte del personal de DHL a nivel nacional,

incluyendo las áreas de Adquisiciones, Televentas y los couriers, para administrar el programa

de incentivos.

VII.3 Resultados

En esta sección se reúnen los resultados del proyecto, que hasta el momento se ha enfocado en

el proceso llevado a cabo para liberar la versión 1.0 del producto con el cliente. Continuando

con los resultados, se explicará el nuevo requerimiento del cliente, las decisiones que fueron

tomadas durante su desarrollo y el proceso adoptado para la liberación de la versión 1.1.

VII.3.1 Versión 1.0

Cuando los casos de uso definidos en el documento de requerimientos, elaborado en la fase

inicial del proyecto, fueron completamente implementados, el sistema fue implantado en el

servidor de pruebas del cliente. Hubo correcciones mínimas, que se relacionaron principalmente

con problemas de configuración del servidor y algunos cambios de estilo en el diseño gráfico del

micrositio.

El sistema fue probado con archivos de datos reales de LEADs de fechas anteriores a la

instalación elegidos por el cliente, mismos que fueron usados durante las pruebas que realizó el

equipo de desarrollo, por lo que, una vez que el sistema fue instalado en pruebas siendo una

réplica exacta del contenido del servidor en la agencia, no se presentaron complicaciones en

cuanto al tratamiento de los datos, según el informe del personal que realizó las pruebas dentro

de DHL.

De la experiencia adquirida durante la instalación del sistema en el servidor de pruebas, se

obtuvo un completo protocolo de instalación que fue documentado y utilizado para la

implantación en el servidor de producción. Al dar este importante paso, la base de datos de

pruebas ya contenía información relevante para el cliente, quien decidió que el sistema

comenzara con ella como datos iniciales para producción. En otro escenario, esta decisión

hubiera supuesto realizar una réplica de la base de datos de pruebas para pasarla a producción,

o reemplazar diversas líneas de código presentes en todo el proyecto. Sin embargo, gracias a la

101

arquitectura utilizada, el sistema pudo ser copiado directamente del servidor de pruebas sin

realizar ningún cambio en el código.

La implantación del sistema en la empresa cliente reportó importantes beneficios al

automatizar el flujo de trabajo de LEADs, eliminando procesos manuales que hasta antes del

desarrollo del micrositio llegaban a tomar hasta 30 horas de trabajo. Ahora, los empleados

cuentan con una herramienta de información que les permite consultar el estado actualizado de

sus LEAD formats ingresados en unos cuantos clicks. Por su parte, los administrativos de la

empresa cuentan con una herramienta confiable que les permite conocer los beneficios reales

del programa y modificarlo de acuerdo a dichos beneficios. La herramienta sirve también como

una solución de comunicación entre empleados y administrativos mediante las secciones de

Noticias y Mensajes Importantes y Contacto, así como los correos que genera para informar a

los usuarios de la actividad relevante para ellos; además, ha permitido realizar los pagos de

LEADs exitosos una vez que cumplen con las condiciones y el sistema genera la petición para

recursos humanos, proceso que solía tardar hasta 6 meses dado que la información obtenida de

las diversas fuentes debía ser conciliada manualmente, y ello se sometía a la disponibilidad del

personal de Televentas. El cliente se ha beneficiado de la misma manera con la documentación

del producto, ya que describe un flujo de trabajo que hasta la fecha no se tenía por escrito.

Así es cómo, esta primera versión del producto terminado, satisface las necesidades iniciales de

DHL y presenta, mediante su uso como una herramienta para el proceso de LEADs los beneficios

esperados. La información del micrositio depende ahora mínimamente de la interacción

humana, ya que los datos deben ser actualizados mediante la carga de archivos de Excel

generados en COMET e IBS.

VII.3.2 Versión 1.1

Durante la fase de transición, en el periodo de pruebas del sistema, el cliente solicitó un nuevo

requerimiento, en el que el sistema debe permitir la captura directa de LEADs por parte de los

empleados. Para mantener la documentación como se había estado manejando hasta ese

momento y llegar a un acuerdo económico razonable, se le pidió al cliente redactar una solicitud

102

de cambio (mostrada en el anexo E) donde expusiera los detalles y que serviría de base para

plantear su implementación, nuevamente mediante la metodología RUP.

Se realizó un plan de trabajo para liberar la versión 1.1 que incluye este nuevo requerimiento,

en 2 semanas. Debido a la petición del cliente de no impactar el código ya implementado, el

desarrollo fue tratado como un nuevo proyecto, únicamente consumiendo cierta funcionalidad

de la versión 1.0, desde una nueva DLL, y agregando los archivos ASPX correspondientes a las

nuevas páginas para capturar LEADs (en un ámbito de empleado) y listas de valores, así como de

aprobación de los LEADs capturados (en el ámbito del administrador funcional).

La base de datos original tampoco fue modificada, simplemente se agregaron 4 tablas que

dependen de las originales, como se muestra en la Error! Reference source not found..

Figura 7-1 Diagrama entidad-relación de la versión 1.1.

Dentro de la nueva DLL se agregaron las clases correspondientes a LeadComet, LovEstado,

LovTitulo y LovTipoContacto, y el acceso a la base de datos para estas entidades fue reutilizado

103

del DAO de entidades genéricas en la DLL original, eliminando así cualquier código de acceso a

datos desde el nuevo proyecto.

Se agregaron nuevos servicios en la capa de negocio para las nuevas entidades y se generó una

nueva fachada que reúne dichos servicios y hereda los originales de la fachada anterior, con lo

que el proyecto DLL original quedó intacto, y la versión 1.1 pudo ser liberada en tiempo y forma.

VII.4 Trabajos a futuro

La herramienta desarrollada tiene un uso muy particular para la empresa cliente. Sin embargo,

los métodos y técnicas utilizadas, así como la documentación y el código escrito, tienen una

amplia aplicación tanto para mejorar la herramienta como para futuros desarrollos de sistemas.

En esta sección se proponen algunos ejemplos.

VII.4.1 Mejoras al producto

El sistema, como se mencionó en la sección anterior, ha resultado en flujos de trabajo más

eficientes que permitirán, eventualmente, recuperar la confianza en el programa de incentivos

por parte de los empleados de DHL. No obstante, y debido a políticas de confidencialidad dentro

de la empresa cliente, los procesos de actualización de información siguen siendo manuales,

dependiendo de la disponibilidad del gerente de Adquisiciones, quien ahora se encarga de

generar los archivos de actualización en COMET e IBS y cargarlos en el micrositio.

Este proceso de actualización puede ser automatizado, conectando directamente el sistema a

las bases de datos correspondientes, y el sistema está preparado para ello. Después de analizar

los sistemas y detectar las tablas y los campos requeridos durante la actualización de

información, se pueden generar vistas para ser consultadas por el micrositio sin necesidad de

modificarlas. En cuanto a los cambios necesarios en el código fuente, gracias a las bondades de

NHibernate, solamente sería necesario realizar modificaciones mínimas en los mapeos y generar

el proveedor de las nuevas bases de datos en el application context. Para el acceso a datos se

deberá entonces descartar el objeto de acceso a datos de Excel y utilizar en su lugar la interfaz

IEntidadDao, que en este desarrollo ya ha sido implementada.

104

La aplicación del desarrollo en cuanto a mejoras al producto es, hasta la fecha, únicamente

teórica, dado que para llevar a cabo las modificaciones es necesario fijar acuerdos cliente-

proveedor con DHL en cuanto a los costos, tiempos y políticas de privacidad, entre otros, para

firmar un contrato que dé inicio a las nuevas implementaciones, de la manera en que se

estipuló para el desarrollo de la versión 1.1

VII.4.2 Extrapolación de buenas prácticas

En proyectos de software genéricos, particularmente aquellos basados en web, la arquitectura

puede ser reutilizada para agilizar los desarrollos. De hecho, dentro de la empresa en la que se

desarrolló el sistema, al término del proyecto se ha comenzado a construir un proyecto genérico

vacío basado en la arquitectura del micrositio, que permitirá enfocarse en las reglas de negocio

de los clientes, mientras que con cada proyecto que lo utilice se podrá robustecer mediante el

estudio y utilización de otros patrones de diseño y herramientas de reuso que faciliten su

aplicación.

La documentación generada para DHL puede ser utilizada para que la empresa de mensajería

evalúe el flujo de trabajo y el programa de incentivos como tal y realice las correcciones que les

parezcan pertinentes, y que puedan o no afectar al sistema desarrollado.

Finalmente, en el ámbito académico, se espera que este trabajo sea una herramienta útil para el

lector, como referencia para la automatización de flujos de trabajo y desarrollos de sistemas de

información basados en buenas prácticas.

Conclusiones

106

Conclusiones

La solución informática entregada al cliente consiste en una serie de artefactos relativos al

proyecto, entre los que se encuentran la especificación de requerimientos, la especificación de

diseño y el sistema que cubre las necesidades del negocio.

El desarrollo se llevó a cabo siguiendo los lineamientos establecidos por la metodología de

desarrollo RUP, utilizando una configuración de baja ceremonia dado que el alcance del

proyecto no ameritaba generar todos los artefactos propuestos. Esto permitió mantener una

comunicación adecuada entre desarrolladores (quienes se encargan de la parte técnica de la

solución) y stakeholders (quienes proveen las reglas de negocio), lo que fue crucial para la

liberación del producto en tiempo y forma.

La arquitectura establecida fue también decisiva para este fin, pues permitió a los

desarrolladores enfocar sus esfuerzos en solventar los requerimientos. Por su parte, la

plataforma tecnológica utilizada ayudó a la rápida implementación de esta arquitectura durante

la fase de elaboración, así como a sus posteriores ajustes durante la fase de construcción, luego

de que los programadores hubieran cubierto la curva de aprendizaje de los componentes de

reuso en proyectos anteriores.

El diseño del sistema mostró su efectividad antes de lo esperado, cuando se aprobó un nuevo

requerimiento por parte del cliente durante la última fase del proceso de desarrollo. Se logró

reutilizar diversos componentes construidos previamente, en especial aquellos de acceso a

datos, logrando que la solución se desarrollara en el corto tiempo requerido para liberarla,

anexando las nuevas reglas de negocio y dejando el código ya escrito intacto.

107

Bibliografía y obras electrónicas

[ABRAHAMSSON, 2002] ABRAHAMSSON, Pekka; Outi Salo; Ronkainen [et. al] Agile Software

Development Methods: Review and Analysis Oulu, Finlandia: VTT Publications 478, 2002.

ABRAN, Alain; James Moore Guide to the Software Engineering Body of Knowledge

Washington, EUA: IEEE, 2004.

[BROWN, 1998] BROWN, William J.; Raphael C. Malveau; Thomas J. Mowbray [et. al]

AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis Wiley, 1998.

CHIBA, Shigeru; Rei Ishikawa Aspect-Oriented Programming Beyond Dependency Injection

Tokyo, Japón: Dept. of Mathematical and Computing Sciences, Tokyo Institute of Technology,

2005.

[CHURCHER, 2007] CHURCHER, Clare Beginning Database Design: From Novice To

Professional, Designing databases for the desktop and beyond Nueva York, EUA: Apress, 2007.

[DPWN, 2005] The Story of DHL Deustche Post World Net, 2005.

[DPWN, 2008-1] DHL: Historia en México Deustche Post World Net, 2008. Último acceso: 13 de

febrero de 2008. URL: http://www.dhl.com/publish/mx/es/AboutDHL/dhl_mexico.high.html

[DPWN, 2008-2] Divisiones DHL Deustche Post World Net, 2008. Último acceso: 13 de febrero

de 2008. URL:

http://www.dhl.com.mx/publish/mx/es/AboutDHL/Divisiones_DHL_new.high.html

ERIKSSON Hans-Erik, Magnus Penker Business Modeling with UML: Business Patterns at Work

EUA: John Wiley & Sons, Inc., 2000.

[GAMMA, 1995] GAMMA, Erich; Richard Helm; Ralph Johnson [et. al] Design Patterns: Elements

of Reusable Object-Oriented Software Addison Wesley, 1995.

[GONZALEZ, 2006] GONZALEZ, Raúl Vicente Inyección de dependencias con Spring

Programanía, 2006. Último acceso: 12 de febrero de 2008. URL:

108

http://www.programania.net/patrones-de-diseno/inyeccion-de-dependencias/inyeccion-de-

dependencias-con-spring/

[KREBS, 2008] KREBS, Joe RUP in the dialogue with SCRUM IBM developerWorks, 2008. Último

acceso: 29 de octubre de 2008. URL: URL: http://www-

128.ibm.com/developerworks/rational/library/feb05/krebs/

[IEEE, 1990] IEEE Standard Glossary of Software Engineering Terminology Nueva York, NY, EUA:

IEEE, 1990.

[KROLL, 2003] KROLL, Per; Philippe Kruchten The Rational Unified Process Made Easy: A

Practitioner’s Guide To The RUP Boston, EUA: Addison Wesley, 2003.

[MAVERICK, 2008] maverick DHL Emerging Markets – Reactivator, Rise of the sales Internal

Branding maverick, 2008. Último acceso: 29 de octubre de 2008. URL:

http://www.mavad.co.uk/internal-communications/portfolio/internal-comms/reactivator/rise-

of-the-sales

[NAUR, 1969] NAUR, Peter; Brian Randell Software Engineering: Report on a conference

sponsored by the NATO Science Committee Bruselas, Bélgica: OTAN, 1969.

NHibernate Reference Documentation NHibernate, 2008. Último acceso: 17 de febrero de

2008. URL: http://www.hibernate.org/hib_docs/nhibernate/1.2/reference/en/html/

POLLACK, Mark; Rick Evans; Aleksander Seovic [et. al] Spring.NET Reference Documentation

version 1.1 RC2 Spring.NET Framework, 2007. Último acceso: 12 de febrero de 2008. URL:

http://www.springframework.net/doc-latest/reference/pdf/spring-net-reference.pdf

[RUMBAUGH, 2000] RUMBAUGH, James; Ivar Jacobson; Grady Booch El Lenguaje Unificado de

Modelado: Manual de Referencia Madrid, España: Pearson Educación, 2000.

[SUN, 2002] Sun Microsystems Design Patterns: Data Access Object Sun Developer Network,

2002. Último acceso: 12 de febrero de 2008. URL:

http://java.sun.com/blueprints/patterns/DAO.html

109

[SUN, 2008] Sun Microsystems Core J2EE Patterns – Data Access Object Sun Developer

Network, 2008. Último acceso: 12 de febrero de 2008. URL:

http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html

VÄSTERNAS, Jan Dependency Injection in Action Callista Enterprise, 2006.

Anexos

Anexo A

Catálogo de patrones de diseño orientado a objetos

112

Nota: El catálogo mostrado en este anexo es una síntesis de [GAMMA, 1995]. Para una

descripción completa de los patrones es recomendable referirse a este libro.

Patrones de creación

Nombre Problema Solución Consecuencias

Fábrica

Abstracta

Abstract

Factory

Proveer una interfaz para crear

familias de objetos dependientes

o relacionados entre sí sin

especificar sus clases concretas.

Se utiliza una fábrica abstracta

cuando:

• Un sistema debe ser

independiente de la manera en

que sus productos son creados,

compuestos y representados.

• Un sistema debe ser configurado

con una de múltiples familias de

productos.

• Una familia de objetos

relacionados es diseñada para

usarse en conjunto, y es

necesario forzar esta condición.

• Se desea proveer una librería de

clases de productos, publicando

sólo sus interfaces, no sus

implementaciones.

• Aísla clases concretas.

• Facilita el intercambio

de familias de

productos.

• Promueve la

consistencia entre

productos.

• Dificulta el soporte

para nuevos tipos de

producto.

Constructor

Builder

Separar la construcción de un

objeto complejo de su

representación, tal que el mismo

proceso de construcción pueda

crear diferentes representaciones.

Se utiliza un constructor cuando:

• El algoritmo para crear un objeto

complejo debe ser

independiente de las partes que

componen el objeto y cómo es

ensamblado.

• El proceso de construcción debe

permitir diferentes

representaciones para el objeto

que es construido.

• Permite variar la

representación

interna de un

producto.

• Aísla el código para

construcción y su

representación.

• Permite un mejor

control sobre los

procesos de

construcción.

Fábrica de

Métodos

Factory

Method

Definir una interfaz para la

creación de objetos, permitiendo

a las subclases decidir qué clase

instanciar.

Se utiliza una fábrica de métodos

cuando:

• Una clase no puede anticipar la

clase de objetos que debe crear.

• Una clase requiere que sus

subclases especifiquen objetos a

crear.

• Las clases delegan

responsabilidades a una de

varias subclases auxiliares y se

• Provee flexibilidad

para la creación de

objetos.

113


Fábrica de

Métodos

Factory

Method

(cont.)

requiere localizar la clase

delegada.

• Conecta clases en

jerarquías paralelas.

Prototipo

Prototype

Especificar los tipos de objetos a

crear usando instancias prototipo

y crear nuevos objetos copiando

este prototipo.

Se utiliza un prototipo cuando:

• Un sistema debe ser

independiente de cómo sus

productos son creados,

compuestos y representados, y

• Las clases a instanciar son

especificadas en tiempo de

ejecución, o

• Se requiere evitar una jerarquía

de clases de fábricas paralela a

la jerarquía de clases de

productos, o

• Las instancias de una clase

pueden tener una o pocas

combinaciones de estado.

• Permite agregar y

eliminar productos en

tiempo de ejecución.

• Permite especificar

nuevos productos

variando sus valores y

estructura.

• Reduce las subclases.

• Permite configurar

una aplicación con

clases

dinámicamente.

Singular

Singleton

Asegurar que una clase tiene sólo

una instancia y proveer un punto

de acceso global a ella.

Se utiliza un singular cuando:

• Debe haber sólo una instancia

de una clase y ésta debe ser

accesible a los clientes desde un

punto de acceso conocido.

• Cuando la única instancia debe

ser extensible con subclases, y

los clientes deben ser capaces

de extenderla sin modificar el

código.

• Acceso controlado a la

única instancia.

• Reduce el espacio de

nombres.

• Permite el

refinamiento de

operaciones y

representación.

• Permite un número

variable de instancias.

• Es más flexible que las

operaciones de clases.

Patrones estructurales


Adaptador

Adapter

Convertir la interfaz de una clase

en otra que es esperada por el

cliente.

Se utiliza un adaptador cuando:

• Se requiere utilizar una clase

existente, pero su interfaz no es

compatible.

• Se requiere crear una clase

reutilizable que no sea

necesariamente compatible con

• Permite al adaptador

sobrescribir el

comportamiento de la

clase adaptada.

• No se requieren

objetos adicionales

para llegar a la clase

114


Adaptador

Adapter

(cont.)

Convertir la interfaz de una clase

en otra que es esperada por el

cliente.

otras interfaces.

• Se requiere utilizar un gran

número de subclases existentes,

pero no es práctico adaptar la

interface creando subclases para

cada una.

adaptada.

• No se requieren

objetos adicionales

para llegar a la clase

adaptada.

• Un mismo adaptador

puede adaptar varios

objetos.

Puente

Bridge

Separar la abstracción de su

implementación, permitiendo

que varíen independientemente.

Se utiliza un puente cuando:

• Se requiere evitar la relación

entre la abstracción y la

implementación.

• La abstracción y su

implementación deben ser

extensibles con subclases.

• Los cambios realizados a la

implementación no deben tener

impacto en los clientes.

• Se requiere esconder la

implementación a los clientes.

• Se requiere separar un objeto en

dos partes.

• Se requiere compartir la

implementación a múltiples

objetos.

• Facilita la

extensibilidad.

• Esconde los detalles

de implementación a

los clientes.

Compuesto

Composite

Componer objetos en estructuras

de árbol para representar

jerarquías parciales.

Se utiliza un compuesto cuando:

• Se requiere representar una

jerarquía parcial de objetos.

• Se requiere que los clientes

ignoren la diferencia entre

composiciones de objetos y

objetos individuales.

• Define jerarquías de

objetos primitivos y

compuestos.

• Simplifica al cliente.

• Facilita la adición de

nuevos componentes.

• Generaliza el diseño.

Decorador

Decorator

Añadir responsabilidades a un

objeto dinámicamente.

Se utiliza un decorador cuando:

• Se debe añadir

responsabilidades a un objeto

sin afectar a los demás objetos.

• Se debe retirar

responsabilidades de un objeto.

• Extender con subclases no es

práctico.

• Es más flexible que la

herencia estática.

• Evita clases en

posiciones altas de la

jerarquía.

• Un decorador y un

componente no son

idénticos.

• Crea muchos objetos

pequeños.

Fachada

Façade

Proveer una interfaz unificada a

un conjunto de interfaces en un

Se utiliza una fachada cuando:

• Se desea proveer una interfaz

• Reduce el número de

objetos a los que el

115


Fachada

Façade (cont.) subsistema.

simple a un subsistema

complejo.

• Existen muchas dependencias

entre clientes e

implementaciones de una

abstracción.

• Se requiere jerarquizar los

subsistemas.

cliente tiene acceso.

• Promueve un

acoplamiento bajo

entre el subsistema y

el cliente.

• No evita que las

aplicaciones utilicen

clases del subsistema,

si son requeridas.

Peso ligero

Flyweight

Utilizar la compartición para

soportar un gran número de

objetos modulares

eficientemente.

Se utiliza peso ligero cuando se

presentan todos estos casos al

mismo tiempo:

• Se utiliza un gran número de

objetos.

• Los costos de almacenaje son

altos por la cantidad de objetos.

• La mayoría de los objetos puede

ser extrínseco.

• Muchos grupos de objetos

pueden ser reemplazados por un

grupo pequeño de objetos

compartidos.

• La aplicación no depende de la

identidad de los objetos.

• Aumenta los costos de

transferencia y

búsqueda.

• Reduce los costos de

almacenaje.

Representante

Proxy

Proveer un contenedor para que

otro objeto controle el acceso a

él.

• Un representante remoto

provee un representante local

para un objeto en un espacio de

nombres diferente.

• Un representante virtual crea

objetos costosos en demanda.

• Un representante de protección

controla el acceso al objeto

original.

• Un representante

remoto puede

esconder el hecho de

que un objeto reside

en otro espacio de

nombres.

• Un representante

virtual puede realizar

optimizaciones como

la creación de objetos

en demanda.

• Un representante de

protección permite

tareas adicionales

cuando se accede al

objeto.

116

Patrones de comportamiento


Cadena de

Mando

Chain of

Responsibility

Evitar la dependencia del emisor

de una solicitud a su receptor,

permitiendo a más de un objeto

manejar la solicitud.

Se utiliza una cadena de mando

cuando:

• Más de un objeto puede

manejar la solicitud.

• Se desea enviar un mensaje sin

especificar explícitamente al

receptor.

• Los receptores deben ser

especificados dinámicamente.

• Reduce dependencias.

• Añade flexibilidad para

asignar

responsabilidades a

objetos.

• No garantiza la

recepción de

mensajes.

Instrucción

Command

Encapsular las solicitudes a un

objeto, permitiendo parametrizar

a los clientes con diferentes

solicitudes.

Se utiliza el patrón de instrucción

cuando:

• Se requiere parametrizar

objetos por la acción que

realizan.

• Se requiere especificar, encolar

y ejecutar solicitudes en

tiempos diferentes.

• Se requiere implementar la

instrucción deshacer.

• Se requiere soportar cambios en

caso de un colapso en el

sistema.

• Se requiere estructurar un

sistema con operaciones de alto

nivel basadas en operaciones

primitivas.

• Elimina la

dependencia del

objeto que invoca la

operación de aquel

que la ejecuta.

• Las instrucciones son

objetos de primera

clase.

• Se puede ensamblar

instrucciones en una

instrucción

compuesta.

• No se debe cambiar

clases existentes para

añadir nuevas

instrucciones.

Intérprete

Interpreter

Dado un lenguaje, definir una

representación para su gramática

con un intérprete que usa la

representación para interpretar

sentencias en el lenguaje.

Se utiliza un intérprete cuando:

• La gramática es simple.

• La eficiencia no es crítica.

• Facilita el cambio y la

extensión de la

gramática.

• Facilita la

implementación de la

gramática.

• Las gramáticas

complejas son difíciles

de mantener.

• Permite agregar

nuevas formas de

interpretar

expresiones.

Iterador

Iterator

Proveer un acceso a los

elementos de un objeto agregado

sin publicar su representación.

Se utiliza un iterador cuando:

• Se requiere acceder a un objeto

agregado sin publicar su

• Soporta variaciones en

la transversal de un

agregado.

117


Iterador

Iterator

(cont.)

representación.

• Se requiere soportar múltiples

transversales de objetos

agregados.

• Se requiere proveer una interfaz

uniforme para diferentes

estructuras agregadas.

• Simplifica las

interfaces de los

agregados.

• Más de un transversal

puede estar pendiente

de un agregado.

Mediador

Mediator

Definir un objeto que encapsule la

manera en la que los objetos

interactúan.

Se utiliza un mediador cuando:

• Un conjunto de objetos se

comunican de maneras

complejas pero bien definidas.

• La reutilización de un objeto es

complicada porque se refiere y

comunica con múltiples objetos.

• Un comportamiento distribuido

entra varias clases debe ser

personalizado sin subclases.

• Limita las subclases.

• Independiza colegas.

• Simplifica los

protocolos de objetos.

• Abstrae la cooperación

entre objetos.

• Centraliza el control.

Memoria

Memento

Sin violar la encapsulación,

capturar y externar el estado

interno de un objeto, tal que

pueda ser restaurado después.

Se utiliza memoria cuando:

• El estado de un objeto debe ser

almacenado.

• Una interfaz directa a la

obtención del estado de un

objeto expondría los detalles de

su implementación.

• Preserva la

encapsulación.

• Simplifica al

originador.

• Puede resultar

costoso.

• Define interfaces

amplias.

• Existen costos

escondidos en su uso.

Observador

Observer

Definir una dependencia uno a

muchos entre objetos tal que

cuando un objeto cambia de

estado, todos sus dependientes

son notificados y actualizados

automáticamente.

Se utiliza un observador cuando:

• Una abstracción tiene dos

aspectos, ambas dependientes

de la otra.

• Cuando los cambios de un

objeto afectan a otros, y no se

sabe cuántos serán los

afectados.

• Cuando un objeto debe notificar

a otros sin asumir cuáles son.

• Abstrae la

dependencia entre

observador y sujeto.

• Soporta comunicación

amplia.

• Actualizaciones

inesperadas.

Estado

State

Permitir a un objeto alterar su

comportamiento cuando su

estado interno cambia.

Se utiliza un estado cuando:

• El comportamiento de un objeto

depende de su estado y debe

cambiar en tiempo de

ejecución.

• Las operaciones tienen

sentencias condicionales largas

• Localiza diferentes

operaciones para

diferentes estados del

objeto.

• Hace las transiciones

de estado explícitas.

• El estado de los

118


Estado

State (cont.)

que dependen del estado del

objeto.

objetos puede ser

compartido.

Estrategia

Strategy

Definir una familia de algoritmos,

encapsularlos y hacerlos

intercambiables.

Se utiliza una estrategia cuando:

• Muchas clases relacionadas

difieren sólo en su

comportamiento.

• Se requieren diferentes

variantes para un algoritmo.

• Un algoritmo utiliza datos que

los clientes no deberían

conocer.

• Una clase define muchos

comportamientos que aparecen

como sentencias condicionales

múltiples en sus operaciones.

• Crea familias de

algoritmos

relacionados.

• Representa una

alternativa a las

subclases.

• Elimina sentencias

condicionales.

Plantilla de

Métodos

Template

Method

Definir el esqueleto de un

algoritmo en una operación,

enviando algunos pasos a

subclases.

Se utiliza una plantilla de

métodos para:

• Implementar partes no

variantes de un algoritmo y

dejar que el comportamiento en

las subclases cambie.

• Factorizar y localizar

comportamientos comunes de

subclases en una clase común

para evitar duplicación de

código.

• Controlar extensiones de

subclases.

• Son una técnica

fundamental de la

reutilización.

Visitante

Visitor

Representar una operación a ser

utilizada por elementos de una

estructura de objetos.

Se utiliza visitante cuando:

• Una estructura de objetos

contiene muchas clases con

diferentes interfaces, y se

requiere realizar operaciones en

estos objetos que dependan de

sus clases concretas.

• Varias operaciones distintas

necesitan ser ejecutadas en

objetos de una estructura,

evitando contaminar sus clases

con estas operaciones.

Las clases que definen los objetos

de la estructura raramente

cambian, pero se requiere definir

nuevas operaciones para la

• Facilita la adición de

nuevas operaciones.

• Recolecta operaciones

relacionadas y separa

las no relacionadas.

• Dificulta la agregación

de clases de

elementos concretos.

119


Visitante

Visitor (cont.) estructura.

Anexo B

Diccionario de entrada de datos del micrositio

121

SUSPECTS

Nombre del dato Tipo Tamaño

(Bytes) Descripción

GSFA Customer ID Char 50 Llave primaria asignada por COMET

Lead Originator Char 15

También llamado LEAD Source, indica el número del

empleado que genera el LEAD así como el folio del

mismo, utilizando la siguiente estructura:

#EMPLEADO_FOLIO#FOLIO

Suspect creation Date Date 7 Fecha en que se ingresa el LEAD en formato dd-mm-

aaaa.

Customer Name Char 100 Nombre del cliente.

Suspect accepted/Rejected

at Date 7

Fecha de aprobación o rechazo del LEAD para esta fase

en formato dd-mm-aaaa.

Qualification Potential

Revenue

Numbe

r 22 Potencial de ingreso.

Reason for Qualified out Char 50 Razón por la que el LEAD ha sido rechazado, en su caso.

Lead Source Type Char 30 Tipo de fuente del LEAD (por campaña, base de datos,

etc.).

DEVELOPMENT LEADS



Customer GSFA id Char 50 Llave primaria asignada por COMET.

Customer name Char 100 Nombre del cliente.

Reason for rejection Char 30 Razón por la que el LEAD ha sido rechazado, en su caso.

Customer Sales Territory

Code Char 75 Código del ejecutivo asignado a la cuenta del LEAD.

Lead Source Type Char 30 Tipo de fuente del LEAD (por campaña, base de datos,

etc.).

Creation date Date 7 Fecha en que se ingresa el LEAD en formato dd-mm-

aaaa.

Lead originator Char 15


empleado que genera el LEAD, así como el folio del



122

CUSTOMERS



GSFA CUSTOMER ID Char 50 Llave primaria asignada por COMET.

COMMITED REVENUE Number 22 Ingreso esperado del cliente.

LOST BUSINESS REASON Char 75 Razón por la que se perdieron las negociaciones.

LOST BUSINESS REASON AT Date 7 Fecha en que se perdieron las negociaciones.

REASON FOR QUALIFIED

OUT Char 50 Razón por la que el cliente fue descalificado.

SALES TERRITORY CODE Char 75 Código del ejecutivo asignado a la cuenta del LEAD.

SUSPECT ACCEPTED AT Date 7 Fecha en que el LEAD pasa de SUSPECT a PROSPECT.

SUSPECT ACCEPTED BY Char 15 Código del empleado que acepta el LEAD como

PROSPECT.

YTD REVENUE Number 22 Monto ingresado por el cliente en el año.

LEAD ORIGINATOR Char 20


empleado que genera el LEAD así como el folio del



PROSPECT ACCEPTED AT Date 7 Fecha en que el LEAD pasa de PROSPECT a

OPPORTUNITY.

PROSPECT ACCEPTED BY Char 15 Código del empleado que acepta el LEAD como

OPPORTUNITY.

OPPORTUNITIES




DHL PIPELINE 2 ENTERED Date 7 Fecha en que el LEAD llega al segundo estado del

proceso (First Contact).

DHL PIPELINE 3 ENTERED Date 7 Fecha en que el LEAD llega al tercer estado del proceso

(Proposal).

DHL PIPELINE 4 ENTERED Date 7 Fecha en que el LEAD llega al cuarto estado del proceso

(Agreed Shipping).

DHL PIPELINE 5 ENTERED Date 7 Fecha en que el LEAD llega al quinto estado del proceso

(Implemented).

DHL PIPELINE 6 ENTERED Date 7 Fecha en que el LEAD llega al sexto estado del proceso

(First Consignment).

DHL PIPELINE 7 ENTERED Date 7 Fecha en que el LEAD llega al séptimo estado del

proceso (Shipped to Profile).

DHL PIPELINE 8 ENTERED Date 7 Fecha en que el LEAD llega al octavo estado del proceso

(Unable to Gain)

123



DHL PIPELINE 9 ENTERED Date 7 Fecha en que el LEAD llega al noveno estado del proceso

(Future Opportunity).

EXPECTED CLOSE DATE Date 7 Fecha esperada para el cierre de negociaciones.

OPPORTUNITY CREATED

DATE Char 100

Fecha en que el LEAD pasa de PROSPECT a

OPPORTUNITY.

OPORTUNITY CREATED BY

LOGIN ID Char 15

Código del empleado que acepta el LEAD como

OPPORTUNITY.

POTENTIAL REVENUE Number 22 Potencial del ingreso del cliente.

ACCOUNT NUMBER Char 15 Número de cuenta del cliente utilizado para conectar

con el archivo 24 meses.

ACCOUNTS




ACCOUNT CLOSED DATE Date 7 Fecha de cierre de negociaciones.

ACCOUNT CREATE DATE Date 7 Fecha de creación de la cuenta.

ACCOUNT NUMBER Char 255 Número de cuenta del cliente utilizado para conectar

con el archivo 24 meses.

FIRST SHIPPMENT DATE Date 7 Fecha del primer envío.

LAST SHIPPMENT DATE Date 7 Fecha del último envío.

Contract end date Date 7 Fecha de fin del contrato.

24 Meses



CUENTA TEXT 255 Número de cuenta del cliente.

PRODUCTO TEXT 255 Tipo de producto.

TERRITORIO TEXT 255 Código del ejecutivo asignado a la cuenta (canal

negociador).

ESTRUCTURA TEXT 255 Complemento al ejecutivo (visitador).

MAC TEXT 255 ID del conjunto de cuentas.

NOM_MAC TEXT 255 Nombre del conjunto de cuentas.

CI TEXT 255 Código de industria.

INDUSTRIA TEXT 255 Nombre de la industria del cliente (automotriz, fármaco,

etc.).

EMPRESA TEXT 255 Nombre de la cuenta.

124



REVENUE DOUBL

E 8 Ingreso en el mes actual.

SHIPPMENTS DOUBL

E 8 Número de envíos en el mes actual.

KILOS DOUBL

E 8 Kilos enviados en el mes actual.

FUENTE TEXT 255 Fuente de la cuenta (inactiva o IBS).

Empleados – Extracto de COMET



Organisation Char 100 Organización a la que pertenece el empleado.

User ID Char 50 Identificador del empleado.

Last Name Char 50 Apellido.

First Name Char 50 Nombre.

Middle Name Char 50 Segundo nombre.

Work Phone Char 40 Número telefónico del trabajo.

Email Char 100 Correo electrónico.

Position Char 50 Posición o posiciones del empleado.

Responsability Char 50 Responsabilidad o responsabilidades del empleado.

Territory Char 75 Territorio o territorios del empleado.

Empleados – Recursos Humanos



ID TEXT 255 Identificador del empleado como una cadena de 11

dígitos.

N° de Empleado TEXT 255 Identificador del empleado sin ceros a la izquierda.

Last TEXT 255 Apellido paterno.

Second Last TEXT 255 Apellido materno.

First Name Text 255 Nombre(s).

Per Status TEXT 255 Campo no utilizado.

Status TEXT 255 Campo no utilizado.

Hire Date TEXT 255 Fecha de contratación.

Term Date TEXT 255 Campo no utilizado.

Action TEXT 255 Campo no utilizado.

Reason TEXT 255 Campo no utilizado.

125



Job Code TEXT 255 Campo no utilizado.

Position TEXT 255 Campo no utilizado.

Descr TEXT 255 Puesto.

DeptID TEXT 255 Campo no utilizado.

Descr TEXT 255 Área.

Eff Date TEXT 255 Campo no utilizado.

Reports to TEXT 255 Campo no utilizado.

Location TEXT 255 Campo no utilizado.

CREST TEXT 255 Campo no utilizado.

Sex TEXT 255 Género.

CR TEXT 255 Campo no utilizado.

Nota: En esta última tabla, existen varios campos no utilizados que ha sido necesario mencionar

dado que el layout de entrada para el archivo de Excel los contiene.

Anexo C

Diccionario de datos del sistema

127

Diagrama Entidad-Relación

128

PERSONA



ID Integer 10 Identificador del registro generado secuencialmente.

APELLIDO_PATERNO Varchar 50 Apellido paterno.

APELLIDO_MATERNO Varchar 50 Apellido materno.

NOMBRE Varchar 100 Nombre de pila completo.

EMAIL Varchar 255 Dirección de correo electrónico.

USUARIO



ID Integer 10 Identificador del usuario generado secuencialmente.

ID_PERSONA Integer 10 Identificador de la persona a la que corresponden los

datos del usuario.

NOMBRE Varchar 255 Nombre de usuario.

CONTRASENA Varchar 255 Contraseña de ingreso encriptada.

PREGUNTA_SECRETA Varchar 255 Pregunta secreta como método de seguridad para

recuperar contraseñas perdidas.

RESPUESTA_SECRETA Varchar 255 Respuesta a la pregunta secreta.

TIPO Integer 1

Tipo de usuario registrado:

1. Administrador.

2. Superusuario.

EJECUTIVO



ID Varchar 50 Identificador del usuario generado por COMET.


datos del ejecutivo.

ORGANIZATION Varchar 255 Organización a la que pertenece el ejecutivo.

TELEFONO Varchar 40 Número telefónico de oficina.

PUESTO Varchar 50 Puesto o puestos del ejecutivo.

RESPONSABILIDAD Varchar 50 Responsabilidad o responsabilidades del ejecutivo.

TERRITORIO Varchar 50 Territorio o territorios del ejecutivo.

129

EMPLEADO



ID Varchar 11 Identificador del usuario generado por COMET.


datos del empleado.

PUESTO Varchar 255 Puesto del empleado.

ID_AREA Integer 10 Área a la que pertenece el empleado.

AREA



ID Integer 10 Identificador del área generado secuencialmente.

NOMBRE Varchar 255 Nombre del área.

BITACORA



ID Integer 10 Identificador del registro de bitácora generado

secuencialmente.

ID_USUARIO Integer 10 Identificador del usuario que realiza la acción

registrada.

DESCRIPCION Varchar 255 Descripción del evento sucedido.

BITACORA_INGRESO



ID_BITACORA Integer 10 Identificador del registro de bitácora al que se

refiere.

EXITOSO Integer 1 Indica si el intento de ingreso fue exitoso o no.

INDUSTRIA



ID Varchar 255 Código de la industria.

130



NOMBRE Varchar 255 Nombre de la industria.

ESTADO_PIPELINE



ID Integer 2 Número de secuencia del estado.

NOMBRE Varchar 50 Nombre del estado.

ESTADO



ID Integer 10 Número de secuencia del estado.

NOMBRE Varchar 255 Nombre del estado.

EVENTO



ID Integer 5 Identificador del evento.

NOMBRE Varchar 255 Nombre del evento.

EVENTO_CUENTA



ID_CUENTA Integer 10 Identificador de la cuenta que presentó el evento.

ID_EVENTO Integer 5 Identificador del evento sucedido.

FECHA Date 7 Fecha en la que se presentó el evento.

EVENTO_LEAD



ID_LEAD Varchar 10 Identificador del LEAD que presentó el evento.

ID_EVENTO Integer 5 Identificador del evento sucedido.

131



FECHA Date 7 Fecha en la que se presentó el evento.

CUENTA



ID Integer 10 Identificador de la cuenta generado secuencialmente.

NUMERO Varchar 255 Número de cuenta.

PRODUCTO Varchar 255 Producto que maneja el cliente.

ID_EJECUTIVO Varchar 255 Ejecutivo de cuenta asignado.

STATUS Varchar 255 Estado de la cuenta (abierta, cerrada o inactiva)

ID_INDUSTRIA Varchar 255 Industria a la que pertenece la cuenta.

NOMBRE Varchar 255 Nombre de la cuenta.

INGRESO_OBJETIVO Numeric 22.2 Ingreso objetivo.

INGRESO Numeric 22.2 Ingreso al mes actual.

ENVIOS Integer 10 Envíos en el mes actual.

KILOS Numeric 22.2 Kilos enviados en el mes actual.

PAGADO Integer 1 Indica si el LEAD que generó esta cuenta ha sido

pagado.

ID_LEAD Varchar 50 Identificador del LEAD que generó la cuenta.

POTENCIAL_INGRESO Numeric 22.2 Potencial de ingreso del cliente.

LEAD



ID Varchar 50 Identificador del LEAD, de tipo cadena de caracteres,

equivalente al GSFA Customer ID.

FOLIO Varchar 255 Folio del LEAD format.

ID_EMPLEADO Varchar 11 Empleado que generó el LEAD.

TIPO_FUENTE Integer 10 Tipo de fuente del LEAD.

RAZON_DESCALIFICACION Varchar 50 Razón de que el LEAD haya sido descalificado.

RAZON_PERDIDA_NEGOCIACION Varchar 75 Razón por la cual se perdieron las negociaciones.

FECHA_ESPERADA_CIERRE Date 7 Fecha en que se espera se cierren las negociaciones.

ID_ESTADO_PIPELINE Integer 2 Estado en el que se encuentra el LEAD.

ID_ESTADO Integer 10 Base de datos en la que se encuentra actualmente el

LEAD.

132

CONFIGURACION



ID Integer 10 Identificador del registro de configuración.

NOMBRE Varchar 255 Nombre de la variable de configuración.

VALOR Varchar 255 Valor de la variable de configuración.

NOTICIA



ID Integer 10 Identificador de la noticia o mensaje.

TITULO Varchar 255 Título de la noticia o mensaje.

CONTENIDO Clob * Contenido o cuerpo de la noticia almacenado como

HTML.

Anexo D

Diagramas del diseño del sistema ampliados

134

Diagrama de la máquina de estados

Mapa del sitio

Inicio: DHL LEADs

Administrador

Superusuario

Empleado

Administrador

Catálogos

Áreas

Empleados

Ejecutivos de cuenta

Usuarios

Noticias y Mensajes

Nueva noticia o mensaje

Configuración

Actualizar información

Condiciones de pago

Correos de RH

Correos de contacto

Bitácora

Superusuario

Reportes

LEADs

Reporte gráfico

Áreas generadoras de

LEADs

Cuentas aperturadas

Mi configuración

Editar perfil

Cambiar contraseña

Empleado

Consulta de estado

Contacto

Ingresar

135

Nuevo

Cumplidos

No cumplidos

Anexo E

Solicitud de cambio para la versión 1.1

137

[DHL: Micrositio LEADs] – Solicitud de cambio

Identificador: RX01 Descripción Resumida: Nueva pantalla para el

registro de LEADs.

Descripción Detallada:

Agregar al desarrollo una pantalla para la captura de LEADs, la cual debe contar con las siguientes características:

1. Cualquier empleado de DHL podrá tener acceso. 2. El desarrollo de esta pantalla NO DEBE TENER IMPACTO en la funcionalidad actual de la

herramienta. 3. La información a capturar es la siguiente:

Campo Descripción Tipo Mandatorio Comentarios

Fecha Fecha de registro. Date Por sistema Fecha en la que se registra el LEAD, debe tomarse del sistema.

Folio I Folio del sistema. Char(10) Por sistema Folio consecutivo asignado por el sistema.

Folio LEAD Folio del formato para LEADs.

Char(10) Variable Folio del LEAD format.

Forma de registro

Char(1) Sí Campo para identificar si el registro es directo o a través de un formato de LEAD.

Núm. Empleado

Número de empleado.

Char(15) Sí

Campo para el registro de número de empleado generador del LEAD y llave para la agrupación de LEADs por empleado.

Nombre Empleado

Nombre del empleado.

Char(50) Sí

Nombre del empleado que genera el LEAD. Este campo debería desplegarse al registrar el Núm. Empleado haciendo una validación con la tabla de empleados que ya se encuentra cargada en la aplicación.

Nombre del cliente

Razón social de la empresa.

Char(75) Sí

Dirección Dirección con número de la empresa.

Char(75) Sí Este campo se liga con el Address 1 de COMET.

Colonia Colonia. Char(75) Sí Campo ligado con Address 2 de COMET.

CP Código Postal. Char(5) Sí

Delegación Municipio o delegación.

Char(75) Sí Campo ligado con City en COMET.

138


Estado Estado de la república.

Char(75) Sí Campo ligado con State en COMET, estos valores se deben tomar del LOV.

Lada Lada del número. Char(4) Sí Este campo se debe concatenar con el de teléfono.

Teléfono Número telefónico.

Char(15) Sí Campo concatenado con “Lada” para subir a COMET.

Giro Industry. Char No Campo ligado con Industry en COMET, tomar lista de LOV.

Nombre Contacto

Nombre del contacto.

Char(20) Sí Campo ligado con First Name Contact de COMET.

Apellido Contacto

Apellido del contacto.

Char(20) Sí Campo ligado con Last Name Contact de COMET.

Correo del contacto

Correo electrónico del contacto.

Char(30) Sí Campo que se liga con Email Address en COMET.

Comentarios Comentarios. ¿? No Campo abierto que se liga con Comments en COMET.

Country Ciudad para registro de COMET.

Char(6) Interno Valor “México”, invariable.

Título Profesión del contacto.

Char(20) No Campo ligado con el Saludation en COMET y se debe tomar del LOV.

Tipo Contacto Tipo de contacto. Char(20) No Campo ligado con el Contact Type en COMET y se debe tomar del LOV.

LEAD ORIGINATOR

EMAIL

Correo electrónico del originador del LEAD.

Char(255) No

LEAD ORIGINATOR

Campo de control interno para la identificación del LEAD.

Char(30) Interno Formato: #EMPL + “FOLIO” + #FOLIO

Control Campo de control de proceso

Boolean Interno Campo para controlar qué registros se han procesado para la carga a COMET.

4. La lista de LOV (List Of Values) son tablas de valores en COMET y que no varían. 5. La información registrada en la pantalla deberá quedar en una base de datos que por medio de

una opción para el administrador del sistema pueda generar un archivo de salida para la carga de LEADs a COMET. Los campos procesados deberán cambiar su valor del campo Control para evitar la duplicidad de cargas para COMET.

6. Dependiendo del valor del campo Forma de Registro será el campo Folio I o Folio LEAD que se deberá tomar para el seguimiento dentro de la herramienta. La idea es que el usuario sólo maneje un folio para efectos del seguimiento de sus LEADs.

139


Comentarios de Análisis de Impacto:

El requerimiento se implementará como una nueva librería de clases para ser agregada en el proyecto Micrositio LEADs, de manera que no afecte al código escrito hasta la fecha. La base de datos será extendida por cuatro tablas: LEAD_COMET, LOV_ESTADO, LOV_TITULO y LOV_TIPO_CONTACTO. Sólo la primera utilizará información almacenada en las tablas de la versión 1.0, pero ninguna dependerá de ellas.

Estado: IMPLEMENTADO Esfuerzo Estimado:

Actualización del diseño: 1 hora. Construcción del módulo: 4 horas. Pruebas de usuario e instalación en producción.

Observaciones:

Será necesario reinstalar los archivos de configuración en el servidor para que los cambios surtan efecto.

sistema para control de incentivos a los empleados de dhl express mexico

Documents