軟件工程實踐十質(zhì)量和風(fēng)險管理

北京理工大學(xué)

軟件工程實踐

湯銘端

中國航天科工集團公司706所

第十講

質(zhì)量管理與質(zhì)量保證

評審與審查

風(fēng)險管理

目的與內(nèi)容

-掌握質(zhì)量的概念

-了解質(zhì)量管理和質(zhì)量保證的內(nèi)容和過程

-掌握評審和審查的過程

-了解和掌握風(fēng)險管理的概念與過程

質(zhì)量管理

質(zhì)量的概念

■質(zhì)量定義：反映實體滿足明確和隱含需

要能力的特性綜合

■定義的說明：

■明確需要：指合同中用戶明確提出的要求與

W女

■隱含需要：指由生產(chǎn)企業(yè)通過市場調(diào)研進行

識別與探明的要求或需要

■特性：實體所特有的性質(zhì)，反映了實體滿足

需要的能力

軟件質(zhì)量的定義

■ANSI/IEEEStd729-1983定義軟件質(zhì)量

為“與軟件產(chǎn)品滿足規(guī)定的和隱含的需

爰的能方有關(guān)的特征或特性的全體”。

■M.J.Fisher定義軟件質(zhì)量為“所有描述

計算機軟件優(yōu)秀程度的特性的組合”。

s質(zhì)量特性及其組合

-為滿足軟件的各項精確定義的功能、性能需求，符合

文檔化的開發(fā)標(biāo)準(zhǔn)，需要相應(yīng)地給出或設(shè)計一些質(zhì)量

將性及其組合。

■如果這些質(zhì)量特性及其組合都能在產(chǎn)品中得到滿足，

則這個軟件產(chǎn)品質(zhì)量就是高的。

.軟件需求是度量軟件質(zhì)量的基礎(chǔ)。不符合需求的軟件

就不具備質(zhì)量。

-標(biāo)準(zhǔn)定義了一組開發(fā)準(zhǔn)則，用來指導(dǎo)軟件人員用工程

化的方法來開發(fā)軟件。如果不遵守這些開發(fā)準(zhǔn)則，軟

件質(zhì)量就得不到保證。

■軟件質(zhì)量是各種特性的復(fù)雜組合。它隨著應(yīng)用的不同

而不同，隨著用戶提出的質(zhì)量要求不同而不同。

什么是軟件質(zhì)量

軟件質(zhì)量的若干側(cè)面

4項目的質(zhì)量

■質(zhì)量的類型：■項目的質(zhì)量

-質(zhì)量，通常指產(chǎn)品的-從項目作為一次性的活

質(zhì)量，廣義的還包括動來看，項目質(zhì)量體現(xiàn)

工作的質(zhì)量。產(chǎn)品質(zhì)在由WBS反映出的項目

范圍內(nèi)所有的階段、子

量是指產(chǎn)品的使用價

項目、項目工作單元的

值及其屬性；

質(zhì)量所構(gòu)成，也即項目

-而工作質(zhì)量則是產(chǎn)品的工作質(zhì)量；

質(zhì)量的保證，它反映-從項目作為一項最終產(chǎn)

了與產(chǎn)品質(zhì)量直接有品來看，項目質(zhì)量體現(xiàn)

關(guān)的工作對產(chǎn)品質(zhì)量在其性能或者使用價值

的保證程度。上，也即項目的產(chǎn)品質(zhì)

量。

產(chǎn)品質(zhì)量與過程質(zhì)量

^^7

/i成本了\

i時間、進屋

影響產(chǎn)品質(zhì)量的4個方面

軟件質(zhì)量特性與模型

■軟件質(zhì)量特性，反映了軟件的本質(zhì)。討

論一個軟件的質(zhì)量，問題最終要歸結(jié)到

定義軟件的質(zhì)量特性。

-定義一個軟件的質(zhì)量，就等價于為該軟

件定義一系列質(zhì)量特性。

-人們通常把影響軟件質(zhì)量的特性用軟件

質(zhì)量模型來描述。

軟件質(zhì)量模型

■軟件質(zhì)量特性定義成分層模型

■最基本的叫做基本質(zhì)量特性，它可以由

一些子質(zhì)量特性定義和度量。

■二次特性在必要時又可由它的一些子質(zhì)

量特性定義和度量。

■1976年Boehm質(zhì)量模型

■1979年McCall質(zhì)量模型

■1985年ISO質(zhì)量模型

McCalI軟件質(zhì)量11特性

-使用性-測試性

■正確性-維護性

-可靠性■移植性

■效率-重用性

■完整性-互操作性

■適應(yīng)性

可維護性(Maintainability)互連性(interoperability)

可測試性(Testability)可移植性(Portability)

靈活性(Flexibility)復(fù)用性(Reusability)

PRODUCTPRODUCT

REVITIONTRANSITION

產(chǎn)品修正產(chǎn)品轉(zhuǎn)移

產(chǎn)品運行

PRODUCTOPERATIONS

正確性(Correctness)可靠性(Reliability)

可使用性(Usability)&率(Efficiency)

完整咫(Integrity)

Boehm質(zhì)量模型

ISO的軟件質(zhì)量評價模型

■按照ISO/TC97/SC7/WG3/1985-1-

30/N382,軟件質(zhì)量度量模型由三層組成

■軟件質(zhì)量需求評價準(zhǔn)則（SQRC）

-軟件質(zhì)量設(shè)計評價準(zhǔn)則（SQDC）

■軟件質(zhì)量度量評價準(zhǔn)則（SQMC）

-高層和中層建立國際標(biāo)準(zhǔn)，低層可由各

使用單位視實際情況制定

SQRCSQDCSQMC

可追蹤性

正確性完備性

一致性

準(zhǔn)確性（精確性）

可靠性容錯性（健壯性）使

簡單性《復(fù)雜性》

簡明性（可理解性）用

模塊獨立性

可維護性通用性單

可擴充性

自檢性《工具性》位

效率自描述性

執(zhí)行效率自

存儲效率

安全性存取控制行

存取審查

操作性制

靈活性

可訓(xùn)練性《培訓(xùn)性》

通信性定

可使用性軟件系統(tǒng)獨立性

機器獨立性

互連性通信共享性

數(shù)據(jù)共享性

（ISO/IEC9126，1991年）質(zhì)量特性

■質(zhì)量特性：功能性、可靠性、可維護性、

效率、可使用性、可移植性

■推薦21個子特性：適合性準(zhǔn)確性互用

性依從性安全性成熟性容錯性

可恢復(fù)性可理解性易學(xué)習(xí)性操作

性時間特性資源特性可分析性

穩(wěn)定性可變更性可測試性可安裝

性可替換性適應(yīng)性一致性

功能性可靠性可使用性效率可維護性可移植性

功能性△△

可靠性V△

可使用性VA△

效率VVV

可維護性△V△

可移植性VV

其中，△表示有利影響,V表示不利影響。

《質(zhì)量成本

-質(zhì)量成本是實施單位為了保證和提高產(chǎn)品質(zhì)量、滿

足用戶需要而支出的費用，以及因未達到質(zhì)量標(biāo)準(zhǔn)

而產(chǎn)生的一切損失費用的總和。

■簡單地說，質(zhì)量成本可被分成“一致成本”和“不

一致成一”

-一致成本包括：培訓(xùn)、指導(dǎo)、查證、確認(rèn)、測試、

維持、測量、審查等的費用

-不一致成本包括：損耗、返工、維修、產(chǎn)品回收、

投訴處理等的費用

-通過縮減一致成本來節(jié)省費用會帶來災(zāi)難性后果

■第一次要完全正確

另外的區(qū)分費用的通用方法

■預(yù)防成本

■關(guān)注第一個以及以后諸個無瑕疵產(chǎn)品對顧客需求滿足程度的預(yù)先

成本

■如設(shè)計評價、培訓(xùn)、QA、供給調(diào)查等預(yù)防活動

■評估成本

■評價產(chǎn)品或過程以確定如何滿足所有客戶需求相關(guān)的費用

■如產(chǎn)品檢查、測試、設(shè)計評審等

■內(nèi)部故障成本

■與滿足客戶需求在脫離組織控制前出現(xiàn)故障相關(guān)的費用

■如損耗、返工、維修、停工期、瑕疵評估、損耗評估等

■外部故障成本

■與那些需求沒能滿足的客戶的決定相關(guān)的費用

■如客戶退貨和補貼、客戶抱怨評估、檢查、調(diào)查、糾正等

總質(zhì)量成本

ri一

外部故障

評估

預(yù)防

當(dāng)前未來

最小化質(zhì)量總成本

■50%或更多的質(zhì)量成本

來自內(nèi)外部的故障

■故障的完全消除是一個

理想但非有效的解決方

案

■Juran：

■只要每單位的評價和預(yù)防

費用低于非一致成本，資

源會分配到預(yù)防和評價中

■當(dāng)預(yù)防和評價成本開始增

加每單位的質(zhì)量成本時，

策略是維持質(zhì)量不變

-最小化質(zhì)量總成本

100%次品最優(yōu)質(zhì)量成本100%

合格品

質(zhì)量管理的內(nèi)容

■質(zhì)量計劃戴明環(huán)—PDCA

■質(zhì)量控制■P：Plan-計戈U

■D：Do-實施

■質(zhì)量保證

-C：Check-檢查

■A：Action-處理

VD

D

質(zhì)量管理

■質(zhì)量管理即在質(zhì)量方面指揮和控制組織的協(xié)調(diào)活動

■質(zhì)量管理是指確定質(zhì)量方針、目標(biāo)和職責(zé)并在質(zhì)量體

系中通過諸如質(zhì)量策劃、質(zhì)量控制、質(zhì)量保證和質(zhì)量

改進并使其實施的全部管理職能的活動

-質(zhì)量方針

■質(zhì)量目標(biāo)

-質(zhì)量策劃

-質(zhì)量控制

-質(zhì)量保證

■質(zhì)量改進

戴明環(huán)—PDCA環(huán)

■P：Plan-計劃

■D：Do-實施

■C：Check-檢查

■A：Action-處理

<D

3

《質(zhì)量計劃

-質(zhì)量計劃的目的主要是確保項目的質(zhì)量

標(biāo)準(zhǔn)能夠得以滿意的實現(xiàn)，其關(guān)鍵是在

項目的計劃期內(nèi)確保項目按期完成，同

時要處理與其他項目計劃之間的關(guān)系。

質(zhì)量計劃的內(nèi)容

-需達到的質(zhì)量目標(biāo)

■質(zhì)量工作具體流程

■在項目各個不同階段，職責(zé)、權(quán)限和資源的具

彳本分酉已

■項目實施中需采用的具體的書面程序和指導(dǎo)書

■有關(guān)階段適用的試驗、檢查、檢驗和評審大綱

■達到質(zhì)量目標(biāo)的測量方法

■隨項目的進展而修改和完善質(zhì)量計劃的程序

■為達到項目質(zhì)量目標(biāo)必須采用的其它措施

項目質(zhì)量控制

■質(zhì)量控制主要是監(jiān)督項目的實施結(jié)果，將項目

的結(jié)果與事先制定的質(zhì)量標(biāo)準(zhǔn)進行比較，找出

其存在的差距，并分析形成這一差距的原因，

質(zhì)量控制同樣貫穿于項目實施的全過程。項目

的結(jié)果包括產(chǎn)品結(jié)果（如交付）以及管理結(jié)果

（如實施的費用和進度）。質(zhì)量控制通常是由

質(zhì)量控制部門或類似的質(zhì)量組織單元實施，但

是也并非總是如此。

質(zhì)量保證

■質(zhì)量保證是所有計劃和系統(tǒng)工作實施達到質(zhì)量

計劃要求的基礎(chǔ)，為項目質(zhì)量系統(tǒng)的正常運轉(zhuǎn)

提供可靠的保證，它應(yīng)該貫穿于項目實施的全

過程之中。在IS09000系列實施之前，質(zhì)量保

證通常被描述在質(zhì)量計劃之中。

■質(zhì)量保證通常是由質(zhì)量保證部門或者類似的組

織單元提供，但是不必總是如此。質(zhì)量保證通

常提供給項目管理組以及實施組織（內(nèi)部質(zhì)量

保證）或者提供給客戶或項目工作涉及的其它

活動（外部質(zhì)量保證）。

質(zhì)量保證”與“保證質(zhì)量”

■保證質(zhì)量是質(zhì)量控制的任務(wù)

■用戶不提QA,項目實施者也要進行質(zhì)量控制，

保證項目質(zhì)量滿足用戶要求

■QA是以保證質(zhì)量為基礎(chǔ)，進一步引伸到提供質(zhì)

量“信任”這一基本目的

■QA的主要工作是促進完善質(zhì)量控制，以便準(zhǔn)備

好客觀證據(jù)，并根據(jù)對方的要求有計劃、有步

驟地開展提供證據(jù)的活動

■“保證”有“保險”的意義

&軟件質(zhì)量保證

-軟件質(zhì)量保證的目的是向管理者提供適

當(dāng)?shù)膶浖椖空褂玫倪^程和正構(gòu)造

產(chǎn)品的可視性。

■軟件質(zhì)量保證包括評審和審計軟件產(chǎn)品

和活動以驗證它們符合適用的規(guī)程和標(biāo)

準(zhǔn)，給項目和其它有關(guān)的經(jīng)理提供這些

評審和審計的結(jié)果。

SQA的問題處理渠道

■首先在軟件項目內(nèi)部處理符合性問題，

如可能的話就地解決它。

■對于那些無法在軟件項目內(nèi)部解決的問

題，軟件質(zhì)量保證組逐級上遞該問題到

管理者的恰當(dāng)層次以求得解決。

&SQA的目標(biāo)

-目標(biāo)工軟件質(zhì)量保證活動是有計劃的。

■目標(biāo)2軟件產(chǎn)品和活動遵守適用的標(biāo)準(zhǔn)、

規(guī)程和需求的情況得到客觀的驗證。

■目標(biāo)3受影響的組和個人接到軟件質(zhì)量

保證活動和結(jié)果的通知。

■目標(biāo)4高級管理者處理在軟件項目內(nèi)部

不能解決的不符合問題。

&SQA的獨立性

■存在負(fù)責(zé)協(xié)調(diào)和實施項目的SQA的組

■SQA有一個向高級管理者報告的渠道，它獨立于：項

目經(jīng)理，軟件工程組，其它的有關(guān)組

■組織機構(gòu)支持那些要求獨立性的活動，如SQA

■獨立性應(yīng)該：

■給擔(dān)當(dāng)SQA角色的個人提供組織上的自由度，使他

們成為高級管理者在軟件項目上的“耳目”。

-使得擔(dān)當(dāng)SQA角色的個人免受他們正在評審的軟件

項目的管理者所作的性能評價的影響。

-使高級管理者相信正在報告的有關(guān)項目過程和產(chǎn)品

的信息是客觀的。

SQA過程活動

活動工按照已建檔的規(guī)程為軟件項目制訂SQA計劃

活動2按照SQA計劃進行SQA組的活動

活動3SQA組參與準(zhǔn)備和評審項目的軟件開發(fā)計劃、標(biāo)

準(zhǔn)和規(guī)程

活動4SQA組評審軟件工程活動以驗證符合性

活動5SQA組審計指定的軟件工作產(chǎn)品以驗證符合性

活動6SQA組定期向軟件工程組報告其活動的結(jié)果

活動7按照已文檔化的規(guī)程對在軟件活動和軟件工作產(chǎn)

品中所鑒別出的偏差建立文檔并加以處理

活動8SQA組與顧客的SQA人員一起對它的活動和發(fā)現(xiàn)

進行定期評審

SQA計劃的內(nèi)容

1.SQA組的職責(zé)和權(quán)力

2.SQA組的資源要求

3.項目的SQA組活動的進度表和投資

4.SQA組參加制定項目的軟件開發(fā)計劃、標(biāo)準(zhǔn)和規(guī)程的情況

5,將由SQA完成的評價

6.將由SQA組進行的審計和評審

7.將用作SQA組評審和審計的基礎(chǔ)的項目的標(biāo)準(zhǔn)和規(guī)程

8,用于對不符合性問題建立文檔和進行跟蹤直至結(jié)束的規(guī)程

9.要求SQA組生成的文檔

10.就SQA活動給軟件工程組和其它軟件一有關(guān)組提供反饋信

息的方法和頻率

軟件可靠性與容錯設(shè)計

）軟件可靠性

Z(t)

0

t

硬件系統(tǒng)故障率軟件系統(tǒng)故障率

軟件可靠性定義

在給定時間間隔內(nèi)和特定的環(huán)境

下，軟件按規(guī)格說明成功運行的

概率。

軟件可靠性的主要指標(biāo)

借用硬件可靠性的定量度量方法來度

量軟件的可靠性：

■MTBF:平均故障間隔時間

■MTTF:平均故障時間

tLt2,..........,tn:失效時間

111

MTTF=-1-v+

n乙li

i=l

軟件可靠性定義的要素

(1)環(huán)境條件

規(guī)定軟件的使用環(huán)境

(輸入數(shù)據(jù)要求和環(huán)境)

(2)規(guī)定時間

時間t是隨機變量。

(3)規(guī)定的功能

(4)成功運行

《軟件容錯技術(shù)

-提高軟件質(zhì)量和可靠性的技術(shù)：

■避開錯誤技術(shù)

■容錯技術(shù)

■對無法避開的差錯，使其影響減至

最小的技術(shù)

什么是容錯軟件?

定義L規(guī)定功能的軟件，在一定程度上對

自身錯誤的作用具有屏蔽能力的軟件；

定義2：規(guī)定功能的軟件，在一定程度上能

從錯誤狀態(tài)自動恢復(fù)到正常狀態(tài)的軟件；

定義3：規(guī)定功能的軟件，在因錯誤而發(fā)生

錯誤時，仍能在一定程度上完成預(yù)期的

功能的軟件。

容錯的一般方法

■實現(xiàn)容錯計算的方法（容錯資源）：

■錯誤檢測算法

■錯誤恢復(fù)算法

■軟件冗余備份

■容錯軟件

■主體：常規(guī)軟件所需資源

■附加體：容錯資源

■實現(xiàn)容錯計算的主要手段是冗余

容錯

■冗余技術(shù)分類:■軟件的容錯系統(tǒng)結(jié)

■結(jié)構(gòu)冗余構(gòu)

-靜態(tài)冗余■多版本結(jié)構(gòu)

■動態(tài)冗余■恢復(fù)塊結(jié)構(gòu)

.混合冗余

■信息冗余

■時間冗余

《結(jié)構(gòu)冗余：靜態(tài)冗余

■3模冗余、多模冗余

■3模(TMR)表決系統(tǒng)的結(jié)構(gòu)

U=(ulAu2)V(u2Au3)V=(ulAu3)

I.結(jié)構(gòu)幾余：動態(tài)幾余

-多重模塊待機儲備,相繼運行

-待機儲備系統(tǒng)結(jié)構(gòu)

&結(jié)構(gòu)冗余：混合冗余

■混合冗余H(N,K)結(jié)構(gòu)

4信息冗余

-以檢測或糾正信息在運算或傳輸中的錯

誤為目的而外加的一部分信息

■誤差校正碼：

■奇偶碼

■定重碼

■循環(huán)碼

時間冗余

-以重復(fù)執(zhí)行指令（指令復(fù)執(zhí)）或程序

（程序復(fù)算）來消除瞬時錯誤帶來的影

響

■常用的程序復(fù)算方法：程序滾回技術(shù)

1111____III.

tot]t2t3tj_xtj4+1

時刻％ti,t2,….對應(yīng)于程序中預(yù)先設(shè)置好的恢復(fù)點

容錯結(jié)構(gòu):多版本結(jié)構(gòu)

■把同一功能的不同版本的程序（多為子系

統(tǒng)或模塊級）并行聯(lián)結(jié)到系統(tǒng)中，構(gòu)成冗

余并行模型

■多版本程序不意圖

同一功能

I容錯結(jié)構(gòu):恢復(fù)塊結(jié)構(gòu)

&求做容錯的塊（基本塊）

提供：

密環(huán)塊（獨立設(shè)計的相應(yīng)冗余備份）

附加的錯誤檢驗

恢復(fù)措施

恢復(fù)塊（Ensure接受測試

JBy基本塊

ElseBy備份塊1

ElseBy備份塊n

(Else錯誤J

&恢復(fù)塊的工作方式

評審與審查

Review&Inspection

4概論

■在軟件的研制過程中必須進行的一項重要工作,

就是軟件的驗證與確認(rèn)。

■軟件驗證是確定軟件開發(fā)周期中的一個給定階

段產(chǎn)品是否達到前階段確立的需求的過程。它

包括評審、審查、測試、檢查、審計等項活動。

■軟件確認(rèn)是在軟件開發(fā)過程結(jié)束時對軟件進行

評價，以確認(rèn)它和軟件需求是否相一致的過程。

也可以說，確認(rèn)是“端到端”的驗證。

什么是驗證與確認(rèn)

■驗證和確認(rèn)是兩項相輔相成的工作，但它們之

間卻極易混淆。

■軟件工程權(quán)威BarryW.Boehm曾巧妙地用兩句

形式相似但內(nèi)容不同的話作過精辟的描述：

■Verification:Arewebuildingtheproductright?

■Validation:Arewebuildingtherightproduct?

■驗證：我們正正確地制造產(chǎn)品嗎？

■確認(rèn)：我們正制造正確的產(chǎn)品嗎？

為什么IV&V

-不論項目大小如何，軟件驗證與確認(rèn)很大程度地

影響著軟件的質(zhì)量。

■人總是會犯錯誤的，而沒有經(jīng)過驗證的軟件將難

以正常工作。

■有典型事例說明在開發(fā)期間每1000行代碼中發(fā)現(xiàn)

有20到50個錯誤，而即使是在系統(tǒng)測試之后每

1000行代碼中仍有L5到4個錯誤。

■軟件驗證與確認(rèn)的目標(biāo)是把錯誤減少到可以接受

的水平。

■軟件的驗證與確認(rèn)工作占用整個項目的30%?

90%的資源。

驗證與確認(rèn)V形圖

■軟件開發(fā)工作開始于圖的左上角，沿左

邊的產(chǎn)生“軟件規(guī)格”側(cè)向下進行到

“v”的底端，其間要逐階段進行驗證;

■之后沿右邊的產(chǎn)生“軟件產(chǎn)品”側(cè)向上,

之間對應(yīng)著它們對“軟件規(guī)格”的驗證。

■v形圖強調(diào)在左側(cè)按照輸入驗證每個輸

出及在右側(cè)根據(jù)“軟件規(guī)格”驗證軟件

產(chǎn)品。

V形圖驗證與確認(rèn)說明

■根據(jù)系統(tǒng)需求驗證軟件需求

■根據(jù)軟件需求驗證概要設(shè)計

■根據(jù)概要設(shè)計驗證詳細(xì)設(shè)計

■根據(jù)詳細(xì)設(shè)計驗證編碼

■用單元測試驗證詳細(xì)設(shè)計

■用組裝測試驗證概要設(shè)計

■用確認(rèn)測試驗證軟件需求

■用系統(tǒng)聯(lián)試驗證系統(tǒng)需求

通過評審進行IV&V

■對軟件的工作產(chǎn)品進行驗證的一個重要

方法是評審。

■評審是把工作產(chǎn)品或工作產(chǎn)品集提交給

項目人員、經(jīng)理、用戶、顧客或其它感

興趣各方進行評價或批準(zhǔn)的過程或會議。

■評審一般有技術(shù)評審、審查、走查、審

計等多種形式。

■檢查階段工作的管理評審稱作階段評審。

$為什么要及早進行評審

1）程序中的大部分錯誤是在編碼之前造成的。據(jù)

統(tǒng)計，設(shè)計及之前階段產(chǎn)生的錯誤大約占63%,

而編碼錯誤僅占37%。

2）錯誤的檢測與改正時間越晚，所付出的代價也

就越高。通過對一些大型軟件項目的分析表明;

如果在需求和設(shè)計階段發(fā)現(xiàn)一個錯誤，改正所

需費用為1；那么在測試前發(fā)現(xiàn)該錯誤，改正

費用則為6.5；在測試時發(fā)現(xiàn)，改正費用為15；

而在交付使用后再發(fā)現(xiàn)，改正費用則高達67。

3）錯誤還會被“放大”。

階段評審

■評審的目的■評審組成員

-階段評審在軟件研制的各■評審由項目組上級主管機

個階段完成了預(yù)定工作時構(gòu)組織，組長由上級主管

領(lǐng)導(dǎo)擔(dān)任。成員包括：

進行，目的是檢查該階段

工作是否完成，是否達到.1）主管領(lǐng)導(dǎo)；

了規(guī)定的質(zhì)量和技術(shù)要求,■2）同行專家；

檢查計劃管理、質(zhì)量管理、-3）質(zhì)量管理人員；

風(fēng)險管理、配置管理的執(zhí)-4）科研（計劃）管理人

行情況，決定是否可以轉(zhuǎn)員；

入下一個研制階段。-5）項目組成員；

■各研制階段結(jié)束時均應(yīng)進■6）交辦方代表（必要

行階段評審。時）。

階段評審程序⑴

■(1)評審前的準(zhǔn)備

-準(zhǔn)備階段評審匯報和被評審文件。匯報內(nèi)容：

■1)本階段研制工作的主要內(nèi)容和完成情況；

■2)為保證產(chǎn)品質(zhì)量所做的質(zhì)量保證工作；

■3)計劃落實和配置管理情況；

■4)本階段出現(xiàn)的主要問題及解決情況；

■5)結(jié)論及建議。

■(2)確定評審人員和日期

■(3)評審組分工

■(4)評審組審閱評審文件

-承辦單位提前三天將評審文件提交評審組審閱

階段評審程序(2)

■(5)評審會議

■1)軟件研制項目組作階段評審匯報；

-2)評審組詢問、討論、審查各項工作，項目組答辯；

-3)評審組作出評審結(jié)論并由組長宣布。

-(6)填寫評審總結(jié)報告

■(7)評審后的工作

■評審結(jié)論入配置管理、保存?zhèn)浒?、交上級審批?/p>

-項目組針對修改意見和改進建議，經(jīng)審批進行修改補充。

-項目組根據(jù)評審意見，轉(zhuǎn)入下一研制階段。

階段評審表

■在每次階段評審時，都必須履行正式手續(xù)，填

寫必要的評審表格，以利于項目管理和質(zhì)量檢

查。

■階段評審表由三張子表組成

-子表1是對評審中發(fā)現(xiàn)問題的記錄

-子表2是評審總結(jié)報告

-子表3是評審小組成員登記與簽字表

■對于在評審中發(fā)現(xiàn)的軟件問題，用軟件問題報

告單對問題進行詳細(xì)的描述。

登記號

評審問題記錄

評審「1期年月日

評審性質(zhì)評審□復(fù)審口

項目名子項目名代號

編號問題摘要問題類型是否解決

1

2

3

5

6

7

8

9

10

11

12

13

14

15

職務(wù)姓名職稱單位簽字

組長

評副組長

審

小成員

組

成成員

員

成員

成員

成員

成員

成員

技術(shù)評審

?以下技術(shù)評審過程是歐洲航空局最佳實踐過程

之一

■目的

-技術(shù)評審的目的是對具體的工作產(chǎn)品集（如文檔、

源代碼）進行評價，并對管理提供以下信息：

-它們符合前一階段制定的軟件規(guī)格；

■它們已按照項目的標(biāo)準(zhǔn)和方法完成；

.所有的更改都正確地得到完成，并只影響對更改規(guī)定的范

圍。

4組織

■技術(shù)評審過程由評審組來執(zhí)行，評審

組中有以下的角色：

■負(fù)責(zé)人

■秘書

■成員

■負(fù)責(zé)人的責(zé)任包括：

-提名評審組；

-組織評審并通知所有參加者評審的時間、地點和日

程；

-會議前向所有參加者分發(fā)評審項并在必要時分配評

審項；

-必要時組織評審組開展準(zhǔn)備工作；

-主持評審會議；

-發(fā)布技術(shù)評審報告。

-必要時秘書應(yīng)協(xié)助負(fù)責(zé)人，并負(fù)責(zé)記錄評審組發(fā)現(xiàn)

的問題、作出的決定和建議。

■各評審組成員檢查評審項并參加評審會議。

■如果被評審項規(guī)模大、復(fù)雜或需要各種專業(yè)

的專家技能才能進行有效的評審，那么負(fù)責(zé)

人可以在成員中分配評審項。

-適當(dāng)時，對技術(shù)評審過程的輸入包括：

-評審會議日程；

-對目的的陳述；

-評審項（如被評審的軟件需求規(guī)格說明、軟件概要

設(shè)計說明）；

-評審項應(yīng)符合的上階段給出的軟件規(guī)格（如評審軟

件詳細(xì)設(shè)計說明時所對應(yīng)的軟件概要設(shè)計說明）；

-評審項使用的計劃、標(biāo)準(zhǔn)及指南；

-與評審項有關(guān)的評審差異表、軟件問題報告單，修

改報告單；

-軟件質(zhì)量保證人員的報告。

編號

評審差異表

日期

提出人

1文檔標(biāo)題:

2文檔代號:

3文檔發(fā)布/版木號:

4問題位置:

5問題說明:

6建議解決方法:

7作者答復(fù):

8評審決定:

結(jié)束/更改/措施/拒收（劃出選擇）

活動=準(zhǔn)備+評審會議

■準(zhǔn)備

■負(fù)責(zé)人起草日程表，并將其與目的、被評審項、規(guī)

格、計劃和指南一起散發(fā)給評審組。

-評審組成員對評審項進行檢查。通過完成評審差異

表來對在檢查中發(fā)現(xiàn)的每個問題進行記錄。將評審

差異表退還給秘書。

-負(fù)責(zé)人將每張評審差異表按主要的、次要的或編輯

上的進行分類

-由秘書按被評審項中偏差的位置對評審差異表進行

排序。

活動=準(zhǔn)備+評審會議

■評審會議

■1）開始；

■2）展示被評審項；

■3）評審差異表的分類；

■4）對主要的評審差異表的評審;

■5）對其它的評審差異表的評審;

■6）結(jié)論。

評審結(jié)論

■典型的結(jié)論是：

-授權(quán)進行下一步的工作，條件是完成更改工作和采

取措施；

.授權(quán)進行限定部分的工作；

-執(zhí)行決定的附加工作。

■如未能對達成一致意見和得出結(jié)論，則：

-在評審報告中記錄非主流的不同觀點；

-由一名或多名成員在會議外尋找解決方法；

-把問題移交給上一級管理部門。

輸出

-報告摘要；

-成員名單；

■被評審項的確定；

-按照分類編組的帶處置標(biāo)志的評審差異表、軟件問題

報告單、軟件修改報告單等；

■措施清單，以及各措施的人員責(zé)任和預(yù)期完成日期；

■結(jié)論。

■輸出可采取會議記錄的形式，或采取獨立報告的形式。

.報告應(yīng)足夠詳細(xì)，以便于管理部門判斷發(fā)生了什么事。

■如果在評審期間難以達成一致意見，可建議評審組成員對輸

出不簽字。

軟件審查

■軟件審查可用于編碼前發(fā)現(xiàn)詳細(xì)設(shè)計中的缺陷，在測

試前發(fā)現(xiàn)代碼的缺陷。軟件審查也可以用于驗證測試

設(shè)計、測試用例和測試過程。

■軟件審查是有效的。通過審查，可以查出開發(fā)過程所

帶給項目的全部缺陷的50%。

-軟件審查是經(jīng)濟的，因為它可以大大減少缺陷的數(shù)量

和降低消除缺陷的費用。在缺陷產(chǎn)生后盡可能短的時

間內(nèi)發(fā)現(xiàn)缺陷可以：

-使軟件開發(fā)者增強查找缺陷產(chǎn)生原因的意識，以便

減少類似缺陷再出現(xiàn)的可能性；

-使查找缺陷的工作量減少，因為不需要在許多可能

的組成部分以外去診斷哪個組成部分有缺陷。

審查的目的

-軟件審查的目的是查出文檔或代碼中的

缺陷。

軟件審查的組織

■主任：主任領(lǐng)導(dǎo)審查并主持審查會。主任應(yīng)具備完成這項工作的

技能，而不必要精通所審查的項目。他（她）必須是公平的、客

觀的。鑒于這些原因，主任常常從與項目無關(guān)的職員中選出。最

好他們受過有關(guān)審查過程的培訓(xùn)。

■秘書：秘書負(fù)責(zé)記錄審查會的記錄，特別是記錄發(fā)現(xiàn)的每個缺陷

的細(xì)節(jié)。

-閱讀員：閱讀者引導(dǎo)審查組遍歷被審查項。

■審查員：審查員在審查時確定和描述被審查項的缺陷。選擇的審

查員應(yīng)能代表各種觀點（如：設(shè)計員、編碼員和測試員）。

-作者：作者是被審查項的編制人員。作者主要回答關(guān)于被審查項

的問題，并負(fù)責(zé)所有的修改。

■一個人可擔(dān)任上述一種或多種角色。沒有人既擔(dān)任作者又擔(dān)任其

它由色。

軟件審查的輸入

■被審查項（如源代碼，或其它文檔）

■被審查項應(yīng)符合的規(guī)格（如詳細(xì)設(shè)計）

■審查檢查單

■應(yīng)用于被審查項的標(biāo)準(zhǔn)和指南

■審查報告表

■從上一次審查中獲得的缺陷表

活動=綜述、準(zhǔn)備、審查會、修改、補充活動

-綜述是對被審查項進行介紹。

■之后審查員對被審查項進行熟悉，作好

參加審查會的準(zhǔn)備。

■然后，審查員在審查會上檢查被審查項、

確定缺陷并決定是否對缺陷進行糾正。

■修改工作包括對故障的修復(fù)。

■補充活動是指檢查在審查會上作出的所

有決定是否都得到了執(zhí)行。

審查的時間和速度

-代碼審查的初始參考值：

■準(zhǔn)備：每小時125行非注釋源代碼；

■審查會：每小時90行非注釋源代碼。

■對偽碼或PDL的審查，上述數(shù)字應(yīng)加倍。

■審查會不應(yīng)超過兩個小時。

軟件審查活動

■綜述：綜述的目的是向?qū)彶榻M介紹被審

查項。主任介紹要審查的范圍，然后詳

細(xì)介紹設(shè)計的具體的范圍，再將輸入分

配給參加者。

軟件審查活動

■準(zhǔn)備：主任、閱讀員和審查員對輸入進行熟悉。

通過閱讀下列資料來做好代碼審查的準(zhǔn)備：

-要審查的代碼設(shè)計規(guī)范；

■編碼標(biāo)準(zhǔn)；

-含以前審查發(fā)現(xiàn)的普遍編碼錯誤的代碼審查檢查單;

-被審查的代碼。

■被審查項的缺陷要在評審差異表中記錄，并在

審查過程中合適的時候進行宣布。準(zhǔn)備工作應(yīng)

單獨進行，而不要在會議上進行。

軟件審查活動■審查會

-主任檢查成員的準(zhǔn)備工作，報告和記錄各成員所花費的時間。

■由閱讀員引導(dǎo)會議遍歷被評審項。對文件閱讀員可總結(jié)某些部分

的內(nèi)容，并一行一行地讀完所有內(nèi)容。對代碼閱讀員應(yīng)覆蓋每個

邏輯塊，至少詳細(xì)討論每個分支一次。審查員利用檢查單來發(fā)現(xiàn)

普遍錯誤。

■秘書對閱讀中發(fā)現(xiàn)的缺陷立即進行記錄。包括下列的內(nèi)容：

.嚴(yán)重性、技術(shù)分類、位置、描述

■不記錄確定的任何解決措施。審查組應(yīng)避免尋找解決措施，而應(yīng)

集中精力發(fā)現(xiàn)缺陷。

■在審查會結(jié)束前，審查組應(yīng)作出下列中的一種決定：

.當(dāng)修改完成之后（如果有）接收該審查項；

■當(dāng)修改完成之后由主任負(fù)責(zé)接收該審查項；

-重新審查整個被審查項（如果5%以上需要修改）。

■秘書應(yīng)在之前起草會議紀(jì)要，以便修改工作能及時地進行。

軟件審查—活動

■修改

.審查之后，軟件作者糾正缺陷清單中列出的缺陷。

■補充活動

-修改之后，補充活動驗證所有的缺陷都得到了正確

的糾正，而無其它缺陷被引入。

■主任負(fù)責(zé)補充活動。

-其它補充活動是：

-依據(jù)不同錯誤類型變化的頻率修改檢查單；

-分析缺陷統(tǒng)計資料，也許會導(dǎo)致對軟件驗證與確認(rèn)工作的