DEV Community: Rene Escalante

La evaluación de productos, procesos y recursos

Rene Escalante — Mon, 08 Nov 2021 05:40:07 +0000

Esta infografía fue creada para una tarea de la Universidad Francisco Gavidia, video de referencia: https://www.youtube.com/watch?v=j1QHt7Xx4z4

5 Aspectos claves del mantenimiento de un sistema

Rene Escalante — Mon, 01 Nov 2021 03:02:16 +0000

Este artículo fue creado para una tarea de la Universidad Francisco Gavidia utilizando como base el capítulo 9 del libro "Ingeniería de Software un enfoque práctico" de Roger Pressman.

1. La evolución del software

Es de aceptar en la empresa que un software evoluciona por los cambios por ejemplo cuando se corrigen errores o se adaptan a un nuevo entorno o nuevas funcionalidades solicitadas por el cliente, Manny Lehman junto a colaboradores desarrollaron una teoría unificada de la evolución del software, que contiene leyes subyacentes como la ley del cambio continuo, ley de complejidad creciente, ley de autorregulación, ley de crecimiento continuo, etc. Estas leyes son una parte fundamental para entender el propósito de la reingeniería de software.

2. RPE (Reingeniería de procesos de empresa)

Los procesos empresariales son tareas lógicamente relacionadas que tienen un cliente definido que recibe el resultado, la mayoría de RPE se enfoca en procesos o subprocesos individuales. Consta de estas actividades

3. Reingeniería de Software

A diferencia de RPE, en la reingeniería de software se contempla un modelo de proceso de ingeniería para reconstruir partes de la aplicación existente. Esta puede contar de los siguientes procesos:

4. Ingeniería inversa

Ingeniería inversa extra información de como funciona un programa existente esto puede suponer la reestructuración de código que supone la reestructuración de módulos sospechosos, y la reestructuración de datos que es una reestructuración a gran escala, ya que se reestructuran los modelos de datos muchas partes del código pueden cambiar, esto se muestra en el siguiente proceso:

5. La economía de la reingeniería

Es un análisis por medio de fórmulas para verificar si vale la pena someter a una aplicación existente a una reingeniería midiendo su costo-beneficio de manera cuantitativa, esto es de mucha importancia para determinar si vale la pena invertir en este mantenimiento del sistema.

El mantenimiento del sistema.

Rene Escalante — Sun, 24 Oct 2021 23:59:23 +0000

Este artículo fue creado para una tarea de la Universidad Francisco Gavidia.

Mapa conceptual

Respuestas a las preguntas de clase

¿Por qué resulta necesario realizar mantenimiento del software?

El mantenimiento del software es vital debido a que a medida que los verdaderos usuarios ocupan el software, se encuentran con defectos aun cuando se hace una muy buena inspección del software esto es posible.
Además por cada cambio que se realiza al producto original es más probable que surjan defectos y se deba realizar mantenimiento.

¿Qué le pasa usualmente a un software que no se mantiene?

Si el software no se le realizan mas cambios, con el tiempo puede convertirse en un codigo legacy, ya que las tecnologías van cambiando frecuentemente, y se volvería anticuado, si se le realizan cambios, surgirán una gran cantidad de defectos que forzara hacer mantenimiento.

¿Cómo es posible clasificar los tipos de mantenimiento en función de sus objetivos?

En el mapa conceptual se presentan los siguientes tipos basados en la clase:

Correctivo: Arregla un defecto.
Adaptivo: Se enfoca en la escalabilidad y los cambios que pueden surgir.
Perfectivo: Se centra en hacer una funcionalidad mas legible y con mayor rendimiento.
Preventivo: Previene problemas de seguridad y que se originen mas defectos.

¿Qué problemas plantea el mantenimiento?

De que se cree un efecto domino, se degrade la calidad con los nuevos cambios, y que si no se sigue una metodología adecuada se cree codigo legacy.

¿Qué necesidades conflictivas aparecen durante el mantenimiento?

Discusiones entre las implementaciones de los desarrolladores para no afectar y que sea escalable el código y además implementar lo que sea necesario y beneficioso para el cliente esto puede llevar a conflictos, pero es necesario que se lleven a cabo y se compartan opiniones y soluciones para obtener el mejor software.

¿Qué hay que hacer para que los atributos de calidad del software no se degraden durante el mantenimiento?

Se debe mantener una documentación adecuada tanto interna como externa y se debe poner de acuerdo al equipo de desarrollo con metodologías de cambio.

Aspectos necesarios en la entrega de un sistema

Rene Escalante — Sun, 17 Oct 2021 16:13:01 +0000

Introducción

La entrega o también conocido como liberación del sistema, es cuando el sistema de software se entrega en el ambiente que los usuarios van a utilizar, por ejemplo este puede ser un ambiente en producción en línea o puede ser que se entregue el descargable y se publique en una tienda de apps móviles para que los usuarios puedan descargarla, esto varía según la naturaleza del software.

Aspectos a considerar

Entrenamiento

Se debe tener una buena preparación y un equipo entrenado para prevenir problemas al entregar el software

¿Quiénes se deben entrenar?

Usuarios Finales: Se les debe mostrar que hace el sistema y como utilizarlo, una buena UI y UX entrena en el momento que se utiliza el sistema y es lo ideal.
Administradores: Se deben dividir las funciones de soporte y quienes tienen las habilidades apropiadas para realizar esta función y explicar internamente como funciona el sistema.

Revisión

Cada rol tiene diferentes necesidades, se debe evaluar basado en las características y estilos de trabajo personales y presiones de la organización lo siguiente:

Grado de uso del sistema.
Eficiencia en el uso.
Cumplimiento de objetivos.

Ayudas

De las más sencillas podemos tener:

Guías, teniendo en cuenta el costo beneficio de tener mucho que leer o muy poco, debe mostrar lo esencial, debe haber guías rápidas con las funciones más vitales.
Documentación y referencia, deberían mostrar a más detalle.
Demostraciones, parte importante de la validación. De las más complejas sin embargo efectivas son:
Talleres, igualmente son importante para la validación.
Apoyo de usuarios expertos como entrenadores. ¿Cuándo deberíamos hacer estas ayudas más complejas? Es cuando existan conflictos por disponibilidad, validación temprana, olvido por desuso, etc.

Esencialmente debe haber ayuda en línea y asistencia activa para dar la mejor ayuda posible.

Documentación

Como se mencionó en Ayudas para el entrenamiento, la documentación es parte muy importante para asegurar un entregable efectivo y resolver problemas, asegurarse de la calidad de la documentación conlleva los siguientes aspectos:

Legibilidad
Estructura
Tamaño
Ilustraciones
Facilidad para ubicar información relevante.
Completo
Correcto

Para el administrador es muy importante, ya que debe indicar las configuraciones por ejemplo:

Autorizar accesos
Agregar o suprimir equipos
Generar respaldos
Solucionar problemas En el aspecto de solucionar problemas debe haber guías para lidiar con mensajes de error y solucionarlos.

Implementación

Esta podría ser de 2 diferentes naturalezas:

Conversión

Se sustituye un sistema anterior por uno nuevo, esto se puede realizar de manera manual o automatizada.
Para esto hay diferentes estrategias como:

Big-bang
Paulatina ya sea de convivencia o ajuste de procedimientos
Procesamiento en paralelo, e.g. uno en producción y otro en prueba/control.

Instalación

Se instala el software para que quede disponible y operativo a los usuarios, la complejidad puede variar dependiendo de:

Tecnología utilizada.
Restricciones funcionales.
Requerimientos de disponibilidad.

Este artículo fue creado para una tarea de la Universidad Francisco Gavidia, video de referencia: https://www.youtube.com/watch?v=DnXSz-dhqrI

El proceso de prueba de un sistema

Rene Escalante — Sun, 10 Oct 2021 19:01:40 +0000

Este artículo fue creado para una tarea de la Universidad Francisco Gavidia, video de referencia: https://www.youtube.com/watch?v=wfgFcwh_EkM

El principio fundamental de una prueba de sistema es: "Asegurar que el sistema hace lo que él cliente quiere que haga"

El proceso de la prueba de un sistema se lleva a cabo con el siguiente orden de pruebas:

Analizaremos cada una de las pruebas para conocer más sobre que se espera al utilizarlas.

Prueba de Función

Siguiendo un esquema de caja negra, se evalúan las funcionalidades de los requerimientos funcionales ignorando la estructura del sistema, pruebas eficaces de este tipo tienen una alta probabilidad de descubrir un defecto, cuando son bien realizadas se hace prueba de una función por vez, para así evitar hacer pruebas tan grandes de múltiples funciones y no encontrar exactamente en que funcionalidad ocurrió el error.

Prueba de Desempeño

También conocida como de rendimiento, esta solo se debería realizar una vez te tenga la certeza que el sistema realiza las funciones que se mencionan en los requerimientos, estas se basan sobre todo en los requerimientos no funcionales y los Ings. de Hardware pueden involucrarse debido a que es necesario validar rendimiento tanto en hardware y software.

Tienen muchos tipos de prueba como de:

Estrés
Volumen
Configuración
Compatibilidad
Configuración
Regresión
Seguridad
Temporización
Medio Ambiente
Calidad
Recuperación
Mantenimiento
Documentación
Factores Humanos

Prueba de Aceptación

Con los resultados de las pruebas el cliente debe revisar que lo que se ha hecho es lo correcto, independientemente de la forma que lo verifique ya sea en un sitio web o instalado en el hardware de los usuarios, la aceptación es que el cliente acepte lo que el sistema está realizando.

Prueba de Instalación

Se instala el sistema a los usuarios y se verifica que funcione correctamente, se considera completo una vez el cliente está satisfecho con los resultados.
Puede que no sea necesario si la prueba de aceptación se ha realizado en el sitio.

Prueba de los programas

Rene Escalante — Mon, 04 Oct 2021 03:24:58 +0000

Este artículo fue creado para una tarea de la Universidad Francisco Gavidia, las imágenes las extraje de Pega Community

Experiencia propia creando prueba de los programas

En mi trabajo he desarrollado pruebas para escenarios completos del sistema así como pruebas unitarias, debido a que utilizo una herramienta low-code conocida como Pega esto es bastante sencillo.

En Pega ya se tienen configuraciones como plantillas que se pueden programar que se les llama rule, para hacer pruebas unitarias utilizamos una "Test Case" rule, donde básicamente se escribe un resultado esperado de otra rule que puede setear información por ejemplo:

En este caso se espera que para la Data Page Customer, cuando se le pase un parametro de ID = Cust-1, que corra en menos o igual de 0.01 segundos y que tenga un output donde la Data Page se le setee el ID a "Cust-1" y el name a "AmCo".

Se puede tener varios test cases en un proceso para hacer distintas pruebas unitarias.

Para probar un escenario completo utilizamos otra rule llamada "Scenario Test Case" que hacen una prueba completa de un escenario con la UI, vínculo un video para una demostración es una funcionalidad parecida a Cypress, pero que ya está integrada en el sistema.

Tipo de prueba que no he probado anteriormente

Basado en el anterior articulo.

Una prueba de instalación es algo que no he realizado antes, al menos con la intención de hacer la prueba propiamente descrita, imagino que este tipo de prueba las hace más frecuentemente IT, y me pareciera bastante interesante si equipos de IT corren un script para validar todos los programas funcionen de la manera esperada en un equipo para evitar hacer pruebas manuales en los equipos de todos los clientes.

Aspectos a considerar en las pruebas de un programa

Rene Escalante — Sun, 26 Sep 2021 23:53:22 +0000

Este artículo fue creado para una tarea de la Universidad Francisco Gavidia, video de referencia.

Objetivo de hacer pruebas

Antes de entregar, debemos hacer pruebas de los programas, debido a que nos permiten descubrir problemas.
La etapa de prueba se centra en la búsqueda de defectos, cosas que debemos corregir para la entrega del usuario, antes de la entrega.
Revisiones de requerimiento y diseño contribuyen en descubrir problemas.

Es de recordar que el propósito de las pruebas es demostrar la existencia de un defecto, no en sí que los programas operan correctamente, sino buscar defectos.

Por eso la prueba es destructivo.
- Para identificar origines de las fallas
- Y corregir.

¿Que significa que el software falla?

No hace lo que especifica los requerimientos.
- Pudo haberse omitido algo.
- Algo imposible de implementar con el software y hardware prescrito.
- El diseño del sistema o del programa puede contener un defecto.
- El código del programa puede estar errado.

Tipos de defectos

Algorítmicos
- La lógica desarrollada no se produce la salida apropiada, debido a algún paso está mal en el procesamiento.
- Incluyen:
  - Condición errónea, por ejemplo no poner notas negativas.
  - Olvidar inicializar una variable.
  - Comparar variables de tipos de datos inapropiados.
Sintaxis: Se realiza cuando no se ha utilizado correctamente las estructuras del lenguaje de programación.
Computación y de precisión:
- Flotantes o enteros inesperados, cuando la implementación de la forma no llega al grado de exactitud esperado, por ejemplo en planillas esto es vital.
Documentación
- No corresponde con lo que el programa realmente hace, se tiene a confiar en la documentación y si por ejemplo se hizo un cambio en el código y no sé hizo cambio en la documentación se da el problema.
Defectos por estrés o sobrecarga
- Cuando una estructura como por ejemplo tamaño de almacenamiento, se sobrecarga en el sistema hasta sobrepasar su capacidad especificada.
Capacidad o de límites
- Se vuelve inaceptable la actividad debido al límite del sistema, por ejemplo tratar de correr un programa de 64 bits en uno de 32 bits.
Desempeño
- Sistema no opera a la velocidad prescrita por los requerimientos.
Sincronización o de coordinación
- Se produce cuando se coordina dichos eventos es inadecuados
Recuperación
- Cuando hay una falla, ocurre cuando no se comporta como el cliente quiere para notificar la falla.
Hardware y Software
- Cuando hardware y/o software no trabajan realmente de acuerdo con las condiciones operativas y documentaciones, por ejemplo una impresora que se realizó todas las configuraciones indicadas e igualmente falla.
Estándares y procedimientos.
- Si no se está siguiendo en el código los estándares mínimos que se han establecido en la empresa.

Tipos de prueba:

Son los siguientes:

Unitaria
Integración
Función
Desempeño
Aceptación
Instalación

Pruebas de integración a más detalle:

Las pruebas integración se planean y coordinan para que al producirse una falla, se pueda tener alguna idea de lo que le ha dado origen.

Tipos:

Ascendente (bottom - up): Desde los componentes elementales a los más generales.
Descendente (top - bottom) Lo contrario, desde los más generales a los más elementales
Big - Bang: No es práctico para grandes sistemas, pero muchos programadores lo ocupan para pequeños, mezclar juntos a todos los componentes como un sistema final y ver si funciona la primera vez. El problema es que es más difícil identificar cuál fue la causa de una falla.
Intercalada: Mezcla los métodos ascendente y descendentes por medio de 3 capas, en el medio la capa objetivo, los niveles por encima del objetivo, y los niveles por debajo del objetivo.

¿Quién realiza las pruebas?

Para evitar las opiniones personales del equipo de desarrollo es buena práctica contar con un equipo de prueba independiente, conocido como QAs.
De esta forma igualmente se puede llevar la codificación y las pruebas concurrentemente.

Visión de los objetos de prueba:

La propia visión que se tiene del objeto de prueba, ya sea un componente, sistema, subsistema, etc. afectara la forma que se lleva a cabo la prueba.
Este puede ser:

Caja negra: Si se ve desde afuera y el contenido, o sea sé el código se desconoce, solo es de tomar entradas y anotar las salidas que produce y verificar que es la esperada. Ejemplo: Debido a que este tipo de prueba es libre de las restricciones impuestas por la estructura interna o lógica, solo es de verificarlas con casos de uso de la lógica de negocio. Método más usado:
- Particionamiento de Equivalencias
- Análisis de Valores Fronteras
- Adivinanza de defectos
Caja blanca: Se utiliza la estructura interna del objeto para probarlo de diferentes maneras Ejemplo: Se pueden ejecutar casos de prueba que ejecuten toas las instrucciones y caminos de control que existen del objeto. Método más usado:
- Pruebas de Cobertura (Instrucción, Decisión, Condición, Decisión/Condición, Múltiples Condiciones, De Caminos).
Caja estructurada: Cuando se utilizan tantas pruebas de caja cerrada en un extremo y en el otro de caja abierta en un programa.

Proceso para encontrar defectos:

Examinar el código.
Comparar el código con las especificaciones
Desarrollar casos de prueba (test case) para demostrar que las entradas tienen salidas esperadas.

Examen de código

Para hacer un examen del código hay de 2 tipos:

Recorridas: Programador lidera la discusión y se presenta a un equipo de revisión, es informal.
Inspecciones: Es más formal, el equipo se reúne para hacer una revisión general y se preparan individualmente para una segunda reunión de grupo, cada inspector estudia el código y documentos relacionados.

¿Qué determina un buen test case?

Aquel que tiene una alta probabilidad de encontrar un defecto no descubierto.
No es redundante, ni muy simple, ni muy complejo, idealmente, el mejor de su clase.
Un exitoso test case es aquel que descubre un defecto no descubierto.

Mapa conceptual sobre aspectos generales de la programación

Rene Escalante — Mon, 20 Sep 2021 04:35:19 +0000

Este mapa mental fue creado para una tarea de la Universidad Francisco Gavidia, utilizando Lucidchart y tomando como referencia el siguiente video:
https://www.youtube.com/watch?v=_jnRi7NF-qc

La importancia de la utilización de objetos en el diseño de un sistema

Rene Escalante — Thu, 09 Sep 2021 03:20:59 +0000

¿Qué es POO?

Programación Orientada a Objetos (POO) es una forma de pensar acerca del software basado en abstracciones del mundo real, orientación por objeto, significa que diseñamos software como una colección de objetos distintos.

Importancias de POO

Una de las características más importantes de un código que sigue POO es que logra encapsulamiento de sus funcionalidades, este es el paradigma fundamental de la POO, debido a que hace sistemas mucho más seguros, ya que separa el código que debería ser accesible para los desarrolladores que quieren implementarlo como una API, y el que no que es código interno de la clase y no debería hacerlo accesible, este modelo también ayuda para la seguridad en sí del sistema con el usuario.

Sobre los objetos

Cada objeto debe tener su propia identidad en un sistema bien construido, como un registro en una base de datos, siguiendo con esta comparación, se podría decir que una clase es los atributos que un registro de una tabla de base de datos debe llevar, y el objeto es el registro en sí.

Siguiendo POO, cuando un objeto se transforma, consta de interfaz, estructura de datos privada, y métodos que son los únicos que pueden transformar legítimamente la estructura de datos del, en otras palabras, no se altera directamente, se debe alterar con métodos/funciones dependiendo del lenguaje.

Ventajas de sistemas POO

Es de gran ayuda al dominio y entendimiento del diseño.
Es más sencillo hacer cambios en un sistema que utiliza POO.
Facilita la reutilización de código.
Es más natural, además como las metodologías ágiles de Scrum, POO es un estándar en la industria.

Metodología de diseños de sistemas

Debe considerarse que la metodología de diseño es algo bastante creativo, esta es una generalidad, pero usualmente para POO se tiene como metodología:

Dividir el sistema en subsistemas.
Producir un diseño OOP de los subsistemas.
Una POO completa es tal que en la implementación solo se agregan detalles y lo más importante ya se diseñó.
- La mayoría de las clases y sus relaciones se identifican con el diseño.

3 Claves para el diseño

Estas claves facilitan un diseño que sigue POO:

Acoplamiento:
Mientras más acoplado más dependientes son los módulos entre sí y por tanto más complejo de entender el programa y más difícil de modificar. Hay de tipo Interacción y Componente.
Cohesión:
Analiza Porque los elementos de un módulo están juntos en ese módulo, tiene tipo a nivel método, clase y herencia.
Abierto-Cerrado:
Se basa fuertemente en herencia para evitar la modificación de una clase, básicamente habrá módulos abiertos a la modificación y módulos cerrados a la modificación que solamente deberían ser expandidos.

Mi metodología de diseños de sistemas

Entrando a más detalle en como personalmente diseño un sistema, usualmente escribo en alto nivel los objetos y las clases que el sistema planeara utilizar, por ejemplo recientemente he estado trabajando en un proyecto de Tic Tac Toe en JavaScript para The Odin Project un currículum que sigo, y escribí esta arquitectura de alto nivel de los módulos como parte de pensar como la estructura del código será en el momento de la implementación.

Usualmente sigo la metodología tradicional de dividir en subsistemas, hacer una arquitectura a alto nivel y luego implementar, en ese caso es un sistema bastante pequeño, pero en un sistema más grande lo segmento.

Nota - Este artículo fue realizado como parte de una tarea de la Universidad Francisco Gavidia tomando como fuente el siguiente video:
https://www.youtube.com/watch?v=UrvQLx73xXY

Infografía: Aspectos importantes/generales del diseño de un sistema

Rene Escalante — Mon, 06 Sep 2021 00:43:03 +0000

Este mapa mental fue creado para una tarea de la Universidad Francisco Gavidia, imagenes extraidas de Wikipedia y del video fuente:
https://www.youtube.com/watch?v=EQ24JCOVCVg

Claves del desarrollo de la planificación y la gestión de proyecto

Rene Escalante — Sun, 22 Aug 2021 14:50:09 +0000

El propósito de planificar proyectos es poder llegar a un compromiso con el cliente para cumplir una meta basado en
planificación y estimación.

Planificación y Estimación.

Para cumplir el objetivo de negocio deseado se debe basar en una predicción de cuando estaría el producto, esto debe tomar en cuenta:

Esfuerzo
Costo
Duración Sin embargo planificación y estimación son definiciones distintas.

¿Qué es la planificación?

Es el proceso parcial que procura una meta, favoreciendo esta meta en específico y tiene como objetivo un resultado en particular.

¿Qué es la estimación?

Es la predicción, imparcial y analítica, ya que no favorece a ninguna meta en específico, y tiene como objetivo la exactitud.

Estimación del tamaño

Estimar el tamaño de un proyecto permite estimar su esfuerzo y duración, medir calidad, y productividad. Estos son algunos de los atributos más importantes para la estimación de tamaño:

LOCs (Toma en cuenta lenguajes, criterios para contar líneas, con o sin comentarios, etc.) la mayoría de herramientas de estimación se basan en LOC (Lines of Code)
Requisitos.
Historias de usuario, casos de uso, puntos de función, etc.

Para proyectos pequeños se puede tomar que esfuerzo/productividad = tamaño.

Sin embargo, es de reconocer que no es sencillo estimar el tamaño debido a que:

Las estimaciones iniciales de la definición son imprecisas.
El software a desarrollar a menudo se ejecuta en entornos desconocidos.
Las habilidades de las personas son desconocidas.

¿Qué puede afectar el proyecto?

Según la incertidumbre de Heisenberg "Al observar algo cambia", en el caso de proyectos esto es debido a que medida vamos analizándolo más, dificultades imprevistas aparecen, las razones que afectan los proyectos son:

Cambio de asunciones, el proyecto no es lo mismo que fue estimado.
Eventos externos imprevistos.

Esto puede ser prevenido tomando más decisiones, debido a que mientras más decisiones se tome, menor es la incertidumbre, en esto se basa el cono de la incertidumbre:

Mientras menos converge el proyecto en este diagrama, es más probable que el proyecto sea caótico y no se cumpla el compromiso con el cliente.

Consideraciones sobre el personal del proyecto

El personal es clave para la gestión de proyectos, ellos harán el proyecto una realidad.
Cada miembro de un equipo tiene su propia personalidad, debe haber un equilibrio entre sus personalidades:

Personalidad orientada a la tarea: Es ideal que el jefe del proyecto tenga esta personalidad, debe demostrar lealtad, proteger al grupo de demandas poco realistas, toma de decisiones, etc. Su motivación es el trabajo en sí.
Personalidad orientada a las relaciones: La motivación viene de su trabajo en equipo, si el grupo fuera constituido por una sola persona, solo funcionaria bien con esta personalidad.
Personalidad orientada a sí misma: La motivación es el éxito personal.

Este grupo de personas, deben crear un equipo, teniendo una comunicación efectiva entre todos y lealtad entre ellos y su trabajo en conjunto, debido a esto la interacción es la parte más importante de todo equipo y es lo que normalmente debería llevar más tiempo:

Además el ambiente laboral para formar un equipo debe satisfacer sus necesidades como la jerarquía de Maslow, satisfaciendo su reconocimiento, afiliación con el grupo, realización personal y motivando al grupo.

Nota - Este artículo fue realizado como parte de una tarea de la Universidad Francisco Gavidia tomando como fuente el siguiente video:
https://www.youtube.com/watch?v=VbCRO0PsL6E

Mapa mental planificacion de proyectos

Rene Escalante — Mon, 16 Aug 2021 04:58:19 +0000

Este mapa mental fue creado para una tarea de la Universidad Francisco Gavidia, imagenes extraidas de Wikipedia, creado con draw.io