Les facteurs d’erreurs

Des expériences réalisées en 1983 pendant un an [Bailey, 83], sur des informaticiens ayant une bonne connaissance de la programmation des logiciels et de l’architecture des ordinateurs, a permis d’évaluer les différents facteurs d’erreurs dans les systèmes informatiques en général. Cette évaluation n’est pas obsolète aujourd’hui malgré les progrès technologiques effectués depuis. En effet, ces résultats restent fiables particulièrement dans le cadre de notre étude car le concepteur qui utilise un SAM pour développer son logiciel peut être ou non un informaticien.

L’erreur humaine dans le schéma ci-dessous représente simultanément le manque d’attention, le manque de compréhension, le mauvais choix et le manquement de la part de l’individu, qui peut être associé à l’utilisateur du SAM dans notre étude.

Chapitre 3 ————————————————————————————————— Le codage est relatif aux erreurs incluses dans le langage de programmation.

La partie structure et organisation indique les erreurs fonctionnelles du logiciel, incluant l’algorithmique.

Les simulations et les tests signalent toutes les erreurs commises pendant la ou les phases de validation du logiciel.

La partie matériel indique le pourcentage des erreurs provenant directement des équipements utilisés, indépendamment du système.

•

• Enfin, la partie interface homme-machine indique le taux d’erreurs dues à une mauvaise ergonomie et une pédagogie insuffisante.

conception 20% codage 10% simulation + tests 10% matériel 5% interface homme- machine 10% structure + organisation 10% erreur humaine 35%

Figure 3-1 : Attribution des facteurs d’erreurs d’après [Bailey, 83]

Nous pouvons remarquer que la part de l’individu représente plus de 60% des erreurs qui se produisent ; tandis que les erreurs logistiques constituent environ 25% de l’ensemble.

L’amélioration de la qualité des logiciels grâce aux nouvelles technologies n’entraîne pas forcément une diminution des erreurs humaines. Le fait que 15 à 43% des erreurs recensées dans les systèmes d’exploitation proviennent des erreurs de codage (mauvaise utilisation des pointeurs et mauvaises allocations de tables) démontrent cette thèse [Ghosh & al, 1998]. Par conséquent, beaucoup d’erreurs sont communes à différents individus, mais diffèrent selon les tâches auxquelles elles sont appliquées.

3.2.2.1.Erreur humaine

« L’erreur n’est pas une pure négation, c’est-à-dire n’est pas le simple défaut ou manquement de quelques perfections, mais c’est une privation de quelques connaissances que l’individu

————————————— Concept d’erreur et de robustesse dans l’utilisation des SAM devrait avoir » Descartes, Méditations, IV, 1641. En effet, on peut considérer l’erreur comme un moyen permettant à un utilisateur de SAM, c’est-à-dire à l’auteur de niveau 119, de progresser dans ses développements. C’est en commettant des erreurs que les problèmes se posent, et que le concepteur utilisant un SAM améliore au fur et à mesure sa méthode de conception, de développement et de tests, bref son produit final.

Il existe différentes démarches pour prendre une décision lors de la phase conceptuelle d’un projet. Suivant la démarche adoptée, on obtient des styles de programmes différents. Nous nous sommes appuyés sur les trois types de démarches présentées par Forner [Forner, 90] : • un style rationnel constitué d’une évaluation systématique et d’une délibération dans une

perspective temporelle étendue. Cela implique une formulation du type « je pense à ce que je pourrai obtenir et ce à quoi je devrais renoncer en choisissant cela ». Cette démarche donne souvent la garantie d’aboutir à un produit assez satisfaisant, et répondant suffisamment aux besoins exprimés, mais nécessite des efforts considérables de la part du concepteur. Ici, l’expérience du concepteur est primordiale. Ce style de conception est fréquemment adopté par les utilisateurs ayant des connaissances en informatique.

• un style intuitif attachant de l’importance à l’imagination, au sentiment présent et à une conscience de soi émotionnelle. Le style intuitif donne la formulation « je choisis cela car je sens qu’il me correspond bien ». Ce réflexe peut devenir rapidement un handicap pour les débutants car, par expérience, les habitudes de développement se prennent très rapidement. De plus, le concepteur tend souvent à donner plus d’importance à l’interface homme-machine, qu’il considère rapidement comme le centre du projet. Le résultat donné par cette démarche est peu convaincant car la structure du programme est souvent inexistante réellement et les différentes fonctions ou opérations mises à la disposition de l’utilisateur final sont peu soignées.

• un style dépendant composé d’une passivité et d’une soumission à l’influence des attentes d’autrui, des événements et du marché. Cela signifie « ma décision de choisir cela a été fondée sur le conseil de personnes qui m’ont convaincu que c’était un bon produit ». Cette démarche peut être intéressante à condition que la personne, source de l’influence est un expert dans le domaine. Mais, cette méthode n’est bénéfique qu’à des individus ayant déjà de l’expérience dans le domaine.

Chapitre 3 ————————————————————————————————— Les erreurs humaines résultent alors souvent du vécu de chaque individu. Le passé, c’est-à- dire l’expérience joue ainsi un rôle primordial dans la limitation des erreurs grâce à des contrôles intrinsèques de l’individu. En effet, l’expérience peut aider l’utilisateur du SAM à réduire ses erreurs comme elle peut l’influencer de telle manière qu’il en oublie les autres parties du projet.

3.2.2.2.Erreur logistique

Beaucoup de logiciels sont conçus avec une « pensée » orientée surtout vers l’ordinateur et le logiciel. Le concepteur a tendance à s’occuper uniquement des problèmes venant de la machine et de son programme [Bailey, 82]. En d’autres termes, il est plus souvent intéressé par tout ce qui est concret, voir palpable, dans un projet, et non pas vers les éléments abstraits telles les spécifications fonctionnelles correspondant à l’objectif final.

Cela peut réveiller l’idée que pour réaliser un programme, il faut être un informaticien ce qui signifie avoir au moins des connaissances sur un système d'exploitation et un langage de programmation. Généralement, l'environnement de travail d'un développeur n'est pas du tout convivial. Il utilise un éditeur tels que « vi » ou « emacs » dans Unix et « Edit » dans Dos. Le mot éditeur sous-entend déjà connaître quelques commandes, généralement rentrés au clavier (sauf sur quelques éditeurs plus conviviaux et ergonomiques, se basant sur des interfaces graphiques) pour saisir des données textuelles. Ainsi, ce type d’erreur peut provenir du mauvais choix sur un ou plusieurs éléments techniques, pendant la phase de spécification technique, du concepteur.

L’erreur logistique provient parfois du fait que l’utilisateur du système auteur accorde trop de confiance à la capacité de la machine. Le résultat n’est pas satisfaisant car cela débouche souvent sur une mauvaise gestion de l’espace disque, un ralentissement de l’exécution d’une opération multimédia, etc.

Ainsi, l’erreur logistique entraîne généralement un mauvais résultat à cause du fait que le concepteur peut s’écarter de façon incontrôlée de son projet. Le suivi du cahier des charges, primordial pour la réussite du projet, peut alors être affecté par l’erreur logistique. Cela entraîne également un étalement considérable du temps global de réalisation. De même, cette erreur induit d’autres erreurs qui peuvent être qualifiées d’erreurs humaines comme le fait de ne pas prendre en considération les différents niveaux des utilisateurs par exemple.

————————————— Concept d’erreur et de robustesse dans l’utilisation des SAM