Chapter_2 軟件過程.ppt

1、1,知識回顧,軟件的概念和特性 軟件危機 軟件工程的概念與軟件工程三要素 軟件工程知識體系,2,問題,如果讓你來組織一個軟件項目的開發(fā)，你認為首先需要關注的問題是什么？,3,項目案例,案例角色和人物,小王：軟件項目負責人,老王：公司技術老總,開發(fā)小組:小李、老趙、小田、小謝,4,軟件開發(fā)需要過程(1/3),由于時間緊迫，小王需要馬上展開軟件項目的開發(fā)工作，但是他現(xiàn)在面臨一系列頭痛的問題： 軟件項目的開發(fā)要做哪些方面的工作？ 這些工作應該按照什么樣的次序開展進行？這些工作完成后將產(chǎn)生什么樣的結果？按照什么樣的規(guī)范來書寫這些內容？ 如何讓員工知道要做哪些工作？,5,軟件開發(fā)需要過程(2/3),小王

2、向老王尋求幫助，老王告訴小王公司以前從來沒有這些方面的記錄，各個項目組都從零開始制定自己的軟件開發(fā)過程，但都沒有形成文檔。 經(jīng)過慎重考慮，小王向老王建議： 項目組需要定義軟件開發(fā)過程。 公司需要一個良好定義、文檔化的軟件開發(fā)過程，以便于支持不同項目組的開發(fā)工作。 老王同意小王的建議，并要求他制定和文檔化一個針對公司特點、并且能滿足大部分軟件項目需求的軟件開發(fā)過程。,6,軟件開發(fā)需要過程(3/3),于是，小王只好找了一大堆的資料，帶著許多疑問和困惑，考慮和制訂項目開發(fā)的過程和活動。 什么是軟件開發(fā)過程？ 如何清晰、準確、規(guī)范地對它加以定義？ 如何根據(jù)公司的特點，制定軟件開發(fā)過程？ 如何不斷地改進

3、軟件開發(fā)過程？ ,7,第二章 軟件過程,信息學院計算機系 張翠肖,8, 軟件過程 基本概念（*） 基本活動：需求工程、軟件開發(fā)、測試和演化, 案例：微軟公司軟件開發(fā)過程模型,內容提綱, 軟件過程模型 瀑布模型（*） 快速原型模型（*） 增量模型（*） 螺旋模型（*） 形式化方法模型 基于組件的開發(fā)模型,9, 軟件過程 基本概念 基本活動：需求工程、軟件開發(fā)、測試和演化, 案例：微軟公司軟件開發(fā)過程模型,內容提綱, 軟件過程模型 瀑布模型 快速原型模型 增量模型 螺旋模型 形式化方法模型 基于組件的開發(fā)模型,10,建造一個房屋的過程,相同的生命周期,不同的過程,2.1 軟件過程的概念,11,什么

4、是過程?,2.1 軟件過程的概念,針對一個給定目的的一系列操作步驟。 例如 目的：去火車站 操作步驟：去學校門口公共汽車站，乘23路汽車 每個過程都有明確的目的以及具體的操作步驟，操作步驟說明了有哪些操作以及按照什么樣的方式來執(zhí)行操作。,12,任務思維模式,用戶需求,過程,產(chǎn)品, 問題, 假設：軟件需求可以在開發(fā)初期完全確定下來, 與用戶的交互只是發(fā)生在確定需求之時和發(fā)布產(chǎn)品之后 現(xiàn)實情況很少符合上述假設,（1）任務思維與過程思維,13,“The quality of a software system is governed by the quality of the process use

5、d to develop and evolve it.” - Watts Humphrey Capability Maturity Model CMM Managing the Software Process - SPM,14,過程思維模式,用戶需求,過程,產(chǎn)品,反饋, 好處, 通過提高可見性來降低開發(fā)風險, 允許在項目進展過程中基于用戶的反饋進行項目變更,（1）任務思維與過程思維,15,（2）軟件過程的概念, 軟件過程是軟件工程人員為了獲得軟件產(chǎn)品而在軟件工具的支持下實施的一系列軟件工程活動。, 軟件過程應該明確定義, 團隊人員的工作和職責, 所執(zhí)行的活動及其順序關系 活動的內容和步驟,

6、軟件過程的目標, 標準化、預見性、生產(chǎn)率、高質量、計劃進度和預算的能力,16,軟件開發(fā)過程的組成 軟件開發(fā)活動 軟件開發(fā)活動間的關系(執(zhí)行和實施的序),17,軟件過程的運行機制,用戶需求,過程定義,活動定義 活動關系 過程制品,參與人員 活動工具,過程資源,過程執(zhí)行,用戶反饋,過程改進 過程結果 軟件產(chǎn)品,18,定義軟件過程的步驟,輸入,輸出,入口 準則,任務,確認 流程,出口 準則, 定義 入口準則：何時開始該步驟？ 可重復的任務：應該做什么？ 確認：如何知道做得怎樣？ 出口準則：已經(jīng)完成了嗎？,19,過程定義模板,20,（3）軟件過程的基本活動, 軟件過程的四個基本活動, 規(guī)格說明（Spe

7、cification）,定義軟件功能以及對其使用的限制, 軟件開發(fā)（Development）,設計和實現(xiàn)滿足規(guī)格說明的軟件, 軟件確認（Validation）,驗證軟件以保證能夠滿足客戶的要求, 軟件演化（Evolution）,改進軟件以適應不斷變化的需求, 不同的組織或軟件類型擁有不同的軟件開發(fā)活動。,21,會議記錄等,分析模型,需求規(guī)格,說明書, 軟件規(guī)格說明是確定系統(tǒng)需要的服務以及運行與開發(fā) 中所受約束的過程，也稱為需求工程。 需求工程的過程,需求獲取,需求分析,需求 規(guī)格說明,需求驗證,工作產(chǎn)品,已確認的 需求規(guī)格 說明書,軟件規(guī)格說明,持續(xù)進行的需求管理,22, 軟件設計是根據(jù)需求規(guī)

8、格說明，確定軟件體系結構， 進一步設計每個系統(tǒng)部件的實現(xiàn)算法、數(shù)據(jù)結構及其 接口等。軟件實現(xiàn)是將軟件設計轉換成程序代碼。 軟件設計的過程,需求 規(guī)格說明,設計活動,體系結構 設計 系統(tǒng) 體系結構,抽象描述 系統(tǒng) 規(guī)格說明,接口設計 接口說明,組件設計 組件說明,數(shù)據(jù)結構 設計 數(shù)據(jù)結構 說明,算法設計 算法說明,設計產(chǎn)品,軟件設計與實現(xiàn),23, 驗證和確認（Verification &Validation）需要指出軟件是否符合規(guī)格說明以及是否滿足客戶的需求。 驗證和確認包括檢查和評審過程以及系統(tǒng)測試 系統(tǒng)測試是使用由規(guī)格說明產(chǎn)生的測試用例執(zhí)行軟件的過程 軟件測試過程,需求 規(guī)格說明,系統(tǒng) 規(guī)格

9、說明,系統(tǒng)設計,詳細設計,驗收 測試計劃,系統(tǒng)集成 測試計劃,子系統(tǒng)集成 測試計劃,單元測試,維護,驗收測試,系統(tǒng) 集成測試,子系統(tǒng) 集成測試,軟件確認,24,軟件演化, 軟件的內在本質是靈活的和可變的, 隨著業(yè)務需求的變化，軟件必須進化和變更, 盡管在開發(fā)過程和演化（維護）過程之間存在劃分，但是現(xiàn),實中全新的系統(tǒng)越來越少, 認識軟件演化過程, 好的軟件需要維護, 維護軟件的成本是很高的，應該在開發(fā)階段考慮維護的問題 文檔是很重要的，但在實際開發(fā)中經(jīng)常存在文檔過時或缺少,文檔的情況,25,例子：開發(fā)過程流程,發(fā)布管理過程 計劃文檔,產(chǎn)品規(guī)劃過程 產(chǎn)品目標文檔,功能測試過程 待測試的代碼,體系結

10、構設計階段 體系結構文檔,編碼階段 程序代碼,功能規(guī)格說明階段 功能說明文檔,單元測試階段 測試后代碼,單元測試 文檔,設計規(guī)格說明階段,設計說明文檔,代碼審查階段,設計子流程,軟件開發(fā)流程,編碼與單元測試子流程,26,例子：設計規(guī)格說明階段, 入口準則, 由計劃負責人和開發(fā)負責人決定是否在編碼之前需要更詳細,的設計規(guī)格說明, 出口準則, 設計規(guī)格說明書通過批準, 輸入, 與該模塊相關的功能規(guī)格說明, 輸出,經(jīng)批準的設計規(guī)格說明書,與所批準的設計規(guī)格說明書相關的配置項 評審文檔的質量記錄 批準文檔的質量記錄,27,例子：設計規(guī)格說明階段, 設計規(guī)格說明的評審者, 固定評審人, 計劃負責人，開發(fā)

11、負責人，功能測試負責人 相關組件的開發(fā)負責人（由計劃負責人決定）, 可用性測試代表（如果在功能規(guī)格說明或用戶接口文檔中缺少附,加的外部接口細節(jié)）, 可選評審人, 開發(fā)團隊人員, 系統(tǒng)測試和性能測試人員，文檔編寫人員，可用性測試人員, 設計規(guī)格說明的批準者, 開發(fā)負責人,28, 流程 設計負責人決定所建設計規(guī)格說明書的數(shù)量和范圍 設計規(guī)格說明負責人參考模板創(chuàng)建文檔 將設計規(guī)格說明書發(fā)布在配置庫中,評審文檔 開發(fā)負責人批準所有的設計規(guī)格說明書,例子：設計規(guī)格說明階段,29,例子：編碼與單元測試子流程, 入口準則, 已經(jīng)獲得功能規(guī)格說明和設計規(guī)格說明, 出口準則, 體系結構文檔, 代碼已編寫并準備進

12、行構建, 輸入, 軟件開發(fā)文檔 軟件設計文檔, 輸出, 代碼, 單元測試檢查單,30,例子：編碼與單元測試子流程, 代碼審查者, 由代碼審查過程指導手冊中指定人員, 編碼與單元測試過程,基于編碼指南編寫程序代碼 對所編寫代碼進行單元測試 執(zhí)行代碼審查,將代碼登入配置管理系統(tǒng), 輸出文檔, 代碼審查結果, 編碼與單元測試過程檢查單,31,討論：項目的軟件過程,項目開始,需求階段,開發(fā)階段 穩(wěn)定階段 項目結束,項目規(guī)劃,需求分析,軟件開發(fā),軟件測試,項目收尾,軟件維護,軟件原型,迭代開發(fā)1 迭代開發(fā)2 集成測試,軟件交付,軟件需求 規(guī)格說明,軟件 設計說明,軟件 代碼,軟件測試文檔 可交付的軟件,

13、迭代,項目里程碑,32, 軟件過程 基本概念 基本活動：需求工程、軟件開發(fā)、測試和演化, 案例：微軟公司軟件開發(fā)過程模型,內容提綱, 軟件過程模型 瀑布模型 快速原型模型 增量模型 螺旋模型 形式化方法模型 基于組件的開發(fā)模型,33,2.2 軟件過程模型,軟件過程模型描述軟件過程的整體框架，是軟件過程的一種抽象表示。,34,(1) 瀑布模型,特點： 開發(fā)階段嚴格按照線性方式進行 階段間有因果關系 每個階段需評審確認 允許反饋 強調文檔,適合場所 需求易于完善定義的軟件,W. Royce，1970,35, 挑戰(zhàn), 實際的項目開發(fā)很少是線性的過程，客戶很難明確地描述軟,件需求, 缺點, 各個階段的

14、劃分完全固定，階段之間產(chǎn)生大量的文檔，極大,地增加了工作量, 開發(fā)過程中很難響應客戶的變更要求, 早期的錯誤可能要等到開發(fā)后期的測試階段才能發(fā)現(xiàn)，進而,帶來嚴重的后果,(1) 瀑布模型,36,(2) 快速原型模型,Why 用戶不能明確需求 開發(fā)人員不確認方案的可行性 軟件人員和用戶難以溝通 難以預期系統(tǒng)運行的效果 ,37,(2) 快速原型模型,What? 軟件的一個早期可運行版本，反映最終系統(tǒng)的部分、重要特性 快速實現(xiàn)，投入運行 表現(xiàn)出目標系統(tǒng)的功能和行為特性，但不需符合全部的實現(xiàn)需求功能和性能上的取舍 原型模型的優(yōu)點 加強用戶和軟件人員之間的溝通，明確系統(tǒng)的需求，“共同語言” 盡早得到系統(tǒng)可

15、用性的反饋信息，及時修改以獲得完整、正確需求 原型模型的缺陷 用戶會由于看到的原型系統(tǒng)不完善，而對產(chǎn)品產(chǎn)生懷疑 可能為了快速開發(fā)原型系統(tǒng)，而采用未經(jīng)充分論證的技術（如操作系統(tǒng)平臺、主要的算法）,38,(2) 快速原型模型,原型系統(tǒng)類型 探索型：需求分析初期，明確開發(fā)目標 實驗型：大規(guī)模開發(fā)和實現(xiàn)之前，考核方案 進化型：使系統(tǒng)易于變化，逐步演化成目標系統(tǒng) 原型系統(tǒng)的使用策略 廢棄策略 追加策略（演化）,39, 快速原型需要迅速建造一個可以運行的軟件原型 ，以便理解和澄清問題，使開發(fā)人員與用戶達成共識。,(2) 快速原型模型,特點 有效適應用戶需求的變化 不知循環(huán)多少次，進度難以控制,適合場所 需

16、求動態(tài)變化、難以確定的軟件系統(tǒng),40, 目的, 減少開發(fā)風險和需求不確定性, 缺點, 原型系統(tǒng)的內部結構可能不好, 開發(fā)人員需要掌握建立快速原型的開發(fā)技術和工具, 適用, 小型或中等規(guī)模的交互式系統(tǒng), 大型系統(tǒng)的某些部分，例如用戶界面 生命周期較短的系統(tǒng),(2) 快速原型模型,41,定義 框架需求,設計 體系結構,增量 1 （核心產(chǎn)品）,分析,設計,編碼,測試,交付,增量 2,分析,設計,編碼,測試,交付,增量 n,分析,設計,編碼,測試,交付,最終 軟件系統(tǒng),(3) 增量模型,42,(3) 增量模型,43, 優(yōu)點, 整個產(chǎn)品被分解成若干個構件逐步交付，用戶可以不斷地看,到所開發(fā)軟件的可運行中

17、間版本, 將早期增量作為原型有助于明確后期增量的需求 降低開發(fā)風險, 重要功能被首先交付，從而使其得到最多的測試, 缺點, 需要軟件具備開放式的體系結構, 需求難以在增量實現(xiàn)之前詳細定義，因此增量與需求的準確,映射以及所有增量的有效集成可能會比較困難, 容易退化為邊做邊改方式，使軟件過程的控制失去整體性,(3) 增量模型,44,(4) 螺旋模型,45, 螺旋回線, 每一個回線表示開發(fā)過程的一個階段, 例如最中心的第一個回線可能與系統(tǒng)可行性有關，接著第二,個回線與需求定義有關，第三個回線與軟件設計有關等, 四個步驟, 確定該階段目標、完成這些目標的可選方案及其約束條件 從風險角度分析方案的開發(fā)策

18、略，努力排除各種潛在的風,險，在需求不適當?shù)那闆r下可能需要建造原型系統(tǒng), 軟件開發(fā)和驗證工作, 評價該階段的結果，并規(guī)劃下一個開發(fā)階段,(4) 螺旋模型,46, 優(yōu)點, 關注軟件的重用, 關注早期錯誤的消除 將質量目標放在首位, 將開發(fā)階段與維護階段結合在一起, 缺點, 需要風險評估的經(jīng)驗,(4) 螺旋模型,47, 形式化方法模型是采用形式化的數(shù)學方法將系統(tǒng)描述轉換成可執(zhí)行的程序。,形式化描述,形式化轉換 1 形式化轉換 2, 形式化轉換 n,集成和 系統(tǒng)測試,(5) 形式化方法模型,需求定義,48, 適用, 特別適合于那些對安全性、可靠性和保密性要求極高的軟件,系統(tǒng)，這些系統(tǒng)需要在投入運行前

19、進行驗證, 優(yōu)點, 由于數(shù)學方法具有嚴密性和準確性，形式化方法開發(fā)過程所,交付的軟件系統(tǒng)具有較少的缺陷和較高的安全性, 缺點, 開發(fā)人員需要具備一定技能并經(jīng)過特殊訓練 形式化描述和轉換是一項費時費力的工作, 現(xiàn)實應用的系統(tǒng)大多數(shù)是交互性強的軟件，但是這些系統(tǒng)難,以用形式化方法進行描述,(5) 形式化方法模型,49, 基于組件的開發(fā)技術是使用可重用的組件或商業(yè)組件 建立復雜的軟件系統(tǒng)。,需求定義,組件分析,需求修改,組件選取 組件庫,面向復用的 系統(tǒng)設計,開發(fā)和集成 組件更新,系統(tǒng)驗證,(6) 基于組件的開發(fā)模型,50, 組件開發(fā)技術的兩個重要因素, 基于組件的軟件體系結構 基于組件的開發(fā)過程, 優(yōu)點, 充分體現(xiàn)軟件復用的思想 實現(xiàn)快速交付軟件, 缺點, 商業(yè)組件的修改受到限制，影響系統(tǒng)的演化,(6) 基于組件的開發(fā)模型,51, 軟件過程 基本概念 基本活動：需求工程、軟件開發(fā)、測試和演化, 案例：微軟公司軟件開發(fā)過程模型,內容提綱, 軟件過程模型 瀑布模型 快速原型模型 增量模型 螺旋模型 形式化方法模型 基于組件的開發(fā)模型,52,案例：微軟公司的軟件開發(fā)過程, 微軟公司的開發(fā)管理原則, 以目標驅動的開發(fā)過程 具有外部可見的里程碑 基于多版本的產(chǎn)品發(fā)布 并行協(xié)作的小型化團隊 經(jīng)常性的同步和穩(wěn)定,48,53,49,案例