Gestión del proceso software - Biblioteca de la ... · Gestión del proceso software, trabajo fin...

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)


Í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


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


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


Orden del día ....................................................................................................................... 66

Desarrollo ............................................................................................................................ 66


Asistentes ............................................................................................................................ 67

Asunto ................................................................................................................................. 67

Orden del día ....................................................................................................................... 67

Desarrollo ............................................................................................................................ 67


Asistentes ............................................................................................................................ 68

Asunto ................................................................................................................................. 68

Orden del día ....................................................................................................................... 68

Desarrollo ............................................................................................................................ 68


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.


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.


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.


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.


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


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


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


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.


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.


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.


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.


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.


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.


Á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


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.


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.


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).


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.


3.3.2 Diagrama de clases básicas

El siguiente diagrama representa el modelo que componen las clases básicas de la aplicación.


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.


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


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


4.2.3 Búsqueda de un proyecto concreto


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


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


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


4.2.6 Gestión de requisitos


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


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


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


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


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


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.


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


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.


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.


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).


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.


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.


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


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


8.1.2 Gestión de actividades


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


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


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


El siguiente diagrama muestra el resultado final del cronograma una vez actualizadas las fechas

reales en las que se ejecutó cada tarea planificada.


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


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.


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.


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.


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.


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.


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.


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


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.


(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.


(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.


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.


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.


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.


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.


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


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.


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.


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.


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.


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.


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.


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.


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.




Fecha: 19 – Abril – 2013

Hora: 18:00 – 19:30

Asistentes



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.




Fecha: 30 – Mayo – 2013

Hora: 19:00 – 20:00

Asistentes



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.

Gestión del proceso software - Biblioteca de la ... · Gestión del proceso software, trabajo fin...

Documents

Transcript of Gestión del proceso software - Biblioteca de la ... · Gestión del proceso software, trabajo fin...