System evolution analysis
This type of analysis lets you investigate the whole system from the outside-in, allowing you to separate the significant layers of the architecture and observe how they evolve in time and how they may depend on each other.
This task actually executes and combines up to five separate reports into a single one, as each report gives a different perspective to the same investigation and, like different pieces of a bigger puzzle, its information is most relevant when incorporated with the others.
- The first report tracks the number of Authors for each layer or subsystem.
- The second report tracks the number of Revisions for each layer or subsystem.
- The third report is similar to the previous one, but it shows the number of Commits for each layer or subsystem.
- The fourth report traces the absolute churn, as number of lines of code added and deleted, again for each layer or subsystem.
- The final report is basically a temporal coupling analysis performed at a higher level of abstraction than the individual module/file, where the data is aggregated for each layer/component of the overall system architecture.
$ gulp system-evolution-analysis [--dateFrom=<dateFrom>] [--dateTo=<dateTo>] [--timeSplit=<timeSplit>] [--layerGroup=<layerGroup>]- The layerGroup parameter is not mandatory (if not present the results will be aggregated for one single layer that is the whole system), however it is very important and you should use it to run different analyses depending how you want to slice your system. See Configuration on how to define different layer groups.
- The timeSplit parameter again determines how to split the time interval into periods of time that are meaningful for the collection of the results.
I suggest you play with the possible values of these parameters in order to understand the effect they have on the analysis and the different learnings you can infer. See Tasks parameters.
The results from the first four reports are represented through typical line charts. It is important to note that the the shorter the chosen time split the more values are plotted in the diagram, therefore the more accurate is the curve interpolation (however this is not necessarily a reason to keep the time split very short). Note that you can use the controls on the left side of the diagram to show and hide a particular curve or a group of curves.
Below is an example of a diagram representing the number of authors.
The following instead are diagrams showing revisions and commits trend.
The chart for the code churn can be very useful to understand how coding effort is distributed across different layers.
Note: pay attention to the different meaning of the Total and Cumulative metric trends. The Total number of the chosen metric (together with Added and Deleted) still refers to the metric value within the time interval determined through the timeSplit parameter. On the other hand, the Cumulative metric is the value accrued (or accumulated) through the entire period of the analysis.
The last diagram is only available when using the layerGroup parameter, and it shows the coupling between the different architectural layers in time through a stacked bar chart.
