Design for Trustworthy Software: Tools, Techniques, and Methodology of Developing Robust Software

Programming has long been considered the engineering equivalent of writing literature, or perhaps composing music. Thus, creativity is an important aspect of the programmer's craft. In the early days of computing, programmers were very scarce, so tests were devised to identify which trainees would likely develop into effective programmers. Those who created the programmer qualifying tests at first assumed that software development would require the same intellectual capabilities that hardware design required. However, this turned out not to be the case. In fact, efforts to retread engineers, draftsmen, time-and-motion study experts, and even physicists were mostly failures (see Sidebar 12.3). IBM, for whom a rapidly growing supply of capable programmers was very important, developed a test that really worked. Surprisingly, it identified musicians as the most promising candidates. After this discovery, it did seem intuitive after all. A program is a statically coded linguistic representation of a dynamic process or performance, just like a musical score when "executed" produces a musical listening experience or performance. The ability to manipulate or read codes or symbols on a piece of paper while imagining what the result will sound like (or, in the case of a program, what the numerical result will be) is a highly creative process. Our interest here is in how TRIZ can be applied to enhance the effectiveness of this process within a given programming staff working on a given project.

Sidebar 12.3: Lingua Latina Non Mortus Est

In the early 1960s, when one of the authors was principal programmer at Univac Defense Systems, he was asked to "retread" a group of 50 mechanical draftsmen as programmers. They had become redundant with the switch from vacuum tube logic to transistor-logic-based computers. The boss asked the author to include his secretary in the class as well. She often found and corrected programming errors when typing assembly-language programs for the programming staff, so he thought she must have some degree of latent talent for this craft. The 50 draftsmen never learned to program, in spite of the author's best efforts to teach them, but the secretary did so well that she was immediately transferred from a clerical pay grade to a professional pay grade as a junior programmer.

The author's next assignment was to write a FORTRAN compiler for the U.S. Air Force to run on a specialized military mainframe that did not have a commercial programming language compiler. The boss's former secretary, now a fledgling junior programmer, was assigned to the team of seven. Each week on Monday, module assignments were handed out with expected input and output. Each week the new programmer showed up early Friday afternoon with a perfect program that could do all the inputs the author had suggested, plus a few pathological cases she had added to the test. She would then ask for the rest of the afternoon off to take her three teenage daughters shopping. After several weeks of this spectacular performance, the author decided to test her skills with an especially complex module. As always, she was in his office right after lunch on Friday with an elegant, documented, and tested solution. The author commented after quickly reading the program as she sat near his desk that she programmed as if she had a degree in Latin, to which she responded, "I do; my BA degree is in Latin." As Paul Harvey would say, the rest of the story is that she was immediately promoted to programmer. She retired from the Univac Defense Systems Division some 20 years later as Director of Systems Programming.

The application of TRIZ to software development was pioneered by Graham Rawlinson (TRIZCON 2001) and Kevin Rea (TRIZCON 2002).[7] Rea took the 40 TRIZ principles that Altschuller and his early colleagues developed and crafted analogical principles that apply to software engineering, similar to the application of the original principles to mechanical engineering. The results are so elegant and useful that they are summarized in Table 12.1 as today's state of the art in applying TRIZ to software design:

So far, the application of TRIZ to software has started with algorithms and improved them by making them run faster, especially on parallel processors. Work has also been reported on the use of a TRIZ-based software tool for software process improvement at Motorola.[9] This tool, TechOptimizer from Invention Machine Corp. (http://www.invention-machine.com/), was intended for manufacturing applications. This project's objectives were to improve quality and cycle time. The following parts of the system were modeled:

  • Development life cycle

  • Project management

  • Software quality assurance

  • Process improvement

One limitation is that budgeted product development cost should not increase. The Principles module of TechOptimizer was found to be the most useful in generating concepts along the lines of Rea's analogical extensions. The Prediction module was less useful but still helpful, and the Effects module was found to be too closely linked with the physical world to be useful in a software process improvement study. The firm's generally available product, the Goldfire™ Innovator's Optimizer Workbench, is a unique problem-solving environment that delivers a structured process for inventive problem solving. It brings focus and clarity to problem definition and analysis, helps generate incremental and innovative ideas, and helps evaluate, validate, and prioritize solutions. Thus, it is a semantic knowledge engine providing precision research, knowledge management, and innovation trend analysis capabilities. The use of the Innovator's Optimizer Workbench indicates that although the transition of TRIZ from the manufacturing world to the software development world may be a bit awkward, it is still promising enough for further research and consideration.

Some of the other early software users of the method seem to think that the method will not really pay off until it can be applied to software architecture or high-level design, and software engineering generally. The pessimists among them think that software TRIZ practitioners must start over using Altschuller's methodology by analyzing thousands of software architecture patents to discover the particular patterns of creativity and innovation that pervade this field in contrast to those of a mechanical nature. Although Rea has done a brilliant job of constructing analogous principles for most of the 40 original TRIZ Inventive Principles, clearly some simply do not apply to software design and development. The 39 Engineering Parameters of TRIZ are even less suitable for analogical transformation from mechanical engineering to software engineering. The last section of this chapter discusses the issue of software patents as a vehicle for intellectual property protection. Although patents might not survive in that role, their precise specifications make good grist for the Altschuller mill to discover how innovation has historically come about in software engineering. The claims are of no interest for such analysis, but every patent begins with a list of its prior art and a recitation of "horribles"the things that are so bad in the prior art that the inventors were led to the invention described in the following specification. Meanwhile, Rea's analogies for the 40 Inventive Principles for Software Design are certainly an adequate starting point to apply the method.

Related

Категории