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

1、xx項目質(zhì)量控制管理方案xx項目質(zhì)量控制管理方案 編輯整理：尊敬的讀者朋友們：這里是精品文檔編輯中心，本文檔內(nèi)容是由我和我的同事精心編輯整理后發(fā)布的，發(fā)布之前我們對文中內(nèi)容進行仔細校對，但是難免會有疏漏的地方，但是任然希望（xx項目質(zhì)量控制管理方案）的內(nèi)容能夠給您的工作和學習帶來便利。同時也真誠的希望收到您的建議和反饋，這將是我們進步的源泉，前進的動力。本文可編輯可修改，如果覺得對您有幫助請收藏以便隨時查閱，最后祝您生活愉快 業(yè)績進步，以下為xx項目質(zhì)量控制管理方案的全部內(nèi)容。第 24 頁 共 24 頁項目質(zhì)量管控方案1 項目質(zhì)量管控方案1.1 前言1.1.1 目的 本計劃的目的在于對所開發(fā)的

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

3、分,致力于滿足質(zhì)量要求5、質(zhì)量保證:質(zhì)量管理的一部分，致力于提供質(zhì)量要求會得到滿足的信任6、質(zhì)量度量：質(zhì)量管理的一部分，致力于對已存在的質(zhì)量數(shù)據(jù)進行分析，得出當前質(zhì)量管理結果的評估數(shù)據(jù)。7、質(zhì)量改進：質(zhì)量管理的一部分,致力于增強滿足質(zhì)量要求的能力1.2 質(zhì)量計劃：制定新項目及維護性項目質(zhì)量計劃在本環(huán)節(jié)中，根據(jù)項目的規(guī)模及性質(zhì)進行質(zhì)量策劃,制定本項目的質(zhì)量計劃；為后續(xù)的質(zhì)量控制、質(zhì)量評估及質(zhì)量改進做出行動綱領.針對公司主要有新項目及維護性項目兩類版本，且兩者之間的質(zhì)量投入有所差異的特性，故質(zhì)量計劃可以區(qū)分以下:1.2.1 常規(guī)項目質(zhì)量計劃要求常規(guī)項目的質(zhì)量計劃制定按質(zhì)量要求分析/質(zhì)量目標/人員.

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

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

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

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

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

9、討論會，需求討論會的與會人員及結果l 聯(lián)調(diào)：是否進行了聯(lián)調(diào),對原版本的影響l 測試執(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ì)量的完成本階段的工作評審管理：主要制定簡單的評審輸入、輸出以及該階段評審的基本準則任務檢查單：用于檢查該階段的任務是否進行以及進行的效果如何常存在的問題：更多的是讓各成員了解一些經(jīng)驗所談會存在哪些問題，可提前預防或糾正1.3.1 計劃階段計

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

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

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

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

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

15、. 是否包含了所有已知的客戶需求或系統(tǒng)需求? 6. 是否已經(jīng)對每個業(yè)務邏輯進行輸入、輸出以及過程的詳細說明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)先級

16、？5. 在現(xiàn)有的資源內(nèi), 是否能實現(xiàn)所有的需求?6. 是否每個需求都可以進行驗證（測試）？5可管理性1. 是否將需求分別陳述，因此它們是獨立的并且是可檢查的？2. 是否所有需求都可以回溯到相應的需求素材，反之亦然？3. 是否已詳細說明需求變更的過程？一致性1. 是否存在沖突或重復的需求項2. 開發(fā)計劃/產(chǎn)品和活動和需求是否保持一致3. 是否可以根據(jù)軟件需求規(guī)范中的信息制定出詳細的測試集，并且每項需求是否可以測試4. 是否有需求跟蹤矩陣1.3.2.2.3 評審輸出1. 評審結果清單2. 根據(jù)評審修訂后的需求規(guī)格說明書1.3.3 設計階段設計階段包括技術方案形成、概要設計、原型設計、詳細設計（如果

17、有的話)等工作的完成。1.3.3.1 質(zhì)量指導方針1. 根據(jù)概要設計文檔模板要求及需求剪裁適合當前項目的模板2. 根據(jù)模板編寫概要設計說明書3. 對于質(zhì)量計劃中的關鍵質(zhì)量屬性在設計中需要重點考慮4. 需要針對項目的結構、項目的特征和用戶的需求來分析，同樣也要考慮到參與項目小組成員的素質(zhì)5. 對于不同的方案分別進行評估6. 對概要設計文檔進行同行評審7. 在設計階段同時完成原型的設計8. 根據(jù)實際需要考慮是否需要進行詳細設計9. 涉及到的需求變更需同步知會其它環(huán)節(jié)的更新。1.3.3.2 評審管理在設計階段需要對設計實現(xiàn)方案、設計、原型等進行評審；評審的形式按實際的質(zhì)量計劃中要求而定。以下僅提供概

18、要設計說明的評審準則1.3.3.2.1 評審輸入項概要設計說明書，需求規(guī)格說明書1.3.3.2.2 評審準則概要設計說明書評審準則評審項評審要求正確性1. 設計說明書的編寫是否按照標準模板來編寫?2. 設計是否正確？是否能夠滿足需求?可行性3. 設計方案在現(xiàn)有條件下是否可行？可理解性4. 設計方案是否能被相關人員理解?完整性5. 是否包括核心功能的實現(xiàn)方案？6. 所有的功能需求與非功能需求是否都體現(xiàn)在了設計中?7. 在設計中是否增加了不必要的功能？ 8. 是否為未來的變更進行了過渡設計？9. 各子系統(tǒng)、模塊之間的關系是否描述得清楚10. 系統(tǒng)的設計是否考慮了系統(tǒng)的可擴展性11. 設計是否考慮了

19、重用性12. 重用構件是否進行了標識13. 是否說明了重用模塊的獲取方式和相關的文檔14. 系統(tǒng)的設計是否考慮了系統(tǒng)的易移植性15. 設計是否使用標準的技術，避免使用怪異的、不易理解的方式和方法16. 設計的調(diào)用寬度、調(diào)用深度、耦合度、內(nèi)聚度和結構化程度是否進行了描述可追溯性17. 設計是否可以跟蹤到需求18. 需求是否可以追溯到設計1.3.3.2.3 評審輸出評審結果列表、評審修訂后的概要設計文檔1.3.4 開發(fā)階段開發(fā)階段主要從代碼規(guī)范、代碼走查、調(diào)測等進行控制管理.1.3.4.1 質(zhì)量指導方針1. 約定開發(fā)的編碼規(guī)范2. 約定代碼審計所需的時間及規(guī)則3. 約定開發(fā)階段的調(diào)測方式4. 約定

20、開發(fā)階段自測的標準5. 約定提交版本提交的原則1.3.4.2 代碼走查走查項走查要求備注規(guī)范性編碼是否符合項目或組織的編碼標準頭文件包含是否完整參數(shù)在程度開始時是否被初始化參數(shù)在循環(huán)開始時是否被初始化在承數(shù)或過程調(diào)用的時候參數(shù)是否被初始化函數(shù)調(diào)用的格式和參數(shù)是否正確變量的聲明和拼寫是否一致變量聲明的范圍是否恰當是否所有的指針都被初始化為null程序中申請的內(nèi)存使用后是否釋放是否每個=，|等都驗證了正確性是否打開的文件都及時關閉了1.3.5 測試階段1.3.5.1 質(zhì)量指導方針1. 盡早的介入測試，所有的測試都可以追溯到需求2. 在測試相應方案啟動之前，必須先理解且分析需求3. 根據(jù)質(zhì)量計劃來制

21、定相應的測試計劃4. 測試計劃中需涵蓋所有關鍵質(zhì)量屬性5. 進行測試計劃評審及修訂6. 建立測試用例對測試需求的覆蓋率7. 進行測試用例評審及修訂8. 不同測試階段可有計劃的調(diào)整當前的測試重點1.3.5.2 評審管理測試評審包括測試方案、測試用例的評審，一般可分為內(nèi)部評審及外部評審；評審的形式按實際的質(zhì)量計劃中要求而定。以下僅提供測試用例的評審準則.1.3.5.2.1 評審輸入需求規(guī)格說明書、概要設計說明書、測試計劃、測試用例、1.3.5.2.2 評審準則測試用例評審活動可以確保用例符合優(yōu)秀用例陳述的特征，包括完整、正確、可行、必要、具有優(yōu)先級、無二義性和可驗證性， 同時亦符合好的用例特征,即

22、完整性、一致性、易修改和可跟蹤性；評審過程保證用例滿足如下要求：l 完整性:指有明確的目的、輸入、輸出，提供必要的備注信息；l 正確性：指每個用例的期望結果與實際需求一致;l 可執(zhí)行性：可執(zhí)行性指測試人員根據(jù)測試用例能夠獨立執(zhí)行測試；l 代表性:指能用最簡單的數(shù)據(jù)，最簡捷的路徑達到測試的目的；l 唯一性：指在各個測試用例沒有重復交叉的現(xiàn)象；l 有效性：指每個用例是否有效？是否冗余？是否能夠執(zhí)行；l 獨立性:是用例與用例之間是否互不依賴？是否能夠獨立執(zhí)行;l 可讀性：指測試用例描述清晰，邏輯正確，拆分合理;l 質(zhì)量指標：指是否能夠滿足質(zhì)量指標中的覆蓋率要求,是否可以滿足bug密度的質(zhì)量要求；n

23、內(nèi)部評審準則評審項評審要求備注完整性1. 針對每個測試需求，是否至少有一個正面用例,是否至少有一個以上反面用例去測試？2. 針對重要測試需求，是否至少使用了兩種以上的設計方法?唯一性1. 是否存在重復的用例?2. 是否存在可以合并的用例？3. 是否存在需要拆分的用例？4. 是否存在冗余的用例？5. 是否存在無效的用例？獨立性1. 每一個用例的目的、操作過程、期望結果是否獨立?2. 每一個用例的目的及期望結果是否保持統(tǒng)一？期望結果是否過于發(fā)散？可讀性1. 不同用例之間針對相關聯(lián)的內(nèi)容描述是否相同？是否存在互斥、矛盾的地方？2. 每個測試用例是否清楚的填寫了測試特性、步驟、預期結果？代表性1. 是

24、否考慮到測試用例的執(zhí)行效率？怎么樣的步驟組合才是最高效的？2. 測試用例是否具有指導性,是否能靈活指導測試人員通過用例發(fā)現(xiàn)更多缺陷,而不是限制他們的思維n 外部評審準則評審項評審要求備注全面性1. 用例樹結構定義是否合理？2. 用例是否包括如下方面：功能、界面、性能用例及需求中涉及到的其它方面用例完整性1. 用例是否覆蓋了所有顯性的需求？用例是否覆蓋了所有隱性的需求2. 針對每個測試需求，是否從正面、反面分別去驗證測試需求？3. 測試用例是否覆蓋每個被測功能的所有可能的輸入輸出的組合?4. 測試用例是否覆蓋正常的輸入輸出組合的所有可能的取值范圍？5. 測試用例是否包括測試了被測試對象的初始化過

25、程？6. 測試用例是否包含了被測對象中所有異常流的測試?7. 是否把最多的測試用例精力放在系統(tǒng)的最主要功能上？8. 針對每個測試用例,是否標識了優(yōu)先級，且標識合理？1. 針對每個期望用例的期望結果；對開發(fā)的要求是否合理？測試開發(fā)設計的認識是否一致？2. 用例期望結果理中與需求保持一致？3. 每一個用例的依賴數(shù)據(jù)、期望結果是否具體到表及字段的變化？質(zhì)量指標1. 用例覆蓋率是否達到相應質(zhì)量指標？ 2. 用例預期缺陷率是否達到相應質(zhì)量指標？1.3.5.2.3 評審輸出評審結果列表評審修訂通過的測試用例列表1.3.6 發(fā)布及維護階段1.3.6.1 質(zhì)量指導方針1. 根據(jù)發(fā)布階段要求準備相應的程序及文檔

26、2. 及時檢查歸檔的各類資源3. 根據(jù)項目特性或公網(wǎng)情況制定現(xiàn)網(wǎng)問題跟蹤流及管理方式4. 與用服結合制定軟件的客戶滿意度調(diào)查單1.3.7 質(zhì)量控制中的文檔管理質(zhì)量管理會形成除項目文檔之外的管理文檔，故文檔管理主要為解決項目過程中產(chǎn)生的各類文檔的正確性、唯一性、及時性、有效性所做的相應約束。1.3.7.1 文檔分類(1)開發(fā)文檔：這類文檔在軟件項目開發(fā)過程中,體現(xiàn)了軟件開發(fā)人員前一階段工作的成果，同時又是后一階段工作的依據(jù).這類文檔包括可行性研究報告、軟件項目開發(fā)計劃、軟件需求規(guī)格說明、系統(tǒng)規(guī)格說明書、軟件功能說明書和數(shù)據(jù)字典等。(2)管理文檔：這類文檔在軟件項目開發(fā)過程中，由軟件開發(fā)人員制定的

27、需提交管理部門的一些工作計劃、工作方案和工作報告。通過閱讀這些文檔，管理人員能夠了解軟件項目開發(fā)活動安排、進度、資源使用等情況.這類文檔包括項目開發(fā)計劃、測試計劃、測試方案、開發(fā)進度報告和項目總結報告等。（3）用戶文檔:這類文檔是軟件開發(fā)人員為使用該軟件的網(wǎng)點經(jīng)辦人員準備的有關該軟件產(chǎn)品使用、操作的資料，主要是操作手冊及新功能介紹方面的文檔。(4）記錄文檔：與客戶交流往來的記錄、軟件項目開發(fā)過程中各種會議、跟蹤記錄、審查記錄、產(chǎn)品投產(chǎn)記錄和問題跟蹤解決記錄等。(5）反饋文檔：這類文檔主要是軟件產(chǎn)品在推廣使用以后，客戶對產(chǎn)品使用過程中意見及產(chǎn)品缺陷、質(zhì)量等方面的信息反饋。1.3.7.2 文檔管理

28、工具文檔管理工具現(xiàn)在采用vss管理方式；存放至文檔基線庫.文檔基線庫1.3.7.3 文檔管理的基本要求l 正確性：所有的文檔都使用相當?shù)臉藴誓０逦臋n中所述的內(nèi)容正確無誤l 唯一性：每個版本的文檔只有一個。l 及時性：文檔隨每個任務的執(zhí)行能夠及時編制及公布l 有效性：防止無效的文檔歸檔以及過期文檔被誤用.具體要求：1. 所有的文檔都使用相應的標準模2. 文檔發(fā)布或歸檔前得到批準3. 必要時對文件進行定期評審與更新4. 確定文件的更改和現(xiàn)行修訂狀況得到識別5. 確保在使用時可獲得有關版本的適用文件6. 確保文件保持清晰、易于識別7. 確保外部文件得到識別并控制其分發(fā)8. 防止過期文件被誤用，若因任

29、何原因而保留時，需對其進行適當?shù)臉俗R1.3.7.4 文檔管理流程根據(jù)現(xiàn)有的狀態(tài)，文檔的管理流程僅涉及歸檔及發(fā)布，如下圖所示：說明：n 由作者或相應負責人提出歸檔申請，必須是評審通過且修改后的文檔方可提出歸檔申請n 是否及時歸檔的檢查在各個過程中的檢查清單中進行檢查n 文檔作廢：文檔歸檔發(fā)布后，需同時作廢此文檔之前的相應版本。n 每次進行歸檔后，由歸檔人員統(tǒng)一進行文檔更新發(fā)布n 歸檔之后的文檔如有再更新的需求,則從基線庫取出來進行更新后，重新歸檔。1.4 質(zhì)量度量：制定項目評估項質(zhì)量度量主要針對項目進行評估,從項目的計劃、過程、質(zhì)量、成本、客戶滿意度不同維度進行評估。具體細節(jié)如下。1.4.1 計

30、劃評估計劃評估主要根據(jù)計劃歷史變更記錄來評估計劃的正確、合理性、可實施情況，并為以后的計劃制定提供參考數(shù)據(jù)。主要針對里程碑進行評估,對于非里程碑的計劃變化不進行評估.1.4.1.1 評估基準1項目啟動時的項目總體計劃、每次變更后的項目計劃、項目結束時的項目總體計劃2項目變動記錄文件1.4.1.2 評估項評估項第x次變更變更原因與上次偏離率%與初始偏離率計劃變更里程碑1里程碑2里程碑31.4.1.3 總結1計劃變更的主要原因是什么？比如n 項目計劃不夠詳細，工作安排不夠細致，時間浪費n 對項目的技術、工作量等認識不清，導致計劃時間失誤n 對項目人員的工作效率、特長認識不清，導致計劃時間失誤n 項

31、目任務跟蹤不及時,錯過最佳調(diào)整時機1.4.2 過程評估過程評估是根據(jù)項目的每個階段的質(zhì)量指導方針以及檢查結果來進行的評估，用于檢查各項目的過程控制是否達到應有的要求。過程評估最終使用計分的方式來得出過程得分.1.4.2.1 輸入條件每個過程的每次的過程檢查清單1.4.2.2 評估記錄評估記錄根據(jù)對不同階段的關注不同,定出相應的百分比，以及每個階段中不同評估項的重點不同,給予不同的分值，最終統(tǒng)計出對過程的總體評分。1.4.2.3 總結對過程得出的最終分進行分析：1. 哪些過程存在嚴重的質(zhì)量問題？2. 哪些過程缺乏哪些質(zhì)量控制環(huán)節(jié)？3. 哪些質(zhì)量控制環(huán)節(jié)沒有起到相應的作用？1.4.3 項目質(zhì)量評估

32、質(zhì)量評估主要根據(jù)測試結果的質(zhì)量評估以及現(xiàn)網(wǎng)問題跟蹤情況進行的評估.1.4.3.1 輸入條件1版本質(zhì)量評估報告2現(xiàn)網(wǎng)問題跟蹤表1.4.3.2 評估項n 測試階段評估主要依據(jù)測試各類數(shù)據(jù)根據(jù)質(zhì)量評估標準進行質(zhì)量評估.n 維護階段評估主要根據(jù)現(xiàn)網(wǎng)問題清單對缺陷率、平均缺陷時間來進行質(zhì)量評估u 缺陷率：指現(xiàn)網(wǎng)問題數(shù)/總問題率u 平均缺陷時間（mtf）：指平均多久時間反饋一個問題。u 平均缺陷恢復時間：指出現(xiàn)一個缺陷后，恢復所需要的時間。1.4.3.3 總結對質(zhì)量情況得出來的評估結果進行分析.1 測試結果反饋情況主要是哪些環(huán)節(jié)中的問題2 現(xiàn)網(wǎng)問題反饋情況主要是哪些環(huán)節(jié)中的問題3 測試結果反饋情況與現(xiàn)網(wǎng)問題反映結果是否一致通過以上總結分析出哪個階段所存在的問題最多，測試方法/策略是否存在問