Guillaume Rivière 2018 – 2019

Le logo de la CCI Bayonne Pays Basque

Projets Génie Informatique

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 lundi 27 mai 2019.

Temps de lecture : environ 20 minutes.

Version du 24/05/2019.

1 • Modalités d'organisation des projets

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 :

Avoir programmé plusieurs projets est un passage nécessaire pour tout informaticien. Savoir programmer des petites fonctions de quelques dizaines de lignes 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 :

  1. Rapport : document PDF entre 4 et 8 pages (ne pas compter la page de garde)
  2. Code source : archive ZIP du projet avec exécutable déjà compilé
  3. Vidéo de démonstration : vidéo FLV de 1 à 4 minutes (20 Mo maximum)

Attention, les noms des trois livrables devront être formatés comme suit :

  1. T-S_NOM1_Prenom1_NOM2_Prenom2.pdf
  2. T-S_NOM1_Prenom1_NOM2_Prenom2.zip
  3. T-S_NOM1_Prenom1_NOM2_Prenom2.flv

où :

Par exemple :

Si vous ne pouvez pas respecter ce format, la grande plage de Bidart recherche des trieurs de grains de sable. Postulez et cessez de perdre votre temps ici.

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 :

  1. 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, …
  2. Manuel utilisateur (avec captures d'écran)
    • Explications des étapes pour utiliser le logiciel (valeurs à saisir, boutons à cliquer, …)
  3. 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
  4. 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.
  5. 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 :

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 « BB FlashBack Express » dont l'exécutable est à disposition sur le disque réseau "COURS" :
I:\G.RIVIERE\1A_Projet_Genie_Informatique\

Le logiciel « BB FlashBack Express » est composé de deux outils :

La fenêtre de paramétrage et lancement de la capture vidéo de BB FlashBack Express
Figure 1.3.1 : Recorder.
La fenêtre de BB FlashBack Express pour lire et exporter la vidéo capturée en FBR
Figure 1.3.2 : Player.

L'outil de capture (Recorder) permet de capturer une zone de l'écran, le déplacement de la souris et le son du microphone. Le fichier obtenu est au format FBR.

L'outil de lecture et d'export (Player) permet de lire le fichier FBR et d'exporter au format FLV. Pour réduire la taille du fichier, diminuez le nombre de trames par secondes (Frame Rate) à 5 fps : File > Export > FLV > General > Frame Rate

Vérifiez avec un lecteur de vidéo (ex. VLC) que la lecture de votre fichier FLV est correcte.

1.4 Évaluation des projets

Pour valider le projet, les conditions suivantes doivent être respectées :

  1. Un programme qui répond au niveau minimal (cf. attentes).
  2. Un programme qui compile, s'exécute et fonctionne correctement.
  3. Livraison le vendredi 21 juin 2019 :
    • du rapport, avec au minimum 4 pages pleines (ne pas compter la page de garde),
    • du code source et du fichier exécutable.
  4. Livraison le lundi 24 juin 2019 de la vidéo de démonstration (format FLV).

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 vendredi 5 juillet 2019 : 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 :

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 pour débloquer votre programme et vous permettre de poursuivre l'avancement de votre projet :

Profitez de ce temps pour travailler le plus possible et préparer vos questions pour le TP №3.

2 • Développement du programme

2.1 Attentes pour le programme

Nous attendons comme livraison du projet un programme « simple » qui proposera :

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 :

La fenêtre du programme simple d'addition fait au premier TP
Figure 2.1.1 : TP1 de DRI.
La fenêtre du programme simple de calcul de pourcentages fait au premier TP
Figure 2.1.2 : TP1 de DRI.
La fenêtre du programme simple de couplage de widgets fait au deuxième TP
Figure 2.1.3 : TP2 de DRI.

Solutions pour mieux traiter le sujet que vous avez retenu :

  1. 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.
  2. 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é :

La fenêtre de la première version du programme de flexion de poutre
Figure 2.1.4 : TP3 de DRI, version 1.

2.1.3 Niveaux supérieurs (Grades C / B / A)

Un projet plus élaboré permettra de prétendre aux grades supérieurs :

La fenêtre de la dernière version du programme de flexion de poutre
Figure 2.1.5 : TP3 de DRI, version 4.

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 :

2.4 Langages et bibliothèques

Attention de vous conformer aux contraintes techniques suivantes :

2.5 Recommandations

Quelques conseils pour bien mener votre projet à son terme :

  1. 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.
  2. 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)
  3. 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 :

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 :

  1. 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().
  2. 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.
  3. 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()
  4. 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.