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

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

2012年2月

2012年2月27日 (月)

【続定量的品質予測のススメ】 正確な科学的・定量的分析の例は何があるのだろうか

P79「5.1 品質分析の実施」において「一般には、プロジェクトの規模が大きい場合には、人間の直感よりも科学的・定量的分析結果の方がより正確である」とある。

これは、広く工学分野の一般論としては正しいであろう。
しかし、だからといってソフトウェア工学分野の現状において当てはまるとは限らないのではないか。

そもそも、ソフトウェア工学における科学的・定量的分析とは何か。
本書に書かれている様々な定量的手法が全て当てはまると考えて良いのか。

バグ密度、テストケース密度、信頼度成長曲線は、人間の直感よりも正確な科学的・定量的アプローチと言えるのだろうか。

未だ科学的・定量的アプローチというのは私は引っかかる。
あくまで個人的な感想だけれど。

2012年2月23日 (木)

【続定量的品質予測のススメ】定量的情報活用の目的

P78「5.1 品質分析の実施」において上流工程の人間系対策を適宜迅速に判断するために、「定性情報に加え、分析の客観性を高め、精度の高い判断を行うために、『定量情報』も駆使する。すなわち、定性情報と定量情報を組み合わせて判断することが、本質的に重要である」とある。

後半はそうだと思う。
前半はどうだろうか。

定量的情報は、分析の客観性を高め、精度の高い判断を行うことに資するのであろうか。
そのような考えもあると思うが、一方で、定量的管理は、対象のうちのある特徴に着目して、それ以外を捨象して評価するものであるから、分析の客観性を高めることや、精度の高さというより、着目した特徴を誇張的に示すものであるという考え方もできる。

どちらもありうる考えだと思うが、前者で考える方が、定量的管理に対し信を置く割合が高い考え方であると思われる。

2012年2月20日 (月)

【続定量的品質予測のススメ】人間の主観に基づくもの

P67「4.2 データの測定・収集の省力化と品質確保」において「上流工程で測定・収集するデータは、基本的に人間の主観に基づくものが多いため、品質管理部門等で当初意図した測定内容にならないことが多い」とある。

では、下流工程で測定・収集するデータは、人間の主観に基づくものが少ないのであろうか。
例示がないので真に何を指しているのかは分からないが、下流工程のテストケースの挙げ方や、テスト実行時間に主観的要素は無視できるほど小さいのであろうか。

本書で挙げているバグ密度、テストケース密度にも主観的要素が絡むからこそむずかしいのではないかと思うのだが。
ここでいう「主観に基づく」の意味を間違ってとらえている可能性はあるが、下流でも主観に基づいたデータは多いと考える。

対象物を客観的に測る術が今のところ公にはないソフトウェア開発においては、主観の要素が入り込むのは仕方がないことだと思うしかないのではないだろうか。

2012年2月16日 (木)

【続定量的品質予測のススメ】正確で不変で安定で

P66「4.1 定量的品質管理の前提条件」において「データはできるだけ正確にタイムリーに測定・収集することが求められる」とある。また「データの測定対象・測定方法は、不変で安定していることが必須である」とある。

後者はその通りであろう。

では前者はどうだろうか。
「データはできるだけタイムリーに測定・収集」は良いと思う。
ただし、「データはできるだけ正確に測定・収集」が引っかかる、

体重測るのにミリグラムまで測るだろうか。
稼働時間を測るのにミリ秒まで測るだろうか。

細かすぎる突っ込みのように思えるかもしれないが、このあたりに敏感になることこそが定量的管理には必要だと考える。

やみくもに正確さを追及することが正しいというのであれば、そこで得られる結果は単なる参考値とするには惜しい。そのメトリクス一発でプロジェクトもしくはプロダクトの是非を判断できるくらいのものであるべきではないだろうか。

2012年2月13日 (月)

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

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

まあ、確かにそう思う。

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

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

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

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

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

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

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

2012年2月 9日 (木)

【続定量的品質予測のススメ】 品質目標の汎化と層別化

品質目標の設定は難しい。

定性的目標は、まあ良い(個人的興味の問題かもしれないけれど)。
問題は定量的目標の方。

P62には「品質目標を設定するたびに、実施プロジェクトごとにその特性に合った品質目標を算出するよりも、過去の類似プロジェクトの実績を参考にして設定する方が効率的である」とある。

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

P62の記述は、品質目標の汎化を、P61の記述はその層別化を言っているように思える。

これは繋がるのだろうか。

「実施プロジェクトごとに・・・算出するよりも、過去の類似プロジェクトの実績を参考にして設定する方が効率的である」のだけれども「同一プロジェクトでもそのまま現在のプロジェクトの目標として設定すべきではない」というのは、どう理解すればよいのだろうか。

細かい設定をしたいのならば・・・、したいのならば・・・ですよ(なぜか丁寧語)、それならば最初からプロジェクト毎に算出した方が良いように思うのだが・・・。

品質目標の設定は難しい。

2012年2月 6日 (月)

【続定量的品質予測のススメ】 品質目標にコミットするということ

品質目標を設定する際に大事なことの1つとして、P61「設定した品質目標に対し、関係者全員(特に、プロジェクトメンバ)がコミットしていること(納得し、合意していること)」とある。

目標なのだから、共有し達成に向かい手を尽くすのは当たり前だろう。

しかし、その目標のメンテナンスは不要なのだろうか。
メンテナンスはどのように行うのであろうか。

このように「目標」として達成目指して推進されて得られた実績データが一定数集まったらそれを元に「統計的に」処理して新たな目標を定めれば良いのだろうか。

生産性ならそれも良いだろう。
品質メトリクスもそれで良いのだろうか。バグ密度やテストケース密度は過去の「目標」に向かって勧められたプロジェクトから得られた実績データを使って統計処理することに何の違和感もないだろうか。

品質目標は、一度定めると縛られる魔物。
だからと言って悪者ではない。

それがどのような意味を持つかよく考えて扱うべきであり、定量的だから統計的と考えて「正しい値」と思いこまずに活用すれば良いのである。

しかし、ここを混同してしまう人は多い。

2012年2月 2日 (木)

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

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

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

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

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

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

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

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

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