FSE/ASE2011勉強会 岡山県立大学 天嵜　聡介

Does Adding Manpower Also Affect Quality Does Adding Manpower Also Affect Quality? An Empirical, Longitudinal Analysis A. Meneely1, P. Rotella2, and L. Williams1 North Carolina State University1 Cisco Systems, Inc. 2

動機・目的 開発チームの拡大における どのような要因がリスクとなるのか？ 「遅れたプロジェクトにマンパワーを追加してもさらに遅らせるだけだ」 教育、コミュニケーションコスト 短期間に多くの開発者を追加することは品質の問題も引き起こしうる 実際には人員の追加が避けられない場合もある 開発チームの拡大における どのような要因がリスクとなるのか？

主要な貢献 開発チーム拡大にかかわるリスクについての理解を助けるような関連性を統計的に示した 直近における製品品質を正確に予測することを助けるような予測モデルを構築できた

開発チームの拡大に関するメトリクス Team Size = 4 Department Modularity Expansion Rate = 3 Expansion Acceleration = 1 Department Modularity ネットワーク分析で用いられるmodularity metric File A File B File C # of Developers Time 3 months

Case Study 対象 評価方法 Cisco社の大規模ネットワーク製品 time windowをスライドさせながらメトリクスを収集 54,000ファイルのソースコード 品質メトリクスは「顧客によって報告されたfailureの時間当たりの発生数」 評価方法 time windowをスライドさせながらメトリクスを収集 品質メトリクスと開発チーム拡大メトリクスの関連性を調べる 品質の予測因子としての開発チーム拡大メトリクスを評価する Time Time Window Team Changes Observed Quality Observed Lag

結果 品質低下に寄与していたメトリクス 予測因子としても有用 Expansion Acceleration Department Modularity 予測因子としても有用 ９５％予測区間（元論文の図６の引用）

The Onion Patch: Migration in Open Source Ecosystems C. Jergensen1, A. Sarma1, and P. Wagstorm2 University of Nebraska1 IBM TJ Watson Research Center2

動機・目的 Onion Model Open Source Ecosystems Open Source Ecosystemにおいても OSS開発者への道モデル MLへ投稿→バグ/Patch報告→Committerへ Open Source Ecosystems 開発基盤を共有しているプロジェクト群 Ex. Eclipse, GNOME 開発者は知識を引き継いで別プロジェクトへ参加できる Reputationも引き継げる、かも Open Source Ecosystemにおいても Onion Modelは妥当か？

主要な貢献 Ecosystemの文脈でOnion Modelを評価した これまでの研究は個々のプロジェクトが対象 EcosystemではOnion model に従わない人が多数であることを示した

対象 GNOME Ecosystem データ 3つの end user application, 3つの library package ML, VCS, BTSの履歴 初めての貢献 20 5 10 Project Timeline r10 r11 r12 r13 Project Experience = 4

Progression Path毎の集計（元論文の表４から引用） 1. Onion Modelに従っているか？ 評価方法 複数プロジェクトへ貢献している開発者を集計 開発者を5種のProgression pathに分けて集計 結果 複数プロジェクトにかかわっている人の方が多い Onion Modelに一致する開発者は少数 Progression Path毎の集計（元論文の表４から引用） Onion Model

2. 他プロジェクトでの経験は貢献に 影響するか？ 評価方法 活動経験とプロジェクトへの貢献の関連を検証 貢献の程度をCode Centralityで表現 Prior Experience: 他のプロジェクトでのActiveな活動経験 結果 活動経験は有意ではなかった Linear Regression による関連性の分析（元論文の表7から引用）

3. どのような要因が貢献の度合に 寄与しているのか？ 評価方法 PCAで開発者を４つの属性で表現 ML への投稿数などを利用 Code Centralityとの関連性を検証 結果 プロジェクトへの参加度合が高いと貢献は増加 経験年数が長いと貢献は減少 活動範囲が広いと貢献は減少 BTSやRepositoryでの活動があり、翻訳などに携わっていて、プロジェクト経験がないと貢献は増加

C. Trude and M. A. Storey University of Victoria Effective Communication of Software Development Knowledge Through Community Portals C. Trude and M. A. Storey University of Victoria

動機・目的 Knowledge exchange Community Portal ソフトウェア開発ではknowledgeのやりとりが重要 Wikiやblogなど様々な媒体がある Community Portal 多種のknowledgeのやりとりが集約されている フィードバックが得られるなど利点も多い Community Portalをどのように使うのが効果的か？

主要な貢献 ソフトウェア開発におけるCommunity Portalの使われ方について分析を行った Community Portalを効率的に使うためのactionableなアドバイスを行った

対象・評価方法 対象 方法 IBM Rational Team Concertの開発チーム 評価の視点を作成 情報をやりとりする媒体を評価 30 functional teams, 15 locations in the world Jazz.netで情報を公開 方法 評価の視点を作成 インタビューとPortal上のデータなどを参考に作成 情報をやりとりする媒体を評価 製品文書, 技術記事, ブログ, wiki

アドバイス 媒体の違いを明確にさせよう 媒体の種類を変えやすいようにしよう 媒体の特性に配慮しよう 精査された内容なのか、ドラフトなのか Wikiにある有用な情報がフォーマルな文書になっていない 媒体の特性に配慮しよう 例: wikiの情報は古くなってる場合がままある 公式文書はレビューされている, etc.

アドバイス(続) さっと書ける媒体を用意しよう コミュニティの中の人を巻き込もう フィードバックが得られるようにしよう 内容の正確性などをあまり気にしなくてよい媒体があればknowledgeを文書化しやすい コミュニティの中の人を巻き込もう コメント欄を設けるなど フィードバックが得られるようにしよう ユーザは記事を執筆した人に連絡が取りたい