極寒の大地でソフトウェア工学を語る~最終章~

img_20151018_143617

今回は最後の記事更新です.

海外生活が始まり二カ月がすぎました.ここでは本当に色々なことが起こります.

  • カナダに到着後二日で感染症にかかり,最初の一週間は病院通い.
  • 自分が乗車している電車に飛び込みがあり緊急停車,線路を歩いてホームまで.
  • 研究の要であるMac Bookが故障,Apple Storeへ行くも,データの復旧は不可能だと言われる.

留学中に起きなくてもねえ… と,思ったりもしましたが,今ではこれも良い経験と前向きに考えています.大学の卒業生でGoogleのエンジニアとして働いている方が,会社説明会のために来校されていて,Tech Talkを聴けたり,研究に関する質問ができたりと,良い経験ができています.

あと,観光にも行きました.電車で3時間の場所にあるケベックシティに行きました.シャトーフロンテナック というホテルがこの町のシンボルになっています.実はこれ,東京ディズニーシーのタワーオブテラーのモデルになっているそうで,カナダにくる機会があれば是非いってみてください.

IMG_20151018_143617

あと11月に突入してから,街中でスケートリンクを見かけるようになりました.道具も借りられるようなので,一度は体験してみたいですね.

storageemulated0DCIMCamera1446927434800

さてさて,海外での研究生活に必死で,ついつい記事は後回しにしてしまいましたが,このような言葉を目にしたのでペンを走らせているところです(実際はキーボードを叩いてます).

Done is better than perfect

その通りだけど,なかなかできないですよね.Facebook社に掲げてあるそうです.まあとりあえず僕はこの連載を終わらせます 笑

さて,今回は「ソフトウェア工学を語る~最終章~」ということで,どんなデータを使っているかとか,どんなことをやってきたのかを順を追って紹介しようと思います.


[ 研究の課題設定 ]

研究の進め方としては,まずどんなことに興味があるのか,どんなことを問題だと感じているのかを考えます.

僕の場合は,まず「開発者」「利用者」二つの視点を考えました.ソフトウェアを作る側,ソフトウェアを使う側,どちらに貢献したいのかを考えるようにしました.その結果,僕は利用者視点で研究を考えることにしました.その理由として,利用者の中には自分が含まれているからです.ソフトウェアの利用者に貢献するということは,自分自身も恩恵を受けることができるということです. ...そう,単純な理由です!

そして,大枠として「利用者」に貢献する研究をするということを決めた後は,具体的な問題を考えます.そこで,利用者がソフトウェアに求めていることは何か ということを考えました.僕なり 考えとして,利用者は不具合の少ないソフトウェアを使いたい だろうと考えました.

そして,指導教員に相談したところ,オープンソースソフトウェア(OSS)がリリースされた後,どのように不具合が修正され,そして収束していくのかを分析する という,ソフトウェアの不具合についての研究テーマがあったため,これに取り組むことにしました.


[ データについて ]

第一回の記事で僕は,ソフトウェア工学についてこう言葉にしました.

ソフトウェア開発過程で蓄積された過去の開発記録を収集し,統計的手法に基づく分析から得られる知見を,現在のソフトウェア開発へ応用する

研究テーマを,ソフトウェアの不具合に注目すると決まりましたから,「蓄積されている過去の開発記録」,今回は,ソフトウェアのリリース後の不具合 についてのデータが必要になりますね.

OSSプロジェクトには,利用者から日々多くの不具合報告や,機能改善の要求が送られます.そのようなユーザからのフィードバックを管理するために,多くのOSSプロジェクトは,不具合管理システム (Bug Tracking System) を用いています.多くの管理システムがありますが,今回はその中でもよく知られているJIRA を紹介します.

不具合管理システム: JIRA

JIRAはタスク管理として,企業でも使われています.上のリンクをクリックすると,System Dashboardという画面に飛びます.そして,今回は不具合のチケットを見る必要がありますから,上のタブからIssuesをクリックし,さらに,Search for issues 選択します.スクリーンショットを貼っときます.

_j6IcvbQYrOC3BR0oPYn7h-ERF0elG9I8RF9dRMI-V4

そうすると,不具合を管理するページに飛べます.

そこで,対象とするProjectを選択したり,不具合についているStatusを既に完了しているもの,に絞り込んだりできます.
チケット一つ一つがこのような形で管理されています.関係するソフトウェアのバージョンや不具合の内容,再現手順などが書かれていたりします,右上の方の,Exportという箇所をクリックすると,これらの不具合情報を取得することができます.Excelで開けるものもあるので,みたい方は試してください.

また,プロジェクトの数や不具合の数が増えてきたりすると,自分でプログラムを書いて必要な情報だけ取得した方が早い場合もあります.うまくプログラムを書くと,必要な各不具合チケットに書かれている必要な情報だけを何千,何万件とあっという間に取得できてしまいます.

スクリーンショット 2015-11-14 18.23.37

私の研究では,不具合が発見されたバージョン情報などの情報に加え,リリース後に報告された不具合が,いつ修正されたか という情報が必要なので,これらのチケットから,修正完了日 の情報が必要です.必要なデータが集まったら,次はデータ整形を経て,分析になります.


さあて分析だ

データを収集した後は,どのようにデータを使うのかということを考えます.

僕たちのアプローチでは,不具合が修正された不具合数を時系列データとし,時間とともに修正される不具合数の変動を見るために,不具合の修正数を時系列に積み上げていき,それを曲線として表現する,不具合修正曲線というものを提案しています.

curve

今回の研究では,リリース後の不具合修正に注目していますから,X軸は,対象とするソフトウェアのリリース日を原点として,観測地点までの経過日数になります(単位は日数:500 = 500日).Y軸は,修正完了した不具合数です.実データとなっている曲線が,収集したデータを不具合修正曲線にしたものです.(ロジスティックなどは後ででてきます.)

この不具合修正曲線を見ることで,リリース後の不具合修正がどのように行われていき,収束していくのかということを観察することができます.これらを見ると,リリースから早い時期では,曲線の傾きが大きいため,不具合修正が活発に行われていることがわかります.一方で,時間経過とともに曲線の傾きが緩やかになっていることも確認できるため,不具合修正数が収束していくことがわかります.

僕たちのアプローチとしては,このように曲線が緩やかになる点,修正すべき不具合がなくなった時期(実際にそうかどうかは断言できません)と解釈し,この時期にあるソフトウェアは不具合は安心して使える.というような主張をしています.

そして,ここまでくると新たな提案が出てきます.

この不具合修正曲線は過去のデータを使っていますから,リリースから時間が経っていないものなどは,曲線を作ることができません.

そこで,次の課題として,曲線の収束を事前に予測できないか ということが出てきます.つまり,観測地点までの不具合修正のデータから,この先の修正曲線の動きを予測する ということです.新しくリリースされたソフトウェアが,あとどれくらい待てば不具合が少なくなり,安心して利用できるのかということがわかるようになれば,実用性のある貢献になると思います.

そして,不具合修正曲線に確立モデル,統計モデルを利用した将来予測に取り組んでいきます.

予測モデルの話になってくると,それを専門に扱っている研究者の協力が必要になってきます.モデルを使った不具合修正予測の研究は,早稲田大学の研究室と共同研究として取り組みました.

早稲田大学の理工学部に一ヶ月出張し,共同研究として研究に取り組みました.
ちょうど三月だったため,新入生向けのサークル勧誘に誘われました 笑

可愛い女性がたくさんいたような気がします.

これ以上語り出すと脱線してしまうので次にいきます.


研究は続いていく

確率・統計モデルの話を始めると,あと何時間かかるかわからないので一言で書きます.

[確率モデル]

不具合が修正される ということを,ある一定の時間間隔で発生する事象だと仮定します.ここで言っていることはつまり,不具合修正はポアソン分布[2]に従っているのではないかと言っています.(Wikipediaにリンクしています)

ポアソン分布に従っている,つまり,ポアソン過程にあるものは,指数関数で記述できます.これはちょうど,不具合修正曲線において,始めは傾きが大きく,その後徐々に傾き収束していく様子に似ています.

リンクをみてみると,世の中のいろいろなことがポアソン過程だと考えられているようで,統計的手法の中でも広く知られていることがわかります.

また,実際には,不具合修正の状況というのは,プロジェクトに報告される不具合数,開発者数などの様々な要因が作用していると考えられます.そのため,より現実の開発環境に即したモデルとして,S字曲線であるロジスティックモデルなども適用し,予測を試みました.先ほどの画像のように,良いフィッティングを示しており,これを用いた将来の曲線予測にも取り組みました.今回はそこまで説明はしません.

それらの試みは,論文として発表しました.そして現在は,それらを応用させた内容で論文誌を書いているところです.


[ 最後に ]

さてさて,最終章はこのくらいで終わろうかと思いますがいかがでしたでしょうか?

1月には帰国し,修士論文,そして春から社会人となっていきます.修了の前に,研究の話,留学の話,もしくは可愛い女の子の話でもいいのでいろんな人と語り合いたいですね.三回に渡って記事を書かせていただきましたが,これにて終了になります.他の方のようにもうちょっと概念図とか入れられたらよかったのですが,文字ばかりの記事になってしまいました.

最後までお付き合いいただいた方,本当にありがとうございまいした!

参考

[1] Wikipedia: ポアソン分布

https://ja.wikipedia.org/wiki/%E3%83%9D%E3%82%A2%E3%82%BD%E3%83%B3%E5%88%86%E5%B8%83

[2]Wikipedia:ロジスティック方程式

https://ja.wikipedia.org/wiki/%E3%83%AD%E3%82%B8%E3%82%B9%E3%83%86%E3%82%A3%E3%83%83%E3%82%AF%E6%96%B9%E7%A8%8B%E5%BC%8F

 

この人に、留学相談したい方は、留学codeからどうぞ