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            
無料ブログはココログ

« 【定量的品質予測のススメ】ソフトウェア信頼度成長モデルの横軸は何を取ると良いか | トップページ | 【ソフトウェア品質の定量的管理とは①】何のために計測するのか »

2008年12月26日 (金)

【定量的品質予測のススメ】測定項目はどう定めるべきか

P38「(a)測定項目の一覧表をもとにした測定とデータの精査」において「測定項目の一覧表を作り「(b)測定データの一元化と正規化」において「複数の測定項目から意味のありそうな項目を集計(一元化)する」とある。

一方、P28「品質予測の実際」には「以下に紹介する測定項目や分析を全て行うのではなく、効果に見合った測定・分析コストだけをかけるようにしていただきたい」とある。

この2つの記述は両立できるのだろうか。

「複数の測定項目から意味のありそうな項目を集計(一元化)する」というのは、測定時はこの項目を使って管理を使用と確信しているわけではないということを意味するであろう。

一方で、「測定項目や分析を全て行うのではなく、効果に見合った測定・分析コストだけをかけるようにしていただきたい」というのは、意味の有りそうな項目を事前に絞ってから測定を始めよと言っている。

これを矛盾と呼んでよいのであろうか。

書籍としての一貫性の観点からは矛盾といってよいであろう。

しかし、2つの記述はそれぞれ真であるとも言える。

昨今の開発環境の進歩は目覚しいものがある。
単体テストは自動でするものというのが常識の開発者も多いであろう。

しかし、一方で、未だ昔ながらのシステムの子守りをしている開発者も多い。
彼らには、単体テスト自動化といってもピンとこないであろう。

そもそも、旧来のシステムにおける単体テストは、昨今の開発者から見たら「それは結合テストでしょう」というものばかりであろう。

この旧来のシステム開発者に取っては、測定項目の追加は即ち「コストの増加」なのである。
彼らにとっては、「測定項目や分析を全て行うのではなく、効果に見合った測定・分析コストだけをかけるようにしていただきたい」というのは、真なのである。

一方、昨今の恵まれた開発環境の開発者にとっては、単体テストだけでなく、開発の生産性項目・品質項目に関わらず、様々な項目が「勝手に」自動化されて取られてしまう状況にある。
彼らにとっては、勝手にあらゆる項目を自動収集されるわけだから、「複数の測定項目から意味のありそうな項目を集計(一元化)する」というのは、真なのである。

このように、相反する記述はそれぞれ立場によっては正しいのである。
しかし、この「立場によっては」という語を外して提示されると、やはり違和感を感じるであろうし、それが正常な反応である。

本書が、この内部矛盾を意図的にしているのであれば、できればそれが分かるようにガイドしてあげる必要があろう。

そうでなければ、P38だけ読んだ人と、P28だけ読んだ人で、同じ本を読んでいるのに測定項目に対する考え方が反対になってしまう危険性がある。
両方読んだら読んだで、あれ、と悩むことになるのだが。

« 【定量的品質予測のススメ】ソフトウェア信頼度成長モデルの横軸は何を取ると良いか | トップページ | 【ソフトウェア品質の定量的管理とは①】何のために計測するのか »

定量的品質予測のススメ」カテゴリの記事

コメント

コメントを書く

(ウェブ上には掲載しません)

トラックバック

この記事のトラックバックURL:
http://app.f.cocolog-nifty.com/t/trackback/1048600/25961894

この記事へのトラックバック一覧です: 【定量的品質予測のススメ】測定項目はどう定めるべきか:

« 【定量的品質予測のススメ】ソフトウェア信頼度成長モデルの横軸は何を取ると良いか | トップページ | 【ソフトウェア品質の定量的管理とは①】何のために計測するのか »