展開フェーズ I - 展開時の決定事項
このトピックの内容: |
展開フェーズ I - 展開時の決定事項
フェーズ I では、Klocwork の展開に関する決断を下すことに重点を置いています。このフェーズでは、いくつかの段階の計画が必要になります。導入フェーズ I ワークシートに情報を記録できます。
ステージ 1: 主要スタッフの特定
Klocwork 展開プロジェクトの成功は、その作業を先導するスタッフによるところが大きいです。Klocwork の利用は、長期的に見て費用削減につながりますが、展開の初期段階においては、次の人たちから非常勤のコミットメントを必要とします。
- Klocwork チャンピオン/スポンサー:通常、Klocwork の展開を補佐するために必要なスタッフの予定を決める、マネージャーまたは管理チームです。この人は、追加グループの Klocwork の利用を推進するだけでなく、ソフトウェア開発メトリックを熟知している必要があります。
- Klocwork 管理者: 管理者は組織の規模により、1 名またはチームがの場合があり、その人たちは、次のような Klocwork 管理作業を行います。
- Klocwork サーバーの管理
- 移行およびソフトウェアのアップデート
- Klocwork データベースのバックアップ
- アクセス許可および役割の設定
- チェッカーセットおよび分類基準の管理
- 当初、Klocwork 管理者は、各プロジェクトの Klocwork 統合ビルドを設定、管理することもあります。
- IT 管理者: 必要なシステム ハードウェアを設定し、認証システムにアクセスを許可し、ライセンス サーバーの管理も行うことがある、IT 部門の担当者です。
- プロジェクト チームの長: Klockwork を使用する各開発チームにおいて、チーム長は手順が機能するパラメータの確立に関与します。例えば、この担当者は実行するチェッカーを選択し、ナレッジ ベースを微調整することにより、可能な限り最良の結果をもたらし、チームの社内連絡先となります。
- デベロッパー: 展開を成功させるには、究極的なエンドユーザー、デベロッパーまたはその人たちの適切な代表者グループが、展開の際の決定や手順に関与することが重要です。最終的には、コードの品質、セキュリティまたはコンプライアンス実施プロジェクトの成功は、デベロッパーが最も効率の高いポイント (デスクトップ) において、規則を採用することに大きく左右されるので、この目標の障害物となるものは最小限に留める必要があります。デスクトップ利用パターンおよびベスト プラクティスが効果的に伝えられるように、いくつかのトレーニング オプション(教室での授業、またはコンピュータをベースにした)があります。
- 品質保証、セキュリティまたはコンプライアンスのチーム:最後に、最終的展開が品質、セキュリティまたはコンプライアンス要件のニーズを満足するためには、展開手順、特にユーザーの許可および役割オプション、そしてその結果であるレポート、監査追跡および制御に適切な利害関係者が関与することが非常に重要です。
静的コード解析プロフェッショナルサービスは、特定の要件を導くために補佐し、展開段階の間、主要なスタッフ メンバーを助言します。
ステージ 2: パイロット プロジェクトの識別
初期セットアップ時の問題による影響を制限するため、最初に Klocwork を 1 つまたは数少ない、小さいながらも代表的なプロジェクトで試験することが推奨されます。最初は、これらのユーザーを 1 つの地理的地域に収めることが勧められます。
ステージ 3: 展開タイプ
この展開の段階について何も決定されていませんが、Klockwork がどこに位置付けられ、前進するために必要な用語に注意することは重要です。次の図は、Klockware がソフトウェア開発ライフサイクル (SDLC) においてどこで使用されているかを示します。

Klocwork は通常、デベロッパー デスクトップおよびビルド解析の両者を使用して SDLC に展開され、適切に使用されます。以下が定義です。
- デベロッパー デスクトップ— Klocwork はデスクトップで使用されます。デベロッパーは各自の IDE 内またはコマンドラインでこれを使用します。このシナリオは、デベロッパーがコーディングをしている際に指摘に直ちに対応するので、費用対効果が最大化します。
- ビルド解析 — Klocwork は完全な統合ビルドに統合されます。通常は、毎晩または毎週の頻度で行われます。この際に、ソフトウェアシステムの全コンポーネントがコンパイルされ、完成したソフトウェア製品に関連付けられます。
Klocwork は、デベロッパーのデスクトップおよび統合ビルドの両方において、Klocwork を展開することを推奨します。これは最適な展開メソッドであり、費用対効果を最大限にするために最も効果的であるからです。
デベロッパー デスクトップおよびビルド解析の展開
以下を個別にする必要があります。統合ビルド解析から開始します。
- 統合プロジェクトにビルド解析を実行します。C/C++ 統合ビルド解析 - チートシート
- Klocwork を設定し、デベロッパー デスクトップで実行します。Klocwork Desktop Analysis を使用したチェックイン前の指摘の修正
最初の段階は、統合ビルド解析を実行することです。希望する間隔で、Klocwork をビルド手順に統合します。これで Validate を管理またはレポートのために使用することができます。
第二段階は、デベロッパーのデスクトップをセットアップすることです。これには、Klockwork プラグインをサポートされている IDE で設定、あるいはコマンドラインで使用します。ここにおける主要なことは、デベロッパーがステップ #1 で環境を統合ビルドに同期することです。
ビルド解析が維持され、デベロッパーがデスクトップで指摘を修正している限り、コードのチェックイン後に未解決の指摘はありません。

ステージ 4: 基本的な展開の構造
Klocwork の展開の最終構造については、プロセスのできるだけ早い段階で検討することをお勧めします。どの Klocwork コンポーネントをインストールし、インストールの構成をどのようにするかを、専用のハードウェアが必要かを含めて見極め、決定する必要があります。
初回展開時には例えば次の事項を決定してください。これには、マルチサイト展開にするか、ユーザーがどこを拠点とするか、サーバーをどこに配置するのが最適か、企業の Reprise ライセンスサーバーがあるか、この既存サーバーを使用して Klocwork ライセンスを管理するかといったことが関係します。
- Klocwork サーバー — これらはすべての Klocwork データのコラボレーションおよびコレクション ポイントとして動作するマシンです。接続されているユーザー数やプロジェクト数により必要となる処理能力が異なります。しかし、一般的に、Klocwork サーバーは高い可用性と数多くのデータベース処理リクエストに平行して対処する能力、十分なデータ格納スペースがあります。Klocwork サーバーを小規模設置のプロジェクトチーム専用とし、事業部や単一のロケーションや世界に展開する組織全体の単一サーバーにつながることもできます。Klocwork サーバーはデータベース、ウェブ サーバー、オプションのライセンス サーバー、認証サーバーで構成されています。Klocwork サーバー自体はライセンスされていません。
- Klocwork ビルドサーバー — Klocwork 統合ビルド解析を行うマシンです。標準プロジェクト ビルド サーバー同様、結果の精度を保つため、Klocwork ビルド サーバーは最終的なプロジェクト環境の正確な設置情報を必要とします。一般に、高速 (より高い処理能力を必要とします) であるほど、良い結果が得られます。このため、Klocwork ビルド サーバーは既存マシンへの単なる追加 Klocwork サーバー ビルド ツールとなる場合もよくあります。これは、CI ビルド システムや分散型ビルド システムにも当てはまることです。
- Klocwork デスクトップ — ローカル解析を行う独立型または Klocwork サーバー プロジェクトに接続されたデベロッパー用ワークステーションです。接続されているプロジェクトの場合、部分的なデスクトップ ビルドを行い、Klocwork サーバーからのセントラル プロジェクトの解析データを利用することができます。通常、デスクトップ マシンは通常プロジェクトのビルド ツールや環境が既にインストールされています。これらのビルド ツールがセントラル ビルド サーバーにリモートにインストールされている場合、Klocwork デスクトップの解析コンポーネントも同様にリモートにインストールされます。
- ライセンスサーバー — Klocwork ライセンス用のライセンスサーバーは、必要に応じて別途インストールすることも、既存の企業 Reprise ライセンスサーバーを利用することもできます。
- 認証サーバー — Klocwork サーバーおよびすべての関連する Klocwork インタラクティブ ツールを希望に応じてコーポレート LDAPや、ActiveDirectory、または NIS サーバーに接続することができます。
- バグ追跡システムやALM/PLM システム、SCM システム、または管理情報やダッシュボード ユーティリティなどのその他のシステムも多種 API を介して Klocwork に接続することができますが、これらはより緩やかに統合されており、基本的な展開の構造に大きな影響を及ぼすことはありません。
インストールの注意事項
インストールの最小要件はシステム要件に記載されています。
さらに、以下を行う際には、特別な注意が必要です。
- 複数のマシンへのサーバー コンポーネントのインストール
- 複数の projects_roots をインストールする
- Klocwork のアクセス制御 (NIS または LDAP の設定を含む)
- ライセンス
大規模展開の場合の追加的なハードウェア検討事項
並列処理またはマルチコア処理を使用している場合は、プロセッサ/コアあたり 2 GB 以上のメモリを割り当てる必要があります。大規模な解析には 2 GB 以上の空き領域が必要です。ビルドのサイズおよびその RAM の要件は、コードの行数だけではなく、コード内の数およびその関係の複雑度によっても異なります。また、Klocwork は、複数のコア プロセッサと一緒にお使いになる際により高いパフォーマンスを発揮します。これは、データベースの性能を大幅に向上させる場合があります。
ステージ 5: 追加の大規模な決定事項
- Klocwork ビルド サーバーおよび Klocwork サーバー間の接続のみが、統合ビルド解析結果がデータベースにロードされる際、大量のデータ転送を必要とします。このため、できる限り、Klocwork ビルド サーバーと Klocwork サーバーは同一の場所に配置、あるいはかなりのネットワーク接続を提供する必要があります。
- Klocwork デスクトップ マシンおよび Klocwork サーバー、ライセンス サーバーおよび認証サーバーは、これに比べて比較的小さい帯域幅を要します。
ステージ 6: ビルドの統合タイプの選択
Klocwork 解析は、組織の既存のビルドシステムに統合する必要があります。統合ビルドは、ビルド システム (ant や make など) または IDE (Visual Studio、CodeWarrior など) で通常行われます。Klocwork 統合ビルド解析で正確な結果を得るためには、ソフトウェアがどのようにコンパイルされ、リンクされているかを build specification (ビルドスペック) の形式で Klocwork に認識させる必要があります。
ビルド統合の詳細については、C/C++ build specification (ビルドスペック) の作成、Java build specification (ビルドスペック) の作成、または C# build specification (ビルドスペック) の作成を参照してください。
ビルドの仕様により、Klocwork ビルド解析を実行できます。Klocwork ビルド解析は並列・分散処理の実行のためのサポートから配布可能です。詳細については、C/C++ 統合ビルド解析 - チートシートを参照してください。使用される方法は、環境、ビルドシステムおよび言語によって異なります。
ステージ 7: 検出する指摘/脆弱性の選択
この段階において、技術リーダーおよびマネージャーは、どの指摘およびセキュリティ上の脆弱性を有効にするのか決定する必要があります。成熟したコード ベースを持つ大規模な開発環境は、解析を始めるために少数の指摘または脆弱性だけを選択し、有効にする問題を繰り返し増やすことを考慮することもできます。
解析の実行と実行の間に独自の Klocwork チェッカーを編成して、新しい組織構成をレポート作成用に直ちに使用できるようにすることもできます。この組織構成を分類基準と呼びます。
MISRA、CERT、CWE および DISA STIG など、よく知られている業界基準を分類基準およびチェッカーとしてダウンロードすることもできまうs。これらのチェッカーを使用するには、https://library.roguewave.com/display/SUPPORT/Klocwork+-+Product+Downloads からダウンロードする必要があります。MISRA チェッカーを有効にする方法については、ダウンロードに含まれている readme ファイルを参照してください。
Klocwork のデフォルト構成から始め、拡大または縮小します。これにより、貴社にとって重要な指摘および脆弱性の早期検出に対する努力に焦点を当てることができます。
多くの組織は、メモリー リーク、バッファー オーバーフローおよび NULL ポインター逆参照などの指摘解析から始めます。他の組織では、セキュリティの脆弱性を考慮し、セキュリティ特有の指摘を検出することに焦点を当てます。例えば、組み込み式ソフトウェアを開発している場合、低目盛り状況に関する規則を有効にすることを考慮することもできます。しかしながら、デスクトップ クライアント ソフトウェアを開発している場合、最初はこの指摘をオフにした方がよいかもしれません。最後に、一部の組織はコンプライアンスのみを考慮することがあります。
Java コードでは、web アプリケーションなど、特定のアプリケーション タイプに調整された、Klocwork の事前定義された Java プロファイルの 1 つを選択します。静的コード解析プロフェッショナル サービスは、貴社にとって何が重要であるか理解するため補佐し、貴社製品のための特定の指摘および脆弱性に導きます。
ステージ 8: 指摘管理アプローチの選択
自動ソース解析の利用を成功させるための主要要素は、長期的に報告された指摘や脆弱性を管理するための手順を実施することです。Klocwork は指摘または脆弱性が検出されたとき(ステート)および報告された指摘にどのアクションが割り当てられたか(ステータス)追跡します。この情報はデータベースに保存され、ビルド全体に情報を提供します。
ステートは、Klocwork によって検出されたすべての指摘と脆弱性に自動的に割り当てられます。
ステータスは、Klocwork によって検出されたすべての指摘と脆弱性にユーザーが割り当てることができます。例えば、ステータスは、即座に修正する必要がある指摘と、一時的あるいは恒久的に問題なく無視することができる指摘を分類するために使用することがでます。
貴社が多様なステータスを使用する方法について、指摘管理で同意する必要があります。
また、プロジェクトをベースラインにし、チェッカーに関わらず、レガシーコードで発見された任意の既存の指摘を脇に置き、コードストリームに新しい指摘が到達することを防ぐことに焦点を当てることができます。
ステージ 9: ロールベースセキュリティの選択 (オプション)
使用するステータスが決まり、手順の一部としてそれぞれのステータスの意味が決まったら、指摘のステータスを変更できる人も決める必要があります。たとえば、「問題ではない (Not a problem)」へのステータス変更は一部のリードデベロッパーまたはレビュー担当者にしか許可できません。ステータスを「問題ではない (Not a problem)」に変更する前に、デベロッパーはステータスを 「保留 (Defer)」に設定し、レビュー担当者は「保留 (Defer)」ステータスに設定されているすべての項目が実際に指摘ではないことを確認しておく必要があります。
Klocwork は役割に基づいて、Klocwork の使用を制御する方法がいくつかあります。例:すべてのデベロッパーに Klocwork プロジェクトを構築してもらいたいですか?「検知 (Analyze)」から「問題ではない (Not a problem)」へのステータス変更を全ジュニア デベロッパーに許可したいですか? Klocwork は、ユーザーごと、あるいはグループごとでカスタマイズする柔軟性を提供します。
次の画像は、通常のデベロッパーのワークフローを示します。

役割ベースのセキュリティを実装するには、最初にシステムにおけるユーザーおよびグループを識別する必要があります。この機能を実装する場合、既存の LDAP または NIS インフラストラクチャのいずれかと統合することが推奨されます。Klocwork の内蔵クセス制御を使用することもできます。