5.4 SUMMARY

< Day Day Up >

To summarize this chapter, it is based on the assumption that avoidable complexity costs our industry a great deal of money. If we can design avoidable complexity out of our systems before we deliver them to testing groups or, worse, to the end customer, then we will save much of that money. The simple metrics-based techniques offer an opportunity for organizations to start that designing-out process.

You may ask if the models behind these techniques are complete, and the answer would be no. Complexity itself is complex as it operates in at least four dimensions. There is the complexity that results from the way a system's components are connected which we can call coupling complexity. There is the complexity that results from the black-box view of a component, basically how cohesive it is.

Complexity also derives from the white-box level. How does a component do what it is supposed to? We can use Information Flow metrics to model the first two dimensions and McCabe Cyclomatic and Essential Complexity metrics to model the third. None of these models are a totally accurate representation of a complexity dimension.

I have also completely ignored the fourth complexity dimension, data complexity which itself can cause major problems with live systems. Complexity is almost certainly a function of these four variables and there may be others, one candidate being the degree of concurrency in a system. Unfortunately very little work seems to have been done in this area and one can only hope that further research into the different aspects of complexity and how they relate to one another will be undertaken in the near future.

The metrics and the associated techniques in this chapter do not give a total solution to the problem of complexity but they provide a start, and one that does not cost an arm and a leg to take advantage of!

< Day Day Up >