CAPITULO II MARCO TEORICO

Este captulo est orientado a realizar un resumen de los mtodos, tcnicas y herramientas que sern aplicados en el Proyecto de grado, el capitulo tiene el objetivo de Focalizar estos aspectos que sern utilizados en el desarrollo del proyecto, introduciendo al lector en cada uno de los temas de forma concreta y bien redactada. Cada una de las afirmaciones que se realicen, deben citar la fuente de origen concluyendo con un resumen realizado por el alumno.

1.2

METODOLOGIAS. En este segmento se debe hacer referencia resumida, a las posibles metodologas que podran ser utilizadas para la realizacin del proyecto de grado, es muy importante hacer referencia a ms de una metodologa, en virtud de que la eleccin de la metodologa adecuada ser desarrollada en el captulo correspondiente. Por este motivo se debe resaltar los aspectos que marcan la diferencia entre las posibles metodologas respecto de la naturaleza del proyecto.

Enfoques metodolgicos de Business Intelligence

Submitted by ATI on 18 January, 2012 - 01:58

BI metodologia data warehouse

En este apartado vamos a revisar muy brevemente los principales enfoques metodolgicos existentes para proyectos BI, as como sus principales limitaciones. El ciclo de vida de un proyecto de BI [17][18] implica mltiples fases, cclicas y muchas veces ejecutndose en paralelo, de ah la complejidad que puede llegar a tener. Se han identificado ms de 900 tareas a ejecutar [17][19], cosa que hace que no sea del todo sencillo definir una metodologa nica. Son muchos los enfoques metodolgicos que la literatura cientfica ha tratado. Segn R. Cicchetti et al. [20] son stos:

Plan-Driven approach o Requeriment-Driven approach

Esta metodologa ms tradicional no parece adecuada para este tipo de proyectos [7] ya que este enfoque no satisfar las demandas futuras de los usuarios, y los usuarios difcilmente son capaces de definir y explicar cmo toman sus decisiones.

Demand-Driven o User-Driven o Prototype-Driven Approach Metodologas orientadas hacia la confeccin de prototipos [21] para la obtencin de los requisitos que sean lo suficientemente precisos [7]. As pues, se busca mostrar al usuario un prototipo funcional [22] para intentar captarlos lo mejor posible [23]. El punto dbil de este enfoque est en asumir que todos los usuarios conocen la estrategia empresarial y se comportan de forma coherente con ella, lo cual no siempre es as. Pero de serlo, si realmente son ellos los que van a tomar las decisiones, son ellos tambin los que deberan dirigir el proceso de creacin del sistema de BI. La idea se fundamenta en crear un primer prototipo basado en los objetivos empresariales y a partir de ah los usuarios definen las necesidades de informacin, las preguntas que le van a hacer al sistema BI, y el mantenimiento y evolucin futura [24] del mismo. B. Afolabi y O. Thiery [5] nos hablan de la importancia de usuario para definirlo basndose en sus propias fases cognitivas (observacin, abstraccin elemental, razonamiento y simbolizacin y creatividad). Se puede adaptar nuestro sistema de BI al tipo de consultas que nos har el usuario final (QueryAdaptation) y al tipo de respuestas que espera recibir (Response Adaptation) [25].

Data-Driven Approach Este enfoque [7] se centra en los datos: en cmo estn estructurados, en quin los usa, en la forma en que los usan. Se fija en los datos con mayor tasa de acceso, aquellos que se consultan con mayor frecuencia, como se relacionan entre ellos, qu consultas suelen venir asociadas. Son los datos los que dirigen el proceso. Este enfoque se basa en la premisa de que los datos nunca mienten, mientras que de los usuarios es difcil de asegurar. El problema es que en este

enfoque, a priori se deja de lado a los usuarios, los objetivos de la organizacin y los futuros requisitos del sistema.

Value-Chain Data Approach Basado en la cadena de valor del Business Intelligence [9], es una evolucin del enfoque Data-Driven focalizada en los datos que generaran mayor valor para el negocio, pero no resuelve las limitaciones de su predecesor.

Process-Driven Approach Este enfoque se basa en el anlisis de los procesos de negocio [14], la informacin que generan y la informacin que consumen. El proceso es la clave y se estructura la informacin segn sea el usuario de proceso. Un aspecto que se puede perder de vista en este enfoque, demasiado centrado en el proceso, es la perspectiva global de la organizacin y las relaciones entre procesos, lo cual puede llevar a tener una visin incompleta o errnea de la organizacin.

Event-Driven Approach Este enfoque propone dividir los procesos de negocio bajo tres puntos de vista: Datos, Funcin y Organizacin, cada una de los cuales se conecta entre s a travs de eventos. La gran ventaja de este enfoque es el anlisis funcional de la organizacin. V. Stefanov y B. List [6] proponen este mismo modelo extendido con objetos BI y conectores de informacin BI, como una manera de rellenar el gap entre el negocio y los sistemas de BI. Este enfoque es muy complejo de llevar a la prctica y requiere una gran experiencia y modelos organizacionales muy maduros.

Object-Process Driven Approach Es una de las variantes metodolgicas a medio camino entre el EventDriven y el Process Driven [13]. En este enfoque, tanto los objetos

como los procesos tienen la misma importancia desde el punto de vista decisional y por tanto se deben tratar de la misma manera.

Joint Approach Enfoque metodolgico centrado en el reconocimiento de las arquitecturas funcionales cruzadas de las empresas. Los procesos no son de un solo departamento, sino que existen muchos puntos de contacto y muchas junturas[11], por lo tanto es donde se tiene que centrar el esfuerzo. La idea es que la organizacin es una matriz de procesos con diferentes necesidades de informacin, pero all donde se juntan es donde debemos hacer el mayor esfuerzo. La dificultad del enfoque puede radicar en la dificultad en definir los procesos de gestin y control de la informacin en estos puntos de contacto.

Goal-Driven Approach Este enfoque [7] se centra en el objetivo de los procesos estratgicos de la organizacin y se basa en el anlisis de la interaccin que tanto clientes como usuarios hacen para conseguir dicho objetivo. A partir de ah establece necesidades de informacin e interrelaciones entre ellas que darn lugar a la estructura del sistema de Business Intelligence. El problema puede aparecer cuando no existe un conocimiento o alineamiento preciso entre los procesos estratgicos y los tcticos u operacionales.

Triple-Driven Approach Vista la inmadurez de las metodologas de Business Intelligence, en Y. Guo et al. [12] apuestan por una combinacin de las mejores ideas de cada una de las metodologas Goal, Data y User Driven, creando la Triple-Driven, pues se considera que estos tres enfoques son perfectamente compatibles.

Model Driven Approach

Otra de las metodologas que se han usado en BI es la Model Driven [3][4]. Con ella, se pretende tender un puente entre el negocio y el departamento de Informtica, intentando proporcionar la base para desarrollar soluciones rpidas, que evolucionen fcilmente y flexibles. Debido a su alto nivel de la reutilizacin de la abstraccin y del cdigo, la metodologa MDA (Model-Driven Architecture) se ha aplicado extensamente. El MDA permite reducir tiempo de desarrollo de software, y mejorar la calidad y el mantenimiento de la solucin. Pero por el contrario, es difcil definir este modelo simplificado de la realidad y an es difcil de implantar sobre arquitecturas SOA (Service-Oriented Architecture) y en organizaciones reales.

Adaptive Business Approach La metodologa Adaptive Business Approach[8] se basa estrictamente en aquellos aspectos realmente relevantes para el negocio y su evolucin. Se centra en los problemas que el negocio tiene que resolver para adaptarse a los cambios del mercado y en los datos de que disponemos para ello. El resultado de los sistemas de Business Intelligence han de ser o bien la solucin al problema o bien la aportacin de ms conocimiento sobre el problema para seguir analizando y tomando decisiones para hallar dicha solucin. El centrarse en slo lo relevante para el cambio, puede dejar de lado o no considerar explcitamente otros aspectos no tan crticos del negocio, pero que determinan o influyen en aspectos ms relevantes. Por lo tanto estas dependencias tienen que tenerse en cuenta explcitamente y no obviarse.

Agile Approach Si este enfoque puede considerarse novel en el rea de Ingeniera del Software, lo es ms en el rea de Business Intelligence. La primera referencia acadmica que encontramos referente al uso de las metodologas giles en BI es un pequeo articulo divulgativo en el ao 2001 de apenas 2 pginas en el que L.T. Moss[10] comenta que sera posible realizar proyectos de Business Intelligence con rigor usando las metodologas giles. Posteriormente, J. Fernndez et al. [26] analizan la correlacin entre los principios bsicos de las metodologas giles y las necesidades de una metodologa de BI. Entre tanto, algunos trabajos adicionales aparecen, pero sorprende la reducida cantidad de trabajos acadmicos del tema respecto al

enorme nmero de artculos de experiencias reales del tema, creciendo exponencialmente en 2011.

1.3

ARQUITECTURAS. En este acpite se debe describir las posibles arquitecturas que podran ser las ms adecuadas para la realizacin del proyecto, es importante remarcar que nos referimos a arquitecturas establecidas de manera formal. Se deben resaltar los aspectos que en el desarrollo del proyecto sern utilizados para elegir una arquitectura o plantear muevas arquitecturas, las cuales eventualmente pueden ser combinaciones de las existentes, pudiendo ser una posible solucin arquitectnica del proyecto.

1.4

MANEJADORES DE BASES DE DATOS. Este acpite est destinado a describir los manejadores de bases de datos que son candidatos a ser elegidos en el desarrollo del proyecto, para ser parte de la solucin. En el resumen de los manejadores de bases de datos, se deben resaltar aspectos tcnicos tales como: Desempeo, Integridad, Tolerancia a Fallos, Carga del Sistema, Portabilidad, Estndar SQL, Soporte de Disparadores (Triger), Tipo de Licenciamiento (dimensionando los lmites), etc. Los cuales sern valorados al momento de elegir el manejador de base de datos ms adecuado para el tipo de proyecto y caso de estudio que se est desarrollando. Es por esta razn que conviene realizar mayor nfasis en aquellos atributos tcnicos que sern ms valorados en el proyecto.

1.5

HERRAMIENTAS DE DESARROLLO Las herramientas de desarrollo que sean posibles alternativas para el desarrollo del proyecto, deben ser mencionadas en este segmento, teniendo el cuidado de resaltar los aspectos de las mismas que contribuirn al logro de los objetivos del proyecto.

1.5.1

ENTORNOS DE TRABAJO. En este segmento se deben resaltar los posibles entornos de trabajo (framework) que podran ser utilizados en el proyecto, se debe resaltar de los mismos aquellos aspectos tcnicos que interesan para lograr las metas del proyecto, estos pueden ser: Arquitectura, Portabilidad, Orientacin, Reusabilidad, Dimensin de sus Componentes, Lenguajes Anfitriones, etc.

1.5.2

LENGUAJES DE PROGRAMACION. Este acpite est orientado a describir los atributos de los lenguajes anfitriones, que probablemente sean elegidos en concordancia con algunos de los entornos de trabajo o (framework) descritos en el acpite anterior, considerando en la redaccin que esta conjuncin, podra ser la herramienta adecuada para viabilizar las metas del proyecto.

1.5.3

HERRAMIENTAS DE DIAGRAMACION. Es posible que en el desarrollo del proyecto se deba recurrir a utilizar algunas herramientas de diagramacin que permitan utilizar los diagramas requeridos por las metodologas descritas, en el acpite correspondiente. Si este es el caso en este segmento se debe describir brevemente las mismas.

1.5.4

OTRAS HERRAMIENTAS. Probamente en el desarrollo del proyecto se vayan a utilizar otras herramientas, tales como productos de software para B.I. (ejm: Discovery, Pentajo, etc), en su caso motores de workflow tales como ProcessMaker. Si este fuera el caso del proyecto que se est desarrollando, estas herramientas deben ser descritas en este acpite de forma resumida.

1.6

OTRAS METODOLOGIAS. Es posible que sea necesario recurrir a otras metodologas que son perifricas al objetivo principal del proyecto, pero necesarias para el desarrollo del mismo. Metodologas para la estimacin de costos de software u otros aspectos, en este caso estas metodologas deben ser descritas en este acpite de forma resumida.