| ドキュメント名 | 解説 | 様式番号 |
|---|---|---|
| バグシート | バグが発見されたときに記述される | 4-01 |
システムのテスト
| クラスレベルテスト | システム実装者 |
| アプリケーションレベルテスト | システム設計者 |
| システムレベルテスト | システム分析者（テスト管理者）とテスト要員 |
システムの評価
要求仕様の評価
システム開発では、要求仕様を基にソフトウェアを開発する。もし、要求仕様の品質が悪いとするならば、初めから作ろうとするソフトウェアがすべて誤っていることになる。本来、このような要求仕様の誤りについては問題領域分析フェーズにて解決しておくべきことである。しかしながらシステム開発の過程で、政治的な側面での仕様変更、期間・工数変更などによって、あるべき要求仕様をねじ曲げられて開発が進められることもあるだろう。このようなケースも考慮に入れながら、問題領域分析フェーズで作成した要求仕様を以下の観点で評価しなければならない。
- 本当にユーザ要求を組み入れた要求仕様と言えるものであったか？
もし、そうでないとすれば、ユーザ要求が組み入れにくかった原因はどこにあったのだろうか？
- 開発期間、開発工数を考慮した要求であったか？
結果として、要求に基づいて作成されたスケジュールは適切であったか？
- ユーザ満足度はどの程度か。
これは、ユーザに利用アンケートを取り、その集計結果によって判断しなければならないため評価フェーズの期間を越えて長期に調査を行うことが必要とされる。
- 開発環境の変化に応じた柔軟な要求の変更がなされたか？
システム開発が長期にわたる場合、ユーザ要求が変化することもありうる。そのような時、要求の変更に柔軟に応じながら、スケジュールの変更を正しく行えるようユーザとの調整を正しくおこなったか？
システム開発の中で作成される要求仕様書は、開発するソフトウェアにおいて「何を作るべきか」という指標として開発中・開発後に使われるものでなければならない。つまり、要求仕様書は、開発中や開発後の保守ドキュメントとしても生きたドキュメントとして活かされなければならない。もしも、開発が進むにつれ要求仕様書が死んだドキュメントとして戸棚の奥に飾れれていたのならば、開発されたソフトウェアはユーザの要求を満たすものかという保証はない。
このような要求仕様書に対する大前提を基にして下記の評価を行う。
- 開発システムは要求仕様を満たしているか？
要求仕様に書かれている以下の要求項目について、開発システムが要求を満たしているかどうか判断する。もし、要求を満たしていない場合は、なぜ切り落としたのか？本質的に必要のない要求だったのか？ということについて議論する。また、そのように切り落とされた要求が、今後、ユーザから不満となることがあるかを議論する。
- 機能面に対する要求
- 性能面に対する要求
- 信頼性に対する要求
- ユーザインタフェースに対する要求
- システム構造に対する要求
- 期間・工数に対する要求
- 拡張性に対する要求
- 要求に曖昧性がなかったか？
要求仕様に書かれた曖昧な定義により、システム開発時に開発依頼側と問題を引き起こした部分について、なぜ開発依頼側と意志疎通ができなかったのか。また、もっと詳細に書くべきことであったのかを論する。
- 要求仕様決定の遅れが開発の遅れにつながらなかったか？
要求仕様を性格に作ろうという思いが、結果的にシステム共通フェーズの遅れにつながり、結果として開発が遅れてしまった場合、その遅れは妥当であったか判断するために議論する。もしかすると、問題となった要求項目自体を曖昧にしていてもシステム共通フェーズやアプリケーション設計・実装フェーズと並行に進めていけるものであったのかもしれない。
- 要求モデルは妥当なものであったか？
- 要求を理解する上で有効なモデルであったか？
- どの程度、次フェーズの設計指針に役だったか？
- 複雑なばかりで、設計フェーズに役立っていなかったのではないか？
- 単純すぎて、設計フェーズに役立つ情報が欠落してはいなかったか？何か追加しておくべきものがあったか？
- モデルに存在するオブジェクトは、ユーザ要求に本質的に必要なオブジェクトであったか？
- アーキテクチャモデルが要求モデルをベースに作成されたものであったか？
- 用語辞書は利用されたか？
問題領域の理解に手間がかかる場合、用語辞書が作成される。用語辞書は、要求仕様の中に出てくる重要な用語の意味が定義されるはずである。ここでは、作成された用語辞書が以降のフェーズでどの程度利用され、有効に活用されたかを判断する。また、用語辞書を作成しなかったプロジェクトでは、本当に作成しなくてよかったのかを議論する。
開発したソフトウェアを以下の項目により評価する。
- システム共通設計フェーズにおける共通化項目の妥当性
システム共通設計フェーズで決めた共通ルールがプロジェクトに適切に効果をもたらしたか？または、有害な共通化ではなかったか？
- アーキテクチャモデルの妥当性
システム共通設計で定めたアーキテクチャモデルがシステム設計として充分機能する構造であっただろうか。何か他に優れたアーキテクチャがなかっただろうか？
- コンポーネント化に対する評価
コンポーネント化することで再利用コードを増やしテストが楽になったであろう部分を、コンポーネント化していなかったソースの箇所はなかったか？もしあれば、今のうちに改善しておいた方が保守が楽になるのではないかといった議論。
- ソースの品質
とりあえず動いてしまったと感ずる部分はないか？もしあれば潜在バグを疑うべきでありシステム設計者の責任においてコードインスペクションを行う。
- テストフェーズの評価
時間をかけたテストがなされたか。バグを修正したことで新たにバグを作ってしまうようなディグレードをテストによって発見できたか。また、ディグレードが頻発してしまった場合は、どこに問題があったのか議論する。
システム開発の開発プロセスについて、以下の項目により評価する。
- スケジュール
計画されたスケジュールと実際に実施されたスケジュールの食い違いはなかったか？もしあったとすれば、その原因はどこにあるか？
- ODGとの連携による開発
コンポーネント開発すべき内容を発見した際に要求を早期にODGに伝えたか？また、それに応じて作られたコンポーネントを使う努力がなされていたか？
- ワークショップの有効利用
システム管理者は、決めるべき事を早期に決断するためにワークショップを有効に利用したか？
- 教育面
ADG開発チームに必要とされる教育が事前になされたか？また、その教育は有効であったか？
- 開発スケジュールの変更と調整
開発内容の変更に伴う開発スケジュールの調整が円滑になされただろうか？もし、なされなかった場合は、その原因を追求する。
作成されたドキュメントに対して、下記の評価を行う。
評価項目 評価の方法 ドキュメントの必要性 プロジェクトとして本当に必要なドキュメントだったのか？ 使われなかったドキュメント なぜ使われなかったか？どうすれば使えたか、または、不必要なものか？ 書くべきドキュメント なぜ書かなかったのか？その影響はどうだったか？ 分厚いドキュメント なぜ分厚くなったか？意味のある情報か？改善策は？ 適切な情報 ドキュメント利用者にとって適切な内容か？たとえば、保守と利用を混同して書いていないか？ 古くなった情報 新しくする必要があるか？するとすれば何時やるか？
手順通りテストを行ったか？システムの評価が客観的かつ、有意義な形でなされたか？