10 Metodologias De Proceso De Software

Evaluación de 10 Metodologías de desarrollo de software

Rossetti, Maximiliano1 – Robert 1

1 Maestría en Ingeniería en Sistemas, Universidad Tecnología Nacional, Facultad Regional Córdoba

1Cristian_fanjul@yahoo.com.ar, 1maximilianorossetti@gmail.com, 1juanscida@gmail.com

Resumen. En el ciclo de vida del desarrollo de un DW implica gestionar cambios en las necesidades de información y las herramientas para la carga, almacenamiento, transformación, consulta y análisis de datos sufren un permanente cambio, como así también el ámbito de negocios.

Estos cambios necesitan ser controlados y bien administrados, con el fin de brindar información correcta en tiempo y forma. Es por ello que contar con un adecuado marco de trabajo, sobre el cuál basarse, puede resultar crucial en el éxito de un proyecto.

A continuación, presentaremos un estudio sobre las alternativas de cómo encarar la gestión y análisis de los requerimientos para la construcción de un Data Warehouse, tomando como referencia los enfoques propuestos por Bill Inmon (data-driven) y Ralph Kimball (requirement-driven), sobre los que se efectúa una comparación y se evalúa un framework de trabajo basado en uno de ellos: DWARF.

Palabras Clave: Data Warehouse (DW), Real-Time, OLAP, Business Intelligence (BI), ETL (Extracción, Transformación y Carga) , Data Mart

1. Introducción

La complejidad de los negocios actuales ha modificado la forma de administrar de las empresas. Los gerentes empresariales no sólo necesitan saber que está sucediendo en el negocio, sino además por qué. En la fase de aplicar tecnología de la información para automatizar el procesamiento de datos, las empresas desarrollaron aplicaciones para medir con rapidez el factor “¿qué está sucediendo?”.

Ahora, en la fase de procesamiento de la información, las empresas requieren conocer el factor “¿por qué está sucediendo?”; el ambiente competitivo y el ritmo de cambio lo demandan así. Las empresas desean pasar con rapidez a la siguiente fase. “¿qué debemos hacer y cuáles son los riesgos?”.

Para contestar estas preguntas se manejan datos a nivel estratégico, para obtener un conjunto de estrategias y herramientas enfocadas a la administración y creación de conocimiento mediante el análisis de datos existentes en una organización o empresa.

Estos datos son manejados a través de los DW, los cuales poseen requerimientos específicos dependiendo de la empresa en la cual se implementen.

Los estudios muestran que el 40% todos los proyectos que incluyen DW nunca se desarrollan, y el 85% fallan al no tener claro los objetivos de negocio [1].

Es por esto que los métodos de definición y gestión de requerimientos son la influencia máxima para un proyecto de DW, y ante requerimientos cambiantes, la gestión de cambios de un DW es uno de los temas más preponderantes para obtener un DW eficiente y útil para la toma de decisiones empresariales.

En este artículo se expone una comparación entre las metodologías de diseños de DW propuestas por Inmon y Kimball, y cómo son manejados los requerimientos de software en cada una de ellas y las consideraciones que se tienen sobre éstos.

1.1. Generalidades

A pesar de que todos los DW son diferentes, hay cuatro requerimientos de DW que son comunes en casi todos: tamaño, herramientas de gestión de datos, estructura y plataforma de software. Un DW es cualquier sistema utilizado para almacenar grandes cantidades de datos en un formato que permite la extracción de datos y de desarrollo de informes. Estos cuatro requerimientos manejan todas las decisiones que rodean la instalación y el mantenimiento de un DW con éxito.

Los requerimientos de DW para las instalaciones y el hardware utilizado pueden ser muy complejos, debido a que estos requerimientos dependen de una combinación de factores conocidos y desconocidos. El mínimo de tamaño para el espacio físico siempre debe incluir el equipo actual, así como los planes para una futura expansión. El espacio real requerido para el aumento de la capacidad de almacenamiento disminuye a medida que el proceso de fabricación para los servidores mejora.

Las herramientas de gestión de datos se utilizan para mover datos dentro y fuera del DW. El tipo y la complejidad de software utilizado es un requisito fundamental DW. El mejor ajuste de software depende de la funcionalidad requerida, el usuario previsto y la complejidad de los datos solicitados desde el almacén.

Los requerimientos de DW incluyen la selección de la estructura de DW. Hay varias estructuras disponibles, y la selección depende de los datos que se añaden al DW, la complejidad de las consultas reales con los datos y la sofisticación de los usuarios. La plataforma de software es un elemento esencial de las necesidades de DW y manejar muchas de las decisiones que rodean al soporte y mantenimiento de la herramienta.

2. Trabajos relacionados

Sólo algunos enfoques han considerado el análisis de requerimientos como una tarea crucial en las primeras etapas del desarrollo del DW. En [10], se propone un método con el fin de determinar las necesidades de información de los usuarios de DW y combinar estos requerimientos con las fuentes de datos disponibles. El enfoque descripto en [9] se centra en la descripción de un proceso de obtención de requerimientos para DWs identificando las metas de los responsables de la toma de decisiones y la información requerida. Por último, en [11], los autores presentan un marco orientado a los objetivos de los modelos de requerimientos para DWs, obteniendo así un modelo conceptual de los mismos mediante el uso de un conjunto de directivas. Desafortunadamente, estos enfoques presentan un inconveniente clave: no proporcionan mecanismos formales para asegurar la trazabilidad entre el modelo de requerimiento y el modelo conceptual, que es una propiedad deseable sólo como se indica en [12]. Estos enfoques sólo proporcionan un conjunto de directivas informales para derivar un modelo conceptual de los requerimientos.

3. Definición de Requerimientos de un DW

Los requerimientos para el sistema de DW determinan qué datos deben estar disponibles, cómo están organizados, y con qué frecuencia se actualizarán. Es ventajoso para iniciar el proceso de recopilación de requerimientos con un descubrimiento comercial macro (ver – ), que es necesario identificar los procesos clave del negocio, las métricas claves para las tomas de decisiones, medidas y requerimientos. Un modelo de alto nivel tiene que ser desarrollado en la manera que representa la forma de hacer negocios [2].

El método de recolección de requerimientos comienza con el análisis de las fuentes de datos. El diseñador selecciona qué porción de los datos disponibles en las bases de datos corporativas son relevantes para la toma de decisiones. El enfoque más utilizado es el manejado por requerimientos (requirements-driven en inglés), que prioriza los requerimientos del usuario por sobre los requerimientos de datos (data-driven en inglés), lo que hace que requiera más esfuerzo en el diseño de la arquitectura de las ETL [3].

Fig. 1 – Cada requerimiento estipulado en el contexto del DW, generará un tipo de diseño diferente, por ello es que el sistema deberá tener un balance entre capacidad, tiempo de respuesta, consistencia de datos, costo, hardware necesario (crítico por la escalabilidad), y otros factores que definen una arquitectura y una metodología de DW. En el relevamiento de requerimientos hay tres perspectivas bien delineadas, Perspectivas de Negocio, de los Usuarios, y de Implementación.

3.1. Perspectiva del Negocio

Los requerimientos de la perspectiva de negocio representan objetivos de alto nivel de la organización para el sistema de DW. Son capturados principalmente en un documento que describe la visión y el alcance del proyecto.

Los requerimientos de negocio identifican los principales beneficios que el sistema de DW proporcionará a la organización y sus usuarios. Ellos representan el nivel más alto de abstracción en la cadena de requerimientos. Expresan las oportunidades de negocio, objetivos de negocio y describir los usuarios típicos y los requerimientos de la organización, además del valor que proveen al sistema en un nivel alto, tal como lo grafica la Fig. 2 - Requerimientos de Negocio

Fig. 2 - Requerimientos de Negocio

3.2. Perspectiva del Usuario

Los requerimientos desde la perspectiva del usuario se describen las tareas que los usuarios deben ser capaces de llevar a cabo con la ayuda del sistema de DW. Estos requerimientos deberán ser obtenidos de personas que realmente utilizan y trabajan con el sistema de DW. Las necesidades de los usuarios deben alinearse con el contexto y los objetivos establecidos por los requerimientos del negocio. Estos requerimientos pueden ser capturados en casos de uso o descripciones de escenarios, que se centran en lo que los usuarios necesitan ver en el sistema de DW, lo que significa que serán mucho más completos y mejores que el enfoque tradicional de elicitación, donde los usuarios los que indican lo que el sistema debe hacer. La Fig. 3 - Requerimientos de usuario - muestra una plantilla para las necesidades del usuario.

Fig. 3 - Requerimientos de usuario

3.3. Perspectiva de implementación

Los requerimientos de una perspectiva de implementación representan los requerimientos de un DW en un nivel detallado. El alto nivel de detalle facilita la especificación completa, la granularidad de los requerimientos, que son un insumo importante para el equipo de desarrollo de un DW. Éstos deben alinearse con los requerimientos del negocio y de usuario. Los requerimientos funcionales definen la funcionalidad que el equipo de desarrollo debe basarse en el sistema de DW para permitir a los usuarios realizar sus tareas, satisfaciendo así los requerimientos del negocio. Los requerimientos de información definen necesidades de información de la organización. Describen la información y los datos que el DW debe entregar o debería tener acceso.

Por otra parte, los requerimientos de la interfaz aumentan la descripción de los requerimientos funcionales y de información mediante la descripción de las características en diferentes dimensiones que son importantes tanto para los usuarios o para el equipo de DW. Son propiedades o cualidades que el sistema de DW debe tener (Fig. 4 - Requerimientos de implementación). Por ejemplo, cuando se conocen los requerimientos funcionales, se puede determinar cómo se van a comportarse un DW, qué cualidades tendrá, y qué tan grande o rápido debería ser. Cuando se conocen los requerimientos de información, sus atributos se pueden determinar, como la calidad o la granularidad. La muestra una plantilla para la especificación de requerimientos funcionales y de información incluyendo sus atributos.

Fig. 4 - Requerimientos de implementación

4. Metodologías bajo estudio [4]

4.1. William Inmon

Inmon ha puesto en claro una buena síntesis de lo que es un DW, debido a que provee guías concretas para construirlo. Implícitamente, esta definición sustenta uno de los principios fundamentales del desarrollo de un DW, que el ambiente de origen de los datos y el ambiente de acceso de datos deben estar físicamente separados en diferentes bases de datos y en equipos separados.

Inmon también identifica la importancia de utilizar un DW para guardar datos históricos continuos, ya que uno de los mayores obstáculos para el análisis de información relevante es no contar con datos disponibles en un periodo de tiempo extendido. Se tiende a almacenar solamente una vista actual del negocio, lo cual es un período muy corto para un análisis de tendencias.

A Inmon se le asocia frecuentemente con DWs a nivel empresarial, que involucran desde el inicio todo el ámbito corporativo, sin centrarse en un incremento específico hasta después de haber terminado completamente el diseño del DW. En su filosofía, un Data Mart es sólo una de las capas del DW, los Data Marts son dependientes (obtienen la información) del DW Corporativo, es decir, se construyen posterior a él.

El enfoque de Inmon de desarrollar una estrategia de DW e identificar las áreas principales desde el inicio del proyecto es necesario para asegurar una solución integral. Esto ayuda a evitar la aparición de situaciones inesperadas en el futuro cercano del proyecto que puedan poner en peligro la información, debido a que se conoce anticipadamente y con bastante exactitud la estructura que presentarán los principales núcleos del desarrollo, lo cual permite enfocar los esfuerzos del desarrollo actual para ser compatible con los subsiguientes.

Inmon es defensor de utilizar el modelo relacional para el ambiente en el que se implementará el DW Corporativo, asegura que esta es la alternativa más adecuada para que el almacén central sea más eficiente sin afectar a los usuarios finales ya que la frecuencia de acceso de los mismos es muy escasa a este nivel. Mientras, aplicará al esquema estrella o modelado dimensional a la aplicación Front-End que llama al Data Mart, y que es donde realmente tiene lugar el acceso de los usuarios.

Inmon ciertamente coincide en que el modelado dimensional está bien para los Data Mart, pero hace énfasis en que estos deben ser dependientes del DW Corporativo; sin embargo está muy convencido que un diseño basado en Diagramas E-R es mucho más apropiado para el DW central de mayor magnitud. La estructura ideal que se busca para un DW, porque proporciona la manera más efectiva de colectar, almacenar y diseminar la Información, es muy probablemente:

• Datos antiguos, limpiados en un RDBMS (un DW Empresarial).

• Datos reconciliados, desde el DW Empresarial obtienen su información los Data Marts, cubos y otras herramientas para análisis y reportes que utilicen un enfoque multidimensional para mostrar la información.

i) Desventajas

El problema que trae consigo este enfoque es que es ideal para los propósitos de desarrollo del equipo de IT pero:

• No es financieramente positivo.

• No es posible dividirla en partes modulares que al implementarse comiencen a ser explotadas, sino que es hasta que toda la arquitectura está en su lugar que los usuarios de negocio obtienen beneficio de ella.

• Es un enfoque de “big bang” que trae consigo mucho riesgo a la compañía que invierte grandes esfuerzos en el desarrollo del DW y no es sino hasta que comienzan a aparecer los Data Marts que realmente comienza a explotar su inversión y a obtener beneficios de ella.

• Es imposible conocer exactamente cuáles son las necesidades concretas de información de una empresa, dado el ambiente dinámico en que se mueve la organización. Además hay que tener en cuentas las implicancias del cambio de estructura que conlleva el desarrollo de la nueva plataforma, y los consiguientes cambios a los sistemas transaccionales que su introducción implica.

• Es muy probable la posibilidad de que luego de un considerable plazo de tiempo y recursos invertidos en el desarrollo del DW, una vez finalizado y puesto en explotación el mismo, se hagan evidentes algunos cambios fundamentales que traen consigo altos costos de desarrollo para la organización, poniendo en evidente peligro el éxito de todo el proyecto en sí y que podían ser evitados con una pronta detección en una temprana puesta en explotación de un primer avance del DW.

ii) Restricciones

• consume mucho más tiempo trabajar única y completamente con esta metodología, esto tiene como consecuencia que muchas empresas se inclinen por usar metodologías de la que obtengan resultados tangibles en menos tiempo.

• Los Data Marts dimensionales se crean sólo una vez creado el DW completo.

Inmon define el DW como un repositorio centralizado para toda la empresa. DW almacena los datos considerados “atómicos” en el nivel más bajo de detalle. Por lo tanto, el DW se encuentra en el centro de la Fábrica de Información Empresarial (CIF), que proporciona un marco lógico para la entrega de inteligencia de negocios.

Fig. 5 - Ciclo de vida de un DW según Inmon

Inmon caracteriza al DW con los siguientes conceptos:

Orientado por temas: Los datos en el DW se organizan de manera que todos los elementos de datos relacionados con el mismo evento en el mundo real o el objeto están unidos entre sí.

Variante en el tiempo: Los cambios en los datos de la base de datos son rastreados y registrados para que los informes se puedan producir que muestra los cambios en el tiempo.

No volátiles: Los datos del DW nunca es sobrescritos o borrados - una vez comprometidos, los datos son estáticos, de sólo lectura, y se retiene para futuros informes

Integrado: La base de datos contiene los datos de la mayoría o la totalidad de las aplicaciones operativas de la organización, y que esta información se haga en consonancia

4.2. Ralph Kimball

Kimball difiere considerablemente de Inmon en el enfoque: “El DW no es nada más que la unión de todos los Data Marts que lo constituyen” [K, p19]. Para Kimball el Data Mart es el DW, esto se afirma en el sentido de que Kimball expone que al construir los Data Marts ya se está construyendo el DW de una manera incremental. Un Data Mart es un subconjunto de datos organizados, como en el DW, para el soporte a la toma de decisiones, pero que sólo representa la visión de un departamento o individuo, por este motivo Kimball es frecuentemente asociado con esfuerzos departamentales y no corporativos.

La metodología de manejo de ciclo de vida de Kimball fue concebida en los mediados de los 80s, designado originalmente como el enfoque del “ciclo de vida acotado de negocios”, este apodo reforzado principios básicos del método:

• Centrarse en la adición de valor del negocio en toda la empresa,

• Dimensionalmente estructurar los datos que se entregan a la empresa

• Iterativamente desarrollar el entorno de DW/BI en incrementos del ciclo de vida manejables en lugar de intentar un enfoque del Big Bang galáctico

Fig. 6 - Ciclo de vida de un DW según Kimball

En la actualidad la mayoría de los proyectos de DW implementan el modelo de Data Marts de Kimball en lugar del esquema de DW empresarial propuesto por Bill Inmon. Esto obedece a motivos de tiempo, costo y el riesgo de fracaso asociados con el desarrollo de los dos últimos [Lee02]. A esta tendencia general se le ha identificado como la aproximación de garantizar la probabilidad de éxito más grande en la implementación de un DW, tanto por la rapidez en la obtención de resultados en períodos cortos (tiempo) con inversiones moderadas (costo) como por la modularidad posible de alcanzar con este enfoque considerando cada Data Mart como un incremento del sistema final, el DW (menor riesgo de fracaso) [Wolf99].

El punto central de la metodología de Kimball es el modelado dimensional. Un buen diseño asegura en gran parte el éxito del proyecto. El objetivo de soporte a la toma de decisiones, sólo es alcanzado si el diseño del DW - Data Mart propone una estructura consistente y adecuada a las necesidades de información de la organización. Por este motivo Kimball pone énfasis en el diseño de los Data Marts, para lo cual utiliza el modelado dimensional en la versión del esquema estrella. Kimball afirma que esta tecnología siempre puede ser aplicada en cualquier proyecto de DW y que es el método más adecuado para alcanzar el objetivo ya mencionado. El esquema estrella representa la de-normalización óptima de los datos que mejor se adapta a los requerimientos de los usuarios.

El concepto clave es que aborda el proyecto de DW como un proceso de Implementación Gradual. Sin embargo, Kimball también pone en claro que lo primero que se debe hacer al comenzar el modelado dimensional es analizar la sólida base que representa el Diagrama E-R de la empresa y a partir de allí iniciar el modelado dimensional, es decir:

• Primero se debe contemplar toda la organización empresarial para encontrar los procesos discretos del negocio.

• Luego corresponde establecer cuales son todos los posibles Data Marts y de entre ellos seleccionar cual es el más adecuado de implementar, en la correspondiente iteración del DW.

• A continuación ya se puede enfocar en él o los Data Mart que pertenecen a la etapa actual del proyecto y proceder con el ciclo de vida que expone en su metodología.

El ciclo de vida propuesto trae como consecuencia que existan Data Marts que se traslapen, para el caso en que se tienen que contemplar las diferentes vistas que distintos usuarios o departamentos tienen acerca del Modelo de Datos Corporativos, las implementaciones de vistas disímiles deben realizarse en Data Mart separados. Para asegurar la correcta unión y engranaje de los Data Marts y evitar que se conviertan en conjuntos aislados de información, Kimball establece el método de dimensiones conformadas y lo designa como el BUS del DW. Todos estos elementos para que funcionen sinérgicamente deben ajustarse en un marco de trabajo sólido, flexible y extensible, que constituye la arquitectura que guiará la implementación del DW. Kimball como ya se vio, utiliza una matriz para clasificar tres grandes áreas: Datos, Tecnología e Infraestructura, los cuales tienen cuatro niveles de detalles siendo el más bajo la implementación física del DW. Una vez establecida la arquitectura, se procede a implementar los primeros incrementos. La Implementación por incrementos de Data Marts trae consigo algunas consideraciones importantes:

• La arquitectura DW se debe desarrollar al principio del proyecto.

• El primer incremento se desarrolla basándose en la arquitectura.

• La operación del DW puede implicar la realización de cambios en la arquitectura.

• Cada incremento adicional puede extender el DW.

• Cada incremento puede causar ajustes en la arquitectura.

• La operación continua puede causar ajustes en la arquitectura.

Muchos expertos afirman en que el enfoque trabaja mejor si primero existe una estrategia de implementación en la organización, pues de esta forma se reduce el número de cambios, que en muchos casos representa una gran parte de los esfuerzos de mantenimiento o de desarrollo del nuevo incremento. Estos cambios son necesarios de realizar para asegurar el adecuado funcionamiento y crecimiento del DW.

i) Restricciones

• Para un proyecto que envuelve la creación de más de un Data Mart es aconsejable que primero se deba desarrollar una estrategia corporativa como esqueleto y luego continuar con la metodología de Kimball.

• El modelado dimensional.

• El modelado dimensional es excelente para representar las vistas de las personal que son de pensamientos similares, pero diferentes grupos de personas querrán su propia estrella que represente sus propias vistas.

• Un esquema estrella se construye obteniendo y asimilando requerimientos de los usuarios, lo que determina la forma y contenido de la estrella. El resultado de la estrella es óptimo para los usuarios que participan en el proceso de obtención de requerimientos. El esquema estrella se forma alrededor de los requerimientos de usuarios y porque estos requerimientos varían de un tipo de usuarios a los otros no es de sorprender que diferentes estrellas sean óptimas para diferentes tipos de usuarios.

El modelado dimensional se centra en la facilidad de acceso de los usuarios finales y ofrece un alto nivel de rendimiento para el DW.

Dentro del modelo planteado por Kimball, la gestión de requerimientos es la primera actividad dentro de cada ciclo incremental.

Fig. 7 - Extraído de “Kimball Lifecycle Methodology Diagram” Kimball group [13]

El problema real es cuando existen múltiples ambientes independientes de esquemas estrella, los mismos datos detallados aparecen en cada estrella. No existe reconciliación de datos y las nuevas estrellas requieren la misma cantidad de trabajo para la creación que las antiguas estrellas. Como resultado:

• Las uniones crecen innecesariamente cuando cada estrella necesita datos detallados que otra estrella ya ha obtenido.

• Los resultados de cada estrella son inconsistentes con el resultado obtenido de cada otra estrella y la habilidad de reconciliar las diferencias no es aparente.

• No existen bases para construir nuevas estrellas porque cada una es construida independientemente.

• La interface para soportar las aplicaciones que alimentan las estrellas se vuelve inmanejable.

• Se genera una gran cantidad de trabajo extra al construir cada parte en comparación al enfoque de DW Corporativo.

5. Comparación de Requerimientos en las metodologías (Kimball vs Inmon)

Paradigma de Bill Inmon: el DW es una parte del sistema global de inteligencia de negocios (BI). La empresa cuenta con un DW, y los Data Marts son la fuente de la información del DW. En el DW la información se almacena en la tercera forma normal [15].

Paradigma de Ralph Kimball: el DW es el conglomerado de todos los Data Marts dentro de la empresa. La información siempre se almacena en el modelo tridimensional.

5.1. Kimball vs. Inmon [16, 17]

CARACTERÍSTICA INMON KIMBALL

Integración a través de un modelo de datos de la empresa Integración través de dimensiones

Arquitectura

Complejidad del método Muy complejo simple

Esquema Top-Down Bottom-Up y Evolutiva

Estructura de la arquitectura DW alimenta a Data Marts departamentales Data Mart modela un proceso de negocio

Modelado de datos

Herramientas Tradicionales (E/R) Modelado dimensional; comienza por modelado relacional tradicional

Orientación de los datos Temas Proceso

Accesibilidad de usuario Baja Alta

Dimensiones

Tasa de cambio Continuos y discretos Cambios lentos

Métodos Timestamp Clave de dimensión

Manejo de cambio de dimensiones Continuo: Registro activo - Fecha de inicio y Fin

Discreto: Un punto en el tiempo; Snapshot Versionado:

Tipo 1 - Cambia el registro requerido; No hay historia

Tipo 2 - Maneja todos los cambios; la historia es resguardada

Tipo 3 - Alguna parte de la historia es paralela; Limite por la historia definida

Filosofía

Primera audiencia IT Usuarios finales

Lugar en la Organización Parte de la Fábrica de Información Corporativa (CIF) Transformador y retenedor de datos operacionales

Objetivo Entregar una solución técnica basada en métodos probados Entregar una solución que haga fácil para los usuarios la consulta directa en un tiempo razonable de respuesta

Pros y contras

Naturaleza de toma de decisiones Tácticos Estratégicos

Requerimientos de Integración de datos Áreas de negocio individuales Integración inter-empresarial

Estructura de datos Métricas de negocio, medidas de performance, cuadros de mando Los datos no métricos y para los datos que se aplicarán para cumplir con múltiples y variadas necesidades de información

Escalabilidad Adaptarse a necesidades de alta volatilidad en un alcance limitado Alcance de crecimiento y cambios en los requerimientos son críticos

Persistencia de datos Los sistemas de origen son relativamente estables Alta tasa de cambio desde los sistemas de origen

Requerimientos de capacidades Pequeños grupos generalistas Grandes grupos de especialistas

Tiempo de entrega la necesidad para la primer aplicación DW es urgente los requerimientos de la organización permiten extensos tiempos de comienzo

Costo de puesta en marcha Bajo costo de comienzo, con cada sub-proyecto costando alrededor de lo mismo Altos costos de puesta en marcha, con costos más bajos en el desarrollo de proyectos subsecuentes

Tabla 1 – Comparación de Metodologías de DW

5.2. Elegir el mejor método

A continuación se presentan lineamientos para determinar cuál de los enfoques (Inmon o Kimball) es el más adecuado a las necesidades de DW de la organización. David Wells abordó este problema en un artículo TDWI FlashPoint a principios de 2003 (Wells, 2003), donde propone 12 criterios de evaluación que se centran en las necesidades, el medio ambiente, la cultura y los conocimientos técnicos de una organización planeando crear un DW. De los 12, ocho favorecen tanto a Kimball como Inmon. Los cuatro elementos restantes (costo de operación, la coherencia de los metadatos y las reglas de negocio, la sostenibilidad y los requerimientos tecnológicos) favorecen a Kimball o Inmon dependiendo de la implementación de un proyecto de un DW determinado.

Para resumir, según los datos de la Tabla 1, una organización es más probable que tenga éxito utilizando el enfoque de Inmon si tiene un gran equipo de especialistas en DWs, planes de un gran proyecto con necesidades de acceso a toda la empresa, Data Marts que están no principalmente en las métricas de negocio, y pueden esperar para ver los resultados más de un largo período de tiempo, desde cuatro a nueve meses (Inmon, 2000). Estas características y requerimientos de datos se ajustan bien con la recomendación de Inmon para construir, primero, una considerable infraestructura en un modelo de datos sólido para toda la empresa. Por otra parte, una organización con características diferentes puede definirse mejor con un enfoque basado en Kimball. Según un experto, "un requisito típico es desarrolla un mercado de datos operativa de un negocio específico zona en 90 días, y desarrollar posteriores Data Marts en 60 a 90 días cada uno" (Mimno, 2002). El enfoque de Kimball es generalmente reconocido como más rápido que el de Inmon, por lo menos para la entrega del primer Data Mart (en comparación con la primera base de datos departamental utilizando el enfoque de Inmon). Éste es más indicado si la organización está en mejores condiciones de albergar equipos pequeños de desarrollo, y espera para almacenar gran cantidad de métricas de negocio.

Una organización con estas características y requerimientos es más probable que tenga éxito con una arquitectura Data Mart desarrollado utilizando el enfoque de modelado tridimensional. Es necesario entender que estos lineamientos representan una simplificación excesiva del proceso, que puede ser útil como un punto de partida para discutir las necesidades de DW y las características de una organización determinada. Como resultado final, el tener el conjunto adecuado de capacidades “livianas” (relaciones interpersonales) es tan importante, si es que no es más importante, que las habilidades técnicas y conocimientos.

Curiosamente, las claves del éxito no son de carácter técnico. Los proyectos no tienen éxito debido a que utilizan un diseño innovador o una nueva tecnología radical. Tienen éxito, debido a las características humanas - el liderazgo, la comunicación, la planificación y relaciones interpersonales (Eckerson, 2003).

Cuando la construcción de un DW, ya sea utilizando Inmon o del enfoque de Kimball, es fundamental que el equipo de DW emplee habilidades “livianas” libremente y con eficacia. Esto implica asegurar que la organización tiene una visión bien articulada de la función del DW y el uso, y asigna suficiente recursos para crear y mantener el DW (Eckerson, 2003). Estos no son típicamente responsabilidades que un equipo de desarrollo de proyectos de IT debe asumir, sin embargo, son críticos para el éxito de un proyecto de DW.

6. Definición de Requerimientos de un Data Warehouse (DWARF – Data WArehouse Requirements deFinition)

En la práctica, tanto para conceptos tan disímiles como Kimball e Inmon, la definición de requerimientos tiene el mismo objetivo: conocer las necesidades de los usuarios finales. Estas necesidades están orientadas a contener información para toma de decisiones, por lo que la concentración de los requerimientos esta apuntada a definir diferentes aspectos, según especifica Fábio Rilston S. Paim [3]

• Representar hechos y sus propiedades: Los hechos son centrales para DW. El análisis de necesidades de los usuarios implica la identificación de los hechos por los que perciben las métricas detrás de las demandas del usuario. Otro requisito de importancia es determinar el grado en que una métrica es capaz de ser agregada, es decir, pueda ser operada (resumida, contada, elaborar un promedio) a lo largo de jerarquías dimensionales (por ejemplo, tiene sentido contar el número anual de los contribuyentes, pero para sumar dichas cantidades no parece tener un valor útil)

• Distinguir y conectar las dimensiones de hechos: Las dimensiones ofrecen la clave para entender las medidas de hechos por lo que permite al usuario ver los datos a través de diferentes puntos de vista. A veces, el análisis de un solo usuario da lugar a un número de dimensiones candidatas. Por ejemplo, la frase: "Analizar el total de los ingresos de los tipos de impuestos individuales por año" claramente especifica dimensiones en el tiempo y los impuestos, así como el hecho de los ingresos fiscales.

• Aseguramiento de sumarizabilidad: Una cuestión importante en DW es garantizar la exactitud de los resultados para cualquier combinación de hechos y dimensiones, también conocido como sumarizabilidad. Los inconvenientes pueden evitarse claramente al expresar los requerimientos de restricción sobre la agregación de los datos, así como conformar hechos y dimensiones de un Data Mart para el modelo de DW empresariales. Por ejemplo, la dimensión "tiempo" y la recaudación de impuestos definido en la unidad "tasa de crecimiento" no se puede combinar en el atributo "día".

• La integración con fuentes de datos: En un ambiente DW, los datos se obtuvieron de diferentes fuentes, dentro y fuera del entorno empresarial. Esta actividad implica no sólo la importación de datos de todos los tipos de bases, sino también el descubrimiento informal de requerimientos de negocios. Entonces, además de especificar los procedimientos y requerimientos para la recolección de datos, se deben determinar cómo se adquieren los datos informales de hojas de cálculo, bases de datos de oficina o incluso introducidos por el propio usuario.

• Agilización de los requerimientos de los cambios del usuario: Una preocupación en aplicaciones de DW es la evolución. Incluso a veces llamados "cambios significativos" puede afectar a la validez general de los datos obtenidos, el debilitamiento, el potencial de apoyo a las decisiones de la aplicación (por ejemplo, un incremento de un dígito en una métrica, aunque manteniendo el mismo contenido, puede afectar el proceso de carga de este y otros valores derivados).

• Documentación de alta calidad: El desarrollo de un conjunto de DWs siempre implica desarrolladores que utilizan documentación operacional preexistente para definir los datos y procedimientos de extracción e integración. Aparte de raras excepciones, dicha documentación legada carece de la calidad necesaria, convirtiendo la extracción de los requerimientos técnicos en una actividad difícil. Por lo tanto, una documentación de alto nivel diseñado para proporcionar una interfaz general para una explotación requerimientos es extremadamente necesaria.

Debido a las características antes mencionadas, definimos un método que es una nueva ingeniería de requerimientos técnicos no funcionales, adaptada al dominio del DW, llamada DWARF (DW Requirements deFinition).

6.1. Concepto del framework

Esta técnica se basa en una serie de fases para obtener y gestionar los requerimientos no funcionales de un DW. Cada fase sigue los niveles de abstracción de la aplicación en profundidad, ya que los requerimientos del proyecto se reúnen para formar una baseline de requerimientos (primera fase). Alrededor de este ciclo se encuentra en la segunda fase llamada Control de Gestión de Requerimientos, con el objetivo de realizar la evaluación permanente de la calidad de la evolución de las necesidades.

Junto a las fases anteriores, los templates de documentos proponen una estructura predefinida para la documentación del DW, mientras trabajan como instrumentos de grabación de hechos para el desarrollo del sistema. A continuación explicaremos brevemente la técnica DWARF.

Fig. 8 – Requerimientos: ciclo de vida de los requerimientos según DWARF

6.2. Planificación de Gestión de Requerimientos (Requirements Management Planning)

En las primeras etapas de una definición de los requerimientos, las normas para un proceso de ingeniería de requerimientos eficaz en los sistemas de DW deben ser definidas. Tales pautas generales guiarán la aplicación correcta de la técnica DWARF, así como evitar que la ausencia de un estándar común cause inconsistencias en las actividades de elicitación, documentación y gestión. Las pautas pueden ser definidas en términos de las reglas de negocio, procedimientos y procesos.

6.3. Especificación de requerimientos (Requirements Specification)

En el desarrollo del DW, los requerimientos del proceso se definen como un enfoque cíclico de la adquisición, representación y evaluación de los requerimientos para producir gradualmente una especificación del sistema. Por lo tanto, un proceso iterativo parece ser más apropiado para apoyar este flujo de trabajo. Los requerimientos de Data Marts inicialmente elicitados atraviesan una secuencia de iteraciones, por el que se los analizan, se negocian entre los participantes del proceso, se registran y se conforman a una especificación de DW más amplio.

En esta fase se genera la elicitación de los requerimientos con las herramientas ya conocidas (Entrevistas, Workshops, Prototipos).

Los esfuerzos de elicitación se centrarán en una instancia de esta modelo estándar para especificar las reglas de negocio, procedimientos y funciones de consulta que hacen que un proyecto a diferencia de la otra. Además, los casos de uso permiten la reutilización de comportamiento común compartida entre los diferentes escenarios de los DWs.

6.4. Gestión de Requerimientos

Los requerimientos no pueden tratarse con buenos resultados sin trazabilidad [6]. En entornos de DW, la gestión de la trazabilidad y el cambio debe llevarse a cabo en ambos requerimientos y esferas arquitectónicas. El primero tiene que ver con la gestión de cambios en los requerimientos acordados y su impacto a otros requerimientos dentro de la misma o en los documentos externos. No es deseable que se extienda la investigación de la arquitectura de base de datos, con el fin de aclarar qué impacto tendrá el cambio subyacente tendrá en el esquema multidimensional. Existen herramientas de apoyo para actividades de investigación [7,8]. Tales herramientas se convierten en obligatorias para los sistemas de DW, ya que generan grandes cantidades de requerimientos y atributos de base de datos.

Las Matrices de trazabilidad [6] se pueden utilizar para mostrar los requerimientos de las dependencias. Diferentes matrices deben definirse para permitir el análisis de referencias cruzadas entre los requerimientos de funcionalidades (ej. frente a los hechos, hechos frente atributos dimensionales). Por otro lado, los cambios en los requerimientos de forma directa afectan el modelo de base de datos tanto Data Mart y Data Viewer. La mayoría de las bases de datos relacionales ofrecen herramientas [7,8] para buscar atributos afectados en la base de datos, y descubre cuántos (y en qué medida) elementos de la base de datos se ven influidos por el cambio. Estas características reducen el esfuerzo de evaluar y realizar el mantenimiento necesario a campos de la tabla de base de datos, preservando así la seguridad de la solución.

7. Tendencias

Hoy existen temas pendientes en el ciclo de vida de un DW, que incluye la definición de los requerimientos.

- Limpieza de datos, indexación, particionamiento y vistas se podría dar una nueva atención a la perspectiva para el DW.

- Automatización de

• adquisición de datos

• gestión de calidad de los datos

• selección y construcción de caminos y estructuras de acceso

• funcionalidad y optimización del rendimiento

- La incorporación de las normas de dominio y de negocios adecuadas en la creación de DW y el proceso de mantenimiento de manera más inteligente

El tema es bastante extenso, y se puede apreciar que la generación de requerimientos al día de hoy es una cuestión de definición empresarial, que puede decidir entre una u otra arquitectura y diseño. Las herramientas son variadas y cada vez están más especializadas, y el método en este documento hace uso de la gestión de requerimientos del DW e implementa de alguna u otra manera mecanismos para poder dar una visibilidad de la variación tanto del mercado como de las tecnologías y así adecuar al DW a las necesidades del usuario, para resolver el proceso de mantenimiento de manera más inteligente. Es evidente que en gran medida todas las soluciones futuras deberán tener en común la necesidad de la detección del cambio en cada etapa del ciclo de vida de un DW.

Por último, aunque no fue presentado en este trabajo, la introducción de metodologías ágiles en el ciclo de proceso de un proyecto DW genera una visión totalmente diferente en relación a la gestión de requerimientos, con el tiempo se podrá determinar si con grandes volúmenes de datos la metodología ágil se adaptará al DW o viceversa [5].

8. Conclusiones

En tiempos en que la necesidad de información es constante, en que los pasos a futuro definen éxito o fracaso de una empresa, la información es una fuente vital de conocimiento para la toma de decisiones. Pero estas decisiones no son siempre realizadas por las mismas personas, ni en el mismo tiempo, ni con la misma información. Como primer paso diseñar una buena arquitectura de DW es necesario conocer bien los requerimientos del negocio y hacer un estudio profundo de las fuentes externas que nos van a suministrar los datos.

Como último paso la situación cambiante define que los requerimientos que surjan de esos cambios, deban ser gestionados y actualizados para mantener la utilidad de un DW con un valor estratégico para cualquier organización. Este trabajo intentó definir las diferencias entre metodologías para el manejo de requerimientos de un DW, y presenta una herramienta que es de utilidad para realizar este seguimiento.

Si bien el concepto de cambios de requerimientos está implícito en cualquier ciclo de vida, en el caso especial de los DW no existe una estandarización en las metodologías para poder gestionar, y más aún, para definir los requerimientos ante la decisión de implementar un DW. Se ha alcanzado la funcionalidad esperada, pero los diferentes conceptos de la génesis de un DW llevan a tener que tomar decisiones basadas en resultados a muy largo plazo, y por ende con un alto riesgo y mucha inversión de dinero. Es por eso que hay un gran trabajo de recursos humanos de análisis de requerimientos por cada necesidad como así también el criterio de los especialistas en el tema.

En caso de tener que elegir un enfoque, el propuesto por Kimball puede ser el más adecuado para la mayoría de las empresas de software. Sobre todo para aquéllas que desean incursionar, o bien aún poseen poca experiencia, en el área del BI, dado que están acostumbradas a administrar requerimientos en una forma clásica, pueden trabajar con equipos pequeños y a la vez presentar resultados en forma más temprana; lo que permite a todos los involucrados evaluar los beneficios y los riesgos antes de incurrir en mayores gastos, o replantear más prontamente sus estrategias de negocios.

9. Referencias

1. KRANTI GAJMAL, GHARDA PALLLAVI KALOKHE, (2013), DW Design Using Process-Oriented Requirement Analysis: A survey, International Journal of Latest Trends in Engineering and Technology (IJLTET), ISSN: 2278-621X

2. P. GIORGINI, S. RIZZI, M. GARZATTI, (2008), Goal-oriented requirements analysis for DW design. Proceedings, 8th ACM International Workshop on Data Warehousing and OLAP, (2005). Also in GRAnD: Goal-oriented approach to requirement analysis in DWs. Decision Support Systems, 45, pp. 4–21.

3. FÁBIO RILSTON S. PAIM, JAELSON F. B. CASTRO, (2010), DWARF: An Approach for Requirements Definition and Management of DW Systems, Universidade Federal de Pernambuco – Centro de Informática

4. ERICKA GRACIELA SEVILLA BERRÍOS, (2003), Guía Metodológica para la Definición y Desarrollo de un DW, Universidad Americana

5. Metodologías Agiles en proyectos BI, ver: http://todobi.blogspot.com.ar/2011/03/metodologias-agiles-en-proyectos-bi.html

6. M. TORANZO, (2002) “A Proposal for Improving Requirements Traceability” (in Portuguese), PhD Thesis, Federal University of Pernambuco.

7. Oracle9i Developer Suite: ver http://www.oracle.com/pls/db92/db92.homepage

8. Rational RequisitePro : ver http://www.ibm.com/software/products/us/en/reqpro/

9. PRAKASH, N., SINGH, Y., GOSAIN, A., (2004) Informational scenarios for DW requirements elicitation. In: Atzeni, P., Chu, W., Lu, H., Zhou, S., Ling, T.-W. (eds.). LNCS, vol. 3288, pp. 205–216. Springer, Heidelberg

10. WINTER, R., STRAUCH, B., (2003) A method for demand-driven information requirements analysis in data warehousing projects. In: HICSS

11. GIORGINI, P., RIZZI, S., GARZETTI, M., (2005), Goal-oriented requirement analysis for data warehouse design. In: DOLAP, pp. 47–56 (2005)

12. STEFANOV, V., LIST, B. 2006, Business metadata for the data warehouse - weaving enterprise goals and multidimensional models. In: EDOC Workshops (2006)

13. R. KIMBALL, L. REEVES, M. ROSS AND W. THORNTHWAITE, 1998, The DW Lifecycle Toolkit, New York, John Wiley & Sons.

14. M. STAUDT, A. VADUVA AND T. VETTERLI, 1999, "The Role of Metadata for Data Warehousing", Technical Report 99.06, Department of Information Technology, University of Zurich.

15. Tercera forma normal: ver http://es.wikipedia.org/wiki/Tercera_forma_normal

16. Inmon CIF glossary: ver http://www.inmoncif.com/library/glossary/#D

17. MARY BRESLIN, (2004), Data Warehousing Battle of the Giants: Comparing the Basics of the Kimball and Inmon Models, Business Intelligence Journal

...