2016年9月頃のメモ
- インスペクションは、欠陥の修正ではなく欠陥の検出に重点を置く。
- レビューアは、インスペクションミーティングに備えて準備を行い、発見された問題をリストにまとめてミーティングに向かう。
- レビューアはそれぞれ、設計やコードのエラーをあらかじめ洗い出しておく。レビューアはチェックリストを基に、設計やコードの調査方針を決定する。
- 1時間でレビューするのは、1時間に100行ほど？
- ミーティングで解決策を話し合ってはならない。参加者はエラーの検出に全力を挙げること。
- 誰かがエラーと考えるような紛らわしいものならば、設計、コード、ドキュメントを明確にする必要がある。
- ミーティングは、一日1回2時間以内
- モデレータはインスペクションレポートをその日のうちに作成する。
- 解決策は3時間目以降に話し合うのでもよい。
ソフトウェア職人気質
- フォーマットの基本定理とは、「視覚的に優れたレイアウトはプログラムの論理構造を明らかにする」
- コードの論理構造を正確に表現する
- コードの論理構造の表現に一貫性がある
- 可読性を向上させる
- 変更に耐える
-
レビューの目的は修正工数を減らすこと
- 問題を指摘すると、修正工数の低減につながるかどうか
- 修正工数を低減させるために、指摘すべき問題をすべて洗い出しているか
-
目的を見失わないように、シナリオにそって問題検出する
-
問題検出が目的で、修正はしない
-
一つの観点だけで通読する。複数の観点で一度にまとめてチェックしない
-
時間配分のムラが起きないようにする
- 以前の類似タスクにおけるレビューでの指摘内容
- 以前のテストで見つかった不具合 (レビューで見逃されたもの)
- 見落として大きな手戻りが発生しそうなもの
- システムの本来の目的や最も大事な機能について考え、システムの価値を明らかにする。その価値を阻害する問題種別を設定する。
- 現状困っている課題を解決する場合
- その課題が解決できるかを問題種別にする
- システムがビジネスや業務へサービスする内容から価値を見つける場合
- 顧客からの要求に隠れている、本当に重要なシステムの価値を阻害する問題種別
- こういったアプローチによって考えた問題種別を5〜10個を目安に絞り込む
- 現状困っている課題を解決する場合
例: アカウント認証システムの特徴と価値
- 目的: グループ会社向けアカウント認証
- 特徴:
- 多くの社内システムの認証に使われる
- 社員が増えたりして認証回数が増えることがある
- 利用状況の把握ができていない
- 時間帯によってはスループットが低下することがある
- 価値:
- アカウント認証がただしくできる
- スループットが安定する
- サーバ増強の判断が適切にできる
- ここから導かれるシナリオ:
- ネットワーク機器の性能が対象ドキュメントに明記されているかチェックする。明記されている場合、機器の仕様と付き合わせて誤りがないか調べる。
- ネットワーク構成図から、認証システムのあるネットワークの最大帯域が、認証を受け取るネットワークの帯域と同じかそれよりも小さいかチェックする。
- その際、認証システムの最大帯域は、今後の拡張があることを前提に置く。
- ここで言うシナリオとは、選定した問題種別を検出するために、「どこ」を「どのように」調べるのかを具体的に記述した文
- 例: 機能間で入出力の不整合がないか調べるため、インターフェース定義をチェックする。入出力の項目の名前と型が一致することを確認する。
- レビューアーの知識に依存しないように、具体的に「どこ」を「どのように」調べるのか記述する
- 修正工数やリスクの低減効果が大きいシナリオを優先する
- 次に優先すべきなのは、漏れに関するシナリオ
- その次は、曖昧さに関するシナリオ
- 要件定義書
- 業務フローの開始条件、終了条件
- 性能、信頼性、セキュリティなどの非機能要件
- システム境界の定義
- 追加と削除、のような対になるべき要件
- 基本設計書
- 実現されていない要件
- システムの運用に必要な機能。ログ出力、実行監視、ハードウェア監視
- 機能間の依存関係の定義
- ユーザーとの入出力
- 詳細設計書
- 例外処理
- データ定義、データの取りうる値の定義
- リソース取得と解放のタイミング
- 機能の物理的配置。どのサーバ、どのクライアントでその機能を実現するのか
「〜など」、指示詞、「処理する」「対応する」とかいっぱい
- インスペクションの準備 p.60
- 作業成果物を異ラベル準備、欠陥チェックリストなど p.93 - 101
- インスペクションデータを分析する p.141
メトリクスの選択: GQM (Goal Question Metric 法 - Basili and Rombach 1988)
- ゴールが何かを定義する
- そのゴールを達成できたかどうかを判断するために答えるべき質問を決める
- その質問に応えるために必要なメトリクスを選択する
インスペクションによって手戻りコストを減らすというゴールなら、
- 各プロジェクトにおいて開発工数のナン%が手戻りに費やされたか
- インスペクションに要した工数はどれくらいか。
- インスペクションによって節約された工数はどれくらいか。
- インスペクションで発見した欠陥の数。それらの種類。それらの重大性。ライフサイクルのどのフェーズか。
- 作業成果物の欠陥のうち、何パーセントをインスペクションで除去できているか。
- インスペクションを実施した作業成果物は、実施しなかった作業成果物に比べて、テスト・デバッグ・保守に費やした時間は少なくなっているか。
測定アクティビティ: 下に進むほど利益が増加 (p.143)
- 生データ項目を集める
- メトリクスを計算する
- 指標: 準備およびインスペクションの速度、欠陥密度、インスペクションの有効性
- 平均値を取る
- 上の指標について、チームの平均値と傾向を調べる
- 傾向を見る
- 一定の条件下で、異常なインスペクション結果を検出できるようになる
- メトリクスの相関を見る
- 準備の速度が上がると、インスペクションの効率に同影響するかなどがわかる
- 欠陥原因分析を行う
- 統計的プロセス管理を行う
準備速度 (LOC/時): 一人のインスペクタが準備のときに1時間で調べられる平均コード行数
準備速度などのメトリクスの異常値があれば注目し、調査する。
- ウォータフォールモデルだと、手戻りが発生することがコストなので、開発途中で見つかった欠陥の数が少ないほうがよい
- アジャイル開発だと、 PDCA サイクルを回した回数だけ品質が上がるので、開発途中で見つかった欠陥の数が大きいほうがよいかも？
- だから、本にかかれているメトリクスを単純には利用できないかも
- いつ欠陥報告が来たかは重要でなく、欠陥の原因となるコードや設計がいつ混入したかが重要
- 原因を調査し、いつ欠陥の原因となるコードや設計が混入したか調べる
- インスペクションがきちんと動いている時期なら、その時期の欠陥発生数が低くなるはず
- 原因
- 原因となるコードや設計が混入した時期
- 誰がどういった経緯で欠陥となる原因を引き起こしたか
- なぜ引き起こしたか
すべての課題は、欠陥修正と機能追加に分けられる？