關于武器裝備軟件問題產生原因分析

任喜錄，胡 勇

(解放軍63961部隊，北京 100012)

關于武器裝備軟件問題產生原因分析

任喜錄，胡 勇

(解放軍63961部隊，北京 100012)

為了提高武器裝備軟件工程化水平，在對武器裝備設計定型軟件測評工作中發現的軟件問題進行分析、歸納的基礎上，總結提出了武器裝備軟件問題產生的7種可能原因：裝備軟件指標可操作性差、軟件需求分析不充分、軟件設計說明內容不詳實、軟件編程不規范、軟件文檔評審不嚴謹、軟件研制單位內部軟件測試不落實、軟件研制過程的軟件工程化管理水平不高，闡述了武器裝備軟件問題產生原因的各種表現，并通過具體軟件問題實例對每一個軟件問題產生原因進行了進一步的說明，這對從根本上減少或避免裝備軟件問題的產生具有促進作用。

武器裝備;軟件問題;產生原因

0 引言

隨著裝備信息化程度的不斷提高，軟件在裝備中的規模和復雜程度越來越大，軟件在裝備中的作用越來越重要，信息化裝備的功能和性能越來越多地由軟件來實現，因此，信息化裝備中軟件的質量對信息化裝備完成任務成敗的影響也越來越大。為了保證定型裝備中的軟件質量，陸軍裝備在設計定型時由必須進行基地試驗、部隊試驗的基礎上增加了軟件測評考核項目。自這時起作者開始從事陸軍裝備設計定型軟件測評工作，在這期間參加并完成了幾十個型號的設計定型軟件測評任務，在軟件測試過程中發現了數千個軟件問題，其中有大量的致命問題和嚴重問題。這些問題在裝備定型前被發現并得到有效解決，保證了這些新研裝備軟件質量的提高[1]。

在軟件測評過程中發現，有的新研裝備軟件中存在的問題很多，多達上千個。雖然裝備設計定型時進行軟件測評是一種減少或避免軟件問題的有效手段，但這不能從根本上減少或避免新研裝備軟件問題的產生。為了找到解決在新研裝備的研制過程中減少或避免軟件問題產生的根本手段，作者對以往發現的軟件問題產生原因進行了分析總結。

1 軟件問題產生原因分析

軟件生命周期始于裝備型號論證，經過一系列階段之后進入編程階段，實現軟件編程。程序中存在的軟件問題并不一定是由編碼所引起的，有的軟件問題是由編程階段之前的某個階段存在的問題所引起的，裝備軟件測試模型見圖1。通過對以往軟件測試發現的軟件問題的原因進行分析、總結，可將軟件測評過程中發現的軟件問題產生的原因歸納為7個方面：

1)裝備軟件指標可操作性差；

2)軟件需求分析不充分；

3)軟件設計內容不詳實；

4)軟件編程不規范；

5)軟件產品評審不嚴謹；

6)研制單位內部軟件測試不落實；

7)軟件研制過程的工程化管理水平不高。

圖1 裝備軟件測試W模型

1.1 裝備軟件指標可操作性差

裝備型號論證分為作戰使用要求論證和戰術技術指標論證兩個方面。裝備型號論證的主要工作是確定裝備型號的作戰使命、任務及作戰對象，確定裝備型號的系統組成、主要戰術技術指標與作戰使用要求等。裝備型號論證的產品是《武器裝備研制總要求》，為開展裝備型號研制提供依據。

在設計定型軟件測評發現的軟件問題中，有些軟件問題是由于裝備的軟件指標可操作性差造成的，這為研制高水平的武器裝備留下了隱患。裝備軟件指標可操作性差的表現為：作戰使用需求不明，戰技指標不細，總體技術方案不清。

例1：在某型節點交換設備的研制總要求中對節點交換設備接入戰術互聯網的戰術技術指標要求是“具有接入戰術互聯網數據傳輸功能”，僅僅這么一句籠統要求，對接入戰術互聯網的組網類型有哪些沒有要求。節點交換設備接入戰術互聯網的組網類型實際可有多種：

1)直接接入戰術互聯網的節點交換設備的數字終端間通過戰術互聯網能進行數據傳輸；

2)直接接入戰術互聯網的節點交換設備的數字終端與戰術互聯網的數字終端之間能進行數據傳輸；

3)非直接接入戰術互聯網的節點交換設備的數字終端之間通過戰術互聯網進行數據傳輸；

4)非直接接入戰術互聯網的節點交換設備的數字終端與戰術互聯網的數字終端之間能進行數據傳輸。

從滿足作戰使用角度來講，上述所有組網類型均應實現。在進行設計定型軟件測評時發現：研制方由于難于實現其中的某些接入戰術互聯網的組網類型而發生了隨意剪裁指標要求情況，當軟件測評時作者對此提出軟件實現存在問題時，研制方以研制總要求對接入戰術互聯網的組網類型沒有明確要求為由，找出各種理由解釋他們這樣做的合理性，并堅稱他們這樣做滿足研制總要求的要求。

例2：在某型節點交換設備的研制總要求中對節點交換設備的信道監測指標要求是“支持鏈路狀態監測功能”。對鏈路狀態監測的約束沒有要求。因此，在型號研制時，研制方只從功能達到的角度實現了這一功能，未考慮實現方法是否符合作戰使用。研制方對鏈路狀態監測功能的實現方式是：節點交換設備通過不可控、周期性地發送握手數據來監測鏈路狀態。采用這種鏈路狀態監測方式的后果是：在作戰使用時，不論是在不要求電磁靜默使用狀態下，還是要求在電磁靜默使用狀態下，只要節點交換設備開機工作，節點交換設備就使作為中繼信道的通信設備——超短波電臺、短波電臺、高速數據電臺、無線接力機、衛星通信地面收發設備等開始周期性地向外發射電磁波信號以傳輸監測握手數據；這樣，在需要電磁靜默時就有可能造成電磁暴露。

1.2 軟件需求分析不充分

軟件需求分析階段的主要任務是依據研制總要求和軟件研制任務書對軟件的功能、性能、數據和接口等要求逐項細化，通過分析深入地、全面地理解研制總要求和軟件研制任務書對軟件的要求，編寫形成《軟件需求規格說明》，為下一步開展軟件設計提供依據。

在設計定型軟件測評過程中發現的軟件問題中，有些軟件問題是由于軟件需求分析不充分造成的。軟件需求分析不充分的表現為：《軟件需求規格說明》的內容沒有完全覆蓋研制總要求中關于軟件方面的要求或軟件研制任務書的要求，沒有覆蓋隱含需求；《軟件需求規格說明》中的要求不全面、不清晰、不準確。

例3：在某探測系統的研制總要求中對GPS定位定向儀的定向指標要求是“定向精度：≤Xmil(基線長度Z米)”，同時，在研制總要求中明確規定了系統的作戰使用條件“探測陣列的傾斜角≤Y°”。GPS定位定向儀的研制單位在進行軟件需求分析時沒有全面分析研究研制總要求的各項戰技指標要求，因此，對GPS定位定向儀的定向精度滿足要求的條件只考慮了被定向物體處于水平狀態下是否滿足要求，未考慮被定向物體處于作戰使用要求允許的非水平狀態下是否滿足要求。軟件測評時，作者在對其他定型試驗單位已通過測試的GPS定位定向儀進行軟件測試時發現：當被定向物體處于研制總要求允許的非水平狀態下工作時，GPS定位定向儀的尋北精度嚴重超出指標要求，并且，當被定向物體處于在研制總要求允許的較大傾斜姿態時GPS定位定向儀不能進行尋北。探測系統在實際使用時被定向物體處于水平狀態的情況較少，大多數情況下是處于非水平狀態下使用。作為探測系統重要組成部分的GPS定位定向儀所存在的只能在被定向物體處于水平狀態下正常工作、在非水平狀態下尋北精度嚴重超出指標要求或者不能尋北的問題如果不被發現和解決，那么，這樣的探測偵查裝備在作戰時將無法為取得戰爭的勝利起到應有的積極作用。

例4：在某武器系統的研制總要求中對引信的指標要求之一是“炮口可靠保險距離不小于X米”。引信研制單位在進行軟件需求分析時未考慮到炮彈旋轉加速度計信號線開路時引信解除保險對使用安全的影響，未考慮炮彈旋轉加速度計信號線開路時不解除保險這一隱含需求，因此，在引信的軟件需求規格說明文檔中沒有要求炮彈旋轉加速度計信號線開路時不解除保險。軟件測試時作者發現：當炮彈旋轉加速度計信號線開路時引信電保險裝置上電后就解除保險，未能滿足炮彈旋轉加速度達到預定值后解除保險的要求。如果存在這一軟件設計缺陷的引信被裝備到部隊，那么，當發射安裝有炮彈旋轉加速度計信號線開路的引信的炮彈時將有可能發生炮彈在炮口附近爆炸的事故。

1.3 軟件設計內容不詳實

軟件設計通常分軟件概要設計和軟件詳細設計。軟件概要設計是軟件的總體設計或架構設計，軟件詳細設計是確定軟件模塊內部特征和內部詳細執行過程的設計。通過軟件設計編寫形成《軟件設計說明》，為下一步開展軟件編程提供依據。

在設計定型軟件測評過程中發現的軟件問題中，有些軟件問題是由于軟件設計說明內容不詳實造成的。軟件設計內容不詳實的表現為：《軟件設計說明》的內容沒有完全覆蓋《軟件需求規格說明》的要求，《軟件設計說明》的設計內容不全面、不詳細、不準確。

例5：在某顯示控制軟件需求規格說明中對RS-232C接口字節傳輸的要求是：傳輸速率19.2kBPS，字節傳輸格式：起始位1位、數據位8位、奇/偶校驗為奇校驗、停止位2位。研制單位在軟件的詳細設計時對RS-232C接口接收字節處理流程中的字節奇/偶校驗考慮不周，因此，致使按照軟件設計說明編制實現的程序在對RS-232C接口接收字節的奇/偶校驗處理時存在軟件缺陷。軟件測試時作者發現：當顯示控制軟件通過RS-232C接口接收到字節校驗位錯誤的數據幀時，顯示控制軟件發生死機。

例6：在某顯示控制軟件的概要設計中要求：顯示控制軟件能夠將接收到的各種信息疊加到偵察視頻圖象上顯示。研制單位在軟件的詳細設計時從功能實現角度出發僅考慮了將接收到的各種信息以白色、透明顯示方式疊加到偵察視頻圖象的深色部分顯示情況，因此，致使按照軟件設計說明編制實現的程序在實現信息疊加到偵察視頻圖象上顯示時未能滿足在各種灰度的偵察視頻圖象上清晰顯示的要求。軟件測試時作者發現：當疊加信息的偵察視頻圖象位置也為白色時被疊加的信息無法看見，影響系統的正常使用。

1.4 軟件編程不規范

軟件編程階段的主要任務是依據《軟件設計說明》按指定的編程語言、采用結構化編程方法、以與軟件詳細設計完全一致的方式完成編程。

在設計定型軟件測評過程中發現的軟件問題中，有些軟件問題是由于軟件編程不規范造成的。軟件編程不規范的表現為：程序沒有完全覆蓋《軟件設計說明》，程序的規范性、安全性、可靠性、可維護性等指標不滿足裝備軟件相關管理規定的要求。

例7：在武器系統研制時有的軟件研制單位編制的程序結構非常復雜，函數圈復雜度非常大，高達200；源程序注釋率很低，低至3%，不滿足注釋率不低于20%的要求；單元規模過大，大至數千行，不滿足重要軟件單元規模不超過100行，一般軟件單元規模不超過200行的要求；編程方式還是“手工作坊式”生產方式，即對于一個獨立功能軟件的開發從軟件需求分析到軟件實現仍是由一個軟件開發人員完成，未按軟件需求分析、軟件設計、軟件編程分工進行軟件開發，因此，導致編制的程序存在各種意想不到的軟件缺陷，軟件的可維護性、可擴充性、可移植性差。

1.5 軟件產品評審不嚴謹

軟件產品評審作為軟件驗證和確認的重要手段，是一種排除軟件缺陷的有效機制。按照軟件生存周期組織進行軟件產品評審，可以及時發現和排除軟件產品存在的缺陷或錯誤，防止在下一階段蔓延和擴大，保證軟件產品質量。

在設計定型軟件測評過程中發現的軟件問題中，有些軟件問題是由于軟件產品評審不嚴謹造成的。軟件產品評審不嚴謹的表現為：軟件產品評審準備不充分，評審會議時間短致使對軟件產品審查不充分，評審會專家構成不合理、代表性不強，審查意見落實不到位。

例8：在已經過評審的某武器系統的跟蹤測角裝置軟件需求規格說明中，對發射接收機與跟蹤測角裝置通信協議的要求是通過串行通信進行信息傳輸時要以含有幀頭、幀長度、信息體、校驗字節和幀尾的幀格式進行傳輸，而設計的通信協議中對發射接收機與跟蹤測角裝置之間進行握手的信息格式和握手應答信息格式是只有一個字節的信息體，沒有幀頭、幀長度、校驗字節和幀尾，這明顯不符合通信協議對信息傳輸格式的要求，卻通過了評審。

1.6 研制單位內部軟件測試不落實

根據軟件開發生存周期研制單位內部軟件測試可分為單元測試、集成測試、配置項測試、系統測試，研制單位內部軟件測試的主要目的是驗證軟件是否滿足軟件研制任務書、軟件需求規格說明、軟件設計說明等文檔所規定的要求，盡可能早、盡可能多地發現軟件中存在的缺陷，為軟件轉入下一階段工作提供依據。

在設計定型軟件測評過程中發現的軟件問題中，有些軟件問題是由于軟件研制單位內部的軟件測試不落實造成的。軟件研制單位內部軟件測試不落實的表現為：軟件測試隊伍不健全，軟件測試人員的軟件測試水平不高，軟件研制過程中未組織軟件測試人員對不同階段開發的程序進行軟件測試。

例9：有些軟件的研制單位在進入設計定型階段時雖然提交了研制單位進行軟件測試的有關文檔，但往往是為了滿足有關軟件質量管理規定要求而撰寫的軟件測試文檔，實際上并未進行內部軟件測試。在對某武器系統的跟蹤測角裝置軟件進行設計定型軟件測評中發現的許多軟件問題都是很容易發現的軟件問題就說明了這一點。譬如：在跟蹤測角裝置與執行同步模塊通信正常時，發送目標坐標信息后跟蹤測角裝置軟件控制顯示的不是“發送成功”，而是“發送失敗”；在非設置狀態下“確認”鍵不是不響應操作，而是響應了確認操作，并發生了顯示屏閃爍；跟蹤測角裝置軟件控制顯示的經度、緯度的單位符號錯誤；當目標坐標信息中的距離值為0時不是不發送目標坐標信息，而是發送不確定的目標坐標信息等。如果研制單位進行了有效的內部軟件測試，那么，這些軟件問題是不難被發現的。

1.7 軟件研制過程的工程化管理水平不高

軟件工程化管理就是要建立一套系統的技術和管理規則，對軟件研制、生產和維護過程實行控制和管理，以保證獲得質量可靠的軟件。

在設計定型軟件測評過程中發現的軟件問題中，有些軟件問題是由于軟件研制過程的軟件工程化管理水平不高造成的。軟件研制過程的軟件工程化管理水平不高的表現為：單位領導對軟件工程化管理工作不重視，軟件工程化管理體系不健全，軟件工程化管理人員職責不明，軟件工程化管理措施未落實。

例10：有些軟件研制單位在軟件開發過程中對軟件過程產品管理不到位，未做到通過對基線的版本控制實現對軟件的版本控制，未做到通過對基線的變更控制實現對軟件的變更控制，未做到通過對基線的管理實現對軟件過程的管理。在設計定型階段提交被測軟件時軟件開發人員對入庫的軟件研制任務書、軟件需求規格說明、軟件設計說明等軟件產品未經變更請求、變更許可、變更實施和變更驗證而隨意進行更改，這對軟件狀態控制和軟件質量的保證帶來很大風險。

2 結束語

作者對于軟件問題產生的原因可從不同角度進行了分析、總結，本文對武器裝備設計定型階段軟件測評時發現的軟件問題產生原因的分析、總結是按照型號論證、軟件需求分析、軟件設計、軟件編程、軟件產品評審、內部軟件測試、軟件工程化管理的線索進行的，在此基礎上將軟件問題產生原因歸納為7個方面：裝備軟件指標可操作性差、軟件需求分析不充分、軟件設計說明內容不詳實、軟件編程不規范、軟件產品評審不嚴謹、軟件研制單位內部軟件測試不落實、軟件研制過程的軟件工程化管理水平不高，并且，對歸納出的每一方面軟件問題原因均通過軟件問題實例進行了說明。

為了促進武器裝備軟件開發質量的進一步提高，作者建議：(1)提高武器裝備型號論證水平，確保軟件指標的描述全面、準確；(2)加強有關軟件開發國軍標的宣貫工作，確保武器裝備軟件開發單位的軟件開發產品規范、詳實、準確；(3)加大對武器裝備軟件開發單位的檢查、監督力度，確保其軟件工程化管理工作得到真正落實。

[1] 張善文,等.軟件測試及其案例分析[M].西安：西安電子科技大學出版社，2012.

Reason Analysis on Problems of Weaponry Software

Ren Xilu, Hu Yong

(63961st Unit of PLA, Beijing 100012, China)

In order to raise the level of software engineering for weapons and military supplies, on the base of analyzing and categorizing the problems during the software testing and evaluation for weaponry design and finalization work, 7 kinds of possible reasons for weaponry software development are summarized in this article: bad operability of the KPIs, incomplete analysis for the requirements, inadequate explanations about the software design, nonstandard software programming, imprecise checking on software documentation, weak implementation of internal software testing and evaluation by developer unit, low level of software engineering management. Furthermore, this article lists the various behaviors of the above different weaponry software problems, and demonstrate the deep reasons of the problems by the practices of software testing and evaluation.

weaponry; software problem; root reason

2016-04-07；

2016-06-21。

任喜錄(1964-)，男，河北定興人，高級工程師，主要從事軟件測評及軟件工程化工作。

1671-4598(2017)02-0110-03

10.16526/j.cnki.11-4762/tp.2017.02.030

TP311.5

A