Application of TRIZ in Software Development
trizjournal | On 15, Sep 2004
By: Herman Hartmann, Ad Vermeulen and Martine van Beers
TRIZ has become a powerful tool to solve problems and to create inventive solutions. An increasing number of patents are being generated with the help of TRIZ. TRIZ is mainly used for mechanical problems and, in its current form, not as much for electrical or software problems. Software is a growing part of a product and is becoming the source of many problems. When TRIZ could be applied to software as well, the applicability of TRIZ could be expanded and software-related problems could be avoided.
At first glance TRIZ doesnât seem to apply to software problems: no atoms, no molecules, no layers to touch; no physical, no chemical effect to apply (see ). Yet software problems have been successfully solved with the use of TRIZ. But, according to many, still a lot of work needs to be done (see , , ). This paper is meant to support the discussions on this subject. On some aspects more experience is needed to obtain a clear picture. Any comment is appreciated greatly.
The examples in literature of applying TRIZ to software are that of applying the Inventive Principles (see  chapter 8 and 10). They are used to solve an algorithmic problem by defining the ideal situation, analyzing the contradictions and using the principles to develop a better algorithm. (An intelligent algorithm is something like the equivalent of a smart construction in Mechanical Engineering.)
The translation from these Inventive Principles into Software is very difficult to use for many; even for very experienced TRIZ users. The translation made by Kevin Rea ( and ) is very helpful but only if you are working in a certain application area (in this case that of concurrent programming). A better way is to use the methodology of Genrich Altshuller by analyzing the patents in Software Engineering and develop a completely new set of Inventive Principles and Contradiction Matrix.
The main contribution of TRIZ however lies in breaking through the âmental inertiaâ(see , chapter 3). In most cases it is sufficient to solve the problem by systematically analyzing the contradictions and making them visible using a graphical representation. Micheal Schlueter (see ) primarily uses this and the IWB software to solve a problem.
The examples that are described in the TRIZ database concern the development of a fast and reliable algorithm using limited resources (such as memory size and processor speed).
The development of successful (patented) algorithms or standards can be commercially very interesting. Examples are: MP3 (for sound processing), MPEG (for Video Processing) and fast search algorithms (Google has become the number 1 search engine, mainly because they own the fastest algorithm). I donât know whether TRIZ is used to develop these algorithms and standards.
Graham Rawlinson (see ), however, concludes: âTRIZ is useful, but not often mind blowing in the solutions derivedâ. The reason for this might be that the development of fast algorithms has been a subject of research since the early sixties (when computers where expensive and the resources where very limited). Many of the methods developed then are still valid now. Furthermore the use of graphical representations (a major contributing factor of TRIZ in the field Mechanical Engineering) and formal methods to describe Software is quite common.
The observation made in 1965 by Gordon Moore, co-founder of Intel, that the number of transistors per square inch on integrated circuits had doubled every year since the integrated circuit was invented. Moore predicted that this trend would continue for the foreseeable future. In subsequent years, the pace slowed down a bit, but data density has doubled approximately every 18 months, and this is the current definition of Moore’s Law, which Moore himself has blessed. Most experts, including Moore himself, expect Moore’s Law to hold for at least another two decades. (From: www.webopedia.com) The result of Mooreâs Law is that, because the capabilities of hardware are continuously increasing, there is mostly not a great challenge for Software Engineers with respect to speed and availability of memory. When the Software proves to be too slow, or requires too much memory, simply wait for new Hardware and the problem is solved automatically.
Creating fast algorithms is important when the required Hardware is not yet available for a longer period of time. Video processing, search engines and wireless data communication are typical examples of today. In a few years time these will hardly be issues anymore. The main challenge in software development lies in managing the increasing complexity due to the increasing size of the software and software teams (see section âSoftware sizeâ and âArchitecture Developmentâ).
In mechanical engineering there is a continuous challenge in creating new products and dealing with increasing contradictions. In many products the technical limits have (almost) been reached. For 100 years, automobiles have driven on combustion engines; 30 years after the Concorde still there isnât commercial supersonic flight and so forth. In other words it becomes more and more difficult to develop new products, and the increase in functionality becomes smaller. Creativity and finding unorthodox solutions while developing new products is essential.
An example: Suppose a mechanical engineer of a car manufacturer goes to his boss, and tells him: âBoss, I am able to make our engine 5 % more efficientâ. His boss probably replies: âThatâs astonishing, take all the time you need and donât forget to write a patentâ. If a software engineer would go to his boss and tells him âBoss, I can make our software work 5 % fasterâ. His boss probably replies, âThatâs of no importance, next month we will get the new processor which works twice as fast. Get back to your work, you still have 20 bugs to solve before the end of this week and donât waste any more timeâ.
As the available memory is increasing 2 times in 18 months, so are the lines of code. Therefore, software products are becoming bigger each year and more people are needed to develop this software. There are trends like open systems; subcontracting; reuse, et cetera to overcome this. All this creates situations that are more complex, resulting in project overruns, unreliable software and unsatisfied customers.
The main challenge nowadays is to manage this increasing complexity. Since the early nineties there is a strong emphasis on software processes. Most organizations are using the capability maturity model (see ) or other frameworks to improve their software development processes.
Another way to deal with the increasing complexity is to create architecture of the software. Software architecture provides the technical structure for a project. A good architecture makes the rest of the work easy. A bad architecture makes the rest of the work almost impossible (see ).
In creating architectures one has to deal with conflicting demands. The Architecture has to fulfill functional and non-functional requirements. Examples of non-functional requirements are: portability, maintainability, flexibility, extendibility and reusability. These non-functional requirements are also know as Soft Intents. In some application areas a softgoal interdependency graph (see ) is used to visualize the conflicts. Mostly solutions are a âbest-fitâ between these conflicting demands. Hardly ever all demands are fully met.
TRIZ could be very useful in solving these conflicting demands (Contradictions) in a more satisfying manner. Since architectures are also used in other fields of mechanical engineering we can learn from the application of TRIZ in this field.
Trends of Technological Evolution
Due to the rapidly increasing capabilities of software it is hard to tell what future products will look like. It is very difficult to imagine what is possible in the future and what will be successful. (Who could have thought that SMS, downloadable ring-tones and removable covers, have become major selling factors for mobile phones?) TRIZ focuses on Technological Evolution and this could be used to identify future possibilities. Combined with commercial trends, this helps in defining successful products in an earlier stage. Further research on this is needed.
Although TRIZ Inventive Principles have been applied to solve Software problems, they were only used to create faster algorithms. The additional value of this to the software community is limited due to Mooreâs law.
The TRIZ Inventive Principles could be very useful in solving the contradictions in the creation of Software Architectures and the TRIZ Trends of Technical Evolution might be useful in identifying future product. The additional value of this to the software community is much bigger. However, on both subjects no examples are described in literature and thus further research is necessary.
The authors would like to thank Micheal Schlueter for help in getting us started and reviewing this article and also Graham Rawlinson and Kevin Rea for their previous work and reviewing this article.
 âFast Software by TRIZâ, Michael Schlueter, ETRIA World Conference – TRIZ Future 2003
 TRIZ and Software â 40 Principle Analogies, Part 1, Kevin Rea, TRIZ-journal 2001
 TRIZ and Software â 40 Principle Analogies, Part 2, Kevin Rea, TRIZ-journal 2001
 Applying TRIZ to Software Problems, Kevin Rea, TRIZCON2002
 TRIZ and Software, Graham Rawlinson, TRIZCON2001
 Hands on systematic innovation, Darrell Mann 2002
 Managing the Software Process, Watts S. Humphrey, 1989
 Software Project Survival Guide, Steve McConnel, 1998
 Non-Functional Requirements in Software Engineering, L. Chung, 2000
Software Process Improvement Consultant
5600 MD Eindhoven
5600 MD Eindhoven
Martine van Beers
5600 MD Eindhoven