5、很關鍵的--質量
預計缺陷總數
實際缺陷總數
預計致命缺陷
實際致命缺陷
預計主要缺陷
實際主要缺陷
預計次要缺陷
實際次要缺陷
預計遺留缺陷數
實際遺留缺陷數
需求階段預計發現缺陷
需求階段實際發現缺陷
設計階段預計發現缺陷
設計階段實際發現缺陷
構建階段預計發現缺陷
構建階段實際發現缺陷
測試階段預計發現缺陷
測試階段實際發現缺陷
實施階段預計發現缺陷
實施階段實際發現缺陷
交付后1個月內發現總缺陷
交付后1個月內發現致命缺陷
交付后1個月內發現主要缺陷
交付后1個月內發現次要缺陷
需求活動預計引入缺陷
需求活動實際引入缺陷
需求活動實際引入缺陷(需求時發現)
需求活動實際引入缺陷(設計時發現)
需求活動實際引入缺陷(編碼時發現)
需求活動實際引入缺陷(測試時發現)
需求活動實際引入缺陷(實施時發現)
需求活動預計清除缺陷
需求活動實際清除缺陷
設計活動預計引入缺陷
設計活動實際引入缺陷
設計活動實際引入缺陷(設計時發現)
設計活動實際引入缺陷(編碼時發現)
設計活動實際引入缺陷(測試時發現)
設計活動實際引入缺陷(實施時發現)
設計活動預計清除缺陷
設計活動實際清除缺陷
編碼活動預計引入缺陷
編碼活動實際引入缺陷
編碼活動實際引入缺陷(編碼時發現)
編碼活動實際引入缺陷(測試時發現)
編碼活動實際引入缺陷(實施時發現)
編碼活動預計清除缺陷
編碼活動實際清除缺陷
測試活動預計引入缺陷
測試活動實際引入缺陷
測試活動預計清除缺陷
測試活動實際清除缺陷
實施活動預計引入缺陷
實施活動實際引入缺陷
實施活動預計清除缺陷
實施活動實際清除缺陷
項目在開發前應該預估會有多少bug，根據bug的修改時間知道要多少返工，以及測試輪次。這些數據也可以反映，因需求不清導致多少bug?引入bug的影響率?以及銷售、交付后有多少bug?這些數據有了，考核都有了。
例如，交付后1個月返工的bug，考核測試與開發、項目經理、總監等。
再例如，你前面有規模估計，自然能預估會有多少bug。以代碼行為例，標準如果是千行bug率在千分之3，那么你是10w行規模則會預計bug300個，測試1輪如果可以發現100個的話要3輪測試。開發測試計劃中你制定2輪不合理了，1輪1周，那需要3周，你給2周也不合理了。
綜上可見，度量是項目管理的靈魂。如何根據當前階段能力，選擇關鍵的度量點是qa、總監要很清醒的。不能不度量，也不能度量過度。以上5點做好了，這家公司基本是正規的公司了。其他的，一些其他高級度量點等再成熟了再度量
