Aller au contenu

ELCa11 - Projet : modalités générales


Présentation

Le projet est le pilier du cours Programmation des interfaces graphiques en C++. Réalisé en binôme, il occupe les séances #9 à #16 (cf. déroulé complet) et représente 50 % de la note finale.

Le travail consiste à développer en C++ / QML, sous Qt Creator, une réplique fonctionnelle d’un jeu parmi trois sujets au choix :

Outils requis

Livrables

  1. Dépôt GitLab du projet, accessible aux enseignants :
    • code source à jour, compilable et exécutable ;
    • un fichier README.md à la racine du dépôt, expliquant le sujet, les fonctionnalités implémentées, les éventuelles extensions, et la procédure de compilation/lancement ;
    • un historique Git propre (commits explicites, équilibre raisonnable des contributions des deux binômes).
  2. Soutenance finale lors du BE #8 (séance #16) :
    • démonstration du jeu en live ;
    • explication des choix techniques et de l’architecture ;
    • questions par les enseignants.

Critères d’évaluation

Axe Détails
Fonctionnalités Toutes les fonctionnalités minimales attendues sont implémentées et fonctionnelles. Bonus pour les extensions.
Qualité du code Lisibilité, organisation, commentaires utiles, respect des conventions vues en cours (std::, nullptr, const, etc.).
Architecture Séparation propre logique métier (C++) / interface (QML). Classes bien conçues, encapsulation, réutilisation des patterns vus en BEs (POO, héritage, exceptions).
Interface utilisateur Utilisabilité, retours visuels appropriés (fin de partie, erreurs, score), esthétique soignée.
Démarche collaborative Commits réguliers, messages explicites, équilibre des contributions entre les deux étudiants, gestion correcte des branches/merge requests.
Soutenance Clarté de la présentation, démonstration maîtrisée, qualité des réponses aux questions.

Conseils méthodologiques

  • Commencer petit : viser d’abord un MVP (Minimum Viable Product) — par ex. la grille s’affiche et les mouvements fonctionnent — puis itérer pour ajouter les fonctionnalités complémentaires.
  • Commiter souvent : au moins une fois par séance, idéalement plus. C’est le meilleur filet de sécurité contre les régressions.
  • Séparer la logique de l’interface dès le début. La logique (calcul, état du jeu) se code en C++ ; l’affichage et les interactions se font en QML. Le pont entre les deux est setContextProperty + Q_PROPERTY (cf. tuto correspondant).
  • Tester l’intégration C++/QML très tôt : il vaut mieux découvrir un problème de communication à la séance #9 qu’à la séance #16.
  • Tenir à jour le README.md du dépôt : faites-le grandir au fil des séances, n’attendez pas la veille de la soutenance.
  • Répartition des tâches : ne pas tout faire chacun de son côté. Travailler en pair-programming sur les parties délicates, et faire des relectures croisées via les merge requests GitLab.