第一章：

軟件工程定義：

1968年10月，Fritz Bauer 首次提出了“軟件工程”的概念，并將“軟件工程”定義為：為了經(jīng)濟(jì)地獲得能夠在實(shí)際機(jī)器上有效運(yùn)行的可靠軟件，而建立并使用的一系列工程化原則。

1993年IEEE對(duì)軟件工程的定義：軟件工程是將系統(tǒng)化的、規(guī)范化的、可度量的途徑應(yīng)用于軟件的開(kāi)發(fā)、運(yùn)行和維護(hù)的過(guò)程，即將工程化應(yīng)用于軟件的方法的研究。

軟件工程原則：

抽象與自頂向下，逐層細(xì)化 ?信息隱蔽和數(shù)據(jù)封裝 模塊化 局部化 確定性 一致性和標(biāo)準(zhǔn)化 完備性和可驗(yàn)證性

瀑布模型：

開(kāi)發(fā)活動(dòng)的特征：（1）以上一項(xiàng)活動(dòng)方產(chǎn)生的工作對(duì)象為輸入(2)利用這一輸入,實(shí)施本項(xiàng)活動(dòng)應(yīng)完成的內(nèi)容(3)給出該項(xiàng)活動(dòng)的工作結(jié)果,作為輸出傳給下一項(xiàng)活動(dòng)(4)對(duì)實(shí)施該項(xiàng)活動(dòng)的工作結(jié)果進(jìn)行評(píng)審,若其工作得到確認(rèn),則繼續(xù)進(jìn)行下一項(xiàng)活動(dòng),否則返回前項(xiàng),甚至更前項(xiàng)的活動(dòng)進(jìn)行返工

瀑布模型的優(yōu)點(diǎn):

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

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

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

(1)由于瀑布模型幾乎完全依賴于書(shū)面的規(guī)格說(shuō)明,很可能導(dǎo)致最終開(kāi)發(fā)出的軟件產(chǎn)品不能真正滿足用戶的需要。如果需求規(guī)格說(shuō)明與用戶需求之間有差異,就會(huì)發(fā)生這種情況(2)瀑布模型只適用于項(xiàng)目開(kāi)始時(shí)需求已確定的情況。總地來(lái)說(shuō),瀑布模型是一種應(yīng)付需求變化能力較弱的開(kāi)發(fā)模型,因此,很多在該模型基礎(chǔ)上開(kāi)發(fā)出來(lái)的軟件產(chǎn)品不能夠真正滿足用戶需求

第二章：

可行性研究的過(guò)程：

復(fù)查系統(tǒng)規(guī)模和目標(biāo)

復(fù)查系統(tǒng)定義，改正含糊或不確切的敘述，清晰地描述對(duì)目標(biāo)系統(tǒng)的一切限制和約束

研究目前正在使用的系統(tǒng)

現(xiàn)有的系統(tǒng)是信息的重要來(lái)源。若一個(gè)軟件是對(duì)舊系統(tǒng)的改造，那開(kāi)發(fā)新系統(tǒng)時(shí)，要充分了解老系統(tǒng)存在的問(wèn)題，需要增加的功能，新系統(tǒng)實(shí)際上是老系統(tǒng)的部分功能加上一些新增功能形成的系統(tǒng)

導(dǎo)出新系統(tǒng)的高層邏輯模型

重新定義問(wèn)題

新系統(tǒng)的邏輯模型實(shí)質(zhì)上表達(dá)了分析員對(duì)系統(tǒng)必須做什么的看法，得到新系統(tǒng)的高層邏輯模型之后，可能會(huì)發(fā)現(xiàn)前面問(wèn)題定義的范疇過(guò)大，分析員還要和用戶一起再?gòu)?fù)查問(wèn)題定義，對(duì)問(wèn)題進(jìn)行重新定義和修正。

導(dǎo)出和評(píng)價(jià)供選擇的解法

分析員應(yīng)該從系統(tǒng)邏輯模型出發(fā)，研究問(wèn)題的幾個(gè)組成部分，細(xì)化各功能點(diǎn)，導(dǎo)出若干個(gè)較高層次的物理解法供比較和選擇

推薦行動(dòng)方針

草擬開(kāi)發(fā)計(jì)劃

任務(wù)分解 進(jìn)度規(guī)劃 財(cái)務(wù)預(yù)算 風(fēng)險(xiǎn)分析及對(duì)策

書(shū)寫(xiě)文檔提交復(fù)查

第三章：

一.軟件需求的定義：

以清晰、簡(jiǎn)單、一致且無(wú)二義性的方式，描述用戶對(duì)目標(biāo)軟件系統(tǒng)在功能、行為、性能、設(shè)計(jì)約束等方面的期望，是在開(kāi)發(fā)過(guò)程中對(duì)軟件系統(tǒng)的約束。

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

業(yè)務(wù)需求：是客戶對(duì)于軟件系統(tǒng)的高層次目標(biāo)要求，定義了項(xiàng)目的遠(yuǎn)景和范圍

用戶需求：從用戶角度描述軟件系統(tǒng)的功能需求與非功能需求，通常只涉及系統(tǒng)的外部行為。

功能需求：功能需求描述軟件系統(tǒng)應(yīng)該提供的功能或務(wù),通常涉及用戶或其他外部系統(tǒng)與目標(biāo)系統(tǒng)之間的交互,不考慮目標(biāo)系統(tǒng)內(nèi)部的實(shí)現(xiàn)細(xì)節(jié)

非功能需求：非功能需求即性能需求，反映了客戶對(duì)軟件系統(tǒng)質(zhì)量和性能的額外要求

約束條件： 約束條件是軟件系統(tǒng)設(shè)計(jì)和實(shí)現(xiàn)時(shí)必須滿足的限制條件

業(yè)務(wù)規(guī)則： 業(yè)務(wù)規(guī)則是對(duì)某些功能的可執(zhí)行性成內(nèi)部執(zhí)行速制的一些限定條件

外部接口需求:??? 外部接口需求是描述目標(biāo)系統(tǒng)與外部環(huán)境之間的交互接口

數(shù)據(jù)定義:當(dāng)用戶描達(dá)一個(gè)數(shù)據(jù)項(xiàng)或一個(gè)復(fù)雜的業(yè)務(wù)數(shù)據(jù)結(jié)構(gòu)的格式或缺省值時(shí),正在進(jìn)行數(shù)據(jù)定義

第四章：

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

啟發(fā)規(guī)則是軟件結(jié)構(gòu)設(shè)計(jì)優(yōu)化準(zhǔn)則，軟件概要設(shè)計(jì)的任務(wù)就是軟件結(jié)構(gòu)的設(shè)計(jì)，為了提高設(shè)計(jì)的質(zhì)量，必須根據(jù)軟件設(shè)計(jì)原理設(shè)計(jì)軟件，利用啟發(fā)規(guī)則優(yōu)化軟件結(jié)構(gòu)。

1.改進(jìn)軟件結(jié)構(gòu)提高模塊獨(dú)立性2.模塊規(guī)模適中3.適當(dāng)控制深度、寬度、扇出、扇入

4.模塊的作用域應(yīng)該在控制域之內(nèi)5.力爭(zhēng)降低模塊接口的復(fù)雜程度

6.設(shè)計(jì)單入口單出口的模塊7.模塊功能可預(yù)測(cè)

第五章：

詳細(xì)設(shè)計(jì)的過(guò)程

軟作詳細(xì)設(shè)計(jì)是軟件工程的重要階段,在詳細(xì)設(shè)計(jì)過(guò)程中,細(xì)化了高層的體系結(jié)構(gòu)設(shè)計(jì)，將軟件結(jié)構(gòu)中的主要部件劃分為能獨(dú)立編碼、編譯和測(cè)試的軟件單元,并進(jìn)行軟件單元的設(shè)計(jì),同時(shí)確定了軟件單元和單元之間的外部接口。

一.詳細(xì)設(shè)計(jì)的基本任務(wù)：

算法設(shè)計(jì):用某種圖形、表格、語(yǔ)言等工具將每個(gè)模塊處理過(guò)程的詳細(xì)算法描述出來(lái)

數(shù)據(jù)結(jié)構(gòu)設(shè)計(jì):對(duì)于需求分析,概要設(shè)計(jì)確定的概念性的數(shù)據(jù)類(lèi)型進(jìn)行確切的定義

物理設(shè)計(jì)： 對(duì)數(shù)據(jù)庫(kù)進(jìn)行物理設(shè)計(jì),即確定數(shù)據(jù)庫(kù)的物理結(jié)構(gòu)

其他設(shè)計(jì)

a.代碼設(shè)計(jì)：為了提高數(shù)據(jù)的輸入、分類(lèi)、存儲(chǔ)及檢索等操作的效率,對(duì)數(shù)據(jù)庫(kù)中的某些數(shù)據(jù)項(xiàng)的值要進(jìn)行代碼設(shè)計(jì)b.輸入/輸出格式設(shè)計(jì)c.人機(jī)對(duì)話設(shè)計(jì)

編寫(xiě)詳細(xì)設(shè)計(jì)說(shuō)明書(shū) ?6 . 評(píng)審：對(duì)處理過(guò)程的算法和數(shù)據(jù)庫(kù)的物理結(jié)構(gòu)要進(jìn)行評(píng)審

二.詳細(xì)設(shè)計(jì)方法：

自頂向下，逐步求精 ?2.具有單入、單出的控制結(jié)構(gòu) 3. 五種控制結(jié)構(gòu)：順序結(jié)構(gòu)，選擇，先判斷型循環(huán)結(jié)構(gòu)，后斷型循環(huán)結(jié)構(gòu)，多選擇分支結(jié)構(gòu)

第七章：

一．測(cè)試用例設(shè)計(jì)：

白盒測(cè)試是對(duì)軟件的過(guò)程細(xì)節(jié)做細(xì)致的檢查。這一方法把測(cè)試對(duì)象看作 個(gè)打開(kāi)的盒子，允許測(cè)試人員利用程序內(nèi)部的邏輯結(jié)構(gòu)及有關(guān)信息設(shè)計(jì)或選擇測(cè)試用例，對(duì)程序所有邏輯路徑進(jìn)行測(cè)試。通過(guò)在不同點(diǎn)檢查程序的狀態(tài),確定實(shí)際的狀態(tài)是否與期望的狀態(tài)一致。

覆蓋標(biāo)準(zhǔn)：

語(yǔ)句覆蓋

含義：就是選擇足夠多的測(cè)試用例，運(yùn)行被測(cè)程序，使得程序中每條語(yǔ)句至少執(zhí)行一次。

判定覆蓋

含義：又稱(chēng)為分支覆蓋，在設(shè)計(jì)測(cè)試用例，針對(duì)程序中具有分支結(jié)構(gòu)的部分，為了測(cè)試所有的可能結(jié)果，需要將每個(gè)分支都至少執(zhí)行一次，查看相應(yīng)的語(yǔ)句執(zhí)行情況和結(jié)果

(1)a=2,b=0,x=4,覆蓋RACBDE

(2)a=3,b=1,x=1覆蓋 RABE

條件覆蓋

條件覆蓋是指設(shè)計(jì)測(cè)試用例時(shí),除了保證每條語(yǔ)句執(zhí)行一次,還要使判定表達(dá)式的每個(gè)條件的各種可能取值都至少執(zhí)行一次,為了實(shí)現(xiàn)條件覆蓋,保證各種可能的條件都取值,即保證

第一個(gè)判斷有以下取值:a>1,a<=1,b=0,b≠0

第二個(gè)判斷有以下取值:a=2,a≠2,x>1,x<=1

選擇兩組測(cè)試用例:

(1)a=2,b=2,x=2(滿足a>1,b≠0,a=2,x>1的條件),執(zhí)行路徑為 RABDE

(2)a=1,b=0,x=0(滿足a<=1,b=0,a≠2,x<=1的條件),執(zhí)行路徑為RABE

判定/條件覆蓋

單獨(dú)使用判定覆蓋和條件覆蓋測(cè)試結(jié)果都不夠全面, 若將兩種覆蓋結(jié)合，就會(huì)相互補(bǔ)充,判定/條件覆蓋就是設(shè)計(jì)足夠多的測(cè)試用例，使得每個(gè)判定表達(dá)式中的每個(gè)條件都取到各種可能的值,并且使每個(gè)判斷語(yǔ)句的所有判斷結(jié)果至少出現(xiàn)一次。

(1)a=2,b=0,x=2(滿足a>1,b=0,a=2,x>1的條件)，執(zhí)行路徑RACBDE

(2)a=1,b=1,x=1(滿足a<=1,b≠0,a≠2,x<=1的條件)，執(zhí)行路徑RABE

條件組合覆蓋

條件組合覆蓋就是設(shè)計(jì)足夠多的測(cè)試用例,使得每個(gè)判定表達(dá)式中條件取值的各種組合都至少出現(xiàn)一次。根據(jù)每個(gè)判定表達(dá)式情況,列出如下條件組合

(1)a>1,b=0,A表達(dá)式為真;(2)a>1,b≠0,A表達(dá)式為假;(3)a<=1,b=0,A表達(dá)式為假

(4)a<=1,b≠0,A表達(dá)式為假;(5)a=2,x>1,B表達(dá)式為真(6)a=2,x<=1,B表達(dá)式為真;

(7)a≠2,x>1,B表達(dá)式為真;(8)a≠2,x<=1,B表達(dá)式為假。

選擇以下四組測(cè)試用例

選擇條件a=2,b=0,x=2,(1)、(5)組合,執(zhí)行路徑 RACBDE

選擇條件a=2,b=1,x=1,(2)、(6)組合,執(zhí)行路徑 RABDE

選擇條件a=1,b=0,x=2,(3)、(7)組合,執(zhí)行路徑 RABDE

選擇條件a=1,b=1,x=1,(4)、(8)組合,執(zhí)行路徑 RABE

路徑覆蓋

就是選取足夠多的用例，保證程序的所有路徑都至少執(zhí)行一次，如果存在環(huán)形結(jié)構(gòu)，也要保證此環(huán)的所有路徑都至少執(zhí)行一次。

(1)a=1,b=1,x=1(滿足a<=1,b≠0,a≠2,x<=1的條件),執(zhí)行路徑為RABE

(2)a=2,b=0,x=2(滿足a>1,b=0,a=2,x>1的條件),執(zhí)行路徑為 RACBDE

(3)a=2,b=1,x=2(滿足a>1,b≠0,a=2,x>1的條件),執(zhí)行路徑為 RABDE;

(4)a=3,b=0,x=1(滿足a>1,b=0,a≠2,x<=1的條件),執(zhí)行路徑為 RACBE

二．測(cè)試的步驟：

單元測(cè)試

a.單元測(cè)試的主要任務(wù)

單元測(cè)試針對(duì)每個(gè)模塊,主要解決五個(gè)方面的問(wèn)題：(1)模塊接口(2)局部數(shù)據(jù)結(jié)構(gòu)（3）路徑測(cè)試 (4)過(guò)界條件 (5)出錯(cuò)處理

b.單元測(cè)試的執(zhí)行過(guò)程

集成測(cè)試

a.非增式集成測(cè)試方法 b. 增式集成測(cè)試方法

確認(rèn)測(cè)試

確認(rèn)測(cè)試的標(biāo)準(zhǔn) ?配置審查的內(nèi)容 ?Alpha Beta 測(cè)試 ?

系統(tǒng)測(cè)試

方法：恢復(fù)測(cè)試方法 ??安全測(cè)試方法 ?強(qiáng)度 ?性能

第八章：

一．軟件維護(hù)的概念

軟件維護(hù)是指在軟件運(yùn)行或維護(hù)階段對(duì)軟件產(chǎn)品所進(jìn)行的修改,這些修改可能是改

正軟件中的錯(cuò)誤,也可能是增加新的功能以適應(yīng)新的需求,但是一般不包括軟件系統(tǒng)結(jié)

構(gòu)上的重大改變。根據(jù)軟件維護(hù)的不同原因,軟件維護(hù)可以分成四種類(lèi)型

(1)改正性維護(hù)

在軟件交付使用后,由于開(kāi)發(fā)時(shí)測(cè)試得不徹底或不完全,在運(yùn)行階段會(huì)暴露一些開(kāi)

發(fā)時(shí)未能測(cè)試出來(lái)的錯(cuò)誤,為了識(shí)別和糾正軟件錯(cuò)誤,改正軟件性能上的缺陷,避免實(shí)

施中的錯(cuò)誤使用,應(yīng)當(dāng)進(jìn)行的診斷和改正錯(cuò)誤的過(guò)程,這就是改正性維護(hù)

(2)適應(yīng)性維護(hù)

隨著計(jì)算機(jī)技術(shù)的飛速發(fā)展和更新?lián)Q代,軟件系統(tǒng)所需的外部環(huán)境或數(shù)據(jù)環(huán)境可能

會(huì)更新和升級(jí),如操作系統(tǒng)或數(shù)據(jù)庫(kù)系統(tǒng)的更換等。為了使軟件系統(tǒng)適應(yīng)這種變化,需

要對(duì)軟件進(jìn)行相應(yīng)的修改,這種維護(hù)活動(dòng)稱(chēng)為適應(yīng)性維護(hù)

(3)完善性維護(hù)

在軟件的使用過(guò)程中,用戶往往會(huì)對(duì)軟件提出新的功能與性能要求,為了滿足這些

要求,需要修改或再開(kāi)發(fā)軟件,以擴(kuò)充軟件功能、增強(qiáng)軟件性能、改進(jìn)加工效率、提高軟件

的可維護(hù)性,這種情況下進(jìn)行的維護(hù)活動(dòng)叫作完善性維護(hù),完善性維護(hù)不一定是救火

式的緊急維修,而可以是有計(jì)劃的一種再開(kāi)發(fā)活動(dòng)

4)預(yù)防性地護(hù)

這類(lèi)維護(hù)是為了提高軟件的可維護(hù)性,可靠性等,為以后進(jìn)一步改進(jìn)軟件打下良好

的基礎(chǔ)的維護(hù)活動(dòng),具體來(lái)講,就是采用先進(jìn)的軟件工程方法對(duì)需要維護(hù)的軟件或軟件中的某一部分重新設(shè)計(jì)、編碼和測(cè)試的活動(dòng)。

二．軟件維護(hù)的特點(diǎn)

1.軟件維護(hù)受開(kāi)發(fā)過(guò)程影響大

2.軟件維護(hù)困難多

3.軟件維護(hù)成本高

三．軟件維護(hù)的步驟

軟件維護(hù)工作包括建立維護(hù)組織、報(bào)告與評(píng)估維護(hù)申請(qǐng)、實(shí)施維護(hù)流程等步驟。

在影響分析和版本規(guī)劃的過(guò)程中,不同的維護(hù)類(lèi)型需要采用不同的維護(hù)策略

（1）改正性維護(hù):首先應(yīng)該評(píng)價(jià)軟件錯(cuò)誤的嚴(yán)重程度,對(duì)于十分嚴(yán)重的錯(cuò)誤,維護(hù)

員應(yīng)該立即實(shí)施維護(hù)對(duì)于一般性的錯(cuò)誤,維護(hù)人員可以將有關(guān)的維護(hù)工作與其他開(kāi)發(fā)

任務(wù)一起進(jìn)行現(xiàn)劃。在有些情況下,有的錯(cuò)誤非常嚴(yán)重,以致不得不臨時(shí)放棄正常的維

護(hù)控制工作程序,既不對(duì)修改可能帶來(lái)的副作用作出評(píng)價(jià),也不對(duì)文檔作相應(yīng)的更新,而

是立即進(jìn)行代碼的修改。這是一種救火式的改正性維護(hù),只有在非常緊急的情況下才使

用,這種維護(hù)在全部維護(hù)中只占很小的比例。應(yīng)當(dāng)說(shuō)明的是,救火式不是取消,只是推遲

了維護(hù)所需要的控制和評(píng)價(jià)。一旦危機(jī)取消,這些控制和評(píng)價(jià)活動(dòng)必須進(jìn)行,以確保當(dāng)

前的修改不會(huì)增加更為重要的問(wèn)題

(2)適應(yīng)性維護(hù):首先確定軟件維護(hù)的優(yōu)先順序,再與其他開(kāi)發(fā)任務(wù)一起進(jìn)行規(guī)劃

(3)定善性維護(hù),根據(jù)商業(yè)的需求和軟件的發(fā)展，有些完善性維護(hù)可能不會(huì)被接受。對(duì)于被接受的維護(hù)中請(qǐng),應(yīng)該確定其優(yōu)先次序井現(xiàn)劃其開(kāi)發(fā)工作

第九章

質(zhì)量保證

產(chǎn)品的生命，不論生產(chǎn)何種產(chǎn)品，質(zhì)量都是極端重要的。軟件產(chǎn)品開(kāi)發(fā)周期長(zhǎng)，耗費(fèi)巨大的人力和物力，更必須特別注意保證質(zhì)量。

軟件質(zhì)量：概括地說(shuō)，軟件質(zhì)量就是“軟件與明確地和隱含地定義的需求相一致的程度”。更具體地說(shuō)，軟件質(zhì)量是軟件與明確地?cái)⑹龅墓δ芎托阅苄枨蟆⑽臋n中明確描述的開(kāi)發(fā)標(biāo)準(zhǔn)以及任何專(zhuān)業(yè)開(kāi)發(fā)的軟件產(chǎn)品都應(yīng)該具有的隱含特征相一致的程度。

軟件質(zhì)量因素的定義：

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

建壯性：在硬件發(fā)生故障、輸人的數(shù)據(jù)無(wú)效或操作錯(cuò)誤等意外環(huán)境下,系統(tǒng)能做出適當(dāng)響應(yīng)的程度

完整性(安全性)：對(duì)未經(jīng)授權(quán)的人使用軟件或數(shù)據(jù)的企圖,系統(tǒng)能夠控制(禁止)的程度

效率：為了完成預(yù)定的功能,系統(tǒng)需要的計(jì)算資源的多少

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

風(fēng)險(xiǎn)：按預(yù)定的成本和進(jìn)度把系統(tǒng)開(kāi)發(fā)出來(lái),并且為用戶所滿意的概率

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

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

靈活性(適應(yīng)性)：修改或改進(jìn)正在運(yùn)行的系統(tǒng)需要的工作量的多少

可測(cè)試性：軟件容易測(cè)試的程度

可移植性：把程序從一種硬件配置和(或)軟件系統(tǒng)環(huán)境轉(zhuǎn)移到另一種配置和環(huán)境時(shí),需要的工作量多少,有一種定量度量的方法是:用原來(lái)程序設(shè)計(jì)和調(diào)試的成本除移植時(shí)需用的費(fèi)用

可再用性：在其他應(yīng)用中該程序可以被再次使用的程度(或范圍)

互運(yùn)行性：把該系統(tǒng)和另一個(gè)系統(tǒng)結(jié)合起來(lái)需要的工作量的多少

軟件質(zhì)量保證的措施主要有：基于非執(zhí)行的測(cè)試（也稱(chēng)為復(fù)審或評(píng)審），基于執(zhí)行的測(cè)試（即以前講過(guò)的軟件測(cè)試）和程序正確性證明。

復(fù)審主要用來(lái)保證在編碼之前各階段產(chǎn)生的文檔的質(zhì)量；基于執(zhí)行的測(cè)試需要在程序編寫(xiě)出來(lái)之后進(jìn)行，它是保證軟件質(zhì)量的最后一道防線；程序正確性證明使用數(shù)學(xué)方法嚴(yán)格驗(yàn)證程序是否與對(duì)它的說(shuō)明完全一致

技術(shù)復(fù)審的必要性：

正式技術(shù)復(fù)審的顯著優(yōu)點(diǎn)是，能夠較早發(fā)現(xiàn)軟件錯(cuò)誤，從而可防止錯(cuò)誤被傳播到軟件過(guò)程的后續(xù)階段。

正式技術(shù)復(fù)審是軟件質(zhì)量保證措施的一種，包括走查和審查等具體方法。走查的步驟比審查少，而且沒(méi)有審查正規(guī)。

走查主要有下述兩種方式。

（1） 參與者驅(qū)動(dòng)法。參與者按照事先準(zhǔn)備好的列表，提出他們不理解的術(shù)語(yǔ)和認(rèn)為不正確的術(shù)語(yǔ)。文檔編寫(xiě)組的代表必須回答每個(gè)質(zhì)疑，要么承認(rèn)確實(shí)有錯(cuò)誤，要么對(duì)質(zhì)疑做出解釋。

（2） 文檔驅(qū)動(dòng)法。文檔編寫(xiě)者向走查組成員仔細(xì)解釋文檔。走查組成員在此過(guò)程中不時(shí)針對(duì)事先準(zhǔn)備好的問(wèn)題或解釋過(guò)程中發(fā)現(xiàn)的問(wèn)題提出質(zhì)疑。這種方法可能比第一種方法更有效，往往能檢測(cè)出更多錯(cuò)誤。經(jīng)驗(yàn)表明，使用文檔驅(qū)動(dòng)法時(shí)許多錯(cuò)誤是由文檔講解者自己發(fā)現(xiàn)的。

審查步驟：

（1） 綜述。由負(fù)責(zé)編寫(xiě)文檔的一名成員向?qū)彶榻M綜述該文檔。在綜述會(huì)結(jié)束時(shí)把文檔分發(fā)給每位與會(huì)者。

（2） 準(zhǔn)備。評(píng)審員仔細(xì)閱讀文檔。最好列出在審查中發(fā)現(xiàn)的錯(cuò)誤的類(lèi)型，并按發(fā)生頻率把錯(cuò)誤類(lèi)型分級(jí)，以輔助審查工作。這些列表有助于評(píng)審員們把注意力集中到最常發(fā)生錯(cuò)誤的區(qū)域。

（3） 審查。評(píng)審組仔細(xì)走查整個(gè)文檔。和走查一樣，這一步的目的也是發(fā)現(xiàn)文檔中的錯(cuò)誤，而不是改正它們。通常每次審查會(huì)不超過(guò)90分鐘。審查組組長(zhǎng)應(yīng)該在一天之內(nèi)寫(xiě)出一份關(guān)于審查的報(bào)告。

（4） 返工。文檔的作者負(fù)責(zé)解決在審查報(bào)告中列出的所有錯(cuò)誤及問(wèn)題。

（5） 跟蹤。組長(zhǎng)必須確保所提出的每個(gè)問(wèn)題都得到了圓滿的解決（要么修正了文檔，要么澄清了被誤認(rèn)為是錯(cuò)誤的條目）。必須仔細(xì)檢查對(duì)文檔所做的每個(gè)修正，以確保沒(méi)有引入新的錯(cuò)誤。如果在審查過(guò)程中返工量超過(guò)5%，則應(yīng)該由審查組再對(duì)文檔全面地審查一遍。

程序正確性證明：

測(cè)試可以暴露程序中的錯(cuò)誤，因此是保證軟件可靠性的重要手段；但是，測(cè)試只能證明程序中有錯(cuò)誤，并不能證明程序中沒(méi)有錯(cuò)誤。因此，對(duì)于保證軟件可靠性來(lái)說(shuō)，測(cè)試是一種不完善的技術(shù)，人們自然希望研究出完善的正確性證明技術(shù)。

?

?

創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎(jiǎng)勵(lì)來(lái)咯，堅(jiān)持創(chuàng)作打卡瓜分現(xiàn)金大獎(jiǎng)

總結(jié)

以上是生活随笔為你收集整理的看这玩意复习你还会挂科？《软件工程2篇》的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。