Mr. Guitton

Pas de réunion cette semaine.

Mr. Strandh

• Revue de code. "Quasiment rien à dire sur le code".



• Le parser est encore expérimental.



• Expliquer dans le mémoire la factorisation de code qui risque de rendre le programme moins lisible.



• Attention de garder le même style pour tout les documents. Utiliser le nous (la forme active est préférable â la passive).
  
  - manuel d'utilisation: Lié au produit et non au projet TER. Expliquer le modèle utilisé et comment les méthodes utilisent ce modèle. Faire une bibliographie sur les termes utilisés, introduire la terminologie. Expliquer les concepts du produit. S'inspirer du manuel d'Emacs. Indexe organisé de façon alphabétique.
  
  - manuel de maintenance: Tout ce que l'on ne peut pas mettre dans le code. Explication des algorithmes. Attention â la répétition. Si il y a des références bibliographiques, ne pas oublier de les y intégrer. On peut y faire des références au manuel utilisateur. Décrire l'architecture du logiciel.
  
  - mémoire: C'est le seul document lié au projet. Expliquer les décisions prises, celles qui n'ont pas été gardées et pourquoi. Dire ce que l'on a appris et comment(exemple de defsystem). Montrer que l'on est ouvert vers l'exterieur (exemple clarification sur un sujet d'un participant de camp.lang.lisp). Parler de l'arbre de décision, c'est celui qui intéresse le plus. On peut faire des références au manuels.
  
  Titre Informatif
  
  Résumé
  
  Table des matières
  
  Introduction (pas refaire le résumé)
  Intro au domaine
  Avantages, inconvénients du langage
  
  Conclusion
  Travaux futures
  Mettre des bilans moins personnels, plutôt axer sur le projet.
  
  Bibliographie
  
  Indexe