Process Road Map:

Everyone must know where they and their software are in the process at all times. If you like process flowcharts, good - some people prefer narratives and checklists. A useful process road map divides the process into simple steps that are easy to understand and control. Enough detail so that you and everybody else can find their way around, but not so much detail that individuality and creativity are stifled.

Process Control:

"Process control" doesn't imply rigid adherence to minutely detailed activities, and it doesn't mean totalitarianism and suppression of individuality. "Process control" means that there are effective mechanisms by which the participants in the process can learn how to improve those parts of the process with which they are most directly concerned. Process control means feedback, education, and opportunity, aimed at providing a climate in which people can strive to make themselves, their product, and the world better.

Quantification and Metrics:

We're not dealing with art but with engineering, and, therefore, objectivity is a prerequisite to process control. In engineering, quantification is the key to objectivity. In software, metrics are the primary arm of quantification.

Configuration Control:

It means that any instant of time, we can examine the product of our labour (a program, requirements, or test suite, say) and know: who, what, when, where, why, and how. Everything intended to last must be configuration controlled, and anything that isn't just doesn't exist as part of the product.

Requirements:

What are we building? Does everybody know? Does everybody understand the same thing? Documents are a necessity because human memory is too fallible.

Requirements Traceability:

Where did these requirements come from? If, as often happens, requirements change during the course of software development, what other requirements are affected? Traceability means that requirements can be mapped onto software components and vice verse. But don't ask for, or expect, a one-to-one mapping, because software and requirements don't map onto one another that way.

Strategic Mores:

For whom is this software being developed? What do they expect to get out of it, beyond mere utility? Will this software not kill the user? Will it crush the competition? Will it enhance our reputation for quality? Will it make lots of money? Will it be the fastest? There are hundreds of strategic objectives, and management establishes the relative importance of each. Without such guidance (given, it is hoped, in quantitative form), no one can know the true objectives of the design or when those objectives are met.

Requirement validation criteria:

How will we know that a requirement is satisfied? What are the objective satisfaction criteria associated with each and every requirement?

Responsibility:

Who is responsible for what and when.

Exit criteria:

How do we know that a given piece of software is ready to go to the next stage of the development process? What are the tangible, objective signs of completion?

Entry criteria:

How do we know that a given piece of software is ready to be accepted by the next stage of the development process? This is not a redundant specification. A component can be passed to many different stages or be used by many different other components, each of which may have different entry criteria. Typically, the exit criteria for a component are the union of all the entry criteria for that component.

Analysis:

Analysis is the engineering process by which a design evolves that fulfills requirements. It may be wholly intuitive or wholly formal. Intuitive analysis, while often effective, cannot be communicated to others easily and, consequently, some kind of formal, often mathematical, analysis is needed, even if only retroactively.

Design:

That's what its all about, isn't it? Design should precede programming or at least be coincident with it. Engineers first design then build, because it is less risky to do it that way. Design errors are paper errors and much cheaper than welded steel and concrete or congealed code.

Design Validation:

How do we know that a design will work if we haven't designed something like this before? Validating the design is not the same as validating the implementation of the design. Bridges that collapse usually do so because of poor designs that were not validated - rarely because the materials and workmanship was poor. The newer the design, the more important that it be validated prior to construction. Validation is done by models, by prototypes, by design inspection.

Programming:

The act of coding a design and testing it to see that what we built is what we intended to build. The bricklayer checks her courses with a level and the programmer with a test.

Integration:

The whole is far greater than the sum of its parts. Only trivial, toy software has a system complexity equal to the sum of its component complexities. An architect spends as much or more time defining the steps by which his building will be erected as he does on the final form of the building. There is no integration worthy of the name without an integration plan and associated integration tests - whether it is the integration of two low-level subroutines or several hundred quasiautonomous systems.

Testing:

Testing is required whenever people are involved. Testing is a key ingredient to self-esteem and pride in craftsmanship. A machinist who does not check her work with a micrometer is either a thief or a fool. A programmer who depends on the subsequent actions of others to catch his bugs has no pride, except, perhaps, the fleeting pride of cranking out vast quantities of untested and buggy software in a short time.