V-model of Engineering Development, Part 2-B - A practitioner's opinion

Yet Yet Another Diagrammatic View - "Invisible Dimensions"

Having elaborated a slightly more nuanced "multi-dimensional" depiction of the model with a "3D" diagram above, it seems pragmatic to explore the model in more detail using different "views". The following figure shows a "kind of orthographic drawing" where the classical V-diagram is given as the so-called "front view" and the other dimensions are "projected" as "top" and "side" views. This is obviously completely imaginary but hopefully the father of orthographic drawings wouldn't be too angry.

The "Front" view shows the classical V-model diagram which communicates that the system progresses (from left to right) from an abstract state (existing only as a concept) to a realized & commissioned state (existing as a full physical "thing"), and that this process first progresses "top-down" (during the design phase) and then "bottom-up" (during the integration phase).

The "Top" view shows that there are several parallel processes running throughout the development (time progresses from left-to-right in both the "Front" and "Top" views). The amount of effort within each of these processes is indicated by the "height of the shape" - a broader\higher shape means more effort. Although this effort changes over the course of the development, it is important to recognize that these processes are still running at every point in time.

 Some [side] notes before continuing:

• This parallelism and "beginning-to-end" nature of these processes is one of the key misunderstandings emanating from the simplistic "Front" view. One can easily interpret the classical V-diagram to simply be a "bent version of the Waterfall model", but it should be clear from these articles that that interpretation is not accurate. The fact that the processes shown in the "Top" view all run concurrently is a fundamental difference with the basic Waterfall-model.
• The concurrency of the processes (in the "Top" view) should not be confused with Concurrent Engineering (we'll get to that in later) and especially not with Project Fast-Tracking (this was explored in another article). Rather, it indicates to the project lead & team, that the ball should not be dropped on any of these aspects in any given time period. Stated differently, at every point in time the team should have the requirements & verification in mind while building out the solution itself.
• The "Top" view concurrency is sometimes implemented fairly literally in job roles where one individual takes care of the requirements while another looks after V&V. This is not the intent of the model. In fact, the two "sides" of the V are presented as a "V" to emphasize that they are effectively "two sides of the same coin" - the left more abstract and the right more concrete. Splitting roles based on "left and right" - especially in the architect or system engineer role - is thus like driving an automobile where one person handles the steering wheel while another handles the pedals & gear shifting... it can be done, but it really shouldn't. That is not to say that a handover isn't possible - just that it should be done only if you really need to do it and know what you are doing.
• A corollary of this is that not everyone would want to be a system engineer \ architect (although the skills could probably be acquired by most knowledge workers). People have different strengths and weaknesses, and to be a proficient development lead ("SE" or "architect") you must be adequately strong in all the relevant processes (although not necessarily in the detail disciplines). This implies a "generalist" rather than a "specialist" which does not suit all personalities well - at least in the opinion of this author.

The "Side" view shows another set of relative-effort concurrent processes, however not as a [direct] function of time but rather as a function of hierarchy. This is where the notion of Concurrent Engineering is touched on: all of the disciplines are involved over the full effort, but the level of effort (shown by the "width" of each shape) differs over the development hierarchy. At the higher system levels (early and late phases in time) the discipline specific resources have lower involvement while at the lower system levels (middle phases in time) the "architect" has lower involvement.

The processes in the diagram named "System Design", "Integration", and "System Verification" are considered generic and applicable in all development efforts - see article Part 1. These processes have different names (especially in different formal development methodologies) and are often broken down into more detail actions, but the purpose remains the same: "top-down" derivation of the proper solution description ("what is to be built & how"), and "bottom-up" building & testing until a proven solution is established.

The processes that are called "Tech. \ Eng. Domain" refer to all the relevant knowledge domains necessary to obtain stakeholder satisfaction in the end-product. Some examples of these domains include mechanical engineering, electronic engineering, and software engineering, but may also include specializations like material science, fluid-mechanics, mathematical modelling, etc. Moreover, aspects like reliability engineering, safety engineering, ergonomics, etc. should be incorporated if the necessary knowledge does not reside within the other specializations.

Some [side] notes before continuing:

• The "Side" view is not exhaustive (obviously). A set of processes which are excluded there are domains \ specializations which should inform the "system" processes. Examples of these domains include: psychology (e.g. reducing barriers to acceptance of a solution), and industrial (or artistic) design (e.g. informing requirements about intuitiveness of use).
• Another aspect that is not explicit in the "Side" view (or other views) is the effort required to manage stakeholders outside of the project. These types of processes are partially addressed in the "discipline" of project management to greater or lesser extents depending on which methodology (e.g. PMI, Prince2) is utilized. These pertain to "dealing with people" (politics?) and may be even more important to the project success than the actual technical deliverable.
• In many organizations and industries, development projects are managed by two persons: a "system engineer" and a "project manager". The responsibility distinction between these individuals is then made on the basis of "technical" (which is allocated to the "engineer") and "time & money" (which is allocated to the "project manager"). This author firmly believes that this is a reason why many projects fail because these "dimensions" are integrally linked (the "iron triangle of projects" concept). Again, the analogy of two individuals operating the controls for a single automobile applies. Rather, one person is responsible for "performance, time, and money", but this person can divide the workload into tasks (which should have substantial independence - more in a different article perhaps).

To summarize more succinctly: there are several "system" processes that run from beginning-to-end (but with varying levels of effort) which are generically applicable to all development efforts. Then there are specializations which pertain to the specific problem space (relevant at the higher levels of the V) and solution space (increasingly pronounced at the lower levels of the V). These parallel processes and disciplines are not visible on a simplistic diagram, but they are very real.