Zenn
🎸

【サマリ版】ソースコード品質のメトリクス 〜メトリクスの活用戦略 DevOpsとマイクロサービス時代のQA〜

2024/06/10に公開
DevOps
QA
保守性
品質特性
ソースコード品質
idea

はじめに

ソースコード品質のメトリクス 〜メトリクスの活用戦略 DevOpsとマイクロサービス時代のQA〜という記事を書いたのですが、気がついたら1万文字を超えていたので（笑）、結果だけのサマリ版を用意しました。

PR

2024年6月12日から14日まで、出島メッセ長崎にてソフトウェア・シンポジウム2024が開催されます。シンポジウムの2日目と3日目には、今こそ考えたい！データを活用した品質改善戦略！と題したワーキンググループを主催いたします。品質改善にご興味のある方はぜひご参加ください！

本記事の目的

ソースコード品質のメトリクスをGQMを用いて提案します。

ソースコード品質のGQMモデル

GQMを使って整理します。
整理されたGQMは非常に明確で、具体的な目標達成に役立つと思います。

ソースコード品質のGQM

下記のGQMは保守性の品質副特性をベースに検討しました。副特性ごとのGQMはソースコード品質のメトリクス 〜メトリクスの活用戦略 DevOpsとマイクロサービス時代のQA〜を参照してください。

総合的な目標（Goal）

  • 目標: ソフトウェアの保守性を向上させ、モジュール性、再利用性、アナライザビリティ、変更性、およびテスト性を高める。
  • 目的: システムの柔軟性と理解を深め、新しい要件への適応、既存機能の改善、問題の特定と修正を迅速かつ効率的に行い、開発効率とソフトウェア品質を全体的に改善する。
  • 範囲: 新規および既存のソフトウェアプロジェクトにおけるソースコードの品質向上。
  • 品質観点: ソフトウェアアーキテクチャの明確性、コード構造のモジュール化、コンポーネントの独立性、可読性、テストカバレッジ、自動化の進捗、ドキュメントの完全性、およびメンテナンスの容易性。

以下は、ISO/IEC 25010 SQuaREの保守性の副特性に基づいたソースコード品質の質問（Question）をコンパクトにまとめたものです。

総合的な質問（Question）

  • 質問1: ソフトウェアの構造はどの程度明確で、コンポーネントはどの程度独立しているか？
  • 質問2: システムの各部分の理解しやすさ、再利用性、および変更の容易さはどの程度か？
  • 質問3: 新しい要件や機能の実装、および既存機能の改善に必要な労力とリスクはどの程度か？
  • 質問4: テストプロセスはどの程度効率的で、自動化されているか？また、テストカバレッジは十分か？
  • 質問5: ドキュメントは最新かつ完全で、開発とテストの両方を支援するために十分な情報を提供しているか？

総合的なメトリクス（Metric）

  • メトリクス1: システム構成 - システムを構成する独立したモジュールや再利用コンポーネントの総数。
  • メトリクス2: コード品質 - 結合度、凝集度、再利用率、バグ率、および静的解析ツールの警告数を含むコードの品質指標。
  • メトリクス3: 効率性 - 新しい要件や機能の実装、テストケースの作成、およびテストデータの準備にかかる時間や労力。
  • メトリクス4: プロセス効率 - 変更リードタイム、リグレッション発生率、テストフィードバックサイクル時間を含む開発プロセスの効率性。
  • メトリクス5: ドキュメントとフィードバック - ドキュメントの更新頻度と完全性、およびテスト結果からのフィードバックの迅速性。

SonarQubeやFour Keysを利用したメトリクスの取得

システム構成（メトリクス1）

  • SonarQube: プロジェクト内のファイル数やディレクトリ数を通じて、モジュールやコンポーネントの数を推定することができます。ただし、再利用コンポーネントの総数を直接測定する機能は提供していません。

コード品質（メトリクス2）

  • SonarQube: コードの品質指標として、バグ数、コードスメル数、脆弱性数、および重複度（Duplicated Lines）などのメトリクスを提供します。結合度や凝集度は直接測定されませんが、関連するメトリクスとしてコードの複雑度（Cyclomatic Complexity）などが利用できます。

効率性（メトリクス3）

  • Four Keys: 「変更リードタイム」を測定して、新しい要件や機能の実装にかかる時間を間接的に評価します。テストケース作成時間やテストデータ準備に関しては、Four Keysでは直接測定されませんが、プロジェクト管理ツールや時間追跡システムを使用して測定することができます。

プロセス効率（メトリクス4）

  • Four Keys: 「変更リードタイム」と「変更失敗率」を測定して、開発プロセスの効率性を評価します。これにより、変更に必要な時間とリグレッション発生率を間接的に測定することができます。

ドキュメントとフィードバック（メトリクス5）

  • SonarQube: ドキュメントの完全性を直接測定する機能は提供していませんが、コードのコメント量を通じてドキュメントの一部を評価することができます。
  • Four Keys: テストフィードバックサイクル時間は、CI/CDパイプラインのデータを利用して測定することができます。これにより、テスト結果からのフィードバックの迅速性を評価することができます。

総合的な課題

  • ツールの制限: SonarQubeは結合度、凝集度、変更伝播度などの特定のメトリクスを直接測定する機能を提供していないため、これらのメトリクスについてはプラグインの利用や他のツールへの検討が必要です。
  • 再利用性の評価: 再利用コンポーネント数の取得や再利用率の正確な測定には、SonarQubeだけでは不十分であり、プロジェクト間で共有されているコードの追跡や相関関係の分析が必要です。
  • ドキュメントとフィードバック: ドキュメントの完全性やテストフィードバックサイクル時間はSonarQubeやFour Keysでは測定できないため、ドキュメント管理システムやプロジェクト管理ツールの利用が必要です。
  • メトリクスの運用: メトリクスが多すぎると運用が難しくなるため、実際のプロジェクトにおいては、必要なメトリクスを選定し、シンプルなセットに絞ることが重要です。
  • 影響の理解: コードの可読性や静的解析ツールの警告数など、SonarQubeで測定可能なメトリクスが保守性に与える影響を正確に理解するためには、追加の分析が必要になる場合があります。

改善活動

このGQMモデルに基づいて、ソースコードの品質改善に向けた具体的な活動を実施することができます。

改善活動の提案

  1. ツールとプロセスの統合:

    • SonarQubeとFour Keysのデータを統合し、ソフトウェアの品質指標を一元的に管理するダッシュボードを構築します。
    • 結合度や凝集度などのメトリクスを測定するために、SonarQubeのプラグインエコシステムを活用するか、専門的な設計解析ツールを導入します。

  2. 再利用性の促進:

    • コードベースを定期的にレビューし、再利用可能なコンポーネントを特定してカタログ化します。
    • プロジェクト間で共有されるライブラリやフレームワークの使用を標準化し、再利用を容易にします。

  3. ドキュメントの改善:

    • ドキュメントの完全性とアクセシビリティを向上させるために、ドキュメント管理システムを導入または最適化します。
    • 開発プロセスにドキュメントの更新を組み込み、変更ごとにドキュメントを維持管理する文化を育成します。

  4. テストプロセスの最適化:

    • テストカバレッジを向上させるために、テストケースの作成とメンテナンスを定期的にレビューします。
    • テスト自動化を推進し、CI/CDパイプラインに統合することで、テストフィードバックサイクルを短縮します。

  5. メトリクスの選定と運用:

    • プロジェクトの目標と制約に基づいて、最も影響力のあるメトリクスを選定し、運用をシンプルに保ちます。
    • メトリクスの結果を定期的にレビューし、品質改善のためのアクションプランを策定します。

  6. 教育とコミュニケーション:

    • 開発チームに対して、ソフトウェアの品質特性と保守性の重要性についてのトレーニングを実施します。
    • チーム間のコミュニケーションを促進し、品質改善のためのアイデアやベストプラクティスを共有します。

参考

Discussion