2.2 軟件過程模型

軟件過程模型，又稱為軟件生存周期模型，是軟件過程的結構框架，它在一定抽象層次上刻畫了一類軟件過程的共同結構和屬性。不同的軟件過程模型闡述不同的軟件開發思想、步驟以及最佳實踐。常見的軟件過程模型包括瀑布模型、增量模型和演化模型。

2.2.1 瀑布模型

1970年Royce提出了著名的線性順序模型，又稱瀑布模型（waterfall model）。正如它的名字一樣，瀑布模型將軟件過程中的各項活動規定為依固定順序連接的若干階段工作，形如瀑布流水，最終得到軟件產品。這些順序執行的階段通常為：需求、設計、實現、測試、交付、運行和維護，如圖2-2所示。每個階段的結束處都設有評審，只有通過評審才能進入后一階段。前一階段的中間產品是后一階段工作的基礎。

瀑布模型的優點在于：①它在支持開發結構化軟件、控制軟件開發復雜度、促進軟件開發工程化方面起了顯著作用；②它為軟件開發維護提供了一種當時較為有效的管理模式，通過開發計劃制訂、項目估算、階段評審和文檔控制有效地對軟件過程進行指導，從而對軟件質量起到一定程度的保障作用。但是，瀑布模型的最大問題在于沒有在實踐中進行驗證。一個沒有通過驗證的模型在大量的實踐中會暴露出它的種種不足和問題：

1）不能應對不確定性。用戶常常難以清楚地給出所有需求，而瀑布模型卻要求如此，它不能接受在許多項目的開始階段自然存在的不確定性，以及開發過程中的需求變更。

2）錯誤發現太遲。軟件的運行版本一直要等到項目開發晚期才能得到，很多錯誤直到運行程序時才被發現，造成大量的返工。

3）開發進度緩慢。由于模型的線性順序，開發者常常被不必要地耽擱，某些項目組成員不得不等待組內其他成員先完成其依賴的任務。

瀑布模型太理想化、太單純，已不再適合當前充滿各種風險的軟件開發項目。但我們應該認識到，“線性”是人們最容易掌握并能熟練應用的思想方法。當人們碰到一個復雜的“非線性”問題時，總是會千方百計地將其分解或轉化為一系列簡單的線性問題，然后逐個解決。線性是一種簡潔，簡潔就是美。當我們領會了線性的精神，就不要再呆板地套用瀑布模型的外表，而應該用活它。例如增量模型和演化模型實質上就是多次重復的線性模型。也許，當軟件工程和開發技術足夠成熟時，線性模型可能會再次回歸到業界實踐中。

2.2.2 增量模型

增量模型（incremental model），又稱有計劃的產品改進模型，它從一組給定的需求開始，通過構造一系列可執行版本來實施開發活動。第一個版本實現一部分需求，下一個版本實現更多的需求，以此類推，直到系統完成。每個版本都要執行必要的活動和任務，如，需求分析和架構設計僅需要執行一次，而軟件詳細設計、軟件編碼和測試、軟件集成和軟件驗收在每個版本構造過程中都會執行。增量模型的例子如圖2-3所示。

和瀑布模型相比，增量模型具有以下顯著的特點：

1）多個版本可以并行開發。在開發每個版本時，開發過程中順序地或部分平行地進行各項活動和任務。當相繼版本在部分并發開發時，開發過程中的活動和任務可以在各版本間平行地被采用。

2）每個版本都是可運行的產品。每一個線性序列產生軟件的一個可發布的“增量”，這必須是可運行的產品。

3）需求在開發早期是明確的。大部分需求在項目早期就被定義，在此基礎上進行整體架構的設計，然后將功能有計劃地分為若干增量來逐步實現。

當開發人員、資源或資金不足以在設定期限內實現一個完全的版本時，增量開發尤為有用。早期的增量可以由較少的人員實現，如果核心產品很受歡迎，可以增加新的人手實現下一個增量。同時，增量能夠有計劃地管理技術風險，并且能提前把產品推向市場。但增量并沒有緩解瀑布模型中的需求風險和架構風險。相反，一旦需求不明確、架構沒有把握或變更頻繁，其返工風險會更大，極可能涉及多個并行開發的版本。

2.2.3 演化模型

就像所有復雜系統一樣，軟件要經過一段時間的演化。業務和產品需求在軟件開發過程中常常發生改變，想要一次迭代就開發出最終產品是不可能的；同時，緊迫的市場期限使得難以一下子完成一個完善的軟件產品。因此，只要核心需求能夠被很好地理解，我們就可以進行漸進式開發，其余需求可以在后續的迭代中進一步定義和實現。這種過程模型稱為演化模型（evolutionary model），它能很好地適應隨時間演化的產品的開發。

演化模型是迭代的過程模型，它的特征是漸進地開發各個可執行版本，逐步完善軟件產品，如圖2-4所示。每個版本在開發時，開發過程中順序地或部分重疊平行地進行各項活動和任務。演化模型通過以下手段緩解了軟件開發所遇到的進度風險、需求風險、架構風險、技術風險、集成風險和質量風險等。

1）優先級高的需求在前面的迭代實現，迭代式交付產品。當進度來不及時，寧可放棄優先級低的需求，絕不犧牲質量。

2）支持迭代間和迭代內的并行開發，加快開發進度。需求在開發早期常常不能被完全了解和確定，演化模型在一部分需求被定義后就開始開發了，然后在每個相繼的版本中逐步完善。

3）在軟件的開發過程中，需求總會變化，但需求變化和需求“蠕變”會導致項目延期交付、工期延誤、客戶不滿意、開發人員受挫。通過向用戶演示迭代所產生的部分系統功能，我們可以盡早地收集用戶對系統的反饋，及時改正對用戶需求的理解偏差，從而保證開發出來的系統能夠真正地解決客戶的問題。

4）當我們對項目的技術方案不確定時，演化模型通過早期迭代進行技術探索，建立架構或技術原型，通過原型的測試與反饋來評估和選擇合適的技術方案，為后續的迭代化開發提供穩定的基礎。

5）在每個迭代中都安排集成和測試，使得系統集成和系統測試提前并持續執行，及早發現代碼缺陷。

演化模型是目前采用最廣泛的模型，統一軟件過程（UP）和許多敏捷過程（如XP、Scrum）都采用了這種模型。原型模型則是迭代次數為2的演化模型，它在第一個迭代中通過界面原型來識別和澄清軟件需求，然后在第二個迭代中根據明確的需求進行開發。但是，演化模型也有一個明顯的缺點——復雜。它比瀑布模型要復雜很多，其難點是迭代的規劃和控制，當然，這也是其成功的關鍵。本節以下內容將詳細闡述迭代化開發原則，并以統一過程為例來解釋演化模型。

2.2.3.1 迭代化開發原則

迭代是處理不確定的復雜問題的有效手段。演化模型采用迭代來應對復雜軟件開發中的不確定性，將一個軟件生命周期劃分為若干個迭代，前一個迭代將為下一個迭代積累經驗。

● 迭代化開發原則一：要求每次迭代都產生一個可執行的軟件版本。每次迭代本身都包括計劃、建模、需求、分析和設計、實現、測試、評估等活動。每個迭代開始于計劃和需求，結束于一個小型發布，其內部就像一個小的瀑布模型，即瀑布模型可以看作迭代化開發的一個特例，整個開發流程只有一次迭代。唯一和瀑布模型不同的是，其計劃、需求、設計、實現、測試等活動允許（或鼓勵）部分并行。

● 迭代化開發原則二：要求有計劃的迭代。采用瀑布模型進行開發也有迭代，例如第一個迭代是對所有的功能進行需求分析、設計、實現和測試，在測試時發現需求有缺陷，然后返工至需求，再進行設計、實現和測試，形成第二個迭代，在測試時又發現缺陷，再返工……但這種迭代是無計劃的、失控的。我們無法事先預計會有多少次迭代，每個迭代做什么，項目什么時候會結束。迭代化開發要求在做項目計劃時就確定迭代的個數，以及每個迭代的起止時間和任務。一個軟件項目通常由3～9個迭代組成，項目的風險越高，迭代就越多。迭代的安排和計劃是由風險驅動的。

汽車4S店業務管理系統的迭代安排

我們首先分析汽車4S店業務管理系統的風險，發現最大的三個風險如下：

1）第一大風險：需求風險。ABC汽車集團公司提不出具體需求，同時由于激烈的市場競爭，在開發過程中需求將會發生變化。

2）第二大風險：技術風險。采用什么架構，是否要采用Web service技術？SJTU項目組沒有相關經驗。

3）第三大風險：進度風險。整個項目的開發進度非常緊。按當前掌握的需求，需要9個月才能完成，但ABC公司為了配合一款新車上市，要求7個月后系統就上線。

根據上述風險分析，我們進行了如下的迭代安排：

1）第一個迭代，解決需求風險，開發需求界面原型，并和ABC公司召開需求聯合評審會，獲得用戶反饋。

2）第二個迭代，解決技術風險和架構風險，開發架構原型，并通過測試確保所選的技術和架構是合理的。

3）第三個迭代～第六個迭代，解決進度風險。我們將用戶需求排出優先級，將優先級高的需求放在第三個迭代完成，構建系統的第一個版本，并在第四個迭代進行第一次移交，包括移交時的系統打包、用戶手冊準備、驗收測試和部署上線。第五個迭代開發優先級中的需求，構建系統的第二個版本，并在第六個迭代進行第二次移交。每個迭代一個月。

在新車上線時，前四個迭代已經完成。雖然系統的功能沒有全部完成，但系統最重要的功能已經移交和上線，而且質量很好，用戶可以開始使用。余下的次要功能在第9個月底全部完成，不影響ABC公司的業務。

事實上，迭代的周期有長有短，同一個軟件項目中多個迭代的周期也常常不盡相同。典型情況下，一個迭代一般是2～6周，這受軟件項目的規模和復雜性、開發組織的規范、穩定性和成熟度，以及軟件開發的自動化程度等因素的影響。

2.2.3.2 統一軟件過程

每一種軟件過程模型都有具體的過程實例，其中統一軟件過程（UP）[1]是目前廣泛接受的演化過程之一。UP是Rational軟件公司（2003年被IBM收購）開發的一個風險驅動的、基于UML和構件式架構的迭代、演化開發過程，它是從幾千個軟件項目的實踐經驗中總結出來的，對于實際項目具有很強的指導意義。

UP的整體框架如圖2-5所示。它展示了兩個維度：水平方向是隨著時間逐漸延展的項目生命周期，展示了過程以階段、迭代和里程碑所表述的動態特性；垂直方向是以規范為邏輯劃分的活動，通過過程元素，如流程、活動、制品、角色等展示了過程的靜態特性。

UP把軟件過程分為先啟（inception）、精化（elaboration）、構建（construction）和產品化（transition）四個階段。每個階段又可分為多個迭代，其中迭代的數量和風險相關，風險越大則迭代個數越多。每個階段結束是一個業務決策里程碑（大里程碑），每個迭代結束是一個技術里程碑（小里程碑）。

先啟階段的目的是在所有項目干系人之間就項目目標達成共識。該階段對新項目尤其重要，新項目的重要業務風險和需求風險問題必須在項目繼續進行之前得到解決。對于擴展現有系統的項目來說，先啟階段較短。先啟階段的結束是軟件生存周期的目標里程碑。

精化階段的目的是建立軟件架構的基線，解決技術風險，以便為軟件的詳細設計和實現提供一個穩定的基礎。架構是基于對大多數重要需求（對系統架構有很大影響的需求）的考慮和風險評估建立起來的。架構的穩定性則通過一個或多個架構原型進行評估和驗證。精化階段的結束是軟件生存周期的架構里程碑。

構建階段的目的是基于已建立基線的架構完成系統開發。從某種意義上來說它是一個“制造”過程——由于需求風險和技術風險已經通過前兩個階段受到控制，其重點在于管理資源和控制操作，以便優化成本、進度和質量，又快又好地實現軟件的功能。從這種意義上說，從先啟和精化階段到構建和產品化階段，管理上的思維定式經歷了從知識產權開發到可部署產品開發的轉變。構建階段的結束是軟件初始能力的里程碑。

產品化階段的重點是交付最終用戶可以使用的軟件。它可跨越幾個迭代，包括測試處于發布準備中的產品和基于用戶反饋進行較小的調整。在產品化階段，用戶的反饋應主要側重于調整產品、配置、安裝和可用性問題，而所有軟件架構上的問題應該在項目早期階段就已得到解決。產品化階段的結束是軟件產品發布的里程碑。