Re: Vモデル手法って

Vモデル手法という言葉自体は一般的なものですから
まずは、このページを読んでください

http://ja.wikipedia.org/wiki/V%E3%83%A2%E3%83%87%E3%83%AB

プロジェクトの中では開発者、SE、コンサルタントと大勢役割分担して作業しているため、みながみなそれぞれのやり方で開発、テストしていたら品質面にムラがでてくるどころか、要件違い、バグの山積み大発生となること間違いなし。ここはやはりPJ全体のテストの方法、考え方として定める必要があり、単体テストは詳細設計書に準拠に検証をすすめなさいよ、統合テストまたはシステムテストでは基本設計書ベースにユーザーの目線で求めたいものが正しいか検証していきなさいよ。といったテストの進め方をこのモデルを応用して定めることとなります。
では実際、プロジェクトを進めていくにあたり、当初に書いた基本設計書、業務プロセスフローをもとに統合テストできるかというと、結構要件変更箇所でていて、テストシナリオ書くときにいっしょに業務フロー書き直すなんてよくありませんか? 厳密にこの手法でやっていこうとするとビジネス設計フェーズにえらく時間がかかるでしょうし、エンドユーザーの理解度が追いつかない、現実的にはムリですので「基本的にはVモデルの考え方を基本としてスパイラルに業務プロセス、要求仕様の穴を埋める。詳細化していく」ということがERP導入では主流のような気がします。
SAPの導入方法論ASAP(今はソリューションマネージャ)もこのVモデルを応用した考え方しています。
ERPの導入における要件定義、基本設計ではプロトタイピングでスパイラルに進めていく。のが基本とされていますがこれは要件仕様FIXの仕方でより完成系をイメージできて極力齟齬を防止する方法というだけであってドキュメンテーションはウォータフォール型を崩していません。
またASAPの考え方は
要件定義、基本設計、詳細設計を記述するときはテストする項目、テストシナリオとしても再利用できるつくり方にすればまたテストシナリオ作る必要ないし、基本設計書や要件定義書が過去のものとして放置されずテスト期間中にアップデートするため納品物の品質保持でき、運用面にも利用できるとのこと。一理ありですね。