ファンクションポイントは、情報システム(製品として) がユーザーに提供するビジネス機能の量を表す「測定単位」です。ファンクション ポイントは、ソフトウェアの機能サイズ測定 (FSM) を計算するために使用されます。1 つのユニットのコスト (ドルまたは時間単位) は、過去のプロジェクトから計算されます。[1]
標準
ファンクション ポイントに基づいてソフトウェアのサイズを決定するための、いくつかの公認標準および/または公開仕様が存在します。
1. ISO規格
- FiSMA: ISO/IEC 29881:2010 情報技術 - システムおよびソフトウェア エンジニアリング - FiSMA 1.1 機能サイズ測定方法。
- IFPUG : ISO/IEC 20926:2009 ソフトウェアおよびシステム エンジニアリング - ソフトウェア測定 - IFPUG 機能サイズ測定方法。
- Mark-II: ISO/IEC 20968:2002 ソフトウェアエンジニアリング - Ml 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]その意図は、演算子/オペランドベースのハルステッド複雑性指標の意図と同様です。
- Bang 測定 – Bang に影響を与える、または Bang を示す 12 個のプリミティブ (単純) カウントに基づく機能メトリックを定義します。Bang は、「ユーザーが認識する、提供される真の機能の測定」として定義されます。Bang 測定は、ソフトウェア ユニットが提供する有用な機能の量という観点からソフトウェア ユニットの価値を評価するのに役立つ場合がありますが、このような適用に関する文献の証拠はほとんどありません。Bang 測定の使用は、「運用システムの保守 - 概要」で説明されているように、再エンジニアリング (完全または部分的) が検討されている場合に適用できます。
- 機能ポイント - 重要な内部処理 (オペレーティング システム、通信システムなど) を備えたシステムへの適用性を向上させるための変更を追加します。これにより、ユーザーが容易に認識できないが、適切な操作に不可欠な機能を考慮できるようになります。
- 重み付けマイクロ機能ポイント- プログラム フローの複雑さ、オペランドと演算子の語彙、オブジェクトの使用法、およびアルゴリズムから得られた重みを使用して機能ポイントを調整する新しいモデル (2009) の 1 つです。
- ファジー機能ポイント - 低×中複雑度と中×高複雑度の間のファジーかつ段階的な移行を提案する[6]
対比
コード行の代わりに関数ポイントを使用すると、次のようないくつかの追加の問題に対処できます。
- 開発者に生産性向上のインセンティブを与えると、作成されたコード行数が「膨張」し、測定システムの価値が低下するリスクがあります。FP の支持者は、これを問題のサイズではなくソリューションのサイズを測定することと呼んでいます。
- コード行数(LOC)の尺度では、高水準言語と同等の機能を提供するにはより多くのコード行数が必要になるため、低水準言語が優遇される。[7] C.ジョーンズは、彼の研究でこれを修正する方法を提案している。[8]
- LOC 測定は、提供されるコード行数を見積もることが困難なプロジェクトの初期段階では役に立ちません。ただし、ファンクション ポイントは要件から導き出すことができるため、代理見積などの方法では役立ちます。
批判
アルブレヒトは研究の中で、ファンクションポイントがコード行数と高い相関関係にあることを観察しました。[9]そのため、より客観的な指標、つまりコード行数を数える方法が利用できる場合、そのような指標の価値が疑問視されるようになりました。さらに、この指標の欠点に対処するために、カウント方法を強化する試みが何度も行われてきました。[10] [11] [12] [13] [14] [15]他の人たちは、提供される機能の量の代理を作成する代替方法を開発することで、課題を回避する解決策を提案しました。[16]
参照
- COCOMO(建設的コストモデル)
- 開発見積ソフトウェアの比較
- COSMIC機能サイズ測定
- マークII方式
- オブジェクトポイント
- ソフトウェア開発の労力見積もり
- ソフトウェアのサイズ設定
- ソースコード行
- ユースケースのポイント
- シンプルファンクションポイント方式
参考文献
- ^ Thomas Cutting、「プロジェクト管理における見積もりの教訓 - 従来型」、2010 年 5 月 28 日取得
- ^ ISO/IEC JTC 1/SC 7 ソフトウェアおよびシステムエンジニアリング (2007-02-01). 「ISO/IEC 14143」. 国際標準化機構. 2019年2月26日閲覧。
{{cite web}}: CS1 maint: 数値名: 著者リスト (リンク) - ^ OMG/CISQ 仕様「自動機能ポイント」、2013 年 2 月、OMG 文書番号 ptc/2013-02-01 http://www.omg.org/spec/AFP/1.0
- ^ AJ Albrecht、「アプリケーション開発の生産性の測定」、Share、GUIDE、IBM 合同アプリケーション開発シンポジウム議事録、カリフォルニア州モントレー、10 月 14 ~ 17 日、IBM Corporation (1979)、83 ~ 92 ページ。
- ^ エンジニアリング機能ポイントと追跡システム、ソフトウェア技術サポートセンター、Wayback Machineで 2010-11-11 にアーカイブ、2008 年 5 月 14 日に取得
- ^ リマ、オシアス・デ・ソウザ;ファリアス、ペドロ・ポルフィリオ・ムニス。ベルキオール、アルナルド ディアス (2003-06-01)。 「ファンクションポイント分析のためのファジーモデリング」。ソフトウェア品質ジャーナル。11 (2): 149–166。土井:10.1023/A:1023716628585。ISSN 1573-1367。S2CID 19655881。
- ^ Jones, C. および Bonsignour O. ソフトウェア品質の経済学、Addison-Wesley、2012 年、pp. 105-109。
- ^ Jones, C. 応用ソフトウェア測定: 生産性と品質の保証。McGraw-Hill。1996 年 6 月。
- ^ Albrecht, A. ソフトウェア機能、ソースコード行数、開発工数の見積もり - ソフトウェアサイエンスの検証。1983 年。
- ^ Symons, CR「ファンクションポイント分析: 問題点と改善点」IEEE Transactions on Software Engineering、1988 年 1 月、pp. 2-111。
- ^ Hemmstra, F. および Kusters R. 「機能ポイント分析: ソフトウェア コスト見積モデルの評価」。European Journal of Information Systems。1991 年。第 1 巻、第 4 号。229-237 ページ。
- ^ Jeffery, R および Stathis, J. 「仕様ベースのソフトウェア サイジング: 機能メトリックの実証的調査」 第 18 回ソフトウェア エンジニアリング ワークショップの議事録。1993 年。p 97-115。
- ^ Symons, C. ソフトウェアのサイジングと見積もり: Mk II FPA (Function Point Analysis)。John Wiley & Sons, Inc. ニューヨーク、1991
- ^ Demarco, T. 「ソフトウェア製品のサイズ設定アルゴリズム」 ACM Sigmetrics パフォーマンス評価レビュー。 1984 年。第 12 巻、第 2 号。pp 13-22。
- ^ Jeffrey, DR, Low, GC および Barnes, M. 「ファンクション ポイント カウント手法の比較」IEEE Transactions on Software Engineering。1993 年。第 19 巻、第 5 号。pp 529-532。
- ^ Schwartz, Adam. 「テストケースを使用したシステムのサイズ設定: ケーススタディ」 2012 年第 9 回国際情報技術会議 - 新世代。2012 年 4 月。pp 242-246。
外部リンク
- 国際ファンクションポイントユーザーグループ (IFPUG)
