Embarquez Agile !
Était l'intitulé d'une journée de conférences fort intéressante sur Bordeaux le 18 mars, organisée par Eurogiciel dans le cadre du pôle de compétitivité Aerospace Valley.
Le sujet : l'agilité dans le monde des systèmes embarqués, de la certification, qualification etc
Parmi les visiteurs, un bon équilibre entre donneurs d'ordre, SSII et consultants.
Ce sujet mérite effectivement d'être traité de façon dédié.
Combien de fois a-t-on entendu :
Dans le monde de l'embarqué, l'agilité c'est pas pour nous
Les contre arguments ont été à la hauteur.
Ce que j'ai retenu avant tout des nombreux et animés échanges :
- L'architecture est une métaphore. Et ce n'en est pas une bonne car elle nous associe l'image d'une structure matérielle figée. Parlons plutôt de pâte à modeler pour la conception logicielle
- Le big freeze est la difficulté de changer la moindre ligne de code après une certification
- Pour l'initiative OpenDO, qui milite pour le développement fédérateur de solutions open source agiles au service du logiciel critique, les pratiques d'ingénierie logicielles sont non seulement fondamentales pour la problématique mais extensibles : on peut ainsi voir naître la notion de certification continue ou de vérification dirigée par les tests
- Une des clefs pour l'embarqué agile, c'est la simulation. Il faut absolument intégrer des simulateurs du hardware dans les cycles itératifs. QEMU, un émulateur reconnu et libre a été évoqué comme solution. Ce dernier est en cours qualification car il doit l'être, comme l'ensemble des artefacts qui interviennent dans la chaîne de certification
- L'intégration continue ajoute nécessairement à son panel la couverture structurelle de code (code source et code objet binaire), absolument critique dans les systèmes embarqués. Une couverture insuffisante, peut être la cause d'une mauvaise expression de besoins et pas seulement un problème de conception : l'agilité est donc ici clairement un avantage en tant que méthode qui challenge souvent les besoins
- Balance HW/SW : le SW est de plus en plus prépondérant 1) pour des questions de souplesse de conception 2) il récupère les erreurs irréversibles du HW. Avec le cycle en V, le HW intervient seulement en intégration. Avec des méthodes agiles, le HW simulé "vit" avec le SW et les deux redeviennent vivants
- Pour installer l'agilité, il faut convaincre la direction mais aussi la qualité (j'en sais qqchose...) et commencer par les aspects techniques pour montrer des résultats en matière de productivité et de qualité du code
- On n'échappe pas aux spécifications d'interfaces système en amont de l'agilité pour garantir une architecture la plus indépendante possible des changements de HW
- Rester rigoureux : on peut produire des specs partielles mais précises (ciblées besoins prioritaires)
- La documentation peut et doit être réduite davantage (c'est pas moi qui l'ait dit !). Des référentiels comme la DO178 n'interdisent nullement de faire de l'agile, pas plus qu'ils ne demandent de produire beaucoup de doc. Il faut savoir répondre aux critères de certifications autrement (si si c'est possible, je l'ai fait)
- La programmation par contrat est essentielle dans le domaine agile embarqué
- Qualification agile d'outils de certification : un sujet que j'affectionne particulièrement pour y avoir planché pendant plusieurs mois. Il s'agit d'automatiser le processus et le rendre perméable aux changements. Pour cela, le projet Qualifying Machine vise à modéliser les règles de qualification, les workflows, les règles de traçabilité etc (avec des solutions techniques telles que DSL, Fitnesse, OAW etc). Ainsi on pourrait envisager d'abandonner la bonne vieille matrice de traçabilité. L'idée autant que le projet, sont très prometteurs. Contribuez.
Pour en savoir plus sur le programme et les intervenants, consulter le billet de Fabrice.