軟件工程課件：第2章 軟件過程

1、第二章軟件過程1軟件工程 - 2013 - 第二章 軟件過程第二章內(nèi)容概要過程、軟件過程經(jīng)典軟件過程模型2軟件工程 - 2013 - 第二章 軟件過程過程：產(chǎn)生某種預定輸出的一系列可預測的步驟，包含一組活動（activities）、約束（constraints）、資源（resources）。ISO 9000對過程的定義: 使用資源將輸入轉(zhuǎn)化為輸出的活動所構(gòu)成的系統(tǒng)。過程（Process）3軟件工程 - 2013 - 第二章 軟件過程過程使用一定的資源，受一定的約束，并生成一定的中間及最終產(chǎn)品；過程中所包含的活動事先都規(guī)定好了；過程中每個活動的開始、結(jié)束有明確的規(guī)定；每項活動都有相應的指導原則，

2、用以明確其目標；各活動之間以某種順序組織；過程可能包括若干相互關(guān)聯(lián)的子過程；過程中的活動、資源以及產(chǎn)品都可能受到約束。過程的特性4軟件工程 - 2013 - 第二章 軟件過程過程能使一組活動具有一致性和質(zhì)量：不同的人使用同一過程能獲得在某一層次上一致的產(chǎn)品；一致性并不排斥靈活性，一致性是在某一層次上實現(xiàn)的；過程可被檢查、理解、控制和改進；過程也是傳授經(jīng)驗的一種途徑。為何使用過程5軟件工程 - 2013 - 第二章 軟件過程軟件過程：為建造高質(zhì)量軟件所需完成的任務的框架，它規(guī)定了完成各項任務的工作步驟。軟件過程與軟件工程6軟件工程 - 2013 - 第二章 軟件過程第二章內(nèi)容概要過程、軟件過程和

3、軟件生命周期經(jīng)典軟件過程模型7軟件工程 - 2013 - 第二章 軟件過程軟件過程模型是對被描述的實際過程的抽象，即是從某種特定角度提出的對軟件過程的簡化描述。經(jīng)典軟件過程模型可為我們提供一些范例軟件過程模型8軟件工程 - 2013 - 第二章 軟件過程也叫線性順序模型或傳統(tǒng)生存周期模型；它將軟件開發(fā)過程劃分成若干相互區(qū)別而又彼此聯(lián)系的階段，每個階段中的工作都以上一個階段工作的結(jié)果為依據(jù)，同時為下一個階段的工作提供了前提；瀑布模型的本質(zhì)是“一次通過”；它是一種文檔驅(qū)動模型，在可運行產(chǎn)品交付之前，客戶只能通過文檔來了解最終的產(chǎn)品會是什么樣子。瀑布模型9軟件工程 - 2013 - 第二章 軟件過程

4、瀑布模型10軟件工程 - 2013 - 第二章 軟件過程階段間具有順序性和依賴性必須等前一階段的工作完成之后，才能開始后一階段的工作前一階段的輸出文檔就是后一階段的輸入文檔瀑布模型的特點11軟件工程 - 2013 - 第二章 軟件過程推遲實現(xiàn)的觀點對于規(guī)模較大的軟件項目來說，編碼開始得越早，最終完成開發(fā)工作所需要的時間反而越長。瀑布模型在編碼之前設置了系統(tǒng)分析與系統(tǒng)設計階段，在這兩個階段主要考慮目標系統(tǒng)的邏輯模型，不涉及軟件的物理實現(xiàn)。清楚地區(qū)分邏輯設計與物理設計，盡可能推遲程序的物理實現(xiàn)，是瀑布模型開發(fā)軟件的一條重要的指導思想。瀑布模型的特點12軟件工程 - 2013 - 第二章 軟件過程質(zhì)

5、量保證的觀點每個階段都必須完成規(guī)定的文檔，沒有交出合格的文檔就是沒有完成該階段的任務。每個階段結(jié)束前都要對所完成的文檔進行評審，以便盡早發(fā)現(xiàn)問題，改正錯誤。瀑布模型的特點13軟件工程 - 2013 - 第二章 軟件過程可強迫開發(fā)人員采用規(guī)范的方法（例如，結(jié)構(gòu)化技術(shù)）嚴格地規(guī)定了每個階段必須提交的文檔，使軟件的維護易于進行。要求每個階段交出的所有產(chǎn)品都必須經(jīng)過質(zhì)量保證小組的仔細驗證，能夠保證軟件產(chǎn)品的質(zhì)量。 瀑布模型的成功在很大程度上是由于它基本上是一種文檔驅(qū)動的模型瀑布模型的優(yōu)點14軟件工程 - 2013 - 第二章 軟件過程將本來非線性的軟件開發(fā)過程人為地加以線性化，不符合實際中的軟件開發(fā)情

6、況；在項目的開始階段難以清楚地給出所有需求；軟件開發(fā)耗時長，可運行版本要等到項目后期才能得到，一旦在后期發(fā)現(xiàn)錯誤，付出的代價將是巨大的?！坝晌臋n驅(qū)動”的這個事實也是瀑布模型的一個主要缺點，這可能導致最終開發(fā)出的軟件產(chǎn)品不能真正滿足用戶的需要。瀑布模型的缺點15軟件工程 - 2013 - 第二章 軟件過程V模型16軟件工程 - 2013 - 第二章 軟件過程瀑布模型的改進，強調(diào)測試活動與分析和設計之間的關(guān)聯(lián)：單元測試校驗程序設計；集成測試校驗系統(tǒng)設計；確認測試確認需求；與瀑布模型關(guān)注文檔和工作產(chǎn)品不同，V模型的關(guān)注點是軟件開發(fā)各階段的活動以及正確性，因此V模型是以活動驅(qū)動的。V模型17軟件工程

7、- 2013 - 第二章 軟件過程本質(zhì)是把瀑布模型中一些隱含的迭代過程明確出來，使開發(fā)活動和驗證活動的相關(guān)性更加明顯；V模型使抽象等級的概念也更明顯：所有從需求到實現(xiàn)部分的活動關(guān)注的是建立更多的系統(tǒng)詳細表述，而所有從實現(xiàn)到交付運行的活動關(guān)注的是對系統(tǒng)的驗證和確認。和瀑布模型一樣，都是對軟件開發(fā)過程過分簡單、理想化的抽象，對需求變化的適應性差。V模型的改良之處與存在的問題18軟件工程 - 2013 - 第二章 軟件過程所謂原型，是一個可以實際運行的模型，它在功能上可以看作是最終產(chǎn)品的一個子集（展示了目標系統(tǒng)的關(guān)鍵功能）。原型/快速原型模型19軟件工程 - 2013 - 第二章 軟件過程原型/快速

8、原型模型20軟件工程 - 2013 - 第二章 軟件過程原型/快速原型模型21軟件工程 - 2013 - 第二章 軟件過程原型模型的優(yōu)勢：快速原型模型是不帶反饋環(huán)的，軟件產(chǎn)品的開發(fā)基本上是線性順序進行的：原型系統(tǒng)已經(jīng)通過與用戶交互而得到驗證開發(fā)人員通過建立原型系統(tǒng)已經(jīng)學到了許多東西利用原型能統(tǒng)一客戶和開發(fā)人員對軟件項目需求的理解，有助于需求的定義和確認；可以考慮結(jié)合瀑布模型，二者互補性強。用快速原型做為需求分析的一種技術(shù)，用于收集客戶的真實需求，然后把客戶滿意了的原型再作為瀑布模型的輸入，從而達到優(yōu)勢互補。原型/快速原型模型22軟件工程 - 2013 - 第二章 軟件過程使用原型必須要注意的問

9、題：由于要求能夠快速建立可供運行的模型，原型不可能象最終產(chǎn)品一樣面面俱到；客戶：不可把原型當作軟件的正式運行版本；開發(fā)人員：同上。還必須牢記原型中沒有考慮質(zhì)量因素的部分；使用前要與用戶達成一致：原型只是模型而已。原型/快速原型模型23軟件工程 - 2013 - 第二章 軟件過程階段式開發(fā)（演化模型）24軟件工程 - 2013 - 第二章 軟件過程軟件系統(tǒng)和其他所有復雜系統(tǒng)一樣，是隨著時間不斷演化的。業(yè)務需求和產(chǎn)品需求隨著開發(fā)向前推進經(jīng)常發(fā)生改變，這使得直線式的開發(fā)模型不切實際。來自時間、成本、人力以及技術(shù)等方面的壓力往往使得演化成為軟件開發(fā)的必經(jīng)之路。階段式開發(fā)大體分為兩種：漸增式開發(fā)迭代式開

10、發(fā)階段式開發(fā)（演化模型）25軟件工程 - 2013 - 第二章 軟件過程階段式開發(fā)（演化模型）增量開發(fā)迭代開發(fā)增量和迭代模型26軟件工程 - 2013 - 第二章 軟件過程增量模型采用隨著日程時間的進展而交錯的線性序列，每一個序列產(chǎn)生軟件的一個可發(fā)布的“增量”；第一個增量往往是核心的產(chǎn)品，實現(xiàn)最基本需求，提供最基本功能；其他補充的產(chǎn)品特征（包括已知的和未知的）留待后續(xù)發(fā)布；這個過程在每個增量發(fā)布后不斷重復，直到產(chǎn)生最終完善的產(chǎn)品。增量模型（漸增模型）27軟件工程 - 2013 - 第二章 軟件過程增量模型（漸增模型）28軟件工程 - 2013 - 第二章 軟件過程增量模型的優(yōu)點：適用于人員配備

11、不充裕、不能在軟件項目期限之前實現(xiàn)一個完全版本的軟件的情況；能有計劃地管理技術(shù)風險；每個增量都發(fā)布了一個可操作的版本，用戶能在較短時間內(nèi)使用上部分功能；可以提前開始培訓、提前開拓市場；使問題修正易于進行；逐步增加產(chǎn)品功能可以使用戶有較充裕的時間學習和適應新產(chǎn)品，減少一個全新的軟件可能給客戶帶來的沖擊；可以針對不同領域開發(fā)不同版本。增量模型（漸增模型）29軟件工程 - 2013 - 第二章 軟件過程增量模型存在的困難：要求每個新的增量構(gòu)件能夠無縫地集成到現(xiàn)有的軟件體系結(jié)構(gòu)中，必須不破壞原來已經(jīng)開發(fā)的產(chǎn)品；因此軟件體系結(jié)構(gòu)必須是開放的，增加了設計階段的投入；本身具有矛盾性，一方面要求開發(fā)人員把軟件

12、看作一個整體，另一方面要求開發(fā)人員把軟件看作構(gòu)件序列，且構(gòu)件間彼此獨立。需要開發(fā)人員協(xié)調(diào)這一矛盾。增量模型（漸增模型）30軟件工程 - 2013 - 第二章 軟件過程增量模型(漸增模型)風險更大的增量模型31軟件工程 - 2013 - 第二章 軟件過程軟件項目中的風險：人員硬件設備項目的生存能力等通過使用原型或其他手段降低風險，是螺旋模型中蘊涵的基本思想；可以把螺旋模型簡單地理解為在每一個階段之前都增加了風險分析的快速原型模型。螺旋模型32軟件工程 - 2013 - 第二章 軟件過程螺旋模型33軟件工程 - 2013 - 第二章 軟件過程螺旋模型制定計劃確定軟件目標，選定實施方案，弄清項目開發(fā)

13、的限制；風險分析分析所選方案，考慮如何識別和消除風險；實施工程實施軟件開發(fā)；客戶評估評價開發(fā)工作，提出修正建議，并計劃下一個階段的任務；34軟件工程 - 2013 - 第二章 軟件過程螺旋模型是對瀑布模型的發(fā)展，并由客戶對階段性產(chǎn)品做出評審，這對保證軟件產(chǎn)品質(zhì)量十分有利；由于引入風險分析等活動，測試活動的確定性增強了；螺旋模型最外層代表維護，開發(fā)與維護采用同樣方式，使維護得到與開發(fā)同樣的重視。螺旋模型的優(yōu)點35軟件工程 - 2013 - 第二章 軟件過程主要適合內(nèi)部開發(fā)，否則風險分析必須在簽訂合同前完成，或者爭取客戶的最大理解；只適合大型軟件項目的開發(fā)，否則，每個階段的風險分析將占用很大一部分

14、資源，增加成本；對開發(fā)人員的風險分析能力是極大的考驗，否則，模型將退化到瀑布模型，甚至更糟。螺旋模型的缺點36軟件工程 - 2013 - 第二章 軟件過程噴泉模型進一步開發(fā)運行狀態(tài)集成和測試階段編碼階段面向?qū)ο笤O計階段面向?qū)ο蠓治鲭A段需求階段維護期“噴泉”體現(xiàn)了面向?qū)ο筌浖_發(fā)過程迭代和無縫的特性37軟件工程 - 2013 - 第二章 軟件過程注意事項 為避免使用噴泉模型開發(fā)軟件時開發(fā)過程過于無序，應該把一個線形過程作為總目標面向?qū)ο蠓缎捅旧硪蠼?jīng)常對開發(fā)活動進行迭代或求精噴泉模型38軟件工程 - 2013 - 第二章 軟件過程軟件過程模式從成功或失敗的軟件開發(fā)實踐中總結(jié)而成，是軟件過程中生命

15、周期、人員、方法、產(chǎn)品四大類要素相互關(guān)聯(lián)的有機整體：人員：誰產(chǎn)品：為實現(xiàn)什么方法：如何生命周期：（何時）做什么幾種典型的軟件過程模式：Rational統(tǒng)一過程、敏捷過程、微軟過程軟件過程模式39軟件工程 - 2013 - 第二章 軟件過程由Rational公司提出并維護，具有多功能性和廣泛的適用性生命周期：迭代與增量的二維生命周期結(jié)構(gòu)人員：按“角色”進行劃分方法：UML建模、基于用例驅(qū)動和以架構(gòu)為中心的分析設計，并提供了一整套支持工具產(chǎn)品：工件Rational統(tǒng)一過程( Rational Unified Process, RUP)40軟件工程 - 2013 - 第二章 軟件過程迭代式開發(fā) 容納

16、需求變更/減少風險管理需求 使用用例和腳本使用基于構(gòu)件的體系結(jié)構(gòu) 功能清晰的模塊和子系統(tǒng)可視化建模模型可為文字、圖形、數(shù)學表達式驗證軟件質(zhì)量 質(zhì)量評估內(nèi)建在貫穿于整個開發(fā)過程的、由全體成員參與的所有活動中控制軟件變更 控制、跟蹤、監(jiān)控修改RUP開發(fā)經(jīng)驗（最佳實踐）41軟件工程 - 2013 - 第二章 軟件過程1. 用戶（user）：用戶代表與所開發(fā)的系統(tǒng)進行交互的某個人或某個系統(tǒng)。2. 用例（use case）：能夠向用戶提供有價值的結(jié)果的一項系統(tǒng)功能。“用例驅(qū)動”3. 架構(gòu)（architecture）：系統(tǒng)在其所處的環(huán)境中最高層次的概念。軟件系統(tǒng)的架構(gòu)是指通過接口交互的重要構(gòu)件的組織和結(jié)構(gòu)

17、?！耙约軜?gòu)為中心”4. 工作流程（workflow）：在業(yè)務中執(zhí)行的活動序列，它相對于業(yè)務主角個體生成一個可見值結(jié)果。5. 角色（worker）：在軟件過程組織的環(huán)境中，個人或協(xié)同工作的小組的行為和職責定義為角色。RUP 術(shù)語（一）42軟件工程 - 2013 - 第二章 軟件過程6. 迭代（iteration）與增量（increment）：迭代是階段中的一個子項目，其結(jié)果是生成系統(tǒng)的一個內(nèi)部或外部的發(fā)布版本。增量是指在后續(xù)迭代結(jié)束后，兩個發(fā)布版本之間存在的差異或差值?！暗驮隽康倪^程”7. 活動（activity）：是要求角色執(zhí)行的工作單元。8. 工件（artifacts）：是一條信息，有三

18、個特性：由過程生成、修改和使用；定義了職責范圍；受到版本控制。9. 階段（phase）和里程碑（milestone）里程碑是迭代正式結(jié)束的時間點。階段是項目中相鄰兩個主要里程碑之間的時間段，在此期間要實現(xiàn)一組既定的目標、完成工件并決定是否進入下一階段。RUP 術(shù)語（二）43軟件工程 - 2013 - 第二章 軟件過程RUP軟件開發(fā)生命周期（二維結(jié)構(gòu)生命周期）初始精化構(gòu)建移交初始精化1精化2構(gòu)建1構(gòu)建2構(gòu)建3移交1移交2環(huán)境工作流業(yè)務建模需求分析與設計實現(xiàn)測試部署項目管理階段配置與變更管理44軟件工程 - 2013 - 第二章 軟件過程1. 業(yè)務建模：描述了如何擬定新目標組織的前景，并基于該前景

19、來確定該組織在業(yè)務用例模型和業(yè)務對象模型中的流程、角色以及職責。主要角色：業(yè)務流程分析員、業(yè)務設計員、業(yè)務模型復審員主要工件：業(yè)務模型（包括業(yè)務用例模型和業(yè)務對象模型）2. 需求：描述系統(tǒng)應該做什么，即捕獲需求，并使開發(fā)人員和用戶就這一需求描述達成共識。主要角色：系統(tǒng)分析員、用戶界面設計員、需求復審員主要工件：用例模型和用戶界面模型生命周期的靜態(tài)結(jié)構(gòu)九個核心工作流程45軟件工程 - 2013 - 第二章 軟件過程3. 分析設計：將需求轉(zhuǎn)化成對未來系統(tǒng)的設計，為系統(tǒng)開發(fā)一個健壯的結(jié)構(gòu)，并調(diào)整設計使其與實現(xiàn)環(huán)境相匹配，優(yōu)化其性能。主要角色：架構(gòu)設計師、架構(gòu)復審員、設計員、數(shù)據(jù)庫設計員、設計復審員主

20、要工件：設計模型和可選的分析模型4. 實現(xiàn)：以層次化的子系統(tǒng)形式化地定義代碼的組織結(jié)構(gòu)；以構(gòu)件的形式實現(xiàn)類和對象；將開發(fā)出的構(gòu)件作為單元進行測試；將各實施人員（或團隊）完成的結(jié)果集成到可執(zhí)行系統(tǒng)中。主要角色：架構(gòu)設計員、實施員、集成員、代碼復審員主要工件：實現(xiàn)模型生命周期的靜態(tài)結(jié)構(gòu)九個核心工作流程46軟件工程 - 2013 - 第二章 軟件過程5. 測試：檢驗對象間的交互作用，驗證軟件中所有構(gòu)件是否正確集成，檢驗所有需求是否被正確的實現(xiàn)，識別、確認缺陷并確保在軟件部署之前將缺陷解決。主要角色：測試設計員、測試員主要工件：測試模型和測試結(jié)果6. 部署：成功地生成產(chǎn)品版本并將軟件分發(fā)給最終用戶。主

21、要角色：部署經(jīng)理、實施人員、技術(shù)文檔編寫員、培訓開發(fā)員主要工件：產(chǎn)品的一個版本和文檔培訓資料生命周期的靜態(tài)結(jié)構(gòu)九個核心工作流程47軟件工程 - 2013 - 第二章 軟件過程7. 配置和變更管理：描述了如何在多個成員組成的項目中控制大量的產(chǎn)品，并提供了相應準則來管理演化系統(tǒng)中的多個變體，跟蹤軟件創(chuàng)建過程中的版本變更主要角色：配置經(jīng)理、變更控制經(jīng)理、集成員主要工件：配置管理計劃、變更請求、項目存儲庫和工作區(qū)8. 項目管理：平衡競爭的目標、管理風險并克服各種約束，從而成功交付使用戶滿意的產(chǎn)品主要角色：項目經(jīng)理、項目復審員主要工件：商業(yè)理由、迭代計劃、風險管理計劃、質(zhì)量保證計劃及相應的評估文檔9.

22、環(huán)境：向軟件開發(fā)組織提供軟件開發(fā)的環(huán)境，包括過程和工具主要角色：過程工程師、工具專家主要工件：工作流程指南和工具、工具指南生命周期的靜態(tài)結(jié)構(gòu)九個核心工作流程48軟件工程 - 2013 - 第二章 軟件過程49軟件工程 - 2013 - 第二章 軟件過程50軟件工程 - 2013 - 第二章 軟件過程51軟件工程 - 2013 - 第二章 軟件過程52軟件工程 - 2013 - 第二章 軟件過程初始階段（Inception）：建立業(yè)務用例和確定項目的范圍生命周期目標里程碑主要項目干系人對系統(tǒng)的范圍達成一致意見；對是否已經(jīng)獲得正確的需求集達成一致意見，并且對這些需求的理解是共同的；對成本/進度估算

23、、優(yōu)先級、風險和開發(fā)流程達成一致意見；已經(jīng)確定所有風險并且有針對每個風險的風險降低策略。生命周期的動態(tài)結(jié)構(gòu)四個階段53軟件工程 - 2013 - 第二章 軟件過程精化階段（Elaboration）：建立穩(wěn)定的架構(gòu)、編制項目計劃和淘汰項目中風險最高的元素生命周期架構(gòu)里程碑產(chǎn)品前景和需求是穩(wěn)定的；架構(gòu)是穩(wěn)定的；可執(zhí)行原型表明已經(jīng)找到了主要的風險元素，并且已得到妥善解決；構(gòu)建階段的迭代計劃足夠詳細和真實，可以保證工作繼續(xù)進行；構(gòu)建階段的迭代計劃有可靠的估算支持；所有項目干系人一致認為，如果在當前架構(gòu)環(huán)境中執(zhí)行當前計劃來開發(fā)完整的系統(tǒng)，則當前的前景可以實現(xiàn)；實際的資源耗費與計劃的耗費相比是可以接受的。

24、生命周期的動態(tài)結(jié)構(gòu)四個階段54軟件工程 - 2013 - 第二章 軟件過程構(gòu)建階段（Construction）：所有構(gòu)件和應用程序功能被開發(fā)并集成為產(chǎn)品，所有的功能被詳盡地測試初始可操作性能里程碑該產(chǎn)品發(fā)布版已經(jīng)足夠穩(wěn)定和成熟，可部署在用戶群中；所有項目干系人已準備好將產(chǎn)品發(fā)布到用戶群；實際的資源耗費與計劃相比仍可以接受。移交階段（Transition）：將軟件產(chǎn)品交付給用戶群體產(chǎn)品發(fā)布里程碑用戶滿意；實際的資源耗費與計劃的耗費相比可以接受。生命周期的動態(tài)結(jié)構(gòu)四個階段55軟件工程 - 2013 - 第二章 軟件過程56軟件工程 - 2013 - 第二章 軟件過程與螺旋模型相比相似：重復一系列組

25、成系統(tǒng)生命周期的循環(huán)差異：RUP給出了每個階段內(nèi)的若干次迭代過程完成后交付的增量的具體要求，即 四個階段的里程碑RUP詳細闡述了不同階段的不同迭代過程經(jīng)歷的九大核心工作流程中活動內(nèi)容的重點和強度不同RUP提供了對每次迭代過程中不同核心工作流程活動的并行化支持優(yōu)點：用于指導需求不明確、不穩(wěn)定的項目開發(fā)時具有更強的可操作性。RUP生命周期的特點57軟件工程 - 2013 - 第二章 軟件過程與瀑布模型相比優(yōu)點：RUP將成本風險進一步降低為獲得一次增量所需的費用RUP進一步降低了產(chǎn)品不能按計劃投放市場的風險RUP使項目開發(fā)更能適應項目需求的變化RUP生命周期的特點58軟件工程 - 2013 - 第二

26、章 軟件過程角色的劃分及相關(guān)活動RUP定義了五大類角色集：分析員、開發(fā)人員、測試員、經(jīng)理、其他角色。每一類角色集又包括多個角色，并給出了每個角色對應的活動。角色的意義將角色和個體區(qū)分開來，有效提高了項目中人力資源的利用率。角色方面的缺陷未給出角色的組織管理方式、角色間的相互地位關(guān)系和交互方式。RUP的人員角色及其活動59軟件工程 - 2013 - 第二章 軟件過程方法：用例及用例驅(qū)動用例是捕獲需求的有效方法用例驅(qū)動整個RUP過程以架構(gòu)為中心在面向?qū)ο蟮姆治鲈O計中采用UML進行可視化建模面向?qū)ο蟮脑O計與構(gòu)件實現(xiàn)工具：Rational SolutionsRUP的方法方法與工具60軟件工程 - 20

27、13 - 第二章 軟件過程優(yōu)點：用例驅(qū)動、以架構(gòu)為中心、迭代和增量的；具有二維迭代性，有利于降低風險、適應需求變化；是可配置的，具有通用性；缺點：是在理想的項目開發(fā)環(huán)境下軟件過程的一種完美模式；未給出具體的剪裁、擴充等配置實施的方法準則。RUP的特點61軟件工程 - 2013 - 第二章 軟件過程敏捷過程敏捷過程（2001/2敏捷軟件開發(fā)宣言 The Manifesto of the Agile Alliance ）強調(diào)適應而非預測變化以人為中心相關(guān)流派：極限編程（eXtreme Programming）、SCRUM、動態(tài)軟件開發(fā)方法（Dynamic System Development Me

28、thod）、水晶系列方法（Crystal Methodologies）、適配性軟件開發(fā)（Adaptive Software Development）、特征驅(qū)動開發(fā)（Feature Driven Development）、開放式源碼（Open Source）等62軟件工程 - 2013 - 第二章 軟件過程敏捷過程的價值觀個體和交互勝過過程和工具可以工作的軟件勝過面面俱到的文檔客戶合作勝過合同談判響應變化勝過遵循計劃敏捷過程的價值觀與原則63軟件工程 - 2013 - 第二章 軟件過程個體和交互勝過過程和工具人是軟件項目獲得成功最為重要的因素合作、溝通及交互能力比單純的軟件編程能力更為重要。合適

29、的工具雖然重要，但不能過分夸大工具的作用。團隊的構(gòu)建（包括個體、交互等）要比項目環(huán)境（包括過程、工具）的構(gòu)建更重要。敏捷過程的價值觀與原則64軟件工程 - 2013 - 第二章 軟件過程可以工作的軟件勝過面面俱到的文檔軟件開發(fā)的主要目標是交付可以工作的軟件。沒有文檔的軟件是一種災難，但過多的面面俱到的文檔比過少的文檔更糟。軟件開發(fā)的主要和中心活動是創(chuàng)建可以工作的軟件?！爸钡狡惹行枰乙饬x重大時，才進行文檔編制”Martin文檔第一定律。編制的內(nèi)部文檔應盡量短小并且主題突出。敏捷過程的價值觀與原則65軟件工程 - 2013 - 第二章 軟件過程客戶合作勝過合同談判需求、進度和項目成本的合同在根本

30、上是存在缺陷的。為開發(fā)團隊和客戶的協(xié)同工作方式提供指導的合同才是最好的合同。敏捷過程的價值觀與原則66軟件工程 - 2013 - 第二章 軟件過程響應變化勝過遵循計劃軟件過程必須有足夠的能力及時響應變化。計劃必須有足夠的靈活性與可塑性制定細致度逐漸降低的計劃敏捷過程的價值觀與原則67軟件工程 - 2013 - 第二章 軟件過程敏捷過程的12條基本原則我們最優(yōu)先要做的是通過盡早的、持續(xù)的交付有價值的軟件來使客戶滿意。即使到了開發(fā)的后期也歡迎改變需求。敏捷過程利用變化來為客戶創(chuàng)造競爭優(yōu)勢。經(jīng)常性地交付可以工作的軟件，交付的間隔可以從幾周到幾個月，交付的時間間隔越短越好。在整個項目開發(fā)期間，業(yè)務人員

31、和開發(fā)人員必須天天都在一起工作。圍繞被激勵起來的個人來構(gòu)建項目。給他們提供所需要的環(huán)境和支持，并且信任他們能夠完成工作。敏捷過程的價值觀與原則68軟件工程 - 2013 - 第二章 軟件過程敏捷過程的12條基本原則（續(xù)）在團隊內(nèi)部，最具有效果并且富有效率的傳遞信息的方法，就是面對面的交談。工作的軟件是首要的進度度量標準。敏捷過程提倡可持續(xù)的開發(fā)速度。責任人、開發(fā)者和用戶應該能夠保持一個長期的、恒定的開發(fā)速度。不斷地關(guān)注優(yōu)秀的技能和好的設計會增強敏捷能力。簡單是最根本的。最好的架構(gòu)、需求和設計出自于自組織的團隊。每隔一段時間，團隊會在如何才能更有效地工作方面進行反省，然后相應地對自己的行為進行調(diào)

32、整。敏捷過程的價值觀與原則69軟件工程 - 2013 - 第二章 軟件過程極限編程是敏捷過程中最富盛名的一個，其中“極限”的含義是指把最好的開發(fā)實踐運用到極致。目前極限編程已經(jīng)成為一個典型的開發(fā)方法，廣泛應用于需求模糊且經(jīng)常改變的場合。特點：對變化和不確定性反應更快速、更敏捷快速的同時保持可持續(xù)的開發(fā)速度極限編程（eXtreme Programming, XP）70軟件工程 - 2013 - 第二章 軟件過程客戶作為開發(fā)團隊的成員使用用戶素材短交付周期（每兩周完成一次迭代）驗收測試結(jié)對編程測試驅(qū)動開發(fā)集體所有（程序代碼屬于整個開發(fā)小組，每個成員都有修改代碼的權(quán)利，都對全部代碼負責）極限編程的有

33、效實踐71軟件工程 - 2013 - 第二章 軟件過程持續(xù)集成（一日內(nèi)多次集成，不斷回歸測試）可持續(xù)的開發(fā)速度（周工作時間不超過40小時，連續(xù)加班不超過兩周）開放的工作空間計劃游戲簡單的設計重構(gòu)使用隱喻（隱喻是把整個系統(tǒng)聯(lián)系在一起的全局視圖，描述系統(tǒng)如何運做，如何把新功能加入到系統(tǒng)中）極限編程的有效實踐72軟件工程 - 2013 - 第二章 軟件過程極限編程的整體開發(fā)過程體系結(jié)構(gòu)試探制訂交付計劃難點試探驗收測試迭代開發(fā)不確定的估計確定的估計隱喻交付計劃最新版本需求新用戶故事差錯下一次迭代用戶認可小交付測試用例用戶故事73軟件工程 - 2013 - 第二章 軟件過程極限編程的迭代過程制訂迭代計劃

34、站立會議代碼共享編程交流與討論未完成的任務用戶故事交付計劃項目速率任務分配下一個任務或未通過驗收的模塊差錯共享的信息新用戶故事新項目速率新功能最新版本結(jié)對編程與人員輪換；持續(xù)地優(yōu)化設計；循環(huán)冗余檢測消除差錯每天74軟件工程 - 2013 - 第二章 軟件過程生命周期敏捷過程是一個一維的迭代過程RUP是一個二維、雙重的迭代過程敏捷過程相對RUP具有對變化和不確定性的“更快速、更敏捷”的反應特性，且在快速的同時仍保持可持續(xù)性，該特性能較好地適應商業(yè)競爭環(huán)境下對小型項目提出的有限開發(fā)時間的約束。敏捷過程的特點（與RUP比較）75軟件工程 - 2013 - 第二章 軟件過程人員敏捷過程突出強調(diào)了“客戶

35、”這一角色的重要性能夠全面、動態(tài)地獲得用戶需求，將需求的持續(xù)反饋用以對過程進行適應性校正調(diào)整敏捷過程中各成員個體相互的地位關(guān)系是平等的，職責是共同的；個體間的首要協(xié)作交互方式為面對面的交談RUP中個體的職責是按照“角色”明確分工的，未給出個體間的地位關(guān)系RUP中主要協(xié)作交互方式是通過“形式化的文檔模型”理想方式：將上述兩種方式進行結(jié)合敏捷過程的特點（與RUP比較）76軟件工程 - 2013 - 第二章 軟件過程方法動態(tài)滿足需求從歡迎變化、與客戶合作到響應變化簡單化，與RUP的以架構(gòu)為中心的設計方法相比，是對產(chǎn)品不同質(zhì)量要求的不同的應對策略團隊持續(xù)自我反省理想方式：與RUP的三種方法在項目開發(fā)的

36、不同階段同時使用整個過程建模使用UML在需求階段可同時采用用例驅(qū)動方法和動態(tài)滿足需求方法在設計階段根據(jù)不同的項目質(zhì)量要求選擇以架構(gòu)為中心和簡單化兩種之一來實施敏捷過程的特點（與RUP比較）77軟件工程 - 2013 - 第二章 軟件過程產(chǎn)品RUP強調(diào)創(chuàng)建和維護形式化的文檔模型，但未論及模型與軟件兩者的優(yōu)先級敏捷過程認為可以工作的軟件勝過面面俱到的文檔理想方式：二者融合軟件開發(fā)的主要和中心活動就是創(chuàng)建可以工作的軟件直到迫切需要且意義重大時，才進行文檔編制編制的內(nèi)部文檔應盡量短小且主題突出，滿足這種要求的最好的文檔形式是模型敏捷過程的特點（與RUP比較）78軟件工程 - 2013 - 第二章 軟件

37、過程敏捷過程的總體特征是針對商業(yè)環(huán)境下通常具有有限資源和有限時間約束的小型項目，提出了一些獨具特色的、操作性較強的解決方案；RUP是理想開發(fā)環(huán)境下軟件過程的一種完美的模式，但對商業(yè)環(huán)境具有有限資源和有限時間約束的項目沒有給出具體完整的配置方案。敏捷過程的特點（與RUP比較）Rational統(tǒng)一過程（RUP）敏捷過程（AP）其他過程XXX項目過程敏捷過程實施策略79軟件工程 - 2013 - 第二章 軟件過程Microsoft公司自己獨特的軟件開發(fā)過程，綜合了RUP和XP的許多優(yōu)點，是對眾多成功項目的開發(fā)經(jīng)驗的正確總結(jié)。MSF的過程模型來自兩個方面：微軟開發(fā)應用程序的過程；一些有效的、公認的過程

38、模型；詳細論述參見微軟軟件開發(fā)解決方案框架（第二版），麥中凡、陶偉編著，北京航空航天大學出版社微軟過程（Microsoft Process, MP）80軟件工程 - 2013 - 第二章 軟件過程項目前景（vision）與項目范圍（scope）項目前景是對項目要解決什么問題的開放性描述，它代表項目的遠景目標項目范圍描述的是在項目的限制條件內(nèi)，需要完成哪些具體的目標，主要是指所有特定的近期目標功能說明書闡釋了軟件每一個特性的功能和執(zhí)行方式，以及所有特性的組合關(guān)系和整體架構(gòu)單頁：概要性的描述所有產(chǎn)品特性的功能、性能及其在項目中的優(yōu)先級詳細：從技術(shù)細節(jié)上詳細描述如何實現(xiàn)所有的產(chǎn)品特性程序經(jīng)理職責是在

39、規(guī)定的項目資源、期限等限制條件下，確保產(chǎn)品能夠如期發(fā)布。微軟過程術(shù)語81軟件工程 - 2013 - 第二章 軟件過程項目計劃應該兼顧未來的不確定因素用有效的風險管理來減少不確定的因素的影響經(jīng)常生成過渡版本并快速地測試軟件來提高產(chǎn)品的穩(wěn)定性及可預測性采用快速循環(huán)、遞進的開發(fā)過程用創(chuàng)造性的工作來平衡產(chǎn)品特性和產(chǎn)品成本項目進度表應該具有較高的穩(wěn)定性和權(quán)威性使用小型項目組并發(fā)地完成開發(fā)工作，并設置多個同步點微軟過程的過程原則82軟件工程 - 2013 - 第二章 軟件過程將大型項目分解成多個可管理的單元，以便更快地發(fā)布產(chǎn)品用產(chǎn)品的前景目標和概要說明指導項目開發(fā)工作先基線化，后凍結(jié)避免產(chǎn)品走形使用原型驗

40、證概念，對項目進行早期論證把零缺陷作為追求的目標里程碑評審會強調(diào)改進工作，避免相互指責微軟過程的過程原則（續(xù)）83軟件工程 - 2013 - 第二章 軟件過程小型的、多元化的項目組角色依賴和職責共享專深的技術(shù)水平和業(yè)務技能以產(chǎn)品發(fā)布為中心明確的目標客戶的主動參與分享產(chǎn)品的前景所有人都參與設計認真從過去的項目中吸取經(jīng)驗共同管理、共同決策項目組成員在同一地點辦公大型項目組也像小型項目組一樣運轉(zhuǎn)微軟過程的組隊原則84軟件工程 - 2013 - 第二章 軟件過程微軟過程的生命周期每個生命周期發(fā)布一個遞進的軟件版本，各生命周期持續(xù)、快速地循環(huán)。每個生命周期分為五個階段，構(gòu)思階段（Envisioning

41、Phase）計劃階段（Planning Phase）開發(fā)階段（Developing Phase）穩(wěn)定階段（Stabilizing Phase）部署階段（Deploying Phase）每個階段均涉及產(chǎn)品管理、程序管理、開發(fā)、測試、發(fā)布各角色及其活動，各階段結(jié)束于一個重要里程碑。微軟過程的特點與AP、RUP比較85軟件工程 - 2013 - 第二章 軟件過程微軟軟件生命周期86軟件工程 - 2013 - 第二章 軟件過程87軟件工程 - 2013 - 第二章 軟件過程構(gòu)思階段前景/范圍認可里程碑主要工作：確定產(chǎn)品目標獲取競爭對手的信息完成對客戶和市場的調(diào)研分析確定新版本產(chǎn)品應該具備的主要特性確定

42、相對于前一版本而言，新版本應該解決的問題和需要增加的功能產(chǎn)品：前景/范圍說明書風險評估說明書項目組織結(jié)構(gòu)說明書微軟軟件生命周期88軟件工程 - 2013 - 第二章 軟件過程計劃階段項目計劃認可里程碑主要工作：根據(jù)產(chǎn)品目標編寫系統(tǒng)的特性規(guī)格說明書，這份說明書主要描述軟件特性、系統(tǒng)結(jié)構(gòu)、各構(gòu)件之間的相關(guān)性以及接口標準從系統(tǒng)高層開始著手進行系統(tǒng)設計描述整個系統(tǒng)的設計方案繪制系統(tǒng)結(jié)構(gòu)圖確定系統(tǒng)中存在的風險因素分析系統(tǒng)的可重用性劃分出系統(tǒng)中的子系統(tǒng)，給出各個子系統(tǒng)和各個構(gòu)件的規(guī)格說明根據(jù)產(chǎn)品特性規(guī)格說明書制定產(chǎn)品開發(fā)計劃產(chǎn)品：功能說明書風險管理計劃項目總體計劃書和總體進度表微軟軟件生命周期89軟件工程

43、 - 2013 - 第二章 軟件過程開發(fā)階段范圍完成里程碑主要工作：編寫程序代碼和書寫文檔產(chǎn)品：源代碼和可執(zhí)行程序安裝腳本和用于發(fā)布的配置信息已凍結(jié)的功能說明書關(guān)于產(chǎn)品使用的支持要素測試說明書和測試用例微軟軟件生命周期90軟件工程 - 2013 - 第二章 軟件過程穩(wěn)定階段發(fā)布就緒認可里程碑主要工作：測試和調(diào)試產(chǎn)品：黃金版本版本注釋關(guān)于產(chǎn)品使用的支持要素測試結(jié)果和測試工具源代碼和可執(zhí)行程序項目文檔里程碑評審記錄微軟軟件生命周期91軟件工程 - 2013 - 第二章 軟件過程部署階段部署完成里程碑主要工作：發(fā)布產(chǎn)品和解決方案，把項目移交到運營和支持人員手中產(chǎn)品：運營與支持信息系統(tǒng)程序和過程知識庫、報告、日志文檔庫，包含項目過程中產(chǎn)生的所有版本的文檔、資源所有項目文檔的最終版本下一步的工作計劃微軟軟件生命周期92軟件工程 - 2013 - 第二章 軟件過程相對RUP，微軟過程可視為RUP的一個精簡配置版本。相對敏捷過程，微軟過程是它的一個擴充版本，擴充了其每個生命周期內(nèi)的各階段的具體運作流程。微軟軟件生命周期特點93軟件工程 - 2013 - 第二章 軟件過程微軟過程中的人員的職責分配與任務分配是按照RUP中的“角色”概念