Le rapport général
1°/ Objectif
Ce rapport ne sert pas à présenter le résultat mais comment il a été obtenu, sans rentrer dans l'aspect technique. On peut le considérer comme une version détaillée de ce qui sera abordé en soutenance, avec des parties supplémentaires.
2°/ Structure et contenu
2.1°/ Introduction générale
Comme toute introduction, elle doit commencer "large", sans être centrée sur le contexte précis, à savoir la SAE IHM. Vous devez donc éviter de commencer votre rapport par :
"Au cours du second semestre, dans le cadre de la SAE IHM, nous devons implementer un jeu de plateau ..."
Vous devez plutôt axer sur le contexte général du jeu ou des SAE. Par exemple :
"Réaliser un jeu est un désir fréquent parmi les étudiants en informatique. ..." ou bien "Les projets en entreprises reposent souvent sur une équipe et un environnement de développement cadré. C'est d'autant plus vrai avec les jeux qui sont des applications nécessitant une somme de connaissances et compétences importante..."
Après ces quelques lignes de généralités, vous pouvez recentrer sur la SAE IHM et ses objectifs généraux (travail d'équipe, développement objet+graphisme, IA, montée en compétence, ...) puis ses objectifs précis : implémentation d'un jeu de plateau (dire lequel), les types de délivrables, ...
Ensuite, vous devez décrire en quelques lignes votre équipe, ainsi que les motivations à choisir tel ou tel jeu.
Enfin, vous terminez avec la présentation des chapitres qui vont suivre.
2.2°/ présentation du jeu
Cette partie décrit de façon résumée le jeu et ses règles principales, en faisant comme si le lecteur ne connaissait pas le jeu en question.
2.3°/ implémentation et challenges
Il faut décrire comment le jeu et ses règles sont transposés dans votre application, avec une partie donnant les contraintes et une autre partie vos choix.
La partie contrainte est normalement assez courte et la plus facile à présenter, puisqu'elle correspond à tout ce qui vous a été imposé : paradigme MVC, 2 versions : texte & java+javafx, fonctionnalités imposées, etc. Pour chaque contrainte, expliquez en quelques mots en quoi elle consiste, comme si le lecteur ne la connaissait pas.
La partie concernant vos choix doit globalement présenter comment l'utilisateur interagit pour jouer, qu'est-ce qui va se passer à l'écran selon les phases du jeu, etc. De ce fait, vous pouvez recourir à quelques copies d'écran de votre application pour illustrer votre propos.
Ensuite, vous devez décrire quels sont les challenges, au sens informatique, à relever pour transposer le jeu en une application, avec les mécanismes/interactions montrés juste avant. Cette description ne doit pas indiquer comment relever le challenge mais plutôt pourquoi c'est un challenge. Vous devez donc trouver des arguments convaincants. Un exemple : la croissance exponentielle du nombre de situations possibles après X coups rend très difficile l'implémentation d'une IA pour choisir le meilleur coup possible à jouer en temps raisonnable. Autre exemple : l'utilisation d'un framework inconnu.
2.4°/ Organisation du travail
Vous devez décrire grâce à 2 diagrammes commentés le déroulement dans le temps prévu initialement et réel. Attention, il ne s'agit pas de faire des diagrammes de Gantt avec 100 tâches chacun, mais des diagrammes synthétiques présentant les grandes parties du développement. Les commentaires doivent expliquer l'origine des différences et similarité (plus dur !) entre les 2 diagrammes. Par exemple, quand une tâche prend du retard, il y a souvent une explication simple : manque de travail, problème technique suite à des incompréhensions ou un manque de connaissance, etc. De même, quand une tâche est faite à temps, il y a des explications simples : le temps imparti était très large, c'était facile, pas besoin d'acquérir de nouvelles connaissances, etc.
Les commentaires doivent également indiquer qui a fait quoi. Si plusieurs personnes ont été impliquées dans la réalisation d'une partie, vous devez donner les pourcentages personnels d'implication.
2.5°/ Bilan
2.5.1°/ réalisation technique
Une première partie doit clairement faire état de ce qui existe au niveau fonctionnel et graphique, et ce qui manque, notamment par rapport aux règles de base du jeu. Si des bugs connus existent, ils doivent également être mentionnés.
Une seconde partie doit mentionner les principales difficultés techniques rencontrées au cours du projet. Il doit s'agir de difficultés critiques pour l'avancement du projet. Vous devez décrire quels impacts négatifs/positifs ont eu ces difficultés, par exemple en terme de retard, de meilleure compréhension du framework, ... Si vous pouvez décrire sans être technique comment ces difficultés ont été surmontées, c'est encore mieux.
2.5.2°/ connaissances & compétences
Vous devez présenter quelles connaissances et compétences ont été acquises au cours de ce projet, pour le groupe en général, que ce soit au niveau informatique, ou bien communication, rédaction, gestion d'équipe, etc.
NB : une version personnelle de cette partie devra être mise en annexe (cf. 2.7)
2.6°/ Conclusion
Comme toute conclusion, elle commence par faire un mini-résumé des sections précédentes, avant d'ouvrir "vers le futur", comme si le projet allait continuer. Généralement, on aborde :
- quels points doivent être développés en priorité pour rendre l'application meilleure, avec une estimation du temps que cela prendrait,
- quels points mériteraient d'être refaits, et comment ils devraient l'être. Cela peut être aussi bien du point de vue technique que d'organisation.
Vous pouvez également ajouter des remarques plus générales par rapport au fait d'être confronté à ce type de projet ambitieux et exigeant : est-ce que cela a attisé votre curiosité et poussé en avant ? Est-ce qu'au contraire, les attentes vous ont entravé ? etc.
2.7°/ Annexes
2.7.1°/ Glossaire
Lors de la description du jeu, de son implémentation, vous serez sans doute amené à utiliser des termes dont la définition n'est pas triviale. Le glossaire permet de les expliquer. NB : ne pas oublier dans le corps principal de mettre une référence vers le glossaire la première fois que l'on rencontre le terme.
2.7.2°/ Figures
Dans certains cas, les figures sont trop "grandes" pour figurer dans le corps du rapport. D'autres ne sont pas cruciales pour la compréhension mais sont utiles pour mettre en avant des points particulier de la réalisation. Dans ce cas, ces figures peuvent être mises dans cette section, à condition de les référencer comme telles dans le corps du rapport.
2.7.3°/ Etude de cas juridique
L'initiation aux bases du droit abordée en S2 permet une première réflexion sur l'importance du droit dans le monde professionnel. Les différentes questions posées abordent les problématiques de la protection des créations numériques (propriété intellectuelle, droit d'auteur), du respect de la vie privée et de la protection des données personnelles.
Le livrable attendu pour cette annexe est une note d’une page comportant les grands principes du Droit qui s’appliquent à la problématique qui vous a été attribuée.
Il s’agit de proposer les éléments de réponses appropriées dans une rédaction claire, concise et personnelle, sans omettre de de citer toutes les sources utilisées.
2.7.4°/ Auto-évaluation
Cette dernière annexe devra être en autant d'exemplaires qu'il y a de membres dans le groupe de projet.
Contrairement au bilan de groupe présenté en section 2.6, il s'agit d'un bilan personnel que chaque étudiant doit faire, ainsi que les conclusions qu'il en tire.
La partie bilan doit aborder au minimum les points suivants :
- les tâches dans lequel il a été impliqué, et le pourcentage d'implication.
- les connaissances et compétences acquises lors du projet, au niveau informatique, organisation du travail, relationnel, etc.
- les difficultés majeures rencontrées, au niveau informatique, organisation du travail, relationnel, etc.
La partie conclusion n'a pas de contrainte à part qu'elle doit exister. Elle peut par exemple aborder les points suivants :
- les critiques positives/négatives concernant les attentes du projet par rapport à vos attentes, votre niveau personnel, votre façon de travailler, ...
- votre avis sur la pertinence de ce type de projet,
- en quoi ce projet a développé votre curiosité, votre certitude d'être dans le bon cursus, ... ou au contraire a remis en cause vos attentes, votre évaluation de vos capacités, de votre envie d'apprendre l'informatique, etc.
- des suggestions sur l'organisation, le contenu, les contraintes, etc. qui permettraient (au choix) d'aller encore plus loin, d'être moins perdu, d'être plus centré sur ce qui vous intéresse, ...
La soutenance
1°/ Objectifs
La soutenance finale permet de faire un bilan du travail réalisé durant la SAE, ainsi que son organisation, sans rentrer dans les détails techniques informatiques (par ex, comment a été codé telle ou telle partie). Ce bilan sert en partie de préambule à une démonstration, permettant de mettre en avant la qualité du résultat, mais aussi d'exposer les défauts et fonctionnalités manquantes. Enfin, une conclusion est tirée à partir du bilan et de la démonstration.
Cette soutenance se structure donc en 3 parties :
- une série de 8-11 transparents présentant le bilan,
- la démonstration de la version graphique,
- 1-2 transparent de conclusion.
Le tout doit tenir entre 20 et 25 minutes.
2°/ Structuration et contenu
2.1°/ bilan
Excepté le traditionnel transparent de garde (avec un vrai titre, pas du genre "SAE IHM", merci !), le bilan doit contenir :
- 2-3 transparents décrivant le jeu, ses règles principales, et les motivations derrière le choix d'implémenter ce jeu.
- 1 ou 2 transparents résumant l'état fonctionnel : quel pourcentage des règles est implémenté ? Est-ce qu'il y a des règles/fonctionnalités optionnelles en plus par rapport au jeu de base ? Quels sont les fonctionnalités manquantes ? etc.
- 2 transparents résumant chacun les principes des stratégies implémentées dans les IA et en quoi elles sont pertinentes, quelle efficacité/performance elles ont, etc. NB : s'il est possible de prouver ces remarques lors de la démonstration, faîtes-le.
- 2 transparents résumant l'organisation du travail :
- quand : résumé sous forme de 2 diagrammes, des phases principales du projet dans le temps. Un diagramme pour ce qui était prévu, et un pour ce qui s'est réellement passé, avec les commentaires expliquant le pourquoi de la différence. ATTENTION : les diagrammes doivent être SYNTHETIQUES (= pas un Gantt avec 100 tâches)
- qui a fait quoi et pourquoi (par affinité ? compétence ? curiosité ? ...)
- 1 transparent résumant les principales difficultés rencontrées lors du projet, du point de vue technique, humain, organisation, ... et quels impacts (positifs et/ou négatifs) elles ont eu sur l'avancement du projet.
- NB 1 : n'abordez que des problèmes "critiques" donc ceux qui ont eu un impact sur les fonctionnalités générales. Si vous avez perdu une semaine pour trouver comment positionner au pixel près un jeton, ce n'est pas critique (et c'est stupide). Si vous avez perdu une semaine pour comprendre comment gérer le déplacement des pions avec boardifier, c'est critique.
- NB 2 : des difficultés peuvent avoir dans un premier temps un impact négatif, mais une fois surmontées, permettre de travailler plus efficacement, donc impact positif.
- 1 transparent résumant les connaissances et compétences acquises au cours de ce projet, pour le groupe en général et pas en individuel.
Compte tenu du nombre de transparents, ce bilan ne doit pas durer plus de 10 minutes.
ATTENTION ! En aucun cas, vous ne devez présenter/expliquer le moindre bout de code dans ces transparents, notamment ceux qui présentent l'IA ou les difficultés rencontrées.
2.2°/ Démonstration de la version graphique
La démonstration dure au maximum 10 minutes. Vous devez "vendre" votre produit non pas à un client potentiel, mais plutôt à un chef de projet, qui est là pour juger de vos capacités à produire un résultat conforme aux attentes, voire qui dépasse celles-ci. Donc quel que soit l'état de complétude votre jeu (de pas jouable à complètement fini), vous démonstration doit surtout mettre en avant les points marquants de votre réalisation et les capacités qui ont permis de la créer. En revanche, votre démonstration doit également être "honnête" et permettre de constater quels sont les points manquants, pas finis, etc.
C'est pourquoi la démonstration doit permettre entre autre à l'auditoire :
- de voir les différentes façons de faire une partie (avec ou sans joueur ordinateur),
- de vérifier si les fonctionnalités présentées dans le bilan sont effectivement finies ou manquantes,
- d'évaluer la jouabilité réelle du jeu, son ergonomie, ...
- de mettre en valeur un ou deux points de règle plus complexes à gérer, afin de prouver qu'ils ont justement été pris en compte correctement ... ou pas,
- si possible de constater la bonne détection d'une fin de partie,
- si possible d'évaluer si les IA font bien ce qui a été exposé dans le bilan.
Remarque : pour les 3 derniers points, il est fortement conseillé de mettre en place un cheat-mode, par exemple avec une touche du clavier, en lançant une partie avec les pions déjà posés à certains endroits, etc.
2.3°/ Conclusion
Les 1-2 transparents de conclusion doivent être ... une conclusion et non pas une simple redite du bilan (= ce que font les étudiants en général).
Vous devez effectivement faire un micro-résumé de l'état de votre projet, mais ensuite, vous devez "ouvrir" votre propos, c'est-à-dire vous projeter dans le futur du projet, s'il existait. Pour cela, vous pouvez vous baser sur deux questions typiquement abordées dans une conclusion :
- en priorité, que faut-il ajouter au projet pour le rendre, selon le cas, plus attractif, complètement fonctionnel, jouable, ... et combien de temps cela pourrait prendre à coder ?
- qu'est-ce que vous changeriez si vous deviez refaire le projet, du point de vue organisation, apprentissage, technique, ... ?