Proceeding of the 33rd international conference on Software engineering (ICSE’11), pp. 261-270, 2011. Configuring Global Software Teams: A Multi-Company Analysis of Project Productivity, Quality, and Profits 1Narayan Ramasubbu 2Marcelo Cataldo 1Rajesh Krishna Balan 2James D. Herbsleb 1Singapore Management University 2Carnegie Mellon University

大平雅雄（奈良先端大・松本研）＠ICSE2011勉強会 背景と目的 分散開発の世界的な需要が年々高まっている 分散開発における様々な側面（地理・時間・組織構成）が，生産性・品質・収益に与える正・負の影響を深く理解する必要がある 各側面が生産性や品質に与える影響は個別に調べられてきたが，総合的に調べた研究は存在しない 本研究の目的は，5大陸15カ国にまたがる4社計362件分の分散開発プロジェクトデータに基づいて，各側面のトレードオフを明らかにすること 大平雅雄（奈良先端大・松本研）＠ICSE2011勉強会

大平雅雄（奈良先端大・松本研）＠ICSE2011勉強会 Research Questions RQ1: 分散開発における各側面（地理・時間・組織構成）が，生産性・品質・収益にどのように影響するか？ RQ2: 分散開発を実施している企業が，地理的・時間的分散の負の側面を緩和するために利用できる組織構成的側面とは？ 大平雅雄（奈良先端大・松本研）＠ICSE2011勉強会

生産性・品質・収益に影響を与える分散開発の側面 地理的分散 同期コミュニケーションが可能（同タイムゾーン限定） vs. 他の開発拠点の進捗などに対するアウェアネスの欠如 時間的分散 24時間体制の平行開発が可能 vs. 同期コミュニケーションの欠如 組織構成的分散 開発拠点の分散（開発拠点の数） 開発者の分散（各開発拠点の開発者の数の不均衡） 開発経験の分散（各開発拠点の開発者の経験の不均衡） 大平雅雄（奈良先端大・松本研）＠ICSE2011勉強会

大平雅雄（奈良先端大・松本研）＠ICSE2011勉強会 分析結果（まとめ） 分散開発では，高収益を確保しつつ生産性と品質を共に向上させることはできない 生産性を上げるためには，品質が犠牲になる 品質を上げるためには，生産性が犠牲になる 開発拠点数が増えると，収益が犠牲になる 大平雅雄（奈良先端大・松本研）＠ICSE2011勉強会

大平雅雄（奈良先端大・松本研）＠ICSE2011勉強会 組織構成の戦略（まとめ） 生産性重視型 開発者の数と経験をバランスよく構成すべきである 品質重視型 開発者の数を顧客側に充実させつつ，開発者の経験は拠点間でバランスよく構成すべきである 収益重視型 経験豊富な開発者を開発委託先に重点配置すべきである 大平雅雄（奈良先端大・松本研）＠ICSE2011勉強会

Does the Initial Environment Impact the Future of Developers? Minghui Zhou Audris Mockus 担当：NAIST 松本研 戸田

プロジェクトの状況を「技術寄り」と「コミュニケーション寄り」の軸で評価する 概要 長期に渡ってプロジェクトに多大な貢献をしている開発者（LTCs: Long-term Contributors）に注目し，彼らがプロジェクトに初めて参加した時の状況を調べる プロジェクトの状況を「技術寄り」と「コミュニケーション寄り」の軸で評価する １軸で評価しているので「どちらでもない」もある 技術寄り：開発者がひたすらタスクをこなしている時 コミュニケーション寄り：開発者が互いにModification Request（修正要求）を出し合っている時

オープンソース，商用ソフトウェア開発プロジェクトをそれぞれ3種類ずつ分析対象とした． 論文中 Table 1. Project Years MLOC2 Domain Cntrbtrs JOnAS 8 0.2 Middleware 279 JBossAS 5 0.3 2516 Mozilla 12 1.5 UI 62056 D >20 Telephony 1966 F >10 3 Embedded telephony 464 K >15 Messaging 223 オープンソース 商用ソフト

参加時のプロジェクトの状況とその後の開発者の参加期間の長短には明確な関係がある 分析結果 オープンソース特有の傾向 技術寄りの時に参加した開発者はLTCsになりやすい 商用ソフトではその傾向は見られなかった オープンソース，商用双方に共通する傾向 コミュニケーション寄りの時には新規参加の開発者数は増加する 技術寄りの時にはLTCsの開発者数は増加する 参加時のプロジェクトの状況とその後の開発者の参加期間の長短には明確な関係がある ただしその関係はプロジェクトごとに異なっている

プロジェクト参加時の状況は，開発者のその後の活動に影響を与えることが分かった． まとめ プロジェクト参加時の状況は，開発者のその後の活動に影響を与えることが分かった． プロジェクトが技術寄りの時期に新規参加した開発者は長期にわたってそのプロジェクトに大きな貢献をしやすい 特筆すべき点 この種の分析には珍しく，商用ソフトウェアのプロジェクトも分析対象にしている データセットのクレンジング，分析の限界についてそれぞれ1ページを割り当て，詳細に記述している 気になった点 1ページ使ってデータクリーニングの内容を丁寧に記述している 論文のLimitationsについて1

1Andrew Meneely 1Laurie Williams North Carolina State University Proceeding of the 33rd international conference on Software engineering (ICSE’11), pp. 281-290, 2011. Socio-Technical Developer Networks: Should We Trust Our Measurements? 1Andrew Meneely 1Laurie Williams North Carolina State University

大平雅雄（奈良先端大・松本研）＠ICSE2011勉強会 背景と目的 最近，CVS等のログデータを対象としたソーシャルネットワーク分析（SNA）に人気が集まっている 開発したSNAメトリクスに基づいて不具合予測等の研究が盛んにおこなわれている 一方，ログデータから抽出した「ネットワーク」と，開発者が実際に知覚している「ネットワーク」とが必ずしも一致しているとは限らない 研究者は後者を主に対象としているため，これまでの研究成果は未だ実証的に確認が取れていない状態である 本研究の目的は，SNAメトリクスが，開発者が知覚している「ネットワーク」を正確に反映しているかを実証すること 大平雅雄（奈良先端大・松本研）＠ICSE2011勉強会

大平雅雄（奈良先端大・松本研）＠ICSE2011勉強会 Research Questions Q1: 開発者ネットワークのつながり（エッジ） 2人の開発者が同時期に同一のソースコードを編集すると，その2人はお互いが協力し合っていると認識しているか？ Q2: 開発者ネットワークの距離 開発者ネットワーク内での2人の開発者の距離は，その二人が感じる「距離感」を反映したものになっているか？ Q3: 開発者ネットワークにおける中心性 開発者ネットワークで中心性（リーダーシップ）の高い開発者は，プロジェクトの中心人物（エキスパート）として他の開発者から実際に認識されているのか？ 大平雅雄（奈良先端大・松本研）＠ICSE2011勉強会

CVSログデータに基づく開発者ネットワーク 「特定の期間内に同一ファイルを編集したかどうか」 3プロジェクト（Linux kernel, PHP, Wireshark）のCVSログから開発者ネットワークを構築 大平雅雄（奈良先端大・松本研）＠ICSE2011勉強会

大平雅雄（奈良先端大・松本研）＠ICSE2011勉強会 オンラインサーベイ 他の開発者に対する実際の認識に関するサーベイを実施 CVSログから共同編集者を抽出し，共同編集者に対する認識を各開発者に選択式回答で問うもの この開発者と頻繁に作業しています この開発者はタイミング良く私の知覚にいます の開発者はソフトウェアセキュリティに関する知識が豊富である この開発者は以前，この機能と同様のものの開発に携わったことがあります，などなど． 大平雅雄（奈良先端大・松本研）＠ICSE2011勉強会

大平雅雄（奈良先端大・松本研）＠ICSE2011勉強会 分析結果（まとめ） 共同開発者とのエッジ 普段よく一緒に開発している開発者 については，開発者ネットワーク内で の距離が短いと認識 2人の開発者の距離 開発者との距離感は，CVSログデータ から抽出した開発者ネットワークに反映 されている 中心性と評判のエキスパート 評判の高い開発者の中心性（次数中 心性と媒介性）は高い傾向にある 大平雅雄（奈良先端大・松本研）＠ICSE2011勉強会