Implementation tasks are those that need to be performed to operate the SCM.
If followed, the tasks below will deliver the following benefits:
· Track all items regardless of status;
· Segregate draft items from approved;
· Establish a clear authority to implement changes to all approved items;
· Establish an audit trail identifying all changes to approved items;
· Control the release of items into controlled environments.
All deliverables that are produced by the project should be registered as soon as they are produced. Many organisations restrict this to technical deliverables, specifications and programs for example. I recommend that all items be registered. The following list is not inclusive but it does list all the major types that should be registered:
· All technical documentation, specification, designs, testing scripts, ... etc.
· All management documentation, plans, roles and responsibilities, memos and minutes.
· All program components, regardless of their classification, in house, third party, technical architecture, ... etc.
Performing the above task retrospectively may be a mammoth task, registering items on an ongoing basis is relatively simple and requires minimal overhead.
Item registration can be performed by the original authors, if a suitable master index is available. Failing that, a central administrative support function may be able to perform this task.
When registering items make sure to identify their status. Those items that do not require any testing or review can be registered as approve. Such items effectively have a null approval process.
A master index of all project deliverables can be used to great benefits. Following are the most important:
· The master index is essentially the register that will enable staff to identify the location of required information. In the absence of a central register, staff will not be able to identify and obtain copies of deliverables without needing to identify the author and then the document. Chasing authors and documents can be a very time consuming process. It once took me over 4 elapsed weeks to track the whereabouts of product evaluation report.
· Registering the deliverables using a suitable database will enable one to estimate the effort required to manage and track all the current and expected deliverables.
· Registering deliverables will encourage staff to identify the storage location of deliverables. What use is it to register items if one does not know where the items are stored. Tracking the location of deliverables will minimise the possibility of loss.
· Registering the status of products will enable one to quantify the effort required to perform approval and review.
· Registering changes will enable one to generate reports that identify the volume of change and the items that undergo most change.
There are basically three ways to register deliverables:
· Manually, using a paper based document index system. This approach is not very useful as it does not allow for easy searching for items and will require additional effort to register the name and location of each deliverable.
· Using an electronic master index. This may be effective at generating reports and at performing ad hoc searches, however one still needs additional effort to register the name and location of each deliverable.
· Using the source control tool. This by far is the most effective way to register items as they are produced. As well as enabling one to search for items, one does not need to document the location of items.
When registering items, one should take a long term view on how the information will be used. My experience is that most people do not register sufficient information. Minimal information includes the following:
· Name;
· Title;
· Description;
· Version number;
· Status;
· A short note on usage.
If one makes use of a source control tool, the following information is generate by the tool at no additional cost or effort:
· Number of revisions;
· Change date for each revision;
· Change author for each revision;
· Last change author;
· Last change date;
This is a rather controversial subject:
· Does one register items before they are produced?
· Does one register items as soon as they are produced?
· Does one register items when they are approved?
· Does one register every change?
· Does one register changes at the end of each day?
The approach to the above varies on the type of deliverable and its life cycle!
Deliverables that take a short duration to produce, up to a week, should be registered as soon they are produced and before they are approved.
Deliverables that take a long period to produce, several weeks, should be registered at predetermined milestones, on the completion of major sections, or when implementing a major change.
Registering every change is wasteful unless the author is able to provide sufficient information for each change to enable effective identification of each registered change.
Registering on the basis of time based milestone, daily , weekly, ...etc. is wasteful as each revision may not correspond to meaningful revision.
The use of the source control tool as a backup utility should be avoided as this tends to clutter the audit trail being documented with meaningless revisions.
As mentioned earlier on, all deliverables should have a defined life cycle and approval is one of the main states.
The status of items should be tracked on an ongoing basis as this is the main milestone at which formal configuration management starts.
The life cycle of each type of deliverable should identify the acceptance criteria.
· Some deliverables will have a null acceptance and approval process, memos for example.
· Some will need to undergo testing or review.
· Some may require several phases of testing.
Having defined the acceptance criteria, the configuration management process should only be concerned that items have actually be through the necessary process.
To simplify the configuration management process and to enable one to employ unskilled staff within the SCM process, the approval of deliverables should be delegated to the project team. Establishing that items have actually met the acceptance criteria should be delegated to the project manager, i.e. the project manager or leader should sign-off an acceptance certificate of one some sort.
Once approved, the team should register the approved items and forward the acceptance certificate to the librarian.
A number of important steps should be performed to assure the accuracy of the approval process. These are listed below:
· The versions that are to enter the approval process should be registered into the source control tool. This will enable one to assign these a unique revision number and a date stamp. Also registering the item before approval will enable one to track the changes to the item resulting from the approval process.
· The items to be registered should be extracted from the source control tool and put through the approval process. Documents will be reviewed or inspected, software will be tested.
· All defects should be registered and assigned a unique reference number. This should take the form of a review reference or test number.
· The items to be corrected should be corrected and then registered into the source control tool. The tool will assign the items a new revision number.
This is another controversial subject. Some organisations define approval as the stage at which the items undergo the approval process. Others view approval as the point at which the approved items are signed off. The distinction is subtle but very important
A business user may participate in the review of a business requirement. The review may identify a number of defects and these may be corrected and checked by the review chairman. At this point the document has undergone the designated approval process. The above deliverable is now approved.
Several weeks or months later, the business user my sign-off the document to indicate that the requirements are correct and accurate.
Applying configuration management at the point of approval will enable one to create an early baseline that is then placed under change control.
Applying configuration management at the point of sign-off may delay the point at which change control is applied and hence may undermine the control applied to the deliverable.
Configuration management should be applied at the earliest possible point. If sign-off is generally delayed, then configuration management should be applied as soon as the deliverable undergoes its approval process.
Project deliverables will be produced over a period of several weeks or months and in ideal situation, deliverables should be approved as soon as they are produced. Once items are approved their status should be incremented to the next value in the status promotion model.
Documents will typically have a model that includes the following:
· In progress: indicating that the deliverable is undergoing development and change.
· Draft: indicating that the item is static having completed its development.
· Approved: indicating that the item has undergone its approval process.
· Signed-off: indicating that the item has been signed-off as being complete.
Software should have a slightly different model:
· In progress: indicating that the deliverable is undergoing development and change.
· Draft: indicating that the item is static having completed its development.
· Unit tested: indicating that the item has been unit tested.
· System tested: indicating that the item has been system tested.
· User tested: indicating that the item has been user tested.
· Production: indicating that the item is live.
The project should aim to promote to approved and unit tested without delay as doing so would enable one to introduce change control into the development process.
The 99% complete syndrome should be avoided, i.e. avoid keeping items in draft status until a few weeks before the end of the stage.
Many organisations delay change control until the start of system testing. Such organisations are missing a golden opportunity to control the configuration of software and documentation.
Change control during system testing is of very limited benefits since it only aims to detect software problems after they have been implemented.
Change control during the development cycle is much more beneficial. Many developers resist applying change control during development stating that the items being controlled are not sufficiently stable and hence over burdening the project. The fact of the matter is that change control is being applied but the process being followed is generally unstructured, uncontrolled and not being measured; when a developer spots a defect in some code or some documentation, this code or documentation is corrected without following a formal process. Hidden amongst all these changes are modifications that may be totally unnecessary or changes that are needed to correct faults due to poor standards, procedures or training.
The overhead of applying change control during development is minimal. Initiating the requests takes minimal effort, documenting the resolution may require additional overhead. The main cost of applying change control during development is that needed to attend the change review boards. These could be held daily, or weekly.
An organised project should need not more than 10 minutes a day to go through new changes to assess their validity.
The benefits of applying change during development are numerous and include;
· Highlight changes due to bad or ineffective standards;
· Highlight changes due to training shortfalls;
· Highlight changes due to unnecessary code tinkering;
· Highlight changes to patch up bad or incomplete design;
· Monitor user requirement changes (requirement creep);
· Enable the project team to acclimatise to working to a formal change control regime before the start of system testing.
To apply change control during development, reduce:
· the volume of required change control documentation;
· the bureaucracy associated with the change control process;
· the level of authority required to authorise and approve changes.
System testing is the stage within the project software life cycle when the volume of changes is likely to increase substantially. It is not uncommon for a project to raise requests of the order of several hundred in the space of a few weeks.
In preparation for system testing make sure that the following is defined and refined:
· The change control process should be reviewed to assess its ability to cope with the high volume of changes;
· Prepare to increase the frequency of change control meetings from its current rate (possibly once a week) to daily;
· Ensure that the change control log is supported with effective reporting features. In an ideal situation the change log should be on a database of some sort by this stage;
· Review the environments and make sure that ownership and security issues are fully defined and implemented;
· Conduct a short audit of the development environment to ensure that all items making up the system are fully identified an itemised. This will need to be migrated into the system testing environment before testing can start.
· Secure completed deliverables and assign them an initial baseline label, “System Test Build 1” for example.
· Ensure that the intermediate build area is operative and supported by the required development and build tools.