漢語版軟件需求分析與設(shè)計復(fù)習(xí)題201011版_第1頁
漢語版軟件需求分析與設(shè)計復(fù)習(xí)題201011版_第2頁
漢語版軟件需求分析與設(shè)計復(fù)習(xí)題201011版_第3頁
漢語版軟件需求分析與設(shè)計復(fù)習(xí)題201011版_第4頁
漢語版軟件需求分析與設(shè)計復(fù)習(xí)題201011版_第5頁
已閱讀5頁,還剩15頁未讀, 繼續(xù)免費(fèi)閱讀

下載本文檔

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

文檔簡介

1、軟件需求分析與設(shè)計模擬考試題及答案一 解釋下列名詞的含義:1軟件工程2過程3風(fēng)險4演化型原型5里程碑6技術(shù)設(shè)計7白盒測試8面向?qū)ο?由底向上測試10性能測試二判斷1、( ) 程序設(shè)計語言種類很多,在進(jìn)行軟件開發(fā)時可以隨便選擇一種語言進(jìn)行編碼。3、( ) 在軟件開發(fā)的各個階段進(jìn)行過程中,增加人員肯定會對整個項(xiàng)目提前完成有好處。4、( ) CoCoMo模型可以用來估算系統(tǒng)的工作量和軟件開發(fā)所需時間。6、( ) OOA方法的核心思想是利用面向?qū)ο蟮母拍詈头椒檐浖枨蠼ㄔ炷P停笾虏襟E是識別對象(屬性和方法),識別類及其結(jié)構(gòu),定義對象之間的消息傳遞等。7、( ) 系統(tǒng)需求分析員應(yīng)該具有開發(fā)軟、硬件系

2、統(tǒng)的經(jīng)驗(yàn)并且了解用戶領(lǐng)域的知識。8、( )軟件運(yùn)行正確,可見軟件中沒有缺陷(fault)。9、( )軟件失?。╢ailure)在系統(tǒng)交付之前和交付之后都可能被發(fā)現(xiàn)。10、( )開發(fā)人員和客戶對軟件質(zhì)量因素的認(rèn)可是完全一致的。12、( )里程碑(milestone)就是開發(fā)過程中的某個活動(activity)。13、( )在軟件開發(fā)中一定要不惜代價避免風(fēng)險。/ 三填空(本大題僅為參考) 1、請列舉出三方面的用以衡量軟件質(zhì)量的因素:( )、( )、( )。2、軟件開發(fā)過程從大的階段上分為( )、( )、程序設(shè)計、( )、單元測試、組裝測試、( )、交付、維護(hù)。3、數(shù)據(jù)流圖中,使用了四種基本符號,它

3、們分別是( )。4、開發(fā)原型的目的是( )。5、請列舉出2種軟件開發(fā)模型:( )、( )。6、項(xiàng)目進(jìn)度通常用活動圖來管理,活動圖中的節(jié)點(diǎn)表示( ),節(jié)點(diǎn)之間的線段表示( )。7、常用的軟件開發(fā)組織結(jié)構(gòu)有( )、成員之間平等的開發(fā)小組方式等。8、軟件成本的算法估算等式E=(a+bSc)m(X)中,主要的影響因素S表示( )。9、風(fēng)險控制的主要手段有( )、( )、( )。四從供選擇的答案中,選出正確的答案填入()內(nèi)。 1白盒測試法常用的方法是A方法,黑盒法中常用的方法是B方法和C方法,C方法根據(jù)輸入的關(guān)系設(shè)計測試用例。供選擇的答案:A、B、C:綜合測試路徑測試等價分類 歸納測試 因 果 圖追蹤

4、回溯排錯( ) 2模塊綜合測試的方法有A和B兩種,A是從下層模塊向上層模塊依次結(jié)合進(jìn)行測試,為測試需要C以便調(diào)用被測模塊,但從開發(fā)的初期就能并行進(jìn)行測試作業(yè),并且每個模塊的D都很容易做,是這種方法的優(yōu)點(diǎn)。其缺點(diǎn)是直到測試的最后階段,程序的缺陷都難以發(fā)現(xiàn)。B是從上層模塊向下層模塊依次結(jié)合進(jìn)行測試,為了測試需要設(shè)計E模塊模擬被測模塊所調(diào)用的下級模塊。 供選擇的答案:A、B、D:功能測試組合測試綜合測試 可靠性測試 結(jié)構(gòu)測試自頂向下測試 自底向上測試C、E:仿真模擬生成 轉(zhuǎn)貯跟蹤 驅(qū)動模塊 宏模塊支持模塊( )4軟件設(shè)計中劃分程序模塊通常遵循的原則是要求各模塊間的耦合性盡可能_,三種可能的模塊耦合是

5、:_:例如,一個模塊直接引用另一模塊中的數(shù)據(jù)。_:例如,一個模塊把開關(guān)量作為參數(shù)傳送給另一模塊。_:例如,一個模塊把數(shù)值量作為參數(shù)傳送給另一模塊。其中,_的耦合性最強(qiáng)。 強(qiáng) 弱 適中 公共耦合 數(shù)據(jù)耦合 邏輯耦合 外部耦合 內(nèi)容耦合 控制耦合5軟件是計算機(jī)系統(tǒng)中與硬件相互依存的部分,它是包括(A)、(B)及(C)的完整集合。其中,(A)是按事先設(shè)計的功能和性能要求執(zhí)行的指令序列,(B)是使程序能夠正確操縱信息的數(shù)據(jù)結(jié)構(gòu),(C)是與程序開發(fā)、維護(hù)和使用有關(guān)的圖文資料。A,B,C: 軟件 程序 代碼 硬件 文檔 外設(shè) 數(shù)據(jù) 圖表 填入答案(A: B: C: D: )五簡述題1說明錯誤、缺陷、失敗的

6、含義與聯(lián)系。(請舉例說明)2影響軟件工程開發(fā)實(shí)踐的關(guān)鍵要素是什么?3畫出軟件生存周期的瀑布模型,注明各個階段所需文檔,并說明其優(yōu)缺點(diǎn)。4簡述設(shè)計用戶界面應(yīng)考慮的問題。5試述COCOMO模型的工作原理。6舉例說明需求的分類及相互關(guān)系。(P138)7對每一種耦合關(guān)系,舉例說明之。8說明軟件測試過程的主要步驟及含義。六綜合題目1 根據(jù)給定的命題畫出UML分析圖(課本或課件上介紹過的圖-例如用例圖、類圖等)。/ 測試方面的題目。2 綜合論述題目。( 例如:為什么軟件維護(hù)費(fèi)用一直居高不下?困難何在?克服困難的途徑何在?-自己總結(jié))( 又例如:試闡述設(shè)計軟件用戶界面應(yīng)該考慮的問題。-課件第5章22,23頁

7、)/ 3. 軟件計劃和項(xiàng)目管理中: 根據(jù)活動圖計算關(guān)鍵路徑 (第三章)漢語版軟件需求分析與設(shè)計教學(xué)內(nèi)容回顧 (備注1:下述問題答案以教學(xué)課件為主要參考,加注“/”標(biāo)記的僅作為參考內(nèi)容) (備注2:所標(biāo)頁數(shù)為英文教材頁數(shù),可以簡單的在課件中或漢語教材中按章節(jié)查找)Chapter01 SE的定義、目的、方法及作用(P2 / P16) / 開發(fā)模式(paradiam)(P4)/ 說明錯誤、缺陷、失敗的含義與聯(lián)系。(請舉例說明)(6頁)(44頁習(xí)題3)軟件質(zhì)量應(yīng)從哪幾個方面來衡量?論述之。(9-12頁)/ 軟件系統(tǒng)的系統(tǒng)組成(P16)現(xiàn)代軟件工程大致包含的幾個階段及各個階段文檔(P23-24)使現(xiàn)代S

8、E實(shí)踐發(fā)生變化的(七個)關(guān)鍵因素是什么?(28-29頁)什么是抽象?(30頁) 什么是軟件過程?軟件過程的重要性是什么?包含幾個階段?(32頁)(45頁)什么是重用?(34頁) 作業(yè):(1)掌握所學(xué)基本概念 (2)習(xí)題2Chaoter02什么是軟件過程?軟件過程的重要性是什么? (P45-46)瀑布模型及各階段文檔,優(yōu)缺點(diǎn)?(P49)原型的概念(P51)論述分階段開發(fā)模型的含義, 分類及特點(diǎn)。(56頁) / 螺旋模型四個象限的任務(wù)及四重循環(huán)的含義?(P58)/ P80-81頁 習(xí)題2, 3。/ 在所有的軟件開發(fā)過程模型中,你認(rèn)為哪些過程給予你最大的靈活性以應(yīng)對需求/ 的變更?(81頁習(xí)題11)

9、作業(yè):(1)掌握所學(xué)基本概念 (2)習(xí)題2,9,11Chapter03什么是項(xiàng)目調(diào)度?活動?里程碑?(83頁)/ 如何計算軟件項(xiàng)目活動圖的關(guān)鍵路徑?(習(xí)題2,3)軟件人員應(yīng)該具備的能力是什么?(96頁)/ 軟件項(xiàng)目組織的基本結(jié)構(gòu)?(101頁)專家估算法的大致含義?(106頁),算式估算法的大致含義?(108頁)試述COCOMO模型的三個階段基本工作原理或含義。(111頁)什么是風(fēng)險?有幾種降低風(fēng)險的策略?(119、122頁)/ 找出圖3.23和3.24(139頁)的關(guān)鍵路徑。作業(yè):(1)掌握所學(xué)基本概念 (2)習(xí)題11Chapter04需求的含義是什么? (143頁)確定需求的過程是什么?(1

10、44頁 圖4.1)舉例說明獲取需求時的需求分類及相互關(guān)系。(152頁)/ 如何使需求變得可測試?(151-152頁, sidebar4.4)需求文檔分為哪兩類?(153頁)什么是功能性需求和非功能性需求/質(zhì)量需求?(149頁)/ 需求的特性?(正確性、一致性、完整性)(155頁)/ 掌握了解DFD圖(172頁)在需求原型化方面,什么是拋棄型原型?什么是演化型原型?(192-193頁)/ 用DFD圖簡單描述ATM機(jī)的工作原理(主要功能和數(shù)據(jù)流)(220頁習(xí)題7)作業(yè):(1)掌握所學(xué)基本概念 (2)采用DFD圖和用例圖做習(xí)題6Chapter05什么是設(shè)計?概念設(shè)計?技術(shù)設(shè)計?(223-224頁)三

11、種設(shè)計層次及其關(guān)系?(229頁)/ 什么是模塊化?什么是抽象?(238頁)論述設(shè)計用戶界面應(yīng)考慮的問題。(242頁)5.5節(jié)-模塊獨(dú)立性-耦合與內(nèi)聚的概念及層次劃分?(248-xxx頁)舉例說明耦合與內(nèi)聚的基本分類。(284頁習(xí)題4,5)作業(yè):(1)掌握所學(xué)基本概念 (2)習(xí)題4,5,9 Chapter06什么是面向?qū)ο???86頁) /有幾個什么特征?(286-291)OO開發(fā)有何優(yōu)勢?(291頁)OO開發(fā)過程有幾個步驟?(292頁)用例圖的組成和畫法(294頁)熟悉類圖中各個類之間的基本關(guān)系分類(303-305)熟悉類圖、順序圖的組成和基本畫法(300-308頁)作業(yè):(1)掌握所學(xué)基本概

12、念 (2)掌握用例圖、類圖、時序圖的基本畫法Chapter07/ 為什么說編碼工作是紛繁復(fù)雜甚至令人氣餒?(337頁) (了解)一般性的編程原則應(yīng)該從哪三個方面考慮?(340-344頁)/ 論述編碼階段實(shí)現(xiàn)某種算法時所涉及的問題。(342頁)在編寫程序內(nèi)部文檔時,除了HCB外,還應(yīng)添加什么注釋信息?(352-354頁)/ 什么是極限編程(XP)?(357頁)作業(yè):(1)掌握所學(xué)基本概念Chapter08產(chǎn)生缺陷的原因?(365頁)缺陷分類的理由?(367頁)幾種主要的缺陷類型?(367-368頁)/ 什么是正交缺陷分類?(369頁)測試的各個階段及其任務(wù)?(372頁圖8.3)/ 測試的態(tài)度問題

13、?(為什么要獨(dú)立設(shè)置測試團(tuán)隊(duì)?)(373頁)測試的方法-黑盒、白盒的概念?(374)什么是單元測試? /步驟?什么是走查和檢查?(376頁)/ 黑盒白盒方法各自的分類?(結(jié)合補(bǔ)充材料)集成測試及其主要方法的分類?(390-392)/ 傳統(tǒng)測試和OO測試有何不同?(398-399頁)/ 測試計劃涉及的幾個步驟?(400頁) (了解)作業(yè):(1)掌握所學(xué)基本概念 (2)習(xí)題7,14Chapter09系統(tǒng)測試的主要步驟及各自含義?(420頁, 圖9.2)/ 什么是系統(tǒng)配置?配置管理?(423頁)/ 什么是回歸測試?(425頁)功能測試的含義極其作用?(430頁)性能測試的含義與作用?(436頁)性能

14、測試的主要分類?(436頁)/ 什么是可靠性、可用性和可維護(hù)性?(438頁)確認(rèn)測試, 確認(rèn)測試分類?(基準(zhǔn)測試和引導(dǎo)測試)(447-448頁)什么是alpha測試?測試?(448頁)/ 什么是安裝測試?(450頁)作業(yè):(1)掌握所學(xué)基本概念一 解釋下列名詞的含義:1.軟件工程:軟件工程是一種系統(tǒng)工程,不只包括對技術(shù)問題的分析與解決,還包括對開發(fā)過程和給參與者分配合適的角色等方面的管理2.過程:軟件工具、技術(shù)和方法的組合。3.風(fēng)險:在軟件生產(chǎn)過程中不希望看到的、有負(fù)面結(jié)果的事件。4.演化型原型:在獲得用戶基本需求說明的基礎(chǔ)上,投入少量人力和物力,快速建立一個原始模型,使用戶及時運(yùn)行和看到模型

15、的概貌和使用效果,并對需求說明進(jìn)行補(bǔ)充和精化,提出改進(jìn)意見,開發(fā)人員進(jìn)一步修改完善,如此循環(huán)迭代,直到得到一個用戶滿意的模型為止。從原型法的基本思想中科院看到,用戶能及早看到系統(tǒng)模型,在循環(huán)迭代修改和完善過程中,使用戶的需求日益明確,從而消除了用戶需求的不確定性,同時從原型到模型的生產(chǎn),周期短、見效快,對環(huán)境變化的適應(yīng)能力較強(qiáng)。5.里程碑:指特定的時間點(diǎn), 標(biāo)志著活動的結(jié)束, 通常伴隨著提交物。6.技術(shù)設(shè)計:技術(shù)設(shè)計軟件功能和接口的實(shí)現(xiàn)方法,告訴程序員怎樣實(shí)現(xiàn)系統(tǒng)能做什么。7.白盒測試:根據(jù)測試對象的結(jié)構(gòu)不同的方式來進(jìn)行測試。 優(yōu)點(diǎn):模塊詳細(xì)測試。缺點(diǎn):實(shí)際上行不通8.面向?qū)ο螅篛O是一種軟件

16、開發(fā)方法,它將問題及其解決方法組織成一系列獨(dú)立的對象,數(shù)據(jù)結(jié)構(gòu)和動作都被包括在內(nèi)。9.由底向上測試:自底向上測試是從“原子”模塊(即軟件結(jié)構(gòu)最低層的模塊)開始組裝測試,因測試到較高層模塊時,所需的下層模塊功能均已具備,所以不再需要樁模塊。 自底向上綜合測試的步驟分為: 1 把低層模塊組織成實(shí)現(xiàn)某個子功能的模塊群(cluster); 2 開發(fā)一個測試驅(qū)動模塊,控制測試數(shù)據(jù)的輸入和測試結(jié)果的輸出; 3 對每個模塊群進(jìn)行測試; 4 刪除測試使用的驅(qū)動模塊,用較高層模塊把模塊群組織成為完成更大功能的新模塊群。 10.性能測試:性能測試將集成的

17、構(gòu)件與非功能性系統(tǒng)需求進(jìn)行比較,得到驗(yàn)證過的系統(tǒng)。作用:測試非功能性需求二判斷1、(×) 程序設(shè)計語言種類很多,在進(jìn)行軟件開發(fā)時可以隨便選擇一種語言進(jìn)行編碼。3、(×)在軟件開發(fā)的各個階段進(jìn)行過程中,增加人員肯定會對整個項(xiàng)目提前完成有好處。4、(×)CoCoMo模型可以用來估算系統(tǒng)的工作量和軟件開發(fā)所需時間。6、() OOA方法的核心思想是利用面向?qū)ο蟮母拍詈头椒檐浖枨蠼ㄔ炷P?,大致步驟是識別對象(屬性和方法),識別類及其結(jié)構(gòu),定義對象之間的消息傳遞等。7、()系統(tǒng)需求分析員應(yīng)該具有開發(fā)軟、硬件系統(tǒng)的經(jīng)驗(yàn)并且了解用戶領(lǐng)域的知識。8、(×)軟件運(yùn)行正確

18、,可見軟件中沒有缺陷(fault)。9、()軟件失?。╢ailure)在系統(tǒng)交付之前和交付之后都可能被發(fā)現(xiàn)。10、(×)開發(fā)人員和客戶對軟件質(zhì)量因素的認(rèn)可是完全一致的。12、()里程碑(milestone)就是開發(fā)過程中的某個活動(activity)。13、(×)在軟件開發(fā)中一定要不惜代價避免風(fēng)險。三填空(本大題僅為參考) 1、請列舉出三方面的用以衡量軟件質(zhì)量的因素:(最終產(chǎn)品的質(zhì)量)、(開發(fā)過程的質(zhì)量)、(商業(yè)價值)。2、軟件開發(fā)過程從大的階段上分為(可行性分析)、(系統(tǒng)需求設(shè)計)、程序設(shè)計、(編寫程序)、單元測試、組裝測試、(系統(tǒng)測試)、交付、維護(hù)。3、數(shù)據(jù)流圖中,使用

19、了四種基本符號,它們分別是( )。 加工 數(shù)據(jù)流向 數(shù)據(jù)集合 外部項(xiàng)4、開發(fā)原型的目的是(用來讓用戶和開發(fā)者共同研究,提出意見,為最終產(chǎn)品定型 )。5、請列舉出2種軟件開發(fā)模型:(瀑布模型)、( 原型化模型)。6、項(xiàng)目進(jìn)度通常用活動圖來管理,活動圖中的節(jié)點(diǎn)表示(開始結(jié)點(diǎn)),節(jié)點(diǎn)之間的線段表示(廣播消息)。7、常用的軟件開發(fā)組織結(jié)構(gòu)有( )、成員之間平等的開發(fā)小組方式等。8、軟件成本的算法估算等式E=(a+bSc)m(X)中,主要的影響因素S表示(系統(tǒng)規(guī)模估計量)。9、風(fēng)險控制的主要手段有(規(guī)避風(fēng)險)、(轉(zhuǎn)移風(fēng)險)、(加入風(fēng)險會發(fā)生)。四從供選擇的答案中,選出正確的答案填入()內(nèi)。 1白盒測試法

20、常用的方法是A方法,黑盒法中常用的方法是B方法和C方法,C方法根據(jù)輸入的關(guān)系設(shè)計測試用例。供選擇的答案: A、B、C:綜合測試路徑測試等價分類 歸納測試 因 果 圖追蹤 回溯排錯 2模塊綜合測試的方法有A和B兩種,A是從下層模塊向上層模塊依次結(jié)合進(jìn)行測試,為測試需要C以便調(diào)用被測模塊,但從開發(fā)的初期就能并行進(jìn)行測試作業(yè),并且每個模塊的D都很容易做,是這種方法的優(yōu)點(diǎn)。其缺點(diǎn)是直到測試的最后階段,程序的缺陷都難以發(fā)現(xiàn)。B是從上層模塊向下層模塊依次結(jié)合進(jìn)行測試,為了測試需要設(shè)計E模塊模擬被測模塊所調(diào)用的下級模塊。A: B: C: D: E: 供選擇的答案:A、B、D:功能測試組合測試綜合測試 可靠性

21、測試 結(jié)構(gòu)測試自頂向下測試 自底向上測試C、E:仿真模擬生成 轉(zhuǎn)貯跟蹤 驅(qū)動模塊 宏模塊支持模塊4軟件設(shè)計中劃分程序模塊通常遵循的原則是要求各模塊間的耦合性盡可能_,三種可能的模塊耦合是: _:例如,一個模塊直接引用另一模塊中的數(shù)據(jù)。_:例如,一個模塊把開關(guān)量作為參數(shù)傳送給另一模塊。_:例如,一個模塊把數(shù)值量作為參數(shù)傳送給另一模塊。其中,_的耦合性最強(qiáng)。 強(qiáng) 弱 適中 公共耦合 數(shù)據(jù)耦合 邏輯耦合 外部耦合 內(nèi)容耦合 控制耦合5軟件是計算機(jī)系統(tǒng)中與硬件相互依存的部分,它是包括(A)、(B)及(C)的完整集合。其中,(A)是按事先設(shè)計的功能和性能要求執(zhí)行的指令序列,(B)是使程序能夠正確操縱信息

22、的數(shù)據(jù)結(jié)構(gòu),(C)是與程序開發(fā)、維護(hù)和使用有關(guān)的圖文資料。A,B,C: 軟件 程序 代碼 硬件 文檔 外設(shè) 數(shù)據(jù) 圖表 填入答案(A: B: C: )五簡述題1說明錯誤、缺陷、失敗的含義與聯(lián)系。(請舉例說明)答:錯誤,是進(jìn)行軟件開發(fā)過程中人為出錯造成的。 缺陷:當(dāng)人們在進(jìn)行軟件開發(fā)活動的過程中出現(xiàn)錯誤時,就會引起缺陷。失?。菏侵赶到y(tǒng)違背了它應(yīng)有的行為??赡軙谙到y(tǒng)交付前或交付后被發(fā)現(xiàn),也可能在測試過程中或者在運(yùn)行和維護(hù)過程中被發(fā)現(xiàn)。(1)單個錯誤可能產(chǎn)生多個缺陷,并且缺陷可能駐留在任何開發(fā)或維護(hù)的產(chǎn)品中,如設(shè)計人員可能錯誤理解某個需求,創(chuàng)建處于需求分析人員和用戶實(shí)際意圖不相符的設(shè)計,這個設(shè)計缺

23、陷是一種錯誤的編碼,可能導(dǎo)致其他缺陷,像不正確的代碼或用戶手冊中不正確的描述等。(2)并非每一個缺陷都對應(yīng)于一個失敗,如果不執(zhí)行缺陷代碼或者不進(jìn)入某個特定狀態(tài)缺陷就不會引起失敗。(3)缺陷是系統(tǒng)的內(nèi)部視圖,這是從開發(fā)人員角度看問題而失敗是系統(tǒng)的外部視圖,它是用戶所看到的問題。例如:X: 內(nèi)存分配 Y: 示例-“在裝配線上的多個傳送帶運(yùn)行”2影響軟件工程開發(fā)實(shí)踐的關(guān)鍵要素是什么?(1)商用產(chǎn)品投入市場時間的緊迫性。(2)計算技術(shù)在經(jīng)濟(jì)中的轉(zhuǎn)變:更低的硬件成本,更高的開發(fā)和維護(hù)成本。(3)功能強(qiáng)大的桌面計算的可用性。 (4)廣泛的局域網(wǎng)和廣域網(wǎng)。(5)面向?qū)ο蠹夹g(shù)的采用及其有效性。(6)使用窗口、

24、圖標(biāo)、菜單和指示器的圖形用戶界面(7)軟件開發(fā)瀑布模型的不可預(yù)測性。3畫出軟件生存周期的瀑布模型,注明各個階段所需文檔,并說明其優(yōu)缺點(diǎn)。答:需求分析 SRS 系統(tǒng)設(shè)計 系統(tǒng)設(shè)計文檔如軟件結(jié)構(gòu)圖 程序設(shè)計 模塊功能算法和數(shù)據(jù)描述文檔 編碼 源程序和注釋 單元測試和集成測試 測試報告 系統(tǒng)測試 測試報告 驗(yàn)收測試 測試報告 運(yùn)行維護(hù) 維護(hù)報告優(yōu)點(diǎn):(1)它的簡單性使得開發(fā)人員很容易向不熟悉軟件開發(fā)的客戶作出解釋。 (2)明確的表示出為了下一階段的開發(fā),那些中間產(chǎn)品是必須的。用里程碑明確表示出一個階段的結(jié)束,并伴隨著提交物。 (3)瀑布模型是其他復(fù)雜模型的基礎(chǔ)。缺點(diǎn):最大的問題是它不能反映實(shí)際代碼的

25、開發(fā)過程。 面臨軟件變動時, 該模型無法處理實(shí)際過程中的重復(fù)開發(fā)問題-軟件是一個創(chuàng)造的過程,不是一個制造的過程。 文檔轉(zhuǎn)換有困難。 沒有將開發(fā)看成一個迭代的過程。 難以適應(yīng)商業(yè)環(huán)境和操作環(huán)境的變化。4簡述設(shè)計用戶界面應(yīng)考慮的問題。答:(1)隱喻:可以認(rèn)識和學(xué)習(xí)的基本術(shù)語。 (2)頭腦中的模型:數(shù)據(jù)、功能、任務(wù)和角色的組織和表示。(3)模型的導(dǎo)航規(guī)則:如何在數(shù)據(jù),功能,活動和角色中移動。 (4)外觀:系統(tǒng)向用戶傳輸信息的外觀特性。(5)感覺:向用戶提供有吸引力的體驗(yàn)和交互技術(shù)。(6)文化問題:信仰,價值觀、道德規(guī)范、傳統(tǒng)、風(fēng)俗和傳說。 (7)用戶偏好:個人喜好。5試述COCOMO模型的工作原理。

26、答:階段1,項(xiàng)目通常構(gòu)建原型以解決包含用戶界面、軟件和系統(tǒng)交互、性能和技術(shù)成熟性等方面在內(nèi)的高風(fēng)險問題。COCOMO用應(yīng)用點(diǎn)來估計規(guī)模。階段2(早期設(shè)計階段),COCOMO采用功能點(diǎn)作為對規(guī)模的估計量。階段3(后體系結(jié)構(gòu)階段),COCOMO規(guī)模用功能點(diǎn)或代碼行的形式來表述。6舉例說明需求的分類及相互關(guān)系。答:A必須滿足的需求(必須的) B很值得要得但不是必須的(值得要的)C可要可不要的(可選的)。之所以有上述分類的原因:有的軟件開發(fā)項(xiàng)目受到了時間和資源的限制。我們在從所有的利益相關(guān)者得到需求的過程中,一定會遇到這樣的情況:大家對“需求應(yīng)該是什么”的看法不一致甚至?xí)袥_突。7對每一種耦合關(guān)系,舉

27、例說明之。六種等級 (關(guān)于耦合程度的度量) 非直接耦合:模塊相互之間沒有信息傳遞數(shù)據(jù)耦合:模塊間傳遞的是數(shù)據(jù) 特征耦合:模塊間傳遞的是數(shù)據(jù)結(jié)構(gòu) 控制耦合:模塊間傳遞的是控制量內(nèi)容耦合:當(dāng)一個模塊直接修改或操作另一個模塊的數(shù)據(jù),或者直接轉(zhuǎn)入另一個模塊時公共耦合:公共耦合指通過一個公共數(shù)據(jù)環(huán)境相互作用的那些模塊間的耦合 非直接耦合8說明軟件測試過程的主要步驟及含義。單元測試 設(shè)計規(guī)格 系統(tǒng)功能 其他軟件 客戶需求 用戶環(huán)境使用中的系統(tǒng)安裝測試構(gòu)件 測 說明 需求 需求 規(guī)格說明功能測試性能測試驗(yàn)收測試集成測試代碼 試 單元測試構(gòu)件 中代碼 的 集成的模塊 運(yùn)行的系統(tǒng) 驗(yàn)證、確認(rèn) 接受的系統(tǒng)單元測試

28、 構(gòu)件 的軟件構(gòu)件 代碼 系統(tǒng)測試 將每個程序 驗(yàn)證系統(tǒng)構(gòu)件 對系統(tǒng)進(jìn)行 將系統(tǒng)與這 根據(jù)顧客的 在系統(tǒng)實(shí)際 構(gòu)件與系統(tǒng) 是否能夠按照 評估,以確 些軟件和硬 需求描述檢 使用環(huán)境中 中的其他構(gòu) 系統(tǒng)和程序設(shè) 定集成的系 件需求的剩 查該系統(tǒng)。 測試該系統(tǒng)。 件隔離,對 計規(guī)格說明中 統(tǒng)是否確實(shí) 余部分進(jìn)行 其本身進(jìn)行 描述的那樣共 執(zhí)行需求規(guī) 比較。 測試。 同工作。 格說明中描 述的功能。六綜合題目3 根據(jù)給定的命題畫出UML分析圖(課本或課件上介紹過的圖-例如用例圖、類圖等)。 UML為人們提供了從不同的角度去觀察和展示系統(tǒng)的各種特征的一種標(biāo)準(zhǔn)表達(dá)方式。在UML中,從任何一個角度對系統(tǒng)所

29、作的抽象都可能需要用幾種模型圖來描述,而這些來自不同角度的模型圖最終組成了系統(tǒng)的完整模型。 一般而言,我們可以從以下幾種常用的視角來描述一個系統(tǒng):系統(tǒng)的使用實(shí)例:從系統(tǒng)外部的操作者的角度描述系統(tǒng)的功能。系統(tǒng)的邏輯結(jié)構(gòu):描述系統(tǒng)內(nèi)部的靜態(tài)結(jié)構(gòu)和動態(tài)行為,即從內(nèi)部描述如何設(shè)計實(shí)現(xiàn)系統(tǒng)功能。系統(tǒng)的構(gòu)成:描述系統(tǒng)由哪些程序構(gòu)件所組成。系統(tǒng)的并發(fā)性:描述系統(tǒng)的并發(fā)性,強(qiáng)調(diào)并發(fā)系統(tǒng)中存在的各種通信和同步問題。系統(tǒng)的配置:描述系統(tǒng)的軟件和各種硬件設(shè)備之間的配置關(guān)系。 UML模型圖(5類,10種):用例圖、靜態(tài)圖(類圖,對象圖,包圖)、行為圖(狀態(tài)圖,活動圖)、交互圖(順序圖,合作圖)、實(shí)現(xiàn)圖(構(gòu)件圖,配置圖

30、)UML主要文件:UML概要(UML Summary)、UML語義(UML Semantics)、UML表示法指南(UML Notation Guide)對象約束語言規(guī)約(Object Contraint language Specification):該文件定義并介紹了一種對象約束語言(OCL),其用途是用來說明在圖形化的系統(tǒng)模型中不能充分表達(dá)的建模信息。它是一種形式化語言。(1).用例圖 (UML use-case diagrams) 從本質(zhì)上將,一個用例是用戶與計算機(jī)之間為達(dá)到某個目的的一次典型交互作用:用例描述了用戶提出的一些可見的需求;用例可大可小;用例對應(yīng)一個具體的用戶目標(biāo) 用例圖

31、描述系統(tǒng)外部的執(zhí)行者與系統(tǒng)的用例之間的某種聯(lián)系。所謂用例是指對系統(tǒng)提供的功能(或稱系統(tǒng)的用途)的一種描述;執(zhí)行者是那些可能使用這些用例的人或外部系統(tǒng);用例和執(zhí)行者之間的聯(lián)系描述了“誰使用哪個用例”。用例圖著重于從系統(tǒng)外部執(zhí)行者的角度來描述系統(tǒng)需要提供哪些功能,并且指明了這些功能的執(zhí)行者是誰;用例圖在UML方法中占有十分重要的地位,人們甚至稱UML是一種用例圖驅(qū)動的開發(fā)方法。1、進(jìn)度項(xiàng)目進(jìn)度是對特定項(xiàng)目的軟件開發(fā)周期的刻畫。包括對項(xiàng)目階段、步驟、活動的分解,對各個活動的交互關(guān)系的描述,以及對各活動完成時間的初步估算2、活動項(xiàng)目的一部分, 一般占用項(xiàng)目進(jìn)度計劃中的一段時間14. 軟件的概念 (=代

32、碼+數(shù)據(jù)+文檔)特點(diǎn)A:軟件是一個邏輯實(shí)體 B:軟件生產(chǎn)不同于硬件C:軟件是復(fù)雜的D:開發(fā)過程中社會因素的干擾(觀念、體制等)3、什么是新的開發(fā)途徑 ? 設(shè)想采用系統(tǒng)工程的方法-強(qiáng)調(diào)可管理的開發(fā)途徑(軟件-分解為許多部分-對每一部分對進(jìn)行細(xì)致的說 明-細(xì)致開發(fā)各個軟件部分-合成軟件部件-高質(zhì)量的軟件產(chǎn)品 )4、什么是軟件工程SE= 弄清問題本質(zhì)(將問題理解清楚,敘述明白) + 實(shí)現(xiàn)解決方案 (通過開發(fā)環(huán)境與工具),用系統(tǒng)科學(xué)的方法解決問題 j問題分析: 大的問題=子問題集+ 子問題之間的關(guān)系集 (Fig1.1) k系統(tǒng)合成: 各個解決方案的最后有機(jī)合成 . l幾個概念: 工具 : 儀器/自動軟

33、件系統(tǒng)/編程環(huán)境 /軟件工具模塊 過程 : 軟件工具、技術(shù)和方法的組合. 模式-開發(fā)軟件時特定的方法或哲學(xué) - 面向?qū)ο竽J?- 結(jié)構(gòu)化模式,基于過程的模式,等等5、什么是過程質(zhì)量過程質(zhì)量是指過程滿足明確和隱含需要的能力的特性之總和。既然過程的基本功能是將輸入轉(zhuǎn)化為輸出,那么過程質(zhì)量一方面可以通過構(gòu)成過程的要素(如投入的資源)和相關(guān)活動滿足明確和隱含需要的程度來考慮,另一方面也可以通過過程輸出(如產(chǎn)品和勞務(wù)等有形或無形產(chǎn)品)的質(zhì)量好壞來間接地反映6、軟件工程師的任務(wù) task: 以計算機(jī)科學(xué)理論和計算機(jī)功能為基礎(chǔ),通過對要解決問題的本質(zhì)的了解,采用相應(yīng)的工具和技術(shù),實(shí)現(xiàn)設(shè)計方案,推出高質(zhì)量的軟

34、件產(chǎn)品。 SE = 采用工具、技術(shù)等用來解決現(xiàn)實(shí)問題的 綜合過程7、軟件工程的目的保軟件具有技術(shù)高質(zhì)量和實(shí)際商業(yè)用途 8、 V模型與基本瀑布模型的區(qū)別A: V模型使一些迭代活動更加明確B: 瀑布模型強(qiáng)調(diào)文檔和提交物/制品, 而V模型強(qiáng)調(diào)開發(fā)活動及正確性9、原型化模型j 解釋:該模型本身是有效的過程模型的基礎(chǔ)。因?yàn)樗试S用戶以獨(dú)立的工程模型的方式, 每一階段都基于原型的建立, 以快速構(gòu)造系統(tǒng), 逐步完成各階段任務(wù) 10、增量式和迭代式增量式開發(fā):(系統(tǒng)需求按照功能分成若干子系統(tǒng),開始建造的版本是規(guī)模小的、部分功能的系統(tǒng),后續(xù)版本添加包含新功能的子系統(tǒng),最后版本是包含全部功能的子系統(tǒng)集.迭代式開發(fā)

35、:系統(tǒng)開始就提供了整體功能框架,后續(xù)版本陸續(xù)增強(qiáng)各個子系統(tǒng),最后版本使各個子系統(tǒng)的功能達(dá)到最強(qiáng).是統(tǒng)一開發(fā)過程(RUP)的關(guān)鍵實(shí)踐開發(fā)被組織成一系列固定的短期小項(xiàng)目每次迭代都產(chǎn)生經(jīng)過測試、集成并可執(zhí)行的局部系統(tǒng)每次迭代都具有各自的需求分析、設(shè)計、實(shí)現(xiàn)和測試隨著時間和一次次迭代,系統(tǒng)增量式完善11、 分階段開發(fā)形式的存在原因A: 培訓(xùn)-觀察用戶的反饋B: 市場-將在早期建立和開拓C: 盡早發(fā)現(xiàn)和修復(fù)軟件問題D: 不同的發(fā)布版本具有不同的專業(yè)技能 12、統(tǒng)一過程它是用例驅(qū)動的、以基本架構(gòu)為中心的、迭代式和增量性的軟件開發(fā)過程框架,它使用對象管理組織(OMG)的UML 并與對象管理組織(OMG)的軟

36、件過程工程原模型(SPEM)等相兼容。 “統(tǒng)一過程”將重復(fù)一系列生命期,這些生命期構(gòu)成了一個系統(tǒng)的壽命。每個生命期都以向客戶推出一個產(chǎn)品版本而結(jié)束。 每個周期包括四個階段:開始階段、確立階段、構(gòu)建階段和移交階段。每個階段可以進(jìn)一步劃分為多次迭代。13、 螺旋模型將瀑布模型和快速原型模型結(jié)合起來,強(qiáng)調(diào)了其他模型所忽視的風(fēng)險分析,特別適合于大型復(fù)雜的系統(tǒng)采用一種周期性的方法來進(jìn)行系統(tǒng)開發(fā)。這會導(dǎo)致開發(fā)出眾多的中間版本。使用它,項(xiàng)目經(jīng)理在早期就能夠?yàn)榭蛻魧?shí)證某些概念。該模型是快速原型法,以進(jìn)化的開發(fā)方式為中心,在每個項(xiàng)目階段使用瀑布模型法。這種模型的每一個周期都包括需求定義、風(fēng)險分析、工程實(shí)現(xiàn)和評審

37、4個階段,由這4個階段進(jìn)行迭代。軟件開發(fā)過程每迭代一次,軟件開發(fā)又前進(jìn)一個層次。采用螺旋模型的軟件過程如下圖所示::螺旋模型基本做法是在“瀑布模型”的每一個開發(fā)階段前引入一個非常嚴(yán)格的風(fēng)險識別、風(fēng)險分析和風(fēng)險控制,它把軟件項(xiàng)目分解成一個個小項(xiàng)目。每個小項(xiàng)目都標(biāo)識一個或多個主要風(fēng)險,直到所有的主要風(fēng)險因素都被確定。 14、 甘特圖: 它是對項(xiàng)目的描述,顯示在活動的并行性,并用顏色或圖標(biāo)來指明完成的程度。使用該圖,項(xiàng)目經(jīng)理能夠了解哪些活動可并行進(jìn)行,那些活動處于關(guān)鍵路徑上。15、聚合和組合的區(qū)別這兩個比較難理解,重點(diǎn)說一下。聚合和組合的區(qū)別在于:聚合關(guān)系是“has-a”關(guān)系,組合關(guān)系是“conta

38、ins-a”關(guān)系;聚合關(guān)系表示整體與部分的關(guān)系比較弱,而組合比較強(qiáng);聚合關(guān)系中代表部分事物的對象與代表聚合事物的對象的生存期無關(guān),一旦刪除了聚合對象不一定就刪除了代表部分事物的對象。組合中一旦刪除了組合對象,同時也就刪除了代表部分事物的對象。實(shí)例分析聯(lián)通客戶響應(yīng)OSS。系統(tǒng)有故障單、業(yè)務(wù)開通、資源核查、割接、業(yè)務(wù)重保、網(wǎng)絡(luò)品質(zhì)性能等功能模塊。現(xiàn)在我們抽出部分需求做為例子講解。1 通知分為一般通知、割接通知、重保通知。這個是繼承關(guān)系。2 NoticeService和實(shí)現(xiàn)類NoticeServiceImpl是實(shí)現(xiàn)關(guān)系。3 NoticeServiceImpl通過save方法的參數(shù)引用Notice,是

39、依賴關(guān)系。同時調(diào)用了BaseDao完成功能,也是依賴關(guān)系。4 割接通知和故障單之間通過中間類(通知電路)關(guān)聯(lián),是一般關(guān)聯(lián)。5 重保通知和預(yù)案庫間是聚合關(guān)系。因?yàn)轭A(yù)案庫可以事先錄入,和重保通知沒有必然聯(lián)系,可以獨(dú)立存在。在系統(tǒng)中是手工從列表中選擇。刪除重保通知,不影響預(yù)案。6 割接通知和需求單之間是聚合關(guān)系。同理,需求單可以獨(dú)立于割接通知存在。也就是說刪除割接通知,不影響需求單。7 通知和回復(fù)是組合關(guān)系。因?yàn)榛貜?fù)不能獨(dú)立于通知存在。也就是說刪除通知,該條通知對應(yīng)的回復(fù)也要級聯(lián)刪除。綜合論述題目。 例如:為什么軟件維護(hù)費(fèi)用一直居高不下?困難何在?克服困難的途徑何在?-自己總結(jié))首先是沒有充分認(rèn)識到

40、軟件維護(hù)的重要性和困難;其次是沒有系統(tǒng)地考慮軟件維護(hù)問題,例如從需求分析和系統(tǒng)設(shè)計時就考慮到維護(hù)的問題;還有管理問題和技術(shù)問題,例如文檔與編碼難于理解,又難于修改。文檔質(zhì)量差和不全,開發(fā)技術(shù)陳舊。例如:試闡述設(shè)計軟件用戶界面應(yīng)該考慮的問題。答:(1)隱喻:可以認(rèn)識和學(xué)習(xí)的基本術(shù)語。 (2)頭腦中的模型:數(shù)據(jù)、功能、任務(wù)和角色的組織和表示。(3)模型的導(dǎo)航規(guī)則:如何在數(shù)據(jù),功能,活動和角色中移動。 (4)外觀:系統(tǒng)向用戶傳輸信息的外觀特性。(5)感覺:向用戶提供有吸引力的體驗(yàn)和交互技術(shù)。(6)文化問題:信仰,價值觀、道德規(guī)范、傳統(tǒng)、風(fēng)俗和傳說。(7)用戶偏好:個人喜好。漢語版軟件需求分析與設(shè)計教

41、學(xué)內(nèi)容回顧C(jī)hapter01 1、SE的定義軟件工程的定義:軟件工程是一種系統(tǒng)工程,不只包括對技術(shù)問題的分析與解決,還包括對開發(fā)過程和給參與者分配合適的角色等方面的管理。2、軟件工程的目的確保軟件具有技術(shù)高質(zhì)量和實(shí)際商業(yè)用途 3、現(xiàn)代軟件工程大致包含的幾個階段及各個階段文檔 4、 什么是抽象?基于某種歸納水平的問題描述。它使我們將注意力集中在問題的關(guān)鍵方面而非細(xì)節(jié)。(30頁) 5、什么是軟件過程?A:定義: 軟件開發(fā)活動中的各種組織及規(guī)范方法。是指一套關(guān)于項(xiàng)目的階段、狀態(tài)、方法、技術(shù)和開發(fā)、維護(hù)軟件的人員以及相關(guān)Artifacts(計劃、文檔、模型、編碼、測試、手冊等)組成6、軟件過程的重要性

42、是什么?軟件過程構(gòu)成了軟件項(xiàng)目管理控制的基礎(chǔ),并且創(chuàng)建了一個環(huán)境以便于技術(shù)方法的采用、工作產(chǎn)品(模型、文檔、報告、表格等)的產(chǎn)生、里程碑的創(chuàng)建、質(zhì)量的保證、正常變更的正確管理。1 有效的軟件過程可以提高組織的生產(chǎn)能力:有效的軟件過程可以改善我們對軟件的維護(hù):7、包含幾個階段?初始級可重復(fù)級定義級定量管理級(不斷)優(yōu)化級企業(yè)改進(jìn)的開展的目的是通過把改進(jìn)轉(zhuǎn)變?yōu)橐环N系統(tǒng)性的行為方式去持續(xù)地和計量地改進(jìn)企如果要用簡單的一句話來表達(dá)從一級到高一級所需要的努力的話,我們可以有:從一級到二級的轉(zhuǎn)化:規(guī)范化過程從二級到三級的轉(zhuǎn)化:標(biāo)準(zhǔn)化、穩(wěn)定的過程從三級到四級的轉(zhuǎn)化:可預(yù)測的過程從四級到五級的轉(zhuǎn)化:

43、繼續(xù)不斷地改進(jìn)過程8、什么是重用?重用 定義: 共性 à可重用的部件à 新的項(xiàng)目 重復(fù)采用以前開發(fā)的軟件系統(tǒng)中具有共性的部件, 用到新的開發(fā)項(xiàng)目中去.9、軟件工程的定義:軟件工程是一種系統(tǒng)工程,不只包括對技術(shù)問題的分析與解決,還包括對開發(fā)過程和給參與者分配合適的角色等方面的管理。10、說明錯誤、缺陷、失敗的含義與聯(lián)系。答:錯誤,是進(jìn)行軟件開發(fā)過程中人為出錯造成的。 缺陷:當(dāng)人們在進(jìn)行軟件開發(fā)活動的過程中出現(xiàn)錯誤時,就會引起缺陷。失?。菏侵赶到y(tǒng)違背了它應(yīng)有的行為??赡軙谙到y(tǒng)交付前或交付后被發(fā)現(xiàn),也可能在測試過程中或者在運(yùn)行和維護(hù)過程中被發(fā)現(xiàn)。(1)單個錯誤可能產(chǎn)生多個缺陷,

44、并且缺陷可能駐留在任何開發(fā)或維護(hù)的產(chǎn)品中,如設(shè)計人員可能錯誤理解某個需求,創(chuàng)建處于需求分析人員和用戶實(shí)際意圖不相符的設(shè)計,這個設(shè)計缺陷是一種錯誤的編碼,可能導(dǎo)致其他缺陷,像不正確的代碼或用戶手冊中不正確的描述等。(2)并非每一個缺陷都對應(yīng)于一個失敗,如果不執(zhí)行缺陷代碼或者不進(jìn)入某個特定狀態(tài)缺陷就不會引起失敗。(3)缺陷是系統(tǒng)的內(nèi)部視圖,這是從開發(fā)人員角度看問題而失敗是系統(tǒng)的外部視圖,它是用戶所看到的問題。11、軟件質(zhì)量應(yīng)從哪幾個方面來衡量?論述之。答:(1)產(chǎn)品的質(zhì)量:用戶在測量軟件質(zhì)量的時候,用戶從故障數(shù)目和故障類型等外部特性進(jìn)行評價,如將失敗分為次要的、主要的、災(zāi)難性的。設(shè)計和編寫代碼傾向

45、于考慮內(nèi)部特性,尤其是,從業(yè)人員通常會把故障的數(shù)目和類型看作產(chǎn)品質(zhì)量的證據(jù)。(2)生產(chǎn)該產(chǎn)品的過程的質(zhì)量:任何一個活動出了差錯都會影響產(chǎn)品的質(zhì)量,對過程進(jìn)行建模的優(yōu)點(diǎn)是我們能夠研究它,并尋找方法對他加以改進(jìn)。(3)在產(chǎn)品將使用的商業(yè)環(huán)境背景下的產(chǎn)品的質(zhì)量商業(yè)應(yīng)用背景下的軟件質(zhì)量(商業(yè)質(zhì)量) A: 技術(shù)價值與商業(yè)價值的聯(lián)系與區(qū)別 技術(shù)價值: 技術(shù)指標(biāo) (軟件速度,正確運(yùn)行的時間,以及可維護(hù)性 , 等等. ) 商業(yè)價值: 機(jī)構(gòu)對軟件是否與其戰(zhàn)略利益相吻合的一種價值評估誤區(qū): 軟件的技術(shù)質(zhì)量將自動轉(zhuǎn)化為軟件的商業(yè)價值 目標(biāo): 將技術(shù)價值與商業(yè)價值統(tǒng)一起來B、 改進(jìn)過程所帶來的商業(yè)價值(或者說對商業(yè)質(zhì)

46、量的影響) X: 傳統(tǒng)公式 : 投資回報(ROI) =資本金+收益+風(fēng)險回報 Y: 軟件生產(chǎn): (將工作量視為投資,而非單純的代價或金錢) 投資 = 生產(chǎn)軟件的正常消耗 + 過程改進(jìn)的消耗 涉及回報的九種投資 : 培訓(xùn); 進(jìn)度控制; 風(fēng)險管理與控制; 質(zhì)量監(jiān)督與管理; 過程控制; 成本管理; 生產(chǎn)率改進(jìn); 客戶管理; 軟件商業(yè)化.C:軟件行業(yè)投資回報的定義(Fig1.6) (一般行業(yè))Dollars-à effort(針對軟件業(yè))12、使現(xiàn)代SE實(shí)踐發(fā)生變化的(七個)關(guān)鍵因素是什么?(1)商用產(chǎn)品投入市場時間的緊迫性。(2)計算技術(shù)在經(jīng)濟(jì)中的轉(zhuǎn)變:更低的硬件成本,更高的開發(fā)和維護(hù)成本

47、。(3)功能強(qiáng)大的桌面計算的可用性。 (4)廣泛的局域網(wǎng)和廣域網(wǎng)。(5)面向?qū)ο蠹夹g(shù)的采用及其有效性。 (6)使用窗口、圖標(biāo)、菜單和指示器的圖形用戶界面(7)軟件開發(fā)瀑布模型的不可預(yù)測性。Chaoter02什么是軟件過程?軟件過程的重要性是什么? (P45-46)1、原型的概念原型: 一種部分開發(fā)的產(chǎn)品,用來讓用戶和開發(fā)者共同研究,提出意見,為最終產(chǎn)品定型2、瀑布模型及各階段文檔,優(yōu)缺點(diǎn)?答:需求分析 SRS 系統(tǒng)設(shè)計 系統(tǒng)設(shè)計文檔如軟件結(jié)構(gòu)圖 程序設(shè)計 模塊功能算法和數(shù)據(jù)描述文檔 編碼 源程序和注釋 單元測試和集成測試 測試報告 系統(tǒng)測試 測試報告 驗(yàn)收測試 測試報告 運(yùn)行維護(hù) 維護(hù)報告優(yōu)點(diǎn)

48、:(1)它的簡單性使得開發(fā)人員很容易向不熟悉軟件開發(fā)的客戶作出解釋。 (2)明確的表示出為了下一階段的開發(fā),那些中間產(chǎn)品是必須的。用里程碑明確表示出一個階段的結(jié)束,并伴隨著提交物。 (3)瀑布模型是其他復(fù)雜模型的基礎(chǔ)。 缺點(diǎn):最大的問題是它不能反映實(shí)際代碼的開發(fā)過程。 面臨軟件變動時, 該模型無法處理實(shí)際過程中的重復(fù)開發(fā)問題-軟件是一個創(chuàng)造的過程,不是一個制造的過程。 文檔轉(zhuǎn)換有困難。 沒有將開發(fā)看成一個迭代的過程。 難以適應(yīng)商業(yè)環(huán)境和操作環(huán)境的變化。3、論述分階段開發(fā)模型的含義, 分類及特點(diǎn)。答:分階段開發(fā)模型:系統(tǒng)被設(shè)計成部分提交, 每次用戶只能得到部分功能, 而其他部分處于開發(fā)過程中.分類:增量開發(fā):系統(tǒng)需求按照功能分成若干子系統(tǒng),開始建造的版本是規(guī)模小的、部分功能的系統(tǒng),后續(xù)版本添加包含新功能的子系統(tǒng),最后版本是包含全部功能的子系統(tǒng)集。 迭代開發(fā):系統(tǒng)開始就提供了整體功能框架,后續(xù)版本陸續(xù)增強(qiáng)各個子系統(tǒng),最后版本使各個子系統(tǒng)的功能達(dá)到最強(qiáng).4、在所有的軟件開發(fā)過程模型中,你認(rèn)為哪些過程給予你最大的靈活性以應(yīng)對需求的變更?1設(shè)計對于分析模型應(yīng)該是可跟蹤的:軟件的模塊可能被映射到多個需求上。2設(shè)計結(jié)構(gòu)應(yīng)該盡可能的模擬實(shí)際問題。3設(shè)計應(yīng)該表現(xiàn)出一致性。4不要把設(shè)計當(dāng)成編寫代碼。 5在創(chuàng)建設(shè)計時就應(yīng)該能夠評估質(zhì)量。6評審設(shè)計以減少語義性的錯誤。Chapter035、

溫馨提示

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

最新文檔

評論

0/150

提交評論