UNIVERSIDAD PERUANA UNIÓN

Escuela de Posgrado
U.P.G. Ingeniería de Sistemas

Una Institución Adventista

METODOLOGÍA OPEN UP EXTENDIDO PARA DESARROLLO DE
PROYECTOS DE BUSINESS INTELLIGENCE

Tesis presentada para optar el grado de Maestría en Ingeniería de
Sistemas con mención en Ingeniería de Software

Autor
Ing. Sergio Omar Valladares Castillo

Lima, Perú
2010

VALLADARES CASTILLO, Sergio Omar. Metodología OpenUP
extendida para desarrollo de proyectos de Business Intelligence.
Tesis (Maestría en Ingeniería de Sistemas con mención en
Ingeniería de Software). Ñaña, Lima: Universidad Peruana Unión,
Unidad de Posgrado de Ingeniería de Sistemas, 2010. 107 p.: 21
cm x 30 cm.

Asesor: Dr. Guillermo Mamani Apaza

INTELIGENCIA DE NEGOCIOS/ METODOLOGÍA OPENUP/
SOFTWARE

ii

Quiero dedicar este trabajo con respeto y
amor a mi padre Delfín Valladares Barrientos
y a mi madre Carmen Castillo Moscoso por
motivarme siempre en seguir adelante

iii

Quiero agradecer en primer lugar a Dios quien
me permite esta oportunidad y me da la sabiduría
necesaria, a mis padres por todo su apoyo y a mi
esposa e hija porque me inspiran en todo momento

iv

INDICE GENERAL

Capítulo

Página

DEDICATORIA.………………………………………………………………….iii
AGRADECIMIENTOS.…..…………………………………………….……….iv
INDICE GENERAL.…….………………………………………………………..v
INDICE DE FIGURAS…………….………………………………..………….vii
INDICE DE TABLAS…………..……………………………………..………..viii
INDICE DE ANEXOS………….……………………………………..…………ix
LISTA DE ABREVIATURAS, SIGLAS Y ACRÓNIMOS…………..…………x
ABSTRACT……………………….……………………………………………..xi
RESUMEN...…………………………………………………………………….xii
I. INTRODUCCIÓN A LA INVESTIGACIÓN ..............................................1
II. FUNDAMENTOS TEÓRICOS ................................................................ 3
2.1 Antecedentes ................................................................................... 3
2.2 Inteligencia de negocios ...................................................................5
2.3 Datawarehouse (DW).......................................................................6
2.4 Metodología para la implementación de BI ......................................9
2.5 Metodología ágil de desarrollo de software OpenUP ..................... 20
III. MÉTODO DE LA INVESTIGACIÓN .................................................... 23
3.1 Tipo de investigación......................................................................23
3.2 Metodología de la investigación. .................................................... 23
3.3 Planificar el proyecto de investigación en base a la metodología
OpenUP adaptada................................................................................ 23
3.4 Diseño de la investigación.............................................................. 24
3.5 Población y muestra....................................................................... 26
v

3.6 Variables e indicadores ..................................................................26
3.7 Técnicas e instrumentos de recolección de datos.......................... 26
IV. DESARROLLO DEL OPENUP PARA BI ............................................ 27
4.1 Decidiendo por OpenUP. ............................................................... 27
4.2 Extendiendo el OpenUP. ................................................................ 29
A) Los roles.................................................................................... 29
B) Entregables ............................................................................... 34
C) Tareas ....................................................................................... 37
D) Fases ........................................................................................ 41
V. VALIDACIÓN Y ANÁLISIS DE LOS RESULTADOS............................ 46
CONCLUSIONES..................................................................................... 59
RECOMENDACIONES ............................................................................ 60
LISTA DE REFERENCIAS ....................................................................... 61
ANEXOS ..................................................................................................66

vi

INDICE DE FIGURAS
Figura

Página

1 - Business Dimensional LifeCycle de Ralp Kimball .................................9
2 – Fases de CRISP-DM ..........................................................................11
3 – Tareas genéricas y salidas del CRISP-DM ........................................12
4 – Esquema del Road Map .....................................................................16
5 – Esquema de las fases del OpenUp ....................................................21
6 – Esquema de la investigación ..............................................................25
7 – Esquema de la fase de concepción del modelo propuesto ................42
8 – Esquema de la fase de elaboración del modelo propuesto ................44
9 – Esquema de la fase de construcción del modelo propuesto ..............45
10 – Resumen comparativo del la evaluación del grado de cumplimiento
de los ítems claves del proyecto de BI ..................................................57

vii

INDICE DE TABLAS
Tabla

Página

1 – Etapas de Datamarting.......................................................................15
2 – Registro general del control de avances por grupos ..........................46
3 – Criterio de evaluación.........................................................................50
4 – Evaluación del grado de cumplimiento de los ítems claves del proyecto
de BI......................................................................................................53

viii

INDICE DE ANEXOS

Anexo

Página

1: Project Charter del proyecto previo considerado para esta investigación.
..............................................................................................................67
2: Plan de proyecto de uno de los grupos que utiliza OpenUp Extendido.
..............................................................................................................71
3: Documento de Visión de uno de los grupos que utiliza OpenUp
Extendido ..............................................................................................77
4: Documento de Requerimientos de uno de los grupos que utiliza
OpenUp Extendido ................................................................................80
5: Plan de iteración de uno de los grupos que utiliza OpenUp Extendido 82
6: Entrevista realizada como parte del rol analista. ..................................83
7: Entrevista realizada como parte del rol analista. ..................................84
8: Documento de Arquitectura de uno de los grupos que utiliza OpenUp
Extendido ..............................................................................................85
9: Documento de Auditoría realizada por el grupo de 4to año a los grupos
de proyecto de BI. .................................................................................96
10: Estructura de una consulta realizada por uno de los grupos del
proyecto de BI. ....................................................................................101
11: Desarrollo con el Pentaho de uno de los grupos……………….…….102
12: OpenUP para BI con el EPF……………………………………………106

ix

LISTA DE ABREVIATURAS, SIGLAS Y ACRÓNIMOS

UP: Unified Process
PU: Productos Unión
PMBOK: Project Management Body Of Knowledge
BI: Business Intelligence
DW: Datawarehouse

Palabras claves: Business Inteligence, Datawarehouse, OpenUP, Unified
Process, Metodología de Software

x

ABSTRACT

This research proposal is to use the OpenUP Software development
methodology to implement a business intelligence solution to this
adaptation is calling OpenUP for BI. The scope of application of this
proposal is in business intelligence projects for small enterprises.
The OpenUP for BI was validated with UPeU systems engineering
students. Research developed into two periods: 2008 and 2009, the teams
2008 business intelligence projects carried out with the traditional model,
instead 2009 teams conducted business intelligence projects applying the
OpenUP for BI. Students attending the 2009 should be requirement having
participated in projects of development of software methodology OpenUP.
The model was applied in industry bakery Productos Unión (PU), the
requirements were validated by users in a previous project. The
deliverables produced by the students were validated on the users in the
previous project approvals. Internal processes on the implementation of
the OpenUP for BI were validated on progress controls as part of the
corresponding course. The final results of the 2009 period are contrasted
with the results obtained by the period 2008 teams.
On the OpenUP for BI achieved an important understanding of the
processes and sequence for the project, also helped on the project for the
implementation of the OpenUP's own formats, was also efficient work due
to the proper implementation of the involved roles, we have a good control
time based on adequate control of tasks and quality with regard to control
of changes under an incremental iterative process.

xi

RESUMEN

La propuesta de esta investigación es de poder utilizar la metodología de
desarrollo de Software OpenUP para implementar una solución de
Inteligencia de Negocios, a esta adecuación se le está llamando OpenUP
para BI. El alcance de la aplicación de esta propuesta es en proyectos de
Inteligencia de negocios para Pymes.
El OpenUP para BI se validó a través de los alumnos de Ingeniería de
Sistemas de la UPeU. La investigación se desarrolló en dos periodos:
2008 y 2009, los equipos del 2008 realizaron proyectos de Inteligencia de
Negocios con el modelo tradicional, en cambio los equipos del 2009
realizaron proyectos de Inteligencia de Negocios aplicando el OpenUP
para BI. Los alumnos que participaron el 2009 debían tener como
requisito el haber participado en proyectos de desarrollo de Software con
la metodología OpenUP.
Se aplicó el modelo en la industria panificadora de Producto Unión (PU),
los requerimientos fueron validados por los usuarios en un proyecto
previo. Los entregables producidos por los alumnos fueron validados en
base a las aprobaciones de los usuarios en el proyecto previo. Los
procesos internos sobre el cumplimiento del OpenUP para BI se validaron
a través

de

los controles de

avances como parte del

curso

correspondiente. Los resultados finales del periodo 2009 se contrastaron
con los resultados obtenidos por los equipos del periodo del 2008.
A través del OpenUP para BI se logró un entendimiento importante de los
procesos y secuencia de trabajo para el proyecto, ayudó también en el
proyecto por la aplicación de los formatos propios del OpenUP, se logró
además un trabajo eficiente debido a la ejecución adecuada de los roles
involucrados, se aprovecho el tiempo en base a un control adecuado de
las tareas y la calidad con respecto al control de los cambios bajo un
proceso iterativo incremental.
xii

CAPÍTULO I
INTRODUCCIÓN A LA INVESTIGACIÓN
En base a la realidad en el Perú, debido a la demanda en el mercado, las
empresas solicitan proyectos de implementación de Inteligencia de
Negocios (BI) a las consultoras que normalmente se dedican al desarrollo
de Software, tales consultoras destinan personal para tales proyectos de
BI. En tales circunstancias el personal designado para ese proyecto de BI
necesita capacitarse en tecnología, herramientas y metodologías
correspondientes a BI, existe una gran similitud entre la implementación
de BI con la forma de desarrollar e implementar un Software, la cual sirvió
de patrón para entender la forma de cómo trabajar con la tecnología
nueva de BI.
La metodología para desarrollar esta investigación fue la siguiente:
desarrollar un prototipo de BI para la industria panificadora de Productos
Unión (PU) con la finalidad de validar los requerimientos y obtener la
aceptación del usuario con respecto a los entregables. También
desarrollar proyectos de BI a través de alumnos de la Escuela de
Ingeniería de Sistemas en su respectivo curso, aplicando el modelo
tradicional Business Dimensional LifeCycle (BDLC) de Ralph Kimball. Una
vez que se tiene la información y validación necesaria por PU e
información generada en base a la ejecución del modelo tradicional
BDLC, se procedió a validar el OpenUP para BI a través de su ejecución
por parte de los alumnos de la escuela de Ingeniería de Sistemas, un año
después, quienes llevarán los temas de BI en su respectivo curso y tienen
ya una base en la aplicación de la metodología OpenUP en algún cursos
previamente, este punto es clave debido a la similitud en el contexto en
que se propone la investigación.
Seguidamente se procedió a validar los resultados obtenidos, en primer
lugar el cumplimiento de los entregables y procesos de acuerdo al modelo
1

propuesto y en segundo lugar los resultados obtenidos con los resultados
de los proyectos previos.
El OpenUP para BI será de utilidad:

En aquellas empresas que están empezando en proyectos de
implementación de BI para Pymes.

Aquellas empresas que tienen mayor conocimiento en proyectos de BI
y ven conveniente seguir utilizando el OpenUP para BI propuesto en
esta investigación.

Como parte de los temas en los cursos a nivel universitario
relacionados a BI o con metodología OpenUP.

En el presente documento se está considerando en el capítulo II el
fundamento teórico necesario para comprender el tema de investigación.
En el capítulo III se explica la modalidad en que se enmarca esta
investigación así como los procesos que se seguirían. En el capítulo IV se
describe la propuesta la investigación, se considera la extensión
adecuada del OpenUP con respecto a los roles, entregables, tareas,
procesos de las fases. En el capítulo V se describe la validación del
OpenUP para BI y el análisis correspondiente de los resultados. En el
Capítulo VI explicamos las conclusiones y recomendaciones en base a los
resultados de la investigación. Como producto complementario a la
investigación en los anexos se muestra el OpenUP para BI utilizando el
plugin del EPF que permite modificar el OpenUP, la cual dicho plugin
ayudó a mejorar la propuesta descrita en el capítulo IV.

2

CAPÍTULO II
FUNDAMENTOS TEÓRICOS

2.1 Antecedentes
a) Consultoría en software y T.I.
Las empresas en el Perú siempre han solicitado servicios de las
consultoras para el desarrollo de software en el Perú, especialmente las
consultoras que se consideran Partners de empresas grande proveedoras
de T.I. tales como Oracle, Microsoft, IBM, entre otras. Tales consultoras
aprovechando el respaldo y productos licenciados que ofrecen dichas
empresas grandes proveedoras de T.I. se centran en soluciones
empresariales cada vez más especializadas (PACIS 2007).
Tales consultoras deben expandir la gama de servicios para poder
abarcar los diversos productos que ofrece su principal Partner tales como
CRM, ERP, Inteligencia de Negocios, BSC, entre otros productos. Es de
este modo ante la necesidad de las empresas del uso de esta tecnología
especializada solicitan el servicios, y tales consultoras que normalmente
ofrecen el servicio de desarrollo de software ahora deben de involucrarse
en proyectos de nueva tecnología en un corto tiempo para no perder la
oportunidad de expandir su negocio, debido a la rapidez de la formulación
del proyecto de una implementación de BI por ejemplo, se basan en su
forma acostumbrada de desarrollar software. A pesar que los procesos de
desarrollo de software tampoco está bien definido en la mayoría de estas
consultoras, la tendencia es hacia un desarrollo iterativo-incremental y
dividido por fases, esto es por enseñanza recibida desde los centros de
estudios de donde provienen los expertos de las consultoras.
La realidad, en su mayoría, de las consultoras en el Perú es que a pesar
de ser especialistas en desarrollo de software así como de los demás
servicios en T.I. aplicados a procesos de grandes negocios, aun no
alcanzan la calidad necesaria para ser competitivos internacionalmente,
3

especialmente en el tema de procesos de desarrollo y/o implementación,
es por eso que en la actualidad el estado promoviendo el modelo del
CMMI para el desarrollo de Software a través del PACIS (PACIS 2007).
b) Productos Unión.
Productos Unión (PU) fue creado en 1919 como Centro de Aplicación del
Colegio Unión (hoy Universidad Peruana Unión). En la actualidad PU es
la principal actividad de autosostenimiento de muchos estudiantes que
pasan por las aulas unionistas. El sistema actual no cubre todas las áreas
necesarias de PU y además sus datos no son confiables,

existe

redundancia de los datos, la estructura de la mayoría de sus tablas no
permite relacionarse e incluso existe datos innecesarios por registro que
ocupan demasiado espacio. Es necesaria muchas veces la intervención
directa en la base de datos del personal de sistema de PU para poder
depurar la data y presentar reportes a las gerencias de PU, ocasionando
utilizar el tiempo en trabajos adicionales en búsqueda, corrección y
presentación de la información a la gerencia (Analista funcional de PU
2007).
Existe en el Perú un aproximado de 28 empresas, nacionales e
internacionales, casi con el mismo rubro de PU de las cuales el Grupo
BIMBO utiliza sistemas de información automatizados tanto a nivel
operativo como gerencial que le permite competir y crecer a nivel mundial.
Desde el año 2005 cuentan con una solución de negocio integrada por un
sistema de tipo ERP (Enterprise Resource Planning), también el 2005
implementaron una solución para el área de ventas usando tecnología de
Inteligencia de Negocios (BI) y Datawarehouse (DW). Para competir con
estas empresas PU debe invertir en tecnología para poder crecer y
conservarse en el mercado (Grupo Bimbo 2007).
Herrera (2007) dice que en la actualidad se encuentran el modelo Gold y
YAM2 para diseñar almacenes de datos basados en UML, pero estos
modelos se quedan en la parte académica, y no se han implementado en
4

estos momentos por parte de los fabricantes de software, un ejemplo de
lo anterior es el modelo GOLD se encuentra en versión 1.4 UML y no se
ha rediseñado hacia el estándar actual. El cual permite realizar más
diagramas y posible extensiones hacia el desarrollo de una herramienta
en código abierto para el desarrollo de bodegas de datos, En el
componente de ETL se encuentra modelos básico pero no estandarizados
al igual que en la proceso de minería de datos.

2.2 Inteligencia de negocios
Fernández (2004) dice que en la empresa actual se da cada vez más
importancia al control de gestión. Los recursos son escasos, los procesos
son complejos, y cada vez es más crítica la información que se requiere
para una correcta toma de decisiones. Por ello, son primordiales las
herramientas de apoyo a la toma de decisiones, entre los que se
encuentra el Business Intelligence y el cuadro de mando (tanto por áreas
como integral) que ayude a los directivos en este sentido.
EL Business Intelligence promete:
 Análisis de la misma información en el 10% del tiempo
 Minimización de los costes de oportunidad por anticipar decisiones de
meses a semanas o de semanas a días
 Ejecutivos sin formación informática realizan complicadas consultas a
las bases de datos en segundos
 Reducción de costes del departamento de Tecnologías de la
Información-Informática
 Reducción de costes horas-hombre-ejecutivo
Business Intelligence ofrece a las organizaciones un marco para analizar
la gran cantidad diaria de datos a fin de extraer valoraciones que puedan
proporcionar una ventaja decisiva en la competitiva economía actual.

5

Business Intelligence es un set de tecnologías que van desde
arquitecturas para almacenar datos, metodologías, técnicas para analizar
información y software entre otros, con un fin común para el apoyo a la
toma de decisiones.
2.3 Datawarehouse (DW)
Concepto
Existen muchas definiciones para el DW, la más conocida fue propuesta
por Inmon (considerado el padre de las Bases de Datos) en 1992: “Un
DW es una colección de datos orientados a temas, integrados, novolátiles y variante en el tiempo, organizados para soportar necesidades
empresariales”. En 1993, Susan Osterfeldt publica una definición que sin
duda acierta en la clave del DW: “Yo considero al DW como algo que
provee dos beneficios empresariales reales: Integración y Acceso de
datos. DW elimina una gran cantidad de datos inútiles y no deseados,
como también el procesamiento desde el ambiente operacional clásico”.
(Oracle University 1999).
El Datawarehouse, es actualmente, el centro de atención de las grandes
instituciones, porque provee un ambiente para que las organizaciones
hagan un mejor uso de la información que está siendo administrada por
diversas aplicaciones operacionales (SQLMax 2001).
En primer lugar, DW no es un producto que pueda ser comprado en el
mercado, sino más bien un concepto que debe ser construido. DW es una
combinación de conceptos y tecnología que cambian significativamente la
manera en que es entregada la información a la gente de negocios. El
objetivo principal es satisfacer los requerimientos de información internos
de la empresa para una mejor gestión, con eficiencia y facilidad de acceso
(Gloria 2002).

Características.
Oracle University (1999) menciona 4 características:
6

Orientado a temas
Una primera característica del Datawarehouse es que la información
se clasifica en base a los aspectos que son de interés para la
empresa.
En el ambiente Datawarehousing se organiza alrededor de sujetos
tales como cliente, vendedor, producto y actividad. Por ejemplo, para
un fabricante, éstos pueden ser clientes, productos, proveedores y
vendedores. Para una universidad pueden ser estudiantes, clases y
profesores. Para un hospital pueden ser pacientes, personal médico,
medicamentos, etc.

Integración
En muchas organizaciones la data reside en diversos sistemas
independientes. Haciendo dificultoso la integración de los datos para
el análisis. Para el Datawarehouse la data está completamente
integrada.

De tiempo variante
Como la información en el Datawarehouse es solicitada en cualquier
momento (es decir, no "ahora mismo"), los datos encontrados en el
depósito se llaman de "tiempo variante". Los datos históricos son de
poco uso en el procesamiento operacional. La información del
depósito por el contraste, debe incluir los datos históricos para usarse
en la identificación y evaluación de tendencias.

No volátil
Los datos en el Datawarehouse son de solo lectura. Los datos son
cargados inicialmente y luego refrescados regularmente

Estructura
Gloria (2002) menciona que la estructura básica de la arquitectura DW
incluye:

7

A. Datos operacionales: un origen de datos para el componente de
almacenamiento físico DW.
B. Extracción de Datos: selección sistemática de datos operacionales
usados para poblar el componente de almacenamiento físico DW.
C. Transformación de datos: Procesos para sumarizar y realizar otros
cambios en los datos operacionales para reunir los objetivos de
orientación a temas e integración principalmente.
D. Carga de Datos: inserción sistemática de datos en el componente de
almacenamiento físico DW.
E. Datawarehouse: almacenamiento físico de datos de la arquitectura
DW.
F. Herramientas de Acceso al componente de almacenamiento físico
DW: herramientas que proveen acceso a los datos.
Oracle University (1999) menciona 3 componentes:

Fuentes de Datos, provienen de sistemas no relacionados, base de
datos relacional, datos externos de distintos formatos y archivos
planos.

Los Datos, pueden ser de una gran variedad tales como datos
relacionados, imágenes, textos, espaciales, audio, video y Web.

Acceso a los datos, los datos son utilizados por diversos propósitos y
de distintos formatos a la vez. Para ello se necesita de programas
especiales para su utilización.

Flujo de datos a través del warehouse
El dato es extraído desde las fuentes, transformados de acuerdo a la
necesidad y entonces transportado al apropiado lugar dentro del almacén
de datos.
Diferentes tipos de datos facilitan las operaciones del Data Warehouse.
Datos que se necesitan depurar provienen del más bajo nivel, cargados
usando el proceso ETL. Los datos en un nivel de resumen es asignado a
8

los datos cargados la cual facilitan el análisis. La Metadata provee la
información o estructura de cómo está conformado el Data Warehouse,
incluyendo un específico detalle con respecto a los datos.
Existen herramientas que acceden al dato del Warehouse para soportar
análisis y otras consultas (Oracle 1999).
2.4 Metodología para la implementación de BI
A. Ciclo de vida dimensional del negocio de Ralph Kimball
Kimball University (2009) explica que el Business Dimensional
LifeCycle (BDLC) propone, tal como se muestra en la figura 1,
empezar el proyecto con una buena planificación que abarca desde la
obtención

de

los

requerimientos

e

información

hasta

las

consideraciones de mejora y crecimiento de la primera versión del BI
implementado. Cuando el proyecto es aprobado, el plan del proyecto
es la guía para la ejecución y control de la implementación del BI.

Figura 1 - Business Dimensional LifeCycle de Ralp Kimball
(Kimball University 2009)

9

Un proceso importante es la captura de los requerimientos del
negocio. Es en este proceso donde se debe validar los requerimientos
con la factibilidad de información y/o datos que tiene la empresa. Se
debe entender al detalle los requerimientos por todo el equipo del
proyecto.
Después que el equipo del proyecto es consciente del alcance del
proyecto es posible trabajar en dos grandes grupos, el primero se
encarga de la parte tecnológica de Hardware y Software necesarios
para el optimo funcionamiento de BI en la empresa, el segundo grupo
se encarga en representar los requerimientos en modelos de BD, DW,
modelos dimensionales, BD intermedia, procesos de ETL, en otros; y
el tercer grupo las interfaces gráficas de los reportes, cuadros
estadísticos para que desde un comienzo el usuario final tenga noción
de la presentación de sus requerimientos, así como la ejecución de la
aplicación por el motor de BI generado por este último grupo.
Una vez que se tiene previa aceptación por parte del usuario, se
procede a implementarlo y probarlo en entornos reales, especialmente
en la Arquitectura de Hardware en el área de producción de la
empresa hasta lograr la aprobación final por el usuario.
Se considera además toda una etapa de mantenimiento para el buen
funcionamiento de la aplicación así como control e implementación del
crecimiento de la data y/o requerimientos del negocio la cual requiere
empezar con un nuevo proyecto desde su planificación, siendo de
este modo todo un ciclo de implementación de esta tecnología.

B. Cross Industry Standard Process for Data Mining.
El Cross Industry Standard Process for Data Mining (CRISP-DM) fue
concebido gracias a un consorcio de tres organizaciones industriales
del joven e inmaduro mercado de minería de datos a finales de 1996.
10

La metodología de CRISP-DM está descrita en términos de un modelo
de proceso jerárquico, consistente en un conjunto de tareas descritas
en cuatro niveles de abstracción (de lo general a lo específico): fase,
tarea genérica, tarea especializada, e instancia de procesos (CRISPDM consortium 2000).
CRISP-DM consortium (2000), tal como se muestra en la figura 2,
especialmente enfatiza la validación de los requerimientos con los
datos existentes en la empresa, es necesario entender la razón de la
existencia de los datos y su relación entre ellos, se considera los
datos almacenados en reportes impresos, datos en hojas de cálculos
o en digital, la cual es necesario ver la redundancia y relación entre
los distintos medios de almacenamiento de estos datos. También se
debe considerar la calidad de los datos, la confianza en el valor de los
datos y su relevancia para los requerimientos.

Figura 2 – Fases de CRISP-DM
(CRISP-DM consortium 2000)

11

Figura 3 – Tareas genéricas y salidas del CRISP-DM
(CRISP-DM consortium 2000)

12

En la figura 3 se muestra las tareas genéricas por cada proceso del
CRISP-DM. Si bien esta metodología se centra en los procesos para
generar los algoritmos de Datamining, considera sus procesos desde la
obtención de los requerimientos.
Se enfatiza un análisis profundo en la reestructuración, depuramiento,
sumarización y formato de los datos para considerarlos dentro de la lógica
del proceso ETL.
C. Hefesto
Bernabeu (2009) propone lo siguiente:
 Fácil distinción y comprensión de objetivos en cada fase.
 Se basa en el usuario, siendo fácil y rápida su adaptabilidad a
cambios en el negocio.
 Involucra

al

usuario

final,

tomando

decisiones

sobre

comportamiento y funciones del DW.
 Usa modelos conceptuales y lógicos sencillos de analizar e
interpretar.
 Independiente de las herramientas usadas en la implementación.
 Independiente del ciclo de vida en el que es empleada.
 Independientes de las estructuras físicas que contiene el DW y su
distribución.
 Aplicada tanto a DM como DW.
 Los datos obtenidos de cada fase con el punto de partida de la fase
siguiente.
Pasos y Aplicación:
a) Análisis de los requerimientos.
Hefesto se preocupa de la obtención de requerimientos y termina
con su representación en un modelo conceptual que es una
representación de alto nivel entendido por los usuarios de la
empresa. Hefesto en este paso detalla lo siguiente:
13

a) Identificar preguntas.
b) Identificar indicadores y perspectiva de análisis.
c) Modelo conceptual.
Bernabeu (2009) enfatiza la realización de cuestionarios adecuados
para que al momento de la entrevista se obtengan mejor calidad en
la respuesta de los usuarios. Desde este paso se tiene una idea
general representada en un modelo conceptual la relación de la
información involucrada según requerimientos.
b) Análisis de los OLTP.
Hefesto también representa el proceso principal de análisis, es en
este paso donde se debe establecer los indicadores considerando su
nivel de granularidad. Hefesto en este paso detalla lo siguiente:
a) Determinación de los indicadores.
b) Establecer correspondencias.
c) Nivel de granularidad.
d) Modelo conceptual ampliado.
Bernabeu (2009) propone en este segundo paso mejorar el modelo
conceptual, dando al esquema un formato dimensional donde se
resaltan los indicadores, datos importantes y el nivel de detalle de
los indicadores (granularidad) así como la relación de la información
involucrada según requerimientos como su relación con la data
existente.
c) Modelo Lógico del DW.
Hefesto en este paso considera la representación de los indicadores
y requerimientos en los modelos propios de una solución de
inteligencia de negocios. En este paso se detalla lo siguiente:
a) Tipo de modelo lógico del DW.
14

b) Tablas de dimensiones.
c) Tabla de hechos.
d) Uniones.
Bernabeu (2009) se centra en este paso en el DW, el repositorio
físico de los datos, sus relaciones de integridad así como su
crecimiento como segmento en el servidor correspondiente.

D. DATAMARTING
Arson Group (2005) propone la metodología Datamarting que asegura
realizar un proyecto de BI en forma sencilla y bien documentada a
través de 4 etapas mostrado en la tabla 1:
 4 etapas
Tabla 1 – Etapas del Datamarting (Arson Group 2005)
ETAPA
Planificación

OBJETIVO PRINCIPAL

PRINCIPALES TÉCNICAS

Preparación del plan de
actividades por etapas,
gestionando los recursos

 Dimensionamiento de
proyectos.
 Métricas de control.

Prepara el modelo
multidimensional y las
especificaciones de carga de
datos




Desarrollo

Realizar los procesos de carga
de datos de todo el modelo e
implementación en la
herramienta OLAP

 Incremental Update for BI.
 Reciclaje de errores.
 Almacenamiento por uso de
información

Implementación

Entrenar a los usuarios para
institucionalizar el proyecto de
BI

 Why five.
 Capacitación por capacidades

Análisis

Six Question.
Análisis de granularidad.
Relaciones dinámicas.
Versioning

 6 documentos
 3 métricas de control (Conforme al ISO/IEC 14143-1:1998)
 4 mejores prácticas alineadas al modelo de CMMI.

15

 10 pasos para la implementación del Datamarting enfocado al
usuario:
1. Identificar los temas de análisis.
2. Identificar las dimensiones de navegación.
3. Elaboración del Modelo Multidimensional Básico.
4. Elaboración del Modelo Multidimensional Complejo.
5. Elaboración de las especificaciones de carga de datos.
6. Creación de Base de Datos.
7. Construcción de la Arquitectura del Datamart.
8. ETL.
9. Implementación.
10. Capacitación al Usuario.

E. ROAD MAP
En la figura 4, se muestra el esquema general del Road Map. Se
evidencia en esta representación una similitud con las fases de
desarrollo de software.

Figura 4 – Esquema del Road Map (PESG 2000)

16

PESG (2000) considera una estructura similar al desarrollo tradicional
del Software. Considera además la justificación correcta del proyecto
de BI así como la capacidad de la empresa de explotar y manejar la
aplicación de BI como corresponde. También considera la muestra de
prototipos

como

interfaces

gráficas,

reportes

para

el

mejor

entendimiento del equipo de trabajo así como el de los usuarios.
Larissa Moss (2004) describe la existencia de tres rutas dentro del BI
Roadmap, Cada ruta tiene un desarrollo específico que contribuye al
los objetivos del proyecto de BI:

La ruta ETL entregará la base de dato cargada.

La pista de aplicación entrega los informes, consultas y
herramientas ad hoc.

El repositorio de metadatos entregará los metadatos.

Cada ruta se mueve a través de las seis etapas del BI Roadmap ya
sean juntos o por separado y en paralelo, realizando las actividades
de ingeniería en sus medidas concretas.
Larissa Moss (2004) justifica que a medida que el entorno de BI se
convierte en un entorno de decisión complicada como apoyo de toda
la Organización en el tiempo, es esencial que exista una base sólida
para

soportar

tal

expansión. Muchas

cosas

tienen

que

ser

considerados y muchas tareas deben ser realizadas por muchas
personas para construir los sólidos cimientos.
La cuestión no es si una metodología debe ser utilizada, sino más
bien qué tipo de metodología se debe utilizar y cómo utilizarlos con
mayor eficacia. Una metodología de cascada tradicional no es
adecuada para el concepto interactivo de liberación de las
aplicaciones de BI, el BI Roadmap si lo es.

17

F. SCRUM PARA BI
Gravitar (2007) menciona que existen numerosas propuestas de
metodología. Tradicionalmente estas metodologías se centran en el
control del proceso, estableciendo rigurosamente las actividades,
herramientas y notaciones al respecto, dado estas reglas estas
metodologías se caracterizan por ser rígidos y dirigidos por la
documentación que se genera en cada una de las actividades
desarrolladas.
Este enfoque no resulta ser el más adecuado para muchos de los
proyectos actuales donde el entorno del sistema es muy cambiante, y
en donde se exige reducir drásticamente los tiempos de desarrollo
pero manteniendo una alta calidad.
Por definiciones propias del SCRUM resumimos que es una
metodología ágil de desarrollo de proyectos, que requiere trabajo
duro porque no se basa en el seguimiento de un plan, sino en
la adaptación continua a las circunstancias de la evolución del
proyecto.
Dos características más destacables son:

Se acepta de entrada que los requerimientos son por definición
cambiantes, y por lo tanto se evitan muchas discusiones
estériles. Los usuarios pueden cambiar de idea sobre lo que
quieren y necesitan.

Entrega frecuente y progresiva de resultados, por lo que en
todo momento se tiene una visión clara de la evolución del
proyecto.

Esta metodología se emplea en entornos que trabajan con requisitos
inestables y que requieren rapidez y flexibilidad (situaciones
frecuentes en el desarrollo de software, etc. y en los proyectos de BI).

18

Al iniciar el proyecto se crea el "listado de funcionalidades", que es un
listado actualizado, incompleto y priorizado de los requerimientos del
proyecto-producto.
El "cliente" es el encargado de mantener este "listado de
funcionalidades" actualizado y priorizado.
La idea básica es que el desarrollo se hace de manera cíclica e
incremental. En cada "ciclo de desarrollo" (sprint), el "equipo de
desarrollo" selecciona el subconjunto de funcionalidades (sprint
backlog) que se incorporarán al producto, y durante el siguiente ciclo
se centrarán únicamente en completar esas funcionalidades y
entregárselas al cliente. Los equipos son pequeños (máximo 8 u 9
personas) pero experimentados. Los ciclos de desarrollo son cortos
(entre 3 y 5 semanas), por lo que se tiene una buena visibilidad sobre
el avance del proyecto.
El "jefe de proyecto" se encarga de ayudar al equipo en sus
necesidades y evitar distracciones inútiles. No ejerce exactamente de
jefe (ya que es el propio equipo de desarrollo el que selecciona,
estima y gestiona su tiempo, y se hace responsable del diseño, de la
implantación, y del resultado). El equipo de desarrollo tiene una gran
autonomía.
G. Extreme Programming (XP) PARA BI
Como parte de una investigación, la Universidad EAFIT (2006)
muestras ciertas características del XP como una opción para
proyectos de BI. Algunas de las características son:

Metodología genérica, aplicable a múltiples plataformas.

Es posible, aunque se enfoca a líneas de negocios específicas,
que permita un análisis del negocio que sea transversal a toda
la organización.

19

Posibilita el acoplamiento de nuevas tecnologías con cada
proyecto que se desarrolle.

Tiene etapas completamente detalladas, que sumándolas den
como resultado la completitud del proyecto de inteligencia de
negocios, a pesar que XP no es específica para BI.

Dice claramente los roles que intervienen en cada actividad y
que entregables se obtienen de ésta.

Permite el crecimiento futuro de las aplicaciones que se
desarrollen con dicha metodología.

Tiene productos definidos por cada etapa o actividad.

Trabaja con arquitectura orientadas a beses de datos
multidimensionales a pesar que no está hecho con ese
objetivo.

La investigación realizada por la Universidad EAFIT (2006) muestra varias
posibilidades del XP para proyectos de BI pero la descarta porque
reconoce que debe ser modificada. Dicha investigación prefiere adaptar la
metodología para implementar BI de la empresa Method Focus (BI ROAD MAP) a una empresa de desarrollo de software Avansoft debido a
que sus procesos son muy similares y además tales empresas ya cuentan
con procesos muy definidos.
2.5 Metodología ágil de desarrollo de software OpenUP
OpenUP se apoya en el proceso Unificado (UP) que aplica enfoques de
iterativo e incremental en un ciclo de vida estructurado. OpenUP abarca
una filosofía ágil que se centra en la naturaleza de colaboración de
desarrollo de software. Es una herramienta que no se amarra a una
tecnología en particular, baja ceremonia (poca documentación) que se
puede ampliar para hacer frente a una amplia variedad de tipos de
proyectos. En la figura 5 se representa las fases que considera esta
20

metodología incluyendo una representación de iteraciones e hitos
principales.

Figura 5 – Esquema de las fases del OpenUP
(Eclipse 2007)
OpenUP es para equipos pequeños que trabajan juntos en el mismo
lugar. Los miembros del equipo incluyen a los actores, promotores,
arquitectos, director del proyecto, y al equipo de pruebas (calidad). Ellos
hacen sus propias decisiones sobre lo que necesitan para trabajar, cuáles
son las prioridades, y la mejor manera de atender las necesidades de los
interesados. La organización debe apoyar al equipo por lo que les permite
estas responsabilidades.
OpenUP se centra en reducir significativamente el riesgo a principios del
ciclo de vida. Esto requiere reuniones periódicas de revisión de riesgos y
la aplicación rigurosa de las estrategias de mitigación.
Los casos de uso se utilizan para obtener y describir los requisitos, por lo
tanto, los miembros del equipo necesitan desarrollar destrezas en la
representación

de

los

casos

uso. Las

partes

interesadas

son

responsables de revisar y certificar que los requisitos son correctos. Los
casos de uso son desarrollados en colaboración.
Arquitectónicamente requisitos importantes deben ser identificados y
establecidos desde la fase de elaboración a fin de que una arquitectura
robusta puede ser creada como el núcleo del sistema. El riesgo de que
21

ocurran cambios en la Arquitectura se debe reducir significativamente en
las iteraciones de la fase de Elaboración.
La prueba se realiza varias veces por iteración, cada vez que la solución
se incrementa con el desarrollo de un requisito, el cambio o corrección de
errores debe ser considerado. Estas pruebas suceden después de que los
desarrolladores han desarrollado la solución (que debería haber sido
sometidos a pruebas por unidad) e integrarlo en el código base. Estas
pruebas ayudan a garantizar que una versión estable es creada y siempre
disponible como progreso del desarrollo.
OpenUP es un iterativo proceso distribuidos en cuatro fases: creación,
elaboración, construcción y transición. Cada fase consta de una o más
iteraciones, con la finalización de cada iteración representan un hito de
menor importancia para el proyecto y contribuye a la consecución de los
hitos más importantes de la fase, donde los objetivos de la fase deben ser
cumplidos (Eclipse 2007).

22

CAPÍTULO III
MÉTODO DE LA INVESTIGACIÓN

3.1 Tipo de investigación.
El tipo de investigación es evaluativo y propositiva, pues se hace una
evaluación del la metodología de desarrollo de software OpenUP para
proyectos de BI y es propositiva ya se propone una metodología
extendida para proyectos de Inteligencia de Negocios.
3.2 Metodología de la investigación.
El método de investigación es pre experimental de corte longitudinal, pues
se aplica la metodología de desarrollo de software OpenUP para el
desarrollo de proyectos de BI y se evalúa la eficiencia de la metodología
durante un periodo académico.
3.3 Planificar el proyecto de investigación en base a la metodología
OpenUP adaptada.
3.3.1 Ejecución del proyecto previo.
Se considera este punto con la intensión de agilizar la captura de
los requerimientos de la empresa

y disponer de los datos

necesarios para que los equipos puedan trabajar sin restricciones.
Además, de lograr una previa aceptación de los usuarios en base
al prototipo presentado.
3.3.2 Afinamiento de la metodología OpenUP.
En base a la experiencia previa, previo análisis, se realizan todos
los cambios necesarios a considerar en la metodología OpenUP de
tal modo que sea entendible y aplicable por los equipos de
proyectos.
3.3.3 Diseño del modelo adaptado
En este ítem se considera el diseño del modelo de OpenUP
adaptado a proyectos de BI.
23

3.3.4 Preparación y alineamiento de los equipos de proyecto.
Se considera dos etapas, la primera es la formación de equipos
que implementarán el BI en base al modelo de Kimball y con los
datos obtenidos en el proyecto previo.
La segunda etapa es la formación de equipos que implementarán
el BI en base a la metodología OpenUP adaptada para BI con los
mismos datos obtenidos en el proyecto previo.
3.3.5 Aplicación del modelo propuesto.
Considerando al equipo de proyecto de BI de la segunda etapa,
implementarán el BI en base a las directivas respectivas basadas
en el modelo propuesto.
3.3.6 Análisis de los resultados en base a los modelos ejecutados.
En base a la información obtenida y en base a experiencias
pasadas, se procederá a evaluar el resultado del trabajo de
equipos de implementación de BI basados en el modelo tradicional
de Kimball con equipos de implementación de BI basados en el
OpenUP para BI.
3.4 Diseño de la investigación.
El esquema de la investigación se presenta a continuación:
Ge: O1--------X
Gc: O2--------Y
Ge: Equipos de trabajos que aplicaron el OpenUP para BI.
Gc: Equipos de trabajos que no aplicaron el OpenUP para BI.
O1: Proyectos de BI en la cual se ha aplicado la metodología OpenUP
para BI.
O2: Proyectos de BI en la cual no se ha aplicado la metodología OpenUP
para BI.
X: Metodología OpenUP para BI para desarrollo de Proyectos de BI
Y: Metodología tradicional para desarrollo de proyectos de BI
24

En la figura 6 se muestra el esquema de la investigación. Se considera un
proceso de “Proyecto previo de BI” con la finalidad de obtener la
aprobación de la empresa PU quien nos ayuda con esta investigación. Se
representa

además

la

ejecución

en

paralelo

de

los

proyectos

experimentales por un lado los que no aplican la metodología OpenUP
para BI y por otro lado los proyectos que si lo aplican. El proceso final es
para analizar los resultados obtenidos por la ejecución de los proyectos
experimentales.
INICIO

PROYECTO PREVIO DE
BI

REQUERIMIENTOS
Y BASE DE DATOS

CAPACITACIÓN
PREVIA

AFINAMIENTO
OPENUP CON BI

PROYECTO BI

CAPACITACIÓN
PREVIA DE OPENUP
PARA BI
PROYECTO BI CON
OPENUP PARA BI

ANALISIS DE
RESULTADOS

FIN

Figura 6 – Esquema de la investigación
25

3.5 Población y muestra
La población está conformada por todo los equipos de trabajo del
quinto año de sistemas del curso de BI.
La muestra es censal, pues

se trabajo con todos los equipos

conformados por alumnos del 5to año de Sistemas de la UPeU que
deben cumplir como prerrequisito la experiencia de trabajos de ciclo
en desarrollo de software siguiendo una metodología de software
basados en UP y llevar el curso de Inteligencia de Negocios (DBAIII),
la intención es monitorear el comportamiento, rendimiento y
efectividad de cada equipo de proyecto en el cumplimiento del
modelo.
3.6 Variables e indicadores
a. Variable independiente.
Modelo de implementación de BI basados en la Metodología de
desarrollo de software OpenUP (OpenUP para BI).
Indicador: Presencia o ausencia de la aplicación de la metodología.
b. Variables dependientes.
 Eficacia de desarrollo de proyectos de BI
Indicadores:
 Cumplimiento de los requerimientos (funcionamiento y visualización
de los reportes correspondientes).
 Calidad de los entregables (formatos).
 Cumplimiento

de

las

actividades

correspondientes

al

Rol

desempeñado.
 Cumplimiento con las fechas programadas por actividad.
3.7 Técnicas e instrumentos de recolección de datos
En base a los controles de avances programados, cada equipo debe
cumplir con los entregables y formatos propuestos y con el cumplimiento
de los requerimientos.
26

CAPÍTULO IV
DESARROLLO DEL OPENUP PARA BI

4.1 Decidiendo por OpenUP.
Los modelos propios para la implementación de BI representan en forma
de grupo de procesos la secuencia de una implementación de BI,
describen los entregables propios de BI y realizan cierta descripción con
respecto a los roles. Como podemos notar del marco teórico existe una
tendencia a buscar alternativas de modelos o metodologías que permitan
un mayor éxito en la implementación de BI.
El problema de los modelos propios de BI no especifican a niveles más
detallados la secuencia de trabajo, de este modo se obvia la relación
entre ellas; no se especifica la relación de trabajo entre los roles. Esta
generalidad ocasiona que no exista una información guía que ayude a la
gestión del proyecto. La falta de formatos es otro problema considerable,
dichos modelos solo mencionan los ítems a considerar por entregables
propios de BI, pero no explican y mucho menos no lo consideran con
respecto a la gestión del proyecto.
La tendencia de acomodar los modelos de BI bajo el enfoque clásico de
las fases de desarrollo de software es notoria, pero existe aún cierta
rigidez en dichos modelos. Por ejemplo el modelo de BDLC de Kimball y
aun el modelo del BI Roadmap según su esquema no evidencia el
conjunto de pruebas iterativas en la construcción del producto como es la
tendencia actual en el desarrollo de software. En estos modelos tampoco
se tampoco se evidencia una división del trabajo en iteraciones que
representen logros inmediatos, la cual es propio de un proyecto de BI,
como por ejemplo la construcción del modelo multidimensional por temas
de negocio.
Existen muchas propuestas, en investigación, de implementar BI bajo el
enfoque de las metodologías de desarrollo de software, especialmente
27

con metodologías ágiles. Aplicar metodologías de desarrollo de software
para implementar BI requiere la modificación o extensión de dichas
metodologías.

Existe

mucha

similitud

entre

los

procesos

de

implementación de BI con las fases de desarrollo de software, está en
investigación la implementación de BI con la metodología SCRUM que se
utiliza muchas veces para el desarrollo de software manteniendo un
desarrollo iterativo incremental. El problema con el SCRUM es que
descarta la planificación detallada del todo el ciclo del proyecto, sabemos
que es parte de la filosofía del SCRUM, y podría adaptarse a nuestra
realidad que es común el atraso en el desarrollo del software, pero es
algo que se intenta revertir. El estado a través del PACIS propone la
certificación del CMMI así como de la norma técnica peruana (NTP)
correspondiente la cual enfatizan la planificación del proyecto como
procesos importantes para proyectos de desarrollo de software, bajo
dicho contexto la metodología SCRUM queda descartada como regla
general.
Como vimos en el marco teórico, la metodología XP es una de las
opciones para adaptarla para proyecto de de implementación de BI, pero
siguiendo el contexto en que se enmarca esta investigación, sería más
trabajoso la forma de adaptar el XP en las consultoras en el Perú que ya
tienen una tendencia a la forma de iterativo incremental clásico debido a
la formación profesional del personal en los proyectos.
En el Perú no existen aun procesos estándares para el desarrollo del
software, algunas consultoras actuales tratan de seguir la metodología
RUP, otras consultoras e incluso las que tienen más tiempo tienen su
propia forma de trabajar pero siguen el estilo iterativo incremental clásico
por la respectiva formación profesional. El RUP se descarta como
propuesta en esta investigación debido a que se necesitaría descartar
muchos procesos, tareas, roles y entregables del RUP para adaptarla a
una implementación de BI, además que el RUP se aplica para proyectos
grandes con equipos grandes de trabajo.
28

Bajo el contexto de la presente investigación se está optando por la
metodología OpenUP debido a que los procesos de esta metodología
permite adaptarla a diversos tipos de proyectos, permitiendo su
factibilidad para proyectos de implementación de BI, además, por la
similitud de los procesos que aplican muchas de las consultoras que
desarrollan software en el Perú.
El OpenUP es la forma sintetizada del RUP, la estructura de la
metodología OpenUP es totalmente básica que facilita su adaptación a la
realidad de diversos proyectos sin perder los principios ágiles y de
desarrollo iterativo incremental clásico así como su base en las mejores
prácticas.
La ventaja que mantiene el OpenUP que proviene del RUP es el detalle
de las tareas desde un enfoque por iteraciones, como se analizó
anteriormente es importante en proyectos de BI, la cual esto permite
relacionar tareas con los roles correspondientes en cada momento.
Además los formatos predefinidos que permiten tener una visión clara del
proyecto por cada rol. Uno de los formatos claves es el Documento de
Arquitectura que permite centralizar la idea de lo que se va a construir y
sirve de guía en toda la fase de construcción. Los formatos de los
documentos relacionados a la gestión, permiten tener una idea clara de lo
que se piensa hacer y ayuda a controlar el rendimiento del proyecto.

4.2 Extendiendo el OpenUP.
A continuación se menciona la propuesta de esta investigación donde
también se compara la propuesta con la forma tradicional de implementar
BI tales como el modelo BDLC de Kimball.
A) Los roles
Las características que considera el OpenUP con respecto a los roles no
se descartan en esta investigación, es mas siguen como línea base para
mantener el cumplimiento de la metodología, la delimitación de la función
29

de un rol no se considera en la mayoría de los modelos de BI. Lo que se
describe a continuación por cada rol son las características adicionales
que deben cumplir para poder trabajar en un proyecto de BI:

Director del proyecto (Project Manager), dirige a la planificación del
proyecto interactuando con los expertos del equipo del proyecto,
coordina las interacciones con los interesados, se asegura de que los
interesados entiendan lo que se está proponiendo en el proyecto, y
mantiene el equipo del proyecto centrado en el cumplimiento de los
objetivos del proyecto.
El director del proyecto necesita conocer, por parte del Analista, el
nivel de complejidad de cada componente involucrada en la
implementación de BI, por ejemplo la complejidad de procesamiento
del código ETL, tiempo de procesamiento del ETL, el refrescamiento
del modelo multidimensional, la carga inicial de datos, depuración de
los datos, entre otros. Este factor es importante porque influye
significativamente en el alcance, tiempo y costo del proyecto,
mantener los márgenes adecuado de tiempo entre las respectivas
iteraciones permitirá un desempeño adecuado en el proyecto.
El director del proyecto necesita conocer por parte del Arquitecto las
alternativas y características de las herramientas adecuadas para el
proyecto así como las divisiones adecuadas de los componentes de la
solución. Este factor es importante porque influye en el tiempo y costo
del proyecto, cada herramienta tiene su particularidad y ámbito de
acción, por ejemplo, algunas herramientas solo considera la
generación del modelo multidimensional, esto significa que el proceso
de ETL tendría que hacerse con el código interno de la base de datos,
la cual aumenta el riesgo y obliga a ejercer un mayor tiempo y control
con respecto a la estructura del código del ETL.
Las representaciones tales como el modelo conceptual por parte del
Analista, debe ser entendido por el Director del proyecto, debido a
30

que este modelo debe ser validado por los interesados, y además el
modelo conceptual ayuda a determinar el alcance del proyecto en la
fase de construcción.
La interacción entre el Director del proyecto, Analista y Arquitecto no
se resalta en los modelos de BI, la representación del OpenUP en la
fase de concepción refleja esta interacción entre los roles la cual es
un factor importante en el proyecto de BI.

Analista (Analyst), la persona en este rol interactúa con los usuarios e
interesados para entender el problema a resolver y mediante la
captación y fijación de prioridades para los requisitos.
El Analista encamina la entrevista de una manera adecuada para
determinar si la empresa necesita de una solución de BI realmente y
si cumple con los requisitos tales como el volumen de datos.
El Analista es el experto que debe saber analizar el modelo de datos
existente, a través del modelo de datos puede reconocer el
funcionamiento de la organización. El Analista debe encontrar los
problemas y errores en la estructura de datos y proponer una
alternativa para su depuración que forme parte de la solución de BI
propuesta.
El Analista tiene la habilidad de identificar indicadores que expresen
comportamientos y tendencias propios de BI y determinar el grado de
importancia para los interesados. Este punto es un factor decisivo en
el éxito del proyecto, pues la buena estructuración de los indicadores
con sus respectivas dimensiones encaminará a un desarrollo sin
inconveniente. Cuando el Analista no es un experto en soluciones de
BI muchas veces confunde un indicador o variable utilizado a nivel
operativo con un indicador propio de BI, es un riesgo que debe ser
considerado por el Director del proyecto al conocer a su equipo.

31

El Analista es el experto que conoce las técnicas propias de una
solución de BI como por ejemplo Source Driven, desarrollo del Modelo
Multidimensional, Drill Down, entre otros.

Arquitecto (Architect), es responsable de definir la arquitectura de la
solución de BI, que incluye tomar las decisiones técnicas clave como
la arquitectura de hardware y software que limitan el diseño y la
ejecución general del sistema. La decisión del Arquitecto influye
significativamente en el plan del proyecto formulado por el Director del
proyecto. En el ámbito de herramientas a considerar en el plan del
proyecto de la solución de BI incluye los diversos dispositivos tales
como Pocket PC, Palms, celulares adecuados y las características de
seguridad adecuada debido a que la información a compartir es de
gran importancia para la organización.
El Arquitecto debe asegurarse de la correcta instalación de las
herramientas involucradas en el proyecto. Monitorear la adecuada
configuración de los componentes de la herramienta de BI y su
posible utilización por los usuarios y miembros del equipo del
proyecto. El Arquitecto debe conocer un nivel avanzado de
administración

de

la

Base

de

Datos

como

por

ejemplo

particionamiento de tablas, es su responsabilidad asegurarse la
correcta implementación del modelo del Datawarehouse.
La capacitación que debe dar el arquitecto a los desarrolladores es un
punto que no se debe descuidar debido a que los desarrolladores
deben adaptarse a las herramientas aceptadas para el proyecto. Una
capacitación previa antes del desarrollo garantiza en cierto modo el
cumplimiento correcto de los tiempos programados.
El Arquitecto debe interactuar constantemente con el Analista, debe
asegurar

que

los

requerimientos

expresados

en

diagramas

complementen con la capacidad técnica de hardware y software así
como la Arquitectura completa de la solución de BI. Por ejemplo las
32

entidades de las dimensiones deben relacionarse con la estructura de
tablas, su almacenamiento como segmento y la distribución entre los
archivos de datos de la Base de Datos, además la estimación del
volumen de datos según el análisis de la granularidad.

Desarrollador (Developer), es responsable de desarrollar una parte
del sistema, incluyendo el diseño para encajar en la arquitectura,
posiblemente de prototipos de los reportes, y la ulterior aplicación,
pruebas unitarias, y la integración de los componentes que forman
parte de la solución.
El desarrollador tiene la experiencia de interactuar con la Base de
Datos, conocedor de las técnicas de optimización de consultas así
conocedor de de los objetos de la Base de datos y seguridad de la
misma. En la solución de BI, el desarrollador no es necesariamente un
programador que utiliza algún lenguaje de programación, existe la
posibilidad de requerir que el desarrollador conozca de un lenguaje de
programación cuando la solución de BI requiera el apoyo para agilizar
los procesos de migración de datos, o módulos complementarios y
simples para la captura de datos necesarios para la solución de BI
tales como módulos de encuestas.
Por las limitaciones de la herramienta de BI, el Desarrollador debe
conocer el lenguaje avanzado propio del Gestor de Base de Datos,
especialmente en el proceso del ETL.
El Desarrollador con la guía del Arquitecto se basa en el documento
de la Arquitectura para continuar con el desarrollo, en el modelo
BDLC de Kimball propone el desarrollo después del entendimiento de
los requerimientos y la línea principal de desarrollo debe esperar al
desarrollo del modelo físico del Datawarehouse, pero no enfatiza una
representación completa de la solución de BI, en la metodología del
OpenUP si enfatiza la representación integrada de la solución en el
documento de Arquitectura la cual sirve de punto de partida para el
33

desarrollo. Uno de los entregables importantes es el Metadato Fuente,
el Desarrollador expresa el paso de los datos desde la fuente (datos a
nivel operacional) hacia el Datawarehouse, la lógica del proceso es
expresado en forma general, el Analista debe validarlo inicialmente
para que pueda ser considerado como parte de la Arquitectura de la
solución de BI en la fase de elaboración. El Desarrollador debe tener
la

habilidad

de

entender

el

documento

de

Arquitectura,

especificaciones y diagramas.
B) Entregables
Una ventaja de la metodología OpenUP en comparación de los modelos
de BI es la presentación de entregables con sus respectivos formatos.
Mientras que en los modelos de BI solamente te describe lo que deberías
presentar, en los formatos del OpenUP muestra una estructura ordenada
que permite ver una correlación dentro del mismo documento como con
otros entregable, además muestra una visión integral de la solución.

Dominio del Director del proyecto. En el OpenUP para BI se mantiene
los formatos originales, la variación es en el contenido. Según la
experiencia del Director de proyecto e información que comparte con
el Arquitecto y Analista determina los tiempos, costos, alcance y
control de calidad que debe estar expresada en los documentos.
Según la cantidad de temas que conforman un grupo de indicadores
que están involucrados en la solución de BI determinará en la
cantidad de iteraciones que el Director de proyecto deba considerar
en el documento.
Una propuesta de la investigación es reemplazar el Work Item List por
un cronograma al formato del diagrama de Gantt, donde las
actividades están reagrupadas por iteraciones claramente definidas y
estas iteraciones reagrupadas por las fases correspondientes.

34

Dominio de los requerimientos. Los entregables y formatos ayudan
completamente para una solución de BI, por tal motivo se mantienen
en el OpenUP para BI.
El modelo de Caso de Uso es perfectamente adaptable para entender
el funcionamiento de una solución de BI y su interacción con sus
respectivos actores. Por ejemplo se representa el actor “Gerente de
venta” que ejecuta el caso de uso “Generar reporte progreso de
ventas por periodo” y a su vez tiene un “extend” hacia el caso de uso
“Filtrar la venta por categoría de productos”.
Un modelo que se incluye en este dominio es el modelo conceptual.
Mientras el modelo de casos de usos representa la funcionalidad de la
solución de BI. El modelo conceptual representa, al mismo nivel del
diagrama de casos de usos, el comportamiento de los indicadores y
su relación con las entidades. Ambos modelos ayudan a comprender
de forma integrada la solución completa e incluso para el
entendimiento de los interesados.

Dominio de la arquitectura. El entregable principal es el Documento de
Arquitectura

(Architecture

Notebook),

se

considera

que

este

documento ayuda completamente para la solución de BI. Los cambios
propuestos en esta investigación es especificar en el documento de
Arquitectura los diagramas y formatos propios de BI, como por
ejemplo el Modelo de Casos de Uso, Modelo conceptual, Modelo
Dimensional, Modelo Físico del Datawarehouse, Metadata Fuente,
formato de los reportes, entre otros.

Dominio del desarrollo. La metodología OpenUp presenta 4
entregables bajo este dominio, Diseño (Design), lo construido (Build),
la implementación (implementation) y Pruebas del desarrollador
(Developer Test), los cuatro entregables son adaptables para una
solución de BI, en el OpenUP para BI conviene considerar lo

35

construido (build) especificándolo en 4 componentes bien definidos
propios de BI:
a) Modelo físico (estrella y/o copo de nieve) en el Datawarehouse.
Responsable es el Desarrollador estructurar el Datawarehouse
según la propuesta en el documento de arquitectura, este proceso
debe ser monitoreado por el Arquitecto especialmente en el
aspecto técnico del desarrollo. Este entregable es un hito interno
de la fase de construcción se requiere la validación del Analista.
b) Código del ETL, lógica de programación o representación gráfica
ejecutable de la migración, depuración y transformación y carga
de los datos al Datawarehouse. La guía inicial es el Metadata
fuente descrito en el documento de arquitectura. Responsable es
el desarrollador de que exista un coherencia entre el Metadata
fuente con lo desarrollado, la entrega puede ser subdividido por
temas (estrella o copo de nieve), cada sub-entrega debe ser
validado por el Analista.
c) Generación del modelo multidimensional. El desarrollador debe
conocer la ventaja de la herramienta que está utilizando para
generar cada componente multidimensional de manera adecuada,
la entrega puede subdividirse también por temas, quien debe
validar cada sub-entrega es el Arquitecto debido a la naturaleza
totalmente técnica del componente.
d) Generación de los reportes, respetando la propuesta del modelo
BDLC de Kimball, existe la posibilidad que la estructura de los
reportes se hayan desarrollado desde la fase de elaboración o
inicios de la construcción, la cual permite aprovechar el tiempo en
el proyecto. Es en la fase de construcción donde se relaciona las
estructuras de los reportes con el modelo multidimensional
generado. También se puede subdividir el entregable por temas,
cada subdivisión debe ser validado por el Analista, es en este
36

punto donde el Analista tiene un rastreo total desde los reportes
en ejecución hasta los requerimientos.
Como parte de la implementación esta la configuración y visualización
de los reportes en diversos dispositivos incluyendo la respectiva
seguridad y el servidor web que los contiene. Se necesita del
monitoreo adecuado del Arquitecto.
Las pruebas del desarrollador deben ser documentado en los
informes de avances y entregados al Director del proyecto o al
responsable del trabajo de los Desarrolladores (apoyo de gestión)
asumiendo que se lleva un control sobre el cumplimiento de las tareas
y/o actividades. Según lo informado, en el caso de encontrar aun
errores que ocasionen atrasos por volver a desarrollar un componente
de BI, el Director del proyecto podrá reestructurar los tiempos del
cronograma rápidamente e informar a todos los implicados tales como
el Arquitecto, Analista, Desarrollador y otros.
El Diseño es opcional solo en el caso que se deba desarrollar un
módulo complementario y simple con un lenguaje de programación,
con respecto a la solución de BI, los diagramas de diseño están
directamente bajo la responsabilidad del Desarrollador.
C) Tareas
Las tareas que propone el OpenUP son adecuadas para implementar una
solución de BI, a continuación se detallaran las tareas que deban ser
enfatizados en el OpenUP para BI como parte de esta investigación:

Disciplina de requerimientos: Detalle del Modelo Conceptual.
Esta tarea describe como representar el modelo conceptual. El
propósito de esta tarea es lograr representar el Modelo Conceptual
que permita el entendimiento apropiado por los interesados y el
equipo del proyecto.

37

1. El Analista es el responsable de representar los indicadores con
las entidades relacionadas en el modelo conceptual. El Analista
descubre los indicadores y entidades a través de las entrevistas
con los interesados. Los Analistas dependen además del análisis
realizado en las fuentes de datos de la organización. A través de
esta tarea el Analista genera el modelo conceptual por cada tema.
2. Para representar adecuadamente el Modelo conceptual debemos
seguir los siguientes pasos:
a) Analizar la información obtenida en las entrevistas realizadas
para

descubrir

indicadores,

asumimos

que

existieron

entrevistas anteriores para determinar si la organización
necesitaba de una solución de BI.
b) Analizamos la estructura de datos de las distintas fuentes,
desde el formato de un reporte en papel, hojas de cálculo
hasta las Bases de Datos operacionales. Se recomienda
analizar las fuentes primero, de esta manera encaminar mejor
la entrevista con los interesados.
c) Agrupamos los indicadores descubiertos con el resto de
variables o entidades relacionados con el indicador, el éxito
del modelo es descubrir todos las relaciones posibles, los
valores o entidades pueden ser abstractos.
d) Buscar imágenes adecuadas que representen a las variables
o entidades y relacionarlas con el indicador. Con esta
representación de alto nivel se forma el Modelo conceptual.
e) Ordenar y separar el Modelo conceptual por cada tema.
3. Debemos considerar que la intención del Modelo conceptual es
hacer que el interesado comprenda y valide la propuesta de la
solución de BI en base a la información obtenida.

Disciplina de la arquitectura: Validación del Arquitecto.
Esta tarea describe el proceso de validación de los Modelos
presentado por los analistas, la validación es desde el punto de vista
38

técnico, el Arquitecto se asegura que lo expresado en los entregables
del Analista no escape del ámbito propuesto por la arquitectura
coordinada por el Director del proyecto y los interesados.
1. El Arquitecto es el responsable de la validación. El Analista
entrega los avances de los modelos y formatos en las fecha
acordadas.
2. El proceso de validación sigue los siguientes pasos:
a) El Analista informa al Director del proyecto sobre el avance
realizado según la fecha acordada en el plan de iteración. El
Director del proyecto actualiza el cronograma programando la
fecha de validación y controlando el estado de las actividades
e informa al Arquitecto para que proceda con la validación.
b) El entregable es dado por el Analista al Arquitecto, de este
modo procede el Arquitecto a analizar los puntos del
entregable que tienen que ver con la propuesta de la
Arquitectura. Si el Arquitecto necesita alguna explicación, el
Analista debe estar dispuesto a brindar la explicación
necesaria.
c) El resultado de la validación del entregable debe ser en mutuo
acuerdo entre el Arquitecto y el Analista. El Arquitecto informa
al Director del proyecto sobre la validación del entregable.
d) Según

el

informe

de validación, si es necesario la

modificación del entregable, el Director del proyecto actualiza
las actividades del cronograma y procede a informar a los
involucrados.
3. Debemos considerar que el Arquitecto solamente valida desde el
punto de vista técnico y según lo acordado entre el Director del
proyecto y el interesado. Además, las notas de la Arquitectura ya
fueron establecidas desde la fase de concepción y refinado a los
inicios de la fase de elaboración.
39

Los entregables del Analista se complementan con el Documento
de Arquitectura en el ítem 9 que es “Vistas de la Arquitectura”.

Disciplina de desarrollo: Integrar y crear.
Esta tarea describe cómo integrar todos los cambios realizados por
los desarrolladores en la base de código y realizar las pruebas
mínimas para validar la construcción. Los pasos propuestos por el
OpenUP se pueden aplicar para la implementación de una solución
de BI. El paso de Crear corresponde al desarrollo propio de un
software, para el OpenUP para BI se mantiene la misma propuesta
en el caso que en una solución de BI necesite de la ayuda de
módulos complementarios o códigos de un lenguaje de programación.
En el OpenUP para BI se propone un paso más “crear componentes
de BI” con los siguientes sub-pasos:
1. Analizar el documento de Arquitectura de una manera integrada y
enfatizando la parte que corresponde construir.
2. Construir considerando el siguiente orden:
a) El modelo del datawarehouse y/o datastaging en el servidor de
Base de Datos.
b) El proceso de ETL.
c) EL modelo multidimensional aplicando datamining donde es
necesario según la herramienta apropiada.
d) Los reportes y dashboards.
3. El Desarrollador presenta su informe de avance al Director del
proyecto. El Director del proyecto actualiza el estado de las
actividades del proyecto y procede a informar a los involucrados
para la respectiva validación.
4. El rol correspondiente, según la naturaleza del entregable, realiza
la validación. El resultado de la validación es de mutuo acuerdo
entre el Desarrollador y el rol revisor. El rol revisor presenta el
40

informe

de

validación

al

Director

del

proyecto

para

la

correspondiente actualización del plan de iteración.
D) Fases
Teniendo como base el OpenUP se procedió a resaltar las partes en que
se debe considerar los temas propios de la Inteligencia de negocios en
sus correspondientes fases, en los siguientes diagramas solamente se
resalta la extensión realizada.
Fase de concepción:
Con respecto a las fases se ejecutan los mismos procesos, la diferencia
es el enfoque, al recoger los requerimientos se debe pensar siempre en la
estructura de datos existente y a desarrollar (Datawarehouse).
El Director del proyecto depende en gran manera del trabajo de los
analistas, pues son ellos los que deben recoger suficiente información
inicial para lograr formular el proyecto de BI. El enfoque clave de los
analistas es la recolección de los requerimientos a nivel gerencial. La
habilidad y experiencia ayudan a saber reconocer un requerimiento a nivel
gerencial. Como sabemos no siempre el Gerente de área o el usuario
saben delimitar este asunto.
Como se muestra en la figura 7 es el Arquitecto quien en base a la
información de los analistas, propone alternativas de arquitectura para
este proyecto. Lo resaltante de este modelo es que el documento de
Arquitectura debe considerar las herramientas de BI y tecnología
involucrada.
Como es propio de la metodología OpenUP, esta información es útil para
el Director del proyecto en preparar los documentos necesarios para
negociar el proyecto con la empresa. En esta fase también es propio del
OpenUP que el Director del proyecto tenga ya un control de las
actividades realizadas agrupadas por iteraciones.

41

Figura 7 – Esquema de la fase de concepción del modelo propuesto

Fase de elaboración:
Esta fase es muy importante para todo tipo de proyecto, incluso en el
proyecto de BI. Es posible representar el funcionamiento de la aplicación
de BI a través de un diagrama de caso de usos del sistema así como su
respectiva documentación de especificación de casos de usos.
Lo resaltante de este modelo son las representaciones de los
requerimientos en los diagramas propios de BI tales como su modelo
42

conceptual, modelo dimensional y físico del DW. Lo que se resalta en este
modelo es también la BD intermedia, que sirve en la mayoría de
proyectos de BI, debido a la complejidad y problemas de los sistemas de
información de una empresa, como una BD de apoyo en el proceso de
ETL.
En estas metodologías de UP se delega la responsabilidad a los
desarrolladores de hacer el Diagrama de Clases de Diseño, que es un
diagrama que representa la estructura real de la aplicación. En el caso de
este modelo varia este asunto, pues tal diagrama no es necesario a
menos que se complemente con un módulo de Software que ayuda de
forma complementaria la obtención de información.
En este modelo se está responsabilizando a los desarrolladores la
Metadata o mapeo de los datos, se representa según formato utilizado, el
paso de los datos desde la BD Operacional al Datawarehouse, si es
necesario la BD Intermedia también se representa en este formato.
Como también se está representando en la figura 8, es responsabilidad
del Arquitecto validando y complementando los entregables generados
por los analistas y desarrolladores con la arquitectura propuesta y
aprobada. Además es responsabilidad del Arquitecto las capacitaciones
necesarias con respecto a las herramientas de BI a utilizar por los
desarrolladores.
Como es propio del UP, debemos basarnos en la Arquitectura, la
propuesta de este modelo es igual, en el documento de la Arquitectura se
debe integrar todos los diagramas realizados así como el Metadata con la
validación del Arquitecto, todo debe estar conforme según la arquitectura
propuesta. El objetivo es tener un documento que sirva como guía para la
construcción de la aplicación de BI.

43

Figura 8 – Esquema de la fase de elaboración del modelo propuesto

Fase de construcción:
Como podemos observar de la figura 9, el desarrollador tiene la mayor
responsabilidad, recordemos que la estructura es por iteraciones siempre,
que es el cumplimiento de logros inmediatos para que en su conjunto se
logren los objetivos de las fases y por ende los objetivos del proyecto.
Para este Modelo se propone que las iteraciones de la fase de
construcción sean según los temas del negocio, esto significa que el
cumplimiento de cada tema sería un logro inmediato de toda la solución
de BI que se propone en los proyectos.
En esta fase es donde se preparan los repositorios necesarios tales como
los del DW y BD Intermedia; también el código propio de la lógica del ETL
y al generación de los cubos y reportes según los requerimientos.
Como es propio del OpenUP los Administradores del proyecto siempre
están supervisando y controlando el cumplimiento de las actividades del
proyecto y los Testers realizan aquí su trabajo de pruebas especiales para
controlar la calidad de los entregables y del producto final.
44

Figura 9 – Esquema de la fase de construcción del modelo propuesto

Fase de transición:
En esta fase se ejecutan los procesos propios del OpenUP, la idea es que
la aplicación sea implementada y probada en un entorno real de trabajo
con la manipulación de los usuarios reales. Por ejemplo se de probar el
DW en la arquitectura de hardware destinada y utilizada en el área de
producción de la empresa. EL DW debe soportar la cantidad de datos
reales a utilizar, su tiempo de respuesta, entre otros. Del mismo modo los
Gerentes, previa capacitación, deben saber manipular los datos para
preparar la información que realmente necesitan.
Esta fase concluye con la aceptación del stakeholder y por ende finaliza el
proyecto.

45

CAPÍTULO V
VALIDACIÓN Y ANÁLISIS DE LOS RESULTADOS

Los resultados se obtuvieron a través de los controles de avances
realizados en las horas de clases como requisito del curso, tutoría fuera
de las horas de clases y a través del equipo de auditoría (alumnos del 4to
año de la Escuela de Ingeniería de Sistemas), un ejemplo de los informes
de auditoría se encuentran en el anexo 9. En la tabla 2 se tiene como
ejemplo la calificación obtenida por los grupos del proyecto de BI en cada
revisión de clases.

Tabla 2 – Registro general del control de avances por grupos.
Trab1

Rev1

Rev2

Rev2.1

Rev3

EXP

Trab

Prom.

Final

Final

Avances

G1
Pentaho

17

15

11

17

12.00

SQLServer

17

16

13

13

11.08

Oracle

17

13

06

10

09.20

Pentaho

17

15

15

18

13.00

SQLServer

17

15

13

18

12.60

Oracle

13

13

11

10

09.40

MicroStrategy

19

16

11

20

13.20

Businnes Object

15

13

11

17

11.20

G2

Los resultados se validaron bajo dos criterios, el primero en el grado de
cumplimiento con los requerimientos del usuario por cada entregable. Y el
segundo criterio en base al rendimiento del trabajo por el cumpliendo del
OpenUP para BI en comparación al rendimiento de trabajo por el
cumplimiento del modelo tradicional BDLC de Kimball.
Con respecto a la primera etapa, durante la ejecución del proyecto previo,
los resultados se validaron con los interesados, gerentes de PU. Esta
46

validación sirvió de base para poder validar del mismo modo cada
entregable generado por los equipos de los proyectos formado por los
alumnos. Cada equipo de proyecto debía trabajar en el mismo escenario y
como mínimo lograr lo mismo del proyecto previo. Se sabe que a pesar de
trabajar en el mismo escenario los resultados serían diversos debido al
factor humano, uso de la herramienta, circunstancias socio cultural, entre
otros.
En Mayo del 2007 se estimo realizar un proyecto previo de
implementación y ejecución del modelo en la misma empresa con la
intensión de capturar los requerimientos necesarios por parte de la
empresa, evaluar la problemática así como analizar el ámbito del proyecto
y los indicadores que servirán en el control de los siguientes proyectos.
Este proyecto previo permitió además, agilizar la captura de los
requerimientos por parte de los proyectos siguientes así como tratar de no
interrumpir a la empresa PU en sus labores diarias considerando la
ejecución de hasta ocho equipos de proyecto en la validación de la
investigación propuesta.
En el anexo 1 se muestra el Project chárter de este proyecto previo
incluyendo el cronograma estimado. La duración fue menos de dos meses
considerando el alcance del prototipo y la experiencia del personal a
cargo del este proyecto previo.
En este proyecto previo se trabajo con la analista funcional de PU, un
programador de PU y el director del proyecto quien era el responsable de
cumplir el modelo propuesto no refinado y desarrollar un prototipo. Al final
del proyecto que duro aproximadamente tres meses, se presentó el
resultado de la implementación ante los gerentes de PU y otras
autoridades de la UPeU, quienes dieron su conformidad en el prototipo
mostrado. Con esta experiencia previa, se procedió a hacer los ajustes
necesarios en la metodología OpenUP para que se adapte a una
implementación de BI.
47

Como parte de la ejecución del proyecto previo, se realizó lo siguiente:

Se delimitó el alcance solo al área de venta de PU para el prototipo,
se logro identificar las tablas correspondientes, y se les representó en
diagrama, en el anexo 8 se muestra las tablas involucradas en el área
de ventas de PU.

En base al análisis se planteó que la Base de Datos necesita ser
corregida, si no se corrige afectaría negativamente a cualquier
implementación de BI. Por consiguiente se tiene que crear una Base
de Datos intermedia entre la Base de Datos Operacional y el
Datawarehouse.

La tabla crítica era “DATOS_CLIENTES” no solo por su importancia
en el tema de ventas sino también por su dependencia con la tabla de
vendedores y aun más por los demasiados errores de datos y
estructura. La representación de la tabla “DATOS_CLIENTES” en la
Base de Datos intermedia fue en dos tablas, la cual se muestra en el
anexo 8. La primera para almacenar los registros no repetidos de los
clientes, esto obligó a que cada registro tenga un identificador único
(PK) nuevo y distinto con respecto a la Base de Datos Operacional. La
segunda tabla almacenaba el identificador único que fue creado en la
primera tabla y también todos los códigos como llave primaria de la
Base de Datos Operacional que hacen referencia al registro actual y
único del cliente.

En todos los procesos de análisis se tuvo el apoyo del Analista
Funcional de Ventas de PU la cual permitió la obtención de los
requerimientos del área de ventas, apoyo del área de informática de
PU y el acceso a los datos correspondientes. Como producto final del
análisis de representó el modelo estrella mostrado en el anexo 8 con
el indicador MONTO_VENTA que es el importe en bruto de la venta
generada según la fecha, el producto, el cliente y política y su relación

48

del indicador con tipo del cliente (block) y vendedor que registró la
venta.

se procedió a crear el metadata o mapeo de los datos en el formato
en una hoja de cálculo tal como se muestra en el anexo 8. Se muestra
tres tipos de procesos del ETL, en las primeras tablas que
corresponden al cliente se necesita utilizar la BD intermedia, en las
tablas que corresponden al tiempo representa a una transformación
directa de la BD Operacional al Datawarehouse y las tablas que
corresponden al indicador Monto_Venta se considera el proceso para
calcular el valor del indicador, en este caso sin la necesidad de la BD
intermedia.

La herramienta de BI que se utilizó fue la de SQLServer2005,
especialmente sus componentes de Integration Service (ETL),
Analysis Service (Motor de BI) y Reporting Services (interfaces
graficas para los reportes y gráficos estadísticos).

Se tuvo la aceptación de los usuarios finales, gerentes de las áreas
relacionadas a la venta en PU. Esta aceptación validó los entregables
generados, la cual serían los entregables que deben lograr cada
equipo de proyecto de BI.

Los entregables que lograron terminar los equipos del proyecto en el
plazo acordado cumplieron con los requerimientos de los usuarios en
base al alcance y en base a la validación hecha por los usuarios de PU en
el proyecto previo.
Con respecto a la segunda etapa, se compara el cumplimiento del modelo
o metodología que siguieron los proyectos en base al cumplimiento del
primer criterio.
En la tabla 3 se muestra una calificación en el intervalo de 0 a 3 en base
al cumplimiento de los criterios en común del modelo tradicional y el
OpenUP para BI y además con los entregables validados bajo primer
49

criterio. La calificación obtenida por los alumnos fue en base a la escala
vigesimal, para la investigación se realizó un resumen por grupos en la
escala de 0 a 3, en la tabla 3 se muestra el detalle del criterio de
evaluación:

Tabla 3 – Criterio de evaluación.
Criterio

Valor

No cumplió

0

Cumplimiento pobre

1

Cumplimiento medio

2

Cumplimiento aceptable

3

La tabla 4 está dividida por 2 secciones que son: la primera sección
formados por los grupos que no aplicaron el OpenUP para BI en el
periodo del 2008, se centraron en cumplir de la manera tradicional
basándose en forma general en el modelo BDLC de Kimball, los grupo
correspondiente a esta sección utilizaron los conocimientos y formatos
propuesto en el PMBOK. Y la segunda sección formada por los grupos
que si aplicaron el OpenUP para BI en el periodo del 2009, debido a la
cantidad de alumnos, se formó 8 grupos, esto representó una ventaja
para la investigación.
Como podemos observar de la tabla 4, se utilizaron 4 herramientas de BI
las cuales fueron: Pentaho (PH), SQLServer 2005 (SQLS), MicroStartegy
(MStr) y Herramientas de Oracle (oracle), cada grupo tenía que escoger
una de ellas.
El primer periodo correspondiente al año 2008, se formaron 4 equipos de
trabajo cada proyecto con una solución de BI particular, además cada dos
equipos con una herramienta de BI distinta de trabajo tales como
MicroStrategy, SQLServer2005, Pentaho, Oracle 10g. Se les mostro como
capacitación previa, los conceptos propio de BI, así como lo que propone
50

el modelo de Kimball. La capacitación detallada sobre los procesos a
seguir fue durante el periodo académico.
El segundo periodo correspondiente al año 2009, con el equipo de trabajo
reunido, alumnos del quinto año de Ingeniería de Sistemas, se procedió a
organizarlos y darles las directivas necesarias. Se obtuvo 8 equipos de
proyecto cada uno cumpliendo con los roles propuestos por la
metodología OpenUP para BI y cada dos equipos con una herramienta de
BI diferente tales como: Pentaho, SqlServer 2005, Microstrategy 8 y
Oracle 10g; se consideró las licencias académicas o de distribución libre
en internet por fines de investigación.
Los criterios de evaluación mostrados en la tabla 4 están agrupados en 4
grupos principales que son: gestión, requerimientos, arquitectura y
desarrollo. A continuación procedemos a analizar los resultados de cada
uno de ellos:
A) Gestión:

Formación del Project Charter, en este ítem se evalúa el proceso
aplicado por los grupos, en el caso de los grupos bajo el modelo
tradicional, prefirieron seguir lo aprendido de la guía del PMBOK,
reconocieron

que

el

modelo

tradicional

no

ofrece

detallada

información al respecto, el resultado se evidencio en el Project
Charter, el documento no mostraba una idea correcta de lo que se
esperaba lograr y tampoco de los componentes involucrados de BI.
Los que aplicaron el OpenUP para BI tuvieron como guía principal los
ítems de los formatos del OpenUP,

en su Project Charter se

evidenció una mejor noción de lo que esperaban realizar durante el
proyecto, esto es debido a la información dada por los roles
correspondiente, la cual cada uno sabía el ámbito de información a
investigar. En el anexo 2 se tiene el plan formulado por cada equipo
de proyecto y se muestra un cronograma general dividido por
iteraciones generales (G1, G2,..., G7), este cronograma serviría para
51

que los equipos de proyecto especifiquen su plan y sus iteraciones
propias de su proyecto teniéndolo como referencia.
 El control de los formatos, en este ítem el equipo de gestión debía
uniformizar y controlar los formatos propuestos. Los grupos bajo el
modelo tradicional tuvieron que estructurar los formatos en base a la
guía del PMBOK, los formatos de un nivel técnico se basaron en los
formatos del RUP y/ OpenUP, esto ocasionó un tiempo de atraso y
ajustes para integrar la idea del proyecto entre los formatos, algunos
grupos lograron una calificación aceptable al respecto. Los que
aplicaron el OpenUP para BI tuvieron esta ventaja con respecto al
tiempo y la integración de la idea del proyecto, Cumpliendo con la
metodología OpenUP se generaron documentos por iteraciones, una
muestra se encuentra en el anexo 5. Se utilizó el plan de iteración
para controlar el cumplimiento de las tareas, en este documento se
considera un campo de documento de referencia, que es un
documento que se utiliza como evidencia del cumplimiento de las
tareas y/o paquete de trabajo. Como documento complementario se
utilizó un cronograma al formato del diagrama Gantt.
 Con respecto al control del Alcance y del Tiempo del proyecto, no
hubo problemas en su mayoría con respecto al proceso de monitoreo
y control, los grupos bajo el modelo tradicional tuvieron atrasos y
cambio en el alcance debido a la dificultad técnica del proyecto de BI.
Desde el inicio de esta fase se fomento el control por parte del Jefe de
proyecto y flujo de los informes de avances dentro del equipo del
proyecto.

52

Tabla 4 – Evaluación del grado de cumplimiento de los ítems claves del proyecto de BI.
Modelo tradicional de BI
G1:PH

G2:SQLS

OpenUP Extendido

G3:MStr G4:Oracle Prom.

G1A:PH G2A:SQLS G3A:MStr G1B:PH G2B:SQLS G3B: MStr G4B:Oracle G5B: MStr Prom.

Gestion
Formación del project charter
Control de los formatos
Control del tiempo
Control del alcance del proyecto

2
1
1
1

2
3
3
3

2
3
3
2

1
1
1
1

1.75
2.00
2.00
1.75

2
3
3
2

3
3
2
3

3
3
3
3

2
3
3
3

3
3
2
3

3
3
3
2

1
3
1
1

1
3
1
1

2.25
3.00
2.25
2.25

Requerimientos
Control de los requerimientos
Control de los formatos

1
0

2
0

2
0

1
0

1.50
0.00

3
3

3
3

3
3

3
3

3
3

3
3

1
3

1
3

2.50
3.00

Arquitectura
Modelo de casos de uso
Modelo Conceptual
Modelo Dimensional
Modelo Físico
Formato del Meatadato Fuente
Validación de la Arquitectura

0
0
3
3
2
0

0
1
3
3
3
0

0
1
3
3
3
0

0
0
1
1
1
0

0.00
0.50
2.50
2.50
2.25
0.00

2
2
3
3
3
3

2
1
3
3
3
2

2
2
3
3
3
3

2
2
3
3
3
2

3
0
3
3
3
2

2
2
3
3
3
3

0
0
1
1
1
1

1
0
2
2
2
2

1.75
1.13
2.63
2.63
2.63
2.25

Desarrollo
Modelo multidimensional
Reportes
Configuración de la impl.
Validacion de los avances

3
0
0
0

3
3
1
0

3
1
1
0

1
0
0
0

2.50
1.00
0.50
0.00

3
2
1
2

3
2
1
2

3
3
1
2

3
2
1
2

3
3
1
2

3
3
1
2

1
1
0
0

1
1
0
0

2.50
2.13
0.75
1.50

53

B) Requerimientos

El tiempo de aprendizaje o adaptación en la ejecución del proyecto
fue más rápido. De los grupos bajo el modelo tradicional y los que
aplicaron el OpenUP para BI sufrieron un atraso en la fase de análisis
o de elaboración especialmente por identificar los indicadores
apropiados para una solución de BI. En cambio en el proceso de
adaptación y ejecución de los procesos, se notó que en la fase de
análisis del grupo bajo el modelo tradicional fue más lento debido a
que hubieron confusión de roles o funciones. Se resalta que los
grupos bajo el modelo tradicional tendieron a un desarrollo en base a
las fases del desarrollo del Software, la cual demuestra una tendencia
común en el entorno de trabajo real.

 Para este ítem los grupos que aplicaron el OpenUP para BI tenían la
ventaja de utilizar los formatos definidos. Un documento importante
que ayuda es el Documento de Visión, se realizó un trabajo en
conjunto para que todos reciban la misma información, toda la
información y experiencia del proyecto previo fue impartida en este
momento, cada grupo desarrollo su documento de Visión, en el Anexo
3 se muestra el documento completo. El siguiente documento que se
generó y que corresponde a esta fase es el de los Requerimientos, en
el Anexo 4 se muestra uno de los documentos generados. Además en
el anexo 6 y 7 se muestra como ejemplo de las entrevistas realizada
por los alumnos.
C) Arquitectura

El proceso de validación de la arquitectura ayudó mucho a los grupos
que aplicaron el OpenUP para BI, la cual permitió que los entregables
generados sean validados y corregidos durante el periodo. Los grupos
bajo el modelo tradicional y algunos grupos que aplicaron el OpenUP
para BI pero no correctamente el proceso de validación, tuvieron que
esperar hasta el control de avance, realizado por mi persona, para
54

recién notar las correcciones que debían hacer, esto provocó atrasos
en el proyecto.
 Como se

muestra en el anexo 8, los proyectos que aplicaron el

OpenUP para BI lograron representar en el Documento de
Arquitectura el sistema en Casos de Usos, diagrama dimensional,
diagrama físico y el Metadata fuente. La fase de elaboración fue la
que tuvo más duración. El asunto de esta prolongación fue de
comprender los indicadores propios de una solución de Inteligencia de
Negocios, sus componentes y todo lo que implica. Al finalizar la fase
de elaboración se cumplió con el proceso de validación del
Documento de Arquitectura.
D) Desarrollo
 El control de los cambios se manejo adecuadamente en la mayoría de
los grupo que aplicaron el OpenUP para BI, por ejemplo cuando se
debía realizar algún cambio en el código del ETL donde requería
agregar un campo más en la tabla del DW, el Desarrollador sabía que
tenía que modificar su código, el Analista procedía a realizarlo en sus
respectivos diagramas, el Arquitecto procedía a validar con la
coherencia de la Arquitectura propuesta y el jefe de proyecto se
encargaba de controlar los tiempos adecuados de modificación y de
comunicar los cambios a la persona correspondiente. En cambio en
los grupos bajo el modelo tradicional no se observó esta forma de
trabajar.

Los equipos que utilizaron las herramientas de SQLServer2005,
Pentaho, aplicaron la ventaja y facilidad de la herramienta para el
desarrollo del ETL, en el anexo 11 se muestra como ejemplo el uso de
las herramientas correspondientes para el ETL, cubos y reporte. Los
equipos que utilizaron la herramienta MicroStrategy, desarrollaron el
ETL con código PL/SQL de Oracle debido a que la Base de Datos de
PU esta con el Gestor de Base de Datos de Oracle 10g y además
55

porque la herramienta de MicroStrategy no presenta este módulo, en
el anexo 10 se muestra como ejemplo el código en PL/SQL. Los
equipos que utilizaron la herramienta de Oracle también decidieron
desarrollar el ETL con código PL/SQL en este caso por la dificultad de
entender la herramienta de Oracle por parte de ellos.

En esta fase se logró la ejecución satisfactoria del ETL en la mayoría
de los equipos de proyecto, durante este proceso se tuvo que afinar
en varias ocasiones el código SQL para optimizar la carga de los
datos al Datawarehouse.

Durante este periodo se preparó a alumnos de 4to año para que
simulen proyectos de auditoría, tales proyectos de auditoría tenían
como objetivo las pruebas en los códigos y procesos del equipo de
proyecto de BI y de esta manera se estaría cumpliendo con el rol
Tester del OpenUP. El equipo de auditoría valido al equipo de
proyecto de BI no solo en lo que propone el OpenUP sino también
con respecto a la Norma Técnica Peruana (NTP) ya sea la 12207 o la
17799, según criterio de equipo de auditoría. En el Anexo 9 se
muestra uno de los documentos generados por el equipo de auditoría.

La figura 10 muestra en resumen que los equipos que aplicaron el
OpenUP para BI tuvieron mejor desempeño y mejor resultado en los
entregables del proyecto dentro del periodo acordado según la
planificación de cada proyecto. Con respecto a la gestión del proyecto,
todos tuvieron un buen desempeño debido a la experiencia previa en
temas de gestión de proyectos, los equipos que aplicaron el OpenUP para
BI tuvieron una ventaja adicional por los formatos y procesos definidos
desde sus inicios.
La mayor ventaja se tuvo en el proceso de análisis, especialmente la
captura de los requerimientos debido a la guía del OpenUP para BI por el
orden e interacción de los roles, formatos y procesos definidos.

56

Figura 10 – Resumen comparativo del la evaluación del grado de cumplimiento de los ítems claves del proyecto de BI.

57

Con respecto a la Arquitectura y Desarrollo notamos que existe un
desempeño menor por todos los equipos, esto es debido a que se aplican
conocimientos nuevos propios de inteligencia de negocios que forman
parte de los entregables tales como Modelo Dimensional, Metadata
Fuente, Desarrollo del ETL, desarrollo del Modelo Multidimensional, entre
otros. Los equipos que aplicaron el OpenUP para BI tuvieron de todos
modos mejor desempeño que los equipos que no lo aplicaron.
Los modelos tradicionales de BI como el OpenUP para BI no son
tutoriales para enseñar a construir una solución de BI, simplemente son
guías de procesos que facilitan el orden de trabajo en los respectivos
proyectos, es por este motivo que notamos una baja del desempeño de
los equipos en la Arquitectura y aun más en el Desarrollo.
El mejor desempeño en la Arquitectura y Desarrollo de los equipos que
aplicaron el OpenUP para BI es debido a la guía adecuada desde la
Gestión de proyecto y Requerimientos. Las buenas prácticas conocidas
con respecto al desarrollo de software respaldan el resultado obtenido
mostrado en la figura 10.

58

CONCLUSIONES
1. La utilización de formatos adecuados permite tener una visión de lo
que se tiene que lograr, Los formatos propios del OpenUP mas las
extensiones realizadas ayudaron a que la persona tenga una noción
de la información que necesita y la información que debe generar.
2. La correcta distribución de las tareas según el perfil del rol que se
desempeña ayuda en la gestión, coordinación, aprovechamiento del
tiempo y la calidad del producto con respecto a los cambios. Además
esta forma coordinada de trabajo ayuda al cumplimiento de los
requerimientos del usuario.
3. Reestructurar el cronograma por iteraciones (logros inmediatos),
permite controlar las tareas y recibir una retroalimentación inmediata,
la cual permite incrementos controlados y validados. Aplicar esta
ventaja del UP en proyectos de BI es adecuado debido además por el
desarrollo por temas.
4. El modelo propuesto es aplicable para proyectos de implementación
de Inteligencia de Negocios, según el alcance de esta investigación,
en soluciones para mediana y pequeñas empresas, esto es factible
debido a la similitud de los procesos de implementación de BI con
procesos de desarrollo de Software.

59

RECOMENDACIONES
1. Se recomienda de un profesional Ingeniero que asegure el
cumplimiento de la metodología. La ventaja de la metodología
OpenUP es que tiene una estructura básica de desarrollo, la cual
permite su adaptación. Con respecto a la calidad, no está muy bien
considerada en esta metodología la cual se requiere la presencia del
rol Ingeniero de procesos para reforzar este asunto, para la ejecución
de los proyectos, el profesor cumplía con este rol.
2. La UPeU debería apostar por esta tecnología, para que esté siempre
competitiva en el entorno de las Universidades que ya cuenta con
esta herramienta como apoyo a las decisiones gerenciales.
3. Se recomienda aplicar este modelo propuesto en cualquier empresa
que desarrolla software y que también se aventura a realizar
proyectos de implementación de BI donde la complejidad o alcance
del proyecto sea baja o media. El tiempo de aprendizaje sería más
rápido y sería la base para entender otras metodologías de
implementación de BI.
4. Para proyectos de mayor envergadura sería bueno analizar el
modelo. Se recomienda roles especiales de control y revisiones
constantes de los avances del proyecto. Además para proyectos de BI
de mayor envergadura es posible apoyarse en los diagramas de caso
de uso del negocio.
5. Se recomienda además como modelo de aprendizaje en institutos o
Universidades con especialidades de Ingeniería de Software, Gestión
de TI, Ingeniería de Sistemas o afines.

60

LISTA DE REFERENCIAS
Alexandre C. 2003. Sistemas de Información en las Empresas: Un modelo
para la Empresa Digital.
http://www.cyta.com.ar/elearn/syma/textos/empresa_digital.htm.
Consultado el 28 de Enero del 2007.

Arson Group. 2005. Datamarting.
http://www.arsongroup.com/PDFs/BICase.pdf. Consultado el 20 de
Mayo del 2009.

Berkel Jan. Datawarehouse; where to locate GIS.
http://gis.esri.com/library/userconf/proc97/proc97/to650/pap650/p65
0.htm. Consultado el 23 de Enero del 2007.
Bernabeu Dario. 2009. Hefesto V1.0.
http://www.redopenbi.com/profiles/blogs/hefesto-v10. Consultado el
20 de Mayo del 2009.
CRISP-DM consortium. 2000. CRISP-DM. http://www.crisp-dm.org/.
Consultado el 20 de Mayo del 2009.
Fernández D. 2004. Business Intelligence. Una herramienta indispensable
para la toma de decisiones.
http://www.improven.com/Documentos/BI.aspx?ind=212&sec=19.
Consultado el 25 de Enero del 2007.
Gloria C. 2002. La Tecnología Datawarehousing.
http://www.inf.udec.cl/revista/edicion3/cwolff.htm. Consultado el 23
de Enero del 2007.

61

Gong L. 2005. Engage your customers in planning the data warehouse
project. http://www128.ibm.com/developerworks/db2/library/techarticle/dm-0506gong/.
Consultado el 26 de Enero del 2007.
Gravitar. 2007. Metodologías Ágiles.
http://www.gravitar.biz/index.php/bi/metodologias-agiles-intro/.
Consultado el 26 de Enero del 2008.
Grupo Bimbo. 2007. Reporte Anual 2006.
http://www.grupobimbo.com/relacioninv/uploads/press/BIMBO%20
Reporte%20Anual%202006.pdf. Consultado el 10 Octubre 2007.
Hadley L. 2002. Data Warehouse Quality Managemen.
http://www.users.qwest.net/~lauramh/resume/dwqual.htm.
Consultado el 23 de Enero del 2007.
Henderson D. PERFORMANCE MEASUREMENT:
THE DATA WAREHOUSE SUPPORTS
BEST PRACTICES. http://www.tdan.com/i010ht03.htm. Consultado
el 23 de Enero del 2007.
Herrera Edwar. 2007. Diseñando un modelo de inteligencia de negocios
con UML.
http://sites.google.com/site/eherrerao902/BorradorAvanzado.pdf.
Consultado el 20 Diciembre del 2008.
Hiperion-Developer Network. 2002. The Role of OLAP in the Corporate
Information Factory.
http://dev.hyperion.com/resource_library/articles/corporate_informat
ion_factory.cfm. Consultado el 23 de Enero del 2007.

62

Horsburgh.com. 2000. Data Warehouse Design.
http://www.horsburgh.com/h_dataw.html. Consultado el 26 de
Enero del 2007
INEI. Manual de Construcción de un Data Warehouse.
http://www.inei.gob.pe/biblioineipub/bancopub/Inf/Lib5084/152.HTM
. Consultado el 23 de Enero del 2007.
Intelligent Enterprice. 2000. The Missing Link.
http://www.intelligententerprise.com/010416/strategic1_1.jhtml.
Consultado el 23 de Enero del 2007.
Intelligent Enterprice. 2004. BI Scorecard: OLAP.
http://www.intelligententerprise.com/print_article.jhtml?articleID=195
02190. Consultado el 23 de Enero del 2007.
Kimball University. 2009. Design Tip #115 Kimball Lifecycle in a Nutshell.
http://www.ralphkimball.com/html/09dt/DT115KimballLifecycleNutsh
ell.pdf. Consultado en Diciembre del 2009.
Ladley John. 2002. Beyond the Data Warehouse: Affecting Business
Change. http://www.dmreview.com/article_sub.cfm?articleId=5300.
Consultado el 23 de Enero del 2007.
Larissa Moss. 2002. Business Intelligence Roadmap .
http://www.information-management.com/issues/20020201/46081.html. Consultado el 22 de Enero del 2008
Lewis C. 2006.Learn Data Warehousing: Data Warehouse Schedule.
http://blogs.ittoolbox.com/oracle/guide/archives/learn-datawarehousing-data-warehouse-schedule-12020. Consultado el 26 de
Enero del 2007
63

Mohanty S. 2004. Beyond Monitoring - Measuring the Effectiveness of a
Data Warehouse.
http://www.datawarehouse.com/article/?articleid=4812. Consultado
el 23 de Enero del 2007.
Eclipse. 2007. OpenUP. http://epf.eclipse.org/wikis/OpenUP/Consultado el
10 de Enero del 2007.
Oracle University. 1999. Data Warehouse Database Design.
Oracle. 2006. Oracle Data Warehousing.
http://www.oracle.com/solutions/business_intelligence/dw_home.ht
ml. Consultado el 23 de Enero del 2007.
PACIS. 2007. La Industria del Software Como Oportunidad de Desarrollo
para el Perú. Publicación del Programa de Apoyo a la
Competitividad de la Industria del Software – PACIS. Págs. 88-90
Penn Computing. 2007. How the Data Warehouse Works.
http://www.upenn.edu/computing/da/dw/howwork.html. Consultado
el 23 de Enero del 2007.
PESG. 2000. A Complete DW/BI Project Life Cycle Roadmap.
https://pesg.com/view_seminar/?id=37. Consultado el 20 de Mayo
del 2009.

Prentice Hall. 2006. Executive Information Systems Don’t Count.
http://www.phptr.com/content/images/0130325848/samplechapter/0
130325848_ch01.pdf. Consultado el 23 de Enero del 2007.

64

Ralph Kimball. 1996. Factless Fact Tables.
http://www.dbmsmag.com/9609d05.html. Consultado el 23 de
Enero del 2007.
Ralph Kimball. 1998. Help for Hierarchies.
http://www.dbmsmag.com/9809d05.html. Consultado el 23 de
Enero del 2007.
Rensselaer. 2005. Rensselaer Data Warehouse Project.
http://www.rpi.edu/datawarehouse/dw-project-plan.html. Consultado
el 26 de Enero del 2007.
SQLMax. 2001. Data Warehousing. http://www.sqlmax.com/dataw1.asp.
Consultado el 23 de Enero del 2007.
Swensson, C. & Sederblad, B. DATA WAREHOUSE - A NEW TOOL IN
EXTENSION SERVICE TO SWEDISH MILKPRODUCERS.
http://www.dina.dk/efita-conf/program/paperspdf/vii_c_3.pdf.
Consultado el 23 de Enero del 2007.
Universidad EAFIT. 2006. ADAPTACION DE UNA METODOLOGIA DE
INTELIGENCIA DE NEGOCIOS A UNA EMPRESA
DESARROLLADORA DE SOFTWARE.
http://bdigital.eafit.edu.co:8080/bdng/query/single.xsp?id1=EAFITP
005.12CDO775. Consultado el 20 de Mayo del 2009.
University of Maryland. 2006. What is the University of Maryland Data
Warehouse?.
http://www.oit.umd.edu/units/dataadmin/DataWarehouse/GenInfo/b
ackgrd.html. Consultado el 23 de Enero del 2007.

65

ANEXOS

66

Anexo 1: Project Charter del proyecto previo considerado para esta
investigación.

Prototipo de Solución de Business Intelligence y
optimización de Base de Datos para Productos Unión

67

Objetivo del proyecto
1.1. General
 Implementar una solución de Business Intelligence (BI) como
prototipo en el área de ventas de Productos Unión (PU).
1.2. Específico
 Proponer mejoras en la Base de Datos operacional de PU.
 Crear una Base de Datos en Desarrollo replicada y optimizada
para PU.
 Aplicar tecnología actual en solución de BI.
 Generar Reportes útiles para la toma de decisión Gerencial de
PU.
2. Beneficios
 El Sistema (por ser un prototipo) servirá para que las Gerencias
respectivas decida si conviene invertir en esta determinada
tecnología.
 La Gerencia de Ventas podrá tener la información del
comportamiento de las ventas y su detalle al día siguiente. Así
como el comportamiento de las ventas por periodos, zonas,
canales de ventas.
 La Gerencia de Ventas podrá generar reportes personalizados
sin necesidad de depender del área de sistemas.
 La información se presenta en forma gráfica en los reportes,
según el criterio del gerente.
 El Sistema mostrará tendencias de las ventas la cual ayudará a
que se tomen correctas decisiones a nivel gerencial en el área
de ventas.
 Los reportes se podrán visualizar desde cualquier parte debido
a su entorno Web y con control de acceso.
 La Base de Datos a nivel operacional será más segura y
trabajará con eficiencia.
 Al tener una Base de Datos de Desarrollo se podrá probar
alguna implementación en ella antes de tocar los datos reales
de PU.
3. Factores críticos de éxito
 Compromiso de las autoridades de las empresas involucradas con
respecto a los procesos y formatos.
 Buena comunicación dentro del proyecto.
 Contar con las herramientas necesarias para lograr un buen desarrollo de
esta etapa.
68

4. Recursos y tiempos
4.1. Personal asignado al proyecto
Recursos Humanos
Cant Unidad Tiempo
Jefe de Proyecto
Sergio Valladares
1
Hora
60
Analista Funcional Lizeth Huanca
1
Hora
60
DBA Junior
Roberto Bustamante
1
Hora
60
DBA Junior
Alumno 3 - 5 año
2
Hora
60
Equipos
Servidor de BD
PCs

1
5

1
1

Software
SQLServer 2005 E.S.
BD Oracle 10g

1
1

1
1

Nota:
 Los Softwares a utilizar están ya bajo licencia y el de Microsoft con
acuerdo para uso académico y para el prototipo.
 Las PCs son de uso común de las personas asignadas por las respectivas
áreas.
 El Servidor está ya comprado y listo para ser utilizado en el CIDS.

69

4.2. Tiempos
Id

Nombre de tarea

Nombres de
los recurs os

Dur ación

1

Analisis de la BD actual de PU

JP,A F

2

Capacitac ion

AF,JP,DBA J

08 abr '07
15 abr '07
22 abr '07
29 abr '07
06 may '07
13 may '07
D L M X J V S D L M X J V S D L M X J V S D L M X J V S D L M X J V S D L M X J V S
JP,AF
2 días
AF,JP,DBAJ
2 días

3

Analisis de la BD mejorada

JP,A F

2 días

4

Creacion de la BD mejorada

DBA J

1 día

5

Exportacion de datos

DBA J

2 días

DBAJ

6

Analsis BI para Ventas (estr uctura)

JP,A F

2 días

JP,AF

7

Capacitac ion BI

JP,A F,DBA J

8

Creacion de BD y ETL de datos

DBA J

5 días

DBAJ

9

Analisis BI para Ventas (cubos)

JP,A F

5 días

JP,AF

10

Analisis BI para Ventas (Reportes)

JP,A F

7 días

JP,AF

11

Implementacion (cubos , reportes)

DBA J

7 días

DBAJ

12

Pruebas f inales

JP,A F,DBA J

13

Doc umentacion

JP,A F

22 días

14

Presentac ion PU-FI

JP,A F

1 día

15

Presentac ion UPeU

JP,A F

1 día

JP,AF
DBAJ

JP,AF,DBAJ

1 día

JP,AF,DBAJ

1 día

JP,AF
JP,AF
JP,AF

70

Anexo 2: Plan de proyecto de uno de los grupos que utiliza OpenUP para
BI.
Sistema de Información Gerencial para Productos Unión
Plan del Proyecto

1. Introducción.
Desde la compra de los insumos, el proceso de producción y
estrategias de ventas así como la relación con los clientes y el
personal debe estar controlado. Es necesario que la información,
generada en estos procesos, llegue ya transformada a la gerencia de
Productos Unión (PU), de tal modo que permita conocer su progreso y
tendencia.
PU es un Centro de Aplicación, donde el estado limita el volumen
de ventas a PU, esto significa que el mercado conseguido debe ser
estratégicamente conservado. PU no cuenta con una herramienta de
información completa que permita recoger información desde los
proveedores, el proceso de producción y las ventas, también carece
de

herramientas

de

información

que

permita

representar

el

comportamiento y tendencias de estos procesos.
El sistema actual no cubre todas las áreas necesarias de PU y
además sus datos no son confiables, existe redundancia de los datos,
la estructura de la mayoría de sus tablas no permite relacionarse e
incluso existe datos innecesarios por registro que ocupan demasiado
espacio. Es necesaria muchas veces la intervención directa en la base
de datos del personal de sistema de PU para poder depurar la data y
presentar reportes a la gerencia de PU, forzando a utilizar el tiempo en
trabajos adicionales en búsqueda, corrección y presentación de la
información a la gerencia.
La intención del proyecto es lograr la implementación parcial de un
sistema de Inteligencia de Negocios (BI) con el fin que PU conozca de
esta herramienta y por ende vea la necesidad de implementar la
71

solución completa, esta herramienta de Inteligencia de Negocios que
será de mucha ayuda para la toma de decisiones a nivel gerencial.

2. Organización del proyecto.
Personal

Roles

Descripción

Castro Mendoza,
José

Jefe de proyecto

Responsable y encargado de la gestión del
proyecto

Orihuela Cornejo,
Carlos

Ingeniero de
procesos

Responsable del seguimiento y control del
cumplimiento de la metodología Open Up.

Villena García, Jorge

Analistas

Experto de Base de Datos y conocedor del
negocio

Desarrolladores

Experto en Base de Datos y herramientas de
BI y encargado de generar reportes
encargados en el proyecto

Arquitectos

Experto en los aspectos técnicos sobre el
proyecto.

Lévano Rodríguez,
Michael
Lévano Rodríguez,
Michael

Tuco Calizaya, Fredy

Ramos Sambrano,
Manuel
Valdez Jara, Edgar

Propone la herramienta con la cual se
trabajará.

3. Medidas y prácticas del proyecto.
3.1. Planificar el proyecto de investigación en base a la
metodología Open Up.
Este ítem considera todo el estudio previo a considerar para
que lo que se determine hacer esté conforme a lo que propone la
metodología Open Up y su respectiva adaptación a los procesos

72

propios de la tecnología de BI y considerando los siguientes
puntos:
 La utilización de la herramienta de BI como es el Pentaho.
 Proceso de ETL.
 La utilización del lenguaje SQL.
 Los intervalos de ejecución (pensando en PU).
 Conocer los temas o áreas a implementar.
 Cantidad de reportes.
 Costo.
 Tiempo.
 Calidad.
3.2. Analizar los requerimientos y entender el negocio.
El método que se realizara para captar los requerimientos es
el de realizar entrevistas con el gerente de PU o con el jefe del
programa que están involucrados en la solución del BI y también
se realizará una revisión de la BD Operacional actual, revisión de
reportes generados por PU, análisis de los requerimientos y
representación del diagrama de casos de uso para un mejor
entendimiento del negocio. El Gerente General delimitará el
ámbito de la investigación.
3.3. Análisis y diseño del sistema actual y de la propuesta.
 Modelo de BD actual.
 Modelo de base de datos optimizada.
 Modelo de base de datos del DW.

Se dividirá en tres módulos:

73

Módulo de registro de datos (si es necesario), se analizará el
modo y la estructura del software que permitirá el ingreso de
datos que no se encuentren en la BD operacional y que es
necesario para la gerencia de PU.

Módulo Data Warehouse, se diseñará la arquitectura que
tendrá el Data Warehouse incluyendo el proceso ETL.

Modulo de BI, se realizará el diseño de la estructura de los
cubos y la estructura de los reportes necesarios para la
gerencia.

3.4. Construcción del módulo registro de datos.
De acuerdo al análisis aprobado por los líderes de usuarios,
se empezará a construir el módulo. El módulo será probado y
aprobado antes del desarrollo del módulo de Data Warehouse.

3.5. Construcción del módulo Data Warehouse.
Inicialmente se instalará y configurará los servidores
necesarios para el sistema. El desarrollo será dividido por submódulos, cada fase se encargará de un número específico de
“temas”

priorizados,

basándose

en

estándares

existentes

mediante el proceso ETL.
3.6. Construcción del módulo de BI.
 Generar los cubos según los temas.
 La generación y ejecución de los reportes por cada tema.

74

3.7. Transición.
Aprobado el sistema, se procederá a implementar los
módulos listos para su funcionamiento por los interesados.
También se gestionará la aplicación de las reglas, políticas,
procedimientos propuestos para el buen funcionamiento del
sistema.

3.8. Medidas.
El control exhaustivo que se realizará se harán en base a las
normas técnicas peruanas: 12207 la parte de Software y 17779 en
asuntos de seguridad con TI, así como el resultado del producto
de BI.

75

Inicio

Entender al
negocio

Fechas

Iteración

Fase

I
1
I
2

I
3

Objetivos primarios

Plan del proyecto aceptado

16/03/09

27/03/09

Requerimientos detallados.
- Entrevista
- Revisión BD Operacional
- Revisión Reportes
Análisis de los requerimientos.
Optimizar el modelo de BD operacional
- Diseñar el modelo BD actual
- Diseñar el modelo BD optimizado
Plan ETL
- Mapeo de los datos.
- Algoritmo / Diagrama del ETL
- Metodología de Transformación de
datos.
Crear el modelo para el DW
- Diseñar el modelo de la BD del DW.
- Control de crecimiento del DW.
Diagramas de CU sobre aplicaciones
complementarias

30/03/09
30/03/09
02/04/09
13/04/09
15/04/09
22/04/09

21/04/09
01/04/09
10/04/09
21/04/09
21/04/09
01/05/09

22/04/09
01/05/09
04/05/09
04/05/09
07/05/09
12/05/09

24/04/09
07/05/09
14/05/09
06/05/09
11/05/09
14/05/09

04/05/09
04/05/09
07/05/09
05/05/09

08/05/09
06/05/09
08/05/09
07/05/09

Optimizar el modelo de BD operacional.
- Finalizar el modelo BD optimizado.
Plan ETL.
- Diagramas de DW.
- Actualizar el mapeo de datos.
Crear el modelo para el DW.
- Finalizar el modelo de la BD del DW.
- Control de crecimiento del DW.

08/05/09

11/05/09

08/05/09
13/05/09
13/05/09
19/05/09
20/05/09
20/05/09
20/05/09
27/05/09

11/05/09
26/05/09
20/05/09
26/05/09
20/05/09
20/05/09
20/05/09
03/06/09

04/06/09
12/06/09
22/06/09

11/06/09
19/06/09
29/06/09

30/06/09

07/07/09

08/07/09

08/07/09

08/07/09

08/07/09




I
4



Construcción

Implementación

Transición
Final

I
5

I
6





I
7
I
8

Fin

Elaboración

Inicio


Implementación de la BD y DW en
desarrollo
Ejecución satisfactorio del ETL
Creación del MOLAP
Tener los reportes adecuados según
área de interés en PU
Implementación en desarrollo de
formularios complementarios
Validaciones del usuario final
Documento final del análisis de los
resultados y propuesta del modelo

76

Estimación
en días

4. Objetivos e hitos del proyecto por iteración.

10

17

12

13

18

12
1
1

Anexo 3: Documento de Visión de uno de los grupos que utiliza OpenUP
para BI
Modelo de un BI utilizando Open Up
Visión

Fecha: 09/02/2009

Modelo de Sistema de Información Gerencial Basado en Business
Intelligence para la Industria de Panificación, utilizando la
metodología Open Up

Visión
1. Introducción
Productos Unión (PU) fue creado en 1919 como Centro de
Aplicación del Colegio Unión (hoy Universidad Peruana Unión).
Productos

Unión

tiene

como

misión

producir

alimentos

que

contribuyan al mejoramiento y conservación de la salud; y como parte
integral de la Universidad Peruana Unión, apoyar en el desarrollo de
la educación cristiana.

Por ser un Centro de Aplicación, el Estado limita el volumen de
ventas a PU, esto significa que el mercado conseguido debe ser
estratégicamente conservado. PU no cuenta con una herramienta de
información completa que permita recoger información desde los
proveedores, el proceso de producción y las ventas, también carece
de

herramientas

de

información

que

permita

representar

el

comportamiento y tendencias de estos procesos. Además los datos
no son confiables, existe redundancia de los datos, la estructura de la
mayoría de sus tablas no permite relacionarse e incluso existe datos
innecesarios por registro que ocupan demasiado espacio.
77

Existe en el Perú un aproximado de 28 empresas, nacionales e
internacionales, casi con el mismo rubro de PU de las cuales el Grupo
BIMBO utiliza sistemas de información automatizados tanto a nivel
operativo como gerencial que le permite competir y crecer a nivel
mundial. Desde el año 2005 cuentan con una solución de negocio
integrada por un sistema de tipo ERP (Enterprise Resource Planning),
también el 2005 implementaron una solución para el área de ventas
usando tecnología de Inteligencia de Negocios (BI) y Datawarehouse
(DW). Para competir con estas empresas PU debe invertir en
tecnología para poder crecer y conservarse en el mercado.

2. Posicionamiento
2.1 El problema
El problema
afecta
el impacto es

Una solución factible es

Se tiene información que no es
confiable, redundante
A la áreas de Producto Unión
relacionadas con la
comercialización de sus productos
La decisiones tomadas a nivel
gerencial se basan en experiencias
personales y no está respaldada en
el análisis de la información que se
produce al no ser confiable
La utilización de un sistema de
Inteligencia de Negocios

78

2.2 Posicionamiento del producto
Para

Productos Unión

quien

Necesita reordenar, depurar y procesar la
información generada y que sirva de apoyo en
las decisiones gerenciales

El “BI-Open Up”

Es una herramienta de Inteligencia de Negocios
que ayuda en la toma de decisiones a nivel
gerencial

que

Permitirá centralizar los datos necesarios y
presentarlos en formatos entendibles y
manejables según la necesidad de análisis que
se requiera en el momento

En vez de

El análisis en base a datos no confiables,
redundantes que no ayudan mucho en la toma
de decisiones a nivel gerencial

Nuestro producto

Permitirá lo siguiente:

79

Centralización y depuración de los
datos necesarios para la toma de
decisiones a nivel gerencial.

Explotación rápida de los datos según
necesidad del análisis del momento.

Ser una herramienta manejable por
los gerentes de área.

Tener opciones de pronósticos y
tendencias

Acensar desde cualquier punto por
ser en entorno Web

Anexo 4: Documento de Requerimientos de uno de los grupos que utiliza
OpenUP para BI
SISTEMA DE INFORMACIÓN GERENCIAL PARA
PRODUCTOS UNIÓN

ESPECIFICACIÓN DE LOS REQUERIMIENTOS DEL SISTEMA
Introducción
En el presente documento se mostrará los requerimientos funcionales y
no funcionales capturados gracias a la entrevista realizada.

Requerimientos funcionales del sistema
 Confiabilidad en los datos almacenados.
 Reordenar, depurar y procesar la información generada y que sirva de
apoyo en las decisiones gerenciales
 Contar con reportes que ayuden a la toma de decisiones de acuerdo al
área de la Empresa.
 Tener un control de las compras y las ventas.
 Tener una buena seguridad de la información.
 Acceder a la información desde cualquier parte.
 Tener opciones de pronósticos y tendencias.
Cualidades del sistema
Usabilidad
 Cada usuario solicita diferentes comportamientos.
 Falta de coordinación entre áreas diferentes que usan el mismo
sistema.
 Diferencia de puntos de vista (prioridades) entre los usuarios.
 La capacitación para usuarios que harán uso del sistema será por fechas
establecidas según los roles que desempeñan.
Fiabilidad
 Las horas de operación para la transacción de información serán las 24
horas del día, pero a la vez se realizarán el mantenimiento respectivo para
eso se tomarán un día para el respectivo mantenimiento.
 El tiempo medio para reparación en caso de falla es de 30 minutos.
80

 El porcentaje de errores o defectos es categorizado por errores menores
(demora de respuesta en los reportes), significantes (impedimento de
realizar reportes por días, meses o años) y críticos (pérdida completa de
datos o imposibilidad de uso de ciertas funcionalidades del sistema).
Performance
 El acceso del usuario al sistema tiene como máximo 5 segundos.

Los tiempos de emisión de reportes que solicite el usuario será de cómo
máximo 1 minuto, dependiendo el tipo de reporte a solicitar.

Esta aplicación permitirá a 300 usuarios conectarse simultáneamente para
hacer alguna operación entre las 9:00 am y 11:00 am.

El tiempo en el cual los usuarios pueden acceder a la herramienta son las
24 horas.

Suportabilidad
Adaptabilidad: El sistema a desarrollar se adapta de acuerdo a los
requerimientos planteados por el usuario final así como también se
adapta al entorno de trabajo donde se empleará.
 Compatibilidad: La compatibilidad del uso de este sistema debe de ser
compatible con los sistemas operativos que trabajan o emplean en el
ámbito, para evitar problemas al momento de dar uso el sistema.
 Configurabilidad: Antes de utilizar o llevar a cabo la ejecución del sistema
de debe configurar para evitar conflictos al momento de la aplicación.
 Instalacion: Declare cualquier requerimiento especial en cuanto a la
instalación de sistema.

System compliance
 Requerimientos
Pentium 400MHz
512MB memory
1GB disk space
Windows NT Server 4.0 sp5 or newer
Microsoft Internet Information Server version 4.0 or newer
Internet Explorer version 4.01 sp1 or newer
Microsoft or compatible ODBC driver
 Precio
Costo licencia : $6,580 (plus 18% mantenimiento)
Incluye:
MicroStrategy Intelligence Server (Standard Edition) a $295 por
usuario
MicroStrategy Desktop Analyst a $995 por usuario
MicroStrategy Architect a $4,995 por usuario (clients tipicamente
necesitan una herramienta arquitectura para 100 usuarios)
81

Anexo 5: Plan de iteración de uno de los grupos que utiliza OpenUP para
BI
Sistema de Información Gerencial para Productos Unión
Plan de Iteración – G4
Hitos
Hito

Fecha

Inicio de la Iteración

15/05/2009

BD Optimizada o intermedia

27/05/2009

Documento de la Arquitectura

28/05/2009

Termino de la Iteración

29/05/2009

Objetivos de alto nivel
 Diseñar el modelo BD optimizado
 Diseñar el modelo DB para el DW.
Asignación de ítems de trabajo
Nombre /
Descripción

Prioridad

Documento
de
referencia

Asignado a

Esfuerzo
Estimado
(horas)

Estado

Horas
trabajadas

Entrevistar a la
Ing. Lizeth
Huanca
Diseñar el
modelo del
negocio
Diseñar el
modelo físico
Controlar el
crecimiento del
DW

1

Audio:
AUD002.amr

Jorge
Sihuacollo

3

Terminado

1

1

Documento
ARQ003.doc

Juan Carlos
Pampa

5

Terminado

3

1

Documento
ARQ003.doc

8

Terminado

5

10

Avanzado
(75%)

8

Actualizar la
lista de
Riesgos
Refinar la
arquitectura
Actualizar
informe de
control de
Actividades

2

Documento:
RISK004.doc

Juan Carlos
Pampa
Aaron
Bocanegra/
Jorge
Sihuacollo
Remy
Yactayo

2

Terminado

1

1

Documento:
ARQ003
Documento:
CONT004

Jorge Jack
Sihuacollo
Aaron
Bocanegra

8

Terminado

5

5

Terminado

3

1

2

82

Anexo 6: Entrevista realizada como parte del rol analista.
ENTREVISTA

Jueves 18 de Junio del 2009

Entrevista con la analista funcional de Productos Unión
Nombre Entrevistado: Ing. Lizeth Huanca
Los temas a tocar fueron:
1- ¿Para saber que producto están en venta y el precio que tiene, a que tablas
entramos?
Entramos a la tabla política, poliprod, almacén artículos.
Esta tabla solo me va dar el detalle de los productos que tiene esa política pero
no me da la cantidad que se esta vendiendo.
En ningún lado se esta guarda cantidad de producto que se esta vendiendo y
que productos se esta vendiendo todo esto se guarda en la tabla Pu_reprod.
2 - ¿Respecto la cantidad de productos entra a almacén y los productos
devueltos?
Cuando ingresa productos al área de producción se hace a través de la tabla
almacén ingresos diversos a quien se va registrar el números de documentos que
tiene esos ingresos y los productos, cantidad. Los Ingresos se van a almacén y la
salida por las ventas, también a la tabla Pu_guias.
3- ¿Como miden la productividad según lo que hemos leído de productividad
es productos buenos entre la cantidad de productos vendidos, se puede sacar
todos los productos buenos producidos?
Todos los productos, o Casi todos los productos tienen 2 tipos el bueno, y el
saldo en la tabla Id articulo por ejemplo de pan fibra que es bueno, y otro id_
articulo de pan fibra saldo

83

Anexo 7: Entrevista realizada como parte del rol analista.
EVIDENCIAS DE AVANCE
SISTEMA DE INFORMACION GERENCIAL PARA PRODUCTOS UNION
Autor: Juan Carlos Pampa – Estudiante UPeU
I. RESUMEN DE AVANCES
 Entrevista con el encargado del Área de Gestión de la Calidad
de Productos Unión, Ing. Eduardo Meza, para conocer los
requerimientos del sistema
II. CUADROS DE RESULTADOS
OBJETIVOS

RESULTADO
ESPERADO

Entrevista al
Entrevista
Ingeniero Eduardo realizada con éxito
Meza de PU

ESTADO DE
AVANCE
100%

INDICADOR
VERIFICABLE
ESPERADO
Requerimientos
del Sistema

OBSERVACIONES

Ninguna por
notificar

III. DIFICULTADES
OBJETIVO

Entrevista al
Ingeniero
Eduardo Meza de
PU

DIFICULTAD

ALCANCE

PLAN ALTERNO

Tiempo

Prioridad

-

-

Ninguna por
notificar

84

Ninguno por
notificar

Anexo 8: Documento de Arquitectura de uno de los grupos que utiliza
OpenUP para BI
SISTEMA DE INFORMACIÓN GERENCIAL BASADO EN
BUSINESS INTELLIGENCE
MICROSOFT SQL SERVER 2005
1. Propósito del proyecto
El proyecto informático que implementaremos, es un sistema de
información basado en Bussines Intelligence utilizando la metodología de
desarrollo de Software Open Up con el fin de que la Gerencia de PU
conozca y pueda elegir la alternativa adecuada para su implementación
completa en un proyecto próximo de naturaleza netamente informática.
Además con el apoyo de este sistema de información, se podrá competir
con empresas grandes con estrategias basadas en la calidad de la
información obtenida, por ende, ayudará a incrementar el mercado ya
ganado por Productos Unión.
2. Metas y filosofías de la arquitectura
SQL Server 2005 es una plataforma global de base de datos que ofrece
administración de datos empresariales con herramientas integradas de
inteligencia empresarial (BI). El motor de datos SQL Server 2005
constituye el núcleo de esta solución de administración de datos
empresariales. Asimismo, SQL Server 2005 combina lo mejor en análisis,
información, integración y notificación, permitiendo así que el negocio
cree y despliegue soluciones de BI rentables que ayuden al equipo a
incorporar datos en cada rincón del negocio a través de tableros de
comando, escritorios digitales, servicios Web y dispositivos móviles. En
resumen, SQL Server 2005 está diseñado para ayudar a las empresas a
enfrentar desafíos tales como: La necesidad de tomar decisiones más
rápidas y más orientadas a datos.

85

3. Asunciones y dependencias
Estas suposiciones y dependencias respecto del sistema se derivan
directamente de las entrevistas con el Stakeholder, las cuales son:
 Productos Unión trabaja con la licencia académica de SQL 2005
en su sistema de planillas.
 Productos Unión trabaja con la licencia de Oracle 10g. Su base de
datos operacional esta en Oracle, por ende dependemos de ella.
 Asignación y disponibilidad del personal de sistemas para las
actividades del proyecto.
4. Requerimientos a cubrir con la arquitectura
1.1 Datos Confiables:
El sistema debe de permitir la integración de diferentes fuentes de datos,
y que sean datos confiables. Para lograrlo se debe de reestructurar los datos
ya almacenados, depurar los datos que sean necesarios y crear una
Datawarehouse.
1.2 Reportes:
El sistema debe permitir la entrega de reportes con vistas interactivas que
proporcionen valiosa información para que ayuden en el proceso de análisis
para la toma de decisiones. De manera tal que dichos reportes (información)
lleguen cuando se requiere. Estos reportes se generarán a través de la
herramienta de Business Intelligent (BI).
Entre los reportes requeridos en PU, captados a través de las entrevistas
realizadas, se encuentran:
 Las variables que desean medir principalmente se encuentra en el
área de Ventas, tales como:
1. Cuánto porciento debe aumentar la producción para la
campaña navideña según las ventas de las últimas tres
campañas.
Son de vital importancia, ya que a través de estos datos
estadísticos se podrá prever la cantidad de insumos y personal
a utilizar
2. Según las ventas anteriores de las campañas, ¿Cuántos es la
tendencia de ingreso de los alumnos a cada campaña
(Verano, Otoño, Invierno y Navideña)?
86

3. ¿Cuán es el porcentaje de los productos más solicitados por
alumnos en cada campaña?
4. De los productos ya vendidos a los supermercados, ¿Cuál es la
tendencia de devolución del total de los productos
entregados en los últimos cuatro años?
5. ¿Cuál es la tendencia de las ventas por Bloques, Políticas,
Clientes y Subclientes de los últimos tres años?
6. ¿Cuál es la tendencia de los productos más vendidos, según
su bloque, política, cliente y subcliente de los últimos tres
años?

1.3 Acceso a la información:
El acceso a la información de debe de realizar desde cualquier parte, es
decir debe de estar realizado en entorno WEB.
5. Decisiones, restricciones, y justificaciones
Se optó por esta herramienta por sus propiedades, tales como:
 Servidor de base de datos, de gran rendimiento.
 RDBMS que pueden ser instalados tanto en sistemas de usuarios como
Windows XP, máquinas de multiprocesador de 64 bits, redes de
ordenadores.
 La administración se facilita mediante interfaz gráfica de usuario.
 Capaz de tener varias instancias del servido en una única máquina.
 Acceso directo a datos desde página Web, gracias a la generación
automática de documentos XML, consiguiendo una completa
integración con Internet.
 Posibilidades de data warehousing y data mining, para almacenar y
analizar datos, funcionando como Online Transaction Processing
(OLTP) y con servicios Online Analytical Processing (OLAP).
 Comunicación perfecta con otras aplicaciones Microsoft, pudiendo
presentar información en hojas de Excel, por citar un ejemplo.

87

6. Abstracciones primarias
El Gestor de Servicio SQL (SQL Service Broker) ofrece un marco para
aplicaciones distribuidas orientados a aplicaciones de línea de negocios a gran
escala.
Los Servicios de Transformación de Datos (DTS) son un conjunto de herramientas
gráficas y objetos programables que pueden usarse para extraer, transformar
y cargar datos (ETL) desde fuentes muy diversas y llevarlas a un destino único
o múltiples destinos. Data Transformation Services (DTS) para Microsoft SQL
Server 2005 introduce un rediseño completo para proporcionar una
plataforma ETL

7. Capas o marco arquitectónico
Microsoft SQL Server 2005 podemos ubicar el código apropiadamente en
relación a su funcionalidad, acceder a datos nativos como XML, y construir
sistemas complejos que sean manejados por el servidor de Bases de Datos. Estos
puntos hacen que el desarrollo de Bases de Datos esté encaminado hacia una
integración. Es más que un sistema gestor de Bases de Datos ya que incluye
múltiples componentes y servicios que la convierten en una plataforma de
aplicaciones corporativas.

Integración entre SQL Server y Common Language Runtime (CLR)
Esta característica hace que los desarrolladores de Bases de Datos
puedan aprovechar las ventajas de la biblioteca de clases de
Microsoft .NET Framework para implementar funcionalidades de
servidor. Además se pueden codificar procedimientos almacenados,
funciones y triggers en un lenguaje .NET Framework.

Notificaciones SQL (Service Brokers)
Permite enviar notificaciones a los suscriptores cuando se produce un
evento. Ésta funcionalidad es muy útil para invalidar cachés o vistas.
Las notificaciones son generadas de forma eficiente i enviadas a
múltiples tipos de dispositivos.
88

Múltiples resultados y transacciones simultaneas para conexión
Una novedad importante es la de permitir múltiples resulsets
abiertos para conexión, el que permite consultar diversos grupos de
resultados sin tener que a consultar al servidor i sin tener que abrir y
cerrar conexiones.

Seguridad
Podemos agrupar las mejoras en 3 grandes áreas:
1. Restricciones de acceso de usuarios al servidor
2. Deshabilitar servicios y restricción de configuraciones de

servicios.
3. Reducción de la superficie de ataques para las nuevas
características.

Tipos de datos
Aparecen nuevos tipos de datos que acaban con las limitaciones del
tipo TEXT y IMAGE que tenían problemas de tamaño y de
actualización. Concretamente aparecen los tipos VARCHAR (MAX),
NVARCHAR(MAX) i VARBINARY(MAX) que se adaptan al tamaño y se
pueden actualizar directamente.

Tratamiento de errores
Desaparece el acceso a los errores a través de la variable @@Error, y
aparecen blocs TRY CATCH anidables y con nuevas funcionalidades
como ERROR_NUMBER, ERROR_MESSAGE, etc.

Sistema de bloqueo (Snapshot Isolation)
Nuevo nivel de aislamiento que hace que no haya bloqueos en las
lecturas, ya que hace que los lectores lean una versión anterior de los
registros. Tiene la ventaja de una lectura más rápida y sin bloqueos,
pero tiene el inconveniente de unas escrituras más lentas y un
tamaño de Base de Datos más grande.
89

7. Vistas de la arquitectura

S U C _ E x t ra e r D a t o s
< < in c l u d e > >

(f ro m S U C )

< < in c l u d e > >
S U C _ T r a n fo rm a rD a t o s

S U C _ E j e c u t a rP ro c e s o E TL

S A _ E n c a rg a d o S i
s te m a s

(f ro m S U C )

(f ro m S U C )

(f ro m A c t o r)

< < in c l u d e > >
S U C _ R e a l iz a rM a n t e n im i e n t o D W H

S U C _ C a r g a rD a t o s

(f ro m S U C )

(f ro m S U C )

< < e x te n d > >
S U C _ R e a l iz a rM a n t e n im i e n t o
U s u a ri o

S A _ A d m in is t ra d o r
S is t e m a

S U C _ A s ig a n a r o q u ita r R o le s
(f ro m S U C )

(f ro m S U C )

(f ro m A c t o r)

< < in c l u d e > >
S U C _ R e a l iz a rM a n t e n im i e n t o
P r ivile g i o s

S U C _ R e a l iz a rM a n t e n im i e n t o R o l

S U C _ A s i g a n a r o q u i t a r P r ivil e g i o s

(f ro m S U C )

(f ro m S U C )

(f ro m S U C )

S A _ G e re n te A re a
(f ro m A c t o r)

S U C _ R e a l iz a rR e p o r t e s D in a m ic o s
(f ro m S U C )

90

Base de datos operacional del área de ventas de PU.

91

DATAWAREHOUSE:

92

CORRECCIÓN DE LOS DATOS DE LOS CLIENTES CON LA BASE DE DATOS INTERMEDIA

93

METADATA
INDICADORES

94

95

Anexo 9: Documento de Auditoría realizada por el grupo de 4to año a los
grupos de proyecto de BI.
AUDITORIA #1
REALIZADA AL EQUIPO DE BUSSINES INTELIGENCE DE 5T0 AÑO

El proceso de Auditoria exige que se reúnan evidencias, evalúen fortalezas y
debilidades del proyecto a auditar; por lo tanto se ha realizado esta auditoria con
el fin de revisar las actividades del grupo de 5to Año de Sistemas, liderado por
Lisette Chávez Pretel, para que el encargado de la empresa “Productos Unión”,
pueda ver como si las actividades se están desarrollando de acuerdo a lo
planificado.
Antes de esta Auditoria se han tenido reuniones con el grupo de 5to para conocer
el Negocio.
Lo primero que requerimos es obtener información general del equipo de trabajo a
auditar, rigiéndonos en los ítems del Open Up y la norma Técnica Peruana para
esta auditoría.

PERSONAL QUE PARTICIPA EN LA IMPLEMENTACIÓN DEL
SISTEMA:

A continuación mencionaremos a los responsables de la implementación del
sistema a auditar:

Jefe de Proyecto

:

Lisette Chávez Pretel

Analistas

:

Rossemery Brañes Vílchez
Noemí Bravo Zapata

Ingeniero de Procesos

:

Lisette Chávez Pretel

Desarrolladores

:

Noemí Bravo Zapata
Samuel Cruzado

Arquitecto

:

Kenny Aguirre Orosco
96

PERSONAL A CARGO DE LA AUDITORIA:

Las evaluaciones y revisión de la auditoria estarán a cargo de las siguientes
personas, estudiantes de ingeniería de sistemas del 4 año de la Universidad
Peruana Unión:

Iniciador

:

Giancarlo Quispe Gavino

Ing. de Procesos

:

Kelly sobrado León

Arquitectos

:

Daniel Quispe Condori (Encargado)
Daniel Cornejo Ruiz

Registradores

:

Lesly Ccapa Antón
Liz Valle Yanavilca

La auditoria se realizara en base a la metodología Open Up y la norma Técnica
Peruana, la cual nos ayudara para poder realizar la investigación y posteriores
recomendaciones.

COMPARACION CON LA METODOLOGÍA OPEN UP:
Principios del Open UP.
1) Colaborar para sincronizar intereses y compartir conocimiento. Este principio
promueve prácticas que impulsan un ambiente de equipo saludable, facilitan la
colaboración y desarrollan un conocimiento compartido del proyecto
 Se nota que el grupo de quinto esta cumpliendo con este principio y se ponen
de acuerdo para no chocar con otras actividades de los integrantes. Para esto han
realizado un cronograma que según trate en lo posible de no afectar a ninguno de
sus integrantes.
2) Equilibrar las prioridades para maximizar el beneficio obtenido por los
interesados en el proyecto. Este principio promueve prácticas que permiten a los
participantes de los proyectos desarrollar una solución que maximice los
97

beneficios obtenidos por los participantes y que cumple con los requisitos y
restricciones del proyecto.
 También cumplen con este principio. Se observa que se organizan y ponen
prioridades a las actividades, para hacer un mejor trabajo y cumplir con las
presentaciones según su calendario de entregas.
3) Centrarse en la arquitectura de forma temprana para minimizar el riesgo y
organizar el desarrollo.
 Según cronograma, podemos observar que tienen planificada reuniones
tempranas para definir la arquitectura.
4) Desarrollo evolutivo para obtener retroalimentación y mejoramiento continuo.
Este principio promueve prácticas que permiten a los equipos de desarrollo
obtener retroalimentación temprana y continua de los participantes del proyecto,
permitiendo demostrarles incrementos progresivos en la funcionalidad.
 Podemos observar en que se programa un desarrollo evolutivo.
La elaboración del Project Charter y el cronograma de ejecución del
proyecto.

Proyect Charter.- El documento fue realizado completamente y con el
formato asignado (el formato del documento Proyect Charter no forma parte
de las plantillas en el OpenUP).

Cronograma de Ejecución del Proyecto.- El cronograma es conciso
destacando las actividades más resaltantes para el proyecto.

COMPARACION CON LA NORMA TECNICA PERUANA NTP:
La siguiente comparación estará desarrollada en base al Ítem 6.1 de la
Norma Técnica Peruana
la que hace referencia al proceso de
documentación, donde veremos la implementación de la documentación,
diseño y estilo, etc.
Implementación del proceso:

Los alumnos de 5º han desarrollado un documento su Proyect Charter donde
especifica el alcance que va tener el producto software.

98

Según la Norma Técnica Peruana, en el ítem 6.1.1 el grupo de 5º en su proyect
charter cumplen los pasos que menciona la norma técnica, pero en los demás
documentos como son las diferentes entrevistas realizadas no cumplen
completamente con lo estipulado en el momento de la creación de un documento.
Recomendaciones:
 Se deberá preparar, documentar e implementar un plan que identifique los
documentos que se van a producir durante el ciclo de vida del producto
software.
 Para cada documento identificado, se deberá considerar lo siguiente:
 a) Título o Nombre.
 b) Propósito.
 c) Audiencia a la que se dirige.
 d) Procedimientos y responsabilidades para las entradas, desarrollo,
revisión,
modificación, aprobación, producción, almacenamiento,
distribución, mantenimiento y gestión de la configuración.
 e) Plazos para las versiones intermedias y final.
En la fase entendiendo el negocio:
La actividades de entender al negocio, mediante entrevistas para poder captar los
requisitos y de esa manera elaborar el análisis del negocio y del sistema fueron
realizadas, pero no en un documento donde detalle específicamente el análisis.
Especificación de los requerimientos del software:
Existen varios documentos realizados donde especifican las entrevistas realizadas
para poder obtener los requerimientos. El documento está de acuerdo con la
plantilla propuesta por el OpenUP, cumple con todos los ítems.
La siguiente comparación estará desarrollada en base al Ítem 6.4.2.3 de la
Norma Técnica Peruana la que hace referencia a la verificación de los
requisitos.
Hay varios documentos donde especifican las reuniones realizadas para las
entrevistas. Ahí detallan la información recolectada, pero no como llegaron a tener
esa información, no hay documentos que muestren si hicieron cuestionarios o
preparativos antes de realizar las entrevistas. También se deben verificar los
requisitos y examinarlos para poder realizar el modelo del negocio.
Recomendaciones:
Se deberán verificar los requisitos teniendo en cuenta los criterios enumerados a
continuación:
99

a) Los requisitos del sistema son consistentes, viables y se pueden probar.
b) Los requisitos del sistema han sido adecuadamente asignados a elementos
hardware, elementos software y operaciones manuales de acuerdo a criterios de
diseño.
c) Los requisitos software son consistentes, viables, se pueden probar y reflejan
fielmente los requisitos del sistema.
d) Los requisitos software relacionados con seguridad física y de acceso y
criticidad son correctos, según demuestran métodos rigurosos v adecuados.
Observaciones:
Según los informes presentados y las entrevistas realizadas, se puede observar que
los integrantes no están cumpliendo sus respectivas funciones, es por ello que
algunos documentos no se están realizando completamente de acuerdo a la norma
técnica.

Según ítem 7.1.3.4 Se deberá informar, en momentos acordados, sobre el
progreso
del proceso, cumplimiento de los planes y soluciones a las situaciones de falta
de
progreso. Esto incluye informes tanto internos como externos, tal como
requieran
los procedimientos organizativos y el contrato.
Este ítem se ha estado cumpliendo y los alumnos de Quinto año, han entregado
los informes requeridos en el momento, según su cronograma.
Observaciones:
El grupo de Desarrollo esta caminando según lo previsto y cumple con su
cronograma de actividades y entregables hasta la fecha de hoy.

100

Anexo 10: Estructura de una consulta realizada por uno de los grupos del
proyecto de BI.
declare
cursor mor is
select (a.importe-a.pago) monto_mora,a.importe total,a.pago acuenta,p.nombre poli ,bl.nombre
cate,
v.id_politica, v.id_personal, v.fecha_doc, v.id_mov_vnt
from dbaiii.d_cliente c,punion2.pu_regventas v, punion2.pu_politicas p, punion2.pu_block bl,
dbaiii.cliente_id cid,
(select DISTINCT icli.id_mov_vnt, ven.id_personal,ven.importe importe,sum(icli.importe) as
pago
from punion2.pu_regventas ven, punion2.pu_ingcli icli
where ven.id_mov_vnt=icli.id_mov_vnt
group by ven.id_personal, ven.importe, icli.id_mov_vnt) a
where v.id_politica=p.id_politica
and bl.id_block=p.id_block and bl.id_area= p.id_area and bl.id_venta= p.id_venta
and v.id_mov_vnt=a.id_mov_vnt
and cid.id_cliente=c.idd_cliente
and cid.id_cliente_ant=v.id_personal
and a.importe!= a.pago
and v.fecha_doc is not null;
vdidtiempo number;
vdidpolitica number;
vdidventa number;
VCONT NUMBER:=0;
begin
for r in mor loop
VCONT:=VCONT+1;
select DISTINCT nvl(idd_tiempo, 0) into vdidtiempo
from sqlserverg2.tiempo
where trunc(fecha_morosidad) = trunc(r.fecha_doc);
select DISTINCT nvl(idd_politica, 0) into vdidpolitica
from sqlserverg2.politica
where id_politica = r.id_politica and categoria=r.cate and politica=r.poli;
select DISTINCT nvl(idd_venta, 0) into vdidventa
from sqlserverg2.venta
where id_mov_vnt = r.id_mov_vnt;
insert into sqlserverg2.morosidad values(vdidtiempo,vdidventa, vdidpolitica,
r.monto_mora,VCONT);
commit;
end loop;
DBMS_OUTPUT.PUT_LINE ('Sucessful!!');
exception
when others then
DBMS_OUTPUT.PUT_LINE ('ERROR:'||VCONT);
DBMS_OUTPUT.PUT_LINE (' 1:'||vdidtiempo||' 2:'||vdidventa||' 3:'||vdidpolitica);
end;
/

101

Anexo 11: Desarrollo con el Pentaho de uno de los grupos.
1) Representación del ETL con Pentaho.

102

103

2) Generación de cubos con Pentaho.

104

3) Generación de reportes con Pentaho.

105

Anexo 12: OpenUP para BI con el EPF.

106

107