Diferencia entre revisiones de «Comentarios para mejorar los trabajos 15-16»

De Wiki de EGC
Saltar a: navegación, buscar
(Sobre la memoria)
(Sobre la memoria)
Línea 5: Línea 5:
 
* Poner una página con los enlaces importantes que correspondan, por ejemplo, repositorio/s de código del equipo, repositorio compartido, repositorio de incidencias, wiki, despliegue, etcétera.
 
* Poner una página con los enlaces importantes que correspondan, por ejemplo, repositorio/s de código del equipo, repositorio compartido, repositorio de incidencias, wiki, despliegue, etcétera.
 
* Hacer un índice de figuras y poner un "caption" a cada figura, ejemplo. Figura 1. esquema de relación entre componentes
 
* Hacer un índice de figuras y poner un "caption" a cada figura, ejemplo. Figura 1. esquema de relación entre componentes
 +
* Debe quedar clara la diferencia entre el proceso abstracto de gestión definido, la herramienta que da soporte a dicho proceso y el ejercicio que se proponga. En el proceso abstracto se define la norma de uso del proceso sin especificar nada concreto con respecto a una herramienta determinada (e.g. GIT). En la parte de cómo dar soporte a ese proceso con una herramienta determinada se especifican detalles de cómo dar soporte al proceso abstracto con la herramienta. Por último, en los ejercicios se debe poner por una parte un enunciado claro del ejercicio y por otra parte la solución a dicho ejercicio. El ejercicio tiene que ser algo concreto y personalizado para el proyecto en cuestión. No valen ejercicios genéricos que valdrían para cualquier proyecto.
  
 
== Sobre el diario ==
 
== Sobre el diario ==

Revisión del 13:17 4 ene 2016

Sobre la memoria

  • En la portada poner nombres y apellidos de cada componente, grupo al que pertenecen (1 o 2, mañana o tarde), curso académico, nombre del proyecto (deliberaciones, almacenamiento,...).
  • Poner una página con control de versiones del documento
  • Poner una página con los enlaces importantes que correspondan, por ejemplo, repositorio/s de código del equipo, repositorio compartido, repositorio de incidencias, wiki, despliegue, etcétera.
  • Hacer un índice de figuras y poner un "caption" a cada figura, ejemplo. Figura 1. esquema de relación entre componentes
  • Debe quedar clara la diferencia entre el proceso abstracto de gestión definido, la herramienta que da soporte a dicho proceso y el ejercicio que se proponga. En el proceso abstracto se define la norma de uso del proceso sin especificar nada concreto con respecto a una herramienta determinada (e.g. GIT). En la parte de cómo dar soporte a ese proceso con una herramienta determinada se especifican detalles de cómo dar soporte al proceso abstracto con la herramienta. Por último, en los ejercicios se debe poner por una parte un enunciado claro del ejercicio y por otra parte la solución a dicho ejercicio. El ejercicio tiene que ser algo concreto y personalizado para el proyecto en cuestión. No valen ejercicios genéricos que valdrían para cualquier proyecto.

Sobre el diario

  • En el diario sería mucho mejor, además de decir cuándo se han tomado las decisiones, añadir qué tiempos y tareas se decidieron y qué imputación en horas real se ha hecho. También, en caso se haber diferencias significativas, se debe hacer un agregado por miembros del grupo y el total de horas imputadas. De no haber diferencias explícitas se considerará que todos los miembros del proyecto han aportado por igual. Si se quieren hacer diferencias, sería conveniente hacer algo parecido a lo hecho por el grupo 7: censos, en el que se desglosa de mutuo acuerdo el grado de implicación en el proyecto. Ver: https://opera.eii.us.es/archivos/egc/entregables/2014-2015/Grupo7/Grupo7Diariodelgrupo7.pdf
  • Si es posible incluir una foto de cada miembro del grupo al lado de su nombre.
  • Pensar en todo momento que el documento debería ser comprensible por otros compañeros vuestros que no hayan hecho el trabajo. En casi todos los casos esto no es así y el documento da por asumidos muchos conocimientos y aún así no pone referencias a dónde buscar más información.
  • En la introducción no se debería describir directamente la funcionalidad del subsistema. Para ello sería mejor tener un apartado propio en el que se defina la funcionalidad del sistema y las interacciones con otros subsistemas.
  • Todas las figuras deben tener una leyenda y deben ser referenciadas y explicadas en el cuerpo del texto del documento.