某項目質(zhì)量控制管理方案

1、范文范例指導參考項目質(zhì)量管控方案1項目質(zhì)量管控方案1.1 前言1.1.1 目的本計劃的目的在于對所開發(fā)的軟件規(guī)定各種必要的質(zhì)量保證措施，以保證所交付的軟件能夠滿足項目預(yù)定需求，能夠滿足本項目總體組制定的且經(jīng)領(lǐng)導小組評審批準的該軟件系統(tǒng)需求規(guī)格說明書中規(guī)定的各項具體需求。軟件開發(fā)項目組在開發(fā)軟件系統(tǒng)所屬的各個子系統(tǒng)（其中包括為本項目研發(fā)或選用的各種支持軟件、組件）時，都應(yīng)該執(zhí)行本計劃中的有關(guān)規(guī)定，但可根據(jù)各自的情況對本計劃作適當?shù)募舨?，以滿足特定的質(zhì)量保證要求，剪裁后的計劃必須經(jīng)項目組相關(guān)負責人批準。1.1.2 術(shù)語和定義1、質(zhì)量管理：在質(zhì)量方面指揮和控制組織的協(xié)調(diào)活動2、質(zhì)量策劃：質(zhì)量管理的一

2、部分，致力于制定質(zhì)量目標并規(guī)定必要的運行過程3、和相關(guān)資源以實現(xiàn)質(zhì)量目標4、質(zhì)量控制：質(zhì)量管理的一部分，致力于滿足質(zhì)量要求5、質(zhì)量保證：質(zhì)量管理的一部分，致力于提供質(zhì)量要求會得到滿足的信任6、質(zhì)量度量：質(zhì)量管理的一部分，致力于對已存在的質(zhì)量數(shù)據(jù)進行分析，得出當前質(zhì)量管理結(jié)果的評估數(shù)據(jù)。7、質(zhì)量改進：質(zhì)量管理的一部分，致力于增強滿足質(zhì)量要求的能力1.2 質(zhì)量計劃：制定新項目及維護性項目質(zhì)量計劃在本環(huán)節(jié)中，根據(jù)項目的規(guī)模及性質(zhì)進行質(zhì)量策劃，制定本項目的質(zhì)量計劃；為后續(xù)的質(zhì)量控制、質(zhì)量評估及質(zhì)量改進做出行動綱領(lǐng)。針對公司主要有新項目及維護性項目兩類版本，且兩者之間的質(zhì)量投入有所差異的特性，故質(zhì)量計劃

3、可以區(qū)分以下：1.2.1 常規(guī)項目質(zhì)量計劃要求常規(guī)項目的質(zhì)量計劃制定按質(zhì)量要求分析/質(zhì)量目標/人員.職責及質(zhì)量保障、過程檢查計劃組成，各項的具體要求如下所述。1.2.1.1 質(zhì)量要素分析1 .主要的質(zhì)量要性如下：功能性質(zhì)量因素：正確性，健壯性，可靠性非功能性質(zhì)量因素：性能，易用性，清晰性，安全性，可擴展性，兼容性，可移植性其它質(zhì)量因素：非以上要求之外的要求。2 .根據(jù)產(chǎn)品的特性及市場目標，將關(guān)鍵的質(zhì)量要素確認，同時區(qū)分本項目的類型傾質(zhì)量型項目：指本項目對質(zhì)量控制更關(guān)注傾成本型項目：指本項目對成本控制更關(guān)注傾工期型項目：指本項目對工期要求更關(guān)注根據(jù)以上分析，再制定相應(yīng)的質(zhì)量目標。訂立質(zhì)量目標時，

4、一般遵循SMAR晾則S：specific具體的Mmeasurable可測量的A：achievable可取得的R：realistic切實的T：timely及時的根據(jù)以上原則，我們可以制定如下質(zhì)量目標：1 .比如本項目的質(zhì)量要素為功能正確性、功能健壯性、性能那質(zhì)量目標可定義例下：需求中所定義的功能都得以實現(xiàn)不穩(wěn)定問題（等級非輕微）都被解決關(guān)鍵模塊（模塊名稱）的性能不能低于V1.0版本2 .針對質(zhì)量目標定出優(yōu)先級1、3、23 .目標分解分解為階段質(zhì)量目標完成階段質(zhì)量目標的手段1.2.1.3人員與職責參加質(zhì)量管理活動的人員，一般情況下，項目組所有的人都可以參與到質(zhì)量管理活動中來。但我們一般可定義如下人

5、員去分別承擔相應(yīng)的職責。1 .質(zhì)量管理人員：制定質(zhì)量管理計劃，對質(zhì)量過程進行控制；對過程檢查單進行實施；進行質(zhì)量度量，制定質(zhì)量改進計劃及實施；參與各類評審活動。2 .測試人員：制定測試計劃，對項目進行測試，進行測試結(jié)果的度量分析；參與各類評審活動。3 .項目管理人員：協(xié)助組織解決質(zhì)量管理過程中所發(fā)現(xiàn)的各類問題及風險。1.2.1.4質(zhì)量保障計劃根據(jù)當前的質(zhì)量目標，計劃需要進行哪些質(zhì)量保障工作，一般可包括專業(yè)培訓、同級評審、測試。1.2.1.4.1 培訓I1 .確認是否需要培訓2 .確認培訓的內(nèi)容、人員、時間，以及所耗費的資源。1.2.1.4.2 評審1 .確認評審內(nèi)容及計劃；需要包括評審的內(nèi)容、

6、評審的方式以及評審的人員等等。2 .對評審結(jié)果的跟蹤、管理方式。1.2.1.4.3測試1.根據(jù)當前的質(zhì)量目標，確定測試的初步計劃，包括測試的范圍及測試方法、手段以及投入的人力及時間資源1.2.1.5過程檢查計劃根據(jù)當前的質(zhì)量目標，制定項目過程中需要檢查的對象、例如:階段檢查對象檢查時機次數(shù)檢查執(zhí)行人員檢查依據(jù)計劃階段計劃階段的產(chǎn)出項目組成立之后至計劃階段結(jié)束3次對應(yīng)測試接口人根據(jù)計劃階段檢查清單進行檢查需求階段需求評審需求評審啟動1次對應(yīng)測試接口人根據(jù)需求階段檢查清單進行檢查。1.2.2維護性項目質(zhì)量計劃要求維護性項目的質(zhì)量計劃制定相對簡單，不需要花較多的時間在其上，并且可以套用比較固定的模板

7、維護性項目基本上會有很明確的需求點以及具體的時間點要求，一般情況下，維護時期會很長，且需求相對較散、小，針對這些特性，維護性項目的質(zhì)量計劃要求僅可以包括：質(zhì)量目標、質(zhì)量保障計劃、過程檢查計劃。1.2.2.1質(zhì)量目標根據(jù)當前的需求簡單定出本版本的質(zhì)量目標1.2,2,2質(zhì)量保障計劃在維護性項目中，質(zhì)量保障計劃主要包括：需求討論、聯(lián)調(diào)以及測試需求討論：參與人員包括開發(fā)及測試人員；需求討論結(jié)果報告聯(lián)調(diào)：對所做的修改及周邊進行聯(lián)調(diào)；聯(lián)調(diào)測試報告測試：根據(jù)質(zhì)量目標制定相應(yīng)的測試計劃安排，1.2,2.3過程檢查計劃無論質(zhì)量目標定為如何，維護性項目的過程檢查，僅需要如下環(huán)節(jié)：需求討論會：是否進行了需求討論會，

8、需求討論會的與會人員及結(jié)果聯(lián)調(diào)：是否進行了聯(lián)調(diào)，對原版本的影響測試執(zhí)行：對測試過程進行檢查1.3質(zhì)量保證與控制質(zhì)量保證與控制是質(zhì)量管理中最重要的一個環(huán)節(jié)，質(zhì)量目標是否能夠有效的實現(xiàn)都有賴于此環(huán)節(jié)的實施控制。本環(huán)節(jié)根據(jù)質(zhì)量保障計劃、過程檢查計劃對版本開發(fā)的各過程定出質(zhì)量指導方針、評審環(huán)節(jié)規(guī)則以及檢查清單。其中質(zhì)量指導方針：用于簡要指引如何高質(zhì)量的完成本階段的工作評審管理：主要制定簡單的評審輸入、輸出以及該階段評審的基本準則任務(wù)檢查單：用于檢查該階段的任務(wù)是否進行以及進行的效果如何常存在的問題：更多的是讓各成員了解一些經(jīng)驗所談會存在哪些問題，可提前預(yù)防或糾1.3.1計劃階段計劃階段指從項目啟動至項

9、目總體計劃制定完成的階段。1.3.1.1 質(zhì)量指導方針在項目的計劃階段，期望產(chǎn)出高質(zhì)量的項目總體計劃，建議遵守以下原則：1 .根據(jù)項目總體計劃模板、項目總體計劃編制說明書的指導原則進行計劃編排2 .計劃制定時需結(jié)合實際并與相關(guān)人員進行必要的溝通3 .了解項目背景、項目目標以及可調(diào)動的資源等4 .計劃制定時需考慮相應(yīng)風險及應(yīng)對措施：如人員變動、需求變化、技術(shù)難題5 .對于把控不準的項目進行不同層面的評審1.3.1.2 評審管理計劃階段的評審主要指項目總體計劃的評審。1.3.1.2.1 評審輸入項項目總體計劃以及當前項目原始需求等相關(guān)資料1.3.1.2.2 評審準則項目總體計劃的評審主要從完整性、

10、正確性、合理性、可管理性進行評審。評審項評審要求備注完整性1 .是否包括從需求至發(fā)布各個階段的任務(wù)計劃？2 .是否對各任務(wù)的交付件定義了質(zhì)量要求？評審項評審要求備注止確性1 .各階段定義是否正確？2 .各子任務(wù)所屬的階段是否止確？合理性1 .各個任務(wù)的先后順序是否合理？并串行安排是否合理？2 .各任務(wù)分配的資源是否合理？3 .各任務(wù)細化的程度是否合理？4 .任務(wù)與任務(wù)之間的約束是否合理？5 .各階段的時間投入比例是否合理？6 .項目的結(jié)束時間，是否與客戶承諾的T7 .項目的計劃中是否考慮一些常見的風險？8 .對風險的應(yīng)對是否體現(xiàn)在計劃中？可管理性1 .對于每個階段是否有明確的里程碑事件？2 .

11、里程碑是否啟明確、可衡量的目標？3 .里程碑達到時，是否能提供標志階段結(jié)束的正式輸出文檔？1.3.1.2.3評審輸出評審結(jié)果輸出包括：1.評審結(jié)果記錄表1.3.2需求階段需求階段指從需求獲取至輸出需求規(guī)格說明書階段。需求階段可劃分為：獲取需求、分析需求、編寫需求規(guī)格說明書三個階段。1 .獲取需求：主要從編寫項目視圖與范圍、用戶群分類、選擇產(chǎn)品/項目需求代表、確定使用實例、分析工作流程、需求重用這幾步驟進行2 .分析需求：包括繪制關(guān)聯(lián)圖、創(chuàng)建開發(fā)原型、分析可行性、劃分需求優(yōu)先級；3 .編寫需求規(guī)范說明書：根據(jù)項目特點裁剪模板、獲取功能和技術(shù)需求、注明需求來源、開發(fā)需求追蹤矩陣。1.3.2.1 質(zhì)

12、量指導方針根據(jù)需求模板、需求編寫指導說明書制定需求說明文檔需求文檔中應(yīng)包括明確的需求范圍需求文檔中應(yīng)包括主要的質(zhì)量屬性需求需細化到要求的程度（可以根據(jù)需求進行開發(fā)設(shè)計及測試設(shè)計）需求的不確定項不超過總體需求的5%需求中應(yīng)明確定義需求的優(yōu)先級制定需求管理原則（包括需求標識、跟蹤方式、變更控制原則）1.3.2.2 評審管理需求階段評審主要針對需求的清晰性、正確性、完整性、可管理性進行評審。評審的形式按實際的質(zhì)量計劃中要求而定。1.3.2.2.1 評審輸入項技術(shù)方案建議書、需求分析、需求規(guī)格說明書1.3.2.2.2評審準則需求評審時，主要針對需求的清晰性、正確性、完整性、可行性、可管理性進行評審,評

13、審細項如下圖所示:評審項評審要求備注1.清晰性1.系統(tǒng)的目標是否已定義？2.是否對關(guān)鍵術(shù)語及略縮語進行了定義？3.是否有對整套系統(tǒng)進行了功能概述？2.止確性1.需求與，需求之1可是否啟重復或沖欠?2.本需求說明書與相關(guān)需求素材是否T?3.是否清晰、簡潔、無二義地表達了每個需求?4.是否每個需求都在項目的范圍內(nèi)5.是否每個需求都沒有內(nèi)容和語法上的錯誤？3,完整性1.編寫的所有需求，其詳細程度是否T和合適？2.需求是否能為設(shè)計提供足夠的基礎(chǔ)?3.所有對其他需求的內(nèi)部引用是否正確?4.是否已經(jīng)列出了系統(tǒng)所必要的依賴/假設(shè)以及約束5.是否包含了所有已知的客戶需求或系統(tǒng)需求？6.是否已經(jīng)對每個業(yè)務(wù)邏輯進

14、行輸入、輸出以及過程的詳細說明7.是否已詳細說明了軟件環(huán)境（共存的軟件）和硬件環(huán)境（特定的配置）8.是否遺漏了必要的信息？如果有遺漏的話，把他們標記為待確定的評審項評審要求備注問題(TBD)?9.是否包括了主要的質(zhì)量屬性，例如性能要求、安全性要求、可靠性要求、可恢復性要求、穩(wěn)定性要求等等10.是否分析了潛在的需求11.是否標識并解決了需求中的潛城的問題4.可行性1 .所描述的所有功能是否都必要？2 .所描述的所肩功能是否充分的滿足客戶/系統(tǒng)目標？3.已知的限制（局限）是否已經(jīng)詳細說明？4.是否已經(jīng)確定每個需求的實現(xiàn)優(yōu)先級？5.在現(xiàn)有的資源內(nèi)，是否能實現(xiàn)所有的需求?6.是否每個需求都可以進行驗證

15、（測試）？5.可管理性1.是否將需求分別陳述，因此它們是獨立的并且是可檢查的？2.是否所有需求都可以回溯到相應(yīng)的需求素材，反之亦然？3.是否已詳細說明需求變更的過程？一B性1.是含存在沖突或重復的需求項2.開發(fā)計劃/產(chǎn)品和活動和需求是否保持T3.是否可以根據(jù)軟件需求規(guī)范中的信息制定出詳細的測試集，并且每項需求是否可以測試4.是否有需求跟蹤矩陣1.3.2.2.3評審輸出1 .評審結(jié)果清單2 .根據(jù)評審修訂后的需求規(guī)格說明書1.3.3設(shè)計階段設(shè)計階段包括技術(shù)方案形成、概要設(shè)計、原型設(shè)計、詳細設(shè)計（如果有的話）等工作的完成。1.3.3.1 質(zhì)量指導方針1 .根據(jù)概要設(shè)計文檔模板要求及需求剪裁適合當前

16、項目的模板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é)的更新。1.3,3.2評審管理在設(shè)計階段需要對設(shè)計實現(xiàn)方案、設(shè)計、原型等進行評審；評審的形式按實際的質(zhì)量計劃中要求而定。以下僅提供概要設(shè)計說明的評審準則1.3.3.2.1 評審輸入項概要設(shè)計說明書，需求規(guī)格說明書1.3.3.2.2

17、評審準則概要設(shè)計說明書評審準則評審項評審要求正確性1.設(shè)計說明書的編寫是否按照標準模板來編寫？2.設(shè)計是否正確？是否能夠滿足需求？可行性3.設(shè)計方案在現(xiàn)有條件下是否可行?可理解性4.設(shè)計方案是否能被相關(guān)人員理解?完整性5.是否包括核心功能的實現(xiàn)方案?6. 所有的功能需求與非功能需求是否都體現(xiàn)在了設(shè)計中?7. 在設(shè)計中是否增加了不必要的功能？8. 是否為未來的變更進行了過渡設(shè)計？9. 各子系統(tǒng)、模塊之間的關(guān)系是否描述得清楚10. 系統(tǒng)的設(shè)計是否考慮了系統(tǒng)的可擴展性11. 設(shè)計是否考慮了重用性范文范例指導參考12.重用構(gòu)件是否進行了標識13.是否說明了重用模塊的獲取方式和相關(guān)的文檔14.系統(tǒng)的設(shè)計

18、是否考慮了系統(tǒng)的易移植性15.設(shè)計是否使用標準的技術(shù)，避免使用怪異的、不易理解的方式和方法16.設(shè)計的調(diào)用寬度、調(diào)用深度、耦合度、內(nèi)聚度和結(jié)構(gòu)化程度是否進行了描述可追溯性17.設(shè)計是否可以跟蹤到需求18.需求是否可以追溯到設(shè)計1.3.3.2.3評審輸出評審結(jié)果列表、評審修訂后的概要設(shè)計文檔1.3.4開發(fā)階段開發(fā)階段主要從代碼規(guī)范、代碼走查、調(diào)測等進行控制管理。1.3.4.1 質(zhì)量指導方針1 .約定開發(fā)的編碼規(guī)范2 .約定代碼審計所需的時間及規(guī)則3 .約定開發(fā)階段的調(diào)測方式4 .約定開發(fā)階段自測的標準5 .約定提交版本提交的原則1.3.4.2代碼走查走查項規(guī)范性走查要求編碼是否符合項目或組織的編

19、碼標準備注頭文件包含是否完整參數(shù)在程度開始時是否被初始化參數(shù)在循環(huán)開始時是否被初始化在承數(shù)或過程調(diào)用的時候參數(shù)是否被初始化函數(shù)調(diào)用的格式和參數(shù)是否正確變量的聲明和拼寫是否T變量聲明的范圍是否恰當是否所有的指針都被初始化為NULL程序中申請的內(nèi)存使用后是否釋放是否每個=,|等都驗證了正確性是否打開的文件都及時關(guān)閉了1.3.5測試階段1.3,5,1質(zhì)量指導方針1 .盡早的介入測試，所有的測試都可以追溯到需求2 .在測試相應(yīng)方案啟動之前，必須先理解且分析需求3 .根據(jù)質(zhì)量計劃來制定相應(yīng)的測試計劃4 .測試計劃中需涵蓋所有關(guān)鍵質(zhì)量屬性5 .進行測試計劃評審及修訂6 .建立測試用例對測試需求的覆蓋率7

20、.進行測試用例評審及修訂8 .不同測試階段可有計劃的調(diào)整當前的測試重點1.3,5,2評審管理測試評審包括測試方案、測試用例的評審，一般可分為內(nèi)部評審及外部評審；評審的形式按實際的質(zhì)量計劃中要求而定。以下僅提供測試用例的評審準則。1.3.5.2.1 評審輸入需求規(guī)格說明書、概要設(shè)計說明書、測試計劃、測試用例、1.3.5.2.2 評審準則測試用例評審活動可以確保用例符合優(yōu)秀用例陳述的特征，包括完整、正確、可行、必要、具有優(yōu)先級、無二義性和可驗證性，同時亦符合好的用例特征，即完整性、一致性、易修改和可跟蹤性；評審過程保證用例滿足如下要求：完整性：指有明確的目的、輸入、輸出，提供必要的備注信息；正確性

21、：指每個用例的期望結(jié)果與實際需求一致；可執(zhí)行性：可執(zhí)行性指測試人員根據(jù)測試用例能夠獨立執(zhí)行測試；代表性：指能用最簡單的數(shù)據(jù)，最簡捷的路徑達到測試的目的；唯一性：指在各個測試用例沒有重復交叉的現(xiàn)象；有效性：指每個用例是否有效？是否冗余？是否能夠執(zhí)行；獨立性：是用例與用例之間是否互不依賴？是否能夠獨立執(zhí)行；可讀性：指測試用例描述清晰，邏輯正確，拆分合理；質(zhì)量指標：指是否能夠滿足質(zhì)量指標中的覆蓋率要求，是否可以滿足BUG®度的質(zhì)量要求；內(nèi)部評審準則評審項評審要求備注完整性1 .針對每個測試需求，是含至少有一個止聞用例，是否至少有一個以上反面用例去測試？2 .針對重要測試需求，是否至少使用了

22、兩種以上的設(shè)計方法？唯一性1 .是含存在重復的用例？2 .是否存在可以合并的用例？3 .是否存在需要拆分的用例？4 .是否存在冗余的用例？5 .是否存在無效的用例？獨立性1 .每一個用例的目的、操作過程、期望結(jié)果是否獨立？2 .每一個用例的目的及期望結(jié)果是否保持統(tǒng)一？期望結(jié)果是否過于發(fā)散？可讀性1 ./、同用例之間針對相關(guān)聯(lián)的內(nèi)容描述是否相同？是否存在互斥、矛盾的地方？2 .每個測試用例是否清楚的填寫了測試特性、步驟、預(yù)期結(jié)果？代表性1.是否考慮到測試用例的執(zhí)行效率？怎么樣的步驟組合才是最高效的？評審項評審要求備注2.測試用例是否具有指導性，是否能靈活指導測試人員通過用例發(fā)現(xiàn)更多缺陷,而不是限

23、制他們的思維外部評審準則評審項評審要求備注全面性1 .用例樹結(jié)構(gòu)定義是否合理？2 .用例是否包括如卜方面：功能、界面、性能用例及需求中涉及到的其它方面用例完整性1 .用例是否覆蓋J所有顯性的需求？用例是否覆蓋了所有隱性的需求2 .針對每個測試需求，是e'從止而、反向分別去驗證測試需求？3 .測試用例是否覆蓋每個被測功能的所有可能的輸入輸出的組合？4 .測試用例是否覆蓋正常的輸入輸出組合的所有可能的取值范圍？5 .測試用例是否包括測試了被測試對象的初始化過程？6 .測試用例是否包含了被測對象中所有異常流的測試？7 .是否把最多的測試用例精力放在系統(tǒng)的最主要功能上？8 .針對每個測試用例，

24、是否標識了優(yōu)先級，且標識合理？1 .針對每個期望用例的期望結(jié)果；對開發(fā)的要求是否合理？測試開發(fā)設(shè)計的認識是否一致？2 .用例期望結(jié)果理中與需求保持T?3 .每一個用例的依賴數(shù)據(jù)、期望結(jié)果是否具體到表及字段的變化？質(zhì)量指標1.用例覆蓋率是否達到相應(yīng)質(zhì)量指標？2,用例預(yù)期缺陷率是否達到相應(yīng)質(zhì)量指標？1.3.5.2.3評審輸出評審結(jié)果列表評審修訂通過的測試用例列表1.3.6發(fā)布及維護階段1.3.6.1 質(zhì)量指導方針1 .根據(jù)發(fā)布階段要求準備相應(yīng)的程序及文檔2,及時檢查歸檔的各類資源3.根據(jù)項目特性或公網(wǎng)情況制定現(xiàn)網(wǎng)問題跟蹤流及管理方式4,與用服結(jié)合制定軟件的客戶滿意度調(diào)查單1.3.7質(zhì)量控制中的文檔

25、管理質(zhì)量管理會形成除項目文檔之外的管理文檔，故文檔管理主要為解決項目過程中產(chǎn)生的各類文檔的正確性、唯一性、及時性、有效性所做的相應(yīng)約束。1.3.7.1 文檔分類(1)開發(fā)文檔：這類文檔在軟件項目開發(fā)過程中，體現(xiàn)了軟件開發(fā)人員前一階段工作的成果，同時又是后一階段工作的依據(jù)。這類文檔包括可行性研究報告、軟件項目開發(fā)計劃、軟件需求規(guī)格說明、系統(tǒng)規(guī)格說明書、軟件功能說明書和數(shù)據(jù)字典等。(2)管理文檔：這類文檔在軟件項目開發(fā)過程中，由軟件開發(fā)人員制定的需提交管理部門的一些工作計劃、工作方案和工作報告。通過閱讀這些文檔，管理人員能夠了解軟件項目開發(fā)活動安排、進度、資源使用等情況。這類文檔包括項目開發(fā)計劃、

26、測試計劃、測試方案、開發(fā)進度報告和項目總結(jié)報告等。(3)用戶文檔：這類文檔是軟件開發(fā)人員為使用該軟件的網(wǎng)點經(jīng)辦人員準備的有關(guān)該軟件產(chǎn)品使用、操作的資料，主要是操作手冊及新功能介紹方面的文檔。(4)記錄文檔：與客戶交流往來的記錄、軟件項目開發(fā)過程中各種會議、跟蹤記錄、審查記錄、產(chǎn)品投產(chǎn)記錄和問題跟蹤解決記錄等。(5)反饋文檔：這類文檔主要是軟件產(chǎn)品在推廣使用以后，客戶對產(chǎn)品使用過程中意見及產(chǎn)品缺陷、質(zhì)量等方面的信息反饋。1.3.7.2 文檔管理工具文檔管理工具現(xiàn)在采用VSS管理方式；存放至文檔基線庫。文檔基線庫1.3.7.3 文檔管理的基本要求正確性：所有的文檔都使用相當?shù)臉藴誓０逦臋n中所述的內(nèi)

27、容正確無誤唯一性：每個版本的文檔只有一個。及時性：文檔隨每個任務(wù)的執(zhí)行能夠及時編制及公布有效性：防止無效的文檔歸檔以及過期文檔被誤用。具體要求：1 .所有的文檔都使用相應(yīng)的標準模2 .文檔發(fā)布或歸檔前得到批準3 .必要時對文件進行定期評審與更新4 .確定文件的更改和現(xiàn)行修訂狀況得到識別5 .確保在使用時可獲得有關(guān)版本的適用文件6 .確保文件保持清晰、易于識別7 .確保外部文件得到識別并控制其分發(fā)8 .防止過期文件被誤用，若因任何原因而保留時，需對其進行適當?shù)臉俗R1.3.7.4文檔管理流程根據(jù)現(xiàn)有的狀態(tài)，文檔的管理流程僅涉及歸檔及發(fā)布，如下圖所示：說明:由作者或相應(yīng)負責人提出歸檔申請，必須是評審

28、通過且修改后的文檔方可提出歸檔中請是否及時歸檔的檢查在各個過程中的檢查清單中進行檢查文檔作廢：文檔歸檔發(fā)布后，需同時作廢此文檔之前的相應(yīng)版本。每次進行歸檔后，由歸檔人員統(tǒng)一進行文檔更新發(fā)布歸檔之后的文檔如有再更新的需求，則從基線庫取出來進行更新后，重新歸檔。1.4質(zhì)量度量：制定項目評估項質(zhì)量度量主要針對項目進行評估，從項目的計劃、過程、質(zhì)量、成本、客戶滿意度不同維度進行評估。具體細節(jié)如下。1.4.1 計劃評估計劃評估主要根據(jù)計劃歷史變更記錄來評估計劃的正確、合理性、可實施情況，并為以后的計劃制定提供參考數(shù)據(jù)。主要針對里程碑進行評估，對于非里程碑的計劃變化不進行評估。1.4.1.1 評估基準1

29、.項目啟動時的項目總體計劃、每次變更后的項目計劃、項目結(jié)束時的項目總體計劃2 .項目變動記錄文件1.4.1.2 評估項與上次偏與初始偏評估項第x次變更變更原因離率離率里程碑1劃里程碑2變e里程碑31.4.1.3 總結(jié)1 .計劃變更的主要原因是什么？比如項目計劃不夠詳細，工作安排不夠細致，時間浪費對項目的技術(shù)、工作量等認識不清，導致計劃時間失誤對項目人員的工作效率、特長認識不清，導致計劃時間失誤項目任務(wù)跟蹤不及時，錯過最佳調(diào)整時機1.4.2 過程評估過程評估是根據(jù)項目的每個階段的質(zhì)量指導方針以及檢查結(jié)果來進行的評估，用于檢查各項目的過程控制是否達到應(yīng)有的要求。過程評估最終使用計分的方式來得出過程

30、得分。1.4.2.1 輸入條件每個過程的每次的過程檢查清單1.4,2.2評估記錄評估記錄根據(jù)對不同階段的關(guān)注不同，定出相應(yīng)的百分比，以及每個階段中不同評估項的重點不同，給予不同的分值，最終統(tǒng)計出對過程的總體評分。1.4.2.3 總結(jié)對過程得出的最終分進行分析：1 .哪些過程存在嚴重的質(zhì)量問題？2 .哪些過程缺乏哪些質(zhì)量控制環(huán)節(jié)？3 .哪些質(zhì)量控制環(huán)節(jié)沒有起到相應(yīng)的作用？1.4.3項目質(zhì)量評估質(zhì)量評估主要根據(jù)測試結(jié)果的質(zhì)量評估以及現(xiàn)網(wǎng)問題跟蹤情況進行的評估。1.4.3.1 輸入條件1 .版本質(zhì)量評估報告2 .現(xiàn)網(wǎng)問題跟蹤表1.4.3.2 評估項測試階段評估主要依據(jù)測試各類數(shù)據(jù)根據(jù)質(zhì)量評估標準進行質(zhì)量評估。維護階段評估主要根據(jù)現(xiàn)網(wǎng)問題清單對缺陷率、平均缺陷時間來進行質(zhì)量評估缺陷率：指現(xiàn)網(wǎng)問題數(shù)/總問題率平均缺陷時間（MTF：指平均多久時間反饋一個問題。平均缺陷恢復時間：指出現(xiàn)一個缺陷后，恢復所需要的時間。1.4.3.3 總結(jié)對質(zhì)量情況得出來的評估結(jié)果進行分析。1 .測試結(jié)果反饋情況主要是哪些環(huán)節(jié)中的問題2 .現(xiàn)網(wǎng)問題反饋情況主要是哪些環(huán)節(jié)中的問題3 .測試結(jié)果反饋情況與現(xiàn)網(wǎng)問題反映結(jié)果是否一致通過以上總結(jié)分析出哪個階段所存在的問題最多，測試方法/策略是否存在問題；改善明確存在問題的環(huán)節(jié)。1.4.4成本