trabajo fin de grado - ruidera principal
TRANSCRIPT
UNIVERSIDAD DE CASTILLA-LA MANCHA
ESCUELA SUPERIOR DE INFORMÁTICA
GRADO EN INGENIERÍA INFORMÁTICA
TECNOLOGÍA ESPECÍFICA DE INGENIERÍA DEL SOFTWARE
TRABAJO FIN DE GRADO
SPT
2: Herramienta web para el seguimiento de
carteras de proyectos software
Roberto Jesús González-Carrato Pozo
Diciembre, 2017
UNIVERSIDAD DE CASTILLA-LA MANCHA
ESCUELA SUPERIOR DE INFORMÁTICA
DEPARTAMENTO DE TECNOLOGÍAS Y SISTEMAS
DE INFORMACIÓN
TECNOLOGÍA ESPECÍFICA DE INGENIERÍA DEL SOFTWARE
TRABAJO FIN DE GRADO
SPT
2: Herramienta web para el seguimiento de
carteras de proyectos software
Autor: Roberto Jesús González-Carrato Pozo
Directores: Félix Óscar García Rubio
María de los Ángeles Moraga de la Rubia
Diciembre, 2017
TRIBUNAL:
Presidente:
Vocal:
Secretario:
FECHA DE DEFENSA:
CALIFICACIÓN:
PRESIDENTE VOCAL SECRETARIO
Fdo.: Fdo.: Fdo.:
PÁGINA DE CALIFICACIÓN
0
II
Resumen
Debido a la gran competitividad que existe en el mercado e incluso para poder
sobrevivir, las empresas necesitan una adecuada planificación a todos los niveles y que
comienza con la planificación estratégica. En los últimos años ha ido cobrando cada vez
más importancia el concepto de gestión de carteras de proyectos, siendo hoy en día
esencial la implementación de éstas en las empresas. Y es que, un óptimo entorno de
gestión de carteras de proyectos no asegura a una organización la consecución de la
planificación estratégica, pero sí que da un soporte muy importante y ayuda a que éste
se logre.
Una de las etapas más importantes en la gestión de carteras de proyectos es el
seguimiento. Gracias a ésta, las empresas están en todo momento informadas sobre el
estado de las carteras de proyectos que gestionan.
Por otro lado, tras analizar el mercado que existe de herramientas que ayudan en
la gestión de carteras de proyectos, se ha detectado que en la actualidad no existe una
aplicación específica que esté orientada a la gestión de carteras de proyectos software,
lo que lleva a pensar que el desarrollo de una herramienta orientada a este tipo de
carteras de proyectos sería más que acertado.
Por todo ello, en el contexto de este TFG se ha considerado el gran potencial e
interés que puede tener una herramienta orientada a dar seguimiento a la gestión de
carteras de proyectos software, con el fin de dar el soporte necesario a las
organizaciones para que éstas logren alcanzar la planificación estratégica que tengan
definida. En el presente TFG se desarrolla la herramienta SPT2 (Software Portfolios
Tracking Tool) que permite la captura y representación adecuada de los indicadores
esenciales de seguimiento de carteras de proyectos, facilitando una representación
adecuada de la información aplicando mecanismos de visualización que faciliten la
toma de decisiones y permitan determinar de forma sencilla el alineamiento de la cartera
con la estrategia.
Una vez se ha desarrollado la aplicación, se ha realizado un caso práctico que ha
permitido para comprobar el correcto funcionamiento de la herramienta SPT2.
III
IV
Abstract
Due to the great competitiveness that exists in the market and even to survive,
companies need adequate planning at all levels and start with the strategic planning. In
recent years, the concept of project portfolio management has become increasingly
important, and today the implementation in companies is essential. And, an optimal
project portfolio management environment does not guarantee the organization the
achievement of strategic planning, but it can be a very important support and help you
to achieve it.
One of the most important stages in the project portfolios management is the
tracking. Thanks to this, the companies are always informed about the status of the
projects portfolios that they manage.
On the other hand, after analyzing the tools that exist for projects portfolios
management, at present there is no specific application that is oriented to the software
projects portfolios management, which leads to think that the development of a tool
oriented to this type of projects portfolios would be successful.
Therefore, in the context of this TFG has been considered the great potential and
interest that can have a tool aimed at tracking the software projects portfolios
management, in order to provide the necessary support to organizations in order to
achieve strategic planning. In the present TFG, the SPT2 tool is developed, which
allows the capture and adequate representation of the essential indicators for tracking
project portfolios, facilitating an adequate representation of the information by applying
visualization mechanisms that facilitate decision making and allow to determine in a
simple way the alignment of the portfolio with the strategy.
Once the application has been developed, a practical case has been made that
allowed verifying the correct functioning of the SPT2 tool.
V
VI
A mis padres, Blas y Ramoni, por dármelo todo sin pedir nada a cambio.
A mi hermana, Gema, por sus ánimos.
A Raquel, por hacer que cada momento juntos sea inolvidable.
VII
VIII
AGRADECIMIENTOS
Después de un intenso período de siete meses, hoy llega el día que tanto
esperaba: por fin escribo este apartado de agradecimientos, el cual significa la
finalización de mi Trabajo Fin de Grado. Un período que, sin duda alguna, recordaré
con cariño por las numerosas alegrías que he vivido y también por los diversos fracasos,
habiendo aprendido de cada uno de ellos.
En primer lugar, agradecer a mis padres, Blas y Ramoni, los cuales son todo un
ejemplo para mí de esfuerzo y trabajo diario. Gracias a su constancia, dedicación y
cariño hoy soy quien soy, habiéndome permitido crecer tanto personal como
profesionalmente por la posibilidad que me dieron de realizar estos estudios
universitarios.
A mi hermana Gema, por sus constantes ánimos y apoyos, preocupándose
siempre por mí y estando orgullosa de cada uno de mis éxitos. También a cada uno de
mis familiares, por estar siempre pendientes de mi evolución académica y por los
ánimos de cada uno de ellos.
A Raquel, ya que sin sus constantes muestras de cariño hacia mí y su apoyo, esto
no hubiera sido posible. Es la base de este éxito, habiéndome levantado el ánimo cada
vez que el agobio se apoderaba de mí, consiguiendo con sus ánimos la constancia y
concentración que necesitaba para cumplir con mis objetivos personales diarios; y, en
definitiva, sacándome una sonrisa en momentos donde parecía difícil sonreír. Por toda
una vida juntos.
A mis amigos, que, aún sin saberlo ellos, con su alegría me han dado los ánimos
necesarios en momentos en los que lo necesitaba.
A mis compañeros en Indra, por preocuparse por mi progreso académico y por
haber aprendido de sus conocimientos y experiencia.
Por último, agradecer todo el esfuerzo realizado a Félix y Marian, ya que me han
dado la oportunidad de realizar este proyecto y por haber sido mi guía durante todos
estos meses. Aunque yo haya sido un alumno más para ellos, ellos para mí han sido
verdaderamente importantes, aportándome su sabiduría y consejos en cada momento.
Gracias a todos, de corazón.
Roberto Jesús González-Carrato Pozo
IX
X
ÍNDICE GENERAL
CAPÍTULO 1. INTRODUCCIÓN ............................................................................. 1
1.1. Introducción al tema. ........................................................................................ 1
1.2. Estructura del documento. ............................................................................... 3
CAPÍTULO 2. OBJETIVOS DEL TFG .................................................................... 5
2.1. Objetivo principal. ............................................................................................ 5
2.2. Objetivos parciales............................................................................................ 6
2.3. Objetivos docentes. ........................................................................................... 9
CAPÍTULO 3. ESTADO DE LA CUESTIÓN ......................................................... 11
3.1. Fundamentos de la gestión de carteras de proyectos software...................... 11
Los proyectos pueden agruparse en carteras o en programas. A continuación vamos
a analizar la diferencia que hay entre ambos términos. ......................................... 12
3.1.1. Carteras de proyectos. ................................................................................ 12
3.1.2. Gestión de proyectos. ................................................................................. 13
3.1.3. Gestión de carteras de proyectos software. ................................................. 14
3.3. Herramientas para la gestión de carteras de proyectos. ............................... 19
3.3.1. SAP Portfolio and Project Management...................................................... 19
3.3.2. Unanet Project ERP Software. .................................................................... 20
3.3.3. Microsoft Project & Portfolio Management. ............................................... 21
3.3.4. Antura Projects. .......................................................................................... 22
3.3.5. Oracle’s Primavera P6 Enterprise Project Portfolio Management................ 23
3.3.6. Micro Focus Project and Portfolio Management. ........................................ 25
3.3.7. UNICOM Focal Point. ............................................................................... 26
3.4. Resumen, conclusiones y contribuciones esperadas del TFG........................ 27
CAPÍTULO 4. MÉTODO DE TRABAJO ............................................................... 29
4.1. OpenUP ........................................................................................................... 29
4.1.1. Ciclo de vida. ............................................................................................. 31
4.1.2. Roles. ......................................................................................................... 32
4.2. Marco tecnológico. .......................................................................................... 35
4.2.1. Herramientas para la gestión de proyectos. ................................................. 36
4.2.2. Herramientas para el modelado software y documentación. ........................ 37
4.2.3. Herramientas para la base de datos. ............................................................ 39
XI
4.2.4. Entorno de desarrollo integrado (IDE), herramientas, tecnologías y
frameworks para el desarrollo de software. ........................................................... 39
CAPÍTULO 5. RESULTADOS: HERRAMIENTA SPT2 ....................................... 47
5.1. Fase de inicio. .................................................................................................. 47
5.1.1. Análisis de requisitos.................................................................................. 47
5.1.2. Modelo de Casos de Uso. ........................................................................... 49
5.1.3. Plan de Iteraciones. .................................................................................... 53
5.2. Fase de elaboración. ........................................................................................ 55
5.2.1. Iteración 1. Configuración del entorno, diseño de la arquitectura del sistema,
de la base de datos y de la interfaz de usuario. ...................................................... 55
5.3. Fase de construcción. ...................................................................................... 64
5.3.1. Iteración 2. Importación de proyectos .xml exportados de MS-Project. ....... 65
5.3.2. Iteración 3. Gestión de usuarios. ................................................................. 67
5.3.3. Iteración 4. Creación tanto de carteras de proyectos, como de proyectos. .... 72
5.3.4. Iteración 5. Vistas de la herramienta para el seguimiento de carteras. ......... 80
5.3.5. Iteración 6. Representación gráfica de la información de seguimiento de
carteras. ............................................................................................................... 85
5.3.6. Iteración 7. Cambios de estado tanto de las carteras de proyectos, como de
los proyectos. ....................................................................................................... 90
5.3.7. Iteración 8. Actualización de valores de la Gestión del Valor Ganado del
proyecto. .............................................................................................................. 97
5.3.8. Iteración 9. Descarga del informe con la información del proyecto deseado.
.......................................................................................................................... 103
5.3.9. Iteración 10. Envío de correo electrónico al usuario. ................................. 106
5.4. Fase de transición. ........................................................................................ 107
5.4.1. Iteración 11. Pruebas de integración y documentación. ............................. 108
5.4.2. Caso práctico con SPT2. ........................................................................... 108
CAPÍTULO 6. CONCLUSIONES Y PROPUESTAS ........................................... 121
6.1. Análisis de los objetivos cumplidos. ............................................................. 121
6.2. Propuestas futuras. ....................................................................................... 123
6.3. Opinión del autor. ......................................................................................... 124
CAPÍTULO 7.BIBLIOGRAFÍA ............................................................................ 125
ANEXO A. MANUAL DE USUARIO ................................................................... 129
ANEXO B. ACRÓNIMOS ...................................................................................... 161
XII
ÍNDICE DE FIGURAS
Figura 1: Relación entre plan estratégico y carteras de proyectos. .................................. 2
Figura 2: Esquema general de la herramienta SPT2........................................................ 3
Figura 3: Relaciones entre carteras, programas y proyectos (PMI, 2013). .................... 13
Figura 4: Entorno de SAP Portfolio and Project Management (SAP Portfolio and
Project Management, 2017)......................................................................................... 20
Figura 5: Entorno de Unanet Project ERP Software (Unanet Project ERP Software,
2017). ......................................................................................................................... 21
Figura 6: Entorno de Microsoft Project Portfolio Management (Microsoft Project &
Portfolio Management, 2017). ..................................................................................... 22
Figura 7: Entorno de Antura Projects (Antura Projects, 2017). .................................... 23
Figura 8: Entorno de Primavera P6 EPPM (Oracle’s Primavera P6 Enterprise Project
Portolio Management, 2017). ...................................................................................... 24
Figura 9: Primavera P6 EPPM permite actualizar las tareas para reflejar el trabajo
realizado (Oracle’s Primavera P6 Enterprise Project Portolio Management, 2017). ..... 25
Figura 10: Entorno de Micro Focus Project and Portfolio Management (Micro Focus
Project and Portfolio Management, 2017). .................................................................. 26
Figura 11: Entorno de UNICOM Focal Point (UNICOM Focal Point, 2017). .............. 27
Figura 12: Visión general de OpenUP (Eclipse EPF, 2012). ........................................ 30
Figura 13: Etapas del ciclo de vida de OpenUP (Eclipse EPF, 2012). .......................... 31
Figura 14: Diferentes roles en OpenUP. ...................................................................... 32
Figura 15: Relaciones del rol Analista en OpenUP. ..................................................... 33
Figura 16: Relaciones del rol Arquitecto en OpenUP................................................... 33
Figura 17: Relaciones del rol Desarrollador en OpenUP. ............................................. 33
Figura 18: Relaciones del rol Project Manager en OpenUP. ........................................ 34
Figura 19: Relaciones del rol Tester en OpenUP. ........................................................ 34
Figura 20: Relaciones de otros roles en OpenUP. ........................................................ 34
Figura 21: Panel de Trello del TFG. ............................................................................ 37
Figura 22: Utilización de Visual Paradigm for UML durante el modelado de casos de
uso del rol administrador. ............................................................................................ 38
Figura 23: Utilización de Balsamiq Mockups durante el diseño de la interfaz de usuario.
................................................................................................................................... 38
Figura 24: Utilización de Eclipse durante el desarrollo de la herramienta. ................... 40
Figura 25: Explicación gráfica del patrón MVC (Gemio, 2017). .................................. 41
Figura 26: Ejemplos de charts representados con la librería Amcharts (Amcharts, 2017).
................................................................................................................................... 44
Figura 27: Funcionalidades del rol administrador. ....................................................... 50
Figura 28: Funcionalidades del rol alta dirección. ........................................................ 51
Figura 29: Funcionalidades del rol gestor de cartera de proyectos................................ 52
Figura 30: Funcionalidades del rol gestor de proyecto. ................................................ 53
Figura 31: Diseño de la base de datos que se utilizará para la herramienta. .................. 57
XIII
Figura 32: Diseño de la interfaz del administrador....................................................... 59
Figura 33: Diseño de la interfaz del rol alta dirección. ................................................. 60
Figura 34: Diseño de la interfaz del gestor de cartera de proyectos cuando el usuario
gestiona una sola cartera de proyectos. ........................................................................ 61
Figura 35: Diseño de la interfaz del gestor de carteras de proyectos cuando el usuario
gestiona varias carteras. .............................................................................................. 62
Figura 36: Diseño de la interfaz del gestor de proyecto cuando el usuario gestiona varios
proyectos. ................................................................................................................... 63
Figura 37: Diseño de la interfaz del gestor de proyecto cuando el usuario gestiona varios
proyectos. ................................................................................................................... 64
Figura 38: Vista para que el gestor de cartera de proyectos seleccione un archivo .xml.
................................................................................................................................... 66
Figura 39: Script que envía el archivo seleccionado al controlador mediante una llamada
AJAX.......................................................................................................................... 66
Figura 40: Extracto del método JAVA que lee la información del archivo .xml
seleccionado. .............................................................................................................. 67
Figura 41: Casos de uso para la gestión de los usuarios del administrador. .................. 68
Figura 42: Casos de uso para la gestión de los usuarios de la alta dirección. ................ 68
Figura 43: Interfaz para crear un nuevo usuario. .......................................................... 69
Figura 44: Interfaz para dar de baja a un usuario. ........................................................ 69
Figura 45: Diagrama de clases Gestión de Usuarios. ................................................... 70
Figura 46: Diagrama de secuencia Eliminar Usuario. .................................................. 70
Figura 47: Código implementado en el controlador para dar de baja a un usuario. ....... 71
Figura 48: Código implementado en el Manager para dar de baja a un usuario. ........... 71
Figura 49: Código implementado en la clase de la capa Modelo para dar de baja a un
usuario. ....................................................................................................................... 71
Figura 50: Casos de uso para la creación de carteras de proyectos y de proyectos para el
administrador. ............................................................................................................. 72
Figura 51: Casos de uso para la creación de carteras de proyectos para la alta dirección.
................................................................................................................................... 73
Figura 52: Casos de uso para la creación de proyectos para el gestor de cartera de
proyectos. ................................................................................................................... 73
Figura 53: Interfaz para crear una nueva cartera de proyectos. ..................................... 74
Figura 54: Método en la clase de la capa Modelo para la inserción de nuevas carteras de
proyectos en la base de datos. ...................................................................................... 75
Figura 55: Interfaz para crear un nuevo proyecto para el rol Administrador. ................ 76
Figura 56: Interfaz para crear un nuevo proyecto para el rol Gestor de Cartera de
Proyectos. ................................................................................................................... 77
Figura 57: Formulario para la creación de un nuevo proyecto siguiendo metodología
tradicional. .................................................................................................................. 78
Figura 58: Formulario para la creación de un nuevo proyecto siguiendo metodología
ágil. ............................................................................................................................. 79
Figura 59: Diagrama de clases creación de carteras de proyectos y de proyectos. ........ 80
XIV
Figura 60: Diagrama de secuencia Creación nuevo proyecto por parte del Gestor de
cartera de proyectos. ................................................................................................... 80
Figura 61: Casos de uso del usuario Gestor de cartera de proyectos para Vistas de la
herramienta para el seguimiento de carteras. ............................................................... 81
Figura 62: Casos de uso del usuario Gestor de cartera de proyectos para Vistas de la
herramienta para el seguimiento de carteras. ............................................................... 81
Figura 63: Casos de uso del usuario Gestor de proyecto para Vistas de la herramienta
para el seguimiento de carteras. ................................................................................... 81
Figura 64: Interfaz mostrada al rol Gestor de proyecto cuando haga login y gestione más
de un proyecto. ........................................................................................................... 82
Figura 65: Interfaz mostrada al rol Alta Dirección/Gestor de cartera de proyectos
cuando seleccione una de sus carteras. ........................................................................ 83
Figura 66: Vista mostrada al rol Alta Dirección cuando su empresa tenga una o más
carteras de proyectos. .................................................................................................. 83
Figura 67: Interfaz mostrada al rol Gestor de proyecto (pestaña Información general)
cuando seleccione uno de sus proyectos siguiendo metodología tradicional. ................ 84
Figura 68: Diagrama de clases para la visualización de las vistas de la herramienta para
el seguimiento de carteras. .......................................................................................... 85
Figura 69: Parte del código del jsp que muestra cada celda de la tabla de proyectos. ... 85
Figura 70: Interfaz nivel Alta Dirección tras introducir gráficos Amcharts. ................. 87
Figura 71: Interfaz nivel Alta Dirección tras introducir gráficos Amcharts. ................. 87
Figura 72: Interfaz nivel Gestión de carteras de proyectos tras introducir gráficos
Amcharts. ................................................................................................................... 88
Figura 73: Interfaz nivel Gestión de proyectos tras introducir gráficos Amcharts......... 89
Figura 74: Construcción del chart en el jsp correspondiente. ....................................... 90
Figura 75: Casos de uso para cambios de estado del rol Alta dirección. ....................... 90
Figura 76: Casos de uso para cambios de estado del rol Gestor de cartera de proyectos.
................................................................................................................................... 91
Figura 77: Casos de uso para cambios de estado del rol Gestor de proyecto................. 91
Figura 78: Interfaz para posibilitar el cambio del estado general de la cartera de
proyectos. ................................................................................................................... 92
Figura 79: Interfaz para posibilitar el cambio del estado general del proyecto.............. 93
Figura 80: Interfaz para posibilitar el cambio de los estados individuales de la cartera de
proyectos. ................................................................................................................... 94
Figura 81: Modal para indicar los nuevos estados individuales deseados de la cartera de
proyectos. ................................................................................................................... 95
Figura 82: Interfaz para posibilitar el cambio de los estados individuales del proyecto. 95
Figura 83: Diagrama de secuencia actualizar estados individuales proyecto. ............... 96
Figura 84: Diagrama de clases para los cambios de estado general/individuales de la
cartera/proyecto. ......................................................................................................... 96
Figura 85: Código en la capa Modelo para el cambio de los estados individuales en la
cartera de proyectos. ................................................................................................... 97
Figura 86: Casos de uso actualizar valores Gestión del Valor Ganado del proyecto. .... 97
XV
Figura 87: Botón creado para la actualización de valores para la Gestión del Valor
Ganado en proyecto siguiendo metodología tradicional. .............................................. 98
Figura 88: Botón creado para la actualización de valores para la Gestión del Valor
Ganado en proyecto siguiendo metodología ágil.......................................................... 98
Figura 89: Modal que permite la actualización de valores para la Gestión del Valor
Ganado en proyectos siguiendo metodología tradicional. ............................................ 99
Figura 90: Formulario que permite la actualización de valores para la Gestión del Valor
Ganado de Forma manual en proyectos que siguen metodología tradicional. ............... 99
Figura 91: Selección de actualización de valores para la Gestión del Valor Ganado de
Forma automática para proyectos siguiendo metodología tradicional. ....................... 100
Figura 92: Formulario en selección de actualización de valores para la Gestión del Valor
Ganado de Forma automática para proyectos siguiendo metodología tradicional. ...... 101
Figura 93: Formulario que permite la actualización de valores para la Gestión del Valor
Ganado de Forma manual en proyectos que siguen metodología ágil. ........................ 101
Figura 94: Formulario en selección de actualización de valores para la Gestión del Valor
Ganado de Forma automática para proyectos siguiendo metodología ágil. ................. 102
Figura 95: Gráfica de la Gestión del Valor Ganado. .................................................. 103
Figura 96: Casos de uso descarga de la información del proyecto. ............................. 103
Figura 97: Nuevo botón para descargar la información del proyecto deseado en formato
PDF. ......................................................................................................................... 104
Figura 98: Diagrama de clases de la descarga de información del proyecto deseado. . 105
Figura 99: Parte de código más relevante del controlador para la descarga del archivo
PDF. ......................................................................................................................... 105
Figura 100: Correo electrónico enviado al usuario cuando ha sido dado de alta en la
herramienta. .............................................................................................................. 106
Figura 101: Correo electrónico enviado al Gestor de cartera de proyectos cuando cambia
el estado general de alguna de sus carteras. ............................................................... 106
Figura 102: Correo electrónico enviado al Gestor de proyecto cuando se le asigne un
nuevo proyecto.......................................................................................................... 107
Figura 103: Código implementado para el envío del correo electrónico cuando un
usuario cambie su contraseña. ................................................................................... 107
Figura 104: Formulario para dar de alta a Pablo Ramírez. ......................................... 109
Figura 105: Correo electrónico enviado al administrador de SPT2 informando del nuevo
alta. ........................................................................................................................... 109
Figura 106: Correo electrónico enviado a Pablo Ramírez informando que ha sido dado
de alta en la herramienta............................................................................................ 109
Figura 107: Formulario para cambiar la contraseña de Pablo Ramírez. ...................... 110
Figura 108: Mensaje informando del éxito durante el cambio de contraseña. ............. 110
Figura 109: Formulario para la creación de la nueva cartera de proyectos.................. 111
Figura 110: Correo electrónico enviado a la alta dirección tras crear una nueva cartera
de proyectos. ............................................................................................................. 111
Figura 111: Correo electrónico enviado al gestor de cartera tras asignarle una nueva
cartera de proyectos. ................................................................................................. 112
Figura 112: Vista de la cartera de proyectos que dirige el usuario Manuel Ruiz. ........ 112
XVI
Figura 113: Formulario para la creación de un nuevo proyecto, asignándoselo a Samuel
Pérez. ........................................................................................................................ 113
Figura 114: Vista de la cartera de proyectos tras la creación de los 2 nuevos proyectos
en la misma. .............................................................................................................. 114
Figura 115: Vista de la cartera de proyectos tras la creación de los 2 nuevos proyectos
en la misma. .............................................................................................................. 114
Figura 116: Vista del proyecto asignado a Samuel Pérez (pestaña “Información
general”). .................................................................................................................. 115
Figura 117: Vista del proyecto asignado a Raquel Santos (pestaña “Gestión del valor
ganado”). .................................................................................................................. 116
Figura 118: Vista del proyecto asignado a Raquel Santos (pestaña “Estado del
proyecto”) tras actualizar el estado de calendario. ..................................................... 116
Figura 119: Gráfica de la Gestión del Valor Ganado del proyecto de Samuel Pérez. .. 117
Figura 120: Vista de la cartera de proyectos tras cancelar el proyecto de Samuel Pérez.
................................................................................................................................. 117
Figura 121: Vista de la cartera de proyectos tras cancelar el proyecto de Samuel Pérez.
................................................................................................................................. 118
Figura 122: Correo electrónico enviado al gestor de proyecto tras la cancelación de su
proyecto. ................................................................................................................... 118
Figura 123: Vista de la cartera de proyectos tras actualizar su estado a Terminada. ... 119
Figura 124: Vista de la cartera de proyectos tras actualizar su estado a Terminada. ... 119
Figura 125: Correo electrónico enviado al gestor de cartera proyecto informando de la
actualización de la misma a Terminada. .................................................................... 120
Figura 126: Interfaz login. ......................................................................................... 129
Figura 127: Pantalla principal Administrador. ........................................................... 130
Figura 128: Apartado Mi cuenta. ............................................................................... 131
Figura 129: Interfaz para la creación de nuevas carteras de proyectos. ....................... 133
Figura 130: Interfaz para la creación de nuevos proyectos. ........................................ 134
Figura 131: Formulario para la introducción de información adicional para el nuevo
proyecto. ................................................................................................................... 135
Figura 132: Formulario para la creación de un nuevo usuario. ................................... 136
Figura 133: Interfaz para la eliminación de usuarios de la aplicación. ........................ 137
Figura 134: Vista del rol Alta dirección tras hacer login. ........................................... 138
Figura 135: Vista del rol Alta dirección tras hacer login. ........................................... 139
Figura 136: Vista de cartera de proyectos para el usuario Alta dirección. .................. 141
Figura 137: Vista de cartera de proyectos para el usuario Alta dirección. .................. 141
Figura 138: Pestaña Información general de la vista de proyecto para el usuario Alta
dirección. .................................................................................................................. 142
Figura 139: Pestaña Estado del proyecto de la vista de proyecto para el usuario Alta
dirección. .................................................................................................................. 143
Figura 140: Pestaña Gestión del valor ganado de la vista de proyecto para el usuario
Alta dirección. .......................................................................................................... 143
Figura 141: Vista rol Gestor de cartera de proyectos tras hacer login gestionando varias
carteras. .................................................................................................................... 145
XVII
Figura 142: Vista cartera del rol Gestor de cartera de proyectos ................................ 145
Figura 143: Vista cartera del rol Gestor de cartera de proyectos. ............................... 146
Figura 144: Vista para actualizar estados individuales de la cartera de proyectos. ...... 149
Figura 145: Vista rol Gestor de proyecto tras hacer login gestionando varios proyectos.
................................................................................................................................. 150
Figura 146: Vista proyecto para el rol Gestor de proyecto. ........................................ 151
Figura 147: Vista proyecto para el rol Gestor de proyecto. ........................................ 152
Figura 148: Vista proyecto para el rol Gestor de proyecto. ........................................ 152
Figura 149: Interfaz para la actualización de los estados individuales del proyecto. ... 155
Figura 150: Vista para actualizar los valores de Gestión del valor ganado del proyecto.
................................................................................................................................. 156
Figura 151: Formulario para actualizar los valores de Gestión del valor ganado del
proyecto tras seleccionar Forma manual. ................................................................... 156
Figura 152: Vista para actualizar los valores de Gestión del valor ganado del proyecto
tras seleccionar Forma automática. ............................................................................ 157
Figura 153: Formulario para actualizar los valores de Gestión del valor ganado del
proyecto siguiendo metodología tradicional tras haber seleccionado Forma automática y
tras seleccionar el proyecto deseado. ......................................................................... 157
Figura 154: Vista para actualizar los valores de Gestión del valor ganado del proyecto
siguiendo metodología ágil tras haber seleccionado Forma manual. .......................... 158
Figura 155: Vista para actualizar los valores de Gestión del valor ganado del proyecto
siguiendo metodología ágil tras haber seleccionado Forma automática y tras seleccionar
el proyecto deseado. .................................................................................................. 158
Figura 156: Gráfica de la Gestión del valor ganado. .................................................. 159
XVIII
ÍNDICE DE TABLAS
Tabla 1: Niveles de Gestión de Proyectos (PMI, 2016). ............................................... 15
Tabla 2: Herramientas y tecnologías empleadas en el presente TFG. ........................... 35
Tabla 3: Plan de Iteraciones. ....................................................................................... 54
Tabla 4: Herramientas y tecnologías usadas para cada capa del modelo MVC. ............ 56
Tabla 5: Consecución de objetivos parciales propuestos para el presente TFG........... 122
Tabla 6: Consecución de objetivos docentes propuestos para el presente TFG. .......... 123
XIX
1
CAPÍTULO 1
INTRODUCCIÓN
1.1. Introducción al tema.
Hoy en día por todos es sabido que no es tarea fácil para una empresa tener
ventajas sobre la competencia para diferenciarse y ganar la preferencia de los clientes.
Lo que está claro es que las personas encargadas de dirigir cualquier organización, sea
del tipo que sea, deben estar constantemente tomando decisiones, lo que implicará
asumir riesgos. Como ya indicó el gran emprendedor Marc Zuckerberg en 2011:
“El riesgo más grande es no tomar ninguno. En un mundo que está
cambiando tan rápido, la única estrategia que está garantizada a fracasar
es no tomar riesgos.”
(Marc Zuckerberg, 2011)
Para mantener la competitividad en el mercado e incluso para poder sobrevivir,
las empresas necesitan una adecuada planificación a todos los niveles y que comienza
con la planificación estratégica (Reifer, 1997). Ello implica la necesidad de una
adecuada coordinación de los proyectos que se desarrollan para satisfacer los objetivos
estratégicos, y que afectan a todos los niveles, desde el nivel estratégico, en el que se
realizan propuestas a largo plazo, hasta el nivel operativo, en el que se incluyen
propuestas a corto plazo, pasando por el nivel táctico, donde se proponen planes de
trabajo a medio plazo.
Con el fin de dar un adecuado soporte a la estrategia empresarial las empresas
deben realizar sus proyectos de una forma organizada y coherente. Para satisfacer este
requisito indispensable, es muy importante realizar una adecuada gestión de los
proyectos en su conjunto (PMI, 2014), lo que recibe el nombre de Gestión de la Cartera
de Proyectos (Project Portfolio Management) y que consiste en la selección y soporte
de proyectos o programas y está guiada por el plan estratégico y los recursos
disponibles (PMI, 2017). Una cartera es un “grupo de proyectos relacionados para
cumplir una estrategia y un programa es un grupo de proyectos gestionados de forma
coordinada para obtener unos beneficios que no serían posibles si se gestionan
individualmente” (PMI, 2017). Los conceptos de cartera y programa son dos conceptos
diferenciados, ya que aunque tanto una cartera como un programa incluyen un grupo de
proyectos, en el último caso se requiere de una coordinación y relación entre los
2
proyectos que les permita obtener un beneficio global mayor que la suma de los
beneficios individuales (PMI, 2013).
Teniendo en cuenta lo anterior y para facilitar el cumplimiento de la estrategia
empresarial mediante la organización de los proyectos en carteras es fundamental
implementar de manera efectiva un entorno de gobierno de carteras, programas y
proyectos (PMI, 2017), con los que se establecen los mecanismos para guiar y facilitar
la toma de decisiones en todo lo que afecta a los proyectos.
En el presente Trabajo Fin de Grado, desde ahora en adelante TFG, se propone
abordar como actividad fundamental de la gestión de carteras de proyectos, el
seguimiento de las mismas, de modo que se facilite a la organización el cumplimiento
de los objetivos estratégicos y por ende al plan estratégico de la misma (Figura 1).
Mediante un soporte adecuado al seguimiento de las carteras se pretende facilitar a las
organizaciones mantener alineados los resultados de los proyectos con el cumplimiento
de los objetivos estratégicos ante las posibles desviaciones que puedan surgir, de modo
que se facilite la toma de decisiones para cumplir el plan estratégico empresarial.
Figura 1: Relación entre plan estratégico y carteras de proyectos.
En particular en este TFG se abordan carteras de proyectos software. Aunque
existen diversas herramientas similares en el mercado (Lee Merkhofer Consulting,
2017), no se han encontrado herramientas específicas que aborden la problemática
especial de carteras de proyectos software, donde se requiere especial coordinación
entre los recursos y cada vez más se realizan de forma más globalizada (Vizcaíno et al.,
2014).
Con todo ello, el principal objetivo del presente TFG es desarrollar e
implementar la herramienta software Software Portfolios Tracking Tool (SPT2, a partir
de ahora), la cual será de gran utilidad en la gestión de carteras de proyectos software.
La herramienta permitirá la captura y representación adecuada de los indicadores
esenciales de seguimiento de proyectos, como puede ser el de Valor Ganado (PMI,
3
2017) tanto para proyectos siguiendo metodología tradicional como para proyectos
siguiendo metodología ágil (Project Management Institute, 2017). Del mismo modo se
facilitará una representación adecuada de la información aplicando mecanismos de
visualización que faciliten la toma de decisiones y permitan determinar de forma
sencilla el alineamiento de la cartera con la estrategia.
Adicionalmente, dada la diversidad de perfiles necesarios para usar la
herramienta, se proporcionará un soporte completo para la gestión de usuarios, de tal
forma que se necesita una autenticación para el acceso al mismo, y la subdivisión de
responsabilidades mediante la división en roles. En particular, se considerarán: el rol
administrador, el cual tendrá tareas propias de administración del sistema; el rol alta
dirección, pudiendo éste visualizar todas las carteras de proyectos de su empresa; el rol
gestor de cartera de proyectos, el cual dirigirá una o varias carteras de proyectos; y el
rol gestor de proyecto, quien será el responsable de uno o más proyectos de la
organización a la que pertenezca.
En la figura 2 se muestra el esquema general del funcionamiento de la herramienta
SPT2 a desarrollar en el presente TFG, es el siguiente:
Figura 2: Esquema general de la herramienta SPT2.
1.2. Estructura del documento.
El presente TFG está compuesto de 6 capítulos, los cuales son los siguientes:
Capítulo 1. Introducción: en este capítulo se ha expuesto el tema a tratar en el
presente TFG, así como la estructura del documento.
Capítulo 2. Objetivos: en el segundo capítulo se presentan los objetivos que
quieren alcanzarse con la realización de este TFG, así como una breve
explicación de cada uno de ellos.
4
Capítulo 3. Estado de la cuestión: en este capítulo se abordan los principales
conocimientos relacionados con la temática del presente TFG, tratando los
fundamentos de la gestión de carteras de proyectos software, la importancia del
gestor de cartera para realizar una correcta gestión de carteras de proyectos
software y una revisión de las herramientas representativas existentes para la
gestión de carteras de proyectos.
Capítulo 4. Método de trabajo: en el cuarto capítulo se expone el método de
trabajo utilizado en el desarrollo de la herramienta SPT2 resultante de este TFG,
así como todas las tecnologías y herramientas empleadas en la misma.
Capítulo 5. Resultados del desarrollo de la herramienta SPT2: en este
capítulo se presentan los principales resultados generados de la aplicación del
método de trabajo indicado en el capítulo 4 para el desarrollo de la herramienta.
Capítulo 6. Conclusiones y propuestas: en el sexto capítulo se exponen las
principales conclusiones extraídas tras haber finalizado el desarrollo de la
herramienta del presente TFG, así como una serie de propuestas de posibles
mejoras de la misma para un trabajo futuro y tras ello, la opinión personal del
autor tras haber logrado el desarrollo de la herramienta SPT2.
En la parte final del documento se presentan los Apéndices, los cuales sirven
para aclarar la información proporcionada con el fin de dar una mejor comprensión de
algunos apartados tratados en capítulos anteriores. Éstos son los siguientes:
Anexo A. Manual de usuario: se proporciona una guía para facilitar el uso de
la herramienta, así como ejemplos de uso de la aplicación desarrollada.
Anexo B. Acrónimos: para finalizar, en este anexo se presentan los acrónimos
utilizados en la elaboración del presente documento.
5
CAPÍTULO 2
OBJETIVOS DEL TFG
A lo largo de este capítulo se describe detalladamente el objetivo principal que
quiere lograrse con el presente TFG, así como los objetivos parciales derivados de éste.
Así mismo, se exponen los distintos objetivos docentes que se pretenden alcanzar con la
realización del mismo.
2.1. Objetivo principal.
La motivación del presente TFG viene dada por la gran importancia que tiene
actualmente para cualquier organización la gestión de carteras de proyectos. Si ésta no
se realiza de una manera óptima, la consecución de la planificación estratégica
empresarial está en peligro.
Es por ello que el objetivo principal es el desarrollo de la herramienta SPT2, la
cual será de gran ayuda en una parte muy importante de la gestión de carteras de
proyectos como es el seguimiento de las mismas, así como de los proyectos contenidos
en éstas. En el contexto de gestión de carteras de proyectos, esta herramienta estará
enfocada a proyectos software, ya que nos proporcionará información específica de la
gestión de proyectos software como es la relativa a la Gestión del Valor Ganado.
Por todo lo anteriormente comentado, el software a desarrollar consistirá en una
herramienta con Interfaz Web para facilitar el acceso y la interoperabilidad entre
distintos usuarios, de tal forma que permita realizar un óptimo seguimiento de las
carteras de proyectos así como de los proyectos contenidos en éstas. De forma
adicional, la herramienta contará con un completo sistema de gestión de usuarios
basados en roles.
Para lograr realizar con éxito este objetivo principal, éste se ha desglosado en
una serie de objetivos parciales, los cuales son descritos a continuación.
6
2.2. Objetivos parciales.
Si queremos alcanzar el objetivo principal, es necesario llevar a cabo la
consecución de los siguientes objetivos parciales:
Obj1 – Capturar información de proyectos exportados de MS-Project. El
usuario con el rol gestor de cartera de proyectos podrá incluir nuevos proyectos
en la cartera de la cual sea responsable y se encuentre en progreso. Para ello,
deberá seleccionar un archivo exportado de MS-Project. La herramienta SPT2
será capaz de cargar automáticamente toda la información relevante para el
seguimiento de la cartera a partir de estos archivos.
Obj2 – Representar indicadores relevantes de las carteras de proyectos. La
herramienta mostrará toda la información relacionada con las carteras y los
proyectos contenidos en éstas mediante una representación adecuada de la
misma usando mecanismos de visualización. Estos indicadores serán el estado
general tanto de las carteras como de los proyectos (en progreso, cancelada/o o
terminada/o), estados individuales tanto de las carteras como de los proyectos
(estado financiero, estado de calendario, estado de alineamiento y estado de
riesgos), presupuesto, fecha de creación y fecha prevista de finalización, entre
otros. Todos estos indicadores se mostrarán con el fin de dar el soporte necesario
a la alta dirección de la organización y a los gestores de carteras de proyectos en
su objetivo de tener conocimiento en todo momento del estado de éstas.
Obj3 – Completa gestión de usuarios: la aplicación será capaz de diferenciar
el rol de cada usuario autenticado. Estos roles, junto con la funcionalidad más
destacada de cada uno de ellos, son los siguientes:
o Rol administrador: podrá crear nuevos usuarios en el sistema y borrar
los ya existentes del mismo. También podrá crear nuevas carteras de
proyectos, asignándoselas al gestor de cartera deseado; al igual que podrá
crear nuevos proyectos y asignarlos a la cartera de proyectos que éste
quiera y al gestor de proyecto deseado.
o Rol alta dirección: este tipo de usuario podrá dar de alta a nuevos
usuarios de su empresa en cuestión en el sistema, así como borrar a ya
existentes del mismo. También podrá crear nuevas carteras de proyectos
en su compañía y asignársela al gestor de cartera de proyectos que éste
desee.
7
o Rol gestor de cartera de proyectos: este usuario podrá crear nuevos
proyectos en las carteras de proyectos que gestione, en el caso de que
ésta se encuentre en el estado en progreso, y asignarlos al gestor de
proyecto deseado.
o Rol gestor de proyecto: este tipo de usuario únicamente podrá visualizar
la información relativa a su proyecto.
Obj4 – Jerarquizar la visibilidad de información mediante niveles. Estos
niveles corresponden con tres de los cuatro roles mencionados anteriormente.
Ordenados de menor a mayor responsabilidad, la jerarquía de niveles será la
siguiente:
o Nivel de gestión de proyectos: la información mostrada en este nivel
corresponde a la visualización del rol gestor de proyecto. Éste tendrá
acceso solamente a los proyectos que gestiona, pudiendo cambiar los
estados individuales de los mismos (financiero, de calendario, de
alineamiento y de riesgos) pero no el estado general (en progreso,
terminado o cancelado).
o Nivel de gestión de carteras de proyectos: en este caso, la información
mostrada corresponde a la visualización del rol gestor de cartera de
proyectos. Éste, además de poder ver toda la información del nivel
inferior, también tendrá acceso a toda la información relativa a las
carteras de proyectos que gestiona. Este usuario podrá cambiar los
estados individuales de sus carteras de proyectos y el estado general de
los proyectos contenidos en éstas, en el caso de que éstos se encuentren
en progreso y se desee actualizar su estado a terminado o cancelado;
pero no podrá actualizar los estados generales de sus carteras de
proyectos.
o Nivel de alta dirección: éste es el nivel más alto de la jerarquía. Se
corresponde con el usuario con el rol alta dirección. Éste podrá ver todas
las carteras de proyectos que tiene su empresa, independientemente de
quien las gestione, al igual que todos los proyectos contenidos en éstas.
Podrá cambiar tanto el estado general de las carteras como el de los
proyectos, siempre que éstas o éstos se encuentren en progreso y el
usuario alta dirección desee actualizar su estado a terminado o
cancelado.
Obj5 – Descarga de informes de proyectos. La aplicación será capaz de dar la
posibilidad al usuario de descargar un archivo en formato .pdf con toda la
información del proyecto que esté visualizando.
8
Obj6 – Correcto seguimiento de la Gestión del Valor Ganado. La
herramienta mostrará todos los datos importantes referentes a la Gestión del
Valor Ganado. El usuario con el rol gestor de proyecto podrá registrar en cada
proyecto (si éstos se encuentran en el estado en progreso) nuevas fechas de
estado, mostrándose de forma automática una gráfica con el registro de todas las
fechas de estado almacenadas en el sistema del proyecto en cuestión, junto con
la información a cada fecha, lo que será muy útil para valorar si el proyecto
sigue el camino correcto.
Obj7 – Facilitar la comunicación y colaboración de los distintos roles. La
aplicación será capaz de enviar de manera automática correos electrónicos a los
usuarios para informar de hechos que ocurran en el sistema y deban saber sobre
ellos. El envío de estos correos se dará en los siguientes casos:
o Creación de nuevo usuario en el sistema: la aplicación enviará un correo
electrónico tanto al usuario con el rol administrador/alta dirección que
ha dado de alta un nuevo usuario, como al nuevo usuario en cuestión con
el fin de informar sobre el nuevo registro en el sistema.
o Eliminación de un usuario del sistema: la herramienta enviará un correo
electrónico al usuario con el rol administrador/alta dirección que ha
eliminado a un usuario de la base de datos, con el objetivo de informar
sobre ello.
o Cambio de contraseña: un correo electrónico será enviado al usuario que
ha cambiado su password informando de este hecho.
o Creación de una nueva cartera de proyectos: un correo electrónico será
enviado a todos los usuarios de la organización con el rol alta dirección
y al gestor de cartera de proyectos que le ha sido asignada la cartera.
o Creación de un nuevo proyecto: cuando esto ocurra, se enviará un correo
electrónico a todos los usuarios de la organización con el rol alta
dirección, al gestor de cartera de proyectos al que pertenece el proyecto y
al gestor de proyecto que le ha sido asignado el proyecto en cuestión.
o Cambio de estado global de una cartera de proyectos: cuando una cartera
de proyectos cambie del estado en progreso a terminada o cancelada, un
correo electrónico será enviado a todos los usuarios de la organización
con el rol alta dirección y al gestor de cartera.
o Cambio de estado global de un proyecto: cuando un proyecto cambie del
estado en progreso a terminado o cancelado, un correo electrónico será
9
enviado a todos los usuarios de la organización con el rol alta dirección,
al gestor de la cartera de proyectos al que pertenece el proyecto y al
gestor de proyecto.
Además de los objetivos anteriormente mencionados, la herramienta SPT2 debe
satisfacer una serie de requisitos no funcionales. Éstos son los siguientes:
Usabilidad: la herramienta desarrollada deberá facilitar el uso a los posibles
usuarios en base al rol que desempeñen.
Disponibilidad: deberá encontrarse a disposición del usuario siempre que éste
desee acceder en el momento que quiera.
Accesibilidad: la aplicación será accesible desde cualquier punto geográfico tras
realizar una autenticación del usuario en la misma.
Portabilidad: la herramienta será independiente de la plataforma en la cual sea
ejecutada, por lo que se considerará el desarrollo de la herramienta como una
aplicación web, ya que ello permitirá su uso en cualquier equipo con conexión a
Internet y provisto de un navegador.
2.3. Objetivos docentes.
Para finalizar este capítulo a continuación van a presentarse una serie de
objetivos docentes que se persiguen satisfacer a lo largo del desarrollo del presente
TFG:
ObjD1. Conocer los fundamentos de la gestión de carteras de proyectos, así
como la importancia que tiene para una organización la correcta gestión de estas
carteras y su repercusión en la consecución de la planificación estratégica.
ObjD2. Alcanzar un grado de conocimiento esencial sobre la gestión de
proyectos y las herramientas que dan soporte a ello.
ObjD3. Adquirir aptitudes para el desarrollo web y tecnologías que faciliten el
mismo como son Bootstrap, HTML5, CSS3, Jquery, AJAX, etc; y lenguajes de
marcas como lo es JSTL.
10
ObjD4. Aplicar conocimientos de Sistemas Gestores de Base de Datos para
tratar la información necesaria de la forma más adecuada de acuerdo a los
objetivos planteados.
ObjD5. Implementar y mantener herramientas, de acuerdo a las actividades de
análisis y diseño realizadas con anterioridad.
ObjD6. Aprender a usar librerías que faciliten la visualización de datos en
desarrollo web, como por ejemplo Amcharts.
ObjD7. Aprender a usar librerías que permitan realizar importaciones de
proyectos exportados de MS-Project, como por ejemplo mediante la librería
MPXJ.
11
CAPÍTULO 3
ESTADO DE LA CUESTIÓN
El objetivo de este capítulo es presentar la información relevante que servirá
como base para el desarrollo del TFG, centrándonos principalmente en los tres
siguientes temas:
Fundamentos de la gestión de carteras de proyectos software.
Herramientas para la gestión de carteras de proyectos.
Resumen y conclusiones.
3.1. Fundamentos de la gestión de carteras de proyectos
software.
El primer concepto fundamental a abordar en el contexto de la gestión de
carteras de proyectos es el de proyecto. Un proyecto se define como un “esfuerzo
temporal emprendido para crear un producto o servicio único” (PMI, 2017).
Los proyectos se caracterizan porque:
Son temporales: esto significa que tienen un comienzo y un final definidos.
Están dirigidos a crear un producto, servicio o resultado único: la singularidad
es una característica importante de los productos entregables de un proyecto. El
producto, servicio o resultado único no ha sido realizado antes.
Los proyectos son elaborados gradualmente: la elaboración gradual de las
especificaciones de un proyecto debe ser coordinada cuidadosamente con la
definición adecuada del alcance del proyecto.
Independientemente del tipo de proyecto con el que tratemos, existen 5 etapas
comunes a todos los proyectos, las cuales estructuran el ciclo de vida del mismo (PMI,
2017):
1. Fase de inicio de proyecto: su objetivo es determinar la viabilidad del proyecto,
definir su alcance y seleccionar al equipo que participará en su ejecución.
12
2. Fase de planificación: busca calcular las necesidades en base a los requisitos,
definir y terminar de perfilar los objetivos del proyecto y planear el curso de
acción para lograr las metas planteadas.
3. Fase de ejecución: en ella se lleva a cabo todo el trabajo, completando las
actividades programadas, siendo fundamental una buena gestión, fomentar la
comunicación y llamar a la responsabilidad individual para cumplir con los
plazos y deadlines establecidos.
4. Seguimiento y control: persigue la detección prematura de desviaciones con el
objeto de garantizar el mejor ajuste, reaccionando a tiempo. Trata de minimizar
el riesgo y mitigarlo. Ésta es la fase más crítica de todo proyecto, ya que de ella
dependerá el alcanzar o no el éxito.
5. Fase de cierre de proyecto: se orienta a la valoración del proyecto, la
transmisión de conocimiento y el cumplimiento de las obligaciones
contractuales adquiridas.
Los proyectos pueden agruparse en carteras o en programas. A continuación vamos
a analizar la diferencia que hay entre ambos términos.
3.1.1. Carteras de proyectos.
Una cartera es un “grupo de proyectos relacionados para cumplir la
estrategia”. Este concepto muchas veces se confunde con el de programa de proyectos,
siendo éste un “grupo de proyectos gestionados de forma coordinada para obtener unos
beneficios que no serían posibles si se gestionan individualmente”. Como podemos
observar estos dos conceptos son muy diferentes. A continuación, en la Figura 3
podemos observar la relación que existe entre carteras, programas y proyectos:
13
Cartera de Nivel
Más Alto
Cartera de Menor Nivel
Programa de Nivel
Más Alto
Programa de menor
nivel
Proyectos
Proyectos
Proyectos
Estrategias y Prioridades
Elaboración Gradual
Gobernabilidad
Decisión sobre Cambios solicitados
Impacto de Cambios en otras
carteras, programas, proyectos
Informe de Desempeño
Solicitudes de Cambio con Impacto
en otras carteras, programas o proyectos
Figura 3: Relaciones entre carteras, programas y proyectos (PMI, 2013).
Para que una cartera de proyectos logre alcanzar el objetivo propuesto por la
organización, entran en juego muchos factores. Uno de ellos, y quizás uno de los más
importantes, es, como se presenta a continuación, la realización de una correcta gestión
de los proyectos que contienen la misma.
3.1.2. Gestión de proyectos.
La gestión de proyectos es la aplicación de conocimientos, habilidades,
herramientas y técnicas a las actividades de un proyecto para satisfacer los requisitos del
mismo. Gestionar un proyecto implica generalmente (PMI, 2017):
Identificar requisitos.
Abordar las necesidades e inquietudes de los interesados (stakeholders) a
medida que se planifica y lleva a cabo el proyecto.
Equilibrar las demandas concurrentes en cuanto a: alcance, tiempo, costes,
calidad, recursos, riesgos, etc. Si alguna de estas demandas cambia puede afectar
a las otras por lo que se debe poner en una balanza los aspectos clave a cumplir
en el proyecto y buscar un equilibrio.
14
En la gestión de los proyectos uno de los elementos clave a tratar son los interesados
o stakeholders, que se definen como “personas u organizaciones que participan
activamente en el proyecto o cuyos intereses pueden verse afectados positiva o
negativamente por la ejecución o terminación del proyecto”. Es fundamental dicha
gestión para maximizar las influencias positivas y minimizar las negativas.
Para realizar una correcta gestión de proyectos con el fin de apoyar los niveles
de decisión de la organización, es imprescindible que esta gestión se encuentre dentro
de un entorno de gestión de carteras (PMI, 2014). A continuación vamos a analizar la
importancia que ésta tiene en la consecución de la planificación estratégica empresarial.
3.1.3. Gestión de carteras de proyectos software.
Las empresas requieren de una adecuada planificación a todos los niveles y que
comienza con la planificación estratégica para sobrevivir y mantener su competitividad
en el mercado. Estos niveles de planificación son (Reifer, 1997):
Nivel estratégico: en el que se realizan propuestas a largo plazo (3-8 años), por
parte de la alta dirección y su equipo de apoyo. Los planes a este nivel se centran
en lo que debe hacerse para satisfacer las metas de la organización.
Nivel táctico: se trata de propuestas a medio plazo (1-3 años), realizadas por
mandos intermedios. Los planes a este nivel están dirigidos a desarrollar las
capacidades necesarias para implementar las estrategias de negocio definidas en
el nivel anterior.
Nivel operativo: incluye propuestas a corto plazo realizadas por supervisores y
responsables de áreas. Los planes a este nivel están dirigidos a establecer metas
y estructuras productivas para los equipos.
Los proyectos permiten apoyar todos los niveles de decisión de la organización para
en última instancia cumplir con la estrategia establecida.
Para la organización de los proyectos de modo que se dé un soporte adecuado a la
estrategia empresarial, es importante realizar una adecuada gestión, lo que recibe el
nombre de Gestión de la Cartera de Proyectos. En nuestro caso, ya que son los
proyectos que nos conciernen y de los que estamos interesados en gestionar, hablaremos
de Gestión de Carteras de Proyectos Software.
Con el fin de dar el soporte necesario a la estrategia empresarial mediante la
organización de los proyectos en carteras es fundamental implementar de forma efectiva
un entorno de gestión de carteras. La gestión de carteras debe dar soporte al gobierno de
carteras mediante una gestión efectiva de las mismas. En lo que respecta a la cartera, los
15
mecanismos de gestión se centran en la evaluación, selección, priorización y asignación
de recursos (PMI, 2016).
Como podemos observar en la Tabla 1, existen tres niveles de Gestión de
Proyectos, los cuales son: nivel de gestión del proyecto organizacional, nivel de
programa y nivel de proyecto.
Niveles Cómo organizar y hacer el trabajo
Nivel de gestión del
proyecto
organizacional
OPM (Organizational Project Management) es un marco de
ejecución de estrategia que utiliza gestión de carteras, programas y proyectos, así como prácticas de habilitación organizacional
para entregar de manera sistemática y predecible estrategias
organizacionales para producir un mejor rendimiento, mejores resultados y una ventaja competitiva sostenible.
Nivel de programa
La gestión de programas es la aplicación de conocimientos,
habilidades, herramientas y técnicas a un programa para cumplir
los requisitos del programa y para obtener beneficios y control no disponibles mediante la gestión de proyectos de forma
individual.
Nivel de proyecto La gestión de proyectos es la aplicación de conocimientos, habilidades, herramientas y técnicas a las actividades del
proyecto para satisfacer los requisitos del mismo.
Tabla 1: Niveles de Gestión de Proyectos (PMI, 2016).
Pero, en realidad, ¿existe una verdadera concienciación de lo importante que es
realizar una correcta gestión de carteras de proyectos y lo que supondría para una
empresa que esto no fuera así?
Con el fin de profundizar en este tema en primer lugar hay que considerar que la
gestión de carteras de proyectos es un concepto que cada vez más empresas tienen
asimilado y ponen en práctica; tanto es así, que se ha convertido en una disciplina que
ha ido cobrando cada vez más importancia en los últimos años, y ahora muchas
organizaciones en muchas industrias están realizando algún tipo de gestión de
cartera (PMI, 2013).
El problema es que la idea de gestión de carteras no siempre es la apropiada. Como
sabemos, considerar algo apropiado o no muchas veces es algo subjetivo, dependiendo
de la propia perspectiva de gestión de carteras que tenga cada organización. Pero sí es
cierto que existen algunos conceptos básicos y generales a todos que las industrias que
pongan en práctica la gestión de carteras deben cumplir. Uno de ellos es dar la
importancia que se merece al rol de gestor o administrador de cartera (Jordan, 2017),
ya que éste es una pieza clave en el devenir de la gestión de la misma, puesto que sus
aportaciones pueden suponer el éxito o el fracaso de la cartera.
16
En particular, el proceso de gestión de carteras requiere como primer paso la
definición de los objetivos estratégicos, que es una responsabilidad del liderazgo de la
organización pero que, sin embargo, necesita aportes del gestor de cartera. No
obstante, ¿dónde está el equilibrio correcto entre estos dos roles para el establecimiento
de metas? Un gestor de cartera no puede asegurar la consecución del objetivo
estratégico con la puesta en marcha de su cartera en concreto, pero sí que puede
proporcionar información verdaderamente importante para ayudar a ello.
Los aportes que un buen gestor de cartera debe hacer a una organización pueden
dividirse en tres categorías (Jordan, 2017):
Capacidad organizativa: podríamos pensar que con esto nos referimos
solamente a que haya suficientes personas asignadas para completar proyectos,
pero también se incluye en este apartado la consideración de la posibilidad de
consumir cambios en las áreas de entrega de la empresa. Esto requiere no sólo la
colaboración entre el administrador de cartera y los equipos de gestión de
proyectos, sino también con los equipos de productos, las TI, las funciones de
servicios profesionales y los recursos humanos. Sólo cuando todas estas áreas
trabajen de manera conjunta y en la misma dirección, se puede establecer una
cantidad realista de objetivos y subobjetivos apropiados.
Habilidad organizativa: capacidad de la organización para entregar las metas y
objetivos específicos que están priorizándose. Saber que tienes suficiente gente
para conseguir un determinado objetivo es un aspecto importante, pero saber que
tienes suficiente gente con las habilidades necesarias para ello, es mejor aún.
Esto puede impulsar las iniciativas de desarrollo o conducir a ajustes en las
metas que persigue la organización.
Distribución óptima: la forma correcta de asignar inversiones a toda la
organización para generar los mayores beneficios. Si bien las metas y los
objetivos se centrarán necesariamente en un subconjunto de la organización,
debe considerarse cómo alinear las inversiones con la capacidad de realizarlas.
Esto considerará la exposición al riesgo organizacional creada al centrarse sólo
en una o dos áreas, así como las implicaciones de los altos niveles de cambio en
áreas que ya han sido objeto de cambios.
Todo lo anteriormente comentado no es algo que los gestores de cartera puedan
hacer de forma aislada: necesitan trabajar con jefes de departamento, recursos humanos,
jefes de proyectos, etc, pero justo ése es el objetivo. La única manera de obtener una
cartera efectiva que tenga la mejor oportunidad posible de cumplir los objetivos
comerciales de los conjuntos de la organización es garantizar que todas las áreas de
negocio trabajen juntas. -Solamente de esto modo una organización tendrá la
posibilidad de realizar su planificación estratégica de manera exitosa. Una cartera de
proyectos cuyo administrador se aísla y no se relaciona con los diferentes roles de su
organización está condenada al fracaso (Jordan, 2017)-.
17
A continuación se presenta un análisis de la etapa de la gestión de carteras
proyectos en la que se centra el presente TFG y una pequeña investigación sobre las
situaciones adversas en la gestión de carteras de proyectos.
3.1.3.1. Importancia del seguimiento de carteras de proyectos.
Como se ha comentado anteriormente, muchos son los factores a la hora de la
consecución del plan estratégico empresarial, siendo en gran parte el éxito de éste tener
una correcta gestión de carteras en la organización. La gestión de carteras está
compuesta de diferentes etapas, las cuales son las siguientes (Medellín Cabrera, 2016):
Definición de áreas estratégicas.
Integración de proyectos en cartera.
Selección de proyectos para cada cartera.
Asignación de recursos.
Seguimiento de las carteras y sus respectivos proyectos.
Como se ha comentado en el capítulo de Introducción, la etapa en la que se centra
este TFG es en el seguimiento de las carteras de proyectos. Un correcto seguimiento
de las carteras de proyectos no va a asegurarnos la consecución del objetivo estratégico
de la cartera, pero sí que nos dará un soporte óptimo para llegar a éste.
El seguimiento de carteras de proyectos y de sus respectivos proyectos permite
saber, entre otras cuestiones (Medellín Cabrera, 2016):
Si las carteras de proyectos están ejecutándose de acuerdo al tiempo y costos
programados.
Si las carteras en progreso soportan las necesidades actuales y futuras de los
clientes.
Si las carteras y sus proyectos están bien balanceadas.
Si son necesarias acciones correctivas.
Llevar a cabo un correcto seguimiento de las carteras de proyectos nos permitirá
tener un conocimiento continuo de los avances logrados, los recursos utilizados, las
diferentes perspectivas y las acciones necesarias a realizar. Todo ello permite, si así lo
requiriese la situación, los ajustes necesarios en tiempos y recursos en la cartera, lo que
implica analizar la composición de la cartera de proyectos y la adaptación a las nuevas
circunstancias empresariales.
Del mismo modo, realizar un correcto seguimiento de las carteras de proyectos
en cualquier organización permitirá mantener informados a todos los involucrados de la
situación por la que pasa tanto la cartera de proyectos en cuestión, como los diferentes
proyectos que la componen.
18
Para el caso que nos concierne, ya que la herramienta a desarrollar en el presente
TFG está centrada en carteras de proyectos software, un indicador muy importante para
el seguimiento de los proyectos pertenecientes a las carteras es el de valor ganado. A
continuación se realiza un análisis de la importancia de una correcta Gestión del Valor
Ganado en proyectos software.
3.1.3.1.1. Gestión del Valor Ganado en proyectos software.
Entre la alta dirección en las organizaciones, el Valor Ganado es uno de los
requisitos que más demandan que tengan las herramientas de gestión que éstos utilizan.
Cuando hablamos de ello, nos referimos al Earned Value Management (EVM), una serie
de parámetros que asesoran sobre el funcionamiento del proyecto en base a una
planificación. El Valor Ganado nos informará de las desviaciones de costo y tiempo del
proyecto. Por tanto, gracias a éste podremos tomar decisiones más rápidas y efectivas,
apoyadas en datos concretos sobre la realidad del trabajo ejecutado (PMI, 2017).
La Gestión del Valor Ganado es tan importante porque responde a varias
preguntas clave en la gestión de proyectos: ¿Se terminará el proyecto en plazo? ¿Está
aprovechándose el tiempo? ¿Vamos adelantados o retrasados con respecto a la
planificación prevista? Gracias a las métricas de esta Gestión, se obtienen las
conclusiones exactas del estado del proyecto a tiempo real.
Por todo ello y viendo la importancia de estos indicadores, la herramienta a
desarrollar contará con una correcta Gestión del Valor Ganado tanto para proyectos
siguiendo metodología tradicional como para proyectos siguiendo metodología ágil
(Project Management Institute, 2017), con el fin de ayudar a la alta dirección de las
organizaciones y a los gestores de carteras de proyectos en la consecución del plan
estratégico empresarial.
3.1.3.2. Situaciones adversas en la gestión de carteras de proyectos.
Lo idílico cuando se pone en marcha una cartera de proyectos para conseguir un
cierto objetivo estratégico en una organización es imaginar que esta cartera entregará los
proyectos necesarios en un tiempo y plazo correctos de manera exitosa. Pero esto no
siempre ocurre así. De hecho, es muy normal que en una cartera de proyectos surjan
problemas que pongan en peligro la entrega exitosa de los proyectos.
Si existe la posibilidad de que los beneficios esperados no vayan a llegar o vayan
a llegar de manera tardía, el administrador de la cartera debe llevar a cabo planes de
recuperación, y eso requiere de su participación continua en la cartera. Estos planes de
19
recuperación pueden incluir la propuesta de nuevos proyectos, la cancelación de algunos
que estén en curso, el ajuste en el alcance de proyectos ya iniciados, etc (Jordan, 2017).
Éste no es un ejercicio para identificar el “fracaso” dentro del proceso de
obtención de beneficios, se trata de asegurar que la organización no se vea
comprometida en la entrega de los objetivos debido a un problema experimentado en la
entrega de beneficios de un subconjunto de proyectos en la cartera. La claridad de la
función para la gestión de cartera es crítica aquí; si la percepción es que el
administrador de la cartera está identificando fallos en los equipos de entrega de
beneficios, habrá fricciones y conflictos inevitables entre esos representantes y el
administrador de la cartera. Eso probablemente reducirá la efectividad de la
comunicación entre esos dos grupos, lo que a su vez conllevará una reducción de la
capacidad de administrar cualquier déficit en el desempeño de la cartera.
Puede haber muchas razones por las cuales los entregables de un proyecto no
cumplen con los objetivos esperados, especialmente en el mundo actual donde las
industrias evolucionan mucho más rápido que nunca. Si bien es importante comprender
por qué se produce el déficit para que la organización pueda mejorar en el futuro, la
medición del déficit no se trata tanto de responsabilizar a las personas por fallos, sino de
identificar la necesidad de solucionarlos tan pronto como sea posible (Jordan, 2017).
Una vez que se han presentado los conceptos más relevantes relacionados con
las carteras de proyectos y los aspectos a considerar en la gestión de las mismas, a
continuación, se realiza una revisión de un conjunto representativo de herramientas
software existentes para la gestión de carteras.
3.3. Herramientas para la gestión de carteras de
proyectos.
Existen diversas herramientas para la gestión de carteras de proyectos. En este
apartado se presentan algunas de las más representativas y destacadas, teniendo en
cuenta el alcance del presente TFG.
3.3.1. SAP Portfolio and Project Management.
SAP Portfolio and Project Management (SAP Portfolio and Project
Management, 2017) es un completo software para la gestión de proyectos y carteras de
proyectos, el cual brinda herramientas robustas para administrar de manera centralizada
el ciclo de vida completo del proyecto, desde la previsión y planificación hasta el
seguimiento y la contabilidad. Ayuda a la creación y gestión de la combinación de la
20
cartera de proyectos y programas que apoyen los objetivos estratégicos de la
organización, optimizando para ello los recursos humanos y financieros tratando de
mejorar la eficiencia. En definitiva, SAP Portfolio and Project Management proporciona
la estructura y los procesos de gobernanza de la cartera de Proyectos y Programas
haciendo especial incidencia en:
Identificar las mejores combinaciones de la cartera de Proyectos y
Programas.
Seleccionar las mejores combinaciones de la cartera de Proyectos y
Programas.
La planificación y ejecución de los proyectos.
Gestionar el lanzamiento de producto.
El análisis financiero de la cartera.
En la Figura 4, se muestra una captura de la herramienta, donde se aprecia la
funcionalidad para el listado de proyectos de una determinada cartera de proyectos.
Figura 4: Entorno de SAP Portfolio and Project Management (SAP Portfolio and
Project Management, 2017).
3.3.2. Unanet Project ERP Software.
Unanet Project ERP Software (Unanet Project ERP Software, 2017) es una
herramienta diseñada específicamente para las organizaciones orientadas a proyectos
para proporcionar la gestión de recursos, presupuestos y pronósticos, la gestión de
proyectos, fichas de tiempo, informes de gastos, contabilidad de proyectos, facturación,
colaboración y finanzas con cálculo de costes en un sistema integrado.
21
Unanet soporta capacidades centralizadas de administración de proyectos y
programación de recursos. Ofrece informes excepcionales con una amplia gama de
informes detallados y de resumen disponibles, incluyendo cuadros de mando gráficos,
costes del proyecto, etc.
En la Figura 5, se muestra una captura de pantalla de la herramienta, donde
puede apreciarse los mecanismos de visualización que ésta utiliza, tales como gráficos
para conocer el rendimiento del proyecto, para saber los recursos humanos utilizados en
el proyecto en cuestión y gráficos comparativos de las horas invertidas en unas
determinadas tareas, entre otros.
Figura 5: Entorno de Unanet Project ERP Software (Unanet Project ERP
Software, 2017).
3.3.3. Microsoft Project & Portfolio Management.
Microsoft Project & Portfolio Management (Microsoft Project & Portfolio
Management, 2017) es un software cuyo objetivo es gestionar y alinear con éxito las
carteras de proyectos con las necesidades del negocio. Ayuda a los responsables de la
toma de decisiones a modelar fácilmente distintos escenarios de cartera para determinar
la mejor trayectoria estratégica, ponderando las propuestas de proyectos contra los
impulsores estratégicos del negocio y considerando las limitaciones de costes y recursos
dentro de una organización.
22
En la Figura 6, se observa una captura de la herramienta en cuestión, donde
pueden apreciarse los gráficos que se utilizan para la visualización de la información,
así como la estructura organizacional de los datos de los proyectos.
Figura 6: Entorno de Microsoft Project Portfolio Management (Microsoft Project
& Portfolio Management, 2017).
3.3.4. Antura Projects.
Antura Projects (Antura Projects, 2017) es una solución completa para la gestión
de proyectos, carteras y recursos. Entre las características de esta herramienta se
incluyen: priorización rápida de tareas, posibilidad de compartir documentos, gestión
intuitiva de los riesgos así como soporte para el seguimiento de éstos y generación de
informes, entre otras. Antura Projects tiene un gran número de clientes y más de
200.000 usuarios satisfechos en más de 50 países. El objetivo de Antura Projects es que
sea siempre la primera opción para todas las organizaciones que requieren un sistema de
gestión de carteras de proyectos.
En la Figura 7, puede apreciarse una captura de la aplicación, en la que podemos
observar los gráficos utilizados para el análisis de costes de una cartera de proyectos
determinada, así como el chart en cuestión utilizado para la visualización del número de
proyectos contenidos en la cartera clasificados por el tipo de éstos.
23
Figura 7: Entorno de Antura Projects (Antura Projects, 2017).
3.3.5. Oracle’s Primavera P6 Enterprise Project Portfolio
Management.
Oracle’s Primavera P6 Enterprise Project Portfolio Management (Oracle’s
Primavera P6 Enterprise Project Portolio Management, 2017) es una aplicación
integrada de gestión de carteras de proyectos. Es un producto fácil de usar para
priorizar, planificar, administrar y evaluar proyectos, programas y carteras. Proporciona
una solución 100% basada en la web para administrar proyectos de cualquier tamaño, se
adapta a distintos niveles de complejidad en todos los proyectos y escala de manera
inteligente para satisfacer las necesidades de todos los roles, funciones o niveles de
habilidades en la organización y en el equipo de proyecto.
En la Figura 8, se presenta una captura de la herramienta en la que puede
observarse un diagrama representativo con la planificación temporal de determinados
elementos de una cartera de proyectos.
24
Figura 8: Entorno de Primavera P6 EPPM (Oracle’s Primavera P6
Enterprise Project Portolio Management, 2017).
Primavera P6 EPPM facilita a los gerentes el seguimiento, la captura y el
análisis del tiempo que los miembros del equipo dedican al trabajo basado en proyectos
al proporcionarles interfaces que se completan automáticamente con sus propias
asignaciones en todos los proyectos. También proporciona información adicional al
gerente del proyecto, incluidas actualizaciones de documentos, notificaciones de estado
y otros comentarios pertinentes.
Este producto facilita la colaboración en equipo para mejorar la toma de
decisiones, agilizar la coordinación y mejorar la eficiencia con nuevas capacidades de
automatización de procesos comerciales.
Los usuarios pueden generar informes en varios formatos. Además, Oracle
ofrece el poderoso Primavera Analytics, un complemento que permite a los usuarios
crear informes operativos e inteligencia comercial en proyectos y programas.
En la Figura 9 se muestra otra captura de la aplicación. En este caso, puede
observarse cómo lista la aplicación unas determinadas tareas a realizar en un proyecto,
indicando el porcentaje completado de cada una de éstas.
25
Figura 9: Primavera P6 EPPM permite actualizar las tareas para reflejar el
trabajo realizado (Oracle’s Primavera P6 Enterprise Project Portolio
Management, 2017).
3.3.6. Micro Focus Project and Portfolio Management.
Micro Focus Project and Portfolio Management (Micro Focus Project and
Portfolio Management, 2017) es un software que proporciona visibilidad de la cartera
en tiempo real, así como equilibra el suministro de recursos, brindando total control
sobre la demanda de los mismos. Con este software el usuario puede gestionar de
manera integrada los proyectos y tener el control para reducir la cantidad de
cronogramas y excesos de presupuesto de estos proyectos, reduciendo así los riesgos y
costes asociados con los proyectos fallidos.
En la Figura 10, puede observarse una captura de pantalla de la aplicación, en la
cual se observa diferente información sobre un proyecto: el porcentaje completado del
mismo, el coste actual, la duración prevista, el estado, la lista de tareas y la cartera a la
que pertenece, entre otros datos.
26
Figura 10: Entorno de Micro Focus Project and Portfolio Management (Micro
Focus Project and Portfolio Management, 2017).
3.3.7. UNICOM Focal Point.
UNICOM adquirió en 2014 el producto “IBM Rational Focal Point”, el cual se
trataba de un software para la gestión de proyectos y carteras desarrollado por IBM.
UNICOM Focal Point (UNICOM Focal Point, 2017) es una solución flexible basada en
la web que permite al usuario realizar una gestión de productos y carteras impulsada por
las necesidades del mercado y sus objetivos comerciales. Focal Point se adapta
rápidamente a la forma en que trabaja el usuario con sus métodos, procesos y flujos de
trabajo. Alguna de las funcionalidades de Focal Point con respecto a la gestión de
carteras de proyectos son las siguientes:
Supervisión de presupuestos reales frente a los que se espera en términos de
costos y beneficios.
Visualización de información importante como riesgos, problemas y elementos
de acción vinculados a carteras y proyectos.
Posibilidad de promover proyectos que ayuden al usuario a alcanzar sus
objetivos lo antes posible.
Comprensión de la fase del ciclo de vida en la que se encuentra el proyecto.
Posibilidad de priorizar carteras/proyectos.
Facilidad para planificar entregas en función de las limitaciones de las personas,
el dinero y el tiempo.
Construcción de gráficos de hoja de ruta para el cambio y posibilidad de
modificación según las restricciones.
En la Figura 11, se muestra una captura de la herramienta analizada en la que se
muestra la interfaz y el entorno que ésta utiliza. Podemos observar en la misma una lista
con una serie de proyectos, para los cuales la herramienta muestra su estado, los costes
27
planificados, el nombre del proyecto y los costes planificados de su mantenimiento,
entre otros datos.
Figura 11: Entorno de UNICOM Focal Point (UNICOM Focal Point, 2017).
3.4. Resumen, conclusiones y contribuciones esperadas
del TFG.
A lo largo de este capítulo se ha explicado el concepto de Gestión de Carteras
de Proyectos Software. Se ha podido apreciar la importancia de una correcta gestión en
las organizaciones empresariales, siendo actualmente verdaderamente importante para
el devenir de cualquier empresa.
De hecho, establecer una disciplina de gestión de cartera efectiva es uno de los
pasos más significativos e importantes que una organización puede realizar para mejorar
la ejecución de la estrategia empresarial. Puesto que una óptima gestión de cartera
involucra a muchas áreas del negocio, la proactividad del gestor de cartera es
verdaderamente relevante puesto que tendrá que relacionarse no sólo con la alta
dirección empresarial y con los gestores de los proyectos de su cartera, sino también con
muchos otros departamentos de la organización.
Tras analizar a fondo el mercado de las herramientas de gestión de carteras de
proyectos, llegamos a la conclusión que existen muchas y muy variadas que nos
permiten realizar una óptima gestión de éstas, ayudando en la medida de lo posible a
conseguir el objetivo estratégico fijado por la empresa. Pero todas estas herramientas
están enfocadas a proyectos en general, abarcando por tanto los mayores mercados
28
posibles: mercados de desarrollo de software, de automoción, de aeronáutica, navales…
No obstante, no se han encontrado herramientas software enfocadas al ámbito de las
carteras de proyectos software.
Es por ello que la herramienta que ha sido desarrollada durante este TFG tiene
esa valía que la diferencia de todas las anteriormente analizadas: está enfocada única y
exclusivamente a carteras de proyectos software. Con esta herramienta las
organizaciones podrán realizar un seguimiento óptimo de sus carteras de proyectos
software y de los proyectos contenidos en éstas, con indicadores clave para este tipo de
proyectos como puede ser la Gestión del Valor Ganado Tradicional o la Gestión del
Valor Ganado Ágil, dependiendo de la metodología utilizada durante el desarrollo del
proyecto en cuestión.
29
CAPÍTULO 4
MÉTODO DE TRABAJO
En este capítulo se expone el método de trabajo que se ha seguido a lo largo del
desarrollo del presente TFG, abarcando las fases de análisis, diseño, implementación y
documentación.
En primer lugar se analiza la metodología utilizada para el desarrollo de la
herramienta, la cual ha sido OpenUP, puesto que es una metodología adecuada para
equipos de trabajo pequeños o incluso individuales y está basada en un modelo iterativo
e incremental.
Para finalizar, se detalla el marco tecnológico, herramientas y lenguajes, que se
han empleado durante el presente TFG, así como las herramientas utilizadas para
realizar la documentación necesaria.
4.1. OpenUP
OpenUP (Eclipse EPF, 2012) es una metodología que se usa principalmente para
el desarrollo de software. Fue propuesta por un conjunto de empresas tecnológicas y
posteriormente donada a Eclipse Software Fundation, quien lo publicó bajo una licencia
libre.
Esta metodología está basada en un desarrollo iterativo e incremental, lo cual se
ajusta a la naturaleza del desarrollo del presente TFG. Esto nos permite realizar
pequeños micro-incrementos dentro de cada una de las iteraciones aportando un valor al
proyecto de manera que se obtenga una versión totalmente probada y funcional tras
cada iteración. Todo esto queda reflejado a modo de resumen en la Figura 12:
30
Figura 12: Visión general de OpenUP (Eclipse EPF, 2012).
OpenUP está diseñada para pequeños grupos de trabajo, tomando una aproximación
del desarrollo ágil. OpenUP se basa en cuatro principios fundamentales (Eclipse EPF,
2012):
Principio del diseño basado en la arquitectura. Este principio promueve
centrarse en la arquitectura de forma temprana para minimizar el riesgo y
organizar el desarrollo.
Principio del desarrollo evolutivo. Es muy importante para ir obteniendo
retroalimentaciones y de esta forma conseguir una mejora continua. Permite
reducir los errores en etapas tempranas.
Principio de colaboración. Este principio promueve prácticas que impulsan un
ambiente de equipo saludable, facilitan la colaboración y desarrollan un
conocimiento compartido del proyecto, proporcionando feedback que es usado
en iteraciones posteriores.
Principio del máximo beneficio. Equilibrar las propiedades para maximizar el
beneficio obtenido por los agentes o stakeholders.
31
4.1.1. Ciclo de vida.
OpenUP se repite a lo largo de una serie de ciclos que constituyen el
denominado Ciclo de Vida de un sistema. Cada uno de ellos concluye con una versión
del producto lista para ser enseñada a los clientes, junto a una documentación acorde a
la versión.
Uno de los objetivos del ciclo de vida del proyecto es centrarse en dos
impulsores clave de las partes interesadas: reducción de riesgos y creación de valor.
Como se muestra en la Figura 13, las cuatro fases del ciclo de vida de OpenUP (Inicio,
Elaboración, Construcción y Transición) enfocan al equipo en la reducción del riesgo
mientras se sigue la creación de valor.
Figura 13: Etapas del ciclo de vida de OpenUP (Eclipse EPF, 2012).
Las características esenciales de cada fase del ciclo de vida sería la siguiente
(Eclipse EPF, 2012):
Fase de Inicio. En esta primera fase del proyecto los stakeholders y el equipo de
desarrollo colaboran para determinar los objetivos que se persiguen.
Fase de Elaboración. En esta segunda fase se analiza el problema y se define la
arquitectura del sistema. Se elabora un plan de proyecto, el cual incluye los
requisitos detallados. También se especifican las herramientas y tecnologías que
se usarán durante el desarrollo.
Fase de Construcción. En esta fase se diseña, implementa y prueba el software.
Fase de Transición. En esta última fase el proceso se enfoca en la transición del
producto de software a la plataforma tecnológica del cliente, confirmando los
interesados que el desarrollo del producto cumple o no con los requisitos
planteados. El propósito de esta fase es asegurar que el producto de software está
listo para ser distribuido a los usuarios.
32
4.1.2. Roles.
A la hora de elaborar cualquier software es importante que las personas que
intervienen cuenten con unas habilidades y destrezas distintas entre ellos, provocando
esto que unos individuos tengan más aptitudes que otros para cumplir las tareas
encomendadas de forma satisfactoria. En la Figura 14 se ilustran los roles que se
consideran en OpenUP. Cabe destacar que, debido a la naturaleza del presente TFG, los
roles serán ostentados por tres personas (el alumno, el director y la directora).
Figura 14: Diferentes roles en OpenUP.
A continuación, se describe cada uno de los roles mostrados en la Figura 14
(Eclipse EPF, 2012):
Analista. Representa la visión del cliente y de los usuarios finales involucrados,
obteniendo información desde los stakeholders para entender el problema que
debe ser resuelto y capturar las prioridades para los requisitos.
En el presente TFG este rol lo han desempeñado el director, la directora y el
alumno.
33
Figura 15: Relaciones del rol Analista en OpenUP.
Arquitecto. Responsable de diseñar la arquitectura del software, incluyendo
esto tomar las principales decisiones técnicas.
Durante el desarrollo del presente proyecto este rol lo ha desempeñado el
alumno.
Figura 16: Relaciones del rol Arquitecto en OpenUP.
Desarrollador. Responsable del desarrollo de una parte del sistema o del
sistema completo dependiendo de la magnitud del mismo.
Durante el desarrollo del presente proyecto este rol lo ha desempeñado el
alumno.
Figura 17: Relaciones del rol Desarrollador en OpenUP.
Project Manager. Encargado de liderar la planificación del proyecto en
colaboración con las partes interesadas y el equipo.
34
Durante el desarrollo del presente TFG este rol lo ha desempeñado el alumno,
con la supervisión del director y la directora.
Figura 18: Relaciones del rol Project Manager en OpenUP.
Stakeholders. Grupo de personas cuyas necesidades serán satisfechas con la
ejecución del proyecto. En este rol se incluye cualquier persona
afectada/relacionada por los objetivos del proyecto.
Durante el desarrollo del presente proyecto este rol lo han desempeñado el
director, la directora y el alumno.
Tester. Responsable de realizar las actividades básicas referentes a las pruebas.
Durante el desarrollo del presente TFG este rol lo ha desempeñado el alumno.
Figura 19: Relaciones del rol Tester en OpenUP.
Otros roles. Cualquier otra persona del equipo de trabajo que realiza tareas
generales.
Figura 20: Relaciones de otros roles en OpenUP.
35
4.2. Marco tecnológico.
En este apartado se exponen las tecnologías y herramientas utilizadas a lo largo
del desarrollo del presente TFG. En la Tabla 2 se muestra un resumen de éstas.
Gestión de
proyectos
Modelado y
documentación
Bases de
datos
Desarrollo de software
Tabla 2: Herramientas y tecnologías empleadas en el presente TFG.
36
4.2.1. Herramientas para la gestión de proyectos.
En este apartado se presentan las herramientas utilizadas para la gestión del
presente TFG.
4.2.1.1. Bitbucket.
Bitbucket (Bitbucket, 2017) es un repositorio privado para proyectos software
que incluye un sistema de control de versiones basado en Git y Mercurial. Además,
ofrece otros servicios como son una wifi, un gestor de incidencias e integración con
otros servicios como Twitter o Google.
Para el desarrollo del presente TFG se ha utilizado Bitbucket como sitio de
alojamiento y control de versiones.
4.2.1.2. Trello.
Trello (Trello, 2017) es una herramienta colaborativa de proyectos con interfaz
web. Usa el método Kanban (Anderson, 2003; Anderson, 2010) que organiza los
proyectos en tableros. Con un solo vistazo, Trello permite ver las tareas que se llevan a
cabo, quién trabaja en una tarea determinada y cuál es el estado de un proceso.
Así mismo, emplea el método Kanban para el registro de actividades con tarjetas
virtuales, permitiendo realizar tareas como agregar listas, adjuntar archivos, etiquetar
eventos y agregar comentarios, entre otras.
Durante el desarrollo del presente TFG, Trello ha sido utilizado para la gestión
de tareas a realizar durante el mismo, como se muestra en la Figura 21.
37
Figura 21: Panel de Trello del TFG.
4.2.2. Herramientas para el modelado software y
documentación.
En este apartado se presentan las herramientas que han sido utilizadas en el
modelado y en la documentación de este TFG.
4.2.2.1. Visual Paradigm for UML.
Visual Paradigm for UML (VP-UML, 2017) es una herramienta CASE
profesional que da soporte al modelado a través de UML. Esta herramienta permite
crear diferentes tipos de diagramas, además de aplicar ingeniería directa e inversa.
Durante este TFG, Visual Paradigm for UML ha sido utilizada para elaborar los
modelos UML necesarios para especificar los requisitos y el diseño de la aplicación
(Figura 22).
38
Figura 22: Utilización de Visual Paradigm for UML durante el modelado de casos
de uso del rol administrador.
4.2.2.2. Balsamiq Mockups.
Balsamiq Mockups (Balsamiq Mockups, 2017) es una aplicación para crear
maquetas para interfaces gráficas para usuario. Permite al diseñador diagramar widgets
pre construidos. Es una herramienta muy fácil de usar.
Balsamiq Mockups ha sido utilizada durante el desarrollo de este TFG para la
realización de los bocetos de las diferentes interfaces de la herramienta (Figura 23).
Figura 23: Utilización de Balsamiq Mockups durante el diseño de la interfaz de
usuario.
39
4.2.2.3. Microsoft Word.
Microsoft Word (Microsoft Word, 2017) ha sido la herramienta utilizada para
realizar la documentación del presente TFG.
4.2.3. Herramientas para la base de datos.
En este apartado se especifica la herramienta utilizada para el desarrollo de la
base de datos de este TFG.
4.2.3.1. MongoDB.
MongoDB (MongoDB, 2017) es la base de datos NoSQL (Bases de datos
NoSQL, 2017) líder y permite a las organizaciones ser más ágiles y escalables.
Empresas de todo el mundo usan MongoDB para crear nuevos tipos de aplicaciones,
mejorar la experiencia del cliente, acelerar el tiempo de comercialización y reducir
costes.
MongoDB ha sido utilizado durante el desarrollo de este TFG para la gestión de
toda la información persistente.
4.2.4. Entorno de desarrollo integrado (IDE), herramientas,
tecnologías y frameworks para el desarrollo de software.
En este apartado se especifican las herramientas, tecnologías, frameworks y
estándares que han sido utilizados para el desarrollo software de este TFG.
4.2.4.1. Eclipse.
Eclipse (Eclipse, 2017) es una plataforma de software compuesto por un
conjunto de herramientas de programación de código abierto multiplataforma. Esta
plataforma, típicamente ha sido usada para desarrollar entornos de desarrollo integrados
(del inglés IDE), como el IDE de Java llamado Java Development Toolkit (JDT) y el
compilador (ECJ) que se entrega como parte de Eclipse.
40
Eclipse ha sido el entorno de desarrollo integrado utilizado durante todo el
desarrollo del presente TFG (Figura 24).
Figura 24: Utilización de Eclipse durante el desarrollo de la herramienta.
4.2.4.2. Spring.
Spring (Spring, 2017) ha sido el framework utilizado para el desarrollo del
presente TFG. Es el framework más popular para la creación de aplicaciones con Java.
También es la herramienta con más demanda en el mercado para los desarrolladores con
este lenguaje. Spring ofrece diversos módulos que facilitan el desarrollo de aplicaciones
mediante los patrones de diseño de software más habituales.
Spring comprende diversos módulos que proveen un rango de servicios (Spring
Framework, 2017):
Contenedor de inversión de control.
Programación orientada a aspectos.
Acceso a datos.
Gestión de transacciones.
Framework de acceso remoto.
Convención sobre Configuración.
Procesamiento por lotes.
Autenticación y Autorización.
Administración remota.
Mensajes.
Testing.
41
Modelo vista controlador.
Este último es una de las partes más importantes de Spring. Este patrón de diseño
permite separar el código en tres partes (Álvarez, 2014):
Modelo: es la parte que gestiona la información. Es decir, las conexiones a la
base de datos y las actualizaciones, y envía a la vista la información a través del
controlador.
Vista: es parte que percibe el usuario y con la que interacciona.
Controlador: se encarga de la lógica de la aplicación, haciendo de nexo entre el
Modelo y la Vista. Cada controlador será una clase con los métodos, y por cada
método habrá una vista que representará la versión procesada de ese método.
A continuación, en la figura 25, se muestra una explicación gráfica del patrón MVC.
Figura 25: Explicación gráfica del patrón MVC (Gemio, 2017).
4.2.4.3. Maven.
Maven (Maven, 2017) es una herramienta de software para la gestión y
construcción de proyectos. Tiene un modelo de configuración de construcción basado
en un formato XML. Maven utiliza un Project Object Model (POM) para describir el
proyecto de software a construir, sus dependencias de otros módulos y componentes
42
externos, y el orden de construcción de los elementos. Viene con objetivos predefinidos
para realizar ciertas tareas claramente definidas, como la compilación del código y su
empaquetado.
Durante el desarrollo del presente TFG, Maven ha sido utilizado para la gestión
de dependencias entre módulos y componentes externos del mismo.
4.2.4.4. Bootstrap.
Boostrap (Bootstrap, 2017) es un framework de código abierto para diseño de
sitios y aplicaciones web. Contiene plantillas de diseño con tipografía, formularios,
botones, cuadros, menús de navegación y otros elementos de diseño basado en HTML5
y CSS3, así como extensiones de JavaScripts opcionales adicionales. Fue desarrollado
por Twitter.
Bootstrap ha sido utilizado durante el desarrollo de este TFG para los diseños de
las interfaces de la herramienta web. De este modo, Bootstrap permite que la
herramienta desarrollada sea responsive, es decir, permite redimensionar y colocar los
elementos de la web de forma que éstos se adapten al ancho de cada dispositivo,
permitiendo una óptima visualización; así como la compatibilidad con los diversos
navegadores existentes.
4.2.4.5. HTML5.
HTML (HTML5, 2017) (HyperText Markup Language) es un lenguaje de
marcado utilizado para la generación de páginas web en el lado del cliente. Es un
estándar a cargo del World Wide Web Consortium (W3C), organización dedicada a la
estandarización de casi todas las tecnologías ligadas a la web, sobre todo en lo referente
a su escritura e interpretación. Basa su funcionalidad en el uso de etiquetas para definir
las distintas partes que componen la página.
Para el desarrollo de la herramienta web la versión elegida de HTML ha sido la
última, la cual es la HTML5.
4.2.4.6. CSS3
CSS (CSS3, 2017) (Cascading Style Sheets) es un lenguaje de diseño gráfico
para definir y crear la presentación de un documento estructurado escrito en un lenguaje
de marcado. Es muy usado para establecer el diseño visual de los documentos web.
43
Para el desarrollo de la herramienta del presente TFG se ha utilizado la última
versión, la cual es CSS3.
4.2.4.7. Jquery.
Jquery (JQuery, 2017) es una biblioteca multiplataforma de JavaScript, la cual
permite simplificar la manera de interactuar con los documentos HTML o agregar
interacción con los diversos elementos de una página web.
Durante el desarrollo del presente proyecto, Jquery ha sido utilizado en las
páginas JSP para interactuar con los elementos HTML.
4.2.4.8. Java.
Java (Java, 2017) es un lenguaje de programación de propósito general,
concurrente y orientado a objetos. En la actualidad, Java es uno de los lenguajes de
programación más populares en uso, particularmente para aplicaciones de cliente-
servidor de web.
En el presente TFG, Java ha sido el lenguaje de programación utilizado en la
parte servidor.
4.2.4.9. Amcharts.
Amcharts (Amcharts, 2017) es una librería muy completa para hacer charts
mediante JavaScript. Es desarrollada por una pequeña compañía de Lituania,
En el presente TFG, la librería Amcharts ha sido utilizada como mecanismo de
visualización, representando gráficos relevantes en la gestión de las carteras de
proyectos.
En la Figura 26 se muestran algunos ejemplos de charts que pueden
representarse con la librería Amcharts.
44
Figura 26: Ejemplos de charts representados con la librería Amcharts (Amcharts,
2017).
4.2.4.10. JSON.
JSON (JSON, 2017) (JavaScript Object Notation) es un formato de texto ligero
para el intercambio de datos. JSON es un subconjunto de la notación literal de objetos
de JavaScript aunque hoy, debido a su amplia adopción como alternativa a XML, se
considera un formato de lenguaje independiente.
4.2.4.11. JSTL.
La librería JSTL (JSTL, 2017) es un componente dentro de la especificación de
Java 2 Enterprise Edition (J2EE) y es controlada por Sun MicroSystems. JSTL no es
más que un conjunto de librerías de etiquetas simples y estándares que encapsulan la
funcionalidad principal que es usada comúnmente para escribir páginas JSP, siendo ésta
la funcionalidad para la que se ha utilizado en el presente TFG.
4.2.4.12. AJAX.
AJAX (AJAX, 2017) (Asynchronous JavaScript And XML) es una técnica de
desarrollo web para crear aplicaciones interactivas. Estas aplicaciones se ejecutan en el
cliente, es decir, en el navegador de los usuarios mientras se mantiene la comunicación
asíncrona con el servidor en segundo plano. De esta forma, es posible realizar cambios
45
sobre las páginas sin necesidad de recargarlas, mejorando la interactividad, velocidad y
usabilidad en las aplicaciones.
4.2.4.13. Apache Tomcat.
Apache Tomcat (Apache Tomcat, 2017) funciona como un contenedor de
servlets desarrollado en la Apache Software Foundation. Tomcat implementa las
especificaciones de los servlets y de JavaServer Pages (JSP).
Durante el desarrollo de este TFG, la versión de Tomcat elegida como servidor
ha sido la v8.5.
46
47
CAPÍTULO 5
RESULTADOS: HERRAMIENTA SPT2
En el presente capítulo se presentan los resultados obtenidos a lo largo del
desarrollo de la herramienta, aplicando, como hemos comentado en el capítulo anterior,
la metodología OpenUP.
El desarrollo se ha llevado a cabo siguiendo el ciclo de vida propio de esta
metodología, de tal forma que se ha recorrido cada una de las fases propias de la misma:
Fase de Inicio, Fase de Elaboración, Fase de Construcción y Fase de Transición. Así
mismo, cada una de estas fases estará compuesta por diferentes iteraciones, con sus
respectivos incrementos.
A continuación, se presentan los resultados obtenidos en cada una de las fases e
iteraciones.
5.1. Fase de inicio.
La fase de inicio ha estado compuesta de varias tareas, tales como reuniones con
los directores del proyecto con el fin de analizar los requisitos de la herramienta y
obtener un completo análisis global de la solución requerida, primeras consultas a la
bibliografía para tener una comprensión lo más completa posible de la dimensión
general del proyecto, definición de las funcionalidades concretas de la herramienta a
realizar durante el presente TFG y el análisis y realización del plan de iteraciones del
desarrollo del proyecto. También, durante esta fase se han realizado los diagramas de
casos de uso de las funcionalidades que se deben implementar.
5.1.1. Análisis de requisitos.
Para comenzar, es importante destacar que los roles que interactuarán con la
herramienta serán varios, ya que no todos los usuarios tendrán disponibles las mismas
funcionalidades según su rol. En concreto, se han definido cuatro: el administrador de
la herramienta, la alta dirección, el gestor de cartera de proyectos y el gestor de
proyecto.
Una vez definidos e identificados los roles y los objetivos del proyecto, se
extraen los siguientes requisitos:
48
Gestión de usuarios. El administrador y la alta dirección podrá dar de alta
nuevos usuarios a la herramienta. Así mismo, podrá eliminarlos de la misma.
También cabe mencionar que todos los usuarios podrán ver su perfil en
cualquier momento y modificar, si así lo desean, su contraseña de acceso al
sistema.
Extracción de la información de interés desde ficheros MS-Project. Se
deberá extraer la información que se encuentre en archivos con extensión .xml
exportados de MS-Project con el fin de crear nuevos proyectos en la cartera de
proyectos deseada o para actualizar la fecha de estado de un proyecto concreto.
Gestión de proyectos. El gestor de proyecto tendrá la posibilidad de visualizar
toda la información de los proyectos que gestione. Así mismo, siempre y cuando
el proyecto en cuestión se encuentre en progreso, podrá actualizar los diferentes
estados individuales del mismo (financiero, de calendario, de alineamiento y de
riesgos) y también podrá actualizar la fecha de estado del proyecto de forma
manual o de forma automática, mediante la extracción de la información de
archivos .xml anteriormente mencionada.
Gestión de carteras de proyectos. El gestor de cartera de proyectos tendrá la
posibilidad de visualizar toda la información de las carteras de proyectos que
gestione, al igual que de todos los proyectos que contengan cada una de éstas.
Éste también podrá cambiar el estado global de los proyectos contenidos en las
carteras que dirige, es decir, pasar el proyecto deseado del estado en progreso a
terminado o cancelado, según se requiera. Así mismo, tendrá la posibilidad de
cambiar el estado individual (financiero, de calendario, de alineamiento y de
riesgos) de sus carteras de proyectos mientras que éstas se encuentren en
progreso. El gestor de cartera de proyectos también podrá crear nuevos
proyectos en sus carteras, siempre y cuando la cartera en concreto se encuentre
en progreso, mediante la extracción de la información de archivos .xml.
Gestión completa de carteras de proyectos en una organización. La alta
dirección podrá visualizar todas las carteras de proyectos, junto con todos los
proyectos contenidos en éstas, de la organización a la que pertenezcan con el fin
de saber en todo momento el estado de éstas. Este usuario tendrá la posibilidad
de cambiar el estado global de la cartera de proyectos que desee, así como de
cualquier proyecto contenido en éstas, siempre y cuando la cartera de proyectos
y/o el proyecto en cuestión se encuentren en progreso. Esto quiere decir que, si
la alta dirección desea por ejemplo cancelar una cartera, podrá hacerlo, y por
ende todos los proyectos que contenga esa cartera y se encuentren en progreso,
se cancelarán también. Otra funcionalidad destacable de la alta dirección es que
podrá crear nuevas carteras de proyectos en su empresa, asignándosela al gestor
de cartera deseado.
49
Completa Gestión del Valor Ganado de los proyectos. La herramienta
mostrará un completo análisis referente a la Gestión del Valor Ganado de cada
proyecto, teniendo como fuente la extracción de información automática y/o los
valores proporcionados por el usuario. Este análisis incluye una gráfica
representativa de los valores en cada fecha de estado registrada.
Mecanismos de visualización. La herramienta considerará diversos
mecanismos de representación tanto tabulares como gráficos, con el fin de
facilitar a los usuarios la toma de decisiones.
5.1.2. Modelo de Casos de Uso.
Tras haber determinado los requisitos, se ha llevado a cabo la realización del
diagrama de casos de uso del sistema. A continuación se presentan los casos de uso de
los roles identificados con anterioridad: administrador, alta dirección, gestor de cartera
de proyectos y gestor de proyecto. Cabe mencionar que la funcionalidad Autenticar se
ha omitido, puesto que es común a todos los roles.
En la Figura 27 podemos observar las funciones correspondientes al rol
administrador:
50
Figura 27: Funcionalidades del rol administrador.
Como puede apreciarse en la Figura 27, el administrador no tiene acceso de
ningún tipo a visualización de datos, ni de carteras de proyectos de la empresa a la que
pertenezca, ni de proyectos. La funcionalidad de este tipo de usuario se resume en
creación y eliminación de usuarios de la base de datos y creación y asignación tanto de
carteras de proyectos, como de proyectos.
A continuación, en la Figura 28, se presenta el diagrama de casos de uso para el
rol alta dirección:
51
Figura 28: Funcionalidades del rol alta dirección.
Como se muestra en la Figura 28, las funcionalidades del usuario con el rol alta
dirección son muy variadas. Al igual que el administrador, éste puede crear y eliminar
usuarios de su empresa de la base de datos, así como crear nuevas carteras de proyectos
en su organización. Lo más destacable con respecto a los demás roles es que puede
visualizar todas las carteras de proyectos que tiene su empresa, así como todos los
proyectos contenidos en éstas, pudiendo actualizar el estado general tanto de cualquier
cartera como de cualquier proyecto siempre y cuando se encuentren en el estado general
en progreso.
Seguidamente, podemos ver en la Figura 29 las funciones correspondientes al rol
gestor de cartera de proyectos:
52
Figura 29: Funcionalidades del rol gestor de cartera de proyectos.
Como se aprecia en la Figura 29, las funcionalidades del gestor de cartera de
proyectos son más limitadas que la del rol alta dirección. La funcionalidad más
destacable y que ningún otro rol puede llevar a cabo, es la posibilidad de actualización
de los estados individuales (financiero, de calendario, de alineamiento y de riesgos) de
las carteras de proyectos que gestiona, siempre y cuando éstas se encuentren en el
estado general en progreso. También puede actualizar el estado general de los proyectos
contenidos en sus carteras, funcionalidad que comparte con el usuario con el rol alta
dirección.
Finalmente, en la Figura 30 se presenta el diagrama de casos de uso para el rol
gestor de proyecto:
53
Figura 30: Funcionalidades del rol gestor de proyecto.
Como se muestra en la Figura 30, el gestor de proyecto es el usuario cuyas
funcionalidades son más limitadas. Las funcionalidades que destacan por encima de las
demás son la actualización de los valores de la Gestión del Valor Ganado del proyecto,
y los cambios de los estados individuales de éste; siendo estas dos funcionalidades
propias de este rol.
5.1.3. Plan de Iteraciones.
A partir del diagrama de casos de uso y los requisitos identificados se ha
realizado el plan de iteraciones. En la Tabla 3 se muestran las iteraciones planificadas,
junto con los objetivos asociados a cada una de ellas:
54
Fase Iteración Objetivos
Inicio 0
Análisis del problema.
Análisis de los requisitos del proyecto.
Análisis y desarrollo del plan de iteraciones.
Elaboración 1
Configuración del entorno.
Diseño de la arquitectura del sistema.
Diseño de la base de datos.
Diseño de la interfaz de usuario.
Implementación de la arquitectura y de la interfaz.
Construcción
2 Implementación funcionalidad importar proyectos
.xml exportados de MS-Project.
3 Implementación funcionalidad gestión de usuarios.
4 Implementación funcionalidad creación de carteras
de proyectos y proyectos.
5 Implementación funcionalidad vistas de la
herramienta para el seguimiento de carteras.
6 Implementación funcionalidad representación
gráfica de la información de seguimiento de
carteras.
7 Implementación funcionalidad cambios de estado
de carteras de proyectos y de proyectos.
8 Implementación funcionalidad actualización
valores Gestión del Valor Ganado del proyecto.
9 Implementación funcionalidad descarga del
informe con la información del proyecto deseado.
10 Implementación funcionalidad envío de correo
electrónico al usuario.
Transición 11 Integración de la versión final.
Manual de usuario.
Tabla 3: Plan de Iteraciones.
Tal como puede observarse en la Tabla 3, en las primeras iteraciones se aborda
el análisis y diseño del desarrollo de la herramienta para luego implementar
funcionalidades progresivamente, aportando éstas cada vez más valor a la herramienta.
55
5.2. Fase de elaboración.
La fase de elaboración está compuesta por únicamente una iteración, en la cual
se ha realizado la configuración del entorno, el diseño de la arquitectura del sistema, de
la interfaz de usuario y de la base de datos, creando de este modo un punto de partida
para el desarrollo de las siguientes iteraciones.
5.2.1. Iteración 1. Configuración del entorno, diseño de la
arquitectura del sistema, de la base de datos y de la interfaz
de usuario.
5.2.1.1. Configuración del entorno.
El presente TFG se ha desarrollado en un equipo con las siguientes
características:
Sistema operativo: Windows 7 Home Premium
Procesador: Inter® Core™ i7-3610QM 2.30 GHz con tecnología Turbo Boost
hasta 3.3 GHz.
Memoria RAM: 8 GB
Arquitectura: 64 bits
Para la realización del proyecto ha sido necesario tener instalado el IDE Eclipse,
siendo en concreto la versión utilizada la neon.1, con el plugin del framework Spring.
5.2.1.2. Diseño de la arquitectura del sistema.
Para la implementación de la herramienta se ha utilizado el framework de
desarrollo Spring, junto con una arquitectura MVC (Modelo – Vista – Controlador). El
patrón MVC, como ya se ha comentado en el apartado 4.2.4.2, es un paradigma que
divide una aplicación en las siguientes partes:
Modelo (Persistencia): capa donde se establecen las reglas de negocio. Es la
encargada de la comunicación con la base de datos persistente para el
intercambio de datos, y de notificar los cambios que se produzcan en los mismos
a la capa de Presentación.
56
Para la parte de implementación de esta capa, se usará MongoDB como Base de
Datos no relacional.
Vista (Presentación): capa donde se muestra la información almacenada en la
capa de Modelo al usuario. Es la encargada de transmitir los datos insertados por
el usuario a la capa de Controlador, así como de recibir los datos procesados por
la capa de Controlador o Modelo, y mostrarlos al usuario.
Las tecnologías usadas para la parte de implementación de esta capa serán
Bootstrap, HTML5, CSS3, Jquery, Ajax y lenguaje de marcado JSTL.
Controlador (Dominio): capa encargada de la gestión del control de la
aplicación y de los datos insertados del usuario, así como de recibir los eventos
de entrada de información. Además, contiene las reglas de gestión de estos
eventos para operar con ellos.
Se usará Java como lenguaje de programación para la creación de todos los
controladores.
La implementación de cada capa viene reflejada a modo resumen en la Tabla 4:
Modelo Vista Controlador
Tabla 4: Herramientas y tecnologías usadas para cada capa del modelo MVC.
57
5.2.1.3. Diseño de la base de datos.
En este apartado se muestra el modelo de datos que se ha realizado para cumplir
con los requisitos establecidos en el presente TFG. El diseño está representado en el
diagrama de la Figura 31.
Figura 31: Diseño de la base de datos que se utilizará para la herramienta.
Tal y como puede observarse en la Figura 31, existen 3 colecciones para
representar toda la información del proyecto: Usuarios, Carteras y Proyectos. Algunos
datos importantes sobre este modelado de datos son los siguientes:
El atributo company está presente en las tres primeras colecciones mencionadas,
refiriéndose éste a la empresa u organización a la que pertenecen los usuarios,
las carteras y los proyectos.
Tanto los proyectos como las carteras tienen un estado general, el cual puede
tomar uno de los siguientes valores: en progreso, terminado o cancelado; y
58
cuatro estados individuales, los cuales son estado financiero, estado de
calendario, estado de alineamiento y estado de riesgos, pudiendo tomar éstos el
valor bien, mal o regular.
El atributo managementMethod de la colección Proyectos puede tomar uno de
los siguientes valores: Tradicional o Ágil. Si toma el valor Tradicional, el
proyecto en cuestión tendrá el atributo valuesTraditionalEVM y no tendrá
valuesAgileEVM. Por el contrario, si toma el valor Ágil, el proyecto tendrá el
atributo valuesAgileEVM y no tendrá valuesTraditionalEVM.
El atributo valuesTraditionalEVM se utiliza para registrar fechas de estado con
sus respectivos valores en un proyecto siguiendo metodología tradicional con el
objetivo de gestionar de manera correcta el Valor Ganado del mismo. Gracias a
este listado de registros de fechas de estado la herramienta es capaz de mostrar
una gráfica de la Gestión del Valor Ganado en la vista del proyecto, siempre y
cuando el proyecto en cuestión tenga más de una fecha de estado registrada. A
su vez, valuesTraditionalEVM contiene listas con los siguientes atributos:
statusDate, EV, PV, AC, CV, SV, CPI, SPI, TCPI, recommendation.
El atributo valuesAgileEVM se utiliza para registrar fechas de estado con sus
respectivos valores en un proyecto siguiendo metodología ágil con el objetivo de
hacer una correcta Gestión del Valor Ganado del mismo. Gracias a este listado
de registros de fechas de estado, la aplicación es capaz de mostrar una gráfica de
la Gestión del Valor Ganado en la vista de proyecto, siempre y cuando el
proyecto en cuestión tenga registrada más de una fecha de estado. A su vez,
valuesAgileEVM contiene listas con los siguientes atributos: statusDate, EV, AC,
plannedPoints, completedPoints, CV, SV, CPI, SPI, TCPI, recommendation.
La razón por la que se ha utilizado durante el desarrollo de la herramienta una base
de datos no relacional como lo es MongoDB es por dos motivos, los cuales se presentan
a continuación:
Todos los proyectos no tienen los mismos atributos, ya que, dependiendo del
método de gestión utilizado durante el proyecto en cuestión, éste tendrá el
atributo valuesTraditionalEVM o valuesAgileEVM.
No cerrar puertas a un trabajo futuro, al igual que se presenta en el capítulo 6.2,
ya que se considera que podría continuarse con el desarrollo de la herramienta
ampliando su funcionalidad y siendo necesario incorporar flexibilidad a la hora
de gestionar la información de cada cartera (que podría diferir de unas a otras
según su tipología), lo que aumentaría notablemente el valor de la misma.
Además, en un entorno real de explotación de la herramienta podría ser
necesario manejar grandes volúmenes de datos, lo que requeriría una mayor
eficiencia que es porporcionada mediante este enfoque.
59
5.2.1.3. Diseño de la interfaz de usuario.
A la hora de diseñar la interfaz de usuario se tuvo en cuenta en primer lugar la
división en roles de la herramienta, de modo que no todos los usuarios accederán a la
misma pantalla al entrar a la aplicación. Se han tenido en cuenta en el diseño el uso de
patrones de usabilidad (Neil, 2010) de acuerdo a cada rol.
En primer lugar, se presenta la interfaz de la página del administrador de la
herramienta, compuesta por los siguientes elementos:
Barra superior en la que podrá visualizar su perfil y hacer logout.
Botón para crear nuevas carteras de proyectos.
Botón para crear nuevos proyectos.
Botón para dar de alta a nuevos usuarios en la aplicación.
Botón para eliminar a usuarios ya existentes de la herramienta.
El diseño de la interfaz del administrador está representado por la Figura 32:
Figura 32: Diseño de la interfaz del administrador.
60
Los elementos que contendrán esta interfaz son los siguientes:
Barra superior en la que podrá visualizar su perfil y hacer logout.
Gráficos representativos de información relacionada con las carteras de
proyectos que tenga la organización.
Tablas con las carteras de proyectos, divididas éstas según su estado.
Botón para crear nuevas carteras de proyectos.
Botón para dar de alta a nuevos usuarios en la aplicación.
Botón para eliminar a usuarios ya existentes de la herramienta.
La Figura 33 muestra el diseño de la interfaz del rol alta dirección:
Figura 33: Diseño de la interfaz del rol alta dirección.
Para la realizar el diseño de la interfaz de usuario del rol gestor de cartera de
proyectos, tenemos que tener en cuenta dos posibles escenarios: que el usuario gestione
una sola cartera de proyectos, o varias.
Si el usuario gestiona solamente una cartera de proyectos, accederá directamente
a la vista con toda la información de ésta. Los elementos que contendrá esta vista son
los siguientes:
61
Barra superior en la que podrá visualizar su perfil y hacer logout.
Gráficos representativos de información relacionada con los proyectos que
contenta su cartera de proyectos.
Tablas con los proyectos, divididos éstos según su estado.
Botón para crear nuevos proyectos en la cartera.
En la Figura 34 puede observarse el diseño de la interfaz para el rol gestor de
cartera de proyectos en el caso indicado.
Figura 34: Diseño de la interfaz del gestor de cartera de proyectos cuando el
usuario gestiona una sola cartera de proyectos.
En el caso contrario al mencionado, es decir, si el usuario gestiona varias
carteras de proyectos, la interfaz cuando acceda a la herramienta tendrá los siguientes
elementos:
Barra superior en la que podrá visualizar su perfil y hacer logout.
Tablas con las carteras que gestiona, divididas éstas según su estado.
La Figura 35 muestra el diseño de la interfaz para el rol gestor de cartera de
proyectos en el caso analizado.
62
Figura 35: Diseño de la interfaz del gestor de carteras de proyectos cuando el
usuario gestiona varias carteras.
Para la realizar el diseño de la interfaz de usuario del rol gestor de proyecto,
tenemos que tener en cuenta dos escenarios similares al rol anterior: que el usuario
gestione un solo proyecto, o varios.
Si el usuario gestiona solamente un proyecto, accederá directamente a la vista
con toda la información de éste. Los elementos que contendrá esta vista son los
siguientes:
Barra superior en la que podrá visualizar su perfil y hacer logout.
Gráficos representativos con información del proyecto.
Diversas pestañas con el fin de organizar toda la información.
Botón para descargar la información del proyecto.
En la Figura 36 puede observarse el diseño de la interfaz para el rol gestor de
proyectos en el caso indicado.
63
Figura 36: Diseño de la interfaz del gestor de proyecto cuando el usuario gestiona
varios proyectos.
En el caso contrario al mencionado, es decir, si el usuario gestiona varios proyectos,
la interfaz cuando acceda a la herramienta tendrá los siguientes elementos:
Barra superior en la que podrá visualizar su perfil y hacer logout.
Tablas con los proyectos que gestiona, divididas éstas según el estado de los
mismos.
La Figura 37 muestra el diseño de la interfaz para el rol gestor de proyecto en el
caso analizado.
64
Figura 37: Diseño de la interfaz del gestor de proyecto cuando el usuario gestiona
varios proyectos.
5.3. Fase de construcción.
Esta fase está dividida en ocho iteraciones. En cada una de éstas van
obteniéndose incrementos de funcionalidad de la herramienta, con el objetivo de que
después de cada iteración se haya producido un incremento de valor de la aplicación.
Las funcionalidades a implementar en las iteraciones de esta fase son las siguientes:
Importación de proyectos .xml exportados de MS-Project.
Gestión de usuarios.
Creación tanto de carteras de proyectos, como de proyectos.
Vistas de la herramienta para el seguimiento de carteras.
Representación gráfica de la información de seguimiento de carteras.
Cambios de estado tanto de las carteras de proyectos, como de los proyectos.
Actualización de valores de la Gestión del Valor Ganado del proyecto.
Descarga del informe con la información del proyecto deseado.
Envío de correo electrónico al usuario.
65
5.3.1. Iteración 2. Importación de proyectos .xml exportados
de MS-Project.
En esta iteración se ha implementado el módulo cuya funcionalidad consiste en
extraer la información relevante de proyectos exportados de MS-Project con extensión
.xml. La implementación de esta funcionalidad se lleva a cabo con dos objetivos:
Permitir al gestor de cartera de proyectos crear nuevos proyectos en su cartera
mediante la carga automática de la información almacenada en estos archivos.
En este caso, del archivo .xml seleccionado por el usuario se desea extraer la
siguiente información:
o Nombre del proyecto.
o Fecha de creación.
o Fecha prevista de finalización.
o Porcentaje completado.
o Presupuesto.
o Valores referentes a la Gestión del Valor Ganado:
Fecha de estado.
EV.
AC.
PV.
Permitir al gestor de proyecto registrar nuevas fechas de estado con sus
respectivos nuevos valores de la Gestión del Valor Ganado mediante la
extracción automática de la información almacenada en estos archivos. Para este
caso, del archivo .xml que seleccione el usuario solamente hace falta extraer la
siguiente información:
o Valores referentes a la Gestión del Valor Ganado:
Fecha de estado.
EV.
AC.
PV.
Para desarrollar esta iteración se han implementado dos vistas, una para cada
uno de los casos mencionados anteriormente, pero ambas con el mismo objetivo: que el
usuario seleccione el proyecto .xml del que desea extraer la información. La vista para la
selección del archivo .xml deseado se presenta en la Figura 38.
66
Figura 38: Vista para que el gestor de cartera de proyectos seleccione un archivo
.xml.
Cuando el usuario seleccione el archivo deseado y pulse Seleccionar proyecto,
un pequeño script implementado en el jsp correspondiente envía mediante una llamada
AJAX al controlador el archivo deseado para que éste sea procesado. El código de este
script se muestra en la Figura 39:
Figura 39: Script que envía el archivo seleccionado al controlador mediante una
llamada AJAX.
67
En lo que respecta al controlador, se han implementado los métodos en JAVA
necesarios para hacer la lectura de información del archivo en cuestión. Para realizar
dicha lectura de estos archivos se ha utilizado la librería MPXJ (MPXJ, 2017), la cual
nos permite extraer toda la información posible de los archivos exportados de MS-
Project. En la Figura 40 se muestra un extracto del método que se encarga de leer la
información almacenada en el archivo .xml:
Figura 40: Extracto del método JAVA que lee la información del archivo .xml
seleccionado.
Como podemos observar hacemos uso de la librería MPXJ (new
MSPDIReader()), teniendo finalmente un objeto ProjectFile del que extraeremos toda la
información.
5.3.2. Iteración 3. Gestión de usuarios.
Esta iteración comprende el desarrollo del módulo referente a la gestión de los
usuarios que tendrán el acceso y podrán interactuar con la herramienta. Tal y como se
ha mostrado en el diagrama de casos de uso en la Figura 27 y en la Figura 28, la gestión
de usuarios corresponde al rol Administrador y al rol Alta Dirección, como se presenta
en la figura 41 y 42. Tanto el Administrador como la Alta Dirección tienen la
posibilidad de dar de alta o de baja a los usuarios en la aplicación.
68
Figura 41: Casos de uso para la gestión de los usuarios del administrador.
Figura 42: Casos de uso para la gestión de los usuarios de la alta dirección.
Crear usuario
En este módulo se dará de alta al nuevo usuario en la aplicación. La vista para la
creación del mismo tanto del administrador como de la alta dirección es la misma.
Cuando se dé de alta a un nuevo usuario se deberá introducir la siguiente información
sobre el mismo, de forma obligatoria: Nombre, Apellidos, Email, Contraseña y Tipo de
usuario.
En el caso del campo Email debe ser un valor que no exista ya en la base de
datos, ya que éste se usa para el acceso a la herramienta. Por lo tanto, no pueden existir
en la aplicación dos usuarios con el mismo email. En caso de intentarlo, se mostrará un
mensaje de error.
Con el fin de evitar la equivocación del administrador/alta dirección al
introducir la contraseña para el nuevo usuario, ésta se pide dos veces. Si éste introduce
en ambos campos la misma contraseña, se creará el nuevo usuario; en el caso contrario,
se mostrará un mensaje de error.
En la Figura 43 se muestra la interfaz de creación del nuevo usuario.
69
Figura 43: Interfaz para crear un nuevo usuario.
Como podemos observar, el campo Empresa ya viene rellenado por defecto y
está deshabilitado. Esto se ha desarrollado así pensando en que, tanto el usuario
administrador como el usuario alta dirección, solamente puedan crear nuevos usuarios
en su empresa y no en otra.
Eliminar usuario
Una vez ya exista un usuario, es posible eliminarlo de la base de datos. La
interfaz para el borrado de un usuario de la aplicación se muestra en la Figura 44.
Figura 44: Interfaz para dar de baja a un usuario.
70
En esta iteración se realiza el diseño para la Gestión de Usuarios, teniendo en
cuenta el paradigma MVC. También cabe mencionar la utilización de los patrones de
diseño Singleton y Fachada (Larman, 1998). Ambos se consiguen con la utilización de
la clase Manager, la cual podemos observar en la siguiente figura. Con la utilización de
este último patrón de diseño mencionado conseguimos reducir la complejidad
minimizando las comunicaciones y dependencias entre clases, ya que las clases
controladoras no interactuarán directamente con las clases DAO implementadas en la
capa Modelo. En la Figura 45 se observa el diagrama de clases de la Gestión de
Usuarios.
Figura 45: Diagrama de clases Gestión de Usuarios.
A continuación, en la Figura 46 se muestra un diagrama de secuencia para el
caso de uso de Eliminar usuario. Por simplicidad, ya que sería muy similar, se ha
omitido el diagrama para la creación del nuevo usuario. El diagrama de la Figura 46
representa el escenario principal que lleva a cabo tanto el Administrador como la Alta
Dirección para dar de baja a un usuario de la herramienta desarrollada. Como
precondición (no mostrado en el diagrama), el usuario anteriormente ha debido
autenticarse.
Figura 46: Diagrama de secuencia Eliminar Usuario.
A continuación, en la Figura 47 se muestra un extracto del método
implementado en el controlador para el borrado del usuario.
71
Figura 47: Código implementado en el controlador para dar de baja a un usuario.
Como ha podido observarse en la Figura 45, el controlador y la capa Modelo
interactúan a través de la clase Manager. En este caso, el código implementado en dicha
clase para interactuar con la clase DAO correspondiente se muestra en la Figura 48.
Figura 48: Código implementado en el Manager para dar de baja a un usuario.
Como se puede ver, desde el Manager se llama a la clase de la capa Modelo, que
será la que se encargue de interactuar con la base de datos para el borrado del usuario.
El método implementado para ello en esta clase, la cual se llama DAOUser se presenta
en la Figura 49.
Figura 49: Código implementado en la clase de la capa Modelo para dar de baja a
un usuario.
72
Tal como puede observarse en la Figura 49, lo que hace el método removeUser
es lo siguiente: primero se busca en la base de datos la colección Usuarios. Tras ello, se
busca el documento cuyo campo email sea el del usuario deseado y, si éste existe, se
devuelve true al Manager o false en caso contrario.
5.3.3. Iteración 4. Creación tanto de carteras de proyectos,
como de proyectos.
En esta iteración se ha desarrollado el módulo para la creación tanto de carteras
de proyecto, como de proyectos contenidos en éstas. Tal y como se ha mostrado en el
diagrama de casos de uso de la Figura 27, la Figura 28 y la Figura 29, la creación de
carteras de proyectos corresponde al rol Administrador y al rol Alta Dirección, y la
creación de proyectos al rol Administrador y al rol Gestor de Cartera de Proyectos. La
funcionalidad de estos roles con respecto a esta iteración podemos observarla en la
Figura 50, Figura 51 y Figura 52.
Figura 50: Casos de uso para la creación de carteras de proyectos y de proyectos
para el administrador.
Como se muestra en la Figura 50, el Administrador puede tanto crear nuevas
carteras de proyectos en la empresa y asignarlas al Gestor de cartera de proyectos
deseado, como crear nuevos proyectos y asignarlos a la cartera requerida y al Gestor de
proyecto que se desee.
73
Figura 51: Casos de uso para la creación de carteras de proyectos para la alta
dirección.
Como se presenta en la Figura 51, la Alta dirección puede crear nuevas carteras
de proyectos en su empresa y asignarlas al Gestor de cartera de proyectos deseado.
Figura 52: Casos de uso para la creación de proyectos para el gestor de cartera de
proyectos.
Tal y como puede observarse en la Figura 52, el Gestor de cartera de proyectos
puede crear nuevos proyectos en su cartera y asignarlos al Gestor de proyecto deseado.
Creación de carteras de proyectos
En este módulo se ha desarrollado la creación de carteras de proyectos en la
aplicación. La vista implementada para la creación de éstas será la misma tanto para el
Administrador como para la Alta Dirección. Cuando se quiera crear una nueva cartera
de proyectos, el usuario deberá indicar mediante un formulario la siguiente información,
de forma obligatoria: Nombre de la cartera, Prioridad, Presupuesto, Gestor de cartera,
Estado financiero, Estado de calendario, Estado de alineamiento, Estado de riesgos y
Objetivo estratégico de la cartera.
74
Los estados anteriormente mencionados estarán divididos en bueno, regular o
malo, debiendo el usuario seleccionar el valor que él considere para la cartera de cada
uno de ellos. En el campo prioridad, deberá seleccionar alta, normal o baja, según la
prioridad que tenga la nueva cartera.
Cabe destacar que no podrán crearse en la aplicación dos carteras de proyectos
que tengan el mismo nombre en la misma empresa. Si el usuario introduce un nombre
para la cartera de proyectos que ya existe, la herramienta mostrará un mensaje de error
por pantalla.
En la Figura 53 se muestra la interfaz de creación de nuevas carteras de
proyectos.
Figura 53: Interfaz para crear una nueva cartera de proyectos.
Como puede observarse en la Figura 53, el campo fecha de creación está
rellenado por defecto y deshabilitado. Esto se debe a que la aplicación muestra el día
actual en el que estamos cuando se crea la cartera, facilitando de este modo dicha
creación al usuario en cuestión.
75
En la Figura 54 se muestra el método implementado en la capa Modelo para la
inserción en la base de datos de una nueva cartera de proyectos.
Figura 54: Método en la clase de la capa Modelo para la inserción de nuevas
carteras de proyectos en la base de datos.
Como puede observarse en la Figura 54, lo que se hace es buscar en la base de
datos la colección Carteras e insertar un nuevo documento con la información de la
nueva cartera de proyectos.
Creación de proyectos
Para este caso, y a diferencia con respecto a la creación de carteras de proyectos,
la interfaz mostrada no será la misma para el Administrador como para el Gestor de
Cartera de Proyectos.
Como comentamos en la iteración 2, crearemos proyectos en la herramienta
utilizando la librería MPXJ para extraer toda la información posible de proyectos .xml
exportados de MS-Project. No obstante, esta librería no ha sido completada (Importing
EV fields with MPXJ return null values, 2017), de modo que no es posible la lectura de
algunos campos de los proyectos de MS-Project, como por ejemplo el Valor Planificado
(PV) o la Variación del cronograma (SV). Para solventar esta limitación, se ha
desarrollado un formulario posterior a la selección del archivo .xml deseado por parte
del usuario, indicando aquí valores esenciales que nos faltarían para realizar un óptimo
seguimiento de los proyectos, y por ende, de las carteras de proyectos.
76
Teniendo en cuenta lo anteriormente comentado, la interfaz para la creación de
un nuevo proyecto, tras haber seleccionado el archivo .xml deseado, se muestra en la
Figura 55 para el rol Administrador y en la figura 56 para el rol Gestor de Cartera de
Proyectos.
Figura 55: Interfaz para crear un nuevo proyecto para el rol Administrador.
77
Figura 56: Interfaz para crear un nuevo proyecto para el rol Gestor de Cartera de
Proyectos.
La diferencia entre las dos vistas es únicamente que el rol Administrador tendrá
que indicar la cartera de proyectos en la que estará contenido el nuevo proyecto, y el rol
Gestor de Cartera de Proyectos no.
Como puede observarse en la Figura 56, el usuario tendrá la opción de elegir el
método de gestión utilizado en su proyecto. Si éste elige Tradicional, se mostrarán los
campos relacionados con la introducción de información esencial para este tipo de
gestión, como puede observarse en la Figura 57. Por el contrario, si el usuario elige
Ágil, se mostrarán los campos referentes a la introducción de información para esta
gestión de proyectos (Figura 58).
78
Figura 57: Formulario para la creación de un nuevo proyecto siguiendo
metodología tradicional.
79
Figura 58: Formulario para la creación de un nuevo proyecto siguiendo
metodología ágil.
Cabe mencionar que no podrán crearse en la misma cartera de proyectos dos
proyectos con el mismo nombre. Si el usuario intenta crear un nuevo proyecto con un
nombre que ya existe en la cartera de proyectos que contendrá a éste, la aplicación
mostrará un error.
A continuación, en la Figura 59 se muestra el diagrama de clases que interactúa
tanto para la creación de carteras de proyectos como para la creación de proyectos.
80
Figura 59: Diagrama de clases creación de carteras de proyectos y de proyectos.
A continuación, en la Figura 60, se muestra el diagrama de secuencia que
representa los pasos que debe realizar el Gestor de cartera de proyectos para crear un
nuevo proyecto en su cartera. Por simplicidad, se ha omitido la acción de autenticación
por parte del usuario.
Figura 60: Diagrama de secuencia Creación nuevo proyecto por parte del Gestor
de cartera de proyectos.
5.3.4. Iteración 5. Vistas de la herramienta para el
seguimiento de carteras.
Esta iteración es de las más importantes, ya que se han desarrollado todas las
vistas de la aplicación, así como toda la carga de la información del usuario. Este
módulo aporta bastante valor a la herramienta desarrollada, ya que, puesto que
dependiendo del rol del usuario, se puede visualizar una información u otra, cuando éste
haga login y navegue por la herramienta, ésta será capaz de cargar todas las carteras de
proyectos o todos los proyectos que el usuario dirija.
Esta funcionalidad corresponde a los roles Alta Dirección (Figura 61), Gestor de
cartera de proyectos (Figura 62) y Gestor de proyecto (Figura 63). El administrador se
81
excluye ya que no tiene poderes para visualizar ni las carteras de proyectos de la
empresa ni los proyectos contenidos en éstas.
Figura 61: Casos de uso del usuario Gestor de cartera de proyectos para Vistas de
la herramienta para el seguimiento de carteras.
Como puede apreciarse en la Figura 59, la Alta dirección puede tanto visualizar
las carteras de proyectos que tenga su empresa, como los proyectos que estén
contenidos en éstas.
Figura 62: Casos de uso del usuario Gestor de cartera de proyectos para Vistas de
la herramienta para el seguimiento de carteras.
Como se presenta en la Figura 60, el Gestor de cartera de proyectos puede tanto
visualizar las carteras de proyectos que gestione, como los proyectos que estén
contenidos en estas carteras.
Figura 63: Casos de uso del usuario Gestor de proyecto para Vistas de la
herramienta para el seguimiento de carteras.
82
Como puede observarse en la Figura 63, el Gestor de proyecto únicamente
puede visualizar los proyectos que gestione.
A modo de ejemplo se presentan diversas vistas con la información que puede
visualizar el rol correspondiente, ya que si pusiéramos todas las interfaces para todos los
roles se haría demasiado extenso el capítulo:
En la Figura 64 puede visualizarse la información que verá el rol Gestor de
proyecto que gestione varios proyectos cuando haga login.
Figura 64: Interfaz mostrada al rol Gestor de proyecto cuando haga login y
gestione más de un proyecto.
En la Figura 65 se presenta la vista que el rol Alta Dirección o Gestor de cartera
de proyectos visualizará cuando éste seleccione una cartera de proyectos.
83
Figura 65: Interfaz mostrada al rol Alta Dirección/Gestor de cartera de proyectos
cuando seleccione una de sus carteras.
En la Figura 66 se muestra la información que verá el rol Alta dirección cuando
su empresa tenga una o más carteras de proyectos.
Figura 66: Vista mostrada al rol Alta Dirección cuando su empresa tenga una o
más carteras de proyectos.
84
En la Figura 67 se presenta la vista que el rol Gestor de proyecto visualizará
cuando seleccione alguno de los proyectos siguiendo metodología tradicional
que dirige (en concreto, la pestaña de Información general).
Figura 67: Interfaz mostrada al rol Gestor de proyecto (pestaña Información
general) cuando seleccione uno de sus proyectos siguiendo metodología tradicional.
Como hemos podido apreciar en la Figura 64, Figura 65 y Figura 66, se ha hecho
uso de la metáfora del semáforo (Gimeno, 2016) a la hora de indicar los estados
individuales de la cartera de proyectos y de los proyectos. Este aporte da un gran valor
visual a la herramienta.
A continuación, en la Figura 68 se muestra el diagrama de clases que interactúa
en la visualización de las vistas de la herramienta para el seguimiento de carteras.
85
Figura 68: Diagrama de clases para la visualización de las vistas de la herramienta
para el seguimiento de carteras.
A continuación, en la Figura 69 se presenta parte del código del jsp para mostrar
cada celda de la tabla de proyectos.
Figura 69: Parte del código del jsp que muestra cada celda de la tabla de
proyectos.
Como puede observarse en la Figura 69, esta visualización de las tablas es
gracias a una combinación de html y lenguaje de marcas JSTL.
5.3.5. Iteración 6. Representación gráfica de la información
de seguimiento de carteras.
En esta iteración se ha llevado a cabo el desarrollo de mecanismos de
visualización con la finalidad de dotar a la herramienta de mayor valor visual y facilitar
de esta manera la interpretación de la información mostrada por la misma. En concreto
se han introducido distintos tipos de gráficos en función de la información que se
deseaba mostrar. Para ello, se ha utilizado la librería Amcharts.
86
En nuestro caso se han utilizado diversos gráficos según el nivel en el que se
encuentre el usuario. Estos niveles, como ya comentamos en el capítulo 2, junto con los
gráficos que se utilizan en ellos, son los siguientes:
Nivel de alta dirección. Se han desarrollado tres gráficos, los cuales indican lo
siguiente: resumen del estado general de las carteras de proyectos, resumen del
presupuesto de las carteras y resumen del número de proyectos que contiene
cada cartera.
Nivel de gestión de carteras de proyectos. Al igual que en el caso anterior, se
han implementado tres gráficos, los cuales son: resumen del estado general de
los proyectos pertenecientes a la cartera, resumen del presupuesto de los
proyectos pertenecientes a la cartera y resumen del porcentaje completado de
cada proyecto de la cartera.
Nivel de gestión de proyectos. En este nivel se ha desarrollado un gráfico, el
cual indica el porcentaje completado de cada proyecto.
A continuación, en la Figura 70 y en la Figura 71 se presenta cómo queda la
interfaz del rol Alta dirección. Como podemos observar, éste ya puede visualizar
toda la información de sus carteras de proyectos, al igual que puede crear nuevas
carteras de proyectos, dar de alta y de baja a usuarios y también puede ver su perfil.
La herramienta, tras varias iteraciones completadas, va adquiriendo cada vez más
funcionalidad.
87
Figura 70: Interfaz nivel Alta Dirección tras introducir gráficos Amcharts.
Figura 71: Interfaz nivel Alta Dirección tras introducir gráficos Amcharts.
Del mismo modo, en la figura 72 puede apreciarse cómo ve el usuario con el rol
Gestor de cartera de proyectos la herramienta, tras hacer login. En el ejemplo de la
captura, la cartera de proyectos del usuario solamente contiene un proyecto.
88
Figura 72: Interfaz nivel Gestión de carteras de proyectos tras introducir gráficos
Amcharts.
Por su parte, la vista para el rol Gestor de proyecto para el proyecto que gestiona
es como la indicada en la Figura 73.
89
Figura 73: Interfaz nivel Gestión de proyectos tras introducir gráficos Amcharts.
La construcción de estos gráficos se realiza de la siguiente forma: en el
controlador creamos el objeto JSON para enviarlo al chart, cuya construcción se
realiza en el jsp correspondiente en un script de tipo JavaScript. La recogida del
JSON en el script y la posterior construcción del chart se muestran en la Figura 74,
poniendo como ejemplo el gráfico que representa un resumen del estado de los
proyectos en el nivel de gestión de carteras de proyectos.
90
Figura 74: Construcción del chart en el jsp correspondiente.
5.3.6. Iteración 7. Cambios de estado tanto de las carteras de
proyectos, como de los proyectos.
Esta iteración comprende el desarrollo referente a la gestión de cambios de
estado de las carteras y de los proyectos por parte del usuario. Tal y como se comentó
en el capítulo 2, esta gestión de cambios de estado corresponde al rol Alta dirección, al
rol Gestor de cartera de proyectos y al rol Gestor de proyecto. Los casos de uso para
cada uno de estos roles en referencia a esta iteración, pueden observarse en la Figura 75,
Figura 76 y Figura 77.
Figura 75: Casos de uso para cambios de estado del rol Alta dirección.
91
Tal y como puede observarse en la Figura 75, la Alta dirección puede tanto
cambiar el estado general de las carteras de proyectos como de los proyectos que estén
contenidos en éstas.
Figura 76: Casos de uso para cambios de estado del rol Gestor de cartera de
proyectos.
Como puede observarse en la Figura 76, el usuario con el rol Gestor de cartera
de proyectos puede cambiar el estado general de los proyectos que estén contenidos en
su cartera, así como también puede cambiar los estados individuales (financiero, de
calendario, de alineamiento y de riesgos) de sus carteras.
Figura 77: Casos de uso para cambios de estado del rol Gestor de proyecto.
Como se presenta en la Figura 77, el Gestor de proyecto únicamente puede
cambiar los estados individuales (financiero, de calendario, de alineamiento y de
riesgos) de los proyectos que gestione.
92
Para abordar de mejor manera esta iteración, la separaremos en dos módulos:
cambio de estado general de la cartera/proyecto y cambio de estados individuales de la
cartera/proyecto.
Cambio de estado general de la cartera/proyecto
Este módulo consiste en el desarrollo de actualizar el estado general de las
carteras y/o proyectos que gestione el usuario. El estado general tanto de las carteras
como de los proyectos puede tener uno de los siguientes valores: en progreso,
terminado/a, cancelado/a. El cambio de este estado general consiste en lo siguiente:
El rol alta dirección podrá actualizar el estado general tanto de sus carteras de
proyectos, como de los proyectos contenidos en éstas; siempre y cuando la
cartera o el proyecto que desee actualizar, se encuentre en progreso.
El rol gestor de cartera de proyectos podrá actualizar el estado general de
cualquier proyecto de cualquier cartera que éste gestione, siempre y cuando el
proyecto en cuestión se encuentre en progreso.
La interfaz desarrollada que verá el usuario cuando tenga la posibilidad de cambiar
el estado general de su cartera será la que se presenta en la Figura 78.
Figura 78: Interfaz para posibilitar el cambio del estado general de la cartera de
proyectos.
93
Por su parte, la interfaz desarrollada que visualizará el usuario cuando tenga la
posibilidad de actualizar el estado general del proyecto será la mostrada en la Figura 79.
Figura 79: Interfaz para posibilitar el cambio del estado general del proyecto.
Cambio de estados individuales de la cartera/proyecto
El desarrollo de este módulo permitirá al usuario actualizar los estados
individuales de su cartera/proyecto. Los estados individuales que poseen tanto las
carteras como los proyectos son los siguientes:
Estado financiero: situación económica en la que se encuentra la cartera o
proyecto en cuestión.
Estado de calendario: situación en la que se encuentra la cartera o el proyecto
con respecto a los períodos previstos de finalización.
Estado de alineamiento: situación de la cartera o del proyecto con respecto a la
planificación estratégica empresarial.
Estado de riesgos: situación en la que se encuentra la cartera o el proyecto con
respecto a riesgos.
Los valores que pueden tomar todos estos estados pueden ser Bueno, Regular o
Malo. Por ejemplo, que el estado de alineamiento tenga valor Bueno quiere decir que
está muy bien alineado con respecto a la planificación estratégica empresarial.
Cabe destacar que para la representación de todos estos estados se hace uso de la
metáfora del semáforo del siguiente modo:
94
Valor Bueno:
Valor Regular:
Valor Malo:
El cambio de estos estados individuales consiste en lo siguiente:
El usuario con el rol Gestor de cartera de proyectos puede actualizar los estados
individuales de las carteras de proyectos que dirija, siempre y cuando éstas se
encuentren en progreso.
El usuario con el rol Gestor de proyecto puede cambiar los estados individuales
de los proyectos en los que sea el gestor, siempre que éstos se encuentren en
progreso.
La interfaz que visualiza el Gestor de cartera de proyectos cuando le sea posible
actualizar los estados individuales de sus carteras es como la mostrada en la Figura 80.
Figura 80: Interfaz para posibilitar el cambio de los estados individuales de la
cartera de proyectos.
95
Cuando el usuario seleccione Actualizar estados, se abrirá una modal, en la que
podrá cambiar todos los estados, uno, o varios. Esto aparece representado con una
captura en la Figura 81.
Figura 81: Modal para indicar los nuevos estados individuales deseados de la
cartera de proyectos.
Por su parte, la interfaz que visualiza el Gestor de proyecto cuando tenga la
posibilidad de cambiar los estados individuales de sus proyectos, es como la mostrada
en la Figura 82.
Figura 82: Interfaz para posibilitar el cambio de los estados individuales del
proyecto.
96
Del mismo modo que anteriormente, si el usuario selecciona Actualizar estados,
se abrirá una modal muy similar a la anterior en la que se podrán indicar los nuevos
estados individuales deseados para el proyecto, según se requiera.
A continuación se muestra el diagrama de secuencia que representa los pasos
que debe realizar el Gestor de proyecto para actualizar los estados individuales de su
proyecto (Figura 83). Por simplicidad, se ha omitido la acción de autenticación por
parte del usuario.
Figura 83: Diagrama de secuencia actualizar estados individuales proyecto.
A continuación, en la Figura 84 se muestra el diagrama de clases que interactúa
en la implementación de los cambios de estado tanto general como individuales para las
carteras de proyectos y para los proyectos.
Figura 84: Diagrama de clases para los cambios de estado general/individuales de
la cartera/proyecto.
En la Figura 85 se presenta el código implementado en la capa Modelo para
actualizar los estados individuales de la cartera de proyectos.
97
Figura 85: Código en la capa Modelo para el cambio de los estados individuales en
la cartera de proyectos.
5.3.7. Iteración 8. Actualización de valores de la Gestión del
Valor Ganado del proyecto.
En esta iteración se ha desarrollado la funcionalidad de poder ofrecer al usuario
con el rol Gestor de proyecto la actualización de la fecha de estado de los proyectos que
gestione, así como de los valores de la Gestión del Valor Ganado en dicha fecha de
estado.
Como hemos comentado, esta funcionalidad es propia únicamente del rol Gestor
de proyecto, como se indica en la Figura 86.
Figura 86: Casos de uso actualizar valores Gestión del Valor Ganado del proyecto.
Para que este usuario pueda llevar a cabo esta funcionalidad, se ha creado un
botón en la vista del proyecto en el apartado Gestión del Valor Ganado Tradicional
(Figura 87) o Gestión del Valor Ganado Ágil (Figura 88) (según método de gestión del
proyecto en cuestión), el cual si se selecciona, la herramienta abre una modal (Figura
89).
98
Figura 87: Botón creado para la actualización de valores para la Gestión del Valor
Ganado en proyecto siguiendo metodología tradicional.
Figura 88: Botón creado para la actualización de valores para la Gestión del Valor
Ganado en proyecto siguiendo metodología ágil.
99
Figura 89: Modal que permite la actualización de valores para la Gestión del Valor
Ganado en proyectos siguiendo metodología tradicional.
Como podemos observar en la Figura 89, la aplicación permite al usuario
actualizar estos valores mediante dos formas: Forma manual y Forma automática. Cabe
mencionar que la herramienta ofrecerá estas dos opciones de actualización de los
valores de la Gestión del Valor Ganado tanto si el proyecto sigue metodología
tradicional, como si sigue metodología ágil.
Si seleccionamos Forma manual, se desplegará un pequeño formulario en el que
el usuario tendrá que introducir los siguientes datos, todos ellos de forma obligatoria:
nueva fecha de estado deseada, Valor planificado en esta nueva fecha (PV), Valor
ganado (EV) y Coste actual (AC). Este formulario se presenta en la Figura 90.
Figura 90: Formulario que permite la actualización de valores para la Gestión del
Valor Ganado de Forma manual en proyectos que siguen metodología tradicional.
100
En cambio, si seleccionamos actualizar estos valores de Forma automática,
tendremos que seleccionar el archivo .xml del cual deseamos obtener la nueva fecha de
estado para nuestro proyecto (Figura 91).
Figura 91: Selección de actualización de valores para la Gestión del Valor Ganado
de Forma automática para proyectos siguiendo metodología tradicional.
Tras indicar el usuario el archivo deseado, se desplegará un pequeño formulario
para la introducción del nuevo Valor planificado (PV) y la nueva Variación del
cronograma (SV) en la nueva fecha de estado que se recuperará del archivo
seleccionado, ya que estos dos valores la librería MPXJ que realiza la lectura de
archivos exportados de MS-Project no es capaz de recuperar (ver apartado 5.3.3 del
presente documento, sección Creación de proyectos). Este formulario se presenta en la
Figura 92.
101
Figura 92: Formulario en selección de actualización de valores para la Gestión del
Valor Ganado de Forma automática para proyectos siguiendo metodología
tradicional.
En el caso de proyectos que siguen metodología ágil, los datos que tendrá que
introducir el usuario en el formulario si selecciona actualizar los valores de la Gestión
del Valor Ganado de forma manual son, todos ellos de forma obligatoria: nueva fecha
de estado deseada, Puntos historia planificados, Puntos historia completados, Valor
Ganado (EV) y Coste actual (AC).Este formulario se presenta en la Figura 93.
Figura 93: Formulario que permite la actualización de valores para la Gestión del
Valor Ganado de Forma manual en proyectos que siguen metodología ágil.
102
En el caso de que el usuario desee actualizar los valores de forma automática,
tras haber seleccionado el archivo deseado, se desplegará un pequeño formulario para la
introducción, de forma obligatoria, de los nuevos valores de Puntos historia planificados
y Puntos historia completados. Este formulario se presenta en la Figura 94.
Figura 94: Formulario en selección de actualización de valores para la Gestión del
Valor Ganado de Forma automática para proyectos siguiendo metodología ágil.
Tras haber actualizado los valores de la Gestión del Valor Ganado con éxito, la
herramienta nos muestra una gráfica con todas las fechas de estado registradas en el
proyecto, indicando, en el caso de que el proyecto siga metodología tradicional, el Valor
planificado (PV), Valor ganado (EV) y Costo actual (AC) en las fechas de estado en
cuestión (Figura 95). Para el caso de que el proyecto siga metodología ágil, esta gráfica
mostrará los valores de los Puntos historia planificados y los Puntos historia
completados. Esta gráfica se ha implementado gracias a la librería Amcharts comentada
en el apartado 5.3.5 del presente documento.
103
Figura 95: Gráfica de la Gestión del Valor Ganado.
5.3.8. Iteración 9. Descarga del informe con la información
del proyecto deseado.
En esta iteración se ha desarrollado poder ofrecer al usuario la descarga de un
archivo con toda la información relativa al proyecto deseado. Este archivo será un PDF,
cuyo nombre tendrá el siguiente formato:
Proyecto_nombre del proyecto a descargar.pdf
Esta funcionalidad es común a los roles Alta dirección, Gestor de cartera de
proyectos y Gestor de proyecto, como se indica en la Figura 96.
Figura 96: Casos de uso descarga de la información del proyecto.
104
Para hacer posible esta funcionalidad se ha creado un botón en la vista de
proyecto, iniciándose automáticamente la descarga de este archivo PDF si el usuario lo
selecciona. Esta vista, con la inclusión de este nuevo botón, se presenta en la Figura 97.
Figura 97: Nuevo botón para descargar la información del proyecto deseado en
formato PDF.
Del mismo modo que en las iteraciones anteriores, a continuación, en la Figura
98 se muestra el diagrama de clases que interactúa en la implementación de la descarga
de información del proyecto deseado.
105
Figura 98: Diagrama de clases de la descarga de información del proyecto deseado.
Como puede observarse en la Figura 98, en esta iteración no interactúa la capa
Modelo ya que no hace falta la utilización de la base de datos.
Para la implementación en el controlador de la descarga de la información se ha
hecho uso de la librería iText (iText, 2017). Ésta es una librería Open Source para crear
y manipular archivos PDF, RTF y HTML en JAVA.
En la Figura 99 se muestra la parte de código más relevante del controlador para
la descarga del archivo PDF.
Figura 99: Parte de código más relevante del controlador para la descarga del
archivo PDF.
106
5.3.9. Iteración 10. Envío de correo electrónico al usuario.
En esta décima iteración se ha desarrollado la funcionalidad del envío de correo
electrónico a los usuarios. Este envío de correo lo realizará la herramienta de manera
automática, lo que facilitará la comunicación y la colaboración entre los distintos roles
de la misma. Los correos electrónicos los enviará la aplicación a los usuarios cuando
ocurran hechos relevantes que deberían conocer. Como ya se presentó en el capítulo 2,
los hechos por los que la aplicación realizará estos envíos son los siguientes:
Creación y eliminación de un usuario del sistema.
Cambio de contraseña.
Creación de nueva cartera de proyectos.
Creación de nuevo proyecto.
Cambio del estado global de la cartera de proyectos.
Cambio del estado global del proyecto.
A continuación van a presentarse algunos ejemplos de correos electrónicos enviados
a usuarios.
El email que se enviará al usuario en el momento en el que se le dé de alta en la
herramienta será como el mostrado en la Figura 100.
Figura 100: Correo electrónico enviado al usuario cuando ha sido dado de alta en
la herramienta.
Por su parte, el email enviado al usuario con el rol Gestor de cartera de proyectos
en el momento en el que se cambie el estado general de alguna de las carteras de
proyectos de su empresa, será como el que se presenta en la Figura 101.
Figura 101: Correo electrónico enviado al Gestor de cartera de proyectos cuando
cambia el estado general de alguna de sus carteras.
107
El correo electrónico enviado al usuario con el rol Gestor de proyecto cuando un
gestor de cartera de proyectos le asigne un nuevo proyecto, será como el mostrado en la
Figura 102.
Figura 102: Correo electrónico enviado al Gestor de proyecto cuando se le asigne
un nuevo proyecto.
La implementación del envío de estos correos electrónicos se ha conseguido gracias
a la librería JavaMail (JavaMail, 2017). Esta librería permite el envío de correos
electrónicos directamente desde la aplicación JAVA.
En la Figura 103 se presenta el código implementado para el envío del correo
electrónico en el caso de que un usuario cambie su contraseña.
Figura 103: Código implementado para el envío del correo electrónico cuando
un usuario cambie su contraseña.
5.4. Fase de transición.
En esta última fase del ciclo de vida de OpenUP, el objetivo principal es el
entregable de una herramienta totalmente operativa, cuyas funcionalidades satisfagan
todos los requisitos extraídos en la fase de inicio junto a la documentación pertinente.
Así mismo, también se entregará un manual de usuario de la aplicación, el cual estará
disponible en el anexo del presente TFG. De este modo, se dan los primeros pasos para
la transición de la herramienta a la hora de desplegarla en un entorno real.
108
5.4.1. Iteración 11. Pruebas de integración y documentación.
En esta última iteración se han realizado pruebas de integración de toda la
aplicación y se han corregido errores detectados. Se ha creado una serie de casos
prácticos para realizar estas pruebas. En el apartado 5.4.2 de este mismo capítulo se
muestra uno de los casos prácticos completos que se ha usado para comprobar el
correcto funcionamiento de la herramienta desarrollada en el presente TFG.
Así mismo, como parte final de la iteración y del desarrollo de la aplicación, se
ha elaborado un manual de usuario, donde se describe el uso de las funcionalidades de
la herramienta desarrollada. Este documento está incluido en el presente trabajo en los
anexos.
5.4.2. Caso práctico con SPT2.
En este apartado se describe un caso práctico que se ha utilizado como prueba de
la aplicación SPT2. Para el caso práctico se ha simulado lo que podría ser un caso real,
desde la creación de un nuevo usuario por parte del administrador, hasta el seguimiento
de un proyecto por parte del Gestor de proyecto.
Para comenzar el caso práctico, supongamos una empresa llamada ESI cuya
planificación estratégica es ser en el año 2020 una de las cinco empresas líderes a nivel
nacional en el desarrollo de software. Para ello, los gerentes de la misma, tras varias
reuniones, han acordado la creación de una cartera de proyectos. Los datos para la
misma son los siguientes:
Nombre: Cartera_Proyectos_Líderes2020
Prioridad: Alta.
Presupuesto: 183.000 €.
Gestor de cartera: Manuel Ruiz.
Objetivo estratégico de la cartera: Conseguir en 2020 entrar en el top 3 del
ránking de empresas líderes a nivel nacional de desarrollo de software.
Tras ello, Pablo Ramírez, el cual pertenece a la alta dirección de la empresa y aún no
tiene acceso a la herramienta, le indica al administrador de la misma que le dé de alta en
la aplicación, proporcionándole sus datos.
A continuación, el administrador de la herramienta en la empresa ESI se dispone a
dar de alta a Pablo Ramírez (Figura 104) como usuario con el rol Alta Dirección,
indicando mediante un correo electrónico la herramienta la creación de este usuario
tanto al administrador de la misma (Figura 105) como a Pablo Ramírez (Figura 106).
109
Figura 104: Formulario para dar de alta a Pablo Ramírez.
Figura 105: Correo electrónico enviado al administrador de SPT2 informando del
nuevo alta.
Figura 106: Correo electrónico enviado a Pablo Ramírez informando que ha sido
dado de alta en la herramienta.
A continuación, Pablo Ramírez hace login en la aplicación para cerciorarse que
ha sido de alta con éxito. Lo primero que hará será cambiar su contraseña, puesto que la
que le asignó el administrador es muy poco segura. Para ello, se dirige a la sección mi
cuenta de la herramienta e indica la nueva contraseña deseada (Figura 107).
110
Figura 107: Formulario para cambiar la contraseña de Pablo Ramírez.
Tras ver en la aplicación un mensaje de éxito en el cambio de su contraseña
(Figura 108), Pablo Ramírez da de alta al que será el gestor de la nueva cartera de
proyectos que se creará en la empresa. Tras ello, se dispone a crear la nueva cartera de
proyectos, con toda la información que se acordó en la anterior reunión con los demás
gerentes de la empresa (Figura 109).
Figura 108: Mensaje informando del éxito durante el cambio de contraseña.
111
Figura 109: Formulario para la creación de la nueva cartera de proyectos.
Tras la creación de esta nueva cartera de proyectos, la herramienta envía un
correo electrónico informando de lo sucedido tanto a todos los usuarios con el rol Alta
Dirección de la empresa (Figura 110), como al propio gestor de la nueva cartera de
proyectos, Manuel Ruiz (Figura 111).
Figura 110: Correo electrónico enviado a la alta dirección tras crear una nueva
cartera de proyectos.
112
Figura 111: Correo electrónico enviado al gestor de cartera tras asignarle una
nueva cartera de proyectos.
Gracias al correo electrónico que ha recibido Manuel Ruiz, éste ha sido
informado de la nueva responsabilidad que tiene en la empresa. Para ver todos los datos
sobre la nueva cartera, Manuel hace login en la aplicación (Figura 112).
Figura 112: Vista de la cartera de proyectos que dirige el usuario Manuel Ruiz.
Después de esto y tras haber visualizado el presupuesto con el que cuenta la
cartera de proyectos y la planificación estratégica que pretende alcanzarse, Manuel Ruiz
comienza la planificación que llevará la cartera de proyectos. Tras este análisis, decide
que creará dos proyectos en su nueva cartera, siguiendo uno de ellos metodología
tradicional y otro metodología ágil (Figura 113, Figura 114 y Figura 115), de los cuales
ya tiene información en su ordenador portátil en archivos con formato .xml exportados
de MS-Project. Estos proyectos los asignará a dos compañeros con los que ya ha
trabajado y conoce, teniendo ambos el rol Gestor de proyecto: Samuel Pérez y Raquel
Santos.
113
Figura 113: Formulario para la creación de un nuevo proyecto, asignándoselo a
Samuel Pérez.
114
Figura 114: Vista de la cartera de proyectos tras la creación de los 2 nuevos
proyectos en la misma.
Figura 115: Vista de la cartera de proyectos tras la creación de los 2 nuevos
proyectos en la misma.
115
Estos dos compañeros se percatan de la asignación de estos nuevos proyectos
gracias al correo electrónico que les llega de manera automática de la herramienta. Tras
ello, ambos hacen login en la misma para ver todos los datos sobre el nuevo proyecto
que les han encomendado (Figura 116 y Figura 117).
Figura 116: Vista del proyecto asignado a Samuel Pérez (pestaña “Información
general”).
116
Figura 117: Vista del proyecto asignado a Raquel Santos (pestaña “Gestión del
valor ganado”).
Tras ver toda la información sobre el mismo, Raquel Santos decide cambiar el
estado de calendario que tiene su proyecto. Actualmente, éste tiene el estado Bueno,
pero Raquel no considera que esto sea así y lo actualiza a Regular (Figura 118).
Figura 118: Vista del proyecto asignado a Raquel Santos (pestaña “Estado del
proyecto”) tras actualizar el estado de calendario.
Tras el paso de unos días, Samuel Pérez decide actualizar la fecha de estado de
su proyecto, haciéndolo de forma automática. Tras ello, la gráfica de la Gestión del
Valor Ganado que visualiza se presenta en la Figura 119.
117
Figura 119: Gráfica de la Gestión del Valor Ganado del proyecto de Samuel Pérez.
Después de dos semanas, el gestor de la cartera de proyectos Manuel Ruiz se
percata de que el estudio de la planificación que realizó de la cartera fue errónea, y que
el presupuesto destinado al proyecto dirigido por Samuel Pérez no es correcto, lo que le
obliga a tener que cancelar el mismo (Figura 120 y Figura 121).
Figura 120: Vista de la cartera de proyectos tras cancelar el proyecto de Samuel
Pérez.
118
Figura 121: Vista de la cartera de proyectos tras cancelar el proyecto de Samuel
Pérez.
De manera automática se informa a Samuel Pérez de este hecho mediante un
correo electrónico (Figura 117).
Figura 122: Correo electrónico enviado al gestor de proyecto tras la cancelación de
su proyecto.
Durante semanas los usuarios con el rol Alta Dirección de la empresa realizan el
seguimiento de esta cartera de proyectos, estando muy satisfechos con el trabajo que
está realizando Manuel Ruiz. Tras el paso de un año, se les informa a los gerentes de la
empresa que han alcanzado de manera exitosa la planificación estratégica por la que se
creó la cartera de proyectos, y lo han hecho con anterioridad al tiempo planificado: la
empresa se encuentra entre las cinco empresas líderes a nivel nacional en el desarrollo
de software. Por ello, Pablo Ramírez actualiza el estado de la cartera de proyectos en la
herramienta a Terminada (Figura 123 y Figura 124), actualizándose por ende el estado
del único proyecto que quedaba en la cartera a este mismo nuevo estado (Figura 124).
De la actualización del estado de la cartera es informado el gestor de la misma, Manuel
119
Ruiz, mediante un correo electrónico automático enviado desde la aplicación (Figura
125).
Figura 123: Vista de la cartera de proyectos tras actualizar su estado a Terminada.
Figura 124: Vista de la cartera de proyectos tras actualizar su estado a Terminada.
120
Figura 125: Correo electrónico enviado al gestor de cartera proyecto informando
de la actualización de la misma a Terminada.
121
CAPÍTULO 6
CONCLUSIONES Y PROPUESTAS
En este capítulo se analiza la consecución o no de los objetivos principales
marcados al inicio del proyecto, tal y como se especificaron en el capítulo 2. Además, se
incluyen propuestas de trabajo futuro para mejorar la herramienta SPT2 y se proporciona
la opinión personal del autor tras la realización del presente TFG.
6.1. Análisis de los objetivos cumplidos.
El objetivo principal del presente TFG era desarrollar una herramienta para dar
soporte a una parte muy importante de la gestión de carteras de proyectos como es el
seguimiento de las mismas, así como de los proyectos contenidos en éstas. Como ya se
comentó en el capítulo 2, esta herramienta debía estar enfocada a proyectos software, ya
que nos proporcionaría información específica de la gestión de proyectos software como
es la relativa a la Gestión del Valor Ganado tanto para proyectos siguiendo metodología
tradicional como para proyectos siguiendo metodología ágil. Así mismo, esta
herramienta facilitaría el acceso y la interoperabilidad entre distintos roles.
Podemos decir que este objetivo ha sido totalmente satisfecho con el diseño e
implementación de la herramienta SPT2 que ha sido desarrollada durante el presente
TFG, tras la consecución de los objetivos parciales presentados en la Tabla 5.
122
ID Objetivo Objetivo ¿Conseguido?
Obj1 Captura de información de proyectos exportados
de MS-Project
Obj2 Representación de indicadores relevantes de las
carteras de proyectos
Obj3 Completa gestión de usuarios
Obj4 Jerarquizar la visibilidad de información mediante
niveles
Obj5 Descarga de informes de proyectos
Obj6 Correcto seguimiento de la Gestión del Valor
Ganado
Obj7 Facilitar la comunicación y colaboración de los
distintos roles
Tabla 5: Consecución de objetivos parciales propuestos para el presente TFG.
A su vez, también podemos decir que se han conseguido alcanzar con éxito
todos los objetivos docentes propuestos para el desarrollo de la herramienta (capítulo 2)
tal y como se presenta en la Tabla 6.
123
ID Objetivo Objetivo ¿Conseguido?
ObjD1
Conocer los fundamentos de la gestión de carteras
de proyectos, así como la importancia de una
correcta gestión de éstas en una organización.
ObjD2
Alcanzar un grado de conocimiento esencial sobre
la gestión de proyectos y las herramientas que dan
soporte a ello.
ObjD3 Adquirir aptitudes para el desarrollo web y
tecnologías que faciliten el mismo.
ObjD4 Aplicar conocimientos de Sistemas Gestores de
Bases de Datos.
ObjD5
Implementar y mantener herramientas, de acuerdo
a las actividades de análisis y diseño realizadas
con anterioridad.
ObjD6
Aprender a usar librerías que faciliten la
visualización de datos en desarrollo web, como
por ejemplo Amcharts.
ObjD7
Aprender a usar librerías que permitan realizar
importaciones de proyectos exportados de MS-
Project, como por ejemplo mediante la librería
MPXJ.
Tabla 6: Consecución de objetivos docentes propuestos para el presente TFG.
6.2. Propuestas futuras.
En esta sección se proponen distintas mejoras y ampliaciones de la herramienta
SPT2 a abordar en el futuro:
Ampliación y mejora del seguimiento de carteras de proyectos según la
metodología de desarrollo utilizada. Puesto que la aplicación desarrollada
muestra vistas diferentes para los proyectos según la metodología utilizada
durante el desarrollo de éstos, esta funcionalidad deberá mejorarse con la
introducción de nuevos gráficos y nuevos valores que permitan un mejor
seguimiento de las carteras de proyectos y de los proyectos contenidos en éstas.
Esto implicará introducir nuevos atributos en las colecciones de la base de datos,
motivo por el cual se ha utilizado base de datos no relacional durante el
desarrollo de la herramienta.
Mejora de la gestión de estados individuales tanto de las carteras como de
los proyectos. Actualmente, la herramienta da soporte a una serie de indicadores
de estados individuales tanto en las carteras como en los proyectos, los cuales
son: estado financiero, estado de calendario, estado de alineamiento y estado de
riegos. Éstos solo pueden tomar tres valores: bien, regular o mal. En el futuro
124
podría ampliarse esta funcionalidad desarrollando más valores para estos estados
y mejorando la gestión de los mismos, como por ejemplo indicando el por qué
un estado tiene el valor indicado, puesto que ahora mismo éstos los actualiza el
gestor basándose en sus conocimientos, sin indicar el porqué de la actualización
a la herramienta.
Internacionalización de la herramienta. La aplicación deberá dar la
posibilidad al usuario de elegir el idioma en el cual visualizará la herramienta
SPT2.
6.3. Opinión del autor.
El desarrollo de este TFG me ha permitido comprender y profundizar en algunos
conceptos estudiados durante la carrera, como son los conceptos de gestión de proyectos
o las herramientas utilizadas para ello. Además de entender la importancia que tiene
para las organizaciones una correcta gestión de carteras, pudiendo suponer si esto no es
así el fracaso en el objetivo de algo tan importante como es alcanzar la planificación
estratégica.
Por otro lado, este desarrollo me ha permitido obtener una serie de competencias
técnicas que durante la carrera no se ven en profundidad, como es el desarrollo web y el
uso de nuevas tecnologías que hasta este momento desconocía. Todo esto me ha
ayudado a comprender que, a pesar de todos los conceptos y todos los conocimientos
que nos son enseñados durante la carrera, todo lo aprendido hasta ahora solamente ha
sido la base de cara al futuro, ya que todavía me queda mucho por aprender y descubrir,
siendo éste un motivo suficiente de motivación para continuar con mi aprendizaje en el
mundo de la Informática.
Para finalizar, quiero destacar lo importante a nivel personal que es para mí la
finalización de este TFG, ya que supone poner fin a una de las etapas más importantes y
bonitas de mi vida, significando esto un punto y seguido en mi formación académica.
Mi objetivo en este momento es esforzarme día a día para seguir creciendo tanto
personal como profesionalmente.
Ciudad Real, a 21 de Noviembre de 2017
Fdo.: Roberto Jesús González-Carrato Pozo
125
CAPÍTULO 7
BIBLIOGRAFÍA
AJAX. (2017). AJAX. Available: https://www.w3schools.com/xml/ajax_intro.asp
Álvarez, M. (2014). Qué es MVC. Available: https://desarrolloweb.com/articulos/que-
es-mvc.html
Amcharts. (2017). Sitio Web Oficial de Amcharts. Available:
https://www.amcharts.com/
Antura Projects. (2017). Sitio Web Oficial de Antura Projects. Available:
http://www.antura.com/
Apache Tomcat. (2017). Sitio Web Oficial Apache Tomcat. Available:
http://tomcat.apache.org/
Balsamiq-Mockups. (2017). Sitio Web Oficial Balsamiq Mockups. Available:
https://balsamiq.com/products/mockups/
Bases de datos NoSQL. (2017). Bases de datos NoSQL: Guía definitiva. Available:
https://blog.pandorafms.org/es/bases-de-datos-nosql/
Bitbucket. (2017). Sitio Web Oficial de Bitbucket. Available: https://bitbucket.org
Blog de Gestión de Proyectos (2017). ¿Qué es el Valor Ganado o EVM? Available:
https://www.sinnaps.com/blog-gestion-proyectos/valor-ganado-evm-2
Booch, G., Rumbaugh, J., y Jacobson I. (2012). El Lenguaje Unificado de Modelado.
Guía del usuario (2ª Edición). Pearson. ISBN: 9788483222706
Bootstrap. (2017). Sitio Web Oficial de Bootstrap. Available: http://getbootstrap.com
CSS3. (2017). Sitio Web Oficial de CSS. Available:
http://www.w3schools.com/css/css3_intro.asp
Eclipse. (2017). Sitio Web Oficial Eclipse. Available: https://www.eclipse.org/ide/
F. Eclipse. Metodología OpenUP. Available: http://epf.eclipse.org/wikis/openup/
Gemio, Nicolás. (2017). Patrón MVC: Available:
https://nicolasgemio.files.wordpress.com/2016/02/mvc-introduction2.jpg?w=800
Gimeno A., S., (2016). El uso de colores en las interfaces. Available:
http://www.torresburriel.com/weblog/2016/12/02/el-uso-de-colores-en-las-interfaces/
126
HTML5. (2017). Sitio Web Oficial de HTML. Available: http://www.w3.org/TR/html5/
Importing EV fields with MPXJ return null values. (2017). Sitio Web Stack Overflow.
Available: https://stackoverflow.com/questions/24204459/importing-ev-fields-with-
mpxj-returns-null-values
iText. (2017). Sitio Web Oficial iText PDF library. Available: https://itextpdf.com/
Java. (2017). Sitio Web Oficial de Java. Available: https://http://www.java.com/es/
JavaMail. (2017). Sitio Web Oficial JavaMail. Available:
http://www.oracle.com/technetwork/java/javamail/javamail145-1904579.html
Jordan, A., (2017). The Role of the Portfolio Manager. Available:
https://www.projectmanagement.com/articles/410219/The-Role-of-the-Portfolio-
Manager
JQuery. (2017). Sitio Web Oficial de JQuery. Available: https://jquery.com
JSON. (2017). Sitio Web Oficial de JSON. Available: https://www.json.org/json-es.html
JSTL. (2017). JSP – Standard Tag Library (JSTL). Available:
https://www.tutorialspoint.com/jsp/jsp_standard_tag_library.htm
Larman, C., (1998). Applying UML and Patterns. Second Edition.
Lee Merkhofer Consulting (2017). Project Portfolio Management Tools.
Maven. (2017). Sitio Web Oficial Maven. Available: https://maven.apache.org/
Medellín Cabrera, E., (2016). Gestión de cartera de proyectos tecnológicos, México:
Premio Nacional de Tecnología.
Micro Focus Project and Portfolio Management. (2017). Sitio Web Oficial de Micro
Focus Project and Portfolio Management. Available:
https://software.microfocus.com/en-us/home
Microsoft Project & Portfolio Management. (2017). Sitio Web Oficial de Microsoft
Project & Portfolio Management. Available: https://www.microsoft.com/en-
us/download/details.aspx?id=41549
Microsoft Word. (2017). Sitio Web Oficial de Microsoft Word. Available:
https://products.office.com/es-es/word
MongoDB. (2017). Sitio Web Oficial MongoDB. Available:
https://www.mongodb.com/es
MPXJ. (2017). Sitio Web Oficial MPXJ library. Available: http://www.mpxj.org/
127
Neil, T., (2010). 12 Standard Screen Patterns. Available:
http://designingwebinterfaces.com/designing-web-interfaces-12-screen-patterns
Oracle’s Primavera P6 Enterprise Project Portolio Management. (2017). Sitio Web
Oficial de Oracle’s Primavera P6 Enterprise Project Portfolio Management. Available:
https://www.oracle.com/applications/primavera/index.html
PMI (2013). A Guide to the Project Management Body of Knowledge (PMBOK®
Guide). Fifth Edition. Project Management Institute (PMI).
PMI (2014). Challenges & Best Practices of Managing Government Projects &
Programs. Project Management Institute (PMI).
PMI (2015). Collaborative Project Procurement Arrangements. Project Management
Institute (PMI).
PMI (2016). Governance of Portfolios, Programs, and Projects: A Practice Guide.
Project Management Institute (PMI).
PMI (2017). A Guide to the Project Management Body of Knowledge (PMBOK®
Guide). Sixth Edition. Project Management Institute (PMI).
Project Management Institute. (2017). Agile Practice Guide. Project Management
Institute (PMI). ISBN: 978-1-62825-199-9
Reifer, D.J. (1997). The Planning Hierarchy. En software Management, 5th edition.
IEEE Computer Society, 1997, pp. 168-170.
S. A. M. González and D. A. S. Espinosa, "Definición de un Modelo de Gestión de
Proyectos Basado en PMBOK Y OpenUP para Desarrollo de Software," Grado
Maestría en Gerencia de Sistemas, ESPE, 2014.
SAP Portfolio and Project Management. (2017). Sitio Web Oficial de SAP Portfolio and
Project Management. Available: https://www.sap.com/products/project-portfolio-
management.html
Spring. (2017). Sitio Web Oficial Spring. Available: https://spring.io/
Spring Framework. (2017). Wikedia, La enciclopedia libre. Available:
https://es.wikipedia.org/wiki/Spring_Framework
Trello. (2017). Sitio Web Oficial Trello. Available: http://www.trello.com
Unanet Project ERP Software. (2017). Sitio Web Oficial de Unanet Project ERP
Software. Available: http://www.unanet.com/
UNICOM Focal Point. (2017). Sitio Web Oficial de UNICOM Focal Point. Available:
https://teamblue.unicomsi.com/products/focal-point/
Vizcaíno, A., García, F., & Piattini, M. (2014). Desarrollo Global de Software. RA-MA.
128
VP-UML. (2017). Sitio Web Oficial Visual Paradigm for UML. Available:
http://www.visual-paradigm.com
129
ANEXO A
MANUAL DE USUARIO
Durante este anexo, se presenta el manual de usuario para el manejo de la
herramienta SPT2. El manual estará dividido para los diferentes roles existentes en la
herramienta: Administrador, Alta dirección, Gestor de cartera de proyectos y Gestor de
proyecto.
1. Manual para el rol Administrador.
En primer lugar, para poder acceder a la aplicación es necesario autenticarse,
para ello basta con introducir su email y contraseña (Figura 126).
Puesto que la herramienta es de uso interno para las organizaciones, no existe la
funcionalidad de registrarse en la misma. Si alguien que no está dado de alta en ésta
desea estarlo, el usuario con el rol Administrador o Alta dirección de la organización a
la que pertenezca el usuario en cuestión deberá darlo de alta.
Figura 126: Interfaz login.
130
Una vez el administrador haya hecho login correctamente, la aplicación mostrará
la pantalla principal (Figura 127), donde pueden observarse las siguientes partes:
En la Zona A aparece una barra de navegación con el nombre de la herramienta
y con dos botones: Mi cuenta y Cerrar sesión.
En la Zona B se presenta información del usuario logueado.
La Zona C está destinada a la gestión de carteras y de proyectos.
En la Zona D se muestran dos botones para la gestión de usuarios.
Figura 127: Pantalla principal Administrador.
A continuación, van a detallarse las acciones que el Administrador puede
realizar, divididas por funcionalidad.
Visualización del perfil del usuario, cambio de contraseña y
cerrar sesión.
Estas funcionalidades son comunes a todos los roles, pudiendo todos ellos
realizarlas.
En la barra de navegación que aparece en la Zona A de la Figura 127 se presentan
tres elementos: nombre de la herramienta a modo informativo, Mi cuenta (con el fin de
que el usuario visualice su perfil, pudiendo cambiar la contraseña si así lo desea) y
Cerrar sesión. A continuación se analiza cada una de estas funcionalidades.
131
o Visualización del perfil del usuario y cambio de contraseña.
Si el usuario selecciona Mi cuenta, aparecerá una vista con todos sus datos
(Figura 128): Nombre, Apellidos, Email, Empresa y Rol del mismo. Justo debajo,
aparecerá un pequeño formulario para que el usuario, en caso de que así lo desee, pueda
modificar su contraseña. En este formulario tendrá que introducir, de forma obligatoria,
su contraseña actual y la nueva contraseña deseada por partida doble.
Figura 128: Apartado Mi cuenta.
Como puede observarse en la Figura 128, los campos Nombre, Apellidos, Email,
Empresa y Rol ya vienen rellenados por defecto con la información del usuario, estando
deshabilitados para que éste no pueda interactuar con ellos.
Cabe destacar que en el formulario para la modificación de la contraseña, si el
usuario introduce de manera errónea su contraseña actual, se mostrará un mensaje de
error por pantalla. También se mostrará este mensaje si el usuario introduce contraseñas
diferentes en el campo Nueva contraseña y en el campo Repita la nueva contraseña.
Es importante destacar que, cuando el usuario modifique su contraseña de
manera exitosa, la herramienta le enviará un correo electrónico informando de ello.
o Cerrar sesión.
Por otro lado, si el usuario selecciona Cerrar sesión, la aplicación mostrará la
pantalla para hacer login (Figura 126).
132
Gestión de carteras de proyectos y de proyectos.
El Administrador puede acceder a estas funcionalidades a través de los botones
situados en la Zona C de la Figura 127: Crear nueva cartera de proyectos y Añadir
nuevo proyecto. A continuación éstas se presentan por separado.
o Creación de carteras de proyectos.
Esta es una funcionalidad que comparten el Administrador y el usuario con el rol
Alta dirección.
Si el usuario selecciona el botón Crear nueva cartera de proyectos, aparecerá
una vista para la introducción de toda la información relacionada con esta
funcionalidad. En concreto, el usuario deberá indicar la siguiente información, de forma
obligatoria: Nombre de la cartera de proyectos, Prioridad, Presupuesto, Gestor de
cartera, Estado financiero, Estado de calendario, Estado de alineamiento, Estado de
riesgos y Objetivo estratégico de la cartera.
Los estados anteriormente mencionados estarán divididos en bueno, regular o
malo, debiendo el usuario seleccionar el valor que él considere para la cartera de cada
uno de ellos. En el campo prioridad, deberá seleccionar alta, normal o baja, según la
prioridad que tenga la nueva cartera.
Cabe destacar que no podrán crearse dos carteras de proyectos que tengan el
mismo nombre en la misma empresa. Si el usuario introduce un nombre para la cartera
de proyectos que ya exista, la herramienta mostrará un mensaje de error por pantalla.
En la Figura 129 se muestra la interfaz para la creación de nuevas carteras de
proyectos.
133
Figura 129: Interfaz para la creación de nuevas carteras de proyectos.
Como puede observarse en la Figura 129, el campo fecha de creación está
rellenado por defecto y deshabilitado. Esto se debe a que la aplicación muestra el día
actual en el que estamos cuando se crea la cartera, facilitando de este modo dicha
creación al usuario.
Cuando el usuario seleccione el botón Crear nueva cartera de proyectos tras
haber introducido toda la información del formulario de la Figura 129, se mostrará un
mensaje de éxito si se creó la nueva cartera o un mensaje de error, en caso contrario.
Cabe mencionar que, cuando se cree una cartera de proyectos de manera exitosa,
la aplicación enviará un correo electrónico de manera automática informando a todos
los usuarios involucrados en la misma sobre este hecho.
o Creación de proyectos.
Esta funcionalidad es compartida por el rol Administrador y por el rol Gestor de
cartera de proyectos.
Si el usuario selecciona el botón Añadir nuevo proyecto, la aplicación mostrará
la interfaz que se presenta en la Figura 130.
134
Figura 130: Interfaz para la creación de nuevos proyectos.
Como puede observarse en la Figura 130, el usuario debe seleccionar el archivo
del que desea importar toda su información. Cabe destacar que este archivo debe tener
extensión .xml. Tras haber seleccionado el archivo deseado, debe seleccionarse el botón
Seleccionar proyecto. Seguidamente, se mostrará un formulario para la introducción de
forma obligatoria de información adicional para el nuevo proyecto (Figura 131), la cual
es: Nombre del proyecto, Tipo de proyecto, Método de gestión utilizado, Cartera a la
que se desea que pertenezca, Gestor de proyecto, Presupuesto, Estado financiero, Estado
de calendario, Estado de alineamiento, Estado de riesgos y Objetivo estratégico del
proyecto. Si el usuario elige Método de gestión tradicional, como se presenta en la
Figura 131, se mostrarán nuevos campos relacionados con este tipo de gestión: Valor
planificado (PV) y Variación del cronograma (SV). En cambio, si el usuario selecciona
Método de gestión ágil, tendrán que introducirse los valores referentes a dos nuevos
campos: Puntos historia planificados y Puntos historia completados.
135
Figura 131: Formulario para la introducción de información adicional para el
nuevo proyecto.
Es importante destacar que la única diferencia con respecto al formulario que
debe rellenar el usuario con el rol Gestor de cartera de proyectos cuando desee crear un
nuevo proyecto en su cartera, es que éste no visualizará el campo Cartera a la que
pertenecerá el proyecto, ya que automáticamente se creará en la cartera en la que se
encuentre el usuario.
Cabe mencionar que no podrán crearse en la misma cartera de proyectos dos
proyectos con el mismo nombre. Si el usuario intenta crear un nuevo proyecto con un
nombre que ya existe en la cartera de proyectos que contendrá a éste, la aplicación
mostrará un mensaje de error. En caso contrario, mostrará un mensaje de éxito.
En el momento en que se cree un proyecto de forma exitosa en cualquier cartera
de proyectos, la aplicación enviará un correo electrónico de manera automática
informando de lo sucedido a todos los usuarios involucrados.
136
Gestión de usuarios.
Los botones para que el Administrador pueda acceder a esta funcionalidad se
presentan en la Zona D de la Figura 127: Dar de alta a un usuario y Dar de baja a un
usuario. A continuación se presentan por separado.
o Crear usuario.
Cuando el usuario seleccione el botón Dar de alta a un usuario (Figura 127), la
herramienta mostrará una vista en la que se deberá introducir, de forma obligatoria, la
siguiente información sobre el mismo: Nombre, Apellidos, Email, Contraseña y Rol del
usuario.
En el caso del campo Email debe ser un valor que no exista ya en la base de
datos, ya que éste se usa para el acceso a la herramienta. Por lo tanto, no pueden existir
en la aplicación dos usuarios con el mismo email. En caso de intentarlo, la aplicación
mostrará un mensaje de error.
Con el fin de evitar la equivocación al introducir la nueva contraseña para el
nuevo usuario, ésta se pide dos veces. Si se introduce en ambos campos la misma
contraseña, se creará el nuevo usuario; en caso contrario, se mostrará un mensaje de
error.
Figura 132: Formulario para la creación de un nuevo usuario.
137
Como puede observarse en la Figura 132, el campo Empresa ya viene rellenado
por defecto y está deshabilitado, ya que el administrador solamente podrá crear nuevos
usuarios en su empresa y no en otra.
Es importante destacar que, cuando se cree un nuevo usuario, la aplicación
enviará un correo electrónico automáticamente tanto al usuario dado de alta como al
usuario que ha llevado a cabo la acción, informando de lo sucedido.
o Eliminar usuario.
Una vez ya exista un usuario, es posible eliminarlo de la base de datos. Si el
usuario selecciona el botón Dar de baja a un usuario, la herramienta mostrará la interfaz
que se presenta en la Figura 133. En ella, el administrador solamente tendrá que buscar
al usuario que desee borrar y seleccionar el botón Eliminar usuario.
Figura 133: Interfaz para la eliminación de usuarios de la aplicación.
En caso de que la eliminación del usuario sea exitosa, la aplicación mostrará un
mensaje de éxito; en caso contrario, mostrará un mensaje de error.
Cuando se elimine un usuario de la base de datos de manera exitosa, la
herramienta enviará un correo electrónico al usuario que ha llevado a cabo la acción
informando de lo sucedido.
138
2. Manual para el rol Alta dirección.
En primer lugar, para acceder a la herramienta SPT2 es necesario que el usuario se
haya autenticado antes. Tras ello, se mostrará la pantalla principal para la vista del rol
Alta dirección (Figura 134 Y Figura 135), donde pueden observarse las siguientes
partes:
En la Zona A aparece una barra de navegación con el nombre de la herramienta
y con dos botones: Mi cuenta y Cerrar sesión.
La Zona B está dedicada a diferentes gráficos representativos de información
relevante de las carteras de proyectos que posee la empresa para la que trabaja el
usuario. La información que proporcionan estos gráficos es la siguiente: estado
de las carteras de proyectos, presupuesto de las carteras y número de proyectos
por cartera.
En la Zona C se muestran las carteras de proyectos que tiene la organización,
divididas por su estado general: en progreso, terminada o cancelada.
En la Zona D puede visualizarse un botón destinado a la creación de nuevas
carteras de proyectos en la organización.
La Zona E está dedicada para la gestión de usuarios. Si se selecciona el botón
Administrar usuarios, aparecen justo debajo dos botones para dicha gestión: Dar
de alta a un usuario y Dar de baja a un usuario.
Figura 134: Vista del rol Alta dirección tras hacer login.
139
Figura 135: Vista del rol Alta dirección tras hacer login.
A continuación, se presentan las acciones que el usuario con el rol Alta dirección
puede realizar, divididas por funcionalidad.
Visualización del perfil del usuario, cambio de contraseña y
cerrar sesión.
Esta funcionalidad está ubicada en la Zona A de la Figura 134.
(Véase el apartado ubicado en este mismo anexo Manual para el rol Administrador
-> Visualización del perfil del usuario, cambio de contraseña y cerrar sesión).
Crear nueva cartera de proyectos.
Esta funcionalidad está situada en la Zona D de la Figura 135.
(Véase el apartado ubicado en este mismo anexo Manual para el rol Administrador
-> Gestión de carteras de proyectos y de proyectos -> Creación de carteras de
proyectos).
140
Administrar usuarios.
Esta funcionalidad está localizada en la Zona E de la Figura 135.
(Véase el apartado ubicado en este mismo anexo Manual para el rol Administrador
-> Gestión de carteras de proyectos y de proyectos -> Gestión de usuarios).
Visualización de carteras de proyectos y de proyectos.
A esta funcionalidad se accede desde la Zona C de la Figura 135. En esta zona se
encuentran las tablas con el listado de todas las carteras de proyectos que tiene la
empresa, divididas por su estado general, el cual puede ser en progreso, terminada o
cancelada. La información de las carteras de proyectos que presentan estas tablas es la
siguiente: Nombre de la cartera, Estado general de la cartera, Gestor de la cartera,
Prioridad, Presupuesto, Fecha de creación, Número de proyectos que contiene la cartera,
Estado financiero, Estado de calendario, Estado de alineamiento y Estado de riesgos.
Como puede apreciarse en la Figura 135, cada cartera tiene cinco estados: un
estado general y cuatro estados individuales. Estos estados individuales pueden tomar
los valores bien, mal o regular, y son los siguientes:
Estado financiero: situación económica en la que se encuentra la cartera de
proyectos.
Estado de calendario: situación en la que se encuentra la cartera con respecto a
los períodos previstos de finalización.
Estado de alineamiento: situación de la cartera de proyectos con respecto a la
planificación estratégica empresarial.
Estado de riesgos: situación en la que se encuentra la cartera o el proyecto con
respecto a riesgos.
Para acceder a visualizar toda la información de la cartera de proyectos, el usuario
debe seleccionar el botón Ver cartera de la cartera deseada, ubicado a la derecha de la
fila de cada cartera en la Zona C de la Figura 135. Tras seleccionar este botón, el
usuario visualiza la vista de la cartera de proyectos, con toda su información (Figura
136 y Figura 137).
141
Figura 136: Vista de cartera de proyectos para el usuario Alta dirección.
Figura 137: Vista de cartera de proyectos para el usuario Alta dirección.
142
Al igual que ocurre con las carteras de proyectos, los proyectos se muestran
divididos por su estado general en tablas (Figura 137). Para que el usuario Alta
dirección visualice la información de los proyectos contenidos en las carteras que la
empresa en la que trabaja tiene, solamente tiene que seleccionar el botón Ver proyecto
(Figura 137). Tras seleccionar este botón, se muestra la vista de proyecto, la cual está
dividida pestañas con el fin de organizar de forma óptima la información. Estas pestañas
son: Información general (Figura 138), Estado del proyecto (Figura 139) y Gestión del
valor ganado (Figura 140).
Figura 138: Pestaña Información general de la vista de proyecto para el usuario
Alta dirección.
143
Figura 139: Pestaña Estado del proyecto de la vista de proyecto para el usuario
Alta dirección.
Figura 140: Pestaña Gestión del valor ganado de la vista de proyecto para el
usuario Alta dirección.
Cambio del estado general de la cartera/proyecto.
Esta funcionalidad consiste en la actualización del estado general de las carteras de
proyectos y/o de los proyectos. El usuario con el rol Alta dirección podrá actualizar el
estado general tanto de sus carteras de proyectos, como de los proyectos contenidos en
éstas; siempre y cuando la cartera o el proyecto que desee actualizar, se encuentre en
progreso.
144
La interfaz que visualiza el usuario cuando tenga la posibilidad de cambiar el
estado general de su cartera de proyectos es como la mostrada en la Figura 136. Cuando
este usuario tenga la posibilidad de cambiar el estado general de un proyecto contenido
en una de sus carteras de proyectos, la interfaz que se mostrará será como la de la Figura
139.
Tras la actualización del estado general de la cartera de proyectos y/ o de los
proyectos, la aplicación enviará un correo electrónico a todos los usuarios involucrados
en la cartera o en el proyecto informando de lo sucedido. Cabe destacar que si una
cartera se actualiza al estado terminada o cancelada y ésta aún contiene proyectos que
cuyo estado general es en progreso, el estado general de estos proyectos se actualizará
automáticamente al mismo estado general al que se actualizó la cartera de proyectos a la
que pertenece.
Descargar informe del proyecto deseado.
Esta funcionalidad es común a los usuarios Alta dirección, Gestor de cartera de
proyectos y Gestor de proyecto.
Consiste en lo siguiente: el usuario tiene la posibilidad de descargar un informe
con toda la información del proyecto deseado. Este informe será un archivo PDF, cuyo
nombre tiene el siguiente formato:
Proyecto_nombre del proyecto a descargar.pdf
La vista que hace posible ofrecer al usuario la posibilidad de esta descarga es la
de proyecto, es decir, la mostrada en la Figura 138, 139 y 140. Si el usuario selecciona
el botón Descargar información del proyecto, la descarga se iniciará automáticamente.
3. Manual para el rol Gestor de cartera de proyectos.
En primer lugar, para acceder a la aplicación es necesario que el usuario se haya
autenticado con anterioridad. Tras ello, se mostrará la pantalla principal para la vista del
rol Gestor de cartera de proyectos. Esta vista puede variar, dependiendo de si el usuario
en cuestión gestiona una cartera de proyectos o más de una.
En la Figura 141 se presenta la vista para el rol Gestor de cartera de proyectos
cuando el usuario gestiona varias carteras de proyectos.
145
Figura 141: Vista rol Gestor de cartera de proyectos tras hacer login gestionando
varias carteras.
Por su parte, en la Figura 142 y en la Figura 143 se muestra la vista para este rol
cuando gestiona únicamente una cartera de proyectos.
Figura 142: Vista cartera del rol Gestor de cartera de proyectos
146
Figura 143: Vista cartera del rol Gestor de cartera de proyectos.
Tal y como se observa en las Figuras 141, 142 y 143, en la vista del Gestor de
cartera de proyectos se observan diferentes partes:
En la Zona A aparece una barra de navegación con el nombre de la herramienta
y con dos botones: Mi cuenta y Cerrar Sesión.
La Zona B está dedicada a representación de la información, tanto visualmente
mediante gráficos como mediante texto. La información que se proporciona
mediante texto es la siguiente: nombre de la cartera de proyectos, gestor de la
misma y estado general de ésta. La información que se proporciona mediante
gráficos es la siguiente: estado de los proyectos, presupuesto de los proyectos y
porcentaje completado de cada proyecto.
En la Zona C se muestra, al igual que anteriormente, información sobre la
cartera de proyectos mediante texto, la cual es: objetivo estratégico de la cartera
de proyectos, presupuesto de la misma y fecha de creación.
La Zona D está dedicada a la visualización de los estados individuales de la
cartera de proyectos, siendo éstos: estado financiero, estado de calendario,
estado de alineamiento y estado de riesgos. Así mismo, se observa un botón, el
cual se utiliza para actualizar los estados individuales de la cartera de proyectos.
En la Zona E se muestra el botón reservado para la creación de nuevos proyectos
en la cartera de proyectos.
La Zona F está destinada a la visualización de los proyectos que contiene la
cartera, divididos éstos por el estado general en el que se encuentren, pudiendo
ser en progreso, terminado o cancelado.
En la Zona G puede observarse el listado de carteras de proyectos que gestiona
el usuario, pudiendo seleccionar éste la que desee en el botón Ver cartera. Tras
147
la selección de este botón, la aplicación mostrará toda la información de la
cartera en cuestión, siendo esta vista como la de la Figura 142 y la Figura 143.
A continuación, se presentan las acciones que el usuario con el rol Gestor de cartera
de proyectos puede realizar, divididas por funcionalidad.
Visualización del perfil del usuario, cambio de contraseña y
cerrar sesión.
Esta funcionalidad está ubicada en la Zona A tanto de la Figura 141 como de la
Figura 142.
(Véase el apartado ubicado en este mismo anexo Manual para el rol Administrador
-> Visualización del perfil del usuario, cambio de contraseña y cerrar sesión).
Crear nuevo proyecto.
Esta funcionalidad está situada en la Zona E de la Figura 143.
(Véase el apartado ubicado en este mismo anexo Manual para el rol Administrador
-> Gestión de carteras de proyectos y de proyectos -> Creación de proyectos).
Visualización de los proyectos.
Esta funcionalidad consiste en la visualización de los proyectos contenidos en las
carteras de proyectos que gestiona el usuario. Como podemos observar en la Zona F de
la Figura 143, los proyectos contenidos en la cartera se muestran organizados según el
estado general en el que se encuentran. Para que el usuario con el rol Gestor de cartera
de proyectos visualice la información del proyecto que desee, solamente tiene que
seleccionar el botón Ver proyecto (Figura 143). Tras seleccionar este botón, se muestra
la vista de proyecto, la cual está dividida en pestañas con el fin de organizar de forma
óptima la información. Estas pestañas son: Información general (Figura 138), Estado
del proyecto (Figura 139) y Gestión del valor ganado tradicional (Figura 140) o
Gestión del valor ganado ágil (según metodología de gestión del proyecto en cuestión).
148
Cambio del estado general de los proyectos contenidos en la
cartera.
Esta funcionalidad es compartida con el usuario con el rol Alta dirección.
Consiste en la actualización del estado general de los proyectos contenidos en las
carteras que gestione el usuario. Esta actualización puede llevarse a cabo siempre y
cuando el proyecto en cuestión se encuentre en progreso.
La interfaz que visualiza el usuario cuando tenga la posibilidad de cambiar el estado
general de cualquier proyecto contenido en una de sus carteras será como la mostrada en
la Figura 139.
Tras la actualización del estado general del proyecto, la aplicación enviará un correo
electrónico a todos los usuarios involucrados en el mismo informando de este hecho.
Cambio de los estados individuales de la cartera de
proyectos.
Esta funcionalidad consiste en ofrecer al usuario la posibilidad de actualizar los
estados individuales de la cartera de proyectos que gestione. Estos estados individuales
son los siguientes:
Estado financiero: situación económica en la que se encuentra la cartera o
proyecto en cuestión.
Estado de calendario: situación en la que se encuentra la cartera o el proyecto
con respecto a los períodos previstos de finalización.
Estado de alineamiento: situación de la cartera o del proyecto con respecto a la
planificación estratégica empresarial.
Estado de riesgos: situación en la que se encuentra la cartera o el proyecto con
respecto a riesgos.
Los valores que pueden tomar todos estos estados pueden ser Bueno, Regular o
Malo. Por ejemplo, que el estado de alineamiento tenga valor Bueno quiere decir que
está muy bien alineado con respecto a la planificación estratégica empresarial.
149
Cabe destacar que para la representación de todos estos estados se hace uso de la
metáfora del semáforo del siguiente modo:
Valor Bueno:
Valor Regular:
Valor Malo:
El cambio de estos estados individuales consiste en lo siguiente: el usuario con el rol
Gestor de cartera de proyectos tiene la posibilidad de actualizar estos estados de las
carteras que dirija, siempre y cuando éstas se encuentren en progreso.
La interfaz que visualiza el Gestor de cartera de proyectos cuando le sea posible
actualizar los estados individuales de sus carteras es como la mostrada en la Figura 143.
Cuando el usuario seleccione Actualizar estados, se abrirá una vista, en la que podrá
cambiar todos los estados, uno, o varios. Esto aparece representado con una captura en
la Figura 144.
Figura 144: Vista para actualizar estados individuales de la cartera de proyectos.
Si la actualización de los estados se lleva a cabo de manera exitosa, la herramienta
mostrará un mensaje de éxito; en caso contrario, mostrará un mensaje de error.
150
Descargar informe del proyecto deseado.
(Véase el apartado ubicado en este mismo anexo Manual para el rol Alta Dirección
-> Descargar informe del proyecto deseado).
4. Manual para el rol Gestor de proyecto.
En primer lugar, para acceder a la herramienta es necesario que el usuario se haya
autenticado con anterioridad. Tras ello, se mostrará la pantalla principal para la vista del
rol Gestor de proyecto. Esta vista puede variar, dependiendo de si el usuario en cuestión
gestiona un proyecto o más de uno.
En la Figura 145 se presenta la vista para el rol Gestor de proyecto cuando el
usuario gestiona varios proyectos.
Figura 145: Vista rol Gestor de proyecto tras hacer login gestionando varios
proyectos.
151
En las Figuras 146, 147 y 148 se presenta la vista para este rol cuando el usuario
gestiona únicamente un proyecto. Es importante destacar que esta vista está dividida en
pestañas con el fin de organizar de forma óptima la información. Estas pestañas son:
Información general (Figura 146), Estado del proyecto (Figura 147) y Gestión del valor
ganado tradicional (Figura 148) o Gestión del valor ganado ágil (según metodología de
gestión del proyecto en cuestión).
Figura 146: Vista proyecto para el rol Gestor de proyecto.
152
Figura 147: Vista proyecto para el rol Gestor de proyecto.
Figura 148: Vista proyecto para el rol Gestor de proyecto.
153
Tal y como se observa en las Figuras 145, 146, 147 Y 148, en la vista del
Gestor de proyecto se observan diferentes partes:
En la Zona A aparece una barra de navegación con el nombre de la herramienta
y con dos botones: Mi cuenta y Cerrar Sesión.
La Zona B está reservada para la representación de la información general del
proyecto, tanto textualmente como en forma de gráfico. La información
representada en forma de texto es la siguiente: nombre del proyecto, gestor del
mismo, cartera de proyectos a la que pertenece, objetivo estratégico del
proyecto, tipo de éste, fecha de inicio, fecha de fin prevista y presupuesto del
proyecto. La información mostrada con un gráfico se refiere al porcentaje
completado del proyecto.
En la Zona C puede visualizarse la información relativa a los estados del
proyecto, tanto al estado general en que se encuentra el mismo como a los
estados individuales (financiero, de calendario, de alineamiento y de riesgos).
En la Zona D se observa un botón, el cual permite al usuario actualizar los
estados individuales del proyecto.
La Zona E está reservada para la representación en forma de texto de la
información de la Gestión del Valor Ganado. Esta información es la siguiente:
Valor planificado (PV), Valor ganado (EV), Costo real (AC), Variación de
costos (CV), Variación del cronograma (SV), CPI, SPI y una recomendación,
basándose la herramienta en todos estos valores comentados anteriormente.
En la Zona F se encuentra un botón, el cual nos permite al usuario actualizar los
valores de la Gestión del Valor Ganado.
La Zona G está dedicada a la representación visual de la Gestión del Valor
Ganado mediante un gráfico.
La Zona H está reservada para visualización del listado de proyectos que
gestiona el usuario, divididos por el estado general en el que se encuentren éstos.
A continuación, se presentan las acciones que el usuario con el rol Gestor de
proyecto puede realizar, divididas por funcionalidad.
Visualización del perfil del usuario, cambio de contraseña y
cerrar sesión.
Esta funcionalidad está ubicada en la Zona A de las Figuras 145, 146, 147 y 148.
(Véase el apartado ubicado en este mismo anexo Manual para el rol Administrador
-> Visualización del perfil del usuario, cambio de contraseña y cerrar sesión).
154
Cambio de los estados individuales del proyecto.
Esta funcionalidad consiste en ofrecer al usuario la posibilidad de actualizar los
estados individuales de los proyectos que gestione. Estos estados individuales son los
siguientes:
Estado financiero: situación económica en la que se encuentra la cartera o
proyecto en cuestión.
Estado de calendario: situación en la que se encuentra la cartera o el proyecto
con respecto a los períodos previstos de finalización.
Estado de alineamiento: situación de la cartera o del proyecto con respecto a la
planificación estratégica empresarial.
Estado de riesgos: situación en la que se encuentra la cartera o el proyecto con
respecto a riesgos.
Los valores que pueden tomar todos estos estados pueden ser Bueno, Regular o
Malo. Por ejemplo, que el estado de alineamiento tenga valor Bueno quiere decir que
está muy bien alineado con respecto a la planificación estratégica empresarial.
Cabe destacar que para la representación de todos estos estados se hace uso de la
metáfora del semáforo del siguiente modo:
Valor Bueno:
Valor Regular:
Valor Malo:
El cambio de estos estados individuales consiste en lo siguiente: el usuario con el rol
Gestor de proyecto tiene la posibilidad de actualizar estos estados de los proyectos que
dirija, siempre y cuando éstos se encuentren en progreso.
La interfaz que visualiza el Gestor de proyecto cuando le sea posible actualizar los
estados individuales de sus proyectos es como la mostrada en la Figura 147.
Cuando el usuario seleccione Actualizar estados, se abrirá una interfaz, en la que
podrá cambiar todos los estados, uno, o varios. Esto aparece representado con una
captura en la Figura 149.
155
Figura 149: Interfaz para la actualización de los estados individuales del proyecto.
Si la actualización de los estados se lleva a cabo de manera exitosa, la herramienta
mostrará un mensaje de éxito; en caso contrario, mostrará un mensaje de error.
Actualización de valores de la Gestión del Valor Ganado.
Esta funcionalidad consiste en la posibilidad que tiene el usuario de actualizar la
fecha de estado relativa a la Gestión del Valor Ganado de su proyecto, ya sea
gestionado de manera tradicional o ágil, así como los indicadores relativos a esta
Gestión. Para llevar a cabo esta acción, el usuario con el rol Gestor de proyecto
selecciona el botón Actualizar valores que se presenta en la Figura 148. Tras la
selección de éste, nos aparece una vista como la mostrada en la Figura 150.
156
Figura 150: Vista para actualizar los valores de Gestión del valor ganado del
proyecto.
Como puede observarse en la Figura 150, la aplicación permite al usuario
actualizar estos valores mediante dos formas: Forma manual y Forma automática. La
herramienta ofrece estas dos opciones de actualización de los valores de la Gestión del
Valor Ganado tanto si el proyecto sigue metodología tradicional, como si sigue
metodología ágil.
Si se selecciona Forma manual, se desplegará un pequeño formulario en el que el
usuario tendrá que introducir los siguientes datos, todos ellos de forma obligatoria:
nueva fecha de estado deseada, Valor planificado en esta nueva fecha (PV), Valor
ganado (EV) y Costo actual (AC). Este formulario se presenta en la Figura 151.
Figura 151: Formulario para actualizar los valores de Gestión del valor ganado del
proyecto tras seleccionar Forma manual.
157
En cambio, si el usuario selecciona actualizar estos valores de Forma
automática, éste tendrá que seleccionar el archivo .xml del cual desea obtener la nueva
fecha de estado para el proyecto en cuestión (Figura 152).
Figura 152: Vista para actualizar los valores de Gestión del valor ganado del
proyecto tras seleccionar Forma automática.
Tras indicar el usuario el archivo deseado, se desplegará un pequeño formulario
para la introducción del nuevo Valor planificado (PV) y la nueva Variación del
cronograma (SV) en la nueva fecha de estado que se recuperará del archivo
seleccionado. Este formulario se presenta en la Figura 153.
Figura 153: Formulario para actualizar los valores de Gestión del valor ganado del
proyecto siguiendo metodología tradicional tras haber seleccionado Forma
automática y tras seleccionar el proyecto deseado.
158
En el caso de proyectos que siguen metodología ágil, los datos que tendrá que
introducir el usuario en el formulario si selecciona actualizar los valores de la Gestión
del Valor Ganado de forma manual son los que se muestran en la Figura 154.
Figura 154: Vista para actualizar los valores de Gestión del valor ganado del
proyecto siguiendo metodología ágil tras haber seleccionado Forma manual.
En el caso de desear actualizar los valores de forma automática, tras haber
seleccionado el archivo deseado, se desplegará un pequeño formulario para la
introducción de la información mostrada en la Figura 155.
Figura 155: Vista para actualizar los valores de Gestión del valor ganado del
proyecto siguiendo metodología ágil tras haber seleccionado Forma automática y
tras seleccionar el proyecto deseado.
159
Tras haber actualizado los valores de la Gestión del Valor Ganado de forma
exitosa, la herramienta muestra una gráfica con todas las fechas de estado registradas en
el proyecto. Para el caso en el que el proyecto siga metodología tradicional, la gráfica
indicará el Valor planificado (PV), Valor ganado (EV) y Costo actual (AC) en las
fechas de estado en cuestión (Figura 156). Para el caso en el que siga metodología ágil,
la gráfica mostrará los valores de los Puntos historia planificados y los Puntos historia
completados.
Figura 156: Gráfica de la Gestión del valor ganado.
Descargar informe del proyecto deseado.
(Véase el apartado ubicado en este mismo anexo Manual para el rol Alta Dirección
-> Descargar informe del proyecto deseado).
160
161
ANEXO B
ACRÓNIMOS
TFG. Trabajo Fin de Grado.
SPT2. Software Portfolios Tracking Tool.
MS-Project. Microsoft Project.
EVM. Earned Value Management.
ERP. Enterprise Resource Planning.
EPPM. Enterprise Project Portfolio Management.
UML. Unified Modeling Language.
IDE. Integrated Development Environment.
OpenUP. Open Unified Process.
JDT. Java Development Toolkit.
MVC. Modelo – Vista – Controlador.
MVC. Model – View – Controller.
POM. Project Object Model.
HTML. HyperText Markup Language.
EPPM. Enterprise Project Portfolio Management.
XML. eXtensible Markup Language.
CSS. Cascading Style Sheets.
W3C. World Wide Web Consortium.
JSON. JavaScript Object Notation.
J2EE. Java 2 Enterprise Edition.
JSP. JavaServer Pages.
AJAX. Asynchronous JavaScript And XML.
JSTL. JavaServer Pages Standard Tag Library.
162
PV. Planned Value.
PV. Valor Planificado.
EV. Earned Value.
EV. Valor Ganado.
AC. Actual Cost.
AC. Costo Actual.
SV. Schedule Variance.
SV. Variación del cronograma.
CV. Cost Variance.
CV. Variación de costos.
CPI. Cost Performance Index.
CPI. Índice del Rendimiento del Coste.
SPI. Schedule Performance Index.
SPI. Índice del Rendimiento del Cronograma.
TCPI. To Complete Performance Index.
TCPI. Índice de Desempeño para Completar.
PDF. Portable Document Format.