Développement créatif

En 1999, la NASA a perdu la sonde Mars Climate Orbiter, qui avait coûté bien plus de cent millions de dollars. Le code n’était pas mal écrit. Le logiciel d’une équipe fournissait ses nombres en unités américaines, tandis que celui d’une autre équipe les interprétait comme des unités métriques. Chaque élément fonctionnait seul ; la défaillance se situait dans la coordination entre les personnes. Cette unité porte sur la façon dont les programmes sont réellement créés : en groupe, pour des utilisateurs, par cycles répétés, en détectant et en corrigeant les erreurs au fur et à mesure.

L'informatique est une activité collaborative. Travailler en équipe apporte plus de perspectives, détecte plus d'erreurs et produit de meilleurs programmes que le travail individuel. Une bonne collaboration repose sur la construction du consensus, une communication claire et l'utilisation des forces de chaque membre. La programmation en binôme – deux personnes devant un seul ordinateur, l'un tapant et l'autre relisant – est une pratique courante. Aux examens, vous devrez pouvoir expliquer comment la collaboration a amélioré un programme (plus d'idées, moins de bugs, tests plus larges).

Une innovation informatique est toute nouveauté dont un programme constitue une partie essentielle. Elle peut être matérielle (une voiture autonome), logicielle (un logiciel de retouche photo) ou conceptuelle (les achats en ligne). Lorsqu’une question mentionne une « innovation informatique », chacun de ces trois types convient.

Pourquoi la diversité des personnes compte. Des personnes aux parcours différents remarquent des problèmes différents. Une équipe qui réunit des points de vue variés est plus susceptible d’éviter les biais, car quelqu’un demandera « qu’en est-il des utilisateurs comme moi ? ». Les développeurs échangent aussi directement avec les utilisateurs : leurs propos aident l’équipe à comprendre à quoi sert le programme et pour qui il doit fonctionner.

Compétences et outils. Les bonnes équipes pratiquent la communication, la recherche de consensus, la résolution des conflits et la négociation. Des outils en ligne comme les documents partagés et les dépôts de code partagés permettent de donner des retours depuis n’importe où.

Exemple résolu. Deux élèves construisent une application de quiz. Mei écrit la procédure de notation tandis que Tom relit chaque ligne au fur et à mesure qu'elle tape ; plus tard, Tom demande à cinq camarades de tester l'application, et deux d'entre eux constatent qu'une réponse vide provoque un plantage. Comment la collaboration a-t-elle aidé ?

1. Tom vérifie le code à mesure qu’il est saisi (programmation en binôme), ce qui peut permettre de détecter les erreurs tôt.
2. Les camarades de classe sont des utilisateurs avec des habitudes différentes ; leurs tests ont révélé un cas que ni l'un ni l'autre programmeur n'avait envisagé, la réponse vide.
3. Chaque avantage est nommé et lié au programme : « plus d'essayeurs ont détecté le crash à réponse vide » rapporte un crédit là où « le travail d'équipe est bon » ne le fait pas.

Exemple corrigé : un désaccord. Deux membres d’une équipe ne sont pas d’accord : Sara souhaite un chronomètre pour chaque question du quiz, tandis que Li estime qu’un chronomètre inquiétera les utilisateurs nerveux. Quelle est la meilleure prochaine étape ?

• Sara et Li votent et la personne qui perd cède : c’est rapide, mais les utilisateurs ne sont pas pris en compte.
• Chacun crée sa propre version sans jamais la partager : l’équipe se divise.
• Ils interrogent des utilisateurs, puis conviennent ensemble d’une règle, par exemple un chronomètre que les utilisateurs peuvent désactiver.

La troisième solution est une recherche de consensus : la décision repose sur des éléments concrets et les deux personnes l’acceptent.

Chaque programme est écrit pour un but précis – il résout un problème ou répond à un intérêt. Un programme prend une entrée, la traite et produit une sortie. Les entrées peuvent provenir d'un utilisateur, d'un appareil, d'un fichier ou d'un autre programme ; les sorties peuvent être visuelles, sonores, textuelles ou un signal envoyé à un appareil. Savoir énoncer clairement le but d'un programme et décrire ses entrées et sorties est une compétence fondamentale (et fait partie de la tâche de création).

Quelques termes employés précisément dans l’examen :

• Un programme (aussi appelé logiciel) est un ensemble d’instructions qui accomplit une tâche lorsqu’un ordinateur l’exécute. Un segment de code est une partie d’un programme.
• Le comportement d’un programme correspond à la façon dont il agit pendant son exécution ; il est généralement décrit par la manière dont un utilisateur interagit avec lui.
• Les entrées comme les sorties peuvent être tactiles (toucher, vibration), audio, visuelles ou textuelles.
• Les sorties dépendent généralement des entrées et peuvent aussi dépendre de l’état antérieur : les valeurs déjà détenues par le programme.

Vous pouvez décrire un programme de manière générale (ce qu’il fait) ou plus détaillée (ce qu’il fait et comment ses instructions le font). Une réponse écrite exige généralement la seconde approche.

Exemple corrigé. Une application de comptage de pas lit les mouvements captés par le capteur de mouvement du téléphone, compte les pas et affiche le total du jour ainsi qu’un badge lorsque l’utilisateur atteint 10,000.

Le badge montre aussi l’état antérieur à l’œuvre : une même entrée correspondant à un pas ne donne un badge que si le total enregistré vient d’atteindre l’objectif.

Une erreur fréquente consiste à confondre la fonctionnalité avec la finalité : dire « il compte les pas » indique ce que fait le programme, pas le problème qu'il résout.

Les programmes se construisent selon un processus itératif, et non linéairement : explorer le problème et les utilisateurs, concevoir (souvent avec un diagramme ou un plan écrit), implémenter en code, puis tester — et répéter. Un problème complexe est décomposé en sous-parties (décomposition). Les commentaires et une nommentation claire documentent la conception afin que d'autres (et votre futur moi) puissent la comprendre. Le développement est incrémental : on construit et teste une petite partie, puis on ajoute la suivante.

Les phases courantes comprennent l’étude et la réflexion, la conception, la création d’un prototype (un premier modèle fonctionnel) et les tests. L’ordre peut être planifié à l’avance ou plus exploratoire, et une équipe peut revenir à une phase précédente à tout moment.

Exemple corrigé : itératif ou incrémental ? Les deux mots se ressemblent et l’examen les distingue.

Un projet réel combine généralement les deux approches.

Enquêter sur ce dont les utilisateurs ont réellement besoin

Avant d’écrire du code, le développeur étudie le problème et les personnes qui utiliseront le programme. Voici un moyen de le faire :

• des enquêtes envoyées aux utilisateurs potentiels, qui collectent rapidement des données auprès de nombreuses personnes;
• des entretiens et une observation directe des utilisateurs effectuant la tâche manuellement;
• les tests utilisateurs, au cours desquels des personnes essaient une première version sous le regard de l’équipe ;
• l'étude de solutions existantes pour voir ce qui fonctionne déjà et ce qui frustre les gens.

Les résultats sont transformés en conception. Deux artefacts servent à cela : une liste de spécifications du programme précisant exactement ce que le programme doit faire, et des diagrammes représentant la mise en page de l'interface utilisateur — des esquisses montrant où apparaissent les commandes et ce que chacune fait lorsqu'elle est utilisée. Concevoir l'interface sur papier d'abord coûte moins cher que de découvrir après codage que les boutons sont mal placés.

La spécification d’un programme définit ses exigences. La phase de conception prévoit ensuite comment y répondre. Elle peut comprendre une séance de remue-méninges, un scénarimage (une suite de croquis de ce que voit l’utilisateur), la division du programme en modules et la planification des tests.

Événements, et programmes qui attendent

Tous les programmes ne s’exécutent pas simplement du début à la fin. Un événement est généré lorsqu’une touche est enfoncée, qu’un clic de souris est effectué, qu’un programme est lancé ou que toute autre action définie se produit — et un événement peut modifier le flux d’exécution en déclenchant le code qui lui est associé, appelé gestionnaire d’événement. Dans de nombreux programmes graphiques, les événements attendent dans une file jusqu’à ce que le gestionnaire en cours ait terminé.

C’est pourquoi un programme doté d’une interface graphique peut sembler ne rien faire : il attend le prochain événement. L’ordre d’arrivée de ces événements dépend des actions de l’utilisateur et d’autres sources d’événements ; un même programme peut donc exécuter ses blocs dans un ordre différent à chaque utilisation.

Cette approche s’appelle la programmation événementielle : les instructions s’exécutent lorsqu’elles sont déclenchées, et non les unes après les autres depuis le début. L’événement fournit également des données d’entrée, comme la touche qui a été enfoncée.

Documentation et attribution

La documentation d’un programme est une description écrite de ce que fait un segment de code, un événement, une procédure ou un programme et de la manière dont il a été développé. Les commentaires en sont une forme : ils sont écrits pour les personnes et ne modifient pas l’exécution du programme. Tous les environnements de programmation ne permettent pas d’ajouter des commentaires ; la documentation se trouve donc parfois dans un fichier séparé.

Rédigez la documentation tout au long du développement, et non à la fin : elle vous aide, vous et vos coéquipiers, à maintenir le programme correct.

Le code provenant d’une autre personne doit être attribué à son auteur : indiquez dans la documentation sa provenance et le nom de l’auteur d’origine si vous le connaissez. Cela s’applique aussi au code écrit avec un partenaire.

Un bogue est une erreur dans un programme ; le débogage consiste à la trouver et à la corriger. L’examen distingue quatre types d’erreurs :

• une erreur de syntaxe viole les règles du langage, empêchant ainsi le programme de s'exécuter;
• une erreur d'exécution fait planter le programme pendant son fonctionnement (par exemple, une division par zéro);
• une erreur logique laisse le programme s’exécuter, mais produit un résultat incorrect ;
• une erreur de dépassement de capacité se produit lorsqu’un nombre se situe hors de la plage que l’ordinateur peut traiter.

Repérez les bogues à l’aide de cas de test utilisant différentes entrées, en ajoutant des instructions d’affichage pour voir les valeurs et en suivant l’exécution du code à la main. Un débogueur arrête le programme à une ligne choisie afin de permettre l’examen de chaque variable, et une visualisation, comme un graphique, peut rendre une anomalie facile à voir. Choisissez les entrées de test délibérément : elles doivent montrer les différents résultats attendus aux limites ou juste au-delà — les valeurs minimale et maximale que le programme doit accepter, ainsi qu’une valeur juste en dehors de chacune de ces limites. Un programme qui fonctionne avec des données ordinaires échoue très souvent avec une liste vide, un zéro ou une valeur située juste après la fin d’une plage ; ce sont donc les entrées à essayer en premier. La méthode fiable consiste à corriger un bogue à la fois, puis à refaire les tests.

Exemple corrigé : choisir les entrées de test. Une page d’inscription à un club doit accepter les âges de 13 à 18. Les exigences indiquent le résultat correct ; vous pouvez donc choisir des entrées et préciser le résultat attendu :

Cinq tests suffisent : 12, 13, 15, 18 et 19. Si le code indique age > 13, seul le test avec 13 révèle l’erreur ; l’âge 15 est accepté dans les deux cas.

Compétence d'examen : savoir nommer le type d'erreur et décrire une stratégie de test capable de la détecter — thème récurrent en QCM et en tâche Create.

Exemple résolu. Un programme censé afficher la moyenne de deux nombres exécute au lieu de cela avg = a + b / 2. En traçant l'ordre des opérations, / s'exécute avant +, calculant ainsi $a+\tfrac{b}{2}$ plutôt que la moyenne. Ajouter des parenthèses corrige l'erreur : avg = (a + b) / 2. Tester avec $a=4,\ b=6$ confirme la correction — la ligne erronée produit $4+3=7$, la ligne corrigée produit $\tfrac{10}{2}=5$. Tester avec des entrées connues est exactement la méthode permettant de repérer et de valider une erreur logique.

Exemple corrigé : nommer l’erreur.

Réponses écrites sur votre propre programme

La section II de l’examen accorde 60 minutes pour deux questions comportant quatre consignes de réponse écrite, toutes relatives au programme que vous avez soumis pour la tâche de création. Vous voyez vos propres segments de code dans votre document de référence personnalisé du projet ; les réponses doivent donc porter sur votre programme, et non sur les programmes en général. Imaginez que la procédure suivante figure dans le vôtre :

PROCEDURE Average(numbers)
{
   sum ← 0
   FOR EACH n IN numbers
   {
      sum ← sum + n
   }
   RETURN(sum / LENGTH(numbers))
}

Les consignes des examens précédents ont demandé les éléments suivants.

1. Une modification qui provoque une erreur logique et la manière dont le comportement change. « Si sum ← 0 est remplacé par sum ← 1, la procédure s’exécute toujours, mais chaque total est supérieur d’une unité à la valeur attendue. Average([2, 4]) renvoie $3.5$ au lieu de $3$. »
2. Un appel que la procédure accepte mais traite incorrectement. « Average([]) : la liste vide est acceptée, mais LENGTH(numbers) vaut 0 ; la dernière ligne divise donc par zéro et une erreur d’exécution arrête le programme. » Indiquez l’appel, le comportement incorrect et la raison : ce sont trois éléments distincts.
3. Une documentation destinée à un autre programmeur. « Un commentaire au-dessus de la procédure indiquant que numbers ne doit pas être vide. Un autre programmeur qui réutilise Average sait ainsi qu’il doit vérifier que la liste n’est pas vide avant de l’appeler. »
4. Une entrée inattendue. Nommez une entrée réelle de votre programme et indiquez ce que celui-ci fait ensuite. S’il rejette l’entrée, indiquez la ligne qui effectue ce rejet.

Erreurs courantes. Décrire une modification sans indiquer ce qui change lors de l’exécution du programme. Donner un appel sans valeurs d’arguments précises. Répondre à propos d’une procédure différente de celle que la consigne désigne.

Répondez à chaque question avant de lire les réponses ci-dessous.

1. Une application de podomètre compte les pas et affiche un total quotidien afin que les utilisateurs puissent atteindre un objectif. Indiquez la finalité du programme et l’une de ses fonctions.
2. Classez chaque erreur : syntaxe, logique, exécution ou dépassement de capacité : (a) un crochet fermant manquant ; (b) une moyenne calculée comme sum / (count + 1) ; (c) une division par une variable qui vaut zéro pendant l’exécution du programme ; (d) l’ajout de $1$ à la plus grande valeur qu’un nombre fixe de bits peut stocker.
3. Une procédure renvoie "pass" pour les scores supérieurs ou égaux à $60$. Choisissez quatre entrées de test et expliquez vos choix.
4. Donnez un avantage de la collaboration lors de la conception d’un programme.
5. Distinguez le développement itératif du développement incrémental.
6. Donnez deux raisons de rédiger des commentaires et d’autres documents relatifs au programme.

1. Finalité : aider les utilisateurs à atteindre un objectif quotidien d’activité. Fonction : par exemple, ajouter $1$ au total chaque fois qu’un pas est détecté ou afficher le total.
2. (a) Syntaxe ; (b) logique ; (c) exécution ; (d) dépassement de capacité.
3. $59$, $60$ et $61$ testent la limite, où les erreurs sont les plus probables ; une valeur extrême telle que $0$ ou $100$ vérifie les limites des entrées valides.
4. Des points de vue différents aident à trouver les erreurs et à éviter les biais, afin que le programme fonctionne pour davantage d’utilisateurs (par exemple, la programmation en binôme permet de repérer les erreurs plus tôt).
5. Le développement itératif répète des cycles de conception, de test et d’amélioration, en révisant le programme après les retours reçus. Le développement incrémental construit et teste le programme par petits éléments, en ajoutant une partie fonctionnelle à la fois.
6. Elle explique ce que fait le code et pourquoi, afin que d’autres personnes (et l’auteur plus tard) puissent le comprendre, le maintenir et le déboguer ; elle consigne également les sources du code emprunté.

• L'évaluation comprend des questions à choix multiples et la composante Créer, avec des réponses écrites sur l'examen AP. Expliquez clairement votre raisonnement, pas seulement votre résultat.
• Connaissez les avantages de la collaboration et la façon dont des perspectives diverses réduisent les biais dans un programme.
• Utilisez un vocabulaire précis (itératif, incrémental, exigences du programme) lorsque vous décrivez un processus de conception.
• Testez les limites de la plage d’entrée et les valeurs juste au-delà, et indiquez la sortie attendue pour chaque test.
• donner et recevoir des retours constructifs ; reconnaître les collaborateurs et les sources.
• Décomposez un grand problème en modules plus petits qu'une équipe peut construire en parallèle.