Customer Reviews

Software Engineering: A Practitioner's Approach: European Adaptation

5 star:		(16)
4 star:		(13)
3 star:		(9)
2 star:		(15)
1 star:		(21)

 

 

I have been a software development "practitioner" for fifteen years. I decided to take a graduate class in software engineering to brush up on my skills and this was the textbook used.

There is quite a bit in this book that applies to development environments ten to fifteen years ago and relatively little that applies to current trends.

Much of the material is also presented "shotgun manner" where many techniques from different sources are just thrown out without much attempt at comparison.

I came away with a worse impression of "software engineering" as a discipline than when I started.

I do think this text could be used as a handy encyclopedia: a starting point to find a definition or two and a jumping point for further research on a particular topic.

..you have to read and listen to pedantic and generally useless stuff like this. There are some useful bits here and there, but overall this book is repetitive, far out of date, and often just wrong-headed.

The really important aspects of this book could easily be condensed into a few chapters, but then you would have to add so much back to get to the level a contemporary software engineer would need to begin to know how to do his or her job properly.

Their are some interesting discussions, for example on metrics, formal methods, and testing. But perhaps I liked these in comparison because they actually talked about real things that someone could actually do. The rest of it reminded me of listening to someone get up in a meeting and talk endlessly about TQM and business reengineering and so on; you know that the VP is going to love it, but when it comes to actually implementing it, that guy is the last person you want to actually have on your team.

Basically, the author doesn't seem to have a clue about how software engineering is actually done in 2001. There is far more in the text talking about completely outdated structured design techinques then there is about OO design, for example. What there is in OO design and analysis seems like filler, or stuff that was made up because it sounded good.

For example, in the chapter I'm reading right now, Pressman describes "THE [emphasis mine] system design process." Apparantly, this process involves among other things, "allocating subsystems to processors and tasks." In the world of Application servers, object brokers and so on, isn't this really an implementation detail?

Anyway, its a lot of blah blah blah, and a lot of incorrect or barely correct details; for example, unit testing is described as primarily a white box activity, when in fact in appraoches like XP, unit testing is largely black box. Actually, there is no discusion of agile softwarte development techniques at all. Design Patterns get a page and a half, whereas DFDs (who the hell uses these anymore?) get like 30 pages.

Often, the exact same material is presented in two differnt places in the book. For example, the treament of Mayer's modularity principles appears almost verbatim the same in chapters 13 and 20, expect for some reason, its formatted differently!

Overall, the impression is exactly like that I had of my high school civics text book, i.e. they must be charging by the pound. And they are charging filet prices for hamburger. Certainly not worth the (dollar amount) McGraw Hill is charging. Unconscionable, when I can buy Knuth's entire set for (dollar amount).

Pressman is not a bad writer, but he needs to be edited and this book need a ground up rewrite. It would also be helpful if he had experts or real practioners involved in the recreation of the book. Maybe I'm just bitter because I have to read it for a class, but this pracitioner has better things to do! Don't buy this book unless someone has required you to, and if they do, complain!

(Do you get the idea I didn't care for the book?)

___

Update:

Now that the class is finished, I felt it was fair to provide a bit of an update. I did promote the book from 1 stars to 2, but barely; 1 and a half is more like it. I also toned down a couple of the more obnoxious comments I had made.

On the positive side, Pressman does have his moments. He is generally good at explaining topics clearly, and he does have some good sense of the relative merits of different appraoches. SO the book is not a complete waste of time and I have found out some useful things from it. I really liked his critcal treatment of BPR, I have to admit. But I'm glad I have the expereince to know what to take for granted, what to take with a grain of salt, and what to disregard completely.

But in general, the book is still overpriced, far out of date, often contradicory, repetitive, and not up on current approaches. Basically, a "fat" book and that ain't neccessarily good, if you know what I mean.

I'm a PhD candidate in Software Engineering, and I have tried to use this text in several occasions both as a student and as a teaching assistant. I have always been disappointed. My largest problem is that the text attempts to do too much, and ends up doing nothing well. There is no analysis of the strengths and weaknesses of different methods. Why/When should I use OO instead of structured methods?

Furthermore, since the book covers so many topics in a limited number of pages, there simply cannot be enough information in order to apply any of them. If you want to try to analyze, design, build and test even a toy problem, there are inevitably a raft of issues that this book does not address. This book does not provide a student a firm grasp of _any_ part of the software engineering process.

I seldom review books but feel compelled to in this case because Pressman's book is so overpriced. As a practicing SE and graduate student of SE I've found his book to be disordered, vague, and verbose. Consider the following randomly selected paragraph -- yes, out of context -- but typical of his writing style: "The...system model (at any view) may call for a completely automated solution, a semi-automated solution, or a nonautomated aproach. In fact, it is often possible to characterize models of each type that serve as alternative solutions to the problem at hand. In essence, the system engineer simply modifies the relative influence of different system elements (people, hardware, software) to derive models of each type." -- page 250. Like the entire book, you can read this several times and still not get anything out of it. Is he simply saying that you can approach problems in more than one way? Elsewhere in the book, re-used software is called "partial-experience" software; after-ship bug fixes result in "external failure costs"; and "behavioral modeling" is an operational principle for all requirements analysis methods. The book is filled with such fluffy nonsense. Reading this book is like drowning in maple syrup.

I used this text in a software engineering course as an undergraduate. I think the problems with this book are two-fold. First, Pressman tries to cover too much and ends up covering nothing very well. The chapters on client/server architecture, realtime software engineering, and documentation are particularly weak. In many places, Pressman "discusses" an SE topic by citing a bunch of articles and books, thus avoiding the troubling task of having to actually present content. The second main problem with this book is that it is addressed to practitioners, as the subtitle suggests, not students. Pressman almost never addresses questions that start with "why", focusing instead on questions that start with "how". He answers questions like "How do I do a requirements analysis", not "why should I worry about requirements?" or "Why should I prefer cleanroom methods over other alternatives?" These are questions that students will want answers to, but software professionals probably already understand at least intuitively. If you are a professional developer, then you might find Pressman to be a moderately useful reference. If you are a student, forget it. Find another book. If you are doing anything OO-centric, run immediately and buy "Design Patterns" by Gamma, Helm, Johnson, Vlissides. If you are working on some other type of project, like a web or database project, I am sure you can find a better book than Pressman. The verdict: Unless you like shelling out money for mediocre books, avoid this one.

I am a mature,second-degree computer science student at a Canadian university and have found this book to be an unmitigated disaster. There are many strategic errors that make this book unsuitable for undergraduates; let's examine them in turn.

Firstly, this book is wildly verbose. You would think after reading this book that the author got paid by the word. It seems that often the authour used 100 words to say something when only 5 would do. All to frequently, instead of just stating a definition,the author will quote extensively one of the industry's 'patron saints' to discuss it at length. Very bad. There are far too many quotes.

In addition,there is a love of three-letter acronyms. Every chapter is crammed with terms to learn. If you're the type of person who loves to use technical terms to impress people, this is your book. If you are just like the rest of us and want to learn how to engineer software, avoid this book like the plague.

Finally,this book doesn't employ good teaching style. In the body of the text, concrete examples are rarely given by the author, yet he asks for such examples in his exercises ! He has written far too general a nook. This goes against the principle of 'tell then test' comprehension.

Professors: PLEASE avoid this book !

I just finished using this book for a software engineering course. This book does have some good information but it is surrounded by a lot of filler. The length could easily be reduced by 40% without losing anything.

What I disliked:
1. Too many useless quotes that give no valuable information. Many of the quotes just seemed useless IT/IS filler with buzzword like comments. This isn't a book I would keep as a reference but its target audience seems to be a classroom environment.

2. Excessive organization. The author seems to give a general overview, then medium detailed discussion, and then an in depth discussion. The text could benefit from shortened general overiews and move directly to the in depth discussion of a topic. The length of the book could be reduced while still keeping useful and valueable content.

3. Over complicated language. Some of the language is unnecessarily complicated. I have the same feelings on this as a previous reviewer (about terminology and syllable length etc).

4. Too IT/IS/MIS based. This is more of a personal preference but the text just seemed a little watered down for people who aren't in computer science.

What I liked:
1. Analysis sections. I felt these were really useful and practical. Easy to follow information.

2. Testing sections. The discussion of different kinds of testing methodologies was helpful though I would have liked it to be more technical.

3. OO sections. Just some really good information here but again I would have liked it to be more technical

My overall impression of the book is that there is definately some good information but you have to sort through a lot of fluff to get to it.

While this book is acceptable and a fair resource for a software engineer, the price is absurdly high. There are many books out there that explain the same concepts in this book, without the unnecessary fluff, and for half the price. The fluff in this book itself should tell you that the author is not concerned with knowledge, but with greed.

i'm using this book for a graduate software engineering course. i don't feel that i've gotten my money's worth. i expected a book that was clear and concise; i found it tobe neither. i've been very disappointed

I am studying for an M.S in software construction in Denmark and this textbook was assigned to a course covering Software Engineering this last semester. The semester at the same time was focusing on teaching the theory of compilers and computation complexity.

Being from Denmark, english is not my native language and I must say that the verbose language used in this book sometimes had me pulling my hair. It seems I am not alone when i say that. Most of the reviews here tell about problems with the overcomplex language used.

I am not sure why the outher finds this necessary. There is also much use of references to other (somewhat outdated) books about the subject. I am not sure how many several authors I have read when i finish this one - it must be several. The left-margin is used for key-points, little advices, web-references which is a great idea. But they do take away the focus of the main text.

I cannot say whether or not it presents the material correctly or if something is missing or the information is outdated or whatnot - I just do not like this book. It seems it was written for software engineers already in the field (it is the practitioner's approach) and the only thing they really need is a (grown up) presentation of the methods used in modern software engineering. And this book does contain that - indeed. Atleast it seems like it.

This book is not for students which at the same studies technical courses like compilers and complexity theory. The intended reader for this book was perhaps never meant to produce source code but instead do the management of these chaotic projects. Though, this I am not sure of, since I an not a practitioner - but a hardworking student seeing myself reading this while coping with the immense culture shock it is for me to realize that I do not know anything about developing software.

The book does manage to give away information (if read carefully) and from one perspective it is not just a waste of money. One usefull feature are the examples of dialogs between members working on a fictive software project. They are very informative.

But to use it like is has been done in my situation is just a clear misconception of the reality which lies in the study of the conceptually hard areas of this kind of education.

Bottom-lines:

- You like programming, mathematics, theoretical studies and understand that careful planning and execution of software projects is a requirement - get another book on software engineering. Perhaps the one by Sommerville or McConnels's Rapid Development are good bets.

- You have been working in the field of software engineering for several years but haven't really gotten the touch of programming or have had ups and downs managing software projects, buy this book indeed, you'll cope with it just fine.