| Grammar | Graph |
project ::==
requirements_analysis
design_document
progress_reports
test_plans
progress_reports ::==
(status_reports | teleconference_minutes)+
|
|
Syntax Directed Quality Processes |
| About | Articles | How to contact me | Projects | Site Map |
Don't Panic!
If you are confused and bewildered by the jargon behind Software Quality; if the acronyms NCR, VOE, and KPA inspire in you fear and loathing; if you find yourself doing meaningless things at work in the name of Quality; then read on, enlightenment is at hand.
I have had ample experience in surviving quality processes, having lived through an ISO9000 certification in one company and an SEI CMM L5 certification in another. I thus feel qualified to spout drivel on the topic of Quality (with a capital `Q').
The basic axiom behind the quality processes that I have encountered is the belief that:
Axiom 1: checking the correctness of the form of something generally helps to to ensure the correctness of its content.
That doesn't sound terribly unreasonable, but most quality processes I have seen take this axiom a step further.
Axiom 1': checking the correctness of the form of something ensures the correctness of its content.
This is bit like saying that if a C program compiles without errors, it must be correct.
Greenhorn programmers are likely to protest the illogicality of Axiom 1'. What distinguishes the greenhorn from the veteran is the awareness of the zeroth axiom of quality processes:
Axiom 0: Resistance is useless!
[ Da, Da, Da, Dah! ]
But I digress. Back to our example then; under the typical quality process a project is required to do at least some of the following:
Now, you'll agree with me that it is very difficult to check whether someone has actually applied his or her brain. So, the evidence actually checked is of course the presence (or absence) of:
Evidence that the project was actually managed (as opposed to team having had a riotous, drunken ball) comes from having records like:
Here is the key insight: notice that what is being checked is the form of the project and not the content.
Lemma 1: Form is checked, not content.
Proof: The reasoning behind this conclusion is simple. Checking the validity of the content (for example, whether a given design document actually makes any sense) requires the Quality Department to be equal or better at project work than the programming team themselves. If this were true, then they would also be coding away and thus would not be the Quality Department.
To be sure, the form of the project is easy to verify and so this is what actually gets checked by an auditor (Axiom 1' being implied).
Can we then look at a more formal model of Software Quality then?
We model our typical project can be modelled using a grammar as in Figure 1.
| Grammar | Graph |
project ::==
requirements_analysis
design_document
progress_reports
test_plans
progress_reports ::==
(status_reports | teleconference_minutes)+
|
|
Now each of these top-level non-terminals can have a defined syntactic structure of their own. For example, most documents will be mandated to have revisions control numbers, author names, and will also be required for follow certain defined formats. For example:
| Grammar | Graph |
design_document ::==
cover_page
introduction
main_content
references
ending_page
cover_page ::==
project_id
project_title
notice_of_confidentiality
author_info
revision_history
introduction ::==
glossary_of_terms
expected_audience
audience_requirements
typographical_conventions
main_content ::==
(technical_chapter)+
|
|
Well, you get the idea ...
We call projects matching a given grammatical structure to be well-formed.
Quality Processes in different organizations will all be different, of course. When the `Quality Department' or (`Software Engineering Process Group', whatever they call themselves) in your company calls a series of meetings to define the Quality Process you will have to follow, they are in fact attempting to specify the grammar defining a well-formed project.
With this under our belt, let us then look at Quality Audits.
Many programmers fear the audit. This fear is entirely misplaced, in my opinion. Some of your managers may tell you that a Quality Process Auditor is a human being and a friend. They may as well be right, I can't tell. In this document however, we look for simple models for complex phenomena. We treat auditors as finite automata.
Since audits check for form, not content (by Lemma 1), and we have a rigorous definition of well-formedness, the audit process can be modelled as a haphazard, partial parse. If the partial parse succeeds, the auditor moves onto the next hapless team. If not, you get the dreaded NCR (Non-Compliance Report).
Ok, by why is the parse "haphazard" and "partial"? Two reasons:
A full parse would involve going down into details. This is time consuming, so say the least.
Instead from starting the parse from the top-level and going down to the details, Quality Auditors start at random places in the project structure and check if the parse tree is locally correct. This is shown diagrammatically in Figure 3 where the nodes touched by the partial parse are marked in red .
Once Quality Processes come into your work place, the "form, not content" philosophy pervades everywhere, and the auditor also knows this. Thus it sufficient that the auditor appear to be doing an audit, for the purposes of convincing his or her customer (the company management) that all is going well. Thus a partial parse suffices.
Note: this is also why is important for you, dear reader, to appear to be mortally terrified of the audit, even if you couldn't care less. Remember: "form, not content".
Here are a few suggestions for survival.
Note: I'm always interested in collecting more strategies. Please email me if you have a useful Quality Process Survival strategy. I will add it to this list with due credit.
Model the syntactic structure of the Quality Process in your organization. Write a tool that will produce documents with the expected structure for you.
This can be a lot of hard work, but at least its more satisfying than futile railing at fate (see Axiom 0).
Offer the Auditor some minor, sacrificial non-compliances. Eg:- mess up the cover page of your document by leaving out the confidentiality notice. Make this kind of mistake here and there in prominent places.
This works because Auditors are busy people. When they find two or three small errors, they tend to cluck, wag their finger at you and move onto the next project.
Get a life: attend a Buddhist Vipassana course, study the taxonomic classification of the Phylum Nematoda, or (gasp) writeup a web page on Quality Processes :).
| Contact: jkoshy@FreeBSD.org |
|