■ 白 光 張永軍 雍明遠
軍用軟件可靠性研究
■ 白 光張永軍雍明遠
我國在軍用軟件領域的起步較晚,在軍用軟件的可靠性研究和應用方面起步更晚且投入的精力明顯不夠。在武器科技化、集成化日益明顯的今天,軟件可靠性方面的不足很容易成為制約我們裝備發展的瓶頸。對此,筆者在應用開發方面進行了討論。
長期以來,在實際使用過程中暴露的軟件以及和軟件有關的問題逐漸增多,直接影響了整個武器系統的質量。為了避免和消除錯誤,確保開發出的軟件系統工作正確,運行可靠,如何提高軟件裝備的可靠性,是軟件質量管理的重點工作。
1983年美國IEEE計算機學會對“軟件可靠性”作出了明確定義,此后該定義被美國標準化研究所接受為國家標準,1989年我國也接受該定義為國家標準。新版GJB/Z 102-97的定義包括兩方面的含義:
(1)在規定的條件下,在規定的時間內,軟件不引起系統失效的概率;
(2)在規定的時間周期內,在所述條件下程序執行所要求的功能的能力;
其中的概率是系統輸入和系統使用的函數,也是軟件中存在的故障的函數,系統輸入將確定是否會遇到已存在的故障(如果故障存在的話)。
同時我們也都知道,第一,無論多么成熟的軟件都不會十全十美,幾乎所有投入使用的軟件仍含有嵌入的錯誤,由于軟件測試時間和費用上的限制,想用連續不斷的檢查來獲得100%正確的軟件是幾乎不可能的。第二,軟件一時的正確運行,不等于程序中已不存在任何差錯。因為和有相當規模的軟件一般總有多條分支和多種功能。在不同的使用目的和輸入條件下,其故障的發生是隨機的。
軟件可靠性是關于軟件能夠滿足需求功能的性質,軟件不能滿足需求是因為軟件中的差錯引起了軟件故障。軟件中有哪些可能的差錯呢?
軟件差錯是軟件開發各階段潛入的人為錯誤:
1.需求分析定義錯誤。如用戶提出的需求不完整,用戶需求的變更未及時消化,軟件開發者和用戶對需求的理解不同等等。
2.設計錯誤。如處理的結構和算法錯誤,缺乏對特殊情況和錯誤處理的考慮等。
3.編碼錯誤。如語法錯誤,變量初始化錯誤等。
4.測試錯誤。如數據準備錯誤,測試用例錯誤等。
5.文檔錯誤。如文檔不齊全,文檔相關內容不一致,文檔版本不一致,缺乏完整性等。
從上游到下游,錯誤的影響是發散的,所以要盡量把錯誤消除在開發前期階段。
根據上面對影響軟件可靠性的分析,造成軟件錯誤的因素貫穿于整個軟件開發的全過程,任何的事后彌補措施都是建立在已經造成了錯誤后果的基礎上的。因此,將軟件錯誤盡可能地消滅在萌芽狀態是投入成本最小的,而通過采用科學的軟件工程化要求進行軟件系統的設計可以將軟件的潛在危險控制到盡可能小的范圍。
開發高可靠軟件必須采用軟件工程方法,搞好軟件開發工程化。當前研制的軍用軟件裝備絕大部分擁有龐大的軟件體系結構:可重用或公用的功能模塊,多個分承包方的參與,決定了項目的開發必然是一個團隊協作開發過程。根據GJB 2786-96,需要從以下幾個方面督促研制方抓好軟件工程的實施:
(1)軟件開發方法
軟件開發方法對軟件的可靠性有重要影響。面向對象的方法便于軟件復雜性控制,有利于生產率的提高,符合人類的思維習慣,能自然地表達現實世界的實體和問題,具有一種自然的模型化能力,達到從問題空間到解空間的較為直接自然的映射。
在面向對象的方法中,由于大量使用具有高可靠性的庫,其可靠性也就有了保證,用面向對象的方法也利于實現軟件重用,所以一般應采用面向對象的方法。
(2)軟件工程環境
軟件工程環境應該能夠集中支撐開發階段的操作。
(3)安全性分析
一定要重視軟件的容錯性設計,把執行任務的潛在危險降到盡可能小。
(4)非開發軟件
非開發軟件應當結合到交付軟件中,非開發軟件的結合應用應經過簽約機構的批準和遵守合同中的數據權限要求。
(5)計算機軟件組成
應根據軟件開發計劃規定的開發方法,將軟件配置項進行分解并劃分成軟件部件和軟件單元。應確保軟件配置項的需求已完全分配,并能進一步細化,以便更好地實施每個軟件部件和軟件單元的設計與測試。
(6)從需求到設計的可追蹤性
明確劃分各開發過程(需求分析過程、設計過程、測試過程、系統集成階段等),在各開發過程中實施進度管理,產生階段質量評價報告,對不合要求的部件和單元及早采取對策。
(7)高級語言
選擇編程語言對開發和維護階段都是重要的。當選擇編程語言時必須注意特殊的應用要求及它對于軟件工程現代化的質量保證原則是否支持,在滿足用戶需求的前提下,還要綜合考慮編譯和編程環境的有效性、語言的可移植性、編程人員的技術水平等。
(8)設計和編碼標準
必須大力推行標準化的實施。標準對于項目的互聯、互通、互操作,對于開放性、可維護性,是一個先決條件。標準的簡單或復雜,決定著系統的簡單與復雜。標準的可操作性,影響著系統的一致性和可維護性;標準的好壞,決定了系統性能。
為標準的實施相應制定許多實施的細則與模板,使得標準的實施不但有章可循,而且可以操作,可以重復(重用),便于檢查。這些細則與模板包括需求分析、概要設計與詳細設計的細則;包括需求分析、概要設計與詳細設計的模板。
(9)軟件開發文件
軟件開發文件包括系統文檔、維護文檔和項目管理文檔等。開發文檔可以使人們對已經執行的開發過程有深入的了解,并對重要的階段成果進行初步和清晰的說明。
(10)處理資源和預留量
應在合同期內對處理資源的利用情況進行監測,資源利用情況應記載在各軟件配置的產品規格說明。
目前我國的軍品承制企業由于受到多種因素的影響和制約,軟件可靠性的要求都重視的不夠,在軟件的開發、設計階段分析不足,缺乏嚴格的評審;在軟件的調試、驗收階段也缺乏科學的測試手段,無法對代碼進行充分的測試;在使用、維護階段不能嚴格按照軟件配置進行管理,造成軟件在生存周期中存在更改隨意性大,質量難控制的問題。
(1)軟件開發過程透明度差:現有的軟件承制單位依然存在軟件的開發過程由開發者“自編”“自導”“自演”的現象,一旦軟件出現問題只能由開發者本人去進行維護,其他人很難介入,而現在的企業人員流動比較大,一但發生人員變更,后繼者往往要將前任的工作推倒從頭再來,嚴重影響科研工作的進行。
(2)沒有嚴格執行配置管理:未對軟件的更改標識、更改控制、更改檢查等進行嚴格控制, 造成軟件的管理混亂, 產品的軟件錯誤較多,軟件質量控制差。
(3)軟件測試不夠:軟件的測試軟件、測試工具缺乏, 測試標準、規范和管理制度不健全。目前絕大多數的軟件檢驗都與硬件一起進行。軟件驗收時所謂的測試也是對預先指定的幾個用例進行測試, 起不到軟件測試的應有作用, 因而造成軟件的缺陷多、故障多。
(4)沒有明確的軟件可靠性指標要求:在戰技指標和研制任務書中沒有明確提出軟件的可靠性指標要求。可靠性指標通常被認為是硬件的可靠性指標, 在考核中沒有對軟件的可靠性進行單獨驗證, 對軟件的可靠性心中無數。
(5)尚未建立完善的檢驗體系:軟件沒有像硬件那樣建立嚴格的“三檢”制度, 軟件檢驗基本上是由軟件開發者完成的。而實踐證明僅僅依靠自檢不能保證軟件質量, 因此交付部隊使用的產品軟件質量問題較多。
針對以上問題,需要加強軟件質量控制,嚴格按照軟件工程化的要求執行,幫助企業建立高效可靠的軟件開發流程,提高軟件系統的可靠性水平。具體做法如下:
(1)實施軟件工程化管理:杜絕開發者集多重角色于一身,嚴格做到設計、生產、檢驗分開,形成三者相互制約的關系,由軟件設計工程師編制軟件的設計圖紙(即詳細設計報告) , 由合格的軟件編程人員按設計報告編程, 最后由軟件檢測人員檢查軟件的設計、編程是否符合要求。這樣才能有效提高軟件質量和可靠性。
(2)按照GJB438B和GBJ2786的要求,對各階段形成的文檔進行審查,實行配置管理,確保軟件設計、生產、維護過程是受控的,可重復的。
(3)嚴格實行軟件配置管理,各階段工作完成后把階段成果送入軟件受控庫中,開發者只能使用,不得隨意修改,若要修改,需按照相應的審批手續報備。當軟件的集成和綜合測試階段結束時, 應該匯總并修訂全部軟件文檔, 連同源程序清單和目標代碼清單一起送入軟件產品庫。進入系統的運行和維護階段后, 若要對配置項進行修改, 必須依照有關程序修改, 產生新的軟件版本。
(4)必須對軟件進行充分的測試:對于軟件開發者來說, 開發出的軟件必須具備可測試性。軟件的缺陷是不可避免的, 不可測試的軟件,其缺陷將不易被發現和糾正。所謂軟件測試, 是通過對源程序及其實際執行所產生的結果進行檢查分析, 以找出程序中可能隱藏的錯誤的過程, 即為了發現程序錯誤而執行程序的過程。程序測試過程通常要反復進行多次, 直到滿足某種測試策略為止。
1.王江為,郭新河.武器裝備軟件可靠性研究,《電腦知識與技術》2011年32期;
2.楊英清.軟件工程技術發展思索,軟件學報,2005(1);
3.吳福全,蘇小桅.軟件質量評估方法與探討,成都大學學報:自然科學版,2008(1);
(作者單位:空軍駐西北地區軍事代表室)