選自公眾號：空天防務觀察

“軟件和網絡推動了美國軍事部門的作戰、訓練和業務能力。在作戰人員的武器庫中，幾乎所有武器都是由軟件定義的，我們更有可能通過安裝新軟件而不是修改硬件來‘提高’系統的殺傷力。”

(資料圖片)

——美國防部作戰試驗與鑒定局2019財年報告

2022年2月，美國防部副部長凱瑟琳?希克斯（Kathleen Hicks）簽署了《美國防部軟件現代化戰略》，該戰略是2019年7月發布的《國防部數字現代化戰略》的子戰略，以2018年12月發布的《國防部云戰略》為基礎并取而代之。新的戰略提出了“以相應速度實現軟件彈性交付”的愿景，指明了五項總體原則，強調了軟件工廠、基于云，以及開發、安全、運維一體化（DevSecOps）框架等軟件現代化思路，制定了長期目標與具體思路。

01

美國對武器系統軟件的看法

在美國防部看來，軟件已成為武器系統最重要的組成部分，其重要性不斷增加。軟件定義了武器系統在戰斗中的觀測、通信和作戰的方式。軟件開發過程最初的設計和采辦決策往往具有深遠而長期的影響，甚至影響了戰爭中武器系統的效能，也影響了隨時間推進針對環境和需求不斷變化的適應能力。

現在，武器系統提供的許多能力來自系統的軟件，而不是硬件。相關以硬件為中心構建能力的思路正在大量的轉變到以軟件為中心構建能力的思路上。美國國防分析研究所2017年發表的一篇論文所指出“國防部的武器系統中以軟件實現功能的需求正在爆炸性增長。與此同時，國防軟件生產能力和工業基礎能力增長得沒有那么快。”

在新的武器系統中，軟件已成為研發和鑒定的重要部分。不僅正在開發的新武器系統受軟件影響，如F-16和F-18戰斗機等傳統武器系統的使用壽命能夠超出設計壽命，也很大程度上依賴軟件升級和改進。

美國防部和防務智庫甚至提出了軟件永存（Software never dies）、軟件永未完成（Software is never done）、軟件定義戰爭（Software Defined Warfare）的說法。并提出，為武器系統全壽命周期內改進軟件創造條件是一項戰略需要，可以確保武器系統在超出早期系統設計需求和規范的條件下，也能夠利用軟件開發實踐持續升級系統能力，適應新的威脅和環境。

02

美國武器系統軟件的狀態和變化

最近40年，美國武器系統軟件規模的增長非常劇烈，下圖以航電軟件為例展示了關鍵武器系統中軟件代碼行數的增長情況（單位為 千行源代碼）。

航空電子軟件中軟件源代碼行（SLOC）的增長情況

與此同時，武器系統中軟件造成的風險占比也越來越高，根據美國防部2018年的評估，60%的武器系統采辦項目中遭遇了軟件引發的風險。這是主要是因為在構建武器系統的新能力時，尚未獲得實際作戰經驗，不可能預計到所有的問題和需求，不止在基本操作方面無法全面預計，在作戰概念、戰術、技術和程序方面也是如此。

其次，軟件本身非預期的相互依賴可能會產生復雜的意外情況，這類問題一般是由軟件的底層體系架構引發。

早先美國軍方武器系統軟件采辦的最佳實踐通過在項目開始時詳細說明軟件的功能需求來降低風險（最佳實踐一般指某種技術、方法、過程、活動或機制可以使生產或管理實踐的結果達到最優，并減少出錯的可能性）。

然而，當對武器系統進行測試、實驗、驗證時，通常都會識別大量額外需求，這就導致了大量的軟件風險和不斷的延期交付。

03

美國武器系統軟件研發深受現代商業軟件工程實踐影響

1、敏捷開發模式

在過去20年間，商業軟件開發實踐經歷了重大變化。2000年以來移動互聯網的發展，使得軟件企業無法提前設計和分析所有需求，也無法預測未來的安全和測試問題，這迫使業界尋找軟件開發的新方法，因為等待需求確認就意味著失去市場。因此轉而探索增量的、迭代的軟件開發方法，隨著時間的推移增量式的提升軟件能力。

可以將敏捷模式和瀑布模式的對比，上圖為敏捷模型，主張周期性的開展需求、設計、開發、測試、集成、反饋等軟件研發活動，下圖為瀑布模型，按階段開展工作，等一個階段所有工作完成之后，再進入下一個階段。

軟件行業經常使用管理學中的“最佳實踐”一詞來描述新的技術方案、模式或者路徑 。當前商業軟件開發的最佳實踐已經從傳統的 “瀑布式”軟件開發模式（即先確定功能需求和規范、再編寫軟件，之后按照需求和規范測試軟件）演變為敏捷（Agile）開發模式或者迭代（Iterative）開發模式。

和瀑布式不同，敏捷開發模式中，首先明確軟件目標和部分特性，但并不定義明確而嚴格的需求。用戶反饋用于確定每次迭代的目標（稱為“沖刺”），從而明確最小可行產品（MVP）的定義和需求，以實現盡早交付，交付后再和用戶一起反復迭代。開發團隊采用沖刺、測試、評審、反饋等組織活動，在較小模塊范圍中開發、測試軟件，集成部署后可以由用戶重復增量的試用、評估和反饋。這種方法允許將更新和改進快速集成到軟件中，在許多情況下，軟件每天都會進行更新。

這種現代的敏捷開發模式，需要重新組織管理人員、開發人員、用戶、運維人員，重新定義相關職責、關系、組織、活動甚至文化等管理要素。此外，還對軟件本身和軟件環境提出了新的要求：

（1）因為軟件是持續變更的，允許不斷的調整需求內容和需求優先級，在設計軟件架構時就必須考慮允許這種變更。因此，必須將功能按照模塊化分解，考慮軟件功能的構成、耦合和擴展方法。有些商業公司會同時啟動多個團隊采用不同架構開發同一款軟件，并在必要時再從縱深的角度考慮選擇一個架構進行長期開發。

（2）軟件的持續變更，就意味著持續開發、測試、試用、反饋、評定需求、開發……的周期性迭代活動，測試意味著需要重新構建、編譯和集成，用戶的試用反饋則意味著重新部署，如果集成和部署過程過于復雜則會造成非常高的迭代成本，這就產生了當前的自動構建、自動測試、持續集成和持續部署工具，也促進了開發運維一體化框架（DevOps）等軟件開發框架和軟件工廠的發展。

2、開發運維一體化（DevOps）框架

DevOps的名稱由開發（Development）和運維（Operations）組合而來，顧名思義，這種模式強調開發、IT運維和質量管理之間的協作，目標是更快更頻繁地發布軟件。因此，開發人員也可能負責運營，或者可能有兩個獨立的團隊進行開放性溝通。無論具體如何管理和配置，都應該讓團隊感覺到對整個軟件壽命周期的所有權。DevOps的整體價值觀與敏捷一致，可以將DevOps看做將敏捷實踐擴展到產品壽命周期的所有范圍。

DevOps最大的兩個特點是協作和自動化。在自動化方面，一個常見的DevOps原則是 “基礎設施即代碼”（Infrastructure as Code），這意味著對操作環境的管理與代碼相同，需要進行版本控制、自動化和持續測試。另一個常見的特征就是形成了針對開發軟件的自動構建、自動測試、持續集成和持續部署的管道。

DevOps的目標是頻繁的小版本更新，為了達到敏捷和快速的目的，一般采用以下原則：

流程自動化：DevOps團隊希望盡可能頻繁地發布軟件，這需要自動化測試和開發、持續集成和持續部署交付）。

標準化環境：當新代碼在操作環境中不能工作時，會出現許多互操作性問題。由于DevOps團隊使用與運行環境一致的標準化環境開發軟件并進行故障檢測和排除，因此開發人員越來越熟悉此環境。標準化環境有助于解決這些互操作性問題。

微服務：為了實現軟件的頻繁發布，DevOps團隊使用基于微服務集成的軟件架構，微服務是小型、分離的軟件組件，理想情況下獨立于其他軟件組件工作。

監測：DevOps團隊負責運行和維護，因此團隊需要持續監控生產環境運行的軟件。頻繁發布可以幫助團隊定位問題版本所在，并快速解決。

DevOps框架也是一種開發模式，將敏捷思路納入軟件的全壽命周期，涵蓋設計、開發、構建、集成、部署、運行、反饋等全階段，DevOps更是一種模式和文化，而非嚴格的規范，有大量的支持工具和流程供企業選擇

3、軟件工廠

軟件工廠也是一種創新的方法，可以幫助開發團隊基于可重用流程和軟件框架創建軟件開發的流水線。通過提供一系列資源、工具，并采用和執行相關規范，軟件工廠能夠幫助開發團隊重用模板、規范、實踐路徑從而實現規模化開發，實現更快的交付、更少的測試、更高的質量以及更好的可維護性。

在美國軍方的研究中，將軟件工廠定義為“低成本、基于云的計算環境，能夠組裝一系列工具，使開發人員、用戶和管理人員每天能夠在一致的節奏中協同工作。”

現代商業軟件開發最佳實踐同時使用敏捷開發模式和軟件工廠，軟件工廠的落地是一組軟件工具，開發人員使用這些軟件工具編寫代碼，確認代碼符合規范和相關要求，程序員與開發團隊的其他成員協作，自動化的構建、測試和記錄過程進度。這樣，開發團隊就能夠在用戶頻繁反饋的情況下進行迭代開發。此外，商業機構還使用了一些新的工具和技術并將其規范化應用，包括：

規模自動化

在產品的整個生命周期內持續開發

提高計算能力并降低計算成本

靜態測試、動態測試和模糊測試技術，支持大量自動化軟件測試

開源，利用開發人員社區來創建可重用的組件和工具

該圖為某軟件工廠思路架構圖，軟件工廠與開發模式的不同在于，開發模式一種文化、組織方法和工具，軟件工廠則是開發模式的徹底貫徹、規范化和規模化

04

美國武器系統軟件研發的現狀和變革

1、美國以前的武器系統軟件采辦過程

在過去15年間，商業軟件開發經歷了重大變化，而武器系統軟件的開發則繼續使用1970年代至1990年代開發的技術。美軍多數情況下在軟件采辦中仍然使用較慢的傳統瀑布方法，這種方法在多年前已經被商業公司拋棄。

美國防部傳統的瀑布式軟件開發過程一般為：首先明確并編制軟件的最終需求，在項目開始時設定進度和成本，并在發布開發建議書（RFP）之前進行初步設計評審。達到里程碑B和完成合同授予后，也完成了軟件各部分的源代碼行數（SLOC）的估算，以此確定資源來開發軟件。經過5-7年的開發周期后， 進行系統測試和缺陷修正，最后正式作為產品發布并部署。

美軍傳統的瀑布式采辦流程

2、美國對軍用軟件引入現代開發方法的認識

2017年以來，美國防部、美國國防創新委員會、美國政府問責局以及美國國防授權法中陸續發布一系列文件，旨在推進在武器裝備系統軟件采辦中引入現代化方法。明確了對瀑布式方法缺點的批評，和對敏捷式方法、軟件工廠等現代方法的認可。

首先因為采用敏捷方法的商業公司都高度評價這種方法帶來的回報，而敏捷模式的一系列方法已經成為商業軟件開發的標準，從微軟到亞馬遜，從谷歌到臉書，包括傳統IT企業IBM也轉而使用這種方法。與此同時，卻沒有商業公司從敏捷方法反向過渡到瀑布方法。

其次，因為缺少權威的或明確的數據能夠明確說明敏捷等現代軟件方法的優勢，2016年開始，美國軍方不同的部門和研究機構對敏捷開發方法進行了評估和實驗。比如，2018年財年美國國防授權法（NDAA）中就明確要求啟動2個敏捷軟件試點，涉及到陸軍的綜合防空導彈防御（IAMD）、空軍的F-22能力管道、海軍的海上戰術指揮與控制（MTC2）等14個項目。此后，包括美國防部負責采辦和維護的副部長、美國防部創新委員會、美國政府問責局等機構對相關的項目進行了評估，這些評估和實驗項目驗證了在商業機構采用敏捷式開發實踐所帶來的好處。并認為，在許多情況下，采用敏捷、迭代開發方法能夠使國防部和國防承包商受益匪淺。

第三，美國防部認為并不是所有的項目都很適合敏捷或迭代的開發方法。如發動機數字控制系統和壽命將終止的遺留平臺等，未必能從敏捷開發中受益。固定硬件平臺的控制系統在壽命周期內很少變化，而且有些軟件往往有相關的操作限制也不建議改變。然而，即使這樣的系統也會受益于現代軟件工廠所鼓勵的自動化構建和測試。

美國防部認為，敏捷方法的主要好處是能夠快速、連續地捕獲軟件缺陷，輕松集成新代碼，并在整個應用程序開發過程中獲取用戶反饋。武器平臺任務軟件、電子戰、通信、雷達和發射系統等軟件都能從系統能力的持續改進和擴展中獲益，這對于創造戰術優勢和應對戰略突襲至關重要。并認為電子戰領域的軟件尤其如此，因為在電子戰中，快速的軟件改進能夠在有限的作戰周期內部署新的探測能力從而形成優勢。

3、美軍不斷鼓勵和牽引敏捷開發模式的應用

從2018年開始，美國防部不斷推進武器系統軟件采辦中現代工程實踐的應用，其中最重要的就是敏捷開發方法。這在2018年之后多年的國防授權法案中都有體現，依據該法案，在美國政府問責局每年的武器系統采辦項目評估中，都會針對所有項目的軟件現代化實踐進行專項評估，同時給出建議。在國防授權法和政府問責局的要求和建議中，現代開發方法的定義還比較開放，極限編程、KanBan、Scrum、DevOps、精益軟件開發都算作是廣義的現代軟件開發或敏捷軟件開發方法。

到2022年，美國軍方項目中使用敏捷等現代軟件方法的項目占比已經很高。

現代軟件開發方法的使用：美國政府問責辦公室2022年調查了59個重大國防采辦項目（MDAP）和中層采辦項目（MTA），其中有39個項目報告使用了至少一種現代方法。中層采辦項目中使用現代方法的頻率高于重大國防采辦項目，19個中層采辦項目中有15個（79%）使用現代方法，而40個重大國防采辦項目中有24個（60%）使用現代化方法。

工作軟件的盡早和持續交付：現代軟件開發方法（如敏捷）強調盡早和連續的軟件交付，以及快速的周期性反饋，以便持續評估軟件的功能、質量和用戶滿意度。連續交付的頻率在商業界能夠達到每2周一次。

美國防部認為考慮武器系統的安全性要求，6個月至1年交付一次軟件更為合適。在美國政府問責辦公室調查使用現代軟件開發方法的39個項目中，有22個項目在12個月以內向用戶交付一次軟件。但美國政府問責辦公室仍然認為6個月到1年的軟件交付頻率不符合敏捷原則，不會從快速迭代反饋循環中獲益。

美國政府問責辦公室在2022年年度評估報告中調查了40個重大國防采辦項目和19個中層采辦項目中現代軟件方法的應用情況

4、美軍推進和規范化DevSecOps框架應用并建設推廣“一號平臺”

在實際推進中，美國防部開展了一系列行動。首先，由美空軍牽頭，推進“開發、安全和運維一體化”（DevSecOps）框架。美國防部總信息官已經簽署正式文件將DevSecOps框架視為現代軟件開發實踐的主要參考框架。此后，在空軍部的牽引下，建設了PlatformOne產品，被美國防部授權在美國軍方全面推廣。

DevSecOps 是 DevOps 的增強，允許將安全實踐集成到 DevOps 方法中。與傳統的集中安全團隊模型相反，每個開發團隊都有權在其軟件交付中考慮安全控制問題。安全實踐和測試在軟件開發周期的早期執行，符合安全左移的思路。其安全實踐內容主要包括：靜態測試、動態測試、微服務交互測試。

DevSecOps軟件生命周期階段如圖所示，涉及9個階段的迭代：計劃、開發、構建、測試、發布、交付、部署、操作和監測，安全嵌入到每個階段

“一號平臺”（Platform One）即是指的美國防部DevSecOps服務團隊，也是指的DevSecOps落地的軟件產品。

作為軟件產品，一號平臺提供規范的DevSecOps工具和環境，能夠創建了 DevSecOps 編碼環境，可幫助軟件團隊將精力集中在研發、運行和持續改進其軟件應用程序上。

根據報道，“一號平臺”至少包括“鐵銀行”（Iron Bank）和“大爆炸”（Big Bang）2個工具，“鐵銀行”是軟件容器倉庫，提供超過800個開源和商業貨架軟件，軟件已根據國防部規范進行了安全加固，“大爆炸”是DevSecOps規范化實例構建工具，能夠支持移動端、云端和本地的快速DevSecOps環境構建。

5、美軍推進軟件工廠建設

2017年，美空軍組建了美軍第一個軟件工廠——凱塞爾航線（Kessel Run），此后美空軍的軟件開發團隊網絡取得了巨大的發展，已經有遍布全美的17家軟件工廠、3個軟件工程小組和2個服務機構。根據2022年年初媒體報道，美國軍方的軟件工廠數量已經達到29家，除空軍的軟件工廠建設較早外，美陸軍于2021年開設了第一個陸軍未來司令部軟件工廠，美海軍2021年也開設了名為“鍛爐”（Forge）的軟件工廠和名為“黑珍珠”（Black Pearl）的服務機構。

近年來，美空軍的軟件開發團隊網絡取得了巨大的發展，已經有遍布全美的17家軟件工廠、3個軟件工程小組和2個企業服務機構（美空軍圖片）

在技術和方案上，美國防部不斷提升“DevSecOps”生態環境和“一號平臺”的先進性和完整度。并出臺了一系列手冊、工具指導和推進軟件工廠的建設。DevSecOps和“一號平臺”為軟件工廠提供了用于開發、構建、測試、安全、發布和交付軟件的流程、管道、腳本和工具，以最少的人工干預生成一組軟件開發、測試、部署環境，自動化了開發、構建、測試、發布和交付階段的活動。

美國防部DevSecOps軟件工廠的參考架構圖，包括用于開發、構建、測試、安全、發布和交付軟件的流程、管道和工具

6、美國防部發布新的軟件采辦路徑并實施

2020年1月，美國防部更新了其采辦指令5000.02，確立了新的適應性采辦框架（ADAPTIVE ACQUISITION FRAMEWORK ）以及上層政策，以實現靈活和適應性采辦。并將采辦路徑和職責的選擇權分配給采辦官員。

新的適應性采辦框架建立了六種獲取途徑：

（1）應急能力采辦（2）中層采辦（3）重大能力采辦（4）國防業務系統采辦（5）軟件采辦（6）服務采辦。

之后，2020財年的美國國防授權法案要求國防部編制軟件采辦途徑。2020年10月，美國防部發布題為“軟件采辦路徑操作”的指令5000.87，旨在集成現代軟件開發實踐，如敏捷、DevSecOps和精益實踐，目的提供安全軟件的高效和有效獲取、開發、集成和及時交付。

根據兩個指令文件，軟件采辦路徑專為軟件密集型系統設計，包含兩條路徑：用于部署在商用硬件和云平臺上運行的軟件路徑，以及用于武器系統中的嵌入式軟件路徑，包括對嵌入式軟件進行升級和改進。指令鼓勵采辦項目中將決策權交給最低實踐級別，經常與用戶接觸，盡可能實現自動化，并至少每年達到關鍵采辦項目里程碑。

在指令發布后，國防部、空軍和國防采辦大學都開展了相關培訓，美國防部還發布了一系列指南，提供了技術工具和資源，并創建了軟件現代化高級指導小組實現現代軟件實踐的過渡。

感謝您閱讀，我們下期見！