Chapter_2 軟件過(guò)程.ppt

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

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

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

4、是過(guò)程?,2.1 軟件過(guò)程的概念,針對(duì)一個(gè)給定目的的一系列操作步驟。 例如 目的：去火車(chē)站 操作步驟：去學(xué)校門(mén)口公共汽車(chē)站，乘23路汽車(chē) 每個(gè)過(guò)程都有明確的目的以及具體的操作步驟，操作步驟說(shuō)明了有哪些操作以及按照什么樣的方式來(lái)執(zhí)行操作。,12,任務(wù)思維模式,用戶需求,過(guò)程,產(chǎn)品, 問(wèn)題, 假設(shè)：軟件需求可以在開(kāi)發(fā)初期完全確定下來(lái), 與用戶的交互只是發(fā)生在確定需求之時(shí)和發(fā)布產(chǎn)品之后 現(xiàn)實(shí)情況很少符合上述假設(shè),（1）任務(wù)思維與過(guò)程思維,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,過(guò)程思維模式,用戶需求,過(guò)程,產(chǎn)品,反饋, 好處, 通過(guò)提高可見(jiàn)性來(lái)降低開(kāi)發(fā)風(fēng)險(xiǎn), 允許在項(xiàng)目進(jìn)展過(guò)程中基于用戶的反饋進(jìn)行項(xiàng)目變更,（1）任務(wù)思維與過(guò)程思維,15,（2）軟件過(guò)程的概念, 軟件過(guò)程是軟件工程人員為了獲得軟件產(chǎn)品而在軟件工具的支持下實(shí)施的一系列軟件工程活動(dòng)。, 軟件過(guò)程應(yīng)該明確定義, 團(tuán)隊(duì)人員的工作和職責(zé), 所執(zhí)行的活動(dòng)及其順序關(guān)系 活動(dòng)的內(nèi)容和步驟,

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

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

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

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

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

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

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

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

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

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

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

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

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

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