Selon vous, quelle est la principale cause des défauts logiciels (et comment les minimiser) [fermé]

Je définis le défaut comme:

"quelque chose dans la conception ou le code de l'application qui l'empêche de fonctionner conformément aux exigences."

Je cherche des idées sur les causes des défauts, par exemple le facteur humain, le manque de tests, le manque de prototypage et les idées possibles pour les atténuer.

L'interprétation est la principale cause de défauts logiciels.

L'interprétation client d'une fonctionnalité diffère de l'interprétation du concepteur.

L'interprétation du concepteur diffère de l'interprétation du programmeur.

La plupart des méthodologies ont inventé des moyens de contrer cet effet. Mais au final, nous ne sommes que des humains et nous ne sommes pas sans défaut. En outre, il y a souvent une pression temporelle et la plupart de la magie méthodologique est souvent ignorée sous pression.

Les tests ne peuvent détecter les problèmes que tôt. Mais même les testeurs sont humains, et il est impossible de tester à 100%. Si vous voulez sortir avant la fin de l'univers.

Je considère que les programmeurs sont la principale cause des défauts logiciels.

Je ne dis pas cela juste pour être drôle, mais parce que l'un des gros problèmes que j'ai observés dans mon travail est la mauvaise collecte des exigences, associée à une mauvaise compréhension du domaine problématique, provoquant des défauts majeurs et des problèmes d'utilisabilité dans le projet.

Cela vient en partie du fait de ne pas vouloir apprendre / comprendre la terminologie de l'utilisateur final, ce qui provoque des malentendus.

Cela vient en partie du fait de parler de la technologie trop tôt dans le processus à des personnes qui ne savent pas de quoi vous parlez ou pourquoi cela est important.

Le meilleur exemple de cela était quand j'ai entendu l'un des programmeurs essayer de comprendre combien de temps les questions / réponses allaient être en caractères ... Je savais qu'il essayait de comprendre quelle taille de champ utiliser dans la base de données, mais le le département qui demandait cela n'avait pas le plus brumeux pourquoi cela comptait - ou que les espaces comptaient. Pour nous, cela semble évident, mais pour eux, c'était une véritable révélation.

La principale cause de défauts est une mauvaise gestion ;)

Sérieusement, un développeur qui fonctionne en bon état, à qui il n'est pas demandé de surcharger, de réduire la qualité, d'avoir des outils appropriés, des conditions de travail silencieuses, etc. produira moins de bugs que quelqu'un travaillant sous une forte pression.

La gestion de l'embauche de mauvais développeurs permet également d'augmenter le nombre de bogues.

Mauvaise gestion .

(Avertissement: je suis censé embaucher et gérer des développeurs)

Je ne vois aucune cause principale - mais une cause qui n'a pas été mentionnée est le couplage involontaire avec un autre code . L'écriture de code qui a des effets secondaires invisibles, traverse les couches d'abstraction, fait des hypothèses sur les données (les variables ne le sont pas, les constantes ne le sont pas et aucune entrée d'un utilisateur n'est sûre), fouille avec des choses qu'il n'a pas besoin de concerner lui-même avec, et ainsi de suite.

La plupart des pratiques de développement que j'étudie se résument à une réduction N, car la complexité d'un programme l'est au moins O(N^2)et peut-être O(k^N). La définition Nreste un exercice pour le lecteur, mais je pense à des choses comme la complexité cyclomatique ici. L'encapsulation de la logique et des données a pour effet de réduire N en compartimentant le problème.

L'impossibilité de penser à tout.

Être incomplet

Manque de communication. Dans la collecte des exigences. Dans le calendrier. Dans le document de conception. Dans les spécifications fonctionnelles. Dans le code (écart entre ce que le programmeur veut et ce qu'il dit au compilateur).

Etiquette sociale. Il est socialement inacceptable d'appeler quelqu'un incapable.

Se précipiter dans les choses sans les comprendre pleinement. Commencer à écrire du code sans bien comprendre les exigences fonctionnelles ou l'architecture technique.

La programmation devrait être presque automatique, il suffit d'écrire ce qui va de soi et a déjà été élaboré dans l'esprit. Dans la pratique, je vois beaucoup de fléaux dans le code pour essayer de comprendre exactement ce que le code est censé faire. J'en ai moi-même été coupable plusieurs fois.

Errare humanum est

Schedule Pressure est certainement une source solide.

Les développeurs précipités ne prennent pas le temps de spécifier complètement les exigences, ni de comprendre pleinement l'intention derrière les exigences, ni d'enquêter pleinement sur les alternatives pour trouver la meilleure solution, ou de réfléchir pleinement à tous les cas extrêmes et aux interactions des changements qu'ils apportent, ou développer un ensemble complet de cas de test, ou effectuer entièrement tous les tests unitaires, ou effectuer un test d'intégration complet, ou tenir pleinement compte des dépendances de la plate-forme, ou tester complètement le programme d'installation, ou documenter entièrement ce qu'ils ont fait pour que le prochain développeur puisse comprendre ....

Une autre chose qui doit être mentionnée est de ne pas avoir de test externe. Lorsque le développeur écrit les tests et les exécute, il teste uniquement son interprétation et non l'exigence réelle. Bien que les tests unitaires écrits par les développeurs soient utiles pour détecter certains bogues, la plupart des bogues auront passé ces tests mais ne seront pas ce que l'utilisateur veut ou a besoin. Tout logiciel non testé par une personne autre que le développeur n'est pas testé (et je ne parle pas simplement d'exécuter les tests du développeur).

C'est parce que le génie logiciel est intrinsèquement complexe. L'essai «No Silver Bullet» en discute.

Ironiquement, bon nombre des autres réponses ici touchent à des sujets qui sont «accidentellement complexes», dans le langage de cet essai, alors qu'en réalité la plupart de ce que font les développeurs de logiciels est «essentiellement complexe», donc c'est juste dans la nature de cela que la création le logiciel est difficile, le logiciel aura des bogues, et notre travail consiste à y faire face.

L'incapacité à comprendre le logiciel comme un réseau de machines à états, les principes qui sous-tendent leur fonctionnement (états, leur détermination et leurs transitions) et les interactions des machines à états.

Écriture de code qui échoue silencieusement par rapport à un code qui signale toutes les erreurs.

Le manque de vérification des choses qui «ne peuvent pas arriver» ou qui sont peu susceptibles de se produire est un gros problème. Parfois, le parfait est l'ennemi du bien. Si cela ne vaut pas une hiérarchie d'exceptions bien pensée, une manipulation rapide et sale est toujours meilleure que rien. Je suis un énormefan d'échouer rapidement, d'assertions et de laisser des assertions qui ont un impact négligeable sur les performances dans les versions. Même dans des scripts ponctuels rapides et sales où je contrôle toutes les données d'entrée, je mets en place une gestion rapide / sale des erreurs, généralement juste avec une fonction équivalente à assert mais qui reste active tout le temps. Ma règle générale est que, si cela ne se produit pas ou si vous pensez que cela ne peut pas se produire, il n'a pas besoin d'échouer avec élégance avec un message d'erreur convivial, mais il devrait au moins échouer rapidement avec un message d'erreur qui donne au programmeur quelques conseils sur ce qui n'a pas fonctionné.

Modifier: Une tactique utile connexe consiste à utiliser les assertions comme un outil de débogage majeur et à les laisser là après la fin de la session de débogage. À partir de ce moment, votre base de code aura des vérifications d'intégrité intégrées qui rendront très difficile la réapparition des bogues associés. Ceci est particulièrement utile pour le code difficile à tester.

La principale cause de défauts logiciels est l'écriture de code.

Écrivez moins de code et vous aurez moins de bugs ;-)

À un niveau, la gestion. Mais ce n'est pas seulement le PHB. C'est la gestion du code lui-même, qui peut ou non être le reflet de la gestion de l'entreprise.

Les participants à l'ensemble du "cycle de vie" doivent être pleinement investis dans la qualité et faire un produit qui ne meurt tout simplement pas . Le logiciel lui-même a la promesse de ne jamais se casser, étant donné la fiabilité appropriée de l'abstraction. Il s'agit seulement de savoir si les constructeurs de logiciels sont intéressés à avoir ce fonctionnement parfait.