The following six case studies are included to illustrate and provide more sophisticated examples of some of the methods advocated by this book. These examples were provided by the leading developers of each methodology. We begin with Cost of Software Quality (CoSQ), which illustrates that quality assurance is not a cost issue in software development but rather a methodology that more than pays its own way. This book is devoted to the development of trustworthy business enterprise applications software, with only the occasional reference to the computing or data processing environment in which the application will run. That environment within a business enterprise is characterized by the information technology application portfoliothat is, the set of all the applications that must run together successfully in a viable enterprise. Quality Function Deployment (QFD) is a very important part of the DFTS process and one that most of today's developers are unfamiliar with. Here we include four case studies of QFD to give you a broad perspective on this powerful methodology. They further support the material introduced in Chapter 11.
Case Study 1 (Chapter 22), "Cost of Software Quality (CoSQ) at Raytheon's Electronic Systems (RES) Group," by Herb Krasner
This case study describes a benchmark software development organization that uses CoSQ to document the results of an improvement program and to observe how CoSQ concepts relate to the consistent production of high-quality software. This case study is meant to supplement the concepts developed in Chapter 4 with a realistic large-scale application in a major software development organization. The organization chosen for this case study showed specific, measured benefits. Although part of a large corporation, this development group was typical of a contract software development group in any large organization. Such an organization can be successful only if it can satisfy customers by delivering high-quality software on time and within budget. CoSQ is used to show the costs and benefits of its investments over the time span of the improvement program and provides a good example of how CoSQ is used in leading software development organizations today. Although this case study pertains primarily to large, mostly military, real-time, mission-critical, and embedded software applications, Raytheon breaks the costs into those associated with conformance and those associated with nonconformance. They can then be classified more generally into costs for taking proactive or preventive measures and costs associated with repairs and cleanups needed to fix design/implementation errors and other rework costs. But the conformance costs are due to taking precautions to prevent or mitigate the effects of threats or probable failure patterns. In most cases these are ambiguous or ill-structured requirements, inadequate designer training, or trying to integrate components built with conflicting assumptions. Raytheon's use of CoSQ occurred within the context of its contract-oriented systems business. Thus, the approach reported in this case study was adapted to the specifics of that situation. A more general approach will likely be required in a different business setting, but we believe this case study presents a useful and generalizable example of CoSQ.
Case Study 2 (Chapter 23), "Information Technology Portfolio Alignment," by Ernest H. Forman
The impact of information technology has led to significant changes in the operation of most organizations. The resource demands for both maintaining and enhancing an organization's information technology portfolio are insatiable, and they almost always exceed the available resources. Early decisions about what information technologies to implement and maintain were made by technologists. Today, however, organizations have realized that these decisions, while requiring a solid understanding of technology, also must involve senior management from throughout the organization to ensure alignment with the organization's strategic and tactical objectives. In the early days of MIS, the most critical applications were automated first. But before the needs of the entire organization could be satisfied, technology change demanded that the first five or six highest-priority applications be redone to meet the challenges of new hardware technology, new software technology, or a changed organization or business model. The result was that even after 20 years, the twelfth and thirteenth most important applications never were implemented. In practice, a wide range of processes have attempted to complete an IT applications portfolio that meets the organization's needs. The results of such processes vary widely because what might be intuitive isn't always effective. For example, assigning weights to criteria and projects and then allocating funds to the highest-ranking projects until available resources are consumed may seem logical, but actually this is far from optimal. In fact, the sum of the local optima is rarely the global optimum. This case study looks at the necessary requirements of a best-practices process for deciding what to include in an organization's portfolio of information technologies. This case study takes you beyond the quality issues involved in designing and developing a particular application, to the interactions of that application with existing and future applications in the user's portfolio. The case study illustrates the authors' approach with a specific example, but the case study is presented with such clarity and detail that you will be able to apply the method to your own situation. One well-worked example is often much more valuable than a theory! This case study illustrates an application of AHP introduced in Chapter 8.
Case Study 3 (Chapter 24), "Defining Customer Needs for Brand-New Products: QFD for Unprecedented Software," by Richard E. Zultner
QFD has traditionally been employed not only for new-product development but also for revisions or model upgrades to existing products. Listening to the voice of the customer is especially valuable when the customer has experience with a product that is to be upgraded. This case study deals with the problem of getting input from the future customers of a new, as-yet-undeveloped product with which they do not have experience. Most of the examples of Taguchi Methods application in this book are to product upgrades and improvements for which the method really works well and for which its application is easiest to visualize. Several times throughout this book we have noted that the enterprise business application designer or software architect rarely gets the opportunity to specify and design a whole new product from scratch, but it does happen. When it does, tools such as Concept Selection and QFD come to the rescue. This case study is a valuable adjunct to the methods taught in this book, because it focuses precisely on those situations. Existing approaches to QFD are reviewed, and new methods based on them are developed. The "mind of the customer" approach is used by the Theory of Constraints (ToC), which identifies the customer's core problem and core conflict. These can then lead to a solution beyond the customer's experience and help you plan for its acceptance and implementation. Applying ToC involves breakthrough solutions or paradigm shifts, and thus may involve overcoming the natural resistance of many people to change. This case study reviews the six layers of resistance to change and describes the specific tools to break through each layer. When the software architect starts with a blank sheet of paper to design a whole new product from scratch, he or she may have to deal with fewer constraints, but the novelty that situation permits will very likely engender organizational resistance. This case study, written by the leading consultant on QFD, teaches the designer how to deal with that resistance.
Case Study 4 (Chapter 25), "Jurassic QFD: Integrating Service and Product Quality Function Deployment," by Andrew Bolt and Glenn Mazur
QFD is a unique system for developing new products. It aims to ensure that the initial quality of the product or service satisfies the customer. In today's fast-paced economy, traditional design methods that rely on extensive concept and market testing and multiple rollouts take too much time and increase the risk that copycat products may enter the market first. Best efforts driven by internal requirements risk failing to recognize important customer needs. The tools and methods described in this chapter show you how these risks can be minimized with proper planning. This case study shows you how QFD can be customized to a specific project, in this case to design a tangible productan animatronic dinosaur to be used in a theme park. Although the product development described in this case study is not software only, but a program-enabled robotic device, the case study deals with planning and requirements determination before the product or service is designed and implemented, as Chapter 11 recommends. It is an important topic that has not been covered in software engineering books so far. It is included here as a clear example of the technology. The ideas and approaches used are innovative, yet all can be realized in different ways, depending on the target applications. Even though this case study is not strictly in the software engineering area, it amply illustrates ideas behind the QFD approach that could form the front end of a systematic design of any complex product. Although it is instructive in many ways, this case study also shows that QFD can be a lot of funespecially when it's used to design really big toys!
Case Study 5 (Chapter 26), "Project QFD: Managing Software Development Projects Better with Blitz QFD®," by Richard E. Zultner
QFD has been used for software development for more than a decade, and its popularity is increasing. This case study reviews the value of QFD for the software manager and the management process as well as the benefits to product quality improvement. After reviewing what can go wrong with a software development project, this case study suggests an initial use of QFD called Blitz QFD®. The idea is for project managers to manage value just like they manage timeby spending time on activities that are truly essential rather than those that are merely desirable. With this form of QFD, the manager can manage value in the same way he or she manages time, money, and people. This ensures that the product delivered to the customer is the first priority of the development project. Project QFD takes a portal-to-portal view of the development project and tells the project manager where to spend scarce person-hours on the most important activities in the project. This is the second case study written by the leading practitioner of QFD. It shows how QFD may be used effectively with a minimum of quantitative or computational overhead.
Case Study 6 (Chapter 27), "QFD 2000: Integrating QFD and Other Quality Methods to Improve the New-Product Development Process," by Glenn Mazur
Competitive advantage in the new millennium may belong more to those who can integrate a multitude of disciplines into a system, rather than to those who expect a single nuanced tool to do it all. The House of Quality is really more of a "great room" to which various "outbuildings" and other structures must connect. This is really a "meta" case study that shows where well-known quality and other management tools can be integrated into the New Product Development Process. These tools include Consumer Encounters, New Lanchester Strategy, Kansei Engineering, Theory of Constraints, TRIZ, Voice of the Customer Analysis, FMEA, and SPC. As such, it presents an array of tools and resources for the development team that wants to integrate various quality methods to build an appropriate organization software development strategy. Designing and developing new products is a multidisciplinary activity that involves different people at different times. It varies according to the company, its customers, and its product.
