Partie 3: Avancement de chaque module de travail

idée numéro 1:
le compte rendu de réunion:
Le rapport etait une liste d'objectif que l'on se fixais pour chaque nouvelles réunion (toutes les semaines en moyennes).
Après chaque réunions nous avons fait un rapport pour pouvoir ciblé notre travail et avoir une marque de notre avancement global du projet. En effet, apres mise en commun de l'avancement des differents modules, nous avons à chaque fois créer des debat sur le codage, les fonctions pour pouvoir optimiser le code et le rapport à permit au chef de modules de donner des objectifs (bienvenu chez mitholand) pour chaque semaine.
Mais une partie de notre compte rendu de réunion, noté aussi les objectif atteind à ne plus modifier.
A completer
idée numéro 2:
Mise en commun du code:
A chaque réunion nous procedons aussi à une suite de test pour savoir si notre code étais bon:
phase de codage, puis phase de test et si erreur on recommance, avec l'appui du rapport pour ne pas effectuer les même erreurs 2 fois.
La phase de test se resume en la mise en commun des different module et des test de leur compatibilité.
A compléter (en expliquant exactement les mise en communs, les difficulté, les choix pour compatibilité, des exemples de problèmes, bref fo balancer bcp la).

je complete

La phase de test se resume en la mise en commun des different module et des test de leur compatibilité.
chaque equipe qui s'occupait des parties du projet, (structure, gestion du fichier binaire, et de l'interface graphique et les liens avec le noyau)
le probleme etant que les interfaces graphiques avec Qt n'est pas tres facile a manipuler (hein nico), il fallait donc partir sur une base solide et extensible au cas où il y aurait des nouvelles fonctionnalités a implementer, chose faite, nous avons donc pris le choix de structurer nos classe sous la forme suivante, une structure de chaque fichier (un fichier structure, et un fichier binaire qui contient les données), un noyau, celui qui gere effectue toutes les fonctions de modifications sur les fichiers, ensuite une interface graphique pour piloter et executer toutes ces fonctions. Il fallait donc bien documenter chaque nouvelle fonctionnalité ajoutée pour qu'elle sera utilisée sans erreur de manipulation (depuis l'interface graphique), a chaque reunion, si quelqu'un avait realisé une nouvelle fonction, il presentait comment elle fonctionne, dans quel cas faut faire attention (cas particuliers) et ensuite debattre s'il y a un moyen de faire autrement, plus simple et plus efficace, (ce furent de longs debats
lors des reunions). le rythme etait parfois tres soutenu, et parfois rien (bein ouai xD) c'est pourquoi que la communication etait indispensanble (ailleur que lors des reunions) nous avons donc mis en place un serveur SVN pour mise en commun des codes, et un forum pour discuter des modifications effectuée (un forum tres actif, lol c pour ça qu'il y a un BBactic dans le lien) en separant biensur le projet en 2 principales parties.
la partie interface graphique (GUI) et une partie noyau (BDD) donc la GUI reprenait petit a petit les nouvelles fonctions recemment implementées dans le noyau, en les adaptant biensur et ameliorant (oui oui nico et chris on fait leur boulot "et boulets")... a completer...