ファンクションポイント法に思う

品質メトリクスには、テスト密度やバグ密度/欠陥密度などがあり、これらの指標値はソースコード行数やファンクション数をベースに、例えば、「xx件/KSLOC」や「xx件/KFP」などの単位で表現する。
ここでファンクション数とは、ファンクションポイント法で計測したソフトウェアの機能数のことである。
ファンクションポイント法(function point method)(以下FP法)とは、1979年にIBMのアレン・J・アルブレヒトが考案したソフトウェアの規模を測定する手法である。FP法は、「ユーザから見える機能に着目する」、すなわちベンダーの視点ではなくユーザーの視点から機能数を測定出来ること、従って開発言語に依存しないこと、などが特徴である。
FP法の標準化団体としてIFPUG(International Function Point User Group)が1986年に発足し、計測マニュアルの改訂や計測技術の普及活動を行っている。IFPUGが定めた計測手法をIFPUG法と呼ぶ。
FP法は、その後適用領域に応じてMKⅡ法やNESMA法、COSMIC-FFP法などの新しい計測手法が提案され、それぞれ個別に国際規格化が進んでいる。 

さて、このファンクションポイント法、一時期は注目を集め随分と話題にもなったが、最近はIT系の雑誌などでもほとんどお目にかからない。日本語の関連書籍を検索してみても最近の出版物はほとんどないようだ。ファンクション数は、品質指標値だけでなく、ソフトウェアの規模見積にも使われる重要な尺度であるから、これをテーマにした記事はもっとあってもよさそうなものだが・・・。
特に、プロジェクトのコストが当初見積を超過して赤字になる事例は、不良プロジェクトの典型例であり、その原因の幾つかは見積手法や、見積の調整要因(パラメーター)にフィードバックされるべきもののはずである。
FP法の話題が表に出てこないのは、FP法が既に成熟した技術で話題性に乏しいからなのか、あるいは、調整要因(パラメーター)やその値などがSIベンダーの秘密事項(知的財産)に該当するからなのか、あるいは思ったほど使われていないから、なのかもしれない・・・(品質指標に限って言えば、多くのベンダーは、ファンクション数よりもソースコード行数の方を使っていると思われる)。
FP法について注意しなければならないことは、これはあくまでソフトウェアの機能数(ファンクション数)を見積もるものであって、直接的に開発工数や開発期間を求めることは出来ないという点である。
FP法で計測したファンクション数から開発工数を求めるためには、過去の実績値が必要になる。これはCOCOMO法など、他の見積手法でも同じである。過去の実績データがないと開発工数も、品質指標値も導出できない。(IPA等が公開している統計データを用いることは可能であるが、本来はベンダー固有の条件、すなわち該当ベンダーの生産性や調整係数が考慮されるべきである)

FP法の説明に入る前に、COCOMO法について簡単に触れておく。COCOMO法は、1981年にTRW社のBarry Boehm氏が提唱したもので、過去63個のソフトウェア開発プロジェクトから得られたデータを元に構築された統計モデルで、基本COCOMO、中間COCOMO、詳細COCOMOの3つから構成されている。
COCOMOでは、開発するプログラムの想定ソースコード行数を元に、問題領域経験度やチーム強度、信頼性要求度、再利用性などの変動要因を使用して開発工数と開発期間を見積もる。
1997年には、汎用化して適用範囲を広げた第2バージョンCOCOMO II法が提案されている。COCOMOⅡ法では、規模の単位をSLOCに限定せず、変動要因も22個に増えている。

FP法は以下の図に示す手順でファンクション数を求める。なお、以下の手順のうち、未調整FP値とVAF(Value Adjustment Factor:調整係数)から「調整済みFP値」を求める部分はオプションであり、ISO/IEC14143でも範囲外である。

 

FunctionPointPractices
(1)計測タイプの決定
計測タイプは3種類ある
①新規開発FP計測
ソフトウェアを新規に開発する場合を指している。データ移行の機能も計測対象に含まれる。
②機能拡張FP計測
既存のアプリケーションに対して機能の追加/更新/削除を行う場合に適用する。
③アプリケーションFP計測
導入済みのソフトウェアに対して、その規模を計測するときに適用する。 

(2)計測範囲の決定、アプリケーション境界の決定
アプリケーションは、FP値の算出単位である。この単位でグループ化を行う。アプリケーションに含まれる機能は、必ず外部とデータのやりとりを行う。アプリケーションと外部との境界を明確にする。

(3)データファンクションの計測
データファンクションは、計測対象のアプリケーションがアクセスする、ユーザ視点でのファイルである。
ファイルは、ILF(Internal Logical File:内部論理ファイル)とEIF(External Interface File:外部インタフェースファイル)の2種類に分類される。
ファイルのデータエレメントタイプ(DET)と、レコードエレメントタイプ(RET)を算出し、ファイルの複雑度を求める。そして、ファイルの複雑度からファイルのFP値を求める。(注)
(注)DETの数とRETの数から複雑度を求める表と、複雑度からFP値を求めるための表が用意されている。

(4)トランザクショナルファンクションの計測
トランザクショナルファンクションは、計測対象のアプリケーションが有する、ユーザ視点での処理(要素処理という)である。
トランザクションは、EI(External Input)と、EO(External Output)と、EQ(External inQuiry)の3種類に分類される。
要素処理のデータエレメントタイプ(DET)と、ファイルタイプリファレンス(FTR)を算出し、要素処理の複雑度を求める。そして、要素処理の複雑度から要素処理のFP値を求める。(注)
(注)DETの数とFTRの数から複雑度を求める表と、複雑度からFP値を求めるための表が用意されている。

(5)未調整ファンクションポイントの計算
ファイルのFP値と要素処理のFP値を合計して未調整ファンクションポイントを求める。

(6)調整係数を求める
対象システムに関するGSCという14項目の特徴を評価する。
14項目の評価点を合計したものをTDI(Total Degree Of Influence)という。
TDIを使用して、以下の式より調整係数(VAF:Value Adjustment Factor)を求める。
VAF = (TDI * 0.01) + 0.65
この式から得られるVAFは、0.65~1.35の値を持ち、未調整FP値に対して±35%の影響を与える。

(7)調整済みファンクションポイントの計算
未調整FP値とVAF(調整係数)から調整済みFP値を求める。
計算式は3種類の計測タイプ毎に用意されている。


2017年7月追記
日本ではファンクションポイント法の普及を日本ファンクションポイントユーザ会(JFPUG)が進めている。
同団体は会員制であるが、会員以外の人も参加できるセミナーなどを開催している。また、ファンクションポイント計測技術者認定国際資格(CFPS)の資格試験を毎年12月初旬に開催している。
(この試験に向けた対策セミナーなども開催しているようだ)
詳細は日本ファンクションポイントユーザ会のHPを参照されたい。

プロジェクト管理のINDEX

トラックバック

このブログ記事に対するトラックバックURL:

コメント & トラックバック

コメントはまだありません。

Update

2019年6月
« 5月    
 12
3456789
10111213141516
17181920212223
24252627282930

Navigation