基于GJB5000A 的軟件估算技術在EICAS 系統中的應用

趙丹，周鵬甲，王建超

（1.陜西千山航空電子有限責任公司，西安710065；2.飛馬智科信息技術股份有限公司，馬鞍山243000）

0 引言

軟件估算技術是構成策劃軟件項目和控制軟件項目進度成本等方面的基石。無論哪類項目在開展項目以前以及進展過程中都要預先估計其軟件項目中所產生的各個軟件產品的規模、工作量、進度和成本等。但在軟件進行開發的過程中，軟件項目的開發過程是復雜多變的，正是由于軟件開發過程的復雜性，軟件估算過程也常常被認為是“黑匣子”過程，擁有非常高的不確定性和繁雜性[1]。軍用軟件成熟度模型即GJB5000A的宗旨是評價軟件項目管理過程并對軟件項目管理過程進行指導，實踐方法并沒有具體的明確指出，僅僅給出了相關的考核標準。因此，簡單高效具體的軟件估算是軟件項目開發和管理過程中非常重要的任務，也極具挑戰性，結合本單位的實際情況，發揮本地化特色，找到適合本單位的方法思路，將軟件項目估算方法應用到本單位實際項目，能夠使本單位軟件項目管理水平走向正規化、流程化和高效化，是具有重要及深遠指導意義的。

依據算法模型（algorithmic model）使用與否，軟件估算方法可以劃分為三類：未基于算法模型的軟件估算方法、基于算法模型的軟件估算方法和組合估算方法[2]。20 世紀60 年代，最先開始研究和探索軟件項目估計方法，形成了SDC 線性模型，線性模型發展經歷了40 多年[3]。依據艾爾布策功能點方法，全面功能點法相繼產生，它是由艾倫·艾布恩等人所給出，其優點是更為細化和可操作性強更強[4]，此后納入國際標準。經過幾十年的時間沉淀，計算機技術發展迅速并得到廣泛普及，人們更加關注和重視軟件估算方法的研究和應用，軟件估算日益重要。

近幾年來，雖然專家系統、神經網絡、人工智能等新技術在軟件項目中得到廣泛應用，提高和改善了很多問題的估計精度，但尚存的問題依然很多[5]。針對目前存在的各類問題，本文使用已有的軟件估算技術，運用到實際開發的軟件項目當中，在實踐中證明了通過此具體的本地化軟件估算技術使軟件項目管理水平得到了提升。

1 GJB5000A基礎及軟件估算技術理論知識

1.1 GJB5000A 基礎

采用能力成熟度模型集成（Capability Maturity Model Integration，CMMI）的思想觀念，GJB5000A 軍用軟件成熟度模型選用了分級表示法，按照提前明確的過程域集對組織的過程改進路徑進行定義。其宗旨是指導軟件開發組織實施有限的關鍵過程活動，來對軟件過程穩步地改進，持續提升組織的軟件過程能力。

在GJB5000A 中，軟件研制能力成熟度等級由低到高分別是初始級（ML1）、已管理級（ML2）、已定義級（ML3）、已定量管理級（ML4）和優化級（ML5）。除ML1之外，其它成熟度等級均含有多個過程域（Process Area）。雖然GJB5000A 中，初始級的組織的軟件研制過程沒有任何要求，但是組織要達到更高的成熟度等級，不僅僅要將本成熟度等級包含的過程域全部實施完成，同時需要實施低于此成熟度等級的所有等級包含的全部過程域。各等級對應過程域及過程域類型見表1。

表1 GJB5000A 等級對應過程域

從表1 可以看出，GJB5000A 已管理級可分為7 個過程域。其中項目策劃過程域和測量與分析過程域均有對估算相關的活動。項目策劃過程域要求對軟件規模、工作量等做估算；測量與分析過程域要求對項目策劃過程中所做的估算做監控和測量分析。根據GJB5000A 的要求，對軟件估計的要求如下：

（1）軟件項目經理組織對WBS 中的主要工作產品和活動進行規模估計。按照《軟件項目估計規程》執行，對規模、工作量/成本、進度和關鍵計算機資源進行估計，形成《軟件估計報告》，記錄估計的結果及其假設，并對其進行配置管理；

（2）當項目的規模、工作量/成本、資源等發生變更時，應重新估計；

（3）軟件項目經理組織《軟件估計報告》評審。

1.2 軟件估算技術理論知識

在GJB5000A 軍用軟件成熟度模型的體系架構下，不僅對軟件本身的質量非常重視，同時也極其關注軟件項目的過程管理質量，而軟件項目過程管理非常重要的一個環節就是軟件項目估算，它是軟件項目管理的前提基礎。軟件項目各類資源被有效利用的程度取決于軟件估算的準確程度。在軟件項目剛開始啟動前，就必須開展軟件估算任務，從而對軟件項目的進度、各類資源和成本等方面進行控制，為軟件項目在后續各階段中實施各個過程域提供必要的數據支撐。

1.2.1 規模估算方法

（1）Delphi 法

Delphi 法又稱專家調查法。顧名思義，專家調查法是依賴于專家的技術經驗和知識儲備，把專家看作信息獲取的主要對象，在缺乏估算的數據和信息資料的情況下，通過專家進行技術預測，對問題進行判斷、評價估計并進行預測，是一種比較直觀的預測方法。Delphi 法的主要工作程序如圖1 所示。

圖1 Delphi法主要工作程序

依據上圖Delphi 法工作程序，應注意以下事項：

①輪番征詢意見：提出的問題數量要求可控，不宜過多，問題要具體明確；

②選擇調查對象：調查對象人數一般控制在10～50 人以內，要求是具有廣泛代表性的專家，對相應業務精通熟悉，同時具有較強的判斷和洞察能力；

③輪番征詢意見后，一般需要使用中位數法統計處理意見，調查結論通常為處于中位數的專家意見。

知悉了Delphi 法的工作流程，可以總結出Delphi法的特點見圖2。

圖2 Delphi法的主要特點

從圖2 中Delphi 法的特點，可以看出Delphi 法的科學性和用途的廣泛性，但是在函詢過程中，需要通過書信來實現調查對象的聯系，無法實現面對面研討，非常浪費時間，各個專家極難不用過多的解釋就提出的明確具體的問題，通過中位數法獲得的最終意見在一定程度上會具有人為強制性，配合使用其他的方法，可以取得較好的估算效果。

（2）類比法

類比法適用于歷史軟件項目的數據具有較強的可信性、準確性和完整性，組織已建立起完善的軟件項目評價和分析機制，同時正在實施的軟件項目與歷史軟件項目復雜程度、應用環境領域等方面相類似的情況，利用歷史軟件項目的數據對比估算正在實施的軟件項目信息。

其基本估算步驟如下：

①將新項目的各個功能模塊以及其代碼行數整理列出；

②對新項目的各個功能模塊與歷史項目的功能模塊進行對比，列出相同點和不同點，同時重點標識出歷史項目的不足之處；

③通過對比新項目和歷史項目，完成步驟①和②后，可以得出新項目的每個功能模塊的估計值，需要注意的是，在使用類比法估算軟件項目時，通常還需考慮對可重用代碼的估算問題進行解決。

（3）PERT 法

PERT（計劃評估的評審技術），也被稱為PERT 方法，用來協調多個承包商和科研院所。在軟件項目整個生命周期實施完成的時間隨機以及假設軟件項目持續時間隨機的情況下，并且理論上服從某種概率分布，使用PERT 法可以將某時間范圍內的軟件項目完成概率估算出來。

定義1：在軟件項目實施過程極其順利，所有任務工作都能順利完成的情況下，所使用的時間稱作樂觀時間；在軟件項目正常實施情況下，某一項工作任務完成所需要的時間稱作最可能時間；在軟件項目實施的最不利的情況下，需要一個特定的任務完成時間被稱為悲觀的時候。

假設以上定義的三個時間估計均服從β分布，可以計算出各個階段的期望時間Ti：

其中，xi表示第i項工作的樂觀時間，mi表示第i項工作的最可能時間，yi表示第i項工作的悲觀時間。

第i項工作的持續時間方差為：

例如，某項目研制劃分需求分析階段、設計與實現階段、測試階段、驗收與交付階段四個階段，各階段按瀑布模型依次開展，沒有時間上的重疊，各階段完成時間估計：需求分析階段為6-12-15；設計與實現階段為14-21-36；測試階段為5-8-10；驗收與交付階段為6-14-13。

則各階段的期望工期和方差為：

從PERT 法可以看出，任何一個軟件項目都具有不可壓縮的最小周期，在項目開展實施過程中，我們要遵循客觀規律不能盲目向用戶承諾。

1.2.2 平均生產率估算方法

通常，估計技術可以劃分為兩種類型：代碼行（LOC）估算法和功能點（FP）估算法，二種估計方法具有相似性和差異。首先，軟件項目策劃人員需要根據用戶需求敘述軟件項目，得到一個有界的軟件范圍，并由此試圖將軟件項目劃分為可以獨立估算的子功能模塊；其次，分別對各個子功能模塊進行代碼行估算或者功能點估算；然后，測量生產力成本，規模或工作的量通過基線變量的具體估計來導出子功能模塊；最后，將子功能模塊的估算進行整理綜合取得整個軟件項目的總估算。

代碼行（LOC）估算法和功能點（FP）估算法針對分解軟件項目子功能模塊所需的顆粒度有所不同。當采用代碼行（LOC）估算法時，必須對各個功能進行很詳細的分解，達到一定的細致程度，而采用功能點（FP）估算法時，各個功能分解程度可以不必很詳細，因為估算功能點所需要的數據估算變量是較為宏觀的。代碼行（LOC）估算法是對每行代碼進行直接估算，與其不同的是，功能點（FP）估算法需要估計輸入、輸出、數據文件、外部接口數量以及復雜程度校正值間接確定。項目策劃人員還必須對被分解的各個功能給出有代表性的估算值范圍。軟件項目策劃人員依據歷史數據或者憑借項目實施過程中的實踐經驗，按照定義1 規定的樂三種情況分別對各個功能模塊給出代碼行或功能點估計值。

1.2.3 工作量估算方法

軟件項目中工作量的估算，是指開發軟件需要的人力資源的估計。工作量估算和軟件項目進度估算共同影響決定軟件項目開發團隊的構建及規模。工作量的單位一般為人日、人月、人年，不同單位間通過轉換系數進行轉換。

通常，主要的軟件工作量估算方法包括：

（1）COCOMO 模型估算方法

COCOMO 模型估計法又稱構造性成本模型，實質是基于模型的一種參數化的項目估算方法，其特點是估算的軟件工作量可以通過定義乘法因子準確合理地估算出來，估算精確、易于使用。

根據復雜程度和應用領域的差異性，COCOMO 可劃分為三個類型和三種軟件應用開發模式，具體見表2。

表2 COCOMO 模型估算方法種類及應用開發模式

COCOMO 工作量估計方法的乘法因子被稱為調整因子（Effort Adjustment Factor，EAF），體現出來多個參數的組合效果，這些參數可以分為五個等級：很低、低、正常、高和很高，數值在0.5 到1.5 之間，其乘積構成COCOMO 模型成本方程的系數，這些參數使得項目特征化和規格化。

基本模型是將已經估算出來的代碼行數（LOC）作為自變量，構建一個靜態單變量模型的函數，最后計算出軟件項目軟件產品開發的工作量。中間模型是基于基本模型的基礎上，需要與硬件、進度、人員各方面的參與，以進一步調整估計的工作負荷影響因素。詳細模型在中間模型的基礎上，同時還需考慮對軟件項目開發過程中策劃、分析、設計、測試等各步驟的影響。

組織模式相對來說項目規模較小，無需過多創新之處，開發環境比較熟悉并且具有一定的穩定性。嵌入式應用開發模式中軟件項目創新性很強，對整個應用層開發要求很高，接口要求受到一定限制，例如新游戲軟件的開發。中間應用開發模式是在上述兩種模式之間的模式。

（2）Putnam 模型估算方法

Putnam 模型估算方法是由Putnam 提出的一種動態多變量模型。此模型估算工作量時，整個生命周期的工作量假定符合特定的分布。通常在大型項目(總工作量≥30 人年)應用。Putnam 模型估算方法公式如下：

其中，L 表示源代碼行數（LOC）；K 表示全生命周期開發過程所需工作量（以人年計）；td 代表開發所持續的時間（單位：年）；Ck 是一個常數，代表一種技術狀態，反映出了“妨礙開發進展的制約”，取值因軟件開發過程的情況不同而有所差異，Ck 具有代表性的參數值如表3 所示。

表3 Ck 的典型值

2 EICAS系統介紹

2.1 系統功能及用途

EICAS 系統（全稱：發動機指示和空勤告警系統）的機載部分包括顯示處理機、液晶顯示器、發動機指示控制器、激勵源轉換盒。

顯示處理機采集來自飛機四臺發動機、環控系統、操縱系統、燃油系統、液壓系統和電氣系統的參數及其告警信號，通過對采集的參數進行綜合處理后傳至系統的顯示器進行顯示并輸出參數，參數以刻度盤、柱狀條、數字或文字的形式顯示出來，并通過不同的色彩編碼對各參數不同的狀態進行區分，為飛行員提供EICAS 系統交聯系統的工作狀態及告警指示，以便采取措施。

在EICAS 系統工作過程中飛行員可以通過操作發動機指示控制器進行畫面切換、顯示亮度調節、兩臺顯示器和兩臺顯示處理機切換等操作。

2.2 軟件用途

EICAS 系統軟件由三個軟件配置項構成。XC-18N顯示處理機軟件駐留在XC-18N 顯示處理機中，D/XYJ-73N 液晶顯示器軟件駐留在D/XYJ-73N 液晶顯示器中，SK-18J 發動機指示控制器軟件駐留在SK-18J發動機指示控制器中。軟件用途如下：

（1）XC-18N 顯示處理機軟件能夠實現各交聯系統的信號采集，并將數據進行組織，再通過HDLC 總線送給液晶顯示器進行顯示；完成系統的自檢、通信和對前端采集模塊進行重配置等任務；

（2）D/XYJ-73N 液晶顯示器軟件主要完成通過HDLC 總線從顯示處理機獲取圖形指令，并將圖形指令生成顯示畫面，還具有自檢、維護等功能；

（3）SK-18J 發動機指示控制器軟件主要完成對操作面板按鍵的掃描，并通過HB6096 總線將結果發送給顯示處理機。

系統軟件結構圖如圖3 所示。

3 軟件估算方法在EICAS系統中的實踐

3.1 EICAS 系統軟件的規模估算

本章僅針對顯示處理機中顯示控制模塊進行估算技術方法實踐討論。顯示處理機中顯示控制模塊主要的軟件模塊包括初始化模塊、數據接收模塊、響應主控信息模塊、顯示畫面數據處理模塊以及發送和接收EPD 數據模塊。

軟件規模估算分代碼估算和文檔估算。由于在項目實踐中EICAS 系統沿用以往項目軟件，所以在這里采用專家調查法結合類比法進行規模估算。具體步驟如下：

（1）確定工作產品。軟件項目經理按照各階段、里程碑所需形成的主要工作產品，明確應實施規模估算的工作產品；

（2）成立軟件估計組。邀請3 名及以上經驗豐富的專家組成軟件估計組；

（3）用寬帶Delphi 估計方法對工作產品規模估算。

圖3 EICAS系統軟件結構圖

①代碼估算

在以前相類似項目基礎上進行估算，歷史項目代碼規模具體情況如表4 所示。

表4 顯示控制模塊代碼歷史數據

估算專家根據上述項目的歷史數據和自身的經驗，對本項目各軟件類比系數進行估算如表5 所示。

如表5 所示，3 位專家根據沿用項目和本項目的特點，獨自估算出模塊的相似系數。然后根據每個模塊所有專家估算的結果做比較，如果估算的最大值和最小值之差與均值的比值（差異率）不超過20%，則認為專家對該模塊的估值是可接受的，估算的終值為各估算專家對該模塊估算的均值。從表5 可以看出，每個模塊的估算偏差值均在20%以內，所以，估值結果是有效的。

表5 顯示控制模塊類比系數估計結果

根據專家的估算情況，整理出的結果如表6 所示。

表6 EICAS 系統顯示控制模塊軟件規模估計表

②文檔估算

估算專家根據沿用項目歷史數據和自身的經驗，對本項目文檔頁數的估算如表7 所示。

如表7 所示，3 位專家根據以往類似項目和本項目的特點，獨自估算出每個文檔的頁數。同理可看出，對每個文檔的估值差異率均不超過20%，估值都是可以接受的。根據專家的估算情況，整理出的估算結果如表8 所示。

表7 顯示控制模塊規模歷史數據

表8 顯示控制模塊規模歷史數據

3.2 EICAS 系統軟件的平均生產率估算

平均生產率是指組織平均每人天的工作效率，可以以每人每天生產的代碼行和每人每天生產的文檔頁數表示。

在本項目實踐中，依據前文敘述的平均生產率估算方法進行本項目的估算，利用已經積累的歷史經驗數據、公開的數據及經驗最終得到平均生產率如表9所示。

表9 EICAS 系統平均生產率估算值

3.3 EICAS 系統軟件的工作量估算

軟件項目經理估計工作時按照估計工作量和成本表中所列出的要求，得出各階段技術工作量、各類型管理工作量、技術總工作量、管理總工作量、軟件項目總工作量的估計值（人日），具體方法如下：

（1）技術總工作量=源代碼估計總行數×難度系數/人均生產率；

（2）按照各階段技術工作量占比，得出各階段技術工作量=技術總工作量×各階段技術工作量占比；

（3）按照各階段管理工作量占比，得出各階段管理工作量=技術總工作量×各階段管理工作量占比；

（4）全生命周期的管理總工作量是各個階段的管理工作量的總和；

（5）軟件項目總工作量=技術總工作量+管理總工作量。

技術工作量和管理工作量估計表如表10-11所示。

通過上表技術工作量和管理工作量可以得到項目總工作量如表12 所示。

4 結語

在軟件項目實施管理整個過程中，獲得有用的軟件估算極其具有挑戰性，也是極為緊要的任務之一。本文針對試點項目EICAS 系統探討使用了軟件估算技術，提高了策劃準確度，提供了較高的估算值，能更好地安排項目任務，降低了成本，對任務按時完成和里程碑的維護提供了可信的數據依據，對歷史項目數據的挖掘和應用，使得以后項目的開發不會僅僅只憑經驗，本次估算方法的應用將是其他項目在軟件策劃方面的參考，對于所在單位推廣軟件工程化管理定量分析方面起到了促進作用。

表10 EICAS 系統技術工作量估計表

表11 EICAS 系統管理 工作量估計表

表12 EICAS 系統項目工作量估計表