Configuration Management Software Resource Center |
|||||
|
|||||
Traditional Configuration Management - checkin/checkout control of sources (and sometimes binaries) and the ability to perform builds (or compiles) of the entities. Other functions may be included as well.
Process Management - control of the software development activities. For example, it might check to ensure that a change request existed and had been approved for fixing and that the associated design, documentation, and review activities have been completed before allowing the code to be "checked in" again.
While process management and control are necessary for a repeatable, optimized development process, a solid configuration management foundation for that process is essential.
Many organizations choose to integrate their problem management and classic configuration management tools to gain better control of their development activities and to improve quality.
This question arises in several forms. Sometimes it is "what are the benefits", but often it is "how can I convince management to use SCM" or "what are/how can I measure the cost savings of implementing SCM". In many cases, it is an indicator of a company looking for a "silver bullet".
First the "bad news": designing and implementing software configuration management will cost in the short-term, it will not be a way to realize short-term savings. These costs will be incurred for design time, tools license fees, equipment costs, user training, and risks of misuse due to unfamiliarity with a new tool or platform or process.
However, the "good news" is that in the long run, that is, over the complete life of a software product, implementing a good SCM process and system which is used correctly by a properly trained development staff will save money by improving quality, reducing problems, and making maintenance and rebuilds of various product vintages more reliable.
Software development is a complex process. Companies enter into SCM practices because they want to be able to control and guide that process as best they can. How much, or how measurable, the cost savings may be will depend upon how well the company has been tracking all actual expenses of development, including debugging, redesign, corrections, etc. over the entire life of the product, not just to expenses to the first release. If they have no such metrics tracking, they are unlikely to see a savings they can recognize (and may even view the implementation of SCM as costing more).
Some of the specific reasons for implementing SCM which have been mentioned over the years include:
Desire to protect their huge investment in software and be able to reproduce a build with the correct components or continue development on a project even if those previously working on it have left the company.
Desire to improve quality and reduce errors caused by building products with the wrong version or some old code which did not include a current fix
Simplification of a complicated build and/or release process.
Desire to streamline processes and let developers worry about actual development.
Reduction of day-to-day labor, thus allowing an under-staffed or over-busy team to produce more useful work.
Facilitation of moving personnel from one project to another with little or no loss of productivity since both projects follow the same process.
Elimination of instances in which software needed to investigate customer-reported problems could not reproduced or rebuilt.
Hiring of new team members (particularly leaders and/or managers) who had good experiences with SCM in prior businesses and advocated such improvements.
Need to perform concurrent development at multiple locations, particularly if that is already being tried and has gotten out of hand.
Improvement of the faith a quality assurance group can have in a new version of a product for which they are responsible, and highlighting of areas where a new product version should be scrutinized during quality assurance.
...over the complete life of a software product, implementing a good SCM process... will save money by improving quality, reducing problems
Regardless of the reason, it is important to recognize that deciding to design a good SCM process and implement such a system is a long-term commitment. The benefits will not be realized overnight. Sufficient time (sometimes over the course of several product cycles) is required before the real benefits can begin to be realized. One error some companies make is to try SCM for a portion of a project, often never really training the developers to use it properly or not allowing them the time to become familiar and comfortable with it, not obtaining adequate hardware to support the new process, or not configuring their systems properly to support the new demands put on them. Then the company abandons the SCM system because of user complaints or, more likely, slippage of the schedule of that first project (even if the initial schedule was underestimated).
The essential elements of a successful implementation of SCM include:
Good planning and design by people experienced in good SCM techniques
Proper and complete education of those who will be following and using the system so that they understand not only how to, but why they must perform certain steps and the benefit to them of doing so
Sufficient time for the users to become familiar and comfortable with the system
Advocacy of the new system by "champions" both in the technical staff and management
Proper equipment and trained support staff to answer questions and solve problems when they arise (or better still, to tend to the continual care of the system so problems are avoided)
A side benefit of implementing a good SCM process is that it will help enable a company to be assessed at a higher SEI Level and/or obtain ISO certification. (Note that these are side benefits, SCM should be approached from the standpoint that it can help you produce better, more reliable products faster, rather than for the purpose of attaining an award or certification.)
more configuration management information