Continuing the Development Cycle

You have heard the voice of the customer in a Taguchi-focused requirements study. You have met the customer's expectations and approval in a Taguchi-centered design specification. You have designed a software product that has been subjected to a Taguchi parameter analysis and optimization against all the adverse but uncontrollable noise factors the team can imagine. Now it is time to complete the development process and actually build the product with software trustworthiness as the goal. However, perhaps we should call the software development process a cycle, because it is the nature of software to be constantly in a state of redesign. The life cycle of any version of a typical enterprise software application is about three years. Conventional wisdom in the field says that when a software product or application is released to the marketplace as version 1.0, the design team should already have version 2.0 in the later stages of technical design and should be working on the requirements for version 3.0. To a hardware designer, such a product-planning process appears to be a rather cynically managed effort to achieve planned obsolescence, but such is the nature of successful software development. The flexible nature of software and the escalating expectations of its users are such that the designer's reach must always exceed his or her grasp. The authors consider this constant improvement and extension process or cycle to be a natural application for Taguchi Methods, because they allow the development group to become a learning organization. In other words, as each version of the product becomes more capable, it becomes at the same time less complex internally and less prone to errors, and thus more robust and trustworthy.

This chapter describes how Taguchi Methods can support each of the verification and validation stages of the development cycle and gives an example or case study of their application to these phases. Until more software vendors employ formal methods in software design, conventional software development processes will continue to be the mainstay of development. Formal methods such as Lawson's Landmark™ and Praxis High Integrity Systems Z require that application developers begin not by writing code but rather by arranging symbols in logical propositions. In the case of Landmark™, the application or specification language is the logical language of accounting, or supply chain, or purchasing, or payroll. In the case of Z (pronounced "zed"it's British, don't you know!), it is essentially the language of mathematical logic: the propositions can be examined for correctness and logical consistency or even proven valid, like a theorem.^[1] As soon as the developer is certain the specification has no logical flaws or bugs, he or she can convert it to a nearly bug-free program semimanually (Z) or automatically (Landmark). The actual cost of bugs delivered in software is truly incredible. More than 18% of software projects are canceled before completion.^[2] But the greater potential losses come from projects that are completed, installed, and then compromise the future of the business using them. The urban legend discussed in Sidebar 18.1 is such a mild case compared to reality that it has become a standing joke among developers.

Here we will start with the definitions supplied by Watts Humphrey of the Software Engineering Institute, which he took from the pioneering work (1976) of G. J. Myers.^[3], ^[4] However, it is our intention to bring these concepts into the context of the process as a whole with Taguchi as a backdrop.

• Testing: The process of executing a program or part of a program with the intention of finding errors.

• Verification: An attempt to find design errors by executing a program in a test or simulated environment. Whenever possible, it is the process of proving a program's correctness.

• Validation: An attempt to find functional problems by executing a program in a test environment.

• Debugging: Diagnosing the precise nature of a known error and correcting it.

These are very early definitions, but they provide a good starting point for making the concepts more precise. Note that testing is a means for verification and validation, and that debugging is a corrective activity, not a testing activity.

Sidebar 18.1: An Urban Legend About Business Software

A story has been floating around the information technology industry for more than 20 years. Although it's probably apocryphal, it is so plausible that it refuses to die. It goes like this: A major retailer with a complex multi-warehouse distribution system experienced a software glitch that caused one of its warehouses to suddenly "disappear" from the system. The company was in the midst of simplifying its supply chain and had recently closed several warehouses as a cost-cutting measure, so no alarm was raised when no new goods arrived at the missing warehouse. Nor, of course, were any requested for dispatch. Goods originally sent to this warehouse were automatically redirected to others in the system since it no longer "existed" (was no longer a viable destination for purchased inventory). The employees at the warehouse were given no instructions, so they just kept reporting for work each day as always. Given no information, they kept the place shipshape and awaited new instructions, which never came. The firm's payroll system was not linked to the supply chain/warehousing system, so the employees of the ghost warehouse kept receiving paychecks. When the software glitch finally came to light, the aging inventory in the missing warehouse was sold off by a factoring firm. The employees were transferred to other sites in the company, with instructions to tell no one about the problem. Apparently, all the employees have kept their silence, because no one has come forward to verify this story. Even if it's true, it would not even make the list of major supply chain software failures. In 2004, Sainsbury lost $527 million, and in 2001 Kmart canceled a new supply chain system after spending $130 million on it.^[5] Lack of an adequate supply chain system soon drove Kmart into bankruptcy.