Syntax Directed Quality Processes

About Articles How to contact me Projects Site Map

Joseph Koshy > Articles > Humor > Modeling Management > Syntax Directed Quality Processes

Syntax Directed Quality Processes

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?

Formal models

We model our typical project can be modelled using a grammar as in Figure 1.

Grammar Graph
project ::== 

progress_reports ::==
    (status_reports | teleconference_minutes)+
project structure as a graph
Figure 1: Project Structure

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 ::==
design document structure
Figure 2: Design Document Structure

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.

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.

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:

  1. 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 .

  2. 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".

Partial parse on project structure
Figure 3: Partial parse on project structure

Strategies for survival

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.

Last Modified: Sat Apr 21 22:53:24 2007
Site Search Google