FSE/ASE2011勉強会 岡山県立大学 天嵜 聡介 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 Expansion Rate = 3 Expansion Acceleration = 1 Department Modularity – ネットワーク分析で用いられる modularity metric # of Developers File A File C File B 3 months Time Case Study • 対象 – Cisco社の大規模ネットワーク製品 • 54,000ファイルのソースコード • 品質メトリクスは「顧客によって報告されたfailureの時間当たりの発生数」 • 評価方法 – time windowをスライドさせながらメトリクスを収集 Quality Observed Team Changes Observed Lag Time Window Time – 品質メトリクスと開発チーム拡大メトリクスの関連性を調べる – 品質の予測因子としての開発チーム拡大メトリクスを評価する 結果 • 品質低下に寄与していたメトリクス – 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 – 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 10 5 r10 r11 r12 Project Experience = 4 r13 Project Timeline 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での活動があり、翻訳などに携わっ ていて、プロジェクト経験がないと貢献は増加 Effective Communication of Software Development Knowledge Through Community Portals C. Trude and M. A. Storey University of Victoria 動機・目的 • Knowledge exchange – ソフトウェア開発では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を文書化しやすい • コミュニティの中の人を巻き込もう – コメント欄を設けるなど • フィードバックが得られるようにしよう – ユーザは記事を執筆した人に連絡が取りたい
© Copyright 2024 ExpyDoc
