There is general consensus - no matter the sector of dedicated systems application - that product complexity is increasing. As reflected in the content of this issue, methods and tools are certainly important elements in being able to handle that complexity.

It's worth emphasising, however, that education and standardisation - or rather, an insufficiency of both - are two factors which are also considered, by just about everyone, to play a significant role.
Discussions with organisations across a broad basket of industry sectors point up, overall, a distinct lack of discipline and method in the current approach to designing dedicated systems. The tendency appears to be to create "islands of technology". Each does its own job more-or-less correctly.

Software, plus the ability for these islands to reside in an architecture linked by network technologies, are changing all that. The systems of tomorrow are becoming software-intensive, networked - and increasingly complex. And most worrying of all - he who says "complex", is really using a covert euphemism for "tending to become intellectually unmanageable".

To tell you the truth, the worry is not so much the complexity per se. Rather, it is how that complexity will be effectively handled and kept under control. Systems become complex when they cannot be thoroughly planned, nor their behaviour fully understood and able to be anticipated. And of course, particularly if you're designing a real time system, then Mr. Murphy has already shown us the way. Those are just the items you need to be absolutely sure you can anticipate.

Considered opinion demonstrates that the root of the design problem lies at the root the system itself - that is, in the requirements capture process. It is one thing to fully understand the behaviour of a system. But if you cannot adequately define system requirements in the first place, then you're asking for trouble. And it's not just a matter of creating a tool to assist in this. When was the last time your marketing and engineering staff managed to agree on requirements? Worse - can you in fact be sure your client has really told you what product functionality they require - rather than a vision of how the end-product should "look and feel"?

To date, we've had "horses for courses" - different tools for different specialist areas. But what we really need is a paradigm shift - dealing with product and system models. We need to be able to simulate, to critique and to verify this or that model - viewed in a holistic manner.

But first and foremost, we need to focus attention on the education issue - and not just education of engineers, but also education of engineering managers. Try this test: what's your ratio of work to rework? Are you into productive programming, or productive communication?

Dr Martin Timmerman
Contact

Dedicated Systems Magazine in general