第2章軟件生存期模型瀑布模型快速原型模型增量模型螺旋模型噴泉模型統一過程基于構件的開發模型敏捷過程在20世紀80年代之前，瀑布模型一直是唯一被廣泛采用的生命周期模型。傳統的瀑布模型如圖所示。

2.1瀑布模型瀑布模型的特點階段間具有順序性和依賴性。其中包含兩重含義：①必須等前一階段的工作完成之后，才能開始后一階段的工作；②前一階段的輸出文檔就是后一階段的輸入文檔。2.1瀑布模型瀑布模型的特點推遲實現的觀點①瀑布模型在編碼之前設置了系統分析和系統設計的各個階段，分析與設計階段的基本任務規定，在這兩個階段主要考慮目標系統的邏輯模型，不涉及軟件的物理實現。②清楚地區分邏輯設計與物理設計，盡可能推遲程序的物理實現，是按照瀑布模型開發軟件的一條重要的指導思想。2.1瀑布模型瀑布模型的特點質量保證的觀點①每個階段都必須完成規定的文檔，沒有交出合格的文檔就是沒有完成該階段的任務。②每個階段結束前都要對所完成的文檔進行評審，以便盡早發現問題，改正錯誤。2.1瀑布模型實際的瀑布模型實際的瀑布模型是帶“反饋環”的，如圖所示。圖中實線箭頭表示開發過程，虛線箭頭表示維護過程。2.1瀑布模型V模型：瀑布模型的一個變體V模型描述了測試階段的活動與開發階段相關活動（包括需求建模、概要設計、詳細設計、編碼）之間的關系。2.1瀑布模型瀑布模型的優點可強迫開發人員采用規范化的方法。嚴格地規定了每個階段必須提交的文檔。要求每個階段交出的所有產品都必須是經過驗證的。2.1瀑布模型瀑布模型的缺點由于瀑布模型幾乎完全依賴于書面的規格說明，很可能導致最終開發出的軟件產品不能真正滿足用戶的需要。如果需求規格說明與用戶需求之間有差異，就會發生這種情況。瀑布模型只適用于項目開始時需求已確定的情況。2.1瀑布模型快速原型是快速建立起來的可以在計算機上運行的程序，它所能完成的功能往往是最終產品能完成的功能的一個子集。快速原型模型如圖所示。2.2快速原型模型快速原型模型的優點(1)有助于滿足用戶的真實需求。(2)原型系統已經通過與用戶的交互而得到驗證，據此產生的規格說明文檔能夠正確地描述用戶需求。(3)軟件產品的開發基本上是按線性順序進行。(4)因為規格說明文檔正確地描述了用戶需求，因此，在開發過程的后續階段不會因為發現規格說明文檔的錯誤而進行較大的返工。2.2快速原型模型快速原型模型的優點(5)開發人員通過建立原型系統已經學到了許多東西，因此，在設計和編碼階段發生錯誤的可能性也比較小，這自然減少了在后續階段需要改正前面階段所犯錯誤的可能性。(6)快速原型的突出特點是“快速”。開發人員應該盡可能快地建造出原型系統，以加速軟件開發過程，節約軟件開發成本。原型的用途是獲知用戶的真正需求，一旦需求確定了，原型可以拋棄，當然也可以在原型的基礎上進行開發。2.2快速原型模型增量模型也稱為漸增模型，是Mills等于1980年提出來的。使用增量模型開發軟件時，把軟件產品作為一系列的增量構件來設計、編碼、集成和測試。每個構件由多個相互作用的模塊構成，并且能夠完成特定的功能。2.3增量模型增量模型如圖所示。

2.3增量模型增量模型的優點

(1)能在較短時間內向用戶提交可完成一些有用的工作產品，即從第1個構件交付之日起，用戶就能做一些有用的工作。(2)逐步增加產品的功能可以使用戶有較充裕的時間學習和適應新產品，從而減少一個全新的軟件可能給用戶組織帶來的沖擊。(3)項目失敗的風險較低，雖然在某些增量構件中可能遇到一些問題，但其他增量構件將能夠成功地交付給客戶。(4)優先級最高的服務首先交付，然后再將其他增量構件逐次集成進來。因此，最重要的系統服務將接受最多的測試。2.3增量模型增量構件開發

每個增量構件應當實現某種系統功能，因此增量構件的開發可以采用瀑布模型的方式，如圖所示。

2.3增量模型采用增量模型需注意的問題

(1)在把每個新的增量構件集成到現有軟件體系結構中時，必須不破壞原來已經開發出的產品。(2)軟件體系結構必須是開放的，即向現有產品中加入新構件的過程必須簡單、方便。因此，采用增量模型比采用瀑布模型和快速原型模型更需要精心的設計。2.3增量模型螺旋模型最初是Boehm于1988年提出來的。該模型將瀑布模型與快速原型模型結合起來，并且加入兩種模型均忽略了的風險分析。螺旋模型的基本思想是，使用原型及其他方法來盡量降低風險。2.4螺旋模型理解這種模型的一個簡便方法，是把它看做在每個階段之前都增加了風險分析過程的快速原型模型。

2.4螺旋模型完整的螺旋模型

2.4螺旋模型完整的螺旋模型

在螺旋模型中，軟件過程表示成一個螺線，而不是像以往的模型那樣表示為一個具有回溯的活動序列。在螺線上的每一個循環表示過程的一個階段。每個階段開始時的任務是確定該階段的目標、為完成這些目標選擇方案及設定這些方案的約束條件。接下來的任務是，從風險角度分析上一步的工作結果，努力排除各種潛在的風險，通常用建造原型的方法來排除風險。如果成功地排除了所有風險，則啟動下一步開發步驟，在這個步驟的工作過程相當于純粹的瀑布模型。最后是評價該階段的工作成果并計劃下一個階段的工作。2.4螺旋模型螺旋模型的4項活動

螺線上的每一個循環可劃分為4個象限，分別表達了4個方面的活動。(1)目標設定——定義在該階段的目標，弄清對過程和產品的限制條件，制訂詳細的管理計劃，識別項目風險，可能還要計劃與這些風險有關的對策。(2)風險估計與弱化——針對每一個風險進行詳細分析，設想弱化風險的步驟。(3)開發與驗證——評價風險之后選擇系統開發模型。(4)計劃——評價開發工作，確定是否繼續進行螺線的下一個循環。如果確定要繼續，則計劃項目的下一個階段的工作。2.4螺旋模型螺旋模型的優點

對可選方案和約束條件的強調有利于已有軟件的重用，也有助于把軟件質量作為軟件開發的一個重要目標。減少了過多測試或測試不足所帶來的風險。在螺旋模型中維護只是模型的另一個周期，因而在維護和開發之間并沒有本質區別。2.4螺旋模型螺旋模型的缺點

螺旋模型是風險驅動的，因此要求軟件開發人員必須具有豐富的風險評估經驗和這方面的專門知識，否則將出現真正的風險：當項目實際上正在走向災難時，開發人員可能還以為一切正常。2.4螺旋模型噴泉模型是典型的面向對象生命周期模型。“噴泉”一詞體現了迭代和無間隙特性。圖中代表不同階段的圓圈相互重疊，這明確表示兩個活動之間存在重疊。2.5噴泉模型由Booch、Jacobson及Rumbaugh提出，統一過程模型如圖所示。

2.6統一過程統一過程的工作流

在統一過程中，有6個核心工作流。

①業務建模工作流。用商業用例為商業過程建立文檔。②需求工作流。目標是描述系統應該做什么，確保開發人員構建正確的系統。為此，需明確系統的功能需求和非功能需求（約束）。③分析和設計工作流。其目標是說明如何做。結果是分析模型和設計模型。2.6統一過程④實現工作流。用分層的方式組織代碼的結構，用構件的形式來實現類，對構件進行單元測試，將構件集成到可執行的系統中。⑤測試工作流。驗證對象之間的交互、是否所有的構件都集成了、是否正確實現了所有需求、查錯并改正。⑥部署工作流。制作軟件的外部版本、軟件打包、分發、為用戶提供幫助和支持。2.6統一過程統一過程的階段

統一過程有4個階段，分別是初始階段、細化階段、構造階段和移交階段。①初始階段。初始階段主要關注項目計劃和風險評估，其目的是確定是否值得開發目標信息系統。②細化階段。細化階段關心定義系統的總體框架，其目標是：細化初始需求（用況）、細化體系結構、監控風險并細化它們的優先級、細化業務案例以及制訂項目管理計劃。2.6統一過程統一過程的階段③構造階段。構造階段是建立系統，構造信息系統的第1個具有操作質量的版本，以能夠交付給客戶進行測試的版本結束，有時稱為測試版本。④移交階段。移交階段包含測試時期，以發布完整的系統而終止，其目標是確保信息系統真正滿足客戶的需求。2.6統一過程主要工作產品

2.6統一過程2.7基于構件的開發模型基于構件的軟件工程（component-basedsoftwareengineering，CBSE）是強調使用可復用的軟件“構件”來設計和構造基于計算機的系統的過程。2.7基于構件的開發模型Clements對CBSE給出了如下描述。

CBSE正在改變大型軟件系統的開發方式。CBSE體現了FrodBrooks和其他人支持的“購買，而非構造”的思想。就如同早期的子程序將程序員從考慮編程細節中解脫出來一樣，CBSE將考慮的重點從編碼轉移到組裝軟件系統。考慮的焦點是“集成”，而不再是“實現”。這樣做的基礎是假定在很多大型軟件系統中存在足夠多的共性，使得開發可復用的構件來滿足這些共性是可行的。2.7基于構件的開發模型當軟件團隊使用傳統的需求獲取技術確定了待開發軟件的系統需求時，該過程開始。體系結構設計完成后，并不立即進行詳細設計任務，而是針對每一系統需求考慮以下問題:(1)現有的商品化構件（commercialoff-the-shelf，COTS）是否能夠實現該需求？(2)內部開發的可復用構件是否能夠實現該需求？(3)可用構件的接口與待構造系統的體系結構是否相容？2.7基于構件的開發模型基于構件的開發模型如下圖。

2.7基于構件的開發模型開發步驟

不考慮構件的開發技術，基于構件的開發模型由以下步驟組成：(1)對于該問題領域的基于構件的可用產品進行研究和評估。(2)考慮構件集成的問題。(3)設計軟件架構以容納這些構件。(4)將構件集成到架構中。(5)進行充分的測試以保證功能正常。2.7基于構件的開發模型典型的構件模型(1)OMG/CORBA。對象管理組織發布了公共對象請求代理體系結構（OMG/CORBA），一個對象請求代理提供了多種服務，使得可復用構件（對象）可以與其他構件通信。(2)MicrosoftCOM/DCOM/.NET。微軟公司開發了構件對象模型（COM），此模型提供了構件的規格說明,在Windows操作系統，一個應用系統中可以使用不同廠商生產的構件。(3)SunJavaBean構件。JavaBean構件系統是一個可移植的、平臺獨立的、使用Java程序設計語言開發的CBSE基礎設施。2.8敏捷過程敏捷過程模型

2001年，KentBeck等17名編程大師發表“敏捷軟件開發”宣言：

我們正在通過親身實踐以及幫助他人實踐的方式來揭示更好的軟件開發之路，通過這項工作，我們認為：個體和交互勝過過程和工具；可工作軟件勝過寬泛的文檔；客戶合作勝過合同談判；響應變化勝過遵循計劃。

2.8敏捷過程敏捷過程

任何一個敏捷過程都可以由所強調的3個關鍵假設識別出來，這3個假設可適用于大多數軟件項目。(1)提前預測哪些需求是穩定的、哪些需求會變化非常困難。同樣的，預測項目進行中客戶優先級的變化也很困難。(2)對很多軟件，設計和構建是交錯進行的。事實上，兩種活動應當順序開展以保證通過構建實施來驗證設計模型，而在通過構建驗證之前很難估計應該設計到什么程度。(3)從制訂計劃的角度來看，分析、設計、構建和測試并不像我們所設想的那么容易預測。2.8敏捷過程敏捷原則

(1)我們最優先要做的是通過盡早、持續交付有價值的軟件來使客戶滿意。(2)即使在開發的后期，也歡迎需求變更。敏捷過程利用變更為客戶創造競爭優勢。(3)經常交付可運行軟件，交付的間隔可以從幾個星期到幾個月，交付的時間間隔越短越好。(4)在整個項目開發期間，業務人員和開發人員必須天天都在一起工作。(5)圍繞有積極性的個人構建項目。給他們提供所需的環境和支持，并且信任他們能夠完成工作。2.8敏捷過程敏捷原則

(6)在團隊內部，最富有效果和效率的信息傳遞方法是面對面交談。(7)可運行軟件是進度的首要度量標準。(8)敏捷過程提倡可持續的開發速度。責任人、開發者和用戶應該能夠保持一種長期、穩定的開發速度。(9)不斷地關注優秀的技能和好的設計會增強敏捷能力。(10)簡單是必要的。(11)好的架構、需求和設計出自于自組織團隊。(12)每隔一定時間，團隊會反省如何才能更有效地工作，并相應調整自己的行為。2.8敏捷過程人的因素

敏捷開發團隊成員及團隊本身必須具備的一些特點:基本能力共同目標精誠合作決策能力模糊問題解決能力相互信任和尊重自我組織極限編程（eXtremeProgramming，XP）

使用最廣泛的敏捷過程，最初由KentBeck提出。XP包含了策劃、設計、編碼和測試4個框架活動的規則和實踐。2.8敏捷過程2.8敏捷過程極限編程的框架活動

①策劃開始于建立“用戶故事”敏捷團隊評估每一個故事并給出成本（cost）故事被分組用于可交付增量對發布日期做出承諾在第一個發行版本（軟件增量）之后，“項目速度”用于幫助建立后續發行版本（軟件增量）的發布日期極限編程的框架活動

②設計。XP設計嚴格遵循KIS（keepitsimple，保持簡潔）原則