The Rationale for Standards


Many of these standards came into being in response to problems brought on, either directly or indirectly, by human nature and the scope of communications (the number of people involved). When there are only a few people involved in an endeavor, communication is relatively easy and the personnel involved can communicate quickly. They can even coin new terms where everyone agrees on the meaning.

As the number of people increase, someone will always be left out, so "training" must occur to teach the new words and the new meanings for old words. New procedures must be explained or shown by example. The rate of communications change either slows down or the population becomes fragmented and misunderstandings occur more and more frequently. The problem becomes even more evident as groups (tribes) separate from one another. Now, the cross-training effectively ceases and the "language drift" between groups increases.

Eventually, disparate groups must reestablish communications. Whose new words will be accepted? Whose new meanings for old words will become the accepted definitions? What if the drift has gone on so long that some of the words are thought to have the same meaning, but are subtly different? This is the state of things today.

Process and Procedural Standards
Now that a group could talk about something, capturing and passing on how to do things became not only possible, but imperative. From how to start a fire or make an atlatl, to how to design the software for a Martian rover, we need to be able to tell others what we have learned and how to do things without them having to discover it on their own. Thus are born both Process and Procedural Standards.

Procedural standards are more tailored to being able to "build" specific existing "products," whereas Process standards are more along the lines of how to derive and build things that have never existed before.For example, there are Process standards that describe how to create new Procedural standards. Neither of these standard types are intended to be cookbooks. It is not uncommon for these types to be merged for "practical" purposes.

At this level, things start to get left out, often deliberately, as too much "unnecessary" detail prevents people from understanding things. There is a reason that Managers only want 1-2 page bullet summaries instead of detailed reports (and yes, I know I am violating that in this article) - they can retain only so much, so it is important to keep it simple.

What this means is that we have to assume a common language and skill set. If either of these lags behind our assumptions, there will be misunderstanding and failures will result. This is one of the major reasons there is no "One Standard to Rule Them All." Every audience comes to the table with different set of backgrounds, skills and biases. Each "standard" is trying to solve a specific set of problems for a specific audience. Expressed another way, this is why we cannot use the same language to describe SCM to a set of realtors as we can to rocket scientists.

Standards Bodies
Over the years, we have gone to great time, trouble and expense to create Standards Bodies whose sole purposes is to document concepts, processes and procedures that reflect the "best" we have learned, or that we think would be a "really good idea." Many (most) of the standards that these bodies produce are intended to be as explicit and unambiguous as possible. They also tend to be targeted towards either larger organizations that can afford the overhead of compliance, or toward products whose development is regulated. And as we all know, every one of these organizations agrees 100% between them - Not!

SCM - Where Do We Stand?
So where do we stand from a CM standpoint? First, are we talking about software CM, hardware CM, systems CM (ITIL) or some other variant of CM? For simplicity's sake, let's assume we are talking about Software CM. Now, are we going to limit this to just Version Control (VC) and Defect/Issue/Enhancement Tracking (DIET), or are we also going to include Build Management? How about Release Management? Are we going to have to also cover any or all of Requirements Management? When in the Software Development Life Cycle (SDLC) are we going to start participating? At which point do we need to become involved in the planning process? It turns out that different standards require SCM participation at different points and levels in the SDLC - and it is beyond the scope of this article to provide either a description of each of the standards or to compare them.

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.