A few years ago I sat through a presentation on the deficiencies of the Dual Vee systems engineering model.  The presenter started by saying that the Vee model is nothing more than a variation on the waterfall, and then went on to conclude that the Vee could not support iterative or Agile development. 

Having been personally taught the Vee model by Hal Mooz and Kevin Forsberg, I knew those statements to be incorrect.  However a cursory reading of the text Visualizing Project Management could lead you to those conclusions.  For example, Figure 7.11 on page 111 clearly shows an arrow pointing from left to right with the caption “time and baseline maturation”.  These words imply a similarity to the waterfall, which also works from left to right.  However, the actual process is to work both sides of the Vee in tandem from top to bottom and then from bottom to top.  As you work down the left side of the Vee with a series elaboration and of decompositions, you have to also work down the right side of the Vee with a series of verification planning activities. Unlike the waterfall, that doesn’t start testing until code and debug has started, the Vee uses verification planning as a means to ensure you have requirements that can, in fact, be verified.

Conversely, as the developer builds and integrates the system, the process conveyed in the Vee model is for the developer to confirm the requirements have not changed.  Therefore, the process starts at the bottom and works up both sides of the Vee, executing the plans developed during the decomposition process, and confirming the requirements and functionality defined during the decomposition process haven’t changed over time or due to results.

As for evolutionary and incremental development, both are documented in the Figures 19.16 through 19.18 on pages 357 and 358 of Visualizing Project Management.  These figures demonstrate a simple view of incremental and evolutionary, where each increment is a separate PDR.  The reality is that each increment does not have to be at PDR.  The increments can be at any level of decomposition and they do not need to be at the same level across the entire project.  For example, a hardware component may have just one Vee, whereas a sub system of the software deliverable could be developed using an Agile methodology and have multiple Vees.  There are no limits to the number of, or types of, permutations.

It is true that a system is “realized” over time however, the Dual Vee is not a variation on the Waterfall or the Spiral.  It is a model that embraces the complexity of systems development by working both sides of the Vee