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

ソフトウェア品質の虚像と実像

2013年4月22日 (月)

【雑感】アカデミアとインダストリーの協働すべきポイント

久しぶりのエントリー。しかし単なる雑感(しかも短い)。


ソフトウェア工学分野も産学連携が言われるけれど、定量的管理分野の狭いところを見てもそれが上手くいっていないように思える。

ここ数年においても、バグ密度やテスト密度に触れる経験論文が生まれる一方で、fault-proneモジュール予測に関する研究論文が世に出ている。

これらは、結びついているのだろうか。両立するのであろうか。

一方でバグの数を予想し、もう一方ではバグを含むモジュールを予想する。

確かに両者が組み合わさればお互いを補い合って相乗効果が見込める…のだろうが、そんなに上手く行くのだろうか。

なぜこのような産学の分離が起きているのか考えた方が良いと思う。特に品質が利益に直結するはずのインダストリー側の人は。

この辺りは本当に協働すべきところだと思う。
不可侵条約結んだかのように無いものとして進めるのはもう無理な時期ではないか。

このような定量的管理分野の狭いところを見てるから上手くいっていないように思えるだけなのかもしれないけれど、ソフトウェア工学分野の産学連携、上手くいっていないように思える。


2012年2月13日 (月)

【しつこく信頼度成長曲線】 「どこが信頼度が成長しているの」への回答

信頼度成長曲線。
「どこの何の信頼度が成長しているのか」と皮肉られることがある。

まあ、確かにそう思う。

しかし、成り立ちを考えればこのネーミングに罪はない。
信頼度成長曲線の論理は平均故障間隔の理屈で考えることができる。

時間の推移につれて対象アプリケーションの発見エラーが減っていくことは、時間の推移につれて対象アプリケーションの信頼度が成長していると考えることが可能であるから。

しかし、ではなぜ「どこの何の信頼度が成長しているのか」のような違和感を覚えるのであろうか。

それは、横軸に時間ではなくテストケース実行件数をとって考えるからではないだろうか。
たとえ時間をとっていても、テストケースを元に実行しているという意識が強ければ同様の印象になると思われる。

特に、信頼度成長曲線の対象とするテストの間で、実行するテストの特徴が時間により変化する場合(最初に新機能・中盤結合あたり・後半レグレッション等)に違和感は非常に大きくなるであろう。
しかし、そのような場合は信頼度成長曲線は使えないいと考えるべきであろう。

信頼度成長曲線の特徴をよく知った上で考えれば、少なくとも「どこの何の信頼度が成長しているのか」という言葉は出てこないであろう。

但し、それで実運用上、信頼度成長曲線が実効性の高いツールであるということにはならない。
信頼度成長曲線は色々な意味で曲者であるから。

2012年2月 2日 (木)

【ソフトウェア開発の定量的管理】基準値と目標値

定量的管理において難しいのは、一度基準値を設定すると、開発者は設定前と同じ状態で開発できるわけではないということ。

別に「あるべき数値」になるように開発をするのであるから何ら問題はないと言うこともできる。ナイーブな人ならばそれで納得するであろう。

しかし、少し考えれば、この状態は悲観したくなるだろう。
基準値が目標値になると、統計的コントロールは非常に困難になる。なぜならば一旦定められた目標値に開発者は縛られるのだから。

よって、基準値設定は非常に慎重に行うべきであると考える。

とはいえ、目標値を定め管理することがビジネス上悪いというわけでもない。
単に統計的に妥当な数字ではないというだけのことだ。

定量的管理という点では、目標値という定め方は問題ないが、定量的品質予測という点では、それ以降の管理ができなくなる可能性が非常に高まるであろう。

基準値と目標値・・・同じように使ってしまいがちであるが、厳格に区別して考えるべきものである。

2012年1月17日 (火)

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

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

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

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

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

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

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

となる。

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

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

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

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

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

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

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

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

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

2011年4月 1日 (金)

【成功するプロジェクトマネジメント】そもそも成功とは何だろうか

ソフトウェア開発における成功とは何だろうか。

プロジェクトの失敗原因はリスク管理がまずいからであるとか、見積もりが甘いからであるとか言われたりする。一見信じられそうだが、このような一元的理解は良くない。

プロジェクトの失敗は、本当に見積もりやリスク管理が弱いからなのだろうか。実はその逆で、見積もりやリスク管理がなまじできるから失敗するということはないのだろうか。

リスク管理能力も見積もり能力も弱く心配症だが、弁だけはたつプロマネがいたとする。彼/彼女が、その話術で上手くジャブジャブの計画を認めさせることに成功すれば、そのプロジェクトの成功確率は上がるのではないだろうか。
コストとスケジュールを守れば成功だというのであれば。

しかし、これは真の意味でのソフトウェア開発の成功なのであろうか。

確かにソフトウェア開発をプロジェクトとして考えれば、予算通り計画通りにプロジェクトを終えることが成功なのであろう。
しかし、それはプロジェクトとしての成功なのであって、当該システムを調達するユーザにとって本当に成功なのだろうか。

ソフトウェア開発の失敗を単純に予算や開発期間の超過だけで評価してはいけないのではないだろうか。
もちろん予算も開発期間も大切である。それは当然のことである。

しかし、同じプロジェクトを別々に行ったとして、成功プロジェクト対比、低コストかつ短期間で終えながら失敗プロジェクトというレッテルが貼られるものがある得るのではないだろうか。

つまり、ジャブジャブに予算、コストを積むということは、SIにとっては成功プロジェクトの秘訣かもしれないが、当該システムを調達するユーザにとってはうれしくなどないことであると。

計画通りを是とする傾向がある組織は多いだろうが、ソフトウェア開発の成功は、いわゆるプロジェクトマネジメントの成功とは違うのではないかと言う視点・・・これを持つことは意義あることだと思いませんか。

2011年3月22日 (火)

【信頼度成長曲線again】前段階で後のカーブが予測できるのか

信頼度成長曲線で、曲線の立ち上がりの形がS字であるとか指数型であるとか、使用するモデルの形によって変わり、これが後の累積バグ予測値にも影響していくのであるが、これは現実のプロジェクトに適用するに当たって正しいことであると考えて良いのであろうか。

理論上は正しいであろう。
しかし、現実のプロジェクトにおいては、曲線の立ち上がり時のテストケースの実施順番次第では、実はカーブの形が変わるということはないだろうか。

もし、現実のプロジェクトにおいて、テストケースの消化順によってカーブの特徴が「かなり変わる」と言えるのであれば、そのプロジェクトにおいては信頼度成長曲線を用いるべきではないだろう。
但し、現実のプロジェクトにおいては、このテストケースの消化順によって特徴が変わるというのはそれ程小さくない誤差の範囲で起き得ると思われるので、「かなり変わる」といえるのがどの程度かの見極めは難しいであろう。

「自組織のテスト傾向に合ったカーブを選ぶ」とよく言われる。
しかし、実測データ、特にテスト開始時のバグ立ち上がり時にカーブがフィットすることが本当に正しい将来予測をするのに必要なのであろうか。

2011年3月11日 (金)

【見える化】見える化・視覚化・定量的管理で注意すべきこと

見える化・視覚化・定量的管理といった複雑なソフトウェア開発の管理を容易にする試みがある。
この種類の試みで注意しなければならないことを考える。

見える化・視覚化・定量的管理の実現方法の中で、観察する情報の種類を減らすことで人による理解を容易にするタイプの場合、使用目的・使用者を適切に設計していないと誤用が甚だしくなる可能性があるのではないだろうか。

そして、観察する情報の種類を落としていることに設計者がそもそも気づいていないことが多いのではないだろうか。

複雑なものを容易に理解できるように表すということは、どこかで単純化・省略がなされているということを常に意識した方が良いだろう。
そしてその単純化・省略の程度次第では、本来の目的を達することができないこともありうると考える。

また、実際は重要でない部分に「理解しやすいから」「計測しやすいから」という理由で着目しても悲惨な管理結果になると考えるのだが、個人的にはそういうものが多い気がする。

2011年3月 4日 (金)

【ソフトウェア開発プロセス】プロセス改善策が直ぐに出てくることの是非

ソフトウェア開発を行う組織において、毎期毎にプロセス改善点が提示され、改善されていくという組織。
これは良い組織なのだろうか。

安易に改善策が出過ぎているのではないかと疑う必要はないのであろうか。
メトリクス計測して改善策、障害分析して改善策、プロジェクト総括して改善策…改善策とはそう簡単に出てきて良いものなのだろうか。

これは、単に自分たちが事前に十分考えてから着手していないからではないのかと自問する必要はないのだろうか。
改善策が必要に応じてポンポン出てくるのはダメなことなのではないか。
なぜ「もう改善するところがない。どうしよう」とならないのか。

もちろん、アンテナ貼っているから「ああすれば良いのでは」「そういう手があるのか」という改善策が浮かぶというのは構わない。そうではなく、何か課題に直面した時に、こうすれば良くなると「容易に思いつく」ことは良くないのではないか…、なぜ事前に思いついていなかったのかと考えるべきではないか。

プロセス改善策がポンポン出てくるというのは、その「プロセス改善プロセス」自体を改善する必要があると考えることも必要なのではないか。

2010年9月17日 (金)

【ソフトウェア開発のメトリクス】計測自動化の必要性

【今回はいつも以上の「戯言」度です。その旨ご承知の上お読みください】

ソフトウェア開発におけるメトリクスの計測に自動化は必須と言われるのはなぜであろうか。

計測に手間暇をかけたらリターンを求めたくなるのが人の性である。
しかし、ソフトウェア開発におけるメトリクス管理は、なかなかこの手間暇に報いてくれる結果が得られない。

そうなるとイライラしてしまうもの。

しかし、自動で採れているならば、一瞥して「ふーん」なるほどという程度の使い方もできる。

ソフトウェア開発の品質メトリクスではそれくらいが丁度良いのではないだろうか。
だからソフトウェア開発におけるメトリクスの計測に自動化は必須と言われるのではないだろうか。

メトリクス関連の記述で、「一つのメトリクスのみを信じてはならない」とか「メトリクスで基準値外となっても直ちにダメだと判断するのではなく原因をよく調査する」等を見るが、これは「ふーん」なるほどという程度の使い方を、まじめに表現したもので、同じことを言っていると考えている。

ソフトウェア開発の定量的管理に多くを期待するべきではない・・・と考える(現時点では)。

但し、マッケーブのサイクロマチック数やネストの深さといったコーディングルール的な定量管理は、賛成する。

2010年8月20日 (金)

【定量的管理】信頼度の錯覚

【お断り】信頼度といってもSRGM(ここでそのものズバリの名前を書くと余計に検索にヒットしそうなので4文字語で・・・)の話ではありません。

ここに次の2つのデータがある。
あなたはどちらを取るか。

1.自分が担当したシステムの直近5プロジェクトのデータ

2.権威があるとされている団体が集めた3000件を超えるプロジェクトデータ

胸を張って1.と言えるだろうか。

2.はデータの数は多い。手にした数字をハンドリングすれば統計的処理もできよう。しかし、データの素性が全く分からない。業種、システムに対する要求レベルも様々な組織が提供していると、工数1人月と言ったところで三者三様の計上方法であろう。仮に、団体がデータの正規化をしているかもしれないが、それでも諸々のブレは生じよう。

一方、1.はデータの素性を自分自身がしっかり理解している。
数は少ないが、5つのプロジェクトデータがどのような背景下で収集されたかも知っている。次のプロジェクトでも、5つそれぞれの状況をイメージして数字のコントロールができよう。

こう書いてしまうと、当たり前のように聞こえるのだが、「未だ自プロジェクトのデータがほとんど集まっていないので、○○○の発行しているデータ集の数字を元に基準値を策定する」みたいなことを聞くのはなぜだろう。

権威に頼ることはない。
それは信頼度の錯覚である。

先の問には、即答で「1.自分が担当したシステムの直近5プロジェクトのデータ」と言うようにしたい。