What do you think?
Rate this book
Managing the Software Process
The author, drawing on years of experience at IBM and the SEI, provides here practical guidance for improving the software development and maintenance process. He focuses on understanding and managing the software process because this is where he feels organizations now encounter the most serious problems, and where he feels there is the best opportunity for significant improvement. Both program managers and practicing programmers, whether working on small programs or large-scale projects, will learn how good their own software process is, how they can make their process better, and where they need to begin. "This book will help you move beyond the turning point, or crisis, of feeling over-whelmed by the task of managing the software process to understanding what is essential in software management and what you can do about it." Peter Freeman, from the Foreword 0201180952B04062001
512 pages, Hardcover
First published January 11, 1989
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 14 of 14 reviews
December 23, 2019
The book is definitely worth reading, even though not exactly my style. I recommended it to a freind of mine and got back only positive feedback.
February 22, 2019
مطالعه این کتاب به دوستانی که دستی در ساخت نرم افزار دارند توصیه می شه مخصوصا اگه کارشون بصورت تیمی و وسیع باشه
Want to Read
December 9, 2009about software making
Want to Read
May 14, 2013i think this will be quite easy to understand the concepts
This entire review has been hidden because of spoilers.
September 9, 2026
Crazy to see the history of what is now Scrum, Agile, and general Software product management.
P.2 A software process is the set of tools, methods and practices we use produce a software product.
We see in this paragraph an explicit statement that this process is built off of Demings work.
5 Stages: Initial Repeatable Defined Managed Optimizing
P. 17 suggests Demmings Book Out of the Crisis
P. 66 Human beings are inherently repelled by technology.
He then goes on to talk about how most will try to find some magic bullet that doesn’t exists. It’s really annoying.
Chapter 7 is kind of interesting when you read it as I did not with my programmer lens on, but as a concept of how to think of dealing with variability… acceptible and non-acceptible exceptions. I mean kinda think about what that means in the world of AGI.
Chapter 8 Software Quality and Assurance… thinking of this in the context of scale is fascinating. You’re right Economy of scale without Q&A is not scale.
P. 160 The ways in which tasks are accomplished
Convention — A general agreement on practices, methods, or procedures, typically arrived at by explicit agreement.
Method — A regular, orderly procedure or process for performing a task, typically defined by an expert.
Practice — A usual procedure or process, typically a matter of habit or tacit agreement.
Process — A defined way to perform some activity, generally involving a sequence of methods or procedures designed to accomplish a specified result, and typically established by technical specialists.
P. 168 - “Clearly it is not wise to establish standards unless there is convincing evidence that it is always the right thing to do.”
It then attempts to conceptualize guidelines and escape functions for a standard. And while it says these will do the same thing, but they more directly acknowledge that errors will happen. Id say they need to acknowledge the error rate is really high.
Ifyou drag that into process in the real world, it’s interesting particularly in education where we’ve overfit standards.
P. 202, interesting list of how to test: Load/stress, volume, compatibility, security, performance (aka does it even meet objectives), instability, reliability, recovery, Servicability, human factors
P. 205
Is the design clear? Does it do what is intended?
Is the coding clear? Did you have trouble understanding it?
Are the comments helpful in understanding the routine?
Would you have trouble modifying it?
Would you be proud of this work if it were yours?
Does the code meet the established coding standards?
Do the tests meet the established unit test standards?
Does input data vary, including maximum, minimum, and nominal values? (All alike data, especially all zeros, is usually a poor choice.)
Is erroneous input data used? (All error conditions should be checked.) Can you think of erroneous data conditions that were not used?
Do the tests show that the routine has the functional capabilities allocated to it?
Do the tests demonstrate that the code completely satisfies each requirement allocated to it?
Does the actual output match the expected output?
P. 218 BUG SEVERITY CLASSIFICATION — MILITARY SYSTEM
Severity 1 — An error that prevents the accomplishment of an operational or mission-essential function, prevents the operator/user from performing a mission-essential function, or jeopardizes personnel safety
Severity 2 — An error that adversely affects the accomplishment of an operational or mission-essential function and for which no acceptable alternative workarounds are available
Severity 3 — An error that adversely affects the accomplishment of an operational or mission-essential function for which acceptable alternative workarounds are available
Severity 4 — An error that is an operator/user inconvenience and affects operational or mission-essential functions
Severity 5 — All other errors
P. 222. He talks about how programmers will always create bugs and then feel guilty about it. The separation of production and testing, in his opinion is one of just making it a process b/c they will never be able to find their own mistakes almost by definition. It’s interesting in th econtext of AI.
P. 302 To measure the software process successful, one must start by knowing the expected results.
P. 303. He discusses that the choice of measurement changes the process itself b/c people are human and they will behave according to how they are measured regardless of right, wrong or otherwise.
P. 315 the list of errors and what precisely is to blame is quite impressive.
P. 446 In the appendix he separates project management from process management.Project management is day to day. Process management overarches that and is the rails from which Project management is possible.
Overall, it’s so interesting how militaristically ordered this book is. So regimented.
P.2 A software process is the set of tools, methods and practices we use produce a software product.
We see in this paragraph an explicit statement that this process is built off of Demings work.
5 Stages: Initial Repeatable Defined Managed Optimizing
P. 17 suggests Demmings Book Out of the Crisis
P. 66 Human beings are inherently repelled by technology.
He then goes on to talk about how most will try to find some magic bullet that doesn’t exists. It’s really annoying.
Chapter 7 is kind of interesting when you read it as I did not with my programmer lens on, but as a concept of how to think of dealing with variability… acceptible and non-acceptible exceptions. I mean kinda think about what that means in the world of AGI.
Chapter 8 Software Quality and Assurance… thinking of this in the context of scale is fascinating. You’re right Economy of scale without Q&A is not scale.
P. 160 The ways in which tasks are accomplished
Convention — A general agreement on practices, methods, or procedures, typically arrived at by explicit agreement.
Method — A regular, orderly procedure or process for performing a task, typically defined by an expert.
Practice — A usual procedure or process, typically a matter of habit or tacit agreement.
Process — A defined way to perform some activity, generally involving a sequence of methods or procedures designed to accomplish a specified result, and typically established by technical specialists.
P. 168 - “Clearly it is not wise to establish standards unless there is convincing evidence that it is always the right thing to do.”
It then attempts to conceptualize guidelines and escape functions for a standard. And while it says these will do the same thing, but they more directly acknowledge that errors will happen. Id say they need to acknowledge the error rate is really high.
Ifyou drag that into process in the real world, it’s interesting particularly in education where we’ve overfit standards.
P. 202, interesting list of how to test: Load/stress, volume, compatibility, security, performance (aka does it even meet objectives), instability, reliability, recovery, Servicability, human factors
P. 205
Is the design clear? Does it do what is intended?
Is the coding clear? Did you have trouble understanding it?
Are the comments helpful in understanding the routine?
Would you have trouble modifying it?
Would you be proud of this work if it were yours?
Does the code meet the established coding standards?
Do the tests meet the established unit test standards?
Does input data vary, including maximum, minimum, and nominal values? (All alike data, especially all zeros, is usually a poor choice.)
Is erroneous input data used? (All error conditions should be checked.) Can you think of erroneous data conditions that were not used?
Do the tests show that the routine has the functional capabilities allocated to it?
Do the tests demonstrate that the code completely satisfies each requirement allocated to it?
Does the actual output match the expected output?
P. 218 BUG SEVERITY CLASSIFICATION — MILITARY SYSTEM
Severity 1 — An error that prevents the accomplishment of an operational or mission-essential function, prevents the operator/user from performing a mission-essential function, or jeopardizes personnel safety
Severity 2 — An error that adversely affects the accomplishment of an operational or mission-essential function and for which no acceptable alternative workarounds are available
Severity 3 — An error that adversely affects the accomplishment of an operational or mission-essential function for which acceptable alternative workarounds are available
Severity 4 — An error that is an operator/user inconvenience and affects operational or mission-essential functions
Severity 5 — All other errors
P. 222. He talks about how programmers will always create bugs and then feel guilty about it. The separation of production and testing, in his opinion is one of just making it a process b/c they will never be able to find their own mistakes almost by definition. It’s interesting in th econtext of AI.
P. 302 To measure the software process successful, one must start by knowing the expected results.
P. 303. He discusses that the choice of measurement changes the process itself b/c people are human and they will behave according to how they are measured regardless of right, wrong or otherwise.
P. 315 the list of errors and what precisely is to blame is quite impressive.
P. 446 In the appendix he separates project management from process management.Project management is day to day. Process management overarches that and is the rails from which Project management is possible.
Overall, it’s so interesting how militaristically ordered this book is. So regimented.
Read
August 11, 2011So good old Humphrey back in 1989 wrote The Bible on managing the software process and its still being used today. This is one of those classics as far as software engineering goes. It is amazingly small book and yet packs more information in it than can be imagined. Not light reading -- 2 chapters were excruciatingly difficult to read. That being said I'm glad I read it.
January 15, 2016
The book is, as someone put it, a precursor to the CMM model of the early 2000s. A fascinating book with core principles still valid. Just not sure how old technologies fit in. But barring that, this book will hold at least until some radically different method of developing software comes up.
Boring in some parts (it is a techie book), but one can just glaze over those pages and move on.
Boring in some parts (it is a techie book), but one can just glaze over those pages and move on.
August 14, 2010
Really the definitive book on the Capability Maturity Model for Software. One can pick up the model elsewhere, but this is the place to get the understanding of the model.
Read
February 2, 2011The foundation book for the CMMI Methodology. A major step in improving the software development process.
Currently Reading
May 11, 2011nice
Want to Read
January 29, 2013i want to know
Read
October 20, 2013i just love the way of author explains the management of software process!
really astonishing
Wow what a lines!
really astonishing
Wow what a lines!
Read
May 18, 2013--------------------dash
Want to Read
December 3, 2013good
Displaying 1 - 14 of 14 reviews