蘇 娟，張利娜，康 冰，李仁洙，衛(wèi) 瑞，趙慧莉，宮佳鵬

（航天科技集團北京航天發(fā)射技術(shù)研究所，北京 100086）

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

蘇 娟，張利娜，康 冰，李仁洙，衛(wèi) 瑞，趙慧莉，宮佳鵬

（航天科技集團北京航天發(fā)射技術(shù)研究所，北京 100086）

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

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

0　引 言

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

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

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

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

圖1　GJB 5000A需求管理模型

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

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

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

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

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

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

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

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

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

2　軟件需求管理平臺建設(shè)

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

圖2　XXX軟件需求追蹤關(guān)系

3　結(jié) 語

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

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

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

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

第四，在進行軟件項目策劃及需求定義時應(yīng)充分考慮對軟件重用構(gòu)件庫的建設(shè)，即對同一類軟件的需求開發(fā)應(yīng)本著重用的原則，具體體現(xiàn)在需求、接口、界面的重用需求定義，避免同類軟件對同一功能模塊進行的反復(fù)定義—開發(fā)—驗證。

10.3969/j.issn.1673 - 0194.2015.18.122

TP311

A

1673-0194（2015）18-0167-02

2015-07-27