herramienta para la gestión de las tareas, reuniones y ... · p.1.2. creación de la memoria 20...

David Rueda Lejárraga

Beatriz Pérez Valle

Máster universitario en Tecnologías Informáticas

2015-2016

Título

Director/es

Facultad

Titulación

Departamento

TRABAJO FIN DE ESTUDIOS

Curso Académico

Herramienta para la gestión de las tareas, reuniones yprocesos principales de Garnica

Autor/es

© El autor© Universidad de La Rioja, Servicio de Publicaciones,

publicaciones.unirioja.esE-mail: [email protected]

Herramienta para la gestión de las tareas, reuniones y procesos principales deGarnica, trabajo fin de estudios

de David Rueda Lejárraga, dirigido por Beatriz Pérez Valle (publicado por la Universidad deLa Rioja), se difunde bajo una Licencia

Creative 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 de Fin de Máster

Herramienta para la gestión de las tareas, reuniones y

procesos principales de Garnica

Autor:

David Rueda Lejárraga

Tutor/es: Beatriz Perez Valle

MÁSTER:

Máster en Tecnologías Informáticas (853M)

Escuela de Máster y Doctorado

AÑO ACADÉMICO: 2015/2016

Resumen

En el trabajo que se presenta en esta memoria se describe el desarrollo de

una aplicación de escritorio desarrollada para la empresa Grupo Garnica

Plywood S.A. Dicha herramienta permitirá gestionar tanto la información

relacionada con los procesos principales de oficina que se tratan en la empresa,

como las reuniones llevadas a cabo por sus empleados.

Abstract

This report describes the development of a desktop application for Grupo

Garnica Plywood described S.A. This application allows to handle both the

information related to office processes used in the company,, as well as, the

meetings held by its employees.

1 de 61

Contenido 1. DOCUMENTO DE OBJETIVOS DEL PROYECTO .................................. 3

1.1. INTRODUCCIÓN Y ANTECEDENTES .............................................................. 3

1.1.1. Acerca de Garnica ............................................................................ 3

1.1.2. Motivación .......................................................................................... 3

1.2. ALCANCE .................................................................................................... 4

1.3. PLANIFICACIÓN DEL PROYECTO ................................................................. 5

1.3.1. EDT ..................................................................................................... 5

1.3.2. Estudio de horas ............................................................................... 6

1.3.3. Calendario de trabajo....................................................................... 6

1.4. PLAN DE RIESGOS....................................................................................... 8

1.5. METODOLOGÍA.......................................................................................... 10

2. ANÁLISIS ....................................................................................................... 11

2.1. CAPTURA DE REQUISITOS......................................................................... 11

2.1.1. Requisitos funcionales ................................................................... 11

2.1.2. Requisitos no funcionales.............................................................. 12

2.2. DIAGRAMAS DE CASOS DE USOS.............................................................. 12

2.2.1. Diagrama de casos de uso............................................................ 13

2.2.2. Especificación de casos de uso ................................................... 13

2.3. TECNOLOGÍAS A UTILIZAR ........................................................................ 23

2.4. PLAN DE PRUEBAS.................................................................................... 23

3. DISEÑO .......................................................................................................... 25

3.1. PROTOTIPOS DE LA INTERFAZ .................................................................. 25

3.2. ARQUITECTURA DEL SISTEMA .................................................................. 34

3.3. DISEÑO DE LA BASE DE DATOS ................................................................ 35

3.3.1. Diagrama Entidad-Relación .......................................................... 35

3.3.2. Diseño lógico ................................................................................... 37

3.4. MODELO DE DOMINIO................................................................................ 38

4. IMPLEMENTACIÓN ..................................................................................... 41

4.1. ESTRUCTURA DE LA APLICACIÓN ............................................................. 41

4.2. COMPONENTES Y TÉCNICAS UTILIZADOS ................................................ 42

2 de 61

4.2.1. Syncfusion........................................................................................ 42

4.2.2. ADO.NET ......................................................................................... 46

4.2.3. Consultas recursivas ...................................................................... 47

4.3. IMPLEMENTACIÓN DE LA APLICACIÓN ...................................................... 49

4.3.1. Implementación de la BD .............................................................. 49

4.3.2. Implementación de la capa de persistencia ............................... 51

4.3.3. Implementación del modelo de dominio ..................................... 54

4.3.4. Implementación del modelo de negocio ..................................... 54

4.3.5. Implementación de la capa de presentación.............................. 55

5. PRUEBAS ...................................................................................................... 58

6. CONCLUSIONES Y GESTIÓN DEL PROYECTO .................................. 59

6.1. GESTIÓN DEL PROYECTO.......................................................................... 59

6.2. CONCLUSIONES ........................................................................................ 60

7. BIBLIOGRAFÍA............................................................................................. 61

Capítulo 1 - DOCUMENTACIÓN

3 de 61

1. DOCUMENTO DE OBJETIVOS DEL PROYECTO

Esta memoria recoge todos los aspectos más destacables del proyecto

“Herramienta para la gestión de las tareas, reuniones y procesos principales de

Garnica”, el cual ha sido desarrollado por David Rueda Lejárraga en la empresa

Grupo Garnica Plywood S.A. (a partir de ahora se referirá solamente como

Garnica).

1.1. INTRODUCCIÓN Y ANTECEDENTES

1.1.1. Acerca de Garnica

Garnica es una empresa que se dedica al contrachapado del chopo y que

posee fábricas en Baños de Rio Tobía, Valencia de Don Juan, Fuenmayor y

Samazan (Francia). Garnica cuenta con unos 900 empleados y es el primer

productor europeo en tableros contrachapados de chopo con más de 220.000

metros cúbicos de tableros al año, unos ingresos superiores a 140 millones de

euros al año y más de 600 clientes en 36 países.

1.1.2. Motivación

A principios de año Garnica decidió que quería mejorar la forma de trabajar

en sus procesos de oficina. Para ello se lanzó a implementar lean service1 en los

procesos principales de oficina. Para realizar una mejor implementación del lean

service, se contrató un consultor especializado en su implementación. Este

consultor guiaría a Garnica paso a paso en dicho proceso y le ayudaría en el

caso de aparecer problemas.

El objetivo principal que motivó la realización de este TFM fue facilitar la

implantación de dicho lean service mediante el desarrollo de una herramienta

que se encargara de facilitar a Garnica dicha implantación. Para ello, esta

herramienta permitirá diseñar, visualizar y editar gráficamente los procesos de

Garnica.

1 Mejorar la efectividad de los procesos administrativos y de soporte, en calidad, coste y plazo.


4 de 61

Otro motivo por el cual llevar a cabo este proyecto fue el gran número de

reuniones que se realizaban en Garnica. En particular, hasta ese momento el

proceso relacionado con la organización, redacción y creación de las futuras

tareas que fueran surgiendo de las reuniones se realizaban manualmente,

creándolas con Outlook, redactándolas en Word y marcando las tareas en un

Excel. Con este proyecto se pretende facilitar dicho proceso.

Por lo tanto, teniendo en cuenta lo anterior, se decidió emprender este

proyecto para solucionar ambos problemas y ayudar a los empleados de Garnica

en una parte de su trabajo.

1.2. ALCANCE

El alcance de este proyecto comprende la creación de una aplicación de

escritorio para sistemas Windows que permita conectarse a una BD, siempre

que se esté conectado a la subred de Garnica. Dicha aplicación permitirá

gestionar toda la información relacionada con las reuniones de los empleados de

Garnica y toda la información relacionada con los procesos principales de oficina.

Además, se incluirá la posibilidad de crear tareas que provengan de reuniones,

procesos, de ambas partes o de ninguna de ellas.

Así mismo, la aplicación deberá dar soporte al envío de reuniones a través del

Outlook de cada empleado, además permitirá exportar ciertos datos a formato

Excel.

El proyecto podría dividirse en tres partes. La parte de gestión de las

reuniones, en la cual se encuentra su creación y su listado. La parte de gestión

de procesos, en la que deberá existir un panel de administración que permita a

los usuarios modificarla información referente a los procesos principales de

oficina, así como crear nuevos procesos o eliminar alguno ya existente. Esta

opción solo deberá estar disponible para ciertos empleados de Garnica. Además,

dispondrá de una parte de gestión de tareas, las cuales podrán provenir de una

reunión, de un proceso, de ambas o de ninguna.


5 de 61

1.3. PLANIFICACIÓN DEL PROYECTO

Para poder dar respuesta a todos los requisitos, cumpliendo los plazos del

proyecto y sobre todo en un proyecto de este tamaño, deberemos realizar una

buena planificación.

1.3.1. EDT

Con objeto de realizar una correcta planificación del trabajo, lo primero que se

ha realizado es una Estructura de Descomposición del Trabajo (EDT). A

continuación, se muestra un diagrama con la estructura del proyecto y

posteriormente se pasa a describir cada una de las tareas que lo conforman.


6 de 61

1.3.2. Estudio de horas

Descripción y tiempo que se estima que será necesario dedicar a cada tarea.

Tarea Tiempo estimado (en horas)

P.1. Gestión del TFM 60

P.1.1. Seguimiento del TFM 5

P.1.2. Creación de la memoria 20

P.1.3. Planificación 13

P.1.4. Reuniones 7

P.1.5. Defensa 15

P.2. Análisis de requisitos 40

P.2.1. Captura de requisitos 20

P.2.2. Diagramas de casos de uso 20

P.3. Diseño 30

P.3.1. Diseño de la BD 10

P.3.2. Diseño de clases 10

P.3.3. Diseño de los prototipos 10

P.4. Implementación 155

P.4.1. Base de Datos 40

P.4.2. Capa de persistencia 40

P.4.3. Capa de lógica de negocio 30

P.4.4. Capa de presentación 45

P.5. Pruebas 15

P.5.1. Establecer el plan pruebas 5

P.5.2. Análisis de las pruebas 5

P.5.3 Realización de mejoras 5

Proyecto completo 300

1.3.3. Calendario de trabajo.

Se estima que para la realización del proyecto se dedicarán 300 horas desde

el 29 de marzo de 2016 hasta el 14 de julio de 2016.


7 de 61

Este proyecto se compatibilizará con el trabajo desarrollado como empleado

de Garnica, cuya dedicación ya está contemplada en la distribución de los

tiempos. Destacar que durante mi jornada laboral en Garnica no se realizará este

proyecto. El tiempo dedicado a este proyecto será durante las horas que no me

encuentre trabajando en la empresa.

Destacar la tarea de Gestión del TFM, la cual se extenderá durante todo el

transcurso del TFM. Solo se señalan con un color diferente los días en los que

se trabajará explícitamente en esa tarea.

Marzo Abril Mayo

L M X J V S D L M X J V S D L M X J V S D

1 2 3 4 5 6 1 2 3 1 2 3 4 1

7 8 9 10 11 12 13 4 5 6 7 8 9 10 2 3 4 5 6 7 8

14 15 16 17 18 19 20 11 12 13 14 15 16 17 9 10 11 12 13 14 15

21 22 23 24 25 26 27 18 19 20 21 22 23 24 16 17 18 19 20 21 22

28 29 30 31 27 28 25 26 27 28 29 30 29 23 24 25 26 27 28 29

30 31 30 31

Junio Julio

L M X J V S D L M X J V S D Gestión

1 2 3 4 5 1 2 3 Análisis

6 7 8 9 10 11 12 4 5 6 7 8 9 10 Diseño

13 14 15 16 17 18 19 11 12 13 14 15 16 17 Implementación

20 21 22 23 24 25 26 18 19 20 21 22 23 24 Pruebas

27 28 29 30 29 30 31 25 26 27 28 29 30 31 Inicio y Fin

Se procurará ceñirse en la medida de lo posible al tiempo estimado. Para

posibles contratiempos, se establecerá un plan de riesgos que se tendrá que

utilizar en dichas situaciones. A continuación, mostramos una tabla y el gráfico

asociado, en el que se muestra el peso correspondiente de cada tarea en

comparación con las demás:

Tarea Horas por tarea

Gestión del TFG 70

Análisis 30

Diseño 40

Implementación 140

Pruebas 20

Total 300

23%

10%

13%

47%

7%

Gestión del TFG

Análisis

Diseño

Implementación

Pruebas


8 de 61

En la siguiente imagen se muestra el diagrama de Gantt diseñado para la

realización del proyecto.

1.4. PLAN DE RIESGOS

Como se ha comentado anteriormente y para intentar evitar o solucionar los

problemas que puedan acontecer durante el desarrollo del proyecto de la mejor

manera posible, se ha creado un plan de riesgos. En particular, se han

identificado los posibles riesgos y un plan de dirección de riesgos a seguir para

cada uno de ellos.

Cambio de requisitos: se dará en el caso en el que los responsables de

soporte decidan añadir o cambiar cierta funcionalidad.

• Probabilidad: alta.

• Momento previsto: durante todo el desarrollo.

• Plan de dirección de riesgos: se estudiará la nueva funcionalidad y en

caso de ser factible se añadirá al proyecto.


9 de 61

Requisitos poco claros: puede darse en el caso de haber realizado una

descripción demasiado breve de algún requisito.


• Momento previsto: durante la etapa de análisis.

• Plan de dirección de riesgos: se revisará cuáles son los requisitos que

estén poco claros y se volverán a redactar para mejorar su descripción.

Errores de diseño, omisiones o malentendidos: durante cualquier etapa

del proyecto puede darse el caso de que los responsables de soporte puedan

detectar algo que no esté a su gusto.

• Probabilidad: baja.

• Momento previsto: durante todo el proyecto.

• Plan de dirección de riesgos: se volverá a la etapa correspondiente a

realizar los cambios necesarios.

Errores en la planificación: puede darse el caso de que la estimación de

tiempos no se ajuste lo suficiente a la realidad.

• Probabilidad: media.


• Plan de dirección de riesgos: si el tiempo de desfase fuera pequeño no se

implantará ningún plan de riesgos. En caso contrario, se volvería a

reajustar la planificación con nuevos tiempos.

Falta del desarrollador: puede darse el caso de que el alumno no pueda

realizar el proyecto debido a distintas causas (indisponibilidad, viajes…).



• Plan de dirección de riesgos: si el tiempo de indisponibilidad fuera

pequeño no se implantará ningún plan de riesgos. En caso de grandes

tiempos de indisponibilidad, se volverá a reajustar la planificación.


10 de 61

Falta del director del proyecto: puede darse el caso de que el director no

pueda reunirse debido a distintas causas (indisponibilidad, conferencias,

clases…).



• Plan de dirección de riesgos: para minimizar este problema, se mantendrá

al director del proyecto lo más al día posible, para minimizar el impacto en

el proyecto.

Fallo hardware: puede darse el caso de que falle el hardware del ordenador

del proyecto y se pierda toda la información del proyecto.

• Probabilidad: baja.


• Plan de dirección de riesgos: para evitarlos se utilizará un repositorio de

GitHub y se realizarán backup semanales por el sistema de seguridad de

Garnica.

Desconocimiento de ciertas herramientas: puede darse el caso de que el

alumno no sepa cómo utilizar alguna herramienta software de las necesarias

para el desarrollo del producto.



• Plan de dirección de riesgos: se buscarán manuales para facilitar su

aprendizaje.

1.5. METODOLOGÍA

Para conseguir un mejor control del proyecto se decidió utilizar la metodología

en cascada. Esta metodología es considerada como el enfoque clásico para el

ciclo de vida del desarrollo de sistemas, se puede decir que es un método puro

que implica un desarrollo rígido. Está es una secuencia de etapas que consisten

en el análisis de requerimientos, el diseño, la implementación, la integración y

las pruebas. Las principales ventajas son su sencillez, te permite tener el

proyecto bajo control y ayuda a entregar el proyecto a tiempo.

Capítulo 2 - ANALISIS

11 de 61

2. ANÁLISIS

El siguiente capítulo se centra en presentar los aspectos referentes al análisis

del proyecto.

2.1. CAPTURA DE REQUISITOS

Los requisitos describen los servicios que ha de ofrecer el sistema y las

restricciones asociadas a su funcionamiento. En esta sección analizaremos los

requisitos tanto funcionales como no funcionales de nuestra aplicación.

2.1.1. Requisitos funcionales

Los requisitos funcionales impuestos para la aplicación son:

R.1) La aplicación mostrará las tareas asociadas a cada usuario.

R.2) Las tareas podrán filtrarse según criterios.

R.3) Las tareas podrán exportarse en excel.

R.4) Las tareas podrán mostrarse en un calendario según su fecha de

finalización.

R.5) La aplicación permitirá crear tareas.

R.6) La aplicación permitirá crear reuniones.

R.7) La aplicación permitirá mostrar las reuniones de cada usuario.

R.8) Toda reunión deberá ir acompaña de una agenda.

R.9) Una reunión deberá tener invitados.

R.10) Una reunión podrá concebir distintas tareas.

R.11) Una reunión podrá incluir una lista de asistentes.

R.12) La aplicación podrá crear un acta para cada reunión finalizada.

R.13) Las reuniones podrán filtrarse según criterios.

R.14) La aplicación mostrará el Mapa de Procesos Principales de Garnica.

R.15) La aplicación mostrará el diagrama de cada proceso y sus

correspondientes datos.

R.16) La aplicación permitirá a usuarios avanzados editar el Mapa de Procesos

Principales de Garnica.

R.17) La aplicación permitirá a usuarios avanzados editar el diagrama de cada

proceso y sus correspondientes datos.

R.18) La aplicación permitirá a usuarios avanzados crear el diagrama de

procesos y sus correspondientes datos.

R.19) La aplicación mostrará todas las tareas de un proceso.

R.20) La aplicación permitirá filtrar según criterios las tareas de un proceso.


12 de 61

R.21) La aplicación permitirá mostrar estadísticas de las tareas de los procesos.

R.22) La aplicación permitirá crear tareas para ese proceso.

R.23) La aplicación permitirá imprimir el mapa de procesos.

R.24) La aplicación permitirá exportar el mapa de procesos.

R.25) La aplicación permitirá ver los datos de los empleados de Garnica.

R.26) La aplicación permitirá editar los datos propios de cada usuario.

2.1.2. Requisitos no funcionales

A continuación, se presentan los requisitos no funcionales que serán divididos

en cuatro grupos.

Requisitos del sistema operativo

La aplicación deberá funcionar correctamente en Windows 7 de 64 y de 32

bits.

Requisitos de disponibilidad

La aplicación deberá tener una disponibilidad de 24/7 semanales,

exceptuando los periodos de tiempo en los que se encuentre en mantenimiento.

Requerimientos de Soporte

Se documentará la aplicación con un manual de ayuda con el objetivo de

explicar el uso e instalación de la misma. Además, se debe crear el proyecto de

forma versionable para que permita realizar mantenimientos del mismo a fin de

aumentar las funcionalidades y/o corregir los errores del mismo. A través de

versiones posteriores se podrá continuar mejorando el proyecto.

Requerimientos de Seguridad

La información estará protegida contra accesos no autorizados, utilizando

mecanismos de validación.

2.2. DIAGRAMAS DE CASOS DE USOS

En esta sección presentaremos los diagramas de casos de uso del proyecto

y su respectiva especificación. También se han diseñado algunos diagramas de

actividad que debido a su sencillez no han sido incluidos en esta memoria.


13 de 61

2.2.1. Diagrama de casos de uso

Tras sendas reuniones con el cliente y en base a los requisitos funcionales

identificados, se ha detectado que la aplicación constará de dos actores, los

usuarios básicos y los usuarios avanzados. Todos los usuarios serán básicos a

excepción de los responsables de algún proyecto que asumirán el rol de usuario

avanzado. El diagrama de casos de uso es el siguiente:

2.2.2. Especificación de casos de uso

A continuación, vamos a mostrar la especificación de los casos de uso. La

descripción de cada caso de uso consta de un nombre, una pequeña descripción,

los actores que intervienen, los requisitos funcionales que cubre, una

precondición y postcondición un flujo básico y, en algunos casos, un flujo

alternativo. Como se ha comentado anteriormente, la aplicación constará de dos

actores que serán el usuario básico y el usuario avanzado.


14 de 61

Caso de uso Mostrar tareas

Descripción El usuario podrá ver todas sus tareas.

Actores Usuario básico.

Requisitos R.1

Precondiciones El usuario debe tener acceso a la aplicación.

Postcondiciones El usuario tendrá acceso a todas las tareas.

Flujo básico

1. El usuario deberá dirigirse al apartado “Tareas”.

2. El sistema mostrará todas las tareas de dicho usuario.

Flujo alternativo y excepciones

El usuario podrá hacer el caso de uso “Filtrar tareas”.

El usuario podrá hacer el caso de uso “Exportar tareas”.

El usuario podrá hacer el caso de uso “Ver tareas en calendario”.

Caso de uso Filtrar tareas

Descripción El usuario podrá filtrar las tareas para ver las que desee.


Requisitos R.2

Precondiciones El usuario está en el apartado “Tareas”.

Postcondiciones El usuario verá en pantalla aquellas tareas que le

interesen.

Flujo básico

1. El usuario deberá elegir unas características de las tareas y crear un

filtro con ellas

2. El sistema analizará dicho filtro y mostrará solo aquellas tareas que lo

cumplan.

Caso de uso Ver tareas en calendario

Descripción El usuario podrá las tareas en un calendario.


Requisitos R.4


Postcondiciones El usuario verá en pantalla un calendario con las tareas en

los días que terminan.

Flujo básico

1. El usuario elegirá la opción de ver tareas en calendario.

2. El sistema obtendrá todas las tareas del usuario y mostrará en el

calendario según la fecha de finalización de cada tarea.


15 de 61

Caso de uso Exportar tareas

Descripción El usuario podrá exportar las tareas en formato Excel.


Requisitos R.3


Postcondiciones El usuario obtendrá un archivo Excel con las tareas

indicadas.

Flujo básico

1. El usuario elegirá la opción de exportar tareas.

2. El sistema creará un archivo excel e incorporará todas las tareas que

tiene en la pantalla.

Caso de uso Crear tareas

Descripción El usuario podrá crear nuevas tareas.


Requisitos R.5


Postcondiciones El usuario creará una nueva tarea para un usuario.

Flujo básico

1. El usuario deberá dirigirse al apartado “Crear Tareas”.

2. El sistema mostrará un formulario con una serie de datos para la

creación de la tarea.

3. El usuario rellenará los campos del formulario.

4. El sistema validará los datos.

5. El sistema creará la tarea.

Caso de uso Crear agenda

Descripción El usuario podrá crear una agenda para una reunion.


Requisitos R.8

Precondiciones El usuario estará en el apartado de “Crear Reuniones”.

Postcondiciones El usuario creará una agenda para una reunión

especifica.

Flujo básico


creación de la agenda.


3. El sistema validará los datos y creará la agenda.


16 de 61

Caso de uso Crear reunión

Descripción El usuario podrá crear nuevas reuniones.


Requisitos R.6, R.10

Precondiciones El usuario está en el apartado “Reuniones”.

Postcondiciones El usuario creará una nueva reunión.

Flujo básico

1. El usuario deberá dirigirse al apartado “Crear Reuniones”.

2. El sistema mostrará una serie de datos para la creación de la reunión.


4. El usuario deberá hacer el caso de uso “Crear agenda”.

5. El usuario deberá hacer el caso de uso “Crear invitaciones”.


7. El sistema notificará de la reunión a los usuarios que estén invitados.

8. El sistema creará la reunión.


El usuario podrá hacer el caso de uso “Crear tareas”.

El usuario podrá hacer el caso de uso “Crear tareas”.

Caso de uso Mostrar reuniones

Descripción El usuario podrá ver todas sus reuniones.


Requisitos R.7


Postcondiciones El usuario tendrá acceso a todas sus reuniones.

Flujo básico

1. El usuario debe dirigirse al apartado de “Reuniones”.

2. El sistema mostrará todas las reuniones de dicho usuario.


El usuario podrá hacer el caso de uso “Crear acta”

El usuario podrá hacer el caso de uso “Filtrar reuniones”

El usuario podrá hacer el caso de uso “Crear tarea”

El usuario podrá hacer el caso de uso “Apuntar asistentes”


17 de 61

Caso de uso Crear invitaciones

Descripción El usuario podrá crear invitaciones para una reunión.


Requisitos R.9

Precondiciones El usuario estará en el apartado de “Crear Reuniones”.

Postcondiciones El usuario creará invitaciones para una reunión especifica.

Flujo básico

1. El sistema mostrara todos los usuarios del sistema.

2. El usuario elegirá a los usuarios que desea invitar.


4. El sistema creará las invitaciones.

Caso de uso Crear acta

Descripción El usuario podrá crear un acta para una reunión.


Requisitos R.12

Precondiciones El usuario estará en el apartado de “Reuniones”.

Postcondiciones El usuario creará un acta para una reunión especifica.

Flujo básico


creación del acta.


3. Ver caso de uso “Apuntar asistentes”

4. El sistema validará los datos y creará el acta.

Caso de uso Filtrar reuniones

Descripción El usuario podrá filtrar sus reuniones para ver las que

desee.


Requisitos R.13

Precondiciones El usuario está en el apartado “Reuniones”.

Postcondiciones El usuario verá en pantalla aquellas reuniones que le

interesen.

Flujo básico

1. El usuario deberá elegir unas características de las reuniones y crear

un filtro con ellas

2. El sistema analizará dicho filtro y mostrará solo aquellas reuniones que

lo cumplan.


18 de 61

Caso de uso Mostrar mapa de procesos

Descripción El usuario podrá ver el mapa de procesos principales

de Garnica.


Requisitos R.14


Postcondiciones El usuario tendrá acceso a al mapa de procesos

principales de Garnica.

Flujo básico

1. El usuario debe dirigirse al apartado de “Procesos”.

2. El sistema mostrará el mapa de procesos principales de Garnica.


El usuario podrá hacer el caso de uso “Mostrar proceso”

El usuario podrá hacer el caso de uso “Editar mapa de procesos”

El usuario podrá hacer el caso de uso “Exportar diagrama”

El usuario podrá hacer el caso de uso “Imprimir diagrama”

Caso de uso Mostrar proceso

Descripción El usuario podrá ver los detalles de un proceso de

Garnica.


Requisitos R.15

Precondiciones El usuario estará en el apartado de “Procesos”.

Postcondiciones El usuario tendrá acceso a todos los detalles del proceso

de Garnica.

Flujo básico

1. El usuario elegirá el proceso del cual ver los detalles.

2. El sistema mostrará todos los detalles del proceso de Garnica.


El usuario podrá hacer el caso de uso “Mostrar tareas del proceso”

El usuario podrá hacer el caso de uso “Editar proceso”

El usuario podrá hacer el caso de uso “Exportar diagrama”

El usuario podrá hacer el caso de uso “Imprimir diagrama”


19 de 61

Caso de uso Apuntar asistentes

Descripción El usuario podrá crear asistentes para una reunión.


Requisitos R.11

Precondiciones El usuario estará en el apartado de “Reuniones”.

Postcondiciones El usuario creará asistentes para un acta especifica.

Flujo básico

1. El sistema mostrara todos los usuarios del sistema.

2. El usuario elegirá a los usuarios que desea apuntar como asistente.


4. El sistema creará los asistentes.

Caso de uso Editar mapa de procesos

Descripción El usuario podrá editar mapa de procesos principales de

Garnica.

Actores Usuario avanzado.

Requisitos R.16

Precondiciones El usuario está en el apartado “Proceso”.

Postcondiciones El usuario tendrá permiso para modificar el mapa de

procesos principales de Garnica.

Flujo básico

1. El usuario debe dirigirse al apartado de “Procesos Avanzados”.

2. El sistema mostrará el mapa de procesos principales de Garnica.

3. El usuario podrá cambiar los datos del mapa de procesos.

4. El sistema validará los datos y guardará el nuevo mapa de procesos.

Caso de uso Crear procesos

Descripción El usuario podrá crear un proceso nuevo.


Requisitos R.18

Precondiciones El usuario está en el apartado “Proceso”.

Postcondiciones El usuario creará un nuevo proceso.

Flujo básico

1. El usuario deberá dirigirse al apartado “Crear procesos”.


creación del proceso.


4. El sistema validará los datos y creará el proceso.


20 de 61

Caso de uso Mostrar tareas del proceso

Descripción El usuario podrá ver todas las tareas asociadas a un

proceso.


Requisitos R.19

Precondiciones El usuario estará en el apartado de “Mostrar proceso”.

Postcondiciones El usuario creará una hoja de identificación para el

proceso especificado.

Flujo básico


creación de la hoja de identificación.



4. El sistema creará la hoja de identificación.


El usuario podrá hacer el caso de uso “Filtrar tareas proceso”

El usuario podrá hacer el caso de uso “Estadísticas tareas

proceso”

Caso de uso Editar proceso

Descripción El usuario podrá editar el diagrama.


Requisitos R.17

Precondiciones El usuario estará en el apartado de “Mostrar proceso”.

Postcondiciones El usuario podrá cambiar el diagrama del proceso y

guardar los cambiar realizados.

Flujo básico

1. El usuario deberá elegir la opción de editar proceso,

2. El sistema mostrará un formulario en una cuadricula editable.

3. El usuario podrá añadir nuevas formas, cambiar las viejas, y modificar

las que ya estaban.

4. Una vez terminados los cambios, el usuario deberá darle a guardar los

cambios.

5. El sistema actualiza el diagrama para ese proceso.


El usuario podrá hacer el caso de uso “Crear procesos”


21 de 61

Caso de uso Imprimir diagrama

Descripción El usuario imprimirá el diagrama.


Requisitos

implementados

R.23

Precondiciones El usuario estará en el apartado de “Mostrar proceso” o

“Mostrar mapa de procesos”.

Postcondiciones El usuario imprimirá en una de sus impresos un

diagrama.

Flujo básico

1. El usuario elegirá la opción de imprimir diagrama.

2. El sistema creará una vista previa de lo que se va a imprimir imagen del

diagrama.

3. El usuario indicará la impresora donde imprimir y la configurará a su

gusto.

Caso de uso Exportar diagrama

Descripción El usuario obtendrá una imagen del diagrama.


Requisitos R.24



Postcondiciones El usuario obtendrá la imagen del diagrama.

Flujo básico

1. El usuario elegirá la opción de exportar diagrama.

2. El usuario indicara la ruta, el nombre y el tipo de imagen.

3. El sistema creara imagen del diagrama.

Caso de uso Ver empleados

Descripción El usuario verá los datos de los empleados.


Requisitos R.25


Postcondiciones El usuario tendrá acceso a los datos de los empleados.

Flujo básico

1. El usuario deberá dirigirse al apartado “Empleados”.

2. El sistema mostrará todos los empleados.


22 de 61

Caso de uso Filtrar tareas proceso

Descripción El usuario obtendrá una lista de tareas según el filtro.


Requisitos R.20



Postcondiciones El usuario solo verá aquellas tareas que cumplan con

los requisitos del filtro

Flujo básico

1. El usuario deberá elegir unas características de las tareas y crear un

filtro con ellas

2. El sistema analizará los filtro y mostrará solo las tareas que lo cumplan.

Caso de uso Estadisticas tareas proceso

Descripción El usuario verá estadísticas de las tareas del proceso.


Requisitos R.21

Precondiciones El usuario estará en el apartado de “Mostrar tareas

proceso”.

Postcondiciones El usuario obtendrá dos graficas en la que se los

mostrarán las estadísticas del proceso.

Flujo básico

1. El usuario elegirá la opción de ver las estadísticas de las tareas del

proceso.

2. El sistema mostrará las estadísticas en dos gráficas.

Caso de uso Editar mis datos

Descripción El usuario modificará sus datos.


Requisitos R.26

Precondiciones El usuario estará en el apartado de “Ver empleados”.

Postcondiciones El usuario tendrá la posibilidad de actualizar sus datos en

la aplicación.

Flujo básico

1. El usuario deberá pulsar sobre su usuario.

2. El sistema mostrará sus datos.

3. El usuario modificará sus datos.

4. El sistema actualizará sus datos.


23 de 61

2.3. TECNOLOGÍAS A UTILIZAR

En el transcurso de este proyecto se utilizarán distintas herramientas y

lenguajes de programación, las cuales se muestran a continuación:

• Visual studio 2010: será necesario para la creación de la aplicación

escritorio.

• ADO.NET: será necesario para la conexión con la BD.

• Syncfusion: utilizado para obtener controles visuales más avanzados.

• Microsoft Office Word: utilizado para la creación de la documentación.

• Microsoft Office Visio: se utilizará para la creación de los casos de usos,

así como el diagrama de EDT y la creación de los prototipos.

• Microsoft Office Project: se utilizará para la creación de la planificación del

presente proyecto.

• C#: será el lenguaje más utilizado y será el encargado de la

implementación de la aplicación.

• WindowForms: será necesario para crear la interfaz de escritorio.

• T-SQL: este lenguaje será utilizado para la creación de la BD y de los

procedimientos almacenados en SQL Server.

Como comentario decir que el lenguaje de programación y el SGBD han sido

impuestos por la empresa, debido a que son utilizados por la misma.

2.4. PLAN DE PRUEBAS

Se ha creado un plan de pruebas que será utilizado en el proyecto. Este plan

será comprobado punto por punto, con objetivo de asegurarnos de que todo

funciona correctamente. En caso de detección de algún fallo, se pasará a su

corrección o mejora.

• Comprobar que solo pueden entrar los usuarios que se encuentran en el

directorio activo de Garnica.

• Comprobar que la lista de tareas es correcta para todos los usuarios.

• Comprobar que los usuarios no puedan ver las tareas de otros usuarios.

• Asegurar que todos los filtros de las tareas funcionan correctamente.

• Comprobar que no se permita crear tareas con datos incoherentes.


24 de 61

• Comprobar que la lista de reuniones es correcta para todos los usuarios.

• Comprobar que los usuarios no puedan ver las reuniones de otros

usuarios.

• Asegurar que todos los filtros de las reuniones funcionan correctamente.

• Comprobar que no permita crear reuniones con datos incoherentes.

• Comprobar que todos los usuarios básicos puedan ver el mapa de

proceso.

• Comprobar que solo los usuarios avanzados puedan editar el mapa de

procesos.

• Comprobar que todos los usuarios básicos puedan ver los detalles de los

procesos.

• Comprobar que solo los usuarios avanzados puedan crear procesos.

• Comprobar que no se permita crear procesos con datos incoherentes.

Capítulo 3 - DISEÑO

25 de 61

3. DISEÑO

En este apartado vamos a tratar los aspectos relacionados en el diseño de la

aplicación, tanto en lo que se refiere al diseño de los prototipos de la interfaz,

como al diseño de las clases del sistema y al diseño de la base de datos.

3.1. PROTOTIPOS DE LA INTERFAZ

Los prototipos de la aplicación han sido diseñados con el programa Visio,

utilizando la plantilla sketchGUIShapes, la cual nos ha facilitado bastante el

trabajo.

Para el diseño de los prototipos nos hemos basado en las explicaciones

iniciales expuestas por los empleados del Departamento de Sistemas de

Garnica. Además, durante todo el proceso, su diseño ha sido revisado y,

finalmente aprobado por los empleados de Garnica destinados para ello.

Página de Inicio: esta página se ejecutará al inicio de la aplicación.

Solamente nos mostrará el mensaje de bienvenida.


26 de 61

Página de Reuniones: esta página nos mostrará un listado de todas las

reuniones a las que estamos invitados. Podremos seleccionarlas y ver

todos sus detallas. En particular, se podrá ver su agenda, el acta, los

invitados, los asistentes, las tareas asociadas y sus indicadores. También

se podrá añadir el acta y sus asistentes en caso de no existir previamente.


27 de 61

Página de Tarea: en ella se nos mostrarán todas nuestras tareas en un

rango de fechas. Podremos seleccionar las tareas de un usuario y de un

tipo concreto. También nos dará la posibilidad de añadir más tareas

(Añadir Tareas), exportar en excel las que tenemos filtradas (Exportar a

Excel) y ver nuestras tareas en un calendario según su fecha de

finalización (Ver en Calendario).


28 de 61

Página de Tarea en Calendario: esta página mostrará las tareas del

usuario apuntadas en un calendario según su fecha de finalización.


29 de 61

Página de Empleados: esta página nos mostrará el listado de todos los

empleados que están registrados en la aplicación junto con sus detalles.

Si hacemos doble click sobre alguno de nuestros datos se abrirá una

pantalla que nos permitirá editar nuestros datos.


30 de 61

Página de Procesos: esta página nos mostrará el diagrama de procesos

y sus datos. Si somos un usuario avanzado podremos editar dicho

diagrama. Los usuarios básicos podrán imprimir y exportar en formato

imagen el diagrama. A demás, de ver las tareas del proceso.


31 de 61

Página de Editor Procesos: esta página nos permitirá dibujar los

diagramas de los procesos. Para ello deberemos añadir las diferentes

formas y editarlas a nuestro gusto. También se podrán crear nuevos

diagramas para otros procesos.


32 de 61

Página de Estadísticas Tareas Proceso: esta página nos mostrará dos

tipos de gráficos de las estadísticas de las tareas asociadas a un proceso.


33 de 61

Página de tareas de procesos: en esta página se nos mostrarán todas las

tareas de un proceso. Podremos realizar distintos filtros para solo ver

ciertas tareas. También se podrán añadir más tareas a un proceso (Añadir

Tarea). Exportar las tareas en un Excel (Exportar a Excel) y ver las

estadísticas de todas las tareas (Ver en Estadisticas).


34 de 61

3.2. ARQUITECTURA DEL SISTEMA

El sistema se basa en la arquitectura en 3 capas (presentación, negocio y

persistencia).

En lo que se refiere a la separación topológica o física de la aplicación, decir

que dispondremos de un servidor, en el cual se alojará la BD. El resto de la

aplicación se instalará en los ordenadores de los usuarios finales.

Capa de Presentación

Capa de persistenciaCapa de lógica de

Negocio

BD interna

Servidor de la BDEquipo del usuario

Capas (Separación lógica)

Topología (Separación física)

Cada capa tendrá una funcionalidad determinada:

Capa de presentación: la que interactuará con el usuario, presenta el

sistema al usuario, le comunica la información y captura la información del

usuario. Esta capa se comunica únicamente con la capa de negocio.

Capa de negocio: es donde se establecen todas las reglas de negocio

que deben cumplirse. Esta capa se comunica con la capa de

presentación, para recibir las solicitudes y presentar los resultados, y con

la capa de persistencia, para solicitar al gestor de base de datos

almacenar o recuperar datos de él. Estará formada por el modelo de

dominio, que refiere a las entidades propias del dominio de la aplicación,

y por el modelo de negocio, que corresponde a las entidades propias que

implementan la lógica de la aplicación, atendiendo a las reglas de negocio.

Capa de persistencia: es la encargada de acceder a la BD. En particular,

recibe las solicitudes de almacenamiento o recuperación de información

desde la capa de negocio.


35 de 61

3.3. DISEÑO DE LA BASE DE DATOS

La aplicación necesitará conectarse a una BD que almacenará la información

referente a los datos de las reuniones, tareas y los procesos. A continuación, se

muestra el diseño de dicha BD, en particular, su diagrama Entidad/Relación

(E/R).

3.3.1. Diagrama Entidad-Relación

En primer lugar, se mostrará el diagrama:


36 de 61

A continuación, se describen las entidades del sistema:

Reunion: Almacenará datos relacionados con las reuniones de los

empleados de Garnica. Estos datos serán utilizados para obtener

indicadores de cada reunión, con el objetivo de comprobar si han sido

productivas.

Agenda: esta entidad es la encargada de almacenar la Agenda de cada

Reunion. Se decidió no ponerla como un atributo de la entidad Reunion

porque no toda Reunion tiene que tener una Agenda y al ser un campo de

gran tamaño nos haría tener un gran desperdicio de espacio en la BD.

Acta: esta entidad es la encargada de almacenar el Acta de cada Reunion.

Se decidió no ponerla como un atributo de la entidad Reunion porque no

toda Reunion tiene que tener un Acta y al ser un campo de gran tamaño

nos haría tener un gran desperdicio de espacio en la BD.

Indicadores: Esta entidad almacenará los indicadores de cada reunión.

Los cuales se utilizarán para evaluar la productividad de cada reunión.

Tarea: es la entidad encargada de almacenar todas las tareas de los

empleados. Cada Tarea puede ser de un tipo distinto y dentro de una

tarea podremos tener otras subtareas.

Empleado: es la entidad encargada de almacenar distintos datos de los

empleados de Garnica.

Proceso: es la entidad encargada de almacenar la información de los

Procesos Principales de Garnica.

Diagrama: es la entidad que se encargara de almacenar el mapa de los

Procesos Principales. Al ser un campo enorme se decidió separar de la

entidad Proceso para hacerlo más eficiente.

Por otro lado, podemos identificar las siguientes relaciones entre las

entidades:

Las relaciones de Reunion con Agenda y Reunion con Acta es la

misma, ya que una Reunion puede tener cero o una Agenda/Acta y

una Agenda/Acta solo pertenece a una Reunion.

Toda Reunion tendrá unos indicadores y los Indicadores solo pueden

pertenecer a una Reunion.


37 de 61

Una Reunion puede crear Tareas y una Tarea puede pertenecer a una

Reunion.

Toda Reunion tendrá algún invitado y algún asistente, y los empleados

podrán ser invitados y asistentes de distintas reuniones.

Los Indicadores podrán ser vistos por ciertos Empleados y los

Empleados podrán ver Indicadores de ninguna o de muchas

Reuniones.

Cada Tarea deberá tener un responsable y un Empleado podrá ser

responsable de ninguna o de muchas Tareas.

Destacar que una Tarea podrá ser hija de una Tarea padre (esto

producirá una estructura de tipo árbol).

Cada Proceso deberá tener un responsable y un Empleado podrá ser

responsable de ninguno o de muchos Procesos.

Todo Diagrama pertenecerá a un Proceso y todo Proceso tendrá un

Diagrama.

3.3.2. Diseño lógico

A continuación, se muestra el diseño lógico normalizado para el diagrama E/R

definido anteriormente.

Reunion

Id Titulo Ubicación DuracionEstimada DuracionReal Fecha

Indicadores

Id NumTareas Asistencia Abandonadas Terminadas EnProceso IdReunion

CE:Reunion

Agenda

IdReunion Contenido

CE:Reunion

Acta

IdReunion Contenido

CE:Reunion

Invitado

IdReunion IdEmpleado

CE:Reunion CE: Empleado


38 de 61

Asistente

IdReunion IdEmpleado

CE:Reunion CE: Empleado

IndicadoresEmpleado

IdIndicadores IdEmpleado

CE:Indicadores CE: Empleado

Empleado

Usuario NombreCompleto Departamento Foto Telefono

Tarea

Id Estado Tipo TiempoDedicado FechaInicio FechaFin FechaEjecutado

Descripcion IdReponsable IdTareaPadre IdReunion IdProceso

CE:Empleado CE:Tarea CE:Reunion CE:Proceso

Proceso

Id Nombre Tipo IDResponsable

CE:Empleado

Diagrama

IdProceso Diagrama

CE:Proceso

3.4. MODELO DE DOMINIO

Como ya se ha comentado anteriormente, el proyecto contará con tres capas.

Cada capa solo podrá conectarse con la que tiene contigua. Además, la capa de

lógica de negocio estará formada por el modelo de negocio y por el modelo de

dominio. A continuación, se presenta el diagrama de paquetes.

En particular en la siguiente figura se muestra el diagrama de clases asociado

al modelo de dominio.


39 de 61


40 de 61

Capítulo 4 - IMPLEMENTACIÓN

41 de 61

4. IMPLEMENTACIÓN

En este apartado se tratarán los aspectos más relevantes de la fase de

implementación.

4.1. ESTRUCTURA DE LA APLICACIÓN

El lenguaje utilizado para la implementación de las capas de presentación,

lógica de negocio y persistencia es C#. Para ello hemos dividido la solución en

tres paquetes, los cuales corresponden a cada una de las capas.

En el paquete de Persistencia se encuentra solo una clase, en la cual se

han implementado los procesos que nos permitirán interactuar con la BD. En el

paquete de LogicaNegocio tenemos dos proyectos (Modelo y Negocio). En el

Modelo tenemos definidas todas las clases de la aplicación y en el Negocio

tenemos toda la Logica de la aplicación. Y por último, la Presentacion en la

cual solo tenemos un proyecto el cual posee todos las interfaces de la aplicación.

La comunicación entre las capas también cambia un poco respecto a la

explicada en la estructura en tres capas presentada anteriormente. A

continuación, se muestra las relaciones entre los diferentes proyectos que

forman la aplicación.


42 de 61

El motivo por el que se han realizado dichas separaciones y relaciones de

paquetes es por restricciones del lenguaje c#. Este lenguaje no trabaja bien

con referencias circulares y por tanto se decidió separar lógica de negocio en

dos paquetes distintos y solventar dicho problema.

4.2. COMPONENTES Y TÉCNICAS UTILIZADOS

Antes de empezar a realizar el desarrollo de la aplicación, se investigó la

existencia de librerías que podrían facilitar el desarrollo de la misma. A

continuación, se destacan las librerías y funcionalidades que se han utilizado

junto con su descripción.

4.2.1. Syncfusion

Syncfusion es una colección de componente software que son utilizados por

los desarrolladores de software para agregar capacidades a sus aplicaciones,

que pueden o no estar expuestas a los usuarios finales.

Destacan las siguientes características:

Posee una licencia de comunidad libre

Cuenta con más de 110 componentes.

Está disponible para Windows Forms, WPF, ASP.NET, Javascript,

Xamarin…

Está en continuo desarrollo.

Está construido para obtener el mejor rendimiento.

Todos los componentes son personalizables por el usuario.


43 de 61

Te permite trabajar con archivos comunes (Excel, Word, PDF,

PowerPoint…)

Cumple con los estándares de accesibilidad populares como la Sección

508 y VPAT.

Posea una integración completa con Visual Studio, lo que facilita su uso.

Incluye una ayuda para ver cómo se utilizan los componentes en

proyectos de prueba creados por ellos y así facilitarnos el trabajo haciendo

uso de esa ayuda.

En nuestro caso, se ha utilizado en la capa de Presentación, en casi todas las

interfaces. Ahora vamos a presentar algunos de sus usos aplicados a nuestro

proyecto:

Para la interfaz básica de la aplicación. Se ha utilizado el componente

MetroForm. El cual incorpora todas las características de un Form y

alguna más.

Para mostrar estadísticas. Para ello se utilizó el componente

ChartControl. Este componente tiene 35 tipos de gráficos (un ejemplo es

el gráfico de columnas que puede observarse en la imagen de abajo). Los

gráficos también son altamente adaptables y piden enlazarse con un gran

número de estructuras de datos (List, DataSet…).


44 de 61

Para mostrar las tablas de datos. Para ello se utilizó el componente

GridGroupingControl. Este control nos permite crear una agrupación

jerárquica, filtrar, ordenar varias columnas y la unión de diversos tipos de

fuentes de datos. También nos da la posibilidad de mostrar millones de

datos y manejar las actualizaciones de datos en tiempo real con menos

uso de la CPU.

Para crear mapas de procesos. Para ello se ha utilizado el componente

Diagram. Este componente tiene la capacidad de presentar diagramas

parecidos a los de Microsoft Visio. Permite crear y editar diagramas. Su

interfaz de programación pone a su disposición muchos comandos útiles

y métodos que permiten funcionalidades tales como la impresión y

exportaciones de los diagramas.


45 de 61

Para exportar datos a Excel. Para implementar esta funcionalidad se ha

utilizado el componente GridGroupingExcelConverterControl. Esta clase

nos permite exportar los datos del GidGroupingControl a un Excel

conservando la jerarquía y de forma optimizada.

Para seleccionar fechas. Para ello se ha utilizado el componente

DateTimePikerAdv. Dicho control nos proporciona una manera fácil de

implementar un selector de fecha-hora. En particular nos permite

configurarlo para que muestra la fecha y la hora siguiendo los estándares

de las diferentes culturas. También es posible modificar diferentes

aspectos de su apariencia, como puede ser el color y su tamaño.

Para almacenar una lista de seleccionables en un componente. Para ello

se ha utilizado el componente MultiColumnComboBox. Este control nos

permite crear una lista desplegable de opciones, en la cual se muestran

distintas columnas. Cuando el usuario seleccione una fila solamente se

mostrará el dato de la columna que le hallamos indicado.


46 de 61

Para mostrar las tareas en un calendario según la fecha de finalización.

Para ello se ha utilizado el componente SchudeleControl. Este control nos

permitirá crear un calendario al cual le podemos indicar que nos añada

distintas tareas en las fechas que queramos para que nos las muestre en

el calendario.

4.2.2. ADO.NET

ADO.NET es un conjunto de componentes del software que pueden ser

usados para acceder a datos y a servicios de datos. Es una parte de la biblioteca

de clases base que están incluidas en el Microsoft .NET Framework. También

puede ser usado para acceder a datos en fuentes no relacionales.

A modo de ejemplo, en la siguiente imagen se muestra un método que accede

a la BD para recuperar todas la reuniones a las que ha sido invitado un usuario

desde la fecha actual en adelante.


47 de 61

También se ha utilizado para invocar a los procedimientos almacenados que

se han creado en la BD (posteriormente hablaremos de ellos). Ejemplo de una

llamada al procedimiento GP_TareaRama, el cual recupera todas las tareas hijas

de una tarea dada:

4.2.3. Consultas recursivas

Las estructuras de tipo árbol nos dan una gran flexibilidad, puesto que no

tienen limitaciones en cuanto a la profundidad del árbol, ni tampoco en la

cantidad de hijos que puede tener cada nodo. Entro los nodos padre-hijo no se

repite información lo que permite realizar modificaciones entre ellos sin afectar

al resto de los nodos.


48 de 61

No obstante, las desventajas de las estructuras tipo árbol aparecen cuando

se trata de recuperar la información de la jerarquía, puesto que no es posible

realizar una sola consulta a la base de datos que devuelva toda o parte de la

jerarquía.

Una de las ayudas que permitían resolver este tipo de consultas vino de la

mano de SQL Server 2000 con la introducción de las Inline Table-Value User-

Defined Function. Estas funciones permiten que una función retorne datos en

forma de tabla y tome el resultado de dicha función como cualquier otra tabla de

la base de datos.

Estas funciones son capaces de devolver todos los identificadores de los hijos

que reportan directa o indirectamente a un padre. El problema era que siempre

nos devolvía la estructura padre hijo completa.

Por ello, en SQL Server 2005 se introdujo una nueva funcionalidad al motor

que facilitará más el trabajo con jerarquías. Esta nueva funcionalidad se llama

Recursive Common Table Expressions (Recursive CTE) y permite realizar una

consulta recursiva sin tener que definir una función para realizar dicha operación.

A continuación, vamos a mostrar una consulta recursiva utilizada en la

aplicación:


49 de 61

Para escribir una consulta CTE se definen dos partes, que deberán ser unidas

por un UNION ALL. La primera parte será el caso base (en el WHERE se debe

filtrar para elegir el nodo base) y la segunda, el caso recursivo la cual hace un

JOIN con la CTE. Este JOIN es lo que indica que es un caso recursivo.

Con esto se obtiene la tarea padre, todos sus hijos y el nivel de cada hijo. Si

por el contrario quisiéramos obtener todos los padres de una tarea base,

simplemente deberemos cambiar la relación del JOIN en el caso recursivo

(recuadro azul de la imagen), haciendo que coincidan el IdTareaPadre de la CTE

y el Id del caso Recursivo.

4.3. IMPLEMENTACIÓN DE LA APLICACIÓN

En este apartado vamos a tratar todo lo referido con la implementación de la

aplicación en sí.

4.3.1. Implementación de la BD

Como se ha comentado anteriormente, para la implementación de la BD se

ha utilizado SQL Server, ya que es el sistema Gestor de BD que se utiliza en

Garnica para almacenar todos los datos. Para ello se creó una nueva BD en la

que almacenar todos los datos, los trigger y procedimientos almacenados

necesarios para la aplicación. A continuación, hablaremos de los trigger y los

procedimientos almacenados.

Una vez creadas las tablas, se decidió implementar algunos procedimientos

almacenados para aquellas consultas que requieran de una consulta recursiva.

Las demás consultas se ejecutarán directamente desde la aplicación a través del

SQL correspondiente.


50 de 61

En particular, se han definido un total de 7 procedimientos almacenados. A

modo de ejemplo, el procedimiento almacenado TareasTipo se encargará de

obtener todas las tareas de un empleado y de un determinado tipo. Estas tareas

serán devueltas por niveles para poder crear una estructura tipo árbol.

Como caso base se eligen las tareas que sean del tipo y del usuario o

departamento indicado, y a partir de esas se obtienen todas sus tareas hijas.

Para mejorar el funcionamiento de las tareas se ha creado un trigger para la

tabla Tarea. Este trigger obtiene la tarea que ha sido añadida o modificada y

comprueba en la tarea padre si todos los hijos han acabado, en caso correcto la

marca como tarea finaliza y vuelve a comprobar a su padre, hasta llegar a la

tarea padre.


51 de 61

A continuación, se presenta el siguiente trigger:

4.3.2. Implementación de la capa de persistencia

Como se ha comentado anteriormente, dentro de la capa de persistencia solo

tendremos una clase llamada GestorBD la cual contendrá todos los métodos

encargados de comunicarse con la BD.


52 de 61

En particular, para acceder a la BD necesitaremos establecer una conexión

con la BD. Para ello se ha creado un archivo de configuración que contiene la

cadena de conexión a la BD. Para facilitar ese trabajo, Visual Studio nos ofrece

una vista gráfica para trabajar con el archivo de configuración.

Realizando esta cadena de conexión (CadenaConexion) nos ahorramos el

tener que escribir todos los aspectos de conexión a la BD cada vez que

queramos realizar una nueva conexión con la BD. En caso de que haría falta

poner el usuario y contraseña de la BD, nos evita que puedan ser visto por

cualquier persona que tenga acceso a la capa de persistencia.

La utilización de la cadena de conexión creada anteriormente es muy sencilla.

Cuando queramos conectarnos a la BD, deberemos indicarle que el

ConnectionString es la cadena de conexión creada anteriormente. Para poder

obtener esa cadena, deberemos apuntar a Settings, Default y el nombre con el

que la hayamos identificado (en nuestro caso CadenaConexion).


53 de 61

A modo de ejemplo se muestra el método getTareasTipo(), el cual se

conecta a la BD e invoca al procedimiento almacenado presentado

anteriormente.

En particular en el código anterior se crea un objeto SqlCommand, al que

deberemos pasarle el nombre del procedimiento almacenado que se quiere

ejecutar y la conexión. También habrá que añadirles las variables de entrada (en

este caso @id).


54 de 61

El siguiente paso consiste en crear un objeto SqlDataReader, el cual nos va a

permitir recorrer los valores devueltos.

4.3.3. Implementación del modelo de dominio

Dentro del paquete Modelo podremos encontrar todas clases que han sido

especificadas en el diseño. Cada clase estará compuesta por sus

correspondientes métodos y atributos. Estas clases serán utilizadas desde

cualquier parte del proyecto.

A continuación, se presenta la distribución del modelo de dominio:

4.3.4. Implementación del modelo de negocio

Dentro del modelo de negocio solo encontraremos una clase llamada

NegocioDatos, la cual contiene todos los métodos que se encargarán de

invocar a los métodos de la persistencia.

A continuación, se presenta el método getEmpleadoAportaciones del

paquete Negocio, que invoca al método de la capa de persistencia

getEmpleadoAportaciones:


55 de 61

4.3.5. Implementación de la capa de presentación

Cada interfaz de la aplicación está compuesta por tres tipos de ficheros:

Fichero con extensión cs. Tiene dos vistas. Una vista diseño, la cual nos

permite ver la vista preliminar de nuestra interfaz. Y vista código, la cual

contiene el código de los eventos que se ejecuten desde el formulario.

Fichero con extensión designer.cs. Es donde encontraremos el código

que se genera automáticamente. No se debe modificar este fichero.

Fichero con extensión resx. Almacena objetos para un programa en un

formato XML, que puede contener tanto información de texto sin formato,

así como datos binarios codificados como texto dentro de las etiquetas

XML

A modo de ejemplo, mostramos los ficheros creados para la interfaz

AbrirDiagrama:

A continuación, se remarcarán algunos aspectos a resaltar de la interfaz de

usuario:

Clase MetroForm

Todas las interfaces de Windows Form deben heredar de la clase Form o

alguna que descienda de ella. Para esta aplicación se decidió utilizar la clase

MetroForm, porque incorpora todas las características de la clase Form y

además añade nuevas funcionalidades. Además permite añadir un listado

imágenes para posicionarlas en la barra del título, cambiar la alineación del título

del formulario, el color de la barra de título y el ancho.


56 de 61

En la imagen anterior se puede ver como se han añadido cinco imágenes en

el encabezado del formulario (La primera imagen simplemente es el logo de la

aplicación). Pinchando en estas imágenes iríamos navegando por las distintos

interfaces de la aplicación. En la parte derecha irá el usuario que se ha

autentificado en la aplicación.

GridGrupingControl

Uno de los problemas que hemos tenido en el desarrollo del proyecto, ha sido

la forma de representar las Tareas. Como se ha explicado anteriormente, una

tarea podrá tener otras tareas hijas y así sucesivamente. Por lo tanto, se buscó

un control que permitiera representar una estructura de tipo árbol. Haciendo las

Tareas de nodos en dicha estructura.

El control GridGroupingControl da soporte a muchas fuentes de datos.

Algunas de ellas son: Entidades de ADO.NET, LINQ a SQL, tablas de datos de

ADO.NET y DataView y todos los DataCollections (IEnumerable,

IList, IBindingList, IQueryable, ITypedList y

ICustomTypeDescriptor).

El control GridGroupingControl soporta tanto las relacionas (1:n), como las

(n:1) en todas las fuentes de datos. Además, también nos permite poder exportar

nuestra estructura en una hoja Excel.

En la imagen anterior se puede ver como tenemos dos niveles de tareas. En

el primer nivel tenemos una tarea con ID 19 y dentro tenemos otras ocho tareas

hijas.


57 de 61

Diagramming

El siguiente problema con el que nos topamos fue el representar gráficamente

el mapa de procesos. Dicho diagrama tenía que ser interactivo y poder

actualizarlo desde la aplicación.

Para ello se decidió utilizar el control Diagram como se ha comentado antes.

Dicho control permite crear diagramas similares a los que podemos hacer con

Visio.

En la imagen se puede observar como los primeros elementos de la parte de

arriba son las distintas formas que podemos añadir a nuestro diagrama. Después

tenemos las siguientes opciones: nuevo, abrir, guardar, imprimir, exportar, cortar,

copiar, pegar, deshacer y rehacer.

Capítulo 5 - PRUEBAS

58 de 61

5. PRUEBAS

A continuación, se presenta el resultado de la ejecución del plan de pruebas.

ID Descripción Estado

1 Comprobar que solo pueden entrar los usuarios que se

encuentran en el directorio activo de Garnica.

2 Comprobar que la lista de tareas es correcta para todos los

usuarios.

3 Comprobar que los usuarios no puedan ver las tareas de otros

usuarios.

4 Asegurar que todos los filtros de las tareas funcionan

correctamente.

5 Comprobar que no permita crear tareas con datos

incoherentes.

6 Comprobar que la lista de reuniones es correcta para todos

los usuarios.

7 Comprobar que los usuarios no puedan ver las reuniones de

otros usuarios.

8 Asegurar que todos los filtros de las reuniones funcionan

correctamente.

9 Comprobar que no permita crear reuniones con datos

incoherentes.

10 Comprobar que todos los usuarios básicos puedan ver el

mapa de proceso.

11 Comprobar que solo los usuarios avanzados puedan editar el

mapa de procesos.

12 Comprobar que todos los usuarios básicos puedan ver los

detalles de los procesos.

13 Comprobar que solo los usuarios avanzados puedan crear

procesos.

14 Comprobar que no permita crear procesos con datos

incoherentes.

Aunque se muestren que finalmente la comprobación es correcta para todos

los apartados, decir que para ello ha sido necesario corregir varios errores de

código y de mal funcionamiento.

Capítulo 6 – CONCLUSIONES Y GESTIÓN

59 de 61

6. CONCLUSIONES Y GESTIÓN DEL PROYECTO

6.1. GESTIÓN DEL PROYECTO

En este apartado se muestra para cada tarea las horas estimadas para su

desarrollo y las horas reales que han sido dedicadas para su realización. Las

tareas se han organizado de acuerdo a la EDP creada anteriormente.

Tarea Horas por tarea Horas reales Desfase

Gestión del TFM 60 60 0

Análisis 40 50 +10

Diseño 30 25 -5

Implementación 155 160 +5

Pruebas 15 10 -5

Proyecto completo 300 305 15

A continuación, se presenta un gráfico de barras en el cual se muestra la

comparación entre ambos tiempos.

0

50

100

150

200

250

300

350

Horas portarea

Horas reales

Capítulo 6 – CONCLUSIONES Y GESTIÓN

60 de 61

6.2. CONCLUSIONES

Esta es la segunda vez que me enfrento a un proyecto de estas dimensiones,

la primera vez fue el TFG del grado en Ingeniería Informática. La experiencia

obtenida en la realización de dicho trabajo ha sido de gran ayuda para confección

del TFM.

Otra ventaja ha sido que las tecnologías con la que debía realizar la aplicación

eran .NET y SQL Server. Ambas fueran usadas para crear la aplicación de mi

TFG y por tanto tenía bastantes conocimientos sobre ellas.

El mayor problema con el que me he encontrado en este trabajo ha sido el

tener que compaginar el trabajo laboral con la realización del TFM. Es muy difícil

tener que trabajar ocho horas y luego sacar tiempo para realizar los trabajos de

la universidad. Pero para intentar minimizar este problema intenté realizar una

buena planificación, la cual me ayudó a repartir la carga de trabajo.

En referencia a la aplicación, destacar que a esta siendo utilizada por los

usuarios de Garnica. Dicha aplicación está incluida en el repositorio de aplicación

básicas de Garnica.

También ha sido necesario aplicar ciertas mejoras que no han sido recogidas

en esta memoria porque se han realizado posteriormente al TFM. Dichas

mejoras se refieren básicamente a nuevos filtros en las pantallas de “Mostrar

tareas” y de “Mostrar tareas del proceso”.

Capítulo 7 - BIBLIOGRAFÍA

61 de 61

7. BIBLIOGRAFÍA

En este apartado se presentan las páginas web y documentos utilizados para

la realización de proyecto.

1. Apuntes y trabajos obtenidos durante el grado. Accedido entre marzo y

junio de 2016.

2. Stackoverflow. Disponible en: http://stackoverflow.com. Accedido entre

marzo y mayo de 2016.

3. MSDN. Microsoft Developer Network. Disponible en:

http://msdn.microsoft.com. Accedido entre marzo y mayo de 2016.

4. W3Schools.com. The world´s Largest web developer site. Disponible en

http://w3schools.com. Accedido entre marzo y mayo de 2016.

5. Repositorio de trabajos de fin de grado de la biblioteca de la universidad

de la rioja. Disponible en: http://investigadoresur.unirioja.es. Accedido entre

febrero y junio de 2016.

http://stackoverflow.com/

http://msdn.microsoft.com/

http://w3schools.com/

http://investigadoresur.unirioja.es/

herramienta para la gestión de las tareas, reuniones y ... · p.1.2. creación de la memoria 20...

Documents