Adapting the Product Life Cycle for Complexity

As the pace of change increases, development processes have adapted to a world where requirements can change at any stage of the life cycle, with a strong focus on the streamlined development of individual subsystems and iterative testing. But this can give leaders a hard time keeping focus on the big picture.

When a system failure is a matter of life and death, or when a system is heavily integrated with few plug-and-play components – in other words, when the cost of an undetected defect is very high – having an approach to the life cycle which emphasises the whole system throughout can be critical to success.

Often, such defects can arise from an emergent property of the system, like an unexpected feedback loop between different components. Just a 15-minute walk in central London takes you from the site of an art installation that gave off harmful porcelain dust, across a bridge that had to be closed for two years because of a resonant vibration, to a building that focused sunbeams and melted cars. In each case, by failing to look at the system as a whole, and to treat users or the environment as part of the system, the result was a costly failure.

Modern development processes like Agile are designed to be adaptable to changing requirements and to ensure quality at the subsystem level. But in practice they can be challenging to adapt to certain circumstances, like when external suppliers are heavily involved in the development process, or when products are complex or critical, in the sense of having emergent behaviour, high costs of maintenance and upgrading, or significant risks from failures while in operation. While embracing the need for development processes to be iterative and recursive, systems engineering recognises there is still a need to model and develop products in a way that is first and foremost concerned with the behaviour of the system as a whole.

Thinking in these terms has produced the ‘V model’, as a distinctive take on the product life cycle. Systems engineering methods strongly emphasise an ability to model the whole system, alongside a scientific methodology of requirements management, so its approach has to retain the clarity of project definition and process associated with a sequential life cycle model, while embracing the modern engineering reality of recursion, iteration, adaptability and change.

At the most basic level, the V model is built around the idea that projects both begin and end with a broad functional understanding of the system and its behaviour. The concept of operation – the understanding of stakeholder needs, system capabilities and performance measures – corresponds to how the whole system is evaluated once in operation and maintenance. Moving further down the V increases the level of detail with which the process is concerned, with corresponding processes for definition and for test and integration on either side of the V.

Verification and validation are primarily conducted against the definitions provided by the equivalent stage. From the beginnings of the V model, recursion along those defined horizontals was encouraged as a clear process for achieving specified functionality. The V model is about the engineering process for the system as a whole, and the ‘requirements and architecture’ stage is about translating customer needs into atomised and scientific requirements, and using those requirements to build a network model of the system which treats individual components as black boxes.

Because of this, the model is fairly agnostic about the process for controlling work in the implementation phase, and subsystem components can be built using a wide variety of processes. Systems engineering is about understanding and assuring the system as a whole.

Even with respect to the whole, the model has adapted to insights from Continuous Engineering and Agile to describe the engineering process more dynamically, by allowing for recursive interactions between adjacent life cycle stages, and allowing for iterated development of future phases. Because systems engineering is focused on a clear process for the translation of needs into requirements and the development of adaptable whole-system models, investing in systems engineering activity in the first iteration of a development process can ensure the process of continuous improvement does not lose sight of the big picture.

At SyntheSys we believe adapting systems engineering to your products is about building up skills, improving processes, and accessing the right tools. In business, what you don’t know absolutely can hurt you, and understanding systems engineering gives a range of opportunities to engineer better throughout the life cycle. To discuss how your organisation may use Systems Engineering to accelerate projects, improve quality and reduce costs, contact us via: cet@synthesys.co.uk or call us on: +44(0)1947 821464.