品質は設計で作り、テストで保証する

設計の段階で品質はほぼ決まる

情報システムの開発における設計フェーズの役割は、何をどのように作るかを決めることです。
そして、想定外を想定内にするフェーズでもあります。

そのため、設計で盛り込まれなかった機能や、設計時に気づけなかった運用は、その後の工程でも気づかれない恐れがあります。
結果として、設計にない機能は、その後作られないままテスト工程まで進むことになります。

また、パフォーマンスなど一部の仕様は、実装前にほぼ決まってしまう場合もあります。

例えば、パフォーマンスについては、テーブル設計が重要になります。
テーブル設計が重要な理由は、テーブルからのデータ取得がシステムのパフォーマンスに影響を与える場合が多いからです。

そして、製造工程以降では、テーブルの構成を変えることはほぼ不可能です。
結果として、パフォーマンスは、実装前にほぼ決まってしまうこととなります。

これらのことから、品質は設計段階でほぼ決まることになります。

設計工程で行うこと

  • システムで対応すること、運用で対処することを決める
  • システムの要件をもとに、システムの画面や、機能の仕様を決める
  • パフォーマンスやセキュリティーなどの非機能要件の仕様検討を行う

テスト工程で行うこと

  • 設計通りにシステムが動いていることの確認
  • 想定外の入力に対し、想定外の動作をしないことの確認

テストで品質を上げるのは大変

システム開発では、テストで品質を上げようとするプロジェクトもありますが、テストで品質を上げるためには、設計書に盛り込まれていないことをテストする必要があります。
そして、設計書に盛り込まれていないことをテストするためには、システムが何のために作られていて、どのように使われるかを知る必要があります。
そのため、システムの運用を含め、多くの知識や経験が必要となります。

また、テスト工程内で盛り込まれていない機能を発見した場合、テスト工程の短い期間で、修正のための影響調査、機能を盛り込むための修正方法の検討、実装、テストのすべての作業を行う必要があります。

さらに、プログラムを修正した場合は、プログラムを修正したことにより、関連する機能が動かなくなってしまうリスクがあります。

そのため、同じ実装規模であっても、新規で機能を作る場合に比べ、テスト工程以降で機能追加を行う場合は、必要となるテストケースが増加することになります。

結果として、テストで品質を上げようとした場合、経験豊富なスーパーマンのような人がテストケースを考える必要が出てきます。

設計をやるために

システム設計のセオリー --ユーザー要求を正しく実装へつなぐ

システム設計のセオリー --ユーザー要求を正しく実装へつなぐ

はじめよう! システム設計 ~要件定義のその後に

はじめよう! システム設計 ~要件定義のその後に

システム設計の基礎から実践まで 1からはじめるITアーキテクチャー構築入門

システム設計の基礎から実践まで 1からはじめるITアーキテクチャー構築入門

グラス片手にデータベース設計~生産管理システム編 (DB Magazine Selection)

グラス片手にデータベース設計~生産管理システム編 (DB Magazine Selection)