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年1月 | トップページ | 2011年3月 »

2011年2月

2011年2月22日 (火)

【ゾーン分析④】次元を増やしたら?

ゾーン分析の長所は、関連のある2つのメトリクスを組み合わせて評価することである。
これによりそれぞれを単独で評価するよりも真実の状況/状態を見ることができるというものである。

ならば、もっと次元を上げて3次元、4次元とすればより良いといえそうであるが、あまりみない(というか経験不足の私は見たことがない)。

人が理解できるのはせいぜい3次元で、一般的には2次元程度が良いということなのだろう。

しかし、次元をもっともっと増やしてコンピュータで解析すれば良いと思う。そうすれば意外な事実が見えるのではないだろうか。

とはいえ、ソフトウェア開発のメトリクス管理においては、残念ながらそれをする価値のある良質のデータを収集することが難しいのではないだろうか。
それに値するデータを有すると言われる方/組織は、ぜひ3次元以上のゾーン分析にチャレンジしていただきたい。

面白いとは思います。

2011年2月18日 (金)

【用語の名称統一】定義すればバラ色なわけではない

以前既に類似の内容を書いたが、再度。

開発に関わる用語の統一。
たとえばウォーターフォール開発の工程を様々な会社が参加しているプロジェクト参加者間で統一すること。

その重要性は理解できる。
同じ名称の語が、利害関係者で異なる意味で理解されると開発に悪影響を与える可能性が非常に高いと容易に想像できるから。

そして、これをいっそのこと業界内で統一してしまえば業界として非常に有益であろうということも理解しやすい。

しかし、だからといってそれを思いつた人が「これが統一定義なので以後これに基づいて使用するように」といっても統一されない。統一することが今の自組織の直接の利益となる理由を見出さないと使うモチベーションは上がらないであろう。
逆に自組織の直接の利益となる理由があれば、速やかに統一標準化が進むであろう。
この理由から、開発技術の統一は実施可能性は比較的高いが、開発プロセスの統一の実現可能性は高くなり難いであろう。

さらには、これら統一定義が関連業界内で複数出された場合、そもそもの趣旨に反するわけであるが、いったん複数出されたら、それを統合するのはかなりの困難を要するだろう。そして現実にこのような例は少なくない。

再度、単一の開発プロジェクトでの統一定義に立ち返る。
この場合は、開発プロジェクトを主導する組織が標準を定めることになるだろう。
しかし、これは統一されるとはいえ、人を長期間固定する開発でないのであれば、統一による利益と教育徹底の程度、そのコストを考えると楽観視はできないのではないだろうか。

2011年2月15日 (火)

【ゾーン分析③】本当に分析を容易にするツールなのか

テスト密度-バグ密度のゾーン分析は、テストの状況把握を容易にするようで、実は逆に把握の難易度を上るツールなのではないだろうか。

真ん中のゾーンに来る場合には、次の2つがある。

①テスト対象の品質が標準的で、かつテストケースの挙げ方も標準的
②テスト対象の品質が悪く、かつテストケースの挙げ方が良くないがケース数は標準的

①に来たからと言って安心できないとなるとどうすれば良いのだろう。
結局、他の評価を行って①か②か判別するのであろうが、単純にテスト密度、バグ密度別々に評価した方がラクではないだろうか。

これは分析が高度になって良いことであるというべきなのだろうか。
複数メトリクスを組み合わせることで管理精度を上げるというのは、非常に難しいことであると思うのであるが・・・。
例えば、3つのメトリクスを用いたゾーン分析となると、もはや把握不能となるのではないだろうか。

ところで、教科書等では、真ん中のゾーンに来る場合には①しか挙げていないことが多い。なぜだろうか。品質が悪くかつテストケースの挙げ方が良くないという2重の不良は起きないという前提なのだろうか。

2011年2月11日 (金)

【ゾーン分析②】その魔力

ゾーン分析は、信頼度成長曲線と同じく理論の直観的理解は容易なのだが、運用にあたっては、なかなか悩ましく難度の高いツールだと考える。

たとえば、真ん中のゾーンに来るとは良いと言われる一方、テスト密度が十分でバグ密度が少ないゾーンの場合、「テスト対象の品質が非常に良いか、テストケースの挙げ方が良くない」のように評価される。

「テスト対象の品質が悪く、かつテストケースの挙げ方が悪い」というのは、テストとして最悪の状況だと思うが、恐ろしいことに、この場合に真ん中のゾーンとなっている可能性がある。
2つのメトリクスを複合的に見ることができるという最大の長所が短所となることもある。

そしてこれが、ありえないほど稀なことではないと思うのだが…。

メトリクスはリスクの気づきを与えるものであるから、良い可能性もあるが悪い可能性もあれば、念のため調べることに意味はある…という考え方はもちろんある。

しかし、それをわざわざ定量的に行う必要があるのであろうか。
定量的に、「ダメな可能性があるから、問題ないことを良く調査しよう」ということが分かったとして、その調査が定性的に行われるのであれば、最初から定性的調査を必須にすれば済むことではないだろうか。
また、別なメトリクスを用いて定量的に行われるのであれば、何も前段階としてゾーン分析をするのではなく、その別なメトリクスで最初から判断すれば良いだけである。

ゾーン分析は、一般的に言えば、良いツールであることを認めるが、バグ密度-テスト密度のゾーン分析に限って言うと、結局9つのゾーン全てでダメな可能性があるという話になるので利用価値は低いのではないかと思う。

定性的に次のことが言えれば、このゾーン分析図は不要であると思える。
  ・テストケースは合理的にテストすべき事項を網羅している
  ・テストで見つかったバグ対応は次工程に進むことに懸念を残していない
そして、これらを考慮したテスト工程を実施せずして定量的管理を行うというのは愚かなこととしか思えない。

では、ゾーン分析は不要なのか。
そうとまでは言えない。
信頼度成長曲線と同じく理論の直観的理解は容易なので、顧客や上位経営層宛ての説明に使用することは良いのではないかと考えるから。

2011年2月 8日 (火)

【ゾーン分析①】その魅力

ゾーン分析図。
ソフトウェア開発品質の分析においてはテスト密度とバグ密度のものが代表的活用例。

2つの異なるメトリクスの基準値達成/未達の評価を同時に行い視覚化するツールである。個々のメトリクスの下限値未満/基準値範囲内/上限値超過という3つの品質状態をそれぞれのメトリクスで組み合わせ、都合3×3=9のゾーンに分けることで、2つのメトリクスの視点を用いて複合的に品質状態を把握しようとするものである。

信頼度成長曲線と同じく理論の直観的理解は容易なのだが、運用にあたっては、なかなか悩ましいツールだと考える。

2011年2月 4日 (金)

【可視化の罠】散布図やバグ増加実績に沿った線

散布図書いてみたら本当に砂粒撒いたみたいになったときに、絶対やってはならないことがある。
それは取り合えず線を引くこと。
線があると、直線であれ曲線であれ、人はそれに捉われる。
見える化は、それをプラスに活用しようというもので、これ自体悪いことではない。

散布図に限らず、直線/曲線に乗ると教科書等に載っていたからと、何も考えずにモデルを適用しては危険だ。自分たちのケースにはあてはまらない特殊要因があるかもしれないからだ。
教科書等の記述はピンキリで、前提条件・モデルの仮定がちゃんと書かれているものからそうでないものまで色々ある。活用に当たっては十分注意が必要である。

また、これら図を自動描画してくれるツールも現在はたくさんある。
しかしこれも使い方が重要である。

散布図描画と共に線を引いてくれちゃうツール。既に書いた通り線があると判断を誤る可能性が増大するのだが、データを入力すると自動で描画されてしまうようなツールでは、考える暇なく頭に直線/曲線が刷り込まれてしまうリスクがあると考える。

個人的には直線/曲線などない図を十分眺めたあと、近似された直線/曲線を加えてみて、その直線/曲線が基にする前提/仮定を考慮した上で評価するという方法を採るべきと考える。

2011年2月 1日 (火)

【定量的管理随想】定量的管理の目的とソフトウェア開発の目的

ソフトウェア開発において定量的管理を行う理由は何であろうか。

品質および生産性の粒を一定水準以上に揃えるため?
これはその通りだろう。

しかし、そもそも我々は定量的管理を行うためにソフトウェア開発を行うものではない。我々の第一の目的は、よいソフトウェアを開発することである。

もちろん品質/生産性も「よい」の1要素である。
しかし全てではない。

また、品質/生産性を担保するのは定量的管理のみではないし、定量的管理が一番効果的と言うわけでもない。

さて、以上を踏まえて敢えて考えたい。
定量的管理が品質/生産性を悪化させているという逆説は成立しないだろうか。

開発者が定量的管理を意識することにより、創造性を阻害されるということはないのだろうか。
開発者は定量的管理を意識する必要はない、その成果物を検証する者が意識すればよい。だから創造性は阻害されない…という考えが建前としてはあるが、実際のところ、開発者はあらかじめ適用される定量的管理の内容を知っている。それを推奨する考えもある(私もそう考える)。

しかし、それはやはり開発者の創造性を委縮させているのではないだろうか。

開発者には開発の本質に集中させるべきで、定量的管理を意識させるべきではないのではないか。

この問題については以前から考えているが私の中では答えが見つかっていない。

« 2011年1月 | トップページ | 2011年3月 »