第一章(下)1.5軟件開發(fā)模型

第一章概述（續(xù)）

1.5軟件開發(fā)模型

SoftwareProcessModel瀑布模型快速原型模型增量模型螺旋模型基于構(gòu)件的開發(fā)方法凈室模型1目錄2.0軟件過程&軟件過程模型2.1瀑布模型軟件生存周期的瀑布模型各階段文檔瀑布模型的特點(diǎn)瀑布模型存在的問題2.2快速原型模型模型原型系統(tǒng)的注意事項(xiàng)原型模型的分類原型模型存在的問題2.3軟件演化模型(1)增量模型(2)螺旋模型2.4面向?qū)ο箝_發(fā)模型基于構(gòu)件的開發(fā)方法2.5形式化方法模型凈室模型2軟件過程&軟件過程模型軟件過程

軟件開發(fā)機(jī)構(gòu)(企業(yè))為開發(fā)高質(zhì)量軟件所需完成的一系列任務(wù)的框架步驟。包括工程技術(shù)和管理活動(dòng)。如方法使用的順序，可交付產(chǎn)品和文檔的格式…軟件過程模型

是軟件過程的抽象表示，為各項(xiàng)軟件開發(fā)活動(dòng)的流程所確定的合理的框架能直觀的表達(dá)軟件開發(fā)的全過程，明確規(guī)定要完成的主要活動(dòng)和任務(wù)的框架也稱為軟件過程模型，軟件工程范型或軟件生存周期模型3典型的軟件過程模型傳統(tǒng)軟件開發(fā)模型形式化方法模型瀑布模型waterfallmodel增量模型incrementalmodel快速原型rapidprototypemodel螺旋模型spiralmodel構(gòu)件集成模型componentintegrationmodel噴泉模型fountainmodel軟件演化模型面向?qū)ο箝_發(fā)模型凈室模型cleanroommodel目錄轉(zhuǎn)換模型transformationalmodel41瀑布模型(WaterfallModel)也稱典型生存周期模型(classiclifecycle)或線性順序模型(linersequentialmodel)軟件生存周期(SoftwareLifeCycle)

如同任何事務(wù)一樣，軟件也有一個(gè)孕育、誕生。成長、成熟、衰亡的生存過程，稱為軟件的生存周期。5軟件生存周期的瀑布模型問題定義可行性研究需求分析軟件設(shè)計(jì)編碼測(cè)試維護(hù)計(jì)劃時(shí)期開發(fā)時(shí)期運(yùn)行時(shí)期6(1)計(jì)劃時(shí)期問題定義

要解決的問題是什么？——確定系統(tǒng)總目標(biāo)目標(biāo)和范圍說明書可行性研究

這個(gè)項(xiàng)目值得開發(fā)么？時(shí)間，投資？對(duì)上一階段所確定的問題有行的通的解決方案么？——項(xiàng)目繼續(xù)or終止？可行性論證報(bào)告

返回返回7(2)開發(fā)時(shí)期設(shè)計(jì)(需求分析＋軟件設(shè)計(jì))＋實(shí)現(xiàn)(編碼＋測(cè)試)）需求分析

為了解決這個(gè)問題目標(biāo)系統(tǒng)必須做什么？——用戶對(duì)軟件系統(tǒng)的全部需求需求規(guī)格說明書軟件的功能需求性能需求環(huán)境和外部接口約束條件返回8軟件設(shè)計(jì)

將需求－>軟件的表現(xiàn)形式總體設(shè)計(jì)：

軟件的總體結(jié)構(gòu)詳細(xì)設(shè)計(jì) 詳細(xì)設(shè)計(jì)每個(gè)模塊確定模塊功能所需要的算法和數(shù)據(jù)結(jié)構(gòu)目標(biāo):應(yīng)使編碼的程序員根據(jù)它們可很容易的寫 出代碼!設(shè)計(jì)文檔返回9編碼：設(shè)計(jì)－>產(chǎn)生計(jì)算機(jī)源程序測(cè)試：發(fā)現(xiàn)錯(cuò)誤！軟件是否有錯(cuò)(功能上的，邏輯上的)？軟件是否達(dá)到需求規(guī)格說明書預(yù)定的要求？軟件是否滿足用戶需求？單元測(cè)試集成測(cè)試確認(rèn)測(cè)試系統(tǒng)測(cè)試測(cè)試報(bào)告：測(cè)試計(jì)劃＋測(cè)試用例＋測(cè)試結(jié)果返回返回10(3)運(yùn)行時(shí)期軟件維護(hù)使軟件在整個(gè)生存期內(nèi)滿足用戶需求，并延長使用壽命改正性維護(hù)：診斷和改正使用過程中發(fā)現(xiàn)的錯(cuò)誤適應(yīng)性維護(hù)：修改軟件以適應(yīng)環(huán)境的變化完善性維護(hù)：根據(jù)用戶要求改進(jìn)或擴(kuò)充軟件使它 更完善預(yù)防性維護(hù)：修改軟件為將來維護(hù)活動(dòng)預(yù)先做準(zhǔn)備維護(hù)報(bào)告11各階段文檔計(jì)劃時(shí)期開發(fā)時(shí)期運(yùn)行時(shí)期問題定義可行性研究需求分析軟件設(shè)計(jì)編碼測(cè)試維護(hù)目標(biāo)和范圍說明書可行性論證報(bào)告需求說明書設(shè)計(jì)文檔程序測(cè)試報(bào)告維護(hù)報(bào)告12瀑布模型的特點(diǎn)階段間具有順序性和依賴性前—階段的工作完成之后，才能開始后一階段的工作；前一階段的輸出文檔就是后一階段的輸入文檔前一階段的輸出文檔正確，后一階段工作才能獲得正確的結(jié)果。推遲實(shí)現(xiàn)的觀點(diǎn)區(qū)分邏輯設(shè)計(jì)與物理設(shè)計(jì)盡可能推遲程序物理實(shí)現(xiàn)質(zhì)量保證的觀點(diǎn)每個(gè)階段都必須完成規(guī)定的文檔，沒有交出合格的文檔就是沒有完成該階段的任務(wù)。每個(gè)階段結(jié)束前都進(jìn)行評(píng)審，若確認(rèn)，則進(jìn)行下一階段，否則返回前項(xiàng)。盡早發(fā)現(xiàn)問題改正錯(cuò)誤。13瀑布模型存在的問題基于的假設(shè)只要當(dāng)分析員能夠作出準(zhǔn)確的需求分析時(shí)，才能得到預(yù)期的正確結(jié)果順序性太過理想化，是文檔驅(qū)動(dòng)的在對(duì)軟件產(chǎn)品試用前，用戶只能從靜態(tài)的文檔來了解產(chǎn)品，要用戶完全精確和正確的對(duì)一個(gè)軟件產(chǎn)品提出確切的需求，實(shí)際上是不可能的。適合：軟件需求比較明確，需求反復(fù)性小，開發(fā)技術(shù)比較成熟的場(chǎng)合目錄142快速原型模型(RapidPrototypeModel)思想：樣機(jī)，樣板房用戶測(cè)試運(yùn)行原型聽取用戶意見建造/修改原型15模型突出“快”，用戶和系統(tǒng)分析員從紙上談兵－>真槍實(shí)彈，如一個(gè)實(shí)際系統(tǒng)，使用原型比瀑布式的方法開銷少40％，工作量少45％需求分析原型開發(fā)最終系統(tǒng)設(shè)計(jì)原型評(píng)價(jià)最終系統(tǒng)實(shí)現(xiàn)用戶反饋16原型系統(tǒng)的注意事項(xiàng)思想來源于“樣機(jī)”，但是不同于工業(yè)樣機(jī)原型應(yīng)充分展示軟件的可見部分僅包括系統(tǒng)主要功能和主要接口，不包括細(xì)節(jié)本質(zhì)是“快速”，盡量縮短開發(fā)原型的時(shí)間使用快速原型語言（shell，超文本，4GL）采用軟件重用技術(shù)在算法的時(shí)/空開銷方面也可以讓步17原型模型的分類拋棄型原型(Throw-awayprototyping)

用于試驗(yàn)?zāi)承└拍?，試?yàn)完系統(tǒng)將無用處進(jìn)化型原型(Exploratoryprogramming)

原型系統(tǒng)不斷被開發(fā)和被修正，最終它變?yōu)橐粋€(gè)真正的系統(tǒng)。18原型模型存在的問題用戶有時(shí)誤解了原型的角色，例如他們可能誤解原型應(yīng)該和真實(shí)系統(tǒng)一樣可靠。缺少控制，由于用戶可能不斷提出新要求，因而原型迭代的周期很難控制。額外的花費(fèi)：研究結(jié)果表明構(gòu)造一個(gè)原型可能需要10%額外花費(fèi)。為了盡快實(shí)現(xiàn)原型，采用了不合適的技術(shù)，后來忘了修改，運(yùn)行效率可能會(huì)受影響。原型法要求開發(fā)者與用戶密切接觸，有時(shí)這是不可能的。例如外包軟件。目錄193軟件演化模型EvolutionaryModel人們已經(jīng)越來越認(rèn)識(shí)到軟件就象所有復(fù)雜系統(tǒng)一樣要經(jīng)過一段時(shí)間的演化。業(yè)務(wù)和產(chǎn)品需求隨著開發(fā)的發(fā)展常常發(fā)生改變，想找到最終產(chǎn)品的一條直線路徑是不可能的。緊迫的市場(chǎng)期限使得難以完成一個(gè)完善的軟件產(chǎn)品，但可以先提交一個(gè)有限的版本以對(duì)付競(jìng)爭(zhēng)或商業(yè)的壓力；只要核心產(chǎn)品或系統(tǒng)需求能夠很好地理解，而產(chǎn)品或系統(tǒng)的細(xì)節(jié)部分可以進(jìn)一步定義。20思想：漸增式或迭代開發(fā)演化模型是利用一種迭代的思想方法，它的特征是使軟件工程師漸進(jìn)地開發(fā)逐步完善的軟件版本。增量模型(IncrementalModel)螺旋模型(SpiralModel)目錄21(1)增量模型IncrementalModel

增量模型把軟件產(chǎn)品看作一系列增量構(gòu)件(Increments)，在開發(fā)過程的各次迭代中，每次完成其中的一個(gè)增量。22規(guī)格說明設(shè)計(jì)實(shí)現(xiàn)和集成交付客戶第1增量增量1規(guī)格說明設(shè)計(jì)實(shí)現(xiàn)和集成交付客戶第3增量增量3規(guī)格說明設(shè)計(jì)實(shí)現(xiàn)和集成交付客戶第4增量增量4calendartimedeliveryof4thincrementCoreproduct文件管理編輯，文檔生成Morefeaturesandfunctionality完善的編輯和文檔生成規(guī)格說明設(shè)計(jì)實(shí)現(xiàn)和集成交付客戶第2增量增量2拼寫檢查&語法檢查高級(jí)頁面排版功能以增量開發(fā)字處理軟件為例23增量模型的特點(diǎn)優(yōu)點(diǎn)：分批逐步提交產(chǎn)品，短時(shí)間內(nèi)提交部分功能產(chǎn)品逐步增加產(chǎn)品功能，用戶有時(shí)間學(xué)習(xí)適應(yīng)新產(chǎn)品困難構(gòu)件集成問題－>軟件體系結(jié)構(gòu)必須是開放的增量模型自身的矛盾性軟件應(yīng)看作一個(gè)整體軟件又是構(gòu)件序列，構(gòu)件間相互獨(dú)立目錄24(2)螺旋模型SpiralModel（Boehm，1988提出）背景：“軟件風(fēng)險(xiǎn)”是任何軟件開發(fā)項(xiàng)目中都普遍存在的風(fēng)險(xiǎn)（Risk）項(xiàng)目風(fēng)險(xiǎn)：在預(yù)算、進(jìn)度、人力、資源、客戶及需求方面潛在的問題成本、時(shí)間上升技術(shù)風(fēng)險(xiǎn)：在設(shè)計(jì)、實(shí)現(xiàn)、接口、維護(hù)方面的問題質(zhì)量下降，甚至無法完工商業(yè)風(fēng)險(xiǎn)：市場(chǎng)、商業(yè)策略、推銷策略軟件的生存能力項(xiàng)目越大，軟件越復(fù)雜，所冒風(fēng)險(xiǎn)越大螺旋模型瀑布模型+快速原型+風(fēng)險(xiǎn)分析(riskanalysis)迭代過程沿螺旋線順時(shí)針迭代，每迭代一次，螺旋線前進(jìn)一周每一輪周期均包含風(fēng)險(xiǎn)分析每一輪都采用原型作為減少風(fēng)險(xiǎn)的機(jī)制產(chǎn)品規(guī)格產(chǎn)品設(shè)計(jì)可運(yùn)行的原型1.確定計(jì)劃確定目標(biāo)、方案和約束2.風(fēng)險(xiǎn)分析評(píng)估方案，識(shí)別消除風(fēng)險(xiǎn)決定項(xiàng)目命運(yùn)4.客戶評(píng)估評(píng)價(jià)開發(fā)工作計(jì)劃下一輪工作3.實(shí)施工程實(shí)施軟件開發(fā)，開發(fā)驗(yàn)證下一產(chǎn)品25提交線評(píng)審原型1風(fēng)險(xiǎn)分析Simulations,models,benchmarks需求計(jì)劃與生命周期計(jì)劃操作概念原型2風(fēng)險(xiǎn)分析Riskanalysis軟件需求Softwarerequirements需求確認(rèn)RequirementValidation開發(fā)計(jì)劃Deveplmentplan風(fēng)險(xiǎn)分析原型3Prototype3軟件產(chǎn)品設(shè)計(jì)Softwareproductdesign設(shè)計(jì)有效性和驗(yàn)證Designvalidationandverification集成與測(cè)試計(jì)劃Integrationandtestplan風(fēng)險(xiǎn)分析可運(yùn)行的原型Operationalprototype詳細(xì)設(shè)計(jì)單元測(cè)試Unittest編碼Code集成測(cè)試Integrationandtest驗(yàn)收測(cè)試Acceptancetest實(shí)現(xiàn)Implementation4.客戶評(píng)估評(píng)價(jià)開發(fā)工作計(jì)劃下一輪工作3.實(shí)施工程實(shí)施軟件開發(fā)，開發(fā)驗(yàn)證下一產(chǎn)品1.確定計(jì)劃確定目標(biāo)、方案和約束2.風(fēng)險(xiǎn)分析評(píng)估方案，識(shí)別消除風(fēng)險(xiǎn)決定項(xiàng)目命運(yùn)Cumulativecost累計(jì)費(fèi)用Progressthroughsteps各步驟進(jìn)度26螺旋模型的特點(diǎn)優(yōu)勢(shì)：

風(fēng)險(xiǎn)驅(qū)動(dòng)：在項(xiàng)目所有階段考慮技術(shù)風(fēng)險(xiǎn)，能夠在風(fēng)險(xiǎn)變成問題前降低它的危害適于大型軟件系統(tǒng)開發(fā)缺陷比較復(fù)雜，需要且成功依賴于風(fēng)險(xiǎn)評(píng)估技術(shù)主要適用于內(nèi)部大型開發(fā)若風(fēng)險(xiǎn)分析的費(fèi)用接近整個(gè)項(xiàng)目預(yù)算，則風(fēng)險(xiǎn)分析是不可行的，只有內(nèi)部開發(fā)的項(xiàng)目，風(fēng)險(xiǎn)過大時(shí)，才能方便停止。目錄274面向?qū)ο箝_發(fā)模型(Object-oriented)軟件規(guī)模龐大，或者需求是模糊或者隨時(shí)間變化時(shí)，傳統(tǒng)方法開發(fā)軟件往往不成功。28294.1噴泉模型(FountainModel)“噴泉”一詞體現(xiàn)了面向?qū)ο筌浖_發(fā)過程的迭代和無縫圓圈重疊：不同階段的重疊，各活動(dòng)存在交迭——無縫中軸線：總目標(biāo)，避免開發(fā)無序向下的箭頭：該階段內(nèi)的迭代維護(hù)圈較小無縫——各階段都使用統(tǒng)一的概念和表示符號(hào)——對(duì)象迭代——容易實(shí)現(xiàn)各步驟的多次反復(fù)迭代。進(jìn)一步開發(fā)維護(hù)期運(yùn)行狀態(tài)集成和測(cè)試階段編碼階段OODOOA需求階段304.2基于構(gòu)件的軟件開發(fā)(CBD)思想：參照硬件標(biāo)準(zhǔn)零部件生產(chǎn)、組裝依據(jù)：應(yīng)用軟件系統(tǒng)的開發(fā)經(jīng)歷需求～維護(hù)， 若每天系統(tǒng)均從頭開發(fā)，則必然存在大量重復(fù)工作－－構(gòu)件？復(fù)用？軟件復(fù)用：將已有的軟件成分用于構(gòu)造新系統(tǒng) ——“開發(fā)伴隨復(fù)用，開發(fā)為了復(fù)用”構(gòu)件：可以復(fù)用，相對(duì)獨(dú)立的部件需求規(guī)格說明設(shè)計(jì)文檔測(cè)試計(jì)劃和用例源代碼…CBD：利用預(yù)先封裝好的軟件來構(gòu)造應(yīng)用Component－BasedDevelopment31螺旋模型＋構(gòu)件用戶通信計(jì)劃產(chǎn)品開發(fā)及發(fā)布用戶評(píng)估風(fēng)險(xiǎn)分析標(biāo)志候選構(gòu)件查找構(gòu)件若存在則提取構(gòu)件若不存在則構(gòu)造構(gòu)件進(jìn)行下一次迭代將新構(gòu)件存入庫中目錄32作業(yè)一、基本知識(shí)點(diǎn)1.什么是軟件生存周期？2.傳統(tǒng)的瀑布模型把生存周期劃分為那些階段，各階段產(chǎn)生的文檔是什么？瀑布模型有哪些特點(diǎn)？4.什么是快速原型法？分類？請(qǐng)說明并加以比較?5.比較增量模型和螺旋模型的特點(diǎn)，各有什么不同和相似的地方?6.你對(duì)構(gòu)件模型的理解7.比較傳統(tǒng)的瀑布模型和噴泉模型33作業(yè)(續(xù))二、1.假設(shè)開發(fā)一個(gè)軟件,把讀入的浮點(diǎn)數(shù)開平方,得到的結(jié)果應(yīng)該精確到小數(shù)點(diǎn)后4位,這個(gè)產(chǎn)品實(shí)現(xiàn)并測(cè)試后,并被拋棄.問打算用什么生命周期模型?并說明理由.2.若你是新上任的項(xiàng)目負(fù)責(zé)人,工作是管理該公司已被廣泛使用的字處理軟件的新版本.公司規(guī)定了完成期限,并且已經(jīng)對(duì)外公布,你打算采用那種生命周期模型,為什么?3.如果讓你做一個(gè)圖書管理信息系統(tǒng)（教材管理信息系統(tǒng)、網(wǎng)上書店），那么你會(huì)采取什么模型34補(bǔ)充課外閱讀XP和RUPXPExtremeProgramming1.2RUP的6個(gè)最佳實(shí)踐(BestPractices)1迭代開發(fā)

DevelopIteratively2需求管理 ManageRequirements3基于構(gòu)件的架構(gòu) UseComponentArchitectures4可視化建模 ModelVisually(UML)5持續(xù)的質(zhì)量驗(yàn)證

ContinuouslyVerifyQuality6變更管理 ManageChange目錄1.2RUP的生命期縱向?yàn)楹诵墓ぷ髁鳎?組工作流）橫向?yàn)闀r(shí)間軸，劃分了4個(gè)階段核心工作流時(shí)間核心過程工作流配置工作流初始階段精化構(gòu)建交付1個(gè)迭代，貫穿工作流每個(gè)階段又細(xì)化為若干迭代一個(gè)活動(dòng)在每次迭代中都有2.1XP(ExtremeProgramming)敏捷方法的代表XP——《ExtremeProgrammingExplained–EmbraceChange》KentBeck，1997年2.2XP的12個(gè)核心實(shí)踐1現(xiàn)場(chǎng)客戶 (On-sitecustomer)2簡(jiǎn)單設(shè)計(jì)(Simpledesign)3配對(duì)編程

(pairprogramming)4編碼標(biāo)準(zhǔn)(Codingstandards)5測(cè)試驅(qū)動(dòng)(Test-driven)重構(gòu)

（Refactoring）67持續(xù)集成Continuousintegration8小發(fā)行版Smallreleases集體代碼所有權(quán)(Collectiveownership)910一周40小時(shí)(40-hourweek)重新調(diào)整計(jì)劃(Planninggame)1