軟件工程簡(jiǎn)答題復(fù)習(xí)

簡(jiǎn)答題

1、簡(jiǎn)述什么是軟件危機(jī)？

軟件危機(jī)是指在計(jì)算機(jī)軟件的開發(fā)和維護(hù)過程中所遇到的一系列嚴(yán)重問題。這些

問題絕不僅僅是"不能正常運(yùn)行的〃軟件才具有的，實(shí)際上幾乎所有軟件都不同程

度地存在這些問題。主要表現(xiàn)，如：對(duì)軟件開發(fā)成本和進(jìn)度估計(jì)不準(zhǔn)確、軟件產(chǎn)

品的質(zhì)量靠不住、用戶對(duì)“已完成的〃軟件系統(tǒng)不滿意、軟件開發(fā)速度跟不上、軟

件不可維護(hù)以及沒有適當(dāng)?shù)奈臋n資料等。

2、簡(jiǎn)述軟件質(zhì)量保證的目標(biāo)。

(1)事前預(yù)防工作，例如，著重于缺陷預(yù)防而不是缺陷檢查。

⑵盡量在剛剛引入缺陷時(shí)即將其捕獲，而不是讓缺陷擴(kuò)散到下一個(gè)階段。

(3)作用于過程而不是最終產(chǎn)品，因此它有可能會(huì)帶來廣泛的影響與巨大的收益

(4)貫穿于所有的活動(dòng)之中，而不是只集中于一點(diǎn)。

3、簡(jiǎn)述螺旋模型的優(yōu)缺點(diǎn)。

螺旋模型具有以下優(yōu)點(diǎn)：

(1)設(shè)計(jì)上的靈活性，可以在項(xiàng)目的各個(gè)階段進(jìn)行變更。

(2)以小的分段來構(gòu)建大型系統(tǒng)，使成本計(jì)算變得簡(jiǎn)單容易。

(3)客戶始終參與每個(gè)階段的開發(fā)，保證了項(xiàng)目不偏離正確方向以及項(xiàng)目的可控

性。

(4)隨著項(xiàng)目推進(jìn)，客戶始終掌握項(xiàng)目的最新信息，從而使得客戶能夠和管理層

有效地交0

⑸對(duì)可選方案和約束條件的強(qiáng)調(diào)有利于己有軟件的重用，也有助于把軟件質(zhì)作

為軟件開發(fā)的一個(gè)重要目標(biāo)。

螺旋模型也存在以下缺點(diǎn)：

螺旋模型是風(fēng)險(xiǎn)驅(qū)動(dòng)的，因此要求軟件開發(fā)人員必須具有豐富的風(fēng)險(xiǎn)評(píng)估經(jīng)驗(yàn)和

這方面的專門知識(shí)，否則將出現(xiàn)真正的風(fēng)險(xiǎn)：當(dāng)項(xiàng)目實(shí)際上正在走向?yàn)?zāi)難時(shí)，開

發(fā)人員可能還以為一切正常。所以，很難讓用戶確信這種演化方法的結(jié)果是可以

控制的。

4、哪些方法有助于提高軟件的可理解性？

以下方法都有助于提高軟件的可理解性

(1)模塊化

(2)詳細(xì)的設(shè)計(jì)文檔

⑶結(jié)構(gòu)化設(shè)計(jì)方法

⑷程序內(nèi)部的文檔

⑸良好的高級(jí)程序設(shè)計(jì)語言

5、什么是單元測(cè)試？其內(nèi)容包括哪些？

單元測(cè)試又稱為模塊測(cè)試，是針對(duì)軟件設(shè)計(jì)的最小單位一程序模塊，進(jìn)行正確性

檢驗(yàn)的測(cè)試工作，其目的在于發(fā)現(xiàn)各模塊內(nèi)部可能存在的各種差錯(cuò)。它需要從程

序內(nèi)部結(jié)構(gòu)出發(fā)設(shè)計(jì)測(cè)試用例，多個(gè)模塊可以平行地獨(dú)立進(jìn)行。

內(nèi)容：1、模塊接口測(cè)試

2、局部數(shù)據(jù)結(jié)閡測(cè)試

3、重要路徑測(cè)試

4、錯(cuò)誤處理測(cè)試

5、邊界測(cè)試

6、簡(jiǎn)述PAD的優(yōu)點(diǎn)。

⑴使用PAD符號(hào)所設(shè)計(jì)出來的程序不能進(jìn)行隨意的控制轉(zhuǎn)移，必然是結(jié)構(gòu)化程

序。

(2)PAD圖描繪程序結(jié)構(gòu)清晰，圖中豎線的總條數(shù)就是程序的層次數(shù)，所以用PAD

圖表現(xiàn)程序邏輯易讀、易懂、易記。

(3)容易將PAD圖自動(dòng)轉(zhuǎn)換為高級(jí)語言源程序。

⑷PAD圖既可以表示程序邏輯，也可用于描繪數(shù)據(jù)結(jié)構(gòu)。

⑸PAD圖的符號(hào)支持自頂向下、逐步求精方法的使用。

7、簡(jiǎn)述問題定義的規(guī)范化要求。

(1)重視問題定義，不能把其當(dāng)作一件小事

(2)客觀、全面的定義，不能避重就輕、偷工減料

(3)清楚問題定義的工作內(nèi)容，不能把問題定義當(dāng)作解決方法

⑷深入分析，抓住問題的本質(zhì)

(5)嚴(yán)格評(píng)審

8、簡(jiǎn)述瀑布模型的優(yōu)缺點(diǎn)。

瀑布模型具有下列優(yōu)點(diǎn)：

(1)可強(qiáng)迫開發(fā)人員采用規(guī)范化的方法

⑵嚴(yán)格地規(guī)定了每個(gè)階段必須提交的文檔。

⑶要求每個(gè)階段交出的所有產(chǎn)品都必須是經(jīng)過驗(yàn)證的。

瀑布模型的缺點(diǎn)：

(1)由于瀑布模型幾乎完全依賴于書面的規(guī)格說明，很可能導(dǎo)致最終開發(fā)出的軟

件產(chǎn)品不能真正滿足用戶的需要。

(2)瀑布模型只適用于項(xiàng)目開始時(shí)需求已確定的情況。

9、數(shù)據(jù)流圖的基本圖形符號(hào)包括哪些？

(1)外部實(shí)體：數(shù)據(jù)輸入源或數(shù)據(jù)輸出匯點(diǎn)，不是目標(biāo)系統(tǒng)的一部分，只是外圍

環(huán)境中的實(shí)體部分，包括人員、組織、部門或其他相關(guān)的軟件系統(tǒng)。

⑵數(shù)據(jù)流：數(shù)據(jù)在系統(tǒng)內(nèi)傳播的路徑，數(shù)據(jù)沿箭頭方向流動(dòng)。數(shù)據(jù)流可以在加

工和加工之間也可以在數(shù)據(jù)存儲(chǔ)和加工之間傳送，數(shù)據(jù)流在數(shù)據(jù)存儲(chǔ)和加工之間

傳送時(shí)含義明確，數(shù)據(jù)存儲(chǔ)就足以說明數(shù)據(jù)流，所以不必命名。同一數(shù)據(jù)流圖上

不能有同名數(shù)據(jù)流。

⑶加工：又稱數(shù)據(jù)處理，是對(duì)數(shù)據(jù)對(duì)象進(jìn)行某些處理或變換，其名稱簡(jiǎn)要的描

述完成什么加工。流入加工的可以是多個(gè)數(shù)據(jù)流，流出加工的也可以是多個(gè)數(shù)據(jù)

流。

(4)數(shù)據(jù)存儲(chǔ)：又稱數(shù)據(jù)文件，可以是數(shù)據(jù)庫文件或任何形式的數(shù)據(jù)組織。流入

數(shù)據(jù)存儲(chǔ)的數(shù)據(jù)流表示寫入數(shù)據(jù)，流出數(shù)據(jù)存儲(chǔ)的數(shù)據(jù)流表示讀出數(shù)據(jù)。

10、簡(jiǎn)述用例圖中《communicate》關(guān)系、《include》關(guān)系、《extend》關(guān)系和泛

化關(guān)系。

參與者和用例之間通過無方向的直線相連，并通過《communicate》關(guān)系進(jìn)行通

信

啟例0和用例之間可能存在包含關(guān)系，表示一個(gè)用例所執(zhí)行的功能中總是包括被包

含用例的功能，通過有向直線將具有包含關(guān)系的兩用例相連，箭頭指向被包含用

例，并在直線上標(biāo)明《include》關(guān)系。

用例和用例之間還可能存在擴(kuò)展關(guān)系，表示一個(gè)用例的執(zhí)行可能需要有其他用例

的功能來擴(kuò)展，但基本用例的功能并不依賴于擴(kuò)展用例，通過有向直線將具有擴(kuò)

展關(guān)系的兩用例相連，箭頭指向基本用例，并在直線上標(biāo)明《extend》關(guān)系。參

與者和參與者以及用例和用例之間可能存在泛化關(guān)系(也稱為繼承關(guān)系)，泛化

關(guān)系用帶空心箭頭的直線表示，箭頭指向被繼承方。

11、面向?qū)ο蟪绦蚣蓽y(cè)試策略主要有哪幾種？

⑴協(xié)作集成

⑵基于集成

⑶高頻集成

⑷基于事件(消息)的集成

⑸基于使用的集成

⑹客戶機(jī)/服務(wù)器的集成

⑺分布式集成

12、簡(jiǎn)述過程設(shè)計(jì)階段的目標(biāo)和任務(wù)。

過程設(shè)計(jì)階段的目標(biāo)是確定具體的實(shí)現(xiàn)所要求的系統(tǒng)，從而在軟件實(shí)現(xiàn)階段可以

把這個(gè)系統(tǒng)設(shè)計(jì)直接翻譯成某種程序設(shè)計(jì)語言編碼實(shí)現(xiàn)，所以過程設(shè)計(jì)最重要的

是盡可能地將各模塊的處理過程描述得簡(jiǎn)明易懂。

過程設(shè)計(jì)的任務(wù)包括：

⑴算法設(shè)計(jì)

(2)數(shù)據(jù)結(jié)構(gòu)細(xì)節(jié)和數(shù)據(jù)操作的設(shè)計(jì)

⑶輸入/輸出格式設(shè)計(jì)

(4)編寫過程設(shè)計(jì)說明書

13、什么是增量模型？有哪些優(yōu)點(diǎn)？

增量模型也稱為漸增模型，增量式開發(fā)該方法使得描述活動(dòng)、開發(fā)活動(dòng)和有效性

驗(yàn)證括動(dòng)交織在一起。系統(tǒng)的開發(fā)是建立一系列的版本(增量)，每個(gè)版本添加部

分功能到先前的版本中。

增量模型具有以下優(yōu)點(diǎn)：

(1)能在最套時(shí)間內(nèi)向用戶提交可完成一些有用的工作產(chǎn)品，即從第1個(gè)增量交

付之日起，用戶就能做一些有用的工作。

(2)逐步增加產(chǎn)品的功能可以使用戶有較充裕的時(shí)間學(xué)習(xí)和適應(yīng)新產(chǎn)品，從而減

少一個(gè)全新的軟件可能給用戶組織帶來的沖擊。

(3)項(xiàng)目失敗的風(fēng)險(xiǎn)較低，雖然在某些增量構(gòu)件中可能遇到一些問題，但其他增

量構(gòu)件將能夠成功地交付給客戶。

(4)優(yōu)先級(jí)最高的服務(wù)首先交付，然后再將其他增量逐次集成進(jìn)來。因此，最重

要的系統(tǒng)服務(wù)將接受最多的測(cè)試。

14、簡(jiǎn)述提高代碼重用性程序設(shè)計(jì)準(zhǔn)則。

⑴提高方法的內(nèi)聚

⑵減小方法的規(guī)模

⑶保持方法的一致

⑷把策略與實(shí)現(xiàn)分開

⑸全面覆蓋

⑹盡量不使用全局信息

⑺利用繼承機(jī)制

(8)使用委托機(jī)制

15、簡(jiǎn)述需求獲取的原則和步驟。

需求獲取應(yīng)遵循以下原則：

(1)深入淺出的原則。就是說，需求獲取要盡可能全面、細(xì)致，獲取的需求是個(gè)

⑵私流程/基線的原則。在與用戶云流的過程中，應(yīng)該用流程將所有的內(nèi)容串

起來，如信息組織結(jié)構(gòu)、處理規(guī)則等，這樣便于交流溝通

步驟：

⑴深入了解應(yīng)用領(lǐng)域，開發(fā)高層的業(yè)務(wù)模型

(2)定義項(xiàng)目范圍和高層需求

⑶識(shí)別用戶類型和用戶代表

⑷獲取具體的需求

⑸確定目標(biāo)系統(tǒng)的業(yè)務(wù)工作流

⑹需求整理與總結(jié)

16、簡(jiǎn)述關(guān)系數(shù)據(jù)庫管理系統(tǒng)的優(yōu)缺點(diǎn)。

優(yōu)點(diǎn)：

⑴謔供了各種最基本的數(shù)據(jù)管理功能

⑵為多種應(yīng)用提供了一致的接口。

(3)標(biāo)準(zhǔn)化的語言(大多數(shù)商品化關(guān)系數(shù)據(jù)庫管理系統(tǒng)都使用SQL語言)。

缺點(diǎn)：

⑴運(yùn)行開銷大。

⑵不能滿足高級(jí)應(yīng)用的需求

⑶與程序設(shè)計(jì)語言的連接不自然

17、簡(jiǎn)述結(jié)構(gòu)化設(shè)計(jì)的原則。

⑴模塊化

(2)低耦合、高內(nèi)聚

⑶抽象

⑷信息隱藏

⑸一致性

18、簡(jiǎn)述UML的特點(diǎn)。

⑴UML支持面向?qū)ο蠹夹g(shù)的主要概念，提供了一批基本的模型元素的表示圖形

和方法，能簡(jiǎn)潔明了地表達(dá)面向?qū)ο蟮母鞣N概念，而且容易掌握和使用。

⑵UML統(tǒng)一了各種方法對(duì)不同類型的系統(tǒng)不同開發(fā)階段以及不同內(nèi)部概念的不

同觀點(diǎn)，從而有效的消除了各種建模語言之間不必要的差異。

⑶UML建模能力比其它面向?qū)ο蠼７椒ǜ鼜?qiáng)。

⑷UML是一種建模語言，而不是一個(gè)開發(fā)過程。

⑸用UML建立的軟件系統(tǒng)模型可以用Java、VC++、dephi等任何一種面向?qū)ο?/p>

的程序設(shè)計(jì)來實(shí)現(xiàn)。

19、什么是白盒測(cè)試？白盒測(cè)試的目的是什么？

白盒測(cè)試是一種測(cè)試方法，盒子指的是被測(cè)試的軟件，白盒是指盒子內(nèi)部是可見

的，即清楚盒子內(nèi)部的東西以及里面是如何運(yùn)作的。在系統(tǒng)中出現(xiàn)一個(gè)缺陷往往

不是由一個(gè)原因?qū)е碌?，就需要通過白盒測(cè)試,提前把每個(gè)功能模塊都測(cè)試一次。

白盒測(cè)試的目的一般包括：

⑴保證程序中所有關(guān)鍵路徑都被測(cè)試到，防止系統(tǒng)投入使用后用戶發(fā)現(xiàn)系統(tǒng)問

題。

(2)便于衡量測(cè)試的完整性，即有沒有把某個(gè)功能點(diǎn)的所有可能情況都測(cè)試到。

(3)可以測(cè)試到程序中所有的真分支、假分支

(4)檢查局部數(shù)據(jù)結(jié)構(gòu)的有效性

⑸檢查程序的異常處理能力

⑹檢查代碼是否遵循編碼規(guī)范

20、通常，繼承關(guān)系的映射有哪三種方法？

(1)將基類和所有子類映射到一張表，表中包含基類和子類的所有屬性。這種方

法適用于子類的個(gè)數(shù)很少(一般只有兩個(gè))，子類和基類的屬性都比較少的情況。

(2)將每個(gè)子類映射到一張表，沒有基類表.在每個(gè)子類的表中包括基類的所有

屬性。這種方法適用于子類的個(gè)數(shù)不多，基類屬性比較少的情況。

⑶將基類映射到一張表，每個(gè)子類映射到一張表。在基類對(duì)應(yīng)的表中定義主鍵,

而在子類定義的表中定義外鍵。這種方法適用于子類的屬性和基類的屬性都比較

多的情況。

21、簡(jiǎn)述體系結(jié)構(gòu)的設(shè)計(jì)應(yīng)遵循啟發(fā)式設(shè)計(jì)原則，

⑴提高模塊獨(dú)立性

⑵模塊規(guī)模適中

⑶結(jié)構(gòu)圖的深度和寬度話中

⑷結(jié)構(gòu)圖中扇入和扇出適當(dāng)

⑸模塊的作用域應(yīng)在控制域之內(nèi)

⑹模塊功能的完善化

⑺消除重復(fù)功能，改善軟件結(jié)構(gòu)

22、簡(jiǎn)述軟件測(cè)試的原則。

⑴應(yīng)當(dāng)把〃盡早地和不斷地進(jìn)行軟件測(cè)試〃作為軟件開發(fā)者的座右銘。

⑵測(cè)試用例應(yīng)由測(cè)試輸入數(shù)據(jù)和與之對(duì)應(yīng)的預(yù)期輸出結(jié)果這兩部分組成。

⑶應(yīng)由第三方人員從事測(cè)試工作。

⑷在設(shè)計(jì)測(cè)試用例時(shí)，應(yīng)當(dāng)包括合理的輸入條件和不合理的輸入條件

(5)注意測(cè)試中的錯(cuò)誤群集現(xiàn)象

⑹嚴(yán)格執(zhí)行測(cè)試計(jì)劃，排除測(cè)試的隨意性。

⑺妥善保存測(cè)試計(jì)劃、測(cè)試用例、出錯(cuò)統(tǒng)計(jì)和最終分析報(bào)告。

23、什么是快速原型模型?有哪些優(yōu)缺點(diǎn)？

快速原型模型又稱原型模型，是增量模型的另一種形式。它是在開發(fā)真實(shí)系統(tǒng)之

前，構(gòu)造一個(gè)原型，即快速建立起來可以在計(jì)算機(jī)上運(yùn)行的程序，它所能完成的

功能往往是最終產(chǎn)品能完成的功能的一個(gè)子集。然后，在該原型的基礎(chǔ)上，逐漸

完成整個(gè)系統(tǒng)的開發(fā)工作。

快速原型模型具有如下優(yōu)點(diǎn)：

(1)有助于滿足用戶的真實(shí)需求。

(2)原型系統(tǒng)已經(jīng)通過與用戶的交互而得到驗(yàn)證，據(jù)此產(chǎn)生的規(guī)格說明文檔能夠

正確地描述用戶需求。

⑶軟件產(chǎn)品的開發(fā)基本上是按線性順序進(jìn)行。

(4)因?yàn)橐?guī)格說明文檔正確地描述了用戶需求，因此，在開發(fā)過程的后續(xù)階段不

會(huì)因?yàn)榘l(fā)現(xiàn)規(guī)格說明文檔的錯(cuò)誤而進(jìn)行較大的返工。

(5)開發(fā)人員通過建立原型系統(tǒng)已經(jīng)學(xué)到了許多東西，因此，在設(shè)計(jì)和編碼階段

發(fā)生錯(cuò)誤的可能性也比較小，這自然減少了在后續(xù)階段需要改正前面階段所犯錯(cuò)

誤的可能性。

(6)快速原型的突出特點(diǎn)是〃快速〃。開發(fā)人員應(yīng)該盡可能快地建造出原型系統(tǒng)，

以加速軟件開發(fā)過程，節(jié)約軟件開發(fā)成本。

24、簡(jiǎn)述軟件危機(jī)爆發(fā)的原因。

(1)軟件開發(fā)過程的進(jìn)展情況較難衡量，很難檢驗(yàn)開發(fā)的正確性且軟件開發(fā)的質(zhì)

量也較難評(píng)價(jià)，因此，控制軟件開發(fā)過程相當(dāng)困難：軟件維護(hù)常常意味著修改原

來的設(shè)計(jì)，維護(hù)的費(fèi)用十分驚人，使得軟件較難維護(hù)。

⑵軟件開發(fā)的過程是多人分工合作，相當(dāng)多的軟件開發(fā)人員對(duì)軟件的開發(fā)和維

護(hù)存在不少錯(cuò)誤的觀念，或多或少采用了一些錯(cuò)誤的方法和技術(shù)，這是造成軟件

危機(jī)的主要原因。

(3)開發(fā)和管理人員只重視開發(fā)而輕視問題的定義，使軟件產(chǎn)品無法滿足用戶的

要求。

(4)軟件管理技術(shù)不能滿足現(xiàn)代軟件開發(fā)的需要，沒有統(tǒng)一的軟件質(zhì)量管理規(guī)范。

(5)在軟件的開發(fā)和維護(hù)關(guān)系問題上存在錯(cuò)誤的觀念。軟件維護(hù)工作通常是在軟

件完成之后進(jìn)行的，因此是極端艱巨復(fù)雜的工作。

25、簡(jiǎn)述單例模式的要點(diǎn)。

從單例模式的要點(diǎn)：

一是某個(gè)類只能有一個(gè)實(shí)例；

二是它必須自行創(chuàng)建這個(gè)實(shí)例；

三是它必須自行向整個(gè)系統(tǒng)提供這個(gè)實(shí)例。

從具體實(shí)現(xiàn)角度來說，就是以下三點(diǎn)：

一是單例模式的類只提供私有的構(gòu)造函數(shù)；

二是類定義中含有一個(gè)該類的靜態(tài)私有對(duì)象；

三是該類提供了一個(gè)靜態(tài)的公有的方法，用于創(chuàng)建或獲取它本身的靜態(tài)私有對(duì)象。

26、軟件維護(hù)存在哪些問題？

1)理解別人寫的程序通常非常困難，而且困難程度隨著軟件配置成分的減少而

迅速增加。如果僅有程序代碼沒有說明文檔，則會(huì)出現(xiàn)嚴(yán)重的問題。

(2)需要維護(hù)的軟件往往沒有合格的文檔，或者文檔資料顯著不足。認(rèn)識(shí)到軟件

必須有文檔僅僅是第一步，容易理解的并且和程序代碼完全一致的文檔才真正有

價(jià)值。

(3)當(dāng)要求對(duì)軟件進(jìn)行維護(hù)時(shí)，不能指望由開發(fā)人員給人們仔細(xì)說明軟件。由于

維護(hù)階段持續(xù)的時(shí)間很長(zhǎng)，因此，當(dāng)需要解釋軟件時(shí)，往往原來寫程序的人已經(jīng)

不在附近了。

(4)絕大多數(shù)軟件在設(shè)計(jì)時(shí)沒有考慮將來的修改。除非使用強(qiáng)調(diào)模塊獨(dú)立原理的

設(shè)計(jì)方法學(xué)否則修改軟件既困難又容易發(fā)生差錯(cuò)。

(5)軟件維護(hù)不是一項(xiàng)吸引人的工作。形成這種觀念很大程度上是因?yàn)榫S護(hù)工作

經(jīng)常遭受挫折。

27、簡(jiǎn)述PDL語言的優(yōu)點(diǎn)。

⑴可以作為注釋直接插在源程序中間。

(2)可以使用普通的文字處理系統(tǒng)，很方便地完成PDL的編輯。

⑶可以自動(dòng)由PDL生成程序代碼

28、軟件維護(hù)報(bào)告包含哪些信息？

⑴滿足維護(hù)要求表中提出的要求所需要的工作

⑵維護(hù)要求的性質(zhì)

⑶這項(xiàng)要求的優(yōu)先次序

⑷與修改有關(guān)的事后數(shù)據(jù)

29、簡(jiǎn)述敏捷開發(fā)的原則。

⑴快速迭代

⑵讓測(cè)試人員和開發(fā)者參與需求討論

⑶編寫可測(cè)試的需求文檔

⑷多溝通，盡量減少文檔

⑸做好產(chǎn)品原型

⑹及早考慮測(cè)試

30、IOS9126軟件質(zhì)量模型。

它由6個(gè)特性和27個(gè)子特性組成，這個(gè)模型是軟件質(zhì)量標(biāo)準(zhǔn)的核心，對(duì)于大部

分的軟件，都可以考慮從這幾個(gè)方面著手進(jìn)行測(cè)評(píng)。

(1)功能性：軟件所實(shí)現(xiàn)的功能達(dá)到它的設(shè)計(jì)規(guī)范和滿足用戶需求的程度。

⑵可靠性：在滿足一定條件的應(yīng)用環(huán)境中軟件能夠正常維持其工作的能力。

(3)可用性：對(duì)于一個(gè)軟件，用戶在學(xué)習(xí)、操作和理解過程中所做努力的程度。

(4)效率：在規(guī)定條件下，用軟件實(shí)現(xiàn)某種功能所需的計(jì)算機(jī)資源(包括時(shí)間)的有

效程度。

⑸維護(hù)性：當(dāng)環(huán)境改變或軟件運(yùn)行發(fā)生故障時(shí)，為使其恢復(fù)正常運(yùn)行所做努力

的程度。

(6)可移植性：為使一個(gè)軟件從現(xiàn)有運(yùn)行平臺(tái)向另一個(gè)運(yùn)行平臺(tái)過度所做努力的

程度。

客觀題

1、引起軟件改變的原因主要有：運(yùn)行環(huán)境變化、需求變化、系統(tǒng)有錯(cuò)。

2、在UML中，通過建立類圖來表示對(duì)象模型。

3、面對(duì)對(duì)象設(shè)計(jì)模型中的數(shù)據(jù)結(jié)構(gòu)對(duì)應(yīng)分析模型中的屬性。

4、面對(duì)對(duì)象分析模型包括：功能模型、對(duì)象模型、動(dòng)態(tài)模型。

5、各種軟件維護(hù)的類型中最重要的是完善性維護(hù)。

6、在類圖中，表示繼承關(guān)系的是空心箭頭。

7,軟件生命周期的最后一個(gè)階段是軟件維護(hù)。

8、屬于軟件項(xiàng)目管理白勺是：軟件過程能力評(píng)估、風(fēng)險(xiǎn)管理、質(zhì)量監(jiān)控。

9、UML的全稱是UnifiedModelingLanguage。

10、張三辦公用的那臺(tái)計(jì)算機(jī)是實(shí)例。

11、冰箱和海爾冰箱這兩個(gè)事物之間是泛也關(guān)系。

12、通過執(zhí)行對(duì)象的操作改變?cè)搶?duì)象的屬性，必須通過消息的傳遞。

13、UML中，包圖是一種分組機(jī)制。

14、信息隱藏概念與模塊的獨(dú)立性概念直接相關(guān)。

15、UML中描述類與類之間關(guān)系的圖是類圖。

1G、軟件維護(hù)產(chǎn)生的副作用，是指因修改軟件而產(chǎn)生的錯(cuò)誤。

17、屬于軟件開發(fā)項(xiàng)E風(fēng)險(xiǎn)的是：關(guān)鍵技術(shù)人員流失。

18、軟件按照設(shè)計(jì)要求，在規(guī)定時(shí)間和條件下不出故障，持續(xù)運(yùn)行的程度。屬于

可靠性軟件質(zhì)量要素。

19、屬于面向?qū)ο蠓椒▋?yōu)點(diǎn)的是：穩(wěn)定性好、可宜用性好、與人類習(xí)慣的思維方

法一致。

20、類的行為應(yīng)該屬于狀態(tài)圖進(jìn)行測(cè)試。

21、類是比較理想的可重用軟構(gòu)件。

22、對(duì)象實(shí)現(xiàn)了數(shù)據(jù)和操作的結(jié)合，使數(shù)據(jù)和操作封裝于對(duì)象的統(tǒng)一體中。

23、軟件維護(hù)時(shí)，對(duì)測(cè)試階段未發(fā)現(xiàn)的錯(cuò)誤進(jìn)行測(cè)試、診斷、定位、糾錯(cuò)，直至

修改的回歸測(cè)試過程稱為改正性維護(hù)。

24、針對(duì)應(yīng)用系統(tǒng)運(yùn)行期間的數(shù)據(jù)特點(diǎn)，修改他的排序算法使其更高效，屬于軟

件維護(hù)中的完善性。

25、軟件項(xiàng)后贏度管理有許多方法,衛(wèi)圈圖的優(yōu)點(diǎn)是標(biāo)明了各任務(wù)的計(jì)劃進(jìn)度

和當(dāng)前進(jìn)度，能動(dòng)態(tài)地反映軟件開發(fā)進(jìn)展情況，但難以反映多個(gè)任務(wù)之間存在的

復(fù)雜的邏輯關(guān)系。

26、“淘寶定時(shí)確認(rèn)收貨”屬于面向?qū)ο笤O(shè)計(jì)任務(wù)中的時(shí)鐘驅(qū)動(dòng)型任務(wù)。

27、UML中能夠描述對(duì)象的行為，反映出對(duì)象的狀態(tài)與事件關(guān)系的是狀態(tài)圖。

28、為適應(yīng)軟件運(yùn)行環(huán)境的變化而修改軟件的活動(dòng)稱為適應(yīng)性維護(hù)。

29、系統(tǒng)分析員Analyst在做儲(chǔ)蓄系統(tǒng)的需求開發(fā)是，發(fā)現(xiàn)：①“取款”用例、

②“查詢余額”用例、③“更改密碼”用例都要使用、④“驗(yàn)證卡號(hào)和密碼”用

例的功能。那么①②③三個(gè)用例與用例④的關(guān)系是包金逸。

30、面向?qū)ο蟮闹饕卣鞒龑?duì)象唯一性、封裝、繼承外，還有多態(tài)性。

31、面向?qū)ο笤O(shè)計(jì)模型中算法對(duì)應(yīng)分析模型中的方法。

32、面向?qū)ο蠓椒ǖ挠美龍D中，q遑n出關(guān)系表示一個(gè)用例的執(zhí)行可能需要用其

他用例的功能來擴(kuò)展。

33、軟件開發(fā)成本度量主要指軟件開發(fā)項(xiàng)目所需的財(cái)務(wù)性成本的估算。主要方法

包括：周期估算法、類比估算法、細(xì)分估算法。

34、UML中表示對(duì)象之間交互的圖為順序圖。

35、火車是一種路上交通工具?；疖嚭完懮辖煌üぞ咧g的關(guān)系是博區(qū)的關(guān)

系。

36、版本控制是軟件配置管理的核心功能。

37、面向?qū)ο蠓治鲞^程中，獲取用戶需求的是：參觀用戶的.1：作流程，觀察用戶

的操作；與同行、專家交談，聽取他們的意見；向用戶群體發(fā)調(diào)查問卷。

38、在ATM自動(dòng)取款機(jī)的工作模型中（用戶通過輸入正確的用戶資料，從銀行

取錢的過程），取款不是參與者,ATM取款機(jī)，用戶，ATM取款機(jī)管理員是參與

者。

39、面向?qū)ο蟮姆治龇椒ㄖ饕墙⑷惸Ｐ停簩?duì)象模型、交互模型、用例模型。

40、定時(shí)消息推送屬于皿驅(qū)動(dòng)任務(wù)。

41>用例圖中，<extend〉;<<extend>>;獷展關(guān)系表示一個(gè)用例的執(zhí)行可能需要由

其他用例的功能來擴(kuò)展。

42、繼承是子類自動(dòng)地共享基類；父類中定義的數(shù)據(jù)和方法的機(jī)制。

43、軟件的可移植性是指把程序從一種計(jì)算環(huán)境轉(zhuǎn)移到另一種計(jì)算環(huán)境的難易

程度。

44、小鳥牌熱水器和熱水器這兩個(gè)事物之間是繼圣美系。

45、類和類之間的靜態(tài)關(guān)系包括：泛化關(guān)系、關(guān)聯(lián)關(guān)系、聚合關(guān)系。

46、用例圖中，<include>;<<indude>>;包含關(guān)系表示一個(gè)用例所執(zhí)行的功能總是

包括被包含用例的功能。

47、用例圖中的參與者是與系統(tǒng)交互的外部實(shí)體。

48、如果發(fā)現(xiàn)一個(gè)類中對(duì)象都是由另一個(gè)類中多個(gè)對(duì)象組合而成，那么這兩個(gè)類

就具有聚合關(guān)系。

49、C++是在C語言的基礎(chǔ)上開發(fā)的一種面向?qū)λ斓木幊陶Z言。

50、由于軟件是邏輯產(chǎn)品，軟件質(zhì)量較容易直接度量。（X）

51、任務(wù)子系統(tǒng)中的協(xié)調(diào)任務(wù)不僅作協(xié)調(diào)工作，也可以讓其再承擔(dān)其他服務(wù)工作。

（X）

52