【ICSE2011勉強会】 Understanding Broadcast Based Peer Review on Open Source Software Projects 担当： 大場 光明（名古屋大学）

研究の目的・手法 オープンソースソフトウェア開発におけるピアレビュー その裏にあるメカニズムや振る舞いについて調査 ある人がパッチを作り、それがコミュニティ全体に ブロードキャスト（同時通報）され、興味のある関係者たちが レビュー、議論を重ねて採否を決める 無視されたり議論が発散したりしそうなのに、実際には 非常に成功している その裏にあるメカニズムや振る舞いについて調査 Apache HTTP server, Subversion, FreeBSD, Linuxカーネル, KDE の5プロジェクトについて調査 無作為に選んだレビューログ（50～200件）を目で見て分析 各プロジェクトのコア開発者（計9名）に電話・メールで聞き取り Session 19 担当：大塲（名古屋大）

レビュアーはコードに挟み込むようにコメントしている Research Question (1) Q1: レビューされるパッチはどう選ばれる? 開発者は自分の興味のある領域や、過去にコミットしていて 責任のある部分に対するパッチを選んでレビューしている 興味のある領域に対する議論や、過去に参加した議論への 返信を様々な手法で抽出 メールフィルタ、件名→コミットログ→diff の段階的な詳細化、 引用に挟みこんでの返信、自分の発言に対する返信には To: や Cc: に自分が含まれるという点 レビュアーはコードに挟み込むようにコメントしている Figure 1: 余白に分析内容を書き込んだレビューログの例（一部） Session 19 担当：大塲（名古屋大）

Research Question (2, 3) Q2: なぜパッチは無視されることがあるのか? OSSプロジェクトでは開発者に時間がない場合、 レビューの質を落とすより、一部を後回しにすることを選ぶ ⇒ 誰からも興味を持たれなかったパッチは無視される コア開発者に興味を持ってもらえるよう、そのパッチの作者が MLに再送するなど努力しなければならない Q3: どんなレビュアーがどのように議論している? OSS開発において各人に固定の役割はなく、 各々の強みを生かした集団的問題解決が行われる 外部の人も客観性や能力があれば重要な参加者に パッチの持つ問題によって、純粋に技術的な議論と、 プロジェクトの目的や対象範囲に関わる議論に分かれる Session 19 担当：大塲（名古屋大）

Research Question (4, 5) Q4: 1つのレビューに多数が関わってきたら? ささいな話題ほど多くの人が関わってきて議論が発散 いわゆる「自転車置き場の議論」 コア開発者はそのような事態をなるべく避けようと努めている 実際、コミッター以外の意見が過半数のレビューは5%以下 Q5: 大規模なプロジェクトでもスケールする? FreeBSD や KDE では話題別のメーリングリストを設けて 効果的に議論を分散 Linux ではパッチを送るときレビュアー個人のアドレスも加え る手法が広く用いられている 90%のメールに複数の宛先（他のプロジェクトでは9%～27%） Session 19 担当：大塲（名古屋大）

Session 19: Software System as City: A Controlled experiment 【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.

CodeCityは、プログラム理解の支援ツールとして非常に有用である 評価 SVツールを利用することで、プログラム理解の正確性 が24%増加し、所要時間が12%減少 概ねほとんどのタスクで双方ともSVツールが優位 上位N・最大などを探すタスクはEclipse+Excelの方が優位 正確性を必要とするプログラム理解 Eclipse+Excelが優位だと予測された SVツールでもそれほど正確性において引けを取らなかった CodeCityは、プログラム理解の支援ツールとして非常に有用である