静的解析の指摘事項の未修正や過大なメトリクス値など、ソースコードの将来的な変更や保守を難しくする“負債”と、それを修正しない場合に発生し得るネガティブな“ビジネスインパクト”を計算して表示します。
さらにそれらを保守性や可読性、信頼性などの「品質特性」によって分類して表示することで、リファクタリングの要否や実施の優先順位を客観的に判断することが可能になります。

ソースファイルごとに、コードの複雑度や保守性などの品質指標をスコア化し、分布を表示します。変更する際にリスクが高いファイルを特定し、リファクタリングや慎重にコードレビューを行う対象を決定することができます。

“バグの混入しやすさ”と“複雑さ”の二軸を用い、変更リスクの高い関数を特定します。バグ予測にはGoogle社のバグ予測スコアを用います。表の右上にある関数ほどバグを生み出しやすい危険なものであることがわかります。

開発現場において、どの工程でバグが埋め込まれやすいかを見える化します。

測定したすべてのメトリクスに対し、４段階に分けてリスクの度合いを一括で確認できます。

テスト項目の消化進捗に対し、バグの検出度合いを測定し、過去の経験と照らし合わせ、テスト進捗の順調度合を確認することができます。

月ごとに検出されたバグ数÷コード行数を算出することでソフトウェアの規模を問わず、バグ改修が収束傾向にあるかどうかを確認することができます。

月ごとにレビュー単位時間あたりの指摘件数を算出することで、各プロジェクトにて効率の良いレビューが実施されているかを判定できます。

極端にチェックインの頻度が高い開発者には、タスクの抱えすぎや担当ソースでバグが多発している可能性があるため早期にフォローするきっかけを作ります。

極端に静的解析違反件数が多い開発者は、担当するソースファイルを抱えすぎているかコーディング規約をおろそかにしている可能性があるため、早期にフォローするきっかけを作ります。

極端にチェックインの頻度が低い開発者は、タスクを抱えすぎてチェックインできていない状況や効率的な開発ができていない可能性がありるため、早期にフォローするきっかけを作ります。

タスク管理ツールに登録されている各開発者のタスク数をマージすることで、担当者の負荷をモニタリングします。