第一篇：軟件工程考試總結(jié)范文

第一章 軟件工程學(xué)概述

1.軟件：是程序、數(shù)據(jù)及相關(guān)文檔的完整集合。

2.軟件危機(jī)：是指在計(jì)算機(jī)軟件開(kāi)發(fā)和維護(hù)過(guò)程中所遇到的一系列嚴(yán)重問(wèn)題。

3.產(chǎn)生軟件危機(jī)的原因

A.與軟件本身的特點(diǎn)有關(guān)。管理和控制軟件開(kāi)發(fā)過(guò)程相當(dāng)困難，軟件較難維護(hù)，它規(guī)模龐大，程序復(fù)雜性將隨著

程序規(guī)模的增加而呈指數(shù)上升。

B.和軟件開(kāi)發(fā)與維護(hù)的方法不正確有關(guān)。

4.消除軟件危機(jī)的途徑：

A.應(yīng)該對(duì)計(jì)算機(jī)軟件有一個(gè)正確認(rèn)識(shí)。

B.認(rèn)識(shí)到軟件開(kāi)發(fā)不是某種個(gè)體勞動(dòng)的神秘技巧，而應(yīng)該是一種組織良好、管理嚴(yán)密、各類人員協(xié)同配合、共同

發(fā)完成的工程項(xiàng)目。

C.充分吸取和借鑒人類長(zhǎng)期以來(lái)從事各種工程項(xiàng)目所積累的行之有效的原理、概念、技術(shù)和方法。

D.開(kāi)發(fā)和使用更好的軟件工具。

5.軟件工程：是指導(dǎo)計(jì)算機(jī)軟件開(kāi)發(fā)和維護(hù)的一門(mén)工程學(xué)科。

6.軟件工程的特征：

A.軟件工程關(guān)注于大型程序的構(gòu)造。

B.軟件工程的中心課題是控制復(fù)雜性。

C.軟件經(jīng)常變化。

D.開(kāi)發(fā)軟件的效率非常重要。

E.和諧的合作是開(kāi)發(fā)軟件的關(guān)鍵。

F.軟件必須有效地支持它的用戶。

G.在軟件工程領(lǐng)域中通常由具有一種文化背景的人替具有另一種文化背景的人創(chuàng)造產(chǎn)品。

7.軟件工程學(xué)的方法學(xué)3要素：方法、工具、過(guò)程。

方法學(xué)：傳統(tǒng)方法學(xué)、面向?qū)ο蠓椒▽W(xué)。

8.軟件生命周期：

軟件定義、軟件開(kāi)發(fā)、運(yùn)行維護(hù)三個(gè)過(guò)程。

軟件定義包括問(wèn)題定義、可行性研究、需求分析3個(gè)階段。

軟件開(kāi)發(fā)包括總體設(shè)計(jì)、詳細(xì)設(shè)計(jì)、編碼和單元測(cè)試、綜合測(cè)試4個(gè)階段。

9.軟件過(guò)程：是為了獲得高質(zhì)量軟件所需要完成的一系列任務(wù)的框架，它規(guī)定了完成各項(xiàng)任務(wù)的工作步驟。

10.過(guò)程模型：瀑布模型、快速原型模型、增量模型、螺旋模型、噴泉模型。

瀑布模型：優(yōu)點(diǎn)：1.可強(qiáng)迫開(kāi)發(fā)員采用規(guī)范的方法2.嚴(yán)格地規(guī)定了每個(gè)階段必須提交的文件3.要求每個(gè)階段交出的所有產(chǎn)品都必須經(jīng)過(guò)質(zhì)量保證小組的仔細(xì)驗(yàn)證。缺點(diǎn)：傳統(tǒng)的瀑布模型過(guò)于理想化，是由文檔驅(qū)動(dòng)的。

快速原型模型：通過(guò)快速構(gòu)建起一個(gè)可在計(jì)算機(jī)上運(yùn)行的原型系統(tǒng)，讓用戶試用原型并收集用戶反饋意見(jiàn)的方法，獲取用戶真正的需要。

增量模型：優(yōu)點(diǎn)：能在較短時(shí)間內(nèi)向用戶提交可完成部分工作的產(chǎn)品；逐步增加產(chǎn)品功能可以使用戶有較充實(shí)的時(shí)

間學(xué)習(xí)和適應(yīng)新產(chǎn)品，從而減少一個(gè)全新的軟件可能給客戶組織帶來(lái)的沖擊。

螺旋模型：優(yōu)點(diǎn)：對(duì)可選方案和約束條件的強(qiáng)調(diào)有利于已有軟件的重用；減少了過(guò)多測(cè)試；維護(hù)只是螺旋模型中另

一個(gè)周期。

第二章 可行性研究（確定問(wèn)題是否能解決）

1.可行性研究的三個(gè)方面：技術(shù)可行性：使用現(xiàn)有的技術(shù)能否實(shí)現(xiàn)該系統(tǒng)。

經(jīng)濟(jì)可行性：該系統(tǒng)的經(jīng)濟(jì)效應(yīng)能否超過(guò)它的開(kāi)發(fā)成本。

操作可行性：系統(tǒng)的操作方式在這個(gè)組織內(nèi)是否行得通。

2.系統(tǒng)流程圖：概括的描繪物理系統(tǒng)的傳統(tǒng)工具。表達(dá)的是數(shù)據(jù)在系統(tǒng)各部件之間流動(dòng)的情況。

基本符號(hào)：處理、輸入輸出、連接、換頁(yè)連接、數(shù)據(jù)流。

3.數(shù)據(jù)流圖DFD：一種圖形化技術(shù)，它描繪信息流和數(shù)據(jù)從輸入移動(dòng)到輸出的過(guò)程中所經(jīng)受的變換。描繪邏輯過(guò)程。

基本符號(hào)：數(shù)據(jù)的源點(diǎn)/終點(diǎn)、變換數(shù)據(jù)的處理、數(shù)據(jù)存儲(chǔ)、數(shù)據(jù)流。

數(shù)據(jù)流圖的命名：先為數(shù)據(jù)流命名，再為處理命名。

數(shù)據(jù)字典：是關(guān)于數(shù)據(jù)信息的集合，也就是對(duì)數(shù)據(jù)流圖中包含的所有元素的定義的集合。

數(shù)據(jù)字典的內(nèi)容：數(shù)據(jù)流、數(shù)據(jù)流分量（數(shù)據(jù)元素）、數(shù)據(jù)存儲(chǔ)、處理。

定義數(shù)據(jù)的方法：順序、選擇、重復(fù)。

符號(hào)：=等價(jià)于、+和、[ ]或、{ }重復(fù)、（）可選

4.成本估計(jì)技術(shù)：代碼行技術(shù)、任務(wù)分解技術(shù)、自動(dòng)估計(jì)成本技術(shù)。

第三章 需求分析（系統(tǒng)必須做什么）

1.需求分析的任務(wù)：

A.確定對(duì)系統(tǒng)的綜合要求。

B.分析系統(tǒng)的數(shù)據(jù)要求。

C.導(dǎo)出系統(tǒng)的邏輯模型。

D.修正系統(tǒng)開(kāi)發(fā)計(jì)劃。

2.與用戶溝通獲取需求的方法：

A.訪談。

B.面向數(shù)據(jù)流自頂向下求精。（結(jié)構(gòu)化分析方法）

C.簡(jiǎn)易的應(yīng)用規(guī)格說(shuō)明技術(shù)。

D.快速建立軟件原型。

3.實(shí)體—聯(lián)系圖（E-R圖）包含的3種信息：數(shù)據(jù)對(duì)象（矩形）、屬性（圓角矩形）、聯(lián)系（菱形）。

4.狀態(tài)轉(zhuǎn)換圖：通過(guò)描繪系統(tǒng)的狀態(tài)及引起系統(tǒng)狀態(tài)轉(zhuǎn)換的事件，來(lái)表示系統(tǒng)的行為。

狀態(tài)：是任何可被觀察到的系統(tǒng)行為模式，有初態(tài)、中間狀態(tài)、終態(tài)。一張狀態(tài)圖中只能有一個(gè)初態(tài)，0到多個(gè)終態(tài)。

事件：引起系統(tǒng)做動(dòng)作或（和）轉(zhuǎn)換狀態(tài)的控制信息。

符號(hào)：初態(tài)（實(shí)心圓）、終態(tài)（一對(duì)同心圓，內(nèi)圓為實(shí)心圓）、狀態(tài)轉(zhuǎn)換（箭頭）。

5.該階段可用到的其他圖形：層次方框圖、Warnier圖、IPO圖、注：E—R圖建立數(shù)據(jù)模型，數(shù)據(jù)流圖建立功能模型，狀態(tài)圖建立行為模型。

第五章 總體設(shè)計(jì)（概括的說(shuō)系統(tǒng)應(yīng)該如何實(shí)現(xiàn)）將軟件需求轉(zhuǎn)化為數(shù)據(jù)結(jié)構(gòu)和軟件的系統(tǒng)結(jié)構(gòu)。

1.基本任務(wù)：A.劃分出組成系統(tǒng)的物理元素：程序、文件、數(shù)據(jù)庫(kù)、人工過(guò)程和文檔等。

B.設(shè)計(jì)軟件的結(jié)構(gòu)。也就是要確定系統(tǒng)中每個(gè)程序由哪些模塊組成，以及這些模塊相互間的關(guān)系。

2.階段：系統(tǒng)設(shè)計(jì)階段，確定系統(tǒng)的具體實(shí)現(xiàn)方案。

結(jié)構(gòu)設(shè)計(jì)階段：確定軟件結(jié)構(gòu)。

典型的總體設(shè)計(jì)過(guò)程包括9個(gè)步驟：

設(shè)想供選擇的方案，選取合理的方案，推薦最佳方案，功能分解，設(shè)計(jì)軟件結(jié)構(gòu)，設(shè)計(jì)數(shù)據(jù)庫(kù)，制定

測(cè)試計(jì)劃，書(shū)寫(xiě)文檔，審查和復(fù)審。

3.設(shè)計(jì)原理：模塊化、抽象、逐步求精、信息隱藏和局部化、模塊獨(dú)立。

模塊：由邊界元素限定的相鄰程序元素的序列，而且有一個(gè)總體標(biāo)識(shí)符代替它。

模塊化：就是把程序劃分成獨(dú)立命名且可獨(dú)立訪問(wèn)的模塊，每個(gè)模塊完成一個(gè)子功能，把這些模塊集成起來(lái)構(gòu)成一個(gè)整體，可以完成指定的功能滿足用戶需求。

抽象：就是抽出事物的本質(zhì)特征而暫時(shí)不考慮它們的細(xì)節(jié)。

逐步求精：為了能集中精力解決主要問(wèn)題而盡量推遲對(duì)問(wèn)題細(xì)節(jié)的考慮?？煽醋魇且豁?xiàng)把一個(gè)時(shí)期內(nèi)必須解決的種種問(wèn)題按優(yōu)先級(jí)排序的技術(shù)。

信息隱藏：設(shè)計(jì)和確定的模塊，使得一個(gè)模塊內(nèi)包含的信息對(duì)于不需要這些信息的模塊來(lái)說(shuō)，是不能訪問(wèn)的。局部化：把一些關(guān)系密切的軟件元素物理地放得彼此靠近。

模塊的獨(dú)立程度的定性標(biāo)準(zhǔn)度量：內(nèi)聚、耦合。

耦合：是對(duì)一個(gè)軟件結(jié)構(gòu)內(nèi)不同模塊之間互連程度的度量。耦合由低程度到高程度分為：數(shù)據(jù)耦合、控制耦合、特征耦合、公共環(huán)境耦合、內(nèi)容耦合。

內(nèi)聚：標(biāo)志著一個(gè)模塊內(nèi)各個(gè)元素彼此結(jié)合的緊密程度。底內(nèi)聚有偶然內(nèi)聚、邏輯內(nèi)聚、時(shí)間內(nèi)聚。中內(nèi)聚包括

過(guò)程內(nèi)聚和通信內(nèi)聚。高內(nèi)聚包括順序內(nèi)聚和功能內(nèi)聚。

注：盡量使用數(shù)據(jù)耦合，少用控制耦合和特征耦合，限制公共環(huán)境耦合的范圍，完全不用內(nèi)容耦合。

4.啟發(fā)規(guī)則：

改進(jìn)軟件結(jié)構(gòu)提高模塊獨(dú)立性。模塊規(guī)模應(yīng)該適中。深度、寬度、扇出和扇入都應(yīng)適當(dāng)。模塊的作用域應(yīng)該在控制域之內(nèi)。力爭(zhēng)降低模塊接口的復(fù)雜程度。設(shè)計(jì)單入口單出口的模塊。模塊功能應(yīng)該可以預(yù)測(cè)。

深度：表示軟件結(jié)構(gòu)中控制的層數(shù)。

寬度：軟件結(jié)構(gòu)內(nèi)同一個(gè)層次上模塊總數(shù)的最大值。

扇出：一個(gè)模塊直接控制的模塊數(shù)。

扇入：表示一個(gè)模塊有多少個(gè)上級(jí)模塊直接調(diào)用它。

注：設(shè)計(jì)的很好的軟件結(jié)構(gòu)，通常頂層扇出比較高，中層扇出較少，底層扇入到公共的使用模塊中去。（底層模塊有高扇入）

5.面向數(shù)據(jù)流的設(shè)計(jì)方法：

目標(biāo)：給出設(shè)計(jì)軟件結(jié)構(gòu)的一個(gè)系統(tǒng)化的途徑。

概念：把信息流映射策劃那個(gè)軟件結(jié)構(gòu)，信息流的類型決定了映射的方。

信息流的類型：變換流和事務(wù)流。

變換流的特點(diǎn)：信息以“外部世界”的形式進(jìn)入軟件系統(tǒng)，經(jīng)處理以后再以“外部世界”的形式離開(kāi)系統(tǒng)。事務(wù)流的特點(diǎn)：數(shù)據(jù)沿輸入通路到達(dá)一個(gè)處理，該處理根據(jù)輸入數(shù)據(jù)的類型在若干個(gè)動(dòng)作序列中選出一個(gè)來(lái)執(zhí)行。

6.變換分析：把具有變換流特點(diǎn)的數(shù)據(jù)流圖按預(yù)先確定的模式映射成軟件結(jié)構(gòu)。

第一步：復(fù)查基本系統(tǒng)模型。

第二步：復(fù)查并精化數(shù)據(jù)流圖。

第三步：確定數(shù)據(jù)流圖是變換特性還是事務(wù)特性。

第四步：確定輸入流和輸出流的邊界，從而孤立出變化中心。

第五步：完成第一級(jí)分解。

第六步：完成第二次分解。

第七步：使用設(shè)計(jì)度量和啟發(fā)規(guī)則對(duì)第一次分割得到的軟件結(jié)構(gòu)進(jìn)一步精化。

第六章 詳細(xì)設(shè)計(jì)（怎樣具體地實(shí)現(xiàn)所要求的系統(tǒng)）即過(guò)程設(shè)計(jì)。通過(guò)對(duì)結(jié)構(gòu)表示進(jìn)行細(xì)化，得到軟

件詳細(xì)的數(shù)據(jù)結(jié)構(gòu)和算法。

1.詳細(xì)設(shè)計(jì)的內(nèi)容：

用圖表列出系統(tǒng)的每個(gè)程序，包括每個(gè)模塊和子程序名稱、標(biāo)識(shí)符、層出結(jié)構(gòu)關(guān)系。對(duì)程序的功能、性能、輸入、輸出、算法、流程、接口等進(jìn)行描述

內(nèi)容包括：程序描述：程序簡(jiǎn)要描述，意義和特點(diǎn)

功能：程序應(yīng)具備的功能

性能：精度、靈活性和時(shí)間特性等

輸入項(xiàng)

輸出項(xiàng)

2.人機(jī)界面設(shè)計(jì)指南：

一般交互指南：涉及信息顯示、數(shù)據(jù)輸入和系統(tǒng)整體控制。

保持一致性，提供有意義的反饋，在執(zhí)行有破壞性的動(dòng)作之前要求用戶確認(rèn)，允許取消絕大多數(shù)

操作，減少在兩次操作之間必須記憶的信息量，提高對(duì)話、移動(dòng)和思考的效率，允許犯錯(cuò)誤，按

功能對(duì)動(dòng)作分類，并據(jù)此設(shè)計(jì)屏幕布局，提供對(duì)用戶工作內(nèi)容敏感的幫助設(shè)施，用簡(jiǎn)單動(dòng)詞或動(dòng)

詞短語(yǔ)作為命令名。

信息顯示指南：只顯示與當(dāng)前工作內(nèi)容有關(guān)的信息，不要用數(shù)據(jù)淹沒(méi)用戶，使用一致標(biāo)記、標(biāo)準(zhǔn)的縮寫(xiě)和可預(yù)知的顏色，允許用戶保持可視化的語(yǔ)境，產(chǎn)生有意義的出錯(cuò)信息，使用大小寫(xiě)、縮進(jìn)和文本分組以幫

助理解，使用窗口分隔不同類型的信息，使用“模擬”顯示表示信息，以使信息更容易被用戶提取，高效率地使用顯示屏。

數(shù)據(jù)輸入指南：盡量減少用戶的輸入動(dòng)作，保持信息顯示和數(shù)據(jù)輸入之間的一致性，允許用戶自定義輸入，交互

應(yīng)該是靈活的，并且可調(diào)整成用戶最喜歡的輸入方式，交互應(yīng)該是靈活的，并且可調(diào)整成用戶最喜

歡的輸入方式，讓用戶控制交互流，對(duì)所有輸入動(dòng)作都提供幫助，消除冗余的輸入。

3.過(guò)程設(shè)計(jì)工具：分為圖形、表格、語(yǔ)言。有程序流程圖、盒圖（N—S圖）、PAD圖（問(wèn)題分析圖）、判定表、判

定樹(shù)、過(guò)程設(shè)計(jì)語(yǔ)言（PDL或偽碼）。

4.程序復(fù)雜程度的定量度量：

McCabe方法：根據(jù)程序控制流的復(fù)雜程度度量度量程序的復(fù)雜度，結(jié)果稱為環(huán)形復(fù)雜度。

流圖：實(shí)質(zhì)上是“退化了的”程序流程圖。有結(jié)點(diǎn)（圓）、邊（箭頭）。

區(qū)域：邊和結(jié)點(diǎn)圍成的面積。

5.計(jì)算環(huán)形復(fù)雜度的方法：

A.區(qū)域數(shù)=環(huán)形復(fù)雜度。

B.流圖G的環(huán)形復(fù)雜度V(G)=E—N+2，E為邊數(shù)，N為結(jié)點(diǎn)數(shù)。

C.V(G)=P+1，P為判定結(jié)點(diǎn)的數(shù)目。

第七章 實(shí)現(xiàn)（編碼和測(cè)試）

1.軟件測(cè)試：就是在軟件投入運(yùn)行前，對(duì)軟件需求分析、設(shè)計(jì)規(guī)格說(shuō)明和編碼的最終復(fù)審，是軟件質(zhì)量保證的關(guān)鍵

步驟。

2.測(cè)試的目的：在軟件投入生產(chǎn)性運(yùn)行之前，盡可能多現(xiàn)的發(fā)軟件在運(yùn)行中的錯(cuò)誤。

3.測(cè)試方法：黑盒測(cè)試、白盒測(cè)試。

黑盒測(cè)試：已經(jīng)知道產(chǎn)品應(yīng)有的功能，檢驗(yàn)每個(gè)功能是否都能正常使用。也叫功能測(cè)試。

白盒測(cè)試：已經(jīng)知道產(chǎn)品的內(nèi)部工作過(guò)程，檢驗(yàn)這些過(guò)程是否按照規(guī)格說(shuō)明書(shū)的規(guī)定正常進(jìn)行。也叫

結(jié)構(gòu)測(cè)試。

以黑盒測(cè)試為主，白盒測(cè)試為輔。

4.測(cè)試步驟：模塊測(cè)試、子系統(tǒng)測(cè)試、系統(tǒng)測(cè)試、驗(yàn)收測(cè)試，平行測(cè)試。

5.白盒測(cè)試技術(shù)：

邏輯覆蓋：是對(duì)一系列測(cè)試過(guò)程的總稱，這組測(cè)試過(guò)程逐漸進(jìn)行越來(lái)越完整的通路測(cè)試。

種類：語(yǔ)句覆蓋、判定覆蓋、條件覆蓋、判定/條件覆蓋、條件組合覆蓋、點(diǎn)覆蓋、邊覆蓋、路徑覆蓋。

基本路徑測(cè)試：

一、根據(jù)過(guò)程設(shè)計(jì)結(jié)果畫(huà)出相應(yīng)流圖。

二、計(jì)算流圖的環(huán)境復(fù)雜度。

三、確定線路獨(dú)立路徑的基本組合。獨(dú)立路徑是指至少引入程序的一個(gè)新處理語(yǔ)句集合或一

個(gè)新條件路徑，就是至少包含一條在定義該路徑之前不曾用過(guò)的邊。

獨(dú)立路徑數(shù)=環(huán)形復(fù)雜度

四、設(shè)計(jì)可強(qiáng)制執(zhí)行基本集合中每條路徑的測(cè)試用例。

6.調(diào)試：在測(cè)試發(fā)現(xiàn)錯(cuò)誤之后排除錯(cuò)誤的過(guò)程。

7.軟件維護(hù)：在軟件已交付使用之后，為了改正錯(cuò)誤或者滿足新的需要而修改軟件的過(guò)程。分為改進(jìn)性維護(hù)、適應(yīng)性

維護(hù)、完善性維護(hù)、預(yù)防性維護(hù)。

決定軟件可維護(hù)性的因素：可理解性、可測(cè)試性、可修改性、可移植性、可重用性。

8.軟件項(xiàng)目管理：通過(guò)計(jì)劃、組織和控制等一系列活動(dòng)，合理的配置和使用各種資源，以達(dá)到既定目標(biāo)的過(guò)程。管理內(nèi)容：估算軟件規(guī)模，工作量估算、進(jìn)度計(jì)劃、人員組織、質(zhì)量保證、軟件配置管理、能力成熟度模型。

第二篇：軟件工程考試總結(jié)

2.說(shuō)明結(jié)構(gòu)化程序設(shè)計(jì)的主要思想是什么？ 答：（1）自頂向下、逐步求精的程序設(shè)計(jì)方法（2分）（2）使用3種基本控制結(jié)構(gòu)、單入口、單出口來(lái)構(gòu)造程序。結(jié)構(gòu)化程序設(shè)計(jì)是實(shí)現(xiàn)該目標(biāo)的關(guān)鍵技術(shù)之一，它指導(dǎo)人們用良好的思想方法開(kāi)發(fā)易于理解、易于驗(yàn)證的程序。結(jié)構(gòu)化程序設(shè)計(jì)方法的基本要點(diǎn)是： 1）采用自頂向下、逐步求精的程序設(shè)計(jì)方法2）使用三種基本控制結(jié)構(gòu)構(gòu)造程序 3）主程序員組的組織形式。

3.軟件測(cè)試包括哪些步驟？說(shuō)明這些步驟的測(cè)試對(duì)象是什么？答：（1）單元測(cè)試，測(cè)試對(duì)象單元模塊（2）集成測(cè)試，測(cè)試對(duì)象為組裝后的程序模塊（3）確認(rèn)測(cè)試，測(cè)試對(duì)象為可運(yùn)行的目標(biāo)軟件系統(tǒng)

4.需求分析與軟件設(shè)計(jì)二個(gè)階段任務(wù)的主要區(qū)別是什么？ 答：需求分析定義軟件的用戶需求，即定義待開(kāi)發(fā)軟件能做什么軟件設(shè)計(jì)定義軟件的實(shí)現(xiàn)細(xì)節(jié)以滿足用戶需求，即研究如何實(shí)現(xiàn)軟件 5.說(shuō)明軟件測(cè)試和調(diào)試的目的有何區(qū)別？

答：測(cè)試的目的是判斷和發(fā)現(xiàn)軟件是否有錯(cuò)誤 調(diào)試的目的是定位軟件錯(cuò)誤并糾正錯(cuò)誤。

7、白盒法：該方法把測(cè)試對(duì)象看作一個(gè)打開(kāi)的盒子，測(cè)試人員須了解程序的內(nèi)部結(jié)構(gòu)和處理過(guò)程，以檢查處理過(guò)程的細(xì)節(jié)為基礎(chǔ)，對(duì)程序中盡可能多的邏輯路徑進(jìn)行測(cè)試，檢查內(nèi)部控制結(jié)構(gòu)和數(shù)據(jù)結(jié)構(gòu)是否有錯(cuò)，實(shí)際的運(yùn)行狀態(tài)與預(yù)期的狀態(tài)是否一致。白盒法也不可能進(jìn)行窮舉測(cè)試。

8、黑盒法：該方法把被測(cè)試對(duì)象看成一個(gè)黑盒子，測(cè)試人員完全不考慮程序的內(nèi)部結(jié)構(gòu)和處理過(guò)程，只在軟件接口處進(jìn)行測(cè)試，依照需求規(guī)格說(shuō)明書(shū)，檢查程序是否滿足功能要求。因此，黑盒測(cè)試又稱為功能測(cè)試或數(shù)據(jù)驅(qū)動(dòng)測(cè)試

9、面向?qū)ο笤O(shè)計(jì)：是把分析階段得到的需求轉(zhuǎn)變成符合成本和質(zhì)量要求的、抽象的系統(tǒng)實(shí)現(xiàn)方案的過(guò)程。或者說(shuō)，面向?qū)ο笤O(shè)計(jì)就是用面向?qū)ο笥^點(diǎn)建立求解域模型的過(guò)程。

10、結(jié)構(gòu)化設(shè)計(jì)：面向數(shù)據(jù)流的設(shè)計(jì)是以需求分析階段產(chǎn)生的數(shù)據(jù)流圖為基礎(chǔ)，按一定的步驟映射成軟件結(jié)構(gòu)，因此又稱結(jié)構(gòu)化設(shè)計(jì)（SD）。

11、結(jié)構(gòu)化分析：是根據(jù)分解與抽象的原則，按照系統(tǒng)中數(shù)據(jù)處理的流程，用數(shù)據(jù)圖來(lái)建立系統(tǒng)的功能模型，從而完成需求分析工作

結(jié)構(gòu)化方法是一種傳統(tǒng)的軟件開(kāi)發(fā)方法，它是由結(jié)構(gòu)化分析、結(jié)構(gòu)化設(shè)計(jì)和結(jié)構(gòu)化程序設(shè)計(jì)三部分有機(jī)組合而成的。它的基本思想：把一個(gè)復(fù)雜問(wèn)題的求解過(guò)程分階段進(jìn)行，而且這種分解是自頂向下，逐層分解，使得每個(gè)階段處理的問(wèn)題都控制在人們?nèi)菀桌斫夂吞幚淼姆秶鷥?nèi)。

結(jié)構(gòu)化分析方法(Structured Method，結(jié)構(gòu)化方法)是強(qiáng)調(diào)開(kāi)發(fā)方法的結(jié)構(gòu)合理性以及所開(kāi)發(fā)軟件的結(jié)構(gòu)合理性的軟件開(kāi)發(fā)方法。結(jié)構(gòu)是指系統(tǒng)內(nèi)各個(gè)組成要素之間的相互聯(lián)系、相互作用的框架。結(jié)構(gòu)化開(kāi)發(fā)方法提出了一組提高軟件結(jié)構(gòu)合理性的準(zhǔn)則，如分解與抽象、模塊獨(dú)立性、信息隱蔽等。針對(duì)軟件生存周期各個(gè)不同的階段，它有結(jié)構(gòu)化分析(SA)、結(jié)構(gòu)化設(shè)計(jì)(SD)和結(jié)構(gòu)化程序設(shè)計(jì)(SP)等方法。

結(jié)構(gòu)化分析方法是面向____數(shù)據(jù)流___進(jìn)行需求分析的方法。結(jié)構(gòu)化分析方法使用____數(shù)據(jù)字典______與____加工說(shuō)明___來(lái)描述。

13、系統(tǒng)流程圖：是描述物理系統(tǒng)的傳統(tǒng)工具，它用圖形符號(hào)來(lái)表示系統(tǒng)中的各個(gè)元素，例如人工處理、數(shù)據(jù)處理、數(shù)據(jù)庫(kù)、文件、設(shè)備等。它表達(dá)了系統(tǒng)中各個(gè)元素之間的信息流動(dòng)的情況。4.軟件生存周期

軟件生存周期是指軟件產(chǎn)品從考慮其概念開(kāi)始到該軟件產(chǎn)品交付使用，直至最終退役為止的整個(gè)過(guò)程，一般包括計(jì)劃、分析、設(shè)計(jì)、實(shí)現(xiàn)、測(cè)試、集成、交付、維護(hù)等階段。

2、采用黑盒技術(shù)設(shè)計(jì)測(cè)試用例有哪幾種方法？這些方法各有什么特點(diǎn)？ ㈠等價(jià)類劃分。等價(jià)類劃分是將輸入數(shù)據(jù)域按有效的或無(wú)效的（也稱合理的或不合理的）劃分成若干個(gè)等價(jià)類，測(cè)試每個(gè)等價(jià)類的代表值就等于對(duì)該類其它值的測(cè)試。㈡邊界值分析。該方法是將測(cè)試邊界情況作為重點(diǎn)目標(biāo)，選取正好等于，剛剛大于或剛剛小于邊界值的情況，根據(jù)這些情況選擇測(cè)試用例。㈢錯(cuò)誤推測(cè)。錯(cuò)誤推測(cè)法沒(méi)有確定的步驟，憑檢驗(yàn)進(jìn)行。它的基本思想是列出程序中可能發(fā)生錯(cuò)誤的情況，根據(jù)這些情況選擇測(cè)試用例

3,Gantt圖是歷史悠久，應(yīng)用廣泛的制定進(jìn)度的計(jì)劃的工具。形象的描繪任務(wù)分解情況，以及每個(gè)子任務(wù)的開(kāi)始時(shí)間和結(jié)束時(shí)間，具有直觀簡(jiǎn)明，容易掌握，容易繪制的優(yōu)點(diǎn)。缺點(diǎn)1不能顯式描繪各項(xiàng)作業(yè)依賴關(guān)系2進(jìn)度的關(guān)鍵部分不明確，難于確定哪些是主攻和主控3有潛力的部分不明確，造成浪費(fèi)。工程網(wǎng)絡(luò) 0分軟件危機(jī)定義和產(chǎn)生的因有哪些？

當(dāng)軟件開(kāi)發(fā)技術(shù)的進(jìn)步不能跟上硬件技術(shù)的進(jìn)步，未能滿足發(fā)展的要求，致軟件開(kāi)發(fā)中遇到的問(wèn)題找不到解決的辦法，使問(wèn)題積累起來(lái)，形成了尖銳的矛盾，因而導(dǎo)致了軟件危機(jī)。

1）軟件日益復(fù)雜和龐大（2）軟件開(kāi)發(fā)管理困難和復(fù)雜（3）軟件開(kāi)發(fā)技術(shù)落后(4）生產(chǎn)方式落后（5）開(kāi)發(fā)工具落后（6）軟件開(kāi)發(fā)費(fèi)用不斷增加

1、可行性研究的任務(wù)是什么？ 首先需要進(jìn)行概要的分析研究，初步確定項(xiàng)目的規(guī)模和目標(biāo)，確定項(xiàng)目的約束和限制，把他們清楚地列舉出來(lái)。然后，分析員進(jìn)行簡(jiǎn)要的需求分析，抽象出該項(xiàng)目的邏輯結(jié)構(gòu)，建立邏輯模型。從邏輯模型出發(fā)，經(jīng)過(guò)壓縮的設(shè)計(jì)，探索出若干種可供選擇的主要解決方法，對(duì)每種解決方法都要研究它的可行性，可從以下三個(gè)方面分析研究每種解決方法的可行性。㈠技術(shù)可行性：對(duì)要開(kāi)發(fā)項(xiàng)目的功能、性能、限制條件進(jìn)行分析，確定在現(xiàn)有的資源條件下，技術(shù)風(fēng)險(xiǎn)有多大，項(xiàng)目是否能實(shí)現(xiàn)。㈡經(jīng)濟(jì)可行性：進(jìn)行開(kāi)發(fā)成本的估算以及了解取得效益的評(píng)估，確定要開(kāi)發(fā)的項(xiàng)目是否值得投資開(kāi)發(fā)。㈢社會(huì)可行性：要開(kāi)發(fā)的項(xiàng)目是否存在任何侵犯、妨礙等責(zé)任問(wèn)題，要開(kāi)發(fā)項(xiàng)目的運(yùn)行方式在用戶組織內(nèi)是否行得通，現(xiàn)有管理制度、人員素質(zhì)、操作方式是否可行。

2、需求分析的任務(wù)是什么？

需求分析的任務(wù)是確定待開(kāi)發(fā)的軟件系統(tǒng)“做什么”。具體任務(wù)包括確定軟件系統(tǒng)的功能需求、性能需求和運(yùn)行環(huán)境約束，編制軟件需求規(guī)格說(shuō)明書(shū)、軟件系統(tǒng)的驗(yàn)收測(cè)試準(zhǔn)則和初步的用戶手冊(cè)。

需求分析是指，開(kāi)發(fā)人員要準(zhǔn)確理解用戶的要求，進(jìn)行細(xì)致的調(diào)查分析，將用戶非形式的需求陳述轉(zhuǎn)化為完整的需求定義，再由需求定義轉(zhuǎn)換到相應(yīng)的形式功能規(guī)約（需求規(guī)格說(shuō)明）的過(guò)程。

3、概要設(shè)計(jì)的定義和基本任務(wù)是什么？

進(jìn)入了設(shè)計(jì)階段，要把軟件“做什么”的邏輯模型變換為“怎么做”的物理模型，即著手實(shí)現(xiàn)軟件的需求，并將設(shè)計(jì)的結(jié)果反應(yīng)在“設(shè)計(jì)規(guī)格說(shuō)明書(shū)”文檔中，所以軟件設(shè)計(jì)是一個(gè)把軟件需求轉(zhuǎn)換為軟件表示的過(guò)程，最初這種表示只是描述了軟件的總的體系結(jié)構(gòu)，稱為軟件的概要設(shè)計(jì)或結(jié)構(gòu)設(shè)計(jì)。①采用某種設(shè)計(jì)方法，將一個(gè)復(fù)雜的系統(tǒng)按功能劃分成模塊。②確定每個(gè)模塊的功能。③確定模塊之間的調(diào)用關(guān)系。④確定模塊之間的接口，即模塊之間傳遞的信息。⑤評(píng)價(jià)模塊結(jié)構(gòu)的質(zhì)量。⑵數(shù)據(jù)結(jié)構(gòu)及數(shù)據(jù)庫(kù)設(shè)計(jì)，漢數(shù)據(jù)結(jié)構(gòu)的設(shè)計(jì)及數(shù)據(jù)庫(kù)的設(shè)計(jì)。⑶編寫(xiě)概要設(shè)計(jì)文檔。主要有：概要設(shè)計(jì)說(shuō)明書(shū)；數(shù)據(jù)庫(kù)設(shè)計(jì)說(shuō)明書(shū)；用戶手冊(cè)；修訂測(cè)試計(jì)劃。⑷評(píng)審

4、詳細(xì)設(shè)計(jì)的基本任務(wù)是什么？有哪幾種描述方法？ 詳細(xì)設(shè)計(jì)是軟件設(shè)計(jì)的第二階段，其基本任務(wù)有：為每個(gè)模塊進(jìn)行詳細(xì)的算法設(shè)計(jì)；為模塊內(nèi)的數(shù)據(jù)結(jié)構(gòu)進(jìn)行設(shè)計(jì)；對(duì)數(shù)據(jù)庫(kù)進(jìn)行物理設(shè)計(jì)，即確定數(shù)據(jù)庫(kù)的物理結(jié)構(gòu)；其它設(shè)計(jì)，根據(jù)軟件系統(tǒng)類型，還可能要進(jìn)行代碼設(shè)計(jì)、輸入/輸出格式設(shè)計(jì)、人機(jī)對(duì)話設(shè)計(jì)；編寫(xiě)詳細(xì)設(shè)計(jì)說(shuō)明書(shū)；評(píng)審。詳細(xì)描述處理過(guò)程常用三種工具：圖形、表格和語(yǔ)言。如結(jié)構(gòu)化程序流程圖、盒圖和問(wèn)題分析圖。IPO圖也是詳細(xì)設(shè)計(jì)的主要工具之一。表格工具如判定表可作為詳細(xì)設(shè)計(jì)中描述邏輯條件復(fù)雜的算法。過(guò)程設(shè)計(jì)語(yǔ)言（PDL）是一種用于描述模塊算法設(shè)計(jì)和處理細(xì)節(jié)的語(yǔ)言工具。

能力成熟度模型（CMM）用于評(píng)價(jià)軟件機(jī)構(gòu)的軟件過(guò)程能力成熟度德模型 文檔：程序開(kāi)發(fā)使用和維護(hù)所常用的圖文資料

2衡量模塊獨(dú)立性的兩個(gè)定性的標(biāo)準(zhǔn)是內(nèi)聚和耦合。耦合是指對(duì)一個(gè)軟件結(jié)構(gòu)內(nèi)不同模塊彼此之間互相依賴的緊密程度。內(nèi)聚標(biāo)志一個(gè)模塊內(nèi)各元素彼此的緊密1簡(jiǎn)述兩種不同集成測(cè)試的比較：自頂向下測(cè)試法主要，優(yōu)點(diǎn)是不需要測(cè)試驅(qū)動(dòng)程序，能夠在測(cè)試階段的早期實(shí)現(xiàn)并驗(yàn)證系統(tǒng)的主要功能，而且能在早期發(fā)現(xiàn)上層模塊的接口的錯(cuò)誤，自頂向下的缺點(diǎn)是需要存根程序，可能遇到與此相聯(lián)系的測(cè)試?yán)щy，底層關(guān)鍵模塊中的錯(cuò)誤發(fā)現(xiàn)的較晚，而且用這種方法不能展開(kāi)人力。自底向下正好相反。

影響維護(hù)的因素：可理解性，可測(cè)試性，可修改性，可移植性，重用性

總體設(shè)計(jì)的九個(gè)階段：1設(shè)想供選擇的方案，2選擇合適的方案，3推薦最佳方案，4功能分解，5設(shè)計(jì)軟件結(jié)構(gòu) 6設(shè)計(jì)數(shù)據(jù)庫(kù)，7制定測(cè)試計(jì)劃，8書(shū)寫(xiě)文檔，9審查和復(fù)查

軟件工程：是指導(dǎo)計(jì)算機(jī)軟件開(kāi)發(fā)和維護(hù)的工程學(xué)科，采用工程概念，原理，技術(shù)和方法來(lái)開(kāi)發(fā)和維護(hù)軟件，吧經(jīng)過(guò)實(shí)踐考驗(yàn)而證明的管理技術(shù)和當(dāng)前能夠得到的最好的技術(shù)方法結(jié)合起來(lái)。要素是方法，工具，過(guò)程 系統(tǒng)流程圖是描繪物理系統(tǒng)的傳統(tǒng)工具，他的基本思想是用圖形符號(hào)以黑盒子形式描繪組成系統(tǒng)的每個(gè)部件。表達(dá)的是數(shù)據(jù)在系統(tǒng)各部件的流動(dòng)情況，而不是對(duì)數(shù)據(jù)進(jìn)行加工處理的控制過(guò)程。

3個(gè)子模型和5個(gè)層次：靜態(tài)結(jié)構(gòu)（對(duì)象模型）交互次序（動(dòng)態(tài)模型）數(shù)據(jù)變換（功能模型）主題層，類和對(duì)象層，結(jié)構(gòu)層，屬性層，服務(wù)層

結(jié)構(gòu)化方法有結(jié)構(gòu)化分析、結(jié)構(gòu)化設(shè)計(jì)、結(jié)構(gòu)化程序設(shè)計(jì)構(gòu)成，它是一種面向數(shù)據(jù)流的開(kāi)發(fā)方法。

結(jié)構(gòu)化設(shè)計(jì)對(duì)數(shù)據(jù)流有兩種分析方法，他們是變換分析設(shè)計(jì)和事務(wù)分析設(shè)計(jì)。質(zhì)量保證是有計(jì)劃的和系統(tǒng)性的活動(dòng)，它對(duì)部件或產(chǎn)品滿足確定的技術(shù)需求提供足夠的信心。

軟件質(zhì)量保證措施（SQA）基于非執(zhí)行的測(cè)試（復(fù)審和評(píng)審）基于執(zhí)行的測(cè)試（軟件測(cè)試）和程序正確性證明

數(shù)據(jù)字典的內(nèi)容：數(shù)據(jù)流，數(shù)據(jù)流分量，數(shù)據(jù)存儲(chǔ)，數(shù)據(jù)處理

數(shù)據(jù)流圖的內(nèi)容：數(shù)據(jù)流，數(shù)據(jù)存儲(chǔ)，數(shù)據(jù)處理，數(shù)據(jù)的原點(diǎn)和終點(diǎn)。

數(shù)據(jù)流圖（DFD）是一種圖形化技術(shù)，他描繪信息流和數(shù)據(jù)從輸入移動(dòng)到輸出的過(guò)程中經(jīng)受的變換。

可行性研究中，數(shù)據(jù)流圖，系統(tǒng)流程圖，數(shù)據(jù)字典

需求分析：訪談，實(shí)體聯(lián)系圖，狀態(tài)轉(zhuǎn)換圖，層次方框圖，Warnier圖，IPO圖 總體設(shè)計(jì)：層次圖和HIPO圖，結(jié)構(gòu)圖

詳細(xì)設(shè)計(jì)：過(guò)程設(shè)計(jì)中有程序流程圖，盒圖，PAD圖，判定表，判定樹(shù)，過(guò)程設(shè)計(jì)語(yǔ)言。面向數(shù)據(jù)結(jié)構(gòu)的設(shè)計(jì)方法：Jackson圖程序復(fù)雜度的定量MaCabe方法和Halstead方法

設(shè)計(jì)人機(jī)界面的過(guò)程中4個(gè)問(wèn)題，系統(tǒng)響應(yīng)時(shí)間，用戶幫助設(shè)施，出錯(cuò)信息處理和命令交互

耦合:盡量使用數(shù)據(jù)耦合少用控制耦合和特征耦合，限制公共環(huán)境耦合的范圍，完全不用內(nèi)容耦合

內(nèi)聚:偶然內(nèi)聚，邏輯內(nèi)聚時(shí)間內(nèi)聚，中內(nèi)聚有過(guò)程內(nèi)聚通信內(nèi)聚，高內(nèi)聚，功能內(nèi)聚，順序內(nèi)聚

模塊化就是把程序劃分為獨(dú)立命名且可獨(dú)立訪問(wèn)的模塊，每個(gè)模塊完成一個(gè)子功能，把這些模塊集起來(lái)構(gòu)成一個(gè)整體，可以完成指定的功能滿足用戶的需求 狀態(tài)轉(zhuǎn)換圖通過(guò)描繪系統(tǒng)狀態(tài)及引起系統(tǒng)狀態(tài)轉(zhuǎn)換的事件，來(lái)表示系統(tǒng)的行為

5.軟件配置管理，簡(jiǎn)稱SCM，它用于整個(gè)軟件工程過(guò)程。其主要目標(biāo)是：標(biāo)識(shí)變更；控制變更；確保變更正確地實(shí)現(xiàn)；報(bào)告有關(guān)變更。SCM是一組管理整個(gè)軟件生存期各階段中變更的活動(dòng)。

Jackson的畫(huà)法：

1定輸入和輸出數(shù)據(jù)結(jié)構(gòu)

2分析確定在輸入和輸出數(shù)據(jù)結(jié)構(gòu)中有對(duì)應(yīng)關(guān)系的數(shù)據(jù)單元，最高層輸入和輸出相對(duì)應(yīng)等有其他。

3從數(shù)據(jù)結(jié)構(gòu)圖導(dǎo)出程序結(jié)構(gòu)圖

4列出所有的操作和條件，并把它們分配到程序結(jié)構(gòu)圖的適當(dāng)位置。5最后用偽碼表示程序處理過(guò)程 盒圖的特點(diǎn)：

1功能域明確，可以從盒圖上一眼看出來(lái) 2不可能任意轉(zhuǎn)移控制

3很容易確定局部和全程數(shù)據(jù)的作用域

4很容易表現(xiàn)嵌套關(guān)系，也可以表示模塊的層次結(jié)構(gòu)。PAD圖：

1使用表示結(jié)構(gòu)化控制結(jié)構(gòu)的PAD符號(hào)結(jié)構(gòu)所設(shè)計(jì)出來(lái)的程序必然是結(jié)構(gòu)化程序。

2PAD圖所描繪的程序結(jié)構(gòu)非常清晰

3PAD圖表現(xiàn)程序邏輯，易讀，易懂，易記 4，容易將PAD圖轉(zhuǎn)換成高級(jí)語(yǔ)言源程序

5即可用于表示程序邏輯，也可用于描繪數(shù)據(jù)結(jié)構(gòu) 6PAD的符號(hào)支持自頂向下，逐步求精方法

第三篇：軟件工程考試

軟件工程是用工程、科學(xué)和數(shù)學(xué)的原則與方法研制、維護(hù)計(jì)算機(jī)軟件的有關(guān)技術(shù)和管理方法 軟件工程三要素：方法、工具和過(guò)程

軟件工程的內(nèi)容：軟件開(kāi)發(fā)技術(shù)和軟件開(kāi)發(fā)管理兩個(gè)方面

可行性研究方面:技術(shù)可行性經(jīng)濟(jì)可行性操作可行性法律可行性

IT項(xiàng)目可行性研究審計(jì)的概念:事前對(duì)IT項(xiàng)目從技術(shù)和經(jīng)濟(jì)兩個(gè)方而進(jìn)行的詳細(xì)論證，涉及

數(shù)據(jù)字典是關(guān)于數(shù)據(jù)的信息的集合，也就是對(duì)數(shù)據(jù)流圖中包含的所有元素的定義的集合.包括（1）數(shù)據(jù)流（2）數(shù)據(jù)元素（3）數(shù)據(jù)存儲(chǔ)（4）處理 驗(yàn)證軟件需求的正確性：（1）一致性：所有需求必須是一致的，任何一條需求不能和其他需求互相矛盾。(2)完整性： 需求必須是完整的，規(guī)格說(shuō)明書(shū)應(yīng)該包括用戶需要的每一個(gè)功能或性能(3)現(xiàn)實(shí)性：指定的需求應(yīng)該是用現(xiàn)有的硬件技術(shù)和軟件技術(shù)基本上可以實(shí)現(xiàn)的。對(duì)硬件技術(shù)的進(jìn)步可以做些預(yù)測(cè)，對(duì)軟件技術(shù)的進(jìn)步則很難做出預(yù)測(cè)，只能從現(xiàn)有技術(shù)水平出發(fā)判斷需求的現(xiàn)實(shí)性。(4)有效性： 必須證明需求是正確有效的，確實(shí)能解決用戶面對(duì)的問(wèn)題。

軟件設(shè)計(jì)過(guò)程有：1數(shù)據(jù)設(shè)計(jì)：將實(shí)體 – 關(guān)系圖中描述的對(duì)象和關(guān)系，以及數(shù)據(jù)詞典中描述的詳細(xì)數(shù)據(jù)內(nèi)容轉(zhuǎn)化為數(shù)據(jù)結(jié)構(gòu)的定義。2總體結(jié)構(gòu)（系統(tǒng)結(jié)構(gòu)）設(shè)計(jì)： 定義軟件系統(tǒng)各主要成份之間的關(guān)系。3過(guò)程設(shè)計(jì)： 把結(jié)構(gòu)成份轉(zhuǎn)換成軟件的過(guò)程性描述。4接口設(shè)計(jì)：定義軟件內(nèi)部各成份之間、軟件與其它協(xié)同系統(tǒng)之間及軟件與用戶之間的交互機(jī)制。軟件設(shè)計(jì)方法：結(jié)構(gòu)化設(shè)計(jì)方法(SD)面向數(shù)據(jù)結(jié)構(gòu)的設(shè)計(jì)方法(JSD方法)面向?qū)ο蟮脑O(shè)計(jì)方法(OOD)

軟件設(shè)計(jì)分兩個(gè)階段完成：結(jié)構(gòu)設(shè)計(jì)：結(jié)構(gòu)設(shè)計(jì)是總體設(shè)計(jì)階段的任務(wù)。結(jié)構(gòu)設(shè)計(jì)確定程序由哪些模塊組成，以及這些模塊之間的關(guān)系。過(guò)程設(shè)計(jì)：確定每個(gè)模塊的處理過(guò)程

結(jié)構(gòu)程序設(shè)計(jì):一種設(shè)計(jì)程序的技術(shù)，它采用自頂向下逐步求精的設(shè)計(jì)方法和單入口單出口的控制結(jié)構(gòu)

軟件測(cè)試：是根據(jù)軟件開(kāi)發(fā)各階段的文檔資料和程序的內(nèi)部結(jié)構(gòu)，精心設(shè)計(jì)一組“高產(chǎn)”的測(cè)試用例，利用這些實(shí)例執(zhí)行程序，找出軟件中潛在的各種錯(cuò)誤和缺陷的過(guò)程 黑盒法（黑盒技術(shù)是把被測(cè)試對(duì)象看成一個(gè)黑盒子，測(cè)試人員完全不考慮程序的內(nèi)部結(jié)構(gòu)和處理過(guò)程，只在軟件的接口處進(jìn)行測(cè)試，依據(jù)需求規(guī)格說(shuō)明書(shū)，檢查程序是否滿足功能要求 白盒法（白盒技術(shù)）：是把測(cè)試對(duì)象看作一個(gè)打開(kāi)的盒子，測(cè)試人員須了解程序的內(nèi)部結(jié)構(gòu)和處理過(guò)程，以檢查處理過(guò)程的細(xì)節(jié)為基礎(chǔ)，對(duì)程序中盡可能多的邏輯路徑進(jìn)行測(cè)試，檢查內(nèi)部控制結(jié)構(gòu)和數(shù)據(jù)結(jié)構(gòu)是否有錯(cuò)，實(shí)際的運(yùn)行狀態(tài)與預(yù)期的狀態(tài)是否一致。驅(qū)動(dòng)模塊：驅(qū)動(dòng)模塊是用來(lái)模擬被測(cè)模塊的上級(jí)調(diào)用模塊的模塊，功能要比真正的上級(jí)模塊簡(jiǎn)單得多，它只完成接受測(cè)試數(shù)據(jù)，以上級(jí)模塊調(diào)用被測(cè)模塊的格式驅(qū)動(dòng)被測(cè)模塊，接收被測(cè)模塊的測(cè)試結(jié)果并輸出。

樁模塊：樁模塊用來(lái)代替被測(cè)試模塊所調(diào)用的模塊。它的作用是返回被測(cè)模塊所需的信息。單元測(cè)試：：?jiǎn)卧獪y(cè)試指對(duì)源程序中每一個(gè)程序單元進(jìn)行測(cè)試，檢查各個(gè)模塊是否正確實(shí)現(xiàn)規(guī)定的功能，從而發(fā)現(xiàn)模塊在編碼中或算法中的錯(cuò)誤。

集成測(cè)試：是指在單元測(cè)試的基礎(chǔ)上，將所有模塊按照設(shè)計(jì)要求組裝成一個(gè)完整的系統(tǒng)進(jìn)行的測(cè)試，故也稱組裝測(cè)試或聯(lián)合測(cè)試。

確認(rèn)測(cè)試：又稱有效性測(cè)試。是為了檢查軟件的功能與性能是否與需求規(guī)格說(shuō)明書(shū)中確定的指標(biāo)相符合所進(jìn)行的測(cè)試

單元測(cè)試內(nèi)容①模塊接口②局部數(shù)據(jù)結(jié)構(gòu)③重要的執(zhí)行路徑④錯(cuò)誤處理⑤邊界條件。調(diào)試的目的確定錯(cuò)誤的原因和位置，并改正錯(cuò)誤，因此調(diào)試也稱為糾錯(cuò)(Debug)調(diào)試的技術(shù)手段有簡(jiǎn)單的調(diào)試方法、歸納法、演繹法和回溯法等 軟件可維護(hù)性：軟件能夠被理解、校正、適應(yīng)及增強(qiáng)功能的容易程度

為了保證軟件的可維護(hù)性，需要做哪些質(zhì)量保證檢查?（1）在檢查點(diǎn)進(jìn)行檢查。檢查點(diǎn)是指軟件開(kāi)發(fā)的每一個(gè)階段的終點(diǎn)。（2）驗(yàn)收檢查。驗(yàn)收檢查是一個(gè)特殊的檢查點(diǎn)的檢查，它是把軟件從開(kāi)發(fā)轉(zhuǎn)移到維護(hù)的最后一次檢查。（3）周期性的維護(hù)檢查（4）對(duì)軟件包的檢查。好的文檔有以下幾方面的作用：（1）好的文檔能提高程序的可閱讀性，但壞的文檔比沒(méi)有文檔更壞；（2）好的文檔意味著簡(jiǎn)明性，風(fēng)格的一致性，容易修改；（3）程序編碼中應(yīng)該有必要的注釋以提高程序的可理解性；（4）程序越長(zhǎng)、越復(fù)雜，則它對(duì)文檔的需求也越迫切 軟件維護(hù)的流程：定維護(hù)申請(qǐng)報(bào)告。審查申請(qǐng)報(bào)告并批準(zhǔn)。進(jìn)行維護(hù)并做詳細(xì)記錄。復(fù)審 面向?qū)ο蠓椒▽W(xué)的出發(fā)點(diǎn)和基本原則:是盡可能模擬人類習(xí)慣的思維方式，使開(kāi)發(fā)軟件的方法與過(guò)程盡可能接近人類認(rèn)識(shí)世界解決問(wèn)題的方法與過(guò)程.描述問(wèn)題的問(wèn)題域與實(shí)現(xiàn)解法的求解域在結(jié)構(gòu)上盡可能一致。

對(duì)象是用面向?qū)ο蠓椒▽W(xué)開(kāi)發(fā)軟件時(shí)對(duì)客觀世界實(shí)體的抽象，它是由描述實(shí)體屬性的數(shù)據(jù)及可以對(duì)這些數(shù)據(jù)施加的所有操作封裝在一起構(gòu)成的統(tǒng)一體。傳統(tǒng)的數(shù)據(jù)是用傳統(tǒng)方法學(xué)開(kāi)發(fā)軟件時(shí)對(duì)客觀世界實(shí)體的抽象，但是，種抽象是不全面的：數(shù)據(jù)只能描述實(shí)體的靜態(tài)屬性，不能描述實(shí)體的動(dòng)態(tài)行為。必須從外界對(duì)數(shù)據(jù)施加操作，才能改變數(shù)據(jù)實(shí)現(xiàn)實(shí)體應(yīng)有的行為。對(duì)象與傳統(tǒng)數(shù)據(jù)有本質(zhì)區(qū)別，它不是被動(dòng)地等待外界對(duì)它施加操作，相反，它是進(jìn)行處理的主體。必須發(fā)消息請(qǐng)求對(duì)象主動(dòng)地執(zhí)行它的某些操作，處理它的私有數(shù)據(jù)，而不能直接從外界對(duì)它的私有數(shù)據(jù)進(jìn)行操作。

對(duì)象模型的五個(gè)層次：主題層（也稱為范疇層），類—&—對(duì)象層，結(jié)構(gòu)層，屬性層，服務(wù)層

面向?qū)ο髮?shí)現(xiàn)主要包括兩項(xiàng)工作：把面向?qū)ο笤O(shè)計(jì)結(jié)果，翻譯成用某種程序語(yǔ)言書(shū)寫(xiě)的面向?qū)ο蟪绦?；測(cè)試并調(diào)試面向?qū)ο蟮某绦?/p>

面向?qū)ο筌浖臏y(cè)試分四個(gè)層次進(jìn)行：算法層、類層、主題層、系統(tǒng)層

項(xiàng)目管理者的目標(biāo): 定義全部項(xiàng)目任務(wù)，識(shí)別出關(guān)鍵任務(wù)，跟蹤關(guān)鍵任務(wù)的進(jìn)展?fàn)顩r，以保證能及時(shí)發(fā)現(xiàn)拖延進(jìn)度的情況

軟件配置管理主要有5項(xiàng)任務(wù)： 標(biāo)識(shí) 版本控制 變化控制 配置審計(jì) 報(bào)告 軟件工程實(shí)施項(xiàng)目管理的目的 ： 在于它能夠幫助我們進(jìn)行系統(tǒng)性思考，并切實(shí)可行地進(jìn)行全局性安排，同時(shí)也可以為項(xiàng)目開(kāi)發(fā)的人力資源需求提供依據(jù)。

項(xiàng)目管理者的任務(wù)：確保信息系統(tǒng)項(xiàng)目符合預(yù)算和進(jìn)度要求，并確保交付的系統(tǒng)能夠達(dá)到預(yù)定的目標(biāo)

軟件的質(zhì)量保證活動(dòng)： 是確保軟件產(chǎn)品從誕生到消亡為止的所有階段的質(zhì)量的活動(dòng)。即為了確定、達(dá)到和維護(hù)需要的軟件質(zhì)量而進(jìn)行的所有有計(jì)劃、有系統(tǒng)的管理活動(dòng) 對(duì)編制高質(zhì)量文檔的要求：(1)針對(duì)性(2)精確性(3)清晰性(4)完整性(5)靈活性

第四篇：軟件工程考試

第一章 軟件工程學(xué)概述

1.軟件的概念，軟件的分類

答：軟件=程序+數(shù)據(jù)+文檔；

按規(guī)模分類：微型、小型、中型、大型、甚大形、極大型（6）

按性質(zhì)分類：系統(tǒng)軟件、支撐軟件、應(yīng)用軟件（3）

按工作方式分類：實(shí)時(shí)、分時(shí)、交互式、批處理（4）

按服務(wù)對(duì)象分類：項(xiàng)目軟件、產(chǎn)品軟件（2）

2.軟件危機(jī)產(chǎn)生的原因（2點(diǎn)），緩解軟件危機(jī)的途徑

答：和軟件本身的特點(diǎn)有關(guān)，和開(kāi)發(fā)軟件的方法不正確有關(guān)；

軟件工程；

3.軟件生命周期包含的活動(dòng)

答：?jiǎn)栴}定義、可行性研究、需求分析、總體設(shè)計(jì)、詳細(xì)設(shè)計(jì)、編碼、測(cè)試（8）

4.問(wèn)題定義階段的任務(wù)

答：確定軟件規(guī)模、性質(zhì)、目標(biāo)

5.常見(jiàn)的軟件開(kāi)發(fā)模型

瀑布模型：適用范圍是需求確定的軟件開(kāi)發(fā)，是描述結(jié)構(gòu)化的軟件開(kāi)發(fā)模型；

快速原型模型：適用范圍是需求不確定的軟件開(kāi)發(fā)；

噴泉模型：是描述面向?qū)ο蟮能浖_(kāi)發(fā)模型；

第二章 可行性研究

1.可行性研究從哪些方面進(jìn)行

答：經(jīng)濟(jì)，技術(shù)，法律，操作（4）

2.系統(tǒng)流圖SFD的作用

答：描述系統(tǒng)的工作過(guò)程，建立系統(tǒng)的業(yè)務(wù)模型

3.數(shù)據(jù)流圖DFD的作用，符號(hào)，畫(huà)法

答：描述系統(tǒng)的功能，建立系統(tǒng)的功能模型

符號(hào)：外部實(shí)體（正方形），處理（圓形），存儲(chǔ)（雙實(shí)線），數(shù)據(jù)流（單箭頭線）畫(huà)法：分離成分，分層畫(huà)DFD（頂層，0層，1層）

第三章 需求分析

1.結(jié)構(gòu)化的需求分析方法SA的原理

答：用DFD、DD進(jìn)行功能分析，建立系統(tǒng)的功能模型，用E-R進(jìn)行數(shù)據(jù)分析，建立系統(tǒng)的數(shù)據(jù)模型

第五章 總體設(shè)計(jì)

1.總體設(shè)計(jì)的原理

答：模塊化、抽象、逐步求精、信息隱藏和局部化、模塊獨(dú)立（5）

2.衡量模塊獨(dú)立的指標(biāo)

答：耦合，內(nèi)聚 3.總體設(shè)計(jì)的啟發(fā)規(guī)則（7點(diǎn)）

答：改進(jìn)軟件結(jié)構(gòu)提高模塊獨(dú)立性

模塊規(guī)模應(yīng)該適中

深度、寬度、扇出和扇入都應(yīng)適當(dāng)

模塊的作用域應(yīng)該在控制域之內(nèi)

力爭(zhēng)降低模塊接口的復(fù)雜程度

設(shè)計(jì)單入口單出口的模塊

模塊功能應(yīng)該可以預(yù)測(cè)

4.結(jié)構(gòu)化的設(shè)計(jì)方法SD的原理

答：將DFD映射成軟件結(jié)構(gòu)圖

第六章 詳細(xì)設(shè)計(jì)

1.用結(jié)構(gòu)化方法進(jìn)行開(kāi)發(fā)在詳細(xì)設(shè)計(jì)階段的任務(wù)

答：對(duì)模塊進(jìn)行設(shè)計(jì)，主要是設(shè)計(jì)模塊的界面和算法 2.結(jié)構(gòu)化程序設(shè)計(jì)SP的原則（7點(diǎn)）

答：采用自頂向下、逐步求精的設(shè)計(jì)方法

程序中用順序、選擇、多分支、while型循環(huán)、until型循環(huán)表示程序邏輯

每種控制結(jié)構(gòu)單入口、單出口

程序語(yǔ)句組成模塊，每個(gè)模塊單入口單出口

復(fù)雜的結(jié)構(gòu)用5種基本控制結(jié)構(gòu)組合嵌套實(shí)現(xiàn)

嚴(yán)格控制goto語(yǔ)句的使用，在下列情況可用：

在非結(jié)構(gòu)化的語(yǔ)言中，用goto語(yǔ)句實(shí)現(xiàn)結(jié)構(gòu)化的構(gòu)造

在某種可以改善而不是損害可讀性的情況下

不僅要注意程序的結(jié)構(gòu)化，還要注意數(shù)據(jù)結(jié)構(gòu)的合理化

3.判斷算法是否為結(jié)構(gòu)化的依據(jù)（3點(diǎn)）

答：由5種基本控制結(jié)構(gòu)組成；

每種控制結(jié)構(gòu)單入口單出口；

模塊單入口單出口

4.描述算法的工具

答：圖形工具：N-S圖，PAD圖，活動(dòng)圖

語(yǔ)言工具：PDL語(yǔ)言

表格工具：判定表、判定樹(shù)

5.算法環(huán)形復(fù)雜度的度量（流程圖-流圖-區(qū)域數(shù)）

答：流程圖-流圖轉(zhuǎn)換方法：

一個(gè)判斷框縮成一個(gè)點(diǎn)；

一個(gè)處理框縮成一個(gè)點(diǎn)；

一個(gè)順序處理序列縮成一個(gè)點(diǎn)；

判定框和與之相連的處理框縮成一個(gè)點(diǎn)；

真假分支的匯聚點(diǎn)增加一個(gè)點(diǎn)

第七章 實(shí)現(xiàn)

1.編碼的風(fēng)格（判斷題）

答：程序內(nèi)部的文檔：恰當(dāng)?shù)臉?biāo)識(shí)符（含義鮮明、縮寫(xiě)（必須保留第一個(gè)字母、輔音字母由于元音字母、字首優(yōu)于字尾）+注解）、適當(dāng)?shù)淖⒔猓ㄐ蜓孕宰⒔?、功能性注解）、程序的視覺(jué)組織（布局、空行、縮進(jìn)）

2.測(cè)試的概念、原則、方法，步驟

答：概念：用最少的時(shí)間和人力，找到軟件中盡可能多的錯(cuò)誤和缺陷

原則：

盡早的和不斷的測(cè)試；

事先要制定測(cè)試計(jì)劃，嚴(yán)格執(zhí)行學(xué)生計(jì)劃，排除測(cè)試的隨意性；

測(cè)試從小規(guī)模測(cè)試開(kāi)始，逐步進(jìn)行大規(guī)模測(cè)試；

充分注意測(cè)試中的“群集”現(xiàn)象；

“窮舉”測(cè)試不可能，應(yīng)該精心設(shè)計(jì)測(cè)試方案，使測(cè)試方案充分的覆蓋程序邏輯，以盡可能多的發(fā)現(xiàn)程序中的錯(cuò)誤；

測(cè)試方案應(yīng)該包含合理的輸入條件和不合理的輸入條件；

測(cè)試應(yīng)由獨(dú)立的第三方從事；

方法有黑盒測(cè)試和白盒測(cè)試

步驟是單元測(cè)試、集成測(cè)試、系統(tǒng)測(cè)試、確認(rèn)測(cè)試

3.白盒測(cè)試法有哪些，黑盒測(cè)試法有哪些

答：白盒測(cè)試法有：邏輯覆蓋法、基本路徑法覆蓋法、循環(huán)覆蓋法

黑盒測(cè)試法有：等價(jià)劃分法，分界值分析法，錯(cuò)誤推算法

4.用邏輯覆蓋法設(shè)計(jì)測(cè)試方案

5.黑盒測(cè)試技術(shù)的原理

答：在測(cè)試中，把程序看作一個(gè)不能打開(kāi)的黑盒子，在完全不考慮程序內(nèi)部結(jié)構(gòu)和內(nèi)部 特性的情況下，在程序接口進(jìn)行測(cè)試，它只檢查程序功能是否按照需求規(guī)格說(shuō)明書(shū)的規(guī)定正常使用，程序是否能適當(dāng)?shù)亟邮蛰斎霐?shù)據(jù)而產(chǎn)生正確的輸出信息。

6.可靠性的概念

答：軟件可靠性是程序在給定的事件間隔內(nèi)，按照規(guī)格說(shuō)明書(shū)的規(guī)定成功的運(yùn)行的概率；可靠性是衡量軟件質(zhì)量的指標(biāo)

7.可靠性的計(jì)算

第八章 維護(hù)

1.維護(hù)的概念、分類

答：在軟件已經(jīng)交付使用后，為了改正錯(cuò)誤或滿足新的需要而修改軟件的過(guò)程； 改正型維護(hù)，完善型維護(hù)，適應(yīng)型維護(hù)，預(yù)防型維護(hù)；

第九章 實(shí)戰(zhàn)

1.軟件有哪些開(kāi)發(fā)方法

答：結(jié)構(gòu)化的開(kāi)發(fā)方法、面向?qū)ο蟮拈_(kāi)發(fā)方法、傳統(tǒng)的開(kāi)發(fā)方法與面向?qū)ο蟮拈_(kāi)發(fā)方法相結(jié)合的實(shí)用開(kāi)發(fā)方法

2.傳統(tǒng)的軟件開(kāi)發(fā)方法的開(kāi)發(fā)步驟

答：?jiǎn)栴}定義，可行性研究，需求分析

業(yè)務(wù)分析（業(yè)務(wù)描述，建立業(yè)務(wù)模型）

功能分析（功能描述，功能模型）

數(shù)據(jù)分析

總體設(shè)計(jì)

建立軟件結(jié)構(gòu)

設(shè)計(jì)數(shù)據(jù)庫(kù)的表結(jié)構(gòu)

詳細(xì)設(shè)計(jì)

模塊設(shè)計(jì)

建立數(shù)據(jù)庫(kù)，錄入數(shù)據(jù)

實(shí)現(xiàn)

編碼，測(cè)試

3.面向?qū)ο蟮拈_(kāi)發(fā)方法的開(kāi)發(fā)步驟

答：?jiǎn)栴}定義，可行性研究

面向?qū)ο蟮姆治?/p>

業(yè)務(wù)分析

功能分析，建立系統(tǒng)的功能模型（參與者，需求結(jié)構(gòu)，功能模型）對(duì)象分析，建立系統(tǒng)初步的對(duì)象模型

用例分析，建立用例分析模型（順序圖，活動(dòng)圖）

擴(kuò)充和完善，建立系統(tǒng)完整的對(duì)象模型

面向?qū)ο蟮目傮w設(shè)計(jì)

擴(kuò)充和完善功能模型

軟件運(yùn)行環(huán)境

軟件架構(gòu)模型（軟件架構(gòu)模式，軟件分層架構(gòu)，軟件邏輯結(jié)構(gòu)）

擴(kuò)充和完善對(duì)象模型，建立平臺(tái)相關(guān)對(duì)象模型

用例設(shè)計(jì)模型（順序圖，活動(dòng)圖）

數(shù)據(jù)庫(kù)設(shè)計(jì)模型（數(shù)據(jù)庫(kù)的表結(jié)構(gòu)，數(shù)據(jù)庫(kù)的邏輯結(jié)構(gòu)）

界面設(shè)計(jì)模型（界面結(jié)構(gòu)模型，屏幕界面模型）

組件圖

部署模型

面向?qū)ο蟮脑敿?xì)設(shè)計(jì)

確定每個(gè)用例的實(shí)現(xiàn)算法

建立數(shù)據(jù)庫(kù)，錄入數(shù)據(jù)

面向?qū)ο髮?shí)現(xiàn)

編碼，測(cè)試

4.BCE、MVC是什么

答：BCE是用例分析模式、MVC是程序設(shè)計(jì)思想

5.傳統(tǒng)的開(kāi)發(fā)方法與面向?qū)ο蟮拈_(kāi)發(fā)方法相結(jié)合的實(shí)用開(kāi)發(fā)方法的開(kāi)發(fā)步驟 答：?jiǎn)栴}定義，可行性研究

需求分析

業(yè)務(wù)分析

功能分析

數(shù)據(jù)分析

動(dòng)態(tài)分析

總體設(shè)計(jì)

軟件運(yùn)行環(huán)境

軟件架構(gòu)模式（C/S B/S）

建立軟件結(jié)構(gòu)圖

設(shè)計(jì)數(shù)據(jù)庫(kù)的表結(jié)構(gòu)

詳細(xì)設(shè)計(jì)

模塊設(shè)計(jì)

建立數(shù)據(jù)庫(kù)，錄入數(shù)據(jù)

實(shí)現(xiàn)

編碼，測(cè)試

第五篇：軟件工程總結(jié)

1.Software is a product and can be manufactured using the same technologies used for other engineering artifacts Answer: b 2.WebApps are a mixture of print publishing and software development, making their development outside the realm of software engineering practice.Answer: b 3.Software engineering umbrella activities are only applied during the initial phases of software development projects.Answer: b 4.Planning ahead for software reuse reduces the cost and increases the value of the systems into which they are incorporated.Answer: a 5.The essence of software engineering practice might be described as understand the problem, plan a solution, carry out the plan, and examine the result for accuracy.Answer: a 6.In agile process models the only deliverable work product is the working program.Answer: b 7.A most software development projects are initiated to try to meet some business need.Answer: a 8.In general software only succeeds if its behavior is consistent with the objectives of its designers.Answer: b 9.Software processes can be constructed out of pre-existing software patterns to best meet the needs of a software project.Answer: a 10.Process technology tools allow software organizations to compress schedules by skipping unimportant activities.Answer: b 11.It is generally accepted that one cannot have weak software processes and create high quality end products.Answer: a 1.Requirements engineering is a generic process that does not vary from one software project to another.Answer: a 2.A stakeholder is anyone who will purchase the completed software system under development.Answer: b 3.It is relatively common for different customers to propose conflicting requirements, each arguing that his or her version is the right one.Answer: a 4.Developers and customers create use-cases to help the software team understand how different classes of end-users will use functions.Answer: a 5.Use-case actors are always people, never system devices.Answer: b 6.Analysis patterns facilitate the transformation of the analysis model into a design model by suggesting reliable solutions to common problems.Answer: a 7.In win-win negotiation, the customer’s needs are met even though the developer’s need may not be.Answer: b 8.In requirements validation the requirements model is reviewed to ensure its technical feasibility.Answer: b

1.Object-oriented domain analysis is concerned with the identification and specification of reusable capabilities within an application domain.Answer: a 2.In structured analysis models focus on the structure of the classes defined for a system along with their interactions.Answer: b 3.Creation and refinement of use cases if an important part of scenario-based modeling.Answer: a 4.It is important to consider alternative actor interactions when creating a preliminary use case.Answer: b 5.Brainstorming is one technique that may be used to derive a complete set of use case exceptions.Answer: a 6.In many cases there is no need to create a graphical representation of a usage scenario.Answer: a 7.One or more attributes of a data object must be defined as a key to allow the location of an instance of the data object.Answer: a 8.Attributes are chosen for an object by examining the problem statement and identifying the entities that appear to be related.Answer: b 9.An analysis package involves the categorization of analysis model elements into useful groupings.Answer: a 10.The data flow diagram must be augmented by min-spec that can serve as a guide the design of the software component that will implement the process.Answer: a 11.The UML sequence diagram show the order in which system events are processed.Answer: b 12.Analysis patterns are discovered, they are not explicitly created.Answer: a 13.It is not possible to justify the time required for WebApp requirements analysis.Answer: b 14.UML activity diagrams can be used to represent the user observable functionality delivered by the WebApp as well as the operations contained in each analysis class.Answer: a 15.Configuration analysis focuses on the architecture of the user’s web browsing environment.Answer: b 16.Content objects are extracted from use cases by examining the scenario description for direct or indirect content references.Answer: a 1.With thorough testing it is possible to remove all defects from a program prior to delivery to the customer.Answer: b 2.Program flow graphs are identical to program flowcharts.Answer: b 3.The cyclomatic complexity of a program can be computed directly from a PDL representation of an algorithm without drawing a program flow graph.Answer: a 4.Graph-based testing methods can only be used for object-oriented systems Answer: b 5.Equivalence testing divides the input domain into classes of data from which test cases can be derived to reduce the total number of test cases that must be developed.Answer: a 6.Boundary value analysis can only be used to do white-box testing.Answer: b 7.Orthogonal array testing enables the test designer to maximize the coverage of the test cases devised for relatively small input domains.Answer: a 8.Client/server architectures cannot be properly tested because network load is highly variable.Answer: b 1.The best representation of system architecture is an operational software prototype.Answer: b 2.The architectural representations can be an enabler for communication among project stakeholders.Answer: a 3.An architectural description is often documented using an architecture template.Answer: b 4.An architectural genre will often dictate the architectural approach that may used for the structure to be built.Answer: a 5.Before an architectural pattern can be chosen for use in a specific system it must have a code implementation to facilitate its reuse.Answer: b 6.Once selected, archetypes always need to be refined further as architectural design proceeds.Answer: a 7.Quantitative methods for assessing the quality of proposed architectural designs are readily available.Answer: b

Chapter 10 Self-Check Quiz

1.In the most general sense a component is a modular building block for computer software.a.True b.False

Answer: a(Section 10.1)

2.In the context of object-oriented software engineering a component contains

a.attributes and operations b.instances of each class c.roles for each actor(device or user)d.set of collaborating classes

Answer: d(Section 10.1.1)

3.In traditional software engineering modules must serve in which of the following roles?

a.Control component b.Infrastructure component c.Problem domain component d.All of the above

Answer: d(Section 10.1.2)

4.Software engineers always need to cerate components from scratch in order to meet customer expectations fully.a.True b.False

Answer: b(Section 10.1.3)

5.Which of the following is not one of the four principles used to guide component-level design?

a.Dependency Inversion Principle b.Interface Segregation Principle c.Open-Closed Principle d.Parsimonious Complexity Principle

Answer: d(Section 10.2.1)

6.The use of stereotypes can help identify the nature of components at the detailed design level.a.True b.False

Answer: a(Section 10.2.2)

7.Classes and components that exhibit functional, layer, or communicational cohesion are relatively easy to implement, test, and maintain.a.True b.False

Answer: a(Section 10.2.3)

8.Software coupling is a sign of poor architectural design and can always be avoided in every system.a.True b.False

Answer: b(Section 10.2.4)

9.WebApp content design at the component level focuses on content objects and the manner in which they interact.a.True b.False

Answer: b(Section 10.4.1)

10.A WebApp functional architecture describes the key functional components and how they interact with each other.a.True b.False

Answer: a(Section 10.4.2)

11.Which of these is a graphical notation for depicting procedural detail?

a.box diagram b.decision table c.ER diagram d.flowchart

Answer: d(Section 10.5.1)

12.A decision table should be used

a.to document all conditional statements b.to guide the development of the project management plan c.only when building an expert system d.when a complex set of conditions and actions appears in a component

Answer: d(Section 10.5.2)

13.A program design language(PDL)is often a

a.combination of programming constructs and narrative text b.legitimate programming language in its own right c.machine readable software development language d.useful way to represent software architecture

Answer: a(Section 10.5.3)

14.In component-based software engineering, the development team examines the requirements to see which are amenable to composition, rather than construction, before beginning detailed design tasks.a.True b.False

Answer: a(Section 10.6)

15.Which of the following is not one of the major activities of domain engineering?

a.analysis b.construction c.dissemination d.validation

Answer: d(Section 10.6.1)

16.Which of the following factors would not be considered during component qualification?

a.application programming interface(API)b.development and integration tools required c.exception handling d.testing equipment required

Answer: d(Section 10.6.2)

17.Which is the following is a technique used for component wrapping?

a.black-box wrapping b.clear-box wrapping c.gray-box wrapping d.white-box wrapping

Answer: b(Section 10.6.2)

18.Which of the following is not one of the issues that form a basis for design for reuse?

a.object-oriented programming b.program templates c.standard data d.standard interface protocols

Answer: a(Section 10.6.3)

19.In a reuse environment, library queries are often characterized using the ________ element of the 3C Model.a.concept b.content c.context d.all of the above

Answer: c(Section 10.6.4)

1.The importance of software design can be summarized in a single word a.b.c.d.Answer: d(Section 8.1)

2.Which of the following is not a characteristic common to all design methods?

a.configuration management b.functional component representation c.quality assessment guidelines d.refinement heuristics

Answer: a(Section 8.2.2)

3.Which of the following can be used to represent the architectural design of a piece of software?

a.Dynamic models b.Functional models c.Structural models d.All of the above

Answer: d(Section 8.3.2)

4.Design patterns are not applicable to the design of object-oriented software?

a.True b.False

Answer: b(Section 8.3.3)

5.Since modularity is an important design goal it is not possible to have too many modules in a proposed design.a.True b.False

Answer: b(Section 8.3.5)

6.Information hiding makes program maintenance easier by hiding data and procedure from unaffected parts of the program.accuracy complexity efficiency quality

a.True b.False

Answer: a(Section 8.3.6)

7.Cohesion is a qualitative indication of the degree to which a module

a.can be written more compactly.b.focuses on just one thing.c.is able to complete its function in a timely manner.d.is connected to other modules and the outside world.Answer: b(Section 8.3.7)

8.Coupling is a qualitative indication of the degree to which a module

a.can be written more compactly.b.focuses on just one thing.c.is able to complete its function in a timely manner.d.is connected to other modules and the outside world.Answer: d(Section 8.3.7)

9.When using structured design methodologies the process of stepwise refinement is unnecessary.a.True b.False

Answer: b(Section 8.3.8)

10.Software designs are refactored to allow the creation of software that is easier to integrate, easier to test, and easier to maintain.a.True b.False

Answer: a(Section 8.3.10)

11.Which of the following is not one of the five design class types

a.Business domain classes b.Entity classes c.Process classes d.User interface classes

Answer: b(Section 8.3.13)

12.Which design model elements are used to depict a model of information represented from the user’s view?

a.Architectural design elements b.Component-level design elements c.Data design elements d.Interface design elements

Answer: c(Section 8.4.1)

13.Which design is equivalent to the floor plan of a house?

a.Architectural design b.Component-level design c.Data design d.Interface design

Answer: a(Section 8.4.2)

14.Which design model is equivalent to the detailed drawings of the access points and external utilities for a house?

a.Architectural design b.Component-level design c.Data design d.Interface design

Answer: d(Section 8.4.3)

15.Which design model is equivalent to a set of detailed drawings for each room in a house?

a.Architectural design b.Component-level design c.Data design d.Interface design

Answer: b(Section 8.4.4)

16.The deployment design elements specify the build order for the software components.a.True b.False

Answer: b(Section 8.4.5)