使用者需求是衡量軟體質量的基礎。
除滿足明確定義的需求外，還要滿足隱含的需求。
mccall軟體質量模型
**特殊原因，使過程效能穩定，防止質量問題的出現。
預防成本：為防止將缺陷引入軟體而進行的預防工作所消耗的費用。
評價成本：檢查軟體是否包含缺陷的工作所消耗的費用。
失效成本：修復缺陷工作所消耗的成本。
確定專案應達到的質量目標和所有特性的要求；
確定專案中的質量活動和質量控制程式；
確定專案採用的控制手段及合適的驗證手段和方法；
確定和準備質量記錄。
質量要素分析；
質量目標；
人員與職責；
過程檢查計畫；
技術評審計畫；
軟體測試計畫；
缺陷跟蹤工具。
（1）技術評審（technical review）
（2）正式和非正式技術評審
（3）技術評審會議
（4）正式技術評審流程
接受該產品，不需要做修改。
由於錯誤嚴重，拒絕接受。等到錯誤改正後，還要進行另一次評審。
暫時接受該產品，但需要對某一部分進行修改，修改後不需要再進行另一次評審。
（5）技術評審的注意事項
（6）同行評審（peer review）
（7）**評審（code review）
（1）bugzilla的功能和特點：
（2）bugzilla的特點：
（3）bugzilla的基本操作說明
改進軟體過程，降低出錯機率
降低質量成本，實現專案效益
失效(failure)：指軟體系統在執行時其行為偏離了使用者的需求，即缺陷的外部表現。
錯誤(fault)：指存在於軟體內部的問題，如設計錯誤、編碼錯誤等，即缺陷的內部原因。
差錯(error)：指人在理解和解決問題的思維和行為過程中所出現的問題，即缺陷的產生根源。
對小專案，可選擇某一時期內發現的所有缺陷。
對大專案，可選擇乙個缺陷樣本集合。
對缺陷逐個進行分析，常以會議的方式進行。
可對分析出的根本原因進行分類，例如：
ibm：疏忽、培訓、通訊失效、書寫錯誤
在逐個分析了缺陷之後，還要對分析得到的根本原因進行綜合和歸納，識別導致缺陷產生的公共原因，並制定有關過程、技術和人員管理方面的改進措施。
用來評價交付使用的軟體的質量，**什麼時候軟體執行達到基本穩定。
一般以每100小時的故障數為單位。
它用來度量軟體處於穩定狀態下的質量。
一般以每1000小時的故障數為單位。
用來度量軟體的可靠性。
用來度量軟體的可維護性。
通常以每千行無註解**為乙個單位
軟體質量活動必須經過規劃並明文規定
質量活動必須盡早開始
質量小組必須獨立存在
質量小組的人員應該經過必要的培訓
專案中的軟體質量管理
專案中的軟體質量管理 提起軟體質量管理，人們更多地會想起 iso9001 cmm cmmi 這些 質量管理聖經 但國內企業做了這麼多年的質量認證，卻沒有使軟體質量有大幅度地提高。實際上，很多企業通過 iso9001 cmm cmmi 等質量認證的目的就不是為了提高質量 有的企業是為了跟風，有的企業則...
專案中的軟體質量管理
專案中的軟體質量管理 提起軟體質量管理，人們更多地會想起 iso9001 cmm cmmi 這些 質量管理聖經 但國內企業做了這麼多年的質量認證，卻沒有使軟體質量有大幅度地提高。實際上，很多企業通過 iso9001 cmm cmmi 等質量認證的目的就不是為了提高質量 有的企業是為了跟風，有的企業則...
專案中的軟體質量管理
專案中的軟體質量管理 提起軟體質量管理，人們更多地會想起 iso9001 cmm cmmi 這些 質量管理聖經 但國內企業做了這麼多年的質量認證，卻沒有使軟體質量有大幅度地提高。實際上，很多企業通過 iso9001 cmm cmmi 等質量認證的目的就不是為了提高質量 有的企業是為了跟風，有的企業則...