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

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

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

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

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

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

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

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

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

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

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

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

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

14、資源，增加成本；對開發人員的風險分析能力是極大的考驗，否則，模型將退化到瀑布模型，甚至更糟。螺旋模型的缺點36軟件工程 - 2013 - 第二章 軟件過程噴泉模型進一步開發運行狀態集成和測試階段編碼階段面向對象設計階段面向對象分析階段需求階段維護期“噴泉”體現了面向對象軟件開發過程迭代和無縫的特性37軟件工程 - 2013 - 第二章 軟件過程注意事項 為避免使用噴泉模型開發軟件時開發過程過于無序，應該把一個線形過程作為總目標面向對象范型本身要求經常對開發活動進行迭代或求精噴泉模型38軟件工程 - 2013 - 第二章 軟件過程軟件過程模式從成功或失敗的軟件開發實踐中總結而成，是軟件過程中生命

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

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

17、。“以架構為中心”4. 工作流程（workflow）：在業務中執行的活動序列，它相對于業務主角個體生成一個可見值結果。5. 角色（worker）：在軟件過程組織的環境中，個人或協同工作的小組的行為和職責定義為角色。RUP 術語（一）42軟件工程 - 2013 - 第二章 軟件過程6. 迭代（iteration）與增量（increment）：迭代是階段中的一個子項目，其結果是生成系統的一個內部或外部的發布版本。增量是指在后續迭代結束后，兩個發布版本之間存在的差異或差值。“迭代和增量的過程”7. 活動（activity）：是要求角色執行的工作單元。8. 工件（artifacts）：是一條信息，有三

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

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

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

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

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

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

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

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

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

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

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

29、的工具雖然重要，但不能過分夸大工具的作用。團隊的構建（包括個體、交互等）要比項目環境（包括過程、工具）的構建更重要。敏捷過程的價值觀與原則64軟件工程 - 2013 - 第二章 軟件過程可以工作的軟件勝過面面俱到的文檔軟件開發的主要目標是交付可以工作的軟件。沒有文檔的軟件是一種災難，但過多的面面俱到的文檔比過少的文檔更糟。軟件開發的主要和中心活動是創建可以工作的軟件。“直到迫切需要且意義重大時，才進行文檔編制”Martin文檔第一定律。編制的內部文檔應盡量短小并且主題突出。敏捷過程的價值觀與原則65軟件工程 - 2013 - 第二章 軟件過程客戶合作勝過合同談判需求、進度和項目成本的合同在根本

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

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

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

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

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

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

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

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

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

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

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

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

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

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