Le logiciel contrôle des aspects de plus en plus nombreux, complexes et parfois vitaux de notre quotidien. Les méthodes actuelles de développement reposent encore largement sur le codage manuel et les tests. Celles-ci peinent à offrir des garanties fortes sur l’absence de bogues. Nous présentons ici quelques techniques d’analyse de design et de code ainsi que des outils informatiques correspondant afin d’accroître l’assurance qualité.
Les méthodes actuelles de développement reposent largement sur l’humain qui est faillible. Un logiciel peut donc contenir des erreurs. Pour se prémunir des erreurs humaines lors du développement, les industriels peuvent recourir à des étapes de test du produit logiciel, ainsi qu’à des étapes de relecture du logiciel ou de différents plans ou modèles représentant le logiciel. Toutefois, ces méthodes ont une efficacité limitée de part la complexité même des produits logiciels. Face à ce constat, des techniques spécifiques ont été développées pour vérifier les logiciels, en utilisant la puissance de calcul offerte par les ordinateurs.
Le cycle de vie du logiciel suit plusieurs étapes, tout comme l’élaboration d’une maison. Ces étapes sont en général :
Des erreurs peuvent être commises à chacune de ces étapes, c’est pourquoi les industriels effectuent des vérifications du travail réalisé à ces différentes étapes :
Ces différentes techniques de validation sont limitées et/ou sujettes à l’erreur humaine :
La recherche en informatique s’est depuis longtemps attaquée à ces problèmes, et des solutions sont maintenant mûres pour être déployées industriellement. Nous présentons ci-dessous trois technologies à portée de main de l’industrie wallonne :
Constituer manuellement un jeu de test est souvent un travail fastidieux : la personne qui élabore ces tests procède souvent par un raisonnement mental où elle envisage des combinaisons d’entrées qui explorent en détail le comportement du logiciel. La recherche du testing a proposé des critères permettant d’estimer la qualité des jeux de test. Cela s’appelle un critère de couverture. Il existe des outils capables de générer des jeux de tests au départ d’une description fonctionnelle d’un logiciel (un modèle) et peuvent assurer la production de jeux de tests garantissant certains critères de couverture. Le prix à payer est la production du modèle et d’un composant permettant d’exécuter les tests généralement exprimés en termes plus abstraits sur l’infrastructure concrète d’implémentation.
Le CETIC dispose de l’expertise dans une série d’outils de ce type, notamment : Qtronic, NModel, Smartesting, de même qu’avec des outils d’estimations de couverture de tests permettant de vérifier la couverture effective (Cobertura, Emma, CoverageValidator…)
Un protocole de communication est un type d’algorithme très particulier visant à coordonner les actions d’un système distribué au moyen de l’échange de messages informatiques. Un protocole de communication peut contenir des erreurs bien connues sous le nom de deadlock, désynchronisation, etc. Détecter qu’un protocole contienne ce type d’erreur est extrêmement fastidieux, surtout si on souhaite que le protocole tolère des retards de transmission ou des pertes de message potentiellement causés par un réseau informatique. La recherche a mené à l’élaboration de techniques automatiques permettant de vérifier le bon comportement d’un protocole face à tous les cas de figure possibles. En utilisant ces techniques, il est possible de vérifier le bon fonctionnement du protocole avant même de l’implémenter.
Le CETIC dispose de l’expertise dans une série d’outils de ce type : SPIN, NuSMV, RODIN…
Suite à l’explosion de la fusée Ariane V lors de son vol inaugural, l’Europe a investi d’énormes moyens dans la recherche sur l’analyse de code. Pour rappel, cette catastrophe est due à une erreur logicielle dans un programme Ada. Un nombre à virgule flottante en 64 bits devait être converti en entier de 16 bits. Malheureusement, au moment du crash, ce nombre en 64 bits était trop grand que pour être représenté en 16 bits. La valeur stockée dans cet entier de 16 bits a donc été inexacte. Ces nombres intervenaient dans un calcul de calibration des gyroscopes de la fusée. A la suite de cette erreur, la fusée a perdu son équilibre et s’est détruite.
Détecter ce type d’erreur sur un logiciel est extrêmement fastidieux. Dans le cas de la fusée Ariane V, le code avait passé les différentes étapes de validation, de testing, de revue manuelle et de contrôle qualité. Le testing n’apporte donc pas de certitude quant au bon fonctionnement du code, à moins de couvrir tous les cas de figure, ce qui n’est pas toujours faisable.
L’Europe a donc investi dans le développement de technologies d’interprétation abstraite. Cette technique permet d’analyser du code pour identifier ses propriétés. Suite à cet investissement, différents logiciels d’analyse de code par interprétation abstraite ont vu le jour, dans différents domaines.
Il en est résulté une série d’outils qui ont la capacité de détecter l’entièreté des erreurs d’un type spécifique à partir du code source, sans nécessiter le développement de modèle. Sur cette base seule, ils peuvent fournir une garantie d’absence d’erreur que des vérificateurs humains utilisant des tests ne pourraient jamais fournir. En effet les tests ne peuvent pas prouver l’absence d’erreur.
Parmi ces outils citons en deux qui sont des leaders et qui sont disponibles au CETIC :
En toute généralité, nous comparons ci-dessous une approche basée sur des tests avec une approche basée sur une vérification automatique.
Les outils cités dans cet article sont, ainsi que les autres outils mentionnés dans cet article, à disposition des entreprises intéressées.