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

« 2011年7月 | トップページ | 2012年2月 »

2012年1月

2012年1月30日 (月)

【続定量的品質予測のススメ】 プロジェクト品質目標の伸縮

P61「統計値は、過去のプロジェクトの実績を統計分析して得られた値であるから、たとえ同一プロジェクトでもそのまま現在のプロジェクトの目標として設定すべきではない」とある。

「たとえ同一プロジェクトでも」の部分の取り扱いは難しい。

現在実施しているプロジェクトの現時点までの実績は、そのままの形では統計値としてこれ以降のプロジェクトを進めるにあたっての目標値としてそのまま使用してはならないと言っている(と取れる)。

言いたいことは分かる。
同一プロジェクト中の小単位の中にも統計的観点で見た場合には様々な差異があるということだろう。
しかし、そもそもソフトウェアは同一の製品を作っているわけではない。差異を言い出したらキリがないのではない。この論法では、最終的にはコマンドごとに目標値を定めるとかいう次元に行きつくのではないだろうか。

そもそもだからこそ統計的に語っているはずである。

とはいえ、解決策が示されていれば主張することは構わないので、本書で示されている解決策をみると次のようになっている。

「現在のプロジェクトメンバのスキル、技術的な難易度、規模、工期、開発環境などの諸条件のなかで、特に変化した特徴的な部分があれば、その影響度を統計値に加味し、妥当性、納得性のある目標値を設定することが大切である」

どうだろう。
やろうとしていることは、プロジェクト目標値では不十分だからプロジェクト内の細分化された小単位の中での目標値を定めようということだろう。
であれば、その影響度は統計的に定められなければ意味がない。

よって、「その影響度を統計値に加味し」とあるが、これは「その影響度を統計的に加味し」とした方が良いと思われる。

現在のプロジェクトメンバのスキル、技術的な難易度、規模、工期、開発環境などの諸条件の差は、統計的に表現される必要がある。
そうでなければ、せっかくの統計的に算出したプロジェクトの目標値が台無しになるだろう。

「妥当性、納得性のある目標値」を算出するのに、プロジェクトメンバのスキルを松竹梅、技術的な難易度を高中低、規模を大中小、工期を長並短、開発環境を良並悪などというぶっちゃけた影響度を加算するのでは、(アバウトながら)精度は下手したら2ケタ落ちるだろう。

よって、この詳細な目標値設定方法に、定量的品質予測を希望する組織は頭を悩ませ答えを求めるのである。

しかし、残念ながら本書では、肝心のその算出方法が書かれていない。
これこそまさに企業秘密であり、競争の源泉だから書かれていなくとも仕方がないと思わねばならない。残念ながら。

2012年1月26日 (木)

【続定量的品質予測のススメ】 プロジェクト品質目標

P60~61「適切な目標設定」について。

前半は、定量的品質管理における品質目標のあるべき姿について書かれている。
これはあるべき姿なので、そんなに簡単にできるのだろうかということはあるがそのままスルーする。

P61頭では
「実績データから得られた統計値に対し、品質目標は、
  ①実際のプロジェクトの特徴を分析して得た所見
  ②プロジェクトとしての到達意欲
の2つを加味して設定する。
」とある。

定量的品質目標と定性的品質目標を合わせた場合には、これはそのまま受け入れられよう。
しかし、本記述は定量的品質管理に関するものである。
定量的に意味のある①②とは何かを考える必要があろう。

本書では、これにつきページを割いて解説されているので、よく読み自組織でよく考えて対応すべきであろう。
プロジェクト目標値の設定…これは本当に難しいことであると思うから。

個人的には、プロジェクト目標値の設定は純粋に定量的方法で行うべきで、定性的なニュアンスを入れてはいけないと思う。しかし、それは非常に難しいと思う。

プロジェクト目標値の導入は理解はできる。しかし、現実にはしない方が良いのではと考える。
プロジェクト目標値を導入して上下限値幅を狭めようとするより広いままでよいのではないかと思うのである。

2012年1月23日 (月)

【続定量的品質予測のススメ】 「できるだけ客観性があり」の良否

P42 「2)リスクの評価手順」の「手順1)システムリスクの評価」において「評価方法は、できるだけ客観性があり」と書かれている。

これは「手順2)プロジェクトリスクの評価」においても書かれている。

客観性は「できるだけ」で良いのだろうかという疑問が生じる。
しかし、この場合は良いと考えられる。

ここではリスクを取り扱っており、かつ評価方法の例として、
「④各要素の状況(値)と重み(値)の乗算結果を合計し、総合評価(ランク付け)する」
とあるように、そもそも客観性を精緻に捉えることは必要と考えていない。

よって「できるだけ」で構わないのである。
しかし、そもそもこれはいわゆる「定性的リスク管理」の方法の説明であり、なぜこれが定量的品質予測のガイド本に詳細に書かれているのかはよく分からない。

2012年1月17日 (火)

【又々信頼度成長曲線】「同じテストを繰り返せば曲線は収束するよね」が本質なのか

ISSRE2011のIndustry Papers発表にてTakeo Niwaさんが信頼度成長曲線について発表していた内容を記しておく。

<発表概要 始>------
横軸が実行済みテストケース数の場合における信頼度成長曲線収束の意味についての発表。

立ち上がりや収束の振る舞いといった曲線の傾向がテスターの恣意やテストケースの実行順に由来するものでない場合、あるテストケーススイートにおける曲線の傾向は、テストケースの実行順に関わらず同一であるはずとし、その上で次のような思考実験を行っていた。

対象テストケーススイートの中で、全てのエラーが、
  ①各々1つのテストケースでしか発見できない場合
  ②各々2つのテストケースで発見できる場合
  ③各々3つのテストケースで発見できる場合
  ④各々N+1つのテストケースで発見できる場合

に、テストケーススイート中のテストケースを乱数を用いてランダムに順序付けして実行した場合に得られる信頼度成長曲線は、それぞれ、

  ①直線
  ②収束しつつあるように見える曲線
  ③②よりもより収束しているように見える曲線
  ④Nつのテストケースの場合よりもより収束しているように見える曲線

となる。

以上から、信頼度成長曲線の傾向がテスターの恣意やテストケースの実施順に由来するものでない場合、エラーを発見できるテストケースに重複があれば、曲線は収束傾向を示し、テストケースが重複するエラーの数が多いほど、また個々のエラーに対し重複するテストケースの数が多いほど、早期かつ明瞭な収束となると言える。

これは、他に曲線が収束する要因があるか否かに関わらず成り立つ。

よって、信頼度成長曲線におけるテスト十分性の要素の1つとして「テストする内容が複数のテストケースで重複していること」があると言える。

ではこの「重複していること」のテスト十分性における意味は何であろうか。
重複していることが、テスト十分性の観点から良いことであるならば、極端な話、同じテストケースを何度も繰り返せば良いことになるし、現にそれで収束していくだろう。しかし本当にそれで良いのであろうか。

<発表概要 終>------

最後の部分は問いかけで終わっており、発表内では答えは示されなかったのですが、どうなのでしょう。

確かに、過去、「テストケースを3回回せ。そうすれば収束する」みたいなことを言うコンサルもみたことがありますので、重複が重要と言う人もいるとは思いますが、違和感を覚えます。

発表では、まず最初に「信頼度成長曲線が活用されることは多いが、直観的に理解しているだけでなぜ傾きが寝ると信頼度が上がるのかを論理的に説明できる人は少ない」とも言われていた。

これは皆様どう思われますか。

【事務連絡】再開します

長期にわたり更新しませんでしたが、ゆっくり再開します。

最初はやはりというか、信頼度成長曲線です。
これについては、今まで否定的もしくはうがった見方ばかりしてきましたが、実は非常に味わい深く面白い玩具です。

« 2011年7月 | トップページ | 2012年2月 »