Gathering SW Indicators

What SW indicators may be gathered from CM & Bug tracking tools

by Kiril Serebnik

2

Overview

Quality and reliability of SW indicators Quality and reliability of SW indicators sourcessources

Raw data for indicators Indicators formulas Summary

3

Quality and reliability of SW indicators sources

From our point of view, we have three major sources to gather information from:

Source code Bug Track system (BT) Configuration Management (CM) system

4

Code

Source code itself may be used for gathering indicators

However these indicators will show dynamic of code metrics (size, number of files, source lines, etc), rather than dynamic of SW Project as a whole.

May be used for some interesting indicators in conjunction with previous

5

Bug Tracking

Secondary source for data indicators. May show dynamic of major SW projects events only– Life cycle of major bugs, major features, etc

May become more reliable with introduction of full CM – BT connectivity feature

Advantage – stores data required for indicators in explicit way

6

CM

CM comprised to be the major source for any kind of SW indicator – the reason – there is no changes in SW but through CM

– However gathering data from base CM may be sometimes complicated

Advantage – highly reliable and quality source Disadvantage – data stored in implicit way

7

Overview

Quality and reliability of SW indicators sources Raw data for indicatorsRaw data for indicators Indicators formulas Summary

8

… before we start …

All data is supposed to be collected once in a period of time (day, week, month), unless other specified

For most indicators, only dynamic of changes may make sense.

9

1. Code raw data

1.1 number of lines in the whole code

1.2 number of SW modules

1.3 number of lines in a SW module

1.4 number of working targets/variants

1.5 number of developers

10

2. TB raw data

2.1 number of open bugs2.2 number of closed bugss2.3 Bug’s age2.4 number of re-opened bugs2.5 number of bugs that were resolved with ‘non-

reproducible’ reason2.6 number of bugs that were resolved with reason

‘not-a-bug’

11

CM raw data

3.1 number of not yet merged changes

3.2 number of merged changes

3.3 number of releases in each release stream

3.4 change age

3.5 time between releases

12

Overview

Quality and reliability of SW indicators sources Raw data for indicators Indicators formulasIndicators formulas Summary

13

Writing pressure

Delta number of lines in the whole code

number of developers

when calculated for given period shows average code writing pressure on a developer during this period

14

number of lines in a SW module number of lines in a SW module

Size of Module

For given moment of time – estimated hardness of support. In conjunction with writing pressure for the same period – estimated number of developers, required for support In dynamic – when goes up or down – means active development. When stays approximately the same – maintenance or stable state.

15

Size of target

number of lines in the whole code

number of working targets/variants

For given moment – size of the target. Use with writing pressure to estimate number of developers for support ‘average’ targetIn dynamic – behavior similar to Module size

16

Average module

If compared with size of module may estimate this module value.

number of lines in the whole codenumber of SW modules

number of lines in the whole codenumber of SW modules

17

Task ratio

For given period shows task ratio.When compared to each other shows quality of BTIn dynamic – working pressure

number of open bugs number of closed bugs

number of open bugs number of closed bugs

number of open changes number of closed changes

number of open changes number of closed changes

18

Amount of work

Amount of work – current (for changesets and SCRs) and futures (for SCRs)

number of open Bugs number of open Bugs

number of open changes number of open changes

19

Quality of bug tracking

If negative shows how many tasks wasn’t registered in bug tracking systemIf positive shows amount of know tasks that not yet treated

number of open Bugs - number of open changeset number of open Bugs - number of open changeset

20

Average task age

Average time to fulfill a taskIn dynamic – when growing a team enters new features development; otherwise – entering debugging

average BAUG ageaverage BAUG age

average change ageaverage change age

21

Quality of work

Should be as closer to zero as possible

number of re-opened Bugsnumber of closed Bugs

number of re-opened Bugsnumber of closed Bugs

22

Quality of workers

Should be as closer to zero as possible

number of non-reproducible Bugsnumber of closed Bugs

number of non-reproducible Bugsnumber of closed Bugs

23

Quality of validation

Should be as closer to zero as possible

number of ‘not-a-bug’ Bugsnumber of closed Bugs

number of ‘not-a-bug’ Bugsnumber of closed Bugs

24

Development effort

number of lines deltanumber of closed changesets

number of lines deltanumber of closed changesets

25

Speed of Development

In dynamic – shows increasing/decreasing of development speed

number of releasesnumber of releases

26

…

there may be a lot of othersthere may be a lot of others

27

Overview

Quality and reliability of SW indicators sources Raw data for indicators Indicators formulas SummarySummary

28

Analyzing the results

Gathering info and presenting it in is important, but it’s much more important to analyze the results in the right way!

29

Advances of the method

The process of gathering data and visualizing it may be automated

You don’t need to run anything – just go and see results

Data source are reliable by themselves– There is no way to insert changes, nut only via

changeset – code metrics are always true