項目度量
項目度量是針對軟件開發項目的特定度量，目的在于度量項目規模、項目成本、項目進度、顧客滿意度等，輔助項目管理進行項目控制。
規模度量
軟件開發項目規模度量(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)等，這些方法不斷細化為更多具體的方法。
1. 功能點分析法
（1）功能點分析法概述
功能點分析法(FPA：function point analysis)是在需求分析階段基于系統功能的一種規模估算方法，是基于應用軟件的外部、內部特性以及軟件性能的一種間接的規模測量。FPA法由IBM的工程師艾倫·艾爾布策(Allan Albrech)于20世紀70年代提出，隨后被國際功能點用戶協會(IFPUG：The International Function Point Users' Group)提出的IFPUG方法繼承，從系統的復雜性和系統的特性這兩個角度來度量系統的規模，其特征是：“在外部式樣確定的情況下可以度量系統的規�！�，“可以對從用戶角度把握的系統規模進行度量”。功能點可以用于“需求文檔”、“設計文檔”、“源代碼”、“測試用例”度量，根據具體方法和編程語言的不同，功能點可以轉換為代碼行。經由ISO組織已經有多種功能點估算方法成為國際標準，如：①加拿大人艾倫·艾布恩(Alain Abran)等人提出的全面功能點法(full function points)；②英國軟件度量協會(UKSMA：United Kingdom Software Metrics Association)提出的IFPUG 功能點法(IFPUG function points)；③英國軟件度量協會提出的Mark II FPA功能點法(Mark II function points)；④荷蘭功能點用戶協會(NEFPUG：Netherlands Function Point Users Group)提出的NESMA 功能點法，以及軟件度量共同協會(COSMIC：the COmmon Software Metrics Consortium)提出的COSMIC-FFP方法，這些方法都屬于艾爾布策功能點方法的發展和細化。
（2）功能點分析法的基本計數
功能點分析的基本計數就是依據標準計算出的系統(或模塊)中所含每一種元素的數目：
�、偻獠枯斎霐�(EI：external input)：計算每個用戶輸入，它們向軟件提供面向應用的數據。輸入應該與查詢區分開來，分別計算。
�、谕獠枯敵鰯�(EO：external output)：計算每個用戶輸出，它們向軟件提供面向應用的信息。這里，輸出是指報表、屏幕、出錯信息，等等。一個報表中的單個數據項不單獨計算。
�、弁獠坎樵償�(EQ：external query)：一個查詢被定義為一次聯機輸入，它導致軟件以聯機輸出的方式產生實時的響應。每一個不同的查詢都要計算。
�、軆炔窟壿嬑募�(ILF：internal logical file)：計算每個邏輯的主文件，如數據的一個邏輯組合，它可能是某個大型數據庫的一部分或是一個獨立的文件。
�、萃獠拷涌谖募�(EIF：external interface file)：計算所有機器可讀的接口，如磁帶或磁盤上的數據文件，利用這些接口可以將信息從一個系統傳送到另一個系統。
（3）功能點分析的主要步驟
功能點分析可以按照如圖5-6所示步驟進行：
圖5-6 功能點分析的主要步驟
（4）案例：CSK株式會社的功能點分析案例
【CSK株式會社的CSFPA概述】
在實施CSFPA之前，CSK以Step數方法來估算開發規模。但是在利用VB、C++、Java、SQL等語言的項目開發中，用Step數方法進行規模估算比較困難。為了以定量化手段降低甚至消除估算錯誤，CSK在IFPUG(International Function Point Users Group)的FP法的基礎上加以改良開發出自身的CSFPA(CSK Simplified Function Point Analysis)法，并在企業內加以實施。CSK于1995年加入IFPUG組織，并于1998年開始正式開展活動。
CSFPA改良的兩點是：增加了度量要件定義等上游工程的簡易測量功能；避免使用人為因素太強的調整系數。CSFPA法適用體制在項目估算時的FP度量、項目完成時的FP度量、實際數據的收集、統計分析、工數模型化、質量指標化等方面具有CSK特有的方式，CSK在該方法的教育與培訓、模型構筑、估算·質量計劃的適用、結果評價·差異分析等方面取得了良好的績效。
【CSFPA法的估算步驟】
CSFPA法與IFPUG法的估算步驟有所不同，二者的相似點以及不同點請參照圖5-7。
圖5-7 CSFPA功能點估算步驟
【CSFPA法的推廣運用】
為了普及和適用CSFPA，CSK在企業內設立由多名專任人員組成的事務局，推進方法的定義以及維護、管理、員工教育、度量支援、數據收集、統計分析、數據利用等。下面對CSFPA的適用體制加以介紹。
項目估算時的FP度量。在估算時度量軟件規模，通過適用相應的工數模型測算預計工數，以此作為制定日程的根據。CSFPA的工數模型以開發的全過程為對象，按照項目的開發范圍進行估算，將式樣、品質、技術的對應要件作為變動要素對此加以調整。
項目完成時的FP度量。在項目完成階段對FP數、使用環境、技術、工數以及質量信息等幾十個項目加以記錄，比較估算時的FP數并進行差異分析，以提升度量精度和模型有效性。
實際數據的收集。將度量的實際數據剃除異常點后納入數據庫，并加以分析，然后向全企業公開。這種標本數據已經超過400件。由于FP度量過程中由于度量者的不同可能導致較大的誤差，事務局還面向經驗甚淺的度量者提供現場支持，驗證度量結果的妥當性，提高度量的精度。另外，還與其他企業所提供的數據進行比較驗證，持續收集數據。
統計分析。對于收集起來的數據，還需要考慮到項目特性的差異并加以分析。作為分析的界限，CSK建立了包括約50種類型(可視化工具類開發、Web類開發、維護的主框架開發等)的數據庫，并對各自包括工數在內的10種以上的項目和FP值實施相關分析。
工數模型化。CSK將FP數和工數的關系稱之為“工數模型”，現在已經擁有可適用的6種工數模型。這些模型與實際數據的收集相配合，實施差異分析，持續提升估算精度。
質量指標化。與工數模型一樣，CSK將FP數和質量數據(缺陷、問題等)之間的相關關系作為質量模型加以提供。通過定義經由質量模型獲得的指標，并與現存的指標相結合，構筑綜合性的質量指標。
【CSK推進FP法的經驗總結】
度量方法的教育與滲透—— 啟蒙。要使用FP法進行度量，當然需要了解度量規則。CSK在其“項目管理研修”這一體制中，對企業員工實施教育，講解FP法的定位、概要、使用方法，進行度量演習，讓企業員工掌握FP法。
模型構筑—— 提升估算精度的路徑。要使用各種模型提升估算的精度，需要度量項目特性以及仔細檢查數據。CSK通過現場調研和支援活動，積累起專業知識和技能，并對技術、式樣、質量方面的特性信息加以整理，構筑適合CSK的估算模型，提高估算精度。
估算·質量計劃的適用—— 制定適當而正確的計劃。構筑起來的模型在實際提案的時候作為估算的根據或者在產品的質量計劃制定過程中適用。在模型不斷適用的情況下，這些模型的適用實例也就逐漸豐富起來。
結果評價·差異分析—— 取得反饋信息至更高水平的運用。項目開發過程中，變更點管理以及計劃與實績的差異分析非常重要。在這個過程中，需要獲得適當的反饋信息，在把握復雜的項目狀況的同時需要靈活應對這些變更和反饋。CSK在這方面也在積極運作并在整個企業內展開。
【CSK功能點法今后的展開】
將FP作為商務活動中的共通尺度是CSK導入FP法的主要目的之一。為了提高CSK與顧客之間將之作為共通尺度的認知度，CSK認為需要實施如下事項：一是提高方法本身的認知度和信賴性；二是客觀地驗證度量數據的精度。FP是度量軟件規模的手段，在軟件開發的商務活動、項目管理、資產管理等諸多場合中都是切實把握規模的依據，是以適當的價格提供高質量軟件的基礎，也是客觀性表示CSK的生產性的重要因素。CSK在通信、控制、嵌入式開發中正在試用COSMIC-FFP。
2. 代碼行
代碼行(line of code)指所有的可執行的源代碼行數，包括可交付的工作控制語言(JCL：job control language)語句、數據定義、數據類型聲明、等價聲明、輸入/輸出格式聲明等。一代碼行(1LOC)的價值和人月均代碼行數可以體現一個軟件組織的生產能力。組織可以根據對歷史項目的審計來核算組織的單行代碼價值。代碼行LOC常用于源代碼的規模估算，常使用的單位有：SLOC(single line of code)、KLOC(thousand lines of code)、LLOC(logical line of code)、PLOC(physical line of code)、NCLOC (non-commented line of code)、DSI(delivered source instruction)。
3. 德爾菲法
德爾菲法(Delphi technique)是最流行的專家評估技術，在沒有歷史數據的情況下，這種方式適用于評定過去與將來、新技術與特定程序之間的差別，但專家“�！钡某潭燃皩椖康睦斫獬潭仁枪ぷ髦械碾y點，盡管德爾菲技術可以減輕這種偏差，在評定一個新軟件實際成本時通常用得不多，但是，這種方式對決定其他模型的輸入時特別有用。德爾菲法鼓勵參加者就問題相互討論。德爾菲法的步驟是：(1)協調人向各專家提供項目規格和估算表格；(2)協調人召集小組會和各專家討論與規模相關的因素；(3)各專家匿名填寫迭代表格；(4)協調人整理出一個估算總結，以迭代表的形式返回給專家；(5)協調人召集小組會，討論較大的估算差異；(6)專家復查估算總結并在迭代表上提交另一個匿名估算；(7)重復4～6，直到最低估算和最高估算一致。
4. 構造性成本模型
構造性成本模型(COCOMO：constructive cost model)是一種精確、易于使用的基于模型的成本估算方法，最早由勃姆(Boehm)于1981年提出。該模型按其詳細程度分為3級：基本COCOMO模型、中間COCOMO模型和詳細COCOMO模型�；綜OCOMO模型是一個靜態單變量模型，它用一個以已估算出來的源代碼行數(LOC)為自變量的函數來計算軟件開發工作量。中間COCOMO模型則在用LOC為自變量的函數計算軟件開發工作量的基礎上，再用涉及產品、硬件、人員、項目等方面屬性的影響因素來調整工作量的估算。詳細COCOMO模型包括中間COCOMO模型的所有特性，但用上述各種影響因素調整工作量估算時，還要考慮對軟件工程過程中分析、設計等各步驟的影響。COCOMO模型具有估算精確、易于使用的特點。在該模型中使用的基本量有以下幾個：(1)DSI(源指令條數)，定義為代碼行數，包括除注釋行以外的全部代碼。若一行有兩個語句，則算做一條指令。(2)MM(度量單位為人月)表示開發工作量。(3)TDEV(度量單位為月)表示開發進度，由工作量決定。(4)COCOMO模型重點考慮15種影響軟件工作量的因素，并通過定義乘法因子，從而準確、合理地估算軟件的工作量。
成本度量
軟件開發成本度量主要指軟件開發項目所需的財務性成本的估算。主要方法如下：
類比估算法。類比估算法是通過比較已完成的類似項目系統來估算成本，適合評估一些與歷史項目在應用領域、環境和復雜度方面相似的項目。其約束條件在于必須存在類似的具有可比性的軟件開發系統，估算結果的精確度依賴于歷史項目數據的完整性、準確度以及現行項目與歷史項目的近似程度。
細分估算法。細分估算法是將整個項目系統分解成若干個小系統，逐個估算成本，然后合計起來作為整個項目的估算成本。細分估算法通過逐漸細化的方式對每個小系統進行詳細的估算，可能獲得貼近實際的估算成本。其難點在于，難以把握各小系統整合為大系統的整合成本。
周期估算法。周期估算法是按軟件開發周期進行劃分，估算各個階段的成本，然后進行匯總合計。周期估算法基于軟件工程理論對軟件開發的各個階段進行估算，很適合瀑布型軟件開發方法，但是需要估算者對軟件工程各個階段的作業量和相互間的比例具有相當的了解。
顧客滿意度度量
顧客滿意是軟件開發項目的主要目的之一，而顧客滿意目標要得以實現，需要建立顧客滿意度度量體系和指標對顧客滿意度進行度量。顧客滿意度指標(CSI：customer satisfaction index)以顧客滿意研究為基礎，對顧客滿意度加以界定和描述。項目顧客滿意度量的要點在于：確定各類信息、數據、資料來源的準確性、客觀性、合理性、有效性，并以此建立產品、服務質量的衡量指標和標準。企業顧客滿意度度量的標準會因為各企業的經營理念、經營戰略、經營重點、價值取向、顧客滿意度調查結果等因素而有所不同。比如：NEC于2002年12月開始實施的CSMP 活動的度量尺度包括共感性、誠實性、革新性、確實性和迅速性，其中，將共感性和誠實性作為CS活動的核心姿態，而將革新性、確實性和迅速性作為提供商品和服務中不可或缺的尺度。每個尺度包括兩個要素，各要素包括兩個項目，共計5大尺度、10個要素和20個項目。例如，共感性這一尺度包括“了解顧客的期待”、“從顧客的立場考慮問題”這兩個要素；“了解顧客的期待”這一要素又包括“不僅僅能勝任目前的工作還能意識到為顧客提供價值而專心投入”、“對顧客的期望不是囫圇吞棗而是根據顧客的立場和狀況來思考‘顧客到底需要什么’并加以應對”這兩個項目。
美國專家斯蒂芬(Stephen H.Kan)在《軟件質量工程的度量與模型》(Metrics and Models in Software Quality Engineering)中認為，企業的顧客滿意度要素如表5-11所示：
表5-11 顧客滿意度要素及其內容
| 顧客滿意度要素 | 顧客滿意度要素的內容 |
| 技術解決方案 | 質量、可靠性、有效性、易用性、價格、安裝、新技術 |
| 支持與維護 | 靈活性、易達性、產品知識 |
| 市場營銷 | 解決方案、接觸點、信息 |
| 管理 | 購買流程、請求手續、保證期限、注意事項 |
| 交付 | 準時、準確、交付后過程 |
| 企業形象 | 技術領導、財務穩定性、執行印象 |
作為企業的顧客滿意度的基本構成單位，項目的顧客滿意度會受到項目要素的影響，主要包括：開發的軟件產品、開發文檔、項目進度以及交期、技術水平、溝通能力、運用維護等等。具體而言，可以細分為如表5-12所示的度量要素，并根據這些要素進行度量。
表5-12 顧客滿意度項目度量要素
| 顧客滿意度項目 | 顧客滿意度度量要素 |
| 軟件產品 | 功能性、可靠性、易用性、效率性、可維護性、可移植性 |
| 開發文檔 | 文檔的構成、質量、外觀、圖表以及索引、用語 |
| 項目進度以及交期 | 交期的根據、進度遲延情況下的應對、進展報告 |
| 技術水平 | 項目組的技術水平、項目組的提案能力、項目組的問題解決能力 |
| 溝通能力 | 事件記錄、式樣確認、Q&A |
| 運用維護 | 支持、問題發生時的應對速度、問題解決能力 |
產品度量
軟件質量的生命周期及其度量
軟件產品度量用于對軟件產品進行評價，并在此基礎之上推進產品設計、產品制造和產品服務優化。軟件產品的度量實質上是軟件質量的度量，而軟件的質量度量與其質量的周期密切相關，如圖5-8所示：
圖5-8 軟件質量的生命周期及其度量
軟件質量度量模型
軟件產品的度量主要針對作為軟件開發成果的軟件產品的質量而言，獨立于其過程。軟件的質量由一系列質量要素組成，每一個質量要素又由一些衡量標準組成，每個衡量標準又由一些量度標準加以定量刻劃。質量度量貫穿于軟件工程的全過程以及軟件交付之后，在軟件交付之前的度量主要包括程序復雜性、模塊的有效性和總的程序規模，在軟件交付之后的度量則主要包括殘存的缺陷數和系統的可維護性方面。一般情況下，可以將軟件質量特性定義成分層模型。勃姆(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)。
表5-13 軟件質量度量FCM模型
| 層 級 | 名 稱 | 內 容 |
| 第一層 | 質量要素：描述和評價軟件質量的一組屬性 | 功能性、可靠性、易用性、效率性、可維護性、可移植性等質量特性以及將質量特性細化產生的副特性 |
| 第二層 | 衡量標準： 衡量標準的組合反映某一軟件質量要素 | 精確性、穩健性、安全性、通信有效性、處理有效性、設備有效性、可操作性、培訓性、完備性、一致性、可追蹤性、可見性、硬件系統無關性、軟件系統無關性、可擴充性、公用性、模塊性、清晰性、自描述性、簡單性、結構性、文件完備性等 |
| 第三層 | 量度標準： 可由各使用單位自定義 |
根據軟件的需求分析、概要設計、詳細設計、編碼、測試、確認、維護與使用等階段，針對每一個階段制定問卷表，以此實現軟件開發過程的質量度量 |
凱悅(Lawrence E. Hyatt)和羅森貝克(Linda H. Rosenberg)在《識別項目風險以及評價軟件質量的軟件質量模型與度量》(A Software Quality Model and Metrics for Identifying Project Risks and Assessing Software Quality)中比較了這3種最常用的軟件質量模型，其基本情況如表5-14所示。
表5-14 3種軟件質量模型之比較
| 度量標準/目標 | 麥 考 爾 | 勃 姆 | ISO 9126 |
| 正確性(Correctness) | X | X | 可維護性 |
| 可靠性(Reliability) | X | X | X |
| 完整性(Integrity) | X | X | |
| 可用性(Usability) | X | X | X |
| 效率性(Efficiency) | X | X | X |
| 可維護性(Maintainability) | X | X | X |
| 可測試性(Testability) | X | 可維護性 | |
| 互操作性(Interoperability) | X | ||
| 適應性(Flexibility) | X | X | |
| 可重用性(Reusability) | X | X | |
| 可移植性(Portability) | X | X | X |
| 明確性(Clarity) | X | ||
| 可變更性(Modifiability) | X | 可維護性 | |
| 文檔化(Documentation) | X | ||
| 恢復力(Resilience) | X | ||
| 易懂性(Understandability) | X | ||
| 有效性(Validity) | X | 可維護性 | |
| 功能性(Functionality) | X | ||
| 普遍性(Generality) | X | ||
| 經濟性(Economy) | X |
軟件質量度量方法
軟件質量度量方法比較多，例如：(1)Halstead復雜性度量法，基本思路是根據程序中可執行代碼行的操作符和操作數的數量來計算程序的復雜性。操作符和操作數的量越大，程序結構就越復雜。(2)McCabe復雜性度量法，其基本思想是程序的復雜性很大程度上取決于程序控制流的復雜性，單一的順序程序結構最簡單，循環和選擇所構成的環路越多，程序就越復雜。
過程度量
軟件過程性能
過程度量是對軟件開發過程的各個方面進行度量，目的在于預測過程的未來性能，減少過程結果的偏差，對軟件過程的行為進行目標管理，為過程控制、過程評價持續改善提供定量性基礎。過程度量與軟件開發流程密切相關，具有戰略性意義。軟件過程質量的好壞會直接影響軟件產品質量的好壞，度量并評估過程、提高過程成熟度可以改進產品質量。相反，度量并評估軟件產品質量會為提高軟件過程質量提供必要的反饋和依據。過程度量與軟件過程的成熟度密切相關，其度量模型如圖5-9所示：
圖5-9 軟件過程性能的度量模型
軟件過程管理中的過程度量
弗羅哈克(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)，主要包括問題定義度量、需求分析度量、設計度量、制造度量、維護度量等。
軟件過程度量流程
軟件過程的度量，需要按照已經明確定義的度量流程加以實施，這樣能使軟件過程度量作業具有可控制性和可跟蹤性，從而提高度量的有效性。軟件過程度量的一般流程主要包括：確認過程問題；收集過程數據；分析過程數據；解釋過程數據；匯報過程分析；提出過程建議；實施過程行動；實施監督和控制。這一度量過程的流程質量能保證軟件過程度量獲得有關軟件過程的數據和問題，并進而對軟件過程實施改善。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
