alexmenor / heroes Goto Github PK

No digas "he elegido x por y". Di cuales eran los requisitos en tu aplicación. Describe las diferentes opciones que había para x. Describe qué X has elegido por uno de los requisitos elegidos de antemano

• Añadir linters/code smell tests

No se trata solamente de un pitch de venta, es un resumen del trabajo hecho.

El aviso debe poder llegar a:

• La policía
• Personas de confianza
• Personas cercanas con la aplicación descargada

Ver

• Back end
• Front end

• Actualizar la sección de la documentación con la elección
• Crear la nueva implementación de persistencia en el microservicio de geo

• Título
• Coma
• Asociar HU
• Justificar el uso de websockets, notificaciones, etc...

I. E. No asumas que el tribunal o quien lea la memoria sabe lo que es "transpilar" o, para el caso, Javascript.

Si tienen un equivalente español, como "control de calidad".
También ten en cuenta que la metodología ágil implica control de calidad en todas las fases del desarrollo, así que limitarlo a un apartado (y a la integración continua) es un poco limitado.

It should be done with a pub/sub system instead.

• Elegir una plataforma de desarrollo de app móvil y documentar la elección.
• Empezar un proyecto de esa plataforma y hacer un scafold básico.
• Incluir un componente de mapa y localizar la posición en ese mapa. Probablemente haya que hacer una elección de proveedor de mapas ahí, documentarla.

• Buscar sistema de persistencia adecuado.
• Interfaz adecuada con el front end.
• Front end
• Tests

Por ejemplo: Grabación de sonido, ubicación, dispositivos cercanos, etc..

No menciones la metodología waterfall (aunque posiblemente sean la única que conocen), explica qué es lo que se ha hecho desde el principio con la metodología ágil (y explícala, ahora mismo está un poco deslavazado con la referencia a los commits y demás). Tienes que explicar incluso el hecho de que estás usando desde el principio git y GitHub, todo eso. No des por supuesto ningún conocimiento en el tribunal.

Planteamiento quizás debería explicar que se trata de la implementación. Backend, si es parte de la implementación, ¿no iría en ese capítulo? Recuerda la jerarquía conceptual de la memoria, y también la "narrativa". Primero planteas, luego implementas, luego despliegas...

Si no describes qué es lo que va a hacer, el estado del arte se limitará a soluciones generalistas al problema, muchas de las cuales no necesariamente tienen que pasar por la informática (puede ser simplemente más iluminación, o más policía, o redes de transportes nocturnos más tupidas9
En general, el estado del arte tiene que tratar sobre el nicho de mercado o tipo de solución informática que se haya propuesto, por eso hay que proponerlo antes.

Si el estado del arte describe soluciones existentes al problema, no pueden ir antes que el análisis dle mismo, porque hay que decir cómo esas soluciones afrontan los problemas planteados.
En general, la memoria tiene que tener una estructura argumentativa y narrativa.

"Estado del arte" va seguido por "inconvenientes". Aunque el índice no tiene necesariamente por qué ser una narración, sí debes de aclarar el contexto lo máximo. Aquí lo obvio sería que estuvieras hablando de los inconvenientes de las soluciones descritas en el estado del arte (y por tanto, debería ser una subsección).

• Back end
• Front end

Aparte de lo dicho en #31, tienes que hablar también de las decisiones de arquitectura tomadas; dices como un hecho que usas un método cliente servidor, pero hay muchas otras opciones, como serverless o basado en contenedores y cosas por el estilo.