Customer Reviews

Software Engineering: (Update) (8th Edition)

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

 

 

I used this book as the text in my software engineering class in the spring semester of 2008. When I was evaluating it for potential adoption, I did not read through it in detail, I looked over the chapter titles and subtitles, read the first few chapters and examined the exercises at the end of the first few chapters. As the semester progressed, I found myself wishing I had read further into the text.
As I moved through the chapters, I found myself mentally noting over and over again that topics are repeated. When the class was over, I asked the students their opinion of the book and they were unanimous, with no prompting from me, in saying that there is a great deal of repetition after the first chapters.
I have no complaint about the quality of exposition or the coverage of software engineering in this book. My reason for not continuing to use it in future classes is solely due to my belief that the size could have been reduced from the current 840 pages to around 600 pages with no real loss of content of flow.

This is a good high-level book for a first software engineering course. It mentions things like critical systems, object oriented programming, and real -time systems, but at a very high level; so it should not be used for a specialized course. It provides many helpful examples and diagrams. My only complaint is that the chapters are very long, and a lot of things are repeated several times. I think this book could easily be 75% shorter without loosing any important information.

It has been 2 years since Sommerville put out the 7th edition of this book. So what has changed? Three new chapters have been added at the end of the 8th edition.

One is entitled "Service-oriented software engineering". All about Web Services, which is a burgeoning field. The 7th edition just had a relatively brief explanation about XML and the sundry services developing atop it. Now the 8th edition goes into those, like the Web Service Description Language, and the Business Process Execution Language. To be sure, the chapter is not an exhaustive explanation of the syntax and usages of these languages. For that, you need to consult books devoted to them (and these do indeed exist). Rather, the chapter furnishes a concise overview that gives you the essence of what they can do. I actually think the chapter should have been simply called "Web Services". The actual title, while accurate, is too indirect.

Another new chapter looks at aspect oriented programming. Again, just an overview. But it does convey accurately what AOP offers. Centred around the key idea of cross cutting concerns. And that conventional object oriented code tends inevitably to have closely related code scattered thru many classes; making maintenance harder. It is by no means clear that AOP will ever become common. But it is one of the most intriguing ideas to arise recently, and Sommerville is correct in explaining it.

In the existing chapters brought over from the 7th edition, I do still disagree with his remarks on Extreme Programming. While XP does have some laudatory features, I take issue with the constant refactoring and the pair programming, as well as having a customer onsite at the developers' place. The latter is simply not realistic in some projects.

While pair programming, and not having programmers responsible for specific parts of the code, totally ignores different levels of expertise. Some programmers are simply better (or more experienced) than others. A real danger is having 2 neophyte programmers unwork complex code made by a senior programmer, that they simply did not understand. If you have done any programming, you will encounter subroutines that are highly intricate and intrinsically hard to understand. Typically, these subroutines are only a small part of the total code. But they might play a crucial part. They should be associated with specific programmers, who are responsible for them.

Another reason against pair programming is when the programmers are not just "pure" programmers. They might have backgrounds in various engineering or scientific fields, where this background is needed for the project. So a programmer/engineer versed in mechanical design, and who has to code accordingly, has different responsibilities from another programmer who has to deal with modelling the electrical circuitry, for example. At the design level, it makes eminent sense to sometimes pair these, when the domains overlap. But at the programming level, each can't usually do the other's work.

it feels like this book goes out its way to stretch easily understandable concepts into a huge 900 page book.

I bought this book as a required textbook for my grad course. I've learned a lot from my past misconception and misunderstanding between software science and software engineering just after reading a few chapters from the book.

The book covers wide aspects of engineering a software, both technical aspects and non-technical aspects (social, laws, ethics) although not in deep-breath details.

I highly recommend this book for any students who want to know about software engineering, pracicing software engineers who want to enhance their engineering ana managerial capability in developing a good software or for self-study for anybody who want to jump into software business.

I was required to purchase this book for a Software Engineering class. This is an incredibly wordy, unnecessarily lengthy textbook. While it is apparent that the author is trying to be witty, it shouldn't take 10 pages to define a term. In the fast-paced world in which we live, this book is unsuitable.

This book is a good book to learn from, it can be a little boring at times but in general it is a good study tool that keeps subject matters seperate where they should be

My ultra-picky professor is known for throwing books across the room when he doesn't like what's in them. He gets very upset when they aren't completely accurate. He has gone through several books in his tenure and this is the one he has stuck with (despite still having his reservations about some of the material.) In my mind, that makes it a very good book. Sommerville is a good writer and makes the material very easy to follow with a lot of graphics, lists, tables, flow charts, etc.

Book got here two days before the minimum, which was a nice suprise. A not so nice supprise was the writing in the book, but I guess I can deal. Only reason for three stars is the writing because the description said "not any mark, excellent condition".

Software Engineering: (Update) (8th Edition)

Received the book within 3 days and the book looks like new.