Often I've been asked on how the quality methodologies used in software are related among them. For instance, talking about Six Sigma, CMMI and PSP/TSP.
My answer is always related to Deming Circle. Deming circle is an iterative problem-solving and quality-improvement process consisting in four steps: Plan, Do, Check, Act.
In software, we use the no-physical characteristics of the products we create as an excuse to not follow an industrial practice, "Why should I care about a free-defect product when fixing it is almost free??" But it is not free, and we must use a proven practice to ensure the little defects injected in design and code don't increase the product price and schedule.
The Deming Circle consists of (from wikipedia):
- PLAN
- Establish the objectives and processes necessary to deliver results in accordance with the specifications.
- DO
- Implement the processes.
- CHECK
- Monitor and evaluate the processes and results against objectives and Specifications and report the outcome.
- ACT
- Apply actions to the outcome for necessary improvement. This means reviewing all steps (Plan, Do, Check, Act) and modifying the process to improve it before its next implementation.
As you can see, this can be easily mapped to a common development practice. But that not always happen in real life. And when a methodology is followed, it's not always at all levels, meaning some developers don't understand how the quality of the code they produce affects the entire product.
Six Sigma uses industrial practices and tools to follow this improvement circle. In a typical DMAIC process you Define what are you trying to improve, then you define a way to Measure the process status, you Analyze the gathered metrics, then decide what to Improve and, finally, you Control the process to ensure the improvement doesn't fade away.
The problem here is that Six Sigma is generic, what makes it feasible to use in any industry, but not always the ideal tool on a given one, like the software industry. In our case we need first to define a way to measure the software process and then tailor the statistical methods.
With CMMI we have an improvement quality framework for software. For different process areas we can improve using practices from a set of defined maturity levels. First we need to Manage our process, then we are able to Define it for organizational use, once defined we can Quantitatively Manage it using statistical tools, and, finally, use all this data to Optimize it.
The problem is that these practices are relatively easy to deploy for departments, groups of projects, and project managers, but very difficult to find a practical usage in a developer daily work. I, a programmer in a CMMI-5 project, may not know how to apply the available quality tools on the lines of code that I need to write right now.
And here is where PSP and TSP can help us to apply the quality philosophy on a person level. PSP ensures every individual has the basic skills for estimating, planning, quality managing and measuring his/her development process. TSP launch is a set of planning sessions that ensures every one in the project agrees on what is needed to do, how to do it, and what is the plan to follow. During project execution we use TSP Managing to ensure the plan and process is followed, to monitor and evaluate project performance, and to improve individual and team processes and support artifacts.
