軟件工程選擇題大全(修改).doc

題號題目內(nèi)容選項A選項B選項C選項D參考答案1在軟件生命周期中，能準(zhǔn)確確定軟件系統(tǒng)的體系結(jié)構(gòu)的功能階段是（ ）概要設(shè)計詳細(xì)設(shè)計需求分析可行性分析A2下面不是軟件工程的3個要素的是（ ）過程方法環(huán)境工具C3下面不屬于軟件的組成的是（ ）程序記錄文檔數(shù)據(jù)B4在瀑布模型中，將軟件分為若干個時期，軟件項目的可行性研究一般歸屬于（ ）維護(hù)時期運(yùn)行時期計劃時期開發(fā)時期C5在瀑布模型中，下面（ ）是其突出的缺點。不適應(yīng)平臺的變動不適應(yīng)算法的變動不適應(yīng)用戶需求的變動不適應(yīng)程序語言的變動C6軟件工程過程通常包含4種基本活動，下面不屬于4種活動之一的是（ ）。軟件規(guī)格說明軟件開發(fā)軟件測試軟件演進(jìn)C7下面不屬于軟件的特點的是（ ）。軟件是一種軟件產(chǎn)品軟件產(chǎn)品不會用壞，不存在磨損、消耗問題軟件產(chǎn)品的生產(chǎn)主要是研制軟件產(chǎn)品非常便宜D8文檔是描述程序、數(shù)據(jù)和系統(tǒng)開發(fā)以及使用的各種圖文資料。下面不是文檔的作用的是（ ）。記錄提供源程序維護(hù)軟件軟件產(chǎn)品介紹B9軟件開發(fā)工具是協(xié)助開發(fā)人員進(jìn)行軟件開發(fā)活動所使用的軟件或環(huán)境。下面不是軟件開發(fā)工具的是（ ）。維護(hù)工具編碼工具測試工具需求分析工具A10下列敘述中不屬于軟件生命周期模型的是（ ）。原型模型瀑布模型螺旋模型快速組裝模型D11軟件設(shè)計中，用抽象和分解的目的是() 提高易讀性降低復(fù)雜性增加內(nèi)聚性降低耦合性B12軟件由3部分組成，它們是（ ）。程序、數(shù)據(jù)和文檔程序、數(shù)據(jù)和界面數(shù)據(jù)、文檔和界面程序、界面和文檔A13軟件生命周期中所花費(fèi)用最多的階段是()詳細(xì)設(shè)計軟件編碼概要設(shè)計軟件測試和維護(hù)D14開發(fā)軟件時對提高開發(fā)人員工作效率至關(guān)重要的是（ ）。操作系統(tǒng)的資源管理功能先進(jìn)的軟件開發(fā)工具和環(huán)境程序人員的數(shù)量計算機(jī)的并行處理能力B15開發(fā)軟件所需高成本和產(chǎn)品的低質(zhì)量之間有著尖銳的矛盾，這種現(xiàn)象稱作（ ）。軟件投機(jī)軟件危機(jī)軟件工程軟件產(chǎn)生B16軟件開發(fā)的結(jié)構(gòu)化生命周期方法將軟件生命周期劃分成（ ）。定義、開發(fā)、運(yùn)行維護(hù)設(shè)計階段、編程階段、測試階段總體設(shè)計、詳細(xì)設(shè)計、編程調(diào)試需求分析、功能定義、系統(tǒng)設(shè)計 A17軟件工程的理論和技術(shù)性研究的內(nèi)容主要包括軟件開發(fā)技術(shù)和（ ）。消除軟件危機(jī)軟件工程管理程序設(shè)計自動化實現(xiàn)軟件可重用B18軟件工程的出現(xiàn)是由于（ ）。程序設(shè)計方法學(xué)的影響軟件產(chǎn)業(yè)化的需要軟件危機(jī)的出現(xiàn)計算機(jī)的發(fā)展C19在軟件生命周期中，能準(zhǔn)確地確定軟件系統(tǒng)必須做什么和必須具備哪些功能的階段是（ ）概要設(shè)計詳細(xì)設(shè)計可行性分析需求分析C20開發(fā)大型軟件時，產(chǎn)生困難的根本原因是大系統(tǒng)的復(fù)雜性人員知識不足客觀世界千變?nèi)f化時間緊、任務(wù)重A21文檔是軟件開發(fā)人員、軟件管理人員、維護(hù)人員、用戶以及計算機(jī)之間的（ ），軟件開發(fā)人員在各個階段以文檔作為前段工作成果的體現(xiàn)和后段工作的基礎(chǔ)。接口橋梁科學(xué)繼續(xù)B22軟件工程學(xué)的目的是以 較低的成本，研制（ ）質(zhì)量的軟件。較高較低可靠優(yōu)秀A23軟件從一個計算機(jī)系統(tǒng)或環(huán)境轉(zhuǎn)換到另一個計算機(jī)和環(huán)境的容易程度稱為（ ）。可用性兼容性可靠性可移植性D24軟件使不同的系統(tǒng)約束條件和用戶需求得到滿足的容易程度稱為（ ）?？捎眯约嫒菪钥煽啃钥梢浦残訠25軟件生存周期是指（ ）階段。軟件開始使用到用戶要求修改為止軟件開始使用到被淘汰為止從開始編寫程序到不能再使用為止從立項制定計劃，進(jìn)行需求分析到不能再使用為止D26軟件工程學(xué)是應(yīng)用科學(xué)理論和工程上的技術(shù)指導(dǎo)軟件開發(fā)的學(xué)科，其目的是（ ）。引入新技術(shù)提高空間利用率用較少的投資獲得高質(zhì)量的軟件縮短研制周期擴(kuò)大軟件功能硬軟件結(jié)合使系統(tǒng)面向應(yīng)用B27下列四個軟件可靠性定義中正確的是（ ）。軟件可靠性是指軟件在給定的時間間隔內(nèi)，按用戶要求成功運(yùn)行的概率軟件可靠性是指軟件在給定的時間間隔內(nèi)，按設(shè)計要求成功運(yùn)行的概率軟件可靠性是指軟件在正式投入運(yùn)行后，按規(guī)格說明書的規(guī)定成功運(yùn)行的概率軟件可靠性是指軟件在給定時間間隔內(nèi)，按規(guī)格說明書的規(guī)定成功運(yùn)行的概率B28提高程序可讀性的有力手段是（ ）。選好一種程序設(shè)計語言顯式說明一切變量使用三種標(biāo)準(zhǔn)控制語句給程序加注釋C29以下（ ）不是結(jié)構(gòu)化分析方法常用的工具。數(shù)據(jù)流圖數(shù)據(jù)字典程序流程圖判定樹C30軟件可行性分析是著重確定系統(tǒng)的目標(biāo)和規(guī)模。對成本-效益進(jìn)行發(fā)現(xiàn)應(yīng)屬于下列選項中的（ ）。經(jīng)濟(jì)可行性操作可行性技術(shù)可行性社會可行性A31在數(shù)據(jù)流圖中，用圓或者橢圓來表示（ ）。數(shù)據(jù)流加工數(shù)據(jù)存儲數(shù)據(jù)源點或終點B32軟件需求分析階段的工作，有4個方面，分別為需求評審，需求分析，編寫需求規(guī)格說明書，以及（ ）。需求獲取階段性報告總結(jié)都不正確A33下面不是軟件需求規(guī)格說明書的特點的是（ ）。正確性無歧義性完整性不可修改性D34需求分析階段的任務(wù)是確定（ ）。軟件開發(fā)方法軟件開發(fā)費(fèi)用軟件系統(tǒng)功能軟件開發(fā)工具C35通常軟件生命周期劃分為計劃、開發(fā)和運(yùn)行3個時期，下列選項中（ ）工作應(yīng)屬于軟件計劃期的內(nèi)容。可行性研究和需求分析問題定義和總體設(shè)計可行性研究和問題定義可行性研究、需求分析和問題定義C36（ ）的目的就是用最小的代價在盡可能短的時間內(nèi)確定該軟件項目是否能夠開發(fā)，是否值得去開發(fā)。需求分析概要設(shè)計總體設(shè)計可行性研究D37下列選項中（ ）不是軟件需求規(guī)格目標(biāo)。便于用戶、分析員和軟件設(shè)計人員進(jìn)行理解及交流控制系統(tǒng)的實施過程作為軟件測試和驗收以及維護(hù)的依據(jù)便于軟件的維護(hù)D38需求分析是發(fā)現(xiàn)、求精、建模的過程，最終產(chǎn)生（ ）。需求規(guī)格說明書模塊設(shè)計書合同文檔詳細(xì)設(shè)計說明書A39下面描述中，符合結(jié)構(gòu)化程序設(shè)計風(fēng)格的是（ ）。使用順序、選擇和重復(fù)（循環(huán)）三種基本控制結(jié)構(gòu)表示程序的控制邏輯模塊只有一個入口，可以有多個出口注重提高程序的執(zhí)行效率不使用goto語句 A40數(shù)據(jù)流圖用于抽象描述一個軟件的邏輯模型，數(shù)據(jù)流圖由一些特定的圖符構(gòu)成。下列圖符名標(biāo)識的圖符不屬于數(shù)據(jù)流圖合法圖符的是（ ）?？刂屏骷庸?shù)據(jù)存儲源和潭A41軟件需求分析階段的工作，可以分為四個方面：需求獲取、需求分析、編寫需求規(guī)格說明書以及（ ）。階段性報告需求評審總結(jié)都不正確 B42下列工具中屬于需求分析常用工具的是（ ）。PADPFDN-SDFDD43在數(shù)據(jù)流圖（DFD）中，帶有名字的箭頭表示（ ）?？刂瞥绦虻膱?zhí)行順序模塊之間的調(diào)用關(guān)系數(shù)據(jù)的流向程序的組成成分C44在軟件生產(chǎn)過程中，需求信息的給出是（ ）。程序員項目管理者軟件分析設(shè)計人員軟件用戶D45下列敘述中，不屬于結(jié)構(gòu)化分析方法的是（ ）。面向數(shù)據(jù)流的結(jié)構(gòu)化分析方法面向數(shù)據(jù)結(jié)構(gòu)的Jackson方法面向數(shù)據(jù)結(jié)構(gòu)的結(jié)構(gòu)化數(shù)據(jù)系統(tǒng)開發(fā)方法面向?qū)ο蟮姆治龇椒―46在軟件生命周期中，能準(zhǔn)確地確定軟件系統(tǒng)必須做什么和必須具備哪些功能的階段是（ ）。 概要設(shè)計詳細(xì)設(shè)計可行性分析需求分析D47結(jié)構(gòu)設(shè)計是一種應(yīng)用最廣泛的系統(tǒng)設(shè)計方法，是以（ ）為基礎(chǔ)、自頂向下、逐步求精和模塊化的過程。數(shù)據(jù)流數(shù)據(jù)流圖數(shù)據(jù)庫數(shù)據(jù)結(jié)構(gòu)B 48概要設(shè)計的結(jié)果是提供一份（ ）。模塊說明書框圖程序數(shù)據(jù)結(jié)構(gòu)A49需求分析是由分析員經(jīng)了解用戶的要求，認(rèn)真細(xì)致地調(diào)研、分析，最終應(yīng)建立目標(biāo)系統(tǒng)的邏輯模型并寫出（ ）。模塊說明書軟件規(guī)格說明書項目開發(fā)計劃合同文檔B501960年Dijkstra提倡的（ ）是一種有效的提高程序設(shè)計效率的方法，把程序的基本控制結(jié)構(gòu)限于順序、 選擇和循環(huán)三種，同時避免使用GOTO語句，這樣使程序結(jié)構(gòu)易于理解。標(biāo)準(zhǔn)化程序設(shè)計模塊化程序設(shè)計多道程序設(shè)計結(jié)構(gòu)化程序設(shè)計D51概要設(shè)計的任務(wù)是決定系統(tǒng)中各個模塊的外部特性 ，即其（ ）。外部特性內(nèi)部特性算法和使用數(shù)據(jù)功能和輸入輸出數(shù)據(jù)D52詳細(xì)設(shè)計的任務(wù)是決定每個模塊的內(nèi)部特性，即模塊（ ）。外部特性內(nèi)部特性算法和使用數(shù)據(jù)功能和輸入輸出數(shù)據(jù)C53結(jié)構(gòu)化分析方法以數(shù)據(jù)流圖、（ ）和加工說明等描述工具，即用直觀的圖和簡潔的語言來描述軟件系統(tǒng)模型。DFD圖PAD圖IPO圖數(shù)據(jù)字典D54在可行性研究階段，對系統(tǒng)所要求的功能、性能以及限制條件進(jìn)行分析，確定是否能夠構(gòu)成一個滿足要求的系統(tǒng)，這稱為（ ）可行性。經(jīng)濟(jì)技術(shù)法律操作B55可行性研究的目的是用最小的代價，在最短的時間內(nèi)確定問題是否可能解決和值得去解決，主要從（ ）三個方面進(jìn)行。技術(shù)可行性、費(fèi)用可行性、效益可行性經(jīng)濟(jì)可行性、技術(shù)可行性、機(jī)器可行性技術(shù)可行性、操作可行性、經(jīng)濟(jì)可行性費(fèi)用可行性、機(jī)器可行性、操作可行性C56數(shù)據(jù)字典是軟件需求分析階段的重要工具之一，它的基本功能是（ ）。數(shù)據(jù)定義數(shù)據(jù)維護(hù)數(shù)據(jù)通訊數(shù)據(jù)庫設(shè)計A57軟件總體結(jié)構(gòu)的內(nèi)容應(yīng)在（ ）文檔中闡明。軟件需求規(guī)格說明書概要設(shè)計規(guī)格說明書詳細(xì)設(shè)計規(guī)格說明書數(shù)據(jù)要求規(guī)格說明書A58需求分析說明書不能作為（ ）?？尚行匝芯康囊罁?jù)用戶和開發(fā)人員之間的合同系統(tǒng)概要設(shè)計的依據(jù)軟件驗收測試的依據(jù)A59以下（ ）不是詳細(xì)設(shè)計中常用的圖形描述工具。數(shù)據(jù)流圖程序流圖盒圖（N-S)問題分析圖（PAD）A60在結(jié)構(gòu)圖的有關(guān)術(shù)語中，用于表示軟件結(jié)構(gòu)中控制的層數(shù)的是（ ）。扇入扇出深度寬度C61模塊的獨(dú)立程度是評價設(shè)計好壞的重要標(biāo)準(zhǔn)。（ ）是衡量軟件的模塊獨(dú)立性的兩個定性度量標(biāo)準(zhǔn)。耦合性和內(nèi)聚性內(nèi)聚性和可靠性耦合性和獨(dú)立性可靠性和獨(dú)立性A62軟件設(shè)計包括（ ）兩個階段。接口設(shè)計和結(jié)構(gòu)設(shè)計概要設(shè)計和詳細(xì)設(shè)計數(shù)據(jù)設(shè)計和概要設(shè)計結(jié)構(gòu)設(shè)計和過程設(shè)計B63（ ）是一個把軟件需求轉(zhuǎn)化為軟件表示的過程，也就是把它加工為在程序細(xì)節(jié)上非常接近于源程序的軟件表示（描述），它是軟件工程的重要階段。軟件設(shè)計過程設(shè)計系統(tǒng)分析結(jié)構(gòu)設(shè)計A64軟件總體設(shè)計階段屬于軟件生命周期的（ ）階段。需求分析軟件設(shè)計編碼軟件維護(hù)B65在詳細(xì)設(shè)計階段，經(jīng)常采用的工具是（ ）。PADSASCDFDC66在軟件開發(fā)中，下面任務(wù)不屬于設(shè)計階段的是（ ）。數(shù)據(jù)結(jié)構(gòu)設(shè)計給出系統(tǒng)模塊結(jié)構(gòu)定義模塊算法定義需求并建立系統(tǒng)模型D67結(jié)構(gòu)化程序設(shè)計主要強(qiáng)調(diào)的是（ ）。程序的規(guī)模程序的易讀性程序的執(zhí)行效率程序的可移植性B68對建立良好的程序設(shè)計風(fēng)格，下面描述正確的是（ ）。程序應(yīng)簡單、清晰、可讀性好符號名的命名要符合語法充分考慮程序的執(zhí)行效率程序的注釋可有可無A69程序流程圖（PFD）中的箭頭代表的是（ ）。數(shù)據(jù)流控制流調(diào)用關(guān)系組成關(guān)系B70下面不屬于軟件設(shè)計原則的是（ ）。抽象模塊化自底向上信息隱蔽C71信息隱蔽的概念與下述哪一種概念直接相關(guān)（ ）。軟件結(jié)構(gòu)定義模塊獨(dú)立性模塊類型劃分模擬耦合度B72程序設(shè)計語言的基本成分是數(shù)據(jù)成分、運(yùn)算成分、控制成分和（ ）。對象成分變量成分語句成分傳輸成分D73在結(jié)構(gòu)化程序設(shè)計思想提出之前，在程序設(shè)計中曾強(qiáng)調(diào)程序的效率，現(xiàn)在，與程序的效率相比，人們更重視程序的（ ）。安全性一致性可理解性合理性C74為了避免流程圖在描述程序邏輯時的靈活性，提出了用方框圖來代替?zhèn)鹘y(tǒng)的程序流程圖，通常也把這種圖稱為（ ）。PAD圖N-S圖結(jié)構(gòu)圖數(shù)據(jù)流圖B75在軟件開發(fā)中，有利于發(fā)揮集體智慧的一種做法是（ ）。設(shè)計評審模塊化主程序員制進(jìn)度控制A76程序的三種基本控制結(jié)構(gòu)是順序、條件和循環(huán)，它們的共同點是（ ）。不能嵌套使用只能用來寫簡單的程序已經(jīng)用硬件實現(xiàn)只有一個入口和一個出口D77軟件的（ ）設(shè)計又稱為總體結(jié)構(gòu)設(shè)計，其主要任務(wù)是建立軟件系統(tǒng)的總體結(jié)構(gòu)。概要抽象邏輯規(guī)劃D78源程序的版面文檔要求應(yīng)有變量說明、適當(dāng)注釋和（ ）?？驁D統(tǒng)一書寫格式修改記錄編程日期B79程序編寫（實現(xiàn)）階段完成的文檔有（ ）。詳細(xì)設(shè)計說明書、模塊開發(fā)宗卷詳細(xì)設(shè)計說明書、用戶手冊模塊開發(fā)宗卷、操作手冊用戶手冊、操作手冊B80結(jié)構(gòu)化設(shè)計方法是面向（ ）的設(shè)計方法。過程對象數(shù)據(jù)流數(shù)據(jù)結(jié)構(gòu)A81軟件測試按照功能劃分可以分為（ ）。黑盒測試和單元測試白盒測試和黑盒測試集成測試和單元測試白盒測試和靜態(tài)測試B82若有一個計算類型程序，它的輸入量只有一個A，其范圍是-2.0,2.0?，F(xiàn)在輸入的角度考慮設(shè)計一組測試該程序的測試用例為-2.001,-2.0,2.0,2.001，設(shè)計這組測試用例的方法是（ ）。邊界值分析法等價類劃分法邏輯覆蓋法錯誤猜測法A83下列選項中不屬于單元測試的內(nèi)容的是（ ）。模塊接口測試局部數(shù)據(jù)結(jié)構(gòu)測試路徑測試數(shù)據(jù)測試D84在白盒測試法中的邏輯覆蓋技術(shù)中，其中發(fā)現(xiàn)錯誤能力最弱的覆蓋技術(shù)是（ ）。語句覆蓋判定覆蓋條件覆蓋數(shù)據(jù)流A85在軟件測試過程的4個步驟中，測試依據(jù)是需求規(guī)格說明的是（ ）。單元測試集成測試確認(rèn)測試系統(tǒng)測試C86軟件測試用例是指為了測試軟件而設(shè)計的一組數(shù)據(jù)，它應(yīng)該包括輸入的數(shù)據(jù)和（ ）兩部分。測試計劃測試規(guī)則以往測試記錄預(yù)期輸出結(jié)果D87軟件測試方法中，白盒測試法和黑盒測試法是常用的方法，其中白盒測試法主要用于測試（ ）。結(jié)構(gòu)合理性軟件外部功能程序正確性程序內(nèi)部邏輯D88程序測試是一項復(fù)雜的工作，一般測試者在進(jìn)行測試中都需要設(shè)計（ ）。測試用例數(shù)據(jù)結(jié)構(gòu)測試方法測試研究A89黑盒測試法屬于（ ）。集成測試系統(tǒng)測試動態(tài)測試靜態(tài)測試C90（ ）實際上是確認(rèn)在的外部環(huán)境中軟件的邏輯正確性，它應(yīng)該包括需求規(guī)格說明和程序等的確認(rèn)。動態(tài)測試靜態(tài)測試確認(rèn)測試系統(tǒng)測試B91下列測試方法中不屬于白盒測試法的是（ ）。邏輯覆蓋測試法循環(huán)測試法基本路徑測試法邊界值分析法D92下列敘述中錯誤的是（ ）。測試是為了尋找錯誤而運(yùn)行程序的過程一個成功的測試是揭示了迄今為止尚未發(fā)現(xiàn)的錯誤的測試測試的目的是為了證明程序是正確的一個好的測試用例是指很可能找到迄今為止尚未發(fā)現(xiàn)的錯誤的測試C93下列選項中不屬于動態(tài)測試法的是（ ）。白盒測試法人工測試法黑盒測試法基本路徑測試法B94軟件測試過程是軟件開發(fā)過程的逆過程，其最基礎(chǔ)性的測試應(yīng)是（ ）。集成測試單元測試有效性測試系統(tǒng)測試B95軟件測試的目的是（ ）。發(fā)現(xiàn)錯誤演示程序的功能改善軟件的性能挖掘軟件的潛能A96與設(shè)計測試數(shù)據(jù)無關(guān)的文檔是（ ）。需求說明書設(shè)計說明書源程序項目開發(fā)設(shè)計D97軟件測試中設(shè)計測試實例（test case）主要由輸入數(shù)據(jù)和（ ）兩部分組成。測試規(guī)則測試計劃預(yù)期輸出結(jié)果以往測試記錄分析C98成功的測試是指（ ）。運(yùn)行測試實例后未發(fā)現(xiàn)錯誤項發(fā)現(xiàn)程序的錯誤證明程序正確改正程序的錯誤B99單獨(dú)測試一個模塊時，有時需要一個 驅(qū)動程序驅(qū)動被測試的模塊。有時還要有一個或幾個（ ）模塊模擬由被測試模塊調(diào)用的模塊。子（Sub）仿真（Initation）棧（Stack）樁（Stub）D100在集成（聯(lián)合）測試中，測試的主要目的是發(fā)現(xiàn)（ ）階段的錯誤。軟件計劃需求分析設(shè)計編碼D101已知程序用插入法排序（升序），現(xiàn)有已排序列1，2，3，4，5?，F(xiàn)向序列中插入2，觀察插入結(jié)果是否在1之前，則采用的是（ ）測試法。黑盒白盒條件覆蓋錯誤推測A102下列所述的測試原則中，錯誤的是（ ）。應(yīng)設(shè)計非法輸入的測試用例測試用例要給出測試的預(yù)期結(jié)果因維護(hù)修改程序后需回歸測試開發(fā)小組應(yīng)與測試小組合并D103軟件調(diào)試的目的是（ ）。發(fā)現(xiàn)錯誤演示程序的功能改善軟件的性能發(fā)現(xiàn)錯誤并糾正錯誤D104下列不屬于軟件調(diào)試技術(shù)的是（ ）。強(qiáng)行排錯法集成測試法回溯法原因排除法B105軟件的維護(hù)指的是（ ）。對軟件的改進(jìn)、適應(yīng)和完善維護(hù)正常運(yùn)行配置新軟件軟件開發(fā)期的一個階段A106由于更新了操作系統(tǒng)而對軟件進(jìn)行的修改工作屬于（ ）。修正性維護(hù)適應(yīng)性維護(hù)完善性維護(hù)預(yù)防性維護(hù)B107軟件調(diào)試的方法中，（ ）是從一般原理或前提出發(fā)，經(jīng)過排除和細(xì)化的過程，推導(dǎo)出結(jié)論的方法?；厮莘w納法二分查找法演繹法D108在軟件維護(hù)中，為了加強(qiáng)、改善系統(tǒng)的功能和性能，以滿足用戶新的要求的維護(hù)稱為（ ）。適應(yīng)性維護(hù)糾錯性維護(hù)完善性維護(hù)預(yù)防性維護(hù)C109強(qiáng)行排除法是一種常用的簡單方法，下列選項中（ ）不屬于強(qiáng)行排除法。輸出內(nèi)存儲器的信息進(jìn)行回歸測試在程序中插入打印語句利用自動調(diào)試工具B110下列中不屬于軟件維護(hù)的是（ ）。糾錯性維護(hù)完善性維護(hù)檢驗性維護(hù)預(yù)防性維護(hù)C1. 軟件工程的概念是哪年提出的( ) A. 1988 B. 1968 C. 1948 D. 19282. 瀑布模型的關(guān)鍵不足在于( ) A. 過于簡單 B. 各個階段需要進(jìn)行評審 C. 過于靈活 D. 不能適應(yīng)需求的動態(tài)變更3. 以下哪一項不是軟件危機(jī)的表現(xiàn)形式( )A. 開發(fā)的軟件不滿足用戶需要 B. 開發(fā)的軟件可維護(hù)性差 C. 開發(fā)的軟件價格便宜 D. 開發(fā)的軟件可靠性差4. 軟件可行性研究實質(zhì)上是要進(jìn)行一次( )需求分析、設(shè)計過程A. 簡化、壓縮的 B. 詳細(xì)的 C. 徹底的 D. 深入的 5. 結(jié)構(gòu)化設(shè)計是一種面向( )的設(shè)計方法A. 數(shù)據(jù)流 B. 模塊 C. 數(shù)據(jù)結(jié)構(gòu) D. 程序 6. 與確認(rèn)測試階段有關(guān)的文檔是( ) A. 需求規(guī)格說明書 B. 概要設(shè)計說明書 C. 詳細(xì)設(shè)計說明書 D. 源程序7. 軟件開發(fā)的需求活動，其主要任務(wù)是（ ）A. 給出軟件解決方案 B. 給出系統(tǒng)模塊結(jié)構(gòu)C. 定義模塊算法 D. 定義需求并建立系統(tǒng)模型8. 以下說法錯誤的是( ) A. 文檔僅僅描述和規(guī)定了軟件的使用范圍及相關(guān)的操作命令 B. 文檔也是軟件產(chǎn)品的一部分，沒有文檔的軟件就不成軟件 C. 軟件文檔的編制在軟件開發(fā)工作中占有突出的地位和相當(dāng)大的工作量 D. 高質(zhì)量文檔對于發(fā)揮軟件產(chǎn)品的效益有著重要的意義 9. 一個項目是否開發(fā)，從經(jīng)濟(jì)上來說是否可行，歸根結(jié)底是取決于( )A. 成本估算 B. 項目計劃 C. 工程管理 D. 工程網(wǎng)絡(luò)圖 10. 在面向?qū)ο蟮脑O(shè)計中，我們應(yīng)遵循的設(shè)計準(zhǔn)則除了模塊化、抽象、低耦合、高內(nèi)聚以外，還有( )A. 隱藏復(fù)雜性 B. 信息隱蔽 C. 經(jīng)常類的復(fù)用 D. 類的開發(fā) 11. 面向?qū)ο蟮闹饕卣鞒龑ο笪┮恍浴⒎庋b、繼承外，還有( )A. 多態(tài)性 B. 完整性 C. 可移植性 D. 兼容性 12. 在考察系統(tǒng)的一些涉及時序和改變的狀況時，要用動態(tài)模型來表示。動態(tài)模型著重于系統(tǒng)的控制邏輯，它包括兩個圖：一個是事件追蹤圖，另一個是( )A. 數(shù)據(jù)流圖 B. 狀態(tài)圖 C. 系統(tǒng)結(jié)構(gòu)圖 D. 用例圖13. 面說法正確的是( ) A. 經(jīng)過測試沒有發(fā)現(xiàn)錯誤說明程序正確 B. 測試的目標(biāo)是為了證明程序沒有錯誤 C. 成功的測試是發(fā)現(xiàn)了迄今尚未發(fā)現(xiàn)的錯誤的測試 D. 成功的測試是沒有發(fā)現(xiàn)錯誤的測試 14. ( )能夠有效地檢測輸入條件的各種組合可能會引起的錯誤A. 等價類劃分 B. 邊界值分析 C. 錯誤推測 D. 因果圖 15 火車是一種陸上交通工具?；疖嚭完懮辖煌üぞ咧g的關(guān)系是( )關(guān)系A(chǔ). 組裝 B. 整體部分 C. has a D. 一般特殊 16、軟件維護(hù)產(chǎn)生的副作用，是指（ ）A、開發(fā)時的錯誤 B、隱含的錯誤C、因修改軟件而造成的錯誤 D、運(yùn)行時誤操作 17、使用程序設(shè)計的控制結(jié)構(gòu)導(dǎo)出測試用例的測試方法是（ ）A、黑盒測試 B、白盒測試 C、邊界測試 D、系統(tǒng)測試 18、軟件詳細(xì)設(shè)計的主要任務(wù)是確定每個模塊的（ ）A、算法和使用的數(shù)據(jù)結(jié)構(gòu) B、外部接口 C、功能 D、編程 19、軟件結(jié)構(gòu)圖的形態(tài)特征能反映程序重用率的是（ ）A、深度 B、寬度 C、扇入 D、扇出 20、為了提高模塊的獨(dú)立性，模塊內(nèi)部最好是（ ）A、邏輯內(nèi)聚 B、時間內(nèi)聚 C、功能內(nèi)聚 D、通信內(nèi)聚 21、軟件是一種（ ）A、程序 B、數(shù)據(jù) C、邏輯產(chǎn)品 D、物理產(chǎn)品 22、需求分析最終結(jié)果是產(chǎn)生（ ）A、項目開發(fā)計劃 B、需求規(guī)格說明書 C、設(shè)計說明書 D、可行性分析報告 23、因計算機(jī)硬件和軟件環(huán)境的變化而作出的修改軟件的過程稱為( ) A、糾正性維護(hù) B、適應(yīng)性維護(hù) C、完善性維護(hù) D、預(yù)防性維護(hù)24、下列屬于維護(hù)階段的文檔是( ) A、軟件規(guī)格說明 B、用戶操作手冊 C、軟件問題報告 D、軟件測試分析報告25、若有一個計算類型的程序，它的輸入量只有一個X，其范圍是-1.0，1.0，現(xiàn)從輸入的角度考慮一組測試用例：-1.001，-1.0，1.0，1.001。設(shè)計這組測試用例的方法是( ) A、條件覆蓋法 B、等價分類法 C、邊界值分析法 D、錯誤推測法26、研究開發(fā)所需要的成本和資源是屬于可行性研究中的( )研究的一方面。 A. 技術(shù)可行性 B. 經(jīng)濟(jì)可行性 C. 社會可行性 D. 法律可行性27、按軟件生命周期方法設(shè)計軟件的過程中，畫數(shù)據(jù)流圖屬于下面哪個階段的工作（ ）A、需求分析 B、程序設(shè)計 C、詳細(xì)設(shè)計 D、軟件維護(hù) 28、經(jīng)過嚴(yán)密的軟件測試后所提交給用戶的軟件產(chǎn)品中（ ）A、軟件不再包含任何錯誤 B、還可能包含少量軟件錯誤 C、所提交給用戶的可執(zhí)行文件不會含有錯誤 D、文檔中不會含有錯誤。 29、等價劃分測試方法屬于（ ） A、黑盒測試 B、白盒測試 C、邊界測試 D、系統(tǒng)測試 30、軟件按照設(shè)計的要求，在規(guī)定時間和條件下達(dá)到不出故障，持續(xù)運(yùn)行的要求的質(zhì)量特性稱為( ) A.可用性 B.可靠性 C.正確性 D.完整性31、確認(rèn)軟件的功能是否與需求規(guī)格說明書中所要求的功能相符的測試屬于（ ）A、集成測試 B、恢復(fù)測試 C、確認(rèn)測試 D、單元測試 32、要顯示描繪軟件開發(fā)項目各作業(yè)的依賴關(guān)系，應(yīng)選擇( )A.Gantt圖 B.工程網(wǎng)絡(luò) C.COCOMO模型 D.數(shù)據(jù)流圖33、從心理學(xué)角度看，對數(shù)據(jù)流程圖的數(shù)據(jù)處理泡進(jìn)行分解，一次分解為多少個泡為宜。（ ）A、31 B、72 C、151 D、18234、結(jié)構(gòu)化程序設(shè)計主要強(qiáng)調(diào)的是（ ）A、程序的規(guī)模 B、程序的效率 C、程序設(shè)計語言的先進(jìn)性 D、程序易讀性35、在用戶界面層次上對軟件進(jìn)行測試屬于哪種測試方法（ ） A、黑盒測試 B、白盒測試 C、邊界測試 D、系統(tǒng)測試 36、對象實現(xiàn)了數(shù)據(jù)和操作的結(jié)合， 使數(shù)據(jù)和操作（ ）于對象的統(tǒng)一體中 A、結(jié)合 B、隱藏 C、封裝 D、抽象37、( )是比較理想的可重用軟構(gòu)件A.子程序庫 B.源代碼包含文件 C.對象 D.類38、下列模型屬于成本估算方法的有( ) A、COCOMO模型 B、McCall模型C、McCabe度量法 D、時間估算法39、軟件生存周期中時間最長的是（ ）階段A、總體設(shè)計 B、需求分析 C、軟件測試 D、軟件維護(hù) 40、為了提高模塊的獨(dú)立性，模塊之間的聯(lián)系最好的是（ ）A、公共耦合 B、控制耦合 C、內(nèi)容耦合 D、數(shù)據(jù)耦合41、軟件概要設(shè)計結(jié)束后得到（ ）A、初始化的軟件結(jié)構(gòu)圖 B、優(yōu)化后的軟件結(jié)構(gòu)圖 C、模塊的接口圖和詳細(xì)算法 D、程序編碼 42、為使得開發(fā)人員對軟件產(chǎn)品的各個階段工作都進(jìn)行周密的思考，從而減少返工，所以（ ）的編制是很重要的A、需求說明 B、概要說明 C、軟件文檔 D、測試計劃 43、汽車有一個發(fā)動機(jī)，因而汽車與發(fā)動機(jī)之間的關(guān)系是（ ）關(guān)系A(chǔ)、一般與特殊 B、整體與部分 C、分類關(guān)系 D、is a 關(guān)系 44、軟件部件的內(nèi)部實現(xiàn)與外部可訪問性的分離，是指軟件的（ ）A、繼承性 B、共享性 C、封裝性 D、抽象性45、單元測試是發(fā)現(xiàn)編碼錯誤，集成測試是發(fā)現(xiàn)模塊的接口錯誤，確認(rèn)測試是為了發(fā)現(xiàn)功能錯誤，那么系統(tǒng)測試是為了發(fā)現(xiàn)（ ）的錯誤A、接口錯誤 B、編碼錯誤 C、性能、質(zhì)量不合要求 D、功能錯誤46、軟件工程管理對軟件項目的開發(fā)管理，即對整個軟件（ ）的一切活動的管理A、軟件項目 B、生存期 C、軟件開發(fā)計劃 D、軟件開發(fā) 47、許多產(chǎn)品的質(zhì)量問題源于新產(chǎn)品的開發(fā)設(shè)計階段，因此在產(chǎn)品（ ）階段就應(yīng)采取有力措施來消滅由于設(shè)計原因而產(chǎn)生的質(zhì)量隱患A、軟件評審 B、軟件測試 C、開發(fā)設(shè)計 D、軟件度量 48、下列幾種類型中，耦合性最弱的是（ ）A、內(nèi)容型 B、控制型 C、公共型 D、數(shù)據(jù)型 49、系統(tǒng)因錯誤而發(fā)生故障時，仍然能在一定程度上完成預(yù)期的功能，則把該軟件稱為（ ）A、軟件容錯 B、系統(tǒng)軟件 C、測試軟件 D、恢復(fù)測試50.瀑布模型的關(guān)鍵不足在于A、過于簡單 B、不能適應(yīng)需求的動態(tài)變更 C、過于靈活 D、各個階段需要進(jìn)行評審 51.在面向?qū)ο筌浖_發(fā)方法中，類與類之間主要有以下結(jié)構(gòu)關(guān)系（1） （1）繼承和聚集 （2）繼承和一般 （3）聚集和消息傳遞 （4）繼承和方法調(diào)用 52.以下哪一項不是軟件危機(jī)的表現(xiàn)形式(3) (1）成本高 （2）生產(chǎn)率低 (3)技術(shù)發(fā)展快 （4）質(zhì)量得不到保證 53.以下哪一項不是面向?qū)ο蟮奶卣鳎?） （1）多態(tài)性 （2）繼承性 （3）封裝性 （4）過程調(diào)用 54.軟件可行性研究一般不考慮（4） （1）是否有足夠的人員和相關(guān)的技術(shù)來支持系統(tǒng)開發(fā)（2）是否有足夠的工具和相關(guān)的技術(shù)來支持系統(tǒng)開發(fā)（3）待開發(fā)軟件是否有市場、經(jīng)濟(jì)上是否合算（4）待開發(fā)的軟件是否會有質(zhì)量問題55.軟件維護(hù)的副作用主要有以下哪幾種（3） （1）編碼副作用、數(shù)據(jù)副作用、測試副作用（2）編碼副作用、數(shù)據(jù)副作用、調(diào)試副作用（3）編碼副作用、數(shù)據(jù)副作用、文檔副作用（4）編碼副作用、文檔副作用、測試副作用56.軟件項目計劃一般不包括以下哪項內(nèi)容（4） （1）培訓(xùn)計劃 （2）人員安排 （3）進(jìn)度安排 （4）軟件開發(fā)標(biāo)準(zhǔn)的選擇和制定57.以下哪一項不屬于面向?qū)ο蟮能浖_發(fā)方法（3） （1)coad方法 (2)booch方法 (3)jackson方法 (4)omt方法 58.以下哪種測試方法不屬于白盒測試技術(shù)（2） （1）基本路徑測試 （2）邊界值分析測試 （3）循環(huán)覆蓋測試 （4）邏輯覆蓋測試 59. “軟件危機(jī)”是指( ) A. 計算機(jī)病毒的出現(xiàn) B. 利用計算機(jī)進(jìn)行經(jīng)濟(jì)犯罪活動 C. 軟件開發(fā)和維護(hù)中出現(xiàn)的一系列問題 D. 人們過分迷戀計算機(jī)系統(tǒng) 60. DFD中的每個加工至少需要( ) A.一個輸入流 B.一個輸出流 C.一個輸入或輸出流 D.一個輸入流和一個輸出流 61. 為了提高模塊的獨(dú)立性，模塊之間最好是( ) A. 控制耦合 B. 公共耦合 C. 內(nèi)容耦合 D. 數(shù)據(jù)耦合 62. 下面關(guān)于PDL語言不正確的說法是( ) A. PDL是描述處理過程怎么做 B. PDL是只描述加工做什么 C. PDL也稱為偽碼 D. PDL的外層語法應(yīng)符合一般程序設(shè)計語言常用的語法規(guī)則 63. 詳細(xì)設(shè)計與概要設(shè)計銜接的圖形工具是( ) A. DFD圖 B. 程序圖 C. PAD圖 D. SC圖 64. 不適合作為數(shù)據(jù)處理與數(shù)據(jù)庫應(yīng)用的語言是( ) A. SQL B. Cobol C. 4GL D. Lisp 65. 下列關(guān)于功能性注釋不正確的說法是( ) A. 功能性注釋嵌在源程序中，用于說明程序段或語句的功能以及數(shù)據(jù)的狀態(tài) B. 注釋用來說明程序段，需要在每一行都要加注釋 C. 可使用空行或縮進(jìn)，以便很容易區(qū)分注釋和程序 D. 修改程序也應(yīng)修改注釋 66. 下列關(guān)于效率的說法不正確的是( ) A. 效率是一個性能要求，其目標(biāo)應(yīng)該在需求分析時給出 B. 提高程序效率的根本途徑在于選擇良好的設(shè)計方法，數(shù)據(jù)結(jié)構(gòu)與算法 C. 效率主要指處理機(jī)時間和存儲器容量兩個方面 D. 程序的效率與程序的簡單性無關(guān) 67. 測試的關(guān)鍵問題是( ) A. 如何組織對軟件的評審 B. 如何驗證程序的正確性 C. 如何采用綜合策略 D. 如何選擇測試用例 68. 結(jié)構(gòu)化維護(hù)與非結(jié)構(gòu)化維護(hù)的主要區(qū)別在于( ) A. 軟件是否結(jié)構(gòu)化 B. 軟件配置是否完整 C. 程序的完整性 D. 文檔的完整性 69. 軟件維護(hù)困難的主要原因是( ) A. 費(fèi)用低 B. 人員少 C. 開發(fā)方法的缺陷 D. 得不到用戶支持 70. 可維護(hù)性的特性中，相互矛盾的是( ) A. 可理解性與可測試性 B. 效率與可修改性 C.可修改性和可理解性 D可理解性與可讀性 71.快速原型是利用原型輔助軟件開發(fā)的一種新思想，它是在研究( )的方法和技術(shù)中產(chǎn)生的 A. 需求階段 B. 設(shè)計階段 C. 測試階段 D. 軟件開發(fā)的各個階段 72. 從目前情況來看，增量模型存在的主要問題是( ) A. 用戶很難適應(yīng)這種系統(tǒng)開發(fā)方法 B. 該方法的成功率很低 C. 缺乏豐富而強(qiáng)有力的軟件工具和開發(fā)環(huán)境 D. 缺乏對開發(fā)過程中的問題和錯誤具有應(yīng)付變化的機(jī)制 73. 下列文檔與維護(hù)人員有關(guān)的有( ) A. 軟件需求說明書 B. 項目開發(fā)計劃 C. 概要設(shè)計說明書 D. 操作手冊 E. 實現(xiàn)錯誤檢測和錯誤恢復(fù)的程序 74. ( )是為了確保每個開發(fā)過程的質(zhì)量，防止把軟件差錯傳遞到下一個過程而進(jìn)行的工作A. 質(zhì)量檢測 B. 軟件容錯 C. 軟件維護(hù) D. 系統(tǒng)容錯 75. 表示對象相互行為的模型是( )模型。A. 動態(tài)模型 B. 功能模型 C. 對象模型 D. 靜態(tài)模型 76. CASE工具的表示集成是指CASE工具提供相同的( ) A. 編程環(huán)境 B. 用戶界面 C. 過程模型 D. 硬件/操作系統(tǒng) 77. 在軟件開發(fā)中，（）是指對將要開發(fā)的系統(tǒng)的開發(fā)成本進(jìn)行估算，然后與可能取得的效益進(jìn)行比較和權(quán)衡 A. 成本效益分析 B. 可行性分析 C. 結(jié)構(gòu)化分析 D. 軟件需求分析 78. 軟件開發(fā)過程來自用戶方面的主要干擾是（） A. 功能變化 B. 經(jīng)費(fèi)減少 C. 設(shè)備損壞 D. 人員變化 79. 軟件復(fù)雜性度量的參數(shù)包括（） A. 結(jié)構(gòu) B. 問題背景 C. 可重用性 D. 容錯性 80. 在 McCall 軟件質(zhì)量度量模型中，（）屬于面向軟件產(chǎn)品操作。 A. 可維護(hù)性 B. 效率 C. 適應(yīng)性 D. 可互操作性 81. 為了提高軟件的可維護(hù)性或可靠性而對軟件進(jìn)行的修改稱為（） A. 糾錯性維護(hù) B. 適應(yīng)性維護(hù) C. 完善性維護(hù) D. 預(yù)防性維護(hù) 82. 面向維護(hù)的技術(shù)涉及軟件開發(fā)的（）階段 A. 設(shè)計 B. 編碼 C. 測試 D. 所有 83. 用白盒技術(shù)設(shè)計測試用例的方法包括（） A. 邊界值分析 B. 條件組合覆蓋 C. 因果圖 D. 錯誤推測 84. 軟件測試的目的是（） A. 為了表明程序沒有錯誤 B. 為了說明程序能正確地執(zhí)行 C. 為了發(fā)現(xiàn)程序中的錯誤 D. 為了評價程序的質(zhì)量 85. 針對軟件需求分析所進(jìn)行的軟件測試是指（） A. 集成測試 B. 確認(rèn)測試 C. 黑盒子測試 D. 白盒子測試 86. 源程序文檔化要求在每個模塊之前加序言性注釋。該注釋內(nèi)容不應(yīng)有（） A. 模塊的功能 B. 語句的功能 C. 模塊的接口 D. 開發(fā)歷史 87. 結(jié)構(gòu)化程序設(shè)計采用的三種基本控制結(jié)構(gòu)是（） A. 順序、分支、選擇 B. 選擇、循環(huán)、重復(fù) C. 順序、選擇、循環(huán) D. 輸入、變換、輸出 88. 在軟件設(shè)計中詳細(xì)描述處理過程常用的三種工具是（） A.SA ， SD ， SP B. 程序流程圖， IPO ， PAD C.SA ， SC ， SD D. 圖形，表格，語言 89. 通信內(nèi)聚、邏輯內(nèi)聚、順序內(nèi)聚和時間內(nèi)聚的內(nèi)聚性從高到低順序是（） A. 通信、邏輯、順序、時間 B. 通信、時間、順序、邏輯 C. 順序、通信、時間、邏輯 D. 順序、通信、邏輯、時間 90. 在下列四種模塊的耦合性中，信息隱蔽性能最好的是（） A. 控制耦合 B. 內(nèi)容耦合 C. 標(biāo)記耦合 D. 數(shù)據(jù)耦合 91. 結(jié)構(gòu)化方法是一種（）的軟件開發(fā)方法A. 面向用戶 B. 面向數(shù)據(jù)結(jié)構(gòu) C. 面向?qū)ο?D. 面向數(shù)據(jù)流 92. 需求分析是回答系統(tǒng)必須（）的問題A. 做什么 B. 怎么做 C. 何時做 D. 為誰做 93. 在軟件生產(chǎn)的（），使用的工具主要是機(jī)器語言和匯編語言 A. 程序系統(tǒng)時代 B. 軟件工程時代 C.面向?qū)ο髸r代 D. 人工智能時代 94軟件工程管理的具體內(nèi)容不包括對 _ 管理A 開發(fā)人員 B 組織機(jī)構(gòu) C 控制 D 設(shè)備 95 在 McCall 軟件質(zhì)量度量模型中， _ 屬于面向軟件產(chǎn)品操作 A 正確性 B 可維護(hù)性 C 適應(yīng)性 D 互操作性 96在快速原型模型的開發(fā)過程中，用原型過程來代替全部開發(fā)階段所用模型是 _模型A 探索型原型 B 演化型原型 C 實驗型原型 D 增量型原型 97 維護(hù)中因刪除一個標(biāo)識符而引起的錯識是 _ 副作用A 文檔 B 數(shù)據(jù) C 編碼 D 設(shè)計 98軟件維護(hù)的困難主要原因是（） A 費(fèi)用低 B 人員少 C 開發(fā)方法的缺陷 D 維護(hù)難 99 用白盒法技術(shù)設(shè)計測試用例的方法包括（） A 錯誤推測 B 因果圖 C 基本路徑測試 D 邊界值分析 100軟件測試中根據(jù)測試用例設(shè)計的方法的不同可分為黑盒測試和白盒測試兩種，它們 A 前者屬于靜態(tài)測試，后者屬于動態(tài)測試 C 都屬于靜態(tài)測試B 前者屬于動態(tài)測試，后者屬于靜態(tài)測試 D 都屬于動態(tài)測試 101程序的三種基本控制結(jié)構(gòu)的共同特點是（） A 只能用來描述簡單程序 B 不能嵌套使用 C 單入口，單出口 D 僅用于自動控制系統(tǒng) 102 JSP 方法是一種面向 _ 的設(shè)計方法A 控制結(jié)構(gòu) B 對象 C 數(shù)據(jù)流 D 數(shù)據(jù)結(jié)構(gòu) 103 當(dāng)一個模塊直接使用另一個模塊的內(nèi)部數(shù)據(jù)，這種模塊之間的耦合為（） A 數(shù)據(jù)耦合 B 公共耦合 C 標(biāo)記耦合 D 內(nèi)容耦合 104 軟件設(shè)計的方法有多種， _ 方法不屬于面向數(shù)據(jù)流的設(shè)計方法A 基于 Jackson 圖的設(shè)計 B 基于 IDEF 0 圖的設(shè)計 C 交換分析設(shè)計 D 事務(wù)分析設(shè)計 105為高質(zhì)量地開發(fā)軟件項目，在軟件結(jié)構(gòu)設(shè)計時，必須遵循 _ 原則A 信息隱蔽 B 質(zhì)量控制 C 程序優(yōu)化 D 數(shù)據(jù)共享 106 數(shù)據(jù)流圖（ DFD ）是 _方法中用于表示系統(tǒng)的邏輯模型的一種圖形工具 A SA B SD C SP D SC 107螺旋模型是一種將瀑布模型和 _ 結(jié)合起來的軟件開發(fā)模型 A 增量模型 B專家系統(tǒng) C噴泉模型 D變換模型 108需求規(guī)格說明書的作用不包括（） A 軟件驗收的依據(jù) C 軟件可行性研究的依據(jù) B