I'm an introducing SPC methods to my training group. My first step is analyzing the results, by question, on our assessments to determine the stability of the assessment. When I use a c-chart on correct answers, the process is in control. However, when I use the c-chart on incorrect questions from the same data set, the process is way out of control. I would have assumed I'd receive the same results. Can anyone explain this phenomenon?
dlhunt 9/25/2003
Murukesh,
I would recommend that you take a look at some of the journal articles that have been published. One that I saw recently in Software Quality Professional, Vol 5, Issue 4, Sept 2003 is called Integrating Improvement Initiatives: Connecting Six Sigma for Software, CMMI, Personal Software Process, and Team Software Process By Gary A. Gack and Kyle Robison. In the article the authors list several reasons for using Six Sigma in software development. To summarize 1)Software projects are very risky. Six Sigma tools can reduce these risks. 2)Requirement failures are associated with 80 percent of failed software projects. Design for Six Sigma DFSS can greatly improve discovery of latent or "hidden" requirements. 3) Expectation failures are a factor is 65 percent of failed software projects. Six Sigma tools can be applied to development and refinement of software cost, schedule, and delivery quality forecasting. 4) Execution failures are a factor in 60 percent of failed software projects. Six Sigma tools (Defect score cards, Defect modeling) can improve the cost benefit analysis.
David Hunt
ASQ Certified Six Sigma Black Belt, CQA, CQE, Quality Manager
Other Articles Available from The American Society for Quality (ASQ):
QICID: 18996
Title: Applying Six Sigma to Software Process Improvement
Copyright: 2001, ASQ
Author: Siviy, Jeannine M.;
Organization: Software Engineering Institute, Pittsburgh, PA
Subject: Process improvement; Six Sigma; Software quality; Software quality assurance (SQA); Zero defects;
Series: International Conference on Software Quality, Pittsburgh, PA, Vol. 11, No. 0, OCTOBER 2001, pp. 1-10
Abstract: [This abstract is based on the author’s abstract.] Six Sigma is a business-driven approach to process improvement that seeks to improve customer satisfaction by reducing defects. The Six Sigma methodology of define, measure, analyze, improve, and control is the framework for achieving virtually defect-free processes and products. The flexibility of this framework enables Six Sigma methodology, along with its toolkit, to easily integrate with existing models of software process implementation. Improvement efforts using real software data demonstrate the concept.
QICID: 18160
Title: Six Sigma for Software
Copyright: 2002, ASQ
Author: Stoddard, Robert W.;
Organization: Motorola Personal Communications Sector, Libertyville, IL
Subject: Customer expectation; Customer satisfaction (CS); Reliability; Six Sigma; Software; Software quality;
Series: Annual Quality Congress Proceedings, Denver, CO, Vol. 56, No. 0, MAY 2002, pp. 1-56
Abstract: [PowerPoint presentation slides only]
Six Sigma for software provides a competitive advantage. With software components of products now the differentiating factor, success is pivotal on software quality and availability. Six Sigma is a business process that allows companies to improve their bottom line by designing and monitoring everyday business activities in ways that minimize waste and resources while increasing customer satisfaction. The overriding objective is customer satisfaction - the degree of confidence a customer has that expectations will be met by the producer. Six Sigma is a toolbox for software. Software Six Sigma Black Belts know when and where to apply these tools to solve business problems in a timely fashion.
QICID: 19021
Title: Sorting Out Six Sigma and the CMM
Copyright: 2001, Software Productivity Consortium NFP, Inc.
Author: Card, David N.;
Organization: Software Productivity Consortium NFP, Inc.
Subject: Capability Maturity Model (CMM); Comparison; Continuous quality improvement (CQI); Control charts; Crosby, Philip B.; Six Sigma; Software configuration management; Software quality assurance (SQA); Statistical process control (SPC);
Series: International Conference on Software Quality, Pittsburgh, PA, Vol. 11, No. 0, OCTOBER 2001, pp. 1-34
Abstract: [PowerPoint presentation slides only.]
Adoption of Six Sigma is increasing among companies who already employ CMM-based software process improvement. While they are superficially different approaches, does Six Sigma counteract CMM-based process improvement? Both Six Sigma and CMM have a common ancestor in Philip Crosby, but the difference between previous total quality approaches and the Six Sigma concept is a matter of focus. Six Sigma is a business strategy with the concept that companies can gain a competitive edge by reducing defects in their industrial and commercial processes. CMM-based improvement relies on a maturity model to provide a synthetic benchmark. It is an assessment-driven improvement strategy that is ambiguous about statistical methods. Training requirements are tailored to the approach and techniques selected. Performance is not directly considered. Six Sigma and CMM share a reluctance to recognize and measure the magnitude of software rework, but each has its advantages as well. CMM translates many Six Sigma concepts into software engineering terminology, while incorporating Six Sigma techniques helps organizations working towards Level 4 and 5 to deliver the best business results.
QICID: 11245
Title: How Does Software Six Sigma Relate to the SEI CMM?
Copyright: 1997, American Society for Quality
Author: Bxttcher, Peter S.; Stoddard, Robert W.;
Organization: Kommunedata A/S, Aalborg, Denmark; Texas Instruments Digital Imaging, Dallas, TX
Subject: Capability Maturity Model (CMM); Process improvement; Six Sigma; Software quality;
Series: International Conference on Software Quality, October 6-8 1997, Montgomery, AL, Vol. 7, No. 0, OCTOBER 1997, pp. 34-53
Abstract: The Capability Maturity Model (CMM) and Software Six Sigma have commonalities, unique features, and inter-dependencies in their underlying models and in their approaches. The underlying model of CMM has five levels representing the maturity of definition, management, measurement, control, and effectiveness of processes. Software Six Sigma is structured by six steps to continuous improvement of processes through measurement, analysis, and control. The underlying models have many commonalities, so that the steps of Software Six Sigma can be mapped into the levels of CMM. However, CMM has unique aspects, such as how-to information related to but not found in Software Six Sigma. Unique parts of Software Six Sigma include Identify Product or Service in step 1, for which there is no key practice area in the current version of CMM. Inter-dependencies between CMM and Software Six Sigma mean, for example, that an organization must achieve CMM levels 2, 3, and 5 before progressing beyond Software Six Sigma steps 3, 4, and 5, respectively. To analyze approaches, Software Six Sigma is compared with the five-phase IDEAL system, which is the approach for using CMM. Commonalities are the correspondences between the steps of Software Six Sigma and all phases of IDEAL except for the Establishing phase. Examples of uniqueness include IDEAL's emphasis on alignment of improvement efforts with strategy and vision as well as Software Six Sigma's focus on customer analysis in step 1. Inter-dependencies of the two approaches include the parallel time sequence that they follow.
QICID: 9733
Title: Managing Quality of Software: Road to Six Sigma
Copyright: 1991, ASQC
Author: Stott, Daniel R.;
Organization: IBM Corporation, Kingston, NY
Subject: Computers; Parts per million (ppm); Performance objectives; Quality assurance (QA); Six Sigma; Software;
Series: Annual Quality Congress, Milwaukee WI, Vol. 45, No. 0, MAY 1991, pp. 734-739
Abstract: This paper shows how to use six sigma concepts to improve software development processes and to encourage a synergistic partnership between software and quality professionals. The author modifies the definition of Six Sigma, which is traditionally based on fewer than 3.4 failures per million opportunities, to 3.0 failures per million and cites several advantages of simplifying the Failure Per Million Opportunities (FPMO).
Since many software development teams have hundreds of members, every communication, procedure or task represents an opportunity for failure; therefore, each individual must strive for low failure rates. Motorola has identified six steps for achieving Six Sigma (3 FPMO) performance in software development: (1) Identify the product you create or service you provide; (2) Identify the Customer(s) for your product or service, and determine what they consider important; (3) Identify your suppliers and what you need from them; (4) Define the process by which you produce your product or service; (5) Design your process to make it mistake proof and eliminate wasted effort; and (6) Ensure continuous improvement of your process by measuring, analyzing, and controlling the improved process.
Opportunities for improvement are processes, tasks, or procedures with high failure rates. The amount of improvement can be represented as a ratio derived by comparing the "baseline" failure rate to the new failure rate. Improvement results in a greater likelihood of meeting requirements.
forrestbreyfogle 5/3/2003
Subject: Assignment of studying the prospects of implementing six sigma initiatives in a IT company which is doing products related to ERP.
Murukesh,
In your email you note that the life cycle of a project in a software company contains various phases. You asked in which phase do we apply the concept. You note that you already have a defect prevention system in place by your Quality department, where our testers manually capture the defects made by the developers. You then reduce the defects by assigning it to the appropriate engineers.
Would like for you to consider how your basic strategy is similar to manufacturing practices where much time is spent testing quality into the product. In lean testing this is considered waste. I know that it is not possible to eliminate testing with your current software development process completely but we should consider what could be done to the development process to reduce the amount of this form of testing. That is, look at the the types of defects and origination of these defects, improve the process so this type of problem does not reoccur in the future --in my mind this is Six Sigma.
Expanding on this -- rather than addressing which phases of Software development should Six Sigma be applied, Six Sigma methodologies should be applied to the overall system of processes that involve the collecting of customer needs to final delivery and servicing of products.
Suggest that you search for Six Sigma speciality software books and other related books on such sites as www.amazon.com; however, care needs to be relative to forcing some of the traditional six sigma metrics to the software development process. You need to have WISE measurements and strategies that reduce reworks and improve cycle times; e.g., wise use of a Design for Six Sigma (DFSS) approach that integrates well with Lean techniques.
Forrest Breyfogle
512-996-8288
forrest@smartersolutions.com
www.smartersolutions.com