第一篇：軟件工程考試總結(jié)范文

第一章 軟件工程學(xué)概述

1.軟件：是程序、數(shù)據(jù)及相關(guān)文檔的完整集合。

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

3.產(chǎn)生軟件危機(jī)的原因

A.與軟件本身的特點(diǎn)有關(guān)。管理和控制軟件開發(fā)過程相當(dāng)困難，軟件較難維護(hù)，它規(guī)模龐大，程序復(fù)雜性將隨著

程序規(guī)模的增加而呈指數(shù)上升。

B.和軟件開發(fā)與維護(hù)的方法不正確有關(guān)。

4.消除軟件危機(jī)的途徑：

A.應(yīng)該對計算機(jī)軟件有一個正確認(rèn)識。

B.認(rèn)識到軟件開發(fā)不是某種個體勞動的神秘技巧，而應(yīng)該是一種組織良好、管理嚴(yán)密、各類人員協(xié)同配合、共同

發(fā)完成的工程項目。

C.充分吸取和借鑒人類長期以來從事各種工程項目所積累的行之有效的原理、概念、技術(shù)和方法。

D.開發(fā)和使用更好的軟件工具。

5.軟件工程：是指導(dǎo)計算機(jī)軟件開發(fā)和維護(hù)的一門工程學(xué)科。

6.軟件工程的特征：

A.軟件工程關(guān)注于大型程序的構(gòu)造。

B.軟件工程的中心課題是控制復(fù)雜性。

C.軟件經(jīng)常變化。

D.開發(fā)軟件的效率非常重要。

E.和諧的合作是開發(fā)軟件的關(guān)鍵。

F.軟件必須有效地支持它的用戶。

G.在軟件工程領(lǐng)域中通常由具有一種文化背景的人替具有另一種文化背景的人創(chuàng)造產(chǎn)品。

7.軟件工程學(xué)的方法學(xué)3要素：方法、工具、過程。

方法學(xué)：傳統(tǒng)方法學(xué)、面向?qū)ο蠓椒▽W(xué)。

8.軟件生命周期：

軟件定義、軟件開發(fā)、運(yùn)行維護(hù)三個過程。

軟件定義包括問題定義、可行性研究、需求分析3個階段。

軟件開發(fā)包括總體設(shè)計、詳細(xì)設(shè)計、編碼和單元測試、綜合測試4個階段。

9.軟件過程：是為了獲得高質(zhì)量軟件所需要完成的一系列任務(wù)的框架，它規(guī)定了完成各項任務(wù)的工作步驟。

10.過程模型：瀑布模型、快速原型模型、增量模型、螺旋模型、噴泉模型。

瀑布模型：優(yōu)點(diǎn)：1.可強(qiáng)迫開發(fā)員采用規(guī)范的方法2.嚴(yán)格地規(guī)定了每個階段必須提交的文件3.要求每個階段交出的所有產(chǎn)品都必須經(jīng)過質(zhì)量保證小組的仔細(xì)驗(yàn)證。缺點(diǎn)：傳統(tǒng)的瀑布模型過于理想化，是由文檔驅(qū)動的。

快速原型模型：通過快速構(gòu)建起一個可在計算機(jī)上運(yùn)行的原型系統(tǒng)，讓用戶試用原型并收集用戶反饋意見的方法，獲取用戶真正的需要。

增量模型：優(yōu)點(diǎn)：能在較短時間內(nèi)向用戶提交可完成部分工作的產(chǎn)品；逐步增加產(chǎn)品功能可以使用戶有較充實(shí)的時

間學(xué)習(xí)和適應(yīng)新產(chǎn)品，從而減少一個全新的軟件可能給客戶組織帶來的沖擊。

螺旋模型：優(yōu)點(diǎn)：對可選方案和約束條件的強(qiáng)調(diào)有利于已有軟件的重用；減少了過多測試；維護(hù)只是螺旋模型中另

一個周期。

第二章 可行性研究（確定問題是否能解決）

1.可行性研究的三個方面：技術(shù)可行性：使用現(xiàn)有的技術(shù)能否實(shí)現(xiàn)該系統(tǒng)。

經(jīng)濟(jì)可行性：該系統(tǒng)的經(jīng)濟(jì)效應(yīng)能否超過它的開發(fā)成本。

操作可行性：系統(tǒng)的操作方式在這個組織內(nèi)是否行得通。

2.系統(tǒng)流程圖：概括的描繪物理系統(tǒng)的傳統(tǒng)工具。表達(dá)的是數(shù)據(jù)在系統(tǒng)各部件之間流動的情況。

基本符號：處理、輸入輸出、連接、換頁連接、數(shù)據(jù)流。

3.數(shù)據(jù)流圖DFD：一種圖形化技術(shù)，它描繪信息流和數(shù)據(jù)從輸入移動到輸出的過程中所經(jīng)受的變換。描繪邏輯過程。

基本符號：數(shù)據(jù)的源點(diǎn)/終點(diǎn)、變換數(shù)據(jù)的處理、數(shù)據(jù)存儲、數(shù)據(jù)流。

數(shù)據(jù)流圖的命名：先為數(shù)據(jù)流命名，再為處理命名。

數(shù)據(jù)字典：是關(guān)于數(shù)據(jù)信息的集合，也就是對數(shù)據(jù)流圖中包含的所有元素的定義的集合。

數(shù)據(jù)字典的內(nèi)容：數(shù)據(jù)流、數(shù)據(jù)流分量（數(shù)據(jù)元素）、數(shù)據(jù)存儲、處理。

定義數(shù)據(jù)的方法：順序、選擇、重復(fù)。

符號：=等價于、+和、[ ]或、{ }重復(fù)、（）可選

4.成本估計技術(shù)：代碼行技術(shù)、任務(wù)分解技術(shù)、自動估計成本技術(shù)。

第三章 需求分析（系統(tǒng)必須做什么）

1.需求分析的任務(wù)：

A.確定對系統(tǒng)的綜合要求。

B.分析系統(tǒng)的數(shù)據(jù)要求。

C.導(dǎo)出系統(tǒng)的邏輯模型。

D.修正系統(tǒng)開發(fā)計劃。

2.與用戶溝通獲取需求的方法：

A.訪談。

B.面向數(shù)據(jù)流自頂向下求精。（結(jié)構(gòu)化分析方法）

C.簡易的應(yīng)用規(guī)格說明技術(shù)。

D.快速建立軟件原型。

3.實(shí)體—聯(lián)系圖（E-R圖）包含的3種信息：數(shù)據(jù)對象（矩形）、屬性（圓角矩形）、聯(lián)系（菱形）。

4.狀態(tài)轉(zhuǎn)換圖：通過描繪系統(tǒng)的狀態(tài)及引起系統(tǒng)狀態(tài)轉(zhuǎn)換的事件，來表示系統(tǒng)的行為。

狀態(tài)：是任何可被觀察到的系統(tǒng)行為模式，有初態(tài)、中間狀態(tài)、終態(tài)。一張狀態(tài)圖中只能有一個初態(tài)，0到多個終態(tài)。

事件：引起系統(tǒng)做動作或（和）轉(zhuǎn)換狀態(tài)的控制信息。

符號：初態(tài)（實(shí)心圓）、終態(tài)（一對同心圓，內(nèi)圓為實(shí)心圓）、狀態(tài)轉(zhuǎn)換（箭頭）。

5.該階段可用到的其他圖形：層次方框圖、Warnier圖、IPO圖、注：E—R圖建立數(shù)據(jù)模型，數(shù)據(jù)流圖建立功能模型，狀態(tài)圖建立行為模型。

第五章 總體設(shè)計（概括的說系統(tǒng)應(yīng)該如何實(shí)現(xiàn)）將軟件需求轉(zhuǎn)化為數(shù)據(jù)結(jié)構(gòu)和軟件的系統(tǒng)結(jié)構(gòu)。

1.基本任務(wù)：A.劃分出組成系統(tǒng)的物理元素：程序、文件、數(shù)據(jù)庫、人工過程和文檔等。

B.設(shè)計軟件的結(jié)構(gòu)。也就是要確定系統(tǒng)中每個程序由哪些模塊組成，以及這些模塊相互間的關(guān)系。

2.階段：系統(tǒng)設(shè)計階段，確定系統(tǒng)的具體實(shí)現(xiàn)方案。

結(jié)構(gòu)設(shè)計階段：確定軟件結(jié)構(gòu)。

典型的總體設(shè)計過程包括9個步驟：

設(shè)想供選擇的方案，選取合理的方案，推薦最佳方案，功能分解，設(shè)計軟件結(jié)構(gòu)，設(shè)計數(shù)據(jù)庫，制定

測試計劃，書寫文檔，審查和復(fù)審。

3.設(shè)計原理：模塊化、抽象、逐步求精、信息隱藏和局部化、模塊獨(dú)立。

模塊：由邊界元素限定的相鄰程序元素的序列，而且有一個總體標(biāo)識符代替它。

模塊化：就是把程序劃分成獨(dú)立命名且可獨(dú)立訪問的模塊，每個模塊完成一個子功能，把這些模塊集成起來構(gòu)成一個整體，可以完成指定的功能滿足用戶需求。

抽象：就是抽出事物的本質(zhì)特征而暫時不考慮它們的細(xì)節(jié)。

逐步求精：為了能集中精力解決主要問題而盡量推遲對問題細(xì)節(jié)的考慮。可看作是一項把一個時期內(nèi)必須解決的種種問題按優(yōu)先級排序的技術(shù)。

信息隱藏：設(shè)計和確定的模塊，使得一個模塊內(nèi)包含的信息對于不需要這些信息的模塊來說，是不能訪問的。局部化：把一些關(guān)系密切的軟件元素物理地放得彼此靠近。

模塊的獨(dú)立程度的定性標(biāo)準(zhǔn)度量：內(nèi)聚、耦合。

耦合：是對一個軟件結(jié)構(gòu)內(nèi)不同模塊之間互連程度的度量。耦合由低程度到高程度分為：數(shù)據(jù)耦合、控制耦合、特征耦合、公共環(huán)境耦合、內(nèi)容耦合。

內(nèi)聚：標(biāo)志著一個模塊內(nèi)各個元素彼此結(jié)合的緊密程度。底內(nèi)聚有偶然內(nèi)聚、邏輯內(nèi)聚、時間內(nèi)聚。中內(nèi)聚包括

過程內(nèi)聚和通信內(nèi)聚。高內(nèi)聚包括順序內(nèi)聚和功能內(nèi)聚。

注：盡量使用數(shù)據(jù)耦合，少用控制耦合和特征耦合，限制公共環(huán)境耦合的范圍，完全不用內(nèi)容耦合。

4.啟發(fā)規(guī)則：

改進(jìn)軟件結(jié)構(gòu)提高模塊獨(dú)立性。模塊規(guī)模應(yīng)該適中。深度、寬度、扇出和扇入都應(yīng)適當(dāng)。模塊的作用域應(yīng)該在控制域之內(nèi)。力爭降低模塊接口的復(fù)雜程度。設(shè)計單入口單出口的模塊。模塊功能應(yīng)該可以預(yù)測。

深度：表示軟件結(jié)構(gòu)中控制的層數(shù)。

寬度：軟件結(jié)構(gòu)內(nèi)同一個層次上模塊總數(shù)的最大值。

扇出：一個模塊直接控制的模塊數(shù)。

扇入：表示一個模塊有多少個上級模塊直接調(diào)用它。

注：設(shè)計的很好的軟件結(jié)構(gòu)，通常頂層扇出比較高，中層扇出較少，底層扇入到公共的使用模塊中去。（底層模塊有高扇入）

5.面向數(shù)據(jù)流的設(shè)計方法：

目標(biāo)：給出設(shè)計軟件結(jié)構(gòu)的一個系統(tǒng)化的途徑。

概念：把信息流映射策劃那個軟件結(jié)構(gòu)，信息流的類型決定了映射的方。

信息流的類型：變換流和事務(wù)流。

變換流的特點(diǎn)：信息以“外部世界”的形式進(jìn)入軟件系統(tǒng)，經(jīng)處理以后再以“外部世界”的形式離開系統(tǒng)。事務(wù)流的特點(diǎn)：數(shù)據(jù)沿輸入通路到達(dá)一個處理，該處理根據(jù)輸入數(shù)據(jù)的類型在若干個動作序列中選出一個來執(zhí)行。

6.變換分析：把具有變換流特點(diǎn)的數(shù)據(jù)流圖按預(yù)先確定的模式映射成軟件結(jié)構(gòu)。

第一步：復(fù)查基本系統(tǒng)模型。

第二步：復(fù)查并精化數(shù)據(jù)流圖。

第三步：確定數(shù)據(jù)流圖是變換特性還是事務(wù)特性。

第四步：確定輸入流和輸出流的邊界，從而孤立出變化中心。

第五步：完成第一級分解。

第六步：完成第二次分解。

第七步：使用設(shè)計度量和啟發(fā)規(guī)則對第一次分割得到的軟件結(jié)構(gòu)進(jìn)一步精化。

第六章 詳細(xì)設(shè)計（怎樣具體地實(shí)現(xiàn)所要求的系統(tǒng)）即過程設(shè)計。通過對結(jié)構(gòu)表示進(jìn)行細(xì)化，得到軟

件詳細(xì)的數(shù)據(jù)結(jié)構(gòu)和算法。

1.詳細(xì)設(shè)計的內(nèi)容：

用圖表列出系統(tǒng)的每個程序，包括每個模塊和子程序名稱、標(biāo)識符、層出結(jié)構(gòu)關(guān)系。對程序的功能、性能、輸入、輸出、算法、流程、接口等進(jìn)行描述

內(nèi)容包括：程序描述：程序簡要描述，意義和特點(diǎn)

功能：程序應(yīng)具備的功能

性能：精度、靈活性和時間特性等

輸入項

輸出項

2.人機(jī)界面設(shè)計指南：

一般交互指南：涉及信息顯示、數(shù)據(jù)輸入和系統(tǒng)整體控制。

保持一致性，提供有意義的反饋，在執(zhí)行有破壞性的動作之前要求用戶確認(rèn)，允許取消絕大多數(shù)

操作，減少在兩次操作之間必須記憶的信息量，提高對話、移動和思考的效率，允許犯錯誤，按

功能對動作分類，并據(jù)此設(shè)計屏幕布局，提供對用戶工作內(nèi)容敏感的幫助設(shè)施，用簡單動詞或動

詞短語作為命令名。

信息顯示指南：只顯示與當(dāng)前工作內(nèi)容有關(guān)的信息，不要用數(shù)據(jù)淹沒用戶，使用一致標(biāo)記、標(biāo)準(zhǔn)的縮寫和可預(yù)知的顏色，允許用戶保持可視化的語境，產(chǎn)生有意義的出錯信息，使用大小寫、縮進(jìn)和文本分組以幫

助理解，使用窗口分隔不同類型的信息，使用“模擬”顯示表示信息，以使信息更容易被用戶提取，高效率地使用顯示屏。

數(shù)據(jù)輸入指南：盡量減少用戶的輸入動作，保持信息顯示和數(shù)據(jù)輸入之間的一致性，允許用戶自定義輸入，交互

應(yīng)該是靈活的，并且可調(diào)整成用戶最喜歡的輸入方式，交互應(yīng)該是靈活的，并且可調(diào)整成用戶最喜

歡的輸入方式，讓用戶控制交互流，對所有輸入動作都提供幫助，消除冗余的輸入。

3.過程設(shè)計工具：分為圖形、表格、語言。有程序流程圖、盒圖（N—S圖）、PAD圖（問題分析圖）、判定表、判

定樹、過程設(shè)計語言（PDL或偽碼）。

4.程序復(fù)雜程度的定量度量：

McCabe方法：根據(jù)程序控制流的復(fù)雜程度度量度量程序的復(fù)雜度，結(jié)果稱為環(huán)形復(fù)雜度。

流圖：實(shí)質(zhì)上是“退化了的”程序流程圖。有結(jié)點(diǎn)（圓）、邊（箭頭）。

區(qū)域：邊和結(jié)點(diǎn)圍成的面積。

5.計算環(huán)形復(fù)雜度的方法：

A.區(qū)域數(shù)=環(huán)形復(fù)雜度。

B.流圖G的環(huán)形復(fù)雜度V(G)=E—N+2，E為邊數(shù)，N為結(jié)點(diǎn)數(shù)。

C.V(G)=P+1，P為判定結(jié)點(diǎn)的數(shù)目。

第七章 實(shí)現(xiàn)（編碼和測試）

1.軟件測試：就是在軟件投入運(yùn)行前，對軟件需求分析、設(shè)計規(guī)格說明和編碼的最終復(fù)審，是軟件質(zhì)量保證的關(guān)鍵

步驟。

2.測試的目的：在軟件投入生產(chǎn)性運(yùn)行之前，盡可能多現(xiàn)的發(fā)軟件在運(yùn)行中的錯誤。

3.測試方法：黑盒測試、白盒測試。

黑盒測試：已經(jīng)知道產(chǎn)品應(yīng)有的功能，檢驗(yàn)每個功能是否都能正常使用。也叫功能測試。

白盒測試：已經(jīng)知道產(chǎn)品的內(nèi)部工作過程，檢驗(yàn)這些過程是否按照規(guī)格說明書的規(guī)定正常進(jìn)行。也叫

結(jié)構(gòu)測試。

以黑盒測試為主，白盒測試為輔。

4.測試步驟：模塊測試、子系統(tǒng)測試、系統(tǒng)測試、驗(yàn)收測試，平行測試。

5.白盒測試技術(shù)：

邏輯覆蓋：是對一系列測試過程的總稱，這組測試過程逐漸進(jìn)行越來越完整的通路測試。

種類：語句覆蓋、判定覆蓋、條件覆蓋、判定/條件覆蓋、條件組合覆蓋、點(diǎn)覆蓋、邊覆蓋、路徑覆蓋。

基本路徑測試：

一、根據(jù)過程設(shè)計結(jié)果畫出相應(yīng)流圖。

二、計算流圖的環(huán)境復(fù)雜度。

三、確定線路獨(dú)立路徑的基本組合。獨(dú)立路徑是指至少引入程序的一個新處理語句集合或一

個新條件路徑，就是至少包含一條在定義該路徑之前不曾用過的邊。

獨(dú)立路徑數(shù)=環(huán)形復(fù)雜度

四、設(shè)計可強(qiáng)制執(zhí)行基本集合中每條路徑的測試用例。

6.調(diào)試：在測試發(fā)現(xiàn)錯誤之后排除錯誤的過程。

7.軟件維護(hù)：在軟件已交付使用之后，為了改正錯誤或者滿足新的需要而修改軟件的過程。分為改進(jìn)性維護(hù)、適應(yīng)性

維護(hù)、完善性維護(hù)、預(yù)防性維護(hù)。

決定軟件可維護(hù)性的因素：可理解性、可測試性、可修改性、可移植性、可重用性。

8.軟件項目管理：通過計劃、組織和控制等一系列活動，合理的配置和使用各種資源，以達(dá)到既定目標(biāo)的過程。管理內(nèi)容：估算軟件規(guī)模，工作量估算、進(jìn)度計劃、人員組織、質(zhì)量保證、軟件配置管理、能力成熟度模型。

第二篇：軟件工程考試總結(jié)

2.說明結(jié)構(gòu)化程序設(shè)計的主要思想是什么？ 答：（1）自頂向下、逐步求精的程序設(shè)計方法（2分）（2）使用3種基本控制結(jié)構(gòu)、單入口、單出口來構(gòu)造程序。結(jié)構(gòu)化程序設(shè)計是實(shí)現(xiàn)該目標(biāo)的關(guān)鍵技術(shù)之一，它指導(dǎo)人們用良好的思想方法開發(fā)易于理解、易于驗(yàn)證的程序。結(jié)構(gòu)化程序設(shè)計方法的基本要點(diǎn)是： 1）采用自頂向下、逐步求精的程序設(shè)計方法2）使用三種基本控制結(jié)構(gòu)構(gòu)造程序 3）主程序員組的組織形式。

3.軟件測試包括哪些步驟？說明這些步驟的測試對象是什么？答：（1）單元測試，測試對象單元模塊（2）集成測試，測試對象為組裝后的程序模塊（3）確認(rèn)測試，測試對象為可運(yùn)行的目標(biāo)軟件系統(tǒng)

4.需求分析與軟件設(shè)計二個階段任務(wù)的主要區(qū)別是什么？ 答：需求分析定義軟件的用戶需求，即定義待開發(fā)軟件能做什么軟件設(shè)計定義軟件的實(shí)現(xiàn)細(xì)節(jié)以滿足用戶需求，即研究如何實(shí)現(xiàn)軟件 5.說明軟件測試和調(diào)試的目的有何區(qū)別？

答：測試的目的是判斷和發(fā)現(xiàn)軟件是否有錯誤 調(diào)試的目的是定位軟件錯誤并糾正錯誤。

7、白盒法：該方法把測試對象看作一個打開的盒子，測試人員須了解程序的內(nèi)部結(jié)構(gòu)和處理過程，以檢查處理過程的細(xì)節(jié)為基礎(chǔ)，對程序中盡可能多的邏輯路徑進(jìn)行測試，檢查內(nèi)部控制結(jié)構(gòu)和數(shù)據(jù)結(jié)構(gòu)是否有錯，實(shí)際的運(yùn)行狀態(tài)與預(yù)期的狀態(tài)是否一致。白盒法也不可能進(jìn)行窮舉測試。

8、黑盒法：該方法把被測試對象看成一個黑盒子，測試人員完全不考慮程序的內(nèi)部結(jié)構(gòu)和處理過程，只在軟件接口處進(jìn)行測試，依照需求規(guī)格說明書，檢查程序是否滿足功能要求。因此，黑盒測試又稱為功能測試或數(shù)據(jù)驅(qū)動測試

9、面向?qū)ο笤O(shè)計：是把分析階段得到的需求轉(zhuǎn)變成符合成本和質(zhì)量要求的、抽象的系統(tǒng)實(shí)現(xiàn)方案的過程。或者說，面向?qū)ο笤O(shè)計就是用面向?qū)ο笥^點(diǎn)建立求解域模型的過程。

10、結(jié)構(gòu)化設(shè)計：面向數(shù)據(jù)流的設(shè)計是以需求分析階段產(chǎn)生的數(shù)據(jù)流圖為基礎(chǔ)，按一定的步驟映射成軟件結(jié)構(gòu)，因此又稱結(jié)構(gòu)化設(shè)計（SD）。

11、結(jié)構(gòu)化分析：是根據(jù)分解與抽象的原則，按照系統(tǒng)中數(shù)據(jù)處理的流程，用數(shù)據(jù)圖來建立系統(tǒng)的功能模型，從而完成需求分析工作

結(jié)構(gòu)化方法是一種傳統(tǒng)的軟件開發(fā)方法，它是由結(jié)構(gòu)化分析、結(jié)構(gòu)化設(shè)計和結(jié)構(gòu)化程序設(shè)計三部分有機(jī)組合而成的。它的基本思想：把一個復(fù)雜問題的求解過程分階段進(jìn)行，而且這種分解是自頂向下，逐層分解，使得每個階段處理的問題都控制在人們?nèi)菀桌斫夂吞幚淼姆秶鷥?nèi)。

結(jié)構(gòu)化分析方法(Structured Method，結(jié)構(gòu)化方法)是強(qiáng)調(diào)開發(fā)方法的結(jié)構(gòu)合理性以及所開發(fā)軟件的結(jié)構(gòu)合理性的軟件開發(fā)方法。結(jié)構(gòu)是指系統(tǒng)內(nèi)各個組成要素之間的相互聯(lián)系、相互作用的框架。結(jié)構(gòu)化開發(fā)方法提出了一組提高軟件結(jié)構(gòu)合理性的準(zhǔn)則，如分解與抽象、模塊獨(dú)立性、信息隱蔽等。針對軟件生存周期各個不同的階段，它有結(jié)構(gòu)化分析(SA)、結(jié)構(gòu)化設(shè)計(SD)和結(jié)構(gòu)化程序設(shè)計(SP)等方法。

結(jié)構(gòu)化分析方法是面向____數(shù)據(jù)流___進(jìn)行需求分析的方法。結(jié)構(gòu)化分析方法使用____數(shù)據(jù)字典______與____加工說明___來描述。

13、系統(tǒng)流程圖：是描述物理系統(tǒng)的傳統(tǒng)工具，它用圖形符號來表示系統(tǒng)中的各個元素，例如人工處理、數(shù)據(jù)處理、數(shù)據(jù)庫、文件、設(shè)備等。它表達(dá)了系統(tǒng)中各個元素之間的信息流動的情況。4.軟件生存周期

軟件生存周期是指軟件產(chǎn)品從考慮其概念開始到該軟件產(chǎn)品交付使用，直至最終退役為止的整個過程，一般包括計劃、分析、設(shè)計、實(shí)現(xiàn)、測試、集成、交付、維護(hù)等階段。

2、采用黑盒技術(shù)設(shè)計測試用例有哪幾種方法？這些方法各有什么特點(diǎn)？ ㈠等價類劃分。等價類劃分是將輸入數(shù)據(jù)域按有效的或無效的（也稱合理的或不合理的）劃分成若干個等價類，測試每個等價類的代表值就等于對該類其它值的測試。㈡邊界值分析。該方法是將測試邊界情況作為重點(diǎn)目標(biāo)，選取正好等于，剛剛大于或剛剛小于邊界值的情況，根據(jù)這些情況選擇測試用例。㈢錯誤推測。錯誤推測法沒有確定的步驟，憑檢驗(yàn)進(jìn)行。它的基本思想是列出程序中可能發(fā)生錯誤的情況，根據(jù)這些情況選擇測試用例

3,Gantt圖是歷史悠久，應(yīng)用廣泛的制定進(jìn)度的計劃的工具。形象的描繪任務(wù)分解情況，以及每個子任務(wù)的開始時間和結(jié)束時間，具有直觀簡明，容易掌握，容易繪制的優(yōu)點(diǎn)。缺點(diǎn)1不能顯式描繪各項作業(yè)依賴關(guān)系2進(jìn)度的關(guān)鍵部分不明確，難于確定哪些是主攻和主控3有潛力的部分不明確，造成浪費(fèi)。工程網(wǎng)絡(luò) 0分軟件危機(jī)定義和產(chǎn)生的因有哪些？

當(dāng)軟件開發(fā)技術(shù)的進(jìn)步不能跟上硬件技術(shù)的進(jìn)步，未能滿足發(fā)展的要求，致軟件開發(fā)中遇到的問題找不到解決的辦法，使問題積累起來，形成了尖銳的矛盾，因而導(dǎo)致了軟件危機(jī)。

1）軟件日益復(fù)雜和龐大（2）軟件開發(fā)管理困難和復(fù)雜（3）軟件開發(fā)技術(shù)落后(4）生產(chǎn)方式落后（5）開發(fā)工具落后（6）軟件開發(fā)費(fèi)用不斷增加

1、可行性研究的任務(wù)是什么？ 首先需要進(jìn)行概要的分析研究，初步確定項目的規(guī)模和目標(biāo)，確定項目的約束和限制，把他們清楚地列舉出來。然后，分析員進(jìn)行簡要的需求分析，抽象出該項目的邏輯結(jié)構(gòu)，建立邏輯模型。從邏輯模型出發(fā)，經(jīng)過壓縮的設(shè)計，探索出若干種可供選擇的主要解決方法，對每種解決方法都要研究它的可行性，可從以下三個方面分析研究每種解決方法的可行性。㈠技術(shù)可行性：對要開發(fā)項目的功能、性能、限制條件進(jìn)行分析，確定在現(xiàn)有的資源條件下，技術(shù)風(fēng)險有多大，項目是否能實(shí)現(xiàn)。㈡經(jīng)濟(jì)可行性：進(jìn)行開發(fā)成本的估算以及了解取得效益的評估，確定要開發(fā)的項目是否值得投資開發(fā)。㈢社會可行性：要開發(fā)的項目是否存在任何侵犯、妨礙等責(zé)任問題，要開發(fā)項目的運(yùn)行方式在用戶組織內(nèi)是否行得通，現(xiàn)有管理制度、人員素質(zhì)、操作方式是否可行。

2、需求分析的任務(wù)是什么？

需求分析的任務(wù)是確定待開發(fā)的軟件系統(tǒng)“做什么”。具體任務(wù)包括確定軟件系統(tǒng)的功能需求、性能需求和運(yùn)行環(huán)境約束，編制軟件需求規(guī)格說明書、軟件系統(tǒng)的驗(yàn)收測試準(zhǔn)則和初步的用戶手冊。

需求分析是指，開發(fā)人員要準(zhǔn)確理解用戶的要求，進(jìn)行細(xì)致的調(diào)查分析，將用戶非形式的需求陳述轉(zhuǎn)化為完整的需求定義，再由需求定義轉(zhuǎn)換到相應(yīng)的形式功能規(guī)約（需求規(guī)格說明）的過程。

3、概要設(shè)計的定義和基本任務(wù)是什么？

進(jìn)入了設(shè)計階段，要把軟件“做什么”的邏輯模型變換為“怎么做”的物理模型，即著手實(shí)現(xiàn)軟件的需求，并將設(shè)計的結(jié)果反應(yīng)在“設(shè)計規(guī)格說明書”文檔中，所以軟件設(shè)計是一個把軟件需求轉(zhuǎn)換為軟件表示的過程，最初這種表示只是描述了軟件的總的體系結(jié)構(gòu)，稱為軟件的概要設(shè)計或結(jié)構(gòu)設(shè)計。①采用某種設(shè)計方法，將一個復(fù)雜的系統(tǒng)按功能劃分成模塊。②確定每個模塊的功能。③確定模塊之間的調(diào)用關(guān)系。④確定模塊之間的接口，即模塊之間傳遞的信息。⑤評價模塊結(jié)構(gòu)的質(zhì)量。⑵數(shù)據(jù)結(jié)構(gòu)及數(shù)據(jù)庫設(shè)計，漢數(shù)據(jù)結(jié)構(gòu)的設(shè)計及數(shù)據(jù)庫的設(shè)計。⑶編寫概要設(shè)計文檔。主要有：概要設(shè)計說明書；數(shù)據(jù)庫設(shè)計說明書；用戶手冊；修訂測試計劃。⑷評審

4、詳細(xì)設(shè)計的基本任務(wù)是什么？有哪幾種描述方法？ 詳細(xì)設(shè)計是軟件設(shè)計的第二階段，其基本任務(wù)有：為每個模塊進(jìn)行詳細(xì)的算法設(shè)計；為模塊內(nèi)的數(shù)據(jù)結(jié)構(gòu)進(jìn)行設(shè)計；對數(shù)據(jù)庫進(jìn)行物理設(shè)計，即確定數(shù)據(jù)庫的物理結(jié)構(gòu)；其它設(shè)計，根據(jù)軟件系統(tǒng)類型，還可能要進(jìn)行代碼設(shè)計、輸入/輸出格式設(shè)計、人機(jī)對話設(shè)計；編寫詳細(xì)設(shè)計說明書；評審。詳細(xì)描述處理過程常用三種工具：圖形、表格和語言。如結(jié)構(gòu)化程序流程圖、盒圖和問題分析圖。IPO圖也是詳細(xì)設(shè)計的主要工具之一。表格工具如判定表可作為詳細(xì)設(shè)計中描述邏輯條件復(fù)雜的算法。過程設(shè)計語言（PDL）是一種用于描述模塊算法設(shè)計和處理細(xì)節(jié)的語言工具。

能力成熟度模型（CMM）用于評價軟件機(jī)構(gòu)的軟件過程能力成熟度德模型 文檔：程序開發(fā)使用和維護(hù)所常用的圖文資料

2衡量模塊獨(dú)立性的兩個定性的標(biāo)準(zhǔn)是內(nèi)聚和耦合。耦合是指對一個軟件結(jié)構(gòu)內(nèi)不同模塊彼此之間互相依賴的緊密程度。內(nèi)聚標(biāo)志一個模塊內(nèi)各元素彼此的緊密1簡述兩種不同集成測試的比較：自頂向下測試法主要，優(yōu)點(diǎn)是不需要測試驅(qū)動程序，能夠在測試階段的早期實(shí)現(xiàn)并驗(yàn)證系統(tǒng)的主要功能，而且能在早期發(fā)現(xiàn)上層模塊的接口的錯誤，自頂向下的缺點(diǎn)是需要存根程序，可能遇到與此相聯(lián)系的測試?yán)щy，底層關(guān)鍵模塊中的錯誤發(fā)現(xiàn)的較晚，而且用這種方法不能展開人力。自底向下正好相反。

影響維護(hù)的因素：可理解性，可測試性，可修改性，可移植性，重用性

總體設(shè)計的九個階段：1設(shè)想供選擇的方案，2選擇合適的方案，3推薦最佳方案，4功能分解，5設(shè)計軟件結(jié)構(gòu) 6設(shè)計數(shù)據(jù)庫，7制定測試計劃，8書寫文檔，9審查和復(fù)查

軟件工程：是指導(dǎo)計算機(jī)軟件開發(fā)和維護(hù)的工程學(xué)科，采用工程概念，原理，技術(shù)和方法來開發(fā)和維護(hù)軟件，吧經(jīng)過實(shí)踐考驗(yàn)而證明的管理技術(shù)和當(dāng)前能夠得到的最好的技術(shù)方法結(jié)合起來。要素是方法，工具，過程 系統(tǒng)流程圖是描繪物理系統(tǒng)的傳統(tǒng)工具，他的基本思想是用圖形符號以黑盒子形式描繪組成系統(tǒng)的每個部件。表達(dá)的是數(shù)據(jù)在系統(tǒng)各部件的流動情況，而不是對數(shù)據(jù)進(jìn)行加工處理的控制過程。

3個子模型和5個層次：靜態(tài)結(jié)構(gòu)（對象模型）交互次序（動態(tài)模型）數(shù)據(jù)變換（功能模型）主題層，類和對象層，結(jié)構(gòu)層，屬性層，服務(wù)層

結(jié)構(gòu)化方法有結(jié)構(gòu)化分析、結(jié)構(gòu)化設(shè)計、結(jié)構(gòu)化程序設(shè)計構(gòu)成，它是一種面向數(shù)據(jù)流的開發(fā)方法。

結(jié)構(gòu)化設(shè)計對數(shù)據(jù)流有兩種分析方法，他們是變換分析設(shè)計和事務(wù)分析設(shè)計。質(zhì)量保證是有計劃的和系統(tǒng)性的活動，它對部件或產(chǎn)品滿足確定的技術(shù)需求提供足夠的信心。

軟件質(zhì)量保證措施（SQA）基于非執(zhí)行的測試（復(fù)審和評審）基于執(zhí)行的測試（軟件測試）和程序正確性證明

數(shù)據(jù)字典的內(nèi)容：數(shù)據(jù)流，數(shù)據(jù)流分量，數(shù)據(jù)存儲，數(shù)據(jù)處理

數(shù)據(jù)流圖的內(nèi)容：數(shù)據(jù)流，數(shù)據(jù)存儲，數(shù)據(jù)處理，數(shù)據(jù)的原點(diǎn)和終點(diǎn)。

數(shù)據(jù)流圖（DFD）是一種圖形化技術(shù)，他描繪信息流和數(shù)據(jù)從輸入移動到輸出的過程中經(jīng)受的變換。

可行性研究中，數(shù)據(jù)流圖，系統(tǒng)流程圖，數(shù)據(jù)字典

需求分析：訪談，實(shí)體聯(lián)系圖，狀態(tài)轉(zhuǎn)換圖，層次方框圖，Warnier圖，IPO圖 總體設(shè)計：層次圖和HIPO圖，結(jié)構(gòu)圖

詳細(xì)設(shè)計：過程設(shè)計中有程序流程圖，盒圖，PAD圖，判定表，判定樹，過程設(shè)計語言。面向數(shù)據(jù)結(jié)構(gòu)的設(shè)計方法：Jackson圖程序復(fù)雜度的定量MaCabe方法和Halstead方法

設(shè)計人機(jī)界面的過程中4個問題，系統(tǒng)響應(yīng)時間，用戶幫助設(shè)施，出錯信息處理和命令交互

耦合:盡量使用數(shù)據(jù)耦合少用控制耦合和特征耦合，限制公共環(huán)境耦合的范圍，完全不用內(nèi)容耦合

內(nèi)聚:偶然內(nèi)聚，邏輯內(nèi)聚時間內(nèi)聚，中內(nèi)聚有過程內(nèi)聚通信內(nèi)聚，高內(nèi)聚，功能內(nèi)聚，順序內(nèi)聚

模塊化就是把程序劃分為獨(dú)立命名且可獨(dú)立訪問的模塊，每個模塊完成一個子功能，把這些模塊集起來構(gòu)成一個整體，可以完成指定的功能滿足用戶的需求 狀態(tài)轉(zhuǎn)換圖通過描繪系統(tǒng)狀態(tài)及引起系統(tǒng)狀態(tài)轉(zhuǎn)換的事件，來表示系統(tǒng)的行為

5.軟件配置管理，簡稱SCM，它用于整個軟件工程過程。其主要目標(biāo)是：標(biāo)識變更；控制變更；確保變更正確地實(shí)現(xiàn)；報告有關(guān)變更。SCM是一組管理整個軟件生存期各階段中變更的活動。

Jackson的畫法：

1定輸入和輸出數(shù)據(jù)結(jié)構(gòu)

2分析確定在輸入和輸出數(shù)據(jù)結(jié)構(gòu)中有對應(yīng)關(guān)系的數(shù)據(jù)單元，最高層輸入和輸出相對應(yīng)等有其他。

3從數(shù)據(jù)結(jié)構(gòu)圖導(dǎo)出程序結(jié)構(gòu)圖

4列出所有的操作和條件，并把它們分配到程序結(jié)構(gòu)圖的適當(dāng)位置。5最后用偽碼表示程序處理過程 盒圖的特點(diǎn)：

1功能域明確，可以從盒圖上一眼看出來 2不可能任意轉(zhuǎn)移控制

3很容易確定局部和全程數(shù)據(jù)的作用域

4很容易表現(xiàn)嵌套關(guān)系，也可以表示模塊的層次結(jié)構(gòu)。PAD圖：

1使用表示結(jié)構(gòu)化控制結(jié)構(gòu)的PAD符號結(jié)構(gòu)所設(shè)計出來的程序必然是結(jié)構(gòu)化程序。

2PAD圖所描繪的程序結(jié)構(gòu)非常清晰

3PAD圖表現(xiàn)程序邏輯，易讀，易懂，易記 4，容易將PAD圖轉(zhuǎn)換成高級語言源程序

5即可用于表示程序邏輯，也可用于描繪數(shù)據(jù)結(jié)構(gòu) 6PAD的符號支持自頂向下，逐步求精方法

第三篇：軟件工程考試

軟件工程是用工程、科學(xué)和數(shù)學(xué)的原則與方法研制、維護(hù)計算機(jī)軟件的有關(guān)技術(shù)和管理方法 軟件工程三要素：方法、工具和過程

軟件工程的內(nèi)容：軟件開發(fā)技術(shù)和軟件開發(fā)管理兩個方面

可行性研究方面:技術(shù)可行性經(jīng)濟(jì)可行性操作可行性法律可行性

IT項目可行性研究審計的概念:事前對IT項目從技術(shù)和經(jīng)濟(jì)兩個方而進(jìn)行的詳細(xì)論證，涉及

數(shù)據(jù)字典是關(guān)于數(shù)據(jù)的信息的集合，也就是對數(shù)據(jù)流圖中包含的所有元素的定義的集合.包括（1）數(shù)據(jù)流（2）數(shù)據(jù)元素（3）數(shù)據(jù)存儲（4）處理 驗(yàn)證軟件需求的正確性：（1）一致性：所有需求必須是一致的，任何一條需求不能和其他需求互相矛盾。(2)完整性： 需求必須是完整的，規(guī)格說明書應(yīng)該包括用戶需要的每一個功能或性能(3)現(xiàn)實(shí)性：指定的需求應(yīng)該是用現(xiàn)有的硬件技術(shù)和軟件技術(shù)基本上可以實(shí)現(xiàn)的。對硬件技術(shù)的進(jìn)步可以做些預(yù)測，對軟件技術(shù)的進(jìn)步則很難做出預(yù)測，只能從現(xiàn)有技術(shù)水平出發(fā)判斷需求的現(xiàn)實(shí)性。(4)有效性： 必須證明需求是正確有效的，確實(shí)能解決用戶面對的問題。

軟件設(shè)計過程有：1數(shù)據(jù)設(shè)計：將實(shí)體 – 關(guān)系圖中描述的對象和關(guān)系，以及數(shù)據(jù)詞典中描述的詳細(xì)數(shù)據(jù)內(nèi)容轉(zhuǎn)化為數(shù)據(jù)結(jié)構(gòu)的定義。2總體結(jié)構(gòu)（系統(tǒng)結(jié)構(gòu)）設(shè)計： 定義軟件系統(tǒng)各主要成份之間的關(guān)系。3過程設(shè)計： 把結(jié)構(gòu)成份轉(zhuǎn)換成軟件的過程性描述。4接口設(shè)計：定義軟件內(nèi)部各成份之間、軟件與其它協(xié)同系統(tǒng)之間及軟件與用戶之間的交互機(jī)制。軟件設(shè)計方法：結(jié)構(gòu)化設(shè)計方法(SD)面向數(shù)據(jù)結(jié)構(gòu)的設(shè)計方法(JSD方法)面向?qū)ο蟮脑O(shè)計方法(OOD)

軟件設(shè)計分兩個階段完成：結(jié)構(gòu)設(shè)計：結(jié)構(gòu)設(shè)計是總體設(shè)計階段的任務(wù)。結(jié)構(gòu)設(shè)計確定程序由哪些模塊組成，以及這些模塊之間的關(guān)系。過程設(shè)計：確定每個模塊的處理過程

結(jié)構(gòu)程序設(shè)計:一種設(shè)計程序的技術(shù)，它采用自頂向下逐步求精的設(shè)計方法和單入口單出口的控制結(jié)構(gòu)

軟件測試：是根據(jù)軟件開發(fā)各階段的文檔資料和程序的內(nèi)部結(jié)構(gòu)，精心設(shè)計一組“高產(chǎn)”的測試用例，利用這些實(shí)例執(zhí)行程序，找出軟件中潛在的各種錯誤和缺陷的過程 黑盒法（黑盒技術(shù)是把被測試對象看成一個黑盒子，測試人員完全不考慮程序的內(nèi)部結(jié)構(gòu)和處理過程，只在軟件的接口處進(jìn)行測試，依據(jù)需求規(guī)格說明書，檢查程序是否滿足功能要求 白盒法（白盒技術(shù)）：是把測試對象看作一個打開的盒子，測試人員須了解程序的內(nèi)部結(jié)構(gòu)和處理過程，以檢查處理過程的細(xì)節(jié)為基礎(chǔ)，對程序中盡可能多的邏輯路徑進(jìn)行測試，檢查內(nèi)部控制結(jié)構(gòu)和數(shù)據(jù)結(jié)構(gòu)是否有錯，實(shí)際的運(yùn)行狀態(tài)與預(yù)期的狀態(tài)是否一致。驅(qū)動模塊：驅(qū)動模塊是用來模擬被測模塊的上級調(diào)用模塊的模塊，功能要比真正的上級模塊簡單得多，它只完成接受測試數(shù)據(jù)，以上級模塊調(diào)用被測模塊的格式驅(qū)動被測模塊，接收被測模塊的測試結(jié)果并輸出。

樁模塊：樁模塊用來代替被測試模塊所調(diào)用的模塊。它的作用是返回被測模塊所需的信息。單元測試：：單元測試指對源程序中每一個程序單元進(jìn)行測試，檢查各個模塊是否正確實(shí)現(xiàn)規(guī)定的功能，從而發(fā)現(xiàn)模塊在編碼中或算法中的錯誤。

集成測試：是指在單元測試的基礎(chǔ)上，將所有模塊按照設(shè)計要求組裝成一個完整的系統(tǒng)進(jìn)行的測試，故也稱組裝測試或聯(lián)合測試。

確認(rèn)測試：又稱有效性測試。是為了檢查軟件的功能與性能是否與需求規(guī)格說明書中確定的指標(biāo)相符合所進(jìn)行的測試

單元測試內(nèi)容①模塊接口②局部數(shù)據(jù)結(jié)構(gòu)③重要的執(zhí)行路徑④錯誤處理⑤邊界條件。調(diào)試的目的確定錯誤的原因和位置，并改正錯誤，因此調(diào)試也稱為糾錯(Debug)調(diào)試的技術(shù)手段有簡單的調(diào)試方法、歸納法、演繹法和回溯法等 軟件可維護(hù)性：軟件能夠被理解、校正、適應(yīng)及增強(qiáng)功能的容易程度

為了保證軟件的可維護(hù)性，需要做哪些質(zhì)量保證檢查?（1）在檢查點(diǎn)進(jìn)行檢查。檢查點(diǎn)是指軟件開發(fā)的每一個階段的終點(diǎn)。（2）驗(yàn)收檢查。驗(yàn)收檢查是一個特殊的檢查點(diǎn)的檢查，它是把軟件從開發(fā)轉(zhuǎn)移到維護(hù)的最后一次檢查。（3）周期性的維護(hù)檢查（4）對軟件包的檢查。好的文檔有以下幾方面的作用：（1）好的文檔能提高程序的可閱讀性，但壞的文檔比沒有文檔更壞；（2）好的文檔意味著簡明性，風(fēng)格的一致性，容易修改；（3）程序編碼中應(yīng)該有必要的注釋以提高程序的可理解性；（4）程序越長、越復(fù)雜，則它對文檔的需求也越迫切 軟件維護(hù)的流程：定維護(hù)申請報告。審查申請報告并批準(zhǔn)。進(jìn)行維護(hù)并做詳細(xì)記錄。復(fù)審 面向?qū)ο蠓椒▽W(xué)的出發(fā)點(diǎn)和基本原則:是盡可能模擬人類習(xí)慣的思維方式，使開發(fā)軟件的方法與過程盡可能接近人類認(rèn)識世界解決問題的方法與過程.描述問題的問題域與實(shí)現(xiàn)解法的求解域在結(jié)構(gòu)上盡可能一致。

對象是用面向?qū)ο蠓椒▽W(xué)開發(fā)軟件時對客觀世界實(shí)體的抽象，它是由描述實(shí)體屬性的數(shù)據(jù)及可以對這些數(shù)據(jù)施加的所有操作封裝在一起構(gòu)成的統(tǒng)一體。傳統(tǒng)的數(shù)據(jù)是用傳統(tǒng)方法學(xué)開發(fā)軟件時對客觀世界實(shí)體的抽象，但是，種抽象是不全面的：數(shù)據(jù)只能描述實(shí)體的靜態(tài)屬性，不能描述實(shí)體的動態(tài)行為。必須從外界對數(shù)據(jù)施加操作，才能改變數(shù)據(jù)實(shí)現(xiàn)實(shí)體應(yīng)有的行為。對象與傳統(tǒng)數(shù)據(jù)有本質(zhì)區(qū)別，它不是被動地等待外界對它施加操作，相反，它是進(jìn)行處理的主體。必須發(fā)消息請求對象主動地執(zhí)行它的某些操作，處理它的私有數(shù)據(jù)，而不能直接從外界對它的私有數(shù)據(jù)進(jìn)行操作。

對象模型的五個層次：主題層（也稱為范疇層），類—&—對象層，結(jié)構(gòu)層，屬性層，服務(wù)層

面向?qū)ο髮?shí)現(xiàn)主要包括兩項工作：把面向?qū)ο笤O(shè)計結(jié)果，翻譯成用某種程序語言書寫的面向?qū)ο蟪绦颍粶y試并調(diào)試面向?qū)ο蟮某绦?/p>

面向?qū)ο筌浖臏y試分四個層次進(jìn)行：算法層、類層、主題層、系統(tǒng)層

項目管理者的目標(biāo): 定義全部項目任務(wù)，識別出關(guān)鍵任務(wù)，跟蹤關(guān)鍵任務(wù)的進(jìn)展?fàn)顩r，以保證能及時發(fā)現(xiàn)拖延進(jìn)度的情況

軟件配置管理主要有5項任務(wù)： 標(biāo)識 版本控制 變化控制 配置審計 報告 軟件工程實(shí)施項目管理的目的 ： 在于它能夠幫助我們進(jìn)行系統(tǒng)性思考，并切實(shí)可行地進(jìn)行全局性安排，同時也可以為項目開發(fā)的人力資源需求提供依據(jù)。

項目管理者的任務(wù)：確保信息系統(tǒng)項目符合預(yù)算和進(jìn)度要求，并確保交付的系統(tǒng)能夠達(dá)到預(yù)定的目標(biāo)

軟件的質(zhì)量保證活動： 是確保軟件產(chǎn)品從誕生到消亡為止的所有階段的質(zhì)量的活動。即為了確定、達(dá)到和維護(hù)需要的軟件質(zhì)量而進(jìn)行的所有有計劃、有系統(tǒng)的管理活動 對編制高質(zhì)量文檔的要求：(1)針對性(2)精確性(3)清晰性(4)完整性(5)靈活性

第四篇：軟件工程考試

第一章 軟件工程學(xué)概述

1.軟件的概念，軟件的分類

答：軟件=程序+數(shù)據(jù)+文檔；

按規(guī)模分類：微型、小型、中型、大型、甚大形、極大型（6）

按性質(zhì)分類：系統(tǒng)軟件、支撐軟件、應(yīng)用軟件（3）

按工作方式分類：實(shí)時、分時、交互式、批處理（4）

按服務(wù)對象分類：項目軟件、產(chǎn)品軟件（2）

2.軟件危機(jī)產(chǎn)生的原因（2點(diǎn)），緩解軟件危機(jī)的途徑

答：和軟件本身的特點(diǎn)有關(guān)，和開發(fā)軟件的方法不正確有關(guān)；

軟件工程；

3.軟件生命周期包含的活動

答：問題定義、可行性研究、需求分析、總體設(shè)計、詳細(xì)設(shè)計、編碼、測試（8）

4.問題定義階段的任務(wù)

答：確定軟件規(guī)模、性質(zhì)、目標(biāo)

5.常見的軟件開發(fā)模型

瀑布模型：適用范圍是需求確定的軟件開發(fā)，是描述結(jié)構(gòu)化的軟件開發(fā)模型；

快速原型模型：適用范圍是需求不確定的軟件開發(fā)；

噴泉模型：是描述面向?qū)ο蟮能浖_發(fā)模型；

第二章 可行性研究

1.可行性研究從哪些方面進(jìn)行

答：經(jīng)濟(jì)，技術(shù)，法律，操作（4）

2.系統(tǒng)流圖SFD的作用

答：描述系統(tǒng)的工作過程，建立系統(tǒng)的業(yè)務(wù)模型

3.數(shù)據(jù)流圖DFD的作用，符號，畫法

答：描述系統(tǒng)的功能，建立系統(tǒng)的功能模型

符號：外部實(shí)體（正方形），處理（圓形），存儲（雙實(shí)線），數(shù)據(jù)流（單箭頭線）畫法：分離成分，分層畫DFD（頂層，0層，1層）

第三章 需求分析

1.結(jié)構(gòu)化的需求分析方法SA的原理

答：用DFD、DD進(jìn)行功能分析，建立系統(tǒng)的功能模型，用E-R進(jìn)行數(shù)據(jù)分析，建立系統(tǒng)的數(shù)據(jù)模型

第五章 總體設(shè)計

1.總體設(shè)計的原理

答：模塊化、抽象、逐步求精、信息隱藏和局部化、模塊獨(dú)立（5）

2.衡量模塊獨(dú)立的指標(biāo)

答：耦合，內(nèi)聚 3.總體設(shè)計的啟發(fā)規(guī)則（7點(diǎn)）

答：改進(jìn)軟件結(jié)構(gòu)提高模塊獨(dú)立性

模塊規(guī)模應(yīng)該適中

深度、寬度、扇出和扇入都應(yīng)適當(dāng)

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

力爭降低模塊接口的復(fù)雜程度

設(shè)計單入口單出口的模塊

模塊功能應(yīng)該可以預(yù)測

4.結(jié)構(gòu)化的設(shè)計方法SD的原理

答：將DFD映射成軟件結(jié)構(gòu)圖

第六章 詳細(xì)設(shè)計

1.用結(jié)構(gòu)化方法進(jìn)行開發(fā)在詳細(xì)設(shè)計階段的任務(wù)

答：對模塊進(jìn)行設(shè)計，主要是設(shè)計模塊的界面和算法 2.結(jié)構(gòu)化程序設(shè)計SP的原則（7點(diǎn)）

答：采用自頂向下、逐步求精的設(shè)計方法

程序中用順序、選擇、多分支、while型循環(huán)、until型循環(huán)表示程序邏輯

每種控制結(jié)構(gòu)單入口、單出口

程序語句組成模塊，每個模塊單入口單出口

復(fù)雜的結(jié)構(gòu)用5種基本控制結(jié)構(gòu)組合嵌套實(shí)現(xiàn)

嚴(yán)格控制goto語句的使用，在下列情況可用：

在非結(jié)構(gòu)化的語言中，用goto語句實(shí)現(xiàn)結(jié)構(gòu)化的構(gòu)造

在某種可以改善而不是損害可讀性的情況下

不僅要注意程序的結(jié)構(gòu)化，還要注意數(shù)據(jù)結(jié)構(gòu)的合理化

3.判斷算法是否為結(jié)構(gòu)化的依據(jù)（3點(diǎn)）

答：由5種基本控制結(jié)構(gòu)組成；

每種控制結(jié)構(gòu)單入口單出口；

模塊單入口單出口

4.描述算法的工具

答：圖形工具：N-S圖，PAD圖，活動圖

語言工具：PDL語言

表格工具：判定表、判定樹

5.算法環(huán)形復(fù)雜度的度量（流程圖-流圖-區(qū)域數(shù)）

答：流程圖-流圖轉(zhuǎn)換方法：

一個判斷框縮成一個點(diǎn)；

一個處理框縮成一個點(diǎn)；

一個順序處理序列縮成一個點(diǎn)；

判定框和與之相連的處理框縮成一個點(diǎn)；

真假分支的匯聚點(diǎn)增加一個點(diǎn)

第七章 實(shí)現(xiàn)

1.編碼的風(fēng)格（判斷題）

答：程序內(nèi)部的文檔：恰當(dāng)?shù)臉?biāo)識符（含義鮮明、縮寫（必須保留第一個字母、輔音字母由于元音字母、字首優(yōu)于字尾）+注解）、適當(dāng)?shù)淖⒔猓ㄐ蜓孕宰⒔狻⒐δ苄宰⒔猓⒊绦虻囊曈X組織（布局、空行、縮進(jìn)）

2.測試的概念、原則、方法，步驟

答：概念：用最少的時間和人力，找到軟件中盡可能多的錯誤和缺陷

原則：

盡早的和不斷的測試；

事先要制定測試計劃，嚴(yán)格執(zhí)行學(xué)生計劃，排除測試的隨意性；

測試從小規(guī)模測試開始，逐步進(jìn)行大規(guī)模測試；

充分注意測試中的“群集”現(xiàn)象；

“窮舉”測試不可能，應(yīng)該精心設(shè)計測試方案，使測試方案充分的覆蓋程序邏輯，以盡可能多的發(fā)現(xiàn)程序中的錯誤；

測試方案應(yīng)該包含合理的輸入條件和不合理的輸入條件；

測試應(yīng)由獨(dú)立的第三方從事；

方法有黑盒測試和白盒測試

步驟是單元測試、集成測試、系統(tǒng)測試、確認(rèn)測試

3.白盒測試法有哪些，黑盒測試法有哪些

答：白盒測試法有：邏輯覆蓋法、基本路徑法覆蓋法、循環(huán)覆蓋法

黑盒測試法有：等價劃分法，分界值分析法，錯誤推算法

4.用邏輯覆蓋法設(shè)計測試方案

5.黑盒測試技術(shù)的原理

答：在測試中，把程序看作一個不能打開的黑盒子，在完全不考慮程序內(nèi)部結(jié)構(gòu)和內(nèi)部 特性的情況下，在程序接口進(jìn)行測試，它只檢查程序功能是否按照需求規(guī)格說明書的規(guī)定正常使用，程序是否能適當(dāng)?shù)亟邮蛰斎霐?shù)據(jù)而產(chǎn)生正確的輸出信息。

6.可靠性的概念

答：軟件可靠性是程序在給定的事件間隔內(nèi)，按照規(guī)格說明書的規(guī)定成功的運(yùn)行的概率；可靠性是衡量軟件質(zhì)量的指標(biāo)

7.可靠性的計算

第八章 維護(hù)

1.維護(hù)的概念、分類

答：在軟件已經(jīng)交付使用后，為了改正錯誤或滿足新的需要而修改軟件的過程； 改正型維護(hù)，完善型維護(hù)，適應(yīng)型維護(hù)，預(yù)防型維護(hù)；

第九章 實(shí)戰(zhàn)

1.軟件有哪些開發(fā)方法

答：結(jié)構(gòu)化的開發(fā)方法、面向?qū)ο蟮拈_發(fā)方法、傳統(tǒng)的開發(fā)方法與面向?qū)ο蟮拈_發(fā)方法相結(jié)合的實(shí)用開發(fā)方法

2.傳統(tǒng)的軟件開發(fā)方法的開發(fā)步驟

答：問題定義，可行性研究，需求分析

業(yè)務(wù)分析（業(yè)務(wù)描述，建立業(yè)務(wù)模型）

功能分析（功能描述，功能模型）

數(shù)據(jù)分析

總體設(shè)計

建立軟件結(jié)構(gòu)

設(shè)計數(shù)據(jù)庫的表結(jié)構(gòu)

詳細(xì)設(shè)計

模塊設(shè)計

建立數(shù)據(jù)庫，錄入數(shù)據(jù)

實(shí)現(xiàn)

編碼，測試

3.面向?qū)ο蟮拈_發(fā)方法的開發(fā)步驟

答：問題定義，可行性研究

面向?qū)ο蟮姆治?/p>

業(yè)務(wù)分析

功能分析，建立系統(tǒng)的功能模型（參與者，需求結(jié)構(gòu)，功能模型）對象分析，建立系統(tǒng)初步的對象模型

用例分析，建立用例分析模型（順序圖，活動圖）

擴(kuò)充和完善，建立系統(tǒng)完整的對象模型

面向?qū)ο蟮目傮w設(shè)計

擴(kuò)充和完善功能模型

軟件運(yùn)行環(huán)境

軟件架構(gòu)模型（軟件架構(gòu)模式，軟件分層架構(gòu)，軟件邏輯結(jié)構(gòu)）

擴(kuò)充和完善對象模型，建立平臺相關(guān)對象模型

用例設(shè)計模型（順序圖，活動圖）

數(shù)據(jù)庫設(shè)計模型（數(shù)據(jù)庫的表結(jié)構(gòu)，數(shù)據(jù)庫的邏輯結(jié)構(gòu)）

界面設(shè)計模型（界面結(jié)構(gòu)模型，屏幕界面模型）

組件圖

部署模型

面向?qū)ο蟮脑敿?xì)設(shè)計

確定每個用例的實(shí)現(xiàn)算法

建立數(shù)據(jù)庫，錄入數(shù)據(jù)

面向?qū)ο髮?shí)現(xiàn)

編碼，測試

4.BCE、MVC是什么

答：BCE是用例分析模式、MVC是程序設(shè)計思想

5.傳統(tǒng)的開發(fā)方法與面向?qū)ο蟮拈_發(fā)方法相結(jié)合的實(shí)用開發(fā)方法的開發(fā)步驟 答：問題定義，可行性研究

需求分析

業(yè)務(wù)分析

功能分析

數(shù)據(jù)分析

動態(tài)分析

總體設(shè)計

軟件運(yùn)行環(huán)境

軟件架構(gòu)模式（C/S B/S）

建立軟件結(jié)構(gòu)圖

設(shè)計數(shù)據(jù)庫的表結(jié)構(gòu)

詳細(xì)設(shè)計

模塊設(shè)計

建立數(shù)據(jù)庫，錄入數(shù)據(jù)

實(shí)現(xiàn)

編碼，測試

第五篇：軟件工程總結(jié)

1.Software is a product and can be manufactured using the same technologies used for other engineering artifacts Answer: b 2.WebApps are a mixture of print publishing and software development, making their development outside the realm of software engineering practice.Answer: b 3.Software engineering umbrella activities are only applied during the initial phases of software development projects.Answer: b 4.Planning ahead for software reuse reduces the cost and increases the value of the systems into which they are incorporated.Answer: a 5.The essence of software engineering practice might be described as understand the problem, plan a solution, carry out the plan, and examine the result for accuracy.Answer: a 6.In agile process models the only deliverable work product is the working program.Answer: b 7.A most software development projects are initiated to try to meet some business need.Answer: a 8.In general software only succeeds if its behavior is consistent with the objectives of its designers.Answer: b 9.Software processes can be constructed out of pre-existing software patterns to best meet the needs of a software project.Answer: a 10.Process technology tools allow software organizations to compress schedules by skipping unimportant activities.Answer: b 11.It is generally accepted that one cannot have weak software processes and create high quality end products.Answer: a 1.Requirements engineering is a generic process that does not vary from one software project to another.Answer: a 2.A stakeholder is anyone who will purchase the completed software system under development.Answer: b 3.It is relatively common for different customers to propose conflicting requirements, each arguing that his or her version is the right one.Answer: a 4.Developers and customers create use-cases to help the software team understand how different classes of end-users will use functions.Answer: a 5.Use-case actors are always people, never system devices.Answer: b 6.Analysis patterns facilitate the transformation of the analysis model into a design model by suggesting reliable solutions to common problems.Answer: a 7.In win-win negotiation, the customer’s needs are met even though the developer’s need may not be.Answer: b 8.In requirements validation the requirements model is reviewed to ensure its technical feasibility.Answer: b

1.Object-oriented domain analysis is concerned with the identification and specification of reusable capabilities within an application domain.Answer: a 2.In structured analysis models focus on the structure of the classes defined for a system along with their interactions.Answer: b 3.Creation and refinement of use cases if an important part of scenario-based modeling.Answer: a 4.It is important to consider alternative actor interactions when creating a preliminary use case.Answer: b 5.Brainstorming is one technique that may be used to derive a complete set of use case exceptions.Answer: a 6.In many cases there is no need to create a graphical representation of a usage scenario.Answer: a 7.One or more attributes of a data object must be defined as a key to allow the location of an instance of the data object.Answer: a 8.Attributes are chosen for an object by examining the problem statement and identifying the entities that appear to be related.Answer: b 9.An analysis package involves the categorization of analysis model elements into useful groupings.Answer: a 10.The data flow diagram must be augmented by min-spec that can serve as a guide the design of the software component that will implement the process.Answer: a 11.The UML sequence diagram show the order in which system events are processed.Answer: b 12.Analysis patterns are discovered, they are not explicitly created.Answer: a 13.It is not possible to justify the time required for WebApp requirements analysis.Answer: b 14.UML activity diagrams can be used to represent the user observable functionality delivered by the WebApp as well as the operations contained in each analysis class.Answer: a 15.Configuration analysis focuses on the architecture of the user’s web browsing environment.Answer: b 16.Content objects are extracted from use cases by examining the scenario description for direct or indirect content references.Answer: a 1.With thorough testing it is possible to remove all defects from a program prior to delivery to the customer.Answer: b 2.Program flow graphs are identical to program flowcharts.Answer: b 3.The cyclomatic complexity of a program can be computed directly from a PDL representation of an algorithm without drawing a program flow graph.Answer: a 4.Graph-based testing methods can only be used for object-oriented systems Answer: b 5.Equivalence testing divides the input domain into classes of data from which test cases can be derived to reduce the total number of test cases that must be developed.Answer: a 6.Boundary value analysis can only be used to do white-box testing.Answer: b 7.Orthogonal array testing enables the test designer to maximize the coverage of the test cases devised for relatively small input domains.Answer: a 8.Client/server architectures cannot be properly tested because network load is highly variable.Answer: b 1.The best representation of system architecture is an operational software prototype.Answer: b 2.The architectural representations can be an enabler for communication among project stakeholders.Answer: a 3.An architectural description is often documented using an architecture template.Answer: b 4.An architectural genre will often dictate the architectural approach that may used for the structure to be built.Answer: a 5.Before an architectural pattern can be chosen for use in a specific system it must have a code implementation to facilitate its reuse.Answer: b 6.Once selected, archetypes always need to be refined further as architectural design proceeds.Answer: a 7.Quantitative methods for assessing the quality of proposed architectural designs are readily available.Answer: b

Chapter 10 Self-Check Quiz

1.In the most general sense a component is a modular building block for computer software.a.True b.False

Answer: a(Section 10.1)

2.In the context of object-oriented software engineering a component contains

a.attributes and operations b.instances of each class c.roles for each actor(device or user)d.set of collaborating classes

Answer: d(Section 10.1.1)

3.In traditional software engineering modules must serve in which of the following roles?

a.Control component b.Infrastructure component c.Problem domain component d.All of the above

Answer: d(Section 10.1.2)

4.Software engineers always need to cerate components from scratch in order to meet customer expectations fully.a.True b.False

Answer: b(Section 10.1.3)

5.Which of the following is not one of the four principles used to guide component-level design?

a.Dependency Inversion Principle b.Interface Segregation Principle c.Open-Closed Principle d.Parsimonious Complexity Principle

Answer: d(Section 10.2.1)

6.The use of stereotypes can help identify the nature of components at the detailed design level.a.True b.False

Answer: a(Section 10.2.2)

7.Classes and components that exhibit functional, layer, or communicational cohesion are relatively easy to implement, test, and maintain.a.True b.False

Answer: a(Section 10.2.3)

8.Software coupling is a sign of poor architectural design and can always be avoided in every system.a.True b.False

Answer: b(Section 10.2.4)

9.WebApp content design at the component level focuses on content objects and the manner in which they interact.a.True b.False

Answer: b(Section 10.4.1)

10.A WebApp functional architecture describes the key functional components and how they interact with each other.a.True b.False

Answer: a(Section 10.4.2)

11.Which of these is a graphical notation for depicting procedural detail?

a.box diagram b.decision table c.ER diagram d.flowchart

Answer: d(Section 10.5.1)

12.A decision table should be used

a.to document all conditional statements b.to guide the development of the project management plan c.only when building an expert system d.when a complex set of conditions and actions appears in a component

Answer: d(Section 10.5.2)

13.A program design language(PDL)is often a

a.combination of programming constructs and narrative text b.legitimate programming language in its own right c.machine readable software development language d.useful way to represent software architecture

Answer: a(Section 10.5.3)

14.In component-based software engineering, the development team examines the requirements to see which are amenable to composition, rather than construction, before beginning detailed design tasks.a.True b.False

Answer: a(Section 10.6)

15.Which of the following is not one of the major activities of domain engineering?

a.analysis b.construction c.dissemination d.validation

Answer: d(Section 10.6.1)

16.Which of the following factors would not be considered during component qualification?

a.application programming interface(API)b.development and integration tools required c.exception handling d.testing equipment required

Answer: d(Section 10.6.2)

17.Which is the following is a technique used for component wrapping?

a.black-box wrapping b.clear-box wrapping c.gray-box wrapping d.white-box wrapping

Answer: b(Section 10.6.2)

18.Which of the following is not one of the issues that form a basis for design for reuse?

a.object-oriented programming b.program templates c.standard data d.standard interface protocols

Answer: a(Section 10.6.3)

19.In a reuse environment, library queries are often characterized using the ________ element of the 3C Model.a.concept b.content c.context d.all of the above

Answer: c(Section 10.6.4)

1.The importance of software design can be summarized in a single word a.b.c.d.Answer: d(Section 8.1)

2.Which of the following is not a characteristic common to all design methods?

a.configuration management b.functional component representation c.quality assessment guidelines d.refinement heuristics

Answer: a(Section 8.2.2)

3.Which of the following can be used to represent the architectural design of a piece of software?

a.Dynamic models b.Functional models c.Structural models d.All of the above

Answer: d(Section 8.3.2)

4.Design patterns are not applicable to the design of object-oriented software?

a.True b.False

Answer: b(Section 8.3.3)

5.Since modularity is an important design goal it is not possible to have too many modules in a proposed design.a.True b.False

Answer: b(Section 8.3.5)

6.Information hiding makes program maintenance easier by hiding data and procedure from unaffected parts of the program.accuracy complexity efficiency quality

a.True b.False

Answer: a(Section 8.3.6)

7.Cohesion is a qualitative indication of the degree to which a module

a.can be written more compactly.b.focuses on just one thing.c.is able to complete its function in a timely manner.d.is connected to other modules and the outside world.Answer: b(Section 8.3.7)

8.Coupling is a qualitative indication of the degree to which a module

a.can be written more compactly.b.focuses on just one thing.c.is able to complete its function in a timely manner.d.is connected to other modules and the outside world.Answer: d(Section 8.3.7)

9.When using structured design methodologies the process of stepwise refinement is unnecessary.a.True b.False

Answer: b(Section 8.3.8)

10.Software designs are refactored to allow the creation of software that is easier to integrate, easier to test, and easier to maintain.a.True b.False

Answer: a(Section 8.3.10)

11.Which of the following is not one of the five design class types

a.Business domain classes b.Entity classes c.Process classes d.User interface classes

Answer: b(Section 8.3.13)

12.Which design model elements are used to depict a model of information represented from the user’s view?

a.Architectural design elements b.Component-level design elements c.Data design elements d.Interface design elements

Answer: c(Section 8.4.1)

13.Which design is equivalent to the floor plan of a house?

a.Architectural design b.Component-level design c.Data design d.Interface design

Answer: a(Section 8.4.2)

14.Which design model is equivalent to the detailed drawings of the access points and external utilities for a house?

a.Architectural design b.Component-level design c.Data design d.Interface design

Answer: d(Section 8.4.3)

15.Which design model is equivalent to a set of detailed drawings for each room in a house?

a.Architectural design b.Component-level design c.Data design d.Interface design

Answer: b(Section 8.4.4)

16.The deployment design elements specify the build order for the software components.a.True b.False

Answer: b(Section 8.4.5)