Metodología ágil de desarrollo de almacenes de datos

Cada día la información es fundamental e indispensable en la toma de dediciones por parte de la gerencia de cualquier empresa. Los almacenes de datos se han convertido en piezas claves en el entorno empresarial.

Este trabajo tiene como objetivo exponer La Metodología Ágil de Desarrollo de Almacenes de Datos basada en el Proceso Unificado de Desarrollo (RUP) elaborada por Ambler W. Scott. El enfoque serial tradicional para la creación de un almacén de datos, donde semanas o meses de modelación son necesarios antes de que comience el proceso de desarrollo es insuficiente para satisfacer las demandas en un ambiente de negocios dinámico como ocurre en estos tiempos. Los cambios en los requerimientos demandan un enfoque de alta colaboración evolutivo y flexible, el Proceso Unificado de Desarrollo (RUP) define tal enfoque.

1. INTRODUCCIÓN

En la mayoría de nuestras organizaciones se utiliza aun el enfoque serial tradicional para el diseño e implementación de almacenes de datos, basado en el concepto de “verdad única”, capturada en los inicios del desarrollo del proyecto. En la actualidad existe un cambio de perspectiva en el diseño e implementación de sistemas tradicionales mediante la metodología del Proceso Unificado de Desarrollo (RUP), pero apreciamos como se continúan elaborando almacenes de datos a partir del principio de la cascada. Nuestro objetivo es difundir la Metodología Ágil de Desarrollo de Almacenes de Datos basada en el Proceso Unificado de Desarrollo (RUP) que controla el riesgo del alcance, de forma temprana el riesgo técnico y financiero, permite la agilidad de forma disciplinada, entre otros aspectos positivos.

2. METODOLOGÍA

(Casares, 2003) Desde que se inició la era de la computadora, las organizaciones han usado los datos desde sus sistemas operacionales para atender sus necesidades de información. Un almacén de datos es una colección de datos en la cual se encuentra integrada la información de la Institución y se usa como soporte para el proceso de toma de decisiones gerenciales.

Reunir los elementos de datos apropiados desde diversas fuentes de aplicación en un ambiente integral centralizado, simplifica el problema de acceso a la información y en consecuencia, acelera el proceso de análisis, consultas y el menor tiempo de uso de la misma.

La gestión administrativa reconoce que una manera de elevar su eficiencia está en hacer el mejor uso de los recursos de información que ya existen dentro de la organización. El almacén de datos es actualmente el centro de atención de las grandes instituciones, porque provee un ambiente para que las organizaciones hagan un mejor uso de los datos que son administrados por diversas aplicaciones operacionales.

(Scott, 2006) El enfoque serial tradicional para el desarrollo de un almacén de datos, donde semanas o meses de modelación son necesarios antes de que comience el proceso de desarrollo es insuficiente para satisfacer las demandas en un ambiente de negocios dinámico como ocurre en estos tiempos. Los cambios en los requerimientos demandan un enfoque de alta colaboración evolutivo y flexible para el desarrollo de un almacén de datos. El Proceso Unificado de Desarrollo o RUP, define tal enfoque.

Razones por las que las organizaciones utilizan RUP para el desarrollo de proyectos de almacenes de datos:

1. RUP controla el riesgo del alcance: RUP reconoce como un hecho que los requerimientos cambian en el desarrollo del proyecto y define un enfoque flexible para controlar estos requerimientos. Tratar de definir los requerimientos de forma total al inicio del proyecto es una decisión muy riesgosa.
2. RUP busca más allá de los datos: una razón por la cual los proyectos de almacenes de datos fallan es no brindar el suficiente valor de negocio. Al identificar y centrarse en el valor de negocio mediante los casos de uso (Stevens, 2000), RUP obtiene una vista de los requerimientos, método preferible al enfoque centrado en los datos.
3. RUP controla de forma temprana el riesgo técnico: muchos proyectos de almacenes de datos fallan por la confianza que brindan modelos detallados creados de forma temprana. Si el modelo de datos es muy detallado, captura “la verdad única” y Usted a gastado meses trabajando en este, el problema radica en que cualquier arquitectura funciona bien en el papel, hasta que usted no prueba la arquitectura con código no puede estar seguro de su funcionamiento correcto.
4. RUP controla el riesgo financiero: el desarrollo iterativo e incremental que de forma temprana maneja los componentes críticos de un proyecto asegura que se garantice el mayor valor de funcionalidad primero, maximizando el retorno de la inversión todo el tiempo.
5. RUP permite la agilidad de forma disciplinada: los proyectos de almacenes de datos son difíciles, se necesita flexibilidad pero al mismo tiempo mantener un nivel de control para lograr que el desarrollo sea efectivo.

El almacén de datos es un aspecto muy importante en la infraestructura de técnica de toda organización, debe ser visto como un producto de continuo desarrollo en el tiempo a través de una serie de versiones. Cada una de estas versiones se considera un proyecto.

Fases de Desarrollo

1. Fase de Concepción

En la etapa inicial de desarrollo (Concepción) se crean las bases del proyecto. Se define el alcance, el plan inicial, la visión del negocio con las metas y la justificación del proyecto, estos artefactos (Stevens, 2000) son perfeccionados a lo largo del desarrollo del proyecto. Los requerimientos iniciales son capturados a través de casos de uso. Durante esta etapa se comienza a pensar en la arquitectura inicial del sistema (Stevens, 2000), desde el punto de vista del negocio y desde el punto de visto técnico. Para un almacén de datos este proceso implica la creación de un modelo conceptual (Stevens, 2000) y un modelo de despliegue (Stevens, 2000), ambos a un alto nivel en esta fase

Se define un plan para el proyecto a alto nivel (Stevens, 2000) y después se refina en un plan más detallado en las siguientes iteraciones. El plan a alto nivel maneja las dependencias principales y la estrategia general, mientras que los planes más refinados (correspondientes a iteraciones más detalladas) manejan las tácticas propias de las situaciones en cuestión de cada iteración. En la planificación del proyecto se debe tener en cuenta acciones a largo plazo como son las operaciones, el soporte y la mejora continua al almacén de datos.

Esta fase de concepción finaliza asegurando la existencia de un alcance definido, plan de desarrollo, análisis de riesgos (Stevens, 2000) donde los clientes concuerden con lo anterior y contar con una estrategia viable para la construcción del almacén de datos.

Existen algunos errores comunes que se incurre en esta etapa, se debe evitar:

• Pensar que es una fase de determinación de los requerimientos de forma tradicional.
• Pensar que se necesita contar con modelos y planes perfectos.
• Tratar de crear un modelo de datos completo al inicio del proyecto.

2. Fase de Elaboración

El principal objetivo de esta fase es mitigar el riesgo técnico en el proyecto para ello se identifican los casos de uso que reflejan los riesgos técnicos de alta prioridad, construyendo con los mismos un esqueleto de trabajo del sistema para probar la arquitectura propuesta, la cual se aprecia en el diagrama de despliegue. Para un proyecto de almacén de datos el riesgo técnico se enfoca principalmente en el volumen de los datos, acceso a los datos existentes anteriormente y calidad de los datos.

Para realizar el trabajo es necesario representar los casos de uso, en casos de uso más pequeños donde los mismos representen escenarios, de estos escenarios se seleccionan los que representen mayor riesgo técnico. Durante esta fase se crea el código necesario para probar la arquitectura. Es necesario crear reportes elementales que utilicen estos datos, no es factible implementar una lógica compleja del negocio, pero se debe acceder a los datos fundamentales de algún modo. Un criterio importante es minimizar la documentación de forma tal que sólo se cuente con la información que se utilizará. También es necesario implementar el proceso de archivar los datos antiguos y por último crear un reporte que utilice tanto los datos activos en el almacén de datos como los datos archivados.

Es útil en esta fase enlazar las entidades del negocio del modelo conceptual con las bases de datos fuentes de los sistemas. Como se implementará el código de extracción de datos se deben adicionar atributos al modelo conceptual y se deben enlazar estos con las columnas de las fuentes de datos, sobre la base de just-in-time y sólo si provee valor al proyecto.

Continuamos trabajando con el modelo de requerimientos identificando nuevos casos de uso a medida que los usuarios lograr una mayor comprensión de lo que desean. Debemos enfocarnos en los tipos de reportes y queries que utilizan los clientes cuando realizan las actividades del negocio descritas en los casos de uso. En esta fase solo se especifican los reportes y sus problemas críticos sin definir detalles, estos detalles se especificarán a partir del principio just-in-time en la fase de Construcción.

En la construcción del almacén de datos mucho grupos de trabajo presentan dificultades al tratar de lograr las mayores especificaciones del problema de una sola vez, no tienen en cuenta que las ideas del cliente cambian. Es más importante menos documentación y más trabajo sobre un software de alta calidad.

Existen algunos errores comunes que se incurre en esta etapa, se debe evitar:

• Documentación de requerimientos muy detallada.
• Documentación de diseño muy detallada.
• Documentación detallada sobre las fuentes de datos.
• Documentación muy detallada sobre el enlace entre las entidades del modelo conceptual y las fuentes de datos.
• No incorporar en el desarrollo del proyecto al personal encargado de las operaciones y al personal cuya función es el soporte.

Para terminar la fase de Elaboración se debe llevar a cabo una revisión de los casos de uso del negocio, determinando si tiene sentido construirlos a partir de una mejor comprensión de la arquitectura y los requerimientos. Es importante mostrar un esqueleto funcional de nuestro almacén de datos que brinde al cliente nuestra comprensión del problema y que al mismo tiempo permita llegar a la conclusión que el proyecto supera los riesgos fundamentales. Este esqueleto será el objetivo de trabajo principal en la fase de Construcción. El objetivo fundamental al final de cada fase de desarrollo es determinar si se continúa o no con el proyecto, el proyecto del almacén de datos debe tener sentido financiero y técnico para continuar con su desarrollo.

3. Fase de Construcción

Durante la fase de Construcción el almacén de datos se desarrolla de forma evolutiva completando el esqueleto desarrollado en la fase de Elaboración. El sistema es construido en iteraciones, cada iteración de construcción representa un punto de chequeo donde se analiza el cumplimiento de los requerimientos propios de la iteración, trabajando de esta forma nos retroalimentamos de los clientes de forma periódica, incrementando la posibilidad de entender sus necesidades actuales. Además produciendo software actualizado de forma regular brindamos evidencias concretas a nuestros clientes de realizar avances en el desarrollo del proyecto. Durante cada iteración se trabaja en los requerimientos de más alta prioridad de forma sucesiva.

Necesitamos adoptar algunas técnicas de desarrollo evolutivo como son:

• Gestión de configuración: el objetivo principal es gestionar los artefactos generados en cada ciclo de vida del proyecto.
• Integración continua: el objetivo principal es reconstruir el sistema en cualquier momento que algo cambie.
• Refactorización: un simple cambio en el código fuente, el cual mejora el diseño, no debe implicar que algo funcione mal o que sea necesario adicionar otras cosas.
• Prueba de regresión: asegura que los cambios hechos al sistema no rompen funcionalidades existentes.

Para desarrollar cada caso de uso en esta fase la estrategia es similar:

1. Identificar los elementos de datos requeridos.
2. Para cada elemento identificado en 1, determinar su mejor fuente.
3. El esquema de datos del almacén de datos debe aceptar nueva información (tablas y/o columnas).
4. Desarrollar el código de extracción, transformación/limpieza (si es necesaria) y carga del almacén de datos y de esta forma detectar datos necesarios.
5. Confeccionar los reportes requeridos.
6. Aplicar pruebas de regresión en base al enfoque evolutivo.
7. Retroalimentarse del cliente mostrándole cualquier cambio realizado.
8. Iterar.

Es importante identificar algunos aspectos importantes sobre la fuente de datos:

• Disponibilidad de la información (24/7).
• Medio de acceso (red, cinta, dvd).
• Acceso a los datos (vía SQL, vía Web Services).
• Personal de contacto para esa fuente de datos.
• Derechos de seguridad de acceso.
• Estructura del dato.

Desde el punto de vista de la importancia de los modelos, estos pueden ser organizados en el siguiente orden:

1. Modelo de datos físico.
2. Modelo de casos de uso.
3. Modelo de enlace entre la fuente y el destino.
4. Modelo de datos lógico.

Existen algunos errores comunes que se incurre en esta fase, se debe evitar:

• Enfoque intensivo a datos, en vez de enfocarnos al dato enfocarnos en el uso de los datos.
• Organizar el trabajo por fuente de datos.
• Escribir especificaciones de reporte de forma detallada.
• Herramientas no adecuadas.
• Pobre colaboración con los clientes.
• Pobre colaboración con el personal de la fuente de datos.

La fase de Construcción termina con la revisión de las capacidades operacionales iniciales. El principal objetivo de esta revisión es comprobar que el almacén de datos puede continuar hacia la siguiente fase (Transición), que los clientes puedan asumir el despliegue del almacén de datos y que los casos de negocios mantengan su sentido.

4. Fase de Transición

El objetivo principal de esta fase es el despliegue de forma productiva del almacén de datos, para ello es necesario comunicarle el plan de despliegue a los clientes finales. Puede ser realizado a través de correos, presentaciones o entrenamientos. Durante la primera versión productiva del almacén de datos es necesario el entrenamiento a los usuarios pues no están familiarizados con las herramientas de análisis de la información, en siguientes versiones no es necesario este entrenamiento sino el conocimiento de los nuevos datos que pueden ser accedidos o las modificaciones realizadas en otros datos.

En esta fase se deben realizar las pruebas del sistema y la aceptación final, pero si esto se ha realizado en las fases de elaboración y construcción, aquí se convierte en un procedimiento formal. El error más común en esta fase es pensar que es una fase de pruebas. Aquí comienza la etapa de desarrollo de versiones.

Podemos resumir que los artefactos elaborados en las diferentes fases son los siguientes:

Fase de Concepción:

• Plan del proyecto.
• Visión.
• Casos de Uso.
• Diagrama Conceptual.
• Diagrama de Despliegue.
• Acta de aprobación con el Cliente.

Fase de Elaboración

• Esqueleto de trabajo con los casos de usos más importantes.
• Modelo de enlace entre la fuente y el destino.
• Reportes elementales.
• Acta de aprobación con el cliente.

Fase de Construcción

• Desarrollo evolutivo del esqueleto de trabajo.
• Acta de aprobación con el cliente.

Fase de Transición

• Plan de despliegue.
• Acta de las pruebas del sistema y la aceptación final por el cliente.

Hemos expuesto ideas útiles con relación al diseño e implementación de un almacén de datos, un elemento indispensable actualmente en nuestros ambientes empresariales.

3. CONCLUSIONES

• Es necesario cambiar el enfoque serial tradicional existente en la mayoría de los especialistas que diseñan e implementan almacenes de datos, una posible solución sería la metodología abordada en este trabajo.
• Los cambios en los requerimientos demandan un enfoque de alta colaboración evolutivo y flexible, el Proceso Unificado de Desarrollo (RUP) define tal enfoque.

4. REFERENCIAS

1. Casares, C. (2003). Data Warehousing. [En línea]. Disponible en: .
2. Scott W. A. (2006). Practice Leader, Agile Development, Rational Methods Group, IBM. [En línea]. Disponible en:
3. Stevens, Perdita. Ed. 2000. Software Engineering with Object and Components