軟件過程模型與軟件項(xiàng)目組織

軟件過程模型(móxíng)與軟件項(xiàng)目組織軟件生存周期軟件過程模型編碼修正(xiūzhèng)模型瀑布模型原型實(shí)現(xiàn)模型演化過程模型基于構(gòu)件的開發(fā)模型形式化開發(fā)過程模型與項(xiàng)目組織共七十一頁軟件生存(shēngcún)周期軟件生存周期是軟件產(chǎn)品或系統(tǒng)從形成概念開始，經(jīng)過研制，交付使用，在使用中不斷增補(bǔ)修訂，直到最后被淘汰，讓位于新的軟件產(chǎn)品的全過程。對軟件生存周期的不同劃分，形成了不同的軟件開發(fā)模型(móxíng)。軟件生存周期的主要階段制定計(jì)劃(Planning)需求分析和定義(RequirementAnalysisandDefinition)軟件設(shè)計(jì)(SoftwareDesign)程序編寫(Coding,Programming)軟件測試(Testing)運(yùn)行/維護(hù)(Running/Maintenance)共七十一頁a“quality”focusprocessmodelmethodstools過程規(guī)定方法(fāngfǎ)使用的順序；要求交付的文檔資料；為保證質(zhì)量和適應(yīng)變化所需要的管理；軟件開發(fā)各個(gè)階段完成的里程碑。方法提供了“如何(rúhé)做”的技術(shù)。工具為軟件工程方法提供了自動的或半自動的軟件支撐環(huán)境，CASE軟件工程層次圖共七十一頁軟件(ruǎnjiàn)過程過程過程是為實(shí)現(xiàn)一個(gè)給定目標(biāo)而進(jìn)行的一系列運(yùn)作步驟。過程具有一系列的性質(zhì)(xìngzhì)：時(shí)間性、并發(fā)性、嵌套性和度量性等。軟件過程軟件過程是開發(fā)和維護(hù)軟件及其相關(guān)產(chǎn)品所涉及的一系列活動。過程是活動的集合；活動是任務(wù)的集合；任務(wù)是把輸入轉(zhuǎn)換為輸出的操作。共七十一頁軟件(ruǎnjiàn)過程軟件過程(guòchéng)是80年代后軟件工程關(guān)注的焦點(diǎn)。軟件過程是開發(fā)高質(zhì)量軟件所需要完成的任務(wù)的一個(gè)框架。軟件工程是由軟件人員在定義好的、成熟的軟件過程框架中進(jìn)行的。共七十一頁軟件(ruǎnjiàn)過程框架軟件過程提供了一個(gè)公共過程框架；選擇一個(gè)公共過程框架的依據(jù)是產(chǎn)品、人員和項(xiàng)目；在公共過程框架下可以建立一個(gè)軟件開發(fā)的綜合計(jì)劃：若干框架活動適用于所有軟件項(xiàng)目，而不在乎其規(guī)模(guīmó)和復(fù)雜性。若干不同任務(wù)的集合使得框架活動適應(yīng)于不同軟件項(xiàng)目的特征和項(xiàng)目組的需求。每一個(gè)任務(wù)集合都由任務(wù)、里程碑、交付物以及質(zhì)量保證點(diǎn)組成。若干庇護(hù)性活動如軟件質(zhì)量保證、軟件配置管理、測試與度量等，貫穿于整個(gè)過程模型之中。庇護(hù)性活動獨(dú)立于任何一個(gè)框架活動，且貫穿于整個(gè)過程之中。共七十一頁公共過程框架Commonprocessframework庇護(hù)性活動UmbrellaActivities

Projecttracking&controlFormaltechnicalreviewsQualityassuranceConfigurationmanagementDocumentationReusabilitymanagementMeasurementRiskmanagement框架活動FrameworkActivities任務(wù)集合(jíhé)worktasks工作任務(wù)workproducts交付物milestones&deliverables質(zhì)量保證點(diǎn)QAcheckpoints共七十一頁軟件(ruǎnjiàn)過程分類軟件過程可分為三大類：基本過程類：是構(gòu)成軟件生存周期主要部分的過程，包括獲取、開發(fā)、實(shí)施、維護(hù)等過程。支持過程類：可穿插到基本過程中提供支持的一系列過程，包括配置管理、質(zhì)量保證、驗(yàn)證、確認(rèn)、評審等過程。組織過程類：一個(gè)(yīɡè)組織用來建立、實(shí)施一種基礎(chǔ)結(jié)構(gòu)、并不斷改進(jìn)該基礎(chǔ)結(jié)構(gòu)的過程，包括管理、改進(jìn)、培訓(xùn)等過程。共七十一頁軟件(ruǎnjiàn)過程模型軟件(ruǎnjiàn)過程模型是軟件(ruǎnjiàn)過程的抽象表示。一個(gè)軟件過程模型是軟件開發(fā)全部過程、活動和任務(wù)的結(jié)構(gòu)框架。它能直觀表達(dá)軟件開發(fā)全過程，明確規(guī)定要完成的主要活動、任務(wù)和開發(fā)策略。軟件過程模型也常稱為軟件開發(fā)模型。共七十一頁軟件過程(guòchéng)模型過程模型定義了：特定問題和應(yīng)用的開發(fā)過程中將遵循的步驟(bùzhòu)；確定將用于表示問題和解的那些成分的類型；利用這些成分表示與問題解決有關(guān)的抽象；直接得到問題的結(jié)構(gòu)。過程模型的選擇影響到設(shè)計(jì)方法、編碼語言和測試和維護(hù)技術(shù)的選擇。共七十一頁軟件過程(guòchéng)模型編碼修正模型（CodeandFixModel）瀑布模型（WaterfallModel）快速原型法（Rapidapplicationdevelopment）增量開發(fā)(kāifā)模型（TheIncrementalModel）螺旋模型（TheSpiralModel）構(gòu)件開發(fā)模型（Component-BasedDevelopment）形式化開發(fā)模型（TheFormalMethodsModel）第四代開發(fā)技術(shù)（FourthGenerationTechniques）共七十一頁編碼修正(xiūzhèng)模型從一個(gè)大致的想法開始工作，然后(ránhòu)經(jīng)過非正規(guī)的設(shè)計(jì)、編碼和測試，最后完成全部工作?？赡苡谢蚩赡軟]有規(guī)格發(fā)布（可能）共七十一頁編碼修正(xiūzhèng)模型好處：成本可能很低。只需要很少的專業(yè)知識，任何寫過程序的人都可以。適用于一些非常小的、開發(fā)完后就會很快丟棄(diūqì)的軟件。缺點(diǎn)：對于規(guī)模稍大的項(xiàng)目，采用這種模型使項(xiàng)目難以控制。共七十一頁瀑布(pùbù)模型共七十一頁瀑布(pùbù)模型所有過程模型的鼻祖。----Royce,1970基本思想是把軟件開發(fā)過程劃分成若干階段，各個(gè)階段相當(dāng)于瀑布中的一個(gè)臺階，把軟件過程比喻成瀑布中的流水，暖流，在這些臺階中由上向下奔流。瀑布模型每個(gè)階段的任務(wù)相對獨(dú)立，便于不同人員分工協(xié)作，從而降低了整個(gè)軟件開發(fā)工程的困難程度(chéngdù)。在軟件的生存期的每個(gè)階段都采用科學(xué)的管理技術(shù)和良好的方法與技術(shù)，而且每個(gè)階段結(jié)束之前，都從技術(shù)和管理兩個(gè)角度進(jìn)行嚴(yán)格的審查，經(jīng)確認(rèn)之后才開始下一階段工作。瀑布模型適合于結(jié)構(gòu)化開發(fā)方法。共七十一頁結(jié)構(gòu)化分析過程(guòchéng)共七十一頁問題(wèntí)定義和可行性研究確定要開發(fā)軟件系統(tǒng)的總目標(biāo)。給出功能、性能、接口等方面的要求，完成該軟件任務(wù)的可行性研究。估計(jì)可利用的資源(計(jì)算機(jī)硬件，軟件(ruǎnjiàn)，人力等)、成本、效益、開發(fā)進(jìn)度。制定出完成開發(fā)任務(wù)的實(shí)施計(jì)劃,連同可行性研究報(bào)告，提交項(xiàng)目管理部門審查。共七十一頁需求(xūqiú)分析對待(duìdài)開發(fā)軟件提出的需求進(jìn)行分析并給出詳細(xì)的定義。編寫軟件需求說明書或系統(tǒng)功能說明書及初步的系統(tǒng)用戶手冊。提交管理機(jī)構(gòu)評審。共七十一頁軟件設(shè)計(jì)總體設(shè)計(jì)——“如何解決問題”可以列出多種解決方案進(jìn)行比較把各項(xiàng)需求轉(zhuǎn)換成軟件的體系結(jié)構(gòu)。結(jié)構(gòu)中每一組成部分都是意義明確的模塊，每個(gè)模塊都和某些需求相對應(yīng)詳細(xì)(xiángxì)設(shè)計(jì)—對每個(gè)模塊要完成的工作進(jìn)行具體的描述，為源程序編寫打下基礎(chǔ)編寫設(shè)計(jì)說明書，提交評審。共七十一頁程序(chéngxù)編寫把軟件設(shè)計(jì)轉(zhuǎn)換成計(jì)算機(jī)可以接受的程序代碼，即寫成以某一種特定(tèdìng)程序設(shè)計(jì)語言表示的“源程序清單”。寫出的程序應(yīng)當(dāng)是結(jié)構(gòu)良好、清晰易讀的，且與設(shè)計(jì)相一致的。共七十一頁軟件測試單元測試：查找各模塊在功能和結(jié)構(gòu)上存在的問題并加以糾正(jiūzhèng)。組裝測試：將已測試過的模塊按一定順序組裝起來。按規(guī)定的各項(xiàng)需求，逐項(xiàng)進(jìn)行有效性測試，決定已開發(fā)的軟件是否合格，能否交付用戶使用。共七十一頁運(yùn)行(yùnxíng)維護(hù)改正性維護(hù)：運(yùn)行中發(fā)現(xiàn)了軟件中的錯(cuò)誤需要修正。適應(yīng)性維護(hù)：為了適應(yīng)變化了的軟件工作環(huán)境，需做適當(dāng)變更。完善性維護(hù)：為了增強(qiáng)(zēngqiáng)軟件的功能需做變更。共七十一頁瀑布模型(móxíng)的特點(diǎn)里程碑或基線驅(qū)動，或者說是文檔驅(qū)動。每個(gè)階段必須完成規(guī)定的文檔；每個(gè)階段結(jié)束前完成文檔審查,及早改正錯(cuò)誤。是一種嚴(yán)格線性的、按階段順序的、逐步細(xì)化的過程模型（開發(fā)模式），階段間具有順序性和依賴性。過程逆轉(zhuǎn)性很差或者說不可逆轉(zhuǎn)，因?yàn)樯狭鞯腻e(cuò)誤會在下流進(jìn)行發(fā)散性傳播，逆轉(zhuǎn)會延誤工期(gōngqī)，增加成本。共七十一頁選擇瀑布模型(móxíng)的條件開發(fā)時(shí)間內(nèi)需求沒有(méiyǒu)或很少變化。分析設(shè)計(jì)人員對應(yīng)用很熟悉。低風(fēng)險(xiǎn)項(xiàng)目，對目標(biāo)和環(huán)境很熟悉。用戶使用環(huán)境很穩(wěn)定。共七十一頁瀑布模型的適用(shìyòng)場合當(dāng)有一個(gè)穩(wěn)定的產(chǎn)品定義和很容易被理解的技術(shù)解決方案時(shí)，可以采用純瀑布(pùbù)模型。當(dāng)你對一個(gè)定義得很好的版本進(jìn)行維護(hù)或?qū)⒁粋€(gè)產(chǎn)品移植到一個(gè)新的平臺上，可以采用瀑布模型。在質(zhì)量需求高于成本需求和進(jìn)度需求的時(shí)候，可以采用瀑布模型。共七十一頁瀑布(pùbù)模型的缺陷在項(xiàng)目開始的時(shí)候，用戶常常難以清楚地給出所有需求；用戶與開發(fā)人員對需求理解存在差異。很少軟件項(xiàng)目按照順序模型進(jìn)行，不能很好地支持迭代。缺乏靈活性，因?yàn)槠俨寄Ｐ痛_定了需求分析的絕對重要性，但是在實(shí)踐中要想獲得完善的需求說明是非常(fēicháng)困難的，導(dǎo)致“阻塞狀態(tài)”。反饋信息慢，開發(fā)周期長。只有到了整個(gè)項(xiàng)目的后半段時(shí)間，客戶才能看到軟件的模樣。一個(gè)沒有及時(shí)發(fā)現(xiàn)的錯(cuò)誤，可能導(dǎo)致災(zāi)難。雖然存在不少缺陷，瀑布模型經(jīng)常被嘲笑為“舊式的”，但是在需求被很好地理解的情況下，仍然是一種合理的方法。共七十一頁瀑布(pùbù)模型變種：V型模型該方法(fāngfǎ)是對瀑布模型的修正，強(qiáng)調(diào)了驗(yàn)證活動共七十一頁瀑布(pùbù)模型變種：生魚片模型把階段重疊起來的瀑布模型起源于日本硬件(yìnɡjiàn)開發(fā)模型（富士通—施樂）可行性研究需求分析總體設(shè)計(jì)詳細(xì)設(shè)計(jì)編碼和調(diào)試系統(tǒng)測試共七十一頁瀑布(pùbù)模型變種：生魚片模型傳統(tǒng)的瀑布模型強(qiáng)調(diào)階段之間最小的重疊，而生魚片模型強(qiáng)調(diào)大幅度的重疊，即在需求分析(fēnxī)完成之前就可以進(jìn)行架構(gòu)設(shè)計(jì)和部分詳細(xì)設(shè)計(jì)。純瀑布模型強(qiáng)調(diào)在任意兩個(gè)階段交接時(shí)，文檔從一個(gè)團(tuán)隊(duì)交給另一個(gè)完全隔離的團(tuán)隊(duì)，但是如果一個(gè)團(tuán)隊(duì)完成各個(gè)階段任務(wù)時(shí)，可以沒有那么多文檔。問題：缺點(diǎn)是什么？生魚片模型因?yàn)殡A段重疊，因而里程碑不明確，很難有效地進(jìn)行過程跟蹤和控制。共七十一頁瀑布模型變種(biànzhǒng)：具有子項(xiàng)目的瀑布模型純瀑布模型的一個(gè)問題是必須完成全部的總體設(shè)計(jì)后才能進(jìn)行詳細(xì)(xiángxì)設(shè)計(jì)，但是，整個(gè)系統(tǒng)中有些部分可能有些特殊性，可以有自己的步驟，即將這些部分劃分為為子項(xiàng)目。問題：該模型有何問題？這種方法的主要風(fēng)險(xiǎn)是相關(guān)性無法預(yù)料。共七十一頁瀑布模型變種：能夠(nénggòu)降低風(fēng)險(xiǎn)的瀑布模型純瀑布模型(móxíng)要求在開始總體設(shè)計(jì)前，必須將用戶的所有需求都搞清楚，但是實(shí)際中是很困難的?？山档惋L(fēng)險(xiǎn)的瀑布模型是在頂端，即需求分析和總體設(shè)計(jì)階段引入螺旋以便降低風(fēng)險(xiǎn)。在該螺旋中，先開發(fā)一個(gè)用戶界面原型，采用系統(tǒng)情節(jié)串聯(lián)圖版（systemstoryboarding）引導(dǎo)用戶提出需求，記錄用戶與系統(tǒng)的交互操作方式，或者采用其它需求獲取方法。共七十一頁聽取用戶意見建造/修改原型用戶測試運(yùn)行原型原型(yuánxíng)模型PrototypeModel共七十一頁建立(jiànlì)原型目標(biāo)開發(fā)(kāifā)原型定義原型功能評估原型原型開發(fā)過程原型規(guī)劃框架定義可執(zhí)行原型評估報(bào)告共七十一頁原型(yuánxíng)模型分類原型是項(xiàng)目系統(tǒng)中的一個(gè)方面或者多個(gè)方面的工作模型。拋棄型原型：用于試驗(yàn)?zāi)承└拍?，試?yàn)完系統(tǒng)將無用處進(jìn)化型原型：原型系統(tǒng)不斷被開發(fā)(kāifā)和被修正，最終它變?yōu)橐粋€(gè)真正的系統(tǒng)。共七十一頁原型模型(móxíng)的基本思想有一個(gè)原型，描述了系統(tǒng)的主要功能(gōngnéng)。通過人機(jī)交互，讓雙方了解目標(biāo)系統(tǒng)的操作。有一個(gè)可運(yùn)行的子集，用戶可以評價(jià)需求和設(shè)計(jì)。利用線性系統(tǒng)，不斷演化形成最終系統(tǒng)。降低了成本，及早發(fā)現(xiàn)錯(cuò)誤、修改量小、開發(fā)周期短。共七十一頁原型模型(móxíng)的特點(diǎn)原型驅(qū)動。優(yōu)點(diǎn)：從實(shí)踐中學(xué)習(xí)改善溝通和用戶(yònghù)參與使部分已知需求清晰化展示描述的一致性和完整性提高系統(tǒng)的實(shí)用性、可維護(hù)性共七十一頁選擇原型(yuánxíng)模型的條件適用于用戶驅(qū)動(qūdònɡ)的系統(tǒng)，即需求模糊或隨時(shí)間變化的系統(tǒng)。已有產(chǎn)品或產(chǎn)品的原型，只需客戶化的工程項(xiàng)目簡單而熟悉的行業(yè)或領(lǐng)域有快速原型開發(fā)工具進(jìn)行產(chǎn)品移植或升級共七十一頁原型模型(móxíng)的缺點(diǎn)用戶有時(shí)誤解了原型的角色，例如他們可能誤解原型應(yīng)該和真實(shí)系統(tǒng)一樣可靠。缺少項(xiàng)目(xiàngmù)標(biāo)準(zhǔn)，進(jìn)化原型方法有點(diǎn)像編碼修正。缺少控制，由于用戶可能不斷提出新要求，因而原型迭代的周期很難控制。額外的花費(fèi)：研究結(jié)果表明構(gòu)造一個(gè)原型可能需要10%額外花費(fèi)。原型法要求開發(fā)者與用戶密切接觸，有時(shí)這是不可能的。例如外包軟件。共七十一頁原型(yuánxíng)模型的缺點(diǎn)雖然有問題存在，但是原型仍是軟件開發(fā)的一個(gè)有效范型。關(guān)鍵是定義(dìngyì)開始的游戲規(guī)則，即用戶與開發(fā)者兩方面必須達(dá)成一致：原型被建造僅是為了定義(dìngyì)需求，之后被拋棄（或至少部分被拋棄），實(shí)際的軟件在充分考慮了質(zhì)量和可維護(hù)行之后才被開發(fā)。共七十一頁演化軟件(ruǎnjiàn)過程模型人們已經(jīng)越來越認(rèn)識到軟件就象所有復(fù)雜系統(tǒng)一樣要經(jīng)過一段時(shí)間的演化。業(yè)務(wù)和產(chǎn)品需求隨著開發(fā)的發(fā)展常常發(fā)生改變，想找到最終(zuìzhōnɡ)產(chǎn)品的一條直線路徑是不可能的。緊迫的市場期限使得難以完成一個(gè)完善的軟件產(chǎn)品，但可以先提交一個(gè)有限的版本以對付競爭或商業(yè)的壓力；只要核心產(chǎn)品或系統(tǒng)需求能夠很好地理解，而產(chǎn)品或系統(tǒng)的細(xì)節(jié)部分可以進(jìn)一步定義。共七十一頁演化軟件過程(guòchéng)模型演化(yǎnhuà)模型是利用一種迭代的思想方法，它的特征是使軟件工程師漸進(jìn)地開發(fā),逐步完善軟件版本。增量模型(IncrementalModel)螺旋模型(SpiralModel)迭代模型（IterativeModel）共七十一頁calendartimeanalysisdesigncodetestSystem/informationengineeringincrement1deliveryof1stincrementCoreproductanalysisdesigncodetestincrement2deliveryof2ndincrementMorefeaturesandfunctionalityanalysisdesigncodetestanalysisdesigncodetestincrement3increment4deliveryof3rdincrementdeliveryof4thincrement

Makesabetteruseofresources.增量(zēnɡliànɡ)模型（IncrementalModel）共七十一頁增量模型(móxíng)的特點(diǎn)任務(wù)或功能模塊驅(qū)動，以功能遞增的方式進(jìn)行軟件開發(fā)，可以分階段提交產(chǎn)品；融合了線性順序模型(móxíng)的基本成分和原型實(shí)現(xiàn)的迭代特征；能較快地產(chǎn)生可操作的系統(tǒng)；在每一步遞增中，均發(fā)布一個(gè)新的增量，把用戶/開發(fā)者的經(jīng)驗(yàn)結(jié)合到不斷求精的產(chǎn)品中；每個(gè)增量的開發(fā)沒有必要使用相同的過程；可改善測試效果和降低軟件開發(fā)總成本。共七十一頁增量(zēnɡliànɡ)模型的特點(diǎn)增量(zēnɡliànɡ)過程模型與原型實(shí)現(xiàn)模型，本質(zhì)上都是迭代的。兩者區(qū)別在：增量模型強(qiáng)調(diào)每一個(gè)增量發(fā)布一個(gè)可操作的產(chǎn)品。早期的增量提供了為用戶服務(wù)的功能和給用戶評價(jià)的平臺。共七十一頁選擇增量(zēnɡliànɡ)模型的條件客戶接受分階段交付。對應(yīng)用領(lǐng)域不熟悉，難以一步到位。用戶(yònghù)可參與到整個(gè)軟件開發(fā)過程中。有較好的類庫和構(gòu)件庫。共七十一頁增量模型存在(cúnzài)的問題增量應(yīng)該相對較小，每個(gè)增量應(yīng)該包含一定的系統(tǒng)功能。所以，很難把用戶的需求映射到適當(dāng)規(guī)模的增量上。大多數(shù)系統(tǒng)需要一組在系統(tǒng)許多部分都會用到的基本服務(wù)。但由于增量實(shí)現(xiàn)前，需求不能被詳細(xì)定義，所以，明確所有增量都會用到的基本服務(wù)就比較困難。若軟件系統(tǒng)的組裝和拆卸(chāixiè)性不強(qiáng)，或開發(fā)人員全局把握能力不高，或客戶不同意分階段提交產(chǎn)品等，均不合適。共七十一頁螺旋(luóxuán)模型（SpiralModel）Spiral模型（Boehm，1988提出）綜合了原型模型的迭代特征和瀑布模型的控制和系統(tǒng)化的優(yōu)點(diǎn)。增加了風(fēng)險(xiǎn)分析，是以風(fēng)險(xiǎn)為導(dǎo)向(dǎoxiànɡ)的生命期模型。從一個(gè)小范圍的關(guān)鍵中心地帶開始尋找風(fēng)險(xiǎn)因素，制定風(fēng)險(xiǎn)控制計(jì)劃，并交付給下一步驟，如此迭代，每次迭代將項(xiàng)目擴(kuò)展到一個(gè)更大的規(guī)模。共七十一頁評審提交劃分風(fēng)險(xiǎn)分析原型1仿真、模型、基準(zhǔn)需求計(jì)劃，生存期計(jì)劃操作概念原型2風(fēng)險(xiǎn)分析軟件需求需求確認(rèn)開發(fā)計(jì)劃風(fēng)險(xiǎn)分析原型3軟件產(chǎn)品設(shè)計(jì)設(shè)計(jì)確認(rèn)與驗(yàn)證集成與測試計(jì)劃風(fēng)險(xiǎn)分析可運(yùn)行原型詳細(xì)設(shè)計(jì)單元測試編碼集成與測試驗(yàn)收測試實(shí)現(xiàn)計(jì)劃下一階段開發(fā)、驗(yàn)證下一代產(chǎn)品確定目標(biāo)、方案和限定評估方案，識別、消除風(fēng)險(xiǎn)累積成本按步驟推進(jìn)共七十一頁螺旋(luóxuán)模型的特點(diǎn)螺旋模型沿著螺線旋轉(zhuǎn)，在四個(gè)象限上分別表達(dá)了四個(gè)方面的活動(huódòng)。制定計(jì)劃——確定軟件目標(biāo)，選定實(shí)施方案，弄清項(xiàng)目開發(fā)的約束條件。風(fēng)險(xiǎn)分析——分析所選方案，考慮如何識別和消除風(fēng)險(xiǎn)。實(shí)施工程——實(shí)施軟件開發(fā)。客戶評估——評價(jià)開發(fā)工作，提出修正建議。共七十一頁螺旋(luóxuán)模型的特點(diǎn)把軟件開發(fā)過程組成為一個(gè)逐步細(xì)化的定義周期（螺旋周期）序列，每經(jīng)歷一個(gè)周期，系統(tǒng)就得到進(jìn)一步的細(xì)化和完善；本質(zhì)上，具有上述特征(tèzhēng)的螺旋是一直運(yùn)轉(zhuǎn)的,直到軟件退役。有時(shí)這個(gè)過程處于睡眠狀態(tài)，但任何時(shí)候出現(xiàn)了改變，過程都會從合適的入口點(diǎn)開始；緊密圍繞開發(fā)中的風(fēng)險(xiǎn)問題，用風(fēng)險(xiǎn)分析推動軟件設(shè)計(jì)向深一層擴(kuò)展、求精；強(qiáng)調(diào)持續(xù)地判斷、確定和修改用戶任務(wù)目標(biāo)，并按成本、效益來分析候選的軟件產(chǎn)品性質(zhì)對任務(wù)目標(biāo)的貢獻(xiàn)；可結(jié)合采用多種軟件開發(fā)方法，但究竟結(jié)合哪一種方法仍由風(fēng)險(xiǎn)分析來決定。共七十一頁螺旋(luóxuán)模型對于大型軟件系統(tǒng)的開發(fā)，螺旋模型是一個(gè)很現(xiàn)實(shí)(xiànshí)的方法。優(yōu)勢：隨著迭代的增加（成本的增加），風(fēng)險(xiǎn)程度隨之降低缺陷：比較復(fù)雜，需要相當(dāng)?shù)娘L(fēng)險(xiǎn)評估技術(shù)，且成功依賴于這種技術(shù)。共七十一頁基于(jīyú)構(gòu)件的開發(fā)面向?qū)ο蠹夹g(shù)為軟件工程的基于構(gòu)件的模型提供了技術(shù)框架。面向?qū)ο竽Ｐ椭袕?qiáng)調(diào)類的創(chuàng)建，類封裝了數(shù)據(jù)(shùjù)和用于操作該數(shù)據(jù)(shùjù)的方法。通過合適的設(shè)計(jì)和實(shí)現(xiàn)，類可以在系統(tǒng)中復(fù)用。共七十一頁基于(jīyú)構(gòu)件的軟件開發(fā)－－CBSDCBSD的興起主要是源于如下四個(gè)不同的背景：研究方面：現(xiàn)代軟件工程思想，特別(tèbié)是對復(fù)用技術(shù)的強(qiáng)調(diào)。產(chǎn)業(yè)方面：支持用構(gòu)件建造GUI、數(shù)據(jù)庫和應(yīng)用的其他部件的一些理論上質(zhì)樸但實(shí)際可用的技術(shù)的成功。政治方面：某些主流互操作技術(shù)，如CORBA、COM和EJB的開發(fā)者的推動。在軟件界：面向?qū)ο蠹夹g(shù)的廣泛使用，提供了建造和使用構(gòu)件的概念基礎(chǔ)和實(shí)用工具。共七十一頁基于(jīyú)構(gòu)件的軟件開發(fā)－－CBSDCBSD提供了一種自底向上的、基于預(yù)先定制包裝好的軟件構(gòu)件(gòujiàn)來構(gòu)造應(yīng)用系統(tǒng)的途徑，當(dāng)前討論的重點(diǎn)主要局限于基于COM、CORBA和EJB等的二進(jìn)制構(gòu)件(gòujiàn)。但是，沒有理由僅僅從這個(gè)局限的角度來看待構(gòu)件(gòujiàn)，也不應(yīng)該僅僅是局限于此，應(yīng)該涉及整個(gè)軟件生存周期。共七十一頁基于(jīyú)構(gòu)件的軟件開發(fā)共七十一頁基于構(gòu)件的軟件工程(ruǎnjiànɡōnɡchénɡ)(CBSE)過程模型構(gòu)件開發(fā)分析(fēnxī)設(shè)計(jì)編程測試領(lǐng)域分析系統(tǒng)測試構(gòu)件提交領(lǐng)域?qū)＜医?jīng)驗(yàn)現(xiàn)有系統(tǒng)資料領(lǐng)域構(gòu)件需求構(gòu)件/構(gòu)架庫領(lǐng)域構(gòu)架領(lǐng)域構(gòu)件系統(tǒng)開發(fā)系統(tǒng)專用構(gòu)件應(yīng)用系統(tǒng)構(gòu)件生產(chǎn)線領(lǐng)域構(gòu)架領(lǐng)域構(gòu)件問題域用戶需求系統(tǒng)生產(chǎn)線系統(tǒng)組裝分析設(shè)計(jì)編程構(gòu)架細(xì)化專

用

構(gòu)件

開

發(fā)分析設(shè)計(jì)編程測試共七十一頁4GT4GT包含一系列的軟件工具(gōngjù)，其共同點(diǎn)：能使軟件開發(fā)人員在高層次上規(guī)約軟件的某些特性，然后，工具(gōngjù)根據(jù)開發(fā)者的規(guī)約自動生成源代碼。共七十一頁4GT模型(móxíng)需求(xūqiú)分析設(shè)計(jì)策略用4GL實(shí)現(xiàn)測試共七十一頁4GT模型(móxíng)支持者：減少開發(fā)，提高軟件的生產(chǎn)率。反對者：源代碼“低效”，系統(tǒng)可維護(hù)性令人懷疑。結(jié)論：4GT的使用對很多的領(lǐng)域而言是一種可行的途徑。對中小型應(yīng)用(yìngyòng)，可以提高生產(chǎn)率，降低分析和設(shè)計(jì)的工作量。共七十一頁形式化方法模型(móxíng)思想形式化方法的主要目的是要把軟件開發(fā)過程建立在嚴(yán)密可行的數(shù)學(xué)基礎(chǔ)之上，從而提高軟件質(zhì)量和軟件生產(chǎn)率。采用事后的或并行的輔助手段，對系統(tǒng)的性質(zhì)進(jìn)行嚴(yán)格的驗(yàn)證。集成到軟件開發(fā)過程中，希望在嚴(yán)格的形式系統(tǒng)的基礎(chǔ)上，實(shí)現(xiàn)從需求規(guī)約(guīyuē)到程序代碼的轉(zhuǎn)換和過渡。共七十一頁形式化規(guī)格(guīgé)說明與需求(xūqiú)比較后修正形式化開發(fā)記錄變換n變換2變換1測試系統(tǒng)需求目標(biāo)系統(tǒng)形式化方法模型共七十一頁形式化開發(fā)(kāifā)模型與瀑布模型的本質(zhì)區(qū)別：軟件需求描述被精練成一個(gè)數(shù)學(xué)符號表達(dá)(biǎodá)的詳細(xì)的形式化描述。設(shè)計(jì)、實(shí)現(xiàn)和測試等開發(fā)過程被一個(gè)轉(zhuǎn)換的開發(fā)過程代替，在這個(gè)轉(zhuǎn)換過程中，形式化描述經(jīng)過一系列轉(zhuǎn)換變成一個(gè)可執(zhí)行程序。共七十一頁形式化開發(fā)(kāifā)模型優(yōu)點(diǎn)：在軟件開發(fā)中，形式化方法提供了一種機(jī)制，能夠消除其它模型難以克