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 power plant workers, etc. often tend to have much more tolerance for, enthusiasm about, and experience with complexity than some other folks might. Something to 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 specifics....my focus at the moment is largely on instructional design cognition, but issues of complexity are common to all areas 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, [EMAIL PROTECTED] writes:
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 are 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. We 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 (http://local.mapquest.com/?ncid=emlcntnew00000002)
