軟件生存期模型概要課件

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

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

2.3增量模型增量模型如圖所示。2.3增量模型增量模型的優(yōu)點

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

每個增量構(gòu)件應(yīng)當(dāng)實現(xiàn)某種系統(tǒng)功能，因此增量構(gòu)件的開發(fā)可以采用瀑布模型的方式，如圖所示。

2.3增量模型增量構(gòu)件開發(fā)2.3增量模型采用增量模型需注意的問題

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

2.4螺旋模型理解這種模型的一個簡便方法，是把它看做在每個階段之前都增加了完整的螺旋模型

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

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

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

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

螺旋模型是風(fēng)險驅(qū)動的，因此要求軟件開發(fā)人員必須具有豐富的風(fēng)險評估經(jīng)驗和這方面的專門知識，否則將出現(xiàn)真正的風(fēng)險：當(dāng)項目實際上正在走向災(zāi)難時，開發(fā)人員可能還以為一切正常。2.4螺旋模型螺旋模型的缺點2.4螺旋模型噴泉模型是典型的面向?qū)ο笊芷谀Ｐ??！皣娙币辉~體現(xiàn)了迭代和無間隙特性。圖中代表不同階段的圓圈相互重疊，這明確表示兩個活動之間存在重疊。2.5噴泉模型噴泉模型是典型的面向?qū)ο笊芷谀Ｐ汀?.5噴泉模型由Booch、Jacobson及Rumbaugh提出，統(tǒng)一過程模型如圖所示。

2.6統(tǒng)一過程由Booch、Jacobson及Rumbaugh提出，統(tǒng)一過統(tǒng)一過程的工作流

在統(tǒng)一過程中，有6個核心工作流。

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

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

2.6統(tǒng)一過程主要工作產(chǎn)品2.6統(tǒng)一過程2.7基于構(gòu)件的開發(fā)模型基于構(gòu)件的軟件工程（component-basedsoftwareengineering，CBSE）是強調(diào)使用可復(fù)用的軟件“構(gòu)件”來設(shè)計和構(gòu)造基于計算機的系統(tǒng)的過程。2.7基于構(gòu)件的開發(fā)模型基于構(gòu)件的軟件工程（compone2.7基于構(gòu)件的開發(fā)模型Clements對CBSE給出了如下描述。

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

2.7基于構(gòu)件的開發(fā)模型基于構(gòu)件的開發(fā)模型如下圖。2.7基于構(gòu)件的開發(fā)模型開發(fā)步驟

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

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

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

2.8敏捷過程敏捷過程模型2.8敏捷過程敏捷過程

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

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

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

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

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

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

②設(shè)計。XP設(shè)計嚴(yán)格遵循KIS（keepitsimple，保持簡潔）原則，通常更愿意使用簡單設(shè)計而不是更為復(fù)雜的表述。嚴(yán)格遵守KIS原則鼓勵使用CRC（類-責(zé)任-協(xié)作者）卡片在設(shè)計中遇到困難,XP推薦立即建立這部分設(shè)計的可執(zhí)行原型，實現(xiàn)并評估設(shè)計原型鼓勵“重構(gòu)”—一種迭代的改進內(nèi)部程序設(shè)計的方法2.8敏捷過程極限編程的框架活動2.8敏捷過程極限編程的框架活動

③編碼。建議在開始編碼之前為每一個故事開發(fā)一系列單元測試鼓勵“結(jié)對編程”④測試。所有的單元測試每天都要執(zhí)行?！膀炇諟y試”由客戶定義，將著眼于客戶可見的、可評審的系統(tǒng)級的特征和功能。2.8敏捷過程極限編程的框架活動2.8敏捷過程自適應(yīng)軟件開發(fā)

自適應(yīng)軟件開發(fā)（adaptivesoftwaredevelopment，ASD）是由JimHighsmith提出的；它可作為構(gòu)建復(fù)雜軟件和系統(tǒng)的一項技術(shù)，其基本概念著眼于人員合作和團隊自組織。2.8敏捷過程自適應(yīng)軟件開發(fā)2.8敏捷過程2.8敏捷過程自適應(yīng)軟件開發(fā)模型

2.8敏捷過程自適應(yīng)軟件開發(fā)模型自適應(yīng)軟件開發(fā)的階段

(1)思考：思考過程中，開始項目規(guī)劃并完成自適應(yīng)循環(huán)策劃。自適應(yīng)循環(huán)策劃通過使用項目開始信息，來確定項目所需的一系列軟件增量發(fā)布循環(huán)。(2)協(xié)作：受激勵的人員以超越其聰明才智和獨創(chuàng)成果的方式共同工作，協(xié)作方法是所有敏捷方法中不斷重現(xiàn)的主旋律。(3)學(xué)習(xí)：當(dāng)ASD團隊成員開始開發(fā)作為自適應(yīng)循環(huán)一部分的構(gòu)件時，其重點是在完成循環(huán)的過程中學(xué)習(xí)盡可能多的東西。2.8敏捷過程自適應(yīng)軟件開發(fā)的階段2.8敏捷過程That'sAll!That'sAll!第2章軟件生存期模型瀑布模型快速原型模型增量模型螺旋模型噴泉模型統(tǒng)一過程基于構(gòu)件的開發(fā)模型敏捷過程第2章軟件生存期模型瀑布模型在20世紀(jì)80年代之前，瀑布模型一直是唯一被廣泛采用的生命周期模型。傳統(tǒng)的瀑布模型如圖所示。

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

2.3增量模型增量模型如圖所示。2.3增量模型增量模型的優(yōu)點

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

每個增量構(gòu)件應(yīng)當(dāng)實現(xiàn)某種系統(tǒng)功能，因此增量構(gòu)件的開發(fā)可以采用瀑布模型的方式，如圖所示。

2.3增量模型增量構(gòu)件開發(fā)2.3增量模型采用增量模型需注意的問題

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

2.4螺旋模型理解這種模型的一個簡便方法，是把它看做在每個階段之前都增加了完整的螺旋模型

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

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

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

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

螺旋模型是風(fēng)險驅(qū)動的，因此要求軟件開發(fā)人員必須具有豐富的風(fēng)險評估經(jīng)驗和這方面的專門知識，否則將出現(xiàn)真正的風(fēng)險：當(dāng)項目實際上正在走向災(zāi)難時，開發(fā)人員可能還以為一切正常。2.4螺旋模型螺旋模型的缺點2.4螺旋模型噴泉模型是典型的面向?qū)ο笊芷谀Ｐ?。“噴泉”一詞體現(xiàn)了迭代和無間隙特性。圖中代表不同階段的圓圈相互重疊，這明確表示兩個活動之間存在重疊。2.5噴泉模型噴泉模型是典型的面向?qū)ο笊芷谀Ｐ汀?.5噴泉模型由Booch、Jacobson及Rumbaugh提出，統(tǒng)一過程模型如圖所示。

2.6統(tǒng)一過程由Booch、Jacobson及Rumbaugh提出，統(tǒng)一過統(tǒng)一過程的工作流

在統(tǒng)一過程中，有6個核心工作流。

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

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

2.6統(tǒng)一過程主要工作產(chǎn)品2.6統(tǒng)一過程2.7基于構(gòu)件的開發(fā)模型基于構(gòu)件的軟件工程（component-basedsoftwareengineering，CBSE）是強調(diào)使用可復(fù)用的軟件“構(gòu)件”來設(shè)計和構(gòu)造基于計算機的系統(tǒng)的過程。2.7基于構(gòu)件的開發(fā)模型基于構(gòu)件的軟件工程（compone2.7基于構(gòu)件的開發(fā)模型Clements對CBSE給出了如下描述。

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

2.7基于構(gòu)件的開發(fā)模型基于構(gòu)件的開發(fā)模型如下圖。2.7基于構(gòu)件的開發(fā)模型開發(fā)步驟

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

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

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

2.8敏捷過程敏捷過程模型2.8敏捷過程敏捷過程

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

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