Software Size Estimation by Integrating Functional Size and Functional Complexity Measures
本研究は、回帰分析を用いて機能サイズ尺度（UFPおよびCFP）と機能複雑度尺度（CCおよびYC）を統合したソフトウェア規模推定モデルを提案しており、これらの指標を組み合わせること、特にUFPと複雑度尺度を組み合わせることが、COCOMO IIのようなアプリケーションにおける推定誤差を大幅に減少させ、予測精度を向上させることを実証している。
原論文は CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/) でライセンスされています。 これは以下の論文のAI生成解説です。著者が執筆または承認したものではありません。技術的な正確性については原論文を参照してください。 免責事項の全文を読む
ソフトウェアの構築は、レンガやモルタルの代わりにコードの行数や機能要件を材料として用いるという点では、建物を建てることによく似た複雑な試みです。何十年もの間、プロジェクトマネージャーは、プロジェクトにどれほどの時間と費用がかかるかを推定するために、これらのコードの行数を数えることに頼ってきました。しかし、この手法には欠陥があります。なぜなら、プログラマーの書き方次第で、全く同じことを行うプログラムであっても、必要なコードの量は劇的に変わる可能性があるからです。これを解決するために、業界は、どのように書かれているかではなく、ユーザーのために実際に「何をするか」——つまり、入力、出力、データファイルを数えること——によってソフトウェアを測定する方法を開発しました。これは「機能サイズ」として知られています。しかし、この機能的なカウントでさえも、盲点があります。それは、機能の「量」を測定する一方で、それらを構築する「難易度」を見落としがちであるということです。単純な機能は容易に構築できるかもしれませんが、分岐や条件が多い複雑な機能は、たとえ伝統的な意味での一つの「機能」としてカウントされたとしても、コーディングにおける悪夢となり得るのです。
この機能のサイズと、それを構築する複雑さの間のギャップこそが、インドネシアの研究チームが取り組んだ中心的な謎です。彼らは、機能サイズによる測定と構造的複雑さによる測定を組み合わせることで、ソフトウェアプロジェクトの真の規模をより正確に予測できるかどうかを検証することに乗り出しました。彼らの研究は、ソフトウェア構築に必要な工数を精緻化することに焦点を当てています。これは、プロジェクトが予算内に収まるか、あるいは制御不能に陥るかを決定する極めて重要な課題です。彼らは、「何を作るか」と「それがどれほど難しいか」の両面を見ることで、デジタルシステムを計画する人々にとって、より明確な全体像を描き出すことを目指しました。
研究者たちはまず、従業員協同組合向けに設計されたものと小売店向けのものという、2つの実世界のソフトウェアプロジェクトからデータを収集しました。公開データセットは、分析に必要な詳細な情報が不足していることが多いため、彼らはそれらを使用しませんでした。代わりに、彼らはこれらのアプリケーションのテキスト形式の要件を取り、BPMN図と呼ばれる視覚的なフローチャートへと変換しました。これらの図は架け橋となり、チームがシステムのあらゆる部分に対して2種類の異なる測定値を抽出することを可能にしました。まず、彼らは機能サイズを算出しました。これは、ユーザーのインタラクションやデータファイルの数を数えるものです。彼らはこれに、標準的なカテゴリー（入力や出力など）に基づく未調整ファンクションポイントを数える方法と、データの出入りを追跡するCOSMICファンクションポイントを数える方法という、2つの確立された手法を用いました。
次に、それらと同じ部分の構造的複雑さを測定しました。これには、フローチャート内のロジックを分析し、意思決定ポイント、ループ、および分岐パスがいくつ存在するかを確認する作業が含まれます。彼らは2つの異なる複雑性指標を用いました。一つはコード内の独立したパスの数を数えるものであり、もう一つは、さまざまな種類の分岐やループの認知的困難さを重み付けするものでした。最後に、これらの組み合わせた測定値を、実際に書かれたコードの行数と比較しました。この最終的なカウントが、研究者が予測しようとしていた完成したソフトウェアの実際のサイズ、すなわち「正解（グラウンド・トゥルース）」となりました。
結果は、使用された機能サイズのメソッドに応じて明確なパターンを示しました。研究者が最初の機能サイズ手法を用いた場合、複雑さの測定値を加えることで、予測の精度が大幅に向上しました。具体的には、推定の誤差率が24%から22%へと低下しました。これは、このタイプの機能カウントにおいては、ロジックの複雑さを知ることが推定を現実に近づけ、精度を補正するのに役立つことを示唆しています。しかし、物語は2番目の機能サイズ手法では異なりました。COSMICファンクションポイントを用いた場合、複雑さの測定値を加えても誤差率は下がらず、15%のまま一定でした。このケースでは、機能サイズの測定値自体がすでに非常に精密であったため、追加の複雑さのデータが最終的な数値をより正確にすることはありませんでした。
誤差率の改善は見られなかったものの、複雑さのデータは依然として価値があることが証明されました。研究者がCOSMICファンクションポイントに複雑さの指標を加えたとき、予測の「質」が異なる形で向上しました。誤差範囲が非常に狭い範囲内に収まる推定値の割合が、76%から80%へと増加したのです。これは、平均的な誤差は変わらないものの、チームが正解に非常に近い値を得ることにおいて、より信頼性が高まったことを意味します。本研究の結論は、複雑さの指標を統合することは「万能薬」ではないということです。その価値は、使用される機能サイズのメソッドに依存します。一方の手法では精度を研ぎ澄ませ、もう一方の手法では一貫性を研ぎ澄ませます。これらの知見は、確立された工数見積もりモデルに投入するデータに対して、より微細な（ニュアanced）アプローチを提供し、ソフトウェアチームがプロジェクトに真に必要とされる時間やリソースについて、より情報に基づいた意思決定を行えるよう支援するものです。
自分の分野の論文に埋もれていませんか？
研究キーワードに一致する最新の論文のダイジェストを毎日受け取りましょう——技術要約付き、あなたの言語で。