IEEE lRANSACTIONS ON SOFTWARE ENGINFERING. VOL zyxwvu 14. NO zyxwv 8. AUGUST 1988 1116 zyxwvutsrqponmlkji A Synthesis of Software Science Measures and the Cyclomatic Number BINA RAMAMURTHY AND AUSTIN MELTON Abstract-In examining the software science family of software com- plexity measures and the cgclomatic number software complexity mea- sure, one quickly makes the following observations. There are char- acteristics of a program which affect its complexity and which a software science measure can detect and measure but the cyclomatic number cannot, and likewise there are characteristics which the cy- clomatic number can detect and measure but the software science mea- sures cannot. Thus, one would like to define a measure or a family of measures which are sensitive to the software characteristics measured by the software science measures and which are also sensitive to the characteristics measured by the cylomatic number. In this paper we present such a family of measures; these new measures are called weighted measures. zyxwvutsrqpon Index Terms-Control flow, cgclomatic number, software complex- ity, software complexity measure or metric, software science, struc- tured programs. I. INTRODUCTION T has been realized for some time that 1) the software I science family of measures and the cyclomatic number are sensitive to different aspects of software complexity and 2) it would be beneficial if one measure or one family of measures were simultaneously sensitive to the aspects of the complexity which are measured by the software sci- ence measures and the cyclomatic number. Hansen [8] proposed an ordered-pair measure which in the first co- ordinate is a variation of the cyclomatic number and which in the second coordinate is a software science measure. However, as Baker and Zweben [2] pointed out, the an- swers given by Hansen’s measure are not clear if the two coordinates do not say the same thing. Baker and Zweben end their paper by saying that efforts to find a combining measure should continue; they were concerned in partic- ular with finding a measure which would combine the measuring capabilities of the software science effort mea- sure and the cyclomatic number. The measures which we propose do combine the soft- ware science measures and the cyclomatic number. We do not claim that our measures can measure all aspects of complexity. More exactly, we do not claim that if our weighted measures say that program A is better than pro- gram B then it follows that program A is less complex than program B with respect to all aspects of complexity. We Manuscript received February 15. 1986, revised June 30. 1987. B. Ramamurthy is with the Department of Computer Science. State Uni- A. Melton is with the Department of Computing and Information Sci- IEEE Log Number 8822019. venity of New York at Buffalo, Butfalo. NY 14214. ence, Kansas State University, Manhattan. KS 66506. claim only that if our weighted measures say that program A is better than program B then with respect to those as- pects of complexity measured by the software science measures and the cyclomatic number (and within their limits of accuracy) program A is less complex than pro- gram B. In this paper we follow the recommendation of Baker et zyxwvuts al. [ 11, and we use the term software complexity mea- sure instead of software complexity metric. As Baker and his coauthors point out, a metric is a well-defined math- ematical concept, and a software complexity measure is clearly not a (mathematical) metric. A metric is a function which takes two arguments and whose returned value rep- resents a difference between the two arguments. How- ever, a software complexity measure is a function which takes one argument and whose returned value represents a measurement of certain aspects of the single argument. Before we define our weighted measures, we introduce the software science fdmily of measures and the cyclom- atic number. 11. SOFTWARE SCIENCE MEASURES In the early 1970’s, the late Professor Maurice H. Hal- stead and his co-workers at Purdue University developed the software science family of measures. The answers or measurements which these measures produce are deter- mined by various calculations involving the number of operators and the number of operands in a program. The measurements are made for each module, and the mea- surements for a program are the sums of the nieasure- ments for the individual modules. The variables for these measures are: ql = the number of unique operators. q2 = the number of unique operands. NI = the total number of occurrences of all operators. N2 = the total number of occurrences of all operands. Basically, an operator is a built-in function or a symbol or a group of symbols in the code that produces an action, and an operand is basically a constant or a variable. In this paper we work with three software science mea- sures; they are the length, volume, and effort measures. These are defined as follows: length volume effort E = V’/V* N = NI + N2 zyxwv I/ = N * log (7, + q2) (log is assumed to have base 2) 0098-5589/88/0800-1116$01 .OO O 1988 IEEE