1、信息系統(tǒng)軟件（總分： 148.00，做題時間： 90分鐘）一、 單項選擇題 （ 總題數(shù)：128，分?jǐn)?shù)： 148.00)1. 下列敘述中，與提高軟件可移植性相關(guān)的是 A. 選擇時間效率高的算法B. 盡可能減少注釋C. 選擇空間效率高的算法D. 盡量用高級語言編寫系統(tǒng)中對效率要求不高的部分（分?jǐn)?shù)： 1.00 ）A.B.C.D. V解析：下列要素中，不屬于 DFD的是。當(dāng)使用DFD對一個工資系統(tǒng)進(jìn)行建模時， 可以被認(rèn)定為外部實體。（分?jǐn)?shù)： 2.00 ）（1）.A 加工B 數(shù)據(jù)流C 數(shù)據(jù)存儲D 聯(lián)系（分?jǐn)?shù)：1.00 ）A.B.C.D. V解析：（2）.A .接收工資單的銀行 B .工資系統(tǒng)源代碼程序C

2、.工資單D 工資數(shù)據(jù)庫的維護(hù)（分?jǐn)?shù)：1.00 ）A. VB.C.D.解析：2. 軟件質(zhì)量的定義是 。A. 軟件的功能性、可靠性、易用性、效率、可維護(hù)性、可移植性B. 滿足規(guī)定用戶需求的能力C. 最大限度達(dá)到用戶滿意D. 軟件特性的總和，以及滿足規(guī)定和潛在用戶需求的能力分?jǐn)?shù)： 1.00 ）A.B.C.D. V在系統(tǒng)轉(zhuǎn)換的過程中，舊系統(tǒng)和新系統(tǒng)并行工作一段時間，再由新系統(tǒng)代替舊系統(tǒng)的策略稱為;在新系統(tǒng)全部正式運行前，一部分一部分地代替舊系統(tǒng)的策略稱為 。（分?jǐn)?shù)：2.00）（1）.A 直接轉(zhuǎn)換B 位置轉(zhuǎn)換C 分段轉(zhuǎn)換D 并行轉(zhuǎn)換（分?jǐn)?shù)：1.00 ）A.B.C.D. V解析：（2）.A 直接轉(zhuǎn)換B 位

3、置轉(zhuǎn)換C 分段轉(zhuǎn)換D 并行轉(zhuǎn)換（分?jǐn)?shù)：1.00 ）A.B.C. VD.解析：在下圖所示的樹形文件系統(tǒng)中，方框表示目錄，圓圈表示文件，“/”表示目錄名之間的分隔符，“ /”在路徑之首時表示根目錄。假設(shè)“.”表示父目錄，當(dāng)前目錄是Y1，那么，指定文件F2所需的相對路徑是;如果當(dāng)前目錄是 X2,“DEL表示刪除命令，那么，刪除文件F4的正確命令是 。（分?jǐn)?shù)：2.00 ）（1）.A /X1/Y2/F2 B ./X1/Y2/F2C. X1/Y2/F2 D ./Y2/F2（分?jǐn)?shù)：1.00 ）A.B.C.D. V解析：.A DEL./Y3/F4 B DEL X2/Y3/F4C. DEL Y3/F4 D DE

4、L/Y3/F4 （分?jǐn)?shù)：1.00 ）A.B.C. VD.解析：3. 以下內(nèi)容中，應(yīng)寫入操作手冊。A. 描述系統(tǒng)對各種輸入數(shù)據(jù)的處理方法B. 說明系統(tǒng)升級時廠商提供的服務(wù)C. 描述系統(tǒng)處理過程的各個界面D. 說明系統(tǒng)各部分之間的接口關(guān)系（分?jǐn)?shù)：1.00 ）A.B.C. VD.4. 在選擇多媒體數(shù)據(jù)壓縮算法時需要綜合考慮 。A. 數(shù)據(jù)質(zhì)量和存儲要求 B 數(shù)據(jù)的用途和計算要求C. 數(shù)據(jù)質(zhì)量、數(shù)據(jù)量和計算的復(fù)雜度D 數(shù)據(jù)的質(zhì)量和計算要求（分?jǐn)?shù)： 1.00 ）A.B.C. VD.解析：5. 數(shù)據(jù)流圖的作用是 。A. 描述了數(shù)據(jù)對象之間的關(guān)系B 描述了對數(shù)據(jù)的處理流程C. 說明了將要出現(xiàn)的邏輯判定D 指明

5、了系統(tǒng)對外部事件的反應(yīng)（分?jǐn)?shù)： 1.00 ）A.B. VC.D.解析：6. 不是結(jié)構(gòu)化分析設(shè)計的原則。A. 模塊獨立B 自頂向下C 自底向上D 逐步求精（分?jǐn)?shù)： 1.00 ）A.B.C. VD.解析：7. 模塊的耦合度描述了 。A. 模塊內(nèi)各種元素結(jié)合的程度B 模塊內(nèi)多個功能之間的接口C. 模塊之間公共數(shù)據(jù)的數(shù)量D .模塊之間相互關(guān)聯(lián)的程度（分?jǐn)?shù)： 1.00 ）A.B.C.D. V解析：8. 內(nèi)聚是一種指標(biāo)，表示一個模塊 。A. 代碼優(yōu)化的程度B. 代碼功能的集中程度C. 完成任務(wù)的及時程度D. 為了與其他模塊連接所要完成的工作量（分?jǐn)?shù)： 1.00 ）A.B. VC.D.解析：9. 在以下關(guān)于

6、軟件質(zhì)量的描述中，正確的是 。A. 軟件質(zhì)量是指軟件滿足規(guī)定用戶需求的能力B. 軟件質(zhì)量特性是指軟件的功能性、可靠性、易用性、效率、可維護(hù)性、可移植性C. 軟件質(zhì)量保證過程就是軟件測試過程D. 以上描述都不對（分?jǐn)?shù)： 1.00 ）A.B.C.D. V解析：10. 軟件生存周期一般劃分為六個階段，包括軟件項目計劃、軟件需求分析和定義、軟件設(shè)計、程序編碼、 軟件測試以及 。A. 部署實施B 調(diào)整完善C.運行維護(hù)D .結(jié)項驗收（分?jǐn)?shù)： 1.00 ）A.B.C. VD.解析：11. 在面向?qū)ο蟮能浖こ讨校粋€組件 （Component） 包含了 A. 所有的屬性和操作 B 各個類的實例C. 每個演員

7、（device or user） 的作用D .一些協(xié)作的類的集合（分?jǐn)?shù)： 1.00 ）A.B.C.D. V解析：12. 應(yīng)用面向?qū)ο蟮能浖_發(fā)方法進(jìn)行分析和設(shè)計時，首先要定義好各種A. 類B 對象C .消息D 操作分?jǐn)?shù)： 1.00 )A. VB.C.D.解析：是面向?qū)ο蟪绦蛟O(shè)計語言不同于其他語言的主要特點，是否建立了豐富的 是衡量一個面向?qū)?象程序設(shè)計語言成熟與否的一個重要標(biāo)志。（分?jǐn)?shù)： 2.00 ）.A .繼承性B .消息傳遞C .多態(tài)性D .靜態(tài)聯(lián)編（分?jǐn)?shù)：1.00 ）A. VB.C.D.解析：.A 函數(shù)庫B 類庫C.類型庫D 方法庫（分?jǐn)?shù)：1.00 ）A.B. VC.D.解析：13. 基

8、線可作為軟件生存期中各開發(fā)階段的一個質(zhì)量檢查點。 當(dāng)采用的基線發(fā)生錯誤時， 可以返回到最近和 最恰當(dāng)?shù)?上。A. 配置項B .程序C .基線D .過程（分?jǐn)?shù)： 1.00 ）A.B.C. VD.解析：14. 面向?qū)ο?（Object-Oriented） 方法是一種非常實用的軟件開發(fā)方法。 一個對象通常由 3 部分組成A. 對象名、類、消息B 名稱、屬性、函數(shù)C. 對象名、屬性、方法D 名稱、消息、操作（分?jǐn)?shù)： 1.00 ）A.B.C. VD.解析：常見的軟件開發(fā)模型有瀑布模型、演化模型、螺旋模型、噴泉模型等。其中模型適用于需求明確或很少變更的項目， 模型主要用來描述面向?qū)ο蟮能浖_發(fā)過程。（分?jǐn)?shù)

9、： 2.00 ）（1）.A .瀑布模型B .演化模型C .螺旋模型D .噴泉模型（分?jǐn)?shù)：1.00 ）A. VB.C.D.解析：（2）.A .瀑布模型B .演化模型C .螺旋模型D .噴泉模型（分?jǐn)?shù)：1.00 ）A.B.C.D. V解析：15. 軟件的質(zhì)量應(yīng)當(dāng)在 中加以保證。A. 軟件設(shè)計階段B 軟件開發(fā)階段C. 軟件評審階段 D .整個生命周期（分?jǐn)?shù)： 1.00 ）A.B.C.D. V解析：16. 為了識別和糾正運行中的程序錯誤而進(jìn)行的維護(hù)稱為 維護(hù)A. 適應(yīng)性B .完善性C .預(yù)防性D .校正性（分?jǐn)?shù)： 1.00 ）A.B.C.D. V解析：不是軟件開發(fā)生命周期的六個階段之一。生命周期中時間

10、最長的是 階段分?jǐn)?shù)： 2.00 ）(1).A.軟件計劃B.軟件測試C.需求分析 D .系統(tǒng)驗收（分?jǐn)?shù)：1.00 )A.B.C.D.V解析：(2).A.軟件設(shè)計B.程序編寫C.需求分析 D .軟件維護(hù)（分?jǐn)?shù)：1.00 )A.B.C.D.V解析：17. 在軟件開發(fā)方法中，生命周期法的主要缺點是：難以準(zhǔn)確定義用戶需求， 軟件開發(fā)工作是勞動密集型的，并且 。A.階段不明確B 無法對項目進(jìn)行管理和控制C.開發(fā)周期長，難適應(yīng)環(huán)境變化D 系統(tǒng)各部分不獨立（分?jǐn)?shù):1.00）A.B.C. VD.解析：18. 結(jié)構(gòu)化開發(fā)方法中，數(shù)據(jù)流圖是 階段產(chǎn)生的成果。A. 需求分析B 總體設(shè)計C 詳細(xì)設(shè)計D 程序編碼（分?jǐn)?shù)：

11、1.00 ）A. VB.C.D.解析：面向?qū)ο蟮拈_發(fā)方法中， 是面向?qū)ο蠹夹g(shù)領(lǐng)域內(nèi)占主導(dǎo)地位的標(biāo)準(zhǔn)建模語言，用這種語言描述系統(tǒng)與外部系統(tǒng)及用戶之間交互的圖是 。（分?jǐn)?shù)：2.00 ）（1）.A . RUP B C+ C. UML D JaVa （分?jǐn)?shù)：1.00 ）A.B.C. VD.解析：.A .類圖B .用例圖C .對象圖D .協(xié)作圖（分?jǐn)?shù)：1.00 ）A.B. VC.D.解析：19. 面向?qū)ο笾械乃^數(shù)據(jù)隱藏指的是 。A. 輸入數(shù)據(jù)必須輸入口令 B 數(shù)據(jù)經(jīng)過加密處理C. 對象內(nèi)部數(shù)據(jù)結(jié)構(gòu)上建有防火墻D 對象內(nèi)部數(shù)據(jù)結(jié)構(gòu)的不可訪問性（分?jǐn)?shù)：1.00 ）A.B.C.D. V解析：20. 面向?qū)ο?/p>

12、的類之間有關(guān)聯(lián)、泛化、實現(xiàn)及依賴等關(guān)系。在統(tǒng)一建模語言中，符號 關(guān)系。A. 關(guān)聯(lián)B .依賴C .實現(xiàn)D .泛化（分?jǐn)?shù)： 1.00 ）A.B.C. VD.解析：21. 在軟件開發(fā)中必須采取有力的措施以確保軟件的質(zhì)量，這些措施至少包括以下的 在軟件開發(fā)初期制定質(zhì)量保證計劃，并在開發(fā)中堅持執(zhí)行 開發(fā)工作嚴(yán)格按階段進(jìn)行，文檔工作應(yīng)在開發(fā)完成后集中進(jìn)行 嚴(yán)格執(zhí)行階段評審 要求用戶參與全部開發(fā)過程以監(jiān)督開發(fā)質(zhì)量 開發(fā)前選定或制定開發(fā)標(biāo)準(zhǔn)或開發(fā)規(guī)范并遵照執(zhí)行 爭取足夠的開發(fā)經(jīng)費和開發(fā)人力的支持A. B .C.D.（分?jǐn)?shù)： 1.00 ）A. VB.C.D.解析：22. CMM提供了一個框架，將軟件過程改進(jìn)劃分

13、成 個成熟度等級。A3 B4 C5 D6（分?jǐn)?shù)： 1.00 ）A.B.C. VD.解析：4 個最基本的活動，按照軟件配置管理的原始指導(dǎo)思想， 受控制的對象應(yīng)是 。實施軟件配置管理包括其中不包括 。（分?jǐn)?shù)： 2.00 ）（1）.A .軟件元素B .軟件項目C .軟件配置項D .軟件過程（分?jǐn)?shù)：1.00 ）A.B.C. VD.解析：（2）.A 配置項標(biāo)識 B 配置項優(yōu)化C. 配置狀態(tài)報告 D 配置審計（分?jǐn)?shù)：1.00 ）A.B. VC.D.解析：23. 通常影響軟件易維護(hù)性的因素有易理解性、易修改性和 A. 易使用性B 易恢復(fù)性C 易替換性D 易測試性（分?jǐn)?shù)： 1.00 ）A.B.C.D. V解析

14、：24. 瀑布模型的主要不足之處在于 。A. 過于簡單B 過于靈活C. 不能適應(yīng)需求的動態(tài)變更D 各個階段需要進(jìn)行評審（分?jǐn)?shù)： 1.00 ）A.B.C. VD.解析：25. 不是標(biāo)準(zhǔn)的SQL語句。A. ALTERTABLE B ALTERVIEWC. CREATETABLE CREATEVIEW（分?jǐn)?shù)： 1.00 ）A.B. VC.D.解析：在數(shù)據(jù)流圖中，帶箭頭的直線表示 。兩條平行線表示 （分?jǐn)?shù)： 2.00 ）.A 加工B 外部實體C 數(shù)據(jù)流D 存儲（分?jǐn)?shù)：1.00 ）A.B.C. VD.解析：.A 加工B 外部實體C 數(shù)據(jù)流D 存儲（分?jǐn)?shù)：1.00 ）A.B.C.D. V26. 軟件的復(fù)雜

15、性與許多因素有關(guān)。 不屬于軟件的復(fù)雜性參數(shù)。A. 源程序的代碼行數(shù) B 程序的結(jié)構(gòu)C. 算法的難易程度 D 程序中注釋的多少（分?jǐn)?shù)： 1.00 ）A.B.C.D. V解析：27. 不屬于面向?qū)ο蟮能浖_發(fā)方法。A. coad 方法 B . booch 方法C. jackson 方法 D . omt 方法（分?jǐn)?shù)： 1.00 ）A.B.C. VD.解析：在面向?qū)ο蠓椒ㄖ校瑢ο罂煽闯墒菍傩?（ 數(shù)據(jù)） 以及這些屬性上的專用操作的封裝體。封裝是一種 技術(shù)，封裝的目的是使對象的 分離。（分?jǐn)?shù)： 2.00 ）（1）.A 組裝 B 產(chǎn)品化 C 固化 D 信息隱蔽（分?jǐn)?shù)： 1.00 ）A.B.C.D. V解析

16、：（2）.A .定義和實現(xiàn)B .設(shè)計和測試C .設(shè)計和實現(xiàn)D .分析和定義（分?jǐn)?shù)：1.00 ）A. VB.C.D.解析：28. 結(jié)構(gòu)化分析方法 （SA） 的一個重要指導(dǎo)思想是 。A.自頂向下，逐步抽象 B .自底向上，逐步抽象C. 自頂向下，逐步分解 D .自底向上，逐步分解（分?jǐn)?shù)： 1.00 ）A.B.C. VD.29. 面向?qū)ο蟮闹饕卣靼▽ο笪ㄒ恍浴⒎庋b性、繼承性和 A. 多態(tài)性B .完整性C .可移植性D .兼容性（分?jǐn)?shù)： 1.00 ）A. VB.C.D.解析：30. 軟件需求規(guī)格說明書在軟件開發(fā)中具有重要作用，但其作用不應(yīng)該包括A. 軟件設(shè)計的依據(jù)B. 用戶和開發(fā)人員對軟件要做什么

17、的共同理解C. 軟件驗收的依據(jù)D. 軟件可行性分析依據(jù)（分?jǐn)?shù)： 1.00 ）A.B.C.D. V解析：31. 在軟件的開發(fā)與維護(hù)過程中，用來存儲、更新、恢復(fù)和管理軟件的多版本的工具是A.文檔分析工具 B 項目管理工具C. 成本估算工具 D 版本控制工具（分?jǐn)?shù)： 1.00 ）A.B.C.D. V解析：32. 在開發(fā)一個系統(tǒng)時，如果用戶對系統(tǒng)的目標(biāo)不是很清楚，難以定義需求，這時最好使用A.原型法B .瀑布模型C . V模型D .螺旋模型（分?jǐn)?shù)： 1.00 ）A. VB.C.D.解析：33. 漸增式開發(fā)方法有利于 。A.獲取軟件需求B 快速開發(fā)軟件 C.大型團(tuán)隊開發(fā) D .商業(yè)軟件開發(fā)（分?jǐn)?shù)： 1.

18、00 ）A.B. VC.D.解析：34. 好的軟件結(jié)構(gòu)應(yīng)該是 A. 高耦合、高內(nèi)聚B. 低耦合、高內(nèi)聚C. 高耦合、低內(nèi)聚D. 低耦合、低內(nèi)聚（分?jǐn)?shù)： 1.00 ）A.B. VC.D.解析：35. 如果有兩個事務(wù)，同時對數(shù)據(jù)庫中同一數(shù)據(jù)進(jìn)行操作，不會引起沖突的操作是A. 其中有一個是 DELETEB. 個是 SELECT 另一個是 UPDATEC. 兩個都是SELECTD. 兩個都是UPDATE（分?jǐn)?shù)： 1.00 ）A.B.C. VD.解析：36. 下列選項中，影響軟件可維護(hù)性最直接的因素是 A. 文檔B .資金C .程序代碼 D . MTTF（分?jǐn)?shù)： 1.00 ）A. VB.C.D.解析：3

19、7. 軟件質(zhì)量因素不包括 。A.正確性B .高性能C .可測試性D .可理解性分?jǐn)?shù)： 1.00 ）A.B. VC.D.解析：38. 需求分析中開發(fā)人員應(yīng)該主要從用戶那里了解 A. 軟件做什么B. 使用界面C. 輸入的信息D. 軟件的規(guī)模（分?jǐn)?shù)： 1.00 ）A. VB.C.D.解析：39. 下列說法錯誤的是 。A. 數(shù)據(jù)倉庫具有時間相關(guān)性B. 數(shù)據(jù)倉庫的數(shù)據(jù)是不穩(wěn)定的C. 數(shù)據(jù)倉庫是集成的D. 數(shù)據(jù)倉庫是面向主題的（分?jǐn)?shù)： 1.00 ）A.B. VC.D.解析：40. 下述CMMI四個能力成熟度等級，級別最高的是 。A.已定義級B 優(yōu)化級C 可重復(fù)級D 已管理級（分?jǐn)?shù)： 1.00 ）A.B.

20、VC.D.解析：41. 軟件配置項是軟件配置管理的對象，指的是軟件工程過程中所產(chǎn)生的A.接口 B .軟件環(huán)境C .信息項D .版本分?jǐn)?shù)： 1.00 )A. VB.C.D.解析：42. 非常明確地標(biāo)明了軟件開發(fā)測試過程中存在的不同級別， 且清楚地描述了這些測試階段和開發(fā)過程各階段的對應(yīng)關(guān)系。A. 螺旋模型B 噴泉模型C.瀑布模型D . V模型（分?jǐn)?shù)： 1.00 ）A.B.C.D. V解析：43. 質(zhì)量體系是一種 。A. 體系結(jié)構(gòu)B 質(zhì)量改進(jìn)過程 C.管理手段D 質(zhì)量管理制度（分?jǐn)?shù)： 1.00 ）A.B.C.D. V解析：在UML提供的圖中，用于描述系統(tǒng)與外部系統(tǒng)及用戶之間的交互； 用于按時間順序

21、描述對象之間的交互。分?jǐn)?shù)： 2.00 ）(1).AA.B.C.D.解析：.用例圖B .類圖C.對象圖D .部署圖（分?jǐn)?shù)：1.00 ） V(2).AA.B.C.D.解析：.網(wǎng)絡(luò)圖B .狀態(tài)圖C .協(xié)作圖D .序列圖（分?jǐn)?shù)：1.00 ） V44. 以下關(guān)于軟件需求分析的說法中，不正確的是 。A. 需求分析需要進(jìn)行軟件功能和性能的技術(shù)實現(xiàn)方法的描述B. 需求分析文檔可用于指導(dǎo)后續(xù)的開發(fā)過程C. 軟件需求包括業(yè)務(wù)需求、用戶需求、功能需求和非功能需求等D. 軟件需求一般應(yīng)由用戶方組織進(jìn)行確認(rèn)分?jǐn)?shù)： 1.00 )A. VB.C.B. 解析：45. 數(shù)據(jù)倉庫的內(nèi)容是隨時間變化的，這種變化趨勢不包括 A. 不

22、斷增加新的數(shù)據(jù)內(nèi)容B. 捕捉到的新數(shù)據(jù)會覆蓋舊的快照C. 不斷刪去過期的數(shù)據(jù)內(nèi)容D. 綜合數(shù)據(jù)將隨時間變化而不斷地進(jìn)行重新綜合（分?jǐn)?shù)： 1.00 ）A.B.C. VD.解析：46. 軟件的 反映了組織機(jī)構(gòu)或客戶對系統(tǒng)、產(chǎn)品高層次的目標(biāo)要求。A. 業(yè)務(wù)需求B .技術(shù)先進(jìn)性C .功能需求D .性能需求（分?jǐn)?shù)： 1.00 ）A. VB.C.D.解析：47. 統(tǒng)一建模語言UML中用來反映代碼的物理結(jié)構(gòu)的是 A.用例圖B 協(xié)作圖C 組件圖D 狀態(tài)圖（分?jǐn)?shù)： 1.00 ）A.B.C. VD.解析：48. 在面向?qū)ο筌浖_發(fā)方法中，一個對象一般由 組成A.名稱、消息、函數(shù)B 名稱、屬性C. 對象名、屬性、消

23、息D 屬性、方法（分?jǐn)?shù)： 1.00 ）A.B.C.D. V49. 因為 Java 平臺 ，所以具有較強(qiáng)的可移植性。A. 具有強(qiáng)大的數(shù)據(jù)操作和事務(wù)處理能力B. 采用Java虛擬機(jī)技術(shù)C. 可用的組件較多，功能豐富D. 適用于分布式系統(tǒng)，支持多層架構(gòu)應(yīng)用（分?jǐn)?shù)： 1.00 ）A.B. VC.D.解析：50. 在面向?qū)ο缶幊碳胺植际綄ο蠹夹g(shù)中， 是類和接口的集合A.對象B .組件C .實例D .屬性（分?jǐn)?shù)： 1.00 ）A.B. VC.D.解析：51. 在軟件生命周期中，需求分析是軟件設(shè)計的基礎(chǔ)。需求分析階段研究的對象是軟件項目的A.規(guī)模B .質(zhì)量要素C 用戶要求D 設(shè)計約束（分?jǐn)?shù)： 1.00 ）A

24、.B.C. VD.解析：52. 個軟件開發(fā)過程描述了“誰做”、“做什么”、“怎么做”和“什么時候做”，RUP用來表述“誰做”。A.角色B .活動C .制品D .工作流（分?jǐn)?shù)： 1.00 ）A. VB.C.D.解析：在UM沖，圖是系統(tǒng)體系結(jié)構(gòu)在某個側(cè)面的表示，所有圖在一起組成系統(tǒng)的完整視圖。 在UML9中圖中，是靜態(tài)圖， 是動態(tài)圖。（分?jǐn)?shù)： 2.00 ）（1）.A 序列圖B 配置圖C 協(xié)作圖D 數(shù)據(jù)流圖（分?jǐn)?shù)：1.00 ）A.B. VC.D.解析：.A .對象圖B .數(shù)據(jù)流圖C .組件圖D .狀態(tài)圖（分?jǐn)?shù)：1.00 ）A.B.C.D. V解析：53. UML的包是一種對模型元素進(jìn)行成組組織的通用

25、機(jī)制，以便于理解復(fù)雜的系統(tǒng)。包與包之間的聯(lián)系主要是依賴和 。A.泛化B .繼承C .跟蹤D .嵌套（分?jǐn)?shù)： 1.00 ）A. VB.C.D.解析：54. 為了滿足用戶提出的增加新功能、 修改現(xiàn)有功能以及一般性的改進(jìn)要求和建議， 需要對軟件進(jìn)行 A.完善性維護(hù)B 適應(yīng)性維護(hù) C 預(yù)防性維護(hù)D 改正性維護(hù)（分?jǐn)?shù)： 1.00 ）A. VB.C.D.解析：55. 某軟件在應(yīng)用初期運行在 WindowsNT環(huán)境中。現(xiàn)該軟件需要在 UNIX環(huán)境中運行，而且必須完成相同的 功能。為適應(yīng)這個要求，軟件本身需要進(jìn)行修改，而所需修改的工作量取決于該軟件的 。A.可擴(kuò)充性B 可靠性C 復(fù)用性D 可移植性（分?jǐn)?shù)： 1

26、.00 ）A.B.C.D. V解析：56. 與客戶機(jī)/服務(wù)器（Client/Server） 架構(gòu)相比，瀏覽器/服務(wù)器（Browser/Server）架構(gòu)的最大優(yōu)點是A. 具有強(qiáng)大的數(shù)據(jù)操作和事務(wù)處理能力，模型思想簡單，易于人們理解和接受B. 部署和維護(hù)方便、易于擴(kuò)展C. 適用于分布式系統(tǒng)，支持多層應(yīng)用架構(gòu)D. 將應(yīng)用一分為二，允許網(wǎng)絡(luò)分布操作（分?jǐn)?shù)： 1.00 ）A.B. VC.D.解析：57. 一般不作為需求分析階段所使用的工具或方法。A. 頭腦風(fēng)暴法B . U/C矩陣C 數(shù)據(jù)流程圖D 需求跟蹤表（分?jǐn)?shù)： 1.00 ）A.B.C. VD.解析：58. 原型法是面向用戶需求而開發(fā)的一個或多個工

27、作模型，以下關(guān)于原型法的敘述不正確的是A. 可以減少文檔的數(shù)量B. 可以逐步明確系統(tǒng)的特征C. 開發(fā)人員可以從實踐中快速獲得需求D. 可以改善開發(fā)人員與用戶的交流（分?jǐn)?shù)： 1.00 ）A. VB.C.D.解析：59. 軟件需求分析方法中不屬于模型驅(qū)動法的是 A. SA（結(jié)構(gòu)化分析）B . IE（信息工程建模）C. OOA面向?qū)ο蠓治觯〥 . RAA（快速架構(gòu)分析）（分?jǐn)?shù)： 1.00 ）A.B.C.D. V解析：60. 下列關(guān)于軟件質(zhì)量保證活動要素的敘述中，不正確的是 。A. 質(zhì)量保證人員不能是兼職的B. 軟件開發(fā)必須嚴(yán)格按照軟件開發(fā)規(guī)范進(jìn)行C. 驗證和確認(rèn)軟件質(zhì)量所用的方法有評審、審查、審計、

28、分析、演示、測試等D. 應(yīng)在軟件開發(fā)過程中及時記錄與質(zhì)量保證有關(guān)的活動（分?jǐn)?shù):1.00）A. VB.C.D.解析：61. 在軟件需求調(diào)研過程中，用戶要求承建單位搭建的業(yè)務(wù)系統(tǒng)采用SOA架構(gòu)實現(xiàn)，且須遵循用戶內(nèi)部的數(shù)據(jù)維護(hù)與管理規(guī)范、信息分類編碼規(guī)范等制度進(jìn)行數(shù)據(jù)庫設(shè)計，這類需求屬于。A. 目標(biāo)需求B 業(yè)務(wù)需求C 功能需求D 非功能性需求（分?jǐn)?shù)：1.00 ）A.B.C.D. V解析：62. UML提供了幾種不同的圖用于組成不同的視圖，下列不屬于靜態(tài)圖的是A.用例圖B 類圖C.序列圖D 配置圖（分?jǐn)?shù)：1.00 ）A.B.C. VD.解析：63. 根據(jù)以下程序流程圖所示，滿足條件覆蓋的用例是 CAS

29、E1:x=1,y=3,z=0 CASE2:x=3,y=2,z=1 CASE3:x=1,y=2,z=0 CASE4:x=1,y=1,z=0A.B .C.D.（分?jǐn)?shù)：1.00 ）A.B.C. VD.解析：64. 在軟件產(chǎn)品交付后產(chǎn)品仍然需要不斷進(jìn)行修改，其中用來檢測和糾正軟件產(chǎn)品中的潛在故障，使其不成為有效故障的行為是。A.完善性維護(hù)B .適應(yīng)性維護(hù) C .改正性維護(hù)D .預(yù)防性維護(hù)（分?jǐn)?shù)：1.00 ）A.B.C.D. V解析：65. 構(gòu)件設(shè)計的原則是 。A. 低內(nèi)聚高耦合 B 高內(nèi)聚低耦合C. 低內(nèi)聚低耦合 D 高內(nèi)聚高耦合（分?jǐn)?shù)： 1.00 ）A.B. VC.D.解析：66. 是系統(tǒng)建模的替代

30、方法， 是可選的系統(tǒng)設(shè)計方法， 經(jīng)常用于系統(tǒng)開發(fā)項目中， 特別是用戶難以陳述或者可視化業(yè)務(wù)需求時。A.設(shè)計用例B 數(shù)據(jù)建模C.結(jié)構(gòu)化功能需求D .建立原型（分?jǐn)?shù)： 1.00 ）A.B.C.D. V解析：67. 面向?qū)ο箝_發(fā)技術(shù)中， 對象定義為系統(tǒng)中用來描述客觀事物的一個實體， 對象之間通過 執(zhí)行有關(guān)操作。A.信息共享B .調(diào)用C.繼承D .消息（分?jǐn)?shù)： 1.00 ）A.B.C.D. V解析：68. 數(shù)據(jù)字典應(yīng)在 階段建立。A.前期規(guī)劃B .需求分析C.概要設(shè)計D .詳細(xì)設(shè)計（分?jǐn)?shù)： 1.00 ）A.B. VC.D.解析：69. 軟件質(zhì)量保證活動應(yīng)貫穿軟件開發(fā)的全過程，下列有關(guān)敘述中不正確的是

31、。A. 必須及時將軟件質(zhì)量保證工作及結(jié)果通知到相關(guān)組織和個人B. 軟件質(zhì)量保證是 CMMI1級的一個關(guān)鍵過程域C. 應(yīng)對軟件質(zhì)量進(jìn)行階段性評審，并形成完整的評審記錄D. 軟件質(zhì)量保證工作需要企業(yè)最高領(lǐng)導(dǎo)者參與（分?jǐn)?shù)： 1.00 ）A.B. VC.D.解析：數(shù)據(jù)流程圖（DFD）是一種能全面描述信息系統(tǒng)邏輯模型的主要工具，在數(shù)據(jù)流程圖中方框表示 不屬于數(shù)據(jù)流程圖的基本成分。（分?jǐn)?shù)： 2.00 ）（1）.A 數(shù)據(jù)流B 數(shù)據(jù)的源點或終點C.數(shù)據(jù)存儲D .加工（分?jǐn)?shù)：1.00 ）A.B. VC.D.解析：（2）.A .外部實體B .處理過程C.數(shù)據(jù)結(jié)構(gòu)D 數(shù)據(jù)流（分?jǐn)?shù)：1.00 ）A.B.C. VD.解

32、析：70. 常用的設(shè)計模式可分為 三類。A.對象型、實現(xiàn)型和結(jié)構(gòu)型 B 創(chuàng)建型、結(jié)構(gòu)型和行為型C. 抽象型、過程型和實現(xiàn)型 D 創(chuàng)建型、接口型和行為型（分?jǐn)?shù)： 1.00 ）A.B. VC.D.解析：71. 不是基于組件的開發(fā)模型的特點。A. 使軟件的版本控制更為簡單B. 支持可重用組件的開發(fā)C. 與面向?qū)ο蠹夹g(shù)相結(jié)合將獲得更好的應(yīng)用效果D. 提高了項目開發(fā)效率，增加了項目開發(fā)成本（分?jǐn)?shù)： 1.00 ）A.B.C.D. V解析：72. 基線（Baseline）是指一個（或一組）配置項在項目生命周期的不同時間點上通過 而進(jìn)入正式受控的一種狀態(tài)。A.領(lǐng)導(dǎo)批準(zhǔn)B 質(zhì)量控制C.正式評審D 驗收測試（分?jǐn)?shù)

33、： 1.00 ）A.B.C. VD.解析：73. 在進(jìn)行軟件配置管理工作中， 可以設(shè)立配置控制委員會協(xié)助項目經(jīng)理進(jìn)行軟件配置管理， 屬于配置控制委員會的職責(zé)。A. 批準(zhǔn)、發(fā)布配置管理計劃B. 決定項目起始基線和軟件開發(fā)工作里程碑C. 建立、更改基線的設(shè)置，審核變更申請D. 執(zhí)行版本控制和變更控制方案（分?jǐn)?shù)： 1.00 ）A.B.C. VD.解析：74. 為擴(kuò)充功能或改善性能而進(jìn)行的修改，屬于 A.糾錯性維護(hù) B .適應(yīng)性維護(hù)C. 預(yù)防性維護(hù)D 完善性維護(hù)（分?jǐn)?shù)： 1.00 ）A.B.C.D. V解析：75. 面向?qū)ο蠓治雠c設(shè)計技術(shù)中， 是類的一個實例。A.對象B .接口C. 構(gòu)件D .設(shè)計模式

34、（分?jǐn)?shù)： 1.00 ）A. VB.C.D.解析：質(zhì)量體系文件通常由三部分組成， 包括質(zhì)量手冊、 和作業(yè)指導(dǎo)書。 質(zhì)量體系文件的特性不包括 （分?jǐn)?shù)： 2.00 ）（1）.A 質(zhì)量原則B 質(zhì)量記錄C 質(zhì)量說明D 程序文件（分?jǐn)?shù)：1.00 ）A.B.C.D. V解析：.A .法規(guī)性B .不變性C.唯一性D .適用性（分?jǐn)?shù)：1.00 ）A.B. VC.D.解析：76. 軟件可行性研究一般不考慮 。A. 是否有足夠的人員和資金來支持系統(tǒng)開發(fā)B. 是否有足夠的工具和相關(guān)的技術(shù)來支持C. 待開發(fā)軟件是否有市場、經(jīng)濟(jì)上是否合算D. 待開發(fā)的軟件是否會有質(zhì)量問題（分?jǐn)?shù)： 1.00 ）A.B.C.D. V解析：7

35、7. 屬于軟件詳細(xì)設(shè)計階段的任務(wù)。A.算法設(shè)計B 功能設(shè)計C.調(diào)用關(guān)系設(shè)計 D 輸入/輸出設(shè)計（分?jǐn)?shù)： 1.00 ）A.B. VC.D.解析：78. 軟件需求規(guī)格說明書在軟件開發(fā)中的作用不包括 A.軟件設(shè)計的依據(jù)B. 軟件可行性分析的依據(jù)C. 軟件驗收的依據(jù)D. 用戶和開發(fā)人員對軟件要做什么的共同理解（分?jǐn)?shù)： 1.00 ）A.B. VC.D.解析：79. 軟件工程需求分析階段的任務(wù)是確定 A. 軟件開發(fā)方法B 軟件開發(fā)工具C.軟件開發(fā)費D 軟件系統(tǒng)的功能（分?jǐn)?shù)： 1.00 ）A.B.C.D. V解析：是軟件生存期中的一系列相關(guān)軟件工程活動的集合，它由軟件規(guī)格說明、軟件設(shè)計與開發(fā)、軟件確 認(rèn)、軟

36、件改進(jìn)等活動組成。 是以追求更高的效益和效率為目標(biāo)的持續(xù)性活動。（分?jǐn)?shù)： 2.00 ）（1）.A .軟件過程B .軟件工具C.質(zhì)量保證D .軟件工程（分?jǐn)?shù)：1.00 ）A. VB.C.D.解析：（2）.A .質(zhì)量策劃B .質(zhì)量控制C.質(zhì)量保證D .質(zhì)量改進(jìn)（分?jǐn)?shù)：1.00 ）A.B.C.D. V解析：80. 對象實現(xiàn)了數(shù)據(jù)和操作的結(jié)合，使數(shù)據(jù)和操作 于對象的統(tǒng)一體中。A. 結(jié)合B.隱藏C.封裝D.抽象分?jǐn)?shù)： 1.00 )A.B.C. VD.解析：81. 軟件可維護(hù)性的特性中相互促進(jìn)的是 A. 可理解性和可測試性 B .可理解性和可移植性C. 效率和可修改性 D .效率和結(jié)構(gòu)（分?jǐn)?shù)： 1.00

37、）A. VB.C.D.解析：82. 面向?qū)ο蠓椒ㄓ性S多特征， 如軟件系統(tǒng)是由對象組成的； ；對象彼此之間僅能通過傳遞消息互相聯(lián)系；層次結(jié)構(gòu)的繼承。A. 開發(fā)過程基于功能分析和功能分解B. 強(qiáng)調(diào)需求分析重要性C. 把對象劃分成類，每個對象類都定義一組數(shù)據(jù)和方法D. 對既存類進(jìn)行調(diào)整（分?jǐn)?shù)： 1.00 ）A.B.C. VD.解析：83. 原型化方法是用戶和設(shè)計者之間執(zhí)行的一種交互構(gòu)成，適用于 系統(tǒng)的開發(fā)A.需求不確定性高的B 需求確定的C. 分時D 實時分?jǐn)?shù)： 1.00 )A. VB.C.D.解析：84. DFD 中的每個“加工”至少需要 。A. 個輸入流 B 一個輸出流C. 一個輸入流或一個輸出

38、流D 一個輸入流和一個輸出流分?jǐn)?shù)： 1.00 ）A.B.C.D. V85. 以下關(guān)于源程序功能性注釋不正確的說法是 。A. 功能性注釋在源程序中，用于說明程序或語句的功能及數(shù)據(jù)的狀態(tài)等B. 注釋用來說明程序段，在每一行都需要加注釋C. 可以使用空行或縮進(jìn)，以便于容易區(qū)分注釋和程序D. 修改程序也應(yīng)修改注釋（分?jǐn)?shù)： 1.00 ）A.B. VC.D.解析：86. 模塊的耦合性可以按照耦合程度的高低進(jìn)行排序，以下 符合耦合程度從低到高的次序。A. 標(biāo)記耦合，公共耦合，控制耦合，內(nèi)容耦合B. 數(shù)據(jù)耦合，控制耦合，標(biāo)記耦合，公共耦合C. 無直接耦合，標(biāo)記耦合，內(nèi)容耦合，控制耦合D. 無直接耦合，數(shù)據(jù)耦合

39、，控制耦合，內(nèi)容耦合（分?jǐn)?shù)： 1.00 ）A.B.C.D. V解析：87. UML語言不支持的建模方式有A.靜態(tài)建模 B 動態(tài)建模C.模塊化建模 D .功能建模分?jǐn)?shù)： 1.00 )A.B.C. VD.解析：88. 在 E-R 模型中，包含的基本成分是 A.數(shù)據(jù)、對象、實體 B .控制、聯(lián)系、對象C. 實體、聯(lián)系、屬性 D 實體、數(shù)據(jù)、聯(lián)系分?jǐn)?shù)： 1.00 ）A.B.C. VD.89. 類之間的關(guān)系不包括 A. 依賴關(guān)系B 泛化關(guān)系C. 實現(xiàn)關(guān)系D 分辨關(guān)系分?jǐn)?shù)： 1.00 ）A.B.C.D. V解析：不是導(dǎo)致軟件錯誤的主要原因90. 軟件錯誤產(chǎn)生的原因很多，A. 測試錯誤B. 設(shè)計錯誤C. 編

40、碼錯誤D. 軟件需求規(guī)格說明錯誤分?jǐn)?shù)： 1.00 )A. VB.C.D.解析：91. 最適合擔(dān)任軟件外部技術(shù)評審專家的是 A. 在軟件工程理論領(lǐng)域有所建樹的高校教授B. 所在機(jī)構(gòu)上級管理機(jī)關(guān)相關(guān)部門的直屬領(lǐng)導(dǎo)C. 具有多年技術(shù)經(jīng)驗的項目承建單位總架構(gòu)師D. 具有同行業(yè)同規(guī)模相關(guān)系統(tǒng)建設(shè)經(jīng)驗的高級咨詢師（分?jǐn)?shù)： 1.00 ）A.B.C.D. V解析：92. 關(guān)于軟件測試對軟件質(zhì)量的意義，有以下觀點：度量與評估軟件的質(zhì)量；保證軟件質(zhì)量；改進(jìn)軟 件開發(fā)過程；發(fā)現(xiàn)軟件錯誤。其中正確的是 。A.、B.、C.、D.、（分?jǐn)?shù)： 1.00 ）A.B.C. VD.93. 采用瀑布模型進(jìn)行系統(tǒng)開發(fā)的過程中， 每個

41、階段都會產(chǎn)生不同的文檔。 以下關(guān)于產(chǎn)生這些文檔的描述中， 正確的是 。A. 外部設(shè)計評審報告在概要設(shè)計階段產(chǎn)生B. 集成測試計劃在程序設(shè)計階段產(chǎn)生C. 系統(tǒng)計劃和需求說明在詳細(xì)設(shè)計階段產(chǎn)生D. 在進(jìn)行編碼的同時，設(shè)計獨立的單元測試計劃（分?jǐn)?shù)： 1.00 ）A.B.C.D. V解析：94. 應(yīng)該在 階段制定系統(tǒng)測試計劃A. 需求分析B .概要設(shè)計C. 詳細(xì)設(shè)計D .系統(tǒng)測試（分?jǐn)?shù)： 1.00 ）A. VB.C.D.解析：95. 代碼走查 （Code Walkthrough） 和代碼審查 （Code Inspection） 是兩種不同的代碼評審方法，這兩種方法 的主要區(qū)別是 。A. 在代碼審查中由

42、編寫代碼的程序員來組織討論，而在代碼走查中由高級管理人員來領(lǐng)導(dǎo)評審小組的活動B. 在代碼審查中只檢查代碼中是否有錯誤，而在代碼走查中還要檢查程序與設(shè)計文檔的一致性C. 在代碼走查中只檢查程序的正確性，而在代碼審查中還要評審程序員的編程能力和工作業(yè)績D. 代碼審查是一種正式的評審活動，而代碼走查的討論過程是非正式的（分?jǐn)?shù)： 1.00 ）A.B.C.D. V解析：96. 軟件測試的目的在 。A.修改所有錯誤 B 發(fā)現(xiàn)錯誤C.評估程序員水平D 證明程序正確分?jǐn)?shù)： 1.00 )A.B. VC.解析：97. 軟件黑盒測試的測試用例設(shè)計主要考慮 A. 軟件功能B 輸入數(shù)據(jù)C.輸出數(shù)據(jù)D 內(nèi)部邏輯（分?jǐn)?shù)：

43、1.00 ）A. VB.C.D.解析：98. 確認(rèn)測試是以軟件 為依據(jù)進(jìn)行的測試。A. 源程序B 需求說明C.概要設(shè)計D 詳細(xì)設(shè)計（分?jǐn)?shù)： 1.00 ）A.B. VC.D.解析：下面關(guān)于軟件測試的說法， 是錯誤的。軟件測試方法可分為黑盒測試法和白盒測試法兩種。黑盒測試法是通過分析程序的 來設(shè)計測試用例的方法。集成測試也叫做 。（分?jǐn)?shù)： 3.00 ）（1）.A 軟件測試就是程序測試B. 軟件測試貫穿于軟件定義和開發(fā)的整個期間C. 需求規(guī)格說明、設(shè)計規(guī)格說明都是軟件測試的對象D. 程序是軟件測試的對象（分?jǐn)?shù)：1.00 ）A. VB.C.D.解析：（2）.A .應(yīng)用范圍B .內(nèi)部邏輯C.功能D 輸入

44、數(shù)據(jù)（分?jǐn)?shù)：1.00 ）A.B.C. VD.解析：（3）.A .部件測試B .組裝測試C. 確認(rèn)測試D .集合測試（分?jǐn)?shù)：1.00 ）A.B. VC.解析：白盒測試通常采用的方法是 ， 不屬于白盒測試用例設(shè)計方法。黑盒測試也稱為功能測試，它不能發(fā)現(xiàn) 。（分?jǐn)?shù)： 3.00 ）（1）.A 靜態(tài)測試 B 動態(tài)測試C.靜態(tài)、動態(tài)測試 D .靜態(tài)、動態(tài)測試和復(fù)審（分?jǐn)?shù)： 1.00 ）A.B.C. VD.解析：（2）.A .基本路徑測試 B .因果圖測試C. 循環(huán)覆蓋測試 D 邏輯覆蓋測試（分?jǐn)?shù)：1.00 ）A.B. VC.D.解析：（3）.A .可靠性錯誤 B .輸入是否正確接收C.界面是否有誤 D 是否存在冗余代碼（分?jǐn)?shù)：1.00 ）A.B.C.B. V解析：為了提高軟件測試的效率，應(yīng)該 。與設(shè)計測試用例無關(guān)的文檔是 。（分?jǐn)?shù)： 2.00 ）（1）.A .隨機(jī)地選取測試數(shù)據(jù)B. 取一切可能的輸入數(shù)據(jù)作為測試數(shù)據(jù)C. 在完成編碼以后制定軟件的測試計劃D. 選擇發(fā)現(xiàn)錯誤可能性較大的測試用例（分?jǐn)?shù)：1.00 ）A.B.C