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

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

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

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

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

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

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

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

• Validate

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 を使用したチェックイン前の指摘の修正も参照してください。

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

• チェッカー構成の編集
• マクロ簡略化または Klocwork knowledge base (ナレッジ ベース) (KB) による解析のチューニング。

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

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

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

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

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

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

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

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

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

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

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

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

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

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