Download C - qwik.jp

ICSE2012勉強会資料
Empirical Studies of Development
2012年8月30日
富士通研究所
ソフトウェアイノベーション研究部
COPYRIGHT 2012 FUJITSU LABORATORIES LTD.
(1/3)
Empirical Studies of Development
Overcoming the Challenges
in Cost Estimation
for Distributed Software Projects
1
COPYRIGHT 2012 FUJITSU LABORATORIES LTD.
概要
(2/3)
 課題
 世界中に配信されるソフトウェアの初期工数見積が難しい
• 国によって異なる設定をしたり、負荷テストをしたりするため、見積が実際より3倍近
く外れることもある
 契約時の初期工数見積は人の経験に基づいて判断される
 解決手段
 ソフトウェア企業３社に協力を依頼して、過去のプロジェクトの特徴と工数をリ
ポジトリに登録し、類似した事例の平均から工数を算出＋経験則による補正
• ISO 9001を認可し、CMMI-level 5と査定されたソフトウェア企業
• 類似した事例は、特徴の距離と、マネージャの判断から絞り込む
• 各企業内で用いているCOCOMO IIベースの工数見積に追加
 ２１９の新規プロジェクトで見積を行い、手法の有無で実験
 結果
 見積のずれが最大で６０％まで抑えられた
 ２０％の純原価削減に貢献できた
2
COPYRIGHT 2012 FUJITSU LABORATORIES LTD.
評価の指標について
(3/3)
 ソフトウェア企業３社に協力を依頼して、過去のプロジェクトの特徴と工数をリ
ポジトリに登録し、類似した事例の平均から工数を算出＋経験則による補正
• ISO 9001を認可し、CMMI-level 5と査定されたソフトウェア企業
• 類似した事例は、特徴の距離と、マネージャの判断から絞り込む
 プロジェクトの特徴を16項目設定
 配備先の数、プラットフォームの種類、新人の割合、パフォーマンス要件など
 工数の数値に加え、経験的な内容を提示して補正がないかを促す
例：経験が浅い開発者がいる場合は、勉強する時間も含めて工数を考えるべき
 プロジェクトマネージャの経験年数が工数の算出結果に影響
｜見積工数 − 実際の工数｜
実際の工数
プロジェクトマネージャ
経験年数
3
COPYRIGHT 2012 FUJITSU LABORATORIES LTD.
(1/6)
Empirical Studies of Development
Characterizing Logging Practices in
Open-Source Software
4
COPYRIGHT 2012 FUJITSU LABORATORIES LTD.
全体概要
(2/6)
 現実にロギングがどのように実践されているかを定量的に調査
 ログメッセージはソフトウェアの開発・運用時にとても重要．しかし，ロギング
コードの多くは気まぐれや後付けで追記・修正されており，体系立っていない
 そこで，ロギングが現実にどう実践されていて，開発・運用にどのような影響を
与えているのかを，OSSを対象に世界で初めて定量的に調査した
 調査方法
 実績のある4つのOSSについて，ソースコード含む開発リポジトリを分析する
• 対象：Apache httpd，OpenSSH，PostgreSQL，Squid
 OSS中のロギングコードの特徴や修正のされ方を分類・集計し，考察を加え，
知見としてまとめる
 結果と，本研究の貢献
 貢献１．世界で初めて，ロギングはソフトウェア開発の重要な実践の１つであ
ることを，定量的な根拠でもって示した
 貢献２．開発者がロギング実践時に苦労している点を明らかにし，より良いロ
ギングのための，新たな支援施策のヒントを示した．
 貢献３．ログ出力レベルの設定間違いを自動検出するコードチェッカーを作
成・評価し，我々の知見の有効性を示した
5
COPYRIGHT 2012 FUJITSU LABORATORIES LTD.
１つ目の貢献の概要
(3/6)
 貢献１）世界で初めて，ロギングはソフトウェア開発の重要な実践
の１つであることを，定量的な根拠でもって示した
Finding
Implication
どの調査対象にも，平均して，30行に1行の
ロギングの実践は，ソフトウェア開発中
にはずっとどこででも行われている．
2
ログメッセージの存在は，ソフトウェア運用中
の故障診断を2.2倍早める．
ロギングの実践は，ソフトウェア運用中
の故障診断に効果的である．
3
平均して，ロギングコードは修正される割合
が約2倍ほど，全体の傾向よりも高い．
ロギングコードは開発者によって，頻
繁にメンテナンスされている．
4
ロギングコードの修正は全コミットの18%に
ロギングコードは，相対的に，ソフト
含まれ，コード全体に占める割合（1/30）に比 ウェア進化のかなりの部分を占めてい
べて高い．
る．
5
ロギングコードの修正の内約33%は，後から
補足的に行われたもの．その他の67%の修
正は，ロギング以外のコードの修正に伴って
行われたもの．36%以上のログメッセージは，
1度は後から修正されていた．
1 割合で，ロギングコードが存在している．
6
現在のアドホックなロギングの実践で
は，都度ログの品質問題が引き起こさ
れ．開発者は後からそれらを修正する
ことに，労力を払っている，
COPYRIGHT 2012 FUJITSU LABORATORIES LTD.
２つ目の貢献の概要
(4/6)
 貢献２）開発者がロギング実践時に苦労している点を明らかにし，
より良いロギングのための，新たな支援施策のヒントを示した．
Finding
Implication
6
ロギングコードの削除・移動は，ロギング
コードの修正の内わずか2%だけ．
目的の説明が不足しているため，ロギングコード
の削除・移動に保守的になるのではないか．
7
ロギングコードの修正の内，約26％はログ
出力レベルの訂正であり，その内の約72%
は，エラーに対する開発者の判断の変化を
反映したもの．
エラー状態を可視化するツールはロギングのテス
トに有効．テストツール・コード解析ツールは，開
発者がログ出力レベルを適切に判断できるような
情報を提供する必要がある．
8
ログ出力レベルの修正の内28%は，他のレ
ベルとのトレードオフを再考したもの．開発
者はコストと便益の調整によく悩まされる．
現在のスカラー値によるレベルの設定が悩ませ
る原因であり，適応的なロギングなど，トレードオ
フをうまく調整する，より知的な方法が必要．
9
ロギングコードの修正内27%は，変数を出
自動的にロギングすべき変数を推測してくれる
力するロギングコードについてのもの．その ツールは有用．Deltaデバッキング手法では，テス
内62%では，新たな変数出力を加えるもの． トケース群を用いて推測できる．
10
ロギングコードの修正の内45%は，静的な
文字列の修正．その内39%は，記録したい
実際の実行時情報との不一致を直すもの．
7
開発者はコード修正に伴うログメッセージ修正の
可能性により注意を払うべきで，自然言語処理と
コード解析の連携は，不一致の検出に有効だろう．
COPYRIGHT 2012 FUJITSU LABORATORIES LTD.
３つ目の貢献の概要
(5/6)
 貢献３）ログ出力レベルの設定間違いを自動検出するコードチェッ
カーを作成・評価し，我々の知見の有効性を示した
 手法の概要：
ログ出力レベル修正の例
 CP-Minerを使ってコードクローンを抽出し，ロギングコードを含むコードクローンの
内，ログ出力レベルが一致しないものを，設定間違いの候補として検出
 評価：
 4つのOSS（Apache httpd，OpenSSH，PostgreSQL，Squid）に適用したところ，
計138個の設定間違いの候補が検出された
• 10個は，ロギングのコンテキストが異なっており，false positiveな検出だと考察
• 24個は，出力レベルの修正が後に行われており，実際に設定間違いだったと考察
 単純なチェッカーであっても，ロギング実践の十分な支援になることがわかった
8
COPYRIGHT 2012 FUJITSU LABORATORIES LTD.
最後に
(6/6)
 大変読みやすい論文
 あげている10個の知見の説明では，それぞれに実際のロギングコードやコ
ミットログが図示されており，直観的にわかりやすい
 読み方として，時間の無い方でも，各知見の説明文と図を流し読むだけでも，
多くの情報を得られそう
 最後の評価では若干コードクローンに関する知識がいるが，それ以外には特
別な知識は殆どいらず，論文中に説明がある
 大変引用しやすそうな論文
 各知見は，開発経験のある方なら確かにそうかもと思える内容であり，それぞ
れに根拠となる数値が定量的に示されている
 調査から発見したことだけでなく，そこからどのようなロギング実践の支援が
有効かの考察を，他の研究を引用して行っている
 その他，貢献をわかりやすく説明している点も，好印象でした
9
COPYRIGHT 2012 FUJITSU LABORATORIES LTD.
(1/2)
Empirical Studies of Development
The Impacts of Software Process
Improvement on Developers:
A Systematic Review
10
COPYRIGHT 2012 FUJITSU LABORATORIES LTD.
概要
(2/2)
 ソフトウェア開発のプロセス改善（SPI）に関するサーベイ論文
 個々の論文ではプロセス改善の狭い部分を扱っているが、プロセス全体でど
ういう影響があるのかを調べたい
 調査手順
 論文誌や学会などからSPIに関する論文に対し、一定の評価基準で厳選
 ISHIKAWA（Fishbone）ダイアグラムに当てはめて知見を整理
 結論
 SPIのためにCMMIモデルなどの導入により障害の件数が減少し、士気向上
に有益だが、開発者には価値のないドキュメント作成を強いられ、工数が増大
11
COPYRIGHT 2012 FUJITSU LABORATORIES LTD.
(1/6)
Empirical Studies of Development
Combining Functional and Imperative
Programming for Multicore Software:
An Empirical Study Evaluating Scala and
Java
12
COPYRIGHT 2012 FUJITSU LABORATORIES LTD.
概要
(2/6)
 背景
 関数・手続き型のスタイルを両立できるマルチパラダイム言語（Scala）の出現
• 並列処理をこれまでより扱いやすくするものとして期待されている
 問題意識
 「マルチパラダイム言語に関して様々なこと（命題）が言われているが、本当に
正しいのだろうか?」
 問題へのアプローチ
 ScalaとJavaで同じプログラムを開発し、開発データを比較する
 結果
 Scalaに関する命題の真偽を実証した
• 「Scalaの方がJavaよりも生産性が高い」という命題は正しくない
• 「Scalaの方がJavaよりもコンパクトなコードになる」という命題は正しい
• 「関数型は手続き型よりパフォーマンスが悪い」という命題は正しくない
13
COPYRIGHT 2012 FUJITSU LABORATORIES LTD.
調査実験
(3/6)
 JavaとScalaで同じプログラムを開発
 被験者：修士課程の学生13人
• 2グループに分かれ、一方はJava版を先に、もう一方はScala版を先に開発
 題材：the Electric VLSI Design System (CADツール)の拡張
 開発期間：Java版、Scala版毎に4週間
 採取データ：工数、コード量、開発物の性能、インタビュー、etc.
 データ分析手法：box-and-whiskers plot, Wilcoxon’s rank sum test
• 中央値から上下4分位の1.5倍の幅に収まるデータを使用
被験者
タスク
採取データ
Java版開発
データ採取
Scala版開発
14
・工数
・コード量
・開発物の性能
・インタビュー
...
COPYRIGHT 2012 FUJITSU LABORATORIES LTD.
結果(1/3)
(4/6)
 1.命題「Scalaの方がJavaよりも生産性が高い」は正しくない
 開発工数を比較すると、Scala版の方がJava版よりも工数がかかっている
 並列処理のコーディングでもScalaの方が若干工数を要する
 テスト・デバッグに要する工数もScalaの方が顕著に高い
• Scalaの型推論や省略記法が解析に悪影響している
直列処理
コーディング
並列処理
コーディング
開発工数
テスト・デバッグ
Scala
中央値：14人時
平均値：18人時
Scala
Java
中央値：56人時
平均値：72人時
中央値：43人時
平均値：52人時
p値: 0.059
Scala
中央値：20人時
平均値：23人時
Java
Java
中央値：11人時
平均値：12人時
中央値：10人時
平均値：14人時
p値: 0.084
p値: 0.041
*グラフは論文より引用し、日本語のノートは本資料作成者が追加
15
COPYRIGHT 2012 FUJITSU LABORATORIES LTD.
結果(2/3)
(5/6)
 2.命題「Scalaの方がJavaよりもコンパクトなコードになる」は正しい
 予想していた通りの結論
コード行数
コード行数の
累積分布関数
文字数
p値: 0.078
Scala
中央値：533LOC
平均値：536LOC
文字数の
累積分布関数
p値: 0.094
Java
中央値：547LOC
平均値：632LOC
Scala
中央値：約28000字?
平均値：中央値と同程度?
Java
中央値：約34000字?
平均値：約36000字?
(文字数は論文中にデータを見つけられず)
*グラフは論文より引用し、日本語のノートは本資料作成者が追加
16
COPYRIGHT 2012 FUJITSU LABORATORIES LTD.
結果(3/3)
(6/6)
 3.命題「関数型は手続き型よりパフォーマンスが悪い」は正しくない
 被験者の成果物をベンチマークしたところ、JavaよりもScalaプログラムの方
が同等あるいはそれ以上の性能を出す場面も多い
• ただし、(スレッドの)並列度が高い場合はJavaの方がスケールする
並列度が低いと
Scalaの方が早い
並列度が高いと
Javaの方が早い
*グラフは論文より引用し、日本語のノートは本資料作成者が追加
 パフォーマンスが良いScalaプログラムは、関数型と手続き型の組合わせ
• パフォーマンス上位の各プログラムの40-60%は関数型スタイルで記述
17
COPYRIGHT 2012 FUJITSU LABORATORIES LTD.
18
COPYRIGHT 2012 FUJITSU LABORATORIES LTD.