第2講軟件開發(fā)過程模型_第1頁
第2講軟件開發(fā)過程模型_第2頁
第2講軟件開發(fā)過程模型_第3頁
第2講軟件開發(fā)過程模型_第4頁
第2講軟件開發(fā)過程模型_第5頁
已閱讀5頁,還剩52頁未讀 繼續(xù)免費(fèi)閱讀

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請(qǐng)進(jìn)行舉報(bào)或認(rèn)領(lǐng)

文檔簡(jiǎn)介

第二講軟件開發(fā)過程模型

北京郵電大學(xué)計(jì)算機(jī)學(xué)院蘆效峰12軟件產(chǎn)品從提出開始,到該軟件產(chǎn)品被淘汰的全過程。

一個(gè)軟件從定義、開發(fā)、使用、維護(hù),直到最終被廢棄,要經(jīng)歷一個(gè)漫長(zhǎng)的時(shí)期,這就如同一個(gè)人要經(jīng)過胎兒、兒童、青年、中年、老年,直到最終死亡的漫長(zhǎng)時(shí)期一樣,通常把軟件經(jīng)歷的這個(gè)漫長(zhǎng)時(shí)期稱為生存周期。

1.軟件生存周期

軟件生存期lifecycle軟件生存期的六個(gè)步驟,即可行性研究、需求分析、設(shè)計(jì)、程序編碼、測(cè)試及運(yùn)行維護(hù)軟件工程學(xué)的一個(gè)重要目標(biāo)就是提高軟件的可維護(hù)性,減少軟件維護(hù)的代價(jià)。在軟件開發(fā)的不同階段進(jìn)行修改需要付出的代價(jià)很不相同:3軟件生存周期

4圖1-2軟件的生存周期軟件測(cè)試評(píng)價(jià)運(yùn)行編碼軟件設(shè)計(jì)需求分析可行性研究可行性研究確定要開發(fā)軟件系統(tǒng)的總目標(biāo)及可行性給出功能、性能、可靠性以及接口等方面的要求估計(jì)可利用的資源(硬件,軟件,人力等)、成本、效益、開發(fā)進(jìn)度制定出完成開發(fā)任務(wù)的實(shí)施計(jì)劃,連同可行性研究報(bào)告,提交管理部門審查5需求分析和定義對(duì)用戶提出的要求進(jìn)行分析并給出詳細(xì)的定義編寫軟件需求說明書或系統(tǒng)功能說明書及初步的系統(tǒng)用戶手冊(cè)提交管理機(jī)構(gòu)評(píng)審6軟件設(shè)計(jì)概要設(shè)計(jì)

—把各項(xiàng)需求轉(zhuǎn)換成軟件的體系結(jié)構(gòu)。結(jié)構(gòu)中每一組成部分都是意義明確的模塊,每個(gè)模塊都和某些需求相對(duì)應(yīng)詳細(xì)設(shè)計(jì)

—對(duì)每個(gè)模塊要完成的工作進(jìn)行具體的描述,為源程序編寫打下基礎(chǔ)編寫設(shè)計(jì)說明書,提交評(píng)審。7程序編寫把軟件設(shè)計(jì)轉(zhuǎn)換成計(jì)算機(jī)可以接受的程序代碼,即寫成以某一種特定程序設(shè)計(jì)語言表示的“源程序清單”寫出的程序應(yīng)當(dāng)是結(jié)構(gòu)良好、清晰易讀的,且與設(shè)計(jì)相一致的8軟件測(cè)試單元測(cè)試,查找各模塊內(nèi)部在功能和結(jié)構(gòu)上存在的問題并加以糾正組裝測(cè)試,將已測(cè)試過的模塊按一定順序組裝起來按規(guī)定的各項(xiàng)需求,逐項(xiàng)進(jìn)行有效性測(cè)試,決定已開發(fā)的軟件是否合格,能否交付用戶使用9運(yùn)行/維護(hù)改正性維護(hù)

運(yùn)行中發(fā)現(xiàn)了軟件中的錯(cuò)誤需要修正適應(yīng)性維護(hù)為了適應(yīng)變化了的軟件工作環(huán)境,需做適當(dāng)變更完善性維護(hù)為了增強(qiáng)軟件的功能需做變更1011階段關(guān)鍵問題結(jié)束標(biāo)準(zhǔn)問題定義問題是什么關(guān)于規(guī)模和目標(biāo)的報(bào)告書可行性研究有可行的解嗎系統(tǒng)高層邏輯模型:數(shù)據(jù)流圖,成本/效益分析需求分析系統(tǒng)必須做什么系統(tǒng)的邏輯模型:數(shù)據(jù)流圖,數(shù)據(jù)字典,算法描述總體設(shè)計(jì)概括的說,系統(tǒng)應(yīng)該如何解決這個(gè)問題可能的解法:系統(tǒng)流程圖,成本/效益分析,推薦的系統(tǒng)結(jié)構(gòu):層次圖或結(jié)構(gòu)圖12階段關(guān)鍵問題結(jié)束標(biāo)準(zhǔn)詳細(xì)設(shè)計(jì)怎樣具體地實(shí)現(xiàn)這個(gè)系統(tǒng)編寫規(guī)格說明:HIPO圖或PDL編碼和單元測(cè)試正確的程序模塊源程序清單,單元測(cè)試方案和結(jié)果綜合測(cè)試符合要求的軟件綜合測(cè)試方案和結(jié)果、完整一致的軟件配置維護(hù)持久地滿足用戶需要的軟件完整準(zhǔn)確的維護(hù)記錄2常用軟件開發(fā)過程模型2.1瀑布模型:將各項(xiàng)活動(dòng)規(guī)定為依固定順序連接的若干階段工作,從上到下,不可逆轉(zhuǎn)13軟件設(shè)計(jì)計(jì)劃階段開發(fā)階段維護(hù)階段可行性研究需求分析編碼軟件測(cè)試運(yùn)行、維護(hù)圖1-3瀑布模型上一項(xiàng)活動(dòng)產(chǎn)生的工作結(jié)果作為下一步輸入每一個(gè)工作結(jié)果進(jìn)行評(píng)審14瀑布模型特點(diǎn)按照傳統(tǒng)的瀑布模型來開發(fā)軟件,有以下特點(diǎn):1、階段間有順序性和依賴性;2、推遲實(shí)現(xiàn)的觀點(diǎn);3、質(zhì)量保證的觀點(diǎn);需求分析驗(yàn)證規(guī)格說明驗(yàn)證設(shè)計(jì)驗(yàn)證編碼測(cè)試綜合測(cè)試維護(hù)優(yōu)點(diǎn):可強(qiáng)迫開發(fā)人員采用規(guī)范的方法;嚴(yán)格規(guī)定了每個(gè)階段必須提交的文檔;要求每個(gè)階段交出的產(chǎn)品都必須經(jīng)過質(zhì)量保證小組的仔細(xì)驗(yàn)證。需求分析驗(yàn)證實(shí)線箭頭表示開發(fā)過程;虛線箭頭表示維護(hù)過程。反饋線開發(fā)過程維護(hù)過程瀑布模型缺點(diǎn)項(xiàng)目開始階段,開發(fā)人員和用戶對(duì)需求的描述常常不全面。如果需求階段沒發(fā)現(xiàn)問題,則影響后面各階段的工作各階段所做的工作都是文檔說明,一般用戶不易理解文字所敘述的軟件。用戶的修改意見加大了修改難度改變會(huì)影響整個(gè)軟件開發(fā)。事先選擇的技術(shù)或需求迅速發(fā)生變化,需要返回到前面,對(duì)前面一系列內(nèi)容進(jìn)行修改152.2快速原型模型由于在項(xiàng)目開發(fā)的初始階段人們對(duì)軟件的需求認(rèn)識(shí)常常不夠清晰,因而使得開發(fā)項(xiàng)目難于做到一次開發(fā)成功,出現(xiàn)返工再開發(fā)在所難免??焖僭湍P偷牡谝徊绞墙ㄔ煲粋€(gè)快速原型,實(shí)現(xiàn)客戶或未來的用戶與系統(tǒng)的交互,用戶或客戶對(duì)原型進(jìn)行評(píng)價(jià),進(jìn)一步細(xì)化待開發(fā)軟件的需求。通過逐步調(diào)整原型使其滿足客戶的要求,開發(fā)人員可以確定客戶的真正需求是什么;第二步則在第一步的基礎(chǔ)上開發(fā)客戶滿意的軟件產(chǎn)品。模型原理圖17原型快速分析運(yùn)行評(píng)價(jià)構(gòu)造執(zhí)行程序做兩次或多次第一次只是試驗(yàn)開發(fā),其目標(biāo)只是在于探索可行性,弄清軟件需求第二次則在此基礎(chǔ)上獲得較為滿意的軟件產(chǎn)品顯然,快速原型方法可以克服瀑布模型的缺點(diǎn),減少由于軟件需求不明確帶來的開發(fā)風(fēng)險(xiǎn),具有顯著的效果。18過程圖19快速分析需求說明構(gòu)造原型原型運(yùn)行原型評(píng)價(jià)原型修改意見修改類型修改原型停止修改修改說明需求分析需求說明設(shè)計(jì)設(shè)計(jì)說明編碼測(cè)試源程序清單軟件產(chǎn)品維護(hù)20

快速原型是快速建立起來的可以在計(jì)算機(jī)上運(yùn)行的程序,完成的功能是最終產(chǎn)品能完成功能的一個(gè)子集。

1.快速原型模型不帶反饋環(huán),軟件開發(fā)基本上是線形順序進(jìn)行的。2.原型系統(tǒng)已經(jīng)通過與用戶交互得到驗(yàn)證;3。

開發(fā)人員在建立原型中學(xué)到了許多東西;快速原型驗(yàn)證規(guī)格說明驗(yàn)證設(shè)計(jì)驗(yàn)證編碼測(cè)試綜合測(cè)試維護(hù)變化的需求驗(yàn)證實(shí)線箭頭表示開發(fā)過程;虛線箭頭表示維護(hù)過程。開發(fā)過程維護(hù)過程快速原型模型特點(diǎn)特點(diǎn)原型模型的最大特點(diǎn)是:利用原型法技術(shù)能夠快速實(shí)現(xiàn)系統(tǒng)的初步模型,供開發(fā)人員和用戶進(jìn)行交流,以便較準(zhǔn)確獲得用戶的需求,采用逐步求精方法使原型逐步完善,是一種在新的高層次上不斷反復(fù)推進(jìn)的過程。它可以大大避免在瀑布模型冗長(zhǎng)的開發(fā)過程中看不見產(chǎn)品雛形的現(xiàn)象。模型的關(guān)鍵快速原型的關(guān)鍵在于盡可能快速地建造出軟件原型,一旦確定了客戶的真正需求,所建造的原型將被丟棄。因此,原型系統(tǒng)的內(nèi)部結(jié)構(gòu)并不重要,重要的是必須迅速建立原型,隨之迅速修改原型,以反映客戶的需求。優(yōu)點(diǎn)克服瀑布模型的缺點(diǎn),減少由于軟件需求不明確帶來的開發(fā)風(fēng)險(xiǎn)。一是開發(fā)工具先進(jìn),開發(fā)效率高,使總的開發(fā)費(fèi)用降低,時(shí)間縮短;二是開發(fā)人員與用戶交流直觀,可以澄清模糊需求,調(diào)動(dòng)用戶的積極參與,能及早暴露系統(tǒng)實(shí)施后潛在的一些問題;三是原型系統(tǒng)可作為培訓(xùn)環(huán)境,有利于用戶培訓(xùn)和開發(fā)同步,開發(fā)過程也是學(xué)習(xí)過程。原型模型的缺陷

1)

建立原型模型的軟件工具與環(huán)境與實(shí)際模型的存在脫節(jié)的現(xiàn)象。

2)

以目前通用的開發(fā)工具,開發(fā)原型本身就不是件容易的事情。

3)

原型模型對(duì)用戶深層次的需求并不能深入分析。4)快速建立起來的系統(tǒng)結(jié)構(gòu)加上連續(xù)的修改可能會(huì)導(dǎo)致產(chǎn)品質(zhì)量低下;缺點(diǎn)產(chǎn)品原型在一定程度上限制了開發(fā)人員的創(chuàng)新,沒有考慮軟件的整體質(zhì)量和長(zhǎng)期的可維護(hù)性。由于達(dá)不到質(zhì)量要求產(chǎn)品可能被拋棄,而采用新的模型重新設(shè)計(jì),因此原型實(shí)現(xiàn)模型不適合嵌入式、實(shí)時(shí)控制及科學(xué)數(shù)值計(jì)算等大型軟件系統(tǒng)的開發(fā);261988年,Barry提出螺旋模型,將瀑布模型和快速原型結(jié)合,注重風(fēng)險(xiǎn)分析,適合于大型復(fù)雜系統(tǒng)。

軟件開發(fā)的風(fēng)險(xiǎn):1、產(chǎn)品交付用戶之后用戶可能不滿意;2、到交付日期后軟件可能還未開發(fā)出來;3、實(shí)際開發(fā)成本可能超過預(yù)算;4、一些關(guān)鍵的開發(fā)人員可能“跳槽”;5、聘請(qǐng)不到需要的專業(yè)人員;

基本思想:使用原型及其他方法來盡量降低風(fēng)險(xiǎn)??煽醋髟诿總€(gè)階段之前都增加了風(fēng)險(xiǎn)分析過程的快速原型模型。螺旋線每個(gè)周期對(duì)應(yīng)一個(gè)開發(fā)階段。2.3螺旋模型27快速原型驗(yàn)證規(guī)格說明驗(yàn)證設(shè)計(jì)驗(yàn)證編碼測(cè)試綜合測(cè)試維護(hù)變化的需求驗(yàn)證風(fēng)險(xiǎn)分析風(fēng)險(xiǎn)分析風(fēng)險(xiǎn)分析風(fēng)險(xiǎn)分析風(fēng)險(xiǎn)分析風(fēng)險(xiǎn)分析簡(jiǎn)化的螺旋模型

螺旋模型的基本思想:使用原型及其他方法來盡量降低風(fēng)險(xiǎn)。簡(jiǎn)化的螺旋模型可看作在每個(gè)階段都增加了風(fēng)險(xiǎn)分析過程的快速原型模型。

風(fēng)險(xiǎn)分析是對(duì)風(fēng)險(xiǎn)進(jìn)行識(shí)別,分析,采取對(duì)策,進(jìn)而消除或減少風(fēng)險(xiǎn)的損害。螺旋模型螺旋模型沿著螺線旋轉(zhuǎn),在四個(gè)象限上分別表達(dá)四個(gè)方面的活動(dòng),即:制定計(jì)劃──確定軟件目標(biāo),選定實(shí)施方案,弄清項(xiàng)目開發(fā)的限制風(fēng)險(xiǎn)分析──分析所選方案,考慮如何識(shí)別和消除風(fēng)險(xiǎn)實(shí)施工程──實(shí)施軟件開發(fā)客戶評(píng)估──評(píng)價(jià)開發(fā)工作,提出修正建議2829

每個(gè)階段開始時(shí)(左上象限)的任務(wù)是:確定該項(xiàng)目的目標(biāo)、為完成這些目標(biāo)選擇方案及設(shè)定這些方案的約束條件。接下來的任務(wù)是:從風(fēng)險(xiǎn)角度分析上步的工作結(jié)果,努力排除各種潛在的風(fēng)險(xiǎn),如果風(fēng)險(xiǎn)不能排除,則停止開發(fā)工作或大幅度削減項(xiàng)目規(guī)模。如果成功排除了所有風(fēng)險(xiǎn),則啟動(dòng)下一個(gè)開發(fā)步驟(右下象限),這個(gè)步驟相當(dāng)于純粹的瀑布模型。最后是評(píng)價(jià)該階段工作成果并計(jì)劃下一階段的工作。螺旋模型

沿著螺旋線每轉(zhuǎn)一圈,表示開發(fā)一個(gè)更完善的版本。

30“螺旋模型”的核心就在于您不需要在剛開始的時(shí)候就把所有事情都定義的清清楚楚。您輕松上陣,定義最重要的功能,實(shí)現(xiàn)它,然后聽取客戶的意見,之后再進(jìn)入到下一個(gè)階段。如此不斷輪回重復(fù),直到得到您滿意的最終產(chǎn)品。32優(yōu)點(diǎn):

1、對(duì)可選方案和約束條件的強(qiáng)調(diào)有利于已有軟件的重用,也有利于把軟件質(zhì)量作為軟件開發(fā)的一個(gè)重要目標(biāo);

2、減少了過多的測(cè)試或測(cè)試不足所帶來的風(fēng)險(xiǎn);

3、維護(hù)只是模型的另一個(gè)周期,在維護(hù)和開發(fā)之間沒有本質(zhì)的區(qū)別。螺旋模型的缺陷1)采用螺旋模型需要具有相當(dāng)豐富的風(fēng)險(xiǎn)評(píng)估經(jīng)驗(yàn)和專門知識(shí),在風(fēng)險(xiǎn)較大的項(xiàng)目開發(fā)中,如果未能夠及時(shí)標(biāo)識(shí)風(fēng)險(xiǎn),勢(shì)必造成重大損失。2)過多的迭代次數(shù)會(huì)增加開發(fā)成本,延遲提交時(shí)間。螺旋模型限制條件螺旋模型強(qiáng)調(diào)風(fēng)險(xiǎn)分析,但要求客戶接受這種風(fēng)險(xiǎn),并做出相關(guān)反映是不容易的。如果執(zhí)行風(fēng)險(xiǎn)分析會(huì)大大影響項(xiàng)目的利潤(rùn),那么風(fēng)險(xiǎn)分析就沒有意義了。只適合大規(guī)模軟件開發(fā)軟件開發(fā)人員應(yīng)該擅長(zhǎng)尋找可能的風(fēng)險(xiǎn),準(zhǔn)確地分析風(fēng)險(xiǎn),否則將會(huì)帶來更大的風(fēng)險(xiǎn)。342.4噴泉模型噴泉模型是一種以用戶需求為動(dòng)力,以對(duì)象為驅(qū)動(dòng)的模型,主要用于描述面向?qū)ο蟮能浖_發(fā)過程。該模型認(rèn)為軟件開發(fā)過程自下而上周期的各階段是相互重疊和多次反復(fù)的,就像水噴上去又可以落下來,類似一個(gè)噴泉。各個(gè)開發(fā)階段沒有特定的次序要求,并且可以交互進(jìn)行,可以在某個(gè)開發(fā)階段中隨時(shí)補(bǔ)充其他任何開發(fā)階段中的遺漏。36需求階段面向?qū)ο蠓治鲭A段面向?qū)ο笤O(shè)計(jì)階段編碼階段集成和測(cè)試階段運(yùn)行狀態(tài)進(jìn)一步開發(fā)維護(hù)期噴泉模型各個(gè)開發(fā)階段沒有特定的次序要求,可以隨時(shí)補(bǔ)充其他任何開發(fā)階段中的遺漏。噴泉模型主要用于面向?qū)ο蟮能浖?xiàng)目,軟件的某個(gè)部分通常被重復(fù)多次,相關(guān)對(duì)象在每次迭代中隨之加入漸進(jìn)的軟件成分。各活動(dòng)之間無明顯邊界,例如設(shè)計(jì)和實(shí)現(xiàn)之間沒有明顯的邊界,這也稱為“噴泉模型的無間隙性”。由于對(duì)象概念的引入,表達(dá)分析、設(shè)計(jì)及實(shí)現(xiàn)等活動(dòng)只用對(duì)象類和關(guān)系,從而可以較容易地實(shí)現(xiàn)活動(dòng)的迭代和無間隙。噴泉模型不像瀑布模型那樣,需要分析活動(dòng)結(jié)束后才開始設(shè)計(jì)活動(dòng),設(shè)計(jì)活動(dòng)結(jié)束后才開始編碼活動(dòng)。該模型的各個(gè)階段沒有明顯的界限,開發(fā)人員可以同步進(jìn)行開發(fā)。優(yōu)點(diǎn)優(yōu)點(diǎn)是可以提高軟件項(xiàng)目開發(fā)效率,節(jié)省開發(fā)時(shí)間,適應(yīng)于面向?qū)ο蟮能浖_發(fā)過程??梢詮娜魏我粋€(gè)開發(fā)階段(泡泡)轉(zhuǎn)到其它任一個(gè)開發(fā)階段,各個(gè)階段之間沒有明顯的界限。也就是,在整個(gè)過程中補(bǔ)漏、拾遺、糾錯(cuò)的切入點(diǎn)大大增多,不受開發(fā)階段的限制。缺點(diǎn)由于噴泉模型在各個(gè)開發(fā)階段是重疊的,因此在開發(fā)過程中需要大量的開發(fā)人員,因此不利于項(xiàng)目的管理。此外這種模型要求嚴(yán)格管理文檔,使得審核的難度加大,尤其是面對(duì)可能隨時(shí)加入各種信息、需求與資料的情況。

2.5增量模型增量模型是一種非整體開發(fā)的模型。根據(jù)增量的方式和形式的不同,分為基于瀑布模型的漸增模型和基于原型的快速原型模型。增量模型和瀑布模型之間的本質(zhì)區(qū)別是:瀑布模型屬于整體開發(fā)模型412.6組件集成模型我們將一個(gè)或多個(gè)相關(guān)類的組合稱為一個(gè)組件或構(gòu)件。組件集成模型融合了螺旋模型的許多特征,本質(zhì)上是演化型的,開發(fā)過程是迭代的以前項(xiàng)目中創(chuàng)建的組件被存儲(chǔ)在一個(gè)組件庫中。一旦開發(fā)人員經(jīng)過與用戶交談,確定軟件目標(biāo)和方案,就可以標(biāo)識(shí)出所需組件。首先搜索已有的組件庫,如果需要的組件己存在,就從庫中提取出來復(fù)用。如果不存在,就采用面向?qū)ο蠓椒ㄩ_發(fā)它。422.7敏捷開發(fā)過程敏捷不是一個(gè)過程,是一類過程的統(tǒng)稱,它們有一個(gè)共性,就是符合敏捷價(jià)值觀,遵循敏捷的原則。敏捷過程將整個(gè)軟件生命周期分解為若干個(gè)小的迭代周期,通過在每個(gè)迭代周期結(jié)束時(shí)交付階段性成果來獲取切實(shí)有效的客戶反饋。其目的是希望通過建立及時(shí)的反饋機(jī)制,來應(yīng)對(duì)隨時(shí)可能的需求變更,并作出響應(yīng)的調(diào)整,432.8微軟開發(fā)方法《微軟的秘密》對(duì)微軟公司軟件產(chǎn)品開發(fā)過程進(jìn)行了介紹。三個(gè)階段:計(jì)劃階段、開發(fā)階段、穩(wěn)定化階段(1)計(jì)劃階段產(chǎn)生:想象性描述、產(chǎn)品說明,接口標(biāo)準(zhǔn)、最初的測(cè)試計(jì)劃、文檔策劃、市場(chǎng)營(yíng)銷想象性描述主要定義產(chǎn)品開發(fā)目標(biāo),不涉及具體細(xì)節(jié)。44想象性描述包括對(duì)競(jìng)爭(zhēng)對(duì)手的產(chǎn)品分析、未來版本的規(guī)劃、必須解決的問題,新功能產(chǎn)品說明:定義出新的產(chǎn)品特性,并賦予不同優(yōu)先級(jí),及特性之間的關(guān)系。隨著項(xiàng)目深入,不斷添加細(xì)節(jié)對(duì)重要產(chǎn)品的分析和設(shè)計(jì)要高層領(lǐng)導(dǎo)復(fù)審基于產(chǎn)品說明,管理部門指定進(jìn)度表,安排開發(fā)組。45(2)開發(fā)階段

首先做計(jì)劃,定里程碑版本,產(chǎn)品分成3、4個(gè)子項(xiàng)目,測(cè)試人員與開發(fā)人員配對(duì),不斷測(cè)試基于產(chǎn)品說明開發(fā)。任務(wù)細(xì)化到4小時(shí)~3天預(yù)留1/3的緩沖時(shí)間(3)穩(wěn)定化階段著重對(duì)產(chǎn)品測(cè)試和調(diào)試,不再增加新的功能內(nèi)部測(cè)試和外部測(cè)試463軟件開發(fā)方法結(jié)構(gòu)化方法自1968年被提出以來經(jīng)過了多年的發(fā)展,形成了一套完整的體系。構(gòu)成結(jié)構(gòu)化開發(fā)方法。面向?qū)ο箝_發(fā)方法47結(jié)構(gòu)化開發(fā)基本原則自頂向下

程序設(shè)計(jì)時(shí),應(yīng)先考慮總體,后考慮細(xì)節(jié);先考慮全局目標(biāo),后考慮局部目標(biāo)。不要一開始就過多追求眾多的細(xì)節(jié),先從最上層總目標(biāo)開始設(shè)計(jì),逐步使問題具體化。逐步細(xì)化對(duì)復(fù)雜問題,應(yīng)設(shè)計(jì)一些子目標(biāo)作為過渡,逐步細(xì)化。模塊化設(shè)計(jì)限制使用goto語句,3種程序結(jié)構(gòu)48結(jié)構(gòu)化的不足隨著軟件產(chǎn)品劇模的不斷增大,結(jié)構(gòu)化范型有時(shí)不能應(yīng)付。也就是說,結(jié)構(gòu)化技術(shù)處理5000行或50000行代碼是有玫的。然而.當(dāng)今的軟件產(chǎn)品,有50000行或5000000甚至更多行代碼的產(chǎn)品非常普遍。維護(hù)階段是結(jié)構(gòu)化范型不能滿足人們期望的第二個(gè)方面。49面向?qū)ο箝_發(fā)方法面向?qū)ο蠹夹g(shù)自20世紀(jì)90年代提出以來得到快速發(fā)展,并被運(yùn)用到各種各樣的軟件應(yīng)用開發(fā)中。面向?qū)ο蠹夹g(shù)將數(shù)據(jù)和數(shù)據(jù)上的操作封裝在一起。對(duì)外封閉這些細(xì)節(jié)。從而實(shí)現(xiàn)了信息隱藏的目的。類、對(duì)象、封裝、50二者區(qū)別面向?qū)ο蟪绦蛟O(shè)計(jì)可以看作一種在程序中包含各種獨(dú)立而又互相調(diào)用的對(duì)象的思想。這與傳統(tǒng)的思想剛好相反:傳統(tǒng)的程序設(shè)計(jì)主張將程序看作一系列函數(shù)的集合,或者直接就是一系列對(duì)電腦下達(dá)的指令。面向?qū)ο蟪绦蛟O(shè)計(jì)中的每一個(gè)對(duì)象都應(yīng)該能夠接受數(shù)據(jù)、處理數(shù)據(jù)并將數(shù)據(jù)傳達(dá)給其它對(duì)象,因此它們都可以被看作一個(gè)小型的“機(jī)器”,即對(duì)象。511.5軟件文檔1.5.1軟件文檔在軟件開發(fā)中的地位和作用

1.軟件文檔在軟件開發(fā)中的地位軟件開發(fā)是一個(gè)系統(tǒng)工程,從軟件的生存周期角度出發(fā),科學(xué)的編制軟件文檔很有必要。軟件文檔也稱文件,通常指的是一些記錄的數(shù)據(jù)和數(shù)據(jù)媒體,可被人和計(jì)算機(jī)閱讀。在軟件工程中,文檔常常用來表示對(duì)活動(dòng)、需求、過程或結(jié)果進(jìn)行描述、定義、規(guī)定、報(bào)告或認(rèn)證的任何書面或圖示的信息,他們描述和規(guī)定了軟件設(shè)計(jì)和實(shí)現(xiàn)的細(xì)節(jié),說明使用軟件的操作命令。524、軟件文檔4.1

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請(qǐng)下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請(qǐng)聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會(huì)有圖紙預(yù)覽,若沒有圖紙預(yù)覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲(chǔ)空間,僅對(duì)用戶上傳內(nèi)容的表現(xiàn)方式做保護(hù)處理,對(duì)用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對(duì)任何下載內(nèi)容負(fù)責(zé)。
  • 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請(qǐng)與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時(shí)也不承擔(dān)用戶因使用這些下載資源對(duì)自己和他人造成任何形式的傷害或損失。

最新文檔

評(píng)論

0/150

提交評(píng)論