Resolution: Won't Fix
Affects Version/s: None
Fix Version/s: None
With help of
SONAR-4828, it will be possible to display the old and current full distribution of complexity by functions, classes or classes when activating a differential view.
Specifications for a widget that shows the actual CC curve for any application or different modules or (ideally) different versions of an application or a module vs. an ideal CC curve.
The distribution of CC on new techno as Java or .NET should be the following: 70% (of objects with) low CC, 20% average, 7.5% high and 2.5% very high.
This means that:
. 70% of objects should be egual or below a low CC threshold,
. 20% = or below an average CC threshold,
. 7.5% = or below an high threshold,
. 2.5% = or belown a very high threshold.
Object = method. I have never use this on classes. For new technos, a small quantity of high/very high CC is acceptable but most objects should have a low or average CC.
The 'CC curve - New technogs.jpg' file shows this ideal curve.
The same ideal distribution for Legacy technos should be:
. 12.5% or low and very high CC
. 37.5% on average and high CC
Cobol and ABAP applications usually have most of their complexity in the middle, with an ideal curve as a bell curve (see 'CC curve - Legacy.jpg).
For these technos, object = a program (not a Cobol paragraph).
It is not very important to be able to change/parametrize these parameters as these ideal curves are pretty exact. It might be somewhat useful for client-server technologies (Oracle Forms for example) where the curve is somewhere in the middle of these 2 ones.
However, it is important to be able to change the CC thresholds for the objects. I would not use the same thresholds for a Cobol TP app and a Cobol batch application.
The widget should calculate the distribution of the app according to these different categories, and trace the actual curve against the ideal curve for:
. one or many applications (in a Sonar view for example) or many modules of an unique application
. one or many versions of an unique application or module. See 'CC curve - Example1.jpg'.
Many versions of many modules/apps would not be very useful, probably too difficult to read and interpret.
The benefit of the widget is to visually compare the current state of complexity of an application against the ideal one. As applications grow older, developpers tend to add new functionalities into existing components, instead of creating new ones. So the complexity goes from left (low/average) to right (high/very higt).
This move can be seen in 'CC curve - Example2.jpg' where all average CC Cobol components have disappeared so the bell is reversed.
Another benefit is to be able to visually estimate the age of an application. The 'CC curve evolution.jpg' shows the same movement from left to right for a new techno app, with an increase of average CC components after 3 years, high/very high CC components beginning to 'bump' after 5 years and after 10 years, most of the components are into these categories. These time estimation is based on a frequency of 4 releases a year. Some application may age more rapidly when changed more frequently.
This is the reason why it is very interesting to show these curves for different versions. This is a good visual way to show that an application needs refactoring because it is aging more than it should. Or sometimes to show that a new application is not on the ideal curve, for example because specifications have changed during the project so the 'first' release is in fact the 2nd or the 3rd.
Do not hesitate to ask for any question.