Download pdf - Case Metologia Kimball

Herramienta CASE para el soporte de proyectos de Data Warehousing basada en la metodología Kimball.

Anteproyecto de Trabajo de Grado

Alexander Ortiz RosadaOscar Eduardo Rendón Sotelo

Director: MSc. Martha Eliana Mendoza Becerra

Universidad del CaucaFacultad de Ingeniería Electrónica y Telecomunicaciones

Departamento de SistemasGestión de la Información – DW

Popayán, Julio de 2008


TABLA DE CONTENIDO

1. PRESENTACION DEL DIRECTOR ........................................................................................................... 1

2. PLANTEAMIENTO DEL PROBLEMA. .................................................................................................... 2

2.1DEFINICION.........................................................................................................22.2MARCO TEORICO..................................................................................................3

2.2.1 HERRAMIENTAS CASE.......................................................................................31.2.2DATA WAREHOUSE............................................................................................51.2.3METODOLOGIA KIMBALL (Metodología BDL)..........................................................6

2.3ANTECEDENTES....................................................................................................92.4JUSTIFICACION...................................................................................................11

3. OBJETIVOS. ................................................................................................................................................ 13

3.1OBJETIVO GENERAL....................................................................................................133.2OBJETIVOS ESPECÍFICOS...............................................................................................13

4. ACTIVIDADES Y CRONOGRAMA. ........................................................................................................ 14

4.1METODOLOGÍA DE TRABAJO.................................................................................144.2CRONOGRAMA DE ACTIVIDADES...........................................................................15

5. RECURSOS, PRESUPUESTO Y FUENTES DE FINANCIACIÓN ...................................................... 15

5.1RECURSOS REQUERIDOS................................................................................................155.2DEFINICIÓN DE FUENTES DE FINANCIACIÓN...........................................................................16

6. CONDICIONES DE ENTREGA. ............................................................................................................... 17

7. CONTENIDO DEL DOCUMENTO FINAL. ............................................................................................ 17

8. REFERENCIAS ............................................................................................................................................ 18

2

1. PRESENTACION DEL DIRECTOR

La Universidad del Cauca con su grupo de Investigación y Desarrollo en Tecnologías de la Información (GTI), ha venido desarrollando varios proyectos alrededor de áreas de conocimiento como son: Bodegas de Datos (DW, por sus siglas en inglés), Procesamiento Analítico On-Line (OLAP) y Minería de datos (DM), que son elementos tecnológicos indispensables en los Sistemas de Soporte a la Toma de Decisiones (DSS), y que se han constituido en áreas de investigación importantes para los grupos académicos e investigativos de Ciencias de la Computación a nivel mundial.

Una de las limitantes a las que se han enfrentando las empresas Colombianas (que en su gran mayoría son MyPiMes) al tratar de incorporar proyectos de DW como soporte a la toma de decisiones, reside en la naturaleza propietaria de las herramientas que actualmente son utilizadas para asistir las metodologías utilizadas para la planeación, diseño y construcción de un DW, ya que la adquisición de estas herramientas resulta muy costosa para la capacidades financieras de dichas empresas.

Por lo tanto este trabajo de grado pretende desarrollar una herramienta CASE que guíe el equipo de desarrollo de un proyecto de DW, por medio de una metodología (Ciclo de vida propuesto por Kimball) que facilite al usuario el seguimiento de las actividades, la documentación del proceso, la interacción con un grupo de trabajo y el manejo de un repositorio central para los documentos.

Además con el desarrollo de este trabajo se aprovechara y aplicara la experiencia que el GTI tiene en el desarrollo proyectos de DW, lo cual además de impactar en el largo plazo las empresas de la región y a nivel Nacional, ayudará a fortalecer el conocimiento en estas áreas del GTI.

El desarrollo del presente trabajo de grado titulado “Herramienta CASE para el soporte de proyectos de Data Warehousing basada en la metodología Kimball”, será realizado por los siguientes estudiantes del programa de Ingeniería de Sistemas: Alexander Ortiz Rosada y Oscar Eduardo Rendón Sotelo.

MSc. Martha Eliana MendozaDirector(a) del Proyecto


2. PLANTEAMIENTO DEL PROBLEMA.

2.1 DEFINICION.

Las Bodegas de Datos o DW por sus siglas en inglés (DW), el Procesamiento Analítico On-Line (OLAP) [Imh03] y la Minería de Datos (DM), son elementos tecnológicos indispensables en los procesos para el soporte a la toma de decisiones, y se han constituido en una línea de investigación de importante interés en el área de Ciencias de la Computación a nivel mundial.

La Universidad del Cauca, no ha sido ajena a las tendencias que, en este sentido orientan las investigaciones sobre el manejo y la gestión de los datos. Es así, que en los últimos años diversos proyectos se han llevado a cabo en nuestra facultad, explorando temáticas relacionadas con las áreas mencionadas anteriormente. En este sentido, se quiere continuar explorando en investigaciones encaminadas a explotar las ventajas que ofrecen estas tecnologías, comprobadas y establecidas globalmente para el manejo de los datos.

Es bien conocido por la comunidad involucrada en el área de desarrollo de DW, que una de las principales causas del fracaso en proyectos de esta clase, reside en la ausencia del uso de herramientas CASE que soporten y faciliten dicho desarrollo, y aunque la aceptación que ha logrado esta tecnología a nivel comercial en compañías con grandes flujos de datos ha hecho que existan en la actualidad varias herramientas de software propietario de esta naturaleza, aun no se cuenta en el entorno local con una herramienta CASE asequible y consolidada que soporte cada fase del ciclo de vida de Las DW’s. [Kel97].

Una de las limitantes en el entorno de desarrollo de proyectos de DW, reside en la naturaleza propietaria de las herramientas que actualmente son utilizadas para asistir las metodologías utilizadas para la planeación, diseño y construcción de un DW, ya que debido a la inmensa importancia que ha cobrado el manejo de los datos en las organizaciones, dichas herramientas resultan elevadamente costosas y constituyen un importante nicho de negocios. Un ejemplo de este tipo de herramientas es Visible Advantage Data Warehouse Edition [Vis01] reconocida herramienta que soporta los procesos de Business Intelligence o BI por sus siglas en ingles (BI) en importantes organizaciones como MTI Lincon Lab, NASA’s Kennedy Space Center, entre otras. Por otro lado, se han encontrado ciertas carencias y debilidades en cuanto a la utilización de estas herramientas, lo cual suscita la motivación para formular el presente proyecto. Entre estos inconvenientes se distinguen [Pow07]:

• (Acceso) La mayoría de las herramientas ofrecen funcionalidad limitada si no se cuenta con una licencia, que comúnmente tiene un precio que difícilmente podrían cubrir las empresas de desarrollo Colombianas, como lo muestra el estudio "Tecnología, oportunidad de crecimiento para las Pymes en Colombia", realizada por Cisco y ACOPI [Del07].

• (Metodología) Las herramientas no convergen en el seguimiento de una metodología estándar para proyectos que requieren la construcción de un DW, por el contrario, y en su mayoría, cada herramienta proporciona una

2


metodología propia o en su defecto un compendio de varias metodologías y estrategias de diseño, lo cual puede ocasionar inconvenientes para desarrolladores que no tengan la experiencia necesaria para abordar proyectos desde este enfoque. De igual manera no se tienen demasiadas referencias a herramientas que faciliten la aplicación de una metodología que encapsule de forma integral tareas, fases y procesos asociados al desarrollo en su totalidad del ciclo de vida para proyectos DW.

• (Documentación) En las etapas iniciales de un ciclo de vida propio del desarrollo de un DW, existen varias tareas como son, análisis de requerimientos, entendimiento del negocio, definición de los objetivos, entre otros, que resultan poco automatizables [Per01]. Ya que las estrategias utilizadas para abordar tales procesos podrían incluir entrevistas, reuniones, y documentos que establezcan planes consensuados entre el cliente y el diseñador, centrados a la definición del alcance y los objetivos del proyecto, estos documentos por lo general cambian continuamente durante la ejecución. Una herramienta CASE debería entonces incluir un repositorio capaz de gestionar dinámicamente estos eventuales cambios.

• (Equipos de trabajo) El trabajo en equipo para desarrollo en proyectos de DW, se puede ver afectado ya que la gran mayoría de las herramientas existentes soportan flujos de trabajo para un solo usuario por proyecto, siendo esto un problema para proyectos de gran magnitud.

Por lo tanto este proyecto está encaminado a la consecución de una herramienta CASE de alto nivel que guíe al equipo de desarrollo de un proyecto de DW, a través de todas las fases del ciclo de vida de un DW, siguiendo una metodología apropiada. Es necesario entonces, que la herramienta facilite al usuario el seguimiento de la metodología, la documentación del proceso, la interacción con un grupo de trabajo y el manejo de un repositorio central para los documentos, que permita administrar dinámicamente estas tareas proporcionando una interfaz en español. Es importante resaltar que esta herramienta no busca asistir etapas de diseño y construcción de una bodega a nivel de esquemas, modelos, y generación de código SQL, dado que no se busca competir con herramientas establecidas en el mercado que ya cumplen con estas tareas, el propósito entonces es, asistir a un equipo de trabajo en las tareas de alto nivel que conlleva el ciclo de vida y la metodología que se han escogido para tal fin. En este sentido, este proyecto identificará el conjunto de patrones necesarios para la construcción de una Herramienta CASE de alto nivel, que soporten el seguimiento de una metodología, en este caso, la metodología Kimball.

2.2 MARCO TEORICO.

2.2.1 HERRAMIENTAS CASE.

Las áreas de informática que no utilizan metodologías de desarrollo soportada por herramientas CASE, podrían compararse a empresas constructoras cuyos métodos de construcción se redujesen a la experiencia de sus operarios y cuyas herramientas constructivas fueran los tradicionales picos, palas, carretillas, etc. aunque sus equipos humanos estuvieran integrados por excelentes jefes de obra y oficiales de

3


albañilería, sus "métodos y técnicas artesanales" les impedirían abordar competitivamente cualquier proyecto de construcción actual, con independencia de que el mismo se llevase a cabo con los más modernos materiales.[Ced08]

El concepto de CASE es utilizado con mucha frecuencia en el ámbito de los sistemas de información para referirse a la ingeniería de sistemas asistida por computador o la ingeniería de software asistida por computador, entre las múltiples definiciones para CASE, resaltaremos la sugerida por Logge Terry [Ter90], quien define el concepto CASE como:

“Herramientas individuales para ayudar al desarrollador de software o administrador de proyecto durante una o más fases del desarrollo de software (o mantenimiento).”

Componentes de una Herramienta CASE [Ken05]:

De una forma esquemática podemos decir que una herramienta CASE se compone de los siguientes elementos:

• Repositorio: (diccionario) donde se almacenan los elementos definidos o creados por la herramienta, y cuya gestión se realiza mediante el apoyo de un Sistema de Gestión de Base de Datos (SGBD) o de un sistema de gestión de ficheros. • Meta modelo: (no siempre visible), que constituye el marco para la definición de las técnicas y metodologías soportadas por la herramienta. • Generador de documentación: El módulo generador de la documentación ofrece a la herramienta CASE la construcción de documentos relacionados con las especificaciones que se tienen contenidas en el repositorio central y que sean necesitadas en el transcurso del proyecto [Inei06].• Carga o descarga de datos: son facilidades que permiten cargar el repertorio de la herramienta CASE con datos provenientes de otros sistemas, o bien generar a partir de la propia herramienta esquemas de base de datos, programas, etc. que pueden, a su vez, alimentar otros sistemas. Este elemento proporciona así un medio de comunicación con otras herramientas. • Comprobación de errores: Facilidades que permiten llevar a cabo un análisis de la exactitud, integridad y consistencia de los esquemas generados por la herramienta. • Interfaz de usuario: Que constará de editores de texto y herramientas de diseño gráfico que permitan, mediante la utilización de un sistema de ventanas, iconos y menús, con la ayuda del ratón, definir los diagramas, matrices, etc. que incluyen las distintas metodologías.

Aunque cabe anotar, que no todas las herramientas CASE contienen en su totalidad los componentes mencionados anteriormente.

Existen tres tipos de productos CASE de acuerdo a [Alb00]:

• CASE de alto nivel: Una herramienta CASE de alto nivel o UPPER CASE está diseñada para soportar los niveles más altos de abstracción de los componentes software. Son herramientas que, en su mayoría, cubren las primeras fases del ciclo de vida, se utilizan para la planificación de proyectos, análisis y diseño general del sistema. Algunos ejemplos son herramientas de ingeniería de requerimientos, herramientas de diseño, herramientas de modelado y de documentación. Para

4

http://www.monografias.com/trabajos12/diccienc/diccienc.shtml

http://www.monografias.com/trabajos14/matriz-control/matriz-control.shtml

http://www.monografias.com/trabajos12/diflu/diflu.shtml

http://www.monografias.com/trabajos13/hisdisgr/hisdisgr.shtml

http://www.monografias.com/trabajos13/hisdisgr/hisdisgr.shtml

http://www.monografias.com/trabajos13/libapren/libapren.shtml

http://www.monografias.com/trabajos12/fundteo/fundteo.shtml

http://www.monografias.com/trabajos6/juti/juti.shtml

http://www.monografias.com/trabajos/adolmodin/adolmodin.shtml

http://www.monografias.com/trabajos11/basda/basda.shtml

http://www.monografias.com/trabajos11/teosis/teosis.shtml

http://www.monografias.com/trabajos15/sistemas-control/sistemas-control.shtml


entender de una forma más precisa la definición de una herramienta CASE de alto nivel, es necesario mencionar las tareas que no son propias de este contexto; una herramienta de alto nivel NO está diseñada para asistir procesos de: compilación, depuración, generación y control de código y pruebas de unidad. [Opf06]

• CASE de bajo nivel: Son productos basados en el uso de la propia maquina a la que se destina la aplicación y están orientados a: generación de bases de datos, generación de programas, soporte de pruebas. Al estar asociados a una plataforma definida ofrecen mejor capacidad de elección.• CASE integrado: Comprende todos los elementos de CASE superior e inferior, y, por lo tanto debería cubrir todas las fases del ciclo de vida de forma totalmente compatible y coherente.

1.2.2 DATA WAREHOUSE.

Según Ralph Kimball, [Kim96] un DW se define como "una copia de las transacciones de datos específicamente estructurada para la consulta y el análisis". También fue Kimball quien determinó que un DW no era más que: "la unión de todos los Data Marts de una entidad". Defiende por tanto una metodología ascendente (bottom-up) a la hora de diseñar un DW.

La arquitectura básica de DW (Ver figura 1) debe incluir herramientas para la extracción de datos desde múltiples fuentes operacionales como son bases de datos operacionales, recursos externos, hojas de cálculo, reportes, archivos planos, etc. Dichas herramientas deben soportar el proceso de Extracción, Transformación y Carga o proceso ETL por sus siglas en inglés, es decir, Extracción, Transformación y Carga de los datos desde sus fuentes, además de la integración de los datos en la bodega y actualizaciones periódicas en la bodega que reflejen la actividad de los datos en las fuentes. Además de la DW principal deberían existir varios DataMarts correspondientes a las diferentes divisiones corporativas o áreas de negocio de la organización, La DW principal contiene los metadatos y metamodelos que describen la estructura interna y la organización de los datos, además de algunos datos derivados generales, los datos derivados provienen de los datos primitivos de la carga de datos después de aplicarles alguna transformación; Los DataMarts contienen los datos derivados exclusivos de cada departamento o área organizacional y son administrados y monitoreados por uno o varios servidores de Warehouse, los cuales proporcionan las vistas multidimensionales del modelo a diferentes servidores OLAP, los cuales proveen el soporte a diferentes herramientas de usuario final, como son herramientas de consulta, análisis, reporte y minería de datos. Por último, debe existir un repositorio para almacenar los metadatos y también herramientas para monitorear y administrar el sistema de DW.

5

http://www.wikipedia.es/enciclopedia/Top-down_y_Bottom-up

http://www.wikipedia.es/enciclopedia/Data_mart

http://www.wikipedia.es/enciclopedia/Data_mart


Fig.1 Arquitectura de un DW. (Adaptado de [Sur01])

1.2.3 METODOLOGIA KIMBALL (Metodología BDL).

El marco presentado por Ralph Kimball con el nombre de Business Dimensional Lifecycle (BDL) ilustra las diferentes etapas por las que debe pasar todo proceso de Data Warehousing. Este enfoque de implementación de DW es ilustrado en figura 2. Este diagrama ilustra la secuencialidad de tareas de alto nivel requeridas para el efectivo diseño, desarrollo e implementación de DW’s. El diagrama muestra una vista general del mapa de ruta de un proyecto en el cual cada rectángulo es una etapa que nos indica dónde estamos ubicados, que etapas hemos realizado y hacia dónde debemos dirigirnos. [Mic05]

Fig. 2. Business Dimensional Lifecycle propuesto por Ralph Kimball.(Adaptado de [Kim96])

Es importante aclarar, que el BDL no intenta reflejar un proyecto en término de tiempos y plazos. Como se puede notar, cada rectángulo del diagrama tiene el mismo ancho, con la excepción del gerenciamiento del proyecto. La experiencia en proyectos de Data Warehousing sostiene que la magnitud de recursos y tiempo

6


requerido para cada rectángulo del ciclo de vida no es igual. El BDL se focaliza en la secuencialidad y la concurrencia y no en tiempos y plazos.

Cada etapa del ciclo de vida de la figura 2 se describe a continuación [Mic05]:

• Planificación del Proyecto.La planificación busca identificar la definición y el alcance del proyecto de DW, incluyendo justificaciones del negocio y evaluaciones de factibilidad.La planificación del proyecto se focaliza sobre recursos, perfiles, tareas, duraciones y secuencialidad. El plan de proyecto resultante identifica todas las tareas asociadas con el BDL e identifica las partes involucradas.

• Definición de los Requerimientos del Negocio.Según la perspectiva de Kimball [Kim98], los requerimientos del negocio se posicionan en el centro del “universo del DW”. Como destaca siempre el autor, los requerimientos del negocio deben determinar el alcance del DW (qué datos debe contener, cómo debe estar organizado, cada cuánto debe actualizarse, quiénes y desde dónde accederán, etc.).

• Modelado Dimensional.Diseñar los modelos de datos para soportar estos análisis requiere un enfoque diferente al usado en los sistemas operacionales. Básicamente se comienza con una matriz donde se determina la dimensionalidad de cada indicador y luego se especifican los diferentes grados de detalle (atributos) dentro de cada concepto del negocio (dimensión), como así también la granularidad de cada indicador (variable o métrica) y las diferentes jerarquías que dan forma al modelo dimensional del negocio (BDM) o mapa dimensional.

• Diseño FísicoEl diseño físico de las base de datos se focaliza sobre la selección de las estructuras necesarias para soportar el diseño lógico. Algunos de los elementos principales de este proceso son la definición de convenciones estándares de nombres y características específicas del ambiente de la base de datos.

• Diseño y Desarrollo de Presentación de Datos.Esta etapa es típicamente la más subestimada de las tareas en un proyecto de DW. Las principales subetapas de esta zona del ciclo de vida son: la extracción, la transformación y la carga (proceso ETL). Se definen como procesos de extracción a aquellos requeridos para obtener los datos que permitirán efectuar la carga del Modelo Físico acordado. Así mismo, se definen como procesos de transformación los procesos para convertir o recodificar los datos fuente a fin poder efectuar la carga efectiva del Modelo Físico. Por otra parte, los procesos de carga de datos son los procesos requeridos para poblar el DW.

• Diseño de la Arquitectura Técnica.Los ambientes de Data Warehousing requieren la integración de numerosas tecnologías. Se debe tener en cuenta tres factores: los requerimientos del negocio, los actuales ambientes técnicos y las directrices técnicas estratégicas futuras planificadas para de esta forma poder establecer el diseño de la arquitectura técnica del ambiente de Data Warehousing.

7


• Selección de Productos e Instalación.Utilizando el diseño de arquitectura técnica como marco, es necesario evaluar y seleccionar componentes específicos de la arquitectura como ser la plataforma de hardware, el motor de base de datos, la herramienta de ETL o el desarrollo pertinente, herramientas de acceso, etc. Una vez evaluados y seleccionados los componentes determinados se procede con la instalación y prueba de los mismos en un ambiente integrado de data Warehousing.

• Especificación de Aplicaciones para Usuarios Finales.No todos los usuarios del DW necesitan el mismo nivel de análisis. Es por ello que en esta etapa se identifican los diferentes roles o perfiles de usuarios para determinar los diferentes tipos de aplicaciones necesarias en base al alcance de los diferentes perfiles (gerencial, analista del negocio, vendedor, etc.)

• Desarrollo de Aplicaciones para Usuarios Finales.Una vez que se ha cumplido con todos los pasos de la especificación y se tiene la posibilidad de trabajar con algunos datos de prueba, comienza el desarrollo de la aplicación [Kim98]: Selección de un enfoque de implementación, Desarrollo de la aplicación y Prueba y verificación de datos.

• Implementación.La implementación representa la convergencia de la tecnología, los datos y las aplicaciones de usuarios finales accesible desde el escritorio del usuario del negocio. Hay varios factores extras que aseguran el correcto funcionamiento de todas estas piezas, entre ellos se encuentran la capacitación, el soporte técnico, la comunicación, las estrategias de feedback. Todas estas tareas deben ser tenidas en cuenta antes de que cualquier usuario pueda tener acceso al DW.

• Mantenimiento y crecimiento.Data Warehousing es un proceso (de etapas bien definidas, con comienzo y fin, pero de naturaleza espiral) pues acompaña a la evolución de la organización durante toda su historia. Se necesita continuar con los relevamientos de forma constante para poder seguir la evolución de las metas por conseguir. Según afirma Kimball [Kim98], “si se ha utilizado el BDL el DW está preparado para evolucionar y crecer”.

• Gerenciamiento del ProyectoEl gerenciamiento del proyecto asegura que las actividades del BDL se lleven en forma clara y sincronizada. Como lo indica el diagrama, el gerenciamiento acompaña todo el ciclo de vida. Entre sus actividades principales se encuentra el monitoreo del estado del proyecto y la comunicación entre los requerimientos del negocio y las restricciones de información para poder manejar correctamente las expectativas en ambos sentidos.

Es importante presentar la estructura de la DW para el usuario final a través de un modelo comprensible. Existen dos modelos dominantes utilizados actualmente en Las DW’s: el modelo relacional y el modelo dimensional (conocido como "esquema estrella"); Este último, diseñado por Ralph Kimball, cumple con los tres requisitos para la comprensión de los modelos de datos citados por McGee [McG76]. Es decir, cuenta con importantes características entre las que se incluyen simplicidad, elegancia y fácil

8


representación, lo que permite al diseñador de DW una fácil abstracción por medio de la representación visual, las estructuras que el modelo utiliza y la robustez del mismo.

2.3ANTECEDENTES.

Aunque en general, existen diversas herramientas CASE destinadas a apoyar procesos de DW, la mayoría de estas son herramientas CASE de bajo nivel que se enfocan en soportar tareas de diseño y construcción del DW, además de ser de naturaleza propietaria. Sin embargo, no se encontraron herramientas que realicen el seguimiento detallado de una metodología específica, reconocida y de libre acceso. A continuación se describen tres de los antecedentes de herramientas CASE más importantes que se encontraron, aunque solo soporten una parte de las etapas de una metodología del desarrollo de proyectos DW:

• Diseño Lógico de DW’s a partir de Esquemas Conceptuales Multidimensionales [Per01].

Este proyecto, correspondiente a la línea de investigación en DW llevado a cabo por el grupo CSI - Instituto de Computación - Fac. Ingeniería - UDELAR. Montevideo, Uruguay. Se ocupa de algunos problemas de diseño lógico de un DW. Concretamente se propone un proceso de diseño para generar el esquema lógico relacional del DW a partir de un esquema conceptual multidimensional y una base de datos fuente integrada. La generación toma lugar aplicando transformaciones de esquemas al esquema relacional de la base de datos fuente. Se propone un algoritmo que determina qué transformaciones se deben aplicar, basadas en un conjunto de reglas de diseño. En la evaluación de las reglas intervienen el esquema conceptual, la base de datos fuente, correspondencias entre ellos y estrategias de diseño que indican restricciones de performance y almacenamiento.

El trabajo incluye el prototipo de una herramienta CASE que asiste al diseñador en la construcción de un DW relacional a partir de una especificación conceptual, y consta de dos herramientas principales: una de asistencia en la definición de lineamientos y otra en la definición de mapeos.

Este antecedente está enfocado en la construcción de una herramienta CASE que automatiza tareas de definición de lineamientos y mapeos para la construcción de los esquemas conceptual, lógico y físico de un DW basados en el modelo CMDM [Car00]. Sin embargo, esta herramienta no contempla el seguimiento bien detallado de una metodología especifica y se centra en tareas netamente de diseño y construcción del DW; en contraste la CASE propuesta en este proyecto pretende asistir tareas como: Análisis de las fuentes de datos, Definición de los requerimientos del DW, Análisis de las reglas de negocio e identificación de los objetos relevantes para la toma de decisiones, entre otras.

• WAND – Herramienta CASE para el diseño basado en las cargas de trabajo de DataMarts. [Gol02].

Este proyecto presenta las principales características del prototipo de la herramienta CASE, que se ha diseñado para asistir la metodología de diseño de arquitecturas

9

http://www.rau.edu.uy/universidad/

http://www.fing.edu.uy/

http://www.fing.edu.uy/inco

http://www.fing.edu.uy/inco/grupos/csi/


ROLAP para DW propuesta por Matteo Golfarelli, Stefano Rizzi, Ettore Saltarelli [Gol02]. WanD asiste al diseñador en la construcción de un DataMart, llevando a cabo el diseño en una forma semi-automática desde las fuentes relacionales operacionales, y permite definir una carga de trabajo principal en el esquema conceptual, la adquisición de los datos en su totalidad y construcción del modelo lógico y físico para el esquema del DataMart. Además de generar las sentencias SQL para la creación de tablas y de índices.

Esta investigación se centra en la definición de los pasos básicos necesarios para un correcto diseño de arquitecturas ROLAP. WAND, por sus siglas en Inglés (WAreHouse INtegrated Designer), es una herramienta CASE que asiste la implementación de dicha metodología. El modelo conceptual adoptado es el Modelo De Hechos Dimensionales, (DFM) descrito en [Gol01].

El desarrollo de esta herramienta CASE presenta una propuesta completa para el proceso de desarrollo de un DW, y se basa en una metodología para el diseño y especificación del esquema del DW en base a un modelo formal desarrollado por los autores que es el Modelo Dimensional de Hechos (DFM - Dimensional Fact Model), este modelo presenta seis fases, que se realizan secuencialmente, a saber: análisis del sistema de información, especificación de requerimientos, diseño conceptual, refinamiento de la carga de trabajo y validación del esquema, diseño lógico y diseño físico, lo que provee un marco definido, claro y formal para la obtención de DW’s que cumplan con propiedades de calidad importantes desde el punto de vista del modelado del mismo.

Si bien WAND se basa en la metodología propuesta por sus creadores, la herramienta no proporciona la asistencia suficiente para cada una de las seis fases mencionadas, en cambio enfoca la mayor parte de su funcionalidad a la construcción de modelos lógicos, conceptuales y físicos, así como a la generación de código SQL para la creación de tablas asociadas al DataMart; La metodología propuesta por Ralph Kimball considera diversas fases y esfuerzos dedicados a la planeación y administración del proyecto de DW (definición del proyecto, preparación de la empresa para un proyecto de DW). Para luego centrar el proyecto a su enfoque, y lo justifica para recibir el apoyo y presupuesto de desarrollo (desarrollar la justificación del negocio, planeación del proyecto, desarrollo del plan del proyecto y la administración del proyecto) y finalmente siguiendo con las demás etapas de construcción de un DW (análisis de requerimientos, modelamiento dimensional, diseño técnico de la arquitectura, procesos de extracción, trasformación y carga de datos (ETL), selección e instalación de los productos, mantenimiento y crecimiento de un DW) en una forma más detallada y con procesos muy bien definidos, los cuales se buscan asistir de forma detallada con el desarrollo de este proyecto.

• Visible Advantage Data Warehouse Edition.

La versión Data Warehouse (DW) de la herramienta CASE Visible Advantage denominada Visible Advantage Data Warehouse Edition da soporte automatizado a todas las tareas de Análisis y Diseño de los proyectos Data Warehouse / Data Mart, desde su concepción de partida incluyendo alcance y beneficios, hasta la creación de la base de datos en la que reside el Data Warehouse: normalizada, desnormalizada, esquema en estrella y / o copo de nieve. En los proyectos Data Warehouse, Visible

10


Advantage DW automatiza las tareas, y resultados asociados con su ejecución, que se indican:

• Definición de requerimientos, objetivos y directivas de negocio, • Identificación de las necesidades de datos del negocio y del diccionario del

Data Warehouse, • Recuperación automática de las bases de datos diseñadas teniendo en cuenta

distintas fuentes de datos potenciales, • Capacidad de referencias cruzadas para identificar fuentes múltiples de datos

asociadas con cualquier atributo del DW, • Análisis visual de los procesos de transformación que especifican los ficheros

fuentes y destino, • Diseño del Data Warehouse y / o Data Mart.

Es una herramienta propietaria desarrollada por Visible Systems Corporation [Vis04] y está establecida como una de las herramientas más importantes para el desarrollo de DW’s a nivel mundial, y define en sí misma una metodología y estructura de trabajo bajo componentes propios desarrollados por la empresa, que no son de libre acceso y divulgación.

2.4JUSTIFICACION.

En la actualidad, el mercado mundial aún cuenta con una limitada oferta de herramientas que soporten desarrollos involucrados con Data Warehouse, incluso las herramientas existentes centran la mayor parte de su funcionalidad en el desarrollo de modelos de Business Intelligence [Imh03], autogeneración de código y en fases de implantación para proyectos de Data Warehouse, apartándose de llevar a cabo el seguimiento de una metodología aplicada a un ciclo de vida de Data Warehousing, bajo un concepto que incorpore el soporte para orientar las actividades de los distintos roles en un equipo de desarrollo. La conformación de un equipo de desarrollo y de sub grupos organizados por roles (role cluster) permite estructurar a las personas y sus actividades en la consecución de proyectos exitosos. El modelo de equipo debe organizarse en equipos pequeños y multidisciplinarios, en los cuales frecuentemente los miembros comparten responsabilidades teniendo una visión común del proyecto, estos equipos tienen la habilidad de responder más rápido que los equipos grandes. Las herramientas existentes, además de no considerar éste enfoque, resultan extremadamente costosas para ser empleadas a nivel académico y en PYMES como se puede ver en [Del07]; puesto que en su totalidad o gran mayoría consisten en software propietario.

Analizado el estudio presentado por [Dav05] se ha encontrado que la utilización de métodos superiores de representación como el modelo dimensional mejora la capacidad de comprensión del negocio, aun para usuarios con poca experiencia en diseño de DW, por esta razón se utilizara en este proyecto el modelo dimensional para soportar la fase de diseño en la construcción del DW.

La metodología de Bodega de Datos que seguirá la herramienta CASE de alto nivel a desarrollar es la propuesta por Ralph Kimball [Kim96], dado que esta metodología además de basarse el modelo dimensional mencionado en [Dav05], cuenta con el mejor nivel de detalle para cada una de sus etapas, en las cuales utiliza instrumentos como: formatos, archivos, plantillas, etc. A continuación se presenta la comparación

11

http://ceds.nauta.es/informes/empresatic04b.htm#ENL6











de algunas de las metodologías mas importantes de DW expuesta en el artículo “X-META: A Methodology for DW Design with Metadata Management” [Car02], que ilustra la diferenciación de las principales características de las metodologías de DW. Esta diferenciación se presenta en la tabla 1.

Otra de las razones para escoger la metodología propuesta por Kimball, es debido a que Kimball es considerado como uno de los padres del concepto de DW y es reconocido por su gran experiencia en el desarrollo de proyectos de Data Warehousing, como se menciona en [Jua05].

Gardner, S. R. Kimball, R., Reeves, L., Ross, M., Thornthwaite, W.

Pereira, W. A. L. Poe, V. Klauer, P.; Brobst, S

Estrategia evolutiva

Si Si Si Si

Miembros de el equipo del proyecto

Equipo experimentado y usuario del negocio

Equipo experimentado

Equipo inexperto Equipo experimentado y usuarios finales participando en la implementación del equipo

Productos del proceso de desarrollo

• Arquitectura de datos

• Proyecto de BD

• Metadatos


• Arquitectura funcional

• Infraestructura técnica

• Modelado dimensional

• Proyecto de BD

• Aplicación de usuario final

• Metadatos





• Proyecto de BD






• Proyecto de BD


• Metadatos

Nivel de detalle No muy detallado Muy detallado Detallado DetalladoProyecto piloto No "Prueba del

concepto"(Selección e instalación del producto)

“Arquitectura e infraestructura”(Fase de experimentación)

“Prueba del concepto” y “Arquitectura e infraestructura”, antes del despliegue del DW

Creación y administración de metadatos

No muy detallado Detallado, pero no integrado a la metodología

No detallado Detallado, pero no integrado a la metodología

Tabla 1. Metodologías DW (Adaptado de [Car02])

Otro aspecto importante que se considera en el desarrollo de este trabajo de grado y que tiene un componente de innovación, es la realización de un estudio que permita determinar los patrones de diseño de software necesarios para la construcción de una herramienta CASE de alto nivel que de soporte al desarrollo de un DW, basados

12


en la metodología de Ralph Kimball, ya que no se encontraron trabajos de investigación que presente patrones de diseños en esta área.

Dado el panorama local en lo referente a la investigación y adopción de las tecnologías basadas en DW, es necesario centrar esfuerzos en labores de investigación encaminadas a una apropiación del conocimiento y a una profundización de conceptos en temáticas que sobre estas tecnologías se viene incursionando tanto en la Universidad del Cauca como en otras instituciones de educación superior a nivel Nacional. A nivel investigativo, este proyecto busca incursionar en una línea de investigación que no ha sido demasiado explorada en la Universidad, como es la construcción de herramientas CASE de alto nivel, y se busca con la ejecución del proyecto recopilar experiencia que sirva para desarrollos similares a futuro; ya que para dar soporte a la metodología planteada se requiere una herramienta CASE de alto nivel que permita el seguimiento paso a paso de las tareas planteadas en el ciclo de vida, que ayude a generar y gestionar los principales productos que sugiere la metodología, y que guíe al usuario presentando ayudas útiles o sugerencias para cada tarea específica. Para este fin, el proyecto busca realizar un estudio detallado de la metodología que permita definir las funcionalidades específicas que debe implementar la herramienta CASE de alto nivel, determinar los roles del equipo de trabajo necesarios que debe considerar la herramienta y determinar los Patrones de Diseño necesarios para la construcción de la misma, de modo que pueda ser adaptable y reutilizable en contextos similares con algunas variantes en la implementación.

3. OBJETIVOS.

3.1 Objetivo General.

Modelar y desarrollar un prototipo de herramienta CASE de alto nivel1 que de soporte al desarrollo de DW, basados en la metodología del ciclo de vida del DW propuesta por Ralph Kimball [Kim96], y asista al equipo de desarrollo2 facilitando la ejecución de las tareas sugeridas por dicha metodología.

3.2 Objetivos Específicos.

1.Determinar el conjunto de patrones de diseño necesarios para construir la herramienta CASE de alto nivel1 que de soporte al desarrollo de DW, basados en la metodología del ciclo de vida del DW propuesta por Ralph Kimball.

2.Modelar la herramienta CASE basada en una arquitectura de software multi-capa, aplicando los patrones de diseño que se determinarán para el proyecto, apoyados en el lenguaje unificado UML para la documentación pertinente.

3.Desarrollar un prototipo de herramienta CASE de alto nivel, que ofrezca a los roles definidos para el equipo de desarrollo de DW, realizar el seguimiento detallado del

1 Para una definición de Case de alto nivel referirse al Marco Teórico, Sección Herramientas CASE.2 La herramienta CASE de alto nivel Stand Alone ofrecerá el manejo de los roles del equipo de desarrollo

definidos durante el proyecto.

13


proceso y mantener organizada y disponible la documentación de cada fase de la metodología de acuerdo a una guía propuesta por la herramienta.

4. ACTIVIDADES Y CRONOGRAMA.

4.1 METODOLOGÍA DE TRABAJO.

FASE 1En esta etapa, se realizará una revisión general de las principales características de la metodología Kimball, con el fin de identificar los artefactos de cada fase del ciclo de vida que se implementaran en la herramienta CASE de alto nivel. Además se evaluaran las características de las principales herramientas CASE existentes para desarrollo de DW. Estas actividades darán pie para la captura de requerimientos.

FASE 2La fase 2 involucra tareas orientadas hacia la construcción de la arquitectura del sistema, el estudio y selección de los patrones de diseño apropiados para la construcción de la herramienta CASE de alto nivel, de igual forma se estudiarán las tecnologías de desarrollo y se seleccionará la más adecuada para el desarrollo del proyecto.

FASE 3Durante esta fase se seguirá un enfoque incremental e iterativo para el análisis, diseño y construcción de cada modulo, así como la integración de cada modulo desarrollado con productos previamente implementados.

FASE 4A partir de los productos obtenidos en fases previas se realizara la validación de la arquitectura obtenida; de igual forma se realizaran pruebas de funcionalidad de la herramienta con un grupo de prueba previamente seleccionado de estudiantes de la Universidad del Cauca. FASE 5En forma paralela al desarrollo de las fases anteriores, se realizara una actividad permanente de documentación, así como ciertos hitos de divulgación de resultados; entre ellos la presentación de un artículo en un evento, revista nacional o internacional, la monografía de grado y sus anexos, y finalmente la sustentación del proyecto ante los jurados definidos por el Consejo de Facultad FIET.

14


4.2 CRONOGRAMA DE ACTIVIDADES.

5. RECURSOS, PRESUPUESTO Y FUENTES DE FINANCIACIÓN

5.1 Recursos requeridos.

RECURSOS HUMANOSFunción NombreDirector MSc. Martha Eliana Mendoza BecerraDesarrollador Alexander Ortiz RosadaDesarrollador Oscar Eduardo Rendón Sotelo

HARDWARECant. Descripción

2 Computadores de escritorio para desarrollo (Intel Pentium IV 3.0 Ghz, 1 GB RAM, D.D 80 GB)

1 Impresora

SOFTWARECant. Descripción

2 Microsoft Office 2007 Professional Edition1 Microsoft SQL Server 2005 Standard Edition2 Microsoft Visual Studio 2005 Professional Edition2 Microsoft Windows XP Professional Edition

OTROSDescripción

Acceso a Internet de banda anchaTinta negra y a color para impresoraPapel para impresión de documentosLibros y material de documentaciónTabla 2. Descripción de los Recursos requeridos.

15


5.2 Definición De Fuentes De Financiación

Nombre del investigado

r

Formación Académica Función Dedicación

Recursos Total

Unicauca ContrapartidaAlexander

Ortiz Rosada

Estudiante Ing.

SistemasDesarrollador 30 h/s $ 6.140.400 $ 6.140.400

Oscar Eduardo Rendón Sotelo

Estudiante Ing.

SistemasDesarrollador 30 h/s $ 6.140.400 $ 6.140.400

MSc Martha Eliana

Mendoza Becerra

Ing. Sistemas Directora 2 h/s $ 1.228.080 $ 1.228.080

TOTAL $ 1.228.080 $ 12.280.800 $13.508.880Tabla 3. Descripción de los gastos de personal

Equipos Valor unitario Valor total2 Computadores de escritorio para desarrollo* $ 1.250.000 $ 2.500.0001 Impresora $ 200.000 $ 200.000

TOTAL $ 1.450.000 $ 2.750.000*Valor relacionado con el uso del equipo en este proyecto en relación con su vida útil

Tabla 4. Descripción de los equipos

Software Valor unitario Valor totalMicrosoft Office 2007 Professional Edition* $ 0 $ 0Microsoft Visual Studio 2005 Professional Edition* $ 0 $ 0Microsoft Windows XP Professional Edition* $ 0 $ 0

TOTAL $ 0 $ 0* MSDN Academic Alliance o Campus Agreement

Tabla 5. Descripción de software

Materiales e insumos Valor unitario Valor totalAcceso a Internet de banda ancha $ 16.600 $ 16.600Tinta negra para impresora $ 100.000 $ 100.000 Tinta color para impresora $ 200.000 $ 200.000Papel para impresión de documentos $ 20.000 $ 20.000Libros y material de documentación $ 300.000 $ 300.000

TOTAL $ 636.600 $ 636.600Tabla 6. Descripción de materiales e insumos

Tabla/Justificación Recursos TotalUnicauca Contrapartida

16


Tabla . Gastos de personal. $ 1.228.080 $ 12.280.800 $ 13.508.880Tabla . Equipos. $ 2.750.000 $ 2.750.000Tabla . Software. $ 0 $ 0Tabla 6. Materiales e insumos. $ 636.600 $ 636.600

TOTAL $ 4.614.680 $ 12.280.800 $ 16.895.480Tabla 7. Resumen costos proyecto

6. CONDICIONES DE ENTREGA.Al culminar el presente trabajo se obtendrán los siguientes productos:

• Prototipo de herramienta CASE de alto nivel que da soporte a proyectos de DW en cada una de sus fases, teniendo como base la metodología propuesta por Ralph Kimball: Código fuente e instaladores.

• Monografía del trabajo de grado: Este documento describe el proceso seguido en el desarrollo del proyecto, los problemas que se presentaron, las respectivas soluciones, los aportes más sobresalientes del proyecto, conclusiones y recomendaciones para desarrollos futuros. Además en sus anexos se contará con el manual técnico de desarrollo de la herramienta.

• Artículo: Artículo producto del desarrollo del proyecto enviado a publicación en un evento/revista nacional o internacional, o en la sitio Web del proyecto.

7. CONTENIDO DEL DOCUMENTO FINAL.Para el documento final se han establecido de forma preliminar los siguientes capítulos:

Capítulo I: Introducción. Este capítulo contiene la visión general del proyecto, la problemática que originó su desarrollo, una descripción general de los resultados.

Capítulo II: Marco teórico. En esta sección se encuentra la base conceptual necesaria para la elaboración del proyecto. Incluye los conceptos de la metodología de desarrollo utilizada para el desarrollo de la herramienta, los fundamentos de CASE, la metodología BDL propuesta por Ralph Kimball.

Capítulo III: Descripción del modelo de soporte y la arquitectura de la herramienta CASE. Se describe el desarrollo realizado de los diferentes componentes del prototipo de herramienta CASE desarrollada, además de mencionar los problemas presentados a lo largo del proyecto las soluciones a los mismos.

Capítulo IV: Descripción general de la herramienta CASE. Se describe un resumen general de la funcionalidad de la herramienta, sus interfaces, mostrando las novedades presentadas por la herramienta.

Capítulo V: Conclusiones y recomendaciones. Se presenta un análisis final del desarrollo del proyecto y las recomendaciones para futuros trabajos.

Capítulo VI: Bibliografía y glosario. Indica la bibliografía utilizada para el desarrollo del trabajo así como el glosario del mismo.

17


Anexos. Contiene información adicional que permite complementar los capítulos desarrollados en la monografía de trabajo de grado.

8. REFERENCIAS

[Alb00] Albizuri-Romero, M. B. 2000. A retrospective view of CASE tools adoption. SIGSOFT Software. http://doi.acm.org/10.1145/346057.346071 [Car00] Carpani, F.: “CMDM: A conceptual multidimensional model for DW”. Master Thesis. InCo - Pedeciba, Universidad de la República, Uruguay, 2000.

[Car02] Carneiro, L., Brayner, A.: “X-META: A Methodology for DW Design with Metadata Management”, White Paper 2002.

[Ced08] Centro Mundial de Formacion por Internet en Analisis, Diseño Informático y CASE. (Visitado 2008, Mayo 18)

http://www.ceds.nauta.es/informes/case03.htm

[Dav05] Schuff, D., Turetken, O., and Corral, K.: “Comparing the Effect of Alternative DW Schemas on End User Comprehension Level,” 3rd Annual SIGDSS Pre-ICIS Workshop on Decision Support Systems, Las Vegas, NV. December 11, 2005.

[Del07] Estadisticas Delta, Inversiones en TIC de PyMes Colombia (Visitado el 2008, Julio 21) http://www.deltaasesores.com/esta/EST424.html

[Gol02] M. Golfarelli, S. Rizzi, E. Saltarelli. WAND: A CASE Tool for Workload-Based Design of a Data Mart. Proceedings Decimo Convegno Nazionale su Sistemi Evoluti Per Basi Di Dati, Portoferraio, Italy, pp. 422-426, 2002.

[Imh03] Imhoff, C., Galemmo, N., Geiger, J. “Mastering Data Warehouse Design, Relational and Dimensional Techniques”. (Wiley, Indianapolis, Indiana, USA: 2003 [Capítulos 1 y 2] )

[Inei06] INSTITUTO NACIONAL DE ESTADISTICA E INFORMATICA (Perú), Elaborado por la Sub-Jefatura de Informática. (Visitado 2006, 28 Noviembre). Herramientas CASE [Documento Informativo]. URL

(Visitado 2008, Febrero 15) http://www.inei.gob.pe/biblioineipub/bancopub/Inf/Lib5103/Libro.pdf

[Inm96] Inmon, W.: “Building the DW”. John Wiley & Sons, Inc. 1996.

[Jua05] Peña, R., Juan, D., and Daza, S., Jesús A.: Utilización de Información Histórica para Decisiones Empresariales, Junio 2005.

18

http://www.inei.gob.pe/biblioineipub/bancopub/Inf/Lib5103/Libro.pdf%20

http://www.inei.gob.pe/biblioineipub/bancopub/Inf/Lib5103/Libro.pdf%20

ftp://ftp-db.deis.unibo.it/pub/stefano/sebd02.pdf

ftp://ftp-db.deis.unibo.it/pub/stefano/sebd02.pdf

http://www.ceds.nauta.es/informes/case03.htm

http://doi.acm.org/10.1145/346057.346071


[Kel97] Kelly, S.: "Data warehousing in action", John Wiley & Sons, New York, 1997.

[Ken05] Análisis Y Diseño De Sistemas 3ª. Edición Kendall & Kendall Páginas 15.16.17.18

[Kim96] Kimball, Ralph.: “The DW Lifecycle Toolkit”, Wiley, 1996.

[Kim98] Kimball, R., Reeves, L., Ross, M., Thornthwaite, W.: “The DW Lifecycle Toolkit”, Wiley Computer Publishing. 1998.

[McG76] McGee, W. C.: “On user criteria for data model evaluation. ACM Transactions on Database Systems” 1, 4 380-387. 1976.

[Mic05] MicroStrategy Experiencia BI 2,: Resumen “Teoría sobre Business Intelligence”, Mayo 2005.

[Opf06] Open Process Framework (OPF), Glosary(Visitado 2008, Julio 21) http://www.opfro.org/index.html?Glossary/GlossaryU.html~Contents

[Per01] Peralta, Veronika.: “Diseño Lógico de DWs a partir de Esquemas Conceptuales Multidimensionales”. Undergraduate Project. Universidad de la República, Uruguay, 2001.

[Pow07] Power, D.J.: A Brief History of Decision Support Systems. DSSResources.COM, World Wide Web, (Visitado 2008, Marzo 23)http://DSSResources.COM/history/dsshistory.html, version 4.0, March 10, 2007.

[Sur01] Surajit,Chaudhuri., Umeshwar, Dayal.: “An Overview of Data Warehousing and OLAP Technology”, White Paper, Hewlett-Packard Labs, Palo Alto. 2001

[Ter90] Terry, B., Logge, D.: Terminology for Software Engineering and Computer-aided Software Engineering, Software Engineering Notes, Abril 1990

[Vis01] Visible Systems Corporations, Visible Advantage Data Warehouse Edition (Visitado 2008, Enero 26) http://www.visible.com/Products/Advantage/datawarehouse_ed.htm

19

http://www.visible.com/Products/Advantage/datawarehouse_ed.htm


UNIVERSIDAD DEL CAUCAFACULTAD DE INGENIERÍA ELECTRÓNICA Y TELECOMUNICACIONES

ACTA DE ACUERDO SOBRE LA PROPIEDAD INTELECTUAL DEL TRABAJO DE GRADO

En atención al acuerdo del Honorable Consejo Superior de la Universidad del Cauca, número 008 del 23 de Febrero de 1999, donde se estipula todo lo concerniente a la producción intelectual en la institución, los abajo firmantes, reunidos el día ___ del mes de __________ de _________ en el salón del Consejo de Facultad, acordamos las siguientes condiciones para el desarrollo y posible usufructo del siguiente proyecto.

Materia del acuerdo: Trabajo de grado para optar el título de Ingeniero en Sistemas.Título del Trabajo de Grado: Herramienta CASE para el soporte de proyectos de Data Warehousing basada en la metodología Kimball.

Objetivo del Trabajo de Grado: Modelar y desarrollar un prototipo de herramienta CASE de alto nivel para dar soporte a proyectos de DW, basada en la metodología BDL propuesta por Ralph Kimball.

Duración del Trabajo de Grado: 10 meses.Los participantes del trabajo de grado, los señores estudiantes de pregrado Alexander Ortiz Rosada, identificado con la cédula de ciudadanía número 10’292.309 de Popayán (Cauca) y Oscar Eduardo Rendón Sotelo, identificado con la cédula de ciudadanía número 10’304.420 de Popayán (Cauca), a quienes en adelante se le llamará "estudiante"; la ingeniera Martha Eliana Mendoza Becerra en calidad de directora del trabajo de grado, identificado con la cédula de ciudadanía 63.483.237 de Bucaramanga-Santander, a quien en adelante se le llamará "docente", y la Universidad del Cauca, representada por el ingeniero Rafael Rengifo Prado identificado con la cédula de ciudadanía número 10’523.038 de la ciudad de Popayán en su calidad de Decano de la FIET, manifiestan que:

1.- La idea original del proyecto es del Grupo de I+D en Tecnologías de Información (GTI), en cabeza de la docente Martha Eliana Mendoza, quien la propuso y presentó al Departamento de Sistemas, que la aceptó como tema para el proyecto de grado en referencia.2.- La idea mencionada fue acogida por el estudiante como trabajo de grado para obtener el título de Ingeniero de Sistemas, quien la desarrollará bajo la dirección del docente.3.- El trabajo de grado es financiado por la Universidad y los estudiantes en la naturaleza, cuantía y porcentajes establecidos en la tabla de presupuesto contenida en el anteproyecto.4.- Los derechos intelectuales y morales, corresponden al docente y a los estudiantes.5.- Los derechos patrimoniales corresponden al docente, a los estudiantes y a la Universidad del Cauca por partes iguales y continuarán vigentes, aún después de la desvinculación de alguna de las partes de la Universidad.6.- El programa de actividades y cronograma del trabajo de grado están estipulados en el anteproyecto. Todos los participantes en el trabajo de grado estarán vinculados por el tiempo de ejecución del mismo.7.- Los participantes se comprometen a cumplir con todas las condiciones de tiempo, recursos, infraestructura, dirección, asesoría, establecidas en el anteproyecto, a estudiar, analizar, documentar y hacer acta de cambios aprobados por el Consejo de Facultad,

20


durante el desarrollo del proyecto, los cuales entran a formar parte de las condiciones generales.8.- El estudiante se compromete a restituir en efectivo y de manera inmediata a la Universidad los aportes recibidos y los pagos hechos por la Institución a terceros por servicios o equipos, si el Consejo de Facultad declara suspendido el proyecto por incumplimiento del cronograma o de las demás obligaciones contraídas por el estudiante; y en cualquier caso de suspensión, la obligación de devolver en el estado en que les fueron proporcionados y de manera inmediata, los equipos de laboratorio, de cómputo y demás bienes suministrados por la Universidad para la realización del proyecto.9.- El docente y el estudiante se comprometen a dar crédito a la Universidad en los informes de avance y de resultados, y en el registro de éstos.10.- Cuando por razones de incumplimiento, legalmente comprobadas, de las condiciones de desarrollo planteadas en el anteproyecto y sus modificaciones, alguno de los participantes deba ser excluido del proyecto, los derechos aquí establecidos concluyen para él. También concluyen estos derechos cuando el estudiante pierde el derecho a continuar estudios al tenor de los principios establecidos en el reglamento estudiantil vigente de la Universidad del Cauca. 11.- El documento del anteproyecto y las actas de modificaciones si las hubiere, forman parte integral de la presente acta.12.- Los aspectos no contemplados en la presente acta serán definidos en los términos del acuerdo 008 del 23 de febrero de 1999 expedido por el Consejo Superior de la Universidad del Cauca, del cual los participantes del acuerdo aseguran tener pleno conocimiento.

Director: _________________________________________Mag. Martha Eliana Mendoza BecerraC.C. 63’483.237 de Bucaramanga (Santander)

Estudiante: _______________________________________Oscar Eduardo Rendón SoteloC.C. 10’304.420 de Popayán (Cauca)

Estudiante: _______________________________________Alexander Ortiz RosadaC.C. 10’292.309 de Popayán (Cauca)

Decano Facultad: _________________________________Mag. Rafael Rengifo Prado10’523.038 de Popayán

21