一種彈上軟件開發生命周期模型

趙淑君

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

0 引言

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

1 傳統軟件開發模型簡介

傳統的軟件開發模型有原型、瀑布型、迭代型/增量型[1]等。

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

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

2 彈上軟件的特點

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

(1) 需求不穩定

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

(2) 對缺陷“零容忍”

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

(3) 研制節點緊迫

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

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

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

3 彈上軟件開發模型組成

3.1 模型組成框圖

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

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

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

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

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

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

(4) 快速代碼優化：是根據正式的設計方案對代碼的實現進行優化的過程。

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

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

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

3.2 原型功能驗證

原型功能驗證階段通過快速形成軟件產品對軟件功能進行驗證來開發軟件需求。

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

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

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

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

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

3.3 快速需求固化

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

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

(1) 用戶需求固化

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

(2) 軟件需求固化

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

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

3.4 快速設計優化

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

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

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

3.5 快速代碼優化

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

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

經過優化的代碼還缺乏系統而全面的內部測試，可在開發庫進行管理。

3.6 軟件內部測試

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

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

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

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

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

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

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

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

3.8 驗收交付

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

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

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

4 文檔和配置管理要求

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

5 結束語

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