|
|
|
|
|
|
|
|
|
|
|
|
|
|
SOFTWARE CONFIGURATION MANAGEMENT
Take hold of your development project with SCM
By Kathy T. Evans-Davis
What happens when you build computer software? In one word: change. In this first article in a series on Software Configuration Management (SCM), we will define SCM, describe how and why its used, and discuss some rules and guidelines that work to produce the best products during the software development process.
What exactly is Software Configuration Management?
In a nutshell, SCM is a system of methods used to control and manage a software development project. The SCM process activities are designed to control change by identifying the likely changing work products, establishing relationships among them, defining mechanisms for managing different versions of these work products, controlling the changes imposed, and auditing and reporting on the changes made.
Various types of work products may be managed or versioned in SCM: documents, software code, design models, etc.
What is the purpose of SCM?
Generally, there are nine goals of effective SCM. Table A describes them.
| Goal |
Description |
| Build management |
managing the process and tools used for builds |
| Configuration control |
controlling the release of a product and its changes |
| Configuration identification |
what code is being produced |
| Defect tracking |
making sure every defect has traceability back to the source |
| Environment management |
managing the hardware and software that host the system |
| Process management |
ensuring adherence to the development process |
| Review |
ensuring completeness and consistency of components |
| Status accounting |
recording and reporting the status of components |
| Teamwork |
facilitating team interactions related to the process |
SCM process concepts
Your project has specific objectives and requirements that will be reflected in the SCM process you implement to manage change. The following are some process concepts vital to any SCM implementation.
Track change packages
Each file in a code line has its own revision history. But each revision is only useful in the context of a set of related files. In order to identify all changed source files, you have to track change packages, which are sets of files related by a logical change.
Track change package propagations
Tracking change packages makes it easier to propagate logical changes from one code line branch to another. But propagating change packages across branches is simply not enough. You must keep track of which change packages have been propagated, which are pending propagation, and which code line branches are probable donors or recipients of propagation.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
-- Advertisement --
Sophisticated Meets Simple For Document Management
Share. Control. Manage.
Documents, emails, and content in the context of how work is done.
Native to Lotus Domino. The User Experience unseen for Lotus Domino.
Do more with less. Really.
See the possibilities Docova unleashes for Lotus Domino. |
-- Advertisement --
Teamstudio Edition 25 has shipped
It's finally here! Now that Teamstudio Edition 25 has shipped, listen to our latest Tool Time audio program to find out what's changed. Updates to all your favorite Teamstudio tools will be discussed.
Plus, you'll get an introduction to Teamstudio Undo (formerly known as Teamstudio Snapper).
Tap here to get started! |
|
|
|
|
|
|
|
|
|
|
