軟件過程框架與軟件過程模型

1、第三講第三講 軟件過程框架與軟件過程模型軟件過程框架與軟件過程模型2軟件過程框架軟件過程框架l什么是過程？ 針對一個給定目標(biāo)的一系列操作步驟。 例如 - 目標(biāo)：去火車站 - 操作步驟：去南門/東門公共汽車站，乘50/17路汽車， 每個過程都有明確的目的以及具體的操作步驟，操作步驟說明了有哪些操作以及按照什么樣的方式來執(zhí)行操作。3l什么是軟件開發(fā)過程？ 按照項目的進(jìn)度、成本和質(zhì)量限制，開發(fā)和維護(hù)滿足用戶需求的軟件所必需的一組有序的軟件開發(fā)活動集合。 軟件開發(fā)活動的例子- 需求分析- 體系結(jié)構(gòu)設(shè)計 開發(fā)活動的順序例子- 先做需求分析，然后再做體系結(jié)構(gòu)設(shè)計 4l在按任務(wù)性質(zhì)，軟件開發(fā)活動可分為二種形

2、式技術(shù)活動技術(shù)活動- 對軟件項目實施開發(fā)，產(chǎn)生軟件產(chǎn)品- 例如，需求分析，概要設(shè)計，編碼，單元測試等等管理活動管理活動- 對軟件項目中的人、產(chǎn)品和過程等實施管理的活動- 例如，制訂軟件項目計劃，軟件配置等等5l如何定義軟件開發(fā)活動?- 名稱- 任務(wù)- 輸入: 開始所必需滿足的條件- 輸出: 完成時所必須滿足的條件以及結(jié)果- 實施: 做什么，怎么做(詳細(xì)的步驟)，或者如何從輸入產(chǎn)生輸出軟件開發(fā)活動軟件開發(fā)活動輸入輸入輸出輸出6軟件活動例子軟件活動例子:- 名字： 單元測試- 任務(wù)l對軟件基本單元模塊進(jìn)行測試，判斷是否有錯- 輸入l有一個已完成、被文檔化和批準(zhǔn)的軟件單元測試計劃l供測試的軟件單元模

3、塊代碼- 實施l遵循單元測試計劃，運行所有的測試用例l撰寫單元測試報告- 輸出l單元測試報告7l為什么需要軟件過程？ - 明確了軟件開發(fā)的過程和步驟，促進(jìn)工程化軟件開發(fā) - 便于制定軟件項目計劃 - 為軟件開發(fā)提供了可視性，便于對軟件開發(fā)過程進(jìn)行管理和控制 - 便于細(xì)化和安排任務(wù)，使得每個人員明確各自的工作8軟件開發(fā)過程模型軟件開發(fā)過程模型l軟件開發(fā)過程模型- 軟件開發(fā)過程模型是軟件開發(fā)全過程、軟件開發(fā)活動以及它們之間關(guān)系的結(jié)構(gòu)框架- 指導(dǎo)軟件開發(fā)以及軟件開發(fā)過程的定義l常用的軟件開發(fā)過程模型- 瀑布模型- 原型模型- 增量模型- 迭代模型- 螺旋模型9l軟件過程分類軟件過程分類 - - 基本

4、過程類 是構(gòu)成軟件生存周期主要部分的那些過程, 包括：定義、構(gòu)建、維護(hù)等過程. - 支持過程類 可穿插到基本過程中提供支持的一系列過程, 包括：文檔開發(fā)、 配置管理、 質(zhì)量保證、驗證、確認(rèn)、聯(lián)合評審、審計、問題解決等程. - 組織過程類 一個組織用來建立、實施一種基礎(chǔ)結(jié)構(gòu), 并不斷改進(jìn)該基礎(chǔ)結(jié)構(gòu)的過程, 包括：管理、計劃、改進(jìn)、培訓(xùn)等過程.10公共軟件過程框架公共軟件過程框架11 一個公共過程框架，是通過定義若干框架活動來建立的，如果不考慮其規(guī)模和復(fù)雜性，這些活動適用于所有軟件項目。 任務(wù)集合每一個集合都由軟件工程工作任務(wù)、項目里程碑、軟件工程產(chǎn)品和交付物以及質(zhì)量保證點組成使得框架活動適應(yīng)于不

5、同軟件項目的特征和項目組的需求。 支持性活動如軟件質(zhì)量保證，軟件配置管理和測度，它們貫穿于整個過程模型之中。支持性活動獨立于任何一個框架活動，且貫穿于整個過程。12l管理性活動管理性活動- - 軟件項目跟蹤和控制軟件項目跟蹤和控制 允許項目組根據(jù)計劃來評估項目進(jìn)度，并且采取必要的措施保證項目按進(jìn)度計劃進(jìn)行。- - 風(fēng)險管理風(fēng)險管理 評估可能對項目成果或者產(chǎn)品質(zhì)量產(chǎn)生影響的風(fēng)險。- - 軟件質(zhì)量保證軟件質(zhì)量保證 確定和執(zhí)行用以保證軟件質(zhì)量的活動。 正式技術(shù)評審: 評估軟件工程產(chǎn)品，盡量在錯誤傳播到下一個動作或活動之前，發(fā)現(xiàn)并清除錯誤。 V&V（Verification and Valid

6、ation）：驗證與確認(rèn)。13- - 測量測量 定義和收集過程、項目和產(chǎn)品的度量，以幫助團(tuán)隊在發(fā)布軟件的時候滿足客戶要求。同時，測量還可與其它框架協(xié)同使用。- - 軟件配置管理軟件配置管理 管理整個軟件過程中變更所帶來的影響。- - 可復(fù)用管理可復(fù)用管理 定義產(chǎn)品復(fù)用的標(biāo)準(zhǔn)（包括軟件構(gòu)件），并且建立構(gòu)件復(fù)用機(jī)制。- - 工作產(chǎn)品工作產(chǎn)品（Work Product）的準(zhǔn)備和生產(chǎn)的準(zhǔn)備和生產(chǎn) 包括了創(chuàng)建產(chǎn)品所必須的活動如建模、文檔、日志、表格和列表等。14l主要的開發(fā)和支持過程主要的開發(fā)和支持過程 1 1、軟件需求分析、軟件需求分析 任務(wù)任務(wù)：收集、分析、理解、確定用戶的要求；然后把用戶的要求精確

7、、完整地描述表達(dá)出來。 目的目的：要回答“要解決什么問題？”， 既系統(tǒng)“做什么？”。 輸入輸入：系統(tǒng)需求文檔/問題陳述、本過程相關(guān)工作計劃 步驟步驟：可行性研究、需求分析、制定相關(guān)開發(fā)計劃 輸出輸出：可行性報告、需求規(guī)范、下一過程開發(fā)計劃 需求說明書是讓用戶理解:“什么是他們真正需要的”； 讓開發(fā)者理解“什么是他們真正的開發(fā)目標(biāo)”。15Review Item Discrepancy16任務(wù)任務(wù)：給出實現(xiàn)系統(tǒng)的實施藍(lán)圖。目的目的：要回答“如何解決該問題？”， 既系統(tǒng)“怎樣做？”。輸入：輸入：軟件需求規(guī)范、本過程相關(guān)計劃步驟步驟： 概要設(shè)計：解決系統(tǒng)的子系統(tǒng)/模塊劃分、子系統(tǒng)/模塊的層次結(jié)構(gòu)及數(shù)據(jù)

8、庫設(shè)計； 詳細(xì)設(shè)計：解決每個模塊/類內(nèi)部算法和數(shù)據(jù)結(jié)構(gòu)； 制定下一過程相關(guān)計劃。 輸出輸出：體系結(jié)構(gòu)設(shè)計說明書、詳細(xì)設(shè)計說明書、下一過程相關(guān)計劃 2、軟件設(shè)計1718193、軟件構(gòu)造任務(wù)任務(wù)：根據(jù)設(shè)計說明書中每個模塊的控制流程編寫出相應(yīng)的源程序。目的目的：寫出高質(zhì)量的代碼和相應(yīng)的文檔。 - 構(gòu)造要注意使系統(tǒng)更易于使用和系統(tǒng)的可重用性。 - 選擇合適的開發(fā)工具及系統(tǒng)軟件、數(shù)據(jù)庫軟件、中間件等。制定編程規(guī)范。輸入：輸入：軟件設(shè)計文檔、本過程相關(guān)計劃步驟：步驟：編程、單元測試、制定下一階段相關(guān)計劃、編制用戶文檔輸出輸出：源程序和相關(guān)文檔、下一過程相關(guān)計劃204、軟件測試任務(wù)任務(wù)：檢查、發(fā)現(xiàn)程序中的錯

9、誤，提高系統(tǒng)可靠性。目的目的：保證系統(tǒng)的正確性、可靠性和可用性?；卮鸹卮穑骸霸撓到y(tǒng)是否能實現(xiàn)規(guī)定的操作？”。輸入：輸入：已經(jīng)完成的代碼、本過程相關(guān)的計劃步驟步驟：集成測試、系統(tǒng)測試、確認(rèn)測試輸出輸出：測試報告和軟件修改報告等。215、軟件維護(hù)任務(wù)任務(wù)：改正軟件系統(tǒng)在使用過程中發(fā)現(xiàn)的隱含錯誤，擴(kuò)充在使用過程中新的功能要求。目的目的：維護(hù)軟件系統(tǒng)的正常運行?；卮鸹卮穑合到y(tǒng)是否滿足用戶的應(yīng)用要求。輸入：輸入：問題報告步驟步驟：問題報告審批、問題修改、審核輸出輸出：軟件修改報告。226.軟件配置管理軟件修改后會發(fā)生什么呢？- 同步更新當(dāng)兩個或兩個以上的角色各自工作在同一產(chǎn)物上時，最后一個修改者會破壞前

10、者的工作。- 通知不達(dá)當(dāng)被若干開發(fā)者共享的產(chǎn)品中的問題被解決時，修改未被通知到一些開發(fā)者。- 多個版本軟件修改與文檔不一致。- 新版本公布的管理和監(jiān)控。 配置和變更管理提供了準(zhǔn)則管理演化系統(tǒng)中的多個變體，跟蹤給定軟件創(chuàng)建過程中的版本。23SRD247.軟件工程管理 項目管理是過程管理的主要體現(xiàn)：(1)建立與客戶的溝通渠道；(2)制訂計劃，定義資源、時限、落實到開發(fā)組；(3)風(fēng)險分析，評估所采用的技術(shù)和管理帶來的風(fēng)險；(4)技術(shù)過程監(jiān)控；(5)客戶評審，獲得客戶的反饋。2526278.軟件質(zhì)量保證 軟件質(zhì)量保證SQA活動，貫穿于軟件過程始終。開發(fā)單位成立SQA小組負(fù)責(zé)全面質(zhì)量管理。在開發(fā)項目計劃

11、時就要做出SQA計劃。其工作：- 各種測試：測試軟件是否滿足規(guī)格說明要求。- 各種評審/審計：為多種人員參與的討論會，以規(guī)格說明或各種標(biāo)準(zhǔn)、規(guī)范為準(zhǔn)評價各項軟件工作。- 報告和記錄：所有測試、評審、審計都要詳細(xì)記錄并寫出報告，報告和記錄均要整理、歸檔。 以上活動均應(yīng)在軟件質(zhì)量保證計劃中列出。2829傳統(tǒng)軟件生命周期模型傳統(tǒng)軟件生命周期模型1. 瀑布模型瀑布模型 Winston Royce在軟件生命周期概念的基礎(chǔ)上，于1970年提出了著名的“瀑布模型”（waterfall model）。 30l瀑布模型中的每一個開發(fā)活動具有下列特征： - 本活動的工作對象來自于上一項活動的輸出，這些輸出一般是代

12、表本階段活動結(jié)束的里程碑式的文檔。 - 根據(jù)本階段的活動規(guī)程執(zhí)行相應(yīng)的任務(wù)。- 產(chǎn)生本階段活動相關(guān)產(chǎn)出軟件產(chǎn)品，作為下一活動的輸入。- 對本階段活動執(zhí)行情況進(jìn)行評審。31l瀑布模型的優(yōu)缺點優(yōu)點優(yōu)點缺點缺點降低了軟件開發(fā)的復(fù)雜程度，而且提高了軟件開發(fā)過程的透明性，提高了軟件開發(fā)過程的可管理性。 模型缺乏靈活性，特別是無法解決軟件需求不明確或不準(zhǔn)確的問題。 推遲了軟件實現(xiàn)，強(qiáng)調(diào)在軟件實現(xiàn)前必須進(jìn)行分析和設(shè)計工作。 模型的風(fēng)險控制能力較弱。 以項目的階段評審和文檔控制為手段有效地對整個開發(fā)過程進(jìn)行指導(dǎo)，保證了階段之間的正確銜接，能夠及時發(fā)現(xiàn)并糾正開發(fā)過程中存在的缺陷，從而能夠使產(chǎn)品達(dá)到預(yù)期的質(zhì)量要求

13、。 瀑布模型中的軟件活動是文檔驅(qū)動的，當(dāng)階段之間規(guī)定過多的文檔時，會極大地增加系統(tǒng)的工作量；而且當(dāng)管理人員以文檔的完成情況來評估項目完成進(jìn)度時，往往會產(chǎn)生錯誤的結(jié)論。322. V模型和模型和W模型模型 1980年代后期Paul Rook提出了V模型 33Evolutif公司在V模型的基礎(chǔ)上提出了W模型343. 原型方法原型方法l原型方法的產(chǎn)生 - 瀑布模型、V模型和W模型都將軟件生命周期劃分成獨立串行的幾個階段，前一個階段沒有完成便無法開始下一階段的工作。 - 然而完整而準(zhǔn)確的需求規(guī)格說明是很難得到的，因為：l在開發(fā)早期用戶往往對系統(tǒng)只有一個模糊的想法，很難完全準(zhǔn)確地表達(dá)對系統(tǒng)的全面要求 l隨

14、著開發(fā)工作的推進(jìn)，用戶可能會產(chǎn)生新的要求l開發(fā)者又可能在設(shè)計與實現(xiàn)的過程中遇到一些沒有預(yù)料到的實際困難，需要以改變需求來解脫困境 35l原型方法指在獲得一組基本需求后，通過快速分析構(gòu)造出一個小型的軟件系統(tǒng)原型，滿足用戶的基本要求。l用戶通過使用原型系統(tǒng)，提出修改意見，從而減少用戶與開發(fā)人員對系統(tǒng)需求的誤解，使需求盡可能準(zhǔn)確。l原型方法主要用于明確需求，但也可以用于軟件開發(fā)的其它階段。 36l原型的三種作用類型： （1）探索型：弄清用戶對目標(biāo)系統(tǒng)的要求，確定所期望的特性；探討多種實現(xiàn)方案的可行性。主要針對需求模糊、用戶和開發(fā)者對項目開發(fā)都缺乏經(jīng)驗的情況。 （2）實驗型；用于大規(guī)模開發(fā)和實現(xiàn)之前，

15、考核技術(shù)實現(xiàn)方案是否合適。 （3） 進(jìn)化型：在構(gòu)造系統(tǒng)的過程中能夠適應(yīng)需求的變化，通過不斷地改進(jìn)原型，逐步將原型進(jìn)化成最終的系統(tǒng)。它將原型方法的思想擴(kuò)展到軟件開發(fā)的全過程，適用于需求經(jīng)常變動的軟件項目。 37l原型方法的特點：（1）從認(rèn)知論的角度看，原型方法遵循了人們認(rèn)識事物的規(guī)律，因而更容易為人們所普遍接受，這主要表現(xiàn)在： 人們對任何事物的認(rèn)知都不可能一蹴而就、盡善盡美； 認(rèn)識和學(xué)習(xí)的過程都是循序漸進(jìn)的； 對于事物的描述，往往都是受環(huán)境的啟發(fā)而不斷完善的； 人們批評指責(zé)一個已有的事物，要比空洞地描述自己的設(shè)想容易得多，改進(jìn)一些事物要比創(chuàng)造一些事物容易得多。38 原型方法將模擬的手段引入分析的

16、初期階段，溝通了人們的思想，縮短了用戶和開發(fā)人員之間的距離。這主要表現(xiàn)在： 所有問題的討論都是圍繞某一個確定原型而進(jìn)行的，彼此之間不存在誤解和答非所問的可能性，為準(zhǔn)確認(rèn)識問題創(chuàng)造了條件。 有了原型才能啟發(fā)人們對原來想不起來或不易準(zhǔn)確描述的問題有一個比較確切的描述； 能夠及早地暴露出系統(tǒng)實現(xiàn)后存在的一些問題，促使人們在系統(tǒng)實現(xiàn)之前就加以解決。39l原型法的適用范圍和局限性：- 對于一個大型系統(tǒng)，如果不經(jīng)過系統(tǒng)分析得到系統(tǒng)的整體劃分，而直接用原型來模擬是很困難的。- 對于原有應(yīng)用的業(yè)務(wù)流程、信息流程混亂的情況，原型構(gòu)造與使用有一定的困難。- 對于一個批處理系統(tǒng)，由于大部分活動是內(nèi)部處理的，因此應(yīng)用

17、原型方法會有一定的困難。40l原型方法存在的問題：- 文檔容易被忽略。 - 建立原型的許多工作會被浪費掉 。- 項目難以規(guī)劃和管理。 41l原型方法可以支持軟件生命周期的不同階段 424. 迭代迭代模型模型(Iterative)l使用瀑布模型人們認(rèn)識到，由于需求很難調(diào)研充分，所以很難一次性開發(fā)成功。l迭代模型提倡兩次開發(fā)：- 第一次是試驗開發(fā)，得到試驗性的原型產(chǎn)品，其目標(biāo)只是在于探索可行性，弄清軟件需求；- 第二次在此基礎(chǔ)上獲得較為滿意的軟件產(chǎn)品。43l迭代模型分類：- 探索式迭代模型- 進(jìn)化型迭代模型l迭代模型的特點：- 優(yōu)點：明確用戶需求、提高系統(tǒng)質(zhì)量、降低開發(fā)風(fēng)險；- 缺點：難于管理、結(jié)

18、構(gòu)較差、技術(shù)不成熟；l迭代模型適用范圍：- 需求不清楚；- 小型或中小型系統(tǒng)；- 開發(fā)周期短445. 增量模型增量模型lMills等人于1980年提出 ，指首先對系統(tǒng)最核心或最清晰的需求進(jìn)行分析、設(shè)計、實現(xiàn)、測試并集成到系統(tǒng)中。再按優(yōu)先級逐步對后續(xù)的需求進(jìn)行上述工作，逐步建設(shè)成一個完整系統(tǒng)的開發(fā)方法。4546l增量模型的優(yōu)點：- 有利于增加客戶對系統(tǒng)的信心；- 降低系統(tǒng)失敗風(fēng)險；- 提高系統(tǒng)可靠性；- 提高了系統(tǒng)的穩(wěn)定性和可維護(hù)性；l增量模型的缺點：- 增量粒度難以選擇；- 確定所有的基本業(yè)務(wù)服務(wù)比較困難 。476. 螺旋模型螺旋模型lBoehm于1988年提出，主要針對大型軟件項目的開發(fā)。l

19、大型軟件項目的特點：（1）需求功能復(fù)雜，無法一開始就明確；開發(fā)周期長，中途需求經(jīng)常變化；（2）往往存在諸多風(fēng)險因素，在不同程度上損害軟件開發(fā)過程和軟件產(chǎn)品的質(zhì)量，所以必須對風(fēng)險進(jìn)行管理。l螺旋模型最大特點就是引入了明確的風(fēng)險管理。4849l制定計劃：確定軟件項目目標(biāo)；明確對軟件開發(fā)過程和軟件產(chǎn)品的約束；制定詳細(xì)的項目管理計劃；根據(jù)當(dāng)前的需求和風(fēng)險因素，制定實施方案，并進(jìn)行可行性分析，選定一個實施方案，并對其進(jìn)行規(guī)劃。l 風(fēng)險分析：明確每一個項目風(fēng)險，估計風(fēng)險發(fā)生的可能性、頻率、損害程度，并制定風(fēng)險管理措施規(guī)避這些風(fēng)險。l實施工程：針對每一個開發(fā)階段的任務(wù)要求執(zhí)行本開發(fā)階段的活動。l客戶評估：客

20、戶使用原型，反饋修改意見；根據(jù)客戶的反饋，對產(chǎn)品及其開發(fā)過程進(jìn)行評審，決定是否進(jìn)入螺旋線的下一個回路。 507. 噴泉模型噴泉模型l噴泉模型認(rèn)為軟件開發(fā)過程的各個階段是相互重疊和多次反復(fù)的，就象噴泉一樣，水噴上去又可以落下來，既可以落在中間，又可以落到底部。l各個開發(fā)階段沒有特定的次序要求，完全可以并行進(jìn)行，可以在某個開發(fā)階段中隨時補(bǔ)充其他任何開發(fā)階段中遺漏的需求。l優(yōu)點：- 提高開發(fā)效率- 縮短開發(fā)周期l缺點：難于管理 5152特點特點：1、各階段之間的無縫連接；2、箭頭表示各階段內(nèi)部的迭代；3、維護(hù)期圓較小，說明維護(hù)時間縮短。538. 構(gòu)件組裝模型構(gòu)件組裝模型l構(gòu)件組裝模型利用模塊化思想將

21、整個系統(tǒng)模塊化，并在一定構(gòu)件模型的支持下復(fù)用構(gòu)件庫中的一個或多個軟件構(gòu)件，通過組裝高效率、高質(zhì)量地構(gòu)造軟件系統(tǒng)。構(gòu)件組裝模型本質(zhì)上是演化的，開發(fā)過程是迭代的 。l構(gòu)件組裝模型的開發(fā)過程就是構(gòu)件組裝的過程，維護(hù)的過程就是構(gòu)件升級、替換和擴(kuò)充的過程。 5455l優(yōu)點：- 充分利用軟件復(fù)用，提高了軟件開發(fā)的效率。 - 允許多個項目同時開發(fā)，降低了費用，提高了可維護(hù)性，可實現(xiàn)分步提交軟件產(chǎn)品。 l缺點：- 缺乏通用的構(gòu)件組裝結(jié)構(gòu)標(biāo)準(zhǔn)，風(fēng)險較大；- 構(gòu)件可重用性和系統(tǒng)高效性之間不易協(xié)調(diào)；- 由于過分依賴于構(gòu)件，構(gòu)件質(zhì)量影響著最終產(chǎn)品的質(zhì)量。 569. 快速應(yīng)用開發(fā)模型快速應(yīng)用開發(fā)模型 快速應(yīng)用開發(fā)（Ra

22、pid Application Development，RAD）是一個增量型的軟件開發(fā)過程模型，強(qiáng)調(diào)極短的開發(fā)周期 。57lRAD模型的缺點：- 并非所有應(yīng)用都適合采用RAD，如果一個應(yīng)用不能被模塊化，那么構(gòu)造應(yīng)用的構(gòu)件就無法快速獲?。?- 由于時間約束，開發(fā)人員和客戶必須在較短的時間內(nèi)完成一系列的需求分析，溝通配合不當(dāng)都會導(dǎo)致應(yīng)用RAD模型的失敗 ；- RAD適合于管理信息系統(tǒng)的開發(fā)；對于其它類型的應(yīng)用系統(tǒng)，如技術(shù)風(fēng)險較高、與外圍系統(tǒng)的互操作性較高等，不太合適 。58傳統(tǒng)方法學(xué)的缺點傳統(tǒng)方法學(xué)的缺點l過分強(qiáng)調(diào)了分階段實施，使得開發(fā)過程各個階段之間存在嚴(yán)重的順序性和依賴性；l思維成果的可重用性

23、很差；l忽視了人在軟件開發(fā)過程中的地位和作用。59新型軟件生命周期模型新型軟件生命周期模型1. RUPlRUP（Rational Unified Process）統(tǒng)一過程模型是由Rational公司（現(xiàn)被IBM公司收購）開發(fā)的一種軟件工程過程框架，是一個面向?qū)ο蟮幕趙eb的程序開發(fā)方法論 。lRUP既是一種軟件生命周期模型，又是一種支持面向?qū)ο筌浖_發(fā)的工具，它將軟件開發(fā)過程要素和軟件工件（Work product）要素整合在統(tǒng)一的框架中 。60lRUP的基本結(jié)構(gòu)61lRUP中的軟件生命周期在時間上被分解為四個順序的階段：初始階段（Inception）、細(xì)化階段（Elaboration）、構(gòu)

24、造階段（Construction）和交付階段（Transition）。l每個階段結(jié)束于一個主要的里程碑(Major Milestones)，并在階段結(jié)尾執(zhí)行一次評估以確定這個階段的目標(biāo)是否已經(jīng)滿足。如果評估結(jié)果令人滿意的話，可以允許項目進(jìn)入下一個階段。62lRUP的9個核心工作流 6個核心過程工作流- 業(yè)務(wù)建模（Business Modeling） - 需求（Requirements） - 分析和設(shè)計（Analysis & Design） - 實現(xiàn)（Implementation） - 測試（Test） - 部署（Deployment） 633個核心支持工作流：- 配置和變更管理（Con

25、figuration & Change Management） - 項目管理（Project Management） - 環(huán)境（Environment） 64l初始階段 - 目標(biāo)是為系統(tǒng)建立商業(yè)企劃（business case）并確定項目的邊界。- 商業(yè)企劃包括項目的驗收規(guī)范、風(fēng)險評估、所需資源估計、階段計劃等。- 要確定項目邊界，需識別所有與系統(tǒng)交互的外部實體，并在較高層次上定義外部實體與系統(tǒng)交互的特性，主要包括識別外部角色（actor）、識別所有用例并詳細(xì)描述一些重要的用例。65- 階段結(jié)束里程碑：生命周期目標(biāo)（Lifecycle Objective）里程碑，包括一些重要的文檔，如

26、：項目構(gòu)想（vision）、原始用例模型、原始業(yè)務(wù)風(fēng)險評估、一個或者多個原型、原始商業(yè)企劃等。 需要對這些文檔進(jìn)行評審，以確定：正確理解用例需求、項目風(fēng)險評估合理、階段計劃可行等。 66l細(xì)化階段 - 目標(biāo)是分析問題領(lǐng)域，建立健全的體系結(jié)構(gòu)基礎(chǔ)，編制項目計劃，完成項目中高風(fēng)險需求部分的開發(fā)。- 里程碑：包括：風(fēng)險分析文檔、軟件體系結(jié)構(gòu)基線、項目計劃、可執(zhí)行的進(jìn)化原型、初始版本的用戶手冊等。 通過評審確定：軟件體系結(jié)構(gòu)已經(jīng)穩(wěn)定、高風(fēng)險的業(yè)務(wù)需求和技術(shù)機(jī)制已經(jīng)解決、修訂的項目計劃可行等。67l構(gòu)造階段- 將所有剩余的技術(shù)構(gòu)件和穩(wěn)定業(yè)務(wù)需求功能開發(fā)出來，并集成為產(chǎn)品，所有功能被詳細(xì)測試。從某種意義上

27、說，構(gòu)造階段只是一個制造過程，其重點放在管理資源及控制開發(fā)過程以優(yōu)化成本、進(jìn)度和質(zhì)量。- 里程碑：初始運行能力（Initial Operational Capability）里程碑。包括：可以運行的軟件產(chǎn)品、用戶手冊等，它決定了產(chǎn)品是否可以在測試環(huán)境中進(jìn)行部署。 通過評審確定：軟件、環(huán)境、用戶是否可以開始系統(tǒng)的運行。68l移交階段 - 移交階段的重點是確保軟件對最終用戶是可用的。交付階段可以跨越幾次迭代，包括為發(fā)布做準(zhǔn)備的產(chǎn)品測試，基于用戶反饋的少量調(diào)整。- 里程碑：產(chǎn)品發(fā)布(Product Release)里程碑。 通過評審確定：最終目標(biāo)是否實現(xiàn)，是否應(yīng)該開始產(chǎn)品下一個版本的另一個開發(fā)周期。

28、在一些情況下這個里程碑可能與下一個周期的初始階段的相重合。69lRUP通過迭代增量建模思想提高了風(fēng)險控制能力，這體現(xiàn)在： 迭代計劃安排是風(fēng)險驅(qū)動的，高風(fēng)險因素集中在前兩個階段解決，特別是體系結(jié)構(gòu)級的風(fēng)險在細(xì)化階段就得到了解決，及早降低了系統(tǒng)風(fēng)險； 每一次迭代都包括需求、設(shè)計、實施、部署和測試活動，因此，每一個中間產(chǎn)品都得到了集成測試，而且這個集成測試是在一個統(tǒng)一的軟件體系結(jié)構(gòu)指導(dǎo)下完成的；70 每一個階段結(jié)束時還有嚴(yán)格的質(zhì)量評審，保證里程碑文檔的質(zhì)量； 由于中間版本的產(chǎn)品是逐步產(chǎn)生的，而且核心功能和性能需求已經(jīng)包含在前面的版本中，所以，可以根據(jù)市場競爭的情況適時推出中間版本，降低市場風(fēng)險。71

29、RUP的最佳實踐： 短時間分區(qū)式的迭代：26周，不鼓勵時間推遲； 適應(yīng)性開發(fā)：小步驟、快速反饋和調(diào)整； 在早期迭代中解決高技術(shù)風(fēng)險和高業(yè)務(wù)價值的問題； 不斷地讓用戶參與迭代結(jié)果的評估，并及時獲取反饋信息，以逐步闡明問題并引導(dǎo)項目進(jìn)展； 在早期迭代中建立內(nèi)聚的核心架構(gòu)。72 不斷地驗證質(zhì)量；盡早、經(jīng)常和實際地測試； 使用用例驅(qū)動軟件建模：用例是獲取需求、制定計劃、進(jìn)行設(shè)計、測試、編寫終端用戶文檔的驅(qū)動力量。 可視化軟件建模：使用UML（Unified Modeling Language，統(tǒng)一建模語言）進(jìn)行軟件建模。 仔細(xì)地管理需求：不要草率地對待需求，而要有機(jī)地進(jìn)行需求的提出、記錄、等級劃分、追

30、蹤。拙劣的需求管理是項目陷入麻煩的一個常見原因。 實行變更請求和配置管理。73RUP模型的優(yōu)點 提高了團(tuán)隊生產(chǎn)力，在迭代的開發(fā)過程、需求管理、可視化軟件建模、驗證軟件質(zhì)量及控制軟件變更等方面，針對所有關(guān)鍵的開發(fā)活動為每個開發(fā)成員提供了必要的準(zhǔn)則、模板和工具指導(dǎo)，并確保全體成員共享相同的知識基礎(chǔ)。它建立了簡潔和清晰的過程結(jié)構(gòu)，為開發(fā)過程提供較大的通用性。 RUP模型的缺點 RUP在理論上，是比較理想的，但在實際應(yīng)用上，還需要更多的工具的支持和普及推廣工作。 742. 敏捷模型敏捷模型l為了避免許多公司的軟件團(tuán)隊陷入過程泥潭，一批業(yè)界專家一起概括出了一些敏捷開發(fā)過程的方法：Scrum，Crysta

31、l，特征驅(qū)動軟件開發(fā)（Feature Driven Development，簡稱FDD），自適應(yīng)軟件開發(fā)（Adaptive Software Development，簡稱ASD），以及極限編程（eXtreme Programming,簡稱XP）。 l敏捷開發(fā)過程是對已有生命周期模型的補(bǔ)充，它本身不是一個完整的方法論，在應(yīng)用傳統(tǒng)的生命周期模型時可以借鑒敏捷開發(fā)的過程指導(dǎo)思想 。75l敏捷開發(fā)的價值觀：- 個人和交互勝過過程和工具；- 實用的軟件勝過面面俱到的文檔；- 客戶合作勝過合同談判；- 響應(yīng)變化勝過遵循計劃。76l敏捷開發(fā)原則：(1)優(yōu)先考慮的是通過盡早地和不斷地提交有價值的軟件使客戶滿意

32、；(2)即使到了開發(fā)的后期，也歡迎改變需求；(3)敏捷過程利用變化來為客戶創(chuàng)造競爭優(yōu)勢；(4)經(jīng)常性地交付可以工作的軟件，交付的間隔可以從幾個星期到幾個月，交付的時間間隔越短越好；(5)圍繞被激勵起來的個體來構(gòu)建項目；(6)給他們提供所需的環(huán)境和支持，并且信任他們能夠完成工作；77(7)在團(tuán)隊內(nèi)部，最具有效果并富有效率的傳遞信息的方法，就是面對面的交談；工作的軟件是首要的進(jìn)度度量標(biāo)準(zhǔn)；敏捷過程提倡可持續(xù)的開發(fā)速度；(8)負(fù)責(zé)人、開發(fā)者和用戶應(yīng)該能夠保持一個長期的、穩(wěn)定的開發(fā)速度；(9)不斷地關(guān)注優(yōu)秀的技能和好的設(shè)計會增強(qiáng)敏捷能力；(10)簡單是最根本的；(11)最好的構(gòu)架、需求和設(shè)計出自于團(tuán)隊

33、；(12)每隔一定時間，團(tuán)隊會在如何才能更有效地工作方面進(jìn)行反省，對自己的行為進(jìn)行調(diào)整。78l敏捷開發(fā)的核心實踐- 項目相關(guān)人員的積極參與 - 集體所有制 - 測試性思維 （TDD）- 創(chuàng)建簡單的內(nèi)容 - 簡單地建模 79- 公開展示模型 - 小增量建模 - 和他人一起建模 - 用代碼驗證 - 使用最簡單的工具 80l極限編程(XP-eXtreme Programming)是敏捷模型的一種實現(xiàn)過程，由Kent Beck在1996年提出 。81l極限編程的12個實踐 ：（1）小版本。為了高度迭代，與客戶展現(xiàn)開發(fā)的進(jìn)展，小版本發(fā)布是一個可交流的好辦法，客戶可以針對性提出反饋。但小版本把模塊縮得很小，會影響軟件的整體思路連貫，所以小版本也需要總體合理的規(guī)劃。（2）項目計劃。客戶需求以客戶故事的形式，由客戶負(fù)責(zé)編寫。極限編程不講求統(tǒng)一的客戶需求收集，也不是由開發(fā)人員整理，而是采取讓客戶編寫，設(shè)定優(yōu)先級別，開發(fā)人員進(jìn)行分析，并進(jìn)行技術(shù)實現(xiàn)。 當(dāng)然項目計劃可進(jìn)行多次，每次迭代完畢后再行修改?？蛻艄适率情_發(fā)人員與客戶溝通的焦點，也是版本設(shè)計的依據(jù)，所以其管理一定是有效的、溝通順暢的。82（3）現(xiàn)場客戶。極限編程要求客戶參與開發(fā)工作，客戶需求就是客戶負(fù)責(zé)編寫的，所以要求客戶在開發(fā)現(xiàn)場一起工作，并為每次迭代提供反饋。（4）隱喻（metaphor）。隱