長所

• Windowsを中心としたチームの開発。主に Windows に焦点を当てる場合の開発モデル選択肢となります。
• 既存の Windows 変更管理システムやバージョン・コントロール・システムの使用が可能です。
• VCS マスター・システムに接続することなく開発が可能です。
• LANSA 開発チームでは LANSA 開発にこのモデルを利用しています。
• 開発者はリポジトリを更新する時期や更新箇所、どのオブジェクトにするかまで選択することが可能で、受信する LANSA オブジェクトの更新を開発者が完全にコントロールできます。開発者の意思表示や合意がない限り、開発環境は変更されません。つまり、開発者は他の開発者からサンドボックスにより守られます。
• セキュリティとタスク追跡は無効になり、代わりに LANSA オブジェクトへのコントロール・アクセスの VCS メソッドが使用されます。例えば、VCS がオブジェクトのチェックアウトを要求し、その際にこのオブジェクトに限定の権限を求めることが可能です。
• システム・データは Visual LANSA により管理され、VCS マスターにチェックインされた別の開発者が加えた変更とともに、VCS マスターから受け取ることも可能です。
• VCS マスターより提供される機能を使って、開発環境の性能を拡張できます。例えば、分岐、マージ、ソース比較、パッチ、ラベル付け、バグ追跡統合など様々な機能が可能です。

短所

• バージョン・コントロール・システムを保守・管理する必要があり、十分な理解が必須となります。
• IBM i スレーブのインストール時とシステム・データの更新時は、VCSマスター・システムが使用出来る状態でなければいけない。(システム初期化と区画初期化)
• オブジェクトの修正 (チェックアウト) および他の開発者がこの変更を使用できるようにする (チェックイン) 許可を得る際は、マスター・システムが使用できる状態でなければいけません。
• 各開発者の PC には、他のモデル以上のディスク容量が必要となります。
• 各開発者が各自 Visual LANSA ソフトウェアをインストールし、更新しなければいけません。