Está en la página 1de 151

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


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.

II
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.

III
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.

IV
Í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

V
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

VI
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

VII
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

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

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

IX
Í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

X
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

XI
Í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

XII
Introducción
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).

2
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.

3
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.
4
• 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.

5
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:

6
• 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.

7
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].

8
Capítulo I

Marco Conceptual
“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

10
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.

11
Figura 1-1:: 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.

I.4 El desarrollo como un sistema


Este proceso de negocio puede a su vez, visualizarse como un sistema (Figura
Figura 1-2);
1 una caja
negra que a partir de ciertas entradas genera una salida. En este caso, las entradas involucran,
aunque no están limitadas a:

• Un flujo
jo 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 datoss 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
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
Sistemas
Especificación Contexto del Contexto del
Flujo de trabajo internos y Bases de datos
técnica cliente proveedor
externos

Metodología Arquitectura Buenas prácticas

Solución informática

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

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 una serie de buenas prácticas necesarias para
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 el
desarrollo del software (Figura
Figura 11-3).

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

13
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 11-3: Factores que influyen en el desarrollo de software.

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


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

14
Capítulo II

Marco Teórico
“¿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.

16
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.

17
Como ejemplo, en la Figura 2--1 [NAUR, 1969] se observa la línea de tiempo para un proyecto de
software de gran escala siguiendo un proceso de ingeniería. El proyecto mostrado comienza con
el estudio e implementación del diseño del sistema, que lo divide en componentes, y estos a su
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
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, es decir, conjuntos
estructurados de datos relevantes a una solución específica.

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,
CHURCHER, 2007
2007]

Figura 2--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
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

19
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

20
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 (Figura 2-3 A).
• La vista de casos de uso
uso, que
ue 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
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 (Figura 2-3 C).
• La vista de actividades
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
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 (Figura
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 (Figura
Figura 2-3
2 E).
• La vista de gestión del modelo
modelo,, que describe la organización del modelo como un
conjunto de paquetes (Figura 2-3 F).

Figura 2-3: Las vistas de UML.

21
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
22
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 Patrones de
Patrones de creación
estructurales comportamiento
Fábrica de métodos (Factory
Adaptador (Adapter) Intérprete (Interpreter)
Method)
Clase Plantilla de métodos (Template
Method)
Fábrica abstracta (Abstract Cadena de mando (Chain of
Adaptador (Adapter)
Factory) Responsibility)
Constructor (Builder) Puente (Bridge) Instrucción (Command)
Ámbito Prototipo (Prototype) Compuesto (Composite) Iterador (Iterator)
Singular (Singleton) Decorador (Decorator) Mediador (Mediator)
Objeto 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.

23
Archivo de configuración
A
<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/>
C B ...
<object id="a" type="A">
<property name="B" ref="b">
<object/>
<object id="c" type="C">
<property name="B" ref="b">
D <object/>
<object id="d" type="D">
<property name="B" ref="b">
<object/>

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).
24
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

25
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 Fachada,, con el que se crea una interfaz unificada para
el subsistema, de manera que las clases cliente solamente acceden a esta. ((Figura
Figura 2-7)
2

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 ssoftware,, como la generación de clases gigantes (blob),


(
código muerto (lava flow
flow), y el diseño no orientado a objetos (functional
functional decomposition),
entre otros.
• Antipatrones de arquitectura de software
software,, como la generación de una arquitectura
dependiente de algún
gún producto de software (vendor lock-in)) y el aislamiento entre
sistemas (stovepipe
stovepipe system
system), entre otros.
• Antipatrones de gestión de proyectos de software
software,, como mantener personas
conflictivas dentro del proyecto (corncob),
), la falta de administración en el proyecto
(Project mismanagement
mismanagement), entre otros.

II.7 Resumen

Ingeniería de Software

Análisis y Diseño Orientado a Objetos


Metodología
RAD Buenas prácticas
Patrones de diseño

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

La propuesta de solución a la necesidad del cliente que concierne a éste trabajo será
desarrollada a través de un proceso de ingeniería de software, que será llevado a cabo
mediante una metodología RAD (específicamente RUP, de la manera en que se explica en el

27
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.

28
Capítulo III

Marco Contextual
“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

30
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].

31
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.

32
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.

33
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.

34
• 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.

35
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.

36
Capítulo IV

Flujo de Trabajo LEADs y Requerimientos del Sistema


“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.

38
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.

39
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,
40
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.

41
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.

42
• 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.

Micrositio LEADs

Gestionar contenido

Registrar
administradores funcionales y
superusuarios

Actualizar
Administrador funcional información

Visualizar reportes

Consultar status
de LEADs
Administrador técnico

Superusuario

Contactar al
administrador

Empleado DHL

Figura 4-4: Diagrama de casos de uso.

43
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

Desarrollar un sistema a manera de micrositio para


introducir en la Intranet de DHL. El sistema será instalado
Micrositio para
R01 Alta en el servidor “avión-cl” de DHL, el cual cuenta con arreglos
Intranet
de discos duros que garantizan la capacidad de almacenaje
y la persistencia de la información.
El sistema generará y actualizará de manera automática los
registros de LEADs conforme a la información contenida en
R02 Registro de LEADs Alta
un archivo extracto de COMET, como se describe en el
requerimiento R07.
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.
R03 Reporteo Gerencial Alta
• 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.

44
ID Nombre Prioridad Características

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


LEADs introduciendo una de las siguientes:
Consulta de Status • El folio del LEAD.
R04 Media
de LEADs • Su número de nómina.
Los administradores y superusuarios podrán a su vez
imprimir una consulta del status de LEADs por estaciones.
El administrador funcional podrá conceder y restringir
R05 Control de Usuarios Media
acceso a directores/gerentes y otros administradores.
El administrador podrá manipular la cantidad de envíos y el
Control de monto mínimo al mes para que sea pagado un LEAD, así
R06 condiciones de Media como su vigencia, es decir, el tiempo en el que los
pago parámetros anteriores deben cumplirse antes de que el
LEAD se dé de baja.
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.
Actualización de • Fecha de ingreso del LEAD.
R07 Alta
Información • 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.
El sistema debe generar un reporte de los LEADs que deben
Pago a Recursos
R08 Alta ser pagados y enviarlo a manera de correo electrónico. El
Humanos
administrador funcional del sistema deberá ser capáz de

45
ID Nombre Prioridad Características

Pago a Recursos gestionar los destinatarios de dicho correo, así como los
R08 Alta
Humanos (cont.) campos del layout de salida del reporte.
El sistema deberá contar con un módulo administrable de
Noticias y Mensajes
R09 Media/Alta noticias y/o mensajes importantes, el cual deberá soportar
Importantes
imágenes.
Los empleados de DHL podrán contactar al administrador a
través del micrositio con dudas o sugerencias. El
R10 Contacto Media/Alta
administrador recibirá los mensajes en su correo
electrónico.
El sitio debe incluir un contador de visitas que reporte el
R11 Contador de Visitas Baja número de visitas por mes y qué usuarios registrados lo
han visitado.
Envío del Status de
Los empleados que hayan registrado LEADs recibirán un
R12 LEAD por Correo Baja
correo informativo cada vez que cambie su status.
Electrónico

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.

ID Nombre Prioridad Características

U01 Fácil Aprendizaje Media/Alta La curva de aprendizaje del sistema debe ser muy pequeña.

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

ID Nombre Prioridad Características

El sistema debe ser capaz de recuperarse de errores


Media/Alt
C01 Tolerancia a Fallas presentados de manera automática y/o mostrar el
a
procedimiento a seguir para corregirlos.
C02 Disponibilidad Alta El sistema debe estar disponible 24/7.

Tabla 4-4: Requerimientos de seguridad del sistema.

ID Nombre Prioridad Características

Tendrán acceso al sistema solamente administradores


funcionales y superusuarios registrados. Los reportes de
S01 Ingreso de Usuarios Alta 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.

ID Nombre Prioridad Características

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
D01 Host del Sistema Alta • 2 GB de RAM.
• Microsoft Windows Server 2003 Enterprise Edition
Service Pack 1.
• Microsoft SQL Server 2000.
•.NET Framework 2.0

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

ID Nombre Prioridad Características

Al finalizar el desarrollo se deberá entregar la


Manual de
DOC01 Media/Alta documentación necesaria para permitir el mantenimiento
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.

48
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.

49
Capítulo V

Análisis y Diseño de la Solución


“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

51
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 del sistema.

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
ció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.

Capa de presentación

Capa de negocio

Capa de datos

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

• Capa de presentación
presentación:: En esta capa superior, se presenta el sistema al usuario, le
comunica y captura la información realizando un procesamiento mínimo,
mínimo que
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
o y enviando las respuestas tras el proceso. Se denomina capa de
negocio o lógica del negocio
negocio,, pues aquí es donde se establecen todas las reglas que
deben cumplirse. La capa de negocio se comunica con la capa de presentación para
recibir solicitudes y entr
entregar
egar resultados, y con la capa de datos, para solicitar que se
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.

52
Estas tres capas residirán en una única plataforma de hardware. Los distintos componentes de
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 ssiguientes beneficios:

• 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
descubiertas
scubiertas por otros componentes.
• Reciclaje,, 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.

V.2.1
.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-3.
5

Figura 55-3: Arquitectura contextualizada del sistema.

53
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).

54
• 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).

Sistema LEADs

SUSPECTS
DEVELOPMENT LEADS
24 Meses CUSTOMERS
OPPORTUNITIES
ACCOUNTS
Empleados

IBS COMET

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.

55
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).

56
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).

57
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).

58
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.

59
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.

60
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.

61
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.

62
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.

63
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.

64
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.

65
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.

66
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.

67
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.

68
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.

69
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.

70
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.

71
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.

72
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.

73
• 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 Salir para cerrar su sesión.

Catálogos

Noticias y
Mensajes
Administrador
Configuración

Bitácora

Inicio: DHL Reportes


LEADs Superusuario
Mi
configuración

Consulta de
estado

Empleado Contacto

Ingresar

Figura 5-22: Mapa del sitio.

V.5.1.1 Inicio: DHL LEADs


La pantalla de inicio mostrará información acerca del programa de incentivos, generada en la
sección de Noticias
icias y Mensajes
Mensajes.. Si el usuario que la visita es un usuario registrado, se
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.

74
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
Meramente informativo en el diagrama, se muestra para definir los puntos del mapa que serán
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.

75
V.5.1.10 Empleado
Meramente informativo en el diagrama, se muestra para definir los puntos del mapa que serán
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.

76
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.

Actividad realizada Horas efectivas de trabajo

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.

77
Capítulo VI

Construcción e implantación del micrositio LEADs


“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).

79
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

80
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,
81
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.

82
• 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.

83
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.

84
En esta sección se describe la organización de ambos proyectos.

VI.3.1
.1 El proyecto CentralMedia.Dhl.Leads
El proyecto se encuentra dividido en 4 carpetas como muestra la Figura 6-3:
6 Datos, Modelo,
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 datos, y SessionFactory.cs, una
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.
nombradas Interfaz e Implementación.. La carpeta Interfaz
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
n el nombre de cada clase la tecnología utilizada: JakartaExcelDao,
NHibernateEntidadDao, etc.

CentralMedia.Dhl.Leads

Datos Modelo Negocio Vista

Implementación Entidad Implementación Web

Interfaz Interfaz

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

La carpeta Modelo contiene las clases que conforman el m


modelo
odelo estático del sistema tal como
se muestra en la Figura 5-17,, en el capítulo V.

85
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:
86
Administrador, Superusuario y Empleado. Todas las páginas ASPX han sido desarrolladas como
clases parciales, utilizando la característica Code Behind de la plataforma .NET 2.0 para separar
la funcionalidad inherente de la página de su representación en el navegador.

ASPTreeView Administrador

aspx Superusuario

Bin Empleado

config Mapeos

estilo

Web logs

media

menu

scripts

usuarios

WebCharts

Figura 66-4: Estructura de despliegue del proyecto Web.

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),
ng.NET (Negocio.xml y Vista.xml) y Log4Net (Log4Net.xml). La subcarpeta Mapeos incluye
Spring.NET
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


porr los archivos ASPX.

87
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.

88
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

89
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.

90
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.

91
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.

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

Actividad realizada Horas efectivas de trabajo

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.

Actividad realizada Horas efectivas de trabajo

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.

93
Capítulo VII

Resultados
“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
95
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.

96
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
97
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.

98
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.

99
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

100
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

101
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

102
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.

103
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.

104
Conclusiones
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.

106
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:

107
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

108
[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.

109
Anexos
Anexo A

Catálogo de patrones de diseño orientado a objetos


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
Se utiliza una fábrica abstracta
cuando:
• Un sistema debe ser
independiente de la manera en
• Aísla clases concretas.
que sus productos son creados,
• Facilita el intercambio
compuestos y representados.
de familias de
• Un sistema debe ser configurado
Fábrica Proveer una interfaz para crear productos.
con una de múltiples familias de
Abstracta familias de objetos dependientes • Promueve la
productos.
Abstract o relacionados entre sí sin consistencia entre
• Una familia de objetos
Factory especificar sus clases concretas. productos.
relacionados es diseñada para
• Dificulta el soporte
usarse en conjunto, y es
para nuevos tipos de
necesario forzar esta condición.
producto.
• Se desea proveer una librería de
clases de productos, publicando
sólo sus interfaces, no sus
implementaciones.
• Permite variar la
Se utiliza un constructor cuando:
representación
• El algoritmo para crear un objeto
interna de un
complejo debe ser
Separar la construcción de un producto.
independiente de las partes que
objeto complejo de su • Aísla el código para
Constructor componen el objeto y cómo es
representación, tal que el mismo construcción y su
Builder ensamblado.
proceso de construcción pueda representación.
• El proceso de construcción debe
crear diferentes representaciones. • Permite un mejor
permitir diferentes
control sobre los
representaciones para el objeto
procesos de
que es construido.
construcción.
Se utiliza una fábrica de métodos
cuando:
• Una clase no puede anticipar la
Fábrica de Definir una interfaz para la clase de objetos que debe crear.
• Provee flexibilidad
Métodos creación de objetos, permitiendo • Una clase requiere que sus
para la creación de
Factory a las subclases decidir qué clase subclases especifiquen objetos a
objetos.
Method instanciar. crear.
• Las clases delegan
responsabilidades a una de
varias subclases auxiliares y se

112
Nombre Problema Solución Consecuencias
Fábrica de
Métodos
requiere localizar la clase • Conecta clases en
Factory
delegada. jerarquías paralelas.
Method
(cont.)
Se utiliza un prototipo cuando:
• Un sistema debe ser
• Permite agregar y
independiente de cómo sus
eliminar productos en
productos son creados,
tiempo de ejecución.
compuestos y representados, y
• Permite especificar
• Las clases a instanciar son
Especificar los tipos de objetos a nuevos productos
especificadas en tiempo de
Prototipo crear usando instancias prototipo variando sus valores y
ejecución, o
Prototype y crear nuevos objetos copiando estructura.
• Se requiere evitar una jerarquía
este prototipo. • Reduce las subclases.
de clases de fábricas paralela a
• Permite configurar
la jerarquía de clases de
una aplicación con
productos, o
clases
• Las instancias de una clase
dinámicamente.
pueden tener una o pocas
combinaciones de estado.
• Acceso controlado a la
Se utiliza un singular cuando: única instancia.
• Debe haber sólo una instancia • Reduce el espacio de
de una clase y ésta debe ser nombres.
accesible a los clientes desde un • Permite el
Asegurar que una clase tiene sólo
Singular punto de acceso conocido. refinamiento de
una instancia y proveer un punto
Singleton • Cuando la única instancia debe operaciones y
de acceso global a ella.
ser extensible con subclases, y representación.
los clientes deben ser capaces • Permite un número
de extenderla sin modificar el variable de instancias.
código. • Es más flexible que las
operaciones de clases.

Patrones estructurales
Nombre Problema Solución Consecuencias
Se utiliza un adaptador cuando: • Permite al adaptador
• Se requiere utilizar una clase sobrescribir el
Convertir la interfaz de una clase existente, pero su interfaz no es comportamiento de la
Adaptador
en otra que es esperada por el compatible. clase adaptada.
Adapter
cliente. • Se requiere crear una clase • No se requieren
reutilizable que no sea objetos adicionales
necesariamente compatible con para llegar a la clase

113
Nombre Problema Solución Consecuencias
adaptada.
otras interfaces. • No se requieren
• Se requiere utilizar un gran objetos adicionales
Adaptador Convertir la interfaz de una clase
número de subclases existentes, para llegar a la clase
Adapter en otra que es esperada por el
pero no es práctico adaptar la adaptada.
(cont.) cliente.
interface creando subclases para • Un mismo adaptador
cada una. puede adaptar varios
objetos.
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. • Facilita la
Separar la abstracción de su • Los cambios realizados a la extensibilidad.
Puente
implementación, permitiendo implementación no deben tener • Esconde los detalles
Bridge
que varíen independientemente. impacto en los clientes. de implementación a
• Se requiere esconder la los clientes.
implementación a los clientes.
• Se requiere separar un objeto en
dos partes.
• Se requiere compartir la
implementación a múltiples
objetos.
Se utiliza un compuesto cuando: • Define jerarquías de
• Se requiere representar una objetos primitivos y
Componer objetos en estructuras jerarquía parcial de objetos. compuestos.
Compuesto
de árbol para representar • Se requiere que los clientes • Simplifica al cliente.
Composite
jerarquías parciales. ignoren la diferencia entre • Facilita la adición de
composiciones de objetos y nuevos componentes.
objetos individuales. • Generaliza el diseño.
• Es más flexible que la
Se utiliza un decorador cuando: herencia estática.
• Se debe añadir • Evita clases en
responsabilidades a un objeto posiciones altas de la
Decorador Añadir responsabilidades a un sin afectar a los demás objetos. jerarquía.
Decorator objeto dinámicamente. • Se debe retirar • Un decorador y un
responsabilidades de un objeto. componente no son
• Extender con subclases no es idénticos.
práctico. • Crea muchos objetos
pequeños.
Fachada Proveer una interfaz unificada a Se utiliza una fachada cuando: • Reduce el número de
Façade un conjunto de interfaces en un • Se desea proveer una interfaz objetos a los que el

114
Nombre Problema Solución Consecuencias
cliente tiene acceso.
simple a un subsistema
• Promueve un
complejo.
acoplamiento bajo
• Existen muchas dependencias
entre el subsistema y
Fachada entre clientes e
subsistema. el cliente.
Façade (cont.) implementaciones de una
• No evita que las
abstracción.
aplicaciones utilicen
• Se requiere jerarquizar los
clases del subsistema,
subsistemas.
si son requeridas.
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 • Aumenta los costos de
Utilizar la compartición para
altos por la cantidad de objetos. transferencia y
Peso ligero soportar un gran número de
• La mayoría de los objetos puede búsqueda.
Flyweight objetos modulares
ser extrínseco. • Reduce los costos de
eficientemente.
• Muchos grupos de objetos almacenaje.
pueden ser reemplazados por un
grupo pequeño de objetos
compartidos.
• La aplicación no depende de la
identidad de los objetos.
• Un representante
remoto puede
esconder el hecho de
que un objeto reside
• Un representante remoto
en otro espacio de
provee un representante local
nombres.
para un objeto en un espacio de
• Un representante
Proveer un contenedor para que nombres diferente.
Representante virtual puede realizar
otro objeto controle el acceso a • Un representante virtual crea
Proxy optimizaciones como
él. objetos costosos en demanda.
la creación de objetos
• Un representante de protección
en demanda.
controla el acceso al objeto
• Un representante de
original.
protección permite
tareas adicionales
cuando se accede al
objeto.

115
Patrones de comportamiento
Nombre Problema Solución Consecuencias
Se utiliza una cadena de mando
• Reduce dependencias.
cuando:
• Añade flexibilidad para
• Más de un objeto puede
Cadena de Evitar la dependencia del emisor asignar
manejar la solicitud.
Mando de una solicitud a su receptor, responsabilidades a
• Se desea enviar un mensaje sin
Chain of permitiendo a más de un objeto objetos.
especificar explícitamente al
Responsibility manejar la solicitud. • No garantiza la
receptor.
recepción de
• Los receptores deben ser
mensajes.
especificados dinámicamente.
Se utiliza el patrón de instrucción
• Elimina la
cuando:
dependencia del
• Se requiere parametrizar
objeto que invoca la
objetos por la acción que
operación de aquel
realizan.
que la ejecuta.
• Se requiere especificar, encolar
• Las instrucciones son
y ejecutar solicitudes en
Encapsular las solicitudes a un objetos de primera
tiempos diferentes.
Instrucción objeto, permitiendo parametrizar clase.
• Se requiere implementar la
Command a los clientes con diferentes • Se puede ensamblar
instrucción deshacer.
solicitudes. instrucciones en una
• Se requiere soportar cambios en
instrucción
caso de un colapso en el
compuesta.
sistema.
• No se debe cambiar
• Se requiere estructurar un
clases existentes para
sistema con operaciones de alto
añadir nuevas
nivel basadas en operaciones
instrucciones.
primitivas.
• Facilita el cambio y la
extensión de la
gramática.
• Facilita la
Dado un lenguaje, definir una implementación de la
representación para su gramática Se utiliza un intérprete cuando: gramática.
Intérprete
con un intérprete que usa la • La gramática es simple. • Las gramáticas
Interpreter
representación para interpretar • La eficiencia no es crítica. complejas son difíciles
sentencias en el lenguaje. de mantener.
• Permite agregar
nuevas formas de
interpretar
expresiones.
Proveer un acceso a los Se utiliza un iterador cuando: • Soporta variaciones en
Iterador
elementos de un objeto agregado • Se requiere acceder a un objeto la transversal de un
Iterator
sin publicar su representación. agregado sin publicar su agregado.

116
Nombre Problema Solución Consecuencias
representación.
• Simplifica las
• Se requiere soportar múltiples
interfaces de los
Iterador transversales de objetos
agregados.
Iterator agregados.
• Más de un transversal
(cont.) • Se requiere proveer una interfaz
puede estar pendiente
uniforme para diferentes
de un agregado.
estructuras agregadas.
Se utiliza un mediador cuando:
• Un conjunto de objetos se
• Limita las subclases.
comunican de maneras
• Independiza colegas.
complejas pero bien definidas.
Definir un objeto que encapsule la • Simplifica los
Mediador • La reutilización de un objeto es
manera en la que los objetos protocolos de objetos.
Mediator complicada porque se refiere y
interactúan. • Abstrae la cooperación
comunica con múltiples objetos.
entre objetos.
• Un comportamiento distribuido
• Centraliza el control.
entra varias clases debe ser
personalizado sin subclases.
• Preserva la
encapsulación.
Se utiliza memoria cuando:
• Simplifica al
• El estado de un objeto debe ser
Sin violar la encapsulación, originador.
almacenado.
Memoria capturar y externar el estado • Puede resultar
• Una interfaz directa a la
Memento interno de un objeto, tal que costoso.
obtención del estado de un
pueda ser restaurado después. • Define interfaces
objeto expondría los detalles de
amplias.
su implementación.
• Existen costos
escondidos en su uso.
Se utiliza un observador cuando:
• Una abstracción tiene dos
• Abstrae la
Definir una dependencia uno a aspectos, ambas dependientes
dependencia entre
muchos entre objetos tal que de la otra.
observador y sujeto.
Observador cuando un objeto cambia de • Cuando los cambios de un
• Soporta comunicación
Observer estado, todos sus dependientes objeto afectan a otros, y no se
amplia.
son notificados y actualizados sabe cuántos serán los
• Actualizaciones
automáticamente. afectados.
inesperadas.
• Cuando un objeto debe notificar
a otros sin asumir cuáles son.
Se utiliza un estado cuando: • Localiza diferentes
• El comportamiento de un objeto operaciones para
Permitir a un objeto alterar su depende de su estado y debe diferentes estados del
Estado
comportamiento cuando su cambiar en tiempo de objeto.
State
estado interno cambia. ejecución. • Hace las transiciones
• Las operaciones tienen de estado explícitas.
sentencias condicionales largas • El estado de los

117
Nombre Problema Solución Consecuencias
Estado que dependen del estado del objetos puede ser
State (cont.) objeto. compartido.
Se utiliza una estrategia cuando:
• Muchas clases relacionadas
difieren sólo en su
• Crea familias de
comportamiento.
algoritmos
• Se requieren diferentes
relacionados.
Definir una familia de algoritmos, variantes para un algoritmo.
Estrategia • Representa una
encapsularlos y hacerlos • Un algoritmo utiliza datos que
Strategy alternativa a las
intercambiables. los clientes no deberían
subclases.
conocer.
• Elimina sentencias
• Una clase define muchos
condicionales.
comportamientos que aparecen
como sentencias condicionales
múltiples en sus operaciones.
Se utiliza una plantilla de
métodos para:
• Implementar partes no
variantes de un algoritmo y
dejar que el comportamiento en
Plantilla de Definir el esqueleto de un
las subclases cambie. • Son una técnica
Métodos algoritmo en una operación,
• Factorizar y localizar fundamental de la
Template enviando algunos pasos a
comportamientos comunes de reutilización.
Method subclases.
subclases en una clase común
para evitar duplicación de
código.
• Controlar extensiones de
subclases.
Se utiliza visitante cuando:
• Una estructura de objetos
contiene muchas clases con
diferentes interfaces, y se
requiere realizar operaciones en • Facilita la adición de
estos objetos que dependan de nuevas operaciones.
sus clases concretas. • Recolecta operaciones
Representar una operación a ser
Visitante • Varias operaciones distintas relacionadas y separa
utilizada por elementos de una
Visitor necesitan ser ejecutadas en las no relacionadas.
estructura de objetos.
objetos de una estructura, • Dificulta la agregación
evitando contaminar sus clases de clases de
con estas operaciones. elementos concretos.
Las clases que definen los objetos
de la estructura raramente
cambian, pero se requiere definir
nuevas operaciones para la

118
Nombre Problema Solución Consecuencias
Visitante
estructura.
Visitor (cont.)

119
Anexo B

Diccionario de entrada de datos del micrositio


SUSPECTS
Tamaño
Nombre del dato Tipo Descripción
(Bytes)
GSFA Customer ID Char 50 Llave primaria asignada por COMET
También llamado LEAD Source, indica el número del
empleado que genera el LEAD así como el folio del
Lead Originator Char 15
mismo, utilizando la siguiente estructura:
#EMPLEADO_FOLIO#FOLIO
Fecha en que se ingresa el LEAD en formato dd-mm-
Suspect creation Date Date 7
aaaa.
Customer Name Char 100 Nombre del cliente.
Suspect accepted/Rejected Fecha de aprobación o rechazo del LEAD para esta fase
Date 7
at en formato dd-mm-aaaa.
Qualification Potential Numbe
22 Potencial de ingreso.
Revenue r
Reason for Qualified out Char 50 Razón por la que el LEAD ha sido rechazado, en su caso.
Tipo de fuente del LEAD (por campaña, base de datos,
Lead Source Type Char 30
etc.).

DEVELOPMENT LEADS
Tamaño
Nombre del dato Tipo Descripción
(Bytes)
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
Char 75 Código del ejecutivo asignado a la cuenta del LEAD.
Code
Tipo de fuente del LEAD (por campaña, base de datos,
Lead Source Type Char 30
etc.).
Fecha en que se ingresa el LEAD en formato dd-mm-
Creation date Date 7
aaaa.
También llamado LEAD Source, indica el número del
empleado que genera el LEAD, así como el folio del
Lead originator Char 15
mismo, utilizando la siguiente estructura:
#EMPLEADO_FOLIO#FOLIO

121
CUSTOMERS
Tamaño
Nombre del dato Tipo Descripción
(Bytes)
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
Char 50 Razón por la que el cliente fue descalificado.
OUT
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.
Código del empleado que acepta el LEAD como
SUSPECT ACCEPTED BY Char 15
PROSPECT.
YTD REVENUE Number 22 Monto ingresado por el cliente en el año.
También llamado LEAD Source, indica el número del
empleado que genera el LEAD así como el folio del
LEAD ORIGINATOR Char 20
mismo, utilizando la siguiente estructura:
#EMPLEADO_FOLIO#FOLIO
Fecha en que el LEAD pasa de PROSPECT a
PROSPECT ACCEPTED AT Date 7
OPPORTUNITY.
Código del empleado que acepta el LEAD como
PROSPECT ACCEPTED BY Char 15
OPPORTUNITY.

OPPORTUNITIES
Tamaño
Nombre del dato Tipo Descripción
(Bytes)
GSFA CUSTOMER ID Char 50 Llave primaria asignada por COMET.
Fecha en que el LEAD llega al segundo estado del
DHL PIPELINE 2 ENTERED Date 7
proceso (First Contact).
Fecha en que el LEAD llega al tercer estado del proceso
DHL PIPELINE 3 ENTERED Date 7
(Proposal).
Fecha en que el LEAD llega al cuarto estado del proceso
DHL PIPELINE 4 ENTERED Date 7
(Agreed Shipping).
Fecha en que el LEAD llega al quinto estado del proceso
DHL PIPELINE 5 ENTERED Date 7
(Implemented).
Fecha en que el LEAD llega al sexto estado del proceso
DHL PIPELINE 6 ENTERED Date 7
(First Consignment).
Fecha en que el LEAD llega al séptimo estado del
DHL PIPELINE 7 ENTERED Date 7
proceso (Shipped to Profile).
Fecha en que el LEAD llega al octavo estado del proceso
DHL PIPELINE 8 ENTERED Date 7
(Unable to Gain)

122
Tamaño
Nombre del dato Tipo Descripción
(Bytes)
Fecha en que el LEAD llega al noveno estado del proceso
DHL PIPELINE 9 ENTERED Date 7
(Future Opportunity).
EXPECTED CLOSE DATE Date 7 Fecha esperada para el cierre de negociaciones.
OPPORTUNITY CREATED Fecha en que el LEAD pasa de PROSPECT a
Char 100
DATE OPPORTUNITY.
OPORTUNITY CREATED BY Código del empleado que acepta el LEAD como
Char 15
LOGIN ID OPPORTUNITY.
POTENTIAL REVENUE Number 22 Potencial del ingreso del cliente.
Número de cuenta del cliente utilizado para conectar
ACCOUNT NUMBER Char 15
con el archivo 24 meses.

ACCOUNTS
Tamaño
Nombre del dato Tipo Descripción
(Bytes)
GSFA CUSTOMER ID Char 50 Llave primaria asignada por COMET.
ACCOUNT CLOSED DATE Date 7 Fecha de cierre de negociaciones.
ACCOUNT CREATE DATE Date 7 Fecha de creación de la cuenta.
Número de cuenta del cliente utilizado para conectar
ACCOUNT NUMBER Char 255
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
Tamaño
Nombre del dato Tipo Descripción
(Bytes)
CUENTA TEXT 255 Número de cuenta del cliente.
PRODUCTO TEXT 255 Tipo de producto.
Código del ejecutivo asignado a la cuenta (canal
TERRITORIO TEXT 255
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.
Nombre de la industria del cliente (automotriz, fármaco,
INDUSTRIA TEXT 255
etc.).
EMPRESA TEXT 255 Nombre de la cuenta.

123
Tamaño
Nombre del dato Tipo Descripción
(Bytes)
DOUBL
REVENUE 8 Ingreso en el mes actual.
E
DOUBL
SHIPPMENTS 8 Número de envíos en el mes actual.
E
DOUBL
KILOS 8 Kilos enviados en el mes actual.
E
FUENTE TEXT 255 Fuente de la cuenta (inactiva o IBS).

Empleados – Extracto de COMET


Tamaño
Nombre del dato Tipo Descripción
(Bytes)
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


Tamaño
Nombre del dato Tipo Descripción
(Bytes)
Identificador del empleado como una cadena de 11
ID TEXT 255
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.

124
Tamaño
Nombre del dato Tipo Descripción
(Bytes)
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.

125
Anexo C

Diccionario de datos del sistema


Diagrama Entidad-Relación

127
PERSONA
Tamaño
Nombre del dato Tipo Descripción
(Bytes)
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
Tamaño
Nombre del dato Tipo Descripción
(Bytes)
ID Integer 10 Identificador del usuario generado secuencialmente.
Identificador de la persona a la que corresponden los
ID_PERSONA Integer 10
datos del usuario.
NOMBRE Varchar 255 Nombre de usuario.
CONTRASENA Varchar 255 Contraseña de ingreso encriptada.
Pregunta secreta como método de seguridad para
PREGUNTA_SECRETA Varchar 255
recuperar contraseñas perdidas.
RESPUESTA_SECRETA Varchar 255 Respuesta a la pregunta secreta.
Tipo de usuario registrado:
TIPO Integer 1 1. Administrador.
2. Superusuario.

EJECUTIVO
Tamaño
Nombre del dato Tipo Descripción
(Bytes)
ID Varchar 50 Identificador del usuario generado por COMET.
Identificador de la persona a la que corresponden los
ID_PERSONA Integer 10
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.

128
EMPLEADO
Tamaño
Nombre del dato Tipo Descripción
(Bytes)
ID Varchar 11 Identificador del usuario generado por COMET.
Identificador de la persona a la que corresponden los
ID_PERSONA Integer 10
datos del empleado.
PUESTO Varchar 255 Puesto del empleado.
ID_AREA Integer 10 Área a la que pertenece el empleado.

AREA
Tamaño
Nombre del dato Tipo Descripción
(Bytes)
ID Integer 10 Identificador del área generado secuencialmente.
NOMBRE Varchar 255 Nombre del área.

BITACORA
Tamaño
Nombre del dato Tipo Descripción
(Bytes)
Identificador del registro de bitácora generado
ID Integer 10
secuencialmente.
Identificador del usuario que realiza la acción
ID_USUARIO Integer 10
registrada.
DESCRIPCION Varchar 255 Descripción del evento sucedido.

BITACORA_INGRESO
Tamaño
Nombre del dato Tipo Descripción
(Bytes)
Identificador del registro de bitácora al que se
ID_BITACORA Integer 10
refiere.
EXITOSO Integer 1 Indica si el intento de ingreso fue exitoso o no.

INDUSTRIA
Tamaño
Nombre del dato Tipo Descripción
(Bytes)
ID Varchar 255 Código de la industria.

129
Tamaño
Nombre del dato Tipo Descripción
(Bytes)
NOMBRE Varchar 255 Nombre de la industria.

ESTADO_PIPELINE
Tamaño
Nombre del dato Tipo Descripción
(Bytes)
ID Integer 2 Número de secuencia del estado.
NOMBRE Varchar 50 Nombre del estado.

ESTADO
Tamaño
Nombre del dato Tipo Descripción
(Bytes)
ID Integer 10 Número de secuencia del estado.
NOMBRE Varchar 255 Nombre del estado.

EVENTO
Tamaño
Nombre del dato Tipo Descripción
(Bytes)
ID Integer 5 Identificador del evento.
NOMBRE Varchar 255 Nombre del evento.

EVENTO_CUENTA
Tamaño
Nombre del dato Tipo Descripción
(Bytes)
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
Tamaño
Nombre del dato Tipo Descripción
(Bytes)
ID_LEAD Varchar 10 Identificador del LEAD que presentó el evento.
ID_EVENTO Integer 5 Identificador del evento sucedido.

130
Tamaño
Nombre del dato Tipo Descripción
(Bytes)
FECHA Date 7 Fecha en la que se presentó el evento.

CUENTA
Tamaño
Nombre del dato Tipo Descripción
(Bytes)
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.
Indica si el LEAD que generó esta cuenta ha sido
PAGADO Integer 1
pagado.
ID_LEAD Varchar 50 Identificador del LEAD que generó la cuenta.
POTENCIAL_INGRESO Numeric 22.2 Potencial de ingreso del cliente.

LEAD
Tamaño
Nombre del dato Tipo Descripción
(Bytes)
Identificador del LEAD, de tipo cadena de caracteres,
ID Varchar 50
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.
Base de datos en la que se encuentra actualmente el
ID_ESTADO Integer 10
LEAD.

131
CONFIGURACION
Tamaño
Nombre del dato Tipo Descripción
(Bytes)
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
Tamaño
Nombre del dato Tipo Descripción
(Bytes)
ID Integer 10 Identificador de la noticia o mensaje.
TITULO Varchar 255 Título de la noticia o mensaje.
Contenido o cuerpo de la noticia almacenado como
CONTENIDO Clob *
HTML.

132
Anexo D

Diagramas del diseño del sistema ampliados


Diagrama de la máquina de estados

134
Mapa del sitio

Áreas

Empleados

Catálogos
Ejecutivos de
cuenta

Usuarios Nuevo

Noticias y Nueva noticia o


Mensajes mensaje
Administrador
Actualizar
información

Condiciones de
pago
Configuración

Correos de RH

Bitácora
Correos de
contacto

Cumplidos

LEADs

No cumplidos
Inicio: DHL LEADs
Reporte gráfico

Reportes
Áreas
generadoras de
LEADs

Cuentas
Superusuario
aperturadas

Editar perfil

Mi configuración
Cambiar
contraseña
Consulta de
estado

Empleado Contacto

Ingresar

135
Anexo E

Solicitud de cambio para la versión 1.1


[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 en la que se registra el LEAD,
Fecha Fecha de registro. Date Por sistema
debe tomarse del sistema.
Folio consecutivo asignado por el
Folio I Folio del sistema. Char(10) Por sistema
sistema.
Folio del formato
Folio LEAD Char(10) Variable Folio del LEAD format.
para LEADs.
Campo para identificar si el registro
Forma de
Char(1) Sí es directo o a través de un formato
registro
de LEAD.
Campo para el registro de número
Núm. Número de de empleado generador del LEAD y
Char(15) Sí
Empleado empleado. llave para la agrupación de LEADs
por empleado.
Nombre del empleado que genera
el LEAD. Este campo debería
Nombre Nombre del desplegarse al registrar el Núm.
Char(50) Sí
Empleado empleado. Empleado haciendo una validación
con la tabla de empleados que ya se
encuentra cargada en la aplicación.
Nombre del Razón social de la
Char(75) Sí
cliente empresa.
Dirección con
Este campo se liga con el Address 1
Dirección número de la Char(75) Sí
de COMET.
empresa.
Campo ligado con Address 2 de
Colonia Colonia. Char(75) Sí
COMET.
CP Código Postal. Char(5) Sí
Municipio o
Delegación Char(75) Sí Campo ligado con City en COMET.
delegación.

137
[DHL: Micrositio LEADs] – Solicitud de cambio
Campo ligado con State en COMET,
Estado de la
Estado Char(75) Sí estos valores se deben tomar del
república.
LOV.
Este campo se debe concatenar con
Lada Lada del número. Char(4) Sí
el de teléfono.
Número Campo concatenado con “Lada”
Teléfono Char(15) Sí
telefónico. para subir a COMET.
Campo ligado con Industry en
Giro Industry. Char No
COMET, tomar lista de LOV.
Nombre Nombre del Campo ligado con First Name
Char(20) Sí
Contacto contacto. Contact de COMET.
Apellido Apellido del Campo ligado con Last Name
Char(20) Sí
Contacto contacto. Contact de COMET.
Correo del Correo electrónico Campo que se liga con Email
Char(30) Sí
contacto del contacto. Address en COMET.
Campo abierto que se liga con
Comentarios Comentarios. ¿? No
Comments en COMET.
Ciudad para
Country registro de Char(6) Interno Valor “México”, invariable.
COMET.
Profesión del Campo ligado con el Saludation en
Título Char(20) No
contacto. COMET y se debe tomar del LOV.
Campo ligado con el Contact Type
Tipo Contacto Tipo de contacto. Char(20) No
en COMET y se debe tomar del LOV.
LEAD Correo electrónico
ORIGINATOR del originador del Char(255) No
EMAIL LEAD.
Campo de control
LEAD interno para la Formato: #EMPL + “FOLIO” +
Char(30) Interno
ORIGINATOR identificación del #FOLIO
LEAD.
Campo para controlar qué registros
Campo de control
Control Boolean Interno se han procesado para la carga a
de proceso
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.

138
[DHL: Micrositio LEADs] – Solicitud de cambio
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.

139

También podría gustarte