内部設計に基づいて、実際にプログラムを作成する
- 変数の命名規則やコメントの書き方など、プログラムの標準的な記述方式を定める
- 目的：ソフトウェアコードの保守性を向上させること
- 実施の目的・ねらい
- 仕様の不備や設計の誤りなどを早期に発見し、手戻り工数の削減を図る
- 設計の工程ごとに設計品質の評価を行い、各工程が終了したかどうかを判断する
- 成果物の問題点の早期発見を行う
- 内部設計書のデザインレビューを実施する目的
外部設計書との一貫性の検証と要件定義の内容を満たしていることの確認 - 外部設計のデザインレビュー
要件定義の内容に関する妥当性の評価と外部設計指針の見直し
- 従来型レビュー
- 管理者主体のレビュー手法
- 目的
- プロジェクトの状況把握と関係者への徹底
- プロジェクトを完成させるための方策の検討
- プロジェクトの成果物に対する技術的評価
- 進め方
- ミーティング形式で進める
- 議論の進め方には制約がなく、発言は自由
- 問題点
- 問題点の検出だけでなく解決策まで及ぶため時間がかかる
- 声の大きな人の発言に支配されがちになる
- ウォークスルー
- 設計上の誤りを早期に発見することを目的として、各設計の終了時点で作成者と複数の関係者が設計書をレビューする方法
- 成果物に含まれている問題点やエラーの検出に焦点を絞り、開発者手動で実施するレビュー手法
- 目的
- 問題点の発見を主目的とする
- 解決策の検討を目的とせず、問題点の見逃しを防ぐ
- 進め方
- プログラマの主催によって複数の関係者が集まり、成果物(プログラムリストなど)をレビューする
- 管理者は原則として出席しない
- 検討資料を事前に配布する
- 入力データの値を仮定してコードを追跡するように、手続きをステップごとにシミュレーションすることによってレビューを行う
- レビューミーティングは1〜2時間程度で終わらせる
- レビューした成果物の品質は、参加者の連帯責任にする
- 問題点
- エラー訂正が成果物作成者の責任で行うため、エラー修正を忘れた場合、エラーが残ってしまう
- インスペクション
- 目的や進め方はウォークスルーと同じであるが、モデレータを選出し、結果データの収集とフィードバックを追加したレビュー手法
- 作業成果物の作成者以外の参加者がモデレータとして主導すること、及び公式な記録、分析を行うことが特徴のレビュー技法
- あらかじめ参加者の役割を決め、いくつかの選ばれた局面に注意を払い、迅速にレビュー対象を評価する
- モデレータ
- インスペクションの実施責任者であり、進行役
- 成果物を作成した開発者ではない第三者が担当する
- エラー訂正の完了を成果物作成者に確認し、未了の場合は訂正を督促する
- ラウンドロビン
- レビューに参加したメンバが持ち回りでレビューの責任者を務めながら、全体のレビューを遂行していく
- 参加者全員がそれぞれの分担について、レビュー責任者を務めながらレビューを行うので、参加者全員の参加意欲が高まる
- パスアラウンド ( pass around )
レビュー対象となる成果物を電子メールなどで複数のレビューアに配布・回覧し、フィードバックを求める方法
- トレーサ
動的デバッグツールの一つ
プログラムの実行過程を時系列的にモニタリングするために、メモリやレジスタの内容を書き出す
プログラムの実行時に、呼び出されたプログラム名やある時点での変数の内容を表示するようなオブジェクトコードを生成する - アサーションチェッカ
変数の間で論理的に成立すべき条件を、プログラムの適切な箇所に挿入し、実行時にその条件を満たしているかどうかを検査するツール
変数の間で理論的に成立すべき条件が満たされているか否かを検査するコードをプログラムの適切な箇所に挿入し、実行時に検査結果が確認できる支援ツール - インスペクタ
デバッグ時にデータ構造の内容を確認するためのツール
プログラム実行時にデータの内容を表示する - デバッガ
プログラムの実行中、必要に応じて変数やレジスタなどの内容を表示し、必要であればその内容を修正して、テストを継続する - スナップショット
指定した命令が実行されるたびに、レジスタや主記憶の一部の内容を出力することによって、正しく処理が行われていることを確認する
- プログラムがシステム設計通りに動作すること、業務要件を満たしていることを確認するために、テスト計画を作成し、テストを実施する
- 問題が発見された場合は、そのレベルに応じて上流の工程に戻りプログラムや内部設計、外部設計を修正する
システム開発におけるテストでは、小さな単位から大きな単位へテストを積み上げていく方法が採られることが多い
- 単体テスト
- 結合テスト
- システムテスト ( 総合テスト )
- 運用テスト
- テストケース作成
- 既に稼働中のシステムに機能を追加するために、プログラムの一部を変更した場合に、本番稼動してよいかどうかを判断するために、稼働中のシステムに影響を与えることなくテストを行う環境
本番環境と同等のテスト環境 - システム適格性確認テストを実施するとき、用意しておくべきテストデータ
実際に業務で使うデータや、業務上例外として処理されるデータ - 実験計画法を利用したテストデータ作成方法
効率良くテストするために、直行表を用いてテストデータを作成する - プログラムの動的テストに用いられるテスト支援ツール
カバレージモニタ - 記号実行ツール
静的テストを行うツール
数値の代わりに記号を入力して実行をシミュレーションする - 構文チェッカ
プログラムのソースコードの静的解析を行う - コードオーディタ
プログラムのソースコードが、コーディング規約にのっとっているかどうかをチェックする静的解析を行う - .テスト項目目標数
レビューやテストすべき項目の目標数
テスト完了後のプログラムを修正した場合、修正部分を確認するテストデータを確認済みのテストデータに追加して再テストを行うほうがよい
- ソフトウェアのテスト工程において、バグ管理図を用いて、テストの進捗状況とソフトウェアの品質を判断したいときの考え方
テスト工程の消化の累積件数、バグ摘出の累積件数及び未解決バグの件数の推移がすべて横ばいになった場合は、解決困難なバグに直面しているかどうかを確認する必要がある - テストの進捗管理に使用する指標
テスト項目の消化件数 - 品質の判断
- テスト消化率のグラフ
横軸：テスト項目消化件数
縦軸：累積バグ件数
テスト項目件数が増えるにつれて累積バグ件数は収束する - バグ管理図
バグ管理図において、すべての線が横ばい状態になった状況から、解決困難なバグに直面しており、その後のテストが進んでいないことが推測できる
バグの発生状況を記載し、管理限界内に入っているかどうかを見るための図
QC七つ道具の一つである管理図の記載方法に準拠して作成する - テストカバレッジ
あるテストデータがプログラムのどの経路を通ったのかを調べ、プログラム全体の経路のうち、何%をカバーしたかを求めること - テストカバー率
システム開発プロジェクトにおいて、成果物の品質を評価するために使用する指標 - バグ原因分析表
発見されたバグが作りこまれた原因(仕様ミス、設計不良、プログラム誤り、テスト不足など)を分析し、表にまとめたもの
- テスト消化率のグラフ
- 外部設計および内部設計の誤りは、プログラムだけでなく、マニュアルなどにも影響を与えるので、コーディングの誤りに比べて修復コストは高い
- プログラムのテストでは、正常なケースで正しく動作するかどうかだけではなく、意図しなかった動きがあるかどうか、あるいは誤った入力があった場合にも意図した動作（エラー処理など）をするかどうかを調べる必要がある
- テストにおけるユーザ部門の役割
システム開発における成果物に対して、業務的観点から内容確認を行う
プログラムの詳細設計は開発部門に任せる
システムテストの段階で参加する
用意された運用マニュアルが適切であることを確認する（運用テスト時） - プログラムの変更管理の実施
変更実施結果の評価基準として、変更作業工数の予測値、障害発生率の目標値を決める
障害発生率：ここでは変更したことによる新たな障害の発生率を示す - テストの事例
- 本社に設置したサーバのデータを、本社及び各事業所内のLANと、本社各事業所とを接続する通信回線とから構成されている自社ネットワークを介して、全国の事業所に提供するアプリケーションを開発する場合、システムテストを本社内のLAN環境で行うとき、応答時間の検証は困難