Systems Engineering: Coping with Complexity [Paperback]

Stevens and his co-authors (two of them from the UK's Defence Evaluation and Research Agency) know that in this environment, many systems fail, very often because they were inadequately thought out, and often also because their development projects were poorly managed. Chapter 1 begins "The world is currently gripped by changes more intense and rapid than those triggered by the ndustrial revolution..." : we are at once swept into the rich, complex, and dangerous life of real system development.

For Stevens, the problem in systems engineering is complexity, and its mastery is, as the subtitle implies, the key to success. The design of complex systems demands hierarchy - of organisations, of projects, of contracts, of documents. Hierarchy implies interfaces: if you split a system into three, you probably create three interfaces between the component subsystems. Interfaces in turn imply specialisation: someone develops the hardware; someone else, the software. Similarly, someone (the customer) writes the requirements specification, while someone else (the developer) tries to meet those requirements. This, like the prime contractor - subcontractor relationship, consists of a customer and a supplier: the marketplace reaches right into the core of system engineering.

The book therefore covers a startling breadth of subjects, but always with the same practical vision and with the same conceptual tools. The first few chapters broadly follow the European Space Agency's now-classical PSS-05 software engineering standard life-cycle phases: user requirements, system requirements, architectural design, integration (of subsystems) and verification, management.

(Requirements are involved in every one of these phases.) Once the reader is grounded in the basics, the next chapter discusses how to tailor the simple life-cycle just presented. A tell-tale section entitled 'smaller systems' gives the game away: the systems in the authors' minds are a great deal larger than the PC 'systems' beloved of advertising copywriters.

The second part of the book (chapter 8 onwards) starts by looking at more realistic life-cycles, based on the management of risk: when is it sensible to go ahead with something? The answer is, when success can be assured even if the bad risks materialize. That can only be guaranteed if the risks have been quantified. Concepts of requirement priority and benefit, risk, and cost loom much larger in the marketplace than technical issues.

The remaining chapters examine management in multi-level projects (hierarchy again), software and systems, prototyping (to control risk), information modeling, projects and the enterprise, a chapter on how to improve and a summary.

Each chapter consists of a double-page title/table of contents, overlaid on some crisp pencil artwork on the theme of engineering progress (from Leonardo's hang-glider to an agile jet). The text is broken up by plenty of simple flow diagrams illustrating life-cycles, trade-offs, business processes and information models, as well as short summaries of what the most important system documents should contain. Key points are highlighted or bulleted within the text. The chapters end with a page or two of realistically tricky exercises: the answers cannot be coded in C.

The helpful appendices include a list of websites: Systems Engineering comes with its own website which contains pointers to several related sites, and itself includes 'proposed' answers to the exercises which end each chapter. Students will find the glossary helpful and comprehensive. There is an extensive list of very varied references, and a detailed index. This book is a carefully worked out description of the process of developing any large, complex, and risky system. The book can also be read as a polemic: an impassioned plea for the discipline to graduate from its narrow roots, whether in academia or in quality control. The concluding paragraphs make it clear that system engineering is a human process, a 'game' in which there are losers as well as winners, something that can be played well, and that absolutely must be played better to limit the risks and losses that are still all too common....

The book will be of interest to several quite different communities: in particular development managers, clients having large systems developed, and students of system and software engineering will all find much that is of interest here. The book may also be a useful supplement (or perhaps an antidote) to the academic perspective on RE. Everyone should have access to a copy.

An example of how this book opened my eyes is the way configuration management is explained, and how it fits within the system engineering process. IT professionals with my background are subject matter experts in change control; however, few of us (certainly myself) realize that change control is a subset of a much larger picture. Every part of system engineering it covered in sufficient detail to understand the basics. This understanding created, in my case, a desire to further research some areas in greater detail. Overall, seeing the process from a high-level view provided some unique insights about what is missing in IT management that can be filled by borrowing from our system engineering brothers and sisters.

I found this book valuable because I did not have to wade through a dry manual and sort out the details in order to get a big picture of system engineering. The brief, succinct chapters and excellent illustrations provided me with a coherent approach to my own job. In fact, I personally believe that applying system engineering principles to IT service delivery and operations management will significantly improve the IT profession. As such I highly recommend this book to my peers and anyone else who needs to see the big picture of the system engineering and how its principles can be related to their job.