Software-quality-management-albrechts-function-point-method

提供:Dev Guides
移動先:案内検索

アルブレヒトの関数点法

ファンクションポイントメトリックは、ソフトウェアアプリケーションのさまざまな機能を測定するための標準化された方法を提供します。 これは、ユーザーの観点から機能を測定します。つまり、ユーザーがリクエストして受け取ったものに基づいて機能を測定します。 ファンクションポイント分析は、ユーザーの観点からソフトウェア開発を測定するための標準的な方法です。

当初Albrechtによって考案されたFunction Pointメジャーは、1986年にInternational Function Point Users Group(IFPUG)が発足して人気が高まりました。 2002年、IFPUG機能ポイントは、ISO/IEC 20926の国際ISO標準になりました。

ファンクションポイントとは何ですか?

  • FP(ファンクションポイント)*は、ソフトウェアアプリケーションの定量化に適した最も一般的な機能タイプメトリックです。 これは、2つのデータ関数タイプと3つのトランザクション関数タイプに分けられる、5人のユーザーが識別可能な論理的な「関数」に基づいています。 特定のソフトウェアアプリケーションについて、これらの各要素は定量化および重み付けされ、ファイル参照や論理フィールドなどの特徴的な要素がカウントされます。

結果の数値(未調整FP)は、追加、変更、または削除された関数セットにグループ化され、値調整係数(VAF)と組み合わされて、FPの最終的な数が取得されます。 カウントタイプごとに、アプリケーション、開発プロジェクト、または拡張プロジェクトの個別の最終式が使用されます。

アルブレヒトの関数点法の適用

アルブレヒトの関数点法を適用する方法を理解しましょう。 その手順は次のとおりです-

コンポーネント(EI、EO、EQ、ILF、およびELF)の数を決定する

  • EI -外部入力の数。 これらは、派生データが外部から内部に境界を通過する基本プロセスです。 ライブラリデータベースシステムの例では、既存の利用者のライブラリカード番号を入力します。
  • EO -外部出力の数。 これらは、派生データが境界を内側から外側へ通過する基本プロセスです。 ライブラリデータベースシステムの例では、利用者にチェックアウトされた書籍のリストを表示します。
  • EQ -外部クエリの数。 これらは、1つ以上の内部論理ファイルと外部インターフェイスファイルからデータを取得する入力コンポーネントと出力コンポーネントの両方を備えた基本プロセスです。 ライブラリデータベースシステムの例では、現在どの本が利用者にチェックアウトされているかを判断します。
  • ILF -内部ログファイルの数。 これらは、外部入力によって維持されるアプリケーション境界内に完全に存在する、論理的に関連するデータのユーザー識別可能なグループです。 ライブラリデータベースシステムの例では、ライブラリ内の書籍のファイル。
  • ELF -外部ログファイルの数。 これらは、参照目的でのみ使用され、完全にシステムの外部に存在する、論理的に関連するデータのユーザー識別可能なグループです。 ライブラリデータベースシステムの例で、ライブラリの請求システムのトランザクションを含むファイル。

未調整の関数ポイントカウント(UFC)を計算する

  • 各コンポーネントを* low、average、または *high として評価します。
  • トランザクション*(EI、EO、およびEQ)の場合、評価は *FTR および DET に基づきます。
  • FTR -更新または参照されたファイルの数。
  • DET -ユーザーが認識可能なフィールドの数。
  • 次の表に基づいて、2つのファイルと10個のデータ要素を参照する EI は、*平均*としてランク付けされます。

FTRs

DETs

*1-5*
*6-15*
  • > 15 *
*0-1*

Low

Low

平均

*2-3*

Low

平均

High

>3

平均

High

High

  • ファイル*(ILFおよびELF)の場合、評価は *RET および DET に基づきます。
  • RET - ILF または ELF 内のユーザーが認識可能なデータ要素の数。
  • DET -ユーザーが認識可能なフィールドの数。
  • 次の表に基づいて、10個のデータ要素と5個のフィールドを含む ILF は、 high としてランク付けされます。

RETs

DETs

*1-5*
*6-15*
  • > 15 *

1

Low

Low

平均

*2-5*

Low

平均

High

>5

平均

High

High

  • 評価を UFC に変換します。

評価

EO

EQ

EI

*ILF*

エルフ

4

3

3

7

5

平均

5

4

4

10

7

高い

6

5

6

15

10

最終関数ポイントカウント(FPC)を計算する

  • 14の一般的なシステム特性*(GSC)に基づいて、値調整係数(VAF)*を計算します。

一般的なシステム特性

簡単な説明

GSC 1

データ通信

アプリケーションまたはシステムとの情報の転送または交換を支援するために、いくつの通信施設がありますか?

GSC 2

分散データ処理

分散データと処理機能はどのように処理されますか?

GSC 3

パフォーマンス

ユーザーは応答時間またはスループットを必要としましたか?

GSC 4

頻繁に使用される構成

アプリケーションが実行される現在のハードウェアプラットフォームはどの程度使用されていますか?

GSC 5

取引レート

トランザクションは毎日、毎週、毎月などの頻度で実行されますか?

GSC 6

オンラインデータ入力

オンラインで入力される情報の割合は?

GSC 7

エンドユーザーの効率

アプリケーションはエンドユーザーの効率のために設計されましたか?

GSC 8

オンライン更新

オンライントランザクションによっていくつのILFが更新されますか?

GSC 9

複雑な処理

アプリケーションには、広範な論理的または数学的な処理がありますか?

GSC 10

再利用性

アプリケーションは、1つまたは複数のユーザーのニーズを満たすように開発されましたか?

GSC 11

インストールが簡単

変換とインストールはどのくらい難しいですか?

GSC 12

操作性

起動、バックアップ、および回復の手順は、どの程度効果的および/または自動化されていますか?

GSC 13

複数のサイト

アプリケーションは、複数の組織の複数のサイトにインストールされるように特別に設計、開発、およびサポートされていましたか?

GSC 14

変更を促進する

アプリケーションは、変更を容易にするために特別に設計、開発、およびサポートされていましたか?

  • 強い影響に影響がないかどうかに基づいて、0〜5のスケールで各 GSC を計量します。
  • 次のように FPC を計算します- + FPC = UFC* (0.65+(sum( GSC )* .01))

複雑

複雑さは、サイズの独立したコンポーネントです。 それは2つのタイプです-

  • 問題の複雑さ-問題の最適な解決に必要なリソースの量です。
  • ソリューションの複雑さ-特定のソリューションを実装するために必要なリソースです。 これには2つの側面があります。 彼らは次のとおりです-
  • 時間の複雑さ-リソースはコンピューター時間です。
  • スペースの複雑さ-リソースはコンピューターのメモリです。

複雑さの測定

複雑さの1つの側面は効率です。 アルゴリズムとしてモデル化できるソフトウェア製品を測定します。

例:特定の問題のすべてのインスタンスを解決するアルゴリズムが* f(n)の計算を必要とする場合、問題を解決する複雑さgを持つ他のすべてのアルゴリズムが *f である場合、* f(n)は漸近的に最適です。 * O(g)。 その場合、与えられた問題の複雑さは大きくなります-問題の解決のための漸近的に最適なアルゴリズムの O