Your SlideShare is downloading. ×
0
「コンテキストの理解による技法、事例の分析」森崎 修司
「コンテキストの理解による技法、事例の分析」森崎 修司
「コンテキストの理解による技法、事例の分析」森崎 修司
「コンテキストの理解による技法、事例の分析」森崎 修司
「コンテキストの理解による技法、事例の分析」森崎 修司
「コンテキストの理解による技法、事例の分析」森崎 修司
「コンテキストの理解による技法、事例の分析」森崎 修司
「コンテキストの理解による技法、事例の分析」森崎 修司
「コンテキストの理解による技法、事例の分析」森崎 修司
「コンテキストの理解による技法、事例の分析」森崎 修司
「コンテキストの理解による技法、事例の分析」森崎 修司
「コンテキストの理解による技法、事例の分析」森崎 修司
「コンテキストの理解による技法、事例の分析」森崎 修司
「コンテキストの理解による技法、事例の分析」森崎 修司
「コンテキストの理解による技法、事例の分析」森崎 修司
「コンテキストの理解による技法、事例の分析」森崎 修司
「コンテキストの理解による技法、事例の分析」森崎 修司
「コンテキストの理解による技法、事例の分析」森崎 修司
「コンテキストの理解による技法、事例の分析」森崎 修司
「コンテキストの理解による技法、事例の分析」森崎 修司
「コンテキストの理解による技法、事例の分析」森崎 修司
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

「コンテキストの理解による技法、事例の分析」森崎 修司

3,767

Published on

ソフトウェアテストシンポジウム2013北海道のテーマ「大人チャレンジ」に沿って苦手技術、手法の克服に向けてコンテキストの話をする機会をいただいたときのスライドです。ただ漠然と「新しい技術を身につけないとなぁ」というもやもやした状態から「これは自分が携わる開発でも効果が大きいからやらねば」「これはもう少し条件が揃わないとまだだなぁ」と分類、判断できるようになる状態になるための助けになれば。 …

ソフトウェアテストシンポジウム2013北海道のテーマ「大人チャレンジ」に沿って苦手技術、手法の克服に向けてコンテキストの話をする機会をいただいたときのスライドです。ただ漠然と「新しい技術を身につけないとなぁ」というもやもやした状態から「これは自分が携わる開発でも効果が大きいからやらねば」「これはもう少し条件が揃わないとまだだなぁ」と分類、判断できるようになる状態になるための助けになれば。

http://jasst.jp/symposium/jasst13hokkaido/report.html#closing

Published in: Technology
0 Comments
5 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
3,767
On Slideshare
0
From Embeds
0
Number of Embeds
11
Actions
Shares
0
Downloads
1
Comments
0
Likes
5
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. コンテキストの理解による技法、事例の分析 ー 苦手の対策にむけて ー 森崎 修司 http://blogs.itmedia.co.jp/morisaki http://twitter.com/smorisaki © 2013 Shuji Morisaki
  • 2. 自己紹介 – 森崎 修司 • サービス開発、SIに携わっていた。 – サービス開発 • 不特定多数のユーザを前提に定型サービスの開発 • 想定ユーザ(ペルソナ)の設定をはじめ、実装、運用まで – システムインテグレーション • エンドユーザから受注し、基本設計よりも後を再発注 – となりの部門では組込み用ソフトウェアを開発しており、そこで の話も漏れ聞いていた。 • 実証的ソフトウェア工学の研究に従事している。 – 国際シンポジウムのプログラム委員 – 多くのソフトウェア開発企業と対話・相談している。 • 7年間で400社との相談、30社程度とNDA下での連携 2 © 2013 Shuji Morisaki
  • 3. 勉強会の懇親会で なるほど。ウチはまだ まだだなぁ。いろいろ 障壁がありそうだし・・ テストの9割程度を 自動化できてだいぶ ラクになりました 自動販売機の 制御ソフトウェア 様々な業務の 請負開発 B社社員 A社社員 3 © 2013 Shuji Morisaki
  • 4. 会社に戻り・・・ • 次のプロジェクトで・・・ 今回はテストを9割自 動化するぞ。 はい。 B社社員 B社社員 © 2013 Shuji Morisaki
  • 5. 開発途中で・・・ えー? なんか、うまくいかないんで すけど..自動化したテスト 自体が間違ってたり、10回 分のリグレッションテストくら いの工数がかかりそうで・・ © 2013 Shuji Morisaki
  • 6. 開発が終わり... 自動化テストってダ メなんじゃない? あいつ、わかってな いなぁ コストも納期も オーバーしてしま いました.. © 2013 Shuji Morisaki
  • 7. 勉強会の懇親会で(再掲) なるほど。ウチもやる ように言ってるんです が、なかなか・・・ テストの9割程度を 自動化できてだいぶ ラクになりました 自動販売機の 制御ソフトウェア 様々な業務の 請負開発 B社事業部長 A社システム部門長 7 © 2013 Shuji Morisaki
  • 8. コンテキストと効果 • 他で効果のあった施策を自身でも試す場合には、施策の 効果が得られるコンテキストを明らかにする必要がある。 • 単純に「組込みソフトウェアだから」「ソフトウェア規模が大き いから」とコンテキストを定義してもうまくいくとは限らない。 8 © 2013 Shuji Morisaki
  • 9. 勉強会の懇親会で(再掲) なるほど。ウチもやる ように言ってるんです が、なかなか・・・ テストの9割程度を 自動化できてだいぶ ラクになりました 自動販売機の 制御ソフトウェア 少しずつ異なる多数の機種 がある。機種間で共通するテ ストがあり、いったん自動化す ると他機種でも流用ができる。 A社システム部門長 様々な業務の 請負開発 業務間で流用できるテストが ほとんどない。テストが共通 化できるような更改案件もそ れほど多くない。 B社事業部長 コンテキスト © 2013 Shuji Morisaki 9
  • 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

×