＜專案名稱＞
作者完成日期
簽收人簽收日期
修改情況記錄：
目錄1 引言 1
1.1 目的 1
1.2 定義和縮寫詞 1
1.3 參考資料 1
2 管理 1
2.1 機構 1
2.2 任務 2
2.3 職責 2
3 文件 2
3.1 基本文件 2
3.1.1 軟體需求規格說明書 2
3.1.2 軟體設計說明書 2
3.1.3 軟體驗證與確認計畫 3
3.1.4 軟體驗證與確認報告 3
3.1.5 使用者文件 3
3.2 其他文件 3
4 標準、條例和約定 4
5 評審和檢查 4
5.1 軟體需求評審 4
5.2 概要設計評審 4
5.3 詳細設計評審 4
5.4 軟體驗證與確認評審 4
5.5 功能檢查 4
5.6 物理檢查 5
5.7 綜合檢查 5
5.8 管理評審 5
6 軟體配置管理 5
7 工具、技術和方法 5
8 **控制 6
9 對供貨單位的控制 6
10 記錄的收集、維護和儲存 6
11 附錄 6
11.1 附錄a：專案進展報表 6
11.2 附錄b：專案階段評審表 11
本條必須指出特定的軟體質量保證計畫的具體目的。還必須指出該計畫所針對的軟體專案（及其所屬的各個子專案）的名稱和用途。
應該列出計畫正文中需要解釋的而在gb/t 11457中尚未包含的術語的定義，必要時，還要給出這些定義的英文單詞及其縮寫詞。
列出要用到的參考資料，如：
a． 本專案的經核准的計畫任務書或合同、上級機關的批文；
b． 屬於本專案的其他已發表的檔案；
c． 本檔案中各處引用的檔案、資料，包括所要用到的軟體開發標準。
列出這些檔案的標題、檔案編號、發表日期和出版單位，說明能夠得到這些檔案資料的**。
必須描述負責軟體質量保證的機構、任務及其有關的職責。
必須描述與軟體質量保證有關的機構的組成。還必須清楚地描述來自專案委託單位、專案承辦單位、軟體開發單位或使用者中負責軟體質量保證的各個成員在機構中的相互關係。
描述計畫所涉及的軟體生存週期中有關階段的任務，特別要把重點放在描述這些階段所應進行的軟體質量保證活動上。
指明軟體質量保證計畫中規定的每乙個任務的負責單位或成員的責任。
為了確保軟體的實現滿足需求，至少需要下列基本文件。
軟體需求規格說明書必須清楚、準確地描述軟體的每乙個基本需求（功能、效能、設計約束和屬性）和外部介面。必須把每乙個需求規定成能夠通過預先定義的方法（例如檢查、分析、演示或測試等）被客觀地驗證與確認的形式。軟體需求規格說明書的詳細格式按gb 8567。
軟體設計說明書應該包括軟體概要設計說明和軟體詳細設計說明兩部分。其概要設計部分必須描述所設計軟體的總體結構、外部介面、各個主要部件的功能與資料結構以及各主要部件之間的介面性和時還必須對主要部件的每乙個子部件進行描述。其詳細設計部分必須給出每乙個基本部件的功能、演算法和過程描述。
軟體設計說明書的詳細格式按gb 8567。
軟體驗證與確認計畫必須描述所採用的軟體驗證和確認方法（例如評審、檢查、分析、演示或測試等），以用來驗證軟體需求規格說明書中的需求是否已由軟體設計說明書描述的設計實現；軟體設計說明書表達的設計是否已由編碼實現。軟體驗證與確認計畫還可用來確認編碼的執行是否與軟體需求規格說明書中所規定的需求相一致。軟體驗證與確認計畫的詳細格式按gb 8567中的測試計畫的格式。
軟體驗證與確認報告必須描述軟體驗證與確認計畫的執行結果。這裡必須包括軟體質量保證計畫所需要的所有評審、檢查和測試的結果。軟體驗證與確認報告的詳細格式按gb 8567中的測試報告的格式。
使用者文件（例如手冊、摜等）必須指明成功執行該軟體所需要的資料、控制命令以及執行條件等；必須指明所有的出錯資訊、含義及其修改方法；還必須描述將使用者發現的錯誤或問題通知專案承辦單位（或軟體開發單位）或專案委託單位的方法。使用者文件的詳細格式按gb 8567。
除基本文件外，還應包括下列文件：
a． 專案實施計畫（其中可包括軟體配置管理計畫，但在必要時也可單獨制訂該計畫），其詳細格式按gb 8567。
b． 專案進展報表：其詳細格式可參考本計畫附錄a中有關《專案進展報表》的各項規定。
c． 專案開發各階段的評審報表：其詳細格式可參考本計畫附錄b中有關《專案階段評審表》的各項規定。
d． 專案開發總結：其詳細格式按gb 8567。
必須列出軟體開發過程中要用到的標準、條例和約定，並列出監督和保證執行的措施。
必須規定所要進行的技術和管理兩方面的評審和檢查工作，並編制或引用有關的評審和檢查規程以及通過與否的技術準則。至少要進行下列各項評審和檢查工作：
在軟體需求分析階段結束後必須進行軟體需求評審，以確保在軟體需求規格說明書中所規定的各項需求的合適性。
在軟體概要設計階段結束後必須進行概要設計評審，以評價軟體設計說明書中所描述的軟體概要設計在總體機構、外部介面、主要部件功能分配、全域性資料結構以及各主要部件之間的介面等方面的合適性。
在軟體詳細設計階段結束後必須進行詳細設計評審，以確定軟體設計說明書中所描述的詳細設計在功能、演算法和過程描述等方面的合適性。
在制訂軟體驗證與確認計畫之後要對它進行評審，以評價軟體驗證與確認計畫中所規定的驗證與確認方法的合適性與完整性。
在軟體釋放前，要對軟體進行檢查，以確認已經滿足在軟體需求規格說明書中規定的所有需求。
在驗收軟體前，要對軟體進行物理檢查，以驗證程式和文件已經一致並已做好了交付的準備。
在軟體驗收時，要允許使用者或使用者所委託的專家對所要驗收的軟體進行設計抽樣的綜合檢查，以驗證**和設計文件的一致性、介面規格說明之間的一致性（硬體和軟體）、設計實現和功能需求的一致性、功能需求和測試描述的一致性。
要對計畫的執**況定期（或按階段）進行管理評審；這些評審必須由獐獨立於被評審單位的機構或授權的第三方主持進行。
必須編制有關軟體配置管理的條款，或引用按照gb/t 12505單獨制訂的。在這些條款或文件中，必須規定用於標識軟體產品、控制和實現軟體的修改、記錄和報告修改實現的狀態以及評審和檢查配置管理工作等四方面的活動。還必須規定用以維護和儲存軟體受控版本的方法和設施；必須規定對所發現的軟體問題進行報告、追蹤和解決的步驟，並指出實現報告、追蹤和解決軟體問題的機構及其職責。
必須指明用以支援特定軟體專案質量保證工作的工具、技術和方法，指出它們的目的，描述它們的用途。
必須指出保護電腦程式物理**的方法和設施，以免非法訪問、意外損壞或自然老化。
供貨單位包括專案承辦單位、軟體銷售單位、軟體開發單位或軟體子開發單位。必須規定對這些供貨單位進行控制的規程，從而保證專案承辦單位從軟體銷售單位購買的、其他開發單位（或子開發單位）開發的或從開發（或子開發）單位現存軟體庫中選用的軟體能滿足規定的需求。
必須指明需要儲存的軟體質量保證活動的記錄，並指出用於彙總、保護和維護這些記錄的方法和設施，並指明要儲存的期限。
專案進展報表（月報表或季報表）由乙個專案進展報表表頭（表a1）和另外三個**（表a2、表a3、表a4）組成。在表a2「軟體階段進度表」中，要填寫各個階段的開工日期與結束日期。其中計畫進度是指在專案實施計畫中確定的計畫進度，因此可以由管理事先填好，而不必由開發人員填寫。
實際進度是指該專案實際的開工日期與結束日期，它將隨著該項目的不斷進度來填寫。其中調整進度是指專案組長發現實現進度與計畫進度不符時提出的進度修改建議；但經專案管理人員研究後，可能對此修改建議作某些更改。此外，在相繼的若干次報表中，專案組長提出的建議修改日期也可能是不相同的。
在此我們規定，最終的調整進度由專案經理來確定。在表a3「軟體階段產品完成情況表」中，要填寫各個文件的開始編寫日期與完成日期。其中關於對計畫進度、調整進度與實際進度的含義的解釋與上相同。
表a4是關於統計軟體開發費用的**。
軟體質量保證計畫
摘要 簡要描述該文件的內容。修改歷史 注釋 評審號為評審記錄表的編號。更改請求號為文件更改控制工具自動生成的編號。目錄1 概述 4 1.1 目的和範圍 4 1.2 軟體質量保證計畫維護 4 1.3 參考資料 4 2 角色與職責 4 2.1 角色 4 2.2 職責 4 3 審核標準 4 4 過程能力與...
軟體質量保證計畫
版本號 1.0 文件修訂 批准人簽字 抄送 軟體專案經理 sqa經理 專案組成員 sccb成員目錄1.概述 4 1.1 目的 4 1.2專案背景 4 1.3範圍 4 1.4術語定義 4 2.專案基本情況 4 3.sqa 組的資源要求 4 4.sqa組織結構和責任 4 4.1組織結構 4 4.2 職責...
軟體質量保證
結課 班級 軟體09k2 姓名 彭奇 學號 0919 軟體質量保證 sqa 是建立一套有計畫，有系統的方法，來向管理層保證擬定出的標準 步驟 實踐和方法能夠正確地被所有專案所採用。軟體質量保證的目的是使軟體過程對於管理人員來說是可見的。它通過對軟體產品和活動進行評審和審計來驗證軟體是合乎標準的。軟體...