在進行同行評審時，一般可以積累如下的度量資料：
（1） 評審文件或**的規模
對於需求文件的規模一般是採用頁或功能點為度量單位；
對於測試用例的規模一般是採用個或頁為度量單位；
對**的規模一般是採用行為度量單位；
對於設計或其他文件一般是採用頁為度量單位。
（2） 個人評審的時間週期，計量單位為小時；
（3） 評審會議的時間週期，計量單位為小時；
（4） 個人評審發現的缺陷個數，計量單位為個；
（5） 評審會議發現的缺陷個數，計量單位為個；
（6） 缺陷總數=在評審會上確定的缺陷個數；
排除了不是缺陷的發現，以及各位專家重複的發現。
（7） 個人評審的工作量，計量單位為人時；
（8） 評審會議的工作量，計量單位為人時；
（9） 評審的總工作量=個人評審的工作量+評審會議的工作量，計量單位為人時；
（10） 個人評審的速率=個人評審的規模/個人評審的工作量，計量單位為：規模的計量單位/人時；
（11） 評審的總體效率=評審發現的缺陷總數/評審的總工作量，計量單位為：個/人時
（12） 評審發現的缺陷密度，計量單位為：個/規模的計量單位
對於上述資料如何分析與使用呢？請看下面的案例：
場景一：某次需求審查，個人評審階段發現的缺陷為10個，會議上發現的缺陷為20個。
分析：對於審查這種評審方式，發現問題應該主要是在會前發現，而不是在記錄會議上，上述的資料表明個人評審時各位專家的投入不夠，本次評審的質量不高，需要考慮是否重新評審或者採取其他補救措施。
場景二：某次設計審查30頁文件，平均個人評審花費的時間為1小時。
分析：按照業內度量資料，進行設計審查時，平均的速率應該為不超過5頁/小時，本次設計審查個人評審投入的時間不夠。
場景三：某次**走查，花費了1個小時，評審了1000行**。
分析：**走查的速率太快，無法保證評審效果。
場景四：審查20頁的需求文件，有5個專家參與，其中2個專家a花費了1小時進行了個
人評審，其他3位專家沒有進行個人評審。
分析：2位專家投入的個人評審時間偏少，3為專家沒有準備，建議推遲評審的時間以便於各位專家事先進行準備，後者修改評審的方式為走查或技術複審。
場景五：某次**審查，專家a的個人評審速率為：1000行/小時，其他專家的個人評審效率約為300行/小時。
分析：專家a的審查速率太快，無法保證評審效果，建議安排其為記錄員。
場景六：某次需求審查，發現的缺陷密度為2個/頁，組織級的審查退出準則為1.5個/頁。
分析：不能通過評審，需要重新審查，並要進行原因分析，判斷是需求文件本身的質量太差，還是本次審查的水平高、準備充分或是審查的技術手段有改進。
場景七：某次需求審查的效率為1.8個/人時，組織級建立的基線為 0個/人時---1.6個/人時
分析：本次審查的效率超出了組織級基線，過程判定為異常，需要進行特殊原因分析，判斷是審查不夠仔細還是文件太簡單，或者是專家水平高等因素。
場景八：某次需求評審持續進行了1天的時間。
分析：會議週期太長，無法保證各位專家能夠高效地的投入到評審工作中，建議拆分為多次評審。
例解 如何分析同行評審的度量資料？
在進行同行評審時，一般可以積累如下的度量資料 1 評審文件或 的規模 對於需求文件的規模一般是採用頁或功能點為度量單位 對於測試用例的規模一般是採用個或頁為度量單位 對 的規模一般是採用行為度量單位 對於設計或其他文件一般是採用頁為度量單位。2 個人評審的時間週期，計量單位為小時 3 評審會議的時間...
如何有效的評審功能測試用例？
新手測試評審的總結分析 為用例評審提供乙個參考標準，保證評審的覆蓋率和有效性 測試組內部的評審 測試部門成員參與 專案組內部的評審 專案經理 架構設計人員 開發人員和測試人員參與 需求評審 需求實現流程圖評審 測試大綱評審 測試用例檢查 需求評審 a 檢查講解的內容無丟失 b 檢查需求理解無偏差 c...
例解 目標驅動的度量元識別方法
1 識別需要資料的人 person 服務經理 2 識別管理目標 goal 要解決的問題 problem 提高客戶請求的處理速度 3 定義如何量化管理目標 要解決的問題 3.1 識別被度量的物件 object 待處理的客戶變更請求 3.2 識別被度量物件的屬性 attribute 待處理的變更請求的個...