Measure It! How to measure quality in (not only) large software projects, OW2con'16, Paris.
1 like229 views
The document discusses the importance of measuring software development metrics and processes to improve productivity and quality. It introduces the Goal-Question-Metric (GQM) approach for defining goals, asking relevant questions, and deriving indicators for assessing metrics related to bug management and resolution. Furthermore, it emphasizes the need for infrastructure and trained professionals in collecting and visualizing data to effectively manage software projects.
Measure It! How to measure quality in (not only) large software projects, OW2con'16, Paris.
- 1. Measure It ! Daniele Gagliardi @dangagliar
- 2. 28 For which of you, desiring to build a tower, does not first sit down and count the cost, whether he has enough to complete it? Luke 14:28
- 3. Gilb’s Law Anything you need to quantify can be measured in some way that is superior to not measuring it at all
- 4. Source: SEI CMU/SEI-2010 How would you measure it ? (concretely)
- 5. GQM Approach ● Define a goal ● Ask a question on how to reach that goal ● Answer with an indicator ● Refine and derive the metric
- 6. GOAL / BENEFIT Question Indicator Algorithm Definition Measuring bugs distribution within project lifecycle, within the effort to solve them It helps on measuring test effectivenss and bus resolution effort In which project phases bugs are originated? In which project phases bugs are solved? Bugs source distribution within project lifecycle Bugs detection distribution within project lifecycle BO = # bugs in project phase X/# total bugs BS = # bugs solvedin project phase X/# total bugs Currently Total number of bugs originated within project phase X Currently Total number of bugs solved within project phase Y GQM examples
- 8. Bugs resolution ratio Bugs detection ratio Average bug resolution time Bugs resolution effectiveness Bugs distribution by severity Bugs distribution by project phases Bugs resolution effort distribution by people Eng corporate metrics (sample)
- 9. Comments density IQ10 – Dead code IQ11 – Essential Complexity IQ12 – Encupsulation violations IQ13 – Class dependencies on its subclasses IQ14 – Cyclomatic complexity IQ16 – Cohesion Eng Customers metrics (sample)
- 10. SLA definition the point of view of the customer Measures, Metrics, KPI are the building blocks
- 11. Nicola Bertazzo, Spago4Q Team Leader at Engineering Group Need for an expert in measures and quality & productivity intelligence
- 12. ✔Infras – boosts production, sources for measures (don’t assemble an infra without Measures in mind) ✔Plan it (processes, measures, etc) - ✔Most of measures should be automated ✔Set it up ✔Configure it (default configuration couldn’t serve you in the best way) ✔Manage it ✔Train people ✔Support people ✔Ask and collect feedbacks (survey, trouble ticketing) : infra evolves with its users The importance of an infrastructure
- 13. Roles of an infrastructure Tools to produce software (sources for measures) Tools to collect measures Tools to visualize
- 14. Plan and Setup the infra Luca Andreatta, Solution Architect at Engineering Group Need for an expert in software development processes and tools
- 15. Measures come automatically from professionals’ work Matteo Massarotto, Senior Developer at Engineering Group Need for trained professionals using right tools in the best way
- 16. Extract data Alessio De Rossi, ETL & DWH Specialist at Engineering Group Need for an expert in ETL and DWH design
- 17. Build your dashbords Giorgia Fineschi, BI Specialist & Spago4Q Consultant at Engineering Group Need for an expert in Business Intelligence and quality data visualisation
- 18. 00 – Feasibility and Contract 01 – Project Management 02 – Project setup 03 – Configuration 04 – Environment setup 05 – Requirements 06 – Design 07 – Implementation 08 – Test 09 – Release 10 – UAT 11 – Sstartup 12 – Production 13 – Peer Reviews 14 – Bugs Management - Coding error - Design error - Missing requirements - Requirement error - Management error - Estimation and planning error - User training error - Infrastructure error - Startup error - Configuration error - Inconsistent Data - Interface error - Documentation error - Contract error Bug type Project phase bug was detected Project phase bug was originated Example : Bug tracking Configuration
- 19. Bugs statistics Distribution of bugs by originating project phase Distribution of bugs by resolution project phase Distribution of bugs resolution effort by originating prj phase
- 20. Impact values: – Very Low: 1 – Low: 2 – Moderate: 3 – High: 4 – Very High: 5 Cost impact Time impact Risk exposure = Impact x probability Example: - Impact High (4), Probability 80% → Exposure = 4 x 0.8 = 3.2 Red zone risks: Impact >= Moderate and Probability >= 80% Example : Risk Management Configuration Probability
- 22. Company production (thanks again, Spago4Q ☺)
- 23. Usage of infra (many thanks, Spago4Q ☺)
- 24. Corporate infra support dashboard (many many thanks, really, Spago4Q ☺)
- 25. Oscar connection (work in progress... ☺) Leveraging experiences coming from OW2 projects, individual members and company members
- 26. Contacts : @dangagliar http://www.spago4q.org Merci de votre attention! Dankon pro via atento! Grazie per la vostra attenzione ! Thanks for Your attention !
- 27. Bibliography ● Spago4Q - www.spago4q.org ● "Peopleware, 2nd edition" Tom Demarco & Timothy Lister – Dorset House Publishing, 1999 ● Gospel of Luke ● Agile Metrics in Action - Christopher W. H. Davis – Manning Publications - 2015 ● https://oscar.ow2.org/ ● Il Processo di Test – Gabriele Ruffatti & Sergio Oltolina, Engineering Group ● Lesson Learned in Software Testing, Cem Kaner, James Bach, Bret Pettichord, John Wiley and Sons, 2002 ● Pragmatic Software Testing, Rex Black, Wiley Publishing, 2007