Évitez ces 5 choses lorsque vous publiez un logiciel

Le coût d'une défaillance logicielle peut être ressenti de différentes manières : dans le cours de l'action d'une entreprise publique, par exemple, ou dans une petite entreprise, cela peut signifier la faillite.

Trop souvent, je vois des organisations publier des logiciels d'une manière à peu près aussi sûre que de jouer à un jeu de roulette russe - jouer avec la sécurité de leurs clients, les données privées et la sécurité, sans parler de la fiabilité. Ils jouent également avec la réputation et les résultats de leur entreprise. IEEE a publié un excellente liste des échecs publics il y a quelques années et vous pouvez être sûr que le logiciel échoue toujours. 

La raison pour laquelle j'aime cette analogie quelque peu effrayante est que j'entends trop souvent des gens dire des choses comme «Ce logiciel est sorti depuis longtemps et n'a pas eu de problèmes» ou «Nous l'avons toujours fait de cette façon et fonctionne »- mais bien sûr, c'est une mauvaise façon de planifier. Une entreprise spécialisée dans l'ingénierie logicielle cherche des moyens de créer et de publier de meilleurs logiciels qui échouent moins. Cela signifie planifier de manière proactive le succès en faisant la bonne chose, même si faire la mauvaise chose a fonctionné jusqu'à présent.

Chercheurs à Harvard ont constaté que quelque chose comme la moitié des projets de logiciels informatiques échouent. Il y a beaucoup de chiffres provenant d'autres pays et cette estimation n'est pas la plus élevée, alors prenons-la une minute. C'est comme jouer à la roulette russe avec 3 balles dans la chambre - une chance d'échec de 50 à 50. Je n'aime pas ces chances et je ne miserais certainement pas sur l'avenir de mon entreprise.

Examinons quelques-uns des mauvais paris que les gens prennent chaque jour lorsqu'ils publient leur logiciel. Des balles dans leur pistolet à roulette, si vous voulez:

1. Anciens bogues connus

Nous savons tous que nous publions des logiciels avec des bogues, car un logiciel sans défaut prendrait une éternité à créer. Mais ce n'est pas une excuse pour ne jamais corriger les bogues que nous connaissons. On a beaucoup parlé de la dette technique en termes très abstraits, mais il s'agit d'une véritable mesure pratique de la dette dans votre logiciel. S'il y a un bug là-bas et que vous ne le corrigez pas, vous feriez mieux d'avoir une assez bonne raison pour laquelle vous pensez que cela n'a pas d'importance. Prévoyez du temps pour chaque version non seulement pour ajouter de nouvelles fonctionnalités, mais pour améliorer les choses de manière générale. Prenez le temps de peaufiner votre logiciel.

2. Nouveaux bogues dans l'ancien code

L'ancien code est compliqué. J'ai vu des entreprises qui ont une politique de « nettoyez-le si vous le réparez quand même » et d'autres où la règle est « ne touchez que ce que vous devez, et uniquement lorsqu'il y a un bogue signalé sur le terrain ». Les deux sont des politiques intéressantes, mais le plus important est de comprendre le risque encouru lorsque vous trouvez un nouveau bogue dans l'ancien code. Je travaillais avec un fournisseur de matériel et ils avaient du mal à gérer la sortie d'un nouvel outil sur du code hérité. Dans leur cas, c'était un problème de portée ambigu qui me laisse encore me demander comment leur compilateur a pu permettre une telle folie. Ils se heurtaient à un conflit – d'un côté, ils avaient ce nouvel outil, et de l'autre ils n'étaient pas censés toucher à l'ancien code à moins qu'il y ait eu un rapport de bogue sur le terrain.

Il est important de comprendre ce que vous prévoyez de faire avec votre ancien code, ainsi que de bien comprendre ses risques pour votre organisation. Si le code est critique, l'âge n'a peut-être pas autant d'importance que vous le pensez. Si le code est obsolète, vous perdez peut-être du temps à tester des choses que vous n'avez pas l'intention de corriger.

3. La sécurité dans le cadre des tests plutôt que du développement

Il est malheureusement courant pour les organisations de négliger la sécurité. Dans certains cas, ils pensent pouvoir tester la sécurité dans leur application (ils ne le peuvent pas), tandis que dans d'autres cas, ils pensent que les problèmes de sécurité ne s'appliqueront pas à leur code (ils le feront). Afin de sortir de ce gâchis de défaillances de sécurité constantes, les entreprises doivent renforcer le code avec les bonnes pratiques AppSec, telles que codifiées dans un outil d'analyse statique qui fait plus qu'une simple analyse de flux. Si vous ne savez pas par où commencer, cela ne ferait pas de mal de simplement prendre les règles MISRA et de commencer à les suivre pour tout code que vous écrivez à partir d'aujourd'hui.

4. La suite de tests toujours en échec et toujours réussie

Une pratique extrêmement courante et dangereuse que je vois est d'avoir une grande suite de tests et de s'appuyer sur une simple métrique du nombre de tests qui ont réussi. Par exemple, vous avez généralement un taux de réussite de 80%, vous pensez donc que tout ira bien. Le problème, c'est qu'il n'y a aucun moyen de savoir si les 80% qui ont été adoptés aujourd'hui sont les mêmes que les 80% qui ont été adoptés hier. Il pourrait facilement y avoir un nouvel échec réel caché dans ces 80% (il y en a) parce que quelque chose d'autre a été corrigé, laissant le nombre équilibré. Gardez votre suite de tests propre ou elle ne vous dit pas grand-chose. Je doute sérieusement de la valeur d'un échec de test que vous vous sentez à l'aise d'ignorer. Pourquoi ne pas simplement sauter ce test - c'est une approche plus honnête et utile.

5. Publication sur le calendrier

Le calendrier est probablement toujours le critère de publication crucial le plus courant. Les gens ont choisi une date et maintenant ils vont sortir parce que cette date est arrivée. Certes, il y a des problèmes externes qui influencent votre calendrier de publication, mais ce n'est pas parce qu'une date est arrivée que vous pouvez pousser un logiciel minable sur vos futurs clients sans méfiance. Relâchez quand il est prêt / sûr / stable / bon. Si le calendrier est une contrainte fixe, assurez-vous que votre processus vous y conduira à temps.

Conclusion

Combien de fois pouvez-vous sortir comme ça avant d'en payer le prix? Dans notre analogie avec la roulette russe, au plus six, peut-être aussi peu qu'un. Faisons de notre mieux pour nous assurer que nous allons fournir le meilleur logiciel avec les meilleures chances de succès.

« MISRA », « MISRA C » et le logo triangulaire sont des marques déposées de The MISRA Consortium Limited. ©The MISRA Consortium Limited, 2021. Tous droits réservés.

Par Arthur Hicken

Arthur est impliqué dans la sécurité logicielle et l'automatisation des tests chez Parasoft depuis plus de 25 ans, aidant à la recherche de nouvelles méthodes et techniques (dont 5 brevets) tout en aidant les clients à améliorer leurs pratiques logicielles.