Tesis Pregrado
Tesis Pregrado
Tesis Pregrado
en la Planeación y Seguimiento de
Proyectos de Inteligencia de Negocios
Página 2 de 39
8.4.3. Tiempo por Dimensiones Compartidas......................................................18
8.5. Registros dotProject vs. Planeación inicial. .......................................................18
9. Propuesta de la nueva metodología del proceso de planeación y seguimiento..........21
9.1. Descripción ........................................................................................................21
9.1.1. Fase ............................................................................................................21
9.1.2. Ciclo ...........................................................................................................21
9.1.3. Frente de trabajo.........................................................................................21
9.1.4. Tipos de tarea.............................................................................................22
9.1.5. Semana .......................................................................................................22
9.2. M etodología del nuevo esquema de planeación ................................................23
9.2.1. Etapa 1 Planeación global ..........................................................................23
9.2.2. Etapa 2 Re-planeación ...............................................................................23
9.2.3. Etapa 3 Seguimiento del proyecto.............................................................23
9.2.4. Etapa 4 Recopilación de datos para Postmortem.......................................24
9.2.5. Etapa 5 Revisión y mejoramiento ..............................................................24
10. Conclusiones ..........................................................................................................25
11. Trabajos futuros .....................................................................................................26
12. Bibliografía. ...........................................................................................................27
13. Anexo No 1. M atriz de actividades BI...................................................................28
14. Anexo No 2. Levantamiento de Riesgos en Proyectos de Inteligencia de Negocios.
31
14.1. Valoración de ries gos.....................................................................................31
14.2. Valoración de ries gos según Impacto y Probabilidad de ocurrencia. ............33
14.3. Planes de mitigación propuestos....................................................................34
14.3.1. Riesgos Funcionales:..................................................................................34
15. Anexo 3 Relación de actividades Nomenclatura vieja incompleta vs. Nueva
nomenclatura......................................................................................................................35
16. Anexo 4 Consulta SQL para obtener tiempos de actividades................................37
17. Anexo 5 Tiempos por Actividad y Tipo de Actividad...........................................38
Página 3 de 39
2. Introducción
Changeset es un proyecto de desarrollo de softw are realizado por el grupo Qualdev de
la Universidad de los Andes. El proyecto tiene como fin implementar softw are y
procesos de apoyo a la ingeniería de softw are, utilizando tecnología de punta y
realizando un proceso de desarrollo con énfasis en calidad.
Una de las labores realizadas por Qualdev, es el trabajo con empresas de desarrollo de
softw are colombianas donde exista la necesidad de mejorar sus procesos internos.
Página 4 de 39
3. Objetivos
Los principales objetivos planteados en el desarrollo del trabajo desempeñado en la
empresa y sugeridos por la gerencia de proyectos, en particular para el proyecto de
inteligencia de negocios, fueron los siguientes:
Si bien, en un principio se quería seguir con otro proceso de ingeniería de softw are en la
empresa, en particular con el de administración de conocimiento, la gerencia de
proyectos recomendó seguir con en el tema que se inició el semestre pasado, es decir,
la planeación y el seguimiento de actividades. Esto, se debe a que la empresa tiene
ánimos de formalizar este proceso, en particular, para los proyectos de inteligencia de
negocios. A corto plazo se desea que este sea un ejemplo para los futuros proyectos.
Página 5 de 39
4. Marco Teórico General
El trabajo llevado a cabo en la empresa tuvo un marco general que rodeó las
actividades. Este marco es similar al usado durante el primer semestre de 2005 [1] por
el equipo que trabajó con las empresas en aquel momento.
Se debe comprender que este mejoramiento no llegará a darse sin los suficientes
esfuerzos por parte de todas las personas involucradas, tanto en el proceso por mejorar,
como en el plan de mejoramiento global. Significa un compromiso constante con el
trabajo emprendido por parte de todos los miembros del equipo.
De la misma manera hay que tener en cuenta, que el mejoramiento de un proceso debe
darse poco a poco sin intentar cubrir todas las fases del mismo en un solo paso, sino
que por el contrario, se deben desarrollar estrategias que permitan manejar
progresivamente las diferentes fases del proceso. En particular, se retomará la
planeación y el seguimiento de actividades. También es importante anotar que incurrir
en el esfuerzo del mejoramiento de un proceso, no significa directamente hacer el
esfuerzo por implementar una herramienta como dotProject o los scripts con los cuales
se hace la carga de las actividades o reportes, sino que ésta puede llegar a ser parte de
la solución.
El modelo IDEAL es llamado de esta manera, por las diferentes fases de trabajo que
involucra: Initiating, Diagnosis, Establishing, Acting y Leverage (Inicialización,
Diagnóstico, Establecimiento, Ejecución y Aprendizaje). Cada una de estas fases
consiste de diferentes actividades o pasos por desarrollar. El modelo está diseñado
como un modelo cíclico, en el cuál una vez se han terminado de ejecutar las diferentes
actividades que éste involucra, se debe volver a iniciar el ciclo de mejoramiento,
llevando a cabo las mismas actividades pero definiendo nuevos objetivos para el ciclo
que comienza. En efecto, en el tiempo trabajado se estableció un nuevo ciclo en la
empresa puesto que se aprovecharon las experiencias aprendidas para retomar la
inicialización de éste.
A continuación se hace una breve referencia de las cinco fases de éste modelo [2]:
Página 6 de 39
4.2.1. Fase de Inicialización
En la fase de Inicialización (Initiating) se identifica la necesidad general para ser tenida
en cuenta dentro del plan de mejoramiento; tiene por lo tanto como entrada, el estímulo
al cambio de mejoramiento por parte de la organización dueña del proceso. Una vez se
tiene identificada esta necesidad de mejora, la gerencia de la organización fija el
contexto para el trabajo que será realizado, identificando en qué áreas de la
organización serán concentrados los esfuerzos y qué puntos de la estrategia de negocio
se quieren llegar a mejorar.
Página 7 de 39
4.3. Modificaciones al la implementación del modelo IDEAL.
En vista que el modelo IDEAL implementado en el trabajo con las empresas durante el
primer semestre del 2005 careció de algunos elementos para que fuera más formal, en
éste se decidió incluir plantillas para plasmar la información y las experiencias obtenidas
en las empresas en un repositorio central de información en Qualdev. [3].
Página 8 de 39
5. Proyectos de inteligencia de negocios
• Análisis multidimensional
• Minería de datos
• Predicciones de comportamiento
• Análisis de negocios
• Preparación para el Balanced Scorecard (Herramienta de evaluación de
desempeño)
• Visualización de reportes
• Búsqueda de datos
Para avanzar sin tropiezos a lo largo de éste documento es recomendable tener claros
ciertos conceptos que son inherentes a los proyectos de inteligencia de negocios. Por
obvias razones no se enuncian todos los términos que implican la inteligencia de
negocios sino los más relevantes para el desarrollo de este documento:
5.2.1. Reporte
Consiste en la abstracción de la información extraída de los datos del cliente que tiene
valor agregado para un área de la empresa en la medida que se agiliza el proceso de
Página 9 de 39
toma de decisiones. Realizar un reporte implica que se deben tener entrevistas con el
cliente para saber qué información quiere ver y cómo quiere verla, hacer un diseño de
éste, la implementación, su inspección y pruebas de visualización.
5.2.2. Estrella
Es el modelo de datos por medio del cual se representa una tabla de hecho (Fact) por el
cual se obtiene un amplio rango de datos qué en suma con los reportes dan valor
agregado a una organización. Una tabla de hecho (Fact) se define como la situación en
el tiempo que representa un hecho crítico para la empresa como lo es una venta, una
transacción, un reclamo, etc.
Para mayor claridad en la Figura 1 se muestra una estrella que representa la venta de
un producto de una empresa en la que se tiene en cuenta el momento (tiempo) en el
que se realizó, el producto vendido, la tienda y el cliente.
En la Figura 2 se aprecia un cubo con sus valores (sumatorias) luego de cruzar tres
dimensiones de ventas de una empresa: color, tamaño y nombre del ítem:
Página 10 de 39
Figura 2: Cubo en el que se cruzan las dimensiones color, nombre y tamaño de ítem.
5.2.5. OLAP
Sigla de Online Analytical Processing. Consiste en el análisis interactivo de datos, el
cual permite que los datos sean resumidos y desplegados en diversas maneras de
forma online, es decir adquiriendo la información directamente de la base de datos.
5.3. Desarrollo
1. Definición de Reportes
2. Definición de Datamarts y diseño de estrellas
3. Implementación de Estrellas
4. Definición e implementación de cubos y dimensiones
5. Implementación de Reportes
6. Definición y diseño del módulo de carga de datos
7. Implementación del módulo de carga de datos
8. Verificación de calidad y consistencia de datos
9. Documentación
10. Riesgos e imprevistos
La anterior lista no implica que los pasos tengan que desempeñarse de manera
secuencial, pueden efectuarse en paralelo. De hecho la documentación es un paso que
se debe hacer desde el principio hasta el final del proyecto.
Página 11 de 39
6. Antecedentes
Durante el primer semestre de 2005 se hizo una primera aproximación del trabajo de
Qualdev en la empresa. En aquella oportunidad se dejó planteado un proceso de
planeación y seguimiento para los proyectos que se estaban ejecutando, entre los
cuales se contaba el de inteligencia de negocios, en éste se realizaron las siguientes
actividades: Clasificación de los tipos de actividades, identificación de las fases y
artefactos por requerimiento y construcción de históricos iniciales. Esto se refleja en el
Anexo No 1. Matriz de actividades BI.
6.1.1. Reportes
Este tipo de actividad hace referencia a las tareas para definir y desarrollar los reportes
6.1.2. Estrellas
Son las actividades para definir los modelos de datos por medio de los cuales se
obtendrán posteriormente los reportes.
Se caracterizaron las actividades necesarias por fase, la unidad de medida por actividad
y grado de complejidad (horas). Se hizo un discriminado dependiendo del tipo de
desarrollador que entraría al proyecto (Junior y Experto) y la complejidad de la actividad
(Sencillo, promedio y complejo).
Página 12 de 39
6.3. Construcción de históricos iniciales por actividad
7. Situación actual.
A continuación se describe las condiciones del proyecto de inteligencia de negocios en
lo que refiere a su proceso de planeación, las fallas encontradas en el proceso de
seguimiento, y por último, los riesgos que afrontó el proyecto.
Por ejemplo, para Reportes se tienen actividades como las entrevistas que se llevaron a
cabo con las personas de la empresa cliente, las tareas para hacer el documento en el
que se plasma el conocimiento del negocio y el diseño del módulo de reportes.
Página 13 de 39
Desafortunadamente no se pudo tener acceso a última planeación del proyecto, ya que
ésta residía en las oficinas del cliente y la empresa no contaba con un archivo de
backup. Esta es la razón por la cual los comparativos de tiempo de planeado vs. el
tiempo real se hizo con respecto a estos dos registros de planeaciones.
1. 7 Estrellas
2. 3 Reportes
3. 30 Dimensiones Compartidas
Figura 3: Actividades que se repiten tantas veces como estrellas hay que desarrollar.
Las otras actividades del tipo Estrella se hacen una sola vez en el proyecto (bajo
condiciones ideales).
En el caso de reportes las actividades que se repiten son las siguientes (Figura 4):
Figura 4: Actividades que se repiten tantas veces como reportes hay que desarrollar.
Por último para las actividades de dimensiones compartidas solo hay una tarea que se
repite tantas veces como dimensiones tenga (Figura 5):
Página 14 de 39
4.1.Elaboración de una dimensión compartida
Figura 5: Actividades que se repiten tantas veces como dimensiones compartidas hay que desarrollar.
Por otro lado, los reportes propuestos no ofrecieron el valor agregado que la
organización estaba buscando. Esto ocurrió en virtud a que los mismos estaban
diseñados para que funcionara cómo se registraban las tareas en Qualdev. En el grupo
de desarrollo de la universidad cada semana se hacía un proyecto nuevo en dotProject
y a su vez un conjunto de proyectos conformaba un ciclo de desarrollo. Sin embargo, en
la empresa se tomo un solo ciclo de desarrollo en el que se tenía un solo proyecto para
todas las semanas que implicaban. Ver Figura 6.
Qualdev Empresa
Proyecto 1 Semana 1 Proyecto 1 Semana 1
Proyecto 2 Semana 2 Semana 2
Proyecto 3 Semana 3 Semana 3
Proyecto 4 Semana 4 Semana 4
Figura 6: Comparativo entre los esquemas de ciclos de planeación Q ualdev vs. Empresa
Cuando se quería sacar un reporte en Qualdev se hacía tan pronto como terminaba el
ciclo, pero en la empresa se requería sacar un reporte en cualquier momento del
proyecto (Vg. Para ver su valor ganado en un momento cualquiera). Infortunadamente,
éste esquema de registrar los proyectos no le funciono a la empresa para hacer una
síntesis de sus avances en un proyecto de inteligencia de negocios.
A pesar que el manejo de riesgos estaba por fuera del alcance de los objetivos trazados
para éste proyecto inicialmente, luego de reuniones con las ingenieras a cargo del
mismo se concluyó que hacer un corto levantamiento de riesgos, sin ser exhaustivo,
aclararía un poco mas el panorama al que se iban a enfrentar los integrantes en
proyectos similares a éste. Ver Anexo No 2. Levantamiento de Riesgos en Proyectos de
Inteligencia de Negocios.
Página 15 de 39
8. Análisis de datos
A continuación se describe la forma en la cual se capturaron los datos del proyecto de
inteligencia de negocios y luego se depuraron y analizaron para calcular los tiempos
invertidos por actividad y tipo de actividad. Las fuentes básicamente fueron las
planeaciones detalladas del proyecto, y los logs de las actividades registradas en la
herramienta de seguimiento dotProject.
Esta tarea se hizo con los registros de dotProject del 11 de julio al 15 de diciembre de
2005.
La primera recomendación fue tomar los tipos de actividades registrados por última vez
en dotProject y poner sus nombres en un formato único de forma que éste nos sirva
como base para la comparación con las planeaciones anteriores y futuras de otros
proyectos.
En vista que los registros de los avances de las actividades en la herramienta dotProject
se comenzaron a incluir un poco antes de poner en práctica las reglas de nomenclatura,
hubo tareas que no guardaron el estándar y mas tarde en la comparación y correlación
de los datos ésta resultaría muy difícil de entender.
Es por ésto que una de las tareas realizadas en conjunto con la ingeniera encargada de
la empresa fue normalizar ésta lista de actividades definitiva. De las 78 actividades
registradas, 43 tuvieron la nomenclatura adecuada, las restantes 35 no. Ver Anexo 3
Relación de actividades Nomenclatura vieja incompleta vs. nueva nomenclatura.
Tan pronto como la nomenclatura de las actividades quedó con un estándar apropiado,
estuvimos en capacidad de saber en realidad cuánto se gastó por actividad y por tipo de
actividad en el proyecto. Entiéndase “tipo de actividad” como la agregación de tareas
comunes. Para obtener los tiempos de cada actividad (y su tipo de actividad) se ejecutó
una consulta SQL, la sumatoria de éstas para mayor flexibilidad se realizaron en Excel
®. Ver anexo 4 Consulta SQL para obtener tiempos de actividades.
En la figura 7 se muestran los resultados luego de realizar las sumatorias parciales para
cada uno de los tipos de actividad.
Página 16 de 39
Se puede apreciar que el tipo de actividad que más tiempo toma es Estrellas. Se puede
inferir a priori que esto fue debido a que se gasto mucho tiempo en las tareas de Prueba
y Verificación de los datos. Ver anexo 5 Tiempos por Actividad y Tipo de Actividad.
Con ésto corroboramos que debido a las actividades de Prueba y Cargue de datos el
proyecto tuvo la mayor inversión de tiempo.
Hay que tener cuidado en no tomar el tiempo completo del tipo de actividad ya que éste
tienen actividades que sólo se ejecutan una sola vez en el proyecto. Solo hay que tomar
las actividades que son inherentes a un solo ítem
Las tareas que implican el desarrollo de una sola estrella son las siguientes:
Página 17 de 39
• 2.18.Verificación de datos por estrella.
• 2.19.Corrección pruebas por estrella.
Entonces lo que se debe hacer es filtrar los tiempos de éstas actividades, hacer la
sumatoria y dividirlo por el número de estrellas desarrolladas en el proyecto (7). Esto
nos da un tiempo de 72.6 horas para cada estrella en promedio.
En vista que los registros en dotProject empezaron después del inicio del proyecto hubo
actividades que no tuvieron el formato adecuado. El primer paso para que se pudiera
hacer una comparación de los registros ingresados en la planeación inicial vs. los
registros que se capturaron por medio de dotProject fue normalizar la forma como se
denominan las actividades y sus registros.
Lo primero que hay que tener en cuenta es que las ventanas de tiempo de la planeación
inicial y lo registrado en dotProject son distintas.
Página 18 de 39
La primera planeación se extiende desde el 17 de abril hasta el 11 de julio de 2005 con
lo cual nos da 68 días hábiles planeados. Por otro lado los registros de dotProject datan
desde el 3 de mayo al 12 de diciembre lo cual son 159 días hábiles reales. Ver Figura 9.
Horas
Primera planeación 964
Resgistro DotProject 977,53
Página 19 de 39
Horas
1200
1000
800
600 Horas
400
200
0
Primera planeación Resgist ro Dot Project
Horas
Primera planeación 705
Registro DotProject 977,53
Ho ras
12 0 0
10 0 0
800
600 Ho ras
400
200
0
Primera pl aneació n R esgi stro Do tPro ject
Página 20 de 39
9. Propuesta de la nueva metodología del proceso de
planeación y seguimiento
9.1. Descripción
Luego de analizar los datos de los registros de las actividades hechas en el proyecto de
inteligencia de negocios se propone el siguiente esquema. Este se hace con base en el
elaborado en Qualdev en el segundo semestre de 2005 [5].
Lo que se busca es que el registro de las tareas de los tipos de actividades sirva de
manera más eficiente para mostrar los avances del proyecto y que la información
consignada ayude a calcular mejor los costos de las actividades para proyectos de la
misma índole en el futuro.
9.1.1. Fase
Esta comprende todas las fases que estén especificadas en una iteración del proyecto
de Inteligencia de Negocios:
1. Definición de Reportes
2. Definición de Datamarts y diseño de estrellas
3. Implementación de Estrellas
4. Definición e implementación de cubos y dimensiones
5. Implementación de Reportes
6. Definición y diseño del módulo de carga de datos
7. Implementación del módulo de carga de datos
8. Verificación de calidad y consistencia de datos
9. Documentación
10. Riesgos e imprevistos
9.1.2. Ciclo
El ciclo es el conjunto de fases que se definen que se pueden repetir a lo largo del
avance del proyecto. Este podría tener un valor numérico (ciclo 1, ciclo 2, etc.).
Los frentes de trabajo son los conjuntos de tareas que se deben realizar dentro de un
ciclo, éstos deben ser en lo posible suficientemente granulados para obtener
retroalimentación de ésta división, pero lo suficientemente grandes como para lograr
realizar una planeación global de principio a fin en donde la unidad de medida sean los
ciclos. Estos necesitan tener un estimativo de tiempo en horas para su desarrollo.
Página 21 de 39
Los frentes de trabajo establecidos para un proyecto de inteligencia de negocios (luego
del análisis) son los siguientes:
1. Reportes
2. Estrellas
3. Dimensiones Compartidas
4. Actividades de soporte
5. Planeación y seguimiento
Se entiende un tipo de tarea como una actividad que puede ser común para uno o más
fases en los ciclos, por ejemplo, algunos tipos de tarea definidos actualmente en el
proyecto de inteligencia de negocios son:
9.1.4.1.Para reportes:
• Entrevista Conocimiento del Negocio
• Documentación del Conocimiento del Negocio
• Priorización de reportes
• Documentación de Priorización de Reportes
• Corrección Documento reportes
• Definición de estándares de visualización
9.1.4.2.Para Estrellas:
• Definición políticas de homologación y extracción
• Diseño del tratamiento de llaves subrogadas
• Diseño de procesos de transformación
• Diseño de la carga de dimensiones
9.1.5. Semana
Página 22 de 39
La semana se toma como el número de la semana dentro de un ciclo determinado, por
ejemplo semana 1 del ciclo es semana 1, y así sucesivamente.
Para cada uno de los frentes de trabajo se define un nombre, una descripción y un
tiempo estimado. La sumatoria de los tiempos estimados debe ser igual a la sumatoria
del mismo tiempo disponible para desarrollo de todos los integrantes del grupo más un
colchón de tiempo.
Cuando se programe se hace una re-planeación de tareas para el ciclo, éstas tareas
deben tener un nombre descriptivo, estar relacionadas con la semana, con el frente de
trabajo, con un requerimiento (En cado de estar relacionada a un requerimiento, es
necesario crear 1 tarea por requerimiento), tener una fecha inicial, fecha final y un
tiempo estimado.
La sumatoria de todos los tiempos de las tareas debe ser igual a la sumatoria del tiempo
disponible de todos los integrantes en ese ciclo.
Con el fin de llevar un ciclo ordenado y dentro de los límites especificados de tiempo
para cada integrante, es necesario que el líder de planeación haga una revisión del
estado del proyecto previamente a la reunión semanal. Para este propósito, dotProject
cuenta con algunos reportes especificados, pero también se cuenta con reportes
desarrollados por el. Los reportes que pueden ser útiles para llevar a cabo un
seguimiento rápido del grupo son los siguientes:
Página 23 de 39
• Tareas por semana - Muestra el progreso de las tareas de cada semana y su
responsable
• Tiempo por requerimiento - Tiempo que se ha invertido a cada requerimiento en
desarrollo
• Tiempo por semana - Tiempo por semana que se ha invertido en el proyecto
• User Performance - Para ubicar dentro de un rango de fecha el trabajo de cada
integrante
Una vez terminado el ciclo, los datos reales deben ser comparados con los datos
planeados, los reportes más útiles son los siguientes:
• Tiempo por tipo de tarea - Tiempo por tipo de tarea que se ha invertido en el
proyecto
• Tiempo por fase - Tiempo por fase que se ha invertido en el proyecto
• También sirven los reportes anteriores por semana que muestran el consolidado
del ciclo. La recopilación de datos para el postmortem es útil pues permite tener
una visión global de los resultados del ciclo para realizar una mejor planeación
para el ciclo siguiente. Esto sin embargo, solo es posible si se hizo una
planeación durante todo el ciclo lo mejor posible y con los datos más cercanos a
la realidad.
En ésta etapa se realiza una revisión de las definiciones del proceso, se analizan los
resultados obtenidos y con base a esto se redefinen los elementos del proceso, etapas
o requerimientos. Se pueden definir nuevos elementos en caso de ser necesario.
Esto con el fin de hacer el proceso más dinámico, y acorde a las necesidades del grupo
de trabajo especifico.
Página 24 de 39
10. Conclusiones
• Gran parte de los éxitos o fracasos de los proyectos de desarrollo son atribuidos
a los procesos de planeación y seguimiento. Este debe estar claramente
definido, pero debe construirse de tal manera que tenga en cuenta los cambios
que se pueden presentar en cualquier momento a lo largo del proyecto, las
recomendaciones dadas en éste documento ayudan a una organización para
establecer estos dos procesos en proyectos de inteligencia de negocios.
• En los proyectos de inteligencia de negocios a diferencia de un proyecto normal
de desarrollo de softw are, existe una alta demanda de tiempo en las tareas que
implican el cargue y prueba de los datos. Los tiempos de cargue de datos y
prueba equivalen a mas del 20% del total del tiempo de Inteligencia de negocios.
Esto es evidencia de los constantes tropiezos tanto técnicos como funcionales
en los que eventualmente un proyecto de esta índole se puede incurrir. Un
primer levantamiento de riesgos y sus planes de mitigación se dejó planteado
pero, para que este tenga relevancia en el desarrollo de proyectos de
Inteligencia de Negocios es necesario invertir tiempo y esfuerzo para refinarlo y
que sirva para reducir los tiempos.
• Si bien, hubo inconvenientes en el análisis de los datos, como lo fue la
divergencia en la nomenclatura de las tareas y las distintas ventanas de tiempo
de planeaciones de registro de tareas, se dejó planteado un esquema mas
aproximado a las tareas que implican la Inteligencia de Negocios y la manera de
cómo se deberían registrar los avances en cada uno de los frentes de trabajo.
Esto proporcionará las herramientas para realizar una estimación cada vez más
cercana de los tiempos y con la suma de otras variables, el costo monetario de
las tareas. Sin embargo, es necesario que las personas que continúen con esta
tarea conozcan mas afondo este tipo de proyectos y se planteen metodologías
mas aproximadas para este costeo.
• Existió un grado de formalidad más alto con respecto a la metodología iniciada
durante el primer semestre de 2005. Por medio de las plantillas de seguimiento
periódicas enmarcadas en el modelo IDEAL, el proceso de recopilación de la
información al final del trabajo fue más rápida y sencilla. La información se
organizó por las diferentes fases del modelo y se especificó qué entregables se
debían tener para cada una de estas. Este es uno de los puntos que se deben
tener en cuenta para continuar en los procesos con las empresas en los
semestres siguientes. Con una metodología mas refinada se pueden lograr
mejores históricos, en este trabajo se están recogiendo los frutos de lo hecho en
el primer semestre de 2005. Se espera que para el 2006 las situaciones mejoren
aun más.
• Las experiencias aquí recopiladas enriquecerán el proceso de Ingeniería de
Softw are en Qualdev y la empresa. El trabajo conjunto entre la academia y la
empresa se complementa haciendo que la universidad tenga un laboratorio real
sin que esto signifique que no sea formal y se haga con el mayor interés y
profesionalismo. Para la empresa es la oportunidad de traer la teoría y el
entusiasmo de los estudiantes por probarse en un ambiente real.
Página 25 de 39
11. Trabajos futuros
Por último, tentativamente en la empresa se puede seguir con algún otro proceso de la
ingeniería de softw are. Administración del conocimiento o de riesgos podrían se algunos
de los que se podrían adelantar en etapas futuras.
Página 26 de 39
12. Bibliografía.
• [1] Rincón, Camilo, Rodríguez Sergio. MEJORAMIENTO DEL PROCESO DE
PLANEACIÓN Y SEGUIMIENTO DE PROYECTOS DE DESARROLLO DE
SOFTWARE EN PEQUEÑAS EMPRESAS. Junio 2005. Universidad de los
andes
• [2] The IDEAL Model: A Practical Guide for Improvement. Jennifer Gremba,
Chuck Myers. Artículo publicado en Bridge, publicación del Softw are
Engineering Institute (SEI), 1997. http://w w w .sei.cmu.edu/ideal/ideal.bridge.html.
Recuperado el 10 de diciembre de 2005.
• [4] Larissa T. Moss, Shaku Atre. Business Intelligence Roadmap: The Complete
Project Lifecycle for Decision-Support Applications. Publisher : Addison Wesley.
Pub Date : February 28, 2003, ISBN : 0-201-78420-3, Pages : 576
Página 27 de 39
13. Anexo No 1. Matriz de actividades BI.
Sencillo Promedio Complejo
TIPO ACTIVIDAD ACTIVIDAD ENTREGABLE
Junior Experto Junior Experto Junior Experto
REPORTES(1) 1.1.Entrevista Conocimiento del Negocio Documento del Conocimiento del Negocio 3 3 3 3 3 3
1.22.Documentación del Conocimiento del Negocio Documento del Conocimiento del Negocio 1 1 1 1 1 1
1.2.Priorización de reportes Documento de Priorización de Reportes 0,6 0,5 0,6 0,5 0,6 0,5
1.23.Documentación de Priorización de Reportes Documento de Priorización de Reportes 0,3 0,3 0,3 0,3 0,3 0,3
1.3.Corrección Documento reportes Acta de Aprobación 2 2 3 3 6 6
1.4.Definición de estándares de visualización Documento de los estándares de visualización 0,5 0,5 0,75 0,75 1 1
1.24.Documentación de los estándares de visualización Documento de los estándares de visualización 0,5 0,5 0,5 0,5 0,5 0,5
1.5.inspección estándares visualización Formato de inspección 0,25 0,25 0,3 0,3 0,4 0,4
Diseño de autenticación Documento de autenticación
1.25.Documentación de autenticación Documento de autenticación 1 1 1 1 1 1
1.6.Definición de usuarios y perfiles 1 1 1,5 1,5 2 2
1.7.Estudio de mecanismos de autenticación 1 0,5 1 1 1 1
1.8.Diseño de mecanismos de autenticación 2 1,5 2 1 2 1
1.9.Inspección diseño de Autenticación Acta de Aprobación 0,25 0,25 0,25 0,25 0,5 0,5
1.10.Implementación de estándares de visualización 2 2 3 3 5 5
Implementación de Autenticación
1.11.Implementación de usuarios y perfiles definidos 1 1 1 1 1 1
1.12.Integración de usuarios y perfiles a mecanismos de
autenticación 3 2 4 3 6 5
1.13.Pruebas de Autenticación Acta de Aprobación 0,5 0,5 0,5 0,5 0,8 0,8
1.26.Documentación de identificación de reportes Documento de identificación de reportes 1 1 1 1 1 1
1.14.Entrevista Individual Identificación de Reportes Documento de identificación de Reportes 0,25 0,25 0,35 0,35 0,5 0,5
1.15.Entrevista Conjunta Identificación de Reportes Documento de identificación de Reportes 1 1 1,5 1,5 3 3
1.16.Inspección Documento Reportes por reporte Formato de inspección 0,1 0,05 0,1 0,05 0,15 0,1
1.17.Implementación de un reporte 0,5 0,2 0,7 0,3 2 1
1.18.inspección Implementación por reporte Formato de inspección 0,3 0,2 0,4 0,3 0,4 0,3
1.19.Correcciones inspección Implementación por reporte 0,5 0,2 0,7 0,3 2 1
1.20.Pruebas de Visualización de un reporte Acta de Aprobación 0,25 0,25 0,25 0,25 0,35 0,35
1.21.Pruebas de Consistencia de datos para un reporte Acta de Aprobación 0,1 0,1 0,2 0,2 0,3 0,3
Página 29 de 39
3.3.Capacitación Mondrian Administración 1 sesión Documento de Aprobación 0,3 0,3 0,3 0,3 0,3 0,3
3.4.Capacitación Usuario Final 1 sesión Documento de Aprobación 0,25 0,25 0,25 0,25 0,25 0,25
3.5.Elaboración Manual de Instalación Manual de Instalación 0,5 0,5 0,5 0,5 0,5 0,5
3.6.Elaboración Manual de Usuario Manual de Usuario 1 1 1 1 2 2
3.7.Elaboración Manual de Administrador Manual de Administrador 2 2 2 2 4 3
3.8.Elaboración Manual técnico Manual técnico 1 1 1 1 1 1
3.9.Reunión de Seguimiento Acta 0,2 0,2 0,2 0,2 0,2 0,2
DIMENSIONES
COMPARTIDAS(4) 4.2. Documentación de dimensiones compartidas Documento Cubos en Xml 0,7 0,7 0,7 0,7 0,7 0,7
4.1.Elaboración de una dimensión compartida 0,2 0,1 0,3 0,1 0,5 0,2
Página 30 de 39
14. Anexo No 2. Levantamiento de Riesgos en
Proyectos de Inteligencia de Negocios.
Fecha: 25 de Octubre de 2005
Se hizo una valoración de los riesgos existentes en este momento. Se dividieron según si los
riesgos encontrados son de índole funcional o técnica.
Riesgos Funcionales
Id Nombre del riesgo Descripción del Riesgo Probabilidad Impacto en
Riesgo de ocurrencia. el proyecto
Riesgos Técnicos
Id Nombre del riesgo Descripción del Riesgo Probabilidad Impacto en el
Riesgo de ocurrencia. proyecto
Página 32 de 39
14.2. Valoración de riesgos según Impacto y Probabilidad de
ocurrencia.
Para establecer sobre que planes hacer un plan de mitigación y seguimiento, entoncesse toman
los riesgos que estén en los cuadrantes (Según probabilidad e Impacto) Media/Alto, Alta/Medio y
Alta/Alto.
Riesgos Funcionales.
Impacto \ Probabilidad Baja Media Alta
1,2 3,4 5
Bajo F_6 F_4
1,2 F_5
Medio F_7
3,4
Alto F_1 F_3
5 F_2
F_8
Entonces, los riesgos funcionales sobre los que se hará plan de mitigación serán F_1, F_2, F_3 y
F_8.
Riesgos Técnicos
Impacto \ Probabilidad Baja Media Alta
1,2 3,4 5
Bajo
1,2
Alto T_2
5
En éste caso no hay riesgos en los cuadrantes (Según probabilidad e Impacto) Media/Alto,
Alta/Medio y Alta/Alto, entonces se hará plan de mitigación sobre T_1 únicamente.
Nota: Por el momento se harán los planes sobre los riesgos que más impacten sobre la
organización. Lo ideal es que se haga plan sobre todos los riesgos, esto queda a discreción de la
empresa.
Página 33 de 39
14.3. Planes de mitigación propuestos.
14.3.1.Riesgos Funcionales:
Riesgos Funcionales
Id Nombre del riesgo Plan de mitigación.
Riesgo
F_1 Ausencia de usuarios En estos dos riesgos lo que se propone es que desde el
funcionales comienzo del proyecto se fijen roles y responsabilidades. No
F_2 Poca disponibilidad de solo por parte del proveedor (la empresa), sino por parte del
tiempo de los usuarios cliente. Ahora, si éste riesgo se materializa, lo ideal es que
funcionales. presente ante el jefe, coordinador o líder un acta que contenga
las actividades pendientes con base en lo que haga falta del
proyecto. En ésta acta es aconsejable incluir:
1. Descripción.
2. Tiempo de entrega.
3. Responsable(s). Por parte de cliente y la empresa.
4. Firmas de los responsables si aplica.
F_3 Dificultad de Delegar un responsable tanto de la parte del cliente, así como
procesamiento de también de la empresa, para que se haga un levantamiento de
información externa. las dificultades de procesamiento y establezcan una acción
sobre éstas.
F_8 Variación constante de Hacer cortes con respecto a especificaciones. Acordar con el
las reglas del negocio. cliente hacer entregables según una fecha de corte y tomar las
variaciones como solicitudes de cambio.
Riesgos Técnicos
Id Nombre del riesgo Plan de mitigación.
Riesgo
Página 34 de 39
15. Anexo 3 Relación de actividades Nomenclatura
vieja incompleta vs. Nueva nomenclatura.
Nomenclatura vieja incompleta Nomenclatura Nueva
1 1.10.Implementación de estándares de visualización 1.10.Implementación de estándares de visualización
2 1.11.Implementación de usuarios y perfiles definidos 1.11.Implementación de usuarios y perfiles definidos
1.12.Integración de usuarios y perfiles a mecanismos de 1.12.Integración de usuarios y perfiles a mecanismos de
3 autenticación autenticación
4 1.13.Pruebas de autenticación 1.13.Pruebas de Autenticación
5 1.17.Implementación de 3 reportes complejos 1.17.Implementación de 3 reportes complejos
6 1.18.Inspección Implementación por reporte 1.18.Inspección Implementación por reporte
7 1.19.Correcciones inspección Implementación por reporte 1.19.Correcciones Inspección Implementación por reporte
8 1.22.Documentación de los estándares de visualización 1.22.Documentación de los estándares de visualización
9 1.22.Documentación del Módulo de autenticación 1.22.Documentación del Módulo de autenticación
10 1.4.Definición de estándares de visualización 1.4.Definición de estándares de visualización
11 1.5.Inspección estándares visualización 1.5.Inspección estándares visualización
12 1.6.Definición de usuarios y perfiles 1.6.Definición de usuarios y perfiles
13 1.7.Estudio de mecanismos de autenticación 1.7.Estudio de mecanismos de autenticación
14 1.9.Inspección diseño de autenticación 1.9.Inspección diseño de Autenticación
15 2.10.Revisión archivos planos 2.10.Revisión archivos planos
16 2.12.Inspección Diseño 7 estrellas 2.12.Inspección Diseño 7 estrellas
17 2.13.Creación esqueleto de la BD para 7 estrellas 2.13.Creación esqueleto de la BD para 7 estrellas
2.14.Creación de Scripts con datos de prueba para 7 2.14.Creación de Scripts con datos de prueba para 7
18 estrellas estrellas
19 2.15.Elaboración de cubos en xml para 7 estrellas 2.15.Elaboración de cubos en xml para 7 estrellas
20 2.16.Creación de Scripts que manipulen la Autenticación 2.16.Creación de Scripts que manipulen la Autenticación
2.16.Creación de Scripts que manipulen los datos de 7 2.16.Creación de Scripts que manipulen los datos de 7
21 estrellas estrellas
22 2.17.Prueba de cargue de Datos por estrella 2.17.Prueba de cargue de Datos por estrella
23 2.18. Verificación de datos para 7 estrellas 2.18. Verificación de datos para 7 estrellas
24 2.19.Corrección pruebas por estrella 2.19.Corrección pruebas por estrella
25 2.2.Diseño tratamiento de llaves subrogadas 2.2.Diseño tratamiento de llaves subrogadas
26 2.20.Documentación del Módulo de carga 2.22.Documentación del Módulo de carga
27 2.20.Documentación de cubos en xml 2.21 Documentación de cubos en xml
28 2.3.Diseño de procesos de transformación 2.3.Diseño de procesos de transformación
29 2.4.Diseño de la carga de dimensiones 2.4.Diseño de la carga de dimensiones
30 2.5.Diseño de la carga de las tablas de hecho 2.5.Diseño de la carga de las tablas de hecho
31 2.6.Inspección diseño Modulo de cargue 2.6.Inspección diseño Módulo de cargue
32 2.7.Instalación Linux 2.7.Instalación Linux
33 2.8.Instalación eclipse 2.8.Instalación eclipse
34 2.9.Montaje Mondrian 2.9.Montaje mondrián
35 3.7Elaboración Manual de Administrador 3.8. Elaboración Manual de Administrador
36 3.8. Elaboración Manual Técnico 3.8. Elaboración Manual Técnico
37 3.9 Reunión seguimiento 3.9.Reunión seguimiento
38 4.1.Elaboración de 30 dimensiones compartidas en xml 4.1.Elaboración de 30 dimensiones compartidas en xml
39 4.2.Documentación de dimensiones compartidas 4.2.Documentación de dimensiones compartidas
40 Actividades varias 5.8 Actividades Varias
41 Actualización repositorio 5.1 Creación y Actualización repositorio
42 Ajustes diseño 2.12.inspección Diseño Una Estrella
43 Documento diseño del Módulo de carga 2.22.Documentación del Módulo de carga
44 Elaboración documento diseño de BD 2.20.Documentación diseño de bodega de datos
45 Elaboración documento requerimientos técnicos 5.10 Elaboración de requerimientos técnicos.
46 Elaborar documento sistemas 1.22.Documentación del Conocimiento del Negocio
47 Generar Código para la manipulación del tag rol en los xml 2.21.Documentación de cubos Xml
48 Generación de Cronds de Carga Inicial y Mensual 2.17.Prueba de cargue de Datos por estrella
2.14.Creación de Scripts con datos de prueba para una
49 Generar Aplicación Para modificación Masiva de las medidas estrella
50 Implementación conexión jdbc odbc foxpro 5.7 Exploración tecnológica
51 Investigación medida calculada MAT 5.7 Exploración tecnológica
52 Modificación documentos 5.2 Revisión Documentación
53 Planeación detallada 3.2.Planeación Detallada
54 Presentación demo aplicación 5.6 Elaborar Demo
55 Pruebas jdbc odbc foxpro 5.7 Exploración tecnológica
56 Pruebas postgres Windows 5.7 Exploración tecnológica
Realizar la validación de la herramienta octopus como etl del
57 proyecto 5.7 Exploración tecnológica
58 Rediseño Código carga hechos 2.6.inspección diseño modulo de cargue
59 Registro en dotproject 3.11 Registro de Tareas DotProject
60 Reinstalación de máquina 5.4 Reinstalación Máquina
61 Reunión con Osvaldo Aguilar 3.9.Reunión seguimiento
62 Reunión de seguimiento 3.9.Reunión seguimiento
63 Reunión con el cliente 3.9.Reunión seguimiento
64 Reunión entrega datos 3.9.Reunión seguimiento
65 Reunión seguimiento Genome 3.9.Reunión seguimiento
66 Revisión de documentación 5.2 Revisión Documentación
67 Revisión de los archivos planos 2.10.Revisión archivos planos
68 Revisión Documentación 5.2 Revisión Documentación
69 Revisión documentación Mondrian 5.2 Revisión Documentación
70 Revisión documento Sistemas 5.2 Revisión Documentación
71 Revisión error jsp Microsoft Internet Explorer 5.7 Exploración tecnológica
72 Revisión jdbc odbc desde Windows 5.7 Exploración tecnológica
73 Soporte 5.3 Soporte técnico
74 Validación modelo bodega de datos 2.10.Revisión archivos planos
Página 36 de 39
16. Anexo 4 Consulta SQL para obtener tiempos de
actividades.
Esta consulta se ejecutó en la base de datos MySQL donde residían los registros del
proyecto de inteligencia de negocios de la empresa.
SELECT
T.`task_id`,
T.`task_name`,
TL.`task_log_id`,
TL.`task_log_name`,
TL.`task_log_description`,
TL.`task_log_hours`,
TL.`task_log_date`,
U.`user_username`
FROM
`task_log` as TL,
`tasks` as T,
`users` as U
WHERE
`task_log_task` = `task_id` and
T.`task_project`=238 and
U.`user_id`=TL.`task_log_creator`
Página 37 de 39
17. Anexo 5 Tiempos por Actividad y Tipo de Actividad
* Tiempos en horas.
Horas
Nuev o_nombre_Activ idad reales
1.10.Implementación de estándares de visualización 4
1.11.Implementación de usuarios y perfiles definidos 24
1.12.Integración de usuarios y perfiles a mecanismosde autenticación 1
1.13.Pruebas de Autenticación 5
1.17.Implementación de 3 reportes complejos 33
1.18.Inspección Implementación por reporte 73,75
1.19.Correcciones Inspección Implementación por reporte 8
1.22.Documentación de los estándares de visualización 2,5
1.22.Documentación del Conocimiento del Negocio 0
1.22.Documentación del Módulo de autenticación 8
1.4.Definición de estándares de visualización 4
1.5.Inspección estándares visualización 1
1.6.Definición de usuarios y perfiles 0
1.7.Estudio de mecanismos de autenticación 0
1.9.Inspección diseño de Autenticación 6,82
Total Reportes 171,07
Página 38 de 39
2.8.Instalación eclipse 0
2.9.Montaje mondrián 2
Total Estrellas 599,21
Página 39 de 39