欒蓉、產(chǎn)啟兵、李敏、徐瑛、陳麗容 /中國航天科工防御技術研究院

隨著裝備信息化和智能化的發(fā)展，軟件逐漸成為裝備的大腦、中樞，大型裝備系統(tǒng)已成為名副其實的“軟件密集型”系統(tǒng)。軟件的快速發(fā)展，對軟件的功能、性能、質量和可靠性等提出了越來越高的要求，然而因軟件設計的各類缺陷導致的質量問題也時有發(fā)生。自2002 年航天系統(tǒng)推行產(chǎn)品保證管理以來，軟件產(chǎn)品保證就是其中最重要的組成部分之一。航天系統(tǒng)十多年來一直采用軟件評測（本文“軟件評測”均特指“軟件第三方評測”）作為軟件質量保證最重要的途徑之一，其作用和效果日益受到各方的重視和關注。軟件評測是對軟件的功能性能是否達到需求規(guī)格說明的要求開展驗證工作，同時發(fā)現(xiàn)并糾正軟件問題，達到提高軟件質量可靠性的目標。

目前，對于軟件評測項目類型的選擇管理較為寬松，對于評測方提出的問題未被研制方采納的情況控制不嚴，從而造成質量不過關的軟件產(chǎn)品裝備系統(tǒng)，影響了整個系統(tǒng)的質量可靠性。筆者在航天軟件質量管理體系的基礎上，借鑒硬件技術狀態(tài)更改控制流程，提出進一步完善型號軟件評測過程質量管控的手段和方法。

一、目前軟件評測管理過程現(xiàn)狀

目前航天行業(yè)軟件研制工程化管理的相關標準規(guī)定各類活動的工作任務、實施步驟、方法和技術、工作要求、技術要求等，明確在軟件完成配置項測試后要在有認證資格的評測單位完成獨立的軟件測試工作。主要工作過程分為4 個方面：

一是軟件研制方完成軟件配置項測試。確認軟件已通過研制過程的內部測試，主要包括單元測試、集成測試、配置項測試，確認軟件技術狀態(tài)已經(jīng)固化、軟件相關文件資料齊全、符合規(guī)范、形成可供測試的固化版本。

二是評測單位針對軟件的不同更改量，在新測、復測和更改確認3 種測試項目類型中選擇適合的類型，隨后制定測試計劃、測試用例、測試規(guī)程，并負責測試數(shù)據(jù)相關工作。過程中軟件研制方要參與測評大綱和測試用例的設計、測試報告的評審。

三是軟件研制方對評測單位評測時發(fā)現(xiàn)的問題要進行分析和處理，對修改內容要進行測試驗證和更改控制，修改后提交評測單位進行回歸測試。

四是評測單位出具評測報告和相關統(tǒng)計測量結果，如軟件總規(guī)模、有效代碼行數(shù)、軟件注釋率、千行代碼缺陷率、文檔問題數(shù)、代碼問題數(shù)等，并通過正式評審，其結論作為軟件驗收的重要依據(jù)。

軟件評測具體流程見圖1。

圖1 軟件評測過程流程圖

二、存在的主要問題

1.評測中3 種測試項目類型的選擇存在就低不就高現(xiàn)象，質量管控較松

在相關評測技術管理要求中對新測項目、復測項目和更改確認這3 種測試項目進行了定義和區(qū)分。主要區(qū)別為新測項目需要對全部代碼進行評測，復測項目和更改確認均屬于回歸測試，只對軟件更改部分和受更改影響部分進行評測。復測項目需進行動態(tài)測試，更改確認項目測試時只對代碼進行靜態(tài)審查，而不進行動態(tài)測試。具體定義見表1。

表1 3種評測項目的測試條件及特點

在實際提交評測的軟件存在更改量較小，評測方認為軟件的更改情況滿足采用“更改確認”的測試條件，而采用更改確認的方式進行驗證只進行靜態(tài)測試，不開展動態(tài)測試，造成測試不夠全面。還有一些在試驗現(xiàn)場臨時做的偏離性更改，由于時間、場地、人員受限，大多都只是按更改確認做靜態(tài)文檔代碼比對，缺少覆蓋性更強、測試更全面的動態(tài)測試，而這些臨時性的更改往往是對試驗成敗起關鍵作用的。

2.評測提出的問題容易被設計師忽視，重視程度不夠，缺乏分析驗證工作

評測方將發(fā)現(xiàn)的問題分為四類:關鍵、重要、一般和建議。通過統(tǒng)計分析近3 年來不修改的問題發(fā)現(xiàn)，嚴重問題均得到了修改，重要問題不修改量達到3%，一般和建議類問題不修改量則高達30%。一方面，評測方與軟件設計師溝通不充分，未將問題及可能存在的風險描述細致清楚；另一方面，軟件設計師過于自信，對評測方反饋的問題僅從程序代碼表層分析，并未對軟件缺陷被觸發(fā)后導致的后果或者對試驗可能造成的影響進行更深入的分析，對于功能較為單一的底層設備軟件尤其是FPGA 軟件，這種現(xiàn)象更為突出。例如，評測方對某產(chǎn)品慣測組件FPGA 進行了評測，提出FPGA 的時鐘CLK 信號和DSP 的寫信號未做同步處理，當評測方指出該部分邏輯需要優(yōu)化設計，將兩個信號做同步處理時，設計師分析認為兩者相位差固定，不作同步不會有問題，并在以往產(chǎn)品測試中均未發(fā)現(xiàn)問題，故對評測方提出的信號同步問題作出本階段不進行更改決定。后來該產(chǎn)品在參加某次試驗時，就是因為該問題導致慣測組件沒有輸出正確有效的信號，試驗任務中止，對產(chǎn)品質量聲譽造成負面影響。

3.評測發(fā)現(xiàn)問題的更改控制流程中責任不夠清晰，對不修改問題的審批要求寬松

目前，航天系統(tǒng)相關的軟件評測管理要求中對評測發(fā)現(xiàn)問題的處理方法進行了規(guī)定：“不修改的問題應經(jīng)過研制方軟件設計師的上一級總體負責人認可；對雙方存在異議的修改問題，研制方應編寫風險分析報告，經(jīng)雙方領導確認后提交上會，由評測報告評審會給出評審意見。”在實際操作中，仍然存在重要問題不更改的現(xiàn)象，主要原因是時間節(jié)點緊張，不滿足軟件更改后的驗證周期。軟件研制方由于時間節(jié)點逼近，對軟件評測方提出的問題沒有足夠的時間認真分析研究，為了達到管理流程的閉環(huán)，研制方更愿意選擇寫風險分析報告提交上會評審，而不愿花費足夠的時間來驗證軟件更改是否正確。而在風險分析評審時，邀請的同行專家精力有限，很難參與某個軟件開發(fā)全過程的各項評審，僅參加一次會議、審閱一份報告未必就能認識到可能存在的所有風險，這就導致了不更改問題被例外放行。

三、軟件評測質量管控優(yōu)化措施

1.加嚴控制評測項目類型的選擇，強化動態(tài)測試

完善軟件評測實驗室體系作業(yè)文件，對評測項目類型的選擇加強把關力度，不可僅根據(jù)經(jīng)驗或軟件改動量的大小和規(guī)模進行判斷，還要綜合考慮被測軟件的重要性、安全性、關鍵等級等方面的內容，強化動態(tài)測試手段，如果測試項目有裁剪必須要說明理由，當功能、性能等有所更改，需要新增測試用例測試，驗證更改的正確性，以此達到評測全面性、充分性和覆蓋性的要求。

2.采用審理方式，加強對軟件評測提出的問題不被采納情況的控制

修改完善GJB5000A 體系文件及相關評測標準和規(guī)范，明確不更改軟件問題處理辦法，根據(jù)軟件的研制過程及評測過程，參照硬件產(chǎn)品的不合格品審理方式，提高對軟件評測問題不修改情況的把關力度：對軟件評測提出的問題，如果軟件研制方不修改，也應辦理《軟件評測不修改問題審理單》，說明不修改的理由及可能存在的風險，落實責任人并提高審批等級。

3.落實軟件裝機許可證制度，強化軟件評測過程質量管控

參照航天系統(tǒng)多年來一直施行的元器件裝機許可證制度，對于提交評測的軟件，軟件單位在確認《軟件評測不修改問題審理單》簽署完整有效，并通過了軟件評測評審會后，發(fā)放“軟件評測合格證”。質量管理部門應檢查軟件具備“軟件裝機許可證”后方可入軟件產(chǎn)品庫。通過發(fā)放“軟件裝機許可證”，可有效提高評測單位對軟件評測過程的質量監(jiān)管水平。

通過推行軟件評測合格證、軟件評測不修改問題審理等優(yōu)化措施要求，評測單位對其影響和效果進行了4 年的跟蹤和統(tǒng)計。截止目前，據(jù)不完全統(tǒng)計，在該措施落實之后， 軟件評測提出的問題修改率平均提高了11 個百分點，取得了顯著成效，促進了軟件質量管理水平的提升，進而為提升軟件質量和可靠性奠定了堅實基礎。