1.4 軍用軟件生存周期

20世紀60年代末提出軟件工程概念后，人們在探索如何在實施軟件工程的過程中逐步認識到，要得到高質量的軟件，只搞好編程工作是遠遠不夠的，編程之前，還必須進行軟件需求分析和軟件設計，且其質量對最終軟件產品的質量更具有決定作用；而且程序編完之后，還要進行重要性并不次于編程工作，而工作量比編程大得多的軟件測試工作。直到20世紀70年代中期，軟件生存周期的概念才逐漸形成。此后，人們又進一步探索軟件生存周期究竟有哪些過程，以及如何實施這些過程才能取得令人滿意的結果等問題。到了20世紀90年代，才出現了關于軟件生存周期的標準，如IEEE 1074—2006《開發軟件項目生存周期過程》、ISO/IEC 12207—2017《系統和軟件工程 軟件生存周期過程》。隨著軟件工程技術的發展，軟件生存周期過程也在不斷豐富，目前這方面的研究仍在繼續。

如同任何事物一樣，軍用軟件也有孕育、誕生、成長、成熟、衰亡的生存過程，我們稱其為軍用軟件的生存周期。

1.4.1 軟件生存周期

軟件生存周期是由工程中產品生存周期的概念得來的。引入軟件生存周期概念對于軟件生產的管理、進度控制有著非常重要的意義，使軟件生產有相應的模式、流程、工序和步驟。

在GB/T 11457—2006《信息技術 軟件工程術語》中“軟件生存周期”的定義為：“從設計軟件產品開始到產品不能再使用時為止的時間周期。軟件生存周期通常包括需求階段、設計階段、實現階段、測試階段、安裝和驗收階段、運行和維護階段，有時還包括引退階段。”

國家標準GB/T 8566—2007《信息技術 軟件生存周期過程》將軟件生存周期劃分為：可行性研究、項目計劃、需求分析、總體設計、詳細設計、編碼實現（包括單元測試）、集成測試、確認測試、系統運行和維護。

軟件生存周期的各階段有不同的劃分。軟件規模、種類、開發模式、開發環境和開發方法都影響軟件生存周期的劃分。在劃分軟件生存周期階段時，應遵循一定的規則，如各階段的任務應盡可能相對獨立，同一階段各項任務的性質應盡可能相同，從而降低每個階段任務的復雜程度，簡化不同階段之間的聯系，有利于軟件項目開發的組織和管理。

通過歸納，可以將軟件生存周期分為 3 個大的階段，即軟件定義階段，軟件開發階段和軟件維護階段。

1.軟件定義階段

軟件定義階段必須回答的問題是：需要軟件解決的問題是什么？如果不知道問題是什么就試圖解決這個問題，只會白白浪費時間和金錢，最終得出的結果很可能是毫無意義的。軟件定義階段是軟件項目的早期階段，主要是由軟件分析人員和用戶合作，針對有待開發的軟件系統進行分析規劃和規格描述，確定軟件做什么，為今后的軟件開發做好準備。軟件定義時期的任務是了解用戶的需求，確定項目的總體目標，考察和分析項目的可行性，導出實現項目目標應該采取的策略，以及系統必須完成的功能，并估計項目需要的資源和成本，制定工程進度表等。這個時期需要分階段地進行以下工作：

（1）軟件任務立項。軟件項目一般始于任務立項，并需要以立項報告的形式針對項目的名稱、性質、目標、意義和規模做出回答，以此獲得對準備著手開發的軟件系統的概括性描述。

（2）可行性研究。在軟件任務立項報告被批準后，接著需要進行項目可行性分析。這個階段要回答的關鍵問題是：“對于上一個階段所確定的目標有行得通的解決辦法嗎？”為了回答這個問題，系統分析員需要在較抽象的高層次上進行分析和設計，對任務立項階段所確定的目標進行可行性和必要性研究。可行性研究主要從技術可行性、經濟可行性、操作可行性等方面進行分析，尋求一種或多種在技術、經濟、操作和法律等各方面可行的解決方案，對各種可能方案做出必要的成本/效益分析，據此提出可行性分析報告，作為是否繼續進行該項工程的依據。

（3）需求分析。這個階段的任務仍然不是具體地解決問題，而是準確地確定“為了解決這個問題，目標系統必須做什么”，主要是確定目標系統必須具備哪些功能。需求分析要求以用戶需求為依據，從功能、性能、數據、操作等多個方面，對軟件系統給出完整、準確、具體的描述，用于確定軟件規格。其結果將以軟件需求規格說明書的形式提交。軟件需求分析是從軟件定義到軟件開發的關鍵步驟，其結論不僅是今后軟件開發的基本依據，同時也是今后用戶對軟件產品進行驗收的基本依據。

（4）制訂項目計劃。在確定項目可以進行以后，就需要針對項目的開展，從人員、組織、進度、資金、設備等多方面進行合理的規劃，并以項目開發計劃書的形式提交書面報告。項目開發計劃涉及實施項目的各個環節，計劃的合理性和準確性將關系項目的成敗。

2.軟件開發階段

軟件開發階段的任務是設計實現已定義的、并經過需求分析的軟件系統。通常將軟件開發階段劃分為軟件設計、軟件實現和軟件測試3個階段。其中，軟件設計又可分為總體設計和詳細設計，編碼是對軟件的實現。軟件測試又可分為單元測試、集成測試、確認測試和系統測試。將設計和實現分開的目的是在開發初期集中精力搞好軟件結構設計，避免過早地為實現細節分散精力。

（1）總體設計。總體設計是建立系統的總體結構，從總體上對軟件的結構、接口、全局數據結構、數據環境等給出設計說明，并以概要設計說明書的形式提交書面報告，其結果將成為詳細設計與軟件實現的基本依據。模塊是總體設計時的基本元素，因此，總體設計的工作主要體現在模塊的構成與模塊接口等方面。結構化設計中的函數、過程，面向對象設計中的類、對象，它們都是模塊。總體設計時并不需要說明模塊的內部細節，但是需要進行全部的有關它們構造的定義，包括功能特性、數據特征、接口等。模塊的獨立性是一個有關質量的重要技術指標，可以使用模塊的內聚性、耦合度等定性參數對模塊獨立性進行度量。

（2）詳細設計。詳細設計以總體設計為依據。它主要是確定軟件結構中每個模塊的內部細節，為編寫程序提供最直接的依據。詳細設計需要從實現每個模塊功能的程序算法和模塊內部的局部數據結構等細節內容上給出設計說明，并以詳細設計說明書的形式提交書面報告。

（3）編碼。編碼是對軟件的實現，以獲得源程序基本模塊為目標。編碼必須按照詳細設計說明書的要求逐個實現每個模塊的功能。在基于軟件工程的軟件開發過程中，編碼往往只是語言轉譯工作，即把詳細設計中的算法描述語言轉換成某種適當的程序設計語言。

（4）單元測試。為了方便調試，針對基本模塊的單元測試也往往和編碼結合在一起進行。單元測試也以詳細設計說明書為依據，用于檢查每個基本模塊在功能、算法與數據結構上是否符合設計要求。

（5）集成測試。集成測試是根據總體設計中的軟件結構，把經過單元測試的模塊，按照某種選定的集成策略將系統組裝起來，在組裝過程中對程序進行必要的測試。

（6）確認測試。確認測試是以用戶為主體，以需求規格說明書中對軟件的定義為依據，由此對軟件的各項規格進行逐項確認，以確保已經完成的軟件系統與需求規格的一致性。在完成對軟件的驗收后，軟件系統就可以交付使用了，開發人員需要以項目開發總結報告的形式對項目進行總結。

（7）系統測試。系統測試是將已經確認的軟件、硬件等其他元素結合在一起，進行系統的各種集成測試和技術測試。其目的是通過與系統的需求相比較，發現所開發的軟件與用戶需求不符或矛盾的地方。系統測試是根據需求規格說明書來設計測試用例的。

3.軟件維護階段

運行階段的任務是保障軟件的正常運行，并對軟件進行維護。為了排除軟件系統中可能隱含的錯誤，適應用戶需求及系統操作環境的變化，需要繼續對系統進行修改或擴充。為了使系統具有較長的生命力，對于每項維護活動都應準確地記錄下來，作為正式的文檔資料加以保存。在適當的時候要對軟件進行評價，如果經過修改或補充，軟件仍不能適應新的需求，則該軟件就應被新的軟件所替代。

研究軟件生存周期的目的是為了科學、有效地組織和管理軟件的生產，從而使軟件生產更可靠、更經濟。采用軟件生存周期來劃分軟件的工程化開發，使軟件開發分階段依次進行。前一個階段任務的完成是后一個階段工作的前提和基礎，而后一個階段通常將前一個階段提出的方案進一步具體化。每個階段結束之前都要接受嚴格的技術評審和管理評審。采用這種劃分，使得每個階段的工作相對獨立，有利于簡化問題，且便于不同人員分工協作。而且其嚴格的科學的評審制度保證了軟件的質量，提高了軟件的可維護性，從而大大提高了軟件開發的生產率和成功率。

1.4.2 典型生存周期模型

軟件生存周期模型提供了一個框架，以便描述在軟件生存周期內進行軟件開發、操作和維護所需要實施的過程、活動和任務。由于工作對象和范圍的不同，軟件開發人員經驗的差異，所采用的軟件生存周期模型也有所不同。

軟件工程過程沒有規定一個特定的軟件生存周期模型或軟件開發方法，各個軟件開發機構可以為自己的開發項目選擇一種生存周期模型，并將軟件工程過程所包含的各種過程、活動和任務映射到該模型中，也可以選擇和使用軟件開發方法來執行適合于其軟件項目的活動和任務。

美國國家航空航天局（NASA）指出：“在整個 NASA 中，從多年的軟件工程實踐中吸取的一個重要教訓是，沒有一個單一的解決方法能夠解決所有的問題。沒有一個生存周期、分析和設計方法、測試方法、產品評估方法適合于所有的NASA軟件項目。”因此，在實際應用中，應根據具體情況選擇適當的軟件生存周期模型。

在GB/T 8566—2007《信息技術 軟件生存周期過程》中描述了軟件生存周期過程的體系結構，但沒有規定一個特定的生存周期模型或軟件開發方法。該標準指出“采用本標準的各方負責為軟件項目選擇一個生存周期模型，并把本標準所述的過程、活動和任務映射到該模型中。各參與方還有責任選擇和應用軟件開發方法，并執行適合于軟件項目的活動和任務”。

下面介紹幾種典型的軟件生存周期模型。

1.瀑布模型

軍用軟件工程最初采用的軟件設計模型，就是根據GJB 437規定反映生存周期法的瀑布模型，也稱線性順序模型、傳統生存周期模型。該模型提出了軟件開發系統化、順序化的方法。

瀑布模型規定了各項軟件工程活動，包括制訂開發計劃、進行需求分析和說明、軟件設計、程序編碼、測試及運行維護，并且規定了它們自上而下，相互銜接的固定次序，如同瀑布流水，逐級下落。如圖1.1所示。

然而軟件開發的實踐表明，上述各項活動之間并非完全是自上而下，呈線性圖式。實際情況是，每項開發活動均處于一個質量環（輸入—處理—輸出—評審）中。從上一項活動接受本項活動的工作對象，作為輸入；利用這一輸入實施本項活動應完成的內容；給出本項活動的工作成果，作為輸出傳給下一項活動；對本項活動實施的工作進行評審。

只有當其工作得到確認，才能繼續進行下一項活動，在圖1.1中用向下的箭頭表示；否則返工，在圖1.1中用向上的箭頭表示。

軟件維護在軟件生存周期中有它的特點。一方面，維護的具體要求是在軟件投入運行以后提出來的，經過評價，確定變更的必要性，才進入維護工作。另一方面，所謂維護中對軟件的變更仍然要經歷上述軟件生存周期在開發中已經歷過的各項活動。事實上，有人把維護稱為軟件的二次開發，正是出于這種考慮。由于軟件在投入使用以后可能經歷多次變更，為把開發活動和維護活動區別開來，便有了b形的軟件生存周期表示，如圖1.2所示。它與前述的軟件生存周期循環一樣，都是軟件生存周期瀑布模型的變種。

瀑布模型為軟件開發和軟件維護提供了一種有效的管理模式。根據這一模式制訂開發計劃、進行成本預算、組織開發力量，以項目的階段評審和文檔控制為手段有效地對整個開發過程進行指導，從而保證軟件產品及時交付，并達到預期的質量要求。與此同時，瀑布模型在大量的軟件開發實踐中也逐漸暴露出它的缺點。其中最為突出的缺點是該模型缺乏靈活性，特別是無法解決軟件需求本身不明確或不準確的問題。

這些問題的存在會給軟件開發帶來嚴重影響，最終可能導致開發出的軟件并不是用戶真正需要的軟件，并且這一點在開發過程完成后才有所察覺。面對這些情況，無疑需要進行返工或是不得不在維護中糾正需求的偏差。但無論上述哪種情況都必須付出高額的代價，并將為軟件開發帶來不必要的損失。另外，隨著軟件開發項目規模的日益龐大，由于瀑布模型不夠靈活等缺點引發出的上述問題顯得更為嚴重。

為彌補瀑布模型的不足，近年來已經提出了多種其他模型。

2.演化模型

由于在項目開發的初始階段人們對軟件的需求認識常常不夠清晰，因而使得開發項目難于做到一次開發成功，出現返工再開發在所難免。因此，可以先做試驗開發，其目標只是在于探索可行性，弄清軟件需求；然后在此基礎上獲得較為滿意的軟件產品。通常把第一次得到的試驗性產品稱為原型，如圖1.3所示。

演化模型又稱為增量模型。軟件在該模型中是被逐漸開發出來的，開發出一部分，向用戶展示一部分，可使用戶及早看到部分軟件，及早發現問題。或者先開發一個原型軟件，完成部分主要功能，展示給用戶并征求意見，然后逐步完善，最終獲得滿意的軟件產品。該模型具有較大的靈活性，適合于軟件需求不明確，設計方案有一定風險的軟件項目。

演化模型從需求分析開始。軟件開發人員與用戶一起定義待開發軟件系統的總目標，定義需求，確定軟件的工作范圍。然后快速設計軟件中對使用者可見部分的表示，進而建造原型，再讓用戶或客戶評估原型，根據評估結果，修改和細化待開發軟件系統的需求，使之滿足用戶的需求。這個過程是一個迭代的過程。

演化模型的優點是：

（1）演化模型與傳統的軟件生存周期法比較，能夠得到更良好的軟件需求，它不僅能夠處理模糊的需求，而且開發人員與用戶可通過原型充分進行交流。

（2）原型系統可作為培訓環境。它有利于使用戶的培訓和開發同步。

（3）演化模型給用戶提供了機會，以更改用戶原來設想的不盡合理的最終系統。

（4）演化模型可以低風險地開發柔性較大的計算機系統。

（5）演化模型使得開發出來的最終系統更容易維護，對用戶更友好。

（6）演化模型可以降低總的開發費用，縮短開發時間。

演化模型的缺點是：

（1）對于開發人員不熟悉的領域，演化模型可能誤導開發者把系統的次要部分當作主要框架，開發出不切題的原型。

（2）原型迭代不收斂于開發者預定的目標。為了消除錯誤，每次更改使得次要部分越來越大，淹沒了系統的主要部分。

（3）原型過快地收斂于需求集合，使得某些基本方面被忽視。

（4）資源規劃和管理比較困難，隨時更新文檔也會帶來許多麻煩。

（5）長期在原型環境下開發，只注意得到令人滿意的原型，容易遺忘用戶環境與實際客戶環境之間的差別。

3.螺旋模型

對于復雜的大型軟件，開發一個原型往往達不到要求。螺旋模型將瀑布模型與演化模型結合起來，并且加入兩種模型均忽略了的風險分析。

軟件風險是普遍存在于任何軟件開發項目中的實際問題。對于不同的項目，其差別只是風險有大有小而已。在制訂軟件開發計劃時，系統分析員必須回答：項目的需求是什么，需要投入多少資源，以及如何安排開發進度等一系列問題。然而，若要他們當即給出準確無誤的回答是不容易的，甚至幾乎是不可能的，但系統分析員又不可能完全回避這一問題。憑借經驗的估計出發給出初步的設想便難免帶來一定風險。實踐表明，項目規模越大，問題越復雜，資源、成本、進度等因素的不確定性越大，承擔項目所冒的風險也越大。因此，風險是軟件開發不可忽視的潛在不利因素，它可能在不同程度上損害軟件開發過程或軟件產品的質量。軟件風險控制的目標是在造成危害之前，及時對風險進行識別、分析，采取對策，進而消除或減少風險的損害。

螺旋模型沿著螺線旋轉，如圖1.4所示，笛卡兒坐標系的4個象限上分別表達了4個方面的活動。

（1）制訂計劃——確定軟件目標，選定實施方案，弄清項目開發的限制條件。

（2）風險分析——分析評價所選方案，考慮如何識別和消除風險。

（3）實施工程——實施軟件開發。

（4）客戶評估——評價開發工作，提出修正建議。

沿螺線自內向外，每旋轉一圈便開發出更為完善的一個新軟件版本。例如，在第一圈，確定了初步的目標、方案和限制條件以后，轉入第Ⅰ象限，對風險進行識別和分析。如果風險分析表明，需求有不確定性，那么在工程象限（第Ⅳ象限）內，所建的原型會幫助開發人員和客戶，考慮其他開發模型，并對需求做進一步修正。客戶對工程成果做出評價之后，給出修正建議。在此基礎上需要再次計劃，并進行風險分析。在每圈螺線上，風險分析的終點做出是否繼續下去的判斷。假如風險過大，開發者和用戶無法承受，項目有可能終止。在多數情況下沿螺線的活動會繼續下去，自內向外，逐步延伸，最終得到所期望的系統。

如果軟件開發人員對所開發項目的需求已有了較好的理解或較大的把握，則無須開發原型，可采用普通的瀑布模型，這在螺旋模型中可認為是單圈螺線。與此相反，如果對所開發項目的需求理解較差，則需要開發原型，甚至需要不止一個原型的幫助，那就需要經歷多圈螺線。在這種情況下，外圈的開發包含了更多的活動，也可能某些開發采用了不同的模型。

螺旋模型適合大型軟件的開發，應該說它是最為實際的方法，它吸收了軟件工程演化的概念，使得開發人員和客戶對每個演化層出現的風險有所了解，繼而做出應有的反應。圖1.5給出了螺旋模型的另一圖式。

螺旋模型的優越性比起其他模型來說是明顯的，但并不是絕對的。要求許多客戶接受和相信演化方法并不容易。這個模型的使用需要具有相當豐富的風險評估經驗和專門知識。如果項目風險較大，又未能及時發現，勢必造成重大損失。

1.4.3 生存周期模型選擇原則

目前，大多數軟件開發項目都采用改進的瀑布模型作為規范化開發的基礎，其主要原因是：

（1）軟件開發單位的軟件工程工作尚處于初級階段，軟件開發人員和管理人員既缺乏經驗，又無歷史數據可供借鑒，因此需要一種比較簡單易行的組織方式。

（2）結構化方法學是系統工程中最成熟的方法學，目前大多數軟件開發都以結構化開發方法學為基礎。

（3）在與結構化方法學相適應的生存周期模型中，改進的瀑布模型最為簡單實用，行之有效。

（4）有關軟件開發的現行國家標準和國家軍用標準都是以瀑布模型為基礎制定的。

隨著計算機技術的迅猛發展，新型軟件支持工具和環境的不斷推出，軟件開發單位在軟件開發經驗和數據方面的日益積累，軟件開發人員業務素質的逐步提高，可以預料，未來軟件開發將會采用更為先進的生存周期模型和技術。因此，在開發一個軟件項目時，首先應當為其選定適當的軟件生存周期模型，然后按選定的模型開展管理和技術工作，選用相應的標準和工具。

對于一個軟件開發項目，選擇生存周期模型時，一般應遵循下述原則：

（1）生存周期模型應與軟件項目的特點（如軟件規模和復雜性）相適應。

（2）生存周期模型應與所采用的軟件開發技術（如結構化方法）相適應。

（3）生存周期模型應滿足整個應用系統的開發進度要求。

（4）生存周期模型應有助于控制和消除軟件開發風險。

（5）生存周期模型應有可用的計算機輔助工具的支持。

（6）生存周期模型應與用戶和軟件開發人員的知識和技能水平相適應。

（7）生存周期模型應有利于軟件開發的管理和控制。

在為一個具體項目選擇軟件生存周期時，通常應考慮項目的特性（如系統的功能和復雜性，軟件的規模和復雜性，需求的穩定性，以前開發結果的使用，開發策略和硬件的可用性等），通過選擇每個過程的活動、規定活動的順序和分配給活動的責任來定義的軟件生存周期。

一個項目可以定義一個或多個軟件生存周期。RTCA DO-178B《機載系統和設備合格審定中的軟件考慮》給出了一個項目的示例。該項目使用了4種不同的軟件生存周期，具有不同軟件生存周期的單個軟件由4個軟件部件（W、X、Y和Z）組成，其開發過程如下：通過開發軟件需求，軟件部件W實施一系列系統需求，使用那些需求來確定軟件設計，將設計轉換為源代碼，并把軟件部件W集成到硬件中；軟件部件X是對在已經合格審定的航空器或發動機中使用的以前開發的軟件的使用說明；軟件部件 Y 利用了能從軟件需求直接編碼的、簡單的、劃分的功能；軟件部件Z使用了原型策略進行軟件開發，其目的是為了更好地理解軟件需求，并減少開發和技術的風險，它采用原始需求作為開發原型的基礎，并使原型在代表被開發系統的、預定的使用環境中進行評估，并用評估的結果來改進軟件需求，進而開發出該軟件部件，如圖1.6所示。