Conduire un projet
Cours · NSI (première), chapitre 11 · première, spécialité numérique et sciences informatiques · le début du chapitre, la suite sur Adloun
« Une part de l'horaire de l'enseignement d'au moins un quart du total en classe de première doit être réservée à la conception et à l'élaboration de projets conduits par des groupes de deux à quatre élèves. » — Programme de NSI
Un quart de l'année. Ce chapitre n'est donc pas un appendice : il décrit ce à quoi une séance sur quatre est consacrée. Le programme en donne la raison — « un enseignement d'informatique ne saurait se réduire à une présentation de concepts ou de méthodes sans permettre aux élèves de se les approprier en développant des projets applicatifs ».
Les dix chapitres précédents ont fourni les outils. Celui-ci dit comment s'en servir sans que le groupe s'effondre en cours de route.
11.1 Choisir un sujet
Le programme est explicite : « dans la mesure du possible, il convient de laisser le choix du thème du projet aux élèves eux-mêmes ». Un sujet choisi est mené ; un sujet imposé est subi.
Les pistes que cite le programme, à titre d'exemples :
- un approfondissement théorique d'un concept étudié en commun ;
- une application à une autre discipline — simulation d'expérience, traitement de données socio-économiques ;
- un logiciel de lexicographie ;
- un projet autour d'un objet connecté ou d'un robot ;
- une bibliothèque implémentant une structure de données complexe ;
- un problème de traitement d'image ou de son ;
- une application mobile, par exemple de réalité virtuelle ou augmentée ;
- un site Web associé à l'utilisation d'une base de données ;
- la réalisation d'un interprète d'un mini-langage ;
- un programme de jeu de stratégie.
Le programme la nomme sans détour : « les professeurs veillent à ce que les projets restent d'une ambition raisonnable afin de leur permettre d'aboutir ».
Un projet trop grand ne produit pas un demi-résultat : il ne produit rien. Trois quarts d'un jeu ne se jouent pas ; les trois quarts d'un site ne s'ouvrent pas. Mieux vaut un morpion qui fonctionne, se teste et se présente, qu'un jeu de stratégie dont il ne restera que des morceaux.
Méthode : Le test du noyau minimal
Avant de vous engager, écrivez en une phrase ce que fera votre programme dans sa version la plus dépouillée — celle qui, seule, mérite encore d'être montrée. Si cette phrase demande un « et » de plus, c'est déjà trop.
Puis dressez à côté la liste des extensions souhaitables. Elles viendront après, si le temps le permet. Un projet se construit du noyau vers l'extérieur, jamais l'inverse.
11.2 Spécifier avant de coder
Tout le chapitre 3 s'applique, à l'échelle du groupe cette fois. Le document de départ tient en une page et répond à quatre questions.
| Question | Ce qu'on écrit |
|---|---|
| Que fait le programme ? | une phrase, du point de vue de l'utilisateur |
| Quelles données entrent, quelles données sortent ? | formats précis |
| Comment sait-on qu'il marche ? | les cas de test, écrits avant le code |
| Qu'est-ce qui n'en fait pas partie ? | la liste de ce qu'on renonce à faire |
La quatrième ligne est celle qu'on oublie, et c'est la plus utile. Écrire noir sur blanc « le programme ne gère pas plusieurs joueurs en réseau » évite trois semaines de discussions et un abandon en février.
11.3 Découper, répartir, assembler
Un projet à plusieurs ne se découpe pas au hasard : ce sont les interfaces, fixées d'avance, qui permettent à chacun d'avancer sans attendre les autres.
Exercices du chapitre
- Choisir l'une des pistes citées par le programme et en écrire le noyau… corrigé
- Rédiger la fiche de spécification en quatre lignes pour ce sujet, sans… corrigé
- Découper ce sujet en trois ou quatre modules, et donner pour chacun… corrigé
- Pour l'un de ces modules, écrire le jeu de tests avant d'écrire le… corrigé
- Voici la fonction gagnant rendue par un groupe corrigé
- Un groupe présente cette fonction et ses tests corrigé