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

軟件過程框架與軟件過程模型第一頁，共八十八頁，2022年，8月28日軟件過程框架什么是過程？針對一個給定目標的一系列操作步驟。

例如

-目標：去火車站

-操作步驟：去南門/東門公共汽車站，乘50/17路汽車，…

每個過程都有明確的目的以及具體的操作步驟，操作步驟說明了有哪些操作以及按照什么樣的方式來執(zhí)行操作。2第二頁，共八十八頁，2022年，8月28日什么是軟件開發(fā)過程？按照項目的進度、成本和質(zhì)量限制，開發(fā)和維護滿足用戶需求的軟件所必需的一組有序的軟件開發(fā)活動集合。

軟件開發(fā)活動的例子-需求分析-體系結構設計

開發(fā)活動的順序例子-先做需求分析，然后再做體系結構設計……3第三頁，共八十八頁，2022年，8月28日在按任務性質(zhì)，軟件開發(fā)活動可分為二種形式技術活動-對軟件項目實施開發(fā)，產(chǎn)生軟件產(chǎn)品-例如，需求分析，概要設計，編碼，單元測試等等管理活動-對軟件項目中的人、產(chǎn)品和過程等實施管理的活動-例如，制訂軟件項目計劃，軟件配置等等4第四頁，共八十八頁，2022年，8月28日如何定義軟件開發(fā)活動?-名稱-任務-輸入:開始所必需滿足的條件-輸出:完成時所必須滿足的條件以及結果-實施:做什么，怎么做(詳細的步驟)，或者如何從輸入產(chǎn)生輸出軟件開發(fā)活動輸入輸出5第五頁，共八十八頁，2022年，8月28日軟件活動例子:-名字：單元測試-任務對軟件基本單元模塊進行測試，判斷是否有錯-輸入有一個已完成、被文檔化和批準的軟件單元測試計劃供測試的軟件單元模塊代碼-實施遵循單元測試計劃，運行所有的測試用例撰寫單元測試報告-輸出單元測試報告6第六頁，共八十八頁，2022年，8月28日為什么需要軟件過程？

-明確了軟件開發(fā)的過程和步驟，促進工程化軟件開發(fā)

-便于制定軟件項目計劃

-為軟件開發(fā)提供了可視性，便于對軟件開發(fā)過程進行管理和控制

-便于細化和安排任務，使得每個人員明確各自的工作7第七頁，共八十八頁，2022年，8月28日軟件開發(fā)過程模型軟件開發(fā)過程模型-軟件開發(fā)過程模型是軟件開發(fā)全過程、軟件開發(fā)活動以及它們之間關系的結構框架-指導軟件開發(fā)以及軟件開發(fā)過程的定義常用的軟件開發(fā)過程模型-瀑布模型-原型模型-增量模型-迭代模型-螺旋模型8第八頁，共八十八頁，2022年，8月28日軟件過程分類

-

基本過程類是構成軟件生存周期主要部分的那些過程,包括：定義、構建、維護等過程.

-支持過程類可穿插到基本過程中提供支持的一系列過程,包括：文檔開發(fā)、配置管理、質(zhì)量保證、驗證、確認、聯(lián)合評審、審計、問題解決等程.

-組織過程類一個組織用來建立、實施一種基礎結構,并不斷改進該基礎結構的過程,包括：管理、計劃、改進、培訓等過程.9第九頁，共八十八頁，2022年，8月28日工作任務里程碑、交付物SQA（軟件質(zhì)量保證）點任務集合技術性活動公共過程框架支持性活動公共軟件過程框架10第十頁，共八十八頁，2022年，8月28日

一個公共過程框架，是通過定義若干框架活動來建立的，如果不考慮其規(guī)模和復雜性，這些活動適用于所有軟件項目。

任務集合——每一個集合都由軟件工程工作任務、項目里程碑、軟件工程產(chǎn)品和交付物以及質(zhì)量保證點組成——使得框架活動適應于不同軟件項目的特征和項目組的需求。

支持性活動——如軟件質(zhì)量保證，軟件配置管理和測度，它們貫穿于整個過程模型之中。支持性活動獨立于任何一個框架活動，且貫穿于整個過程。11第十一頁，共八十八頁，2022年，8月28日管理性活動-軟件項目跟蹤和控制允許項目組根據(jù)計劃來評估項目進度，并且采取必要的措施保證項目按進度計劃進行。-風險管理評估可能對項目成果或者產(chǎn)品質(zhì)量產(chǎn)生影響的風險。-軟件質(zhì)量保證確定和執(zhí)行用以保證軟件質(zhì)量的活動。

·正式技術評審:

評估軟件工程產(chǎn)品，盡量在錯誤傳播到下一個動作或活動之前，發(fā)現(xiàn)并清除錯誤。

·V&V（VerificationandValidation）：驗證與確認。12第十二頁，共八十八頁，2022年，8月28日-測量定義和收集過程、項目和產(chǎn)品的度量，以幫助團隊在發(fā)布軟件的時候滿足客戶要求。同時，測量還可與其它框架協(xié)同使用。-軟件配置管理管理整個軟件過程中變更所帶來的影響。-可復用管理定義產(chǎn)品復用的標準（包括軟件構件），并且建立構件復用機制。-工作產(chǎn)品（WorkProduct）的準備和生產(chǎn)

包括了創(chuàng)建產(chǎn)品所必須的活動如建模、文檔、日志、表格和列表等。13第十三頁，共八十八頁，2022年，8月28日主要的開發(fā)和支持過程

1、軟件需求分析

任務：收集、分析、理解、確定用戶的要求；然后把用戶的要求精確、完整地描述表達出來。

目的：要回答“要解決什么問題？”，既系統(tǒng)“做什么？”。

輸入：系統(tǒng)需求文檔/問題陳述、本過程相關工作計劃步驟：可行性研究、需求分析、制定相關開發(fā)計劃

輸出：可行性報告、需求規(guī)范、下一過程開發(fā)計劃

需求說明書是讓用戶理解:“什么是他們真正需要的”；讓開發(fā)者理解“什么是他們真正的開發(fā)目標”。14第十四頁，共八十八頁，2022年，8月28日ReviewItemDiscrepancy15第十五頁，共八十八頁，2022年，8月28日任務：給出實現(xiàn)系統(tǒng)的實施藍圖。目的：要回答“如何解決該問題？”，既系統(tǒng)“怎樣做？”。輸入：軟件需求規(guī)范、本過程相關計劃步驟：概要設計：解決系統(tǒng)的子系統(tǒng)/模塊劃分、子系統(tǒng)/模塊的層次結構及數(shù)據(jù)庫設計；詳細設計：解決每個模塊/類內(nèi)部算法和數(shù)據(jù)結構；制定下一過程相關計劃。輸出：體系結構設計說明書、詳細設計說明書、下一過程相關計劃2、軟件設計16第十六頁，共八十八頁，2022年，8月28日17第十七頁，共八十八頁，2022年，8月28日18第十八頁，共八十八頁，2022年，8月28日3、軟件構造任務：根據(jù)設計說明書中每個模塊的控制流程編寫出相應的源程序。目的：寫出高質(zhì)量的代碼和相應的文檔。-構造要注意使系統(tǒng)更易于使用和系統(tǒng)的可重用性。-選擇合適的開發(fā)工具及系統(tǒng)軟件、數(shù)據(jù)庫軟件、中間件等。制定編程規(guī)范。輸入：軟件設計文檔、本過程相關計劃步驟：編程、單元測試、制定下一階段相關計劃、編制用戶文檔輸出：源程序和相關文檔、下一過程相關計劃19第十九頁，共八十八頁，2022年，8月28日4、軟件測試任務：檢查、發(fā)現(xiàn)程序中的錯誤，提高系統(tǒng)可靠性。目的：保證系統(tǒng)的正確性、可靠性和可用性?；卮穑骸霸撓到y(tǒng)是否能實現(xiàn)規(guī)定的操作？”。輸入：已經(jīng)完成的代碼、本過程相關的計劃步驟：集成測試、系統(tǒng)測試、確認測試輸出：測試報告和軟件修改報告等。20第二十頁，共八十八頁，2022年，8月28日5、軟件維護任務：改正軟件系統(tǒng)在使用過程中發(fā)現(xiàn)的隱含錯誤，擴充在使用過程中新的功能要求。目的：維護軟件系統(tǒng)的正常運行?；卮穑合到y(tǒng)是否滿足用戶的應用要求。輸入：問題報告步驟：問題報告審批、問題修改、審核輸出：軟件修改報告。21第二十一頁，共八十八頁，2022年，8月28日6.軟件配置管理軟件修改后會發(fā)生什么呢？-同步更新——當兩個或兩個以上的角色各自工作在同一產(chǎn)物上時，最后一個修改者會破壞前者的工作。-通知不達——當被若干開發(fā)者共享的產(chǎn)品中的問題被解決時，修改未被通知到一些開發(fā)者。-多個版本——軟件修改與文檔不一致。-新版本公布的管理和監(jiān)控。配置和變更管理提供了準則管理演化系統(tǒng)中的多個變體，跟蹤給定軟件創(chuàng)建過程中的版本。22第二十二頁，共八十八頁，2022年，8月28日SRD23第二十三頁，共八十八頁，2022年，8月28日7.軟件工程管理

項目管理是過程管理的主要體現(xiàn)：(1)建立與客戶的溝通渠道；(2)制訂計劃，定義資源、時限、落實到開發(fā)組；(3)風險分析，評估所采用的技術和管理帶來的風險；(4)技術過程監(jiān)控；(5)客戶評審，獲得客戶的反饋。24第二十四頁，共八十八頁，2022年，8月28日25第二十五頁，共八十八頁，2022年，8月28日26第二十六頁，共八十八頁，2022年，8月28日8.軟件質(zhì)量保證軟件質(zhì)量保證SQA活動，貫穿于軟件過程始終。開發(fā)單位成立SQA小組負責全面質(zhì)量管理。在開發(fā)項目計劃時就要做出SQA計劃。其工作：-各種測試：測試軟件是否滿足規(guī)格說明要求。-各種評審/審計：為多種人員參與的討論會，以規(guī)格說明或各種標準、規(guī)范為準評價各項軟件工作。-報告和記錄：所有測試、評審、審計都要詳細記錄并寫出報告，報告和記錄均要整理、歸檔。

以上活動均應在軟件質(zhì)量保證計劃中列出。27第二十七頁，共八十八頁，2022年，8月28日28第二十八頁，共八十八頁，2022年，8月28日傳統(tǒng)軟件生命周期模型1.瀑布模型

WinstonRoyce在軟件生命周期概念的基礎上，于1970年提出了著名的“瀑布模型”（waterfallmodel）。29第二十九頁，共八十八頁，2022年，8月28日瀑布模型中的每一個開發(fā)活動具有下列特征：-本活動的工作對象來自于上一項活動的輸出，這些輸出一般是代表本階段活動結束的里程碑式的文檔。-根據(jù)本階段的活動規(guī)程執(zhí)行相應的任務。-產(chǎn)生本階段活動相關產(chǎn)出——軟件產(chǎn)品，作為下一活動的輸入。-對本階段活動執(zhí)行情況進行評審。30第三十頁，共八十八頁，2022年，8月28日瀑布模型的優(yōu)缺點優(yōu)點缺點降低了軟件開發(fā)的復雜程度，而且提高了軟件開發(fā)過程的透明性，提高了軟件開發(fā)過程的可管理性。模型缺乏靈活性，特別是無法解決軟件需求不明確或不準確的問題。推遲了軟件實現(xiàn)，強調(diào)在軟件實現(xiàn)前必須進行分析和設計工作。模型的風險控制能力較弱。以項目的階段評審和文檔控制為手段有效地對整個開發(fā)過程進行指導，保證了階段之間的正確銜接，能夠及時發(fā)現(xiàn)并糾正開發(fā)過程中存在的缺陷，從而能夠使產(chǎn)品達到預期的質(zhì)量要求。瀑布模型中的軟件活動是文檔驅(qū)動的，當階段之間規(guī)定過多的文檔時，會極大地增加系統(tǒng)的工作量；而且當管理人員以文檔的完成情況來評估項目完成進度時，往往會產(chǎn)生錯誤的結論。31第三十一頁，共八十八頁，2022年，8月28日2.V模型和W模型

1980年代后期PaulRook提出了V模型32第三十二頁，共八十八頁，2022年，8月28日Evolutif公司在V模型的基礎上提出了W模型33第三十三頁，共八十八頁，2022年，8月28日3.原型方法原型方法的產(chǎn)生

-瀑布模型、V模型和W模型都將軟件生命周期劃分成獨立串行的幾個階段，前一個階段沒有完成便無法開始下一階段的工作。

-然而完整而準確的需求規(guī)格說明是很難得到的，因為：在開發(fā)早期用戶往往對系統(tǒng)只有一個模糊的想法，很難完全準確地表達對系統(tǒng)的全面要求隨著開發(fā)工作的推進，用戶可能會產(chǎn)生新的要求開發(fā)者又可能在設計與實現(xiàn)的過程中遇到一些沒有預料到的實際困難，需要以改變需求來解脫困境34第三十四頁，共八十八頁，2022年，8月28日原型方法指在獲得一組基本需求后，通過快速分析構造出一個小型的軟件系統(tǒng)原型，滿足用戶的基本要求。用戶通過使用原型系統(tǒng)，提出修改意見，從而減少用戶與開發(fā)人員對系統(tǒng)需求的誤解，使需求盡可能準確。原型方法主要用于明確需求，但也可以用于軟件開發(fā)的其它階段。35第三十五頁，共八十八頁，2022年，8月28日原型的三種作用類型：（1）探索型：弄清用戶對目標系統(tǒng)的要求，確定所期望的特性；探討多種實現(xiàn)方案的可行性。主要針對需求模糊、用戶和開發(fā)者對項目開發(fā)都缺乏經(jīng)驗的情況。（2）實驗型；用于大規(guī)模開發(fā)和實現(xiàn)之前，考核技術實現(xiàn)方案是否合適。（3）進化型：在構造系統(tǒng)的過程中能夠適應需求的變化，通過不斷地改進原型，逐步將原型進化成最終的系統(tǒng)。它將原型方法的思想擴展到軟件開發(fā)的全過程，適用于需求經(jīng)常變動的軟件項目。36第三十六頁，共八十八頁，2022年，8月28日原型方法的特點：（1）從認知論的角度看，原型方法遵循了人們認識事物的規(guī)律，因而更容易為人們所普遍接受，這主要表現(xiàn)在：①人們對任何事物的認知都不可能一蹴而就、盡善盡美；②認識和學習的過程都是循序漸進的；③對于事物的描述，往往都是受環(huán)境的啟發(fā)而不斷完善的；④人們批評指責一個已有的事物，要比空洞地描述自己的設想容易得多，改進一些事物要比創(chuàng)造一些事物容易得多。37第三十七頁，共八十八頁，2022年，8月28日⑵原型方法將模擬的手段引入分析的初期階段，溝通了人們的思想，縮短了用戶和開發(fā)人員之間的距離。這主要表現(xiàn)在：①所有問題的討論都是圍繞某一個確定原型而進行的，彼此之間不存在誤解和答非所問的可能性，為準確認識問題創(chuàng)造了條件。②有了原型才能啟發(fā)人們對原來想不起來或不易準確描述的問題有一個比較確切的描述；③能夠及早地暴露出系統(tǒng)實現(xiàn)后存在的一些問題，促使人們在系統(tǒng)實現(xiàn)之前就加以解決。38第三十八頁，共八十八頁，2022年，8月28日原型法的適用范圍和局限性：-對于一個大型系統(tǒng)，如果不經(jīng)過系統(tǒng)分析得到系統(tǒng)的整體劃分，而直接用原型來模擬是很困難的。-對于原有應用的業(yè)務流程、信息流程混亂的情況，原型構造與使用有一定的困難。-對于一個批處理系統(tǒng)，由于大部分活動是內(nèi)部處理的，因此應用原型方法會有一定的困難。39第三十九頁，共八十八頁，2022年，8月28日原型方法存在的問題：-文檔容易被忽略。-建立原型的許多工作會被浪費掉。-項目難以規(guī)劃和管理。40第四十頁，共八十八頁，2022年，8月28日原型方法可以支持軟件生命周期的不同階段41第四十一頁，共八十八頁，2022年，8月28日4.迭代模型(Iterative)使用瀑布模型人們認識到，由于需求很難調(diào)研充分，所以很難一次性開發(fā)成功。迭代模型提倡兩次開發(fā)：-第一次是試驗開發(fā)，得到試驗性的原型產(chǎn)品，其目標只是在于探索可行性，弄清軟件需求；-第二次在此基礎上獲得較為滿意的軟件產(chǎn)品。42第四十二頁，共八十八頁，2022年，8月28日迭代模型分類：-探索式迭代模型-進化型迭代模型迭代模型的特點：-優(yōu)點：明確用戶需求、提高系統(tǒng)質(zhì)量、降低開發(fā)風險；-缺點：難于管理、結構較差、技術不成熟；迭代模型適用范圍：-需求不清楚；-小型或中小型系統(tǒng)；-開發(fā)周期短43第四十三頁，共八十八頁，2022年，8月28日5.增量模型Mills等人于1980年提出，指首先對系統(tǒng)最核心或最清晰的需求進行分析、設計、實現(xiàn)、測試并集成到系統(tǒng)中。再按優(yōu)先級逐步對后續(xù)的需求進行上述工作，逐步建設成一個完整系統(tǒng)的開發(fā)方法。44第四十四頁，共八十八頁，2022年，8月28日45第四十五頁，共八十八頁，2022年，8月28日增量模型的優(yōu)點：-有利于增加客戶對系統(tǒng)的信心；-降低系統(tǒng)失敗風險；-提高系統(tǒng)可靠性；-提高了系統(tǒng)的穩(wěn)定性和可維護性；增量模型的缺點：-增量粒度難以選擇；-確定所有的基本業(yè)務服務比較困難。46第四十六頁，共八十八頁，2022年，8月28日6.螺旋模型Boehm于1988年提出，主要針對大型軟件項目的開發(fā)。大型軟件項目的特點：（1）需求功能復雜，無法一開始就明確；開發(fā)周期長，中途需求經(jīng)常變化；（2）往往存在諸多風險因素，在不同程度上損害軟件開發(fā)過程和軟件產(chǎn)品的質(zhì)量，所以必須對風險進行管理。螺旋模型最大特點就是引入了明確的風險管理。47第四十七頁，共八十八頁，2022年，8月28日48第四十八頁，共八十八頁，2022年，8月28日制定計劃：確定軟件項目目標；明確對軟件開發(fā)過程和軟件產(chǎn)品的約束；制定詳細的項目管理計劃；根據(jù)當前的需求和風險因素，制定實施方案，并進行可行性分析，選定一個實施方案，并對其進行規(guī)劃。風險分析：明確每一個項目風險，估計風險發(fā)生的可能性、頻率、損害程度，并制定風險管理措施規(guī)避這些風險。實施工程：針對每一個開發(fā)階段的任務要求執(zhí)行本開發(fā)階段的活動?？蛻粼u估：客戶使用原型，反饋修改意見；根據(jù)客戶的反饋，對產(chǎn)品及其開發(fā)過程進行評審，決定是否進入螺旋線的下一個回路。49第四十九頁，共八十八頁，2022年，8月28日7.噴泉模型噴泉模型認為軟件開發(fā)過程的各個階段是相互重疊和多次反復的，就象噴泉一樣，水噴上去又可以落下來，既可以落在中間，又可以落到底部。各個開發(fā)階段沒有特定的次序要求，完全可以并行進行，可以在某個開發(fā)階段中隨時補充其他任何開發(fā)階段中遺漏的需求。優(yōu)點：-提高開發(fā)效率-縮短開發(fā)周期缺點：難于管理50第五十頁，共八十八頁，2022年，8月28日51第五十一頁，共八十八頁，2022年，8月28日特點：1、各階段之間的無縫連接；2、箭頭表示各階段內(nèi)部的迭代；3、維護期圓較小，說明維護時間縮短。52第五十二頁，共八十八頁，2022年，8月28日8.構件組裝模型構件組裝模型利用模塊化思想將整個系統(tǒng)模塊化，并在一定構件模型的支持下復用構件庫中的一個或多個軟件構件，通過組裝高效率、高質(zhì)量地構造軟件系統(tǒng)。構件組裝模型本質(zhì)上是演化的，開發(fā)過程是迭代的。構件組裝模型的開發(fā)過程就是構件組裝的過程，維護的過程就是構件升級、替換和擴充的過程。53第五十三頁，共八十八頁，2022年，8月28日54第五十四頁，共八十八頁，2022年，8月28日優(yōu)點：-充分利用軟件復用，提高了軟件開發(fā)的效率。-允許多個項目同時開發(fā)，降低了費用，提高了可維護性，可實現(xiàn)分步提交軟件產(chǎn)品。缺點：-缺乏通用的構件組裝結構標準，風險較大；-構件可重用性和系統(tǒng)高效性之間不易協(xié)調(diào)；-由于過分依賴于構件，構件質(zhì)量影響著最終產(chǎn)品的質(zhì)量。55第五十五頁，共八十八頁，2022年，8月28日9.快速應用開發(fā)模型快速應用開發(fā)（RapidApplicationDevelopment，RAD）是一個增量型的軟件開發(fā)過程模型，強調(diào)極短的開發(fā)周期。56第五十六頁，共八十八頁，2022年，8月28日RAD模型的缺點：-并非所有應用都適合采用RAD，如果一個應用不能被模塊化，那么構造應用的構件就無法快速獲??；-由于時間約束，開發(fā)人員和客戶必須在較短的時間內(nèi)完成一系列的需求分析，溝通配合不當都會導致應用RAD模型的失??；-RAD適合于管理信息系統(tǒng)的開發(fā)；對于其它類型的應用系統(tǒng)，如技術風險較高、與外圍系統(tǒng)的互操作性較高等，不太合適。57第五十七頁，共八十八頁，2022年，8月28日傳統(tǒng)方法學的缺點過分強調(diào)了分階段實施，使得開發(fā)過程各個階段之間存在嚴重的順序性和依賴性；思維成果的可重用性很差；忽視了人在軟件開發(fā)過程中的地位和作用。58第五十八頁，共八十八頁，2022年，8月28日新型軟件生命周期模型1.RUPRUP（RationalUnifiedProcess）統(tǒng)一過程模型是由Rational公司（現(xiàn)被IBM公司收購）開發(fā)的一種軟件工程過程框架，是一個面向?qū)ο蟮幕趙eb的程序開發(fā)方法論。RUP既是一種軟件生命周期模型，又是一種支持面向?qū)ο筌浖_發(fā)的工具，它將軟件開發(fā)過程要素和軟件工件（Workproduct）要素整合在統(tǒng)一的框架中。59第五十九頁，共八十八頁，2022年，8月28日RUP的基本結構60第六十頁，共八十八頁，2022年，8月28日RUP中的軟件生命周期在時間上被分解為四個順序的階段：初始階段（Inception）、細化階段（Elaboration）、構造階段（Construction）和交付階段（Transition）。每個階段結束于一個主要的里程碑(MajorMilestones)，并在階段結尾執(zhí)行一次評估以確定這個階段的目標是否已經(jīng)滿足。如果評估結果令人滿意的話，可以允許項目進入下一個階段。61第六十一頁，共八十八頁，2022年，8月28日RUP的9個核心工作流

6個核心過程工作流-業(yè)務建模（BusinessModeling）-需求（Requirements）-分析和設計（Analysis&Design）-實現(xiàn)（Implementation）-測試（Test）-部署（Deployment）62第六十二頁，共八十八頁，2022年，8月28日3個核心支持工作流：-配置和變更管理（Configuration&ChangeManagement）-項目管理（ProjectManagement）-環(huán)境（Environment）63第六十三頁，共八十八頁，2022年，8月28日初始階段-目標是為系統(tǒng)建立商業(yè)企劃（businesscase）并確定項目的邊界。-商業(yè)企劃包括項目的驗收規(guī)范、風險評估、所需資源估計、階段計劃等。-要確定項目邊界，需識別所有與系統(tǒng)交互的外部實體，并在較高層次上定義外部實體與系統(tǒng)交互的特性，主要包括識別外部角色（actor）、識別所有用例并詳細描述一些重要的用例。64第六十四頁，共八十八頁，2022年，8月28日-階段結束里程碑：生命周期目標（LifecycleObjective）里程碑，包括一些重要的文檔，如：項目構想（vision）、原始用例模型、原始業(yè)務風險評估、一個或者多個原型、原始商業(yè)企劃等。需要對這些文檔進行評審，以確定：正確理解用例需求、項目風險評估合理、階段計劃可行等。65第六十五頁，共八十八頁，2022年，8月28日細化階段-目標是分析問題領域，建立健全的體系結構基礎，編制項目計劃，完成項目中高風險需求部分的開發(fā)。-里程碑：包括：風險分析文檔、軟件體系結構基線、項目計劃、可執(zhí)行的進化原型、初始版本的用戶手冊等。通過評審確定：軟件體系結構已經(jīng)穩(wěn)定、高風險的業(yè)務需求和技術機制已經(jīng)解決、修訂的項目計劃可行等。66第六十六頁，共八十八頁，2022年，8月28日構造階段-將所有剩余的技術構件和穩(wěn)定業(yè)務需求功能開發(fā)出來，并集成為產(chǎn)品，所有功能被詳細測試。從某種意義上說，構造階段只是一個制造過程，其重點放在管理資源及控制開發(fā)過程以優(yōu)化成本、進度和質(zhì)量。-里程碑：初始運行能力（InitialOperationalCapability）里程碑。包括：可以運行的軟件產(chǎn)品、用戶手冊等，它決定了產(chǎn)品是否可以在測試環(huán)境中進行部署。

通過評審確定：軟件、環(huán)境、用戶是否可以開始系統(tǒng)的運行。67第六十七頁，共八十八頁，2022年，8月28日移交階段-移交階段的重點是確保軟件對最終用戶是可用的。交付階段可以跨越幾次迭代，包括為發(fā)布做準備的產(chǎn)品測試，基于用戶反饋的少量調(diào)整。-里程碑：產(chǎn)品發(fā)布(ProductRelease)里程碑。通過評審確定：最終目標是否實現(xiàn)，是否應該開始產(chǎn)品下一個版本的另一個開發(fā)周期。在一些情況下這個里程碑可能與下一個周期的初始階段的相重合。68第六十八頁，共八十八頁，2022年，8月28日RUP通過迭代增量建模思想提高了風險控制能力，這體現(xiàn)在：⑴迭代計劃安排是風險驅(qū)動的，高風險因素集中在前兩個階段解決，特別是體系結構級的風險在細化階段就得到了解決，及早降低了系統(tǒng)風險；⑵每一次迭代都包括需求、設計、實施、部署和測試活動，因此，每一個中間產(chǎn)品都得到了集成測試，而且這個集成測試是在一個統(tǒng)一的軟件體系結構指導下完成的；69第六十九頁，共八十八頁，2022年，8月28日⑶每一個階段結束時還有嚴格的質(zhì)量評審，保證里程碑文檔的質(zhì)量；⑷由于中間版本的產(chǎn)品是逐步產(chǎn)生的，而且核心功能和性能需求已經(jīng)包含在前面的版本中，所以，可以根據(jù)市場競爭的情況適時推出中間版本，降低市場風險。70第七十頁，共八十八頁，2022年，8月28日RUP的最佳實踐：⑴短時間分區(qū)式的迭代：2～6周，不鼓勵時間推遲；⑵適應性開發(fā)：小步驟、快速反饋和調(diào)整；⑶在早期迭代中解決高技術風險和高業(yè)務價值的問題；⑷不斷地讓用戶參與迭代結果的評估，并及時獲取反饋信息，以逐步闡明問題并引導項目進展；⑸在早期迭代中建立內(nèi)聚的核心架構。71第七十一頁，共八十八頁，2022年，8月28日⑹不斷地驗證質(zhì)量；盡早、經(jīng)常和實際地測試；⑺使用用例驅(qū)動軟件建模：用例是獲取需求、制定計劃、進行設計、測試、編寫終端用戶文檔的驅(qū)動力量。⑻可視化軟件建模：使用UML（UnifiedModelingLanguage，統(tǒng)一建模語言）進行軟件建模。⑼仔細地管理需求：不要草率地對待需求，而要有機地進行需求的提出、記錄、等級劃分、追蹤。拙劣的需求管理是項目陷入麻煩的一個常見原因。⑽實行變更請求和配置管理。72第七十二頁，共八十八頁，2022年，8月28日RUP模型的優(yōu)點提高了團隊生產(chǎn)力，在迭代的開發(fā)過程、需求管理、可視化軟件建模、驗證軟件質(zhì)量及控制軟件變更等方面，針對所有關鍵的開發(fā)活動為每個開發(fā)成員提供了必要的準則、模板和工具指導，并確保全體成員共享相同的知識基礎。它建立了簡潔和清晰的過程結構，為開發(fā)過程提供較大的通用性。RUP模型的缺點RUP在理論上，是比較理想的，但在實際應用上，還需要更多的工具的支持和普及推廣工作。73第七十三頁，共八十八頁，2022年，8月28日2.敏捷模型為了避免許多公司的軟件團隊陷入過程泥潭，一批業(yè)界專家一起概括出了一些敏捷開發(fā)過程的方法：Scrum，Crystal，特征驅(qū)動軟件開發(fā)（FeatureDrivenDevelopment，簡稱FDD），自適應軟件開發(fā)（AdaptiveSoftwareDevelopment，簡稱ASD），以及極限編程（eXtremeProgramming,簡稱XP）。敏捷開發(fā)過程是對已有生命周期模型的補充，它本身不是一個完整的方法論，在應用傳統(tǒng)的生命周期模型時可以借鑒敏捷開發(fā)的過程指導思想。74第七十四頁，共八十八頁，2022年，8月28日敏捷開發(fā)的價值觀：-個人和交互勝過過程和工具；-實用的軟件勝過面面俱到的文檔；-客戶合作勝過合同談判；-響應變化勝過遵循計劃。75第七十五頁，共八十八頁，2022年，8月28日敏捷開發(fā)原則：(1)優(yōu)先考慮的是通過盡早地和不斷地提交有價值的軟件使客戶滿意；(2)即使到了開發(fā)的后期，也歡迎改變需求；(3)敏捷過程利用變化來為客戶創(chuàng)造競爭優(yōu)勢；(4)經(jīng)常性地交付可以工作的軟件，交付的間隔可以從幾個星期到幾個月，交付的時間間隔越短越好；(5)圍繞被激勵起來的個體來構建項目；(6)給他們提供所需的環(huán)境和支持，并且信任他們能夠完成工作；76第七十六頁，共八十八頁，2022年，8月28日(7)在團隊內(nèi)部，最具有效果并富有效率的傳遞信息的方法，就是面對面的交談；工作的軟件是首要的進度度量標準；敏捷過程提倡可持續(xù)的開發(fā)速度；(8)負責人、開發(fā)者和用戶應該能夠保持一個長期的、穩(wěn)定的開發(fā)速度；(9)不斷地關注優(yōu)秀的技能和好的設計會增強敏捷能力；(10)簡單是最根本的；(11)最好的構架、需求和設計出自于團隊；(12)每隔一定時間，團隊會在如何才能更有效地工作方面進行反省，對自己的行為進行調(diào)整。77第七十七頁，共八十八頁，2022年，8月28日敏捷開發(fā)的核心實踐-項目相關人員的積極參與-集體所有制-測試性思維（TDD）-創(chuàng)建簡單的內(nèi)容-簡單地建模78第七十八頁，共八十八頁，2022年，8月28日-公開展示模型

-小增量建模

-和他人一起建模

-用代碼驗證

-使用最簡單的工具

79第七十九頁，共八十八頁，2022年，8月28日極限編程(XP-eXtremeProgramming)是敏捷模型的一種實現(xiàn)過程，由Kent

Beck在1996年提出。80第八十頁，共八十八頁，2022年，8月28日極限編程的12個實踐：（1）小版本。為了高度迭代，與客戶展現(xiàn)開發(fā)的進展，小版本發(fā)布是一個可交流的好辦法，客戶可以針對性提出反饋。但小版本把模塊縮得很小，會影響軟件的整體思路連貫，所以小版本也需要總體合理的規(guī)劃。（2）項目計劃?？蛻粜枨笠钥蛻艄适碌男问?，由客戶負責編寫。極限編程不講求統(tǒng)一的客戶需求收集，也不是由開發(fā)人員整理，而是采取讓客戶編寫，設定優(yōu)先級別，開發(fā)人員進行分析，并進行技術實現(xiàn)。當然項目計劃可進行多次，每次迭代完畢后再行修改?？蛻艄适率情_發(fā)人員與客戶溝通的焦點，也是版本設計的依據(jù)，所以其管理一定是有效的、溝通順暢的。81第