複製鏈接
請複製以下鏈接發送給好友

度量

(軟件度量)

鎖定
度量(software measurement)是對軟件開發項目過程及其產品進行數據定義、收集以及分析的持續性定量化過程。
中文名
軟件度量
外文名
software measurement
作    用
軟件開發的暗箱中跳將出來
目    的
理解、預測、評估、控制和改善

度量基本介紹

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

度量發展歷程

度量 度量
如Lemmerich所言, 測量在科學領域有悠久的歷史。相對早在1889年就定義好了度量單位~米的長度測量,温度的度量複雜的多。Fahrenheit和Celsius分別在1714年和1742年提出了基於某固定點間隔遞增等級的温度度量方法。Celsius將100度和0度之間分為100個等份。但問題是一直不能確定50攝氏度。而且長度的測量總是一個比例尺度,但是温度可能用間隔( 攝氏/華氏温度表) 或者比例尺度(開氏温度)來衡量。
今天,計算機在我們生活的每個領域幾乎都扮演了非常重要的角色。在計算機上運行的軟件也越來越重要。因此,可預測、可重複、準確地控制軟件開發過程和軟件產品已經非常重要。軟件度量就是衡量軟件品質的一種手段。 軟件度量或者説軟件工程度量領域是一個在過去30多年研究非常活躍的軟件工程領域。軟件度量(software measurement)和軟件量度(software metrics)一樣非常有名(譯者注:為了區分,譯者將software measurement和software metrics分別譯成軟件度量和軟件量度,其實他們都可以表示軟件度量)。但學界還沒有明確這兩個術語的區別。參照測量理論的相關術語,我們採用軟件度量(software measurement)。從文獻上看,這兩個術語是同義詞。量度(metric)在這裏不作度量空間理解,它理解為:度量是客觀對象到數字對象的同態映射。同態映射包括所有關係和結構映射。用另一句話説,軟件品質和軟件度量成直對關係。這是度量和軟件度量的根本理念。

度量研究陣營

軟件度量研究主要分為兩個陣營:一部分認為軟件可以度量,一部分認為軟件無法通過度量分析。無論如何,研究主流是關心軟件的品質和認為軟件需要定量化度量。目前有超過上千種軟件度量方法被軟件研究人員及從業人員提出,並且到今天有超過5000份論文出版發表。

度量三維度

軟件度量 軟件度量
軟件度量能夠為項目管理者提供有關項目的各種重要信息,其實質是根據一定規則,將數字或符號賦予系統、構件、過程或者質量等實體的特定屬性,即對實體屬性的量化表示,從而能夠清楚地理解該實體。軟件度量貫穿整個軟件開發生命週期,是軟件開發過程中進行理解、預測、評估、控制和改善的重要載體。軟件質量度量建立在度量數學理論基礎之上。軟件度量包括3個維度,即項目度量、產品度量和過程度量,具體情況如表-1所示。
為什麼需要軟件度量  在軟件開發中,軟件度量的根本目的是為了管理的需要。利用度量來改進軟件過程。人們是無法管理不能度量的事物。在軟件開發的歷史中,我們可以意識到,在60年代末期的大型軟件所面臨的軟件危機反映了軟件開發中管理的重要性

度量管理功能

沒有對軟件過程的可見度就無法管理;而沒有對見到的事物有適當的度量或適當的準則去判斷、評估和決策,也無法進行優秀的管理。我們説軟件工程的方法論主要在提供可見度方面下工夫。但僅僅是方法論的提高並不能使其成為工程學科。這就需要使用度量度量是一種可用於決策的可比較的對象。度量已知的事物是為了進行跟蹤和評估。對於未知的事物,度量則用於預測。本專題將討論軟件度量的一些基本問題。但應認識到軟件度量的成果是非常初步的,還需要大量工作才可能真正地做到實用化,但它的實用化成就將對軟件的高質量和高速發展有不可估量的影響。那麼, 一、什麼是度量呢? 1、度量概念:度量存在於左右我們生活的很多系統的核心之中。在經濟領域,度量決定着價格和付款的增加;在雷達系統中,度量使我們能透過雲層探測到飛機;在醫療系統中,度量使得能夠診斷某些特殊疾病;在天氣預測系統中,度量是天氣預報的基礎;沒有度量,技術的發展根本無法進行。度量的正式定義是: 度量 是指在現實的世界中,把數字或符號指定給實體的某一屬性, 以便以這種方式來根據已明確的規則來描述它們.
因此,度量關注的是獲取關於實體屬性的信息。一個實體可以是一個實物,如人或房間;或者是一個事件,如旅行;或軟件項目的測試階段。屬性是我們所關注的實體的特徵或特性,如血壓的高度(人)、時間(測試階段)、範圍或顏色(房間)、花銷(旅行) 等。因此,説"度量事物"或"度量屬性"的説法是不完全正確的;應該説"度量事物的屬性"。"度量房間"的説法是模糊的;我們可以説度量它的長度、範圍和温度等。同樣説"度量温度"的説法也是模糊的,應該説:我們度量的是某一特定地理位置和特定情況下的温度。2、工程學科需要度量軟件工程要的是有模型和理論支持的方法。
如在設計電路的時候我們應用歐姆定律。這個定律描述了電路中電阻、電流和電壓三者之間的關係。但是這些理論已超出了一般意義上的科學方法的範疇,在這種範疇裏最基本的東西是度量度量除了在發展一個理論的過程中起作用外,我們使用度量並應用它們。因此設計一個特定電流和電阻的電路時我們就知道需要多大的電壓。
如果沒有度量,我們很難想象關於電子、機械、及普通工程的定律能得到發展。但事實上在軟件工程的主流裏度量卻被忽略了。
現在的情況是:
■當我們在設計和開發軟件產品的時候,我們並未能制定出度量的目標。例如:我們保證説我們將使用户界面友好、可靠、易於維護;而並未使用度量的術語來詳細説明它們的具體含義。Gilb曾經説過:所謂模糊目標定理,就是沒有明確目標的項目將不能明確地達到它的目標。
■我們未能對構成軟件項目實際費用的各個不同的部分進行有效的度量。譬如:通常我們並不知道,和測試階段相比,設計階段花費時間多大。
■我們並未試圖使我們開發的產品的各種質量合格。因此我們未能使用術語(如:在一段時間裏使用故障的可能性、把產品安裝到新環境中需花費的工作量等)向潛在的用户説明產品的可靠性很高。
■我們總是試圖説服自己使用另一種新的革新的開發技術和方法進行軟件開發
事實上,我們在軟件度量方面做的工作很少很少,而且所作的度量方面的工作也與一般科學意義上的度量相分離。我們經常會看到諸如此類的話:"軟件的費用有80%花費在維護上。"或"軟件每一千行程序中平均有55個Bugs。"。但是這些話並沒有告訴我們這樣的結果是怎樣產生的、試驗是怎樣設計、執行的、度量的是那個實體、及錯誤的框架是什麼等等。沒有這些東西,我們就不能在我們自己的環境中客觀地進行反覆度量,重現度量的結果以獲得與工業標準的真實比較。因此,歸因於度量不充分的問題的產生是由於缺乏嚴格的度量方法造成的。
除了傳統的對計算機硬件的性能進行度量外,對算法的複雜性的度量一直是計算機科學的重要組成部分。但是,這種度量方法只適用於小程序,而對大型、複雜的軟件來説它卻無能為力了。這就屬於軟件工程的範疇了。如果我們不承認度量將會一個更重要的作用的話,軟件危機將在隨後的幾年裏依然存在 五、軟件度量工具
隨着軟件定量方法(如:軟件度量)的重要性不斷增加,市場上出現了許多度量工具。然而,度量工具還是很混亂。因為沒有統一的度量標準規範,每種工具發明商家都是按照他們自己的軟件度量規範。對度量工具做了好的綜述。

度量種類劃分

aich等根據分類學把度量工具分成了以下幾種:
● 通用度量工具
● 小生境度量工具(Niche Metrics Tool);
● 靜態分析;
源代碼靜態分析;
● 規模度量

度量管理目標

軟件開發正在經受一場危機。費用超支(特別是在維護階段的花費太大)、生產率低下、 以及質量不高等問題正困擾着它。簡言之,軟件開發經常處於失控狀態。軟件之所以失控是因為沒有度量。Tom Demarco曾經説過:"沒有度量就不能控制。"這種説法是好的,但不完全。並不能説為了獲得控制必須進行度量度量活動必須有明確的目標或目的,而正是這決定着我們選擇哪種屬性和實體進行度量。這個目標與軟件開發、使用時所涉及的人的層次有關。以下主要從管理者軟件工程師兩種角度來考慮,為了達到各種目標所要進行的度量工作。管理者而言
1.需要度量軟件開發過程中的不同階段的費用。例如:度量開發整個軟件系統的費用(包括從需求分析階段到發佈之後的維護階段)。必須清楚這個費用以決定在保證一定的利潤的情況下的價格。
2.為了決定付給不同的開發小組的費用,需要度量不同小組職員的生產率。
3.為了對不同的項目進行比較、對將來的項目進行預測、建立基線以及設定合理的改進目標等,需要度量開發的產品的質量。
4.需要決定項目的度量目標。例如:應達到多大的測試覆蓋率、系統最後的可靠性應有多大等。
5.為了找出是什麼因素影響着費用和生產率,需要反覆測試某一特定過程和資源的屬性。
6.需要度量和估計不同軟件工程方法和工具的效用,以便決定是否有必要把它們引入到公司中。
軟件工程師而言
1.需要制定過程度量以監視不斷演進的系統。這包括設計過程中的改動、在不同的回顧或測試階段發現的錯誤等等。
2.需使用嚴格的度量的術語來指定對軟件質量和性能的要求,以便使這些要求是可測試的。例如:系統必須"可靠",可用如下的更具體 的文字加以描述:"平均錯誤時間必須大於15個CPU時間片。"
3.為了合格需要度量產品和過程的屬性。例如:看一個產品是否合格要看產品的一些可度量的特性如"β測試階段少於20個錯誤。","每個模塊的代碼行不超過100行。",和開發過程的一些屬性如"單元測試必須覆蓋90%以上的用例。"等。
4.需要度量當前已存在的產品和過程的屬性以便預測將來的產品。例如:
(1).通過度量軟件規格説明書的大小來預測目標的大小。
(2).通過度量設計文檔的結構特性來預測將來維護的"盲點"。
(3).通過度量測試階段的軟件的可靠性來預測軟件今後操作、運行的可靠性。
研究上面我們列出的度量的目標和活動我們可以發現:軟件度量的目標可大致 概括為兩類。
其一,我們使用度量來進行估計。這使得我們可以同步地跟蹤一個特定的軟件項目 。
其二,我們應用度量來預測項目的一些重要的特性。但是,值得指出的是我們不能過分誇大這些預測。有些人甚至認為只要使用合適的模型和工具,所獲得的預測可以精確到只需使用極少的其他度量(甚至根本就不用使用度量)。
事實上,這種期望是不現實的。

度量項目度量

項目度量是針對軟件開發項目的特定度量,目的在於度量項目規模、項目成本、項目進度、顧客滿意度等,輔助項目管理進行項目控制。

度量規模度量

軟件質量度量模型 軟件質量度量模型
軟件開發項目規模度量(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
運用維護支持、問題發生時的應對速度、問題解決能力表7-2顧客滿意度項目度量要素

度量產品度量

軟件質量的生命週期及其度量
軟件產品度量用於對軟件產品進行評價,並在此基礎之上推進產品設計、產品製造和產品服務優化。軟件產品的度量實質上是軟件質量的度量,而軟件的質量度量與其質量的週期密切相關。
軟件軟件質量度量模型
軟件產品的度量主要針對作為軟件開發成果的軟件產品的質量而言,獨立於其過程。軟件的質量由一系列質量要素組成,每一個質量要素又由一些衡量標準組成,每個衡量標準又由一些量度標準加以定量刻劃。質量度量貫穿於軟件工程的全過程以及軟件交付之後,在軟件交付之前的度量主要包括程序複雜性、模塊的有效性和總的程序規模,在軟件交付之後的度量則主要包括殘存的缺陷數和系統的可維護性方面。一般情況下,可以將軟件質量特性定義成分層模型。勃姆(Barry W. Boehm)在《軟件風險管理》(Software Risk Management)中第一次提出了軟件質量度量的層次模型。而麥考爾(McCall)等人將軟件質量分解至能夠度量的層次,提出FCM 3層模型(參見表5-13):軟件質量要素(factor)、衡量標準(criteria)和量度標準(metrics),包括11個標準,分為產品操作(product operation)、產品修正(product revision)和產品轉移(product transition)。ISO 9126將軟件質量總結為6大特性,每個特性包括一系列副特性,其軟件質量模型包括3層,即高層:軟件質量需求評價準則(SQRC);中層:軟件質量設計評價準則(SQDC);低層:軟件質量度量評價準則(SQMC)。
層 級名 稱內 容
第一層質量要素:
描述和評價軟件質量的一組屬性功能性、可靠性、易用性、效率性、可維護性、可移植性等質量特性以及將質量特性細化產生的副特性
第二層衡量標準:
衡量標準的組合反映某一軟件質量要素精確性、穩健性、安全性、通信有效性、處理有效性、設備有效性、可操作性、培訓性、完備性、一致性、可追蹤性、可見性、硬件系統無關性、軟件系統無關性、可擴充性、公用性、模塊性、清晰性、自描述性、簡單性、結構性、文件完備性等
第三層量度標準:
可由各使用單位自定義根據軟件的需求分析、概要設計、詳細設計、編碼、測試、確認、維護與使用等階段,針對每一個階段制定問卷表,以此實現軟件開發過程的質量度量表7-3 軟件質量度量FCM模型 凱悦(Lawrence E. Hyatt)和羅森貝克(Linda H. Rosenberg)在《識別項目風險以及評價軟件質量的軟件質量模型與度量》(A Software Quality Model and Metrics for Identifying Project Risks and Assessing Software Quality)中比較了這3種最常用的軟件質量模型,其基本情況如表5-14所示。
度量標準麥 考 爾勃 姆ISO 9126
正確性(Correctness)
可維護性
可靠性(Reliability)
完整性(Integrity)
可用性(Usability)
效率性(Efficiency)
可維護性(Maintainability)

度量度量標準

可測試性(Testability)
可維護性
互操作性(Interoperability)
適應性(Flexibility)
可重用性(Reusability)
可移植性(Portability)
明確性(Clarity)
可變更性(Modifiability)
可維護性
文檔化(Documentation)
恢復力(Resilience)
易懂性(Understandability)
有效性(Validity)
可維護性
功能性(Functionality)
普遍性(Generality)
經濟性(Economy)
軟件質量模型之比較
軟件質量度量方法比較多,例如:(1)Halstead複雜性度量法,基本思路是根據程序中可執行代碼行的操作符和操作數的數量來計算程序的複雜性。操作符和操作數的量越大,程序結構就越複雜。(2)McCabe複雜性度量法,其基本思想是程序的複雜性很大程度上取決於程序控制流的複雜性,單一的順序程序結構最簡單,循環和選擇所構成的環路越多,程序就越複雜。

度量軟件度量標準

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

度量過程度量

軟件過程性能 過程度量是對軟件開發過程的各個方面進行度量,目的在於預測過程的未來性能,減少過程結果的偏差,對軟件過程的行為進行目標管理,為過程控制、過程評價持續改善提供定量性基礎。過程度量軟件開發流程密切相關,具有戰略性意義。軟件過程質量的好壞會直接影響軟件產品質量的好壞,度量並評估過程、提高過程成熟度可以改進產品質量。相反,度量並評估軟件產品質量會為提高軟件過程質量提供必要的反饋和依據。過程度量軟件過程的成熟度密切相關。
軟件過程管理中的過程度量
弗羅哈克(William A.Florac)、帕克(Robert E.Park)和卡爾頓(Anita D.Carleton)在《實用軟件度量:過程管理和改善之度量》(Practical Software Measurement:Measuring for Process Management and Improvement)中描述了過程管理和項目管理的關係。認為軟件項目團隊生產產品基於三大要素:產品需求、項目計劃和已定義軟件過程度量數據在項目管理中將被用來:(1)識別和描述需求,(2)準備能夠實現目標的計劃,(3)執行計劃,(4)跟蹤基於項目計劃目標的工作執行狀態和進展。而過程管理也能使用相同的數據和相關度量來控制和改善軟件過程本身。這就意味着,軟件組織能使用建構和維持度量活動的共同框架來為過程管理和項目管理兩大管理功能提供數據。
軟件過程管理包括定義過程、計劃度量、執行軟件過程、應用度量、控制過程和改善過程,其中計劃度量和應用度量是軟件過程管理中的重要步驟,也是軟件過程度量的核心內容。計劃度量建立在對已定義軟件過程的理解之上,產品、過程、資源的相關事項和屬性已經被識別,收集和使用度量以進行過程性能跟蹤的規定都被集成到軟件過程之中。應用度量通過過程度量將執行軟件過程所獲得的數據,以及通過產品度量將產品相關數據用來控制和改善軟件過程。軟件過程度量的內容
軟件過程度量主要包括三大方面的內容,
一是成熟度度量(maturity metrics),主要包括組織度量、資源度量、培訓度量、文檔標準化度量、數據管理與分析度量、過程質量度量等等;
二是管理度量(management metrics),主要包括項目管理度量(如里程碑管理度量、風險度量、作業流程度量、控制度量、管理數據庫度量等)、質量管理度量(如質量審查度量、質量測試度量、質量保證度量等)、配置管理度量(如式樣變更控制度量、版本管理控制度量等);
三是生命週期度量(life cycle metrics),主要包括問題定義度量、需求分析度量、設計度量、製造度量、維護度量等。軟件過程度量流程
軟件過程度量,需要按照已經明確定義的度量流程加以實施,這樣能使軟件過程度量作業具有可控制性和可跟蹤性,從而提高度量的有效性。軟件過程度量的一般流程主要包括:確認過程問題;收集過程數據;分析過程數據;解釋過程數據;彙報過程分析;提出過程建議;實施過程行動;實施監督和控制。這一度量過程的流程質量能保證軟件過程度量獲得有關軟件過程的數據和問題,並進而對軟件過程實施改善。
參考資料