回答:
個人的には、「ファンクションポイントとは」という質問に対する明確な答えは見当たりません。そのようなことがなければ、私はファンクションポイントで何かを行うと主張する推定方法論に本当に躊躇しています。
深刻なソフトウェア推定方法論の最も重要な部分は「実績への定期的な再調整」です。つまり、見積もりを作成し、それを書き留め、プロジェクトが終了したら、実際の結果を見積もりと比較します。必要に応じて、見積もりプロセスを修正します。これには、入力と推定プロセスを実際の入力と比較することが含まれます。
たとえば、ソースコード行（SLOC）を見積もり、そこから進んだ場合、実際に配信されたSLOCを見積もりSLOCと比較し、迷ったかどうか、どこまで、どこで、なぜ迷ったかを確認する必要があります。SLOCの見積もりが正確で正確な場合、工数を完全に予測する見積もり担当者は、SLOCの見積もりに価値がない場合は効果がありません。ごみが出て、ごみが出ます。（同じことが関数ポイントにも当てはまります。）
SLOC（または関数ポイント）の実績が最初の見積もりと一致する場合は、見積もりコストと実績コストを比較し、見積もりパラメーターを調整して結果を改善できます。General Dynamics / Fort Worth Divisionは、1980年代初頭に、F-16C / Dソフトウェア開発のためにこの演習を詳細に行い、その後数年間、これらの見積もりに会社の最終利益を賭けていました。GD / FWは、かなりの間、GDのキャッシュカウであり、会社の残りの部分を浮かせたままでした。
また、要件と機能のクリープはソフトウェア推定の敵であることに注意してください。
（これは後で編集します。）Berndの最後の点は答えに値します。彼は早い時期に来るプロジェクトについて何をすべきかを尋ね、割り当てられたすべての工数を費やさないでください。
これは、（はるかに一般的な）スケジュールのオーバーランと同じくらいの見積もりエラーです。問題の事実は次のとおりです。すべてのプロジェクトがスケジュールを超過している場合、見積もり担当者は仕事をしていません。
見積もり担当者がすべてを正しく行っており、マネージャーがすべてを正しく行っている場合は、いくつかのプロジェクトが遅れて発生するプロジェクトに加えて、早期に発生することになります。推定値は確率です。見積もりを日陰にしてスケジュールのアンダーランを排除し、BY DEFINITIONによってスケジュールのオーバーランの可能性を増やします。あなたの管理がアンダーランのゼロ可能性とスケジュールと見積もりを要求した場合は、スケジュール配布されようとしているWILL保証、オーバーランすることを、その後、あなたは死の行進の需要を見て開始し、その後、あなたは辞任を見始めると、あなたのオーバーランGETはるかに、はるかに悪いことに、あなたが後任を募集しようとするとき（そしてあなたの会社がスウェットショップであるという言葉が出てきます）。
プロジェクトの範囲を扱う場合、一般的には、コード行ではなく関数ポイントの測定を使用することをお勧めします。ソフトウェアプロジェクトは数百万を超えるLOC（ライブラリのLOCを含む）を持つ可能性があるため、その数は比較的意味がなくなります。
ライブラリから機能を呼び出す場合、LOCをどのように測定しますか？ライブラリのLOCを含めますか？ライブラリからLOCを含めない場合、上司は十分なLOCを記述していませんか？
一般に、「XXX行のコードを記述した」よりも「XXXの機能を完了した」と言う方が適切です。
しかし、私はあなたがあなた自身のために見ることを勧めます。 関数ポイントまたはコード行を推定する方が簡単ですか？これらの結果をCOCOMO IIモデルに接続し、どちらが使いやすいかを確認してください。
また、このCOCOMO IIマニュアルでは、11ページあたりの関数ポイントとLOCの詳細な説明が記載されています。
私は、固定価格プロジェクトを計算するための関数ポイントを導入した組織で働いています。つまり、顧客と仕様に基づいてカウントし、カウントを一致させてから、＃FPにFP価格を掛けて、プロジェクト価格を決定します。これらすべては、年間2桁のミリオンユーロのプロジェクトの売上高を伴う環境で発生します。摩擦の絶え間ない原因であった価格決定から曖昧さと交渉を取り除くことが意図されています。
最初のキャリブレーションを行い、2桁のミリオンユーロに相当する約2年間のプロジェクト履歴を評価しました。
#FPとプロジェクトのコストは非常に間接的に相関していることがわかります。+/- 50％の偏差は合理的に可能です。ただし、長期的には機能点数とプロジェクトコストが収束することがわかります（期待どおり、またはそれ以上：期待しています）。
私たちは現在、これを組織と経験に展開する過程にあります（超現実的な観点から）：
FPカウントルールの適用に関する議論。これには基準がありますが、直接価格について議論できない場合、これらは無視されます。
キャリブレーションとキャリブレーション検証に費やした努力にもかかわらず、価格が上がったというクライアントの印象。疑わしい理由は、この手順によりコストが残酷に明確になり、一部の「問い合わせない」または戦略的プロジェクトでコストを隠したり、シフトしたり、カバーしたりする方法がないためです。
コストをカバーしないプロジェクトを処理する必要がある（50％アンダーシュート...）
コード行を優先して関数ポイントを使用すると、いくつかの追加の問題に対処しようとします。
•開発者がより生産的になるように動機付けされている場合、作成されたコード行の「インフレ」のリスク、したがって測定システムの価値を低下させるリスク。FPの擁護者は、これを問題のサイズではなく、ソリューションのサイズを測定するものとして参照します。
•高レベルの言語に同様の機能を提供するには、より多くのコード行が必要であるため、コードの行（LOC）は低レベルの言語に報酬を与えます。C.ジョーンズは彼の作品でこれを修正する方法を提供しています。
•LOCメジャーは、配信されるコードの行数を見積もることが難しいプロジェクトの初期段階では役立ちません。ただし、関数ポイントは要件から導出できるため、プロキシによる推定などの方法で役立ちます。