Adaptación e implantación de una arquitectura blockchain para dar soporte al trabajo de equipos en una organización

Universidad de Valladolid ESCUELA DE INGENIER´ IA INFORM´ ATICA GRADO EN INGENIER´ IA INFORM ´ ATICA Menci´on en tecnolog´ıas de la informaci´on ADAPTACI´ ON E IMPLANTACI´ ON DE UNA ARQUITECTURA BLOCKCHAIN PARA DAR SOPORTE AL TRABAJO DE EQUIPOS EN UNA ORGANIZACI´ ON Alumno: Sa´ul Llamas Garc´ıa Tutores: Joaqu´ın Nicol´as Adiego Rodriguez Natalia Mart´ın Cruz A mis padres que me han dado todo. I II AGRADECIMIENTOS Agradecimientos A mi padre, por haberme todos los recursos que me han permitido llegar hasta aqu´ı. A mi madre, por ser una luchadora que ha cuidado toda la vida de m´ı. A mis hermanos que han estado ah´ı siempre que los necesito. A mis amigos que siempre han estado ah´ı en los buenos y en los malos momentos. A la gran cantidad de compa˜neros con los que he tenido honor de compartir clase, y que han logrado que este camino haya sido mucho m´as f´acil de lo que parec´ıa. III AGRADECIMIENTOS IV RESUMEN Resumen El proyecto expuesto en este documento tiene como objetivo desarrollar una aplicaci´on que permita dar soporte a la planificaci´on, gesti´on y validaci´on de entregas y tareas de los grupos de trabajo que forman una organizaci´on, haciendo uso de las tecnolog´ıas emergentes de la blockchain con el objetivo de mantener un registro inmutable de todas estas actividades. Este proyecto ha sido desarrollado sobre una red Ethereum, haciendo uso de la implementaci´on Geth (Go Ethereum) para el despliegue de esta. As´ı como se ha utilizado tambi´en el sistema IPFS (Sistema de archivos interplanetario) para el almacenamiento de archivos. Para el desarrollo de contratos inteligentes se ha utilizado el lenguaje Solidity. En cuanto al desarrollo del front-end ha sido realizado en JavaScript, haciendo uso de la librer´ıa React, as´ı como se han utilizado las tecnolog´ıas HTML5 y CSS. Para la comunicaci´on con la red Ethereum se ha utilizado la librer´ıa Web3JS. V RESUMEN VI ABSTRACT Abstract The exposed project presented in this document aims to develop an application which allows to support the management and validation of deliveries and tasks of the working groups which form an organization. This project makes use of emerging blockchain technologies, adapting the traditional architecture of an application to these new technologies This project has been developed on an Ethereum network, making use of the Geth implementation (Go Ethereum) for its deployment as well as IPFS (Interplanetary File System) system for file storage. The Solidity language has been used for the development of smart contracts. Regarding the front-end development, it has been performed in JavaScript, using the React library, as well as HTML5 and CSS technologies. For communication with the Ethereum network, the Web3JS library has been used. VII ´ INDICE GENERAL A.6.3.Edici´ondetareas.............................. 96 A.7.Misnotificaciones.................................. 96 B. Resumen de enlaces adicionales 97 Bibliograf´ıa 99 XIV ´ INDICE DE FIGURAS ´ Indice de figuras 3.1. Roles e interacci´on. Obtenida de [60] . . . . . . . . . . . . . . . . . . . . . . . 13 3.2. Eventos y artefactos. Obtenida de [54] . . . . . . . . . . . . . . . . . . . . . . 15 5.1. Modelo conceptual de dominio. . . . . . . . . . . . . . . . . . . . . . . . . . . 26 5.2. Descentralizado vs centralizado. Obtenida de [18] . . . . . . . . . . . . . . . . 29 5.3. Esquema conceptual de la arquitectura. . . . . . . . . . . . . . . . . . . . . . 30 6.1. Ciclo de vida, componente React. Obtenida de [38] . . . . . . . . . . . . . . . 34 6.2. Ciclo de vida, hooks. Obtenida de [44] . . . . . . . . . . . . . . . . . . . . . . 36 6.3. Ramas de Git. Obtenida de [6] . . . . . . . . . . . . . . . . . . . . . . . . . . 39 7.1. Ramas de Git. Obtenida de [23] . . . . . . . . . . . . . . . . . . . . . . . . . . 42 7.2. Esquema b´asico MVVM React realizado por m´ı. . . . . . . . . . . . . . . . . 43 7.3. Comportamiento base para a˜nadir un hash utilizando el patr´on off-chain . . . 44 7.4. Comportamiento base para obtener un documento utilizando el hash . . . . . 44 7.5. Diagrama de componentes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 7.6. Representaci´on del esfuerzo del backend frente al front-end. .......... 48 7.7. Cliente servidor tres niveles, tomada de [40] . . . . . . . . . . . . . . . . . . . 49 7.8. Diagrama de despliegue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 8.1. Modelo final en implementaci´on . . . . . . . . . . . . . . . . . . . . . . . . . . 56 XV ´ INDICE DE FIGURAS A.1.Barraadministrador ................................ 83 A.2.Barrausuario.................................... 83 A.3.Creaci´ondecuentas ................................ 84 A.4.Creaci´ondecuentas ................................ 84 A.5.Creaci´ondegrupos ................................ 85 A.6.Creaci´ondegrupos................................. 85 A.7.Creaci´ondeproyectos ............................... 86 A.8.A˜nadirtareas.................................... 87 A.9.Fasedeentrega................................... 88 A.10.Fasedeentrega................................... 88 A.11.Fasedeentrega................................... 89 A.12.Validaci´ondegrupo ................................ 90 A.13.Validaci´ondegrupo ................................ 90 A.14.Validaci´on creador de la tarea . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 A.15.Validaci´on creador de la tarea . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 A.16.Validaci´on creador de la tarea . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 A.17.Validaci´on creador de la tarea . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 A.18.Finalizartarea ................................... 93 A.19.Finalizartarea ................................... 93 A.20.Edici´ondeproyectos................................ 94 A.21.Edici´ondeproyectos................................ 94 A.22.Edici´ondegrupos ................................. 95 A.23.Edici´ondegrupos ................................. 95 A.24.Edici´ondetareas.................................. 96 A.25.Misnotificaciones.................................. 96 XVI ´ INDICE DE TABLAS ´ Indice de tablas 3.1. Planificaci´on inicial de los sprints . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.2. Descripci´on de las historias de usuario . . . . . . . . . . . . . . . . . . . . . . 18 4.1. Riesgo 1: Variabilidad de historias de usuario. . . . . . . . . . . . . . . . . . . 20 4.2. Riesgo 2: Problemas en la formaci´on del alumno. . . . . . . . . . . . . . . . . 20 4.3. Riesgo 3: Falta de conocimiento para realizar el proyecto . . . . . . . . . . . . 20 4.4. Riesgo 4; Imposibilidad de realizar reuniones. . . . . . . . . . . . . . . . . . . 21 4.5. Riesgo 5: Retraso en el desarrollo de tareas . . . . . . . . . . . . . . . . . . . 21 4.6. Riesgo 6: Baja por enfermedad o problemas t´ecnicos. . . . . . . . . . . . . . . 21 4.7. Riesgo 7: Problemas de despliegue de la aplicaci´on . . . . . . . . . . . . . . . 21 4.8. Riesgo 8: Problemas en el cumplimiento de la ficha final inicial. . . . . . . . . 21 8.1. Bater´ıa de pruebas de alto nivel navegaci´on . . . . . . . . . . . . . . . . . . . 59 8.2. Bater´ıa de pruebas de alto nivel creaci´on de grupos, proyectos y tareas. . . . 60 8.3. Bater´ıa de pruebas de alto nivel creaci´on de grupos, proyectos y tareas. . . . 60 8.4. Bater´ıa de pruebas validaci´on de tareas . . . . . . . . . . . . . . . . . . . . . 61 8.5. Bater´ıa de pruebas de alto nivel navegaci´on . . . . . . . . . . . . . . . . . . . 61 8.6. Configuraci´oninicial ................................ 63 9.1. Sprint0 ....................................... 70 9.2. Sprint1........................................ 71 XVII ´ INDICE DE TABLAS 9.3. Sprint2 ....................................... 72 9.4. Sprint3 ....................................... 74 9.5. Sprint4 ....................................... 74 9.6. Sprint5 ....................................... 75 9.7. Sprint6 ....................................... 76 9.8. Sprint7 ....................................... 78 9.9. Sprint8 ....................................... 79 9.10.Sprint9 ....................................... 79 XVIII CAP´ ITULO 1. INTRODUCCI ´ ON Cap´ıtulo 1 Introducci´on Cuando escuchamos “blockchain”lo primero que se nos pasa por la cabeza son las criptomon´edas, pero hay mucho m´as detr´as de esta tecnolog´ıa.(Explicada en detalle en el cap´ıtulo 2).En los ´ultimos tiempos se est´a utilizando esta tecnolog´ıa para tareas tales como procesos de licitaci´on de contratos [68], alternativas de DNS [47], o aplicaciones descentralizadas (DApps) [8]. En esta nueva rama del desarrollo de aplicaciones distribuidas (DApps) se engloba este proyecto que toma la idea base de los algoritmos que utilizan las tecnolog´ıas de la blockhain, con el objetivo de realizar una aplicaci´on que gestione conjunto de tareas que se producen en el flujo del trabajo en equipo una organizaci´on, manteniendo as´ı un registro inmutable de los datos asociados a las entregas de esas tareas. A groso modo, estos algoritmos (Explicados en detalle en la secci´on 2.1.2) de los que se toma la idea de proyecto, permiten que todos los miembros de la red sincronicen un conjunto de informaci´on que todos tienen en com´un, que es inalterable. Y que cada inserci´on que se produzca en este conjunto de informaci´on, se realice con la seguridad de que cumple con las condiciones anteriormente expuestas, y que por tanto pueda ser sincronizada de forma segura por el resto. De esta manera el conjunto de personas que forman un grupo dentro de un proyecto de una organizaci´on , que tienen unas tareas asignadas, podr´an realizar una entrega asociada a esa tarea. Este proceso de entrega consta de un proceso de consenso del contenido de la entrega, donde todos los miembros dan su ‘s´ı’ explicito a que el contenido de esta es el correcto y final, y que por tanto esta entrega sea almacenada de manera inalterable en un registro hist´orico e inmutable, es decir, en la blockchain. 1 1.1. MOTIVACI ´ ON 1.1. Motivaci´on La idea de este proyecto nace de los algoritmos de la blockchain (Explicados en detalle en la secci´on 2.1.2), que logran que todos sus miembros mantengan un conjunto de datos inalterables de forma com´un, sin necesidad de que una entidad centralizada intervenga en la validaci´on de la introducci´on de nuevos datos. De esta forma, estos mecanismos logran alcanzar un consenso entre los miembros de la red, sobre la sobre la integridad e inmutabilidad de los datos que residen sin necesidad de recurrir a un tercero. Se toma por tanto esta idea a para lograr que un grupo de trabajo formado por diversos miembros, realice una validaci´on en conjunto de la entrega, y que cuando esta tenga el consenso de todos los miembros, sea almacenada en la blockchain. De esta manera, se producir´a un proceso de consenso donde mediante la aplicaci´on cada miembro del grupo deba dar un ’s´ı’ expl´ıcito, respecto a que este es el resultado final de una entrega asociada a una tarea. De esta manera, el grupo logra llega a un consenso de que este es el resultado final. Por tanto una vez finalizado el consenso esto quedar´a plasmado dentro de la blockchain (Explicado en el cap´ıtulo 2), pues como cada miembro ser´a participe de la red, cuando se produzca el registro en la blockchain de esta entrega por parte de uno de los miembros, al ser todos participes de una red de consenso, esta informaci´on quedar´a almacenada de forma inmutable e accesible para todos estos miembros, siendo impl´ıcitamente aceptada por todos los participantes de la red. 1.2. Objetivos El objetivo general de este proyecto es desarrollar una aplicaci´on de trabajo en equipo basada en una arquitectura que tome por tecnolog´ıa de almacenamiento principal la cadena de bloques, y que permita mantener en esta un historial inmutable de las tareas realizadas y de su contenido. 1.2.1. Objetivos t´ecnicos de desarrollo Los objetivos principales de este proyecto son: An´alisis de las tecnolog´ıas existentes con el objetivo de seleccionar una segura y acorde a la idea del trabajo en equipo. Adecuaci´on de la aplicaci´on a las retracciones impuestas por las tecnolog´ıas de la blockchain que surjan durante el desarrollo del proyecto, con el objetivo de mantener la idea base de la aplicaci´on. Proporcionar un mecanismo de validaci´on de tareas en equipo, que permita mantener un registro inmutable de las transacciones (Entregas) de los usuarios 2 CAP´ ITULO 1. INTRODUCCI ´ ON Proporcionar un acceso a la aplicaci´on por parte del usuario sin requerir de software de terceros. 1.2.2. Objetivos personales En cuanto a mis objetivos personales basados en la finalizaci´on de mis estudios residen: Conocer un nuevo framework de desarrollo web, mejorando as´ı mis facetas del desarrollo web en el apartado de front end Conocer nuevas tecnolog´ıas futuras alternativas de backend como pudiera ser la blockchain. Complementar la planificaci´on y desarrollo de un proyecto, con los realizados en mis pr´acticas curriculares con el objetivo de formarme acerca de diversas metodolog´ıas o mejorar en ellas. Ganar independencia en el trabajo buscando retos en tecnolog´ıas emergentes, donde encontrar´e nuevos retos y problemas a solventar. Aprender nuevos lenguajes de programaci´on como Solidity. Realizar un despliegue real de una aplicaci´on. 1.3. Usuarios objetivos Principalmente esta aplicaci´on esta destinada a ser utilizada como un sistema de validaci´on dentro del ´ambito escolar por parte de mis tutores de TFG. Ser´ıa por tanto utilizada para la entrega y validaci´on de tareas dentro de grupos de trabajo en aula. Adicionalmente,esta aplicaci´on tiene tambi´en como mercado secundario a aquellas organizaciones que necesiten, o tengan pensado en un futuro utilizar un sistema de organizaci´on y planificaci´on de tareas, que requiera de una de validaci´on segura, previa a la entrega por parte de los grupos de trabajo presentes en la organizaci´on. Utilizar´ıan esta aplicaci´on en un entorno de red privado. 1.4. Estructuraci´on de la memoria El presente documento est´a estructurado en los siguientes cap´ıtulos: Cap´ıtulo 2 Estado del arte, este cap´ıtulo recoge la investigaci´on previa de las tecnolog´ıas existentes blockchain, as´ı como el funcionamiento de esta. 3 1.4. ESTRUCTURACI ´ ON DE LA MEMORIA Cap´ıtulo 3 Planificaci´on y desarrollo del proyecto, en este cap´ıtulo se aborda la planificaci´on inicial realizada en el proyecto, aplicando una metodolog´ıa ´agil. Cap´ıtulo 4 Plan de riesgos y costes, en este cap´ıtulo se realiza una estimaci´on del coste del proyecto y de los posibles riesgos a los que se enfrenta este proyecto. Cap´ıtulo 5 An´alisis previo, en el marco de la metodolog´ıa ´agil, este cap´ıtulo est´a destinado a el an´alisis previo que se realiza en el sprint 0 con el objetivo de esclarecer una visi´on m´as clara del proyecto. Cap´ıtulo 6 Tecnolog´ıas utilizadas, cap´ıtulo destinado a la descripci´on de las tecnolog´ıas seleccionadas en este proyecto. Cap´ıtulo 7 Dise˜no, cap´ıtulo destinado a la fase de dise˜no de la aplicaci´on Cap´ıtulo 8 Implementaci´on, despliegue y pruebas, cap´ıtulo destinado a la fase de implementaci´on y despliegue de la aplicaci´on, y las pruebas realizadas sobre este Cap´ıtulo 9 Seguimiento del proyecto, este cap´ıtulo est´a destinado a la serie de sprints que se han realizado a lo largo del proyecto, y los eventos relacionados con estos. Cap´ıtulo 10 Conclusiones, cap´ıtulo final para realizar una valoraci´on del proyecto, y el posible futuro de este proyecto. Finalmente existen una serie de ap´endices donde est´a el manual de usuario 4 CAP´ ITULO 2. LA BLOCKCHAIN Cap´ıtulo 2 La blockchain 2.1. Fundamentos de la blockchain 2.1.1. Introduci´on a la blockchain Una cadena de bloques (en ingl´es blockchain), es una estructura de datos cuya informaci´on se agrupa en conjuntos (bloques) incorporando metadatos, relativas a otro bloque de la cadena anterior en una l´ınea temporal. Debido a las t´ecnicas criptogr´aficas empleadas, la modificaci´on de un bloque solo puede ser lograda modificando todos los bloques anteriores, que por tanto a medida que crece logra un almacenamiento de informaci´on irrefutable e inmutable. Podr´ıa verse por tanto como una base de datos no relacional (un log o un registro hist´orico) donde se almacena informaci´on relativa a transacciones que han ocurrido en un sistema o entre usuarios. 2.1.2. Principios de la blockchain La gobernanza es una estructura a trav´es de la cual un participante o usuario de un sistema acepta utilizar este bajo una serie de normas. Para que cualquier sistema de gobernanza funcione correctamente, deben existir tres elementos sin que estos interfieran entre s´ı: [21] Gobernantes Reglas Participantes Una de las caracter´ısticas clave de blockchain es la descentralizaci´on, incrementando la complejidad de de la gobernanza sobre blockchain. Por tanto aqu´ı es donde entra el concepto 5 3.1. ENFOQUE SELECCIONADO 3.1.1. Scrum Se ha seleccionado el framework Scrum para el desarrollo de este proyecto. Scrum es un proceso de gesti´on que reduce la complejidad en el desarrollo de productos para satisfacer las necesidades de los clientes. La gerencia y los equipos de Scrum trabajan juntos alrededor de requisitos y tecnolog´ıas para entregar productos funcionando de manera incremental usando el empirismo. Existen tres pilares b´asicos que soportan toda la implementaci´on del control de procesos emp´ıricos la transparencia, la inspecci´on y la adaptaci´on. [4] [34] La transparencia: Debe emplearse una terminolog´ıa regida por un est´andar com´un, de tal forma que los observadores puedan comprender y entender lo que est´an viendo, as´ı como todos estos aspectos deben ser visibles para los interesados en el resultado. La inspecci´on: Aquellos usuarios involucrados en el marco de Scrum, deben realizar una inspecci´on del progreso realizado con el objetivo de evitar variaciones indeseadas. La frecuencia de estas no debe ser alta, para evitar que interfiera en el trabajo. La adaptaci´on: En caso de producirse una variaci´on por encima de los l´ımites marcados como aceptables, debe reajustarse el proceso o material que estaba siendo procesado. Dicho ajuste debe producirse lo m´as pronto que sea posible con el objetivo de minimizar el crecimiento de esa desviaci´on. 3.1.2. Organizaci´on de equipos y roles en Scrum Los grupos de trabajo de Scrum (“Scrum Teams”) est´an formados generalmente de 3 a 10 miembros, es decir, que el tama˜no de estos suele ser bastante peque˜no. Dentro de estos grupos de trabajo existen tres roles (Que podemos visualizarlos en la figura 3.1 entablados dentro de la categor´ıa de “roles centrales”.La otra categor´ıa ser´ıa la de roles no centrales). Estos tres roles son: [34] Product owner: El Due˜no de Producto es el responsable de maximizar el valor del producto y el trabajo del Equipo de Desarrollo(Este proceso podr´ıa variar en cada organizaci´on). Adem´as es el responsable de gestionar la lista de producto. (Ver Product Backlog en la secci´on 3.1.4) Development Team: Formado por el grupo de personas que realizan la creaci´on de incremento (Ver incremento en la secci´on 3.1.4), as´ı como realizan la labor de entregar un incremento de producto “terminado”, que pueda ser potencialmente desplegado en producci´on al final de cada “sprint”(Ver Sprint en la secci´on.3.1.3). Cabe decir que estos grupos son autoorganizados, pues no existe una orden de un miembro superior de como transformar un elemento de la lista de producto en incrementos de funcionalidad. 12 CAP´ ITULO 3. PLANIFICACI ´ ON Y DESARROLLO DEL PROYECTO Scrum Master: Es el encargado de que Scrum se entienda y se adopte correctamente dentro del Scrum Team . Es el l´ıder del proyecto, pero que a su vez est´a al servicio del del Scrum Team ayud´andoles a encontrar soluciones a los problemas encontrados as´ı como es responsable de la eficiencia y del cumplimiento de los objetivos de este equipo.Adem´as permite que personas externas a este equipo entienda que interacciones pueden ser ´utiles y cuales no. Estas interacciones son clave, pues el Scrum Master tiene el objetivo, y res responsable de maximizar el valor del producto Figura 3.1: Roles e interacci´on. Obtenida de [60] 3.1.3. Eventos Scrum En Scrum existen eventos predefinidos con el fin de crear regularidad y minimizar la necesidad de reuniones no definidas en Scrum. Todos los eventos son bloques de tiempo (timeboxes), de tal modo que todos tienen una duraci´on m´axima. [34] (Podemos encontrarnos una visi´on de este proceso en la figura 3.2 Entre los eventos que nos podemos encontrar: Sprint: Es el elemento base de Scrum, consiste en un bloque de tiempo de entre 2 semanas y 1 mes, donde se crea un incremento ( Ver en la secci´on 3.1.4) que es marcado como ‘terminado’ en la finalizaci´on de este periodo. La duraci´on de este bloque debe ser consistente a lo largo del proyecto, es decir, no debe variar la duraci´on del sprint. Tras 13 3.1. ENFOQUE SELECCIONADO la finalizaci´on de un sprint, inmediatamente comienza otro. Un Sprint podr´ıa cancelarse si el objetivo est´a desfasado respecto a una idea de mercado actual. Sprint Planning: Previo al comienzo del Sprint se realiza una planificaci´on de este, donde esta planificaci´on es realizada por el equipo Scrum al completo, y tiene un m´aximo de duraci´on de 8h para un sprint de un mes. Se trata por tanto de fijar los objetivos y tareas que se realizar´a en este sprint. A estas tareas se le asigna una estimaci´on de carga, formada por puntos de historia, y que es representada en forma de horas en cuanto a trabajo equivalente.(Existen varias t´ecnicas como la escala lineal o estimaci´on de p´oker, que asignan un n´umero predefinido a cada punto) De esta manera las tareas quedan representadas en horas de trabajo dentro de un sprint. Sprint Goal: Es una meta establecida en el sprint en cuesti´on, y que se desglosa en Historias de Usuario (H.U) del Backlog (Ver secci´on 3.1.4 pertenecientes al sprint. De esta manera sirve de punto referencia mental a la hora de realizar de desarrollar la funcionalidad requerida. Daily Scrum: En espa˜nol Scrum diario, es una reuni´on diaria de unos 15 minutos donde el Team Scrum donde se sincroniza y evaluado el trabajo realizado en las ´ultimas d´ıa adecu´andolo al Sprint goal, y se planifica el de las futuras pr´oximas 24h. Sprint Review: En espa˜nol revisi´on del sprint, es una renuni´on realizada al final del sprint con el objetivo de inspeccionar el incremento, modificar y adaptar la Lista de Producto (Ver secci´on 3.1.4). Se trata de una reuni´on informal con el objetivo de facilitar la retroalimentaci´on de informaci´on y fomentar la colaboraci´on.Participan Participan en ella el Product Owner, el Development Team, y el Scrum Master. Sprint Retrospective:En espa˜nol retospectiva del sprint, es una reuni´on que se realiza al final del sprint y tiene como objetivo inspeccionar el proceso realizado en el ´ultimo sprint, identificando aquellos elementos que han salido satisfactoriamente, que pueden ser objeto de mejora en futuros sprints. De esta manera se logra la mejora en la forma de trabajo del Scrum Team. Tiene una duraci´on m´axima de 3h para un sprint de 1 mes. Sprint 0: Corresponde a la fase previa al inicio de un proyecto de Scrum, donde se realiza un estudio previo del campo del proyecto, as´ı como se prepara la arquitectura, una planificaci´on inicial y una versi´on incial del Backlog (Ver secci´on 3.1.4) Cabe decir que este “sprint”no genera ning´un valor al producto, y por tanto muchos miembros de la comunidad de Scrum rechazan esta nomenclatura, consider´andolo simplemente una fase previa. 3.1.4. Artefactos Scrum Los artefactos de Scrum tiene como objetivo representar el trabajo o valor en diversas formas que son ´utiles para proporcionar transparencia y oportunidades para la inspecci´on 14 CAP´ ITULO 3. PLANIFICACI ´ ON Y DESARROLLO DEL PROYECTO Figura 3.2: Eventos y artefactos. Obtenida de [54] y adaptaci´on. Los artefactos definidos por Scrum est´an dise˜nados espec´ıficamente para maximizar la transparencia de la informaci´on clave, necesaria para asegurar que todos tengan el mismo entendimiento del artefacto. [34] En la figura 3.2 podemos visualizar tambi´en los artefactos citados a continuaci´on: Product Backlog: En espa˜nol Lista de Producto es una lista ordenada por prioridad de los requisitos del producto. Cabe decir que esta lista nunca est´a completa, se establece un Backlog inicial, que refleja los requisitos conocidos y mejor entendidos al principio.El Product Backlog sufrir´a cambios a lo largo del proyecto, y por tanto es variable.Las personas encargadas de proporcionar las estimaciones en el Product Backlog son los integrantes del Development Team.El Due˜no de Producto (Product Owner) es el responsable de la Lista de Producto, incluyendo su contenido, disponibilidad y ordenaci´on. Los requisitos del producto son denominados historias de usuario. Sprint Backlog, en espa˜nol Lista de Pendientes del Sprint, es el conjunto de historias de usuario de la Lista del Backlog seleccionadas para el Sprint actual, sumado a un plan para entregar el Incremento de producto y conseguir el Sprint Goal. Una vez seleccionada esta lista, es inmutable mientras est´a en desarrollo, con el objetivo de optimizar el trabajo obteniendo as´ı una visi´on de cuan cerca se est´a del Sprint Goal. Incremento: Es la suma de todos los elementos del Backlog completados en el sprint actual, m´as aquellos que anteriormente ya hab´ıan sido completados en sprints anteriores. Al final de un Sprint el nuevo Incremento debe estar “Terminado”, lo cual significa que est´a en condiciones de ser utilizado 15 3.2. PLANIFICACI ´ ON 3.2. Planificaci´on 3.2.1. Adaptaci´on de Scrum al proyecto En el contexto explicado en la secci´on 3.1 con una variabilidad de los requisitos a lo largo del proyecto debido a la incertidumbre de las tecnolog´ıas escogidas es necesario aplicar la metodolog´ıa de Scrum sobre el marco de este proyecto. Primariamente estableceremos los roles, donde el alumno ser´a Product Owner, as´ı como ser´a el ´unico miembro activo en el Development Team. Finalmente el Rol de Scrum Master ser´a ocupado por Joaqu´ın Adiego, co-dirigente del TFG, as´ı como Natalia Mart´ın, co-dirigente tambi´en del TFG ocupar´a el rol de stakeholder. Quedan establecidas las reuniones mediante videoconferencia las revisiones del sprint y retrospectivas, de la misma forma que en esta reuni´on se trata la planificaci´on del siguiente sprint. En caso de indisponibilidad de alguna de las partes, por diversos motivos, ya sea por las pr´acticas del alumno u otro motivo, con motivo de no retrasar los sprints y cumplir los plazos la comunicaci´on ser´ıa de forma escrita, pero con una explicaci´on detalla e exhaustiva tratando as´ı de evitar desviaciones en los objetivos planteados. Existir´a tambi´en una comunicaci´on constante semanal v´ıa correo con el Scrum Master con el objetivo de solventar problemas que requieran de su intervenci´on. Debido a la incertidumbre relativa al proyecto, se realizar´a un sprint 0 con el objetivo de analizar las tecnolog´ıas m´as apropiadas para la realizaci´on del proyecto. De esta manera este sprint servir´a como pre´ambulo a la redacci´on del cap´ıtulo 2. Se ha establecido para el valor de los puntos de historia la t´ecnica de p´oker [35].El Planning p´oker es una t´ecnica para estimar usando story points en donde cada miembro del Development Team debe otorgar un estimado en story points al ´ıtem que se est´e tratando, usando una sucesi´on de Fibonacci (0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89). 3.2.2. Planificaci´on inicial de los sprints El plan de estudios del grado en Ingenier´ıa Inform´atica establece que la duraci´on del TFG son 300h. La fecha final del proyecto tambi´en ser´a acorde a la fecha l´ımite de entrega de la convocatoria ordinaria del TFG. Por tanto, se ha establecido la duraci´on de los sprints en 2 semanas, teniendo cada uno una carga de 34h aproximadamente por sprint. En la tabla 3.1 puede verse una planificaci´on inicial. Esta planificaci´on es susceptible a cambios, as´ı como la fecha de finalizaci´on podr´ıa basarse en la fecha l´ımite de la convocatoria extraordinaria. 16 CAP´ ITULO 3. PLANIFICACI ´ ON Y DESARROLLO DEL PROYECTO Sprint Comienzo Fin Sprint 1 15/02/2021 01/03/2021 Sprint 2 01/03/2021 15/03/2021 Sprint 3 15/03/2021 29/03/2021 Sprint 4 29/03/2021 12/04/2021 Sprint 5 12/04/2021 26/04/2021 Sprint 6 26/04/2021 10/05/2021 Sprint 7 10/05/2021 24/05/2021 Sprint 8 24/05/2021 07/06/2021 Sprint 9 07/06/2021 21/06/2021 Tabla 3.1: Planificaci´on inicial de los sprints 3.2.3. Descripci´on de historias de usuario Las historias de usuario (H.U) son abordadas en el cap´ıtulo 9 donde se describen las tareas asignadas, y si se han incorporado nuevas. Sin embargo existe una planificaci´on inicial del Product Backlog que podr´a variar en el tiempo. Se puede ver en la tabla 3.2 un Backlog inicial. 3.2.4. Modificaciones de la planificaci´on inicial. En esta secci´on vamos a hablar de los cambios ocurridos sobre la planificaci´on inicial. Debido a problemas t´ecnicos con el equipo del alumno, en los sprints 6 y 7, donde no ha podido realizar sus labores se ha modificado la planificaci´on en las fechas de los sprints. Por tanto se ha retomado el sprint 6 en la fecha original del sprint planificado inicialmente como el 8 (D´ıa 24/05/2021). De esta manera se ha desplazado el calendario de sprints planificado inicialmente, manteniendo el n´umero de sprints restante y con la misma duraci´on de dos semanas. La finalizaci´on del proyecto por tanto se establecer´ıa sobre la fecha l´ımite del proyecto. Se ha a˜nadido a las historias de usuario la funcionalidad necesaria para que haya notificaciones dentro de la aplicaci´on. Puede verse en el cap´ıtulo 9 la variaci´on que se ha producido en los diversos sprints. En cuanto a la validaci´on inicialmente se propon´ıa la idea de que solo el grupo validase la tarea, aunque como veremos en la secci´on 5.3.1 finalmente tambi´en la persona que crea la tarea validar´a la entrega. 17 3.2. PLANIFICACI ´ ON H.U Nombre Descripci´on 1 Consultar tareas Como usuario quiero ver las tareas activas que tengo disponibles 2 Consultar historial Como usuario quiero ver el historial de las tareas finalizadas 3 Consultar informaci´on de grupo Como usuario quiero ver que miembros est´an formando actualmente mi grupo 4 Entrega Como usuario quiero poder realizar una entrega para una tarea. 5 Validaci´on de tarea Como usuario quiero poder marcar una tarea como validada. 6 Lista de entregas Como administrador quiero poder ver las entregas de una tarea 7 Registrar usuarios Como administrador quiero poder limitar quien se registra en la aplicaci´on 8 A˜nadir tareas Como administrador quiero poder a˜nadir nuevas tareas 9 Modificar tareas Como administrador quiero poder modificar las tareas creadas 10 Crear grupos Como administrador quiero poder crear grupos de trabajo 11 Modificar grupos Como administrador quiero poder modificar los grupos creados 12 Crear proyecto Como administrador quiero poder crear los proyectos creados 13 Eliminar grupos Como administrador quiero poder eliminar los grupos de trabajo 14 Eliminar tareas Como administrador quiero poder eliminar las tareas creadas 15 Consultar entrega Como usuario quiero poder consultar el estado de una entrega 16 Login Como usuario quiero poder loguearme para acceder a la aplicaci´on 17 Cerrar sesi´on Como usuario quiero poder cerrar la sesi´on actual. 18 Modificar proyectos Como administrador quiero poder modificar los proyectos creados Tabla 3.2: Descripci´on de las historias de usuario 18 CAP´ ITULO 4. PLAN DE RIESGOS Y ESTIMACI ´ ON DE COSTES Cap´ıtulo 4 Plan de riesgos y estimaci´on de costes Un riesgo es un evento o condici´on probable cuya ocurrencia tiene un efecto en los objetivos de un proyecto. [39] Por tanto este evento puede ocurrir en un futuro, y en caso de producirse tiene asociado un efecto. Se pueden categorizar estos riesgos en: Riesgos de proyecto: Son aquellos riesgos asociados relacionados con el no cumplimiento de los objetivos marcados por el equipo de desarrollo y el jefe de proyecto. Riesgos de negocio: Asociados al aspecto econ´omico. Por ejemplo, el retraso del proyecto puede desenvocar que la tecnolog´ıa ya no sea atractiva y las ventas no sean las esperadas. Por tanto debe realizarse una estimaci´on de los riesgos existentes, estimar el impacto de este, la probabilidad, y la importancia. Todo esto lo abordamos en el plan de riesgos que desarrollaremos a continuaci´on. Identificaci´on de riesgos Como dijimos en la secci´on 1.3, esta aplicaci´on est´a destinada a ser usada en el ´ambito escolar, si se estimase oportuno su uso. Por tanto, en un principio aunque tuviese un mercado secundario comercial, no est´a pensado en el desarrollo inicial de este proyecto su comercializaci´on, y por tanto quedar´ıa subordinado a otro proyecto que mejorase la implementaci´on actual. El resultado del an´alisis de riesgos se muestra en las tablas 4.1 a 4.8. En ellas se identifica el riesgo, estableciendo una probabilidad (Escala baja media alta), con un impacto en caso de producirse (Bajo, medio,alto). De la misma manera existir´a un plan de mitigaci´on (Reducir 19 la probabilidad de que ocurra) as´ı como de contingencia (Plan de actuaci´on en caso de que se materialice el riesgo) Riesgo encontrado Variaci´on en las historias de usuario del proyecto Probabilidad Alta Impacto Medio Plan de mitigaci´on Se ha seleccionado una metodolog´ıa ´agil con el fin de poder responder a los diversos cambios ocasionados en las historias de usuario por las restricciones que puedan existir en las tecnolog´ıas Plan de contingencia Modificaci´on del backlog Tabla 4.1: Riesgo 1: Variabilidad de historias de usuario. Riesgo encontrado Problemas de formaci´on en las tecnolog´ıas del proyecto Probabilidad Media Impacto Alta Plan de mitigaci´on Se han adquirido una serie de cursos de Udemy con el objetivo de mejorar la calidad de formaci´on Plan de contingencia Buscar nuevas fuentes de formaci´on. o buscar una tecnolog´ıa alternativa. Tabla 4.2: Riesgo 2: Problemas en la formaci´on del alumno. Riesgo encontrado Falta de conocimiento para aplicar una arquitectura blockchain Probabilidad Baja Impacto Alta Plan de mitigaci´on Se ha realizado un estudio de la arquitectura de aplicaciones similares Plan de contingencia Consultar a expertos, o foros de Ethereum para tratar de solventar los posibles problemas Tabla 4.3: Riesgo 3: Falta de conocimiento para realizar el proyecto 20 CAP´ ITULO 4. PLAN DE RIESGOS Y ESTIMACI ´ ON DE COSTES Riesgo encontrado Imposibilidad de realizar reuniones con el Scrum Master Probabilidad Media Impacto Bajo Plan de mitigaci´on Se ha establecido una posible franja horaria semanal. Plan de contingencia Comunicaci´on por correo. Tabla 4.4: Riesgo 4; Imposibilidad de realizar reuniones. Riesgo encontrado Retraso en el desarrollo de tareas Probabilidad Medio Impacto Medio Plan de mitigaci´on Planificaci´on no optimista en cuanto a duraci´on de las tareas Plan de contingencia Nueva planificaci´on de las tareas Tabla 4.5: Riesgo 5: Retraso en el desarrollo de tareas Riesgo encontrado Baja temporal en el equipo de desarrollo (Salud, problemas t´ecnicos..) Probabilidad Baja Impacto Alto Plan de mitigaci´on Se puede contar con un sprint de refuerzo en la fase final. Plan de contingencia Modificaci´on de la planificaci´on inicial de los sprints, y mover las tareas a futuros sprints. Tabla 4.6: Riesgo 6: Baja por enfermedad o problemas t´ecnicos. Riesgo encontrado El proyecto no puede ser desplegado en redes p´ublicas por seguridad. Probabilidad Bajo Impacto Alto Plan de mitigaci´on Se ha realizado un estudio, y se puede implementar una conexi´on segura. Plan de contingencia El proyecto se limitar´ıa a redes privadas de internet. Tabla 4.7: Riesgo 7: Problemas de despliegue de la aplicaci´on Riesgo encontrado El proyecto no cumple con la primera fecha l´ımite Probabilidad Medio Impacto Medio Plan de mitigaci´on Se ha previsto una segunda fecha l´ımite implicando un sobrecoste del proyecto Plan de contingencia Modificaci´on de la planificaci´on y incorporaci´on de nuevos sprints. Sobrecoste del proyecto Tabla 4.8: Riesgo 8: Problemas en el cumplimiento de la ficha final inicial. 21 5.3. AN ´ ALISIS DE LA FUNCIONALIDAD NECESARIA 3. La persona que cre´o la tarea (Responsable de la tarea) deber´a validar la tarea tambi´en. Pasar´a a fase 4. 4. El responsable deber´a por tanto marcar la tarea como finalizada, y se producir´a la inserci´on del documento en la blockchain. 28 CAP´ ITULO 5. AN ´ ALISIS PREVIO Figura 5.2: Descentralizado vs centralizado. Obtenida de [18] 29 5.3. AN ´ ALISIS DE LA FUNCIONALIDAD NECESARIA Figura 5.3: Esquema conceptual de la arquitectura. 30 CAP´ ITULO 6. TECNOLOG´ IAS UTILIZADAS Cap´ıtulo 6 Tecnolog´ıas utilizadas 6.1. Ethereum Ethereum es una plataforma open source, que sirve para programar contratos inteligentes. Sus aplicaciones web son denominadas como la web ’3.0’, debido a la descentralizaci´on de los servicios Se ha seleccionado esta tecnolog´ıa al ser la que m´as est´a creciendo actualmente, contando con una amplia comunidad de desarrolladores y con una documentaci´on en crecimiento y estable. En Ethereum hay dos formas de gestionar las cuentas, de forma local o remota. La primera forma se basa en que cada usuario genera una direcci´on privada (Clave privada), que es gestionada por ´el, y que es utilizada para firmar las transacciones que enviar´a a la blockchain. Permite garantizar el anonimato de la persona que posee esta cuenta, pues es necesario informar de la direcci´on p´ublica (clave p´ublica) para que se comuniquen contigo. La segunda de estas formas, es la utilizada en este proyecto. Todas las claves privadas est´an alojadas en un ´unico nodo, en este caso en el servidor. Esta decisi´on inicial de dise˜no, ha sido para facilitar la accesibilidad de los usuarios, impidiendo as´ı que tengan que desplegar un nodo, o utilizar una extensi´on como Metamask, evitando as´ı que instalen software de terceros, y sea accesible desde cualquier dispositivo. Al ser creadas de forma remota, estas cuentas necesitan de una contrase˜na o frase con la que se cifra la cuenta. Cuando sea necesario realizar una transacci´on, la cuenta debe ser desbloqueada con esta contrase˜na. Esta red ser´a privada, y por tanto estar´a limitado el acceso y creaci´on de cuentas. De esta manera, tambi´en ser´a ficticio el balance de las cuentas, y el computo necesario ser´a mucho menor. 31 6.2. REACT 6.1.1. Web3JS Web3JS (El 3 viene de la web ’3.0’ denominada por ellos y JS de JavaScript) es una API en Javascript compatible con Ethereum que implementa las especificaciones genericas RPC en formato JSON. Esta librer´ıa se comunica con un nodo local a trav´es de llamadas RPC (Sustituido en nuevas versiones por HTTP), y es compatible con los diversos tipos de nodos Ethereum que existen. [67] Esta tecnolog´ıa por tanto es la utilizada como proveedor, utilizando estos mecanismos de RPC (Y ahora HTTP en nuevas versiones) para interactuar desde el nodo con la web. 6.1.2. Clientes de Ethereum Existen varias implementaciones de Ethereum, en diversos lenguajes. En mi caso se ha seleccionado GoEth, que est´a escrita en Go. Basicamente estas implementaciones son ejecutables via CLI. (Consola) [32] 6.2. React React es una librer´ıa Javascript focalizada en el desarrollo de interfaces de usuario desarrollada por Facebook, y enfocada a p´aginas de tipo Single Page Tipe (SPA). La propia p´agina web se define as´ı, y no como un “framework”, como muchos tienden a pensar. B´asicamente React dentro de una arquitectura MVC estar´ıa enfocado a la vista. Su objetivo por tanto es ayudar al desarrollador web, evitando as´ı que tenga que desarrollar una gran cantidad de c´odigo javascript para lograr la funcionalidad. 6.2.1. Estructura de React Como hemos dicho anteriormente React es una librer´ıa, y como librer´ıa que es, se implementa sobre archivos de tipo JavaScript. Existe una curiosidad y es que el lenguaje de estos archivos no es propiamente JavaScript, si no una extensi´on de este (JSX). JSX es una extensi´on de sintaxis de JavaScript que nos permite mezclar JS y HTML (XML), de ah´ı su nombre JavaScript XML. B´asicamente nos permite usar c´odigo JS dentro del HTML, y viceversa. Al ser una librer´ıa y no un framework, existe una versatilidad en el uso de React. En el caso de este proyecto, se ha utilizado la herramienta create-app [22]. Esta herramienta permite establecer un proyecto basado en componentes, partiendo del componente padre App, y de un punto de inicio, que es el fichero index.html, que enlaza con dicho componente. 32 CAP´ ITULO 6. TECNOLOG´ IAS UTILIZADAS 6.2.2. Ciclo de vida de un componente en React Como hemos dicho anteriormente, el desarrollo de esta aplicaci´on esta basado en componentes. Hasta la versi´on 16.8 de React, el desarrollo estaba basado en clases (React class component) donde el ciclo de vida ven´ıa marcado por una serie de funciones. Con la llegada de esta versi´on, se incorporaron los hooks de estado, que permit´ıan un desarrollo m´as r´apido de la aplicaci´on, proporcionando m´as versatilidad y reducci´on del c´odigo de la implementaci´on. Para entrar en el mundo de estos hooks y del ciclo de vida, primero debemos presentar lo que es un estado en React. Un estado en React es, entonces, un almac´en de datos mutable, asociado a un componente en concreto. Este estado es inicializado y puede ser modificado, y permite el acceso a sus valores desde ese componente. Adem´as del estado, los componentes tienen unas propiedades. Estas propiedades b´asicamente son una serie de variables o funciones que se reciben cuando se invoca al componente, y pueden ser utilizadas con diversas finalidades. Por ejemplo, un componente que reciba el t´ıtulo para luego que sea mostrado en v´ıa HTML. En este proyecto se ha utilizado los function hooks [58], la alternativa a las clases de componentes. B´asicamente el funcionamiento es el mismo, pero requiere mucho menos c´odigo a la hora de realizar una implementaci´on. En la figura 6.1 podemos ver un diagrama de actividad del ciclo de vida de un componente tradicional de React. (Class component) Cuando es llamado y comienza su ciclo de vida, y recibe las propiedades, ya sean funciones o variables. A continuaci´on comienza el montaje el componente(ComponentWillMount). Este apartado es utilizado para establecer valores iniciales a los estados del componente, y inicializarlos por tanto. Tras este punto se ejecuta el render. El render contiene el c´odigo JSX que se mostrar´a al usuario. Puede tomar valores del punto anterior, por ejemplo, de una carga de la base de datos, para ser mostrados posteriormente estos datos en una lista al usuario. Tras este paso finaliza el montaje del componente, a este estado se le llama componentDidMount.B´asicamente se suele utilizar para recibir datos de las APIs. Solo se ejecuta en el lado del cliente. Una vez finalizada esta carga todo depender´a de los eventos que se produzcan dentro del componente. Hay dos opciones, una actualizaci´on de estado del componente (De un estado de este b´asicamente) o la finalizaci´on del ciclo de vida de este componente(ComponentWillUnmount), siendo destruido. Las actualizaciones se producen por eventos tales como un click sobre un bot´on, que actualiza un estado, entonces se produce la recarga del componente, y se produce una nueva llamada al render. 33 6.2. REACT Figura 6.1: Ciclo de vida, componente React. Obtenida de [38] 34 CAP´ ITULO 6. TECNOLOG´ IAS UTILIZADAS Ciclo de vida en hook functions Una vez explicado el funcionamiento en un componente de clase de React, veamos este nuevo mecanismo de hooks. Un hook permite la creaci´on de un componente dentro de una funci´on. B´asicamente antes deb´ıamos crear una clase y definir una serie de m´etodos para poder acceder a dicha librer´ıa, y poder utilizarla dentro de las funciones. Ahora simplemente podemos definir una funci´on e invocar c´odigo React dentro de ella sin la necesidad de realizar el anterior proceso, que era bastante largo y tedioso. Existen una nueva serie de m´etodos opcionales dentro de una function hook [58]: useState: Permite la inicializaci´on y definici´on de estados. [66] useEffect: [65] Sustituye al viejo ciclo de vida. Ejecuta los tres m´etodos: ComponentWillMount,ComponentDidMount y el ComponentWillUnmount. Basicamente el c´odigo que est´a dentro de este se ejecuta por primera vez haciendo la funci´on de ComponentWillMount, permite establecer observables sobre los estados sustituyendo al ComponentDidMount y a todo el proceso de observaci´on de estados anterior, y se puede establecer un return a esta funci´on para ejecutar la funcionalidad del ComponentWillUnmount Podemos ver el nuevo ciclo de vida en la figura 6.2. Los cambios m´as significativos son que ahora se ejecuta antes el render que el estado de ComponentWillMount, actualizandose por tanto posteriormente el componente con los valores cargados mediante el useEffect, o mediante la inicializaci´on del useState. 6.3. IPFS El Sistema de archivos interplanetario (En ingl´es InterPlanetary File System - IPFS) es una red (Y protocolo) dise˜nado para crear un m´etodo p2p direccionable con el objetivo de almacenar y compartir archivos, basado en un FS (File system `o sistema de ficheros) descentralizado B´asicamente IPFS utiliza el algoritmo SHA-256 [36] para transformar la ruta que indexa el documento. El resultado es un hash que recibe el nombre de content identifier (CID). Este CID es utilizado para obtener posteriormente el documento [37] 6.3.1. IPFS-http-client Es una API en JavaSCript que implementa el core del protocolo IPFS. [42] 35 6.3. IPFS Figura 6.2: Ciclo de vida, hooks. Obtenida de [44] 36 CAP´ ITULO 6. TECNOLOG´ IAS UTILIZADAS 6.4. NPM NPM (Node Package Manager) es el administrador de paquetes predeterminado para el tiempo de ejecuci´on de JavaScript Node.js, que permite a˜nadir y gestionar dependencias, librer´ıas y m´odulos a las aplicaciones que estamos desarrollando. Requiriendo NodeJS, permite desplegar un servidor en local para desarrollar la aplicaci´on, as´ı como una compilaci´on para el despliegue. Entre los paquetes instalados destacan: 6.4.1. @material-ui/core Este plugin contiene una librer´ıa de componentes listos para el uso, como tablas con funcionalidades de paginaci´on, o selectores con b´usqueda incluida. Tambi´en contiene un listado de iconos y otras funcionalidades. [5] 6.4.2. React-bootstrap Este plugin es la implementaci´on de Boostrap para react. Proporciona una gran variedad de clases CSS, que permiten el desarrollo del front-end con facilidad, as´ı como una serie de componentes como botones, inputs de formularios.. [57] 6.4.3. React-router-dom React no tiene un sistema de navegaci´on por defecto al tratarse de una librer´ıa. Por tanto este paquete nos proporciona una serie de componentes de navegaci´on. Es por tanto el paquete encargado de las rutas, y de la navegabilidad entre ellas. [56] 6.4.4. Moment y moment-timezone Paquete para el formateo de fechas, y gesti´on de zonas horarias de la aplicaci´on. [46] 6.5. Solidity y Truffle. Solidity es un lenguaje de alto nivel orientado a smart contracts. Su sintaxis es similar a la de JavaScript, de tipo est´atico y est´a enfocado espec´ıficamente a la M´aquina Virtual de Etehreum (EVM). [62] Truffle es un conjunto de herramientas de programaci´on orientadas a smart contracts (contratos inteligentes) que permiten el desarrollo aplicaciones sobre la blockchain. El objetivo principal de Truffle es proveer un entorno de desarrollo en la blockchain, permitiendo con estas 37 7.2. OFF-CHAIN DATASORE DESCRIPTION Figura 7.3: Comportamiento base para a˜nadir un hash utilizando el patr´on off-chain Figura 7.4: Comportamiento base para obtener un documento utilizando el hash 44 CAP´ ITULO 7. DISE ˜ NO 7.3. Atomic Web Desing El concepto de Atomic Web Design nace de un art´ıculo de Brad Frost [11], en el que explica el dise˜no de una interfaz web descomponiendo en unidades m´as peque˜nas, como ´el denomina ´atomos, y reutilizando estos componentes a trav´es de la composici´on para generar elementos m´as grandes y potentes que compongan todo el dise˜no. [64] Este patr´on por tanto permite la creaci´on de componentes independientes que favorecen la reutilizaci´on, y facilitad el mantenimiento de estos al tratarse como piezas aisladas. Cada uno de estos componentes en este proyecto estar´a en un archivo js. Se combina con el patr´on de React Conditional Rendering, que b´asicamente subdivide a este componente en m´odulos dentro de ese fichero, y son llamados de forma din´amica en el render, en funci´on de las condiciones que se establezcan. 7.3.1. Componentes de este proyecto A continuaci´on se mostrar´a un listado de los componentes desarrollados. App Componente padre del que cuelgan el resto de componentes. Contiene la aplicaci´on entera. Adem´as contiene el Router padre que permite la navegaci´on a lo largo de la web.(Un router en react es un componente que permite el enrutamiento entre enlaces.) PanelAdminTask Contiene el router hijo para el enrutamiento dentro del panel de tareas del admin.Es responsable por tanto de invocar al men´u secundario que permite la navegabilidad entre sus componentes hijos. TaskListaAdmin. Contiene la lista de tareas activas y de entregas. AddTask. Es el componente que permite a un administrador crear tareas. ValidateTask. Es el componente que permite a un administrador, que ha creado una tarea, validar las entregas asociadas a esa tarea. ManageTask Componente para la modificaci´on de las tareas (Grupos asociados ect..) AddProject Componente para a˜nadir tareas ManageProject Componente que contiene la lista de proyectos y que permite la edici´on de estos. PanelAdminGroupAndUser. Contiene el router hijo para el enrutamiento dentro del panel admin de grupos y usuarios. Adem´as invoca a un segundo men´u. RegisterUser Componente que permite registar usuarios en el sistema. ManageUsers Componente que permite gestionar usuarios. 45 7.4. BACKEND AS SERVICE ManageGroup Componente que permite la gesti´on de grupos, y contiene un listado de ellos. AddGroup Componente que permite crear grupos. Profile Componente que muestra el perfil de usuario. MyGroups Componente que muestra los grupos de un usuario. Notificaciones Componente que muestra las notificaciones de usuario. Login Componente que permite el acceso al sistema. HeaderBar Barra principal de navegaci´on superior. SecondaryHeaderBar Barra secundaria invocada por otros componentes como PanelAdminGroup, para garantizar la navegabilidad en sus componentes hijos List Task Contiene la lista de tareas disponibles de un usuario. Task Permite realizar una entrega, validar, y consultar el estado de esta. En la figura 7.5 se puede ver los anteriores componentes citados, as´ı como la relaci´on que existe entre ellos. Existe adem´as un componente denominado PrivateRoute, que ha sido creado para gestionar las rutas en funci´on de si el usuario est´a logueado o no. 7.4. Backend as Service Un BaaS omBaaS oBackend as a Service (Backend como servicio) es una plataforma que facilita el desarrollo del lado del back-end proporcionando al desarrollador una serie de m´etodos para interactuar con los servicios alojados en ´el. [12] Por tanto las responsabilidades de ejecuci´on y mantenimiento de servidores caen a cargo de un tercero, permitiendo al desarrollador centrarse en el desarrollo del front-end, haciendo uso se los servicios proporcionados. Podemos ver una comparativa del esfuerzo de desarrollo del front-end frente al back-end en la figura 7.6 Se ha seleccionado en este proyecto Firebase, debido a la cantidad de servicios que proporciona como por ejemplo una base de datos en tiempo real, o la autentificaci´on y validaci´on de usuarios. De esta manera, descentralizamos del servidor donde est´a alojado el nodo Ethereum, los servicios de base de datos. 46 CAP´ ITULO 7. DISE ˜ NO Figura 7.5: Diagrama de componentes. 47 7.5. DIAGRAMA DE DESPLIEGUE DE LA APLICACI ´ ON Figura 7.6: Representaci´on del esfuerzo del backend frente al front-end. 7.5. Diagrama de despliegue de la aplicaci´on La aplicaci´on web ha sido desplegada sobre un servidor nginx, aunque podr´ıa ser desplegado en un servidor con la tecnolog´ıa Express de NodeJS perfectamente, o los servicios de hosting de Firebase. La tecnolog´ıa de desarrollo de Node, permite realizar un ”build”, es decir una preparaci´on para el despliegue generando los archivos necesarios. Se ha tomado esta decisi´on de centralizar el servidor para facilitar la conexi´on con la red privada Ethereum del nodo de la m´aquina. De esta manera la m´aquina contendr´a el nodo con todas las cuentas Ethereum del sistema, y gestionar´a los servicios de proveedor. Las cuentas tradicionales de usuario de Firebase, estar´an enlazadas por tanto a la direcci´on Ethereum. La firma de cifrado de la cuenta, y de transacciones ser´a compartida. Adem´as el servidor contendr´a el sistema IPFS. De esta manera ser´a privado y solo accesible por el sistema. B´asicamente tendr´ıamos una arquitectura cliente servidor de tres niveles(Ver imagen 7.7, donde el servidor se comunica con los servicios distribuidos de Firebase, y con la blockchain, as´ı como con IPFS. Aunque inicialmente tom´abamos una tecnolog´ıa descentralizada, para lograr la mayor accesibilidad por parte del usuario sin requerir software de terceros, ha sido necesario una mayor centralizaci´on de los servicios para lograr una mayor seguridad. Finalmente podemos ver el diagrama de despliegue de la aplicaci´on en la figura 7.8 48 CAP´ ITULO 7. DISE ˜ NO Figura 7.7: Cliente servidor tres niveles, tomada de [40] 7.6. Dise˜no de la base de datos Como hemos dicho, se ha seleccionado los servicios de Firebase. En el caso del presente proyecto se ha seleccionado Firestore Real Time Database. B´asicamente es una base de datos no relacional. Partiendo del modelo conceptual realizado al comienzo del proyecto (Figura 5.1, se ha necesitado realizar una serie de cambios para adaptarse a una base de datos no relacional, as´ı como se ha decidido realizar m´as cambios. En la clase asociaci´on del rol, pasa como atributo de grupo donde se almacena el nombre del usuario. Entrega pasa a ser una clase, donde la clase ficheros pasa a ser un array como atributo. Esta clase estar´a asociada ´unicamente a la tarea, y tendr´a un atributo que almacene el grupo de la entrega.La asociaci´on de responsable pasa a ser un atributo de tarea, que almacena la persona que la entreg´o. Adem´as debido a los cambios en las historias de usuario, se ha creado una nueva clase notificaciones. Los cambios se ver´an reflejados en la implementaci´on final de la base de datos en la secci´on 8.3 49 7.6. DISE ˜ NO DE LA BASE DE DATOS Figura 7.8: Diagrama de despliegue 50 CAP´ ITULO 8. IMPLEMENTACI ´ ON, DESPLIEGUE Y PRUEBAS Cap´ıtulo 8 Implementaci´on, despliegue y pruebas 8.1. Implementaci´on Ethereum Para la implementaci´on de GoEth es necesario realizar un script para minar solo cuando hay transacciones pendientes. El cliente por defecto mina bloques aunque no haya transacciones, de esta manera solucionamos el problema. var mining_threads = 1 function checkWork() { if (eth.getBlock("pending").transactions.length > 0) { if (eth.mining) return; console.log("== Pending transactions! Mining..."); miner.start(mining_threads); } else { miner.stop(); console.log("== No transactions! Mining stopped."); } } eth.filter("latest", function(err, block) { checkWork(); }); eth.filter("pending", function(err, block) { checkWork(); }); checkWork(); Adem´as es necesario implementar el primer bloque denominado ”g´enesis”. Este bloque 51 8.1. IMPLEMENTACI ´ ON ETHEREUM contiene la configuraci´on de algunas de las reglas de la red Ethereum. Sirve para definir el gas por transacci´on, el id de la red o la dificultad de minado. { "config": { "chainId": 2334156, "homesteadBlock": 0, "eip150Block": 0, "eip150Hash": "0x0000000000000000000000000000000000...0", "eip155Block": 0, "eip158Block": 0, "byzantiumBlock": 0, "constantinopleBlock": 0, "petersburgBlock": 0, "istanbulBlock": 0, "clique": { "period": 16, "epoch": 30000 } }, "nonce": "0x0", "timestamp": "0x602bd66c", "extraData": "0x0020481527dba2d330b6c688d654c50086f917c9fa000...00", "gasLimit": "0x37d7840", "difficulty": "0x1", "mixHash": "0x0000000000000000000000000000000000000000000000000000000000000000", "coinbase": "0x20481527dba2d330b6c688d654c50086f917c9fa", "alloc": { "20481527dba2d330b6c688d654c50086f917c9fa": { "balance": "0xfffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff" } }, "number": "0x0", "gasUsed": "0x0", "parentHash": "0x000000000000000000000000000000000000000000000000000000" } 8.1.1. Smart contract Estructura del contrato inteligente utilizado para mantener el registro de las entregas y los archivos. contract StorageEntrega { string public name = ’StorageEntrega’; 52 CAP´ ITULO 8. IMPLEMENTACI ´ ON, DESPLIEGUE Y PRUEBAS uint public fileCount = 0; //par key value mapping(uint => File) public files; struct File { uint fileId; string fileHash; string entregaHash; address payable uploader; } event FileUploaded( uint fileId, string fileHash, string entregaHash, address payable uploader ); constructor() public { } function uploadFile(string memory _fileHash, string memory _entregaHash) public { require(bytes(_fileHash).length > 0); require(bytes(_fileName).length > 0); require(msg.sender!=address(0)); fileCount ++; files[fileCount] = File(fileCount, _fileHash, _entregaHash, msg.sender); emit FileUploaded(fileCount, _fileHash, _entregaHash, msg.sender); // Emitir } } 8.2. Estructura del c´odigo web A continuaci´on se muestra la estructura final del c´odigo del proyecto: |- .gitignore |- package.json |- package-lock.json |- truffle-config.js |- README.md | 53 8.4. PRUEBAS Test de creaci´on de grupos, proyectos y tareas. En estos test de alto nivel se busca testear la funcionalidad a la hora de la crear grupos, tareas o proyectos. Nºprueba Descripci´on de la prueba Resultado P-06 Prueba de introducci´on de campos vac´ıos en la creaci´on de grupos, proyectos y tareas Correcto P-07 Grupos personalizados en los proyectos Correcto P-08 Grupos personalizados en las tareas Correcto P-09 Fecha correcta en la creaci´on de las tareas Correcto P-10 Test de selecci´on de responsable al crear la tarea Correcto P-11 Imposiblidad de crear una tarea antes de la fecha actual de hoy Correcto Tabla 8.2: Bater´ıa de pruebas de alto nivel creaci´on de grupos, proyectos y tareas. 8.4.3. Test de modificaci´on de grupos, proyectos y tareas Se ha testeado la funcionalidad correspondiente a la modificaci´on de las tareas, grupos y proyectos. Nºprueba Descripci´on de la prueba Resultado P-12 Modificaci´on del responsable de grupo Correcto P-13 Modificaci´on de los grupos de un proyecto Correcto P-14 Modificaci´on de los miembros de un grupo Correcto P-15 Modificaci´on de los datos de una tarea. Correcto P-16 Modificaci´on de los datos de un grupo Correcto P-17 Modificaci´on de los datos de un proyecto. Correcto P-18 Modificaci´on del responsable de un grupo. Correcto P-19 Eliminaci´on de grupo. Error (Solucionado) P-20 Eliminaci´on de proyecto. Correcto Tabla 8.3: Bater´ıa de pruebas de alto nivel creaci´on de grupos, proyectos y tareas. 60 CAP´ ITULO 8. IMPLEMENTACI ´ ON, DESPLIEGUE Y PRUEBAS Validaci´on y visi´on de tareas En esta secci´on se meustra una lista de las pruebas de alto nivel realizadas para la validaci´on y visi´on de las tareas. Nºprueba Descripci´on de la prueba Resultado P-21 Solo responsable del grupo puede entregar Correcto P-22 Solo el responsable puede deshacer la entrega Correcto P-23 El usuario no puede volver a validad la tarea una vez hecho, y es informado de que la ha validado Correcto P-24 Cambio de fase correcto cuando todos validan la entrega Correcto P-24 El responsable no puede deshacer la entrega en fase 2 correcto P-25 El administrador no puede validar hasta estar en fase 3. Correcto P-26 El administrador puede validar correctamente la tarea. Correcto P-27 Solo el responsable puede finalizar la tarea Correcto P-28 Se puede descargar el archivo en todas las fases tras la entrega por parte del Correcto P-29 Tarea visionada como finalizada si la fecha ya se ha superado. Correcto P-30 La tarea sigue activa para el ´ultimo d´ıa de posibilidad de entrega. Correcto Tabla 8.4: Bater´ıa de pruebas validaci´on de tareas Bater´ıa de pruebas IPFS Debido a que los asserts no funcionaban con la librer´ıa de IPFS, se ha comprobado manualmente la coincidencia del hash en IPFS y en el smart contract NºArchivo Hash Coincide P-32 prueba.pdf QmdqHisEV24zkNDsBBg2BvvUt4td79FwH9t1hBFNzSt6ia S´ı P-33 prueba.zip QmVqNB8uazk9Fw8z6F3lrjNpDsTnrUT3V3R1jmDzh5a9oA S´ı P-34 prueba.py QmXhi1p5jfx8RhHpXbyPEZNkmaUoybG94byr6L9scqK5xv S´ı Tabla 8.5: Bater´ıa de pruebas de alto nivel navegaci´on 61 8.5. DESPLIEGUE DE LA APLICACI ´ ON. 8.5. Despliegue de la aplicaci´on. En esta secci´on se desarrollar´a el proceso de despliegue de la aplicaci´on. 8.5.1. Entorno de despliegue. Se recomienda el despliegue de esta aplicaci´on en redes privadas de internet, de hecho est´a pesando para ello, limitando su acceso al exterior para garantizar una mayor seguridad. En caso de realizar un despliegue de cara a la red p´ublica, es necesario implementar el protocolo SSL sobre http, es decir, https. En el presente documento se realizar´a de cara a la red p´ublica, pues el objetivo es que sea utilizado por los alumnos de la universidad, sin tener que acceder v´ıa VPN. 8.5.2. Herramientas requeridas Las herramientas requeridas para el despliegue son: Node JS versi´on +14 [49] Npm versi´on 7+ [50] IPFS CLI [20] GoETH [33] 8.5.3. Proceso de preparaci´on Tras la instalaci´on de las herramientas anteriores es necesario obtener el c´odigo fuente del proyecto que est´a en la siguiente url https://github.com/oxsaulxo/TFGBlockchain. Una vez obtenido el c´odigo fuente es momento de instalar las dependencias del proyecto, para ello ejecutamos npm install Instalamos la herramienta Truffle con npm, para ello ejecutamos npm install -g truffle –save Una vez instaladas las dependencias crearemos un proyecto en firebase. https:// firebase.google.com/?hl=es Inicializamos el daemon IPFS mediante en comando ipfs init. Se crear´a por defecto en el espacio de usuario una carpeta. 62 CAP´ ITULO 8. IMPLEMENTACI ´ ON, DESPLIEGUE Y PRUEBAS A continuaci´on necesitamos una serie de ficheros para el cliente geth. Los obtenemos desde la siguiente url. https://drive.google.com/drive/folders/1AOchyg09b2LjvQksCNg4oqplBS1BgXsS? usp=sharing Estos archivos ser´an guardados en un directorio fuera del directorio del c´odigo fuente del proyecto. En este directorio estar´a todo lo relacionado a Ethereum. Por ejemplo puede recibir este nombre ese directorio. 8.5.4. Proceso de configuraci´on Debido a que el plan es gratuito de firebase, no podemos exportar ni importar datos, por tanto habr´a que realizar una serie de configuraciones a mano. El primer paso ser´a coger los datos de la API que nos ha proporcionado al crear el proyecto dentro de firebase. Configuraremos los archivos fireconfig.js y fireRespaldo.js con estos datos que est´an situados en la ruta del proyecto /src/Servicios/Firebase/. Como hemos dicho, no se puede importar manualmente, y por tanto no contamos con la configuraci´on inicial de administrador. Por tanto, nos dirigimos al panel de firebase desde la web, y en authentificaci´on creamos una cuenta en el Authentication (”Nueva cuenta”, recordad este email y contrase˜na). Una vez creada, nos dirigimos a firestore, y creamos manualmente la colecci´on ¨ Usuarios”. En esta colecci´on, insertamos un nuevo documento con ID de documento autom´atico y los siguientes campos de la tabla 8.5.4 Campo valor tipo Email El introducido anteriormente al crear la cuenta String Admin true Boolean Nombre Admin por ejemplo String Grupos vac´ıo Array Uid Lo obtenemos en el panel de autentificaci´on, del usuario creado String EthereumAccount vac´ıo String Tabla 8.6: Configuraci´on inicial A continuaci´on nos dirigimos al directorio que creamos con nombre “Ethereum”, y creamos un directorio denominado nodos dentro de ´el. Creamos entonces una cuenta para un minero, ejecutamos por tanto: geth –datadir ./nodos account new Yintroducimos la contrase˜na utilizada al crear la cuenta de Firebase anterior, y nos quedamos con la direcci´on publica que nos indica. (Cuidado porque la puede indicar con todo en may´usculas.. Podemos dirigirnos a dentro del directorio nodos, y en keystore obtenerla del nombre, o compararla para estar seguro) A continuaci´on nos vamos al fichero genesis.json, y editamos en el campo alloc la direcci´on que hay por la obtenido anteriormente (La actual es 0x20481527dba2d330b6c688d654c50086f917c9fa). 63 8.5. DESPLIEGUE DE LA APLICACI ´ ON. En este fichero adem´as se puede configurar el id de la red. Nos dirigimos de nuevo a la colecci´on Usuarios, y modificamos en campo EthereumAccount que estaba vac´ıo introduciendo esta nueva direcci´on sin el 0x previo, por ejemplo ’20481527dba2d330b6c688d654c50086f917c9fa’. Inicializamos la blockchain con este primer bloque (G´enesis.) Para ello ejecutamos el siguiente comando geth –datadir ./nodos init ./genesis.json Ejecutamos la blockchain para ver los cambios (Introducir en network id el valor correspondiente si se ha variado la id de esta, cuidado con las comillas). par´ametro console para lanzarlo en modo consola y poder ejecutar comandos: geth --datadir ./nodos --networkid "2334156" --http --http.api "eth,net,web3,personal,miner,admin" console Consultamos que cuenta est´a situada como base (Es decir la que recibe el dinero al minar) Para ello ejecutamos web3.eth.getCoinbase() . En caso de no estar configurado, utilizamos miner.setEtherbase(address) donde address es la direcci´on p´ublica que hemos obtenido del minero. Una vez configurado cerraremos el cliente geth. Una vez configurado esto, iniciamos por primera vez IPFS, ejecutamos ipfs daemon, y paramos ipfs. Ejecutamos por tanto el siguiente comando para activar el cors: (cuidado con las comillas) ipfs config --json API.HTTPHeaders.Access-Control-Allow-Origin ‘["*"]’ Configuraci´on de ficheros Primariamente hay que configurar el puerto donde se desplegar´a la red. En el archivo truffle-config.js de la ra´ız del proyecto configuramos los siguientes par´ametros: Puerto: pondremos el puerto interno donde estar´a desplegado la red Ethereum Cambiar el id network si es necesario Mantenemos localhost, pues la red ser´a privada. Configuraci´on de ficheros de conexi´on: /src/Servicios/IPFS/ipfs.js Configurar con la direcci´on p´ublica ip, y el puerto p´ublico para la API. (Posteriormente habr´a que mapear el puerto p´ublico al privado interno, se ver´a m´as adelante.) Si se quiere desplegar en local se utilizar´a http://127.0.0.1:port donde port ser´a el puerto privado interno. (No ser´a necesario el mapeo). En caso de la red privada http://ipprivada: port /src/Servicios/IPFS/ipfsConnection.js Configurar con la direcci´on p´ublica ip, y el puerto p´ublico para el Gateway.(Posteriormente habr´a que mapear el puerto p´ublico al privado interno, se ver´a m´as adelante.) Si se quiere desplegar en local se utilizar´a http://127.0.0.1:port donde port ser´a el puerto privado interno. (No ser´a necesario el mapeo) En caso de la red privada http://ipprivada: port 64 CAP´ ITULO 8. IMPLEMENTACI ´ ON, DESPLIEGUE Y PRUEBAS /src/Servicios/Web3/web3.js Configurar con la direcci´on p´ublica ip, y el puerto p´ublico para la api de web3js.(Posteriormente habr´a que mapear el puerto p´ublico al privado interno, se ver´a m´as adelante.) Si se quiere desplegar en local se utilizar´a http://127.0.0.1:port donde port ser´a el puerto privado interno. (No ser´a necesario el mapeo) . En caso de la red privada http://ipprivada: port Configuraci´on de IPFS. Nos dirigimos a la carpeta donde est´a IPFS (Por defecto en el espacio de usuario, es una carpeta oculta) All´ı habr´a un archivo denominado config donde configuraremos el gatway y la API: (En el objeto adresses) gateway: /ip4/0.0.0.0/tcp/puerto donde puerto es el puerto interior del sistema. API: /ip4/0.0.0.0/tcp/puerto donde puerto es el puerto interior del sistema. Es necesario por tanto mapear todo puerto publico con el privado En el caso de red privada o local configurar la ip 0.0.0.0 con la ip correspondiente. Compilaci´on de contratos Para compilar los contratos es necesario tener desplegada la red, por tanto la lanzamos con el comando que proporcionamos antes: Lanzamos la red Ethereum con la opci´on vista m´as atr´as. Desbloqueamos la cuenta del minero con web3.personal.unlockAccount(’address’,”password”,0) Mandamos al minero minar con miner.start(1) Compilamos con truffle migration –reset Paramos el minero con miner.stop() 8.5.5. Despliegue en servidor En este caso se utiliza un servidor nginx. Se instala por tanto este tipo de servidor. ( sudo apt-get install nginx) En /etc/nginx/sites-available creamos un fichero de configuraci´on: app.conf con el siguiente contenido server { listen 80; server_name localhost; root /var/www/proyecto/build; index index.html; 65 8.5. DESPLIEGUE DE LA APLICACI ´ ON. location / { add_header ’Access-Control-Allow-Origin’ * always; add_header Access-Control-Allow-Origin *; add_header Access-Control-Expose-Headers Content-Length; add_header Access-Control-Allow-Headers Range; try_files \$uri /index.html =404; } } En listen ponemos el puerto privado interno donde est´a escuchando nginx. (Hay que mapear este puerto a una ip p´ublica) En root indicamos la ruta donde est´a el build del proyecto. La configuraci´on de location permite funcionar el CORS. Eliminamos el enlace simb´olico que hay en /etc/nginx/sites-enables/default, y creamos un enlace simb´olico apuntando al fichero /etc/nginx/sites-available/app.conf desde /etc/nginx/sites-enables Se genera el build del proyecto con npm run build. Los resultados deben estar en /var/www/proyecto/build 8.5.6. Lanzamiento Una vez todo preparado hay que lanzar el daemon de IPFS en segundo plano, ejecutamos: ipfs daemon Tras esto lanzamos el cliente geth en segundo plano con el siguiente comando (Establecemos el puerto pertinente, -http addr 0.0.0.0 si se va a comunicar con el exterior.) El script detecta si existen transacciones y la mina en caso correcto. geth --datadir ./nodos --networkid 2334156 --identity "testNet" --preload "./mineWhenNeed.js" --rpc.gascap ’0’ --rpc.txfeecap ’0’ --http --http.vhosts "*" --http.port "4003" --http.corsdomain "*" --http.addr 0.0.0.0 --http.api "eth,net,web3,personal,miner,admin" --allow-insecure-unlock console A continuaci´on desbloqueamos el minero desde la consola de Geth: web3.personal.unlockAccount(.adress”,”password”,0) Y le mandamos minar con el siguiente comando. miner.start(1) Activar el servidor nginx. 66 CAP´ ITULO 8. IMPLEMENTACI ´ ON, DESPLIEGUE Y PRUEBAS 8.5.7. Lanzamiento en local Como hemos dicho, para lanzarlo en local se debe configurar con la ip de localhost oloopback, as´ı como puertos internos. Puede ser lanzado mediante npm como npm run start, con el daemon IPFS y geth lanzados. 8.6. Decisiones tomadas a lo largo del proyecto Se han tomado la siguientes decisiones a lo largo del proyecto para cumplir con los objetivos. Para cumplir con el objetivo de establecer una mayor facilidad en la accesibilidad de la aplicaci´on se ha decidido mantener todos las cuentas en un nodo. Si no cada usuario tendr´ıa que desplegar un nodo y configurarlo, utilizar alg´un proveedor como Metamask. Los usuarios ser´ıan responsables de la gesti´on de los nodos adem´as, y de del mal uso de estas. Exist´ıa adem´as otro problema relacionado a esto, y es que solo se permiten 25 conexiones remotas activas simultaneas si se hubiese utilizado ese modelo , lo que limitar´ıa el acceso a la aplicaci´on en caso de tener un n´umero activos de usuarios. Se ha decidido utilizar Firebase para agilizar el proceso de desarrollo del back-end. Exist´ıa una tecnolog´ıa de pago como era Spanner que proporcionaba una base de datos descentralizada. El hecho de centralizar ya el nodo de Ethereum en un servidor, ya romp´ıa con la idea de la descentralizaci´on, por tanto, para facilitar el desarrollo del back-end y la gesti´on de usuarios se utiliz´o Firebase. La selecci´on de Ethereum, frente a otras redes se basaba en la facilidad que otorgaba Ethereum para el desarrollo de aplicaciones IPFS era la ´unica alternativa, y la m´as utilizada por la mayor´ıa de las DApps. Swarm es una red P2P, y permit´ıa el acceso de terceros a estos documentos. 8.7. Licencia El software ser´a propiedad de mis tutores, Joaqu´ın Adiego, y Natalia Mart´ın. Queda por tanto en sus manos la responsabilidad del desarrollo, mantenimiento, distribuci´on y uso de la aplicaci´on. 67 8.7. LICENCIA 68 CAP´ ITULO 9. SEGUIMIENTO DEL PROYECTO Cap´ıtulo 9 Seguimiento del proyecto En el presente cap´ıtulo se abordar´an los sprints realizados a lo largo del proyecto. Cada historia de usuario del Backlog es transformada como un conjunto de subtareas que son realizadas en uno o en varios sprints con el objetivo de lograr dicha funcionalidad. A continuaci´on en las diferentes secciones recogeremos los diversos sprints, donde en una tabla estar´an las diversas tareas realizadas correspondientes a una o varias historias de usuarios. Se utilizar´a la siguiente nomenclatura: HU (Historia de usuario): Nºde la historia de usuario a la que est´a asociada una tarea. Si esa tarea no tiene que ver con una historia de usuario, es decir, no genera valor en el proyecto si no el equipo (Chore) se representar´a con ‘ - ’ (Ya sea documentaci´on, formaci´on..). En muchos de los casos para no alargar las tablas se definir´a ´unicamente la tarea, y no las subtareas que estaban a cargo, y si involucran a varias historias de usuario se indicar´a. TE (Tiempo empleado): Tiempo empleado medido en horas ininterrumpidas de trabajo Resultado: Indica el estado final de la tarea. Cabe decir que inicialmente se estimaba realizar unas 33-34h por sprint. En ciertos puntos se han necesitado m´as horas para cumplir las tareas, incluso incumpliendo alguna y posponi´endola al siguiente sprint por una mala planificaci´on Recordemos que estamos empleando una estimaci´on de p´oker para los story points donde respectivamente de 1 al 9, las horas que corresponden son: 1,2,3,5,8,13,21,34,55. 9.1. Sprint 0 Se ha realizado un sprint 0 con el objetivo de realizar un estudio previo de las tecnolog´ıas correspondientes a la blockchain. De esta manera se puede esclarecer la serie de dudas que hab´ıa al respecto sobre esta tecnolog´ıa, de manera que se puede seleccionar una tecnolog´ıa en concreto. Por tanto obtenemos una arquitectura l´ogica inicial de la aplicaci´on. (Ver tabla 9.1) Este sprint adem´as ha servido como redacci´on del cap´ıtulo 2 de la documentaci´on. 69 9.7. SPRINT 6 tanto la fecha l´ımite del proyecto ser´ıa de cara a la convocatoria extraordinaria. El objetivo de este sprint es implementar el sistema de entregas. Para ello implementaremos el sistema IPFS, as´ı como los contractos inteligentes. Tambi´en se desplegar´a las herramientas para desarrollar los contratos inteligentes, as´ı como la l´ogica de back end de las tareas. Se realizar´a tambi´en un script para controlar el minado. Formaci´on IPFS, 4 puntos (5h) A˜nadir archivos a IPFS, 5 puntos (8h) Descargar archivos de IPFS, 5 puntos (8h) Desarrrollo de smart contracts, 4 puntos (5h) Despliegue de smart contracts y herramientas, 1 punto (1h) Script de minado, 2 puntos (2h) Ejecuci´on de smart contracts y obtener datos de los bloques, 3 puntos (3h) Sprint Review: (Ver tabla 9.7) Se ha realizado una formaci´on en IPFS. Posteriormente se ha realizado la funcionalidad para almacenar ficheros en este sistema, as´ı como para descargarlos. En el caso de esto segundo, ha sido un poco complejo porque es almacenado con el nombre del hash que genera. Por tanto ha habido que almacenar el nombre del fichero, e utilizar una librer´ıa auxiliar para permitir la descarga correcta del documento. Adem´as se ha realizado el contrato y desplegado el contrato para la inserci´on de las tareas en la bockchain. Por tanto tambi´en se ha realizado la l´ogica de back-end para las entregas. Algunas tareas han quedado incompleta. Sprint planning: En la pr´oximo sprint se finalizar´an las tareas que han quedado incompletas relacionadas con almacenar la entrega en la blockchain, as´ı como se realizar´a el sistema de validaci´on. HU Tarea TE Descripci´on Resultado - T-49 5h Formaci´on IPFS API Completado - T-50 1h Configuraci´on IPFS y herramientas de smart contracts Completado HU-4 T-51 6h Desarrollo de smart contracts, y migrations Completado HU-4 T-52 2h Test truffle smart contract Completado HU-4,15 T-53 1,5h Funcionalidad de almacenar el archivo a IFPS Completado HU-4,15 T-54 19h Funcionalidad descarga del fichero subido a IPFS. Completado HU-4 T-55 7h Pruebas y solucci´on a errores IPFS Completado HU-4 T-56 - Script minado cuando No iniciado HU-4 T-57 - Subir el archivo a la blockchain No iniciado Total 41,5h Tabla 9.7: Sprint 6 76 CAP´ ITULO 9. SEGUIMIENTO DEL PROYECTO 9.8. Sprint 7 En este sprint por tanto se realizar´an las tareas relacionadas con la implementaci´on del sistema de fases descrito en la secci´on 5.3. B´asicamente primero implementaremos la funcionalidad para insertar el hash del documento de IPFS en la blockchain junto con los dem´as datos de la entrega, y tambi´en implementaremos los m´etodos para leer este hash de la blockchain y para obtener el documento. Adem´as se realizar´a un script para controlar el minado para cuando solo existan transacciones. Utilizaremos posteriormente esta funcionalidad en el sistema de validaci´on que hemos citado anteriormente por fases. Se implementar´a por tanto la funcionalidad requerida para que los miembros validen la tarea. Adem´as se ha decidido tambi´en posteriormente realizar una serie de cambios visuales. Ejecutar transacciones y leer bloques de la blockchain, 3 puntos (3h) Script de minado, 3 puntos (3h) Sistema de validaci´on, 7 puntos (20h) Eliminar entrega, puntos 2 (2h) Cambios visuales, puntos 4 (5h) Sprint Review: (Ver tabla 9.8) Se han completado todas las tareas dentro del tiempo establecido al comienzo del proyecto, que deber´ıa emplearse para realizar un sprint. Por tanto se ha implementado toda la funcionalidad requerida para validar las tareas, y almacenarlas en la blockchain. Sprint planning: El Scrum Master ha propuesto realizar una nueva serie de nuevas funcionalidades: Notificaciones para el proceso de validaci´on y la entrega m´ultiple. Por tanto 9.9. Sprint 8 Se han a˜nadido dos nuevas historias de usuario: Entrega m´ultiple (22) y notificaciones de usuario (23). Se realizar´an las tareas acordes a esta funcionalidad, as´ı como tareas acordes a la gesti´on del balance de las cuentas de Ethereum. Por ´ultimo se realizar´an tareas relacionadas con la documentaci´on Entrega m´ultiple 6 puntos (13h) Maquetaci´on y funcionalidad de notificaciones 6 puntos (13h) Gesti´on de balances de cuentas 2 puntos (2h) Documentaci´on dise˜no, implementaci´on y revisiones. 5 puntos (8h) Sprint Review: (Ver tabla 9.9) Se han encontrado impedimientos en la funcionalidad correspondiente a la entrega m´ultiple debido a las restricciones que impone la API Web3JS,la blockchain y el sistema IPFS. Por lo dem´as la funcionalidad correspondiente a las notificaciones fue realizada correctamente y sin problemas y en un tiempo bastante corto y menor de lo previsto. Se realizaron tareas de documentaci´on Sprint planning: Se ha descartado la funcionalidad de la entrega m´ultipe para el siguiente sprint.Por tanto se realizar´an tareas correspondientes a la documentaci´on, y soluci´on a posibles errores, y mejoras visuales. 77 9.10. SPRINT 9 HU Tarea TE Descripci´on Resultado HU-4 T-58 1h Script minado Completado HU-4, T-59 5h Almacenar el hash del documento y la entrega en la blockchain. Lectura del bloque de la blockchain, para obtener el hash del documento de la entrega Completado HU-4 T-59 1h Soluci´on a problemas de gas de la red. Reconfiguraci´on de la red. Completado HU-4,15,5 T-60 18h Implementaci´on completo del sistema de validaci´on por fases. Completado HU-4,5 T-61 3h Pruebas fases de validaci´on Completado HU-4 T-62 1h Eliminar entrega Completado HU-19,20,2,6 T-63 1h Modificaci´on del componente lista, por componente de lista UI material. Completado HU-2 T-64 1h Maquetaci´on y l´ogica de lista de tareas finalizadas Completado HU-7,4 T-65 2h Cambios en el front-end, componente barra de carga as´ıncrona Completado - T-66 1h Cambios visuales en los colores de la aplicaci´on Completado Total 34h Tabla 9.8: Sprint 7 9.10. Sprint 9 Este es el ´ultimo sprint, donde se desarrollar´an tareas de documentaci´on, y peque˜nos cambios en la aplicaci´on Despliegue de la aplicaci´on: 5 puntos (8h) Cambios visuales de la aplicaci´on: 2 puntos (2h) Test y correci´on de bugs: 1 punto (1h) Documentaci´on despliegue: 3 puntos (3h) Documentaci´on sprints: 3 puntos (3h) Documentaci´on an´alisis final de costes: 1 punto (1h) Modificaci´on y documentaci´on conclusiones, resumen y abstract: 1 punto (1h) Documentaci´on, manual de usuario: 3 puntos (3h) Documentaci´on pruebas: 2 puntos (2h) Revisi´on final de la memoria: 5 puntos (8h) Sprint Review: (Ver tabla 9.10) Se da por concluido el proyecto en este sprint con el despliegue de la aplicaci´on y una serie de cambios visuales. Por lo dem´as se ha producido una redacci´on de la memoria de aquellos puntos que quedaban por realizar. Se han solucionado algunos bugs a la hora 78 CAP´ ITULO 9. SEGUIMIENTO DEL PROYECTO HU Tarea TE Descripci´on Resultado HU-22 T-67 20h Entrega m´ultiple Descartada HU HU-23 T-68 3h Maquetaci´on y funcionalidad de notificaciones Completada HU-7 T-69 1h Balance de cuentas ilimitado Completada HU-23 T-70 1h Pruebas notificaciones Completada - T-71 4h Documentaci´on dise˜no Completada - T-72 1,5h Documentaci´on implementaci´on Completada - T-73 1,5h Cambios documentaci´on tecnolog´ıas utilizadas Completada - T-74 1,5h Cambios documentaci´on scrum Completada Total 33,5h Tabla 9.9: Sprint 8 de eliminar un grupo que hab´ıa problemas con la recursividad de la eliminaci´on, as´ı como hab´ıa un problema con el n´umero de los validadores de un grupo por tomar mal el nombre de la variable. En cuanto al despliegue, nunca hab´ıa realizado uno real, por tanto tuve que investigar para realizar todo correctamente. Se ha utilizado un servidor nginx sobre las m´aquinas virtuales de la uva. HU Tarea TE Descripci´on Resultado - T-75 4h Despliegue en la m´aquina virtual Completado HU-4,5 T-76 1 Cambios visuales en la aplicaci´on Completado HU-4 T-77 1h Soluci´on bug validadores Completado HU-13 T-78 1h Soluci´on bug eliminar grupo Completado - T-79 2,5h Documentaci´on despliegue Completado - T-80 0,5h Documentaci´on an´alisis final de costes Completado - T-81 0,5h Documentaci´on decisiones en el proyecto Completado - T-82 0,5h Documentaci´on resumen y abstract Completado - T-83 0,5h Documentaci´on conclusiones Completado - T-84 3h Pruebas finales Completado - T-85 2h Documentaci´on pruebas Completado - T-86 2h Documentaci´on manual de usuario Completado - T-87 2h Documentaci´on sprint 6,7,8 y 9 Completado - T-88 3h Revisi´on final de la memoria y peque˜nos cambios Completado - T-87 0,25h Reajuste sesi´on de usuario Completado Total 24,75 Tabla 9.10: Sprint 9 79 9.10. SPRINT 9 80 CAP´ ITULO 10. CONCLUSIONES Y TRABAJO FUTURO Cap´ıtulo 10 Conclusiones y trabajo futuro 10.1. Conclusiones finales sobre el proyecto Cuando se comenz´o este proyecto exist´ıan una serie de objetivos t´ecnicos y personales. El resultado ha sido satisfactorio en cuanto a ellos. En cuanto a los objetivos t´ecnicos de la aplicaci´on de la secci´on 1.2.1: Se ha realizado un estudio para determinar las tecnolog´ıas, siendo este satisfactorio, y con buen resultado para el desarrollo del proyecto. Se ha podido aplicar una arquitectura basada en blockchain por tanto a la hora de realizar el proyecto. Se ha realizado un sistema de validaci´on basado en fases con el objetivo de dar soporte a las necesidades. Se ha desarrollado la aplicaci´on sin requerir de la instalaci´on de un software de terceros. En cuanto a los objetivos personales referentes a la secci´on 1.2.2: Se han adquirido conocimientos en desarrollo de front-end en un nuevo framework (Aunque React se define como una librer´ıa). Ten´ıa conocimiento en tecnolog´ıas m´as viejas, y de esta manera se han actualizado mis conocimientos de cara al mercado laboral Se han adquirido conocimientos acerca de una tecnolog´ıa que en el futuro podr´ıa ganar mucha fuerza como es la blockchain de cara al registro de transacciones. He ampliado mis conocimientos acerca de la planificaci´on de proyectos gracias a estas dos v´ıas. Tanto en las pr´acticas como en este proyecto, se han aplicado la metodolog´ıa Scrum. Finalmente se han cumplido tambi´en los objetivos de ganar autonom´ıa en el trabajo, frente a posibles problemas donde no abundasen soluciones, as´ı como se ha conseguido realizar un despliegue real como adquirir conocimientos en un lenguaje nuevo como Solidity. 81 10.2. FUNCIONALIDAD FUTURA DE LA APLICACI ´ ON 10.2. Funcionalidad futura de la aplicaci´on En un futuro la aplicaci´on pudiera requerir de mejoras: Migraci´on a una base descentralizada e implementaci´on de los servicios de backend. Mejoras visuales en los formularios de la p´agina web. Permitir el env´ıo de notificaciones de los administradores hacia los usuarios. Generaci´on de notificaciones v´ıa email tambi´en. 82 AP´ ENDICE A. MANUAL DE USUARIO Ap´endice A Manual de usuario En este ap´endice se describir´a el proceso de creaci´on de grupos, proyectos, y tareas desde el punto de vista del administrador, hasta llegar a la validaci´on de tareas correspondiente a la funcionalidad del usuario com´un. A.5 De esta manera servir´a como manual de usuario para ambas partes este proceso de descripci´on de la funcionalidad web. Antes de nada vamos a explicar la funcionalidad de la barra superior del apartado del administrador. Esta barra la podemos ver por ejemplo en la figura A.3. B´asicamente un usuario com´un tiene los apartados de tareas (Donde est´a la lista de tareas y la entrega y la validaci´on) y mi grupo (Donde hay informaci´on relacionada con el usuario.), as´ı como un apartado del manual de usuario de la p´agina, el icono para ir a sus notificaciones y logout. A mayores por tanto un administrador tiene: Panel de tareas: Donde tiene la funcionalidad para crear y modificar tareas, as´ı como para crear y modificar proyectos. Panel de grupo: Donde tiene la funcionalidad para crear grupos y registrar usuarios. Figura A.1: Barra administrador Figura A.2: Barra usuario 83 A.1. CREACI ´ ON DE USUARIOS A.1. Creaci´on de usuarios Las personas que tiene rol de administrador son los ´unicos que pueden registar usuarios en la aplicaci´on. Hay que tener en cuenta que este proceso de creaci´on tardar´a un poco pues hay que crear su cuenta ethereum. Por tanto, esta contrase˜na que se proporcione servir´a de cifrado de la cuenta y no es modificable. Podemos ver este proceso con la retroalimentaci´on en las figuras A.3 y A.4 Figura A.3: Creaci´on de cuentas Figura A.4: Creaci´on de cuentas 84 AP´ ENDICE A. MANUAL DE USUARIO A.2. Creaci´on de grupos La creaci´on de grupos es parte de la funcionalidad tambi´en del administrador. B´asicamente el administrador selecciona en el buscador/selector a lo usuarios que quiera a˜nadir, y posteriormente selecciona un responsable para el grupo, que ser´a la persona que realizar´a las entregas, y las finalizar´a. Podemos ver el proceso en las figuras A.5 y A.6 Figura A.5: Creaci´on de grupos Figura A.6: Creaci´on de grupos 85 A.5. VALIDACI ´ ON DE TAREAS Figura A.16: Validaci´on creador de la tarea Figura A.17: Validaci´on creador de la tarea 92 AP´ ENDICE A. MANUAL DE USUARIO A.5.4. Finalizar tarea Una vez producido la validaci´on por parte del administrador, se produce la finalizaci´on de la entrega. Este proceso tarda bastante, pues se env´ıa una transacci´on a la blockchain para que sea minada. Podemos ver este proceso en las figuras A.18 y A.19 Figura A.18: Finalizar tarea Figura A.19: Finalizar tarea 93 A.6. EDICI ´ ON GRUPOS, TAREAS Y PROYECTOS A.6. Edici´on grupos, tareas y proyectos El administrador puede modificar los grupos, proyectos y tareas existente. En las diversas subsecciones veremos como. A.6.1. Edici´on de proyectos En la figura A.20 podemos ver la lista de proyectos existente, as´ı como el n´umero de grupos que tiene asociados. Podemos editar este proyecto, y como vemos en la figura A.20 se pueden a˜nadir y quitar grupos, as´ı como actualizar el nombre del proyecto o eliminar este proyecto. Figura A.20: Edici´on de proyectos Figura A.21: Edici´on de proyectos 94 AP´ ENDICE A. MANUAL DE USUARIO A.6.2. Edici´on de grupos El administrador por tanto tambi´en puede modificar los grupos listados en la figura A.22. Como podemos ver en la figura A.23 se pueden quitar y a˜nadir personas al grupo. Adem´as se puede cambiar el responsable del grupo. Como solo hay un responsable de grupo, la otra persona perder´a dicho rol, es decir, se produce una transferencia de los poderes. Figura A.22: Edici´on de grupos Figura A.23: Edici´on de grupos 95 A.7. MIS NOTIFICACIONES A.6.3. Edici´on de tareas El administrador puede editar tambi´en las tareas existentes. Puede cambiar los datos de la tarea, o a˜nadir nuevos grupos que pertenezcan al proyecto al que est´a asignado en esa tarea. Podemos ver esto en m´as detalle en la figura A.24 Figura A.24: Edici´on de tareas A.7. Mis notificaciones Todos los usuarios cuentan con notificaciones que son generadas cuando se producen eventos como la entrega de la tarea por parte del responsable del grupo o de la tarea. Figura A.25: Mis notificaciones 96 AP´ ENDICE B. RESUMEN DE ENLACES ADICIONALES Ap´endice B Resumen de enlaces adicionales Enlaces adicionales de este Trabajo de Fin de Grado: Repositorio con el c´odigo fuente https://github.com/oxsaulxo/TFGBlockchain Recursos adicionales de configuraci´on y scripts: https://drive.google.com/drive/folders/ 1AOchyg09b2LjvQksCNg4oqplBS1BgXsS 97 98 BIBLIOGRAF´ IA Bibliograf´ıa [1] ¿C´omo se crea un bloque? es. Feb. de 2020. url:https://academy.bit2me.com/ mineria-bitcoin-como-se-crea-un-bloque/ (visitado 07-02-2021). [2] ¿Qu´e es la dificultad de miner´ıa en Bitcoin? es. Dic. de 2019. url:https://academy. bit2me.com/que-es-dificultad-mineria-bitcoin/ (visitado 07-02-2021). [3] ¿Qu´e es npm? es. Ene. de 2021. url:https://www.freecodecamp.org/espanol/ news/node-js-npm-tutorial/ (visitado 10-07-2021). [4] ¿Qu´e es Scrum? en. url:https://www.scrum.org/resources/blog/que-es-scrum (visitado 05-02-2021). [5] @material-ui/core. en. url:https://www.npmjs.com/package/@material-ui/core (visitado 10-07-2021). [6] 5 Git Workflows & Branching Strategy to deliver better code. en. Mayo de 2020. url: https://zepel.io/blog/5-git-workflows-to-improve-development/ (visitado 23-02-2021). [7] Bit2Me Academy. ¿Qu´e es la recompensa de bloque? es. Jun. de 2019. url:https: //academy.bit2me.com/que-es-recompensa-de-bloque/ (visitado 10-02-2021). [8] Aplicaciones descentralizadas (dapps). es. url:https : / / ethereum . org (visitado 11-02-2021). [9] Ataque del 51 %. en. Jul. de 2018. url:https://komodoplatform.com/en/blog/51attack-how-komodo-can-help-prevent-one/ (visitado 11-02-2021). [10] Atlassian. Jira — Software de seguimiento de proyectos e incidencias. es. url:https: //www.atlassian.com/es/software/jira (visitado 11-07-2021). [11] Atomic Design. en. Jun. de 2013. url:https://bradfrost.com/blog/post/atomicweb-design/ (visitado 11-07-2021). [12] Backend como servicio: ¿Qu´e es un BaaS? es-ES. Ene. de 2021. url:https : / / blog.back4app.com/ es /que - es - unbaasbackend - como - servicio/ (visitado 25-05-2021). [13] Vlad Balin. React MVX. Nov. de 2020. url:https://github.com/gaperton/ReactMVx (visitado 25-05-2021). [14] Blockchain Networks for DApps. Dic. de 2020. url:https://blaize.tech/services/ how-to-choose-the-right-blockchain-network-for-your-dapp-development/ (visitado 13-02-2021). 99 BIBLIOGRAF´ IA [15] Blockchain: Desarrollando Smart Contracts para Ethereum con Truffle. es. Mayo de 2019. url:https://www.returngis.net/2019/05/desarrollando-smart-contractspara-ethereum-con-truffle/ (visitado 10-07-2021). [16] BOE.es - BOE-A-2021-2292 Resoluci´on de 4 de febrero de 2021, de la Direcci´on General de Trabajo.url:https://www.boe.es/eli/es/res/2021/02/04/(3) (visitado 07-07-2021). [17] Centralizado, Descentralizado y Distribuido: Diferencias. es. url:https://latinotoken. com / conceptos - basicos - 101 - centralizado - descentralizado - distribuido - p2p-cuales-las-diferencias/ (visitado 11-02-2021). [18] Centralized vs Decentralized: Core Differences? en-US. Ago. de 2018. url:https : //101blockchains.com/centralizedvsdecentralizedinternetnetworks/ (visitado 11-02-2021). [19] Alistair Cockburn. Agile Software Development. Highsmith Series, 2002. url:https: //archive.org/details/agilesoftwaredev0000cock (visitado 05-02-2021). [20] Command-line. en-US. url:https://docs.ipfs.io/install/command-line/ (visitado 12-07-2021). [21] Luke Conway. La blockchain. en. url:https://www.investopedia.com/terms/b/ blockchain.asp (visitado 14-02-2021). [22] Crear una nueva aplicaci´on React – React. es. url:https://es.reactjs.org/docs/ create-a-new-react-app.html. [23] davidbritch. Modelo Model-View-ViewModel: Microsoft. es-es. url:https://docs. microsoft . com / es - es / xamarin / xamarin - forms / enterprise - application - patterns/mvvm (visitado 25-05-2021). [24] Design Patterns for Blockchain.url:https://www.researchgate.net/publication/ 342963667_Emerging_Design_Patterns_for_Blockchain_Applications (visitado 25-05-2021). [25] El concepto de consenso en Blockchain, su relevancia y consecuencias. es-ES. Jul. de 2019. url:https://santanderglobaltech.com/concepto-consenso-blockchainrelevancia-consecuencias/ (visitado 11-02-2021). [26] Estimaci´on del costo del proyecto. es. Nov. de 2014. url:https://www.recursosenprojectmanagement. com/estimacion-del-coste-del-proyecto/ (visitado 11-07-2021). [27] Ethereum Apps You Can Use Right Now.url:https://consensys.net/blog/news/ 90-ethereum-apps-you-can-use-right-now/ (visitado 11-07-2021). [28] Flowchart Maker & Online Diagram Software.url:https://app.diagrams.net/ (visitado 11-07-2021). [29] GitHub: ¿Qu´e Es GitHub Y C´omo Utilizarlo? es. Abr. de 2019. url:https://www. hostinger.es/tutoriales/que-es-github (visitado 23-02-2021). [30] GitHub: Where the world builds software. en. url:https://github.com/ (visitado 23-02-2021). [31] Gnosis.url:https://gnosis.io/ (visitado 13-02-2021). [32] Go Ethereum.url:https://geth.ethereum.org/ (visitado 10-07-2021). [33] Go Ethereum.url:https://geth.ethereum.org/ (visitado 12-07-2021). 100 BIBLIOGRAF´ IA [34] Gu´ıa de scrum. en. url:http://www.scrumguides.org/docs/scrumguide/v2016/ 2016-Scrum-Guide-Spanish.pdf (visitado 05-02-2021). [35] Gu´ıa para estimar usando story points. es. url:https://es.linkedin.com/pulse/ gu%5C%C3%5C%ADaparaestimarusandostorypointsrobertoarmoran (visitado 05-02-2021). [36] Hashing. en-US. url:https://docs.ipfs.io/concepts/hashing/ (visitado 11-07-2021). [37] How IPFS works. en-US. url:https://docs.ipfs.io/concepts/how-ipfs-works/ (visitado 11-07-2021). [38] Trey Huffine. componentDidMakeSense — React Component Lifecycle Explanation. en. Dic. de 2019. url:https://levelup.gitconnected.com/componentdidmakesensereact-lifecycle-explanation-393dcb19e459 (visitado 18-02-2021). [39] Bob Hughes y Mike Cotterell. Software Project Management. 5a edici´on. Europa, Oriente Medio y Africa: McGraw-Hill Education, 2009. isbn: 9780077122799. [40] Imagen servidor tres niveles. es. url:https://es.wikipedia.org/wiki/Programaci% 5C%C3%5C%B3n_por_capas (visitado 25-05-2021). [41] IPFS Documentation. en-US. url:https://docs.ipfs.io/ (visitado 10-07-2021). [42] ipfs-http-client. en. url:https:// www .npmjs .com / package/ ipfshttp - client (visitado 10-07-2021). [43] Jos´e Maldonado. Truffle, la mayor herramienta de desarrollo para Ethereum. es. Ene. de 2021. url:https://es.cointelegraph.com/explained/truffle-the-biggestdevelopment-tool-for-ethereum (visitado 10-07-2021). [44] Gal Margalit. React hooks lifecycle. Jul. de 2021. url:https://github.com/Wavez/ react-hooks-lifecycle (visitado 18-02-2021). [45] Julio Mar´ın. Centralized vs Decentralized vs Distributed: a quick overview. en. Ene. de 2019. url:https://medium.com/@juliomacr/centralized-vsdecentralizedvs-distributed-a-quick-overview-1f3bd17b8468 (visitado 11-02-2021). [46] moment. en. url:https://www.npmjs.com/package/moment (visitado 10-07-2021). [47] Namecoin, un DNS basado en blockchain.url:https://www.namecoin.org/ (visitado 12-02-2021). [48] New React Developer Tools – React Blog. es. url:https://es.reactjs.org/blog/ 2015/09/02/new-react-developer-tools.html (visitado 15-07-2021). [49] Node.js. Node.js. es. url:https://nodejs.org/es/ (visitado 15-07-2021). [50] npm. en. url:https://www.npmjs.com/ (visitado 15-07-2021). [51] Peepeth.url:https://peepeth.com/t/Peepth (visitado 12-02-2021). [52] Premier Diagramming, Modeling Software & Tools. en-US. url:https://astah.net/ (visitado 22-02-2021). [53] Principios de gobernanza en la blockchain. es-AR. Sep. de 2020. url:https : / / 101blockchains.com/es/principios-de-gobernanza-blockchain/ (visitado 07-02-2021). [54] Proceso y Roles de Scrum. es-ES. url:https://www.softeng.es/es-es/empresa/ metodologias-de-trabajo/metodologia-scrum/proceso-roles-de-scrum.html (visitado 14-02-2021). 101