Sistema online de cálculo de presupuestos para ofertas de desarrollo tecnológico

Escuela de Ingenier´ ıa Inform´ atica TRABAJO FIN DE GRADO Grado en Ingenier´ ıa Inform´ atica Sistema online de c´ alculo de presupuestos para ofertas de desarrollo tecnol´ ogico Autor: D˜na. Silvia del Carmen Montero Vega 2 Escuela de Ingenier´ ıa Inform´ atica TRABAJO FIN DE GRADO Grado en Ingenier´ ıa Inform´ atica Sistema online de c´ alculo de presupuestos para ofertas de desarrollo tecnol´ ogico Autor: D˜na. Silvia del Carmen Montero Vega Tutor: Dr. Diego R. Llanos Ferraris 2 Resumen El siguiente Trabajo de Fin de Grado consiste en el desarrollo de un sistema de gesti´on de presupuestos de proyectos de car´acter tecnol´ogico, destinado a su uso por grupos de investigaci´on. Dicho sistema est´a compuesto por el desarrollo de una parte de l´ogica de servidor y una interfaz web que aproveche dicho servicio. A partir de esta premisa surgen las bases para este proyecto: Diferentes utilidades que permitan a los usuarios del sistema gestionar de una forma m´as eficiente y gr´afica los presupuestos y todo lo relacionado con ellos, permitiendoles su creaci´on, modificaci´on, eliminaci´on y visualizaci´on como archivos. Dicho sistema se divide en dos partes, un servicio REST y una aplicaci´on web. El servicio REST se ha implementado utilizando Javascript, el entorno de ejecuci´on Node.js [24] y el framework Express [4]. Por otro lado, la aplicaci´on web se ha desarrollado utilizando Javascript y el framework React.js [13]. Todo ello se ha preparado para su despliegue utilizando la tecnolog´ıa Docker [3]. Se escogi´o realizar un sistema de estas caracter´ısticas ya que hasta ahora la generaci´on de presupuestos se estaba llevando a cabo utilizando software de hojas de c´alculo, lo que no proporcionaba ning´un tipo de estructura ni facilidades para la creaci´on de los mismos y dificultaba su organizaci´on para utilizarlos en futuras referencias. 3 4 Abstract The following Final Degree Project consists in the development of a budget management system, focused on budgets for technological projects, and intended for use by research groups. Such system is composed by the development of server-side logic and a web interface that takes advantadge of the aforementioned server. Based on this premise the features for this project arise: Different utilities that allow the users of the platform the ability to manage their budgets, by enabling them to create new ones or edit, delete and view as files the existing ones in a more effective and graphic manner. Said system is divided in two parts, a REST service and a web application. The REST server has been implemented using Javascript, runtime environment Node.js [24] and the Express [4] framework. On the other hand, the web application has been implemented using Javascript and the framework React.js [13]. The whole system has been set to be deployed using Docker [3]. It was chosen to make a system with these features since until now, budget creation had been done using spreadsheets, which provided no structure or facilities for this task and also hindered their management and storage for the future. 5 6 Tabla de Contenidos 1. Introducci´on 17 1.1. Contextoymotivaci´on...................................... 17 1.2. Objetivos ............................................. 17 1.3. Puntodepartida......................................... 18 1.4. Estructuradeestamemoria................................... 18 1.5. Dominiodelproblema ...................................... 19 1.5.1. ¿Qu´e es un presupuesto? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 1.5.2. C´alculo de un presupuesto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 1.5.3. Tipos de costes en un proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 1.5.4. Pasos para el c´alculo de un presupuesto . . . . . . . . . . . . . . . . . . . . . . . . 21 2. Estado del Arte 23 2.1. Software de Hojas de C´alculo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.1.1. Ventajas.......................................... 23 2.1.2. Inconvenientes ...................................... 23 2.2. EasyProjects........................................... 23 2.2.1. Ventajas.......................................... 24 2.2.2. Inconvenientes ...................................... 24 2.3. Hubstaff.............................................. 24 2.3.1. Ventajas.......................................... 24 2.3.2. Inconvenientes ...................................... 24 2.4. Conclusi´on ............................................ 25 3. An´alisis de requisitos 27 3.1. Definici´ondelosactores..................................... 27 3.2. Requisitosdeusuario....................................... 27 3.3. Requisitosfuncionales ...................................... 27 3.4. Requisitosnofuncionales .................................... 29 3.5. Requisitosdeinformaci´on .................................... 29 3.6. Reglasdenegocio......................................... 31 3.7. Estadosdeunpresupuesto.................................... 31 4. Plan de proyecto 33 4.1. Resumendelproyecto ...................................... 33 4.1.1. Prop´osito, alcance y objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 4.1.2. Definiciones y acr´onimos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 4.1.3. M´etodo escogido para el proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 4.1.4. Evoluci´ondelplan .................................... 34 7 5.3. Caso de Uso 3.1 - Ver lista de usuarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 5.4. Caso de Uso 3.2 - Registrar usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 5.5. Caso de Uso 3.3 - Eliminar usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 5.6. Caso de Uso 4.1 - Editar par´ametros del sistema . . . . . . . . . . . . . . . . . . . . . . . 51 5.7. Caso de Uso 4.2 - Ver lista de cargos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 5.8. CasodeUso4.3-Crearcargo.................................. 52 5.9. Caso de Uso 4.4 - Eliminar cargo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 5.10. Caso de Uso 4.5 - Editar cargo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 5.11. Caso de Uso 5.1 - Revisar presupuestos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 5.12. Caso de Uso 5.2 - Aprobar presupuesto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 5.13. Caso de Uso 5.3 - Rechazar presupuesto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 5.14. Caso de Uso 5.4 - Obtener archivo presupuesto . . . . . . . . . . . . . . . . . . . . . . . . 56 5.15. Caso de Uso 6.1 - Ver lista de presupuestos . . . . . . . . . . . . . . . . . . . . . . . . . . 57 5.16. Caso de Uso 6.2 - Crear presupuesto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 5.17. Caso de Uso 6.3 - Eliminar presupuesto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 5.18. Caso de Uso 6.4 - Editar presupuesto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 5.19. Caso de Uso 6.5 - Duplicar presupuesto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 5.20. Caso de Uso 6.6 - Obtener archivo presupuesto . . . . . . . . . . . . . . . . . . . . . . . . 60 5.21. Caso de Uso 6.7 - Ver lista de materiales . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 5.22. Caso de Uso 6.8 - A˜nadir material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 5.23. Caso de Uso 6.9 - Eliminar material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 5.24. Caso de Uso 6.10 - Editar material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 5.25. Caso de Uso 6.11 - Crear art´ıculo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 5.26. Caso de Uso 6.12 - Eliminar art´ıculo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 8.1. Prueba1.1............................................. 96 8.2. Prueba1.2............................................. 96 8.3. Prueba1.3............................................. 96 8.4. Prueba1.4............................................. 97 8.5. Prueba2.1............................................. 97 8.6. Prueba2.2............................................. 98 8.7. Prueba2.3............................................. 98 8.8. Prueba2.4............................................. 98 8.9. Prueba3.1............................................. 99 8.10.Prueba3.2............................................. 99 8.11.Prueba4.1............................................. 100 8.12.Prueba4.2............................................. 100 8.13.Prueba4.3............................................. 100 8.14.Prueba4.4............................................. 101 8.15.Prueba5.1............................................. 101 8.16.Prueba5.2............................................. 102 8.17.Prueba5.3............................................. 102 8.18.Prueba5.4............................................. 102 8.19.Prueba5.5............................................. 103 8.20.Prueba5.6............................................. 103 8.21.Prueba6.1............................................. 104 8.22.Prueba6.2............................................. 104 14 8.23.Prueba6.3............................................. 105 8.24.Prueba6.4............................................. 105 8.25.Prueba7.1............................................. 106 8.26.Prueba7.2............................................. 106 8.27.Prueba7.3............................................. 107 8.28.Prueba7.4............................................. 107 8.29.Prueba8.1............................................. 108 8.30.Prueba8.2............................................. 108 8.31.Prueba8.3............................................. 109 8.32.Prueba8.4............................................. 109 8.33.Prueba9.1............................................. 110 8.34.Prueba9.2............................................. 110 8.35.Prueba9.3............................................. 111 8.36.Prueba9.4............................................. 111 8.37.Prueba10.1............................................ 112 8.38.Prueba10.2............................................ 112 8.39.Prueba11.1............................................ 112 8.40.Prueba11.2............................................ 113 8.41.Prueba11.3............................................ 113 8.42.Prueba12.1............................................ 113 8.43.Prueba12.2............................................ 114 8.44.Prueba12.3............................................ 114 8.45.Prueba12.4............................................ 114 8.46.Prueba13.1............................................ 115 8.47.Prueba13.2............................................ 115 8.48.Prueba14.1............................................ 115 8.49.Prueba14.2............................................ 116 8.50.Prueba14.3............................................ 116 8.51.Prueba14.4............................................ 116 8.52.Prueba15.1............................................ 117 8.53.Prueba15.2............................................ 117 8.54.Prueba15.3............................................ 117 8.55.Prueba15.4............................................ 118 8.56.Prueba15.5............................................ 118 8.57.Prueba15.6............................................ 118 8.58.Prueba15.7............................................ 118 8.59.Prueba15.8............................................ 119 8.60.Prueba15.9............................................ 119 8.61.Prueba15.10 ........................................... 119 8.62.Prueba15.11 ........................................... 119 8.63.Prueba15.12 ........................................... 120 8.64.Prueba15.13 ........................................... 120 8.65.Prueba15.14 ........................................... 120 8.66.Prueba15.15 ........................................... 120 8.67.Prueba15.16 ........................................... 121 8.68.Prueba15.17 ........................................... 121 15 8.69.Prueba16.1............................................ 121 8.70.Prueba16.2............................................ 122 8.71.Prueba16.3............................................ 122 8.72.Prueba16.4............................................ 122 8.73.Prueba17.1............................................ 123 8.74.Prueba17.2............................................ 123 8.75.Prueba17.3............................................ 123 8.76.Prueba17.4............................................ 124 8.77.Prueba18.1............................................ 124 8.78.Prueba18.2............................................ 124 8.79.Prueba18.3............................................ 125 8.80.Prueba18.4............................................ 125 8.81.Prueba19.1............................................ 125 8.82.Prueba19.2............................................ 126 8.83.Prueba19.3............................................ 126 8.84.Prueba19.4............................................ 126 16 Cap´ıtulo 1 Introducci´on 1.1. Contexto y motivaci´on Actualmente, los equipos de investigaci´on viven rodeados de gastos diarios que requieren un control, con la finalidad de que los proyectos desarrollados por los mismos prosperen y puedan ser finalizados. Para realizar este tipo de seguimiento, lo ideal es realizar facturas o desgloses de los desembolsos que tendr´an lugar, as´ı como de los cobros que se esperan. Esta tarea puede resultar ardua dependiendo del contexto en el que nos encontremos, ya que no es lo mismo la factura de una compra por Internet que la factura de un extenso y complejo proyecto de investigaci´on. En el ´ambito tecnol´ogico esto no es distinto, ya que realizar una aproximaci´on de lo que va a conllevar a nivel monetario el desarrollo de un proyecto software no es tarea sencilla. El presente TFG est´a motivado por todo lo mencionado anteriormente, con el fin de desarrollar una herramienta que ayude a centralizar y facilitar dichas tareas para lograr el crecimiento y ´exito de los proyectos, permitiendo a los equipos de investigaci´on la generaci´on de presupuestos en respuesta a solicitudes de transferencia tecnol´ogica por parte del tejido empresarial. A lo largo del presente documento se detallar´an todas las fases que forman parte del desarrollo del proyecto, desde la elicitaci´on de requisitos y an´alisis del mismo hasta la implementaci´on total de la aplicaci´on. 1.2. Objetivos El objetivo del presente Trabajo de Fin de Grado es dotar a equipos de investigaci´on de peque˜no o mediano tama˜no de una herramienta que les permita gestionar los presupuestos de sus proyectos, permiti´endoles almacenarlos todos en un mismo lugar y con una estructura est´andar. Esto incluye la gesti´on de proveedores, costes de personal, costes recurrentes, viajes y dietas, y de costes indirectos. Para conseguir todo esto se deber´a implementar una parte de l´ogica de servidor que se encargue del almacenamiento de toda la informaci´on de los presupuestos, clientes, materiales utilizados, servicios contratados, tareas a llevar a cabo en los proyectos as´ı como posibles viajes que sean necesarios para la realizaci´on de los mismos. Adem´as, tambi´en se implementar´a una interfaz web que aproveche la l´ogica del servidor y permita a los usuarios realizar las tareas de forma simple y r´apida. Por tanto, las tareas a desarrollar son las siguientes: Desarrollo de un back-end: Nos permitir´a gestionar toda la informaci´on relacionada con los presupuestos, materiales, tareas, servicios, viajes, as´ı como los par´ametros gen´ericos que se utilizar´an para calcular los costes de los proyectos, los perfiles profesionales con sus respectivos salarios, y finalmente las cuentas de los usuarios de la organizaci´on. 17 Desarrollo de un front-end: La interfaz de usuario, que se apoyar´a en el servidor previamente implementado, utilizar´a la informaci´on del mismo para permitir a los usuarios de la organizaci´on realizar las tareas de gesti´on, creaci´on, edici´on, visualizaci´on y eliminaci´on de presupuestos y de las entidades asociadas a ellos. 1.3. Punto de partida Actualmente este tipo de tareas se realizan utilizando software de hojas de c´alculo, lo que limita significativamente la estructura que el usuario puede darle a los presupuestos, y dificulta su organizaci´on cuando se tiene un n´umero elevado de los mismos. Otra alternativa es la utilizaci´on de software de pago similares disponibles en el mercado, pero dichos programas est´an orientados a la monitorizaci´on de proyectos en curso y a su planificaci´on, por lo que no permite una generaci´on de presupuestos propiamente dichos. Por tanto, el objetivo de este trabajo ser´a automatizar y facilitar el proceso de creaci´on y almacenamiento para futura de referencia de los presupuestos de proyectos de car´acter tecnol´ogico. 1.4. Estructura de esta memoria La memoria del presente Trabajo de Fin de Grado est´a formada por una serie de cap´ıtulos, cada uno sobre un tema espec´ıfico, a fin de organizar todo el trabajo realizado: 1. Estado del Arte: Dedicado a analizar los pros y los contras de soluciones ya existentes para el problema que se desea abordar. 2. An´alisis de Requisitos: Dedicado a extraer del problema planteado las necesidades del sistema y consolidar unos requisitos sobre los que se realizar´a el trabajo. 3. Plan de Proyecto: Dedicado a elaborar la planificaci´on del proceso de desarrollo del proyecto, detallando las fases por las que pasar´a y sus respectivos riesgos. 4. Modelo de An´alisis: Detalla los diferentes casos de uso del sistema y el modelo de dominio extra´ıdos de los requisitos. 5. Dise˜no: Detalla la arquitectura del sistema, diagramas de secuencia y bocetos sobre los que se basar´an las vistas del sistema. 6. Implementaci´on: Dedicado a detallar los procesos seguidos durante el desarrollo del sistema, as´ı como la descripci´on de lo desarrollado. 7. Plan de Pruebas y Evaluaci´on: Se planifican y elaboran una serie de pruebas a realizar para comprobar el correcto funcionamiento del sistema bas´andose en los requisitos. 8. Manual del Programador: Explica todo lo necesario para que un desarrollador pueda mantener o ampliar el sistema en un futuro. 9. Manual de Instalaci´on: Detalla los pasos a seguir para la instalaci´on del sistema en un nuevo entorno. 10. Manual de Usuario: Explica a un usuario todo lo necesario para poder utilizar el sistema desarrollado. 11. Conclusiones y Trabajo Futuro: Expone las conclusiones extra´ıdas de la realizaci´on del trabajo y posibles v´ıas de trabajo futuro sobre el sistema desarrollado. 18 1.5. Dominio del problema En esta secci´on se explicar´a brevemente qu´e es un presupuesto, qu´e finalidad tiene y qu´e es necesario tener en cuenta para calcular uno, con el fin de facilitar la comprensi´on acerca del dominio del problema que motiva el presente trabajo. 1.5.1. ¿Qu´e es un presupuesto? El presupuesto de un proyecto es una herramienta utilizada para estimar el coste total de un proyecto. Generalmente, el detalle de un presupuesto incluye una estimaci´on detallada de todos los costes que deber´an ser afrontados antes de que el proyecto se considere finalzado [18]. Ayuda al responsable de su gesti´on (normalmente un project manager) a realizar una estimaci´on acerca del coste que ese proyecto va a suponer para su empresa u organizaci´on, as´ı como las ganancias o p´erdidas que implique. La creaci´on de un presupuesto suele tener lugar con antelaci´on al inicio del proyecto, generalmente para poder realizar una oferta al cliente al que se le va a proveer el servicio, y una vez iniciado el proyecto, el presupuesto se utiliza como referencia para la monitorizaci´on del mismo. La importancia de tener un presupuesto a la hora de realizar un proyecto tiene tres razones principales: Permite obtener la financiaci´on necesaria para la realizaci´on del mismo. Permite llevar un control sobre el coste del proyecto. Favorece el aumento de los margenes de beneficio de la empresa u organizaci´on que lleva a cabo el proyecto. 1.5.2. C´alculo de un presupuesto A la hora de realizar el c´alculo de un presupuesto se deben tener en cuenta dos cosas: el tipo de estimaci´on que se quiere realizar y los tipos de costes que se deben de tener en cuenta. A continuaci´on, se detallar´a brevemente en que consiste cada uno de esos aspectos. Enfoques de estimaci´on de costes de un proyecto La estimaci´on del coste total de un proyecto puede ser algo dif´ıcil de calcular inicialmente, ya que al abordar un problema nuevo suelen existir ciertas dificultades para estimar su tama˜no y complejidad. Es por eso que es necesario escoger una t´ecnica para realizar dicha estimaci´on, lo que permitir´a comenzar la creaci´on del presupuesto con un cierto orden y estructura. Algunas de las t´ecnicas de estimaci´on [32] m´as utilizadas son las siguientes: Bottom-up estimation (de abajo hacia arriba): Consiste en realizar una estimaci´on de cada una de las partes m´as peque˜nas que compone el proyecto (tareas, objetivos o fases) y sumarlas para obtener su coste total. Se recomienda su uso cuando se conocen las implicaciones del proyecto con detalle. Top-down estimation (de arriba hacia abajo): Se parte de una cifra total, que es el presupuesto con el que contar´a el proyecto, y a partir de ah´ı se divide el trabajo en partes m´as peque˜nas. Se recomienda su uso para proyectos que tienen un presupuesto fijo. Estimaci´on an´aloga: Analizar los datos de proyectos previamente realizados que sean similares para decidir el coste. 19 Estimaci´on par´ametrica: Utilizar datos y par´ametros concretos de proyectos espec´ıficos y aplicarlos al proyecto actual, para tomar decisiones utilizando la relaci´on estad´ıstica entre datos hist´oricos y variables. Estimaci´on en tres puntos: Realizar una media ponderada entre la estimaci´on m´as pesimista, m´as optimista y la m´as probable. 1.5.3. Tipos de costes en un proyecto Para realizar estimaciones detalladas acerca de los distintos costes que implica el proyecto, es necesario tener en cuenta que no todos son iguales. A la hora de clasificarlos, destacamos dos tipos de clasificaciones distintas: una en funci´on de la categor´ıa , y otra en funci´on de si el coste es directo o indirecto . En primer lugar, en cuanto a la clasificaci´on por categor´ıas, destacamos algunas de las m´as comunes: Mano de Obra: Salarios de empleados a tiempo parcial y a tiempo completo. Gastos de viajes: Cualquier viaje que sea necesario realizar para la finalizaci´on del proyecto (conferencias, reuniones...) Para calcular el coste de los viajes hay que tener en cuenta ciertos par´ametros que generalmente ser´an globales a toda la organizaci´on y que no se incluyen en el salario de los trabajadores, ya que no son una retribuci´on por el trabajo realizado, si no que compensan los gastos que se producen al trabajar fuera del lugar habitual [17]: •Dieta completa: Compensa los gastos de desayuno, comida y cena del trabajador. •Media dieta: Compensa los gastos cuando se tiene que realizar o bien la comida o bien la cena fuera del centro habitual del trabajo. No tiene necesariamente por qu´e ser la mitad de la dieta completa. •Alojamiento: Compensa los gastos del alojamiento cuando un trabajador debe pernoctar fuera del domicilio habitual debido al trabajo. •Coste del kil´ometro: Cuant´ıa que compensa el gasto de combustible y el desgaste del veh´ıculo cuando el trabajador tiene que utilizar su veh´ıculo personal para un desplazamiento fuera del centro habitual de trabajo. Materiales: Cualquier objeto material que se necesite para llevar a cabo el proyecto (software, equipaci´on, hardware...) Servicios: Incluye todo aquello no necesariamente tangible (es decir, que no se pueda considerar material) que sea necesario para el proyecto (contrataci´on de servicios externos de telecomunicaciones, asesoramiento legal, consultores, investigaci´on de mercado...) Por otra parte, la clasificaci´on de los costes tambi´en se puede realizar dependiendo de si estos son directos o indirectos [31]. Los costes directos son aquellos que se pueden atribuir de forma directa a un proyecto concreto, como por ejemplo los salarios de los empleados que trabajan en ´el, el alquiler de equipaci´on, costes materiales, etc. Sin embargo, los costes indirectos son aquellos que no se pueden atribuir a un proyecto en concreto, ya que que benefician a todos los proyectos de la organizaci´on, como por ejemplo el alquiler y los gastos de la oficina, el personal de administraci´on, el material de oficina... Para incluir dichos costes en los presupuestos de los distintos proyectos de la organizaci´on, se suele realizar una estimaci´on que proporciona un porcentaje de margen te´orico para la recuperaci´on de costes indirectos, y dicho porcentaje se aplica a los costes directos de cada uno de los proyectos. Generalmente, suele ser distinto dependiendo de la categor´ıa del coste, y puede ser menor en las organizaciones de menor tama˜no, ya que normalmente tienen menos costes de tipo indirecto a los que hacer frente (oficinas m´as peque˜nas, 20 menor cantidad de personal...). Por ejemplo, si una organizaci´on decide tener un porcentaje de retorno de costes indirectos para materiales del 6 %, y en dicha organizaci´on existe un proyecto cuyos costes directos de materiales ascienden a 5.000 € , a ese presupuesto se a˜nadir´a un coste indirecto de materiales de 300 € . 1.5.4. Pasos para el c´alculo de un presupuesto El procedimiento de c´alculo de un presupuesto puede variar entre organizaciones e incluso entre proyectos de la misma organizaci´on, ya que cada tipo de proyecto puede tener unas necesidades distintas, pero generalmente el proceso de c´alculo y estimaci´on sigue los siguientes pasos b´asicos: 1. Dividir el proyecto en tareas y objetivos: Decidir que tareas se deben llevar a cabo para el desarrollo del proyecto, y los objetivos que se quieren cumplir. 2. Identificaci´on de recursos: Determinar que materiales y servicios se necesitar´an para realizar las distintas tareas del proyecto, as´ı como los viajes que sean necesarios. 3. Suma de todos los costes: Tras haber dividido el proyecto en cada una de las subtareas y haber determinado los materiales, se necesitar´a sumar todos ellos para obtener una serie de valores que permitir´an tener una vista global del proyecto. Costes directos del proyecto: Generalmente incluyen materiales, servicios, viajes, mano de obra... Recuperaci´on de costes indirectos del proyecto Coste total del proyecto: Se calcula sumando el total de los costes directos e indirectos. Oferta: Generalmente suele ser la financiaci´on de la que se dispone para realizar el proyecto o la oferta que se realiza al cliente del mismo, dependiendo del contexto. Beneficio antes de impuestos: La diferencia entre la oferta y el coste total que el proyecto supone a la empresa. Cabe destacar que generalmente las cifras contempladas en los presupuestos no incluyen los impuestos pertinentes, por lo que estos se deber´an a˜nadir posteriormente en el caso de que fuese necesario. 21 22 Cap´ıtulo 2 Estado del Arte En el presente cap´ıtulo se van a analizar brevemente tres soluciones software encontradas que podr´ıan resolver el problema que motiva el presente TFG, destacando sus ventajas e inconvenientes. 2.1. Software de Hojas de C´alculo En primer lugar, cabe destacar una de las herramientas m´as utilizadas globalmente para la creaci´on de presupuestos y para realizar contabilidad de costes de forma gen´erica. Algunos de los programas de hojas de c´alculo m´as conocidos son: Microsoft Excel [15], Numbers [9], Google Sheets [5], Libre Office Calc [2], etc. A continuaci´on se destacar´an las ventajas y desventajas de la siguiente posible soluci´on de forma gen´erica, sin centrarse en ning´un programa de los previamente mencionados en concreto: 2.1.1. Ventajas F´acil de utilizar. Curva de aprendizaje no muy pronunciada, lo que permite que los usuarios se adapten r´apidamente a su uso y puedan ser productivos antes. Gratuito. Extrema flexibilidad. Se pueden crear presupuestos sin seguir ning´un patr´on establecido. 2.1.2. Inconvenientes Extrema flexibilidad. Aunque esto se ha considerado tambi´en como una ventaja, la extrema flexibilidad del software implica que es dif´ıcil mantener una estructura cohesiva entre todos los presupuestos que pertenecen a una misma organizaci´on. No permite visualizar todos los presupuestos de forma global. No permite generar archivos con los presupuestos. Poco robusto. Los c´alculos pueden ser f´acilmente estropeados sin que los usuarios se den cuenta. 2.2. Easy Projects Easy Projects [11] es un software de gesti´on de proyectos desarrollado por Logic Software. La cantidad de herramientas que ofrece esta soluci´on se extiende m´as all´a de la generaci´on de presupuestos, pero en esta secci´on simplemente se analizar´a la utilidad asociada con los presupuestos, destacando sus ventajas e inconvenientes. 23 9. Persona de contacto en la organizaci´on del cliente al que va dirigido el presupuesto. RI-03: Para cada art´ıculo almacenado en el hist´orico de materiales del sistema se almacenar´a: 1. Nombre. 2. Proveedor. RI-04: Para cada material utilizado en un presupuesto se almacenar´a: 1. Precio. 2. Cantidad. RI-05: Para cada servicio utilizado en un presupuesto se almacenar´a: 1. Concepto. 2. Precio. 3. Cantidad. 4. Tiempo. RI-06: Para cada viaje contemplado en un presupuesto se almacenar´a: 1. Concepto. 2. Kil´ometros. 3. Dias completos que va a durar el viaje. 4. Dias parciales que va a durar el viaje. 5. Coste del transporte por tren. 6. Coste del transporte por avi´on. 7. Costes adicionales del viaje. 8. Cantidad. RI-07: Para cada tarea contemplada en un presupuesto se almacenar´a: 1. Concepto. 2. Unidades (Meses, semanas, d´ıas...) que se tardar´a en llevar a cabo la tarea. 3. Horas por unidad que se tardar´a en realizar la tarea. 4. Incertidumbre: Dependiendo del perfil profesional al que se le asigne la tarea, la incertidumbre determinar´a las posibilidades de que la tarea se alargue m´as de lo previsto. RI-08: Para cada conjunto de par´ametros del sistema se almacenar´a: 1. Coste de una Dieta Completa Nacional. 2. Coste de Media Dieta Nacional. 3. Coste de un kil´ometro. 4. Coste de un hotel. 5. Porcentaje de margen te´orico para la recuperaci´on de costes indirectos por viajes. 6. Porcentaje de margen te´orico para la recuperaci´on de costes indirectos por materiales y servicios. 7. Porcentaje de margen te´orico para la recuperaci´on de costes indirectos por mano de obra. RI-09: Para cada perfil profesional o cargo considerado en el sistema se almacenar´a: 1. T´ıtulo. 2. Salario por horas. 30 3.6. Reglas de negocio Las caracter´ısticas de dominio en las que se encuadra el sistema son las siguientes: RN-01: S´olo se podr´a obtener un archivo de los presupuestos que est´en pendientes de ser aprobados y de los presupuestos aprobados. RN-02: S´olo se podr´a eliminar los presupuestos editables. RN-03: Los presupuestos en estado editable siempre tendr´an que utilizar los par´ametros m´as recientes registrados en el sistema. 3.7. Estados de un presupuesto Durante su ciclo de vida, un presupuesto puede pasar por distintos estados, que influir´an en las acciones que se pueden llevar a cabo sobre dicho presupuesto. A continuaci´on se mostrar´a en el siguiente diagrama el flujo entre los distintos estados y se detallar´a que se puede realizar en cada uno de ellos. Figura 3.1: Estados de un presupuesto Borrador: Estado inicial de todos los presupuestos al ser creados. Permite a los usuarios con rol de comercial editar los presupuestos y eliminarlos. Pendiente de Aprobaci´on: Para que un presupuesto pase a este estado, el comercial deber´a finalizarlo. Permite a los usuarios con rol de comercial o de jefe visualizar un archivo del presupuesto, y a los usuarios con rol de jefe aprobarlo o rechazarlo. Si el presupuesto es rechazado, volver´a a estado de borrador. Aprobado: Para que un presupuesto pase a este estado, el jefe deber´a aprobarlo. Permite que los usuarios con rol de comercial o jefe visualicen un archivo del presupuesto. 31 32 Cap´ıtulo 4 Plan de proyecto 4.1. Resumen del proyecto En este apartado se detallar´a el plan de proyecto seguido para llevar a cabo el desarrollo del sistema planteado en este TFG. 4.1.1. Prop´osito, alcance y objetivos El objetivo del proyecto es el desarrollo de un sistema completo de contabilidad de costes que permita a sus usuarios la creaci´on y gesti´on de presupuestos para sus proyectos, as´ı como una forma organizada de almacenarlos. Las caracter´ısticas que se incluir´an son: capacidad por parte del administrador de gestionar el alta y baja de los usuarios del sistema, capacidad por parte de los jefes de la organizaci´on de modificar ciertos par´ametros de los presupuestos, as´ı como aprobar o denegar los presupuestos de los comerciales. Tambi´en permitir´a que dichos comerciales puedan crear, editar, duplicar, visualizar y eliminar los presupuestos de la organizaci´on. Las funciones ser´an completamente accesibles a trav´es de la interfaz web desarrollada para el sistema. 4.1.2. Definiciones y acr´onimos A continuaci´on se enumeran un conjunto de definiciones y acr´onimos que ser´an usados a lo largo del presente documento. REST: REpresentational State Transfer, transferencia de estado representacional. CRUD: Create, Read, Update and Delete - Crear, Leer, Actualizar y Borrar. API: Application Programming Interface, Interfaz de programaci´on de aplicaciones. Conjunto de funciones, subrutinas y procedimientos que se utilizan para el desarrollo e integraci´on del software de una aplicaci´on. Front-end: Desarrollo de una interfaz web que permite al usuario interactuar con los datos que se manejan en una aplicaci´on. Back-end: Parte del desarrollo de una aplicaci´on que corresponde al servidor, donde se procesa y se almacenan los datos de la misma. Factor Incertidumbre (de una tarea): Dependiendo del perfil profesional al que se le asigne una tarea de un proyecto, este par´ametro determina la probabilidad de que dicha tarea se alargue m´as de lo previsto. 33 4.1.3. M´etodo escogido para el proyecto Para llevar a cabo el desarrollo del proyecto se ha decidido emplear un desarrollo basado en cascada, ya que los requisitos a los que est´a sujeto el sistema son claros y no admiten mucha interpretaci´on, por lo que es improbable que durante el transcurso del proyecto dichos requisitos cambien. Este m´etodo de desarrollo se caracteriza por ser secuencial, constando de un conjunto de etapas que se ejecutan una tras otra. En el caso de este proyecto, el desarrollo se dividir´a en 5 fases: an´alisis, dise˜no, implementaci´on, pruebas y mantenimiento. Tal y como indica el desarrollo en cascada, cada fase deber´a ser completada antes de poder comenzar con la siguiente. 4.1.4. Evoluci´on del plan El plan de desarrollo de proyecto debe detallar cada una de las fases por las que pasar´a el proceso de desarrollo del sistema, y adem´as detallar como se realizar´a la gesti´on de su evoluci´on. Por tanto, para obtener un plan completo debemos considerar al menos: Especificaci´on de los objetivos del proceso. Estimaci´on de costes materiales, temporales y de servicios necesarios para el desarrollo del sistema. Especificaci´on de las tareas a realizar y su extensi´on en el tiempo, as´ı como determinar las distintas fases que atravesar´a el proyecto. Recursos necesarios para realizar cada una de las tareas detalladas. Estudio de los posibles riesgos que pueden surgir, un plan de protecci´on que indique como podemos evitarlos y un plan de contingencia asociado que indique como actuar ante cada uno de ellos en caso de que sucedan. 4.1.5. Ciclo de vida del proyecto Como se ha mencionado previamente, el ciclo de vida de este proyecto constar´a de cinco fases completamente diferenciadas entre s´ı, que requerir´an ciertos artefactos de entrada al comienzo de la fase y generar´an otros artefactos de salida. Los artefactos de salida de una fase ser´an utilizados como artefactos de entrada de la siguiente fase, y as´ı sucesivamente a lo largo del desarrollo del proyecto. A continuaci´on se detalla brevemente los objetivos a cumplir en cada una de las fases del proyecto: Fase de an´alisis: Establecer el alcance y el ´ambito del proyecto, casos cr´ıticos y estimaci´on temporal. Fase de dise˜no: Analizar el dominio del problema, establecer una arquitectura base apropiada y desarrollar un plan de proyecto apropiado. Fase de implementaci´on: Minimizar costes de desarrollo en la medida de lo posible pero obteniendo aun as´ı una calidad adecuada en el producto final. Fase de pruebas: Comprobar que el producto desarrollado cumple con los requisitos establecidos en fases previas de forma satisfactoria. Fase de mantenimiento: Conseguir que el usuario sea capaz de utilizar el producto de forma correcta y alcanzar un resultado final r´apido, eficiente y con altos niveles de usabilidad que sea aceptado por el cliente. 34 4.2. Gesti´on del proyecto 4.2.1. Plan de puesta en marcha Para comenzar el desarrollo del proyecto adecuadamente se realizar´a una estimaci´on de cada una de las fases, teniendo en cuenta la experiencia obtenida en la realizaci´on de proyectos previos similares a este. El desarrollo se realizar´a de forma individual, por lo que no se tendr´a en cuenta la gesti´on de personal para la realizaci´on del proyecto. Antes de empezar el proceso de desarrollo, ser´a necesario tener conocimiento de ciertos aspectos clave para su elaboraci´on. A continuaci´on se muestra una lista de aquellas tecnolog´ıas o conceptos sobre los que se deber´a tener conocimiento previo para el proyecto, divididos seg´un los apartados que se van a desarrollar dentro del mismo, a fin de que se pueda entender con una mayor claridad: Base de datos Conocimiento sobre bases de datos relacionales, incluyendo tanto para su uso como para el dise˜no de una base de datos desde cero. Back-end Conocimiento sobre Javascript. Conocimiento sobre la estructura y el funcionamiento del framework Node.js. Front-end Conocimiento sobre HTML, CSS y Javascript. Conocimiento sobre la estructura y el funcionamiento del framework React.js. Despliegue Conocimiento sobre Docker. 4.2.2. Plan de trabajo En este apartado se detalla cada una de las fases del proyecto y las actividades por las que estar´an compuestas. 35 Fase de an´alisis ID: 01 Inicio de la fase de An´alisis Predecesoras: - Duraci´on: - - Tabla 4.1: Actividad 01 ID: 02 Comprensi´on del dominio del problema Predecesoras: 01 Duraci´on: 2 d´ıas Aprendizaje de conceptos econ´omicos relacionados con la creaci´on de presupuestos para proyectos de empresas tecnol´ogicas. Tabla 4.2: Actividad 02 ID: 03 Elicitaci´on de requisitos Predecesoras: 01 Duraci´on: 3 d´ıas Obtenci´on de los requisitos funcionales, no funcionales y de informaci´on. Tabla 4.3: Actividad 03 ID: 04 Definici´on de actividades Predecesoras: 02, 03 Duraci´on: 2 d´ıas Definici´on de las actividades necesarias para el desarrollo del proyecto y su duraci´on. Tabla 4.4: Actividad 04 ID: 05 Estudio de los riesgos Predecesoras: 04 Duraci´on: 2 d´ıas An´alisis de los riesgos que presenta el proyecto y creaci´on de un plan de contenci´on para cada uno de ellos. Tabla 4.5: Actividad 05 ID: 06 Elaboraci´on del calendario Predecesoras: 05 Duraci´on: 1 d´ıa Elaboraci´on de una planificaci´on temporal para la ejecuci´on de las distintas fases del proyecto. Tabla 4.6: Actividad 06 36 ID: 07 Aprendizaje de Node.js Predecesoras: 06 Duraci´on: 7 d´ıas Aprendizaje del funcionamiento y arquitectura del framework Node.js, que se utilizar´a para el desarrollo del back-end. Tabla 4.7: Actividad 07 ID: 08 Aprendizaje de React.js Predecesoras: 06 Duraci´on: 7 d´ıas Aprendizaje del funcionamiento y arquitectura del framework React.js, que se utilizar´a para el desarrollo del front-end. Tabla 4.8: Actividad 08 ID: 09 Aprendizaje de Docker Predecesoras: 06 Duraci´on: 9 d´ıas Aprendizaje de la tecnolog´ıa Docker, que ser´a utilizada para el despliegue del sistema desarrollado. Tabla 4.9: Actividad 09 ID: 10 Elaboraci´on del plan de proyecto Predecesoras: 07, 08, 09 Duraci´on: 3 d´ıas Elaboraci´on del documento que describe el plan de proyecto, incluyendo todas las actividades y fases, su planificaci´on temporal y la gesti´on de los riesgos asociados a las mismas. Tabla 4.10: Actividad 10 ID: 11 Fin de la fase de An´alisis Predecesoras: 10 Duraci´on: - - Tabla 4.11: Actividad 11 Fase de Dise˜no ID: 12 Inicio de la fase de Dise˜no Predecesoras: 11 Duraci´on: - - Tabla 4.12: Actividad 12 ID: 13 Elaboraci´on de los casos de uso Predecesoras: 12 Duraci´on: 3 d´ıas Elaboraci´on del diagrama de casos de uso del sistema y especificaci´on de cada uno de ellos a partir de los requisitos concretados en la fase de an´alisis. Tabla 4.13: Actividad 13 37 ID: 14 Elaboraci´on del modelo de dominio Predecesoras: 12 Duraci´on: 3 d´ıas Elaboraci´on del modelo de dominio de las entidades del sistema que ser´an utilizadas, ´unicamente indicando los atributos de las mismas. Tabla 4.14: Actividad 14 ID: 15 Elaboraci´on del despliegue del sistema Predecesoras: 12 Duraci´on: 6 d´ıas Elaboraci´on del diagrama de despliegue del sistema, junto con las dependencias de cada apartado del conjunto. Tabla 4.15: Actividad 15 ID: 16 Dise˜no de la arquitectura del sistema Predecesoras: 13, 14, 15 Duraci´on: 6 d´ıas Elaboraci´on de un diagrama que permita definir la arquitectura que tendr´a el sistema. Tabla 4.16: Actividad 16 ID: 17 Dise˜no de los bocetos del sistema Predecesoras: 16 Duraci´on: 2 d´ıas Elaboraci´on de bocetos que muestren las vistas que ser´a necesario implementar en el sistema en base a los casos de uso previamente definidos. Tabla 4.17: Actividad 17 ID: 18 Elaboraci´on de diagramas de secuencia Predecesoras: 16 Duraci´on: 6 d´ıas Elaboraci´on de diagramas de secuencia tanto para el front-end como para el back-end, que detallen la realizaci´on de los casos de uso previamente detallados. Tabla 4.18: Actividad 18 ID: 19 Fin de la fase de Dise˜no Predecesoras: 17, 18 Duraci´on: - - Tabla 4.19: Actividad 19 Fase de Implementaci´on ID: 20 Inicio de la fase de Implementaci´on Predecesoras: 19 Duraci´on: - - Tabla 4.20: Actividad 20 38 ID: 21 Preparaci´on del entorno de desarrollo Predecesoras: 20 Duraci´on: 1 d´ıa Se instalar´an todas las dependencias necesarias para poder llevar a cabo el desarrollo del back-end, el front-end y el despliegue de todo el sistema. Tabla 4.21: Actividad 21 ID: 22 Desarrollo del back-end Predecesoras: 21 Duraci´on: 30 d´ıas Se llevar´a a cabo la implementaci´on del servicio en base al an´alisis del sistema previamente realizado. Tabla 4.22: Actividad 22 ID: 23 Desarrollo del front-end Predecesoras: 22 Duraci´on: 30 d´ıas Se llevar´a a cabo la implementaci´on de una interfaz web que utilice el servicio implementado anteriormente. Tabla 4.23: Actividad 23 ID: 24 Fin de la fase de Implementaci´on Predecesoras: 22, 23 Duraci´on: - - Tabla 4.24: Actividad 24 Fase de Pruebas ID: 25 Inicio de la fase de Pruebas Predecesoras: 24 Duraci´on: - - Tabla 4.25: Actividad 25 ID: 26 Realizaci´on de pruebas del sistema Predecesoras: 25 Duraci´on: 4 d´ıas Realizaci´on de las pruebas necesarias para comprobar que el sistema cumple de forma satisfactoria los requisitos establecidos. Tabla 4.26: Actividad 26 ID: 27 Fin de la fase de Pruebas Predecesoras: 26 Duraci´on: - - Tabla 4.27: Actividad 27 39 46 Cap´ıtulo 5 Modelo de an´alisis 5.1. Casos de uso del sistema A continuaci´on se detallar´an los casos de uso del sistema a desarrollar. 5.1.1. Diagrama general de casos de uso Figura 5.1: Diagrama general de casos de uso 47 5.1.2. Caso de uso 1: Iniciar sesi´on CU-1 Iniciar sesi´on Actor Usuario Descripci´on El sistema deber´a permitir al usuario iniciar sesi´on. Precondici´on Secuencia Normal Paso Acci´on 1 El actor introduce usuario y contrase˜na. 2 El sistema comprueba que las credenciales introducidas son correctas. 3 El actor inicia sesi´on correctamente en el sistema. El caso de uso termina. Postcondici´on El actor consigue acceder al sistema. Excepciones Variaci´on Acci´on 1b, 2b, 3b El actor sale del sistema y el caso de uso queda sin efecto. 2c El sistema determina que las credenciales no son correctas, se lo notifica al usuario y el caso de uso contin´ua en el paso 1. Tabla 5.1: Caso de Uso 1 - Iniciar sesi´on 5.1.3. Caso de uso 2: Cerrar sesi´on CU-2 Cerrar sesi´on Actor Usuario Descripci´on El sistema deber´a permitir al usuario cerrar sesi´on. Precondici´on El actor ha iniciado sesi´on. Secuencia Normal Paso Acci´on 1 El actor pulsa el bot´on de cerrar sesi´on. 2 El sistema muestra un mensaje informando de la acci´on que se va a realizar y pidiendo confirmaci´on. 3 El actor pulsa el bot´on de cerrar sesi´on. El caso de uso termina. Postcondici´on El actor ha cerrado sesi´on en el sistema. Excepciones Variaci´on Acci´on 1b, 2b El actor sale del sistema y el caso de uso queda sin efecto. 3b El actor pulsa el bot´on de cancelar y el caso de uso queda sin efecto. Tabla 5.2: Caso de Uso 2 - Cerrar sesi´on 48 5.1.4. Caso de uso 3: Gesti´on de Usuarios Los casos de uso de la gesti´on de usuarios permiten al administrador visualizar los usuarios del sistema, registrar usuarios nuevos y eliminar usuarios existentes. Figura 5.2: Diagrama en detalle de gesti´on de usuarios CU-3.1 Ver lista de usuarios Actor Administrador Descripci´on El sistema deber´a permitir al administrador visualizar un listado de todos los usuarios del sistema. Precondici´on El actor ha iniciado sesi´on en el sistema. Secuencia Normal Paso Acci´on 1 El actor entra en la p´agina principal. 2 El sistema muestra un listado con los usuarios del sistema. El caso de uso termina. Postcondici´on Excepciones Variaci´on Acci´on 1b, 2b El actor sale del sistema. El caso de uso queda sin efecto. 2c El sistema no contiene usuarios que mostrar, notific´andoselo al actor. El caso de uso termina. Tabla 5.3: Caso de Uso 3.1 - Ver lista de usuarios 49 CU-3.2 Registrar usuario Actor Administrador Descripci´on El sistema deber´a permitir al administrador registrar usuarios en el sistema. Precondici´on El actor ha iniciado sesi´on en el sistema. Secuencia Normal Paso Acci´on 1 Se realiza el caso de uso ’Ver lista de usuarios’. 2 El actor selecciona registrar usuario. 3 El sistema solicita los datos necesarios. 4 El actor rellena los datos necesarios para registrar un nuevo usuario y pulsa el bot´on de registrar. 5 El sistema comprueba que los datos son v´alidos. 6 El sistema muestra un mensaje de ´exito. El caso de uso termina. Postcondici´on El usuario se ha a˜nadido al sistema. Excepciones Variaci´on Acci´on 2b, 4b El actor sale del sistema y el caso de uso queda sin efecto. 5b El sistema detecta que los datos no son v´alidos, muestra un mensaje de error y el caso de uso continua en el paso 4. Tabla 5.4: Caso de Uso 3.2 - Registrar usuario CU-3.3 Eliminar usuario Actor Administrador Descripci´on El sistema deber´a permitir al administrador eliminar usuarios del sistema. Precondici´on El actor ha iniciado sesi´on en el sistema. Secuencia Normal Paso Acci´on 1 Se realiza el caso de uso ’Ver lista de usuarios’. 2 El actor pulsa el bot´on eliminar en el usuario que desee. 3 El sistema muestra un mensaje informando de la acci´on que se va a realizar y solicitando confirmaci´on. 4 El actor pulsa el bot´on eliminar. 5 El sistema elimina el usuario del sistema. El caso de uso termina. Postcondici´on El usuario se elimina del sistema. Excepciones Variaci´on Acci´on 4b El actor pulsa el bot´on cancelar y el caso de uso queda sin efecto. Tabla 5.5: Caso de Uso 3.3 - Eliminar usuario 50 5.1.5. Caso de uso 4: Gesti´on de par´ametros del sistema Los casos de uso de la gesti´on de par´ametros del sistema permiten al jefe editar los par´ametros del sistema, visualizar los cargos existentes en el sistema, crear nuevos, editarlos y eliminarlos del sistema. Figura 5.3: Diagrama en detalle de gesti´on de par´ametros CU-4.1 Editar par´ametros del sistema Actor Jefe Descripci´on El sistema deber´a permitir al jefe editar los par´ametros del sistema. Precondici´on El actor ha iniciado sesi´on en el sistema. Secuencia Normal Paso Acci´on 1 El actor entra en la p´agina principal. 2 El actor pulsa el bot´on de ajustes del sistema. 3 El sistema muestra los par´ametros actuales del sistema para modificarlos. 4 El actor modifica los datos y pulsa el bot´on de guardar. 5 El sistema comprueba que los datos con v´alidos. 6 El sistema muestra un mensaje de ´exito. El caso de uso termina. Postcondici´on Los par´ametros del sistema se modifican. Excepciones Variaci´on Acci´on 1b, 2b, 4b El actor sale del sistema y el caso de uso queda sin efecto. 3b, 4c El actor selecciona la opci´on cancelar y el caso de uso queda sin efecto. 5b El sistema detecta que los datos no son v´alidos, muestra un mensaje de error y el caso de uso continua en el paso 4. Tabla 5.6: Caso de Uso 4.1 - Editar par´ametros del sistema 51 CU-4.2 Ver lista de cargos Actor Jefe Descripci´on El sistema deber´a permitir al jefe visualizar un listado de todos los cargos del sistema. Precondici´on El actor ha iniciado sesi´on en el sistema. Secuencia Normal Paso Acci´on 1 El actor entra en la p´agina principal. 2 El actor pulsa el bot´on de ajustes del sistema. 3 El sistema muestra un listado con los cargos del sistema. El caso de uso termina. Postcondici´on Excepciones Variaci´on Acci´on 1b, 2b El actor sale del sistema. El caso de uso queda sin efecto. 2c El sistema no contiene cargos que mostrar, notific´andoselo al actor. El caso de uso termina. Tabla 5.7: Caso de Uso 4.2 - Ver lista de cargos CU-4.3 Crear cargo Actor Jefe Descripci´on El sistema deber´a permitir al jefe crear cargos en el sistema. Precondici´on El actor ha iniciado sesi´on en el sistema. Secuencia Normal Paso Acci´on 1 Se realiza el caso de uso ’Ver lista de cargos’. 2 El actor selecciona crear cargo. 3 El sistema solicita los datos necesarios. 4 El actor rellena los datos necesarios para crear un nuevo cargo y pulsa el bot´on de guardar. 5 El sistema comprueba que los datos son v´alidos. 6 El sistema muestra un mensaje de ´exito. El caso de uso termina. Postcondici´on El cargo se ha a˜nadido al sistema. Excepciones Variaci´on Acci´on 2b, 4b El actor sale del sistema y el caso de uso queda sin efecto. 5b El sistema detecta que los datos no son v´alidos, muestra un mensaje de error y el caso de uso continua en el paso 4. Tabla 5.8: Caso de Uso 4.3 - Crear cargo 52 CU-4.4 Eliminar cargo Actor Jefe Descripci´on El sistema deber´a permitir al jefe eliminar cargos del sistema. Precondici´on El actor ha iniciado sesi´on en el sistema. Secuencia Normal Paso Acci´on 1 Se realiza el caso de uso ’Ver lista de cargos’. 2 El actor pulsa el bot´on eliminar en el cargo que desee. 3 El sistema muestra un mensaje informando de la acci´on que se va a realizar y solicitando confirmaci´on. 4 El actor pulsa el bot´on eliminar. 5 El sistema elimina el cargo del sistema. El caso de uso termina. Postcondici´on El cargo se elimina del sistema. Excepciones Variaci´on Acci´on 4b El actor pulsa el bot´on cancelar y el caso de uso queda sin efecto. Tabla 5.9: Caso de Uso 4.4 - Eliminar cargo CU-4.5 Editar cargo Actor Jefe Descripci´on El sistema deber´a permitir al jefe editar los cargos del sistema. Precondici´on El actor ha iniciado sesi´on en el sistema. Secuencia Normal Paso Acci´on 1 Se realiza el caso de uso ’Ver lista de cargos’. 2 El actor pulsa el bot´on de editar en el cargo que desee. 3 El sistema muestra los datos actuales del cargo para modificarlos. 4 El actor modifica los datos y pulsa el bot´on de guardar. 5 El sistema comprueba que los datos con v´alidos. 6 El sistema muestra un mensaje de ´exito. El caso de uso termina. Postcondici´on Los datos del cargo se modifican. Excepciones Variaci´on Acci´on 2b, 4b El actor sale del sistema y el caso de uso queda sin efecto. 4c El actor selecciona la opci´on cancelar y el caso de uso queda sin efecto. 5b El sistema detecta que los datos no son v´alidos, muestra un mensaje de error y el caso de uso continua en el paso 4. Tabla 5.10: Caso de Uso 4.5 - Editar cargo 53 5.1.6. Caso de uso 5: Gesti´on de presupuestos Los casos de uso de la gesti´on de presupuestos permiten al jefe visualizar los presupuestos aprobados y pendientes de aprobaci´on, aceptar presupuestos, rechazar presupuestos y visualizar archivos de los presupestos. Figura 5.4: Diagrama en detalle de gesti´on de presupuestos CU-5.1 Revisar presupuestos Actor Jefe Descripci´on El sistema deber´a permitir al jefe visualizar un listado de todos los presupuestos aprobados y pendientes de aprobaci´on del sistema. Precondici´on El actor ha iniciado sesi´on en el sistema. Secuencia Normal Paso Acci´on 1 El actor entra en la p´agina principal. 2 El sistema muestra un listado con los presupuestos aprobados y pendientes de aprobaci´on del sistema. El caso de uso termina. Postcondici´on Excepciones Variaci´on Acci´on 1b El actor sale del sistema. El caso de uso queda sin efecto. 2b El sistema no contiene presupuestos que mostrar, notific´andoselo al actor. El caso de uso termina. Tabla 5.11: Caso de Uso 5.1 - Revisar presupuestos 54 CU-5.2 Aprobar presupuesto Actor Jefe Descripci´on El sistema deber´a permitir al jefe aprobar un presupuesto. Precondici´on El actor ha iniciado sesi´on en el sistema. Secuencia Normal Paso Acci´on 1 Se realiza el caso de uso ’Revisar presupuestos’. 2 El actor pulsa el bot´on aprobar en el presupuesto pendiente de aprobaci´on que desee. 3 El sistema muestra un mensaje informando de la acci´on que se va a realizar y solicitando confirmaci´on. 4 El actor pulsa el bot´on aprobar. 5 El sistema cambia el estado del presupuesto a aprobado. El caso de uso termina. Postcondici´on El estado del presupuesto ha cambiado a aprobado. Excepciones Variaci´on Acci´on 2b El actor sale del sistema. El caso de uso queda sin efecto. 4b El actor pulsa el bot´on cancelar y el caso de uso queda sin efecto. Tabla 5.12: Caso de Uso 5.2 - Aprobar presupuesto CU-5.3 Rechazar presupuesto Actor Jefe Descripci´on El sistema deber´a permitir al jefe rechazar un presupuesto. Precondici´on El actor ha iniciado sesi´on en el sistema. Secuencia Normal Paso Acci´on 1 Se realiza el caso de uso ’Revisar presupuestos’. 2 El actor pulsa el bot´on rechazar en el presupuesto pendiente de aprobaci´on que desee. 3 El sistema muestra un mensaje informando de la acci´on que se va a realizar y solicitando confirmaci´on. 4 El actor pulsa el bot´on rechazar. 5 El sistema cambia el estado del presupuesto a editable. El caso de uso termina. Postcondici´on El estado del presupuesto ha cambiado a editable. Excepciones Variaci´on Acci´on 2b El actor sale del sistema. El caso de uso queda sin efecto. 4b El actor pulsa el bot´on cancelar y el caso de uso queda sin efecto. Tabla 5.13: Caso de Uso 5.3 - Rechazar presupuesto 55 CU-6.8 A˜nadir material Actor Comercial Descripci´on El sistema deber´a permitir al comercial a˜nadir materiales a un presupuesto. Precondici´on El actor ha iniciado sesi´on en el sistema. Secuencia Normal Paso Acci´on 1 Se realiza el caso de uso ’Ver lista de materiales’. 2 El actor selecciona a˜nadir material. 3 El sistema muestra el historial de art´ıculos del sistema. 4 El actor pulsa el bot´on de a˜nadir de uno de los art´ıculos del historial. 5 El sistema solicita los datos necesarios para a˜nadir el material. 6 El actor rellena los datos necesarios para a˜nadir un material y pulsa el bot´on de guardar. 7 El sistema comprueba que los datos son v´alidos. 8 El sistema muestra un mensaje de ´exito. El caso de uso termina. Postcondici´on El material se ha a˜nadido al presupuesto. Excepciones Variaci´on Acci´on 2b, 4b, 6b El actor sale del sistema y el caso de uso queda sin efecto. 7b El sistema detecta que los datos no son v´alidos, muestra un mensaje de error y el caso de uso continua en el paso 4. 4c El actor pulsa el bot´on de crear art´ıculo. Se ejecuta el caso de uso 6.11 ¡Crear Art´ıculo¿. El caso de uso continua en el paso 5. 4d El actor pulsa el bot´on de eliminar de uno de los art´ıculos del historial. Se ejecuta el caso de uso 6.12 ¡Eliminar Art´ıculo¿. El caso de uso continua en el paso 3. Tabla 5.22: Caso de Uso 6.8 - A˜nadir material CU-6.12 Eliminar material Actor Comercial Descripci´on El sistema deber´a permitir al comercial eliminar materiales de un presupuesto. Precondici´on El actor ha iniciado sesi´on en el sistema. Secuencia Normal Paso Acci´on 1 Se realiza el caso de uso ’Ver lista de materiales’. 2 El actor pulsa el bot´on eliminar en el material que desee. 3 El sistema muestra un mensaje informando de la acci´on que se va a realizar y solicitando confirmaci´on. 4 El actor pulsa el bot´on eliminar. 5 El sistema elimina el material del presupuesto. El caso de uso termina. Postcondici´on El material se elimina del presupuesto. Excepciones Variaci´on Acci´on 4b El actor pulsa el bot´on cancelar y el caso de uso queda sin efecto. Tabla 5.23: Caso de Uso 6.9 - Eliminar material 62 CU-6.13 Editar material Actor Comercial Descripci´on El sistema deber´a permitir al comercial editar los materiales de un presupuesto. Precondici´on El actor ha iniciado sesi´on en el sistema. Secuencia Normal Paso Acci´on 1 Se realiza el caso de uso ’Ver lista de materiales’. 2 El actor pulsa el bot´on editar en el material que desee. 3 El sistema muestra los datos actuales del material para modificarlos. 4 El actor modifica los datos y pulsa el bot´on de guardar. 5 El sistema comprueba que los datos con v´alidos. 6 El sistema muestra un mensaje de ´exito. El caso de uso termina. Postcondici´on Los datos del cargo se modifican. Excepciones Variaci´on Acci´on 2b, 4b El actor sale del sistema y el caso de uso queda sin efecto. 4c El actor selecciona la opci´on cancelar y el caso de uso queda sin efecto. 5b El sistema detecta que los datos no son v´alidos, muestra un mensaje de error y el caso de uso continua en el paso 4. Tabla 5.24: Caso de Uso 6.10 - Editar material CU-6.11 Crear art´ıculo Actor Comercial Descripci´on El sistema deber´a permitir al comercial crear art´ıculos en el historial del sistema. Precondici´on El actor ha iniciado sesi´on en el sistema. Secuencia Normal Paso Acci´on 1 El sistema solicita los datos necesarios para crear un art´ıculo. 2 El actor rellena los datos necesarios y pulsa el bot´on de guardar. 3 El sistema comprueba que los datos son v´alidos. 4 El sistema muestra un mensaje de ´exito. El caso de uso termina. Postcondici´on El art´ıculo se ha a˜nadido al historial del sistema. Excepciones Variaci´on Acci´on 2b El actor sale del sistema y el caso de uso queda sin efecto. 5b El sistema detecta que los datos no son v´alidos, muestra un mensaje de error y el caso de uso continua en el paso 1. Tabla 5.25: Caso de Uso 6.11 - Crear art´ıculo 63 CU-6.12 Eliminar art´ıculo Actor Comercial Descripci´on El sistema deber´a permitir al comercial eliminar art´ıculos del historial del sistema. Precondici´on El actor ha iniciado sesi´on en el sistema. Secuencia Normal Paso Acci´on 1 El sistema muestra un mensaje informando del art´ıculo que se va a eliminar y solicita confirmaci´on. 2 El actor pulsa el bot´on eliminar. 3 El sistema elimina el art´ıculo del historial. El caso de uso termina. Postcondici´on El art´ıculo se elimina del historial del sistema. Excepciones Variaci´on Acci´on 2b El actor pulsa el bot´on cancelar y el caso de uso queda sin efecto. Tabla 5.26: Caso de Uso 6.12 - Eliminar art´ıculo 64 Figura 5.7: Gesti´on de servicios de un presupuesto Figura 5.8: Gesti´on de tareas de un presupuesto Figura 5.9: Gesti´on de viajes de un presupuesto 65 No se incluye descripci´on detallada de los casos de uso relacionados con la gesti´on de servicios, tareas y viajes de un presupuesto, debido a que son an´alogos a los casos de uso previamente descritos para la gesti´on de materiales de un presupuesto del sistema. 5.2. Modelo de dominio Figura 5.10: Modelo de dominio 66 Cap´ıtulo 6 Dise˜no En este cap´ıtulo se detallar´an los modelos generados durante la fase de dise˜no del sistema. Estos modelos han sido realizados a partir de los diagramas creados durante la fase de an´alisis y con el fin de expandir y clarificar los mismos, mostrando as´ı la arquitectura final del sistema desarrollado, as´ı como los servicios que proporciona y las distintas interacciones con el usuario. 6.1. Arquitectura del sistema En esta secci´on se detallar´a la arquitectura elegida para llevar a cabo el desarrollo de cada una de las partes del sistema. Se ha dividido la aplicaci´on en dos partes, utilizando una arquitectura cliente-servidor. 6.1.1. Arquitectura del Back-end Para realizar la implementaci´on de la parte de servidor, se ha optado por una arquitectura de capas, con 3 estrictas y una relajada. [30] Esto quiere decir que cada capa del sistema se comunica s´olo con la que est´a inmediatamente por debajo, exceptuando la capa relajada, con la que se pueden comunicar el resto de las capas del sistema. Se ha escogido este patr´on arquitect´onico con el fin de simplificar la implementaci´on todo lo posible. Las capas en las que se ha dividido el sistema son las siguientes: Routes: Esta capa se ocupar´a de recibir y gestionar tanto las peticiones HTTP como las respuestas que se le enviar´an al cliente. Estar´a compuesta por los router, que reciben las peticiones y env´ıan las respuestas, y los HttpHandlers, que parsean las peticiones para poder enviarlas a la capa de servicio, y le dan formato a las respuestas recibidas de los servicios para poder enviarlas como respuesta a las peticiones HTTP. Services: Esta capa se ocupa de toda la l´ogica de negocio de la aplicaci´on y la comunicaci´on con la base de datos. Model: Esta capa define los modelos del dominio del sistema necesarios para la comunicaci´on con la base de datos utilizando el ORM. Util: Esta es la ´unica capa relajada del sistema. Contiene utilidades variadas que pueden ser utilizadas por el resto de las capas. A continuaci´on se mostrar´a el diagrama de capas de la arquitectura del back-end del sistema. Debido a su tama˜no, se mostrar´an dos versiones, una con el detalle de las operaciones y otra sin el detalle, para que se pueda apreciar la organizaci´on de las distintas capas. 67 Figura 6.1: Arquitectura usada para el Back-end 68 Figura 6.2: Arquitectura usada para el Back-end (Simplificada) 69 6.1.2. Arquitectura Front-end La arquitectura del front-end del sistema ha sido dise˜nada utilizando una simplificaci´on del patr´on MVVM [29], ya que React como librer´ıa no implementa ning´un patr´on arquitect´onico por s´ı misma. El patr´on MVVM (Model-View-ViewModel, o Modelo-Vista-VistaModelo) ayuda a separar la l´ogica de negocio de la interfaz de usuario. Se compone de tres partes principales: Modelo: Contiene el modelo de datos y la l´ogica de negocio de nuestra aplicaci´on. VistaModelo: Contiene toda la l´ogica de presentaci´on, e implementar´a propiedades y funciones que nos permitan definir las funcionalidades que va a tener nuestra aplicaci´on, y que se enlazar´an (tambi´en conocido como binding) con la Vista. Es decir, se encarga de realizar la comunicaci´on entre el Modelo y la Vista de nuestro sistema. Vista: Es la interfaz gr´afica de nuestra aplicaci´on, con la que interectuar´a el usuario. Para explicar como se adaptar´a est´a arquitectura al dise˜no de nuestro sistema, es necesario explicar algunos de los conceptos principales de React: Componentes: Los componentes [26] nos permiten separar la interfaz de usuario en piezas independientes. Dichos componentes aceptar´an entradas arbitrarias (llamadas ”props. o propiedades) y devolver´an a React elementos que describen aquello que debe aparecer en pantalla. Estado: El estado de un componente [28] son aquellas propiedades que van asociado a ´el. Cuando estas propiedades cambian, el componente se re-renderiza para mostrar la informaci´on apropiada dependiendo de los valores de dicho estado. El estado en React se considera inmutable y s´olo se puede cambiar utilizando la funci´on especializada setState(). Un componente puede tener tantos estados como sea necesario. Context API: El Contexto en React [27] proporciona una forma de pasar datos a trav´es del ´arbol de componentes sin tener que pasar props manualmente entre niveles. En React el flujo de datos entre componentes va desde arriba hacia abajo en el ´arbol de compnentes. Es decir, los componentes padres pueden pasar propiedades a sus hijos, y as´ı sucesivamente, pero nunca al rev´es. El Context API proporciona una forma de crear un contexto global formado por propiedades a las que podr´an acceder por igual todos aquellos componentes que se encuentren dentro del Provider de dicho contexto, sin necesidad de que esas propiedades hayan pasado previamente por los componentes que est´an por encima de ellos. Una vez explicados estos conceptos b´asicos, los componentes principales de la arquitectura del sistema son los siguientes [16]: Modelo: Se considerar´a modelo todos los API services del sistema, que ser´an los que se comuniquen con la API REST y obtengan la informaci´on necesaria para poder pas´arsela a los componentes. VistaModelo: Incluye todos los contextos del sistema, as´ı como el estado local y la l´ogica almacenada en cada uno de los componentes. Vista: Parte visual de los componentes (JSX, CSS). La comunicaci´on entre componentes y API services se llevar´a a cabo de la siguiente forma: El usuario interact´ua con la interfaz. Dicha interacci´on causa un cambio en el estado del componente. 70 Cuando React detecta que el estado ha cambiado, provoca un re-renderizado del componente correspondiente. Si es necesario, el componente interactuar´a con el service correspondiente para recibir o env´ıar la informaci´on correspondiente al API REST. A continuaci´on se mostrar´a un diagrama que pretende ilustrar la interaci´on entre el usuario y los componentes con sus respectivos estados, inspirado en uno similar pero con la gesti´on de estados utilizando el Context API [21]: Figura 6.3: Funcionamiento React + Context API Finalmente, se mostrar´a un diagrama de paquetes que ilustra como est´an organizados los distintos componentes y paquetes del sistema: 71 Figura 6.14: Editar servicio de un presupuesto Figura 6.15: Eliminar servicio de un presupuesto 78 Figura 6.16: Creaci´on (o edici´on) de un presupuesto - Gesti´on de viajes Figura 6.17: Creaci´on (o edici´on) de un presupuesto - Gesti´on de Tareas 79 Figura 6.18: Creaci´on (o edici´on) de un presupuesto - Gesti´on de Tareas 80 6.2.3. Revisi´on de presupuestos y ajustes de par´ametros del sistema Se incluyen las vistas para visualizar, aceptar y rechazar presupuestos por parte de los jefes, as´ı como la vista que permitir´a la gesti´on de par´ametros del sistema y la visualizaci´on, creaci´on, edici´on y eliminaci´on de los distintos cargos o perfiles profesionales del mismo. Figura 6.19: Gesti´on de par´ametros y cargos del sistema Figura 6.20: Panel de revisi´on de presupuestos 81 6.2.4. Gesti´on de usuarios Se incluyen las vistas para la visualizaci´on, creaci´on y eliminaci´on de usuarios del sistema por parte del administrador. Figura 6.21: Panel de control para la gesti´on de usuarios Figura 6.22: Registro de un Usuario 82 6.3. Diagrama de paths de la aplicaci´on En esta secci´on se mostrar´a el diagrama de paths del sistema. Este diagrama permite ver en detalle las rutas y recursos de los que dispondr´a el sistema, as´ı como los distintos endpoints a los que se podr´an realizar peticiones HTTP. A su vez, esto nos permite tener una vista de alto nivel del tipo de operaciones que el usuario podr´a llevar a cabo al utilizar el sistema. Debido al gran tama˜no del diagrama, se proporciona una versi´on con los endpoints y otra sin ellos que permita poder visualizar mejor la organizaci´on de las rutas del sistema. Figura 6.23: Diagrama de Paths simplificado de la aplicaci´on 83 Figura 6.24: Diagrama de Paths de la aplicaci´on 84 6.4. Diagramas de secuencia en dise˜no En esta secci´on se mostrar´an los diagramas de secuencia en dise˜no para los casos de uso que se han considerado m´as relevantes para la comprensi´on del funcionamiento global del sistema. Debido a que el sistema a desarrollar est´a formado por una parte de servidor o back-end y una parte de cliente o front-end, esta secci´on se dividir´a en dos subsecciones para explicar con m´as detalle cada una de las partes del sistema implementado. Cabe destacar que que todos los casos de uso son muy similares entre s´ı, por lo que s´olo se van a detallar algunos de ellos, haciendo hincapi´e en aquellos casos de uso que tengan alguna cosa distinta al resto. 6.4.1. Diagramas de secuencia en dise˜no del Back-end En este apartado se mostrar´an los diagramas de secuencia en dise˜no para los casos de uso m´as relevantes de la parte de servidor o back-end de la aplicaci´on. Para la correcta comprensi´on de esta parte del sistema se va a detallar un caso de uso de cada tipo. Los casos de uso est´andares y que se ven repetidos a lo largo de todo el sistema son los de visualizaci´on, creaci´on, edici´on y eliminaci´on de datos. Por tanto, se mostrar´a uno de cada tipo y se har´a especial hincapi´e en el caso de uso de inicio de sesi´on por parte de los usuarios, al ser este un caso de uso completamente distinto al resto. En el caso de las interacciones del sistema con la base de datos, no se detallar´an demasiado ya que se ha utilizado un ORM para facilitar esta tarea, lo cual simplifica todo bastante Se utilizar´a color verde para representar la capa de las rutas, azul para la capa de los servicios, rojo para los modelos y finalmente gris para aquellas entidades que pertenezcan a la capa relajada de utilidades del sistema o utils. Figura 6.25: Inicio de Sesi´on 85 Figura 6.26: Registrar Usuario Figura 6.27: Visualizar usuarios del sistema Figura 6.28: Eliminar usuarios del sistema 86 Figura 6.29: Editar Presupuesto 87 develop, a la que converger´an las distintas ramas de desarrollo que incluyan las distintas features, y la rama master, que ser´a la rama principal o de producci´on, desde la que s´olo se podr´an crear otras ramas para arreglos de errores de forma r´apida, tambi´en llamados hotfixes. 7.7. Servidor de la aplicaci´on En este apartado se explicar´a por separado la parte del servidor para front-end y para back-end. 7.7.1. Back-end El API REST del servicio se encuentra desplegado en un contenedor Docker que contiene todas las dependencias necesarias y permite su comunicaci´on con la base de datos y la aplicaci´on web. 7.7.2. Front-end La parte de la aplicaci´on web se encuentra desplegada en un contenedor Docker que permite su comunicaci´on con la API, utilizando nginx [20] como servidor web. 94 Cap´ıtulo 8 Plan de pruebas y evaluaci´on En este apartado se detallar´an las pruebas a realizar para comprobar que todo lo implementado funciona de la forma esperada, y que por tanto se cumplen con todos los objetivos planteados. Se llevar´an a cabo pruebas unitarias que comprueben detalladamente los requisitos planteados en el cap´ıtulo 3, de forma que a trav´es de ellas se verifique que tanto la interfaz web como el servidor desarrollados permiten realizar todas las funcionalidades de la forma esperada. 8.1. Pruebas para el back-end En este apartado se detallar´an las pruebas realizadas para comprobar el funcionamiento de la API REST desarrollada, comprobando el correcto funcionamiento de todas las operaciones CRUD implementadas para la gesti´on de presupuestos, usuarios, cargos, par´ametros, materiales, servicios, viajes, art´ıculos y tareas. Las pruebas se realizar´an utilizando Postman [25], una aplicaci´on que sirve para realizar peticiones HTTP al servidor una vez desplegado. Para ello, simplemente hace falta conocer la URL de la API y las URL de los distintos endpoints de la misma. Adem´as, habr´a que tener en cuenta la estructura de los JSON que el servidor espera recibir, as´ı como las cabeceras necesarias en las peticiones, para poder realizar las pruebas de forma exitosa. La URL para hacer las pruebas desplegando en local ser´a http://localhost:8080/. 8.1.1. Pruebas sobre gesti´on de usuarios En este apartado se realizar´an las pruebas correspondientes al correcto funcionamiento de la gesti´on de usuarios del sistema, que incluyen la comprobaci´on de los credenciales de usuario as´ı como la creaci´on, eliminaci´on y visualizaci´on de los mismos (RF-01, RF-03, RF-04 y RF-05). 95 Prueba 1.1 (RF-01) Descripci´on Esta prueba est´a destinada a comprobar el correcto funcionamiento de la autenticaci´on de un usuario. Endpoint /login Tipo de petici´on POST Par´ametros del Body username y password Acci´on Autenticar un usuario. Resultado Esperado El servidor contesta con un 200, y retorna el token de identificaci´on del usuario, asi como su id y su rol en el sistema. Tabla 8.1: Prueba 1.1 Prueba 1.2 (RF-03) Descripci´on Esta prueba est´a destinada a comprobar el correcto funcionamiento de la creaci´on de un usuario. Endpoint /users Tipo de petici´on POST Par´ametros del Body Nombre, username, password, email y rol. Acci´on Registrar un usuario en el sistema. Resultado Esperado El servidor contesta con un 201, indicando que se ha creado correctamente. Tabla 8.2: Prueba 1.2 Prueba 1.3 (RF-04) Descripci´on Esta prueba est´a destinada a comprobar el correcto funcionamiento del listado de los usuarios. Endpoint /users Tipo de petici´on GET Par´ametros del Body - Acci´on Listar los usuarios existentes en el sistema. Resultado Esperado El servidor responde devolviendo un JSON que contiene todos los usuarios del sistema. Tabla 8.3: Prueba 1.3 96 Prueba 1.4 (RF-05) Descripci´on Esta prueba est´a destinada a comprobar el correcto funcionamiento de la eliminaci´on de un usuario. Endpoint /users/userid Tipo de petici´on DELETE Par´ametros del Body - Acci´on Eliminar un usuario indicando su id en la petici´on. Resultado Esperado El servidor contesta con un 200, indicando que se ha eliminado correctamente. Tabla 8.4: Prueba 1.4 8.1.2. Pruebas sobre gesti´on de cargos En este apartado se realizar´an las pruebas correspondientes al correcto funcionamiento de la gesti´on de cargos del sistema, que incluyen la creaci´on, edici´on, visualizaci´on y eliminaci´on de los mismos (RF-08, RF-09, RF-10 y RF-11). Prueba 2.1 (RF-08) Descripci´on Esta prueba est´a destinada a comprobar el correcto funcionamiento del listado de los cargos del sistema. Endpoint /positions Tipo de petici´on GET Par´ametros del Body - Acci´on Listar los cargos existentes en el sistema. Resultado Esperado El servidor contesta con un JSON que contiene todos los cargos existentes en el sistema. Tabla 8.5: Prueba 2.1 97 Prueba 2.2 (RF-09) Descripci´on Esta prueba est´a destinada a comprobar el correcto funcionamiento de la creaci´on de un cargo. Endpoint /positions Tipo de petici´on POST Par´ametros del Body Nombre, salario Acci´on A˜nadir un nuevo cargo. Resultado Esperado El servidor contesta con un 201, indicando que se ha creado correctamente. Tabla 8.6: Prueba 2.2 Prueba 2.3 (RF-10) Descripci´on Esta prueba est´a destinada a comprobar el correcto funcionamiento de la modificaci´on de un cargo. Endpoint /positions/positionid Tipo de petici´on PUT Par´ametros del Body Nombre y/o salario actualizados Acci´on Modificar un cargo existente, indicando su id en la petici´on y pasando los datos actualizados en el body. Resultado Esperado El servidor contesta con un 200, indicando que se ha modificado correctamente. Tabla 8.7: Prueba 2.3 Prueba 2.4 (RF-11) Descripci´on Esta prueba est´a destinada a comprobar el correcto funcionamiento de la eliminaci´on de un cargo. Endpoint /positions/positionid Tipo de petici´on DELETE Par´ametros del Body - Acci´on Eliminar un cargo concreto indicando su id en la petici´on. Resultado Esperado El servidor contesta con un 200, indicando que se ha eliminado correctamente. Tabla 8.8: Prueba 2.4 98 8.1.3. Pruebas sobre gesti´on de par´ametros En este apartado se realizar´an las pruebas correspondientes al correcto funcionamiento de la gesti´on de par´ametros del sistema, que incluyen la creaci´on, edici´on, visualizaci´on y eliminaci´on de los mismos (RF-06 y RF-07). Prueba 3.1 (RF-06) Descripci´on Esta prueba est´a destinada a comprobar el correcto funcionamiento de la visualizaci´on de los par´ametros actuales del sistema. Endpoint /parameters Tipo de petici´on GET Par´ametros del Body - Acci´on Visualizar los par´ametros m´as recientes registrados en el sistema. Resultado Esperado El servidor contesta con un JSON que contiene el ultimo set de par´ametros registrados en el sistema. Tabla 8.9: Prueba 3.1 Prueba 3.2 (RF-07) Descripci´on Esta prueba est´a destinada a comprobar el correcto funcionamiento de la creaci´on de set de par´ametros. Endpoint /parameters Tipo de petici´on POST Par´ametros del Body costes indirectos de viajes, materiales, servicios y MO, costes de dietas, hotel y precio del km Acci´on A˜nadir un nuevo set de par´ametros al sistema. Resultado Esperado El servidor contesta con un 201, indicando que se ha creado correctamente. Tabla 8.10: Prueba 3.2 8.1.4. Pruebas sobre gesti´on de art´ıculos En este apartado se realizar´an las pruebas correspondientes al correcto funcionamiento de la gesti´on de art´ıculos del sistema, que incluyen la creaci´on, visualizaci´on, eliminaci´on y visualizaci´on de un hist´orico de uso de los mismos (RF-22, RF-23, RF-24 y RF-25). 99 Prueba 4.1 (RF-22) Descripci´on Esta prueba est´a destinada a comprobar el correcto funcionamiento del listado de los art´ıculos del sistema. Endpoint /articles Tipo de petici´on GET Par´ametros del Body - Acci´on Listar los art´ıculos existentes en el sistema. Resultado Esperado El servidor contesta con un JSON que contiene todos los art´ıculos existentes en el sistema. Tabla 8.11: Prueba 4.1 Prueba 4.2 (RF-24) Descripci´on Esta prueba est´a destinada a comprobar el correcto funcionamiento de la creaci´on de un art´ıculo. Endpoint /articles Tipo de petici´on POST Par´ametros del Body Nombre, proveedor Acci´on A˜nadir un nuevo art´ıculo. Resultado Esperado El servidor contesta con un 201, indicando que se ha creado correctamente. Tabla 8.12: Prueba 4.2 Prueba 4.3 (RF-23) Descripci´on Esta prueba est´a destinada a comprobar el correcto funcionamiento de la visualizaci´on de un listado de presupuestos donde se ha utilizado un art´ıculo. Endpoint /articles/articleid/historic Tipo de petici´on GET Par´ametros del Body - Acci´on Obtener el hist´orico de un art´ıculo existente, indicando su id en la petici´on. Resultado Esperado El servidor contesta con un JSON que contiene un listado de los presupuestos en los que ese art´ıculo ha sido utilizado. Tabla 8.13: Prueba 4.3 100 Prueba 4.4 (RF-25) Descripci´on Esta prueba est´a destinada a comprobar el correcto funcionamiento de la eliminaci´on de un art´ıculo. Endpoint /articles/articleid Tipo de petici´on DELETE Par´ametros del Body - Acci´on Eliminar un art´ıculo concreto indicando su id en la petici´on. Resultado Esperado El servidor contesta con un 200, indicando que se ha eliminado correctamente. Tabla 8.14: Prueba 4.4 8.1.5. Pruebas sobre gesti´on de presupuestos En este apartado se realizar´an las pruebas correspondientes al correcto funcionamiento de la gesti´on de presupuestos del sistema, que incluyen la creaci´on, visualizaci´on, edici´on, eliminaci´on y duplicaci´on de los mismos (RF-12, RF-19, RF-20, RF-42, RF-43 y RF-44). Prueba 5.1 (RF-12) Descripci´on Esta prueba est´a destinada a comprobar el correcto funcionamiento del listado de los presupuestos aprobados y pendientes de aprobaci´on. Endpoint /budgets/filter/pendingandapproved Tipo de petici´on GET Par´ametros del Body - Acci´on Listar los presupuestos aprobados y pendientes de aprobaci´on del sistema. Resultado Esperado El servidor contesta con un JSON que contiene todos los presupuestos aprobados y pendientes de aprobaci´on del sistema. Tabla 8.15: Prueba 5.1 101 Prueba 5.2 (RF-19) Descripci´on Esta prueba est´a destinada a comprobar el correcto funcionamiento de la creaci´on de un presupuesto. Endpoint /budgets Tipo de petici´on POST Par´ametros del Body Nombre, id del creador, id de los par´ametros, estado, oferta del cliente, nombre del cliente, direcci´on del cliente, CIF del cliente, info. de contacto Acci´on A˜nadir un nuevo presupuesto. Resultado Esperado El servidor contesta con un 201, indicando que se ha creado correctamente. Tabla 8.16: Prueba 5.2 Prueba 5.3 (RF-20) Descripci´on Esta prueba est´a destinada a comprobar el correcto funcionamiento de la modificaci´on de un presupuesto. Endpoint /budgets/budgetid Tipo de petici´on PUT Par´ametros del Body Nombre, estado, oferta del cliente, nombre del cliente, direcci´on del cliente, CIF del cliente, info. de contacto actualizados Acci´on Modificar un presupuesto existente, indicando su id en la petici´on y pasando los datos actualizados en el body. Resultado Esperado El servidor contesta con un 200, indicando que se ha modificado correctamente. Tabla 8.17: Prueba 5.3 Prueba 5.4 (RF-42) Descripci´on Esta prueba est´a destinada a comprobar el correcto funcionamiento del listado de todos los presupuestos del sistema. Endpoint /budgets Tipo de petici´on GET Par´ametros del Body - Acci´on Listar todos los presupuestos del sistema. Resultado Esperado El servidor contesta con un JSON que contiene todos los presupuestos del sistema. Tabla 8.18: Prueba 5.4 102 Prueba 5.5 (RF-43) Descripci´on Esta prueba est´a destinada a comprobar el correcto funcionamiento de la duplicaci´on de un presupuesto. Endpoint /budgets/budgetid/duplicate Tipo de petici´on POST Par´ametros del Body - Acci´on Crear una copia de un presupuesto del sistema. Resultado Esperado El servidor contesta con un 201, que indica que el presupuesto duplicado se ha creado correctamente. Tabla 8.19: Prueba 5.5 Prueba 5.6 (RF-44) Descripci´on Esta prueba est´a destinada a comprobar el correcto funcionamiento de la eliminaci´on de un presupuesto. Endpoint /budgets/budgetid Tipo de petici´on DELETE Par´ametros del Body - Acci´on Eliminar un presupuesto concreto indicando su id en la petici´on. Resultado Esperado El servidor contesta con un 200, indicando que se ha eliminado correctamente. Tabla 8.20: Prueba 5.6 103 8.1.9. Pruebas sobre gesti´on de viajes En este apartado se realizar´an las pruebas correspondientes al correcto funcionamiento de la gesti´on de viajes de presupuestos del sistema, que incluyen la creaci´on, edici´on, visualizaci´on y eliminaci´on de los mismos (RF-30, RF-31, RF-32 y RF-33). Prueba 9.1 (RF-30) Descripci´on Esta prueba est´a destinada a comprobar el correcto funcionamiento del listado de todos los viajes de un presupuesto. Endpoint /budgets/budgetid/trips Tipo de petici´on GET Par´ametros del Body - Acci´on Listar todos los viajes de un presupuesto. Resultado Esperado El servidor contesta con un JSON que contiene todos los viajes del presupuesto cuyo id indicamos en la petici´on. Tabla 8.33: Prueba 9.1 Prueba 9.2 (RF-31) Descripci´on Esta prueba est´a destinada a comprobar el correcto funcionamiento de la creaci´on de un viaje para un presupuesto. Endpoint /budgets/budgetid/trips Tipo de petici´on POST Par´ametros del Body Concepto, km, cantidad, d´ıas completos y parciales, coste de tren, avi´on y otros gastos. Acci´on Crear un viaje asociado a un presupuesto del sistema. Resultado Esperado El servidor contesta con un 201, que indica que el viaje se ha creado correctamente. Tabla 8.34: Prueba 9.2 110 Prueba 9.3 (RF-33) Descripci´on Esta prueba est´a destinada a comprobar el correcto funcionamiento de la eliminaci´on de un viaje asociado a un presupuesto. Endpoint /budgets/budgetid/trips/tripid Tipo de petici´on DELETE Par´ametros del Body - Acci´on Eliminar un viaje concreto indicando su id y el id del presupuesto al que pertenece en la petici´on. Resultado Esperado El servidor contesta con un 200, indicando que se ha eliminado correctamente. Tabla 8.35: Prueba 9.3 Prueba 9.4 (RF-32) Descripci´on Esta prueba est´a destinada a comprobar el correcto funcionamiento de la modificaci´on de un viaje. Endpoint /budgets/budgetid/trips/tripid Tipo de petici´on PUT Par´ametros del Body Concepto, km, cantidad, d´ıas completos y parciales, coste de tren, avi´on y otros gastos actualizados. Acci´on Modificar un viaje existente, indicando su id y el del presupuesto al que pertenece en la petici´on y pasando los datos actualizados en el body. Resultado Esperado El servidor contesta con un 200, indicando que se ha modificado correctamente. Tabla 8.36: Prueba 9.4 111 8.2. Pruebas para el front-end En este punto se detallar´an las pruebas correspondientes a la parte de la interfaz del sistema desarrollado, detallando los pasos a dar para probar el correcto funcionamiento de la aplicaci´on en base a los requisitos. 8.2.1. Pruebas sobre autenticaci´on de usuarios En este apartado se detallar´an las pruebas correspondientes al inicio y cierre de sesi´on por parte de los usuarios (RF-01 y RF-02). Prueba 10.1 (RF-01) Descripci´on Esta prueba est´a destinada a comprobar el funcionamiento de inicio de sesi´on del usuario en el sistema. Acci´on Introducir las credenciales del usuario en la ventana de inicio de sesi´on. Resultado Esperado El usuario ha conseguido identificarse correctamente en el sistema y est´a en la vista de dashboard, que depender´a de su rol en el sistema. Tabla 8.37: Prueba 10.1 Prueba 10.2 (RF-02) Descripci´on Esta prueba est´a destinada a comprobar el funcionamiento de cierre de sesi´on del usuario en el sistema. Acci´on Hacer click en el bot´on de cerrar sesi´on que se encuentra en la barra lateral de la interfaz. Resultado Esperado El usuario ha terminado su sesi´on y se encuentra en la p´agina de inicio de sesi´on. Tabla 8.38: Prueba 10.2 8.2.2. Pruebas sobre gesti´on de usuarios En este apartado se realizar´an las pruebas correspondientes al correcto funcionamiento de la gesti´on de usuarios del sistema, que incluyen la creaci´on, eliminaci´on y visualizaci´on de los mismos (RF-03, RF-04 y RF-05). Prueba 11.1 (RF-03) Descripci´on Esta prueba est´a destinada a comprobar el funcionamiento de la creaci´on de usuarios en el sistema. Acci´on Introducir el nombre, el nombre de usuario, el correo electr´onico y el rol en el formulario de registro que se encuentra en la pantalla principal del administrador. Pulsar el bot´on de registrar. Resultado Esperado El usuario aparece en la lista de usuarios del sistema. Tabla 8.39: Prueba 11.1 112 Prueba 11.2 (RF-04) Descripci´on Esta prueba est´a destinada a comprobar el funcionamiento del listado de los usuarios del sistema. Acci´on Iniciar sesi´on en el sistema con un usuario en el rol de administrador. Resultado Esperado El usuario ha accedido a su p´agina principal y puede visualizar un listado de los usuarios del sistema. Tabla 8.40: Prueba 11.2 Prueba 11.3 (RF-05) Descripci´on Esta prueba est´a destinada a comprobar el funcionamiento de la eliminaci´on de un usuario del sistema. Acci´on Hacer click en el icono de eliminar al lado del nombre de un usuario en el listado de usuarios del sistema. Pulsar eliminar en el dialogo de confirmaci´on. Resultado Esperado El usuario ha desaparecido del listado de usuarios del sistema. Tabla 8.41: Prueba 11.3 8.2.3. Pruebas sobre gesti´on de cargos En este apartado se realizar´an las pruebas correspondientes al correcto funcionamiento de la gesti´on de cargos del sistema, que incluyen la creaci´on, edici´on, visualizaci´on y eliminaci´on de los mismos (RF-08, RF-09, RF-10 y RF-11). Prueba 12.1 (RF-08) Descripci´on Esta prueba est´a destinada a comprobar el funcionamiento de la visualizaci´on del listado de los perfiles profesionales o cargos del sistema. Acci´on Hacer click en el bot´on de la barra lateral C¸argos”. Resultado Esperado El usuario puede visualizar un listado de los cargos actuales del sistema. Tabla 8.42: Prueba 12.1 113 Prueba 12.2 (RF-09) Descripci´on Esta prueba est´a destinada a comprobar el funcionamiento de a˜nadir cargos nuevos al sistema. Acci´on Hacer click en el bot´on de la barra lateral C¸ argos”. Pulsar el bot´on de a˜nair. Rellenar el formulario y confirmar. Resultado Esperado El cargo nuevo aparece en la lista de cargos del sistema. Tabla 8.43: Prueba 12.2 Prueba 12.3 (RF-10) Descripci´on Esta prueba est´a destinada a comprobar el funcionamiento de la modificaci´on de un cargo del sistema. Acci´on Hacer click en el icono de editar al lado del cargo en el listado de cargos del sistema. Rellenar el formulario con los datos nuevos y confirmar. Resultado Esperado Los datos del cargo se muestran modificados en el listado de cargos del sistema. Tabla 8.44: Prueba 12.3 Prueba 12.4 (RF-11) Descripci´on Esta prueba est´a destinada a comprobar el funcionamiento de la eliminaci´on de un cargo del sistema. Acci´on Hacer click en el icono de eliminar al lado del cargo en el listado de cargos del sistema. Pulsar el bot´on de eliminar en el di´alogo de confirmaci´on. Resultado Esperado El cargo ya no aparece en el listado de cargos del sistema. Tabla 8.45: Prueba 12.4 114 8.2.4. Pruebas sobre gesti´on de par´ametros En este apartado se realizar´an las pruebas correspondientes al correcto funcionamiento de la gesti´on de par´ametros del sistema, que incluyen la creaci´on y visualizaci´on de los mismos (RF-06 y RF-07). Prueba 13.1 (RF-06) Descripci´on Esta prueba est´a destinada a comprobar el funcionamiento de la visualizaci´on de los ´ultimos par´ametros del sistema. Acci´on Hacer click en el bot´on de la barra lateral ”Par´ametros”. Resultado Esperado El usuario puede visualizar los ´ultimos par´ametros con los que cuenta el sistema. Tabla 8.46: Prueba 13.1 Prueba 13.2 (RF-07) Descripci´on Esta prueba est´a destinada a comprobar el funcionamiento de a˜nadir par´ametros nuevos al sistema. Acci´on Hacer click en el bot´on de la barra lateral ”Par´ametros”. Editar los valores necesarios en el formulario de la pantalla y pulsar el bot´on de confirmar. Resultado Esperado Los par´ametros del sistema cambian en la pantalla. Todos los presupuestos en estado editable ahora utilizar´an esos par´ametros. Tabla 8.47: Prueba 13.2 8.2.5. Pruebas sobre gesti´on de art´ıculos En este apartado se realizar´an las pruebas correspondientes al correcto funcionamiento de la gesti´on de art´ıculos del sistema, que incluyen la creaci´on, visualizaci´on, eliminaci´on y visualizaci´on de un hist´orico de uso de los mismos (RF-22, RF-23, RF-24 y RF-25). Prueba 14.1 (RF-23) Descripci´on Esta prueba est´a destinada a comprobar el funcionamiento de la visualizaci´on del hist´orico de presupuestos en los que se ha utilizado un material. Acci´on Pulsar el bot´on de edici´on de un presupuesto o crear uno nuevo. En la vista de editor de presupuestos, pulsar el bot´on de hist´orico de al lado de un art´ıculo, que se encuentra en la tabla con hist´orico de art´ıculos de sistema, en la secci´on de materiales. Resultado Esperado El usuario puede visualizar un listado de todos los presupuestos en los que ese art´ıculo ha sido utilizado previamente. Tabla 8.48: Prueba 14.1 115 Prueba 14.2 (RF-24) Descripci´on Esta prueba est´a destinada a comprobar el funcionamiento de a˜nadir art´ıculos nuevos al sistema. Acci´on En la secci´on de materiales del editor de presupuestos, hacer click en el bot´on de a˜nadir en la tabla del hist´orico de art´ıculos del sistema. Rellenar el formulario y pulsar el bot´on de confirmar. Resultado Esperado El art´ıculo nuevo aparece en la lista de art´ıculos del sistema. Tabla 8.49: Prueba 14.2 Prueba 14.3 (RF-22) Descripci´on Esta prueba est´a destinada a comprobar el funcionamiento de la visualizaci´on de art´ıculos del sistema. Acci´on Acceder al editor de presupuestos. Navegar hasta la secci´on de materiales. Resultado Esperado El usuario puede visualizar una tabla con un listado del hist´orico de art´ıculos del sistema. Tabla 8.50: Prueba 14.3 Prueba 14.4 (RF-25) Descripci´on Esta prueba est´a destinada a comprobar el funcionamiento de la eliminaci´on de un art´ıculo del sistema. Acci´on Hacer click en el icono de eliminar al lado del art´ıculo en el listado de art´ıculos del sistema. Pulsar el bot´on de eliminar en el di´alogo de confirmaci´on. Resultado Esperado El art´ıculo ya no aparece en el listado de art´ıculos del sistema. Tabla 8.51: Prueba 14.4 116 8.2.6. Pruebas sobre gesti´on de presupuestos En este apartado se realizar´an las pruebas correspondientes al correcto funcionamiento de la gesti´on de presupuestos del sistema, que incluyen la creaci´on, visualizaci´on, edici´on, eliminaci´on, ordenaci´on, duplicaci´on y visualizaci´on en PDF de los mismos (RF-12, RF-13, RF-14, RF-15, RF-16, RF-17, RF-18, RF-19, RF-20, RF-21, RF-42, RF-43, RF-44, RF-45, RF-46, RF-47, RF-48 y RF-49). Prueba 15.1 (RF-12) Descripci´on Esta prueba est´a destinada a comprobar el funcionamiento de la visualizaci´on de un listado con los presupuestos aprobados y pendientes de aprobaci´on del sistema. Acci´on Iniciar sesi´on en el sistema con el rol de jefe. Resultado Esperado El usuario visualizar´a un listado con los presupuestos aprobados y pendientes de aprobaci´on del sistema. Tabla 8.52: Prueba 15.1 Prueba 15.2 (RF-13) Descripci´on Esta prueba est´a destinada a comprobar el funcionamiento de la aprobaci´on del presupuesto del sistema. Acci´on Hacer click en el icono de aprobaci´on al lado del presupuesto pendiente de aprobaci´on en el listado de presupuestos aprobados y pendientes de aprobaci´on del sistema. Resultado Esperado El estado del presupuesto ha pasado a ser .aprobado”. Tabla 8.53: Prueba 15.2 Prueba 15.3 (RF-14) Descripci´on Esta prueba est´a destinada a comprobar el funcionamiento del rechazo de un presupuesto del sistema. Acci´on Hacer click en el icono de rechazo al lado del presupuesto pendiente de aprobaci´on en el listado de presupuestos aprobados y pendientes de aprobaci´on del sistema. Resultado Esperado El estado del presupuesto ha pasado a ser . ed itable”. Ya no se muestra en el listado. Tabla 8.54: Prueba 15.3 117 Prueba 15.4 (RF-15) Descripci´on Esta prueba est´a destinada a comprobar el funcionamiento de la visualizaci´on del archivo de un presupuesto del sistema. Acci´on Hacer click en el icono de descarga al lado del presupuesto pendiente de aprobaci´on en el listado de presupuestos aprobados y pendientes de aprobaci´on del sistema. Resultado Esperado El usuario puede visualizar un archivo PDF con los datos del presupuesto. Tabla 8.55: Prueba 15.4 Prueba 15.5 (RF-16) Descripci´on Esta prueba est´a destinada a comprobar el funcionamiento de la ordenaci´on del listado de presupuestos por nombre. Acci´on Hacer click en el la cabecera de la tabla de la columna de nombres en el listado de presupuestos aprobados y pendientes de aprobaci´on del sistema. Resultado Esperado Los presupuestos pasan a estar ordenados por nombre en la tabla. Tabla 8.56: Prueba 15.5 Prueba 15.6 (RF-17) Descripci´on Esta prueba est´a destinada a comprobar el funcionamiento de la ordenaci´on del listado de presupuestos por estado. Acci´on Hacer click en el la cabecera de la tabla de la columna de estados en el listado de presupuestos aprobados y pendientes de aprobaci´on del sistema. Resultado Esperado Los presupuestos pasan a estar ordenados por estado en la tabla. Tabla 8.57: Prueba 15.6 Prueba 15.7 (RF-18) Descripci´on Esta prueba est´a destinada a comprobar el funcionamiento de la ordenaci´on del listado de presupuestos por autor. Acci´on Hacer click en el la cabecera de la tabla de la columna de autores en el listado de presupuestos aprobados y pendientes de aprobaci´on del sistema. Resultado Esperado Los presupuestos pasan a estar ordenados por autor en la tabla. Tabla 8.58: Prueba 15.7 118 Prueba 15.8 (RF-19) Descripci´on Esta prueba est´a destinada a comprobar el funcionamiento de la creaci´on de presupuestos. Acci´on Iniciar sesi´on en el sistema con rol de comercial. Introducir un nombre para el presupuesto en el formulario de la pantalla principal y pulsar el bot´on de confirmaci´on. Resultado Esperado El presupuesto ha sido creado y se puede modificar desde el editor de presupuestos. Tabla 8.59: Prueba 15.8 Prueba 15.9 (RF-20) Descripci´on Esta prueba est´a destinada a comprobar el funcionamiento de la edici´on de presupuestos. Acci´on Iniciar sesi´on en el sistema con rol de comercial. Pulsar el bot´on de edici´on al lado del nombre de presupuesto editable en la lista de presupuestos. Cambiar los valores necesarios y pulsar el bot´on de ”guardar y salir”. Resultado Esperado El usuario ha editado el presupuesto con ´exito. Tabla 8.60: Prueba 15.9 Prueba 15.10 (RF-21) Descripci´on Esta prueba est´a destinada a comprobar el funcionamiento de la edici´on de presupuestos. Acci´on Iniciar sesi´on en el sistema con rol de comercial. Pulsar el bot´on de edici´on al lado del nombre de presupuesto editable en la lista de presupuestos. Pulsar el bot´on de ”guardar y finalizar”. Resultado Esperado El estado del presupuesto ha cambiado a ”pendiente de aprobaci´on”. Tabla 8.61: Prueba 15.10 Prueba 15.11 (RF-42) Descripci´on Esta prueba est´a destinada a comprobar el funcionamiento de la visualizaci´on de un listado con todos los presupuestos del sistema. Acci´on Iniciar sesi´on en el sistema con el rol de comercial. Resultado Esperado El usuario visualizar´a un listado con todos los presupuestos del sistema. Tabla 8.62: Prueba 15.11 119 Prueba 19.2 (RF-31) Descripci´on Esta prueba est´a destinada a comprobar el funcionamiento de a˜nadir viajes a un presupuesto. Acci´on En el editor de presupuestos, hacer click en la pesta˜na de ”Viajes”. Pulsar el bot´on de a˜nadir en la tabla de viajes. Rellenar el formulario y confirmar. Resultado Esperado El viaje nuevo aparece en la lista de viajes del presupuesto. Tabla 8.82: Prueba 19.2 Prueba 19.3 (RF-32) Descripci´on Esta prueba est´a destinada a comprobar el funcionamiento de la modificaci´on de un viaje del presupuesto. Acci´on Hacer click en el icono de editar al lado del viaje en el listado de viajes del presupuesto. Rellenar el formulario con los datos nuevos y confirmar. Resultado Esperado Los datos del viaje se muestran modificados en el listado de viajes del presupuesto. Tabla 8.83: Prueba 19.3 Prueba 19.4 (RF-33) Descripci´on Esta prueba est´a destinada a comprobar el funcionamiento de la eliminaci´on de un viaje de un presupuesto. Acci´on Hacer click en el icono de eliminar al lado del viaje en el listado de viajes del presupuesto. Pulsar el bot´on de eliminar en el di´alogo de confirmaci´on. Resultado Esperado El viaje ya no aparece en el listado de viajes del presupuesto. Tabla 8.84: Prueba 19.4 126 Cap´ıtulo 9 Manual de programador En este cap´ıtulo se detallar´a la informaci´on necesaria para un desarrollador que quiera trabajar en el sistema implementado, tanto para su mantenimiento como para su ampliaci´on. Se incluir´a toda la informaci´on necesaria tanto para el back-end como para el front-end. 9.1. Back-end En este punto se explicar´a todo lo necesario acerca de la estructura del back-end del sistema, incluyendo una explicaci´on detallada de cada una de las carpetas y ficheros de inter´es. Al final de la secci´on se incluir´a una breve explicaci´on de como realizar peticiones HTTP con Postman [25], herramienta utilizada para probar la API REST desarrollada. 9.1.1. Directivas generales El c´odigo fuente desarrollado se divide en cuatro subcarpetas: ’models’, ’routes’, ’services’ y ’tools’. Carpeta routes: Contiene los distintos endpoints que tiene el sistema. Se encarga de recibir y gestionar las peticiones que la API recibe, as´ı como dar formato y enviar las respuestas pertinentes en formato JSON y con un c´odigo HTTP de respuesta en funci´on de la operaci´on realizada. Carpeta services: Contiene la l´ogica de negocio de la aplicaci´on. Es decir, las funcionalidades necesarias para operar con la BBDD del sistema (el equivalente a las queries, pero utilizando Sequelize como ORM). Carpeta models: Contiene los modelos de dominio de las entidades del sistema necesarios para la comunicaci´on con la BBDD. Para cada entidad se definen los campos correspondientes a cada una de las columnas de las tablas correspondientes en la BBDD. Carpeta tools: Contiene una serie de ficheros auxiliares en los que se apoya el sistema para su funcionamiento, incluyendo utilidades para la autenticaci´on de usuarios y para la gesti´on de promesas Javascript. 9.1.2. Carpeta routes En la carpeta router se encuentran los endpoints a los que la aplicaci´on realizar´a peticiones. Esta carpeta se divide en 10 subcarpetas, es decir, una para cada entidad del sistema, y una adicional para aislar el endpoint referente a la autenticaci´on de los usuarios del sistema. Dentro de cada una de esas subcarpetas encontramos dos ficheros, el httpHandler y el router. 127 Router: Define los distintos endpoints relacionados con esa entidad del dominio. Redirige las peticiones al HttpHandler correspondiente. HttpHandler: Recibe las peticiones de los distintos endpoints, recoge la informaci´on necesaria de las mismas y interact´ua con el servicio correspondiente dependiendo de la petici´on. Tambi´en le da formato a la informaci´on que recibe del servicio para convertirla en una respuesta HTTP valida en formato JSON. Generalmente, cada una de las entidades del sistema tiene 5 endpoints distintos, salvo ciertas entidades que no necesitan todos ellos y salvo el caso particular de los presupuestos, que tienen algun endpoint m´as. Aun as´ı, podemos resumir el funcionamiento de los endpoints de cada una de las entidades del sistema de la siguiente forma: GET elements: Obtener todos los elementos del sistema. En el caso de materiales, servicios, viajes y tareas, obtenemos todos los que pertenecen a un presupuesto dado. GET element: Obtiene un elemento en concreto dado su identificador. POST create new element: Crea un nuevo elemento con los datos requeridos. DELETE element: Elimina un elemento dado su identificador. Si se borra un elemento que tiene otros por debajo, estos elementos tambi´en se eliminar´an, como sucede en el caso de los presupuestos, que tienen materiales, servicios, viajes y tareas. PUT element: Edita un elemento mediante su identificador y proporcionando los nuevos datos. En el caso de los presupuestos, destacamos tres endpoints particulares que otras entidades no tienen: POST duplicate budget: Recibe el identificador de un presupuesto, y crea una copia en la BBDD. GET pending and approved budgets: Devuelve todos los presupuestos aprobados y pendientes de aprobaci´on del sistema. PUT update parameter in editable budgets: Edita el identificador de los par´ametros del sistema a los est´an asociados los presupuestos editables del sistema. 9.1.3. Carpeta services Contiene los ficheros que proveen de consultas y funciones de tratamiento de los datos al handler correspondiente. Interact´uan con la BBDD mediante el ORM. Hay una por cada entidad de dominio (usuarios, art´ıculos, cargos, par´ametros, presupuestos, materiales, servicios, viajes y tareas) y una adicional para gestionar la autenticaci´on. Dentro de cada fichero se encuentran consultas an´alogas a los endpoints que posee cada una de las entidades. Nos permiten obtener todos los elementos del tipo correspondiente, un elemento concreto utilizando su identificador, crear un elemento, editarlo y eliminarlo. Tenemos dos casos especiales, el de budget-service que, como mencionamos en la secci´on anterior, nos permite duplicar un presupuesto, editar los par´ametros de todos los presupuestos editables, y obtener los presupuestos aprobados y pendientes de aprobaci´on, y el caso especial de auth-service , que contiene funciones espec´ıficas para comprobar los credenciales del usuario. 128 9.1.4. Carpeta models En la carpeta model se encuentran definidas las nueve entidades de la BBDD, habiendo una por cada tabla: users, parameters, articles, positions, budgets, materials, tasks, trips y services . Dentro de cada modelo se definen sus atributos, que equivalen a las columnas de la tabla correspondiente a la BBDD. 9.1.5. Carpeta tools En la carpeta de tools encontramos los siguientes archivos Javascript: to: Contiene una funci´on que facilita la gesti´on de promesas Javascript. crypto: Contiene las funciones de hash que se utilizan para la gesti´on del encriptado y desencriptado de contrase˜nas utilizando Passport.js [10]. auth-middleware: Contiene los middleware (funciones que se ejecutan cada vez que se realiza una petici´on) relacionados con la protecci´on de los endpoints utilizando JWT (JSON Web Token). 9.1.6. Otros ficheros relevantes En esta secci´on se indican otros ficheros de inter´es del sistema, que se encuentran en la carpeta ra´ız (/”) del proyecto. /app.js: Punto de entrada de la aplicaci´on, donde se instancia el servidor Express [4] y se crean las rutas de la API: /db.js: Gestiona la conexi´on y sincronizaci´on con la BBDD utilizando Sequelize [14], as´ı como las relaciones entre las distintas tablas. /middleware.js: Utiliza los middlewares de autenticaci´on para proteger los endpoints del sistema. 9.1.7. Pruebas en Postman Tal y como se indic´o al principio de esta secci´on, a continuaci´on se indicar´a como hacer una serie de peticiones que permitan probar el funcionamiento de la API. Para realizar la demostraci´on utilizaremos los endpoints de los cargos del sistema. El resto de peticiones para los dem´as endpoints se realizar´ıan de forma an´aloga. En todas las peticiones a realizar se debe indicar la URL y un endpoint . En este caso, la URL base ser´ıa http://localhost:8080/ y el endpoint ser´ıa /positions Iniciar Sesi´on En primer lugar, debemos hacer una petici´on de login con los credenciales del usuario para obtener el token que necesitamos para hacer peticiones a los endpoints protegidos. Dicho token ser´a incluido en un header con el nombre ’Authorization’ en el resto de las peticiones a realizar. 129 Figura 9.1: Header de autorizaci´on de las peticiones Obtener todos los cargos Con esta petici´on obtenemos todos los cargos del sistema. Figura 9.2: GET todos los cargos 130 Obtener un cargo Con esta petici´on obtenemos el cargo con identificador 1 del sistema. Figura 9.3: GET cargo con identificador 1 Crear un cargo Con esta petici´on crearemos un cargo nuevo en el sistema. 131 Figura 9.4: POST a˜nadir un cargo Editar un cargo Con esta petici´on editaremos el cargo previamente creado en el sistema. Figura 9.5: PUT editar un cargo 132 Eliminar un cargo Con esta petici´on eliminaremos el cargo previamente creado en el sistema. Figura 9.6: DELETE un cargo 9.2. Front-end En este punto se detallar´a lo necesario para la comprensi´on del front-end del sistema implementado. 9.2.1. Directivas generales En la ra´ız del proyecto (dentro de la carpeta ’src’) encontramos varias carpetas, que a su vez tienen varias subcarpetas, que agrupan los ficheros dependiendo del tipo de funcionalidad que desempe˜nan en el sistema. Las carpetas en las que esta dividido son ’components’, ’pages’, ’API’, ’context’ y ’utils’. Carpeta components: Dentro de esta carpeta se encuentran los componentes React de la aplicaci´on. Est´an divididos seg´un la vista a la que pertenecen, y a su vez subdivididos dependiendo de la funcionalidad que cumplan dentro de dicha vista. Carpeta pages: Esta carpeta tambi´en contiene componentes, pero ´unicamente contiene aquellos que se corresponden a cada una de las rutas de la aplicaci´on. Es decir, los componentes que est´an m´as arriba en la jerarqu´ıa de la misma. Carpeta API: Contiene todas las llamadas a la API REST del sistema, siendo el ´unico punto de comunicaci´on del front-end con la misma. Dichas llamadas se encuentran divididas en ficheros que se corresponden con cada uno de los endpoints del sistema. Carpeta context: En esta carpeta se almacenan los dos contextos a los que acceden los componentes del sistema. 133 Carpeta utils: Contiene utilidades variadas para la gesti´on y el parseado de los datos. 9.2.2. Carpeta components La carpeta components contiene pr´acticamente todos los componentes del sistema. Esta a su vez est´a subdividida en carpetas que se corresponden a cada una de las vistas del sistema. A continuaci´on se detallar´a lo que contiene cada una de ellas: Editor: Contiene todos los componentes relacionados con el editor de presupuestos del sistema. A su vez, est´a subdividida en los componentes relacionados con cada uno de las entidades que forman un presupuesto: BudgetMaterials, BudgetServices, BudgetTrips y BudgetTasks. PDFView: Contiene todos los componentes relacionados con el visor de PDF del sistema. Son todos los que se necesitan para la generaci´on de los PDF, y a su vez est´a subdividida tambi´en en las distintas tablas con las que cuenta el archivo: ICTable, SummaryTable, TotalTasksTable, TasksTable, TripsTable, ServicesTable y MaterialsTable. Positions: Contiene todos los componentes relacionados con la gesti´on de los cargos del sistema: la tabla y el formulario de creaci´on/edici´on. Dashboard: Contiene todos los componentes utilizados para la visualizaci´on de la p´agina principal del sistema. Como dicha vista depende del rol del usuario, a su vez se subdivide en carpetas que corresponden al dashboard de cada tipo de usuario: •AdminDashboard: P´agina principal del administrador del sistema. Contiene todos los componentes referentes a la gesti´on de los usuarios del sistema. •BossDashboard: P´agina principal de los usuarios con rol de jefe. Contiene todos los componentes relacionados a la visualizaci´on y gesti´on de presupuestos aprobados y pendientes. •CommercialDashboard: P´agina principal de los usuarios con rol de comercial. Contiene todos los componentes relacionados a la visualizaci´on y gesti´on de todos los presupuestos del sistema, as´ı como la creaci´on de nuevos. Adem´as, hay ciertos componentes mas gen´ericos que no pertenecen a ninguna vista en particular, y son los siguientes: Login: Componente que permite a los usuarios iniciar sesi´on en el sistema. Se muestra siempre que no exista un token v´alido en el localStorage del navegador. Sidebar: Barra lateral que aparece en todas las vistas del sistema y permite a los usuarios navegar por el mismo. Notification: Snackbar lateral que aparece para notificar al usuario cuando se ha realizado una acci´on. Popup: Cuadro de di´alogo que se utiliza para mostrar distintos formularios en todo el sistema. ConfirmationDialog: Cuadro de di´alogo que se utiliza para solicitar confirmaci´on al usuario a la hora de realizar distintos tipos de acciones en todo el sistema. 134 9.2.3. Carpeta pages Esta carpeta contiene aquellos componentes que se encuentran en la parte superior de la jerarqu´ıa de la aplicaci´on. Es decir, todos aquellos que se corresponden a una vista del sistema. Son los siguientes: Dashboard: P´agina principal del sistema. Se muestra al iniciar sesi´on, y es diferente para cada tipo de usuario. Los administradores ver´an el panel de gesti´on de usuarios, los jefes ver´an el panel de gesti´on de presupuestos, donde podr´an visualizar presupuestos aprobados o pendientes, as´ı como aprobar o rechazar aquellos que est´en pendientes. Finalmente, los comerciales ver´an el panel de control con todos los presupuestos del sistema donde podr´an visualizar, editar, eliminar y crear presupuestos. Editor: P´agina que se corresponde al editor de presupuestos, al que se accede al editar un presupuesto existente o crear uno nuevo. En el se puede editar el presupuesto, ver un resumen de las cifras del mismo y visualizar las distintas entidades que lo forman (materiales, servicios, viajes y tareas) as´ı como crearlas, editarlas o eliminarlas. Parameters: En esta vista los usuarios con rol de jefe pueden visualizar y editar los par´ametros del sistema que se utilizar´an para calcular los valores pertinentes en los presupuestos. Positions: En esta vista los usuarios con rol de jefe podr´an visualizar, editar, eliminar y crear cargos profesionales en el sistema. PDFView: Vista que permite a los usuarios visualizar un archivo PDF de un presupuesto. 9.2.4. Carpeta API Contiene todos los ficheros desde donde se realizan peticiones a la API REST utilizando Axios [23]. Existe un fichero para cada endpoint existente en la API, con el fin de dividir las peticiones de una forma pr´actica y f´acil de entender. 9.2.5. Carpeta context Contiene los dos contextos a los que tienen acceso los componentes del sistema. El concepto de contexto en React fue explicado en el cap´ıtulo 6. A fin de simplificar el sistema, se ha decidido tener ´unicamente dos contextos. El resto de estado se almacena de forma particular en cada componente y se pasar´a entre componentes utilizando las propiedades. Los dos contextos con los que cuenta el sistema son los siguientes: context: Contexto general del sistema. Contiene los datos del usuario que tiene la sesi´on iniciada y gestiona el almacenamiento de dichos datos en el LocalStorage (objeto que nos permite almacenar datos de manera local en un navegador) [22]. Tienen acceso a ´el todos los componentes del sistema. editorContext: Contexto asociado al editor de presupuestos del sistema. Contiene todos los datos del presupuesto con el que se est´a trabajando, as´ı como de las entidades asociadas a ´el. Tambi´en contiene distintas funcionalidades que permiten calcular los datos que se muestran en el resumen del presupuesto. S´olo tienen acceso a ´el los componentes de la vista Editor. 9.2.6. Carpeta utils Contiene un fichero llamado budgetUtils que contiene funciones que ayudan al parseo de datos del presupuesto, como por ejemplo las fechas del mismo. 135 142 Cap´ıtulo 11 Manual de usuario En este cap´ıtulo se detallar´a paso por paso y utilizando apoyo visual la forma de utilizar la interfaz del sistema desarrollado durante el transcurso del proyecto. La explicaci´on de dichas acciones se dividir´a bas´andose en el rol que tenga en el sistema el usuario que pueda realizarlas. 11.1. Acceso a la aplicaci´on Este paso es com´un para todos los usuarios del sistema. La aplicaci´on ser´a accesible mediante un navegador web a trav´es de un dominio dado. Para poder acceder a las funcionalidades del sistema, el usuario deber´a haber sido dado de alta en el sistema previamente por el administrador del mismo, y deber´a iniciar sesi´on. Figura 11.1: Inicio de sesi´on 11.2. Administrador del Sistema El administrador del sistema visualizar´a un panel que le permitir´a realizar las siguientes acciones: Visualizar listado de usuarios: Visualizar una tabla con todos los usuarios del sistema, su nombre, correo electr´onico, nombre de usuario y rol. (Figura 11.2) 143 Eliminar un usuario: Para dar de baja a un usuario en el sistema, el administrador deber´a pulsar el bot´on de la papelera de la tabla de usuarios que se corresponda al usuario que desea eliminar. Tras pulsarlo, aparecer´a un cuadro de di´alogo solicitando confirmaci´on para realizar la acci´on. (Figura 11.3) Crear un usuario: Para crear un usuario, el administrador deber´a rellenar el formulario de la parte superior de la pantalla y pulsar el bot´on de ’REGISTRAR’. (Figura 11.2) Figura 11.2: Panel de Administraci´on de Usuarios Figura 11.3: Dialogo de confirmaci´on - Eliminar usuario 144 11.3. Jefes Los usuarios del sistema con rol de jefe podr´an realizar las siguientes acciones: aprobar y rechazar presupuestos, visualizar presupuestos en formato PDF y gestionar los cargos y los par´ametros del sistema. A continuaci´on se explicar´a con mayor detalle en que parte del sistema se llevan a cabo dichas acciones. 11.3.1. Revisi´on de Presupuestos Al iniciar sesi´on con una cuenta de usuario con rol de jefe, se podr´a visualizar un panel de control que mostrar´a todos los presupuestos del sistema con estado aprobado y pendiente de aprobaci´on (figura 11.4). Sobre ellos se podr´an llevar a cabo las siguientes acciones: Aprobar un presupuesto: S´olo se podr´a llevar a cabo sobre los presupuestos pendientes de aprobaci´on. Para aprobar un presupuesto el usuario deber´a pulsar el bot´on con un check verde situado en la fila de la tabla correspondiente al presupuesto que desee aprobar. Tras pulsar, el estado del presupuesto cambiar´a a aprobado. Rechazar un presupuesto: S´olo se podr´a llevar a cabo sobre los presupuestos pendientes de aprobaci´on. Para rechazar un presupuesto el usuario deber´a pulsar el bot´on con una cruz roja situado en la fila de la tabla correspondiente al presupuesto que desee rechazar. Tras pulsar, el estado del presupuesto cambiar´a a borrador. Por tanto, desaparecer´a de la tabla y podr´a volver a ser editado por el comercial. Visualizar un archivo PDF de un presupuesto: Para visualizar un presupuesto, bastar´a con pulsar en el bot´on con el icono de descarga situado en la fila de la tabla correspondiente al presupuesto que desee visualizar. Tras pulsar, se abrir´a un visualizador de PDF como el de la figura 11.5 que permitir´a al usuario ver el presupuesto, descargarlo, imprimirlo... Figura 11.4: Panel de Revisi´on de Presupuestos 145 Figura 11.5: Visualizador de archivos PDF 11.3.2. Gesti´on de Cargos Para acceder a la vista de gesti´on de cargos del sistema, ser´a necesario pulsar el bot´on ’CARGOS’ situado en la barra lateral. Desde esa vista, el usuario podr´a realizar las siguientes acciones: Visualizar cargos del sistema: Al acceder a la vista de cargos, el usuario podr´a visualizar una tabla con todos los cargos del sistema, incluyendo el nombre del cargo y su salario por hora (figura 11.6). Crear un cargo: Para a˜nadir un cargo al sistema, el usuario deber´a pulsar el bot´on de ’A ˜ NADIR’ de la parte superior de la pantalla, rellenar el formulario del di´alogo (figura 11.7) con el nombre del cargo y su salario y nuevamente pulsar ’A˜ NADIR’. Se crear´a el cargo y aparecer´a en la tabla. Editar un cargo: Para editar un cargo, el usuario deber´a pulsar el bot´on del l´apiz situado en la fila de la tabla correspondiente al cargo que desee editar. Nuevamente, aparecer´a un cuadro de di´alogo con un formulario con los datos del cargo (figura 11.8). Cuando el usuario haya acabado de editar los datos, deber´a pulsar ’GUARDAR’. El cargo se mostrar´a actualizado en la tabla. Eliminar un cargo: Para eliminar un cargo, el usuario deber´a pulsar el bot´on del cubo de la basura situado en la fila de la tabla correspondiente al cargo que desee eliminar. Aparecer´a un di´alogo de confirmaci´on similar al visto previamente para eliminar un usuario (figura 11.3). Al pulsar ’ELIMINAR’, el cargo ya no aparecer´a en la tabla. 146 Figura 11.6: Panel de Gesti´on de Cargos Figura 11.7: Crear Cargo 147 Figura 11.8: Editar Cargo 148 11.3.3. Par´ametros del Sistema Para acceder a la vista de gesti´on de par´ametros del sistema, ser´a necesario pulsar el bot´on ’EDITAR PAR ´ AMETROS’ situado en la barra lateral. Desde esa pantalla (figura 11.9), el usuario podr´a visualizar los par´ametros que tiene actualmente el sistema y editarlos cambiando los valores de los campos de texto y pulsando en ’ACTUALIZAR’. Al actualizar los par´ametros del sistema, todos los presupuestos en estado ’borrador’ del sistema se recalcular´an utilizando los nuevos valores proporcionados por el usuario, mientras que aquellos que est´en ’pendientes de aprobaci´on’ o ’aprobados’ utilizar´an los par´ametros que tuviesen en el momento de su aprobaci´on. Figura 11.9: Editar Par´ametros 11.4. Comerciales Los usuarios del sistema con rol de comerciales podr´an realizar las siguientes acciones: visualizar todos los presupuestos del sistema, crear un presupuesto, editarlo, eliminarlo, duplicarlo y visualizar un archivo PDF del mismo. 11.4.1. Administraci´on de Presupuestos Al iniciar sesi´on con una cuenta de usuario con rol de jefe, se podr´a visualizar un panel de control (figura 11.10) que mostrar´a todos los presupuestos del sistema: su nombre, su creador, su estado, su fecha de creaci´on, su ´ultima fecha de actualizaci´on y, en el caso de los presupuestos aprobados, el usuario que lo aprob´o. En dicho panel se podr´an realizar las siguientes acciones: Crear un presupuesto: Para crear un nuevo presupuesto, el usuario deber´a introducir un nombre para el mismo en el formulario de la parte superior de la pantalla y pulsar en ’CREAR’. Esto le llevar´a al editor de presupuestos con un presupuesto ”vac´ıo”sobre el que trabajar. Mas adelante se detallar´an todas las acciones que se pueden llevar a cabo en dicha pantalla para construir los presupuestos. 149 Eliminar un presupuesto: Esta acci´on s´olo se puede llevar a cabo sobre los presupuestos que a´un est´an en estado de borrador. Para eliminar un presupuesto, el usuario deber´a pulsar el bot´on del cubo de la basura situado en la fila de la tabla correspondiente al cargo que desee eliminar. Aparecer´a un di´alogo de confirmaci´on similar al visto previamente para eliminar un usuario (figura 11.3). Al pulsar ’ELIMINAR’, el presupuesto ya no aparecer´a en la tabla. Visualizar un archivo PDF de un presupuesto: Se realizar´a de la misma forma que se explic´o previamente para la visualizaci´on de archivos en la pantalla de gesti´on de presupuestos. Esta acci´on s´olo se puede llevar a cabo sobre los presupuestos en estado aprobado o pendiente de aprobaci´on. Duplicar un presupuesto: Para duplicar un presupuesto, el usuario deber´a pulsar el bot´on con el icono de copia situado en la fila de la tabla correspondiente al presupuesto que desee duplicar. Al pulsarlo, se crear´a un nuevo presupuesto con el mismo contenido que el seleccionado, pero en su nombre habr´a a˜nadido un ’(copia)’ al final, para que puedan ser distinguidos. Editar un presupuesto: Esta acci´on s´olo se puede llevar a cabo sobre los presupuestos que a´un est´an en estado de borrador. Para editar un presupuesto, el usuario deber´a pulsar el bot´on del l´apiz situado en la fila de la tabla correspondiente al presupuesto que desee editar. Al pulsarlo, el usuario ser´a llevado al editor de presupuestos con el presupuesto seleccionado para que pueda trabajar sobre ´el. A continuaci´on se explicar´a con detalle todas las acciones que se pueden llevar a cabo en dicha pantalla. Figura 11.10: Panel de Administraci´on de Presupuestos 11.4.2. Editor de Presupuestos La vista de edici´on de presupuestos permite al usuario editar los datos de un presupuesto y a˜nadirle materiales, servicios, tareas o viajes. Como se ha explicado previamente, se puede acceder a ella al crear un presupuesto o al editar uno. En primer lugar, se muestra un formulario (figura 11.11) con los datos principales del presupuesto. Desde este formulario se pueden editar dichos datos y para modificarlos, el usuario tiene dos opciones: 150 SALIR SIN GUARDAR: Al pulsar el bot´on, el usuario volver´a a la pantalla de administraci´on. GUARDAR Y SALIR: Al pulsar el bot´on, el usuario actualizar´a los datos del presupuesto y volver´a a la pantalla de administraci´on. El estado del presupuesto seguir´a siendo el de ’borrador’. GUARDAR Y FINALIZAR: Al pulsar el bot´on, el usuario actualizar´a los datos del presupuesto y volver´a a la pantalla de administraci´on. El estado del presupuesto pasar´a a ser ’pendiente de aprobaci´on’, por lo que el usuario no podr´a continuar edit´andolo. Figura 11.11: Formulario del Presupuesto Debajo del formulario ya descrito, el usuario dispondr´a de una serie de datos que le permitir´an tener un vistazo general del presupuesto. Estos datos ser´an los siguientes: Gasto total en materiales, servicios, viajes, y dietas. Se mostrar´a adem´as el total de estas tres cifras y la diferencia entre dicho total y la oferta que se le ha realizado al cliente, lo que se conoce como la FACTURACI ´ ON NETA. Gasto total en mano de obra, incluyendo un resumen sobre la cantidad de horas que se necesitar´a de cada cargo que est´e involucrado en el presupuesto, as´ı como el precio total de estas horas. Adem´as, se mostrar´a la suma de esta cifra y el total en materiales, servicios y viajes, lo que se denomina TOTAL COSTES DIRECTOS. MARGEN TE ´ ORICO del proyecto. Es decir, la diferencia entre la oferta al cliente y el total de costes directos del presupuesto. Recuperaci´on de costes indirectos del proyecto. Se utilizan los porcentajes definidos en los par´ametros del sistema para realizar el c´alculo de dichos costes para materiales y servicios, viajes y mano de obra. El total es el denominado TOTAL COSTES INDIRECTOS. Oferta al cliente - (dinero que se espera ganar) COSTE TOTAL: Suma de los costes directos e indirectos del proyecto. BENEFICIO ANTES DE IMPUESTOS: Diferencia entre el coste total y la oferta al cliente. 151