Explotación de Datos Aplicada al Ámbito Universitario

Transcripción

1 Instituto Tecnológico de Buenos Aires Universidad Politécnica de Madrid Trabajo presentado como requisito final del módulo IX de la Maestría en Ingeniería del Software Explotación de Datos Aplicada al Ámbito Universitario Alumno Lic. Carlos Alberto Marí Directores de Tesis M. Ing. Paola V. Britos M. Ing. Juan M. Bournissen Buenos Aires, Febrero 2005

2 IINDIICE 1. Introducción Descripción del problema en el estado actual Criterios para definir el éxito del producto software a desarrollar Esbozo de la solución Recursos y Tecnología a utilizar en la planificación tentativa Metodología a seguir Plan de trabajo Bibliografía Alumno: Carlos Alberto Marí Página: 2 de 21

3 1.. IINTRODUCCIIÓN Objetivo General El presente anteproyecto está orientado a satisfacer las necesidades de la alta dirección de las instituciones académicas de nivel superior, centrado en la información sobre los alumnos y específicamente en el régimen de promoción, es decir, en todo lo que tenga que ver con inscripción a materias, notas, exámenes, turnos, etc. Objetivos Particulares 1. Se busca otorgar a los directivos de la institución, de una herramienta que les permita tomar las mejores decisiones, con respecto a la situación académica de los alumnos, y 2. Optimizar a través de herramientas inteligentes el régimen de promoción de los alumnos analizando su desempeño académico. Usuario A través de los objetivos planteados se busca que este proyecto sea viable para cualquier institución académica de nivel superior. Se considerará, para la realización del primer prototipo como usuario a la Universidad Adventista del Plata (UAP), de la que se expondrán sus problemáticas y la solución a emprender. Alumno: Carlos Alberto Marí Página: 3 de 21

4 2.. DESCRIIPCIIÓN DEL PROBLEMA EN EL ESTADO ACTUAL La UAP recibe todos los años a unos 1800 alumnos que cursan alguna de las aprox. 30 carreras que esta imparte, organizadas administrativamente en 4 Facultades o Unidades Académicas. Dos veces al año (cuatrimestralmente) se realiza la denominada inscripción de asignaturas, momento en el que el alumno se anota o inscribe a las asignaturas que le corresponda de acuerdo a la oferta académica y a su avance en el estudio. Aunque el sistema ofrece cierta flexibilidad, el Régimen de Promoción para cada asignatura es similar y define que al terminar el cursado de la asignatura, un alumno podrá promocionar, regularizar o quedar libre. Si un alumno queda libre deberá volver a cursar la materia en un período posterior. Si un alumno regulariza, entonces, si se trata de una asignatura cuatrimestral, debe rendir un examen final en cualquiera de los 6 turnos de examen inmediatamente siguientes (3 turnos por año) y tiene 3 oportunidades para aprobar, es decir, puede rendir mal dos veces y aprobar en un tercer intento; si la asignatura es de cursado anual, entonces los turnos se extienden a 8 y los intentos a 4. Desde el momento que termina el cursado con estado regular al momento del examen final, se dice que la asignatura está regularizada y en ese estado, se permite la inscripción de correlativas siguientes. La escala de calificación utilizada para la evaluación de los exámenes finales es de 0 a 10, y se considera aprobado un examen si se obtiene una calificación igual o superior a 6. En relación a los turnos, hay que decir que actualmente existen 3 turnos generales y normales para exámenes finales: febrero, julio y diciembre. Sin embargo, la UAP ha visto necesario disponer de 2 turnos especiales (abril, septiembre) con el fin de ayudar a los alumnos que deben correlativas y destrabar alguna posible acumulación de materias en estado regular. Cada vez que un alumno inscribe una asignatura se crea o abre un legajo que se cierra recién cuando la asignatura es aprobada o perdida, adoptando alguna de las modalidades definidas en el régimen de promoción según sea el caso. Existen modalidades de aprobación, de regularización y de pérdida de una asignatura, las más importantes para el contexto del estudio se presentan en la siguiente tabla: Abrev. Nombre de Modalidad Detalle APD Aprobado por Promoción El alumno está eximido de rendir un examen final y Directa su nota final es igual a la calificación de regularización. Normalmente, mayor o igual a 8. API Aprobado por Promoción El alumno regularizó la asignatura y aprobó Indirecta rindiendo un examen final. Nota mayor igual a 6. RPI Regular por Promoción El alumno no aprobó por Promoción Directa, pero Indirecta tampoco desaprobó la materia. Debe rendir un examen final en los plazos y turnos estipulados por el régimen de promoción. PPT Perdido por Tiempo El alumno regularizó la asignatura y teniendo oportunidades para presentarse a rendir, no las aprovechó y se le acabó el tiempo (los 6 turnos siguientes al cursado). PPI Perdido por Intentos El alumno regularizó la asignatura y rindió las veces que podía, sin lograr aprobar. PRE Perdido por Recursar El alumno regularizó la asignatura y antes de que se venza por tiempo o por intentos, decide inscribirla para recursarla. Alumno: Carlos Alberto Marí Página: 4 de 21

5 Dificultades encontradas 1. Correlatividad y regularidad. Es de uso muy común que los planes de estudio tengan muchas correlativas entre asignaturas, es decir, muchas materias que tienen como prerrequisito otras. Por otro lado, está la situación que permite a un alumno mantener una asignatura en estado regular hasta 3 años en algunos casos. El Artículo 4 del Régimen de Promoción vigente, en su inciso (a) dice que para inscribirse en una asignatura se requiere tener regularizada sus correlativas anteriores. Notar que dice regularizada, es decir que para cursar una asignatura no se requiere la aprobación de los prerrequisitos. Esto permite que un alumno curse y regularice Análisis Matemático I, por ejemplo; que sin aprobarla, se inscriba para cursar Análisis Matemático II (que tiene como prerrequisito Análisis Matemático I) y también la regularice (no puede rendir finales hasta aprobar todos los prerrequisitos); entonces se inscriba para cursar Análisis Matemático III (que tiene como prerrequisito Análisis Matemático II) sin todavía tener aprobada Análisis Matemático I (Ver figura 1). Figura 1: Problemática en relación a la correlatividad y regularidad de una materia A juicios de algunos académicos de la UAP, plantean que hoy estas situaciones son absolutamente nocivas y están lejos de ayudar a un alumno y menos mejorar su rendimiento. Puede ocurrir que un alumno deba rendir un final de una materia que ya fue dictada otra vez posteriormente, por otro profesor y con contenidos modificados y el alumno deba presentarse a rendir con los nuevos contenidos y el nuevo profesor. Alumno: Carlos Alberto Marí Página: 5 de 21

6 Entonces se han sugerido estudios del Régimen de Promoción para revisar estos detalles y evaluar su aplicación así como está funcionando. Será que realmente está ayudando a los alumnos? Será que el régimen así de flexible está siendo utilizado realmente por los alumnos, en el sentido de aprovechar los intentos disponibles y aprobar asignaturas que sin esos plazos no lo harían? Será que son necesarios tantos turnos, pensando en los alumnos y en el costo que significa la implementación de cada uno? No será que un porcentaje significativo de las materias son aprobadas por promoción directa? o que otra proporción importante apruebe rindiendo un único examen final en su primera oportunidad? Por otro lado, se tiene la sospecha (por ahora) que es considerable la cantidad de asignaturas que se pierden por tiempo y/o por recursar y, que por lo tanto, no se está ayudando con otorgar 3 años de regularidad o más de 10 oportunidades para rendir un final anual, por ejemplo. (Ver figura 2) Figura 2: Dudas del presente régimen de promoción en relación al beneficio para el alumno La facultad de Teología de la UAP experimentó durante dos años suprimir la 'regularidad', es decir que el alumno terminaba de rendir y en el turno de diciembre debía rendir, siendo esta su única oportunidad de aprobar la materia. Las razones por las que se discontinúo este procedimiento son: Comenzó a generarse muchas situaciones que implicaban la realización de excepciones. Por ejemplo enfermedad, salidas especiales, etc. Estas situaciones impedían al alumno, por fuerza mayor, aprovechar el único turno del cual disponían. Terminó siendo un régimen de excepciones. Los docentes indirectamente sentían cierta presión a la hora de desaprobar a un alumno, sabiendo que si o si debía recursar la materia Alumno: Carlos Alberto Marí Página: 6 de 21

7 El resto de las unidades académicas tenía un régimen de promoción totalmente diferente y esto generaba ciertas dificultades a Secretaría General Existía un beneficio administrativo de la facultad pero no se percibía un beneficio para el alumno. Es probable que cuando dicha facultad implementó este cambio en el régimen de promoción, no se contó con información adecuada para realizar un cambio apropiado, siendo necesario un regreso al plan original. 2. No se puede integrar fácilmente datos que provienen de diferentes aplicaciones informáticas del entorno universitario. 3. Existe inconsistencia en la información que manejan distintos sectores de la institución. 4. Distribución de los datos no adecuada para el análisis. Los datos transaccionales no están organizados de una manera que proporcione fácilmente la información requerida por los administradores. Los administradores necesitan información resumida a partir de la cual puedan analizar tendencias que afecten a su organización o equipo. Necesitan encontrar los factores críticos que afectan al éxito de la institución y la forma óptima de ajustar esos factores para mejorar el éxito de la misma. 5. Se toman decisiones sin contar con la suficiente información para que las mismas puedan estar bien respaldadas, y por otro lado no se toman decisiones por falta del conocimiento necesario. Existe un déficit de información para la toma de decisiones Otros sistemas académicos analizados Para poder plantear una solución se investigó en distintas instituciones académicas, obteniéndose el siguiente resultado: a) Tecnológico de Monterrey (TM) 1 Esta universidad ha realizado desarrollos muy interesantes llegando a establecer una muy buena integración informática entre la institución, docentes y alumnos. Entres las ventajas de este sistema se encuentran: Lista de clases, donde el profesor puede ver la lista de cursos en los cuales esta como instructor Los docentes pueden ingresar sus calificaciones e inmediatamente puede ser consultada por el alumno Ver y actualizar información personal Ver información del alumno Correo electrónico automatizado, que permite a los docentes enviar mensajes a los alumnos tan pronto como se inscriben al curso. Boleta electrónica de calificaciones. No tiene un enfoque orientado a la Inteligencia de Negocios. 1 Alumno: Carlos Alberto Marí Página: 7 de 21

8 b) Universidad Nacional de Asunción (UNA) 2 El objetivo principal del sistema es proveer a la Universidad de mecanismos automatizados que faciliten la planificación, organización, gestión y control académico. La arquitectura del sistema está pensada para su uso en un entorno multiusuario dando alcance a los diferentes sectores que componen la organización de la Universidad, especialmente a estudiantes, docentes, al sector administrativo y a la dirección académica. A continuación se exponen las principales funcionalidades del Sistema de Gestión Académica: Plan de estudios Ingreso a las carreras Administración de datos personales de alumnos y docentes Definición del calendario de exámenes Inscripción a cursar materias Evaluaciones parciales Generación automática de derechos a exámenes finales Inscripción a los exámenes finales y registro de notas Egresados Convalidaciones Reportes estadísticos Consultas y procesos vía Web No tiene un enfoque orientado a la Inteligencia de Negocios. c) Instituto Tecnológico de Buenos Aires (ITBA) 3 Esta universidad se encuentra actualmente desarrollando un sistema similar al pretendido por el presente anteproyecto, en lo que respecto al uso de la tecnología de Inteligencia de Negocio, pero aplicada a otra área. El trabajo que se está desarrollando en el ITBA forma parte del trabajo de tesis del Ing. Javier Nader, alumno de la escuela de Postgrado de este mismo establecimiento. Tiene un enfoque orientado a la Inteligencia de Negocios pero orientado a otra área diferente a la pretendida por el presente anteproyecto, además de estar en un proceso de desarrollo Alumno: Carlos Alberto Marí Página: 8 de 21

9 Cuadro comparativo de las instituciones evaluadas Características TM UNA ITBA UAP Herramienta de consulta y reporte Herramienta de B.D. Multidimensional Herramienta de Minería de Datos Sistema de información ejecutiva Sistema de Gestión de Base de Datos Análisis de información por planilla y gráfico Posibilidad de exportaciones para la generación de presentaciones Integración Institución-Docente-Alumno Enfoque orientado a Inteligencia de Negocios Enfoque orientado a Explotación de Datos a través de Sistemas Inteligentes Alumno: Carlos Alberto Marí Página: 9 de 21

10 3.. CRIITERIIOS PARA DEFIINIIR EL ÉXIITO DEL PRODUCTO SOFTWARE A DESARROLLAR A continuación se presenta un cuatro donde se establece una vinculación entre los objetivos buscados y los factores de éxito que son necesarios para alcanzar esos objetivos: Objetivo Factor de Éxito Componentes del Factor de Éxito Que los directivos de la institución puedan tomar las mejores decisiones, con respecto a la situación académica de los alumnos 1. Acceder de manera directa a la información, de manera adecuada y en el momento correcto, minimizando el tiempo requerido en recoger la información relevante. 1.1 Contar con una colección de datos en un ambiente integral centralizado donde esté la información de la institución (Data Warehouse). 1.2 Contar con un herramienta que permita al usuario acceder a la colección de datos desde diferentes vistas o perspectivas como si fuera un cubo multidimensional (Servidor OLAP) Optimizar el régimen de promoción de los alumnos 2. Ídem punto Extracción no trivial de información, previamente desconocida y potencialmente útil Contar con un herramienta que permita a un usuario predecir tendencias y comportamientos (Data Mining) Lo expuesto en este cuadro, deberá considerarse como factores de éxito iniciales. En la medida que se avance con el proyecto podrán ir surgiendo nuevos factores y por lo tanto la lista podría ampliarse. Entendemos por Factor de éxito, aquello que debe ocurrir (o debe no ocurrir) para conseguir un objetivo. Entendemos por Componentes del factor de éxito, aquello que se debe hacer para conseguir cada uno de los factores de éxito. Alumno: Carlos Alberto Marí Página: 10 de 21

11 4.. SOLUCIIÓN A IIMPLEMENTAR La solución que se propone es contar con una alternativa tecnología, que deberá contar con un almacén de datos con características especiales de tipo Data Warehouse (DW). Además se hará uso de la tecnología de Explotación de Datos con Sistemas Inteligentes (ED) a fin de poder explorar los grandes volúmenes de datos con el objeto de descubrir patrones y modelos de comportamiento o relaciones entre diferentes variables. Data Warehouse Un DW es una base de datos que contendrá información representando el historial de la institución. Estos datos históricos los utilizaremos para realizar el análisis que apoyen las decisiones de los directivos. Estos datos se encuentran organizados para permitir el análisis más que para procesar transacciones en tiempo real como ocurre en los sistemas de proceso de transacciones en línea (OLTP). Aunque un DW es una base en sí, la diferenciamos en que contendrá resúmenes, consolidaciones y análisis de la interrelación de los datos a través del tiempo. Este DW es una base de datos de tipo read-only creada específicamente para soporte de decisiones. Algunas de las características con la que contaremos al utilizar este tipo de almacén de datos son: Poder combinar datos de orígenes heterogéneos en una única estructura homogénea. Organizar los datos en estructuras simplificadas buscando la eficiencia de las consultas analíticas más que del proceso de transacciones. Contar con datos transformados que son válidos, coherentes, consolidados y con el formato adecuado para realizar el análisis. Proporcionar datos estables que representan el historial de la institución. Actualizar periódicamente con datos adicionales, no con transacciones frecuentes. Simplificar los requisitos de seguridad. Proporcionar una base de datos organizada para el análisis. A continuación se representa gráficamente la solución a utilizar: Alumno: Carlos Alberto Marí Página: 11 de 21

12 Los pasos principales a considerar para la construcción de este sistema serán: Determinar que sistemas transaccionales (OLTP) están asociados al área de negocio seleccionado Definir el origen de los datos operacionales. El modelo de datos fuente Documentar las bases de datos de los sistemas transaccionales Determinar las superposiciones y relaciones entre los sistemas transaccionales Especificar los requerimientos para el soporte a las decisiones Diseñar el DW Crear el área de preparación de datos Crear la base de datos del DW Limpiar y transformar los datos Cargar datos en la base de datos de un DW Preparar información de presentación Explotación de Datos a través de Sistemas Inteligentes Con tanta información disponible en un DW, es muy posible que ocurra lo que un dicho tradicional declara como los árboles no dejan ver el bosque, es decir, que exista dificultad para obtener aquella información que realmente es muy valiosa para la institución. Por esta razón es que se desea hacer uso de la tecnología de ED. Alumno: Carlos Alberto Marí Página: 12 de 21

13 El proceso de ED consistirá de las siguientes fases: Filtrado de datos Selección de variables Extracción de conocimientos Interpretación y evaluación Con estas fases cumplidas y con los patrones obtenidos se buscará realizar predicciones en relación al régimen de promoción de la UAP 4. Como se tiene la sospecha (por ahora) que es considerable la cantidad de asignaturas que se pierden por tiempo y/o por recursar y, que por lo tanto, no se está ayudando con 6 oportunidades para una materia cuatrimestral u 8 oportunidades para rendir un final anual, la utilización de ED permitirá arrojar luz sobre esta área. Es decir, que el supuesto beneficio para el alumno, de permitirles tener varias posibilidades para rendir un examen final y además que pueda contar con tanto tiempo sin llegar a perder la regularidad de la misma, está resultando en un perjuicio para el alumno y no un beneficio. Muchos alumnos terminan recursando la materia con la correspondiente pérdida de tiempo y dinero. A través de las técnica de ED con sistemas inteligentes, se buscará obtener el conocimiento necesario para proveer de elementos concretos, basados en los datos existentes que forman la experiencia ya vivida por la institución, para realizar si fuese necesaria una revisión del Régimen de Promoción de la UAP. 4 El Régimen de Promoción utilizado actualmente fue aprobado por el Consejo Académico de la UAP, el 16 de diciembre de 1999 según Acuerdo Nº 99/67, Acta 167. Alumno: Carlos Alberto Marí Página: 13 de 21

14 5.. RECURSOS Y TECNOLOGÍÍA A UTIILIIZAR Recursos Humanos: El recurso humano utilizado para el desarrollo de este proyecto será, en principio, solo la del tesista. Igualmente se está en la búsqueda de otra persona para que participe apoyando en tareas de programación. Además, al ser un proyecto de interés institucional, se cuenta con el apoyo de los distintos sectores académicos de la Universidad a fin de realizar un estudio apropiado de la problemática de negocio. Base de Datos: La base de datos para uso transaccional que actualmente se utiliza es PostgreSql en su versión 7.4. La estructura del Data Warehouse a desarrollar también se alojará en una base de datos de este tipo. Servidor OLAP: A fin de realizar las consultas multidimensionales utilizando el lenguaje MDX será necesario contar con un servidor OLAP. Para esto la comunidad de software libre provee el producto llamado Mondrian 5, el cual será utilizado en este proyecto. Formateo de Cubos: La sola utilización del lenguaje MDX para la realización de las consultas multidimensionales produce salidas poco legibles por el usuario. Para que dichas salidas sean formateadas de manera más agradables y tenga la posibilidad de realizar la correspondiente navegación por el cubo se hará uso de la herramienta llamada JPIVOT 6, que hace uso de la tecnología Java. Plataforma de Desarrollo: El desarrollo será utilizando la plataforma JSP que utiliza el lenguaje JAVA. Máquina Virtual Java: Para poder trabajar con Java será necesario contar con la Máquina Virtual Java correspondiente al sistema en el cual se hará el desarrollo. En principio se estará trabajando en un estación cliente de tipo Linux utilizando la distribución Mandrake. Servidor Web: Considerando que será un desarrollo hecho en JSP, se utilizará el servidor web Tomcat 7. Minería de Datos: Se ha realizado investigaciones sobre que herramientas utilizar aquí y por el momento se podrá optar por Weka 8 o R 9. Estas dos herramientas pertenecen a proyectos Open Alumno: Carlos Alberto Marí Página: 14 de 21

15 Source, pero no se descarta la posibilidad de ir hacia herramientas propietarias como es el caso de Clementine, correspondiente a la empresa SPSS, o quizás alguna otra Alumno: Carlos Alberto Marí Página: 15 de 21

16 6.. METODOLOGÍÍA A SEGUIIR Dadas las características del sistema a desarrollar y considerando que el mismo corresponde a un software tradicional, se orientará su desarrollo a la especialidad de Ingeniería del Software. La metodología a seguir es una combinación de Métrica Versión 3 y del Proceso Unificado. Métrica Versión 3 Es un instrumento útil para la sistematización de las actividades que dan soporte al ciclo de vida del software dentro del marco que permite alcanzar los siguientes objetivos: Proporcionar o definir sistemas de información que ayuden a conseguir los fines de la organización mediante la definición de un marco estratégico para el desarrollo de los mismos. Dotar a la organización de productos software que satisfagan las necesidades de los usuarios dando una mayor importancia al análisis de requisitos. Mejorar la productividad de los departamentos de Sistemas y Tecnologías de la información y las comunicaciones, permitiendo una mayor capacidad de adaptación a los cambios y teniendo en cuenta la reutilización en la medida de lo posible. Facilitar la comunicación y entendimiento entre los distintos participantes en la producción de software a lo largo del ciclo de vida del proyecto, teniendo en cuenta su papel y responsabilidad, así como las necesidades de todos y cada uno de ellos. Facilitar la operación, mantenimiento y uso de los productos software obtenidos. Proceso Unificado El Proceso Unificado de Desarrollo del Software es un marco de trabajo genérico que puede especializarse en una gran variedad de sistemas software, para diferentes áreas de aplicación, tipos de organizaciones, niveles de aptitud y tamaños de proyectos. El Proceso Unificado está basado en componentes, esto quiere decir que el sistema software en construcción está formado por componentes software interconectados a través de interfaces bien definidas. Utiliza el Lenguaje Unificado de Modelado UML (Unified Modeling Languaje) para preparar todos los esquemas de un sistema software. El Proceso Unificado de Desarrollo se caracteriza por estar guiado por los casos de uso, centrado en la arquitectura y por ser iterativo e incremental: Basado en casos de uso: es una técnica para capturar información de cómo un sistema o negocio trabaja, o de cómo se desea que trabaje. Alumno: Carlos Alberto Marí Página: 16 de 21

17 Centrado en la arquitectura: se centra tanto en los elementos estructurales significativos del sistema, subsistemas, componentes y nodos, como en las colaboraciones que tienen lugar entre estos elementos a través de las interfaces. Los modelos que representan la arquitectura son: modelo de análisis, de diseño, de despliegue, de implementación y de casos de uso. Iterativo e incremental: El ciclo de vida iterativo se basa en la evolución de prototipos ejecutables que se muestran a los usuarios y clientes. En cada iteración va creciendo y se obtienen nuevos requisitos o se modifican los actuales. Combinación de metodologías Se utilizará Métrica V.3 en los flujos de trabajo de soporte y Proceso Unificado para los flujos de trabajo del proceso. El Proceso Unificado no tiene bien definido los flujos de trabajo de soporte, por esta razón se utilizará la combinación con Métrica V.3. El siguiente cuadro muestra los procesos principales que se harán con cada metodología: METODOLOGÍA Proceso Principal Métrica V.3 Proceso Unificado Interface de Gestión del Proyecto Interface de Gestión de la Configuración Interface de Aseguramiento de la Calidad Estudio de Viabilidad del Sistema Captura de Requisitos como Casos de Uso Análisis Diseño Implementación Pruebas Despliegue Alumno: Carlos Alberto Marí Página: 17 de 21

18 7.. PLAN DE TRABAJJO Se presenta a continuación el plan de trabajo a realizarse a partir del 1/11/2004 hasta el 30/04/2005, es decir que este proyecto tendrá una duración de 6 meses. Interface de Gestión del Proyecto Del 1/11/2004 al 14/11/2004 Estimación de esfuerzo 4 días Planificación 6 días Interface de Gestión de la Configuración Definición de los requisitos de gestión de configuración Establecimiento del plan de la gestión de configuración Identificación y registros de productos Registro del cambio en el sistema de gestión de la configuración Del 15/11/2004 al 21/11/ día 1 día 1 día Interface de Aseguramiento de la Calidad Del 22/11/2004 al 5/12/2004 Identificación de las propiedades de calidad Revisión del análisis de consistencia 1 día Revisión de la verificación de la arquitectura del sistema Revisión de las pruebas unitarias, de integración y del 3 días sistema Revisión de las pruebas de aceptación del sistema Estudio de Viabilidad del Sistema Del 6/12/2004 al 20/12/2004 Establecimiento del alcance de sistema 1 día Estudio de la situación actual 1 día Definición de requisitos del sistema Estudio de alternativas de solución 4 días Valoración de las alternativas 1 día Selección de la solución 1 día Captura de Requisitos como Casos de Uso Del 21/12/2004 al 3/1/2005 Determinar los requisitos de construcción 4 días Encontrar Actores y casos de uso 1 día Priorizar casos de uso 1 día Detallar casos de uso 4 días Análisis Del 4/1/2005 al 19/1/2005 Analizar la arquitectura Analizar casos de uso 4 días Analizar las clases 4 días Alumno: Carlos Alberto Marí Página: 18 de 21

19 Diseño Del 20/1/2005 al 2/2/2005 Diseñar la arquitectura Diseñar casos de uso 3 días Diseñar las clases 3 días Describir modelo de datos Implementación Del 3/2/2005 al 15/3/2005 Implementar la Arquitectura 30 días Pruebas Del 18/3/2005 al 29/3/2005 Planificar la prueba Diseñar la prueba Realizar la prueba 4 días Evaluar la prueba Otras Actividades Del 1/4/2004 al 30/4/2004 Escribir el manual de usuario 6 días Escribir el glosario general 1 días Realizar correcciones 15 días Junto a este documento se adjunta la gráfica de Gantt en archivo de Microsoft Proyect. Alumno: Carlos Alberto Marí Página: 19 de 21

20 8.. BIIBLIIOGRAFÍÍA Libros: Harjinder S. Gill y Prakash C. Rao, Data Warehousing, la integración de información para la mejor toma de decisiones, Prentice Hall, 1996 Jean-Michel Franco y EDS-Instituc Prométhéus, El Data Warehouse, El Data Minning, Ediciones Gestión 2000, 1997 Jiawei Han y Micheline Kamber, Data Mining: Concepts and Techniques, Morgan Kaufmann Publishers, Robert Groth, Data Mining: A Hands-On Approach for Business Professionals, Prentice Hall PTR, 1998 Jill Dyché, E-data, Transformando datos en información con Data WareHousing, Prentice Hall, 2001 Papers: A Survey on Logical Models for OLAP Databases. Autores: Panos Vassiliadis, Timos Sellis. Providing OLAP (on-line analytical processing) to user-analysts: An IT mandate. Technical report, Autores. E.F. Codd, S.B. Codd, C.T. Salley Maintenance of Data Cubes and Summary Tables in a Warehouse. Autores: I. Mumick, D.Quass, B.Mumick. ftp://db.stanford.edu/pub/papers/cube-maint-sigmod.ps Implementing Data Cubes Efficiently. Autores: Harinarayan, Rajaraman, Ullman ftp://db.stanford.edu/pub/papers/cube.ps On the Computation of Multidimensional Aggregates. Autores: S. Agarwal, R. Agrawal, P.M. Deshpande, A. Gupta, J.F. Naughton, R. Ramakrishnan, S. Sarawagi. Proc. VLDB '96, Data Warehouse Quality Design: A Review of the DWQ Project. Autores: M. Jarke, Y. Vassiliou. Towards Quality -Oriented Data Warehouse Usage and Evolution. Autores: Vassiliadis y otros Data Integration : a Theoretical Perspective. Autor: M. Lenzerini Alumno: Carlos Alberto Marí Página: 20 de 21

21 Artículos: Artículos de Ralph Kimball de Intelligent Enterprise An Overview of Data Warehousing and OLAP Technology, Surajit Chaudhuri, Umesh Dayal,ACM SIGMOD Record 26(1), Marzo Links varios: Data Warehouse: funcionalidad y servicios. Data Warehousing and OLAP The Data Warehousing Information Center Data Warehousing Online. Tutorial Data WareHousing Alumno: Carlos Alberto Marí Página: 21 de 21