軟件工程期末復(fù)習(xí)——填空題

軟件工程填空題1、軟件危機(jī)是指在計(jì)算機(jī)軟件的_開(kāi)發(fā)和維護(hù)_過(guò)程中所遇到的一系列嚴(yán)重問(wèn)題。2、軟件危機(jī)包含下述兩個(gè)方面的問(wèn)題：一是 _如何開(kāi)發(fā)軟件，以滿足對(duì)軟件日益增長(zhǎng)的需求；二是 _如何維護(hù)數(shù)量不斷膨脹的已有軟件_ 。3、軟件不同于硬件，它是計(jì)算機(jī)系統(tǒng)中的 _邏輯部件_ 而不是物理部件。4、一個(gè)軟件從定義、開(kāi)發(fā)、使用和維護(hù)，直到最終被廢棄，要經(jīng)歷一個(gè)漫長(zhǎng)的時(shí)期，通常把這個(gè)漫長(zhǎng)的時(shí)期稱為 _生命周期_ 。5、軟件配置主要包括 _程序、 文檔_和_數(shù)據(jù)_ 等成分。6、軟件工程學(xué)的一個(gè)重要目標(biāo)就是提高軟件的 _可維護(hù)性 、減少 _軟件維護(hù)_ 的代價(jià)。7、軟件工程是指導(dǎo)計(jì)算機(jī)軟件 _軟件開(kāi)發(fā)_ 和 _維護(hù)_ 的一門(mén)工程學(xué)科。8、軟件工程包括 _技術(shù)_ 和 _管理_ 兩方面的內(nèi)容，是技術(shù)與管理緊密結(jié)合所形成的工程學(xué)科。9、通常把在軟件生命周期全過(guò)程中使用的一整套技術(shù)方法的集合稱為 _方法學(xué)_ ，也稱為范型。10、軟件工程方法學(xué)包含_方法、工具 和_過(guò)程_ 三個(gè)要素。11、目前使用最廣泛的軟件工程方法學(xué)，分別是 _傳統(tǒng)方法學(xué) 和 面向?qū)ο蠓椒▽W(xué)_ 。12、概括地說(shuō)，軟件生命周期由 _軟件定義_ 、 _軟件開(kāi)發(fā)_ 和 _運(yùn)行維護(hù)（軟件維護(hù)）_ 個(gè)時(shí)期組成，每個(gè)時(shí)期又進(jìn)一步劃分為若干個(gè)階段。13、軟件定義時(shí)期通常進(jìn)一步劃分為個(gè)階段，即 _問(wèn)題定義_ 、 _可行性研究_ 和需求分析。、14、螺旋模型將 _瀑布、_ 模型和 _快速原型_ 模型結(jié)合起來(lái)，加入了兩種模型均忽略了的風(fēng)險(xiǎn)分析，彌補(bǔ)了這兩種模型的不足。15、瀑布模型 _不能_ 適應(yīng)需求可變的軟件開(kāi)發(fā)，只有到 _開(kāi)發(fā)結(jié)束_ 才能見(jiàn)到整個(gè)軟件系統(tǒng)。16、可行性研究階段當(dāng)從系統(tǒng)邏輯模型出發(fā)，探索若干種可供選擇的主要解法，對(duì)每種解法都應(yīng)該從 _技術(shù)可行性、經(jīng)濟(jì)可行性_和 _操作可行性_ 這三個(gè)方面研究每種解法的可行性。17、可行性研究_ 的目的就是用最小的代價(jià)在盡可能短的時(shí)間內(nèi)確定問(wèn)題是否能夠解決。18、可行性研究的目的不是解決問(wèn)題，而是確定問(wèn)題是否 _值得去解決_ 。19、_數(shù)據(jù)流圖_ 和 _數(shù)據(jù)字典_ 定義了軟件系統(tǒng)的邏輯模型，以后可以從這個(gè)邏輯模型出發(fā)設(shè)計(jì)新系統(tǒng)。20、系統(tǒng)流程圖_是概括地描繪物理系統(tǒng)的傳統(tǒng)工具。21、系統(tǒng)流程圖表達(dá)的是 _數(shù)據(jù)_ 在系統(tǒng)各部件之間流動(dòng)的情況。22、數(shù)據(jù)流圖是一種圖形化技術(shù)，它描繪 _信息流_ 和 _數(shù)據(jù)_ 從輸入移動(dòng)到輸入的過(guò)程中所經(jīng)愛(ài)的變換。23、數(shù)據(jù)流圖中的圓角矩形或圓形代表著對(duì)變換數(shù)據(jù)的 _處理_ 。24、數(shù)據(jù)流圖有種成分：源點(diǎn)或終點(diǎn)、 _處理_ 、 _數(shù)據(jù)存儲(chǔ)_ 和 _數(shù)據(jù)流_ 。25、_數(shù)據(jù)字典_ 是對(duì)數(shù)據(jù)流圖中包含的所有元素的定義的集合。26、成本效益分析的目的正是要從 _經(jīng)濟(jì)_ 角度分析開(kāi)發(fā)一個(gè)特定的新系統(tǒng)是否劃算，從而幫助客戶組織的負(fù)責(zé)人正確地作出是否投資于這項(xiàng)開(kāi)發(fā)工程的決定。27、軟件開(kāi)發(fā)成本主要表現(xiàn)為 _人力消耗_ 。28、接口需求描述應(yīng)用系統(tǒng)與它的環(huán)境通信的格式。常見(jiàn)的接口需求有： _用戶接口需求、硬件接口需求、軟件接口需求和通信接口需求。29、_逆向_ 需求說(shuō)明軟件系統(tǒng)不應(yīng)該做什么。30、訪談是最早開(kāi)始使用的獲取 的技術(shù)，它有兩種基本形式，分別是 _用戶需求、的_正式、非正式_的訪談。31、_情景分析技術(shù)_ 就是對(duì)用戶將來(lái)使用目標(biāo)系統(tǒng)解決某個(gè)具體問(wèn)題的方法和結(jié)果進(jìn)行分析，系統(tǒng)分析員利用這種技術(shù)，往往能獲知用戶的具體需求。32、_結(jié)構(gòu)化分析方法_ 是面向數(shù)據(jù)流自頂向下逐步求精進(jìn)行需求分析的方法。33、使用傳統(tǒng)的訪談或面向數(shù)據(jù)流自頂向下求精方法定義需求時(shí)，用戶處于被動(dòng)地位，為了解決這個(gè)問(wèn)題，人們研究出一種面向團(tuán)隊(duì)的需求收集法，稱為簡(jiǎn)易的 _應(yīng)用規(guī)格說(shuō)明技術(shù)_ 。34、快速原型就是快速建立起來(lái)的旨在演示目標(biāo)系統(tǒng)主要功能的可運(yùn)行的程序?？焖僭蛻?yīng)具備的第一個(gè)特性是 _快速_ 、第二個(gè)特性是 _容易修改_ 。35、需求分析階段得出的最主要文檔是_軟件需求規(guī)格說(shuō)明書(shū)_ 。36、數(shù)據(jù)對(duì)象彼此之間相互連接的方式稱為_(kāi)聯(lián)系_ ，也稱為關(guān)系。它分為一對(duì)一聯(lián)系、 _一對(duì)多_ 聯(lián)系和 _多對(duì)多_ 聯(lián)系。37、ER圖中包含了 _實(shí)體_、_關(guān)系_ 和 _屬性_ 等3種基本成分。38、按照形式化的程度，可以把軟件工程使用的方法劃分成 _非形式化_、 _半形式化_和 _形式化_類。39、有窮 _狀態(tài)機(jī)_可以準(zhǔn)確地描述一個(gè)系統(tǒng)，因此它是表達(dá)規(guī)格說(shuō)明的一種形式化方法。40、Petri網(wǎng)_可以有效地描述并發(fā)活動(dòng)。它包含種元素：一組位置、一組轉(zhuǎn)換、輸入函數(shù)以及輸出函數(shù)。41、Petri網(wǎng)的標(biāo)記是在Petri網(wǎng)中_權(quán)標(biāo)_的分配。42、在Petri網(wǎng)中，當(dāng)每個(gè)輸入線上至少有一個(gè)權(quán)標(biāo)，而 _禁止_線上沒(méi)有權(quán)標(biāo)的時(shí)候，相應(yīng)的轉(zhuǎn)換才是允許的。43、總體設(shè)計(jì)過(guò)程通常由兩個(gè)主要階段組成，分別是 _系統(tǒng)設(shè)計(jì)_階段和 _結(jié)構(gòu)設(shè)計(jì)_階段。44、需求分析階段得出的數(shù)據(jù)流圖是 _總體設(shè)計(jì)_的極好的出發(fā)點(diǎn)。45、對(duì)總體設(shè)計(jì)的結(jié)果在通過(guò)技術(shù)審查后還需由使用部門(mén)的負(fù)責(zé)人從 _管理_角度進(jìn)行復(fù)審。46、_模塊化_是把程序劃分成獨(dú)立命名且可獨(dú)立訪問(wèn)的模塊，每個(gè)模塊完成一個(gè)子功能。47、_抽象_就是抽出事物的本質(zhì)特征而暫時(shí)不考慮它們的細(xì)節(jié)。48、_逐步求精_是為了集中精力解決主要問(wèn)題而盡量推遲對(duì)問(wèn)題細(xì)節(jié)的考慮。49、定性度量模塊獨(dú)立程序的標(biāo)準(zhǔn)是_內(nèi)聚_和_耦合_。50、耦合是對(duì)一個(gè)軟件結(jié)構(gòu)內(nèi)不同模塊之間 _互連程度_程度的度量。51、_功能內(nèi)聚_是最高程度的內(nèi)聚。52、_深度_表示軟件結(jié)構(gòu)中控制的層數(shù)，它往往能粗略地標(biāo)志一個(gè)系統(tǒng)的大小和復(fù)雜程度。53、_層次_圖用于描繪軟件的層次結(jié)構(gòu)，圖中的每一個(gè)矩形框代表一個(gè) _模塊_，方框間的連線表示調(diào)用關(guān)系，而不像層次方框圖那樣表示組成關(guān)系。54、通常所說(shuō)的結(jié)構(gòu)化設(shè)計(jì)方法，也是基于_數(shù)據(jù)流的設(shè)計(jì)方法。55、信息流有兩種類型，分別是_變換流_和_事務(wù)流_。56、模塊間還經(jīng)常用帶注釋的短箭頭表示調(diào)用過(guò)程中來(lái)回傳遞的信息。有時(shí)箭頭尾部帶空心圓表示傳遞的是_數(shù)據(jù)_，帶實(shí)心圓的表示傳遞的是_控制信息_。57、模塊之間聯(lián)系越緊密，其耦合性就越_強(qiáng)_、模塊的獨(dú)立性就越_差_。58、詳細(xì)設(shè)計(jì)階段的根本目標(biāo)是確定應(yīng)該怎樣 _具體地實(shí)現(xiàn)_ 所要求的系統(tǒng)。59、詳細(xì)設(shè)計(jì)的結(jié)果基本上決定了最終的_程度代碼_ 的質(zhì)量。60、結(jié)構(gòu)程序設(shè)計(jì)語(yǔ)言的重復(fù)結(jié)構(gòu)有：_順序_ 結(jié)構(gòu)、_選擇 結(jié)構(gòu)、_循環(huán)_ 結(jié)構(gòu)三種。61、系統(tǒng)響應(yīng)時(shí)間有兩個(gè)重要屬性，分別是 _長(zhǎng)度_和_易變_ 。62、常見(jiàn)的幫助設(shè)施可分為_(kāi)集成的_ 和_附加的_ 兩類。63、描述程序處理過(guò)程的工具稱為過(guò)程設(shè)計(jì)的工具，它們可以分圖形、表格和_語(yǔ)言_ 三類。64、程序流程圖又稱為_(kāi)程序框圖_ 。65、PAD是_問(wèn)題分析圖_ 的英文縮寫(xiě)。66、McCabe方法根據(jù)程序控制流的復(fù)雜程度，這樣度量出的結(jié)果稱為程序的_環(huán)形復(fù)雜度_ 。67、在流圖中用圓表示_結(jié)點(diǎn)_ ，流圖中的箭頭線稱為_(kāi)邊_ ，它和程序流程圖中的箭頭線類似，代表_控制流_ ，由邊和結(jié)點(diǎn)圍成的面積稱為_(kāi)區(qū)域_ 。68、Halstead方法是根據(jù)程序中的_運(yùn)算符_ 和_操作數(shù)_ 的總數(shù)來(lái)度量程序的復(fù)雜程度。69、Jackson圖不僅可表示程序結(jié)構(gòu)，還可表示操作和條件。70、通常把 _編碼_ 和 _測(cè)試_ 統(tǒng)稱為實(shí)現(xiàn)。71、 所謂 _編碼_ 就是把軟件設(shè)計(jì)結(jié)果翻譯成用某種程序設(shè)計(jì)語(yǔ)言書(shū)寫(xiě)的程序。72、測(cè)試的目的就是在軟件投入生產(chǎn)性運(yùn)行之彰，盡可能多地發(fā)現(xiàn)軟件中的_錯(cuò)誤_ 。73、通過(guò)測(cè)試發(fā)現(xiàn)錯(cuò)誤之后還必須診斷并改正錯(cuò)誤，這就是 _調(diào)試_ 的目的。74、程序內(nèi)部的文檔包括恰當(dāng)?shù)?_標(biāo)識(shí)符_ 、適當(dāng)?shù)腳注解_ 和程序的_視覺(jué)組織_ 等等。75、測(cè)試是為了發(fā)現(xiàn)程序中的錯(cuò)誤而_執(zhí)行程序_ 的過(guò)程。76、應(yīng)該從“小規(guī)?！睖y(cè)試開(kāi)始，并逐步進(jìn)行“ _規(guī)模_ ”測(cè)試。77、為了達(dá)到最佳的測(cè)試效果，應(yīng)該由獨(dú)立的 _第三方_ 從事測(cè)試工作。78、 _黑盒_ 測(cè)試法把程序看成一個(gè)黑盒子，完全不考慮程序的內(nèi)部結(jié)構(gòu)和處理過(guò)程。79、 _模塊測(cè)試_ 的目的是保證每個(gè)模塊作為一個(gè)單元能正確運(yùn)行，通常又稱為單元測(cè)試。80、子系統(tǒng)測(cè)試，兼有檢測(cè)和組裝兩重含義通常稱為 _集成測(cè)試_ 。81、_驗(yàn)收測(cè)試_ 測(cè)試是在用戶積極參與下進(jìn)行的，而且可能主要使用實(shí)際數(shù)據(jù)進(jìn)行測(cè)試，也稱為_(kāi)確認(rèn)測(cè)試_ 測(cè)試。82、單元測(cè)試主要使用_白盒_ 測(cè)試技術(shù)。83、審查小組的任務(wù)是發(fā)現(xiàn)錯(cuò)誤而不是 _改正_ 錯(cuò)誤。84、人工測(cè)試源程序如果由審查小組正式地進(jìn)行，則稱為 _代碼審查_(kāi) 。85、在測(cè)試過(guò)程中，由于模塊并不是一個(gè)獨(dú)立的程序，因此必須為每個(gè)單元測(cè)試開(kāi)_驅(qū)動(dòng)程序_ 和（或） _存根程序_ 。86、由模塊組裝成程序時(shí)有兩種方式，分別是 _非漸增式_ 測(cè)試和 _漸增式_ 測(cè)試。87、目前在進(jìn)行集成測(cè)試時(shí)普遍采用_漸增式_ 測(cè)試方法。88、當(dāng)使用漸增方式把模塊結(jié)合到程序中去，有 _自頂向下_ 和 _自底向上_ 兩種集成策略。89、自頂向下集成方法中，將模塊組裝到程序結(jié)構(gòu)中時(shí)可使用的策略有深度優(yōu)先和 _寬度優(yōu)先_。90、確認(rèn)測(cè)試的目標(biāo)是驗(yàn)證軟件的_有效性_ 。91、確認(rèn)測(cè)試通常使用 _黑盒_ 測(cè)試法。92、_軟件可靠性_ 是程序在給定的時(shí)間間隔內(nèi)，按照規(guī)格說(shuō)明書(shū)的規(guī)定成功地運(yùn)行的概率。93、估計(jì)錯(cuò)誤總數(shù)的方法有_植入錯(cuò)誤法_ 和分別測(cè)試法。94、軟件工程的主要目的就是提高軟件的_可維護(hù)性_ ，減少軟件維護(hù)所需要的_工作量_，降低軟件系統(tǒng)的_總成本_ 。95、_軟件維護(hù)_ 就是在軟件交付使用后，為了改正錯(cuò)誤或滿足新的需要而修改軟件的過(guò)程。96、維護(hù)過(guò)程本質(zhì)上是修改和壓縮了的_軟件定義_ 和_開(kāi)發(fā)過(guò)程。97、決定軟件可維護(hù)性的因素主要有可理解性、可測(cè)試性、可修改性、可移植性和可重用性5個(gè)。98、軟件系統(tǒng)的文檔可以分為_(kāi)用戶文檔_和_系統(tǒng)文檔_ 兩類。99、_代碼重構(gòu)_是最常見(jiàn)的再工程活動(dòng)。100、軟件維護(hù)通常包括4類活動(dòng)，分別是改正性、適應(yīng)性、完善性和_預(yù)防性_ 維護(hù)。101、_文檔_ 是影響軟件可維護(hù)性的決定因素102、為了估算項(xiàng)目的工作量和完成期限，目前常采用 _代碼行技術(shù)_ 和 _功能點(diǎn)技術(shù)_ 兩種技術(shù)估算軟件規(guī)模。103、當(dāng)用代碼行技術(shù)估算軟件規(guī)模時(shí)，當(dāng)程序較小時(shí)，常采用的單位是 _代碼行數(shù)_（LOC），當(dāng)程序較大時(shí)，常用的單位是 _千行代碼數(shù)（KLOC）。104、功能點(diǎn)技術(shù)定義了信息域的個(gè)特性，分別是輸入項(xiàng)數(shù)、輸出項(xiàng)數(shù)、查詢數(shù)、主文件數(shù)和外部接口數(shù)。105、軟件項(xiàng)目的開(kāi)發(fā)時(shí)間最多可以減少到正常開(kāi)發(fā)時(shí)間的_75%_ 。106、在工程網(wǎng)絡(luò)中用箭頭_表示作業(yè)，用_圓圈_ 表示事件。107、Gantt圖與工程網(wǎng)絡(luò)相比，工程網(wǎng)絡(luò)_ 能顯示地定義事件及作業(yè)之間的依賴關(guān)系 Gantt圖_只能隱