軟體度量常用方法

① 什麼是軟體度量

軟體度量是對軟體開發項目、過程及其產品進行數據定義、收集以及分析的持續性定量化過程，目的在於對此加以理解、預測、評估、控制和改善。沒有軟體度量，就不能從軟體開發的暗箱中跳將出來。通過軟體度量可以改進軟體開發過程，促進項目成功，開發高質量的軟體產品。度量取向是軟體開發諸多事項的橫斷面，包括顧客滿意度度量、質量度量、項目度量、以及品牌資產度量、知識產權價值度量，等。度量取向要依靠事實、數據、原理、法則；其方法是測試、審核、調查；其工具是統計、圖表、數字、模型；其標準是量化的指標。

② 軟體度量的原則和軟體度量實施的方法

原則：不要為了考核開發者而度量，度量是為了解現狀，牽引能力提升；
方法：關鍵KPI，一般從質量、效率、成本三個方面設置度量指標；

③ 軟體測試中對軟體質量進行度量的指標常用的有哪些

你好！

有N多種指標：
缺陷統計數據的度量(I)
所有缺陷數量的時間走勢或趨勢統計 (Bug Trends By Time)
未被處理的缺陷按照嚴重程度的統計 (Active Bugs By Severity)
未被處理的缺陷按照優先程度的統計 (Active Bugs By Priority)
未被處理的缺陷數量的時間走勢或趨勢統計 （Active Bugs Over Time）
已發現缺陷的數量和已修復的缺陷的數量的比率 (Fixed/Found)。也被稱為修改率或糾錯率(Fix Rate)
未處理的缺陷數量和已處理的的缺陷數量的比率 (active/resolved)
已處理的被修復的缺陷數量和已處理的缺陷數量的比率（Resolved as Fixed/resolved）
重新被激活的已修復的缺陷數量(Bug re-activation rate)
通過測試找到的缺陷的統計(Bugs opened by testing activity)
所有的缺陷按照嚴重程度的統計(All Bugs By Severity)
新被發現的缺陷按嚴重程度的統計 (Opened Bugs By Severity)
已處理的缺陷按照嚴重程度的統計 (Resolved Bugs By Severity)
被修復的缺陷按照嚴重程度的統計 (Fixed By Severity)
不同語言版本缺陷數量的統計(Bugs opened by Language version)
被報告存在缺陷的各功能統計(Where your bugs were found)
處理缺陷的平均時間的統計(Average Time to Resolve)
關閉缺陷的平均時間的統計(Average Time to Close)
被處理缺陷的不同結論統計(Resolved Bugs By Resolution)

詳細的信息你可以留下郵箱，我發給你文件！

④ 軟體質量屬性的度量方法

隨著軟體的復雜性日益增長， 軟體開發的周期以及費用也日益增長，軟體質量的保證與提高越來越成為了人們高度重視的問題。軟體質量的度量的理論和研究也隨之發展起來，好的度量模型和標准能夠有效地提高軟體開發效率和軟體質量。本文主要介紹軟體質量的概念和度量模型以及軟體質量度量的方法，並對未來的發展趨勢做一些展望

⑤ 度量的軟體度量標准

1.軟體研發成本度量規范簡介
本標准規定了軟體研發成本度量方法、過程及原則，包括軟體研發成本的構成、軟體研發成本度量過程、軟體研發成本度量的應用。本標准適用於度量成本與功能規模密切相關的軟體研發項目的成本。本標准不涉及軟體定價，但相關各方可依據本標准明確研發成本，從而為軟體定價提供重要依據。
2.標准研製背景
長期以來，如何度量和評估軟體研發項目的成本一直是產業界的難題。目前我國尚無科學統一的軟體研發項目成本度量標准體系以指導、規范、管理軟體項目的研發成本，較大程度導致做預算時無據可依，造成極大浪費；在軟體項目招評標過程中，由於無法界定軟體工程項目的合理成本范圍，常常出現惡意低價或超高價格競標現象；軟體開發商在項目實施過程中，由於缺乏成本控制的科學依據，也經常出現時間滯後、費用遠遠超出最初估算水平的情況。
3.標准研製過程
在國家工業和信息化部軟體服務業司領導下，從2010年開始啟動我國軟體成本度量標准體系的研製工作。中國軟體行業協會系統與軟體過程改進分會 （以下簡稱 「過程改進分會」）和中國電子技術標准化研究院（以下簡稱「電子四所」）圍繞軟體研發成本度量標准體系建設開展了基礎性研究工作，梳理了標准體系。核心標准《軟體研發成本度量規范》於2010年12月正式立項，計劃號為2010-3194T-SJ，由過程改進分會和電子四所共同牽頭起草，組織產、學、研、 用約40家單位共同參與，歷時3年，為軟體項目預算、立項審批、招投標、項目計劃、變更管理等工作提供「科學依據」。
4.標準的價值
1、倡導使用統一的國際功能點方法度量軟體規模，使度量結果可比對；
2、倡導使用基準數據估算軟體工期和成本，使估算結果更科學；
3、倡導使用一致的估算過程和公式，使估算過程透明化、估算結果可追溯。
5.標准試點應用
《軟體研發成本度量規范》從2012年開始試點應用。海關總署、中國人民銀行、東軟集團等單位都參與了試點工作，分別在預算審批、項目立項、招投標、項目計劃等場景進行應用，取得了很好的效果。截至2013年年底，共有約2000人參加CCEP培訓，近1500人通過考試並成為國內首批CCEP（軟體成本估算專家）。採用標准規定的方法後，極大的解決了試點企業長期以來面臨的問題。
6.標准發布
行業標准《軟體研發成本度量規范》（SJ/T11463-2013） 由中華人民共和國工業和信息化部於2013年10月17日正式發布，並於2013年12月1日開始正式實施。
7.最新進展
經推薦，該標准由中關村智聯軟體服務業質量創新聯盟 牽頭，正在申請升級為國家標准，於2015年7月31日正式下達計劃號：20151553-T-469 1.規范研製背景
北京作為全國軟體與信息服務業之都，產業規模一直位居全國前列，並且保持著較快的增長水平，軟體和信息服務業在全市經濟發展中也佔有越來越重要的地位。隨著十二五規劃的逐步實施，北京市各行各業信息化建設投資也不斷加大，僅全市每年屬於市級財政撥款范疇的信息化項目就可達700至800個，金額總量可達三十多億元，涉及上千家企事業單位。然而本市一直沒有科學統一的標准以支撐、規范、管理信息化項目軟體開發費用的測算，這大大制約了北京軟體產業的健康可持續發展。由於相關標準的缺失，如何測算信息化項目軟體開發的合理費用一直都是北京軟體產業發展中的難點，因而常常導致軟體項目預算審批無依據、惡意競標等問題的發生。
2.規范的價值
由北京市經濟和信息化委員會歸口指導，北京軟體和信息服務交易所、北京軟體行業協會過程改進分會聯合制訂的北京市首個軟體成本度量地方標准《信息化項目軟體開發費用測算規范》將於今年11月起正式實施，這標志著我市信息化項目軟體開發工作擁有了科學、標準的費用評估方法，有助於規范行業市場、推動軟體企業提升生產效率，提升產業增長質量。 1.編制背景
長期以來，如何度量軟體研發成本一直是產業界的難題，尤其是在預算、招投標、項目計劃等活動中因為缺失科學統一的軟體研發成本度量標准，較大程度導致項目做預算時無據可依，進而造成預算浪費或預算不足；在軟體項目招投標過程中，因為缺乏軟體研發成本度量依據，惡意競標、低價中標現象頻頻發生；開發方在項目實施過程中，由於缺乏成本控制的科學依據，也經常出現時間滯後，費用遠遠超出最初預算的情況。科學統一的軟體研發成本度量標准既是有效進行軟體項目管理的重要依據，也是當前軟體產業發展的迫切需要。
為此，工業與信息化部軟體服務業司委託中國軟體行業協會系統與軟體過程改進分會牽頭組織編制了《軟體研發成本度量規范》。標准中規定了軟體研發成本度量的方法及過程，包括軟體研發成本的構成、軟體研發成本度量的過程、軟體研發成本度量的應用。其目的是幫助軟體研發涉及各方科學、一致地進行成本度量。但標准中沒有包含軟體研發成本度量過程中所需要的估算模型、行業基準數據及其在不同場景進行成本估算的詳細步驟和方法，因此需要制訂標準的應用指南，以便相關各方針對不同的應用場景、正確使用行業數據和模型，有效開展軟體研發成本度量相關工作。
2.編制目的與范圍
本指南是《軟體研發成本度量規范》系列應用指南之一，針對預算場景。
《軟體研發成本度量規范》中的成本度量，特指對軟體研發成本的預計值進行估算或對實際值進行測量、分析的過程。而《軟體研發成本度量規范》中，預算是指根據項目成本估算的結果確定預計項目費用的過程。因此，本指南主要描述在預算場景下如何開展成本估算工作，而不涉及編制預算的其他方面。
在《軟體研發成本度量規范》及本指南中，軟體研發過程包括從項目立項開始到項目完成驗收之間的需求分析、設計、編碼、集成、測試、驗收交付活動及相關的項目管理、支持活動。因此，本指南中軟體研發成本僅包括軟體研發過程中的所有直接成本和間接成本，但不包括數據遷移、軟體維護等成本。本指南中所涉及工作量、工期也僅為軟體研發過程所用工作量、工期。
本指南編制的主要目的是指導預算活動相關各方，基於《軟體研發成本度量規范》有效開展成本估算工作，並為確定軟體項目預算提供科學依據。
本指南明確了基於《軟體研發成本度量規范》和基準數據開展成本估算相關活動的步驟與方法，並通過示例，明確了典型情況的估算及調整方法；對於其他特殊情況，相關人員應根據本指南及《軟體研發成本度量規范》中的相關原則，結合項目特點，選擇適當的估算方法或對估算結果進行合理調整。
對於與預算類似的其他早期估算應用場景，相關人員也可參照本指南的相關原則與方法，開展項目估算活動。

⑥ 軟體缺陷度量方法簡述

1.原則上來講，我們更希望一種規范化開發的體系來規正這個命題，不需要為此傷腦筋。但在里程碑或計劃的截止時間點能結束測試對大多數的軟體項目僅僅是一種期望，而不是既定的現實。理想的情況下，我們可以嚴格執行計劃，然後在計劃要求的deadline或者里程碑點上提交交付件，以確認該里程碑是否達到要求，是否可以進行下一階段的工作——但正如前提所言，這個僅僅是理想情況
2.現在讓我們現實一點。我們為什麼會有這樣的問題(一個軟體如何確定測試結束點)？往往就是因為我們不知道何時可以結束一個軟體的測試。不管教科書上如何說明一個軟體只要還在生命周期內，就無法結束測試，但現實要求我們在某一個時間點上，結束對軟體某一階段的測試。那麼，這個問題實際上就已經轉化為確定該階段測試的結束點的方法了。這個方法可能是一種規范，一套流程，一些交付件，一些評審，一些由統計學原理得出的收斂曲線或者僅僅只是一些確認而已。而個人認為，無論這個方法是何種形式的，其基本的要求就是能達成一種協議，確認該協議生效——那麼這個階段的測試就結束了，至於這個點在什麼時間，我想就是完成所有要求的這些確認的時間而已。
在軟體消亡之前，如果沒有測試的結束點，那麼軟體測試就永無休止，永遠不可能結束。軟體測試的結束點，要依據自己公司具體情況來制定，不能一概而論！個人認為測試結束點由以下幾個條件決定：：
1.基於「測試階段」的原則：
每個軟體的測試一般都要經過單元測試、集成測試、系統測試這幾個階段，我們可以分別對單元測試、集成測試和系統測試制定詳細的測試結束點。每個測試階段符合結束標准後，再進行後面一個階段的測試。舉個例子來說：單元測試，我們要求測試結束點必須滿足「核心代碼100%經過Code Review」、「功能覆蓋率達到100%」、「代碼行覆蓋率不低於80%」、「不存在A、B類缺陷」、「所有發現缺陷至少60%都納入缺陷追蹤系統且各級缺陷修復率達到標准」等等標准。集成測試和系統測試的結束點都制定相關的結束標准，當然也是如此。
2.基於「測試用例」的原則：
測試設計人員設計測試用例，並請項目組成員參與評審，測試用例一旦評審通過，後面測試時，就可以作為測試結束的一個參考標准。比如說在測試過程中，如果發現測試用例通過率太低，可以拒絕繼續測試，待開發人員修復後再繼續。在功能測試用例通過率達到100%，非功能性測試用例達到95%以上，允許正常結束測試。但是使用該原則作為測試結束點時，把握好測試用例的質量，非常關鍵。
3.基於「缺陷收斂趨勢」的原則：
軟體測試的生命周期中隨著測試時間的推移，測試發現的缺陷圖線，首先成逐漸上升趨勢，然後測試到一定階段，缺陷又成下降趨勢，直到發現的缺陷幾乎為零或者很難發現缺陷為止。我們可以通過缺陷的趨勢圖線的走向，來定測試是否可以結束，這也是一個判定標准。
4.基於「缺陷修復率」的原則：
軟體缺陷在測試生命周期中我們分成幾個嚴重等級，它們分別是：嚴重錯誤、主要錯誤、次要錯誤、一般錯誤、較小錯誤和測試建議6種。那我們在確定測試結束點時，嚴重錯誤和主要錯誤的缺陷修復率必須達到100%，不允許存在功能性的錯誤；次要錯誤和一般錯誤的缺陷修復率必須達到85%以上，允許存在少量功能缺陷，後面版本解決；對於較小錯誤的缺陷修復率最好達到60%~70%以上。對於測試建議的問題，可以暫時不用修改。
5.基於「驗收測試」的原則：
很多公司都是做項目軟體，如果這種要確定測試結束點，最好測試到一定階段，達到或接近測試部門指定的標准後，就遞交用戶做驗收測試。如果通過用戶的測試驗收，就可以立即終止測試部門的測試；如果客戶驗收測試時，發現了部分缺陷，就可以針對性的修改缺陷後，驗證通過後遞交客戶，相應測試也可以結束。
6.基於「覆蓋率」的原則：
對於測試「覆蓋率」的原則，個人覺的只要測試用例的「覆蓋率」覆蓋了客戶提出全部的軟體需求，包括行業隱性需求、功能需求和性能需求等等，只要測試用例執行的覆蓋率達到100%，基本上測試就可以結束。如「單元測試中語句覆蓋率最低不能小於80%」、「測試用例執行覆蓋率應達到100%」和「測試需求覆蓋率應達到100%」都可以作為結束確定點。如果你不放心，非得要看看測試用例的執行效果，檢查是否有用例被漏執行的情況，可以對常用的功能進行「抽樣測試」 和「隨機測試」。對於覆蓋率在單元測試、集成測試和系統測試，每個階段都不能忽略。
7.基於「項目計劃」的原則：
大多數情況下，每個項目從開始就要編寫開發和測試的Schele，相應的在測試計劃中也會對應每個里程碑，對測試進度和測試結束點做一個限制，一般來說都要和項目組成員(開發，管理，測試，市場，銷售人員)達成共識，團隊集體同意後制定一個標准結束點。如果項目的某個環節延遲了，測試時間就相應縮短。大多數情況下是所有規定的測試內容和回歸測試都已經運行完成，就可以作為一個結束點。很多不規范的軟體公司，都是把項目計劃作為一個測試結束點，但是如果把它作為一個結束點，測試風險較大，軟體質量很難得到保證。
8.基於「缺陷度量」的原則：
這個原則也許大家用的不是很多，了解比較少。我們可以對已經發現的缺陷，運用常用的缺陷分析技術和缺陷分析工具，用圖表統計出來，方便查閱，分時間段對缺陷進行度量。我記得以前zhuzx在這個論壇上提出過缺陷分析技術這個問題，我不再重復講述。我們也可以把 「測試期缺陷密度」和 「運行期缺陷密度」作為一個結束點。當然，最合適的測試結束的准則應該是「缺陷數控制在一個可以接受的范圍內」。比如說：一萬行代碼最多允許存在多少個什麼嚴重等級的錯誤，這樣比較好量化，比較好實施，成為測試缺陷度量的主流。
9.基於「質量成本」的原則：
一個軟體往往要從「質量/成本 /進度」三方面取得平衡後就停止。至於這三方面哪一項佔主要地位，就要看是什麼軟體了。比如說是：人命關天的航天航空軟體，那還是質量重要些，就算多花點錢、推遲一下進度，也要測試能保證較高質量以後才能終止測試，發布版本。如果是一般的常用軟體，由於利益和市場的原因，哪怕有bug，也必須得先推出產品，沒辦法呀。一般來說，最主要的參考依據是：「把找到缺陷耗費的代價和這個缺陷可能導致的損失做一個均衡」。具體操作的時候，可以根據公司實際情況來定義什麼樣的情況下算是「測試花費的代價最劃算、最合理」，同時保證公司利益最大化。如果找到bug的成本比，用戶發現bug的成本還高，也可以終止測試。
10.基於「測試行業經驗」的原則：
很多情況下，測試行業的一些經驗，也可以為我們的測試提供借鑒。比如說測試人員對行業業務的熟悉程度，測試人員的工作能力，測試的工作效率等等都會影響到整個測試計劃的執行。如果一個測試團隊中，每個人都沒有項目行業經驗數據積累，拿到一個新的項目，自然是一頭霧水，不知道從何處開始，測試質量自然不會很高。因此通過測試者的經驗，對確認測試執行和結束點也會起到關鍵性的作用

⑦ 哪些軟體適合使用功能點方法進行度量

軟體規模度量分為：代碼行技術和功能點技術等
代碼行技術優點和缺點分別是：
優點：用軟體代碼行數估算軟體規模簡單易行。
缺點：代碼行數的估算依賴於程序設計語言的功能和表達能力；
採用代碼行估算方法會對設計精巧的軟體項目產生不利的影響；
在軟體項目開發前或開發初期估算它的代碼行數十分困難；
代碼行估算只適用於過程式程序設計語言，對非過程式的程序設計語言不太適用等等。
功能點技術的優點和缺點是：
優點：比代碼行更為合理。
缺點：在某些計算上，主觀意識較為強烈！

⑧ 軟體度量的方法體系

項目度量
項目度量是針對軟體開發項目的特定度量，目的在於度量項目規模、項目成本、項目進度、顧客滿意度等，輔助項目管理進行項目控制。
規模度量
軟體開發項目規模度量(size measurement)是估算軟體項目工作量、編製成本預算、策劃合理項目進度的基礎。規模度量是軟體項目失敗的重要原因之一。一個好的規模度量模型可以解決這一問題。有效的軟體規模度量是成功項目的核心要素：基於有效的軟體規模度量可以策劃合理的項目計劃，合理的項目計劃有助於有效地管理項目。規模度量的要點在於：由開發現場的項目成員進行估算；靈活運用實際開發作業數據；杜絕盲目迎合顧客需求的「交期逆推法」。
軟體規模度量有助於軟體開發團隊准確把握開發時間、費用分布以及缺陷密度等等。軟體規模的估算方法有很多種，如：功能點分析(FPA：function points analysis)、代碼行(LOC：lines of code)、德爾菲法(Delphi technique)、COCOMO模型、特徵點(feature point)、對象點(object point)、3-D功能點(3-D function points)、Bang度量(DeMarco's bang metric)、模糊邏輯(fuzzy logic)、標准構件法(standard component)等，這些方法不斷細化為更多具體的方法。
成本度量
軟體開發成本度量主要指軟體開發項目所需的財務性成本的估算。主要方法如下：
類比估演算法。類比估演算法是通過比較已完成的類似項目系統來估算成本，適合評估一些與歷史項目在應用領域、環境和復雜度方面相似的項目。其約束條件在於必須存在類似的具有可比性的軟體開發系統，估算結果的精確度依賴於歷史項目數據的完整性、准確度以及現行項目與歷史項目的近似程度。
細分估演算法。細分估演算法是將整個項目系統分解成若干個小系統，逐個估算成本，然後合計起來作為整個項目的估算成本。細分估演算法通過逐漸細化的方式對每個小系統進行詳細的估算，可能獲得貼近實際的估算成本。其難點在於，難以把握各小系統整合為大系統的整合成本。
周期估演算法。周期估演算法是按軟體開發周期進行劃分，估算各個階段的成本，然後進行匯總合計。周期估演算法基於軟體工程理論對軟體開發的各個階段進行估算，很適合瀑布型軟體開發方法，但是需要估算者對軟體工程各個階段的作業量和相互間的比例具有相當的了解。
顧客滿意度度量
顧客滿意是軟體開發項目的主要目的之一，而顧客滿意目標要得以實現，需要建立顧客滿意度度量體系和指標對顧客滿意度進行度量。顧客滿意度指標(CSI：customer satisfaction index)以顧客滿意研究為基礎，對顧客滿意度加以界定和描述。項目顧客滿意度量的要點在於：確定各類信息、數據、資料來源的准確性、客觀性、合理性、有效性，並以此建立產品、服務質量的衡量指標和標准。企業顧客滿意度度量的標准會因為各企業的經營理念、經營戰略、經營重點、價值取向、顧客滿意度調查結果等因素而有所不同。比如：NEC於2002年12月開始實施的CSMP 活動的度量尺度包括共感性、誠實性、革新性、確實性和迅速性，其中，將共感性和誠實性作為CS活動的核心姿態，而將革新性、確實性和迅速性作為提供商品和服務中不可或缺的尺度。每個尺度包括兩個要素，各要素包括兩個項目，共計5大尺度、10個要素和20個項目。例如，共感性這一尺度包括「了解顧客的期待」、「從顧客的立場考慮問題」這兩個要素；「了解顧客的期待」這一要素又包括「不僅僅能勝任目前的工作還能意識到為顧客提供價值而專心投入」、「對顧客的期望不是囫圇吞棗而是根據顧客的立場和狀況來思考『顧客到底需要什麼』並加以應對」這兩個項目。
美國專家斯蒂芬(Stephen H.Kan)在《軟體質量工程的度量與模型》(Metrics and Models in Software Quality Engineering)中認為，企業的顧客滿意度要素如表7-1所示： 顧客滿意度要素 顧客滿意度要素的內容 技術解決方案 質量、可靠性、有效性、易用性、價格、安裝、新技術 支持與維護 靈活性、易達性、產品知識 市場營銷 解決方案、接觸點、信息 管理 購買流程、請求手續、保證期限、注意事項 交付 准時、准確、交付後過程 企業形象 技術領導、財務穩定性、執行印象 作為企業的顧客滿意度的基本構成單位，項目的顧客滿意度會受到項目要素的影響，主要包括：開發的軟體產品、開發文檔、項目進度以及交期、技術水平、溝通能力、運用維護等等。具體而言，可以細分為如表7-2所示的度量要素，並根據這些要素進行度量。
顧客滿意度項目 顧客滿意度度量要素
軟體產品 功能性、可靠性、易用性、效率性、可維護性、可移植性
開發文檔 文檔的構成、質量、外觀、圖表以及索引、用語
項目進度以及交期 交期的根據、進度遲延情況下的應對、進展報告
技術水平 項目組的技術水平、項目組的提案能力、項目組的問題解決能力
溝通能力 事件記錄、式樣確認、Q&A
運用維護 支持、問題發生時的應對速度、問題解決能力

⑨ 軟體規模估算有哪些方法

現實中常見的軟體成本估算方法包括經驗法（專家法）、類推法，類比法、方程法，交叉驗證法。除估算方法外，還需要估算資料庫的支持才能繼續度量分析，從而得出估算目標。估算數據基礎可以是企業歷史資料庫，也可以是行業基準資料庫。
《軟體研發成本度量規范》中軟體成本估算的思路分三步驟：規模估算、工作量估算、成本估算。

⑩ 簡述軟體度量GQM方法的基本步驟。

GQM的實施過程大致分為七個階段：先期調研，制定目標，產生計劃，產生測量計劃，收集和整理數據，數據分析，打包。其中GQM的核心是GQM目標（Goal）和GQM計劃，所謂GQM計劃就是用一組問題(Question)來定義GQM目標，再對每個問題給出一組度量（Metric）。