Since my first experience with software engineering and ever after I have wondered why all methods only state the products which have to be delivered. The syntax is described, the semantics get less attention, and how the products have to be made, how to transform a requirements document to a structure chart for example, is totally neglected.
When I started to develop my own software engineering method which supports the reuse of existing artifacts and knowledge, I got a further shock. The existing methods were based on experience only. No sound theories backed them, no explanations were given why it should be done in the way described or why it should work. No sound statistical comparisons were made.
Software engineering research is not yet research in the scientific sense. Software engineering methods are developed and tools are build based on reasonable sounding arguments only. Afterwards it is claimed ``it works because of the higher productivity'', but we all know the Hawthorne effect. A change can have a positive effect independent of the kind of change. Changing back to the old procedure has again a positive result. Therefore it is impossible to use this kind of information to build a unifying theory on software engineering. See [#!bradley!#,#!habermann!#,#!richardson!#,#!thayer!#] for a discussion about this topic.
Another reason is that if one tries a statistical sound way of measuring the effect, there is the problem of the metrics. As Fenton [#!fenton!#] shows, we do not know what to measure, eg. should we measure lines of code in a month for productivity or should we measure centimeters documentation. We also do not know what we measure. What does it say when we write so many lines of code?
As I got the feeling that software engineering is problem solving by humans for humans, and that reuse is problem solving with existing (partial) solutions, I went to cognitive psychology to see whether theories existed on how people solve and should solve problems to base my own method on.
It appeared that several kinds of problems existed, i.e. formal problems and non-formal problems [#!wickelgren79!#], and that software engineering could be classified as solving formal problems. For formal problem solving several theories existed.
Software engineering can be seen as a special form of problem solving. The splitting of the software lice cycle into several steps is the division of a problem into subproblems (a general problem solving method). The use of program plans [#!rist!#,#!littman!#,#!yu!#,#!wiedenbeck!#] can be compared with the schemata [#!mayer!#]. Functional fixedness in programming was proved by [#!mayer75!#].
The human understander is best viewed as an opportunistic processor, capable of exploiting both bottom up and top-down cues as they become available [#!letovsky!#]. This is consistent with the memory model of the schema theory. We see that software engineers do the same. Generally, it is found that software engineers first play with the problem, give partial solutions, go into details, etc. until they feel grip on the problem (a mental problem model is created) [#!guindon!#]. From then on they first give a solution in general terms before they specialize [#!duncker!#].
All these findings supported the idea that conclusions from cognitive psychology can be used in software engineering.
My work gives theories based on cognitive psychology, and from the conclusions drawn a process is derived and necessary characteristics for describing reusable components are derived.
My work has improved the state of the art by giving a process model which is also refined to a method.
My work has improved the state of the practice as HP has used ideas from it in their reuse project, the reuse process model as discussed in former workshops has incorporated several ideas.