チェックリストを使えばレビューの指摘件数増に統計的有意差があったという報告。で、チェックリストをどう使えばよいか？：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
チェックリストを使えばレビューの指摘件数増に統計的有意差があったという報告。で、チェックリストをどう使えばよいか？ 情報処理学会第170回ソフトウェア工学研究会で発表した内容。坂東祐司、森崎修司、松本健一「セキュリティ要件のレビューにおけるチェックリストの表記方法の比較」。 チェックリストに収録された質問に答えていくことにより、レビュー対象の欠陥を検出する。論文では、90名超の協力者による実験を実施し、チェックリストを使わない場合、表記方法だけが異なる2種類のチェックリストの3つのグループで、指摘の正答数、正答率を調べた。チェックリストを使わない場合と比較するとチェックリストを使用したほうが、正答数、正答率ともに向上し、統計的有意差があった、というもの。 チェックリストを使ったほうが欠陥の検出数、正答率も高くなるという結果となった。今回のチェックリストは論文のタイトルのとおり、セキュリティ
ソースコードのコメントよりも空白行のほうが理解を助けるという研究結果：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
IEEE Transaction on Software Engineeringの論文Raymond P.L. Buse and Westley R. Weimer: Learning a Metric for Code Readabilityから。120人の被験者が10種類のオープンソースプロジェクトのソースコードの一部（20行等、非常に局所的）をもとに読みやすさに影響を与えることを実験結果から示している。 25種類のメトリクスと読みやすさとの相関を求めている。メトリクスには、コメント行数や予約語の数、空行の数、括弧の数、変数名の長さ、変数の個数などが含まれる。このうち、読みやすさに最も影響を与えやすいメトリクスとして、1位に変数の個数、2位に行数、3位に括弧の数、9位に空行数、15位にコメント行数が示されている。 この論文では、多くの人に短時間で読みやすさが評価できるように、対象ソース
Design by contractでソフトウェア機能を記述する：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
Design by contractはソフトウェアの機能や関数/メソッドの事前条件、事後条件、いかなる場合でも不変である状態（条件）、を明らかにし、文書化する手法だ。機能や関数/メソッドが想定している範囲を明らかにし、想定外の使われ方を防ぐことにより不具合防止を支援する。 条件をソースコードに含めておき、条件を満たさない場合に、実行をやめたりするものを契約プログラミング（Programming by contract）と呼ぶ。assertのような言語仕様を使ったり、例外処理を使ったりして、機能や関数/メソッドが想定外の使われ方をしていることを明らかにする。 外部仕様に相当するドキュメントにはこれらの条件が比較的記述されていることが多いように思う。詳細設計、内部仕様やソースコードに記す場合には、対象の数が多くなることもあり、網羅的に記述するのはしんどいところだろう。形式的でないドキュメントに
ソフトウェアレビューのメリットは？：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
ソフトウェア開発でのレビューといえばソフトウェアに含まれる不具合や矛盾を早期に発見しようとする作業やその承認作業をさす。ソフトウェアに含まれる不具合や矛盾は早い段階で修正されればされるほど、その修正にかかる工数が小さくなることがいくつかの事例で確認されており、また多くの方に直感的/経験的に感じられているだろう。レビューは実際にプログラムを実行しながらテストをする前に実施できるので、テストよりも早く不具合や矛盾を抽出できることがあり、修正工数の低減に寄与する。 レビューの対象は多岐にわたる。ソフトウェア開発の成果物、中間成果物のほとんどはレビューの対象とできるだろう（効率的であるかどうかは別として）。要求仕様、外部設計仕様、ソースコードはもちろんのこと、テスト仕様（テスト設計）、テストケースもその対象といえるだろう。レビューの対象としてポピュラーなのは設計書やソースコードだろう。 レビューの
メトリクスをはかったものの．．．というときに：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
ソフトウェアの開発規模が大きくなるにつれ、多くの組織では何らかのメトリクスを計測し異常の検出に使っている。もちろん、はかることによるオーバヘッドが無視できない、はからなくてもうまくいっているのであれば、そのまま進めたほうがよいだろうが、なかなかそうもいかないというのが実情ではないだろうか。 よく用いられるメトリクスとして、規模（ソースコード行数、ドキュメントページ数、Funtion Point）や品質（テスト密度、バグ密度、レビュー指摘密度、チェックリスト密度）がある。これらが一定の範囲におさまっていなければ、会議の議題にあげたり、再チェックしたり、というふうに使っているだろう。また、EVM（Earned Value Management）のような利用用途が明確なものであれば、利用方法に困ることはないだろう。 それ以外のメトリクスをどう使うかというところに悩んでいる組織も多い。たとえばソー
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
