ソフトウェアのサイズ設定

ソフトウェアのサイズ設定またはソフトウェアのサイズ見積りは、ソフトウェア エンジニアリングにおけるアクティビティであり、ソフトウェア アプリケーションまたはコンポーネントのサイズを決定または見積り、他のソフトウェア プロジェクト管理アクティビティ (見積りや追跡など)を実装できるようにするために使用されます。重量が有形材料の固有の特性であるのと同様に、サイズはソフトウェアの固有の特性です。

ソフトウェアのサイズ設定は、ソフトウェアの労力見積もりとは異なります。サイズ設定ではソフトウェアの予想サイズを見積もりますが、労力見積もりではソフトウェアの構築に必要な労力を予測します。ソフトウェアのサイズとソフトウェアの作成に必要な労力の関係は、生産性と呼ばれます。

たとえば、ソフトウェア エンジニアが Web ベースの小規模な計算機アプリケーションを構築した場合、プロジェクトの労力は 280 工数であったと言えます。ただし、これだけではソフトウェア製品自体のサイズに関する情報は得られません。逆に、アプリケーションのサイズが 5,000 LOC (コード行数) または 30 FP (機能ポイント) であると言っても、それを作成するために必要なプロジェクトの労力はわかりません。

歴史的に、最も一般的なソフトウェア サイジング方法は、アプリケーション ソースに記述されたコード行数を数えることでした。もう 1 つのアプローチは、機能サイズ測定を行うことです。これは、機能ポイント分析を実行して機能サイズを数値で表す方法です。元のサイジング方法は IFPUG です。IFPUG FPA 機能サイジング方法 (FSM) は、複雑なアルゴリズムを見積もる際の精度が低く、コード行数を見積もるよりも比較的使いにくいにもかかわらず、効果的に使用されてきました。元の機能サイズ測定方法論を適応させたものが登場しており、これらの標準は、COSMIC 機能ポイント、Mk II機能ポイント、Nesma 機能ポイント、および FiSMA 機能ポイントです。これらの標準の他のバリアントには、オブジェクト指向機能ポイント (OOFP) や、アルゴリズムと制御フローの複雑さを考慮した加重マイクロ機能ポイントなどの新しいバリアントがあります。

最適な機能サイジング方法は、アプリケーションの機能ドメイン、開発組織のプロセス成熟度、FSM方法の使用範囲など、さまざまな要因によって異なります。^{[1] [2]機能ポイントには、プロジェクトの生産性の測定や計画されたプロジェクトの見積もり以外にも、プロジェクトの進捗状況の監視や}商用オフザシェルフ（COTS）パッケージの要件カバレッジの評価など、 多​​くの用途と利点があります。 ^[3]

その他のソフトウェアのサイズ設定方法には、ソフトウェアに含まれるユースケースの数と特性をカウントするユースケースベースのソフトウェアのサイズ設定や、 「プロセス制御」や「リアルタイム」システムなど、保存されるデータの量が非常に限られているソフトウェアのサイズ設定に対応する COSMIC 機能サイズ測定などがあります。

IFPUGメソッドとCOSMICメソッドはどちらもISO/IEC 標準です。

ソフトウェアまたはコンポーネントの非機能的側面のサイズを決定する IFPUG 方式はSNAP と呼ばれ、非機能的サイズはSNAP ポイントで測定されます。SNAP モデルは、非機能要件を測定するための 4 つのカテゴリと 14 のサブカテゴリで構成されています。非機能要件は、関連するサブカテゴリにマッピングされます。各サブカテゴリのサイズが決定され、要件のサイズはそのサブカテゴリのサイズの合計になります。SNAP のサイズ決定プロセスは、機能ポイントのサイズ決定プロセスと非常によく似ています。アプリケーション境界内で、非機能要件は、関連するカテゴリとそのサブカテゴリに関連付けられます。標準化された一連の基本基準を使用して、各サブカテゴリはそのタイプと複雑さに応じてサイズが決定されます。このような要件のサイズは、そのサブカテゴリのサイズの合計です。これらのサイズを合計して、ソフトウェア アプリケーションの非機能的サイズの測定値を算出します。

いくつかのソフトウェア品質標準では、組織の標準ソフトウェア エンジニアリング ライフ サイクルの一部として、有効なサイジング方法を使用することを義務付けています。たとえば、能力成熟度モデル統合( CMMI ) では、このような要件が課せられます。ソフトウェア サイジングが適切に使用されない限り、組織は CMMI レベル 2 またはレベル 3 として評価 (認定) されません。

• SEER-SEM
• PRICEシステム
• 開発見積ソフトウェアの比較