Depending on the source of reference SCM is defined in a multitude of manners , what i have tried to do here is provide a basic understanding of the SCM process and described how exactly we go about doing the same using PVCS from Merant as the automated tool.
Some definitions
Software configuration management is the methodology employed to establish and maintain the integrity of software work products along the system development life cycle. Changes to these software work products are done in a controlled manner eliminating any risk of unwanted changes creeping into the system.
“Configuration management involves the collection and maintenance of data concerning the hardware and software of computer systems that are being used.”
“CM embodies a set of techniques used to help define, communicate and control the evolution of a product or system through its concept, development, implementation and maintenance phases.”
“CM, a key concept in the Information Age, is a set of systematic controls to keep information up to date and accurate.”
“CM identifies in detail the total configuration (i.e. hardware, firmware, software, services and supplies) current at any time in the life cycle of each system to which it is applied, together with any changes or enhancements that are proposed or are in course of being implemented. It provides traceability of changes through the lifecycle of each system and across associated systems or groups of systems. It therefore permits the retrospective reconstruction of a system whenever necessary.”
" The goals of using CM are to ensure the integrity of a product and to make its evolution more manageable. Although there is overhead involved in using CM, it is generally agreed that the consequences of not using CM can lead to many problems and inefficiencies. The overhead of using CM relates to time, resources, and the effects on other aspects of the software lifecycle"
A discipline applying technical and administrative direction and surveillance
to:
identify and document the functional and physical characteristics of CIs; audit the CIs to verify conformance to specifications, interface control documents and other contract
requirements; control changes to CIs and their related documentation; and
record and report information needed to manage CIs effectively, including the status of proposed
changes and the implementation status of approved changes.
Software Configuration Management encompasses the disciplines and techniques of initiating, evaluating and controlling change to software products during and after the software engineering process
"A set of management disciplines within the software engineering process to develop a baseline"
Software Configuration Management (SCM) is the discipline for managing the evolution of computer program products during all stages of development and sustainment.
The definitions can go on and on so lets cut short and go to the next part.
The main features that are answered by SCM is shown diagram form.
Why SCM
The most frustrating problems involved in software development are often caused by poor configuration management or absence of SCM below are a few examples
The latest version of the source code cannot be found
A difficult bug that was fixed with great difficulty suddenly reappears
A fully tested program does not work
You Tested the wrong version of the code!!!
Who overwrote my changes
SCM answers issues like
What is the status of my modules?
What changes have been made to my software?
Does any one else’s change affect my software?
Visibility in status of evolving software product.
Answers who ,what ,when ,why of changes
There is no Trace ability between Software requirements, documentation and Code.
Programmers working on the wrong version of the code.
Wrong version of code has been base lined.
Tracking deliverable issues.
Distributed Development Teams.
Multi platform Development Environs.
Parallel Development .
Some real life scenarios
Scene 1 Software Development Test Lab
Two hours into a four-hour test, you sit stunned in front of your terminal. The display is
frozen_a problem you were sure had been fixed the previous week. What could have
happened?
Scene 2 Monday Morning
You are a software development team leader who has just returned from vacation. In your
absence, one of your key programmers won the lottery and has departed for Tahiti. While
reviewing her notes and the work she left behind, you find that there are still a dozen files
checked out of the file management system in her name, but you don't know why.
Scene 3 The Day Before a Progress Review with the Customer
You are the manager of a software development project. You are gathering status data in preparation for your meeting with the customer. When you ask why a low-priority module has been changed so many times while a module that the customer is interested in has not been started, you discover that one of the engineers has been trying to improve the module by making warning text appear in day-glow orange. Since the customer does not have color monitors, the engineer has wasted valuable time and money making unnecessary changes to the software.
The most frustrating software problems are often caused by poor configuration management:
The latest version of source code cannot be found
A difficult bug that was fixed at great expense suddenly reappears
A developed and tested feature is mysteriously missing
A fully tested program suddenly does not work
The wrong version of the code was tested .
There is no trace ability between the software requirements, documentation and code
Programmers are working on the wrong version of the code
The wrong version of the configuration items is being baselined
No one knows which modules comprise the software system delivered to the customer
Configuration is a term that is commonly used to describe the physical and functional characteristics of a system
Example What is the configuration of your machine? The answer we expect is say 700Mhz Pentium III processor 512mb RAM,20Gb hard disk, Multimedia kit. That's configuration is a method in which we describe certain key features of the item in question.
The sub processes under SCM may be classified as
Configuration Identification.
Configuration Control
Configuration Status Accounting
Configuration Audit
Work Product
Work products may be of two types
a) The deliverables to the clients Ex Executable code, Source code (depending on the type of contract with the client etc.
b) Non Deliverables artifacts used to produce these deliverables in an efficient manner Ex Project plans, QA plans, Design Specifications , Requirement specification documents
Configuration Identification " This is the first step in which the work products that have to be included in the scope of configuration management are identified. What Configuration Identification does is identifies the smallest unit of each work product and assigns a methodology to uniquely address the smallest unit. This may be done by a standard naming system or automated tools can be used for the same. Depending on the environment in which the software is developed or the small units can change.
A thumb rule for the identification of CI's is that any work product that is susceptible to change during the course of the SDLC and whch is directly or indirectly associated with the system outcome is considered as a configurable item CI. CI's may also be a hardware parameter like say the CPU frequency the Bus speed within the system etc. For these parameters are also susceptible to change.
EX The smallest unit may be a . fmb or .fmx if Forms (Developer 2000 is used)
It might be a .asp file in if ASP is used etc. Typically a CI will have a associated unique name and identifier. Nowadays with the advent of modern tools one need not go to the smallest event.
Examples of some of the CI's in a small project are
Documentation (user manuals, system manuals, brochures etc)
Marketing documents (Proposals , contracts, Memorandum of understandings etc)
Requirement analysis documents (Requirement catalogues, specifications)
Design Documents (Design specifications, Functional specifications, Entity Relationship diagrams, Data Flow Diagrams etc)
Testing plans, Test case specifications.
Project Management material (Project plans, SCM plan, SQA plan, Risk Plan ,Testing plans, Implementation plans etc)
Customer Related (Test data, Company logos etc)
Hence it is identified the next step would be to control changes to the identified CI and ensure that no accidental unintended change occurs to the system. This is done by following a "Base lining strategy"
Baselines Baselines are nothing but snap shots of any system or work product which serves as the reference point for the further development or activities. In the sense its a stepping stone using which further development is done.
"A specification or product that has been formally reviewed and agreed to by responsible management that thereafter serves as the basis for further development and can be changed only through formal change control procedures."
EX Before a programmer begins coding he has the baselined DS (design specifications) which he refers when coding. Therefore Design Specification baseline serves as a reference for further development of the system.
In case the DS has not been baselined in other words if the DS keeps on changing , how does the programmer coding?? Therefore a pre meditated status is considered as fit to render the DS as baselined. For this example it might be that when the DS is Peer reviewed, verified by SQA in a series of reviews/or client has approved the design, it is rendered to be baselined and would be considered as reference fro all further development .
Henceforth any changes to the baselined DS would have to be carefully analyzed and carried according to a pre agreed upon change control procedure. This is followed rigorously in most projects to prevent any creep from occurring. Bigger the project gets more important is the concept of Change control practice. It would be discussed in detail in later steps.
Just as DS in the previous example each work product would have its own set of conditions to be followed for it to rendered fit to be baselined. This may vary from organization to organization. The information given here are more applicable to small software projects with minimum interactions with other engineering fields.
This is the next logical step in the SCM activities. Once we have identified what are our configurable items , we define a control policy or procedure describing how we would go about controlling the sanctity of the work products. There are multitude of commercial tools available today, one of them can be selected or even a manual system can be designed. Out of my experience i can recall a project team which was very apprehensive about using a new tool and decided to go for a manual system . Initially everything went hunky dory and then when changes started pouring in from the client side the manual system broke down. The moral i would like to infer is make use of tools when you are allotted for one and two do so earnestly!!
The next question is when do we start placing an configurable item under the auspices of Configuration Control??
Starting too early leads to a lot of Bureaucracy as in a government office and real progress suffers which in today's highly competitive environment increasing the time to market factor.
Starting too late would result in sheer chaos!
Some of these entities must be maintained even after the completion of development and until the software is not phased out from the market. Its like maintaining the spare parts of a particular model of automobile until the automobile is no longer sold by the company. Even after the product is decommissioned there would be a need for support for the existing software which would be still in use at many locations.
The concepts of baseline can be better understood by the figure below.
The table describes a few of the CI and the points at which Configuration control is applied and also the criteria to be satisfied for base lining of these CI's.
| Name of CI | Instant of subjection to config Control *** | Baseline criteria |
| Requirement specifications |
The completion of first draft version. |
Client sign off. This indicates that client has come to an understanding with the development team regarding the Requirements for which the application is limited to.( before client sign off , it would undergo Peer review/Group review, SQA review and feedback incorporated) |
| Design documents | Draft versions | Client sign off ( if any) or after Peer/Group review, SQA review and prior to beginning coding. |
| Project plans | Draft versions | After undergoing Reviews and SQA approval or planning board approval. |
| Code | latest by which a complete versions of the smallest unit of code is ready. | After all levels of testing (unit, system, integration testing etc ) and before implementation or hosting at client site. |
The point at which the CI's are subjected to configuration control and the baseline condition may be different from organization. What i have tried to do is give a brief sketch which is applied at Applitech Solution Ltd which has been my source of bread butter and cake too!! for the past 2 years.
Though in principle everything would be almost the same irrespective which company you would be in. The SCM would be different for other cross engineering disciplines. Ex the missile system development I was talking would have a thorough SCM team which would drill down to the pitch and quality control of the last screw in the missile.
Consider an example of say the US missile program , lets for convenience sake consider one of their popular and exposed missiles, the "Tomahawk cruise missile"
The missile can hit a predetermined target ata maximum distance of 2500km with an error range of 2X2 feet reactangle. To ensure such amount of accuracy extreme precision based engineering has to be done.
TEMPLATES and CHECKLISTS
These templates i have gathered from all round the web and some I myself have authored. However if you need them you can use the same but do not seek appreciation for it!!!.
|
Templates |
Checklists |
|
| Software Configuration Management Plan | ||
| Software Configuration Management Guidelines | ||
| Software Configuration Control | ||
| Software Configuration Status accounting | ||
| Software Configuration audits |
