DeFying Loans

EC2: una instancia EC2 es una máquina virtual que se ejecuta en la infraestructura de nube de AWS. ERC-721: es un estándar de token no fungible (NFT) en la cadena de bloques Ethereum.

Introducción

Equipo

Objetivos

En el caso de los expertos, creemos que están familiarizados con las aplicaciones descentralizadas y podrían sugerir mejoras o buenas prácticas que ya han visto y podrían utilizar, ahorrándonos tiempo en investigación. Queríamos asegurarnos de que todas las historias de usuarios se resolvieran dentro de un período de tiempo determinado.

Estructura del documento

En este capítulo, brindamos una descripción general de las lecciones que aprendimos durante el proyecto, tanto en términos del aspecto técnico como en términos de gestión del proyecto, la empresa y el ecosistema criptográfico en general.

Problema

Introducción
Antecedentes
El potencial de los NFTs
Validación del problema
Desafío y Oportunidad
Análisis de los préstamos con garantía tradicionales
Análisis de la competencia directa
Análisis de la competencia indirecta
En resumen

La idea de innovar basándose en los préstamos surgió de una lluvia de ideas sobre las NFT (ver apéndice A.3). Además, la mayoría de los expertos coincidieron en que las NFT eran lo suficientemente sólidas como para ofrecer garantías para un préstamo A.5.

Solución

Introducción

Modelo “Casa de empeño”

En caso de impago, el prestamista retiene el bien al entender el valor que tiene y es responsable de su posterior venta. Así como el valor y el atractivo de una casa de empeño residen en los bienes pignorados, el valor y el atractivo de nuestra plataforma residen en los NFT pignorados.

Modelo de negocios

Por eso otros recursos clave son: la composición del contrato inteligente que ejecuta la lógica de préstamo de forma automática y segura, y la plataforma web con la que interactúan los usuarios. El modelo de negocio evolucionó a lo largo del proyecto basándose principalmente en el feedback de los usuarios y expertos consultados.

Diferencial

Funcionamiento (Requerimientos funcionales)

En ese momento, el préstamo pasa a estar disponible en la plataforma para que otros usuarios de préstamos puedan verlo. El dinero de las cuotas pagadas se acumula en la plataforma y el prestamista puede optar por retirarlo cuando quiera.

Requerimientos no funcionales

El sistema debe garantizar que el acceso a los datos y todas las acciones realizadas en ellos deben ser autorizados por los usuarios específicos. Seguridad RNF3 El sistema debe garantizar que el acceso a los datos y todas las acciones realizadas en ellos sean accesibles.

Arquitectura

En la Ilustración 3.13, el flujo comienza con la interacción del usuario con el sitio web de DeFying Loans. Ejecute el siguiente comando en la raíz del repositorio frontend para realizar una compilación.

Metodología de Trabajo

Discovery

No es novedad que el ecosistema criptográfico tenga una tremenda volatilidad y la preocupación por esto se puede ver en el proceso de empatía. Las preguntas frecuentes eran cómo manejar el aumento o la caída del precio de la garantía utilizada en el préstamo. Además, decidimos realizar reuniones con usuarios típicos, con técnicos expertos en negocios e innovación.

En el segundo ciclo logramos un prototipo (a diferencia del ciclo anterior que fue un pretotipo).

Elección de las tecnologías

Nuevamente, queríamos que se sintieran cómodos y que pudieran brindarnos toda la retroalimentación que pudieran imaginar. En el menú de la izquierda que se ve en la Ilustración 4.1, puede cambiar de cuenta para simular transacciones entre diferentes cuentas y también puede compilar, implementar y probar todas las funciones del contrato. Una vez compiladas y desplegadas, aparecen las funciones que se pueden llamar para insertar los parámetros necesarios y así probar.

Lo que ve a la derecha de la Ilustración 4.1 es el código de un contrato de prueba que hicimos.

Delivery

83 Para las historias de usuarios más importantes, aplicamos el desarrollo impulsado por el comportamiento (en adelante BDD). Este procedimiento se repite hasta que haya una ronda completa en la que ningún miembro tenga que mover la historia del usuario. En este punto es importante describir el flujo que siguieron las historias de usuario en el mismo.

En esta prueba se comprobó si se cumplían todos los escenarios de la historia de usuario.

Plan de releases

Elegimos implementar estas funcionalidades en la primera versión del proyecto porque se encuentran entre las funcionalidades centrales de la aplicación y en el flujo de desarrollo del préstamo son las primeras que realiza el usuario. Pago de cuotas: Una vez inicializado el préstamo, el prestatario debe poder pagar las cuotas antes de la fecha de vencimiento y el prestamista debe poder retirar este dinero de la plataforma. Si, por el contrario, el préstamo se rescinde anticipadamente por falta de pago, entonces es el prestamista quien debe hacerse cargo de la propiedad del título.

Optimizar la experiencia del usuario: Hemos realizado muchos cambios en la interfaz gráfica de la plataforma para mejorar la experiencia del usuario.

Gestión de riesgos

Backlog de versiones de riesgo: contiene los riesgos de una versión determinada que se seleccionan del Backlog de productos de riesgo. Risk Sprint Backlog: contiene los riesgos de un sprint determinado que se seleccionan del Risk Release Backlog del lanzamiento al que pertenece el sprint. A continuación se detallan los riesgos de todo el proyecto, que como ya hemos mencionado, se almacenan en el Risk Product Backlog (ver Apéndice A.21.

Algunos de los riesgos como el 4, 11 y 15 se introdujeron al inicio del proyecto debido a nuestra inexperiencia tanto en la gestión del proyecto como en el uso de las tecnologías elegidas.

Aseguramiento de Calidad

Design Thinking
Iteraciones rápidas y feedback constante de usuarios típicos y expertos
Buenas prácticas en la arquitectura del sistema
Buenas prácticas en los estándares de codificación
Utilización de prácticas sugeridas por el libro Clean Code
Utilización de la metodología BDD en las historias de usuario más importantes
Pruebas de integración manuales
Sprint Review Meeting
Sprint Retrospective Meeting
Métricas de calidad

Como vimos en el proceso de desarrollo, dedicamos una etapa completa de las historias de usuario a la refactorización. Como mencionamos en el capítulo 4.3 Entrega, solo utilizamos BDD para las historias de usuarios más importantes porque la metodología consumía mucho tiempo y el aseguramiento de la calidad del proyecto no era una prioridad muy alta. Si las pruebas tuvieron éxito, la historia del usuario se movió al estado "Listo".

A continuación podemos ver una simulación del flujo de historias de usuario y subtareas en nuestro tablero Jira, usando la historia de usuario como ejemplo.

Métricas

Objetivo: Nuestro objetivo con este análisis era obtener una puntuación de al menos 4 puntos en promedio entre todos los usuarios típicos de al menos 5 encuestados después de la prueba alfa. Al final de cada sprint, mostramos gráficamente los valores y obtuvimos la desviación de la estimación de velocidad. Luego evaluamos cada tarea por separado y las sumamos para obtener el valor de la evaluación de la historia del usuario.

Análisis: Al igual que la estimación de la velocidad, la estimación del esfuerzo no fue nada fácil.

Conclusiones

Cumplimiento de los Objetivos

Esto se ve con más detalle en el gráfico de la Ilustración 6.1 del Capítulo 6. Finalmente, queríamos contar con la aprobación de los expertos en la materia (la tercera métrica de la Tabla 7.1) y por eso los entrevistamos. Las métricas para la precisión de la estimación de la velocidad y la precisión de la estimación del esfuerzo (las dos primeras filas de la Tabla 7.2) van de la mano.

Esto se ve claramente en el gráfico de desviación de la estimación de velocidad: cuando finalizan los sprints, la desviación se acerca a 0.

Lecciones Aprendidas

La estimación es una de las actividades más difíciles en la gestión de proyectos, por lo que es muy importante considerar ciertos detalles para evitar el fracaso. Un ejemplo es el caso de Solidity, una tecnología que no conocíamos y por eso hicimos varias pruebas para entenderla. Esto nos trajo muchos problemas cuando terminamos la tesis y tuvimos que hacer las últimas funciones de la aplicación desde que estábamos.

Al codificar la funcionalidad de creación de ofertas, inicialmente la diseñamos agregando un mapeo (lista) de ofertas a la estructura (objeto) de cada préstamo.

Pasos a seguir

Fijan un umbral mínimo en función del importe a pagar por el préstamo y el valor de la garantía que cubre. Para explicar esta funcionalidad, primero debes entender qué es un oráculo en el contexto del ecosistema criptográfico. Una de las ideas que utilizamos es dar la opción de combinar cuotas del préstamo si el usuario así lo desea.

Lo único que seguiría igual que en el modelo original es el uso de un NFT como garantía.

Available: https://www.bitpanda.com/academy/en/lessons/what-is-market-capitalisation-market-cap-and-why-does-it-matter/.

Capitalización y volumen del mercado cripto

Mercado de las DeFi

Lluvia de ideas inicial sobre los NFTs

Si se introdujeran nuevas regulaciones en el mercado, el negocio sufriría un impacto significativo y seguramente se vería una caída en los ingresos. Sin embargo, en el futuro el concepto NFT podrá aplicarse al mundo material. Es uno de los DEX más populares y ha sido un importante impulsor del crecimiento del mercado DeFi.

Curve Finance: Curve Finance es un protocolo de intercambio descentralizado (DEX) que se centra en el intercambio de monedas estables.

Primeras entrevistas con usuarios típicos y expertos

Dice que últimamente se ha hablado mucho de los NFT y que esto probablemente infle un poco su valor, pero está convencido de que hay valor en la tecnología y cree que será cada vez mayor en el futuro. Para que la plataforma funcione bien es muy importante validar la autenticidad de los NFT: "Nunca prestaré dinero por algo que tiene un 90% de probabilidad de ser estafado". De todos modos, también señalaron que la mayoría de los NFT estaban en Ethereum y que Solana también existía como una alternativa más barata que ha crecido mucho últimamente.

Le apasiona el mundo NFT y cree que la tecnología tiene un gran valor, especialmente en el mundo de la música.

Preguntas guía para la primera parte del desarrollo

Páginas de Confluence con información de los sprints

Ya que la aplicación necesita interactuar con contratos inteligentes no creados por nosotros para su correcto funcionamiento. Ya que ninguno de los miembros del equipo tiene mucha experiencia en la gestión de proyectos de software. Dado que el equipo tiene muy poca experiencia en gestión de proyectos y tecnología Blockchain.

Dado que el precio de las transacciones en blockchain es alto hoy.

Análisis de la competencia directa

Esta plataforma es muy similar a NFTfi en su modelo de préstamo con NFT como garantía, pero además de ofrecer esta funcionalidad, también es un mercado de NFT donde los usuarios pueden comprar y vender sus tokens no fungibles. Al igual que con NFTfi, tenemos muchas ideas sobre cómo funciona la plataforma. Esto significa que la plataforma distribuye acciones (en forma de NFT) a los usuarios que estén interesados en invertir en ella, y el 100% de las ganancias de X2Y2 se distribuyen entre sus miembros.

Matrices de Pugh utilizadas para elegir las tecnologías

Workflows de Github para automatizar el proceso de despliegue

Prototipo (Imágenes)

Características del proyecto

Muchos riesgos: la mayoría de los cuales sólo se pueden aceptar porque se refieren al mundo blockchain y no tenemos control sobre ellos (por ejemplo, el testnet Rinkeby, en el que estábamos desarrollando, dejó de funcionar después de la fusión de Ethereum). Seguridad: La seguridad fue la principal prioridad en el desarrollo porque se maneja el dinero de los usuarios. El proyecto es una prueba de concepto, no una plataforma lista para usarse en el mundo real.

Tomamos esta decisión porque no sabíamos si el modelo de negocio que habíamos armado sería viable, además la industria blockchain es muy dinámica.

Tableros de las Retrospective Meetings en MetroRetro

Primera entrega al CIE para la aprobación inicial del proyecto

Requisitos no funcionales

Evidencia buenas prácticas y estándares de codificación - Solidity

Evidencia buenas prácticas y estándares de codificación – Typescript

Evidencia buenas prácticas y estándares de codificación – NextJs

Evidencia buenas prácticas y estándares de codificación – NestJs

Riesgos especificados de todo el proyecto, sacados directamente de las páginas

Risk Product Backlog

Risk Release Backlogs

Risk Sprint Backlogs