2015年5月
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31            
無料ブログはココログ

« 2010年5月 | トップページ | 2010年7月 »

2010年6月

2010年6月22日 (火)

【定量的評価の肝2】数字になって見えなくなるもの

数字はわかりやすい。
しかし、そのわかりやすさは本当に開発状況をわかりやすく示しているとは限らない。

わかりやすいとは単純化による恩恵であることを忘れてはならない。

そしてその前提にあるソフトウェア開発はもともと複雑な活動であることも。

数字はわかりやすいが、そのわかりやすさで、もっと大事なものを失ってはつまらない。


2010年6月18日 (金)

【定量的評価の肝1】評価より評価後が大切

ソフトウェア開発メトリクスというと、基準値やデータ計測の正確性に目が行きがちであるが、より重要なのは、それをどう役立てるかということ。

テスト密度やバグ摘出密度にしても、基準値の範囲内だからハイOKという使い方は、問われれば「それはよくない」と答えるだろうが、実践上そのように使われていることが多いのではないか。

それをどう役立てるかの視点で考えれば、評価結果より評価後のアクションが大切である。
評価で「テストケースが少ない」「バグ摘出件数が少ない」となったときにどうするか。
その時考える・・・というのでは、せっかく定量的に管理しているのにもったいないと考えるべきである。

テスト前に、テストケースをどう挙げるか、ケース不足となった場合にどうケースを増やすかについて予め考えておけば、メトリクス評価で未達となった場合の対応も、合理的に進めていけよう。

少なくともソフトウェア開発におけるメトリクス管理においては、闇雲に量をこなすことというわけではない。テストであれば何をどのようにテストするかの中身がまず重要であり、その充分性妥当性を別アングルで評価するのがメトリクスであると考えるべきである。

テストケース不足と言われたときに、「いやこれこれの理由でこれで充分」もしくは「これこれの考えに基づいた追加テストケースを作成し実施する」のような合理的な対応を見据えたテストを最初から行うべきである。

「品質保証に足りないと言われた・・・どうしよう」というのは卒業すべきである。
ただし・・・卒業の仕方次第ではある。

2010年6月15日 (火)

【共通フレーム2007第2版改訂情報】「要件」と「要求」の交錯

「共通フレーム2007第2版改訂情報」P13の「、「『要求』と『要件』の概念整理に基づく用語変更」について再び考察する。

第1版P240の「機能要求」が第2版では「機能要件」となっているように、要求と要件では、この改訂に当たっては、「要求」の一部が「要件」に変更になっている。

しかし、1箇所だけ「要件」が「要求」になっているところがある。
第1版P232の「契約の変更要件」が第2版P244の「契約の変更要求」になっている箇所だ。

第2版の定義、
   「要件」は要求プロセスのアウトプットに対して、特に「固まった文書」を
   強調したいときに使う。
から、この変更はわからないでもない。

しかし、開発者にとってはどうでも良いことのようにも思える。
これは「要件」は要求プロセスのアウトプットに対して、特に「固まった文書」を強調したいときに使う・・・という「共通フレーム第2版」の定義は業界に定着するか否かにかかっているだろう。

英語では同じ語である「要求」と「要件」を分けて考えることについて、実際に開発に携わる者たちが必要性を感じるか、加えて感じる場合に「共通フレーム第2版」の定義でしっくりくるか、自然に理解できるかにかかっていよう。

ちなみに、以前のエントリでも書いたが、「共通フレーム第2版」では、次の定義を頭に入れておくことをフレーム使用者に求めている。

-------
①「要求」「要件」は、ともにrequirementの訳語である。
②「要求」を一般的な訳語とする。ただし、「要件」は要求プロセスのアウトプットに対して、特に「固まった文書」を強調したいときに使う。
③「要求」「要件」以前のものを、「ニーズ」という。
 期待(expectation)、要望(desire/wants)、思い(wish)、夢(dream)、
 意図(intension)などは、ニーズの類義語である。
-------

2010年6月11日 (金)

【メトリクスの精度】本末転倒にならないために

手段と目的の取り違え。

ソフトウェア開発品質の定量的管理は、当然開発品質の維持向上が目的であって、管理精度の向上が主目的ではない。
これは忘れがちなので注意が必要。

改めて言うまでもなく、ソフトウェア開発品質の向上が目的であって、ソフトウェア開発品質の定量的管理の向上は、その目的のための手段に過ぎないのだ。

だから、どのようなメトリクスを用いるべきかの議論は大いにすべきであるが、メトリクスの計測精度のみに固執した議論はダメ。

開発規模やテストケース1件の数え方をいかに精度高く定義するかに熱中する前にすべきことがあるではないか。

個々の計測項目の精度以前に、使用するモデル、例えば単純割算のテスト密度の精度はどの程度高いのか考えなくて良いのか。

分母となる開発規模に対してテストケースは単純な比例関係にあると何を根拠に言うのか。あなたはそれが精度高く成り立つと説明出来るか。

モデルの精度を考慮せずにそのモデルで使用する個々の計測項目の精度に固執するのはおかしなことではないか。

このような自問が先ずあって、その上で個々の精度の話が本来はあるべきだと考える。

2010年6月 8日 (火)

【メトリクス活用】基準値未達時の対応

ソフトウェアのメトリクス管理において、基準値未達の場合、如何に対応しているだろうか。

達成自体を目的化していると未達にならないように最初から開発者が調整してしまうということもあろう。

それの是非はともかくとして、未達項目があった場合の対応はどうなっているだろうか。

例えばテストケース足らなければ「じゃあ足すか」となるわけであるが、ではどう足すのかで頭悩ますことはないか。足らないのだから、不十分のはずなのに、メトリクスからは大抵の場合、残念ながら何が不十分かまではわからない。

そもそも論を言えば、基準値未達時の対応は、思い付きでなされるべきではなく、どう対応するかは予め設計されているべきものである。

ここまでのテストは、これこれの理由で実施した。これでは不充分ということであれば、次はこれこれの理由から追加でこれこれのテストを行う…と言うことができるような仕掛けを予め考えておくことが重要である。

但し、これはそもそも論、あるべき論であり、現実は厳しいかもしれない。

しかし考えるべきである。

2010年6月 4日 (金)

【共通フレーム2007第2版改訂情報】「要求」「要件」「ニーズ」の交錯

引き続き「共通フレーム2007第2版改訂情報」について。

P12~13に、「『要求』と『要件』の概念整理に基づく用語変更」として初版と第2版における要求・要件・ニーズに対する変更点が書かれている。

これはちゃんと整理して公開したという点では評価できる。
しかし、内容的にはなぜそのように変えたのだろう、変える必要があったのであろうかと思える箇所もいくつかある。

1.「要求事項」と「要求」と「要件」
 P43「契約上の要求」は「契約上の要求事項」に変更されており、
 P43「システム要求事項」は「システム要件」に変更されている。

 「要求事項」は前者では採用され、後者では否定されている。

2.「要求仕様」は「要件」なのか「仕様」なのか
 P80「要求仕様を反映している」は「要件を反映している」に変更されている。
 P83「要求仕様の変更」は「仕様変更」に変更されている。

 後者はなぜ「要件変更」ではダメだったのであろうか。

上記2つについては何故なのか変更履歴に説明が欲しいところ。

2010年6月 1日 (火)

【共通フレーム2007第2版改訂情報】「要求」「要件」「ニーズ」はなぜ別々に定義される必要があったのか

「共通フレーム2007第2版」について「共通フレーム2007第2版改訂情報」なる資料がIPAのHPで公開されていた(http://sec.ipa.go.jp/publish/index.html#ent)。

気づかなかったのでこれに触れずに「共通フレーム2007第2版」についてななめ読みしてきたが、ここでこの「改訂情報」に触れたい。

「共通フレーム2007第2版改訂情報」P11の背景において「国際標準で使用されている『requirement』の訳語として、要求と要件がある。この2つの用語の概念を整理した上で、『共通フレーム2007』の全文書全般にわたって使用箇所を見直し、適切な訳語を当てはめる」と書かれている。
「国際標準で使用されている『requirement』の訳語として、要求と要件がある」が前提のようになっているようだが、そもそもそれで良いのだろうか。
「ニーズ」という新しい概念まで加えており、要求に関しては国際標準の3倍のバリエーションとなってしまっている。

どうしても定義しないといけないと考えるのであれば、それはそれでよいのであるが、ならば何故旧版の「要求」と「要件」の定義を変える必要があったのであろうか。

「共通フレーム2007」では、「要件」「要求」「ニーズ」の3つについて、国際標準ではなく「共通フレーム2007」独自の定義を頭に入れておけと言っているのである。
それだけでも重要な差異であるのに、旧版から2年で定義を大きく変えてしまうというのでは、「共通フレーム2007」のスタンダードという位置づけとして好ましくないのではないだろうか。

これら定義として、「共通フレーム2007第2版改訂情報」には次のように書かれている。
 

【プロセス共有化WGにおける合意事項】
①「要求」「要件」は、ともにrequirementの訳語である。
②「要求」を一般的な訳語とする。ただし、「要件」は要求プロセスのアウトプットに対して、特に「固まった文書」を強調したいときに使う。
③「要求」「要件」以前のものを、「ニーズ」という。
 期待(expectation)、要望(desire/wants)、思い(wish)、夢(dream)、
 意図(intension)などは、ニーズの類義語である。

さて、②のように、requirementの訳語を「要求」と考えるのであるなら、「要件」「ニーズ」などと新しい語を定義するのではなく、「要求」に対する相対的位置付けを簡潔に記述する方法で定めればよかったのではないか。

詰めは甘いであろうが、例えば次のような感じで。
「要件」の代わりに「要求が固まった文書」とし、
「ニーズ」の代わりに「要求のインプットとなるもの」とする。

このようにすれば「要件」「ニーズ」などという語をわざわざ定義しなくとも良いのではないか。

なぜ国際標準では1つでこと足りる定義を複数定める必要があったのであろうか。
しかも、それを知りながら定め、かつその定義自体を自ら変更してしまう確信犯。

どうしても定義が必要だというのであれば、なぜそのようにする必要があるのかについての説明が必要であろう。
しかし、この理由がどこにあるのか、「共通フレーム2007第2版」だけでなく、「共通フレーム2007第2版改訂情報」においても分からなかった。

「共通フレーム2007」は、多くの人に共通認識のための定義として使ってもらうことを目的としていたはずである。
だから、定義すれば良いというものではないと思うのだが・・・。

« 2010年5月 | トップページ | 2010年7月 »