推定手法-FPカウントプロセス

FPカウントプロセスには、次の手順が含まれます-

Step 1 −カウントのタイプを決定します。
Step 2 −カウントの境界を決定します。
Step 3 −ユーザーが必要とする各基本プロセス（EP）を特定します。
Step 4 −一意のEPを決定します。
Step 5 −データ関数を測定します。
Step 6 −トランザクション機能を測定します。
Step 7 −機能サイズ（未調整の機能ポイント数）を計算します。
Step 8 −値調整係数（VAF）を決定します。
Step 9 −調整されたファンクションポイントカウントを計算します。

Note−一般的なシステム特性（GSC）は、CPM 4.3.1でオプションになり、付録に移動しました。したがって、ステップ8とステップ9はスキップできます。

ステップ1：カウントのタイプを決定する

ファンクションポイントカウントには3つのタイプがあります-

開発ファンクションポイントカウント
アプリケーションファンクションポイントカウント
エンハンスメントファンクションポイントカウント

開発ファンクションポイントカウント

ファンクションポイントは、要件から実装段階までの開発プロジェクトのすべてのフェーズでカウントできます。このタイプのカウントは、新しい開発作業に関連付けられており、変換作業をサポートする一時的なソリューションとして必要とされた可能性のあるプロトタイプが含まれる場合があります。このタイプのカウントは、ベースラインファンクションポイントカウントと呼ばれます。

アプリケーションファンクションポイントカウント

アプリケーション数は、提供されたファンクションポイントとして計算され、変換作業（プロトタイプまたは一時的なソリューション）および存在した可能性のある既存の機能は除外されます。

エンハンスメントファンクションポイントカウント

実稼働後にソフトウェアに変更が加えられた場合、それらは拡張機能と見なされます。このような拡張プロジェクトのサイズを決定するために、ファンクションポイントカウントがアプリケーションで追加、変更、または削除されます。

ステップ2：カウントの境界を決定する

境界は、測定対象のアプリケーションと外部アプリケーションまたはユーザードメインとの間の境界を示します。（図1を参照）

境界を決定するには、以下を理解してください。

ファンクションポイントカウントの目的
測定されるアプリケーションの範囲
どのアプリケーションがどのデータをどのように維持するか
アプリケーションをサポートする事業領域

ステップ3：ユーザーが必要とする各基本プロセスを特定する

機能的なユーザー要件を、次のすべての基準を満たす最小のアクティビティ単位に構成および/または分解します。

ユーザーにとって意味があります。
完全なトランザクションを構成します。
自己完結型です。
カウントされているアプリケーションのビジネスを一貫した状態のままにします。

たとえば、機能ユーザー要件-「従業員情報の保守」は、従業員の追加、従業員の変更、従業員の削除、従業員の照会などの小さなアクティビティに分解できます。

このように識別されたアクティビティの各ユニットは、エレメンタリープロセス（EP）です。

ステップ4：独自の基本プロセスを決定する

すでに特定されている2つのEPを比較し、次の場合は1つのEP（同じEP）としてカウントします。

同じDETのセットが必要です。
同じFTRのセットが必要です。
EPを完了するには、同じ一連の処理ロジックが必要です。

複数の形式の処理ロジックを持つEPを複数のEpに分割しないでください。

たとえば、「従業員の追加」をEPとして識別した場合、従業員に扶養家族がいる場合といない場合があるという事実を説明するために、2つのEPに分割しないでください。EPはまだ「従業員の追加」であり、依存関係を説明するために処理ロジックとDETにバリエーションがあります。

ステップ5：データ関数を測定する

各データ関数をILFまたはEIFとして分類します。

データ関数は次のように分類されます。

内部論理ファイル（ILF）（測定対象のアプリケーションによって維持されている場合）。
外部インターフェースファイル（EIF）が参照されているが、測定対象のアプリケーションによって維持されていない場合。

ILFおよびEIFには、ビジネスデータ、制御データ、およびルールベースのデータを含めることができます。たとえば、電話交換は、ビジネスデータ、ルールデータ、制御データの3つのタイプすべてで構成されています。ビジネスデータは実際の呼び出しです。ルールデータは、コールをネットワーク経由でルーティングする方法であり、制御データは、スイッチが相互に通信する方法です。

ILFとEIFのカウントについては、次のドキュメントを検討してください。

提案されたシステムの目的と制約。
現在のシステム（そのようなシステムが存在する場合）に関するドキュメント。
ユーザーが認識している目的、問題、およびニーズの文書化。
データモデル。

ステップ5.1：各データ関数のDETを数える

次のルールを適用して、ILF / EIFのDETをカウントします-

EPの実行を通じてILFまたはEIFで維持されている、またはILFまたはEIFから取得されている、一意のユーザーを識別できる繰り返しのないフィールドごとにDETをカウントします。
2つ以上のアプリケーションが同じデータ関数を維持および/または参照するときに測定される、アプリケーションによって使用されているDETのみをカウントします。
別のILFまたはEIFとの関係を確立するために、ユーザーが必要とする属性ごとにDETをカウントします。
関連する属性を確認して、それらがグループ化されて単一のDETとしてカウントされているかどうか、または複数のDETとしてカウントされているかどうかを判別します。グループ化は、EPがアプリケーション内で属性をどのように使用するかによって異なります。

ステップ5.2：各データ関数のRETを数える

次のルールを適用して、ILF / EIFのRETをカウントします。

データ関数ごとに1つのRETをカウントします。
DETの次の追加の論理サブグループごとに1つの追加のRETをカウントします。
- キー以外の属性を持つ関連付けエンティティ。
- サブタイプ（最初のサブタイプを除く）。
- 必須の1：1以外の関係にある帰属エンティティ。

ステップ5.3：各データ関数の機能の複雑さを判断する

RETS	データ要素タイプ（DET）
RETS	1-19	20-50	>50
1	L	L	A
2から5	L	A	H
> 5	A	H	H

機能の複雑さ： L =低; A =平均; H =高

ステップ5.4：各データ関数の関数サイズを測定する

機能の複雑さ	ILFのFPカウント	EIFのFPカウント
低	7	5
平均	10	7
高い	15	10

ステップ6：トランザクション関数を測定する

トランザクション機能を測定するには、次の手順が必要です。

ステップ6.1：各トランザクション関数を分類する

トランザクション機能は、外部入力、外部出力、または外部照会として分類する必要があります。

外部入力

外部入力（EI）は、境界の外側から来るデータまたは制御情報を処理する基本プロセスです。EIの主な目的は、1つ以上のILFを維持すること、および/またはシステムの動作を変更することです。

次のすべてのルールを適用する必要があります-

データまたは制御情報は、アプリケーションの境界の外側から受信されます。
境界に入るデータがシステムの動作を変更する制御情報でない場合、少なくとも1つのILFが維持されます。
識別されたEPについては、3つのステートメントのいずれかを適用する必要があります-
- 処理ロジックは、アプリケーションの他のEIによって実行される処理ロジックとは異なります。
- 識別されたデータ要素のセットは、アプリケーション内の他のEIに対して識別されたセットとは異なります。
- 参照されるILFまたはEIFは、アプリケーション内の他のEIによって参照されるファイルとは異なります。

外部出力

外部出力（EO）は、アプリケーションの境界外にデータまたは制御情報を送信する基本プロセスです。EOには、外部からの問い合わせ以外の追加の処理が含まれます。

EOの主な目的は、データまたは制御情報の取得以外の、またはそれらに加えて、処理ロジックを介してユーザーに情報を提示することです。

処理ロジックは-でなければなりません

少なくとも1つの数式または計算が含まれています。
派生データを作成します。
1つ以上のILFを維持します。
システムの動作を変更します。

次のすべてのルールを適用する必要があります-

アプリケーションの境界の外部にデータまたは制御情報を送信します。
識別されたEPについては、3つのステートメントのいずれかを適用する必要があります-
- 処理ロジックは、アプリケーションの他のEOによって実行される処理ロジックとは異なります。
- 識別されたデータ要素のセットは、アプリケーション内の他のEOとは異なります。
- 参照されるILFまたはEIFは、アプリケーション内の他のEOによって参照されるファイルとは異なります。

さらに、次のいずれかのルールを適用する必要があります-

処理ロジックには、少なくとも1つの数式または計算が含まれています。
処理ロジックは、少なくとも1つのILFを維持します。
処理ロジックは、システムの動作を変更します。

外部からのお問い合わせ

外部照会（EQ）は、境界の外側にデータまたは制御情報を送信する基本プロセスです。EQの主な目的は、データまたは制御情報の取得を通じてユーザーに情報を提示することです。

処理ロジックには数式や計算が含まれておらず、派生データも作成されません。処理中にILFが維持されることも、システムの動作が変更されることもありません。

次のすべてのルールを適用する必要があります-

アプリケーションの境界の外部にデータまたは制御情報を送信します。
識別されたEPについては、3つのステートメントのいずれかを適用する必要があります-
- 処理ロジックは、アプリケーションの他のEQによって実行される処理ロジックとは異なります。
- 識別されたデータ要素のセットは、アプリケーション内の他のEQとは異なります。
- 参照されるILFまたはEIFは、アプリケーション内の他のEQによって参照されるファイルとは異なります。

さらに、次のすべてのルールを適用する必要があります-

処理ロジックは、ILFまたはEIFからデータまたは制御情報を取得します。
処理ロジックには、数式や計算は含まれていません。
処理ロジックは、システムの動作を変更しません。
処理ロジックはILFを維持しません。

ステップ6.2：各トランザクション関数のDETをカウントする

次のルールを適用して、EIのDETをカウントします-

境界を越える（入るおよび/または出る）すべてを確認します。
トランザクション関数の処理中に境界を越える（入るおよび/または出る）一意のユーザー識別可能で繰り返されない属性ごとに1つのDETをカウントします。
複数のメッセージがある場合でも、アプリケーション応答メッセージを送信する機能については、トランザクション関数ごとに1つのDETのみをカウントしてください。
複数の手段がある場合でも、アクションを開始する機能については、トランザクション関数ごとに1つのDETのみをカウントしてください。
以下の項目をDETとしてカウントしないでください-
- トランザクション関数によって境界内で生成され、境界を出ることなくILFに保存された属性。
- レポートのタイトル、画面またはパネルの識別子、列見出し、属性のタイトルなどのリテラル。
- 日付と時刻の属性など、アプリケーションで生成されたスタンプ。
- ページング変数、ページ番号、および位置情報。たとえば、「211の行37から54」。
- 「前へ」、「次へ」、「最初」、「最後」およびそれらのグラフィカルな同等物を使用してリスト内をナビゲートする機能などのナビゲーション支援。

次のルールを適用して、EO / EQのDETをカウントします-

境界を越える（入るおよび/または出る）すべてを確認します。
トランザクション関数の処理中に境界を越える（入るおよび/または出る）一意のユーザー識別可能で繰り返されない属性ごとに1つのDETをカウントします。
複数のメッセージがある場合でも、アプリケーション応答メッセージを送信する機能については、トランザクション関数ごとに1つのDETのみをカウントしてください。
複数の手段がある場合でも、アクションを開始する機能については、トランザクション関数ごとに1つのDETのみをカウントしてください。
以下の項目をDETとしてカウントしないでください-
- 境界を越えずに境界内で生成された属性。
- レポートのタイトル、画面またはパネルの識別子、列見出し、属性のタイトルなどのリテラル。
- 日付と時刻の属性など、アプリケーションで生成されたスタンプ。
- ページング変数、ページ番号、および位置情報。たとえば、「211の行37から54」。
- 「前へ」、「次へ」、「最初」、「最後」およびそれらのグラフィカルな同等物を使用してリスト内をナビゲートする機能などのナビゲーション支援。

ステップ6.3：各トランザクション関数のFTRをカウントする

次のルールを適用して、EIのFTRをカウントします-

維持されている各ILFのFTRをカウントします。
EIの処理中に読み取られたILFまたはEIFごとにFTRをカウントします。
維持および読み取りの両方であるILFごとに1つのFTRのみをカウントします。

次のルールを適用して、EO / EQのFTRをカウントします-

EPの処理中に読み取られたILFまたはEIFごとにFTRをカウントします。

さらに、次のルールを適用して、EOのFTRをカウントします-

EPの処理中に維持される各ILFのFTRをカウントします。
EPによって維持および読み取りされるILFごとに1つのFTRのみをカウントします。

ステップ6.4：各トランザクション機能の機能の複雑さを判断する

FTR	データ要素タイプ（DET）
FTR	1-4	5-15	>=16
0-1	L	L	A
2	L	A	H
> = 3	A	H	H

機能の複雑さ： L =低; A =平均; H =高

EQが最低1FTRを持っている必要があることを除いて、各EO / EQの機能の複雑さを決定します-

EQには最低1つのFTRが必要です FTR	データ要素タイプ（DET）
EQには最低1つのFTRが必要です FTR	1-4	5-15	> = 16
0-1	L	L	A
2	L	A	H
> = 3	A	H	H

機能の複雑さ： L =低; A =平均; H =高

ステップ6.5：各トランザクション関数の関数サイズを測定する

機能の複雑さから各EIの機能サイズを測定します。

複雑	FPカウント
低	3
平均	4
高い	6

機能の複雑さから各EO / EQの機能サイズを測定します。

複雑	EOのFPカウント	EQのFPカウント
低	4	3
平均	5	4
高い	6	6

ステップ7：機能サイズを計算する（未調整の機能ポイント数）

機能サイズを計算するには、以下の手順に従う必要があります-

ステップ7.1

手順1で見つけたものを思い出してください。カウントのタイプを決定します。

ステップ7.2

タイプに基づいて機能サイズまたは機能ポイント数を計算します。

開発ファンクションポイントカウントについては、ステップ7.3に進んでください。
アプリケーションファンクションポイントカウントについては、ステップ7.4に進んでください。
拡張ファンクションポイントカウントについては、ステップ7.5に進んでください。

ステップ7.3

開発ファンクションポイントカウントは、機能の2つのコンポーネントで構成されています-

プロジェクトのユーザー要件に含まれるアプリケーション機能。
プロジェクトのユーザー要件に含まれる変換機能。変換機能は、データを変換したり、特別な変換レポートなど、他のユーザー指定の変換要件を提供したりするために、インストール時にのみ提供される機能で構成されます。たとえば、既存のアプリケーションを新しいシステムに置き換えることができます。

DFP = ADD + CFP

どこ、

DFP =開発ファンクションポイントカウント

ADD =開発プロジェクトによってユーザーに提供される機能のサイズ

CFP =変換機能のサイズ

ADD = FPカウント（ILF）+ FPカウント（EIF）+ FPカウント（EI）+ FPカウント（EO）+ FPカウント（EQ）

CFP = FPカウント（ILF）+ FPカウント（EIF）+ FPカウント（EI）+ FPカウント（EO）+ FPカウント（EQ）

ステップ7.4

アプリケーションファンクションポイントカウントを計算する

AFP = ADD

どこ、

AFP =アプリケーションファンクションポイントカウント

ADD =開発プロジェクトによってユーザーに提供される関数のサイズ（変換機能のサイズを除く）、またはアプリケーションがカウントされるたびに存在する関数。

ADD = FPカウント（ILF）+ FPカウント（EIF）+ FPカウント（EI）+ FPカウント（EO）+ FPカウント（EQ）

ステップ7.5

拡張ファンクションポイントカウントは、機能の次の4つのコンポーネントを考慮します-

アプリケーションに追加される機能。
アプリケーションで変更される機能。
変換機能。
アプリケーションから削除される機能。

EFP = ADD + CHGA + CFP + DEL

どこ、

EFP =拡張ファンクションポイントカウント

ADD =拡張プロジェクトによって追加される機能のサイズ

CHGA =拡張プロジェクトによって変更される関数のサイズ

CFP =変換機能のサイズ

DEL =拡張プロジェクトによって削除される関数のサイズ

ADD = FPカウント（ILF）+ FPカウント（EIF）+ FPカウント（EI）+ FPカウント（EO）+ FPカウント（EQ）

CHGA = FPカウント（ILF）+ FPカウント（EIF）+ FPカウント（EI）+ FPカウント（EO）+ FPカウント（EQ）

CFP = FPカウント（ILF）+ FPカウント（EIF）+ FPカウント（EI）+ FPカウント（EO）+ FPカウント（EQ）

DEL = FPカウント（ILF）+ FPカウント（EIF）+ FPカウント（EI）+ FPカウント（EO）+ FPカウント（EQ）

ステップ8：値調整係数を決定する

GSCはCPM4.3.1でオプションになり、付録に移動しました。したがって、ステップ8とステップ9はスキップできます。

値調整係数（VAF）は、カウントされるアプリケーションの一般的な機能を評価する14のGSCに基づいています。GSCは、テクノロジーに依存しないユーザーのビジネス上の制約です。各特性には、影響の程度を決定するための説明が関連付けられています。

一般的なシステム特性	簡単な説明
データ通信	アプリケーションまたはシステムとの情報の転送または交換を支援するための通信設備はいくつありますか？
分散データ処理	分散データと処理機能はどのように処理されますか？
パフォーマンス	ユーザーは応答時間またはスループットを必要としましたか？
頻繁に使用される構成	アプリケーションが実行される現在のハードウェアプラットフォームはどの程度使用されていますか？
取引率	トランザクションは毎日、毎週、毎月などどのくらいの頻度で実行されますか？
オンラインデータ入力	情報の何パーセントがオンラインで入力されていますか？
エンドユーザーの効率	アプリケーションはエンドユーザーの効率を考慮して設計されましたか？
オンラインアップデート	オンライントランザクションによって更新されるILFはいくつですか？
複雑な処理	アプリケーションには広範な論理的または数学的処理がありますか？
再利用性	アプリケーションは、1つまたは複数のユーザーのニーズを満たすように開発されましたか？
インストールの容易さ	変換とインストールはどのくらい難しいですか？
操作のしやすさ	起動、バックアップ、および回復の手順はどの程度効果的および/または自動化されていますか？
複数のサイト	アプリケーションは、複数の組織の複数のサイトにインストールするように特別に設計、開発、およびサポートされていましたか？
変更を促進する	アプリケーションは、変更を容易にするために特別に設計、開発、およびサポートされましたか？

影響の程度の範囲は、影響なしから強い影響まで、0から5のスケールです。

評価	影響力の程度
0	存在しない、または影響なし
1	偶発的な影響
2	中程度の影響
3	平均的な影響
4	有意義な影響
5	全体に強い影響力

14のGSCのそれぞれの影響の程度を決定します。

このようにして得られた14個のGSCの値の合計は、総影響度（TDI）と呼ばれます。

TDI = ∑¹⁴ Degrees of Influence

次に、値調整係数（VAF）を次のように計算します。

VAF = (TDI × 0.01) + 0.65

各GSCは0から5まで変化し、TDIは（0×14）から（5×14）、つまり0（すべてのGSCが低い場合）から70（すべてのGSCが高い場合）、つまり0≤TDI≤70まで変化します。したがって、VAFは0.65（すべてのGSCが低い場合）から1.35（すべてのGSCが高い場合）の範囲で変化する可能性があります。つまり、0.65≤VAF≤1.35です。