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

ソフトウェア開発品質・生産性私見

2014年6月11日 (水)

【定量的管理の疑問点】バグ摘出密度へのu管理図の適用

さて、再度バグ摘出密度について考えてみる。

上下限値管理にはx管理図的な絶対値によるものではなく、u管理図を用いることで評価する規模に合わせた上下の管理限界(≒上下限値)設定をして管理すると言う方法もある。

これ、一見凄いことのように見える。
規模に応じた適切な値に上下限値が変わっていくのだから。

しかし、これは単に評価対象の開発規模が小さいとブレは大きいよと言っているだけの話で、それを有難がる意味は無いと個人的には思う。

但し、どんなに気合いを込めた開発だろうと、どんなに機械的な開発であろうと、ソフトウェアの開発である限り、バグは開発規模に対し離散的に埋め込まれるので、バグ摘出密度はバラついて当たり前だよということを視覚的に開発者および管理者に意識させてくれる。この点でu管理図はx管理図的な管理より啓蒙的であると言えよう。

とはいえ、u管理図も実績データからの平均値一本で全てが決まると言うモデルの性質上、限界はある。
しかし意外にも現実がモデルにあまりに上手く当てはまることも多く、個人的には神秘的なツールだという印象がある。

2013年11月27日 (水)

【定量的管理の疑問点】バグ摘出密度の上下限幅が2倍なのはどうなのか

バグ摘出密度の上下限値が2倍やそれ以上の幅となっている組織は多いと思われるが、これについて違和感を覚えないだろうか。

他の指標、例えば生産性実績を2倍以上の幅で管理されていたらどう思うのであろうか(個人的には別にそれもありと思うだけだが)。

管理するに妥当な範囲とは何か考えもせず適当な実績値持って来て箱ひげの見た目で判断してないだろうか。

そしてこのような大きな幅を持っていることに対して「バグ発生は離散的だし、統計的に十分な数のデータ集まっていないからこの程度のバラツキは許容すべき」とかを何の検証もなく直感で言って終わらせていないだろうか。

いやいや、このような管理はダメだと思われる。
管理というより管理もどき。

バグは離散的データ。だからこそちゃんと考えないと。

2013年11月20日 (水)

【品質保証】「チェックリストに追加します」がダメなわけ

何か問題があってうまい再発防止策がない際の苦肉の策である「チェックリストに追加します」の問題点。

本来チェックリストは行動、結果、成果物が予め定めた事項を満たすことを事後に確認するためのもの。しかし活用開始すれば直ぐ行動者は監査や品証への先回り的にチェックリストを満たすよう行動し始める。

チェックリストの項目いくら増えてもここまでならまだ問題は少ない。
しかし項目多くなるとその内チェックリスト項目を満たせば良いという者が出てくる。それでもまあチェックリストの体はなしているが、更に項目多くなると最後に"本プロジェクトでは対象外"をためらわず乱発するのが出てくる。何のためのチェックリスト。

また項目多いと本来のチェック側もよく分からなくり本来すべきをしなくなったり/できなくなったりする。実質使われないのと一緒の状態。それでも漏れのないフルスペックチェックリスト名の下に続々と項目追加され、一方で運用は破綻する。

最初に戻ると、チェックリストは行動、結果、成果物が予め定めた事項を満たすことを事後に確認するもの。しかしその予め定めた事項は詳細でないといけないのだろうか。チェックリストの使用者はチェック対象の素人なのか。チェックリストはチェックすべき項目全て詳細に網羅すべきものなのか。分野や使用目的によると思う。
チェック者でなく実施者がそれを満たすための用途ならもはやそれをチェックリストと呼ぶ必要はないし、基本的なことならいちいちリスト確認させるというより身につけさせるべき振る舞いである。だからチェックリストは本当に漏れやすい事項についてチェック能力を有するものが分かる程度に簡潔に作成するべきものであり、故に安易に増やし続けることは良くないのである。

2013年9月22日 (日)

【LOCとFP】違いを肉の値付けにたとえてみた

LOCとFC。

その違いが分かるように肉の値付けでたとえてみた。

【LOC】 
グラムいくらで価格を決定
部位が異なっても価格に影響しない
肉が牛か豚か鶏かを問わない

【FC】
部位のまとまりの単位(もも1足、ひれ1枚等)で価格を決定
もも一足が牛・豚・鶏で大きさが異なっても価格に影響しない
肉が牛か豚か鶏かを問わない

こんな感じではどうか。
LOCとFPでは異なる点に着目しているというのはそれぞれの存在意義であろう。

このように整理してみれば、両者が何をしようというのが多少わかりやすくなると思う。

肉の場合、大抵は、国産・牛・サーロイン・500グラムのように買う。
しかも、国産と言っても更に産地が細分化されたり、牛と言っても品種が明示されたり等級があったりする。

しかし、LOC的考えでは、「肉を500グラム」と言うだけであり、FP的考えでは「レバー1個ともも1つ」と言っているだけである。

肉を買うときにLOC的考えやFP的考えでは買わない。
LOCやFPのどっちが優れているか論争のもやもやはこのような点に根があるように思う。

2013年5月15日 (水)

【品質改善】組織は品質改善ツールと技法のどちらを積極的に採用しているか

自組織は品質改善ツールと技法のどちらを積極的に採用しているかを考えてみると、組織の品質改善に対するスタンスが分かるのではないだろうか。
(ここでは重要部分を人以外が行う方法をツールとし、重要部分を人が行う方法を技法とする)

さて、積極さである。
非常に簡素化して次の4つに分けて考えてみる。

1.【ツール】積極【技法】積極
2.【ツール】消極【技法】消極
3.【ツール】積極【技法】消極
4.【ツール】消極【技法】積極


1.【ツール】積極【技法】積極

拙速は手戻りが大きい等現実には色々考慮すべき点もあると思われるが総論的には、これは良い組織といえるだろう。


2.【ツール】消極【技法】消極

逆にこちらは、競合に置いていかれるから積極性を持つべきだというのは総論的には正しいであろう。
競合がなければ伝統工芸化することも可能かもしれないが。


そして、今回本当に議論したいのは次の2つ。
これらはどの様な時に生ずるのであろう。

こちらもステレオタイプで考えて行く。


3.【ツール】積極【技法】消極

このような組織は、品質改善施策というと、誰かがどこかからツール持って来てほら使えとなるケースが多いのではないだろうか。

ツール入れたがるが、頭使うのはちょっと…ということ。
組織の偉い人がどこかで聞いて来たツールというケースはまだ良いかもしれない。
偉い人が理解できないと採用できないという組織もこのケースになるのではないか。
ツール、特に有料ツールは営業用に採否決定者の能力に合ったプレゼン資料をうまく作るだろうから。でも、お金にならない技法はそういう採否決定者が理解できるプレゼン資料作ってくれる人いないから…。
折角高価で有益なツールを導入してもそれを活かす技法が偉い人用の割り算中心のメトリクス以上にならず、残念な組織は多いと思う。

このような組織は、ツールを導入することが即ち成果なので、元が丸のところに四角のツールを押し込んでも是とされる。
とにかく導入フェーズが全て。

しかしツールは本来、導入前と後、特に導入後が大切だと思う。当たり前だが。
どこかからツールを持って来て、さあ使え使えとやって、お、使ったな、はいOKではツールがもったいない。

これでも良いと言えるのは、どうしようもなく管理ができていない組織だけではないだろうか。


4.【ツール】消極【技法】積極

改善意識はあるが、原則現状と連続した改善が中心で、概念が変わったりフローが大きく変わるツール導入には消極的。

しかし考えることは出来るので、組織内では状況は改善し続けていると考えている。

3.と逆でトップが特にリーダーシップを発揮せず、現場主導の場合こうなるのではないだろうか。
だから、トップが一声掛かれば、1.になる素因を持っている…はず。


最後に…

ここまで勝手にステレオタイプな
考えを書いておいてなんだが、どの組織も1.を目指すべきなのだろうかとも思わなくもない。

…いや、やはり目指すべきなのだろう。

2013年5月14日 (火)

【LOCとFP】これこそまさに目的は何かの世界

LOCとFP。
一方の宣伝屋の言うどちらが優れているか論をただ受け入れるのではなく自分の使いたい用途で使い分けるべきだろう。

とはいえ、どちらも帯に短したすきに長し。というか、中には帯にもたすきにも使えない単なる布切れ程度と考える人もいるだろう。

しかしサイクロマチック数だとかハルステッドの何とかならOKと言われているのでもない。

そこで残念ながら冒頭の、

自分の使いたい用途で使い分けるべき

という言葉が出てきてしまう。
嫌いな言葉だけど。

LOCは言語や開発者によるバラツキが大きすぎるというFP側の人もいれば、FPは大雑把すぎて開発中の管理に不向きというLOC側の人もいる。

どちらも一面正しい。

調べるとFPの方が良い様な気がするが、これは、後発のFPがLOCへの批判を叫ぶことで売り出したからではないかと思えてしまう。個人的印象だけれど。

fault-proneモジュール予測でFP使うべきという人は見ないからやはり実際の開発フェーズではFPは使いづらそう。

LOCとFPとその他色々なもの…
不本意ながら用途に合わせて使い分けるしかないのだろう(今のところ)。

何を今更なエントリーとなったが…実際に開発している人でこういうの意識せずにどちらかのみを信じて?使ってる人多いと思うので改めて書いた。

2013年3月 4日 (月)

【バグ曲線〜何度目かの…】なぜ収束するのか

ソフトウェアテストシンポジウムJaast Tokyo'13で「なぜバグ曲線は収束するのか~Microsoft Excelを使って考えてみる~」(丹羽)という発表があった。
その場にいたし、当日発表資料と論文が以下に公開されているのでこれについて書いてみる。
 http://www.jasst.jp/symposium/jasst13tokyo/report.html 

この発表の論旨は、つまるところ、

テストケース中にどうしても含まれるテスト確認項目の重複と、バグを早く出そうというテスト実施者の恣意によるテスト実施順の2つが原因となってバグを前倒しで叩き出すことでいわゆるバグ曲線はあの形になる

と言っている。

言っていることは理解できる。

ただし、この2つの要因だけで、たくさんの事例で見られるあの曲線が本当に生まれるのかは、今回の説明だけでは分からない。
収束に寄与しうるということが分かっただけである。
これは発表においても言及されている。

だから本当はここで説明されていない別な要因があって、その寄与の方が大きく、今回の2つはあまり収束に関係ないという可能性は残ったままである。

まあ、そうではあるが、バグ曲線の収束理由について、あまり考えずに活用している組織が多いのは、そうであろうし、この理由について考えるべきと問題提起した意義はある。


しかし、論文も発表も同じであるが、その構成はよくない。

この発表では、結局、上の2つの理由からテストケースを用いたテストのバグ曲線管理は非常に難しい、というか、実質無意味に近いということを言外に言っている(ように見える)。

それはそれで、まあ良い。

とはいえ、最後の最後にテストケースに縛られないベータテストや運用テストでは、この2つの束縛から自由なのでバグ曲線管理はうまく行くのではないかみたいなことをさらっと言っている。

これは酷い。
現状高々5枚半の論文なのだから、このテストケースに縛られないテストにおけるバグ曲線の性質について述べるスペースは十分残っている。

これについて説明しなかったのは出し惜しみと言われてもしかたがない。。

そうは言いながら、発表資料にもあるが、バグ曲線の活用について、ここで示された収束理由を元に、品質担当者、開発者、上位マネージャー、そしてバグ曲線を納品条件にするお客様と議論してみることは良いことなのではないだろうか。

このような管理を生業とする人たちの好きなExcelを使って…という提案は良いと思う。
本論文ではそのために、採り上げた2つのバグ曲線収束理由の説明をExcel関数を用いているのだという。

2012年10月 3日 (水)

【データ指向の…(デート本)】多分もの凄く中身のある本…多分、多分

『データ指向のソフトウェア品質マネジメント―メトリクス分析による「事実にもとづく管理」の実践』

ーーーーーーーーーー
前回、本書の全体の感想を書き、今回は少しだけ中身に触れようと思っていたが、思うところがあり前回と同じことを別な表現で書くことにした。

ーーーーーーーーーー

今まで見たことのない本である。
本書の評価はこれに尽きる。
ありがちなメトリクス万歳な本と思って読み進めると裏切られる。
しかも、これが良い意味で裏切られているのか悪い意味で裏切られているのかが直ぐ分からない。
どうも本書は、ソフトウェアメトリクス管理そのものを説明する本ではなくて、ソフトウェアメトリクス管理を行う際に必要となる技法説明に軸足を置いた本のようだ。
うまく説明できないが、前者は「こういう時にはこういうメトリクスがあって、ほらこんなことが分かるんだよ」というもの。
これは裏読みする私の大好物である。
しかし後者は「定量的管理にはまずそれを行うための技法(主に数学知識)が必要だよね。だから事実にもとづく事例データ見せてあげるから、それ使って技法学びましょう。その後、学んだ技法使って何が出来るかは自分で考えなさい」というものであり、そこに挙げられる個々の技法自体も「著者の場合こう考えたけれど各自考えてみて」みたいなスタンスで置かれている。
これは裏読みするには困る。
とはいえ、ソフトウェアの定量的管理の難しいところから逃げまくっているわけでもなく、著者の(SLOCベースで話を進める等比較的オーソドックスな)考え方が、事例の中からしっかり伝わってくる構成になっている。オーソドックスなので個人的には物足りない点もあるが。
しかし、事例の選び方はかなり巧妙で、事例をいくつか挙げながら、多くの技法を無駄なく良い具合に説明して行く。これは見事といえる。

結構内容も深入りしているが、装丁からは想像できない熱の入った文体が所々顔を出して、何か簡単なことのように読み進められてしまう。しかしこれは前提知識がないと雰囲気だけで著者の主張を読み取れないまま終わってしまう恐れのある構成でもある。
以上、色々書いたが、1つ非常に素晴らしい長所がある。
否定的に取れるように書いておいてなんだが、最後に挙げた何か簡単なことのように読み進められてしまうという点だ。メトリクス管理で悩むのは概要は分かるが現実にどう進めれば良いか分からないからと言う人や組織が多いと思う。そこを狙った啓蒙本も出されていたりするが、なかなか満足の域に達してない。本書はこの部分を筆者の進め方を追体験することでクリアできるのではないかと思う。
但し題名がこれを明確に打ち出していないため、書店で潜在読者に訴えられないのは残念。
せめてサブタイトルに「データと一緒にデートしよう」とでもあれば、意図を察して手を延ばす潜在読者もいたような気がする。
結局、デート本と呼ばれているわけでもあるし。
まあ、勘違いする者も…いないか、さすがに。

ということで、書名と内容がズレていると個人的には思える。
最後に…
こういう本を世に出せた著者にやはり嫉妬する。
これはもの凄い本である可能性がある…が、実は私には良く分からない。
良く分からないというのは本書が私より遥かに出来る人により私より出来る人向けに書かれているからだと思う。


私も前提知識が足りないところを文の勢いで読ませてもらっているのだろう。
こうなると、本書のターゲットとなる読者層がよく分からない。
私も少しはソフトウェアメトリクスかじっているつもりでいたし。
本書は、これからメトリクスを使った管理を始めようかという者にも呆気なく読めるが、しかし読後、自分たちのデータを前に何をすれば良いかはやっぱり分からないままになってしまう可能性はある。それでも読む前と比べれば大きく前進しているはずだが実感がつかめないかもしれない。このため、本書は、事例はあるがそれでも類書の1つという感じになり埋もれるリスクは高い。
原因の一つは、悪くいうと長所でもある「語り」で多くのことを言おうと文章に内容を詰め込みすぎていることにあると思う。良いことがうまく書かれていても、長い文では気づかないよという感じ…あくまで悪く言えばだけれど。表にしたり、列挙する形で書けば分かりやすいだろうなという部分は多くあるように思う。

ただやはり柔らかい文でさらりと読める分、広い範囲の読者がそれぞれの興味の範囲内で大満足でなくとも満足できるようになっている可能性は捨てられない。
今まで見たことのない本であると最初に書いたが、単に自分が全てを理解したと確信を持てなかっただけであった。
ここまで書いておいて何だが、本書は先入観なしで読むのが一番良いと思う。

2012年9月28日 (金)

【データ指向の…(デート本)】多分もの凄く中身のある本…多分

『データ指向のソフトウェア品質マネジメント―メトリクス分析による「事実にもとづく管理」の実践』

今まで見たことのない本である。
本書の評価はこれに尽きる。

ありがちなメトリクス万歳な本と思って読み進めると裏切られる。
しかも、これが良い意味で裏切られているのか悪い意味で裏切られているのかが直ぐ分からない。

どうも本書は、ソフトウェアメトリクス管理そのものを説明する本ではなくて、ソフトウェアメトリクス管理を行う際に必要となる技法説明に軸足を置いた本のようだ。

うまく説明できないが、前者は「こういう時にはこういうメトリクスがあって、ほらこんなことが分かるんだよ」というもの。
これはナナメ読みする私の大好物である。

しかし後者は「定量的管理にはまずそれを行うための技法(主に数学知識)が必要だよね。だから事実にもとづく事例データ見せてあげるから、それ使って技法学びましょう。その後、学んだ技法使って何が出来るかは自分で考えなさい」というものであり、そこに挙げられる個々の技法自体も「著者の場合こう考えたけれど各自考えてみて」みたいなスタンスで置かれている。

これはナナメ読みするには困る。

とはいえ、ソフトウェアの定量的管理の難しいところから逃げまくっているわけでもなく、著者らの考え方が、事例の中からしっかり伝わってくる構成になっている(個人的に合わない考えもあるが)し、事例の選び方もかなり巧妙である。
これらは見事といえる。

また、結構内容も深入りしているが、装丁からは想像できない熱の入った文体が所々顔を出して、何か簡単なことのように読み進められる。

以上、色々書いたが、1つどうにも我慢がならない欠陥がある。

書名が長すぎるのだ。

検索すると本書は「デート本」というセンスある略称をつけられている。40文字超えてる書名を4文字に略せるのだから、ものごとをシンプルに捉えることができるという意味でメトリクス本に相応しい略称だろう。
何の本だかさっぱり分からないが。

あと、これは私だけかもしれないが、書名と内容が既に書いたようにズレていると思えるのは気持ち悪い。

最後に…
こういう本を世に出せた著者に嫉妬する。
多分これはもの凄い本である。

しかし、恐らくこのような評価をするのは私と一部のひねくれ者だけだろう。
他のソフトウェア品質に関わる人たちにとっては類書の1つという感じではないだろうか。

原因は、巧妙だけれど色々な芸を詰め込みすぎていることにもあると思う。
よく言えば、良いことがうまく書かれていても、うますぎて気づかないよという感じ…あくまでよく言えばだけれど。この種の本を裏を考えながら読む人は少ないだろうから、伝わらないことが多そう。

ただその分、広い範囲の読者がそれぞれの興味の範囲内で大満足でなくとも満足できるようにはなっているかもしれない。

…次回から少ないながらも本書についていつも通りのナナメ読みをして行く。

2011年7月16日 (土)

【ソフトウェアメトリクス】同じチームだから、同じということ

ソフトウェアのメトリクス管理において「前の開発とメンバーが同じなら品質・生産性の指標値は同じようになる」というようなことが言われたりする。

これはどういう解釈すべきか。
同じメンバーなら同じ結果というのであれば、野球、サッカーにどうして人は熱狂するのであろう。
ソフトウェア開発とスポーツは違うのか。
違うとするならばどこが違うのか。

百歩譲って「前の開発とメンバーが同じなら品質・生産性の指標値は同じようになる」が、統計的に成立するとして、しかし、その許容すべき誤差は最初から大きめで、沢山のプロジェクトを総括する際には良いかもしれないが、開発中の特定のプロジェクトに対し評価等を行うのは、見積もり時以外かなり厳しいしいと考えられる。

「前の開発とメンバーが同じなら品質・生産性の指標値は同じようになる」と言うこと自体に問題があるわけではなく、それはちゃんと検証してから使うべきというのである。

いやいやそれは仮定であって、それで良いのだよ…と言われるのであれば、もはや何も言うまい。

より以前の記事一覧