The UK engineering population is currently unprepared for large-scale, complex IT projects, Stuart Jobbins from Rolls Royce told attendees at a recent BCS Thought Leadership debate.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Definitions of complex systems have to incorporate the numbers game. The higher the number of technical parts and people involved, the more likely a system is to be complex. With complex systems, one can see the final result, but it is becoming increasingly difficult to see or understand the inner workings of such a system, attendees heard.
From a real-time-controls perspective, complexity jumped in the move from linear (continuous) systems, with their inherent constraints, to the realisation of these systems by digital construction, which allowed us arbitrary and discontinuous relationships. This was the liberating step for flexibility - but the precipice with regards complexity.
There is complexity in requirements, as well as within the IT systems themselves. Therefore, there is a need to be able to define the limits of projects. Civil engineers have developed the role of architect and IT modelling can be compared with this.
Unfortunately, real life is not simple. For example, attempting to real-time model a simple fuel injector, across hydraulic, electro-magnetic and mechanical domains, would involve not only the complex interaction of the systems in terms of actuation response, but the environmental factors, (temperature, pressure), along with the dynamic changes caused to these parameters during actuation, as well as mechanical wear-out, drift, original manufacturing tolerance compensation and lots more.
Synthetically trying to replicate the physical world will always be constrained by the technology available. Even if we could sufficiently synthesise the behaviour without introducing error, we would still have to live with the approximation errors, rounding, and so on, of the underlying machines, speakers at the event said.
The "capability" growth of electronics, from a reliability standpoint, but more significantly from a computation standpoint, has enabled engineers to provide solutions that increasingly improve the fidelity of the required operation - a direct factor in increasing system complexity - and allowed us to push the boundaries of a system's operating efficiency.
Complexity continues to grow. In automotive engine control, complexity has been doubling every four years since the advent of electronic control, irrespective of the mitigating actions to simplify. In aircraft engine control, the doubling takes seven years.
Most unreliability in software stems from the interaction of relatively simple components in emergent behaviours, such as the system that is exercised through contexts that the designer had not predicted, or foreseen.
Simple solutions are characterised by a small number of well-defined interfaces and coherent interface policies. Reliable systems tend to be simple (easy to validate) and the product of a uniform development philosophy (usually stemming from a single corporation, team, or even designer).
In terms of a development process for complex systems, there seems to be clear evidence that the successes are based on incremental or evolutionary approaches to a solution rather than revolutionary ones. Even revolutionary systems are often best achieved by incremental developments, in that we usually phase the project to first establish a framework, then some elements of a functioning system and then build towards full functionality.