一種彈上軟件開發(fā)生命周期模型

趙淑君

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

0 引言

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

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

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

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

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

2 彈上軟件的特點

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

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

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

(2) 對缺陷“零容忍”

彈上設備任務具有一次性的特點，軟件質(zhì)量好壞直接關(guān)系到任務的成敗，因此對于軟件缺陷“零容忍”。因為一個小小的軟件疏忽就會導致任務的失敗，造成非常嚴重的損失和后果，這不是通常軟件“bug”修復就可以的。通常彈上軟件具有很高的安全關(guān)鍵等級，“一次做對”、“零缺陷”是彈上軟件質(zhì)量的最高目標，也是彈上軟件過程控制的最高目標。

(3) 研制節(jié)點緊迫

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

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

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

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

3.1 模型組成框圖

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

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

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

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

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

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

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

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

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

(7) 驗收交付：是將通過軟硬件集成測試和三方評測的軟件完成正式驗收交付的過程。

3.2 原型功能驗證

原型功能驗證階段通過快速形成軟件產(chǎn)品對軟件功能進行驗證來開發(fā)軟件需求。

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

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

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

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

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

3.3 快速需求固化

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

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

(1) 用戶需求固化

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

(2) 軟件需求固化

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

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

3.4 快速設計優(yōu)化

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

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

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

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

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

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

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

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

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

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

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

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

3.7 軟硬件集成測試及第三方評測

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

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

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

3.8 驗收交付

驗收交付階段的主要任務是進行軟件驗收準備并完成軟件驗收交付[16]。

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

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

4 文檔和配置管理要求

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

5 結(jié)束語

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