Revisión arquitectura #31
Description
Buenas tardes equipo. Os paso un resumen de lo hablado en clase. Algunas cosas son generales y otros aspectos concretos de vuestro trabajo.
-
Título: Cambiadlo y añadir vuestro id de grupo. Esto indica poco cuidado al hacer las cosas.
-
Incluir leyendas en los gráficos: Obligatorio. No perdais puntos por este detalle por favor. :war
-
1.2 Quality Goals: Indicad el nivel de importancia de las prioridades. ¿Es más importante el 1 o el 5? Un texto encima de la tabla o debajo
-
1.3 Stakeholders: Los perfiles tienen que ser más precisos. Es más adecuado utilizar palabras que definan los diferentes tipos de usuario como por ejemplo Senderista en lugar de Users.
-
2. Architecture Constrains: Hay que distinguir las restricciones de las 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.
-
3.1 Business Context: El diagrama que utilizáis no está bien. Es una mezcla del diagrama de casos de uso de UML. La idea de este esquema es mostrar una primera impresión de lo que hace vuestra aplicación, que actores intervienen y con qué servicios se conecta si es que lo hace. Mirad ejemplos de la doc de clase o por Google. Si tenéis dudas lo vemos.
3.2 Technical Context: No teneis diagrama de contexto técnico, no es necesario tenerlo. Es posible utilizar el diagrama anterior si es muy parecido, ya visteis que un grupo mostró uno que era muy parecido al anterior. En próximas etapas del proyecto donde todo esté más maduro decidireis si debe incluirse.
-
4 Solution Strategy: Si tenéis TO DO cambiarlos a issues.
-
Punto 6: Los diagramas graficamente están bien, para ser excelentes debeis:
- Incluir leyenda (segunda vez en que incido).
- Cambiar el color de la fuente de los rectángulos azules. No se lee nada. Ese matiz le resta calidad, transmite improvisación.
- Si utilizáis colores, intentad que estén armonizados entre si pero lo suficientemente diferentes para no confundirlos. Si la finalidad es estética no es una prioridad
-
Puntos 7 y 8: Tenéis que empezar a hacer foco en estos puntos. 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.
-
9 Design Decisions . Ante todo el haber dicho que dejabais una decisión pendiente de tomar me ha gustado. Dais feedback ✅ . Tened en cuenta que en próximas versiones debe de resolverse.
-
Recomendación, incluir una tabla con la siguiente estructura Fecha, Decisión tomada, Nombre Participantes, Pros, Contras
-
Incluir las decisiones a las que me referí en el apartado 2
-
10.2 Quality Scenarios: 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. Tenéis que ser concretos.
-
"Tiempos de respuesta breves" ❌
-
"Tiempos de respuesta menores de 3 milisegundos ✅
-
11 Risk and Terchnical Debts: En clase hemos hablado de incluir la deuda técnica -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 se reordenará de forma pulcra".
-
Fusionar las tablas riesgos + soluciones . 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.
Opinión personal: Chicos os veo pillados. Tenéis tiempo de sobra a revertir la situación y entregar un proyecto de calidad pero debéis trabajarlo. No veiais esto como un tirón de orejas sino como un aviso. Vosotros mismos en los riesgos sois conscientes de que las tecnologías son nuevas para vosotros y dominarlas exige tiempo, por eso todo este análisis y documentación luego os ayudará.
Mis recomendaciones:
-
Sed pragmáticos. primero dibujad a mano los esquemas y subid una foto, según tengáis las cosas claras ya los maquetareis. Ahora mismo tenéis que recuperar el tiempo perdido.
-
Haced cuanto antes los cambios en las tablas (nuevas columnas, etc) así solo tendréis que rellenar y los cambios van más rápido.
-
Sinceramente opino que dedicándole un par de tardes de trabajo duro mejorará mucho el proyecto y cogeréis velocidad. Al principio todo es más dificil, no os desanimeis. Tened claro que esto depende de vosotros yo poco más puedo hacer.
Mucho animo.