Cet article rapporte une discussion déclenchée par l'article Pourquoi ne pas copier les méthodes du logiciel embarqué.
Sommaire-
Texte de Jean Kott
Pourquoi ne pas copier les méthodes des logiciels embarqués ?
Remarques de Jean KOTT relatives à l'article de Laurent Bloch sur le même sujet.
Quelques caractéristiques des systèmes embarqués
J'admets comme embarqué tout système informatique, logiciel et matériel pilotant ou contrôlant le fonctionnement d'un dispositif physique dont les lois de comportement et d'évolution sont représentables par des règles en nombre fini formalisables sous forme d'équations ou de formules algébriques. Véhicules, systèmes industriels et asservissement divers entrent en général dans cette catégorie.Ce genre de système a une grande autonomie et n'interagit avec l'humain qu'au travers de quelques individus bien formés et particulièrement compétents.
Leur domaine et leur périmètre sont connus de manière rigoureuse : la mathématique permet, à partir des équations de comportement de connaître de manière précise les valeurs possibles en entrée et en sortie ainsi que leurs limites.
Le référentiel équationnel modélisant l'ensemble constitue un étalon de référence pour mesurer de manière juste et précise la qualité du système : preuves ou vérifications par relecture sont relativement facile à mener et les jeux d'essais sont aisés à produire automatiquement car l'on sait, pour chaque donnée en entrée, le résultat que l'on doit attendre (les formules et équations de modélisation sont là pour ça). Le déterminisme du système est total.
Le système est toujours cohérent avec la réalité qui l'entoure car l'acquisition des données est en temps réel et automatique (pas de discontinuité dans la chaine acquisition/traitement/sortie).
Le système est très souvent gouverné par les données. Les flux de contrôle en sont minimes et ne provoquent que des changements d'états très mineurs et n'entraînant que peu de complexité supplémentaire. Ce point est important car il existe quelques cas de systèmes embarqués ou le flux de contrôle est important. Dans un tel cas, la mise au point du système est beaucoup plus douloureuse (j'ai expérimenté ce genre de cas). et les méthodes classiques de développement de systèmes embarqués peuvent même être mises en défaut.
Le système est invariant dans le temps : placé dans les mêmes conditions à plusieurs époques différentes, le système aura toujours le même comportement. Cette propriété est, par ailleurs, une condition suffisante de son déterminisme. Ces propriétés permettent d'avoir une mesure précise de l'écart entre la réalité du système et ce que dit la théorie. Le « bruit » est donc bien contrôlé.
Quelques caractéristiques des systèmes d'informations d'entreprise.
On est dans un univers à l'opposé de ce qui est dit au paragraphe précédent, sauf peut-être chez les industriels baignant déjà dans une culture scientifique et technique. Il ne faut voir aucune critique ni jugement de valeur dans ce qui pourrait être interprété comme des insuffisances ou erreurs dans ce que je dis ci-après
Le domaine d'application et le périmètre, s'ils sont connus de certains des acteurs, ne sont pas ou mal formalisés.
Les exigences fonctionnelles, rarement modélisées par des règles strictes (à défaut d'équations algébriques) , sont souvent non exprimées car considérées comme allant de soi dans la culture ambiante. Mesurer la qualité d'un système dans un tel environnement relève de la gageure. Il est toujours extrêmement difficile de savoir si un dysfonctionnement relève d'un bogue du système ou de l'insuffisance des exigences initiales.
Sauf exception, les process de l'entreprise ne peuvent garantir la cohérence entre le système et la réalité (comme par exemple des écarts entre le stock réel et le stock enregistré dans le S.I.).
Le système interagit avec de nombreux humains dont la formation est souvent inappropriée ou insuffisante. Trop d'acteurs n'ont pas toujours conscience des impacts d'une saisie incomplète ou inexacte.
Les flots de contrôle sont nombreux et complexes. Le système connait ainsi de nombreux états internes dont l'influence sur le résultat des opérations est loin d'être anodin. Il n'est jamais facile de mettre en place des jeux d'essais couvrant correctement l'ensemble car la chance de pouvoir maitriser toute la combinatoire des états possibles est très faible.
Le nombre d'acteurs est tel qu'il est déraisonnable de considérer le système comme déterministe. Par exemple, si deux acheteurs sont en concurrence pour acquérir le même objet unique dans le stock (ou dernière place sur un avion), nul ne peut dire qui sera servi et la même opération avec les mêmes acteurs répétée à deux époques différentes pourra conduire à un résultat différent. Le même problème se pose pour l'allocation d'une ressource unique au sein d'une entreprise.
Le système n'est donc pas invariant dans le temps ce qui rend encore plus difficile l'élaboration de tests ayant une couverture totale. On pourrait ainsi poursuivre la compraison, mais il n'est pas très utile d'enfoncer le clou davantage.
Transposabilité des méthodes d'un univers à l'autre
Une lecture rapide de mes propos pourrait laisser supposer que je suis sévère avec les DSI et MOA d'entreprises et qu'il suffirait d'un peu plus de rigueur de leur part pour améliorer la situation.
Le problème n'est pas du tout là...
Il faudrait , en toute rigueur, distinguer le cas des entreprises pour lesquels le SI est le coeur de leur outil de production, voire leur coeur de métier, et celles chez qui le SI n'est pas ou peu présent dans la production.
Un autre point à prendre en compte est la diversité et le nombre des acteurs interragissant avec le SI. Les systèmes embarqués sont pilotés par une petite élite de gens bien formés à cette tâche. Le SI d'un banque ou d'un grand commerçant est en relation avec un grand nombre d'employés dont la compréhension du S.I. est très inhomogène voire inégale. En outre, un encore plus grand nombre de clients peuvent souvent accéder au S.I. ce qui aggrave encore les difficultés.
Ces considérations ainsi que d'autres montent qu'en entreprise, la rigueur souhaitable des exigences fonctionnelles est souvent en contradiction avec une organisation faite d'êtres humains qui ont chacun leur ego, leurs peurs, leurs certitudes et leur plus ou moins grande lucidité. Sauf à « nazifier » (pardon pour le néologisme) l'organisation d'une entreprise, les espaces de libertés laissés aux collaborateurs (surtout lorsqu'ils ont quelque responsabilité) ne permettent en général pas, d'aboutir à un ensemble d'exigences vraiment cohérentes. Il suffit de permuter deux managers pour faire évoluer les exigences d'un S.I.
Il faut donc vivre avec cette réalité, les exigences totalement formalisées pour un S.I. classique relèvent plutôt du voeu pieu. Il existe même des cas ou fixer une règle fonctionnelle d'arbitrage est impossible ce qui peut conduire à une indétermination de certains résultats (ce sont en fait les règles techniques internes du système qui arbitrent sans aucune cohérence avec la réalité fonctionnelle).
Il faut se dire que l'erreur est indissociable de l'intelligence. On ne peut concevoir comme sans erreur qu'un système dont l'humain serait totalement absent.
Il me parait plus important de pratiquer une culture qui permet de prendre du recul par rapport aux dysfonctionnements du S.I. en ne les diabolisant pas. Si les pannes sont bien anticipées et les procédures de secours connues de tous, elles sont plus facilement acceptées. Jusqu'à un certain taux (quelques heures par an ou par mois selon la criticité) elles font partie de la vie normale du S.I.
Il est bien préférable d'avoir à supporter quelques incidents que de travailler dans un univers proche de celui du meilleur des mondes d'Aldous Huxley.
Réponse de Michel Volle
La conclusion me semble très pertinente. Il faut aussi rappeler que le logiciel le mieux vérifié (par exemple, celui d'une sonde spatiale de la NASA) comporte encore en moyenne un défaut toutes les 10 000 lignes de code source (Jacques Printz, Architecture logicielle, Dunod, 2006, p. 73). Au delà d'une certaine taille, il n'existe pas de logiciel sans défaut.
C'est pourquoi il faut, dans nos systèmes d'information, prévoir une supervision de l'automate, toujours sujet à des pannes aléatoires ; dans les automobiles, avions, sondes spatiales et autres, il faut... croiser les doigts en espérant que les tests ont couvert toutes les situations que la machine pourrait rencontrer, y compris les plus rares, et que les défauts du logiciel (qui inévitablement sont là) resteront en sommeil et sans conséquence.
Réponse de Laurent Bloch
Le chiffre avancé par Jacques Printz me semble devoir être considéré avec prudence, il concerne plutôt les logiciels de gestion. Il faut d'abord se poser la question : qu'est-ce qu'un défaut dans un logiciel ? L'article de Gérard Le Lann sur l'échec du premier vol d'Ariane 5 me semble une piste de réflexion plus fructueuse pour le monde qui relève des équations de la physique :
http://www.inria.fr/rrrt/rr-3079.html
Je pense à un autre exemple dans le domaine de l'embarqué, un accident du métro sans pilote de Lille : les concepteurs du logiciel n'avaient pas su prévoir qu'un camion de 35 tonnes tomberait d'un échangeur sur un pont enjambant la voie et que ce pont ne résisterait pas au choc. On est assez loin de la problématique du nombre d'erreurs par ligne de code. Et la plupart des défauts imputables à l'embarqué sont de cet ordre. Tel logiciel parfaitement sûr pour Ariane 4 ne l'est plus pour Ariane 5 parce que les grandeurs physiques considérées ne sont plus dans les mêmes intervalles. Le système de commande des missiles Patriot (accident de Dahran pendant la guerre du Golfe) n'avait jamais été testé pour 17 jours de fonctionnement ininterrompu, d'où débordement de zone mémoire.
Réponse de Michel Volle
Je trouve le sujet tellement important que je me fais un devoir de recopier ici ce que Jacques Printz a écrit dans son ouvrage Architecture logicielle, à partir de la p. 71 :
« Depuis les premières statistiques produites par la NASA avec le programme navette spatiale, on a pris l'habitude de mesurer la qualité d'un programme du point de vue des défauts par le taux d'erreur résiduelle ramené au millier d'instructions effectivement livrées, soit :
(...) Il y a consensus parmi les experts sur les chiffres suivants : en fin de programmation, on observe des taux d'erreur de l'ordre d'une erreur toutes les 10-15 lignes de code. Pour installer dans de bonnes conditions, les processus IVVT doivent ramener ce taux aux alentours de 1-2 Err/kLS. »
Réponse de Laurent Bloch
Je précise mon objection à la citation de Printz : il concerne des logiciels écrits « à la main ». Les exemples que je donne concernent plutôt des logiciels engendrés par des systèmes qui produisent leurs propres preuves. Loin de moi l'idée que ce soit une garantie absolue contre les erreurs de programmation, mais dans les exemples que je donne, et l'article de Le Lann explique pourquoi, les défauts ne sont pas des erreurs de programmation, ni des erreurs de spécification du logiciel, mais des erreurs de conception de systèmes, où des éléments de l'environnement n'avaient pas été pris en considération.
Jeu de briques
Snake
Pacman
Bubble