B7 in a DFTS Context

As we explained in Chapter 2, Design for Trustworthy Software (DFTS) is essentially a design technology. It emphasizes upstream activities and employs specific tools, techniques, and methodologies to deliver trustworthy software. In this respect, it is akin to designfocused quality initiatives such as Design for Six Sigma (DFSS). However, software development must also provide problem-solving/process-improvement opportunities, as manifested in various iterative loops of the DFTS model (see Figure 2.6 in Chapter 2). Without such iteration providing internal feedback as well as customer interaction and consequent opportunities for process improvement, the model will have a severe deficiency. Process improvement capabilities are an integral part of the DFTS technology and its accompanying process. In this sense, DFTS is not unlike TQM/Six Sigma, which are process-focused quality management systems. DFTS thus must possess design as well as process improvement capabilities to be effective; one is seriously handicapped without the other. But given the predominance of design in the software development process, an effective software development technology comprises process improvement capabilities that are a subliminal part of the design process and deployed as required. In particular, B7 tools can be of great value in project management, inspection, and testing and in analyzing software metrics. But statistical tools generally are of relatively limited use in upstream design phases given the lack of volumetric data. However, as we stated earlier, not all B7 tools are quantitative, let alone statistical. All nonstatistical tools can be used in upstream phases too.

B7 tools become even more effective when used as part of the systematic DFTS framework. In Chapters 2 and 5 (see Figures 2.6, 5.1, and 5.6), DFTS was presented as a step-by-step technology deployment that includes organizational learning, human competence building, and problem-solving subprocesses. Such a step-by-step approach is crucial for three reasons:^[4]

• It makes the decision process explicit.

• By acting as a "checklist" of the key steps in a development activity, it ensures that important issues are not overlooked.

• The structured methods can be made self-documenting. In the process of executing the method, the team creates a record of the decision-making process for future reference and to educate newcomers.