敏捷開發在大型航天地面系統軟件應用研究

中國人民解放軍63921部隊 趙爽 劉文紅 翟文麗

一、引言

航天地面系統軟件服務于航天和經濟建設，隨著各類先進技術在天基領域的不斷應用，航天地面系統軟件越來越多地呈現出信息化、體系化、自動化的特點，軟件在航天地面系統軟件中所占的比例大幅上升，對軟件研制的時效性和質量要求越來越高，當前航天地面系統軟件研制面臨著下列問題和挑戰：

（一）航天地面系統軟件研制方式的轉變

航天地面系統軟件研制發生了巨大的變化，軟件規模由單體軟件轉變為大型復雜系統，研制模式由用戶單位自研轉變成招標研制或聯合研制，從單一團隊到多團隊協同開發，特別是對于大型系統，涉及到十幾家企業聯合研制。軟件開發模型從瀑布模型轉變為敏捷開發，以管理為中心的離散式模型轉變為以生產為中心的連續式模型；軟件研制過程中涉及的角色、人員變多，需要大量協同調度等。面對競標研制、競爭性采購的新常態，在“多任務并舉、高密度發射、大批量交付”的科研形勢下，航天地面系統軟件研制問題日益突出。

（二）需求不確定

時間緊、論證不充分導致任務需求獲取不足，軟件需求分析不全面，用戶試用時需求發生比較大的變化，滿足不了任務需要，改動軟件工作量大，影響軟件進度和質量。需求沒有進行有效的管理，需求變更難以控制，系統問題難以追溯，需求維護困難，更無法實現積累與復用。

大型航天軟件系統軟件開發成本高、風險大、周期長，參與單位及人員眾多，如何能夠保證研制進度、確保大型航天地面系統軟件的質量，增強航天軟件系統性能成為亟待解決的問題。本文以某大型航天地面系統為例，研究了敏捷開發在大型航天地面系統的應用。

二、基于敏捷開發的軟件研制

（一）大型航天地面系統簡介

大型航天地面系統存在著系統復雜、業務廣、技術含量高等特點，涉及多個學科領域業務知識，交叉性強，規模大，研制周期長，集成難度高，管理復雜。這類系統包含多個分系統、子系統及軟件配置項，涉及多個用戶單位，用戶數量多崗位角色多，需求復雜且不明確。以某系統為例，包含6個分系統、35個子系統，188個軟件配置項，由9家企業共同研制完成，用戶單位12家，但整個系統研制周期不到2年，同時還要滿足急需任務需要。系統基于微服務架構[1]，采用容器化部署方案[2]。

（二）敏捷開發

敏捷開發是一種以人為核心、迭代、循序漸進的開發方法，在1991年由Roger提出[3]，它的核心思想在于快速、增量式地交付可工作的軟件，個人與溝通勝過過程與工具；可工作的軟件勝過面面俱到的文檔；客戶協作勝過合同談判；響應變化勝過遵循計劃[4-8]。21世紀初，敏捷宣言的發布標志著敏捷軟件開發方法正式誕生。敏捷開發主要包括動態系統開發方法、Scrum、極限編程（XP）、透明水晶開發方法（Crystal Methods）和特性驅動開發（FDD）等[4]，在敏捷開發中，軟件項目被劃分為多個子項目，各個項目的成果都經過測試，具備集成和可運行的特征。敏捷開發一般采用2—4周的迭代周期便能快速響應用戶的需求，有效的節省資源，一經提出便受到行業的推崇，越來越多的軟件公司始采用敏捷開發模式[9-17]。

（三）敏捷開發的應用

基于大型航天地面系統的復雜性及需求不明確特點以及敏捷開發的適應性，確定采用敏捷開發研制模式，進行敏捷迭代開發、持續集成和測試。項目建立了適應敏捷開發的組織結構，明確了職責，并強調進行基于敏捷的需求工程，加強需求開發和管理。敏捷開發軟件研制流程如圖1所示，覆蓋從立項論證到運行維護乃至報廢全過程。

圖1 敏捷開發軟件研制流程

在基于敏捷迭代開發中，整個軟件研發周期劃分為原型版、任務版和正式版三個階段。原型版軟件為了滿足急需任務需要，基于用戶原始需求，完成系統基本和急需任務功能，界面也較為簡單。用戶代表高度參與此階段工作，討論任務需求，參與項目每日站會，對照需求表查看項目功能完成情況。任務版軟件是在原型版軟件基礎上部署到典型用戶單位真實環境進行試用，用戶根據任務需求和崗位職責對照軟件進行試用，反饋新的使用需求和軟件存在的問題，研制單位根據反饋問題細化需求，修復缺陷，增加功能，對軟件進行升級，并開始多輪的構建和測試，進行迭代完善，持續交付。正式版軟件是在任務版軟件基礎上完成軟件系統所有功能，實施第三方評測，開展試驗鑒定和驗收測試工作，形成最終的正式交付版本。

每個軟件版本的研制又劃分為一系列短小的、固定長度的小迭代項目。每一次迭代都包括需求分析、設計、實現和集成與測試。由于項目復雜，人員眾多，項目采用集中式開發和異地分散式開發相結合的模式[18]，在原型版階段各研制單位主要在各自的分散開發環境中進行Scrum迭代開發，制定sprint，召開每日站會等，形成數據庫段和軟件段。軟件段包括插件應用程序段、WEB應用程序段、二次開發接口段等等。在集中開發環境中，將段按照約定的標準規范基于統一的集成框架進行迭代的集成和測試，形成系統和系統文檔，如圖所示。系統采用開放式面向服務架構，支持界面集成、服務集成及數據集成：

1）界面集成。遵循統一的界面集成規范開發集成前臺終端軟件，通過統一的界面集成框架和通用控件庫，確保各系統的用戶界面風格和操作方式的一致性。

2）服務集成。新研和已有應用服務資源通過統一的服務目錄，完成跨平臺服務調用和數據訪問，實現服務集成。

3）數據集成。通過統一的數據主題服務目錄提供跨平臺的數據資源訪問服務集成。

圖2 開發方式

三、敏捷需求工程

（一）需求工程

需求工程主要包括需求開發（分析）和需求管理，如圖3所示，需求開發包括需求獲取、需求分析和需求確認，包括引出用戶需求并將其轉化為產品需求，對產品需求進行分解，描述產品的功能、性能、設計特征、驗證要求等。需求管理包括需求變更管理和需求追蹤。鑒于敏捷開發針對的是需求變化多、響應速度快、能頻繁交付的開發場景，因此敏捷開發需求工程更加占用重要的地位[19][20]，貫穿于基于敏捷開發的軟件研制的全生命周期，重要程度甚至高于基于瀑布模型的軟件研制。航天地面系統軟件從立項論證開始直至驗收交付甚至到維護保障都在進行需求工程。項目需求來源包括系統立項論證報告（可行性分析報告）、研制技術要求（任務書)、需求匯編報告、需求申請表及紀要等等。在立項論證階段對系統定位、使命任務、關鍵指標、質量要求、進度以及經費等進行系統論證，立項論證的結果是系統需求的源頭，主要是系統業務需求分析及主要功能分析，在后續的技術（建設）方案、任務書、需求規格說明等都在深化需求。運行維護需求開發對交付后產品的運行提供技術支持與服務，監控軟件的運行狀態，獲取維護需求，并制定相應的解決方案，必要時對產品進行改造升級維護。

圖3 需求工程

由于本項目系統復雜，規模比較大，用戶比較多，需求來源多，因此著重進行了需求開發和需求的有效管理。為了規范系統需求的提出、分發、變更及維護管理，控制需求變化引起的開發、測試與需求不一致的情況，確保用戶提出的需求理解準確，在系統中得到充分實現，成立了需求管理組織機構，建立需求管理規定，指定專人，常態化開展需求對接及管理工作，收集用戶需求，每半個月開展一輪“需求理解—對接—分析—確認”工作，保障系統開發、測試、上線及運行管理等工作的順利進行。

（二）角色與職責

1.用戶單位為系統主要使用單位，履行下列職責：

(1)負責提出系統用戶需求，提出對系統的功能、性能、設計約束和其他方面的期望和要求等；

(2)負責解釋項目開發過程中遇到的本單位的系統需求問題；

(3)負責對本單位最終用戶需求實現情況進行結果驗證；

(4)負責確認需求結果，參與項目驗收等。

2.總體單位為系統論證、建設及使用單位，履行下列職責：

(1)負責需求管理的整體協調工作，包括需求管理流程的審批等；

(2)負責提出系統需求，提出對系統的功能、性能、設計約束和其他方面的期望和要求等；

(3)負責系統需求變更分析、需求優先級評估等工作；

(4)負責需求申請和變更審批，對需求進行管理和追蹤；

(5)負責對需求實現進行結果驗證，確認需求結果并進行項目驗收；

(6)負責維護需求信息、跟進需求變更以及需求處理進展，定期向相關領導報告需求進展。

3.研制單位負責實現系統各種需求，履行下列職責：

(1)負責需求開發過程相關工作，處理需求開發、實現、測試和系統上線運行工作；

(2)負責對用戶提出的需求進行系統的功能、性能、設計約束和其他方面的需求分析；

(3)負責編寫軟件需求文檔及需求列表等，實現需求人員與開發人員的有效交互；

(4)負責根據需求評審和評估意見，及時修改和調整需求內容；

(5)負責本單位從研制合同開始到項目驗收的需求管理與追蹤；

(6)負責提出系統開發、性能優化、軟件升級等需求。

（三）需求開發

需求開發（獲取）主要是獲得系統目標需求和引出用戶使用需求，由于本項目用戶較多且分散，因此將其分為主動獲取和主動提交。主動獲取指總體單位和研制方通過需求調研表、需求文檔、研討會等形式主動獲取用戶需求。主動提交指用戶或用戶代表在原型系統使用過程中記錄使用需求，形成用戶需求文檔（需求匯編），通過需求申請表和需求匯編報告等形式主動向總體單位和研制方提交用戶需求。需求申請表如表1所示：

表1 需求申請表

本項目當系統初步完成原型版開發提交用戶使用后，用戶根據使用過程中的問題和使用需求，形成用戶需求匯編。例如某典型單位多個崗位的用戶提出上下冊200多頁的需求匯編，其中涵蓋系統所有子系統。

（四）需求理解與分析

在獲得用戶需求后，需將其轉化為產品需求，并對產品需求進行分解，描述產品的功能、性能、設計特征、驗證要求等。研發項目組在拿到來源于用戶單位的需求匯編（上/下冊）和需求申請表，梳理待明確或待細化問題，初步形成需求分析報告，進一步與用戶對接溝通，理解需求。

在需求溝通理解的基礎上，研制方進一步對需求進行分析，梳理出680項原始需求，建立了項目需求列表。研發人員依據項目需求列表，進行了需求分析，將需求分解映射到軟件配置項，確定需求優先級、研制單位及在哪個版本中實現該需求，有些不在項目建設范圍內的需求納入到項目二期是實現，如表2所示。上述680項在原型版實現190項，任務版64，正式版266項，其余161項需求納入項目二期建設。

表2 需求分析表

（五）需求確認

需求確認按照需求分析評審和軟件成果確認兩種方式組織實施。

1.需求評審

總體單位組織需求分析預審，參加需求預審的單位包括用戶單位及各承研單位，完成對需求的預審查，確保處理措施明確可行，初步設計合理，完成時間滿足要求。各承研單位根據預審查的問題進行修改完善。

2.軟件確認

軟件完成小版本迭代后，由總體單位組織各承研單位提交軟件階段成果，對軟件功能完成情況進行確認，對軟件版本進行管理，及時更新至部署環境，進一步由用戶進行功能確認后，部署更新至各用戶單位。

（六）需求管理

為了保證需求的完整性、一致性，需要在整個軟件生命周期對需求進行管理，追蹤從用戶到產品，以及產品部件的需求，并控制其變更，需求追蹤表如表3所示。

表3 需求追蹤表

四、敏捷與GJB5000的融合

GJB5000標準是軍用軟件研制能力成熟度模型，GJB5000A是以CMMI1.2版本為基礎制定的適用于軟件開發全過程的通用標準，關注標準化的研制過程和規范化的文檔，對軟件工程過程進行管理，保證按時交付高質量的軟件產品。在實施過程中，特別是在5000A評價的早期，多采用嚴流程、重文檔的瀑布生存周期模型，但這與輕量級、輕文檔的敏捷開發并不矛盾，在本質上都是為了提高產品質量、保證研制進度[21-23]。GJB5000A規定了管理、工程和支持實踐域，未規定如何實施，鼓勵依據標準因地制宜，建立本地化軟件過程管理體系，可以根據項目特點進行適當的剪裁。GJB5000A在向5000B改版時，特別強調了對于敏捷方法的適用，并在某研制企業進行了試點，分析了其覆蓋的實踐域。

在基于敏捷研制過程中，需求開發和管理、配置管理都占有很高的地位，計劃會議、每日站會、評審會議和回顧會議等都是在進行項目策劃和管理，從傳統的WBS轉為基于需求特性進行項目管理。產品任務列表、需求匯編報告、紀要、每個迭代版本的設計、測試大綱、報告等都是文檔類產品，特別是在本項目研制過程中，在任務版和正式版交付時，都要求整理過程記錄和文檔，形式規范化的項目文檔。而敏捷工具的使用，自動化的記錄和分析了項目研制過程中的數據，供質量保證和測量與分析使用。敏捷開發的特點就是需求不明確，因此會引入變化和風險，在每個迭代周期，都在不斷的識別風險并跟蹤，有效進行風險的緩解。

五、結論

敏捷開發方法的應用解決了傳統瀑布模型對于需求不確定反復迭代的大型軟件項目不適用的問題，極大的降低了項目的風險，保證了項目的進度，在早期就能得到用戶對系統的反饋，并在初始迭代中實現，項目質量也得到了保證。但敏捷開發對用戶的參與度要求比較高，可以說用戶已經成為了研發團隊的一員，人與人之間的溝通十分重要，因此構建合理流暢的工作流程、分散與集中的工作環境、團隊的有效合作特別重要。