探索型ソフトウェアエンジニアリング

探索ベースのソフトウェアエンジニアリング( SBSE ) は、遺伝的アルゴリズム、シミュレーテッドアニーリング、タブーサーチなどのメタヒューリスティック探索技術をソフトウェアエンジニアリングの問題に適用します。ソフトウェアエンジニアリングの多くの活動は、最適化問題として定式化できます。線形計画法や動的計画法などのオペレーションズリサーチの最適化技術は、計算の複雑さや問題構造に関する仮定のために、大規模なソフトウェアエンジニアリングの問題には実用的ではないことがよくあります。研究者や実務家は、問題構造に関する仮定をほとんど課さないメタヒューリスティック探索技術を使用して、ほぼ最適または「十分良い」解を見つけます。^{[ 1 ]}

SBSEの問題は、以下の2種類に分類できます。

• 例えば、人員をタスクに割り当てること（典型的な組み合わせ最適化問題）など、ブラックボックス型の最適化問題。
• ソースコードに対する操作を考慮する必要があるホワイトボックス問題。^{[ 2 ]}

SBSE は、ソフトウェア エンジニアリングの問題をメタヒューリスティックで解決できる計算探索問題に変換します。これには、探索空間、つまり可能な解の集合を定義することが含まれます。この空間は通常、網羅的に探索するには大きすぎるため、メタヒューリスティックアプローチが提案されます。次に、メトリック^{[ 3 ]} (適合度関数、コスト関数、目的関数、または品質尺度とも呼ばれます) を使用して、潜在的な解の品質を測定します。多くのソフトウェア エンジニアリングの問題は、計算探索問題として再定式化できます。^{[ 4 ]}

一方、 「検索ベースアプリケーション」という用語は、別の産業用途において、検索技術ではなく検索エンジン技術を使用することを指します。

ソフトウェアエンジニアリングの問題に最適化を適用した初期の試みの1つは、 1976年にWebb MillerとDavid Spoonerによってソフトウェアテストの分野で報告されました。^{[ 5 ]} 1992年に、S. Xanthakisとその同僚は、ソフトウェアエンジニアリングの問題に初めて探索手法を適用しました。 ^{[ 6 ]} SBSEという用語は、2001年にHarmanとJonesによって初めて使用されました。^{[ 7 ]}研究コミュニティは、2013年までに40か国の約270の機関にまたがる800人以上の著者を含むまでに成長しました。^{[ 8 ]}

探索ベースのソフトウェアエンジニアリングは、ソフトウェア開発プロセスのほぼすべてのフェーズに適用可能です。ソフトウェアテストは、主要なアプリケーションの 1 つです。^{[ 9 ]}探索技術は、要件分析[ ^{10 ] [ 11 ] 、}設計^{[ 12 ] [ 13 ]}、リファクタリング^{[ 14} ] 、開発[ ^{15 ]}、保守^{[ 16 ]}などの他のソフトウェアエンジニアリング活動^にも^適用されています。

SBSE に利用できるツールには、OpenPAT ^{[ 30 ]} 、EvoSuite ^{[ 31 ]}、Python のコード カバレッジ測定ツールであるCoverage ^{[ 32 ]などがあります。}

以下のような様々な方法や技術が利用可能です。

• プログラムの実行中に特定の部分を監視するために、計測器を使用してプロファイリング^{[ 33 ]を行います。}
• プログラムに関連付けられた抽象構文木を取得し、それを自動的に解析することで、その構造に関する知見を得ることができる。
• SBSEに関連するプログラムスライシングの応用例としては、ソフトウェア保守、最適化、プログラム分析などが挙げられる。
• コードカバレッジとは、与えられた入力データセットに対して、コードのうちどれだけが実行されるかを測定する指標です。
• 静的プログラム解析

SBSEは比較的新しい研究分野であるため、まだ業界で広く受け入れられているとは言えない。

業界でSBSEが成功している事例は、主にソフトウェアテストの分野で見られます。大規模なバグ発見のためにランダムなテスト入力を自動的に生成できる機能は、企業にとって魅力的です。2017年、Facebookは検索ベースのバグ発見アプリであるSapienzを開発したソフトウェアスタートアップのMajicke Limitedを買収しました。^{[ 34 ]}

他のアプリケーションシナリオでは、ソフトウェアエンジニアは、制御がほとんどできないツールや、人間が作成するものとは異なるソリューションを生成するツールを採用することに抵抗を感じる場合があります。^{[ 35 ]}プログラムの修正や改善にSBSEを使用する場合、開発者は、自動的に生成された変更がシステムの要件やテスト環境の範囲外で予期しない動作を生成しないことを確信する必要があります。完全な自動化プログラミングはまだ実現されていないことを考慮すると、そのような変更の望ましい特性は、保守活動をサポートするために人間が容易に理解できる必要があることです。^{[ 36 ]}

もう一つの懸念は、SBSEによってソフトウェアエンジニアが不要になる可能性があるという点です。支持者たちは、SBSEの動機はエンジニアとプログラムの関係を強化することにあると主張しています。^{[ 37 ]}

• プログラム解析（コンピュータサイエンス）
• 動的プログラム解析
• 遺伝的改良

• SBSEに関する出版物のリポジトリ（2012年5月2日時点のWayback Machineアーカイブ）
• メタヒューリスティクスとソフトウェアエンジニアリング（ 2011年9月23日、 Wayback Machineにアーカイブ済み）
• ソフトウェア成果物インフラストラクチャリポジトリ
• ソフトウェア工学に関する国際会議
• 遺伝的アルゴリズムと進化的計算（GECCO）
• Google Scholar の検索ベースソフトウェアエンジニアリングに関するページ