Quality Software Management

QualitySoftwareManagement is a four volume set by GeraldWeinberg, published by Dorset House.

Jerry gives this explanation for the series in the introduction to volume 2:

"In the four decades I've spent in the software business, I've learned that there are three fundamental abilities needed to do a quality job of managing software engineering:
  1. "the ability to understand complex situations so you can plan a project and then observe and act in order to keep the project going according to plan, or modify the plan;
  2. "the ability to observe what's happening and to understand the significance of our observations in terms of effective adaptive actions;
  3. "the ability to act appropriately in difficult interpersonal situations, even though you may be confused, or angry, or so afraid that you want to run away and hide."

I highly recommend these books for anyone who is trying to make sense out of the madness of engineering projects, especially in small organizations.

-- DaveSmith

The above sounds very similar to WilliamEdwardsDeming's ProfoundKnowledge. --DanielSvennberg

From my web site:

I like Jerry Weinberg. He's a lunatic: I like that in a person. He writes from a technical and psychological perspective, describing how to think about what you do. Many of his books are out of print or hard to find. This series is one of my favorites.

-- RonJeffries http://www.xprogramming.com/recommended_reading_prog.htm'' ( BrokenLink )

[A relevant comment moved from CommitmentSchedule:]

I've been reading GeraldWeinberg's QualitySoftwareManagement books recently and it seems like the XP focus on interaction with the end users fits well with Weinberg's idea (adapted and expanded from PhillipCrosby's ideas in QualityIsFree) of quality being defined as that which provides value to some person(s). Weinberg's version is more humanistic than Crosby's original definition of quality as "conformance to requirements" and seems to fit even more closely with the XP ideal of building value for a specific on-site customer. As WaldenMathews pointed out in a comment on what I wrote here originally: "getting the requirements right is the hardest piece of the puzzle. It's too easy to conform to the wrong requirements, and fail to deliver quality." -- PeterSeibel

With reference to XP. One of the declared strengths of XP is the demarcation between customer, who declares and prioritises requirements, and the developers who estimate and deliver solutions. The objective of the demarcation is that as the customer defines the value (and the conditions for defining when the requirement is met) so the work will focus on delivering quality (value to the customer).

A potential problem arises when the GoalDonor (provider of requirements) and GoldOwner (the person with the budget) are not the same person. At this point the quality of the system to the GoldOwner may drop and the project will be in trouble (this is what happened to C3 I believe).

-- TomAyerst

See: TotalQuality

CategoryBook, CategoryQuality CategoryManagement