ファンクションポイントのカウント

Question

プロジェクトのファンクションポイント分析（FPA）を実行しています。私はこのプロセスにまったく慣れておらず、得られた結果を検証するためのログインモジュールと認証モジュールのみから始めました。

私はデータ機能をよく理解していて、内部ロジックファイルと外部インターフェイスファイルの数は正しいと思います。トランザクション関数（EI、EO、EQ）の計算に関するガイダンスが必要です。

プロセス仕様は次のとおりです。

新規ユーザーは登録してからログインします
既存のユーザーが直接ログインする
登録時に収集および保存されたユーザーデータ。
ログイン時の通常の検証チェック：無効な資格情報のエラー、それ以外の場合は正常なログイン
ログインしたユーザーのために維持されるセッションの詳細。
nを超えるログインの後にユーザーが一時的に停止しました。
セッションはアイドルタイムアウトで自動的に終了しました。
パスワードを忘れた、または設定を更新してメール/パスワード設定を更新する

私はこのプロセスの非常に重要な部分をEI/EO/ILFとして数えています。

外部入力：4

ログインする
ログアウト
登録
設定を更新

外部出力：3

不完全/無効な登録フォーム
ログインが無効であるか、試行が失敗した後にユーザーがスロットルされました
セッションタイムアウト

内部論理ファイル：2

ユーザーデータ
セッションデータ

外部クエリまたは外部インターフェイスファイルはありません。

上記のカウントを低い複雑さで評価しているにもかかわらず、38 UFP = 2014 SLOC（Javaの場合：FPあたり53 SLOC）が得られます。これは、係数が最も低いCOCOMO IIを使用すると、驚くほど高い労力の見積もりになります。

私の疑問はFP=カウントまたは複雑度とは関係ありません。EIまたはEOとして正しいものを選択しているかどうかについて、私はより心配します。FPA手法を理解している限り、データ/コントロールアプリケーションの境界に入る情報はEIとしてカウントされるため、論理的にはログイン、ログアウト、サインアップ、設定の更新、パスワードの忘れがすべての入力です。同様に、無効なログイン、ログインの成功、無効なデータ関連のエラーメッセージ、タイムアウト情報などはすべて出力です。したがって、上記で数えたよりもさらに多くのEIおよびEOがありますが、出力FPカウントは非現実的に高くなります。

私はFPAを正しく行っていますか、それとも何かを誤解していましたか？

amon · Accepted Answer

通常、ファンクションポイント分析を正しく実行しており、結果は適切に見えます。しかしながら：

一部の出力を誤って分類しています。
あなたはその努力に対するCOCOMO IIの見積もりに驚きます。
この分析は、最新のWeb開発の現実を無視しています。Webフレームワークはおそらくすでにセッション管理を実装しています。

外部入力と外部出力とは何ですか？

グラフィカル・ユーザー・インターフェースの場合、EIおよびEOは画面、ウィジェット、またはフォームと考えるのが最善です。したがって、ログインフォームは1つの外部入力です。検証エラーを個別の外部出力として分類しています。検証（およびレート制限など）はログイン機能の一部であるため、私はそれを行いません。代わりに、特別なエラー処理を行う必要がある場合は、ログイン機能をより複雑に評価します。

あなたの商品を次のように分類します。

ログインフォーム：外部入力、中程度の複雑さ。（追加のレート制限ロジックおよびその他のセキュリティ上の考慮事項によって正当化されます）
登録フォーム：外部入力、シンプル。
ログアウトとセッションタイムアウト：外部入力、シンプル。
設定の更新：外部入力、シンプル。
パスワードを忘れた：外部入力、非常に複雑。（見た目はシンプルですが、慎重なセキュリティ設計が必要です）
セッションストレージ：内部論理ファイル、シンプル。
ユーザー詳細ストレージ：内部論理ファイル、シンプル。

そうです、ここには外部出力はありません！しかし、公平に言うと、このアプリケーションはまだ何も実行せず、ログインを提供するだけです。設定を表示するための別の画面と設定を更新するための別の画面がある場合、それを別の単純なEOとして数えます。また、ユーザーがログイン認証情報を入力するさまざまなポイントがいくつかの共通コードを共有しているため、パスワードの処理の複雑さはかなり単純です平均して。

複雑な重みを単純なEIに3倍、中程度のEIに4倍、複雑なEIに6倍、単純なILFに4倍の重みを使用すると、C = 27の関数点カウントに到達します。同じ球場。調整係数Fを使用する場合_私、これはさらに上下にシフトする可能性があります。

COCOMO IIの見積もりから何がわかりますか？

見積もりは、その機能のコーディングに費やされた時間を説明するだけではありません。これはプロジェクト期間全体の見積もりであり、ある程度の分析、設計、およびテストが含まれています。このトピックについて聞いた講義によると、推定作業量の約30％だけが開発タスクに費やされます。したがって、27 FPが約3.5人月の作業に対応する場合、その約1人月は開発時間になります。

COCOMOから得られる見積もりは信じられないほど長く聞こえる傾向がありますが、大規模な組織、さまざまなスキルレベル、予期しない複雑さやバグ、コーディングだけでなくソフトウェア開発に必要なすべての作業をコンテキストに入れると、楽観的になりすぎないように注意してください。もちろんそれは可能より速いですが、それに賭けるべきではありません。ファンクションポイント分析が細心の注意を払って行われ、FPAが適しているプロジェクトに適用される場合、数値は現実的な桁数になる傾向があります。

ファンクションポイントとWeb開発。

Web開発は少し異なります。

まず、堅牢なWebサイトをすばやく簡単に作成できる成熟したWebフレームワークとライブラリが多数あります（そのフレームワークをすでに知っている限り）。 1人の経験豊富な人がおそらく1日から1週間以内に要件を実装できます。ログインは非常に重要で基本的なため、Webフレームワークが実際に「HelloWorld」アプリケーションとしてこれを行う方法を教えてくれるかもしれません。

第二に、Web開発にははるかに多くのコード行が含まれる傾向がありますが、それほど難しくはありません。ログインフォームを手動で作成する場合は、フォームをHTMLで記述し、CSSでスタイルを設定し、JavaScriptでクライアント側のチェックを行い、ログインフォームが可能なURLを作成する必要がありますPOSTから、パスワードをチェックする実際のバックエンドコードを作成します。これは合計で400行のコードになる可能性がありますが、1か月かかることを意味するわけではありません。^[1] そのため、多くのコードは非常に迅速に記述されたボイラープレートであるため、Web開発にCOCOMOを適用することに警戒しています。

^{[1]：もちろん、ログインフォームの作成には1か月かかる場合があります。かなりの設計作業、または特別なセキュリティ機能が必要な場合。多くの大きなウェブサイトは、その小さなテキストフィールドにそれよりもはるかに多くの努力を費やしていると確信しています。}