信息系統(tǒng)工程技術(shù)知識(shí)(三)

1、信息系統(tǒng)工程技術(shù)知識(shí) （ 三）（ 總分： 101.00 ，做題時(shí)間： 90 分鐘 ）一、 單項(xiàng)選擇題 （ 總題數(shù)： 48，分?jǐn)?shù)： 101.00）1. 下列關(guān)于軟件測試技術(shù)的敘述，不正確的是 。A. 用黑盒測試的結(jié)論分辨數(shù)據(jù)庫或系統(tǒng)層面的錯(cuò)誤B. 要滿足較高的覆蓋準(zhǔn)則，路徑數(shù)量有可能非常龐大。C. 搭建測試環(huán)境時(shí)必須盡可能地于真實(shí)環(huán)境一致。D. 兼容性驗(yàn)證測試和用戶環(huán)境模擬測試可以不同。（分?jǐn)?shù)： 2.00 ）A. VB.C.D.解析：軟件測試按使用的測試技術(shù)不同可以將測試分為靜態(tài)測試和動(dòng)態(tài)測試，進(jìn)一步地可以將靜態(tài)測試分 成靜態(tài)分析和代碼審查，將動(dòng)態(tài)測試分成白盒測試和黑盒測試。代碼審查 （ 包括代

2、碼評(píng)審和走查 ） 主要依靠有經(jīng)驗(yàn)的程序設(shè)計(jì)人員根據(jù)軟件設(shè)計(jì)文檔，通過閱讀程序，發(fā)現(xiàn) 軟件錯(cuò)誤和缺陷。代碼審查一般按代碼審查單閱讀程序，查找錯(cuò)誤。代碼審查的內(nèi)容包括：檢查代碼和設(shè) 計(jì)的一致性；檢查代碼的標(biāo)準(zhǔn)性、可讀性；檢查代碼邏輯表達(dá)的正確性和完整性；檢查代碼結(jié)構(gòu)的合現(xiàn)性 等。代碼審查雖然在發(fā)現(xiàn)程序錯(cuò)誤上有一定的局限性，但它不需要專門的測試工具和設(shè)備，且有一旦發(fā)現(xiàn) 錯(cuò)誤就能定位錯(cuò)誤和一次發(fā)現(xiàn)一批錯(cuò)誤等優(yōu)點(diǎn)。靜態(tài)分析主要對(duì)程序進(jìn)行控制流分析、數(shù)據(jù)流分析、接口分析和表達(dá)式分析等。靜態(tài)分析一般由計(jì)算機(jī)輔 助完成。靜態(tài)分析的對(duì)象是計(jì)算機(jī)程序，程序設(shè)計(jì)語言不同，相應(yīng)的靜態(tài)分析工具也應(yīng)不同。目前具備靜 態(tài)分

3、析功能的軟件測試工具有很多，如 Purify、Macabe等。白盒測試是一種按照程序內(nèi)部的邏輯結(jié)構(gòu)和編碼結(jié)構(gòu)設(shè)計(jì)并執(zhí)行測試用例的測試方法。采用這種測試方法，測試者需要掌握被測程序的內(nèi)部結(jié)構(gòu)。白盒測試通常根據(jù)覆蓋準(zhǔn)則設(shè)計(jì)測試用例，使程序中的每個(gè)語句、 每個(gè)條件分支、每個(gè)控制路徑都在程序測試中受到檢驗(yàn)。白盒測試需要運(yùn)行程序，并能在運(yùn)行過程中跟蹤 程序的執(zhí)行路徑。黑盒測試是一種從軟件需求出發(fā)，根據(jù)軟件需求規(guī)格說明設(shè)計(jì)測試用例，并按照測試用例的要求運(yùn)行被測 程序的測試方法。它較少關(guān)心程序內(nèi)部的實(shí)現(xiàn)過程，側(cè)重于程序的執(zhí)行結(jié)果，將被測程序看成是不可見的 黑盒子，因此被稱為黑盒測試。黑盒測試著重于驗(yàn)證軟件功

4、能和性能的正確性，它的典型測試項(xiàng)目包括功 能測試、性能測試、邊界測試、余量測試和強(qiáng)度測試等。2. 在會(huì)議上，由參與人員閱讀程序，利用測試數(shù)據(jù)人工進(jìn)行程序，對(duì)輸出結(jié)果進(jìn)行審查，以達(dá)到測試的目 的，這種測試方法是 。A. 軟件審查B .代碼走查C .技術(shù)評(píng)審D .代碼審查（分?jǐn)?shù)： 2.00 ）A.B. VC.D.解析：代碼審查 （包括代碼評(píng)審和走查 ） 主要依靠有經(jīng)驗(yàn)的程序設(shè)計(jì)人員根據(jù)軟件設(shè)計(jì)文檔， 通過閱讀程序， 發(fā)現(xiàn)軟件錯(cuò)誤和缺陷。代碼審查一般按代碼審查單閱讀程序，查找錯(cuò)誤。代碼審查的內(nèi)容包括：檢查代碼 和設(shè)計(jì)的一致性；檢查代碼的標(biāo)準(zhǔn)性、可讀性；檢查代碼邏輯表達(dá)的正確性和完整性；檢查代碼結(jié)構(gòu)的

5、合 理性等。代碼審查雖然在發(fā)現(xiàn)程序錯(cuò)誤上有一定的局限性，但它不需要專門的測試工具和設(shè)備，且有一旦 發(fā)現(xiàn)錯(cuò)誤就能定位錯(cuò)誤和一次發(fā)現(xiàn)一批錯(cuò)誤等優(yōu)點(diǎn)。3. 在信息系統(tǒng)工程建設(shè)過程中， 不屬于配置管理工具。A. 文檔版本信息表 B 系統(tǒng)變更流程C.系統(tǒng)用用戶權(quán)限表 D 基線（分?jǐn)?shù)： 2.00 ）A.B.C. VD.解析：軟件配置管理包括 4 個(gè)主要活動(dòng)：配型識(shí)別、變更控制、狀態(tài)報(bào)告和配置審計(jì)。軟件配置管理工具包括追蹤工具、版本管理工具和發(fā)布工具。其中選項(xiàng)A屬于版本管理，選項(xiàng) B系統(tǒng)變更流程屬于追蹤工具，選項(xiàng) D 基線屬于發(fā)布工具。選項(xiàng)C系統(tǒng)用戶權(quán)限表不屬于配置管理工具，它應(yīng)該在建立配置管理系統(tǒng)時(shí)考慮的

6、。4. 下列選項(xiàng)中不適用于判斷和評(píng)價(jià)程序復(fù)雜度的是 。A. 執(zhí)行路徑數(shù)B 算法的難易程度C. 系統(tǒng)用戶數(shù)D 程序有無注釋（分?jǐn)?shù)： 2.00 ）A.B.C. VD.解析：復(fù)雜度的種類分為模塊、類和程序三種復(fù)雜度。模塊復(fù)雜度包含了關(guān)于模塊的復(fù)雜度信息，類復(fù)雜 度是針對(duì)那些面向?qū)ο筇匦缘某绦颍岁P(guān)于類的復(fù)雜度信息；程序復(fù)雜度包含了關(guān)于程序的復(fù)雜度 信息。而判斷一個(gè)程序復(fù)雜度，從程序設(shè)計(jì)中的路徑執(zhí)行數(shù)和數(shù)據(jù)結(jié)構(gòu)與算法和在編碼時(shí)是否遵循的標(biāo)準(zhǔn)的編碼 規(guī)范與否都可以影響到在程序設(shè)計(jì)時(shí)，如果路徑設(shè)計(jì)越復(fù)雜，執(zhí)行路徑的效率就會(huì)越受到相應(yīng)的影響，程 序的易讀性也會(huì)受到影響。同一問題可以用不同算法解決，而一

7、個(gè)算法的質(zhì)量優(yōu)劣將影響到算法乃至程序的效率。算法分析的目的在 于選擇合適的算法和改進(jìn)算法，一個(gè)算法的評(píng)價(jià)主要從時(shí)間復(fù)雜度和空間復(fù)雜度來考慮。軟件開放是工程性的工作，所以要有規(guī)范，在進(jìn)行程序設(shè)計(jì)時(shí)要遵循標(biāo)準(zhǔn)的規(guī)范進(jìn)行編碼，這樣能增加軟 件的可靠性、易讀性和易維護(hù)性。5. 軟件錯(cuò)誤產(chǎn)生的原因很多， 不是導(dǎo)致軟件錯(cuò)誤的主要原因。A. 測試錯(cuò)誤B .設(shè)計(jì)錯(cuò)誤C. 編碼錯(cuò)誤D 軟件需求規(guī)格說明錯(cuò)誤（分?jǐn)?shù)： 2.00 ）A. VB.C.D.解析：在軟件開發(fā)過程中，造成錯(cuò)誤的原因有很多，比如程序員的大意造成的編碼錯(cuò)誤，語法錯(cuò)誤等。測 試是為了評(píng)價(jià)和改進(jìn)產(chǎn)品質(zhì)量、 識(shí)別產(chǎn)品的缺陷和問題而進(jìn)行的活動(dòng)。 軟件測試

8、不是導(dǎo)致軟件錯(cuò)誤的原因， 軟件測試是針對(duì)一個(gè)程序的行為，在有限測試用例集合上，動(dòng)態(tài)驗(yàn)證是否達(dá)到預(yù)期的行為，需要選取適當(dāng) 的測試用例。測試不僅是檢查預(yù)防措施是否有效的主要手段，而且是識(shí)別由于某種原因預(yù)防措施無效而產(chǎn) 生的錯(cuò)誤的主要手段。需要注意的是，在廣泛的測試活動(dòng)成功完成后，軟件可能仍有錯(cuò)誤，交付后出現(xiàn)的 軟件失效的補(bǔ)救措施是通過軟件維護(hù)來達(dá)成的。6.SOA 應(yīng)用體系架構(gòu)主要優(yōu)點(diǎn)是 。A. 提高整體性能B 有利于應(yīng)用集成C.提高安全性D 有利于硬件集成（分?jǐn)?shù)： 2.00 ）A.B. VC.D.解析：SOA即面向服務(wù)的架構(gòu)，是一種在計(jì)算機(jī)環(huán)境中設(shè)計(jì)、開發(fā)、部署和管理離散邏輯單元（服務(wù)）模型的方法

9、。在SOa模型中，所有的功能都定義成獨(dú)立的服務(wù)。服務(wù)之間通過交互和協(xié)調(diào)完成業(yè)務(wù)的整體邏輯。所有的服務(wù)通過服務(wù)總線或流程管理器來連接。SOA為企業(yè)的現(xiàn)有自查或投資帶來了更好的復(fù)用性，SOA能夠在最新的和現(xiàn)有的系統(tǒng)之上創(chuàng)建應(yīng)用，借助現(xiàn)有應(yīng)用產(chǎn)生新服務(wù)，為企業(yè)提供更好的靈活性來構(gòu)建系統(tǒng) 和業(yè)務(wù)流程，有利于應(yīng)用集成。與SOA緊密相關(guān)的技術(shù)主要有 UDDk WSDL SOAP等，這些技術(shù)都是以 XML為基礎(chǔ)發(fā)展起來的。7. 非常明確地標(biāo)明了軟件開發(fā)測試過程中存在的不同級(jí)別，且清楚地描述了這些測試階段和開發(fā)過程各階 段的對(duì)應(yīng)關(guān)系 。A. 螺旋模型B 噴泉模型C.瀑布模型D . V模型（分?jǐn)?shù)： 2.00 ）

10、A.B.C.D. V解析：V模型是軟件開發(fā)測試中最重要的一種模型。V模型大體可以劃分為下面幾個(gè)不同的階段步驟，既需求分析、概要設(shè)計(jì)、詳細(xì)設(shè)計(jì)、編碼、單元測試、 集成測試、系統(tǒng)測試、驗(yàn)收測試。需求分析：即你首先要明確客戶需要的是什么，需要軟件做成什么樣子，需要有哪幾項(xiàng)功能，這一點(diǎn)上比 較關(guān)鍵的是分析師和客戶溝通時(shí)的理解能力與交互性。要求分析師能準(zhǔn)確地把客戶所需要達(dá)到的功能，實(shí) 現(xiàn)方式等表述出來，給出分析結(jié)果，寫出規(guī)格文檔說明書。概要設(shè)計(jì)： 主要是架構(gòu)的實(shí)現(xiàn)， 指搭建架構(gòu)、 表述各模塊功能、 模塊接口連接和數(shù)據(jù)傳遞的實(shí)現(xiàn)等項(xiàng)事務(wù)。 詳細(xì)設(shè)計(jì)：對(duì)概要設(shè)計(jì)中表述的各模塊進(jìn)行深入分析，對(duì)各模塊組合進(jìn)行分

11、析等，這一階段要求達(dá)到偽代 碼級(jí)別，已經(jīng)把程序的具體實(shí)現(xiàn)的功能、現(xiàn)象等描述出來。編碼：按照詳細(xì)設(shè)計(jì)好的模塊功能表，編程人員編寫出實(shí)際的代碼。 單元測試：按照設(shè)定好的最小測試單元進(jìn)行按單元測試，主要是測試程序代碼，為的是確保各單元模塊被 正確的編譯，單元的具體劃分按不同的單位與不同的軟件有不同，比如有具體到模塊的測試，也有具體到 類、函數(shù)的測試等。集成測試：經(jīng)過了單元測試后，將各單元組合成完整的體系，主要測試各模塊間組合后的功能實(shí)現(xiàn)情況， 以及模塊接口連接的成功與否，數(shù)據(jù)傳遞的正確性等。是軟件系統(tǒng)集成過程中所進(jìn)行的測試，其主要目的 是檢查軟件單位之間的接口是否正確。它根據(jù)集成測試計(jì)劃，一邊將模塊

12、或其他軟件單位組合成越來越大 的系統(tǒng)，一邊運(yùn)行該系統(tǒng)，以分析所組成的系統(tǒng)是否正確，各組成部分是否合拍。系統(tǒng)測試：經(jīng)過了單元測試和集成測試以后，我們要把軟件系統(tǒng)搭建起來，按照軟件規(guī)格說明書中所要求 的，測試軟件其性能功能等是否和用戶需求相符合，在系統(tǒng)中運(yùn)行是否存在漏洞等。驗(yàn)收測試：主要就是用戶在拿到軟件的時(shí)候，會(huì)根據(jù)前邊所提到的需求，以及規(guī)格說明書來做相應(yīng)測試， 以確定軟件達(dá)到符合效果的。對(duì)于軟件測試過程來說，所有的測試都應(yīng)追溯到用戶需求。軟件測試的目標(biāo)在于揭示錯(cuò)誤。而最嚴(yán)重的錯(cuò) 誤(從用戶角度來看)是那些導(dǎo)致程序無法滿足需求的錯(cuò)誤，所以，V模式要求在測試工作真正開始前的較長時(shí)間內(nèi)就進(jìn)行測試計(jì)劃

13、。測試計(jì)劃可以在需求模型一完成就開始或者說應(yīng)該和需求分析一起進(jìn)行，在進(jìn) 行需求分析的時(shí)候就把系統(tǒng)測試用例根據(jù)需求文檔說明書而作出來，詳細(xì)的測試用例定義可以在概要設(shè)計(jì) 模型被確定后立即開始。因此，所有測試應(yīng)該在任何代碼被產(chǎn)生前就進(jìn)行計(jì)劃和設(shè)計(jì)。這其實(shí)是V模型占軟件開發(fā)測試模型中重要地位的原因。8. 軟件生存周期一般劃分為六個(gè)階段，包括軟件項(xiàng)目計(jì)劃、軟件需求分析和定義、軟件設(shè)計(jì)、程序編碼、 軟件測試以及 。A. 部署實(shí)施B 調(diào)整完善C 運(yùn)行維護(hù)D 結(jié)項(xiàng)驗(yàn)收(分?jǐn)?shù)： 2.00 )A.B.C. VD.解析：正如同任何事物一樣，軟件也有一個(gè)孕育、誕生、成長、成熟、衰亡的生存過程。我們稱其為計(jì)算 機(jī)軟件的

14、生周期。 根據(jù)這一思想， 把上述基本的過程活動(dòng)進(jìn)一步展開， 可以得到軟件生存周期的六個(gè)階段： 軟件項(xiàng)目計(jì)劃、軟件需求分析和定義、軟件設(shè)計(jì)、程序編碼、軟件測試以及運(yùn)行維護(hù)。9. 軟件可行性研究一般不考慮 。A. 是否有足夠的人員和資金來支持系統(tǒng)開發(fā)B. 是否有足夠的工具和相關(guān)的技術(shù)來支持C. 待開發(fā)軟件是否有市場、經(jīng)濟(jì)上是否合算D. 待開發(fā)的軟件是否會(huì)有質(zhì)量問題(分?jǐn)?shù)： 2.00 )A.B.C.D. V解析：可行性研究包括在四個(gè)方面的研究。(1) 經(jīng)濟(jì)可行性：進(jìn)行成本 / 效益分析。從經(jīng)濟(jì)角度判斷系統(tǒng)開發(fā)是否“合算”。(2) 技術(shù)可行性：進(jìn)行技術(shù)風(fēng)險(xiǎn)評(píng)價(jià)。從建設(shè)基礎(chǔ)、問題的復(fù)雜性等出發(fā)，判斷系統(tǒng)

15、開發(fā)在時(shí)間、費(fèi)用等限 制條件下成功的可能性。(3) 法律可行性：確定系統(tǒng)開發(fā)可能導(dǎo)致的任何侵權(quán)、妨礙和責(zé)任。(4) 方案的選擇：評(píng)價(jià)系統(tǒng)或產(chǎn)品開發(fā)的幾個(gè)可能的候選方案。最后給出結(jié)論意見。10. 軟件測試的目的是 。A.評(píng)價(jià)軟件的質(zhì)量 B 發(fā)現(xiàn)軟件的錯(cuò)誤C. 找出軟件的所有錯(cuò)誤 D .證明軟件是正確的分?jǐn)?shù)： 2.00 )A.B. VC.D.解析：軟件測試的目的：(1) 測試是程序的執(zhí)行過程，目的在于發(fā)現(xiàn)錯(cuò)誤；(2) 一個(gè)好的測試在于發(fā)現(xiàn)至今未發(fā)現(xiàn)的錯(cuò)誤；(3) 一個(gè)成功的測試是發(fā)現(xiàn)了至今未發(fā)現(xiàn)的錯(cuò)誤的測試。11. 屬于軟件詳細(xì)設(shè)計(jì)階段的任務(wù)。A. 算法設(shè)計(jì)B 功能設(shè)計(jì)C 調(diào)用關(guān)系設(shè)計(jì)D 輸入/輸

16、出設(shè)計(jì)(分?jǐn)?shù)： 2.00 )A. VB.C.D.解析：詳細(xì)設(shè)計(jì)階段的任務(wù)有很多，但顯然功能設(shè)計(jì)、調(diào)用關(guān)系設(shè)計(jì)、輸入 / 輸出設(shè)計(jì)都是概要設(shè)計(jì)階段的 任務(wù)。12. 需求分析中開發(fā)人員應(yīng)該主要從用戶那里了解 。A. 軟件做什么B 使用界面C 輸入的信息D 軟件的規(guī)模(分?jǐn)?shù)： 2.00 )A. VB.C.D.解析：需求分析是在可行性研究的基礎(chǔ)上，將用戶對(duì)系統(tǒng)的描述，通過開發(fā)人員的分析概括，抽象為完整 的需求定義，再形成一系列文檔的過程?？尚行匝芯恐荚谠u(píng)估目標(biāo)系統(tǒng)是否值得去開發(fā)，問題是否能夠解 決，而需求分析旨在回答“系統(tǒng)做什么”的問題， 確保將來開發(fā)出來的軟件產(chǎn)品能夠真正滿足用戶的需要。13. 下述

17、CMM四個(gè)能力成熟度等級(jí)，級(jí)別最高的是 。A.已定義級(jí)B 優(yōu)化級(jí)C 可重復(fù)級(jí)D 已管理級(jí)(分?jǐn)?shù)： 2.00 )A.B. VC.D.解析： CMMI(Capability Maturity Model Integration)，即軟件能力成熟度模型集成，是由美國國防部與卡內(nèi)基一梅隆大學(xué)和美國國防工業(yè)協(xié)會(huì)共同開發(fā)和研制的，其目的是幫助軟件企業(yè)對(duì)軟件工程過程進(jìn)行管 理和改進(jìn)，增強(qiáng)開發(fā)與改進(jìn)能力，從而能按時(shí)地、不超預(yù)算地開發(fā)出高質(zhì)量的軟件。1) 初始級(jí) 軟件過程是無序的，有時(shí)甚至是混亂的，對(duì)過程幾乎沒有定義，成功取決于個(gè)人努力。管理是反應(yīng)式的。2) 可重復(fù)級(jí) 建立了基本的項(xiàng)目管理過程來跟蹤費(fèi)用、進(jìn)度和

18、功能特性。制定了必要的過程紀(jì)律，能重復(fù)早先類似應(yīng)用 項(xiàng)目取得的成功經(jīng)驗(yàn)。3) 已定義級(jí)已將軟件管理和工程兩方面的過程文檔化、標(biāo)準(zhǔn)化，并綜合成該組織的標(biāo)準(zhǔn)軟件過程。所有項(xiàng)目均使用經(jīng) 批準(zhǔn)、剪裁的標(biāo)準(zhǔn)軟件過程來開發(fā)和維護(hù)軟件，軟件產(chǎn)品的生產(chǎn)在整個(gè)軟件過程是可見的。4) 量化管理級(jí)分析對(duì)軟件過程和產(chǎn)品質(zhì)量的詳細(xì)度量數(shù)據(jù)，對(duì)軟件過程和產(chǎn)品都有定量的理解與控制。管理有一個(gè)作出 結(jié)論的客觀依據(jù)，管理能夠在定量的范圍內(nèi)預(yù)測性能。5) 優(yōu)化管理級(jí)過程的量化反饋和先進(jìn)的新思想、新技術(shù)促使過程持續(xù)不斷改進(jìn)。14. 軟件配置項(xiàng)是軟件配置管理的對(duì)象，指的是軟件工程過程中所產(chǎn)生的A. 接口 B .軟件環(huán)境C .信息項(xiàng)D

19、 .版本(分?jǐn)?shù)： 2.00 )A.B.C. VD.解析： CSCI(Computer Software Configuration Item) 即計(jì)算機(jī)軟件配置項(xiàng)，在軟件設(shè)計(jì)文檔中經(jīng)常用到。 在配置管理中，“配置”和“配置項(xiàng)”是重要的概念，“配置”是在技術(shù)文檔中明確說明并最終組成軟件 產(chǎn)品的功能或物理屬性。因此“配置”包括了即將受控的所有產(chǎn)品特性，其內(nèi)容及相關(guān)文檔，軟件版本， 變更文檔，軟件運(yùn)行的支持?jǐn)?shù)據(jù)，以及其他一切保證軟件一致性的組成要素，相對(duì)與硬件類配置，軟件產(chǎn) 品的“配置”包括更多的內(nèi)容并具有易變性。受控軟件經(jīng)常被劃分為各類配置項(xiàng) (Configuraion items ，CIs) ，

20、這類劃分是進(jìn)行軟件配置管理的基礎(chǔ)和前 提，Cis是邏輯上組成軟件系統(tǒng)的各組成部分。比如一個(gè)軟件產(chǎn)品包括幾個(gè)程序模塊，每個(gè)程序模塊及其 相關(guān)文檔和 f 支撐數(shù)據(jù)可能被命名為一個(gè) CI 。一個(gè)系統(tǒng)包括的 CIs 的數(shù)目是一個(gè)與設(shè)計(jì)密切相關(guān)的問題， 關(guān)于怎樣將一個(gè)軟件系統(tǒng)劃分為不同的 Cis 將在以下有關(guān)章節(jié)中闡述，注意如果一個(gè)產(chǎn)品同時(shí)包括硬件和 軟件部分，一般一個(gè) Ci 也同時(shí)包括軟件和硬件部分，一個(gè)純軟件的 Ci 通常也稱之為軟件配置項(xiàng) (CSCi) 。 本規(guī)范的CI 一般指CSCI，軟硬件的配置管理有一些相通的地方，但因?yàn)檐浖子谛薷模攒浖渲?管理是一個(gè)更應(yīng)該系統(tǒng)化的過程。15. 好的

21、軟件結(jié)構(gòu)應(yīng)該是 。A.高耦合、高內(nèi)聚 B 低耦合、高內(nèi)聚C. 高耦合、低內(nèi)聚 D 低耦合、低內(nèi)聚(分?jǐn)?shù)： 2.00 )A.B. VC.D.解析：耦合性是程序結(jié)構(gòu)中各個(gè)模塊之間相互關(guān)聯(lián)的度量。它取決于各個(gè)模塊之間接口的復(fù)雜程度、調(diào)用 模塊的方式以及哪些信息通過接口。一般模塊之間可能的連接方式有七種，構(gòu)成耦合性的七種類型。它們之間的關(guān)系為(1) 非直接耦合 (Nondirect coupling) 。如果兩個(gè)模塊之間沒有直接關(guān)系，它們之間的聯(lián)系完全是通過主模 塊的控制和調(diào)用來實(shí)現(xiàn)的，這就是非直接耦合。這種耦合的模塊獨(dú)立性最強(qiáng)。(2) 數(shù)據(jù)耦合 (Data Coupling) 。如果一個(gè)模塊訪問另一

22、個(gè)模塊時(shí)， 彼此之間是通過數(shù)據(jù)參數(shù) ( 不是控制參數(shù)、 公共數(shù)據(jù)結(jié)構(gòu)或外部變量 ) 來交換輸入、 輸出信息的， 則稱這種耦合為數(shù)據(jù)耦合。由于限制了只通過參數(shù)表 傳遞數(shù)據(jù)，按數(shù)據(jù)耦合開發(fā)的程序界面簡單、安全可靠。因此，數(shù)據(jù)耦合是松散的耦合，模塊之間的獨(dú)立 性比較強(qiáng)。在軟件程序結(jié)構(gòu)中至少必須有這類耦合。(3) 標(biāo)記耦合 (Stamp Coupling) 。如果一組模塊通過參數(shù)表傳遞記錄信息，就是標(biāo)記耦合。事實(shí)上，這組模 塊共享了這個(gè)記錄，它是某一數(shù)據(jù)結(jié)構(gòu)的子結(jié)構(gòu)，而不是簡單變量。這要求這些模塊都必須清楚該記錄的 結(jié)構(gòu)，并按結(jié)構(gòu)要求對(duì)此記錄進(jìn)行操作。在設(shè)計(jì)中應(yīng)盡量避免這種耦合，它使在數(shù)據(jù)結(jié)構(gòu)上的操作

23、復(fù)雜化 了。如果采取“信息隱蔽”的方法， 把在數(shù)據(jù)結(jié)構(gòu)上的操作全部集中在一個(gè)模塊中， 就可以消除這種耦合。(4) 控制耦合 (control (Coupling) 。如果一個(gè)模塊通過傳送開關(guān)、標(biāo)志、名字等控制信息，明顯地控制選擇另一模塊的功能， 就是控制耦合。 這種耦合的實(shí)質(zhì)是在單一接口上選擇多功能模塊中的某項(xiàng)功能。因此， 對(duì)所控制模塊的任何修改，都會(huì)影響控制模塊。另外，控制耦合也意味著控制模塊必須知道所控制模塊內(nèi) 部的一些邏輯關(guān)系，這些都會(huì)降低模塊的獨(dú)立性。(5) 外部耦合 (External Coupling) 。一組模塊都訪問同一全局簡單變量而不是同一全局?jǐn)?shù)據(jù)結(jié)構(gòu)，而且不 是通過參數(shù)表傳

24、遞該全局變量的信息，則稱之為外部耦合。例如 C 語言程序中各個(gè)模塊都訪問被說明為 extern 類型的外部變量。外部耦合引起的問題類似于公共耦合，區(qū)別在于在外部耦合中不存在依賴于一個(gè) 數(shù)據(jù)結(jié)構(gòu)內(nèi)部各項(xiàng)的物理安排。(6) 公共耦合 (Common Coupling) 。若一組模塊都訪問同一個(gè)公共數(shù)據(jù)環(huán)境，則它們之間的耦合就稱為公共 耦合。公共的數(shù)據(jù)環(huán)境可以是全局?jǐn)?shù)據(jù)結(jié)構(gòu)、共享的通信區(qū)、內(nèi)存的公共覆蓋區(qū)等。內(nèi)聚 (Cohesion) 是一個(gè)模塊內(nèi)部各成分之間相關(guān)聯(lián)程度的度量。 內(nèi)聚按強(qiáng)度從低到高有以下幾種類型：(1) 偶然內(nèi)聚。如果一個(gè)模塊的各成分之間毫無關(guān)系，則稱為偶然內(nèi)聚，也就是說模塊完成一組

25、任務(wù)，這些 任務(wù)之間的關(guān)系松散，實(shí)際上沒有什么聯(lián)系。(2) 邏輯內(nèi)聚。 幾個(gè)邏輯上相關(guān)的功能被放在同一模塊中， 則稱為邏輯內(nèi)聚。 如一個(gè)模塊讀取各種不同類型 外設(shè)的輸入。盡管邏輯內(nèi)聚比偶然內(nèi)聚合理一些，但邏輯內(nèi)聚的模塊各成分在功能上并無關(guān)系，即使局部 功能的修改有時(shí)也會(huì)影響全局，因此這類模塊的修改也比較困難。(3) 時(shí)間內(nèi)聚。 如果一個(gè)模塊完成的功能必須在同一時(shí)間內(nèi)執(zhí)行 ( 如系統(tǒng)初始化 ) ，但這些功能只是因?yàn)闀r(shí)間 因素關(guān)聯(lián)在一起，則稱為時(shí)間內(nèi)聚。(4) 通信內(nèi)聚。如果一個(gè)模塊的所有成分都操作同一數(shù)據(jù)集或生成同一數(shù)據(jù)集，則稱為通信內(nèi)聚。(5) 順序內(nèi)聚 如果一個(gè)模塊的各個(gè)成分和同一個(gè)功能密切

26、相關(guān)，而且一個(gè)成分的輸出作為另一個(gè)成分的輸入，則稱為順 序內(nèi)聚。(6) 功能內(nèi)聚。模塊的所有成分對(duì)于完成單一的功能都是必需的，則稱為功能內(nèi)聚。(7) 信息內(nèi)聚。模塊完成多個(gè)功能，各個(gè)功能都在同一數(shù)據(jù)結(jié)構(gòu)上操作，每一項(xiàng)功能有一個(gè)唯一的入口點(diǎn)。 這個(gè)模塊將根據(jù)不同的要求，確定該模塊執(zhí)行哪一個(gè)功能。由于這個(gè)模塊的所有功能都是基于同一個(gè)數(shù)據(jù) 結(jié)構(gòu) ( 符號(hào)表 ) ，因此，它是一個(gè)信息內(nèi)聚的模塊。程序由許多個(gè)邏輯上相對(duì)獨(dú)立的模塊組成。模塊 (module) 是程序中邏輯上相對(duì)獨(dú)立的單元；好的軟件設(shè)計(jì) 模塊大小要適中、高內(nèi)聚、低耦合。16. 下列選項(xiàng)中，影響軟件可維護(hù)性最直接的因素是 。A. 文檔B .資

27、金C .程序代碼 D . MTTF(分?jǐn)?shù)： 2.00 )A. VB.C.D.解析：軟件可維護(hù)性定義：軟件能夠被理解、校正、適應(yīng)及增強(qiáng)功能的容易程度。軟件的可維護(hù)性、可使 用性、可靠性是衡量軟件質(zhì)量的幾個(gè)主要特性，也是用戶十分關(guān)心的幾個(gè)問題。軟件的可維護(hù)性是軟件開發(fā)階段的關(guān)鍵目標(biāo)。影響軟件可維護(hù)性的因素較多，設(shè)計(jì)、編碼及測試中的疏忽 和低劣的軟件配置，缺少文檔等都對(duì)軟件的可維護(hù)性產(chǎn)生不良影響。軟件可維護(hù)性可用下面七個(gè)質(zhì)量特性來衡量，即可理解性、可測試性、可修改性、可靠性、可移植性、可用性和效率。對(duì)于不同類型的維護(hù)，這七個(gè)特性的側(cè)重點(diǎn)也是有所不同。本題答案為A不是C。因?yàn)榧词勾a的可讀性再好，也難

28、以通過大量的閱讀代碼來得到該軟件的功能、設(shè)計(jì)等方面的有效信息。17. 軟件質(zhì)量因素不包括 。A.正確性B .高性能C .可測試性D .可理解性分?jǐn)?shù)： 2.00 )A.C.D.解析：軟件質(zhì)量反映實(shí)體滿足明確和隱含需要能力的特性綜合。(1) 明確需要，指合同中用戶明確提出的要求與需要。(2) 隱含需要，指由生產(chǎn)企業(yè)通過市場調(diào)研進(jìn)行識(shí)別與探明的要求或需要。(3) 特性，實(shí)體所特有的性質(zhì)，反映了實(shí)體滿足需要的能力。 軟件的質(zhì)量特性包括功能性、可靠性、易用性、效率、可維護(hù)性、可移植性等六個(gè)方面，每個(gè)方面都包含 若干個(gè)子特性：功能性：適合性、準(zhǔn)確性、互操作性、依從性、安全性； 可靠性：成熟性、容錯(cuò)性、易恢

29、復(fù)性；易用性：易理解性、易學(xué)性、易操作性： 效率：時(shí)間特性、資源特性；可維護(hù)性：易分析性、易改變性、穩(wěn)定性、易測試性； 可移植性：適應(yīng)性、易安裝性、遵循性、易替換性。在UML提供的圖中，一用于描述系統(tǒng)與外部系統(tǒng)及用戶之間的交互； 用于按時(shí)間順序描述對(duì)象之間的相互。(分?jǐn)?shù)： 4.00 )(1) .A .用例圖B .類圖C.對(duì)象圖D .部署圖(分?jǐn)?shù)：2.00 )A. VB.C.D.解析：.A .網(wǎng)絡(luò)圖B .狀態(tài)圖C .協(xié)作圖D .序列圖(分?jǐn)?shù)：2.00 )A.B.C.D. V解析：UML中包括九種圖：用例圖、類圖、對(duì)象圖、狀態(tài)圖、時(shí)序圖、協(xié)作圖、活動(dòng)圖、組件圖、配置圖。(1) 用例圖 (UseCa

30、seDiagram) 。描述角色以及角色與用例之間的連接關(guān)系。 說明的是誰要使用系統(tǒng)， 以及他 們使用該系統(tǒng)可以做些什么。(2) 類圖 (ClassDiagram) 。是最常用的一種圖， 類圖可以幫助我們更直觀地了解一個(gè)系統(tǒng)的體系結(jié)構(gòu)。 通過 關(guān)系和類表示的類圖，可以圖形化的方式描述一個(gè)系統(tǒng)的設(shè)計(jì)部分。(3) 對(duì)象圖。 對(duì)象圖是類圖的實(shí)例， 幾乎使用與類圖完全相同的標(biāo)識(shí)。 它們的不同點(diǎn)在于對(duì)象圖顯示類的多 個(gè)對(duì)象實(shí)例，而不是實(shí)例的類。一個(gè)對(duì)象圖是類圖的一個(gè)實(shí)例。由于對(duì)象存在生命周期，因此對(duì)象圖只能 在系統(tǒng)某一時(shí)間段存在。(4) 狀態(tài)圖。 描述一個(gè)實(shí)體基于事件反應(yīng)的動(dòng)態(tài)行為， 顯示了該實(shí)體如何根

31、據(jù)當(dāng)前所處的狀態(tài)對(duì)不同的時(shí)間 做出反應(yīng)的。(5) 時(shí)序圖。又稱順序圖，描述了對(duì)象之間動(dòng)態(tài)的交互關(guān)系，著重體現(xiàn)對(duì)象間消息傳遞的時(shí)間順序。(6) 協(xié)作圖。 協(xié)作圖用于顯示組件及其交互關(guān)系的空間組織結(jié)構(gòu)，它并不側(cè)重于交互的順序。協(xié)作圖顯示了交互中各個(gè) 對(duì)象之間的組織交互關(guān)系以及對(duì)象彼此之間的鏈接。協(xié)作圖用途：通過描繪對(duì)象之間消息的移動(dòng)情況來反映具體的方案：顯示對(duì)象及其交互關(guān)系的空間組織結(jié) 構(gòu)，而非交互的順序。活動(dòng)圖(ActivityDiagram) 。UML活動(dòng)圖記錄了單個(gè)操作或方法的邏輯，單個(gè)用戶案例，或者單個(gè)業(yè)務(wù) 流程的邏輯。 描述系統(tǒng)中各種活動(dòng)的執(zhí)行順序， 通常用于描述一個(gè)操作中所要進(jìn)行的各項(xiàng)

32、活動(dòng)的執(zhí)行流程。 同時(shí)，它也常被用來描述一個(gè)用例的處理流程，或者某種交互流程?；顒?dòng)圖由一些活動(dòng)組成，圖中同時(shí)包括了對(duì)這些活動(dòng)的說明。當(dāng)一個(gè)活動(dòng)執(zhí)行完畢之后，控制將沿著控制 轉(zhuǎn)移箭頭轉(zhuǎn)向下一個(gè)活動(dòng)。活動(dòng)圖中還可以方便地描述控制轉(zhuǎn)移的條件以及并行執(zhí)行等要求。(8) 組件圖 (ComponentDiagram) 。組件圖是用來反映代碼的物理結(jié)構(gòu)。 從組件圖中， 可以了解各軟件組件 ( 如 源代碼文件或動(dòng)態(tài)鏈接庫 ) 之間的編譯器和運(yùn)行時(shí)依賴關(guān)系。(9) 配置圖。配置圖描述系統(tǒng)中硬件和軟件的物理配置情況和系統(tǒng)體系結(jié)構(gòu)。 在配置圖中，用節(jié)點(diǎn)表示實(shí)際的物理設(shè)備，如計(jì)算機(jī)和各種外部設(shè)備等，并根據(jù)它們之間的連

33、接關(guān)系，將 相應(yīng)的節(jié)點(diǎn)連接起來，并說明其連接方式。在節(jié)點(diǎn)里面，說明分配給該節(jié)點(diǎn)上運(yùn)行的可執(zhí)行構(gòu)件或?qū)ο螅?從而說明哪些軟件單元被分配在哪些節(jié)點(diǎn)上運(yùn)行。18. 面向?qū)ο蠓治雠c設(shè)計(jì)技術(shù)中， 是類的一個(gè)實(shí)例。A. 對(duì)象B .接口 C .構(gòu)件D .設(shè)計(jì)模式(分?jǐn)?shù)： 2.00 )A. VB.C.D.解析：一個(gè)類定義了一組對(duì)象。 類具有行為 (be-havoir) ，它描述一個(gè)對(duì)象能夠做什么以及做的方法 (method) ， 它們是可以對(duì)這個(gè)對(duì)象進(jìn)行操作的程序和過程。一個(gè)對(duì)象是一個(gè)類的一個(gè)實(shí)例，它代表一個(gè)現(xiàn)實(shí)物理“事 件”，例如在一個(gè)財(cái)物系統(tǒng)數(shù)據(jù)庫中的一個(gè)顧客或一個(gè)庫存部分。類的繼承(class inhe

34、ritance) 是一個(gè)重要的概念，它為一個(gè)子類繼承它的父類的內(nèi)置描述提供了途徑。在父類中使用的代碼被向下傳給這個(gè)類指 定的一個(gè)類 ( 子類)。19. 以下關(guān)于軟件需求分析的說法中，不正確的是 。A. 需求分析需要進(jìn)行軟件功能和性能的技術(shù)實(shí)現(xiàn)方法的描述B. 需求分析文檔可用于指導(dǎo)后續(xù)的開發(fā)過程C. 軟件需求包括業(yè)務(wù)需求、用戶需求、功能需求和非功能需求等D. 軟件需求一般應(yīng)由用戶方組織進(jìn)行確認(rèn)(分?jǐn)?shù)： 2.00 )A. VB.C.D.解析：軟件需求分析是深入描述軟件的功能和性能，確定軟件設(shè)計(jì)的約束和軟件同其他系統(tǒng)元素的接口細(xì) 節(jié)，定義軟件的其他有效性需求，借助于當(dāng)前系統(tǒng)的邏輯模型導(dǎo)出目標(biāo)系統(tǒng)邏輯

35、模型，解決目標(biāo)系統(tǒng)“做 什么”的問題。但不涉及具體實(shí)現(xiàn)方法的描述，因此選項(xiàng)A錯(cuò)誤。20. 軟件的 反映了組織機(jī)構(gòu)或客戶對(duì)系統(tǒng)、產(chǎn)品高層次的目標(biāo)要求。A. 業(yè)務(wù)需求B .技術(shù)先進(jìn)性C .功能需求D .性能需求(分?jǐn)?shù)： 2.00 )A. VB.C.D.解析：軟件需求包括三個(gè)不同的層次業(yè)務(wù)需求、用戶需求和功能需求也包括非功能需求。業(yè)務(wù)需 求(business requirement)反映了組織機(jī)構(gòu)或客戶對(duì)系統(tǒng)、產(chǎn)品高層次的目標(biāo)要求，它們在項(xiàng)目視圖與范圍文檔中予以說明。用戶需求 (user requirement) 文檔描述了用戶使用產(chǎn)品必須要完成的任務(wù)，這在使用實(shí)例 (use case) 文檔或方案

36、腳本 (scenario) 說明中予以說明。功能需求 (functional requirement)定義了開發(fā)人員必須實(shí)現(xiàn)的軟件功能，使得用戶能完成他們的任務(wù)，從而滿足了業(yè)務(wù)需求。所謂特性 (feature) 是指邏輯上相關(guān)的功能需求的集合，給用戶提供處理能力并滿足業(yè)務(wù)需求。21. 統(tǒng)一建模語言UML中用來反映代碼的物理結(jié)構(gòu)的是 。A. 用例圖B 協(xié)作圖C 組件圖D 狀態(tài)圖(分?jǐn)?shù)： 2.00 )A.B.C. VD.解析：統(tǒng)一建模語言 UML中，組件圖用來反映代碼的物理結(jié)構(gòu)。組件可以是源代碼、二進(jìn)制文件或可執(zhí)行 文件，包含邏輯類的實(shí)現(xiàn)信息。組件圖是用來反映代碼的物理結(jié)構(gòu)。從組件圖中，可以了解各

37、軟件組件(如源代碼文件或動(dòng)態(tài)鏈接庫 ) 之間的編譯器和運(yùn)行時(shí)依賴關(guān)系。22. 在面向?qū)ο筌浖_發(fā)方法中，一個(gè)對(duì)象一般由 組成。A. 名稱、消息、函數(shù) B 名稱、屬性C. 對(duì)象名、屬性、消息 D 屬性、方法(分?jǐn)?shù)： 2.00 )A.B.C.D. V 解析：對(duì)象是面向?qū)ο蠓椒ㄖ凶罨镜母拍睿梢杂脕肀硎究陀^世界中的任何實(shí)體，對(duì)象是實(shí)體的抽象。 面向?qū)ο蟮某绦蛟O(shè)計(jì)方法中的對(duì)象是系統(tǒng)中用來描述客觀事物的一個(gè)實(shí)體，是構(gòu)成系統(tǒng)的一個(gè)基本單位， 由一組表示其靜態(tài)特征的屬性和它可執(zhí)行的一組操作組成。對(duì)象是屬性和方法的封裝體。屬性即對(duì)象所包含的信息，它在設(shè)計(jì)對(duì)象時(shí)確定，一般只能通過執(zhí)行對(duì)象的操作來改變。操作描述

38、了對(duì)象 執(zhí)行的功能，操作也稱為方法或服務(wù)。操作是對(duì)象的動(dòng)態(tài)屬性。配置管理是軟件質(zhì)量保證的重要一環(huán)。 軟件配置管理的基本任務(wù)包括配置標(biāo)識(shí)、 版本管理、變更管理、 和配置報(bào)告。在配置管理庫中，受控庫 (CL) 通常以 為單位建立并維護(hù)。(分?jǐn)?shù)： 4.00 )(1) .A 配置組管理B 配置對(duì)象管理 C 配置審核D 配置庫管理(分?jǐn)?shù)：2.00 )A.B.C. VD.解析：配置管理過程是對(duì)處于不斷演化、完善過程中的軟件產(chǎn)品的管理過程。其最終目標(biāo)是實(shí)現(xiàn)軟件產(chǎn)品 的完整性、一致性、可控性，使產(chǎn)品極大程度地與用戶需求相吻合。軟件配置管理的基本任務(wù)包括配置標(biāo)識(shí)、版本管理、變更管理、配置審核和配置報(bào)告。通常，受

39、控庫以軟 件配置管理項(xiàng)為單位建立并維護(hù)。.A .開發(fā)項(xiàng)目B .配置管理項(xiàng)C .子系統(tǒng)D .軟件產(chǎn)品(分?jǐn)?shù)：2.00 )A.B. VC.D.解析：23. 因?yàn)镴AVA平臺(tái)，所以具有較強(qiáng)的可移植性。A. 具有強(qiáng)大的數(shù)據(jù)操作和事務(wù)處理能力B. 采用JAVA虛擬機(jī)技術(shù)C. 可用的組件較多，功能豐富D. 適用于分布式系統(tǒng)，支持多層架構(gòu)應(yīng)用（分?jǐn)?shù)： 2.00 ）A.B. VC.D.解析： Java 平臺(tái)引入了 Java 虛擬機(jī)，具有跨平臺(tái)運(yùn)行的功能，所以具有較強(qiáng)的可移植性，能夠很好地適應(yīng)各種Web應(yīng)用。Java虛擬機(jī)（Java Virtual Machine , JVM）是軟件模擬的計(jì)算機(jī)，它可以在任何處

40、理器上（ 無論是在計(jì)算機(jī)中還是在其他電子設(shè)備中 ） 安全兼容地執(zhí)行保存在 .class 文件中的字節(jié)碼。 Java 虛擬機(jī) 的“機(jī)器碼”保存在 .class 文件中，有時(shí)也可以稱之為字節(jié)碼文件。因此，本題的答案應(yīng)選擇 B采用JAVA虛擬機(jī)技術(shù)。24. 在面向?qū)ο缶幊碳胺植际綄?duì)象技術(shù)中， 是類和接口的集合。A.對(duì)象B .組件C .實(shí)例D .屬性（分?jǐn)?shù)： 2.00 ）A.B. VC.D.解析：在面向?qū)ο缶幊桃约胺植际綄?duì)象技術(shù)中，組件是類和接口的集合，通過可重用的外部API 來滿足需求（ 功能性的以及非功能性的 ）。ISO/IEC 9126 定義的軟件質(zhì)量特性，包括功能性、可靠性、 、效率、可維護(hù)性

41、和可移植性。成熟性子特性屬于軟件的 質(zhì)量特性。（分?jǐn)?shù)： 4.00 ）.A .穩(wěn)定性B .適合性C .易用性D .準(zhǔn)確性（分?jǐn)?shù)：2.00 ）A.B.C. VD.解析：這是國標(biāo)中的原話，為概念性介紹，詳見國標(biāo) ISO/IEC 9126 。.A .功能性B .可靠性C .可維護(hù)性D .可移植性（分?jǐn)?shù)：2.00 ）A.B. VC.D.解析：25. 是系統(tǒng)建模的替代方法， 是可選的系統(tǒng)設(shè)計(jì)方法， 經(jīng)常用于系統(tǒng)開發(fā)項(xiàng)目中， 特別是用戶難以陳述或者可視化業(yè)務(wù)需求時(shí)。A.設(shè)計(jì)用例B 數(shù)據(jù)建模C 結(jié)構(gòu)化功能需求D 建立原型（分?jǐn)?shù)： 2.00 ）A.B.C.D. V 解析：本題重點(diǎn)考查考生對(duì)系統(tǒng)開發(fā)方法適用條件的

42、把握。原型化設(shè)計(jì)方法比較適合于用戶需求不清，用 戶難以陳述或者可視化業(yè)務(wù)需求時(shí)。選項(xiàng)A,設(shè)計(jì)用例較常用于系統(tǒng)測試；選項(xiàng)B,數(shù)據(jù)建模是系統(tǒng)設(shè)計(jì)時(shí)選用的基本工具；選項(xiàng) C,結(jié)構(gòu)化功能需求作為軟件工程中最早出現(xiàn)的開發(fā)方法，通常采用自頂向下、逐 層分解的原則,特別適用于需求確定的簡單項(xiàng)目。26. 面向?qū)ο箝_發(fā)技術(shù)中, 對(duì)象定義為系統(tǒng)中用來描述客觀事物的一個(gè)實(shí)體, 對(duì)象之間通過 執(zhí)行有關(guān)操作。A.信息共享B 調(diào)用C .繼承D 消息（分?jǐn)?shù)： 2.00 ）A.B.C.D. V解析：本題考查面向?qū)ο蠓椒ㄋ婕暗幕靖拍?。面向?qū)ο?對(duì)象+分類+繼承+通過消息的通信。其中消息指對(duì)象之間進(jìn)行通信的一種構(gòu)造, 對(duì)象間

43、通過消息的傳遞 / 通信去執(zhí)行某些活動(dòng)； 繼承是父類對(duì)象與子類之 間共享數(shù)據(jù)和方法的機(jī)制,是一種關(guān)系的體現(xiàn)；調(diào)用通常用于表示將程序的執(zhí)行交給其他代碼段。27. 基準(zhǔn)程序規(guī)范用于評(píng)價(jià)計(jì)算機(jī)在事務(wù)處理、數(shù)據(jù)處理、企業(yè)管理等方面的性能。A. Linpack B . SPEC C. TPC D. MFLOPS（分?jǐn)?shù)： 2.00 ）A.B.C. VD. 解析：性能評(píng)測分為“評(píng)估”和“測試”兩類方法。其中,測試是用基準(zhǔn)測試程序來度量計(jì)算機(jī)的性能；評(píng)估基本上是基于一些原始數(shù)據(jù)進(jìn)行推算，典型的有：MIPS MIFLOPS數(shù)據(jù)處理速率PDR綜合理論性能CTP等，其中：LINPACK（Fortran 語言寫成 ）

44、 基準(zhǔn)程序運(yùn)行的是實(shí)際使用程序,比理論峰值更能反映系統(tǒng)的性能。SPEC以95為例，由兩組基準(zhǔn)測試程序組成，SPEC95對(duì)計(jì)算機(jī)性能的測試有兩種不同的方法：速度測試和吞吐量或速度測試，其兩種性能輸出活動(dòng)：將處理后形成的信息傳遞給人或需要此信息的活動(dòng)。TPC基準(zhǔn)程序規(guī)范用于評(píng)價(jià)在聯(lián)機(jī)事務(wù)處理（OLTP ）環(huán)境下的數(shù)據(jù)庫和硬件的性能，不同系統(tǒng)之間用性能價(jià)格比進(jìn)行比較。MFLOPS僅僅能用來衡量機(jī)器浮點(diǎn)操作的性能，而不能體現(xiàn)機(jī)器的整體性能。28. 數(shù)據(jù)字典應(yīng)在 階段建立。A.前期規(guī)劃B .需求分析C .概要設(shè)計(jì)D .詳細(xì)設(shè)計(jì)（分?jǐn)?shù)： 2.00 ）A.B. VC.D.解析：數(shù)據(jù)字典 (Data dict

45、ionary) 是一種用戶可以訪問的記錄數(shù)據(jù)庫和應(yīng)用程序元數(shù)據(jù)的目錄。數(shù)據(jù)字典 應(yīng)在軟件系統(tǒng)的需求分析階段建立。29. 軟件質(zhì)量保證活動(dòng)應(yīng)貫穿軟件開發(fā)的全過程，下列有關(guān)敘述中不正確的是 。A. 必須及時(shí)將軟件質(zhì)量保證工作及結(jié)果通知給相關(guān)組織和個(gè)人B. 軟件質(zhì)量保證是 CMMI 1級(jí)的一個(gè)關(guān)鍵過程域C. 應(yīng)對(duì)軟件質(zhì)量進(jìn)行階段性評(píng)審，并形成完整的評(píng)審記錄D. 軟件質(zhì)量保證工作需要企業(yè)最高領(lǐng)導(dǎo)者參與(分?jǐn)?shù)： 2.00 )A.B. VC.D.解析：本題中的第 A, C和D選項(xiàng)描述都是正確的。選項(xiàng) B中，軟件質(zhì)量保證是 CMMI 2級(jí)中的一個(gè)關(guān)鍵過 程域，不屬于 CMMI 1 級(jí)的關(guān)鍵過程域。數(shù)據(jù)流程圖

46、(DFD)是一種能全面地描述信息系統(tǒng)邏輯模型的主要工具，在數(shù)據(jù)流程圖中方框表示,不屬于數(shù)據(jù)流程圖的基本成分。(分?jǐn)?shù)： 4.00 )(1) .A 數(shù)據(jù)流B 數(shù)據(jù)的源點(diǎn)或終點(diǎn)C.數(shù)據(jù)存儲(chǔ)D 加工(分?jǐn)?shù)：2.00 )A.B. VC.D.解析：(2) .A .外部實(shí)體B .處理過程C.數(shù)據(jù)結(jié)構(gòu)D 數(shù)據(jù)流(分?jǐn)?shù)：2.00 )A.B.C. VD.解析：數(shù)據(jù)流程圖(DFD)是一種能全面地描述信息系統(tǒng)邏輯模型的主要工具，它能夠采用少數(shù)幾種符號(hào)綜合地反映出信息在系統(tǒng)中的流動(dòng)、處理和存儲(chǔ)情況。數(shù)據(jù)流圖有四種基本圖形符號(hào)：箭頭，表示數(shù)據(jù)流；圓 或橢圓，表示加工；雙杠，表示數(shù)據(jù)存儲(chǔ)；方框，表示外部實(shí)體一數(shù)據(jù)的源點(diǎn)或終

47、點(diǎn)。 因此，上題中，在數(shù)據(jù)流程圖中方框表示數(shù)據(jù)的源點(diǎn)或終點(diǎn)，數(shù)據(jù)結(jié)構(gòu)不屬于數(shù)據(jù)流程圖的基本成分。30. 不是Web性能測試的基本指標(biāo)。A.響應(yīng)時(shí)間B 吞吐量C 登錄系統(tǒng)用戶數(shù) D 資源利用率(分?jǐn)?shù)： 2.00 )A.B.C. VD.解析：Web性能測試的基本指標(biāo)主要包括系統(tǒng)響應(yīng)時(shí)間、吞吐量、并發(fā)用戶數(shù)、資源利用率等。登錄系統(tǒng) 用戶數(shù)不等于系統(tǒng)的并發(fā)用戶數(shù)，因此，登錄系統(tǒng)用戶數(shù)不是Web性能測試的基本指標(biāo)。31. 常用的設(shè)計(jì)模式可分為 等三類。A.對(duì)象型、實(shí)現(xiàn)型和結(jié)構(gòu)型 B 創(chuàng)建型、結(jié)構(gòu)型和行為型C. 抽象型、過程型和實(shí)現(xiàn)型 D 創(chuàng)建型、接口型和行為型(分?jǐn)?shù)： 2.00 )A.B. VC.D.解

48、析：設(shè)計(jì)模式描述了軟件設(shè)計(jì)過程中某一類常見問題的一般性解決方案。常用的設(shè)計(jì)模式可分為三類： 創(chuàng)建型；結(jié)構(gòu)型和行為型。32. 不是基于組件的開發(fā)模型的特點(diǎn)。A. 使軟件的版本控制更為簡單B. 支持可重用組件的開發(fā)C. 與面向?qū)ο蠹夹g(shù)相結(jié)合將獲得更好的應(yīng)用效果D. 提高了項(xiàng)目開發(fā)效率，增加了項(xiàng)目開發(fā)成本(分?jǐn)?shù)： 2.00 )A.B.C.D. V解析：基于組件的開發(fā)方法是將系統(tǒng)作為組件集成體，將組件作為可重用實(shí)體來看待，通過定制和更換組 件來實(shí)現(xiàn)維護(hù)和更新。由于具有可以重用的組件，通過組件開發(fā)可以提高單個(gè)項(xiàng)目的開發(fā)效率，降低項(xiàng)目 的開發(fā)成本。因此，選項(xiàng) D是錯(cuò)誤的，其余選項(xiàng)都屬于基于組件的開發(fā)模型的

49、特點(diǎn)。33. 為擴(kuò)充功能或改善性能而進(jìn)行的修改，屬于 。A.糾錯(cuò)性維護(hù)B .適應(yīng)性維護(hù) C .預(yù)防性維護(hù)D .完善性維護(hù)(分?jǐn)?shù)： 2.00 )A.B.C.D. V解析： 1.糾錯(cuò)性維護(hù) 糾正在開發(fā)階段產(chǎn)生而在測試和驗(yàn)收過程沒有發(fā)現(xiàn)的錯(cuò)誤。其主要內(nèi)容包括：(1) 設(shè)計(jì)錯(cuò)誤； (2) 程序錯(cuò)誤； (3) 數(shù)據(jù)錯(cuò)誤： (4) 文檔錯(cuò)誤。2. 適應(yīng)性維護(hù)為適應(yīng)軟件運(yùn)行環(huán)境改變而作的修改。環(huán)境改變的主要內(nèi)容包括：(1) 影響系統(tǒng)的規(guī)則或規(guī)律的變化；(2) 硬件配置的變化，如機(jī)型、終端、外部設(shè)備的改變等；(3) 數(shù)據(jù)格式或文件結(jié)構(gòu)的改變；(4) 軟件支持環(huán)境的改變，如操作系統(tǒng)，編譯器或?qū)嵱贸绦虻淖兓取?

50、. 預(yù)防性維護(hù) 為了降低設(shè)備或系統(tǒng)失效或功能退化的概率，按預(yù)定的時(shí)間間隔或規(guī)定的標(biāo)準(zhǔn)進(jìn)行的維護(hù)。4. 完善性維護(hù)為擴(kuò)充功能或改善性能而進(jìn)行的修改。修改方式有插入、刪除、擴(kuò)充和增強(qiáng)等。主要內(nèi)容包括：（1） 為擴(kuò)充和增強(qiáng)功能而作的修改，如擴(kuò)充解題范圍和算法優(yōu)化等；（2） 為改善性能而作的修改，如提高運(yùn)行速度、節(jié)省存貯空間等；（3）為便于維護(hù)而作的修改，如為了改進(jìn)易讀性而增加一些注釋等。 綜上，為擴(kuò)充系統(tǒng)功能或改善性能而進(jìn)行的修改屬于完善性維護(hù)。34. 一般不作為需求分析階段所使用的工具或方法。A.頭腦風(fēng)暴法B . U/C矩陣C 數(shù)據(jù)流程圖D 需求跟蹤表（分?jǐn)?shù)： 2.00 ）A.B.C. VD. 解

51、析：需求分析階段是信息系統(tǒng)項(xiàng)目的前期階段，主要內(nèi)容是承建單位入場以后，系統(tǒng)分析人員與用戶進(jìn) 行交流以獲取實(shí)際需求，再根據(jù)需求編制相應(yīng)的需求規(guī)格說明書。這是一個(gè)迭代的過程，有經(jīng)驗(yàn)的分析人 員會(huì)采用召開會(huì)議（頭腦風(fēng)暴法）、U/C矩陣、需求跟蹤等方法進(jìn)行分析。而數(shù)據(jù)流程圖是設(shè)計(jì)階段用到的 工具。35. 原型法是面向用戶需求而開發(fā)的一個(gè)或多個(gè)工作模型，以下關(guān)于原型法的敘述不正確的是A.可以減少文檔的數(shù)量B 可以逐步明確系統(tǒng)的特征C. 開發(fā)人員可以從實(shí)踐中快速獲得需求D 可以改善開發(fā)人員與用戶的交流（分?jǐn)?shù)： 2.00 ）A. VB.C.D.解析：原型法是軟件開發(fā)人員慣常使用的一種方法，它可以根據(jù)用戶的需

52、求開發(fā)一個(gè)或多個(gè)工作模型，以 便快速識(shí)別用戶的需求，同時(shí)，用戶可以對(duì)照這個(gè)模型，印證實(shí)際業(yè)務(wù)將用到的需求，也可以激發(fā)思維， 更加清晰地描述業(yè)務(wù)系統(tǒng)的典型特點(diǎn)。當(dāng)系統(tǒng)開發(fā)人員與用戶就某個(gè)原型進(jìn)行溝通時(shí)，可以更加明確地了 解到用戶實(shí)際的需求，而用戶可以從原型中看到系統(tǒng)將來的雛形，也從側(cè)面堅(jiān)定了用戶的信心，有助于雙 方愉快地交流。但是，文檔作為最終展現(xiàn)系統(tǒng)成果的形式，原型法不能減少它的數(shù)量。36. 軟件需求分析方法中不屬于模型驅(qū)動(dòng)法的是 。A. SA（結(jié)構(gòu)化分析）B . IE（信息工程建模）C. OOA面向?qū)ο蠓治觯〥 . RAA（快速架構(gòu)分析）（分?jǐn)?shù)： 2.00 ）A.B.C.D. V解析：RAA（快速架構(gòu)分析）