Customer Reviews

A Framework for Understanding Systems Engineering

5 star:		(0)
4 star:		(1)
3 star:		(1)
2 star:		(0)
1 star:		(0)

 

 

I have been a practicing systems engineer for several years, ever since I joined my employer's Systems Engineering division. Membership in the division is the only qualification I have. I started as an electronics engineer. I had quite a bit of schooling in electronics engineering, but I had none in systems engineering, so I wasn't really sure what a systems engineer was. I did some requirements, scheduling, work-flow, haggling with sub-contractors, and so on. But some other people in the division seemed to be mostly managers, others technical advisors, yet others spent all their time in the lab. Looking for a little clarity, I got this book.

Dr. Kasser reassures me that the reason I wasn't sure on this matter was that the profession as a whole is unsure. It is still feeling its way toward a satisfactory definition of systems engineering and trying to distill a suitably definitive body of knowledge. Several chapters in the book address this issue (ch, 1, 11, 14, and 20), and chapter 11, particularly, develops the "2-D Hitchens-Kasser-Massie" framework, which I found useful because I was able to put all of my systems engineering activities, and also those of my colleages, into some quadrant or other of the knowledge space.

Providing insight into the ongoing professional debate among system engineers is one of the book's better accomplishments. Other chapters discuss particular aspects of a systems engineer's work, like requirements development and complexity management, but while these are reasonably good outlines in themselves, they really don't cohere into a book. The organization is not quite random, but you wonder when you finish this thing why, for example, all those chapters on the systems engineering body of knowledge (1, 11, 14, and 20 again) aren't all in one section. And why isn't chapter 13, "Managing Systems of Systems," linked somehow to chapter 17, "Reducing and Managing Complexity," rather than being separated from it by chapters on object-oriented requirements? Because of this seeming chaotic organization, the book serves better as a reference than as a text book, which you might expect to proceed sequentially, building subsequent material on its predecessors.

The book is also chock full of copy-edit errors. Sometimes when I revise a text, I insert words in the wrong order, neglect to harmonize verb tense, and so on, so that some sentences contain artifacts of two or more versions. When I'm lucky I catch these errors before pushing the "send" button. Too many of these sorts of things have gotten past the editor in this book, and so we end up with sentences like, "The demand for systems engineers...is growing around the world demand" (p. 11-1). Typos abound as well, "i.e." is used when clearly "e.g." is meant (e.g., p. 10-5), and in several chapters (6, 12, 13, and 20) the page numbering is wrong. Human understanding is, fortunately, robust to copy-edit errors, but human attention is distracted by them, and human nature occasionally irked.

This book is substantially less expensive than any formal text on systems engineering, and for systems engineers, who from time to time also do cost-benefit analyses, this is a plus. So for the money, this is an OK reference, and it did, after all, answer my core question about what systems engineering aspired to be.

I've got quite a few books on Systems Engineering, and this is one of the few that balances theoretical and practical views (especially important for us playing a role on both fields - academia and industry).

It has a good breath but does not go deep enough on each topic (although it presents an extensive list of references), so I'd recommend it as a fist read in Systems Engineering.

Presents some topics such as flexible and non-flexible systems, Systems of Systems, Object Orientation for SE, as well as Complexity and how to deal with it, subjects of increasing interest for students, engineers and managers alike. Also, has some examples on real engineering projects, connecting theory with the "real-world".

The only thing that could have been better are i) its finishing and ii) its pictures.

To sum up: it fulfils its goals... helps one understand SE.

Hope this helps!