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

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

0 引言

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

1 軟件研制存在的主要問(wèn)題及對(duì)策

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

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

1.1.1 存在的問(wèn)題

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

1.1.2 案例分析

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

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

1.1.3 對(duì)策

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

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

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

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

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

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

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

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

1.2.1 存在的問(wèn)題

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

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

1.2.2 案例分析

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

1.2.3 對(duì)策

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

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

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

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

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

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

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

2.1 形勢(shì)分析

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

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

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

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

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

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

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

3 結(jié)束語(yǔ)

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

［1］ 阮 鐮，陸民燕，韓峰巖，等.裝備軟件質(zhì)量和可靠性管理［M］.北京:國(guó)防工業(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］.北京:國(guó)防工業(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.