EN JP CN

展開フェーズ II - 実装ステップ

展開フェーズ II - 実装ステップ

展開フェーズ II - 実装ステップ

展開フェーズ II - 実装ステップ

フェーズ II は、フェーズ I の決定事項に基づいた展開の実行に重点を置きます。導入フェーズ II ワークシートに情報を記録できます。

段階 1:Klocworkインストール

選択した インストール構成により、ハードウェアおよびストレージ要件、データ管理およびライセンスについて考慮する必要があります。Klocwork サーバーをはじめとしたツールは、フェーズ Iフェーズ Iで作成した実装計画に基づいてインストールする必要があります。

Klocwork をデスクトップに展開する場合は、Klocwork IDE プラグインまたはコマンドライン ソフトウェア (kwcheck) をデベロッパーのデスクトップにインストールする必要があります。各デベロッパーは、デスクトップ解析プラグインをインストールできます。

段階 2:役割ベースのセキュリティの設定

このフェーズでは、役割ベースのセキュリティのメソッドを確認しました。既存の LDAP インフラストラクチャまたは NIS インフラストラクチャを統合する方法または Klocwork 基本アクセス制御を使用する方法の詳細については、アクセス制御のセットアップを参照してください。

特定のユーザーまたはグループの役割を設定する方法については、プロジェクトへのアクセスの有効化を参照してください。

段階 3:指摘/脆弱性の構成

フェーズ I、段階 7 では、Klocwork を使用して特定する指摘と脆弱性を特定しました。フィールドこのデータを制御する Klocwork 構成に変更を加える必要があります。統合ビルド解析用チェッカーの設定を参照してください。

デベロッパーが独立して作業を行っている場合、自身の設定をカスタマイズすることができます。Klocwork 統合ビルド解析と作業をしている場合、デスクトップと統合プロジェクトとの間で一貫性のある解析を行うために、データを Klocwork サーバーと同期化するためにアクセスが必要です。

段階 4:最初の解析の実行

統合ビルド解析に続き、解析に関する情報は次の Klocwork クライアントから使用できるようになります。

Klocwork デベロッパー デスクトップ解析を実行するには、通常システム全体よりもファイルごとに行います。デベロッパーは Klockwork IDE プラグインまたはコマンドラインのいずれかを使用することができます。

デベロッパーデスクトップの Klockwork サーバー上の特定の Klocwork プロジェクトを参照することが重要です。このアプローチにより、デベロッパー デスクトップ解析はどの指摘およびセキュリティの脆弱性が解析中に有効になっているか決定する構成ファイルにアクセスできるようになります。デベロッパーが IDE プラグインを使用、またはコマンドライン上で自動的に行われます。

特別なデベロッパーデスクトップに対する考慮

統合ビルド解析が完了したら、デベロッパーはプロジェクトと同期化することにより、解析を利用することができます。Eclipse を CDT と使用、Eclipse を Java と使用、あるいは Visual Studio を使用している場合、手順はプッシュボタン アプローチで簡単に同期化をセットアップし、解析を行うだけです。コマンドラインで kwcheck を使用している場合、または別の IDE で Klocwork を実行している場合は、解析の前にビルド スペックを生成しておく必要があります。

デスクトップでスペックを構築する方法は 2 つあります。

  1. その場で build specification (ビルド スペック) の生成
  2. 統合プロジェクトからの build specification (ビルドスペック) を使用します。

オプション #1 を強くお奨めします。このオプションでは、デベロッパーはデスクトップで解析を行う前に、ファイル/モジュールのスペックをたやすく構築することができます。メリットとしては、新しいファイルのためでさえも、ほとんどいつも可能な限り最新のビルドスペックを使用できることです。この方法では、デベロッパーがコードのコンパイルと kwinject などの Klocwork ビルド支援ツールの実行を環境内で直接行うことが必要となります。代わりに、kwshell を使用して、手順を自動化することができます。

オプション #2 のメリットは、既に生成されている、統合プロジェクト ビルド スペックを使用することです。このオプションは、デベロッパーが、システム全体を構築するために使用した、ビルド マシンと同じパスを使用してファイルの作業を行うときにのみ使用できます。これは通常めったに起こりません。さらに、この方法では、デスクトップで作成された、新しいファイルの解析ができません。

注: オプション #2 は、特別な配慮が必要です。というのは、完全な統合ビルド スペック ファイルを使用することで、同期手順で特定の劣化が生じることがあるからです。システムに 5000 を超えた Klocwork の指摘がある場合、同期化に要する時間が長くなります。この場合、統合ビルド スペックを取り扱いやすいコンポーネントに分ける必要があります。このオプションを避けるべき理由はここにあります。

Klocwork Desktop Analysis を使用したチェックイン前の指摘の修正も参照してください。

段階 5a:結果の調整

解析が完成したら、さらに指摘検出を 2 つの方法で調整することができます。

特定のタイプの指摘が多すぎると感じた場合、構成ファイルで無効にすることもできます。代わりに、リストが少なく、より多くの指摘や脆弱性を有効にしたい場合もあります。

場合によっては、誤検出が解析にある場合もあります。ナレッジ ベース (KB: knowledge base) を設定し、誤検出を削減あるいはなくすための方法がいくつかあります。C/C++ 解析のチューニングおよび Java 解析のチューニングを参照してください。

段階 5b:ビルド頻度の決定

解析ビルドの頻度は、ソフトウェア開発手順により異なります。夜間ビルドを行ったり、週ごとにビルドを行うことができます。あるいは、デベロッパーが機敏な開発アプローチを購読している場合は、反復ビルドを行うこともできます。

通常、リリースごとあるいは反復ごと、マイルストーンごとに解析ビルドを行い、次に必要に応じてより頻繁に行います。中間ビルドはマイルストーンごとに片付けることができます。詳細は 統合プロジェクトとビルドの管理、「ビルド リテンション ポリシー」を参照してください。

段階 6:ベースラインの生成 (オプション)

大規模なソフトウェア プロジェクトでは、多くの組織はベースラインを作ることにより、新らたに生じた指摘に努力を注ぎます。これは、特定のビルドで解析 (通常はプロジェクトの最初の Klocwork 解析) を実行し、Klocwork によって報告されたすべての指摘および脆弱性のステータスを "保留 (Defer)" にする方法です。この方法に従うと、組織は、すべての既存の Klocwork の指摘を保持している特定のステータスに割り当てて、その後のビルドで特定される新しい指摘と脆弱性だけに重点的に取り組むことができます。ベースラインとなった指摘がなくなったわけではありません。デベロッパー表示のデフォルトでは表示されていないだけですが、リソースに余裕があり、管理職が必要とみなした場合には表示し、アクション可能なステータスに戻すことができます。これは段階 X でカバーされています。バックログへの対処:

レガシー コードが既に承認されている、あるいは使用可能として実証されている場合、かつ将来修正されたときに Klocwork が品質、セキュリティまたはコンプライアンス チェックを確実に行うためにのみ利用されている場合、ベースラインが役に立つこともあります。最後に、ベースライン戦略は必ずしもすべての指摘に適用する必要はなく、あるいは指摘の重度に基づいて選択、または他のツールやソース コードのコメントから既存の許可済み偏差をインポートすることもできます。

段階 7:指摘管理の開始

指摘のベースラインが実現されたら、デベロッパーは Klocwork Static Code Analysis またはデベロッパー ツールを使用して、適切なステータスを適用することができます。全員がステータスの意味(フェース I、段階 7)について知る、あるいは教育を受ける必要があります。そして指摘および脆弱性は、新しいステータスのマークを付ける必要があります。この時点で、デベロッパーは「要修正 (Fix)」ステートになっている指摘を修正する必要があります。

後で実行される解析が行われ、手順全体が再度開始されます。

段階 8:バックログへの対処 (オプション)

段階 5 を使用する場合は、ベースラインを確立すると、ある時点で調査が必要な指摘のバックログが作成されます。Klocwork が、新規開発において発見された指摘を取り扱い可能なレベルにまで減らしてから行います。この段階はオプションであり、リソースを割り当てることができる場合にのみ対応します。

レガシー コードの既存の指摘に対処する手順は頻繁に、変更を加えているコードを理解している、経験を積んだデベロッパーに個別作業として与えられます。

段階 9:通常の測定の確立

手近に測定可能なメトリックがあるため、貴社の手順や生産性を大幅に改善することができます。Klocwork数多くのメトリックおよびトレンディング データがあり、サイズ、複雑性、指摘数、セキュリティの脆弱性および変更量など、コードを測定することに使用できます。このデータは、ソフトウェアの開発評価および優先順位の決定するために役立ち、懸念すべき領域の確認を可能にし、コード改善またはその他のテストの計画を立てたり、前進する際の解析戦略を作ることができます。

Klocwork をデスクトップおよび統合ビルドレベルの両者で展開した場合、統合ビルドで検出される指摘数は、チェックイン前にデベロッパーが指摘に対応するため、時間の経過と共に減少します。この傾向は、他の該当するメトリックと共に、Klocwork Static Code Analysis でモニターすることができます。

Klocwork デスクトップで修正される、指摘または脆弱性の数をさらに細かく測定することができます。組織がデベロッパー IDE プラグインまたはkwcheck を使用していて、このレベルで修正された指摘が決して統合ビルドに達しない場合でも、Klocwork はこれらの指摘を追跡します。

段階 10:バックアップ手順の開始

Klocwork が継続的開発手順に統合されたら、保持しているデータおよび提供するデータは計り知れないほど貴重になります。そのため、Klocwork データベースのバックアップ(および復元)手順の開始、確認およびモニターが確実に行われていることが非常に重要です。Klocwork データのバックアップを参照してください。