Tesina Oviedo y Alfaro v1.1.3 - Universidad para la Cooperación ...

i
UNIVERSIDAD PARA LA COOPERACIÓN INTERNACIONAL
(UCI)
IMPLEMENTACIÓN DE UN SISTEMA DE
ACTIVOS DE PROCESOS
DE RENDIMIENTO Y EFICIENCIA
ESTEBAN OVIEDO BLANCO
LUIS FERNANDO ALFARO ARAYA
PROYECTO FINAL DE GRADUACIÓN PRESENTADO
COMO REQUISITO PARCIAL PARA OPTAR POR EL TÍTULO DE MASTER EN
ADMINISTRACIÓN DE PROYECTOS
San José, Costa Rica
Mayo de 2011

ii
UNIVERSIDAD PARA LA COOPERACION INTERNACIONAL
(UCI)
Este Proyecto Final de Graduación fue aprobado por la Universidad como
Requisito parcial para optar al grado de Máster en Administración de Proyectos
_____________________________
ERIKA GATJENS SOTO
PROFESOR TUTOR
_____________________________
WILLIAM GUITIÉRREZ SANDÍ
LECTOR No.1
_____________________________
GUILLERMO ORTIZ VENEGAS
LECTOR No.2
_____________________________
LUIS FERNANDO ALFARO ARAYA
SUSTENTANTE No.1
_____________________________
ESTEBAN OVIEDO BLANCO
SUSTENTANTE No.2

iii
DEDICATORIA
A mi ESPOSA
Por servirme de ejemplo de esfuerzo y superación
Esteban
A mi MADRE
Mi socia, mi amiga y un gran ejemplo de Vida
Luis Fernando
A BABEL Software
Por el apoyo brindado y por patrocinar el proyecto
Luis Fernando y Esteban

iv
AGRADECIMIENTOS
Este trabajo es el fruto de un esfuerzo personal y profesional, pero sobre
todo, es el efecto combinado de muchas personas y circunstancias que nos
permitieron alcanzar los objetivos que nos habíamos propuesto. Mencionar de
manera justa a cada quien es una empresa arriesgada, pero que emprendemos
con enorme gusto.
Quisiéramos reconocer a la Universidad para la Cooperación Internacional
(UCI), por intermedio de Ing. Ramiro Fonseca al Correo, en su calidad de Decano
por el entorno estimulante que nos brindó en el periodo de estudio y por la
excelencia de la formación académica.
Tuvimos la suerte de contar con una tutora, una filóloga y dos lectores de
gran calidad: Ing. Erika Gätjens Soto, Ms Cristina Araya Umaña, Ing. Edgar
Oviedo Blanco y al Ing. William Gutiérrez, respectivamente, quienes más allá de
su responsabilidad particular, hicieron contribuciones siempre oportunas y
enriquecedoras.
Este periodo de estudio y a presión como los que hemos vivido implica
muchas pequeñas dificultades y desafíos. Los amigos y compañeros de trabajo de
BABEL Software, jugaron un rol facilitador que merece mencionarse, entre ellos o
más en su nombre, quisiéramos mencionar a Erick Salazar, Guillermo Ortiz y
Cesar Oviedo.

v
Completar la maestría es, sin duda, un logro profesional y personal que
tiene un real sentido cuando pensamos en quienes más han influido en nuestra
formación como persona y profesional.
A todos, nuestro más sincero agradecimiento.

vi
ÍNDICE
DEDICATORIA ........................................................................................................ iii
AGRADECIMIENTOS ............................................................................................. iv
ÍNDICE .................................................................................................................... vi
ÍNDICE DE FIGURAS ........................................................................................... viii
ÍNDICE DE CUADROS .......................................................................................... xii
RESUMEN EJECUTIVO ....................................................................................... xiii
1. INTRODUCCIÓN ........................................................................................... 14
1.1. Antecedentes ........................................................................................... 14
1.2. Problemática. ........................................................................................... 17
1.3. Justificación del problema ........................................................................ 18
1.4. Supuestos ................................................................................................ 19
1.5. Restricciones ........................................................................................... 20
1.6. Objetivo general ....................................................................................... 20
1.7. Objetivos específicos ............................................................................... 20
2. MARCO TEORICO ........................................................................................ 22
2.1. Marco referencial o institucional ............................................................... 22
2.1.1. Antecedentes de la Institución ........................................................... 22
2.1.2. Visión y Misión de BABEL ................................................................. 28
2.1.3. Estructura organizativa ...................................................................... 29
2.1.4. Productos que ofrece ........................................................................ 31
3. MARCO METODOLOGICO ........................................................................... 52
3.1. Fuentes de información ............................................................................ 52
3.1.1. Fuentes Primeras .............................................................................. 52
3.1.2. Fuentes Secundarias ......................................................................... 53
3.2. Técnicas de Investigación ........................................................................ 54
3.3. Método de Investigación .......................................................................... 55
3.4. Marco Metodológico del Proyecto según los objetivos planteados .......... 57
4. DESARROLLO .............................................................................................. 60
4.1. Análisis del sistema actual ....................................................................... 60
4.1.1. AdIntra-InSpec................................................................................... 60
4.1.2. BugTracking ...................................................................................... 75
4.1.3. Análisis de la situación actual .......................................................... 104
4.2. Administración del proyecto ................................................................... 108
4.2.1. Gestión de Integración .................................................................... 108
4.2.2. Gestión del alcance ......................................................................... 116
4.2.3. Gestión del tiempo ........................................................................... 122
4.2.4. Gestión de costos ............................................................................ 125

4.2.5. Gestión de calidad ........................................................................... 129
4.2.6. Gestión de recursos humanos ......................................................... 130
4.2.7. Gestión de comunicaciones ............................................................ 135
4.2.8. Gestión de Riesgos ......................................................................... 138
4.2.9. Gestión de Adquisiciones ................................................................ 144
4.3. Entregables del proyecto ....................................................................... 145
4.3.1. Entrevistas con los interesados ....................................................... 145
4.3.2. Análisis de las fuentes de información ............................................ 146
4.3.3. Análisis técnico de dimensiones y métricas .................................... 153
4.3.4. Diseño de la solución propuesta...................................................... 158
4.3.5. Diseño de los reportes de la herramienta ........................................ 162
4.4. Ejecución del Proyecto ........................................................................... 187
5. CONCLUSIONES ........................................................................................ 204
6. RECOMENDACIONES ................................................................................ 206
7. BIBLIOGRAFÍA ............................................................................................ 209
8. ANEXOS ...................................................................................................... 210
8.1. Anexo 1: ACTA CONSTITUTIVA DEL PFG ........................................... 210
8.2. Anexo 2: EDT DEL PFG ........................................................................ 216
8.3. Anexo 3: CRONOGRAMA DEL PFG ..................................................... 218
8.4. Anexo 4: CRONOGRAMA DEL PROYECTO SAPRE ........................... 221
8.1. Anexo 5: DEMOSTRACIÓN DEL PROYECTO SAPRE......................... 222
vii

viii
ÍNDICE DE FIGURAS
Figura 1. Competencias en Tecnologías de Microsoft. ......................................... 24
Figura 2. Plataformas tecnológicas usadas en BABEL ......................................... 26
Figura 3. Estructura Organizativa de BABEL ........................................................ 29
Figura 4. Dirección Financiero-Administrativa y la dirección Operativa de BABEL 30
Figura 5. Ciclo de vida para el desarrollo de software de BABEL ........................ 34
Figura 6. Ciclo de vida para el desarrollo de BI de BABEL ................................... 37
Figura 7. Arquitectura del Data Warehouse de BABEL ......................................... 37
Figura 8. Ciclo de vida del Outsourcing ................................................................ 42
Figura 9. Ciclo de vida del Software Factory ......................................................... 45
Figura 10. Principales clientes de BABEL ............................................................. 51
Figura 11. Pantalla de Login de Adintra ................................................................ 61
Figura 12. Pantalla de ingreso al sistema de Adintra ............................................ 62
Figura 13. Árbol de carpetas de Adintra ................................................................ 63
Figura 14. Menú de opciones de Adintra .............................................................. 64
Figura 15. Jerarquía de Proyecto-Módulo de Adintra ............................................ 64
Figura 16. Pantalla de creación de proyecto de Adintra ........................................ 65
Figura 17. Pantalla de creación de módulo de Adintra .......................................... 65
Figura 18. Pantalla de jerarquía de Proyecto-Módulo-Requerimiento de Adintra . 66
Figura 19. Pantalla de creación de requerimiento de Adintra ............................... 66
Figura 20. Pantalla de jerarquía de proyecto-Módulo-Requerimiento-CasoUso de
Adintra ................................................................................................................... 67
Figura 21. Pantalla de creación del caso de uso de Adintra ................................. 68
Figura 22. Estructura de Proyecto-Módulo-Requerimiento-CasoUso-CasoPrueba
de Adintra .............................................................................................................. 68
Figura 23, Pantalla de creación de caso de prueba de Adintra ............................. 69
Figura 24. Estructura de Proyecto-Módulo-Requerimiento-CasoUso-CasoPrueba-
EscenarioPrueba de Adintra ................................................................................. 70
Figura 25. Creación del escenario de prueba (tab de Descripción) de Adintra ..... 71
Figura 26. Creación del escenario de prueba (tab de Requerimientos) de Adintra 72
Figura 27. Creación del escenario de prueba (tab de Procedimiento) de Adintra . 73
Figura 28. Creación del escenario de prueba (tab de Resultados) de Adintra ...... 74
Figura 29. Creación del escenario de prueba (tab de Archivos adjuntos) de Adintra
.............................................................................................................................. 74
Figura 30. Pantalla de ingreso al sistema de Bug Tracking .................................. 75
Figura 31. Pantalla inicial del sistema de Bug Tracking ........................................ 76
Figura 32. Pantalla de consulta de pulgas de Bug Tracking ................................. 77
Figura 33. Pantalla de “Nueva pulga” de Bug Tracking ......................................... 78

Figura 34. Pantalla de pulga nueva con los campos ingresados de Bug Tracking 79
Figura 35. Pantalla de consulta de pulgas de Bug Tracking ................................. 80
Figura 36. Pantalla de consulta de pulgas de Bug Tracking ................................. 81
Figura 37. Pantalla de “Modificar Pulga” de Bug Tracking .................................... 81
Figura 38. Sub-Pantalla de “Modificar Estado de la Pulga” de Bug Tracking ........ 82
Figura 39. Pantalla de “Consulta de Pulgas” de Bug Tracking .............................. 82
Figura 40, Pantalla de “Consulta de Pulgas” de Bug Tracking .............................. 83
Figura 41. Pantalla de “Modificar Pulga” de Bug Tracking .................................... 84
Figura 42. Sub-Pantalla de “Modificar estado de la Pulga” de Bug Tracking ........ 84
Figura 43. Pantalla de “Consulta de Pulga” de Bug Tracking ............................... 85
Figura 44. Pantalla de “Modificar Pulga” de Bug Tracking .................................... 86
Figura 45. Sub-Pantalla de “Modificar estado de la Pulga” de Bug Tracking ........ 87
Figura 46. Pantalla inicial de “Consulta de Requerimientos Asignados” de Bug
Tracking ................................................................................................................ 87
Figura 47. Pantalla de “Consulta de Requerimientos Asignados” de Bug Tracking
.............................................................................................................................. 88
Figura 48. Pantalla de “Consulta de Requerimientos Asignados” de Bug Tracking
.............................................................................................................................. 89
Figura 49. Pantalla de “Asignar Requerimientos” de Bug Tracking ....................... 89
Figura 50. Pantalla de “Asignar Requerimientos” de Bug Tracking ....................... 90
Figura 51. Pantalla de “Configuración de Versión de Revisión de Proyectos” de
Bug Tracking ......................................................................................................... 91
Figura 52. Pantalla de “Configuración de Versiones – Seleccionar Proyecto” de
Bug Tracking ......................................................................................................... 91
Figura 53. Pantalla de “Configuración de Versiones” de Bug Tracking ................. 92
Figura 54. Pantalla de “Configuración de Versiones – Crear una nueva versión” de
Bug Tracking ......................................................................................................... 93
Figura 55. Pantalla de “Configuración de Versiones – Nueva versión creada” de
Bug Tracking ......................................................................................................... 93
Figura 56. Pantalla “Misc. Tables” de Bug Tracking .............................................. 94
Figura 57. Pantalla “Misc. Tables – Crear una nueva prioridad o severidad” de Bug
Tracking ................................................................................................................ 95
Figura 58. Pantalla “Misc. Tables – Prioridad o severidad creada” de Bug Tracking
.............................................................................................................................. 96
Figura 59. Pantalla de “Consulta de tiempos de corrección de pulgas” de Bug
Tracking ................................................................................................................ 97
Figura 60. Pantalla de “Consulta de tiempos de corrección de pulgas” de Bug
Tracking ................................................................................................................ 98
Figura 61. Pantalla de “Consulta de tiempos de corrección de pulgas” de Bug
Tracking ................................................................................................................ 98
ix

Figura 62. Sub-Pantalla de “Historial de tiempos de corrección de pulgas” de Bug
Tracking ................................................................................................................ 99
Figura 63. Pantalla “User and Security” de Bug Tracking ................................... 100
Figura 64. Pantalla “User and Security – Pestaña Users” de Bug Tracking ........ 101
Figura 65. Pantalla “User and Security – Pestaña User Groups” de Bug Tracking
............................................................................................................................ 101
Figura 66. Pantalla “User and Security – Pestaña User Groups” de Bug Tracking
............................................................................................................................ 102
Figura 67. Pantalla “User and Security – Pestaña User Groups” de Bug Tracking
............................................................................................................................ 103
Figura 68. Diagrama de cierre de proyecto de SAPRE ....................................... 114
Figura 69. EDT de la fase de inicio de SAPRE ................................................... 117
Figura 70. EDT de la fase de planeación de SAPRE .......................................... 119
Figura 71. EDT de la fase de ejecución de SAPRE ............................................ 120
Figura 72. EDT de la fase de control de SAPRE ................................................. 121
Figura 73. EDT de la fase de cierre de SAPRE .................................................. 121
Figura 74. Diagrama de control de calidad para proyectos internos pequeños de
Babel ................................................................................................................... 129
Figura 75. Estructura Organizacional de SAPRE ................................................ 131
Figura 76, Plan de ingreso y liberación de personal de SAPRE ......................... 134
Figura 77, Base de Datos de AdIntra-InSpec ...................................................... 148
Figura 78, Base de Datos de Bug Tracking ........................................................ 151
Figura 79, Diagrama de la solución propuesta para SAPRE .............................. 159
Figura 80, Diagrama de las fuentes de datos de SAPRE ................................... 160
Figura 81, Sección de datos de Microsoft Excel ................................................. 164
Figura 82, Sección de Otras fuentes de Microsoft Excel ..................................... 165
Figura 83, Conectar con el servidor de bases de datos de tabla pivote de Excel 165
Figura 84, Seleccionar base de datos y tabla de tabla pivote de Excel ............. 166
Figura 85, Importación de datos de la tabla pivote de Excel ............................... 167
Figura 86, Creación reporte 1 en Excel, paso 1 .................................................. 168
Figura 87, Creación reporte 1 en Excel, paso 2 .................................................. 169
Figura 88, Creación reporte 1 en Excel, paso 3 .................................................. 170
Figura 89, Gráfica del reporte 1 en Excel ............................................................ 171
Figura 90, Creación reporte 2 en Excel, paso 1 .................................................. 172
Figura 91, Creación reporte 2 en Excel, paso 2 .................................................. 173
Figura 92, Creación reporte 2 en Excel, paso 3 .................................................. 174
Figura 93, Gráfica del reporte 2 en Excel ............................................................ 175
Figura 94, Creación reporte 3 en Excel, paso 1 .................................................. 176
Figura 95, Creación reporte 3 en Excel, paso 2 .................................................. 177
Figura 96, Creación reporte 3 en Excel, paso 3 .................................................. 178
x

Figura 97, Creación reporte 4 en Excel, paso 1 .................................................. 179
Figura 98, Creación reporte 4 en Excel, paso 2 .................................................. 180
Figura 99, Gráfica del reporte 4 en Excel ............................................................ 181
Figura 100, Creación reporte 5 en Excel, paso 1 ................................................ 182
Figura 101, Creación reporte 5 en Excel, paso 2 ................................................ 183
Figura 102, Gráfica del reporte 5 en Excel .......................................................... 184
Figura 103, Creación reporte 6 en Excel, paso 1 ................................................ 185
Figura 104, Creación reporte 6 en Excel, paso 2 ................................................ 186
Figura 105, Grafica del valor ganado de la primera semana de SAPRE ............ 188
Figura 106, Grafica del valor ganado de la segunda semana de SAPRE ........... 189
Figura 107, Grafica del valor ganado de la tercera semana de SAPRE ............. 191
Figura 108. Gráfica del valor ganado de la cuarta semana de SAPRE ............... 192
Figura 109, Grafica del valor ganado de la quinta semana de SAPRE ............... 194
Figura 110. Gráfica del valor ganado de la séptima semana de SAPRE ............ 195
Figura 111. Gráfica del valor ganado de la octava semana de SAPRE .............. 197
Figura 112. Gráfica del valor ganado de la novena semana de SAPRE ............. 199
Figura 113. Gráfica del valor ganado de la décima semana de SAPRE ............. 200
Figura 114. Gráfica del valor ganado de la décima primera semana de SAPRE 202
Figura 115. Gráfica del valor ganado de la décima segunda semana de SAPRE
............................................................................................................................ 203
Figura 116, EDT del desarrollo de la tesina ........................................................ 217
Figura 117, Cronograma del desarrollo de la tesina ........................................... 220
Figura 118, Cronograma del proyecto SAPRE ................................................... 221
xi

xii
ÍNDICE DE CUADROS
Cuadro 1. Marco metodológico para el objetivo de contar con una nueva
herramienta del proyecto SAPRE ......................................................................... 57
Cuadro 2, Marco metodológico para el objetivo de generar activos de procesos del
proyecto SAPRE ................................................................................................... 58
Cuadro 3. Marco metodológico para el objetivo de brindar retroalimentación del
proyecto SAPRE ................................................................................................... 59
Cuadro 4. Acta Constitutiva del proyecto del proyecto SAPRE........................... 108
Cuadro 5, Lista de involucrados del proyecto SAPRE ........................................ 122
Cuadro 6. Lista de actividades del proyecto SAPRE .......................................... 123
Cuadro 7. Costos de los recursos del proyecto SAPRE ..................................... 125
Cuadro 8. Costos de las etapas del proyecto SAPRE ........................................ 126
Cuadro 9. Costos de las actividades del proyecto SAPRE ................................. 126
Cuadro 10. Presupuesto del proyecto SAPRE .................................................... 128
Cuadro 11. Interesados del proyecto SAPRE ..................................................... 135
Cuadro 12. Análisis de interesados del proyecto SAPRE ................................... 136
Cuadro 13. Matriz de comunicaciones del proyecto SAPRE .............................. 137
Cuadro 14. Riesgo RSK-001 del proyecto SAPRE ............................................. 138
Cuadro 15. Riesgo RSK-002 del proyecto SAPRE ............................................. 139
Cuadro 16. Riesgo RSK-003 del proyecto SAPRE ............................................. 140
Cuadro 17. Riesgo RSK-004 del proyecto SAPRE ............................................. 140
Cuadro 18. Riesgo RSK-005 del proyecto SAPRE ............................................. 141
Cuadro 19. Riesgo RSK-006 del proyecto SAPRE ............................................. 142
Cuadro 20. Riesgo RSK-007 del proyecto SAPRE ............................................. 143
Cuadro 21. Valor ganado de la primera semana del proyecto SAPRE ............... 187
Cuadro 22. Valor ganado de la segunda semana del proyecto SAPRE ............. 189
Cuadro 23. Valor ganado de la tercera semana del proyecto SAPRE ................ 190
Cuadro 24. Valor ganado de la cuarta semana del proyecto SAPRE ................. 191
Cuadro 25. Valor ganado de la quinta semana del proyecto SAPRE ................. 193
Cuadro 26. Valor ganado de la séptima semana del proyecto SAPRE ............... 194
Cuadro 27. Valor ganado de la octava semana del proyecto SAPRE ................. 196
Cuadro 28. Valor ganado de la novena semana del proyecto SAPRE ............... 198
Cuadro 29. Valor ganado de la décima semana del proyecto SAPRE ................ 199
Cuadro 30. Valor ganado de la décima primera semana del proyecto SAPRE .. 201
Cuadro 31. Valor ganado de la décima segunda semana del proyecto SAPRE . 202
Cuadro 32. Acta Constitutiva del PFG ................................................................ 210

xiii
RESUMEN EJECUTIVO
El presente estudio se orienta a la Implementación de un Sistema de
Activos de Procesos de Rendimiento y Eficiencia, el cual surge de la necesidad de
mejorar la retroalimentación dada a la organización por el “Departamento de
Aseguramiento de la Calidad”, cuyo propósito último es asegurar un proceso de
reingeniería en la empresa costarricense BABEL Software, orientado a asegurar la
calidad de los productos y los servicios, y, promover y asegurar el involucramiento
activo de todos los actores empresariales.
En particular, este proceso de reingeniería busca desarrollar una ventana
de oportunidad para BABEL y que se orienta al incremento del poder de las
herramientas con que cuenta la empresa para el seguimiento y la medición del
rendimiento del personal, durante el proceso de fabricación del software.
El estudio, de aplicación práctica-programática, se desarrolló en el periodo
comprendido entre el 20 de noviembre del 2010 y el 30 de marzo del 2011. Esta
propuesta de mejora fue aceptada por la empresa y, desde el 31 de marzo del
2011, es de acatamiento obligatorio por parte de los integrantes del equipo, en
cualquiera de las etapas de los proyectos, con el fin de proporcionar a los gerentes
de proyecto, mejores activos de procesos con los que podrán mejorar su reacción
ante imprevistos del día a día y también su estimación ante los nuevos proyectos,
todo esto mientras se mejoran los procesos de captura y seguimiento de
inconsistencias (pulgas).
PALABRAS CLAVE: Control de Calidad, Proceso de Fabricación del Software,
Indicadores de Desempeño, Tecnología de la Información, Empresa
Costarricense, Inteligencia de Negocios, Outsourcing, Data Warehouse, Cubos de
información.

14
"La imaginación es más importante que el conocimiento.
El conocimiento es limitado, mientras que la imaginación no"
Albert Einstein
1. INTRODUCCIÓN
1.1. Antecedentes
Soluciones Informáticas BABEL S.A., conocida comercialmente como BABEL 1 ,
es una empresa de capital costarricense fundada en enero de 2002. BABEL tiene
como objetivo principal el diseño e implementación de soluciones informáticas y
sus servicios se ofertan a distintas empresas e instituciones que deseen utilizar la
tecnología de información como medio para incrementar el rendimiento y la
eficiencia en la ejecución de sus procesos.
Iniciada en el año 2002 como una microempresa y con solamente dos
empleados, BABEL ha crecido de manera exponencial; de ahí que para el 2008 –
tan solo 6 años después–, la empresa ya contaba con cerca de 100 colaboradores
directos y con 3 sedes: dos en Costa Rica y una en Ecuador. Este crecimiento
obliga a cualquier compañía a ordenar sus procesos de producción y a fortalecer
sus líneas de negocio, si desea seguir manteniendo un nivel de crecimiento
sostenible. Es por ello que, en el 2008, la empresa decidió invertir en un proceso
de preparación para aspirar a una certificación internacional y con esto optimizar
sus procesos, economizar costos de producción y garantizar productos de buena
calidad a sus clientes, de tal forma que sea reconocida no sólo como una empresa
1 En lo sucesivo BABEL o la empresa.

15
ordenada, sino también de alta calidad y con estándares de trabajo reconocidos a
escala internacional.
En el mercado del Desarrollo de Software, al igual que en la mayoría de
mercados, las certificaciones de los procesos de una compañía marcan una
enorme diferencia favorable en relación con aquellas compañías que no cuentan
con ellas. Dentro de las certificaciones más famosas a nivel mundial en cuanto a
desarrollo de software se encuentra la de Capability Maturity Model Integration (o
CMMI por sus siglas en inglés), la cual se basa en cinco niveles de capacidad de
madurez. Estos son:
1. Ejecutado
2. Gestionado
3. Definido
4. Cuantitativamente gestionado
5. Optimizado
Para acceder a una certificación de CMMI, la empresa tuvo que llevar a cabo
tres acciones principales, a saber:
1. Definir y documentar todos los procedimientos que componen la metodología
de gestión y fabricación del software, basándose en estándares y teoría
mundialmente reconocida y alineada a la manera en que la empresa venía
trabajando.
2. Crear un departamento formal de “Aseguramiento de la Calidad”, de manera
que sus integrantes, además de realizar pruebas a los artefactos de software,
también monitorean los procedimientos de fabricación y con ello garantizarle a
los clientes y a la organización que se están respetando.

16
3. Contratar a un consultor experto por un período de un año para que guiara a la
empresa en este proceso de ordenamiento y culturización, de manera que se
fuera preparando para una posible evaluación y certificación.
Para efectos de la presente tesina, lo establecido en el numeral 2 anterior es
de particular importancia, ya que el departamento de Aseguramiento de Calidad es
el marco operativo y programático en el cual se desarrollará e incorporará el
proyecto en estudio.
Ya dicho, el departamento de Aseguramiento de Calidad se encarga de realizar
las pruebas de verificación y validación a los entregables que va desarrollando el
departamento de Desarrollo a la Medida, pero también es el responsable de
auditar los procedimientos de fabricación. Para realizar estas labores la empresa
debió invertir en la creación y compra de herramientas que automatizaran los
procesos de revisión de los productos, así como para la identificación y
seguimiento de errores en los mismos.
Dotarse de estas herramientas le permitió a la empresa documentar cada
revisión y cualquier posible error en algún producto, pero también le permitió
obtener indicadores muy importantes en cuanto al desempeño de la empresa
durante cada proyecto. Esto ha permitido obtener información de la cantidad de
errores y tiempo de retrabajo (desperdicio) para un proyecto específico, para una
etapa específica de un proyecto específico y para cada empleado que participó en
un proyecto específico.
Esta gran utilidad no es sino que un activo de proceso que la organización
logró automatizar para cada proyecto que desarrolla y con la cual puede efectuar

17
una etapa de cierre en cada proyecto, permitiendo con ello la retroalimentación a
cada miembro del equipo del proyecto para efectos de reconocimiento laboral, o
bien, para hacer conciencia y evaluar lo que se hizo incorrectamente y así buscar
una mejora continua en cada nuevo proyecto.
En la actualidad BABEL cuenta con oficinas en San José, Pérez Zeledón,
Ecuador y República Dominicana y nuevamente está alcanzando los 100
colaboradores directos. Luego de la crisis del año 2009, la empresa está
retomando los esfuerzos y la inversión que tenía en el 2008, lo que hace
indispensable actualizar los procedimientos y las herramientas con que ya cuenta.
1.2. Problemática.
Más que un problema, la presente tesina busca desarrollar una ventana de
oportunidad que se le presenta a BABEL para incrementar el poder de las
herramientas con que cuenta para el seguimiento y la medición del rendimiento del
personal, durante el proceso de fabricación del software, de manera que pueda
obtener la misma información –y más– de la que actualmente obtiene de los
indicadores, tanto de un proyecto específico como de todos los proyectos que se
desarrollan en la empresa.
De esta manera, lo que se busca es obtener la capacidad de analizar el
proceso de fabricación y al personal mismo que compone los equipos de proyecto,
más que analizar un simple proyecto. En otras palabras, el objetivo que se
persigue es ampliar la capacidad de análisis que actualmente se realiza, para
alimentar los activos de procesos de una manera integral donde se tomen en
cuenta todos los proyectos y no solamente uno en específico.

18
Así, por ejemplo, en cualquier momento se podrá analizar el rendimiento de
cualquier miembro del equipo de proyecto en cualquier etapa del proceso de
fabricación, para todos los proyectos en general. Actualmente se puede realizar un
análisis como el siguiente: “¿Cuál es el rendimiento de X, durante la etapa de
diseño del proyecto SIFA?”
Una vez desarrollado el proyecto, se podrá profundizar el análisis de manera
que se pueda realizar un análisis como este: “¿Cuál es el rendimiento promedio de
X, durante las etapas de diseño de todos los proyectos?”. Con esto se puede
identificar si X tiene alguna deficiencia en su capacidad como diseñador, o si algún
error que cometió en el proyecto actual es ocasional. Luego, en caso de que se
determine que es algo ocasional, podría evaluarse como sigue: “¿Cuál es el
rendimiento de X durante los meses de Diciembre de un periodo dado?”, y con eso
se podría identificar algún antecedente personal que pudiera estar afectando el
rendimiento de X en cada diciembre desde que ocurrió algún evento lamentable y
con ello identificar que el bajo rendimiento de X en el diseño no corresponde a
falta de competencia, sino a una afectación de orden emocional.
Para lograr este objetivo, informáticamente no es suficiente desarrollar un
conjunto de reportes estáticos, ya que la información siempre sería la misma y lo
que se busca es tener flexibilidad en el análisis, por lo que se deberá optar por la
implementación de una solución de Inteligencia de Negocios (BI, por sus siglas en
inglés).
1.3. Justificación del problema
La empresa cuenta actualmente con una serie de Activos de Procesos
basados en indicadores de rendimiento y retrabajo por proyecto, por miembro del

19
equipo en una fase específica de un proyecto específico y por proyecto específico.
Se requiere alimentar los activos de procesos con información global de todos los
proyectos, sin limitarse a un proyecto específico. El fin último de esto es que
BABEL sea una empresa con estándares internacionales y de competencia
mundial.
1.4. Supuestos
Como supuestos para este proyecto, tenemos:
• Un sistema que está a cargo del Departamento de Calidad, en el cual se
registran los siguientes datos:
Las inconsistencias detectadas en cada uno de los requerimientos del
sistema.
Registro del desarrollador que realizó el requerimiento o bien de quienes
estuvieron involucrados en la elaboración.
El tiempo que duró el desarrollador en solucionar la inconsistencia y cuándo
fue aprobada por el Departamento de Calidad.
• Una base de datos, que cuenta con toda la información estructurada de todos
los proyectos realizados hasta la fecha.
• Integrar a la empresa una buena base, luego del seminario de graduación para
la elaboración del PFG.
• Fortalecimiento del trabajo en grupo.
• Comunicación abierta y fluida entre el tutor y los sustentantes.

20
1.5. Restricciones
Como restricciones para este proyecto se pueden identificar:
1. Tiempo, dado que se cuenta hasta el mes de abril para desarrollar el PFG.
2. Fluidez, toda vez que la comunicación será a través del sitio web de la UCI.
3. Acceso a tecnologías, ya que sólo se utilizarán con las que la empresa tenga
licencia.
4. Sólo se cuenta con dos desarrolladores para la realización de este sistema.
5. La información a utilizar será únicamente la contenida en la base de datos del
sistema que actualmente se utiliza para el control de inconsistencias.
1.6. Objetivo general
Maximizar la capacidad de análisis del rendimiento de los miembros de los
equipos de proyectos en un plazo de 3 meses, mediante el desarrollo de una
herramienta de inteligencia de negocios enfocada en el Control de Calidad de los
entregables dentro del proceso de fabricación del software, con el propósito de
generar elementos que permitan a la empresa su competencia y certificación a
nivel internacional.
1.7. Objetivos específicos
1. Contar con una herramienta que permita en un plazo no mayor a 3 meses,
efectuar un análisis del rendimiento e índices de retrabajo de los miembros de
proyectos, en todos los proyectos en general, sin limitarse a un análisis para un
proyecto específico.

21
2. Generar en el instante que sea necesario activos de procesos de la
organización, basados en estadísticas generales de rendimiento por persona,
por etapa del proceso y por fechas, para faciliatar la toma de desiciones, tanto
administrativas como gerenciales
3. Brindar retroalimentación a los miembros de los equipos de proyectos en la
etapa de cierre, mediante la generación de reportes definidos por los gerentes
de proyecto, a fin de mejorar su rendimiento tanto en el proyecto que cierra
como en su historial de proyectos en la empresa.

22
2. MARCO TEORICO
2.1. Marco referencial o institucional
2.1.1. Antecedentes de la Institución
BABEL es una empresa dedicada al análisis, diseño e implementación de
soluciones informáticas, mediante el desarrollo de herramientas de software que
se integran a cualquier plataforma.
Fundada en enero del 2002, la empresa tiene como visión convertirse en
la mejor opción para las organizaciones que desean renovar o mejorar su
plataforma de tecnologías de información, como medio para incrementar el
rendimiento en la ejecución de los procesos.
BABEL es la empresa costarricense de mayor crecimiento del sector de
tecnologías de la información en los últimos años, habiéndose convertido
además en socio comercial del productor de software más importante del mundo
y colocándose en la máxima categoría que otorga esta compañía a nivel
mundial: Microsoft Gold Certified Partner. Al contar con más de 50 profesionales
certificados en diversas tecnologías de Microsoft, es una de las diez empresas
latinoamericanas con la mayor cantidad de consultores certificados y
competencias técnicas adquiridas.
Todo esto, en conjunto, le ha permitido a BABEL consolidarse en el
mercado costarricense y proyectarse hacia el mercado mundial. En el año 2007
se da la apertura de una oficina en la Zona Sur de Costa Rica, y un año
después, la empresa inicia operaciones en Ecuador, contando en la actualidad
con cerca de 10 ingenieros en cada oficina. Así entonces, BABEL consolida su

23
presencia internacional y fortalece las estrechas relaciones con sus actuales
socios comerciales, con quienes ha desarrollado hasta el día de hoy más de 200
proyectos exitosos, tanto en instituciones del sector público como del sector
privado, en más de 10 países alrededor del mundo.
A inicios del 2010, BABEL extiende sus operaciones en República
Dominicana, con lo cual consolida un equipo de cerca de cien colaboradores y
asociados en total, siendo una empresa de alto nivel enfocada en la excelencia
del servicio y la calidad de su personal.
Perfil de la Empresa
Empresa de inversión 100 por ciento costarricense.
Desarrollo de software a la medida y servicios complementarios.
Integradores de sistemas de información.
Expertos en el desarrollo de herramientas de inteligencia de negocios.
Nueve años de experiencia en más de 10 países en cuatro continentes.
Consultores con muy amplia experiencia en diversas tecnologías para el
desarrollo de software.
Microsoft Gold Certified Partner con más competencias a nivel
centroamericano.
Cerca de 50 de sus consultores certificados en más de 10 distintas áreas
de especialización, tanto de Microsoft como Oracle, Java y otras
plataformas tecnológicas.
Departamentos especializados: Desarrollo a la medida, Base de datos,
Soporte de aplicaciones, Outsourcing, Soporte en Tecnologías de la
Información, Aseguramiento de la Calidad, entre otros.

24
Figura 1. Competencias en Tecnologías de Microsoft.
Perfil de los Profesionales
Áreas de Desempeño:
Actualmente BABEL cuenta con personal capacitado en las áreas de:
Ingeniería de Software:
Análisis de problemas y diseño de soluciones.
Diseño avanzado con UML.
Modelado de bases de datos mediante el uso de herramientas CASE.
Inteligencia de Negocios:
Soluciones basadas en plataforma Microsoft, integrando con Oracle,
DB2/AS400, etc.
Gestión de proyectos de software:
Procesos ingenieriles de estimación de proyectos de software.
Aseguramiento de la calidad del software.
Control de cambios en el software.
Gestión de riesgos en proyectos de software.
Ingeniería industrial orientada al mejoramiento informático:
Análisis y auditoría de procesos industriales y de manufactura.
Estudio y optimización de procedimientos organizacionales.

25
Apoyo mediante software a certificaciones de calidad (ISO, CMMI).
Formación Académica
Los socios, funcionarios y colaboradores de BABEL cuentan con estudios de
ingeniería, de maestría y de doctorado en las diversas áreas antes
mencionadas, en universidades de alto prestigio, como son:
Universidad de Alicante, España (UA)
Universidad Politécnica de Madrid, España (UPM)
Instituto Tecnológico de Costa Rica (ITCR)
Centro de Formación en Tecnologías de Información (CENFOTEC)
Universidad de Costa Rica (UCR)
Universidad Nacional de Costa Rica (UNA)
Universidad Latina de Costa Rica (ULatina)
Universidad Interamericana de Costa Rica (UICR)
Escuela Politécnica del Ejército de Ecuador (ESPE)
Plataformas tecnológicas.
En directa armonía con su nombre, BABEL ofrece a sus clientes soluciones
en diferentes plataformas y lenguajes. Si bien su fuerte son las herramientas
Microsoft, propiamente el valor agregado del servicio que la empresa brinda, se
centra en la integración de servicios y plataformas:
Microsoft.Net
Silverlight

26
Sharepoint
PHP
Java
Oracle
Microsoft SQL Server
AS/400
Adobe Flex
Figura 2. Plataformas tecnológicas usadas en BABEL
Lenguajes de programación
C# .NET
VB .NET
Java
PHP
HTML
JavaScript
XML

27
XAML
Herramientas de diseño gráfico
Adobe Flex
Adobe Fireworks
Adobe Dreamweaver
Adobe Flash
Adobe Photoshop
Adobe Illustrator
Microsoft SilverLight
Expression Blend
Herramientas para análisis y diseño
Visio
Rational Rose
ER-Win
Bases de datos
SQL Server
Oracle
DB2
Herramientas para reportes
Reporting Services
Crystal Reports
Herramientas para administración de infraestructura
ISA Server
IIS
Active Directory
Exchange
SharePoint Services

28
2.1.2. Visión y Misión de BABEL
Visión
Ser reconocida internacionalmente como una compañía costarricense
consolidada y confiable, que brinda las mejores soluciones en el área de la
Tecnología de Información.
Misión
Ofrecer al mercado nacional e internacional las soluciones informáticas a la
medida de la más alta calidad, haciendo uso de las tecnologías más modernas
disponibles y el personal más calificado del mercado, satisfaciendo plenamente y
de manera eficiente y eficaz, las necesidades informáticas de nuestros clientes.

29
2.1.3. Estructura organizativa
Figura 3. Estructura Organizativa de BABEL

30
A continuación se detallan la dirección Financiero-Administrativa y la dirección Operativa.
Figura 4. Dirección Financiero-Administrativa y la dirección Operativa de BABEL

31
2.1.4. Productos que ofrece
Líneas de Negocios (Servicios)
BABEL ofrece el desarrollo e integración de sistemas en las siguientes
modalidades:
• Desarrollo de Software a la Medida
• Inteligencia de Negocios
• Outsourcing y Software Factory
• Soporte de Aplicaciones
• Soporte Técnico
A continuación se brinda una breve descripción de cada servicio que brinda la
compañía. Para efectos de la presente tesina, se le solicita al lector prestar mayor
atención al apartado de Inteligencia de Negocios, ya que es el marco en el que se
desarrollará el proyecto.

32
BABEL ofrece un proceso completo de Desarrollo de Software a la
Medida, que contempla desde la investigación y el análisis de las
necesidades reales del cliente, hasta el diseño, desarrollo e
implementación de una solución informática que brinde a los usuarios
un incremento en la productividad y facilidad en el manejo de la
información.
Con la experiencia de más de 200 proyectos en 4 continentes, la empresa ha logrado
desarrollar una metodología que permite llevar a cabo exitosamente cada una de las etapas
de sus proyectos. Para esto, en cada una de las etapas del proceso de fabricación de
software se utilizan procedimientos, lenguajes y estándares definidos por los organismos de
más prestigio a nivel internacional como lo son SEI, PMI, Rational e IEEE, lo que permite
entregar a los socios comerciales de la empresa, una herramienta tecnológica capaz de
facilitar satisfactoriamente la gestión de su operación en las áreas que más lo necesite.
Metodología de Implementación
La metodología de gestión de proyectos de BABEL, nace de la necesidad de una
organización formal (documentada) de su forma de
trabajar.
Tomando en cuenta el objetivo estratégico de la
compañía de certificarse en CMMI nivel 3, se ha afinado una metodología de gestión que
permita llegar a esa meta; además de utilizar CMMI como base de lo que se debe de tener

33
dentro de la metodología, se toma también como base los procedimientos formales y las
mejores prácticas del PMI, así como la forma de documentar usando UML y los formatos
estándar de IEEE e ISO.
Todas estas entradas generan una metodología de gestión de proyectos muy robusta, que
le permite a la empresa afianzar el éxito en los proyectos de software.
Metodología de Desarrollo de Software
La gestión de un proyecto de software requiere que exista un conocimiento por parte del
administrador del proyecto de cómo éste se desarrolla, ya que, aunque en BABEL no es el
caso, algunos administradores de proyecto pueden no ser del área informática.
Para afinar la metodología de desarrollo de software, la empresa utiliza el estándar de
desarrollo RUP, el cual estipula la creación del software en iteraciones que vayan
incrementando el valor del proyecto, es decir, que se creen piezas de software que se vayan
afinando e integrando para crear el sistema por completo.
Etapas
Fase inicio / conceptualización
Fase de planeación
Fase de ejecución
Fase de control
Fase de cierre

34
Ciclo de vida para el desarrollo de software
Figura 5. Ciclo de vida para el desarrollo de software de BABEL

35
La información es el activo más importante que tiene una
empresa; y el éxito de la misma depende de que tanto conozca
dicha empresa a su mercado. Por esto BABEL ofrece lo último
en tecnología para el uso estratégico y efectivo de la
información.
La Inteligencia de Negocios o Business Intelligence (BI) se puede
definir como la extracción y transformación de la información de una empresa de
sus distintas bases de datos, integrándola en una sola base de datos para que el
usuario genere sus propios reportes, pronósticos y estadísticas para identificar
comportamientos, tendencias y definir el rumbo de su negocio para el apoyo en
la toma de decisiones, representando una ventaja competitiva en el mercado.
Propuesta
En BABEL se sabe que cada negocio es diferente y tiene sus propias
características; por tal razón, los proyectos de Inteligencia de Negocios se
implementan “a la medida”. Así se cumple a cabalidad las necesidades del cliente,
asegurando la satisfacción con el resultado final.
Se cuenta con personal certificado internacionalmente, con alta capacidad de
análisis y experiencia en extracción e integración de datos para que estos puedan

36
combinarse correctamente y brindar a los socios comerciales la información que
realmente necesitan y en el momento oportuno.
Servicios de BI
Inteligencia de Negocios
Almacenes de Datos - Data Warehouse
Minería de Datos - Data Mining
Paneles de Informes Gerenciales - Dashboarding
Cuadros de Mando Integral - Balance Scorecard
Portales de Apoyo a la Toma de Decisiones - BI Porta
Desarrollo de Base de Datos
Migraciones a nuevas Tecnologías
Creación de Interfaces de Datos (ETL) en Integration Services
Soluciones de Reportería en Reporting Services
Reportes Demográficos
Administración de Base de Datos
Mantenimiento de Bases de Datos
Optimización de Bases de Datos

37
Ciclo de Vida de Un Proyecto de BI
Figura 6. Ciclo de vida para el desarrollo de BI de BABE
Arquitectura Data Warehouse
Herramientas del Usuario Final
Algunos Casos de Éxito
Figura 7. Arquitectura del Data Warehouse de BABEL

38
¿Qué son Métricas y Dimensiones?
En un proyecto de Business Intelligence,
hay dos conceptos que se mencionan
constantemente: Dimensiones y
Métricas. Según el software de Business
Intelligence que se utilice podrían variar
el nombre del término, pero el papel que
cumplen es el mismo: Ayudan a
responder las preguntas que tiene el
usuario.
Las Dimensiones (también llamada entidad, perspectiva, característica, dato
maestro, etc.). Son los grupos de datos que permiten identificar quién, cuándo o
dónde se genera una operación o transacción del negocio. Por ejemplo: Clientes,
proveedores, tiempo o lugar, son ejemplos de dimensiones típicas.
La agrupación de dimensiones según una relación de dependencia lógica, se le
denomina jerarquías. Tal es el caso del Tiempo: Año – Mes – Día.
Las Métricas (también llamados KPIs, Indicadores, Valores, etc.). Son los valores
numéricos generados en una o varias operaciones o transacciones de negocio.
Por ejemplo: Total ventas, total costes, total pagos. Ayudan a responder las
preguntas referidas a cantidades o importes.

39
Combinando adecuadamente las dimensiones y métricas, según las necesidades
de información que tenga el usuario, se podrá responder a sus interrogantes. Por
ejemplo, se podrían generar los siguientes informes: Ventas por cliente y meses,
Costes de producción por región, Facturación año actual vs. año anterior, etc.

40
En BABEL se solventa la necesidad de Outsourcing
(tercerización) de Servicios de Tecnología de la Información
que viven las empresas del mundo moderno. Se ofrece esta
solución cuando se requieren recursos capacitados, por un plazo
de tiempo determinado, con características técnicas específicas y
un alto grado de profesionalismo y compromiso para laborar en
sus instalaciones con el objetivo de establecer un conjunto integrado de
procesos que aseguren el éxito. Bajo el objetivo de satisfacer los requerimientos
de los usuarios y habilitar la optimización de los procesos del negocio.
Valor Agregado para los Clientes
Se provee al cliente del servicio de Outsourcing en desarrollo de software
e infraestructura, por medio de consultores que cuentan con un alto nivel de
conocimiento y certificaciones internacionales que garantizan dicho
conocimiento. Se brinda garantía de experticia y calidad, lo que implica que el
consultor que se le asigna satisface sus expectativas, y en el caso de que no sea
así, el cliente cuenta con la opción de reemplazarlo por un nuevo consultor que
se ajuste a sus requerimientos.

41
¿Cómo se cobra?
Se presenta la modalidad de cobro por tarifa mensual y tarifa por hora.
Además, en casos en los que el período de contratación sea mayor a seis
meses, se ofrecen tarifas especiales.
Actualmente BABEL cuenta con los siguientes perfiles profesionales:
Especialista de Producto: Profesional en Tecnologías de Información con más
de cinco años de experiencia en desarrollo de software. Alto nivel de conocimiento
en lenguajes y herramientas de programación, apto para realizar tareas de
administración de proyectos y liderar técnicamente equipos de trabajo.
Consultor Senior: Profesional en Tecnologías de Información con más de tres
años de experiencia en desarrollo de software. Alto nivel de conocimiento en
lenguajes y herramientas de programación, apto para liderar técnicamente equipos
de trabajo y proponer soluciones de desarrollo y programación.
Consultor Avanzado: Profesional en Tecnologías de Información con más de dos
años de experiencia en desarrollo de software. Alto nivel de conocimiento en
lenguajes y herramientas de programación, apto para cumplir con tareas de
desarrollo y programación eficazmente.

42
Ciclo de Vida del Outsourcing
Figura 8. Ciclo de vida del Outsourcing
Ventajas de la Contratación Externa de Servicios de TI
Opción de controlar y reducir costos operativos: esto le permite reorientar
capital hacia áreas esenciales de la organización, razones:
Ahorro en proceso de reclutamiento y selección: al delegar la tarea de
reclutamiento y selección en manos de expertos.
Eliminación de responsabilidad patronal: como cargas sociales,
seguros, vacaciones, incapacidades, aguinaldo, cesantía, tiempos ociosos,
entre otros.
Acceso a la tecnología más reciente y experiencia de clase mundial sin
inversión de capital, ni formación de personal: dado que se pone a su
disposición consultores que han trabajado con empresas con necesidades
similares, por lo que la inversión corresponde a la empresa proveedora del
Outsourcing. Esto involucra acceso a las diferentes habilidades, destrezas y
tecnologías como sean necesarias. Los proveedores del servicio de
Outsourcing de Tecnologías de la Información (TI) pueden rápida y fácilmente

43
actualizar la infraestructura en respuesta a las necesidades cambiantes del
negocio así como migración de tecnologías y reducir los riesgos de fallas en el
intento. Esto representa una ventaja competitiva que ayuda a evitar el costo de
adaptarse a los constantes cambios en tecnología y formación de personal.
Reducir las cargas de trabajo, y carga administrativa: mientras se retiene el
control de la toma de decisiones.
Posibilidad de contar con personal temporal y de prueba.
Flexibilidad: para aumentar o disminuir su plantilla laboral.
Apoyo en la elaboración del perfil del puesto.
Mejora el profesionalismo de los servicios: al brindar mejor desempeño,
reducción y en algunos casos hasta eliminación de los errores operacionales e
ineficiencias son unas de las más importantes ventajas del outsourcing.
Ganancia y transferencia de conocimientos y experticia: a los funcionarios
de la institución contratante, pues se garantiza que el profesional es experto en
las funciones para las que es contratado.
Puede utilizar sus recursos internos en otras áreas y con ello la posibilidad de
liberarlos y orientarlos a la dirección de su negocio, al mejoramiento de
procesos y servicios, etc.
Ahorro de tiempo: es decir, mejoramiento de la velocidad de desarrollo; pues
el desarrollo interno se ve interferido por varios factores incluyendo la falta de
personal, falta de experiencia, competencia con otros proyectos internos, y por
estar en varias tareas al mismo tiempo.
Disminución o eliminación de auditorías y demandas laborales.

44
Sofware Factory es un modelo de servicios apoyado en una estrategia
metodológica que ha madurado en los últimos años en el mundo de la
informática. Esta forma de trabajo es una analogía de los procesos de
producción industriales. La misma permite reducir considerablemente la
incertidumbre en el desarrollo y mantenimiento de proyectos de software y
ofrece una serie de beneficios directos sobre la confiabilidad y nivel de
satisfacción de los productos entregados.
Aplica las técnicas de fabricación y principios de desarrollo de software para
imitar los beneficios de la fabricación tradicional.
BABEL ofrece una solución alternativa al Outsourcing, con
dos particularidades: que se conforman equipos completos
de trabajo, y que el trabajo se realiza en las instalaciones de
BABEL, ya sea en Costa Rica (San José y Pérez Zeledón) o
en Ecuador, lo que representa un ahorro adicional en cuanto
a infraestructura para nuestros socios comerciales.
Características Generales
No se negocia con el usuario final, sino con un intermediario.
No se instala el producto, por lo tanto se puede o no generar el instalador.
Los clientes son principalmente otras empresas desarrolladoras de
software.
Se ayuda a otros clientes a terminar un producto parcial o totalmente.
Se desarrolla desde BABEL.

45
Ventajas
Proporciona una mayor claridad presupuestaria.
Un calendario acotado de los requerimientos de mantenimiento, consultas,
requerimientos de información e incidencias asociados a las aplicaciones
productivas de la empresa.
Ciclo de Vida de Software Factory
Figura 9. Ciclo de vida del Software Factory

46
Metodologías Agiles
Características del Extreme Programming
Pensada para proyectos cortos con requerimientos
muy cambiantes o poco claros.
Apunta a una alta integración con el usuario.
Orientando todo a las pruebas.
Se planifica a muy corto plazo (3 a 4 semanas máximo).
Se realizan reuniones informales todos los días por la mañana para
intercambiar experiencias.
Aplicable en cualquier rama de mercado y ciencia.
Beneficios del Extreme Programming
El cliente tiene el control sobre las prioridades.
Busca ofrecer muchas entregas de un sistema, agregando funcionalidad
paulatinamente en lapsos cortos lo que provoca menor taza de errores.
Se hacen pruebas continuas durante el proyecto.
La metodología XP es más utilizada para la implementación de nuevas
tecnologías donde los requerimientos cambian rápidamente.

47
BABEL brinda el servicio de dar mantenimiento a proyectos de
software desarrollados con antelación por BABEL o por empresas colegas.
Incluye el monitoreo, la evaluación, la adecuación y hasta la
corrección de aplicaciones con las que el cliente contaba
previamente.
Para esto cuenta con un equipo humano especializado,
con conocimientos en diversas tecnologías, en constante
capacitación y con certificaciones internacionales que los acreditan, lo que
permite brindarles a los socios comerciales un tiempo de respuesta ágil tanto en
aplicaciones desarrolladas en tecnologías emergentes como en las más
consolidadas.
Servicios de Soporte de Aplicaciones
Soporte por Demanda:
Se atienden incidentes o errores de máxima urgencia en aplicaciones
claves que se encuentran en producción, con disponibilidad inmediata.
Bajo cualquier esquema.
Los profesionales asisten al sitio o trabajan remotamente.
Desarrollo de Mejoras: Si el cliente es dueño del código fuente de sus
sistemas, BABEL puede realizar cualquier cambio que desee, para mejorar el
rendimiento o agregar funcionalidades requeridas al mismo.

48
Ejecución de Garantías: Un miembro del equipo siempre está presente en el
ciclo de vida de los proyectos a la medida, por lo cual en la etapa de garantía
es capaz de solucionar de manera rápida y ágil cualquier detalle que aparezca
en el período de garantía.
BABEL diagnostica y optimiza el uso de la plataforma informática y de
comunicaciones de sus clientes, propiciando un uso más
eficiente de los recursos. Para ello provee de consultores de TI
que se ajustan a los requerimientos del cliente y que conocen la
situación tanto del mercado local como global.
Los Servicios de Consultoría y el Soporte Técnico de
BABEL le ayudan a sus clientes a definir las mejores opciones tecnológicas para
su empresa y a solucionar cualquier incidencia que pueda surgir en su entorno
tecnológico.
Los Servicios de Soporte de BABEL sirven para que todos los clientes de la
empresa obtengan más éxito con los productos adquiridos y se implementan de
tal manera que sean aprovechados de manera eficiente. El personal está
capacitado para solventar las necesidades básicas de soporte para todo tipo de
empresa, con un alto grado de profesionalismo para brindar servicio de calidad.
Se ofrece el mantenimiento preventivo y correctivo para la infraestructura
tecnológica de los clientes, así como planificación e instalación de todo tipo de

49
dispositivos informáticos, cableado estructurado y demás componentes
asociados.
Funciones
Diagnóstico de equipo actual.
Compra e implementación de equipo nuevo.
Coordinación de proyectos y apoyo de los mismos en la parte técnica.
Optimización de redes informáticas y todos sus servicios.
Configuración de controladores de dominio.
Administración de políticas de dominio.
Administración de Active Directory, con unidades organizativas y respectivos
grupos de seguridad global.
Administración de sitios web y hosting de correo electrónico.
Administración de correo a nivel de aplicaciones web.
Administración de la base de datos de sistema de producción y sistemas de
pruebas.
Administración del servidor de archivos con la información de todos los
funcionarios archivos planos, instaladores y respaldos.
Administración de los protocolos de red básicos, como DHCP, DNS, TCP/IP.
Administración de Redes de Categoría 5, cableado, ponchado y toda la
administración.
Administración de la red inalámbrica.
Soporte técnico a todas las terminales de la red, incluyendo instalación de
sistemas operativos, configuración y soporte de cada una de las aplicaciones
que se utilicen.
Velar por el buen funcionamiento de los enlaces dedicados de la red, a través
de ISA por medio de enlaces VPN.

50
Administración de los servidores de Remote Desktop Connection a través de
los clientes de RDP o terminal services, para trabajos de aplicaciones en
segundo plano.

51
Principales Clientes de BABEL 2
Figura 10. Principales clientes de BABEL
2 Todos los logotipos son propiedad exclusiva de las correspondientes empresas representadas y se utilizan en este documento
únicamente de manera ilustrativa, con el único objetivo de referirse a cada empresa por medio de su logotipo.

52
3. MARCO METODOLOGICO
La siguiente sección corresponde a los pasos que se seguirán para realizar la
investigación y análisis del presente estudio. Se exponen las técnicas, fuentes y
procedimientos que serán de vital ayuda para la investigación del desarrollo del
sistema.
3.1. Fuentes de información
Podemos entender como fuentes de información todo aquello que nos sirva
de instrumento (así como documentos, personas, documentales, entre otros) que
nos ayuden a satisfacer la demanda de información necesaria para poder
desarrollar la investigación. Estas fuentes de información pueden ser primarias o
secundarias. Para esta investigación se utilizarán las que a continuación se
describen:
3.1.1. Fuentes Primeras
Se puede considerar una fuente primaria a toda aquella información que
viene a aportar material de primera mano relativo a un fenómeno que se desea
investigar, donde se encuentran los datos requeridos, que posteriormente se
pueden convertir en información útil para el investigador. Los datos son todos
aquellos fundamentos o antecedentes que se requieren para llegar al
conocimiento exacto de un objeto de estudio. Estos datos, que se deben recopilar
de las fuentes, tendrán que ser suficientes para poder sustentar y defender un
trabajo (Eyssautier, 2002).

53
Y para los fines de esta investigación se utilizarán las siguientes fuentes
primarias de información:
Entrevistas con los gerentes administrativos
Entrevistas con los gerentes de proyectos
Entrevistas con el gerente de control de calidad
Entrevistas con el equipo de desarrollo
3.1.2. Fuentes Secundarias
Las fuentes secundarias son aquellas fuentes de información que se basan
en las fuentes primarias, ya que estas interpretan, analizan y hacen reseñas de las
primarias; estas fuentes nos ofrecen cosas como: brindar a los lectores una
síntesis de la información que existe en las fuentes primarias sobre temas de
interés; y, remitir a los usuarios los documentos cuyos contenidos puedan ayudar
a solucionar sus necesidades de información, como por ejemplo lo son: libros de
texto, artículos de revistas, crítica literaria y comentarios, enciclopedias, biografías,
diccionarios, resúmenes, normas, patentes (Aróstegui).
Y para los fines de esta investigación se utilizaran las siguientes fuentes
secundarias de información:
Metodología de gestión de proyectos de BABEL
Guía de los fundamentos para la dirección de proyectos (PMBOK)
Administración profesional de proyectos
Estándares de desarrollo de Microsoft
Reportes de rendimiento de personal de años pasados
Reporte de inconsistencias en proyectos de años pasados

54
3.2. Técnicas de Investigación
Para cumplir con los objetivos de esta investigación y con base en las fuentes de
información antes mencionadas se manejarán las siguientes técnicas de
investigación:
• La observación ya que se atenderá, día a día, la organización para obtener la
información y registrarla para su posterior análisis (Ortíz Rida, Pilar María). Se
utilizarán los siguientes tipos:
Observación directa: para determinar las verdaderas necesidades de la
empresa, en un hacer de día a día de la empresa.
Observación no participante: se recogerá la información desde afuera,
sin interrumpir el día a día de la organización.
Observación no estructurada: ya que se realizará sin ayuda de
elementos técnicos especiales.
Observación de campo: es decir, se realizará en el lugar donde ocurren
los hechos.
Observación de equipo: realizada por los sustentantes de esta
investigación.
• La entrevista, ya que parte de la información de la investigación se obtendrá
mediante los diálogos entre los sustentantes y las personas de la organización
donde surge la necesidad de este sistema, recopilando los cargos y analizando
sus con el objetivo tomarlos como referencia y lecciones aprendidas para la

55
elaboración de los planes de los objetivos de este proyecto (Ortíz Rida, Pilar
María).
• Investigación documental, esto porque se utilizarán diferentes documentos
propios de la empresa, así como estándares internacionales que
fundamentarán y complementarán este trabajo, y así poder extraer información
significativa que ayudará a lograr el cumplimiento de los objetivos propuestos
(Ortíz Rida, Pilar María).
3.3. Método de Investigación
Para esta investigación se utilizará el método de investigación “analítico –
sintético”, el cual consiste en “la separación de las partes de un todo para
estudiarlas en forma individual (análisis) y la reunión racional de elementos
dispersos para estudiarlos en su totalidad (síntesis)” (Eyssautier, 2002).
Por lo tanto, esta investigación se basa en el estudio de las fuentes de datos e
información recopilada, identificando los elementos requeridos para lograr con
éxito los objetivos del proyecto, que se traducen en el desarrollo del plan de
gestión del proyecto, el cual contempla las áreas de conocimiento de: alcance,
tiempo, recursos humanos y comunicaciones.
Asimismo, se hará uso del método de observación por entrevista, en forma
dirigida, la cual ”puede definirse como una entrevista cara a cara, donde el
entrevistador pregunta al entrevistado y recibe de éste las respuestas pertinentes
a las hipótesis de la investigación. Las preguntas y su secuenciación marcarán el
grado de estructuración del cuestionario, objeto de la entrevista” (Frida Ortiz,

56
María Pilar García), esto con el fin de recolectar información de interés y requerida
para el alcanzar los objetivos de este proyecto.

57
3.4. Marco Metodológico del Proyecto según los objetivos planteados
Objetivo: Contar con una herramienta que permita efectuar un análisis del
rendimiento e índices de retrabajo de los miembros de proyectos, en todos los
proyectos en general, sin limitarse a un análisis para un proyecto específico.
Cuadro 1. Marco metodológico para el objetivo de contar con una nueva
herramienta del proyecto SAPRE
Fuentes de información
Herramientas
Primarias Secundarias Entrevistas
Bases de Información Entregables
Datos Histórica
Se
Se Se
Gerente de
entrevistará analizarán analizarán
Desarrollo a
a los los los reportes
la Medida
gerentes actuales antiguos
Metodología involucrados, repositorios para
Gerente de
de Gestión para de datos determinar
Calidad
de Proyectos determinar con que qué datos
las
cuenta la aún son
Gerentes de
Reportes de dimensiones empresa. importantes
Proyectos
personal de y las
para las
años métricas que
distintas
pasados se necesitan.
áreas.
Gerentes de
control de
calidad
1. Documento
de análisis
técnico donde
se identifiquen
las
dimensiones y
las métricas
que se
desean
analizar en
cada
Gerencia, con
la creación de
la herramienta
de Inteligencia
de Negocios.
Objetivo: Generar activos de procesos de la organización, basados en
estadísticas generales de rendimiento por persona, por etapa del proceso y por
fechas.

58
Cuadro 2, Marco metodológico para el objetivo de generar activos de procesos del
proyecto SAPRE
Fuentes de información Herramientas Entregables
Secundaria Entrevista Bases de Información
Primarias
Gerente de
Desarrollo a
la Medida
Gerente de
Calidad
Gerentes de
Proyectos
s
Metodología
de gestión
de
proyectos
Guía de los
fundamento
s para la
dirección de
proyectos
(PMBOK)
Administraci
ón
profesional
de
proyectos
Reportes de
personal de
años
pasados
s
Se
entrevistará
a los
gerentes
involucrado
s para
identificar
los activos
de
procesos
con que la
empresa
cuenta.
Datos
Se
diseñarán
nuevos
repositorios
de datos
para un
análisis
global de
los
proyectos.
Histórica
Se
diseñarán
indicadores
de
rendimiento
por proyecto
y globales
para todos
los
proyectos.
1. Documento
donde se
identificarán
los indicadores
que se desean
evaluar en la
herramienta.
2. Documento
de Diseño de
los reportes
que mostrarán
los indicadores
a manera de
Dashboard
con la
información de
todos los
proyectos.
Objetivo: Brindar retroalimentación a los miembros de los equipos de proyectos
en la etapa de cierre, a finn de mejorar su rendimiento tanto en el proyecto que
cierra como en su historial de proyectos en la empresa.

59
Cuadro 3. Marco metodológico para el objetivo de brindar retroalimentación del
Gerente de
Desarrollo a
la Medida
Gerente de
Calidad
Gerentes de
control de
calidad
proyecto SAPRE
Fuentes de información Herramientas Entregables
Secundaria Entrevista Bases de Información
Primarias
s
s Datos Histórica
Estándares
de
desarrollo
de Microsoft
Metodología
de gestión
de
proyectos
Reportes de
personal de
años
pasados
Reporte de
inconsistenc
ias de
personal de
años
pasados
Se
entrevistará
tanto a los
gerentes
involucrado
s, como a
los
miembros
de los
equipos
para
identificar
los
conceptos
claves en
que debe
ser
retroaliment
ado cada
integrante
del equipo.
Se
desarrollará
n procesos
de carga
diaria de
históricos
de datos
para poder
brindar la
información
por medio
de los
indicadores
que se
definan.
Todos los
días se
harán cargas
nocturnas de
datos de los
nuevos
proyectos en
la nueva
Base de
Datos para
acumular
información
histórica que
permita
sacar
estadísticas
con la nueva
herramienta
de
Inteligencia
de Negocios.
1. Diseño de
un
procedimiento
de cierre de
proyectos,
basado en PMI
y donde se
incluya la
información
que se podrá
obtener de la
herramienta de
Inteligencia de
Negocios.

60
4. DESARROLLO
4.1. Análisis del sistema actual
En la actualidad, el departamento de Control de Calidad de la empresa
cuenta con sistemas de información transaccionales que le permiten registrar los
problemas que se detectan durante las distintas etapas del proceso de desarrollo
del software y asociarlos a los requerimientos del cliente. Estos sistemas también
le permiten al departamento de Calidad darle seguimiento a estos incidentes,
implementando una trazabilidad desde que se abren los incidentes hasta que se
cierran.
Los sistemas se denominan AdIntra-InSpec y BugTracking. El primero
permite registrar los requerimientos del cliente para un proyecto determinado, de
manera que se especifique correctamente la funcionalidad de cada módulo del
sistema. El BugTracking por su lado permite registrar una “pulga” o incidente que
ha sido identificado durante la etapa de validación, asociándolo directamente a un
requerimiento del sistema que se está testeando. A continuación se describirá la
funcionalidad de cada sistema de manera general, con la intensión de presentar al
lector una visión del alcance funcional de cada uno de los sistemas existentes.
4.1.1. AdIntra-InSpec
A continuación se describen todas las funcionalidades del sistema AdIntra-
InSpec para que el lector pueda apreciar al ambito de esta aplicación, así como
sus restricciones, las cuales se pretenden resolver con la implementación del
Cubo de Información SAPRE.

61
4.1.1.1. Login
Figura 11. Pantalla de Login de Adintra
4.1.1.2. Ingreso al sistema
Una vez ingresado al sistema se muestran todas las carpetas que representan los
proyectos en forma de árbol.

62
Figura 12. Pantalla de ingreso al sistema de Adintra
4.1.1.3. Manejo de árbol de carpetas- Jerarquía: Proyecto-Módulo-
Requerimiento-CU-Caso Prueba-Escenarios de prueba
Para ilustrar mejor el árbol de manejo del sistema, se presenta un proyecto
expandido (en este caso el proyecto ejemplo será Bug Tracker), y se identifica
jerárquicamente que todo Proyecto está distribuido por Módulos, cada módulo
contiene Requerimientos (en verde), cada requerimiento tiene asociados Casos
de Uso (rosado), cada caso de Uso tiene Casos de Prueba (en morado) y cada
casos de prueba se le asocia Escenarios de Prueba.

63
Figura 13. Árbol de carpetas de Adintra
Para agregar cualquier objeto(Módulo, Requerimiento, Caso de Uso, Caso de
Prueba, Escenario), debe situarse sobre la carpeta correspondiente y dar click
derecho y seleccionar en el menu la opción “New” y agregar el objeto que desee.

64
Figura 14. Menú de opciones de Adintra
4.1.1.4. Jerarquía: Proyecto-Módulo
Figura 15. Jerarquía de Proyecto-Módulo de Adintra
4.1.1.4.1. Crear Proyecto
A continuación se presenta la forma de crear un proyecto, donde se debe llenar el
“Nombre” y si fuese necesaria una descripción.

65
Figura 16. Pantalla de creación de proyecto de Adintra
4.1.1.4.2. Crear Módulo
A continuación se presenta la forma de crear un módulo, donde se debe llenar el
“Nombre” y si fuese necesaria una descripción.
Figura 17. Pantalla de creación de módulo de Adintra

66
4.1.1.5. Jerarquía: Proyecto-Módulo-Requerimiento
Figura 18. Pantalla de jerarquía de Proyecto-Módulo-Requerimiento de Adintra
4.1.1.5.1. Crear Requerimiento
A continuación se presenta la forma de crear un Requerimiento, donde se debe
llenar el “Nombre” y si fuese necesaria una descripción.
Figura 19. Pantalla de creación de requerimiento de Adintra

67
4.1.1.6. Jerarquía: Proyecto-Módulo-Requerimiento-CasoUso
Figura 20. Pantalla de jerarquía de proyecto-Módulo-Requerimiento-CasoUso de
Adintra
4.1.1.6.1. Crear Caso de Uso
A continuación se presenta la forma de crear un Caso de Uso, donde se debe
llenar el “Nombre” y si fuese necesaria una descripción, además existen otros
“Tabs” para agregar archivos o vincular el Caso de Uso.

68
Figura 21. Pantalla de creación del caso de uso de Adintra
4.1.1.7. Jerarquía: Proyecto-Módulo-Requerimiento-CasoUso-Caso
Prueba
Figura 22. Estructura de Proyecto-Módulo-Requerimiento-CasoUso-CasoPrueba
de Adintra

69
4.1.1.7.1. Crear Caso de Prueba
A continuación se presenta la forma de crear un Caso de Prueba, donde se debe
llenar el “Nombre” y si fuese necesaria una descripción.
Figura 23, Pantalla de creación de caso de prueba de Adintra

70
4.1.1.8. Jerarquía: Proyecto-Módulo-Requerimiento-CU-Caso Prueba-
Escenarios de prueba
Figura 24. Estructura de Proyecto-Módulo-Requerimiento-CasoUso-CasoPrueba-
EscenarioPrueba de Adintra
4.1.1.8.1. Crear Escenario de Prueba
A continuación se presenta la forma de crear un Escenario de Prueba, donde se
debe llenar el “Nombre”, en el Tab Description, se debe agregar la descripción de
la prueba.

71
Figura 25. Creación del escenario de prueba (tab de Descripción) de Adintra
En el Tab Requeriments, se debe agregar los requisitos para ejecutar la prueba.

72
Figura 26. Creación del escenario de prueba (tab de Requerimientos) de Adintra
En el Tab Procedure, se debe agregar los pasos para ejecutar la prueba.

73
Figura 27. Creación del escenario de prueba (tab de Procedimiento) de Adintra
En el Tab Results, se debe agregar el resultado esperado para ejecutar la prueba.

74
Figura 28. Creación del escenario de prueba (tab de Resultados) de Adintra
En el Tab Attachs, se debe agregar imágenes o archivos asociados con la
prueba.
Figura 29. Creación del escenario de prueba (tab de Archivos adjuntos) de Adintra

75
4.1.2. BugTracking
A continuación se describen todas las funcionalidades del sistema
BugTracking para que el lector pueda apreciar al ámbito de esta aplicación, así
como sus restricciones, las cuales se pretenden resolver con la implementación
del Cubo de Información SAPRE.
Este sistema fue desarrollado por BABEL y se integra al sistema AdIntra-
InSpec para relacionar los incidentes o pulgas a los requerimientos que en ése
sistema fueron definidos.
4.1.2.1. Ingresar al sistema
Para ingresar al sistema, se debe disponer un nombre de usuario y password
registrados en el sistema.
Figura 30. Pantalla de ingreso al sistema de Bug Tracking

76
Al ingresar al sistema se muestra la siguiente pantalla de inicio.
Figura 31. Pantalla inicial del sistema de Bug Tracking

77
4.1.2.2. Inconsistencias del sistema (Pulgas)
4.1.2.2.1. Crear pulga
Al hacer clic en el ícono de “Pulga nueva” se abre la siguiente pantalla de consulta
de pulgas, donde se presenta la opción de nueva pulga “New”
Figura 32. Pantalla de consulta de pulgas de Bug Tracking
Al presionar el botón “Nuevo” se abre la siguiente pantalla donde se presenta los
campos para registrar una pulga nueva.

78
Figura 33. Pantalla de “Nueva pulga” de Bug Tracking
Para crear una pulga nueva se deben llenar todos los campos y asignar un usuario
con permisos de supervisor, como se muestra en la siguiente pantalla, y presionar
el botón “Save”.

79
Figura 34. Pantalla de pulga nueva con los campos ingresados de Bug Tracking
Al crear la pulga, ésta se muestra en la pantalla de consulta de pulgas,
asignada al usuario seleccionado, como se muestra en la figura siguiente.

80
Figura 35. Pantalla de consulta de pulgas de Bug Tracking
4.1.2.2.2. Asignar una pulga nueva a un Desarrollador
En la pantalla de consulta de pulgas, seleccionar la pulga nueva a asignar
haciendo clic en el ícono “Modificar” correspondiente.

81
Figura 36. Pantalla de consulta de pulgas de Bug Tracking
Al hacer clic en consultar la pulga nueva se abre la pantalla de modificar pulga,
donde los únicos cambios que se pueden hacer son: el status de la pulga a
“Asignada”, el usuario al que se le asigna y agregar descripciones, como se ilustra
a continuación.
Figura 37. Pantalla de “Modificar Pulga” de Bug Tracking
Al hacer clic en el botón “Change” para cambiar el estado de una pulga, se abre
una sub-pantalla donde se debe seleccionar el nuevo estatus de “Assigned” en el
campo “New Status”.

82
Figura 38. Sub-Pantalla de “Modificar Estado de la Pulga” de Bug Tracking
Al hacer clic en guardar cambios, el sistema registra los cambios y muestra la
pulga asignada al usuario seleccionado y con el estatus de “Asignada”:
Figura 39. Pantalla de “Consulta de Pulgas” de Bug Tracking

83
4.1.2.2.3. Cambiar estatus de pulga a “Corregida”
Seleccionar una pulga asignada y hacer clisc en el ícono de “Modificar pulga”
Figura 40, Pantalla de “Consulta de Pulgas” de Bug Tracking
Se abre la pantalla de modificar pulga, donde el único cambio que permite el
sistema es Modificar el estatatus a “Corregida”. Para cambiar el estatus de la
pulga hacer clic en “Change” y cambiar el estatus.

84
Figura 41. Pantalla de “Modificar Pulga” de Bug Tracking
Al hacer clic en el botón “Change” para cambiar el estado de una pulga, se abre
una sub-pantalla donde se debe seleccionar el nuevo estatus de “Corrected” en el
campo “New Status”.
Figura 42. Sub-Pantalla de “Modificar estado de la Pulga” de Bug Tracking

85
4.1.2.2.4. Cambiar estatus de pulga a “Verificada o Re-Abierta”
Seleccionar una pulga con estatus de corregida y hacer clic en el ícono de
“Modificar pulga”
Figura 43. Pantalla de “Consulta de Pulga” de Bug Tracking
Se abre la pantalla de modificar pulga, donde el único cambio que permite el
sistema es Modificar el estatus a “Verificada” o “Corregida”. Para cambiar el
estatus de la pulga se debe hacer clic en “Change” y cambiar el estatus.

86
Figura 44. Pantalla de “Modificar Pulga” de Bug Tracking
Al hacer clic en el botón “Change” para cambiar el estado de una pulga, se abre
una sub-pantalla donde se debe seleccionar el nuevo estatus de “Verified” o “Re-
Open” en el campo “New Status”.

87
Figura 45. Sub-Pantalla de “Modificar estado de la Pulga” de Bug Tracking
4.1.2.3. Consultar eficiencia de corrección de pulgas
Al hacer clic en el botón de consulta de requerimientos asignados se abre la
siguiente pantalla:
Figura 46. Pantalla inicial de “Consulta de Requerimientos Asignados” de Bug
Tracking
Para hacer una consulta a un sistema específico, se debe seleccionar el proyecto
correspondiente la lista desplegable y luego seleccionar el módulo a consultar en
la lista de módulos.

88
Figura 47. Pantalla de “Consulta de Requerimientos Asignados” de Bug Tracking
El sistema muestra el nombre del requerimiento a corregir, a quién fue asignado, y
las estadísticas de esfuerzo estimado de corrección, esfuerzo real en corregir la
pulga y los porcentajes correspondientes.

89
Figura 48. Pantalla de “Consulta de Requerimientos Asignados” de Bug Tracking
4.1.2.4. Asignar un requerimiento a un usuario
Para asignar un requerimiento a un usuario, hacer clic en el ícono “Assign
Requirement to User” y el sistema muestra la pantalla correspondiente.
Figura 49. Pantalla de “Asignar Requerimientos” de Bug Tracking
Para asignar un requerimiento a un usuario, se debe seleccionar de la lista
desplegable el proyecto correspondiente para que el sistema muestre los módulos
del proyecto. Luego seleccionar un módulo para que el sistema muestre los
requerimientos del módulo (El sistema muestra resaltado en azul los

90
requerimientos ya asignados). Seleccionar el usuario correspondiente y asignar el
esfuerzo estimado y el esfuerzo real y presionar el botón “Assing”.
Figura 50. Pantalla de “Asignar Requerimientos” de Bug Tracking
4.1.2.5. Configurar versión de revisión de proyecto
Para configurar una revisión de un proyecto, hacer clic en el ícono “Configuration”
para abrir la pantalla correspondiente.

91
Figura 51. Pantalla de “Configuración de Versión de Revisión de Proyectos” de
Bug Tracking
Para configurar la versión de una revisión, seleccionar el proyecto correspondiente
de la lista desplegable.
Figura 52. Pantalla de “Configuración de Versiones – Seleccionar Proyecto” de
Bug Tracking

92
El sistema muestra las versionas cargadas para el proyecto seleccionado.
Figura 53. Pantalla de “Configuración de Versiones” de Bug Tracking
Para crear una nueva versión, se debe ingresar el nombre de la versión y
presionar el botón “New”. Para modificar una versión existente, se debe
seleccionar la versión correspondiente, ingresar el nuevo nombre y presionar el
botón “Update”.

93
Figura 54. Pantalla de “Configuración de Versiones – Crear una nueva versión” de
Bug Tracking
El sistema muestra la nueva versión creada.
Figura 55. Pantalla de “Configuración de Versiones – Nueva versión creada” de
Bug Tracking

94
4.1.2.6. Gestionar Prioridades y Severidades
El sistema permite agregar prioridades y severidades para que estén disponibles
al crear una pulga. Para agregar una nueva prioridad, se debe entrar en la pestaña
“Misc. Tables”.
Figura 56. Pantalla “Misc. Tables” de Bug Tracking
Para crear una nueva prioridad o una nueva severidad, activar la casilla
correspondiente, en el campo “Name” ingresar el nombre nuevo y presionar el
botón “New”.

95
Figura 57. Pantalla “Misc. Tables – Crear una nueva prioridad o severidad” de Bug
Tracking
El sistema muestra la nueva prioridad o severidad y aparecen disponibles al crear
una pulga nueva.

96
Figura 58. Pantalla “Misc. Tables – Prioridad o severidad creada” de Bug Tracking
4.1.2.7. Consultar Proyectos
Para consultar los siglos de vida de una inconsistencia (Pulga) en un proyecto,
hacer clic en el ícono “Review Bug Correction Time” y el sistema muestra la
siguiente pantalla.

97
Figura 59. Pantalla de “Consulta de tiempos de corrección de pulgas” de Bug
Tracking
Para consultar un proyecto en específico, se debe seleccionar en los campos de
filtros disponibles y presionar el botón “Search”.

98
Figura 60. Pantalla de “Consulta de tiempos de corrección de pulgas” de Bug
Tracking
El sistema muestra la lista de inconsistencias según los filtros seleccionados. Para
consultar una pulga específica, hacer clic en el ícono de consulta correspondiente.
Figura 61. Pantalla de “Consulta de tiempos de corrección de pulgas” de Bug
Tracking

99
Al hacer clic en consultar la pulga, se abre la sub-pantalla de tiempos de la
inconsistencia seleccionada.
Figura 62. Sub-Pantalla de “Historial de tiempos de corrección de pulgas” de Bug
Tracking
4.1.2.8. Usuarios y Seguridad
El sistema permite crear nuevos usuarios y asignarlos en grupos con permisos
establecidos. Para ingresar hay hacer clic en el ícono “User and Security”.

100
Figura 63. Pantalla “User and Security” de Bug Tracking
4.1.2.8.1. Crear nuevo usuario
Para crear un nuevo usuario, se debe ingresar a la pestaña “User”, ingresar el
nombre de usuario nuevo en el campo “Login”, activar la casilla “Active” y
presionar el botón “New”.

101
Figura 64. Pantalla “User and Security – Pestaña Users” de Bug Tracking
4.1.2.8.2. Crear nuevo grupo
Para crear un nuevo Grupo, se debe ingresar a la pestaña “User Groups”, ingresar
el nombre de grupo nuevo en el campo “Group Name” y presionar el botón “New”.
Figura 65. Pantalla “User and Security – Pestaña User Groups” de Bug Tracking

102
4.1.2.8.3. Agregar un usuario a un grupo
En la pestaña “User Groups” se debe seleccionar el grupo correspondiente, en la
sub-pestaña “Users In Group”, seleccionar el usuario requerido de la lista de
usuarios a la derecha de la pantalla y presionar el botón “

Figura 67. Pantalla “User and Security – Pestaña User Groups” de Bug Tracking
103

104
4.1.3. Análisis de la situación actual
Pese a que la empresa ha tenido un avance significativo en la
automatización de los procesos de Control de Calidad en el ciclo de desarrollo del
software, pasando de lo manual a métodos estandarizados y automatizados, se ha
vuelto indispensable dar un nuevo paso en el análisis de la información que los
sistemas van almacenando, acorde a las nuevas necesidades del mundo
globalizado. Es decir, ya no basta con almacenar los datos de las revisiones y
asegurarse de que un sistema haya sido testeado y depurado antes de enviarlo al
cliente, sino que surge la necesidad de analizar qué es lo que se está haciendo de
manera incorrecta para corregirlo.
Con fundamento en lo anterior y a los distintos métodos de observación
utilizados y a las mismas entrevistas a personajes claves, a continuación se
detallan algunos de los problemas que han sido identificados por las Gerencias de
Desarrollo, Calidad y Proyectos, relacionados con el impacto del retrabajo en el
rendimiento y la productividad de cada uno de los miembros del equipo de trabajo
y por ende, del proyecto en si.
4.1.3.1. Problema 1: Análisis Individual de Proyectos
Como se puede apreciar, ambos sistemas (AdIntra-InSpec y BugTracking)
se complementan para llevar a cabo un control de los requerimientos y de las
pulgas que cada sistema desarrolla de manera individual. Aquí se identifica el
primer problema, al limitarse a tener que realizar el análisis de rendimiento para
únicamente un sistema específico a la vez y no poder analizar varios sistemas al
mismo tiempo, o realizar el análisis por persona o por períodos de tiempo.

105
Nace entonces la necesidad de una herramienta que permita analizar varios
proyectos simultáneamente, para contar con una fuente de información mucho
mayor que simplemente las actividades desarrolladas hasta el momento para un
proyecto específico.
4.1.3.2. Problema 2: Desconocimiento del rendimiento de los
miembros de los equipos de trabajo en el tiempo
Esto se torna problemático dado que, en ocasiones, los proyectos de
desarrollo de software se recargan sobre personas técnicamente más capaces o
con menor incidencia de errores que otros y, al finalizar el proyecto, si estas
situaciones no se han identificado, se suele felicitar o reprochar todos los errores
al equipo en general, generando resentimientos en estas personas que resultan
alltamente positivas de la curva normal del rendimiento de los miembros del
equipo de proyecto.
Para solventar esta problemática, se requiere de una herramienta que
permita identificar el rendimiento individual. En el desarrollo de software, el
rendimiento de un programador se puede medir por la cantidad de pulgas que
produjo por requerimiento o por el tiempo que requirió para corregir un error, en
relación con el tiempo que tardó en desarrollar la funcionalidad por primera vez.

106
4.1.3.3. Problema 3: Patrones de comportamiento
Hay que tener siempre en cuenta que en los proyectos de desarrollo de
software, la mano de obra está constituida por personas profesionales y la materia
prima la componen sus ideas, análisis y algoritmos, lo que en ocasiones redunda
en que la productividad de un miembro del equipo de trabajo puede verse afectada
por factores internos o externos al ambiente laboral.
Los factores internos del ambiente laboral comúnmente tienen que ver con
la relación que existe entre los mismos miembros del equipo, o, con la relación
que alguno de ellos pueda tener con las políticas de la empresa o la misma
empresa en sí. Aunque también se pueden identificar otros aspectos como la
relación que un miembro del equipo de trabajo tenga con un cliente, o qué tan a
gusto se pueda sentir un miembro del equipo de trabajo con las labores que le
asignaron, o con el rol que está desempeñando en los proyectos.
Dentro de los factores externos se pueden mencionar otras situaciones que
no tienen su causa en la relación “proyecto-miembro del equipo de proyecto”, o en
la relación “empresa-empleado”, sino que provienen de fuentes externas como la
familia, los amigos, la salud, la progenie, problemas personales u otros.
Por tanto, es importante poder determinar patrones de comportamiento en
los miembros del equipo de trabajo para poder prevenir bajas en el rendimiento y
tomar las precauciones necesarias antes de que se conviertan en problemas para
el Administrador de Proyectos. Para esto se requiere de un sistema que permita
realizar análisis estadístico basado en el historial individual para generar
proyecciones de comportamiento y rendimiento.

107
4.1.3.4. Problema 4: Falta de información para tomar decisiones
oportunas
Adicionalmente, al realizar un análisis únicamente para un sistema
específico, el mismo se convierte en un análisis reactivo en cuanto al tratamiento
de riesgos se refiere, pues los datos que se pueden obtener corresponden a
riesgos que ya se materializaron en ese proyecto. Mientras que si se pudiera
analizar varios proyectos a la vez con la intensión de ver patrones de desempeño,
este tipo de análisis se convierten en análisis estadísticos y de proyección que le
permiten a un Administrador, entre otras cosas, ver tendencias de su equipo de
trabajo en el tiempo, o incluso identificar un promedio de pulgas por cada uno de
sus miembros, lo que le permitirá tomar acciones de mitigación que minimicen o
eliminen el impacto de los riesgos.

108
4.2. Administración del proyecto
4.2.1. Gestión de Integración
El propósito de este apartado es ver el proyecto como un solo componente,
para así identificar, definir, combinar, unificar y coordinar las diversas etapas por
las que pasará el proyecto, así como las áreas del conocimiento a utilizar para que
éste sea desarrollado con éxito.
Para iniciar con este proceso fue que se dio paso a elaborar el acta
constitutiva, la cual se muestra a continuación, mostrando información de alto nivel
y considerada importante para formalizar el proyecto y documentar los
requerimientos iniciales que satisfacen las necesidades y expectativas de los
interesados.
4.2.1.1. Acta de proyecto
Cuadro 4. Acta Constitutiva del proyecto del proyecto SAPRE
ACTA DEL PROYECTO
Fecha
Nombre de Proyecto
Implementación de un Sistema de
Activos de Procesos de Rendimiento
03-Enero-2011
y Eficiencia
- SAPRE -
Fecha de inicio del proyecto Fecha tentativa de finalización del
proyecto
17 de enero del 2011 31 de marzo del 2011
Objetivos del proyecto (general y específicos)
Objetivo General

109
Maximizar la capacidad de análisis del rendimiento de los miembros de los
equipos de proyectos, mediante el desarrollo de una herramienta de
inteligencia de negocios enfocada en el Control de Calidad de los entregables
dentro del proceso de fabricación del software, con el propósito de generar
elementos que permitan a la empresa su competencia y certificación a nivel
internacional.
Objetivos Específicos
• Contar con una herramienta que permita efectuar un análisis del
rendimiento e índices de retrabajo de los miembros de proyectos, en todos
los proyectos en general, sin limitarse a un análisis para un proyecto
específico.
• Generar activos de procesos de la organización, basados en estadísticas
generales de rendimiento por persona, por etapa del proceso y por fechas.
• Brindar retroalimentación a los miembros de los equipos de proyectos en la
etapa de cierre, a fin de mejorar su rendimiento tanto en el proyecto que
cierra como en su historial de proyectos en la empresa.
Justificación o propósito del proyecto (Aporte y resultados esperados)
Actualmente existe un sistema de control de inconsistencias en la empresa,
que registra cual fue el desarrollador encargado del requerimiento, cuales
inconsistencias fueron detectadas en esa sección del código y cuánto tiempo
duró el desarrollador en corregir dichas inconsistencias, mientras que con el
actual sistema se puede generar un reporte que lo único que indica son
totalizaciones, agrupadas por los diferentes rubros (desarrollador,
requerimiento) y se pueden ordenar ya sea descendentemente o

110
ascendentemente, lo que es adecuado para las funciones iniciales del sistema
existente.
Sin embargo, con el pasar del tiempo, otras áreas fueron solicitando dichos
reportes para analizarlos para sus propios fines, lo que evidenció que hacía
falta información importante que el sistema actual sí estaba almacenando pero
no fue contemplando a la hora de desarrollar los reportes actuales. Ello obligó a
que los diferentes departamentos se vieran obligados a revisar directamente la
base de datos o bien buscar otros métodos para obtener la información que
necesitaban (en muchos casos esta falta de procesamiento orilló a que se
tomaran decisiones omitiendo dicho análisis). Debido al crecimiento de la
empresa, se intentó retomar estos análisis con el agravante de que tomaba
mucho tiempo y recursos humanos su realización, ya que se requería la
participación de los gerentes encargados de los reportes y de los
desarrolladores para extraer la información que no estaba en los reportes
actuales. Pese a ello, la información derivada de los reportes era muy difícil de
relacionar, por lo que se decidió hacerlos solo cuando fuera estrictamente
necesario.
Con la elaboración del sistema que se plantea en este proyecto, se busca dar
fin a esta problemática, ya que utilizando un cubo de información que tenga
como fuente de datos la base de datos que alimenta el actual sistema, se le
brindará a los diferentes departamentos una herramienta de análisis, donde no
sólo podrán generar los reportes actuales, sino que también podrán combinar
dicha información con cualquier otro dato que se encuentre en la base, según
sean sus necesidades. De esta manera, se brindará una herramienta de
análisis que solucionará las actuales carencias de información de la empresa, e

111
incluso se espera que se solucionen otros aspectos que aún no han sido
visualizados por los departamentos.
Descripción del producto o servicio que generará el proyecto –
Entregables finales del proyecto
Durante la elaboración del seminario de graduación y el PFG se generará:
• Acta de Constitución del Proyecto: documento que autoriza formalmente
el inicio del proyecto.
• Documentación de los alcances del proyecto: documento donde se
describen las necesidades de los interesados, las cuales conllevarán a
cumplir los objetivos del sistema.
• EDT: es la estructura jerárquica y descendente formada por los entregables
a realizar del proyecto, para así dimensionar el alcance del proyecto.
• Cronograma: análisis de la secuencia de las actividades, su duración, los
requisitos de los recursos y las restricciones del proyecto.
• Presupuesto del sistema: este es un estimado de cuánto se gastará en la
elaboración del sistema.
• Plan de la gestión de calidad: contendrá el proceso que se seguirá para
garantizar la calidad del proceso y del producto.
• Plan de la gestión de recursos humanos: contendrá los roles de las
personas dentro del proyecto, sus responsabilidades, las habilidades que
requieren.
• Plan de comunicación: contendrá las necesidades de información de las
personas involucradas en el proyecto.
• Plan de gestión de riesgos: es el plan donde se identifican los riesgos, su

112
posible impacto y probabilidad de ocurrencia en el proyecto y el cómo se
deberá de atender si se llegase a materializar.
• Plan para las adquisiciones: contendrá las diferentes adquisiciones que
se realizaran en el proyecto.
• Sistema SAPRE: este consiste en varios entregables, los cuales se listan a
continuación:
Documento de análisis técnico: que identifica las dimensiones y
métricas que se desean analizar.
Documento de identificadores: que identifica los identificadores que se
desea evaluar con el cubo de información.
Documento de reportes: que muestra cómo se mostrará la información
resultante del cubo para ser analizada.
Sistema SAPRE: que muestra el cubo de información para el análisis de
la información de los proyectos.
• Documento de cierre: documento que oficializa la finalización del sistema
de información.
Supuestos
• Se cuenta con un sistema en el cual se registran los siguientes datos:
Las inconsistencias detectadas
El desarrollador que realizó el requerimiento
El tiempo que se duró en solucionar la inconsistencia
• Se tiene una base de datos, bien estructurada con todos los datos de los
proyectos realizados en el pasado.
Restricciones

113
• Se utilizarán las tecnologías con las que la empresa tenga licencia
• Se cuenta con un desarrollador y medio para la realización de este sistema
• La información a utilizar será únicamente la contenida en la base de datos
del sistema que actualmente se utiliza para el control de inconsistencias.
Información histórica relevante
Actualmente existen sistemas que se encargan de generar este tipo de
información, pero para lograr esto se debe de tener algunas otras herramientas
de la misma compañía que son las encargadas de recopilar la información;
además, hay que considerar que tienen un valor monetario alto en el mercado.
También hay algunas que son gratuitas pero no llegan al nivel de detalle que se
requiere analizar con este sistema a implementar. Y ninguno de los existentes
en el mercado tiene la flexibilidad de conectarse a otras fuentes de datos de
terceros, por lo que no se podría conectar a la actual base de datos de la
empresa.
Identificación de grupos de interés (Stakeholders)
Cliente(s) directo(s):
• Gerente General
• Gerente de Proyectos
• Gerente de Recursos Humanos
Cliente(s) indirecto(s):
• Gerente de Control de Calidad
• Desarrolladores
Esteban Oviedo Blanco
Firma:

114
Luis Fernando Alfaro Araya
Firma:
Guillermo Ortiz
Firma:
4.2.1.2. Proceso de cierre de proyectos
Con el fin de efectuar un cierre adecuado al proyecto, es que lleva a cabo el
siguiente flujo:
Figura 68. Diagrama de cierre de proyecto de SAPRE
Donde el proceso de cierre de proyecto inicia con la aprobación por parte
de cliente de la puesta en producción del sistema en los servidores, a lo que el
equipo del proyecto realiza una ultima actualización de los documentos solicitados,
esto con el fin de entregarle al cliente un DVD con todo el código fuente y los

115
documentos finales generados. Una vez recolectada toda la información se
convoca a realizar la reunión de cierre formal del proyecto, donde se hará entrega
del DVD con la información final y a su vez se firma el documento que indica la
aceptación del sistema. Una vez finalizado se procede a realizar los cierres
internos, los cuales inician con una reunión con el equipo de desarrollo, donde se
intercambiarán experiencias y se retroalimentará a todo el equipo, según lo
ocurrido durante el desarrollo, a lo que el gerente de proyectos generará activos
de procesos. Con la finalización de esta reunión, se procede a liberar al personal y
asignarlo a otros proyectos. Luego se realiza otra reunión pero sólo con los
gerentes que estuvieron involucrados, esto para retroalimentarse a nivel gerencial
y dar los resultados del proyecto. Al final se procede a entregar al gerente del
área, el AMPO con toda la información recolectada y firmada y todo lo que fue
necesario para el desarrollo del mismo sistema. Esto último tiene el fin de que, en
caso de que durante el periodo de garantía se presenten inconsistencias, el
departamento de soporte de aplicaciones pueda realizar las correcciones.

116
4.2.2. Gestión del alcance
En este apartado se pretende lograr la definición sobre qué elementos se
van a llevar a cabo y cuáles no son parte del proyecto, para así poder completar
con éxito lo solicitado.
4.2.2.1. Definición del alcance de SAPRE
Luego de las entrevistas y análisis de los sistemas actuales se concluyó que se
debe de satisfacer las siguientes necesidades:
• Un sistema con el cual se pueda analizar varios proyectos
simultáneamente, para así poder analizar la situación del proyecto o de un
individuo en un determinado rango de tiempo.
• Un sistema que facilite el medir el rendimiento del personal de la empresa.
• Un sistema que ayude a crear formas de comportamiento del personal,
como por ejemplo que cierto empleado, en un periodo determinado, es
poco productivo, lo cual eventualmente se puede relacionar con algún
evento personal que sucedió en dicha fecha.
Un mejor detalle de este alcance se explica en los apartados 4.1.3: Análisis de la
situación actual, 4.3.2: Análisis de las fuentes de información y 4.3.3: Análisis
técnico de dimensiones y métricas.

117
4.2.2.2. Estructura detallada de trabajo (EDT)
Con la estructura detallada de trabajo, se permitirá tener una visión general
del trabajo requerido para llevar a cabo SAPRE y a la vez organizar los grupos de
tareas, con el fin de cumplir con el alcance. A continuación se presenta el EDT
para cada una de las fases del mismo.
4.2.2.2.1. EDT de la Fase de Inicio
En esta fase lo que se llevará a cabo es:
Creación y firma del acta de constitución del proyecto.
Identificación de todos los involucrados en el proyecto.
Figura 69. EDT de la fase de inicio de SAPRE
4.2.2.2.2. EDT de la Fase de Planeación
En esta fase lo que se llevará a cabo es, en orden descendente:
1. Recopilar los requisitos mediante entrevistas con los involucrados y activos
de procesos anteriores de la empresa.

118
2. Generar la estructura detallada de trabajo con base a los requerimientos
obtenidos.
3. Definir los grupos de trabajo y las actividades que se llevaran a cabo con
los mismos.
4. Identificar los recursos necesarios para llevar a cabo las actividades
definidas.
5. Desarrollar el plan de los recursos humanos.
6. Estimar la duración de cada una de las tareas.
7. Definir el cronograma del proyecto.
8. Estimar los costos de las tareas.
9. Determinar cuánto costará el proyecto y tener claridad presupuestal.
10. Definir el plan de la gestión de la calidad que se le aplicará al producto.
11. Planificar el modo en que se gestionarán las comunicaciones dentro del
proyecto.
12. Definir el plan de gestión de riesgos y, a su vez, identificar y planificar la
respuesta (mitigación y contingencia) a los riesgos identificados.
13. Planear cómo se gestionarán las adquisiciones necesarias para llevar a
cabo con éxito el proyecto.

119
Figura 70. EDT de la fase de planeación de SAPRE
4.2.2.2.3. EDT de la Fase de Ejecución
En esta fase lo que se llevará a cabo es:
1. Distribuir los informes de avance del estatus del proyecto.

120
2. Proceder a codificar y realizar el cubo de información, lo cual consta de la
extracción y transformación de los datos, carga los datos a un data
warehouse, creación de reportes de los indicadores, pruebas de
aseguramiento de calidad y corrección de los incidentes encontrados.
Figura 71. EDT de la fase de ejecución de SAPRE

121
4.2.2.2.4. EDT de la Fase de Control
En esta fase lo que se llevará a cabo es:
1. Monitoreo del tutor al proyecto
2. Revisiones del avance del equipo de trabajo para asegurar el trabajo
realizado, el alcance y los costos del proyecto.
Figura 72. EDT de la fase de control de SAPRE
4.2.2.2.5. EDT de la Fase de Cierre
En esta fase lo que se llevará a cabo es:
1. Instalar el cubo de información en los servidores de la empresa.
2. Llevar a cabo la reunión de cierre del proyecto, donde se firma la carta de
cierre de proyecto.
Figura 73. EDT de la fase de cierre de SAPRE

122
4.2.3. Gestión del tiempo
En este apartado se busca identificar las actividades necesarias y la
secuencia en la que se deberán ejecutar los recursos (humanos y materiales) y su
estimación en tiempo para lograr los objetivos trazados en el proyecto. Como
resultado de todo esto se presentará el cronograma con el que se trabajará
durante las etapas de planeación, ejecución, control y cierre del proyecto.
4.2.3.1. Lista de actividades, recursos y duración de actividades
Luego del análisis se detallan las actividades y su secuencia, las cual
permitirán el desarrollo adecuado de los grupos de tareas, para así lograr un
producto de alta calidad. Asimismo y con tal de optimizar el tiempo, se analiza la
necesidad de recursos, evidenciándose que sólo se necesitará del recurso
humano, ya que el material son activos de la empresa. A fin de optimizar el uso del
recurso humano, es que se ejecutan tareas en paralelo, con el fin de reducir
tiempos y costos, sin sacrificar la calidad del producto final.
Posteriormente y como producto del análisis de recursos, se determina que
participarán de la ejecución de todo el proyecto las siguientes personas:
Cuadro 5, Lista de involucrados del proyecto SAPRE
Nombre del Recurso Iniciales Grupo al que pertenece
Esteban Oviedo EO PM/Desarrollador
Luis Fernando Alfaro LA PM/Desarrollador
César Oviedo CO Desarrollador
Guillermo Ortiz GO Gerente Desarrollo
Erick Salazar ES Gerente Calidad

123
Como resultado de estos análisis, se crea el cronograma de trabajo del
proyecto, el cual se muestra en el Anexo 4. A continuación se listan las actividades
con sus sucesores, recursos y duraciones.
Cuadro 6. Lista de actividades del proyecto SAPRE
ID Nombre de la tarea Duración Predecesor Iniciales Involucrados
0 SAPRE 32 días
1 Fase de Inicio 0.63 días
2 Desarrollar el Acta de Constitución del Proyecto 0.5 días LA,EO
3 Identificar a los Interesados 1 horas 2 EO,LA
4 Fase de Planeación 7.5 días
5 Recopilar Requisitos 0.5 días 3 LA,EO
6 Crear la Estructura Detallada de Trabajo 0.5 días 5 LA,EO
7 Definir las Actividades 0.5 días 6 LA,EO
8 Estimar los Recursos de las Actividades 0.5 días 7 LA,EO
9 Desarrollar el Plan de Recursos Humanos 0.5 días 8 LA,EO
10 Estimar la Duración de las Actividades 0.5 días 9 LA,EO
11 Desarrollar el Cronograma 0.5 días 10 LA,EO
12 Estimar los Costos 0.5 días 11 LA
13 Determinar el Presupuesto 0.5 días 12 LA
14 Plan de gestión de la Calidad 0.5 días 13 LA
15 Plan de gestión de las Comunicaciones 0.5 días 14 LA
16 Plan de gestión de Riesgos 0.5 días 15 LA
17 Identificar los Riesgos 0.5 días 16 LA
18 Plan de Respuesta a los Riesgos 0.5 días 17 LA
19 Plan de gestión de las Adquisiciones 0.5 días 18 LA
20 Fase de Ejecución 25.13 días
21 Distribuir la informe de avance 25 días
22 Distribuir la informe de avance 1 0 días ES,GO,LA,EO
23 Distribuir la informe de avance 2 0 días ES,GO,LA,EO
24 Distribuir la informe de avance 3 0 días ES,GO,LA,EO
25 Distribuir la informe de avance 4 0 días ES,GO,LA,EO

124
ID Nombre de la tarea Duración Predecesor Iniciales Involucrados
26 Distribuir la informe de avance 5 0 días ES,GO,LA,EO
27 Distribuir la informe de avance 6 0 días ES,GO,LA,EO
28 Desarrollo del Sistema 25 días
29 Procesos de Extracción de Datos 10 días 11 EO,LA
30 Procesos de Transformación de los Datos 10 días 29 EO,LA
31 Procesos de Carga de Datos 10 días 30 EO,LA
32 Creación de Reporte de Indicadores 10 días 31 EO,LA
33 Pruebas 5 días 32 EO,LA,ES,GO
34 Corrección de incidentes 2 días 33 EO,LA
35 Fase de Control 32 días
36 Monitoreo bi-semanal con Tutor 30 días
37 Monitoreo bi-semanal con Tutor 1 0 días EO,LA
38 Monitoreo bi-semanal con Tutor 2 0 días EO,LA
39 Monitoreo bi-semanal con Tutor 3 0 días EO,LA
40 Monitoreo bi-semanal con Tutor 4 0 días EO,LA
41 Controlar el trabajo, alcance, costos 30 días
42 Monitorear y Controlar el Trabajo del Proyecto 1 1 hora EO,LA
43 Monitorear y Controlar el Trabajo del Proyecto 2 1 hora EO,LA
44 Monitorear y Controlar el Trabajo del Proyecto 3 1 hora EO,LA
45 Monitorear y Controlar el Trabajo del Proyecto 4 1 hora EO,LA
46 Monitorear y Controlar el Trabajo del Proyecto 5 1 hora EO,LA
47 Monitorear y Controlar el Trabajo del Proyecto 6 1 hora EO,LA
48 Monitorear y Controlar el Trabajo del Proyecto 7 1 hora EO,LA
49 Fase de Cierre 2.5 días
50 Instalación del Sistema 1 día 34 EO
51 Reunión de cierre de proyecto y adquisiciones 1 días 50 EO,LA,ES,GO

125
4.2.4. Gestión de costos
En este apartado se busca mostrar cómo con la estimación de las
actividades se llegó a generar el presupuesto del proyecto. Considerando que este
proyecto es interno, sólo se está tomando en cuenta el precio de costo de los
recursos. Para obtener estos datos se utiliza, como unidad de medida, las horas
necesarias para completar la actividad, que es la forma en que se estima en la
empresa.
4.2.4.1. Estimación de costos
Para esto se desglosó el costo para la empresa de los recursos humanos
identificados que serían necesarios para llevar a cabo con éxito el proyecto, de lo
que se obtuvieron los siguientes datos:
Cuadro 7. Costos de los recursos del proyecto SAPRE
Nombre del Recurso Costo x hora
Esteban Oviedo $13.00
Luis Fernando Alfaro $13.00
César Oviedo $13.00
Guillermo Ortiz $15.00
Erick Salazar $15.00
Con esta información, se obtiene el costo de cada una de las etapas, las cuales se
describe a continuación:

126
Cuadro 8. Costos de las etapas del proyecto SAPRE
SAPRE $8,520.67
Fase de Inicio $130.00
Fase de Planeación $1,040.00
Fase de Ejecución $6,512.67
Fase de Control $182.00
Fase de Cierre $656.00
Cuadro 9. Costos de las actividades del proyecto SAPRE
Nombre de la tarea
Costo
SAPRE $8,520.67
Fase de Inicio $130.00
Desarrollar el Acta de Constitución del Proyecto $104.00
Identificar a los Interesados $26.00
Fase de Planeación $1,040.00
Recopilar Requisitos $104.00
Crear la Estructura Detallada de Trabajo $104.00
Definir las Actividades $104.00
Estimar los Recursos de las Actividades $104.00
Desarrollar el Plan de Recursos Humanos $104.00
Estimar la Duración de las Actividades $104.00
Desarrollar el Cronograma $104.00
Estimar los Costos $39.00
Determinar el Presupuesto $39.00
Gestión de la Calidad $39.00
Gestión de las Comunicaciones $39.00
Gestión de Riesgos $39.00
Identificar los Riesgos $39.00
Plan de Respuesta a los Riesgos $39.00
Plan de gestión de las Adquisiciones $39.00
Fase de Ejecución $6,512.67
Distribuir la informe de avance $0.00
Desarrollo del Sistema $6,512.67

127
Nombre de la tarea
Costo
Procesos de Extracción de Datos $502.67
Procesos de Transformación de los Datos $1,300.00
Procesos de Carga de Datos $1,300.00
Creación de Reporte de Indicadores $1,300.00
Pruebas $1,850.00
Corrección de incidentes $260.00
Fase de Control $182.00
Monitoreo bi-semanal con Tutor $0.00
Controlar el trabajo, alcance, costos $182.00
Fase de Cierre $656.00
Instalación del Sistema $208.00
Reunión de cierre de proyecto y adquisiciones $448.00

128
4.2.4.2. Presupuesto del proyecto
Una vez que se tiene la información de los costos de cada una de las tareas, se concluye que el BAC (por sus
siglas en inglés para identificar el Presupuesto al finalizar [Budget At Completion]) es de $8.520,67, con la siguiente
distribución:
Cuadro 10. Presupuesto del proyecto SAPRE

129
4.2.5. Gestión de calidad
En este apartado se definirán los procesos y actividades con los que se
garantizará que el proyecto satisfaga todas las necesidades planteadas en los
requerimientos.
En la empresa normalmente utiliza una metodología de control de
calidad, la cual se diagrama a continuación:
Inicio
Codificación del sistema
Obtener
Requerimientos del
sistema
No
N Iteraciones
Corrección de
inconsistencias
Crear escenarios de
pruebas
Aprobación
de CU
Aplicar Pruebas
Si
Aprobación
del sistema
Figura 74. Diagrama de control de calidad para proyectos internos pequeños de
Babel

130
Donde el primer paso es identificar cuáles fueron los requerimientos del
sistema solicitados. De seguido se procede a realizar algunos escenarios de
pruebas que garanticen que el sistema cumple con lo solicitado. Después, se
espera a que los desarrolladores terminen el sistema que, de inmediato, los
encargados de aplicar la calidad lleven a cabo los escenarios identificados en el
paso anterior. Posteriormente, y si se descubre que existen requerimientos que
no se cumplen o bien que el sistema presenta errores en alguna de sus
funcionalidades, éstos informan al gerente de proyectos que existen
inconsistencias y le comunica, de manera informal, cuáles fueron las
inconsistencias encontradas para que, a su vez, éste informe al equipo de
desarrolladores para que las corrijan. De no encontrarse ningún problema en el
sistema, los desarrolladores de proyectos informan al gerente de proyectos para
que proceda a su instalación en producción.
4.2.6. Gestión de recursos humanos
Con este plan se quiere lograr organizar al equipo de trabajo, definir los
roles y responsabilidades de cada uno de los involucrados y, de esta manera,
dejar claro qué debe hacer cada uno y en qué momento. Así, se evita que queden
asuntos sin atender y que, eventualmente, puedan afectar negativamente el
proyecto.
Dado que este es un proyecto pequeño se facilitan labores como las de
influenciar al equipo para que esté a gusto y motivado y mantener un nivel ético y
profesional ante la información que se está manejando, ya que ésta puede afectar
directamente al personal de la empresa en general.

131
4.2.6.1. Organigrama
A continuación se muestra la estructura organizacional que aplicará al
proyecto. A su vez, se describirán los distintos roles y responsabilidades que
tendrá el personal.
Figura 75. Estructura Organizacional de SAPRE
4.2.6.2. Roles del proyecto
4.2.6.2.1. Patrocinador
Persona que cuenta con conocimiento y experiencia en dirigir personal y
proyectos de diferentes tipos, en especial en las áreas donde se detectó la falta de
funcionalidad al sistema Bug Tracking y que, a su vez, al terminar el cubo de
información serán los principales usuarios para la toma de decisiones.
Integrantes:
Guillermo Ortiz
Erick Salazar

132
4.2.6.2.2. Gerente de proyectos
Integrante del equipo que cuenta con conocimientos y experiencia en
administración de proyectos, incluyendo experiencia en planeación, ejecución y
control. Éste tendrá la responsabilidad del proyecto en general, administrará el
proyecto en todos sus aspectos, se encargará de aprobar los cambios en los
requerimientos negociados, planeará y controlará el proyecto para así poder tomar
acciones necesarias y oportunas para evitar desviaciones en el plan de trabajo, y
ejecutará acciones correctivas necesarias para alcanzar los objetivos del proyecto
con la calidad esperada, presupuesto y tiempo acordados, además de facilitar los
recursos humanos y materiales requeridos.
Integrantes:
Esteban Oviedo
Luis Fernando Alfaro
4.2.6.2.3. Desarrollador BI
Es la persona con conocimientos técnicos en la elaboración de Bases de
Datos usando tecnologías de Microsoft. Será responsable de la elaboración de los
cubos de información así como del diseño de la base de datos del sistema y de
desarrollar todos los módulos del sistema, así como de brindarle al usuario un fácil
acceso a la información solicitada.
Integrantes:
Esteban Oviedo
Luis Fernando Alfaro

133
4.2.6.2.4. Encargado de Calidad
Es la persona con un conocimiento y experiencia en la auditoría de
administración de proyectos. Se hará responsable de realizar revisiones periódicas
para el aseguramiento de la calidad del sistema, además de asegurar que se
cumplen las normas de calidad que BABEL establece.
Integrantes:
Erick Salazar

134
4.2.6.3. Plan de ingreso y liberación de personal
A continuación se muestra el plan donde se indica la fecha en que ingresarán y se retirarán los involucrados en el
proyecto.
Figura 76, Plan de ingreso y liberación de personal de SAPRE

135
4.2.7. Gestión de comunicaciones
Este apartado tiene como finalidad garantizar la generación, recopilación y
distribución de la información del proyecto, para que así todos los interesados
tengan la información necesaria para lograr que los objetivos sean cumplidos de la
mejor manera y así satisfacer la necesidad de información de los proyectos de los
patrocinadores.
4.2.7.1. Interesados
Cuadro 11. Interesados del proyecto SAPRE
Nombre Rol en el proyecto Puesto Tipo
Guillermo Ortiz Patrocinador Gerente de
desarrollo a la
medida
Erick Salazar Patrocinador Gerente de
aseguramiento de
calidad
Interno /
partidario
Interno /
partidario
Esteban Oviedo Gerente de Proyecto Director Operativo Interno /
partidario
Luis Fernando
Alfaro
Gerente de
proyectos
Gerente de
proyectos
Interno /
partidario

136
4.2.7.2. Estrategia
La estrategia a utilizar para aumentar el apoyo y minimizar los efectos
negativos se basará en el siguiente cuadro:
Cuadro 12. Análisis de interesados del proyecto SAPRE
Interesado Tipo de Interés
Impacto que tiene Estrategia para
en el proyecto ganar apoyo
Guillermo Ortiz Interesado directo Define los
requerimientos y
tiene el poder de
cambiarlos
Mostrarle avances
significativos.
Involucrarlo en el
desarrollo para
que opine sobre el
Erick Salazar Interesado directo Define los
requerimientos y
tiene el poder de
cambiarlos
posible resultado.
Involucrarlo en el
desarrollo para
que opine sobre el
posible resultado.
4.2.7.3. Matriz de comunicaciones
Con el fin de mantener una buena comunicación se utilizarán las
conversaciones vía correo electrónico en las cuales se deberá de marcar copia,
siempre, a los gerentes de proyecto. En el caso de las conversaciones telefónicas
o presenciales, las cuales se considerarán como reuniones informales, se deberá
de comunicar los acuerdos tomados vía correo electrónico a los gerentes del
proyecto. Para el resto de comunicaciones se hará de la siguiente manera:

137
¿Qué se
comunica?
Acta de
constitución
Inicio del
proyecto
Documento de
análisis técnico
Documento de
identificadores
Documento de
reportes
Cronograma /
Presupuesto
Avance del
proyecto
Documento de
cierre de
proyecto
Cuadro 13. Matriz de comunicaciones del proyecto SAPRE
¿Quién lo
comunica?
Gerentes de
Proyectos
Gerentes de
Proyectos
Gerentes de
Proyectos
Gerentes de
Proyectos
Gerentes de
Proyectos
Gerentes de
Proyectos
Gerentes de
Proyectos
Gerentes de
Proyectos
¿A quién lo
comunica?
Patrocinadores
Todos los
interesados del
proyecto
Todos los
interesados del
proyecto
Todos los
interesados del
proyecto
Todos los
interesados del
proyecto
Patrocinadores
Patrocinadores
Patrocinadores
¿Cuándo lo
comunica?
Conceptualización
del proyecto
Inicio del proyecto
Luego de las
entrevistas
Luego de las
entrevistas
Luego de las
entrevistas
Posterior al
análisis de los
alcances
Cada 15 días
Finalización del
proyecto
¿Cómo lo
comunica?
Reunión /
Documento
oficial
Reunión de
inicio de
proyecto
Reunión de
validación /
Correo
Electrónico
Reunión de
validación /
Correo
Electrónico
Reunión de
validación /
Correo
Electrónico
Reunión /
Correo
Electrónico
Correo
Electrónico
Documentación
oficial

138
4.2.8. Gestión de Riesgos
En este apartado se busca determinar un método formal y sistemático de
administración de los riesgos del proyecto. Esta actividad se concentra en la
identificación y control de áreas o eventos que tienen el potencial de causar
cambios no deseados en el costo, tiempo o alcance, durante el desarrollo del
proyecto.
El análisis de riesgos se basa en el hecho de que el cambio es un factor
continuo e inevitable, lo que puede provocar un efecto adverso en los resultados
iniciales esperados del proyecto. Ante esta situación, el análisis de riesgos busca
minimizar los cambios no deseados que puedan surgir en el desarrollo del
proyecto a partir de un efecto contrario a lo esperado.
4.2.8.1. Riesgos identificados
Cuadro 14. Riesgo RSK-001 del proyecto SAPRE
ID Prioridad del
Descripción breve
Referencia riesgo
Ejecución de un cambio en los
requerimientos no aprobado
Descripción detallado del riesgo
Un miembro del proyecto ejecuta un
cambio en algún requerimiento del
proyecto sin la aprobación
Fecha
identificación
RSK-001 Media 24-Enero-2011
Entregable o meta principal impactada
Cubo de información
Área de impacto
correspondiente, provocando una
pérdida para la parte desarrolladora
Cronograma de Actividades y alcances
de la solución.
Plan de mitigación Responsable Fecha inicio Fecha finalización
Los cambios se llevarán a las
Gerentes del
reuniones de seguimiento o
Proyecto
informales y deberán ser aprobados

139
Descripción breve
para poder proceder con el mismo,
evitando que se perjudique de
manera inesperada al cubo en
costo, tiempo o alcance.
Plan de contingencia
Se evaluará la forma en que
procedió informalmente el cambio
para determinar el nivel de
responsabilidad que permita
negociar puntualmente la situación
presentada y tomar acciones
correctivas para evitar que se siga
presentando.
ID
Referencia
Prioridad del
riesgo
Fecha
identificación
Impacto detallado
Varía según análisis del cambio, pero
generalmente afectará uno o varios de los
siguientes tres aspectos (alcance, tiempo y
dinero)
Probabilidad
de Exposición Estado del riesgo
ocurrencia del riesgo
10% Bajo Activo
Cuadro 15. Riesgo RSK-002 del proyecto SAPRE
ID Prioridad del
Descripción breve
Referencia riesgo
Indisponibilidad de tiempo por parte
del algún miembro clave del equipo
Descripción detallado del riesgo
Un miembro clave del equipo se
encuentre saturado de actividades o
atendiendo un volumen alto de
actividades no relacionadas o
asignadas al proyecto dificultando
poder atender las necesidades del
proyecto (contestar correos,
llamadas, actividades de ejecución o
control, entre otras cosas)
Fecha
identificación
RSK-002 Media 24-Enero-2011
Entregable o meta principal impactada
Definición del alcance / Cubo de información
Área de impacto
Cronograma de Actividades
Plan de mitigación Responsable Fecha inicio Fecha finalización
Los gerentes de proyecto tendrán la
responsabilidad de informar
semanalmente las situaciones
especiales que se presenten para su
discusión y toma oportuna de
decisiones.
Plan de contingencia
Gerentes
del Proyecto
Impacto detallado

140
Descripción breve
Se asignará a personas de respaldo
para cada miembro clave del
proyecto.
ID
Referencia
Prioridad del
riesgo
Fecha
identificación
Esto afectará directamente en los tiempos, por lo
que según sea el caso podría requerir de una
nueva estimación de tiempo, alcance y costo.
Probabilidad
de Exposición Estado del riesgo
ocurrencia del riesgo
25% Medio Activo
Cuadro 16. Riesgo RSK-003 del proyecto SAPRE
Descripción breve
ID Prioridad del Fecha
Referencia riesgo identificación
Suposición de requerimientos RSK-003 Alta 24-Enero-2011
Descripción detallado del riesgo Entregable o meta principal impactada
El programador a la hora del
Cubo de información
desarrollo, lleva a cabo funciones
supuestas, provocando re trabajo o
atraso en el tiempo establecido
Área de impacto
Cronograma de Actividades y alcances
Plan de mitigación Responsable Fecha inicio Fecha finalización
Los nuevos o cambios de
requerimientos se deberán de
discutir en reuniones informales para
llegar a un acuerdo.
Plan de contingencia
Se procederá a revisar los
requerimientos, para detectar dudas
Gerentes del
Proyecto
Impacto detallado
Esto afectará directamente en los tiempos, por lo
que según sea el caso podrían requerir de una
negociación.
Probabilidad
de Exposición Estado del riesgo
ocurrencia del riesgo
10% Medio Activo
Cuadro 17. Riesgo RSK-004 del proyecto SAPRE
ID Prioridad del Fecha
Descripción breve
Referencia riesgo identificación
Mala extracción de los datos RSK-004 Alta 24-Enero-2011
Descripción detallado del riesgo Entregable o meta principal impactada

141
Descripción breve
A la hora de hacer las extracciones
de la bases de datos de los
sistemas existentes, se confundan
valores lo cual conllevaría a que los
reportes den información errónea
Plan de mitigación
Se utilizaran los diccionarios de
datos y material utilizado en el
desarrollo del sistema BugTracking,
además de realizar las consultas del
caso al personal que lo desarrollo
Plan de contingencia
Se involucrará más al personal que
estuvo a cargo anteriormente del
desarrollo del sistema BugTrackig.
ID
Referencia
Prioridad del Fecha
riesgo identificación
Cubo de información
Área de impacto
Cronograma de Actividades y alcances
Responsable
Desarrollador
Fecha
inicio
Fecha finalización
Impacto detallado
Esto afectará directamente en los tiempos, por lo
que según sea el caso podrían requerir de una
negociación.
Probabilidad Exposición
Estado del riesgo
de ocurrencia del riesgo
50% Medio Activo
Cuadro 18. Riesgo RSK-005 del proyecto SAPRE
Descripción breve
ID Prioridad del Fecha
Referencia riesgo identificación
Mala uso del cubo de información RSK-005 Media 24-Enero-2011
Descripción detallado del riesgo Entregable o meta principal impactada
A la hora de hacer uso del cubo de
información, no se sabe cómo
Aprobación del cubo
Área de impacto
utilizarlo de manera correcta, lo que
causaría la mala información en los
reportes y por consiguiente un mal
Reportes del cubo
análisis de la información
Plan de mitigación
Se impartirán capacitaciones por
parte de los desarrolladores del
cubo a los usuarios finales
Responsable
Patrocinadores
Fecha
inicio
Fecha finalización

142
Descripción breve
Plan de contingencia
Se retomarán las capacitaciones,
con dudas que hayan salido
durante el uso del cubo
ID
Referencia
Prioridad del
riesgo
Fecha
identificación
Impacto detallado
Se desplegaran informes con incompletos o con
información erróneas, lo cual puede llevar a
malas decisiones gerenciales
Probabilidad Exposición
de ocurrencia del riesgo
Estado del riesgo
40% Medio Activo
Cuadro 19. Riesgo RSK-006 del proyecto SAPRE
ID Prioridad del
Descripción breve
Referencia riesgo
Poca experiencia en el desarrollo
de cubos
Descripción detallado del riesgo
Poca experiencia de los
desarrolladores en la elaboración
del cubo
Fecha
identificación
RSK-006 Alta 24-Enero-2011
Entregable o meta principal impactada
Cubo de información
Área de impacto
Cubo de información
Plan de mitigación Responsable Fecha inicio Fecha finalización
Se impartirá un curso introductorio
al iniciar el proyecto, para capacitar
a los desarrolladores con tal de que
no afecte el tiempo, alcance ni el
costo
Plan de contingencia
Se solicitará a un experto en el
desarrollo de cubos que se
incorpore al proyecto para mejorar
los tiempos de entrega
Desarrollador
18-Enero-
2011
Impacto detallado
Se producirán muchas inconsistencias en la
elaboración del cubo, lo cual puede impactar
gravemente al proyecto
Probabilidad Exposición
Estado del riesgo
de ocurrencia del riesgo
70% Medio Activo

143
Cuadro 20. Riesgo RSK-007 del proyecto SAPRE
ID Prioridad del
Descripción breve
Referencia riesgo
No terminar en el tiempo estipulado
el cubo de información
Descripción detallado del riesgo
Debido a eventos inesperados, el
tiempo de conclusión del proyecto,
se extienda más de lo requerido
Plan de mitigación
Se estará revisando semanalmente
el avance, para tomar las medidas
del caso
Plan de contingencia
Se incorporará más personal con
experiencia, para acelerar los
procesos de desarrollo
Fecha
identificación
RSK-007 Media 24-Enero-2011
Entregable o meta principal impactada
Cubo de información
Área de impacto
Aprobación del cubo
Responsable
Patrocinadores
Impacto detallado
Fecha
inicio
Fecha finalización
No lograr cumplir con el desarrollo del cubo en el
plazo establecido, el cual es inamovible
Probabilidad Exposición
Estado del riesgo
de ocurrencia del riesgo
40% Medio Activo

144
4.2.9. Gestión de Adquisiciones
Para este proyecto no se requirieron nuevas adquisiciones, ya que la
empresa contaba con todos los requerimientos del mismo.

145
4.3. Entregables del proyecto
4.3.1. Entrevistas con los interesados
Como parte de la etapa de análisis del proyecto, se diseñó una entrevista
que se aplicó a las Gerencias de Desarrollo, de Calidad y de Proyectos. La
intención de esta entrevista fue determinar las principales deficiencias en la
administración de la productividad de los miembros del equipo de trabajo en los
proyectos.
La entrevista que aplicada es la siguiente:
Encuesta sobre análisis de productividad del personal
Nombre: ________________________________________________
Puesto: _________________________________________________
Fecha: ____________________
1. Defina su puesto
R/ ______________________________________________
________________________________________________
________________________________________________
2. ¿Cuánto personal tiene a su cargo?
R/ ______________________________________________
3. ¿Qué actividades desarrolla el personal a su cargo?
R/ ______________________________________________
________________________________________________
________________________________________________
4. ¿Tiene control usted sobre el índice de productividad del personal a
su cargo? (si no, pase a la pregunta 6)

146
R/ ______________________________________________
5. ¿El control de la productividad está automatizado y le permite conocer
el rendimiento del personal antes de incluirlo en algún proyecto?
R/ ______________________________________________
6. ¿Qué situaciones son las que causan bajas en la productividad de los
miembros de su equipo en un proyecto?
R/ ______________________________________________
7. ¿Tiene alguna manera de determinar si estas situaciones responden a
algún patrón en el tiempo o a un escenario específico?
R/ ______________________________________________
8. Antes de iniciar un proyecto, ¿puede identificar riesgos relacionados
con la productividad del personal que asignó a ese proyecto?
R/ ______________________________________________
9. ¿Mencione 3 consecuencias negativas que se han presentado en
algún proyecto por no conocer el rendimiento que podía esperar de un
colaborador antes de iniciar el proyecto?
R/ ______________________________________________
¡Muchas gracias por su colaboración!
__________________________________
Firma
4.3.2. Análisis de las fuentes de información
Para generar un cubo de información, se debe generar un almacén de
datos (o Data Warehouse por su nombre en inglés) el cual se alimentará de una

147
fuente de información que en este caso será la Base de Datos del sistema
BugTracking, ya que ahí se encuentra la información de todas las pulgas que se
detectan en los sistemas que desarrolla la empresa, así como todos los datos que
se recolectan durante el ciclo de vida de la pulga, hasta que ésta se cierra.

STAT_Spec_Funct
SpecId (FK)
FunctId
Description
STAT_Spec_Res ult
SpecId (FK)
ResultId
Description
STAT_Spec
Id
ApprovedBy (FK)
ApprovalDate
Name
Author (FK)
AssignedTo
CreationDate
Status (FK)
Priority (FK)
Milestone (FK)
SpecVersion
Description
Comments
Restrictions
ParentType (FK)
Parent
LastUpdate
Locked
LastUpdatedBy (FK)
SubOrder
STAT_Milestone
Id
Milestone
Description
STAT_Spec_Re quis ites
SpecId (FK)
ReqId
Description
STAT_Hist_Spec
MovementId
Id
ApprovedBy (FK)
ApprovalDate
Name
Author (FK)
AssignedTo (FK)
CreationDate
Status (FK)
Priority (FK)
Milestone (FK)
SpecVersion
Description
Comments
Restrictions
ParentType (FK)
Parent
Functionality
Requisites
Results
PostedBy (FK)
PostedIn
PostedDate
Action
SubOrder
STAT_PrioritySpec
Id
Name
STAT_His t_Spec_BackUp
MovementId
Id
ApprovedBy (FK)
ApprovalDate
Name
Author (FK)
AssignedTo (FK)
CreationDate
Status (FK)
Priority (FK)
Milestone
SpecVersion
Description
Comments
Restrictions
ParentType (FK)
Parent
Functionality
Requisites
Results
PostedBy (FK)
PostedIn
PostedDate
Action
STAT_SpecPare nt
Id
Name
STAT_SpecsRe vie w
RevisionId
SpecId (FK)
AssignedTo (FK)
ParentCategory
Review edBy (FK)
Review edDate
StatusId
Review Notes
CategoryFullPath
STAT_SpecStatus
id
Name
STAT_His t_Category_BackUp
MovementId
Id
Name
Parent
Description
PostedBy (FK)
PostedIn
PostedDate
Action
STAT_Hist_Category
MovementId
Id
Name
Parent
Description
PostedBy (FK)
PostedIn
PostedDate
Action
SubOrder
STAT_His t_Us eCase_BackUp
MovementId
Id
ParentCategory
ApprovedBy (FK)
ApprovalDate
Name
Author (FK)
AssignedTo
CreationDate
Status
Actor
BriefDescription
Precondition
Flow OfEvents
AlternateFlow OfEvents
PostConditions
Notes
PostedBy (FK)
PostedIn
PostedDate
Action
STAT_Re vis ionNotes
RevisionId (FK)
AssignedTo (FK)
DocumentType
Notes
STAT_TestCaseScenarioRe vie w
RevisionId (FK)
TestCaseId (FK)
ScenarioId
AssignedTo (FK)
ParentCategory
Review edBy (FK)
Review edDate
StatusId
Review Notes
CategoryFullPath
STAT_Revisions
RevisionId
RevisionName
Comments
PostedBy (FK)
PostedDate
RevisionType
Finished
STAT_Hist_TestCase
MovementId
Id
Parent
ApprovedBy (FK)
ApprovalDate
Author (FK)
AssignedTo (FK)
Weight
Status (FK)
Priority (FK)
CreationDate
Name
Description
PostedBy (FK)
PostedIn
PostedDate
Action
ParentType
TestCaseTypeId
Path
SubOrder
ITLS_Us ers
UserId
login
status
Administrator
Name
LastName
EmailAddress
Passw rd
STAT_Tes tCase
Id
Parent
ApprovedBy (FK)
ApprovalDate
Author (FK)
AssignedTo (FK)
Weight
Status (FK)
Priority (FK)
CreationDate
Name
Description
Locked
LastUpdatedBy (FK)
ParentType
TestCaseTypeId (FK)
Path
SubOrder
Consecutives
idName
idValue
ISET_TestTypes
Id
Description
STAT_Ge neralParamete rs
PreConditionPath
AttachmentPath
SpecsPath
UseCasePath
CategoriesPath
Version
MiscellaneousPath
Te stTypes
Id
Description
ITLS_Report_Area
Id_Area
Name
ITLS_Reports
Id_Report
Report_Name
Id_Area (FK)
IREV_Scenarios InRe vie w
ScenarioId
TestCaseId
Review Id (FK)
Version
Status
Priority
SectionId
Comments
AssignedToUserId
IREV_Review s
Review Id
STAT_His t_Te stCas e_BackUp
Review Name
Review Date
Notes
Author
MovementId
Id
Parent
ApprovedBy
ApprovalDate
Author (FK)
AssignedTo
Weight
Status (FK)
Priority (FK)
CreationDate
Name
Description
PostedBy (FK)
PostedIn
PostedDate
Action
ParentType
TestCaseTypeId
Path
IREV_GeneralParam eters
Version
ITLS_Gene ralParame ters
STAT_RevisionStatus
StatusId
Low estAllow edPriority
Version
Active
GroupId
GeneralParameterId
TTP_Server
TTP_Database
TTP_Directory
TTP_Dns
TTP_Url
SMTP_Server
Name
DocumentType
sys diagrams
diagram_id
name
principal_id
version
definition
IREV_SectionsInReview
SectionId (FK)
Review Id (FK)
IREV_Sections
SectionId
SectionName
UserInCharge
Product
STAT_Te stCas eTypes
TestCaseTypeId
Name
Description
IREV_Groups
GroupId
GroupName
GroupDescription
ITLS_Products
ProductId
ProductName
STAT_ScenarioTem plates
ScenarioTemplateId
Name
Description
Inputs
Database
Comments
Instructions
Steps
Notes
Results
Observations
ITLS_Obje cts
Id
STAT_PriorityTestCase
Id
Name
STAT_Hist_UseCase
MovementId
Id
ParentCategory
ApprovedBy (FK)
ApprovalDate
Name
Author
AssignedTo (FK)
CreationDate
Status (FK)
Actor (FK)
BriefDescription
Precondition
Flow OfEvents
AlternateFlow OfEvents
PostConditions
Notes
PostedBy (FK)
PostedIn
PostedDate
Action
SubOrder
ISET_ExecutionStatus
StatusId
Name
TypeId
STAT_Docum entLinks
ParentId
ParentType
ChildId
ChildType
STAT_SpecTemplates
Name
Description
ApplicationId (FK)
SpecTemplateId
Name
Description
Prerequisites
Restrictions
Functionality
Results
Comments
ITLS_Applications
ApplicationId
ApplicationName
Description
ITLS_Permis sions
PermissionId
PermissionName
Description
ApplicationId (FK)
ObjectId (FK)
STAT_ExecutionTCSte ps
StepId
Name
StepPath
ITLS_Pe rm issionsInGroup
PermissionId (FK)
GroupId (FK)
STAT_Te stCas eStatus
Id
Description
ISET_GeneralParam eter
ExecutableFilesPath
DriversPath
Version
TTPDataBase
STAT_Use Case Template s
UseCaseTemplateId
Name
Description
Preconditions
Flow Events
AlternativeEvents
PostConditions
Notes
ITLS_Groups
GroupId
GroupName
Description
ApplicationId (FK)
ITLS_Use rs InGroup
UserId
GroupId (FK)
STAT_Us eCas eStatus
Id
Description
STAT_Actors
id
Name
STAT_Us eCas eReview
RevisionId
UseCaseId (FK)
AssignedTo
ParentCategory
Review edBy
Review edDate
StatusId
Review Notes
CategoryFullPath
STAT_UseCase
Id
ParentCategory (FK)
ApprovedBy (FK)
ApprovalDate
Name
Author (FK)
AssignedTo (FK)
CreationDate
Status (FK)
Actor (FK)
BriefDescription
Precondition
Flow OfEvents
AlternateFlow OfEvents
PostConditions
Notes
LastUpdate
Locked
LastUpdatedBy (FK)
SubOrder
STAT_Category
Id
Name
Parent
Description
Locked
LastUpdatedBy
SubOrder
STAT_Use Case _Attachm ent
UCId (FK)
AttachmentPath
STAT_Hist_Scenario_BackUp
MovementId
Id
TCId
ApprovedBy (FK)
ApprovalDate
Name
Author (FK)
AssignedTo (FK)
CreationDate
Status (FK)
Priority (FK)
Weight
Description
Inputs
DBInformation
HWTemplatePath
SWTemplatePath
EnvironmentComments
ContextPreconditions
GeneralInstructions
Notes
Results
Observations
Steps
PostedBy (FK)
PostedIn
PostedDate
Action
AutomaticRun
LayerId
ExecutionPlanId
Path
RestrictedRun
STAT_Reviewe dExecutions
RevisionId (FK)
ExecutionId (FK)
STAT_Hist_Scenario
MovementId
Id
TCId
ApprovedBy (FK)
ApprovalDate
Name
Author (FK)
AssignedTo (FK)
CreationDate
Status (FK)
Priority (FK)
Weight
Description
Inputs
DBInformation
HWTemplatePath (FK)
SWTemplatePath (FK)
EnvironmentComments
ContextPreconditions
GeneralInstructions
Notes
Results
Observations
Steps
PostedBy (FK)
PostedIn
PostedDate
Action
AutomaticRun
LayerId
ExecutionPlanId
Path
RestrictedRun
IsAutomatable
EverAutomated
SubOrder
STAT_PriorityScenario
Id
Name
STAT_Scenario_Step
IdSc (FK)
IdTc (FK)
IdStep
Description
STAT_Sce nario
Id
TCId
ApprovedBy (FK)
ApprovalDate
Name
Author (FK)
AssignedTo (FK)
CreationDate
Status (FK)
Priority (FK)
Weight
Description
Inputs
DBInformation
HWTemplatePath (FK)
SWTemplatePath (FK)
EnvironmentComments
ContextPreconditions
GeneralInstructions
Notes
Results
Observations
LastUpdate
Locked
LastUpdatedBy
AutomaticRun
LayerId
ExecutionPlanId
EstimatedExecutionTime
Path
RestrictedRun
IsAutomatable
EverAutomated
SubOrder
STAT_Scenario_Attachme nt
IdSc (FK)
IdTc (FK)
IdAttach
AttachPath
STAT_ScenarioStatus
Id
Description
STAT_Tem plateType
Id
Name
Description
STAT_Templates
Id
ISET_Finis hedExe cutions
ExecutionId
ExecutionName
Comments
QueueSentTime
ExecutionTypeId (FK)
ProductId (FK)
BuildId (FK)
UserName
Machine
FinishedTime
Review Id
Type (FK)
Name
Description
ISET_FinishedExecutionsScenarios
ExecutionId (FK)
Id
TCId
ExecutionPlanId (FK)
LayerId (FK)
Status
Result
FailedStep
StartTime
EndTime
Comments
Review ed
Review Comments
Incident
Executor_Name
RestrictedRun
Version (FK)
STAT_Layers
LayerId
LayerName
ISET_Builds
BuildId
ProductId (FK)
BuildName
UserName
Description
CreationDate
TtpVersion
ISET_QueuedExecutions Sce narios
ExecutionId (FK)
Id
TCId
ExecutionPlanId (FK)
LayerId (FK)
Status
Result
FailedStep
StartTime
EndTime
Executor_Name
RestrictedRun
Version (FK)
ISET_Products
ProductId
ProductName
Description
ISET_QueuedExecutions
ExecutionId
ExecutionName
Comments
QueueSentTime
ExecutionTypeId (FK)
ProductId (FK)
BuildId (FK)
UserName
Machine
Status
Review Id
ScheduledStart
Dow nloadFiles
ISET_ExecutionTypes
ExecutionTypeId
Name
Description
ISET_HistoryExecutionsScenarios
ExecutionId (FK)
Id
TCId
ExecutionPlanId (FK)
LayerId (FK)
Status
Result
FailedStep
StartTime
EndTime
Review ed
Review Comments
Incident
Comments
Executor_Name
RestrictedRun
Version (FK)
STAT_Exe cutionPlans
ExecutionPlanId
Name
Description
ISET_His toryExecutions
ExecutionId
ExecutionName
Comments
QueueSentTime
ExecutionTypeId (FK)
ProductId (FK)
BuildId (FK)
UserName
Machine
FinishedTime
Review Id
STAT_ExecutionPlanSteps
ExecutionPlanId (FK)
StepId (FK)
StepExecutionOrder
STAT_ExecutionSteps
StepId
Name
StepPath
148
4.3.2.1. AdIntra-InSpec
IncidentId
AutoExecuted
Figura 77, Base de Datos de AdIntra-InSpec

149
El sistema InSpec fue desarrollado por la empresa AdIntra y adquirido por
BABEL para la automatización de los procesos de análisis de requerimientos
inicialmente. Este sistema permite registrar los requerimientos que componen los
sistemas, agrupándolos por pantallas, que a su vez se agrupan en módulos, que a
su vez se agrupan en sistemas. Además, para cada requerimiento permite asignar
escenarios de pruebas.
Al realizar un análisis de la información que almacena este sistema en su
Base de Datos, pudimos determinar que existe un abanico muy amplio de
posibilidades para poder obtener estadísticas como las que se buscan con el cubo
SAPRE. Sin embargo, debido a que no es la única fuente de datos, sino que está
relacionada con el sistema BugTracking, se debe tener en consideración
solamente aquellos conceptos que son relacionables entre ambas fuentes.
Además, otra limitante para utilizar toda la capacidad de esta Base de Datos, es
que el sistema no es muy utilizado en la empresa (se utiliza únicamente para
registrar los requerimientos sin mayor detalle), por lo que muchas funcionalidades
del sistema no almacenan información y aunque las tablas existen en la Base de
Datos, posiblemente muchas de ellas están vacías.
La principal razón de que no se utilice ampliamente el sistema, es porque
no genera una salida de gran valor, como lo sería un documento con la
especificación de los requerimientos en el formato que utiliza la empresa. Lo que
hace que se deban invertir muchas horas en alimentar el sistema sin poder
obtener nada a cambio, más que la digitalización de la información.
Dentro de los principales conceptos que se pueden obtener de esta fuente
de datos se encuentran:

150
- Información General del Desarrollador
- Información General del Gerente del Proyecto
- Información General del Proyecto (Módulos y Pantallas)

151
4.3.2.2. BugTracking
sysdiagram s
name
principal_id
diagram_id (PK)
version
definition
bugState
stateID (PK)
state
bugPriority
priorityID (PK)
priority
bugSeverity
severityID (PK)
severity
release
releaseID (PK)
projectID
releaseNumber
user
userLogin (PK)
userPassw
active
userGroup
groupID (PK)
groupName
perm ission
permissionID (PK)
permissionDetail
logType
idLogType (PK)
logTypeDescription
bug
bugID (PK)
logHeader
headerID (PK)
date
logTypeID (FK)
releaseID (FK)
priorityID (FK)
severityID (FK)
stateID (FK)
requirID
bugDetail
asignedTo (FK)
testedBy (FK)
bugName
requirementByUser
requirementID
userID (FK)
estimatedTime
realTime
usersInGroup
userID (FK)
groupID (FK)
perm issionInGroup
permissionID (FK)
groupID (FK)
logDetail
logDetailID (PK)
logHeaderID (FK)
detail
responsibleID
bugHistorical
bugHistorialID (PK)
bugID (FK)
stateID (FK)
date
durationHours
historyDetail
responsibleID
logBugCorrectionTim e
BugHistoryLogID (PK)
BugHistoryID (FK)
responsibleID (FK)
duration
date
Figura 78, Base de Datos de Bug Tracking

152
El sistema BugTracking fue desarrollado por BABEL Software para
automatizar el proceso de revisión o testing de aplicaciones que son desarrolladas
por la empresa para sus clientes.
Este sistema reutiliza información que se encuentra registrada en el sistema
AdIntra-InSpec para asociarla con las pulgas o errores que se van detectando en
el proceso de revisión.
A su vez, el sistema BugTraking almacena información relacionada con el
ciclo de vida de cada una de las pulgas que se registran. Esta información es
utilizada por el cubo SAPRE para incorporar los siguientes conceptos:
- Datos de la pulga
- Tiempos de corrección
- Estado de las pulgas
- Fechas (ingreso, modificación, cierre)
- Gravedad de la pulga
- Tipo de pulga
- Información General del Tester (Analista de Calidad)

153
4.3.3. Análisis técnico de dimensiones y métricas
Después de analizar la necesidad de los clientes -en este caso las
Gerencias de Desarrollo, de Calidad y de Proyectos de la empresa-, y de analizar
las fuentes de datos de donde se puede obtener la información, se observó que se
puede generar un cubo que contenga las siguientes dimensiones y métricas:
4.3.3.1. Dimensiones
Datos de la pulga: Corresponde a la información que se almacena actualmente
en relación con los incidentes detectados durante el periodo de testing. Estos
datos son:
- Identificador de la pulga
- Nombre
- Descripción
Desarrollador: Corresponde a la información del programador que desarrolló el
requerimiento en el cual se detectó una pulga. La información que almacena
actualmente el BugTracking en relación con el programador es:
- Nombre del programador
- Correo electrónico
Rango de corrección: Corresponde a los rangos definidos en el BugTracking
para determinar la tendencia de los tiempos que tardan los equipos de proyectos
resolviendo los errores que cometen en la programación de los sistemas. Por
ejemplo: De 0 a 30 minutos, de 30 minutos a 1 hora y así sucesivamente. La
información que se almacena es:

154
- Rango de corrección
Estado de la pulga: Corresponde al catálogo de estados que puede tener una
pulga durante su ciclo de vida, desde que se reporta hasta que se cierra. El único
dato que se almacena es:
- Estado de la pulga
Fecha de ingreso de la pulga: Especifica la fecha en que se ingresó la
información de la pulga en el sistema BugTracking. La fecha posee una jerarquía
definida de la siguiente manera:
- Año
- Mes
- Día
Fecha de modificación de la pulga: Indica las fechas en que se modificó el
estado de una pulga a lo largo de su ciclo de vida. La fecha posee la siguiente
jerarquía:
- Año
- Mes
- Día
Gravedad de la pulga: Corresponde al catálogo de gravedad en que se puede
evaluar una pulga cuando se registra en el sistema BugTracking. La información
que se almacena en el sistema es:
- Gravedad de la pulga

155
Gerente del Proyecto: Corresponde a la información que almacena el sistema
BugTracking sobre el Gerente del Proyecto. Los datos que se registran son:
- Nombre del Gerente del Proyecto
Proyecto: Encierra la información referente a la estructura de un proyecto: sus
módulos y sus pantallas. Los datos que se almacenan son:
- Proyecto
- Módulo
- Pantalla
Pulgas sin atender: Establece los rangos de días que pasa una pulga sin atender
por parte del programador para su respectiva solución, como por ejemplo: de 0 a 5
días, de 5 a 7 días y así sucesivamente. El sistema almacena únicamente:
- Rango de días
Tester: Corresponde a la información que almacena el sistema BugTracking
acerca del Analista de Calidad que realizó las pruebas al requerimiento donde se
detectó la pulga. Los datos que se registran son:
- Correo Electrónico
- Nombre del Analista de Calidad
Tipo de pulga: Define la categoría de la pulga, en cuanto a si es de Interfaz
Gráfica, funcional o de otro tipo. En el sistema BugTracking se almacena la
siguiente información:
- Tipo de pulga

156
4.3.3.2. Métricas o Medidas
Cantidad de Pantallas: Representa la sumatoria de la cantidad de pantallas que
componen un módulo de un sistema.
Cantidad de Proyectos: Se orienta a la sumatoria de la cantidad de proyectos
para realizar agrupaciones por programador, por administrador de proyectos o por
rangos de fechas, por ejemplo.
Cantidad de Pulgas: Corresponde a la sumatoria de pulgas registradas en el
BugTracking. Esta medida, por ejemplo, puede ser agrupada por programador, por
sistema, por módulo, o por fechas.
Pulgas Ponderadas por Proyecto: Apunta a la sumatoria promedio de pulgas
por proyecto. Esta medida puede ser agrupada por programador, por sistema, por
módulo, o por fechas.
Pulgas por Pantalla: Es la sumatoria de pulgas agrupadas por pantalla, para
todos los sistemas que se han testeado y cuyos resultados se han registrado en la
aplicación BugTracking.
Pulgas por Pantalla Promedio: Se enfila a la sumatoria de los promedios de
pulgas por pantalla de cada módulo de cada sistema testeado.
Pulgas por Proyecto: Corresponde a la sumatoria de pulgas agrupadas por
proyecto, para todos los sistemas que se han testeado y cuyos resultados se han
registrado en la aplicación BugTracking.

157
Tiempo de Corrección de Pulgas: Orientado a la sumatoria de los tiempos de
corrección de pulgas para todos los sistemas que se han testeado y cuyos
resultados se han registrado en la aplicación BugTracking.

158
4.3.4. Diseño de la solución propuesta
Tal y como se indicó con anterioridad, para la generación del cubo de
información SAPRE fue necesaria la creación de un almacén de datos
(DataWarehouse) que se debe alimentar diariamente de los datos almacenados
por el sistema BugTracking el cual, a su vez, hace uso de información almacenada
en la Base de Datos del sistema AdIntra-InSpec.
Esta alimentación diaria desde la Base de Datos de BugTracking hacia el
DataWarehouse se realiza en horario nocturno, a fin de que los procesos de
extracción de datos no sobrecarguen la Base de Datos fuente y así evitar una baja
en el desempeño del sistema transaccional en el que se registran las pulgas.
En tal razón, la información que se analiza en el cubo SAPRE siempre
estará un día atrasado, pues la carga de la información correspondiente al día del
análisis se realizará hasta la noche de dicho día. Este comportamiento es propio
de un cubo de información.
En la figura 79 se aprecia el flujo lógico de los datos entre los sistemas,
hasta llegar al cubo de información.

159
Figura 79, Diagrama de la solución propuesta para SAPRE
Como se puede apreciar, el sistema transaccional BugTracking hace uso de
datos almacenados en la Base de Datos del sistema AdIntra-InSpec. Estos datos
corresponden principalmente a información de los requerimientos y los sistemas
que son testeados por los analistas del departamento de calidad de la empresa.
Esta información es necesaria para no duplicar datos en ambos sistemas al tener
que asociar una pulga con un requerimieto.
Vale señalar que el sistema BugTracking busca aprovechar la información
que ya está almacenada en la Base de Datos del sistema AdIntra-InSpec. Con
esto, se puede asociar la información existente de los requerimientos y los
sistemas, con la información nueva que se incluye sobre las pulgas, desde que se
registran hasta que se cierran. De esta manera, se evita tener que registrar
nuevamente la información de los sistemas, sus módulos y los requerimientos que
se están testeando y se reutiliza toda la estructura que ya fue registrada en el
sistema AdIntra-InSpec.
Durante las pruebas, toda la información que se registra sobre las pulgas
detectadas se almacena en la Base de Datos propia del sistema BugTracking. Por

160
eso, la principal fuente de datos para el DataWarehouse es la Base de Datos del
BugTracking. Sin embargo, siempre será necesario extraer algunos datos de los
sistemas, los módulos y los requerimientos registrados en el AdIntra-InSpec para
servir principalmente de dimensiones para el DataMart SAPRE.
En la siguiente figura se observa la información que se extrae desde cada
Base de Datos para cargar el DataWarehouse. En ella se aprecian claramente los
datos que se extraen desde la Base de Datos del sistema AdIntra-InSpec, así
como de la Base de Datos del sistema BugTracking con la intensión de cargar el
DataWarehouse. Para realizar estos procesos de extracción fue necesario
programar tareas que residen en el DataWarehouse y que diariamente se
encargan de hacer las cargas incrementales, complementando la información
existente. Estas tareas se basan en la tecnología Integration Services de Microsoft
SQL Server 2008 R2.
Figura 80, Diagrama de las fuentes de datos de SAPRE

161
Una vez cargado el DataWarehouse, se procede a realizar el análisis
multidimensional de los datos para generar el cubo de información SAPRE. Para
esto se requirió de la tecnología Analysis Services de Microsoft SQL Server 2008
R2.
Para la creación del cubo fue indispensable definir, primero, las medidas o
métricas y las dimensiones especificadas en la sección anterior. Estas
dimensiones y medidas fueron definidas de acuerdo a las necesidades
expresadas por los clientes (en este caso los Gerentes de Desarrollo, Calidad y
Proyectos) y a la restricción de información con que se cuenta en los sistemas
transaccionales.
Por último, una vez desarrollado el cubo de información, se establecieron
las consultas que el usuario podrá realizar para generar sus propios reportes o
informes basados en Microsoft Office Excel, los cuales se verán en el siguiente
apartado.

162
4.3.5. Diseño de los reportes de la herramienta
4.3.5.1. Indicadores
Como parte del análisis de la necesidad que viene a satisfacer esta
herramienta, se determinó una serie de indicadores que la herramienta debe
proveer para que sea útil para las gerencias que están patrocinando el proyecto.
Estos indicadores se logran por medio de cruces de variables, las cuales se
mencionan a continuación.
Los indicadores se clasifican en 2 grupos:
1. Indicadores para analizar el rendimiento en el desarrollo de sistemas
2. Indicadores para determinar patrones de comportamiento y distribución de
errores
Dentro del primer grupo se definieron los siguientes indicadores:
Cantidad de pulgas por programador por proyecto: Este indicador debe
mostrar la sumatoria de pulgas que han sido detectadas en los requerimientos que
fueron programados por cada programador en un proyecto específico.
Tiempo de corrección de pulgas por programador por proyecto: Este
indicador debe mostrar la sumatoria del tiempo que invierte cada programador en
corregir las pulgas que han sido detectadas en los requerimientos que fueron
programados por él en un proyecto específico. Este indicador corresponde al
retrabajo o al desperdicio que se genera durante la etapa de desarrollo de un
proyecto.

163
Cantidad de pantallas con errores por sistema: Este indicador debe mostrar la
cantidad de pantallas en que se han detectado pulgas para un sistema específico.
Como parte del segundo grupo de indicadores, enfocados al análisis de
comportamientos o patrones en la distribución de las pulgas, se definieron los
siguientes indicadores:
Cantidad de pulgas en el tiempo: Este indicador debe mostrar la distribución del
registro de pulgas a lo largo del tiempo. Se le puede agregar la variable
“programador” para evaluar el comportamiento de un individuo específico.
Cantidad de pulgas distribuidas en intervalos de tiempos de corrección: Este
indicador debe mostrar la cantidad de pulgas que han sido detectadas, distribuidas
en los intervalos de tiempo de corrección predefinidos en el BugTraking.
Tiempo de corrección de pulgas distribuidas en intervalos de tiempos de
corrección: Este indicador debe mostrar la sumatoria del tiempo invertido en la
corrección de pulgas, distribuido en los intervalos de tiempo de corrección
predefinidos en el BugTraking.
4.3.5.2. Reportes
Para visualizar estos indicadores gráficamente se hace uso de la
herramienta Microsoft Excel, desde la cual se establece una conexión con el cubo
para poder obtener los indicadores mencionados anteriormente y desde ahí poder

164
manipular la información al gusto del usuario, hasta llegar incluso al nivel de
graficación que permite Excel sobre las tablas Pivote.
A continuación se describe el proceso que se debe seguir para conectar
Excel con el cubo SAPRE para después generar los indicadores y posteriormente
complementar estos reportes con gráficos y otra funcionalidad que adiciona Excel.
Como primer paso se debe abrir una nueva hoja de cálculo en Excel y dar
clic en el menú Datos, en donde aparecerá la opción de “Obtener datos externos”.
Figura 81, Sección de datos de Microsoft Excel
Al hacer clic ahí se despliega un submenú con varias opciones, de las que
se deberá seleccionar la opción “De otras fuentes” y posteriormente “Desde
Analysis Services”.

165
Figura 82, Sección de Otras fuentes de Microsoft Excel
Aparecerá una ventana emergente en donde se debe indicar la dirección en
donde se encuentra ubicado el servidor en donde reside el cubo.
Figura 83, Conectar con el servidor de bases de datos de tabla pivote de Excel

166
Posteriormente se debe seleccionar la Base de Datos DataWarehouse de donde
se alimenta el cubo, para filtrar los cubos y poder seleccionar el cubo SAPRE más
fácilmente.
Figura 84, Seleccionar base de datos y tabla de tabla pivote de Excel
Se debe seleccionar el cubo y dar clic en el botón Finalizar para continuar
con el proceso de creación.
Por último se debe indicar si se desea generar el cubo en una hoja
existente o en una hoja nueva. Esto es a gusto del usuario.

167
Figura 85, Importación de datos de la tabla pivote de Excel
Al dar clic en el botón Aceptar se genera la tabla pivote en el Excel y se
conecta al cubo para comenzar a generar los reportes que se desean, basados en
los indicadores definidos.
4.3.5.2.1. Reporte 1: Cantidad de pulgas por programador por
proyecto
Para generar el primer reporte con el indicador de la cantidad de pulgas por
programador por proyecto, se debe primero arrastrar el cálculo de la cantidad de
pulgas al cuadro de valores de la tabla pivote.

168
Figura 86, Creación reporte 1 en Excel, paso 1
Luego se debe arrastrar la información de los programadores en el cuadro
de Etiquetas de Fila para distribuir la totalidad de las pulgas por cada
programador, independientemente de los proyectos en los que se haya generado
cada pulga.

169
Figura 87, Creación reporte 1 en Excel, paso 2
Por último se debe arrastrar la información del Proyecto en el cuadro de
Etiquetas de columnas para distribuir las pulgas no solo por empleado, sino
también por Proyecto.

170
Figura 88, Creación reporte 1 en Excel, paso 3
Con esto se tiene una distribución de las pulgas que cada programador ha
provocado en cada uno de los sistemas testeados por el departamento de Calidad
de la empresa.
Finalmente, se puede manipular la información para graficar un proyecto
específico, como en el siguiente caso:

171
Figura 89, Gráfica del reporte 1 en Excel
Así se puede determinar visualmente y de una manera muy sencilla, sobre
cuáles programadores están cayendo la mayor cantidad de retrabajo producido
por errores de codificación y tomar las acciones correspondientes.
El dato que aparece sin registrar indica que se detectaron pulgas en
requerimientos que no tienen asociado un programador en el sistema AdIntra-
InSpec.
4.3.5.2.2. Reporte 2: Tiempo de corrección de pulgas por
programador por proyecto
Para generar este reporte con el indicador de la acumulación de tiempo de
corrección de pulgas por programador por proyecto, se debe primero arrastrar el
cálculo del tiempo de corrección de pulgas al cuadro de valores de la tabla pivote.

172
Figura 90, Creación reporte 2 en Excel, paso 1
Luego se debe arrastrar la información de los programadores en el cuadro
de Etiquetas de Fila para distribuir la totalidad del tiempo de corrección de las
pulgas por cada programador, independientemente de los proyectos en los que se
haya invertido el tiempo.

173
Figura 91, Creación reporte 2 en Excel, paso 2
Por último se debe arrastrar la información del Proyecto en el cuadro de
Etiquetas de columnas para distribuir el tiempo de corrección de las pulgas no solo
por empleado, sino también por Proyecto.

174
Figura 92, Creación reporte 2 en Excel, paso 3
Con esto se tiene una distribución del tiempo de corrección de las pulgas
que cada programador invierte en cada uno de los sistemas testeados por el
departamento de Calidad de la empresa.
Finalmente, se puede manipular la información para graficar un proyecto
específico, como en el siguiente caso:

175
Figura 93, Gráfica del reporte 2 en Excel
4.3.5.2.3. Reporte 3: Cantidad de pantallas con errores por
sistema
Para generar este reporte con el indicador de la cantidad de pantallas con
pulgas por sistema, se debe primero arrastrar el cálculo de la cantidad de
pantallas al cuadro de valores de la tabla pivote.

176
Figura 94, Creación reporte 3 en Excel, paso 1
Luego se debe arrastrar la información de los proyectos en el cuadro de
Etiquetas de Fila para distribuir la totalidad de las pantallas con errores por cada
proyecto, para obtener la cantidad de pantallas con pulgas que cada sistema tiene.

177
Figura 95, Creación reporte 3 en Excel, paso 2
Finalmente, se puede manipular la información para graficar un proyecto
específico, como en el siguiente caso:

178
Figura 96, Creación reporte 3 en Excel, paso 3
Así como se pueden generar estos reportes para analizar el desempeño de
los miembros del equipo de un proyecto específico, también se pueden generar
otros reportes interesantes que muestran tendencias que pueden ayudar a un
gerente de proyectos a tomar decisiones antes de que acontezcan situaciones que
pongan en riesgo el proyecto.
Como parte de los indicadores de comportamiento y patrones en la
distribución de pulgas, se definieron los siguientes reportes.
4.3.5.2.4. Reporte 4: Cantidad de pulgas en el tiempo
Lo primero que se debe hacer para generar este reporte con el indicador de
la cantidad de pulgas en el tiempo, es arrastrar el cálculo de la cantidad de pulgas
al cuadro de valores de la tabla pivote.

179
Figura 97, Creación reporte 4 en Excel, paso 1
Posteriormente se debe arrastrar la información de las fechas en que se
reportaron pulgas, en el cuadro de Etiquetas de Fila para distribuir la totalidad de
las pulgas a lo largo del tiempo.

180
Figura 98, Creación reporte 4 en Excel, paso 2
Nótese cómo al agregar una dimensión que posee jerarquías, como las
fechas, se puede desagregar la información (hacer drill-down) a un nivel de
semestre, trimestre, mes e incluso día.
Igualmente esta información se puede graficar para sacar conclusiones de
una manera visual y mucho más práctica.

181
Figura 99, Gráfica del reporte 4 en Excel
4.3.5.2.5. Reporte 5: Cantidad de pulgas distribuidas en
intervalos de tiempos de corrección
Lo primero que se debe hacer para generar este reporte con la cantidad de
pulgas en intervalos de tiempos de corrección, es arrastrar el cálculo de la
cantidad de pulgas al cuadro de valores de la tabla pivote.

182
Figura 100, Creación reporte 5 en Excel, paso 1
En el sistema BugTracking existe una definición de intervalos de tiempo
para categorizar las pulgas de acuerdo a su tiempo de corrección y con esto dar
una idea del tiempo promedio que se requiere para corregir una pulga.
Para completar este reporte, se debe arrastrar la información de la
dimensión de rangos de fechas de corrección, en el cuadro de Etiquetas de Fila
para distribuir la totalidad de las pulgas en los rangos definidos en el sistema
BugTracking.

183
Figura 101, Creación reporte 5 en Excel, paso 2
Finalmente, esta información se puede graficar para presentar los
resultados de una manera más agradable y fácil de entender.

184
Figura 102, Gráfica del reporte 5 en Excel
4.3.5.2.6. Reporte 6: Tiempo de corrección de pulgas distribuidas
en intervalos de tiempos de corrección
Para generar este reporte con la sumatoria del tiempo asignado a la
corrección de pulgas, distribuido en los mismos intervalos de tiempo descritos en
el reporte anterior, primero se debe arrastrar el cálculo de la sumatoria del tiempo
total invertido en la corrección de pulgas al cuadro de valores de la tabla pivote.

185
Figura 103, Creación reporte 6 en Excel, paso 1
Posteriormente, se debe arrastrar la información de la dimensión de rangos
de fechas de corrección, en el cuadro de Etiquetas de Fila para distribuir la
totalidad de las pulgas en los rangos definidos en el sistema BugTracking.

186
Figura 104, Creación reporte 6 en Excel, paso 2
Uniendo los dos últimos gráficos se pueden obtener conclusiones muy
interesantes en cuanto al patrón de rendimiento y tendencia de tipos de errores
que se cometen en la empresa, durante el desarrollo de software.
Por ejemplo, el gráfico del reporte anterior muestra una tendencia muy
fuerte a que la mayor cantidad de pulgas sean corregidas en el rango de 0 a 30
minutos. Sin embargo, complementándose con este último reporte, se puede
apreciar que aunque son muy pocas las pulgas en el rango de más de 5 horas,
representan una suma muy importante de tiempo de corrección.
Este tipo de análisis se propicia con la herramienta desarrollada y queda a
gusto de los usuarios la generación sus propios informes para explotar al máximo
la capacidad de la herramienta desarrollada y sacarle el máximo provecho.

187
Ejecución del Proyecto
En este apartado se detallará lo sucedido durante la elaboración del cubo de
información SAPRE:
• Antes de iniciar oficialmente el proyecto, analizamos los conocimientos de los 2
desarrolladores con los que se iba a realizar el mismo, encontrándose que
éstos tenían muy poca experiencia en la elaboración de cubos de información,
pero sí dominaban el uso de la herramienta SQL SERVER 2008, por lo que se
tuvo que posponer la fecha de inicio de proyecto del 3 de enero al 17 de enero
del 2011, con el fin de que los desarrolladores pudieran capacitarse para poder
llevar a cabo el producto, lo que implicaría que el tiempo de desarrollo se
acortaría.
• Durante la primera semana de ejecución se detectó un retraso en la toma de
requerimientos, debido a la disponibilidad de los patrocinadores y de que hubo
que negociar algunos requerimientos debido al tiempo que se tenía para la
elaboración del sistema.
• Posterior la primera semana, se detectó un ligero atraso en el avance del
proyecto, ya que para llevar el control se empleó el método “Valor Ganado”, el
cual dio el siguiente resultado:
Cuadro 21. Valor ganado de la primera semana del proyecto SAPRE
Datos Montos Interpretación
BCWS(PV) $1,040.00 Costo presupuestado del trabajo calendarizado es de$1040
BCWP(EV) $649.65 Costo presupuestado del trabajo realizado es de $649.65
ACWP(AC) $533.00 Costo actual del trabajo realizado $533
BAC $8,520.67 El proyecto cuesta $8520.67

188
Datos Montos Interpretación
CV $116.65 El proyecto está por debajo de lo presupuestado en $116.65
CPI 1.219 El proyecto va mejor de lo planeado en $0.21
SV
($390.35) El proyecto va atrasado en el cronograma
SPI
0.625 El proyecto está avanzando al 62.46% de lo planificado
CSI
0.76 El proyecto está en estado VERDE
Figura 105, Grafica del valor ganado de la primera semana de SAPRE
• Finalizada la primera semana, se buscó mejorar los tiempos con respecto a la
elaboración de los planes, intentando mejorar el ambiente de trabajo para que
los recursos humanos se enfocarán más.
• También se inició, en paralelo, los procesos de extracción en donde, a pesar
de los esfuerzos hechos con la capacitación, se identificó que se estaba

189
necesitando más esfuerzo y tiempo por parte de los desarrolladores para
realizar la tarea.
• Alcanzado el segundo corte, se encontró que hubo una mejora significativa con
respecto a la elaboración de los planes, pero se detectó el atraso en la primera
tarea del desarrollo, lo cual permitió levantar la bandera de alerta. Los datos
obtenidos en este segundo corte fueron:
Cuadro 22. Valor ganado de la segunda semana del proyecto SAPRE
Datos Montos Interpretación
BCWS(PV) $1,565.42 Costo presupuestado del trabajo calendarizado es de$1565.42
BCWP(EV) $1,389.53 Costo presupuestado del trabajo realizado es de $1389.53
ACWP(AC) $1,254.50 Costo actual del trabajo realizado $1254.5
BAC $8,520.67 El proyecto cuesta $8520.67
CV $135.03 El proyecto está por debajo de lo presupuestado en $135.03
CPI 1.108 El proyecto va mejor de lo planeado en $0.1
SV
($175.89) El proyecto va atrasado en el cronograma
SPI
0.888 El proyecto está avanzando al 88.76% de lo planificado
CSI
0.98 El proyecto está en estado VERDE
Figura 106, Gráfica del valor ganado de la segunda semana de SAPRE

190
• En esta semana y con el fin de dar más tiempo al desarrollo se procedió, con
urgencia, a terminar los planes y apoyar de lleno al desarrollo para solventar la
falta de experiencia.
• A pesar del esfuerzo puesto en el proceso de extracción de datos, hubo que
trabajar más tiempo de lo estimado para alcanzar la meta y aún así no se pudo
terminar al 100 por ciento.
• Luego, en el tercer corte, se notó que las tareas costaban más dinero de lo
estimado.
Cuadro 23. Valor ganado de la tercera semana del proyecto SAPRE
Datos Montos Interpretación
BCWS(PV) $1,786.42 Costo presupuestado del trabajo calendarizado es de$1786.42
BCWP(EV) $1,662.53 Costo presupuestado del trabajo realizado es de $1662.53
ACWP(AC) $1,885.00 Costo actual del trabajo realizado $1885
BAC $8,520.67 El proyecto cuesta $8520.67
CV $ (222.47) El proyecto está por encima de lo presupuestado en $222.47
CPI 0.882 El proyecto va peor de lo planeado en $1.88
SV
($123.89) El proyecto va atrasado en el cronograma
SPI
0.931 El proyecto está avanzando al 93.06% de lo planificado
CSI
0.82 El proyecto está en estado VERDE

191
Figura 107, Grafica del valor ganado de la tercera semana de SAPRE
• Se logra terminar la extracción de datos, sin dificultad.
• Posteriormente, se identifica un problema similar al de la extracción de datos,
esto es, debido a la falta de experiencia las tareas toman más tiempo de lo
estimado.
• Luego del análisis de “Valor Ganado”, se detecta un aumento significativo en la
variación del costo, así como en el avance del cronograma, lo que lleva a
poner en riesgo la finalización del proyecto en el plazo establecido, por lo que
se toma la decisión de incorporar a un recurso humano más, con experiencia
en el desarrollo de cubos de información.
Cuadro 24. Valor ganado de la cuarta semana del proyecto SAPRE

192
Datos Montos Interpretación
BCWS(PV) $2,436.42 Costo presupuestado del trabajo calendarizado es de$2436.42
BCWP(EV) $2,033.95 Costo presupuestado del trabajo realizado es de $2033.95
ACWP(AC) $2,730.00 Costo actual del trabajo realizado $2730
BAC $8,520.67 El proyecto cuesta $8520.67
CV $ (696.05) El proyecto está por encima de lo presupuestado en $696.05
CPI 0.745 El proyecto va peor de lo planeado en $1.74
SV
($402.47) El proyecto va atrasado en el cronograma
SPI
0.835 El proyecto está avanzando al 83.48% de lo planificado
CSI 0.62 El proyecto es en un estado AMARILLO: \
Figura 108. Gráfica del valor ganado de la cuarta semana de SAPRE
• Con la incorporación de este nuevo recurso, se logra acortar el tiempo de la
transformación de datos y del proceso de carga datos.

193
• Se logra encaminar de nuevo al sistema, ya que al incorporar un nuevo recurso
al proyecto se reduce la variación del costo y se recupera el avance según el
cronograma, lo que ayuda a encaminar de nuevo el proyecto.
Cuadro 25. Valor ganado de la quinta semana del proyecto SAPRE
Datos Montos Interpretación
BCWS(PV) $3,112.42 Costo presupuestado del trabajo calendarizado es de$3112.42
BCWP(EV) $3,395.90 Costo presupuestado del trabajo realizado es de $3395.9
ACWP(AC) $4,043.00 Costo actual del trabajo realizado $4043
BAC $8,520.67 El proyecto cuesta $8520.67
CV $(647.10) El proyecto está por encima de lo presupuestado en $647.1
CPI 0.840 El proyecto va peor de lo planeado en $1.83
SV
$283.48 El proyecto va adelantado
SPI
1.091 El proyecto está avanzando al 109.1% de lo planificado
CSI
0.92 El proyecto está en estado VERDE

194
Figura 109, Grafica del valor ganado de la quinta semana de SAPRE
• Con la carga de datos, el nuevo recurso vino a ejercer una función más que
todo de guía y apoyo, lo cual favoreció el avance según lo establecido en el
cronograma, pero no se logró mejorar el costo acumulado del proyecto.
• Se inicia, con nuevos bríos, la creación de los reportes de indicadores.
• El análisis de valor ganado mostró los siguientes resultados:
Cuadro 26. Valor ganado de la séptima semana del proyecto SAPRE
Datos Montos Interpretación

195
Datos Montos Interpretación
BCWS(PV) $3,788.42 Costo presupuestado del trabajo calendarizado es de$3788.42
BCWP(EV) $4,383.45 Costo presupuestado del trabajo realizado es de $4383.45
ACWP(AC) $5,239.00 Costo actual del trabajo realizado $5239
BAC $8,520.67 El proyecto cuesta $8520.67
CV $ (855.55) El proyecto está por encima de lo presupuestado en $855.55
CPI 0.837 El proyecto va peor de lo planeado en $1.83
SV
$595.03 El proyecto va adelantado
SPI
1.157 El proyecto está avanzando al 115.7% de lo planificado
CSI
0.97 El proyecto está en estado VERDE
Figura 110. Gráfica del valor ganado de la séptima semana de SAPRE

196
• La creacion de los reportes transcurrio con pocos incidentes y a un buen ritmo,
lo cual ayudó a mejorar los costos del proyecto, pero se notó una leve pérdida
en el avance del cronograma, que a pesar de su mejora, disminuyó
ligeramente.
• Se habló con los patrocinadores para notificarles que se estaría empezando
con las pruebas.
• El análisis del valor ganado dio los siguientes resultados:
Cuadro 27. Valor ganado de la octava semana del proyecto SAPRE
Datos Montos Interpretación
BCWS(PV) $4,464.42 Costo presupuestado del trabajo calendarizado es de$4464.42
BCWP(EV) $5,129.19 Costo presupuestado del trabajo realizado es de $5129.19
ACWP(AC) $6,305.00 Costo actual del trabajo realizado $ 6305
BAC $8,520.67 El proyecto cuesta $8520.67
CV $(1,175.81) El proyecto está por encima de lo presupuestado en $1175.81
CPI 0.814 El proyecto va peor de lo planeado en $1.81
SV
$664.77 El proyecto va adelantado
SPI
1.149 El proyecto está avanzando al 114.89% de lo planificado
CSI
0.93 El proyecto está en estado VERDE

197
Figura 111. Gráfica del valor ganado de la octava semana de SAPRE
• Se terminaron los reportes y se empezó con el proceso de calidad, en donde
se encontró que debido a que los patrocinadores (los cuales tenían que
participar en el proceso de calidad) estaban precarios de tiempo como para
dedicarse a depurar el sistema lo cual ocasionó un atraso que fue compensado
con los adelantos en cronograma que se habían obtenido en las actividades
anteriores.
• A pesar de los atrasos, los indicadores indicaron una mejoría tanto en el costo
como en el avance del cronograma del proyecto, lo cual fue bien recibido, pero
se mantuvo la preocupación del atraso identificado en las pruebas.

198
Cuadro 28. Valor ganado de la novena semana del proyecto SAPRE
Datos Montos Interpretación
BCWS(PV) $5,140.42 Costo presupuestado del trabajo calendarizado es de$5140.42
BCWP(EV) $5,951.95 Costo presupuestado del trabajo realizado es de $5951.95
ACWP(AC) $7,567.00 Costo actual del trabajo realizado $7567
BAC $8,520.67 El proyecto cuesta $8520.67
CV $ (1,615.05) El proyecto está por encima de lo presupuestado en $1615.05
CPI 0.787 El proyecto va peor de lo planeado en $1.78
SV
$811.53 El proyecto va adelantado
SPI
1.158 El proyecto está avanzando al 115.78% de lo planificado
CSI
0.91 El proyecto está en estado VERDE

199
Figura 112. Gráfica del valor ganado de la novena semana de SAPRE
• Al continuar con las pruebas, se presentó el mismo problema con los
patrocinadores, por lo que se les solicito -de manera formal- que se agendaran
reuniones impostergables para cumplir con las fechas establecidas, lo cual fue
aceptado.
• Se aprovechó, por parte del equipo de desarrollo, para corregir algunas de las
inconsistencias encontradas (con el fin de adelantar trabajo) y, ademas, se
procedió a insertar valores de otros proyectos en el sistema BucktTracking, con
fienes de análisis y pruebas.
• Luego de la valoracion del valor ganado, se obtuvieron los siguientes
resultados:
Cuadro 29. Valor ganado de la décima semana del proyecto SAPRE
Datos Montos Interpretación
BCWS(PV) $6,026.42 Costo presupuestado del trabajo calendarizado es de$6026.42
BCWP(EV) $6,818.60 Costo presupuestado del trabajo realizado es de $6818.6
ACWP(AC) $9,227.00 Costo actual del trabajo realizado $9227
BAC $8,520.67 El proyecto cuesta $8520.67
CV $(2,408.40) El proyecto está por encima de lo presupuestado en $2408.4
CPI 0.739 El proyecto va peor de lo planeado en $1.73
SV
$792.18 El proyecto va adelantado
SPI
1.131 El proyecto está avanzando al 113.14% de lo planificado
CSI
0.84 El proyecto está en estado VERDE

200
Figura 113. Gráfica del valor ganado de la décima semana de SAPRE
• Más adelante, se logró invertir más tiempo en la ejecucion de las pruebas, pero
con el propósito de disminuir los costos, se rescindió del tiempo del experto en
desarrollo de cubos, ya que en estos procesos no se ocupaba de tanto el
apoyo. Con esto terminan las pruebas.
• Se incia el proceso de correccion de inconsistencias, donde se vuelve a incluir
al experto en desarrollo de cubos, y es aquí donde en se logra acortar el
tiempo estimado para la correccion, dando por terminada las correcciones.
• Además, se incia con los procesos de intalacion del sistema en los servidores
de la empresa.

201
Cuadro 30. Valor ganado de la décima primera semana del proyecto SAPRE
Datos Montos Interpretación
BCWS(PV) $7,692.42 Costo presupuestado del trabajo calendarizado es de$7692.42
BCWP(EV) $7,932.57 Costo presupuestado del trabajo realizado es de $7932.57
ACWP(AC) $10,831.00 Costo actual del trabajo realizado $10831
BAC $8,520.67 El proyecto cuesta $8520.67
CV $(2,898.43) El proyecto está por encima de lo presupuestado en $2898.43
CPI 0.732 El proyecto va peor de lo planeado en $1.73
SV
$240.15 El proyecto va adelantado
SPI
1.031 El proyecto está avanzando al 103.12% de lo planificado
CSI
0.76 El proyecto está en estado VERDE

202
Figura 114. Gráfica del valor ganado de la décima primera semana de SAPRE
• Se prosigio con la instalacion, la cual tambien demoró menos de los esperado.
• Se procedio a realizar la reunión de cierre con los patrocinadores.
• El último corte del valro ganado mostró los siguientes datos:
Cuadro 31. Valor ganado de la décima segunda semana del proyecto SAPRE
Datos Montos Interpretación
BCWS(PV) $8,046.67 Costo presupuestado del trabajo calendarizado es de$8046.67
BCWP(EV) $8,520.32 Costo presupuestado del trabajo realizado es de $8520.32
ACWP(AC) $11,060.00 Costo actual del trabajo realizado $11060
BAC $8,520.67 El proyecto cuesta $8520.67
CV $(2,539.68) El proyecto está por encima de lo presupuestado en $2539.68
CPI 0.770 El proyecto va peor de lo planeado en $1.77
SV
$473.65 El proyecto va adelantado
SPI
1.059 El proyecto está avanzando al 105.88% de lo planificado
CSI
0.82 El proyecto está en estado VERDE

Figura 115. Gráfica del valor ganado de la décima segunda semana de SAPRE
203

204
5. CONCLUSIONES
Si se quiere, la principal conclusión que se desprende de este estudio es que
se logró identificar que el desarrollo de los diferentes planes de gestión para el
proyecto permite un mejor y mayor control sobre el día a día de aquél, pese a los
imprevistos que, sin duda, se presentarán. No obstante, estos mismos planes
ayudarán a manejarlos con un mayor control.
Pero es importante tener presente que esto tendrá éxito, sí y sólo sí, se está al
día con el proyecto para darle un seguimiento adecuado. Es decir, de poco servirá
la planeación si los distintos procesos no se acompañan en el tiempo y en el
espacio. Recuérdese que lo que pasa durante el proyecto es fundamental para
alcanzar los objetivos y lograr que el proyecto sea un éxito desde cualquier ángulo
que se le mire.
Sin duda, un común denominador de todo proyecto son los imprevistos, con los
cuales siempre habrá que lidiar, más allá de experiencia profesional y de la
correcta planeación. De ahí la importancia del día a día y los cambios pertinentes
que el tiempo marque, con el fin último de mantener el proyecto en curso. No debe
olvidarse que un pequeño problema mal atendido se puede convertir en un grave
problema, que no sólo cuesta tiempo, sino también dinero.
Por demás, ha de tenerse presente que los procesos de revisión de
inconsistencias son vitales para el logro de las metas propuestas. Dependiendo de
cómo haya resultado el proceso de seguimiento y control, existe la posibilidad de
que se disgreguen algunos pequeños requerimientos y, es en esta etapa del
proceso de elaboración donde se capturan, para así evitarle al cliente que reporte

205
inconsistencias, que pueden redundar en una equivocada percepción de la
empresa y, en consecuencia, una pérdida de confianza por parte de los clientes.

206
6. RECOMENDACIONES
De lo anterior se derivan las siguientes recomendaciones:
• Capacitar al personal del departamento de Calidad, esto con el fin de que
sean ellos mismos, lo que con esta nueva herramienta definan estándares
internos de documentación de las inconsistencias (pulgas), esto con el fin
de que ellos mismos puedan ayudar a generar mejores reportes.
• Hacer conciencia en el personal del departamento de Calidad, con el fin de
que hagan una mayor costumbre en ingresar todas las inconsistencias en el
sistema “Bug Tracking”, esto ya que se detectó que hay ciertas
inconsistencias (ej.: la falta de tildes en las pantallas) que no ingresan, lo
cual puede implicar poco tiempo de detección, registro de la misma y
corrección, pero cuando esto se manifiesta muchas veces si llega consumir
gran cantidad de tiempo, por lo que se requeriría mediante algún método el
mitigar la aparición de estas pequeñas pero considerables inconsistencias.
• Estar recalcando periódicamente en la importancia del uso de estas
herramientas, ya que de ellas van a depender no solo ciertas decisiones en
los proyectos en curso, si no que dependerán muchas otras decisiones
gerenciales y a nivel de personal, las cuales si no se cuenta con
información fidedigna, llevaría a cometer errores que podrían implicar
mucho dinero.

207
• Capacitar a todo el personal que esté a cargo de la gerencia de proyectos,
con el fin de que estos puedan usar esta nueva herramienta para generar
reportes que ayuden al crecimiento del personal que tengan a cargo o bien
para determinar cuáles podrían ser cambios necesarios para los actuales
proyectos, así como para los futuros, el cómo podrían conformar un equipo
más acorde al proyecto por empezar.
• Concientizar en los gerentes de proyectos de la gran importancia de dar
retroalimentación de los involucrados en el proyecto con el fin de que la
empresa pueda seguir creciendo de la mejor manera posible.
• Trabajar conjuntamente con el departamento de Recursos Humanos, con el
fin de poder determinar a qué personal se le puede reconocer de alguna
forma, el esfuerzo brindado hacia el proyecto y hacia la empresa, y del
mismo modo, ver cuales recursos no están generando ingresos y sus
motivos y considerar el sustituirlos.
• Hacer la cultura entre los equipos de trabajo, el que estén revisando sus
progresos individuales y generales cada cierto tiempo de tiempo con el fin
de ayudar a detectar riesgos lo antes posible, para evitar que estos causen
problemas en algunas de las áreas del proyecto.
• Para lo que respecta a actividades en los que se depende de otras
personas que no están tan involucradas en el proceso, como lo puede ser
en el proceso de revisión del producto, siempre procurar contar con
personas de respaldo, esto para que en caso de las personas asignadas no
tengan el tiempo necesario de llevar a cabo dichas actividades, puedan ser

208
sustituidos, temporalmente, por otras personas, para así evitar atrasos en la
ejecución de dichas actividades.

209
7. BIBLIOGRAFÍA
BABEL (2010). Servicios de BABEL . Extraído el 1 diciembre,
2010, de http://www. BABEL .cr/desarrollo-software-a-medida.html
BABEL (2010). Acerca de BABEL . Extraído el 1 diciembre,
2010, de http://www. BABEL .cr/ BABEL -software.html
Chamoun, Y. (2002). Administración profesional de Proyectos. La Guía. México:
McGraw-Hill.
Daccach, J. (2007) Administración de Proyectos. Extraído el 30 de abril, 2010, de
http://www.degerencia.com/articulo/administracion_de_proyectos.
Project Management Institute (PMI) (2008). Guía de los Fundamentos de la
Dirección de Proyectos. PMBOK Guide. Pennsylvania: PMI Publications.
Ortíz Rida, Pilar María (2006) Metodología de la investigación. El proceso y sus
técnicas. México: Noriega Editores (Limusa)
ARÓSTEGUI (2001) La investigación histórica: teoría y método. Editorial Crítica

210
8. ANEXOS
8.1. Anexo 1: ACTA CONSTITUTIVA DEL PFG
Cuadro 32. Acta Constitutiva del PFG
ACTA DEL PROYECTO
Fecha
Nombre de Proyecto
Implementación de un Sistema de
Activos de Procesos de Rendimiento
10-Noviembre-2010
y Eficiencia
- SAPRE -
Áreas de conocimiento /
Área de aplicación (Sector /
procesos:
Actividad):
• Gestión de la Integración
o Desarrollar el Acta de
Constitución del Proyecto
o Dirigir y Gestionar la Ejecución
del Proyecto
o Monitorear y Controlar el
Trabajo del Proyecto
o Cerrar Proyecto o Fase
• Gestión del Alcance
o Recopilar Requisitos
o Crear la EDT
o Controlar el Alcance
• Gestión del Tiempo
o Definir las Actividades
o Secuenciar las Actividades
o Estimar los Recursos de las
Actividades
o Estimar la Duración de las
Actividades
o Desarrollar el Cronograma
o Controlar el Cronograma
• Gestión de Costos
o Estimar los Costos
o Determinar el Presupuesto
o Controlar los Costos
Tecnologías de Información

211
• Gestión de la Comunicación
o Identificar a los Interesados
o Planificar las comunicaciones
o Informar el desempeño
• Gestión del Riesgo
o Identificar los Riesgos
o Planificar la Respuesta a los
Riesgos
Fecha de inicio del proyecto
Fecha tentativa de finalización del
proyecto
03 de noviembre del 2011 15 de marzo del 2011
Objetivos del proyecto (general y específicos)
Objetivo General
• Maximizar la capacidad de análisis del rendimiento de los miembros de los
equipos de proyectos, mediante el desarrollo de una herramienta de
inteligencia de negocios enfocada en el Control de Calidad de los
entregables dentro del proceso de fabricación del software.
Objetivos Específicos
• Contar con una herramienta que permita efectuar un análisis del
rendimiento e índices de retrabajo de los miembros de proyectos, en todos
los proyectos en general, sin limitarse a un análisis para un proyecto
específico.
• Generar activos de procesos de la organización, basados en estadísticas
generales de rendimiento por persona, por etapa del proceso y por fechas.
• Brindar retroalimentación a los miembros de los equipos de proyectos en la
etapa de cierre, de su rendimiento tanto en ese proyecto que cierra, como
en su historial de proyectos en la empresa.

212
Justificación o propósito del proyecto (Aporte y resultados esperados)
Actualmente existe un sistema de control de inconsistencias en la empresa, la
cual registra cual fue el desarrollador encargado del requerimiento, cuales
inconsistencias fueron detectadas en esa sección del código y cuánto tiempo
duró el desarrollador en corregir dichas inconsistencias, a lo que con el actual
sistema se puede generar un reporte que lo único que indica son totalizaciones,
agrupadas por los diferentes rubros (desarrollador, requerimiento) y se pueden
ordenar ya sea descendentemente o ascendentemente, lo que es adecuado
para las funciones iniciales del sistema existente.
Sin embargo, con el pasar del tiempo, otras áreas fueron solicitando dichos
reportes para analizarlos para sus propios fines, a lo que se fueron
descubriendo que hacía falta información importante, que el sistema actual si
estaba almacenando pero no fue contemplando a la hora de desarrollar los
reportes actuales, por lo que los diferentes departamento se vieron obligados a
revisar directamente la base de datos o bien buscar otros métodos para
obtener la información que necesitaban (que en muchos casos, simplemente se
tomó tomo la decisión de omitir dicho análisis). Debido al crecimiento de la
empresa, se intentó retomar estas análisis pero se encontraron con que
tomaba mucho tiempo en realizarlo, ya que se necesitaba tiempo de los
gerentes encargados de los reportes, de los desarrolladores para extraer la
información que no estaba en los reportes actuales, y aun así la información
entre los reportes era muy difícil de relacionar, por lo que se decidió hacerlos
solo cuando fuera estrictamente necesario.

213
Ahora con la elaboración del sistema que se plantea en este proyecto, se
pretende dar fin a esta problemática, ya que utilizando un cubo de información
que tenga como fuente de datos la base de datos que alimenta el actual
sistema, se le brindara a los diferentes departamentos con una herramienta de
análisis, donde no solo podrán generar los reportes actuales, sino que también
podrán combinar dicha información con cualquier otro dato que se encuentre
en la base de datos, según sean sus necesidades, y es de esta manera que se
brindará una herramienta de análisis, que solucionará las actuales carencias de
información de la empresa, e incluso se espera que se solucionen otros
aspectos que aún no han sido visualizados por los departamentos.
Descripción del producto o servicio que generará el proyecto –
Entregables finales del proyecto
Durante la elaboración del seminario de graduación y el PFG se generará:
• Documento de análisis técnico donde se identifiquen las dimensiones y
las métricas que se desean analizar en cada Gerencia, con la creación de la
herramienta de Inteligencia de Negocios.
• Documento de Diseño de indicadores, donde se identificarán los
conceptos, así como niveles máximos y mínimos que se desean evaluar
con la herramienta.
• Documento de Diseño de los reportes que mostrarán los indicadores a
manera de Dashboard con la información de todos los proyectos.
• Herramienta de Inteligencia de Negocios para realizar los análisis que
cada Gerencia necesita.
• Diseño de un procedimiento de cierre de proyectos, basado en PMI y
donde se incluya la información que se podrá obtener de la herramienta de
Inteligencia de Negocios.

214
Supuestos
• Se cuenta con un sistema en el cual se registran los siguientes datos:
o Las inconsistencias detectadas
o El desarrollador que realizó el requerimiento
o El tiempo que se duró en solucionar la inconsistencia
• Se tiene una base de datos, bien estructurada con todos los datos de los
proyectos realizados en el pasado.
• Se dejará un buena base luego del seminario de graduación para la
elaboración del PFG
• El proyecto propuesto será apto para el trabajo en grupo
• Se contará con una buena comunicación entre el tutor y los sustentantes
Restricciones
• Se cuenta hasta el mes de abril para desarrollar el PFG
• Se tomará como guía al PMBOK versión 4
• Toda comunicación será a través del sitio web de la UCI
• Se utilizaran las tecnologías con las que la empresa tenga licencia
• Se cuenta con un desarrollador y medio para la realización de este sistema
• La información a utilizar será únicamente la contenida en la base de datos
del sistema que actualmente se utiliza para el control de inconsistencias.
Información histórica relevante
Actualmente existen sistemas que se encargan de generar este tipo de
información, pero para lograr esto se debe de tener algunas otras herramientas
de la misma compañía que son las encargadas de recopilar la información y
además de esto es que tienen un valor monetario alto en el mercado. También

215
hay algunas que son gratuitas pero no llegan al nivel de detalle sé que requiere
analizar con este sistema a implementar. Y ninguno de los existentes en el
mercado tiene la flexibilidad de conectarse a otras fuentes de datos de
terceros, por lo que no se podría conectar a la actual base de datos de la
empresa.
Identificación de grupos de interés (Stakeholders)
Cliente(s) directo(s):
• Gerente General
• Gerente de Proyectos
• Gerente de Recursos Humanos
• Gerentes de proyectos
Cliente(s) indirecto(s):
• Gerente de Control de Calidad
• Desarrolladores
Realizado por:
Aprobado por:
Ramiro Fonseca Macrini
Firma:
Firma:

8.2. Anexo 2: EDT DEL PFG
216

Figura 116, EDT del desarrollo de la tesina
217

8.3. Anexo 3: CRONOGRAMA DEL PFG
218

219

Figura 117, Cronograma del desarrollo de la tesina
220

221
8.4. Anexo 4: CRONOGRAMA DEL PROYECTO SAPRE
Figura 118, Cronograma del proyecto SAPRE

222
8.1. Anexo 5: DEMOSTRACIÓN DEL PROYECTO SAPRE
Hacer clic para verlo