Estimation-techniques-fp-counting-process
推定手法-FPカウントプロセス
FPカウントプロセスには次の手順が含まれます-
- *ステップ1 *-カウントのタイプを決定します。
- *ステップ2 *-カウントの境界を決定します。
- *ステップ3 *-ユーザーが必要とする各Elementary Process（EP）を特定します。
- *ステップ4 *-一意のEPを決定します。
- *ステップ5 *-データ関数を測定します。
- *ステップ6 *-トランザクション関数を測定します。
- *ステップ7 *-機能サイズ（未調整の機能ポイントカウント）を計算します。
- *ステップ8 *-値調整係数（VAF）を決定します。
- *ステップ9 *-調整された機能ポイント数を計算します。
注-一般システム特性（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で維持または取得された、一意のユーザーを識別可能な繰り返しのないフィールドごとにDETをカウントします。
- 2つ以上のアプリケーションが同じデータ関数を維持および/または参照するときに測定されるアプリケーションで使用されているDETのみをカウントします。
- ユーザーが別のILFまたはEIFとの関係を確立するために必要な各属性のDETをカウントします。
- 関連する属性を確認して、グループ化されて単一のDETとしてカウントされるか、複数のDETとしてカウントされるかを判断します。 グループ化は、EPがアプリケーション内の属性をどのように使用するかに依存します。
ステップ5.2：各データ関数のRETをカウントする
次のルールを適用して、ILF/EIFのRETをカウントします-
- データ関数ごとに1つのRETをカウントします。
- DETの次の追加の論理サブグループごとに、追加のRETを1つカウントします。
- 非キー属性を持つ関連エンティティ。
- サブタイプ（最初のサブタイプ以外）。
- 必須の1：1以外の関係にある属性エンティティ。
ステップ5.3：各データ関数の機能の複雑さを決定する
RETS
データ要素タイプ（DET）
*1-19**20-50*- > 50 *
1
L
L
A
2から5
L
A
H
>5
A
H
H
機能の複雑さ： L =低; A =平均; H =高
ステップ5.4：各データ関数の機能サイズを測定する
| Functional Complexity | FP Count for ILF | FP Count for EIF |
|---|---|---|
| Low | 7 | 5 |
| Average | 10 | 7 |
| High | 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に保存される属性。
- レポートのタイトル、画面またはパネルの識別子、列見出し、属性タイトルなどのリテラル。
- 日付および時刻属性などのアプリケーション生成スタンプ。
- 「行37〜54の211」などのページング変数、ページ番号、位置情報。
- 「前へ」、「次へ」、「最初」、「最後」、およびそれらに相当するグラフィックを使用してリスト内をナビゲートする機能などのナビゲーション支援。
次のルールを適用して、EO/EQのDETをカウントします-
- 境界を越える（出入りする）すべてを確認します。
- トランザクション機能の処理中に境界を越える（出入りする）一意のユーザー識別可能な繰り返しのない属性ごとに1つのDETをカウントします。
- 複数のメッセージがある場合でも、アプリケーション応答メッセージを送信するために、トランザクション関数ごとに1つのDETのみをカウントします。
- アクションを開始する機能が複数ある場合でも、トランザクション機能ごとに1つのDETのみをカウントします。
- 次の項目をDETとしてカウントしないでください-
- 境界を越えずに境界内で生成された属性。
- レポートのタイトル、画面またはパネルの識別子、列見出し、属性タイトルなどのリテラル。
- 日付および時刻属性などのアプリケーション生成スタンプ。
- 「行37〜54の211」などのページング変数、ページ番号、位置情報。
- 「前へ」、「次へ」、「最初」、「最後」、およびそれらに相当するグラフィックを使用してリスト内をナビゲートする機能などのナビゲーション支援。
ステップ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：各トランザクション関数の機能の複雑さを決定する
FTRs
データ要素タイプ（DET）
*1-4**5-15*- > = 16 *
0-1
L
L
A
2
L
A
H
>=3
A
H
H
機能の複雑さ： L =低; A =平均; H =高
EQには最低1 FTRが必要であることを除いて、各EO/EQの機能の複雑さを決定します-
EQには最低1つのFTRが必要です
FTRs
データ要素タイプ（DET）
1-4
5-15
>=16
0-1
L
L
A
2
L
A
H
>=3
A
H
H
機能の複雑さ： L =低; A =平均; H =高
ステップ6.5：各トランザクション関数の機能サイズを測定する
機能の複雑さから各EIの機能サイズを測定します。
| Complexity | FP Count |
|---|---|
| Low | 3 |
| Average | 4 |
| High | 6 |
機能の複雑さから各EO/EQの機能サイズを測定します。
| Complexity | FP Count for EO | FP Count for EQ |
|---|---|---|
| Low | 4 | 3 |
| Average | 5 | 4 |
| High | 6 | 6 |
ステップ7：機能サイズの計算（未調整の機能ポイント数）
機能サイズを計算するには、以下の手順に従う必要があります-
ステップ7.1
ステップ1で見つけたものを思い出してください。 カウントのタイプを決定します。
ステップ7.2
タイプに基づいて機能サイズまたは機能ポイント数を計算します。
- 開発機能のポイント数については、ステップ7.3に進みます。
- アプリケーション機能のポイント数については、ステップ7.4に進みます。
- 拡張機能のポイントカウントについては、ステップ7.5に進みます。
ステップ7.3
開発機能ポイントカウントは、機能の2つのコンポーネントで構成されています-
プロジェクトのユーザー要件に含まれるアプリケーション機能。
プロジェクトのユーザー要件に含まれる変換機能。 変換機能は、インストール時にのみ提供される機能で構成され、データを変換したり、特別な変換レポートなどの他のユーザー指定の変換要件を提供したりします。 例えば 既存のアプリケーションを新しいシステムに置き換えることができます。
*DFP = ADD＆plus; CFP*
どこで、
*DFP* =開発機能ポイント数*ADD* =開発プロジェクトによってユーザーに提供される機能のサイズ*CFP* =変換機能のサイズ*ADD* = FPカウント（ILF）＆plus; FPカウント（EIF）＆plus; FPカウント（EI）＆plus; FPカウント（EO）＆plus; FPカウント（EQ）*CFP* = FPカウント（ILF）＆plus; FPカウント（EIF）＆plus; FPカウント（EI）＆plus; FPカウント（EO）＆plus; FPカウント（EQ）ステップ7.4
アプリケーション関数のポイントカウントを計算する
*AFP = ADD*どこで、
*AFP* =アプリケーション機能ポイント数*ADD* =開発プロジェクトによってユーザーに提供される機能のサイズ（変換機能のサイズを除く）、またはアプリケーションがカウントされるたびに存在する機能。*ADD* = FPカウント（ILF）＆plus; FPカウント（EIF）＆plus; FPカウント（EI）＆plus; FPカウント（EO）＆plus; FPカウント（EQ）ステップ7.5
拡張機能ポイント数は、機能の次の4つのコンポーネントを考慮します-
アプリケーションに追加される機能。
アプリケーションで変更される機能。
変換機能。
アプリケーションから削除される機能。
*EFP = ADD＆plus; CHGA＆plus; CFP＆plus; DEL*
どこで、
*EFP* =拡張機能ポイント数*ADD* =拡張プロジェクトによって追加される機能のサイズ*CHGA* =拡張プロジェクトによって変更される機能のサイズ*CFP* =変換機能のサイズ*DEL* =拡張プロジェクトによって削除される機能のサイズ*ADD* = FPカウント（ILF）＆plus; FPカウント（EIF）＆plus; FPカウント（EI）＆plus; FPカウント（EO）＆plus; FPカウント（EQ）*CHGA* = FPカウント（ILF）＆plus; FPカウント（EIF）＆plus; FPカウント（EI）＆plus; FPカウント（EO）＆plus; FPカウント（EQ）*CFP* = FPカウント（ILF）＆plus; FPカウント（EIF）＆plus; FPカウント（EI）＆plus; FPカウント（EO）＆plus; FPカウント（EQ）*DEL* = FPカウント（ILF）＆plus; FPカウント（EIF）＆plus; FP COUNT（EI）＆plus; FPカウント（EO）＆plus; FPカウント（EQ）ステップ8：値調整係数を決定する
GSCはCPM 4.3.1でオプションになり、付録に移動しました。 したがって、ステップ8とステップ9はスキップできます。
値調整係数（VAF）は、カウントされるアプリケーションの一般的な機能を評価する14のGSCに基づいています。 GSCは、テクノロジーに依存しないユーザービジネスの制約です。 各特性には、影響の程度を判断するための説明が関連付けられています。
| General System Characteristic | Brief Description |
|---|---|
| Data Communications | How many communication facilities are there to aid in the transfer or exchange of information with the application or system? |
| Distributed Data Processing | How are distributed data and processing functions handled? |
| Performance | Did the user require response time or throughput? |
| Heavily Used Configuration | How heavily used is the current hardware platform where the application will be executed? |
| Transaction Rate | How frequently are transactions executed daily, weekly, monthly, etc.? |
| On-Line Data Entry | What percentage of the information is entered online? |
| End-user Efficiency | Was the application designed for end-user efficiency? |
| Online Update | How many ILFs are updated by online transaction? |
| Complex Processing | Does the application have extensive logical or mathematical processing? |
| Reusability | Was the application developed to meet one or many user’s needs? |
| Installation Ease | How difficult is conversion and installation? |
| Operational Ease | How effective and/or automated are start-up, back-up, and recovery procedures? |
| Multiple Sites | Was the application specifically designed, developed, and supported to be installed at multiple sites for multiple organizations? |
| Facilitate Change | Was the application specifically designed, developed, and supported to facilitate change? |
影響範囲の範囲は、影響なしから強い影響まで、0〜5のスケールです。
| Rating | Degree of Influence |
|---|---|
| 0 | Not present, or no influence |
| 1 | Incidental influence |
| 2 | Moderate influence |
| 3 | Average influence |
| 4 | Significant influence |
| 5 | Strong influence throughout |
14個のGSCのそれぞれの影響度を決定します。
このようにして得られた14個のGSCの値の合計は、影響度合計（TDI）と呼ばれます。
- TDI = ∑ ^ 14 ^影響度*
次に、値調整係数（VAF）を次のように計算します
*VAF =（TDI×0.01）＆plus; 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です。
ステップ9：調整済み関数ポイントカウントの計算
VAF（V4.3.1より前のCPMバージョン）を使用するFPAアプローチにより、これは、
- 調整済みFPカウント=未調整FPカウント×VAF *
ここで、未調整のFPカウントは、ステップ7で計算した機能サイズです。
VAFは0.65から1.35まで変化する可能性があるため、VAFは最終調整FPカウントに±35％の影響を及ぼします。
ファンクションポイントの利点
機能点は便利です-
- 問題のサイズの代わりにソリューションのサイズを測定する。
- 機能ポイントが必要なのは要件だけであるためです。
- テクノロジーに依存しないため。
- プログラミング言語に依存しないため。
- テストプロジェクトの見積もり。
- プロジェクト全体のコスト、スケジュール、および労力を見積もる際。
- 契約交渉では、ビジネスグループとのコミュニケーションを容易にする方法を提供します。
- ソフトウェアの機能の実際の使用、インターフェース、および目的に値を定量化し割り当てます。
- 時間、コスト、人員、期間、その他のアプリケーションメトリックなど、他のメトリックとの比率を作成する場合。
FPリポジトリ
ISBSG（International Software Benchmarking Standards Group）は、ITデータ用の2つのリポジトリを拡大および維持しています。
- 開発および強化プロジェクト
- メンテナンスおよびサポートアプリケーション
Development and Enhancement Projectsリポジトリには6,000以上のプロジェクトがあります。
データはMicrosoft Excel形式で配信されるため、必要な分析を簡単に行うことができます。また、データを他の目的に使用することもできます。
ISBSGリポジトリライセンスは、http：//www.isbsg.com/から購入できます。
ISBSGは、割引コード「IFPUGMembers」を使用すると、オンライン購入でIFPUGメンバーに10％の割引を提供します。
ISBSGソフトウェアプロジェクトデータリリースの更新は、http：//www.ifpug.org/isbsg/にあります。
COSMICとIFPUGは協力して、ソフトウェアの非機能要件とプロジェクト要件に関する用語集を作成しました。 以下からダウンロードできます-http://cosmic-sizing.org/publications/glossary-of-terms-for-nf-and-project-requirements/[cosmic-sizing.org]
