Desarrollo de una aplicación web para un gabinete pericial

Desarrollo de una aplicación web para un gabinete pericial

Universidad Politécnica de Barcelona (UPC) – Facultad de Informática de Barcelona (FIB)

Memoria Alumne: Jorge Álvarez Fernández Director: Carles Farré Tost Especialidad de Ingeniería del software 26 de Julio de 2018

Reconocimientos Este proyecto no podría haber sido posible sin el apoyo de muchas personas.

Me gustaría agradecer a mi supervisor Carles por el apoyo ofrecido con sus útiles consejos,

correcciones y los comentarios constructivos para corregir el proyecto durante su planificación y desarrollo, junto con su gran paciencia.

Tambien me gustaria agradecer a mis profesores, compañeros, y amigos de la Facultad de

Informática de Barcelona y los que hubo. Gracias a ellos pude aprender cosas que no podría haber realizado yo solo sin el apoyo que me han ofrecido.

Por último, me gustaría agradecer también el apoyo que me ofrecido mi familia,

especialmente, a mis padres y a mi hermano. Ellos me han dado todo el apoyo necesario para poder finalizar mis estudios.

Gracias a todos, me habeis dado la fuerza necesaria para continuar.

1

Lista de contenido Lista de figuras 5

Lista de tablas 5

1. Introducción y contextualización 6 1.1. Resumen del proyecto 6 1.2. Contexto 7 1.3. Estado del arte 8 1.4. Solución del problema 9 1.5. Stakeholders 9

2. Planificación 10 2.1. Planificación inicial 10 2.2. Presupuesto Inicial 13 2.3. Planificación definitiva 16 2.4. Presupuesto Final 19 2.5. Motivos de los cambios 22

3. Metodología y rigor 24 3.1. Metodología de trabajo 24 3.2. Pruebas de validación 24 3.3. Git Workflow 25

4. Sostenibilidad y compromiso social 26 4.1. Proyecto Puesto en Producción 26 4.2. Vida Útil 27 4.3. Riesgos 28 4.4. Matriz de sostenibilidad 29 4.5. Conclusiones de la sostenibilidad del proyecto 30

5. Análisis de requisitos 32 5.1. Requisitos funcionales 32 5.2. Requisitos no funcionales 34

6. Especificación 36 6.1. Casos de uso 36 6.2. Modelo Conceptual 52

7. Diseño 54 7.1. Arquitectura del sistema 54

7.2. Diseño de Interfaces 56

2

7.3. Diseño Interno 80

8. Implementación 103 8.1. Software utilizado 103 8.2. Despliegue del software 106

9. Testing 107 9.1. Test unitarios 107 9.2. Rendimiento 107 9.3. Usabilidad 107

10. Conclusiones 109 10.1. Conclusiones finales 109 10.3. Futuro del proyecto 110

11. Bibliografía 111 11.1. Fuentes de datos 111 11.2. Fuentes de tablas 111 11.3. Fuentes de figuras 112

Lista de figuras

Figura 1: Diagrama de Gantt Inicial 12 Figura 2: Diagrama de Gantt Final 18 Figura 3: Proceso de trabajo de un Git Workflow para proyectos solitarios 25 Figura 4: Casos de uso Login y Logout 36 Figura 5: Casos de uso Crear Usuario, Editar Usuario, Borrar Usuario, Introducir Cliente, Editar Cliente, Borrar Cliente, Introducir Norma Minuta Cliente y Editar Norma Minuta Cliente38 Figura 6: Casos de uso Introducir Taller, Editar Taller, Borrar Taller, Introducir Peritaje, Editar Peritaje, Crear Avance, Cerrar Peritaje y Crear Minuta 43 Figura 7: Casos de uso Editar Minutas, Introducir Norma Minuta Perito, Editar Norma Minuta Perito, Calcular Medias Peritación y Calcular Estadísticas Generales 48 Figura 8: Modelo conceptual de la aplicación 52 Figura 9: Esquema una petición a una aplicación con una arquitectura MVC 54 Figura 10 : Diagrama de flujo de la aplicación 56 Figura 11: Pantalla de inicio de sesión 57 Figura 12: Pantalla de inicio de sesión - Mensaje de carga 57 Figura 13: Pantalla de inicio de sesión - Mensaje de error 58 Figura 14: Barra de navegación 58 Figura 15: Barra de navegación - Desplegable de las opciones de “Administración” 58 Figura 16: Barra de navegación - Desplegable de la opción “Peritajes” 58 Figura 17: Pantalla de usuarios 59 Figura 18: Formulario emergente para crear un usuario 60

3

Figura 19: Formulario emergente para buscar usuarios 61 Figura 20: Formulario emergente para editar usuarios 61 Figura 21: Formulario Eliminar Usuarios 62 Figura 22: Pantalla de Clientes 62 Figura 23: Formulario para Introducir un Cliente 62 Figura 24: Formulario para Actualizar un Cliente 63 Figura 25: Formulario para Buscar Clientes 64 Figura 26: Formulario para Introducir un Cliente 65 Figura 27: Pantalla de Normas Minutas Clientes 65 Figura 28: Pantalla de Introducción de una Norma para las minutas de los clientes 66 Figura 29: Pantalla de Edición de una Norma para las minutas de los clientes 67 Figura 30: Pantalla de Edición de una Norma para las minutas de los clientes 67 Figura 31: Pantalla de Búsqueda de normas para las minutas de los clientes 68 Figura 32: Pantalla de Introducción de normas para las minutas de los peritos 68 Figura 33: Pantalla de Edición de normas para las minutas de los peritos 69 Figura 34: Pantalla de Búsqueda de normas para las minutas de los peritos 69 Figura 35: Pantalla de talleres 70 Figura 36: Pantalla de introducción de talleres 70 Figura 37: Pantalla de búsqueda de talleres 71 Figura 38: Pantalla de edición de un taller 71 Figura 39: Pantalla de eliminación de un taller 72 Figura 40: Pantalla de cálculo de estadísticas Generales - Vacio 72 Figura 41: Pantalla de búsqueda para calcular las estadísticas generales 72 Figura 42: Pantalla de cálculo de estadísticas Generales - Resultados 73 Figura 43: Pantalla de medias de peritación - Vacío 73 Figura 44: Pantalla de búsqueda para calcular las medias de peritación 73 Figura 45: Pantalla de medias de peritación - Resultados 74 Figura 46: Pantalla creación de peritajes 74 Figura 47: Pantalla de listado de peritajes 75 Figura 48: Pantalla de búsqueda de peritajes 75 Figura 49: Pantalla de edición de peritajes - Datos Generales 76 Figura 50: Pantalla de edición de peritajes - Avancés - Vacio 76 Figura 51: Pantalla de edición de peritajes - Avancés - Formulario de creación 77 Figura 52: Pantalla de edición de peritajes - Avancés - Con Registros 77 Figura 53: Pantalla de edición de peritajes - Datos generales - Proceso de cierre de un peritaje 1 78 Figura 54: Pantalla de edición de peritajes - Cierre de informe - Proceso de cierre de un peritaje 2 78 Figura 55: Pantalla de edición de peritajes - Introducción y edición de valores de Minutas no automáticos - Proceso de cierre de un peritaje 3 79 Figura 56: Pantalla de listado de minutas. 79 Figura 57: Logotipo de Revel 80

4

Figura 58: Ejemplo de la estructura de datos del modelo de Cliente 81 Figura 59: Diagrama de secuencia del caso de uso “Inicio de sesión” 82 Figura 60: Diagrama de secuencia del caso de uso “Cerrar sesión” 83 Figura 61: Diagrama de secuencia del caso de uso “Cerrar sesión” 83 Figura 62: Diagrama de secuencia del caso de uso “Editar Usuario” 84 Figura 63: Diagrama de secuencia del caso de uso “Borrar Usuario” 85 Figura 64: Diagrama de secuencia del caso de uso “Introducir Cliente” 86 Figura 65: Diagrama de secuencia del caso de uso “Editar Cliente” 87 Figura 66: Diagrama de secuencia del caso de uso “Borrar Cliente” 88 Figura 67: Diagrama de secuencia del caso de uso “Introducir Norma Minuta Cliente” 89 Figura 68: Diagrama de secuencia del caso de uso “Editar Norma Minuta Cliente” 90 Figura 69: Diagrama de secuencia del caso de uso “Introducir Taller” 91 Figura 70: Diagrama de secuencia del caso de uso “Editar Taller” 92 Figura 71: Diagrama de secuencia del caso de uso “Borrar Taller” 93 Figura 72: Diagrama de secuencia del caso de uso “Introducir Peritaje” 94 Figura 73: Diagrama de secuencia del caso de uso “Editar Peritaje” 95 Figura 74: Diagrama de secuencia del caso de uso “Crear Avances” 96 Figura 75: Diagrama de secuencia del caso de uso “Cerrar Peritaje” 97 Figura 76: Diagrama de secuencia del caso de uso “Crear Minuta” 98 Figura 77: Diagrama de secuencia del caso de uso “Editar Minutas” 99 Figura 78: Diagrama de secuencia del caso de uso “Introducir Norma Minuta Perito” 100 Figura 79: Diagrama de secuencia del caso de uso “Editar Norma Minuta Perito” 101

Lista de tablas

Tabla 1: Presupuesto original del programa 15 Tabla 2: Presupuesto actualizado del programa 21

5

1. Introducción y contextualización

1.1. Resumen del proyecto 1.1.1. English The project consists of the creation, configuration and management of an application that will serve to facilitate the management of an expert cabinet. The application will be destined to be used by two types of users:

● Cabinet managers: They will be responsible for managing the data entered, facilitating the calculations of these, reducing their workload and at the same time, the use of office tools that would be used is reduced.

● Cabinet experts: It will allow the user to keep track of all the expert reports assigned to him on a single platform. This will make it easier for you to keep track of your work.

To apply the project, it has been decided to create a web platform, in which users do not have the need to install any software, and at the same time, is characterized by its usability, allowing users, not only learn to use the tool, that they find comfortable to use. 1.1.2. Català El projecte consisteix en la creació, configuració i gestió d’una aplicació que serveix per facilitar la gestió d’un gabinet pericial. L’aplicació està destinada a ser utilitzada per dos tipus d’usuaris:

● Gestors del gabinet: S'encarregaran de gestionar les dades introduïdes, facilitant els càlculs d’aquests, reduint la seva càrrega de treball i alhora, l'ús d’eines ofimàtiques que anessin a utilizar es vegi reduït.

● Perits del gabinet: Permetrà a l’usuari portar un control de tots els peritatges que tingui assignats en una única plataforma. Això li facilitarà portar un control dels seus treballs.

Per aplicar el projecte, s'ha decantat per crear una plataforma web, en la qual els usuaris no tinguin la necessitat d'instal·lar cap programari, i alhora, estigui caracteritzada per la seva usabilitat, permetent als usuaris, no només aprendre a utilitzar l'eina, si no també que els resulti còmoda d'utilitzar.

6

1.1.3. Castellano El proyecto consiste en la creación, configuración y gestión de una aplicación que servirá para facilitar la gestión de un gabinete pericial. La aplicación estará destinada a ser utilizara por dos tipos de usuarios:

● Gestores del gabinete: Se encargaran de gestionar los datos introducidos, facilitando los cálculos de estos, reduciendo su carga de trabajo y a la vez, el uso de herramientas ofimáticas que fueran a utilizar se vea reducido.

● Peritos del gabinete: Permitirá al usuario llevar un control de todos los peritajes que tenga asignados en una única plataforma. Esto le facilitará llevar un control de sus trabajos.

Para aplicar el proyecto, se ha decantado por crear una plataforma web, en la cual los usuarios no tengan la necesidad de instalar ningún software, y a la vez, esté caracterizada por su usabilidad, permitiendo a los usuarios, no solo aprender a utilizar la herramienta, si no tambíen que les resulte cómoda de utilizar.

1.2. Contexto 1.2.1. Introducción Este trabajo fin de grado (TFG) es realizado mediante una modalidad A para un gabinete pericial en el cual el estudiante da soporte técnico, por lo cual resultaría conveniente describir un poco la metodología de trabajo que se realiza en un gabinete pericial. Un gabinete pericial es una empresa que recibe siniestros de las empresas aseguradoras. Un siniestro es un suceso que produce un daño o una pérdida material considerable. Estos siniestros pueden ser de diferentes bienes, como objetos, viviendas, barcos o coches. Una vez que se hayan evaluado los daños, estos se enviarán mediante una plataforma web ofrecida por la aseguradora, para así, añadir los datos de la evaluación de daños del siniestro y dar por finalizado el siniestro.

Cuando un perito finaliza un siniestro, este recibe una minuta de acuerdo a los costos de reparación, incitando al perito de que para obtener beneficios es necesario evaluar una gran cantidad de siniestros. Encarecer los siniestros para aumentar los beneficios no es una táctica recomendable, ya que puede llevar a una mala relación con las aseguradoras y provocar que estas dejen de enviar peticiones de valoración al gabinete. Además, un gabinete pericial no solo trabajará con una única asegurada, si no que tratará de trabajar con el mayor número posible de aseguradoras, por lo cual deberá de realizar un control de todos lo datos introducidos por las plataformas web de cada empresa.

7

1.2.2. Formulación del problema Debido a la cantidad de plataformas web de las diferentes aseguradoras existentes, se requiere visitar las diferentes aplicaciones para preparar las diferentes visitas que tendrá que hacer el perito para evaluar los daños, provocando que este, tenga que navegar de forma repetida por todas las plataformas existentes. Lo ideal sería crear una aplicación en la cual pudiera conectarse a las plataformas API de las diferentes plataformas web. No obstante, la gran mayoría de plataformas web de las aseguradoras no disponen de ninguna plataforma API, por lo cual, unificar todo en una única plataforma resultaría imposible. Esto provoca que se tenga que crear una plataforma en la cual se tengan que introducir los datos de forma manual, haciendo el usuario introduzca los datos ya repetidos en las otras plataformas web en esta. Además, debido a la dependencia de los sistemas, se desea que estos datos se encuentren en un sistema independiente de otras empresas, tanto aseguradoras como soluciones de otras, debido a que el negocio de estas soluciones es muy común que en un futuro dejen de dar soporte técnico a sus soluciones (normalmente asociado a una vida útil anormalmente corta), forzando al perito utilizar un software obsoleto o dejar de disponer de ese software, hasta que salga otro software que ofrezca funciones parecidas.

1.3. Estado del arte Actualmente, con una única excepción, la mayoría de software que utilizan los diferentes gabinetes periciales es un software hecho a medida, por lo cual, imposible de obtener para el alumno para su estudio. No obstante, como mencionamos anteriormente, existe una excepción, el XT50 [1], un programa de peritación comercial desarrollado por APCAS DATA [2], una empresa propiedad de APCAS [3] (Asociación de Peritos de Seguros y Comisarios de Averías). Un software de gestión pericial completo diseñado para un entorno web para tanto el ordenador como para los diferentes dispositivos móviles (Tablets, smartphones). Debido a que ha sido pedido por APCAS, podemos asegurarnos que las características que tienen son la clave para un gabinete pericial. Es una solución completa tanto a para los peritos como para la gestión del gabinete. No obstante, se requiere una suscripción anual [4] para poder disfrutar de sus servicios. A pesar de todas las ventajas que ofrece el XT50, la mayoría son soluciones que aplicará a un nivel general de problemas. Teniendo en cuenta que un gabinete tiene su propia metodología de gestión, además de la posibilidad de que el software pueda quedar en desuso, es preferible adaptar algunas de las soluciones ofrecidas por el software y aplicarlos en un software nuevo para asegurar que la empresa, no tenga problemas si algun dia se deja de dar soporte al software y deciden cerrar el servicio.

8

1.4. Solución del problema El proyecto en sí, solventa el problema en utilizar un software web en el cual, actualmente, todas los navegadores web son capaces de navegar sin ningún problema de compatibilidad. El software ofrece una solución administrativa para todos los peritos del gabinete, ofreciendo una agenda personal sobre todos sus peritajes en una única aplicación, eliminando la descentralización de los diferentes peritajes a realizar, y a la vez, ofrecer al gabinete pericial un historial de todos los peritajes realizados. El software también ofrece una solución administrativa para el empresario, aplicando los cálculos de las diferentes empresas con sus variables. No obstante, a pesar de todas las ventajas que ofrece, sin la introducción de una API por los clientes, no se puede obtener los datos de los peritajes de forma automática, forzando a los usuarios de la aplicación a introducir los datos a mano.

1.5. Stakeholders Los stakeholders o principales actores de este proyecto son aquellas personas que están de una manera o otra relacionados con el proyecto a desarrollar, en nuestro caso al tratarse de una herramienta definiremos los siguientes stakeholders:

● Desarrollador: El estudiante que presenta este proyecto. Este stakeholder se enfocará en desarrollar la aplicación para poder finalizar sus estudios universitarios.

● Director del proyecto: El director del proyecto ofrecerá apoyo ● Dueño del gabinete pericial: El beneficiario principal de la aplicación. Con ella

pretende acelerar el proceso de trabajo y facilitar para sus trabajadores, además de su trabajo para calcular las nóminas de sus trabajadores y comprobar que los datos que han introducido sean los correctos.

● Usuarios de la aplicación: Los usuarios de la aplicación en un principio serán los trabajadores del gabinete. Estos tienen interés en la aplicación para poder facilitar y agilizar el proceso de un peritaje, pudiendo realizar un mayor volumen de trabajo en un tiempo menor.

9

2. Planificación

2.1. Planificación inicial El proyecto tendrá una duración estimada de 88 días efectivos , en los cuales comenzará el 1

26 de febrero y terminará el 25 de junio, el primer día de la defensa oral. Debido a ello, la fecha final de entrega del TFG será inamovible. El desarrollo del proyecto finalizara el día 24 de mayo para que el desarrollador del proyecto pueda preparar la defensa de este. Aun así, cabe comentar que esta fecha puede variar debido a las posibles desviaciones, que se entrara en detalle en el apartado de Descripción de tareas . Se prevé que el TFG se haya invertido unas 450 horas aproximadamente. 2.1.1. Gestión del proyecto La primera parte de todo el proyecto. Se trata del estudio del proyecto que se pretende realizar y documentar el contenido clave de este, de los cuales destacan los siguientes:

● Alcance: El objetivo del proyecto y hasta donde se quiere alcanzar ● Planificación: Cálculo de los tiempos y tareas del programa ● Gestión económica: Calcular los costes de desarrollo del software para la empresa

y los beneficios económicos que aportará. ● Sostenibilidad: Abarcara tanto la sostenibilidad ambiental como el compromiso

social que pueda abarcar el proyecto. Durante la gestión del proyecto se realizará dos presentaciones del proyecto, una preliminar de 3 minutos y una de 5 minutos. En la semana final de esta tarea, se dedicara a unir todos el contenido de los documentos entregados en uno solo, además de una revisión de las competencias realizadas en este TFG. Una vez acabada la gestión del proyecto, veremos que este contendrá las historias de usuario y la planificación para el desarrollo del software, facilitando así, las historias de usuario que queramos implementar en el Backlog . 2

1 Días en los que se han trabajado 2 Backlog: Artefacto de la metodología scrum que contiene una lista ordenada de las historias de usuario ordenadas de mayor a menor prioridad que se realizarán durante el desarrollo del proyecto.

10

2.1.2. Desarrollo de la aplicación Exceptuando la iteración inicial, cada iteración consta de una planificación inicial en la cual se decidirán las historias de usuario que se desarrollaran, su desarrollo (junto con sus pruebas de validación) y una revisión final del programa. Iteración inicial (10/04/18 - 18/04/18) La primera acción que se hará en el desarrollo del proyecto será hacer una revisión rápida de todos los requisitos declarados en el documento de la gestión del proyecto y otros posibles requisitos que se hayan encontrado en el momento de la entrega de este o después. Una vez declarado las historias que creamos necesarias, definiremos el backlog inicial con aquellas historias de usuario que se creen apropiadas para el desarrollo del proyecto. Primera Iteración (19/04/18 - 27/04/18) En la primera iteración se enfocara en la creación del modelo del programa, la posibilidad de introducir los datos relacionados con los siniestros (Talleres, aseguradoras) y un sistema de credenciales para limitar el acceso y tener control de quien realiza los cambios. Segunda Iteración (30/04/18 - 08/05/18) En la segunda iteración se desarrollará en la posibilidad de registrar siniestros, ofreciendo la posibilidad de añadir datos de los modelos anteriormente mencionados. Tercera Iteración (09/05/18 - 15/05/18) El objetivo de esta iteración es implementar el sistema de minutas , tanto para el gabinete 3

para controlar los beneficios, como para los peritos para calcular parte de su nómina. Cuarta Iteración (16/05/18 - 24/05/18) En esta última iteración se enfocara en la obtención de la media de peritajes realizados por un perito, para así, poder evaluar su eficiencia. Además, se calculara la minuta final que deberá de recibir por el trabajo realizado por este para así, pagar parte de su nómina. Todas estas iteraciones se han ido introduciendo historias de usuario en las cuales tienen un coste definido por la dificultad de estas. De acuerdo a ellas, el coste del proyecto se ha definido que tendrá un coste total de 50 puntos de historias de usuario sin contar las historias de usuario con peso desconocido.

3 Cuenta que presenta los honorarios por un trabajo.

11

2.1.3. Documentación y presentación En este último conjunto de tareas que se realizarán se trataran de redactar la memoria del proyecto desarrollado y la presentación del proyecto. Una vez se ha llegado a este punto se dará por finalizado el desarrollo de la aplicación para prepararse para la defensa de este mismo, practicando la presentación oral que, como mínimo, empezará el 25 de junio.

Figura 1: Diagrama de Gantt Inicial

12

2.2. Presupuesto Inicial Como el trabajo que se realiza es para el TFG, no se esperan costes de mano de obra por el desarrollo de la aplicación. No obstante, se simulara los costes de mano de obra para el cálculo del desarrollo del proyecto. El cálculo del presupuesto se tendrán en cuenta las siguientes características

● Costes directos: Supondrá la mano de obra del desarrollador de la aplicación. Se ha calculado que un coste aceptable tanto para el desarrollador como para una PYME sería de 10 € por hora de trabajo durante todo el proyecto. Contaremos únicamente el tiempo que se dedica a desarrollar la aplicación del TFG ya que este es el producto que se venderá al gabinete pericial. Se prevé que se dedique una 175 horas durante el TFG con la planificación del diagrama de Gantt de la entrega anterior. Cada iteración se espera que dure 35 horas aproximadamente.

● Costes indirectos: Estos costes serán aquellos que están derivados del desarrollo de la aplicación, de los cuales se considerarán los siguientes:

○ Consumo eléctrico: Se tendrá en cuenta un contrato con la Tarifa Tiempo de Endesa, en la cual se cobrará 0.14 €/kWh [5] por las horas de trabajo en las cuales se enfocarán en el desarrollo del trabajo. El consumo eléctrico del hardware usado durante el proyecto se encuentra en el apartado 4.1.1. Ambiental. Para el cálculo eléctrico de la factura se tendrá en cuenta el tiempo que se dedicara al desarrollo del software, que mencionamos en el apartado de costes directos. Para el cálculo del consumo eléctrico se tendrá en cuenta la siguiente fórmula Cálculo consumo eléctrico de desarrollo de la aplicación = 175 horas de trabajo * ( 21 W + 120 W) + 665 horas que las maquinas estan apagadas * (0.3 W + 0.2 W) Cálculo consumo eléctrico de desarrollo de la aplicación = 24.67 kW (ordenador) + 332.5 W (monitor)

○ Amortización: El hardware que se utilizara para desarrollar el software tiene

un coste total de 900 €, donde este tiene una esperanza de vida de 5 años. Suponiendo que se invertirán 175 horas por el mismo motivo que los costes directos, se espera que la amortización del hardware usado sea de unos 3,59 €.

● Contingencias: 10% del presupuesto calculado con los costes directos e indirectos se utilizará en caso de contingencia. Se ha procurado que el presupuesto de la aplicación sea el más preciso posible. A pesar de ello, es muy probable que debido a una falta de información, se requiera un esfuerzo extra para su compensación que no se haya considerado.

13

● Imprevistos: Durante el desarrollo de la aplicación es posible que se encuentren imprevistos durante una iteración. La probabilidad de que se puedan llevar a cabo desviaciones del proyecto causadas por imprevistos según el diagrama de Gantt son los siguientes:

○ Iteración inicial: 2%. Debido a la documentación del primer entregable tenemos bastante claro los objetivos que queremos aplicar. En el caso improbable de que ocurra.

○ Primera iteración: 5%. Existe la posibilidad de que se necesite introducir datos aparte de los que estén relacionados con los siniestros.

○ Segunda iteración: 10%. Es la parte clave de la aplicación, donde los usuarios accederán a ella de forma rutinaria. Debido a ello se tiene que asegurar que todas las operaciones realizadas se guarden de forma correcta y se lo más usable posible para el usuario.

○ Tercera iteración: 5%: El cálculo de minutas es basarse en unas reglas de diferentes variables de las aseguradoras. Se tendrá que asegurar que los cálculos sean los correctos ya que estos servirán para calcular el beneficio de la empresa.

○ Cuarta iteración: 5%: Las estadísticas han de contener todos los motivos por el cierre de un siniestro. Es posible que se descubran nuevos motivos o nuevas fórmulas en la iteración anterior que afecten a esto.

● Impuestos: Impuestos que habrá que pagar al estado por la producción y venta de la aplicación. El IVA actual (7 de abril de 2018) es del 21% [6].

14

Los cálculos del presupuesto son los siguientes:

Nombre Tasa Valor Costo

Iteración Inicial 10 €/h 35 horas 350,00 €

Primera Iteración 10 €/h 35 horas 350,00 €

Segunda Iteración 10 €/h 35 horas 350,00 €

Tercera Iteración 10 €/h 35 horas 350,00 €

Cuarta Iteración 10 €/h 35 horas 350,00 €

Total CD 10 €/h 175 horas 1.750,00 €

Consumo Ordenador 0,14 €/kWh 24,67 kWh 3,45 €

Consumo Monitor 0,14 €/kWh 0,3325 kWh 0,05 €

Amortización Hardware 3,59 €

Total CI 7,09 €

Total CD + CI 1.757,09 €

Contingencia 10% 1.757,09 € 175,71 €

Total CD + CI + Contingencia 1.932,80 €

Imprev. It inicial 1% 350€ 4€

Imprev. It 1 3% 350€ 11€

Imprev. It 2 5% 350€ 18€

Imprev. It 3 10% 350€ 35€

Imprev. It 4 5% 350€ 18€

Total Imprevistos 84€

Subtotal 2.016,80 €

IVA 21% 2.016,80 € 423,53 €

Total 2.440,33 €

Tabla 1: Presupuesto original del programa

Presupuesto del proyecto aproximado = 2,440.33 €

15

2.3. Planificación definitiva El proyecto tendrá una duración estimada de 99 días efectivos , en los cuales comenzará el 4

26 de febrero y terminará el 10 de julio, una semana después de la defensa oral. El desarrollo del proyecto finalizara el día 14 de junio para que el desarrollador del proyecto pueda preparar la defensa de este. Se prevé que el TFG se haya invertido unas 495 horas aproximadamente La planificación final del proyecto es la siguiente, teniendo en cuenta los cambios mencionados anteriormente: 2.3.1. Gestión del proyecto La primera parte de todo el proyecto. Se trata del estudio del proyecto que se pretende realizar y documentar el contenido clave de este, de los cuales destacan los siguientes:

● Alcance: El objetivo del proyecto y hasta donde se quiere alcanzar ● Planificación: Cálculo de los tiempos y tareas del programa ● Gestión económica: Calcular los costes de desarrollo del software para la empresa

y los beneficios económicos que aportará. ● Sostenibilidad: Abarcara tanto la sostenibilidad ambiental como el compromiso

social que pueda abarcar el proyecto. Durante la gestión del proyecto se realizará dos presentaciones del proyecto, una preliminar de 3 minutos y una de 5 minutos. En la semana final de esta tarea, se dedicara a unir todos el contenido de los documentos entregados en uno solo, además de una revisión de las competencias realizadas en este TFG. Una vez acabada la gestión del proyecto, veremos que este contendrá las historias de usuario y la planificación para el desarrollo del software, facilitando así, las historias de usuario que queramos implementar en el Backlog . 5

4 Días en los que se han trabajado 5 Backlog: Artefacto de la metodología scrum que contiene una lista ordenada de las historias de usuario ordenadas de mayor a menor prioridad que se realizarán durante el desarrollo del proyecto.

16

2.3.2. Desarrollo de la aplicación Iteración inicial (10/04/18 - 18/04/18) La primera acción que se hará en el desarrollo del proyecto será hacer una revisión rápida de todos los requisitos declarados en el documento de la gestión del proyecto y otros posibles requisitos que se hayan encontrado en el momento de la entrega de este o después. Una vez declarado las historias que creamos necesarias, definiremos el backlog inicial con aquellas historias de usuario que se creen apropiadas para el desarrollo del proyecto. Primera Iteración (19/04/18 - 27/04/18) En la primera iteración se enfocara en la creación del modelo del programa, la posibilidad de introducir los datos relacionados con los siniestros (Talleres, aseguradoras) y un sistema de credenciales para limitar el acceso y tener control de quien realiza los cambios. Segunda Iteración (30/04/18 - 08/05/18) En la segunda iteración se desarrollará en la posibilidad de registrar siniestros, ofreciendo la posibilidad de añadir datos de los modelos anteriormente mencionados. Tercera Iteración (09/05/18 - 15/05/18) El objetivo de esta iteración es implementar el sistema de minutas , tanto para el gabinete 6

para controlar los beneficios, como para los peritos para calcular parte de su nómina. Cuarta Iteración (28/05/18 - 05/06/18) En esta iteración se enfocara en la obtención de la media de peritajes realizados por un perito, para así, poder evaluar su eficiencia. Además, se calculara la minuta final que deberá de recibir por el trabajo realizado por este para así, pagar parte de su nómina. Esta iteración se retrasara aproximadamente dos semanas para poder finalizar el trabajo de otras asignaturas para poder dedicarle el tiempo deseado. Quinta Iteración (06/06/18 - 14/06/18) Se mirara de mejorar las interfaces de los usuarios para que sean más usables y agradables para el usuario en esta iteración. Sexta Iteración (03/07/18 - 10/07/18) Por último, en esta iteración, se enfocara en refactorizar el código para poder aplicar las leyes actualizadas para evitar posibles problemas legales. Todas estas iteraciones se han ido introduciendo historias de usuario en las cuales tienen un coste definido por la dificultad de estas. De acuerdo a ellas, el coste del proyecto se ha calculado que se ha realizado tiene un coste de 69 puntos de historias de usuario, de un

6 Cuenta que presenta los honorarios por un trabajo.

17

total de 72 puntos de historias de usuario. Estos 3 últimos puntos van referenciados a la historias de usuario relacionadas con la última iteración. 2.3.3. Documentación y presentación En este último conjunto de tareas que se realizarán se trataran de redactar la memoria del proyecto desarrollado y la presentación del proyecto. Una vez se ha llegado a este punto se dará por finalizado el desarrollo de la aplicación para prepararse para la defensa de este mismo, practicando la presentación oral que, como mínimo, empezará el 25 de junio.

Figura 2: Diagrama de Gantt Final

18

2.4. Presupuesto Final Como el trabajo que se realiza es para el TFG, no se esperan costes de mano de obra por el desarrollo de la aplicación. No obstante, se simulara los costes de mano de obra para el cálculo del desarrollo del proyecto. El cálculo del presupuesto se tendrán en cuenta las siguientes características

● Costes directos: Supondrá la mano de obra del desarrollador de la aplicación. Se ha calculado que un coste aceptable tanto para el desarrollador como para una PYME sería de 10 € por hora de trabajo durante todo el proyecto. Contaremos únicamente el tiempo que se dedica a desarrollar la aplicación del TFG ya que este es el producto que se venderá al gabinete pericial. Se prevé que se dedique una 245 horas durante el TFG con la planificación del diagrama de Gantt de la entrega anterior. Cada iteración se espera que dure 35 horas aproximadamente.

● Costes indirectos: Estos costes serán aquellos que están derivados del desarrollo de la aplicación, de los cuales se considerarán los siguientes:

○ Consumo eléctrico: Se tendrá en cuenta un contrato con la Tarifa Tiempo de Endesa, en la cual se cobrará 0.14 €/kWh por las horas de trabajo en las cuales se enfocarán en el desarrollo del trabajo. El consumo eléctrico del hardware usado durante el proyecto se encuentra en el apartado 4.1.1. Ambiental. Para el cálculo eléctrico de la factura se tendrá en cuenta el tiempo que se dedicara al desarrollo del software, que mencionamos en el apartado de costes directos. Para el cálculo del consumo eléctrico se tendrá en cuenta la siguiente fórmula Cálculo consumo eléctrico de desarrollo de la aplicación = 245 horas de trabajo * ( 21 W + 120 W) + 1.083 horas que las maquinas estan apagadas * (0.3 W + 0.2 W) Cálculo consumo eléctrico de desarrollo de la aplicación = 29,65 kW (ordenador) + 541,5 W (monitor)

○ Amortización: El hardware que se utilizara para desarrollar el software tiene

un coste total de 900 €, donde este tiene una esperanza de vida de 5 años. Suponiendo que se invertirán 245 horas por el mismo motivo que los costes directos, se espera que la amortización del hardware usado sea de unos 5,03 €.

● Contingencias: 10% del presupuesto calculado con los costes directos e indirectos se utilizará en caso de contingencia. Se ha procurado que el presupuesto de la aplicación sea el más preciso posible. A pesar de ello, es muy probable que debido a una falta de información, se requiera un esfuerzo extra para su compensación que no se haya considerado.

● Imprevistos: Durante el desarrollo de la aplicación es posible que se encuentren imprevistos durante una iteración. La probabilidad de que se puedan llevar a cabo

19

desviaciones del proyecto causadas por imprevistos según el diagrama de Gantt son los siguientes:

○ Iteración inicial: 2%. Debido a la documentación del primer entregable tenemos bastante claro los objetivos que queremos aplicar. En el caso improbable de que ocurra.

○ Primera iteración: 5%. Existe la posibilidad de que se necesite introducir datos aparte de los que estén relacionados con los siniestros.

○ Segunda iteración: 10%. Es la parte clave de la aplicación, donde los usuarios accederán a ella de forma rutinaria. Debido a ello se tiene que asegurar que todas las operaciones realizadas se guarden de forma correcta y se lo más usable posible para el usuario.

○ Tercera iteración: 5%: El cálculo de minutas es basarse en unas reglas de diferentes variables de las aseguradoras. Se tendrá que asegurar que los cálculos sean los correctos ya que estos servirán para calcular el beneficio de la empresa.

○ Cuarta iteración: 5%: Las estadísticas han de contener todos los motivos por el cierre de un siniestro. Es posible que se descubran nuevos motivos o nuevas fórmulas en la iteración anterior que afecten a esto.

○ Quinta iteración: 5%: Existe la posibilidad de que para aplicar las interfaces como el usuario desee, se tenga que cambiar por completo la estructura de una interfaz ya implementada.

○ Sexta iteración: 5%: La posibilidad de que la refactorización del código suponga un gran cambio en el cual se tenga que descartar las funciones creadas e implementar unas completamente nuevas, además de mirar cómo mirar que la aplicación de estas nuevas leyes no influya en funciones deseadas por el cliente.

● Impuestos: Impuestos que habrá que pagar al estado por la producción y venta de la aplicación. El IVA actual (7 de abril de 2018) es del 21%.

20

Los cálculos del presupuesto son los siguientes:

Nombre Tasa Valor Coste

Iteración Inicial 10 €/h 35 horas 350,00 €

Primera Iteración 10 €/h 35 horas 350,00 €

Segunda Iteración 10 €/h 35 horas 350,00 €

Tercera Iteración 10 €/h 35 horas 350,00 €

Cuarta Iteración 10 €/h 35 horas 350,00 €

Quinta Iteración 10 €/h 35 horas 350,00 €

Sexta Iteración 10 €/h 35 horas 350,00 €

Total CD 10 €/h 245 horas 2.450,00 €

Consumo Ordenador 0,14 €/kWh 29,65 kWh 4,15 €

Consumo Monitor 0,14 €/kWh 0,5415 kWh 0,08 €

Amortización Hardware 5,03 €

Total CI 9,26 €

Total CD + CI 2.459,26 €

Contingencia 10% 2.459,26 € 245,93 €

Total CD + CI + Contingencia 2.705,18 €

Imprev. It inicial 1% 350€ 4€

Imprev. It 1 3% 350€ 11€

Imprev. It 2 5% 350€ 18€

Imprev. It 3 10% 350€ 35€

Imprev. It 4 5% 350€ 18€

Imprev. It 5 5% 350€ 18€

Imprev. It 6 5% 350€ 18€

Total Imprevistos 119€

Subtotal 2.824,18 €

IVA 21% 2.824,18 € 593,08 €

Total 3.417,26 €

Tabla 2: Presupuesto actualizado del programa

Presupuesto del proyecto final = 3.417,26 €

21

2.5. Motivos de los cambios En el momento del cálculo del tiempo del proyecto, se calculó que este se entregaría el 21 de mayo, cerca del dia de la entrega del informe. No obstante, debido a múltiples motivos, se tuvo que retrasar hasta el 10 de julio. Debido a ello, también se incrementó el presupuesto del proyecto para poder implementar estos requisitos no calculados. Los motivos de los cambios realizados son los siguientes:

● Calidad de la interfaz insuficiente. El desarrollador de la aplicación no calculo la dificultad del desarrollo de una interfaz usable con conexiones con el servidor. Para solventarlo, se ha decidido implementar una quinta iteración para refactorizar el código la interfaz.

● Sustitución de la Ley Orgánica de Protección de datos (LOPD) por el Reglamento General de Protección de Datos (RGPD) [7]. Se ha decidido implementarlo en este para cumplir el nuevo reglamento y evitar problemas legales.

● Se ha decidido implementar una sexta implementación para refactorizar el código interno de la aplicación para cumplir el nuevo reglamento.

● Retrasos en la implementación de la quinta y sexta iteración para dedicar tiempo a las entregas finales y exámenes finales de otras asignaturas, junto a la preparación de la documentación y presentación del mismo proyecto. El tiempo dedicado no varía.

● Recibido fecha definitiva de presentación y entrega. Cambia el tiempo dedicada a la presentación y el hito que representa el dia de la defensa oral.

22

23

3. Metodología y rigor Durante la carrera, sobretodo en la especialidad de Ingeniería de Software, se introduce al alumno las diferentes metodologías de trabajo para desarrollar software. Entre ellas las que más han destacado y se han trabajado han sido las metodologías ágiles como Scrum o Kanban. Estas metodologías ágiles nos aseguran que el software que desarrollemos se pueda realizar en el menor tiempo posible para realizar demostraciones a los posibles clientes y obtener un feedback para asegurar que el desarrollo de la aplicación va en buen camino o no. De esta manera, se asegura también de que los posibles cambios que desee el cliente sean un impacto mucho más menor comparado con las metodologías de trabajo más clásicas, como Cascade, en el desarrollo de software.

3.1. Metodología de trabajo Viendo las metodologías de trabajo y la ventaja que ofrecen sería idóneo utilizar una metodología ágil. Debido a que la empresa con la que trataremos, requerirá el software de manera inmediata y la posibilidad de cambios nos decantamos por la metodología Scrum, una metodología ágil que destaca en la obtención de resultados más pronto que otras metodologías ágiles [8]. Como el alumno que se encargará del proyecto de TFG será el único integrante esta metodología, será un poco diferente, ya que no habrá ningún tipo de reunión, además de que este, ocupara todos los roles principales (Product Owner, Scrum Master y Scrum Team ). Se utilizará básicamente las historias de usuario y la metodología Scrum para tener un control del proyecto para que este, tenga las funciones esperadas y no perder de vista el objetivo principal. Para tener en cuenta el seguimiento del proyecto y todas las funciones que se desean aplicar según las historias de usuario, se utilizará Trello, un software web gratuito que permite tener en cuenta el seguimiento del software desarrollado.

3.2. Pruebas de validación Por supuesto, cuando se realiza un proyecto ágil, cada historia de usuario deberá de ir acompañada de un conjunto de tests que comprueban que el funcionamiento de este sea correcto. Además para asegurarnos de que durante el desarrollo del software no se producirán errores en apartados ya desarrollados utilizaremos la metodología de desarrollo TDD

24

(Test Driven Development) [9] para las pruebas unitarias. Debido al tiempo reducido que se posee, se utilizará esta metodología en las partes más importantes de la aplicación, como los modelos de la aplicación, teniendo en cuenta que para el desarrollo de la aplicación se implementa con una arquitectura MVC . 7

Para el desarrollo y realización de los tests se utilizará el framework revel [10], un framework que no solo facilitará el desarrollo del software, sino también la preparación de estas pruebas.

3.3. Git Workflow Aun así, se implementara una metodología de trabajo de git (Git workflow) para proyectos solitarios [11], para poder tener un control de los cambios realizados en cada versión y así, volver a un estado anterior del proyecto, y a la vez, tener un historial de todos los cambios realizados. En un principio el proyecto contará con tres ramas:

● Maestro y origen: Representa el código que el usuario utilizará. Contendrá únicamente el código que se utilizara en la aplicación.

● Desarrollo: En ella es donde se implementara la mayoría de nuestro trabajo. Se realizarán las tareas de mantenimiento del código, corrección de bugs y/o modificar las características y funciones ya implementadas. Una vez decidido que los cambios están listos para el uso, se implementaran en la rama maestro y origen.

● Características: En principio la rama se llamará de acuerdo a la característica que se desee implementar o cambios a gran escala. Esto facilitará que, si en la rama de desarrollo, se tiene que hacer una tarea de mantenimiento y publicarla a la rama maestra, no se tenga que deshacer la nueva función. Una vez que la característica o función, ya haya sido implementada correctamente, procuraremos implementar el código desarrollado en la rama de desarrollo para implementarla en ella. Como que una vez que la función ya haya sido implementada, esta rama creada será eliminada ya que los cambios menores y su mantenimiento se realizará en la rama de desarrollador.

Figura 3: Proceso de trabajo de un Git Workflow para proyectos solitarios

7 Modelo Vista Controlador

25

4. Sostenibilidad y compromiso social

4.1. Proyecto Puesto en Producción 4.1.1. Ambiental Para cuantificar el impacto ecológico del desarrollo del TFG se medirá en kWh. Representará el consumo energético que intervendrá en el proceso de producción del proyecto realizado. El desarrollador del TFG se dedicara a realizar el proyecto de inicio a fin, por lo cual los 94 días marcados en el diagrama de Gantt, se encargará de hacerlos todo el. Para su cálculo se tendrá en cuenta la máquina del autor de la aplicación, que es un equipo de sobremesa. Pantalla LCD:

● Activo: 21 W ● Standby: 1 W ● Apagado: 0.2 W

Ordenador sobremesa:

● Activo: 120 W ● Standby: 5 W ● Apagado: 0.5 W

Cálculo consumo eléctrico de desarrollo del TFG = 495 horas de trabajo * ( 21 W + 120 W) + 1881 horas que las maquinas estan apagadas * (0.3 W + 0.2 W) Cálculo consumo eléctrico de desarrollo del TFG = 70.7355 kWh En este cálculo, se ha tenido en cuenta las siguientes condiciones:

● No se le sumará el tiempo que la máquina permanece en standby debido a que el alumno que desarrolla la aplicación suele apagar por completo sus recursos electrónicos.

● Se ha configurado el ordenador para que el consumo de este mientras este apagado se el mínimo posible, afectando al consumo total.

● Las horas de dedicación son de inicio a fin. No se espera que el ordenador pase a estar en modo standby en ningún momento.

26

Existe la posibilidad de reducir el consumo energético del desarrollo de la aplicación si se dispusiera de un ordenador portátil, ya que estos, tienen un consumo eléctrico notablemente menor al de un ordenador junto con su monitor. Se espera que en futuros proyectos se utilice un ordenador portátil para reducir su impacto medioambiental a largo plazo. 4.1.2. Económico El coste de realización del proyecto que se ha calculado parece ser aceptable. Se ha procurado reducir al máximo la posibilidad de que ocurra un imprevisto, ya que el programa está enfocado para el presupuesto de un gabinete pericial y para que finalice en la fecha acordada con la menor variación posible. Se ha de tener en cuenta que la aplicación que se desea desarrollar es una aplicación bastante simple pero, a pesar de ello, facilitará la gestión del gabinete, ahorrando tiempo para este y a la vez, poder dedicar ese tiempo perdido en otras tareas que se encuentren necesarias. No obstante, debido a los cambios realizados en el proyecto (ver apartado 2.5), no se ha podido ajustar el coste previsto del proyecto a la aplicación final, provocando que estos cambios se aplicarán con urgencia para ofrecer un software de buena calidad. 4.1.3. Social Este proyecto tiene como interés ofrecer apoyo a una parte del sector que ha ido decayendo últimamente a una parte de la economía que necesita poder realizar la mayor cantidad de trabajo posible para poder sacar beneficios. A nivel personal me ha ayudado no solo a practicar las herramientas de gestión y creación de proyectos, sino también a prepararme a los posibles problemas que se puedan encontrar al realizar un proyecto para una empresa y poder prepararlo para poder solventar los problemas encontrados y a la vez, estar concienciado que el desarrollo de software tiene un gran impacto para una empresa, en los ámbitos sociales (como interacciona la empresa con el software), económicos (coste de producción) y ambientales (consumo eléctrico, huella de carbono, etc...).

4.2. Vida Útil 4.2.1. Ambiental El proyecto en sí permitirá mejorar la huella ecológica que genera la empresa, fomentando la reducción del consumo del papel que utilizan para guardar los peritajes en formato físico, ya que sus datos se guardarán en formato digital. El motivo de esto es debido a que sus clientes, tienden a eliminar los peritajes realizados, dificultando a los peritos obtener datos de los peritajes ya realizados. Además, al agilizar el proceso de un gabinete pericial, se prevé que también se reduzca el consumo eléctrico.

27

En un principio, se espera que el proyecto utilice un servidor en el cual, los usuarios, accedan a este mediante su ordenador y/o dispositivos inteligentes. 4.2.2. Económico A día de hoy, no se ha calculado el coste de los posibles ajustes, actualizaciones y reparaciones durante la vida útil del proyecto, debido a que el proyecto en sí aun no esta finalizado. No obstante, se prevé que las posibles actualizaciones del proyecto durante su vida útil tengan un impacto económico menor, ya que, al diseñar el software con una arquitectura MVC, facilitará la posibilidad de actualizar el código, y a la vez, añadir nuevas funcionalidades gracias a la modularidad que ofrece. 4.2.3. Social El beneficiario final del proyecto en sí es el gabinete pericial que utilizara el software, ja que este, facilitara el proceso de las diferentes entidades existentes dentro de un gabinete pericial. En un principio, solventa de una manera eficaz el problema planteado inicialmente, ya uno de los motivos del desarrollo del software, es la desconfianza de las soluciones online facilitadas debido a una esperanza de vida útil corta.

4.3. Riesgos 4.3.1. Ambiental A día de hoy, se prevé que una vez finalizado el proyecto, se tenga que aumentar el número de funcionalidades, en el cual, es posible que este tenga que generar un impacto mayor al medio ambiente, teniendo en cuenta un mayor consumo eléctrico y a la vez, calcular la posibilidad de tener que cambiar el equipo informático de desarrollo por otro, reduciendo el impacto a la larga, a pesar de aumentar el impacto medioambiental para obtener un ordenador. Aparte de esto, en caso de que se produzca un abandono por parte del desarrollador, se ofrecerá el código fuente del programa a la empresa, para que el futuro desarrollador no tenga que invertir un mayor número de recursos para desarrollar el mismo software. Cabe comentar que existe la posibilidad de que el cliente al que diseñamos el software, pueda interesarse por otras soluciones, provocando el desarrollo del proyecto un malgasto energético. 4.3.2. Económico En un principio, no se prevé ningún escenario que pueda perjudicar la viabilidad del proyecto, exceptuando retrasos. Estos retrasos, en un principio, no influenciaron el tiempo previsto para conseguir la viabilidad el proyecto, pero aumentó de forma considerable el

28

precio final del desarrollo del software, provocando un posible desagrado por parte de nuestro cliente. Además, si el proyecto alcanza un coste elevado y con un gran número de funciones no implementadas, es posible que el cliente, se decante por otras soluciones, reduciendo al proyecto realizado como un malgasto económico. 4.3.3. Social El proyecto creará un software que se espera que genere dependencia para el negocio, causando una posible debilidad en caso de que el proyecto se dejará de desarrollar, o que necesitará actualizaciones para evitar los posibles fallos en futuras aplicaciones. Para evitar que esto no ocurra en caso de abandono por parte del desarrollador, se ofrecerá el código fuente a la empresa, para así, otro desarrollador de software, se encargue realizar el desarrollo del software y que no se tenga que dedicar a desarrollar un software nuevo. A pesar de ello, el negocio no se espera que sea perjudicial para los trabajadores de los gabinetes, ja que se espera solventar los problemas más comunes que se suelen encontrar en los gabinetes periciales.

4.4. Matriz de sostenibilidad

Proyecto puesto en producción

(PPP)

Vida Útil Riesgos

Dimensión Ambiental

8 10 -5

Dimensión Económica

5 6 -10

Dimensión Social 8 10 -5

Puntuación total 27

29

4.5. Conclusiones de la sostenibilidad del proyecto El proyecto en sí, parece que sea suficientemente sostenible. Durante el desarrollo de producción se ha ido valorando la metodología de de trabajo a seguir, junto con sus componentes físicos, para que el desarrollo de la aplicación resulte el menor impacto posible, obteniendo resultados aceptables. No obstante, al evaluar la vida útil del programa se ha detectado que el proyecto en si, no se cree que haya alcanzado un nivel de sostenibilidad destacable, sobretodo en la dimensión económica, debida a que una vez este proyecto haya finalizado, los usuarios de la aplicación lo irán utilizando mientras que el desarrollador prepara una versión actualizada, con corrección de errores a nivel de interfaz, mejora de rendimiento y sobretodo, funcionalidad que provoque que su viabilidad sea mayor. Por último me gustaría comentar sobre los riesgos encontrados. Durante el desarrollo del proyecto. hemos detectado que la posibilidad de que otras aplicaciones en la web, interesen en un futuro al desarrollador del proyecto antes del fin de la vida útil del software, implicando que el tiempo y recursos dedicados por el desarrollador y el cliente destinatario, acaben volviéndose un derroche. También cabe la posibilidad de que el uso del software que se haya desarrollado cause una gran dependencia al cliente, provocando que, una vez dejado el soporte técnico, implique que este tenga que seguir utilizando un software que no funcione con la fiabilidad que iba antes.

30

31

5. Análisis de requisitos Este apartado contiene los requisitos funcionales y no funcionales a implementar durante el desarrollo del proyecto. El cumplimiento de estos requisitos es imperativo para la obtención del software que el usuario desea. Los requisitos funcionales tienen una prioridad establecida, implicando la necesidad que existe para el usuario de ese requisito.

5.1. Requisitos funcionales

Requisito: Los gestores se encargarán del control de los clientes, introduciendolos junto con sus normas de minuta para los pagos de sus trabajos. Descripción: El sistema permitirá a los gestores de la aplicación introducir los clientes junto con sus métodos de pago para el cálculo de las minutas que se recibirán. Prioridad: 5

Requisito: La administración se encargará del control de usuarios con las opciones de crear, modificar y borrar sus datos. Descripción: El sistema permitirá a los usuarios que sean administradores crear usuarios, junto con la posibilidad de modificar sus datos (incluido las contraseñas) y borrarlos si lo encuentran necesario. Prioridad: 5

Requisito: Los usuarios tendrán la posibilidad introducir y consultar los datos de los diferentes talleres a los que visiten Descripción: Los usuarios tendrán la posibilidad de calcular los datos de las diferentes entidades, permitiendo a los usuarios, consultar y actualizar los datos si lo encuentran necesario. Prioridad: 5

Requisito: Los usuarios tendrán la posibilidad de introducir y modificar peritajes. Descripción: Los peritos serán capaces de introducir peritajes asignados a sí mismos y modificarlos para ir guardando su posteriores trabajos. Los gestores tendrán la posibilidad de crear usuarios y al mismo tiempo, asignarlo a uno de los usuarios que crean necesario. Prioridad: 5

Requisito: Los usuarios tendrán la posibilidad de introducir avances dentro de un peritaje Descripción: Los usuarios podrán introducir en los diferentes peritajes un número ilimitado de avances que representará el motivo de por qué ha de volver a visitar el siniestro. Prioridad: 3

32

Requisito: Para que un peritaje se cierre, el usuario deberá de introducir los datos de cierre en la pantalla de cierre de informe. Descripción: Los usuarios serán capaces de introducir peritajes asignados a sí mismos y modificarlos para aplicar estos datos Prioridad: 5

Requisito: Al cerrarse un peritaje, se generará la base para poder trabajar con la minuta que se percibirá por el cliente Descripción: Al cerrarse un peritaje, se abrirá un registro de minuta que permitirá a los gestores introducir los datos relacionados con la minuta del peritaje cerrado, permitiendo calcular los beneficios de acuerdo al usuario. Prioridad: 5

Requisito: Los gestores podrán listar los peritajes y descargar una versión de hoja de cálculos del listado de todas las minutas creadas. Descripción: Para que los gestores puedan trabajar con herramientas ofimáticas, se incluirá la opción de descargar el listado de todas las minutas ya creadas para así calcular el beneficio que estas obtendrán en una hoja de cálculo. Prioridad: 1

Requisito: Los gestores podrán recibir un resumen de todos los peritajes realizados por los diferentes peritos dentro de un rango de fechas Descripción: Los gestores tendrán la posibilidad de calcular un resumen con las medias de peritación de los peritajes que ha recibido los trabajadores. Prioridad: 2

Requisito: Los gestores podrán calcular la nómina de los peritos según el trabajo realizado para calcular parte de la nómina final Descripción: Los gestores tendrán la posibilidad de calcular parte de la nómina de los peritos y una vez calculada, poder aplicarla a la nómina final de estos. Prioridad: 4

Requisito: Cualquier dato que se elimine en la aplicación, en vez de eliminarse por completo, permanecerán ocultos, sin la posibilidad de modificarlos y usarlos. Descripción: Eliminar datos sin tener una copia puede producir problemas, sobretodo si hay otros objetos que necesiten los datos de esos registros. El motivo es para no romper las relaciones de las clases existentes, manteniendo los datos ya introducidos. Prioridad: 5

33

5.2. Requisitos no funcionales

Requisito: Usabilidad Descripción: La interfaz debe de ser fácil e intuitiva para los usuarios que deseen trabajar con ella. Prioridad: 5

Requisito: Seguridad Descripción: El sistema deberá de contener unos mínimos de seguridad necesarios, para evitar los ataques más comunes a las páginas web, como SQL Injection o DDoS. Prioridad: 5

Requisito: Portabilidad Descripción: El sistema debe de ser utilizado sin la necesidad de que sus usuarios deban de instalarlo. Prioridad: 5

Requisito: Multiplataforma Descripción: El sistema deberá de funcionar en distintos tipos de sistemas operativos y plataformas de hardware. Prioridad: 4

Requisito: Rendimiento Descripción: El sistema deberá soportar la carga de trabajo del gabinete, sin que su experiencia para sus usuarios se vea afectado Prioridad: 3

Requisito: Leyes de protección de datos Descripción: El sistema deberá cumplir con el Reglamento General de Protección de Datos (RGPD). Prioridad: 5

Requisito: Escabilidad Descripción: El sistema ha de ser fácil implementar nuevas funciones, para poder introducir Prioridad: 4

34

35

6. Especificación

6.1. Casos de uso En este apartado estarán listados los casos de uso, con múltiples figuras, que supondrán las funcionalidades deseadas por los usuarios, junto con una tabla de explicación del comportamiento de la funcionalidad

Figura 4: Casos de uso Login y Logout

36

Caso de uso Login

Actor Usuario

Precondición Existe el usuario en el cual se desea acceder

Escenario principal

1. El usuario introduce los datos necesarios para acceder 2. El usuario hace clic en el botón para iniciar sesión 3. El sistema guarda la sesión hasta el cierre de la misma 4. El sistema redirige al usuario a la pantalla principal del menú.

Extensiones 1a. Uno o más campos vacíos 1. El sistema muestra un mensaje que pide al usuario introducir los

datos ya introducidos 2. Ir al paso 1

1b. Datos no válidos 1. El sistema mostrará un mensaje diciendo que no se ha podido

iniciar la sesión 2. Ir al paso 1

1c. Usuario ya registrado 1. Ir al paso 4

Caso de uso Logout

Actor Usuario

Precondición El usuario ha iniciado su sesión en la pantalla principal

Escenario principal

1. El usuario hace clic en el link para cerrar sesión 2. El sistema destruye la sesión del usuario. 3. El sistema redirige al usuario a la pantalla de login.

37

Figura 5: Casos de uso Crear Usuario, Editar Usuario, Borrar Usuario, Introducir

Cliente, Editar Cliente, Borrar Cliente, Introducir Norma Minuta Cliente y Editar Norma Minuta Cliente

38

Caso de uso Crear Usuario

Actor Gestor

Precondición El gestor ha iniciado su sesión en la pantalla principal

Escenario principal

1. El gestor entra en la pantalla de usuarios. 2. El gestor hace clic en el botón “Crear Usuarios” 3. El gestor introduce los datos básicos del usuario, junto con los datos personales del usuario. 4. El gestor le asigna un nombre de usuario y contraseña al usuario. 5. El gestor hace clic en el botón para crear el usuario. 6. El sistema crea el usuario y devuelve al gestor un mensaje confirmando su creación.

Extensiones 5a. Nombre de Usuario ya registrado 1. El sistema mostrará un mensaje de acuerdo que no se ha podido

crear el usuario por los motivos introducidos 2. Ir al paso 4

Caso de uso Editar Usuario

Actor Gestor

Precondición El gestor ha iniciado su sesión en la pantalla principal y existe un usuario.

Escenario principal

1. El gestor entra en la pantalla de usuarios. 2. El gestor hace clic en el enlace de “Editar Usuario” del registro correspondiente 3. El sistema devuelve un formulario con los contenidos del registro a modificar ya introducidos. 4. El gestor actualiza los datos del usuario 5. El gestor hace clic en el botón para guardar los cambios. 6. El sistema guarda las modificaciones y devuelve al gestor un mensaje confirmando su edición.

Extensiones 4a. Nombre de Usuario ya registrado 1. El sistema mostrará un mensaje de acuerdo que no se ha podido

crear el usuario porque ya existe. 2. Ir al paso 3

39

Caso de uso Borrar Usuario

Actor Gestor

Precondición El gestor ha iniciado su sesión en la pantalla principal y existe un usuario.

Escenario principal

1. El gestor entra en la pantalla de usuarios. 2. El gestor hace clic en el enlace de “Borrar Usuario” del registro correspondiente 3. El gestor confirma que desea borrar el usuario 4. El sistema eliminará el registro de la pantalla de usuarios y devuelve al gestor un mensaje confirmando su eliminación

Caso de uso Introducir Cliente

Actor Gestor

Precondición El gestor ha iniciado su sesión en la pantalla principal

Escenario principal

1. El gestor entra en la pantalla de cliente. 2. El gestor hace clic en el botón “Introducir Cliente” 3. El gestor introduce los datos del cliente 4. El gestor hace clic en el botón para guardar el cliente. 5. El sistema crea el registro del cliente y devuelve al gestor un mensaje confirmando que se ha podido crear.

Extensiones 4a. Nombre repetido 1. El sistema mostrará un mensaje de acuerdo que no se ha podido

crear el usuario porque el cliente tiene el mismo nombre que uno ya introducido

2. Ir al paso 4

40

Caso de uso Editar Cliente

Actor Gestor

Precondición El gestor ha iniciado su sesión en la pantalla principal y existe un cliente

Escenario principal

1. El gestor entra en la pantalla de usuarios. 2. El gestor hace clic en el enlace de Editar Cliente del registro correspondiente 3. El sistema devuelve un formulario con los contenidos del registro a modificar ya introducidos. 4. El gestor actualiza los datos del cliente 5. El gestor hace clic en el botón para modificar los datos. 6. El sistema guarda las modificaciones y devuelve al gestor un mensaje confirmando que se ha podido actualizar.

Extensiones 4a. Nombre repetido 3. El sistema mostrará un mensaje de acuerdo que no se ha podido

crear el usuario porque el cliente tiene el mismo nombre que uno ya introducido

4. Ir al paso 4

Caso de uso Borrar Cliente

Actor Gestor

Precondición El gestor ha iniciado su sesión en la pantalla principal y existe un cliente.

Escenario principal

1. El gestor entra en la pantalla de clientes. 2. El gestor hace clic en el enlace de Borrar Cliente del registro correspondiente 3. El gestor confirma que desea borrar el cliente 4. El sistema eliminará el registro de la pantalla de clientes y devuelve al gestor un mensaje confirmando su eliminación.

41

Caso de uso Introducir Norma Minuta Cliente

Actor Gestor

Precondición El gestor ha iniciado su sesión en la pantalla principal y tiene un cliente sin norma de minuta de ese cliente

Escenario principal

1. El gestor entra en la pantalla de usuarios. 2. El gestor hace clic en el enlace de “Añadir Norma”. 3. El gestor introduce los datos básicos del usuario, junto con los datos personales del usuario. 4. El gestor hace clic en el botón para introducir la norma. 5. El sistema guarda las norma y devuelve al gestor el mensaje confirmando que se ha podido crear.

Extensiones 4a. La norma ya existe 1. El sistema mostrará un mensaje de acuerdo al contenido

introducido 2. Ir al paso 3

Caso de uso Editar Norma Minuta Cliente

Actor Gestor

Precondición El gestor ha iniciado su sesión en la pantalla principal y tiene una norma de minuta de uno de sus clientes ya definida

Escenario principal

1. El gestor entra en la pantalla de usuarios. 2. El gestor hace clic en el enlace de Editar Norma de los registros aplicados 3. El sistema devuelve un formulario con los contenidos del registro a modificar ya introducidos. 4. El gestor actualiza los datos del registro 4. El gestor hace clic en el botón para actualizar la norma 5. El sistema guarda las norma y devuelve al gestor un mensaje confirmando su edición.

Extensiones 5a. La norma ya existe 1. El sistema mostrará un mensaje de error relacionado al contenido


42

Figura 6: Casos de uso Introducir Taller, Editar Taller, Borrar Taller, Introducir

Peritaje, Editar Peritaje, Crear Avance, Cerrar Peritaje y Crear Minuta

43

Caso de uso Introducir Taller

Actor Usuario


Escenario principal

1. El usuario entra en la pantalla de usuarios. 2. El usuario hace clic en el enlace de “Introducir Taller” de los registros aplicados 3. El usuario introduce los datos del taller 4. El usuario hace clic en el botón para introducir el taller 5. El sistema guarda los datos y devuelve al usuario el mensaje confirmando su creación

Extensiones 4a. Falta de datos 1. El sistema mostrará un mensaje de error informando la falta de

datos 2. Ir al paso 3

Caso de uso Editar Taller

Actor Usuario

Precondición El usuario ha iniciado su sesión en la pantalla principal y tiene un Taller introducido

Escenario principal

1. El usuario entra en la pantalla de usuarios. 2. El usuario hace clic en el enlace de “Editar Taller” de los registros aplicados 3. El sistema devuelve un formulario con los contenidos del registro a modificar ya introducidos. 4. El usuario introduce los datos básicos del usuario, junto con los datos personales del usuario. 5. El usuario hace clic en el botón para actualizar el taller 6. El sistema actualiza el registro y devuelve al gestor el mensaje confirmando su creación

Extensiones 5a. Falta de datos 1. El sistema mostrará un mensaje de error informando la falta de

datos 2. Ir al paso 4

44

Caso de uso Borrar Taller

Actor Usuario


Escenario principal

1. El usuario entra en la pantalla de clientes. 2. El usuario hace clic en el enlace de “Borrar Taller” del registro correspondiente 3. El usuario confirma que desea borrar el taller 4. El sistema eliminará el registro y devuelve al gestor un mensaje confirmando su eliminación

Caso de uso Introducir Peritaje

Actor Usuario


Escenario principal

1. El usuario entra en la pantalla de introducción de peritajes. 2. El usuario introduce los datos básicos del usuario, junto con los datos personales del usuario. 3. El usuario hace clic en el botón para introducir la norma 4. El sistema guarda las norma y devuelve al gestor el mensaje confirmando su creación

Extensiones 3a. No se han introducido los datos necesarios 1. El sistema mostrará un mensaje de error relacionado al contenido


45

Caso de uso Editar Peritaje

Actor Usuario


Escenario principal

1. El usuario entra en la pantalla de listado de peritajes. 2. El usuario hace clic en el enlace de Editar Peritaje de los registros aplicados 3. El sistema devuelve un formulario con los contenidos del registro a modificar ya introducidos. 4. El usuario introduce los datos básicos del usuario, junto con los datos personales del usuario. 5. El usuario hace clic en el botón para guardar los cambios 6. El sistema guarda las norma y devuelve al gestor el mensaje confirmando su creación

Extensiones 5a. No se han introducido los datos necesarios 1. El sistema mostrará un mensaje de error relacionado al contenido


Caso de uso Crear Avance

Actor Usuario

Precondición El usuario ha iniciado su sesión en la pantalla principal, tiene un peritaje ya creado y este no se encuentra en un estado de cierre

Escenario principal

1. El usuario entra en la pantalla de usuarios. 2. El usuario hace clic en el enlace de Editar Norma de los registros aplicados 3. El usuario introduce los datos básicos del usuario, junto con los datos personales del usuario. 4. El gestor hace clic en el botón para introducir la norma 5. El sistema guarda las norma y devuelve al gestor el mensaje confirmando su creación

Extensiones 4a. Falta de datos 1. El sistema mostrará un mensaje de error relacionado al contenido


46

Caso de uso Cerrar Peritaje

Actor Usuario

Precondición El usuario ha iniciado su sesión en la pantalla principal y tiene un peritaje introducido.

Escenario principal

1. El usuario entra en la pantalla de listado de peritajes. 2. El usuario hace clic en el enlace de Editar Peritaje de los registros aplicados 3. El sistema devuelve un formulario con los contenidos del registro a modificar ya introducidos. 4. El usuario accede a la pestaña de cierre de peritaje 5. El usuario introduce los datos relacionados con el cierre del peritaje 6. El usuario hace clic en el botón para guardar y cerrar el peritaje. 7. El sistema guarda el peritaje y devuelve al gestor el mensaje confirmando su cierre

Extensiones 4a. El peritaje no tiene un estado de cierre 1. El sistema no dejará finalizar el cierre del peritaje, provocando

que este no pueda ser finalizado. 2. El usuario actualiza el peritaje, definiendo un motivo de cierre. 3. Ir al paso 4

Caso de uso Crear Minuta

Actor Usuario

Precondición El usuario ha iniciado su sesión en la pantalla principal y ha cerrado un peritaje

Escenario principal

1. El sistema crea la minuta utilizando los datos del cierre del peritaje que ha introducido el usuario junto con las normas de minutas del cliente que se realizó el peritaje.

47

Figura 7: Casos de uso Editar Minutas, Introducir Norma Minuta Perito, Editar Norma

Minuta Perito, Calcular Medias Peritación y Calcular Estadísticas Generales

48

Caso de uso Editar Minutas

Actor Gestor

Precondición El gestor ha iniciado su sesión en la pantalla principal y existe una minuta

Escenario principal

1. El gestor entra en la pantalla de minutas. 2. El gestor hace clic en la minuta que desea editar. 3. El gestor actualiza los datos de la minuta. Estos datos no son los mismos que se utilizaron para crear la minuta. 7. El sistema guarda las norma y devuelve al gestor el mensaje confirmando su creación

Extensiones 4a. La regla ya existe 1. El sistema mostrará un mensaje de error relacionado al contenido


Caso de uso Buscar Minutas

Actor Gestor

Precondición El gestor ha iniciado su sesión en la pantalla principal y tiene una norma de minuta ya definida

Escenario principal

1. El gestor entra en la pantalla de usuarios. 2. El gestor hace clic en el enlace de Editar Norma de los registros aplicados 3. El gestor introduce los datos básicos del usuario, junto con los datos personales del usuario. 4. El gestor hace clic en el botón para introducir la norma 5. El sistema guarda las norma y devuelve al gestor el mensaje confirmando que se ha podido crear.

Extensiones 4a. La regla ya existe 1. El sistema mostrará un mensaje de error relacionado al contenido


49

Caso de uso Introducir Norma Minuta Perito

Actor Gestor

Precondición El gestor ha iniciado su sesión en la pantalla principal y tiene un cliente sin norma de minuta para perito

Escenario principal

1. El gestor entra en la pantalla de usuarios. 2. El gestor hace clic en el enlace de “Añadir Norma”. 3. El gestor introduce los datos básicos del usuario, junto con los datos personales del usuario. 4. El gestor hace clic en el botón para introducir la norma. 5. El sistema guarda las norma y devuelve al gestor el mensaje confirmando que se ha podido crear.

Extensiones 4a. La norma ya existe 1. El sistema mostrará un mensaje de acuerdo al contenido


Caso de uso Editar Norma Minuta Perito

Actor Gestor

Precondición El gestor ha iniciado su sesión en la pantalla principal y tiene una norma de minuta para peritos ya definida

Escenario principal

1. El gestor entra en la pantalla de usuarios. 2. El gestor hace clic en el enlace de “Editar Norma” de los registros aplicados 3. El sistema devuelve un formulario con los contenidos del registro a modificar ya introducidos. 4. El gestor actualiza los datos del registro 4. El gestor hace clic en el botón para actualizar la norma 5. El sistema guarda las norma y devuelve al gestor un mensaje confirmando su edición.

Extensiones 5a. La norma ya existe 3. El sistema mostrará un mensaje de error relacionado al contenido


50

Caso de uso Calcular Medias Peritación

Actor Gestor

Precondición El gestor .ha iniciado su sesión en la pantalla principal y existe una o más minutas (o peritajes finalizados)

Escenario principal

1. El gestor entra en la pantalla de Medias de peritación. 2. El gestor hace clic en el enlace de buscar. 3. El gestor introduce en el formulario los filtros que desea introducir para aplicar el cálculo. 4. El gestor hace clic en el botón para realizar la búsqueda. 5. El sistema guarda las norma y devuelve al gestor el mensaje, confirmando que se ha podido crear.

Extensiones 4a. Falta de datos de búsqueda necesarios 5. El sistema mostrará un mensaje de error relacionado al contenido


Caso de uso Calcular Estadísticas Generales

Actor Gestor

Precondición El gestor ha iniciado su sesión en la pantalla principal y existe al menos un peritaje.

Escenario principal

1. El gestor entra en la pantalla de Medias de peritación. 2. El gestor hace clic en el enlace de buscar. 3. El gestor introduce en el formulario los filtros que desea introducir para aplicar el cálculo. 4. El gestor hace clic en el botón para realizar la búsqueda. 5. El sistema guarda las norma y devuelve al gestor el mensaje, confirmando que se ha podido crear.

Extensiones 4a. Falta de datos de búsqueda necesarios 7. El sistema mostrará un mensaje de error relacionado al contenido


51

6.2. Modelo Conceptual En este apartado contiene el modelo conceptual a implementar gráficamente mostrado del software deseado.

Figura 8: Modelo conceptual de la aplicación

52

Restricciones

● Cada clase tiene un identificador único. ● Cada clase contiene una fecha de creación, modificación y eliminación. Estos

campos pueden ser nulos y si la fecha de eliminación no es nula se considerará eliminado.

● El campo Nombre de la clase Cliente ha de ser único. ● El campo Nombre de la clase Taller ha de ser único. ● El campo ExpCliente de la clase Peritaje ha de ser único. ● El campo Username de la clase Usuario ha de ser único. ● El campo FechaInicio de la clase Avance debe de ser menor que el campo

FechaProximaVisita. ● El campo FechaCominicación de la clase Peritaje debe de ser menor que el campo

FechaPeritaje . ● El campo FechaPeritaje de la clase Peritaje debe de ser menor que el campo

FechaCierre. ● Para poder Introducir la FechaCierre en la clase Peritaje , esta clase tiene que tener

asignado un cliente , a un usuario que sea perito y también que el campo EstadosPeritaje de peritaje, pertenezca a la enumeración EstadosCierre.

53

7. Diseño

7.1. Arquitectura del sistema Para el desarrollo de la aplicación se decantó por utilizar la arquitectura MVC . El propósito 8

principal de esta arquitectura es separar la interfaz del usuario con la parte lógica de la aplicación. Gracias a ello, nos aseguraremos que los cambios que hayamos aplicado no tengan efectos secundarios en otras partes de la aplicación.

Figura 9: Esquema una petición a una aplicación con una arquitectura MVC

Para entender el procedimiento de la arquitectura MVC primero se debería explicar qué es cada objeto de la arquitectura. Routes Representa el patrón de URIs que el usuario puede introducir. Cada ruta tiene asignado 9

uno o varios métodos, en los cuales cada método tiene asignado una función de la capa de Controller. Estas rutas solo se aplican después de la introducción del nombre del domino.

8 Model View Controller 9 Uniform Resource Identifier : Identifica los recursos de la red con una cadena de caracteres para facilitar el acceso por parte de usuarios

54

Controller Representa el comportamiento de la aplicación que tendrá nuestro software. Su función servirá para tratar los datos de la petición, obtener los datos necesarios para la respuesta, tratarlos y una vez hecho, aplicarlos en la capa de View para devolver un resultado gráfico al usuario. Model Representa la información que se queda almacenada en la aplicación, como los Usuarios. Los modelos tienen la responsabilidad de controlar los datos en las cuales, se encargan de añadir, modificar o borrar datos de la aplicación. View Representa el resultado gráfico que recibe del usuario. Esta contendrá plantillas en las cuales, dependiendo de la información que reciba de la capa Controller, los datos de esta interfaz variarán. También cabe comentar que esta capa, a parte de ofrecer los datos de la capa Model, tambíen se encargará de proveer una interfaz gráfica, en la cual deberá de permitir al usuario poder navegar por la aplicación.

55

7.2. Diseño de Interfaces 7.2.1. Diagrama de navegación

Figura 10 : Diagrama de flujo de la aplicación

56

Para simplificar el diagrama se tendrán en cuenta estas restricciones: ● Todas las views contienen una barra de navegación que permite navegar a los

usuarios a las páginas asociadas con la view Menu. ● Los usuarios podrán navegar sin tener en cuenta las restricciones de acceso por

privilegios. 7.2.2. Imágenes de la interfaz aplicada Este apartado contiene capturas de imágenes creada, mostrando la interfaz gráfica implementada. El objetivo de este apartado es para que el lector pueda hacerse una idea de la interfaz implementada.

Figura 11: Pantalla de inicio de sesión

Figura 12: Pantalla de inicio de sesión - Mensaje de carga

57

Figura 13: Pantalla de inicio de sesión - Mensaje de error

Figura 14: Barra de navegación

Figura 15: Barra de navegación - Desplegable de las opciones de “Administración”

Figura 16: Barra de navegación - Desplegable de la opción “Peritajes”

58

Figura 17: Pantalla de usuarios

59

Figura 18: Formulario emergente para crear un usuario

60

Figura 19: Formulario emergente para buscar usuarios

Figura 20: Formulario emergente para editar usuarios

61

Figura 21: Formulario Eliminar Usuarios

Figura 22: Pantalla de Clientes

Figura 23: Formulario para Introducir un Cliente

62

Figura 24: Formulario para Actualizar un Cliente

63

Figura 25: Formulario para Buscar Clientes

64

Figura 26: Formulario para Introducir un Cliente

Figura 27: Pantalla de Normas Minutas Clientes

65

Figura 28: Pantalla de Introducción de una Norma para las minutas de los clientes

66

Figura 29: Pantalla de Edición de una Norma para las minutas de los clientes

Figura 30: Pantalla de Edición de una Norma para las minutas de los clientes

67

Figura 31: Pantalla de Búsqueda de normas para las minutas de los clientes

Figura 32: Pantalla de Introducción de normas para las minutas de los peritos

68

Figura 33: Pantalla de Edición de normas para las minutas de los peritos

Figura 34: Pantalla de Búsqueda de normas para las minutas de los peritos

69

Figura 35: Pantalla de talleres

Figura 36: Pantalla de introducción de talleres

70

Figura 37: Pantalla de búsqueda de talleres

Figura 38: Pantalla de edición de un taller

71

Figura 39: Pantalla de eliminación de un taller

Figura 40: Pantalla de cálculo de estadísticas Generales - Vacio

Figura 41: Pantalla de búsqueda para calcular las estadísticas generales

72

Figura 42: Pantalla de cálculo de estadísticas Generales - Resultados

Figura 43: Pantalla de medias de peritación - Vacío

Figura 44: Pantalla de búsqueda para calcular las medias de peritación

73

Figura 45: Pantalla de medias de peritación - Resultados

Figura 46: Pantalla creación de peritajes

74

Figura 47: Pantalla de listado de peritajes

Figura 48: Pantalla de búsqueda de peritajes

75

Figura 49: Pantalla de edición de peritajes - Datos Generales

Figura 50: Pantalla de edición de peritajes - Avancés - Vacio

76

Figura 51: Pantalla de edición de peritajes - Avancés - Formulario de creación

Figura 52: Pantalla de edición de peritajes - Avancés - Con Registros

77

Figura 53: Pantalla de edición de peritajes - Datos generales - Proceso de cierre de un

peritaje 1

Figura 54: Pantalla de edición de peritajes - Cierre de informe - Proceso de cierre de un peritaje 2

78

Figura 55: Pantalla de edición de peritajes - Introducción y edición de valores de

Minutas no automáticos - Proceso de cierre de un peritaje 3

Figura 56: Pantalla de listado de minutas.

79

7.3. Diseño Interno 7.3.1. Frameworks y estructura del código interno Para agilizar el proceso de desarrolla y al mismo tiempo, utilizar una arquitectura MVC (ver apartado 7.1) se ha decidido utilizar el framework Revel. Este framework ofrece una gran facilidad en la producción de una página web. No obstante, al estar en una fase que se considera como prototipo (v0.19.0) este puede estar tentado a cambios que requiera la refactorización del código. No obstante, la mayor ventaja que ofrece este framework frente a otros, como Iris [12], es que Revel ofrece soporte a la arquitectura MVC, un factor decisivo al escoger este framework, a pesar de que, su documentación es bastante pobre, con ejemplos desactualizados.

Figura 57: Logotipo de Revel

A pesar de las ventajas que ofrecía revel, no poseía ORM . Debido a que se quería dar un 10

soporte a cualquier tipo de base de datos, se consideró mirar las diferentes librerías existentes para facilitar el uso de un ORM. Entre todas las opciones visibles, la más completo, a día de hoy, era GORM. Ofrece múltiples ventajas, entre ellas, la flexibilidad de definir constraints gracias a las etiquetas de las variables de los modelos, ofreciendo la posibilidad de definir los datos de las columnas y sus restricciones en la misma variable, pero por desgracia, no ofrece soporte para la creación de claves foráneas.

10 Object-Relational mapping : Permite utilizar el modelo de datos utilizada por el programa para crear una base de datos relacional

80

Figura 58: Ejemplo de la estructura de datos del modelo de Cliente

81

7.3.2. Diagrama de secuencia Este apartado contiene todo el apartado lógico que se ha aplicado a la aplicación. Hay que comentar que debido a las limitaciones que se ha visto del lenguaje de programación usado (apartado 8.1), puede que el resultado aplicado sea ligeramente diferente para aplicar la misma lógica. Inicio de sesión

Figura 59: Diagrama de secuencia del caso de uso “Inicio de sesión”

82

Cerrar sesión

Figura 60: Diagrama de secuencia del caso de uso “Cerrar sesión”

Crear Usuario

Figura 61: Diagrama de secuencia del caso de uso “Cerrar sesión”

83

Editar Usuario

Figura 62: Diagrama de secuencia del caso de uso “Editar Usuario”

84

Borrar Usuario

Figura 63: Diagrama de secuencia del caso de uso “Borrar Usuario”

85

Introducir Cliente

Figura 64: Diagrama de secuencia del caso de uso “Introducir Cliente”

86

Editar Cliente

Figura 65: Diagrama de secuencia del caso de uso “Editar Cliente”

87

Borrar Cliente

Figura 66: Diagrama de secuencia del caso de uso “Borrar Cliente”

88

Introducir Norma Minuta Cliente

Figura 67: Diagrama de secuencia del caso de uso “Introducir Norma Minuta Cliente”

89

Editar Norma Minuta Cliente

Figura 68: Diagrama de secuencia del caso de uso “Editar Norma Minuta Cliente”

90

Introducir Taller

Figura 69: Diagrama de secuencia del caso de uso “Introducir Taller”

91

Editar Taller

Figura 70: Diagrama de secuencia del caso de uso “Editar Taller”

92

Borrar Taller

Figura 71: Diagrama de secuencia del caso de uso “Borrar Taller”

93

Introducir Peritaje

Figura 72: Diagrama de secuencia del caso de uso “Introducir Peritaje”

94

Editar Peritajes

Figura 73: Diagrama de secuencia del caso de uso “Editar Peritaje”

95

Crear Avances

Figura 74: Diagrama de secuencia del caso de uso “Crear Avances”

96

Cerrar Peritaje

Figura 75: Diagrama de secuencia del caso de uso “Cerrar Peritaje”

97

Crear Minuta

Figura 76: Diagrama de secuencia del caso de uso “Crear Minuta”

98

Editar Minutas

Figura 77: Diagrama de secuencia del caso de uso “Editar Minutas”

99

Introducir Norma Minuta Perito

Figura 78: Diagrama de secuencia del caso de uso “Introducir Norma Minuta Perito”

100

Editar Norma Minuta Perito

Figura 79: Diagrama de secuencia del caso de uso “Editar Norma Minuta Perito”

101

Calcular Medias Peritación

Figura 80: Diagrama de secuencia del caso de uso “Calcular Medias Peritación” Calcular Estadísticas Generales El procedimiento es el mismo, cambiando algunos valores del cálculo de medias con otro controlador llamado EstadisticasGenerController

102

103

8. Implementación

8.1. Software utilizado Golang Golang (también llamado Go para simplificar) es un lenguaje de programación “Orientado a Objetos” inspirando en C. Este lenguaje de programación ha sido desarrollado por Google, encontrándose entre sus diseñadores iniciales Rob Pike y Ken Thompson (conocidos por participar en el desarrollo del sistema operativo UNIX). Este lenguaje de programación, en comparación con otros, no utiliza objetos, si no que utiliza estructuras para poder almacenar sus datos y a la vez, implementar funciones que utilizan esos datos, provocando un comportamiento parecido. [13] A pesar de la desventaja que puede suponer, el código que genera, es muy eficiente, requiriendo muy pocos ciclos para procesar las peticiones, junto con un bajo consumo de memoria RAM, haciéndolo idóneo para entornos donde se necesite la mayor eficiencia posible.

104

Las diferencias que posee Go con un lenguaje de programación orientado a objetos son muchas. Debido a ello, para hacer una comparativa de las diferencias que tiene, nos basaremos en las funcionalidades ofrecidas por Java[14]:

1. Go no posee clases con constructoras. En vez de instanciar métodos, herencias de clases, y búsqueda dinámica de métodos, Go provee estructuras e interfaces para implementar objetos.

2. Go ofrece punteros para valores de todos los tipos, no solo objetos y matrices. 3. Go ofrece funciones que devuelven cualquier tipo, sin necesidad de crear objetos

para devolver múltiples variables. 4. Las matrices de Go son valores. Cuando una matrizes usado como un parámetro de

función, la función puede recibir una copia de la matriz, no un puntero si el programador lo desea. También ofrece soporte a matrices dinámicas (sin tamaño fijo).

5. Las cadenas de caracteres están provistas por el lenguaje de programación, sin necesidad de una librería externa.

6. Las tablas de hash están provistas en el lenguaje de programación sin necesidad de una librería externa. En Go se llaman maps .

7. Go no utiliza excepciones para controlar errores. En vez de ello, ofrece al desarrollador variables tipo error en las cuales devuelven los errores relacionados con la función.

8. Go no acepta sobrecarga de funciones. Las funciones y métodos han de tener nombres únicos.

9. Go no posee variables finales. 10. Go no posee aritmética de punteros. Esto ofrece que no se pueda obtener una

dirección ilegal para que sea usada de forma incorrecta, además de facilitar el recolector de basura.

11. En Go es opcional el uso del carácter punto y coma “;” al final de una instrucción. 12. La publicidad de estructuras, funciones y variables van definidas por la primera letra,

siendo la primera en mayúscula una entidad pública, mientras que una en minúscula se define como una clase privada.

Git Herramienta de control de versiones del código que nos permite controlar las versiones del código implementado tal como se ha declarado en la metodología de trabajo utilizando Git Workflow (apartado 3.3). Google Drive Google Drive es una servicio en la nube ofrecida por Google con múltiples herramientas ofimáticas integradas en ellas. Este servicio está disponible a aquellos que tengan una cuenta google. Durante el desarrollo del proyecto, se ha ido utilizando este servicio para la creación de la documentación del código, junto con sus diagramas y sus hojas de cálculo, además de

105

ofrecer la posibilidad de ofrecer descargar de documentación online sin tener que buscar un servicio de descargar como MEGA o Dropbox . JQuery JQuery es una librería rápida, ligera y con múltiples herramientas para Javascript. Esta librería no solo facilita la escritura del código, si no que además incluye funciones que facilitan la creación de implementaciones complejas (Ej: Conexiones AJAX) o la posibilidad de realizar animaciones con el documento HTML. Aparte de las ventajas que ofrece, esta librería es necesaria para el uso de Bootstrap. Bootstrap Framework web que permite crear diseños de interfaces web que utilicen HTML, CSS y JavaScript. Facilita la creación de interfaces gráficas para el uso de los usuarios, permitiendo Trello Software de administración y organización de proyectos en la nube. Emplea el sistema kanban para el registro de actividades utilizando tarjetas virtuales para organizar sus tareas en las cuales se cuelgan en un tablón virtual solo visible a aquellos que estén relacionados con el proyecto. Ofrece extensiones para poder expandir su funcionalidad, como evaluación del coste de cada tarjeta virtual. Durante el desarrollo del proyecto, hemos utilizado una metodología de trabajo Scrum (ver apartado 3.1) Atom Editor de código fuente de código abierto con soporte para plugins y control de versiones de Git integrado. Es una aplicación de escritorio construida utilizando tecnologías web. Gracias al soporte con plug-ins se pudo desarrollar el software del TFG sin ningún problemas gracias al plug-ins que permiten al editor de texto trabajar con el lenguaje de programación Go con las facilidades que se ofrecerían en un entorno de desarrollo como IntelliJ IDEA.

106

8.2. Despliegue del software El software se entregará como un ejecutable. El servidor que hospede el software, debe de configurarse para ejecutar este programa como un servicio. Una vez configurado, junto con los parámetros de configuración del sistema aplicados correctamente (encontrados en el entregable en el fichero de configuración app.conf que se encuentra en el directorio src/proyecto/conf/. Una vez configurado correctamente, de acuerdo a las necesidades del desarrollo del software, los usuarios podrán acceder introduciendo la URI asignado al servidor. El rango de acceso lo definirá el administrador del sistema, en el cual, se le ha recomendado, por medidas de seguridad, no implementar el acceso a través de Internet hasta que el software cumpla unos protocolos de seguridad necesarios para su uso, entre ellos, se recomendaría como mínimo la implementación del protocolo TLS . 11

11 Transport Layer Security: Aplica un cifrado a la conexión para proporcionar comunicaciones seguras en la red.

107

9. Testing

9.1. Test unitarios Siguiendo la metodología ágil, se ha diseñado la implementación de tests unitarios en cada historia de usuario para asegurar la calidad del proyecto siguiendo la metodología de desarrollo TDD (ver apartado 3.3). No obstante, se han encontrado dificultades de implementación de la parte de los tests de controladores. Debido a esto, para evitar una falta de funcionalidades, se ha enfocado en la implementación de los tests unitarios a nivel de modelo, sin probar por completo el funcionamiento de los controladores. A pesar de ello, debido a que el trabajo es realizado por un único desarrollador, se espera que los cambios que se vayan implementando durante el desarrollo no afecten de forma negativa a las funcionalidades ya implementadas.

9.2. Rendimiento Este proyecto ha sido creado y probado en un entorno local de pruebas. Consecuentemente, las pruebas de rendimiento no se han realizado debido a que necesitamos probarlo en la maquina del entorno de producción, y comprobar cómo de rápido responde a una gran demanda de peticiones. Esto es necesario debido a que la maquina del entorno de trabajo no solo ejecutara la aplicación, si no también un conjunto de herramientas de software que el gabinete encuentra necesarias.

9.3. Usabilidad La página se ha ido probando y desarrollando de acuerdo a la usabilidad recomendada por el dueño del gabinete pericial. Las pruebas de los prototipos han recibido opiniones positivas por parte del dueño, suponiendo por parte del dueño, el programa desarrollado se encuentra suficientemente aceptable. No obstante, es necesario que los trabajadores del gabinete utilicen y evalúen la usabilidad del software, ya que resulta necesario escuchar la opinión de todos los usuarios para poder conocer si el software desarrollado ofrece la usabilidad necesaria. También cabe comentar que el desarrollador ha ido probando la usabilidad de este software para ofrecer ideas de usabilidad que encontraría necesarias para los usuarios.

108

109

10. Conclusiones

10.1. Conclusiones finales La mayoría de los objetivos deseados han sido cumplidos. Estos objetivos son los siguientes:

● Desarrollar una plataforma para la introducción de datos para un gabinete. ● Implementar un sistema de cálculo de minutas para facilitar a la gestión del gabinete

el cálculo de minutas tanto por los peritajes que se cobran de los clientes, como para los pagos que se han de realizar a los peritos.

Además de cumplir los objetivos específicos del proyecto, también se han cumplido (en cierta medida) las competencias técnicas. Las competencias y su motivo de cumplimiento son los siguientes:

● Desarrollar, mantener y evaluar sistemas y servicios de software complejos y/o críticos: Necesario para desarrollar cualquier tipo de software. Desde el comienzo del proyecto, hemos definido desarrollado y probado un proyecto complejo, cumpliendo su objetivo al definir su arquitectura y sus funcionalidades.

● Dar solución a problemas de integración en función de las estrategias, de los estándares y de las tecnologías disponibles: Actualmente, existen muchos estándares y tecnologías disponibles en las cuales nos facilitan el proceso de trabajo, agilizando el proceso y permitiendo añadir más funcionalidades al software en un tiempo menor y/o aumentar la calidad de las funcionalidades con estrategias de desarrollo como las metodologías ágiles, software como Frameworks y estándares como REST API.

● Identificar, evaluar y gestionar los riesgos potenciales asociados a la construcción de software que se puedan presentar: El coste del proyecto ha sido calculado, medido en tiempo y controlado con los recursos disponibles. Al utilizar una metodología ágil como scrum, nos ha permitido ser más flexible al permitirnos evitar posibles riesgos.

● Desarrollar, mantener y evaluar servicios y aplicaciones distribuidas con soporte de red: Este proyecto se enfoca en desarrollar una aplicación que ofrece un servicio en una intranet de una empresa. Este servicio, tiene que estar disponible para múltiples usuarios.

● Especificar, diseñar, implementar y evaluar bases de datos: Cuando se consideraba la implementación del proyecto, uno de los factores clave a tener en cuenta para que su desarrollo fuera correcto, era el diseño de una base de datos funcional. Durante el transcurso del proyecto, gracias al framework revel, se nos permite utilizar el código que generemos para cualquier base de datos que esta pueda dar soporte.

● Controlar la calidad y diseñar pruebas en la producción del software: Necesario para aplicar la metodología de desarrollo a base de pruebas. No se ha cumplido con el objetivo personal esperado, pero no obstante, se cree que el nivel de cumplimiento declarado se cumple sin ningún problema.

110

● Definir y gestionar los requisitos de un sistema de software: La idea del proyecto ha sido ofrecida por el dueño de un gabinete pericial, en el cual este, nos pide un software en el cual, tenemos que detectar los requisitos para poder trabajar con ellos.

Personalmente, el desarrollo de este proyecto ha sido un completo desafío, ya que ha sido un proyecto en el cual, he desarrollado completamente por mi mismo desde cero. Para comenzar, la elección de una metodología ágil fue una decisión acertada para poder apreciar el progreso del proyecto, además de ofrecer flexibilidad en según qué iteraciones para poder compaginar con otras asignaturas matriculadas. Además, el desarrollo de un sistema que en un principio me era completamente desconocido me ha ayudado a identificar posibles errores en futuros proyectos. En resumen, hemos desarrollado un software funcional para una empresa que requería de unos requisitos muy específicos. A pesar de ello, se han ido encontrando durante la marcha un número mayor de requisitos para que el el software final, cumpliera todos los requisitos. Debido a ello, se espera que una vez se haya finalizado este proyecto, pueda dedicarme a finalizar el software por completo.

10.3. Futuro del proyecto El proyecto en sí, una vez terminado el TFG, continuará su desarrollo, ofreciendo nuevas funcionalidades para que este acabe en un estado en el cual sea completamente funcional. Entre ellas, las mejoras a implementar se encuentran las siguientes

● Cálculo de minuta por los KMs recorridos por los peritos. ● Sistema de facturación. ● Implementación de interfaces adaptada para smartphones. ● Mejorar el código, como implementar tests para probar por completo la funcionalidad

de los controladores. ● Incluir una o múltiples imágenes en los diferentes peritajes.

Aparte de estas mejoras comentadas, necesitaremos mirar la posibilidad de que una vez que el sistema sea completamente estable, tenga la posibilidad de que este sea accesible fuera de la intranet, para que los usuarios puedan acceder sin la necesidad de tener que desplazarse físicamente al gabinete pericial o de depender de servicios remotos.

111

11. Bibliografía

11.1. Fuentes de datos [1] XT50, un programa hecho por y para la pericia (n.d.). Retrieved March 02, 2018, from http://www.xt50.es/xt50.html [2] APCAS Data Quienes Somos (n.d). Retrieved March 02, 2018, http://www.xt50.es/quienes-somos.html [3] APCAS Asociación de Peritos de Seguros y Comisarios de Averías (n.d.). Retrieved March 02, 2018, from https://www.apcas.es [4] XT50, Preguntas Frequentes (FAQ) (n.d.). Retrieved March 02, 2018 from http://www.xt50.es/faqs.html [5] Precio del kWh (n.d.). Retrieved April 7, 2018 from https://tarifasgasluz.com/faq/precio-kwh#para-potencias-electricas-mayores-10-kw [6] Tipos de IVA en España. (2018, February 13). Retrieved April 07, 2018 from http://gestron.es/tipos-impositivos-iva-en-espana/ [7] REGLAMENTO GENERAL DE PROTECCIÓN DE DATOS. (n.d.). Retrieved May 19, 2018 from http://www.agpd.es/portalwebAGPD/temas/reglamento/index-ides-idphp.php [8] Qué es SCRUM. (2018, February 04). Retrieved from https://proyectosagiles.org/que-es-scrum/ http://www.etnassoft.com/2011/07/27/tests-unitarios-cuando-usarlos-y-pistas-para-conseguir-un-sistema-robusto/ [9] Tests Unitarios. Cuándo usarlos y pistas para conseguir un sistema robusto. (n.d.). Retrieved Retrieved March 02, 2018 from http://www.etnassoft.com/2011/07/27/tests-unitarios-cuando-usarlos-y-pistas-para-conseguir-un-siste [10] Revel Testing. (n.d.). Retrieved March 02, 2018 from https://revel.github.io/ [11] Lambert, S. (n.d.). A Git Workflow for Solo Projects. Retrieved March 03, 2018 from https://sdlambert.github.io/2015/04/09/git-workflow-for-solo-development/ [12] Iris vs Revel 2018 Comparison. (n.d.). Retrieved June 25, 2018 from https://stackshare.io/stackups/revel-vs-iris [13] Francia, S. (2014, June 09). Is Go an Object Oriented language? Retrieved June 25, 2018 from http://spf13.com/post/is-go-object-oriented/ [14] Nilsson, S. (n.d.). Go vs. Java: 14 main differences. Retrieved June 24, 2018 from https://yourbasic.org/golang/go-vs-java/

11.2. Fuentes de tablas [Tabla 1: Presupuesto original del programa] Jorge A. F., Presupuesto Inicial. (2018). Retrieved 25 June, 2018 from https://docs.google.com/spreadsheets/d/1XwgOFQi_FTspd9PaQkf-uiUnk1X8JnvufK3alOgwYHY/edit?usp=sharing [Tabla 2: Presupuesto actualizado del programa] Jorge A. F.,Presupuesto Final (2018). Retrieved May 20, 2018, from https://docs.google.com/spreadsheets/d/1f3hDMdJaABGTIsqDBcSRsmAEjHv7iim2lryL1hwn2mk/edit?usp=sharing

112

http://www.xt50.es/xt50.html

http://www.xt50.es/quienes-somos.html

https://www.apcas.es/

http://www.xt50.es/faqs.html

https://tarifasgasluz.com/faq/precio-kwh#para-potencias-electricas-mayores-10-kw

http://gestron.es/tipos-impositivos-iva-en-espana/

http://www.agpd.es/portalwebAGPD/temas/reglamento/index-ides-idphp.php

https://proyectosagiles.org/que-es-scrum/

http://www.etnassoft.com/2011/07/27/tests-unitarios-cuando-usarlos-y-pistas-para-conseguir-un-sistema-robusto/



https://revel.github.io/

https://sdlambert.github.io/2015/04/09/git-workflow-for-solo-development/

https://stackshare.io/stackups/revel-vs-iris

http://spf13.com/post/is-go-object-oriented/

https://yourbasic.org/golang/go-vs-java/

https://docs.google.com/spreadsheets/d/1XwgOFQi_FTspd9PaQkf-uiUnk1X8JnvufK3alOgwYHY/edit?usp=sharing

https://docs.google.com/spreadsheets/d/1XwgOFQi_FTspd9PaQkf-uiUnk1X8JnvufK3alOgwYHY/edit?usp=sharing

https://docs.google.com/spreadsheets/d/1f3hDMdJaABGTIsqDBcSRsmAEjHv7iim2lryL1hwn2mk/edit?usp=sharing

https://docs.google.com/spreadsheets/d/1f3hDMdJaABGTIsqDBcSRsmAEjHv7iim2lryL1hwn2mk/edit?usp=sharing

11.3. Fuentes de figuras [Figura 1: Diagrama de Gantt Inicial] Jorge A. F.,Diagrama de Gantt Final (2018). Retrieved June 25, 2018, from https://drive.google.com/file/d/1HlGlJLMkU0lTV9JsxrB2A6rNc76pSoAb/view?usp=sharing [Figura 2: Diagrama de Gantt Final] Jorge A. F.,Diagrama de Gantt Final (2018). Retrieved June 25, 2018, from https://drive.google.com/file/d/1HlGlJLMkU0lTV9JsxrB2A6rNc76pSoAb/view?usp=sharing [Figura 3: Proceso de trabajo de un Git Workflow para proyectos solitarios] Lambert, S. (n.d.). A Git Workflow for Solo Projects. Retrieved March 03, 2018 from https://sdlambert.github.io/2015/04/09/git-workflow-for-solo-development/ [Figura 9: Esquema una petición a una aplicación con una arquitectura MVC] Coleman, A., & PHP. (n.d.). Creating a Basic Laravel 5 MVC Application in 10 Minutes – Self-Taught Coders. Retrieved June 23, 2018 from https://selftaughtcoders.com/from-idea-to-launch/lesson-17/laravel-5-mvc-application-in-10-minutes/ [Figura 58: Ejemplo de la estructura de datos del modelo de Cliente] Server Frameworks Part 2: Spring, Ruby, Revel. (n.d.). Retrieved June 24, 2018 from https://blog.digitalfoundry.com/server-frameworks-pt-2/

113

https://drive.google.com/file/d/1HlGlJLMkU0lTV9JsxrB2A6rNc76pSoAb/view?usp=sharing

https://drive.google.com/file/d/1HlGlJLMkU0lTV9JsxrB2A6rNc76pSoAb/view?usp=sharing

https://sdlambert.github.io/2015/04/09/git-workflow-for-solo-development/

https://selftaughtcoders.com/from-idea-to-launch/lesson-17/laravel-5-mvc-application-in-10-minutes/

https://blog.digitalfoundry.com/server-frameworks-pt-2/

Documents

Desarrollo de una aplicación web para un gabinete pericial