|
|
|
|||||||||
|
|||||||||
|
|||||||||
Two years ago the author created an experimental program based on the Theory of Inventive Problem Solving (TRIZ). It contained only one chart. The initial sketch threatened to become a complicated project, so the author implemented a few TRIZ tools to resolve unexpected problems. It was found that the interface solution dramatically simplified the program development. The following is a brief description of the problem solving process.
In regards to effectiveness, TRIZ is largely based on overcoming successful psychological inertia. The problem usually occurs when an individual's brain tries to keep the object or process image unchangeable (even though changes are needed to resolve problems).
But software elements are flexible. For example, a programmer can easily divide, combine, sort, copy, move or erase data, code or images. A programmer finds it easy to start, stop and repeat processes in order to provide parallel operations. And a programmer can easily connect and disconnect any objects while staying accustomed to any change at any time.
This is the reason why it is easy to find examples of TRIZ methods in software implementation, but difficult to find unexpected solutions.
Fortunately, software creation problems are not obviously related to software elements. According to the author of Hands-On Systematic Innovation and TRIZ for Software, Darrell Mann, contradictions tend to occur at the interfaces between software and the outside world.1 The human-software interface is important; it may be the most important program element, which directly influences a common success of software components. On the other hand, one's imagination of human behavior is difficult to change.
Human-software interface problems appear to be the most comfortable for use in TRIZ implementation in comparison to other types of software creation problems. This is true of TRIZ-based software.
In general, TRIZ-based software should present one or more recommendations to a customer. To choose and adapt recommendations to a customer's special case the TRIZ-based program should create a system model. The final goal is to build a system where no unacceptable effects occur. The more complete and the more exact the system model is the more complete and exact the recommendation set is. The only way to create such a model today is to request from a customer a system description.
The two most widely used system descriptions in TRIZ models include:
The object-relationship model is the key to formulating comprehensive recommendations. For example, to receive a recommendation such as "divide the wheel into independent parts" one should define the wheel as one that is related to (interacted) objects.
The cause-effect model can be used to find contradictions and for formulating the ideal final result (IFR). The cause-effect logic is partially presented in simple form in any system model. Any system cannot exist without its elements. Taking out field or substance destroys a Su-field.
But what if someone wants to receive recommendations such as "perform heating in place or area where you want to secure ampoule sealing and do not perform or eliminate heating where you want to prevent medicine degradation"? One should define that the ampoule sealing is the useful result of the heating and that the medicine degradation is the harmful consequence of the heating.
There are several ways to present both models in a graph or matrix. One of the simplest forms is by listing relationships. Usually each element of such list contains an "object-relation-object" record. Such relationships can be shown in a table. The author researched a table and found it lends itself to software users and simple in realization.
Figure 1 shows an example of an object-relationship model implementation. (The author added columns for conjunctions (prepositions) to increase readability.) A user can leave table fields blank or a user may enter object properties, partially defined interactions, actions, processes or even single objects. To define the process the author uses collective names such as "sentence, fact, essential." Take, for example, a coal burning process in a stove, examined in Figure 1.
| |||||
Figure 2 contains sentences related to the problem.
| |||||
The descriptions in Figure 2 allow for the presentation of distinct recommendations for a TRIZ-based program user. For example, one can describe the system (program) that was intended to be created. It contains the interactions table (object-relationship table) and the cause-effect relations table. An individual can choose the object cause-effect relations table and receive appropriate recommendations. One of the recommendations (an ideality concept) can be seen on the bottom of Figure 2. The first program's advice is to get rid of the cause-effect relations table.
Recommendations give users the idea to adapt an existing table by entering cause-effect relations. The first thought that may come to mind is shown in Figure 3. The cause-effect links are shown by the red arrows. The simple system model drawing, which contains only four cause-effect links, appears too complex. A new problem, therefore, can be formulated. The new question is: how does one decrease the drawing complexity?
| |||||
The drawing complexity depends on the number of links drawn. One of the contradictions can be formulated: the number of links should be big to show all the cause-effect relations and the number of links should be small to keep the picture simple and clear.
To resolve similar contradictions a hierarchical menu interface, a tree view interface and a tab interface are widely used.3 Generally, they are different implementations of the same principle. The complex data is divided into separate parts (separation principle) and arranged in a multi-level order (another dimension principle).
Now, try to implement a tree view interface to the problem. In this special case two tree nodes can be linked only once between two sentences because only one cause-effect relation can be defined. By placing some node (sentence) at the top of the list, one can create the tree, which describes how the root node (sentence) links with other nodes (sentences). Such a tree contains only two levels. On the first level there is the root node and the second level contains other nodes. As shown in Figure 4, one can see that the tree contains cause-effect relations of drawing complexity. The drawing complexity is caused by the fact that the cause-effect relations are drawn inside the interaction table. (This relation is shown with elbow arrows.) The drawing complexity also grows as the number of links increases. The drawing complexity does not depend directly on other facts.
| |||||
Only one step divides a user from a final decision. The root node must be placed on top of the list. It is enough just to select the appropriate row in the table and define it as "root node." In Figure 5, the modified tree example is shown. In three combined pictures the selected row "moves" downward. On the top part of the picture the root is the cause-effect relations drawing inside the interaction table. An individual can see that the elbow arrow points to the drawing complexity. On the middle part the root is the entering of the cause-effect relation. And on the bottom, the root is the described system.
| |||||
By using the dynamic principle one can create a dynamic two-level tree. Any time a user selects any row (node, fact) its relations with other rows (nodes, facts) appears. A user is allowed to enter and change the cause-effect relations.
The described interface is a simple implementation that the author created independently as a TRIZ-based experimental program.7 To create the program the simplest tools were used.
The Theory of Inventive Problem Solving methods can be implemented to resolve software problems. In the author's opinion, software interface problems are most convenient to TRIZ implementation. The described examples show how using methods such as the ideality concept, contradictions and inventive principles help to resolve real software problems. The knowledge allows for the creation of a simple experimental TRIZ-based program.
Igor Zadesenets has been using TRIZ since 1989. From 1992 to 1995 he collaborated with Ideation International Company developing software where Zadesenets developed a TRIZ-based experimental program called Adviser. Contact Igor Zadesenets at igorzy (at) gmail.com.
