SPA Conference session: Agile Specification Quality Control (version 23 Jan)

One-line description:a method for measuring defects (non conformance to standards) of any software document such as requirement or code
 
Session format: Workshop (75 mins) [read about the different session types]
 
Abstract:Content
1. Participants will carry out QC (Inspection) of a 'top level project requirements document,' supplied by participants or by us, if necessary
2. wrt basic rules of intelligibility.
3. We will measure major defect density, and
4. extrapolate results to true density.
5. We will compare results to a give Defect Level
6. for Exit to next process

Objectives
Give participants practical experience in a powerful software project measurement technique, which can drive change, personal improvement, and real conformance to best practices (the standards we use in the QC process here for how to write (Rule) and levels of quality (exit level)

A full description of the process is in:
http://www.gilb.com/tiki-download_file.php?fileId=264
The Paper on Agile SQP as published in Testing Experience 2009, by Tom Gilb
 
Audience background:any attendee interested in software development best practices, especially quality measurement and quality control
 
Benefits of participating:practical understanding of a powerful, but quick and inexpensive, practice for software specification quality measurement and control.
(the process is invented by the leaders of the session)
 
Materials provided:Digital copies of
slides, papers, book chapters, case studies
 
Process:a SQC briefing defines and illustrates the process
1. Rules for specification are defined
2. participants note defects, and
3. report their totals
4. session manager computes real level of defects, and draws conclusions

or alternate view copied from contents above
1. Participants will carry out QC (Inspection) of a 'top level project requirements document,' supplied by participants or by us, if necessary
2. wrt basic rules of intelligibility.
3. We will measure major defect density, and
4. extrapolate results to true density.
5. We will compare results to a give Defect Level
6. for Exit to next process
 
Detailed timetable:75 minutes

1. briefing 10 min. (the requirement spec, the rues, what is a defect?)

2. checking process 20 mins. (participants count defects, classify as major or minor, summarize ready to report total)

3. reporting process 15 mins. (participants report total majors they found)

4. results computation process 15 mins. (QC leader does calculations and extrapolations, Total found by team, density per 300 words, unfound defects, total defects in all, defects remaining if we correct those we found, downstream loss of project time if we do nothing now)

5. conclusions 15 minutes (should the specification exit its process to next user, should it be repaired or totally rewritten?, what are consequences for the project time if whole document is released unchanged?)
 
Outputs:1. reporting process 15 (participants report total majors they found)
results computation process 15 (QC leader does calculations and extrapolations, Total found by team, density per 300 words, unfound defects, total defects in all, defects remaining if we correct those we found, downstream loss of project time if we do nothing now)

2. participants will understand, and be able to repeat a generic measurement process for any software project specification.

 
History:never at SPA or conference, but used in training courses in house usually
 
Presenters
1. Tom Gilb
RPL
2. Kai Gilb 3.