Stephen R. Schach's "Object-Oriented & Classical Software Engineering" (7ed) is an OK book: it's not bad, but it could certainly be better.

First, some minor quibbles: even though the typography and editing is good, I'm not all that enamored with the color scheme: the orange and black theme is too much like a pumpkin. I know it's trivial, but I thought I'd just pass it along. A little more meaningful is that Schach seems to place too much emphasis on definitions. I don't need multiple reminders of the differences between things like corrective, perfective and adaptive maintenance. It would be better if he just focused on the function and not on the definition. For university use, I suppose this is OK. But, I found it a bit irritating.

The medium-level problem with the book is that there's a lot of temporal shift in the presentation: he would talk about some model or methodology in terms that implied it was the latest and greatest thing. Yet, it had been around for decades. This is probably a function of the overall age of the book: this is the 7th edition.

Most importantly, Schach needs to pick a methodology and stick with it: either talk about the classical methodology or the object-oriented one. Not both. Nowadays, most people probably work with, and are interested in, an object-oriented methodology. Having 1/3 of a book filled with the classical methodology is useless to them. Ditto for those people still working in a classical environment: they won't care about 2/3 of the book. And, for those people who are in a classical environment and want to move to an object-oriented one, there's really nothing in the book that will help them with the transition. If he removed the classical material from the book and published a "how to transition" book instead, that would be great.

Again, it's not a bad book. But, it's not that great. I rate it at an OK 3 stars out of 5.

I had to buy this for my software engineering course at school, and I have found it very useful in explaining software design models and reqs and spec documentation. What I didn't expect were great anecdotes and the chapters on coding practices improved my code-writing skills more than any other source.

I also like the fact that the author strayed away from language-specifics, relying more on the theory and design than the actual impementation.

I had to buy this for my software engineering course at school, and I have found it very useful in explaining software design models and reqs and spec documentation. What I didn't expect were great anecdotes and the chapters on coding practices improved my code-writing skills more than any other source.

I also like the fact that the author strayed away from language-specifics, relying more on the theory and design than the actual impementation.

I took Professor Schach's course with the last edition of this book two years ago, and it has been very useful for me now that I work at a big corporation. It is a common misconception to think of it as a UML or OOP programming book, because many people confuse software engineering with the areas of software development and programming. They are quite different. This book is best aimed at programmers that want to understand the processes that exist for writing well-planned code in a large organizations. Think of this book as focusing on the overarching _process_ of writing software. This is especially important from the perspective of a project leader or a manager in a software company. It also offers important business perspectives for software development that you should be aware of. If you want to understand why your customers are unhappy with your results, why things are over budget, or why your project keeps missing deadlines, for example. There's alot more in there as well. I really liked it, and Schach knows what he's doing. He owns a software consulting company if I remember correctly.

My criticism of the book is not with its content. The content is fine for a text book. My criticism is on the price: $$?! The information is basic software engineering material found in numerous sources. The fundamentals that students need can be found in other texts just as well written and significantly more economical. If you are an instructor you may want to look at Pfleeger or even the Systems Analysis and Design book in the Cashman series.

Again, this is a respectable reference and text book - the price is too much to ask of students though!

I gave up on this book when I reached the extended example of object-oriented analysis, design and implementation. The analysis was ok; the design dropped a few elements without explanation, but was largely coherent.

The implementation was a nightmare. It looked like procedural C++, with practically no relationship to the analysis and design.

I think the book does a good job of conveying the time-tested key concepts behind software engineering. It should not be taken seriously as a discussion of object-oriented methodology.

I gave up on this book when I reached the extended example of object-oriented analysis, design and implementation. The analysis was ok; the design dropped a few elements without explanation, but was largely coherent.

The implementation was a nightmare. It looked like procedural C++, with practically no relationship to the analysis and design.

I think the book does a good job of conveying the time-tested key concepts behind software engineering. It should not be taken seriously as a discussion of object-oriented methodology.

Schach's Object-Oriented and Classical Software Engineering is a textbook in the traditional sense of the word. The book is divided into two parts. The first part, Introduction to Software Engineering, deals with software life-cycle models, teams, software engineering tools, and a few other general topics. The second part, The Phases of the Software Life Cycle, then takes a more detailed look at requirements, design, implementation, and so forth.

The book has undergone a number of revisions during its lifetime, and it shows. Schach discusses both structured and object-oriented methods, but the coverage isn't unified enough; the book feels like a quickly-made patch. I also wish that iterative development and agile methods had received more attention.

To make matters worse, Schach's writing style doesn't impress me much. Ineffective passive constructions abound and modifiers always are put before the verb, even if the sentence contains a modal verb or the verb is be. This actually gets annoying after a while! What's more, Scach's approach is very, very prescriptive, and at least I frequently found myself objecting vehemently to the advice presented.

It's sad that to my knowledge there are no really good general books on software engineering. Sommerville's book suffers from the exact same defects as Schach's. Can a software engineering book not be made accurate, thought-provoking, and fun to read?

Schach's Object-Oriented and Classical Software Engineering is a textbook in the traditional sense of the word. The book is divided into two parts. The first part, Introduction to Software Engineering, deals with software life-cycle models, teams, software engineering tools, and a few other general topics. The second part, The Phases of the Software Life Cycle, then takes a more detailed look at requirements, design, implementation, and so forth.

The book has undergone a number of revisions during its lifetime, and it shows. Schach discusses both structured and object-oriented methods, but the coverage isn't unified enough; the book feels like a quickly-made patch. I also wish that iterative development and agile methods had received more attention.

To make matters worse, Schach's writing style doesn't impress me much. Ineffective passive constructions abound and modifiers always are put before the verb, even if the sentence contains a modal verb or the verb is be. This actually gets annoying after a while! What's more, Scach's approach is very, very prescriptive, and at least I frequently found myself objecting vehemently to the advice presented.

It's sad that to my knowledge there are no really good general books on software engineering. Sommerville's book suffers from the exact same defects as Schach's. Can a software engineering book not be made accurate, thought-provoking, and fun to read?

It is one of the best book that i have read :)

It is one of the best book that i have read :)