基于GJB 5000A的軍用型號軟件需求管理研究

蘇 娟，張利娜，康 冰，李仁洙，衛 瑞，趙慧莉，宮佳鵬

（航天科技集團北京航天發射技術研究所，北京 100086）

基于GJB 5000A的軍用型號軟件需求管理研究

蘇 娟，張利娜，康 冰，李仁洙，衛 瑞，趙慧莉，宮佳鵬

（航天科技集團北京航天發射技術研究所，北京 100086）

針對本單位軍用型號軟件數量多、進度緊、開發平臺不統一以及軟件開發人員能力呈梯度模式分布的實際情況，基于GJB 5000A《軍用軟件成熟度模型》，研究適用于本單位的軟件需求管理過程，提高人員執行效率，確保型號軟件質量，促進組織級過程積累，提高本單位軟件工程化研制能力。

軍用型號軟件；GJB 5000A；需求；管理；軟件工程化

0　引 言

隨著國際關系局勢日益嚴峻，近年來，軍用型號軟件項目數量劇增，且功能不斷擴充，但軍用軟件運行的高可靠性、安全性仍是保證部隊作戰的首要戰略指標。在軟件研發團隊人員及水平相對固定的情況下，按照以往過多依賴于個人能力和“游擊隊”式的開發模式，不但不能滿足型號軟件工程化管理要求，并且為軟件后期運行維護帶來了極大隱患，故需要對軟件研制過程各項活動進行分析及把關，提高交付軟件質量，保證交付進度。通過梳理，近年來軍用型號研制過程中出現的質量問題，主要原因有如下幾方面：第一，部分軟件后期由于與相關系統的接口需求分析不明確造成軟件運行錯誤；第二，開發方過度承諾，后期需求變更無法控制且版本混亂；第三，大多數系統和軟件項目的投入，有一半以上純屬浪費；第四，用戶提供給開發方的需求清單不能反映真實需求；第五，系統測試階段發現的錯誤，80%是由不正確的需求或遺漏的需求造成的；第六，項目主管對需求分析和定義的基本原理和重要性缺乏認識，忽視對需求的投入；第七，缺乏有效的需求分析工具支持需求分析和需求管理。

與傳統的、有形的、可描述清晰的以及可具體檢測的硬件生產制造需求相比，軟件需求具有模糊性、變化性和主觀性的特點。正因為軟件需求的這些特點，對于一個軟件項目的開發來講，最困難的部分就是準確說明軟件需求，在用戶和開發團隊之間建立對需求的共同理解，維護需求與各階段工作產品達到一致性，并控制需求的變更。由此可見，軟件需求分析及實現作為項目研制最重要的一個組成部分，對其過程管理的好壞很大程度上決定了軟件開發的成敗。

1　基于GJB 5000A建立本地化的需求管理模型

通過多年探索和研究發現，在運用GJB 9001B實現對軟件研制各階段產品進行有效考核的基礎上，借助GIB 5000A可幫助軍工單位加強軟件研制過程管控，滿足軟件工程化要求，確保軟件研發進度及質量。GJB 5000A-2008《軍用軟件研制能力成熟度模型》是參照《軟件能力成熟度模型》（CMMI）1.2版制定的。其目的是幫助軍用軟件研發組織對軟件研制過程進行管理和改進，增強開發與改進能力，它為改進一個組織的軟件開發過程提供了單一的集成化框架，二級分為7個過程域，各域繼相互獨立又相輔相成。其中需求管理是一個單獨的過程域，主要由5個專用實踐來描述。這5個專用實踐圍繞著“管理需求”這個專用目標開展，如圖1所示是基于GJB 5000A的需求管理模型。

圖1　GJB 5000A需求管理模型

1.1軟件需求管理基本過程定制

根據我所型號軟件工程化大綱要求及軟件研制具體流程，對需求管理過程進行了本地化定制，其中，專用實踐SP1.1和SP1.2在實際執行過程中關聯性較強，且時間較集中，采用“需求的理解和承諾”活動來描述，重點細化明確了需求提供者準則，將型號項目組定位為用戶方，軟件研究室定位為開發方，系統總體及軟件生產人員定位為軟件部署和維護人員；考慮到以往軟件研制過程“重代碼輕文檔”的弊端，對系統需求的顆粒度劃分原則進行了定義，并將其細化入《軟件任務書評審要素表》及《軟件任務書檢查表》具體條目，為確保軟件需求的可追溯落到實處奠定了基礎。在訂制過程中，隨著對體系的理解不斷加深，也采用了使用替代實踐的方式簡化本地化執行步驟，如為了簡化需求承諾的流程使其具有可操作性，裁剪掉了軟件需求承諾單，用軟件評審結論報告簽署頁及軟件任務書審簽流程替代；將需求管理計劃并入軟件項目開發計劃，確保需求管理過程策劃與項目開發主計劃的一致性。

SP1.4和SP1.5所關注的內容，貫穿軟件研制過程的各個階段，且存在前后依賴關系，執行時間點為階段工作完成時和需求發生變更時，故采取用“需求跟蹤”活動來描述，航天科技集團北京航天發射技術研究所（以下簡稱我所）軟件多為非獨立工作模式，主要運行于整個CAN總線通信網絡或以太網通信網絡中，與其他軟件有頻繁的數據交互，故在需求跟蹤實踐中，除了關注軟件本身的功能、性能在各級工作產品中完成情況，也強調與相關聯軟件的通信接口即橫向需求的追蹤，對于軟件需求輸入中非技術類條目的追蹤，在項目管理PMC過程域中通過項目例會及相關評審活動實現。對于需求追蹤的形式制定了需求正反向追蹤記錄表—需求跟蹤矩陣—項目問題追蹤表—項目問題報告及糾正單的統一化流程處理方式。并明確需求追蹤不一致性的發現渠道，除軟件項目組成員，還包括第三方測試人員、利益相關方、項目QA人員及同行專家。

由于SP1.3需求的變更對后續軟件質量、顧客滿意度、批產及運行維護過程都有很大影響，故對需求變更活動，進行了強化說明，并細分具體的操作步驟。通過軟件需求變更情景劃分定義了不同的軟件需求變更流程，對于研制過程中產生的變更，按照軟件更改申請單提交—型號指揮批準（SCCB組長）—軟件更改研制—軟件回歸測試—版本升級受控流程來實現，對于軟件外場參加大型試驗及運行維護時發生地變更，按照填寫軟件需求溝通備忘錄，填寫外場軟件狀態更改記錄單—例外放行情況確認—補錄技術偏離單、軟件更改申請單及更改單—入庫受控流程實現。

1.2適用于不同生存周期模型的需求管理過程

隨著軟件編程語言、運行環境的擴展，結合型號研制進度緊、用戶需求變更頻繁的特點，傳統的瀑布模型已經不能滿足目前多型號軟件并行開發的局面，通過梳理我所型號軟件研制特點，結合《QJA 30A （2013）航天型號軟件工程化要求》中定義的航天軟件研制類型，對新研軟件進行了分類，除傳統瀑布模型外，充分借鑒敏捷開發方法，結合航天企業文化特點，新增原型開發模型、迭代模型及增量模型，可單獨使用也可組合使用，并可在定義模型基礎上根據型號研制階段特點對模型進行衍生及細分，覆蓋各型號軟件研制任務，可根據軟件開發人員能力梯度及項目組成員組成選用不同的開發模型。

對于迭代模型及原型開發模型中迭代階段的需求開發及實現，采用需求溝通備忘錄及需求正反向追蹤表確保需求的可追蹤性，弱化需求變更的流程控制，迭代過程中軟件版本入開發庫管理，當迭代階段完成后，回歸瀑布模型研制模式，嚴格遵守軟件需求變更流程，必要時需形成軟件更改影響域分析報告，并通過會議評審，確保需求更改的可行性。

1.3軟件需求過程管理過程與其他過程域的集成

基于GJB 5000A的軟件工程化建設是一個各個過程域相互影響、共同促進的過程，軟件需求管理過程的不斷推進也離不開相關過程域的支持。主要有：需求變更對項目策劃過程的影響，將需求的變更轉化為進度偏差，根據進度偏差超閾值的多少來進行合適的計劃變更；需求變更需要依賴測量與分析過程統計相關數據，方便項目研制過程中項目負責人宏觀把握需求狀態的情況，也為組織級生存周期模型選型指南及決策支持提供了保證；配置管理過程為需求承諾及變更輸入的有效性提供了支持，確保了軟件需求追蹤及變更活動不是無源之水。

2　軟件需求管理平臺建設

由于軟件規模龐大造成的需求顆粒較多，對需求追蹤及變更的有效性帶來了實際執行困難，采用以往的Excel表格填寫方式，不但嚴重耗費一線技術人員的時間和精力，而且不能保證追蹤的有效性，久而久之，需求管理的執行有效性下降，以往項目運行的各種弊端重新凸顯。我所與相關單位合作，嘗試研發訂制了軟件需求管理工具，經試用，對提高人員效率，確保需求管理執行落到實處起到了促進作用。如：采用需求影響域分析，自動對變更工作產品的需求追蹤關系進行分析，對于未變更的需求項，工具自動繼承與上級工作產品的追蹤關系，對于變更的功能項，用紅色在需求跟蹤矩陣中標注出來，需求管理人員只需根據紅色標注索引即可對更改需求項的追蹤關系重新定義，即可完成新一輪的需求追蹤活動，工具會自動生成新版本的需求跟蹤矩陣；針對表格化的需求跟蹤矩陣不直觀分析困難的特點，采取需求追蹤關系圖的表現形式，一列代表一個階段的工作產品，列與列之間通過連線表現相關工作產品的追蹤關系，當需求發生變更時，需求管理人員只需直接拖動并改變連線即可實現對追蹤關系的重新定義。當發生需求追蹤不一致情況時，只需根據本階段需求實現要素與之前各階段工作產品的需求項關聯情況，逐級檢查出中間環節未追蹤上或未實現的需求條目。效果如圖2所示。

圖2　XXX軟件需求追蹤關系

3　結 語

通過為期1年的GJB 5000A二級全面運行，我所型號軟件工程化水平有了顯著提高，并實現了各型號軟件均能夠按期交付，靶場無低層次質量問題出現，EPG組對本地化流程及管理模式也有了更深層次的理解。在現有本地化需求管理過程的基礎上，深化體系的本地化訂制，使其與本單位實際情況更加貼合，促進執行力度。

第一，簡化需求正反向追蹤記錄表，在各階段軟件設計文件中體現，無需再生成表單，簡化設計人員的工作量，避免了多處產生同一張表帶來內容不一致的隱患；

第二，對不同生存周期模型的需求管理活動的測量項進行梳理和定義，對于采用敏捷方法開發的軟件弱化對需求變更情況的統計，加強對軟件質量問題及研制進度的測量與分析；

第三，區分使用不同編程語言實現的軟件需求跟蹤力度，對于非代碼行實現的軟件可根據項目實際情況只追蹤至模塊和線程；

第四，在進行軟件項目策劃及需求定義時應充分考慮對軟件重用構件庫的建設，即對同一類軟件的需求開發應本著重用的原則，具體體現在需求、接口、界面的重用需求定義，避免同類軟件對同一功能模塊進行的反復定義—開發—驗證。

10.3969/j.issn.1673 - 0194.2015.18.122

TP311

A

1673-0194（2015）18-0167-02

2015-07-27