Faits et idées fausses sur l'ingénierie logicielle

Robert L. Glass

Genres: Programmation

Année de publication: 2008

Année de lecture: 2020

Ma note: Maximale

Nombre de lectures: 1

Nombre total de pages: 233

Résumé (pages): 0

Langue originale de la publication: Anglais

Traductions dans d'autres langues: Russe, Chinois

Informations générales

Un livre de 2008 composé de 55 faits et 10 idées fausses sur les développeurs et la programmation en général. Tous les matériaux sont divisés en groupes spécifiques, par exemple : gestion, développement et autres.

Il convient de préciser tout de suite que presque tous les sujets et questions abordés par l’auteur sont très controversés (holivaires), et les avis des lecteurs peuvent différer considérablement. Pour économiser du temps et de l'espace, je ne vais pas décrire mon avis et ma vision sur chaque point. Ici, je vais simplement énumérer rapidement tous les faits et idées fausses, puis à la fin je donnerai une évaluation générale du livre. Chaque fait ou idée fausse est présenté sous la forme d'un article moyen, donc si cela vous intéresse, vous pouvez lire non pas tout le livre, mais choisir des sujets spécifiques. Avant de lister tous les faits et idées fausses, il convient de noter que l’auteur suit une structure claire dans la présentation du matériel :

• Tout d'abord, il discute du fait ou de l'idée fausse.
• Ensuite, il décrit les débats et discussions à son sujet.
• Enfin, il fournit des sources d'information relatives au sujet.

Faits sur la programmation

Facteur humain

1. Le facteur le plus important dans le développement de logiciels n'est pas les méthodes et les outils utilisés par les programmeurs, mais les programmeurs eux-mêmes.
2. Selon une étude sur les différences personnelles, les meilleurs programmeurs surpassent les plus faibles jusqu'à 28 fois. Si l'on considère que leur rémunération n'est jamais proportionnelle, le meilleur programmeur est l’acquisition la plus avantageuse de l’industrie du logiciel.
3. Si un projet ne respecte pas les délais, l'ajout de main-d'œuvre ne fera que le retarder davantage.
4. Les conditions de travail ont une forte influence sur la productivité et la qualité des résultats.
5. La publicité autour des outils et méthodes est un fléau pour l'industrie du logiciel. La plupart des améliorations des outils et méthodes n'augmentent la productivité et la qualité que de 5 à 35 %. Mais beaucoup de ces améliorations ont été annoncées comme offrant un avantage « de l'ordre de grandeur ».
6. Apprendre une nouvelle méthode ou un nouvel outil diminue d'abord la productivité des programmeurs et la qualité du produit. Les bénéfices de l’apprentissage ne peuvent être tirés qu’après avoir franchi la courbe d'apprentissage. Par conséquent, l’introduction de nouvelles méthodes et outils n'a de sens que si a) leur valeur réelle est évidente et b) l’on fait preuve de patience en attendant les gains.
7. Les développeurs parlent beaucoup des outils. Ils en essaient beaucoup, en achètent suffisamment, mais ne travaillent pratiquement jamais avec eux.
8. La cause la plus fréquente de l'ingouvernabilité d'un projet est une mauvaise estimation. (La deuxième raison est abordée dans le Fait 23.)
9. La plupart des évaluations dans les projets logiciels sont effectuées au début du cycle de vie. Cela ne nous dérange pas tant que nous ne comprenons pas que les évaluations ont été faites avant que les exigences ne soient définies, et donc avant que la tâche ne soit étudiée. Par conséquent, les évaluations sont généralement faites trop tôt.
10. La plupart des évaluations dans les projets logiciels sont faites soit par les cadres supérieurs, soit par le personnel marketing, et non par ceux qui vont créer le logiciel, ni leurs responsables. Ainsi, l'évaluation est effectuée par les mauvaises personnes.
11. Les évaluations des projets logiciels sont rarement révisées ensuite. En d'autres termes, les évaluations faites par les mauvaises personnes et au mauvais moment ne sont généralement pas corrigées.
12. Etant donné que les évaluations sont si erronées, il n'y a pas tant de raisons de s'inquiéter de ce que les projets logiciels ne sont pas terminés dans les délais fixés par les évaluations. Pourtant, tout le monde s'en inquiète.
13. Il n'y a pas de contact entre les gestionnaires et les programmeurs. Dans une étude sur un projet qui n’a pas respecté les paramètres définis en fonction de l’évaluation et qui a été considéré comme un échec par la direction, les exécutants techniques l’ont qualifié de projet le plus réussi sur lequel ils aient jamais travaillé.
14. L'analyse de faisabilité d'un projet donne presque toujours une réponse « oui ».
15. La réutilisation « en miniature » (dans les bibliothèques de sous-programmes) existe depuis presque 50 ans et cette tâche est bien maîtrisée.
16. Le problème de la réutilisation « à grande échelle » (dans les composants) reste en grande partie non résolu, bien que tout le monde s'accorde à dire qu'il est très important de le faire.
17. Le succès de la réutilisation à grande échelle est maximal dans les familles de systèmes apparentés, et dépend donc du domaine d'application. Cela limite la portée de la réutilisation à grande échelle.
18. Dans la pratique de la réutilisation, il existe deux « règles des trois » : a) les composants réutilisés plusieurs fois sont trois fois plus coûteux que les composants à usage unique ; et b) un composant réutilisé plusieurs fois doit être testé dans trois applications différentes avant de pouvoir être considéré comme suffisamment général pour être inclus dans une bibliothèque de composants.
19. La modification du code réutilisé comporte un grand risque d’erreur. Si plus de 20-25 % du code d'un composant doivent être modifiés, il vaut mieux le réécrire depuis le début.
20. La réutilisation des modèles de conception est une solution aux problèmes liés à la réutilisation du code.
21. Augmenter la complexité d'une tâche de 25 % rend la solution logicielle quatre fois plus complexe. Ce n'est pas une condition que l'on peut essayer de modifier (bien que la complexité doive toujours être minimisée), c'est une réalité.
22. Quatre-vingts pour cent du travail de développement logiciel consiste en travail intellectuel. Une grande partie de ce travail peut être qualifiée de créatif. Et seulement une petite partie relève de l’aspect technique.

Exigences

23. Une des deux causes les plus fréquentes de l’ingouvernabilité des projets est l’évolution des exigences. (L’autre cause est abordée dans le Fait 8.)
24. Corriger les erreurs dans les exigences est le plus coûteux lorsqu'elles sont découvertes lors de la phase d'exploitation, et le moins coûteux lorsqu'elles sont identifiées tôt dans le processus de développement.
25. Les exigences manquantes sont l'erreur la plus difficile à corriger.

Conception

26. Au fur et à mesure de l’avancement des exigences initiales à l’architecture, une avalanche de « exigences dérivées » (exigences pour des solutions de conception spécifiques) s’abat sur nous, en raison de la complexité du processus. La liste de ces exigences dérivées est souvent 50 fois plus longue que l'originale.
27. La meilleure solution de conception pour une tâche de programmation est rarement la seule.
28. La conception est un processus complexe et itératif. La première solution de conception sera probablement incorrecte et, sans aucun doute, sous-optimale.

Codage

29. Les programmeurs passent de la conception au codage lorsqu'ils ont décomposé la tâche en « primitives » maîtrisées par le concepteur. Si le programmeur et le concepteur sont deux personnes différentes, les primitives du concepteur ne correspondront probablement pas à celles du programmeur, ce qui entraînera des problèmes.
30. COBOL est un très mauvais langage, mais tous les autres (pour le traitement des données d’entreprise) sont bien pires.
31. La phase de débogage est la plus coûteuse dans le cycle de vie.

Test

32. Il s'avère que dans les logiciels, que le programmeur moyen pense être soigneusement testés, on vérifie souvent seulement 55–60% des chemins logiques. L'utilisation d'outils automatisés, tels que les analyseurs de couverture, permet d'augmenter cette proportion à environ 85–90%. Tester 100% des chemins logiques d'un logiciel est pratiquement impossible.
33. Même si une couverture de test à 100% était possible, elle ne serait pas un critère suffisant pour juger de la qualité du test. Environ 35% des défauts logiciels sont causés par des chemins logiques manquants, et 40% supplémentaires sont liés à l'exécution d'une combinaison unique de chemins logiques. Ces défauts ne peuvent pas être détectés avec une couverture de test à 100%.
34. Sans outils, il est presque impossible de faire un travail de correction des erreurs de manière efficace. Les débogueurs sont largement utilisés – contrairement à d'autres outils, comme les analyseurs de couverture de test.
35. Les tests sont rarement automatisés. C'est-à-dire que certains processus de test peuvent et doivent être automatisés. Cependant, une grande partie du travail lié aux tests ne peut pas être automatisée.
36. Un complément important aux outils de test est le code de débogage intégré créé par le programmeur, de préférence activé dans le code objet en fonction des directives de compilation.
37. Des inspections minutieuses permettent de corriger jusqu'à 90% des erreurs du produit logiciel avant qu'un premier test de référence soit effectué.
38. Les inspections minutieuses offrent de nombreux avantages, mais elles ne peuvent pas remplacer les tests.
39. Il est reconnu que les revues effectuées après coup (également appelées rétrospectives) sont importantes tant du point de vue des intérêts du consommateur (utilisateur du logiciel) que pour améliorer le processus. Cependant, dans la plupart des organisations, les revues rétrospectives ne sont pas effectuées.
40. Dans les inspections, en plus des facteurs techniques, il y a également des facteurs sociaux. Accorder plus d'attention à un aspect au détriment d'un autre mène directement à la catastrophe.
41. Le coût de la maintenance représente généralement de 40 à 80% (en moyenne 60%) du coût du logiciel. Par conséquent, cette phase de son cycle de vie est probablement la plus importante.
42. Environ 60% des dépenses de maintenance sont consacrées à l'amélioration du code et environ 17% à la correction des erreurs. Ainsi, la maintenance et le support logiciel se concentrent principalement sur l'ajout de nouvelles fonctionnalités plutôt que sur la correction.
43. La maintenance est une solution, pas un problème.
44. Si l'on compare les tâches de développement et de maintenance du logiciel, elles sont en grande partie identiques, à l'exception de la tâche supplémentaire de maintenance, qui consiste à « étudier le produit maintenu ». Cela prend environ 30% du temps consacré à la maintenance dans son ensemble, et cette activité prédomine dans la maintenance. Ainsi, on peut dire que la maintenance est plus gourmande en ressources que le développement.
45. L'amélioration de la qualité du développement logiciel conduit à une augmentation, et non à une diminution, de la maintenance.

Qualité

46. La qualité est un ensemble de propriétés.
47. La qualité n'est pas déterminée par la satisfaction de l'utilisateur, la conformité aux exigences du client, l'acceptabilité du prix et le respect des délais de livraison du produit, ou la fiabilité.
48. Il existe des erreurs auxquelles la plupart des programmeurs sont prédisposés.
49. Les erreurs ont tendance à se regrouper.
50. Il n'existe pas encore une approche unique et meilleure pour éliminer les erreurs.
51. On ne peut pas éviter les erreurs. L'objectif est d'éviter les erreurs critiques ou de les minimiser.

Efficacité

52. L'efficacité dépend davantage de la conception de qualité de l'application que de la programmation de qualité.
53. L'efficacité du code en langage de haut niveau, compilé avec les bons paramètres d'optimisation, peut atteindre 90% de l'efficacité d'un code assembleur fonctionnellement équivalent. Et dans certaines architectures modernes complexes, cela peut même être plus élevé.
54. Il existe des compromis entre l'optimisation de la taille et l'optimisation de la vitesse. Souvent, l'amélioration du premier facteur entraîne une dégradation du second.

Sur les recherches scientifiques

55. De nombreux scientifiques travaillant dans l'industrie du logiciel ont tendance à défendre leurs théories plutôt qu'à mener des recherches. Résultat : a) la valeur de certaines théories propagées est bien inférieure à ce que croient leurs défenseurs ; b) il y a peu de recherches visant à déterminer quelle est la véritable valeur de ces théories.

Illusions de la programmation

1. Il est impossible de gérer ce qui ne peut pas être mesuré.
2. La gestion peut rendre le produit logiciel de qualité.
3. La programmation peut et doit être impersonnelle.
4. Les outils et les technologies sont universels.
5. La programmation nécessite plus de méthodologies.
6. Pour estimer les coûts et déterminer les délais, commencez par compter les lignes de code.
7. L'utilisation de données d'entrée aléatoires est un bon moyen d'optimiser les tests.
8. « Toutes les erreurs deviennent visibles si suffisamment d'yeux se posent dessus ».
9. En connaissant le coût de la maintenance dans le cas précédent, on peut prédire combien cela coûtera à l'avenir et décider de l'opportunité de remplacer le produit.
10. On peut enseigner la programmation en montrant comment écrire des programmes.

Conclusion

Bien que le livre ait été écrit en 2008, je le recommande toujours à ceux qui étudient la programmation. En revanche, le premier inconvénient qui saute aux yeux est qu'il est difficile de confirmer ou d'infirmer les pourcentages et chiffres que l'auteur mentionne dans certains faits. Il y a aussi quelques faits qui, à ce jour, ont perdu de leur pertinence. Cependant, dans l'ensemble, la grande majorité du contenu reste pertinent, et il sera utile de le lire non seulement pour les développeurs, mais aussi pour les managers.