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.
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.
|