摘要:我國開展軟體工程化推進多年，但效果並不是很理想。筆者結合軟體工程化推進的現狀，根據多年軍品軟體研發和軟體工程化推進的實踐經驗，提出了推進軟體工程化的一些方式和方法，以期能在推進軟體工程化尤其是在提高軟體產品質量方面起到應有的效果。
關鍵詞:GJB5000；軟體工程化；軟體能力成熟度；CMM；CMMI
引言
當今社會的發展越來越離不開軟體的支撐，許多已開發國家已將軟體視為「國家間競爭的重要武器」，把對軟體技術的研究和軟體產業的發展作為國家競相扶持的重點。如何提升軟體的技術能力，加強對軟體開發過程的管理，已經成為軟體行業主要關注的方向。在裝備研製和使用保障過程中，質量是關係官兵生命，關係戰爭勝負的重大問題。為確保我國軍品軟體產品質量，總裝備部於2003開始引入由美國卡耐基﹒梅隆大學軟體工程研究所（CMU/SEI）提出的CMM/CMMI。在進行深入研究CMM的基礎上，於2003年了基於CMM的GJB5000-2003《軍用軟體能力成熟度模型》[1]。經過多年的試點和探索，2008年了基於CMMI-DEV1.2[2]的GJB5000A-2008《軍用軟體研製能力成熟度模型》[3]。規範了為達到研製高質量的軍用軟體的目標，劃分了軟體研發能力等級以及各等級的典型特徵和能力水平，並給出了如何持續改進能力等級的具體指導[4]。但在將近二十年的推進過程中，推進效果並不是很理想。
1軟體工程化推進現狀
1.1缺乏系統和專業的軟體工程化建設指導
按照GJB8000-2013《軍用軟體研製能力等級要求》[5]，大多數軍品軟體承研單位需要滿足GJB5000A三級研製能力等級要求。GJB5000A三級需覆蓋17個過程域39個目標132個特定實踐，內容涵蓋了軟體工程和軟體過程管理的內容[3]。原來開展軟體研製，軟體設計師主要依據GJB2786A-2009《軍用軟體開發通用要求》和GJB438B-2009《軍用軟體開發文檔通用要求》這兩份標準，主要開展軟體工程相關的活動即可。GJB5000對軟體研製全生命周期的方方面面應開展哪些活動都進行了說明[5]。很多承研單位都面臨如何在軟體研發過程中開展項目策劃、項目監控、風險管理、供方管理等方面的工作的困惑。參照美國軟體工程研究所（SEI)提出的SCAMPI評估方式[6]考評單位是否滿足GJB5000的目標，在如何開展、如何推進方面沒有給出一定的指導。各單位的最佳實踐也沒有形成軍品承研單位共同的資產，每個單位在軟體過程體系建設和軟體工程推進中都是在重複不斷摸索。
1.2軟體研發過程與軟體工程化要求的衝突
隨著信息技術的發展，應用於新領域系統的軍品軟體越來越多，系統需求不明確是經常存在的情況。在系統需求不明確的情況下，軟體需求也無法明確和清晰。在軟體研製進度緊張、技術難度高和人力資源緊張時，為了減少不必要的軟體研發投入，往往先開展軟體代碼的編寫、調試和系統聯試，在反覆疊代確認軟體需求後，才根據軟體代碼開展軟體需求和設計的編寫。造成軟體工程化的需求分析、需求管理等活動證據缺乏，規範的工作分解結構（WorkBreakdownStructure）任務策劃與實際開展的軟體工程活動衝突（如正常應該是先需求分析、再設計、後編碼，而實際是先編碼，後補充需求分析和設計的證據）。造成軟體工程化實施無法給出合理的證據。
1.3軟體工程師技能與工程化要求的不匹配
GJB5000A對項目的軟體工程化的開發和管理都提出了很高要求，軟體設計師是順利開展軟體工程化的關鍵角色。軟體設計師由原來只需熟悉GJB438B-2009《軍用軟體開發文檔通用要求》和GJB2786A-2009《軍用軟體開發通用要求》，還需熟悉項目管理的相關內容（如項目策劃、項目監控、風險管理、資源管理等）。由原來的只需開展軟體工程活動，到軟體工程活動和軟體過程活動都得理解和開展。從開發過程中對需求、設計及實現的具體活動定義，到項目管理、跟蹤報告的周期機制，事無巨細[7]。軟體設計師的技能與工程化的要求存在的不小的差距。
2推進軟體工程化的方式方法
戴明（W.E.Deming）和朱蘭（J.Juran）指出一個系統的質量主要取決於用來開發和維護該系統的過程的質量。而GJB5000就是通過規範軟體研發過程的活動，避免軟體過程無規則和混亂的管理，來確保軟體產品的質量。GJB5000給出了系統的開展軟體過程活動的具體要求和實施的具體指導[4]。結合具體軟體過程工程化的開展方面，筆者認為可以採取一些好的方式方法。
2.1構建面向全組織的軟體工程過程組織架構
承研單位和軟體設計師對開展軟體工程化的第一反應是抗拒，這是目前普遍存在的現象。軟體工程化要求多、內容複雜。軟體工程化評價專家對GJB5000有各自不同的理解。造成承研單位對具體如何開展、如何實施無所適從。各單位在推進過程中，除了軟體工程化的交流資料外，可借鑑和參考的資料有限。再加上軟體工程化推進短期內無法看到效果，軟體工程師普遍認為軟體工程化推進沒必要和無意義。為降低各單位推進軟體工程化的難度，降低軟體工程師對推進軟體工程化的牴觸心裡，提高開展軟體工程化推進的積極性，應構建全組織的軟體工程過程組織架構。為軍品承研單位的互相學習、相互借鑑，最佳實踐在軟體工程化推進中的推廣搭建平台。搭建的平台如圖1所示。軍品裝備發展部SEPG管理全組織的軟體工程化專家、評價專家，可有效的收集到各承製公司和承製單位的最佳實踐。在對其進行梳理和整理後，可構建全組織的軟體工程化組織資產，為各承製公司提供知識共享。承製公司SEPG負責本公司內的最佳實踐收集、資源共享，負責本公司內的最佳實踐的收集和推廣。該組織可確保最佳實踐在全組織內的有效利用，減少不必要的軟體工程化建設的重複工作，提高軟體工程化推進的效率，消除各承製單位的孤島狀態。
2.2軟體工程過程要求為導向的求同存異推進
能否直接或間接的提高軟體產品質量是檢驗軟體工程過程活動必要性和有效性的標準。我國在引進CMM/CMMI時，根據軍品軟體研製的特點進行了本地化的修訂，但在推進的過程中還是存在了一些問題。如評價時以GJB5000A的資料性部件為標準，不滿足就是不合格，造成軟體工程師對軟體工程化推進的牴觸心裡。國外的一些標杆企業，如波音、柯林斯、洛克希德馬丁等也達到了三級以上的成熟度等級，但並不是完全照搬CMMI，其中有一些公司是採用了公司自己的管理機制（為類三級）。這說明在國外的軟體工程化推進過程中，其主要目標是滿足軟體工程化的要求即可，沒對採取的形式進行限制。我國軍品軟體研製單位各有各的實際情況，各有各的特點，完全按照同一個模式開展推進是不可能也是不現實的。應允許單位根據各自的特點開展推進。
2.3緊密結合軍品軟體研製特點制定推進方式
我國裝備軟體發展的過程中，存在一些自身的特點。武器裝備的研發模式而影響的軍品軟體的開發模式，如軟體研發普遍存在的時間緊（軟體作為武器裝備研發的後端）、需求變動大（改軟體比硬體方便，成本低）、軟體研發不受重視（軟體基本不計價）等。遵循軟體工程過程的要求開展，存在一定的難度。如目前普遍存在的逆向工程問題，是沒法迴避的現實問題。如果生搬硬套，既違背了GJB5000推進的初衷，又增加了不必要的工作量。針對這種普遍存在的共性問題，應組織全組織的軟體工程過程組織進行專題討論，在確保軟體產品質量的前提下，討論具體推進的方式和方法，並作為全組織的最佳實踐進行推廣。從而減少各單位對這種共性問題如何推進的不必要的和重複的摸索、討論、試點和解釋。
2.4軟體工程師針對性的技能培訓
GJB5000A的推進從二級開始。GJB5000A二級包含7個過程域（配置管理、測量與分析、項目監控、項目策劃、過程和產品質量保證、需求管理、供方協議管理），除需求管理外都屬於支持類和項目管理類的過程域。7個過程域基本上是軟體工程師在研發過程中不太關注的內容，對軟體工程師開展所有的培訓成本高，效果也不會太理想。應對軟體項目中的軟體負責人開展這方面的培訓，軟體負責人在進行具體的推進過程中，結合具體的工作內容有針對性的對軟體工程師進行指導即可。確保軟體項目中有軟體過程的明白人。
3結束語
軟體工程化推進是一個複雜的系統工程，需要在具體實踐中不斷的探索、研究新的方式和方法，尋求更為合適的推進途徑。目前，軍用軟體開發和應用的範圍越來越廣，軍用軟體對武器裝備的質量起著至關重要的作用。在軟體工程化的推進實踐中，在執行國家軍用標準的同時，探索合適的軟體工程化推進模式，從而提升軍用軟體的產品質量。
參考文獻
[3]GJB5000A-2008軍用軟體研製能力成熟度模型.
[4]石柱,軍用軟體研製能力成熟度模型及其應用[M].北京:中國標準出版社,2009.
[5]GJB8000-2013軍用軟體研製能力等級要求.
[6]過程改進用的標準CMMI評估方法(SCAMPI)實施指南(QRMS-41).王方德,譯.總裝備部電子信息基礎部技術基礎局,2005.
[7]任甲林.術以載道——軟體過程改進實踐指南[M].北京:人民郵電出版社,2014.
[8]石柱.軟體質量管理[M].北京:航空工業出版社,2003
[9]鄧成飛,李潔.軟體工程管理.北京:國防工業出版社,2000.
[10]張萬軍,鄭寧,趙宇蘭.基於CMMI的軟體工程及實訓指導.清華大學出版社2011.
[11]任甲林.術以載道——軟體過程改進實踐指南人民郵電出版社2014.
作者：程春姬 單位：中國航空無線電電子研究所
關鍵詞:GJB5000；軟體工程化；軟體能力成熟度；CMM；CMMI
引言
當今社會的發展越來越離不開軟體的支撐，許多已開發國家已將軟體視為「國家間競爭的重要武器」，把對軟體技術的研究和軟體產業的發展作為國家競相扶持的重點。如何提升軟體的技術能力，加強對軟體開發過程的管理，已經成為軟體行業主要關注的方向。在裝備研製和使用保障過程中，質量是關係官兵生命，關係戰爭勝負的重大問題。為確保我國軍品軟體產品質量，總裝備部於2003開始引入由美國卡耐基﹒梅隆大學軟體工程研究所（CMU/SEI）提出的CMM/CMMI。在進行深入研究CMM的基礎上，於2003年了基於CMM的GJB5000-2003《軍用軟體能力成熟度模型》[1]。經過多年的試點和探索，2008年了基於CMMI-DEV1.2[2]的GJB5000A-2008《軍用軟體研製能力成熟度模型》[3]。規範了為達到研製高質量的軍用軟體的目標，劃分了軟體研發能力等級以及各等級的典型特徵和能力水平，並給出了如何持續改進能力等級的具體指導[4]。但在將近二十年的推進過程中，推進效果並不是很理想。
1軟體工程化推進現狀
1.1缺乏系統和專業的軟體工程化建設指導
按照GJB8000-2013《軍用軟體研製能力等級要求》[5]，大多數軍品軟體承研單位需要滿足GJB5000A三級研製能力等級要求。GJB5000A三級需覆蓋17個過程域39個目標132個特定實踐，內容涵蓋了軟體工程和軟體過程管理的內容[3]。原來開展軟體研製，軟體設計師主要依據GJB2786A-2009《軍用軟體開發通用要求》和GJB438B-2009《軍用軟體開發文檔通用要求》這兩份標準，主要開展軟體工程相關的活動即可。GJB5000對軟體研製全生命周期的方方面面應開展哪些活動都進行了說明[5]。很多承研單位都面臨如何在軟體研發過程中開展項目策劃、項目監控、風險管理、供方管理等方面的工作的困惑。參照美國軟體工程研究所（SEI)提出的SCAMPI評估方式[6]考評單位是否滿足GJB5000的目標，在如何開展、如何推進方面沒有給出一定的指導。各單位的最佳實踐也沒有形成軍品承研單位共同的資產，每個單位在軟體過程體系建設和軟體工程推進中都是在重複不斷摸索。
1.2軟體研發過程與軟體工程化要求的衝突
隨著信息技術的發展，應用於新領域系統的軍品軟體越來越多，系統需求不明確是經常存在的情況。在系統需求不明確的情況下，軟體需求也無法明確和清晰。在軟體研製進度緊張、技術難度高和人力資源緊張時，為了減少不必要的軟體研發投入，往往先開展軟體代碼的編寫、調試和系統聯試，在反覆疊代確認軟體需求後，才根據軟體代碼開展軟體需求和設計的編寫。造成軟體工程化的需求分析、需求管理等活動證據缺乏，規範的工作分解結構（WorkBreakdownStructure）任務策劃與實際開展的軟體工程活動衝突（如正常應該是先需求分析、再設計、後編碼，而實際是先編碼，後補充需求分析和設計的證據）。造成軟體工程化實施無法給出合理的證據。
1.3軟體工程師技能與工程化要求的不匹配
GJB5000A對項目的軟體工程化的開發和管理都提出了很高要求，軟體設計師是順利開展軟體工程化的關鍵角色。軟體設計師由原來只需熟悉GJB438B-2009《軍用軟體開發文檔通用要求》和GJB2786A-2009《軍用軟體開發通用要求》，還需熟悉項目管理的相關內容（如項目策劃、項目監控、風險管理、資源管理等）。由原來的只需開展軟體工程活動，到軟體工程活動和軟體過程活動都得理解和開展。從開發過程中對需求、設計及實現的具體活動定義，到項目管理、跟蹤報告的周期機制，事無巨細[7]。軟體設計師的技能與工程化的要求存在的不小的差距。
2推進軟體工程化的方式方法
戴明（W.E.Deming）和朱蘭（J.Juran）指出一個系統的質量主要取決於用來開發和維護該系統的過程的質量。而GJB5000就是通過規範軟體研發過程的活動，避免軟體過程無規則和混亂的管理，來確保軟體產品的質量。GJB5000給出了系統的開展軟體過程活動的具體要求和實施的具體指導[4]。結合具體軟體過程工程化的開展方面，筆者認為可以採取一些好的方式方法。
2.1構建面向全組織的軟體工程過程組織架構
承研單位和軟體設計師對開展軟體工程化的第一反應是抗拒，這是目前普遍存在的現象。軟體工程化要求多、內容複雜。軟體工程化評價專家對GJB5000有各自不同的理解。造成承研單位對具體如何開展、如何實施無所適從。各單位在推進過程中，除了軟體工程化的交流資料外，可借鑑和參考的資料有限。再加上軟體工程化推進短期內無法看到效果，軟體工程師普遍認為軟體工程化推進沒必要和無意義。為降低各單位推進軟體工程化的難度，降低軟體工程師對推進軟體工程化的牴觸心裡，提高開展軟體工程化推進的積極性，應構建全組織的軟體工程過程組織架構。為軍品承研單位的互相學習、相互借鑑，最佳實踐在軟體工程化推進中的推廣搭建平台。搭建的平台如圖1所示。軍品裝備發展部SEPG管理全組織的軟體工程化專家、評價專家，可有效的收集到各承製公司和承製單位的最佳實踐。在對其進行梳理和整理後，可構建全組織的軟體工程化組織資產，為各承製公司提供知識共享。承製公司SEPG負責本公司內的最佳實踐收集、資源共享，負責本公司內的最佳實踐的收集和推廣。該組織可確保最佳實踐在全組織內的有效利用，減少不必要的軟體工程化建設的重複工作，提高軟體工程化推進的效率，消除各承製單位的孤島狀態。
2.2軟體工程過程要求為導向的求同存異推進
能否直接或間接的提高軟體產品質量是檢驗軟體工程過程活動必要性和有效性的標準。我國在引進CMM/CMMI時，根據軍品軟體研製的特點進行了本地化的修訂，但在推進的過程中還是存在了一些問題。如評價時以GJB5000A的資料性部件為標準，不滿足就是不合格，造成軟體工程師對軟體工程化推進的牴觸心裡。國外的一些標杆企業，如波音、柯林斯、洛克希德馬丁等也達到了三級以上的成熟度等級，但並不是完全照搬CMMI，其中有一些公司是採用了公司自己的管理機制（為類三級）。這說明在國外的軟體工程化推進過程中，其主要目標是滿足軟體工程化的要求即可，沒對採取的形式進行限制。我國軍品軟體研製單位各有各的實際情況，各有各的特點，完全按照同一個模式開展推進是不可能也是不現實的。應允許單位根據各自的特點開展推進。
2.3緊密結合軍品軟體研製特點制定推進方式
我國裝備軟體發展的過程中，存在一些自身的特點。武器裝備的研發模式而影響的軍品軟體的開發模式，如軟體研發普遍存在的時間緊（軟體作為武器裝備研發的後端）、需求變動大（改軟體比硬體方便，成本低）、軟體研發不受重視（軟體基本不計價）等。遵循軟體工程過程的要求開展，存在一定的難度。如目前普遍存在的逆向工程問題，是沒法迴避的現實問題。如果生搬硬套，既違背了GJB5000推進的初衷，又增加了不必要的工作量。針對這種普遍存在的共性問題，應組織全組織的軟體工程過程組織進行專題討論，在確保軟體產品質量的前提下，討論具體推進的方式和方法，並作為全組織的最佳實踐進行推廣。從而減少各單位對這種共性問題如何推進的不必要的和重複的摸索、討論、試點和解釋。
2.4軟體工程師針對性的技能培訓
GJB5000A的推進從二級開始。GJB5000A二級包含7個過程域（配置管理、測量與分析、項目監控、項目策劃、過程和產品質量保證、需求管理、供方協議管理），除需求管理外都屬於支持類和項目管理類的過程域。7個過程域基本上是軟體工程師在研發過程中不太關注的內容，對軟體工程師開展所有的培訓成本高，效果也不會太理想。應對軟體項目中的軟體負責人開展這方面的培訓，軟體負責人在進行具體的推進過程中，結合具體的工作內容有針對性的對軟體工程師進行指導即可。確保軟體項目中有軟體過程的明白人。
3結束語
軟體工程化推進是一個複雜的系統工程，需要在具體實踐中不斷的探索、研究新的方式和方法，尋求更為合適的推進途徑。目前，軍用軟體開發和應用的範圍越來越廣，軍用軟體對武器裝備的質量起著至關重要的作用。在軟體工程化的推進實踐中，在執行國家軍用標準的同時，探索合適的軟體工程化推進模式，從而提升軍用軟體的產品質量。
參考文獻
[3]GJB5000A-2008軍用軟體研製能力成熟度模型.
[4]石柱,軍用軟體研製能力成熟度模型及其應用[M].北京:中國標準出版社,2009.
[5]GJB8000-2013軍用軟體研製能力等級要求.
[6]過程改進用的標準CMMI評估方法(SCAMPI)實施指南(QRMS-41).王方德,譯.總裝備部電子信息基礎部技術基礎局,2005.
[7]任甲林.術以載道——軟體過程改進實踐指南[M].北京:人民郵電出版社,2014.
[8]石柱.軟體質量管理[M].北京:航空工業出版社,2003
[9]鄧成飛,李潔.軟體工程管理.北京:國防工業出版社,2000.
[10]張萬軍,鄭寧,趙宇蘭.基於CMMI的軟體工程及實訓指導.清華大學出版社2011.
[11]任甲林.術以載道——軟體過程改進實踐指南人民郵電出版社2014.
作者：程春姬 單位：中國航空無線電電子研究所
收藏