障害の原因となる銀の弾丸はないってこと？

　ソフトウエア・メトリクスの分野（特にエンピリカル・ソフトウエア工学）の分野では、
障害の原因となる要因を、過去のプロジェクトから探し出し、それを元に、新規プロジェクト
に適用して、障害予測や各種見積もり予測に役立てようとしている。

　そのために、

PROMISE Software Engineering Repository
http://promise.site.uottawa.ca/SERepository/datasets-page.html

なんかで、プロジェクトデータが公開されているということは、前に書いた。

今日は、そこで興味深いことを見つけたので、書いてみる。

---

そこにある２つの（はじめにある、ＮＡＳＡのプロジェクト）ＣＭ１とＪＭ１について

普通だと、障害原因を探るのに、ステップワイズ法（変数増減法）を使うと思うけど、
ここでは、決定木を使って、確かめられないか、考えてみよう。

ＣＭ１をＷｅｋａの決定木Ｊ４８（Ｃ４．５と同じようなもの）で分析すると

となる。つまり、障害は、lOComment（Halstead's count of lines of comments）と
ev(g)（McCabe "essential complexity"）で説明付いてしまう。

　ほ～、正答率８８％だそうな。。。

---

とおもって、じゃあ、ＪＭ１でやると・・・

なんじゃこりゃ（－＿－；）ちなみに正答率７９．５％
なので、主要３要因、Loc、IOBlank、Total_Opでやると、こうなる

loc（McCabe's line count of code）、total_Op（total operators）
で説明付くらしい・・・
正答率８１．１％なので、ぐちゃぐちゃなのより、よくなった。

---

あれ・・・指標、変わってない？

じゃあ、ＣＭ１のデータを、ＪＭ１の指標Loc,IOBlank,Total_Opとdefeateの値
だけを残して、決定木で分析したら？

なにもでてこないし、
逆にＪＭ１のデータを、ＣＭ１の指標IOComment,ev(g)とdefeateだけを使って
決定木を分析すると、

出てくるけど、正答率は下がる。

---

つまり、決定木を使うと、

ＣＭ１の指標は、lOComment、ev(g)
ＪＭ１の指標は、Loc,Total_Op

が向いていて、他の変数ではあまりせつめいできなさそう。

・・・ということは、プロジェクトによって、障害が起こる要因はちがうってこと・・

障害の原因となる銀の弾丸はないってこと？


だとしたら、ステップワイズ法で変数を決定し、それを「ほかの」プロジェクトに適用することは無理ということになり、もしそのようなことがやりたいのなら、

（１）先に、いろいろなプロジェクトにおいて、
　　何が障害を予見する要因かを探し出し、
　　→Ｊ４８でもいいけど、他にもっと適切な方法があると思う


（２）適用しようとするプロジェクトが（１）のどのプロジェクトと
　　類似しているかを、Ｋ－ＮＮ法などで確認し、

（３）その似ているプロジェクトの障害説明要因を使って、
　　適用したいプロジェクトの予測を行う

っていうように、やり方をがらりと変えないといけなくなると思うんですけど・・・


・・・データマイニングとか、この分野は専門外だから、よくわかんないんですけど、
どう思います？


Ｐ．Ｓ　実はこれ、大学院のレポート＆発表で出したもの。

　そのときのコメントが、「でも、この要因でも、説明しているとはいえないよね。当てはまりはよくない。意外と、プログラマの技術力とかが測れたとして、その指標を入れたら、ガラリと変わるといったようなこともありえるかもね？」という意見がありました。