|
コンポーネントと用語チェックリストチェックリストは、特定の標準またはガイドラインを構成する一連のルールを反映する一連のチェックです。 チェックリストは、特定のプロジェクト/レビューの特定のチェックが選択されるプロジェクトに依存しないリソースです。 標準で以下を含みます:
レビューツールは、これらのルールのレビューを2つのレベルでサポートします。 まず、通常最も時間のかかるルールをチェックする際の生産性が大幅に向上します。 可能な限り多くの手動検査をガイドおよび自動化し(2)、自動静的分析テストの一部を実行します(1)。 第二に、プロセス全体をサポートします。 レビューツールは、すべてのカテゴリのルールのレビューアクティビティの文書化、追跡、レポート、および監査をサポートする単一のまとまったリポジトリとして機能します。 たとえば、ツールは外部分析ツールの結果を記録し、全体のレビュードキュメント内に結果を統合できます。 イニシアチブ標準のチェックリストに加えて、レビューツールは一般に受け入れられている設計手法のチェックリストをサポートしています。 Imagix-Checksチェックリストを使用して、Imagix 4Dのメトリック、ソースチェック、フローチェックレポートが潜在的な設計または実装の問題を示しているソフトウェアの部分を識別、評価、文書化できます。
レビューレビューは、Imagix 4Dプロジェクトのソフトウェアが評価される一連のチェックです。レビューは、Imagix 4Dプロジェクトに固有のものです。 レビューにはさまざまなチェックリストからのチェックを含めることができ、プロジェクトには複数のレビューを含めることができます。 レビューでは、各チェックについてプロジェクト固有のデータが収集および記録されます。 レビュープロセス中に、この基礎となるデータは増大します。 レビューのバックアップは自動および手動で作成され、後で以前のポイントを復元したり、2つのポイント間のレビューの変更を比較したりするために使用できます。
チェックチェックとは、ソフトウェアの正確性、一貫性、コンプライアンス、パフォーマンス、セキュリティ、またはその他の望ましいプロパティに対する潜在的な懸念事項であるソフトウェアの特定のスタイルまたは動作の説明と、識別および 標準の特定のルールに関連付けられたソフトウェアのこれらの部分の評価。 通常、標準のルールとレビューツールのチェックの間には直接対応があります。チェックは、チェックリストまたはレビュー内の一意の名前で識別されます。 チェックは、レビューの実施に必要な手作業を最小限に抑えるように設計されています。 これは、チェック間で共有できる共通のステップを作成し、これらのステップを準備チェックに分割することによって部分的に達成されます。 これらのチェックの結果は、複数のチェック間でダウンストリーム入力として共有できます。 このような準備チェックは、Prep-xxxという名前で識別されます。 チェックの2番目のカテゴリは、チェックリストまたはレビューツールの使用に関するドキュメントのみを含むものです。 これらは、Info-xxx名で識別されます。 通常、チェックリスト内およびレビュー内の他のすべてのチェックは、標準の特定のルールに対応しています。 このような各チェックには、標準のルールに関連付けられた一意の名前があります。 場合によっては、関連する一連のチェックを組み合わせることにより、別のチェックまたはルールとの適合性が保証されます。 これらの場合、複合チェックはまだレビューおよびチェックリストにリストされていますが、レビューツールに表示されるとき、チェック表示はそれを構成する個々のチェックを示します。 これは、チェックリストに階層を課すことにより、レビュープロセスの構造化に役立ちます。
ステップステップは、ソフトウェアの一部を特定または評価する際の特定のアクションです。 各チェックは、このような手順の順序付きリストで構成されています。レビューツールは特定のアクションタイプのセットを実装し、これらはステップの定義に使用されます。 これらのアクションタイプには、入力プローブのセットに基づく分析を伴い、出力プローブのセットを生成するものがあります。 通常、これらのアクションタイプを使用するステップは自動化できます。 出力プローブが自動的に生成される場合でも、手動でオーバーライドできます。 他のアクションタイプでは、レビューアーがソフトウェアの知識と分析を適用して、手順で説明されている基準に適合するソースファイル内のシンボル(関数、変数、またはデータ型)または行を手動で識別する必要があります。 通常、これはImagix 4Dの一般的な視覚化および分析機能を使用して行われます。 または、基準が標準言語機能またはライブラリに関連するステップの場合、ステップ固有の標準プローブファイルをロードして、候補シンボルを識別できます。
プローブプローブは、ソフトウェアの特定の部分に関連付けられたアーティファクトです。これらにはいくつかのタイプがあります。 プローブは、ソフトウェア内の特定のシンボル(関数、変数、マクロ、データ型)、ソースコード内の特定の場所(ソースファイルと行番号)、または関連するシンボルと共に特定の場所(ステートメント内で読み取り中の変数など)を識別できます。この最後のタイプのプローブは、通常、可変フローチェック分析の実行などの自動ステップによって生成されますが、ユーザが手動で追加することもできます。 プローブは他のステップへの入力として機能するため、一部のプローブでは、解析の実行に使用されるImagix 4D設定を指定する必要があります。 これは、クリティカルリージョン定義の場合に特に当てはまります。定義はプローブとして記録され、ダウンストリームチェックの一部としてタスクフローチェック分析を実行するための入力として使用されます。 レビュープロセスで何かを識別および追跡する際の完全な柔軟性を実現するために、ノートはプローブとして直接機能することができます(プローブに添付されることに加えて)。 たとえば、これにより、外部の静的または動的分析ツールによって検出された結果を記録する方法が提供されます。
評価評価は、特定のプローブが評価対象のルールに準拠しているかどうかの評価です。 各準備前チェックまたは情報チェックの最終ステップでは、レビュー対象のルールに直接関連するプローブを特定します。 評価が割り当てられるのはこれらのプローブです。各プローブには、問題なし(OK)、懸念、または違反の評価を割り当てることができます。 プローブは、未評価(初期条件)として設定することもできます。 プローブで実行できる別のアクションは、ステップからプローブを削除することです。 これは、問題なしの評価を割り当てることとは異なる影響を及ぼします。 問題なしの評価は、プローブが特定され、検査され、問題ではないと判断されたことを示します。 プローブを削除すると、検査が行われたすべての記録が消去され、ソフトウェアの以降のバージョンのレビューの基礎となるアーティファクトは残りません。 したがって、最終ステップのプローブは、チェックされるルールに単純に適用されない限り、削除するのではなく評価する必要があります。 ただし、ユーザ入力に基づく以前のステップでは、特に下流のステップへの誤ったプローブの伝播を回避する際に、誤って識別されたプローブを削除することが役立ちます。
ノートノートは、レビュー、チェック、ステップ、またはプローブに関連付けられたテキスト文字列です。 ノートは、アーティファクトに注釈を付けてコメントする機能を提供するため、作成されるドキュメントレコードに追加されます。レビューの実施に関係する多くのアクションは、自動的にノートを生成し、追跡および監査アクティビティを支援します。 さらに、メニュー項目を使用すると、レビュープロセス全体を通じて、ほとんどの項目(レビュー、チェック、ステップ、またはプローブ)にノートを作成して添付できます。 これらのメモは、削除しない限り、レビューの永続的な部分として残ります。 同じアイテムに複数のノートが添付されている場合、それらを順番に削除する必要があり、最新のノートが最初に削除されます。
|