アーティファクト(ソフトウェア開発)

ウィキペディアから、無料の百科事典
ナビゲーションにジャンプ 検索にジャンプ

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

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

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

アーティファクトと見なされるものの多くは、ソフトウェアのドキュメントです。

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

アーティファクトは保守性が異なります。保守性は、主にアーティファクトが果たす役割によって影響を受けます。役割は、実用的または象徴的のいずれかです。ソフトウェア開発の初期段階では、アーティファクトが設計チームによって作成され、プロジェクトスポンサーに、請負業者がプロジェクトのニーズを満たすことにどれほど真剣に取り組んでいるかを示す象徴的な役割を果たします。象徴的なアーティファクトは情報をうまく伝えないことがよくありますが、見た目は印象的です。シンボリックは理解を深めます。一般的に言って、照らされた巻物はまた、象徴的な品質を維持するために必要な勤勉さのために維持不可能であると考えられています。このため、イルミネーションスクロールがプロジェクトのスポンサーに提示されて承認されると、実用的な役割を果たすアーティファクトに置き換えられます。

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

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

アーティファクトを収集、整理、および管理するために、ソフトウェア開発フォルダーを利用できます。

// POST:api / Todo
[HttpPost]
public async Task <ActionResult <TodoItem >> PostTodoItem(TodoItem item)
{{
    _context.TodoItems.Add(item);
    await _context.SaveChangesAsync();
 
    CreatedAtAction(nameof(GetTodoItem)、new {id = item.Id}、item);を返します。
}

も参照してください

参照

  1. ^ H.リーバーマン、BAナルディ、D。ライト。Grammex:例による文法の定義。コンピューティングシステムにおけるヒューマンファクターに関するACM会議(要約、デモンストレーション、CHI 1998)、米国カリフォルニア州ロサンゼルス、11〜12ページ。ACM Press、1998年4月。

さらに読む

  • Kroll&Philippe Kruchten(2003)による。Rational Unified Processを簡単に:RUPの実践者向けガイド