ソフトウェアレビューの効果を高める秘訣2つ：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
仕事柄、多くの方に「ソフトウェアレビューがうまくいかない。どうしたものか」という相談をいただきます。多くの場合、レビューの目的設定が不十分、参加者のマインドが醸成されていないことが原因になっています。 レビューの目的設定が明確にされていないことは多く、レビュー会議がはじまっていくつか欠陥が指摘されると「このレビューって結局どんな欠陥を検出すればいいんだっけ？」という状況になることは少なくありません。各々のレビューアが自身の経験に基づいて欠陥を指摘すると、必ずしも開発しているソフトウェアに求められるような（早期検出すべき）欠陥ばかりになるとは限りません。たとえば、ユーザ数が5ユーザ程度しかおらず、同時アクセスの可能性がほとんどないシステムに対して、同時アクセスやそのときの性能問題を指摘することは、必ずしも適切とは限りません。それよりも指摘すべき（優先順位の高い）欠陥があることが多いからです。
汎用的な観点ではなく業務特化の観点でのレビュー実施の効果を予想した研究：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
2013/3/12に「業務観点でのレビューを目指した不具合情報の分析」というタイトルで情報処理学会ソフトウェア工学研究会で発表しました。論文PDFはこちら。（本著作物の著作権は情報処理学会に帰属します。本著作物は著作権者である情報処理学会の許可のもとに掲載するものです。ご利用に当たっては「著作権法」ならびに「情報処理学会倫理綱領」に従うことをお願いいたします。） レビューのコスト削減効果は、レビューで検出して欠陥を修正したときのコストとレビューで見逃して（あるいはレビューを実施せず）レビュー以降のフェーズで欠陥を検出し、修正したときのコストの差です。@IT情報システムマネジメントの記事「レビューを「数」だけで管理しているからコストが膨らむ」で解説しています。 レビューで検出することによってコスト削減につながる欠陥をつきつめると、どのようなものになるでしょうか。おそらく対象ソフトウェアにとっ
ソースコード変更波及解析の8カテゴリ - どのくらいご存知ですか？：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
変更波及解析は既存のソフトウェアに変更を加えたら、どの場所に影響を与えるかを調べる方法です。影響は本来の意図であるものや本来意図していない副作用も含みます。変更波及解析が不十分だとデグレードする場合があります。 Steffen Lehnert氏のA Review of Software Change Impact Analysisという文献調査をしたテクニカルレポートがここで公開されています。調査対象の文献が182件ある大きめの調査です。網羅性や調査方法に関しても客観的な基準を与え、洗練した上で論文として公開されるのかもしれません。 このテクニカルレポートで紹介されている影響波及解析のカテゴリの一覧は以下のとおりです。10カテゴリのうち9番目は組合せ、10番目は「その他」なので、実質的には8カテゴリあります。どのくらいのカテゴリをご存知ですか？ いずれも完璧とはいかないまでも、変更波及解析
コードレビューやテストの優先順位付けに統計モデルが役立つか実際に試してみた論文：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
プログラムの規模が大きくなるとソースコードレビューやシステムテストをどこからはじめてよいか優先順位が付けにくくなります。優先順位は様々です。たとえば、欠陥を見逃した場合にリスクが大きくなるところからはじめる、多くのユーザが使う基本機能の正常動作からはじめる、依存関係が多く様々な部分から参照される共通モジュールからはじめる、今後も長期にわたって保守、拡張する部分からはじめるといった方針が考えられます。もちろん、できた部分から順番にという順位付けもあるでしょう。 優先順位のつけ方の一つとして、ソースコードの特徴から不具合がありそうなクラス、モジュール、メソッド、関数を予測する技法としてFault-proneモジュール予測という技法があります。過去の不具合のデータとソースコードの特徴を表わす数値をモデルに与え、不具合が起こりやすいソースコードの特徴を学習させます。数値は関数、メソッド、クラスとい
本質的でないレビュー指摘を減らすための試行を紹介した日経ITproの記事：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
要求ドキュメントや設計ドキュメントをレビューにおいて、誤字脱字の指摘の割合が高く本質的な欠陥の指摘が少ないというのは、どのような組織、プロジェクト、チームにおいても共通の悩みでしょう。 そのようなレビューを改善することを目的として、レビューで検出すべき欠陥の条件を変えて実務者の方にご協力いただいて検出結果を比較する試行をしました。 結果は論文で報告しています（S. Morisaki Y. Kamei K. Matsumoto: Experimental Evaluation of Effect of Specifying a Focused Defect Type in Software Inspection: PDFはこちらから）。ほぼ同じ内容の記事を以前に日経SYSTEMS（雑誌）に寄稿していました。昨日Web記事として日経ITproのサイトにも掲載いただきました。こちらから読めます。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
