要求、設計をはかる

要求仕様や設計書作成のメトリクスとしては、要求仕様や設計書のページ数とレビューの指摘密度やチェックリスト密度が代表的なようでこれらを収集されているところは多いのではないだろうか。

UMLなどの形式的手法に沿って書かれていれば、ユースケースポイントやクラス図から定義済みクラス数や定義済みメソッド数を取得することができる。シーケンスダイアグラムやアクティビティダイアグラムからも同様のメトリクスを取得することができる。EPM Pro*での「コーディングからテストへの移行直前にソースコードの行数が増減していれば、そこにリスクの可能性がある」というような観察と同様に、設計がほぼ終了しつつあるときに定義済みクラスの増減があれば、リスクの観察ができるだろう。

要求定義や設計フェーズに計測したほうがよいものがあるかと質問されることがあるが、まずは計測の目的を伺ったり、計測の結果得ようとしていることを伺うようにしている。計測の目的はいくつかのパターンに分類でき、プロセス変更の結果を定量的に示したかったり、リスク予測をしたかったり、問題点の発見をしたいというのが代表的だ。目的に応じてこたえるようにしている。

目的はさておきメトリクスとして収集したほうがよいものを強いてあげるならば？と聞かれることもあり、以下の4つを候補として答えることにしている。自動計測が難しいので、もちろん目的が合致していて、コストがみあっていることが前提なのだが。特に要求、設計時には、目的がはっきりしない計測をあまりおすすめしていない。計測コストが小さければかまわないのだが。

• 「T.B.D(to be determined: 後で決める)」の数
  顧客や他の設計部門の決定を待ってから決める部分や現時点では明確でない部分が多く決められていないである。ある程度はしかたがないことではあるが、これが多すぎると何も決まらないままプロジェクトが進んでいるリスクがある。
• 異常系の厳密さや存在有無
  一般に、正常系の定義や設計が終了してから異常系の定義や設計がはじまるので、異常系処理の厳密さや存在有無は要求や設計の進行度合いをはかる目安となる。
• 変更による手戻りの度合いや工数
  変更によって発生した手戻りの累積。たとえば手戻りの工数がとれて いれば本来計画していた工数に追加の工数がどの程度必要となるかを類推できる場合がある。
• レビューでの指摘の種類と指摘数
  ここにも書いたことがあるが、要求仕様のレビューや設計レビューでの指摘事項の記録は参考になるものが多い。