Managing the SoS Value Cycle

by Philip Boxer

The traditional ‘V’ of the software verification cycle is described in PSS-05-10 by the European Space Agency as follows:

“Software development starts in the top left-hand corner, progresses down the left-hand ‘specification’ side to the bottom of the ‘V’ and then onwards up the right-hand ‘production’ side. The V-formation emphasises the need to verify each output specification against its input specification, and the need to verify the software at each stage of production against its corresponding specification.” (March 1995)

Work within INCOSE by Jack Ring and others on ‘Intelligent Systems Engineering’ makes this ‘V’ the lower part of a System Value Cycle that seeks to align its focus on System with an upper inverted ‘V’ focused on Value with the problem to be addressed at its apex, and the relationship between the two ‘V’s focusing on Purpose. In our terms, the bottom ‘V’ is about designing a structure-determined system (of systems), while the top ‘V’ describes the structure-determining processes by which such a system is itself composed with other systems to useful ends.

Hillary Sillitto in the INCOSE 2006 conference relates this cycle to the way the scope and boundaries of the resultant system emerge from this cycle through the way four different kinds of question about degrees of freedom are answered:

double-v.jpg

Each of these questions relate to different constituencies with differing vested interests in how they are answered. How, then, is this cycle to be managed as a whole? What happens if we approach this cycle not from the point of view of the systems, but from the point of view of the demands?

As long as the problem remains a generic one based on symmetric assumptions about the nature of demand, the top ‘V can be addressed independently of the bottom ‘V’. But as soon as the demand situation is such that the demands emerging from it are necessarily asymmetric and dynamic (as described here), this is no longer possible – the systems have to be understood as more than socio-technical, and it becomes necessary to model the structure-determining as well as the structure-determined processes.

The need for Through-Life Capability Management (TLCM) is one such situation. The acquisition framework needed to support it is still emerging (see here), but it represents a step-change in the relationship between purchaser and provider that involves both parties in the whole cycle. We can expect to see the need for it emerging elsewhere as the asymmetric and dynamic nature of demand becomes increasingly insistent, for example:

TLCM is an emerging form of asymmetric governance.

Leave a Reply

You must be logged in to post a comment.