機能ポイント

ファンクションポイントは、情報システム（製品）がユーザーに提供するビジネス機能の量を表す「測定単位」です。ファンクションポイントは、ソフトウェアの機能サイズ測定（FSM）を計算するために使用されます。単一ユニットのコスト（ドルまたは時間）は、過去のプロジェクトから計算されます。^{[ 1 ]}

ファンクションポイントに基づいてソフトウェアのサイズを決定するための、いくつかの認知された標準規格や公開仕様が存在する。

1. ISO規格

• FiSMA: ISO/IEC 29881:2010 情報技術 - システムおよびソフトウェアエンジニアリング - FiSMA 1.1 機能サイズ測定方法。
• IFPUG : ISO/IEC 20926:2009 ソフトウェアおよびシステムエンジニアリング - ソフトウェア測定 - IFPUG 機能サイズ測定方法。
• Mark-II: ISO/IEC 20968:2002 ソフトウェアエンジニアリング – Mark II ファンクションポイント分析 – カウント方法マニュアル
• Nesma: ISO/IEC 24570:2018 ソフトウェアエンジニアリング – Nesma機能サイズ測定方法バージョン2.3 – ファンクションポイント分析の適用に関する定義とカウントガイドライン
• COSMIC : ISO/IEC 19761:2011 ソフトウェアエンジニアリング。機能サイズ測定方法。
• OMG : ISO/IEC 19515:2019 情報技術 — オブジェクト管理グループ 自動機能ポイント (AFP)、1.0

最初の 5 つの規格は、機能サイズ測定に関する包括的な規格ISO/IEC 14143の実装です。 ^{[ 2 ]} IT ソフトウェア品質コンソーシアムが主導する OMG 自動機能ポイント (AFP) 仕様は、国際機能ポイントユーザーグループ ( IFPUG )のガイドラインに従って機能ポイントのカウントを自動化するための規格を提供します。ただし、この規格の現在の実装には、事前の設定なしに外部出力 (EO) と外部照会 (EQ) をすぐに区別できるという制限があります。^{[ 3 ]}

ファンクションポイントは、1979 年にIBMの Allan J. Albrecht が著した「アプリケーション開発生産性の測定」で定義されました。^{[ 4 ]}ソフトウェアの機能的なユーザー要件が特定され、それぞれが出力、照会、入力、内部ファイル、外部インターフェースの 5 つのタイプのいずれかに分類されます。機能が特定され、タイプに分類されると、その複雑さが評価され、ファンクションポイントの数が割り当てられます。これらの機能的なユーザー要件はそれぞれ、入力の場合はデータ入力、照会の場合はユーザークエリなど、エンドユーザーのビジネス機能に対応します。この区別は、ファンクションポイントで測定される機能がユーザー指向の要件に容易に対応できるようになる傾向がある一方で、実装にリソースを必要とする内部機能 (アルゴリズムなど) を隠してしまう傾向があるため重要です。

現在、アルゴリズムの複雑さをサイズ算出結果に含めたISO認定のFSMメソッドは存在しません。近年、この弱点に対処するための様々なアプローチが提案され、いくつかの商用ソフトウェア製品に実装されています。この弱点（およびその他の弱点）を補うために設計されたAlbrechtベースのIFPUGメソッドのバリエーションには、以下のようなものがあります。

• 早期かつ容易な機能ポイント – 2つの質問によって問題とデータの複雑さを調整し、やや主観的な複雑さの測定値が得られます。データ要素を数える必要がないため、測定が簡素化されます。
• エンジニアリング機能ポイント – 要素（変数名）と演算子（算術、等号/不等号、ブールなど）がカウントされます。このバリエーションは計算機能を強調します。^{[ 5 ]}意図は、演算子/オペランドベースのハルステッド複雑度尺度と同様です。
• バン尺度 – バンに影響を与える、またはバンを示す12個の基本的な（単純な）カウントに基づく機能メトリックを定義します。バンとは、「ユーザーが認識する、実際に提供される機能の尺度」と定義されます。バン尺度は、ソフトウェアユニットがどれだけ有用な機能を提供するかという観点からその価値を評価するのに役立つ可能性がありますが、文献にはそのような適用例はほとんどありません。バン尺度の使用は、『運用システムの保守 - 概要』で説明されているように、再設計（完全なもの、または部分的なもの）を検討している場合に適用できます。
• 機能ポイント – 内部処理能力の高いシステム（オペレーティングシステム、通信システムなど）への適用性を向上させるための変更を追加しました。これにより、ユーザーには容易に認識できないものの、正常な動作に不可欠な機能を考慮に入れることが可能になります。
• 加重マイクロファンクションポイント– プログラムの流れの複雑さ、オペランドと演算子の語彙、オブジェクトの使用、およびアルゴリズムから導き出された重みを使用してファンクションポイントを調整する、比較的新しいモデル（2009年）の1つ。
• ファジー関数点 - 低×中と中×高の複雑性の間の曖昧で段階的な遷移を提案します^{[ 6 ]}

コード行数の代わりにファンクションポイントを使用する目的は、いくつかの追加的な問題に対処することにある。

• 開発者の生産性を高めるインセンティブが与えられると、生成されるコード行数が「インフレ」し、結果として測定システムの価値が低下するリスクがある。FP（ファンクションプログラミング）の提唱者は、これを問題の大きさではなく、解決策の大きさを測定することだと表現する。
• コード行数（LOC）は、低レベル言語の方が同等の機能を実現するのに必要なコード行数が多いため、低レベル言語を優遇する指標です。^{[ 7 ]} C. Jonesは、自身の研究でこの問題を解決する方法を提案しています。^{[ 8 ]}
• LOC（コード行数）は、納品されるコード行数を推定するのが難しいプロジェクトの初期段階では役に立ちません。しかし、ファンクションポイントは要件から導き出すことができるため、代理見積もりなどの手法において有用です。

アルブレヒトは研究の中で、ファンクションポイントはコード行数と高い相関関係にあることを指摘した^{[ 9 ]。}そのため、より客観的な指標、すなわちコード行数を数える方法がある場合、そのような指標の価値が疑問視されるようになった。さらに、この指標の欠点と認識されている点に対処するために、数える方法を強化する試みが複数行われてきた^{[ 10 ] [ 11 ] [ 12 ] [ 13 ] [ 14 ] [ 15 ]。}また、提供された機能量の代理指標を作成する代替方法を開発することで、課題を回避する解決策を提案した者もいる^{[ 16 ] 。}

• COCOMO（構成コストモデル）
• 開発見積もりソフトウェアの比較
• COSMIC機能サイズ測定
• マークIIメソッド
• 対象点
• ソフトウェア開発工数見積もり
• ソフトウェアサイジング
• ソースコードの行数
• 事例ポイントを活用する
• 単純関数点法

• 国際ファンクションポイントユーザーグループ（IFPUG）