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

2011年3月

2011年3月29日 (火)

【想定外のリスク】想定外の想定外たるゆえん

想定外のリスクという場合の「想定外」とは何であろうか。

2種類あると考える。
ひとつは対象を考えてはいたがここまでという範囲を超えるもの。
もうひとつは、対象を考えてさえいなかったもの。

両者はまったく別物であると思われるが、リスクを考える場合、どちらがより。致命的なのであろうか。

直観的に後者の方が良くないと思えるが、しかし考えててさえいないものを考えることはどうすればよいのだろうかという根本的課題がある。

このあたり、リスク検討者は意識する必要があると考える。

2011年3月25日 (金)

【ソフトウェアの値付け①】なぜ生産性なのか

ソフトウェアの妥当な値段とは何か。
これに対して普遍的に活用できる方法は現在のところない。

「分かりやすい」という点で工数に基づく値付けが一般化している。
しかし、投入工数で値付けというのは、先端技術であり、開発者の英知を結集して作られているはずのソフトウェア開発に対する方法としては少々お粗末な感は否めない(先端技術であり、開発者の英知を結集して・・・は現実にはそうでもないかもしれないが)。

この課題は、先人が既に考えてきているにも関わらず、未だ解が見つかっていないわけであるが、解が見つからない可能性が高いからといって、これについて考えることに意味がないとは思わない。

そう考え、ソフトウェアの値付けについて改めて考えてみたい。

そもそも、値付けの話になぜ人月が出てくるのだろうか。
人月で考えるということは生産性という考えが裏にある。しかし、1つのソフトウェア内に重複した部分などあってはならないはずなのに、どうして開発の粒がそろっているかのような前提を置くのであろうか。

2011年3月22日 (火)

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

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

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

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

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

2011年3月18日 (金)

【深淵なるソフトウェア定量的管理再考②】ゾーン分析

信頼度成長曲線の次は、ゾーン分析について考えてみる。

ゾーン分析では、単一では品質判断が心もとないソフトウェア開発のメトリクス評価への対策の1つとして活用されている。

仕掛けとして良いと思われる。単一ではなく関連する複数のメトリクスを複合的に用いた評価を行うことはより精度高い定量的評価が可能になると思われる。

しかし、単一で心もとないものは高々2つ組み合わせれば劇的に評価の精度が上がるのだろうか。

もし上がるのであれば、2次よりもより高次の組み合わせを行った方が良いのではないかと考えられないか。
とはいえ5次元のゾーン分析やn次元ゾーン分析の話はメジャーとは言えない。

これは何故であろうか。

推測であるが、2次元は人が理解しやすいからではないだろうか。
3次元では立体になるので頭の中での理解が途端に難しくなり、4次元以上となると大抵の人が把握不能になるだろう。

故に2次元。
しかし、2次元では精度の幅がそれ程上がるのであろうか。
よく見かける、バグ密度とテスト密度のゾーン分析では、真ん中のゾーンに入ってさえも安心できないかもしれないと書かれている場合もあって、結局ゾーン分析した後で定性的分析を行わねばならないこととなっている。

単一では品質判断が心もとないソフトウェア開発のメトリクスを、2つまとめて評価しても劇的に評価の信頼度が増すわけではないのである。残念ながら。

2011年3月15日 (火)

【深淵なるソフトウェア定量的管理再考①】バグ曲線

ソフトウェア開発における定量的管理の奥深さとその奥深さに対する開発現場の姿勢について改めて考えてみたい。
考えるにあたっては、バグ曲線とゾーン分析を用いたい。

バグ曲線。
これは「事実の記録」としては正しいものだろう。
また、個々のプロジェクト毎の曲線のみについて分析することも有効だと考える。

しかし、これを複数プロジェクトの計測結果を基にした統計的処理を考えたり、そこまでは言わないまでも、複数プロジェクトの曲線間の共通の法則のようなことを考えるとなると、途端に色々なモデル上の前提・仮定やノイズについて考える必要が出てくる(この辺りは過去のエントリご参照)。

しかし、現場ではこのような難しい事項に対し考慮不足のまま走っているように思える。
例えば、実際のバグ曲線とモデルから描画される信頼度成長曲線を比べたりということをモデルの前提・仮定を顧みることなく行っている組織が多いのではないだろうか。

また、バグ曲線の横軸についても、実施テストケース累積数を採った方が、日付やテストへの投入時間とするよりも良いという考え方が提示されている。確かにその考えも理解できる。しかし日付やテストへの投入時間の方が劣っていると一概に言えないのではないだろうか。
日付は1日あたりのテスト件数のばらつきが多いことやテストを実施しない日の取り扱いが欠点/課題とされるし、テストへの投入時間の場合もテスト1件のテスト投入時間のばらつきが言われる。しかし、これは日付や経過時間といった時間に着目しているから出てくる当然の課題だと考えられないか。

優れていると言われるテスト件数を横軸にとった場合にこれらに相当する程度の欠点はないだろうか。
日付や経過時間の場合には時間に着目し欠点が挙げられるので、テスト件数の場合はテストケースに着目した欠点があるのではないだろうか。
それぞれのテストケース1件とは、テスト対象の規模に対して同じ価値のテストがされるのであろうか。1件のテストに対し確認されるFPやSLOC数は同じなのだろうか。同じでなくて良いのであろうか。

日付や経過時間は時間に付随した欠点があるから実施テストケース累積数の方が良いという考え方を採用する組織が多いように思われるが、そのような判断においてテストケース数の重みに関する欠点についての検討は十分なされているのであろうか。

信頼度成長曲線の横軸は、日付や経過時間は時間の場合と実施テストケース累積数の場合とでは、見たい傾向が異なるので優劣の話ではなく、両方採用すれば良いのではないかと考える。

日付や経過時間は、収束するには、あとどの程度の日数、時間テストを行う必要があるかを見るもので、実施テストケース累積数は、収束するには、あとどの程度のテストケースを実施する必要があるかを見るものと考えれば優劣をつけるべきものではないと考えられるのではないだろうか。

(…と書いたが、個人的にはどちらも大した予測はできないと考えている。上記は信頼度成長曲線を使うのであれば、検討した方が良いのではないかというものを客観的視点で書いたものである)

2011年3月11日 (金)

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

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

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

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

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

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

2011年3月 8日 (火)

【ソフトウェアメトリクスの基準値】ネジの基準値とソフトウェアの基準値

ネジの基準値とソフトウェアの基準値。
ネジの場合は基準値にこだわることが品質を維持することに直結している。
一方でSW開発業界では1つの指標だけで品質を判断してはならないというようなことが言われる。
この差はどこから来るのか。
そのメトリクスが対象物の品質に直結しているか否かにあるのではないか。
ネジはそこにあることが分かるが、ソフトウェアはここにあるかを直接知ることができない。
長さが基準値を超えたネジはダメなネジと即答できるが、バグ密度が一定数以上のソフトウェアがバグフィックス後にダメなソフトであるかは即答できない。
隔靴掻痒。
ネジを作るのに1個当たり何秒の検査時間をかけたかなんて測りもしないだろうし何パターンのテストをしたかなども測らないだろう。測るパターンは予め決まっているのだから。よしんば測ったとしても、それは品質のためではなく生産性のためだろう。
そもそも、ネジは基準から外れたら即アウトであるのに、ソフトウェアは一定範囲内のバグは出てこないといけないという点で大きく異なる。
バグが出てもフィックスされれば問題ないというロジックもネジのメトリクス管理からは理解できないだろう。
 
このあたりの違いに何かソフトウェアの品質に関するヒントが潜んでいないだろうか。

2011年3月 4日 (金)

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

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

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

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

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

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

2011年3月 1日 (火)

【リスク管理】リスク定量化の悩ましさ

リスク管理。
ソフトウェア開発のプロジェクトマネジメントにおいて、必須の管理項目である。
リスク項目を挙げた上で、定性的管理することの重要性は理解できる。

しかし、リスクを数値化して定量的管理を行うことは理解できない。
リスクは管理者がその頭で考えたものであって、客観的にそこにあるものではない。

何が言いたいのか。
リスクには、挙げられていないリスクもあるはずなのである。
それはひょっとしたら管理者/開発者が想像できないもしくはミスにより漏らしたものかもしれない。

漏らしたリスクがあることは仕方がない。
リスクは人が挙げるものであるのだから。
定性的管理においては、気付いた時点で挙げて管理すればよいので問題はないもしくは小さいと思われる。

しかし、リスクの定量的管理においてはこれは致命的ではないだろうか。
本来挙げるべきリスクが挙げられられないままに算出された定量的リスク量にはどのような意味があるのだろうか。

リスクを全部挙げれば良いではないか、そうするようなチェックリストを作れば良いのではないか…という性質のものではないのでリスクは悩ましいのである。

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