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

ソフトウェアの品質、ソフトウェアテストなどについて学んだことを記録するブログです。

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

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

簡単に思いつくもの

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

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

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

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

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

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

(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)レビューの価値

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