2.8.2 Etude de la qualité externe des logiciels de fouille visuelle de données

En ECD, la validation croisée, le holdout ou le boostrap constituent des techniques d’évaluation de la qualité des modèles des données qui sont construits à travers des interfaces. Afin de faciliter la modélisation des données, il est nécessaire que l’interface soit de bonne qualité. Dans le processus de développement de logiciels, comme spécifié ci-dessus, il existe des facteurs visibles par les développeurs et des facteurs visibles par les utilisateurs finaux. Dans ce travail, nous désignons par défaillance du logiciel la non-conformité avec les attentes des utilisateurs. Les techniques d’étude de la qualité des logiciels d’analyse de données décrites dans la section 2.8.1 sont visibles par les développeurs. En ECD, très peu de travaux sont consacrés aux autres aspects concernant les défaillances du logiciel, notamment l’interaction homme machine, l’analyse du contexte, des actions, de l’activité, l’ergonomie des interfaces et cognitive. En général, l’évaluation de la qualité des logiciels en vue de la détection des défaillances de logiciels peut être faite en amont du processus de conception du logiciel c'est-à-dire après analyse des besoins, elle peut être intégrée dans le cycle de développement itératif du logiciel (génie logiciel), l’étude de la qualité du logiciel peut aussi avoir lieu après développement ou prototypage (test du logiciel, évaluation ergonomique). Il existe de nombreuses méthodes d’évaluation de logiciels. Une classification de ces méthodes d’évaluation peut être faite en fonction de leurs objectifs, du moment où l’évaluation a lieu ou du type d’utilisateurs impliqués dans l’évaluation. En génie logiciel, on parle de test du logiciel. Le test de logiciel a pour objectifs de détecter les déviations par rapport aux spécifications, détecter des erreurs, augmenter la confiance dans le programme, déterminer un niveau de fiabilité dans le logiciel, évaluer les performances ou évaluer le comportement en charge.

Du point de vue IHM et génie logiciel, les aptitudes attendues de l’évaluation de logiciels sont de plusieurs ordres : la satisfaction des besoins des utilisateurs, la fiabilité, la pérennité, l’interopérabilité, la conformité aux standards et un bon ratio coût / performance.

Pour matérialiser concrètement ces différentes méthodes d’amélioration de la qualité des logiciels, il existe des normes et des critères de développement de systèmes de qualité. Nous pouvons citer les standards, par exemple la norme ISO 9241 [Iso, 1999] et HFES/ANSI 200, les guides de style, par exemple le guide de Sun [Sun, 1999], [Constantine, 2001] et [Detweiler et Omanson, 1996], les compilations de règles [Vanderdonckt, 1994] et les critères liés au contexte de l’activité : l’activity checklist de [Kaptelinin, 1999]. L’un des travaux précurseurs du domaine de la qualité du logiciel a donné naissance au modèle de McCall [McCall et al., 1977] qui recense une cinquantaine de critères permettant d’exprimer la qualité du logiciel. Partant de la liste de McCall, [Ghezzi et al., 1991] a établi une liste plus exhaustive de critères de qualité des logiciels. Cette liste comprend seize critères. Il existe d’autres modèles tels que celui de [Murine et Carpenter, 1984]. Un autre ensemble de facteurs de qualité des logiciels a été réalisé par [Boëhm, 1978]. Ces facteurs concernent les fonctionnalités et les performances du logiciel du point de vue génie logiciel et de l’utilisabilité.

Plus récemment, l’évaluation heuristique [Nielsen, 1993a] et les recommandations ergonomiques [Bastien et Scapin, 1999] mettent beaucoup plus l’accent sur l’évaluation ergonomique des IHM. L’étude des facteurs humains et des IHM complète la qualité des logiciels dans les fondements théoriques de ces travaux qui sont basés sur un ensemble de critères. Des travaux de psychologie cognitive relatifs à la visualisation de données [Healey, 1996] proposent aussi des primitives intéressantes dans un contexte d’évaluation qualitative.

Mais, certaines des techniques décrites ci-dessus sont assez générales. Pour des nouveaux systèmes tels que ceux de la FVD, une piste de recherche consiste à retrouver les caractéristiques de qualité puis à voir comment les évaluer. Une autre piste de recherche peut consister à adapter les normes, les standards ou critères existants aux nouveaux systèmes. On obtient alors des recommandations de qualité spécifiques, des critères de qualité spécifiques et des questionnaires spécifiques. Dans le cadre de la FVD, les questions de qualité externe des logiciels restent d’actualité : que faut-il faire pour garantir la qualité d’un environnement de FVD ? Quels principes faut-il appliquer ? Quand et comment les appliquer ?