高秉亞，黃 強(qiáng)，王高飛

(1.空軍駐滬寧地區(qū)軍事代表室， 南京210039； 2.南京電子技術(shù)研究所， 南京210039)

0 引言

隨著武器裝備作戰(zhàn)使用性能的不斷提升、信息化程度的不斷提高，使得大量的軟件技術(shù)運(yùn)用到裝備系統(tǒng)中，軟件的規(guī)模越來越大，復(fù)雜度越來越高，武器裝備的很多功能需要由軟件來實(shí)現(xiàn)，很多性能需要靠軟件來提升，因此軟件質(zhì)量在全系統(tǒng)質(zhì)量中所占的砝碼越來越重。我國裝備軟件工程化管理起步較晚，十年前，還普遍將軟件視為硬件的一個(gè)附屬部分，沒有將軟件列為型號配套表，作為產(chǎn)品來單獨(dú)控制，缺乏完整的指標(biāo)體系和嚴(yán)格的測評驗(yàn)證手段，尚未建立完整的質(zhì)量保證體系。目前，軟件開發(fā)與管理大多仍為“自設(shè)計(jì)、自編碼、自測試”手工作坊模式，造成軟件質(zhì)量普遍偏低、開發(fā)效率低、技術(shù)和進(jìn)度風(fēng)險(xiǎn)大、維護(hù)困難和開發(fā)費(fèi)用高等一系列問題，給部隊(duì)的作戰(zhàn)和保障帶來了很大困難，其根本原因就是技術(shù)和質(zhì)量管理薄弱，工程化管理水平低［1］。軍代表對軟件質(zhì)量監(jiān)督也缺少有效的手段和方法，工作很被動。可喜的是，目前國家、軍隊(duì)對軟件質(zhì)量控制越來越重視，相繼出臺了一系列標(biāo)準(zhǔn)和法規(guī)，旨在抓好軟件全壽命周期，特別是研制開發(fā)階段的軟件產(chǎn)品質(zhì)量控制［2］。

1 軟件研制存在的主要問題及對策

1.1 需求分析不到位、功能基線欠準(zhǔn)確

在整個(gè)軟件研制過程中，軟件需求分析是在明確軟件分配需要后的一個(gè)核心環(huán)節(jié)。在軟件需求分析過程中應(yīng)明確軟件需要達(dá)到的性能指標(biāo)，并將需求作為軟件設(shè)計(jì)的約束條件，為軟件設(shè)計(jì)提供依據(jù)，為軟件測試提供測試準(zhǔn)則和驗(yàn)收標(biāo)準(zhǔn)［3］。軟件需求分析是軟件研制的起點(diǎn)，也是項(xiàng)目實(shí)施的關(guān)鍵點(diǎn)。據(jù)統(tǒng)計(jì)數(shù)據(jù)顯示，在查找出的軟件錯誤中，屬于需求分析和軟件設(shè)計(jì)的錯誤約占64%，屬于程序編寫錯誤的僅占36%。另據(jù)有關(guān)統(tǒng)計(jì)，軟件產(chǎn)品存在的不完整性、不正確性，其80%以上是需求分析錯誤所致，而且由于需求分析錯誤或偏差造成根本性的功能問題尤為突出。

1.1.1 存在的問題

在軟件需求分析方面，大部分軍工企業(yè)存在以下兩點(diǎn)問題:(1)需求分析和確定過程不嚴(yán)謹(jǐn)、不深入、功能基線不具體，分配基線欠準(zhǔn)確;(2)與用戶的溝通力度有限，需求分析不細(xì)致，沒有準(zhǔn)確理解或描述用戶的真實(shí)意圖。

1.1.2 案例分析

案例1:2009年12月，一種武器系統(tǒng)制導(dǎo)雷達(dá)在外場靶試中發(fā)現(xiàn)信號處理相關(guān)處理/融合插件在低溫環(huán)境下有時(shí)不能正常啟動，系統(tǒng)任務(wù)可靠性大幅下降。其故障機(jī)理為:該處理模塊中的某橋片為CMOS芯片，在低溫條件下運(yùn)行速度會下降，如出現(xiàn)偶發(fā)的異常數(shù)據(jù)，會導(dǎo)致數(shù)據(jù)無法及時(shí)發(fā)送，造成橋片內(nèi)部PCI緩沖區(qū)堵塞，從而PCI接口進(jìn)入死鎖狀態(tài)。對應(yīng)解決措施為:修改程序，開啟PCI緩沖區(qū)保護(hù)機(jī)制，問題可以復(fù)現(xiàn)，并得到驗(yàn)證。從該案例剖析，得出結(jié)論是:軟件設(shè)計(jì)師對武器裝備工作環(huán)境需求不明確，對橋片的工作機(jī)理和保護(hù)機(jī)制了解不全面。

案例2:1996年4月，阿麗亞娜5發(fā)射升空后6 s，在3 700 m高度爆炸，造成重大損失。其主要原因是承制方對軍方的需求存在理解偏差，軟件中的技術(shù)指標(biāo)和設(shè)計(jì)錯誤引起故障。

1.1.3 對策

1)軟件承制單位必須加強(qiáng)同軍方及其代表的全面、全過程溝通，并將其制度化。積極主動邀請用戶參加各階段的需求變更確認(rèn)和評審，而不是消極應(yīng)付，從需求識別確認(rèn)、需求跟蹤與反跟蹤、需求變更控制、需求版本控制［2］四個(gè)方面，無限逼近用戶的真實(shí)需求，確保軟件需求分析內(nèi)容正確、完整、一致和可驗(yàn)證，需求描述無歧義、可追溯、可修改。

2)提高研發(fā)團(tuán)隊(duì)對軟件需求"重要性"意識的培養(yǎng)，確定軟件承制單位的高層管理者、軟件工程組、軟件配置管理組、軟件質(zhì)量保證組與用戶以及相互之間的有效溝通和無縫對接。在工程研制過程中，設(shè)計(jì)人員要克服一接到任務(wù)就匆忙著手編寫程序的習(xí)慣，而是先要在明確需求的前提下，準(zhǔn)確分析系統(tǒng)的需求，并逐步細(xì)化對軟件的要求，編制出符合用戶要求的軟件設(shè)計(jì)規(guī)范、軟件需求規(guī)格說明、接口規(guī)格說明等文檔，提交用戶評審，以達(dá)到需求的共識。

3)督促軟件承制單位建立健全軟件質(zhì)量管理體系，制定本單位的軟件標(biāo)準(zhǔn)過程，特別是軟件需求甄別和確定過程。以軟件需求分析質(zhì)量為突破口，提出軟件全過程質(zhì)量要求，配置相應(yīng)的資源，落實(shí)相應(yīng)的質(zhì)量保證活動，不斷提高軟件過程質(zhì)量保證能力，從源頭杜絕管理和設(shè)計(jì)缺陷。

1.2 配置管理水平低、項(xiàng)目設(shè)置不合理

軟件配置是指軟件開發(fā)過程中，構(gòu)成軟件產(chǎn)品的各種文檔、程序及其數(shù)據(jù)的優(yōu)化組合。該組合中的每一個(gè)元素被稱為配置中的一個(gè)配置項(xiàng)［4］。通俗地講，軟件生存周期各個(gè)階段活動的產(chǎn)物經(jīng)審批后即可稱之軟件配置項(xiàng)。

軟件配置項(xiàng)要素包含有:軟件需求分析文檔、軟件概要設(shè)計(jì)文檔、軟件詳細(xì)設(shè)計(jì)文檔、軟件實(shí)體、軟件測試文檔、用戶支持文檔等，包括與合同、過程、計(jì)劃和產(chǎn)品有關(guān)的文檔和資料;源代碼、目標(biāo)代碼和可執(zhí)行代碼;相關(guān)產(chǎn)品包括:軟件工具、庫內(nèi)的可重構(gòu)軟件、外購軟件及顧客提供的軟件等。

軟件配置管理是一種標(biāo)識、組織和控制修改的技術(shù)，要對軟件生存期內(nèi)各階段的文檔、實(shí)體和最終產(chǎn)品的演化及變更進(jìn)行管理，簡單而言就是管理軟件的變化，目的是將錯誤減少至最低，并提高效率。軟件配置管理貫穿軟件生命周期，是開發(fā)高質(zhì)量軟件必不可缺的，是軟件質(zhì)量管理的精髓。

軟件配置管理的主要任務(wù)包括:識別和確定配置項(xiàng)、定義配置項(xiàng)和版本的標(biāo)識規(guī)則、制定控制變更的權(quán)限和實(shí)施步驟、記錄、跟蹤配置項(xiàng)的變更狀態(tài)、驗(yàn)證配置項(xiàng)的正確性和完整性、進(jìn)行版本管理和發(fā)行管理。應(yīng)有文檔化的配置項(xiàng)識別準(zhǔn)則，根據(jù)準(zhǔn)則進(jìn)行配置項(xiàng)識別，明確配置項(xiàng)列表，給予配置項(xiàng)唯一的編號、名稱，并標(biāo)明一些重要屬性，如受控級別、存儲位置、負(fù)責(zé)人、源代碼語言等。相對于硬件配置，軟件的“配置”包括更多的內(nèi)容并具有易變性。

1.2.1 存在的問題

1)在軟件開發(fā)時(shí)，不可能一步到位，變更是不可避免的。由于配置管理經(jīng)驗(yàn)少、水平低，加劇了軟件工程之間的混亂，造成軟件設(shè)計(jì)缺陷多、質(zhì)量差、開發(fā)效率低。主要原因是變更前沒有協(xié)調(diào)一致的有效分析或變更控制管理不嚴(yán)格，其次是文檔質(zhì)量較差，“三庫”管理不到位，內(nèi)部測評開展不充分，內(nèi)部測評發(fā)現(xiàn)的缺陷與定型測評發(fā)現(xiàn)的缺陷出現(xiàn)倒掛現(xiàn)象。

2)配置項(xiàng)識別準(zhǔn)則不完善，項(xiàng)目設(shè)置不合理。普遍存在配置項(xiàng)過大或過小而不能較好適應(yīng)軟件配置管理中的版本控制、變更控制、技術(shù)狀態(tài)及成本控制要求，并對軟件開發(fā)各階段產(chǎn)生的各種文檔的管理缺乏一致性和完整性驗(yàn)證的手段。

1.2.2 案例分析

在一種型號雷達(dá)的軟件研制過程中，由于研制進(jìn)度和管理經(jīng)驗(yàn)的缺乏，在軟件集成測試和定型測評中，發(fā)現(xiàn)各配置項(xiàng)與軟件需求、各配置項(xiàng)之間存在不一致的問題數(shù)十項(xiàng);其次，配置項(xiàng)設(shè)置過大(以雷達(dá)分系統(tǒng)為單位進(jìn)行劃分)，沒有設(shè)置合理的關(guān)鍵、重要軟件單元(CSU)，造成管理和技術(shù)狀態(tài)控制上的困難，也大幅增加了軟件開發(fā)、測試、測評的成本。

1.2.3 對策

1)督促承制單位制定配置項(xiàng)管理計(jì)劃，嚴(yán)格落實(shí)“三庫”管理。制定軟件“三庫”管理規(guī)定，建立相應(yīng)的軟件配置管理組織，對整個(gè)研制過程中的軟件實(shí)施不同管理等級的控制。將早期開發(fā)并通過內(nèi)部測評的軟件納入軟件開發(fā)庫管理，將通過階段正式測評的軟件納入軟件受控庫管理，將最終通過定型測評的軟件納入軟件產(chǎn)品庫管理。嚴(yán)格入庫/出庫控制、訪問控制、更動控制、版本控制、配置審核、配置報(bào)告、庫間轉(zhuǎn)換、維護(hù)規(guī)程等，嚴(yán)把文檔審查、代碼審查、階段評審、測試驗(yàn)證等關(guān)口，并將評價(jià)意見和改進(jìn)建議的歸零/整改與否，作為“三庫”管理的重要方面。

2)加強(qiáng)和完善軟件版本管理，建立“版本樹”管理機(jī)制。版本控制是所有配置項(xiàng)管理系統(tǒng)的核心功能。標(biāo)識一個(gè)配置項(xiàng)變更(如需求變化或設(shè)計(jì)更改)的最好方法就是版本(樹)，它的主要作用是記錄和追蹤文件的變更，如文件更改的內(nèi)容、時(shí)間、原因和更改審批人員等。版本(樹)不僅記錄了配置項(xiàng)當(dāng)前狀態(tài)，為后續(xù)開發(fā)提供依據(jù)，而且還可以根據(jù)版本追溯以前的狀態(tài)，避免未經(jīng)授權(quán)的訪問和修改，避免因舊版本丟失/無法重現(xiàn)、更改出錯或原設(shè)計(jì)人員離職等導(dǎo)致無法研制后果。此外，版本管理可以有效解決不同設(shè)計(jì)師之間的溝通、協(xié)調(diào)問題，減少錯誤。特別是需重點(diǎn)控制版本升級的時(shí)機(jī):當(dāng)出現(xiàn)大的變更時(shí)，如需求變化，導(dǎo)致軟件需求文檔需要增加新功能時(shí)，主版本號升級(由V 1.＊＊升級到V 2.＊＊);當(dāng)出現(xiàn)小的變更時(shí)，如局部的修改完善，主版本號不變，次版本號升級(由V＊＊.0升級到V＊＊.1);

3)優(yōu)化完善配置項(xiàng)識別準(zhǔn)則，合理確定配置項(xiàng)，突出軟件質(zhì)量監(jiān)督重點(diǎn)，提高配置項(xiàng)管理效率。軟件配置項(xiàng)的通俗定義:軟件中可以獨(dú)立進(jìn)行開發(fā)的一個(gè)實(shí)體，包括程序、數(shù)據(jù)及其相應(yīng)的文檔和說明。所以，系統(tǒng)配置項(xiàng)可按功能進(jìn)行逐級細(xì)化、按層次標(biāo)識，如分系統(tǒng)(第一層標(biāo)識)、子系統(tǒng)(第二層標(biāo)識)、功能模塊(第三層標(biāo)識)……，過大過細(xì)兩個(gè)極端均不利于配置項(xiàng)的管理。以一種雷達(dá)系統(tǒng)軟件配置項(xiàng)劃分為例，其數(shù)據(jù)管理分系統(tǒng)的能力調(diào)度軟件及其組成模塊在表1(配置項(xiàng)劃分粒度過大)中未被有效標(biāo)識出來;通過優(yōu)化完善(采納軍代表審查意見)，在表2中配置項(xiàng)的劃分就比較合理，功能模塊大小適中，更切合技術(shù)狀態(tài)控制和質(zhì)量監(jiān)督的實(shí)際。

表1 不合理的軟件配置項(xiàng)(過大)組成表

表2 合理的軟件配置項(xiàng)組成表

4)建議搭建或提倡承制單位使用“基于需求基線的軟件管理系統(tǒng)(BSCM)”，建立BSCM數(shù)學(xué)模型，以解決軟件配置管理過程中軟件配置項(xiàng)一致性、完整性和可追溯性等問題。

2 扭轉(zhuǎn)質(zhì)量監(jiān)控觀念，實(shí)施軟硬件捆綁把關(guān)

2.1 形勢分析

雖然國家、軍隊(duì)對軟件工程化管理和軟件研制質(zhì)量控制越來越重視，要求承研、承制單位建立、健全軟件質(zhì)量管理體系，并將軟件作為裝備及其配套產(chǎn)品的一部分納入型號研制計(jì)劃，嚴(yán)格按照軟件質(zhì)量和工程化要求抓好軟件全生存周期管理;要求軍代表從設(shè)計(jì)源頭入手，狠抓軟件文檔審查、軟件研制階段評審、軟件技術(shù)狀態(tài)控制(“三庫”的建立和管理)，確保軟件文檔質(zhì)量符合要求、軟件測試充分有效、軟件技術(shù)狀態(tài)受控，最終確保軟件質(zhì)量。但是，由于慣性思維和出于成本考慮，大部分企業(yè)又把軟、硬件變成了“兩張皮、兩條線”，在質(zhì)量、進(jìn)度管理上不盡一致，依然是硬件優(yōu)先。主要表現(xiàn)在以下三點(diǎn):(1)在研制計(jì)劃管理上不盡協(xié)調(diào)，軟件開發(fā)和質(zhì)量保證計(jì)劃滯后于硬件計(jì)劃;(2)軟、硬件質(zhì)量管理力度不同，仍然是硬件強(qiáng)、軟件弱，沒有真正將軟件視為產(chǎn)品;(3)對軟件的資源投入仍然不夠，在人力、物力、財(cái)力上均有較大欠缺等，結(jié)果就是硬件更強(qiáng)、軟件更弱。此外，還會造成二者技術(shù)狀態(tài)協(xié)調(diào)和銜接上的困難，不利于全系統(tǒng)/整機(jī)技術(shù)狀態(tài)的控制。

相對于企業(yè)軟件工程化管理水平低的現(xiàn)狀，軍代表開展軟件質(zhì)量監(jiān)督也存在一些困難。(1)方法、手段有限，根基薄弱;(2)一線軍代表中軟件人員嚴(yán)重匱乏;(3)扭轉(zhuǎn)質(zhì)量監(jiān)督理念需要一個(gè)過程。這三個(gè)方面決定了軍代表開展軟件質(zhì)量監(jiān)督的難度很大，需要適應(yīng)新形勢、加緊補(bǔ)課，積極探索研究開展軟件質(zhì)量監(jiān)督的新方法、新手段。

2.2 軟硬件捆綁把關(guān)探討

將軟、硬件在計(jì)劃、質(zhì)量和成本管理上捆綁起來，二者并重。以立項(xiàng)論證為起點(diǎn)，在型號裝備研制的各個(gè)階段乃至全生命周期內(nèi)，真正將軟件視為產(chǎn)品，納入型號研制計(jì)劃和型號配套表，建立完整的指標(biāo)體系和完備的測評考核平臺。同步制定全過程研制計(jì)劃、同步開展過程質(zhì)量控制和驗(yàn)收把關(guān)、同步進(jìn)行成本審核控制，兩者缺一不可，并將其“原則化、制度化”，徹底打破“硬件優(yōu)先”的慣例，從根本上解決軟、硬件研制的管理“兩張皮、兩條線”的問題，促進(jìn)軟件質(zhì)量監(jiān)督和工程化水平邁上一個(gè)新的臺階。同時(shí)，實(shí)施軟、硬件捆綁把關(guān)，亦可解決兩者的技術(shù)狀態(tài)控制的協(xié)調(diào)性問題，有利于整機(jī)技術(shù)狀態(tài)控制，確保整機(jī)研制質(zhì)量。

1)嚴(yán)格按照軟件質(zhì)量和工程化管理要求，同步抓好軟/硬件立項(xiàng)評審、需求評審、概要/初步設(shè)計(jì)、詳細(xì)設(shè)計(jì)、集成測試 /初樣試驗(yàn)、軟件測評/硬件鑒定和定型等重點(diǎn)環(huán)節(jié)，做到同步轉(zhuǎn)階段、同步凍結(jié)技術(shù)狀態(tài)，同步開展定型試驗(yàn)、同步開展價(jià)值工程和成本分析審查，同步設(shè)計(jì)定型。

2)軍代表依據(jù)軟硬件捆綁把關(guān)的原則，對照各個(gè)研制階段的軟件成果，明確軟件研制階段監(jiān)控重點(diǎn)，如表3所示，以點(diǎn)帶面，抓好軟件全生命周期的質(zhì)量監(jiān)督。目前，已將該表格落實(shí)應(yīng)用于部分在研重點(diǎn)雷達(dá)型號中，成效明顯。

表3 軟件研制階段監(jiān)控重點(diǎn)

3 結(jié)束語

鑒于當(dāng)前軍用軟件面臨的工程化管理水平低、軟件產(chǎn)品質(zhì)量低的形勢，軍代表應(yīng)加快研究軟件質(zhì)量監(jiān)督的相關(guān)方法，加強(qiáng)對策研究，積極探索軟件質(zhì)量監(jiān)督的新手段、新方法，按照系統(tǒng)監(jiān)督、突出重點(diǎn)、預(yù)防為主、防檢結(jié)合的原則，切實(shí)抓好軟件需求分析和設(shè)計(jì)評審、文檔審簽、配置管理、定型測評等重點(diǎn)環(huán)節(jié)，抓好里程碑節(jié)點(diǎn)控制，盡快提升軟件研制質(zhì)量和工程化管理水平。

［1］ 阮 鐮，陸民燕，韓峰巖，等.裝備軟件質(zhì)量和可靠性管理［M］.北京:國防工業(yè)出版社，2006.Ruan Lian，Lu Minyan，Han Fengyan，et al.The software quality and reliability management［M］.Beijing:National Defense Industry Press，2006.

［2］ 何新貴.GJB5000《軍用軟件能力成熟度模型》實(shí)施指南［M］.北京:國防工業(yè)出版社，2004.He Xingui.GJB5000 military software capability maturity model implementaiton guide［M］.Beijing:National Defense Industry Press，2004.

［3］ 常云麗，鄔欣明，鄭 威.軍用軟件需求分析研究［J］.火力與指揮控制，2013，38(1):126-128.Chang Yunli，Wu Xinming，Zheng Wei.Research on military software requirement analysis［J］.Fire Control＆ Command Control，2013，38(1):126-128.

［4］ 王珍英.配置管理在軟件項(xiàng)目管理中的應(yīng)用［J］.計(jì)算機(jī)系統(tǒng)應(yīng)用，2008，17(6):101-104，61.Wang Zhenying.Application of configuration management in software project management［J］.Computer Systems ＆ Applications，2008，17(6):101-104，61.