Comentarios para mejorar los trabajos 15-16

De Wiki de EGC
Revisión del 13:13 7 ene 2016 de Benavides (discusión | contribuciones) (Sobre la memoria)
Saltar a: navegación, buscar

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 al inicio con control de versiones del documento
  • Poner una página al inicio 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
  • Todas las figuras deben tener una leyenda y deben ser referenciadas y explicadas en el cuerpo del texto del documento.
  • Cuando describa los cambios que ha hecho en el sistema sería bueno resumir dichos cambios de manera general: refactorización, añadir funcionalidades o lo que proceda pero a un alto nivel y luego, si procede, poner una lista con cambios más de bajo nivel que hayan implicados eso cambios de bajo nivel.
  • En muchos casos, los documentos repiten la misma información en varios sitios. En un informe técnico se debe intentar contar las cosas en un solo sitio salvo el resumen, introducción y conclusiones en donde es frecuente repetir información y, en caso de tener que repetir algo para aclarar la lectura del texto se debe poner una referencia al sitio principal donde se dan detalles del asunto en cuestión. Ejemplo: Como se explica en la Sección X.Y, el entorno de desarrollo que se usa en el proyecto es ZZZZ.
  • 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. Hay una confusión generalizada entre usar una herramienta (por ejemplo jenkins o maven) y afirmar que se está siguiendo una aproximación determinada (por ejemplo de construcción automática o integración continua). Las herramientas son medios que dan soporte a un proceso, no son el proceso.
  • Añadir un apartado sobre las mejoras que se proponen para el futuro (curso siguiente) y que no han sido desarrolladas en el sistema actual.
  • Proponer mecanismos automáticos para actualizar el código en el repositorio central. Ejemplo: una tarea jenkings cnd se haga un tag en el repositorio de un equipo.
  • 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.
  • El apartado "resumen" en un documento técnico no suele tener número de sección y suele estar alineado en el centro

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 este ejemplo
  • Si es posible incluir una foto de cada miembro del grupo al lado de su nombre.