黃 洋

隨著航空裝備數(shù)字化程度的提高，軟件在航空裝備中的比例和規(guī)模呈大幅上升趨勢，但軟件的質(zhì)量和可靠性卻差強人意，軟件故障已成為航空裝備事故發(fā)生的主要原因。根據(jù)理論研究和國內(nèi)外實踐經(jīng)驗，實施軟件工程可有效提升軟件質(zhì)量，確保軟件可靠性。

從國內(nèi)型號軟件研制現(xiàn)狀來看，雖然研發(fā)單位都對軟件過程進行了控制，但軟件工程化總體水平仍較落后，軟件質(zhì)量難以保證，因此，制定一個適合我國國情的軟件工程化管理體系，開展必要的軟件工程化工作尤為重要。

1 軟件工程研究現(xiàn)狀

軟件工程（Software Engineering）是應用計算機科學理論和技術(shù)以及工程管理原則和方法，按照預算和進度，實現(xiàn)滿足用戶要求的軟件產(chǎn)品的定義開發(fā)、發(fā)布和維護的工程或以之為研究對象的學科。從1968年“軟件工程”提出至今，已總結(jié)出多種軟件工程方法和模型，包括國外的CMMI（Capability Maturity Model Integration）、ISO 9000，以及國內(nèi)的軍用軟件研制能力成熟度模型、GJB 9001等。

能力成熟度集成模型（Capability Maturity Model Integration）是美國卡內(nèi)基·梅隆大學軟件工程研究所（SEI）從1986年開始研究并完成的。CMMI過程模式用于提高軟件研發(fā)和管理能力，包括5 級：初始級（Initial）、可重復級（Repeatable）、已定義級（Defined）、已管理級（Managed）和優(yōu)化級（Optimizing）。

ISO 9000系列標準是一組保證產(chǎn)品質(zhì)量的標準，是歐盟認可的國際標準化組織制定的標準。其中，ISO 9001指導軟件企業(yè)建立質(zhì)量體系，對企業(yè)的管理和控制提出具體的質(zhì)量要求。

GJB 5000A-2008《軍用軟件研制能力成熟度模型》用于提高軍用軟件研發(fā)和管理能力。軍用軟件研制能力成熟度模型分為ML1（初始級），ML2（已管理級），ML3（已定義級）， ML4（已定量管理級）， ML5（優(yōu)化級）5個級別。此外，GJB 9001B—2009《質(zhì)量管理體系要求》也進一步強調(diào)對軟件工程化管理要求的細化。

2 復雜航空軟件工程化綜合管理框架

由于航空型號軟件研制具有軟件在飛機中的實現(xiàn)比率大幅上升、大部分軟件為嵌入式軟件、高可靠性和高安全性、參與研制的單位眾多的特點，為了保證復雜軟件系統(tǒng)的研發(fā)，需要按照軟件工程化的理論、技術(shù)和方法進行軟件研制工作。

軟件工程化管理主要對軟件開發(fā)過程、軟件驗證過程、軟件質(zhì)量管理過程和使用與維護過程進行管理。軟件開發(fā)過程對開發(fā)各階段的開發(fā)活動進行管理；軟件驗證過程主要是對軟件測試和評審進行管理；軟件質(zhì)量管理主要包括軟件分級管理、軟件需求管理、軟件文檔管理、軟件質(zhì)量保證、軟件配置管理、軟件失效分析和糾正措施系統(tǒng)過程；軟件維護是軟件在交付使用后，因出現(xiàn)故障或改善原有性能等進行的修改，應加強對該階段管理的強度。

軟件工程化管理工作包括總體規(guī)劃、組織建設、體系建設、標準與規(guī)范以及工具建設，分為5個部分?？傮w規(guī)劃包含實施原則和實施策略；組織建設包括機構(gòu)組成和人員組成；體系建設包括頂層要求、實施大綱以及工作規(guī)范；標準與規(guī)范主要是選擇合適的標準和規(guī)范進行剪裁和融合；工具建設是軟件研制單位為了提高軟件開發(fā)效率，降低軟件開發(fā)成本進行的基礎建設。軟件工程化管理的關(guān)鍵包括對軟件開發(fā)過程的全過程控制、對軟件質(zhì)量的全方位管理和建立多層次的軟件開發(fā)、管理體系。

軟件工程化綜合管理框架如圖1所示。

3 軟件工程實施重點

3.1 軟件測試質(zhì)量評價

軟件測試質(zhì)量評價是通過軟件測試實踐，在不同測試活動中選取了一系列度量元對軟件測試工作質(zhì)量進行評價，并對軟件測試質(zhì)量的評價值做出A、B、C、D的“模糊”評價。

軟件測試質(zhì)量評價包括合格性評價和模糊評價兩個部分。合格性評價主要是對軟件測評過程和活動是否按照相關(guān)國軍標要求進行評價。模糊評價是在合格性評價通過的基礎上，按照合理的軟件測試評價模型，度量影響軟件測試質(zhì)量的相關(guān)因素，基于灰色理論給出軟件測試質(zhì)量的評價。本文提出的軟件測試評價模型，分為測試需求、測試策劃、測試設計、測試執(zhí)行和測試總結(jié)5個活動，每個活動有若干個度量元。單元測試、部件測試、配置項測試和系統(tǒng)測試將分別按照以下的評價方法進行評價后，在進行加權(quán)集成評價。

軟件測試工作質(zhì)量評價框架如圖2所示。

軟件測試工作質(zhì)量評價實施步驟如下：

● 對被測軟件進行測評歷史評價及文檔質(zhì)量評價。

● 進行合格性評價。評審組按照相關(guān)標準要求的目標進行審查，確定軟件測試項目合格性。

● 進行“模糊評價”。確定各測試級別、測試活動的關(guān)聯(lián)系數(shù)權(quán)重；確定每個度量元最優(yōu)指標及權(quán)重；收集各度量元相關(guān)數(shù)據(jù)，計算實際值與最優(yōu)指標的關(guān)聯(lián)系數(shù)、單項活動綜合關(guān)聯(lián)系數(shù)、待評價對象測試活動綜合關(guān)聯(lián)系數(shù)及綜合關(guān)聯(lián)系數(shù)。

● 進行綜合評價，確定綜合評判定量要求，計算綜合評價值，根據(jù)綜合評價值判定測評項目所處的檔位并排序。

3.2 軟件研制工具管理

目前，軟件研制工具管理在型號管理中是一個盲區(qū)，將軟件研制工具納入統(tǒng)一管理可降低使用多種工具帶來的多種風險、減少工具使用沖突，提高型號軟件研制質(zhì)量，便于工程管理和評價。

國內(nèi)外對于軟件研制工具管理較為系統(tǒng)和完整的標準是RTCA DO-330《軟件工具資格鑒定考慮》，但其以目標為基礎的鑒定方法并不適合我國遵循過程導向標準的現(xiàn)行軟件研制體制。

因此，借鑒RTCA DO-330的工具鑒定思想，結(jié)合目前我國型號管理現(xiàn)狀，制定了軟件研制工具管理實施方法。軟件研制工具管理實施框圖如圖3所示。具體實施步驟如下：

● 確定軟件研制工具管理范圍，包括型號軟件開發(fā)工具和驗證工具；

● 調(diào)研擬承擔型號項目單位預計使用的開發(fā)工具和測試工具，了解目前主流工具的使用情況；

● 按照軟件級別和工具類型對工具進行分級，自研的開發(fā)工具、驗證工具與商用工具具有不同的級別；

● 在承研單位計劃使用該工具前完成工具鑒定；

● 工具鑒定時承研單位根據(jù)工具等級提交審查資料；評審組根據(jù)審查單對工具資料進行會議審查（必要時可進行現(xiàn)場抽測），并給出審查結(jié)論。

4 復雜軟件工程化管理實踐和應用

軟件工程化的實施重點是軟件開發(fā)過程。軟件工程化管理的實踐和應用主要從軟件生存期各階段過程控制、軟件全方位質(zhì)量管理、軟件組織過程3個方面開展。

4.1 軟件生存期各階段過程控制

在航空型號軟件實施軟件生存期各階段過程控制中，按照GJB 2786A-2009《軍用軟件開發(fā)通用要求》的要求，將軟件開發(fā)過程分為系統(tǒng)分析與軟件定義、軟件需求分析、軟件設計、軟件實現(xiàn)、軟件測試、軟件驗收與交付和軟件使用與維護7個階段。在軟件工程化實施過程中對每個階段的進入條件、主要工作、階段產(chǎn)品和完成標志進行規(guī)定。

以軟件需求分析階段為例，規(guī)定進入軟件需求分析階段的條件是軟件開發(fā)任務書已完成并通過評審、軟件開發(fā)項目組成立并且軟件配置管理功能基線已建立。規(guī)定該階段主要進行軟件需求分析和制定軟件開發(fā)計劃，工作產(chǎn)品是軟件開發(fā)計劃、軟件需求規(guī)格說明、軟件接口說明和數(shù)據(jù)要求說明。并規(guī)定需求階段的完成標志是所有階段產(chǎn)品均完成、軟件開發(fā)計劃經(jīng)批準后生效、軟件需求規(guī)格說明通過評審并且完成分配基線的建立。

4.2 軟件全方位質(zhì)量管理

通過分級管理、軟件評審管理、軟件配置管理、軟件測試管理和建立軟件失效報告、分析和糾正措施系統(tǒng)等5個方面，對型號軟件實施軟件全方位質(zhì)量管理。

4.2.1 建立軟件分級管理

根據(jù)軟件失效后的危害，將軟件劃分為關(guān)鍵、重要和一般3個等級。由于飛機上軟件多，管理成本較大，對不同級別的軟件在文檔管理、評審管理和測試管理上進行分級管理。

對于關(guān)鍵軟件，要求完成GJB 2786A要求的全部軟件文檔，并且對每個開發(fā)階段都要進行外部評審，軟件測試要求完成單元測試、部件測試、配置項/系統(tǒng)測試。對于重要和一般軟件，可按照規(guī)定進行適當裁剪。

4.2.2 進行軟件評審管理

在型號軟件的評審管理中，對軟件不同階段的產(chǎn)品評審進行區(qū)別管理。評審方式分為正式評審和內(nèi)部評審。正式評審在質(zhì)量管理部門組織下進行。內(nèi)部評審是在軟件項目組內(nèi)完成的評審，評審過程、內(nèi)容和要求，以及評審組的成員和負責人均由該項目組長確定。

在型號軟件研制的系統(tǒng)分析/軟件定義階段、軟件需求分析、配置項/系統(tǒng)測試、軟件驗收階段進行外部評審，在軟件設計、軟件實現(xiàn)和單元測試階段進行內(nèi)部評審。

4.2.3 進行軟件配置管理

對型號軟件進行軟件配置管理，將軟件開發(fā)的階段產(chǎn)品納入配置管理基線中，源程序、文檔或數(shù)據(jù)任何一個變更均要通過配置管理相關(guān)程序的審查批準。

在型號級和承研單位級均建立開發(fā)庫、受控庫和產(chǎn)品庫，裝機軟件統(tǒng)一從型號級配置庫中進行提取。在軟件配置管理過程中要建立配置管理組織機構(gòu)、制定軟件配置管理計劃、進行軟件配置管理活動、記錄并報告軟件配置管理狀態(tài)、進行軟件配置管理審核。

4.2.4 進行軟件測試管理

對型號軟件進行軟件內(nèi)部測試管理和獨立測試管理。

對承研單位內(nèi)部測試工作進行內(nèi)部測試管理，評估承研單位內(nèi)部驗證能力，評審研制主管部門參加內(nèi)部測試重要節(jié)點，抽查內(nèi)部測試質(zhì)量。

對第三方測試、鑒定測評以及定型測評進行獨立管理，要求各階段測評工作邀請同行專家進行內(nèi)部評審，研制主管部門參與大綱評審、總結(jié)評審等重要節(jié)點的評審，并對定型測評的測試結(jié)果進行抽查。

4.2.5 建立軟件失效報告、分析和糾正措施系統(tǒng)

在型號軟件完成系統(tǒng)測試后，建立軟件的失效報告、分析和糾正措施系統(tǒng)（SFRACAS），將軟件的失效加以記錄、報告，找出失效原因，并采取糾正措施。

SFRACAS的工作要完成軟件問題報告、軟件問題影響分析、軟件糾正措施和軟件失效報告、分析和糾正措施系統(tǒng)報告。

軟件問題報告是糾正措施的過程輸入，對軟件問題進行分類和分級，將軟件問題分為文檔問題、程序問題、設計問題及其他問題4類，并根據(jù)問題嚴重程度分為關(guān)鍵、重要、一般和建議改進4個等級。

對軟件問題進行影響分析主要體現(xiàn)在費用、進度、風險以及對合同的影響等方面。對軟件問題進行影響分析后，按照問題的類型和等級進行優(yōu)先次序的分類，采取有效的糾正措施，完成軟件SFRACAS報告。

4.3 軟件組織過程

型號軟件組織過程主要進行培訓、過程監(jiān)督及工具建設。培訓主要由總師單位和技術(shù)支撐單位負責研制體系專項培訓和專項技術(shù)培訓。過程監(jiān)督依據(jù)型號相關(guān)要求標準及相關(guān)法規(guī)，編寫監(jiān)督檢查實施方案，確定檢查目標，對參研單位的研制情況和各項能力進行檢查，以督促軟件研制，及早發(fā)現(xiàn)問題，及早采取糾正措施。工具建設是構(gòu)建軟件工程環(huán)境，包括軟件開發(fā)過程支撐工具、質(zhì)量保證工具、項目管理工具和團隊協(xié)作工作環(huán)境4類。目前型號軟件研制單位都具備一定的開發(fā)基礎和工具積累，新項目開始前選用工具應充分考慮本單位工具使用歷史，適當選用和增加開發(fā)和管理工具，從而提高軟件產(chǎn)品質(zhì)量和開發(fā)效率。

5 結(jié)束語

本文在對軟件工程方法、過程及航空型號軟件工程化現(xiàn)狀充分調(diào)研的基礎上，提出了航空型號軟件工程化的總體構(gòu)架以及軟件工程化實施重點，并對軟件測試質(zhì)量及軟件研制工具管理進行了著重探討；對灰色理論和軟件測試工作的度量元進行了研究，提出了合格性評價結(jié)合模糊評價的測試質(zhì)量評價方法；參照RTCA DO-330標準，結(jié)合國內(nèi)航空型號軟件研制現(xiàn)狀，提出了軟件研制工具管理方法。該方法可在航空型號軟件工程中應用，以解決復雜軟件研制管理的問題。

[1] 阮廉，陸民燕，韓峰巖. 裝備軟件質(zhì)量和可靠性管理[M]. 北京：國防工業(yè)出版社，2006.

[2] 孫旭，楊順昆，劉斌. 復雜航空軟件工程化綜合管理框架[J]. 現(xiàn)代電子技術(shù). 2012，35（24）.

[3] 楊芙清. 軟件工程技術(shù)發(fā)展思索[J]. 軟件學報.2005，16（1）.

[4] WONGTHONGTHAM P，KASISOPHA N，CHANG E，et al．A software engineering ontology as software engineering knowledge representation[C]//Third International Conference on Convergence and Hybrid Information Technology．Busan：ICCIT，2008.

[5] DILLONTS，CHANGE，WONGTHONGTHAM P．Ontology-base software engineering：software engineering 2.0[C]//19th Australian Conference on Software Engineering.perth：IEEE，2008.