Origines et évolutions de la psychologie de la programmation

Transcription

1 Chapitre 1 Origines et évolutions de la psychologie de la programmation Le domaine de la psychologie de la programmation est né dans les années Deux périodes peuvent être distinguées. Dans la première, les recherches, menées principalement par des informaticiens, avaient pour objectif principal l'évaluation d'outils informatiques en termes de performance. C'étaient des études expérimentales visant à analyser les effets de différents facteurs (par exemple, l'indentation) sur la performance dans différentes tâches de programmation et, ceci, sans modèles cognitifs pour rendre compte de l'activité dans ces différentes tâches. Le livre qui illustre le mieux les études de cette période est celui de Shneiderman (1980) : il a eu un certain impact dans le monde informatique au moment de sa publication. Depuis une dizaine d'années il y a eu un intérêt accru de la part des psychologues et ergonomes qui ont vu dans la programmation un terrain pour étudier des activités de conception, de compréhension, de résolution de problèmes par l'expert ainsi que le moyen de développer et évaluer des outils d'aide à ces activités. Cette seconde période se caractérise par l'élaboration de modèles cognitifs de la programmation et par l'utilisation, à côté et en complément des méthodes expérimentales, de méthodes plus cliniques d'analyse de l'activité. Les chercheurs de ce domaine scientifique se rencontrent au cours de workshops annuels ou bis-annuels : celui du «Psychology 1. Les éditeurs de l'ouvrage Psychology of Programming (Hoc, Green, Samurçay & Gilmore, 1990), situent l'origine de la psychologie de la programmation aux années Il est vrai qu'une étude française (Rouanet & Gateau, 1967) a alors eu pour objet l'analyse du programmeur de gestion. Mais ce genre d'étude était tout à fait unique à l'époque et il a fallu attendre les années 70 pour que les études dans ce domaine se multiplient.

2 16 Génie logiciel et psychologie de la programmation of Programming Interest Group» côté européen, et le workshop «Empirical Studies of Programmers» côté nord américain. Ces rencontres ont donné lieu à nombre de productions scientifiques Première période Paradigme expérimental A l'origine de l'étude de la programmation il y avait l'intérêt des informaticiens pour tester de nouveaux outils de programmation. Des méthodes, langages ou outils de visualisation ont été développés à mesure que la programmation évoluait en s'éloignant de l'utilisation des langages machines. Le besoin de valider ces nouveaux outils expérimentalement est alors né. Dans cet objectif, les informaticiens ont emprunté des méthodes à la psychologie expérimentale pour évaluer ces outils (voir par ex., Curtis, 1982). Ces méthodes expérimentales permettent de tester l'effet d'un ou plusieurs facteurs, dits variables indépendantes, sur les valeurs prises par une variable dépendante. Le principe est de construire une situation expérimentale en faisant varier les valeurs prises par une variable indépendante. On a, dans le cas le plus simple, une condition expérimentale où cette variable est présente et une condition contrôle où cette variable est absente, toutes choses étant égales par ailleurs. On mesure alors l'effet de cette variable sur une autre variable dite «dépendante» qui est, la plupart du temps dans ces études, un indicateur de performance. Pour illustrer cette approche, nous citerons un exemple hypothétique donné par Shneiderman (1980). C'est une étude bi-factorielle. Les deux variables indépendantes dont on veut mesurer les effets sont l'utilisation de noms de variables mnémoniques (significatifs) d'une part, et l'utilisation de commentaires d'autre part. Chaque variable peut être présente ou absente. La variable dépendante est une mesure de performance dans une tâche de modification de programme. En croisant ces deux facteurs, on obtient quatre conditions expérimentales (voir tableau 1.1) dans lesquelles on peut affecter les sujets expérimentaux de façon aléatoire. Il faut en effet s'assurer que le facteur expérience des sujets est bien un facteur contrôlé dans cette étude, ce qui signifie qu'il faut s'assurer que les sujets viennent bien d'une même population dont on peut décrire les caractéristiques. Le tableau 1.1 présente des résultats hypothétiques, cités par Shneiderman (1980, p. 20), d'une telle expérience. On peut voir d'après les moyennes dans les marges, qu'il y a un effet du facteur «présence de commentaires», d'une part, et du facteur «présence de nom mnémonique de variables», d'autre part.

3 Origines et évolutions de la psychologie de la programmation 17 Dénomination des variables Mnémonique Non mnémonique Avec commentaires 84,5 72,3 78,4 Sans commentaires 75,4 56,8 66,1 80,0 64,6 72,3 Tableau 1.1. Moyenne des scores de modifications obtenus dans une expérience bi-factorielle (extrait de Shneiderman, 1980, p. 20) Une seconde étape est alors de procéder à des tests statistiques, de type analyse de variance, qui permettent de montrer quelle est la probabilité de ne pas trouver ces résultats lors de répliques sur des groupes similaires. Si ce pourcentage est faible pour l'effet d'une variable indépendante, par exemple 1 pour mille, alors on peut dire qu'il y a un effet significatif de cette variable à p = Les variables dépendantes les plus souvent utilisées dans les études de cette période sont des indicateurs de performance. Ces indicateurs sont souvent construit relativement à différentes tâches de programmation : par exemple, le nombre d'erreurs détectées et corrigées et le temps mis pour les détecter dans une tâche de déboggage. Ces indicateurs mesurent très clairement la réussite dans une tâche donnée en termes de produit final de l'activité mais ne décrivent en aucune manière l'activité mise en œuvre pour réaliser la tâche. Nous verrons que cela pose un problème pour interpréter les résultats. Une autre approche expérimentale qui caractérise les études de cette première période est la recherche de corrélation entre, d'une part, des facteurs propres aux sujets, e.g., le nombre d'années d'expérience en programmation, et, d'autre part, des facteurs comportementaux, e.g., la réussite à un test censé mesurer l'habileté à comprendre des programmes. L'objectif pratique de ces études était de développer des tests de compétence à des fins de sélection. Une remarque méthodologique rappellera simplement au lecteur que l'établissement d'une corrélation entre deux facteurs ne signifie pas qu'il y ait une relation de causalité entre ces facteurs Critiques méthodologiques Nous soulignerons en effet plusieurs problèmes méthodologiques. En pratique, il est souvent difficile d'isoler un facteur et de le faire varier sans entraîner d'autres variations dans la situation. On peut toutefois essayer de l'isoler mais au risque de

4 18 Génie logiciel et psychologie de la programmation créer une situation assez artificielle. Nous illustrerons cette limite méthodologique à travers deux exemples, le premier illustrant une utilisation peu maîtrisée, à notre sens, de l'approche expérimentale, le second illustrant une application mieux maîtrisée de l'approche expérimentale mais qui crée une situation relativement artificielle. Gannon (1977) a étudié l'effet du caractère typé d'un langage de programmation sur la performance dans une tâche de conception de programme mesurée, entre autres, par le nombre d'erreurs produites dans le programme. La variable indépendante a deux valeurs : typage statique, i.e., déclaration du type des variables, et absence de typage statique. Pour introduire cette variable, cet auteur a été en fait amené à prendre deux langages différents. Cela a pour effet de faire varier, non seulement le facteur étudié, mais aussi beaucoup d'autres caractéristiques syntaxiques et sémantiques des langages. L'interprétation des résultats est alors difficile car il y a des facteurs confondus qui peuvent être aussi la cause des résultats obtenus. Pour éviter ce problème méthodologique, des auteurs (en particulier, Sime, Green & Guest, 1973 ; 1977) ont créé des micro-langages qui variaient selon un ou plusieurs facteurs bien identifiés. Ainsi, ils ont pu comparer l'effet de différents types de boucles (goto, emboîtées, etc.) ou de différents types de tests sur la performance dans différentes tâches. Ce faisant, ils créent une situation assez artificielle en comparaison des situations habituelles de programmation. Ils défendent ainsi cette position : «The technique of using severely restricted micro-languages allows comprehensive conclusions to be reached... in our opinion, at present more can be lost than learned by increasing the size of experimental language.» (Sime et al. 1977). Gannon défend l'approche contraire, estimant que l'utilisation de micro-langages est trop artificielle : «Languages features must be evaluated in the context in which they are used, and creating too small a language may prevent the observations of errors resulting from the interaction of languages features.» (Gannon, 1976) Absence de cadre théorique Un autre problème est lié à l'absence de cadre théorique et au fait d'avoir des indicateurs de performance qui mesurent le produit final de l'activité : il est alors difficile d'interpréter la présence d'un effet. En effet, ces études n'offrent pas de modèle explicatif en termes de processus cognitifs pour la présence d'un effet. En aucun cas, elles n'expliquent pourquoi et comment une variable a un effet sur la performance. De plus, l'absence d'effet en termes de performance n'a, à notre avis, qu'une faible valeur indicative de l'effet du facteur considéré. Cet effet peut exister mais, simplement, ne pas être détecté par ces indicateurs finaux. Il faut alors des

5 Origines et évolutions de la psychologie de la programmation 19 indicateurs qui portent sur l'activité elle-même pour détecter cet effet. Seules les études de la seconde période mettent en œuvre des méthodes pertinentes pour analyser l'activité proprement dite. Nous allons donner un exemple qui illustre les limites méthodologiques de la première période et anticiper sur les changements paradigmatiques qui s'opèrent lors de la seconde période. Cet exemple porte sur l'effet de la dénomination significative ou non des variables. Rappelons qu'un programme est formé de symboles prédéfinis (opérateur, mots réservés) et de noms choisis par l'informaticien (noms de variables, de sousprogrammes). On peut s'attendre à ce que la présence, dans un programme, de noms significatifs facilite la compréhension. Or les études de la première période portant sur ce facteur ne font pas toujours apparaître un effet positif de ce facteur sur la compréhension : Weissman (1974) ne trouve pas d'effet de ce facteur dans différentes tâches de programmation ; (Sheppard, Curtis, Milliman & Love, 1979a ; Sheppard, Curtis, Milliman, Borst & Love, 1979b) ne trouvent pas d'effet de ce facteur mesuré par la capacité à reproduire de mémoire un programme fonctionnellement équivalent. Shneiderman (1980) montre que, plus le programme est complexe, plus la dénomination mnémonique des variables aide à la compréhension et ceci relativement à un score de détection d'erreur dans une tâche de déboggage. Bien que certaines études permettent de mieux cerner dans quelles conditions un effet de cette variable est observé en termes de performance de compréhension, elles ne montrent pas quels sont les mécanismes cognitifs qui opèrent. Dans la seconde période les auteurs étudiant la compréhension se sont constitué des cadres théoriques et des paradigmes correspondants. Ainsi, on a supposé qu'un nom significatif est un indice sémantique qui permet d'activer une structure de connaissances (dans ce cas, un schéma de variable) stockée en mémoire à long terme et de faire des inferences sur la base des connaissances évoquées. Une étude (Soloway & Erhlich, 1984) a permis de saisir l'effet des noms de variables dans la compréhension en utilisant un paradigme pertinent pour étudier les inferences faites lors de la compréhension de programme : une tâche de completion. Si la ligne effacée correspond à «Count : = 0» et que le schéma correspondant «schéma de compteur» est évoqué grâce au nom de la variable «Count» dans l'instruction de mise à jour «Count : = Count + 1», les experts peuvent inférer l'instruction manquante plus facilement que les novices. Dans cette étude, il est alors clair que le nom est un indice sémantique qui permet d'activer en mémoire un schéma, ce qui rend possible 1'inference de la partie restant à particulariser dans ce schéma. Selon ce modèle explicatif de l'effet du nom des variables sur l'activité, on peut comprendre pourquoi un indicateur portant sur le produit de l'activité ne peut mesurer un tel effet. Ces mécanismes d'activation sont transitoires et les processus de compréhension se basent sur une multiplicité de données en entrée, pas uniquement les noms significatifs de variables. Ainsi dans l'expérience de Sheppard et al. (1979a ; 1979b) l'absence d'effet peut être dû au fait que les programmes

6 20 Génie logiciel et psychologie de la programmation étaient commentés : l'effet des commentaires peut avoir masqué sinon annulé l'effet de la mnémonicité des variables. La difficulté d'interpréter l'absence comme la présence d'effet et les résultats contradictoires entre ces études de la première période est aussi soulignée par Hoc, Green, Samurçay et Gilmore (1990). Ces auteurs l'illustrent par les études portant sur l'effet de structures notationnelles variées comme l'organigramme versus le listing. Les résultats sont contradictoires, certains auteurs montrant une amélioration de la performance avec l'utilisation de l'organigramme (Wright, 1977), alors que d'autres constatent une absence d'effet (Shneiderman, Mayer, McKay & Heller, 1977). Il faut attendre des études de la seconde période pour comprendre quels sont les composants de l'activité qui sont affectés par l'utilisation d'organigrammes. Ainsi, Gilmore et Smith (1984) soulignent le fait que l'aide apportée par une structure notationnelle donnée est relative à la stratégie suivie par les informaticiens pour réaliser une tâche. Pour une tâche de déboggage, les sujets observés par ces auteurs suivent soit une stratégie d'exécution du programme, soit une stratégie de compréhension qui leur permet de construire un modèle mental du programme. Or l'organigramme est une aide apportée au processus d'exécution : les sujets qui suivent cette stratégie ont une meilleure performance avec l'organigramme par rapport au listing Emprunts théoriques pauvrement utilisés Nous avons souligné précédemment l'absence de cadre théorique qui caractérise les études de cette première période. Il faut toutefois reconnaître que quelques emprunts théoriques ont été faits à la psychologie mais que les concepts empruntés ont été très pauvrement utilisés par les informaticiens. L'exemple le plus illustratif est l'emprunt de la notion de mémoire à court terme. Une distinction classique en psychologie, quoique objet d'un vieux débat (Florès, 1970), concerne la mémoire à court terme (MCT), dont la capacité de rétention est limitée, et la mémoire à long terme (MLT) dont la capacité est illimitée. Selon un article célèbre en psychologie (Miller, 1956) l'empan de la MCT serait de sept plus ou moins deux unités ce qui limite notre capacité à traiter l'information. Ce chiffre représente le nombre d'éléments isolés (chiffres ou lettres ne formant pas une suite significative) pouvant être conservés en MCT. Ce résultat a été utilisé en informatique pour le développement de métriques de complexité. Or un résultat complémentaire, tout aussi important, concerne le processus de «chunking». Ce processus étend la capacité de la mémoire à court terme en regroupant conceptuellement des items élémentaires en des unités d'une autre nature. Nous allons voir que si le concept de MCT a été effectivement utilisé dans le développement de métriques de complexité de programme, le concept de chunking, tout aussi important, lui n'a pas été pris en compte.