Rating: ![2 stars](http://www.reviewfocus.com/images/stars-2-0.gif) Summary: Mediocre at best Review: I bought this book for an undergraduate course in software engineering. I was thoroughly unimpressed by the book. Pressman attempts to cover too many topics within SE and ends up doing none well. Topics such as documentation, client/server architectures, and internet design are sketchy at best. I think that most of the useful information in this book could be condensed into about 200 pages. I'd think twice about tossing down the bills for this particular text, especially if you are a student and not a professional.
Rating: ![5 stars](http://www.reviewfocus.com/images/stars-5-0.gif) Summary: Great Toolchest for Real-world Software projects Review: I had the 3rd edition many years ago for a course I took. At the time I was a junior programmer and did not see the usefulness for all the management and other information in the book.
Now that I'm a software development lead, I have dusted off the book. It has been a god-send. In one volume is most of the information one needs to gather requirements, price, design, build, test and deploy great software. It is not dogmatic, which may be why it is not more popular. Pressman lays the necessary truths for each step of software development, then gives the reader choices for how to perform the tasks.
The book cites great sources, and is easy to read. Quite a bargin, considering its wide-range and utilitarian nature.
I recommend it.
Rating: ![2 stars](http://www.reviewfocus.com/images/stars-2-0.gif) Summary: A book written by a PhD for other PhDs to make you buy! Review: I had to buy this book for a class and I can honestly say I got very little useful information from it. I have been a practicing software engineer for 12 years - all of it on the bleeding edge (client server, fat client, distributed computing) and much of this book is outdated and related little to what I feel is done in practice. I found it ironic that such an academic tome uses the words "Pracitioner's Approach" in the subtitle. If you want to know what people who study software engineers think they do, buy this book. Otherwise, save your money and subscribe to any of the several good trade magazines which address current issues.
Rating: ![2 stars](http://www.reviewfocus.com/images/stars-2-0.gif) Summary: Potentially Good Reference; Not for Pedagogy Review: 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.
Rating: ![3 stars](http://www.reviewfocus.com/images/stars-3-0.gif) Summary: Good content, delivery is difficult to comprehend. Review: I have worked in system development and maintenance for over 18 years. In that time I have performed programmer, analyst and/or leadership roles on a variety of software engineering projects. I would say that classifies me as a practitioner. I think this book does a good job covering many processes and techniques of software engineering. I especially like the References, Points to ponder and Further readings/web sites at the end of each chapter. However, Dr Pressman's delivery is is not easy for me to follow. Many places in this book I found it hard to sort the meaningful message from the filler sentences. Also the vocabulary of Dr Pressman is not that of a typical technical developer and makes the reading that much more difficult. I am used to acronyms but not the 5 and 6 syllable words when common terminology would suffice. So, after cutting through the static and frequently referencing my dictionary I found the book to be very helpful.
Rating: ![3 stars](http://www.reviewfocus.com/images/stars-3-0.gif) Summary: some good sections, but a lot of filler and fluff Review: 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.
Rating: ![2 stars](http://www.reviewfocus.com/images/stars-2-0.gif) Summary: Bought it only because it was a text book Review: I love to program. I learn new languages just because I don't know them. This book is MAJOR boring. I only own it because it's a required text book for a class I'm taking. Buy it for that reason. No other.
Rating: ![4 stars](http://www.reviewfocus.com/images/stars-4-0.gif) Summary: Good book, but perhaps not the best textbook Review: I read this book with a dual purpose. I am a software developer who is starting a new software engineering project at work as well as a part-time graduate student studying for a comprehensive master's exam. I found this book quite an entertaining read for this genre. It is very well written. It has also given me a lot of good ideas for my upcoming software project. This is an excellent book for someone who wishes to hone their software engineering skills. While this book may make an excellent companion text, I do not think it would work as well as a textbook for someone with no experience in Software Engineering.
Rating: ![5 stars](http://www.reviewfocus.com/images/stars-5-0.gif) Summary: Great book! Review: I really like this book! The way the author tells about McCabe's Cyclomatic Complexity, for example, is really clear. It's goes deep inside the details but is still easy to read.
Rating: ![1 stars](http://www.reviewfocus.com/images/stars-1-0.gif) Summary: disordered, vague, verbose, overpriced Review: 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.
|