間違いだらけの ドキュメントレビュー 森崎 修司 静岡大学 情報学部 [email protected] twitter.com/smorisaki 自己紹介 森崎 修司 • サービス開発とインテグレーション（2001～） – オンラインストレージサービスの開発 • 通常の（当事者）レビュー • プロジェクトマネジメント – 第三者レビュー: 無線ICタグの研究開発に従事 • EPCglobal（無線ICタグの国際標準化団体）でソフトウェアの標準化活動 • サービス化、ソリューション化 • ソフトウェアレビューの研究（2005～） – 250社超との相談、18社と機密保持契約ベースの共同研究 – レビュー観点の設定、効果測定、レビューとテストのバランス – Fraunhofer研究機構（ドイツ）とソフトウェアレビューに関する国際連携 http://www.software-inspection-wg.org • 好きなこと – 凝った異常系の仕組みが動くかどうかシナリオテストしている瞬間 © 2011 Shizuoka University and Shuji Morisaki, All rights reserved 私の研究グループで目指すところ • ソフトウェア開発者と研究者のエコシステムを作る。 – 日本では「研究者に聞けば何かわかる」という状況には必ずし もない。 – スウェーデン、ドイツでは一部で互助機能ができあがりつつあ る。 コンテキストの分析、観測結果、 技法、プラクティス 開発者 フィールドデータ、 フィードバック 研究者 詳細はhttp://www.atmarkit.co.jp/news/200912/21/review.html をご覧ください 3 © 2011 Shizuoka University and Shuji Morisaki, All rights reserved ソフトウェアレビュー • プログラムが動作する前に（中間）成果物に問題がないか を目視で確認する静的解析技法 • 目的 – 不具合の修正コストの低減 – 状況把握と承認 – 保守性向上 • インプット 各種ドキュメント（ソースコードを含む） • アウトプット インプットのドキュメントに含まれる問題点のリスト • 課題 実施の自由度が高く、エビデンスが残りにくい。 4 © 2011 Shizuoka University and Shuji Morisaki, All rights reserved 自由度の高さ ー レビューが難しい理由(1/2) • 指摘しようと思えば、どんなふうにでも指摘できる。 • 「指摘せずにはいられない」欠陥もある。 我々の研究グループでの調査 協力者数 試行A1 37名 試行A2 レビュー対象 設計ドキュメント お願いの 内容 誤字脱字の指摘はし 特になし ないでください 指摘 誤字脱字の指摘 8% 誤字脱字の指摘 42% © 2011 Shizuoka University and Shuji Morisaki, All rights reserved 自由度の高さ ー レビューが難しい理由(2/2) • 指摘しようと思えば、どんなふうにでも指摘できる。 • 「指摘せずにはいられない」欠陥もある。 協力者数 我々の研究グループでの調査 試行B1 試行B2 80名 レビュー対象 ソースコード お願いの 内容 パスワード再発行時にな 特になし りすましの可能性はあり ますか？ 指摘 18%はパスワードとは関 係のない指摘 81%はパスワードとは関 係のない指摘 © 2011 Shizuoka University and Shuji Morisaki, All rights reserved レビューのフェーズ ・インタフェースの不整合 ・フォントが不統一 ・データ定義が不完全 ・必要なテスト環境は？ ・実現できる性能か？ ・・・・・・ ドキュメント 欠陥検出 作成 ドキュメントから欠陥を見つける 他にインタフェースの 不整合はないかな？ インタフェースX とYの間に不整 合があるように 思います 欠陥指摘 見つけた欠陥を指摘し確認する 欠陥 修正 7 © 2011 Shizuoka University and Shuji Morisaki, All rights reserved 時間切れ ー 欠陥検出での間違い（1） • 一部だけで中途半端に終わっている。 – 特定の部分ばかりをみていて他の部分はみていない。 – 前半ばかりみていて後半をみていない。 – エラーコードの整合性ばかりみていて性能問題をみていない。 対象ドキュメント © 2011 Shizuoka University and Shuji Morisaki, All rights reserved 作成者気分 ー 欠陥検出での間違い（2） • 「作り直してやろうか」と考える。 • 書き直しの後のレビューを加味すると書き直したほうがコス トが大きくなる場合が多い。 抽象クラスで美しくなる・・・ 対象ドキュメント © 2011 Shizuoka University and Shuji Morisaki, All rights reserved 人間関係の持込み ー 欠陥検出での間違い(3) • 作成担当者によって力の入れ方を変える 後輩A担当分 つけあがらない ように細かくみ ておこう リーダB担当分 間違いはないだ ろうし、指摘して にらまれたらイヤ だから軽めに・・ © 2011 Shizuoka University and Shuji Morisaki, All rights reserved 意地の張り合い ー 欠陥指摘での間違い(1) • 「何か言わないと・・」と焦ってしまい、本質でないことを口に 出す。 対象ドキュメント な、何か言 わないと・・ インタフェースX とYに不整合が レビューアA 排他制御が できていない レビューアB レビューアC © 2011 Shizuoka University and Shuji Morisaki, All rights reserved 人格攻撃 ー 欠陥指摘での間違い(2) • 欠陥以外を指摘している。 こんな基本的なこと もわかっていないの にエンジニアやって るの？ レビューアA 設計はつまると ころセンス。セン スがないんだよ 作成者 © 2011 Shizuoka University and Shuji Morisaki, All rights reserved 意図的な見逃し ー 欠陥指摘での間違い(3) ここで何か指摘 すると電車で家 に帰れなくな る・・。 あー眠 レビューアA レビューアB アイツ、自分の 担当部分を指摘 すると逆上する からなぁ レビューアC © 2011 Shizuoka University and Shuji Morisaki, All rights reserved 間違いのまとめ • 欠陥検出: 無計画、無方針が原因 – 時間切れ – 作成者気分 – 人間関係の持込み • 欠陥指摘: 役割分担、信頼感の不足が原因 – 意地の張り合い – 人格攻撃 – 意図的な見逃し © 2011 Shizuoka University and Shuji Morisaki, All rights reserved 間違いと対策 • 欠陥検出: 無計画、無方針が原因 – 時間切れ – 作成者気分 – 人間関係の持込み → 読み進め方の方針を与え限定する。 • 欠陥指摘: 役割分担、信頼感の不足が原因 – 意地の張り合い – 人格攻撃 – 意図的な見逃し → 役割を明確にし各々の分担や責任を明確化する。 © 2011 Shizuoka University and Shuji Morisaki, All rights reserved リーディングテクニック （レビュー技法） • Defect-based reading（欠陥種別による着眼点設定） – 観点ごとに以下の着眼点から問題検出する。 • 抜け • 誤り • 曖昧さ • Perspective-based reading（役割による観点設定） – 開発プロジェクトでの役割を想定して問題を検出する。 • ユーザ（利用部門） • テストエンジニア • プログラマ – 役割の定義と読み進め方の方針を事前に合意しておく。 – 役割は必ずしも実際の立場でなくてよい。 例）PMがユーザでもよい。 © 2011 Shizuoka University and Shuji Morisaki, All rights reserved Defect-based reading • 三大着眼点として「漏れ」「誤り」「曖昧」がある。 • 漏れ – 記述や実装が漏れている。 • 誤り – 記述されている情報が誤っている。 • 曖昧 – 何通りかに解釈でき、解釈によっては誤って実装されてしまう。 出典: A. Porter, L. Votta and V. Basili, “Comparing Detection Methods for Software Requirements Inspections: A Replicated Experiment,” IEEE Transactions on Software Engineering, Vol. 21, No. 6, pp. 563–575 (1995) 17 © 2011 Shizuoka University and Shuji Morisaki, All rights reserved 漏れ - Defect-based reading • 「誤り」「曖昧」よりも検出が難しい。 • 検討漏れ – 検討さえされていない。 – ログ出力やログがいっぱいになる等 • 記述漏れ – 検討されていたが記述するのを忘れている。 – わざわざ書かなくても常識に該当するので書かなかった。 – 「常識」とは？ • ドキュメントをみる前に「ソフトウェアのあるべき姿」「書いてな ければならない項目」をイメージする。 → 想定した内容と実際のドキュメントを比べて漏れを検出 する。 18 © 2011 Shizuoka University and Shuji Morisaki, All rights reserved 漏れ - Defect-based reading 「漏れ」のチェックリスト例 対象 漏れを発見するための着眼点 要件定義 ・シナリオ、業務フローの開始／終了条件 ・性能・信頼性・セキュリティ等の非機能要件 ・システム境界の定義 ・「追加」「削除」など、対になるべき要件 基本設計書 ・実現されていない要件 ・運用／保守に必要になる機能（状態監視・運用手順等） ・機能間の依存関係 ・ユーザとの入出力 詳細設計書 ・例外処理 ・データ定義、データの取り得る値 ・リソース取得／解放のタイミング ・機能の物理的配置（機器、サーバ、コア） より詳細な情報: 森崎 修司，間違いだらけのドキュメントレビュー「第2回 問題検 出 その1」 日経SYSTEMS 2011年5月号，pp. 102-105 19 © 2011 Shizuoka University and Shuji Morisaki, All rights reserved 誤り - Defect-based reading • 不整合が原因 – 外部で開発（定義）されたドキュメントやコード – 開発しているドキュメントやコードの他の部分 • 外部との不整合を検出する。 – ブラウザが送出する文字コードとサーバ側の文字コードの一 致 • 内部との不整合を検出する。 – データ型、上限値、下限値の機能間、モジュール間での一 致 20 © 2011 Shizuoka University and Shuji Morisaki, All rights reserved 曖昧 - Defect-based reading • 読み手によって複数の解釈ができることが原因 （解釈できないこともある） 自然言語での曖昧さの例 表現 説明 など 「など」に該当する要素が何なのか明確でない場合がある。該当 する要素全て書き出すか「～を満たすもの」と条件を明示する。 処理する 対応する 具体的に何をすればよいのか明確でない。具体的な演算や入 出力を明示する。 すぐに ただちに 切れ目なく連続させるのか、若干の間隔をおいてよい場合の2通 りがあり、曖昧になりがち。 ～を考慮して どの程度加味するのかはっきりしない。加味する情報をどう利用 ～を踏まえて するのか具体的に書く。 より詳細な情報: 森崎 修司，間違いだらけのドキュメントレビュー「第2回 問題検出 その 1」 日経SYSTEMS 2011年5月号，pp. 102-105 21 © 2011 Shizuoka University and Shuji Morisaki, All rights reserved Defect-based readingの評価 • “Scenario”がDefect-based readingに該当する。 • 網羅性が上がっている。 出典: A. Porter, L. Votta and V. Basili, “Comparing Detection Methods for Software Requirements Inspections: A Replicated Experiment,” IEEE Transactions on Software Engineering, Vol. 21, No. 6, pp. 563–575 (1995) 22 © 2011 Shizuoka University and Shuji Morisaki, All rights reserved Perspective-based reading イメージ •契約との整合性 •検収条件 •実装に必要 な情報は？ •このプログラ ム起動はどこ で？ •業務軽減にな る？ •使い勝手は？ 発注者 プログラマ 利用部門 テストエンジニア © 2011 Shizuoka University and Shuji Morisaki, All rights reserved •テストできるの か？ •「すばやく」って 何秒？ Perspective-based readingのシナリオ例 • 各役割の読み進め方を定義したものをシナリオと呼ぶ。 プログラマの役割とそのシナリオ例 初級プログラマ エキスパートプログラマ 前提 対象システムに知識がない 対象システムの知識豊富 指示 ユースケースをもとにレビュー もっとも複雑、重要なクラスからレビュー 質問 ・ソースコード中のコメントやドキュ メントは十分でしたか？ ・ユーザ操作が関与する部分に おいてエラー、例外処理はありま すか？ ・エラー、デバッグのためのログ 出力はありますか？ ・データ構造は適切に使われています か？また、実行速度やメモリ使用量との トレードオフは考慮されていますか？ ・このクラスで実現されている機能は今 後の開発でも必要になりそうですか？再 利用性を高めるための追加工数をかけ る価値がありそうですか？ 出典: C. Denger, F. Shull: “A Practical Approach for Quality-Driven Inspections,” IEEE Software 24(2), pp. 79-86 (2007) © 2011 Shizuoka University and Shuji Morisaki, All rights reserved Perspective-based readingの実験的評価 • 2種類の要求定義ドキュメント においてレビューア間で指摘 欠陥の重なりが少ないことを 示している。 • 役割 – D: 設計者 – U: ユーザ – T: テストエンジニア • (a), (b)はグループを示す。 出典: J. C. Maldonado, J. Carver, F. Shull, S. Fabbri, E.Dória, L. Martimiano, M. Mendonça, V. Basili, International Journal of Empirical Software Engineering, vol. 11, no. 1, p. 119-142(2006) © 2011 Shizuoka University and Shuji Morisaki, All rights reserved まとめ • ドキュメントレビューの難しさは自由度にある。 • ドキュメントレビューにありがちな間違いを紹介した。 – 欠陥検出 – 欠陥指摘 • ありがちな間違いを低減する方法のうち2つを紹介した。 – Defect-based reading – Perspective-based reading – 欠陥記録シートを我々の研究グループのWebで公開してい ます。 http://lab.inf.shizuoka.ac.jp/morisaki/templates_reviews_and_inspections.html • 詳細は日経SYSTEMS 2011年4～9月号の連載記事「間 違いだらけのドキュメントレビュー」で解説している。 © 2011 Shizuoka University and Shuji Morisaki, All rights reserved 謝辞とお願い • 謝辞 – 本セッションで紹介した私の研究グループの統計データは志 ある企業、エンジニアの方々から提供いただいたものです。 – いただいたデータがエンジニアの皆様のお役に立つよう精進 いたしますので、今後ともよろしくお願いいたします。 • ユーザ企業の皆様へお願い – 本日お知らせした観点・着眼点・範囲の絞り込みを様々な方 法で試しております。 – 方法の1つとして日本語ドキュメントの解析の研究を進めよう としております。 – ご協力いただける可能性がある場合、ご挨拶させていただけ ればと思います。 © 2011 Shizuoka University and Shuji Morisaki, All rights reserved お知らせ 1. 論文、記事等の公開情報をお知らせするメールニュースご希 望の方はメールアドレスをお知らせください。 – – – – From: 情報をお送りするメールアドレス To: [email protected] Subject: 論文、記事等の公開情報のお知らせ希望 本文 ご氏名: ご所属: – いただいた情報を本来の目的以外で使用することはありません。 2. 当研究グループとの具体的な連携（有償の受託・共同研究） を募集しています。 – – 詳細な統計データや海外動向との比較ができます。 首都圏の拠点の企業とも多く連携しています。 © 2011 Shizuoka University and Shuji Morisaki, All rights reserved 28
© Copyright 2024 Paperzz
