gestión del proceso software - biblioteca de la ... · gestión del proceso software, trabajo fin...
TRANSCRIPT
Eneko Valladares Reyes
Gestión del proceso software
Arturo Jaime Elizondo
Facultad de Ciencias, Estudios Agroalimentarios e Informática
Grado en Ingeniería Informática
2012-2013
Título
Autor/es
Director/es
Facultad
Titulación
Departamento
TRABAJO FIN DE GRADO
Curso Académico
© El autor© Universidad de La Rioja, Servicio de Publicaciones, 2013
publicaciones.unirioja.esE-mail: [email protected]
Gestión del proceso software, trabajo fin de gradode Eneko Valladares Reyes, dirigido por Arturo Jaime Elizondo (publicado por la
Universidad de La Rioja), se difunde bajo una LicenciaCreative Commons Reconocimiento-NoComercial-SinObraDerivada 3.0 Unported.
Permisos que vayan más allá de lo cubierto por esta licencia pueden solicitarse a los titulares del copyright.
Trabajo Fin de Grado Página 1
UNIVERSIDAD DE LA RIOJA
Facultad de Ciencias, Estudios Agroalimentarios e Informática
TRABAJO FIN DE GRADO
Grado en Ingeniería Informática
Gestión del proceso software
Alumno: Eneko Valladares Reyes
Director: Arturo Jaime Elizondo
Logroño, (Junio, 2013)
Trabajo Fin de Grado Página 2
Índice 1. Documento de Objetivos del Proyecto ..................................................................................... 6
1.1 Objetivo ............................................................................................................................... 6
1.2 Comunicaciones .................................................................................................................. 6
1.3 Alcance del producto .......................................................................................................... 6
1.4 Metodología ........................................................................................................................ 7
1.5 Tecnologías a utilizar ........................................................................................................... 7
1.6 Identificación de riesgos y planes de acción ....................................................................... 7
1.6.1 Riesgos posibles ........................................................................................................... 7
1.6.2 Plan de actuación ......................................................................................................... 8
1.6.3 Precauciones a adoptar ................................................................................................ 9
1.7 Entregables .......................................................................................................................... 9
1.8 Horario laboral .................................................................................................................. 10
1.8.1 Plan semanal de trabajo ............................................................................................. 10
1.8.2 Estructura de Descomposición del Trabajo ................................................................ 11
1.8.3 Estimación de tiempos y cronograma ........................................................................ 12
2. Análisis (Iteración 1) ................................................................................................................ 14
2.1 Conceptos preliminares .................................................................................................... 14
2.2 Requisitos funcionales ....................................................................................................... 17
2.2.1 Proyectos gestionados en la aplicación ..................................................................... 17
2.2.2 Requisitos de los proyectos gestionados en la aplicación ......................................... 17
2.2.4 Notificaciones ............................................................................................................. 18
2.2 Requisitos no funcionales ................................................................................................. 18
2.3 Prototipos de interfaces de usuario .................................................................................. 19
3. Diseño (Iteración 1) ................................................................................................................. 20
3.1 Diseño Arquitectónico ....................................................................................................... 20
3.1.1 Descomposición lógica de capas ................................................................................ 20
3.1.2 Descomposición física de capas ................................................................................. 21
3.2 Diseño de la Base de Datos ............................................................................................... 21
3.2.1 Requisitos de datos .................................................................................................... 21
3.2.2 Diseño conceptual ...................................................................................................... 22
3.2.3 Diseño Lógico ............................................................................................................. 23
3.2.4 Normalización ............................................................................................................ 24
3.3 Diseño de las clases ........................................................................................................... 24
Trabajo Fin de Grado Página 3
3.3.1 Descomposición en paquetes .................................................................................... 24
3.3.2 Diagrama de clases básicas ........................................................................................ 25
3.3.3 Paquete lógica de negocio ......................................................................................... 26
3.3.4 Paquete persistencia .................................................................................................. 26
3.3.5 Paquete presentación ................................................................................................ 26
4. Implementación (Iteración 1) .................................................................................................. 27
4.1 Estructura de proyectos .................................................................................................... 27
4.2 Plan de pruebas ................................................................................................................. 27
4.2.1 Acceso a la aplicación ................................................................................................. 27
4.2.2 Nuevo Proyecto .......................................................................................................... 27
4.2.3 Búsqueda de un proyecto concreto ........................................................................... 28
4.2.4 Gestión de fases de un proyecto ................................................................................ 28
4.2.5 Gestión de participaciones de un proyecto ............................................................... 28
4.2.6 Gestión de requisitos ................................................................................................. 29
4.2.7 Gestión de peticiones de cambio ....................................................................................... 29
5. Seguimiento y control hasta la 1ª iteración ............................................................................ 30
5.1 Recorte del alcance ........................................................................................................... 30
La conclusión del análisis nos permite pensar que, llegados a este punto, la fecha de
finalización del proyecto se mantiene acorde a lo planificado. .............................................. 30
5.2 Control y actualización del cronograma ............................................................................ 31
6. Análisis (Iteración 2) ................................................................................................................ 33
6.1 Requisitos funcionales ....................................................................................................... 33
6.1.1 Tareas definidas en un proyecto ................................................................................ 33
6.1.2 Actividades imputadas a un proyecto ........................................................................ 33
7. Diseño (Iteración 2) ................................................................................................................. 34
7.1 Diseño de la Base de Datos ............................................................................................... 34
7.1.1 Requisitos de datos .................................................................................................... 34
7.1.2 Diseño conceptual ...................................................................................................... 35
7.1.3 Diseño Lógico ............................................................................................................. 36
7.1.4 Normalización ............................................................................................................ 37
7.2 Diseño de las clases ........................................................................................................... 37
7.2.1 Descomposición en paquetes .................................................................................... 37
7.2.2 Diagrama de clases básicas ........................................................................................ 37
7.2.3 Paquete lógica de negocio ......................................................................................... 38
Trabajo Fin de Grado Página 4
7.2.4 Paquete persistencia .................................................................................................. 38
7.2.5 Paquete presentación ................................................................................................ 38
8. Implementación (Iteración 2) .................................................................................................. 39
8.1 Plan de pruebas ................................................................................................................. 39
8.1.1 Gestión de tareas definidas en un proyecto .............................................................. 39
8.1.2 Gestión de actividades ............................................................................................... 40
8.1.3 Plan del proyecto ....................................................................................................... 40
9. Seguimiento y control hasta la 2ª iteración ............................................................................ 41
10. Conclusiones.......................................................................................................................... 44
10.1 Posibles ampliaciones del sistema .................................................................................. 44
10.2 Opinión personal ............................................................................................................. 45
Anexo 1: Manual de usuario ....................................................................................................... 46
1. Introducción .................................................................................................................... 46
2. Inicio de Sesión ................................................................................................................ 46
3. Pantalla principal ............................................................................................................. 47
3.1 Funciones de carácter general ...................................................................................... 47
3.2 Funciones de proyecto .................................................................................................. 48
3.3 Área de notificaciones ................................................................................................... 48
3.4 Panel de búsqueda de proyectos ............................................................................ 49
3.5 Área de despliegue de funcionalidad ...................................................................... 50
3.6 Barra de estado ....................................................................................................... 50
4. Crear un nuevo proyecto ................................................................................................ 51
5. Consultar notificaciones .................................................................................................. 54
6. Consultar el calendario.................................................................................................... 55
7. Consulta de hojas de actividad ........................................................................................ 57
8. Plan de proyecto ............................................................................................................. 58
9. Participantes de un proyecto .......................................................................................... 59
10. Requisitos de un proyecto ........................................................................................... 60
11. Peticiones de cambio .................................................................................................. 62
12. Tareas .......................................................................................................................... 64
Anexo 2: Actas de las reuniones ................................................................................................. 66
Acta de la reunión 1 ............................................................................................................ 66
Asistentes ............................................................................................................................ 66
Asunto ................................................................................................................................. 66
Trabajo Fin de Grado Página 5
Orden del día ....................................................................................................................... 66
Desarrollo ............................................................................................................................ 66
Acta de la reunión 2 ............................................................................................................ 67
Asistentes ............................................................................................................................ 67
Asunto ................................................................................................................................. 67
Orden del día ....................................................................................................................... 67
Desarrollo ............................................................................................................................ 67
Acta de la reunión 3 ............................................................................................................ 68
Asistentes ............................................................................................................................ 68
Asunto ................................................................................................................................. 68
Orden del día ....................................................................................................................... 68
Desarrollo ............................................................................................................................ 68
Trabajo Fin de Grado Página 6
1. Documento de Objetivos del Proyecto El proyecto consiste en la implementación de una aplicación colaborativa para facilitar el
desarrollo y gestión de proyectos en una organización dedicada a la producción de software.
Para ello la aplicación ofrece una interfaz para gestionar los requisitos, fechas, tareas,
peticiones de cambio, etc. generadas en cada proyecto.
1.1 Objetivo El objetivo es conseguir una aplicación de escritorio para Windows que permita gestionar
proyectos de software en un entorno multiproyecto.
El modelo multiproyecto supone una dificultad añadida a la hora de gestionar la producción de
software, puesto que los participantes de éstos deben ser capaces de gestionar eficientemente
varios proyectos de forma simultánea.
De forma añadida debemos tener en cuenta la problemática habitual de los proyectos, como
puede ser la volatilidad de los requisitos del proyecto, que muchas veces están en continuo
movimiento y suponen una reasignación constante de los recursos en la organización; lo que
deja de manifiesto la importancia crucial en la gestión de los proyectos para una organización
dedicada a la producción de software.
1.2 Comunicaciones Como medios de comunicación entre los participantes del proyecto se acuerda el uso del
correo electrónico, reuniones periódicas y Google drive.
1.3 Alcance del producto A continuación ser irán enumerando los requisitos que debe satisfacer el producto. En el
capítulo de análisis se definirán en detalle cada uno de los requisitos funcionales del producto.
Se define un Primer módulo que se ocupará de lo siguiente:
Gestión de proyectos: Este apartado se encargará de dar de alta nuevos proyectos y definir la configuración de cada proyecto, estableciendo la prioridad, los participantes, responsabilidades…
Definición de los requisitos del sistema: Este apartado se encargará de identificar funciones, restricciones y otras propiedades necesarias que deban satisfacerse para cumplir las necesidades propuestas por los usuarios de un sistema informático.
Control de versiones de los requisitos: La distribución y recepción de la información del estado de las versiones de los requisitos es de vital importancia para evitar pérdidas de tiempo trabajando en unos requisitos no actualizados.
Gestión de los cambios de requisitos: Los cambios en los requisitos pueden venir
suscitados por variaciones en el entorno (tecnología, estándares a cumplir, etc.) o por
incidencias en el sistema.
El Segundo módulo se encargará de la gestión de proyectos:
Planificación del proyecto: Este proceso comprende tres actividades diferentes. Estimar: predecir el tamaño del producto final, el tiempo, y el equipo humano requerido para desarrollarlo.
Trabajo Fin de Grado Página 7
Planificar: producir un plan detallado y comprensible para el proyecto usando como
base los valores de una estimación. Debe incluir la definición de hitos claves, la
identificación de tareas y distribución de personal asignado a cada tarea, así como su
responsable.
Gestionar los compromisos: consiste en asegurar que la estimación y el plan se revisan
y ratifican por los responsables de su realización.
Seguimiento del proyecto: El seguimiento del proyecto consiste en recopilar datos
reales del progreso del proyecto, determinar y realizar acciones correctivas, y
gestionar los cambios a los compromisos acordados.
La base de esta actividad es la utilización de un plan de proyecto que se utilice como
medio para comunicar el estado del mismo. Esto implica que el plan es un documento
vivo, que se actualiza con los datos del progreso del proyecto y que es distribuido a los
afectados.
1.4 Metodología Se utilizará un ciclo de vida iterativo e incremental con dos iteraciones, de modo que la
primera iteración cubra los requisitos definidos en el primer módulo y la segunda iteración se
encargue de la implementación del segundo módulo. Entre cada iteración, se planificará una
reunión de evaluación para comprobar la evolución y las necesidades de re-planificación en el
proyecto. En este hito se marcarán los plazos a cubrir en el tiempo restante del proyecto.
1.5 Tecnologías a utilizar Plataforma: .NET
Lenguaje de programación: C#
Sistema Gestor de Base de Datos: MySQL
Sistema Operativo: Windows
Mi experiencia previa me permite afirmar que la combinación de estas tecnologías resulta
efectiva para un proyecto de estas características. Además, el uso de tecnologías conocidas,
permite un ahorro sustancial de tiempo destinado a la formación y familiarización con cada
una de las tecnologías utilizadas.
1.6 Identificación de riesgos y planes de acción El siguiente apartado tiene como objetivo identificar y detallar los posibles riesgos que se
puedan producir durante el desarrollo del proyecto; así mismo, se establece un plan de
actuación antes esos posibles imprevistos.
1.6.1 Riesgos posibles
Indisponibilidad del personal: al tratarse de un proyecto totalmente dependiente del alumno
una situación de enfermedad o accidente de éste afectarían de manera muy grave al
desarrollo del proyecto.
Fallo Hardware: un fallo en los elementos que forman la plataforma de desarrollo del proyecto
podría suponer un retraso en la planificación, además de otros daños colaterales como la
pérdida o corrupción de datos.
Trabajo Fin de Grado Página 8
Fallo Software: una actuación correctiva ante esta situación podría suponer un retraso
evidente en los plazos, ya que el software utilizado para el desarrollo del proyecto requiere de
cierto tiempo para su instalación y configuración.
Estimación incorrecta: es de suponer que las fechas estimadas o la duración de las tareas
pueden tener desviaciones derivadas de la inexperiencia del estimador o necesidades de
aprendizaje no previstas.
1.6.2 Plan de actuación
En caso de indisponibilidad, será necesario replantear la distribución del tiempo y el número
de horas invertidas, para compensar todo el tiempo que se pierda durante el periodo de
indisponibilidad. Una posible solución sería intensificar el número de horas durante las
semanas inmediatamente posteriores al imprevisto e ir normalizando el plan de trabajo
paulatinamente, hasta alcanzar el ritmo de trabajo estimado al inicio del proyecto.
Como actuación ante posibles fallos en el hardware que ocasionen pérdidas o corrupciones de
datos, es necesario reparar/sustituir el componente afectado, y si es necesario, recuperar los
datos del plan de copias de seguridad.
Para prevenir fallos en el software, como medida preventiva, se instalará y configurará el
software necesario para el desarrollo en dos equipos, de modo que si uno de los dos falla
durante el desarrollo, podamos utilizar el otro, siendo necesario únicamente, recuperar la
última versión del código y de la base de datos.
Ante posibles parones en el desarrollo por necesidades de formación, será necesario utilizar
medios externos (manuales, foros, compañeros de trabajo…) para subsanar la situación en la
mayor brevedad posible. En caso de que el parón fuera notorio, sería necesario convocar una
reunión de urgencia con el director de proyecto y analizar la situación de forma conjunta
priorizando las tareas sucesivas y buscando una alternativa que permita continuar con el
proyecto.
Un error en la estimación de la duración de las tareas nos obligará a incrementar las horas
asignadas al proyecto, para esto será necesario un análisis en profundidad del calendario
disponible para encontrar el tiempo necesario y redistribuir el tiempo asignado en la
planificación. Hay que tener en cuenta que las obligaciones laborales del alumno limitan de
forma notoria el número de horas disponibles para el proyecto.
Ante cualquier otro imprevisto, la recomendación será estudiarlo cuando se plantee y buscar
una solución en ese momento. Si el problema persiste lo más adecuado será convocar una
reunión con el director de proyecto para buscar una solución conjunta.
Será necesario documentar cualquier fallo sucedido durante el desarrollo del proyecto, lo que
ayudará a evitar los mismos errores en el futuro.
Trabajo Fin de Grado Página 9
1.6.3 Precauciones a adoptar
En el caso de imprevistos personales será necesario adoptar todas las precauciones lógicas
para conservar la integridad de la persona así como su salud.
Como medida cautelar para evitar pérdidas de datos derivadas de un fallo hardware o un fallo
software se propone realizar copias de seguridad periódicas:
Al finalizar cada sesión de desarrollo de código, realizaremos una copia completa del código
almacenándola en un medio de datos externo (USB, CD, DVD…). Para cada copia realizada
utilizaremos una nomenclatura basada en la fecha, de modo que tengamos identificada cada
versión por la fecha. Ejemplo: copia 20130203 será la copia correspondiente al desarrollo
realizado el día 3 de febrero de 2013.
Del mismo modo, será necesario realizar una copia semanal de la base de datos completa,
utilizando una nomenclatura similar.
Como medida de precaución para evitar un retraso por desconocimiento es recomendable
obtener manuales de las diferentes herramientas que se usarán durante el proyecto.
Para evitar fallos de estimación se recomienda realizar un buen análisis, dedicándole el tiempo
necesario y contrastando nuestras estimaciones con las de otros proyectos que nos sirvan
como guía.
1.7 Entregables A continuación se describen cada uno de los artefactos que serán generados y que constituyen
los entregables del proyecto:
Documento de objetivos del proyecto: documento donde se describen las directrices a seguir en el proyecto.
Catálogo de requisitos: En este documento se define de forma clara, precisa, completa y verificable todas las funcionalidades y restricciones del sistema.
Prototipos de interfaces de usuario: en este documento se especifican las interfaces entre el sistema y el usuario: formatos de pantallas, diálogos, principalmente.
Modelo arquitectónico
Modelo de datos
Modelo de clases
Código fuente de la aplicación y ficheros de BB.DD: estos entregables representan los ficheros del producto final, empaquetados y almacenados en CD junto con los mecanismos necesarios para facilitar su instalación.
Plan de pruebas: este documento servirá como base para contrastar y verificar que el software construido cumple con los requisitos planteados en el proyecto, además de asegurar una calidad mínima en el producto entregado al cliente.
Manual de usuario: Este documento está destinado a dar asistencia a las personas que
utilizan el sistema en particular.
Trabajo Fin de Grado Página 10
1.8 Horario laboral El objetivo de este apartado es definir el trabajo a realizar y cómo se llevará a cabo. Para ello
se proporciona una enumeración de todas las tareas a realizar, una estimación de tiempo y un
marco para la revisión y control de la gestión del proyecto.
Está planificación nos servirá una vez finalizado el proyecto, para comparar el rendimiento real
con el estimado al inicio del proyecto.
1.8.1 Plan semanal de trabajo
La siguiente tabla muestra el horario semanal de trabajo a seguir durante el tiempo que dure
el desarrollo del proyecto estructurado en las siguientes categorías:
La primera, en gris, representa tiempo de tareas fijas, que están firmemente establecidas,
cómo trabajar y el tiempo que se invierte en el trayecto a la oficina. Estas horas, salvo
excepciones, no pueden ser invertidas en el desarrollo del proyecto.
La segunda, en rojo, son las horas regulares establecidas para trabajar en el proyecto.
En la tercera y última categoría, representada en azul, están marcadas las horas que podrían
ser utilizadas para trabajar en el proyecto como medida excepcional si llegasen a ser
necesarias. La utilización de estas horas debe ser una medida temporal en caso de necesidad y
no algo habitual, ya que estas horas representa tiempo de actividades discrecionales como
comer, descansar, hacer vida social o dormir.
Horas Lunes Martes Miércoles Jueves Viernes Sábado Domingo
8:00 – 9:00
9:00 – 10:00
10:00 – 11:00
11:00 – 12:00
12:00 – 13:00
13:00 – 14:00
14:00 – 15:00
15:00 – 16:00
16:00 – 17:00
17:00 – 18:00
18:00 – 19:00
19:00 – 20:00
20:00 – 21:00
Horario Laboral
Horas Proyecto
Horas extra
Trabajo Fin de Grado Página 11
1.8.2 Estructura de Descomposición del Trabajo
Proyecto
Seguimiento
y
control
Planificación
Objetivo
Comunicaciones
Alcance
Tecnología
Riesgos
EDT
Cronograma
Análisis 1
Requisitos funcionales
Requisitos
No funcionales
Interfaces
Diseño 1
Arquitectura
Modelo de datos
Modelo de clases
Implementación 1
Preparar
entorno
Generar
código
Pruebas
Análisis 2
Requisitos funcionales
Requisitos
No funcionales
Interfaces
Diseño 2
Modelo de clases
Modelo de datos
Implementación 2
Generar código
pruebas
Implantación
Manual de usuario
Instalación
Defensa
Preparar
defensa
Presentación
Trabajo Fin de Grado Página 12
1.8.3 Estimación de tiempos y cronograma
Tarea Duración Tiempo Comienzo Fin
SEGUIMIENTO Y CONTROL 86 días 14 horas vie 15/02/13 lun 10/06/13
PLANIFICACIÓN 11 días 20 horas vie 15/02/13 vie 01/03/13 Objetivo 2 días 3 horas vie 15/02/13 sáb 16/02/13
Comunicaciones 1 día 1 hora sáb 16/02/13 sáb 16/02/13
Alcance 2 días 5 horas dom 17/02/13 lun 18/02/13
Tecnología 1 día 1 hora mar 19/02/13 mar 19/02/13
Riesgos 1 día 1 hora mar 19/02/13 mar 19/02/13
Planificación 2 días 3 horas mié 20/02/13 jue 21/02/13
EDT 2 días 3 horas vie 22/02/13 dom 24/02/13
Cronograma 5 días 3 horas lun 25/02/13 vie 01/03/13
ITERACIÓN 1 27 días 120 horas vie 01/03/13 dom 07/04/13
ANÁLISIS 1 7 días 26 horas vie 01/03/13 dom 10/03/13
Requisitos funcionales 2 días 15 horas vie 01/03/13 lun 04/03/13
Requisitos no funcionales 3 días 5 horas mar 05/03/13 jue 07/03/13
Interfaces 2 días 6 horas vie 08/03/13 dom 10/03/13
DISEÑO 1 6 días 19 horas lun 11/03/13 dom 17/03/13
Arquitectura 1 día 2 horas lun 11/03/13 lun 11/03/13
Modelo de Clases 4 días 7 horas mar 12/03/13 vie 15/03/13
Modelo de datos 2 días 10 horas sáb 16/03/13 dom 17/03/13
IMPLEMENTACIÓN 1 16 días 75 horas lun 18/03/13 dom 07/04/13
Preparar Entono 3 días 5 horas lun 18/03/13 mié 20/03/13
Generar Código 13 días 60 horas mié 20/03/13 vie 05/04/13
Pruebas 2 días 10 horas sáb 06/04/13 dom 07/04/13
Unitarias 1 día 3 horas sáb 06/04/13 sáb 06/04/13
Integración 1 día 2 horas sáb 06/04/13 sáb 06/04/13
Sistema 1 día 3 horas dom 07/04/13 dom 07/04/13
Aceptación 1 día 2 horas dom 07/04/13 dom 07/04/13
EVALUACIÓN 1 día 1 hora lun 08/04/13 lun 08/04/13
ITERACIÓN 2 41 días 135 horas mar 09/04/13 dom 02/06/13
ANÁLISIS 2 9 días 25 horas mar 09/04/13 vie 19/04/13
Requisitos funcionales 5 días 15 horas mar 09/04/13 dom 14/04/13
Requisitos no funcionales 3 días 5 horas dom 14/04/13 mar 16/04/13
Interfaces 3 días 5 horas mié 17/04/13 vie 19/04/13
DISEÑO 2 2 días 10 horas sáb 20/04/13 dom 21/04/13
Modelo de Clases 1 día 5 horas sáb 20/04/13 sáb 20/04/13
Modelo de datos 1 día 5 horas dom 21/04/13 dom 21/04/13
IMPLEMENTACIÓN 2 32 días 100 horas lun 22/04/13 dom 02/06/13
Generar Código 26 días 85 horas lun 22/04/13 dom 26/05/13
Pruebas 7 días 15 horas lun 27/05/13 dom 02/06/13
Unitarias 3 días 5 horas lun 27/05/13 mié 29/05/13
Integración 2 días 3 horas mié 29/05/13 jue 30/05/13
Sistema 2 días 3 horas vie 31/05/13 sáb 01/06/13
Aceptación 1 día 4 horas dom 02/06/13 dom 02/06/13
IMPLANTACIÓN 5 días 5 horas lun 03/06/13 vie 07/06/13 Manual de Usuario 4 días 3 horas lun 03/06/13 jue 06/06/13
Instalación 1 día 2 horas vie 07/06/13 vie 07/06/13
DEFENSA 3 días 5 horas sáb 08/06/13 lun 10/06/13 Preparación 2 días 4 horas sáb 08/06/13 dom 09/06/13
Presentación 1 día 1 hora lun 10/06/13 lun 10/06/13
Trabajo Fin de Grado Página 13
Trabajo Fin de Grado Página 14
2. Análisis (Iteración 1)
2.1 Conceptos preliminares A continuación se detallan algunos conceptos necesarios para entender los requisitos
funcionales que debe cumplir la aplicación.
Tipos de usuario: representa cada uno de los roles de los usuarios que utilizan la aplicación.
Categoría Descripción
Becario Son empleados sin experiencia, pueden no pertenecer directamente a la organización y las tareas realizadas por ellos deben ser supervisadas por un programador de mayor categoría o un jefe de proyecto.
Programador Junior Son empleados que realizan tareas de programación en los proyectos. Se les asignan tareas que cubren unos requisitos definidos dentro de cada proyecto.
Programador Senior Cuando los programadores junior adquieren cierta experiencia promocionan a la categoría senior. A ellos se les atribuyen las tareas de implementación de mayor responsabilidad dentro de los proyectos.
Jefe de proyecto A él se le atribuye la responsabilidad de un proyecto en particular. Se encarga de planificar y distribuir el trabajo del proyecto entre los programadores.
Responsable Es el encargado de coordinar los diferentes proyectos dentro del departamento. Su función principal es monitorizar la evolución de los proyectos de su departamento y asignar los proyectos a los jefes de proyecto que considere oportunos.
Director Es la figura con mayor responsabilidad dentro de la organización. Accede a la aplicación para monitorizar los proyectos, sin embargo, no participa activamente en la implementación de éstos.
Fases de un proyecto: representan cada una de las etapas de un proyecto gestionado en la
aplicación.
Fase Descripción
Planificación Esta es la fase con la que nacen los proyectos. En esta etapa se definen las responsabilidades del proyecto, los requisitos…
Implementación En esta etapa se definen las tareas a implementar, asignan a los programadores y éstos las codifican.
Integración Es la etapa en la que se llevan a cabo las pruebas de integración con otros sistemas.
Aceptación Es la última fase antes de poner el proyecto en producción. En esta etapa se verificará que se satisfacen todos los requisitos mediante las pruebas de aceptación.
Producción En esta fase se sube a producción todo el código necesario para el funcionamiento del proyecto
Postmortem En esta última fase el responsable del proyecto lo da por finalizado.
Trabajo Fin de Grado Página 15
Rol de participante: determina el tipo de participación de cada usuario en un proyecto.
Rol Descripción
Responsable Es la máxima autoridad dentro de un proyecto, tiene potestad para aceptar o rechazar cambios sobre requisitos.
Jefe de proyecto Interviene en el proyecto gestionando requisitos y definiendo tareas.
Implementador Es el encargado de llevar a cabo cada una de las tareas definidas por los jefes de proyecto.
Estado de un requisito: define la situación de un requisito en un determinado momento.
Estado Descripción
Propuesto El requisito ha sido propuesto por una persona con la autoridad suficiente para proponerlo.
Aprobado El requisito ha sido aprobado por el responsable del proyecto.
Implementado El código que implanta el requisito ha sido diseñado, escrito y han sido realizadas sus pruebas unitarias.
Verificado El requisito implementado ha sido completamente verificado según los procedimientos establecidos.
Diseñado Los elementos de diseño resultantes de este requisito funcional fueron creados y revisados.
Entregado El sistema funcional que engloba el requisito ha sido entregado a los usuarios.
Anulado Un requisito planificado ha sido retirado por el comité de control de cambios.
Rechazado Requisito presentado que nunca fue aprobado.
Diferido Requisito presentado en el que por circunstancias se difiere su implementación.
Estado de una petición de cambio: determina la situación de una petición de cambio.
Estado Descripción
Inicial El peticionario del cambio cumplimenta el formulario correspondiente de la petición de cambio.
Entregada El autor ha enviado una petición de cambio, se comprueba que cumple todos los requisitos necesarios, y se distribuye a las personas involucradas.
Presentada El responsable del proyecto ha leído la petición de cambio.
Evaluada El responsable ha analizado los posibles impactos, técnicos y económicos, en sus áreas y en el proyecto. Si se necesita un estudio más profundo se pasa al evaluador.
Aprobada La petición de cambio ha superado la evaluación.
Realizada Se ha desarrollado el contenido del cambio.
Verificada Se ha comprobado que el contenido del cambio ha sido corregido y que está operativo.
Cerrada El cambio ha funcionado correctamente durante un tiempo prudencial.
Anulada El autor ha anulado la petición de cambio.
Rechazada No se ha justificado la necesidad o viabilidad del cambio. Se ha comunicado tal decisión al autor.
Diferida El cambio ha sido presentado y evaluado, pero por razones técnicas se ha aconsejado su retraso para mejor ocasión. Se ha comunicado tal decisión al autor.
Cancelada El cambio ha sido presentado, evaluado, aprobado, realizado y verificado, pero por razones técnicas han aconsejado su cancelación.
Trabajo Fin de Grado Página 16
Roles en una petición de cambio: indica la función desempeñada por cada persona que
interviene en una petición de cambio de requisito de un proyecto.
Rol Descripción
Responsable del proyecto
Persona que dirige el proyecto y que designa al evaluador de cada petición y al modificador de cada petición de cambio aprobada. Es miembro del CCB.
Autor Persona que envía la petición de cambio, puede pertenecer al proyecto o a cualquier área afectada por el mismo.
Evaluador Persona a quien se le solicita que analice más profundamente el impacto de un cambio propuesto.
Modificador Persona responsable de realizar los cambios en respuesta a una petición de cambio aprobada.
Verificador Persona responsable de determinar si el cambio fue realizado correctamente.
Tipo de petición: clasifica cada petición de cambio según su finalidad.
Tipo Descripción
Cambio de requisito Este tipo de petición se produce cuando el usuario quiere cambiar un requisito sin que este cambio esté producido por alguna incidencia.
Mejora propuesta Determina una mejoría en el funcionamiento del requisito
Incidencia Indica una incidencia detectada en el funcionamiento normal del requisito.
Tipo de notificación: determina el grupo al que pertenece cada una de las notificaciones que
recibe el usuario de la aplicación
Tipo Descripción
Calendario En este grupo entran todas aquellas notificaciones que tienen que ver con plazos y fechas referentes a un proyecto de la aplicación.
Asignaciones Agrupa todas las notificaciones que tienen que ver con asignaciones del usuario dentro de un proyecto. Roles asignados dentro de un proyecto, en una petición…
Requisitos Este tipo de notificación agrupa a aquellas notificaciones que tienen que ver con requisitos de proyectos gestionados dentro de la aplicación.
Peticiones Determina notificaciones acerca de peticiones de cambio sobre requisitos de un proyecto.
Trabajo Fin de Grado Página 17
2.2 Requisitos funcionales Se distinguen cuatro tipos de requisitos funcionales atendiendo a la entidad con la cual está
relacionado cada requisito funcional. Estas entidades son: Proyectos gestionados en la
aplicación, requisitos de cada proyecto, peticiones de cambio sobre requisitos y notificaciones
de usuario.
2.2.1 Proyectos gestionados en la aplicación
La aplicación debe permitir gestionar entidades de tipo proyecto para:
Dar de alta nuevos proyectos en la aplicación.
Buscar y consultar los proyectos en los que participa el usuario.
Definir los participantes de cada proyecto asignando un rol determinado para cada
participante dentro del proyecto.
Estimar las fechas en las que el proyecto entrará en cada fase.
Modificar de las fechas estimadas para cada fase.
Confirmar las fechas estimadas para cuando el proyecto cambie de fase.
Consultar el calendario de actuación de cada proyecto indicando la fecha estimada
para cada fase; y una vez confirmada cada fase, la fecha real en la que el proyecto
entró en cada una de las fases definidas en el proyecto.
Consultar el listado de participantes de un proyecto mostrando el rol desempeñado
por cada participante dentro del proyecto.
Finalizar una participación dentro de un proyecto.
Añadir de nuevas participaciones al proyecto.
2.2.2 Requisitos de los proyectos gestionados en la aplicación
En cuanto a los requisitos la aplicación debe permitir:
Definir nuevos requisitos para cada proyecto.
Consultar los datos de un requisito (estado, prioridad, versiones, etc.)
Consultar las diferentes versiones de un requisito.
Modificar el estado de un requisito.
Filtrar la lista de requisitos del proyecto dependiendo del estado de cada requisito.
2.2.3 Peticiones de cambio sobre un requisito del proyecto A medida que los participantes de un proyecto trabajan en él pueden necesitar que las
especificaciones de requisitos se adapten a unas necesidades concretas. Para gestionar estos
cambios, la aplicación utiliza el concepto de petición de cambio. Para poder gestionar estas
peticiones es necesario que la herramienta nos permita:
Presentar solicitudes de cambio para cada requisito definido en un proyecto.
Consultar el listado de peticiones realizadas por cualquier usuario de la aplicación.
Filtrar el listado dependiendo del estado actual de cada petición de cambio.
Consultar los detalles de una solicitud y su evolución a través del tiempo a medida que
ésta ha ido cambiando de estado.
Modificar el estado de una solicitud de cambio.
Generar una nueva versión de requisito para las peticiones aprobadas.
Trabajo Fin de Grado Página 18
2.2.4 Notificaciones
Al tratarse de una aplicación colaborativa es fundamental comunicar mediante notificaciones
los cambios que surgen en cada proyecto a los diferentes empleados que han sido asignados al
proyecto.
De este modo, es necesario que la aplicación permita:
Notificar cambios en las fases definidas en un proyecto.
Notificar cambios en las asignaciones, participaciones, etc. de los participantes de un
proyecto.
Notificar cambios en los requisitos definidos en un proyecto gestionado por la
aplicación.
Notificar cambios en la evolución de cada petición de cambio gestionadas en la
aplicación.
Filtrar el listado de notificaciones de usuario dependiendo de si éstas han sido leídas o
no.
Eliminar notificaciones de la bandeja del usuario.
Marcar notificaciones como leídas.
Marcar notificaciones como no leídas.
2.2 Requisitos no funcionales La aplicación debe cumplir, al menos, los siguientes requisitos no funcionales:
Concurrencia: Es fundamental que el sistema pueda actuar con varios usuarios de
forma simultánea.
Rendimiento: En condiciones óptimas de la red el tiempo de respuesta de la aplicación debe ser relativamente rápido.
Mantenibilidad: La información relativa a los requisitos y los proyectos debe ser
posible gestionarlos mediante la interfaz de la aplicación. Queda fuera de este
proyecto la gestión relativa a la información de los usuarios y otros elementos
predefinidos como estados o prioridades.
Trabajo Fin de Grado Página 19
2.3 Prototipos de interfaces de usuario A continuación se presenta el aspecto que presentará la pantalla principal de la aplicación.
La idea es que la pantalla se divida en cinco áreas principales:
Barra de herramientas: situada en la parte superior y que permite acceder a la
funcionalidad de la aplicación mediante botones. Los botones de la barra de
herramientas se clasificarán en dos grupos:
o Aquellos que activan una funcionalidad independientemente del proyecto
seleccionado en el panel lateral de proyectos.
o Aquellos que activan una funcionalidad para el proyecto seleccionado en el
panel de proyectos.
Panel de proyectos: situado en la parte izquierda, resaltado en azul. La aplicación
dispondrá de un panel que nos permitirá acceder al proyecto que nos interese. Será
necesario incluir en este panel alguna herramienta de búsqueda o filtro para facilitar al
usuario la localización de un proyecto determinado.
Área principal: en esta zona, situada en el centro de la pantalla, se presentará la
información funcional relativa a un proyecto seleccionado. Esta zona irá cambiando en
función de la opción que seleccione el usuario en la barra de herramientas.
Trabajo Fin de Grado Página 20
Área de notificaciones: en esta zona se presentarán las notificaciones al usuario con
información relativa a cambios de estado de los proyectos, cambios en los requisitos,
etc.
Barra de estado: en la parte inferior de la interfaz estará situada la barra de estado que
mostrará información de usuario; como el login de usuario, la categoría profesional
asignada y el departamento al que pertenece el usuario.
3. Diseño (Iteración 1)
3.1 Diseño Arquitectónico Para el desarrollo de la aplicación de escritorio se utilizará una arquitectura de tres capas.
Cada capa se implementará dentro de un proyecto y todas las capas residirán en la misma
solución, formando conjuntamente el código de la aplicación.
3.1.1 Descomposición lógica de capas
Desde un punto de vista lógico, el sistema se descompone en las tres capas más habituales en
la programación de este estilo; presentación, negocio y persistencia.
La siguiente figura representa gráficamente las capas y las relaciones que establecen entre sí.
3.1.1.1 Capa de presentación
En esta capa estarán los formularios necesarios para interactuar con el usuario. Además se
encargará de operaciones de validación de datos si fuera necesario.
3.1.1.2 Capa de lógica
En esta capa se implementarán todas las reglas de negocio necesarias para que la aplicación
funcione acorde a las premisas establecidas en el análisis del proyecto.
3.1.1.3 Capa de persistencia
En esta capa se implementarán los métodos necesarios para comunicarse con la base de datos,
actuando como intermediario entre la capa de lógica y el Sistema Gestor de Base de Datos
(SGBD).
3.1.1.4 Almacén de datos
Será el encargado de almacenar las tablas y los procedimientos almacenados necesarios para
guardar en la Base de Datos la información relativa a las entidades del proyecto.
Cap
a d
e p
rese
nta
ció
n
Aplicación de
escritorio
Cap
a d
e n
ego
cio
paquete lógica
Cap
a d
e p
ersi
sten
cia
paquete persistencia
Trabajo Fin de Grado Página 21
3.1.2 Descomposición física de capas
La idea inicial del proyecto implica un único equipo para realizar la demostración, en el que
residen las tres capas (aplicación) y el SGBD en local, sin embargo, la aplicación está pensada
para trabajar en red, de forma el SGBD estaría en un servidor al que se conecta cada usuario,
que tiene instalada la aplicación en su equipo personal. Los equipos de usuario estarían
conectados en red local.
3.2 Diseño de la Base de Datos
3.2.1 Requisitos de datos
A continuación se describen los requisitos de datos del primer módulo de la aplicación, cuya
finalidad será gestionar los propios proyectos como entidades y los requisitos definidos en
cada proyecto. Estas tareas de gestión de proyectos y requisitos estarán apoyadas por
notificaciones que proporcionan al usuario de la aplicación información útil acerca de los
movimientos que se producen durante la gestión de los proyectos.
La base de datos debe almacenar información de los proyectos en los que trabajan los
usuarios de la aplicación. Para cada proyecto es necesario guardar un código identificativo, que
será único, el nombre, una breve descripción, la fecha en la que comenzó el proyecto y la
prioridad asignada a éste. La aplicación trabaja con cinco niveles de prioridad: baja, normal,
alta, muy alta y urgente.
Según avanza el proyecto, éste va atravesando fases. Un proyecto puede encontrarse en una
única fase en un momento de tiempo determinado, sin embargo, es necesario conocer todas
las fases por las que ha pasado un proyecto a lo largo de su ciclo de vida, la fecha en la que se
estimaba llegar a cada fase y la fecha real en la que el proyecto llegó a cada fase.
Por otro lado, es necesario conocer todos los usuarios que participan en cada proyecto y cuál
es el rol desempeñado por éstos en el proyecto. Además, será necesario almacenar la fecha de
inicio y finalización de cada participación. Un usuario no puede desempeñar más de un rol en
cada proyecto; además, un proyecto debe tener como mínimo un responsable asignado.
Cada empleado dispondrá de un usuario para acceder a la aplicación. Para cada empleado
debemos guardar el nombre, los apellidos, login de usuario, contraseña y dirección de correo
electrónico. Cada empleado pertenece a un departamento del que necesitamos saber el
código de departamento y el nombre. Además un departamento puede tener a su vez un
departamento de nivel superior, ya que la empresa tiene una relación jerárquica.
Por otra parte, cada empleado tiene asignada una categoría profesional. Además, según vayan
adquiriendo experiencia, los empleados pueden cambiar de categoría, por lo que es necesario
conocer el periodo concreto en el que tuvo una determinada categoría cada empleado.
Cada proyecto gestionado en la aplicación puede tener definido una serie de requisitos. Para
cada requisito nos interesa saber el código, que será único, el nombre, la fecha de creación, la
prioridad de implementación, el estado actual de cada requisito y la persona que definió el
requisito. Cada requisito puede llegar a tener varias versiones y para cada una de ellas nos
interesa conocer el número de versión, la fecha en la que se definió la versión, una descripción
de la versión del requisito y si la versión está o no activa actualmente.
Trabajo Fin de Grado Página 22
Los usuarios de la aplicación pueden solicitar cambios en la versión activa de un requisito. Para
cada petición es necesario almacenar el código único de la petición, un título descriptivo, la
fecha en la que se realizó la petición, el tipo de petición, que puede ser cambio, mejora o
incidencia; la prioridad, asunto, motivos de la solicitud, una breve descripción, la respuesta
final del responsable, el autor de la petición y el empleado designado para modificar el
requisito si finalmente se aprueba; el empleado que debe verificar que los cambios sean
correctos.
Finalmente debemos guardar la información referente a las notificaciones que recibe cada
usuario. Cada notificación tiene una fecha de envío, la fecha en la que el usuario recibió la
notificación, el empleado al que va dirigida, un texto que describe el motivo de la notificación,
un indicador para saber si el usuario quiere marcarla como leída o como no leída, la prioridad y
un tipo de notificación que indica el grupo al que pertenece la notificación; ésta puede ser
calendario, asignación, requisito o petición.
3.2.2 Diseño conceptual
A continuación se muestra el modelo Entidad Relación correspondiente a los requerimientos
de datos del punto anterior.
Para simplificar la comprensión del modelo se han excluido los atributos de cada entidad, que
podremos ver en el modelo lógico posterior.
Trabajo Fin de Grado Página 23
3.2.3 Diseño Lógico
En el siguiente modelo se presenta la transformación del modelo E/R en tablas lógicas,
detallando para cada tabla la clave primaria (PK) y sus claves foráneas (FK).
Trabajo Fin de Grado Página 24
3.2.4 Normalización
Analizando el diseño lógico podemos observar que todos los atributos que aparecen en él son
monovaluados, por lo tanto, podemos afirmar que el modelo se encuentra en primera forma
normal.
Observando en detalle las dependencias funcionales podemos afirmar que todos los atributos
no primos dependen de manera total de toda clave primaria o candidata, por lo tanto,
podemos decir, que el modelo se encuentra en segunda forma normal.
Analizando la tabla “EMPLEADO” podemos observar que sus dependencias funcionales
rompen la tercera forma normal, ya que el atributo password, que es un atributo no primo,
tiene una dependencia funcional con el atributo login, que no es superclave.
Para corregir esta anomalía tendríamos que dividir la tabla empleado en dos, una con los
atributos de usuario (login y password) en el que la clave primaria sería el atributo login, y otra
tabla con el resto de atributos. Sin embargo, nos interesa asumir esta desnormalización para
optimizar nuestras consultas en Base de Datos, ya que el riesgo de redundancia es mínimo;
esta situación podría producirse para empleados con varias etapas en la organización.
Por lo tanto, afirmamos que el resto de tablas cumplen con la tercera forma normal.
Dado que nuestro volumen de datos no es excesivamente elevado podemos dar por
satisfechas nuestras necesidades con este nivel de normalización en nuestro diseño.
3.3 Diseño de las clases
3.3.1 Descomposición en paquetes
Como se observa en el diagrama que se presenta a continuación, se han estructurado las
clases de la aplicación en cuatro paquetes, a los que se han denominado: clases básicas,
presentación, lógica de negocio y persistencia.
El paquete clases básicas representa el modelo en el que se basa el universo conceptual de la
aplicación. Este paquete da soporte al resto de paquetes.
En el paquete presentación estarán todas las clases que dan soporte a la interfaz gráfica de la
aplicación, en su mayor parte clases para construir los objetos formulario de la aplicación.
El paquete lógica de negocio se encargará de englobar las clases que deciden las reglas que
deben cumplirse en el sistema. A su vez hará de intermediario entre la capa de presentación y
la persistencia.
Por último, en el paquete persistencia residen las clases que se encargan de interactuar con el
sistema gestor de base de datos.
Trabajo Fin de Grado Página 25
3.3.2 Diagrama de clases básicas
El siguiente diagrama representa el modelo que componen las clases básicas de la aplicación.
Trabajo Fin de Grado Página 26
3.3.3 Paquete lógica de negocio
A continuación se muestra el detalle de las clases que componen el paquete de lógica de
negocio.
3.3.4 Paquete persistencia
Para el paquete persistencia implementaremos una única clase que se compondrá de todos los
métodos necesarios para dar soporte al paquete de lógica de negocio.
3.3.5 Paquete presentación
El paquete de presentación estará compuesto de tantas clases como formularios diferentes se
utilizan en la aplicación. El siguiente esquema muestra el detalle de las clases que componen el
paquete.
Trabajo Fin de Grado Página 27
4. Implementación (Iteración 1)
4.1 Estructura de proyectos A continuación se explica la estructura del entorno de implementación de la aplicación. Todos los proyectos que componen la aplicación se han agrupado dentro de una única solución de Microsoft Visual Studio. Dentro de esta solución se han creado 4 proyectos:
Modelo: esta biblioteca de clases contiene todas las clases que representan las clases básicas de la aplicación usadas por el resto de los proyectos de la aplicación.
Lógica: esta biblioteca de clases contiene las clases de la capa de lógica de negocio, actúa a modo de intermediario entre la persistencia y la presentación.
Persistencia: esta biblioteca de clases se encarga de interactuar con la base de datos realizando entradas y salidas de datos en la base de datos.
Presentación: contiene los formularios de la aplicación que interactúan entre el usuario y la capa de negocio.
4.2 Plan de pruebas El objetivo de este documento es especificar el Plan de Pruebas en la aplicación, comprobando
que el proyecto cumple con los requisitos funcionales descritos en el análisis.
4.2.1 Acceso a la aplicación
TEST-CASE PASOS RESULTADO
FrmLogin Comprobar que los datos de acceso a la aplicación son obligatorios OK
FrmPrincipal Comprobar login, categoría y departamento de la barra de estado OK
4.2.2 Nuevo Proyecto
TEST-CASE PASOS RESULTADO
FrmPrincipal Comprobar apertura de formulario asistente nuevo proyecto paso 1 en forma modal
OK
FrmNuevoP1 Comprobar campos obligatorios: código de proyecto y nombre OK
Comprobar control datetime con fecha actual OK
Comprobar que se cargan todas las prioridades en la lista desplegable OK
FrmNuevoP2 Comprobar que es obligatorio agregar un responsable OK
Comprobar que sólo se puede agregar un único responsable OK
Comprobar que la fecha de inicio de la participación no puede ser anterior a la fecha de inicio del proyecto
OK
Comprobar que se cargan todos los roles disponibles en la lista desplegable
OK
Comprobar que se pueden agregar participaciones con cualquier rol OK
FrmNuevoP2 Comprobar que las fases deben ir en orden cronológico OK
Comprobar que al finalizar se insertan los datos en BB.DD. OK
Comprobar que se envían las notificaciones de participación y fases OK
Trabajo Fin de Grado Página 28
4.2.3 Búsqueda de un proyecto concreto
TEST-CASE PASOS RESULTADO
FrmPrincipal Comprobar que se localizan proyectos por código OK
Comprobar que se localizan proyectos por nombre OK
Comprobar que se muestran sólo proyectos activos en los que participa el usuario
OK
Comprobar que la búsqueda en blanco muestra todos los proyectos OK
Comprobar desplazamiento mediante flechas OK
4.2.4 Gestión de fases de un proyecto
TEST-CASE PASOS RESULTADO
FrmCalendario Comprobar que se muestran las fases iniciadas en el mes que muestra el calendario
OK
Comprobar que no se puede finalizar una fase con fases anteriores abiertas
OK
Comprobar que se puede retrasar la fecha de inicio de una fase OK
Comprobar que se puede finalizar una fase activa OK
Comprobar que la lista de fases cambian al cambiar el mes en el calendario
OK
4.2.5 Gestión de participaciones de un proyecto
TEST-CASE PASOS RESULTADO
FrmParticipaciones Comprobar que la lista muestra las participaciones del proyecto seleccionado
OK
Comprobar que la lista desplegable muestra todos los roles disponibles
OK
Comprobar que la lista cambia en función del rol seleccionado en la lista desplegable
OK
Comprobar que no se puede finalizar la participación de un responsable
OK
Comprobar que no se puede eliminar la participación de un responsable
OK
Comprobar que se pueden agregar nuevas participaciones OK
Comprobar que solo no se pueden agregar más de un responsable
OK
Comprobar que se puede finalizar una participación OK
Comprobar que se puede eliminar una participación OK
Comprobar que no se puede agregar a un participante con más de un rol
OK
Trabajo Fin de Grado Página 29
4.2.6 Gestión de requisitos
TEST-CASE PASOS RESULTADO
FrmRequisitos Comprobar que la lista muestra los requisitos del proyecto seleccionado
OK
Comprobar que la lista desplegable muestra todos los estados disponibles
OK
Comprobar que la lista cambia en función del estado seleccionado en la lista desplegable
OK
Comprobar que se pueden agregar nuevos requisitos al proyecto
OK
Comprobar que se pueden solicitar peticiones de cambio sobre un requisito del proyecto
OK
Comprobar que aparecen todas las versiones de un requisito OK
Comprobar las operaciones de cambio de estado de un requisito
OK
Comprobar botones de estado disponibles dependiendo del usuario y el estado del requisito
OK
4.2.7 Gestión de peticiones de cambio
TEST-CASE PASOS RESULTADO
FrmPeticionesCambio Comprobar que la lista muestra las peticiones de cambio del proyecto seleccionado
OK
Comprobar que la lista desplegable muestra todos los estados disponibles
OK
Comprobar que la lista cambia en función del estado seleccionado en la lista desplegable
OK
Comprobar que se puede consultar los detalles de una petición al pulsar el botón ver
OK
Comprobar que el formulario detalle de una petición de cambio se abre en forma modal
OK
Comprobar las operaciones de cambio de estado de un requisito
OK
Comprobar botones de cambio de estado disponibles según rol del usuario y estado de la petición
OK
4.2.8 Gestión de notificaciones
TEST-CASE PASOS RESULTADO
FrmNotificaciones Comprobar que el listado muestra las notificaciones correspondientes al usuario
OK
Comprobar que el listado se filtra en función de la opción seleccionada en la lista desplegable
OK
Comprobar que se marcan notificaciones como leídas OK
Comprobar que se marcan notificaciones como no leídas OK
Comprobar que se pueden eliminar notificaciones OK
Comprobar actualización del listado OK
Trabajo Fin de Grado Página 30
5. Seguimiento y control hasta la 1ª iteración En este aparatado se realizará un seguimiento con el fin de conocer la salud del proyecto e identificar aquellas áreas que requieren de mayor atención. Además se monitorizará y controlará la totalidad del esfuerzo del proyecto implementando acciones correctivas, si fueran necesarias, de modo que el proyecto cumpla con el plan establecido.
5.1 Recorte del alcance A nivel general, se puede afirmar que las estimaciones de las tareas planificadas han sido bastante precisas, sin embargo, un imprevisto personal, que supuso un parón total en el proyecto durante casi dos semanas, produjo que se resintiera el tiempo invertido en la fase de implementación 1. Este imprevisto provocó un recorte en el alcance planificado para la fase de implementación 1, trasladando parte de las tareas planificadas en esta iteración a la segunda. En la siguiente gráfica se puede observar el contraste entre el tiempo y el tiempo real invertido.
La fase de seguimiento y control ha consumido la mitad del tiempo estimado para ello en el proyecto completo; dado que estamos en la mitad del proyecto, podemos afirmar que el avance es correcto. Respecto a las fases de planificación, análisis 1 y diseño 1 se puede observar una ligera subestimación en el tiempo, sin embargo, no son suficientemente significativas como para tomar medidas correctivas concretas. Para corregir las carencias de la fase de implementación 1, se modificará la estimación de tiempos para la segunda iteración, incrementando el número de horas invertidas en la fase de implementación 2. Esto lo llevaremos a cabo, utilizando parte de las horas extras marcadas en el horario laboral, pensadas como salvoconducto en caso de urgencia.
La conclusión del análisis nos permite pensar que, llegados a este punto, la fecha de
finalización del proyecto se mantiene acorde a lo planificado.
01020304050607080
ESTIMADO
REAL
Trabajo Fin de Grado Página 31
5.2 Control y actualización del cronograma A continuación puede observarse en detalle la diferencia de tiempo invertido en relación al
tiempo planificado por tareas.
Nombre de tarea Tiempo Planificado Tiempo Real Diferencia
SEGUIMIENTO Y CONTROL 7 horas 7 horas 0 horas
PLANIFICACIÓN 20 horas 30 horas 10 horas
Objetivo 3 horas 4 horas 1 horas
Comunicaciones 1 hora 1 hora 0 hora
Alcance 5 horas 6 horas 1 horas
Tecnología 1 horas 2 horas 1 horas
Riesgos 1 horas 2 horas 1 horas
Planificación 3 horas 4 horas 1 horas
EDT 3 horas 5 horas 2 horas
Cronograma 3 horas 6 horas 3 horas
ITERACIÓN 1 120 horas 101 horas 19 horas
ANÁLISIS 1 26 horas 30 horas 4 horas
Requisitos funcionales 15 horas 18 horas 3 horas
Requisitos no funcionales 5 horas 5 horas 0 horas
Interfaces 6 horas 7 horas 1 horas
DISEÑO 1 19 horas 21 horas 2 horas
Arquitectura 2 horas 2 horas 0 horas
Modelo de Clases 7 horas 7 horas 0 horas
Modelo de datos 10 horas 12 horas 2 horas
IMPLEMENTACIÓN 1 75 horas 50 horas 25 horas
Preparar Entono 5 horas 4 horas 1 horas
Generar Código 60 horas 41 horas 19 horas
Pruebas 10 horas 5 horas 5 horas
Unitarias 3 horas 2 horas 1 horas
Integración 2 hora 1 hora 1 hora
Sistema 3 hora 1 hora 2 hora
Aceptación 2 hora 1 hora 1 hora
EVALUACIÓN 1 hora 1,5 hora 0,5 hora
Trabajo Fin de Grado Página 32
En el siguiente diagrama se refleja el resultado de la actualización del cronograma una vez
registrados los tiempos reales para la primera iteración y re-planificadas las tareas
correspondientes a la segunda iteración.
Trabajo Fin de Grado Página 33
6. Análisis (Iteración 2)
6.1 Requisitos funcionales En esta segunda iteración se distinguen dos tipos de requisitos funcionales: aquellos requisitos
que están relacionados con las tareas definidas en un proyecto y los requisitos relacionados
con las actividades que los empleados imputan a un proyecto.
Desde un punto de vista teórico definimos actividad como el resultado de la ejecución de una
tarea definida en un proyecto por un empleado concreto. Cada empleado irá cerrando
actividades a medida que vaya completando tareas asignadas, y el plan del proyecto se irá
actualizando de forma automática mostrando a cada participante del proyecto una visión
global del avance del proyecto, además de un resumen por cada una de las fases definidas en
él.
6.1.1 Tareas definidas en un proyecto
La aplicación debe permitir gestionar las siguientes funcionalidades relacionadas con tareas:
Definir nuevas tareas en un proyecto
Asignar una tarea a un participante del proyecto
Consultar las tareas definidas en un proyecto
Eliminar tareas de un proyecto
Editar una tarea definida en un proyecto
Filtrar la lista de tareas por su estado
6.1.2 Actividades imputadas a un proyecto
En cuanto a las actividades, la aplicación debe permitir:
Imputar una actividad derivada de una tarea definida en un proyecto
Consultar las actividades imputadas en un proyecto
Cerrar una actividad derivada de una tarea definida
Listar las actividades imputadas por mes
Editar una actividad imputada a un proyecto
Eliminar una actividad imputada a un proyecto
6.1.3 Plan del proyecto
El plan del proyecto tiene como objetivo informar a los participantes del proyecto, por lo que
sus requisitos funcionales serán de consulta:
Mostrar el tiempo planificado por fase
Mostrar el tiempo ejecutado por fase
Mostrar el porcentaje completado hasta la fecha sobre la estimación por fase
Mostrar la fase actual del proyecto y el tiempo estimado para la siguiente
Mostrar un resumen de todas las fases
Trabajo Fin de Grado Página 34
7. Diseño (Iteración 2)
7.1 Diseño de la Base de Datos En este apartado se describe el diseño correspondiente a la segunda iteración definida en el
proyecto, en la que se introducen los conceptos de tarea, actividad y plan del proyecto que se
relacionan con algunos de los conceptos definidos en la primera iteración como los proyectos,
los requisitos o las fases de cada proyecto.
7.1.1 Requisitos de datos
Para cada proyecto definido en la base de datos se pueden definir tareas de forma que el
conjunto de todas las tareas complete el proyecto y cubra todos y cada uno de los requisitos
definidos en el proyecto.
Es necesario para cada tarea almacenar la siguiente información: nombre asignado a la tarea,
fecha de creación de la tarea, descripción del fin con el que se define la tarea, estado actual de
la tarea, fecha de inicio estimado para ejecutar la tarea, fecha de finalización prevista, número
de horas estimadas para ejecutar la tarea, el empleado designado para ejecutar la tarea, fase y
proyecto en la que se define la tarea.
Cada una de las tareas puede referenciar uno o más requisitos definidos en el proyecto, de
modo que al ejecutar las tareas los requisitos queden cubiertos. Es necesario que la base de
datos guarde la relación entre tarea y requisitos cubiertos.
Cada actividad representa la ejecución de una tarea y para cada tarea puede imputarse más de
una actividad mientras permanezca en estado abierta. Para cada actividad nos interesa saber
la tarea que origina la actividad, la fecha en la que se ejecutó, el tipo de actividad, el número
de horas necesarias para ejecutar la actividad y los comentarios de la persona que ejecutó la
actividad.
A medida que se van ejecutando tareas el plan del proyecto se va actualizando y muestra a
cada empleado el porcentaje de tareas completadas por fase en función de la estimación para
cada una de esas tareas.
Dado que los tiempos estimados se almacenan con las tareas, que los tiempos ejecutados se
guardan con cada actividad, y que los porcentajes son cálculos derivados de los datos
anteriores, no es necesario almacenar información adicional para el plan del proyecto; ya que
seremos capaces de construirlo en base al resto de información almacenada en nuestro
modelo de datos.
Trabajo Fin de Grado Página 35
7.1.2 Diseño conceptual
A continuación se muestra el modelo Entidad Relación ampliado a partir del modelo definido
en la primera iteración y adaptado a los requerimientos de datos del punto anterior.
Para simplificar la comprensión del modelo se han excluido los atributos de cada entidad, que
podremos ver en el diseño lógico posterior.
Trabajo Fin de Grado Página 36
7.1.3 Diseño Lógico
En el siguiente modelo se presenta la transformación del modelo E/R en tablas lógicas,
detallando para cada tabla la clave primaria (PK) y sus claves foráneas (FK).
Trabajo Fin de Grado Página 37
7.1.4 Normalización
Analizando el diseño lógico comprobamos que las nuevas tablas introducidas en el modelo
cumplen como mínimo la tercera forma normal.
7.2 Diseño de las clases En este apartado se muestra el diseño de clases ampliado con respecto al modelo definido en
el diseño de clases de la primera iteración del proyecto.
7.2.1 Descomposición en paquetes
La estructura de paquetes se mantiene con respecto al diagrama de paquetes representado en
el apartado de diseño de la primera iteración.
7.2.2 Diagrama de clases básicas
El siguiente diagrama representa el modelo que componen las clases básicas de la aplicación.
Trabajo Fin de Grado Página 38
7.2.3 Paquete lógica de negocio
A continuación se muestra el detalle de las clases que componen el paquete de lógica de
negocio.
7.2.4 Paquete persistencia
Para el paquete persistencia mantiene una única clase, en la que se agregan los métodos
correspondientes a las entradas y salidas en base de datos relacionadas con las actividades y
las tareas.
7.2.5 Paquete presentación
En el paquete de presentación aparecen tres nuevos formularios: FrmActividades,
FrmPlanProyecto y FrmTareas.
Trabajo Fin de Grado Página 39
8. Implementación (Iteración 2)
8.1 Plan de pruebas El objetivo de este documento es ampliar la especificación del Plan de Pruebas de la aplicación
definido en la primera iteración del proyecto, cubriendo los requisitos funcionales definidos en
el apartado diseño de esta segunda iteración.
8.1.1 Gestión de tareas definidas en un proyecto
TEST-CASE PASOS RESULTADO
FrmTareas Comprobar que en la definición de una nueva tarea están disponibles todos los requisitos del proyecto que estén sin cubrir
OK
Comprobar que no se puede estimar una fecha de inicio anterior al inicio del proyecto
OK
Comprobar que todos los datos de la tarea son obligatorios OK
Comprobar que se crean las notificaciones correspondientes al definir una nueva tarea
OK
Comprobar la relación en base de datos entre requisito y tarea al definir una nueva tarea en un proyecto
OK
Comprobar que están disponibles todos los participantes de un proyecto cuando se define una nueva tarea
OK
Comprobar que no se pueden crear tareas sin requisitos a cubrir OK
Comprobar que se pueden filtrar las tareas diferenciando aquellas que se han ejecutado de aquellas que no
OK
Comprobar que se pueden consultar los detalles de una tarea OK
Comprobar que se puede eliminar una tarea no ejecutada OK
Comprobar que no se pueden eliminar las tareas ejecutadas OK
Comprobar que se notifican las tareas eliminadas al empleado asignado para su ejecución
OK
Comprobar que se pueden modificar los datos de una tarea no ejecutada
OK
Comprobar que las tareas ejecutadas no son editables OK
Comprobar que se notifican los cambios de tareas editadas a los empleados implicados en la tarea
OK
Trabajo Fin de Grado Página 40
8.1.2 Gestión de actividades
TEST-CASE PASOS RESULTADO
FrmActividades Comprobar que en la definición de una nueva actividad están disponibles todas las tareas que estén sin ejecutar
OK
Comprobar que no se pueden imputar horas decimales que no sean media hora
OK
Comprobar que todos los datos de la actividad son obligatorios OK
Comprobar que al imputar una actividad se puede cerrar una tarea
OK
Comprobar que al imputar una actividad se puede mantener abierta una tarea
OK
Comprobar que se crean las notificaciones correspondientes al cerrar una tarea
OK
Comprobar la relación en base de datos entre la tarea y la actividad al imputar una actividad
OK
Comprobar que no se pueden imputar actividades en tareas cerradas
OK
Comprobar que se pueden consultar las actividades imputadas en un proyecto
OK
Comprobar que se pueden consultar los detalles de una actividad OK
Comprobar que se puede eliminar una actividad de una tarea no cerrada
OK
Comprobar que no se pueden eliminar las actividades de una tarea cerrada
OK
Comprobar que se notifican las actividades eliminadas al responsable del proyecto
OK
Comprobar que se pueden editar los datos de una actividad independientemente de que su tarea esté o no cerrada
OK
Comprobar que se notifican los cambios en actividades al responsable del proyecto
OK
8.1.3 Plan del proyecto
TEST-CASE PASOS RESULTADO
FrmPlanProyecto Comprobar que se incrementa el tiempo real de una fase al imputar nuevas actividades
OK
Comprobar que se incrementan los porcentajes de una fase al imputar nuevas actividades
OK
Comprobar que se modifican los tiempos y porcentajes de una fase al editar las horas imputadas en una actividad
OK
Comprobar que el resumen del plan del proyecto es coherente con cada una de las fases del proyecto
OK
Comprobar que los datos mostrados para cada fase coinciden con las actividades imputadas en la misma
OK
Trabajo Fin de Grado Página 41
9. Seguimiento y control hasta la 2ª iteración En la siguiente tabla se puede apreciar las diferencias entre el tiempo planificado al final de la
primera iteración y el tiempo real invertido para cada tarea.
Nombre de tarea Tiempo Planificado Tiempo Real Diferencia
SEGUIMIENTO Y CONTROL 14 horas 14 horas 0 horas
ITERACIÓN 2 150 horas 146 horas 4 horas
ANÁLISIS 2 25 horas 13 horas 12 horas
Requisitos funcionales 15 horas 10 horas 5 hora
Requisitos no funcionales 5 hora 1 hora 4 horas
interfaces 5 hora 2 horas 3 horas
DISEÑO 2 10 horas 6 horas 4 horas
Modelo de Clases 5 horas 3 horas 2 horas
Modelo de datos 5 horas 3 horas 2 horas
IMPLEMENTACIÓN 2 115 horas 127 horas 12 horas
Generar Código 100 horas 110 horas 10 horas
Pruebas 15 horas 17 horas 2 horas
Unitarias 5 horas 8 horas 3 horas
Integración 3 horas 4 horas 1 horas
Sistema 3 horas 1 hora 2 horas
Aceptación 4 horas 4 horas 0 horas
IMPLANTACIÓN 5 horas 4 horas 1 horas
Manual de Usuario 3 horas 3 horas 0 horas
Instalación 2 hora 1 hora 1 horas
DEFENSA 5 horas 5 horas 0 horas
Preparación 4 horas 4 horas 0 horas
Presentación 1 hora 1 hora 0 horas
Trabajo Fin de Grado Página 42
El siguiente diagrama muestra el resultado final del cronograma una vez actualizadas las fechas
reales en las que se ejecutó cada tarea planificada.
Trabajo Fin de Grado Página 43
El siguiente gráfico muestra la relación entre el tiempo planificado y el tiempo real invertido en
la segunda iteración.
Como se puede apreciar en la gráfica, las estimaciones hechas en el seguimiento y control
realizadas al final de la primera iteración fueron bastante exactas.
Las desviaciones más significativas las podemos encontrar en la fase de análisis 2, en la que se
invirtió menos tiempo del planificado y en la fase de implementación 2, en la que hicieron falta
10 horas más para terminar las tareas planificadas.
En general se puede afirmar que las estimaciones se han normalizado en esta segunda
planificación, lo cual suele ocurrir en la mayoría de los proyectos, ya que al inicio del proyecto,
las estimaciones se basan más en la intuición que en datos reales.
El balance final del proyecto es de 301,5 horas reales invertidas, lo cual cumple con los
parámetros marcados para el desarrollo del trabajo de fin de grado.
0
20
40
60
80
100
120
140
Tiempo Planificado
Tiempo Real
Trabajo Fin de Grado Página 44
10. Conclusiones
10.1 Posibles ampliaciones del sistema Como posibles ampliaciones en el proyecto, se podría establecer un tercer módulo que
incluya:
Gestión de la calidad del software implementado
Para gestionar, asegurar y controlar la calidad nos centraremos en una técnica estática
(no implica ejecución del software), las inspecciones software:
o Inspecciones software: el objetivo es detectar e identificar defectos de un
producto para:
Verificar que el producto satisface sus especificaciones.
Verificar que el producto se ajusta a los estándares aplicables.
Identificar las desviaciones de los estándares y las especificaciones.
Recoger los datos de defectos y de esfuerzo.
Y un cuarto módulo:
Mejora del proceso software
Consiste en evaluar los procesos que siguen los proyectos, para ello recopilaremos
datos mediante cuestionarios y analizaremos los resultados mediante informes
presentados a los participantes de cada proyecto.
Este sistema de reporting permitiría a los analistas de los proyecto evaluar el
rendimiento de cada uno de los empleados además de mejorar las estimaciones de
cada jefe de proyecto, posibilitando que la planificación y la previsión en la
organización mejoren de forma significativa y se reduzcan los costes derivados por
falta de previsión en los proyectos.
Estos dos módulos estarían encaminados en la línea de mejorar la calidad del software
implementado en nuestros proyectos, por lo que tendría sentido introducirlos en la aplicación
después de un tiempo de uso y una metodología de trabajo definida para la herramienta.
Trabajo Fin de Grado Página 45
10.2 Opinión personal
El desarrollo de este proyecto me ha servido para abordar una idea concebida durante mi
carrera profesional. La temática que aborda es realmente interesante ya que aplica conceptos
teóricos estudiados durante la carrera sobre problemas reales surgidos en el día a día de un
programador.
Al tratarse de mi segundo proyecto de fin de carrera, he podido imprimir un carácter más
personal e independiente a la hora de plantear soluciones. Esta independencia intelectual
también se debe en parte a la experiencia profesional que he adquirido desde que finalicé la
ingeniería técnica, permitiéndome centrarme durante el desarrollo del proyecto en las
posibles soluciones aplicables al problema en lugar de tener que investigar la metodología
necesaria para implementar las soluciones, tal y como me sucedió en el primer proyecto.
Desde un punto de vista profesional, terminar este proyecto supone la culminación de una
etapa académica que me enriquece a nivel curricular y me permite mirar hacia delante en mi
trayectoria profesional.
A nivel académico estoy satisfecho de los conocimientos adquiridos y el nivel de exigencia
requerido para superar los créditos necesarios para la obtención del título.
Finalmente me gustaría agradecer el apoyo mostrado al director de mi proyecto, ya que su
ayuda y consejos han resultado decisivos para el éxito de este proyecto.
Trabajo Fin de Grado Página 46
Anexo 1: Manual de usuario
1. Introducción Este manual trata de explicar el funcionamiento de la aplicación. Dicha aplicación está
diseñada para gestionar los proyectos en desarrollo de una empresa de software. El objetivo
del manual es obtener el mayor rendimiento de la aplicación y mejorar las condiciones de uso
del usuario para facilitar su labor de gestión.
2. Inicio de Sesión Al iniciar la aplicación el usuario deberá introducir sus datos de conexión en la siguiente
ventana:
Los datos de conexión (Usuario y Contraseña) son proporcionados por la organización a cada
usuario de la aplicación.
Para la asignación del nombre de usuario se utiliza una nomenclatura basada en la primera
letra del nombre seguida del apellido (Ejemplo: Eneko Valladares evalladares). Esta
nomenclatura facilita al usuario la tarea de tener que recordar sus datos de conexión además
de facilitar la identificación de otros login de usuario que son utilizados en la aplicación para
hacer referencia a los empleados.
Trabajo Fin de Grado Página 47
3. Pantalla principal Después de iniciar sesión, el usuario se encuentra con la pantalla principal, desde la cual puede
gestionar todas las opciones accesibles en la aplicación.
3.1 Funciones de carácter general
En la parte superior izquierda, en la barra de herramientas de la aplicación, podemos
encontrar las funciones de carácter general. Estas funciones son independientes del proyecto
seleccionado en el panel de búsqueda de proyectos, ya que ofrecen información común a
todos los proyectos en los que interviene el usuario de la aplicación.
Las funciones son las siguientes:
Nuevo proyecto: permite al usuario crear un nuevo proyecto en la aplicación.
Notificaciones: permite al usuario consultar las notificaciones recibidas.
Calendario: permite al usuario consultar las fechas correspondientes a las fases de los
proyectos en los que participa.
Actividades: esta funcionalidad permite al usuario gestionar la actividad relacionada
con las tareas asignadas en los proyectos en los que participa.
Trabajo Fin de Grado Página 48
3.2 Funciones de proyecto
El resto de botones de la barra de herramientas se corresponden con funcionalidades
particulares para cada proyecto. Al desplegar cada una de estas funcionalidades, en la pantalla
principal se mostrarán los datos del proyecto que esté seleccionado en el panel de proyectos.
Las funcionalidades de proyecto son las siguientes:
Plan del proyecto: esta funcionalidad nos permite acceder al resumen del plan del
proyecto, que nos permitirá controlar el avance de cada proyecto.
Participaciones: esta función permite al usuario consultar y gestionar las
participaciones de los empleados en cada uno de los proyectos.
Requisitos: mediante esta función el usuario puede consultar y gestionar los requisitos
definidos en un proyecto.
Peticiones: esta función permite al usuario consultar e intervenir en el proceso de
petición de cambio de los requisitos de un proyecto.
Tareas: esta función permite consultar al usuario las tareas definidas en un proyecto
en el que participa.
3.3 Área de notificaciones
El área de notificaciones informa al usuario de las nuevas notificaciones recibidas según su
categoría. Al recibir una nueva notificación el contador se incrementará. Análogamente, al leer
cada nueva notificación recibida, el contador disminuirá.
Hay definidas cuatro categorías de notificación según su contenido:
Calendario: este tipo de notificaciones informan acerca de los eventos estimados y
producidos en las fases de un proyecto.
Asignaciones: informan al usuario acerca de su relación e intervención en cada uno de
los proyectos.
Requisitos: notifican al usuario las definiciones y cambios en los requisitos relativos a
los proyectos en los que participa.
Peticiones: informan acerca del proceso de petición de cambio de los requisitos
definidos en los proyectos.
Trabajo Fin de Grado Página 49
3.4 Panel de búsqueda de proyectos
En la parte izquierda de la aplicación el usuario dispone de un panel para poder localizar y
seleccionar un proyecto determinado.
Para buscar un proyecto concreto el usuario debe escribir en la caja de texto el código o el
nombre del proyecto y al pulsar la tecla ENTER o el botón con la lupa; se mostrarán en el panel
todas las coincidencias encontradas para el texto introducido.
Los resultados están limitados a 10 coincidencias, de modo que si hay más de 10 proyectos
coincidentes, los resultados aparecerán paginados.
El usuario puede desplazarse por cada página utilizando los botones de paginación o mediante
las flechas y del teclado o pulsando en los botones de paginación que aparecen en la
parte inferior del panel.
El usuario también puede desplazarse por cada proyecto mostrado en el panel haciendo clic en
cada proyecto o utilizando las flechas ↑ y ↓ del teclado.
Trabajo Fin de Grado Página 50
3.5 Área de despliegue de funcionalidad
En el área de despliegue de funcionalidad, que al iniciar la aplicación aparece en gris, se
mostrarán los formularios correspondientes a cada funcionalidad seleccionada. De modo que
es en esta área donde el usuario trabajará con la aplicación.
3.6 Barra de estado
En la parte inferior de la aplicación se localiza la barra de estado, que proporciona información
sobre el usuario correspondiente a la sesión iniciada.
La información que proporciona es:
Login de usuario
Categoría profesional
Departamento
Trabajo Fin de Grado Página 51
4. Crear un nuevo proyecto Para crear un nuevo proyecto en la aplicación, el usuario debe pulsar el botón nuevo proyecto:
Al desplegar esta funcionalidad se mostrará un asistente que el usuario tendrá que rellenar
con información relativa al proyecto que quiere crear. Este asistente, dispone de un total de 3
pasos para poder crear el proyecto:
(1) Información general
En este primer paso el usuario debe completar información general del proyecto:
Código del proyecto (Campo obligatorio)
Nombre del proyecto (Campo obligatorio)
Descripción (Campo obligatorio)
Fecha de inicio del proyecto (por defecto la fecha actual)
Prioridad asignada al proyecto (por defecto urgente)
Una vez completado el formulario basta con pulsar el botón siguiente para ir al paso 2.
Trabajo Fin de Grado Página 52
(2) Participantes del proyecto
En este paso el usuario debe añadir los participantes del proyecto con sus respectivos
roles. Mediante el botón “+” el usuario puede ir añadiendo cada participante, rol
asignado y fecha de inicio en el proyecto.
Trabajo Fin de Grado Página 53
(3) Fases
En el tercer y último paso del asistente, el usuario debe informar acerca de las fechas
estimadas para cada fase del proyecto. Estas fases servirán para que los participantes
del proyecto sean conscientes de los plazos marcados en el proyecto y puedan
planificar su trabajo acorde a las fechas manejadas en cada proyecto.
Las fechas informadas para cada fase deben estar en orden cronológico, de modo que
cada fecha estimada sea mayor o igual que la de la anterior fase.
Una vez completa esta información, el usuario debe pulsar finalizar para que se cree el
proyecto y la aplicación se encargará de enviar las notificaciones correspondientes a
cada participante del proyecto con la información correspondiente a cada asignación y
fase del proyecto.
Trabajo Fin de Grado Página 54
5. Consultar notificaciones
Para consultar las notificaciones recibidas el usuario debe pulsar el botón de notificaciones.
Al pulsar este botón se mostrará un formulario de consulta en el área principal de la aplicación,
mostrando por defecto todas las notificaciones recibidas por el usuario en orden descendente
de fecha.
El usuario tiene la posibilidad de filtrar las notificaciones del usuario y mostrar: todas las
notificaciones, notificaciones marcadas como leídas o notificaciones marcadas como no leídas
mediante la lista desplegable que aparece en la parte inferior izquierda del formulario.
Le usuario tiene la posibilidad de eliminar, marcar como leídas o como no leídas una o más
notificaciones. Para hacerlo, debe seleccionar las notificaciones que le interesen haciendo clic
en la primera casilla (checkbox) de cada notificación. Una vez seleccionadas, podrá ejecutar la
función que desee mediante los botones que aparecen en la parte inferior derecha del
formulario.
Trabajo Fin de Grado Página 55
Para consultar los detalles de una notificación basta con pulsar el botón ver que aparece a la
derecha de cada notificación y se abrirá el formulario con la información en detalle.
En este formulario aparece la siguiente información:
Identificador de la notificación
Texto
Fecha de envío
Fecha de recepción
Tipo de notificación
Si la notificación elegida para ver el detalle es una notificación marcada como no leída, al
pulsar el botón ver se marcará como leída.
6. Consultar el calendario
Mediante esta opción, el usuario puede gestionar las fases estimadas para cada proyecto, de
forma que al pulsar el botón calendario, se muestre en el área principal de la aplicación un
formulario con un calendario y la información de cada fase de los proyectos en los que
interviene el usuario.
Trabajo Fin de Grado Página 56
Al abrirse el formulario, por defecto aparecerá el mes actual; el usuario puede moverse y
consultar la información de los diferentes meses utilizando las flechas de desplazamiento del
calendario. Al cambiar el mes se modificará la información de la lista, mostrando aquellas fases
estimadas/confirmadas en el mes de consulta.
Para cada fase el usuario puede retrasar la fecha de inicio o confirmar la finalización de la fase
si ésta no lo está. Al retrasar una fecha estimada se abrirá un formulario mediante el cual el
usuario podrá cambiar la fecha estimada.
Al finalizar una fase se enviará una notificación a cada participante del proyecto informando
del cambio de fase.
Trabajo Fin de Grado Página 57
7. Consulta de hojas de actividad
Esta opción permite al usuario consultar el detalle de cada una de las actividades imputadas a
cada proyecto; distinguiendo por proyecto, tipo de actividad, departamentos y empleados,
todo ello distribuido por meses.
El usuario dispone de una serie de listados desplegables que permiten filtrar las actividades
mostradas en la lista. El calendario de la parte derecha permite elegir el periodo temporal de
las actividades mostradas.
En la parte inferior aparece el acumulado de horas mostradas para el mes y opciones de
búsqueda elegidas.
Trabajo Fin de Grado Página 58
8. Plan de proyecto
El plan del proyecto permite al usuario consultar la situación de un proyecto concreto.
Entre otros datos mostrados el formulario presenta:
Tiempo estimado en la planificación Vs. tiempo completado hasta la fecha
Nº de tareas definidas Vs Completadas
Nº de requisitos definidos en el proyecto Vs. Requisitos implementados
Nº de peticiones de cambio solicitadas Vs. Solicitudes implementadas
Distribución de participantes en el proyecto por categoría profesional
Días transcurridos desde el inicio del proyecto
Días transcurridos desde el inicio de la fase actual
Nº de notificaciones generadas en el proyecto
Nº de actividades imputadas por los empleados en el proyecto
Trabajo Fin de Grado Página 59
9. Participantes de un proyecto
Esta opción permite al usuario consultar y gestionar las participaciones de un proyecto.
Al pulsar el botón participaciones se despliega en el área principal la información de cada
participante en el proyecto mostrando, la fecha en la que se inició la participación, la fecha de
finalización de la participación en el proyecto, el rol desempeñado y el login.
Para cada participación la aplicación permitirá finalizar la participación o eliminarla del
proyecto.
El botón nuevo permite agregar nuevas participaciones al proyecto del mismo modo que
ocurría en el paso 2 del asistente para la creación de nuevos proyectos.
Trabajo Fin de Grado Página 60
10. Requisitos de un proyecto
El botón requisitos permite al usuario gestionar los requisitos definidos en un proyecto de la
aplicación.
El formulario desplegado muestra una lista con los requisitos definidos en el proyecto, y para
cada requisito, en la parte lateral derecha, las versiones definidas en cada requisito.
La lista desplegable de la parte inferior permite al usuario filtrar la lista de requisitos
dependiendo del estado en el que se encuentren éstos.
Finalmente, el formulario dispone de los botones para gestionar los cambios de estado de un
requisito; éstos estarán activados o desactivados dependiendo del estado actual del requisito
seleccionado y del usuario que este gestionando el requisito.
Trabajo Fin de Grado Página 61
Verificar: únicamente estará disponible cuando el requisito se encuentre en estado
implementado y servirá para marcar el requisito como verificado.
Anular: este botón estará disponible para anular un requisito siempre que éste no esté en
estado anulado.
Rechazar/Aprobar: este botón permite aprobar o rechazar un requisito propuesto en el
proyecto.
Cambio: mediante este botón el usuario puede gestionar una petición de cambio para el
requisito seleccionado. Al pulsar este botón se despliega un formulario para cumplimentar los
detalles de una petición.
Una vez cumplimentado el formulario el usuario debe pulsar el botón guardar para publicar la
solicitud de cambio. Después, cada participante del proyecto recibirá una notificación
informándole acerca de la nueva petición de cambio.
Trabajo Fin de Grado Página 62
Mediante el botón nuevo, el usuario puede proponer un nuevo requisito en el proyecto.
11. Peticiones de cambio
Este botón permite desplegar en el área principal de la aplicación el formulario
correspondiente a la gestión de peticiones de cambio de requisitos del proyecto.
Trabajo Fin de Grado Página 63
En el formulario se muestra una lista con todas las peticiones de cambio del proyecto.
El usuario puede consultar los detalles de una petición concreta pulsando el botón ver que
aparece a la derecha de la petición.
En la parte inferior del formulario el usuario dispone de una lista desplegable para filtrar la lista
de las peticiones de cambio dependiendo del estado actual de cada petición.
Trabajo Fin de Grado Página 64
En la parte inferior derecha del formulario el usuario dispone de los botones correspondientes
para gestionar el estado de cada petición en curso.
Anular: este botón permite al usuario anular una petición de cambio propuesta.
Cerrar: este botón permite cerrar una petición de cambio que ha sido realizada.
Verificar: mediante esta opción el verificador asignado a la petición puede marcar la petición
como verificada.
Cancelar: este botón permite al usuario cancelar una petición realizada y verificada.
Diferir: este botón permite cambiar el estado de una petición a diferida.
Aprobar/Rechazar: mediante estos botones el usuario puede aprobar o rechazar una petición
de cambio propuesta.
12. Tareas
En esta sección los usuarios pueden consultar las tareas asignadas e imputar actividades a cada
tarea.
Trabajo Fin de Grado Página 65
Para imputar una actividad el usuario debe pulsar sobre el botón con el reloj en la tarea en la
que quiere imputar actividades.
Una vez rellenado el formulario de actividad el usuario tiene dos opciones:
Imputar la actividad y mantener abierta la tarea.
Imputar la actividad y cerrar la tarea.
Si el usuario elige la opción de cerrar la tarea no se podrán imputar más actividades en esta
tarea.
Trabajo Fin de Grado Página 66
Anexo 2: Actas de las reuniones
Acta de la reunión 1
Lugar: Edificio Vives, despacho nº 217; Universidad de La Rioja (Logroño)
Fecha: 15 – Febrero – 2013
Hora: 16:30 – 19:00
Asistentes
Don Arturo Jaime Elizondo
Don Eneko Valladares Reyes
Asunto
Reunión inicial del proyecto.
Orden del día
Análisis inicial del proyecto.
Elección de una estrategia a seguir en el proyecto.
Elección de las formas de comunicación del proyecto.
Análisis del calendario disponible para el desarrollo del proyecto.
Desarrollo
Exposición inicial de la idea del proyecto.
Se acuerda seguir como orientación las directrices fijadas en PMBOK.
Se acuerda comunicación mediante correo electrónico.
Se fija una fecha para la próxima reunión.
Trabajo Fin de Grado Página 67
Acta de la reunión 2
Lugar: Edificio Vives, despacho nº 217; Universidad de La Rioja (Logroño)
Fecha: 19 – Abril – 2013
Hora: 18:00 – 19:30
Asistentes
Don Arturo Jaime Elizondo
Don Eneko Valladares Reyes
Asunto
Reunión con motivo del seguimiento y control del avance del proyecto (Hito 1).
Orden del día
Análisis de la documentación del proyecto correspondiente a la primera iteración.
Demostración de la aplicación.
Análisis del desarrollo pendiente en la segunda iteración del proyecto.
Desarrollo
Lectura rápida de la documentación correspondiente a la primera iteración del proyecto.
Anotaciones y correcciones en la documentación del proyecto.
Demostración del funcionamiento desarrollado hasta la fecha en la aplicación.
Análisis conjunto de la segunda iteración del proyecto.
Se acuerda una fecha para la próxima reunión en la que se evaluará el avance final del
proyecto.
Trabajo Fin de Grado Página 68
Acta de la reunión 3
Lugar: Edificio Vives, despacho nº 217; Universidad de La Rioja (Logroño)
Fecha: 30 – Mayo – 2013
Hora: 19:00 – 20:00
Asistentes
Don Arturo Jaime Elizondo
Don Eneko Valladares Reyes
Asunto
Reunión con motivo del seguimiento y control de la segunda iteración del proyecto.
Orden del día
Análisis de la documentación del proyecto correspondiente a la segunda iteración.
Análisis de temas pendientes en el proyecto.
Desarrollo
Lectura conjunta de la documentación del proyecto.
Análisis y revisión de defectos de la memoria.
Balance final del proyecto.