品質測量並不限於測試期間所發現的缺陷，還包括經由需求、設計、程式碼、測試程序及其他軟體工作物同儕審查所發現的缺陷。使用已識別之測量，依照使用的普遍情況，下列只是所能產生之度量的樣本：
● 缺陷優先序(工業標準常規、IEEE、國際標準化組織(ISO)、國際電工委員會(IEC)等等)。
● 缺陷總數。
● 隨時間推移開啟的缺陷數。
● 隨時間推移解決或關閉的缺陷數。
● 由於測試問題造成的時程變更(增加時間)。
● 缺陷年齡，或缺陷圍堵(亦即，未於下一個或之後的階段中發現)及“滲漏”至之後階段的百分比。
● 缺陷密度(以錯誤之總數除以總SLOC，若可以，最好依組態項目、使用案例或模組或軟體包或物件等區分，但罕見)。
● 重工人時數。
● 計畫vs.實際的缺陷計數。
● 修補的成本。
● 缺陷根本成因(遺失或誤解的需求、過程違反、工具錯誤等等)。
● 計畫vs.實際重工成本及時程。
● 計畫vs.實際缺陷績效指標。

　　軟體專案經理須考慮那些項目要接受品質保證及管制，而更重要的是，要建立那些基準值，以供計畫及實際品質的比較。應使用專案的工作拆解結構，作為產品品質清單的來源。此外，須為品質的測試與測量，建立源自產品需求之已定義且量化的離去準則。各品質項目可能發生之缺陷數估算值的訂定，須以先前發展工作的歷史資料為根據。亦須予考量的事項，還有專案計畫全景及期望之範圍內，可預期及可接受的測試與重工量。
　　基準標的包括為各產品類別，符合計畫與契約需求，須處之可接受品質水準，而建立之高低水準範圍。在此情況下，產品品質基準是演繹自歷史資料及計畫與契約所設定之特定需求的組合。可接受的品質須根據系統履行任務重要能力，所能被接受的退化程度及/或對系統發展或生命週期支援的衝擊予以定義。以下是判定系統品質水準的指導原則：
◎無優先序1或2的缺陷。
◎為每個交付QA/QC的產品，規定優先序3缺陷的最大可接受標準差水準。驗證僅為與人類互動有關的缺陷指派優先序3。
◎為每個交付QA/QC的產品，規定優先序4及5的最大可接受標準水準。
　　最終，品質基準須為各項工作產品的驗收建立臨限。換句話說，就是宣告產品符合或超越所有需求的離去準則為何？同樣的，其須識別產品發展期間，相較於先前的發展努力，什麼樣的缺陷水準是合理的，而且是可以接受的，以符合計畫利害相關者的期望。
---from Guidebook for Acquisition of Naval Software Intensive Systems

----------------
引文: