郭棟 劉文紅 董冠濤 張碩 陸璐
(1.中國航天系統科學與工程研究院 北京市 100048 2.北京跟蹤與通信技術研究所 北京市 100095)
型號軟件往往規模巨大、價格高昂、型號繁多、系統復雜、關鍵等級高。參與軟件研制的單位多,同時能力水平不一,對型號軟件的質量帶來了較大影響。而現有的基于GJB5000A 來評價承制單位軟件研制能力的評價模型,仍存在一些局限性。例如:
(1)對軟件管理要求與技術要求權重一樣,而且管理要求比技術要求多。以三級為例,技術要求140 條,管理要求256 條,評價時權重一樣。通過調研發現,研制單位在實施要求時投入大量的精力在管理要求上,技術要求并沒有得到有效提升。因此,需要深入研究如何在現有軟件研制能力評價方法的基礎上,突出型號軟件研制技術能力要求,以便引導承制單位更加注重軟件研制技術能力的提升[1]。
(2)現有的評價方法重點關注了開發過程的能力評價,對聯調、試驗和交付后出現的問題無法有效評價。例如:研制單位在接受評價時,不反映聯調、試驗和交付后出現的問題,評價組將無法準確了解軟件的實際狀況[2]。
(3)目前采用的研制能力評價方法,是對研制單位自薦項目進行評價,只體現過程最優的四個項目的研制能力,未能對研制單位的軟件整體和歷史數據進行分析評價。
綜上所述,需要在現有軟件研制能力評價方法的基礎上,針對型號軟件研制的特點,制定對型號軟件研制能力進行評價的方法。
20世紀70年度中期,美國國防部就組織力量研究軟件項目失敗的原因,統計發現失敗的軟件項目中70%是由于管理不善造成的,從而掀起了研究軟件工程化管理的熱潮。為評價型號軟件承研機構的能力,研究和發布了CMMI,規定了必須具有相應軟件研制能力成熟度等級的機構才能承擔研制合同。CMMI 中包括了對軟件研制機構的管理、技術、組織、支持等各方面的要求。
根據2015年度美國國防部發布的《軟件概況》中的數據,其軟件承研機構中軟件能力成熟度等級(CMMI)100%達到三級以上,達到最高級五級的占比57%[3]。具體數據如圖1所示。

圖1:美國防部軟件承研機構的成熟度等級分布
目前,隨著工作的一步步深入推進,型號軟件研制能力評價成效顯著,科學化、信息化水平已逐步提高,但仍存在如引言中所述的受理審查項可操作性不強,研制能力評價更關注軟件開發過程能力,對軟件產品交付后的問題無法評價,現階段對管理要求和工程要求重點不突出等問題。
針對軟件研制能力進行評價的過程中,考慮到如果模型中包含的評價指標數量過多,會使處理過程及建模過程復雜化,指標重要性程度的確定也將變得困難,改變系統本質的可能性將升高;相反,若評價指標數量過少,則難以客觀、全面的刻畫系統發展狀態。
軟件的研制能力一方面需要依靠軟件開發與測試人員的技術能力,另一方面,合理的軟件開發過程管理能夠降低開發過程中不必要的失誤,利于后期維護與提高軟件質量。高質量的軟件離不開高質量的軟件研制過程。軟件的研制能力,還直接與其研制出的產品質量相掛鉤,在實際項目累積數據中不斷更新。
考慮到以上因素,本文從軟件研制過程側面和項目/產品累積數據側面這樣兩個大的方面來對型號軟件研制能力進行綜合評價。其中,以軟件研制能力成熟度評分作為研制單位的研制過程側面參數,以該研制單位當前已研制的各個項目/產品的累積數據為研制單位產品質量側面參數,分別進行獲取。具體結構如圖2所示。

圖2:軟件研制能力模型框架
考慮到該軟件研制能力評價方法的實施,是由軟件研制總體單位來對下方各子系統研制單位進行評價,總體單位在匯總各型號數據時可以拿到大量歷史承制軟件項目的質量信息,因此這樣搭建的評價模型在實際操作中是可行的。
3.2.1 GJB 5000A 的評分成績與歸一化處理
評價機構對GJB 5000A 的評分方式使用SCAMPI 方法[4]進行,由被評單位自行提供自己的項目來進行度量,根據這些項目的相關質量數據,對每個實踐域進行評價,給出每個實踐以S/L/P/NY 的分值。最終的統計評分采用木桶原理式,以短板作為能力的記錄點。一個目標未實現,則整體過程域評價為不通過;一個過程域不通過,則本級別評價不通過。通過對應級別軟件研制能力成熟度的單位,統計其所有實踐,最終得到的得分成績記為A。A 必然是大于6 分,最大能得到8 分。
GJB 5000A 一共分為5 個等級,考慮到不同等級的要求不同,本文在讀入對應的GJB 5000A 得分后,還要根據具體單位的成熟度通過權值對分數進行調整。例如:讀入的原始GJB 5000A 得分成績相同時,成熟度三級的單位在本算法中的得分成績應比成熟度二級的得分更高。
本文設置成熟度5 級權重為1.0,成熟度等級越低權重越低。如果直接讀出某單位的軟件研制能力成熟度打分成績為A,該單位的成熟度等級為N0,假設隨著熟度等級每降一級減少的權重為p0,則該單位軟件研制能力成熟度打分成績得分計算公式為:

其中,p0初始值可以根據專家經驗確定,后期累積歷史數據后,可通過對原始數據經過數學處理獲取權重來進行進一步調整。A 為0 ~8 之間的連續值,PSCM取值范圍即為0 ~8。
歸一化后軟件研制能力成熟度打分成績得分計算公式為:

3.2.2 已研制每項目研制過程評價與歸一化處理
該階段考察的指標包括需求評審問題數、單元測試問題數、測試用例數等。每個階段的指標都有一個基準值,與基準值偏差越大,研制過程評價得分越低。

設所有參與評價的單位中考察指標數(或者給定標準的考察指標數)最多為nmax,PYZ歸一化后計算公式為:

3.2.3 已研制每產品交付后問題評價與歸一化處理
交付后問題評價考察的指標包括發現問題難度、問題嚴重等級、發現問題的階段、發現問題數量。
針對每個問題都具有發現問題難度、問題嚴重等級、發現問題的發生階段三個屬性,發現問題難度越小、問題嚴重等級越高、發現問題的發生階段越靠后,最終的評價分數越低。
設發現問題難度包括1、2、3、4、5 五個等級。其中,等級1為執行軟件基本功能即能發現的問題;等級2 為需要進行一定的用例設計方法,執行到較偏的邏輯分支才能發現的問題;如此遞推直至等級5 為極為隱蔽難以發現的問題。發現問題難度每增加一個等級,則權重增加p1,發現的問題難度等級為N1,則發現問題難度對交付后軟件問題評價結果權重公式為:

設發現問題嚴重等級包括1(致命)、2(嚴重)、3(一般)、4(輕微)、5(建議)五個等級,發現問題嚴重等級每降低一個等級(對應的值增加),則權重增加p2,發現的問題難度等級為N2,則發現問題難度對交付后軟件問題評價結果權重公式為:

設發現問題發生階段包括方案、需求、設計、編碼、使用等,假設劃分階段數為S,按階段先后順序對應的標注值為1、2、3、…、S,發現問題發生階段往后一個階段,則權重增加p3,發現問題發生階段對應值為N3,則發現問題難度對交付后軟件問題評價結果權重公式為:

設該階段總分為B,如果在軟件交付后共發現k 個問題,第i 問題對應的發現問題難度、問題嚴重等級、發現問題的發生階段指標值分別為(當未發現問題,即k=0 時,),對應該階段的得分值權重為:

同前,p1,p2,p3初始值可以根據專家經驗確定,在后期累積歷史數據后,可通過對原始數據經過數學處理獲取權重來進行調整。
PJF歸一化后計算公式為:

3.2.4 綜合評價方法
綜合評價方法采用加權平均的方式。假設綜合評價得分滿分為100,三個方面的評價結果權重為W1,W2,W3,且滿足W1+W2+W3=1。
則綜合評價得分Q 的計算公式為:

為了驗證本文所提的型號軟件研制能力評價方法,本文選擇了兩個型號軟件研制單位來進行試點應用。兩個單位均已通過GJB5000A 能力評價二級,且在同一型號中分別承擔了多個軟件配置項的研制。
針對單位A,首先讀取其軟件研制能力成熟度二級評分成績如表1所示。

表1:單位A 的軟件研制能力成熟度二級評分
該研制單位在本型號的配套軟件中負責了3 個軟件配置項的研制,每個軟件配置項的研制均可視為一個獨立研制項目進行統計。對應這3 個軟件配置項,其研制過程中的相關指標統計如表2所示。

表2:單位A 負責的配置項相關指標
配置項1 在交付后發現的軟件問題情況如表3所示。

表3:單位A 配置項1 的問題
配置項2 在交付后發現的軟件問題情況如表4所示。

表4:單位A 配置項2 的問題
配置項3 在交付后發現的軟件問題情況如表5所示。

表5:單位A 配置項3 的問題
在將該單位的數據代入了專家經驗相關參數p 和a 的取值矩陣后進行計算,得到P1=0.871,P2=0.881,P3=0.936,最終得分Q=89.6分。
針對單位B,首先讀取其軟件研制能力成熟度二級評分成績如表6所示。

表6:單位B 的軟件研制能力成熟度二級評分
該研制單位在本型號的配套軟件中負責了2 個軟件配置項的研制,每個軟件配置項的研制均可視為一個獨立研制項目進行統計。對應這2 個軟件配置項,其研制過程中的相關指標統計如表7所示。

表7:單位B 負責的配置項相關指標
配置項1 在交付后發現的軟件問題情況如表8所示。

表8:單位B 配置項1 的問題
配置項2 在交付后發現的軟件問題情況如表9所示。
H.264的編碼算法有:幀內預測編碼,幀間預測編碼,DCT變換和量化,熵編碼。 幀間預測編碼消耗時間占到整套算法運行時間80%左右,所以H.264編碼器算法優化的重點就是幀間預測編碼算法的優化。

表9:單位B 配置項2 的問題
在將該單位的數據代入了專家經驗相關參數p 的取值矩陣后進行計算,P1=0.888,P2=0.884,P3=0.818,最終得分Q=86.3 分。
如表10所示,從兩個單位原始的軟件研制能力打分情況來看,兩個單位均為軟件成熟度二級單位,得分情況單位B 略優于單位A。

表10:兩個單位的得分比較
而從該型號中所承擔的軟件研制任務情況看,單位A 承接的軟件中,交付后的問題尤其較易檢出的低級錯誤相對較少,但存在部分需求、設計階段的問題未在研制過程中及時檢出。單位B 所承接的軟件中交付后的問題數量相對更多,級別也相對高一些,但主要為編碼階段發生的問題。在交付后仍存在部分較易檢出的問題未在研制過程中予以檢出,說明其管理能力較好(與原始軟件研制能力得分情況一致)但技術能力略弱。
以上情況體現在兩個單位的最終得分中,單位B 的得分從原來的單純的軟件研制能力評分高于A 單位,變為了在改進后的軟件研制能力綜合評價方法下低于A 單位,說明該評價方法將各單位實際的技術能力和研制項目的產品質量也納入了考慮。
本文的主要技術創新點包括:
(1)提供了一種基于過程評估和測試結果的軟件質量評價方法,基于軟件研制過程中的質量評審問題、GJB5000A 評分和年審問題、以及當前軟件研制測試過程中的問題來綜合計算,得到所研制軟件質量的綜合評估結果。
本文在現有軟件質量評價研究成果的基礎上,提出了一種基于過程評估和測試結果的軟件質量評價方法,立足于總體單位所能方便獲得的質量數據,快速便捷評估各軟件的質量。該軟件質量評價方法可在型號軟件領域推廣實施,綜合軟件研制過程要素和測試結果來快速度量軟件質量。