Martin and all,
Good points....I shall also pop up from lurking.  In addition to being  
cautious about domain dependence for complexity issues, I think that user  
experience/background can also be an issue. Engineers, programmers, nuclear  
plant workers, etc. often tend to have much more tolerance for, enthusiasm  
about, and experience with complexity than some other folks might.  Something 
keep in mind when testing.
Complex problem solving is an increasingly hot topic these days. Books such  
as Sternberg and Frensch's "Complex Problem Solving: Principles and 
Mechanisms"  (1991, Lawrence Erlbaum Associates) or David Jonassen's "Learning 
to Solve  
Complex Scientific Problems" (2007, Taylor & Francis Group) may be helpful  
to lead to additional reference trails. The IEEE web site is also a good source 
 for information on metrics for software complexity. And there is work on  
design cognition within the field of design studies....including "design  
complexity" for software engineering. 
Sorry I don't have more focus at the moment is largely on  
instructional design cognition, but issues of complexity are common to all 
 of design. The literature tends to be scattered across cognitive science,  
design studies, education to some extent, and all of the engineering  fields....
Sue Rothwell
Ph.D. Candidate, Information Science and Technology
The iSchool at Syracuse University
Syracuse, NY  USA
In a message dated 10/10/2008 2:16:00 P.M. Eastern Daylight Time,  

When  discussing the cognitive process involved in a software, a lot of 
decision  making and evaluation which do not show up in the finishing product 
left  out. Also using the 1040ez and 1040a example, I would be cautious not to 
make  the software complexity problem a test for financial and tax terminology 
 problem because as Adelson and Soloway (1985) said that software design is  
pretty domain dependent.

One paper might be helpful for this problem is  'the structure of ill 
structured problems' by Simon H. published in Artificial  Intelligent in 1973. 
might be able to tackle the software complexity  problem by breaking it down to 
subproblems that are 'well defined' and tackle  them individually. But, as 
others has mentioned, the concept of complexity  also includes the interaction 
between these subproblems which then need to be  looked at.

**************New MapQuest Local shows what's happening at your destination.  
Dining, Movies, Events, News & more. Try it out 

Reply via email to