1. ## S/W complexity Measurement

How does one measure the complexity of a software product ?
In sizing estimates one does use complexity as one of the factors but I am interested in compelexity mesurement.
Please do also specify if any one has actually used these techniques .

Ramnath

------------------
If you cannot convince them , confuse them
-- The Good Old Murphy

2. ## Re: S/W complexity Measurement

I have used various complexity measurements, usually in relation to working out reliability measurements. Something to keep in mind: the complexity of a given software application is just one branch of software metrics and it is focused very much on direct measurement of certain attributes of that application, size being one of them. The idea, however, is generally to get measures of the structure of the application as opposed to just general counts of overall lines, classes, or functions. Usually you are going to give these metrics as an ordinal number (interval) or as a relative number (ratio). This is so that you can relate the metrics to other metrics.

One measure of this that you have probably heard of is cyclomatic complexity. This is the degree of logical branching within a function and within the application as a whole. It is basically a count of these constructs, regardless of their nature ("while", "for", "if", "goto", case", "gosub", etc). Keep in mind that something like cyclomatic complexity can be very misleading when applied to object-oriented code! Some also use function interface complexity which is basically the number of parameters to a function and the number of function return points. As an example of what "complexity" is looked for, the idea is that functions that have greater than six discrete input parameters can be difficult to use and lead to possible parameter ordering problems - thus complexity. If functions have greater than one return point, you essentially break the single entry/single exit design concept, thus adding to complexity.

The above can also tie in with structural complexity. This really falls right out of the previous two because you have "absolute" structural complexity whicih essentially measures the number of functions or modules and then you have "relative" structural complexity, which is the ratio of function/module linkages to other functions/modules. If you want more complex (although I would maintain somewhat questionable in implementation) metrics, consider something like Halstead's measure. This is a statistical approach that concentrated on the total number of operators and operands in the application logic and then related this directly to development effort. (It is that last part that I find questionable because a lot of people can interpret things a different way in that context.) There is also a form of orthogonal complexity called Munson-Koshgoftaar Complexity. Basically, it is a weighted summation of complexity factors, the factors being: context coupling, control flow, data structures, and size.

Hopefully some of that gives you some ideas. There are, of course, many other measures besides these although I chose to show you the ones that most of the others are derived from. Most other measures you see are basically a variation on the overall theme. Just keep in mind that, in general, complexity is broken up into three distinct areas: internal algorithmic complexity, architectural complexity, and data flow complexity. From these generally flow the other terms you will hear that make up the major divisions: (1) structural complexity, (2) computational complexity, (3) logical complexity, (4) conceptual complexity, and (5) textual complexity.

One more thing to keep in mind and I shall finally end my rambling: complexity metrics in software can be used in a fashion such that you make measures of the (perhaps estimated) time it takes to complete a program. Thus they can relate to effort metrics, like the one I showed you above. (You could also use these for maintainability metrics if you wanted.) You can also use them as the basis for the susceptibility of an application to have defects (due to complexity) and thus you can relate that to the testability measure of the application and thus speak to the effort needed to test the application.

------------------

3. ## Re: S/W complexity Measurement

Hi Jeff,
As you wrote
[b]
"the complexity of a given software application is just one branch of software metrics and it is focused very much on direct measurement of certain attributes
"
[b]
1. I just want to be clear on this .Is it that these attributes like size depend on the complexity ( which I feel) .In what way the focus is trying to be emphasised here ?
Is complexity by itself considered as a factor or only in conjunction with other attributes like size, effort etc

2. Does complexity get judged by the kind of user interface of the application i.e just based on the presentation to the end user ?

Such a practice exists or it is simply called as USABILITY ..

Ramnath

4. ## Re: S/W complexity Measurement

<BLOCKQUOTE><font size="1" face="Verdana, Arial, Helvetica">quote:</font><HR>Originally posted by nath:
1. I just want to be clear on this .Is it that these attributes like size depend on the complexity ( which I feel) .In what way the focus is trying to be emphasised here ?<HR></BLOCKQUOTE>

Size-oriented normalization is where you take the "lines of code" approach which is strictly a measure of size since, by itself, it tells you nothing of complexity. I can have a program that has thirty thousand print statements and while it is a large program, it is not very complex at all. I can have a much smaller program that does nested recursive loops and thus it is much smaller in size, but also much more complex. So size is not a direct correlation to complexity. They are two different focuses. (However, when you are figuring out complexity, you can use size as one attribute since a lot of conditional branching in a larger program is more complex than conditional branching in a smaller program.)

<BLOCKQUOTE><font size="1" face="Verdana, Arial, Helvetica">quote:</font><HR>Is complexity by itself considered as a factor or only in conjunction with other attributes like size, effort etc.<HR></BLOCKQUOTE>

It is in relation to other factors. It can be little else simply because defining it in relation only to itself would not tell you what is complex - only that something is complex. IEEE Standard 729-1983 defines software complexity like this: "The degree of complication of a system or system component, determined by such factors as the number and intricacy of interfaces, the number and intricacy of conditional branches, the degree of nesting, the types of data structures, and other system characteristics." That is not a bad definition overall.

In general, functions (or methods, if you prefer) are the operative level of granularity of complexity analysis. This is even more so the case when you try to move between languages, such as between C and Java and measure what they call relative complexity. So if you are porting an application to another language, even though the application basically stays the same and the logic stays the same, the complexity measure may go up or down due to the nature of the language. Using functions/methods as the basis, however, you keep the measure relatively stable.

The big challenge in software development circles has been making sure that complexity measures do, in fact, correlate to attributes like maintenance times, code defects, development effort, test effort, etc.

<BLOCKQUOTE><font size="1" face="Verdana, Arial, Helvetica">quote:</font><HR>2. Does complexity get judged by the kind of user interface of the application i.e just based on the presentation to the end user ?

Such a practice exists or it is simply called as USABILITY ..
<HR></BLOCKQUOTE>

Usually the user interface aspects apply strictly to usability, like layout as just one example. The notion of complexity more speaks to what is "under the hood", so to speak. In other words, it talks about the source of what makes the application work, irrespective of how that appears in the form of a GUI. Complexity is very much a logic-based measure. Putting it in terms of markup instead of source, think of a very easy Web page that you have seen that allows mouse-overs, dynamic layering, etc. On the surface, the page is very easy to use. However "under the hood" (at the source level), the markup and scripting to make all that work might be quite complex.

In usability complexity measures, of a sort, call fall under what they call preference metrics, which attempt to quantify the subjective evaluations and preferences of users and this often speaks to the "complexity" of the interface. This falls to two key elements in usability: interpretation (understandability) and facility (overall ease of use). Going back to layout, like I mentioned above, there is a measure called layout complexity. This is based on the distribution of sizes and positions of visual objects. According to this metric, a layout is considered "more complex" if there is more variation in the heights and widths of visual objects and in their distances from the edges of the visual interaction context.

Sorry to digress there but I wanted to show you how different these things can be.

------------------

#### Posting Permissions

• You may not post new threads
• You may not post replies
• You may not post attachments
• You may not edit your posts
•

vBulletin Optimisation provided by vB Optimise v2.6.0 Beta 4 (Pro) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.