本節書摘來自華章計算機《軟件建模與設計: UML、用例、模式和軟件體系結構》一書中的第3章，第3.1節,作者：（美）Hassan Gomaa，更多章節內容可以訪問云棲社區“華章計算機”公眾號查看。

3.1　軟件生存周期模型

瀑布模型（waterfall model）是最早被廣泛使用的軟件生存周期模型。本節首先回顧瀑布模型，然后概述其他可選擇的軟件生存周期模型，這些模型用來克服瀑布模型的部分局限性，它們是：拋棄型原型生存周期模型（throwaway prototyping life cycle model），增量開發生存周期模型（incremental development life cycle model，也稱為演化式原型evolutionary prototyping），螺旋模型（spiral model），以及統一軟件開發過程（Unified Software Development Process）。
3.1.1　瀑布生存周期模型
從20世紀60年代以來，開發軟件的成本逐步增長，同時制造和購買硬件的成本則急劇下降。進一步說，當前軟件成本一般占據整個項目預算的百分之八十，然而在軟件開發的早期，硬件則是最大的項目成本（Boehm 2006）。
在20世紀60年代，相關人員還沒有明確理解與開發軟件相關的一些問題。在60年代后期，人們才理解到存在軟件危機這一問題。軟件工程這個術語是指為了有效開發一個大型軟件系統所需要的管理與技術方法、過程和工具。隨著軟件工程概念的不斷推廣與使用，人們已經使用軟件生存周期模型開發了許多大規模的軟件。圖3-1展示了第一個被廣泛使用的軟件生存周期模型，通常指的是瀑布模型，它一般被看做是傳統的或者“古典”的軟件生存周期。瀑布模型是一個理想化的過程模型，它規定每一階段完成后才能啟動下一階段，另外，一個項目在沒有迭代和重復的情況下從一個階段移動到下一個階段。
3.1.2　瀑布模型的局限性
瀑布模型是對早期軟件項目所使用的較為散亂的開發方法的一種重要改進，它已經被成功應用在許多項目中。然而，事實上，當在開發中檢測到一些軟件錯誤時，在生存周期的連續階段中時常需要一些重復與迭代（見圖3-2）。此外，對于一些軟件開發項目而言，瀑布模型會呈現出以下顯著問題：
軟件需求作為軟件開發項目中的一個關鍵因素，無法進行合適的測試，直至一個工作系統被開發出來并能演示給最終用戶。事實上，好幾個研究工作已經指出軟件需求規約的錯誤通常在最后才被檢測到（直至執行系統測試或驗收測試才能被檢測到），并且需要花費最大的代價對其進行糾正。
只有在生存周期的后期才能得到一個工作的系統。因此，直到系統幾乎可以運行時，一個重要的設計或性能問題才有可能被發現，到那時通常已經太晚了，以至于無法采取有效的措施。

　

對于帶有很大風險因素的軟件開發項目來說——例如，由于那些無法清晰理解或預期會改變的需求所導致的風險——瀑布模型的變體或者其他替代模型已經被提出。
可以使用兩種不同的軟件原型方法來克服瀑布模型的一些局限：拋棄型原型和演化式原型。拋棄型原型有助于解決瀑布模型的第一個問題，這個問題在前面的列表中已被描述，演化式原型則有助于解決第二個問題。
3.1.3　拋棄型原型
拋棄型原型有助于闡明用戶需求。該方法對從用戶界面上獲得反饋非常有用，并且能夠應用于具有復雜用戶界面的系統。
一個拋棄型原型能夠在一個初步的需求規約被制定之后就被開發出來（圖3-3）。通過讓用戶使用原型，可以得到許多通常難以得到的有價值的反饋。以這些反饋為基礎，就可以準備制定一個修訂的需求規約。后續的開發過程則延續了傳統的軟件生存周期。
針對詳述交互式信息系統需求的問題，拋棄型原型（尤其是用戶界面的原型）已經成為解決該問題的一種有效方案。Gomaa（1990）描述了如何使用拋棄型原型來闡明一個具有高度交互性的制造型應用軟件的需求。該原型有助于克服存在于用戶和開發者之間的溝通障礙這一最大的問題。
拋棄型原型也能被用于構造設計的實驗性原型（圖3-4）。這個原型能用于確定特定的算法是否邏輯正確，或者用于確定它們是否滿足性能目標。

3.1.4　通過增量開發的演化式原型
演化式原型方法是增量開發的一種形式，在增量開發中，原型從幾個中間步驟的可運行系統（圖3-5）逐步演化為可交付系統。該方法可用于確定系統是否滿足性能目標，并用于測試設計中所涵蓋的關鍵構件。另外，通過將實現分布在一個較長的時間段內也降低了開發的風險。用例和基于場景的通信圖能輔助選擇每一次增量中的系統子集。
演化式原型方法的一個目標是得到早期運行的系統子集，隨后在該子集上逐步構造。如果系統的第一個增量版本對一條從外部輸入到外部輸出的路徑進行了完整的測試，那么使用增量式原型方式是有優勢的。
Gomaa（1990）描述了通過增量開發的演化式原型的一個實例。開發者在一個實時的機器人控制系統（Gomaa 1986）中使用了這種方法，結果得到了一個系統的早期可運行版本，這極大鼓舞了開發團隊和管理者的士氣。同時，這種方法也帶來了一系列的好處，包括驗證系統的設計、確定特定的關鍵算法是否滿足性能目標以及持續進行系統集成。
3.1.5　拋棄型原型和增量開發的結合
與傳統的瀑布生存周期相比，使用增量開發的生存周期模型方法能夠更早地得到一個以演化式原型為形式的工作系統。然而，開發這種類型的原型比開發一個拋棄型原型需要投入更多的關注，這是由于演化式原型形成了最終產品的基礎；因此，從一開始就必須將軟件質量考慮進來，而不能將其作為一種事后產物添加進來。特別是，需要仔細地設計軟件體系結構并且指明所有的接口。
傳統的瀑布生存周期模型因引入拋棄型原型或增量開發而受到嚴重的沖擊。將拋棄型原型與增量開發這兩種方法結合起來也是有可能的，如圖3-6所示。其中，拋棄型原型被用來闡明需求。當理解需求并完成規約之后，就可開始進行一個增量開發生存周期。在后續的增量開發中，由于用戶環境的變化，需求的進一步變更也可能是必要的。

3.1.6　螺旋模型
螺旋模型是一個風險驅動的過程模型，最初由Boehm（1988）開發用來解決軟件生存周期早期過程模型中存在的已知問題，尤其是瀑布模型中的問題。螺旋模型旨在涵蓋其他生存周期模型，例如瀑布模型、增量開發模型以及拋棄型原型模型。
在螺旋模型中，徑向坐標代表成本，角坐標代表完成一次模型周期（循環）的成果。螺旋模型包含以下4個象限，如圖3-7所示。

圖3-7　螺旋過程模型
1）定義目標、候選方法和約束。此次循環的詳細計劃：確定目標以及用來實現目標的各種候選方法。
2）分析風險。對當前項目風險進行詳細評估；為了減輕風險，計劃待執行的活動。
3）開發產品。進行產品開發，例如需求分析、設計或者編碼。
4）計劃下一次循環。對此次循環的成果進行評估，并開始計劃下一次循環。
螺旋模型的每一次循環都會迭代地經過這4個象限，盡管循環的次數是由特定項目決定的。每一個象限中的活動描述都要足夠通用，使得它們能夠被包含在任何一個循環中。
螺旋模型的目標是風險驅動，因此一個特定循環中的風險由“分析風險”這一象限決定。為了管理這些風險，需要額外地計劃特定項目的活動來解決這些風險。例如，當風險分析指出軟件需求并未被清晰理解時，就需要采用需求原型。這些特定項目的風險被稱為過程驅動力（process driver）。對于任何過程驅動力而言，需要執行一個或多個特定項目的活動來管理這個風險（Boehm and Belz 1990）。
識別一個特定項目風險的例子是確定初始的軟件需求沒有被很好地理解。用來管理該風險所需執行的一個特定項目的活動是開發一個拋棄型原型，其目的是從用戶處得到反饋從而有助于闡明系統的需求。
3.1.7　統一軟件開發過程
按照Jacobson et al.（1999）中的描述，統一軟件開發過程（USDP）是使用UML表示法的一種用例驅動的軟件過程。USDP也被稱為Rational統一過程（RUP）（Kroll and Kruchten 2003；Kruchten 2003）。USDP/RUP是一種流行的基于UML的軟件開發過程。本節介紹PLUS方法如何用于USDP/RUP過程。
如圖3-8所示，USDP包含5個核心工作流和4個階段，同時USDP是可迭代的。制品（artifact）被定義為由一個過程生產、修改或使用的信息（Kruchten 2003）。工作流（workflow）被定義為生產可觀測結果的一系列活動（Kruchtem 2003）。階段（phase）被定義為兩個里程碑之間的一段時間，在此過程中一組事先定義的開發目標得到了滿足，完成了一些制品，同時做出了是否進入下一階段的決定（Kruchten 2003）。通常，在一個階段中存在超過一次的迭代；因此，USDP中一個階段迭代與螺旋模型中的一次循環是相對應的。

圖3-8　統一軟件開發過程（Jacobson et al，THE UNIFIED SOFTWARE DEVELOPMENT PROCESS，Figure 1.5“Unified Software Development Process”p.11，?1999 Pearson Education，Inc.Reproduced by permission of Pearson Education，Inc.）
每一次循環歷經所有的四個階段，并且指明了每一個核心工作流中的開發工作。每一個工作流及其產物如下所述：
1）需求。需求工作流的產物是用例模型。
2）分析。分析工作流的產物是分析模型。
3）設計。設計工作流的產物是設計模型和部署模型。
4）實現。實現工作流的產物是實現模型。
5）測試。測試工作流的產物是測試模型。
與螺旋模型類似，USDP是一個風險驅動的過程。USDP生存周期階段如下所述（Jacobson，Booch，and Rumbaugh 1990；Kruchten 2003）：
1）初始。在初始階段，制定出達到足夠水平的初步想法，用以證明有能力進入細化階段。
2）細化。在細化階段，定義軟件體系結構。
3）構造。在構造階段，開發出能夠發布給用戶的軟件產品。
4）交付。在交付階段，軟件被交付給用戶。

總結

以上是生活随笔為你收集整理的《软件建模与设计: UML、用例、模式和软件体系结构》一一3.1　软件生存周期模型...的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。