2016-05-11 17 views
1

機能点分析の意味は何ですか? それはソフトウェアのコスト見積もりに使用されますか?関数Point Analysisを定義する適切な定義がありますか? あなたは私にそれについての短い説明を教えてくれますか?ファンクションポイント分析とは何ですか?

+0

私はあなたがウィキペディアを試していないと信じられません:-) https://en.wikipedia.org/wiki/Function_point – Leo

+0

私は多くのサイトを試しました。しかし、私はちょうどそれの正確で明確な意味をしたかった。 –

答えて

1

IFPUG

http://www.ifpug.org/about-ifpug/about-function-point-analysis/

ファンクションポイント分析(FPA)から公式の答えは、明確なビジネス 意義のサイジング尺度です。 1979年にIBMのAllan Albrechtによって最初に公表された FPA技術は、ソフトウェアユーザーに意味のある 用語のソフトウェアに含まれる機能を定量化します。この対策は、ソフトウェアが に対処することを目的としたビジネス要件に直接 を関連付けるものです。したがって、開発環境の幅広い範囲にまたは開発初期の要件定義から完全な運用に至るまで、開発中の プロジェクトの幅広い範囲にわたって容易に適用することができます。 開発 プロセスの生産性やソフトウェアをサポートする単位あたりのコストなどの他のビジネス手段も容易に導き出すことができます。機能点数値自体は 段数で得られます。標準的な基準の標準化されたセットを使用して、 それぞれのビジネス関数は、そのタイプと の複雑さに従った数値インデックスです。これらの指標は合計されて、 サイズの初期測定値を与え、その後、ソフトウェア全体に関連する多くの要因 を組み込むことによって正規化される。最終的な結果は、ソフトウェア製品のサイズと複雑度を測定するファンクションポイントインデックスと呼ばれる単一の数字 です。

要約すると、ファンクションポイントのテクニックは、評価、計画、ソフトウェア生産の管理と制御を支援する目的で提供されています( )。

ps。 IFPUGの定義は、ブラジルの裁判所で機能点に関する紛争が起こっている場合(これは主に、政府契約は通常FPで定義されているため)、具体的に取られているものです。

+0

非常にありがとう@Leo –

3

私はレオの回答に同意しますが、より実用的な説明を試みるでしょう:ISOによって承認されたとして

を何それは

ファンクションポイント分析(FPA)であること(ISO/IEC 14143を参照)機能のサイジングのために、現在5つの規格の一つです。 FPAは、実際には、「IFPUG機能規模測定」というタイトルのISO/IEC 20926規格に広く使われている短期間の用語です。

FPAは、ソフトウェアに対する機能要件の量を評価するための手段です(「測定値」という用語は、実際には誤解を招くものです)。この評価を達成するために、以前の「機能的分解」として知られていた技術が使用されています。この概念は、詳細なルールと表記法が全く異なるにもかかわらず、実際には「ユースケース」の要件を記述することに非常に近いものです。要するに、機能要件は、「基本機能」に分解され、次いで、それぞれがポイント値で評価される。すべての基本機能のポイントの合計は、「サイズ」または要件の量の指標として使用されます。これは「機能点」(fp)の単位で表される「機能的サイズ」と呼ばれます。

機能分解の自然な表現は機能ツリーです。

FPA標準には、既存のアプリケーションの変更を評価するための一連のルールもあり、既存のシステムの拡張(「拡張」または「リリース」)の適応のための機能要件を評価するために使用できます。それは

FPAではありません何

自体で努力推定技術ないです。明らかに、機能要件の大きさと実装努力との間の関係は、むしろ緩やかであり、しばしば緩やかである。関数点は、より複雑な見積もりモデル(COCOMOなど)への(1つの)入力として使用することができ、他のすべての努力ドライバーを考慮する必要があります。

FPAはではありません。「ソフトウェアメトリック」 - 機能サイズは、ソフトウェアによって満たされるユーザー要件に常に関連しています。コード行やコードの複雑さを数えたり測定したりすることができますが、機能的なサイズは分析プロセスの結果です。それを使用する場合は

FPAは、要件が知られているが、実装の詳細は、まだ指定されたか、評価されていない場合は、早い段階でソフトウェアプロジェクトのための努力を推定するのに役立ちます。機能要件は機能サイズに反映され、非機能要件は評価モデルに入力する必要があります。あなたは良い、実績のある(そして信頼できる)モデルを持っている/使用する必要があります。そうでなければ、機能的なサイズはこの目的には役に立たないのです。

FPAは、「回復コスト」という意味でアプリケーションの「価値」を評価するのに役立ちます。

最終的に、ITクライアント/ベンダーとの関係では、FPAを価格設定の基礎として使用することができます。顧客は、時間当たりのレートではなく、合意された「価格/単価」に基づいて請求されます。ないを使用する

は定義により

、FPAは、機能要件の基本的な理解が必要です。したがって、FPAを使用することが不可能ではないにしても、機能上の要件を満たしていない、または知っていなければ、難しくなります。

FPAは、個人のパフォーマンスを評価するのに適していません。これは、アプリケーションにとってはかなり総合的な評価であり、一部のみをサイズ設定することはできません。

+0

それは良い例だったでしょう。また、あなたのテキストは混乱しているようです。あなたは初めに「FPAは努力予測技術ではない」と言ったが、後で「FPAはソフトウェアプロジェクトのための努力を推定するのに役立つ」と言った。少なくとも私は混乱しているように思えます。私は信じている。努力の推定に何かを使うことも、まったく使うこともできません。あなたは明確にしたいですか? – SimpleGuy

+0

Nomen est omen ;-)私の声明を「FPAに変更することは、努力の見積もり技術ではありません**」と私はそうしています。 「使用するとき」という段落は、FPAからの努力見積もりを得るためには、合理的な(努力推定)モデルが必要であることを示しています。 – Benny

+0

: - Pはいコメントは私を助けていて、他の人にも役立つと思います! – SimpleGuy

関連する問題