There are points in any system development process where you can stop, take a look at what' s been accomplished so far, and make sure that you' ve done things in a qualitative way. We call these stopping places quality checkpoints.
For example, one company I worked for had what they called a "burn doc": a standardized document that walked administrators through the installation of network operating system (NOS) software on new servers. The document was very elaborate, down to making sure the computer' s BIOS was updated with the latest firmware. Administrators following this burn doc were able to uniformly turn out a quality product because they followed highly definitive steps. The administrator still had to know and understand server software, so you didn' t actually detach the level of the knowledge the person had to have from the activity (in other words, the CIO couldn't say, "a trained chimp could do this"), but the process was uniform and generated the same look and feel on all servers. You had a known quantity. There were burn docs for different kinds of servers: web, intranet, file and print, etc.
A quality checkpoint in an IT system that required the burning of new servers would be to ascertain that the administrators had installed the NOS according to a specific burn doc.
In the software development process, a component that most developers overlook if they can at all get away with it is the concept of commenting. Being liberal with comments throughout the code that describe what each code section does can be enormously helpful at software revision time (or troubleshooting time, as the case may be). A quality checkpoint might be that you examine pieces of code that have been developed to ascertain whether the code has been well documented.
Note Most developers include a code comment header in any piece of code they write. The header typically includes the initial author, original date, revision author, revision date, modification comments, purpose, and other relevant information that helps those who work on the code after it has been released to understand what the intent was. (Or sometimes to hunt down and assail the nincompoop who wrote the code in the first place!)
Was this article helpful?