Schaum's Outline of Theory and Problems of Software Engineering

by David A. Gustafson

Tough Test Questions? Missed Lectures? Not Enough Time? Fortunately for you, there's Schaum's Outlines. More than 40 million students have trusted Schaum's to help them succeed in the classroom and on exams. Schaum's is the key to faster learning and higher grades in every subject. Each Outline presents all the essential course information in an easy-to-follow, topic-by-topic format. You also get hundreds of examples, solved problems, and practice exercises to test your skills. This Schaum's Outline gives you

256 pages, Paperback

First published June 24, 2002

Reviews

[Alejandro Teruel · Rating 2 out of 5]

A very uneven and, twelve years after it was published, ultimately unsatisfying coverage of Software Engineering. The book shows signs of having been rushed into print by McGraw-Hill staff, the back cover offers at least five chapters that simply don´t exist (Software Configuration Management, Cleanroom Software Engineering, Component-Based Software Engineering, Reengineering, Computer-Aided Software Engineering) and some four chapters whose titles do not correspond to the contents page of the book, plus this misspelling "Design Concepts and Principals".

The books attempts to cover too much material but fails to focus on the essentials of the field. The chapters on analysis and design of object-oriented software are particularly weak and its use of UML diagrams is very poor. There are definitions which are incomplete to the point of being wrong (for example, chapter one defines unit testing as "testing by the original developer". A so-called "software process model" is introduced without defining or explaining what a software process is, and then a bunch of different diagrams is simply thrown together randomly in a way guaranteed to ensure student confusion.
There is an intriguing attempt to distinguish between a management approach based on processes and one based on the project, but it is half-heartedly explained and then abandoned. The description of chief programmer teams is ludicrously incomplete:

IBM developed the chief programmer team concept. It assigns specific roles to members of the team. The chief programmer is the best programmer and leads the team. Nonprogrammers are used on the team for documentation and clerical duties. Junior programmers are included to be mentored by the chief programmer.

The chapter on Software Metrics is highly idiosyncratic, but totally unrepresentative of the current use of metrics in the field. The chapter includes an abstract and dry introduction to some basic theory on measurement, which is again quickly set aside in order to introduce a hodge-podge set of, mostly outdated or at the very least polemical metrics like Halstead´s Software Science, Henry-Kafura´s Information Flow which are no longer mainstream issues in software engineering. Lines of code is introduced in a an example, but no caveats on its use are included. McCabe´s cyclomatic number is also introduced because the author considers it to be one of the most commonly used metrics in software development, even though, at least to my knowledge, it hasn´t been used outside of testing for years.

There are some interesting tidbits scattered throughout the book. The brief chapter on risk management is probably good enough for an introductory course on Software Engineering, while some of the measures of cohesion and coupling, as well as some of the object-oriented metrics are interesting in a footnote kind of way.

In short, I would definitely advise students and practitioners to steer clear of this book.