Software Engineering: A Practitioner's Approach (Hardcover)

~ (Author) "In this part of Software Engineering: A Practitioner's Approach, you'll learn about the product that is to be engineered and the process that provides a..." (more)
Key Phrases: software reuse, system spec, macroscopic schedule, World Wide Web, Dorset House, Computer Society Press (more...)

Editorial Reviews

Product Description

Well-suited for both the student and the working professional, Software Engineering A Practitioner's Approach recognizes the dramatic growth in the field of software engineering and emphasizes new and important methods and tools used in the industry.

About the Author

Roger S. Pressman is an internationally recognised authority on software process improvement and software engineering technologies. He is currently president of R. S. Pressman and Associates Inc., a consultancy specialising in software engineering practices. --This text refers to an out of print or unavailable edition of this title.

Product Details

• Hardcover: 852 pages
• Publisher: McGraw-Hill Companies; 4th edition (August 1, 1996)
• Language: English
• ISBN-10: 0070521824
• ISBN-13: 978-0070521827
• Product Dimensions: 9.5 x 7.6 x 1.5 inches
• Shipping Weight: 3.3 pounds
• Average Customer Review: 2.8 out of 5 stars  See all reviews (72 customer reviews)
• Amazon.com Sales Rank: #1,784,801 in Books (See Bestsellers in Books)

Customer Reviews

Most Helpful Customer Reviews

20 of 20 people found the following review helpful:

2.0 out of 5 stars Potentially Good Reference; Not for Pedagogy, April 9, 2001

By A Customer

This review is from: Software Engineering: a Practitioner's Approach (Hardcover)

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.

18 of 18 people found the following review helpful:

2.0 out of 5 stars Encapsulates the worst part of being a software engineer.., November 12, 2001

By	"lodro2" (Washington, DC) - See all my reviews

This review is from: Software Engineering: a Practitioner's Approach (Hardcover)

..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.

19 of 20 people found the following review helpful:

2.0 out of 5 stars No evaluation and analysis, March 11, 2000

By	Mike Whalen "[e-mail]" (Minneapolis, MN, USA) - See all my reviews

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.