Introduction to the Personal Software Process(sm) (SEI Series in Software Engineering) (Paperback)

by Watts S. Humphrey (Author)

Editorial Reviews

Review
Introduction To The Personal Software Process provides help for software engineers at all levels of experience, from students to experienced professionals, helping them become far more effective by allowing them to manage their work habits and personal software management techniques. It=20 provides advice and guidance from one of the world's leading software process and software quality experts while providing practical exercises for improving personal skills. Support materials are freely available on the Addison-Wesley website at http://www. awl. com/cseng including copies of the forms illustrated in the book and spreadsheets for the exercises. -- Midwest Book Review

Product Description
Introduces Personal Software Process (PSP), which is a guide to using disciplined personal practices to do superior software engineering. A hands-on book that provides practical exercises to help improve time-management and quality - assurance practices. Paper.

See all Editorial Reviews

Product Details

• Paperback: 304 pages
• Publisher: Addison-Wesley Professional (December 30, 1996)
• Language: English
• ISBN-10: 0201548097
• ISBN-13: 978-0201548099
• Product Dimensions: 9.3 x 6.3 x 0.8 inches
• Shipping Weight: 1 pounds (View shipping rates and policies)
• Average Customer Review: 3.7 out of 5 stars See all reviews (3 customer reviews)
• Amazon.com Sales Rank: #494,873 in Books (See Bestsellers in Books)

• This item is part of The SEI Series.

Customer Reviews

Most Helpful Customer Reviews

10 of 12 people found the following review helpful:

4.0 out of 5 stars Measure everything, interpret carefully, April 10, 2004

By	Charles Ashbacher "([e-mail])" (Marion, Iowa United States([e-mail])) - See all my reviews (TOP 50 REVIEWER)

The Personal Software Process (PSP), which is a registered service mark of Carnegie Mellon University, is all about measuring and recording. Nearly everything is measured, from lines of code produced per unit time to the time spent playing/watching sports. Charts are everywhere in the book; some plot the progress of software development projects and others the weekly schedule of a college student. Therefore, there are charts that are headed "Student Y's Fixed Weekly Commitments."
The initial premise of the book is that of a college student who must plan their time in order to complete all that needs to be done. Of course, the point is to emphasize that planning major projects, such as your life, requires that you set reasonable goals that are compatible with everything else that you want to do. Once the goals are set, the next step is to order your time so that all activities are allotted an appropriate time slot.
The second segment deals with tracking a software development process from start to end. It is all about time, how much you expect to spend on each section and how much was actually spent. The goal is to track now so that your future projections are more accurate. With so many charts and entries, there is nothing that can be measured that does not appear somewhere in a chart.
While I am a proponent of measuring and recording the significant characteristics of any project, one must take care to avoid an over reliance on the act of measuring. Even though software development is a team game, it is still very much an individual effort. There is a great deal of room for the occasional "brilliant stroke", where someone has a flash of insight into a problem that solves it in a new, unique and more efficient manner. The best programmers are still in many ways artists and regimentation can stifle their creative sides.
The PSP is also different from the agile processes, which reduce the software planning cycle to a few weeks rather than a longer term. Very little is also written down in agile processes, and planning to the minute is considered counterproductive. However, even if you are a firm believer in the agile approach, reading this book will be of value. When you write down very little, you must make sure that what is written down is important, so by studying the PSP, you have a better chance of recording what is critical.
Humphrey is on one end of the software development spectrum, in that he sets down a process with extensive planning. Agile processes are on the other end, where there is a minimum of planning. Most development groups will find their best location somewhere in the middle. Since the best way to find your location is to study the extremes, all software developers will find value in this book.

38 of 51 people found the following review helpful:

4.0 out of 5 stars Good if you are a first or second year college student, but, December 16, 1998

By A Customer

I originally bought this book to improve my own software engineering habits. While this book has its merits, I am afraid that it is geared more toward the first and second year college student than the professional engineer. It specifically addresses student issues, and most of the lessons are not applicable to professional work environments. However, if you happen to be a college student in CE, then I would suggest this book as a primer. Humphrey is very detailed in his explanation and extremely epxerienced in this field.

3.0 out of 5 stars This is a great book if, February 11, 2000

By A Customer

This is a great book if you have never, like me, had any type of process education or formal time management training. I wish this book was available 15 years ago when I took my first CS class in college.

For the working programmer, especially in today's visual integrated environment, applying alot of the material is hard. The Lines of Code (LOC) measurement used is not considered the best judge of program complexity, plus in a visual environment where one can spend days laying out forms or reports that generate no lines of code can skew numbers. I understand its use: It is easy to explain and calculate for beginners, but is lacking for working programmers.

There is also an emphasis on distinct phases of program development, particularly the compile and test phase. For those of us who work in a visual environment (be it C, Pascal, or Basic) the phases blur together and tracking time spent on compile is negligable. Also not mentioned is should intentional syntax errors (such as going to copy a variable name) that automatic syntax checking catches be tracked?

The extreme academic bend of the book also begins to annoy after awhile. The use of "small programs" to work with on the job is rare. Tracking number of lines changed can be tough in large programs, even with source code controls in place. The base code review checklist is extremely simple (intentionally) and aimed at C or Ada programmers, leaving other languages hanging.

One last annoyance: Many of the forms talked about are not available to print or use in a spreadsheet. The one form most working programmers would use, the time log, is the most glaring example.

If you meet either of the requirements in the first paragraph, read the book. You will find something of use. Just about anyone in the field would benefit from chapters 3 and 7 (in particular) since we all tend to have problems estimating how much time things will take.

Lastly, most of the data used to show how things improved after using the Personal Software Process was from 2 groups, one "real world" company and a group of students. Both groups only had around 15 people. Even combining both groups a sample of 30 programmers is not overwelming evidence. A larger sample is needed.

Although only 3 years old, to me the book needs to be updated. Larger samples for the improvement examples, handling non-code artificts such as forms and program documentation, and making sure that all of the forms are available on standard size paper (8.5x11 or A4) would be a good starting place.