3日目:バグトラッキング分析、コミュニティ抽出

NAISTサマーブートキャンプ

ソフトウェア工学講座「社会ネットワーク分析」の実習(2009年8月10-12日)に参加しました。
一日目午前:NAISTソフトウェア設計学講座をちょっと見学してきた
一日目午後:社会ネットワーク分析の基礎
二日目:ネットワークの特徴量、Pajekの使い方



三日目は実習でApacheのバグ修正システムの分析をして発表し、応用としてコミュニティ抽出の講義を受けました。
実習に使ったデータは手元にないので簡単に感想を書きます。

実習:バグトラッキングシステムの分析

オープンソースソフトウェアはたくさんのひとが開発に関わり、また商用ソフトのように緊急のバグ修正が必要になることも少ないので、たくさんのバグを長期にわたって管理する必要があります。だから、どんなバグがあるかを把握し、議論や修正の報告をするためのシステムが役立ちます。
今回の実習ではApacheのバグトラッキングシステムのログ、2003年の12ヶ月分を用いて分析しました。データは、システムに報告されたバグと、バグにコメントしているユーザをつなげた二部グラフです。ネットワークの可視化、代表的な指標(平均経路長、平均クラスタリング係数、次数分布)、次数の大きいユーザのランキング、中心性分析などを組み合わせて分析しました。

  • 指標を一つずつ見ていっても何もわからない。指標の組み合わせ、あるいはネットワーク図と比較しないと意味を読み取るのは難しい。
  • 二部グラフを通常のグラフに変換したものを見るよりも、もとの二部グラフを眺めたほうが直感的な気がした。ネットワーク図の解釈は、もとの二部グラフと、変換できる二種類のグラフのすべてを見る必要がある。
  • データだけでなくその時期に起きた出来事を調べるのも分析に有効である。たとえば、バグ修正が活発になったのはApacheのリリース前だったからである、という事実はデータだけではわからない。
  • ネットワーク図や指標などを用いて疑問や仮説が出たあとに、さらに詳しく調べる必要がある。たとえばネットワーク図で特定のバグやユーザに注目して、どのようにグラフが変化していくかを見る。
  • データからいろんな解釈が出てくるのは当然である。モデル化することで結論が出るのではなく、データからいろんなモデルを構築してみんなで議論してくことで結論をみちびいていく。モデル化のプロセスが社会ネットワーク分析の肝である。

短期間ですが、社会ネットワーク分析の入り口を体験できたように思います。

密度の高いつながり(コミュニティ)を抽出する

あまり理解できていないので概要だけ書きます。Pajekにもコミュニティ抽出の機能があるのでそのうち試したいです。
3個以上のノード同士がみんなでつながり合っている部分をクリークとよびます。これだとすごく濃いコミュニティしか抽出できないので、距離をすこし伸ばしてn-クリーク(1-クリーク=ふつうのクリーク)とすることもあります。ほかにk-コンプレックスとかk-クリーク・コミュニティ、k-コアなどの基準があるそうです。
また所属関係グラフを分析するときにm-sliceという基準が使われます。たとえばA社とB社の両方にエントリーするひとが一人しかいないときよりも、四人いるほうがA社とB社は何かつながりが深そうだとわかります。そうやってリンクの重みを計算することで、二部グラフを変換するときにやたらとつながりが増えてしまうという問題を解決できます。
前回の二部グラフをてきとうにm-sliceっぽく抽出すると以下のようになりました。


もっと大規模なデータに使うとおもしろくなりそうですね。
ひとまずこんな感じです。