軟件度量專家索林根(Van Solingen)在《聚焦產品的軟件過程改善》(Product Focused Software Process Improvement)中詳細闡述了軟件度量項目工程(Measurement program engineering)，提出軟件度量的十大方針，如下所示。
1. 準備讓軟件開發者參與軟件度量項目；
2. 開始軟件度量工程前了解軟件產品的質量目標、過程模型和學習目的；
3. 軟件度量項目工程為目標導向，確保具備有限但相關的度量設定；
4. 指定期望值(假設)；
5. 由具有實際度量經驗的人員按照規則對度量數據作出分析和解釋；
6．將度量數據的分析和解釋聚焦于：詳細而精確的過程行為、全局過程、或者產品質量目標，但是決非聚焦于個人績效；
7. 執行專門資源(人員)來支持度量項目工程的開發團隊；
8. 評價實際產品質量和目標產品質量的差距；
9. 評價過程行為的影響(產品質量方面)；
10. 將特定情景中過程行為的知識存儲到經驗數據庫中。
高爾發的關鍵成功因素：九大要素
品質與生產力管理集團(Q/P Management Group)總裁斯科特·高爾發(Scott Goldfarb)在《建立有效的度量體系》(Establishing a Measurement Program)中認為，建立并實施有效軟件度量體系的關鍵成功因素包括如下：
1. 確定度量目標和計劃；
2. 獲得高層管理者的支持；
3. 擁有專屬資源；
4. 面向員工的培訓、教育和營銷推廣；
5. 日常工作中的度量一體化；
6. 聚焦于項目團隊的結果；
7. 度量不要針對個人；
8. 有效定義數據以及實情報告制度；
9. 推動度量自動化。
軟件工程研究所的軟件度量規則：二十八條規則
美國卡內基·梅隆大學軟件工程研究所在《軟件度量指南》中列出了如下軟件度量的規則：
1. 理解軟件度量方法只是達到目的的手段，而其本身并不是目的；
2. 以應用度量結果而不是收集數據為中心；
3. 理解度量的目標；
4. 理解如何應用度量方法；
5. 設定期望值；
6. 制定計劃以實現早期成功；
7. 以局部為重點；
8. 從小處著手；
9. 將開發人員與分析人員分開；
10. 確信度量方法適合要實現的目標；
11. 將度量次數保持在最低水平；
12. 避免浮夸度量數據；
13. 編制度量工作成本；
14. 制定計劃使數據收集速度至少是數據分析和應用的3倍；
15. 至少每月收集一次關于工作投入水平的數據；
16. 明晰關于工作投入水平數據收集的范圍；
17. 僅收集受控軟件的錯誤數據；
18. 不要指望準確地度量糾錯工作；
19. 不要指望找到界定完善的放之四海而皆準的過程度量方法；
20. 不要指望找到過程度量的數據庫；
21. 理解高級過程的特征；
22. 應用關于生命周期階段的簡單定義；
23. 用代碼行表示規模；
24. 明確將哪些軟件納入度量范圍；
25. 不要指望使數據收集工作自動化；
26. 使提供數據的工作更容易；
27. 使用商業上可用的工具；
28. 認為度量數據存在瑕疵、不精確也不穩定。
帕克的目標驅動軟件度量原則：四大原則體系
帕克(Robert E. Park)、哥特(Wolfhart B. Goethert)和弗羅哈克(William A. Florac)在1996年的《目標驅動軟件度量指導手冊》(Goal-Driven Software Measurement—— A Guidebook)中提出軟件度量的原則如表5-10所示：
表5-10 帕克的目標驅動軟件度量原則
1. 部門管理者的度量原則
—— 設立清晰的目標；
—— 讓員工協助定義度量手段；
—— 提供積極的管理監督：尋求和使用數據；
—— 理解員工報告的數據；
—— 不要使用度量數據來獎賞或者懲罰實施度量的員工，并確信他們知道你和其他任何人都遵守這一規則；
—— 建立保護匿名的慣例，對匿名提供保護將建立起信任并培育起可靠數據的收集機制；
—— 如果員工的報告基于對組織有用的數據，支持他們；
—— 不要強調那些排斥其他度量方式的某種度量方式或者指標。
2. 項目管理者的度量原則
—— 知曉組織的戰略性焦點并強調支持該戰略的度量手段；
—— 在追蹤的度量手段上與項目組獲得一致，并在項目計劃中定義這些度量手段；
—— 向項目組提供規則有序的關于其所收集數據的反饋；
—— 不要私人單獨地進行度量。
3. 項目組的度量原則
—— 盡最大努力報告準確而及時的數據；
—— 協助在管理中將項目數據聚焦于改善軟件過程；
—— 不要使用軟件度量夸耀自身的優秀，否則這將鼓勵其他人使用其他數據展示其反面。
4. 通用原則
—— 軟件度量本身不要成為一個戰略；
—— 在軟件過程改善的全局戰略中整合軟件度量，為此應該擁有或者開發一種這樣的戰略來聯合軟件度量計劃；
—— 帶著共同目標與課題從點滴做起；
—— 設計一種持續的軟件度量過程，以使其：
? 與組織目標與宗旨相聯系
? 包括嚴格的定義
? 持續實施；
—— 在廣泛實施所設計的度量手段和過程之前進行測試；
—— 對軟件度量手段和度量活動的效果進行度量和監控。
弗羅哈克的實用軟件度量原則：十大原則
弗羅哈克(William A.Florac)、帕克(Robert E.Park)和卡爾頓(Anita D.Carleton)在《實用軟件度量：過程管理和改善度量》(Practical Software Measurement：Measuring for Process Management and Improvement)中提出成功的過程度量原則如下。
1. 過程度量受商業目標驅動；
2. 過程度量手段源自軟件過程；
3. 有效度量需要明確闡述的可操作性的定義；
4. 不同的人擁有不同的度量觀點和需求；
5. 度量結果必須在產生結果的過程和環境中檢驗；
6. 過程度量應當跨越整個生命周期；
7. 保持的數據應當提供分析未來的實際基線；
8. 度量是進行客觀溝通交流的基礎；
9. 在項目內部和項目之間對數據進行總計和比較需要細心和規劃；
10. 結構性的度量過程將強化數據的可靠性。
軟件度量的要點：來自實戰的教訓
軟件度量這一作業本身比較難以在實際的軟件開發中順利操作，也難以在軟件開發改善中產生立竿見影的效果，甚至會讓人覺得這是枯燥無味的無用功。這往往會形成妨礙實施軟件度量的阻力，挫傷軟件度量人員的積極性和熱情。那么，如何有效地推動軟件度量，就成為軟件度量作業的重點課題。下面是軟件度量作業的要點，可以作為推動軟件度量作業的參考。
1. 從點滴開始。與其采用聲勢浩大的軟件度量運動，還不如從點滴開始：讓員工逐漸進入度量狀態，避免因為大規模運動帶來的不適和阻力。從點滴開始，從小規模的簡單的度量項目開始，從能夠吸引員工并能讓其接納的度量項目開始，保證軟件度量能在避免受挫的情況下得以逐漸推進，同時盡可能提高軟件度量的自動化程度。
2. 解釋為什么。這是消除抵制情緒和消解阻力的重要環節，因為人們不會切實地踐行那些他們沒有真正理解和接納的理念和措施。需讓員工明白，使用度量將比沒有任何度量要好；度量將在一定程度上增進對軟件開發的理解、預測、評估、控制和改善；軟件度量僅僅針對軟件產品、項目和過程，而不針對個人；等等。
3. 根據項目實情加以具體實施。不同的項目擁有不同的產品、流程、環境、目標和顧客，顧客、軟件開發人員、項目組甚至經營者對項目的需求也不同，必須聚焦于解決該項目在產品、流程等方面的問題，而不是直接套用以前曾經實施或者已經模式化的度量標準。
4. 共享數據。度量數據的共享這一行為本身具有四大好處：一則可以讓員工感受到度量的切實性，即行動正在按照計劃進展；二則可以為員工提供度量的反饋信息，以改進現狀；三則可以通過比較，尋找最佳實踐，實施標桿學習；四則可以通過數據共享增進信任，消除軟件度量可能帶來的誤解。
5. 保持簡單易懂。簡單易懂這一點對于降低度量過程中的理解成本、溝通成本和實施成本都不可或缺。因為軟件開發人員沒有必要成為軟件度量理論、統計方法以及度量技術的專家，他們僅僅需要知道軟件度量與解決問題之間的關系，知道如何簡單高效地實施度量。
6. 塑造度量文化。在軟件開發中有意識地塑造一種重視記錄、親近數據、偏好圖表、基于度量進行作業的習慣或者說文化，將判斷、分析和決策立基于可預測性、可控制性、可改善性之上。
軟件度量的陷阱：直面銅板的反面
就像銅板的正反兩面，軟件度量也具有正反兩個方面的影響：正面效用在于通過度量獲得定量化的可控過程，負面影響在于其過度濫用帶來的危害，比如：
1. 軟件開發的量化指標替代了開發目標。軟件開發管理中定量化極為重要，這當然是指有目的的、毫無浪費的、明確的定量化。如果視軟件度量為目的，那么軟件度量就會陷入可悲的誤區：純粹的量化指標替代了目標，數據淹沒了宗旨，任務迷糊了方向，軟件度量成為軟件開發過程的目標而不是手段，成為應付考核和評價的功利性工具。指標僅僅是個反光鏡，而不是行進的指向標。如果不能理解軟件度量在商務上的目標，那么就會出現這樣的情況：收集了錯誤的數據，以及數據沒有被正確使用。要想接近目標，雙眼必須注視前方。
2. 軟件開發的度量方法取代了度量理念。軟件度量不僅僅包含著豐富多樣的度量方法，更包含著博大精深的度量理念；不僅僅需要理解軟件度量的方式方法，更要踐行軟件度量的理念。如果僅僅拘泥于軟件度量的方式方法而忽略更為本質、更為精髓、更為深刻的理念，那么軟件度量對于軟件開發的意義就不再重要，因為這種情況下的軟件度量雖然獲得了看似完美的軀殼，卻丟失了靈魂。
3. 軟件開發的度量結果成為獎懲的根本依據。軟件度量的結果如果成為考核和獎懲的根本依據，那么就偏離了軟件度量的用途：軟件度量只針對項目、產品和過程，用于對軟件項目、產品和過程進行理解、分析、預測、評估和改善；軟件度量從不針對個人，既不用于評估個人的能力，也不用于評估個人的績效，更不用于作為個人獎懲的根據，這樣才能保持數據的可靠性、客觀性和準確性。如果軟件度量針對個人，這將從根本上影響個人的態度和行為，并危害團隊的績效。永遠不要讓軟件度量成為軟件開發人員心理上的負擔。
過程影響公司的首席咨詢顧問卡爾·威格在其《軟件度量的十大陷阱》一文中總結了軟件度量應該避免的十大陷阱：
1. 缺乏管理承諾；
2. 度量得太多太早；
3. 度量得太少太晚；
4. 度量了錯誤的事項；
5. 度量定義不嚴密；
6. 度量用于評估個人；
7. 度量用于激勵而非理解；
8. 僅僅收集但不使用數據；
9. 缺乏溝通和培訓；
10. 曲解度量數據。
軟件度量并非神話，從其誕生之日起就沒有預言過任何神話。軟件度量僅僅是增進軟件理解、預測、評價、控制和改善的富有助益的路徑。如果僅僅寄希望于以統計為基礎的軟件度量來獲取軟件開發的所謂“銀彈”，就需要重溫那句富有諷刺意味的名言：謊言有三種，即謊言、該死的謊言、統計數據。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
