Gathering SW Indicators

654 views
568 views

Published on

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

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
654
On SlideShare
0
From Embeds
0
Number of Embeds
13
Actions
Shares
0
Downloads
6
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Gathering SW Indicators

  1. 1. Gathering SW Indicators What SW indicators may be gathered from CM & Bug tracking tools by Kiril Serebnik
  2. 2. Overview <ul><li>Quality and reliability of SW indicators sources </li></ul><ul><li>Raw data for indicators </li></ul><ul><li>Indicators formulas </li></ul><ul><li>Summary </li></ul>
  3. 3. Quality and reliability of SW indicators sources <ul><li>From our point of view, we have three major sources to gather information from: </li></ul><ul><li>Source code </li></ul><ul><li>Bug Track system (BT) </li></ul><ul><li>Configuration Management (CM) system </li></ul>
  4. 4. Code <ul><li>Source code itself may be used for gathering indicators </li></ul><ul><li>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. </li></ul><ul><li>May be used for some interesting indicators in conjunction with previous </li></ul>
  5. 5. Bug Tracking <ul><li>Secondary source for data indicators. May show dynamic of major SW projects events only </li></ul><ul><ul><li>Life cycle of major bugs, major features, etc </li></ul></ul><ul><li>May become more reliable with introduction of full CM – BT connectivity feature </li></ul><ul><li>Advantage – stores data required for indicators in explicit way </li></ul>
  6. 6. CM <ul><li>CM comprised to be the major source for any kind of SW indicator – the reason – there is no changes in SW but through CM </li></ul><ul><ul><li>However gathering data from base CM may be sometimes complicated </li></ul></ul><ul><li>Advantage – highly reliable and quality source </li></ul><ul><li>Disadvantage – data stored in implicit way </li></ul>
  7. 7. Overview <ul><li>Quality and reliability of SW indicators sources </li></ul><ul><li>Raw data for indicators </li></ul><ul><li>Indicators formulas </li></ul><ul><li>Summary </li></ul>
  8. 8. … before we start … <ul><li>All data is supposed to be collected once in a period of time (day, week, month), unless other specified </li></ul><ul><li>For most indicators, only dynamic of changes may make sense. </li></ul>
  9. 9. 1. Code raw data <ul><li>1.1 number of lines in the whole code </li></ul><ul><li>1.2 number of SW modules </li></ul><ul><li>1.3 number of lines in a SW module </li></ul><ul><li>1.4 number of working targets/variants </li></ul><ul><li>1.5 number of developers </li></ul>
  10. 10. 2. TB raw data <ul><li>2.1 number of open bugs </li></ul><ul><li>2.2 number of closed bugss </li></ul><ul><li>2.3 Bug’s age </li></ul><ul><li>2.4 number of re-opened bugs </li></ul><ul><li>2.5 number of bugs that were resolved with ‘non-reproducible’ reason </li></ul><ul><li>2.6 number of bugs that were resolved with reason ‘not-a-bug’ </li></ul>
  11. 11. CM raw data <ul><li>3.1 number of not yet merged changes </li></ul><ul><li>3.2 number of merged changes </li></ul><ul><li>3.3 number of releases in each release stream </li></ul><ul><li>3.4 change age </li></ul><ul><li>3.5 time between releases </li></ul>
  12. 12. Overview <ul><li>Quality and reliability of SW indicators sources </li></ul><ul><li>Raw data for indicators </li></ul><ul><li>Indicators formulas </li></ul><ul><li>Summary </li></ul>
  13. 13. Writing pressure <ul><li>Delta number of lines in the whole code </li></ul><ul><li>number of developers </li></ul>when calculated for given period shows average code writing pressure on a developer during this period
  14. 14. Size of Module number of lines in a SW module <ul><ul><ul><li>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 </li></ul></ul></ul><ul><ul><ul><li>In dynamic – when goes up or down – means active development. When stays approximately the same – maintenance or stable state . </li></ul></ul></ul>
  15. 15. Size of target <ul><li>number of lines in the whole code </li></ul><ul><li>number of working targets/variants </li></ul><ul><li>For given moment – size of the target. Use with writing pressure to estimate number of developers for support ‘average’ target </li></ul><ul><li>In dynamic – behavior similar to Module size </li></ul>
  16. 16. Average module <ul><ul><ul><li>If compared with size of module may estimate this module value. </li></ul></ul></ul>number of lines in the whole code number of SW modules
  17. 17. Task ratio <ul><ul><ul><li>For given period shows task ratio. </li></ul></ul></ul><ul><ul><ul><li>When compared to each other shows quality of BT </li></ul></ul></ul><ul><ul><ul><li>In dynamic – working pressure </li></ul></ul></ul>number of open bugs number of closed bugs number of open changes number of closed changes
  18. 18. Amount of work <ul><ul><ul><li>Amount of work – current (for changesets and SCRs) and futures (for SCRs) </li></ul></ul></ul>number of open Bugs number of open changes
  19. 19. Quality of bug tracking <ul><ul><ul><li>If negative shows how many tasks wasn’t registered in bug tracking system </li></ul></ul></ul><ul><ul><ul><li>If positive shows amount of know tasks that not yet treated </li></ul></ul></ul>number of open Bugs - number of open changeset
  20. 20. Average task age <ul><ul><ul><li>Average time to fulfill a task </li></ul></ul></ul><ul><ul><ul><li>In dynamic – when growing a team enters new features development; otherwise – entering debugging </li></ul></ul></ul>average BAUG age average change age
  21. 21. Quality of work <ul><ul><ul><li>Should be as closer to zero as possible </li></ul></ul></ul>number of re-opened Bugs number of closed Bugs
  22. 22. Quality of workers <ul><ul><ul><li>Should be as closer to zero as possible </li></ul></ul></ul>number of non-reproducible Bugs number of closed Bugs
  23. 23. Quality of validation <ul><ul><ul><li>Should be as closer to zero as possible </li></ul></ul></ul>number of ‘not-a-bug’ Bugs number of closed Bugs
  24. 24. Development effort number of lines delta number of closed changesets
  25. 25. Speed of Development <ul><ul><ul><li>In dynamic – shows increasing/decreasing of development speed </li></ul></ul></ul>number of releases
  26. 26. … <ul><li>there may be a lot of others </li></ul>
  27. 27. Overview <ul><li>Quality and reliability of SW indicators sources </li></ul><ul><li>Raw data for indicators </li></ul><ul><li>Indicators formulas </li></ul><ul><li>Summary </li></ul>
  28. 28. Analyzing the results <ul><li>Gathering info and presenting it in is important, but it’s much more important to analyze the results in the right way ! </li></ul>
  29. 29. Advances of the method <ul><li>The process of gathering data and visualizing it may be automated </li></ul><ul><li>You don’t need to run anything – just go and see results </li></ul><ul><li>Data source are reliable by themselves </li></ul><ul><ul><li>There is no way to insert changes, nut only via changeset </li></ul></ul><ul><ul><li>code metrics are always true </li></ul></ul>

×