趙淑君

(北京遙感設(shè)備研究所，北京 100854)

0 引言

通常策劃軟件項(xiàng)目開發(fā)工作時(shí)需要根據(jù)項(xiàng)目的特點(diǎn)選擇一種適合的軟件開發(fā)生命周期模型(以下簡(jiǎn)稱軟件開發(fā)模型)，按照軟件開發(fā)模型的要求開展軟件開發(fā)活動(dòng)。彈上軟件的開發(fā)過(guò)程亦如此。彈上軟件作為導(dǎo)彈的大腦和核心，其研發(fā)過(guò)程的控制對(duì)軟件質(zhì)量乃至整個(gè)武器系統(tǒng)的質(zhì)量起到至關(guān)重要的作用，因此選擇一種合適的軟件開發(fā)模型十分必要。

1 傳統(tǒng)軟件開發(fā)模型簡(jiǎn)介

傳統(tǒng)的軟件開發(fā)模型有原型、瀑布型、迭代型/增量型[1]等。

原型一般用于軟件項(xiàng)目早期，此時(shí)需求不明確，需要快速形成軟件產(chǎn)品，但對(duì)軟件產(chǎn)品可靠性要求不高，通常用于功能演示驗(yàn)證；瀑布模型一般用于需求明確的項(xiàng)目，是一種理想的文檔驅(qū)動(dòng)型的開發(fā)方式；迭代型/增量型介于二者之間，但是軟件需求的變更需要受到嚴(yán)格的控制，每一次迭代都類似一個(gè)瀑布過(guò)程，整個(gè)開發(fā)周期比較長(zhǎng)，管理活動(dòng)消耗時(shí)間較多。

近年來(lái)提出的敏捷開發(fā)方法，在許多行業(yè)和領(lǐng)域得到了廣泛的關(guān)注和應(yīng)用[2-4]，它的本質(zhì)是一種“關(guān)注產(chǎn)品本身勝于過(guò)程和文檔”的觀點(diǎn)，它的4句宣言“個(gè)體和交互勝過(guò)過(guò)程和工具、可以工作的軟件勝過(guò)面面俱到的文檔、客戶合作勝過(guò)合同談判、響應(yīng)變化勝過(guò)遵循計(jì)劃”[5]強(qiáng)調(diào)開發(fā)者之間以及開發(fā)者與客戶之間面對(duì)面地交流，強(qiáng)調(diào)以人為核心，強(qiáng)調(diào)快速響應(yīng)，它的開發(fā)特點(diǎn)類似于迭代型或者增量型，但是敏捷開發(fā)方法更側(cè)重于給出了很多操作層面的方法和步驟，如用戶故事、每日站會(huì)、沖刺、回顧、燃盡圖、結(jié)對(duì)編程等[6]，但它對(duì)文檔的要求相對(duì)較弱，通常在高層級(jí)描述系統(tǒng)結(jié)構(gòu)和行為以及關(guān)鍵的設(shè)計(jì)原理[7]，編制“剛剛夠(just enough)”的文檔[8]，該方法在安全關(guān)鍵軟件和軍用軟件開發(fā)實(shí)踐中也獲得了一些有益探索[9-10]。

2 彈上軟件的特點(diǎn)

彈上軟件有其專門的應(yīng)用場(chǎng)景，既遵循軟件的一般研制規(guī)律，必須經(jīng)過(guò)系統(tǒng)分析與設(shè)計(jì)(用戶需求開發(fā))、軟件需求分析、軟件設(shè)計(jì)和實(shí)現(xiàn)、單元測(cè)試/單元集成測(cè)試、配置項(xiàng)測(cè)試、軟硬件集成測(cè)試、驗(yàn)收交付和運(yùn)行維護(hù)等多個(gè)階段[11]，同時(shí)又具有自己的特點(diǎn)，主要表現(xiàn)在3個(gè)方面。

(1) 需求不穩(wěn)定

武器裝備有其自身的研制規(guī)律，需要?jiǎng)?chuàng)新和突破，研制過(guò)程是一個(gè)不斷探索發(fā)現(xiàn)、不斷深化認(rèn)識(shí)的過(guò)程，因此軟件需求必然也是一個(gè)循序漸進(jìn)、不斷迭代和完善的過(guò)程，很難一次明確到位。在這個(gè)過(guò)程中由于需求不斷變化，軟件技術(shù)狀態(tài)始終在一個(gè)動(dòng)態(tài)的變化當(dāng)中，需求變更呈現(xiàn)常態(tài)化，特別是整個(gè)研制階段的初期和中期，為了系統(tǒng)功能的改進(jìn)和性能的優(yōu)化，軟件經(jīng)常需要不斷地修改和完善。頻繁的更改不僅影響軟件的質(zhì)量也影響開發(fā)的進(jìn)度。

(2) 對(duì)缺陷“零容忍”

彈上設(shè)備任務(wù)具有一次性的特點(diǎn)，軟件質(zhì)量好壞直接關(guān)系到任務(wù)的成敗，因此對(duì)于軟件缺陷“零容忍”。因?yàn)橐粋€(gè)小小的軟件疏忽就會(huì)導(dǎo)致任務(wù)的失敗，造成非常嚴(yán)重的損失和后果，這不是通常軟件“bug”修復(fù)就可以的。通常彈上軟件具有很高的安全關(guān)鍵等級(jí)，“一次做對(duì)”、“零缺陷”是彈上軟件質(zhì)量的最高目標(biāo)，也是彈上軟件過(guò)程控制的最高目標(biāo)。

(3) 研制節(jié)點(diǎn)緊迫

彈上軟件作為武器系統(tǒng)的一部分，它的研制進(jìn)程與武器系統(tǒng)的研制進(jìn)度緊密相關(guān)，經(jīng)常要求研制節(jié)點(diǎn)“后墻不倒”。時(shí)間緊，任務(wù)重，對(duì)軟件質(zhì)量是一個(gè)極大的挑戰(zhàn)。因此，在需求不穩(wěn)定不明確的情況下如何有效開展軟件研制工作，從而既保證軟件質(zhì)量又要滿足武器系統(tǒng)的進(jìn)度要求，就成為一個(gè)引人思考的問(wèn)題。

彈上軟件的上述特點(diǎn)表明，其面臨一個(gè)矛盾，需求很難一次明確，但是又要求產(chǎn)品可靠性高，原型和瀑布型無(wú)法滿足要求，采用迭代型/增量型又因?yàn)轭l繁的需求變更使得軟件過(guò)程控制復(fù)雜繁瑣，無(wú)法滿足進(jìn)度要求，敏捷開發(fā)中對(duì)于文檔需求的弱化同樣也不能滿足彈上軟件開發(fā)的文檔標(biāo)準(zhǔn)[12]要求。

本文針對(duì)彈上軟件的上述特點(diǎn)，提出了一種基于原型+快速瀑布模型的彈上軟件開發(fā)模型，解決在需求不穩(wěn)定的情況下，通常的軟件開發(fā)模型無(wú)法同時(shí)滿足質(zhì)量和進(jìn)度要求的問(wèn)題，并對(duì)該模型的各個(gè)階段主要工作內(nèi)容和要求進(jìn)行了闡述。該模型同樣適用于具有類似特點(diǎn)的其他軟件。

3 彈上軟件開發(fā)模型組成

3.1 模型組成框圖

彈上軟件開發(fā)模型的組成如圖1所示。

說(shuō)明：一次軟件開發(fā)過(guò)程以完成軟件驗(yàn)收交付活動(dòng)作為結(jié)束標(biāo)志，后續(xù)運(yùn)行維護(hù)(包含武器系統(tǒng)聯(lián)試)過(guò)程中，如果需要進(jìn)行軟件修改，執(zhí)行軟件更改升級(jí)過(guò)程。

基于原型+快速瀑布模型的彈上軟件開發(fā)模型，包括：原型功能驗(yàn)證、快速需求固化、快速設(shè)計(jì)優(yōu)化、快速代碼優(yōu)化、軟件內(nèi)部測(cè)試、軟硬件集成測(cè)試/三方評(píng)測(cè)和驗(yàn)收交付等階段。

(1) 原型功能驗(yàn)證：是通過(guò)需求分析、設(shè)計(jì)、實(shí)現(xiàn)和測(cè)試驗(yàn)證的快速迭代過(guò)程形成初步的軟件產(chǎn)品，并放到所屬系統(tǒng)中完成初步驗(yàn)證，以便引出正式的軟件需求，也即開發(fā)軟件需求的過(guò)程。

(2) 快速需求固化：是根據(jù)原型功能驗(yàn)證結(jié)果，將軟件需求進(jìn)行固化，形成正式軟件需求文檔的過(guò)程。

(3) 快速設(shè)計(jì)優(yōu)化：是根據(jù)正式的軟件需求文檔，對(duì)軟件初步設(shè)計(jì)方案進(jìn)行優(yōu)化，形成正式軟件設(shè)計(jì)方案的過(guò)程。

(4) 快速代碼優(yōu)化：是根據(jù)正式的設(shè)計(jì)方案對(duì)代碼的實(shí)現(xiàn)進(jìn)行優(yōu)化的過(guò)程。

(5) 軟件內(nèi)部測(cè)試：是對(duì)優(yōu)化后的代碼進(jìn)行詳細(xì)的單元測(cè)試、單元集成測(cè)試和配置項(xiàng)測(cè)試的過(guò)程。

(6) 軟硬件集成測(cè)試/三方評(píng)測(cè)：軟硬件集成測(cè)試是將軟件置于所屬系統(tǒng)與硬件及外部設(shè)備或其他軟件進(jìn)行集成測(cè)試以確定軟硬件及本軟件與其他軟件之間的工作是否相協(xié)調(diào)一致的過(guò)程，同時(shí)在此階段還要視需要開展軟件第三方評(píng)測(cè)工作并最終通過(guò)軟件第三方評(píng)測(cè)。

(7) 驗(yàn)收交付：是將通過(guò)軟硬件集成測(cè)試和三方評(píng)測(cè)的軟件完成正式驗(yàn)收交付的過(guò)程。

3.2 原型功能驗(yàn)證

原型功能驗(yàn)證階段通過(guò)快速形成軟件產(chǎn)品對(duì)軟件功能進(jìn)行驗(yàn)證來(lái)開發(fā)軟件需求。

彈上軟件作為導(dǎo)彈武器系統(tǒng)的一部分，其功能和性能與硬件及系統(tǒng)耦合非常緊密，軟件需求很難在項(xiàng)目初期獨(dú)立明確出來(lái)，即使描述很明確，軟件嚴(yán)格按照需求實(shí)現(xiàn)了，由于武器系統(tǒng)本身的復(fù)雜性，未知不確定因素很多，也容易出現(xiàn)“正確地做了(you built it right)”[13-14]但做的產(chǎn)品不滿足武器系統(tǒng)使用要求的情況。

原型功能驗(yàn)證的指導(dǎo)思想就是通過(guò)原型開發(fā)方法，快速形成一個(gè)原型產(chǎn)品，在接近真實(shí)的系統(tǒng)中進(jìn)行驗(yàn)證，通過(guò)驗(yàn)證的結(jié)果來(lái)修正軟件需求、設(shè)計(jì)和實(shí)現(xiàn)，直到該原型產(chǎn)品初步滿足系統(tǒng)使用要求。這是一個(gè)引出需求、開發(fā)需求的過(guò)程，往往需要任務(wù)提出方和任務(wù)承制方緊密合作，需要需求分析、設(shè)計(jì)、實(shí)現(xiàn)和功能驗(yàn)證的快速反復(fù)迭代。在功能驗(yàn)證過(guò)程中原始需求不斷被修改和完善，經(jīng)過(guò)多次驗(yàn)證后逐漸趨于收斂，直至軟件產(chǎn)品初步滿足系統(tǒng)要求。

與通常的增量或迭代模型不同，在該過(guò)程中對(duì)文檔的要求是比較弱的，對(duì)中間形成的工作產(chǎn)品的配置管理要求也是比較弱的，對(duì)測(cè)試驗(yàn)證的全面性和系統(tǒng)性的要求也是比較弱的。在首次迭代時(shí)，形成需求、設(shè)計(jì)和測(cè)試驗(yàn)證的初始文檔，之后每一次快速迭代過(guò)程中，需記錄本次迭代過(guò)程中需求的變化、軟件設(shè)計(jì)更改情況以及驗(yàn)證用例設(shè)計(jì)和執(zhí)行情況。這些文件側(cè)重于對(duì)需求、設(shè)計(jì)和測(cè)試驗(yàn)證內(nèi)容的記述，對(duì)標(biāo)準(zhǔn)化和規(guī)范化要求較弱，通常和源代碼一起在開發(fā)庫(kù)中進(jìn)行管理，進(jìn)行非正式的控制。

在此過(guò)程中整個(gè)項(xiàng)目團(tuán)隊(duì)需要經(jīng)常討論或進(jìn)行非正式的評(píng)審，討論的內(nèi)容包括技術(shù)需求、實(shí)現(xiàn)方案、如何驗(yàn)證以及驗(yàn)證數(shù)據(jù)和結(jié)果的分析等，一次討論往往涵蓋需求、設(shè)計(jì)、實(shí)現(xiàn)和測(cè)試驗(yàn)證整個(gè)過(guò)程的內(nèi)容。

總之，本階段的重點(diǎn)在于快速引出需求，快速進(jìn)行功能驗(yàn)證，確保提出的軟件需求是符合實(shí)際的，滿足大系統(tǒng)功能要求的，并且與整個(gè)系統(tǒng)的功能是協(xié)調(diào)一致的，是確保軟件人員不但“正確地做了(you built it right)”并且還“做了正確的東西(you built the right thing)”[13-14]的重要一環(huán)，因?yàn)樵诖_保需求正確的基礎(chǔ)上談軟件的質(zhì)量才有意義。

3.3 快速需求固化

當(dāng)原型軟件產(chǎn)品開發(fā)完畢，功能得到初步驗(yàn)證后，需求逐步明晰并趨于穩(wěn)定，自本階段開始，將進(jìn)入嚴(yán)格的軟件工程化控制流程，包括文檔的質(zhì)量控制、配置管理(包括基線控制、更改控制等)、評(píng)審管理等。

快速需求固化階段將軟件需求進(jìn)行固化，形成正式的軟件需求。這一環(huán)節(jié)非常重要，明確了需求即明確了軟件項(xiàng)目的范圍和邊界，作為后續(xù)工作的基礎(chǔ)以及驗(yàn)證軟件是否滿足要求的依據(jù)。具體工作分為用戶需求固化和軟件需求固化2部分。

(1) 用戶需求固化

任務(wù)提出方根據(jù)前期功能驗(yàn)證的結(jié)果，以文檔的形式快速固化用戶需求，編制軟件任務(wù)書，任務(wù)書從用戶的角度描述對(duì)軟件的要求，包括軟件的運(yùn)行場(chǎng)景，詳細(xì)的功能、性能和外部接口要求，特別是在原型功能驗(yàn)證階段不作為考慮重點(diǎn)的安全性和可靠性要求要明確提出來(lái)，另外管理要求以及一些設(shè)計(jì)約束包括開發(fā)環(huán)境要求、交付的形式、里程碑評(píng)審節(jié)點(diǎn)、進(jìn)度控制要求等應(yīng)一并明確出來(lái)。任務(wù)提出方將自己最關(guān)注的內(nèi)容明確地提出來(lái)，有助于任務(wù)承制方準(zhǔn)確理解用戶要求，進(jìn)而正確實(shí)現(xiàn)它。

(2) 軟件需求固化

任務(wù)承制方根據(jù)軟件任務(wù)書，進(jìn)行需求分析，結(jié)合初級(jí)軟件產(chǎn)品功能驗(yàn)證結(jié)果，從承制方的角度理解每一條用戶需求，并向下分解，逐級(jí)細(xì)化為可實(shí)現(xiàn)的軟件需求，編制軟件需求規(guī)格說(shuō)明文檔。

在本階段，任務(wù)提出方和承制方應(yīng)充分溝通，以便清晰、準(zhǔn)確、無(wú)二義性地描述出真實(shí)的需求，這2份文檔分別由任務(wù)提出方及承制方編寫，同時(shí)進(jìn)行評(píng)審，便于評(píng)審專家對(duì)這2份文檔的一致性和協(xié)調(diào)性進(jìn)行審查，從而確保任務(wù)提出方和承制方對(duì)于需求的理解是協(xié)調(diào)一致的，承制方準(zhǔn)備實(shí)現(xiàn)的功能正是提出方所需要的，并且以文檔的形式固化了下來(lái)。通過(guò)評(píng)審的文檔納入受控庫(kù)進(jìn)行管理，如果后續(xù)有需求變更需要嚴(yán)格按照更改控制流程進(jìn)行。

3.4 快速設(shè)計(jì)優(yōu)化

快速設(shè)計(jì)優(yōu)化階段依據(jù)固化的軟件需求對(duì)軟件設(shè)計(jì)方案進(jìn)行優(yōu)化，形成最優(yōu)的正式軟件設(shè)計(jì)方案。

在功能驗(yàn)證階段，需求是比較模糊的，最初的設(shè)計(jì)方案與當(dāng)時(shí)的認(rèn)識(shí)有關(guān)，功能驗(yàn)證過(guò)程中漸進(jìn)地修改代碼，使之越來(lái)越接近使用要求，但是最初的產(chǎn)品架構(gòu)和模塊劃分與固化后的軟件需求相比，不一定是最優(yōu)的了。因此需要對(duì)前期的軟件架構(gòu)進(jìn)行重新審視，視需要進(jìn)行優(yōu)化和調(diào)整，并對(duì)模塊劃分合理性進(jìn)行檢查，按照內(nèi)聚性強(qiáng)且耦合性弱的原則，對(duì)不符合要求的模塊重新進(jìn)行設(shè)計(jì)優(yōu)化，確保軟件架構(gòu)和模塊劃分對(duì)于固化后的需求來(lái)講已經(jīng)是最優(yōu)的，形成軟件設(shè)計(jì)說(shuō)明文檔。

軟件設(shè)計(jì)說(shuō)明文檔需進(jìn)行正式評(píng)審，確保設(shè)計(jì)方案相對(duì)于需求的合理性，相對(duì)于實(shí)現(xiàn)的最優(yōu)性，即確保設(shè)計(jì)方案是能實(shí)現(xiàn)軟件需求的最優(yōu)方案。該文檔通過(guò)評(píng)審后納入受控庫(kù)進(jìn)行管理，如果后續(xù)有設(shè)計(jì)變更需要嚴(yán)格按照更改控制流程進(jìn)行。

3.5 快速代碼優(yōu)化

快速代碼優(yōu)化階段依據(jù)評(píng)審后的軟件設(shè)計(jì)說(shuō)明文檔對(duì)已形成的軟件代碼進(jìn)行優(yōu)化，使之與設(shè)計(jì)相一致，并使之符合編程規(guī)范。

代碼優(yōu)化包括2部分：一是依據(jù)設(shè)計(jì)優(yōu)化進(jìn)行架構(gòu)和模塊實(shí)現(xiàn)方面的優(yōu)化，對(duì)代碼進(jìn)行修改完善，使之與優(yōu)化后的設(shè)計(jì)保持一致；二是編程語(yǔ)言規(guī)范上的優(yōu)化。在功能驗(yàn)證階段，側(cè)重于快速編寫出代碼進(jìn)行功能驗(yàn)證，對(duì)代碼規(guī)范性要求不是關(guān)注的重點(diǎn)，本階段需求和設(shè)計(jì)已經(jīng)相對(duì)固化，對(duì)軟件編程的規(guī)范性要求就提到了議事日程。代碼完成后應(yīng)采用靜態(tài)分析工具進(jìn)行代碼規(guī)則檢查，對(duì)發(fā)現(xiàn)的編程規(guī)則問(wèn)題及時(shí)進(jìn)行修正。

經(jīng)過(guò)優(yōu)化的代碼還缺乏系統(tǒng)而全面的內(nèi)部測(cè)試，可在開發(fā)庫(kù)進(jìn)行管理。

3.6 軟件內(nèi)部測(cè)試

軟件內(nèi)部測(cè)試階段的任務(wù)是對(duì)優(yōu)化后的代碼進(jìn)行系統(tǒng)全面的內(nèi)部測(cè)試，以驗(yàn)證“你正確地做了(you built it right)”。

軟件內(nèi)部測(cè)試包括單元測(cè)試、單元集成測(cè)試和配置項(xiàng)測(cè)試3個(gè)活動(dòng)[15]。

在功能驗(yàn)證階段，為了快速收斂需求，經(jīng)歷的是需求-實(shí)現(xiàn)-功能驗(yàn)證的不斷迭代過(guò)程，主要就是壓縮了系統(tǒng)全面的內(nèi)部測(cè)試時(shí)間，這是考慮到內(nèi)部測(cè)試是測(cè)試軟件實(shí)現(xiàn)的正確性，在需求還不十分確定的情況下，先把明確的需求固化下來(lái)才是最緊迫的事情，過(guò)于強(qiáng)調(diào)軟件實(shí)現(xiàn)正確性是意義不大的。

在本階段，需求已經(jīng)明確，設(shè)計(jì)和實(shí)現(xiàn)也得到優(yōu)化，到了驗(yàn)證軟件產(chǎn)品本身正確性的時(shí)機(jī)。系統(tǒng)全面的內(nèi)部測(cè)試是保證軟件質(zhì)量的重要環(huán)節(jié)，首先應(yīng)進(jìn)行全面的測(cè)試用例設(shè)計(jì)，亦可繼承之前在功能驗(yàn)證階段的部分測(cè)試用例，對(duì)優(yōu)化后的軟件代碼在單元級(jí)、單元和單元之間以及配置項(xiàng)級(jí)進(jìn)行測(cè)試，針對(duì)發(fā)現(xiàn)的問(wèn)題修改軟件代碼并完成回歸測(cè)試，分別形成單元測(cè)試報(bào)告、單元集成測(cè)試報(bào)告和配置項(xiàng)測(cè)試報(bào)告，通過(guò)相應(yīng)的同行或正式評(píng)審后與源代碼一起納入受控庫(kù)管理，如后續(xù)有代碼更改需要嚴(yán)格按照更改控制流程進(jìn)行并完成回歸測(cè)試。

3.7 軟硬件集成測(cè)試及第三方評(píng)測(cè)

軟硬件集成測(cè)試的任務(wù)是將軟件置于所屬系統(tǒng)環(huán)境進(jìn)行集成測(cè)試，以驗(yàn)證“你做了正確的東西(you built the right thing)”。

本階段由任務(wù)提出方主導(dǎo)，任務(wù)承制方參與，將通過(guò)內(nèi)部測(cè)試的源代碼作為系統(tǒng)的一部分，與硬件及系統(tǒng)中其他設(shè)備或軟件進(jìn)行集成測(cè)試，驗(yàn)證軟件是否滿足軟件任務(wù)書的要求，以及是否與整個(gè)系統(tǒng)相適應(yīng)。形成系統(tǒng)整機(jī)測(cè)試報(bào)告或軟硬件集成測(cè)試報(bào)告。

在此過(guò)程中，通常根據(jù)軟件的安全關(guān)鍵等級(jí)要求，任務(wù)承制方將軟件提交第三方評(píng)測(cè)，并配合評(píng)測(cè)單位進(jìn)行第三方評(píng)測(cè)，對(duì)軟硬件集成測(cè)試和三方評(píng)測(cè)中發(fā)現(xiàn)的問(wèn)題一并修改，完成相應(yīng)的回歸測(cè)試，直至所有問(wèn)題均得到解決，并嚴(yán)格按照更改控制流程完成受控庫(kù)中相應(yīng)文檔和代碼的更改升級(jí)。通過(guò)內(nèi)部測(cè)試、軟硬件集成測(cè)試和三方評(píng)測(cè)的源代碼和全部文檔入產(chǎn)品庫(kù)。

3.8 驗(yàn)收交付

驗(yàn)收交付階段的主要任務(wù)是進(jìn)行軟件驗(yàn)收準(zhǔn)備并完成軟件驗(yàn)收交付[16]。

在此階段，任務(wù)承制方需要編制軟件研制總結(jié)報(bào)告等管理性文檔，提交驗(yàn)收申請(qǐng)，從產(chǎn)品庫(kù)中提取正式軟件產(chǎn)品完成裝機(jī)，并由任務(wù)提出方組織完成軟件的驗(yàn)收測(cè)試，通過(guò)驗(yàn)收測(cè)試的軟件通常隨硬件交付。

至此一個(gè)彈上軟件的開發(fā)周期完成。交付后如果需要對(duì)軟件進(jìn)行修改，則執(zhí)行嚴(yán)格的軟件更改控制過(guò)程。

4 文檔和配置管理要求

彈上軟件開發(fā)需要遵循的頂層標(biāo)準(zhǔn)GJB2786A[11],GJB438B[12],GJB5235[17]等對(duì)軍用軟件文檔和軟件配置管理都做了嚴(yán)格的要求，特別是GJB438B詳細(xì)規(guī)定了軟件文檔編制的要求，因此無(wú)論采用什么開發(fā)模型，都不能隨意減少文檔的輸出數(shù)量或降低對(duì)文檔質(zhì)量的要求，本模型也不例外。本模型強(qiáng)調(diào)軟件文檔質(zhì)量的重要性，區(qū)別在于根據(jù)彈上軟件特點(diǎn)對(duì)文檔的產(chǎn)生和控制時(shí)機(jī)進(jìn)行適應(yīng)性調(diào)整，避免了產(chǎn)生大量頻繁變動(dòng)的正式文檔以及不必要的配置管理、正式評(píng)審等成本的增加，這樣既提高了開發(fā)效率，又能通過(guò)高的軟件文檔質(zhì)量和必要的配置管理活動(dòng)來(lái)保證武器系統(tǒng)研制周期較長(zhǎng)情況下的軟件可繼承性，減少對(duì)人的過(guò)度依賴。

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

在軟件開發(fā)過(guò)程中，既尊重軟件的特殊性，又遵循和順應(yīng)軟件研制的一般規(guī)律，才能交出高質(zhì)量的軟件，最大程度地減少質(zhì)量問(wèn)題的發(fā)生。本文提出的軟件開發(fā)模型，針對(duì)大部分彈上軟件的特點(diǎn)，強(qiáng)調(diào)了研制前期快速功能驗(yàn)證的必要性，中期需求固化和設(shè)計(jì)實(shí)現(xiàn)優(yōu)化的必要性，以及后期全面系統(tǒng)的測(cè)試驗(yàn)證的必要性。本模型適用于大部分彈上軟件的開發(fā)過(guò)程，如果軟件有特殊要求或者需求很明確或?qū)|(zhì)量要求不高的應(yīng)用場(chǎng)合，則應(yīng)按照軟件的實(shí)際情況選擇其他更為合適的開發(fā)模型。同樣，本模型亦同樣適用于需求不穩(wěn)定但對(duì)軟件質(zhì)量要求高的其他類軟件的開發(fā)活動(dòng)。