ソフトウェアの品質を学びまくる2.0

ソフトウェアの品質、テストなどについて学んだことを記録するブログです。旧ブログからゆっくり移行中です。http://blog.livedoor.jp/prjmng/

設計工程の品質を見定めたくて仕方ない

 社内の有志で、設計工程の品質評価技法についてディスカッションをしています。ソフトウェアの品質を評価するのさえ難しいのに、ドキュメントの品質となるとなおさら手がかりが少なく、いろいろ調べております。今回はそのメモです。

簡単に思いつくもの

 設計のドキュメントの品質を判断するのにまず思いつく量は、

①ドキュメントのページ数
②見積もった開発規模
③レビューでの指摘件数
④レビューにかけた工数(時間×人数)

など。で、これらを組み合わせた

・記述密度: 規模あたりのページ数=①÷②
・指摘密度: ページ数あたりの指摘件数=③÷①
・生産性: 指摘件数あたりの工数=④÷③

といったところでしょうか。

 ただ、「枚数」ってあまりに不安定な量ですよね。
 ぱっと思いつくだけでも、以下の問題があります。

(1)「1ページ」の重みが一定でない

 Wordで作った基本設計書と、EXCELで作ったDBのテーブル定義書とで、1ページは同じ価値をもつのでしょうか。フォントや行間が違えば同じ内容でもページ数は変わります。文字数でカウントしようとしても、絵の多いドキュメントだと、中身は濃いのに文字数は少ないかもしれません。

(2)何をもって「1ページ」が決めがたい

 たとえばDB上の5個のテーブルで保持されている、1つのカラムの桁数を変えようというとき、テーブル定義書を5ページ書き換えることになりますが、それを「5ページ」と数えてしまうと、1から書いたテーブル定義5ページ分と、桁数をちょっとだけ変える5ページ分が、同じということになってしまう。

 ということで、「ページ数」はそう簡単にはメトリクスには使えません。
 となると、やはり見積もり技術にも歴史のある②開発規模と、単純に数えられる③指摘件数 が有力候補になります。

論文を調べてみる

 レビューの定量化に関する論文を拾ってみましょう。
 タイトルは、『レビューの質と価値の定量化の提案』。ソフトウェア品質管理に関する、日科技連の2007年度第1分科会(テーマ:「ソフトウェアプロセス評価・改善」)、グループAの論文です。

 本論文ではレビューを、「価値」(Value)と「質」(Quality)という2つの側面から捉えています。レビューに関して現在普及しているメトリクスが「質」に偏っていることを指摘し、「価値」に関するメトリクスも合わせて提案するものです。

(1)レビューの質

 レビューのプロセスに注目。
 プロセスの良し悪しの要素は、たとえば「レビューの目的・狙いは明確だったか」といったもので、必ずしも定量化しやすいものとはいえません。よって、これらの要素を12項目のチェックリストにし、その配点をもって質の点数としています。

(2)レビューの価値

 ズバリ、レビューの成果を金額に換算。
 この金額を求めるためのパラメタとして、レビューで摘出した不良の修正範囲の広さと発見工程をポイント化します。このポイントに対し、単位ポイントあたりの不良修正時間と、時間単価をかければ、その不良摘出の価値が算出されるというものです。
 各パラメタのポイントや算出式など、若干恣意的な部分もありそうですが、何より直感的に理解しやすく、また計算も簡単であるというところが優れていると思います。