更新 : 2007 年 11 月
この用語集では、Visual Studio Team System ヘルプで使用されている主要な用語を定義します。
バージョン [version]
以前の形式からの 1 つ以上の変更を反映する、ソース管理内の項目のステータス。バージョン番号が大きいほど、新しいバージョンになります。バージョン管理 [version control]
ベースラインの確立および保守を行い、ベースラインへの変更を特定して以前のベースラインに戻れるようにすること。パーティション [partition]
単体テストでコード カバレッジを広くするためにプロキシとして使用されるクラス。パートナー テスト [Partner Test]
マイクロソフトのパートナーにより記述され、テスト フレームワークの機能拡張インターフェイスを使用するテスト。排他経過時間 [elapsed exclusive time]
関数内での処理に要した時間から、関数内での項目の呼び出しにかかった時間を除外した時間。「包括経過時間」を参照してください。排他時間 [exclusive time]
この関数またはモジュール内で経過した時間の合計から、この関数から呼び出された関数またはモジュールの処理に要した時間を除外したもの。排他遷移 [exclusive transitions]
関数内でユーザー (リング 3) とカーネル モード (リング 0) の間にある遷移の数から、関数が呼び出した項目による遷移を除外したもの。配置後スクリプト [post-deployment script] [post-deployment scripts]
データベース配置スクリプトの実行後に特定の順序で実行されるユーザー定義のデータベース スクリプト。配置前スクリプト [pre-deployment script] [pre-deployment scripts]
データベース配置スクリプトの実行前に特定の順序で実行されるユーザー定義のデータベース スクリプト。バイナリのインストルメント [instrument a binary]
パフォーマンスのデータを収集するために、バイナリに診断プローブを挿入します。配布グループ [distribution group]
電子メールによる配布のみに使用される、ユーザー、コンピュータ、連絡先、および他のグループのコレクション。パイロット [pilot]
ソリューションを稼動環境に導入し、導入者、システム サポート スタッフ、およびエンド ユーザーによる評価を行うこと。パイロットの目的は、配置の影響を最小限に抑え、プロジェクトを完了できるかどうかに関する貴重なフィードバックを提供することです。バグ [bug]
製品の潜在的な不協和の要因を記録する作業項目の種類の 1 つ。コードの欠陥をトラックする作業項目の種類の共通名です。バグ収束 [bug convergence]
修正されるバグの割合が、発見されるバグの割合を越えた時点。バグ収束は、アクティブなバグのカウントに対して目に見える成果を上げていることの指標になります。プロジェクトの終了が見えてきたサインです。バグ割り当て [bug allotment]
バグの修正のために割り当てられた一定の開発時間。割り当てはイテレーション計画に残っている余裕期間の中から作成されます。バックログ [backlog]
現在考慮中、または未完の作業を表す、まだ閉じていない一連の作業項目。発生確率/影響度マトリックス [probability and impact matrix]
リスクの 2 つの次元、発生確率、および発生した場合の目標への影響を組み合わせることで、リスクのレベル (低、中、または高) を判断するための一般的な方法。パフォーマンス テスト [performance test]
パフォーマンスに対するサービス品質要求が満たされていることを確かめるテスト。パフォーマンス テストでは、機能が正しく動いていることだけでなく、機能が完了するまでに必要な時間もチェックします。反復開発 [iterative development]
基本的な機能の核となるセットのビルドとテスト、配置を最初に行い、以降のバージョンで機能を追加していくというソリューション開発方法。汎用テスト [generic test]
Visual Studio のテストの種類と呼ばれるものの 1 つで、不明なテストまたはツールをカプセル化して Visual Studio で既知のテストの種類として扱うことを可能にします。ビジョン ステートメント [vision statement]
プロジェクト ビジョンを概説し、価値命題、ステークホルダ、および推進力となる要素を説明した簡単なステートメント。必須フィールド [required fields]
規則のあるフィールド。実際には、作業項目の種類のデザイナによって、ある範囲の値を持つことが必須となるフィールドが識別されます。ヒット [hit]
テストで実行されたコード行。表形式データ ストリーム (TDS) [tabular data stream (TDS)]
Microsoft SQL Server を実行しているサーバーとクライアントとの間でデータを転送する際に使用する内部プロトコル。TDS を使用すると、クライアント製品とサーバー製品は、オペレーティング システム、サーバーのリリース、またはネットワーク トランスポートに関係なく通信できます。ビルド [build]
成果物 (ソフトウェア コンポーネント) の名前を付けられたセットで、通常、独立したソース バージョンのセットからコンパイルされます。ビルド エージェント [build agent]
Team Foundation ビルドがインストールされているコンピュータまたはサーバー。新しいビルド定義を作成する前に、コンピュータまたはサーバーをビルド エージェントとして指定する必要があります。Visual Studio Team System のユーザー インターフェイスを使用すると、新しいビルド エージェントを指定したり既存のビルド エージェントを管理したりできます。ビルド エラー [build error]
ビルド中断の原因となった懸案事項を通知するメッセージ。ビルド サイクル [build cycle]
内部リリース サイクルの 1 つ。機能の追加、各機能に対するテスト ケースの作成、新規の機能をビルドする前の各機能の安定化、および評価のためのリリースというプロセスから成ります。ビルド確認テスト (BVT) [build verification test (BVT)]
スモーク テストとも呼ばれます。ビルドの状態を高いレベルから判断するために使用されるテストのグループです。チームのメンバがさらに詳細なテストを実施する価値があるかどうかを判断するために、通常、これらのテストは、ソフトウェアの中核的な機能を実行します。ビルド確認テストはビルドの実行後に日常的に実行して、ソース コードのコンパイルに成功していることと、さらに詳細なテストを始める準備ができていることを確認します。ビルド承認テスト [build acceptance test]
「ビルド確認テスト (BVT)」を参照してください。ビルドの状態 [build health]
現状でビルドされているソフトウェアの品質。ビルドの定義 [build definition]
単一または一連のソリューションがビルドされる条件を管理するために使用されます。品質への不満 [quality dissatisfaction]
リリースの品質が低いときに生じる不満。品質保証 [quality assurance]
定義済みの標準、手法、手順、および方法がプロジェクトに適用されていること、およびその結果を確認する、計画的で体系的な手段。これには、プロジェクトの全体的なパフォーマンスを定期的に評価してプロジェクトが該当する品質標準を満たしていることを確認するプロセスと、顧客要求を満たすために実行することが求められるソリューションのレベルを示したドキュメントの両方が含まれます。ファジー テスト [fuzz testing]
ソフトウェアの脆弱性につながる可能性のあるエラーを検出する可能性を最大化するために、ソフトウェア アプリケーション プログラミング インターフェイス (API) およびネットワーク インターフェイスに構造的な (ただし無効な) 入力を行うテスト。フェーズ [phase]
プロセス モデルまたは製品のライフ サイクル内の各区分。通常は、製品またはサービスの開発における基本的な遷移であり、主要マイルストーンまたは外部マイルストーンで頂点に達するか、製品またはサービスの開発における基本的な遷移を表します。負荷プロファイル [load profile]
ロード テストまたはストレス テストに対してシミュレートされた作業負荷。負荷プロファイルは、一定にすることや、ステップにより動的に増加させることができます。負荷分散 [load balance]
使用可能なリソースに作業を再分配すること。または、使用可能な時期に再スケジュールすること。物理設計 [physical design]
設計プロセス内の 3 番目の主要な段階。この段階で、プロジェクト チームは論理設計を具体的に実装する方法を決定します。物理設計では、エンド ユーザーが使用するテクノロジを考慮します。この設計のゴールは、実装やパフォーマンスに関する考慮事項などのテクノロジに対する現実の制約を論理設計に適用することです。物理設計は、建築請負業者が配線、配管、暖房、および換気の構造における物理的な要素を計画する段階に対応しています。請負業者の計画により、アーキテクトの計画に詳細が追加され、建築に対する現実の制約が反映されます。部分 [partial]
テストで部分的に実行されたコード行。「ヒット」および「ミス」も参照してください。ブラウザ プロファイル [browser profile]
Internet Explorer 6 や Netscape 6 など、特定のブラウザをシミュレートするための HTTP ヘッダーのコレクション。ブラウザ ミックス [browser mix]
仮想ユーザーが特定のブラウザ プロファイルを実行する確率を指定します。たとえば、Internet Explorer 6 の使用が 95% で、Pocket IE の使用が 5% などと指定します。Web テストおよびコード化された Web テストに対してのみ有効です。「ロード テスト シナリオ」、「Web テスト」、「コード化された Web テスト」を参照してください。ブラック ボックス テスト [black box test]
コンポーネントの実装に関係なく、コンポーネントの実際の動作に基づくテスト。フレームワーク [framework]
現実を確認する方法を構成する、一連の前提、概念、価値、および手法。プログラム [program]
プロジェクトをグループ化したもの。通常は、連携して管理および提供される共通の一連のゴール、計画、および成功の測定が含まれています。プロジェクト [project]
「チーム プロジェクト」を参照してください。プロジェクト クエリ [project queries]
全ユーザー用に保存されるクエリ。プロジェクト スコープ [project scope]
ソリューション スコープを計画および提供するためにプロジェクト スポンサーとプロジェクト チーム間で合意および文書化される作業。プロジェクト ビジョン [project vision]
システムを構築するための目的、動機、および背景。プロジェクト ビジョンのゴールは、チームの焦点を中心目的に合わせることです。プロジェクト ポータル [project portal]
チーム プロジェクトのコード以外の作業生産物およびレポートの格納および提供に使用する Windows SharePoint Services サイト。プロジェクト ライフ サイクル [project life cycle]
通常、連続するプロジェクト フェーズ。フェーズの名前および番号は、プロジェクトに参加する 1 つ以上の組織のニーズにより決定されます。プロジェクト管理者 [project administrator]
UI または SDK から作業項目トラッキングを変更できる管理者。プロジェクト計画 [project plan]
プロジェクトの実行と管理の両方をガイドするために使用される、正式な承認済みのドキュメント。プロジェクト計画の主な用途は、計画の前提と判断を文書化し、ステークホルダ間のコミュニケーションを促し、承認されたスコープ、コスト、およびスケジュールのベースラインを文書化することです。プロジェクト計画は、要約または詳細にすることができます。プロジェクト項目 [project item] [project items]
データベース プロジェクトを構成するさまざまな種類のオブジェクト (データ生成計画、スクリプト、スキーマ オブジェクト定義など)。プロセス [process]
結果、製品、またはサービスを生み出す一連のアクティビティ (通常は継続的な操作)。目標を達成するために設計された一連の処理または操作です。プロトタイプ [prototype]
後の段階、または製品の最終的な完成版に対するモデルとして機能する、製品または製品コンポーネントの暫定的なタイプ、フォーム、またはインスタンス。このモデルは、物理モデル、電子モデル、デジタル モデル、分析モデルなどになり、新しいまたは普及していないテクノロジの実現性の評価、技術的なリスクの評価または軽減、要件の妥当性の確認、重要な機能のデモンストレーション、製品特性の設定、プロセス特性の設定、パフォーマンスまたは製品機能の特徴付け、物理的な基本原則の明確化などに使用できます。分岐 [branch]
ファイルのコレクションは複数の分岐パスに展開できます。分岐は、チームで複数のコード ベースを維持する必要がある場合によく使用されます。たとえば、製品のリリース後に次のバージョンの作業を開始する必要がある場合などです。ソース管理においては、分岐はファイル システムのコピー操作に似ています。分析 [analysis]
概念設計においては、ビジネスおよびユーザーについての情報をユース ケースと作業プロセスを文書化したシナリオに分解して吟味すること。論理設計においては、サービス、オブジェクト、属性、およびシナリオ間の関係を識別すること。物理設計においては、実装の候補となるテクノロジを選択し、暫定的な配置モデルを立案するために、インフラストラクチャの物理的な制約とアプリケーションの物理的要件とを考慮すること。分離開発環境 [isolated development environment]
データベース プロジェクトから作成され、通常はデータベース生成計画によりデータが設定されているデータベースの個人用コピー。分離開発環境を使用すると、他の開発プロセスを阻害することなく、データベース スキーマに対する変更の実施とテストを安全に行うことができます。テストの完了後、変更したスキーマをバージョン管理にチェックインすると、チームの他のメンバと変更を共有できます。ベースライン [baseline]
プロジェクト、作業パッケージ、アクティビティに関する元来の承認済みプランから、承認されたスコープでの変更を加えた、または除いたもの。通常、何かについて (たとえば、コストのベースライン、スケジュールのベースライン、パフォーマンス測定のベースラインなど) のベースラインになります。ベータ版 [beta version]
評価とフィードバックのために顧客とパートナーに送付される製品のプレリリース バージョン。ペルソナ [persona]
特定のユーザー グループの一般的なスキル、能力、ニーズ、要望、作業特性、タスク、および背景を示したもの。ペルソナは、特定のユーザー グループの重要な性質を記述する実際のデータを 1 人の架空の人物に集めた、現実感のある虚構です。変更管理 [change management]
新たなエラーの発生を防ぎ、サービス レベル アグリーメントに合致する状態で合意された IT サービス レベルに影響がある場合でも、それを最小限に抑えるための試験済みの方法と技法を使用して、管理上の変更を実施すること。変更諮問委員会 [change advisory board]
IT 環境の変更についての評価、計画、承認に対して責任を負う、サービス提供とサポート機能を担当する人々から成る正式に任命されたグループ。変更諮問委員会 (CAB) は、正式な変更管理プロセスの主要な構成要素であり、IT の全領域の代表、およびビジネス部門の代表とから成り立っている場合が多く見られます。プロジェクトに関して、このグループは、プロジェクトから IT 環境について提案された変更の承認または拒否を担当します。変更制御 [change control]
構造化された手順に従って変更要求の提出、承認、実装、および確認を行うことにより、IT プロジェクトまたはソリューションの品質と整合性を損ねることなく、変更管理を容易にするための基本原則とプロセス。変更セット [changeset]
変更の論理的なグループ。変更セットの目的は、配布されるすべてのファイルと作業項目の更新を、1 回のチェックイン操作で行うことができるようにグループ化することです。変更セット ID [changeset ID]
特定の変更セットに割り当てられた数値 ID。包括経過時間 [elapsed inclusive time]
関数内でかかった時間と関数内での項目の呼び出の処理に要した時間。「排他経過時間」を参照してください。包括時間 [inclusive time]
この関数またはモジュール内で経過した時間の合計。この関数から呼び出された関数またはモジュールの処理に要した時間も含めます。包括遷移 [inclusive transitions]
関数内でユーザー (リング 3) とカーネル モード (リング 0) の間にある遷移の数。関数が呼び出した項目による遷移も含めます。ボトムアップ見積もり [bottom-up estimating]
優れたスケジュール設定を行うための基本原則の 1 つ。実際に作業を行う人によって工数を見積もり、タスク レベルの見積もりをまとめ上げるため、優れた見積もり方式として認識されています。保留中のテスト [pending test]
実行対象として選択されていても、未進行のテスト。保留中のテストは、[テスト結果] ウィンドウで確認できます。保留中の変更 [pending change]
1 つの参加リスト内で実行済みでも、データベースには未送信であり、発行および永続的な記録が行われていない一連の変更。