第11章 RUP軟件開發過程

第11章

RUP軟件開發過程11.1軟件開發過程

11.2RUP簡介11.3RUP的二維開發模型11.4RUP核心工作流11.5RUP特點11.1軟件過程歷史概述11.1.1軟件開發過程簡介11.1.2當前流行的軟件開發過程11.1.1軟件開發過程簡介Ivar：軟件開發過程是將用戶需求轉化為軟件系統所需要的活動的集合。Who，When，What，How軟件開發過程包含：實施于軟件開發和維護中的階段、方法、技術、實踐和相關產物（計劃、文檔、模型、代碼、測試用例和手冊等）的集合。11.1.1軟件開發過程簡介軟件開發過程是開發高質量軟件所需要完成的任務的框架。軟件開發過程的層次圖：11.1.1軟件開發過程簡介軟件工程過程將各種技術結合在一起，使得軟件能夠被合理地和及時地開發出來。軟件工程的方法層在技術上說明了需要如何去開發軟件。軟件工程的工具層為軟件過程和方法提供了自動或半自動的支持。軟件過程提供一個框架，在這個框架下可以建立一個軟件開發的綜合計劃。11.1.2當前流行的軟件過程RationalUnifiedProcess（RUP）Object-OrientedSoftwareProcess（OOSP）ExtremeProgramming（XP）CleanroomDynamicSystemDevelopmentMethod（DSDM）瀑布式螺旋式11.2RUP簡介11.2.1RUP過程的背景11.2.2傳統的軟件開發模型11.2.1RUP過程的背景軟件項目失敗的原因：混亂的需求管理。開發者之間，以及開發者和用戶不清晰的交流。沒有發現需求、設計和實現中的不一致。架構不夠堅固。缺少有效的測試。對項目狀態的主觀估計。沒有正確地處理項目開發過程中的風險。沒有對項目變更進行控制。11.2.1RUP過程的背景RationalUnifiedProcess（RUP，統一開發過程）是一套面向對象的軟件工程過程。RUP說明了如何有效地使用成熟技術開發軟件。11.2.2傳統的軟件開發模型1.瀑布模型（WaterfallModel）2.螺旋模型1.瀑布模型（WaterfallModel）瀑布模型是一種線性模型。瀑布模型將軟件生存周期劃分為6個階段：需求分析設計實現測試運行維護瀑布模型最為突出的缺點是缺乏靈活性，不能處理好需求變化1.瀑布模型（WaterfallModel）

需求分析設計實現測試部署運行維護2.螺旋模型螺旋模型使用原型作為降低風險的機制。螺旋模型使開發者在產品演化的任意階段均可使用原型方法。螺旋模型體現了RUP中迭代的思想。一個螺旋的周期一般包括四個階段：確定目標，選擇方案，選定完成目標的策略。風險分析。啟動開發階段。評審前一階段的工作，計劃下一階段工作。2.螺旋模型

11.3RUP的二維開發模型傳統的瀑布開發模型是一個一維的模型，開發過程被劃分為多個連續的階段。在RUP中，軟件開發生命周期根據時間和RUP的核心工作流劃分為二維空間。橫軸表示項目的時間維，縱軸以內容來組織的邏輯活動。11.3RUP的二維開發模型11.3RUP的二維開發模型11.3.1RUP的核心工作流11.3.2RUP的四個階段11.3.3RUP的迭代開發模型11.3.1RUP的核心工作流RUP中有9個核心工作流，分為6個核心過程工作流（CoreProcessWorkflows）和3個核心支持工作流（CoreSupportingWorkflows）。9個核心工作流在項目中輪流被使用，在每一次迭代中以不同的重點和強度重復。11.3.1RUP的核心工作流1.業務建模（BusinessModeling）2.需求分析（Requirements）3.分析與設計（AnalysisandDesign）4.實現（Implementation）5.測試（Test）6.部署（Deployment）7.設置和變更管理（ConfigurationandChange Management）8.項目管理（ProjectManagement）9.環境（Environment）1.業務建模（BusinessModeling）理解待開發系統所在機構的組織結構及其業務運作，確保所有參與人員對開發系統有共同的認識。2.需求分析（Requirements）定義系統功能及用戶界面，明確客戶需要的系統的功能，開發人員理解系統的需求，為項目預算及計劃提供基礎。3.分析與設計（AnalysisandDesign）把需求分析的結果轉化為分析和設計模型，確定實現規格。4.實現（Implementation）定義代碼的組織結構、實現代碼、單元測試、系統集成。5.測試（Test）驗證各自子系統的交互與集成；發現缺陷并作出修改建議。6.部署（Deployment）打包、分發、安裝軟件，升級舊系統；培訓用戶及銷售人員，并提供技術支持。制定并實施beta測試。7.設置和變更管理（ConfigurationandChangeManagement）跟蹤并維護系統所有產品的完整性和一致性。8.項目管理（ProjectManagement）為軟件開發項目提供計劃、執行和監控可行性的指導；為風險管理提供框架。9.環境（Environment）為軟件開發機構提供過程管理和工具的支持。11.3.2RUP的四個階段RUP包括以下幾個階段：起始階段細化階段構建階段交付階段每個階段結束于一個主要的里程碑（MajorMilestones），每個階段本質上是兩個里程碑之間的時間跨度。11.3.2RUP的四個階段1.初始階段2.細化階段3.構建階段4.交付階段1.初始階段初始階段所要進行如下的活動：明確說明項目規模，了解環境以及最重要的需求和約束，以便可以得出最終產品的驗收標準。計劃和準備業務理由。評估風險管理、人員配備、項目計劃以及成本/進度/收益折衷的備選方案。綜合考慮構架，評估構架。準備項目的環境，評估項目和組織，選擇工具，決定流程中要改進的部分。1.初始階段初始階段的評估標準如下：出資人同意系統范圍定義以及費用和進度評估。主要用例是否符合需求。費用和進度評估、優先級、風險以及開發過程的可信性。任何已開發的原型的深度和廣度。實際開銷與計劃開銷。初始階段的焦點是需求和分析工作流。2.細化階段細化階段所要進行如下的活動：設計確定系統的體系結構，制定工作計劃和資源要求細化階段的焦點是需求、分析和設計工作流。2.細化階段細化階段的評估標準如下：標明用例模型中的用戶和參與者，并且建立用例的描述文檔。用例模型需完成80％。創建軟件系統開發過程中的軟件結構的描述文檔。創建可執行的系統原型。細化業務案例和風險列表。創建整個項目的開發計劃。3.構造階段構建階段的主要目標如下：優化資源、避免不必要的報廢和返工，使開發成本降到最低。盡快達到質量的要求。快速完成有用的版本，例如Alpha版、Beta版和其他測試發布版。完成所有功能的分析、開發和測試。迭代式、遞增地開發隨時可以發布的產品。確定準備好軟件系統的外部環境。構建階段的焦點是實現工作流。4.交付階段交付階段的主要目標如下：進行Beta版使用測試，按用戶的要求驗證新系統。替換舊的系統，順利的升級。對用戶和維護人員進行培訓。開始調整活動，例如調試、性能或可用性的增強。與用戶達成共識，配置基線與評估標準一致。交付階段的焦點是實現和測試工作流。11.3.3RUP的迭代開發模型RUP中的每個階段可以進一步分解為迭代。11.3.3RUP的迭代開發模型與傳統的瀑布模型相比較，迭代過程的優點：降低了在一個增量上的開支風險。降低了產品無法按照既定進度進入市場的風險。加快了整個開發工作的進度。11.3.3RUP的迭代開發模型與傳統的瀑布模型相比較，迭代過程的優點：項目的開發不是瀑布式的開發，而多考慮到需求的變更、設計的優化等情況，進行多次的迭代開發，每一次迭代完成，都能夠提交一個可運行的產品，并且在原有的基礎上得到提高。里程碑里程碑是開發過程的檢查和同步點，而不是靜態的點使用里程碑，使得團隊的成員能夠共同協作和同步工作里程碑包含兩種形式：主要里程碑內部里程碑每個里程碑結束時，都應當同客戶取得一致里程碑結束的標志是可以提交相應的成果項目的整個過程建議分成三個主要里程碑：項目前期（PreProject）項目開發（Development）項目提交（Deliver）對于每個主要的里程碑，項目可以根據情況定義次級里程碑里程碑及迭代開發milestone1milestone4milestone3milestone2里程碑及迭代開發TimeFunctionmilestone1milestone4milestone3milestone2milestone1milestone4milestone3milestone2milestone1milestone4milestone3milestone2Version1Version2Version3風險管理風險：將來可能發生的問題，這個問題是同項目相關的，會對項目的開展產生負面影響。風險管理的原則風險管理的原則事先預期，事先處理，而不是等到風險發生的時候再處理找到風險的根本再處理，而不只是處理表面的問題設法降低和轉化風險，而不是回避使用已知和可控的方法處理風險風險管理示例在項目開始時，項目計劃中必須包含風險計劃項目進行過程中，必須執行持續的風險管理活動在以下情況下，必須提供風險報告：項目開始時每個星期必須提交一次風險報告當一個重要的里程碑結束時當項目發生變動時其他覺得有必要做風險分析的時間風險報告的內容為了使風險管理達到預期的要求，風險報告應該包含以下內容：最重要的風險的內容風險發生的可能性風險可能產生的影響處理風險的手段和計劃風險的負責人11.4核心工作流介紹11.4.1需求工作流11.4.2分析工作流11.4.3設計工作流11.4.4實現工作流11.4.5測試工作流11.4.1需求工作流需求捕獲通過對應問題的理解和分析，確立問題涉及的信息、功能和系統行為，將用戶需求精確化、完全化。需求的焦點主要在初始和細化階段，在細化階段后期，需求捕獲的工作量大幅下降。11.4.1需求工作流11.4.1需求工作流1.制品2.工作人員3.工作流1.制品在需求工作流，主要的UML制品：用例模型（UseCaseModel）參與者（Actor）用例（UseCase）構架描述術語表（Glossary）用戶界面原型2.工作人員參與需求工作流階段的工作人員：系統分析人員（SystemAnalyst）用例描述人員（UseCaseSpecifier）用戶界面設計人員（UserInterface Designer）構架設計師（Architect）3.工作流需求捕獲的工作流主要包括五個活動：確定參與者和用例區分用例的優先級詳細描述一個用例構造完整用例模型構造用戶界面原型11.4.2分析工作流分析的主要工作開始于初始階段的結尾，和需求一樣是細化階段的主要焦點。細化階段的大部分活動是捕獲需求和分析；分析工作與需求捕獲在很大程度上重疊。11.4.2分析工作流11.4.2分析工作流1.制品2.工作人員3.工作流1.制品在分析工作流期間，主要的UML制品：分析模型用例實現（分析）分析類分析包構架模型2.工作人員在分析工作流期間，所參與的工作人員：構架設計師用例工程師構件工程師3.工作流分析工作流主要包括四個活動：構架分析分析用例分析類分析包11.4.3設計工作流設計工作流的主要工作是位于細化階段的中后期部分和構造階段的開始部分的主要建模活動。系統建模最初的焦點是需求和分析，在分析活動逐步完善后，建模的焦點開始轉向設計。11.4.3設計工作流11.4.3設計工作流1.制品2.工作人員3.工作流1.制品在分析工作流期間，主要的UML制品：設計模型設計類用例實現-設計設計子系統接口配置圖2.工作人員參與設計工作流的工作人員包括：構架設計師用例工程師構件工程師3.工作流設計工作流中，主要包括四種活動：構架設計設計一個用例設計一個類設計一個子系統11.4.4實現工作流實現（實施）是關于把設計模型轉換成可執行代碼的過程。從系統分析師或系統設計師的角度看，實現工作流的重點就是完成軟件系統的可執行代碼。實現工作流是構建階段的焦點。11.4.4實現工作流11.4.4實現工作流1.制品2.工作人員3.工作流1.制品在實現工作流中，主要有六種制品：實現模型組件實現子系統接口構架描述（實現模型）集成構造計劃2.工作人員參與實現工作流的工作人員：構架設計師構件工程師系統集成人員3.工作流在實現工作流中，包括一系列