TRACERYプロダクトマネージャーの haru です。
この記事ではV字モデルの構造について説明します。V字モデルの構造を把握することで、各プロセスで力を入れるべきポイントが分かり、効果的にシステム開発を進めることができます。
V字モデルの全体像と開発を組み立てる方法については以下の記事を参照してください。
システム開発プロセスの分類とその関係
システム開発のプロセスは、大きく5つのプロセスに分けられます。
- 企画 『なぜそのシステムを作るのか』という目的(Why)
- 要件定義 『何を作るのか』(What)
- 設計 『どのように作るのか』(How)
- 実装『実際に作る』(Make)
- テスト『品質を保証する』(Test)
企画、要件定義、設計、実装は、上図のように左から右へ目的と手段の関係になっています。たとえば、企画から見ると要件定義は企画を実現する手段であり、要件定義から見ると企画は要件定義の目的です。
テストは、企画、要件定義、設計、実装それぞれのプロセスの成果の品質を保証します。
V字モデルへのマッピング
これらのプロセスの関係をV字モデルにマッピングすると下図のようになります。「Test(品質を保証する)」はV字モデルの右辺すべてにわたります。
各レイヤーの説明
上図で示したV字モデルの各レイヤーについて順に説明します。
「Why」のレイヤー
システム*1を開発する目的(Why)が関心事のレイヤーです*2。そしてその目的が実現されているかを、V字モデルの右辺で検証します。
各プロセスの概要は以下のとおりです。V字モデルの右辺の「運用・評価」は「運用」プロセスと「評価」プロセスに分かれます。
- 「企画」プロセス
- 解決すべき問題や取り組むべき課題、創出する価値を定義します。そして、目的を実現するためのコンセプトや方向性、道筋や計画を構想します。
- 「運用」プロセス
- 開発したシステムを実際に運用し、事業を運営します*3。
- 「評価」プロセス
- 企画プロセスで定義した問題が解決され、価値が創出されているかを検証し評価します。
「What」のレイヤー
業務やシステムで実現すること(What)が関心事のレイヤーです。
この「業務やシステムで実現すること(What)」を定義することを、ここでは「要件定義」と呼びます。
要件定義は、「業務要件定義」と「システム要件定義」に分かれます。
そしてV字モデルの右辺では、大きく以下の2つの内容を検証します。
- 業務要件定義で定義した要件が実現されているか、実運用できるかどうか
- システム要件定義で定義した要件が実現されているか、システムとして動作するかどうか
各プロセスの概要は以下のとおりです。
- 「業務要件定義」プロセス
- 具体的な業務の構成や業務の流れ、業務の中でのシステムの利用場面(ユースケース)など、業務に求める要件を定義します。
- 「システム要件定義」プロセス
- 業務要件定義で定義したシステムの利用場面(ユースケース)を詳細化し、機能要件や開発項目を抽出します。また、システム全体に求める性能やセキュリティなどの非機能要件やシステムのアーキテクチャを定義します。
- 「運用テスト(受入テスト)」プロセス
- 業務が実運用できるかどうか、業務要件定義で定義した要件が実現されているかを検証します。開発チームに開発を依頼した担当者が、依頼内容が実現されているかを確認する目的の場合、受入テストともいいます。
- 「システムテスト」プロセス
- システム内に配置される各ソフトウェアや外部システムが連携して動作し、システム要件(機能要件や性能、セキュリティなどの非機能要件*4)を満たしているかを検証します。
「How」のレイヤー
業務要件やシステム要件を満たすために、ソフトウェアをどのような仕様で実現し、ソフトウェアの内部をどのようにを作るか(How)*5が関心事のレイヤーです。
V字モデルの右辺では主にソフトウェアが仕様どおりに正しく動作するかどうかという観点で検証します。それに加えて、要件定義で定義した要件を満たすことができるかという観点でも検証します。
各プロセスの概要は以下のとおりです。
- 「基本設計」プロセス
- 大きく「仕様化」と「全体設計」に分かれます
- 仕様化: システム要件定義フェーズでリストアップされた開発項目(画面、API、機能など)の仕様を定義します*6。
- 全体設計: ソフトウェアアーキテクチャー設計、データ全体設計(リレーショナルデータベースを使用する場合、ER図等)などを設計します。
- 大きく「仕様化」と「全体設計」に分かれます
- 「結合テスト」プロセス
- 個々のモジュールやコンポーネント*7を結合し、ソフトウェア全体としての動作を検証します。画面や機能間のデータの連携などをテストします。
- 「詳細設計」プロセス
- 開発の最小単位であるコンポーネントやモジュールを設計します。詳細設計を完了するとプログラミングが可能になります。
- 「単体テスト」プロセス
- コンポーネントやモジュール単位の動作を検証します。
「Make」のレイヤー
設計に基づき、ソフトウェアを実装すること(Make)が関心事のレイヤーです。
そしてV字モデルの右辺ではプログラミングしたコードが可読性や保守性に優れ、品質が高いかどうかを検証します。
以下は各プロセスの概要です。
- 「プログラミング」プロセス
- 設計に基づいて具体的なコードを書き、システムの機能を実現します。
- 「コードレビュー」プロセス
- プログラムコードを査読し、コードが可読性や保守性に優れているか、バグやセキュリティの脆弱性がないか、効率的に動作するかなどの品質を検証します。
最後に
本記事では、V字モデルの構造について説明しました。
V字モデルの各レイヤーの関心事を把握することで、各プロセスの重要なポイントを理解し、力を集中させることができます。また、各プロセス間の関係を理解することで、他のプロセスの成果物を確認する能力が養われます。
他のプロセスの成果物を確認するために必要となるプロセス間の関係についての知識や各レイヤーの詳細な内容は、別の記事で説明します。
V字モデルの構造を理解することで、効果的にシステム開発を進められるようになるでしょう。
各レイヤーの詳細説明記事
*1:ここでのシステムは狭義のシステムを内包する「広義のシステム」を対象とする。詳細はシステム開発におけるシステムとは何かを参照のこと
*2:企画プロセスでは、システムを開発する目的だけではなく、目的を実現するための構想や計画も立案する。システムを開発する目的が、企画プロセスの最大の関心事であり、起点となるため、ここではシステムを開発する目的のみをあげている
*3:共通フレーム2013では、「運用」プロセスは運用テストと同じレイヤーに位置づけられている。これは、運用が業務担当者の責任と考えられているためと想定される。本メディアのV字モデルでは、事業運用の責任を経営者の責任、すなわち事業レベルと捉え、企画と同じレイヤーに「運用」プロセスを置いている
*4:機能要件(Functional Requirements)は、ユーザー視点から見て、ソフトウェアシステムやアプリケーションがどのように動作すべきかを具体的に定義する要件のこと。非機能要件(Non-functional Requirements)は、ソフトウェアシステムの性能、セキュリティ、使用性や信頼性、効率性など機能以外に関する要件である。
*5:「ソフトウェアをどのような仕様で実現するか」=「外部設計」、「ソフトウェアの内部をどのようにを作るか」=「内部設計」と表現することもある。
*6:共通フレーム2013では「ソフトウェア要件定義」に該当するが、本メディアでは「基本設計」に分類する
*7:コンポーネントは、ソフトウェアシステムの機能的な単位で設計される。特定の機能やサービスを提供する部分であり、他のコンポーネントやシステムとインターフェースを通じて通信する。モジュールは、プログラムを構成するコードの単位で設計される。特定の機能やロジックのまとまりを表し、コードの整理と管理を容易にする。