Configuration Management
This section is about classical configuration management which answers "Which version do we have?" not to be confused with configurability.
Configuration management takes place all through the life of a product.
Some people focus on the configuration of a system as it is developed.
Others try to keep track of system configuration once they are shipped.
These are really two sides of the same coin but have never been effectively treated as the same problem.
As systems are developed it is important to keep a trail of the intermediate products built along the way as well as any released products.
One reason to keep intermediate artifacts is that designers sometimes take a wrong path and need to backup and go another direction.
A reason why released product documentation must be preserved is that multiple versions of a product may exist in the field simultaneously.
In order to make design changes to a system that is not the current version requires a comprehensive documentation set.
The question a repairman always asks is; "What is the Model Number?"
This is another way of asking, What is the version number.
Most manufactured systems have many components each with multiple source design documents.
These must each be preserved such that any version of the entire product documentation can be reproduced.
A very disciplined approach is required to keep track of all the combinations of coordinated design documents.
Sometimes not considered is the fact that not only the source documents but the tools used to produce them must be captured.
Recently, in the news it was reported that some very complex military systems are in danger of not being maintainable because the programs required to read the original design documents are no longer available.
In other words even though the source media is available, the tools needed to read them are not.
Configuration or Change Control Board
The configuration of systems during design and manufacture is controlled by a Change Control Board.
This system is partly mechanized with an electronic change control system.
The change control board is responsible for the disposition of reports about system performance.
They determine the relative priority of the problem to the product maker.
They have the ability to commit resources to resolving problems.
Change Control System
The change control board's efforts are dependant on a change control system that allows them to track problems by product release.
Many companies have proprietary change control systems that incorporate all their design artifacts.
For software one of the early standards was the Software Change Control System (SCCS) which is still in use today.
It was followed by the Revision Control System (RCS).
SCCS has been largely replaced by a more recent system called Concurrent Versioning System (CVS) an extension of RCS.
CVS has a GUI that makes windows based development easier.
Some of the concepts important to change control are; the baseline, checkin, checkout, lock, branch, merge, export, import, tag and conflict.
Baseline
A baseline is like a relative foundation.
If a foundation is what secures a building to the ground, a baseline secures a system to some relative point of development.
Its like a foundation in the air or on water.
Consider the lie detector.
It uses Galvanic Skin Response (GSR) to measure the change in skin's resistance to electricity.
As your anxiety goes up, your skin resistance goes down and the lie detector measures it.
Now everyone is different so there is no absolute truth or false in the system but it is calibrated by asking the person being tested, questions, answers to which he is unlikely to lie about.
This establishes a baseline of the persons basic skin resistance.
Now when questions whose answers are unknown to the interviewer are asked, the anxiety level of the interviewee may indicate cognitive dissonance.
Used with other non verbal cues, a trained interviewer can often tell if someone is telling the truth.
So a baseline in this sense is a reference point for future measurements.
The same is true for system baselines.
Each baseline is a reference point to time say when a product is shipped or maybe a hunch that we may have to get back to this point or when a defined set of features are completed.
In any event future changes are added to baselines to which we can return.
Checkin
Change control systems manage the access to a set of design artifacts similar to a librarian.
Once checked out only those having checked out an artifact may change it.
Others are said to be locked out.
Checking in requires that all changes made are reconciled to each other.
This works well if the changes are in different places.
Sometimes two people try to change exactly the same portions of an artifact.
This causes a conflict that must be manually reconciled.
Branch / Merge
Sometimes development must travel down different paths simultaneously.
For example one group fixes immediate problems in the current release of something to be shipped next week while another group makes wholesale changes that may not be put to use for months.
The splitting of something into 2 versions is called a branch.
If later the changes of one version can be implemented in the other a merge occurs where the branches are brought back together.
Back | Next
Copyright Spidel Tech Solutions, Inc. 2004 All Rights Reserved. Updated:
9/27/2008 3:01:31 AM
Idx: 2139 Site Design STS
