1. Explain the Six-Sigma quality constraints and provide a justification as to why the software development company should consider it.
2. Compare and contrast quality control processes for both hardware and software.
3. Examine the arguments presented in the case study and evaluate their applications to control the quality of software produced in the organization.
4. Propose a testing strategy for a software development project that ensures high quality of the software delivered.
5. Describe the idiosyncrasies of software, and explain why software needs a different set of rules for testing and for quality control as opposed to those used in hardware.
6. Use at least three (3) quality resources in this assignment. Note: Wikipedia and similar Websites do not qualify as quality resources.

• Be typed, double spaced, using Times New Roman font (size 12), with one-inch margins on all sides; citations and references must follow APA or school-specific format.

Why Six-Sigma Efforts do not Apply to Software

When we think of high-quality systems, we often use hardware analogies to justify applying successful hardware techniques to software. But Binder (1997) explains why some of the hardware techniques are inappropriate for software. In particular, consider the notion of building software to meet what is known as “six-sigma” quality constraints. Manufactured parts usually have a range or tolerance within which they are said to meet their design goals. For example, if a part is to weigh 45 mg, we may in fact accept parts that weigh between 44.9998 mg and 45.0002 mg; if a part’s weight is outside this range, we say that it is faulty or defective. A six-sigma quality constraint says that in a billion parts, we can expect only 3.4 to be outside the acceptable range (i.e., no more than 3.4 parts per billion are faulty). As the number of parts in a product increases, the chances of getting a fault-free product drop, so that the chance of a fault-free 100-part product (where the parts are designed to six-sigma constraints) is 0.9997. We can address this drop in quality by reducing the number of parts, reducing the number of critical constraints per part, and simplifying the process by which we put together separate parts.

However, Binder points out that this hardware analogy is inappropriate for software for three reasons: process, characteristics, and uniqueness. First, because people are variable, the software process inherently contains a large degree of uncontrollable variation from one “part” to another. Second, software either conforms or it doesn’t. There are no degrees of conformance, as in “doesn’t conform, conforms somewhat, conforms a lot, conforms completely.” Conformance is binary and cannot even be associated with a single fault; sometimes many faults contribute to a single failure, and we usually do not know exactly how many faults a system contains. Moreover, the cause of a failure may rest with a different, interfacing application (as when an external system sends the wrong message to the system under test). Third, software is not the result of a mass-production process. “It is inconceivable that you would attempt to build thousands of identical software components with an identical development process, sample just a few for conformance, and then, post hoc, try to fix the process if it produces too many systems that don’t meet requirements. We can produce millions of copies by a mechanical process, but this is irrelevant with respect to software defects …. Used as a slogan, six-sigma simply means some (subjectively) very low defect level. The precise statistical sense