Bogue logiciel -Software bug

Un bogue logiciel est une erreur, un défaut ou un défaut dans un programme ou un système informatique qui l'amène à produire un résultat incorrect ou inattendu, ou à se comporter de manière involontaire. Le processus de recherche et de correction des bogues est appelé " débogage " et utilise souvent des techniques ou des outils formels pour identifier les bogues, et depuis les années 1950, certains systèmes informatiques ont également été conçus pour dissuader, détecter ou corriger automatiquement divers bogues informatiques pendant les opérations.

La plupart des bogues proviennent d'erreurs et d'erreurs commises dans la conception d'un programme ou dans son code source , ou dans les composants et les systèmes d'exploitation utilisés par ces programmes. Quelques-uns sont causés par des compilateurs produisant un code incorrect. Un programme qui contient de nombreux bogues, et/ou des bogues qui interfèrent sérieusement avec ses fonctionnalités, est dit bogué (défectueux). Les bogues peuvent déclencher des erreurs qui peuvent avoir des effets d'entraînement . Les bogues peuvent avoir des effets subtils ou faire planter le programme ou bloquer l'ordinateur. D'autres bogues sont qualifiés de bogues de sécurité et peuvent, par exemple, permettre à un utilisateur malveillant de contourner les contrôles d'accès afin d' obtenir des privilèges non autorisés .

Certains bogues logiciels ont été liés à des catastrophes. Les bogues dans le code qui contrôlaient l' appareil de radiothérapie Therac-25 étaient directement responsables du décès de patients dans les années 1980. En 1996, le prototype de fusée Ariane 5 de l'Agence spatiale européenne, d'une valeur de 1 milliard de dollars , a dû être détruit moins d'une minute après son lancement en raison d'un bogue dans le programme informatique de guidage embarqué. En juin 1994, un hélicoptère Chinook de la Royal Air Force s'est écrasé sur le Mull of Kintyre , tuant 29 personnes. Cela a d'abord été rejeté comme une erreur du pilote, mais une enquête de Computer Weekly a convaincu une enquête de la Chambre des Lords qu'elle pouvait avoir été causée par un bogue logiciel. dans l' ordinateur de contrôle moteur de l'avion .

En 2002, une étude commandée par le National Institute of Standards and Technology du département américain du Commerce a conclu que « les bugs logiciels, ou erreurs, sont si répandus et si préjudiciables qu'ils coûtent à l'économie américaine environ 59 milliards de dollars par an, soit environ 0,6 % du produit intérieur brut ».

Histoire

Le mot bugge en moyen anglais est à la base des termes " bugbear " et " bugaboo " en tant que termes utilisés pour un monstre.

Le terme «bogue» pour décrire les défauts fait partie du jargon technique depuis les années 1870 et est antérieur aux ordinateurs électroniques et aux logiciels informatiques; il peut avoir été utilisé à l'origine dans l'ingénierie matérielle pour décrire des dysfonctionnements mécaniques. Par exemple, Thomas Edison a écrit les mots suivants dans une lettre à un associé en 1878 :

Il en a été ainsi dans toutes mes inventions. La première étape est une intuition, et vient avec un sursaut, puis des difficultés surgissent - cette chose cède et [c'est] alors que les "Bugs" - comme on appelle ces petits défauts et difficultés - se manifestent et des mois d'observation intense, d'étude et la main-d'œuvre sont nécessaires avant que le succès ou l'échec commercial ne soit certainement atteint.

Baffle Ball , le premier jeu de flipper mécanique , a été annoncé comme étant "sans bugs" en 1931. Les problèmes avec l'équipement militaire pendant la Seconde Guerre mondiale étaient appelés bugs (ou pépins ). Dans un livre publié en 1942, Louise Dickinson Rich , parlant d'une machine à découper la glace motorisée , a déclaré: "Le sciage de la glace a été suspendu jusqu'à ce que le créateur puisse être amené à retirer les insectes de son chéri."

Isaac Asimov a utilisé le terme "bug" pour se rapporter à des problèmes avec un robot dans sa nouvelle " Catch That Rabbit ", publiée en 1944.

Une page du journal de l'ordinateur électromécanique Harvard Mark II , avec un papillon mort qui a été retiré de l'appareil.

Le terme "bogue" a été utilisé dans un récit par la pionnière de l'informatique Grace Hopper , qui a rendu public la cause d'un dysfonctionnement d'un des premiers ordinateurs électromécaniques. Une version typique de l'histoire est:

En 1946, lorsque Hopper a été libéré du service actif, elle a rejoint la faculté de Harvard au laboratoire de calcul où elle a poursuivi ses travaux sur le Mark II et le Mark III . Les opérateurs ont retracé une erreur dans le Mark II à un papillon piégé dans un relais, inventant le terme bug . Ce bogue a été soigneusement supprimé et enregistré dans le journal de bord. Issu du premier bogue, nous appelons aujourd'hui les erreurs ou les problèmes dans un programme un bogue .

Hopper n'a pas trouvé le bogue, comme elle l'a facilement reconnu. La date dans le journal de bord était le 9 septembre 1947. Les opérateurs qui l'ont trouvé, y compris William "Bill" Burke, plus tard du Naval Weapons Laboratory , Dahlgren, Virginie , connaissaient le terme d'ingénierie et ont amusé gardé l'insecte avec la notation "Premier cas réel de bogue découvert." Hopper adorait raconter l'histoire. Ce journal de bord, accompagné d'un papillon de nuit, fait partie de la collection du Smithsonian National Museum of American History .

Le terme connexe « debug » semble également être antérieur à son utilisation en informatique : l'étymologie du mot dans l' Oxford English Dictionary contient une attestation de 1945, dans le contexte des moteurs d'avion.

Le concept selon lequel un logiciel pourrait contenir des erreurs remonte aux notes de 1843 d'Ada Lovelace sur le moteur d'analyse , dans lesquelles elle parle de la possibilité que des "cartes" de programme pour le moteur d'analyse de Charles Babbage soient erronées :

... un processus d'analyse doit également avoir été effectué afin de fournir au moteur analytique les données opérationnelles nécessaires ; et qu'il peut également s'agir d'une source possible d'erreur. Étant donné que le mécanisme réel est infaillible dans ses processus, les cartes peuvent lui donner de mauvais ordres.

Rapport "Bogues dans le système"

L'Open Technology Institute, dirigé par le groupe New America, a publié un rapport "Bugs in the System" en août 2016 indiquant que les décideurs américains devraient procéder à des réformes pour aider les chercheurs à identifier et à résoudre les bogues logiciels. Le rapport "met en évidence la nécessité d'une réforme dans le domaine de la découverte et de la divulgation des vulnérabilités logicielles". L'un des auteurs du rapport a déclaré que le Congrès n'avait pas fait assez pour lutter contre la vulnérabilité des cyberlogiciels, même s'il avait adopté un certain nombre de projets de loi pour lutter contre le problème plus vaste de la cybersécurité.

Les chercheurs gouvernementaux, les entreprises et les experts en cybersécurité sont les personnes qui découvrent généralement les failles logicielles. Le rapport appelle à réformer les lois sur la criminalité informatique et le droit d'auteur.

La loi sur la fraude et les abus informatiques, la loi sur le droit d'auteur du millénaire numérique et la loi sur la confidentialité des communications électroniques criminalisent et créent des sanctions civiles pour les actions que les chercheurs en sécurité commettent régulièrement lorsqu'ils effectuent des recherches légitimes sur la sécurité, selon le rapport.

Terminologie

Alors que l'utilisation du terme "bogue" pour décrire les erreurs logicielles est courante, beaucoup ont suggéré qu'il devrait être abandonné. Un argument est que le mot "bug" est séparé du sens qu'un être humain a causé le problème, et implique plutôt que le défaut est apparu tout seul, conduisant à une poussée pour abandonner le terme "bug" en faveur de termes tels que "défaut", avec un succès limité. Depuis les années 1970 , Gary Kildall a suggéré avec humour d'utiliser le terme « gaffe ».

En génie logiciel, le métamorphisme d'erreur (du grec meta = "changement", morph = "forme") fait référence à l'évolution d'un défaut dans l'étape finale du déploiement logiciel. La transformation d'une "erreur" commise par un analyste dans les premières étapes du cycle de vie du développement logiciel, qui conduit à un "défaut" dans la dernière étape du cycle, a été appelée "métamorphisme d'erreur".

Les différentes étapes d'une "erreur" dans l'ensemble du cycle peuvent être décrites comme des "erreurs", des "anomalies", des "fautes", des "échecs", des "erreurs", des "exceptions", des "crashs", des "problèmes", des "bugs" , "défauts", "incidents" ou "effets secondaires".

La prévention

Erreur résultant d'un bug logiciel affiché sur deux écrans à la gare de La Croix de Berny en France.

L'industrie du logiciel a fait beaucoup d'efforts pour réduire le nombre de bogues. Ceux-ci inclus:

Des erreurs typographiques

Les bogues apparaissent généralement lorsque le programmeur fait une erreur de logique . Diverses innovations dans le style de programmation et la programmation défensive sont conçues pour rendre ces bogues moins probables ou plus faciles à repérer. Certaines fautes de frappe, en particulier des symboles ou des opérateurs logiques/mathématiques , permettent au programme de fonctionner de manière incorrecte, tandis que d'autres, comme un symbole manquant ou un nom mal orthographié, peuvent empêcher le programme de fonctionner. Les langages compilés peuvent révéler des fautes de frappe lorsque le code source est compilé.

Méthodologies de développement

Plusieurs schémas aident à gérer l'activité des programmeurs afin de produire moins de bogues. Le génie logiciel (qui traite également des problèmes de conception de logiciels) applique de nombreuses techniques pour prévenir les défauts. Par exemple, les spécifications formelles des programmes indiquent le comportement exact des programmes afin que les bogues de conception puissent être éliminés. Malheureusement, les spécifications formelles sont impraticables pour autre chose que les programmes les plus courts, en raison de problèmes d' explosion combinatoire et d' indétermination .

Les tests unitaires consistent à écrire un test pour chaque fonction (unité) qu'un programme doit exécuter.

Dans le développement piloté par les tests, les tests unitaires sont écrits avant le code et le code n'est pas considéré comme terminé tant que tous les tests ne sont pas terminés avec succès.

Le développement logiciel agile implique des versions logicielles fréquentes avec des changements relativement mineurs. Les défauts sont révélés par les commentaires des utilisateurs.

Le développement open source permet à quiconque d'examiner le code source. Une école de pensée popularisée par Eric S. Raymond sous le nom de loi de Linus dit que les logiciels open source populaires ont plus de chances d'avoir peu ou pas de bogues que les autres logiciels, car "avec suffisamment de globes oculaires, tous les bogues sont superficiels". Cette affirmation a cependant été contestée : le spécialiste de la sécurité informatique Elias Levy a écrit qu'« il est facile de cacher des vulnérabilités dans un code source complexe, peu compris et non documenté », car « même si les gens revoient le code, cela ne veut pas dire qu'ils êtes qualifié pour le faire." La vulnérabilité OpenSSL de 2008 dans Debian en est un exemple .

Prise en charge du langage de programmation

Les langages de programmation incluent des fonctionnalités permettant d'éviter les bogues, telles que les systèmes de type statique , les espaces de noms restreints et la programmation modulaire . Par exemple, lorsqu'un programmeur écrit (pseudocode) LET REAL_VALUE PI = "THREE AND A BIT", bien que cela puisse être syntaxiquement correct, le code échoue à une vérification de type . Les langages compilés attrapent cela sans avoir à exécuter le programme. Les langages interprétés détectent de telles erreurs lors de l'exécution. Certains langages excluent délibérément des fonctionnalités qui conduisent facilement à des bogues, au détriment des performances plus lentes : le principe général étant qu'il est presque toujours préférable d'écrire un code plus simple et plus lent qu'un code impénétrable qui s'exécute légèrement plus rapidement, d'autant plus que le coût de maintenance est substantiel . Par exemple, le langage de programmation Java ne prend pas en charge l'arithmétique des pointeurs ; les implémentations de certains langages tels que Pascal et les langages de script ont souvent une vérification des limites d'exécution des tableaux, au moins dans une version de débogage.

Analyse de code

Les outils d' analyse de code aident les développeurs en inspectant le texte du programme au-delà des capacités du compilateur pour détecter les problèmes potentiels. Bien qu'en général le problème de trouver toutes les erreurs de programmation données par une spécification ne soit pas résoluble (voir problème d'arrêt ), ces outils exploitent le fait que les programmeurs humains ont tendance à faire souvent certains types d'erreurs simples lors de l'écriture de logiciels.

Instrumentation

Des outils pour surveiller les performances du logiciel pendant son exécution, soit spécifiquement pour trouver des problèmes tels que des goulots d'étranglement , soit pour donner l'assurance d'un fonctionnement correct, peuvent être intégrés explicitement dans le code (peut-être aussi simplement qu'une déclaration disant PRINT "I AM HERE"), ou fournis comme outils. Il est souvent surprenant de trouver où la plupart du temps est pris par un morceau de code, et cette suppression des hypothèses peut entraîner la réécriture du code.

Essai

Les testeurs de logiciels sont des personnes dont la tâche principale est de trouver des bogues ou d'écrire du code pour prendre en charge les tests. Sur certains projets, plus de ressources peuvent être consacrées aux tests qu'au développement du programme.

Les mesures pendant les tests peuvent fournir une estimation du nombre de bogues probables restants ; cela devient plus fiable plus un produit est testé et développé.

Débogage

L'historique typique des bogues ( données du projet GNU Classpath ). Un nouveau bogue soumis par l'utilisateur n'est pas confirmé. Une fois qu'il a été reproduit par un développeur, c'est un bogue confirmé . Les bogues confirmés sont ensuite corrigés . Les bogues appartenant à d'autres catégories (non reproductibles, ne seront pas corrigés, etc.) sont généralement minoritaires

La recherche et la correction de bogues, ou le débogage , est une partie importante de la programmation informatique . Maurice Wilkes , l'un des premiers pionniers de l'informatique, a décrit sa prise de conscience à la fin des années 1940 qu'une grande partie du reste de sa vie serait consacrée à la recherche d'erreurs dans ses propres programmes.

Habituellement, la partie la plus difficile du débogage est de trouver le bogue. Une fois qu'il est trouvé, il est généralement relativement facile de le corriger. Les programmes connus sous le nom de débogueurs aident les programmeurs à localiser les bogues en exécutant le code ligne par ligne, en surveillant les valeurs des variables et d'autres fonctionnalités pour observer le comportement du programme. Sans débogueur, du code peut être ajouté afin que des messages ou des valeurs puissent être écrits sur une console ou dans une fenêtre ou un fichier journal pour suivre l'exécution du programme ou afficher des valeurs.

Cependant, même avec l'aide d'un débogueur, la localisation des bogues relève de l'art. Il n'est pas rare qu'un bogue dans une section d'un programme provoque des échecs dans une section complètement différente, ce qui le rend particulièrement difficile à suivre (par exemple, une erreur dans une routine de rendu graphique provoquant l'échec d'une routine d' E/S de fichier ) , dans une partie apparemment indépendante du système.

Parfois, un bogue n'est pas un défaut isolé, mais représente une erreur de réflexion ou de planification de la part du programmeur. De telles erreurs de logique nécessitent qu'une section du programme soit révisée ou réécrite. Dans le cadre de la révision du code , parcourir le code et imaginer ou transcrire le processus d'exécution peut souvent trouver des erreurs sans jamais reproduire le bogue en tant que tel.

Plus généralement, la première étape de la localisation d'un bogue consiste à le reproduire de manière fiable. Une fois que le bogue est reproductible, le programmeur peut utiliser un débogueur ou un autre outil tout en reproduisant l'erreur pour trouver le point auquel le programme s'est égaré.

Certains bogues sont révélés par des entrées qui peuvent être difficiles à recréer pour le programmeur. L'une des causes des décès de la machine à rayonnement Therac-25 était un bogue (en particulier, une condition de course ) qui ne s'est produit que lorsque l'opérateur de la machine est entré très rapidement dans un plan de traitement; il a fallu des jours de pratique pour devenir capable de le faire, de sorte que le bogue ne s'est pas manifesté lors des tests ou lorsque le fabricant a tenté de le dupliquer. D'autres bogues peuvent cesser de se produire chaque fois que la configuration est augmentée pour aider à trouver le bogue, comme l'exécution du programme avec un débogueur ; ceux-ci sont appelés heisenbugs (nommés avec humour d'après le principe d'incertitude de Heisenberg ).

Depuis les années 1990, notamment suite à la catastrophe du vol 501 d'Ariane 5 , l'intérêt pour les aides automatisées au débogage s'est accru, comme l'analyse statique de code par interprétation abstraite .

Certaines classes de bogues n'ont rien à voir avec le code. Une documentation ou un matériel défectueux peut entraîner des problèmes d'utilisation du système, même si le code correspond à la documentation. Dans certains cas, les modifications apportées au code éliminent le problème même si le code ne correspond plus à la documentation. Les systèmes embarqués fonctionnent souvent autour de bogues matériels, car créer une nouvelle version d'une ROM est beaucoup moins cher que de reconditionner le matériel, surtout s'il s'agit d' articles de base .

Benchmark des bugs

Pour faciliter la recherche reproductible sur les tests et le débogage, les chercheurs utilisent des repères de bogues organisés :

  • la référence Siemens
  • ManyBugs est une référence de 185 bogues C dans neuf programmes open source.
  • Defects4J est un benchmark de 341 bugs Java issus de 5 projets open-source. Il contient les correctifs correspondants, qui couvrent une variété de types de correctifs.
  • BEARS est une référence des échecs de construction d'intégration continue se concentrant sur les échecs de test. Il a été créé en surveillant les builds de projets open-source sur Travis CI .

Gestion des bogues

La gestion des bogues comprend le processus de documentation, de catégorisation, d'attribution, de reproduction, de correction et de publication du code corrigé. Les modifications proposées au logiciel – les bogues ainsi que les demandes d'amélioration et même des versions entières – sont généralement suivies et gérées à l'aide de systèmes de suivi des bogues ou de systèmes de suivi des problèmes . Les éléments ajoutés peuvent être appelés défauts, tickets, problèmes ou, selon le paradigme de développement agile , histoires et épopées. Les catégories peuvent être objectives, subjectives ou une combinaison, comme le numéro de version , la zone du logiciel, la gravité et la priorité, ainsi que le type de problème, comme une demande de fonctionnalité ou un bogue.

Un triage des bogues passe en revue les bogues et décide si et quand les corriger. La décision est basée sur la priorité du bogue et sur des facteurs tels que les calendriers du projet. Le triage n'est pas destiné à enquêter sur la cause des bogues, mais plutôt sur le coût de leur résolution. Le triage se fait régulièrement, et passe par les bogues ouverts ou rouverts depuis la réunion précédente. Les participants au processus de triage sont généralement le chef de projet, le responsable du développement, le responsable des tests, le responsable de la construction et les experts techniques.

Gravité

La gravité est l'intensité de l'impact du bogue sur le fonctionnement du système. Cet impact peut être une perte de données, financière, une perte de clientèle et un gaspillage d'efforts. Les niveaux de gravité ne sont pas standardisés. Les impacts diffèrent d'un secteur à l'autre. Un crash dans un jeu vidéo a un impact totalement différent d'un crash dans un navigateur Web ou un système de surveillance en temps réel. Par exemple, les niveaux de gravité des bogues peuvent être « plantage ou blocage », « aucune solution de contournement » (ce qui signifie qu'il n'y a aucun moyen pour le client d'accomplir une tâche donnée), « a une solution de contournement » (ce qui signifie que l'utilisateur peut toujours accomplir la tâche), « visuel défaut" (par exemple, une image manquante ou un bouton ou un élément de formulaire déplacé), ou "erreur de documentation". Certains éditeurs de logiciels utilisent des sévérités plus qualifiées telles que « critique », « élevée », « faible », « bloquante » ou « triviale ». La gravité d'un bogue peut être une catégorie distincte de sa priorité de correction, et les deux peuvent être quantifiées et gérées séparément.

Priorité

La priorité contrôle l'emplacement d'un bogue dans la liste des modifications planifiées. La priorité est décidée par chaque éditeur de logiciel. Les priorités peuvent être numériques, telles que 1 à 5, ou nommées, telles que « critique », « élevée », « faible » ou « différée ». Ces échelles d'évaluation peuvent être similaires ou même identiques aux évaluations de gravité , mais sont évaluées comme une combinaison de la gravité du bogue et de son effort estimé pour le corriger ; un bogue de faible gravité mais facile à corriger peut avoir une priorité plus élevée qu'un bogue de gravité modérée qui nécessite des efforts excessifs pour être corrigé. Les cotes de priorité peuvent être alignées sur les versions du produit, telles que la priorité "critique" indiquant tous les bogues qui doivent être corrigés avant la prochaine version du logiciel.

Versions logicielles

Il est courant de publier des logiciels avec des bogues connus et de faible priorité. Les bogues de priorité suffisamment élevée peuvent justifier une version spéciale d'une partie du code contenant uniquement les modules avec ces correctifs. Ceux-ci sont connus sous le nom de patchs . La plupart des versions incluent un mélange de changements de comportement et de multiples corrections de bogues. Les versions qui mettent l'accent sur les corrections de bogues sont appelées versions de maintenance , pour les différencier des versions majeures qui mettent l'accent sur les ajouts ou les modifications de fonctionnalités.

Les raisons pour lesquelles un éditeur de logiciel choisit de ne pas corriger ou même de corriger un bogue particulier incluent :

  • Un délai doit être respecté et les ressources sont insuffisantes pour corriger tous les bogues avant la date limite.
  • Le bogue est déjà corrigé dans une prochaine version, et il n'est pas prioritaire.
  • Les modifications nécessaires pour corriger le bogue sont trop coûteuses ou affectent trop d'autres composants, nécessitant une activité de test majeure.
  • Il peut être soupçonné, ou connu, que certains utilisateurs se fient au comportement bogué existant ; un correctif proposé peut introduire une modification avec rupture .
  • Le problème se situe dans un domaine qui sera obsolète avec une prochaine version ; le réparer est inutile.
  • "Ce n'est pas un bug, c'est une fonctionnalité". Un malentendu est né entre un comportement attendu et perçu ou une caractéristique non documentée .

Les types

Dans les projets de développement de logiciels, une "erreur" ou une "faute" peut être introduite à n'importe quelle étape. Les bogues proviennent d'oublis ou de malentendus commis par une équipe logicielle lors de la spécification, de la conception, du codage, de la saisie de données ou de la documentation. Par exemple, un programme relativement simple pour classer par ordre alphabétique une liste de mots, la conception peut ne pas tenir compte de ce qui doit se passer lorsqu'un mot contient un trait d'union . Ou lors de la conversion d'une conception abstraite en code, le codeur peut créer par inadvertance une erreur de un par un et ne pas trier le dernier mot d'une liste. Les erreurs peuvent être aussi simples qu'une faute de frappe : un "<" là où un ">" était prévu.

Une autre catégorie de bogue est appelée une condition de concurrence qui peut se produire lorsque des programmes ont plusieurs composants s'exécutant en même temps. Si les composants interagissent dans un ordre différent de celui prévu par le développeur, ils pourraient interférer les uns avec les autres et empêcher le programme de terminer ses tâches. Ces bogues peuvent être difficiles à détecter ou à anticiper, car ils peuvent ne pas se produire à chaque exécution d'un programme.

Les erreurs conceptuelles sont l'incompréhension d'un développeur de ce que le logiciel doit faire. Le logiciel résultant peut fonctionner selon la compréhension du développeur, mais pas ce qui est vraiment nécessaire. Autres types:

Arithmétique

Logique

Syntaxe

  • Utilisation du mauvais opérateur, comme effectuer une affectation au lieu d' un test d'égalité . Par exemple, dans certaines langues, x=5 définira la valeur de x sur 5 tandis que x==5 vérifiera si x est actuellement 5 ou un autre nombre. Les langages interprétés permettent à un tel code d'échouer. Les langages compilés peuvent détecter de telles erreurs avant le début des tests.

Ressource

Multi-threading

Interfaçage

  • Utilisation incorrecte de l'API.
  • Implémentation incorrecte du protocole.
  • Manipulation matérielle incorrecte.
  • Hypothèses incorrectes d'une plate-forme particulière.
  • Systèmes incompatibles. Une nouvelle API ou un nouveau protocole de communication peut sembler fonctionner lorsque deux systèmes utilisent des versions différentes, mais des erreurs peuvent se produire lorsqu'une fonction ou une fonctionnalité implémentée dans une version est modifiée ou manquante dans une autre. Dans les systèmes de production qui doivent fonctionner en continu, l'arrêt de l'ensemble du système pour une mise à jour majeure peut ne pas être possible, comme dans l'industrie des télécommunications ou Internet. Dans ce cas, des segments plus petits d'un grand système sont mis à niveau individuellement, afin de minimiser les perturbations sur un grand réseau. Cependant, certaines sections peuvent être négligées et ne pas être mises à niveau, et provoquer des erreurs de compatibilité qui peuvent être difficiles à trouver et à réparer.
  • Annotations de code incorrectes

Travail d'équipe

  • mises à jour non propagées ; par exemple, le programmeur modifie "myAdd" mais oublie de modifier "mySubtract", qui utilise le même algorithme. Ces erreurs sont atténuées par la philosophie Ne vous répétez pas .
  • Commentaires obsolètes ou incorrects : de nombreux programmeurs supposent que les commentaires décrivent précisément le code.
  • Différences entre la documentation et le produit.

Conséquences

La quantité et le type de dommages qu'un bogue logiciel peut causer affectent naturellement la prise de décision, les processus et la politique concernant la qualité du logiciel. Dans des applications telles que les vols spatiaux habités ou la sécurité automobile , étant donné que les failles logicielles peuvent causer des blessures ou même la mort, ces logiciels feront l'objet d'un examen et d'un contrôle de qualité beaucoup plus approfondis que, par exemple, un site Web d'achat en ligne. Dans des applications telles que la banque, où les failles logicielles peuvent causer de graves dommages financiers à une banque ou à ses clients, le contrôle de la qualité est également plus important que, par exemple, une application de retouche photo. Le Software Assurance Technology Center de la NASA a réussi à réduire le nombre d'erreurs à moins de 0,1 pour 1 000 lignes de code ( SLOC ), mais cela n'a pas été jugé faisable pour les projets du monde des affaires.

Selon une étude de la NASA sur " Flight Software Complexity ", " un processus de développement logiciel exceptionnellement bon peut réduire les défauts à 1 défaut pour 10 000 lignes de code ".

Outre les dommages causés par les bugs, une partie de leur coût est due aux efforts investis pour les corriger. En 1978, Lientz et al. ont montré que la médiane des projets investit 17 % de l'effort de développement dans la correction de bogues. Une recherche en 2020 sur les référentiels GitHub a montré que la médiane est de 20 %.

Bogues bien connus

Un certain nombre de bogues logiciels sont devenus bien connus, généralement en raison de leur gravité: les exemples incluent divers accidents d'avions spatiaux et militaires. Le bogue le plus célèbre est peut-être le problème de l' an 2000 , également connu sous le nom de bogue Y2K, dans lequel on craignait qu'un effondrement économique mondial ne se produise au début de l'année 2000 à la suite d'ordinateurs pensant que c'était 1900. (En fin de compte , aucun problème majeur n'est survenu.) La perturbation des opérations boursières de 2012 impliquait une telle incompatibilité entre l'ancienne API et une nouvelle API.

Dans la culture populaire

  • Dans le roman de 1968 2001: A Space Odyssey et dans le film correspondant de 1968 2001: A Space Odyssey , l'ordinateur de bord d'un vaisseau spatial, HAL 9000 , tente de tuer tous les membres de son équipage. Dans le roman de suivi de 1982, 2010: Odyssey Two , et le film d'accompagnement de 1984, 2010 , il est révélé que cette action a été causée par le fait que l'ordinateur a été programmé avec deux objectifs contradictoires: divulguer pleinement toutes ses informations et garder le véritable objectif du secret de vol de l'équipage ; ce conflit a rendu HAL paranoïaque et finalement meurtrier.
  • Dans la version anglaise de la chanson Nena 1983 99 Luftballons (99 Red Balloons) à la suite de "bugs dans le logiciel", la sortie d'un groupe de 99 ballons rouges est confondue avec un lancement de missile nucléaire ennemi, nécessitant une réponse de lancement équivalente , entraînant une catastrophe.
  • Dans la comédie américaine de 1999 Office Space , trois employés tentent d'exploiter la préoccupation de leur entreprise de corriger le bogue informatique Y2K en infectant le système informatique de l'entreprise avec un virus qui envoie des centimes arrondis sur un compte bancaire séparé. Le plan se retourne contre lui car le virus lui-même a son propre bogue, qui envoie prématurément de grosses sommes d'argent sur le compte.
  • Le roman de 2004 The Bug , d ' Ellen Ullman , raconte la tentative d'un programmeur de trouver un bogue insaisissable dans une application de base de données.
  • Le film canadien de 2008 Control Alt Delete raconte l'histoire d'un programmeur informatique à la fin de 1999 qui luttait pour corriger les bogues de son entreprise liés au problème de l'an 2000.

Voir également

Les références

Liens externes