有一個想法，X的平均值不按照樹上的求發，完全按照概率的算法，算出來的結果式不是更科學。即，按照概率書上直接求數學期望和方差的方法。不知道能不能算先進。理論依據到是有的，就是也還是大數定理。
度量中遇到的問題：
1. 收集測試用例文檔頁數不科學。因為在測試小組編寫測試用例是在Excel下面，基本上一個用例的編寫占用一格。因此，考察測試文檔的有效性跟測試用例的有效性雷同，所以文檔的數量度量不再考慮。
開題報告中的問題：
1.偏題。論文研究的主要目的是促進研發。方法，找測試、開發、產品質量的關系。從測試度量角度，度量測試，度量開發，度量產品質量。
實施度量活動的一些經驗教訓：
1.必須獲得高層領導的支持，這是實施度量計劃的基礎
2.成立專門的數據分析小組，成立可以由組織層的數據分析人員和項目經理構成
3.在度量開展之前必須定義度量目標
4.3級中，由于大量文檔的使用，軟件工程室個人的效率會有比較大的下降。因此，充分利用工具來減輕手工勞動強度將有利于軟件開發過程的運用于推廣。
5.度量系統的能力，是和組織軟件過程成熟度關系密切。因此，在軟件過程還不成熟、混亂的情況下，需要制定簡單可行的度量計劃。隨著軟件過程的逐步成熟，再根據需要逐步提高質量系統的能力。
6.長期來看，必須把過程管理建立在數據的基礎上，即使對于CMM2級來說，盡早的積累數據，也是非常有用的。
一點想法，可以將度量分析出來的穩定可控的數據作為評測工作的標準。
實際操作步驟
1.確定當前的評審數據值在控制圖上的位置。
2.如果缺陷密度出于UCL和LCL之內，這就意味著被評審對象的質量可以被接受，修改后可以進入下游活動
3.如果缺陷密度高于UCL，這就意味著被評審的對象的質量不能被接受，采取的措施是修改后重新評審
4.如果缺陷密度低于LCL，這就意味著被評審對象中發現了過少的缺陷，這有兩種可能：
�。�1）評審效率太低，需要重新評審；
�。�2）被評審的質量可能由于某種原因，特別高，這種情況下就不必再評審了。
在第四中情況下，評審小組需要結合自己的經驗來判斷是否需要重新評審。
在執行過程改進之后，比如開展同行評審主席培訓，可以使用一個過程改進因子，比如開展這項培訓可以提高同行評審對象質量20％。這樣，就可以獲得新的過程能力：
均值（新）＝均值（舊）×（1－20％）
UCL（新）＝UCL（舊）×（1－20％）
LCL（新）＝LCL（舊）×（1－20％）
然后，將培訓后開展的培訓數據點，打在新的控制圖上，觀察點的位置。如果大量點落在均值之上，說明培訓的效果沒有達到預計的提高20％的目標，即高估了培訓的效果。這時就要根據新的數據來重新獲得過程能力。如果大量點落在均值之下，說明培訓的效果達到并超過預計的提高20％的目標，即低估了培訓效果，這時也要根據新的數據點來重新獲得過程能力�？傊�，只要新的數據點出現明顯異�；蛘吣撤N模態，就說明過程處于失去控制狀態，需要做進一步的調查來了解實事和真相。
軟件過程模型和標準
1.目標/問題/度量模型GQM(Goal/Question/Metric)
2.統計過程控制模型SPC(Statistical Process Control)
3.ISO/IEC 15939 是一個有關軟件度量過程的國際標準
4.實用軟件度量模型PSM(Practical Software Measurement)是對ISO/IEC 15939的具體實現。其描述了2個模型：度量過程模型MPM(Measurement Process Model)和度量信息模型MIM(Measurement Information Model)
<I-C-M模型>，模型基于"Plan-Do-Check-Act"管理方式
軟件度量概念從1968年被正式。軟件度量的實質是將軟件的屬性數量化。
軟件度量的主要建模方法：其中統計方法類中主要是回歸分析（以多元線性回歸較常用）
Basili所提出的目標/問題/度量(Goal/Question/Metrics,G/Q/M)模型，針對性強靈活性好，且更為重要的是，它可以從小型開始(Start Small),這樣成本不高但見效很快，從而贏得開發人員和管理人員的支持。不過該方法缺乏系統性，需要組織本身來提出一整套系統的、適合于組織自身實際的度量指標體系。
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/
