Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Gathering SW Indicators

699 views

Published on

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

Published in: Technology
  • Be the first to comment

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>

×