アーティファクト（ソフトウェア開発）

アーティファクトは、ソフトウェアの開発中に生成される多くの種類の具体的な副産物の 1 つです。一部のアーティファクト (ユース ケース、クラスダイアグラム、要件、設計ドキュメントなど) は、ソフトウェアの機能、アーキテクチャ、設計を説明するのに役立ちます。その他のアーティファクトは、プロジェクト計画、ビジネス ケース、リスク評価など、開発プロセス自体に関係しています。

ソフトウェア開発に関連するアーティファクトという用語は、主に、統合プロセスなどの特定の開発方法またはプロセスに関連付けられています。この用語の使用法は、これらの方法に由来している可能性があります。

ビルド ツールは、テスト用にコンパイルされたソース コードをアーティファクトと呼ぶことがよくあります。これは、テスト計画を実行するには実行ファイルが必要であるためです。テストする実行ファイルがないと、テスト計画のアーティファクトは非実行ベースのテストに限定されます。非実行ベースのテストでは、アーティファクトはウォークスルー、検査、および正確性証明です。一方、実行ベースのテストには、テスト スイートと実行ファイル の少なくとも 2 つのアーティファクトが必要です。アーティファクトは、リリースされたコード (コード ライブラリの場合) またはリリースされた実行ファイル (プログラムの場合) を指す場合もありますが、より一般的には、アーティファクトは製品そのものではなく、ソフトウェア開発の副産物です。オープン ソース コード ライブラリには、多くの場合、変更によってコード ライブラリに 回帰バグが発生しないことをコントリビューターが確認できるようにするためのテスト ハーネスが含まれています。

成果物とみなされるものの多くはソフトウェアのドキュメントです。

エンドユーザー開発において、アーティファクトとは、一般的なプログラミング言語を知らなくてもエンドユーザーが作成するアプリケーションまたは複雑なデータオブジェクトです。アーティファクトは、データベース要求や文法規則などの自動化された動作や制御シーケンス、^[1]、またはユーザー生成コンテンツを説明します。

成果物の保守性はさまざまです。保守性は主に、成果物が果たす役割によって左右されます。役割は、実用的な場合と象徴的な場合があります。ソフトウェア開発の初期段階では、設計チームによって成果物が作成されることがあります。成果物は、プロジェクト スポンサーに対して、請負業者がプロジェクトのニーズを満たすことにどれほど真剣に取り組んでいるかを示す象徴的な役割を果たします。象徴的な成果物は、多くの場合、情報をうまく伝えられませんが、見栄えがします。象徴的な成果物は理解を深めます。一般的に、イルミネーション スクロールは、象徴的な品質を維持するために必要な注意のため、保守不可能であると見なされます。このため、イルミネーション スクロールがプロジェクト スポンサーに示され、承認されると、実用的な役割を果たす成果物に置き換えられます。実用的な成果物は通常、プロジェクトのライフサイクル全体にわたって保守する必要があり、そのため、一般的に保守性が非常に高くなります。

成果物は、プロジェクト管理の観点からは成果物として重要です。ソフトウェア プロジェクトの成果物は、ソフトウェア自体を追加した成果物と同じになる可能性があります。

副産物としてのアーティファクトの意味は、科学において、問題そのものではなく、手元のプロセスから生じるもの、つまり、目的ではなく手段から生じる関心の結果を指す アーティファクトという用語の使用に似ています。

成果物を収集、整理、管理するには、ソフトウェア開発フォルダーを利用できます。

• アーティファクト (UML)

• Per Kroll、Philippe Kruchten (2003)。Rational Unified Process を簡単にする: RUP 実践ガイド。Addison -Wesley Professional。ISBN 978-0-321-16609-8。