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

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