「コンテキストの理解による技法、事例の分析」森崎 修司
- 1. コンテキストの理解による技法、事例の分析 ー 苦手の対策にむけて ー 森崎 修司 http://blogs.itmedia.co.jp/morisaki http://twitter.com/smorisaki © 2013 Shuji Morisaki
- 2. 自己紹介 – 森崎 修司 • サービス開発、SIに携わっていた。 – サービス開発 • 不特定多数のユーザを前提に定型サービスの開発 • 想定ユーザ（ペルソナ）の設定をはじめ、実装、運用まで – システムインテグレーション • エンドユーザから受注し、基本設計よりも後を再発注 – となりの部門では組込み用ソフトウェアを開発しており、そこで の話も漏れ聞いていた。 • 実証的ソフトウェア工学の研究に従事している。 – 国際シンポジウムのプログラム委員 – 多くのソフトウェア開発企業と対話・相談している。 • 7年間で400社との相談、30社程度とNDA下での連携 2 © 2013 Shuji Morisaki
- 4. 会社に戻り・・・ • 次のプロジェクトで・・・ 今回はテストを9割自 動化するぞ。 はい。 B社社員 B社社員 © 2013 Shuji Morisaki
- 5. 開発途中で・・・ えー？ なんか、うまくいかないんで すけど．．自動化したテスト 自体が間違ってたり、10回 分のリグレッションテストくら いの工数がかかりそうで・・ © 2013 Shuji Morisaki
- 8. コンテキストと効果 • 他で効果のあった施策を自身でも試す場合には、施策の 効果が得られるコンテキストを明らかにする必要がある。 • 単純に「組込みソフトウェアだから」「ソフトウェア規模が大き いから」とコンテキストを定義してもうまくいくとは限らない。 8 © 2013 Shuji Morisaki
- 10. 苦手の対策に向けて • 苦手意識はどこからくるのか？ – – – – 開発メンバの多くの賛同を得なければならない。 単純に性に合わない。 習得する知識やスキルが多く、時間がかかりそう。 自身のコンテキストでは効果が出ないと直感的に感じている。 • 例）テスト自動化への苦手意識 – 他のテストエンジニアも自動化しないと効果が出ないのか？ – 自動化するテストケースの準備を事前にするのが億劫なのか ？ – ツールやフレームワークを使いこなすのに時間がかかりそうなの か？ – テスト自動化によって省力化できなさそうな理由があるか？ 10 © 2013 Shuji Morisaki
- 11. 苦手の対策に向けて • コンテキストを意識すれば・・・ – 単純な苦手意識であれば、克服できるよう手を施す。 – よりつきつめて効果が本当に得られるのかを考えることができ る。 • 漠然と「あー、何か勉強せねば・・」という気分を持ち続けるこ とが減る。 – 苦手意識を克服できるような機会を待つ。 – 効果が出ないと判断している場合には、効果がでる状況にな るまでは着手しない。 11 © 2013 Shuji Morisaki
- 12. アジェンダ • • • • コンテキストの違いによる効果の違い メトリクスを用いた手法とコンテキスト リファクタリングとコンテキスト コンテキストを明らかにするための着眼点 12 © 2013 Shuji Morisaki
- 13. Fault-proneモジュール予測 • 不具合のありそうなソースコードモジュールを予測する手法 （prone: ～の傾向がある） – モジュール: クラス、ソースコードファイル、・・・ 不具合の ありそうな順 モジュール群 予測モデル モジュール群 13 © 2013 Shuji Morisaki
- 14. Fault-proneモジュール予測 • 不具合のありそうなソースコードモジュールを予測する手法 プロダクトメトリクス （prone: ～の傾向がある） 過去の不具合とソースコードメトリクスの関 係をモデル化、経験則から予測 – モジュール: クラス、ソースコードファイル、・・・ プロセスメトリクス 編集作業をはじめとした開発作業を計測し、 経験則から予測 不具合の ありそうな順 モジュール群 予測モデル モジュール群 14 © 2013 Shuji Morisaki
- 15. 変更履歴と不具合分析: FixCache*1 • FixCache: 同じモジュールで不具合が再発しやすいという 経験則を使って予測する。 – 7つのオープンソースプロジェクトの変更履歴約200,000件で 実証 – 「メモリキャッシュ」のアルゴリズムを用いて不具合の可能性 の高いモジュールを選出 – 全体のソースコードファイルの1割で73～95%の精度で不具 合を予測できた。 • Googleでのソースコード更新履歴に基づく不具合予測に応 用されている。*2 *1: Kim S., Zimmermann T., James E. W., Zeller A., “Predicting Faults from Cached History” In Proceedings of the 29th international conference on Software Engineering , p. 489-498. *2: Lewis C., Ou R. “Bug Prediction at Google” http://google-engtools.blogspot.jp/2011/12/bugprediction-at-google.html 15 © 2013 Shuji Morisaki
- 16. FixCacheの活用 • ご自身の開発にFixCacheを使うと効果が出そうですか？ – 不具合のありそうなモジュールからテストすると余裕をもった 修正ができます。 – プログラマに「ここは要注意のモジュールです」と伝えることが できます。 • 理由は？ 16 © 2013 Shuji Morisaki
- 17. リファクタリング • コードリファクタリング（code refactoring: 継続的改善の一つ） – プログラムのふるまいを変えず、ソースコードの保守性、拡張 性を高める。 – 変更を繰り返したり、場当たり的なコード記述をすることでソー スコードの見通しが悪くなり、リファクタリングが必要となる。 リファクタリング対象となるコードの例 aggregateTotal(a, b, c){ total = a + b + c; shipping = 0; if (total < 3000) { shipping = 800; } total = total * 1.05; return total; } aggregateTotal_008(a, b, c){ total = a + b + c; shipping = 0; if (total < 3000) { shipping = 800; } total = total * 1.08; return total; } 17 © 2013 Shuji Morisaki
- 18. リファクタリング • コードリファクタリング（code refactoring: 継続的改善の一つ） – プログラムのふるまいを変えず、ソースコードの保守性、拡張 性を高める。 – 変更を繰り返したり、場当たり的なコード記述をすることでソー スコードの見通しが悪くなり、リファクタリングが必要となる。 リファクタリング対象となるコードの例 aggregateTotal(a, b, c){ total = a + b + c; shipping = 0; if (total < 3000) { shipping = 800; } total = total * 1.05; return total; } 重複 aggregateTotal_008(a, b, c){ total = a + b + c; shipping = 0; if (total < 3000) { shipping = 800; } total = total * 1.08; return total; } 18 © 2013 Shuji Morisaki
- 19. リファクタリングの実施 • ご自身の開発でリファクタリングを実施すると効果がありそう ですか？ – 将来の変更が簡単になったりバグが混入しにくくなります。 – 将来的にデグレードが減る可能性があります。 • 理由は？ 19 © 2013 Shuji Morisaki
- 20. コンテキストを明らかにするための着眼点 • エンピリカルソフトウェア工学の論文*で紹介されている。 – – – – – – – プロダクト プロセス プラクティス・ツール・技術 開発に関わる関係者 組織 組織タイプ（マトリクス型組織、階層型組織など） 市場 * K. Petersen and C. Wohlin, Context in Industrial Software Engineering Research, In Proceedings of the 3rd International Symposium on Empirical Software Engineering and Measurement (ESEM ’09), pp. 401-404(2009) ソフトウェア品質のホンネ 第114回「コンテキスト把握のための6つの分類」でも紹介しています。 http://www.juse-sqip.jp/wp3/honne/backnumber_114/ 20 © 2013 Shuji Morisaki
- 21. まとめ • コンテキストの違いによるテスト自動化の効果の違いを紹介 した。 • コンテキストを意識することで、単なる苦手意識か前提が 揃っていないかが明らかになることを示した。 • コンテキストを意識した上で手法を実施すると効果があるの かどうか検討いただいた。 – Fault-proneモジュール予測 – リファクタリング • 参考文献: 奈良先端科学技術大学院大学:ソフトウェア開発におけるエンピリカルアプロ ーチ、アスキー(2008) 21 © 2013 Shuji Morisaki