IPA午前Ⅱ ソフトウェア開発の見積もり手法 解説

Tech

本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。

IPA午前Ⅱ ソフトウェア開発の見積もり手法 解説

ソフトウェア開発における工数や期間の見積もりでは、定量的手法の適用とそれらの基本的な計算原理の理解が重要である。

背景

ソフトウェア開発プロジェクトの計画において、工数、期間、費用を正確に見積もることは成功に不可欠である。見積もりは、プロジェクトの予算編成、資源配分、スケジュール策定の基礎となり、不正確な見積もりはプロジェクトの遅延やコスト超過、品質低下を引き起こす可能性がある。そのため、経験に基づく直感的な見積もりだけでなく、定量的手法を用いた客観的な見積もりの導入が求められる。

問題点

IPA午前Ⅱ試験では、ソフトウェア開発の見積もりに関する主要な手法、特にファンクションポイント（FP）法やCOCOMO（Constructive Cost Model）について、その基本原理、計算ステップ、適用条件が問われる傾向にある。これらの問題では、与えられたプロジェクトの特性や機能要件から、見積もり指標（例：FP値、工数）を正確に算出する能力が試される。単に公式を覚えるだけでなく、各手法が何を測定し、どのように適用されるかを理解することが重要となる。

計算/手順

ソフトウェア開発の見積もり手法は多岐にわたるが、代表的なものとしてファンクションポイント（FP）法とCOCOMOが挙げられる。

1. ファンクションポイント（FP）法

FP法は、ユーザーに提供される機能の量（機能的規模）に基づいてソフトウェアの規模を見積もる手法である。要件定義段階で適用しやすく、特定のプログラミング言語に依存しない特徴がある。

手順

  1. データ機能とトランザクション機能の識別と複雑度評価

    • データ機能: ユーザーが認識できる論理ファイルの数。

      • 内部論理ファイル（ILF: Internal Logical File）: アプリケーション内部で保守されるデータグループ。

      • 外部インタフェースファイル（EIF: External Interface File）: 別のアプリケーションによって保守されるが、現在のアプリケーションによって参照されるデータグループ。

    • トランザクション機能: ユーザーが認識できるプロセス。

      • 外部入力（EI: External Input）: アプリケーションの内部論理ファイルを更新するデータ入力。

      • 外部出力（EO: External Output）: 処理されたデータをユーザーに提供する出力。

      • 外部照会（EQ: External Inquiry）: 内部論理ファイルからデータを取得し、ユーザーに提供するが、データを更新しない出力。

    • 識別された各機能に対して、そのデータ要素数や参照ファイル数に基づいて「単純」「平均」「複雑」のいずれかの複雑度を割り当て、それぞれに対応するポイントを積算する。

  2. 未調整ファンクションポイント（UFP: Unadjusted Function Point）の算出

    • 各機能のポイントを合計する。

    • UFP = Σ (データ機能ポイント) + Σ (トランザクション機能ポイント)

  3. 汎用システム特性（VAF: Value Adjustment Factor）の適用

    • 信頼性、性能、移植性など14項目からなる汎用システム特性（GSC: General System Characteristics）を評価し、各項目を0（影響なし）から5（強い影響）で採点する。

    • GSCの合計点（DI: Degree of Influence）を算出する。

    • VAF = (DI * 0.01) + 0.65 （IFPUGの場合）

  4. 調整済みファンクションポイント（AFP: Adjusted Function Point）の算出

    • AFP = UFP * VAF

  5. 工数の見積もり

    • AFPに過去の実績に基づく生産性係数（例：人月/FP）を乗じて工数を見積もる。

    • 工数 (人月) = AFP * 生産性係数

2. COCOMO (Constructive Cost Model)

COCOMOは、ソフトウェアの規模（主としてLOC: Lines Of Code、またはKLOC: Kilo Lines Of Code）と、プロジェクトの属性（コストドライバ）に基づいて工数を見積もる経験的モデルである。

計算式

COCOMOには、基本COCOMO、中間COCOMO、詳細COCOMOがある。IPA午前Ⅱでは主に基本COCOMOや中間COCOMOが問われる。

  • 基本COCOMO:

    • 工数 (人月) = a * (KLOC)^b

    • 期間 (月) = c * (工数)^d

    • 係数 a, b, c, d は開発モード（オーガニック、セミデタッチト、エンベデッド）によって異なる。

      • オーガニックモード: 比較的小規模で、経験豊富な開発者が集まった安定した環境。

      • セミデタッチトモード: 中規模で、ある程度の経験者がいる環境。

      • エンベデッドモード: 大規模で、複雑なシステムや厳格な制約がある環境。

  • 中間COCOMO: 基本COCOMOに加えて、システムの信頼性、データベース規模、製品の複雑度、開発者の能力、経験、開発ツールの利用度など、15種類の「コストドライバ」を評価し、工数調整係数（EAF: Effort Adjustment Factor）を算出する。

    • 工数 (人月) = a * (KLOC)^b * EAF

    • EAFは、各コストドライバの評価値（例：非常に低い、低い、普通、高い、非常に高い）に対応する係数を全て乗算した値である。

graph TD
    A["ソフトウェア開発見積もりプロセス"] --> B{"対象プロジェクトの特性分析"};
    B --> C{"見積もり手法の選択"};
    C --> D1["ファンクションポイント法 (FP法)"];
    C --> D2["COCOMO(\"構成型コストモデル\")"];

    D1 --> E1["機能数と複雑度評価"];
    E1 --> F1["未調整FP (UFP) 算出"];
    F1 --> G1["汎用システム特性評価 (VAF)"];
    G1 --> H1["調整済みFP (AFP) 算出"];

    D2 --> E2["規模 (KLOC) 決定"];
    E2 --> F2["開発モード選択 (オーガニック等)"];
    F2 --> G2["コストドライバ評価 (EAF) -- 中間COCOMOの場合"];
    G2 --> H2["工数算出"];

    H1 --> I["最終的な工数・期間見積もり"];
    H2 --> I;
    I --> J["見積もり結果のレビューと調整"];
    J --> K["プロジェクト計画への反映"];

図：ソフトウェア開発の見積もりプロセスの概要

要点

  • FP法: ユーザー視点での機能的規模に基づき、要件定義段階で適用しやすい。言語非依存。調整済みファンクションポイント（AFP）を算出する。

  • COCOMO: コード行数（KLOC）を主要な入力とし、プロジェクトの属性（コストドライバ）を考慮して工数を見積もる。

  • 両手法とも、過去の実績データや組織固有の生産性係数、コストドライバの評価が正確な見積もりの鍵となる。

  • 見積もりはプロジェクトのライフサイクルを通じて反復的に行い、情報が増えるにつれて精度を高めることが推奨される。

参考文献

  • [1] 経済産業省, “ソフトウェア開発見積もりガイドライン V2.0”, 2009年4月1日, https://www.meti.go.jp/policy/it_policy/eng/e_spt.htm

  • [2] IPA, “共通フレーム2017 (SLCP-JCF2017)”, 2017年9月11日, https://www.ipa.go.jp/archive/osc/common-frame/

  • [3] Boehm, B. W., “Software Engineering Economics”, Prentice-Hall, 1981.

  • [4] International Function Point Users Group (IFPUG), “Measurement Practices Manual”, 最新版のIFPUGガイドラインを参照. (参照日: 2024年7月26日)

ライセンス：本記事のテキスト/コードは特記なき限り CC BY 4.0 です。引用の際は出典URL（本ページ）を明記してください。
利用ポリシー もご参照ください。

コメント

タイトルとURLをコピーしました