Vモデル手法って

よくウォーターフォール型の開発手法としてVモデルという言葉を聞くのですが、どういったものなのでしょうか? またASAPでいうSAP導入方法論とはどう違うのでしょうか?すいませんがご教示ください。

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の考え方は
要件定義、基本設計、詳細設計を記述するときはテストする項目、テストシナリオとしても再利用できるつくり方にすればまたテストシナリオ作る必要ないし、基本設計書や要件定義書が過去のものとして放置されずテスト期間中にアップデートするため納品物の品質保持でき、運用面にも利用できるとのこと。一理ありですね。

emyさんお礼遅くなってすいません。
テストにおける基本的な考え方、理解できました。
統合テストは本来基本設計書を基にした検証。とはいいますが実際は単体テストの延長線、基本設計には明確になっていなかった考慮不足の対応がほとんどです。今後はこれを防ぐに最適な方法考えていきたいと思います。また何か助言のほどよろしくお願いします。ありがとうございました。