jMetra Analysis:
Observing LOCC at application level it seems to imply significant growth between the last iteration and the current one. The LOCC data is also supported by direct correlation with Method and Class count data, confirming that this significant growth is most likely not from creating more complex code, but from growth in functionality of the application. Since the application seems to be growing across all three of these metrics in directly proportional to each other over the last iteration it shows that our coding practices have remained consistent between iterations. This is perhaps a good sign that we have conformed and are producing the same quality of output over time, but is not good when considering that refactoring should have decreased the rate of growth of our code. While this might be accounted for by the fact we have doubled the functionality of the application it should be a yellow flag for our efforts.
Further analysis shows that there was in fact a discrepancy among the distribution of growth in each of the three metrics across individual packages. The app package doubled in methods, grew significantly in LOCC, but remained constant in classes. The percent increase of LOCC was smaller than the percent increase in method count per class showing that we were doing a good job of refactoring and implementing only necessary code. The observations on the GUI package were in line with the app package.
Perhaps the most significant contributor to the application level results was the services package which was more than 5x line count (LOCC) of the previous iteration, while only increasing the method count by 3x, and class count by 4x. This is a red flag for development that shows that there might be room for significant refactoring, simplification, and compartmentalization as the line count has grown far more rapidly than the method count per class.
JMT Analysis:
Coupling Between Objects (CBO):
CBO metric allows us to measure Reusability, Maintainability and Complexity. A higher degree of coupling between objects complicates application maintenance because object interconnections and interactions are more complex. Excessive coupling between object classes is detrimental to modular design and prevents reuse. The more independent a class is, the easier it is to reuse it in other applications. The average CBO value for various modules in our project is: 11 for App, 14.33 for GUI, 11.33 for Sevices and 5 for Utils. None of them seem to be that bad. But looking at individual values, two classes seem to have relatively high CBO values namely MainGUI (48) and ServicesApi (28). Traditionally GUI classes and modules always are more complex and coupled due to the very nature of User Interface. Moreover, MainGUI class is the holder of main method, which adds additional coupling because it needs to instantiate all other classes. So the higher value of MainGUI class may be justifiable due to above reasons, but it should still be reviewed to make sure that our reasons for justification hold true for this class. CBO value of ServicesApi class raises a red flag, which should be thoroughly reviewed and split into multiple classes if necessary. SevicesApi CBO value is more than twice the average and there is no good reason to anticipate that additional coupling.
Response for a Class (RFC):
Is to measure Complexity. The larger the number of methods that can be invoked from a class, the greater the complexity of the class. A worst case value for possible responses will assist in appropriate allocation of testing time. ConfigurationInfo (38) and ServicesApi (54) are the two class that have a relatively high RFC. Both these classes need to be reviewed for reasons behind their high RFC values. A special effort should be made to review the ServicesApi class, because it has relatively high CBO and RFC.
Methods per Class (MPC):
ConfigurationInfo class and ServicesApi class have relatively high number of MPC, which contribute for higher RFC.
Fields per Class:
ConfigurationInfo class has relatively high number of FPC.
Overall:
A relative look at the averages show that current averages are about 0 - 10% higher/lower from previous ones, which is not significant. This indicates that consistent coding practices are followed from iteration to iteration. Though averages have not changed, the total number of methods have changed from 81 to 139 and total number of classes have changed from 14 to 19, which could be taken as a measure of new functionality added to the project. However, this measure should further be looked at in conjunction with the increase and variation in lines of code. This comparison helps us to find out where most of the new code is added and no one module or class is made relatively more complex.
Review MainGUI, ConfigurationInfo and ServicesApi classes and make them less complex, if possible.
JMetrics Analysis:
Testing effort focus:
The most complex classes appear to be PeerDiscovery.java, StatusScreen.java, and ServicesApi.java. We should put extra focus on these classes during unit testing.
Refactoring effort focus:
Based on metrics, ServicesApi.java and PeerDiscovery.java are our largest classes. Upon further examination these classes appear to be cohesive and provide related set of services.
Dead code/Unimplemented classes:
MusicProfileListener.java and FileInfoListener.java do not include any code (just a method declaration). We should check whether these classes needed be implemented or removed from the project.
Code Review focus:
During our code review we should pay special attention to the classes with high cyclomatic complexity. Classes with have high cyclomatic complexity have multiple control paths and are susceptible to bugs. The classes that meet this criteria in our project are: PeerDiscovery.java, PrefScreen.java, ServicesApi.java and StatusScreen.java.