IMPORTANCIA PARA LA IMPLEMENTACIÓN DE UN DASHBOARD

Integrantes:
Cristopher Yulian Vera Diaz
Luis Miguel Moya

Entregado a :

Fredy Alberto Simanca Herrera

Proyecto de grado
Universidad cooperativa de Colombia
Ingeniería
Ingeniería en sistemas

Bogotá

27/09/2019
 DEFINICION DEL TEMA A TRATAR

A partir de una base de datos de una empresa, generar un Data Warehouse el cual va a
guardar datos de diferentes puntos estratégicos de una empresa.
A partir de estos enfoques se diseñará un dashboard que le provea a los analistas de la
compañía diferentes indicadores y alertas, de diferentes aspectos como ventas, ganancias,
perdidas, etc.
El dashboard servirá para tomar decisiones que optimicen la estrategia de la empresa, pero
no sirve para definir una acción concreta o correcta para realizar estudios en un área
determinada.
El Dashboardse generará con la Suite Pentaho la cual brinda herramientas que ayudaran en
todo el proceso:
1. Pre-procesamiento e integración de datos.
2. Generación y visualización de cubos.
3. Generación de dashboard
La implementación de dashboards en empresas que tengan un gran flujo de información ha
tenido un gran auge en los últimos años, dado la facilidad que brinda para el análisis y toma
de decisiones en áreas críticas para la empresa, existen diversas herramientas en el mercado
para hacer este tipo de implementaciones, no solo la Suite Pentaho que es la herramienta
que en nuestro caso vamos a usar, otra herramienta muy usada es Amazon QuickSight. Esta
herramienta ayuda a las compañías a mejorar su proceso de toma de decisiones a través de
la simplificación de la detección de datos con Amazon QuickSight. Estos socios ayudan a
los clientes de AWS a aprovechar sus datos al máximo mediante la selección de
experiencias completas e iterativas en Amazon QuickSight que ayudan a los usuarios a
identificar fácilmente tendencias, valores atípicos e impulsores comerciales clave.
Algunos casos de éxito de éxito usando QuickSight son:
 AGILISIUM
“Nuestra experiencia en Amazon QuickSight permite a los profesionales obtener
información de manera instantánea y rentable con un resumen fácil de comprender,
en el dispositivo de su preferencia. Con los servicios de Agilisium basados en
Amazon QuickSight, puede conocer mejor sus datos y a sus clientes,”
 Belle Fleur
“Opertivizar datos en información procesable se convirtió en una tarea clave.
Nuestro proceso ágil incluye días de inmersión en AWS para lanzar su piloto o
prueba de concepto de panel y lago de datos , que incluye el uso de Amazon
QuickSight para transformar y analizar datos de manera uniforme con el fin de
obtener información empresarial util”
 JUSTIFICACIÓN
Conocer los datos, analizar las tendencias y fijar líneas de actuación: estos son los
beneficios que ofrece un dashboard de negocios para una empresa. Esta potente
herramienta servirá además para dibujar la estrategia de las diferentes áreas de negocio de
la compañía.
A efectos prácticos un dashboard lograría ayudar a una empresa de la siguiente manera:
 Compartir y monopolizar.
Con el cuadro de mandos se podrá tener toda la información de la compañía
 Decidir el rumbo de la compañía
Gracias a la presentación de KPI’s en gráficos resolutivos y diagramas interactivos,
la toma de decisiones estratégicas de una forma sutil y efectiva será mucho más
sencilla.
 Reaccionar de forma inmediata
Ese acceso en cualquier momento a la medición de los resultados de los KPI’s
permitirá a la empresa reaccionar de forma inmediata a los cambios que se
produzcan en la compañía.
 Tener mayor efectividad
El responsable de la gestión del dashboard de negocios podrá integrar estos datos
en un Excel elaborado y de fácil lectura, que minimiza los tiempos y optimiza la
gestión.
 DESARROLLO ORGANIZADO Y SISTEMATICO DE LA REVISIÓN
BIBLIOGRAFICA

¿QUE ES UN DASHBOARD?
Se entiende por cuadro de mando o Dashboard al sistema de informa de la evolución de
parámetros fundamentales de negocio de una organización o de un área del mismo. Es una
de las posibilidades de “explotar” datos multidimensionales y extraer información valedera
que ayude a la toma de decisiones en los diferentes niveles de la organización.

Los parámetros se miden a partir de:

 Métricas: valores sobre la actividad o resultado del negocio. Ej.: monto de ventas
semanal
 KPI’s (Key performance indicador) : medida del nivel de cumplimiento de un
objetivo. Ej.: velocímetro de indica verde en caso de que se supere el manto de
ventas estimando a la semana-
Formados por :
 Gráficos
 Mapas
 Alertas visuales

¿QUÉ ES UN DATA WAREHOUSE?

Es un repositorio unificado para todos los datos que recogen los diversos sistemas de una
empresa. El repositorio puede ser físico o lógico y hace hincapié en la captura de datos de
diversas fuentes sobre todo para fines analíticos y de acceso.
Normalmente, un data warehouse se aloja en un servidor corporativo a cada vez más, en la
nube. Los datos de diferentes aplicaciones de procesamiento de transacciones online
(OLTP) y otras fuentes se extraen selectivamente para su uso por aplicaciones analíticas y
consultas por usuarios.
Data warehouse es una arquitectura de almacenamiento de datos que permite a los
ejecutivos de negocio organizar, comprender y utilizar sus datos para tomar decisiones
estratégicas. Un data warehouse es una arquitectura conocida ya en muchas empresas
modernas.
¿QUÉ ES UN ETL?
Extract , Transform and Load (extraer , transformar y cargar) es un proceso que permite a
las organizaciones mover datos desde múltiples fuentes, reformatearlos y limpiarlos, y
cargarlos en otra base de dats , data mart , o data warehause para analizar, o en otro sistema
operacional para apoyar un proceso de negocio.
 METODOLOGÍA

La selección de la metodología para el proyecto es de transcendencia, ya que de ella

depende como el proyecto puede optimizar mejor recursos. Partiendo de esta premisa se
elige para llevar cabo el proyecto la “Metodología de Prototipos”.
Metodología de prototipos

Un cliente, a menudo, define un conjunto de objetivos generales para el software, pero no

identifica los requisitos detallados, proceso o salida. En otros casos el responsable del
software puede no estar seguro de la eficacia de un algoritmo, de la capacidad de
adaptación de un sistema operativo o de la forma en que debería tomarse la interacción
hombre-máquina. En estas y en otras muchas situaciones un paradigma de construcción de
prototipos puede ofrecer el mejor enfoque.

El paradigma de construcción de prototipos (figura) comienza con la recolección de

requisitos. El desarrollador y el cliente encuentran y definen los objetivos globales para el
software, identifican los requisitos conocidos y las áreas del esquema en donde es
obligatoria más definición. Entonces aparece un <<diseño rápido>>.
Etapas

 Plan rápido.
 Modelado, diseño rápido
 Construcción del Prototipo
 Desarrollo, entrega y retroalimentación
 Comunicación
 Entrega del desarrollo final

El diseño rápido se centra en una representación de esos aspectos del software que serán
visibles para el usuario/cliente (por ejemplo: enfoques de entrada y formatos de salida). El
diseño rápido lleva a la construcción de un prototipo.

El prototipo lo evalúa el cliente/usuario y se utiliza para refinar los requisitos del software a
desarrollar. La iteración ocurre cuando el prototipo se pone a punto para satisfacer las
necesidades del cliente, permitiendo al mismo tiempo que el desarrollador comprenda
mejor lo que necesita hacer.

Lo ideal sería que el prototipo sirviera como un mecanismo para identificar los requisitos
de software. Si se construye un prototipo de trabajo, el desarrollador intenta hacer uso de
los fragmentos del programa ya existentes o aplica herramientas (por ejemplo: generadores
de informes, gestores de ventanas, etc.) que permiten generar rápidamente programas de
trabajo.

Sin embargo, la construcción de prototipos también puede ser problemática por las
siguientes razones:

1. El cliente ve lo que parece ser una versión de trabajo del software, sin tener en
conocimiento de que el prototipo también está junto con él, sin saber que con la prisa de
hacer que funcione no se ha tenido en cuenta la calidad del software global o la facilidad de
mantenimiento a largo plazo. Cuando se informa de que el producto se debe construir otra
vez ara que se puedan mantener los niveles altos de calidad, el cliente no lo entiende y pide
que se apliquen << unos pequeños ajustes>> para que se pueda hacer del prototipo un
producto final. De forma demasiado frecuente la gestión de desarrollo del software es muy
lenta.
2. En desarrollador, a menudo, hace compromisos de implementación para hacer que el
prototipo funcione rápidamente. Se puede utilizar un sistema operativo o lenguaje de
programación inadecuando simplemente porque está disponible y porque es conocido; un
algoritmo eficiente se puede implementar simplemente para mostrar la capacidad. Después
de algún tiempo, el desarrollador debe familiarizarse con estas selecciones, y olvidarse de
las razones por las que son inadecuadas. La selección menos ideal ahora es una parte
integral del sistema.

Aunque pueden surgir problemas, la construcción de prototipos puede ser un paradigma

efectivo para la ingeniería de software. La clave es definir las reglas del juego al comienzo;
es decir, el cliente y el desarrollador se deben poner de acuerdo en que el prototipo se
construya para servir como un mecanismo de definición de requisitos.

PROTOTIPOS

La creación de prototipos consiste en construir rápida y económicamente un sistema

experimental para que lo evalúen los usuarios finales. Interactuando con el prototipo, los
usuarios pueden darse una mejor idea de sus requerimientos de información. El prototipo
avalado por los usuarios puede servir de plantilla para crear el sistema definitivo.

El prototipo es una versión funcional de un sistema de información o de parte de éste, pero

su propósito es el de servir de modelo preliminar. Una vez en operación, el prototipo se
refinará más aún hasta que cumpla con precisión los requerimientos de los usuarios. Una
vez finalizado el diseño, el prototipo se puede convertir en un sistema en producción
refinado.
 CICLO DE VIDA DEL PROTOTIPO

Etapas para la elaboración del modelo de prototipos

 CARACTERÍSTICAS

El prototipo funcional evolutivo desarrolla un comportamiento que satisface los requisitos y

necesidades que se han entendido claramente. Realiza, por tanto, un proceso real de datos,
para contrastarlo con el usuario.
Se va modificando y desarrollando sobre la marcha, según las apreciaciones del cliente.
Para que la construcción de prototipos sea posible se debe contar con la participación activa
del cliente.
Genera un producto más seguro, en cuanto a la satisfacción de las necesidades del cliente.

Ventajas Desventajas

· Este modelo es útil cuando el cliente · Impropio para sistemas complejos y

conoce los objetivos generales para el grandes
software, pero no identifica los requisitos
· Puede omitir pasos en el análisis, la
detallados de entrada, procesamiento o
documentación y las pruebas.
salida.
· Su principal desventaja es que una vez
· También ofrece un mejor enfoque
que el cliente ha dado su aprobación final
cuando el responsable del desarrollo del
al prototipo y cree que está a punto de
software está inseguro de la eficacia de un
recibir el proyecto final, se encuentra con
algoritmo, de la adaptabilidad de un
que es necesario reescribir buena parte del
sistema operativo o de la forma que
prototipo para hacerlo funcional, porque
debería tomar la interacción humano-
lo más seguro es que el desarrollador
máquina
haya hecho compromisos de
· Se puede reutilizar el código implementación para hacer que el
prototipo funcione rápidamente. Es
posible que el prototipo sea muy lento,
muy grande, no muy amigable en su uso,
o incluso, que esté escrito en un lenguaje
de programación inadecuado.
 IMPLEMENTACIÓN

La implementación fue realizada con la herramienta CDF (Community Dashboard

Framework) de la Suite Pentaho. Dicha herramienta se basa en HTML, CSS y JavaScript
para su funcionamiento.
Se reutilizaron los ejemplos que provee la Suite, tanto de la documentación como de los
ejemplos concretos que provee para poder lograr mostrar los indicadores, todo lo demás es
conocimiento previo de HTML, CSS y JavaScript.
Estructura de CDF

Este framework establece una estructura de archivos necesarios para la ejecución del
dashboard:

a) Un archivo .html de base que debe contener en cierto lugar un parámetro al cual se
lo referencia como {content}. A continuación se muestra el que se definió para éste
trabajo:

A este documento el framework lo llama “estilo”.

b) Una carpeta que contiene los siguiente archivos:

c) Un archivo llamado index.xml el cual brinda los datos necesarios para que se
muestre la carpeta del proyecto en la herramienta Saiku.

i) Un archivo llamado index.properties el cual indica los parámetros para el

archivo anterior:

ii) Un archivo .xcdf el cual tiene un formato .xml que es el que lee la herramienta
Saiku para identificar que se trata de un Dashboard generado con la herramienta
CDF:

iii) En este documento se indica que archivo HTML se va a usar como “template” y
que archivo se va a usar como “estilo”, éste último es el que se mencionó en el
punto a).
iv) Un documento HTML que haga referencia al seleccionado como “template” en
el archivo anterior. Este es el que va a reemplazar el parámetro {content} en el
documento del punto a), insertando todo su contenido en lugar de {content}.
Este archivo básicamente contiene toda la estructura web definida para el
dashboard. Es una opción (como se hizo en este trabajo) agregar tantas hojas de
estilo como sean necesarias para darle forma a la página web resultante.
 v) Otra opción que da este framework, por el hecho de tratarse en definitiva de
programación web (entendiendo ciertas cuestiones específicas del framework),
es la de agregar scripts JS. En este trabajo se utiliza un script para la definición
de los componentes del core de CDF.
Ejemplo de definición de un componente

A continuación, se muestra un ejemplo de definición de un componente en CDF.

a) Como primer paso se debe definir, en algún script en el documento template, una
variable que contenga:
(1) El nombre del objeto del dashboard
(2) El tipo de componente que se quiere utilizar.
(3) El objeto que contiene la definición el componente.
(4) La referencia al id del tag HTML donde se cargara el objeto.

Aquí un ejemplo:

b) La definición del componente. A continuación se muestra la definición

correspondiente al componente que se muestra en el punto (1) :
Como se puede ver en la imagen arriba, se especifican características especiales del
componente como el ancho, el alto, el color de fondo. Al ser un gráfico tipo velocímetro se
puede definir el color de la aguja, de las diferentes marcas, el tamaño de la letra, los colores
a utilizar en los rangos y los mismos rangos que va a mostrar el grafico.
También se debe definir la fuente de los datos, es decir, de donde se va a nutrir el
componente para mostrar los datos. En la mayoría de los casos se puede utilizar la
referencia a un archivo .cda. Este archivo contiene el query y la conexión a la base de datos
que se utilizará. CDF utiliza este mecanismo para evitar ataques a la base de datos; CDF
prohíbe el uso de sql directo desde un Script JS por defecto. Entonces el archivo CDA, el
cual solo se puede acceder desde el servidor, contiene la definición del query, que conexión
se utilizara y define un id para dicha consulta.
En la definición del componente se utiliza el path al archivo CDA y el id de la consulta para
identificar el query que se utilizará para obtener los datos con que se va a cargar el
componente.
 ANÁLISIS Y DISCUSIÓN

En la realización de este dashboard se evidencio el arduo trabajo en horas de desarrollo que

se requiere para interpretar la información que el cliente solicita. Es nuestro deber como
ingenieros facilitar el trabajo de las personas que interpretan esta información con fines más
prácticos.

La información en si misma no significa gran cosa sin un análisis adecuado de la

información, y no solo el análisis sino además un buen uso de la información obtenida para
que tenga gran impacto la elaboración de un dashboard como estos, de lo contrario de
estará tirando al valde muchas horas de programación.