Agilit et avionique "Monteriez-vous bord d'un avion dont des logiciels de vol sont crits par des praticiens

s de l'eXtremeProgamming?" Emmanuel CHENU emmanuel.chenu@gmail.com L'objectif de ce retour d'exprience est de faire dcouvrir un secteur de lindustrie, lavionique, o lAgilit russi percer. Larticle prsente ce que le dveloppement Agile apporte l'avionique et comment nous avons procd pour introduire cette dmarche dans un contexte industriel priori peu rceptif ces pratiques. Des faits seront exposs pour vous aider rpondre question suivante: "Monteriez-vous bord d'un avion dont des logiciels de vol sont crits par des praticiens de l'eXtreme-Progamming?". La prsentation voquera la progression vers l'Agilit, les obstacles surmonts et ceux qui rsistent. Elle s'adresse un public dj familiaris avec la dmarche Agile et l'eXtreme-Programming [XP] en particulier. 1. CONTEXTE INDUSTRIEL DE LAVIONIQUE Secteur Nous dveloppons des quipements de navigation embarqus sur aronef, tels que des rcepteurs GPS, des gestionnaires de vol, des centrales inertielles et des centrales anmobaromtriques. Il sagit dquipements pour lesquels une panne impacte la scurit du vol. Dans ces produits, une part importante des fonctionnalits est alloue des logiciels temps-rel embarqus. Ces quipements et leurs logiciels doivent tre certifis par un organisme spcialis pour assurer la scurit du vol. Le march de l'avionique est essentiellement partag par de grands groupes industriels cause de cots de dveloppement levs et de petites sries produites. Contraintes absolues En plus de certaines difficults habituelles du dveloppement logiciel, ce secteur est confront aux contraintes de sret de fonctionnement et du temps-rel embarqu. La certification pour vol Un niveau de criticit est attribu un logiciel avionique en fonction de l'impact que peut avoir une panne sur la scurit du vol. Le document RTCA DO-178B de 1992 donne les objectifs tenir lors du dveloppement pour certifier un logiciel pour vol. Plus le niveau de criticit est lev, plus les objectifs sont nombreux et contraignants. Ils portent sur les processus, leurs activits, les document et les preuves produire. Entre autres, il est demand de vrifier le logiciel dans son environnement oprationnel, c'est dire sur le matriel cible [HW]. La dmarche de dveloppement est pilote par les exigences, que cela soit pour la construction du logiciel (traabilit) ou pour sa vrification (couverture par les tests). La certification est obtenue aprs une srie d'audits exigeant la fourniture de preuves des activits menes pour atteindre les objectifs. La DO-178B ne dcrit que les objectifs tenir - pas la manire de les tenir. Ainsi, il y a de la flexibilit dans la manire de raliser un dveloppement conforme DO-178B. Par exemple, la norme laisse le choix du cycle de vie en laissant explicitement la porte ouverte au cycle de vie itratif et incrmental. Nanmoins, puisque les objectifs concernent beaucoup la planification, les processus, les activits et les preuves des travaux, le cycle en V a historiquement t la manire intuitive de raliser un dveloppement conforme DO-178B. Le logiciel temps-rel embarqu Le logiciel sexcute sur un HW spcifique avec un systme opratoire [OS] spcifique. Le compilateur gnrant le code pour le processeur cible n'a pas toujours le mme comportement que celui pour le processeur de dveloppement. Le code n'a pas toujours le mme comportement sur la cible avec l'OS spcifique que sur la machine de dveloppement. Le HW et l'OS sont souvent dvelopps en parallle du SW. Ils sont alors disponibles tard dans le

projet. Lorsque le HW est enfin disponible, cest souvent en trs petites quantits (car en prototypage ou pour des raisons de cot). Aussi, nous sommes confronts aux problmes temps-rel, de concurrence et de ressources limites (CPU comme mmoire). Enfin, la carte cible est souvent un environnement peu ergonomique en terme d'outils de dveloppement, particulirement pour les aspects tests et automatisation. Culture Les applications sont spcifiques chaque client, ce qui fait que le modle industriel semble intuitivement proche de l'artisanat. Mais, l'hritage culturel des standards STD-2167, la philosophie de la DO-178B et la pratique du CMMi ont instaur le paradigme de la production de masse avec son modle de dveloppement prdictif et le cycle de vie en V. Dans cet environnement, nous constatons que sont privilgis: les processus dtaills et les outils plutt que la communication; les contrats plutt que la collaboration; (avec les clients comme avec les fournisseurs) la documentation exhaustive plutt que le logiciel excutable et fonctionnel; la planification prdictive plutt que l'adaptation empirique et continue. Nanmoins, la dmarche Lean est en train de se mettre en place en dveloppement. Ce changement est essentiellement tir par le dveloppement logiciel. Cependant, comme nous travaillons dans un domaine o le logiciel n'est pas considr comme le cur mtier (qui reste l'aronautique) cela ralentit l'adoption de cette dmarche. Contraintes drives Le niveau 3 du CMMi est exige par certains clients. Dans une culture dj marque par la planification prdictive, la documentation, la standardisation, la sparation des tches et centre sur les activits, le CMMi trouve un environnement de choix pour se dployer. Au niveau 3, le modle insiste entre autre sur la standardisation des pratiques, avec ce que cela apporte de formalisme et de perte de flexibilit. Enfin, la sous-traitance au forfait est souvent impose ds le devis et le travail est parfois rparti sur plusieurs sites. Atouts Lavionique est aussi un secteur avec de nombreux atouts. Le volume des dveloppements et les ressources aux profils spcialiss font qu'il est possible de travailler en quipe pluridisciplinaire. De plus, localement, les managers accordent une grande autonomie aux quipes pour leur organisation et l'amlioration continue. L'entreprise dveloppe des lignes de produits stables. Il y a donc possibilit de capitaliser sur les projets et de rutiliser. Les ressources sont stables, ce qui permet de capitaliser sur les gens. Enfin, les contraintes de sret de fonctionnement font qu'il existe une vraie culture de la qualit du produit, de la rigueur et de la discipline dans la dmarche de dveloppement. 2. PROBLEMES RECURRENTS DE L' AVIONIQUE ET APPORTS DE LA DEMARCHE AGILE Il est souvent dit que les dmarches Agiles tel que XP sont adaptes aux projets marqus par des inconnues significatives. Des algorithmes complexes et nouveaux, des exigences de performance ambitieuses, un HW et un OS disponibles tard dans le projet sont des inconnues classiques des projets avioniques. Plus particulirement, XP aide rsoudre les problmes suivants: Problmes de processus L'hritage des normes xxx-STD-2167 et leur tradition de cycle en V se traduit (comme ailleurs) par des dveloppements plus coteux et longs que prvus, avec perte de visibilit sur l'avancement et la dtection souvent tardive et posteriori de dfauts. Certains problmes critiques notre secteur se dtectent tard, comme des performances non-tenues en consommation mmoire et en charge CPU. Outre la rponse classique ce problme classique, la dmarche itrative et incrmentale permet de surveiller tt et continuellement l'volution des performances.

Problmes lis au temps-rel embarqu Les applications SW sont couples un HW et un OS spcifiques, disponibles tard et en quantit limite. Donc, l'intgration sur cible est naturellement du type "big-bang" et tardive. Cette intgration sur processeur cible reste le goulot d'tranglement classique des projets (l'entre du tunnel). L'activit de test est alors peu optimise puisque essentiellement compose de sances de debug sur cible. De plus, il est regrettable de devoir vrifier des algorithmes mtier complexes sur une cible peu ergonomique. Le Test-Driven Development [TDD] amne dcoupler le code et donc rduire et isoler les dpendances vers l'OS et le HW. Grce cela, il devient possible de conduire des tests sur la machine de dveloppement avec des simulacres de HW et d'OS. Ainsi, le code est test, et en grande partie intgr bien avant la disponibilit du HW cible, par des tests automatiss faisant intervenir des donnes d'entre et attendues provenant de simulations produites par des experts de l'avionique. En fait, ne pas disposer du HW et de l'OS est un atout, car cela force clairement penser les dpendances et sparer les problmes. Le TDD libre le dveloppeur de problmes classiques pour qu'il puisse concentrer une partie de ses comptences spcifiques au temps-rel, la concurrence et aux interfaces avec le HW. Ainsi grce la confiance que le dveloppeur a en son logiciel dvelopp dans cette dmarche, il sait que les problmes qu'il dtectera sur la cible ne concerneront plus que les aspects temps-rel, concurrence et interface avec le HW. Les autres problmes peuvent tre reproduits et corrigs sur une machine de dveloppement. Problmes de flexibilit Il est impossible de rutiliser du code coupl au HW et l'OS et difficile de porter une telle application pour une autre cible et un autre OS. Comme le TDD amne dcoupler le code fonctionnel du HW et de l'OS, il devient possible de rutiliser et porter les applications pour dautres environnements. De plus, grce une gestion de versions avec intgration continue multiprojets, il est possible de construire des logiciels dont 30% du code est rutilis entre applications de gammes diffrentes et 60% entre produits dune mme gamme. Problmes de ressources humaines Nous sommes galement confronts des problmes de ressources humaines. Il est difficile de trouver des dveloppeurs ayant une exprience du gnie logiciel, de l'embarqu, et de l'avionique. De plus, les quipes perdent souvent en motivation car les projets sont longs et ponctus par de lourdes activits de documentation, de revue et de traabilit. Ceci est accentu par la culture de production de masse et le CMMi qui visent rendre les individus interchangeables en sparant penser et faire. XP aide pallier au manque de dveloppeurs par la formation acclre dans le cadre du travail en binmes, des quipes pluridisciplinaires et de l'espace partag. De plus, la dmarche motive par l'importance accorde aux individus, l'esprit d'quipe, l'auto-organisation et lapprciation continue des rsultats obtenus. La sret de fonctionnement La grande proccupation de l'avionique est la sret de fonctionnement. Un audit de certification va chercher s'assurer que l'application ne contient que du code rpondant des besoins oprationnels. La prise en compte de tous les besoins oprationnels et le code devront tre intgralement vrifis par des tests. Aussi, les produits (exigences, architecture, code, tests...) devront tre vrifis par des revues. Avec la construction incrmentale pilote par des scnarios oprationnels, une si grande importance accorde aux tests systmatiques de niveau recette et dveloppeur, une relecture en continue en binmes du code et des tests, et lintransigeance sur la qualit du logiciel, XP est une dmarche approprie pour assurer la sret de fonctionnement. De plus, la disponibilit tt et en continue d'un logiciel fonctionnel et la transparence sur l'avancement et les difficults rassurent les certificateurs sur le fait que les dveloppeurs matrisent une dmarche de travail rigoureuse et discipline. Nanmoins, sans adaptation, la dmarche ne propose pas le niveau de formalisme requis pour les audits de certification. 3. DES ADAPTATIONS SONT NECESSAIRES

Adaptations de l' eXtreme-Programming Nous avons une pratique de XP adapte notre environnement. Nous n'avons pas suivi la recommandation "Do all XP before you customize it". Les valeurs et les principes restent parfaitement compatibles de notre secteur. C'est au niveau des pratiques qu'il a fallu faire des adaptations. Environ 70% du temps, l'quipe travaille en binmes qui permutent. Le reste du temps est rserv du travail individuel comme des revues, la traabilit et la documentation. Malheureusement, en plus des revues informelles en binmes, la DO178B et le CMMi nous imposent de mener des revues formelles supplmentaires pour les produits (exigences, architecture, code, tests). Les besoins sont dcrits avec un formalisme plus lourd que les scnarios. En effet, la DO-178B exige la spcification dexigences finement traces par rapport des besoins du client et aux tests. Le cycle hebdomadaire et le cycle trimestriel ne sont pas appliqus tels quels. Certains logiciels sont essentiellement composs d'algorithmes trs complexes et ont peu dinteractions avec lutilisateur. Il est alors difficile de mesurer en continue un avancement du logiciel en boite-noire. Lavancement est donc mesur l'aide de trois cycles. Un cycle quotidien permet de mesurer l'avancement des tches. Un cycle mensuel permet de mesurer un avancement du logiciel en boite-blanche. Enfin, un cycle trimestriel permet de mesurer un avancement du logiciel en boite-noire. Tester d' abord est trs difficile pour le code impact par la concurrence. L'criture de ce code est pilote par les tests, mais pas dans un cadre o il y a concurrence. Certaines adaptations du TDD sont ncessaires. En plus du classique cycle trs rapide de test et intgration sur machine de dveloppement, nous ajoutons un cycle moins rapide de compilation pour le processeur cible. A cela s'ajoute galement un cycle moins rapide de test sur carte cible d'valuation (ou sur un ventuel simulateur de processeur cible). Enfin, lorsque le matriel cible est enfin disponible, s'ajoute un cycle moins rapide de test sur carte cible finale. Cette dmarche permet de rgulirement mesurer la consommation en CPU et mmoire, qui sont des ressources critiques pour nos applications. Il est difficile d'obtenir une relle implication du client final, quil soit avionneur, certificateur ou pilote. Par contre, les projets ont toujours des reprsentants internes du client: experts mtier et responsable qualit. Le dploiement incrmental et le dploiement quotidien sont impossibles sur lenvironnement de production final (laronef), dautant plus que le logiciel doit tre certifi avant dtre embarqu pour vol. Ces pratiques ne sont pas non plus ralisables sur un HW dvelopp en parallle du logiciel. Malheureusement, ces pratiques restent rares mme sur un environnement simul chez le client. Par contre, elles sont pratiques sur un environnement simul dans nos laboratoires. Le code et les tests ne sont pas les seuls produits essentiels pour une certification D0-178B. Les audits de certification pour vol demandent la production de nombreux documents et preuves formelles non gnres partir du code et des tests. L'eXtreme-Programming ne dit pas qu'il ne faut pas produire de tels documents. La dmarche propose de rflchir au niveau strictement ncessaire et suffisant, d'tre conscient que cela un cot et de mesurer si cela vaut ce cot. Mme si toute cette documentation n'est pas ncessaire pour produire un logiciel de qualit, elle apporte de la valeur puisqu'elle permet de passer des audits de certification. Pour viter de remanier sans cesse la documentation, il s'agit de sparer le stable du variable, de documenter en priorit le stable et de choisir autant que possible des formats qui privilgient le travail collaboratif. Le contrat contour ngoci est possible pour les versions intermdiaires, mais rarement pour la version finale. En effet, les applications avioniques contiennent peu de fonctionnalit optionnelles ou de confort. Par contre, la traabilit et la couverture des exigences sont si importantes pour les certificateurs que nous en avons cr une pratique supplmentaire. Au fil des activits, nous consignons les informations de traabilit et couverture. En continue et automatiquement, ces informations sont consolides, quantifies, vrifies dans la mesure du possible et enfin publies. Interprtation du Manifeste Agile Comme les principes d'XP, ceux du Manifeste Agile sont galement applicables. Nanmoins, il faut rinterprter certains d'entre eux.

"Notre plus grande priorit est de satisfaire le client par la livraison tt et en continue de logiciel de valeur." Ce principe reste bien sr valable, mais il faut comprendre que du logiciel avionique de valeur pour un client est un logiciel "bon pour vol". Obtenir cette valeur demande un travail bien plus consquent que pour de nombreux autres projets de dveloppement. "La faon la plus efficace de transmettre linformation une quipe et entre les membres est par des conversations face face." Ce principe s'applique galement, mais une partie de l'information doit de plus tre consigne pour l'audit de certification car les informations informelles ne constituent pas des preuves. "Le logiciel oprationnel est la principale mesure d'avancement." Ce principe s'applique en partie, car il faut bien comprendre qu'un logiciel avionique n'est rellement oprationnel que s'il est certifi, et la certification est une dmarche peu incrmentale. 4. POURQUOI CE SECTEUR EST A PRIORI PEU RECEPTIF A LAGILITE? L'industrie est trs marque par la dmarche Lean en production et logistique. Il est alors trs tonnant que l'avionique mette autant de temps adopter le Lean en dveloppement. Pourquoi ce secteur semble peu rceptif? D'abord, la peur des audits de certification induit une peur de changer des pratiques qui ont aboutit un produit certifi. Les auditeurs ont l'habitude de certifier des projets mens dans une dmarche prdictive, en phases et pilote par les plans. Alors, nous avons peur d'tre les premiers proposer de certifier un logiciel dvelopp avec une autre dmarche. Aussi, il existe une ide prconue selon laquelle la dmarche Agile est inadapte aux logiciels critiques, car perue comme peu rigoureuse - comme si "lger" tait synonyme de " la lgre". Nous constations que les processus lourds, dtaills et lents rassurent. Il existe galement une ide prconue selon laquelle le TDD n'est pas appropri pour le dveloppement de logiciels embarqus sur HW spcifique avec OS temps-rel - car il est difficile d'automatiser et de systmatiser tt dans le projet le test sur un processeur cible. Pourtant, il nous semble que les applications embarques nont jamais t autant testes. Enfin, le vocabulaire de l'Agilit ("eXtreme-Programming", "Scrum", "ScrumMaster", "Agile" ...) ne semble pas accrocher les industriels. 5. MISE EN PRATIQUE PROGRESSIVE DE LAGILITE Comment avons nous conduit le changement ? Nous avons eu la chance davoir un Champion. Il sagit de quelquun, cout dans lentreprise, qui voit lopportunit, est convaincu de son intrt et qui explique sans relche. Pour nous, la transition vers l'Agilit est une dmarche progressive et continue reposant sur l'initiative de dveloppeurs logiciel passionns. Ceci fait dailleurs la fragilit de la dmarche! Introduite par des dveloppeurs logiciel et soutenue par la hirarchie proche, la dmarche a dabord naturellement concern le primtre purement logiciel. Suite aux premiers rsultats positifs sur la qualit des produits et la motivation des quipes, la dmarche sest dploye sur un nombre croissant de projets. Les dveloppeurs commencent par adopter les pratiques les plus techniques, puis passent au travail dquipe pour finir par la gestion de projet. Ensuite, la dmarche se dploie sur un primtre plus large que le logiciel. Chronologiquement, la progression a t la suivante: 1. Les quipes recherchent l'excellence technique et sont intransigeantes sur le niveau de qualit. Cette prise de conscience est dterminante pour la suite. 2. La dmarche oriente-objet sinstalle. Les principes avancs de conception oriente-objet dcris par Robert Martin sont appliqus. On organise la rutilisation.

Les quipes sont pluridisciplinaires. La programmation par contrat est systmatise avec une nette amlioration de la qualit. Les tests natifs sont progressivement mis en place. Les tests natifs sont automatiss. LeXtreme-Programming fait des mules dans les quipes. On applique la conception incrmentale, la construction en 10 minutes, lintgration continue et lautomatisation. On officialise le partage du code, le travail en binmes, lespace de travail commun, la courte runion quotidienne davancement et le management visuel. 8. Les quipes passent du dveloppement itratif et incrmental sur des cycles trs courts. 9. Les quipes travaillent sur la communication, le travail d'quipe, lamlioration continue et la gestion de projet Agile en mettant en place des runions de dbut ditration, de fin ditration, les rtrospectives ditration et le suivi dindicateurs davancement mesurs en continue. Les projets menant une dmarche Agile sont gnralement accompagns par un coach ddi. Il sagit dun dveloppeur Agile expriment et/ou simplement passionn. On constate que les quipes demandent tre ainsi guides. Par contre, on remarque que la dmarche reste encore fragile puisque certaines pratiques perdent en rigueur ou ne sont plus appliques si le coach quitte le projet. 6. COMMENT PARLER DAGILITE A DES INDUSTRIELS? Le vocabulaire En tant que praticiens du dveloppement logiciel Agile dans un domaine industriel, nous avons trs souvent d vendre - ou plutt justifier - la pertinence de notre dmarche auprs de notre management et de clients. Au cours de nombreuses prsentations et dmonstrations, nous nous sommes rendu compte que nos auditeurs taient peu rceptifs aux termes "eXtreme-Programming", "Scrum" ou mme "Agile". Nous avons mme constat que ces noms desservent parfois les dmarches qu'ils nomment. Travaillant dans un domaine industriel, nous avons remarqu que notre management et nos clients sont bien plus rceptifs l'vocation de la dmarche Lean. Ainsi, nous avons appris adapter notre communication au vocabulaire du Lean pour accrocher nos dcideurs. Les rsultats Comme souvent, il faut convaincre en communiquant sur les rsultats obtenus. Par exemple, lors d'un rcent projet, 16KLS de C++ avec 30% de rutilisation, dvelopps en cinq mois quatre ont t intgrs sur cible sur site client en quatre jours. Le taux de dfauts rsiduels est de 0.18/KLS. Les cots et dlais du projet ont t respects. Les dfauts rsiduels sont rapidement corrigs sans monopoliser le HW et sans rgression. La dmarche de ce projet, entre autre, est prise comme modle de base pour un projet stratgique et d'envergure qui dbute. 7. OBSTACLES QUI PERSISTENT Inertie des grandes organisations L'organisation de l'entreprise, en termes de processus, de standards, d'outils, de locaux et d'organisation d'quipes pluridisciplinaires ne suit pas le rythme d'volution demand par les dveloppeurs. Par exemple, il existe une masse importante de standards orients cycle en V qu'il est difficile de faire voluer d'autant plus qu'ils sont figs par une dmarche CMMi. De mme, les outils sont standardiss et grs par une DSI centrale qui ne suit pas l'volution des besoins spcifiques des projets. Par ailleurs, certaines descriptions de postes standards ne sont plus adaptes : les chefs de projet perdent une grande part de leurs anciennes fonctions au profit d'une quipe auto-organise et dun coach. Une organisation 2 vitesses La propagation de la dmarche Agile se fait projet par projet. Elle n'est pas impose et donc est mene d'abord par les quipes les plus motives par la dmarche. La constitution d'un esprit d'quipe fort fait que les dveloppeurs hors d'un projet Agile se sentent exclus. Le dpartement logiciel tend se dcouper en deux groupes. D'un ct, les adeptes de la dmarche qui veulent l'appliquer toujours plus loin et ceux qui

3. 4. 5. 6. 7.

s'en sentent exclus, qui ne sont pas attirs ou qui rsistent au changement. Interprtations de la DO178B Lesprit de la DO178B amne une drive chez les certificateurs qui consiste penser que la qualit et la sret de fonctionnement sont essentiellement le rsultat de lapplication dun processus trs dtaill o chaque activit est ralisable exclusivement partir des informations produites par la prcdente. Dans cette sparation de penser et de faire , le dveloppeur menant une activit est interchangeable au dtriment de la flexibilit et de la crativit. Dailleurs, lors des audits, les certificateurs cherchent identifier et comprendre par eux-mmes tout le code induit par un besoin oprationnel. Ceci soppose lide selon laquelle un logiciel de qualit est le rsultat du travail dune quipe de qualit appliquant des pratiques qui incitent la flexibilit et la crativit. Facteur d' chelle Les logiciels sont embarqus dans des systmes dont le dveloppement ne suit pas une dmarche Agile. Il est alors difficile de travailler en flux-tendu tir dans un contexte plus vaste qui fonctionne en phases. Clients Certains clients nont pas confiance sur la tenue des dlais. Ils senferment alors dans lide quils peuvent suivre les dveloppements avec des revues calques sur des fins de phase et contrler la pertinence des travaux grce la documentation. Un tel client n'est pas conscient de l'intrt qu'il peut tirer d'un fournisseur ayant une dmarche Agile. Malheureusement, les dveloppeurs ont trs rarement accs aux clients finaux, ce qui ne permet pas de leur exposer la dmarche. Dans ce cas de figure, nous avons parfois une attitude schizophrne: nous voulons tre Agile mais nous avons peur de la raction des clients. Alors, nous cachons la dmarche derrire une faade de dveloppement prdictif en phases. L' automatisation et le TDD sont difficiles au niveau systme Plus le niveau du test est lev, plus l'automatisation devient difficile. Aussi, le TDD ne permet pas de tester la concurrence. Nanmoins, il aide sparer les problmes et donc isoler les problmes de concurrence. Organisation des quipes La pratique de l'quipe complte est respecte. Malheureusement, le travail est souvent perturb par une comptabilit par mtier et non par projet. Ceci aboutit trop souvent des intrts conflictuels au sein de l'quipe. Il s'agit l d'une consquence directe des modles industriels centrs sur les activits et non sur les flux. 8. CONCLUSION Contrairement aux ides reues, la dmarche Agile et leXtreme-Programming en particulier nous aident dvelopper efficacement des logiciels temps-rel embarqus. De mme, ces dmarches sont appropries pour assurer la sret de fonctionnement d'un logiciel. Nanmoins, elles doivent tre adaptes pour fournir le niveau de formalisme requis par les audits de certification pour vol. Il y a quelques annes les industriels sont passs avec beaucoup de prcautions au dveloppement orient-objet de logiciels avioniques. Les certificateurs sont actuellement en train dauditer cette premire vague dapplications. Nous pouvons alors envisager que dans un futur proche, de plus en plus dindustriels vont chercher certifier des produits dvelopps avec des processus plus lgers mais garantissant au moins la mme sret de fonctionnement. Alors, les audits devront peut-tre galement aller dans le sens de la fluidit, peut-tre en adoptant une certification incrmentale ou en continue en dlguant un auditeur sur site. En tout cas, en tant que dveloppeurs, nous sommes rassurs de constater que la dmarche en cours a permis de diminuer la complexit des applications, d'amliorer la testabilit, d'automatiser la nonrgression, de baisser trs sensiblement le nombre de dfauts rsiduels, de permettre la rutilisation et dacclrer les dveloppements tout en assurant la sret de fonctionnement.

Alors, monteriez-vous bord d'un avion dont des logiciels de vol sont crits par des praticiens de leXtreme Programming? Bientt, vous le ferez sans en avoir conscience. 9. BIBLIOGRAPHIE Considrations sur le logiciel en vue de la certification des systmes et quipements de bord RTCA DO-178B / ED-12B - 1992 eXtreme Programming Explained - Kent Beck Manifesto for Agile Software Development - http://agilemanifesto.org/ Towards An Agile Avionics Process - Andrew Wils, Stefan Van Baelen - 2007 XP in a Safety-Critical Environment - Mary Poppendieck - 2007 Embedded Extreme Programming: An Experience Report - Nancy Van Shooenderwoert - 2004 Effective Test Driven Development for Embedded Software - Michael J. Karlesky, William I. Bereza, Carl B. Erickson - 2006 Extreme Programming And Embedded Software Development - James Grenning - 2002 Progress Before Hardware - James Grenning - 2004 Embedded Test Driven Development Cycle - James Grenning - 2004 Launching XP Extreme Programming at a Process-Intensive Company - James Grenning - 2001