軟件項目質(zhì)量規(guī)劃

軟件項目質(zhì)量規(guī)劃包括以下內(nèi)容：
□ 質(zhì)量標(biāo)準(zhǔn)和政策
□ 質(zhì)量目標(biāo)
□ 角色和職責(zé)
□ 質(zhì)量管理活動
□ 風(fēng)險評估
□ 缺陷預(yù)防措施

軟件項目質(zhì)量標(biāo)準(zhǔn)和政策

質(zhì)量標(biāo)準(zhǔn)和質(zhì)量政策存在組織過程資產(chǎn)中，通常由專人負(fù)責(zé)不斷地更新并發(fā)布。

質(zhì)量標(biāo)準(zhǔn)和質(zhì)量政策可以是軟件供應(yīng)商本身的要求，也可以是用戶方提出的要求，根據(jù)項目的具體情況而定。

軟件項目依據(jù)的質(zhì)量標(biāo)準(zhǔn)和質(zhì)量政策：
□ 編碼標(biāo)準(zhǔn)
□ 文檔標(biāo)準(zhǔn)

軟件項目質(zhì)量目標(biāo)

軟件項目的質(zhì)量目標(biāo)描述了組織內(nèi)部或用戶方的接受標(biāo)準(zhǔn)，組織內(nèi)部的接受標(biāo)準(zhǔn)來自于組織的質(zhì)量管理計劃。項目經(jīng)理可以根據(jù)項目情況定義項目具體的質(zhì)量目標(biāo)：

1. 產(chǎn)品目標(biāo)
□ 項目交付缺陷密度 Defects per K FPs <= 30
□ 程序開發(fā)生產(chǎn)率 FPs/Hour > 0.18
□ 錯誤修正百分比 No. of Bad Fixes / No. of Delivered Tickets < 1%

2. 流程執(zhí)行目標(biāo)
□ 客戶滿意度調(diào)查分?jǐn)?shù) PAST >= 85
□ 項目進度偏差 ±5%

軟件項目角色

軟件項目職責(zé)

1. 項目經(jīng)理
□ 合同履約的負(fù)責(zé)人
□ 項目計劃的制定和執(zhí)行監(jiān)督人
□ 項目組織的指揮員
□ 項目協(xié)調(diào)工作的紐帶
□ 項目控制的中心等

2. 系統(tǒng)分析小組
□ 起草用戶需求報告
□ 系統(tǒng)可行性分析報告、系統(tǒng)需求說明書和設(shè)計任務(wù)書等
□ 制定系統(tǒng)開發(fā)計劃
□ 制定系統(tǒng)測試方案
□ 制定系統(tǒng)試運行計劃等

3. 開發(fā)小組
□ 配合系統(tǒng)分析人員完成軟件系統(tǒng)及模塊的需求調(diào)研與需求分析
□ 配合系統(tǒng)分析人員完成軟件系統(tǒng)及模塊的設(shè)計
□ 編制與項目相關(guān)的技術(shù)文檔
□ 完成軟件系統(tǒng)及模塊的編碼
□ 完成單元測試
□ 協(xié)助測試人員完成軟件系統(tǒng)及模塊的測試

4. 測試小組
□ 設(shè)計測試計劃和測試策略
□ 編制測試軟件，準(zhǔn)備測試數(shù)據(jù)
□ 編寫測試用例
□ 搭建測試環(huán)境，執(zhí)行測試
□ 編寫測試報告
□ 跟蹤缺陷

5. 配置管理組
□ 完善各個部門發(fā)送需要存檔和進行版本控制的代碼、文檔（包括外來文件）和階段性成果
□ 對代碼、文檔等進行單向出入的控制
□ 對所有存檔的文檔進行版本控制
□ 提供文檔規(guī)范，并傳達到開發(fā)組中

6. 質(zhì)量保證組
□ 系統(tǒng)分析人員是否正確的反映了用戶的需求
□ 軟件執(zhí)行是否正確的實現(xiàn)了分析人員的設(shè)計思想
□ 測試人員是否進行了較為徹底的和全面的測試
□ 配置管理員是否對文檔的規(guī)范化進行的比較徹底，版本控制是否有效

軟件項目質(zhì)量活動

1. 項目管理計劃評審。

2. 項目配置管理計劃評審。

3. 項目質(zhì)量管理計劃評審。

4. 需求評審。

5. 外部設(shè)計評審。

6. 內(nèi)部設(shè)計評審。

7. 代碼評審。

8. 測試計劃評審。

9. 測試用例評審。

10. 測試：
□ 單元測試
□ 集成測試
□ 系統(tǒng)測試
□ 驗收測試

11. 項目管理QA評審。

12. 過程改進。

13. 交付物驗收評審。

14. 根本原因分析RCA。

15. 項目總結(jié)會等。

軟件項目風(fēng)險評估

項目風(fēng)險評估包括風(fēng)險管理規(guī)劃、風(fēng)險識別、風(fēng)險分析、風(fēng)險應(yīng)對規(guī)劃和風(fēng)險監(jiān)控等各個過程。項目風(fēng)險管理的目標(biāo)在于提高項目積極事件的概率和影響，降低項目消極事件的概率和影響：

1. 規(guī)劃風(fēng)險管理
定義如何實施項目風(fēng)險管理活動的過程。

2. 識別風(fēng)險
判斷哪些風(fēng)險會影響項目并記錄其特征的過程。

3. 實施定性風(fēng)險分析
評估并綜合分析風(fēng)險的發(fā)生概率和影響，對風(fēng)險進行優(yōu)先排序，從而為后續(xù)分析或行動提供基礎(chǔ)的過程。

4. 實施定量風(fēng)險分析
就已識別風(fēng)險對項目整體目標(biāo)的影響進行定量分析的過程。

5. 規(guī)劃風(fēng)險應(yīng)對
針對項目目標(biāo)，制定提高機會、降低威脅的方案和措施的過程。

6. 監(jiān)控風(fēng)險
在整個項目中，實施風(fēng)險應(yīng)對計劃、跟蹤已識別風(fēng)險、監(jiān)測殘余風(fēng)險、識別新風(fēng)險和評估風(fēng)險過程有效性的過程。

軟件項目缺陷分布

項目各個階段缺陷分布情況：

需求說明書編寫原則

需求人員加強與客戶之間的溝通，需求說明書的編寫應(yīng)遵循以下八大原則：

1. 功能與實現(xiàn)分離，即描述做什么而不是這樣實現(xiàn)。

2. 使用面向處理的規(guī)格說明語言，討論來自環(huán)境的各種刺激可能導(dǎo)致系統(tǒng)做出什么樣的功能性反映，來定義一個行為模型，從而得到做什么的規(guī)格說明。

3. 如果目標(biāo)軟件只是一個大系統(tǒng)中的一個元素，那么整個大系統(tǒng)也要包括在規(guī)格說明的描述之中。描述該目標(biāo)軟件與系統(tǒng)的其他系統(tǒng)元素交互的方式。

4. 規(guī)格說明必須包括系統(tǒng)運行的環(huán)境。

5. 系統(tǒng)規(guī)格說明必須是一個認(rèn)識的模型，而不是設(shè)計或?qū)崿F(xiàn)的模型。

6. 規(guī)格說明必須是可操作的，以便能夠利用它決定對于任意給定的測試用例，已提出的實現(xiàn)方案是否都能夠滿足規(guī)格說明。

7. 規(guī)格說明必須容許不完備性并允許擴充。

8. 規(guī)格說明必須局部化和松散的耦合。局部化，當(dāng)信息被修改時，只要修改某個段落。松散的耦合，以便能夠很容易地加入和刪除段落。

設(shè)計的技術(shù)標(biāo)準(zhǔn)

1. 設(shè)計出來的結(jié)構(gòu)應(yīng)是分層結(jié)構(gòu)，從而建立軟件分成之間的控制。

2. 設(shè)計應(yīng)當(dāng)模塊化，從邏輯上將軟件劃分為完成特定功能或子功能的構(gòu)建。

3. 設(shè)計應(yīng)當(dāng)既包含數(shù)據(jù)抽象，也包含過程抽象。

4. 設(shè)計應(yīng)當(dāng)建立具有獨立功能特征的模塊。

5. 設(shè)計應(yīng)當(dāng)建立能夠降低模塊與外部環(huán)境之間復(fù)雜連接的接口。

6. 設(shè)計應(yīng)能根據(jù)軟件需求分析獲取得信息，建立可驅(qū)動、可重復(fù)的方法。

編碼的缺陷預(yù)防措施

編碼的缺陷預(yù)防措施主要有：
□ 統(tǒng)一編碼規(guī)范
□ 代碼評審
□ 常見編碼錯誤規(guī)避
□ 單元測試