《軟件工程基礎(chǔ)》第10章 軟件生存期模型

1、10.1 軟件過程框架軟件過程框架的內(nèi)容 軟件過程框架定義了若干框架活動(dòng)，為完整的軟件開發(fā)過程建立了基礎(chǔ)。過程框架還全面包括了可用于整個(gè)軟件過程的活動(dòng)，稱為“普適性活動(dòng)（Umbrella Activities）”。 10.1 軟件過程框架軟件過程框架的內(nèi)容 10.1 軟件過程框架軟件過程框架的內(nèi)容 過程框架：定義了若干框架活動(dòng)，這些活動(dòng)適用于所有軟件項(xiàng)目。普適性活動(dòng)：如軟件質(zhì)量保證，軟件配置管理和測量，它們貫穿于整個(gè)過程模型之中?？蚣芑顒?dòng)：框架中每一個(gè)活動(dòng)都由一組軟件工程動(dòng)作組成，每一個(gè)動(dòng)作又包含一個(gè)任務(wù)集合。任務(wù)集合：每一個(gè)集合都由軟件工程工作任務(wù)、項(xiàng)目里程碑、軟件工程產(chǎn)品以及質(zhì)量保證點(diǎn)組成

2、，使得框架活動(dòng)適應(yīng)于不同軟件項(xiàng)目的特征和項(xiàng)目組的需求。10.1 軟件過程框架通用過程框架通用過程框架可適用于絕大多數(shù)的軟件項(xiàng)目，該框架由溝通、策劃、建模、構(gòu)造和部署5個(gè)通用框架活動(dòng)組成。(1) 溝通。這項(xiàng)框架活動(dòng)包含系統(tǒng)分析員與客戶之間大量的交流和協(xié)作，還包括需求獲取以及其他相關(guān)活動(dòng)。 (2) 策劃。策劃活動(dòng)協(xié)助軟件開發(fā)團(tuán)隊(duì)定義全局目標(biāo)，并為后續(xù)的軟件工程工作制定計(jì)劃。策劃活動(dòng)包括一系列管理和技術(shù)實(shí)踐，如描述需要執(zhí)行的技術(shù)任務(wù)、可能的風(fēng)險(xiǎn)、資源需求、工作產(chǎn)品和工作進(jìn)度計(jì)劃。10.1 軟件過程框架通用過程框架(3) 建模。建模的目的是為了更好地理解需要構(gòu)建的實(shí)體。 在軟件工程中，要?jiǎng)?chuàng)建兩類模型：

3、分析模型和設(shè)計(jì)模型。分析模型通過描述軟件的信息域、功能域及行為域來表達(dá)客戶的需求；設(shè)計(jì)模型描述軟件架構(gòu)、用戶界面及構(gòu)件細(xì)節(jié)，從而幫助開發(fā)者高效地開發(fā)軟件。10.1 軟件過程框架通用過程框架(4) 構(gòu)造。構(gòu)造活動(dòng)包括一系列編碼和測試任務(wù)，從而為向客戶和最終用戶交付可運(yùn)行軟件做好準(zhǔn)備。(5) 部署。部署活動(dòng)是將軟件（全部或者完成的部分）交付給用戶，用戶對其進(jìn)行評測并給出反饋意見。 部署活動(dòng)包括三個(gè)動(dòng)作：交付、支持和反饋。10.1 軟件過程框架典型的普適性活動(dòng) (1) 軟件項(xiàng)目跟蹤和控制：由項(xiàng)目組根據(jù)計(jì)劃來評估項(xiàng)目進(jìn)度，并且采取必要的措施保證項(xiàng)目按進(jìn)度計(jì)劃進(jìn)行。(2) 風(fēng)險(xiǎn)管理：評估可能對項(xiàng)目成果或

4、者產(chǎn)品質(zhì)量產(chǎn)生影響的風(fēng)險(xiǎn)。(3) 軟件質(zhì)量保證：確定和執(zhí)行用以保證軟件質(zhì)量的活動(dòng)。(4) 正式技術(shù)評審：評估軟件工程產(chǎn)品，盡量在錯(cuò)誤傳播到下一個(gè)動(dòng)作或活動(dòng)之前，發(fā)現(xiàn)并清除錯(cuò)誤。10.1 軟件過程框架典型的普適性活動(dòng) (5)測量：定義和收集過程、項(xiàng)目和產(chǎn)品的度量，以幫助團(tuán)隊(duì)在發(fā)布軟件的時(shí)候滿足客戶要求。同時(shí)，測量還可與其他框架協(xié)同使用。(6)軟件配置管理：管理整個(gè)軟件過程中變更所帶來的影響。(7)可復(fù)用管理：定義產(chǎn)品復(fù)用的標(biāo)準(zhǔn)（包括軟件構(gòu)件），并且建立構(gòu)件復(fù)用機(jī)制。(8)工作產(chǎn)品的準(zhǔn)備和生產(chǎn)：包括創(chuàng)建產(chǎn)品所必須的活動(dòng)，如建模、文檔、日志、表格和列表等。10.2 傳統(tǒng)軟件過程模型瀑布模型在20世紀(jì)

5、80年代之前，瀑布模型一直是唯一被廣泛采用的生命周期模型。傳統(tǒng)的瀑布模型如圖所示。 10.2 傳統(tǒng)軟件過程模型瀑布模型的特點(diǎn)階段間具有順序性和依賴性。其中包含兩重含義： 必須等前一階段的工作完成之后，才能開始后一階段的工作； 前一階段的輸出文檔就是后一階段的輸入文檔。10.2 傳統(tǒng)軟件過程模型瀑布模型的特點(diǎn)推遲實(shí)現(xiàn)的觀點(diǎn) 瀑布模型在編碼之前設(shè)置了系統(tǒng)分析和系統(tǒng)設(shè)計(jì)的各個(gè)階段，分析與設(shè)計(jì)階段的基本任務(wù)規(guī)定，在這兩個(gè)階段主要考慮目標(biāo)系統(tǒng)的邏輯模型，不涉及軟件的物理實(shí)現(xiàn)。 清楚地區(qū)分邏輯設(shè)計(jì)與物理設(shè)計(jì)，盡可能推遲程序的物理實(shí)現(xiàn)，是按照瀑布模型開發(fā)軟件的一條重要的指導(dǎo)思想。10.2 傳統(tǒng)軟件過程模型瀑

6、布模型的特點(diǎn)質(zhì)量保證的觀點(diǎn) 每個(gè)階段都必須完成規(guī)定的文檔，沒有交出合格的文檔就是沒有完成該階段的任務(wù)。 每個(gè)階段結(jié)束前都要對所完成的文檔進(jìn)行評審，以便盡早發(fā)現(xiàn)問題，改正錯(cuò)誤。10.2 傳統(tǒng)軟件過程模型實(shí)際的瀑布模型實(shí)際的瀑布模型是帶“反饋環(huán)”的，如圖所示。 10.2 傳統(tǒng)軟件過程模型瀑布模型的優(yōu)點(diǎn)可強(qiáng)迫開發(fā)人員采用規(guī)范化的方法。嚴(yán)格地規(guī)定了每個(gè)階段必須提交的文檔。要求每個(gè)階段交出的所有產(chǎn)品都必須是經(jīng)過驗(yàn)證的。10.2 傳統(tǒng)軟件過程模型瀑布模型的缺點(diǎn)由于瀑布模型幾乎完全依賴于書面的規(guī)格說明，很可能導(dǎo)致最終開發(fā)出的軟件產(chǎn)品不能真正滿足用戶的需要。如果需求規(guī)格說明與用戶需求之間有差異，就會發(fā)生這種情

7、況。瀑布模型只適用于項(xiàng)目開始時(shí)需求已確定的情況。10.2 傳統(tǒng)軟件過程模型快速原型模型快速原型是快速建立起來的可以在計(jì)算機(jī)上運(yùn)行的程序，它所能完成的功能往往是最終產(chǎn)品能完成的功能的一個(gè)子集?？焖僭湍Ｐ腿鐖D所示，圖中實(shí)線箭頭表示開發(fā)過程，虛線箭頭表示維護(hù)過程。 10.2 傳統(tǒng)軟件過程模型快速原型模型的優(yōu)點(diǎn)(1)有助于滿足用戶的真實(shí)需求。(2)原型系統(tǒng)已經(jīng)通過與用戶的交互而得到驗(yàn)證，據(jù)此產(chǎn)生的規(guī)格說明文檔能夠正確地描述用戶需求。(3)軟件產(chǎn)品的開發(fā)基本上是按線性順序進(jìn)行。(4)因?yàn)橐?guī)格說明文檔正確地描述了用戶需求，因此，在開發(fā)過程的后續(xù)階段不會因?yàn)榘l(fā)現(xiàn)規(guī)格說明文檔的錯(cuò)誤而進(jìn)行較大的返工。 10.

8、2 傳統(tǒng)軟件過程模型快速原型模型的優(yōu)點(diǎn)(5)開發(fā)人員通過建立原型系統(tǒng)已經(jīng)學(xué)到了許多東西，因此，在設(shè)計(jì)和編碼階段發(fā)生錯(cuò)誤的可能性也比較小，這自然減少了在后續(xù)階段需要改正前面階段所犯錯(cuò)誤的可能性。(6) 快速原型的突出特點(diǎn)是“快速”。開發(fā)人員應(yīng)該盡可能快地建造出原型系統(tǒng)，以加速軟件開發(fā)過程，節(jié)約軟件開發(fā)成本。 原型的用途是獲知用戶的真正需求，一旦需求確定了，原型可以拋棄，當(dāng)然也可以在原型的基礎(chǔ)上進(jìn)行開發(fā)。10.2 傳統(tǒng)軟件過程模型增量模型 增量模型也稱為漸增模型，是Mills等于1980年提出來的。使用增量模型開發(fā)軟件時(shí)，把軟件產(chǎn)品作為一系列的增量構(gòu)件來設(shè)計(jì)、編碼、集成和測試。每個(gè)構(gòu)件由多個(gè)相互作

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

10、構(gòu)件開發(fā) 每個(gè)增量構(gòu)件應(yīng)當(dāng)實(shí)現(xiàn)某種系統(tǒng)功能，因此增量構(gòu)件的開發(fā)可以采用瀑布模型的方式，如圖所示。 10.2 傳統(tǒng)軟件過程模型采用增量模型需注意的問題 (1)在把每個(gè)新的增量構(gòu)件集成到現(xiàn)有軟件體系結(jié)構(gòu)中時(shí)，必須不破壞原來已經(jīng)開發(fā)出的產(chǎn)品。(2)軟件體系結(jié)構(gòu)必須是開放的，即向現(xiàn)有產(chǎn)品中加入新構(gòu)件的過程必須簡單、方便。 因此，采用增量模型比采用瀑布模型和快速原型模型更需要精心的設(shè)計(jì)。10.2 傳統(tǒng)軟件過程模型螺旋模型 螺旋模型最初是Boehm于1988年提出來的。該模型將瀑布模型與快速原型模型結(jié)合起來，并且加入兩種模型均忽略了的風(fēng)險(xiǎn)分析。螺旋模型的基本思想是，使用原型及其他方法來盡量降低風(fēng)險(xiǎn)。 10

11、.2 傳統(tǒng)軟件過程模型螺旋模型 理解這種模型的一個(gè)簡便方法，是把它看做在每個(gè)階段之前都增加了風(fēng)險(xiǎn)分析過程的快速原型模型。 10.2 傳統(tǒng)軟件過程模型完整的螺旋模型 10.2 傳統(tǒng)軟件過程模型完整的螺旋模型 在螺旋模型中，軟件過程表示成一個(gè)螺線，而不是像以往的模型那樣表示為一個(gè)具有回溯的活動(dòng)序列。在螺線上的每一個(gè)循環(huán)表示過程的一個(gè)階段。每個(gè)階段開始時(shí)的任務(wù)是確定該階段的目標(biāo)、為完成這些目標(biāo)選擇方案及設(shè)定這些方案的約束條件。接下來的任務(wù)是，從風(fēng)險(xiǎn)角度分析上一步的工作結(jié)果，努力排除各種潛在的風(fēng)險(xiǎn)，通常用建造原型的方法來排除風(fēng)險(xiǎn)。如果成功地排除了所有風(fēng)險(xiǎn)，則啟動(dòng)下一步開發(fā)步驟，在這個(gè)步驟的工作過程相當(dāng)

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

13、已有軟件的重用，也有助于把軟件質(zhì)量作為軟件開發(fā)的一個(gè)重要目標(biāo)。減少了過多測試或測試不足所帶來的風(fēng)險(xiǎn)。在螺旋模型中維護(hù)只是模型的另一個(gè)周期，因而在維護(hù)和開發(fā)之間并沒有本質(zhì)區(qū)別。10.2 傳統(tǒng)軟件過程模型螺旋模型的缺點(diǎn) 螺旋模型是風(fēng)險(xiǎn)驅(qū)動(dòng)的，因此要求軟件開發(fā)人員必須具有豐富的風(fēng)險(xiǎn)評估經(jīng)驗(yàn)和這方面的專門知識，否則將出現(xiàn)真正的風(fēng)險(xiǎn)：當(dāng)項(xiàng)目實(shí)際上正在走向?yàn)?zāi)難時(shí)，開發(fā)人員可能還以為一切正常。10.2 傳統(tǒng)軟件過程模型噴泉模型 噴泉模型是典型的面向?qū)ο笊芷谀Ｐ汀?“噴泉”一詞體現(xiàn)了迭代和無間隙特性。圖中代表不同階段的圓圈相互重疊，這明確表示兩個(gè)活動(dòng)之間存在重疊。 10.3 現(xiàn)代軟件過程模型基于構(gòu)件的開發(fā)

14、模型 基于構(gòu)件的軟件工程（component-based software engineering，CBSE）是強(qiáng)調(diào)使用可復(fù)用的軟件“構(gòu)件”來設(shè)計(jì)和構(gòu)造基于計(jì)算機(jī)的系統(tǒng)的過程。Clements對CBSE給出了如下描述。10.3 現(xiàn)代軟件過程模型基于構(gòu)件的開發(fā)模型 Clements對CBSE給出了如下描述。 CBSE正在改變大型軟件系統(tǒng)的開發(fā)方式。CBSE體現(xiàn)了Frod Brooks和其他人支持的“購買，而非構(gòu)造”的思想。就如同早期的子程序?qū)⒊绦騿T從考慮編程細(xì)節(jié)中解脫出來一樣，CBSE將考慮的重點(diǎn)從編碼轉(zhuǎn)移到組裝軟件系統(tǒng)。考慮的焦點(diǎn)是“集成”，而不再是“實(shí)現(xiàn)”。這樣做的基礎(chǔ)是假定在很多大型軟件系

15、統(tǒng)中存在足夠多的共性，使得開發(fā)可復(fù)用的構(gòu)件來滿足這些共性是可行的。10.3 現(xiàn)代軟件過程模型基于構(gòu)件的開發(fā)模型 當(dāng)軟件團(tuán)隊(duì)使用傳統(tǒng)的需求獲取技術(shù)確定了待開發(fā)軟件的系統(tǒng)需求時(shí)，該過程開始。體系結(jié)構(gòu)設(shè)計(jì)完成后，并不立即進(jìn)行詳細(xì)設(shè)計(jì)任務(wù)，而是針對每一系統(tǒng)需求考慮以下問題:(1)現(xiàn)有的商品化構(gòu)件（commercial off-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)是否相容？ 10.3 現(xiàn)代軟件過程模型基于構(gòu)件的開發(fā)模型 10.3 現(xiàn)代軟件過程模型開發(fā)步驟 不考慮構(gòu)件的開發(fā)技術(shù)，基于構(gòu)件的開發(fā)模型由以下步

16、驟組成： (1)對于該問題領(lǐng)域的基于構(gòu)件的可用產(chǎn)品進(jìn)行研究和評估。(2)考慮構(gòu)件集成的問題。(3)設(shè)計(jì)軟件架構(gòu)以容納這些構(gòu)件。(4)將構(gòu)件集成到架構(gòu)中。(5)進(jìn)行充分的測試以保證功能正常。10.3 現(xiàn)代軟件過程模型典型的構(gòu)件模型 (1)OMG/CORBA。對象管理組織發(fā)布了公共對象請求代理體系結(jié)構(gòu)（OMG/CORBA），一個(gè)對象請求代理提供了多種服務(wù)使得可復(fù)用構(gòu)件（對象）可以與其他構(gòu)件通信。(2)Microsoft COM。微軟公司開發(fā)了構(gòu)件對象模型（COM），此模型提供了運(yùn)行于Windows操作系統(tǒng)下的單個(gè)應(yīng)用中使用不同廠商生產(chǎn)的構(gòu)件的規(guī)格說明。(3)Sun JavaBean構(gòu)件。JavaB

17、ean構(gòu)件系統(tǒng)是一個(gè)可移植的、平臺獨(dú)立的、使用Java程序設(shè)計(jì)語言開發(fā)的CBSE基礎(chǔ)設(shè)施。 10.3 現(xiàn)代軟件過程模型形式化方法模型 形式化系統(tǒng)開發(fā)模型是一種基于形式化數(shù)學(xué)變換的軟件開發(fā)方法，它可將系統(tǒng)規(guī)格說明轉(zhuǎn)換為可執(zhí)行的程序。 10.3 現(xiàn)代軟件過程模型與瀑布模型的區(qū)別 軟件需求規(guī)格說明被細(xì)化為用數(shù)學(xué)記號表達(dá)的詳細(xì)的形式化規(guī)格說明。設(shè)計(jì)、實(shí)現(xiàn)和單元測試等開發(fā)過程由變換開發(fā)過程代替。通過一系列變換將形式化規(guī)格說明細(xì)化成為程序。這種細(xì)化的過程如圖所示。10.3 現(xiàn)代軟件過程模型面向方面的軟件開發(fā) 面向方面的軟件開發(fā)（aspect-oriented software development，AO

18、SD）通常稱為面向方面編程（aspect-oriented progamming，AOP），是相對較新的一種軟件工程模型，為定義、說明、設(shè)計(jì)和構(gòu)建方面（aspect）提供過程和方法。 10.3 現(xiàn)代軟件過程模型統(tǒng)一過程 由Booch、Jacobson及Rumbaugh提出，統(tǒng)一過程模型如圖所示。 10.3 現(xiàn)代軟件過程模型統(tǒng)一過程的工作流 在統(tǒng)一過程中，有5個(gè)核心工作流。 需求工作流。需求工作流的目標(biāo)是確保開發(fā)人員構(gòu)建正確的系統(tǒng)。 分析工作流。分析工作流的目標(biāo)是分析和細(xì)化需求。 設(shè)計(jì)工作流。設(shè)計(jì)工作流是對分析工作流的細(xì)化，直到設(shè)計(jì)模型可以被程序員實(shí)現(xiàn)為止。 實(shí)現(xiàn)工作流。實(shí)現(xiàn)工作流的目標(biāo)是：用選

19、擇的實(shí)現(xiàn)語言實(shí)現(xiàn)目標(biāo)信息系統(tǒng)。 測試工作流。測試工作流是質(zhì)量保證組的職責(zé)。10.3 現(xiàn)代軟件過程模型統(tǒng)一過程的階段 統(tǒng)一過程有4個(gè)階段，分別是初始階段、細(xì)化階段、構(gòu)造階段和移交階段。 初始階段。初始階段主要關(guān)注項(xiàng)目計(jì)劃和風(fēng)險(xiǎn)評估，其目的是確定是否值得開發(fā)目標(biāo)信息系統(tǒng)。 細(xì)化階段。細(xì)化階段關(guān)心定義系統(tǒng)的總體框架，其目標(biāo)是：細(xì)化初始需求（用況）、細(xì)化體系結(jié)構(gòu)、監(jiān)控風(fēng)險(xiǎn)并細(xì)化它們的優(yōu)先級、細(xì)化業(yè)務(wù)案例以及制訂項(xiàng)目管理計(jì)劃。 構(gòu)造階段。構(gòu)造階段是建立系統(tǒng)，構(gòu)造信息系統(tǒng)的第1個(gè)具有操作質(zhì)量的版本，以能夠交付給客戶進(jìn)行測試的版本結(jié)束，有時(shí)稱為測試版本。 移交階段。移交階段包含測試時(shí)期，以發(fā)布完整的系統(tǒng)而終

20、止，其目標(biāo)是確保信息系統(tǒng)真正滿足客戶的需求。 10.3 現(xiàn)代軟件過程模型敏捷過程模型 2001年，Kent Beck等17名編程大師發(fā)表“敏捷軟件開發(fā)”宣言： 我們正在通過親身實(shí)踐以及幫助他人實(shí)踐的方式來揭示更好的軟件開發(fā)之路，通過這項(xiàng)工作，我們認(rèn)為： 個(gè)體和交互勝過過程和工具； 可工作軟件勝過寬泛的文檔； 客戶合作勝過合同談判； 響應(yīng)變化勝過遵循計(jì)劃。 10.3 現(xiàn)代軟件過程模型敏捷過程模型 對于敏捷開發(fā)，Ivar Jacobson給出了下面非常有用的論述。 “敏捷（Agility）已經(jīng)成為當(dāng)今現(xiàn)代軟件過程的一個(gè)時(shí)髦用詞。每個(gè)人都是敏捷的，敏捷團(tuán)隊(duì)是能夠適當(dāng)響應(yīng)變化的靈活團(tuán)隊(duì)。變化就是軟件開

21、發(fā)本身，軟件構(gòu)建有變化、團(tuán)隊(duì)成員在變化、使用新技術(shù)會帶來變化，各種變化都會對開發(fā)的軟件產(chǎn)品以及項(xiàng)目本身造成影響。我們必須接受的是支持變化的意識，它應(yīng)當(dāng)根植于軟件開發(fā)中的每一件事中，因?yàn)檫@是軟件的心臟與靈魂。敏捷團(tuán)隊(duì)意識到軟件是團(tuán)隊(duì)中所有人共同開發(fā)完成的，這些人的個(gè)人技能和合作能力是項(xiàng)目成功的關(guān)鍵所在?！?0.3 現(xiàn)代軟件過程模型敏捷過程模型 任何一個(gè)敏捷過程都可以由所強(qiáng)調(diào)的3個(gè)關(guān)鍵假設(shè)識別出來，這3個(gè)假設(shè)可適用于大多數(shù)軟件項(xiàng)目。(1) 提前預(yù)測哪些需求是穩(wěn)定的、哪些需求會變化非常困難。同樣的，預(yù)測項(xiàng)目進(jìn)行中客戶優(yōu)先級的變化也很困難。(2) 對很多軟件，設(shè)計(jì)和構(gòu)建是交錯(cuò)進(jìn)行的。事實(shí)上，兩種活動(dòng)應(yīng)

22、當(dāng)順序開展以保證通過構(gòu)建實(shí)施來驗(yàn)證設(shè)計(jì)模型，而在通過構(gòu)建驗(yàn)證之前很難估計(jì)應(yīng)該設(shè)計(jì)到什么程度。(3) 從制訂計(jì)劃的角度來看，分析、設(shè)計(jì)、構(gòu)建和測試并不像我們所設(shè)想的那么容易預(yù)測。10.3 現(xiàn)代軟件過程模型極限編程 極限編程（eXtreme Programming，XP）使用面向?qū)ο蠓椒ㄗ鳛橥扑]的開發(fā)范型。XP包含了策劃、設(shè)計(jì)、編碼和測試4個(gè)框架活動(dòng)的規(guī)則和實(shí)踐。 10.3 現(xiàn)代軟件過程模型極限編程的框架活動(dòng) 策劃。策劃活動(dòng)開始于建立健全描述待開發(fā)軟件特征與功能需求的“故事”（也稱為用戶故事）。 設(shè)計(jì)。XP設(shè)計(jì)嚴(yán)格遵循KIS（keep it simple， 保持簡潔）原則，通常更愿意使用簡單設(shè)計(jì)而不是更為復(fù)雜的表述。 編碼。XP推薦在故事開發(fā)和基本設(shè)計(jì)完成之后，團(tuán)隊(duì)不應(yīng)直接開始編碼，而是開發(fā)一系列用于檢測本次（軟件增量）發(fā)行包括所有故事的單元測試，一旦建立起單元測試，開發(fā)者就可以更集中精力于必須實(shí)現(xiàn)的內(nèi)容以通過單元測試。 測試。 10.3 現(xiàn)代軟件過程模型自適應(yīng)軟件開發(fā) 自適應(yīng)軟件開發(fā)（adapt