軟件工程期末重點知識總結(jié)

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

1.1軟件危機

1.1.1軟件危機的介紹

1.軟件危機定義：軟件危機是指在軟件的開發(fā)和維護過程中，所遇到的一系列嚴

重問題。

2.軟件危機主要有以下一些典型表現(xiàn)（也是軟件二程面臨的問題）：

（1）對軟件開發(fā)成本和進度的估計常常很不準(zhǔn)確。

（2）用戶對“已經(jīng)完成的”軟件系統(tǒng)不滿意的現(xiàn)象經(jīng)常發(fā)生。

（3）軟件產(chǎn)品的質(zhì)量往往靠不住。

（4）軟件常常是不可維護的。

（5）軟件通常沒有適當(dāng)?shù)奈臋n資料。

（6）軟件成本在計算機系統(tǒng)總成本所占的比例逐年上升。

（7）軟件開發(fā)生產(chǎn)率提高的速度，遠遠跟不上計算機應(yīng)用迅速普及深入的趨勢。

1.1.3消除軟件危機的途徑

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

其中，程序是能夠完成預(yù)定功能和性能的可執(zhí)行的指令序列；

數(shù)據(jù)是使程序能夠適當(dāng)?shù)靥幚硇畔⒌臄?shù)據(jù)結(jié)構(gòu)：

文檔是開發(fā)、使用和維護程序所需要的圖文資料。

2.總之，為了解決軟件危機，既要有技術(shù)措施（方法和工具），又要有必要的組

織管理措施。

軟件工程正是從管理和技術(shù)兩方面研究如何更好的開發(fā)和維護計算機軟件的一

門新學(xué)科。

1.2軟件工程

1.2.1軟件工程的介紹

軟件工程的定義：軟件工程是指導(dǎo)計算機軟件開發(fā)和維護的一門工程學(xué)科。

采用工程的概念、原理、技術(shù)和方法來開發(fā)與維護軟件，把經(jīng)過時間考驗而證明

正確的管理技術(shù)和

當(dāng)前能夠得到的最好的技術(shù)方法結(jié)合起來，以經(jīng)濟的開發(fā)出高質(zhì)量的軟件并有效

地維護它，這就是軟件工程。

1.2.2軟件工程的基本原理（簡答）

七條原理：他認為這7條原理是確保軟件產(chǎn)品質(zhì)量和開發(fā)效率的原理的最小集

&口0

這7條原理是互相獨立的，其中任意6條原理的組合都不能代替另一條原理，因

此，它們是缺一不可的最小集合。

軟件工程的七條基本原理：

（1）用分階段的生命周期計劃嚴格管理。

（2）堅持進行階段評審。

（3）實行嚴格的產(chǎn)品控制。

（4）采用現(xiàn)代程序設(shè)計技術(shù)。

（5）結(jié)果應(yīng)能清楚地審查。

（6）開發(fā)小組的成員應(yīng)該少而精。

（7）承認不斷改進軟件工程實踐的必要性。

]23軟件匚程方法學(xué)

1.軟件工程包括技術(shù)和管理兩方面的內(nèi)容，是技術(shù)和管理緊密結(jié)合所形成的工程

學(xué)科。

所謂管理就是通過計劃、組織和控制等一系列活動，合理地配置和使用各種資源,

以達到既定目標(biāo)的過程。

2.軟件工程方法學(xué)包含3個要素：方法、工具和過程。

其中，方法是完成軟件開發(fā)的各項任務(wù)的技術(shù)方法，回答“怎么做”的問題；

工具是為運用方法而提供的自動的或半自動的軟件工程支撐環(huán)境；

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

項任務(wù)的工作步驟。

1.3軟件生命周期

1.概括地說，軟件生命周期由軟件定義、軟件開發(fā)和運行維護（也稱軟件維護）

3個時期組成，

每個時期又進一步劃分成若干個階段。

2.軟件定義時期的任務(wù)是：確定軟件開發(fā)工程必須完成的總目標(biāo)；確定工程的可

行性；

導(dǎo)出實現(xiàn)工程目標(biāo)應(yīng)該采用的策略及系統(tǒng)必須完成的功能：估計完成該項工程需

要的資源和成本，并且制定工程進度表。

軟件定義時期通常進一步劃分成3個階段，即問題定義、可行性研究和需求分析。

3.開發(fā)時期具體設(shè)計和實現(xiàn)在前一時期定義的軟件,它通常由下述4個階段組成:

總體設(shè)計，詳細設(shè)計，編碼和單元測試，綜合測試。

其中前兩個階段乂稱為系統(tǒng)設(shè)計，后兩個階段乂稱為系統(tǒng)實現(xiàn)。

4.維護時期的主要任務(wù)是使軟件持久的滿足用戶的需求。具體地說，當(dāng)軟件在使

用過程中發(fā)現(xiàn)錯誤時應(yīng)該加以改正；

當(dāng)環(huán)境改變時，應(yīng)該修改軟件以適應(yīng)新的環(huán)境；當(dāng)用戶有新要求時應(yīng)該及時改進

軟件以滿足用戶的新需要。

通常對維護時期不在進一步的劃分階段，但是每一次維護活動本質(zhì)上都是一次壓

縮和簡化了的定義和開發(fā)過程。

5.軟件生命周期每個階段的基本任務(wù)（8個階段）

（1）問題定義（2）可行性研究（3）需求分析（4）總體設(shè)計

（5）詳細設(shè)計（6）編碼和單元測試（7）綜合測試（8）軟件維護

1.4軟件過程

1.4.1瀑布模型

特點：（1）階段間具有順序性和依賴性

（2）推遲實現(xiàn)的觀點（3）質(zhì)量保證的觀點

優(yōu)點：

（1）可強迫開發(fā)人員采用規(guī)范的方法

（2）嚴格的規(guī)定了每個階段必須提交的文檔

（3）要求每個階段的所有產(chǎn)品都必須經(jīng)過質(zhì)量保證小組的仔細驗證

缺點：

（1）無法解決軟件需求不明確或不準(zhǔn)確的問題

（2）可能導(dǎo)致最終開發(fā)的產(chǎn)品不能真正滿足用戶的需要

（3）瀑布模型比較適合開發(fā)需求明確的軟件

1.4.2快速原型模型（過渡產(chǎn)品）

快速原型：是快速建立起來的可以在計算機上運行的程序，它所能完成的功能往

往是最終產(chǎn)品能完成的功能的一個子集。

原型：是快速實現(xiàn)和運行的早期版本，反映最終系統(tǒng)部分重要特性。

優(yōu)點：

（1）通常能反映用戶真實需求；

（2）軟件產(chǎn)品的開發(fā)基本上是線性順序進行的。

144螺旋模型（改進了原型模型，在每個階段都加入風(fēng)險分析）

螺旋模型的基本思想是，使用原型及其他方法來盡量降低風(fēng)險。

理解這種模型的一個簡便方法，是把它看作在每個階段之前都增加了風(fēng)險分析過

程的快速原型模型。

螺旋模型主要適用于內(nèi)部開發(fā)的大規(guī)模軟件項目。

1.4.5噴泉模型（P22）

第二章可行性研究

2.1可行性研究的任務(wù)

1.可行性研究的目的不是解決問題，而是確定問題是否值得去解決。

2.可行性研究的基本內(nèi)容

（1）技術(shù)可行性（2）經(jīng)濟可行性（3）操作可行性

2.2可行性研究過程

典型的可行性研究過程有下述一些步驟：

（1）復(fù)查系統(tǒng)規(guī)模和目標(biāo)（2）研究目前正在使用的系統(tǒng)

（3）導(dǎo)出新系統(tǒng)的高層邏輯模型（4）進一步定義問題

（5）導(dǎo)出和評價供選擇的解法（6）推薦行動方針

（7）草擬開發(fā)計劃（8）書寫文檔提交審查

2.4數(shù)據(jù)流圖

數(shù)據(jù)流圖（DFD）是一種圖形化技術(shù)，它描繪信息流和數(shù)據(jù)從輸入移動到輸出的

過程中所經(jīng)受的交換。

4個元素圖形表示（P41）

2.5數(shù)據(jù)字典（理解）

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

的集合。

任后字典最主要的用途都是供人查閱對不了解的條目的解釋，數(shù)據(jù)字典的作用也

正是在軟件分析和設(shè)計的過程中給人

提供關(guān)于數(shù)據(jù)的描述信息。

數(shù)據(jù)流圖和數(shù)據(jù)字典共同構(gòu)成系統(tǒng)的邏輯模型，沒有數(shù)據(jù)字典，數(shù)據(jù)流圖就不嚴

格，然而沒有數(shù)據(jù)流圖，

數(shù)據(jù)字典也難以發(fā)揮作用。只有數(shù)據(jù)流圖和對數(shù)據(jù)流圖中每個元素的精確定義放

在一起，

才能共同構(gòu)成系統(tǒng)的規(guī)格說明書。

第三章需求分析

3.1需求分析的任務(wù)

3.1.1確定系統(tǒng)的綜合要求

通常對軟件系統(tǒng)有下述幾方面的綜合要求

(1)功能需求(2)性能需求

(3)可靠性和可用性需求(4)出錯處理需求

(5)接口需求(6)約束

(7)逆向需求(8)將來可能提出的要求

3.3.2軟件規(guī)格說明書的作用？（自己查）

（1）軟件設(shè)計和實現(xiàn)的基礎(chǔ)

（2）軟件開發(fā)項目的規(guī)劃、軟件價格的估算等

（3）測試和用戶驗收軟件系統(tǒng)的重要依據(jù)

（4）為軟件維護提供重要的信息

例.下列敘述中，不屬于軟件需求規(guī)格說明書的作用的是_Do

A.便于用戶、開發(fā)人員進行理解和交流

B.反映出用戶問題的結(jié)構(gòu)，可以作為軟件開發(fā)工作的基礎(chǔ)和依據(jù)

C.作為確認測試和驗收的依據(jù)

D.便于開發(fā)人員進行需求分析任何

3.8驗證軟件需求

3.8.1從哪些方面驗證軟件需求的正確性

1.一般說來，應(yīng)該從下述4個方面進行驗證。

（1）一致性：所有需求必須是一致的，任何一條需求不能和其他需求互相矛盾。

（2）完整性：需求必須是完整的，規(guī)格說明書應(yīng)該包括用戶需要的每一個功能

或性能。

（3）現(xiàn)實性：指定的需求應(yīng)該是用現(xiàn)有的硬件技術(shù)和軟件技術(shù)基本上可以實現(xiàn)

的。

（4）有效性：必須證明需求是正確有效的，確實能解決用戶面對的問題。

第五章總體設(shè)計

5.1設(shè)計工程

1.總體設(shè)計過程通常由兩個主要階段組成：

（1）系統(tǒng)設(shè)計階段，確定系統(tǒng)的具體實現(xiàn)方案（2）結(jié)構(gòu)設(shè)計階段：確定軟件結(jié)

構(gòu)

2.典型的總體設(shè)計包括下屬9個步驟:

（1）設(shè)想供選擇的方案（2）選取合理的方案

（3）推薦最佳方案（4）功能分解

（5）設(shè)計軟件結(jié)構(gòu)（6）設(shè)計數(shù)據(jù)庫

（7）制定測試計劃（8）書寫文檔。

（應(yīng)該完成的文檔通常有下述幾種：系統(tǒng)說明、用戶手冊、測試計劃、詳細的實

現(xiàn)計劃、數(shù)據(jù)庫設(shè)計結(jié)構(gòu)）（9）審查和復(fù)查

5.2設(shè)計原理

5.2.1模塊化（P94）

1.模塊：是由邊界元素限定的相鄰程序元素的序列，而且有一個總體標(biāo)示符代表

它。

面向?qū)ο蠓椒▽W(xué)中的定象是模塊，對象內(nèi)的方法也是模塊。模塊是構(gòu)成程序的基

本構(gòu)件。

2.模塊化：就是把程序劃分成獨立命名且可獨立訪問的模塊，每個模塊完成一個

子功能，把這些模塊集成起來構(gòu)成一個整體，

可以完成指定的功能滿足用戶的需求。

5.2.4信息隱藏（隱蔽）和局部化

信息隱藏（隱蔽）：在設(shè)計和確定模塊時，是的一個模塊內(nèi)包含的信息（過程和

數(shù)據(jù)），

不允許其他不需要這些信息的模塊訪問，獨立的模塊間僅僅交換為完成系統(tǒng)功能

而必須交換的信息。

局部化：將一些關(guān)系密切的軟件元素物理的放得彼此靠近。

5.2.5模塊獨立

1.衡量模塊獨立性的兩個準(zhǔn)則：（1）耦合性（2）內(nèi)聚性

2.耦合定義：耦合是對一個軟件結(jié)構(gòu)內(nèi)不同模塊之間互連程度的度量。

耦合強弱取決于模塊間接口的反正程度，進入或訪問一個模塊的點，以及通過接

口的數(shù)據(jù)。

3.耦合分類：

（1）無直接耦合：兩個模塊沒有直接關(guān)系，模塊獨立性最強。

（2）數(shù)據(jù)耦合：一個噗塊訪問另一個模塊時，僅僅通過數(shù)據(jù)參數(shù)交換輸入、輸

出信息。

（數(shù)據(jù)耦合是低耦合）

（3）控制耦合：模塊之間傳遞的是控制信息（盡管有時這種控制信息以數(shù)據(jù)的

形式出現(xiàn)），如開關(guān)、

標(biāo)志、名字等，控制被調(diào)用模塊的內(nèi)部邏輯。

（4）特征耦合：兩個模塊通過傳遞數(shù)據(jù)結(jié)構(gòu)加以聯(lián)系，或都與一個數(shù)據(jù)結(jié)構(gòu)有

關(guān)系，則稱這兩個模塊間存在特征耦合。

可能出現(xiàn)的情況：當(dāng)把整個數(shù)據(jù)結(jié)構(gòu)作為參數(shù)傳遞時，被調(diào)用的模塊雖然只需要

使用其中的一部分數(shù)據(jù)元素，

但實際可以使用的數(shù)據(jù)多于它真正需要的數(shù)據(jù)，這將導(dǎo)致對數(shù)據(jù)訪問失去控制。

（5）公共環(huán)境耦合：一組模塊引用一個公用數(shù)據(jù)區(qū)（也稱全局數(shù)據(jù)區(qū)，公共數(shù)

據(jù)環(huán)境）

公共數(shù)據(jù)區(qū)指：全局數(shù)據(jù)結(jié)構(gòu)、共享通訊區(qū)、內(nèi)存公共覆蓋區(qū)等。

（6）內(nèi)容耦合：（是最不好的耦合形式）有下列情況之一的。

A.一個模塊直接訪問另一個模塊的內(nèi)部信息。

B.一個模塊不通過正常入口轉(zhuǎn)換到另一個模塊內(nèi)部。

C.兩個模塊有一部分代碼重疊。

D.一個模塊有多個入匚模塊。

（注：盡量使用數(shù)據(jù)耦合，少用控制耦合和特征耦合，限制公共環(huán)境耦合的范圍,

完全不用內(nèi)容耦合。）

4.內(nèi)聚定義：又條質(zhì)內(nèi)聯(lián)系。指一個模塊內(nèi)部各個元素彼此結(jié)合的緊密程度的度

量。

若一個模塊內(nèi)各元素聯(lián)系的越緊密，則它的內(nèi)聚性就越高。設(shè)計目標(biāo)：高內(nèi)聚。

5.內(nèi)聚有哪些？（P99）

7種內(nèi)聚及評分：功能內(nèi)聚（10分）、順序內(nèi)聚（9分）、通信內(nèi)聚（7分）、

過程內(nèi)聚（5分）、時間內(nèi)聚（3分）、邏輯內(nèi)聚3分）、偶然內(nèi)聚（0分）

5.3啟發(fā)規(guī)則（P100）

改進原則：高內(nèi)聚、低耦合

啟發(fā)性規(guī)則以下幾條：

（1）改進軟件結(jié)構(gòu)，提高模塊獨立性

（2）模塊規(guī)模應(yīng)該適中（重點）

（3）深度、寬度、扇出和扇入都應(yīng)適當(dāng)（計算題）

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

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

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

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

5.4描述軟件結(jié)構(gòu)的圖形工具5.4.2結(jié)構(gòu)圖（P103）

主要成分說明：

（1）一個方框代表一個模塊，框內(nèi)注明模塊的名字或者主要功能。

（2）方框之間的箭頭（或直線）表示模塊的調(diào)用關(guān)系，表示前一模塊對后一模

塊的調(diào)用。

（3）調(diào)用直線邊的小箭頭，表示調(diào)用時從一個模塊傳給另一個模塊的數(shù)據(jù)，也

指出了傳送方向.

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

數(shù)據(jù)流可分為兩種類型：（1）變換型數(shù)據(jù)流（2）事務(wù)性數(shù)據(jù)流

第六章詳細設(shè)計

6.1結(jié)構(gòu)程序設(shè)計

1.什么是結(jié)構(gòu)程序設(shè)計？

經(jīng)典定義：如果一個程序的代碼塊僅僅通過順序、選擇和循環(huán)這3種基本控制結(jié)

構(gòu)進行連接，

而且每個代碼塊只有一個入口和一個出口，則稱這個程序是結(jié)構(gòu)化的。

比較全面的定義：結(jié)構(gòu)程序設(shè)計是盡可能少用GOTO語句的程序設(shè)計方法，最

好僅僅在檢測出錯誤時才使用

GOTO語句，而且一個總是使用前向的GOTO語句。

6.2人機界面設(shè)計（理解PU9-P設(shè)4）

6.3過程設(shè)計的工具（出大題）（結(jié)合課件）

1.要求:會畫程序流程圖、盒圖、PAD圖等圖形工具。

2.表格工具

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

（2）判定樹：是判定表的變種，它也能夠清晰地表示復(fù)雜的條件組合和應(yīng)做的

動作之間的對應(yīng)關(guān)系。

3語言工具

過程%計語言（PDL）：也稱偽碼，是一種介于自然語言和形式化語言之間的語

言，

用于描述功能模塊的算法設(shè)計和處理細節(jié)的語言。

特點：易編寫，易理解，容易轉(zhuǎn)化成源程序。

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

Jackson方法和Warnier方法。

6.4.1Jackson圖（會畫）（P133例題）

邏輯數(shù)據(jù)結(jié)構(gòu)：順序結(jié)構(gòu)、選擇結(jié)構(gòu)、重復(fù)結(jié)構(gòu)

Jackson圖的優(yōu)點：（1）形象直觀可讀性好（2）既能表示數(shù)據(jù)結(jié)構(gòu)也能表示程

序結(jié)構(gòu)

6.5程序復(fù)雜程度的定量度量

1.計算環(huán)形復(fù)雜度的3種方■法

（1）數(shù)圖上的區(qū)域個數(shù)（2）等于判定結(jié)點數(shù)+1（最優(yōu)）（3）邊數(shù)一結(jié)點數(shù)+2

2.環(huán)形復(fù)雜度的用途（P138）

第七章實現(xiàn)

7.1編碼/7.1.2編碼風(fēng)格（理解），重點看（P148/5.效果）

7.2軟件測試基礎(chǔ)

7.2.1軟件測試的目標(biāo)

Myers給出的軟件測試的目的

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

（2）好的測試方案是極可能發(fā)現(xiàn)迄今為止尚未發(fā)現(xiàn)的錯誤的測試方案。

（3）成功的測試是發(fā)現(xiàn)了至今為止尚未發(fā)現(xiàn)的錯誤的測試

總之，測試的目的是以最少的時間和人力，系統(tǒng)地找出軟件中潛在的各種錯誤和

缺陷；

測試附帶的收獲是它能證明軟件的功能和性能與需求說明相符合.

說明：測試不能表明軟件中不存在錯誤，它只能說明軟件中存在錯誤。

7.2.3測試方法

軟件測試方法一般分為：靜態(tài)測試盒動態(tài)測試。

靜態(tài)測試：是指被測程序不在機器上運行，采用人工測試和計算機輔助靜態(tài)分析

的手段對程序進行檢測。

動態(tài)測試：是指通過運行程序發(fā)現(xiàn)錯誤，又分白盒測試和黑盒測試。

（1）已知產(chǎn)品應(yīng)該具有的功能，可以通過“黑盒測試”來檢驗每個功能是否符

合設(shè)計要求。

（2）己知產(chǎn)品的內(nèi)在工作過程，可以通過“白盒測試”來檢驗每種內(nèi)部操作是

否按要求的規(guī)定正常進行。

73單元測試

7.3.1測試重點

單元測試方法有哪些？（5個）

（1）模塊接口測試（2）局部數(shù)據(jù)結(jié)構(gòu)測試

（3）路徑測試（重要的執(zhí)行通路）（4）出錯處理測試（5）邊界測試

7.3.2代碼審查（屬于靜態(tài)測試）（P154）

7.4集成測試

7.4.4回歸測試

回歸測試定義：指集成測試中，重新執(zhí)行已經(jīng)做過測試的某個子集，

以保證上述這些變化沒有帶來非預(yù)期的副作用。

先采取自頂向下的方式測試被修改的模塊及其子模塊；然后將這一部分視為子系

統(tǒng)，再自低向上測試。

7.5確認測試

1.確認測試的依據(jù)？

需求分析階段產(chǎn)生的軟件需求規(guī)格說明書，準(zhǔn)確的描述了用戶對軟件的合理期

望，

因此是軟件有效性的標(biāo)準(zhǔn)，也是進行確認測試的基礎(chǔ)。

753人舊1^和8戊2測試（適應(yīng)：為多個用戶開發(fā)的軟件）

Alpha測試：由用戶在開發(fā)環(huán)境下進行的測試。

Bela測試：由最終用戶在實際使用環(huán)境下進行的測試，這些用戶定期返回有關(guān)錯

誤信息給開發(fā)者。

注意：只有當(dāng)Alpha測試達到一定的可靠程度時，才開始Beta測試。

7.6白盒測試技術(shù)

所謂測試方案包括具體的測試目的（例如，預(yù)定要測試的具體功能），應(yīng)該輸入

的測試數(shù)據(jù)和預(yù)期的結(jié)果。

通常又把測試數(shù)據(jù)和預(yù)期的輸出結(jié)果稱為測試用例。

7.6.1邏輯覆蓋

邏輯覆蓋有幾種（出題）

邏輯覆蓋是以程序內(nèi)部的邏輯結(jié)構(gòu)為基礎(chǔ)設(shè)計測試用例的技術(shù)。

包括：語句覆蓋、判定覆蓋、條件覆蓋、判定-條件覆蓋、條件組合覆蓋、

點覆蓋、邊覆蓋、路徑覆蓋

7.6.2控制結(jié)構(gòu)測試

1.基本路徑測試（P166例題）

以環(huán)形復(fù)雜度為基礎(chǔ)，導(dǎo)出基木可執(zhí)行路徑集合，設(shè)計測試用例的方法。測試用

例要保證程序的可執(zhí)行語句執(zhí)行一-次。

使用基本路徑測試技術(shù)設(shè)計測試用例的步驟：

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

（2）計算流圖的環(huán)形復(fù)雜度。

（3）確定線性獨立路經(jīng)的基本集合。

（4）設(shè)計可強制執(zhí)行基本集合中每條路徑的測試用例。（包括路徑1-6的測試用

例）

7.7黑盒測試技術(shù)

7.7.1等價劃分（P172）/7.7.2邊界值分析（P175）

7.9軟件可靠性

軟件可靠性的定義：

程序在給定的時間間隔內(nèi)，按照規(guī)格說明書的規(guī)定成功地運行的概率。

隨著運行時間的增加，運行時出現(xiàn)程序故障的概率也將增加，即可靠性隨著給定

的時間間隔的加大而減少。

第八章維護

軟件維護需要的工作量很大，平均來說，大型軟件的維護成本高達開發(fā)成本的四

倍左右。

8.1軟件維護的定義

軟件維護的定義：就是在軟件已經(jīng)交付使用之后，為了改正錯誤或者滿足新的需

求而修改軟件的過程。

分為4類：改正性維護、適應(yīng)性維護、完善性維十、預(yù)防性維護。

各種維護類型及維護工作量的比例：

完善性維護（50%-66%）、改正性維護（17%?21%）、

適應(yīng)性維護（18%-25%）、其他維護活動（4%左右）

8.4軟件的可維護性

8.4.1決定軟件可維護性的因素

決定軟件可維護性的因素：（5個）

（I）可理解性（2）互測試性（3）可修改性（4）可移植性（5）可重用性

8.4.2文檔（包括系統(tǒng)文檔和用戶文檔）

文檔作用：文檔是影響軟件可維護性的決定因素。

用戶文檔：主要描述系統(tǒng)功能和使用方法，并不關(guān)心這些功能是怎樣實現(xiàn)的。

系統(tǒng)文檔：描述系統(tǒng)設(shè)計、實現(xiàn)和測試等各種方面的內(nèi)容。

總體來說，軟件文檔應(yīng)該滿足下述要求：

（1）必須描述如何使用這個系統(tǒng)，沒有這種描述時即使是最簡單的系統(tǒng)也無法

使用。

（2）必須描述怎樣安裝和管理這個系統(tǒng)。

（3）必須描述系統(tǒng)需求和設(shè)計。

（4）必須描述系統(tǒng)的實現(xiàn)和測試，以便使系統(tǒng)成為可維護的。

第九章面向?qū)ο蠓椒▽W(xué)引論

9.2面向?qū)ο蟮母拍?/p>

9.2.2其他概念

7.繼承（P213）

單繼承：一個類只允許有一個父類，即類等級為樹形結(jié)構(gòu)。

多繼承：一個類允許有多個父類。

9.3面向?qū)ο蠼?/p>

用面向?qū)ο蠓椒ㄩ_發(fā)軟件，通常需要建立三種形式的模型，它們分別是：

描述系統(tǒng)數(shù)據(jù)結(jié)構(gòu)的市象模型、描述系統(tǒng)控制結(jié)構(gòu)的動態(tài)模型、描述系統(tǒng)功能的

功能模型。

9.4對象模型

9.4.1類圖的基本符號（P217）類圖描述類及類與類之間的靜態(tài)關(guān)系。

9.6功能模型

功能模型表示變化的系統(tǒng)的“功能”性質(zhì)，它指明了系統(tǒng)應(yīng)該“做什么”，

因此更直接的反映了用戶對目標(biāo)系統(tǒng)的需求。

使用“用例圖”描述（P224）

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

3種模型分別是：對象模型、功能模型、動態(tài)模型

3種模型之間的關(guān)系：

（1）對象模型描述了動態(tài)模型、功能模型所操作的數(shù)據(jù)結(jié)構(gòu)。

對象模型中的操作對應(yīng)于動態(tài)模型中事件和功能中的函數(shù)。

（2）動態(tài)模型描述了實現(xiàn)的控制結(jié)構(gòu)，告訴我們哪些結(jié)構(gòu)是依賴于對象值，

哪些引起對象的變化，并激活了函數(shù)。

（3）功能模型由數(shù)據(jù)流圖和用例圖組成，描述了對象模型中操作的含義、

動態(tài)模型中動作的意義以及對象模型中的約束的意義。

第十一章面向?qū)ο笤O(shè)計

11.2啟發(fā)規(guī)則

6個啟發(fā)規(guī)則：

（1）設(shè)計結(jié)果應(yīng)該清晰易懂。（2）一般.特殊結(jié)構(gòu)的深度應(yīng)適當(dāng)。

（3）設(shè)計簡單的類。（4）使用簡單的協(xié)議。

（5）使用簡單的服務(wù)。（6）把設(shè)計變動減至最小。

11.3軟件重用

11.3.1概述

1.重用的定義：

重用也叫再用或復(fù)用，是指同一事物不作修改或稍加改動就多次重復(fù)使用。

2.軟件成分的重用級別

軟件成分的重用可以進一步劃分成3個級別，級別由低到高分別是：

（1）代碼重用（2）設(shè)計結(jié)果重用（3）分析結(jié)果重用

第十二章面向?qū)ο髮崿F(xiàn)

12.2程序設(shè)計風(fēng)格

12.2.1提高可重用性

提高可重用性的主要規(guī)則（7條）:

（1）提高方法的內(nèi)聚（2）減小方法的規(guī)模

（3）保持方法的一致性（4）把策略與實現(xiàn)分開

（5）全面覆蓋（6）盡量不使用全局信息

（7）利用繼承機制

第十三章軟件項目管理

13.3進度計劃

13.3.2Gantt圖（Gantt圖的優(yōu)缺點）

優(yōu)點：直觀簡明，容易掌握，容易繪制。

缺點：（1）不能顯式地描繪各項作業(yè)彼此間的依賴關(guān)系。

（2）進度計劃的關(guān)鍵部分不明確，難于判定哪些部分應(yīng)當(dāng)是主攻和主控的對象。

（3）計劃中有潛力的部分及潛力的大小不明確，往往造成潛力的浪費。

13.3.2工程網(wǎng)絡(luò)（工程網(wǎng)絡(luò)的優(yōu)缺點）（P315）

工程網(wǎng)絡(luò)是制定進度計劃時另一種常用的圖形工具，它同樣能描繪任務(wù)分解情況

以及

每項作業(yè)的開始時間和結(jié)束時間，此外，它還顯式的描繪了各個作業(yè)彼此間的依

賴關(guān)系。

因此，工程網(wǎng)絡(luò)是系統(tǒng)分析和系統(tǒng)設(shè)計的強有力的工具。

13.4人員組織

人員組織的3種方式：

民主程序員組、主程序員組、現(xiàn)代程序員組

13.5質(zhì)量保證

13.5.1軟件質(zhì)量

1.軟件質(zhì)量的定義：軟件質(zhì)量就是“軟件與明確地和隱含地定義的需求相一致的

程度

更具體的說，軟件質(zhì)量是軟件與明確地敘述的功能和性能需求、文檔中明確描述

的開發(fā)標(biāo)準(zhǔn)

以及任何專業(yè)開發(fā)的軟件產(chǎn)品都應(yīng)該具有的隱含恃征相一致的程度。

上述定義強調(diào)了下述的3個要點：

（1）軟件需求是度量軟件質(zhì)量的基礎(chǔ)，與需求不一致就是質(zhì)量不高。

（2）指定的開發(fā)標(biāo)準(zhǔn)定義了一組指導(dǎo)軟件開發(fā)的準(zhǔn)則，如果沒有遵守這些準(zhǔn)則,

肯定會導(dǎo)致軟件質(zhì)量不高。

（標(biāo)準(zhǔn)有：國家標(biāo)準(zhǔn)、國際標(biāo)準(zhǔn)、行'也標(biāo)準(zhǔn)、企業(yè)標(biāo)準(zhǔn)）

（3）通常，有一組沒有顯式描述的隱含需求（例如，軟件應(yīng)該是容易維護的）。

如果軟件滿足明確描述的需求，當(dāng)卻不滿足隱含的需求，那么軟件的質(zhì)量仍然是

值得懷疑的。

2.軟件質(zhì)量因素的定義（P325表）

裳13.7軟件質(zhì)■因素的定義

質(zhì)?因索_______定義

系統(tǒng)滿足規(guī)格說明和用戶目標(biāo)的程度.即,在定環(huán)境下儺正確地完成預(yù)期功能

正確性

的程度

在硬件發(fā)生故障、輸入的數(shù)據(jù)無效或操祚錯設(shè)等意外環(huán)境下?系統(tǒng)能做出適當(dāng)響

健壯性

應(yīng)的曾度

為了完成預(yù)定的功能，系統(tǒng)需要的計算資源的多少

完整性

對未經(jīng)授權(quán)的人使用軟件或數(shù)據(jù)的企圖，系統(tǒng)能修控制（禁止）的程度

（安全性）

可用性系統(tǒng)在完成預(yù)定應(yīng)該完成的功能時令人清意的程度

風(fēng)般按預(yù)定的成本和進度把系統(tǒng)開發(fā)出來?并且為用戶所滿意的慨率

可理解性理解和使用該系統(tǒng)的容易程度

可維修性診斷和改正在運行現(xiàn)場發(fā)現(xiàn)的錯誤所需要的工作量的大小

靈活性