1項目質(zhì)量管控方案

2項質(zhì)量管控方案

CY一、、一

2.1刖百

2.1.1目的

本計劃的目的在于對所開發(fā)的軟件規(guī)定各種必要的質(zhì)量保證措施，以保證所交付的軟件

能夠滿足項目預(yù)定需求，能夠滿足本項目總體組制定的且經(jīng)領(lǐng)導(dǎo)小組評審批準的該軟件系統(tǒng)

需求規(guī)格說明書中規(guī)定的各項具體需求。

2.1.2軟件開發(fā)項目組在開發(fā)軟件系統(tǒng)所屬的各個子系統(tǒng)（其中包括為本項目研發(fā)

或選用的各種支持軟件、組件）時，都應(yīng)該執(zhí)行本計劃中的有關(guān)規(guī)定，但可根據(jù)

各自的情況對本計劃作適當?shù)募舨?，以滿足特定的質(zhì)量保證要求，剪裁后的計劃

必須經(jīng)項目組相關(guān)負責人批準。

2.1.3術(shù)語和定義

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

2.質(zhì)量策劃：質(zhì)量管理的一部分，致力于制定質(zhì)量目標并規(guī)定必要的運行過程3.和相關(guān)資

源以實現(xiàn)質(zhì)量目標

4.質(zhì)量控制：質(zhì)量管理的一部分，致力于滿足質(zhì)量要求

2.25.質(zhì)量保證：質(zhì)量管理的一部分，致力于提供質(zhì)量要求會得到滿足的信任

2.36.質(zhì)量度量：質(zhì)量管理的一部分，致力于對已存在的質(zhì)量數(shù)據(jù)進行分析，得出當前質(zhì)

量管理結(jié)果的評估數(shù)據(jù)。

2.47.質(zhì)量改進：質(zhì)量管理的一部分，致力于增強滿足質(zhì)量要求的能力

質(zhì)量計劃：制定新項目及維護性項目質(zhì)量計劃

2.4.1在本環(huán)節(jié)中，根據(jù)項目的規(guī)模及性質(zhì)進行質(zhì)量策劃，制定本項目的質(zhì)量計劃；為

后續(xù)的質(zhì)量控制、質(zhì)量評估及質(zhì)量改進做出行動綱領(lǐng)。針對公司主要有新項目及

維護性項目兩類版本，且兩者之間的質(zhì)量投入有所差異的特性，故質(zhì)量計劃可以

區(qū)分以下：

2.4.2常規(guī)項目質(zhì)量計劃要求

2.4.2.1常規(guī)項目的質(zhì)量計劃制定按質(zhì)量要求分析/質(zhì)量目標/人員.職責及質(zhì)量保障、過

程檢查計劃組成，各項的具體要求如下所述。

2.4.2.2質(zhì)量要素分析

■主要的質(zhì)量要性如下：

■功能性質(zhì)量因素：正確性，健壯性，可靠性

■非功能性質(zhì)量因素：性能，易用性，清晰性，安全性，可擴展性，兼容性，可移

植性

■其它質(zhì)量因素：非以上要求之外的要求。

■根據(jù)產(chǎn)品的特性及市場目標，將關(guān)鍵的質(zhì)量要素確認，同時區(qū)分本項目的類型

■傾質(zhì)量型項目：指本項目對質(zhì)量控制更關(guān)注

■傾成本型項目：指本項目對成本控制更關(guān)注

傾工期型項目：指本項目對工期要求更關(guān)注

2.4.2.3根據(jù)以上分析，再制定相應(yīng)的質(zhì)量目標。

2.4.2.4質(zhì)量目標

訂立質(zhì)量目標時，一般遵循SMART原則

S：specific具體的

M：measurab1e可測量的

A：achievable可取得的

R:realistic切實的

T：timely及時的

1.根據(jù)以上原則，我們可以制定如下質(zhì)量目標：

2.比如本項目的質(zhì)量要素為功能正確性、功能健壯性、性能

?那質(zhì)量目標可定義例下：

?需求中所定義的功能都得以實現(xiàn)

?不穩(wěn)定問題（等級非輕微）都被解決

?關(guān)鍵模塊（模塊名稱）的性能不能低于VI.0版本

3.針對質(zhì)量目標定出優(yōu)先級

4.1.3.2

5.目標分解

?分解為階段質(zhì)量目標

?完成階段質(zhì)量目環(huán)的手段

2.4.2.5人員與職責

1.參加質(zhì)量管理活動的人員，一般情況下，項目組所有的人都可以參與到質(zhì)量管理活

動中來。但我們一般可定義如下人員去分別承擔相應(yīng)的職責。

2.質(zhì)量管理人員：制定質(zhì)量管理計劃，對質(zhì)量過程進行控制；對過程檢查單進行實施;

進行質(zhì)量度量，制定質(zhì)量改進計劃及實施；參與各類評審活動。

階段

計劃階計劃階段的項目組成立之3次對應(yīng)測試接口根據(jù)計劃階段檢查

段產(chǎn)出后至計劃階段人清單進行檢查

結(jié)束

需求階需求評審需求評審啟動1次對應(yīng)測試接口根據(jù)需求階段檢查

段人清單進行檢查。

2.4.3維護性項目質(zhì)量計劃要求

維護性項目的質(zhì)量計劃制定相對簡單，不需要花較多的時間在其上，并且可以套用比較固定

的模板。

2.4.3.1維護性項目基本上會有很明確的需求點以及具體的時間點要求，一般情況下,

維護時期會很長，且需求相對較散、小，針對這些特性，維護性項目的質(zhì)量計劃要

求僅可以包括：質(zhì)量目標、質(zhì)量保障計劃、過程檢查計劃。

2.4.3.2質(zhì)量目標

根據(jù)當前的需求簡單定出本版本的質(zhì)量目標。

2.4.3.3質(zhì)量保障計劃

在維護性項目中，質(zhì)量保障計劃主要包括：需求討論、聯(lián)調(diào)以及測試。

需求討論：參與人員包括開發(fā)及測試人員；需求討論結(jié)果報告

聯(lián)調(diào)：對所做的修改及周邊進行聯(lián)調(diào)；聯(lián)調(diào)測試報告

2.4.3.4測試：根據(jù)質(zhì)量目標制定相應(yīng)的測試計劃安排，

2.4.3.5過程檢查計劃

?無論質(zhì)量目標定為如何，維護性項目的過程檢查，僅需要如下環(huán)節(jié)：

?需求討論會：是否進行了需求討論會，需求討論會的與會人員及結(jié)果

?聯(lián)調(diào)：是否進行了聯(lián)調(diào)，對原版本的影響

測試執(zhí)行：對測試過程進行檢查

2.5質(zhì)量保證與控制

質(zhì)量保證與控制是質(zhì)量管理中最重要的一個環(huán)節(jié)，質(zhì)量目標是否能夠有效的實現(xiàn)都有賴

于此環(huán)節(jié)的實施控制。本環(huán)節(jié)根據(jù)質(zhì)量保障計劃、過程檢查計劃對版本開發(fā)的各過程定出質(zhì)

量指導(dǎo)方針、評審環(huán)節(jié)規(guī)則以及檢查清單。其中

質(zhì)量指導(dǎo)方針：用于簡要指引如何高質(zhì)量的完成本階段的工作

評審管理：主要制定簡單的評審輸入、輸出以及該階段評審的基本準則

任務(wù)檢查單：用于檢查該階段的任務(wù)是否進行以及進行的效果如何

2.5.1常存在的問題：更多的是讓各成員了解一些經(jīng)驗所談會存在哪些問題，可提前預(yù)

防或糾正

2.5.2計劃階段

計劃階段指從項目啟動至項目總體計劃制定完成的階段。

2.5.2.1質(zhì)量指導(dǎo)方針

1.在項目的計劃階段，期望產(chǎn)出高質(zhì)量的項目總體計劃，建議遵守以下原則：

2.根據(jù)《項目總體計劃模板》、《項目總體計劃編制說明書》的指導(dǎo)原則進行計劃編排

3.計劃制定時需結(jié)合實際并與相關(guān)人員進行必要的溝通

4.了解項目背景、項目目標以及可調(diào)動的資源等

5.計劃制定時需考慮相應(yīng)風險及應(yīng)對措施：如人員變動、需求變化、技術(shù)難題

6.對于把控不準的項目進行不同層面的評審

2.5.2.2評審管理

計劃階段的評審主要指項目總體計劃的評審。

2.5.2.2.1評審輸入項

《項目總體計劃》以及當前項目原始需求等相關(guān)資料

2.5.2.2.2評審準則

項目總體計劃的評審主要從完整性、正確性、合理性、可管理性進行評審。

評審項評審要求備注

完整性1.是否包括從需求至發(fā)布各個階段的任務(wù)計劃？

2.是否對各任務(wù)的交付件定義了質(zhì)量要求？

3.是否對各任務(wù)的交付件定義了質(zhì)量要求？

正確性1.各階段定義是否正確？

2.各子任務(wù)所屬的階段是否正確？

3.各子任務(wù)所屬的階段是否正確？

合理性1.各個任務(wù)的先后順序是否合理？并串行安排是否合理？

2.各任務(wù)分配的資源是否合理？

3.各任務(wù)細化的程度是否合理？

4.任務(wù)與任務(wù)之間的約束是否合理？

5.各階段的時間投入比例是否合理？

6.項目的結(jié)束時間，是否與客戶承諾的一致

7.項目的計劃中是否考慮一些常見的風險？

8.對風險的應(yīng)對是否體現(xiàn)在計劃中？

9.對風險的應(yīng)對是否體現(xiàn)在計劃中？

可管理性1.對于每個階段是否有明確的里程碑事件？

2.里程碑是否有明確、可衡量的目標？

3.里程碑達到時，是否能提供標志階段結(jié)束的正式輸出文檔？

4.里程碑達到時，是否能提供標志階段結(jié)束的正式輸出文檔？

5.里程碑達到時，是否能提供標志階段結(jié)束的正式輸出文檔？

2.5.2.2.3評審輸出

1.評審結(jié)果輸出包括：

2.《評審結(jié)果記錄表》

2.5.3需求階段

1.需求階段指從需求獲取至輸出需求規(guī)格說明書階段。需求階段可劃分為：獲取需求、

分析需求、編寫需求規(guī)格說明書三個階段。

2.獲取需求：主要從編寫項目視圖與范圍、用戶群分類、選擇產(chǎn)品/項目需求代表、確

定使用實例、分析工作流程、需求重用這幾步驟進行

3.分析需求：包括繪制關(guān)聯(lián)圖、創(chuàng)建開發(fā)原型、分析可行性、劃分需求優(yōu)先級；

2.5.3.1編寫需求規(guī)范說明書：根據(jù)項目特點裁剪模板、獲取功能和技術(shù)需求、注明需求

來源、開發(fā)需求追蹤矩陣。

2.5.3.2質(zhì)量指導(dǎo)方針

■根據(jù)《需求模板》、《需求編寫指導(dǎo)說明書》制定需求說明文檔

■需求文檔中應(yīng)包括明確的需求范圍

■需求文檔中應(yīng)包括主要的質(zhì)量屬性

■需求需細化到要求的程度（可以根據(jù)需求進行開發(fā)設(shè)計及測試設(shè)計）

■需求的不確定項不超過總體需求的5%

■需求中應(yīng)明確定義需求的優(yōu)先級

■制定需求管理原則（包括需求標識、跟蹤方式、變更控制原則）

2.5.3.3評審管理

需求階段評審主要針對需求的清晰性、正確性、完整性、可管理性進行評審。評審的形

式按實際的質(zhì)量計劃中要求而定。

2.5.3.3.1評審輸入項

《技術(shù)方案建議書》、《需求分析》、《需求規(guī)格說明書》

2.5.3.3.2評審準則

需求評審時，主要針對需求的清晰性、正確性、完整性、可行性、可管理性進行評審，評審

細項如下圖所示：

評審項評審要求備注

1.清晰1.系統(tǒng)的目標是否已定義？

性2.

3.是否對關(guān)鍵術(shù)語及略縮語進行了定義？

4.

5.是否有對整套系統(tǒng)進行了功能概述？

6.

2.正確1.需求與需求之間是否有重復(fù)或沖突？

性2.本需求說明書與相關(guān)需求素材是否一致？

3.

4.是否清晰、簡潔、無二義地表達了每個需求？

5.是否每個需求都在項目的范圍內(nèi)

評事項評審要求備注

6.是否每個需求都沒有內(nèi)容和語法上的錯誤？

3.完整1.編寫的所有需求，其詳細程度是否一致和合適？

性2.

3.需求是否能為設(shè)計提供足夠的基礎(chǔ)？

4.所有對其他需求的內(nèi)部引用是否正確？

5.是否已經(jīng)列出了系統(tǒng)所必要的依賴/假設(shè)以及約束

6.是否包含了所有已知的客戶需求或系統(tǒng)需求？

7.是否已經(jīng)對每個業(yè)務(wù)邏輯進行輸入、輸出以及過程的詳細說明

8.是否已詳細說明了軟件環(huán)境（共存的軟件）和硬件環(huán)境（特定的

配置）

9.是否遺漏了必要的信息？如果有遺漏的話，把他們標記為待確定的

問題（TBD）?

10.是否包括了主要的質(zhì)量屬性，例如性能要求、安全性要求、可靠

性要求、可恢復(fù)性要求、穩(wěn)定性要求等等

11.

12.是否分析了潛在的需求

13.是否標識并解決了需求中的潛城的問題

4.可行1.所描述的所有功能是否都必要？

性2.

3.所描述的所有功能是否充分的滿足客戶/系統(tǒng)目標？

4.

5.已知的限制（局限）是否已經(jīng)詳細說明？

6.

7.是否已經(jīng)確定每個需求的實現(xiàn)優(yōu)先級？

8.在現(xiàn)有的資源內(nèi)，是否能實現(xiàn)所有的需求？

9.是否每個需求都可以進行驗證（測試）？

10.

5.可管1.是否將需求分別陳述，因此它們是獨立的并且是可檢查的？

理性2.

3.是否所有需求都可以回溯到相應(yīng)的需求素材，反之亦然？

4.

5.是否已詳細說明需求變更的過程？

6.

一致性

1.是否存在沖突或重復(fù)的需求項

2.開發(fā)計劃/產(chǎn)品和活動和需求是否保持一致

3.是否可以根據(jù)軟件需求規(guī)范中的信息制定出詳細的測試集，并且

每項需求是否可以測試

評事項評審要求備注

4.

5.是否有《需求跟蹤矩陣》

2.5.3.3.3評審輸出

1.《評審結(jié)果清單》

2.《根據(jù)評審修訂后的需求規(guī)格說明書》

2.5.4設(shè)計階段

設(shè)計階段包括技術(shù)方案形成、概要設(shè)計、原型設(shè)計、詳細設(shè)計（如果有的話）等工作的完

2.5.4.1質(zhì)量指導(dǎo)方針

1.根據(jù)概要設(shè)計文檔模板要求及需求剪裁適合當前項目的模板

2.根據(jù)模板編寫概要設(shè)計說明書

3.對于質(zhì)量計劃中的關(guān)鍵質(zhì)量屬性在設(shè)計中需要重點考慮

4.需要針對項目的結(jié)構(gòu)、項目的特征和用戶的需求來分析，同樣也要考慮到參與項目小

組成員的素質(zhì)

5.對于不同的方案分別進行評估

6.對概要設(shè)計文檔進行同行評審

7.在設(shè)計階段同時完成原型的設(shè)計

8.根據(jù)實際需要考慮是否需要進行詳細設(shè)計

9.涉及到的需求變更需同步知會其它環(huán)節(jié)的更新。

2.5.4.2評審管理

在設(shè)計階段需要對設(shè)計實現(xiàn)方案、設(shè)計、原型等進行評審；評審的形式按實際的質(zhì)量計

劃中要求而定。

以下僅提供概要設(shè)計說明的評審準則

2.5.4.2.1評審輸入項

2.5.4.2.2《概要設(shè)計說明書》，《需求規(guī)格說明書》

2.5.4.2.3評審準則

概要設(shè)計說明書評審準則

評審項評審要求

正確性1.設(shè)計說明書的編寫是否按照標準模板來編寫？

2.設(shè)計是否正確？是否能夠滿足需求？

3.設(shè)計是否正確？是否能夠滿足需求？

可行性4.設(shè)計方案在現(xiàn)有條件下是否可行？

5.

可理解性6.設(shè)計方案是否能被相關(guān)人員理解？

7.

完整性8.是否包括核心功能的實現(xiàn)方案？

9.

10.所有的功能需求與非功能需求是否都體現(xiàn)在了設(shè)計中？

11.

12.在設(shè)計中是否增加了不必要的功能？

13.

14.是否為未來的變更進行了過渡設(shè)計？

15.

16.各子系統(tǒng)、模塊之間的關(guān)系是否描述得清楚

17.系統(tǒng)的設(shè)計是否考慮了系統(tǒng)的可擴展性

18.設(shè)計是否考慮了重用性

19.重用構(gòu)件是否進行了標識

20.是否說明了重用模塊的獲取方式和相關(guān)的文檔

21.系統(tǒng)的設(shè)計是否考慮了系統(tǒng)的易移植性

22.設(shè)計是否使用標準的技術(shù)，避免使用怪異的、不易理解的方式和

方法

23.

24.設(shè)計的調(diào)用寬度、調(diào)用深度、耦合度、內(nèi)聚度和結(jié)構(gòu)化程度是否

進行了描述

可追溯性25.設(shè)計是否可以跟蹤到需求

26.需求是否可以追溯到設(shè)計

2.5.4.2.4評審輸出

《評審結(jié)果列表》、評審修訂后的《概要設(shè)計文檔》

2.5.5開發(fā)階段

開發(fā)階段主要從代碼規(guī)范、代碼走查、調(diào)測等進行密制管理。

2.5.5.1質(zhì)量指導(dǎo)方針

1.約定開發(fā)的編碼規(guī)范

2.約定代碼審計所需的時間及規(guī)則

3.約定開發(fā)階段的調(diào)測方式

4.約定開發(fā)階段自測的標準

5.約定提交版本提交的原則

2.5.5.2代碼走查

走查項走查要求備注

規(guī)范性編碼是否符合項目或組織的編碼標準

頭文件包含是否完整

參數(shù)在程度開始時是否被初始化

參數(shù)在循環(huán)開始時是否被初始化

在承數(shù)或過程調(diào)用的時候參數(shù)是否被初始化

函數(shù)調(diào)用的格式和參數(shù)是否正確

變量的聲明和拼寫是否一致

變量聲明的范圍是否恰當

是否所有的指針都被初始化為NULL

程序中申請的內(nèi)存使用后是否釋放

是否每個=,|等都驗證了正確性

是否打開的文件都及時關(guān)閉了

2.5.6測試階段

2.5.6.1質(zhì)量指導(dǎo)方針

1.盡早的介入測試.，所有的測試都可以追溯到需求

2.在測試相應(yīng)方案啟動之前，必須先理解且分析需求

3.根據(jù)質(zhì)量計劃來制定相應(yīng)的測試計劃

4.測試計劃中需涵蓋所有關(guān)鍵質(zhì)量屬性

5.進行測試計劃評審及修訂

6.建立測試用例對測試需求的覆蓋率

7.進行測試用例評審及修訂

8.不同測試階段可有計劃的調(diào)整當前的測試重點

2.5.6.2評審管理

測試評審包括測試方案、測試用例的評審，一般可分為內(nèi)部評審及外部評審；評審的形

式按實際的質(zhì)量計劃中要求而定。

以下僅提供測試用例的評審準則。

2.5.6.2.1評審輸入

《需求規(guī)格說明書》、《概要設(shè)計說明書》、《測試計劃》、《測試用例》、

2.5.6.2.2評審準則

?測試用例評審活動可以確保用例符合優(yōu)秀用例陳述的特征，包括完整、正確、可行、

必要、具有優(yōu)先級、無二義性和可驗證性，同時亦符合好的用例特征，即完整性、一

致性、易修改和可跟蹤性；評審過程保證用例滿足如下要求：

?完整性：指有明確的目的、輸入、輸出，提供必要的備注信息；

?正確性：指每個用例的期望結(jié)果與實際需求一致；

?可執(zhí)行性：可執(zhí)行性指測試人員根據(jù)測試用例能夠獨立執(zhí)行測試；

?代表性：指能用最簡單的數(shù)據(jù)，最簡捷的路徑達到測試的目的；

?唯一性：指在各個測試用例沒有重復(fù)交叉的現(xiàn)象；

?有效性：指每個用例是否有效？是否冗余？是否能夠執(zhí)行；

■獨立性：是用例與用例之間是否互不依賴？是否能夠獨立執(zhí)行；

■可讀性：指測試用例描述清晰，邏輯正確，拆分合理；

■質(zhì)量指標：指是否能夠滿足質(zhì)量指標中的覆蓋率要求，是否可以滿足BUG密度的質(zhì)量

要求;

■內(nèi)部評審準則

評審項評審要求備注

完整性1.針對每個測試需求，是否至少有一個正面用

例，是否至少有一個以上反面用例去測試？

2.針對重要測試需求，是否至少使用了兩種以上

的設(shè)計方法？

3.針對重要測試需求，是否至少使用了兩種以上

的設(shè)計方法？

4.針對重要測試需求，是否至少使用了兩種以上

的設(shè)計方法？

1.是否存在重復(fù)的用例？

唯一性2.是否存在可以合并的用例？

3.是否存在需要拆分的用例？

4.是否存在冗余的用例？

5.是否存在無效的用例？

6.是否存在無效的用例？

1.每一個用例的目的、操作過程、期望結(jié)果是否

獨立性獨立？

2.每一個用例的目的及期望結(jié)果是否保持統(tǒng)一？

3.每一個用例的目的及期望結(jié)果是否保持統(tǒng)一？

期望結(jié)果是否過于發(fā)散？

1.不同用例之間針對相關(guān)聯(lián)的內(nèi)容描述是否相

可讀性同？是否存在互斥、矛盾的地方？

2.每個測試用例是否清楚的填寫了測試特性、步

驟、預(yù)期結(jié)果？

3.每個測試用例是否清楚的填寫了測試特性、步

驟、預(yù)期結(jié)果？

1.是否考慮到測試用例的執(zhí)行效率？怎么樣的

代表性步驟組合才是最高效的？

2.測試用例是否具有指導(dǎo)性，是否能靈活指導(dǎo)測

試人員通過用例發(fā)現(xiàn)更多缺陷，而不是限制他

們的思維

■外部評審準則

評審項評審要求備注

1.用例樹結(jié)構(gòu)定義是否合理？

全面性2.用例是否包括如下方面：功能、界面、性能用

例及需求中涉及到的其它方面用例

3.用例是否包括如下方面：功能、界面、性能用

例及需求中涉及到的其它方面用例

1.用例是否覆蓋了所有顯性的需求？用例是否

完整性覆蓋了所有隱性的需求

2.針對每個測試需求，是否從正面、反面分別去

驗證測試需求？

3.測試用例是否覆蓋每個被測功能的所有可能的

輸入輸出的組合？

4.測試用例是否覆蓋正常的輸入輸出組合的所有

可能的取值范圍？

5.測試用例是否包括測試了被測試對象的初始化

過程？

6.測試用例是否包含了被測對象中所有異常流的

測試？

7.是否把最多的測試用例精力放在系統(tǒng)的最主要

功能上？

8.針對每個測試用例，是否標識了優(yōu)先級，且標

識合理？

9.針對每個測試用例，是否標識了優(yōu)先級，且標

識合理？

10.針對每個測試用例，是否標識了優(yōu)先級，且標

識合理？

1.針對每個期望用例的期望結(jié)果；對開發(fā)的要求

是否合理？測試開發(fā)設(shè)計的認識是否一致？

2.用例期望結(jié)果理中與需求保持一致？

3.每一個用例的依賴數(shù)據(jù)、期望結(jié)果是否具體到

表及字段的變化？

4.每一個用例的依賴數(shù)據(jù)、期望結(jié)果是否具體到

表及字段的變化？

1.用例覆蓋率是否達到相應(yīng)質(zhì)量指標？

質(zhì)量指2.用例預(yù)期缺陷率是否達到相應(yīng)質(zhì)量指標？

標

2.5.6.2.3評審輸出

《評審結(jié)果列表》

《評審修訂通過的測試用例列表》

2.5.7發(fā)布及維護階段

2.5.7.1質(zhì)量指導(dǎo)方針

1.根據(jù)發(fā)布階段要求準備相應(yīng)的程序及文檔

2.及時檢查歸檔的各類資源

3.根據(jù)項目特性或公網(wǎng)情況制定現(xiàn)網(wǎng)問題跟蹤流及管理方式

4.與用服結(jié)合制定軟件的客戶滿意度調(diào)查單

2.5.8質(zhì)量控制中的文檔管理

2.5.8.1質(zhì)量管理會形成除項目文檔之外的管理文檔，故文檔管理主要為解決項目過程

中產(chǎn)生的各類文檔的正確性、唯一性、及時性、有效性所做的相應(yīng)約束。

2.5.8.2文檔分類

(1)開發(fā)文檔：這類文檔在軟件項目開發(fā)過程中，體現(xiàn)了軟件開發(fā)人員前一階段工作的

成果，同時又是后一階段工作的依據(jù)。這類文檔包括可行性研究報告、軟件項目開發(fā)計劃、

軟件需求規(guī)格說明、系統(tǒng)規(guī)格說明書、軟件功能說明書和數(shù)據(jù)字典等。

(2)管理文檔：這類文檔在軟件項目開發(fā)過程中，由軟件開發(fā)人員制定的需提交管理部

門的一些工作計劃、工作方案和工作報告。通過閱讀這些文檔，管理人員能夠了解軟件項目

開發(fā)活動安排、進度、資源使用等情況。這類文檔包括項目開發(fā)計劃、測試計劃、測試方案、

開發(fā)進度報告和項目總結(jié)報行等。

2.5.8.3(3)用戶文檔：這類文檔是軟件開發(fā)人員為使用該軟件的網(wǎng)點經(jīng)辦人員準備

的有關(guān)該軟件產(chǎn)品使用、操作的資料，主要是操作手冊及新功能介紹方面的文檔。

2.5.8.4(4)記錄文檔：與客戶交流往來的記錄、軟件項目開發(fā)過程中各種會議、跟

蹤記錄、審查記錄、產(chǎn)品投產(chǎn)記錄和問題跟蹤解決記錄等。

2.5.8.5(5)反饋文檔：這類文檔主要是軟件產(chǎn)品在推廣使用以后，客戶對產(chǎn)品使用

過程中意見及產(chǎn)品缺陷、質(zhì)量等方面的信息反饋。

2.5.8.6文檔管理工具

文檔管理工具現(xiàn)在采用VSS管理方式；存放至文檔基線庫。文檔基線庫

2.5.8.7文檔管理的基本要求

?正確性：所有的文檔都使用相當?shù)臉藴誓０逦臋n中所述的內(nèi)容正確無誤

?唯一性：每個版本的文檔只有一個。

?及時性：文檔隨每個任務(wù)的執(zhí)行能夠及時編制及公布

1.有效性：防止無效的文檔歸檔以及過期文檔被誤用。

2.具體要求：

3.所有的文檔都使用相應(yīng)的標準模

4.文檔發(fā)布或歸檔前得到批準

5.必要時對文件進行定期評審與更新

6.確定文件的更改和現(xiàn)行修訂狀況得到識別

7.確保在使用時可獲得有關(guān)版本的適用文件

8.確保文件保持清晰、易于識別

9.確保外部文件得到識別并控制其分發(fā)

2.5.8.8防止過期文件被誤用，若因任何原因而保留時，需對其進行適當?shù)臉俗R

2.5.8.9文檔管理流程

根據(jù)現(xiàn)有的狀態(tài)，文檔的管理流程僅涉及歸檔及發(fā)布，如下圖所示:

■說明：

■由作者或相應(yīng)負責人提出歸檔申請，必須是評審?fù)ㄟ^且修改后的文檔方可提出歸檔

申請

■是否及時歸檔的檢查在各個過程中的檢查清單中進行檢查

■文檔作廢：文檔歸檔發(fā)布后，需同時作廢此文檔之前的相應(yīng)版本。

■每次進行歸檔后，由歸檔人員統(tǒng)一進行文檔更新發(fā)布

歸檔之后的文檔如有再更新的需求，則從基線庫取出來進行更新后，重新歸檔。

質(zhì)量度量：制定項目評估項

2.5.9質(zhì)量度量主要針對項目進行評估，從項目的計劃、過程、質(zhì)量、成本、客戶滿意

度不同維度進行評估。具體細節(jié)如下。

2.5.10計劃評估

2.5.10.1計劃評估主要根據(jù)計劃歷史變更記錄來評估計劃的正確、合理性、可實施情況,

并為以后的計劃制定提供參考數(shù)據(jù)。主要針對里程碑進行評估，對于非里程碑的計

劃變化不進行評估。

2.5.10.2評估基準

1.項目啟動時的《項目總體計劃》、每次變更后的項目計劃、項目結(jié)束時的《項目總體

計劃》

2.5.10.32.項目變動記錄文件

2.5.10.4評估項

第x次變與上次偏與初始偏

評估項變更原因

更離率％離率%

里程碑1

計

劃

里程碑2

里程碑3

2.5.10.5總結(jié)

■1.計劃變更的主要原因是什么？比如

■項目計劃不夠詳細，工作安排不夠細致，時間浪費

■對項目的技術(shù)、工作量等認識不清，導(dǎo)致計劃時間失誤

■對項目人員的工作效率、特長認識不清，導(dǎo)致計劃時間失誤

2.5.11項目任務(wù)跟蹤不及時，錯過最佳調(diào)整時機

2.5.12過程評估

2.5.12.1過程評估是根據(jù)項目的每個階段的質(zhì)量指導(dǎo)方針以及檢查結(jié)果來進行的評估，

用于檢查各項目的過程控制是否達到應(yīng)有的要求。過程評估最終使用計分的方式來

得出過程得分。

2.5.12.2輸入條件

每個過程的每次的《過程檢查清單》

2.5.12.3評估記錄

2.5.12.4評估記錄根據(jù)對不同階段的關(guān)注不同，定出相應(yīng)的百分比，以及每個階段中不

同評估項的重點不同，給予不同的分值，最終統(tǒng)計出對過程的總體評分。

2.5.12.5總結(jié)

1.對過程得出的最終分進行分析：

2.哪些過程存在嚴重的質(zhì)量問題？

3.哪些過程缺乏哪些質(zhì)量控制環(huán)節(jié)？

2.5.13哪些質(zhì)量控制環(huán)節(jié)沒有起到相應(yīng)的作用？

2.5.14項目質(zhì)量評估

質(zhì)量評估主要根據(jù)測試結(jié)果的質(zhì)量評估以及現(xiàn)網(wǎng)問題跟蹤情況進行的評估。

2.5.14.1輸入條件

1.《版本質(zhì)量評估報告》

2.5.14.22.現(xiàn)網(wǎng)問題跟蹤表

2.5.14.3評估項

■測試階段評估主要依據(jù)測試各類數(shù)據(jù)根據(jù)質(zhì)量評估標準進行質(zhì)量評估。

■維護階段評估主要根據(jù)現(xiàn)網(wǎng)問題清單對缺陷率、平均缺陷時間來進行質(zhì)量評估

?缺陷率：指現(xiàn)網(wǎng)問題數(shù)/總問題率

2.5.14.4平均缺陷時間（MTF）：指平均多久時間反饋一個問題。

2.5.14.5平均缺陷恢復(fù)時間：指出現(xiàn)一個缺陷后，恢復(fù)所需要的時間。

2.5.14.6總結(jié)

對質(zhì)量情況得出來的評估結(jié)果進行分析。

1.測試結(jié)果反饋情況主要是哪些環(huán)節(jié)中的問題

2.現(xiàn)網(wǎng)問題反饋情況主要是哪些環(huán)節(jié)中的問題

3.測試結(jié)果反饋情況與現(xiàn)網(wǎng)問題反映結(jié)果是否一致

2.5.15通過以上總結(jié)分析出哪個階段所存在的問題最多，測試方法/策略是否存在問題;

改善明確存在問題的環(huán)節(jié)。

2.5.16成本評估

2.5.16.1成