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
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
of design. The literature tends to be scattered across cognitive science,
design studies, education to some extent, and all of the engineering fields....
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
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