Acceso Acerca de

CRM Inteligente :: Documentación

Capítulo 5
Diseño

En esta fase se explicarán cómo se llevarán a cabo lo definido en la fase de análisis. De esta forma se detallarán las distintas decisiones que hemos tomado para el desarrollo del sistema. Además se incluyen los casos de uso extraídos a partir de la toma de requerimientos.

5.1. Arquitectura

El sistema esta compuesto por 4 grandes componentes:

5.2. Casos de uso

Son una forma de especificar los requisitos de un sistema. Tienen como misión describir la interacción entre un usuario ajeno al sistema y el sistema con texto en lenguaje natural. Los casos de uso representan los requisitos funcionales desde el punto de vista del usuario y cada uno de ellos realiza una funcionalidad concreta (iniciar sesión, registrar incidencia, ...). Para ello será necesario identificar cuales son los usuarios que interaccionan con el sistema y cuáles son sus operaciones dentro de él.

Objetivos de los casos de uso

Los objetivos de los casos de uso son:

Elementos que intervienen

Existen dos tipos de elementos que intervienen en los casos de uso:

Actores:
Son todas aquellas personas que tienen un rol en la interacción con el sistema. Todos los actores pueden desempeñar varios roles y un rol puede ser desempeñado por varios actores. Un usuario adopta la función de un actor cuando éste interactúa con el sistema.
Caso de uso:
Es la interacción que se quiere simular.

5.2.1. UC - 1. Iniciar sesión

Caso de uso 1

Iniciar sesión

Objetivos

Identificar y validar a un cliente en el sistema

Actores

Usuario, Sistema

Entradas

Identificador de usuario, contraseña

Condiciones previas

La aplicación debe estar activa, no debe haber sesión iniciada

Salidas

Mensaje informativo de inicio correcto o fallido

Post-condición si éxito

Sesión iniciada, mostrar la pantalla de bienvenida

Post-condición si fallo

No se inicia sesión, y se muestra un mensaje de error por pantalla

Activador

Botón ”Iniciar Sesión” en la pantalla de inicio de la aplicación

Secuencia

Introducir los datos, pulsar el activador

Excepciones

Los datos no son validados correctamente

Frecuencia de uso

Siempre. Previamente a cualquier acción en el sistema es preciso haber iniciado la sesión.

Asuntos pendientes

5.2.2. UC - 2. Registrar un nuevo cliente

Caso de uso 2

Registrar un nuevo cliente

Objetivos

Dar de alta en la aplicación a un nuevo cliente e incorporar sus datos al sistema

Actores

Usuario, sistema

Entradas

Datos personales de usuario

Condiciones previas

Estar en la pantalla de registro de nuevos clientes

Salidas

Confirmación de registro correcto o excepciones E1, E2

Post-condición si éxito

El usuario queda registrado como cliente en el sistema

Post-condición si fallo

El usuario queda registrado como cliente en el sistema

Activador

Botón ”Registrar usuario” en la pantalla de registro

Secuencia

Introducir los datos de usuario, pulsar el botón activador

Excepciones

E1: Ya hay un cliente registrado con el mismo identificador

E2: Faltan datos obligatorios o son incorrectos (formato, etc)

Frecuencia de uso

Baja. Una vez por cliente.

Asuntos pendientes

5.2.3. UC - 3. Crear una nueva incidencia

UC - 3.1 Crear una nueva avería
Caso de uso 3.1

Crear una nueva avería

Objetivos

Registrar los datos correspondientes a una avería

Actores

Usuario, sistema.

Entradas

Descripción de la avería, tipo de avería, fecha, urgencia, efectos y repercusión de la avería

Condiciones previas

Que se haya detectado una avería

Salidas

Notificación de operación correctamente finalizada,
Identificador de avería,
Acciones a tomar

Post-condición si éxito

Registro correcto de la avería;
Notificación a los técnicos (si procede) u otras acciones para resolver el problema;
Notificación de confirmación al cliente

Post-condición si fallo

Mensaje informativo explicando el motivo del fallo

Activador

Botón ”Introducir Avería”

Secuencia

Rellenar los datos de la avería y pulsar el activador
Si error, E1

Excepciones

E1: No haber rellenado todos los campos obligatorios

Frecuencia de uso

Alta. Cada vez que se detecta una avería

Asuntos pendientes

UC - 3.2 Crear una nueva reclamación
Caso de uso 3.2

Crear una nueva reclamación

Objetivos

Registrar los datos correspondientes a una reclamación

Actores

Usuario, sistema.

Entradas

Descripción de la reclamación, tipo de reclamación, fecha, causas de la reclamación

Condiciones previas

Cliente descontento

Salidas

Notificación de operación correctamente finalizada,

Identificador de reclamación,

Acciones a tomar

Post-condición si éxito

Registro correcto de la avería
Notificación a los técnicos (si procede) u otras acciones para resolver el problema
Notificación de confirmación al cliente

Post-condición si fallo

Mensaje informativo explicando el motivo de la reclamación

Activador

Botón ”Introducir Reclamación”

Secuencia

Rellenar los datos de la reclamación y pulsar el activador
Si error, E1

Excepciones

E1: No haber rellenado todos los campos obligatorios

Frecuencia de uso

Alta. Cada vez que se enuncia una reclamación

Asuntos pendientes

UC - 3.3 Crear una nueva consulta
Caso de uso 3.3

Crear una nueva consulta

Objetivos

Obtener información

Actores

Usuario, sistema.

Entradas

Descripción de la consulta, tipo de consulta, fecha

Condiciones previas

Sesión iniciada.
Cliente pide información.

Salidas

Respuesta a la información que se pide, si se conoce, o un aviso de que la consulta va a ser enviada a un experto

Post-condición si éxito

Registro correcto de la consulta
Si se conoce la respuesta: notificación de la respuesta a la consulta
Si no: notificar a un experto para que encuentre y envíe al cliente una respuesta a la consulta

Post-condición si fallo

Mostrar el mensaje de error informando del fallo

Activador

Botón ”Consultar”

Secuencia

Rellenar los datos de la reclamación y pulsar el activador
Si error, E1

Excepciones

Frecuencia de uso

Alta. Cada vez que se enuncia una reclamación

Asuntos pendientes

5.2.4. UC - 4. Consultar una incidencia

UC - 4.1 Consultar una avería
Caso de uso 4.1

Consultar una avería

Objetivos

Obtener información de una avería existente

Actores

Usuario, Sistema

Entradas

Identificador de la avería

Condiciones previas

Que el usuario haya iniciado sesión, que la avería exista

Salidas

Se muestran los datos de la avería solicitada y su estado actual
Acciones a tomar

Post-condición si éxito

Se guarda la actividad del cliente en el histórico del cliente

Post-condición si fallo

Se muestra un mensaje de error indicando el motivo del fallo

Activador

Botón ”Consultar” en la pantalla de averías

Secuencia

Introducir el identificador del cliente.
Pulsar el activador. Si fallo E1

Excepciones

E1 que el identificador no sea válido

Frecuencia de uso

Alta

Asuntos pendientes

UC - 4.2 Consultar una reclamación
Caso de uso 4.2

Consultar una reclamación

Objetivos

Obtener información de una reclamación existente

Actores

Usuario, Sistema

Entradas

Identificador de la reclamación

Condiciones previas

Que el usuario haya iniciado sesión, que la reclamación exista

Salidas

Se muestran los datos de la reclamación solicitada y su estado actual
Acciones a tomar

Post-condición si éxito

Se guarda la actividad del cliente en el histórico del cliente

Post-condición si fallo

Se muestra un mensaje de error indicando el motivo del fallo

Activador

Botón ”Consultar” en la pantalla de reclamaciones

Secuencia

Introducir el identificador del cliente. Pulsar el activador. Si fallo E1

Excepciones

E1 que el identificador no sea válido

Frecuencia de uso

Alta

Asuntos pendientes

UC - 4.3 Recuperar una consulta
Caso de uso 4.3

Recuperar una consulta

Objetivos

Obtener información de una consulta existente

Actores

Usuario, Sistema

Entradas

Identificador de la consulta

Condiciones previas

Que el usuario haya iniciado sesión, que la consulta exista

Salidas

Se muestran los datos de la consulta solicitada y su estado actual
Respuesta a la consulta si se ha encontrado

Post-condición si éxito

Se guarda la actividad del cliente en el histórico del cliente

Post-condición si fallo

Se muestra un mensaje de error indicando el motivo del fallo

Activador

Botón ”Recuperar” en la pantalla de consultas

Secuencia

Introducir el identificador del cliente.
Pulsar el activador. Si fallo E1

Excepciones

E1 que el identificador no sea válido

Frecuencia de uso

Alta

Asuntos pendientes

5.2.5. UC - 5 Proponer acciones

Caso de uso 5

Proponer acciones

Objetivos

Obtener una o varias acciones aplicables al contexto de la incidencia

Actores

Sistema

Entradas

Identificador del cliente, identificador de la incidencia

Condiciones previas

Que el usuario haya iniciado sesión, que la incidencia exista

Salidas

Se muestran las acciones adecuadas a la incidencia correspondiente

Post-condición si éxito

Post-condición si fallo

Se muestra un mensaje de error indicando el motivo del fallo

Activador

Automático

Secuencia

Excepciones

Frecuencia de uso

Muy Alta. Cada vez que se crea una incidencia

Asuntos pendientes

5.2.6. UC - 6 Cerrar sesión

Caso de uso 6

Cerrar sesión

Objetivos

Finalizar la sesión del cliente

Actores

Usuario, Sistema

Entradas

Condiciones previas

Que el usuario haya iniciado sesión

Salidas

Se muestra un mensaje informativo notificando la desconexión del sistema

Post-condición si éxito

Sesión cerrada

Post-condición si fallo

No se cierra la sesión

Activador

Botón ”Cerrar sesión”

Secuencia

Pulsar el activador.

Excepciones

Frecuencia de uso

Siempre

Asuntos pendientes

5.3. Diseño de la base de datos

Una vez realizado el análisis y establecido los requisitos, es necesario decidir diseñar la solución al problema. En el diseño de la base de datos se utilizó un diagrama entidad - relación. Como suele ser habitual en este tipo de diagramas cada tabla se representa junto con los atributos que la componen. Además se especifica el tipo de cada atributo. Junto a cada atributo se muestran unos pequeños iconos

PIC ó PIC ó PIC

que aportan información sobre cada atributo. Tienen el siguiente significado:

Cada tabla según el modelo entidad - relación puede estar relacionada con una o varias tablas del modelo. La nomenclatura utilizada para las relaciones es la siguiente:

Además para clarificar la lectura del diagrama se agrupan las tablas en regiones.


PIC

Figura 5.1: Diagrama entidad - relación


Dependiendo de su funcionalidad cada una de las tablas pertenecen a un grupo de los siguientes:

Datos descriptivos (Perfil del cliente):
Los datos descriptivos proporcionan información sobre el cliente. Dentro de este grupo distinguiremos 2 tipos de datos: los datos estáticos y los datos dinámicos. Los datos estáticos corresponden a aquellos datos que no cambian o lo hacen muy poco. Deben actualizarse periódicamente en plazos no menores a un año aunque existen excepciones como cuando un cliente cambia de domicilio. Los datos dinámicos de un cliente son aquellos que son más propensos a cambios. Un cliente puede adoptar varios perfiles dentro de la empresa durante su vida y existen factores que determinan su perfil. Estos factores pueden ser: deudas establecidas con la empresa, beneficios aportados, gastos, …
Datos promocionales (Acciones al cliente):
Cuando se produce una incidencia la empresa proporciona en el menor tiempo posible una solución al cliente. Esa solución se denomina ’acción’ y para cada incidencia y cada producto se guardarán todas las acciones propuestas en la tabla ’HistóricoAcciones’. Todas las acciones se almacenarán en la tabla ’Acciones’ y en el caso de que se proporcione un nuevo tipo de acción se guardará en la tabla ’Acciones’.
Datos transaccionales (Reacciones del cliente):
Dependiendo del grado de aceptación por parte del cliente a la acción propuesta por la empresa ante una incidencia, se generará una reacción (en algunos casos no se produce ninguna). Esta reacción se guardará en la tabla ’HistóricoReacciones.’ Si el tipo de reacción no se ha producido nunca se creará una nueva entrada en la tabla ’Reacciones’
Inteligencia:
Esta es la parte más compleja del diseño. A través de estas tablas se quiere proporcionar al sistema de inteligencia. El módulo de inteligencia está compuesto de reglas que mediante unos procesos estadísticos determinan cúales son las acciones que deben realizarse ante una determinada incidencia. Los factores que intervienen para determinar que acción se va a tomar en los procesos estadísticos son muy diversos, pero se basa en que reacciones se han obtenido a las diversas acciones que se han planteado ante incidencias del mismo tipo.
Datos usuarios:
Almacena los datos de los usuarios (trabajadores) y sus roles. Esta información no será procesada por las herramientas de Data Mining. Su tamaño dependerá del número de trabajadores de la empresa. Además de almacenar datos personales, también almacena el rol de cada usuario, de tal forma que cada rol tiene asociados unos privilegios. De esta forma como suele ser habitual cada trabajador, dependiendo de su rango podrá ver más o menos datos o incluso algunos datos podrán dejar de ser interesantes para determinados tipos de usuarios por lo que no se mostrarían a los usuarios con ese rol.
Incidencias:
En esta parte del diseño aparentemente simple reside la tabla de incidencias que se interconecta a través de claves ajenas con los módulos de inteligencia, datos promocionales, datos transaccionales, y datos del cliente. Cada vez que haya una nueva incidencia se almacenará en este módulo. Además para el análisis y clasificación de los datos este módulo junto con algún otro resultara fundamental ya que permite averiguar qué acción acciones llevaron al cliente a reaccionar.
Productos:
En este módulo se distinguen 2 tablas. Ambas almacenan información de productos, los productos y servicios con los que comercializa la empresa. La razón de que haya 2 tablas es para separar la información, meramente descriptiva del producto, esto es, sus características, desde el punto de vista del cliente. Dependiendo de los productos y servicios que venda la empresa dicha tabla podría ser necesario ampliarla o duplicarla de tal manera que una tabla almacena productos o servicios de un tipo y otros productos o servicios de otro tipo. En cambio la tabla Productos almacena información estadística de primera mano relevante y alguna característica necesaria para inferir comportamientos en torno a ese producto.

5.4. Diseño conjunto del sistema

El sistema dispondrá de varios módulos para alcanzar su objetivo:

El módulo de inteligencia recopilará la información de la base de datos, en general del DW y otros almacenes de datos dinámicos para elaborar los árboles de decisión necesarios para el proceso productivo y toma de decisiones.

Este proceso se realizará “offline” dada la gran cantidad de datos almacenados. En producción el flujo de datos será el siguiente:


PIC

Figura 5.2: Interrelación de los módulos del sistema