徹底攻略 JSTQB Foundation教科書&問題集 シラバス2018対応を勉強しているので、自分のメモとしてまとめています。第８弾。
プロジェクトやプロダクトの特性に応じたモデルの選択
シラバスでは、以下のファクターを考慮してモデルを選択し、必要に応じてアレンジすることを推奨している。
- プロジェクトのゴール
- 開発するプロダクトの種類
- ビジネス上の優先度（市場に参入するまでの時間など）
- プロダクトリスクやプロジェクトリスク
例に以下を挙げる。
- 小規模な内部向けの管理システム開発
- アジャイル開発モデルを使って自由に作る方が効率的でよいものができる可能性がある。
- 自動車のブレーキシステム
- セーフティクリティカルシステムなどは、きちんと設計してて、徹底的にテストするシーケンシャル開発モデルのほうが向いている。
- 文化に合わせたモデル選定
- 自由に情報共有する風土がない組織でアジャイル開発モデルを取り入れた場合、チームメンバーのコミュニケーションが悪くて開発が今くいかないことが懸念される
テストレベルの組み合わせ
プロジェクトの状況によっては、テストレベルやテスト活動を組み合わせたり、再編成したりする場合もある。
市販ソフトウェア（Commercial Off-The-Shelf:COTS:コッツ / 棚から出してすぐ使える商品の意味、日本ではパッケージソフトともいわれている）を購入して大規模システムに組み込む場合、統合テストと受け入れテストを一緒にテストすることになる。
（市販ソフトウェアの大規模な連携を統合テストで検証しながら、受け入れテストで運用性を確認する作業が一緒に行われる。）
ウォーターフォール開発モデルでは、通常4つのテストレベルをシーケンシャルに実施するが、４つのテストレベルが必ずしもシーケンシャルに独立して行われるとは限らない。
ソフトウェア開発ライフサイクルモデルの組み合わせ
プロジェクトによっては、複数のソフトウェア開発ライフサイクルモデルを組み合わせる場合もある。
⏬例
- フロントエンドシステムのUI開発とテスト
→ アジャイル開発モデル：徹底的に使い勝手の良いものを作るため - バックエンドシステムとテスト
→ V字モデル：ロジックにエラーが起きないように、きちんと設計・テストするため
プロジェクトの初期段階ではスパイラルにより試行を繰り返し、試行フェーズが完了した後はインクリメンタル開発モデルで機能拡張していくというように、アジャイル開発モデル同士を組み合わせる場合もある。
開発対象に応じたソフトウェア開発ライフサイクルモデルの適用
開発対象はソフトウェアだけとは限らない。
⏬例
- IoTシステム
- デバイス：シーケンシャル
- ソフトウェアプロダクト：アジャイル
- 開発対象ごとに個別のソフトウェア開発ライフサイクルモデルを適用するのが一般的
IoT（Internet of Things）とは、「モノのインターネット」と訳される。センサーや駆動装置、家電製品、車など、これまでインターネットに接続されていなかった様々なモノをネットに接続することで、飛躍的に便利に使うことができるようになる。
モデルを組み合わせる理由
プロジェクトやプロダクトの特性に適合させる理由は主に以下の３つ。
システムのプロダクトリスクが違う
業務上重要なシステムほど大規模で複雑なシステムになり、故障したときのリスクが高くなる。
部門内で使用するような小規模システムは、故障したときのリスクが限定されるためリスクが低くなる。
そのため、複雑なプロジェクトにはシーケンシャル開発モデルを採用し、単純なプロダクトにはアジャイル開発モデルを採用するという使い分けが行われる。
多くの部署がプロジェクトやプログラムに参加している
部署によって通常使っているソフトウェア開発ライフサイクルモデルが異なる場合が多くなる。
シーケンシャルに慣れている部署とアジャイルに慣れている部署が同じプロジェクトに参加したとき、無理にソフトウェア開発ライフサイクルモデルを統一させるよりも、それぞれが慣れたモデルを使ったほうが成功の確率が高い可能性がある。
プロダクトを市場に投入する時間が短い
ビジネス上の理由で、短期間でプロダクトを市場に投入しなければならないことがある。
複数テストレベルを同時に行ったり、複数のテストタイプを同時に行ったりすることで、市場投入までの期間を短縮する。
次回