Règlement des Projets Génie Informatique
Vous devrez avoir lu le présent règlement, et constitué votre binôme AVANT la première séance de TP du mercredi 16 juin 2021.
Temps de lecture : environ 20 minutes.
Version du 15/06/2021.
1 • Modalités d'organisation des projets
- Le projet se déroule sur 13 jours, du mercredi 16 juin au vendredi 25 juin 2021, avec rendu le lundi 28 juin 2021.
- Le travail s'effectue en binôme (des monômes seront autorisés si nécessaire, les trinômes seront refusés).
1.1 Objectif général
L'objectif du projet est de produire un logiciel écrit en langage C et contrôlé par une interface graphique GTK+.
1.2 Objectif pédagogique
Ce module s'inscrit dans la continuité du module « Algorithmique et Programmation » et est l'aboutissement de votre apprentissage de la programmation informatique en 1re année. Il doit permettre, en condition projet, de réappliquer et de mettre en œuvre de manière plus autonome les compétences vues précédemment en cours : le langage C, les fonctions, la bibliothèque graphique GTK+ et les environnements de développement Eclipse ou Visual Studio. Au-delà d'être capable de programmer, une compétence importante doit continuer d'être murie : être capable d'utiliser une documentation, que ce soit pour les fonctions du langage C ou pour les fonctions de GTK+.
Le projet est l'occasion de progresser encore en programmation avant la 2e année afin de pouvoir y appréhender sereinement de nouvelles notions telles que :
- Modélisation de programmes ;
- Programmation Orientée Objet ;
- Programmation de scripts ;
- Programmation de cartes électroniques ;
- Programmation de robots ;
- Programmation d'interfaces graphiques JavaFX / Android.
Avoir programmé plusieurs projets est un passage nécessaire pour tout informaticien. Les petites fonctions de quelques dizaines de lignes que vous avez programmé pour l'instant est un début mais reste insuffisant. Pour aborder sereinement le génie logiciel, il faut ensuite programmer des petits programmes (environ 500 à 2000 lignes et une dizaine de fonctions) sur quelques semaines, puis des programmes plus conséquents (environ 5.000 à 10.000 lignes et une centaine de fonctions) pendant des stages, et enfin intervenir sur des logiciels existants (environ 50.000 à 100.000 lignes) en mission d'entreprise ou sur des logiciels libres.
1.3 Recette
La recette de votre projet comprendra les trois rendus suivants à déposer sur la plateforme moodle1a.estia.fr :
- Rapport : document PDF entre 4 et 8 pages (ne pas compter la page de garde)
- Code source : archive ZIP du projet avec exécutable déjà compilé
- Vidéo de démonstration : vidéo MP4 de 1 à 4 minutes (20 Mo maximum)
Attention, les noms des trois livrables devront être formatés comme suit :
T-S_NOM1_Prenom1_NOM2_Prenom2.pdf
T-S_NOM1_Prenom1_NOM2_Prenom2.zip
T-S_NOM1_Prenom1_NOM2_Prenom2.mp4
où :
T
est le numéro du thème choisiS
est le numéro du sujet choisiNOM1
est le nom en majuscules du premier membre du binôme, sans espaces (remplacer par un tiret si nécessaire) et sans caractères accentuésPrenom1
est le prénom du premier membre du binôme, sans espaces (remplacer par un tiret si nécessaire) et sans caractères accentuésNOM2
est le nom en majuscules du deuxième membre du binôme, sans espaces (remplacer par un tiret si nécessaire) et sans caractères accentuésPrenom2
est le prénom du deuxième membre du binôme, sans espaces (remplacer par un tiret si nécessaire) et sans caractères accentués
Par exemple :
2-1_ARTZAMENDI_Elorri_IZPEGUY-IPARLA_Peio.pdf
2-1_ARTZAMENDI_Elorri_IZPEGUY-IPARLA_Peio.zip
2-1_ARTZAMENDI_Elorri_IZPEGUY-IPARLA_Peio.mp4
1.3.1 Le rapport
Votre rapport comptera entre 4 et 8 pages (la page de garde ne compte pas) afin de présenter les éléments suivants :
- Conception de l'interface
- Explication des fonctionnalités proposées et de la finalité du logiciel
- Croquis de l'interface
- Organisation de l'interface : hiérarchie et placement des composants
- Réutilisation des composants déjà vus en TP : Window, HBox, VBox, Grid, Frame, Label, Entry, SpinButton, HScale, VScale, RadioButton, Image
- Utilisation d'autres composants à partir de la documentation : MenuBar, Notebook, CheckButton, ComboBox, …
- Manuel utilisateur (avec captures d'écran)
- Explications des étapes pour utiliser le logiciel (valeurs à saisir, boutons à cliquer, …)
- Métriques (nombre de lignes de code : SLOC, % CLOC, % BLOC ; nombre de fichiers ; nombre de fonctions ; nombre de types structurés)
- En informatique, il n’est pas toujours facile de rendre compte du travail effectué (ex. soutenances de stages). Le but est de donner une idée du travail accompli.
- Les métriques (pour le projet et par fichier) aident à donner une idée de la taille du projet.
- Outils de calcul automatique
- Inutile de compter à la main, il existe des outils de calcul de métriques
- Par exemple : cncc
- Compilation de l'utilitaire : g++ cncc.cpp -o cncc.exe
- Utilisation : cncc.exe main.c callbacks.c callbacks.h
- Utilisation sur tous les fichiers d'un projet : cncc.exe *.c *.h
- Explication de parties de code choisies
- Si une fonction est particulièrement intéressante, a demandé beaucoup d’effort, ou mérite des explications pour la comprendre.
- Bilan de ce que vous avez appris et des difficultés rencontrées
- Quelles leçons retenez-vous du travail accompli ?
1.3.2 Le code source
L'archive contiendra un seul sous-répertoire appelé code_source qui devra contenir tous les fichiers, par exemple :
- code_source
- main.c
- callbacks.c
- callbacks.h
- interface.glade
- image1.jpg
- parametres.txt
- projet.exe
1.3.3 La vidéo de démonstration
Votre vidéo de démonstration devra faire état du bon fonctionnement de votre logiciel. En plus de présenter les fonctionnalités disponibles, ellse devra montrer que celles-ci fonctionnent correctement. Le bon fonctionnement des éventuelles fonctionnalités additionnelles devra aussi être montré (export, rechargement des valeurs, …).
Pour rester lisible, la qualité de l'image doit être à l'échelle 1:1 (c.-à-d. pas de rétrécissement de la résolution). La capture d'écran doit être faîte avec un outil de qualité dédié à cet usage. Les vidéos capturées au téléphone, caméra de sport, … sont proscrites.
Nous déconseillons les logiciels movavi, apowersoft, … qui incrustent une annonce sur la vidéo.
Nous recommandons l'outil de capture d'écran « VokoscreenNG » installé sur votre PC.
Quelques astuces :
- Pour obtenir une vidéo de taille raisonnable, capturez uniquement une zone de l'écran et diminuez le nombre de trames par secondes (Frame Rate) à 10 fps.
- Activez la capture du micro pour commentez votre démonstration.
- Préférez le conteneur MP4 avec le codec vidéo X264 et le codec audio MP3.
- Vérifiez la qualité de vos vidéos avec un lecteur (ex. VLC) et vérifiez que la lecture est correcte avant de rendre le fichier définitif.
1.4 Évaluation des projets
Pour valider le projet, les conditions suivantes doivent être respectées :
- Un programme qui répond au niveau minimal (cf. attentes).
- Un programme qui compile, s'exécute et fonctionne correctement.
- Livraison le lundi 28 juin 2021 :
- du rapport, avec au minimum 4 pages pleines (ne pas compter la page de garde),
- du code source et du fichier exécutable.
- Livraison le mercredi 30 juin 2021 de la vidéo de démonstration (format MP4).
Le grade sera fonction du niveau du programme rendu, de la complétude du rapport et de qualité la démonstration en vidéo.
Un projet incomplet (sans code source, sans rapport, ou sans vidéo) entrainera un F. Un projet qui ne fonctionne pas (sans au moins une des fonctionnalités) entrainera un F.
1.4.1 Modalités de rattrapage
Si vous n'êtes pas en mesure de livrer un projet répondant aux exigences minimales à la date butoir (Session 1), vous disposerez alors automatiquement d'un délai de 10 jours pour terminer votre projet et livrer la version définitive (Session 2) le lundi 5 juillet 2021 : mais vous ne prétendrez alors plus qu'au grade E. Si le projet livré en session 2 ne répond pas aux exigences minimales, le grade F sera automatiquement appliqué.
1.5 Calendrier
Les jalons et échéances des projets :
- mer. 16 juin : 2h TP1
- mer. 16 juin : 2h T.Perso
- jeu. 17 juin : 2h T.Perso
- lun. 21 juin : 2h TP2
- lun. 21 juin : 2h T.Perso
- mer. 23 juin : 2h T.Perso
- jeu. 24 juin : 2h TP3
- ven. 25 juin : 2h T.Perso
- Session 1
- lun. 28 juin : fin des projets et dépôt de la recette
- mer. 30 juin : dépôt de la vidéo (au plus tard)
- Session 2
- lun. 5 juillet : dépôt de la recette complète (rapport, code source avec exécutable et vidéo de démonstration)
1.6 Les séances de travail personnel
Ce temps est prévu dans votre planning pour faire avancer le projet. Des salles sont réservées au planning pour vous accueillir dans le bâtiment pendant ces heures, mais sans enseignants présents dans les salles.
En cas de besoin, pendant ces séances, les enseignants suivants seront d'astreinte à leur bureau ou sinon sur Teams pour débloquer votre programme et vous permettre de poursuivre l'avancement de votre projet :
- M. BAKNI (bureau Ikasi, dernier étage, bât. 2)
- M. DANIEL (Bureau 203, dernier étage, bât. 2)
- M. DELAMARE (bureau 205, dernier étage, bât. 2)
- M. MASSON (bureau 204, dernier étage, bât. 2)
- M. RIVIÈRE (bureau 211, dernier étage, bât. 2)
Profitez de ce temps pour travailler le plus possible et préparer vos questions pour les TP №2 et №3.
2 • Développement du programme
2.1 Attentes pour le programme
Nous attendons comme livraison du projet un programme « simple » qui proposera :
- Des paramètres en entrée, modifiables par curseur et bouton incrément (cf. TP2 de DRI)
- Des valeurs de sortie, réactualisées quand les paramètres d'entrée varient (cf. TP3 de DRI, version 1)
- Des fonctionnalités de commodité (cf. TP3 de DRI, version 2), comme :
- Exporter les valeurs dans un format exploitable (ex. : CSV)
- Recharger les valeurs de la dernière exécution
Afin de ne pas vous engager dans des programmes disproportionnés (et risquer de ne pas aboutir, au vu du temps imparti), vous devrez vous en tenir aux sujets éligibles qui sont présentés dans la suite. Ces sujets permettent de cadrer le travail, mais les spécifications restent cependant suffisamment succinctes pour que vous puissiez l’interpréter à votre envie et exprimer votre inventivité.
Bonus : Porter soin à l'ergonomie (ex. : nombre d’actions pour obtenir un résultat) et à l'utilisabilité de l'interface peut également permettre d'accroître votre grade (ex. : faire tester votre conception à quelques utilisateurs pour valider vos choix et rendre compte de l’étude dans votre rapport).
2.1.1 Un projet simple, mais pas simpliste (sinon Grade F)
Un projet trop simpliste reflètera un travail insuffisant et ne sera pas accepté.
Par exemple, ceci ne sera pas suffisant :
Solutions pour mieux traiter le sujet que vous avez retenu :
- N'auriez-vous pas choisi de traiter le sujet de manière trop minimaliste ? Réfléchissez donc à rendre votre programme réellement utilisable pour résoudre un vrai problème et répondre à un vrai besoin utilisateur.
- Réfléchissez à élaborer votre interface pour ajouter de nouvelles commodités (ex. : coupler un HScale/VScale avec un SpinButton pour les entrées). Ajoutez de nouvelles fonctionnalités. Demandez vous quels autres paramètres pourraient entrer en compte dans le calcul.
2.1.2 Niveau minimal (Grades E / D / C)
Votre projet doit proposer plusieurs paramètres pouvant varier et afficher des informations en conséquence.
Par exemple, ceci serait accepté :
2.1.3 Niveaux supérieurs (Grades C / B / A)
Un projet plus élaboré permettra de prétendre aux grades supérieurs :
- Fonction d'exportation (cf. TP3 de DRI, version 2)
- Fichier de sauvegarde (cf. TP3 de DRI, version 2)
- Options activables (cf. TP3 de DRI, version 3)
- Création dynamique de widgets (cf. TP3 de DRI, version 4)
- Utilisation appropriée de widgets évolués (cf. aide : dessin pixel sur GtkImage, grille d’images avec GtkTable, signaux du clavier, listes déroulantes avec GtkComboBox, dessin de primitives avec GtkDrawingArea, …)
2.2 Choix de thème et de sujet
Vous devez choisir votre sujet parmi les sujets proposés. Les sujets sont organisés en cinq thèmes représentatifs des thématiques de l'ingénieur ESTIA : T1. Gestion Industrielle, T2. Électronique, T3. Robotique, T4. Mécanique et T5. Informatique. Pour chaque thème, un ou deux sujets sont proposés. Ce cadre offre une certaine liberté, car une fois la contrainte du sujet respectée, vous être libre d'interpréter et d'adapter le sujet à vos envies, à vos expériences passées, ou à votre ambition en fonction du temps que vous souhaitez consacrer.
En revanche, les sujets libres ne sont pas acceptés, pour des raisons variées. D'une part, lors de votre vie professionnelle, vous devrez le plus souvent répondre à un besoin défini par votre client ou par les utilisateurs ciblés. D'autre part, cela vous évite de faire des choix de sujets disproportionnés au vu du temps imparti : peut s'avérer très dangereux pour votre grade final ! Enfin, cela évite de céder à la tentation de recopier des projets existants qui abondent sur Internet.
2.3 Outils de développement
Pour développer votre projet, vous avez le choix des outils suivants :
- Pour dessiner l'interface graphique : Glade 3.8
- Pour écrire et compiler le code source (au choix) :
- Notepad++ / GCC / Makefile
- VisualStudio / VC++
- Eclipse CDT / GCC
2.4 Langages et bibliothèques
Attention de vous conformer aux contraintes techniques suivantes :
- Seul langage accepté : C ANSI
- C99, C++, C#, Objective C, Swift
- Visual Basic
- Java
- PHP, Python
- …
- Seule bibliothèque acceptée : GTK+ 2.0
- GTKmm, PyGTK, Qt, MFC, Tcl/Tk
- SDL, OpenGL
- OpenCV, Gandalf
- …
2.5 Recommandations
Quelques conseils pour bien mener votre projet à son terme :
- Compilez votre programme au fur et à mesure de son avancement
- N'attendez pas d'avoir écrit des centaines de lignes de codes avant de tenter une compilation ! Sinon, vous allez vous noyer dans plusieurs dizaines d'erreurs à corriger toutes en même temps (sans même savoir que certaines sont provoquées par d'autres…).
- Commencez toujours par les premières erreurs (c.-à-d. celles affichées en premier) en remontant avec l'ascenseur de la fenêtre. Car les erreurs suivantes peuvent être des « fausses erreurs » engendrées en cascade par les premières « vraies erreurs ». Une fois quelques erreurs corrigées, tentez une nouvelle compilation et continuez en corrigeant les premières erreurs qui apparaissent.
- Outre la compilation, il faut aussi tester chaque fonctionnalité au fur et à mesure. Les tests unitaires consistent à tester indépendamment que chaque fonction est correcte avant de l'appeler avec les autres fonctions.
- Faîtes régulièrement des sauvegardes !!!
- Deux choses arrivent très souvent : i) supprimer des fichiers par mégarde, ii) obtenir un programme complètement instable après seulement quelques petites modifications dont vous ne retrouvez pas la trace.
- Il est primordial de créer des sauvegardes de votre code source, en créant des archives ZIP numérotées, au fur et à mesure de l'avancement du projet. C'est ce que nous appelons le développement incrémental. (ex. : mon_projet-0.01.zip, mon_projet-0.02.zip, …)
- Dès que j'obtiens une version majeure (c.-à-d. suite à un gros effort de développement) ou une version stable (c.-à-d. qui compile et qui fonctionne correctement), alors je change de numéro de version ou j'indique « stable » dans le nom de l'archive. (ex : mon_projet-1.01.zip ou mon_projet-1.10--stable.zip)
- Ne vous y prennez pas au dernier moment !
- La conception, le développement, les recherches dans la documentation, le debuggage, ou encore les tests, exigent de la réflexion et prennent du temps.
- Ne vous laissez pas surprendre, commencez votre projet dès maintenant.
2.5.1 Gestion du temps
L'effort de développement prévu au planning est de :
- Temps : 6h TP + 10h T.Perso = 16h = 2 jours
- Effort : 2 jours x 2H = 4 jours-homme
Attention cependant de ne pas prendre cette mesure comme une absolue vérité pour estimer le coût d'un logiciel : Le Mythe du mois-homme
2.6 Foire aux questions
Le plus souvent, vous faîtes les mêmes erreurs. En cas de problème, attention de vérifier les points suivants :
- Nom du fichier glade : vérifiez la cohérence entre le nom du fichier présent sur votre disque dur et le nom utilisé dans votre fonction main().
- De nombreux messages d'erreur apparaissent lors de l'exécution : vérifiez les noms des widgets entre ce que vous avez saisi dans Glade et ce que vous avez écrit dans votre code.
- Comparaison des chaînes de caractères : attention d'utiliser les fonctions adéquates pour faire ce travail : strcmp() ou, avec Visual Studio, strcmp_s()
- Impossible de changer la valeur d'un spinbutton ou d'un hscale: : i) vérifier que vous les avez initialisés dans la fonction realize de la fenêtre. ii) vérifier dans Glade que vous avez bien connecté cette fonction realize au signal realize de la fenêtre.
Remarque : cette liste à vocation à s'étoffer au fil du temps.