Viade es2c is a decentralized routes management system based on the solid specifications and React framework created by some students at "Universidad de Oviedo".
Voy a comentaros cosas particulares de vuestro proyecto y otras generales que se han hablado en la practica para que os sirvan de guía. Pretenden ser sugerencias y no críticas.
:warning: Un buen gráfico debe cumplir los siguientes puntos:
Leyenda (incluye explicar colores y formas)
Flechas en una única dirección
Nombrar todos los elementos
Tener título
Disposición: Los elementos más importantes en el centro y con un tamaño adecuado
[x] Título: Acordaos cambiar el título. Tiene que aparecer el nombre de vuestro grupo _ViaDeES2C.
[x] 1.2 Quality Goals: Opciónal. Es posible hacer una tabla con las columnas Importancia de prioridad, Objetivo, Descripción donde se informe la relevancia de cada una de las prioridades.
[x] 1.3 Stakeholders: Los perfiles tienen que ser más precisos. Es más adecuado utilizar Senderista en lugar de User, es muy genérico. Incluso podéis tener diferentes perfiles de usuarios y no todos tienen que usar todas las opciones de vuestro programa. En la práctica se puso el ejemplo de una persona invidente que puede necesitar un asistente de voz. Todos los grupos que he visto tienen exactamente los mismos perfiles, yo creo que trabajando esto demuestra trabajo y dedicación.
Recordad eliminar el email del profesor, inventaros uno si quereis. :heavy_exclamation_mark:
[x] 2. Architecture Constrains: Distinción entre restricciones y decisiones.
Una restricción viene impuesta por factores externos al grupo (Por ejemplo la utilización de PODs).
Una decisión por el contrario se ha elegido por el grupo.
[x] 3.1 Business Context: Este tipo de diagrama tiene mucho de "arte". A mi me ha transmitido la idea general. Ahora bien, en mi opinión haría lo siguiente.
Quitar las flechas que forman una cruz. Buscad otra disposición
Haced el cuadrado de la aplicación más grande y el POD un poco más pequeño. El centro del diagrama es vuestro programa.
3.2 Technical Context: Podéis combinar este diagrama con el del anterior apartado si son muy parecidos. En vuestro caso era más completo el primero, al menos en esta fase del desarrollo. Sentido común chicos, un arquitecto de software debe de tomar estas decisiones. No digo que esté mal, ni mucho menos, pero tened claro que podéis jugar esa carta, más adelante el mismo proyecto os llevará a dibujar un diagrama más completo si se necesita.
Puntos 5, 7 y 8: Es normal en el estado de madurez del proyecto que no existan estos esquemas. Pero recordad que cuando empecéis a programar no dejar esto descuidado porque al final es mucho trabajo para poco tiempo. ⏰ La metodología requiere constancia.
[x] Punto 6: Me gusta, los gráficos están trabajados y se cuidado en ellos 👍 : pero revisad estos detalles:
El primer diagrama no tiene título
El primer diagrama creo que el user debe de ser un "actor" (monigote) y no un rectángulo.
Revisad las flechas. Os digo una cosa que me chirría (puede estar bien otra vez opinión). En el segundo diagrama después de almacenar la ruta, yo incluiría una flecha del POD hacia ViaDe confirmando que se ha guardado. Ese será el evento que desencadenará un posible mensaje por pantalla "ruta guardada correctamente".
[x] 9 Design Decisions:
Incluir las decisiones a las que me referí en el apartado 2 (si tenéis alguna)
Recomendación, incluir una tabla con la siguiente estructura Fecha, Decisión tomada, Nombre Participantes, Pros, Contras.
10.2 Quality Scenarios
Recomendación: Añadir en la tabla una columna con un identificador de incidencia, puede ser un número entero. El único requisito de un identificador es que sea único, pero os animo a que lo codifiquéis. por ejemplo EF_01. Es mucho más elegante.
En los escenarios no utilices descripciones genéricas. Hay que ser concreto.
"Tiempos de respuesta breves" ❌
"Tiempos de respuesta menores de 3 milisegundos ✅
Puede ocurrir que un escenario tenga 2 prioridades diferentes. Por ejemplo
Simplicidad: medio/alto. El primer valor es para el desarrollador y el segundo para el cliente.
11 Risk and Terchnical Debts ✅No os olvidéis de seguir actualizando esta sección
En clase hemos hablado de incluir la deuda técnica (ya he visto que está contemplado 👍) -Todos los atajos tomados que después deberán solucionarse- Ejemplo: "Hemos incluido todo el código en un único script de manera desordenada para cumplir las fechas de entrega. El código de reordenará de forma pulcra".
Fusionar las tablas riesgos + soluciones (está hecho) 👍 Que se pueda ver la solución de cada riesgo a su lado. Es una buena manera de mantener la documentación ordenada. La finalidad de la documentación es que un tercero pueda entender el proyecto. Tened eso en cuenta.
12 Glosary: Recordad incluir los acrónimos y demás terminología que cualquier persona ajena al proyecto deba entender. Imaginad que os asignan a otra persona. ¿Que terminos debe dominar?
Buenos días equipo.
Voy a comentaros cosas particulares de vuestro proyecto y otras generales que se han hablado en la practica para que os sirvan de guía. Pretenden ser sugerencias y no críticas.
:warning: Un buen gráfico debe cumplir los siguientes puntos:
[x] Título: Acordaos cambiar el título. Tiene que aparecer el nombre de vuestro grupo _ViaDeES2C.
[x] 1.2 Quality Goals: Opciónal. Es posible hacer una tabla con las columnas Importancia de prioridad, Objetivo, Descripción donde se informe la relevancia de cada una de las prioridades.
[x] 1.3 Stakeholders: Los perfiles tienen que ser más precisos. Es más adecuado utilizar Senderista en lugar de User, es muy genérico. Incluso podéis tener diferentes perfiles de usuarios y no todos tienen que usar todas las opciones de vuestro programa. En la práctica se puso el ejemplo de una persona invidente que puede necesitar un asistente de voz. Todos los grupos que he visto tienen exactamente los mismos perfiles, yo creo que trabajando esto demuestra trabajo y dedicación.
Recordad eliminar el email del profesor, inventaros uno si quereis. :heavy_exclamation_mark:
[x] 2. Architecture Constrains: Distinción entre restricciones y decisiones.
Una restricción viene impuesta por factores externos al grupo (Por ejemplo la utilización de PODs).
Una decisión por el contrario se ha elegido por el grupo.
[x] 3.1 Business Context: Este tipo de diagrama tiene mucho de "arte". A mi me ha transmitido la idea general. Ahora bien, en mi opinión haría lo siguiente.
Haced el cuadrado de la aplicación más grande y el POD un poco más pequeño. El centro del diagrama es vuestro programa.
3.2 Technical Context: Podéis combinar este diagrama con el del anterior apartado si son muy parecidos. En vuestro caso era más completo el primero, al menos en esta fase del desarrollo. Sentido común chicos, un arquitecto de software debe de tomar estas decisiones. No digo que esté mal, ni mucho menos, pero tened claro que podéis jugar esa carta, más adelante el mismo proyecto os llevará a dibujar un diagrama más completo si se necesita.
Puntos 5, 7 y 8: Es normal en el estado de madurez del proyecto que no existan estos esquemas. Pero recordad que cuando empecéis a programar no dejar esto descuidado porque al final es mucho trabajo para poco tiempo. ⏰ La metodología requiere constancia.
[x] 9 Design Decisions:
Incluir las decisiones a las que me referí en el apartado 2 (si tenéis alguna)
Recomendación, incluir una tabla con la siguiente estructura Fecha, Decisión tomada, Nombre Participantes, Pros, Contras.
10.2 Quality Scenarios
Recomendación: Añadir en la tabla una columna con un identificador de incidencia, puede ser un número entero. El único requisito de un identificador es que sea único, pero os animo a que lo codifiquéis. por ejemplo EF_01. Es mucho más elegante.
En los escenarios no utilices descripciones genéricas. Hay que ser concreto. "Tiempos de respuesta breves" ❌ "Tiempos de respuesta menores de 3 milisegundos ✅
Puede ocurrir que un escenario tenga 2 prioridades diferentes. Por ejemplo
Simplicidad: medio/alto. El primer valor es para el desarrollador y el segundo para el cliente.
11 Risk and Terchnical Debts ✅No os olvidéis de seguir actualizando esta sección
12 Glosary: Recordad incluir los acrónimos y demás terminología que cualquier persona ajena al proyecto deba entender. Imaginad que os asignan a otra persona. ¿Que terminos debe dominar?
¡Buen trabajo, seguid así !