中國(guó)人民解放軍63921部隊(duì) 趙爽 劉文紅 翟文麗

一、引言

航天地面系統(tǒng)軟件服務(wù)于航天和經(jīng)濟(jì)建設(shè)，隨著各類先進(jìn)技術(shù)在天基領(lǐng)域的不斷應(yīng)用，航天地面系統(tǒng)軟件越來(lái)越多地呈現(xiàn)出信息化、體系化、自動(dòng)化的特點(diǎn)，軟件在航天地面系統(tǒng)軟件中所占的比例大幅上升，對(duì)軟件研制的時(shí)效性和質(zhì)量要求越來(lái)越高，當(dāng)前航天地面系統(tǒng)軟件研制面臨著下列問(wèn)題和挑戰(zhàn)：

（一）航天地面系統(tǒng)軟件研制方式的轉(zhuǎn)變

航天地面系統(tǒng)軟件研制發(fā)生了巨大的變化，軟件規(guī)模由單體軟件轉(zhuǎn)變?yōu)榇笮蛷?fù)雜系統(tǒng)，研制模式由用戶單位自研轉(zhuǎn)變成招標(biāo)研制或聯(lián)合研制，從單一團(tuán)隊(duì)到多團(tuán)隊(duì)協(xié)同開(kāi)發(fā)，特別是對(duì)于大型系統(tǒng)，涉及到十幾家企業(yè)聯(lián)合研制。軟件開(kāi)發(fā)模型從瀑布模型轉(zhuǎn)變?yōu)槊艚蓍_(kāi)發(fā)，以管理為中心的離散式模型轉(zhuǎn)變?yōu)橐陨a(chǎn)為中心的連續(xù)式模型；軟件研制過(guò)程中涉及的角色、人員變多，需要大量協(xié)同調(diào)度等。面對(duì)競(jìng)標(biāo)研制、競(jìng)爭(zhēng)性采購(gòu)的新常態(tài)，在“多任務(wù)并舉、高密度發(fā)射、大批量交付”的科研形勢(shì)下，航天地面系統(tǒng)軟件研制問(wèn)題日益突出。

（二）需求不確定

時(shí)間緊、論證不充分導(dǎo)致任務(wù)需求獲取不足，軟件需求分析不全面，用戶試用時(shí)需求發(fā)生比較大的變化，滿足不了任務(wù)需要，改動(dòng)軟件工作量大，影響軟件進(jìn)度和質(zhì)量。需求沒(méi)有進(jìn)行有效的管理，需求變更難以控制，系統(tǒng)問(wèn)題難以追溯，需求維護(hù)困難，更無(wú)法實(shí)現(xiàn)積累與復(fù)用。

大型航天軟件系統(tǒng)軟件開(kāi)發(fā)成本高、風(fēng)險(xiǎn)大、周期長(zhǎng)，參與單位及人員眾多，如何能夠保證研制進(jìn)度、確保大型航天地面系統(tǒng)軟件的質(zhì)量，增強(qiáng)航天軟件系統(tǒng)性能成為亟待解決的問(wèn)題。本文以某大型航天地面系統(tǒng)為例，研究了敏捷開(kāi)發(fā)在大型航天地面系統(tǒng)的應(yīng)用。

二、基于敏捷開(kāi)發(fā)的軟件研制

（一）大型航天地面系統(tǒng)簡(jiǎn)介

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

（二）敏捷開(kāi)發(fā)

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

（三）敏捷開(kāi)發(fā)的應(yīng)用

基于大型航天地面系統(tǒng)的復(fù)雜性及需求不明確特點(diǎn)以及敏捷開(kāi)發(fā)的適應(yīng)性，確定采用敏捷開(kāi)發(fā)研制模式，進(jìn)行敏捷迭代開(kāi)發(fā)、持續(xù)集成和測(cè)試。項(xiàng)目建立了適應(yīng)敏捷開(kāi)發(fā)的組織結(jié)構(gòu)，明確了職責(zé)，并強(qiáng)調(diào)進(jìn)行基于敏捷的需求工程，加強(qiáng)需求開(kāi)發(fā)和管理。敏捷開(kāi)發(fā)軟件研制流程如圖1所示，覆蓋從立項(xiàng)論證到運(yùn)行維護(hù)乃至報(bào)廢全過(guò)程。

圖1 敏捷開(kāi)發(fā)軟件研制流程

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

每個(gè)軟件版本的研制又劃分為一系列短小的、固定長(zhǎng)度的小迭代項(xiàng)目。每一次迭代都包括需求分析、設(shè)計(jì)、實(shí)現(xiàn)和集成與測(cè)試。由于項(xiàng)目復(fù)雜，人員眾多，項(xiàng)目采用集中式開(kāi)發(fā)和異地分散式開(kāi)發(fā)相結(jié)合的模式[18]，在原型版階段各研制單位主要在各自的分散開(kāi)發(fā)環(huán)境中進(jìn)行Scrum迭代開(kāi)發(fā)，制定sprint，召開(kāi)每日站會(huì)等，形成數(shù)據(jù)庫(kù)段和軟件段。軟件段包括插件應(yīng)用程序段、WEB應(yīng)用程序段、二次開(kāi)發(fā)接口段等等。在集中開(kāi)發(fā)環(huán)境中，將段按照約定的標(biāo)準(zhǔn)規(guī)范基于統(tǒng)一的集成框架進(jìn)行迭代的集成和測(cè)試，形成系統(tǒng)和系統(tǒng)文檔，如圖所示。系統(tǒng)采用開(kāi)放式面向服務(wù)架構(gòu)，支持界面集成、服務(wù)集成及數(shù)據(jù)集成：

1）界面集成。遵循統(tǒng)一的界面集成規(guī)范開(kāi)發(fā)集成前臺(tái)終端軟件，通過(guò)統(tǒng)一的界面集成框架和通用控件庫(kù)，確保各系統(tǒng)的用戶界面風(fēng)格和操作方式的一致性。

2）服務(wù)集成。新研和已有應(yīng)用服務(wù)資源通過(guò)統(tǒng)一的服務(wù)目錄，完成跨平臺(tái)服務(wù)調(diào)用和數(shù)據(jù)訪問(wèn)，實(shí)現(xiàn)服務(wù)集成。

3）數(shù)據(jù)集成。通過(guò)統(tǒng)一的數(shù)據(jù)主題服務(wù)目錄提供跨平臺(tái)的數(shù)據(jù)資源訪問(wèn)服務(wù)集成。

圖2 開(kāi)發(fā)方式

三、敏捷需求工程

（一）需求工程

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

圖3 需求工程

由于本項(xiàng)目系統(tǒng)復(fù)雜，規(guī)模比較大，用戶比較多，需求來(lái)源多，因此著重進(jìn)行了需求開(kāi)發(fā)和需求的有效管理。為了規(guī)范系統(tǒng)需求的提出、分發(fā)、變更及維護(hù)管理，控制需求變化引起的開(kāi)發(fā)、測(cè)試與需求不一致的情況，確保用戶提出的需求理解準(zhǔn)確，在系統(tǒng)中得到充分實(shí)現(xiàn)，成立了需求管理組織機(jī)構(gòu)，建立需求管理規(guī)定，指定專人，常態(tài)化開(kāi)展需求對(duì)接及管理工作，收集用戶需求，每半個(gè)月開(kāi)展一輪“需求理解—對(duì)接—分析—確認(rèn)”工作，保障系統(tǒng)開(kāi)發(fā)、測(cè)試、上線及運(yùn)行管理等工作的順利進(jìn)行。

（二）角色與職責(zé)

1.用戶單位為系統(tǒng)主要使用單位，履行下列職責(zé)：

(1)負(fù)責(zé)提出系統(tǒng)用戶需求，提出對(duì)系統(tǒng)的功能、性能、設(shè)計(jì)約束和其他方面的期望和要求等；

(2)負(fù)責(zé)解釋項(xiàng)目開(kāi)發(fā)過(guò)程中遇到的本單位的系統(tǒng)需求問(wèn)題；

(3)負(fù)責(zé)對(duì)本單位最終用戶需求實(shí)現(xiàn)情況進(jìn)行結(jié)果驗(yàn)證；

(4)負(fù)責(zé)確認(rèn)需求結(jié)果，參與項(xiàng)目驗(yàn)收等。

2.總體單位為系統(tǒng)論證、建設(shè)及使用單位，履行下列職責(zé)：

(1)負(fù)責(zé)需求管理的整體協(xié)調(diào)工作，包括需求管理流程的審批等；

(2)負(fù)責(zé)提出系統(tǒng)需求，提出對(duì)系統(tǒng)的功能、性能、設(shè)計(jì)約束和其他方面的期望和要求等；

(3)負(fù)責(zé)系統(tǒng)需求變更分析、需求優(yōu)先級(jí)評(píng)估等工作；

(4)負(fù)責(zé)需求申請(qǐng)和變更審批，對(duì)需求進(jìn)行管理和追蹤；

(5)負(fù)責(zé)對(duì)需求實(shí)現(xiàn)進(jìn)行結(jié)果驗(yàn)證，確認(rèn)需求結(jié)果并進(jìn)行項(xiàng)目驗(yàn)收；

(6)負(fù)責(zé)維護(hù)需求信息、跟進(jìn)需求變更以及需求處理進(jìn)展，定期向相關(guān)領(lǐng)導(dǎo)報(bào)告需求進(jìn)展。

3.研制單位負(fù)責(zé)實(shí)現(xiàn)系統(tǒng)各種需求，履行下列職責(zé)：

(1)負(fù)責(zé)需求開(kāi)發(fā)過(guò)程相關(guān)工作，處理需求開(kāi)發(fā)、實(shí)現(xiàn)、測(cè)試和系統(tǒng)上線運(yùn)行工作；

(2)負(fù)責(zé)對(duì)用戶提出的需求進(jìn)行系統(tǒng)的功能、性能、設(shè)計(jì)約束和其他方面的需求分析；

(3)負(fù)責(zé)編寫軟件需求文檔及需求列表等，實(shí)現(xiàn)需求人員與開(kāi)發(fā)人員的有效交互；

(4)負(fù)責(zé)根據(jù)需求評(píng)審和評(píng)估意見(jiàn)，及時(shí)修改和調(diào)整需求內(nèi)容；

(5)負(fù)責(zé)本單位從研制合同開(kāi)始到項(xiàng)目驗(yàn)收的需求管理與追蹤；

(6)負(fù)責(zé)提出系統(tǒng)開(kāi)發(fā)、性能優(yōu)化、軟件升級(jí)等需求。

（三）需求開(kāi)發(fā)

需求開(kāi)發(fā)（獲?。┲饕谦@得系統(tǒng)目標(biāo)需求和引出用戶使用需求，由于本項(xiàng)目用戶較多且分散，因此將其分為主動(dòng)獲取和主動(dòng)提交。主動(dòng)獲取指總體單位和研制方通過(guò)需求調(diào)研表、需求文檔、研討會(huì)等形式主動(dòng)獲取用戶需求。主動(dòng)提交指用戶或用戶代表在原型系統(tǒng)使用過(guò)程中記錄使用需求，形成用戶需求文檔（需求匯編），通過(guò)需求申請(qǐng)表和需求匯編報(bào)告等形式主動(dòng)向總體單位和研制方提交用戶需求。需求申請(qǐng)表如表1所示：

表1 需求申請(qǐng)表

本項(xiàng)目當(dāng)系統(tǒng)初步完成原型版開(kāi)發(fā)提交用戶使用后，用戶根據(jù)使用過(guò)程中的問(wèn)題和使用需求，形成用戶需求匯編。例如某典型單位多個(gè)崗位的用戶提出上下冊(cè)200多頁(yè)的需求匯編，其中涵蓋系統(tǒng)所有子系統(tǒng)。

（四）需求理解與分析

在獲得用戶需求后，需將其轉(zhuǎn)化為產(chǎn)品需求，并對(duì)產(chǎn)品需求進(jìn)行分解，描述產(chǎn)品的功能、性能、設(shè)計(jì)特征、驗(yàn)證要求等。研發(fā)項(xiàng)目組在拿到來(lái)源于用戶單位的需求匯編（上/下冊(cè)）和需求申請(qǐng)表，梳理待明確或待細(xì)化問(wèn)題，初步形成需求分析報(bào)告，進(jìn)一步與用戶對(duì)接溝通，理解需求。

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

表2 需求分析表

（五）需求確認(rèn)

需求確認(rèn)按照需求分析評(píng)審和軟件成果確認(rèn)兩種方式組織實(shí)施。

1.需求評(píng)審

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

2.軟件確認(rèn)

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

（六）需求管理

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

表3 需求追蹤表

四、敏捷與GJB5000的融合

GJB5000標(biāo)準(zhǔn)是軍用軟件研制能力成熟度模型，GJB5000A是以CMMI1.2版本為基礎(chǔ)制定的適用于軟件開(kāi)發(fā)全過(guò)程的通用標(biāo)準(zhǔn)，關(guān)注標(biāo)準(zhǔn)化的研制過(guò)程和規(guī)范化的文檔，對(duì)軟件工程過(guò)程進(jìn)行管理，保證按時(shí)交付高質(zhì)量的軟件產(chǎn)品。在實(shí)施過(guò)程中，特別是在5000A評(píng)價(jià)的早期，多采用嚴(yán)流程、重文檔的瀑布生存周期模型，但這與輕量級(jí)、輕文檔的敏捷開(kāi)發(fā)并不矛盾，在本質(zhì)上都是為了提高產(chǎn)品質(zhì)量、保證研制進(jìn)度[21-23]。GJB5000A規(guī)定了管理、工程和支持實(shí)踐域，未規(guī)定如何實(shí)施，鼓勵(lì)依據(jù)標(biāo)準(zhǔn)因地制宜，建立本地化軟件過(guò)程管理體系，可以根據(jù)項(xiàng)目特點(diǎn)進(jìn)行適當(dāng)?shù)募舨?。GJB5000A在向5000B改版時(shí)，特別強(qiáng)調(diào)了對(duì)于敏捷方法的適用，并在某研制企業(yè)進(jìn)行了試點(diǎn)，分析了其覆蓋的實(shí)踐域。

在基于敏捷研制過(guò)程中，需求開(kāi)發(fā)和管理、配置管理都占有很高的地位，計(jì)劃會(huì)議、每日站會(huì)、評(píng)審會(huì)議和回顧會(huì)議等都是在進(jìn)行項(xiàng)目策劃和管理，從傳統(tǒng)的WBS轉(zhuǎn)為基于需求特性進(jìn)行項(xiàng)目管理。產(chǎn)品任務(wù)列表、需求匯編報(bào)告、紀(jì)要、每個(gè)迭代版本的設(shè)計(jì)、測(cè)試大綱、報(bào)告等都是文檔類產(chǎn)品，特別是在本項(xiàng)目研制過(guò)程中，在任務(wù)版和正式版交付時(shí)，都要求整理過(guò)程記錄和文檔，形式規(guī)范化的項(xiàng)目文檔。而敏捷工具的使用，自動(dòng)化的記錄和分析了項(xiàng)目研制過(guò)程中的數(shù)據(jù)，供質(zhì)量保證和測(cè)量與分析使用。敏捷開(kāi)發(fā)的特點(diǎn)就是需求不明確，因此會(huì)引入變化和風(fēng)險(xiǎn)，在每個(gè)迭代周期，都在不斷的識(shí)別風(fēng)險(xiǎn)并跟蹤，有效進(jìn)行風(fēng)險(xiǎn)的緩解。

五、結(jié)論

敏捷開(kāi)發(fā)方法的應(yīng)用解決了傳統(tǒng)瀑布模型對(duì)于需求不確定反復(fù)迭代的大型軟件項(xiàng)目不適用的問(wèn)題，極大的降低了項(xiàng)目的風(fēng)險(xiǎn)，保證了項(xiàng)目的進(jìn)度，在早期就能得到用戶對(duì)系統(tǒng)的反饋，并在初始迭代中實(shí)現(xiàn)，項(xiàng)目質(zhì)量也得到了保證。但敏捷開(kāi)發(fā)對(duì)用戶的參與度要求比較高，可以說(shuō)用戶已經(jīng)成為了研發(fā)團(tuán)隊(duì)的一員，人與人之間的溝通十分重要，因此構(gòu)建合理流暢的工作流程、分散與集中的工作環(huán)境、團(tuán)隊(duì)的有效合作特別重要。