某項目質量控制管理方案

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

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

3、如下所述。1.2.1.1質要素分析主要的質要性如下：功能性質因素：正確性，健壯性，可靠性非功能性質因素：性能，用性，清晰性，安全性，可擴展性，兼容性，可移 植性其它質因素：非以上要求之外的要求。根據(jù)產品的特性及市場目標，將關鍵的質要素確認，同時區(qū)分本頊目的類型傾質型頊目：指本頊目對質控制關注傾成本型頊目：指本頊目對成本控制關注傾工期型頊目：指本頊目對工期要求關注根據(jù)以上分析，再制定相應的質目標。訂質目標時，一般遵循 SMART原則S : specific 具體的M : measurable 可測的A : achievable可取得的R : realistic 實的T : timely及時的根據(jù)

4、以上原則，我們可以制定如下質目標：比如本項目的質要素為功能正確性、功能健壯性、性能那質目標可定義下：需求中所定義的功能得以實現(xiàn)穩(wěn)定問題（等級非輕微）被解決關鍵模塊（模塊名稱）的性能能低于 V1.0版本針對質目標定由優(yōu)先級1、3、2目標分解分解為階段質目標完成階段依目標的手段1.2.1.3人員與職責參加質管活動的人員，一般情況下，項目組所有的人可以參與到質管活動中來。但我們一般可定義如下人員去分別承擔相應的職責。質管人員：制定質管計劃，對質過程進控制；對過程檢查單進實施； 進質，制定質改進計劃及實施；參與各類評審活動。測試人員：制定測試計劃，對項目進測試，進測試結果的分析；參與各類評 審活動。項

5、目管人員：協(xié)助組織解決質管過程中所發(fā)現(xiàn)的各類問題及風險。1.2.1.4質保障計劃根據(jù)當前的質目標，計劃需要進哪些質保障工作，一般可包括專業(yè)培訓、同級評 審、測試。培訓確認是否需要培訓確認培訓的內容、人員、時間，以及所耗費的資源。評審確認評審內容及計劃；需要包括評審的內容、評審的方式以及評審的人員等等。對評審結果的跟蹤、管方式。測試根據(jù)當前的質目標，確定測試的初步計劃，包括測試的范圍及測試方法、手段以及投入的人及時間資源1.2.1.5過程檢查計劃根據(jù)當前的質目標，制定或目過程中需要愴查g對象、如：階段檢A寸象檢查時機次數(shù) 檢查執(zhí)人員檢查依舞計劃階段計劃階段的產出頊目組成 之 后至計劃階段 結束3

6、次寸應測試接口人根據(jù)計劃階段愴查清單進愴查需求階段需求評審需求評審啟動1次寸應測試接口人根據(jù)需求階段愴查清單進愴查。1.2.2維護，性頊目質計劃要求誼護性頊目的質計劃制定才叩對簡單，需要花較多的時間在其上，并且可以全用比較固定的模板0誼護性頊目基本上會有很明確的需求點以及具體的時間點要求，一般情況下，誼護時期會很 長，且需求相對較散、小，針對這些特性，維護性頊目的質計劃要求僅可以包括：質目 標、質保障計劃、過程愴查計劃。1.2.2.1質目標根據(jù)當前的需求簡單定由大版本的質目標。1.2.2.2質保障計劃在維護性項目中，質保障計劃主要包括：需求討論、聯(lián)調以及測試。需求討論：參與人員包括開發(fā)及測試人

7、員；需求討論結果報告聯(lián)調：對所做的修改及周邊進聯(lián)調；聯(lián)調測試報告測試：根據(jù)質目標制定相應的測試計劃安排，1.2.2.3過程檢查計劃無論質目標定為如何，維護性項目的過程愴查，僅需要如下環(huán)節(jié)：需求討論會：是否進需求討論會，需求討論會的與會人員及結果聯(lián)調：是否進聯(lián)調，對原版本的影響測試執(zhí)：對測試過程進愴查1.3質保證與控制質保證與控制是質管中最重要的一個環(huán)節(jié)，質目標是否能夠有效的實現(xiàn)有賴于此環(huán)節(jié)的實施控制。本環(huán)節(jié)根據(jù)質保障計劃、過程愴查計劃對版本開發(fā)的各過程定出質指導方針、評審環(huán)節(jié)規(guī)則以及愴查清單。其中質指導方針：用于簡要指 引如口何高質的）完成本階段的工作評審管 ：主要制定簡單的評審輸入、輸出以及

8、該階段評審的基本準則任務檢查單：用于愴查該階段的任務是否進以及進的效果如何常存在的問題：多的是讓各成員解一些經驗所談會言在哪些問題，可提前預防或糾1.3.1 計劃階段計劃階段指從項目啟動至項目總體計劃制定完成的階段。1.3.1.1質指導方針在項目的計劃階段，期望產出高質的項目總體計劃，建議遵守以下原則：根據(jù)項目總體計劃模板、項目總體計劃編制說明書的指導原則進計劃編排計劃制定時需結合實際并與相關人員進必要的溝通解項目背景、項目目標以及可調動的資源等計劃制定時需考慮相應風險及應對措施：如人員變動、需求變化、技術難題對于把控準的項目進同層面的評審1.3.1.2評審管計劃階段的評審主要指項目總體計劃的

9、評審。1.3.1.2.1評審輸入項項目總體計劃以及當前項目原始需求等相關資1.3.1.2.2評審準則項目總體計劃的評審主要從完整性、正確性、合性、可管性進評審。評寸項評審要求備注完整性是否包括從需求至發(fā)布各個階段的任務計劃？是否對各任務的交付件定義質要求？評審項評審要求備注正確性各階段定義是否正確？各子任務所屬的階段是否正確？臺性各個任務的先后順序是否臺？并安排是否合？各任務分配的資源是否合？各任務細化的程是否合？任務與任務之間的約束是否合？各階段的時間投入比是否臺？頊目的結束時間，是否與客戶承諾的一致頊目的計劃中是否考慮一些常見的風險？對風險的應對是否體現(xiàn)在計劃中？可管性對于每個階段是否有明

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

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

12、目標是否已定義？2.是否對關鍵術語及縮語進定義？3,是否有對整套系統(tǒng)進功能概述？2 正確性1.需求與需求之間是否有重復或沖突？2.本需求說明書與相關需求素材是否一致？3,是否清晰、簡潔、無二義地表達每個需求?4.是否每個需求在項目的范圍內5.是否每個需求沒有內容和語法上的錯誤?3 完整性1.編寫的所有需求，其詳細程是否一致和合適?2.需求是否能為設計提供足夠的基礎？3.所有對其他需求的內部引用是否正確？4. 是否已經由系統(tǒng)所必要的依賴/假設以及約束5.是否包含所有已知的客戶需求或系統(tǒng)需求 ?6.是否已經對每個業(yè)務邏輯進輸入、輸出以及過程的詳細說明7. 是否已詳細說明軟件環(huán)境（共存的軟件）和硬件

13、環(huán)境（特定的配 置）8. 是否遺必要的信息？如果有遺的話，把他們標記為待確定的評審項評審要求備注問題(TBD) ?9,是否包括主噗的質屬性，如性能噗求、安全性噗求、可靠性噗求、可恢復性噗求、穩(wěn)定性噗求等等10.是否分析潛在的需求11,是否標識并解決需求中的潛城的問題4 .可性1.所描述的所有功能是否必噗？2.所描述的所有功能是否充分的滿足客戶/系統(tǒng)目標？3,已知的限制（局限）是否已經詳細說明？4, 是否已經確定每個需求的實現(xiàn)優(yōu)先級？5,在現(xiàn)有的資源內,是否能實現(xiàn)所有的需求？6,是否每個需求可以進驗正（測試）？5 可管性1, 是否將需求分別陳述，因此它們是獨的并且是可檢查的？2,是否所有需求可以

14、回溯到相應的需求素材，反之亦然？3,是否已詳細說明需求變的過程？-致性1,是否存在沖突或重復的需求頊2,開發(fā)計劃/產品和活動和需求是否保持一致3,是否可以根據(jù)軟件需求規(guī)范中的信息制定由詳細的測試集，并且每頊需求是否可以測試4,是否有需求跟蹤矩陣1.3.2.2.3評審輸出評審結果清單根據(jù)評審修訂后的需求規(guī)格說明書1.3.3 設計階段設計階段包括技術方案形成、概要設計、原型設計、詳細設計（如果有的話）等工作的 完成。1.3.3.1質指導方針根據(jù)概要設計文檔模板要求及需求剪裁適合當前項目的模板根據(jù)模板編寫概要設計說明書對于質計劃中的關鍵質屬性在設計中需要重點考慮需要針對項目的結構、項目的特征和用戶的

15、需求來分析，同樣也要考慮到參與項目小 組成員的素質對于同的方案分別進評估對概要設計文檔進同評審在設計階段同時完成原型的設計根據(jù)實際需要考慮是否需要進詳細設計涉及到的需求變需同步知會其它環(huán)節(jié)的新。1.3.3.2評審管在設計階段需要對設計實現(xiàn)方案、設計、原型等進評審；評審的形式按實際的質計 劃中要求而定。.以下僅提供概要設計說明的評審準則1.3.3.2.1評審輸入項概要設計說明書，需求規(guī)格說明書1.3.3.2.2評審準則概要設計說明書評審準則評審項評審要求正確性1.設計說明書的編寫是否按照標準模板來編寫？2.設計是否正確？是否能夠滿足需求？可性3.設計方案在現(xiàn)有條件下是否可？可解性4.設計方案是否

16、能被相關人員解？完整性5.是否包括核心功能的實現(xiàn)方案？6.所有的功能需求與非功能需求是否體現(xiàn)在設計中？7.在設計中是否增加必要的功能？8.是否為未來的變進過渡設計？9.各子系統(tǒng)、模塊之間的關系是否描述得清楚10.系統(tǒng)的設計是否考慮系統(tǒng)的可擴展性11.設計是否考慮重用性范文范例指導參考重用構件是否進標識是否說明重用模塊的獲取方式和相關的文檔系統(tǒng)的設計是否考慮系統(tǒng)的移植性設計是否使用標準的技術，避免使用怪異的、解的方式和方 法設計的調用寬、調用深、耦臺、內聚和結構化程是否進 描述可追溯性設計是否可以跟蹤到需求需求是否可以追溯到設計1.3.3.2.3評審輸出評審結果表、評審修訂后的概要設計文檔1.3

17、.4開發(fā)階段開發(fā)階段主要從代碼規(guī)范、代碼走查、調測等進控制管。1.3.4.1節(jié)指導方針約定開發(fā)的編碼規(guī)范約定代碼審計所需的時間及規(guī)則約定開發(fā)階段的調測方式約定開發(fā)階段自測的標準約定提交版本提交的原則1.3.4.2代碼走查走查項走查要求備注規(guī)范性編碼是否符合頊目或組織的編碼標準頭文件包含是否完整參數(shù)在程開始時是否被初始化參數(shù)在循環(huán)開始時是否被初始化在承數(shù)或過程調用的時候參數(shù)是否被初始化函數(shù)調用的格式和參數(shù)是否正確變的聲明和拼寫是否一致變聲明的范圍是否，恰當是否所有的布針被初始化為 NULL程序中申請的內存使用后是否釋放是否每個二二,|等驗正正確性是否打開的文件及時關閉1.3.5測試階段1.3.5

18、.1質指導方針盡早的介入測試，所有的測試可以追溯到需求在測試相應方案啟動之前，必須先解且分析需求根據(jù)質計劃來制定相應的測試計劃測試計劃中需涵蓋所有關鍵質屬性進測試計劃評審及修訂建瀏試用對測試需求的覆蓋進瀏試用評審及修訂同測試階段可有計劃的調整當前的測試重點1.3.5.2評審管測試評審包括測試方案、測試用的評審，一般可分為內部評審及外部評審；評審的形 式按實際的質計劃中要求而定。以下僅提供測試用的評審準則。1.3.5.2.1評審輸入需求規(guī)格說明書、概要設計說明書、測試計劃、測試用、1.3.5.2.2評審準則測試用評審活動可以確保用符合優(yōu)秀用陳述的特征，包括完整、正確、可、必要、具有優(yōu)先級、無二義

19、性和可驗正性，同時亦符合好的用特征，即完整性、一致性、修改和可跟蹤性；評審過程保證用滿足如下要求：完整性：指有明確的目的、時入、時出，提供必要的備注信息；正確性：指每個用的期望結果與實際需求一致；可執(zhí)性：可執(zhí)性指測試人員根據(jù)測試用能夠獨執(zhí)測試；代表性：布能用最簡單的數(shù)據(jù)，最簡捷的徑達到測試的目的；唯一性：布在各個測試用沒有重復交叉的現(xiàn)象；有效性：指每個用是否有效？是否冗余？是否能夠執(zhí)；獨性：是用與用之間是否互依賴？是否能夠獨執(zhí)；可讀性：指測試用描述清晰，邏輯正確，拆分合；質指標：指是否能夠滿足質指標中的覆蓋要求，是否可以滿足BUG密的質要求；內部評審準則評審項評審要求備注完整性針對每個測試需求

20、，是否至少有一個正面用，是否至少有一個以上反面用去測試？針對重噗測試需求，是否至少使用兩種以上的 設計方法？唯-性是否存在重復的用？是否存在可以合并的用？是否存在需噗拆分的用？是否存在冗余的用？是否存在無效的用？獨性每一個用的目的、 操作過程、期望結果是否獨？每一個用的目的及期望結果是否保持統(tǒng)一？期望結果是否過于發(fā)散？可讀性同用之間針對相關聯(lián)的內容描述是否相同？是否存在互斥、矛盾的地方？每個測試用是否清楚的填寫測試特性、步驟、預期結果？代表性1.是否考慮到測試用的執(zhí)效？怎么樣的步驟組合才是最高效的？評審項評審要求備注2.測試用是否具有指導性，是否能靈活指導測試人員通過用發(fā)現(xiàn)多缺陷 ，而是限制他

21、們的思維外部評審準則評審項評審要求備注全面性用時結構定義是否合？用是否包括如下方面：功能、界面、性能用及需求中涉及到的其它方面用完整性用是否覆蓋所有顯性的需求？用是否覆蓋所有隱性的需求針對每個測試需求，是否從正面、反面分別去驗證測試需求？測試用是否覆蓋每個被測功能的所有可能的輸入輸出的組合？測試用是否覆蓋正常的輸入輸出組合的所有可能的取值范圍？測試用是否包括測試被測試對象的初始化過程？測試用是否包含被測對象中所有異常的測試？是否把最多的測試用放在系統(tǒng)的最主要功能上？針對每個測試用，是否標識優(yōu)先級，且標識針對每個期望用的期望結果；對開發(fā)的要求是否臺？測試開發(fā)設計的認識是否一致？用期望結果中與需求

22、保持一致？每一個用的依賴數(shù)據(jù)、期望結果是否具體到表及字段的變化？質指標用覆蓋是否達到相應質指標用預期缺陷是否達到相應質指標1.3.5.2.3評審輸出評審結果表評審修訂通過的測試用表發(fā)布及維護階段1.3.6.1質指導方針根據(jù)發(fā)布階段要求準備相應的程序及文檔及時檢查歸檔的各類資源根據(jù)項目特性或公網情況制定現(xiàn)網問題跟蹤及管方式與用服結合制定軟件的客戶滿意調查單質控制中的文檔管質管會形成除項目文檔之外的管文檔，故文檔管主要為解決項目過程中產生的 各類文檔的正確性、唯-性、及時性、有效性所做的相應約束。1.3.7.1寸檔分類開發(fā)文檔：這類文檔在軟件項目開發(fā)過程中，體現(xiàn)軟件開發(fā)人員前一階段工作的成 果，同

23、時又是后一階段工作的依據(jù)。這類文檔包括可性研究報告、軟件項目開發(fā)計劃、軟 件需求規(guī)格說明、系統(tǒng)規(guī)格說明書、軟件功能說明書和數(shù)據(jù)字典等。管文檔：這類文檔在軟件項目開發(fā)過程中，由軟件開發(fā)人員制定的需提交管部門 的一些工作計劃、工作方案和工作報告。通過閱讀這些文檔，管人員能夠解軟件項目開 發(fā)活動安排、進、資源使用等情況。這類文檔包括項目開發(fā)計劃、測試計劃、測試方案、 開發(fā)進報告和項目總結報告等。用戶文檔：這類文檔是軟件開發(fā)人員為使用該軟件的網點經辦人員準備的有關該軟件 產品使用、操作的資，主要是操作手冊及新功能介紹方面的文檔。記錄文檔：與客戶交往來的記錄、軟件項目開發(fā)過程中各種會議、跟蹤記錄、審查

24、記錄、產品投產記錄和問題跟蹤解決記錄等。反饋文檔：這類文檔主要是軟件產品在推廣使用以后，客戶對產品使用過程中意見及 產品缺陷、質等方面的信息反饋。1.3.7.2文檔管工具文檔管工具現(xiàn)在采用 VSS管方式；存放至文檔基線庫。文檔基線庫1.3.7.3寸檔管的基本要求正確性：所有的文檔使用相當?shù)臉藴誓０逦臋n中所述的內容正確無誤唯一性：每個版本的文檔只有一個。及時性：文檔隨每個任務的執(zhí)能夠及時編制及公布有效性：防止無效的文檔歸檔以及過期文檔被誤用。具體要求：所有的文檔使用相應的標準模文檔發(fā)布或歸檔前得到批準必要時對文件進定期評審與新確定文件的改和現(xiàn)修訂狀況得到識別確保在使用時可獲得有關版本的適用文件確

25、保文件保持清晰、于識別確保外部文件得到識別并控制其分發(fā)防止過期文件被誤用，因任何原因而保時，需對其進適當?shù)臉俗R1.3.7.4文檔管程根據(jù)現(xiàn)有的狀態(tài)，文檔的管程僅涉及歸檔及發(fā)布，如下圖所示：說明:日作者或相應負責人提出歸檔申請，必須是評審通過且修改后的文檔方可提出歸檔申請是否及時歸檔的檢查在各個過程中的檢查清單中進檢查文檔作廢：文檔歸檔發(fā)布后，需同時作廢此文檔之前的相應版本。每次進歸檔后，由歸檔人員統(tǒng)一進文檔新發(fā)布歸檔之后的文檔如有再新的需求，則從基線庫取出來進新后，重新歸檔。1.4質：制定項目評估項質主要針對頊目進評估，從頊目的計劃、過程、質、成本、客戶滿意同 維進評估。具體細節(jié)如下。1.4.

26、1計劃評估計劃評估主要根據(jù)計劃歷史變記錄來評估計劃的正確、合性、可實施情況，并為 后的計劃制定提供參考數(shù)據(jù)。主要針對程碑進評估，對于非程碑的計劃變化進評 估。1.4.1.1評估基準總體與初始偏離%1 頊目啟動時的頊目總體計劃、每次變后的頊目計劃、頊目結束時的頊目 計劃2頊目變動記錄文件1.4.1.2評估項與上次偏評估項 第x次交交原因離 %程碑 1計劃程碑 2程碑 31.4.1.3 總結1 計劃變的主要原因是么？比如項目計劃夠詳細，工作安排夠細致，時間費對項目的技術、工作等認識清，導致計劃時間失誤對項目人員的工作效、特長認識清，導致計劃時間失誤項目任務跟蹤及時，錯過最佳調整時機1.4.2 過程

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