軍用軟體維護方法探析論文

　　【摘要】為了提高我軍保障力和戰鬥力，本文透過研究軍用軟體維護的現狀，提出了軟體維護的重要性，並根據實際情況提出了軟體維護的具體方法。

　　【關鍵詞】軟體維護；軍用軟體；保障力

　　隨著社會資訊化的迅猛發展，軍用裝備正在朝著軟體密集型裝備方向發展，部隊使用的武器裝備中軟體的成分日益增加[1]。隨著裝備投入、訓練使用時間的增加，軟體故障已經越來越多地暴露出對裝備效能、維護、恢復的制約[2]。軟體維護也越來越體現出其重要性，國外對裝備中軟體保障問題非常重視[3]。美國從20世紀80年代已開始大規模研究軟體保障問題，而我國軟體保障研究才開始起步[4]。

　　1 軟體維護定義

　　軟體維護，是指軟體產品已經交付使用之後，為糾正錯誤、改進效能或其他屬性或使產品適應改變了的環境而進行的修改活動。

　　按性質不同，一般將軟體維護劃分為如下四類：

　　1.1 糾錯性維護

　　使用者在使用軟體時仍會發現在前期的測試中沒有揭露的軟體系統中的潛在錯誤，診斷和改正這些錯誤的過程稱為糾錯性維護。

　　1.2 適應性維護

　　由於作業系統或編譯系統的升級，為了使軟體能適應新的環境而引起的程式修改活動。

　　1.3 完善性維護

　　在軟體的使用過程中，為了滿足使用者新的需求而增加或擴充軟體功能的活動。

　　1.4 預防性維護

　　為了提高軟體的可維護性和可靠性，為未來的進一步改進打下基礎而修改軟體的活動。

　　2 軟體維護的國內現狀

　　隨著武器裝備複雜性的增長，出現了使用和保障費用高，戰備完好性差等問題。軟體維護逐漸引起各國軍方和工業界的普遍注意，不同程度地開展了軟體維護、保障性分析及設計，國內目前處於起步階段。

　　2.1 可維護性差

　　在裝備的研製過程中，國內企業的軟體開發大都採用“手工作坊”式的開發方式，由軟體開發設計人員自行設計、自行編碼、自行測試、自行包維護，甚至完全由一個人完成。

　　近幾年剛剛有所改觀。山於無法對軟體開發過程進行有效的監督與管理，軟體的可理解性、可測試性、可修改性差，使得軟體出現故障後只能由開發者自行維護，其它人員難以介入。軟體人員“跳槽”後對軟體維護影響極大，甚至可以使軟體維護工作處於癱瘓狀態（軟體無人能讀懂，無人能維護）。

　　在軟體需要進行維護的`時候，才發現設計的時候不重視可維護性，存在軟體程式碼無註釋、軟體文件與程式碼小符、開發時用的開發工具無處查詢、某些模組無原始碼等問題。

　　2.2 可靠性低

　　計算機軟體已經成為武器裝備中最重要的一部分[5]。但據目前統計，軟體可靠性整整比硬體低一個數量級。有的系統故障統計結果是軟體故障佔系統故障的60%～70%。軟體儘管與硬體小同，在使用過程中沒有磨損，沒有消耗，但軟體是有生命的，在使用過程中更需要維護，需要保障。

　　2.3 軟體維護的力度小夠

　　鑑於軟體的自身特點，任何軟體都難以做得盡善盡美。據美軍統計：軟體即使在裝備研製過程中經過了嚴格的工程化及測試後仍會有多達15%的缺陷遺留在軟體之中未被暴露。

　　美軍1997年的軟體保障費用高達200億美元，每行程式碼的年維護費用為110美元，為裝備正常使用提供了保證。

　　目前國內關於軟體維護經費如何處理處於一個非常時期，軍品審定價時完全不考慮軟體經費，軟體維護經費更無從談起。而現在軟體使用階段的保障經費已遠遠超過了軟體的購置經費，並非一筆可有可無的經費。只有軟體研製經費，沒有軟體維護經費，是嚴重的比例失調。缺乏經費己成為嚴重製約軟體保障的因素，這對於開展軟體維護工作十分不利。

　　3 軟體維護的重要性

　　軟體維護對軟體可靠性產生的影響，比硬體維護對硬體可靠性產生的影響要大。主要表現在兩個方面，一是透過正確的糾錯性維護可以使軟體可靠性不斷地提高，失效率不斷下降。而硬體進行維護後，可靠性一般不會提高（多為恢復到某一定值），失效率也不會下降。另一方面，軟體維護對軟體全系統產生的關聯影響較大，而硬體維護對全系統產生的關聯影響相對較小。可見軟體維護性對於軟體而言，是一個比硬體維護性更重要的屬性，而且軟體維護性與軟體可靠性相一致。

　　軟體與硬體不同，在使用過程中沒有磨損、沒有消耗。但軟體是有生命的，在使用過程中是需要維護、需要保障的。軟體維護是軟體生命週期的最後一個階段，處於系統投入生產性執行以後的時期。軟體維護是軟體生命週期中耗費最多，延續時間最長的活動。通常大型軟體的維護成本是開發成本的4倍左右，軟體開發組織中60%以上的人力用於軟體維護。要想延長軟體生命，充分發揮軟體的作用，必須搞好軟體維護。例如，在沙漠風暴作戰行動中，E-3空中預警飛機作為戰場保障的中介部分，起著跟蹤所有戰場空中目標並指揮攔截的作用，被譽為神眼。而在當時戰場上電磁訊號太多造成擁塞，以致E-3的能力大打折扣，不得不對E-3雷達中的許多軟體進行修改。為此，專門派出軟體保障組直接進行軟體維修，使E-3預警機的雷達軟體在96小時內得到修正後完成飛行檢測並投入使用。

　　4 如何做好軟體維護

　　4.1 軟體維護準備工作

　　當接到軟體維護任務時，第一步需要做的準備工作為熟悉所維護的軟體功能、軟體架構體系。熟悉所維護軟體功能的主要方法是閱讀該軟體的設計文件或軟體使用維護說明書[6]。

　　熟悉軟體功能的同時，我們還需要熟悉軟體的架構體系。熟悉軟體架構體系就等於站在軟體維護的最高點。在面向物件分析與設計技術流行的今天，沒有理解軟體的架構體系，要去維護軟體是很困難的。

　　4.2 如何收集並解決軟體問題

　　裝備定型後，技術狀態固，軟體的技術狀態也同時固化。當出現軟體質量問題時，大部分承製單位都以能不改就不改，必須改再說的思想去解決軟體質量問題，原因是因為一旦軟體出現問題，大部分都需要修改原始碼，哪怕幾個字元的修改都需要重新編譯並生成新的版本，導致了軟體技術狀態的變更。基於這種情況，如何既保證技術狀態的管理又能有效解決部隊的軟體問題是值得我們深思的。我個人認為應從以下幾方面進行：

　　4.2.1 承製單位應建立軟體維護部門

　　軟體維護部門隸屬於售後部門，與部隊建立一種簡單而有效的機制。對部隊反映的軟體問題予以登記，“軟體維護登記表”內容包括：編號，日期，反映單位，反映人，聯絡電話，問題描述，記錄員，軟體維護人員，單位領導，軟體更改單號等內容。

　　4.2.2 軟體修改保持原有程式碼的編碼規範

　　為了保證編碼規範的統一性，必須保持所維護的軟體的編碼規範。如果整個系統中沒有統一的編碼規範，那至少在模組的層次上的編碼規範應該是統一的，因為一般情況下都是一個人負責開發一個模組。

　　4.2.3 軟體修改後進行測試

　　為確保對軟體的修改並沒有破壞它的核心功能，好的做法用一個測試用例來重新測試，這樣就可以知道當你修改其他部分時有沒有再引入bug。有時，可能只是對程式碼做了一點修改，並要把它提交到原始碼控制系統中，但是執行整個的迴歸測試卻會花費很長的時間。這種情況下，我們可以取出迴歸測試集的一個子集進行一次“冒煙測試”，即只覆蓋了迴歸測試集中的一部分測試用例的測試。每次修改後都應進行“冒煙測試”。

　　4.2.4 保留修改記錄

　　如何清楚記錄軟體維護過程，正確統計所做的維護工作的工作量並做好後續的相關文件更新是非常重要的。軟體維護人員到現場維護完成後，應填寫“軟體維護記錄單”，其包括

　　軟體維護類別：糾錯性維護，適應性維護，完善性維護，預防性維護；

　　難度係數：範圍0.1-1；

　　維護日期：開始到結束的日期；

　　完成工時：最小單位為1小時；

　　完成人：完成該軟體維護的程式設計師；

　　反映單位：具體的單位名稱和地址；

　　問題描述：對反映問題的具體描述；

　　解決措施：描述解決問題的步驟和方法，儘量描述到需要修改系統多層架構中哪一層的哪個方法；

　　軟體更改單號：若存在軟體更改的情況，則填寫對應的軟體更改的編號；

　　程式設計師建議：該解決方案有什麼要注意或不能滿足的地方，現有系統的不合理性等；