L’avenir du développement de logiciels de l’armée

La transformation numérique de l’armée au cours des dernières années s’est concentrée sur l’amélioration des réseaux, du cloud computing et des données. Désormais, le service souhaite retravailler la manière dont il gère le développement de logiciels en le centralisant et en le simplifiant afin que les programmes critiques soient mis à jour rapidement.

Mais qu’est-ce que cela signifie pour l’achat, le développement, la mise à jour et l’application de correctifs ?

Défense un s’est assis avec Jennifer Swanson, sous-secrétaire adjointe de l’armée pour les données, l’ingénierie et les logiciels, pour en savoir plus sur le changement de développement logiciel de l’armée et ce que cela signifie pour les gestionnaires de programme et l’industrie.

Qu’est-ce que cela signifie exactement de ne plus mettre de logiciel dans le maintien, et pourquoi est-ce important ?

À partir d’octobre de cette année, nous n’effectuerons plus la transition d’aucun logiciel vers [Army Materiel Command] pour le maintien. Donc, c’est chose faite. L’argent associé à cela restera avec le [program managers], et la responsabilité de faire tout ce qu’ils doivent faire du point de vue du maintien en puissance leur incombera à partir d’octobre. Nous n’allons pas retirer les systèmes qui ont déjà effectué la transition AMC pour la plupart. Mais les choses qui n’y sont pas n’y vont pas.

Que signifie ce changement pour les gestionnaires de programme ?

Je pense que cela dépend de l’étape de vie du système, de ce qui doit être fait et s’il y a des exigences pour ajouter plus de capacité. Pour nos nouveaux systèmes, il n’y aura aucune phase de maintien en puissance car cela ne fait pas partie [continuous integration, continuous delivery, and continuous deployment]. Le modèle pour CI/CD [means] les choses traditionnelles que nous faisons dans le maintien en puissance comme la résolution des problèmes, les cybercorrectifs, ce genre de choses qui se produisent dans les versions avec des capacités supplémentaires et vous publiez des versions très fréquemment. Vous faites tout ce qui doit être fait, qu’il s’agisse d’ajouter des capacités ou d’un cyber correctif, dans une seule version.

Pour les systèmes qui approchent de la fin de leur vie et que vous n’avez pas vraiment besoin de capacités supplémentaires, à ce stade, je pense que nous prendrons une décision avec la communauté des exigences, avec [Army Futures Command]. S’il y a plus de capacité à ajouter, alors nous chercherons différents types d’argent pour pouvoir le faire. Si ce n’est pas le cas, le PM sera alors responsable de toutes les fonctions de maintien en puissance, comme la réparation et le cyber-correction, dont il a besoin.

La mise à niveau et le développement de logiciels ne sont pas un nouveau défi pour le DOD. En quoi cela sera-t-il différent ?

Ce que le DOD a fait pour nous nous a permis de faire ce que nous devons faire pour que cela fonctionne. D’un point de vue financier, et nous explorons cela avec le DOD, nous pensons que parce que nous avons pris la décision de ne plus faire la transition du logiciel vers le maintien en puissance, nous pouvons réellement utiliser le BA-07 RDT&E [funds] pour les logiciels. BA-08 a permis d’utiliser RDT&E pour les fonctions d’exploitation et de maintenance. Mais si nous ne faisons pas la transition du logiciel vers le maintien, nous n’en avons plus besoin.

Qu’est-ce qui rend ce changement différent ?

Nous avons passé la plus grande partie de l’année avec le soutien de nombreux hauts dirigeants [for] changer beaucoup de processus autour du logiciel. Pourquoi cela a-t-il échoué dans le passé ? Parce que je pense que c’était considéré comme quelque chose que le PM pourrait simplement faire mieux, développer de meilleurs logiciels, mieux rédiger votre contrat. Mais les exigences n’ont pas été écrites pour permettre le développement agile de logiciels. Les testeurs n’étaient pas autorisés à faire des tests agiles. Tout était comme avant, et puis d’une manière ou d’une autre, c’était censé s’améliorer comme par magie.

Il y a eu beaucoup d’efforts, dirigés par mon bureau, avec l’énorme soutien de [top Army leaders]… qui nous a permis de changer certaines choses très importantes. Premièrement, du point de vue des exigences, et nous avons travaillé là-dessus avec [Army Futures Command] au cours des neuf derniers mois ou si nous pensons que nous serons prêts à commencer à tirer parti [software initial capabilities documents and capability needs statements] ce mois-ci. Cela change vraiment la donne, car au lieu de nous donner un document de 200 pages, ce qui est en quelque sorte la façon dont nous fonctionnons depuis longtemps, ce sera un court et concis de haut niveau c’est ce dont nous avons besoin [document].

L’autre élément du processus d’exigences qui change est que l’AFC est à bord pour s’associer à FORSCOM, disons nos opérateurs, et nous aurons une équipe qui nous aidera à affiner cette exigence dans les sprints de développement. Nous n’avons jamais fait cela auparavant. Et c’est comme ça que Agile fonctionne, n’est-ce pas ? Vous avez besoin de personnes qui connaissent les exigences pour être avec vous et le développement qui peut vous aider à hiérarchiser le backlog et à affiner les exigences au fur et à mesure. Et nous n’avons jamais fait cela auparavant. Je pense que cela change assez la donne.

Comment la simplification des exigences affectera-t-elle les fournisseurs ?

Nous modifions déjà les contrats en ce qui concerne la façon dont nous demandons à l’industrie de livrer les produits. Un grand changement et nous l’avons fait avec Enterprise Business Systems-Convergence, comme un bon exemple. EBS-C est un système de grande entreprise qui engloutit une grande partie des systèmes commerciaux hérités. General Fund Enterprise Business System (GFEBS), Global Combat Support System Army (GCSS-Army), Logistics Modernization Program (LMP) et AESIP Hub sont tous subsumés par EBS-C.

Lorsque nous avons rédigé les exigences pour EBS-C, nous y avons mis de nombreuses portes qui nous permettent d’évaluer avec des oraux et des démonstrations, pas seulement un document écrit. Finies les propositions écrites. Il y aura des parties écrites, évidemment. Mais il y aura un élément de démonstration, qu’il soit oral ou qu’il s’agisse d’une démonstration, cela dépendra du programme. Mais il y aura un composant show me dans les propositions. Et c’est donc quelque chose que les vendeurs voient maintenant beaucoup plus hors de nos bureaux.

L’autre chose est que nous n’évaluons pas seulement la solution, nous évaluons la capacité de l’entreprise à être agile, car c’est là que nous avons trébuché dans le passé. Ainsi, vous pouvez nous montrer une solution brillante et une démo. Mais si nous vous donnons de nouvelles exigences, à quelle vitesse pouvez-vous transformer ces nouvelles exigences en une nouvelle version ? Et cela fait partie des activités de prototypage EBS-C qui se déroulent actuellement. Je pense que c’est assez important parce que cela envoie vraiment le message à l’industrie qu’il est tout aussi important pour vous d’avoir la bonne équipe et une compréhension du développement logiciel agile puis du CI/CD que d’avoir une bonne solution.

Quels projets ou quels programmes vont voir ce virage agile ?

Logiciels, programmes lourds. Tous. Les programmes basés sur des logiciels qui sortent avec des exigences vont dans cette direction.

Si vous avez un composant de développement logiciel important, c’est ce que nous faisons. Maintenant, si votre composant logiciel achète strictement un logiciel commercial, cela pourrait être un peu différent. Mais il s’agit vraiment de développement de logiciels et de la part de cela dans votre programme.

Qu’y a-t-il d’autre d’important dans la façon dont l’armée envisage le développement de logiciels ?

Les choses vont beaucoup, beaucoup plus vite. La publication de matériel logiciel, par exemple, qui était un processus assez long qui nécessitait tout un tas de documents et d’artefacts et tout un tas de choses, et qui était en fait gérée par AMC, car le logiciel était en train de passer au maintien. À partir de [FY]24, ça n’arrivera plus non plus. Le PEO sera responsable de sa propre version du matériel logiciel et il n’aura qu’à fournir les artefacts requis par la loi. Nous avons vraiment allégé ce processus. Aujourd’hui, il faut des mois pour obtenir une version logicielle. Cela devrait prendre un jour ou deux.

Les tests de certification d’interopérabilité de l’armée, auxquels chaque logiciel doit passer, ont également été radicalement simplifiés. Les PEO y seront également beaucoup plus propriétaires de ce qu’ils testent et de la manière dont ils le testent. Et se dirigeaient, à la fin de 24, vers une capacité AIC basée sur le cloud.

Toutes ces choses sont des choses qui prennent très, très longtemps à faire aujourd’hui. Le thème est de savoir comment simplifier tout ce que nous pouvons pour que cela prenne le moins de temps possible.

Qu’est-ce que l’industrie doit savoir à ce sujet?

Je pense que l’industrie va devoir recruter les bonnes personnes qui comprennent ce type de développement logiciel. J’ai parlé à beaucoup d’entre eux et je pense qu’il y a certainement une lacune dans notre entrepreneur de défense[s] capacité d’embaucher et de retenir ce talent. Et je sais qu’ils cherchent comment résoudre ce problème parce qu’ils voient que cela s’en vient. La vérité est qu’il y a un écart parce que nous, DOD, dans le passé, n’avons pas vraiment donné la priorité aux logiciels ; nous avons été d’accord avec ce qu’ils ont fait. Alors, pourquoi changer ? Eh bien, cela se produit.

Où voyez-vous l’état des logiciels de l’armée dans les six à 12 prochains mois ?

Nous allons commencer à voir certains de nos programmes que nous avons déjà pu influencer, comme EBS-C, commencer à être livrés, ce qui sera très excitant car ce sera bien mieux que ce que nous avions auparavant. Mais nous continuerons à apprendre, je n’en doute pas. Nous prendrons ce que nous pourrons, les réussites de ces programmes, et nous en tirerons parti. Et les choses qui n’ont pas fonctionné comme nous le pensions, nous les ajusterons.

Beaucoup d’obstacles au CI/CD dont j’ai parlé, comme les exigences et les tests, seront résolus parce que nous avons une tonne d’élan en ce moment. Nous en avons déjà corrigé beaucoup, donc je pense que nous allons continuer à le faire et je pense que ces choses seront codifiées.

Nous avons un projet de langage de contrat auquel nos PM ont accès, pour savoir comment rédiger les appels d’offres comme nous voulons les écrire aujourd’hui. Mais cela va continuer à évoluer.

Du point de vue des contrats, nous recevons actuellement beaucoup d’aide de la part du Commandement des contrats de l’armée à Aberdeen Proving Ground. Nous recueillons des informations qui seront fournies à titre indicatif aux PM dans un délai très court, en termes de types de contrats que vous devriez utiliser pour les logiciels. Nous travaillons en étroite collaboration avec Danielle Moyer et Meg Dake et son équipe pour essayer de fournir ces conseils en termes de, OK, pas de prix fixe ferme, mais quoi ? Quels sont les meilleurs moyens d’acheter des sprints ? Et comment puis-je tenir les entrepreneurs responsables ? Parce que c’est une partie du problème : s’ils ne livrent pas, comment puis-je configurer cela pour m’assurer que je ne vous paie pas pour faire quelque chose et que je vous paie ensuite pour le réparer ? Donc, il y a beaucoup d’activité et je pense certainement que dans les six à 12 prochains mois, nous aurons compris cela.

Note de l’éditeur: Cette interview a été modifiée pour plus de longueur et de clarté.