【ICSE2011勉強会】 Understanding Broadcast Based Peer Review on Open Source Software Projects 担当：大場光明（名古屋大学） 1 研究の目的・手法オープンソースソフトウェア開発におけるピアレビュー    ある人がパッチを作り、それがコミュニティ全体にブロードキャスト（同時通報）され、興味のある関係者たちがレビュー、議論を重ねて採否を決める無視されたり議論が発散したりしそうなのに、実際には非常に成功しているその裏にあるメカニズムや振る舞いについて調査     2 Apache HTTP server, Subversion, FreeBSD, Linuxカーネル, KDE の5プロジェクトについて調査無作為に選んだレビューログ（50～200件）を目で見て分析各プロジェクトのコア開発者（計9名）に電話・メールで聞き取り Session 19 担当：大塲（名古屋大） Research Question (1) Q1: レビューされるパッチはどう選ばれる?    開発者は自分の興味のある領域や、過去にコミットしていて責任のある部分に対するパッチを選んでレビューしている興味のある領域に対する議論や、過去に参加した議論への返信を様々な手法で抽出  メールフィルタ、件名→コミットログ→diff の段階的な詳細化、引用に挟みこんでの返信、自分の発言に対する返信には To: や Cc: に自分が含まれるという点レビュアーはコードに挟み込むようにコメントしている Figure 1: 余白に分析内容を書き込んだレビューログの例（一部） 3 Session 19 担当：大塲（名古屋大） Research Question (2, 3) Q2: なぜパッチは無視されることがあるのか?  OSSプロジェクトでは開発者に時間がない場合、レビューの質を落とすより、一部を後回しにすることを選ぶ ⇒ 誰からも興味を持たれなかったパッチは無視される   コア開発者に興味を持ってもらえるよう、そのパッチの作者が MLに再送するなど努力しなければならない Q3: どんなレビュアーがどのように議論している?   OSS開発において各人に固定の役割はなく、各々の強みを生かした集団的問題解決が行われる   4 外部の人も客観性や能力があれば重要な参加者にパッチの持つ問題によって、純粋に技術的な議論と、プロジェクトの目的や対象範囲に関わる議論に分かれる Session 19 担当：大塲（名古屋大） Research Question (4, 5) Q4: 1つのレビューに多数が関わってきたら?   ささいな話題ほど多くの人が関わってきて議論が発散   いわゆる「自転車置き場の議論」コア開発者はそのような事態をなるべく避けようと努めている  実際、コミッター以外の意見が過半数のレビューは5%以下 Q5: 大規模なプロジェクトでもスケールする?    FreeBSD や KDE では話題別のメーリングリストを設けて効果的に議論を分散 Linux ではパッチを送るときレビュアー個人のアドレスも加える手法が広く用いられている  5 90%のメールに複数の宛先（他のプロジェクトでは9%～27%） Session 19 担当：大塲（名古屋大）【SIGMOD/VLDB/ICDE2011勉強会】 Session 19: Software System as City: A Controlled experiment Richard Wettel, Michele Lanza and Romain Robbes 担当: 高井康勢(名古屋大学) 背景  Software Visualization(以下SV) Tool   背景にある問題:   ソースコードなどを可視化し、プログラム理解を支援するツール色々なツールがあるが、経験的に有用であると評価されているツールがほとんどない SVツールの発展・導入を妨げている研究の目的:  SVツールの評価を行う評価対象SVツール  CodeCity: ソースコードを都市として表現  既存ツール(Polymetric Views)の拡張   色分けのしかたを変更出力(Disharmony Map):     建物: クラス高さ: メソッド数基礎の面積: 属性数色: design problem[18] dataに基づく [18] R. Wettel and M. Lanza. Visually localizing design problems with disharmony maps. In Proceedings of Softvis 2008, pages155–164. ACM Press, 2008. ツールの評価にあたり   ツールの比較を行うような実験のためのガイドラインをTR[19]にまとめたガイドラインに基づき評価実験を行った   プログラム理解の補助に関する実験 EclipseとExcelを用いた方法と比較   正確性と所要時間を比較クラス間関連・変更による影響範囲・主要クラスの特定 [19] R. Wettel, M. Lanza, and R. Robbes. Empirical validation of CodeCity: A controlled experiment. Tech Report 2010/05,University of Lugano, June 2010. 評価  SVツールを利用することで、プログラム理解の正確性が24%増加し、所要時間が12%減少    概ねほとんどのタスクで双方ともSVツールが優位上位N・最大などを探すタスクはEclipse+Excelの方が優位正確性を必要とするプログラム理解   Eclipse+Excelが優位だと予測された SVツールでもそれほど正確性において引けを取らなかった CodeCityは、プログラム理解の支援ツールとして非常に有用である