The Test Program Set and Industrial Automation Branches of the Oklahoma City Air Logistics Center, Directorate of

ing today, this software group applies several measures in the control of its process and product output. The measures relate to financial health, project management, workload and labor, and process improvement (rework and productivity). Rudimentary SPC has been applied to the measures for some time in the form of run charts [1 and 3] (i.e., charts that graph-ically portray measured results in chronological sequence). Run charts are fine, they provide trend information. But in the traditional quality application, what is expected are control charts [1 and 3]. From classes [2 and 4], conference presentations [5], and books [1 and 3], it is implied that you are not really apply-ing SPC unless you are using control charts. Here is where six sigma originates. The predominant thought is you cannot have six sigma (translation: really good) quality unless you know the process is in control. Understanding whether or not the process is in control comes from the use of control charts, thus, the impetus to apply this SPC technique to software quality control. It is our under-standing that the software organizations attempting to apply SPC are using data taken from product reviews, predominantly direct-ed to the coding portion of the process. They are using defects identified in relation to effort expended, or lines of code or func-tion points as data for the control charts. The application of SPC Control Charts in this article does not focus on analysis of software defects. The following discus-sion will illustrate how SPC can be coupled to Earned Value indicators to provide information about the quality of project performance. The use of SPC Control Charts then becomes a tool in the control of software project cost and schedule. Earned Valu