UNIVERSIDAD PERUANA UNIN

Escuela de Posgrado
U.P.G. Ingeniera de Sistemas

Una Institucin Adventista

METODOLOGA OPEN UP EXTENDIDO PARA DESARROLLO DE

PROYECTOS DE BUSINESS INTELLIGENCE

Tesis presentada para optar el grado de Maestra en Ingeniera de

Sistemas con mencin en Ingeniera de Software

Autor
Ing. Sergio Omar Valladares Castillo

Lima, Per
2010

VALLADARES CASTILLO, Sergio Omar. Metodologa OpenUP

extendida para desarrollo de proyectos de Business Intelligence.
Tesis (Maestra en Ingeniera de Sistemas con mencin en
Ingeniera de Software). aa, Lima: Universidad Peruana Unin,
Unidad de Posgrado de Ingeniera de Sistemas, 2010. 107 p.: 21
cm x 30 cm.

Asesor: Dr. Guillermo Mamani Apaza

INTELIGENCIA DE NEGOCIOS/ METODOLOGA OPENUP/

SOFTWARE

ii

Quiero dedicar este trabajo con respeto y

amor a mi padre Delfn 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 sabidura
necesaria, a mis padres por todo su apoyo y a mi
esposa e hija porque me inspiran en todo momento

iv

INDICE GENERAL

Captulo

Pgina

DEDICATORIA..iii
AGRADECIMIENTOS.....iv
INDICE GENERAL....v
INDICE DE FIGURAS....vii
INDICE DE TABLAS......viii
INDICE DE ANEXOS...ix
LISTA DE ABREVIATURAS, SIGLAS Y ACRNIMOS..x
ABSTRACT...xi
RESUMEN....xii
I. INTRODUCCIN A LA INVESTIGACIN ..............................................1
II. FUNDAMENTOS TERICOS ................................................................ 3
2.1 Antecedentes ................................................................................... 3
2.2 Inteligencia de negocios ...................................................................5
2.3 Datawarehouse (DW).......................................................................6
2.4 Metodologa para la implementacin de BI ......................................9
2.5 Metodologa gil de desarrollo de software OpenUP ..................... 20
III. MTODO DE LA INVESTIGACIN .................................................... 23
3.1 Tipo de investigacin......................................................................23
3.2 Metodologa de la investigacin. .................................................... 23
3.3 Planificar el proyecto de investigacin en base a la metodologa
OpenUP adaptada................................................................................ 23
3.4 Diseo de la investigacin.............................................................. 24
3.5 Poblacin y muestra....................................................................... 26
v

3.6 Variables e indicadores ..................................................................26

3.7 Tcnicas e instrumentos de recoleccin 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. VALIDACIN Y ANLISIS DE LOS RESULTADOS............................ 46
CONCLUSIONES..................................................................................... 59
RECOMENDACIONES ............................................................................ 60
LISTA DE REFERENCIAS ....................................................................... 61
ANEXOS ..................................................................................................66

vi

INDICE DE FIGURAS
Figura

Pgina

1 - Business Dimensional LifeCycle de Ralp Kimball .................................9

2 Fases de CRISP-DM ..........................................................................11
3 Tareas genricas y salidas del CRISP-DM ........................................12
4 Esquema del Road Map .....................................................................16
5 Esquema de las fases del OpenUp ....................................................21
6 Esquema de la investigacin ..............................................................25
7 Esquema de la fase de concepcin del modelo propuesto ................42
8 Esquema de la fase de elaboracin del modelo propuesto ................44
9 Esquema de la fase de construccin del modelo propuesto ..............45
10 Resumen comparativo del la evaluacin del grado de cumplimiento
de los tems claves del proyecto de BI ..................................................57

vii

INDICE DE TABLAS
Tabla

Pgina

1 Etapas de Datamarting.......................................................................15
2 Registro general del control de avances por grupos ..........................46
3 Criterio de evaluacin.........................................................................50
4 Evaluacin del grado de cumplimiento de los tems claves del proyecto
de BI......................................................................................................53

viii

INDICE DE ANEXOS

Anexo

Pgina

1: Project Charter del proyecto previo considerado para esta investigacin.

..............................................................................................................67
2: Plan de proyecto de uno de los grupos que utiliza OpenUp Extendido.
..............................................................................................................71
3: Documento de Visin 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 iteracin 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 Auditora realizada por el grupo de 4to ao 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 EPF106

ix

LISTA DE ABREVIATURAS, SIGLAS Y ACRNIMOS

UP: Unified Process

PU: Productos Unin
PMBOK: Project Management Body Of Knowledge
BI: Business Intelligence
DW: Datawarehouse

Palabras claves: Business Inteligence, Datawarehouse, OpenUP, Unified

Process, Metodologa de Software

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 Unin (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 investigacin es de poder utilizar la metodologa de

desarrollo de Software OpenUP para implementar una solucin de
Inteligencia de Negocios, a esta adecuacin se le est llamando OpenUP
para BI. El alcance de la aplicacin de esta propuesta es en proyectos de
Inteligencia de negocios para Pymes.
El OpenUP para BI se valid a travs de los alumnos de Ingeniera de
Sistemas de la UPeU. La investigacin 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 deban tener como
requisito el haber participado en proyectos de desarrollo de Software con
la metodologa OpenUP.
Se aplic el modelo en la industria panificadora de Producto Unin (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 travs

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 travs del OpenUP para BI se logr un entendimiento importante de los
procesos y secuencia de trabajo para el proyecto, ayud tambin en el
proyecto por la aplicacin de los formatos propios del OpenUP, se logr
adems un trabajo eficiente debido a la ejecucin 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

CAPTULO I
INTRODUCCIN A LA INVESTIGACIN
En base a la realidad en el Per, debido a la demanda en el mercado, las
empresas solicitan proyectos de implementacin 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 tecnologa, herramientas y metodologas
correspondientes a BI, existe una gran similitud entre la implementacin
de BI con la forma de desarrollar e implementar un Software, la cual sirvi
de patrn para entender la forma de cmo trabajar con la tecnologa
nueva de BI.
La metodologa para desarrollar esta investigacin fue la siguiente:
desarrollar un prototipo de BI para la industria panificadora de Productos
Unin (PU) con la finalidad de validar los requerimientos y obtener la
aceptacin del usuario con respecto a los entregables. Tambin
desarrollar proyectos de BI a travs de alumnos de la Escuela de
Ingeniera de Sistemas en su respectivo curso, aplicando el modelo
tradicional Business Dimensional LifeCycle (BDLC) de Ralph Kimball. Una
vez que se tiene la informacin y validacin necesaria por PU e
informacin generada en base a la ejecucin del modelo tradicional
BDLC, se procedi a validar el OpenUP para BI a travs de su ejecucin
por parte de los alumnos de la escuela de Ingeniera de Sistemas, un ao
despus, quienes llevarn los temas de BI en su respectivo curso y tienen
ya una base en la aplicacin de la metodologa OpenUP en algn cursos
previamente, este punto es clave debido a la similitud en el contexto en
que se propone la investigacin.
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 estn empezando en proyectos de

implementacin 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 investigacin.

Como parte de los temas en los cursos a nivel universitario

relacionados a BI o con metodologa OpenUP.

En el presente documento se est considerando en el captulo II el

fundamento terico necesario para comprender el tema de investigacin.
En el captulo III se explica la modalidad en que se enmarca esta
investigacin as como los procesos que se seguiran. En el captulo IV se
describe la propuesta la investigacin, se considera la extensin
adecuada del OpenUP con respecto a los roles, entregables, tareas,
procesos de las fases. En el captulo V se describe la validacin del
OpenUP para BI y el anlisis correspondiente de los resultados. En el
Captulo VI explicamos las conclusiones y recomendaciones en base a los
resultados de la investigacin. Como producto complementario a la
investigacin 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 captulo IV.

CAPTULO II
FUNDAMENTOS TERICOS

2.1 Antecedentes
a) Consultora 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 ms 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 tecnologa
especializada solicitan el servicios, y tales consultoras que normalmente
ofrecen el servicio de desarrollo de software ahora deben de involucrarse
en proyectos de nueva tecnologa en un corto tiempo para no perder la
oportunidad de expandir su negocio, debido a la rapidez de la formulacin
del proyecto de una implementacin 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 mayora de estas
consultoras, la tendencia es hacia un desarrollo iterativo-incremental y
dividido por fases, esto es por enseanza recibida desde los centros de
estudios de donde provienen los expertos de las consultoras.
La realidad, en su mayora, de las consultoras en el Per es que a pesar
de ser especialistas en desarrollo de software as como de los dems
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 implementacin,

es por eso que en la actualidad el estado promoviendo el modelo del
CMMI para el desarrollo de Software a travs del PACIS (PACIS 2007).
b) Productos Unin.
Productos Unin (PU) fue creado en 1919 como Centro de Aplicacin del
Colegio Unin (hoy Universidad Peruana Unin). 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 adems sus datos no son confiables,

existe

redundancia de los datos, la estructura de la mayora de sus tablas no

permite relacionarse e incluso existe datos innecesarios por registro que
ocupan demasiado espacio. Es necesaria muchas veces la intervencin
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 bsqueda, correccin y
presentacin de la informacin 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 informacin automatizados tanto a nivel
operativo como gerencial que le permite competir y crecer a nivel mundial.
Desde el ao 2005 cuentan con una solucin de negocio integrada por un
sistema de tipo ERP (Enterprise Resource Planning), tambin el 2005
implementaron una solucin para el rea de ventas usando tecnologa de
Inteligencia de Negocios (BI) y Datawarehouse (DW). Para competir con
estas empresas PU debe invertir en tecnologa 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 disear almacenes de datos basados en UML, pero estos
modelos se quedan en la parte acadmica, 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 versin 1.4 UML y no se
ha rediseado hacia el estndar actual. El cual permite realizar ms
diagramas y posible extensiones hacia el desarrollo de una herramienta
en cdigo abierto para el desarrollo de bodegas de datos, En el
componente de ETL se encuentra modelos bsico pero no estandarizados
al igual que en la proceso de minera de datos.

2.2 Inteligencia de negocios

Fernndez (2004) dice que en la empresa actual se da cada vez ms
importancia al control de gestin. Los recursos son escasos, los procesos
son complejos, y cada vez es ms crtica la informacin 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:
Anlisis de la misma informacin en el 10% del tiempo
Minimizacin de los costes de oportunidad por anticipar decisiones de
meses a semanas o de semanas a das
Ejecutivos sin formacin informtica realizan complicadas consultas a
las bases de datos en segundos
Reduccin de costes del departamento de Tecnologas de la
Informacin-Informtica
Reduccin 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 economa actual.

Business Intelligence es un set de tecnologas que van desde

arquitecturas para almacenar datos, metodologas, tcnicas para analizar
informacin y software entre otros, con un fin comn para el apoyo a la
toma de decisiones.
2.3 Datawarehouse (DW)
Concepto
Existen muchas definiciones para el DW, la ms conocida fue propuesta
por Inmon (considerado el padre de las Bases de Datos) en 1992: Un
DW es una coleccin de datos orientados a temas, integrados, novoltiles y variante en el tiempo, organizados para soportar necesidades
empresariales. En 1993, Susan Osterfeldt publica una definicin que sin
duda acierta en la clave del DW: Yo considero al DW como algo que
provee dos beneficios empresariales reales: Integracin y Acceso de
datos. DW elimina una gran cantidad de datos intiles y no deseados,
como tambin el procesamiento desde el ambiente operacional clsico.
(Oracle University 1999).
El Datawarehouse, es actualmente, el centro de atencin de las grandes
instituciones, porque provee un ambiente para que las organizaciones
hagan un mejor uso de la informacin 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 ms bien un concepto que debe ser construido. DW es una
combinacin de conceptos y tecnologa que cambian significativamente la
manera en que es entregada la informacin a la gente de negocios. El
objetivo principal es satisfacer los requerimientos de informacin internos
de la empresa para una mejor gestin, con eficiencia y facilidad de acceso
(Gloria 2002).

Caractersticas.
Oracle University (1999) menciona 4 caractersticas:
6

Orientado a temas
Una primera caracterstica del Datawarehouse es que la informacin
se clasifica en base a los aspectos que son de inters 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 mdico,
medicamentos, etc.

Integracin
En muchas organizaciones la data reside en diversos sistemas
independientes. Haciendo dificultoso la integracin de los datos para
el anlisis. Para el Datawarehouse la data est completamente
integrada.

De tiempo variante
Como la informacin en el Datawarehouse es solicitada en cualquier
momento (es decir, no "ahora mismo"), los datos encontrados en el
depsito se llaman de "tiempo variante". Los datos histricos son de
poco uso en el procesamiento operacional. La informacin del
depsito por el contraste, debe incluir los datos histricos para usarse
en la identificacin y evaluacin de tendencias.

No voltil
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 bsica de la arquitectura DW
incluye:

A. Datos operacionales: un origen de datos para el componente de

almacenamiento fsico DW.
B. Extraccin de Datos: seleccin sistemtica de datos operacionales
usados para poblar el componente de almacenamiento fsico DW.
C. Transformacin de datos: Procesos para sumarizar y realizar otros
cambios en los datos operacionales para reunir los objetivos de
orientacin a temas e integracin principalmente.
D. Carga de Datos: insercin sistemtica de datos en el componente de
almacenamiento fsico DW.
E. Datawarehouse: almacenamiento fsico de datos de la arquitectura
DW.
F. Herramientas de Acceso al componente de almacenamiento fsico
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, imgenes, textos, espaciales, audio, video y Web.

Acceso a los datos, los datos son utilizados por diversos propsitos y
de distintos formatos a la vez. Para ello se necesita de programas
especiales para su utilizacin.

Flujo de datos a travs del warehouse

El dato es extrado desde las fuentes, transformados de acuerdo a la
necesidad y entonces transportado al apropiado lugar dentro del almacn
de datos.
Diferentes tipos de datos facilitan las operaciones del Data Warehouse.
Datos que se necesitan depurar provienen del ms 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 anlisis. La Metadata provee la

informacin o estructura de cmo est conformado el Data Warehouse,
incluyendo un especfico detalle con respecto a los datos.
Existen herramientas que acceden al dato del Warehouse para soportar
anlisis y otras consultas (Oracle 1999).
2.4 Metodologa para la implementacin 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 planificacin que abarca desde la
obtencin

de

los

requerimientos

informacin

hasta

las

consideraciones de mejora y crecimiento de la primera versin del BI

implementado. Cuando el proyecto es aprobado, el plan del proyecto
es la gua para la ejecucin y control de la implementacin del BI.

Figura 1 - Business Dimensional LifeCycle de Ralp Kimball

(Kimball University 2009)

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 informacin y/o datos que tiene la empresa. Se
debe entender al detalle los requerimientos por todo el equipo del
proyecto.
Despus 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 tecnolgica 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 grficas de los reportes, cuadros
estadsticos para que desde un comienzo el usuario final tenga nocin
de la presentacin de sus requerimientos, as como la ejecucin de la
aplicacin por el motor de BI generado por este ltimo grupo.
Una vez que se tiene previa aceptacin por parte del usuario, se
procede a implementarlo y probarlo en entornos reales, especialmente
en la Arquitectura de Hardware en el rea de produccin de la
empresa hasta lograr la aprobacin final por el usuario.
Se considera adems toda una etapa de mantenimiento para el buen
funcionamiento de la aplicacin as como control e implementacin del
crecimiento de la data y/o requerimientos del negocio la cual requiere
empezar con un nuevo proyecto desde su planificacin, siendo de
este modo todo un ciclo de implementacin de esta tecnologa.

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 minera de datos a finales de 1996.
10

La metodologa de CRISP-DM est descrita en trminos de un modelo

de proceso jerrquico, consistente en un conjunto de tareas descritas
en cuatro niveles de abstraccin (de lo general a lo especfico): fase,
tarea genrica, tarea especializada, e instancia de procesos (CRISPDM consortium 2000).
CRISP-DM consortium (2000), tal como se muestra en la figura 2,
especialmente enfatiza la validacin de los requerimientos con los
datos existentes en la empresa, es necesario entender la razn de la
existencia de los datos y su relacin entre ellos, se considera los
datos almacenados en reportes impresos, datos en hojas de clculos
o en digital, la cual es necesario ver la redundancia y relacin entre
los distintos medios de almacenamiento de estos datos. Tambin 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 genricas y salidas del CRISP-DM

(CRISP-DM consortium 2000)

12

En la figura 3 se muestra las tareas genricas por cada proceso del

CRISP-DM. Si bien esta metodologa se centra en los procesos para
generar los algoritmos de Datamining, considera sus procesos desde la
obtencin de los requerimientos.
Se enfatiza un anlisis profundo en la reestructuracin, depuramiento,
sumarizacin y formato de los datos para considerarlos dentro de la lgica
del proceso ETL.
C. Hefesto
Bernabeu (2009) propone lo siguiente:
Fcil distincin y comprensin de objetivos en cada fase.
Se basa en el usuario, siendo fcil y rpida su adaptabilidad a
cambios en el negocio.
Involucra

al

usuario

final,

tomando

decisiones

sobre

comportamiento y funciones del DW.

Usa modelos conceptuales y lgicos sencillos de analizar e
interpretar.
Independiente de las herramientas usadas en la implementacin.
Independiente del ciclo de vida en el que es empleada.
Independientes de las estructuras fsicas que contiene el DW y su
distribucin.
Aplicada tanto a DM como DW.
Los datos obtenidos de cada fase con el punto de partida de la fase
siguiente.
Pasos y Aplicacin:
a) Anlisis de los requerimientos.
Hefesto se preocupa de la obtencin de requerimientos y termina
con su representacin en un modelo conceptual que es una
representacin 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 anlisis.
c) Modelo conceptual.
Bernabeu (2009) enfatiza la realizacin 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 relacin de la
informacin involucrada segn requerimientos.
b) Anlisis de los OLTP.
Hefesto tambin representa el proceso principal de anlisis, es en
este paso donde se debe establecer los indicadores considerando su
nivel de granularidad. Hefesto en este paso detalla lo siguiente:
a) Determinacin 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 relacin de la informacin
involucrada segn requerimientos como su relacin con la data
existente.
c) Modelo Lgico del DW.
Hefesto en este paso considera la representacin de los indicadores
y requerimientos en los modelos propios de una solucin de
inteligencia de negocios. En este paso se detalla lo siguiente:
a) Tipo de modelo lgico 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
fsico de los datos, sus relaciones de integridad as como su
crecimiento como segmento en el servidor correspondiente.

D. DATAMARTING
Arson Group (2005) propone la metodologa Datamarting que asegura
realizar un proyecto de BI en forma sencilla y bien documentada a
travs de 4 etapas mostrado en la tabla 1:
4 etapas
Tabla 1 Etapas del Datamarting (Arson Group 2005)
ETAPA
Planificacin

OBJETIVO PRINCIPAL

PRINCIPALES TCNICAS

Preparacin del plan de

actividades por etapas,
gestionando los recursos

Dimensionamiento de
proyectos.
Mtricas 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
implementacin en la
herramienta OLAP

Incremental Update for BI.

Reciclaje de errores.
Almacenamiento por uso de
informacin

Implementacin

Entrenar a los usuarios para

institucionalizar el proyecto de
BI

Why five.
Capacitacin por capacidades

Anlisis

Six Question.
Anlisis de granularidad.
Relaciones dinmicas.
Versioning

6 documentos
3 mtricas de control (Conforme al ISO/IEC 14143-1:1998)
4 mejores prcticas alineadas al modelo de CMMI.

15

 10 pasos para la implementacin del Datamarting enfocado al

usuario:
1. Identificar los temas de anlisis.
2. Identificar las dimensiones de navegacin.
3. Elaboracin del Modelo Multidimensional Bsico.
4. Elaboracin del Modelo Multidimensional Complejo.
5. Elaboracin de las especificaciones de carga de datos.
6. Creacin de Base de Datos.
7. Construccin de la Arquitectura del Datamart.
8. ETL.
9. Implementacin.
10. Capacitacin al Usuario.

E. ROAD MAP
En la figura 4, se muestra el esquema general del Road Map. Se
evidencia en esta representacin 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 adems la justificacin correcta del proyecto
de BI as como la capacidad de la empresa de explotar y manejar la
aplicacin de BI como corresponde. Tambin considera la muestra de
prototipos

como

interfaces

grficas,

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 especfico que contribuye al
los objetivos del proyecto de BI:

La ruta ETL entregar la base de dato cargada.

La pista de aplicacin entrega los informes, consultas y

herramientas ad hoc.

El repositorio de metadatos entregar los metadatos.

Cada ruta se mueve a travs de las seis etapas del BI Roadmap ya

sean juntos o por separado y en paralelo, realizando las actividades
de ingeniera en sus medidas concretas.
Larissa Moss (2004) justifica que a medida que el entorno de BI se
convierte en un entorno de decisin complicada como apoyo de toda
la Organizacin en el tiempo, es esencial que exista una base slida
para

soportar

tal

expansin. Muchas

cosas

tienen

que

ser

considerados y muchas tareas deben ser realizadas por muchas

personas para construir los slidos cimientos.
La cuestin no es si una metodologa debe ser utilizada, sino ms
bien qu tipo de metodologa se debe utilizar y cmo utilizarlos con
mayor eficacia. Una metodologa de cascada tradicional no es
adecuada para el concepto interactivo de liberacin de las
aplicaciones de BI, el BI Roadmap si lo es.

17

F. SCRUM PARA BI
Gravitar (2007) menciona que existen numerosas propuestas de
metodologa. Tradicionalmente estas metodologas se centran en el
control del proceso, estableciendo rigurosamente las actividades,
herramientas y notaciones al respecto, dado estas reglas estas
metodologas se caracterizan por ser rgidos y dirigidos por la
documentacin que se genera en cada una de las actividades
desarrolladas.
Este enfoque no resulta ser el ms adecuado para muchos de los
proyectos actuales donde el entorno del sistema es muy cambiante, y
en donde se exige reducir drsticamente los tiempos de desarrollo
pero manteniendo una alta calidad.
Por definiciones propias del SCRUM resumimos que es una
metodologa gil de desarrollo de proyectos, que requiere trabajo
duro porque no se basa en el seguimiento de un plan, sino en
la adaptacin continua a las circunstancias de la evolucin del
proyecto.
Dos caractersticas ms destacables son:

Se acepta de entrada que los requerimientos son por definicin

cambiantes, y por lo tanto se evitan muchas discusiones
estriles. 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 visin clara de la evolucin del
proyecto.

Esta metodologa 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 bsica es que el desarrollo se hace de manera cclica e
incremental. En cada "ciclo de desarrollo" (sprint), el "equipo de
desarrollo" selecciona el subconjunto de funcionalidades (sprint
backlog) que se incorporarn al producto, y durante el siguiente ciclo
se centrarn nicamente en completar esas funcionalidades y
entregrselas al cliente. Los equipos son pequeos (mximo 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 intiles. 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 diseo, de la
implantacin, y del resultado). El equipo de desarrollo tiene una gran
autonoma.
G. Extreme Programming (XP) PARA BI
Como parte de una investigacin, la Universidad EAFIT (2006)
muestras ciertas caractersticas del XP como una opcin para
proyectos de BI. Algunas de las caractersticas son:

Metodologa genrica, aplicable a mltiples plataformas.

Es posible, aunque se enfoca a lneas de negocios especficas,

que permita un anlisis del negocio que sea transversal a toda
la organizacin.

19

Posibilita el acoplamiento de nuevas tecnologas con cada

proyecto que se desarrolle.

Tiene etapas completamente detalladas, que sumndolas den

como resultado la completitud del proyecto de inteligencia de
negocios, a pesar que XP no es especfica 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 metodologa.

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 investigacin 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 investigacin prefiere adaptar la
metodologa 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 adems tales empresas ya cuentan
con procesos muy definidos.
2.5 Metodologa 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 filosofa gil que se centra en la naturaleza de colaboracin de
desarrollo de software. Es una herramienta que no se amarra a una
tecnologa en particular, baja ceremonia (poca documentacin) 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

metodologa incluyendo una representacin de iteraciones e hitos

principales.

Figura 5 Esquema de las fases del OpenUP

(Eclipse 2007)
OpenUP es para equipos pequeos 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, cules
son las prioridades, y la mejor manera de atender las necesidades de los
interesados. La organizacin 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 peridicas de revisin de riesgos y
la aplicacin rigurosa de las estrategias de mitigacin.
Los casos de uso se utilizan para obtener y describir los requisitos, por lo
tanto, los miembros del equipo necesitan desarrollar destrezas en la
representacin

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 colaboracin.
Arquitectnicamente requisitos importantes deben ser identificados y
establecidos desde la fase de elaboracin a fin de que una arquitectura
robusta puede ser creada como el ncleo del sistema. El riesgo de que
21

ocurran cambios en la Arquitectura se debe reducir significativamente en

las iteraciones de la fase de Elaboracin.
La prueba se realiza varias veces por iteracin, cada vez que la solucin
se incrementa con el desarrollo de un requisito, el cambio o correccin de
errores debe ser considerado. Estas pruebas suceden despus de que los
desarrolladores han desarrollado la solucin (que debera haber sido
sometidos a pruebas por unidad) e integrarlo en el cdigo base. Estas
pruebas ayudan a garantizar que una versin estable es creada y siempre
disponible como progreso del desarrollo.
OpenUP es un iterativo proceso distribuidos en cuatro fases: creacin,
elaboracin, construccin y transicin. Cada fase consta de una o ms
iteraciones, con la finalizacin de cada iteracin representan un hito de
menor importancia para el proyecto y contribuye a la consecucin de los
hitos ms importantes de la fase, donde los objetivos de la fase deben ser
cumplidos (Eclipse 2007).

22

CAPTULO III
MTODO DE LA INVESTIGACIN

3.1 Tipo de investigacin.

El tipo de investigacin es evaluativo y propositiva, pues se hace una
evaluacin del la metodologa de desarrollo de software OpenUP para
proyectos de BI y es propositiva ya se propone una metodologa
extendida para proyectos de Inteligencia de Negocios.
3.2 Metodologa de la investigacin.
El mtodo de investigacin es pre experimental de corte longitudinal, pues
se aplica la metodologa de desarrollo de software OpenUP para el
desarrollo de proyectos de BI y se evala la eficiencia de la metodologa
durante un periodo acadmico.
3.3 Planificar el proyecto de investigacin en base a la metodologa
OpenUP adaptada.
3.3.1 Ejecucin del proyecto previo.
Se considera este punto con la intensin de agilizar la captura de
los requerimientos de la empresa

y disponer de los datos

necesarios para que los equipos puedan trabajar sin restricciones.

Adems, de lograr una previa aceptacin de los usuarios en base
al prototipo presentado.
3.3.2 Afinamiento de la metodologa OpenUP.
En base a la experiencia previa, previo anlisis, se realizan todos
los cambios necesarios a considerar en la metodologa OpenUP de
tal modo que sea entendible y aplicable por los equipos de
proyectos.
3.3.3 Diseo del modelo adaptado
En este tem se considera el diseo del modelo de OpenUP
adaptado a proyectos de BI.
23

3.3.4 Preparacin y alineamiento de los equipos de proyecto.

Se considera dos etapas, la primera es la formacin de equipos
que implementarn el BI en base al modelo de Kimball y con los
datos obtenidos en el proyecto previo.
La segunda etapa es la formacin de equipos que implementarn
el BI en base a la metodologa OpenUP adaptada para BI con los
mismos datos obtenidos en el proyecto previo.
3.3.5 Aplicacin del modelo propuesto.
Considerando al equipo de proyecto de BI de la segunda etapa,
implementarn el BI en base a las directivas respectivas basadas
en el modelo propuesto.
3.3.6 Anlisis de los resultados en base a los modelos ejecutados.
En base a la informacin obtenida y en base a experiencias
pasadas, se proceder a evaluar el resultado del trabajo de
equipos de implementacin de BI basados en el modelo tradicional
de Kimball con equipos de implementacin de BI basados en el
OpenUP para BI.
3.4 Diseo de la investigacin.
El esquema de la investigacin se presenta a continuacin:
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 metodologa OpenUP
para BI.
O2: Proyectos de BI en la cual no se ha aplicado la metodologa OpenUP
para BI.
X: Metodologa OpenUP para BI para desarrollo de Proyectos de BI
Y: Metodologa tradicional para desarrollo de proyectos de BI
24

En la figura 6 se muestra el esquema de la investigacin. Se considera un

proceso de Proyecto previo de BI con la finalidad de obtener la
aprobacin de la empresa PU quien nos ayuda con esta investigacin. Se
representa

adems

la

ejecucin

en

paralelo

de

los

proyectos

experimentales por un lado los que no aplican la metodologa OpenUP

para BI y por otro lado los proyectos que si lo aplican. El proceso final es
para analizar los resultados obtenidos por la ejecucin de los proyectos
experimentales.
INICIO

PROYECTO PREVIO DE
BI

REQUERIMIENTOS
Y BASE DE DATOS

CAPACITACIN
PREVIA

AFINAMIENTO
OPENUP CON BI

PROYECTO BI

CAPACITACIN
PREVIA DE OPENUP
PARA BI
PROYECTO BI CON
OPENUP PARA BI

ANALISIS DE
RESULTADOS

FIN

Figura 6 Esquema de la investigacin

25

3.5 Poblacin y muestra

La poblacin est conformada por todo los equipos de trabajo del
quinto ao de sistemas del curso de BI.
La muestra es censal, pues

se trabajo con todos los equipos

conformados por alumnos del 5to ao de Sistemas de la UPeU que

deben cumplir como prerrequisito la experiencia de trabajos de ciclo
en desarrollo de software siguiendo una metodologa de software
basados en UP y llevar el curso de Inteligencia de Negocios (DBAIII),
la intencin 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 implementacin de BI basados en la Metodologa de
desarrollo de software OpenUP (OpenUP para BI).
Indicador: Presencia o ausencia de la aplicacin de la metodologa.
b. Variables dependientes.
Eficacia de desarrollo de proyectos de BI
Indicadores:
Cumplimiento de los requerimientos (funcionamiento y visualizacin
de los reportes correspondientes).
Calidad de los entregables (formatos).
Cumplimiento

de

las

actividades

correspondientes

al

Rol

desempeado.
Cumplimiento con las fechas programadas por actividad.
3.7 Tcnicas e instrumentos de recoleccin 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

CAPTULO IV
DESARROLLO DEL OPENUP PARA BI

4.1 Decidiendo por OpenUP.

Los modelos propios para la implementacin de BI representan en forma
de grupo de procesos la secuencia de una implementacin de BI,
describen los entregables propios de BI y realizan cierta descripcin con
respecto a los roles. Como podemos notar del marco terico existe una
tendencia a buscar alternativas de modelos o metodologas que permitan
un mayor xito en la implementacin de BI.
El problema de los modelos propios de BI no especifican a niveles ms
detallados la secuencia de trabajo, de este modo se obvia la relacin
entre ellas; no se especifica la relacin de trabajo entre los roles. Esta
generalidad ocasiona que no exista una informacin gua que ayude a la
gestin 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 gestin del proyecto.
La tendencia de acomodar los modelos de BI bajo el enfoque clsico de
las fases de desarrollo de software es notoria, pero existe an cierta
rigidez en dichos modelos. Por ejemplo el modelo de BDLC de Kimball y
aun el modelo del BI Roadmap segn su esquema no evidencia el
conjunto de pruebas iterativas en la construccin del producto como es la
tendencia actual en el desarrollo de software. En estos modelos tampoco
se tampoco se evidencia una divisin del trabajo en iteraciones que
representen logros inmediatos, la cual es propio de un proyecto de BI,
como por ejemplo la construccin del modelo multidimensional por temas
de negocio.
Existen muchas propuestas, en investigacin, de implementar BI bajo el
enfoque de las metodologas de desarrollo de software, especialmente
27

con metodologas giles. Aplicar metodologas de desarrollo de software

para implementar BI requiere la modificacin o extensin de dichas
metodologas.

Existe

mucha

similitud

entre

los

procesos

de

implementacin de BI con las fases de desarrollo de software, est en

investigacin la implementacin de BI con la metodologa 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 planificacin detallada del todo el ciclo del proyecto, sabemos
que es parte de la filosofa del SCRUM, y podra adaptarse a nuestra
realidad que es comn el atraso en el desarrollo del software, pero es
algo que se intenta revertir. El estado a travs del PACIS propone la
certificacin del CMMI as como de la norma tcnica peruana (NTP)
correspondiente la cual enfatizan la planificacin del proyecto como
procesos importantes para proyectos de desarrollo de software, bajo
dicho contexto la metodologa SCRUM queda descartada como regla
general.
Como vimos en el marco terico, la metodologa XP es una de las
opciones para adaptarla para proyecto de de implementacin de BI, pero
siguiendo el contexto en que se enmarca esta investigacin, sera ms
trabajoso la forma de adaptar el XP en las consultoras en el Per que ya
tienen una tendencia a la forma de iterativo incremental clsico debido a
la formacin profesional del personal en los proyectos.
En el Per no existen aun procesos estndares para el desarrollo del
software, algunas consultoras actuales tratan de seguir la metodologa
RUP, otras consultoras e incluso las que tienen ms tiempo tienen su
propia forma de trabajar pero siguen el estilo iterativo incremental clsico
por la respectiva formacin profesional. El RUP se descarta como
propuesta en esta investigacin debido a que se necesitara descartar
muchos procesos, tareas, roles y entregables del RUP para adaptarla a
una implementacin de BI, adems que el RUP se aplica para proyectos
grandes con equipos grandes de trabajo.
28

Bajo el contexto de la presente investigacin se est optando por la

metodologa OpenUP debido a que los procesos de esta metodologa
permite adaptarla a diversos tipos de proyectos, permitiendo su
factibilidad para proyectos de implementacin de BI, adems, 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
metodologa OpenUP es totalmente bsica que facilita su adaptacin a la
realidad de diversos proyectos sin perder los principios giles y de
desarrollo iterativo incremental clsico as como su base en las mejores
prcticas.
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.
Adems los formatos predefinidos que permiten tener una visin 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 gua en toda la fase de construccin. Los formatos de los
documentos relacionados a la gestin, 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 continuacin se menciona la propuesta de esta investigacin donde
tambin se compara la propuesta con la forma tradicional de implementar
BI tales como el modelo BDLC de Kimball.
A) Los roles
Las caractersticas que considera el OpenUP con respecto a los roles no
se descartan en esta investigacin, es mas siguen como lnea base para
mantener el cumplimiento de la metodologa, la delimitacin de la funcin
29

de un rol no se considera en la mayora de los modelos de BI. Lo que se

describe a continuacin por cada rol son las caractersticas adicionales
que deben cumplir para poder trabajar en un proyecto de BI:

Director del proyecto (Project Manager), dirige a la planificacin 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
implementacin de BI, por ejemplo la complejidad de procesamiento
del cdigo ETL, tiempo de procesamiento del ETL, el refrescamiento
del modelo multidimensional, la carga inicial de datos, depuracin de
los datos, entre otros. Este factor es importante porque influye
significativamente en el alcance, tiempo y costo del proyecto,
mantener los mrgenes adecuado de tiempo entre las respectivas
iteraciones permitir un desempeo adecuado en el proyecto.
El director del proyecto necesita conocer por parte del Arquitecto las
alternativas y caractersticas de las herramientas adecuadas para el
proyecto as como las divisiones adecuadas de los componentes de la
solucin. Este factor es importante porque influye en el tiempo y costo
del proyecto, cada herramienta tiene su particularidad y mbito de
accin, por ejemplo, algunas herramientas solo considera la
generacin del modelo multidimensional, esto significa que el proceso
de ETL tendra que hacerse con el cdigo 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 cdigo 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 adems el
modelo conceptual ayuda a determinar el alcance del proyecto en la
fase de construccin.
La interaccin entre el Director del proyecto, Analista y Arquitecto no
se resalta en los modelos de BI, la representacin del OpenUP en la
fase de concepcin refleja esta interaccin entre los roles la cual es
un factor importante en el proyecto de BI.

Analista (Analyst), la persona en este rol interacta con los usuarios e

interesados para entender el problema a resolver y mediante la
captacin y fijacin de prioridades para los requisitos.
El Analista encamina la entrevista de una manera adecuada para
determinar si la empresa necesita de una solucin 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 travs del modelo de datos puede reconocer el
funcionamiento de la organizacin. El Analista debe encontrar los
problemas y errores en la estructura de datos y proponer una
alternativa para su depuracin que forme parte de la solucin 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 estructuracin 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 tcnicas propias de una

solucin 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

solucin de BI, que incluye tomar las decisiones tcnicas clave como
la arquitectura de hardware y software que limitan el diseo y la
ejecucin general del sistema. La decisin 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 solucin de BI incluye los diversos dispositivos tales
como Pocket PC, Palms, celulares adecuados y las caractersticas de
seguridad adecuada debido a que la informacin a compartir es de
gran importancia para la organizacin.
El Arquitecto debe asegurarse de la correcta instalacin de las
herramientas involucradas en el proyecto. Monitorear la adecuada
configuracin de los componentes de la herramienta de BI y su
posible utilizacin por los usuarios y miembros del equipo del
proyecto. El Arquitecto debe conocer un nivel avanzado de
administracin

de

la

Base

de

Datos

como

por

ejemplo

particionamiento de tablas, es su responsabilidad asegurarse la

correcta implementacin del modelo del Datawarehouse.
La capacitacin 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
capacitacin 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 tcnica de hardware y software as

como la Arquitectura completa de la solucin de BI. Por ejemplo las
32

entidades de las dimensiones deben relacionarse con la estructura de

tablas, su almacenamiento como segmento y la distribucin entre los
archivos de datos de la Base de Datos, adems la estimacin del
volumen de datos segn el anlisis de la granularidad.

Desarrollador (Developer), es responsable de desarrollar una parte

del sistema, incluyendo el diseo para encajar en la arquitectura,
posiblemente de prototipos de los reportes, y la ulterior aplicacin,
pruebas unitarias, y la integracin de los componentes que forman
parte de la solucin.
El desarrollador tiene la experiencia de interactuar con la Base de
Datos, conocedor de las tcnicas de optimizacin de consultas as
conocedor de de los objetos de la Base de datos y seguridad de la
misma. En la solucin de BI, el desarrollador no es necesariamente un
programador que utiliza algn lenguaje de programacin, existe la
posibilidad de requerir que el desarrollador conozca de un lenguaje de
programacin cuando la solucin de BI requiera el apoyo para agilizar
los procesos de migracin de datos, o mdulos complementarios y
simples para la captura de datos necesarios para la solucin de BI
tales como mdulos 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 gua del Arquitecto se basa en el documento
de la Arquitectura para continuar con el desarrollo, en el modelo
BDLC de Kimball propone el desarrollo despus del entendimiento de
los requerimientos y la lnea principal de desarrollo debe esperar al
desarrollo del modelo fsico del Datawarehouse, pero no enfatiza una
representacin completa de la solucin de BI, en la metodologa del
OpenUP si enfatiza la representacin integrada de la solucin 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 lgica del proceso es
expresado en forma general, el Analista debe validarlo inicialmente
para que pueda ser considerado como parte de la Arquitectura de la
solucin de BI en la fase de elaboracin. El Desarrollador debe tener
la

habilidad

de

entender

el

documento

de

Arquitectura,

especificaciones y diagramas.
B) Entregables
Una ventaja de la metodologa OpenUP en comparacin de los modelos
de BI es la presentacin de entregables con sus respectivos formatos.
Mientras que en los modelos de BI solamente te describe lo que deberas
presentar, en los formatos del OpenUP muestra una estructura ordenada
que permite ver una correlacin dentro del mismo documento como con
otros entregable, adems muestra una visin integral de la solucin.

Dominio del Director del proyecto. En el OpenUP para BI se mantiene

los formatos originales, la variacin es en el contenido. Segn la
experiencia del Director de proyecto e informacin que comparte con
el Arquitecto y Analista determina los tiempos, costos, alcance y
control de calidad que debe estar expresada en los documentos.
Segn la cantidad de temas que conforman un grupo de indicadores
que estn involucrados en la solucin de BI determinar en la
cantidad de iteraciones que el Director de proyecto deba considerar
en el documento.
Una propuesta de la investigacin es reemplazar el Work Item List por
un cronograma al formato del diagrama de Gantt, donde las
actividades estn 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 solucin 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 solucin de BI y su interaccin 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 categora 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
solucin de BI. El modelo conceptual representa, al mismo nivel del
diagrama de casos de usos, el comportamiento de los indicadores y
su relacin con las entidades. Ambos modelos ayudan a comprender
de forma integrada la solucin 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 solucin de BI. Los cambios

propuestos en esta investigacin 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 Fsico del Datawarehouse, Metadata Fuente,
formato de los reportes, entre otros.

Dominio del desarrollo. La metodologa OpenUp presenta 4

entregables bajo este dominio, Diseo (Design), lo construido (Build),
la implementacin (implementation) y Pruebas del desarrollador
(Developer Test), los cuatro entregables son adaptables para una
solucin de BI, en el OpenUP para BI conviene considerar lo

35

construido (build) especificndolo en 4 componentes bien definidos

propios de BI:
a) Modelo fsico (estrella y/o copo de nieve) en el Datawarehouse.
Responsable es el Desarrollador estructurar el Datawarehouse
segn la propuesta en el documento de arquitectura, este proceso
debe ser monitoreado por el Arquitecto especialmente en el
aspecto tcnico del desarrollo. Este entregable es un hito interno
de la fase de construccin se requiere la validacin del Analista.
b) Cdigo del ETL, lgica de programacin o representacin grfica
ejecutable de la migracin, depuracin y transformacin y carga
de los datos al Datawarehouse. La gua 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) Generacin 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 tambin por temas, quien debe
validar cada sub-entrega es el Arquitecto debido a la naturaleza
totalmente tcnica del componente.
d) Generacin 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 elaboracin o
inicios de la construccin, la cual permite aprovechar el tiempo en
el proyecto. Es en la fase de construccin donde se relaciona las
estructuras de los reportes con el modelo multidimensional
generado. Tambin se puede subdividir el entregable por temas,
cada subdivisin debe ser validado por el Analista, es en este
36

punto donde el Analista tiene un rastreo total desde los reportes

en ejecucin hasta los requerimientos.
Como parte de la implementacin esta la configuracin y visualizacin
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 gestin)
asumiendo que se lleva un control sobre el cumplimiento de las tareas
y/o actividades. Segn 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 rpidamente e informar a todos los implicados tales como
el Arquitecto, Analista, Desarrollador y otros.
El Diseo es opcional solo en el caso que se deba desarrollar un
mdulo complementario y simple con un lenguaje de programacin,
con respecto a la solucin de BI, los diagramas de diseo estn
directamente bajo la responsabilidad del Desarrollador.
C) Tareas
Las tareas que propone el OpenUP son adecuadas para implementar una
solucin de BI, a continuacin se detallaran las tareas que deban ser
enfatizados en el OpenUP para BI como parte de esta investigacin:

Disciplina de requerimientos: Detalle del Modelo Conceptual.

Esta tarea describe como representar el modelo conceptual. El
propsito 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 travs de las entrevistas
con los interesados. Los Analistas dependen adems del anlisis
realizado en las fuentes de datos de la organizacin. A travs 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 informacin obtenida en las entrevistas realizadas
para

descubrir

indicadores,

asumimos

que

existieron

entrevistas anteriores para determinar si la organizacin

necesitaba de una solucin de BI.
b) Analizamos la estructura de datos de las distintas fuentes,
desde el formato de un reporte en papel, hojas de clculo
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 imgenes adecuadas que representen a las variables
o entidades y relacionarlas con el indicador. Con esta
representacin de alto nivel se forma el Modelo conceptual.
e) Ordenar y separar el Modelo conceptual por cada tema.
3. Debemos considerar que la intencin del Modelo conceptual es
hacer que el interesado comprenda y valide la propuesta de la
solucin de BI en base a la informacin obtenida.

Disciplina de la arquitectura: Validacin del Arquitecto.

Esta tarea describe el proceso de validacin de los Modelos
presentado por los analistas, la validacin es desde el punto de vista
38

tcnico, 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 validacin. El Analista
entrega los avances de los modelos y formatos en las fecha
acordadas.
2. El proceso de validacin sigue los siguientes pasos:
a) El Analista informa al Director del proyecto sobre el avance
realizado segn la fecha acordada en el plan de iteracin. El
Director del proyecto actualiza el cronograma programando la
fecha de validacin y controlando el estado de las actividades
e informa al Arquitecto para que proceda con la validacin.
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 explicacin, el
Analista debe estar dispuesto a brindar la explicacin
necesaria.
c) El resultado de la validacin del entregable debe ser en mutuo
acuerdo entre el Arquitecto y el Analista. El Arquitecto informa
al Director del proyecto sobre la validacin del entregable.
d) Segn

el

informe

de validacin, si es necesario la

modificacin 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 tcnico y segn lo acordado entre el Director del
proyecto y el interesado. Adems, las notas de la Arquitectura ya
fueron establecidas desde la fase de concepcin y refinado a los
inicios de la fase de elaboracin.
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 cmo integrar todos los cambios realizados por
los desarrolladores en la base de cdigo y realizar las pruebas
mnimas para validar la construccin. Los pasos propuestos por el
OpenUP se pueden aplicar para la implementacin de una solucin
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 solucin de BI necesite de la ayuda de
mdulos complementarios o cdigos de un lenguaje de programacin.
En el OpenUP para BI se propone un paso ms 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 segn 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 validacin.
4. El rol correspondiente, segn la naturaleza del entregable, realiza
la validacin. El resultado de la validacin es de mutuo acuerdo
entre el Desarrollador y el rol revisor. El rol revisor presenta el
40

informe

de

validacin

al

Director

del

proyecto

para

la

correspondiente actualizacin del plan de iteracin.

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 extensin realizada.
Fase de concepcin:
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 informacin
inicial para lograr formular el proyecto de BI. El enfoque clave de los
analistas es la recoleccin 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
informacin 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 tecnologa
involucrada.
Como es propio de la metodologa OpenUP, esta informacin es til para
el Director del proyecto en preparar los documentos necesarios para
negociar el proyecto con la empresa. En esta fase tambin 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 concepcin del modelo propuesto

Fase de elaboracin:
Esta fase es muy importante para todo tipo de proyecto, incluso en el
proyecto de BI. Es posible representar el funcionamiento de la aplicacin
de BI a travs de un diagrama de caso de usos del sistema as como su
respectiva documentacin de especificacin 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 fsico del DW. Lo que se resalta en este

modelo es tambin la BD intermedia, que sirve en la mayora de
proyectos de BI, debido a la complejidad y problemas de los sistemas de
informacin de una empresa, como una BD de apoyo en el proceso de
ETL.
En estas metodologas de UP se delega la responsabilidad a los
desarrolladores de hacer el Diagrama de Clases de Diseo, que es un
diagrama que representa la estructura real de la aplicacin. En el caso de
este modelo varia este asunto, pues tal diagrama no es necesario a
menos que se complemente con un mdulo de Software que ayuda de
forma complementaria la obtencin de informacin.
En este modelo se est responsabilizando a los desarrolladores la
Metadata o mapeo de los datos, se representa segn formato utilizado, el
paso de los datos desde la BD Operacional al Datawarehouse, si es
necesario la BD Intermedia tambin se representa en este formato.
Como tambin 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. Adems 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
validacin del Arquitecto, todo debe estar conforme segn la arquitectura
propuesta. El objetivo es tener un documento que sirva como gua para la
construccin de la aplicacin de BI.

43

Figura 8 Esquema de la fase de elaboracin del modelo propuesto

Fase de construccin:
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
construccin sean segn los temas del negocio, esto significa que el
cumplimiento de cada tema sera un logro inmediato de toda la solucin
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; tambin el cdigo propio de la lgica del ETL
y al generacin de los cubos y reportes segn los requerimientos.
Como es propio del OpenUP los Administradores del proyecto siempre
estn 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 construccin del modelo propuesto

Fase de transicin:
En esta fase se ejecutan los procesos propios del OpenUP, la idea es que
la aplicacin sea implementada y probada en un entorno real de trabajo
con la manipulacin de los usuarios reales. Por ejemplo se de probar el
DW en la arquitectura de hardware destinada y utilizada en el rea de
produccin 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 capacitacin, deben saber manipular los datos para
preparar la informacin que realmente necesitan.
Esta fase concluye con la aceptacin del stakeholder y por ende finaliza el
proyecto.

45

CAPTULO V
VALIDACIN Y ANLISIS DE LOS RESULTADOS

Los resultados se obtuvieron a travs de los controles de avances

realizados en las horas de clases como requisito del curso, tutora fuera
de las horas de clases y a travs del equipo de auditora (alumnos del 4to
ao de la Escuela de Ingeniera de Sistemas), un ejemplo de los informes
de auditora se encuentran en el anexo 9. En la tabla 2 se tiene como
ejemplo la calificacin obtenida por los grupos del proyecto de BI en cada
revisin 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 comparacin al rendimiento de trabajo por el
cumplimiento del modelo tradicional BDLC de Kimball.
Con respecto a la primera etapa, durante la ejecucin del proyecto previo,
los resultados se validaron con los interesados, gerentes de PU. Esta
46

validacin 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 deba trabajar en el mismo escenario y
como mnimo lograr lo mismo del proyecto previo. Se sabe que a pesar de
trabajar en el mismo escenario los resultados seran 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
implementacin y ejecucin del modelo en la misma empresa con la
intensin de capturar los requerimientos necesarios por parte de la
empresa, evaluar la problemtica as como analizar el mbito del proyecto
y los indicadores que servirn en el control de los siguientes proyectos.
Este proyecto previo permiti adems, 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
ejecucin de hasta ocho equipos de proyecto en la validacin de la
investigacin propuesta.
En el anexo 1 se muestra el Project chrter de este proyecto previo
incluyendo el cronograma estimado. La duracin 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 implementacin 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 metodologa OpenUP para que se adapte a una
implementacin de BI.
47

Como parte de la ejecucin 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 anlisis se plante que la Base de Datos necesita ser

corregida, si no se corrige afectara negativamente a cualquier
implementacin de BI. Por consiguiente se tiene que crear una Base
de Datos intermedia entre la Base de Datos Operacional y el
Datawarehouse.

La tabla crtica era DATOS_CLIENTES no solo por su importancia

en el tema de ventas sino tambin por su dependencia con la tabla de
vendedores y aun ms por los demasiados errores de datos y
estructura. La representacin 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 tambin todos los cdigos como llave primaria de la
Base de Datos Operacional que hacen referencia al registro actual y
nico del cliente.

En todos los procesos de anlisis se tuvo el apoyo del Analista

Funcional de Ventas de PU la cual permiti la obtencin de los
requerimientos del rea de ventas, apoyo del rea de informtica de
PU y el acceso a los datos correspondientes. Como producto final del
anlisis 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 segn la fecha, el producto, el cliente y poltica y su relacin

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 clculo 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 transformacin
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 grficos estadsticos).

Se tuvo la aceptacin de los usuarios finales, gerentes de las reas

relacionadas a la venta en PU. Esta aceptacin valid los entregables
generados, la cual seran 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 validacin hecha por los usuarios de PU en
el proyecto previo.
Con respecto a la segunda etapa, se compara el cumplimiento del modelo
o metodologa que siguieron los proyectos en base al cumplimiento del
primer criterio.
En la tabla 3 se muestra una calificacin en el intervalo de 0 a 3 en base
al cumplimiento de los criterios en comn del modelo tradicional y el
OpenUP para BI y adems con los entregables validados bajo primer
49

criterio. La calificacin obtenida por los alumnos fue en base a la escala

vigesimal, para la investigacin se realiz un resumen por grupos en la
escala de 0 a 3, en la tabla 3 se muestra el detalle del criterio de
evaluacin:

Tabla 3 Criterio de evaluacin.

Criterio

Valor

No cumpli

Cumplimiento pobre

Cumplimiento medio

Cumplimiento aceptable

La tabla 4 est dividida por 2 secciones que son: la primera seccin

formados por los grupos que no aplicaron el OpenUP para BI en el
periodo del 2008, se centraron en cumplir de la manera tradicional
basndose en forma general en el modelo BDLC de Kimball, los grupo
correspondiente a esta seccin utilizaron los conocimientos y formatos
propuesto en el PMBOK. Y la segunda seccin 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 investigacin.
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 tena que escoger
una de ellas.
El primer periodo correspondiente al ao 2008, se formaron 4 equipos de
trabajo cada proyecto con una solucin de BI particular, adems cada dos
equipos con una herramienta de BI distinta de trabajo tales como
MicroStrategy, SQLServer2005, Pentaho, Oracle 10g. Se les mostro como
capacitacin previa, los conceptos propio de BI, as como lo que propone
50

el modelo de Kimball. La capacitacin detallada sobre los procesos a

seguir fue durante el periodo acadmico.
El segundo periodo correspondiente al ao 2009, con el equipo de trabajo
reunido, alumnos del quinto ao de Ingeniera 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
metodologa 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 acadmicas o de distribucin libre
en internet por fines de investigacin.
Los criterios de evaluacin mostrados en la tabla 4 estn agrupados en 4
grupos principales que son: gestin, requerimientos, arquitectura y
desarrollo. A continuacin procedemos a analizar los resultados de cada
uno de ellos:
A) Gestin:

Formacin del Project Charter, en este tem se evala el proceso

aplicado por los grupos, en el caso de los grupos bajo el modelo
tradicional, prefirieron seguir lo aprendido de la gua del PMBOK,
reconocieron

que

el

modelo

tradicional

no

ofrece

detallada

informacin 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 gua principal los
tems de los formatos del OpenUP,

en su Project Charter se

evidenci una mejor nocin de lo que esperaban realizar durante el

proyecto, esto es debido a la informacin dada por los roles
correspondiente, la cual cada uno saba el mbito de informacin 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 servira para
51

que los equipos de proyecto especifiquen su plan y sus iteraciones

propias de su proyecto tenindolo como referencia.
El control de los formatos, en este tem el equipo de gestin deba
uniformizar y controlar los formatos propuestos. Los grupos bajo el
modelo tradicional tuvieron que estructurar los formatos en base a la
gua del PMBOK, los formatos de un nivel tcnico 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 calificacin aceptable al respecto. Los que
aplicaron el OpenUP para BI tuvieron esta ventaja con respecto al
tiempo y la integracin de la idea del proyecto, Cumpliendo con la
metodologa OpenUP se generaron documentos por iteraciones, una
muestra se encuentra en el anexo 5. Se utiliz el plan de iteracin
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 mayora 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 tcnica 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 Evaluacin 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
Formacin 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 Fsico
Formato del Meatadato Fuente
Validacin 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
Configuracin 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 adaptacin en la ejecucin del proyecto

fue ms rpido. De los grupos bajo el modelo tradicional y los que
aplicaron el OpenUP para BI sufrieron un atraso en la fase de anlisis
o de elaboracin especialmente por identificar los indicadores
apropiados para una solucin de BI. En cambio en el proceso de
adaptacin y ejecucin de los procesos, se not que en la fase de
anlisis del grupo bajo el modelo tradicional fue ms lento debido a
que hubieron confusin 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
comn en el entorno de trabajo real.

Para este tem los grupos que aplicaron el OpenUP para BI tenan la
ventaja de utilizar los formatos definidos. Un documento importante
que ayuda es el Documento de Visin, se realiz un trabajo en
conjunto para que todos reciban la misma informacin, toda la
informacin y experiencia del proyecto previo fue impartida en este
momento, cada grupo desarrollo su documento de Visin, 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. Adems en
el anexo 6 y 7 se muestra como ejemplo de las entrevistas realizada
por los alumnos.
C) Arquitectura

El proceso de validacin 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 validacin, tuvieron que
esperar hasta el control de avance, realizado por mi persona, para
54

recin notar las correcciones que deban 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 fsico y el Metadata fuente. La fase de elaboracin fue la
que tuvo ms duracin. El asunto de esta prolongacin fue de
comprender los indicadores propios de una solucin de Inteligencia de
Negocios, sus componentes y todo lo que implica. Al finalizar la fase
de elaboracin se cumpli con el proceso de validacin del
Documento de Arquitectura.
D) Desarrollo
El control de los cambios se manejo adecuadamente en la mayora de
los grupo que aplicaron el OpenUP para BI, por ejemplo cuando se
deba realizar algn cambio en el cdigo del ETL donde requera
agregar un campo ms en la tabla del DW, el Desarrollador saba que
tena que modificar su cdigo, el Analista proceda a realizarlo en sus
respectivos diagramas, el Arquitecto proceda a validar con la
coherencia de la Arquitectura propuesta y el jefe de proyecto se
encargaba de controlar los tiempos adecuados de modificacin 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 cdigo 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 adems
55

porque la herramienta de MicroStrategy no presenta este mdulo, en

el anexo 10 se muestra como ejemplo el cdigo en PL/SQL. Los
equipos que utilizaron la herramienta de Oracle tambin decidieron
desarrollar el ETL con cdigo PL/SQL en este caso por la dificultad de
entender la herramienta de Oracle por parte de ellos.

En esta fase se logr la ejecucin satisfactoria del ETL en la mayora

de los equipos de proyecto, durante este proceso se tuvo que afinar
en varias ocasiones el cdigo SQL para optimizar la carga de los
datos al Datawarehouse.

Durante este periodo se prepar a alumnos de 4to ao para que

simulen proyectos de auditora, tales proyectos de auditora tenan
como objetivo las pruebas en los cdigos y procesos del equipo de
proyecto de BI y de esta manera se estara cumpliendo con el rol
Tester del OpenUP. El equipo de auditora valido al equipo de
proyecto de BI no solo en lo que propone el OpenUP sino tambin
con respecto a la Norma Tcnica Peruana (NTP) ya sea la 12207 o la
17799, segn criterio de equipo de auditora. En el Anexo 9 se
muestra uno de los documentos generados por el equipo de auditora.

La figura 10 muestra en resumen que los equipos que aplicaron el

OpenUP para BI tuvieron mejor desempeo y mejor resultado en los
entregables del proyecto dentro del periodo acordado segn la
planificacin de cada proyecto. Con respecto a la gestin del proyecto,
todos tuvieron un buen desempeo debido a la experiencia previa en
temas de gestin 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 anlisis, especialmente la
captura de los requerimientos debido a la gua del OpenUP para BI por el
orden e interaccin de los roles, formatos y procesos definidos.

56

Figura 10 Resumen comparativo del la evaluacin del grado de cumplimiento de los tems claves del proyecto de BI.

57

Con respecto a la Arquitectura y Desarrollo notamos que existe un

desempeo 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 desempeo que los equipos que no lo aplicaron.
Los modelos tradicionales de BI como el OpenUP para BI no son
tutoriales para ensear a construir una solucin de BI, simplemente son
guas de procesos que facilitan el orden de trabajo en los respectivos
proyectos, es por este motivo que notamos una baja del desempeo de
los equipos en la Arquitectura y aun ms en el Desarrollo.
El mejor desempeo en la Arquitectura y Desarrollo de los equipos que
aplicaron el OpenUP para BI es debido a la gua adecuada desde la
Gestin de proyecto y Requerimientos. Las buenas prcticas conocidas
con respecto al desarrollo de software respaldan el resultado obtenido
mostrado en la figura 10.

58

CONCLUSIONES
1. La utilizacin de formatos adecuados permite tener una visin de lo
que se tiene que lograr, Los formatos propios del OpenUP mas las
extensiones realizadas ayudaron a que la persona tenga una nocin
de la informacin que necesita y la informacin que debe generar.
2. La correcta distribucin de las tareas segn el perfil del rol que se
desempea ayuda en la gestin, coordinacin, aprovechamiento del
tiempo y la calidad del producto con respecto a los cambios. Adems
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 retroalimentacin inmediata,
la cual permite incrementos controlados y validados. Aplicar esta
ventaja del UP en proyectos de BI es adecuado debido adems por el
desarrollo por temas.
4. El modelo propuesto es aplicable para proyectos de implementacin
de Inteligencia de Negocios, segn el alcance de esta investigacin,
en soluciones para mediana y pequeas empresas, esto es factible
debido a la similitud de los procesos de implementacin de BI con
procesos de desarrollo de Software.

59

RECOMENDACIONES
1. Se recomienda de un profesional Ingeniero que asegure el
cumplimiento de la metodologa. La ventaja de la metodologa
OpenUP es que tiene una estructura bsica de desarrollo, la cual
permite su adaptacin. Con respecto a la calidad, no est muy bien
considerada en esta metodologa la cual se requiere la presencia del
rol Ingeniero de procesos para reforzar este asunto, para la ejecucin
de los proyectos, el profesor cumpla con este rol.
2. La UPeU debera apostar por esta tecnologa, 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 tambin se aventura a realizar
proyectos de implementacin de BI donde la complejidad o alcance
del proyecto sea baja o media. El tiempo de aprendizaje sera ms
rpido y sera la base para entender otras metodologas de
implementacin de BI.
4. Para proyectos de mayor envergadura sera bueno analizar el
modelo. Se recomienda roles especiales de control y revisiones
constantes de los avances del proyecto. Adems para proyectos de BI
de mayor envergadura es posible apoyarse en los diagramas de caso
de uso del negocio.
5. Se recomienda adems como modelo de aprendizaje en institutos o
Universidades con especialidades de Ingeniera de Software, Gestin
de TI, Ingeniera de Sistemas o afines.

60

LISTA DE REFERENCIAS
Alexandre C. 2003. Sistemas de Informacin 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.
Fernndez 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 Tecnologa 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. Metodologas 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. Diseando 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 Construccin 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. Publicacin del Programa de Apoyo a la
Competitividad de la Industria del Software PACIS. Pgs. 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 Dont 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

investigacin.

Prototipo de Solucin de Business Intelligence y

optimizacin de Base de Datos para Productos Unin

67

Objetivo del proyecto

1.1. General
Implementar una solucin de Business Intelligence (BI) como
prototipo en el rea de ventas de Productos Unin (PU).
1.2. Especfico
Proponer mejoras en la Base de Datos operacional de PU.
Crear una Base de Datos en Desarrollo replicada y optimizada
para PU.
Aplicar tecnologa actual en solucin de BI.
Generar Reportes tiles para la toma de decisin Gerencial de
PU.
2. Beneficios
El Sistema (por ser un prototipo) servir para que las Gerencias
respectivas decida si conviene invertir en esta determinada
tecnologa.
La Gerencia de Ventas podr tener la informacin del
comportamiento de las ventas y su detalle al da 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 informacin se presenta en forma grfica en los reportes,
segn 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 podrn visualizar desde cualquier parte debido
a su entorno Web y con control de acceso.
La Base de Datos a nivel operacional ser ms segura y
trabajar con eficiencia.
Al tener una Base de Datos de Desarrollo se podr probar
alguna implementacin en ella antes de tocar los datos reales
de PU.
3. Factores crticos de xito
Compromiso de las autoridades de las empresas involucradas con
respecto a los procesos y formatos.
Buena comunicacin 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 ao
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 estn ya bajo licencia y el de Microsoft con
acuerdo para uso acadmico y para el prototipo.
Las PCs son de uso comn 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 acin

Analisis de la BD actual de PU

JP,A F

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 das
AF,JP,DBAJ
2 das

Analisis de la BD mejorada

JP,A F

2 das

Creacion de la BD mejorada

DBA J

1 da

Exportacion de datos

DBA J

2 das

DBAJ

Analsis BI para Ventas (estr uctura)

JP,A F

2 das

JP,AF

Capacitac ion BI

JP,A F,DBA J

Creacion de BD y ETL de datos

DBA J

5 das

DBAJ

Analisis BI para Ventas (cubos)

JP,A F

5 das

JP,AF

10

Analisis BI para Ventas (Reportes)

JP,A F

7 das

JP,AF

11

Implementacion (cubos , reportes)

DBA J

7 das

DBAJ

12

Pruebas f inales

JP,A F,DBA J

13

Doc umentacion

JP,A F

22 das

14

Presentac ion PU-FI

JP,A F

1 da

15

Presentac ion UPeU

JP,A F

1 da

JP,AF
DBAJ

JP,AF,DBAJ

1 da

JP,AF,DBAJ

1 da

JP,AF
JP,AF
JP,AF

70

Anexo 2: Plan de proyecto de uno de los grupos que utiliza OpenUP para
BI.
Sistema de Informacin Gerencial para Productos Unin
Plan del Proyecto

1. Introduccin.
Desde la compra de los insumos, el proceso de produccin y
estrategias de ventas as como la relacin con los clientes y el
personal debe estar controlado. Es necesario que la informacin,
generada en estos procesos, llegue ya transformada a la gerencia de
Productos Unin (PU), de tal modo que permita conocer su progreso y
tendencia.
PU es un Centro de Aplicacin, donde el estado limita el volumen
de ventas a PU, esto significa que el mercado conseguido debe ser
estratgicamente conservado. PU no cuenta con una herramienta de
informacin completa que permita recoger informacin desde los
proveedores, el proceso de produccin y las ventas, tambin carece
de

herramientas

de

informacin

que

permita

representar

el

comportamiento y tendencias de estos procesos.

El sistema actual no cubre todas las reas necesarias de PU y
adems sus datos no son confiables, existe redundancia de los datos,
la estructura de la mayora de sus tablas no permite relacionarse e
incluso existe datos innecesarios por registro que ocupan demasiado
espacio. Es necesaria muchas veces la intervencin 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 bsqueda, correccin y presentacin de la
informacin a la gerencia.
La intencin del proyecto es lograr la implementacin 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

solucin completa, esta herramienta de Inteligencia de Negocios que

ser de mucha ayuda para la toma de decisiones a nivel gerencial.

2. Organizacin del proyecto.

Personal

Roles

Descripcin

Castro Mendoza,
Jos

Jefe de proyecto

Responsable y encargado de la gestin del

proyecto

Orihuela Cornejo,
Carlos

Ingeniero de
procesos

Responsable del seguimiento y control del

cumplimiento de la metodologa Open Up.

Villena Garca, 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 tcnicos sobre el

proyecto.

Lvano Rodrguez,
Michael
Lvano Rodrguez,
Michael

Tuco Calizaya, Fredy

Ramos Sambrano,
Manuel
Valdez Jara, Edgar

Propone la herramienta con la cual se

trabajar.

3. Medidas y prcticas del proyecto.

3.1. Planificar el proyecto de investigacin en base a la
metodologa 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
metodologa Open Up y su respectiva adaptacin a los procesos

72

propios de la tecnologa de BI y considerando los siguientes

puntos:
La utilizacin de la herramienta de BI como es el Pentaho.
Proceso de ETL.
La utilizacin del lenguaje SQL.
Los intervalos de ejecucin (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 mtodo que se realizara para captar los requerimientos es
el de realizar entrevistas con el gerente de PU o con el jefe del
programa que estn involucrados en la solucin del BI y tambin
se realizar una revisin de la BD Operacional actual, revisin de
reportes generados por PU, anlisis de los requerimientos y
representacin del diagrama de casos de uso para un mejor
entendimiento del negocio. El Gerente General delimitar el
mbito de la investigacin.
3.3. Anlisis y diseo 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 mdulos:

73

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

Mdulo Data Warehouse, se disear la arquitectura que

tendr el Data Warehouse incluyendo el proceso ETL.

Modulo de BI, se realizar el diseo de la estructura de los

cubos y la estructura de los reportes necesarios para la
gerencia.

3.4. Construccin del mdulo registro de datos.

De acuerdo al anlisis aprobado por los lderes de usuarios,
se empezar a construir el mdulo. El mdulo ser probado y
aprobado antes del desarrollo del mdulo de Data Warehouse.

3.5. Construccin del mdulo Data Warehouse.

Inicialmente se instalar y configurar los servidores
necesarios para el sistema. El desarrollo ser dividido por submdulos, cada fase se encargar de un nmero especfico de
temas

priorizados,

basndose

en

estndares

existentes

mediante el proceso ETL.

3.6. Construccin del mdulo de BI.
Generar los cubos segn los temas.
La generacin y ejecucin de los reportes por cada tema.

74

3.7. Transicin.
Aprobado el sistema, se proceder a implementar los
mdulos listos para su funcionamiento por los interesados.
Tambin se gestionar la aplicacin de las reglas, polticas,
procedimientos propuestos para el buen funcionamiento del
sistema.

3.8. Medidas.
El control exhaustivo que se realizar se harn en base a las
normas tcnicas 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

Iteracin

Fase

I
1
I
2

I
3

Objetivos primarios

Plan del proyecto aceptado

16/03/09

27/03/09

Requerimientos detallados.
- Entrevista
- Revisin BD Operacional
- Revisin Reportes
Anlisis de los requerimientos.
Optimizar el modelo de BD operacional
- Disear el modelo BD actual
- Disear el modelo BD optimizado
Plan ETL
- Mapeo de los datos.
- Algoritmo / Diagrama del ETL
- Metodologa de Transformacin de
datos.
Crear el modelo para el DW
- Disear 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

Construccin

Implementacin

Transicin
Final

I
5

I
6

I
7
I
8

Fin

Elaboracin

Inicio

Implementacin de la BD y DW en
desarrollo
Ejecucin satisfactorio del ETL
Creacin del MOLAP
Tener los reportes adecuados segn
rea de inters en PU
Implementacin en desarrollo de
formularios complementarios
Validaciones del usuario final
Documento final del anlisis de los
resultados y propuesta del modelo

76

Estimacin
en das

4. Objetivos e hitos del proyecto por iteracin.

10

17

12

13

18

12
1
1

Anexo 3: Documento de Visin de uno de los grupos que utiliza OpenUP

para BI
Modelo de un BI utilizando Open Up
Visin

Fecha: 09/02/2009

Modelo de Sistema de Informacin Gerencial Basado en Business

Intelligence para la Industria de Panificacin, utilizando la
metodologa Open Up

Visin
1. Introduccin
Productos Unin (PU) fue creado en 1919 como Centro de
Aplicacin del Colegio Unin (hoy Universidad Peruana Unin).
Productos

Unin

tiene

como

misin

producir

alimentos

que

contribuyan al mejoramiento y conservacin de la salud; y como parte

integral de la Universidad Peruana Unin, apoyar en el desarrollo de
la educacin cristiana.

Por ser un Centro de Aplicacin, el Estado limita el volumen de

ventas a PU, esto significa que el mercado conseguido debe ser
estratgicamente conservado. PU no cuenta con una herramienta de
informacin completa que permita recoger informacin desde los
proveedores, el proceso de produccin y las ventas, tambin carece
de

herramientas

de

informacin

que

permita

representar

el

comportamiento y tendencias de estos procesos. Adems los datos

no son confiables, existe redundancia de los datos, la estructura de la
mayora 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 informacin automatizados tanto a nivel
operativo como gerencial que le permite competir y crecer a nivel
mundial. Desde el ao 2005 cuentan con una solucin de negocio
integrada por un sistema de tipo ERP (Enterprise Resource Planning),
tambin el 2005 implementaron una solucin para el rea de ventas
usando tecnologa de Inteligencia de Negocios (BI) y Datawarehouse
(DW). Para competir con estas empresas PU debe invertir en
tecnologa para poder crecer y conservarse en el mercado.

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

Una solucin factible es

Se tiene informacin que no es

confiable, redundante
A la reas de Producto Unin
relacionadas con la
comercializacin de sus productos
La decisiones tomadas a nivel
gerencial se basan en experiencias
personales y no est respaldada en
el anlisis de la informacin que se
produce al no ser confiable
La utilizacin de un sistema de
Inteligencia de Negocios

78

2.2 Posicionamiento del producto

Para

Productos Unin

quien

Necesita reordenar, depurar y procesar la

informacin 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 segn la necesidad de anlisis que
se requiera en el momento

En vez de

El anlisis 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

Centralizacin y depuracin de los

datos necesarios para la toma de
decisiones a nivel gerencial.

Explotacin rpida de los datos segn

necesidad del anlisis del momento.

Ser una herramienta manejable por

los gerentes de rea.

Tener opciones de pronsticos 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 INFORMACIN GERENCIAL PARA
PRODUCTOS UNIN

ESPECIFICACIN DE LOS REQUERIMIENTOS DEL SISTEMA

Introduccin
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 informacin 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 informacin.
Acceder a la informacin desde cualquier parte.
Tener opciones de pronsticos y tendencias.
Cualidades del sistema
Usabilidad
Cada usuario solicita diferentes comportamientos.
Falta de coordinacin entre reas diferentes que usan el mismo
sistema.
Diferencia de puntos de vista (prioridades) entre los usuarios.
La capacitacin para usuarios que harn uso del sistema ser por fechas
establecidas segn los roles que desempean.
Fiabilidad
Las horas de operacin para la transaccin de informacin sern las 24
horas del da, pero a la vez se realizarn el mantenimiento respectivo para
eso se tomarn un da para el respectivo mantenimiento.
El tiempo medio para reparacin 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 das, meses o aos) y crticos (prdida completa de
datos o imposibilidad de uso de ciertas funcionalidades del sistema).
Performance
El acceso del usuario al sistema tiene como mximo 5 segundos.

Los tiempos de emisin de reportes que solicite el usuario ser de cmo

mximo 1 minuto, dependiendo el tipo de reporte a solicitar.

Esta aplicacin permitir a 300 usuarios conectarse simultneamente para

hacer alguna operacin 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 tambin 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 ejecucin del sistema
de debe configurar para evitar conflictos al momento de la aplicacin.
Instalacion: Declare cualquier requerimiento especial en cuanto a la
instalacin 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 iteracin de uno de los grupos que utiliza OpenUP para
BI
Sistema de Informacin Gerencial para Productos Unin
Plan de Iteracin G4
Hitos
Hito

Fecha

Inicio de la Iteracin

15/05/2009

BD Optimizada o intermedia

27/05/2009

Documento de la Arquitectura

28/05/2009

Termino de la Iteracin

29/05/2009

Objetivos de alto nivel

Disear el modelo BD optimizado
Disear el modelo DB para el DW.
Asignacin de tems de trabajo
Nombre /
Descripcin

Prioridad

Documento
de
referencia

Asignado a

Esfuerzo
Estimado
(horas)

Estado

Horas
trabajadas

Entrevistar a la
Ing. Lizeth
Huanca
Disear el
modelo del
negocio
Disear el
modelo fsico
Controlar el
crecimiento del
DW

Audio:
AUD002.amr

Jorge
Sihuacollo

Terminado

Documento
ARQ003.doc

Juan Carlos
Pampa

Terminado

Documento
ARQ003.doc

Terminado

10

Avanzado
(75%)

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

Documento:
RISK004.doc

Juan Carlos
Pampa
Aaron
Bocanegra/
Jorge
Sihuacollo
Remy
Yactayo

Terminado

Documento:
ARQ003
Documento:
CONT004

Jorge Jack
Sihuacollo
Aaron
Bocanegra

Terminado

Terminado

82

Anexo 6: Entrevista realizada como parte del rol analista.

ENTREVISTA

Jueves 18 de Junio del 2009

Entrevista con la analista funcional de Productos Unin

Nombre Entrevistado: Ing. Lizeth Huanca
Los temas a tocar fueron:
1- Para saber que producto estn en venta y el precio que tiene, a que tablas
entramos?
Entramos a la tabla poltica, poliprod, almacn artculos.
Esta tabla solo me va dar el detalle de los productos que tiene esa poltica pero
no me da la cantidad que se esta vendiendo.
En ningn 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 almacn y los productos
devueltos?
Cuando ingresa productos al rea de produccin se hace a travs de la tabla
almacn ingresos diversos a quien se va registrar el nmeros de documentos que
tiene esos ingresos y los productos, cantidad. Los Ingresos se van a almacn y la
salida por las ventas, tambin a la tabla Pu_guias.
3- Como miden la productividad segn lo que hemos ledo 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 Gestin de la Calidad
de Productos Unin, 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 INFORMACIN GERENCIAL BASADO EN
BUSINESS INTELLIGENCE
MICROSOFT SQL SERVER 2005
1. Propsito del proyecto
El proyecto informtico que implementaremos, es un sistema de
informacin basado en Bussines Intelligence utilizando la metodologa de
desarrollo de Software Open Up con el fin de que la Gerencia de PU
conozca y pueda elegir la alternativa adecuada para su implementacin
completa en un proyecto prximo de naturaleza netamente informtica.
Adems con el apoyo de este sistema de informacin, se podr competir
con empresas grandes con estrategias basadas en la calidad de la
informacin obtenida, por ende, ayudar a incrementar el mercado ya
ganado por Productos Unin.
2. Metas y filosofas de la arquitectura
SQL Server 2005 es una plataforma global de base de datos que ofrece
administracin de datos empresariales con herramientas integradas de
inteligencia empresarial (BI). El motor de datos SQL Server 2005
constituye el ncleo de esta solucin de administracin de datos
empresariales. Asimismo, SQL Server 2005 combina lo mejor en anlisis,
informacin, integracin y notificacin, permitiendo as que el negocio
cree y despliegue soluciones de BI rentables que ayuden al equipo a
incorporar datos en cada rincn del negocio a travs de tableros de
comando, escritorios digitales, servicios Web y dispositivos mviles. En
resumen, SQL Server 2005 est diseado para ayudar a las empresas a
enfrentar desafos tales como: La necesidad de tomar decisiones ms
rpidas y ms 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 Unin trabaja con la licencia acadmica de SQL 2005
en su sistema de planillas.
Productos Unin trabaja con la licencia de Oracle 10g. Su base de
datos operacional esta en Oracle, por ende dependemos de ella.
Asignacin 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 integracin 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 informacin para que ayuden en el proceso de anlisis
para la toma de decisiones. De manera tal que dichos reportes (informacin)
lleguen cuando se requiere. Estos reportes se generarn a travs de la
herramienta de Business Intelligent (BI).
Entre los reportes requeridos en PU, captados a travs de las entrevistas
realizadas, se encuentran:
Las variables que desean medir principalmente se encuentra en el
rea de Ventas, tales como:
1. Cunto porciento debe aumentar la produccin para la
campaa navidea segn las ventas de las ltimas tres
campaas.
Son de vital importancia, ya que a travs de estos datos
estadsticos se podr prever la cantidad de insumos y personal
a utilizar
2. Segn las ventas anteriores de las campaas, Cuntos es la
tendencia de ingreso de los alumnos a cada campaa
(Verano, Otoo, Invierno y Navidea)?
86

3. Cun es el porcentaje de los productos ms solicitados por

alumnos en cada campaa?
4. De los productos ya vendidos a los supermercados, Cul es la
tendencia de devolucin del total de los productos
entregados en los ltimos cuatro aos?
5. Cul es la tendencia de las ventas por Bloques, Polticas,
Clientes y Subclientes de los ltimos tres aos?
6. Cul es la tendencia de los productos ms vendidos, segn
su bloque, poltica, cliente y subcliente de los ltimos tres
aos?

1.3 Acceso a la informacin:

El acceso a la informacin 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, mquinas de multiprocesador de 64 bits, redes de
ordenadores.
La administracin se facilita mediante interfaz grfica de usuario.
Capaz de tener varias instancias del servido en una nica mquina.
Acceso directo a datos desde pgina Web, gracias a la generacin
automtica de documentos XML, consiguiendo una completa
integracin 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).
Comunicacin perfecta con otras aplicaciones Microsoft, pudiendo
presentar informacin 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 lnea de negocios a gran
escala.
Los Servicios de Transformacin de Datos (DTS) son un conjunto de herramientas
grficas y objetos programables que pueden usarse para extraer, transformar
y cargar datos (ETL) desde fuentes muy diversas y llevarlas a un destino nico
o mltiples destinos. Data Transformation Services (DTS) para Microsoft SQL
Server 2005 introduce un rediseo completo para proporcionar una
plataforma ETL

7. Capas o marco arquitectnico

Microsoft SQL Server 2005 podemos ubicar el cdigo apropiadamente en
relacin 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
integracin. Es ms que un sistema gestor de Bases de Datos ya que incluye
mltiples componentes y servicios que la convierten en una plataforma de
aplicaciones corporativas.

Integracin entre SQL Server y Common Language Runtime (CLR)

Esta caracterstica 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. Adems 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 cachs o vistas.
Las notificaciones son generadas de forma eficiente i enviadas a
mltiples tipos de dispositivos.
88

Mltiples resultados y transacciones simultaneas para conexin

Una novedad importante es la de permitir mltiples resulsets
abiertos para conexin, 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 restriccin de configuraciones de

servicios.
3. Reduccin de la superficie de ataques para las nuevas
caractersticas.

Tipos de datos
Aparecen nuevos tipos de datos que acaban con las limitaciones del
tipo TEXT y IMAGE que tenan problemas de tamao y de
actualizacin. Concretamente aparecen los tipos VARCHAR (MAX),
NVARCHAR(MAX) i VARBINARY(MAX) que se adaptan al tamao y se
pueden actualizar directamente.

Tratamiento de errores
Desaparece el acceso a los errores a travs 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 versin anterior de los
registros. Tiene la ventaja de una lectura ms rpida y sin bloqueos,
pero tiene el inconveniente de unas escrituras ms lentas y un
tamao de Base de Datos ms 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

CORRECCIN DE LOS DATOS DE LOS CLIENTES CON LA BASE DE DATOS INTERMEDIA

93

METADATA
INDICADORES

94

95

Anexo 9: Documento de Auditora realizada por el grupo de 4to ao a los

grupos de proyecto de BI.
AUDITORIA #1
REALIZADA AL EQUIPO DE BUSSINES INTELIGENCE DE 5T0 AO

El proceso de Auditoria exige que se renan evidencias, evalen 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 Ao de Sistemas, liderado por
Lisette Chvez Pretel, para que el encargado de la empresa Productos Unin,
pueda ver como si las actividades se estn 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 informacin general del equipo de trabajo a
auditar, rigindonos en los tems del Open Up y la norma Tcnica Peruana para
esta auditora.

PERSONAL QUE PARTICIPA EN LA IMPLEMENTACIN DEL

SISTEMA:

A continuacin mencionaremos a los responsables de la implementacin del

sistema a auditar:

Jefe de Proyecto

Lisette Chvez Pretel

Analistas

Rossemery Braes Vlchez

Noem Bravo Zapata

Ingeniero de Procesos

Lisette Chvez Pretel

Desarrolladores

Noem Bravo Zapata

Samuel Cruzado

Arquitecto

Kenny Aguirre Orosco

96

PERSONAL A CARGO DE LA AUDITORIA:

Las evaluaciones y revisin de la auditoria estarn a cargo de las siguientes

personas, estudiantes de ingeniera de sistemas del 4 ao de la Universidad
Peruana Unin:

Iniciador

Giancarlo Quispe Gavino

Ing. de Procesos

Kelly sobrado Len

Arquitectos

Daniel Quispe Condori (Encargado)

Daniel Cornejo Ruiz

Registradores

Lesly Ccapa Antn

Liz Valle Yanavilca

La auditoria se realizara en base a la metodologa Open Up y la norma Tcnica

Peruana, la cual nos ayudara para poder realizar la investigacin y posteriores
recomendaciones.

COMPARACION CON LA METODOLOGA OPEN UP:

Principios del Open UP.
1) Colaborar para sincronizar intereses y compartir conocimiento. Este principio
promueve prcticas que impulsan un ambiente de equipo saludable, facilitan la
colaboracin 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 segn 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 prcticas que permiten a los
participantes de los proyectos desarrollar una solucin que maximice los
97

beneficios obtenidos por los participantes y que cumple con los requisitos y
restricciones del proyecto.
Tambin 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 segn su calendario de entregas.
3) Centrarse en la arquitectura de forma temprana para minimizar el riesgo y
organizar el desarrollo.
Segn cronograma, podemos observar que tienen planificada reuniones
tempranas para definir la arquitectura.
4) Desarrollo evolutivo para obtener retroalimentacin y mejoramiento continuo.
Este principio promueve prcticas que permiten a los equipos de desarrollo
obtener retroalimentacin 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 elaboracin del Project Charter y el cronograma de ejecucin 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 Ejecucin del Proyecto.- El cronograma es conciso

destacando las actividades ms resaltantes para el proyecto.

COMPARACION CON LA NORMA TECNICA PERUANA NTP:

La siguiente comparacin estar desarrollada en base al tem 6.1 de la
Norma Tcnica Peruana
la que hace referencia al proceso de
documentacin, donde veremos la implementacin de la documentacin,
diseo y estilo, etc.
Implementacin del proceso:

Los alumnos de 5 han desarrollado un documento su Proyect Charter donde

especifica el alcance que va tener el producto software.

98

Segn la Norma Tcnica Peruana, en el tem 6.1.1 el grupo de 5 en su proyect

charter cumplen los pasos que menciona la norma tcnica, pero en los dems
documentos como son las diferentes entrevistas realizadas no cumplen
completamente con lo estipulado en el momento de la creacin 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) Ttulo o Nombre.
b) Propsito.
c) Audiencia a la que se dirige.
d) Procedimientos y responsabilidades para las entradas, desarrollo,
revisin,
modificacin, aprobacin, produccin, almacenamiento,
distribucin, mantenimiento y gestin de la configuracin.
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 anlisis del negocio y del sistema fueron
realizadas, pero no en un documento donde detalle especficamente el anlisis.
Especificacin 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 comparacin estar desarrollada en base al tem 6.4.2.3 de la
Norma Tcnica Peruana la que hace referencia a la verificacin de los
requisitos.
Hay varios documentos donde especifican las reuniones realizadas para las
entrevistas. Ah detallan la informacin recolectada, pero no como llegaron a tener
esa informacin, no hay documentos que muestren si hicieron cuestionarios o
preparativos antes de realizar las entrevistas. Tambin se deben verificar los
requisitos y examinarlos para poder realizar el modelo del negocio.
Recomendaciones:
Se debern verificar los requisitos teniendo en cuenta los criterios enumerados a
continuacin:
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
diseo.
c) Los requisitos software son consistentes, viables, se pueden probar y reflejan
fielmente los requisitos del sistema.
d) Los requisitos software relacionados con seguridad fsica y de acceso y
criticidad son correctos, segn demuestran mtodos rigurosos v adecuados.
Observaciones:
Segn los informes presentados y las entrevistas realizadas, se puede observar que
los integrantes no estn cumpliendo sus respectivas funciones, es por ello que
algunos documentos no se estn realizando completamente de acuerdo a la norma
tcnica.

Segn 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 ao, han entregado
los informes requeridos en el momento, segn su cronograma.
Observaciones:
El grupo de Desarrollo esta caminando segn 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) Representacin del ETL con Pentaho.

102

103

2) Generacin de cubos con Pentaho.

104

3) Generacin de reportes con Pentaho.

105

Anexo 12: OpenUP para BI con el EPF.

106

107