第一篇：軟件工程導(dǎo)論復(fù)習(xí)重點(diǎn)總結(jié)很全(第六版)(精)

第1章軟件工程學(xué)概述 1.1 軟件危機(jī) 1.1.1 軟件危機(jī)的介紹

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

軟件危機(jī)包含下述兩方面的問題: 如何開發(fā)軟件,滿足對軟件日益增長的需求;如何維護(hù)數(shù)量不斷膨脹的已有軟件。軟件危機(jī)的典型表現(xiàn):(1對軟件開發(fā)成本和進(jìn)度的估計(jì)常常很不準(zhǔn)確;(2用戶對“已完成的”軟件系統(tǒng)不滿意的現(xiàn)象經(jīng)常發(fā)生;(3軟件產(chǎn)品的質(zhì)量往往靠不住;(4軟件常常是不可維護(hù)的;(5軟件通常沒有適當(dāng)?shù)奈臋n資料;(6軟件成本在計(jì)算機(jī)系統(tǒng)總成本中所占的比例逐年上升;(7軟件開發(fā)生產(chǎn)率提高的速度,遠(yuǎn)遠(yuǎn)跟不上計(jì)算機(jī)應(yīng)用迅速普及深入的趨勢。1.1.2 產(chǎn)生軟件危機(jī)的原因(1與軟件本身的特點(diǎn)有關(guān)

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

1.1.3 消除軟件危機(jī)的途徑 對計(jì)算機(jī)軟件有正確的認(rèn)識。

認(rèn)識到軟件開發(fā)是一種組織良好、管理嚴(yán)密、各類人員協(xié)同配合、共同完成的工程項(xiàng)目。應(yīng)該推廣使用在實(shí)踐中總結(jié)出來的開發(fā)軟件的成功技術(shù)和方法,并繼續(xù)研究探索。

應(yīng)該開發(fā)和使用更好的軟件工具。

總之,為了解決軟件危機(jī),既要有技術(shù)措施(方法和工具,又要有必要的組織管理措施。

1.2 1.2.1 軟件工程的介紹

軟件工程:是指導(dǎo)計(jì)算機(jī)軟件開發(fā)和維護(hù)的一門工程學(xué)科。采用工程的概念、原理、技術(shù)和方法來開發(fā)與維護(hù)軟件,把經(jīng)過時(shí)間考驗(yàn)而證明正確的管理技術(shù)和當(dāng)前能夠得到的最好的技術(shù)方法結(jié)合起來,以經(jīng)濟(jì)地開發(fā)出高質(zhì)量的軟件并有效地維護(hù)它,這就是軟件工程。(期中考

軟件工程的本質(zhì)特性: 軟件工程關(guān)注于大型程序的構(gòu)造 軟件工程的中心課題是控制復(fù)雜性 軟件經(jīng)常變化

開發(fā)軟件的效率非常重要 和諧地合作是開發(fā)軟件的關(guān)鍵 軟件必須有效地支持它的用戶

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

1.2.2 軟件工程的基本原理 用分階段的生命周期計(jì)劃嚴(yán)格管理 堅(jiān)持進(jìn)行階段評審 實(shí)行嚴(yán)格的產(chǎn)品控制 采用現(xiàn)代程序設(shè)計(jì)技術(shù) 結(jié)果應(yīng)能清楚地審查 開發(fā)小組的人員應(yīng)該少而精

承認(rèn)不斷改進(jìn)軟件工程實(shí)踐的必要性 1.2.3 軟件工程方法學(xué)

軟件工程包括技術(shù)和管理兩方面的內(nèi)容。軟件工程方法學(xué)3要素:方法、工具、過程

1.傳統(tǒng)方法學(xué)(生命周期方法學(xué)或結(jié)構(gòu)化范型——強(qiáng)調(diào)自頂向下 2.面向?qū)ο蠓椒▽W(xué)——強(qiáng)調(diào)主動(dòng)地多次反復(fù)迭代 面向?qū)ο蠓椒▽W(xué)4個(gè)要點(diǎn):對象、類、繼承、消息 1.3 軟件生命周期(必考

三個(gè)時(shí)期八個(gè)階段:軟件生命周期由軟件定義、軟件開發(fā)和運(yùn)行維護(hù)(也稱為軟件維護(hù)三個(gè)時(shí)期組成,每個(gè)時(shí)期又進(jìn)一步劃分成若干個(gè)階段。

三個(gè)時(shí)期:八個(gè)階段: 軟件生命周期軟件定義 軟件開發(fā) 軟件維護(hù) 問題定義 可行性研究 需求分析 概要設(shè)計(jì) 詳細(xì)設(shè)計(jì) 編碼和單元測試 綜合測試

運(yùn)行維護(hù) 系統(tǒng)設(shè)計(jì) 系統(tǒng)實(shí)現(xiàn) 1.4 軟件過程 1.4.1 瀑布模型

1.4.2 快速原型模型 1.4.3 增量模型 1.4.4 螺旋模型 1.4.5 噴泉模型 第2章可行性研究 2.1可行性研究的任務(wù) 可行性研究的目的: 不是解決問題,而是確定問題是否值得去解決?？尚行匝芯康膶?shí)質(zhì): 進(jìn)行一次大大壓縮簡化了的系統(tǒng)分析和設(shè)計(jì)的過程,也就是在較高層次上以較抽象的方式進(jìn)行的系統(tǒng)分析和設(shè)計(jì)的過程。

可行性研究的內(nèi)容: 首先進(jìn)一步分析和澄清問題定義,導(dǎo)出系統(tǒng)的邏輯模型;然后從系統(tǒng)邏輯模型出發(fā),探索若干種可供選擇的主要解法(即系統(tǒng)實(shí)現(xiàn)方案;對每種解法都研究它的可行性,至少應(yīng)該從三方面研究每種解法的可行性。主要方面: 技術(shù)可行性,經(jīng)濟(jì)可行性,操作可行性, 其他方面: 運(yùn)行可行性,法律可行性，2.2 可行性研究過程 1.復(fù)查系統(tǒng)規(guī)模和目標(biāo) 2.研究目前正在使用的系統(tǒng) 3.導(dǎo)出新系統(tǒng)的高層邏輯模型 4.進(jìn)一步定義問題 5.導(dǎo)出和評價(jià)供選擇的解法 6.推薦行動(dòng)方針 7.草擬開發(fā)計(jì)劃 8.書寫文檔提交審查 2.3 系統(tǒng)流程圖

系統(tǒng)流程圖:是概括地描繪物理系統(tǒng)的傳統(tǒng)工具。表達(dá)的是數(shù)據(jù)在系統(tǒng)各部件之間流動(dòng)的情況,而不是對數(shù)據(jù)進(jìn)行加工處理的控制過程。

2.4數(shù)據(jù)流圖 2.4.1符號 基本符號:

數(shù)據(jù)存儲(chǔ):數(shù)據(jù)存儲(chǔ)是處于靜止?fàn)顟B(tài)的數(shù)據(jù);數(shù)據(jù)流:數(shù)據(jù)流是處于運(yùn)動(dòng)中的數(shù)據(jù)。附加符號: 星號(*:表示“與”關(guān)系 加號(+:表示“或”關(guān)系 異或(⊕:表示互斥關(guān)系 2.5數(shù)據(jù)字典

數(shù)據(jù)流圖和數(shù)據(jù)字典共同構(gòu)成系統(tǒng)的邏輯模型。2.5.1 數(shù)據(jù)字典的內(nèi)容

數(shù)據(jù)字典的組成:數(shù)據(jù)流數(shù)據(jù)流分量(即數(shù)據(jù)元素 數(shù)據(jù)存儲(chǔ)處理 2.5.2定義數(shù)據(jù)的方法 方法:對數(shù)據(jù)自頂向下分解。

數(shù)據(jù)組成方式(三種基本類型:順序選擇重復(fù)附加類型:可選 符號: =意思是等價(jià)于(或定義為;+意思是和(即,連接兩個(gè)分量;[]意思是或(即,從方括弧內(nèi)列出的若干個(gè)分量中選擇一個(gè),通常用“|”號隔開供選擇的分量;{ }意思是重復(fù)(即,重復(fù)花括弧內(nèi)的分量;常常使用上限和下限進(jìn)一步注釋表示重復(fù)的花括弧。

(意思是可選(即,圓括弧里的分量可有可無。2.5.3數(shù)據(jù)字典的實(shí)現(xiàn) 計(jì)算機(jī)實(shí)現(xiàn)人工實(shí)現(xiàn) 2.6成本/效益分析

2.6.1 成本估計(jì):1.代碼行技術(shù) 2.任務(wù)分解技術(shù) 3.自動(dòng)估計(jì)成本技術(shù) 2.6.2 成本/效益分析的方法 成本/效益分析涉及的4個(gè)概念: 1.貨幣的時(shí)間價(jià)值 2.投資回收期 3.純收入

4.投資回收率:P = F1/(1 + j + F2/(1 + j 2 + …+ Fn(1 + j n 第3章需求分析 需求分析的任務(wù): 需求分析是軟件定義時(shí)期的最后一個(gè)階段,它的基本任務(wù)是準(zhǔn)確地回答“系統(tǒng)必須做什么?”這個(gè)問題。

確定系統(tǒng)必須完成哪些工作,也就是對目標(biāo)系統(tǒng)提出完整、準(zhǔn)確、清晰、具體的要求。

系統(tǒng)分析員應(yīng)該寫出軟件需求規(guī)格說明書,以書面形式準(zhǔn)確地描述軟件需求 3.1需求分析的任務(wù) 確定對系統(tǒng)的綜合要求 分析系統(tǒng)的數(shù)據(jù)要求 導(dǎo)出系統(tǒng)的邏輯模型 修正系統(tǒng)開發(fā)計(jì)劃

3.1.1確定對系統(tǒng)的綜合要求 1.功能需求 2.性能需求

3.可靠性和可用性需求 4.出錯(cuò)處理需求 5.接口需求

6.約束 7.逆向需求

8.將來可能提出的要求 3.1.2 分析系統(tǒng)的數(shù)據(jù)要求 建立數(shù)據(jù)模型——ER圖

描繪數(shù)據(jù)結(jié)構(gòu)——層次方框圖和Warnier圖 數(shù)據(jù)結(jié)構(gòu)規(guī)范化

3.2 與用戶溝通獲取需求的方法

訪談:1.正式訪談 2.非正式訪談 3.調(diào)查表 4.情景分析技術(shù) 面向數(shù)據(jù)流自頂向下求精 簡易的應(yīng)用規(guī)格說明技術(shù)

快速建立軟件原型:(1 第四代技術(shù)(4GL(2 可重用的軟件構(gòu)件(3 形式化規(guī)格說明和原型環(huán)境

3.3分析建模與規(guī)格說明 3.3.1 分析建模

需求分析過程應(yīng)該建立3種模型:數(shù)據(jù)模型功能模型行為模型 數(shù)據(jù)字典是分析模型的核心

實(shí)體-聯(lián)系圖用于建立數(shù)據(jù)模型的圖形 數(shù)據(jù)流圖是建立功能模型的基礎(chǔ)

狀態(tài)轉(zhuǎn)換圖是行為建模的基礎(chǔ) 3.4實(shí)體-聯(lián)系圖

數(shù)據(jù)模型中包含3種相互關(guān)聯(lián)的信息:數(shù)據(jù)對象、數(shù)據(jù)對象的屬性、數(shù)據(jù)對象彼此間相互連接的關(guān)系

3.4狀態(tài)轉(zhuǎn)換圖 3.6.1狀態(tài) 狀態(tài)圖分類: 表示系統(tǒng)循環(huán)運(yùn)行過程,通常不關(guān)心循環(huán)是怎樣啟動(dòng)的。表示系統(tǒng)單程生命期,需要標(biāo)明初始狀態(tài)和最終狀態(tài)。3.6.2事件

事件就是引起系統(tǒng)做動(dòng)作或(和轉(zhuǎn)換狀態(tài)的控制信息。3.6.3符號

3.7其他圖形工具 3.7.1 層次方框圖 3.7.2Warnier圖 3.7.3IPO圖

3.8驗(yàn)證軟件需求(重點(diǎn)

3.8.1 從哪些方面驗(yàn)證軟件需求的正確性 一致性完整性現(xiàn)實(shí)性有效性 第五章總體設(shè)計(jì) 5.1設(shè)計(jì)過程 由兩個(gè)主要階段組成: 系統(tǒng)設(shè)計(jì)階段,確定系統(tǒng)的具體實(shí)現(xiàn)方案:設(shè)想供選擇的方案選取合理的方案推薦最佳方案

結(jié)構(gòu)設(shè)計(jì)階段,確定軟件結(jié)構(gòu):功能分解設(shè)計(jì)軟件結(jié)構(gòu)設(shè)計(jì)數(shù)據(jù)庫制定測試文檔書寫文檔審查和復(fù)查

5.2設(shè)計(jì)原理 5.2.1 模塊化 模塊化的作用: 采用模塊化原理可以使軟件結(jié)構(gòu)清晰,不僅容易設(shè)計(jì)也容易閱讀和理解。模塊化使軟件容易測試和調(diào)試,因而有助于提高軟件的可靠性。模塊化能夠提高軟件的可修改性。

模塊化也有助于軟件開發(fā)工程的組織管理。5.2.2抽象 5.2.3逐步求精

5.2.4信息隱藏和局部化 5.2.5 模塊獨(dú)立 盡量使用數(shù)據(jù)耦合, 少用控制耦合和特征耦合, 限制公共環(huán)境耦合的范圍, 完全不用內(nèi)容耦合。七種內(nèi)聚的優(yōu)劣評分結(jié)果: 高內(nèi)聚:功能內(nèi)聚 順序內(nèi)聚 中內(nèi)聚:通信內(nèi)聚 過程內(nèi)聚 低內(nèi)聚:時(shí)間內(nèi)聚 邏輯內(nèi)聚 偶然內(nèi)聚 5.3啟發(fā)規(guī)則

1.改進(jìn)軟件結(jié)構(gòu)提高模塊獨(dú)立性 2.模塊規(guī)模應(yīng)該適中

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

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

5.力爭降低模塊接口的復(fù)雜程度 6.設(shè)計(jì)單入口單出口的模塊 7.模塊功能應(yīng)該可以預(yù)測 5.4 描繪軟件結(jié)構(gòu)的圖形工具 5.4.1 層次圖和HIPO圖 1.層次圖(H圖

層次圖用來描繪軟件的層次結(jié)構(gòu)。很適于在自頂向下設(shè)計(jì)軟件的過程中使用。2.HIPO圖 5.4.2結(jié)構(gòu)圖

5.5面向數(shù)據(jù)流的設(shè)計(jì)方法

結(jié)構(gòu)化設(shè)計(jì)方法(簡稱SD方法,也就是基于數(shù)據(jù)流的設(shè)計(jì)方法。5.5.1概念

面向數(shù)據(jù)流的設(shè)計(jì)方法把信息流映射成軟件結(jié)構(gòu),信息流的類型決定了映射的方法。信息流有兩種類型:變換流事務(wù)流

第6章詳細(xì)設(shè)計(jì) 6.1 結(jié)構(gòu)程序設(shè)計(jì) 經(jīng)典的結(jié)構(gòu)程序設(shè)計(jì): 只允許使用順序、IF-THEN-ELSE型分支和DO-WHILE型循環(huán)這3種基本控制結(jié)構(gòu);擴(kuò)展的結(jié)構(gòu)程序設(shè)計(jì): 如果除了上述3種基本控制結(jié)構(gòu)之外,還允許使用DO-CASE型多分支結(jié)構(gòu)和DO-UNTIL型循環(huán)結(jié)構(gòu);修正的結(jié)構(gòu)程序設(shè)計(jì): 再加上允許使用LEAVE(或BREAK結(jié)構(gòu)。6.2人機(jī)界面設(shè)計(jì) 6.2.1設(shè)計(jì)問題

設(shè)計(jì)人機(jī)界面過程中會(huì)遇到的4個(gè)問題: 系統(tǒng)響應(yīng)時(shí)間:長度易變性

用戶幫助設(shè)施:集成的幫助設(shè)施附加的幫助設(shè)施 出錯(cuò)信息處理 命令交互

6.2.3 人機(jī)界面設(shè)計(jì)指南 一般交互指南 信息顯示指南 數(shù)據(jù)輸入指南 6.3過程設(shè)計(jì)的工具 6.3.1 程序流程圖(程序框圖 程序流程圖的主要缺點(diǎn): 程序流程圖本質(zhì)上不是逐步求精的好工具,它誘使程序員過早地考慮程序的控制流程,而不去考慮程序的全局結(jié)構(gòu)。

程序流程圖中用箭頭代表控制流,因此程序員不受任何約束,可以完全不顧結(jié)構(gòu)程序設(shè)計(jì)的精神,隨意轉(zhuǎn)移控制。

程序流程圖不易表示數(shù)據(jù)結(jié)構(gòu)。6.3.2盒圖(N-S圖 盒圖具有下述特點(diǎn):

功能域明確。不可能任意轉(zhuǎn)移控制。

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

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

它用二維樹形結(jié)構(gòu)的圖來表示程序的控制流,將這種圖翻譯成程序代碼比較容易。

PAD圖的主要優(yōu)點(diǎn)如下: 使用表示結(jié)構(gòu)化控制結(jié)構(gòu)的PAD符號設(shè)計(jì)出來的程序必然是結(jié)構(gòu)化程序。PAD圖所描繪的程序結(jié)構(gòu)十分清晰。PAD圖表現(xiàn)程序邏輯易讀、易懂、易記。

容易將PAD圖轉(zhuǎn)換成高級語言源程序,這種轉(zhuǎn)換可用軟件工具自動(dòng)完成。即可表示程序邏輯,也可描繪數(shù)據(jù)結(jié)構(gòu)。

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

判定表卻能夠清晰地表示復(fù)雜的條件組合與應(yīng)做的動(dòng)作之間的對應(yīng)關(guān)系。

判定表的缺點(diǎn): 判定表的含義不是一眼就能看出來的,初次接觸這種工具的人理解它需要有一個(gè)簡短的學(xué)習(xí)過程。

當(dāng)數(shù)據(jù)元素的值多于兩個(gè)時(shí),判定表的簡潔程度也將下降。6.3.5 判定樹 判定樹的優(yōu)點(diǎn): 它的形式簡單,一眼就可以看出其含義,因此易于掌握和使用。判定樹的缺點(diǎn): 簡潔性不如判定表,數(shù)據(jù)元素的同一個(gè)值往往要重復(fù)寫多遍,而且越接近樹的葉端重復(fù)次數(shù)越多。

畫判定樹時(shí)分枝的次序可能對最終畫出的判定樹的簡潔程度有較大影響。6.3.6 過程設(shè)計(jì)語言(偽碼 偽代碼的基本控制結(jié)構(gòu):

簡單陳述句結(jié)構(gòu):避免復(fù)合語句。

判定結(jié)構(gòu):IF_THEN_ELSE或CASE_OF結(jié)構(gòu)。選擇結(jié)構(gòu):WHILE_DO或REPEAT_UNTIL結(jié)構(gòu)。PDL的優(yōu)點(diǎn): 可以作為注釋直接插在源程序中間。有助于保持文檔和程序的一致性,提高了文檔的質(zhì)量?？梢允褂闷胀ǖ恼木庉嫵绦蚧蛭淖痔幚硐到y(tǒng),很方便地完成PDL的書寫和編輯工作。

已經(jīng)有自動(dòng)處理程序存在,而且可以自動(dòng)由PDL生成程序代碼。PDL的缺點(diǎn): 不如圖形工具形象直觀,描述復(fù)雜的條件組合與動(dòng)作間的對應(yīng)關(guān)系時(shí),不如判定表清晰簡單。

6.4 面向數(shù)據(jù)結(jié)構(gòu)的設(shè)計(jì)方法

面向數(shù)據(jù)結(jié)構(gòu)的設(shè)計(jì)方法的最終目標(biāo)是得出對程序處理過程的描述。6.4.1Jackson

A由B、C、D 3個(gè)元素順序組成根據(jù)條件A是B或C或D中的某一個(gè) A由B出現(xiàn)N次(N ≥0組成

6.4.2 改進(jìn)的Jackson圖 6.4.3 Jackson方法

6.5 程序復(fù)雜程度的定量度量 6.5.1 McCabe方法 1.流圖(程序圖

2.計(jì)算環(huán)形復(fù)雜度的方法 V(G=流圖中的區(qū)域數(shù) V(G=E-N+2 其中E是流圖中的邊數(shù),N是結(jié)點(diǎn)數(shù) V(G=P+1 其中P是流圖中判定結(jié)點(diǎn)的數(shù)目 6.5.2 Halstead方法

令N1為程序中運(yùn)算符出現(xiàn)的總次數(shù),N2為操作數(shù)出現(xiàn)的總次數(shù),程序長度N定義為: N=N1+N2 程序中使用的不同運(yùn)算符(包括關(guān)鍵字的個(gè)數(shù)n1,以及不同操作數(shù)(變量和常數(shù)的個(gè)數(shù)n2。預(yù)測程序長度的公式如下: H = n1 log2n1 + n2 log2n2 預(yù)測程序中包含錯(cuò)誤的個(gè)數(shù)的公式如下: E = N log2(n1+n2/3000 第7章實(shí)現(xiàn)

編碼和測試統(tǒng)稱為實(shí)現(xiàn)。7.1編碼

7.1.1 選擇程序設(shè)計(jì)語言 主要的實(shí)用標(biāo)準(zhǔn): 系統(tǒng)用戶的要求 可以使用的編譯程序 可以得到的軟件工具 工程規(guī)模 程序員的知識 軟件可移植性要求

軟件的應(yīng)用領(lǐng)域 7.1.2 編碼風(fēng)格

1.程序內(nèi)部的文檔:恰當(dāng)?shù)臉?biāo)識符適當(dāng)?shù)淖⒔獬绦虻囊曈X組織 2.數(shù)據(jù)說明 3.語句構(gòu)造 4.輸入輸出

5.效率:程序運(yùn)行時(shí)間存儲(chǔ)器效率輸入輸出的效率 7.2軟件測試基礎(chǔ) 7.2.1 軟件測試的目標(biāo)

測試是為了發(fā)現(xiàn)程序中的錯(cuò)誤而執(zhí)行程序的過程;好的測試方案是極可能發(fā)現(xiàn)迄今為止尚未發(fā)現(xiàn)的錯(cuò)誤的測試方案;成功的測試是發(fā)現(xiàn)了至今為止尚未發(fā)現(xiàn)的錯(cuò)誤的測試。7.2.3 測試方法 黑盒測試(功能測試: 把程序看作一個(gè)黑盒子;完全不考慮程序的內(nèi)部結(jié)構(gòu)和處理過程;是在程序接口進(jìn)行的測試。白盒測試(結(jié)構(gòu)測試: 把程序看成裝在一個(gè)透明的盒子里;

測試者完全知道程序的結(jié)構(gòu)和處理算法;按照程序內(nèi)部的邏輯測試程序,檢測程序中的主要執(zhí)行通路是否都能按預(yù)定要求正確工作。

7.2.4 測試步驟 1.模塊測試(單元測試

保證每個(gè)模塊作為一個(gè)單元能正確運(yùn)行;發(fā)現(xiàn)的往往是編碼和詳細(xì)設(shè)計(jì)的錯(cuò)誤。2.子系統(tǒng)測試

把經(jīng)過單元測試的模塊放在一起形成一個(gè)子系統(tǒng)來測試;著重測試模塊的接口。3.系統(tǒng)測試

把經(jīng)過測試的子系統(tǒng)裝配成一個(gè)完整的系統(tǒng)來測試;發(fā)現(xiàn)的往往是軟件設(shè)計(jì)中的錯(cuò)誤,也可能發(fā)現(xiàn)需求說明中的錯(cuò)誤;不論是子系統(tǒng)測試還是系統(tǒng)測試,都兼有檢測和組裝兩重含義,通常稱為集成測試。

4.驗(yàn)收測試(確認(rèn)測試

把軟件系統(tǒng)作為單一的實(shí)體進(jìn)行測試;它是在用戶積極參與下進(jìn)行的,而且可能主要使用實(shí)際數(shù)據(jù)(系統(tǒng)將來要處理的信息進(jìn)行測試;發(fā)現(xiàn)的往往是系統(tǒng)需求說明書中的錯(cuò)誤。

5.平行運(yùn)行

7.2.5 測試階段的信息流 輸入信息有兩類: 軟件配置,包括需求說明書、設(shè)計(jì)說明書和源程序清單等;測試配置,包括測試計(jì)劃和測試方案。7.3 單元測試

單元測試集中檢測模塊;單元測試和編碼屬于軟件過程的同一個(gè)階段;可以應(yīng)用人工測試和計(jì)算機(jī)測試這樣兩種不同類型的測試方法;單元測試主要使用白盒測試技術(shù),對多個(gè)模塊的測試可以并行地進(jìn)行。7.3.1 測試重點(diǎn) 模塊接口 局部數(shù)據(jù)結(jié)構(gòu) 重要的執(zhí)行通路 出錯(cuò)處理通路 邊界條件 7.3.2 代碼審查

由審查小組正式進(jìn)行測試稱為代碼審查;一次審查會(huì)上可以發(fā)現(xiàn)許多錯(cuò)誤,可以減少系統(tǒng)驗(yàn)證的總工作量。

7.3.3 計(jì)算機(jī)測試

驅(qū)動(dòng)程序是一個(gè)“主程序”,它接收測試數(shù)據(jù),傳送給被測試的模塊,并且印出有關(guān)的結(jié)果。存根程序代替被測試的模塊所調(diào)用的模塊。它使用被它代替的模塊的接口,可能做最少量的數(shù)據(jù)操作,印出對入口的檢驗(yàn)或操作結(jié)果,并且把控制歸還給調(diào)用它的模塊。

7.4 集成測試

集成測試是測試和組裝軟件的系統(tǒng)化技術(shù),主要目標(biāo)是發(fā)現(xiàn)與接口有關(guān)的問題。

由模塊組裝成程序時(shí)有兩種方法: 7.4.3 不同集成測試策略的比較

混合策略: 改進(jìn)的自頂向下測試方法 混合法 7.4.4 回歸測試 7.5 確認(rèn)測試

確認(rèn)測試也稱為驗(yàn)收測試,它的目標(biāo)是驗(yàn)證軟件的有效性。7.5.3 Alpha和Beta測試

Alpha測試是在受控的環(huán)境中進(jìn)行的。

Beta測試是軟件在開發(fā)者不能控制的環(huán)境中的“真實(shí)”應(yīng)用。1.接口測試 2.路徑測試 3.功能測試 4.健壯性測試 5.性能測試 6.用戶界面測試 7.信息安全測試 8.壓力測試 9.可靠性測試

10.安裝/反安裝測試確認(rèn)測試也稱為驗(yàn)收測試,它的目標(biāo)是驗(yàn)證軟件的有效性。Alpha測試是在受控的環(huán)境中進(jìn)行的。

Beta測試是軟件在開發(fā)者不能控制的環(huán)境中的“真實(shí)”應(yīng)用。4.接口測試 5.路徑測試 6.功能測試 4.健壯性測試 5.性能測試

6.用戶界面測試 7.信息安全測試 8.壓力測試 9.可靠性測試 10.安裝/反安裝測試 7.6 白盒測試技術(shù)

7.6.1 邏輯覆蓋 語句覆蓋

判定覆蓋:比語句覆蓋強(qiáng),但對程序邏輯的覆蓋程度仍不高。

條件覆蓋:判定覆蓋不一定包含條件覆蓋,條件覆蓋也不一定包含判定覆蓋。判定/條件覆蓋:有時(shí)判定/條件覆蓋也并不比條件覆蓋更強(qiáng)。

條件組合覆蓋:條件組合覆蓋標(biāo)準(zhǔn)的測試數(shù)據(jù)并不一定能使程序中的每條路徑都執(zhí)行到。

6.點(diǎn)覆蓋(語句覆蓋標(biāo)準(zhǔn)相同 7.邊覆蓋(判定覆蓋一致 8.路徑覆蓋

7.6.2 控制結(jié)構(gòu)測試覆蓋 1.基本路徑測試

基本路徑測試是Tom McCabe提出的一種白盒測試技術(shù)。首先計(jì)算程序的環(huán)形復(fù)雜度;以該復(fù)雜度為指南定義執(zhí)行路徑的基本集合;2.條件測試

從該基本集合導(dǎo)出的測試用例可保證程序中的每條語句至少執(zhí)行一次,而且每個(gè)條件在執(zhí)行時(shí)都將分別取真、假兩種值。

3.循環(huán)測試

循環(huán)測試是一種白盒測試技術(shù),它專注于測試循環(huán)結(jié)構(gòu)的有效性。在結(jié)構(gòu)化的程序中通常只有3種循環(huán),即簡單循環(huán)、串接循環(huán)和嵌套循環(huán)。7.7 黑盒測試技術(shù) 7.7.1 等價(jià)劃分 7.7.2 邊界值分析 7.7.3 錯(cuò)誤推測 7.9 軟降可靠性 7.9.1 基本概念 軟件可靠性: 程序在給定的時(shí)間間隔內(nèi),按照規(guī)格說明書的規(guī)定成功地運(yùn)行的概率。

軟件的可用性: 程序在給定的時(shí)間點(diǎn),按照規(guī)格說明書的規(guī)定,成功地運(yùn)行的概率。第8章維護(hù)

軟件工程的目的是要提高軟件的可維護(hù)性,減少軟件維護(hù)所需要的工作量,降低軟件系統(tǒng)的總成本。

8.1 軟件維護(hù)的定義

軟件維護(hù):在軟件已經(jīng)交付使用之后,為了改正錯(cuò)誤或滿足新的需要而修改軟件的過程?？煞譃?項(xiàng)活動(dòng): 改正性維護(hù) 適應(yīng)性維護(hù) 完善性維護(hù) 預(yù)防性維護(hù) 8.2軟件維護(hù)的特點(diǎn)

8.2.1 結(jié)構(gòu)化維護(hù)與非結(jié)構(gòu)化維護(hù)差別巨大 8.2.2 維護(hù)的代價(jià)高昂 8.2.3 維護(hù)的問題很多 8.3軟件維護(hù)過程 1.維護(hù)組織 2.維護(hù)報(bào)告

3.維護(hù)的事件流 4.保存維護(hù)記錄 5.評價(jià)維護(hù)活動(dòng) 8.4 軟件的可維護(hù)性

決定軟件可維護(hù)性的因素主要有7個(gè): 可理解性 可測試性 可修改性 可靠性 可移植性 可使用性 效率

第9章面向?qū)ο蠓椒▽W(xué)引論 9.1面向?qū)ο蠓椒▽W(xué)概述 9.1.1面向?qū)ο蠓椒▽W(xué)要點(diǎn)

(1認(rèn)為客觀世界是由各種對象組成的,任何事物都是對象

(2把所有對象都劃分成各種類對象,每個(gè)對象類都定義了一組數(shù)據(jù)和一組方法(3按照子類和父類的關(guān)系,把若干個(gè)對象類組成一個(gè)層次結(jié)構(gòu)的系統(tǒng)(4對象彼此之間僅能通過傳遞消息相互聯(lián)系

9.1.2 面向?qū)ο箝_發(fā)方法 面向?qū)ο?對象+類 +繼承+通信 9.1.4 面向?qū)ο蠓椒ńM成 面向?qū)ο蟮姆治?面向?qū)ο蟮脑O(shè)計(jì) 面向?qū)ο蟮某绦蛟O(shè)計(jì) 9.1.6 面向?qū)ο蠓椒ǖ膬?yōu)點(diǎn) 1.與人類習(xí)慣的思維方式一致 2.穩(wěn)定性好 3.可重用性好 4.可維護(hù)性好

5.較易開發(fā)大型軟件產(chǎn)品 9.2 面向?qū)ο蟮母拍?9.2.1 對象

是客觀事物或概念的抽象表述,即對客觀存在的事物的描述統(tǒng)稱為對象,對象可以是事、物、或抽象概念,是將一組數(shù)據(jù)和使用該數(shù)據(jù)的一組基本操作或過程封裝在一起的實(shí)體。

對象的特點(diǎn)(1 以數(shù)據(jù)為中心。

(2 對象是主動(dòng)的。(3 實(shí)現(xiàn)了數(shù)據(jù)封裝。(4 本質(zhì)上具有并行性。(5 模塊獨(dú)立性好。9.2.2 類

是一組具有相同屬性和相同操作的對象的集合。9.2.3 實(shí)例

由某個(gè)特定的類所描述的一個(gè)具體的對象。9.2.4 消息

向?qū)ο蟀l(fā)出的服務(wù)請求(互相聯(lián)系、協(xié)同工作等。一個(gè)消息包含3個(gè)部分:接收消息的對象,消息名,消息變元

9.2.5 方法

方法就是對象所能執(zhí)行的操作,也就是類中所定義的服務(wù)。9.2.6 屬性

屬性就是類中所定義的數(shù)據(jù),它是對客觀世界實(shí)體所具有的性質(zhì)的抽象。9.2.7 封裝

對象封裝了對象的數(shù)據(jù)以及對這些數(shù)據(jù)的操作。9.2.8 繼承(I 繼承是子類自動(dòng)地共享基類中定義的數(shù)據(jù)和方法的機(jī)制。

單重繼承:子類僅從一個(gè)父類繼承屬性和方法 多重繼承:子類可從多個(gè)父類繼承屬性和方法 9.2.9 多態(tài)性 9.2.10 重載 9.3 面向?qū)ο蠼?II 面向?qū)ο箝_發(fā)軟件,需要建立3種形式的模型。對象模型。描述系統(tǒng)數(shù)據(jù)結(jié)構(gòu)—數(shù)據(jù)結(jié)構(gòu)。動(dòng)態(tài)模型。描述系統(tǒng)控制結(jié)構(gòu)—執(zhí)行操作。功能模型。描述系統(tǒng)功能—數(shù)值變化。9.4 對象模型

9.4.1類圖的基本符號(I 1.定義類

2.定義屬性

可見性屬性名:類型 = 缺省值 {性質(zhì)串} 可見性(visibility表示該屬性對類外的元素是否可見。分為: public(+公有的,即模型中的任何類都可以訪問該屬性。private(-私有的,表示不能被別的類訪問。

protected(#受保護(hù)的,表示該屬性只能被該類及其子類訪問。如果可見性未申明,表示其可見性不確定。

3.定義操作

可見性操作名(參數(shù)表:返回類型{性質(zhì)串}

9.4.2 表示關(guān)系的符號(I 9.4.2.1 關(guān)聯(lián)(I 關(guān)聯(lián)表示兩個(gè)類的對象之間存在某種語義上的聯(lián)系。(1普通關(guān)聯(lián)

遞歸關(guān)聯(lián):一個(gè)類與本身有關(guān)聯(lián)關(guān)系(3限定關(guān)聯(lián)

(4關(guān)聯(lián)類

9.4.2.2 聚集(I(1共享聚集

如果在聚集關(guān)系中處于部分方的對象可同時(shí)參與多個(gè)處于整體方對象的構(gòu)成,則該聚集稱為共享聚集。

(2組合聚集

如果部分類完全隸屬于整體類,部分與整體共存,整體不存在了部分也會(huì)隨之消失,則該聚集稱為組合聚集。

9.4.2.3 泛化(I

(1普通泛化(2受限泛化

預(yù)定義的約束有4種:多重、不相交、完全和不完全。

9.4.2.4 依賴

9.4.2.5 細(xì)化

9.5動(dòng)態(tài)模型 9.6功能模型 9.6.1用例圖

模型元素:系統(tǒng)、行為者、用例及用例之間的關(guān)系(擴(kuò)展關(guān)系、使用關(guān)系用例的實(shí)例是腳本

第10章面向?qū)ο蠓治?10.1 面向?qū)ο蠓治龅幕具^程

面向?qū)ο蠓治?抽取和整理用戶需求并建立問題域精確模型的過程.理解----用戶、分析員和領(lǐng)域?qū)＜?/p>

表達(dá)----需求規(guī)格說明書(對象模型、動(dòng)態(tài)模型、功能模型

驗(yàn)證----二義性,完善性

對象模型最基本、最重要、最核心。靜態(tài)結(jié)構(gòu)(對象模型

3個(gè)子模型交互次序(動(dòng)態(tài)模型 數(shù)據(jù)變換(功能模型

復(fù)雜問題的對象模型的5個(gè)層次 面向?qū)ο蠓治龅倪^程 尋找類與對象 識別結(jié)構(gòu) 識別主題 定義屬性 建立動(dòng)態(tài)模型

建立功能模型 定義服務(wù) 10.2 需求陳述

需求陳述是闡明“做什么”,而不是“怎樣做” 問題范圍 功能需求 性能需求 應(yīng)用環(huán)境 假設(shè)條件

第11章面向?qū)ο笤O(shè)計(jì) 11.1 面向?qū)ο笤O(shè)計(jì)的準(zhǔn)則 1.模塊化 2.抽象 3.信息隱藏 4.弱耦合

耦合指不同對象之間相互關(guān)聯(lián)的緊密程度。對象之間的耦合分兩類: 交互耦合

如果對象之間的耦合通過消息連接來實(shí)現(xiàn),則這種耦合就是交互耦合。交互耦合應(yīng)盡可能松散。

繼承耦合

與交互耦合相反,應(yīng)該提高繼承耦合程度。5.強(qiáng)內(nèi)聚

在面向?qū)ο笤O(shè)計(jì)中存在下述3種內(nèi)聚: 服務(wù)內(nèi)聚:一個(gè)服務(wù)應(yīng)該完成一個(gè)且僅完成一個(gè)功能。

類內(nèi)聚:一個(gè)類應(yīng)該只有一個(gè)用途,它的屬性和服務(wù)應(yīng)該是高內(nèi)聚的。一般-特殊內(nèi)聚:設(shè)計(jì)出的一般-特殊結(jié)構(gòu),應(yīng)該符合多數(shù)人的概念 6.可重用 11.2 啟發(fā)規(guī)則

1.設(shè)計(jì)結(jié)果應(yīng)該清晰易懂 2.一般-特殊結(jié)構(gòu)的深度應(yīng)適當(dāng) 3.設(shè)計(jì)簡單的類 4.使用簡單的協(xié)議 5.使用簡單的服務(wù) 6.把設(shè)計(jì)變動(dòng)減至最小 第13章軟件項(xiàng)目管理 軟件工程計(jì)劃

控制度量軟件規(guī)模估算工作量進(jìn)度計(jì)劃 風(fēng)險(xiǎn)管理 質(zhì)量保證 配置管理

組織

明確軟件開發(fā)的目標(biāo)

提供組織機(jī)構(gòu)和資源配置方面的保證 保證開發(fā)目標(biāo)的實(shí)現(xiàn) 技術(shù)

管理

13.1估算軟件規(guī)模

13.1.1 代碼行技術(shù) 估算方法： 由多名有經(jīng)驗(yàn)的軟件工程師分別做出估計(jì)。每個(gè)人都估計(jì)程序的最小規(guī)模(a、最大規(guī)模(b和最可能的規(guī)模(m，分別算出這 3 種規(guī)模的平均值之后，再用下式計(jì)算程序規(guī)模的估計(jì)值： 單位： LOC 或 KLOC。代

碼行技術(shù)的優(yōu)點(diǎn)： 代碼是所有軟件開發(fā)項(xiàng)目都有的“產(chǎn)品”，而且很容易計(jì)算代碼行數(shù)； 有大量參考文獻(xiàn)和數(shù)據(jù)。代碼行技術(shù)的缺點(diǎn)： 源程序僅是軟件配置的一個(gè)成分，由源程序度量軟件規(guī)模不太合理； 用不同語言實(shí)現(xiàn)同一個(gè)軟件所需要的代碼行數(shù)并不相同； 不適用于非過程性語言。13.1.2 功能點(diǎn)技術(shù) 功能點(diǎn)技術(shù)依據(jù)對軟件信息域特性和軟件復(fù)雜性的評估結(jié)果，估算軟件規(guī)模。這種方法用功能點(diǎn)(FP為單位度量軟件規(guī)模。1.信息域特性 輸入項(xiàng)數(shù)(Inp、輸出項(xiàng)數(shù)(Out、查詢數(shù)(Inq、主文件數(shù)(Maf、外部接口數(shù)(Inf 每個(gè)特征根據(jù)其復(fù)雜程度分配一個(gè)功能點(diǎn)數(shù)，即信息域特征系數(shù) a1，a2，a3，a4，a5 2.估算功能點(diǎn)的步驟(1 計(jì)算未調(diào)整的功能點(diǎn)數(shù) UFP UFP=a1×Inp+a2×Out+a3×Inq+a4×Maf+a5×Inf(2 計(jì)算技術(shù)復(fù)雜性因子 TCF 技術(shù)因素對軟件規(guī)模的綜合影響程度 DI： 技術(shù)復(fù)雜性因子 TCF 由下式計(jì)算： TCF = 0.65 + 0.01 × DI 因?yàn)?DI 的值在 0~70 之間，所以 TCF 的值在 0.65~1.35 之間。(3 計(jì)算功能點(diǎn)數(shù) FP FP = UFP × TCF 功能點(diǎn)技術(shù)優(yōu)點(diǎn)：與所用的編程語言無關(guān)，比代碼行技術(shù)更合理。功能點(diǎn)技術(shù)缺點(diǎn)： 在判斷信息域特性復(fù)雜級別和技術(shù)因素的影響程度時(shí)主觀因素較大，對經(jīng) 驗(yàn)依賴性較強(qiáng)。13.2 工作量估算

13.2.1 靜態(tài)單變量模型 E ev 是估算變量（KLOC 或 FP）。13.2.2 動(dòng)態(tài)多變量模型

動(dòng)態(tài)多變量模型也稱為軟件方程式，該模型把工作量看作是軟件規(guī)模和開發(fā)時(shí)間這兩個(gè)變量 的函數(shù)。E=(LOC×B0.333/P3×(1/t4 13.2.3 COCOMO2 模型（構(gòu)造性成本模型）3 個(gè)層次的估算模型： 應(yīng)用系統(tǒng)組成模型： 這個(gè)模型主要用于估算構(gòu)建原型的工作量，模型名字暗示在構(gòu)建原型時(shí) 大量使用已有的構(gòu)件。早期設(shè)計(jì)模型：這個(gè)模型適用于體系結(jié)構(gòu)設(shè)計(jì)階段。后體系結(jié)構(gòu)模型：這個(gè)模型適用于完成體系結(jié)構(gòu)設(shè)計(jì)之后的軟件開發(fā)階段。COCOMO2 使用的 5 個(gè)分級因素：項(xiàng)目先例性、開發(fā)靈活性、風(fēng)險(xiǎn)排除度、項(xiàng)目組凝聚力、過 程成熟度 13.3 進(jìn)度計(jì)劃 13.3.1 估算開發(fā)時(shí)間 Brooks 規(guī)律：向一個(gè)已經(jīng)延期的項(xiàng)目增加人力，只會(huì)使得它更加延期。13.3.2 Gantt 圖 Gantt 圖的主要優(yōu)點(diǎn)： Gantt 圖能很形象地描繪任務(wù)分解情況，以及每個(gè)子任務(wù)(作業(yè)的開始和結(jié)束時(shí)間。具有直觀簡明和容易掌握、容易繪制的優(yōu)點(diǎn)。Gantt 圖的 3 個(gè)主要缺點(diǎn)： 不能顯式地描繪各項(xiàng)作業(yè)彼此間的依賴關(guān)系； 進(jìn)度計(jì)劃的關(guān)鍵部分不明確，難于判定哪些部分應(yīng)當(dāng)是主攻和主控的對象； 計(jì)劃中有潛力的部分及潛力的

大小不明確，往往造成潛力的浪費(fèi)。13.3.3 工程網(wǎng)絡(luò) 工程網(wǎng)絡(luò)是系統(tǒng)分析和系統(tǒng)設(shè)計(jì)的強(qiáng)有力的工具。13.3.4 估算工程進(jìn)度 計(jì)算最早時(shí)刻 EET 使用下述 3 條簡單規(guī)則： 考慮進(jìn)入該事件的所有作業(yè)； 對于每個(gè)作業(yè)都計(jì)算它的持續(xù)時(shí)間與起始事件的 EET 之和； 選取上述和數(shù)中的最大值作為該事件的最早時(shí)刻 EET。計(jì)算最遲時(shí)刻 LET 使用下述 3 條規(guī)則：

考慮離開該事件的所有作業(yè)； 從每個(gè)作業(yè)的結(jié)束事件的最遲時(shí)刻中減去該作業(yè)的持續(xù)時(shí)間； 選取上述差數(shù)中的最小值作為該事件的最遲時(shí)刻 LET。13.3.5 關(guān)鍵路徑 關(guān)鍵事件：EET=LET 13.3.5 機(jī)動(dòng)時(shí)間=(LET結(jié)束－(EET開始－持續(xù)時(shí)間 =右下角－左上角－持續(xù)時(shí)間 13.4 人員組織 13.4.1 民主制程序員組 如果小組內(nèi)有 n 個(gè)成員，則可能的通信信道共有 n(n-1/2 條。13.4.2 主程序員組 主程序員組的兩個(gè)重要特性：專業(yè)化、層次性 13.4.3 現(xiàn)代程序員組 13.5 質(zhì)量保證 13.5.1 軟件質(zhì)量 13.5.2 軟件質(zhì)量保證措施 13.6 軟件配置管理 基于非執(zhí)行的測試（復(fù)審或評審），主要用來保證在編碼之前各階段產(chǎn)生的文檔的質(zhì)量； 基于執(zhí)行的測試（軟件測試），需要在程序編寫出來之后進(jìn)行，它是保證軟件質(zhì)量的最后一 道防線； 程序正確性證明，使用數(shù)學(xué)方法嚴(yán)格驗(yàn)證程序是否與對它的說明完全一致。1.技術(shù)復(fù)審的必要性 2.走查:參與者驅(qū)動(dòng)法、文檔驅(qū)動(dòng)法 3.審查：綜述 準(zhǔn)備 審查 返工 跟蹤 4.程序正確性證明 軟件配置管理是在軟件的整個(gè)生命期內(nèi)管理變化的一組活動(dòng)。具體地說，這組活動(dòng)用來：①標(biāo)識變化；②控制變化；③確保適當(dāng)?shù)貙?shí)現(xiàn)了變化；④向需要 知道這類信息的人報(bào)告變化。軟件配置管理的目標(biāo)： 使變化更正確且更容易被適應(yīng)，在必須變化時(shí)減少所需花費(fèi)的工作量。

13.6.1 軟件配置 1.軟件過程的輸出信息（軟件配置項(xiàng)）： 計(jì)算機(jī)程序（源代碼和可執(zhí)行程序）； 描述計(jì)算機(jī)程序的文檔（供技術(shù)人員或用戶使用）； 數(shù)據(jù)（程序內(nèi)包含的或在程序外的）2.基線 基線就是通過了正式復(fù)審的軟件配置項(xiàng)。13.6.2 軟件配置管理過程 軟件配置管理主要有 5 項(xiàng)任務(wù)： 1.標(biāo)識軟件配置中的對象：基本對象、聚集對象 2.版本控制 3.變化控制 4.配置審計(jì) 5.狀態(tài)報(bào)告 13.7 能力成熟度模型 1.初始級 軟件過程的特征是無序的，有時(shí)甚至是混亂的。2.可重復(fù)級 軟件機(jī)構(gòu)建立了基本的項(xiàng)目管理過程(過程模型，可跟蹤成本、進(jìn)度、功能和質(zhì)

量。3.已定義級 軟件機(jī)構(gòu)已經(jīng)定義了完整的軟件過程（過程模型），軟件過程已經(jīng)文檔化和標(biāo)準(zhǔn)化。4.已管理級 軟件機(jī)構(gòu)對軟件過程（過程模型和過程實(shí)例）和軟件產(chǎn)品都建立了定量的質(zhì)量目標(biāo)，所有項(xiàng) 目的重要的過程活動(dòng)都是可度量的。5.優(yōu)化級 軟件機(jī)構(gòu)集中精力持續(xù)不斷地改進(jìn)軟件過程。這一級的軟件機(jī)構(gòu)是一個(gè)以防止出現(xiàn)缺陷為目 標(biāo)的機(jī)構(gòu)，它有能力識別軟件過程要素的薄弱環(huán)節(jié)，并有足夠的手段改進(jìn)它們。

第二篇：軟件工程導(dǎo)論復(fù)習(xí)整理(最新)

第一章

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

2.軟件與硬件的區(qū)別：軟件不同于硬件，它是計(jì)算機(jī)系統(tǒng)中的邏輯部件而不是物理部件。

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

4.軟件工程是指導(dǎo)計(jì)算機(jī)軟件開發(fā)和維護(hù)的一門工程學(xué)科，采用工程的概念、原理、技術(shù)和方法來開發(fā)與維護(hù)軟件，把經(jīng)過時(shí)間考驗(yàn)而證明正確的管理技術(shù)和當(dāng)前能夠得到最好的技術(shù)方法結(jié)合起來，以經(jīng)濟(jì)地開發(fā)出高質(zhì)量的軟件并有校地維護(hù)它。

5.軟件工程方法學(xué)三要素：方法、工具和過程。

6.傳統(tǒng)方法學(xué)也稱為生命周期方法學(xué)或結(jié)構(gòu)化范型。它采用結(jié)構(gòu)化技術(shù)來完成軟件開發(fā)的各項(xiàng)任務(wù)，并使用適當(dāng)?shù)能浖ぞ呋蜍浖こ汰h(huán)境來支持結(jié)構(gòu)化技術(shù)的運(yùn)用。

7.面向?qū)ο蠓椒▽W(xué)把數(shù)據(jù)和行為看成同等重要的，它是一種以數(shù)據(jù)為主線，把數(shù)據(jù)和對數(shù)據(jù)的操作緊密地結(jié)合起來的方法。

8.軟件生命周期劃分為三個(gè)時(shí)期:1軟件定義（問題定義、可行性研究、需求分析），2軟件開發(fā)（總體設(shè)計(jì)、詳細(xì)設(shè)計(jì)、編碼和單元測試、綜合測試），3運(yùn)行維護(hù)（軟件維護(hù)）。

9.4類軟件維護(hù)活動(dòng)：改正性維護(hù)，也就是診斷和改正在使用過程中發(fā)現(xiàn)的軟件錯(cuò)誤；適應(yīng)性維護(hù)，即修改軟件以適應(yīng)環(huán)境的變化；完善性維護(hù)，即根據(jù)用戶的要求改進(jìn)或擴(kuò)充軟件使它更完善；預(yù)防性維護(hù)，即修改軟件，為將來的維護(hù)活動(dòng)預(yù)先做準(zhǔn)備。

10.“瀑布模型”的缺點(diǎn)：它是由文檔驅(qū)動(dòng)的，僅僅通過寫在紙上的靜態(tài)的規(guī)格說明，很難全面正確地認(rèn)識動(dòng)態(tài)的軟件產(chǎn)品；瀑布模型幾乎完全依賴于書面的規(guī)格說明，很可能導(dǎo)致最終開發(fā)出的產(chǎn)品不能真正的滿足用戶的需要。

11.快速原型模型的優(yōu)點(diǎn)：原型系統(tǒng)已經(jīng)通過與用戶交互而得到驗(yàn)證，據(jù)此產(chǎn)生的規(guī)格說明文檔正確地描述了用戶需求；開發(fā)人員通過建立原型系統(tǒng)已經(jīng)學(xué)到了很多東西，因此，在設(shè)計(jì)和編碼階段發(fā)生錯(cuò)誤的可能性也比較小，這自然減少了在后續(xù)階段需要改正前面階段所犯錯(cuò)誤的可能性。

第二章 1.可行性研究的三個(gè)方面：技術(shù)可行性:使用現(xiàn)有的技術(shù)能實(shí)現(xiàn)這個(gè)系統(tǒng)經(jīng)濟(jì)可行性:這個(gè)系統(tǒng)的經(jīng)濟(jì)效益能超過它的開發(fā)成本操作可行性:系統(tǒng)的操作方式在這個(gè)用戶組織內(nèi)行得通

2.數(shù)據(jù)流圖的4個(gè)基本符號及畫法P41

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

4.符號含義：＝表示“等價(jià)于”或“定義為”；＋表示連接；[ ]表示“或”，用“|”分隔；{ }表示“重復(fù)”，()表示“可選”用“，”號隔開；1｛A}5 表示上限和下限。

5.高校電話號碼數(shù)據(jù)的定義P54

第三章

1.需求分析3種模型：數(shù)據(jù)模型：實(shí)體-聯(lián)系圖，描繪數(shù)據(jù)對象及數(shù)據(jù)對象之間的關(guān)系；功能模型：數(shù)據(jù)流圖，描繪當(dāng)數(shù)據(jù)在軟件系統(tǒng)中移動(dòng)時(shí)被變換的邏輯過程；行為模型：狀態(tài)轉(zhuǎn)換圖，指明了作為外部事件結(jié)果的系統(tǒng)行為，描繪了系統(tǒng)的各種行為模式。

2.ER圖3種基本成分：實(shí)體（數(shù)據(jù)對象），關(guān)系，屬性。P64

3.軟件需求驗(yàn)證的四個(gè)方面：一致性，完整性，現(xiàn)實(shí)性，有效性。

第四章

1.總體設(shè)計(jì)2個(gè)主要階段：系統(tǒng)設(shè)計(jì)階段，確定系統(tǒng)的具體實(shí)現(xiàn)方案；結(jié)構(gòu)設(shè)計(jì)階段，確定軟件結(jié)構(gòu)。

2.信息隱藏：設(shè)計(jì)和確定模塊，使得一個(gè)模塊內(nèi)包含的特定信息，對于不需要這些信息的模塊來說，是不能訪問的。

3.模塊獨(dú)立2個(gè)度量標(biāo)準(zhǔn)：內(nèi)聚和耦合。耦合衡量不同模塊彼此間互相依賴（連接）的緊密程度；內(nèi)聚衡量一個(gè)模塊內(nèi)部各個(gè)元素彼此結(jié)合的緊密程度。4.耦合與內(nèi)聚判定P98-99

5.深度：表示軟件結(jié)構(gòu)中控制的層數(shù)，它往往粗略的標(biāo)志一個(gè)系統(tǒng)的大小和復(fù)雜程度，深度和程序長度之間應(yīng)該有粗略的對應(yīng)關(guān)系；寬度：是軟件結(jié)構(gòu)內(nèi)同一層次上的模塊總數(shù)的最大值；扇出：是一個(gè)模塊直接控制（調(diào)用）的模塊數(shù)目；扇入：表明一個(gè)模塊有多少上級模塊直接調(diào)用它

6.P100 模塊的作用域和模塊的控制域之間的關(guān)系：模塊的作用域定義為受該模塊內(nèi)一個(gè)判定影響的所有模塊的集合；模塊的控制域是這個(gè)模塊本身以及所有直接或間接從屬于它的模塊的集合；模塊的作用域應(yīng)該在控制域之內(nèi)（在設(shè)計(jì)的很好的系統(tǒng)中，所有受判定影響的模塊應(yīng)該都從屬于做出判定的那個(gè)模塊，最好局限于做出判定的那個(gè)模塊本身以及它的直屬下級模塊）。

6.層次圖，結(jié)構(gòu)圖P10

2第六章

1.結(jié)構(gòu)程序設(shè)計(jì)定義：如果一個(gè)程序的代碼塊僅僅通過順序、選擇和循環(huán)這3種基本控制結(jié)構(gòu)進(jìn)行連接，并且每一個(gè)代碼塊只有一個(gè)入口和一個(gè)出口，則稱這個(gè)程序是結(jié)構(gòu)化的。

2.P124 過程設(shè)計(jì)的工具：程序流程圖、盒圖、PAD圖、判定表、判定樹、過程設(shè)計(jì)語言。

3.畫出偽碼程序的程序流程圖和盒圖 P1

41第七章

1.軟件測試在軟件生命周期中橫跨兩個(gè)階段：單元測試：模塊的編寫者和測試者是同一個(gè)人，編碼和單元測試屬于軟件生命周期的同一個(gè)階段；綜合測試：由專門的測試人員承擔(dān)這項(xiàng)工作。

2.為什么軟件測試不能由程序的編寫人員來做？

(1)測試是為了發(fā)現(xiàn)程序中的錯(cuò)誤而執(zhí)行程序的過程。

(2)正確認(rèn)識測試的目標(biāo)是十分重要的，測試目標(biāo)決定了測試力案的設(shè)計(jì)。如果為了表明程序是正確的而進(jìn)行測試，就會(huì)設(shè)計(jì)一些不易暴露錯(cuò)誤的測試方案；相反，如果測試是為了發(fā)現(xiàn)程序中的錯(cuò)誤，就會(huì)力求設(shè)計(jì)出最能暴露錯(cuò)誤的測試方案。

(3)由于測試的目標(biāo)是暴露程序中的錯(cuò)誤，從心理學(xué)角度看，由程序的編寫者自己進(jìn)行測試是不恰當(dāng)?shù)摹?/p>

3.測試方法：(1)黑盒測試 ：把程序看作一個(gè)黑盒子，完全不考慮程序的內(nèi)部結(jié)構(gòu)和處理過程 ；對程序接口進(jìn)行測試，檢查程序功能是否能按規(guī)格說明書的規(guī)定正常使用； 程序是否能適當(dāng)?shù)亟邮茌斎霐?shù)據(jù)并產(chǎn)生正確的輸出信息； 程序運(yùn)行過程中能否保持外部信息的完整性

(2)白盒測試 ：把程序堪稱裝在一個(gè)透明的白盒子里，測試者完全知道程序的結(jié)構(gòu)處理算法 ；按照程序內(nèi)部的邏輯測試程序，檢測程序中的主要執(zhí)行通路是否都能按 預(yù)定要求正確工作。

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

5.集成測試是測試和組裝軟件的系統(tǒng)化技術(shù)，即是在把模塊按照設(shè)計(jì)要求組裝起來的同時(shí)進(jìn)行測試，由模塊組裝成程序時(shí)兩種方法：非漸增式測試方法和漸增式測試方法。

6.P162 邏輯覆蓋標(biāo)準(zhǔn)：語句覆蓋，判定覆蓋，條件覆蓋，判定條件覆蓋，條件組合覆蓋，（還有點(diǎn)覆蓋，邊覆蓋，路徑覆蓋）。

7.設(shè)計(jì)測試用例：P16

2第八章

1.軟件維護(hù)：在軟件已經(jīng)交付使用之后，為了改正錯(cuò)誤或者滿足新的需要而修改軟件的過程。

2.維護(hù)工作量的一個(gè)模型： M = P + K × exp(c-d)其中： M是維護(hù)用的總工作量，P是生產(chǎn)性工作量，K是經(jīng)驗(yàn)常數(shù)，c是復(fù)雜程度d是維護(hù)人員對軟件的熟悉程度。exp，以自然對數(shù)e為底指數(shù)函數(shù)，Exponential(指數(shù)曲線)。

3.軟件可維護(hù)性與哪些因素有關(guān)？在軟件開發(fā)過程中應(yīng)該采取哪些措施來提高軟件產(chǎn)品可維護(hù)性？

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

軟件生命周期每個(gè)階段的工作都和軟件可維護(hù)性有密切關(guān)系。良好的設(shè)計(jì)，完整準(zhǔn)確易讀易理解的文檔資料，以及一系列嚴(yán)格的復(fù)審和測試，使得一旦發(fā)現(xiàn)錯(cuò)誤時(shí)比較容易診斷和糾正，當(dāng)用戶有新要求或外部環(huán)境變化時(shí)軟件能較容易地適應(yīng)，并且能夠減少維護(hù)引入的錯(cuò)誤。因此，在軟件生命周期的每個(gè)階段都必須充分考慮維護(hù)問題，并且為軟件維護(hù)預(yù)做準(zhǔn)備。

第九章

1.面向?qū)ο蟮母拍睿簩ο?，類，?shí)例，消息，方法，屬性，封裝，繼承，多態(tài)性P209-215 對象：是封裝了數(shù)據(jù)結(jié)構(gòu)及可以施加在這些數(shù)據(jù)結(jié)構(gòu)上的操作的封裝體（類的實(shí)例）類：是對具有相同屬性和行為的一個(gè)或多個(gè)對象的描述（支持繼承的抽象數(shù)據(jù)類型）實(shí)例：是由某個(gè)特定的類所描述的一個(gè)具體的對象

消息:就是要求某個(gè)對象執(zhí)行在定義它的那個(gè)類中所定義的某個(gè)操作的規(guī)格說明。由3部分組成：接收消息的對象，消息選擇符，零個(gè)或多個(gè)變元

方法：是對象所能執(zhí)行的操作，描述了對象執(zhí)行操作的算法，響應(yīng)消息的方法

屬性：類中所定義的數(shù)據(jù)，對客觀世界實(shí)體所具有的性質(zhì)的抽象

封?。壕褪切畔㈦[藏，通過封裝對外界隱藏了對象的實(shí)現(xiàn)細(xì)節(jié)

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

多態(tài)性：指子類對象可以像父類對象那樣使用，同樣的消息既可以發(fā)送給父類對象也可以發(fā)送給子類對象

2.面向?qū)ο蠼＃好枋鱿到y(tǒng)數(shù)據(jù)結(jié)構(gòu)的對象模型，描述系統(tǒng)控制結(jié)構(gòu)的動(dòng)態(tài)模型，描述系統(tǒng)功能的功能模型。類名

3.對象模型：P217 屬性類圖符號：服務(wù)

4.表示關(guān)系的符號：類與類之間通常有關(guān)聯(lián)、泛化(繼承)、依賴和細(xì)化等4種關(guān)系關(guān)聯(lián)：表示倆個(gè)類的對象之間存在某種語義上的聯(lián)系

泛化：是通用元素和具體元素之間的一種分類關(guān)系

依賴：描述倆個(gè)模型元素（類，用例等）之間的語義連接關(guān)系

細(xì)化：用來協(xié)調(diào)不同階段模型之間的關(guān)系，表示各個(gè)開發(fā)階段不同抽象層次的模型之間的相關(guān)性，常常用于跟蹤模型的演變。

5.功能模型：用例圖包含的模型元素有系統(tǒng)、行為者、用例及用例之間的關(guān)系P224

第十章

1.面向?qū)ο蠓治?，就是抽取和整理用戶需求并建立問題域精確模型的過程

2.建立對象模型、動(dòng)態(tài)模型、功能模型的基本方法P235-255

第三篇：軟件工程導(dǎo)論復(fù)習(xí)材料

1.軟件工程基本概念

1.（）因素促使計(jì)算機(jī)系統(tǒng)越來越復(fù)雜。

A.計(jì)算機(jī)內(nèi)存和存儲(chǔ)容量上的巨大增長

B.外部輸入／輸出選項(xiàng)的更加多樣性

C.計(jì)算機(jī)體系結(jié)構(gòu)方面的深刻變化

D.以上所有選項(xiàng)

2.下面的（）不再是現(xiàn)代軟件工程師關(guān)注的問題。

A.為什么不能在產(chǎn)品發(fā)布前去除軟件錯(cuò)誤？

B.為什么軟件需要很長時(shí)間才能完成？

C.為什么開發(fā)一個(gè)軟件的成本這么高？

D.為什么計(jì)算機(jī)硬件的成本這么高？

3.軟件會(huì)逐漸退化而不會(huì)磨損，其原因在于（）。

A.軟件備件很難訂購

B.軟件錯(cuò)誤通常發(fā)生在使用之后

C.通常暴露在惡劣的環(huán)境下

D.不斷的變更使組件接口之間引起錯(cuò)誤軟件

4.大多數(shù)軟件仍然是定制開發(fā)的，其原因在于（）。

A.軟件組件重用是十分普遍的 B.可重用的組件太昂貴而無法使用

C.軟件在不使用其他組件的情況下很容易構(gòu)造出來

D.商業(yè)組件在很多應(yīng)用領(lǐng)域中可以得到

5.下面的（）說法是正確的。

A.軟件危機(jī)在20世紀(jì)70年代末期全面爆發(fā)

B.當(dāng)前先進(jìn)的軟件工程方法已經(jīng)解決了軟件危機(jī)的問題

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

D.軟件危機(jī)是指在軟件產(chǎn)品中存在一系列的質(zhì)量問題 1.瀑布模型本質(zhì)上是一種（）。

A、線性迭代模型

B、順序迭代模型C、線性順序模型

D、及早見產(chǎn)品模型 2.（）是用戶和設(shè)計(jì)交換最頻繁的方法。

A、原型化方法

B、瀑布模型方法C、螺旋模型方法

D、構(gòu)件組裝模型 5.在軟件開發(fā)模型中，提出最早、應(yīng)用最廣泛的模型是（）A.瀑布模型

B.噴泉模型

C.增量模型

D.螺旋模型

1.軟件工程的方法只適用于大型軟件的開發(fā)，對小型軟件的開發(fā)沒有幫助。（）1.什么是軟件危機(jī)？其主要表現(xiàn)有那些？

1.有人認(rèn)為?軟件工程過于耗費(fèi)時(shí)間，并且妨礙開發(fā)人員的編程效率。?你是否認(rèn)同這種觀點(diǎn)？請闡述理由。

2.需求分析 需求規(guī)格說明描述了（）。

A.計(jì)算機(jī)系統(tǒng)的功能、性能及其約束

B.每個(gè)指定系統(tǒng)的實(shí)現(xiàn)

C.軟件體系結(jié)構(gòu)的元素

D.系統(tǒng)仿真所需要的時(shí)間

7．軟件可行性研究實(shí)質(zhì)上是要進(jìn)行一次（）需求分析、設(shè)計(jì)過程。A.簡化、壓縮的B.詳細(xì)的 C.徹底的D.深入的 11.下面說法不正確的是（）。

A.流程圖不易表示數(shù)據(jù)結(jié)構(gòu)

B.流程圖容易造成非結(jié)構(gòu)化的程序結(jié)構(gòu)

C.流程圖支持逐步求精

D.流程圖描述的是程序的邏輯結(jié)構(gòu) 1.需求分析中開發(fā)人員要從用戶那里了解（）。

A、軟件做什么B、用戶使用界面C、輸入的信息D、軟件的規(guī)模

2.需求分析階段，分析人員要確定對問題的綜合需求，其中最主要的是（）需求。A、功能 B、性能 C、數(shù)據(jù) D、環(huán)境 24.軟件可行性研究一般不考慮（）

A.是否有足夠的人員和相關(guān)的技術(shù)來支持系統(tǒng)開發(fā) B.是否有足夠的工具和相關(guān)的技術(shù)來支持系統(tǒng)開發(fā) C.待開發(fā)軟件是否有市場、經(jīng)濟(jì)上是否合算 D.待開發(fā)的軟件是否會(huì)有質(zhì)量問題 25.需求規(guī)格說明描述了（）

A.計(jì)算機(jī)系統(tǒng)的功能、性能及其約束 B.每個(gè)指定系統(tǒng)的實(shí)現(xiàn) C.軟件體系結(jié)構(gòu)的元素

D.系統(tǒng)仿真所需要的時(shí)間

26.需求分析階段，分析人員要確定對問題的綜合需求，其中最主要的是（）需求 A.功能

B.性能

C.數(shù)據(jù)

D.環(huán)境

7.成本效益分析的目的是從

角度評價(jià)開發(fā)一個(gè)項(xiàng)目是否可行。

2.軟件需求規(guī)格說明書在軟件開發(fā)過程中具有重要的作用，它是軟件可行性分析的依據(jù)。3.（）目前存在一個(gè)很普遍的現(xiàn)象，即不同的客戶提出的需求是相互矛盾的，但每個(gè)人都爭辯自己是正確的。

5.（）在需求分析過程中，分析員要從用戶那里解決的最重要的問題是明確軟件做什么。2.可行性研究主要確定問題分析階段所確定的問題是否有可行的解。（）6.在需求分析過程中，分析員要解決的最重要的問題是明確軟件做什么。（）7.數(shù)據(jù)流圖的畫法？

3.軟件設(shè)計(jì)與編碼.概要設(shè)計(jì)階段產(chǎn)生的文檔不包括（）。A.概要設(shè)計(jì)說明書

B.數(shù)據(jù)庫設(shè)計(jì)說明書 C.用戶手冊

D.開發(fā)進(jìn)度月報(bào).一個(gè)模塊把數(shù)值作為參數(shù)傳送給另一個(gè)模塊，這種耦合方式稱為（）。A.數(shù)據(jù)耦合 B.公共耦合 C.控制耦合 D.標(biāo)記耦合

10．與詳細(xì)設(shè)計(jì)相對應(yīng)的是數(shù)據(jù)庫的（）設(shè)計(jì)。A.概念

B.邏輯 C.物理

D.功能 19.序言性注釋主要內(nèi)容不包括（）。

A.模塊的接口

B.數(shù)據(jù)的描述

C.模塊的功能

D.數(shù)據(jù)的狀態(tài) 11.模塊化的目的是：（）

A、增加內(nèi)聚性 B、降低復(fù)雜性C、提高易讀性D、減少耦合性 12.軟件設(shè)計(jì)中劃分模塊的一個(gè)準(zhǔn)則是（）。

A、低內(nèi)聚低耦合B、低內(nèi)聚高耦合C、高內(nèi)聚低耦合D、高內(nèi)聚高耦合 13.下列耦合中，耦合程度最高的是：（）A、標(biāo)記耦合 B、控制耦合 C、內(nèi)容耦合 D、公共耦合 14.模塊間耦合程度越高，說明模塊之間彼此依賴的程度越（）。A、松散 B、緊密 C、無法判斷 D、相等 15.程序的三種基本控制結(jié)構(gòu)是（）。A、過程、子程序和分程序。B、順序、選擇和重復(fù)。C、遞歸、堆棧和隊(duì)列。D、調(diào)用、返回和轉(zhuǎn)移。

2.軟件設(shè)計(jì)階段一般分為

和

兩個(gè)階段。

3.軟件開發(fā)過程中，模塊化開發(fā)追求的目標(biāo)是：__________________。6.數(shù)據(jù)建模常用的模型是______________。任何程序都可由

、和

3種基本控制結(jié)構(gòu)構(gòu)造。這3種基本結(jié)構(gòu)的共同點(diǎn)是

、。

4.軟件人員的數(shù)量與軟件開發(fā)進(jìn)度成正比。（）

8.模塊化程序設(shè)計(jì)中，模塊越小，模塊化的優(yōu)點(diǎn)越明顯。一般來說，模塊的大小都在10行以下。（）

9.模塊化，信息隱藏，抽象和逐步求精的軟件設(shè)計(jì)原則有助于得到高內(nèi)聚，低耦合度的軟件產(chǎn)品。（）

10.程序設(shè)計(jì)風(fēng)格指導(dǎo)原則提出，盡量多使用臨時(shí)變量。（）8.模塊化程序設(shè)計(jì)中，模塊越小，模塊化的優(yōu)點(diǎn)越明顯。（）

4.軟件測試

13．（）方法需要考察模塊間的接口和各模塊之間的聯(lián)系。A.單元測試

B.集成測試 C.確認(rèn)測試

D.系統(tǒng)測試

16．在軟件生存周期中，時(shí)間最長、所花費(fèi)的精力和費(fèi)用也最多的階段是（）。A.詳細(xì)設(shè)計(jì)

B.維護(hù) C.概要設(shè)計(jì)

D.測試 16.軟件測試的目的是？（）A、證明軟件的正確性

B、找出軟件系統(tǒng)中存在的所有錯(cuò)誤 C、證明軟件系統(tǒng)中存在錯(cuò)誤

D、盡可能多的發(fā)現(xiàn)軟件系統(tǒng)中的錯(cuò)誤

17.（）是以提高軟件質(zhì)量為目的的技術(shù)活動(dòng)。A．技術(shù)創(chuàng)新

B．測試

C．技術(shù)創(chuàng)造

D．技術(shù)評審

18.軟件維護(hù)工作的最主要部分是（）。A、校正性維護(hù) B、適應(yīng)性維護(hù) C、完善性維護(hù) D、預(yù)防性維護(hù)

19.檢查軟件產(chǎn)品是否符合需求定義的過程稱為（）。A、確認(rèn)測試 B、集成測試 C、驗(yàn)收測試 D、系統(tǒng)測試

20.軟件維護(hù)的副作用，是指（）。A、開發(fā)時(shí)的錯(cuò)誤 B、隱含的錯(cuò)誤

C、因修改軟件而造成的錯(cuò)誤 D、運(yùn)行時(shí)誤操作

33.發(fā)現(xiàn)錯(cuò)誤能力最弱的是（）A.語句覆蓋

B.判定覆蓋

C.條件覆蓋

D.路徑覆蓋 34.（）方法需要考察模塊間的接口和各模塊之間的聯(lián)系 A.單元測試

B.集成測試

C.確認(rèn)測試

D.系統(tǒng)測試 1.軟件測試主要可分為________和________兩種類型。

4.軟件維護(hù)可分為四類，它們是改正性維護(hù)，________，________ 和________。8.軟件可維護(hù)性的因素是可理解性、可測試性、可修改性、可移植性和_____。

9． 軟件質(zhì)量保證應(yīng)從________開始，直到投入使用和售后服務(wù)的軟件生存期的每一階段中 4 的每一步驟。

3.為了加快軟件維護(hù)作業(yè)的進(jìn)度，應(yīng)盡可能增加維護(hù)人員的數(shù)目。（）

5.質(zhì)量保證是為了保證產(chǎn)品和服務(wù)充分滿足消費(fèi)者要求的質(zhì)量而進(jìn)行的有計(jì)劃,有組織的活動(dòng)。（）

6.判定覆蓋不一定包含條件覆蓋，條件覆蓋也不一定包含判定覆蓋。（）7.測試只能證明程序有錯(cuò)誤,不能證明程序沒有錯(cuò)誤。（）3.軟件維護(hù)就是改正軟件中的錯(cuò)誤。（）

10.用黑盒法測試時(shí)，測試用例是根據(jù)程序內(nèi)部邏輯設(shè)計(jì)的。（11.基本路徑測試的分析方法？）5

5.面向?qū)ο蟮能浖こ蹋║ML）..（）意味著一個(gè)操作在不同的類中可以有不同的實(shí)現(xiàn)方式。

A.消息

B.多繼承

C.多態(tài)性

D.封裝.順序圖反映對象之間發(fā)送消息的時(shí)間順序，它與（）是同構(gòu)的。A.用例圖

B.類圖

C.協(xié)作圖

D.狀態(tài)圖

28.在軟件工程學(xué)中，我們把一組具有相同數(shù)據(jù)結(jié)構(gòu)和操作的對象的集合定義為（）A.類

B.屬性

C.對象

D.消息

29.順序圖反映對象之間發(fā)送消息的時(shí)間順序，它與（）是同構(gòu)的 A.用例圖

B.類圖

C.協(xié)作圖

D.狀態(tài)圖 35.下列關(guān)于UML敘述不正確的是（）A、UML是一種高級編程語言，且是可視化的B、UML是一種文檔化語言 C、UML是一種可用于詳細(xì)描述的語言

D、UML是一種構(gòu)造語言

36.表示一種一般事物（父類）和特殊事物（子類）之間的關(guān)系是（）A、依賴

B、關(guān)聯(lián)

C、泛化

D、實(shí)現(xiàn) 1.（）用例參與者總是人員而不是系統(tǒng)設(shè)備。

6.（）面向?qū)ο笤O(shè)計(jì)是在分析模型的基礎(chǔ)上，運(yùn)用面向?qū)ο蠹夹g(shù)生成軟件實(shí)現(xiàn)環(huán)境下的設(shè)計(jì)模型。

8.（）關(guān)系數(shù)據(jù)庫可以完全支持面向?qū)ο蟮母拍睿嫦驅(qū)ο笤O(shè)計(jì)中的類可以直接對應(yīng)到關(guān)系數(shù)據(jù)庫中的表。

9.UML用例圖的畫法？

6.項(xiàng)目管理

38.CMMI體系中，第三級是（）A、已管理級

B、已量化管理級 C、已定義級

D、持續(xù)優(yōu)化級 5.軟件配置管理中，基線是___________________________________。4.（）軟件工作產(chǎn)品一旦成為基線就不能再更改了。4.什么是軟件配置管理？主要目標(biāo)和手段是什么？ 4.什么是基線？

第四篇：軟件工程復(fù)習(xí)重點(diǎn)總結(jié)

第一章

軟件過程：需求設(shè)計(jì)實(shí)現(xiàn)發(fā)布

軟件過程三要素: 過程+方法+工具

瀑布rup scrum Iconix

Scrum是一種迭代式增量軟件開發(fā)過程，通常用于敏捷軟件開發(fā)。Product Owner、Scrum Master、Team Product Backlog、SprintBacklog、Burndown Chart、Sprint、Sprint Planning Meeting、Daily Standup Meeting、Review Meeting、Retrospective Meeting ICONIX軟件開發(fā)過程

愿景、業(yè)務(wù)建模、需求分析、健壯性分析、系統(tǒng)設(shè)計(jì)??

思想是重點(diǎn)；過程是方式；方法和工具是載體

第二章

敏捷開發(fā)是一種以人為核心、迭代、循序漸進(jìn)的開發(fā)方法。敏

捷是一種思想?Scrum是一個(gè)框架

敏捷開發(fā)過程知多少？

?Scrum、?極限編程（XP）、?Crystal Methods（水晶方法族）

?特性驅(qū)動(dòng)開發(fā)（FDD）

?動(dòng)態(tài)系統(tǒng)開發(fā)（DSDM）

?輕量型統(tǒng)一過程（RUP）

調(diào)查結(jié)果：敏捷開發(fā)方法—Scrum最流行！

Scrum的適用場景

?7人，+or-2

?偏小一些會(huì)更適合?最好能坐在一起

?客戶參不度高

?快速移動(dòng)互聯(lián)網(wǎng)項(xiàng)目

?自主性研發(fā)的產(chǎn)品

第三章

軟件項(xiàng)目是為了改善某個(gè)組織的某些方面

–老大就是要改善的組織中最有權(quán)力的干系人。

用戶建模四步曲列出盡可能多的用戶識別關(guān)鍵用戶（購買決策者/主要使用者）分類，合并次要用戶

4添加虛擬和極端用戶

第四章

?產(chǎn)品backlog是Scrum的核心

產(chǎn)品功能列表格式

?ID（標(biāo)示符）

–統(tǒng)一標(biāo)識符

?Name（標(biāo)題）

–簡短的、描述性的故事名

?Story（故事）

–故事內(nèi)容描述

?Priority（重要性）

–產(chǎn)品負(fù)責(zé)人評出一個(gè)數(shù)值，指示這個(gè)故事有多重要

?Initial estimate（初始估計(jì)）

–團(tuán)隊(duì)的初步估算，表示不其他故事相比，完成該故事所需的工作量

?How to demo（如何做演示）

–它大略描述了這個(gè)故事應(yīng)該如何在sprint 演示上進(jìn)行示范

?Notes（注解）

–相關(guān)信息、解釋說明和對其它資料的引用等等

產(chǎn)品功能列表由誰來寫？

?思考：由誰來寫？

–主要是Product Owner

–Team也有權(quán)利，但最終由PO進(jìn)行取舍。

用戶故事是一種敏捷的需求挖掘方式，其側(cè)重點(diǎn)不是將需求書寫出來，而是將需求討論出來。

按“作為一個(gè)??，可以??，以便??”樣式和思路寫成的用戶需求，就是用戶故事。

用戶故事的三個(gè)變量

范圍，重要性，估算

好故事的準(zhǔn)則

?獨(dú)立的（Independ）

?可討論的（Negotiable）

?對用戶戒客戶有價(jià)值的（Valuable）

?可估計(jì)的（Estimatable）

?小的（Small）

?可測試的（Testable）

Sprint會(huì)議如何迚行

–確定Sprint目標(biāo)及長度

–講解Story、估算時(shí)間、任務(wù)分解

–決定 sprint 要包含的故事

–一些其他問題

第六章

什么是界面原型

?界面原型指使用工具根據(jù)客戶需求及軟件分析人員的理解，將頭腦中的界面快速的反映到介質(zhì)上。

界面原型的目的?盡早驗(yàn)證需求

?盡早明確不確定性的因素

?方便溝通交流

?為后續(xù)界面設(shè)計(jì)提供基礎(chǔ)

第八章

ICONIX過程

?ICONIX過程的規(guī)模介于RUP和XP之間

?適合中小型的、需求相對明確的軟件項(xiàng)目

?ICONIX核心思想

?開源！節(jié)流！

ICONIX軟件過程是用例驅(qū)動(dòng)的軟件過程。

ICONIX過程中的第一步：明確愿景

?愿景是確保項(xiàng)目成功的第一步；

?愿景必須來自老大；

?愿景必須是可度量。

如何獲取軟件項(xiàng)目的愿景

?獲取軟件項(xiàng)目愿景的三步曲：

?第一步：找到軟件項(xiàng)目的“老大”；

?第二步：得到“老大”對項(xiàng)目的期望（愿景）；

?第三步：描述出愿景的度量指標(biāo)；

要點(diǎn)：系統(tǒng)要改善哪個(gè)組織的流程？

老大就是要改善的組織中最有權(quán)力的干系人

第九章

業(yè)務(wù)建模的目的：從組織的角度來定位系統(tǒng)的價(jià)值。

業(yè)務(wù)建模

?業(yè)務(wù)建模的目的是把視角從系統(tǒng)轉(zhuǎn)向組織，站在客戶角度看問題。

?業(yè)務(wù)用例是對組織為外部業(yè)務(wù)執(zhí)行者提供的價(jià)值的建模。

?現(xiàn)狀業(yè)務(wù)序列圖是對組織價(jià)值內(nèi)部實(shí)現(xiàn)流程（業(yè)務(wù)工人與業(yè)務(wù)實(shí)體的協(xié)作）的建模 ?改迚業(yè)務(wù)序列圖是對新系統(tǒng)為組織提供的改良的建模。

業(yè)務(wù)建模的步驟：

1.明確我們?yōu)檎l服務(wù)（選定愿景要改進(jìn)的組織）。

2.要改進(jìn)的組織是什么現(xiàn)狀（業(yè)務(wù)用例圖、現(xiàn)狀業(yè)務(wù)序列圖）。

3.我們?nèi)绾胃倪M(jìn)（改進(jìn)業(yè)務(wù)序列圖）。

第十章

域建模的步驟

第一步：提取名詞或名詞短語

第二步：排除重復(fù)、相似

第三步：排除系統(tǒng)范圍外

第四步：畫出第一版域模型圖

第五步：整理第一版域模型

域模型之間的關(guān)系

?泛化[Generalization]，一般元素和特殊元素的關(guān)系。

?關(guān)聯(lián)[Association]，兩個(gè)類乊間存在著某種語義上的聯(lián)系。

系統(tǒng)需求分析的目的是把視角轉(zhuǎn)向新系統(tǒng)，站在最織

用戶（及其它干系人）的角度看問題。

?系統(tǒng)用例是對（新）系統(tǒng)為系統(tǒng)執(zhí)行者提供的價(jià)值的建模

系統(tǒng)用例建模步驟

1.繪制系統(tǒng)用例圖

2.編寫系統(tǒng)用例描述

3.更新域模型

繪制系統(tǒng)用例圖

1.確定系統(tǒng)邊界

2.識別系統(tǒng)執(zhí)行者

3.識別系統(tǒng)用例

4.確定用例間的關(guān)系

用例描述的作用

?用例圖描述總體，用例文檔描述紳節(jié)。

?每個(gè)用例必須對應(yīng)有用例描述。

用例描述的基本組成?干系人利益

?基本路徑

?擴(kuò)展路徑

?業(yè)務(wù)觃則

軟件產(chǎn)品的典型非功能性需求(RUPS)

?可靠性[Reliability]。

?可用性[Usability]。

?性能[Performance]。

?可支持性[Supportability]。

需求獲取的方法

?研究文檔。

?問卷調(diào)查。

?訪談。

?觀察。

?研究競爭對手。

需求分析結(jié)果復(fù)核

?形式：面對面會(huì)議。

?參會(huì)人：甲乙雙方在需求分析階段的主要參與者。

?被審材料：域模型、用例圖、用例描述、非功能性需求；

?過程：需求分析師主持，最終需求分析成果，所有參與者交流討論，達(dá)成統(tǒng)一理解和確認(rèn)。?結(jié)論：所有參與者簽字確認(rèn)。（當(dāng)然，也有可能是未達(dá)成共識，需要返工。）

?注意：后續(xù)的工作基本不需要用戶的參不了。

第十一章

健壯性分析的步驟

第一步：創(chuàng)建一個(gè)空的健壯性圖。

第三步：從基本路徑的第一句話開始畫健壯性圖。

第二步：直接將用例文本粘貼到圖上（基本路徑和擴(kuò)展路徑）。

第四步：貫串整個(gè)用例基本路徑，一次一個(gè)句子，畫執(zhí)行者、適當(dāng)?shù)倪吔鐚ο蠛蛯?shí)體對象以及控制器，和各元素乊間的連線。

第五步：將每一個(gè)擴(kuò)展路徑畫在健壯性圖上，并以紅色標(biāo)示出。

在用例驅(qū)動(dòng)的開發(fā)模式中，用例的準(zhǔn)確完整性是關(guān)鍵；

?健壯性分析技術(shù)兩個(gè)主要的價(jià)值：其一幫助完善用例分析結(jié)果；其二完善域模型，做為需求分析走向系統(tǒng)設(shè)計(jì)的過度技術(shù)；

?丌要花費(fèi)太多的精力和時(shí)間在本階段，本階段的成果也僅起到過度作用，不納入最終文檔； 第十二章

關(guān)鍵設(shè)計(jì)是功能性需求的設(shè)計(jì)，成果為類圖和序列圖；

?關(guān)鍵設(shè)計(jì)還沒考慮真實(shí)實(shí)現(xiàn)的平臺相關(guān)因素，因此不能基于這個(gè)階段的設(shè)計(jì)成果開始編碼； ?關(guān)鍵設(shè)計(jì)的方法就是在域模型、用例描述和健壯性分析的基礎(chǔ)上，迭代生成類圖和序列圖；

關(guān)鍵設(shè)計(jì)的步驟

?第一步：將現(xiàn)有的域模型直接作為第一版靜態(tài)類模型；

?第二步：基于用例描述和健壯性分析結(jié)果，畫出每個(gè)用例的序列圖；

?健壯性圖中的控制類會(huì)轉(zhuǎn)化為方法；

?如果也轉(zhuǎn)化為控制類，那么就添加到類圖中（注意：邊界類丌添加到類圖中）； ?第三步：整理靜態(tài)類圖和序列圖；

?第四步：關(guān)鍵設(shè)計(jì)復(fù)核，迭代更新用例圖、類圖和序列圖；

高內(nèi)聚、低耦合。是判斷設(shè)計(jì)好壞的標(biāo)準(zhǔn)。

關(guān)鍵設(shè)計(jì)復(fù)核的指導(dǎo)建議

?確保關(guān)鍵設(shè)計(jì)的“如何做”和需求階段的“做什么”匹配。也就是說每個(gè)用例都要和序列圖匹配，包含了用例的基本流程和分支流程。

?復(fù)核設(shè)計(jì)的品質(zhì)。應(yīng)該至少有一個(gè)設(shè)計(jì)與家在場。

?檢查消息的連貫性。檢查時(shí)序圖上消息箭頭的指向，有時(shí)我們會(huì)發(fā)現(xiàn)對象乊間缺少消息而造成跳躍，我們必須消除這些邏輯跳躍。

?確保方法分配給了適當(dāng)?shù)念?，類視圖中的每一個(gè)類擁有適當(dāng)?shù)姆椒ê蛯傩浴?/p>

第五篇：軟件工程導(dǎo)論最全復(fù)習(xí)總結(jié)(精)

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

2、軟件是程序、數(shù)據(jù)及相關(guān)文檔的完整集合,程序是能夠完成預(yù)定功能和性能的可執(zhí)行的

程序序列;數(shù)據(jù)是是使程序能夠適當(dāng)?shù)奶幚硇畔⒌臄?shù)據(jù)結(jié)構(gòu);文檔是開發(fā)、使用和維護(hù)程序所需要的圖文資料。

3、軟件工程學(xué)包含3個(gè)要素:方法、工具、過程。

4、目前使用最廣泛的軟件工程方法學(xué)是傳統(tǒng)方法學(xué)和面向?qū)ο蠓椒▽W(xué)。

5、軟件工程方法學(xué)的軟件過程基本上可以用瀑布模型來描述。

6、瀑布模型、快速原型模型、增量模型、螺旋模型、噴泉模型。

7、Rup把軟件生命周期劃為:初始、精化、構(gòu)建、移交階段。

8、可行性研究的三方面:技術(shù)可行性、經(jīng)濟(jì)可行性、操作可行性。

9、數(shù)據(jù)流圖(DFD是一種圖形化技術(shù),他描繪信息流和數(shù)據(jù)從輸入移動(dòng)到輸出的過程中

所經(jīng)受的變化。

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

11、數(shù)據(jù)流圖和數(shù)據(jù)字典共同構(gòu)成系統(tǒng)的邏輯模型,沒有數(shù)據(jù)字典,數(shù)據(jù)如就不嚴(yán)格, 沒有流程圖,數(shù)據(jù)字典也難以發(fā)揮作用。

12、需求分析階段結(jié)束之前,系統(tǒng)分析員應(yīng)該寫出軟件需求規(guī)格說明書,以書面形式準(zhǔn)

確的描述軟件需求。13、9、結(jié)構(gòu)化分析方法就是面向數(shù)據(jù)流自頂向下逐步求精進(jìn)行需求分析的方法。

14、ER圖中包含了實(shí)體、關(guān)系和屬性,矩形代表實(shí)體,菱形表示關(guān)系,橢圓或圓角矩

形表示屬性,用直線把實(shí)體和其屬性連接。

15、驗(yàn)證軟件需求的正確性:一致性、完整性、現(xiàn)實(shí)性、有效性。

16、總體設(shè)計(jì)的基本目的是回答“概括地說,系統(tǒng)應(yīng)該如何實(shí)現(xiàn)?”,總體設(shè)計(jì)又稱為

概要設(shè)或初步設(shè)計(jì)。

17、模塊的獨(dú)立程度可以有兩個(gè)定性標(biāo)量度量:內(nèi)聚和耦合。

18、軟件測試的目標(biāo):(1測試是為了發(fā)現(xiàn)程序中的錯(cuò)誤而執(zhí)行程序的過程;(2好的

測試方案是極可能發(fā)現(xiàn)迄今為止尚未發(fā)現(xiàn)的錯(cuò)誤的測試方案;(3成功的測試是發(fā)現(xiàn)可至今為止尚未發(fā)現(xiàn)的錯(cuò)誤的測試。

19、軟件測試步驟:模塊測試、子系統(tǒng)測試、系統(tǒng)測試、驗(yàn)收測試、平行運(yùn)行。

20、軟件可靠性是程序在給定的時(shí)間點(diǎn),按照規(guī)格說明書的規(guī)定,成功的運(yùn)行的概率。

21、用面向?qū)ο蠓椒ㄩ_發(fā)軟件,通常需要建立3種形式的模型:描述系統(tǒng)數(shù)據(jù)結(jié)構(gòu)的對

象模型,描述系統(tǒng)控制結(jié)構(gòu)的動(dòng)態(tài)模型和描述系統(tǒng)功能的功能模型。

22、用面向?qū)ο蠓椒ㄩ_發(fā)軟件,在任何情況下,對象模型始終都是最重要、最基本的、最核心的。

23、通常,使用UML提供的類圖來建立對象模型。

24、類與類之間通常有關(guān)聯(lián)、泛化(繼承、依賴和細(xì)化等4種關(guān)系。

25、在UML中,在一段為空心的三角形的連線表示泛化關(guān)系。

26、復(fù)雜問題的對象模型通常由:主題層、類與對象層、結(jié)構(gòu)層、屬性層和服務(wù)層。

27、廣義的說,軟件重用可分為知識重用、方法和標(biāo)準(zhǔn)的重用、軟件成分的重用。

28、工程網(wǎng)絡(luò)和Gantt圖同樣是安排進(jìn)度和管理工程進(jìn)度情況的強(qiáng)有力的工具。29、3種典型人員組織方式:民主制程序員組、住程序員組、現(xiàn)代程序員組。30、軟件過程的輸出信息可以分為3類計(jì)算機(jī)程序、描述計(jì)算機(jī)程序的文檔、數(shù)據(jù),這

些項(xiàng)組成了軟件過程中產(chǎn)生的全部信息,人們把他們統(tǒng)稱為軟件配置,而這些項(xiàng)就是軟件配置項(xiàng)。

31、Cmm把軟件過程從無序到有序的進(jìn)化過程分成5個(gè)階段,并把這些階段排序,形

成五個(gè)逐層提高的等級。能力的成熟度的5個(gè)等級從低到高依次是:初始級(1級、可重復(fù)級(2級、已定義級(3級已管理級(4級和優(yōu)化級(5級。

15、編碼風(fēng)格:持續(xù)內(nèi)部文檔、數(shù)據(jù)說明、語句構(gòu)造、輸入輸出、效率、32、軟件危機(jī)的典型表現(xiàn):對軟件開發(fā)成本和進(jìn)度的估計(jì)常常很不準(zhǔn)確;用戶對“已完

成”的軟件系統(tǒng)不滿意的現(xiàn)象經(jīng)常發(fā)生;軟件產(chǎn)品質(zhì)量往往靠不住;軟件常常是不可維護(hù)的;軟件通常沒有適當(dāng)?shù)奈臋n資料;軟件成本在計(jì)算機(jī)總成本中所占的比例逐年上升;軟件開發(fā)生產(chǎn)效率提高的速度,遠(yuǎn)遠(yuǎn)跟不上計(jì)算機(jī)應(yīng)用迅速普及深入的趨勢。

33、軟件不同于硬件,他是計(jì)算機(jī)系統(tǒng)的邏輯部件而不是物理部件。

34、軟件不同于一般程序,它的一個(gè)顯著特點(diǎn)就是規(guī)模龐大。簡單題

1、軟件工程基本原理(1用分階段的生存周期嚴(yán)格管理。(2堅(jiān)持進(jìn)行階段評審。(3實(shí)行嚴(yán)格的產(chǎn)品控制。(4采用現(xiàn)代程序設(shè)計(jì)技術(shù)。(5結(jié)果應(yīng)能清楚地審查。(6開發(fā)小組人員應(yīng)該少而精。(7承認(rèn)不斷改進(jìn)軟件工程實(shí)踐的必要性。

2、軟件生命周期各階段的基本任務(wù)軟件生命周期由軟件定義、軟件開發(fā)和運(yùn)行維護(hù)3個(gè)時(shí)期組成,每個(gè)時(shí)期又進(jìn)一步劃分成若干個(gè)階段。(1問題定義(2可行性研究(3需求分析(4總體設(shè)計(jì)(5詳細(xì)設(shè)計(jì)(6編碼和單元測試(7綜合測試(8軟件維護(hù)

3、需求分析的任務(wù)

一、確定對系統(tǒng)的綜合要求(1功能需求(2性能需求(3可靠性和可用性需求(4出錯(cuò)處理需求(5接口需求(6約束(7逆向需求(8將來可能提出的需求

二、分析系統(tǒng)的數(shù)據(jù)要求

三、導(dǎo)出系統(tǒng)的邏輯模型

四、修正系統(tǒng)開發(fā)計(jì)劃

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

5、面向?qū)ο笤O(shè)計(jì)準(zhǔn)則和啟發(fā)式原則

(1模塊化(2抽象(3信息隱藏(4弱耦合(5強(qiáng)內(nèi)聚(6可重用

(1設(shè)計(jì)結(jié)果應(yīng)該清晰易懂(2一般-特殊結(jié)構(gòu)的深度應(yīng)適當(dāng)(3設(shè)計(jì)簡單的類(4使用簡單的協(xié)議(5使用簡單的服務(wù)(6把設(shè)計(jì)變動(dòng)減至最小

6、軟件維護(hù)的幾種類型

(1改正性維護(hù)(2適應(yīng)性維護(hù)(3完善性維護(hù)(4預(yù)防性維護(hù)

7、決定軟件可維護(hù)性因素

(1可理解性(2可測試性(3可修改性(4可移植性(5可重用性

8、軟件配置項(xiàng)

軟件配置的主要任務(wù)就是控制變化,同時(shí)也負(fù)責(zé)各個(gè)軟件配置項(xiàng)和軟件各種版本的標(biāo)志、軟件配置審計(jì)以及軟件配置發(fā)生的任何變化的報(bào)告。(1標(biāo)識軟件配置中的對象(2版本控制(3變化控制(4配置審計(jì)(5狀態(tài)報(bào)告

設(shè)計(jì)題

1、等價(jià)類有效/無效數(shù)據(jù)邊界值測試

2、UML類圖的描述

3、N-S圖、PAD圖 論述題

(1軟件工程(2可行性研究問題定義階段必須回答的關(guān)鍵問題是:“要解決的問題是

什么”。如果不知道問題是什么就試圖解決這個(gè)問題,顯然是盲目的,只會(huì)自白浪費(fèi)

時(shí)間和金錢,最終得出的結(jié)果很可能是毫無意義的。盡管確切地定義問題的必要性是十分明顯的,但是在實(shí)踐中它卻可能是最容易被忽視的一個(gè)步驟。(3需求分析這個(gè)階段的任務(wù)仍然不是具體地解決客戶的問題,而是準(zhǔn)確地回答“目標(biāo)系統(tǒng)必須做什么”這個(gè)問題。(4總體設(shè)計(jì)這個(gè)階段的基本任務(wù)是,概括地回答“怎樣實(shí)現(xiàn)目標(biāo)系統(tǒng)?”這個(gè)問題。概要設(shè)計(jì)又稱為初步設(shè)計(jì)、邏輯設(shè)計(jì)、高層設(shè)計(jì)或總體設(shè)計(jì)。(5詳細(xì)設(shè)計(jì)這個(gè)階段的任務(wù)還不是編寫程序,而是設(shè)計(jì)出程序的詳細(xì)規(guī)格說明。這種規(guī)格說明的作用很類似于其他工程領(lǐng)域中工程師經(jīng)常使用的工程藍(lán)圖,它們應(yīng)該包含必要的細(xì)節(jié),程序員可以根據(jù)它們寫出實(shí)際的程序代碼。(6編碼實(shí)現(xiàn)(語言,測試這個(gè)階段的關(guān)鍵任務(wù)是寫出正確的容易理解、容易維護(hù)的程序模塊。(7維護(hù)維護(hù)階段的關(guān)鍵任務(wù)是,通過各種必要的維護(hù)活動(dòng)使系統(tǒng)持久地滿足用戶的需要。

(8面向?qū)ο蠹夹g(shù)(9項(xiàng)目管理

1.軟件工程學(xué):為了更有效地開發(fā)與維護(hù)軟件,軟件工作者早20世紀(jì)60年代后期開始認(rèn)真

研究消除軟件危機(jī)的途徑,從而逐漸形成了一門新興的工程學(xué)科。2.軟件危機(jī)典型變現(xiàn):(1.對軟件發(fā)開成本和進(jìn)度的估計(jì)常常不準(zhǔn)確.(2.用戶對“已完成的”軟件系統(tǒng)不滿意的現(xiàn)象經(jīng)常發(fā)生.(3.軟件產(chǎn)品的質(zhì)量往往靠不住.(4.軟件常常是不可維護(hù)的.(5.軟件通常沒有適當(dāng)?shù)奈臋n資料.(6.軟件成本在計(jì)算機(jī)系統(tǒng)總成本中所占的比例逐年上升.(7.軟件開發(fā)產(chǎn)生率提高的速度,遠(yuǎn)遠(yuǎn)跟不上計(jì)算機(jī)應(yīng)用迅速普及深入的趨勢.3.產(chǎn)生軟件危機(jī)的原因:(1.軟件不同于硬件,它是計(jì)算機(jī)系統(tǒng)中的邏輯部件而不是物理部件.(2.軟件不同于一般程序,它的一個(gè)顯著特點(diǎn)是規(guī)模龐大,而且程序復(fù)雜性將隨著程序規(guī)模 的增加而呈指數(shù)上升.(3.軟件本身獨(dú)有的特點(diǎn)確實(shí)給開發(fā)和維護(hù)帶來一些客觀困難.(4與軟件開發(fā)和維護(hù)有關(guān)的許多錯(cuò)誤認(rèn)識和做法形成,可以歸因于在計(jì)算機(jī)系統(tǒng)發(fā)展的早

期階段軟件開發(fā)的個(gè)體特點(diǎn).4.消除軟件危機(jī)的途徑:(1.應(yīng)該對計(jì)算機(jī)軟件有一個(gè)正確的認(rèn)識.(2.充分認(rèn)識到軟件開發(fā)不是某種個(gè)體勞動(dòng)的神秘技巧,而應(yīng)該是組織良好、管理嚴(yán)密、各

類人員協(xié)同配合、共同完成的工程項(xiàng)目.(3.在使用要總結(jié)出成功的技術(shù)和方法,盡快消除錯(cuò)誤概念和做法.(4.開發(fā)和使用更好的軟件工具 5.軟件工程的本質(zhì)特性:(1.軟件工程關(guān)注于大型程序的構(gòu)造.(2.軟件工程的中心課題是控制復(fù)雜性.(3.軟件經(jīng)常變化.(4.開發(fā)軟件的效率非常重要.(5.和諧地合作是開發(fā)軟件的關(guān)鍵.(6.軟件必須有效地支持它的用戶.(7.在軟件工程領(lǐng)域中通常由具有一種文化背景的人替具有另一種文化背景的人創(chuàng)造產(chǎn)

品.6.軟件工程的原理:(1.用分段的生命周期計(jì)劃嚴(yán)格管理.(2.堅(jiān)持進(jìn)行階段評審.(3.實(shí)行嚴(yán)格的產(chǎn)品控制.(4.采用現(xiàn)代程序設(shè)計(jì)技術(shù).(5.結(jié)果應(yīng)能清楚地審查.(6.開發(fā)小組的人員應(yīng)該少而精.(7.承認(rèn)不斷改進(jìn)軟件工程實(shí)踐的必要性.7.軟件生命周期:由軟件定義、軟件開發(fā)和運(yùn)行維護(hù)3個(gè)時(shí)期組成,每個(gè)時(shí)期又進(jìn)一步劃分成若干個(gè)階段.8.軟件開發(fā)時(shí)期4個(gè)階段:總體設(shè)計(jì),詳細(xì)設(shè)計(jì),編碼和單元測試,綜合測試.9.軟件維護(hù),維護(hù)階段的關(guān)鍵任務(wù)是,通過各種必要的維護(hù)活動(dòng)使系統(tǒng)持久地滿足用戶的需要.10.瀑布模型的特點(diǎn):(1.階段間具有順序性和依賴性.(2.推遲實(shí)現(xiàn)的觀點(diǎn).(3.質(zhì)量保證的觀點(diǎn).11.快速原型模型:是快速建立起來的可以在計(jì)算機(jī)運(yùn)行的程序,它所能完成的功能往往是最

終產(chǎn)品能完成的功能的一個(gè)子集.12.快速模型的主要優(yōu)點(diǎn)是不帶饋環(huán)的,軟件產(chǎn)品基本上是線性順序進(jìn)行的.13.可行性研究的目的:用最小的代價(jià)在盡可能短的時(shí)間內(nèi)確定問題是否能夠解決.14.可行性的解法:(1技術(shù)可行性.(2經(jīng)濟(jì)可行性.(3操作可行性.15.可行性研究過程步驟:(1.復(fù)查系統(tǒng)規(guī)模和目標(biāo).(2.研究目前正在使用的系統(tǒng).(3.導(dǎo)出新系統(tǒng)的高層邏輯模型.(4.進(jìn)一步定義問題.(5.導(dǎo)出和評價(jià)供選擇的解法.(6.推薦行動(dòng)方針.(7.草擬開發(fā)計(jì)劃.(8.書寫文檔提交審查.16.系統(tǒng)流程圖:是概括地描繪物理系統(tǒng)的傳統(tǒng)工具.它的基本思想是用圖形符號以黑盒子形

式描繪組成系統(tǒng)的每個(gè)部件.17.數(shù)據(jù)流圖(DFD:是一種圖形化技術(shù),它描繪信息流和數(shù)據(jù)從輸入移動(dòng)到輸出的過程中所經(jīng)

受的變換.18.數(shù)據(jù)字典:是關(guān)于數(shù)據(jù)的信息的集合,就是對數(shù)據(jù)流圖中包括的所有元素的定義的集合.19.數(shù)據(jù)字典組成元素:(1數(shù)據(jù)流.(2數(shù)據(jù)流分量.(3數(shù)據(jù)存儲(chǔ).(4處理.20.定義數(shù)據(jù)的方法:定義絕大多數(shù)復(fù)雜事物的方法,都是用被定義的事物的成分的某種組合

表示這個(gè)事物,這些組成成分又由更底層的成分的組合來定義.21.數(shù)據(jù)字典最重要用途:作為分析階段的工具。

22.為什么要進(jìn)行需求分析:因?yàn)樗幕救蝿?wù)是準(zhǔn)確地回答“系統(tǒng)必須做什么?”這個(gè)問

題?？尚行匝芯侩A段只是粗略了解用戶的需求,許多細(xì)節(jié)被忽略,然而最終的系統(tǒng)中卻不能遺漏任何細(xì)節(jié)。所以可行性研究并不能代替需求分析。

23.軟件系統(tǒng)綜合要求:(1功能需求.(2性能需求.(3可靠性和可行性需求.(4出錯(cuò)處理需求.(5 接口需求.(6約束.(7逆向需求.(8將來可能提出的要求.24.訪談:是最早開始使用的獲取用戶需求的技術(shù),是迄今為止仍然廣泛使用的需求分析技術(shù).25.需求分析過程3種模型:數(shù)據(jù)模型、功能模型和行為模型.26.數(shù)據(jù)模型包含3種相互關(guān)聯(lián)信息:數(shù)據(jù)對象、數(shù)據(jù)對象的屬性及數(shù)據(jù)對象彼此間相互連接的關(guān)系.27.總體設(shè)計(jì)的目的:就是回答“概括地說,系統(tǒng)應(yīng)該如何實(shí)現(xiàn)?”這個(gè)問題.28.總體設(shè)計(jì)兩個(gè)過程:系統(tǒng)設(shè)計(jì)階段,確定系統(tǒng)的具體實(shí)現(xiàn)方案;結(jié)構(gòu)設(shè)計(jì)階段,確定軟件結(jié)

構(gòu).29.總體設(shè)計(jì)過程步驟:(1設(shè)想供選擇的方案.(2選取合理的方案.(3推薦最佳方案.(4功能分

解.(5設(shè)計(jì)軟件結(jié)構(gòu).(6設(shè)計(jì)數(shù)據(jù)庫.(7制定測試計(jì)劃.(8書寫文檔.(9審查和復(fù)查.30.模塊化:就是把程序劃分成獨(dú)立命名且可獨(dú)立訪問的模塊,每個(gè)模塊完成一個(gè)子功能,把這

些模塊集成起來構(gòu)成一個(gè)整體,可以完成指定的功能滿足用戶的需求.31.怎做到模塊獨(dú)立:開發(fā)具有獨(dú)立功能而且和其他模塊之間沒有過多的相互作用的模塊.32模塊獨(dú)立兩個(gè)定性標(biāo)準(zhǔn)度量:內(nèi)聚和耦合.33.耦合:對一個(gè)軟件結(jié)構(gòu)內(nèi)不同模塊之間互連程度的度量.34.內(nèi)聚:標(biāo)志著一個(gè)模塊各個(gè)元素彼此結(jié)合的緊密程度,它是信息隱藏和局部化概念的自然

擴(kuò)展.35.功能內(nèi)聚10分順序內(nèi)聚9分通信內(nèi)聚7分過程內(nèi)聚5分時(shí)間內(nèi)聚3分邏輯內(nèi)聚1 分偶然內(nèi)聚0分

36.設(shè)計(jì)時(shí)要力爭做到高內(nèi)聚,低耦合.37.啟發(fā)式規(guī)則介紹:(1.改進(jìn)軟件結(jié)構(gòu)提高模塊獨(dú)立性.(2.模塊規(guī)模應(yīng)該適中.(3.深度、寬度、扇出和扇入都應(yīng)適當(dāng).(4.模塊的作用域應(yīng)該在控制域之內(nèi).(5.力爭降低模塊接口的復(fù)雜程度.(6.設(shè)計(jì)單入口單出口的模塊.(7.模塊功能應(yīng)該可以預(yù)測

38.交換流:信息沿輸入通信路進(jìn)入系統(tǒng),同時(shí)由外部形式變換成內(nèi)部形式,進(jìn)入系統(tǒng)的信息通

過變換中心,經(jīng)加工處理以后再沿輸出路變成外部形式離開軟件系統(tǒng).39.事務(wù)流:數(shù)據(jù)沿輸入通路到達(dá)一個(gè)處理T,這個(gè)處理根據(jù)輸入數(shù)據(jù)的類型在若干個(gè)動(dòng)作序列

中選出一個(gè)來執(zhí)行.40.詳細(xì)設(shè)計(jì)目標(biāo):確定應(yīng)該怎樣具體地實(shí)現(xiàn)所要求的系統(tǒng).41.結(jié)構(gòu)程序設(shè)計(jì):如果一個(gè)程序的代碼塊僅僅通過順序、選擇和循環(huán)這3種基本控制結(jié)構(gòu)進(jìn)

行連接,并且每個(gè)代碼只有一個(gè)入口和一個(gè)出口.42.實(shí)現(xiàn):通常把編碼和測試統(tǒng)稱.43.編碼:就是那軟件設(shè)計(jì)結(jié)果翻譯成用某種程序設(shè)計(jì)語言書寫的程序.44.測試方法:黑盒測試(知產(chǎn)品的功能可測試和白盒測試(知產(chǎn)品內(nèi)部工作過程可測試

45.測試步驟:(1模塊測試.(2子系統(tǒng)測試.(3系統(tǒng)測試.(4驗(yàn)收測試.(5平行運(yùn)行.46.測試重點(diǎn):(1模塊接口(2局部數(shù)據(jù)結(jié)構(gòu)(3重要的執(zhí)行通路(4出錯(cuò)處理通路(5邊界條件.47.確認(rèn)測試:也稱驗(yàn)收測試,它的目標(biāo)是驗(yàn)收軟件的有效性.48.Alpha測試:由用戶在開發(fā)者的場所進(jìn)行,并且在開發(fā)者對用戶的“指導(dǎo)”下進(jìn)行測試.開發(fā)者

負(fù)責(zé)記錄發(fā)現(xiàn)的錯(cuò)誤和使用中遇到的問題.49.Beta測試:由軟件的最終用戶在一個(gè)或多個(gè)客戶場所進(jìn)行.與Alpha測試不同,開發(fā)者通常

不在Beta測試的現(xiàn)場,因此,Bate測試時(shí)軟件在開發(fā)者不能控制的環(huán)境中的“真實(shí)”應(yīng)用.50.調(diào)試:是在測試發(fā)現(xiàn)錯(cuò)誤之后排除錯(cuò)誤的過程.51.軟件維護(hù):就是在軟件已經(jīng)交付使用之后,為了改正錯(cuò)誤或滿足新的需要而修改的過程.52.改正性維護(hù):診斷和改正錯(cuò)誤的過程.53.決定軟件維護(hù)性的因素:(1可理解性.(2可測試性.(3可修改性.(4可移植性.(5可重用性.54.用戶文檔:是用戶了解系統(tǒng)的第一步,它應(yīng)該能使用戶獲得對系統(tǒng)的準(zhǔn)確的初步印象.55.用戶文檔包括的內(nèi)容:(1功能描述(2安裝文檔(3使用手冊(4參考手冊(5操作員指南.56.系統(tǒng)文檔:指從問題定義、需求說明到驗(yàn)收測試計(jì)劃這樣一系列和系統(tǒng)實(shí)現(xiàn)有關(guān)的文檔.