面向?qū)ο筌浖_發(fā)過程-UP介紹.ppt

1、1,第七章面向?qū)ο筌浖_發(fā)過程（1)統(tǒng)一過程模型UP介紹,2,提綱,7a.1 UP的基本結(jié)構(gòu) 7a.2 UP的階段 7a.3 迭代增量式開發(fā) 7a.4 核心工作流 7a.5 最佳實踐 7a.6 UP工件,3,7a.1 UP的基本結(jié)構(gòu),軟件開發(fā)模型的出發(fā)點 如何更快（效率）更好（質(zhì)量）地滿足需求 使得開發(fā)過程在一種受控的方式下運行 過程活動任務 還需要涉及：項目、人員、工件 UP（Unified Process）是一個軟件開發(fā)過程的框架 擁抱變化：用戶反饋和適應調(diào)整逐步滿足用戶需求； 迭代增量式開發(fā) 用例驅(qū)動整個開發(fā)過程 提倡基于構(gòu)件的軟件體系結(jié)構(gòu)為中心展開開發(fā)活動,4,7a.1 UP的基本結(jié)構(gòu)

2、,5,UP科目（3e中）,6,7a.2 UP的階段（初始階段，inception）,初始階段的目標是為系統(tǒng)建立商業(yè)案例和確定項目的邊界。 項目邊界的確定 識別外部角色，識別用例，描述主要用例；（系統(tǒng)應該為不同的用戶提供什么？） 用戶提出的非功能性要求描述。 系統(tǒng)的整體架構(gòu)劃分（子系統(tǒng)的劃分），與外界環(huán)境的交互關系等。 商業(yè)案例（business case） 使用資源估計，包括項目的支撐環(huán)境； 估計潛在的風險； 對整個項目做最初的項目成本和日程估計 項目驗收規(guī)范。,7,7a.2 UP的階段（初始階段，inception）,初始階段主要目標： 明確軟件系統(tǒng)的范圍和邊界條件，包括從功能角度的構(gòu)想(v

3、ision)分析、產(chǎn)品驗收標準和哪些做與哪些不做的相關決定； 明確區(qū)分系統(tǒng)的關鍵用例和主要的功能場景； 展現(xiàn)或者演示至少一種符合主要場景要求的候選軟件體系結(jié)構(gòu)； 對整個項目做最初的項目成本和日程估計（更詳細的估計將在隨后的細化階段中做出）； 估計出潛在的業(yè)務風險（主要指各種不確定因素造成的潛在業(yè)務風險）； 準備好項目的支持環(huán)境。 評審標準： 風險承擔者就范圍定義、成本/日程估計達成共識； 以客觀的主要用例證實對需求的理解； 成本/日程、優(yōu)先級、業(yè)務風險和開發(fā)過程的可信度；,8,7a.2 UP的階段（初始階段，inception）,初始階段的產(chǎn)出： 構(gòu)想文檔：核心項目需求、關鍵特性、主要約束的總

4、體構(gòu)想； 原始用例模型（完成10%20%）； 原始項目術語表（可能部分表達為業(yè)務模型）； 原始商業(yè)案例，包括商業(yè)背景、驗收規(guī)范、成本預計等； 原始的業(yè)務風險評估； 一個或多個原型,9,7a.2 UP的階段（細化階段，elaboration）,細化階段的主要目標是分析問題領域，建立健全的體系結(jié)構(gòu)基礎，編制項目計劃，淘汰項目中最高風險的元素。 確保軟件結(jié)構(gòu)、需求、計劃足夠穩(wěn)定，確保項目技術風險已經(jīng)降低到能夠預計完成整個項目的成本和日程的程度； 針對項目的軟件結(jié)構(gòu)上的主要技術風險已經(jīng)解決或處理完成； 通過完成軟件結(jié)構(gòu)上的主要場景建立軟件體系結(jié)構(gòu)的基線； 建立一個包含高質(zhì)量組件的可演化的產(chǎn)品原型； 說

5、明基線化的軟件體系結(jié)構(gòu)可以保障系統(tǒng)需求可以控制在合理的成本和時間范圍內(nèi)； 建立好產(chǎn)品的支持環(huán)境。,10,7a.2 UP的階段（細化階段，elaboration）,評審標準： 產(chǎn)品的構(gòu)想是否穩(wěn)定？ 體系結(jié)構(gòu)是否穩(wěn)定？ 可執(zhí)行的原型版是否顯示技術風險要素已被處理和可靠的解決； 構(gòu)建階段的計劃是否足夠詳細和精確？是否被可靠的審核基礎支持？ 如果當前計劃在現(xiàn)有的體系結(jié)構(gòu)環(huán)境中被執(zhí)行而開發(fā)出完整系統(tǒng)，是否所有的風險承擔人同意該構(gòu)想是可實現(xiàn)的？ 實際的費用開支與計劃開支是否可以接受？,11,7a.2 UP的階段（細化階段，elaboration）,細化階段的產(chǎn)出： 用例模型（完成至少80）所有用例均被識別

6、，大多數(shù)用例描述被開發(fā)； 補充捕獲非功能性要求和未關聯(lián)于特定用例要求的需求（補充規(guī)范） 軟件體系結(jié)構(gòu)描述 可執(zhí)行的軟件原型 經(jīng)修訂過的技術風險清單和商業(yè)案例 總體項目的開發(fā)計劃，包括粗粒度的項目計劃，顯示迭代過程和對應的審核標準； 用戶手冊的初始版本（可選）,12,7a.2 UP的階段（構(gòu)造階段，construction）,構(gòu)造階段：所有剩余的構(gòu)件和應用程序功能被開發(fā)并集成為產(chǎn)品，所有的功能被詳盡的測試。 通過優(yōu)化資源和避免不必要的返工達到開發(fā)成本的最小化； 根據(jù)實際需要達到適當?shù)馁|(zhì)量目標； 根據(jù)實際需要形成各個版本（，和release） 對所有必須的功能完成分析、設計、開發(fā)和測試工作； 采用

7、循環(huán)漸進的方式開發(fā)出一個可以提交給最終用戶的完整產(chǎn)品； 確定軟件、站點、用戶都為產(chǎn)品的最終部署做好了相關準備； 達成一定程度上的并行開發(fā)機制。,13,7a.2 UP的階段（構(gòu)造階段，construction）,審核標準： 產(chǎn)品是否足夠穩(wěn)定和成熟地發(fā)布給用戶？ 是否所有的風險承擔人準備好向用戶移交？ 實際費用與計劃費用的比較是否仍可被接受？ 構(gòu)造階段的產(chǎn)出： 特定平臺上的集成產(chǎn)品； 用戶手冊； 當前版本的描述。,14,7a.2 UP的階段（移交階段，transition）,移交階段的主要目標：確保軟件產(chǎn)品可以提交給最終用戶。 進行測試以期達到最終用戶的需要； 測試版本和舊系統(tǒng)的并軌； 轉(zhuǎn)換功能數(shù)

8、據(jù)庫； 對最終用戶和產(chǎn)品支持人員的培訓； 提交給市場和產(chǎn)品銷售部門； 和具體部署相關的工程活動； 協(xié)調(diào)bug修訂、改進性能和可用性(usability）等工作； 基于完整的構(gòu)想和產(chǎn)品驗收標準對最終部署做出評估； 達到用戶要求的滿意度； 達成各風險承擔人對產(chǎn)品部署基線已經(jīng)完成的共識； 達成各風險承擔人對產(chǎn)品部署符合構(gòu)想中標準的共識,15,7a.2 UP的階段（移交階段，transition）,評審標準： 用戶是否滿意？ 實際費用與計劃費用的比較是否仍可被接受？,總結(jié)：,16,7a.3 迭代增量式開發(fā),UP的每個階段可以進一步分為迭代過程。 迭代過程是生成可執(zhí)行產(chǎn)品版本（內(nèi)部和外部）的完整開發(fā)循環(huán)

9、，是最終產(chǎn)品的一個子集，從一個迭代過程到另一個迭代過程遞增式增長形成最終的系統(tǒng)。,17,7a.3 迭代增量式開發(fā),迭代化的方法： 將整個項目的開發(fā)目標劃分成為一些更易于完成和達到的階段性小目標，這些小目標都有一個定義明確的階段性評估標準。 迭代就是為了完成一定的階段性目標而所從事的一系列開發(fā)活動。 在每個迭代開始前都要根據(jù)項目當前的狀態(tài)和所要達到的階段性目標制定迭代計劃； 整個迭代過程包含了需求、設計、實施（編碼）、部署、測試等各種類型的開發(fā)活動； 迭代完成之后需要對迭代完成的結(jié)果進行評估，并以此為依據(jù)來制定下一次迭代的目標。,18,7a.3 迭代增量式開發(fā),UP中的迭代增量式開發(fā)（風險驅(qū)動）

10、,19,7a.3 迭代增量式開發(fā),項目的主要風險集中在前兩個階段： 在細化階段中經(jīng)過幾次迭代后，為系統(tǒng)建立一個穩(wěn)定的架構(gòu)，之后在實現(xiàn)更多的系統(tǒng)需求時，不再對該架構(gòu)進行修改。 同時，在細化階段中，通過迭代來不斷地收集用戶的需求反饋，便得系統(tǒng)的需求逐步地明確和完整。,20,7a.3 迭代增量式開發(fā),21,7a.3 迭代增量式開發(fā),開發(fā)計劃的組織 項目計劃確定整個項目的開發(fā)目標和進度安排，包括每一個階段的起止時間段。 階段計劃當前階段中包含有幾個迭代，每一次迭代要達到的目標以及進度安排。 迭代計劃針對當前迭代的詳細開發(fā)計劃，包括開發(fā)活動以及相關資源的分配。,22,7a.3 迭代增量式開發(fā),項目開發(fā)計

11、劃也是完全體現(xiàn)迭代化的思想： 每次迭代中項目經(jīng)理都會根據(jù)項目情況來不斷地調(diào)整和細化項目開發(fā)計劃。 迭代計劃是在對上一次迭代結(jié)果進行評估的基礎上制定的，如果上一次迭代達到了預定的目標，那么當前迭代只需要解決剩下的問題；如果上一次迭代中留有一些問題還沒有解決，則當前迭代還需要繼續(xù)去解決這些問題。 所以必須注意，迭代是不能重疊的，即當還沒有完成當前迭代時，決不能進入下一迭代，因為下一次迭代的計劃是根據(jù)當前迭代的結(jié)果而制定的。,23,7a.4 核心工作流,軟件開發(fā)流程定義了“誰”、“何時”、“如何”做“某事”。四種主要的建模元素被用來表達： 角色（worker）“誰” 活動（activity）“如何”

12、 工件（artifact）“某事” 工作流（workflow，discipline） “何時”,24,7a.4 核心工作流,工作流是產(chǎn)生具有可觀察結(jié)果的活動序列,25,7a.4 核心工作流,26,7a.4 核心工作流（商業(yè)建模）,商業(yè)建模 大多數(shù)商業(yè)工程化的主要問題是軟件工程人員和商業(yè)工程人員之間不能正確地交流，這導致了商業(yè)工程的產(chǎn)出沒有作為軟件開發(fā)輸入而正確地被使用，反之亦然。 在商業(yè)建模中使用商業(yè)用例來文檔化商業(yè)過程，從而確保了組織中所有商業(yè)過程人員達到共識。 商業(yè)用例被分析以理解商業(yè)過程如何被業(yè)務支持，而這些在商業(yè)對象模型中被核實。 許多項目可能不進行商業(yè)建模。,27,7a.4 核心工作

13、流（需求）,需求 是描述系統(tǒng)應“做什么”，并允許開發(fā)人員和用戶就該描述達成共識。 創(chuàng)建構(gòu)想 建立用例模型 識別actor 識別use case 描述use case 其他功能和非功能性需求在補充規(guī)范中說明。,Use case起到貫穿整個系統(tǒng)的開發(fā)周期線索的作用，相同的用例模型在需求捕獲階段、分析/設計階段和測試階段中使用。,28,7a.4 核心工作流（分析和設計）,分析和設計 顯示系統(tǒng)“如何”在實現(xiàn)階段被實現(xiàn)的，達到下列目標： 在特定的實現(xiàn)環(huán)境中完成用例描述中指定的任務和功能 滿足了所有的需求 健壯地被建造（如果功能需求發(fā)生變化，應該易于更改） 分析設計結(jié)果是一個設計模型和可選的分析模型： 設

14、計模型由設計類和一些描述組成： 設計類被組織成具有良好接口的設計包和設計子系統(tǒng) 描述則體現(xiàn)了類的對象如何協(xié)同工作實現(xiàn)用例的功能 設計模型是源代碼的抽象 設計活動以體系結(jié)構(gòu)設計為中心,29,7a.4 核心工作流（實現(xiàn)）,實現(xiàn) 目的： 定義代碼的組織結(jié)構(gòu)以層次化方式組織實施子系統(tǒng)； 實現(xiàn)類和對象以構(gòu)件的形式（源文件、二進制文件、可執(zhí)行文件等）； 將開發(fā)出的構(gòu)件作為單元進行測試； 將由單個實現(xiàn)者或小組產(chǎn)生的結(jié)果集成為可執(zhí)行的系統(tǒng)。,30,7a.4 核心工作流（測試）,測試 目的 驗證對象間的交互作用； 驗證軟件構(gòu)件的正確集成； 驗證所有需求被正確的實現(xiàn)； 識別并確保在軟件發(fā)布之前缺陷被處理。,UP提

15、出了迭代的方法，意味著在整個項目中進行測試，從而允許盡可能早地發(fā)現(xiàn)缺陷，從根本上降低了修改缺陷的成本； 測試生命周期的幾個階段：計劃、設計、實現(xiàn)、執(zhí)行和審核。,31,7a.4 核心工作流（發(fā)布）,發(fā)布 目標是成功地生成版本，將軟件分發(fā)給最終用戶。包含的活動： 生成軟件本身外的產(chǎn)品； 軟件打包 安裝軟件 給用戶提供幫助 許多情況下還包括如下的活動： 計劃和進行測試版 移植現(xiàn)有的軟件或數(shù)據(jù) 正式驗收,32,7a.4 核心工作流（配置和變更管理）,配置和變更管理 完成建立并管理基線的任務。 基線：已經(jīng)通過正式復審和批準的某規(guī)約或產(chǎn)品，它因此可以作為進一步開發(fā)的基礎，并且只能通過正式的變更控制過程進行

16、改變。 配置項：置于配置和變更管理控制之下的工件。 提供了管理系統(tǒng)演化中的多個變體、跟蹤軟件版本的準則； 描述了如何管理并行開發(fā)、分布式開發(fā)，如何自動化創(chuàng)建工程； 涵蓋了需求變更管理，即：如何報告缺陷？如何管理缺陷？及如何使用缺陷來跟蹤進展和發(fā)展的傾向？,33,7a.4 核心工作流（項目管理、環(huán)境）,項目管理 集中在迭代開發(fā)過程的組織管理方面 目標是提供以下的事物來使該任務更簡單： 管理項目的框架； 計劃、配備、執(zhí)行、監(jiān)控項目的實踐準則； 管理風險的框架。 環(huán)境 目的是給軟件開發(fā)組織提供軟件開發(fā)環(huán)境（過程和工具），軟件開發(fā)隊伍需要它們的支持； 集中在項目環(huán)境中配置過程的活動，同樣著重支持項目的開發(fā)規(guī)范的活動，提供了逐步指導手冊，介紹了如何在組織中實現(xiàn)過程； 還包含了定制流程所必須的準則、模板、工具的開發(fā)工具箱。,34,7a.5 最佳實踐,短時間