Statistical process control? refers to both a state of process operation and to the use of statistical tools and techniques to analyze a process or its outputs so that we may control, manage, and improve the quality of the output or the capability of the process. SPC includes a collection of tools (e.g., flowcharts, scatter diagrams, histograms, Pareto analysis, cause‐and‐effect diagrams, run charts, and control charts) to help users understand a particular process. However, Shewhart control charts are at the heart of statistical process control because they measure process performance over time, and provide operational definitions for statistical control and process capability
One reason why SPC is receiving attention is that process management and continual improvement methods have gained wide acceptance in the software community. The acceptance of this “process thinking” approach has motivated many to start measuring software processes in ways that are responsive to questions relating to process performance. Traditional software measurement and analysis methods of measuring “planned versus actual” are not sufficient for measuring or predicting process performance. So the time has come to merge “process thinking” with “statistical thinking.”
Statistical thinking embraces three principles:
All work occurs in a system of interconnected processes.
Variation exists in all processes.
Understanding and reducing variation are keys to success.
If we examine the basis for “process thinking” and “statistical thinking,” we find that they are founded on the principles of statistical process control. These principles hold that by establishing and sustaining stable levels of variability, processes will yield predictable results. We can then say that the processes are under statistical control. Controlled processes are stable processes, and stable processes enable us to predict results. This, in turn, enables us to prepare achievable plans, meet cost estimates and scheduling commitments, and deliver required product functionality and quality with acceptable and reasonable consistency. If a controlled process is not capable of meeting customer requirements or other business objectives, the process must be improved or retargeted.
The term
software process
refers not just to an organization's overall software process but to any process or subprocess used by a software project or organization. In fact, a good case can be made that it is only at subprocess levels that true process management and improvement can take place. Thus, the concept of software process is viewed as applying to any identifiable activity that is undertaken to produce or support a software work product or service. This includes planning, estimating, designing, coding, testing, inspecting, reviewing, measuring, and controlling, as well as the subtasks and activities that comprise these undertakings. This is consistent with the SPC view that a process is defined as “any set of conditions or set of causes that work together to produce a given result.” In other words, a process is a
system of causes
that includes the people, materials, energy, equipment, and procedures necessary to execute the process.
