Creativity and TRIZ


TRIZ (pronounced "treez," for Teoriya Resheniya Izobreatatelskikh Zadatch) is the Russian acronym for the Theory of Inventive Problem Solving (TIPS). TRIZ is a systematic approach to solving a variety of system problems creatively. Its roots can be traced to the Russian engineer and inventor Genrich Saulovich Altschuller, who discovered that the evolution of systems is not a random process, but is governed by certain objective laws. These laws, proposed by Altschuller, in turn can be used to consciously develop a system based on discovering innovative ideas and implementing them. He states that inventiveness can be taught. Creativity is not instinctive, and one does not have to be born with particular traits to be creative; rather, creativity can be acquired by learning.[1], [2], [3]

Sidebar 12.1: What Is Serendipity?

Serendipity is the ability to recognize a valuable result that occurs when you're actually looking for something else. The word was introduced into the English language by Sir Horace Walpole in 1754. It was derived from a legend called "The Three Princes of Serendip." (Ceylon was called Serendip by medieval Arab explorers from whom the legend comes.) At a rare truce meeting between their incessant wars, the princes decided that each year they would meet and compare their inventions, and a committee of their combined advisers would elect as king for a year the prince with the best invention. The three princes soon discovered that their best inventions often turned out to be not what they were trying to create, but accidental discoveries they had not intended. In a letter to a friend, Walpole called this situation "serendipity" and thereby added this useful neologism to the English language (Oxford English Dictionary, Volume IX). Stories of serendipity abound in American technology. Perhaps the best known is the discovery of a transparent bulletproof plastic later named Lexan at General Electric R&D Laboratories by Drs. Bendler and French when they were only seeking to create a scratchproof form of Plexiglas. Of course, the oldest serendipity stories are the "Eureka!" experience of Archimedes, much later the discovery of X-rays by Roentgen, and the discovery of penicillin by Sir Alexander Fleming.

When one of the authors was vice president and director of a computer architecture program at a company led by a retired military officer, he had the occasion to note to the CEO that innovation inhered in three qualities: creativity, tenacity, and serendipity. The CEO, ever the military commander, leaned across his large desk and inquired intently, "Yes, but how do you manage serendipity?" The author, realizing that he was on the spot, improvised, "You 'manage' serendipity by providing inventors a laboratory environment in which it is very likely to happen." It was a narrow escape. However, the CEO shortly later led the design of a new research laboratory for the firm in which the physical layout maximized opportunities for serendipity. He really got it!


In English, TRIZ is sometimes called by the tantalizing apparent nonsequitur systematic innovation rather than by its Russian acronym.[4] Systematic conjures the image of an algorithmic sequence of activities that are performed to achieve a known result. In contrast, innovation is the result of heuristics, which are the opposite of algorithms, and which are erratic and unpredictable. Writers on the subject do not intend an oxymoron and thus carefully define the term to make it precise. The essence of the theory is that contradictions can be resolved methodically by the application of innovation solutions. The premises on which the theory is based are that the ideal design is a goal, that contradictions can actually lead to improved solutions, and that innovation as a process can be structured systematically.[5] Practitioners of TRIZ have shown that applying common solutions to resolve contradictions improves the design of products and systems. Use of TRIZ has shown it to be far more effective than the ultimate heuristic known as trial and error. This method was favored by Edison, who was fond of saying that genius is "1% inspiration and 99% perspiration." Edison could afford the luxury of doing thousands of experiments to reach a single goal because he surrounded himself with bright young men he trained and supervised closely as co-inventors (see Sidebar 12.2). His methods worked for the incandescent lightbulb, but he wasted a fortune at the peak of his career trying to separate iron ore magnetically.

Actually, all the processes for enhancing creativity are limited, because their usefulness decreases as the goal's complexity increases. At some point all heuristics reduce to trial and error, and the number of trials increases dramatically as complexity increases. Altschuller was motivated to develop TRIZ by two questions: How can the time required to invent a needed product be reduced? and How can a process be structured to encourage breakthrough thinking? He soon realized that scientists are simply not trained to "think outside the box"that is, outside their own field of reference. He and his colleagues then analyzed innovative solutions to problems stated and solved on the worldwide patent base to develop the patterns of innovation. They studied 200,000 patents and selected 40,000 of them as being particularly good exemplars of the methodology they were seeking to develop. These demonstrated that the development of an engineering system is not a sequence of random (heuristic) events but rather is governed by certain patterns. Since then, TRIZ practitioners have reviewed more than two million patents to further refine the method. It is a systematic and orderly way to help engineers think outside the box by giving them examples from beyond their own narrow discipline and experience.

TRIZ has developed a large tool set over the past five decades, beginning with the 40 inventive principles (adapted for software in Table 12.1, shown later), and then the 39 engineering parameters, the four separation principles, the concept of ideality, and the 76 standard solutions.[6]

Table 12.1. Rea's Analogies for Altschuller's Inventive Principles[8]

Principle Number

Principle Name

Description

Software Analogy

Example

1

Segmentation

Divide an object into independent parts

Separate similar functions and properties into self-contained program modules

C++ templates and OOP generally

2

Extraction

Separate an interfering part or property from a system

Define the grammar of a programming language to enable interpretive extraction

Extract text from image files

3

Local quality

Change a system's structure from uniform to non-uniform

Change an object's classification from a homogenous hierarchy to a heterogeneous hierarchy

Nonuniform access algorithms

4

Asymmetry

Change the shape of a design from symmetrical to asymmetrical

Change the program to nonuniformly affect a computation's result

Second-order hashing function to even out a hash table

5

Consolidation

Make operations in a system contiguous or parallel

Make processes run concurrently

Synchronize execution of threads in time

6

Universality

Make a part perform multiple functions

Make a program support multiple functions based on context

Polymorphism

7

Nesting

Palce an object inside another, then another, then another

Inheritance in OOP

Nested objects in OOP

8

Counterweight

To counter a system's weight, merge it with other objects that provide "lift"

Use sharing to support large numbers of fine-grained objects efficiently to counter dynamic loads on a system

A shared object that can be used in multiple contexts simultaneously

9

Prior counteraction

Preload counter tension to reduce excessive stress

Perform a preliminary process or actions to improve a later computation

Multiply by a precomputed reciprocal in a loop rather than dividing by a constant

10

Prior action

Carry out all or part of an action in advance

Same

Java translation to interpretive language for a Java Virtual Machine (JVM)

11

Cushion in advance

Prepare a means beforehand to compensate for unusual events

Use an algorithm that handles worst-case harmful effects

Exception handling in Java

12

Equipotentiality

In a potential field, limit position changes

Change an algorithm's operating conditions to control the flow of data in and out

A transparent persistent data store

13

Do something in reverse

Invert the action to solve a problem

Store transactions in reverse order for backing out

Database recovery

14

Spheroidality

Replace linear parts with curved parts

Replace linear data structures with circular ones

Circular buffer

15

Dynamicity

Design the characteristics of an object or process to change to be optimal

Same

DLLs

16

Partial or excessive action

If 100% is hard to achieve, try for less or more by dithering

Increase algorithmic performance by perturbation

Synchronization in Java

17

Transition to a new dimension

Difficulty with moving an object in a line may by solved by moving it in a plane

Use multilayered assembly of class objects

Interfaces in Java

18

Mechanical vibration

Use oscillation

Change the frequency of an algorithm's execution

Change an object's invocation rate to maximize overall application performance, such as updating balances on accounts after each transaction

19

Periodic action

Use periodic rather than continuous actuation

Perform a task periodically rather than continuously

Time scheduled backups

20

Continuity of useful action

Maximize a system's duty cycle

Develop a fine-grained solution that utilizes the processor at full load

Asynchronous nonpreemptive multitasking

21

Rushing through

Conduct a Process at high speed

Transfer data in burst mode before a worst-case scenario

Allocate network banwidth on a priority basis

22

Convert harm into benefit

Eliminate a harmful action by adding it to another harmful action

Invert the role of a harmful process and direct it back

Defeat denial-of-service attacks on a network server

23

Feedback

Introduce feedback to improve a process or action

Introduce a feedback variable into a closed loop to improve subsequent iterations

Rate-based feedback in an asynchronous transfer mode (ATM)system

24

Mediator

Use an intermediary process

Use a mediator to provide a view of the data in a different context

Mediators can be used XML to enhance semistructured data

25

Self-service

Make an object serve itself by performing auxiliary functions

Same

Automatic updating of applications over the Internet

26

Copying

Use an inexpensive copy instead of the real thing

Instead of creating a new object, use a shallow copy

A shallow copy constructs a new object and inserts references to the original object in it

27

Dispose

Repalce an expensive object with multiple inexpensive objects

Same

Use rapid or throwaway prototypes

28

Replacement of a mechanical system

Replace a mechanical system with sensory means

Same

Voice recognition versus typing and reading

29

Pneumatic or hydraulic construction

Use gas or liquid parts instead of mechanical parts

None

None

30

Flexible films or membranes

Isolate the object from its environment

Isolate the object with wrapper objects

Wrappers in Java

31

Porous materials

Make an object porous

None

None

32

Change color

Change an object's transparency

Same

A transparency function in a photo program

33

Homogeneity

Make objects interacting with a given object out of the same material

Create pure objects of a certain type, ensuring identical properties

Container data object, such as an array

34

Rejecting and regenerating parts

Discard portions of an object that have fulfilled their function

Discard unused memory

Garbage collection in Java

35

Transformation properties

Change the degree or flexibility

Same

Software can be transformed to provide a different service based on properties changing by time of day

36

Phase transition

Use phenomena that change during a phase transition

None

None

37

Thermal expansion

Use thermal expansion of materials

None

None

38

Accelerated oxidation

Replace common air with oxygen-enriched air

None

None

39

Inert environment

Replace the normal environment with an inert one

None

None

40

Composite materials

Change from uniform to composite materials

Change from uniform software abstraction to a composite one

Software design patterns are the core abstractions behind successful recurring problem solutions in software architecture


The natural objective function of innovative system development with TRIZ is ideality, which is defined as follows:

ideality = Σ benefits / (Σ costs + Σ harm)

in which evolution toward the ideal system is guaranteed by increasing benefits while reducing costs and harm. To provide direction to the design evolution, the design team usually imagines the ideal final result, which provides an ideal, if unrealistic, goal but gets the team focused on the same "out of the box" goal. This tends to remove both real and perceived barriers by offering alternative solutions. Starting with perfection encourages breakthrough thinking, inhibits backsliding toward less-ideal solutions, and leads to defining clear boundaries for the project.

In spite of this complexity, the method can be most easily understood as a mapping. As shown in Figure 12.1, all the TRIZ tools support this process. You identify a specific problem and its parameters, and then you map it to a generic TRIZ problem. Using the appropriate TRIZ tools, you find the generic TRIZ solution to the generic TRIZ problem. Finally, you map the generic solution from the TRIZ solution space back to the original specific problem space as a specific solution.

Figure 12.1. The TRIZ Solution Process


The first of the inventive principles is segmentation (see Table 12.1). Using this tool allows the user to apply the process shown in Figure 12.1 iteratively on the various subsystems or their components. Principle 7 in the list is nesting (see Table 12.1), which allows the user to employ the process shown in Figure 12.1 recursively on the whole system under design. The genius of the TRIZ inventive problem-solving or design methodology is that it combines at different levels both algorithmic and heuristic problem-solving techniques. It is a curious way of applying knowledge and experience to produce wisdom. Herbert Hoover, a noted hydraulic mining engineer before he became U.S. President, once said, "Wisdom is not knowing the ultimate, but rather knowing what to do next." TRIZ uses an algorithmic process to lead the inventor toward which heuristic to apply next. As always with heuristics, it is in the end a trial-and-error process, but a highly focused trial-and-error process informed by the experience of three million successful inventions documented as patents.

If you're interested in the development and practice of this sophisticated development methodology, we encourage you to read Systematic Innovation: An Introduction to TRIZ (see endnote 4), written by three experienced practitioners and illustrated with many examples from manufacturing. In this book we want to discuss more-recent applications of the method to software development.

Sidebar 12.2: Being There When the Page Was Blank

When one of the authors was an engineering undergraduate, he took an electrical engineering (EE) course on rotating machinery from a 72-year-old professor emeritus. Needing a professor's signature to pursue an opportunity to participate in the International Geophysical Year in 1956, he went to the professor's secretary to get the form signed. He asked if she would have "the doctor" sign the form. She told him that the correct title was Professor, not Doctor, because the professor had no degree. In fact, he had not even attended high school. Shocked, the author asked how the professor could teach at Harvard without a formal education. The secretary replied that when the professor was 13, his father had apprenticed him to Mr. Edison, and the professor's name was also on the patents for almost all the machinery in the school's EE laboratory. She noted wisely that if you invented it, you don't need to go to school to learn about it.





Design for Trustworthy Software. Tools, Techniques, and Methodology of Developing Robust Software
Design for Trustworthy Software: Tools, Techniques, and Methodology of Developing Robust Software
ISBN: 0131872508
EAN: 2147483647
Year: 2006
Pages: 394

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net