軟件能力成熟度模型在航天器軟件研制中的應用研究

（北京空間飛行器總體設計部，北京 100094）

1 引言

我國航天系統較早地開展了軟件工程化的研究和應用工作，原航天工業總公司在20世紀90年代中期發布了相關要求，將軟件納入航天器產品配套表，對軟件進行管理［1］，同時規定了對航天器軟件實施規范化的工程管理［2］。然而，隨著軟件復雜度和規模的不斷提高，傳統的軟件工程化方法在保證軟件質量和進度方面已顯得力不從心，新的理論和方法不斷地被研究和實踐。

本文首先介紹“軍用軟件能力成熟度模型”的基本內容。然后對當前我國在航天器軟件工程化推行中存在的問題進行分析，提出了將“軟件能力成熟度模型”思想和內容進行本地化，以解決軟件工程化推行中存在的問題，進而提升軟件研制能力的相關建議。

2 軟件能力成熟度模型簡介

20世紀80年代，美國國防部為了評估其軟件承包商的能力，委托卡內基—梅隆大學的軟件工程研究所（SEI）提出了一種“軟件能力成熟度模型”（CMM），1991年推出1.0版［3］，2000年升級為集成能力成熟度模型（CMM Integration，CMMI）。美國國防部要求軟件承研單位的CMMI等級達到三級以上，NASA 要求航天軟件的研制單位達到CMMI四級以上。2000年6月，我國國務院頒發了《鼓勵軟件產業和集成電路產業發展的若干政策》（18 號文件）［4］，鼓勵組織實施CMMI認證。針對國防領域，2003年發布了《GJB5000-2003軍用軟件研制能力成熟度模型》，2008年又發布了《GJB5000A-2008軍用軟件研制能力成熟度模型》（簡稱GJB5000A），內容來源于CMMI V1.2版，略有刪減［5］。

GJB5000A 中軟件能力成熟度模型將軟件研制能力成熟度分為5 個等級，分別是初始級、已管理級、已定義級、已定量管理級和優化級。每個成熟度等級由若干過程域組成，其中初始級不包含任何過程域；已管理級包含配置管理、測量與分析、項目監控、項目策劃、過程和產品質量保證、需求管理、供方協議管理等過程域；已定義級包含決策分析和決定、集成項目管理、組織過程定義、組織過程焦點、組織培訓、產品集成、需求開發、風險管理、技術解決方案、確認、驗證等過程域；已定量管理級包含組織過程績效、定量項目管理等過程域；優化級包含原因分析和決定、組織創新和部署等過程域。每個過程域由若干目標組成（包括各個過程域獨自的專用目標和所有過程域都包含的共用目標），每個目標又由若干實踐組成?！败娪密浖芰Τ墒於饶Ｐ汀睂Τ跏技壗M織的軟件研制過程無任何要求。軟件開發組織要達到除初始級之外的某個成熟度等級，除了需要實施該成熟度等級包含的過程域之外，還需實施比該成熟度等級低的所有等級所包含的過程域，當一個過程域包含的所有目標均被實現時，則認為該過程域已被實現。

筆者認為，軟件能力成熟度模型的核心思想主要體現在以下幾個方面：

（1）將軟件開發活動的整體視為一個過程，而不只是將軟件工程活動視為一個過程，即關注軟件開發活動各個方面的過程化，而不僅是工程活動的過程化；

（2）重視測量數據，包括軟件的規模、質量、進度等，強調用數據說話；

（3）重視組織資產的積累和應用，強調成果不歸個人所有，不做重復性開發；

（4）強調本地化的實踐。

3 當前航天器軟件研制中存在的不足

3.1 生存周期的本地化研究和實踐不足

2005年，航天科技集團公司發布了軟件工程化管理要求方面的標準，對航天器軟件生存周期及各階段的管理提出了要求，其中，在軟件生存周期的選擇上只規定了一種“瀑布模型”，如圖1所示。2013年，根據新的發展形勢在多個方面對原標準進行了修訂和完善，如在軟件生存周期上，按繼承性程度的不同提出了4類軟件研制流程，但依然是基于“瀑布模型”的裁剪，其中新研軟件仍采用完整“瀑布模型”。

圖1 航天器軟件研制“瀑布模型”技術流程Fig.1 Developing flow of spacecraft software

從圖1可看出，新研軟件的研制流程共分為10個階段，順序執行。但近年來，由于航天器整器研制周期縮短，而整器測試時間加長等原因，使得產品研制的時間大大壓縮。對于硬件而言，新研產品可以通過方案階段先期開展技術攻關，來解決研制周期不足問題；軟件產品卻很難做到，因為軟件的需求確定較晚，往往需要到初樣開始后的較長時間，而且越是技術狀態新的型號，軟件需求下達越晚。對于為整星各個分系統提供服務的軟件（如數據管理軟件），往往具有“三最”特點：需求下達最晚，軟件交付給航天器最早，（交付前）軟件研制周期最短。因此，往往前面的許多階段都還未完成，就直接進入航天器測試階段。在這種情況下，新研軟件很難按照圖1要求的流程開展研制活動，實際操作過程中不能按照既定的軟件研制技術流程進行的現象非常普遍，使得多個階段的工作難以落實，未發揮應有的作用。

3.2 軟件開發過程的數據測量和分析不足

首先是對軟件開發工作量和進度缺少可信的數據采集和分析。由于軟件具有修改便利、可不斷完善等特點，又由于系統聯試前留給軟件開發的時間不足等客觀原因，導致軟件在開發期間存在大量交付“半成品”的現象。同時相對于航天器研制主線而言，軟件產品的開發工作易被忽視，其進度也可根據需要伸縮，在此過程中軟件開發自身的工作量、進度往往沒有被客觀地記錄，而是跟著航天器系統設計進行，最初制訂的軟件開發計劃往往寫完后即束之高閣，無法指導實際的軟件開發。其次，對于各個階段出現的問題、故障（bug）、記錄和統計也很不全面，如開發方測試、分系統聯試中發現的大部分問題未被記錄，航天器整器測試中只分析、統計占一小部分的問題。

由于缺少對工作量、進度、質量等多方面數據的采集、統計、分析，使得某些深層次問題被掩蓋。例如當前航天器軟件開發遇到的一個重要問題是：軟件開發未完成即交付航天器，軟件質量的保證主要靠航天器整器測試。

充分的航天器整器測試是當前航天器軟件質量保證的“強項”。因為一方面，測試環境與真實環境的相似度更高，這對軟件問題的暴露非常有利；另一方面，當前航天器整器測試的周期變長，同時測試對軟件測試的項目也大量增加，與過去相比，航天器整器測試階段對軟件功能、性能的覆蓋率要高很多。

依靠航天器整器測試這個強項來確保航天器軟件的質量，雖然很有效，但也存在一些問題和隱憂。

1）不利于軟件規模的擴大

系統測試（如航天器整器測試）對于規模不大、邏輯不很復雜的軟件，是可以保證質量的，但是對于規模龐大、邏輯復雜的軟件，很可能無法保證測試的充分性，因為內部的一些邏輯可能測不到。目前的航天器軟件（嵌入式）的規模還不算大（例如很少有源代碼超過10萬行的），邏輯也不是十分復雜，隨著后續軟件功能的復雜化，這種過分依賴系統測試的做法是存在隱患的。

2）不利于效率的提升

資料顯示，美國軍用軟件的系統測試時間只占開發時間的4.8%［6］；ESA 的航天器整器測試時間也很短，主要測試接口，產品本身的質量由產品交付前的研制階段來保證，其航天器整器測試的成本是按小時計算的。相比而言，我國航天器軟件開發的時間一般為4～5個月，而航天器整器測試時間初樣一般1年以上，正樣一般8個月以上。

現有的做法對于軟件開發而言，效率不高。因為交付前留給軟件開發的時間不足，使得軟件無法按照最有效的開發方法進行，只能先解決最緊迫的編碼問題，其他工作產品后補；同時，由于航天器整器測試的時間非常長，在此過程中軟件更改的空間很大，很容易導致需求提出方在初期不進行充分考慮，提出不正確、不合理的需求，而在測試過程中頻繁修改，導致軟件的不斷返工。

3）不利于航天器研制流程優化

長時間的航天器整器測試，使得其研制周期較長，成為我國與國外航天器競標中的弱項。隨著市場化競爭，航天器研制周期和成本可能會進一步壓縮，研制過程逐步與國際接軌，航天器整器測試時間必然要縮短。但在現有的軟件研制模式下，由于軟件的質量過依賴于航天器電性能測試，一旦測試時間壓縮，對軟件質量會造成重大影響。

3.3 軟件復用的隨意性大

由于軟件復用缺少軟件開發組織的參與，如缺少組織級的軟件復用庫和使用指南、復用規程等，沒有指定人員對復用軟件模塊的質量、維護負責。航天器軟件的復用往往體現出與“人”相關、與“項目”相關。與“人”相關是指只有開發人員本人能夠復用其過去開發的模塊，其他人不會用；與“項目”相關是指只有在兩個非常相似的航天器間才會復用，而且多數情況下復用者是知其然不知所以然。這種隨意性給軟件復用的質量、效率都帶來了不利影響。

4 應用軟件能力成熟度模型解決當前問題的建議

針對前文中分析的當前航天器軟件工程化實施中存在的不足，結合對軟件能力成熟度模型的研究和應用，提出以下幾點解決措施。

1）開發本地化生存周期模型

軟件能力成熟度模型非常強調本地化，要求組織建立適合自己的可用的組織過程資產集和工作環境。例如對于生存周期模型，其明確提出“生存周期模型可以對各種顧客或各種情況開發，因為一個生存周期模型不可能適合所有情況”。針對當前新研軟件的特點，筆者開發了一種“原型瀑布模型”，以實現生存周期與實際軟件研制流程相符，并更好地保證交付前的軟件質量（如圖2所示）。

圖2 原型瀑布結合模型Fig.2 Model of integrated prototype with waterfall

該模型的特點是采用目標分解法，將軟件開發分成兩個階段：第一階段，采用原型法開發，以快速實現支持系統功能檢查的軟件功能，滿足航天器第一階段目標；第二階段，待原型完成交付且用戶需求基本明確后，再按照瀑布模型開展研制工作，經歷一個完整的開發過程，以確保軟件的功能完整、性能滿足要求、質量可靠，滿足航天器第二階段目標。

2）應用組織資產提升軟件復用能力

軟件能力成熟度模型里頻繁出現的一個詞是“組織資產”，要求在軟件的策劃、開發、測試中都要使用組織已有的資產，并將在新的開發過程中形成的代碼、文件、數據、經驗等納入組織資產。軟件能力成熟度模型要求被復用的資產得到管理，要保證享有權限的人員能夠很方便地獲取到組織資產；在具體項目中，使用了組織資產要留下記錄；項目開發完成后，要提煉出組織資產提交到組織資產庫。因此，軟件能力成熟度模型不是簡單地提出軟件要“復用”的要求，而是提出了很多具體的、操作性較強的軟件復用實施的方法和要求，并非常強調將其上升為組織行為，這對于提升航天器軟件的復用能力，減少重復開發，提高質量和效率，具有非常重要的現實意義。

3）利用數據采集和分析發現問題本質

要解決問題、提升能力，首先要發現問題和隱患，并了解導致問題的原因。按照軟件能力成熟度模型的思想，根據本單位特點對項目的進度偏離情況、發生的更改、存在的風險、資源到位情況等進行監控；同時對規模、進度、工作量、質量、變更等指標進行分解，設計多個能夠表征這些指標的測量項，確定采集時機、存儲方法、分析方法、采集人員、復核人員、分析人員等。對軟件開發中存在的深層次問題，以“數據”為判斷依據，減少憑經驗、憑印象等不科學方法使用的概率。

4）重視配套設施，促進軟件工程過程落實

軟件工程主要關注軟件工程過程，而對軟件工程的輔助、支持等方面的過程關注不夠，例如策劃、監控、測量分析、質量保證、組織培訓等，使得軟件工程過程經常由于“配套設施”跟不上，導致實施困難很大。軟件能力成熟度模型則更加關注軟件開發活動的整體，即如何對軟件開發活動的各個方面進行過程化，其中包括工程活動的過程化。實踐證明，通過對項目管理、支持、過程管理等工程以外的活動也充分重視，實施過程化的管理、監控等，是工程過程實施的有力保障和促進。

5 結束語

軟件能力成熟度模型提供了一整套提升軟件組織能力的知識體系和方法論，是在總結優秀軟件組織成功經驗的基礎上提煉出來的，但國外的成功經驗不一定適合，因此如何做好本地化，依舊是一個難題。針對航天器軟件當前存在的軟件生存周期與實際研制流程不符、產品質量對航天器整器測試過于依賴等問題，本文在軟件能力成熟度模型的框架下提出了4點建議，并已在一定范圍內開展了應用，取得了良好的效果。

（References）

［1］劉正高.航天型號軟件產品總體策劃［J］.質量與可靠性，2005（6）：29-31 Liu Zhenggao.Summarily plan of aerospace software［J］.Quality and Reliability，2005（6）：29-31（in Chinese）

［2］石柱.航天型號軟件工程化十年回顧與展望［J］.航天控制，2006（4）：66-72 Shi Zhu.Aerospace software engineering practice——the past ten years and the future［J］.Aerospace Control，2006（4）：66-72（in Chinese）

［3］謝超，馬士龍，林夢香.新一代的過程改進模型：CMMI［J］.計算機科學，2001（8）：81-84 Xie Chao，Ma Shilong，Lin Mengxiang.A process improvement mode of next generation：CMMI［J］.Computer Science，2001（8）：81-84（in Chinese）

［4］倪光南.發展嵌入式軟件對我國的重要性［J］.電子產品世界，2012（3）：11-14 Ni Guangnan.The importance of the development of embedded software industry in China［J］.Electronic Engineering ＆ Product World，2012（3）：11-14（in Chinese）

［5］倪亭.在軟件研發與測試中推廣GJB5000A［J］.軟件，2013（2）：31-35 Ni Ting.Promote GJB5000Ain software development and testing［J］.Computer Engineering ＆ Software，2013（2）：31-35（in Chinese）

［6］Capers Jones.軟件評估、基準測試與最佳實踐［M］.韓柯，譯.北京：機械工業出版社，2003 Capers Jones.Software assessmetnts，benchmarks，and best practices［M］.Han Ke，translated.Beijing：China Machine Press，2003（in Chinese）