功能點分析方法在軟件需求管理中的應用
2008-04-16 作者：曹濟 劉黎明 王寧（caoji） 來源：項目管理者聯盟
軟件項目面臨的一個普遍困難就是需求的不確定與頻繁變更，有效管理軟件需求要解決的一個基本問題是確定變更的粒度大小以及對項目的影響程度。本文使用功能點標準度量需求的規模，使得采用量化方式管理軟件需求成為可能，從而對功能點在軟件項目管理方面的應用進行擴充。
關鍵詞： 需求管理 需求變更 功能點 項目管理 軟件度量
1. 背景
相對于傳統行業的項目而言，在軟件項目中經常會發生工期拖延、費用超支、質量低下、用戶不滿意等負面情形[1]，其原因可能包括客戶要求不合理、過程管理不規范、質量意識淡漠等多種因素，但不能否認的是軟件本身的特點是問題產生的根源。
相對于其他行業而言，例如土建、制造等傳統行業，軟件更為抽象和不易衡量，同時軟件還具有容易變更的特點。再加上軟件不容易量化的特點使得軟件項目的計劃與跟蹤粒度過粗、不能及時發現項目中存在的問題，從而導致軟件項目的管理往往流于形式化，不能起到應有的作用。
軟件項目管理主要從四個方面關注項目的進展狀況[2]，它們依次是項目的范圍、時間、成本和質量，如圖一所示。其中項目范圍作為主要的變量，對其他三個指標產生明顯的影響。而軟件項目范圍的不確定性則會直接導致項目工期、項目成本和項目質量的不確定性。
圖一：項目管理三角形軟件項目范圍的不確定性通常表現為如下兩個方面：
1. 項目前期需求不明確。前期需求不明確導致項目范圍不確定，而基于范圍基礎之上的工期、成本與質量目標顯然也帶有很大的不確定性。正是因為需求不明確，許多項目傾向于采用固定價合同計價模式。當后期發生追加需求時，甲方可以避免追加合同金額的情形（甲方申請由追加需求產生的額外費用是比較困難的，因為他往往缺乏有效的方法說服自己的上司追加費用與額外需求之間明確的對應關系）�？上攵�，固定價合同模式對項目的乙方會產生什么樣的影響。乙方只好做些力所能及的被動適應性工作，例如無可奈何的加班、質量方面的下降、工期方面的順延等等。
2. 需求變更時無法做出可信的量化影響分析。 因為需求規模的單位比較模糊，例如一個需求、需求模塊等籠統提法，導致變更的需求規模描述不容易被接受。尤其是對于客戶而言，基于變更的需求所推導出的對應的工期變更、成本變更和質量變更也缺乏說服力。所以當需求變更后，項目計劃的修改往往是不夠準確的。
在軟件項目的需求管理中引入功能點分析方法可以有針對性地解決上述的問題[3]。在軟件項目中引入功能點分析方法有助于：
約束需求的詳細程度
對需求變更的影響程度綜合分析
區分需求變更及其對應的種類
2. 功能點方法概述
一個軟件的大小可以通過交付給用戶的功能點數來度量，就如一間房子的大小通過提供給用戶的建筑面積或使用面積來度量一樣。根據ISO的標準表述，功能點分析方法的目的是量化表述用戶功能性需求的軟件規模（A size of the software derived by quantifying the Functional User Requirement）
目前被納入ISO標準的功能點分析方法總共有四種，分別是
IFPUG 功能點標準
Mark II 功能點標準
Nesma 功能點標準
COSMIC FFP 功能點標準
IFPUG（International Function Point User Group）功能點標準是目前軟件行業采用最廣泛的功能點分析方法 。功能點分析方法是從用戶的角度將所有的用戶業務功能需求區分為駐留數據的功能需求和處理數據的事務功能需求[3]，如圖二所示。
其中，數據功能需求區分為應用內部邏輯數據和應用外部的接口數據；事務功能區分為對數據的外部輸入、輸出和查詢。數據功能的 復雜性由數據元素類型（DET ）和記錄元素類型（RET ）決定 ；而事務功能的復雜性由數據元素類型（DET ）和文件引用類型（FTR ）決定 。將功能轉換為對應的復雜程度，再根據復雜程度轉換為對應的功能點數值[3]，這樣就將用戶的業務功能需求表述為一個用數值表示的軟件需求規模。完整的功能點計數過程如圖三所示[3]。
因為功能點分析方法是一個確定軟件需求規模的標準方法，所以它可以界定需求的有效粒度。從而有助于約束需求的詳細程度，并采用統一的尺度衡量軟件需求規模。
3. 采用功能點方法管理軟件需求變更
3.1. 基于功能點分析方法的需求變更分類
何謂軟件需求變更？從功能點分析的角度就是需求發生了變化，而這種變化的判定依據可以參考功能點的識別規則。需求的變更相對于原有的需求而言無非就是三種類型：新增需求、修改需求和刪除需求。新增需求和刪除需求相對容易判斷，而修改需求的判斷就不是那么直接了。在實際的軟件項目中，需求的變更通常存在下列的情形：
第一種是需求不明確的前提所提出的變更，即在需求定義時用戶沒有能力或時間定義需求，或定義的需求不夠詳細，因而在需求確認后提出變更，通常包括新增需求和變更需求；
第二種是在需求明確的前提下所提出的變更，通常是因為當前的業務與最初提出的需求已經發生了變化或者原有的功能已經不適用，通常包括新增需求、刪除的需求和變更的需求。
我們將第一種需求稱為遺漏性需求變更，而將第二種需求變更稱為追加性需求變更。下面分析的結果對于遺漏性和追加性的需求變更都適用。
3.1.1. 數據功能的需求變更分類
對于新增和刪除的數據功能容易識別，例如在原有需求的基礎之增加或刪除發票信息或價格規則信息，則易判斷發票信息或價格規則信息為增加或刪除的數據功能。對于修改的數據功能則比較困難。
判斷修改的數據功能時應注意：如果修改僅包含邏輯文件中新紀錄的增加或者已存在字段中新值的增加，那么不能認為數據功能被修改；如果數據功能中添加了新字段，而這個新字段卻并沒有被應用所使用，那么該數據功能也不能認為是被修改的數據功能。一個數據功能被算作被修改的功能，通常其結構要發生改變（如：增加或刪除一個字段或者修改了字段特征）[3]。
所以對于數據功能的需求變更可以區分為增加、修改和刪除。
3.1.2. 事務功能的需求變更分類
類似于數據功能的判斷，對于新增和刪除的事務功能也容易識別。例如在原有需求的基礎之增加或刪除價格規則維護功能，則易判斷價格規則維護功能為增加或刪除的事務功能。通常，當判斷有新增或刪除的數據功能時，事務功能也會有新增或刪除。而當新增或刪除事務功能時，數據功能卻不一定發生變化。例如，增加或刪除了價格規則這樣的數據功能時，則對應的應該有新增或刪除的事務功能。否則，如何維護對應的數據功能？反之，則不必然。
對于修改的事務功能判斷相對困難。判斷EI/EO/EQ類型的事務功能是否被修改，則可參考事務功能的唯一性判定原則。如果以下三個條件任一條件滿足，則說明事務功能發生了變化，需求應被當作變更的需求處理。判斷事務功能是否變更的三個條件如下：
事務功能的DET是否發生變化，例如增加、刪除或修改DET
事務功能關聯的FTR是否發生變化，例如FTR增加、減少或修改
事務功能對應的處理邏輯是否發生變化，例如處理邏輯增加、減少或修改
什么是處理邏輯？功能點分析方法通過枚舉方式列出十三種邏輯[3]，如表一所示。需要注意的是，區分事務功能的唯一性時，可以不考慮處理邏輯13，即重新分類或重新排列數據邏輯；而當判斷一個事務功能是否被修改時，則所有的處理邏輯都在考慮的范圍，哪怕事務功能僅僅只是對處理邏輯13 做了修改，也應視作修改的事務功能。
表一：事務功能的13種處理邏輯
表一中各字母表示的含義如下：
M：事務功能必須執行的處理邏輯
M*：事務功能必須執行其中的至少一個
C：事務功能可以執行，但并不是必須執行的處理邏輯
N：事務功能不能執行的處理邏輯
至此，可以將軟件需求變更歸類為遺漏性需求變更和追加性需求變更。而對每一性質的變更又可區分為新增、刪除和變更三種類型。下一節進一步描述不同需求變更類型的功能點算法。
3.2. 需求變更的影響分析
正如圖一中項目管理三角形描述的那樣，采用功能點衡量需求變更的程度，是為了更好地評價需求對項目的工期、成本以及質量的影響。首先涉及到的問題就是如何對需求變更后的項目規模重新評價，在上一節描述了對單次需求變更（包括增加、修改和刪除）的識別，在此基礎上可以根據下面的公式計算變更后的項目功能點規模。
CAFP=(CBFP+DEL)*VAFB+(ADD+CHGA+CFP)*VAFA （1）
其中
CAFP：變更后項目功能點總數（表示每次需求變更后對項目功能點的計數）
CBFP：變更前項目功能點總數 （最初的項目功能點數通常在需求規格說明書批準后得到，又稱為項目的初始基線功能點）
DEL：刪除需求的功能點總數
VAFB：修改前調整系數
ADD：增加需求的功能點總數
CHGA：修改后需求的功能點總數
CFP：數據轉換的功能點數（如果系統中涉及到遺留系統數據遷移時會有此類型功能點）
VAFA：修改后調整系數
需要說明的是，在軟件需求變更的過程中，VAFB和VAFA通常是一致的，因為單次需求變更往往對于系統的非功能性需求沒有明顯的影響。
因為每次需求變更后可以重新確定項目的功能點，所以可以在此基礎上重新確定項目的工期、成本和質量[2]，[4-8]。
對于后續階段提出的需求變更與項目前期提出的需求變更所引發的工作量的評估看起來會有比較大的不同，感覺上好像后續的變更引發的工作量更大。這是因為后續階段提出的新需求可能會涉及到對技術架構體系的修改，這樣就會涉及到很多工作量。但如果不涉及到技術架構的話，需求在前期與后期提出對于引發的工期、成本和質量應該區別不大。
需求變更影響分析在合同管理方面有著重要的意義，軟件項目合同的項目約束條件（工期、費用和質量要求）與項目的范圍有直接的對應關系。當軟件需求如果比原有需求增加、修改和刪除時，項目的約束條件應該也隨之發生變化。因為在很多軟件項目中存在需求前期不明確、不完整的情形，所以軟件需求變更管理應該充分考慮這一因素，因而本文將其區分為遺漏性需求與追加性需求。上述的公式（1）主要適用于項目組內部對于需求規模的評價，而客戶方與開發方組織對于需求規模的評定應充分考慮遺漏性需求發生的可能性，因為遺漏性需求不應該排除在項目的合同范圍之外，也即意味著客戶無需為遺漏性需求支付額外的費用或降低其他約束標準。
4. 采用功能點方法約束軟件需求
不同于軟件項目的追加性需求，軟件項目的遺漏性需求是應該并且也可能避免的。在需求的獲取階段可以標準功能點作為需求的約束標準，避免產生遺漏性需求。具體來說，對于每一項客戶提出的業務功能都應該以圖二所描述的模型作為約束標準。每一項功能都必須有對應的數據功能，而每一個數據功能也必須有對應的事務功能。而對于每一項數據功能自然可以聯想到維護數據功能的三種事務功能，輸入功能（通常包括新增、刪除和修改三種功能）、輸出功能和查詢功能。而每一項事務功能通常至少與一個內部邏輯文件或外部接口文件關聯。
而對于具體每項需求（包括數據功能與事務功能）描述的詳細程度也可以參考功能點約束標準。對于每項數據功能，識別它們所包含的DET和RET；對于每項事務功能，識別它們的對應的DET、FTR以及所采用的處理邏輯（處理邏輯即上文所描述的十三種處理邏輯）。如果客戶不能確定對應的DET、RET、FTR或處理邏輯，那么也應該將這些不能確定的內容作為需求風險識別出來，在后續的階段應加以確認和跟蹤，及早確認這些不確定項。
5. 結論
本文通過分析軟件需求變更的特點，將軟件功能點分析方法引入軟件需求變更管理過程中。對于軟件需求變更首先將其區分為遺漏性需求或追加性需求，然后再區分需求是新增、修改還是刪除，尤其是分析了判斷修改需求的界定標準，給出了判定修改需求的三個條件。在此基礎上，討論需求變更的影響分析，并給出了需求變更后的項目功能點公式。最后建議采用功能點標準作為客戶需求的約束標準，提高軟件需求的完整性和詳細程度。功能點分析方法作為確定軟件規模的基礎方法，可以有效提升軟件量化管理水平，還可以廣泛應用于軟件項目管理、質量管理等相關領域。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
