R/sir/madam
There are some techniques for debugging for the software.
I think, utlimately, that experts work a la Klein concerning this since it is a high validity domain in the sense that the same patterns occurs sufficiently often so that you can learn from them. In essence, the 10000 hours have effect. If I got this right, experts works with one scenario at a time (the most likely given the evidence) and if there is anything that refutes this scenario, then they go to the next scenario. Scenarios can be refined, it is possible to walk back etc. So, I would call this deductive, that is, you try a model or theory at a time and if it fits, then this is what you use until either you are able to locate the fault or, if everything possible is tried, then changed to another theory or model. Note, I use theory in a broad sense here http://misq.org/the-nature-of-theory-in-information-systems.html?SID=07rkdmd364pv3sh0122timssc5.
Beginners and intermediates borrow models and theories from text books, in courses, during experience of actually working with software. Again, I think this is mainly deductive.
The deduction and induction can be studied on state-diagrams which represent mainly application behavior. This is the fastest and simple way of deducting relations. Then in terms of logic based on facts the relations between entities can be introduced. These facts can conform to the system of fact production rules.
This is a common paradigm to represent system as a finite-state diagram. More can be read from Kearns and McNaughton. However, their examples are based on regular languages matching problem. In any case, the diagram can be generalized in the common sense.
Thus, the deduction means refactoring the relational model (represented by diagram) and induction is a methodology of project development. For that purpose there are number of patterns to apply, for instance, in programming, this is known as a design patterns.
- Badges
- Science topic
- Similar topics
- Computer Science and Engineering
- Software