Software complexity, to me, has something to do with how we perceive a
software system. According to Dr. Brooks's study (1977), computer
programming has three phases, understanding, method-finding, and coding.
Some might agree that method-finding can qualify as a software design
I tend to see a software system as software design plus coding. That is
generating a blueprint and implementing the plan. The boundary is vague and
hard to define. Most software developers, however, would agree they
experience these two cognitive processes during a software design task.
Now back to the software complexity. McCabe and Halstead measure the
complexity from the point of view of the finish product. It measure what
comes in and what comes out. 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.
I am certainly not an expert in this area and would like to hear from others
about this issue.
On Fri, Oct 10, 2008 at 1:02 PM, Ruven E Brooks <[EMAIL PROTECTED]>wrote:
> No one seems to have yet mentioned the work on quantifying software
> complexity such as the McCabe and
> Halstead metrics. There is evidence that these measures have behavioral
> correlates - e.g., modules with
> higher cyclomatic complexity tend to have larger numbers of defects - so
> there is clearly a cognitive
> aspect to software complexity. However, I can't find any work which
> provides an explicity psychological model for
> software complexity which could be used to relate it to more general ideas
> of cognitive complexity.
> Ruven Brooks
Department of Learning & Performance Systems
Pennsylvania State University