Vモデル(ソフトウェア開発)

ウィキペディアから、無料の百科事典
ナビゲーションにジャンプ 検索にジャンプ
システムエンジニアリングプロセスのVモデル。[1]

ソフトウェア開発ではVモデル[2]は、ウォーターフォールモデルの拡張と見なすことができる開発プロセスを表しており、より一般的なVモデルの例です。直線的に下に移動する代わりに、プロセスステップはコーディングフェーズの後に上に曲げられ、典型的なV字型を形成します。Vモデルは、開発ライフサイクルの各フェーズとそれに関連するテストフェーズの関係を示しています横軸と縦軸は、それぞれ時間またはプロジェクトの完全性(左から右)と抽象化のレベル(最上部の最も粗い抽象化)を表します。

プロジェクト定義フェーズ

要件分析

検証プロセスの最初のステップである要件分析フェーズでは、ユーザーのニーズを分析することにより、システムの要件が収集されますこのフェーズは、理想的なシステムが実行する必要があることを確立することに関係しています。ただし、ソフトウェアがどのように設計または構築されるかは決定されません。通常、ユーザーはインタビューを受け、ユーザー要件ドキュメントと呼ばれるドキュメントが生成されます。

ユーザー要件ドキュメントには、通常、ユーザーが期待するシステムの機能、インターフェイス、パフォーマンス、データ、セキュリティなどの要件が記載されています。これは、ビジネスアナリストが、システムについての理解をユーザーに伝えるために使用されます。このドキュメントはシステム設計フェーズのシステム設計者のガイドラインとなるため、ユーザーはこのドキュメントを注意深く確認してください。ユーザー受け入れテストは、このフェーズで設計されています。機能要件も参照してください

ソフトとハードの両方の方法論の要件を収集するには、次のようなさまざまな方法があります。インタビュー、アンケート、ドキュメント分析、観察、使い捨てプロトタイプ、ユースケース、ユーザーとの静的および動的ビュー。

システム設計

システム設計は、システムエンジニアがユーザー要件文書を調査することにより、提案されたシステムのビジネスを分析および理解するフェーズです。彼らは、ユーザーの要件を実装できる可能性と手法を理解します。要件のいずれかが実行可能でない場合は、ユーザーに問題が通知されます。解決策が見つかり、それに応じてユーザー要件ドキュメントが編集されます。

開発フェーズの青写真となるソフトウェア仕様書を作成します。このドキュメントには、一般的なシステム構成、メニュー構造、データ構造などが含まれています。また、理解を助けるために、ビジネスシナリオの例、サンプルウィンドウ、およびレポートが含まれている場合があります。エンティティ図、データディクショナリなどの他の技術文書もこのフェーズで作成されます。システムテスト用のドキュメントが用意されています。

建築設計

コンピュータアーキテクチャソフトウェアアーキテクチャの設計の段階は、高レベルの設計とも呼ばれます。アーキテクチャを選択する際のベースラインは、モジュールのリスト、各モジュールの簡単な機能、それらのインターフェイスの関係、依存関係データベース テーブル、アーキテクチャ図、テクノロジの詳細などで構成されるすべてを実現する必要があることです。統合テストの設計が実行されます。特定のフェーズで。[3]

モジュール設計

モジュール設計フェーズは、低レベル設計とも呼ばれます。設計されたシステムは、より小さなユニットまたはモジュールに分割され、プログラマーが直接コーディングを開始できるように、それぞれが説明されています。低レベルの設計ドキュメントまたはプログラム仕様には、モジュールの詳細な機能ロジックが擬似コードで含まれます。

  • タイプとサイズを含むすべての要素を含むデータベーステーブル
  • 完全なAPIリファレンスを含むすべてのインターフェースの詳細
  • すべての依存関係の問題
  • エラーメッセージリスト
  • モジュールの完全な入力と出力。

単体テストの設計は、この段階で開発されます。

検証フェーズ

Vモデルでは、検証フェーズの各ステージには、検証フェーズの対応するステージがあります。[4]以下は、Vモデルでの検証の典型的なフェーズですが、他の名前で知られている場合もあります。

ユニットテスト

Vモデルでは、モジュール設計段階で単体テスト計画(UTP)が作成されます。これらのUTPは、コードレベルまたはユニットレベルでバグを排除するために実行されます。ユニットは、プログラムモジュールなど、独立して存在できる最小のエンティティです。ユニットテストは、最小のエンティティが残りのコード/ユニットから分離されたときに正しく機能できることを確認します。

統合テスト

統合テスト計画は、アーキテクチャ設計フェーズで作成されます。これらのテストは、独立して作成およびテストされたユニットが共存し、それらの間で通信できることを確認します。テスト結果はお客様のチームと共有されます。

システムテスト

システムテスト計画は、システム設計フェーズで作成されます。ユニットおよび統合テストプランとは異なり、システムテストプランはクライアントのビジネスチームによって構成されます。システムテストは、開発されたアプリケーションからの期待が満たされていることを確認します。アプリケーション全体は、その機能、相互依存性、および通信についてテストされます。システムテストは、機能要件と非機能要件が満たされていることを確認します。負荷およびパフォーマンステスト、ストレステスト、回帰テストなどは、システムテストのサブセットです。

ユーザー受け入れテスト

ユーザー受け入れテスト(UAT)計画は、要件分析フェーズで作成されます。テストプランは、ビジネスユーザーによって構成されます。UATは、現実的なデータを使用して、実稼働環境に似たユーザー環境で実行されます。UATは、提供されたシステムがユーザーの要件を満たし、システムがリアルタイムで使用できる状態にあることを確認します。

批評

Vモデルは、多くの理由から、ソフトウェア開発の不適切なモデルとしてアジャイル支持者などから批判されてきました。[5] [6] [7]批判には以下が含まれます。

  1. ソフトウェア開発プロセスを正確に反映するには単純すぎて、マネージャーを誤った安心感に導く可能性があります。V-Modelは、ソフトウェア開発のプロジェクト管理ビューを反映しており、ソフトウェア開発者やユーザーではなく、プロジェクトマネージャー、会計士、弁護士のニーズに適合します。
  2. 初心者には簡単に理解できますが、早期の理解は、初心者が開発プロセスと、実際にVモデルをどのように適応および拡張する必要があるかについての理解を深める場合にのみ役立ちます。開業医がVモデルの素朴な見方に固執する場合、それをうまく適用することは非常に困難になります。
  3. それは柔軟性がなく、ソフトウェア開発の厳格で直線的な見方を促進し、変化に対応する固有の能力を持っていません。
  4. ウォーターフォールモデルのわずかなバリエーションしか提供しないため、そのモデルと同じ批判の対象となります。これは、テスト、特に初期のテスト計画の重要性をより重視します。ただし、Vモデルに対する一般的な実際的な批判は、初期の段階がオーバーランしたが実装日が固定されたままである場合、開発の最後にテストがタイトなウィンドウに押し込まれることにつながるというものです。
  5. これは、テストに対する非効率的で非効率的なアプローチと一致しており、したがって暗黙的に推奨されます。探索的テストではなく、事前にテストスクリプトを作成することを暗黙的に促進します。それは、テスターが本当にそこにあるものを発見するのではなく、彼らが見つけることを期待しているものを探すことを奨励します。また、テストを計画および実行するための最も効果的かつ効率的な方法を選択するようにテスターを奨励するのではなく、いずれかのレッグの同等のレベル間の厳密なリンクを奨励します(たとえば、ユーザー要件ドキュメントから導出されるユーザー受け入れテスト計画)。
  6. それは一貫性と精度に欠けています。Vモデルが正確に何であるかについては広範囲にわたる混乱があります。ほとんどの人が同意する要素に要約すると、ソフトウェア開発の陳腐で役に立たない表現になります。Vモデルのメリットに関する意見の不一致は、多くの場合、その定義についての共通の理解の欠如を反映しています。

現在の状態

Vモデルの支持者は、Vモデルは時間の経過とともに進化し、開発プロセス全体を通じて柔軟性と敏捷性をサポートしていると主張しています。[8]彼らは、高度に統制されたアプローチであることに加えて、安定したソフトウェア製品を構築するために必要な綿密な設計、開発、および文書化を促進すると主張しています。最近、医療機器業界で採用されています。[9] [10]

も参照してください

参考文献

  1. ^ 操作のClarusの概念。 2009年7月5日、 Wayback Machine Publication No. FHWA-JPO-05-072、連邦高速道路局(FHWA)、2005年に
  2. ^ KevinForsbergおよびHaroldMooz、「システムエンジニアリングとプロジェクトサイクルの関係」、1991年10月のシステムエンジニアリングに関する全国評議会の第1回年次シンポジウムの議事録:57–65。
  3. ^ Vモデルとは-長所、短所、およびいつ使用するか
  4. ^ DeSpautz、Joseph; ケネスS.コバックス; Gerhard Werling(2008年3月11日)。「自動システムの検証のためのGAMP標準」製剤加工。2012年5月8日にオリジナルからアーカイブされました2012年2月28日取得
  5. ^ 「Vモデルの死」、2013年1月6日にアクセス
  6. ^ 「危険で魅惑的なVモデル」、2013年1月6日にアクセス
  7. ^ 「テスト開発のための新しいモデル」、2013年1月6日にアクセス
  8. ^ 「アジャイルシステムエンジニアリングプロセスに向けて」、2013年1月6日にアクセス
  9. ^ 「医療機器ソフトウェアを開発する際にアジャイルプラクティスを採用することへの障壁」
  10. ^ 「医療機器産業のためのソフトウェアプロセス開発、評価および改善フレームワーク」

さらに読む

  • Roger S. Pressman:Software Engineering:A Practitioner's Approach、The McGraw-Hill Companies、ISBN 0-07-301933-X 
  • Mark Hoffman&Ted Beaumont:アプリケーション開発:プロジェクトライフサイクルの管理、Mc Press、ISBN 1-883884-45-4 
  • Boris Beizer:ソフトウェアテスト技術。第2版​​、International Thomson Computer Press、1990、ISBN 1-85032-880-3 

外部リンク