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 1-2); una caja Figura 1 negra que a partir de ciertas entradas genera una salida. En este caso, las entradas involucran, aunque no están limitadas a: • Un flujo de trabajo, es decir, una parte del proceso de negocio del cliente que se jo requiere automatizar. • Información sobre sistemas que utiliza el cliente y que puedan influir sobre la realización del software. Estos pueden ser internos o externos. • • Bases de datos existentes a las que se deba tener acceso mediante la solución. s Una especificación técnica que complementa la información sobre el flujo de trabajo, indicando las necesidades del cliente para construir el software. Esta puede basarse en políticas o limitaciones tecnológicas. aciones • • 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

Flujo de trabajo

Sistemas internos y externos

Bases de datos

Especificación técnica

Contexto del cliente

Contexto del proveedor

Metodología

Arquitectura

Buenas prácticas

Solución informática

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

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

Durante los próximos capítulos del presente documento, se plasma el seguimiento de este seguimien 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- [NAUR, 1969] se observa la línea de tiempo para un proyecto de -1 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 Almacenamiento de información 1 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, 2007 CHURCHER, 2007]

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

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 que modela la funcionalidad del sistema y su interacción con uso, ue los usuarios u otros sistemas, llamados actores (Figura 2-3 B). • La vista de la máquina de estados, que describe el ciclo de vida de un objeto a través de estados, sus estados y las transacciones entre los mismos en un cierto periodo (Figura 2-3 C). • La vista de actividades, que describe el flujo de una operación concreta, particularizando actividades, la descripción de la vista de la máquina de estados (Figura 2-3 C). • La vista de interacción, que muestra el flujo de control del modelo a través de diversos interacción, 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 2-3 E). Figura 2 • La vista de gestión del modelo, que describe la organización del modelo como un modelo, 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 de creación Clase
Fábrica de métodos (Factory Method)

Patrones estructurales
Adaptador (Adapter)

Patrones de comportamiento
Intérprete (Interpreter) Plantilla de métodos (Template Method) Cadena de mando (Chain of Responsibility) Instrucción (Command) Iterador (Iterator) Mediador (Mediator) Memoria (Memento) Observador (Observer) Estado (State) Estrategia (Strategy) Visitante (Visitor)

Ámbito
Objeto

Fábrica abstracta (Abstract Factory) Constructor (Builder) Prototipo (Prototype) Singular (Singleton)

Adaptador (Adapter) Puente (Bridge) Compuesto (Composite) Decorador (Decorator) Fachada (Façade) Peso ligero (Flyweight) Representante (Proxy)

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

C

B

D

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

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 Número de oficinas Número de concentradoras, almacenes y terminales Número de puertos de salida Número de aviones Número de vehículos Número de países y territorios Envíos por año Cobertura de destinos

Alrededor de 285,000 Alrededor de 6,500 Más de 450 240 420 76,200 Más de 220 Más de 1,500 millones 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

Administrador funcional

Actualizar 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 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: • • R03 Reporteo Gerencial Alta • • Reporte gráfico del pipeline de LEADs. Reporte gráfico de status de LEADs. Número de cuentas aperturadas al LEAD. LEADs que han abierto cuentas pero no han cumplido con las condiciones de pago. • • • • Convertion Rate. Fuentes actuales generadoras de LEADs. Cuentas aperturadas. Cuentas aperturadas por canal. Alta en el servidor “avión-cl” de DHL, el cual cuenta con arreglos

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 R04 de LEADs Media

• •

El folio del LEAD. Su número de nómina.

Los administradores y superusuarios podrán a su vez imprimir una consulta del status de LEADs por estaciones. 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 R06 condiciones de pago Media monto mínimo al mes para que sea pagado un LEAD, así como su vigencia, es decir, el tiempo en el que los parámetros anteriores deben cumplirse antes de que el LEAD se dé de baja. 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: • Actualización de R07 Información Alta • • • • • • Número de LEAD formats ingresados. Fecha de ingreso del LEAD. Fecha de pago. LEADs exitosos y no exitosos. Causa de fallo del LEAD. Potencial de revenue. Canal de venta y ejecutivo de cuenta donde está asignado el LEAD. • Pago a Recursos R08 Humanos administrador funcional del sistema deberá ser capáz de Alta ser pagados y enviarlo a manera de correo electrónico. El Número de nómina a quien fue pagado.

El sistema debe generar un reporte de los LEADs que deben

45

ID R08

Nombre Pago a Recursos

Prioridad Alta

Características gestionar los destinatarios de dicho correo, así como los campos del layout de salida del reporte. El sistema deberá contar con un módulo administrable de

Humanos (cont.) Noticias y Mensajes R09 Importantes

Media/Alta noticias y/o mensajes importantes, el cual deberá soportar 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 Electrónico Baja correo informativo cada vez que cambie su status.

IV.5 Requerimientos no funcionales del sistema
Los requerimientos no funcionales complementan a los funcionales, describiendo características que debe tener el sistema sin referirse a la propia funcionalidad. Estos requerimientos suelen ser limitantes en el desarrollo del software. Para el proyecto en cuestión, se identificaron los siguientes requerimientos no funcionales, divididos en requerimientos de usabilidad (Tabla 4-2), confiabilidad (Tabla 4-3), seguridad (Tabla 4-4), desempeño (Tabla 4-5) y documentación (Tabla 4-6).
Tabla 4-2: Requerimientos de usabilidad del sistema.

ID U01

Nombre Fácil Aprendizaje

Prioridad

Características

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 Media/Alt

Características El sistema debe ser capaz de recuperarse de errores

C01

Tolerancia a Fallas a

presentados de manera automática y/o mostrar el procedimiento a seguir para corregirlos.

C02

Disponibilidad

Alta

El sistema debe estar disponible 24/7.

Tabla 4-4: Requerimientos de seguridad del sistema.

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 Manual de

Prioridad Al finalizar el

Características desarrollo se deberá entregar la

DOC01 mantenimiento

Media/Alta documentación necesaria para permitir el mantenimiento del sistema.

DOC02

Manual de usuario

Alta

El sistema deberá contar con un manual de usuario.

IV.6 Restricciones
Junto con los requerimientos, se entregó un listado de restricciones que deben ser tomadas en cuenta durante el desarrollo del sistema, y que también responden a necesidades específicas del cliente. • • • • El sistema deberá ser desarrollado como una aplicación web. Los datos deberán ser almacenados en una base de datos SQL Server 2000. El sistema deberá estar basado en la plataforma de desarrollo .NET 2.0. El diseño del sistema no incluirá conectividad con otros sistemas de manera directa.

IV.7 Resumen
Durante la fase de inicio se mantuvieron reuniones con el cliente con el objetivo de entender el alcance del proyecto y las necesidades del negocio, construyendo así los requerimientos del sistema. La primera reunión se llevó a cabo el día 5 de diciembre de 2006, donde se presentaron los requerimientos del sistema. Sin embargo, el proyecto dio inicio formalmente a principios de enero de 2007, cuando el presupuesto para el desarrollo fue aprobado por DHL. Esta fase tuvo una duración aproximada de 28 horas, divididas en casi tres meses, dada la disponibilidad por parte del cliente de concertar reuniones para el levantamiento de requerimientos. Las actividades realizadas se muestran en la Tabla 4-7.

48

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

Actividad realizada Levantamiento de requerimientos con el cliente Análisis de la información y generación de requerimientos

Horas efectivas de trabajo 20 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 sea escalable y pueda ampliarse con mayor facilidad en caso de ción 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 5 Representación de una arquitectura multicapa. 5-2:

Capa de presentación: En esta capa superior, se presenta el sistema al usuario, le presentación: comunica y captura la información realizando un procesamiento mínimo que mínimo, comúnmente consiste de un filtrado previo para comprobar que no existen errores de formato. Esta capa se comunica únicamente con la capa de negocio.

Capa de negocio: En esta capa residen los programas que se ejecutan, recibiendo : peticiones del usuario y enviando las respuestas tras el proceso. Se denomina capa de o negocio o lógica del negocio, pues aquí es donde se establecen todas las reglas que negocio, deben cumplirse. La capa de negocio se comunica con la capa de presentación para recibir solicitudes y entregar resultados, y con la capa de datos, para solicitar que se entregar 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 s siguientes 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 descubiertas por otros componentes. descubiertas • • 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 Arquitectura contextualizada .1 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 5 Arquitectura contextualizada del sistema. 5-3:

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

Sistema LEADs

24 Meses

SUSPECTS DEVELOPMENT LEADS 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

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.

7

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 515) 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 518.

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.

Los nombres de los métodos de los servicios, así como sus implementaciones, se han omitido en el diagrama por motivos de claridad.

11

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 LEADs

Reportes 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 y Mensajes. Si el usuario que la visita es un usuario registrado, se icias Mensajes. personalizará mostrando su nombre de usuario. V.5.1.2 Administrador Meramente informativo en el diagrama, se muestra para definir los puntos del mapa que serán accesibles únicamente para los administradores. 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 Levantamiento de las reglas de negocio con el cliente Análisis de la información Diseño del sistema Desarrollo de arquitectura ejecutable

Horas efectivas de trabajo 18 15 15 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.

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.

12

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 El proyecto CentralMedia.Dhl.Leads .1 El proyecto se encuentra dividido en 4 carpetas como muestra la Figura 6-3: Datos, Modelo, 6 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. Contiene también dos carpetas nombr nombradas Interfaz e Implementación. La carpeta Interfaz . contiene las interfaces de los DAOs que serán expuestas a la capa de negocio, y la carpeta Implementación contiene, como su nombre lo indica, la implementación de cada una de estas interfaces, indicando en el nombre de cada clase la tecnología utilizada: JakartaExcelDao, n 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 modelo estático del sistema tal como modelo 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 6 Estructura de despliegue del proyecto Web. 6-4:

Dentro de Bin se encuentran todas las librerías de clases utilizadas por el proyecto, incluyendo el compilado de CentralMedia.Dhl.Leads y las DLLs de Spring.NET y NHibernate. La carpeta config contiene los archivos XML de configuración para NHibernate (Datos.xml), Spring.NET (Negocio.xml y Vista.xml) y Log4Net (Log4Net.xml). La subcarpeta Mapeos incluye ng.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 por los archivos ASPX. por 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 Diseño de interfaz gráfica Adaptación de la interfaz para web Módulo de Contacto Gestión de usuarios Módulo de Noticias y Mensajes Importantes Módulo de Catálogos Módulo de Actualización de Información Módulo de Configuraciones Módulo de Reportes Reporte Gráfico de LEADs Módulo de Bitácora Módulo de mensajería para correos electrónicos

Horas efectivas de trabajo 10 10 5 18 20 15 30 8 25 10 4 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 Pruebas de instalación en servidores de pruebas Pruebas de usuario al sistema Instalación en el servidor de producción

Horas efectivas de trabajo 10 12 1

Se refiere a una versión del producto terminado preliminar a su lanzamiento. Se considera la última etapa de pruebas.

16

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 clienteproveedor 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-dedependencias-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/riseof-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 Se utiliza una fábrica abstracta cuando: • Un sistema debe ser independiente de la manera en que sus productos son creados, compuestos y representados. • Un sistema debe ser configurado con una de múltiples familias de productos. • Una familia de objetos relacionados es diseñada para usarse en conjunto, y es necesario forzar esta condición. • Se desea proveer una librería de clases de productos, publicando sólo sus interfaces, no sus implementaciones. Se utiliza un constructor cuando: • El algoritmo para crear un objeto complejo debe ser independiente de las partes que componen el objeto y cómo es ensamblado. • El proceso de construcción debe permitir diferentes representaciones para el objeto que es construido. Se utiliza una fábrica de métodos cuando: • Una clase no puede anticipar la clase de objetos que debe crear. • Una clase requiere que sus subclases especifiquen objetos a crear. • Las clases delegan responsabilidades a una de varias subclases auxiliares y se Consecuencias

Fábrica Abstracta Abstract Factory

Proveer una interfaz para crear familias de objetos dependientes o relacionados entre sí sin especificar sus clases concretas.

• Aísla clases concretas. • Facilita el intercambio de familias de productos. • Promueve la consistencia entre productos. • Dificulta el soporte para nuevos tipos de producto.

Constructor Builder

Separar la construcción de un objeto complejo de su representación, tal que el mismo proceso de construcción pueda crear diferentes representaciones.

• Permite variar la representación interna de un producto. • Aísla el código para construcción y su representación. • Permite un mejor control sobre los procesos de construcción.

Fábrica de Métodos Factory Method

Definir una interfaz para la creación de objetos, permitiendo a las subclases decidir qué clase instanciar.

• Provee flexibilidad para la creación de objetos.

112

Nombre Fábrica de Métodos Factory Method (cont.)

Problema

Solución

Consecuencias

requiere localizar delegada.

la

clase

• Conecta clases en jerarquías paralelas.

Prototipo Prototype

Especificar los tipos de objetos a crear usando instancias prototipo y crear nuevos objetos copiando este prototipo.

Se utiliza un prototipo cuando: • Un sistema debe ser independiente de cómo sus productos son creados, compuestos y representados, y • Las clases a instanciar son especificadas en tiempo de ejecución, o • Se requiere evitar una jerarquía de clases de fábricas paralela a la jerarquía de clases de productos, o • Las instancias de una clase pueden tener una o pocas combinaciones de estado. Se utiliza un singular cuando: • Debe haber sólo una instancia de una clase y ésta debe ser accesible a los clientes desde un punto de acceso conocido. • Cuando la única instancia debe ser extensible con subclases, y los clientes deben ser capaces de extenderla sin modificar el código.

• Permite agregar y eliminar productos en tiempo de ejecución. • Permite especificar nuevos productos variando sus valores y estructura. • Reduce las subclases. • Permite configurar una aplicación con clases dinámicamente.

Singular Singleton

Asegurar que una clase tiene sólo una instancia y proveer un punto de acceso global a ella.

• Acceso controlado a la única instancia. • Reduce el espacio de nombres. • Permite el refinamiento de operaciones y representación. • Permite un número variable de instancias. • Es más flexible que las operaciones de clases.

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

Adaptador Adapter

Convertir la interfaz de una clase en otra que es esperada por el cliente.

113

Nombre

Problema

Solución otras interfaces. • Se requiere utilizar un gran número de subclases existentes, pero no es práctico adaptar la interface creando subclases para cada una. Se utiliza un puente cuando: • Se requiere evitar la relación entre la abstracción y la implementación. • La abstracción y su implementación deben ser extensibles con subclases. • Los cambios realizados a la implementación no deben tener impacto en los clientes. • Se requiere esconder la implementación a los clientes. • Se requiere separar un objeto en dos partes. • Se requiere compartir la implementación a múltiples objetos. Se utiliza un compuesto cuando: • Se requiere representar una jerarquía parcial de objetos. • Se requiere que los clientes ignoren la diferencia entre composiciones de objetos y objetos individuales. Se utiliza un decorador cuando: • Se debe añadir responsabilidades a un objeto sin afectar a los demás objetos. • Se debe retirar responsabilidades de un objeto. • Extender con subclases no es práctico. Se utiliza una fachada cuando: • Se desea proveer una interfaz

Consecuencias adaptada. • No se requieren objetos adicionales para llegar a la clase adaptada. • Un mismo adaptador puede adaptar varios objetos.

Adaptador Adapter (cont.)

Convertir la interfaz de una clase en otra que es esperada por el cliente.

Puente Bridge

Separar la abstracción de su implementación, permitiendo que varíen independientemente.

• Facilita la extensibilidad. • Esconde los detalles de implementación a los clientes.

Compuesto Composite

Componer objetos en estructuras de árbol para representar jerarquías parciales.

• Define jerarquías de objetos primitivos y compuestos. • Simplifica al cliente. • Facilita la adición de nuevos componentes. • Generaliza el diseño. • Es más flexible que la herencia estática. • Evita clases en posiciones altas de la jerarquía. • Un decorador y un componente no son idénticos. • Crea muchos objetos pequeños. • Reduce el número de objetos a los que el

Decorador Decorator

Añadir responsabilidades a un objeto dinámicamente.

Fachada Façade

Proveer una interfaz unificada a un conjunto de interfaces en un

114

Nombre

Problema

Solución simple a un subsistema complejo. • Existen muchas dependencias entre clientes e implementaciones de una abstracción. • Se requiere jerarquizar los subsistemas. Se utiliza peso ligero cuando se presentan todos estos casos al mismo tiempo: • Se utiliza un gran número de objetos. • Los costos de almacenaje son altos por la cantidad de objetos. • La mayoría de los objetos puede ser extrínseco. • Muchos grupos de objetos pueden ser reemplazados por un grupo pequeño de objetos compartidos. • La aplicación no depende de la identidad de los objetos.

Consecuencias cliente tiene acceso. • Promueve un acoplamiento bajo entre el subsistema y el cliente. • No evita que las aplicaciones utilicen clases del subsistema, si son requeridas.

Fachada Façade (cont.)

subsistema.

Peso ligero Flyweight

Utilizar la compartición para soportar un gran número de objetos modulares eficientemente.

• Aumenta los costos de transferencia y búsqueda. • Reduce los costos de almacenaje.

Representante Proxy

Proveer un contenedor para que otro objeto controle el acceso a él.

• Un representante remoto provee un representante local para un objeto en un espacio de nombres diferente. • Un representante virtual crea objetos costosos en demanda. • Un representante de protección controla el acceso al objeto original.

• Un representante remoto puede esconder el hecho de que un objeto reside en otro espacio de nombres. • Un representante virtual puede realizar optimizaciones como la creación de objetos en demanda. • Un representante de protección permite tareas adicionales cuando se accede al objeto.

115

Patrones de comportamiento
Nombre Problema Solución Se utiliza una cadena de mando cuando: • Más de un objeto puede manejar la solicitud. • Se desea enviar un mensaje sin especificar explícitamente al receptor. • Los receptores deben ser especificados dinámicamente. Se utiliza el patrón de instrucción cuando: • Se requiere parametrizar objetos por la acción que realizan. • Se requiere especificar, encolar y ejecutar solicitudes en tiempos diferentes. • Se requiere implementar la instrucción deshacer. • Se requiere soportar cambios en caso de un colapso en el sistema. • Se requiere estructurar un sistema con operaciones de alto nivel basadas en operaciones primitivas. Consecuencias • Reduce dependencias. • Añade flexibilidad para asignar responsabilidades a objetos. • No garantiza la recepción de mensajes. • Elimina la dependencia del objeto que invoca la operación de aquel que la ejecuta. • Las instrucciones son objetos de primera clase. • Se puede ensamblar instrucciones en una instrucción compuesta. • No se debe cambiar clases existentes para añadir nuevas instrucciones. • Facilita el cambio y la extensión de la gramática. • Facilita la implementación de la gramática. • Las gramáticas complejas son difíciles de mantener. • Permite agregar nuevas formas de interpretar expresiones. • Soporta variaciones en la transversal de un agregado.

Cadena de Mando Chain of Responsibility

Evitar la dependencia del emisor de una solicitud a su receptor, permitiendo a más de un objeto manejar la solicitud.

Instrucción Command

Encapsular las solicitudes a un objeto, permitiendo parametrizar a los clientes con diferentes solicitudes.

Intérprete Interpreter

Dado un lenguaje, definir una representación para su gramática con un intérprete que usa la representación para interpretar sentencias en el lenguaje.

Se utiliza un intérprete cuando: • La gramática es simple. • La eficiencia no es crítica.

Iterador Iterator

Proveer un acceso a los elementos de un objeto agregado sin publicar su representación.

Se utiliza un iterador cuando: • Se requiere acceder a un objeto agregado sin publicar su

116

Nombre

Problema

Solución representación. • Se requiere soportar múltiples transversales de objetos agregados. • Se requiere proveer una interfaz uniforme para diferentes estructuras agregadas. Se utiliza un mediador cuando: • Un conjunto de objetos se comunican de maneras complejas pero bien definidas. • La reutilización de un objeto es complicada porque se refiere y comunica con múltiples objetos. • Un comportamiento distribuido entra varias clases debe ser personalizado sin subclases.

Consecuencias • Simplifica las interfaces de los agregados. • Más de un transversal puede estar pendiente de un agregado.

Iterador Iterator (cont.)

Mediador Mediator

Definir un objeto que encapsule la manera en la que los objetos interactúan.

• Limita las subclases. • Independiza colegas. • Simplifica los protocolos de objetos. • Abstrae la cooperación entre objetos. • Centraliza el control.

Memoria Memento

Sin violar la encapsulación, capturar y externar el estado interno de un objeto, tal que pueda ser restaurado después.

Se utiliza memoria cuando: • El estado de un objeto debe ser almacenado. • Una interfaz directa a la obtención del estado de un objeto expondría los detalles de su implementación.

• Preserva la encapsulación. • Simplifica al originador. • Puede resultar costoso. • Define interfaces amplias. • Existen costos escondidos en su uso.

Observador Observer

Definir una dependencia uno a muchos entre objetos tal que cuando un objeto cambia de estado, todos sus dependientes son notificados y actualizados automáticamente.

Se utiliza un observador cuando: • Una abstracción tiene dos aspectos, ambas dependientes de la otra. • Cuando los cambios de un objeto afectan a otros, y no se sabe cuántos serán los afectados. • Cuando un objeto debe notificar a otros sin asumir cuáles son. Se utiliza un estado cuando: • El comportamiento de un objeto depende de su estado y debe cambiar en tiempo de ejecución. • Las operaciones tienen sentencias condicionales largas

• Abstrae la dependencia entre observador y sujeto. • Soporta comunicación amplia. • Actualizaciones inesperadas.

Estado State

Permitir a un objeto alterar su comportamiento cuando su estado interno cambia.

• Localiza diferentes operaciones para diferentes estados del objeto. • Hace las transiciones de estado explícitas. • El estado de los

117

Nombre Estado State (cont.)

Problema

Solución que dependen del estado del objeto. Se utiliza una estrategia cuando: • Muchas clases relacionadas difieren sólo en su comportamiento. • Se requieren diferentes variantes para un algoritmo. • Un algoritmo utiliza datos que los clientes no deberían conocer. • Una clase define muchos comportamientos que aparecen como sentencias condicionales múltiples en sus operaciones. Se utiliza una plantilla de métodos para: • Implementar partes no variantes de un algoritmo y dejar que el comportamiento en las subclases cambie. • Factorizar y localizar comportamientos comunes de subclases en una clase común para evitar duplicación de código. • Controlar extensiones de subclases. Se utiliza visitante cuando: • Una estructura de objetos contiene muchas clases con diferentes interfaces, y se requiere realizar operaciones en estos objetos que dependan de sus clases concretas. • Varias operaciones distintas necesitan ser ejecutadas en objetos de una estructura, evitando contaminar sus clases con estas operaciones. Las clases que definen los objetos de la estructura raramente cambian, pero se requiere definir nuevas operaciones para la

Consecuencias objetos puede compartido. ser

Estrategia Strategy

Definir una familia de algoritmos, encapsularlos y hacerlos intercambiables.

• Crea familias de algoritmos relacionados. • Representa una alternativa a las subclases. • Elimina sentencias condicionales.

Plantilla de Métodos Template Method

Definir el esqueleto de un algoritmo en una operación, enviando algunos pasos a subclases.

• Son una fundamental reutilización.

técnica de la

Visitante Visitor

Representar una operación a ser utilizada por elementos de una estructura de objetos.

• Facilita la adición de nuevas operaciones. • Recolecta operaciones relacionadas y separa las no relacionadas. • Dificulta la agregación de clases de elementos concretos.

118

Nombre Visitante Visitor (cont.)

Problema estructura.

Solución

Consecuencias

119

Anexo B

Diccionario de entrada de datos del micrositio

SUSPECTS
Nombre del dato GSFA Customer ID Tipo Char Tamaño (Bytes) 50 Descripción 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 mismo, utilizando la siguiente estructura: #EMPLEADO_FOLIO#FOLIO Fecha en que se ingresa el LEAD en formato dd-mmaaaa. Nombre del cliente. Fecha de aprobación o rechazo del LEAD para esta fase en formato dd-mm-aaaa. Potencial de ingreso. Razón por la que el LEAD ha sido rechazado, en su caso. Tipo de fuente del LEAD (por campaña, base de datos, etc.).

Lead Originator

Char

15

Suspect creation Date Customer Name Suspect accepted/Rejected at Qualification Potential Revenue Reason for Qualified out Lead Source Type

Date Char Date Numbe r Char Char

7 100 7 22 50 30

DEVELOPMENT LEADS
Nombre del dato Customer GSFA id Customer name Reason for rejection Customer Sales Territory Code Lead Source Type Creation date Tipo Char Char Char Char Char Date Tamaño (Bytes) 50 100 30 75 30 7 Nombre del cliente. Razón por la que el LEAD ha sido rechazado, en su caso. Código del ejecutivo asignado a la cuenta del LEAD. Tipo de fuente del LEAD (por campaña, base de datos, etc.). Fecha en que se ingresa el LEAD en formato dd-mmaaaa. También llamado LEAD Source, indica el número del empleado que genera el LEAD, así como el folio del mismo, utilizando la siguiente estructura: #EMPLEADO_FOLIO#FOLIO Descripción Llave primaria asignada por COMET.

Lead originator

Char

15

121

CUSTOMERS
Nombre del dato GSFA CUSTOMER ID COMMITED REVENUE LOST BUSINESS REASON LOST BUSINESS REASON AT REASON FOR QUALIFIED OUT SALES TERRITORY CODE SUSPECT ACCEPTED AT SUSPECT ACCEPTED BY YTD REVENUE Tipo Char Number Char Date Char Char Date Char Number Tamaño (Bytes) 50 22 75 7 50 75 7 15 22 Descripción Llave primaria asignada por COMET. Ingreso esperado del cliente. Razón por la que se perdieron las negociaciones. Fecha en que se perdieron las negociaciones. Razón por la que el cliente fue descalificado. Código del ejecutivo asignado a la cuenta del LEAD. Fecha en que el LEAD pasa de SUSPECT a PROSPECT. Código del empleado que acepta el LEAD como PROSPECT. 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 mismo, utilizando la siguiente estructura: #EMPLEADO_FOLIO#FOLIO Fecha en que el LEAD pasa de PROSPECT a OPPORTUNITY. Código del empleado que acepta el LEAD como OPPORTUNITY.

LEAD ORIGINATOR

Char

20

PROSPECT ACCEPTED AT PROSPECT ACCEPTED BY

Date Char

7 15

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

122

Nombre del dato DHL PIPELINE 9 ENTERED EXPECTED CLOSE DATE OPPORTUNITY CREATED DATE OPORTUNITY CREATED BY LOGIN ID POTENTIAL REVENUE ACCOUNT NUMBER

Tipo Date Date Char Char Number Char

Tamaño (Bytes) 7 7 100 15 22 15

Descripción Fecha en que el LEAD llega al noveno estado del proceso (Future Opportunity). Fecha esperada para el cierre de negociaciones. Fecha en que el LEAD pasa de PROSPECT a OPPORTUNITY. Código del empleado que acepta el LEAD como OPPORTUNITY. Potencial del ingreso del cliente. Número de cuenta del cliente utilizado para conectar con el archivo 24 meses.

ACCOUNTS
Nombre del dato GSFA CUSTOMER ID ACCOUNT CLOSED DATE ACCOUNT CREATE DATE ACCOUNT NUMBER FIRST SHIPPMENT DATE LAST SHIPPMENT DATE Contract end date Tipo Char Date Date Char Date Date Date Tamaño (Bytes) 50 7 7 255 7 7 7 Descripción Llave primaria asignada por COMET. Fecha de cierre de negociaciones. Fecha de creación de la cuenta. Número de cuenta del cliente utilizado para conectar con el archivo 24 meses. Fecha del primer envío. Fecha del último envío. Fecha de fin del contrato.

24 Meses
Nombre del dato CUENTA PRODUCTO TERRITORIO ESTRUCTURA MAC NOM_MAC CI INDUSTRIA EMPRESA Tipo TEXT TEXT TEXT TEXT TEXT TEXT TEXT TEXT TEXT Tamaño (Bytes) 255 255 255 255 255 255 255 255 255 Tipo de producto. Código del ejecutivo asignado a la cuenta (canal negociador). Complemento al ejecutivo (visitador). ID del conjunto de cuentas. Nombre del conjunto de cuentas. Código de industria. Nombre de la industria del cliente (automotriz, fármaco, etc.). Nombre de la cuenta. Descripción Número de cuenta del cliente.

123

Nombre del dato REVENUE SHIPPMENTS KILOS FUENTE

Tipo DOUBL E DOUBL E DOUBL E TEXT

Tamaño (Bytes) 8 8 8 255

Descripción Ingreso en el mes actual. Número de envíos en el mes actual. Kilos enviados en el mes actual. Fuente de la cuenta (inactiva o IBS).

Empleados – Extracto de COMET
Nombre del dato Organisation User ID Last Name First Name Middle Name Work Phone Email Position Responsability Territory Tipo Char Char Char Char Char Char Char Char Char Char Tamaño (Bytes) 100 50 50 50 50 40 100 50 50 75 Descripción Organización a la que pertenece el empleado. Identificador del empleado. Apellido. Nombre. Segundo nombre. Número telefónico del trabajo. Correo electrónico. Posición o posiciones del empleado. Responsabilidad o responsabilidades del empleado. Territorio o territorios del empleado.

Empleados – Recursos Humanos
Nombre del dato ID N° de Empleado Last Second Last First Name Per Status Status Hire Date Term Date Action Reason Tipo TEXT TEXT TEXT TEXT Text TEXT TEXT TEXT TEXT TEXT TEXT Tamaño (Bytes) 255 255 255 255 255 255 255 255 255 255 255 Descripción Identificador del empleado como una cadena de 11 dígitos. Identificador del empleado sin ceros a la izquierda. Apellido paterno. Apellido materno. Nombre(s). Campo no utilizado. Campo no utilizado. Fecha de contratación. Campo no utilizado. Campo no utilizado. Campo no utilizado.

124

Nombre del dato Job Code Position Descr DeptID Descr Eff Date Reports to Location CREST Sex CR

Tipo TEXT TEXT TEXT TEXT TEXT TEXT TEXT TEXT TEXT TEXT TEXT

Tamaño (Bytes) 255 255 255 255 255 255 255 255 255 255 255 Campo no utilizado. Campo no utilizado. Puesto. Campo no utilizado. Área. Campo no utilizado. Campo no utilizado. Campo no utilizado. Campo no utilizado. Género. Campo no utilizado.

Descripción

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
Nombre del dato ID APELLIDO_PATERNO APELLIDO_MATERNO NOMBRE EMAIL Tipo Integer Varchar Varchar Varchar Varchar Tamaño (Bytes) 10 50 50 100 255 Apellido paterno. Apellido materno. Nombre de pila completo. Dirección de correo electrónico. Descripción Identificador del registro generado secuencialmente.

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

EJECUTIVO
Nombre del dato ID ID_PERSONA ORGANIZATION TELEFONO PUESTO RESPONSABILIDAD TERRITORIO Tipo Varchar Integer Varchar Varchar Varchar Varchar Varchar Tamaño (Bytes) 50 10 255 40 50 50 50 Descripción Identificador del usuario generado por COMET. Identificador de la persona a la que corresponden los datos del ejecutivo. Organización a la que pertenece el ejecutivo. Número telefónico de oficina. Puesto o puestos del ejecutivo. Responsabilidad o responsabilidades del ejecutivo. Territorio o territorios del ejecutivo.

128

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

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

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

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

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

129

Nombre del dato NOMBRE

Tipo Varchar

Tamaño (Bytes) 255

Descripción Nombre de la industria.

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

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

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

EVENTO_CUENTA
Nombre del dato ID_CUENTA ID_EVENTO FECHA Tipo Integer Integer Date Tamaño (Bytes) 10 5 7 Descripción Identificador de la cuenta que presentó el evento. Identificador del evento sucedido. Fecha en la que se presentó el evento.

EVENTO_LEAD
Nombre del dato ID_LEAD ID_EVENTO Tipo Varchar Integer Tamaño (Bytes) 10 5 Descripción Identificador del LEAD que presentó el evento. Identificador del evento sucedido.

130

Nombre del dato FECHA

Tipo Date

Tamaño (Bytes) 7

Descripción Fecha en la que se presentó el evento.

CUENTA
Nombre del dato ID NUMERO PRODUCTO ID_EJECUTIVO STATUS ID_INDUSTRIA NOMBRE INGRESO_OBJETIVO INGRESO ENVIOS KILOS PAGADO ID_LEAD POTENCIAL_INGRESO Tipo Integer Varchar Varchar Varchar Varchar Varchar Varchar Numeric Numeric Integer Numeric Integer Varchar Numeric Tamaño (Bytes) 10 255 255 255 255 255 255 22.2 22.2 10 22.2 1 50 22.2 Número de cuenta. Producto que maneja el cliente. Ejecutivo de cuenta asignado. Estado de la cuenta (abierta, cerrada o inactiva) Industria a la que pertenece la cuenta. Nombre de la cuenta. Ingreso objetivo. Ingreso al mes actual. Envíos en el mes actual. Kilos enviados en el mes actual. Indica si el LEAD que generó esta cuenta ha sido pagado. Identificador del LEAD que generó la cuenta. Potencial de ingreso del cliente. Descripción Identificador de la cuenta generado secuencialmente.

LEAD
Nombre del dato ID FOLIO ID_EMPLEADO TIPO_FUENTE RAZON_DESCALIFICACION RAZON_PERDIDA_NEGOCIACION FECHA_ESPERADA_CIERRE ID_ESTADO_PIPELINE ID_ESTADO Tipo Varchar Varchar Varchar Integer Varchar Varchar Date Integer Integer Tamaño (Bytes) 50 255 11 10 50 75 7 2 10 Descripción Identificador del LEAD, de tipo cadena de caracteres, equivalente al GSFA Customer ID. Folio del LEAD format. Empleado que generó el LEAD. Tipo de fuente del LEAD. Razón de que el LEAD haya sido descalificado. Razón por la cual se perdieron las negociaciones. Fecha en que se espera se cierren las negociaciones. Estado en el que se encuentra el LEAD. Base de datos en la que se encuentra actualmente el LEAD.

131

CONFIGURACION
Nombre del dato ID NOMBRE VALOR Tipo Integer Varchar Varchar Tamaño (Bytes) 10 255 255 Descripción Identificador del registro de configuración. Nombre de la variable de configuración. Valor de la variable de configuración.

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

Nueva noticia o mensaje 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 Superusuario Cuentas 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 Fecha Folio I Folio LEAD Forma de registro Núm. Empleado Número empleado. de Descripción Fecha de registro. Folio del sistema. Folio del formato para LEADs. Tipo Date Char(10) Char(10) Char(1) Mandatorio Por sistema Por sistema Variable Sí Comentarios Fecha en la que se registra el LEAD, debe tomarse del sistema. Folio consecutivo asignado por el sistema. Folio del LEAD format. Campo para identificar si el registro es directo o a través de un formato de LEAD. Campo para el registro de número de empleado generador del LEAD y llave para la agrupación de LEADs por empleado. Nombre del empleado que genera el LEAD. Este campo debería desplegarse al registrar el Núm. Empleado haciendo una validación con la tabla de empleados que ya se encuentra cargada en la aplicación.

Char(15)

Nombre Empleado

Nombre empleado.

del

Char(50)

Nombre del cliente Dirección Colonia CP Delegación

Razón social de la empresa. Dirección con número de la empresa. Colonia. Código Postal. Municipio delegación. o

Char(75) Char(75) Char(75) Char(5) Char(75)

Sí Sí Sí Sí Sí Campo ligado con City en COMET. Este campo se liga con el Address 1 de COMET. Campo ligado con Address 2 de COMET.

137

[DHL: Micrositio LEADs] – Solicitud de cambio Estado Lada Teléfono Giro Nombre Contacto Apellido Contacto Correo del contacto Comentarios Country Título Tipo Contacto LEAD ORIGINATOR EMAIL LEAD ORIGINATOR Estado de república. la Char(75) Char(4) Char(15) Char Char(20) Char(20) Char(30) ¿? para de del Char(6) Char(20) Char(20) Sí Sí Sí No Sí Sí Sí No Interno No No No Campo ligado con State en COMET, estos valores se deben tomar del LOV. Este campo se debe concatenar con el de teléfono. Campo concatenado con “Lada” para subir a COMET. Campo ligado con Industry en COMET, tomar lista de LOV. Campo ligado con First Name Contact de COMET. Campo ligado con Last Name Contact de COMET. Campo que se liga con Email Address en COMET. Campo abierto que se liga con Comments en COMET. Valor “México”, invariable. Campo ligado con el Saludation en COMET y se debe tomar del LOV. Campo ligado con el Contact Type en COMET y se debe tomar del LOV.

Lada del número. Número telefónico. Industry. Nombre del contacto. Apellido del contacto. Correo electrónico del contacto. Comentarios. Ciudad registro COMET. Profesión contacto.

Tipo de contacto.

Correo electrónico del originador del Char(255) LEAD. Campo de control interno para la Char(30) identificación del LEAD. Campo de control de proceso Boolean

Interno

Formato: #EMPL + “FOLIO” + #FOLIO Campo para controlar qué registros se han procesado para la carga a COMET.

Control

Interno

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

Sign up to vote on this title
UsefulNot useful