軟件工程簡答題復(fù)習(xí)_第1頁
軟件工程簡答題復(fù)習(xí)_第2頁
軟件工程簡答題復(fù)習(xí)_第3頁
軟件工程簡答題復(fù)習(xí)_第4頁
軟件工程簡答題復(fù)習(xí)_第5頁
已閱讀5頁,還剩5頁未讀 繼續(xù)免費(fèi)閱讀

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進(jìn)行舉報或認(rèn)領(lǐng)

文檔簡介

簡答題

1、簡述什么是軟件危機(jī)?

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

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

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

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

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

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

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

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

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

(4)貫穿于所有的活動之中,而不是只集中于一點。

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

螺旋模型具有以下優(yōu)點:

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

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

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

性。

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

有效地交0

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

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

螺旋模型也存在以下缺點:

螺旋模型是風(fēng)險驅(qū)動的,因此要求軟件開發(fā)人員必須具有豐富的風(fēng)險評估經(jīng)驗和

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

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

控制的。

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

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

(1)模塊化

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

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

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

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

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

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

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

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

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

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

3、重要路徑測試

4、錯誤處理測試

5、邊界測試

6、簡述PAD的優(yōu)點。

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

序。

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

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

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

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

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

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

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

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

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

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

(5)嚴(yán)格評審

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

瀑布模型具有下列優(yōu)點:

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

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

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

瀑布模型的缺點:

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

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

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

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

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

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

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

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

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

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

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

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

流。

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

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

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

化關(guān)系。

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

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

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

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

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

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

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

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

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

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

⑴協(xié)作集成

⑵基于集成

⑶高頻集成

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

⑸基于使用的集成

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

⑺分布式集成

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

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

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

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

過程設(shè)計的任務(wù)包括:

⑴算法設(shè)計

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

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

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

13、什么是增量模型?有哪些優(yōu)點?

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

驗證括動交織在一起。系統(tǒng)的開發(fā)是建立一系列的版本(增量),每個版本添加部

分功能到先前的版本中。

增量模型具有以下優(yōu)點:

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

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

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

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

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

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

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

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

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

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

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

⑶保持方法的一致

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

⑸全面覆蓋

⑹盡量不使用全局信息

⑺利用繼承機(jī)制

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

15、簡述需求獲取的原則和步驟。

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

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

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

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

步驟:

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

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

⑶識別用戶類型和用戶代表

⑷獲取具體的需求

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

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

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

優(yōu)點:

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

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

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

缺點:

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

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

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

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

⑴模塊化

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

⑶抽象

⑷信息隱藏

⑸一致性

18、簡述UML的特點。

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

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

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

同觀點,從而有效的消除了各種建模語言之間不必要的差異。

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

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

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

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

19、什么是白盒測試?白盒測試的目的是什么?

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

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

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

白盒測試的目的一般包括:

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

題。

(2)便于衡量測試的完整性,即有沒有把某個功能點的所有可能情況都測試到。

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

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

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

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

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

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

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

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

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

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

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

多的情況。

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

⑴提高模塊獨立性

⑵模塊規(guī)模適中

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

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

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

⑹模塊功能的完善化

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

22、簡述軟件測試的原則。

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

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

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

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

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

⑹嚴(yán)格執(zhí)行測試計劃,排除測試的隨意性。

⑺妥善保存測試計劃、測試用例、出錯統(tǒng)計和最終分析報告。

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

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

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

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

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

快速原型模型具有如下優(yōu)點:

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

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

正確地描述用戶需求。

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

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

會因為發(fā)現(xiàn)規(guī)格說明文檔的錯誤而進(jìn)行較大的返工。

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

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

誤的可能性。

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

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

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

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

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

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

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

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

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

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

要求。

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

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

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

25、簡述單例模式的要點。

從單例模式的要點:

一是某個類只能有一個實例;

二是它必須自行創(chuàng)建這個實例;

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

從具體實現(xiàn)角度來說,就是以下三點:

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

二是類定義中含有一個該類的靜態(tài)私有對象;

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

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

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

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

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

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

價值。

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

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

不在附近了。

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

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

(5)軟件維護(hù)不是一項吸引人的工作。形成這種觀念很大程度上是因為維護(hù)工作

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

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

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

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

⑶可以自動由PDL生成程序代碼

28、軟件維護(hù)報告包含哪些信息?

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

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

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

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

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

⑴快速迭代

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

⑶編寫可測試的需求文檔

⑷多溝通,盡量減少文檔

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

⑹及早考慮測試

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

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

分的軟件,都可以考慮從這幾個方面著手進(jìn)行測評。

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

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

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

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

效程度。

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

的程度。

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

程度。

客觀題

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

2、在UML中,通過建立類圖來表示對象模型。

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

4、面對對象分析模型包括:功能模型、對象模型、動態(tài)模型。

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

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

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

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

9、UML的全稱是UnifiedModelingLanguage。

10、張三辦公用的那臺計算機(jī)是實例。

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

12、通過執(zhí)行對象的操作改變該對象的屬性,必須通過消息的傳遞。

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

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

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

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

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

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

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

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

法一致。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

②“查詢余額”用例、③“更改密碼”用例都要使用、④“驗證卡號和密碼”用

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

30、面向?qū)ο蟮闹饕卣鞒龑ο笪ㄒ恍?、封裝、繼承外,還有多態(tài)性。

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

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

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

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

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

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

35、火車是一種路上交通工具。火車和陸上交通工具之間的關(guān)系是博區(qū)的關(guān)

系。

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

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

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

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

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

者。

39、面向?qū)ο蟮姆治龇椒ㄖ饕墙⑷惸P停簩ο竽P汀⒔换ツP?、用例模型?/p>

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

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

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

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

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

程度。

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

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

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

包括被包含用例的功能。

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

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

就具有聚合關(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

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預(yù)覽,若沒有圖紙預(yù)覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護(hù)處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負(fù)責(zé)。
  • 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時也不承擔(dān)用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論