Remerciez-le!

Remerciez @Admin pour avoir partagé cet document gratuitement, de la manière la plus simple, en partageant sur les réseaux sociaux.

Agilité et avionique "Monteriez-vous à bord d'un avion dont des logiciels de vo

Agilité et avionique "Monteriez-vous à bord d'un avion dont des logiciels de vol sont écrits par des praticiens de l'eXtreme- Progamming?" Emmanuel CHENU emmanuel.chenu@gmail.com L'objectif de ce retour d'expérience est de faire découvrir un secteur de l’industrie, l’avionique, où l’Agilité à réussi à percer. L’article présente ce que le développement Agile apporte à l'avionique et comment nous avons procédé pour introduire cette démarche dans un contexte industriel à priori peu réceptif à ces pratiques. Des faits seront exposés pour vous aider à répondre à question suivante: "Monteriez-vous à bord d'un avion dont des logiciels de vol sont écrits par des praticiens de l'eXtreme-Progamming?". La présentation évoquera la progression vers l'Agilité, les obstacles surmontés et ceux qui résistent. Elle s'adresse à un public déjà familiarisé avec la démarche Agile et l'eXtreme-Programming [XP] en particulier. 1. CONTEXTE INDUSTRIEL DE L’AVIONIQUE Secteur Nous développons des équipements de navigation embarqués sur aéronef, tels que des récepteurs GPS, des gestionnaires de vol, des centrales inertielles et des centrales anémobarométriques. Il s’agit d’équipements pour lesquels une panne impacte la sécurité du vol. Dans ces produits, une part importante des fonctionnalités est allouée à des logiciels temps-réel embarqués. Ces équipements et leurs logiciels doivent être certifiés par un organisme spécialisé pour assurer la sécurité du vol. Le marché de l'avionique est essentiellement partagé par de grands groupes industriels à cause de coûts de développement élevés et de petites séries produites. Contraintes absolues En plus de certaines difficultés habituelles du développement logiciel, ce secteur est confronté aux contraintes de sûreté de fonctionnement et du temps-réel 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 sécurité du vol. Le document RTCA DO-178B de 1992 donne les objectifs à tenir lors du développement 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 activités, les document et les preuves à produire. Entre autres, il est demandé de vérifier le logiciel dans son environnement opérationnel, c'est à dire sur le matériel cible [HW]. La démarche de développement est pilotée par les exigences, que cela soit pour la construction du logiciel (traçabilité) ou pour sa vérification (couverture par les tests). La certification est obtenue après une série d'audits exigeant la fourniture de preuves des activités menées pour atteindre les objectifs. La DO-178B ne décrit que les objectifs à tenir - pas la manière de les tenir. Ainsi, il y a de la flexibilité dans la manière de réaliser un développement conforme DO-178B. Par exemple, la norme laisse le choix du cycle de vie en laissant explicitement la porte ouverte au cycle de vie itératif et incrémental. Néanmoins, puisque les objectifs concernent beaucoup la planification, les processus, les activités et les preuves des travaux, le cycle en V a historiquement été la manière intuitive de réaliser un développement conforme DO-178B. Le logiciel temps-réel embarqué Le logiciel s’exécute sur un HW spécifique avec un système opératoire [OS] spécifique. Le compilateur générant le code pour le processeur cible n'a pas toujours le même comportement que celui pour le processeur de développement. Le code n'a pas toujours le même comportement sur la cible avec l'OS spécifique que sur la machine de développement. Le HW et l'OS sont souvent développés en parallèle du SW. Ils sont alors disponibles tard dans le projet. Lorsque le HW est enfin disponible, c’est souvent en très petites quantités (car en prototypage ou pour des raisons de coût). Aussi, nous sommes confrontés aux problèmes temps-réel, de concurrence et de ressources limitées (CPU comme mémoire). Enfin, la carte cible est souvent un environnement peu ergonomique en terme d'outils de développement, particulièrement pour les aspects tests et automatisation. Culture Les applications sont spécifiques à chaque client, ce qui fait que le modèle industriel semble intuitivement proche de l'artisanat. Mais, l'héritage 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 modèle de développement prédictif et le cycle de vie en V. Dans cet environnement, nous constatons que sont privilégiés: les processus détaillés et les outils plutôt que la communication; les contrats plutôt que la collaboration; (avec les clients comme avec les fournisseurs) la documentation exhaustive plutôt que le logiciel exécutable et fonctionnel; la planification prédictive plutôt que l'adaptation empirique et continue. Néanmoins, la démarche Lean est en train de se mettre en place en développement. Ce changement est essentiellement tiré par le développement logiciel. Cependant, comme nous travaillons dans un domaine où le logiciel n'est pas considéré comme le cœur métier (qui reste l'aéronautique) cela ralentit l'adoption de cette démarche. Contraintes dérivées Le niveau 3 du CMMi est exigée par certains clients. Dans une culture déjà marquée par la planification prédictive, la documentation, la standardisation, la séparation des tâches et centrée sur les activités, le CMMi trouve un environnement de choix pour se déployer. Au niveau 3, le modèle 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 imposée dès le devis et le travail est parfois réparti sur plusieurs sites. Atouts L’avionique est aussi un secteur avec de nombreux atouts. Le volume des développements et les ressources aux profils spécialisés 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'amélioration continue. L'entreprise développe des lignes de produits stables. Il y a donc possibilité de capitaliser sur les projets et de réutiliser. Les ressources sont stables, ce qui permet de capitaliser sur les gens. Enfin, les contraintes de sûreté de fonctionnement font qu'il existe une vraie culture de la qualité du produit, de la rigueur et de la discipline dans la démarche de développement. 2. PROBLEMES RECURRENTS DE L'AVIONIQUE ET APPORTS DE LA DEMARCHE AGILE Il est souvent dit que les démarches Agiles tel que XP sont adaptées aux projets marqués 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 particulièrement, XP aide à résoudre les problèmes suivants: Problèmes de processus L'héritage des normes xxx-STD-2167 et leur tradition de cycle en V se traduit (comme ailleurs) par des développements plus coûteux et longs que prévus, avec perte de visibilité sur l'avancement et la détection souvent tardive et à posteriori de défauts. Certains problèmes critiques à notre secteur se détectent tard, comme des performances non-tenues en consommation mémoire et en charge CPU. Outre la réponse classique à ce problème classique, la démarche itérative et incrémentale permet de surveiller tôt et continuellement l'évolution des performances. Problèmes liés au temps-réel embarqué Les applications SW sont couplées à un HW et un OS spécifiques, disponibles tard et en quantité limitée. Donc, l'intégration sur cible est naturellement du type "big-bang" et tardive. Cette intégration sur processeur cible reste le goulot d'étranglement classique des projets (l'entrée du tunnel). L'activité de test est alors peu optimisée puisque essentiellement composée de séances de «debug» sur cible. De plus, il est regrettable de devoir vérifier des algorithmes métier complexes sur une cible peu ergonomique. Le Test-Driven Development [TDD] amène à découpler le code et donc à réduire et isoler les dépendances vers l'OS et le HW. Grâce à cela, il devient possible de conduire des tests sur la machine de développement avec des simulacres de HW et d'OS. Ainsi, le code est testé, et en grande partie intégré bien avant la disponibilité du HW cible, par des tests automatisés faisant intervenir des données d'entrée 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 dépendances et séparer les problèmes. Le TDD libère le développeur de problèmes classiques pour qu'il puisse concentrer une partie de ses compétences spécifiques au temps-réel, à la concurrence et aux interfaces avec le HW. Ainsi grâce à la confiance que le développeur a en son logiciel développé dans cette démarche, il sait que les problèmes qu'il détectera sur la cible ne concerneront plus que les aspects temps-réel, concurrence et interface avec le HW. Les autres problèmes peuvent être reproduits et corrigés sur une machine de développement. Problèmes de flexibilité Il est impossible de réutiliser 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 amène à découpler le code fonctionnel du HW et de l'OS, il devient possible de réutiliser et porter les applications pour d’autres environnements. De plus, grâce une gestion de versions avec intégration continue multiprojets, il est possible de construire des logiciels dont 30% du code est réutilisé entre applications de gammes différentes et 60% entre produits d’une même gamme. Problèmes de ressources humaines Nous uploads/Industriel/ agile-avionics.pdf