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

3.1　軟件生存周期模型

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

　

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

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

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

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

圖3-8　統(tǒng)一軟件開發(fā)過程（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.）
每一次循環(huán)歷經(jīng)所有的四個階段，并且指明了每一個核心工作流中的開發(fā)工作。每一個工作流及其產(chǎn)物如下所述：
1）需求。需求工作流的產(chǎn)物是用例模型。
2）分析。分析工作流的產(chǎn)物是分析模型。
3）設(shè)計。設(shè)計工作流的產(chǎn)物是設(shè)計模型和部署模型。
4）實現(xiàn)。實現(xiàn)工作流的產(chǎn)物是實現(xiàn)模型。
5）測試。測試工作流的產(chǎn)物是測試模型。
與螺旋模型類似，USDP是一個風(fēng)險驅(qū)動的過程。USDP生存周期階段如下所述（Jacobson，Booch，and Rumbaugh 1990；Kruchten 2003）：
1）初始。在初始階段，制定出達到足夠水平的初步想法，用以證明有能力進入細化階段。
2）細化。在細化階段，定義軟件體系結(jié)構(gòu)。
3）構(gòu)造。在構(gòu)造階段，開發(fā)出能夠發(fā)布給用戶的軟件產(chǎn)品。
4）交付。在交付階段，軟件被交付給用戶。

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。