Artifact_(software_development)
「アーティファクト」ソフトウェア開発
アーティファクトは、ソフトウェアの開発中に製造有形副産物の多くの種類の一つです。一部のアーティファクト（ユースケース、クラス図、その他の統一モデリング言語（UML）モデル、要件、および設計ドキュメントなど）は、ソフトウェアの機能、アーキテクチャ、および設計を説明するのに役立ちます。その他の成果物は、プロジェクト計画、ビジネスケース、リスク評価など、開発自体のプロセスに関係しています。
用語のアーティファクトソフトウェア開発に関連しては、主に特定の開発手法やプロセスなど、関連付けられている統一プロセス。この用語の使用法は、これらの方法に由来している可能性が
ビルドツールは、テスト計画を実行するために実行可能ファイルが必要であるため、テスト用にコンパイルされたソースコードをアーティファクトとして参照することがよくテストする実行可能ファイルがない場合、テスト計画アーティファクトは非実行ベースのテストに制限されます。非実行ベースのテストでは、アーティファクトはウォークスルー、検査、および正当性の証明です。一方、実行ベースのテストには、テストスイートと実行可能ファイルの少なくとも2つのアーティファクトが必要です。アーティファクトは、リリースされたコード（コードライブラリの場合）またはリリースされた実行可能ファイル（プログラムの場合）を参照する場合がありますが、より一般的には、アーティファクトは製品自体ではなくソフトウェア開発の副産物です。オープンソースコードライブラリには、多くの場合、コントリビューターが変更によってコードライブラリにリグレッションバグが発生しないことを確認できるテストハーネスが含まれています。
アーティファクトと見なされるものの多くは、ソフトウェアのドキュメントです。
では、エンドユーザーの開発成果物は、アプリケーションや、一般的なプログラミング言語を知らなくても、エンドユーザーによって作成された複雑なデータオブジェクトのいずれかです。アーティファクトは、データベース要求や文法規則、またはユーザー生成コンテンツなどの自動化された動作または制御シーケンスを記述します。
アーティファクトは保守性が異なります。保守性は、主にアーティファクトが果たす役割によって影響を受けます。役割は、実用的または象徴的のいずれかです。ソフトウェア開発の初期段階では、設計チームがアーティファクトを作成して、プロジェクトスポンサーに、請負業者がプロジェクトのニーズを満たすことにどれほど真剣に取り組んでいるかを示す象徴的な役割を果たします。象徴的なアーティファクトは情報をうまく伝えないことがよくありますが、見た目は印象的です。象徴的な理解を深めます。一般的に言って、照らされた巻物はまた、象徴的な品質を維持するために必要な勤勉さのために維持不可能であると考えられています。このため、イルミネーションスクロールがプロジェクトのスポンサーに提示されて承認されると、実用的な役割を果たすアーティファクトに置き換えられます。実用的なアーティファクトは通常、プロジェクトのライフサイクル全体を通じて維持する必要があり、そのため、一般的に高度に維持可能です。
アーティファクトは、プロジェクト管理の観点から、成果物として重要です。ソフトウェアプロジェクトの成果物は、ソフトウェア自体が追加されたアーティファクトと同じになる可能性が
副産物としてのアーティファクトの意味は、科学におけるアーティファクトという用語の使用に似ており、問題自体ではなく、手元のプロセスから生じるもの、つまり、目的ではなく手段から生じる関心の結果を指します。
アーティファクトを収集、整理、および管理するために、ソフトウェア開発フォルダーを利用できます。
// POST：api / Todopublic async Task
も参照してください
アーティファクト（UML）
ソフトウェア開発フォルダ
参考文献
^ H.リーバーマン、BAナルディ、D。ライト。Grammex：例による文法の定義。コンピューティングシステムにおけるヒューマンファクターに関するACM会議（要約、デモンストレーション、CHI 1998）、米国カリフォルニア州ロサンゼルス、11〜12ページ。ACM Press、1998年4月。
参考文献
Kroll＆Philippe Kruchten（2003）による。Rational Unified Processを簡単に：RUPの実践者向けガイド。。