點度量（3）—功能規模度量方法選擇
blueski推薦 [2005-1-18]
出處：51CMM
作者：中南大學劉秋林譯
4. 功能規模度量方法的共性問題
依照文獻，功能規模度量方法也要處理一些難題。Kemerer 在文獻[23]引用 Pressmann說道：“功能點度量，像 LOC，也有相關的爭議…反對者說道，這種方法不是完全客觀和依靠數據，而是更多地需要一些基于主觀的計算手段…”；Capers Jones 發現，FP計算方法的變量結果可以在超過+/- 50％范圍內變化。還有G. Low 和D.R. Jeffery 也發表過聲明，“在組織內，功能點計算變化的范圍大約平均在30％之內…”。由此可見，可再現性和客觀性是功能規模度量方法的核心問題。其他論文如Abran等的文章[15]提到未來需要集中研究的問題如自動操作和可兌換性。本文這部分將討論以下幾個重要的問題：
自動操作（automation），
客觀性/可靠性（objectivity / reliability），
可兌換性（convertibility），
加權因子值的需要（need of a Value Adjustment Factor）
重用的包含(inclusion of reuse),
新技術的影響(influence on / of new technologies),
不同的度量軟件工作產品（different measurement artifacts）。
4.1 度量的自動操作（Automation of measurement）
如在第3章提到的那樣，一種完全自動化度量的獨立估計工具是個理想的解決方案。對應于實際的軟件生命周期階段，工具應源于實際文檔的功能點計算。自動數據收集不但減少了萃取數據過程中發生錯誤的風險并且減輕了工作量。這對大家接受功能規模度量非常重要。
為了自動化操作，有關這類方法的可能性進行了大量的討論。比如Symons提出實現IFPUG功能點非常困難，但Mark II功能點在CASE工具的幫助下可以實現自動化[14]。
MacDonnell做了調查產品的復雜評估是否可以完全以自動化，不需要人工輸入方式的進行[18]，結果如表5所示。表5顯示了他的觀點，完全自動化估計是不可能的
| 方法 | 是否可以自動化 |
| Bang Metric | 不可以 |
| IFPUG | 不可以 |
| Mark II FPA | 不可以 |
| 表 5: 自動化度量的可能性 | |
Ho等提出了一種源于源代碼利用程序的篇幅來自動化度量功能點的框架方法[24]。被提出的框架可以用來建立一種符合“IFPUG計算實踐手冊”自動化功能點度量模型。認識到模型高度依賴于限幅工具的能力和效率，已經進行了原型開發的進一步研究。Paton發表了對于這種方法的理論基礎[25] 。首先，定義了中間程序表現包含足夠信息計算功能點的DF（P）的方式。其次，很明顯這種中間程序表示法可以利用程序篇幅（一種靜態代碼分析形式）以及程序追查（一種動態代碼分析形式） 得到。 因而，自動化功能點計算是可能的。
另外一種是Oppermann 為了支持全面功能點版本1自動化度量而開發的方法[27]，它作為西門子和馬格德堡的大學（譯者注：馬格德堡的大學是德國的一所綜合性大學）合作的成果論文提出的。 它是經過評價全面功能點在西門子的適用性后，才決定開發一個工具進行自動計算[28]。但是，遺憾的是經過進一步的調查研究發現，由于西門子說明書文檔的結構復雜和多樣性，完全自動化計算是不可能的。因而開發了一個由兩部分組成的幫助度量的工具。 FFPExtract 分析西門子的需求說明書且選出一些可能可以度量的作品。然后FFPCounter 在一個對話框中顯示出需求說明書和建議進行度量的作品。這些作品可以被用戶接受進行計算也可以拒絕。
Diab, Frappier 和St-Denis 提出了另一種有趣的方法[52][53]。利用IFPUG和全面功能點的正式定義，他們能夠進行自動計算。這種方法對B說明書語言（針對IFPUG）和ROOM（實時面向對象模型）語言（針對COSMIC的全面功能點）特別適用。
自動計算功能點的一般解決方案是可能的（本文介紹的方法是非常專門的），但還沒有令人滿意，還必須做在這個領域的進一部研究。
4.2客觀性/可靠性（Objectivity/Reliability）
在功能規模度量，任何參與的評估員個人的方法主觀地方強調的越多，結果的可重復性越難。
舉一個Symons給出的有關IFPUG內部問題的例子[15]：三個子系統單獨度量的功能點和少于由他們組成的整個系統度量的功能點。
此外，在他看來單個功能元素如輸入、輸出等的權重是任意選擇，他認為應該根據某種具體環境進行修改。
Iok Kuan Wu Simon在一次案例研究（500不同地區的香港商業公司）中發現由于功能點方法太主觀，僅有大約23％的公司使用這種方法[29]。從這里可以看出經驗對功能點分析方法的結果可重復性是非常重要。因此，這個問題可以通過培訓來解決，但是太花工作量。然而，不管主觀性，LOC對Simon來說好像也不是一個好的選擇，特別是在科學應用如數據通訊和多媒體應用領域。
MacDonnell已經做了調查[18]：不管對個人要求或者執行評價或估計要求，模型是否如定義的那樣對一個給定的系統在一個給定的時間點（假設沒有計算錯誤）總是會得出同樣的結果。表6可見調查結果。
| 方法 | 是否客觀 |
| Bang Metric | 不 |
| IFPUG | 不 |
| Mark II FPA | 不 |
| 表6：方法的客觀性 | |
依照Abran全面功能點要有好的可重復性，需要評估人員有和業務領域一樣的功能度量領域的經驗。
從上面爭議的陳述可見，這個主題還需進一步研究。其中包括為客觀性和可重復性，清楚定義計算，分別地估計和度量什么，怎樣計算、估計和度量。
為了支持客觀性/可重復性的評價，ISO標準14143第三部分提供了一個和準確性一樣驗證可重復和可再現性的框架[49]。
4.3 可兌換性（Convertibility）
有許多功能規模方法分布在不同功能業務領域而且因此有不同的度量策略。
如果想提出一種新的方法或者比較不同方法之間的度量結果，必須研究不同方法之間的可兌換性。Symons已經提出人們是否接受一個新的規模的方法其是否能轉換是需要考慮的條件[08]。 通過分析可兌換性，他發現COBOL SLOC和Albrecht 功能點相互關聯不是很好，同樣Albrecht 功能點和Mark II 功能點也不是很好轉換。
Capers Jones 認為特種點和功能點之間開發了兌換[30]，SPR工具如KnowledgePlan能執行這些轉換。由于是不同的度量策略，想得到DeMarco's Bang這種度量方式和其他功能點或特征點的兌換關系是不可能的
Meli調研了Mark II和IFPUG功能點之間的關系[31]。既然兩者都是用于相同功能業務方面，他們之間應該有個比例并且因此能從一個轉換成另外一個。但是依照Meli的看法，這些方法不能進行比較。
全面功能點的可兌換性仍然在研究中。這是COSMIC主動提出而且強調最多正在研究的方面之一。
為了支持可兌換性的分析，ISO標準14143第三部分提供了一個可兌換性的確認方法的框架[49]。
4.4 加權因子值（Value Adjustment Factors）
有關加權因子值非常有趣的討論早已提出。問題是它的作用是什么和應該怎么樣使用它。
Lokan 等說根據他們的經驗，一般系統特征（GSC the General System Characteristics）和加權因子值（VAF the Value Adjustment Factor）很難理解[32]。一般看來它們是重要的，但是很難成功應用。由于加權因子值，即使在技術和質量要求上的做了大量努力也是明顯無效的。依照Symons導致這種尷尬地步的一個原因是已經引入這個集合和因子的爭議和試驗策略 [14]。
在功能點分析的演化過程中，一般系統特征（GSC）已經被修改和分別大范圍地減少（在他們的數量和他們的集合方面）。
根據Lokan等[32]，一些規模度量方法加了些特征（如Mark II 功能點不是14個特征而是19個），但是也有一些其他規模度量方法（包括特征點，3-D等）不描述調整過程或者甚至直接采用IFPUG的建議。ISO在功能規模度量的標準明確拒絕采用加權因子值。
Lokan后來的陳述道，沒有任何調查研究加權因子值的人發現使用這個因子后對工作量估計的準確性有多大程度的提高。因此不斷有估計人員根本就不使用一般系統特征和加權因子值。（可以參見我們在西門子同樣的經歷[27][28]），他們忽略它或者在工作量估計時把它考慮為成本驅動因素。
結果，Lokan做出了這樣的結論：一般系統特征和加權因子值是度量一個應用軟件的不同方面。認為規模有不同的尺度衡量比使勁將它們合起來形成一個數據要好些。
Meli 有相同的結論[31]。他告訴大家我們必須放棄使用加權因子值，至少不應用作應用軟件規模度量的調節元素，也許加權因子值可以作為一個限制條件使用（如加權因子值越大，應用軟件越好）或者用作會影響生產成本的元素調節生產力值。
Symons建議應該可能地校準一般系統特征，在不同的應用軟件領域從而就有不同的加權因子值[14]。
在Meli的觀點，只有兩種處理加權因子值的可能選擇[33]。一是完全放棄加權因子值，只使用未調整數。第二是為了限制某種特殊應用軟件的功能點數而使用加權因子值。這就意味著同一個功能點數目可以是非常有用和有效的組件的功能點計算也可以是不是那么有用有效的組件的功能點計算。
然后限制條件可以給出這個不同的概念。如影響程度越高（用一個計算出來的數字表示），應用軟件越好。
下面是處理這個問題需要進一步研究的方面
多少個一般系統特征數應該定義（建議4到100）
哪個集合是必須的 ，
影響范圍應該是多少（+/-5 范圍內或者不是這樣）。
4.5重用的包含（Inclusion of reuse）
傳統的功能規模度量是度量用戶視域中的整個軟件產品功能規模。
既然新提出的軟件開發方法都支持重用，如面向對象，COTS和JavaBeans,在商業計算時，為了單獨決定軟件的自我繼承部分是多少時，傳統的度量方式是不夠的（更詳細的信息請參見文獻[45]）。
Meli發現需要區別開用戶要求且發布給用戶的功能點和軟件開發團隊實際開發的功能點[33]。這也是為什么需要發現并提出新方法的原因。他提出了一個對這個問題的解決方法[31]：定義兩種不同的功能點度量方法，一個是和外部用戶視域相關聯，另一個是為了滿足軟件制造管理和生產性的需要。
Ho等為了處理這個問題度量了軟件工程的執行過程[34]。因此，識別出發生了多少重用是非常重要的。為了得到這個信息，全面功能點使用了層的概念識別軟件中潛在的功能重用源并進行度量。
Meli進一步說道，現存的軟件工作產品事實上（如文檔、源代碼、說明書和用戶手冊等）可能包含一個積累，它能用一個可選的定量化標準范圍 [33]。和新產生的詳細描述的軟件數據一起考慮，一個基準數據基數是比較重要的。它能在重用現象的強烈作用下形成產品數據。因此如果項目計劃在草稿到實現過程中使用了大量的重用，平均比率不是有用的。由于這個原因，應該要有一個完全開發的功能點生產率數據。而后，由于指望的重用，對于具體的項目，要在完全開發的基礎上重新校準工作量。
4.6 新技術的影響（Impact of new software technologies）
傳統的軟件規模度量方法研發時滿足了傳統的軟件開發需要。既然有新的方法和領域引入，即使功能規模度量仍能可以適用于軟件的新方法也必須對傳統方法進行完善。在本文提到的新的軟件方面如下：
Internet 和 Intranet 軟件，
圖形用戶界面，
分布式軟件（如客戶端服務器），
面向對象系統
其他
依照Longstreet [35] [36]面向對象系統主要不同是其對系統采用的一種另外不同的觀察方式。傳統的軟件系統是個結構合成物，面向對象看來是一個單一的實體，對象表現了數據和過程。
對于圖形用戶界面（GUI），internet 和 intranet 軟件同樣是對軟件的另類觀察。用FrontPage或者其他html工具開發的Web站點可能或者不可能包含任何功能。關鍵是對信息在哪里存放和信息怎樣處理過程的理解。多數網站無非是菜單和文本。但也必須考慮這類系統的功能度量。
但Longstreet認為IFPUG功能點能適合面向對象環境[36]（既然產品的功能規模是面向用戶，它應該和實現方式無關），但是必須要有一些面向對象和傳統開發比較的標準化要素。為了支持這個觀點，Longstreet發布了擴展的IFPUG 4.1版來適合圖形用戶界面、Internet, Intranet, OO和其他新出現的軟件技術領域[20]。
Boehm也說全面功能點適用于圖形用戶界面（GUI）,客戶/服務器（client/server） 和 面向對象（object-oriented） 系統[19]，但也有一些問題需要解決。
當然，利用大多數功能規模方法，每一個功能業務領域可以度量功能規模，也可以得到一個數值。但是問題是，這個數據是否能正確代表系統或者它是否只是個數字，沒有其他任何意義。
Symons意識到一個困難是方法的定義和過程將逐漸變的越復雜[08]，因為為了將一個老的規模方法改編適應新的開發方法和技術，就必須連續加入新的規則到老的規模度量方法中[08]。因此很難維持這些追加內容的一致性。
另外一個是有關分布式軟件的問題，用戶對功能的看法是必要實現的功能是否充分刻畫。對這個問題的一個可能的方案是使用全面功能點版本2.0，它包含了層的概念來分別處理不同軟件視域。進一步的研究會揭示新的功能規模度量方法是如全面功能點方法是否完全解決這些問題。
4.7 度量的工作產品（Measurement artifacts）
在整個軟件生命周期都有可能有功能規模度量。既然在不同的軟件生命周期階段工作產品不同，就需要有不同的考慮：
哪些工作產品可以用來度量/估計 ，
對某種方法，什么時候是度量的最早時間點，
方法是在估計嗎，
UML 是否可以用于度量/估計，
是否有可能從源代碼進行后期度量計算 。
度量的工作產品（Artifacts for measurement）
首先，功能規模度量的開始時間點已經討論。圖8和圖9（figures 8 and 9）是COSMIC [16] 自己確定的早期和后期實現用戶功能需求的 模型。
Figure 8: Pre-implementation FURs (Source: [16])
Figure 9: Post- implementation FURs (Source: [16])
圖中所有顯示的工作產品，應該可以得到度量的必須信息。
度量時間的最早點（Earliest point of time for measurement）
Garmus和 Herron [03] 說過，DeMarco's Bang和3-D功能點方法需要對系統過程的詳細認識，但是在初期不可能充分計算系統過程（如系統的狀態和轉換過程），對這兩種方法來說， 計算功能點越早越困難。因此它們必須在比 Mark II功能點、特征點和IFPUG功能點使用的軟件生命周期更后的階段度量，其中Mark II功能點、特征點和IFPUG功能點可以在相同的系統詳情水平，得到相同精確程度的功能點，但是不幸的是他們需要的詳情業只有經過大約15-40 %的開發時間后才可能有。
早期估計（Earlier estimations）
Boehm指出越早度量項目就可能越早在控制之下[19]。
一般都相信只有在設計階段才可能進行功能點計算，但是有規則可以使得更早得到功能點數據（在IFPUG4.0支持下）。有時用啟發式規則。但在真正進行這種可能新得計算往往發現是又不可能，根據一般模型的適用性，在需求收集階段，功能點計算可能只是一個更好或者更差估計。當所有商業需求終結時，可能有準確的功能點計算。為了克服這個時間點遲后問題，有人提出了早期功能點方法。Meli總結了應用這種方法的結果[31][33]。他發現方法在軟件項目沒有所有詳細資料（功能說明書）時估計功能點值早期功能點是一種非常有用的方法，它能是一種正式標準的計算。
但重要的是需要考慮這種方法的效力，這種方法的系統是根據實際計算案例來設置的，它的效果只是用一種不變的確認來保證。但依照資料，早期功能點方法已經完善地比較有效，在大多情況它估計的數值在實際功能點數值+/-10%內。
另外一種早期估計的方法是早期全面功能點方法。這種方法基于早期功能點分析并且現在正在開發完善。
利用UML進行度量（Measurement using UML）
有幾種利用UML元素進行估計功能規模的方法已經被提出和討論。其中一種是Stutzke被提出來的用來估計特征點的方法[44]。他參考結合了以前別人的工作成果如Reifer's模型(1990)、類點方法（the Class Points Method，被Fischmann/McRitchie 提出）和南非方法（the South African Method 被Meyerson提出)。但他認為不是所有的問題都解決了，可能問題是：
對象模型的重用部分需要多少工作量 ，
特別的分析方法是怎樣影響工作量的 ，
將設計的對象轉換為執行代碼需要多少工作量 。
Longstreet給出了一些怎么用用例度量功能點的例子[20]。他聲明每一步必須分析它是否是一個事務或者是一個數據類型。他還列出了采用用例進行功能點計算的風險：
在用例中沒有標識清楚必須的事務，
在用例中可能沒有正確標識事務，
在用例中沒有清楚定義屬性數，
屬性數不能固定到一個實體上。
但他， Longstreet [36], 聲明功能點分析可以非常容易的適用于用例方法。
Meli 提出用例已經變成一個捕獲用戶需求的一般方法，因為用例是從用戶的角度描述功能，他們應該很容易轉換成功能點[37]。但這個事實需要一項一項確認，既然功能轉換和用例的“解剖”水平可能不同，進一步的研究應提供些這種潛在關系的統計證據。
從源代碼進行后期計算（Post-calculation from source code）
一個最后重要的考慮是希望從源代碼進行后期計算功能點 。既然有方法已經從源代碼實現功能業務內容自動度量，后期計算也是可能。自動度量的方法在本文的4.1進行了介紹
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/