Software Configuration Management (SCM). (IT News).
Imagine, if you released that same car with tyres which should have failed the quality assurance test, but didn't, because the specification had not been updated Consider the cost implications for all those cars to be repaired or recalled
Software development projects still include basic mistakes because the industry blatantly ignores the importance of configuration management. How many other businesses can you name where people can overwrite each other's work, send out the wrong version of a product to clients, or fix problems that later get re-introduced?
IT is sufficiently established as an industry now for ad-hoc standards of working practice to be unacceptable. It's time we were able to add stamps of quality and approval on software--whether it's for internal development or for external customers--and we can't get that in place without some fundamental changes to IT management practices.
Why is the use of SCM constantly growing?
Today's world of managing and developing software applications within large-scale, multi-platform distributed systems is incomparable to anything that existed in the past. The increasing complexity of the development life cycle of products, multi platforms and the need for rapid deployment, have resulted in the development of a new class of software designed specifically to exploit the available technology and keep track of the myriad of software assets at the component level.
Flexibility and ease of change with complete traceability and maintainability during the whole life cycle of each module or component of software are crucial factors in the battle for time to market and development efficiency. The first factor might imply the use of state-of- the-art technology, creativity and expertise (among other things), the second calls for a sophisticated infrastructure of the development process--namely a suitable Software Configuration Management system.
* Developer: "I can't change this file--it is shared by so many modules ..."
* Team leader: "if only I had the time to re-organise the project tree and files"
* Development manager: "The release won't be ready for at least two weeks. We are still in integration testing"
* "How can we prevent code overwriting?"
* Customer claim: "I can't understand. I've had enough! This is the fifth time I've seen the same bugs in my software"
* Project manager: "Why does it take us two weeks to make the integration each time we want to have a new release?"
* Marketing: "I don't understand why it takes three months to fix a bug and six months to build a new feature!"
If some or all of these problems sound familiar, you are one of many encountering SCM problems.
What is SCM?
According to Ovum Software Evaluation Service it is "A disciplined approach to managing the evolution of software development and maintenance practices and their components as they change over time."
To ensure we use the same terms let's define a more basic CM term--Configuration Item (CI):
"Every item containing data and/or meta-data and having a life cycle (ie. changing during a life span of a project/product) is a Configuration Item."
Now we can describe Configuration Management as the activity set that is meant to control the change or the lifecycle of each CI.
One should keep in mind that the principal goals of SCM are to maximise the productivity of the software engineering process by reducing errors and efforts involved in the software development and modifications.
The IEEE (Institute of Electrical & Electronics Engineers) defines five SCM functions:
* Configuration Identification
* Version Control
* Change Control
* Status Accounting
* Configuration Review & Auditing
Configuration Item Identification
The first step on the SCM activity list must be the identification of all the Configuration Items (CI's) involved or related in the system's operation.
Possible configuration items include design and test documents; source code; specifications; test results; hardware components; baselines; releases; and change requests. The identified configuration items are, in most projects, interrelated and form one or more hierarchical structures (e.g. project tree; system; modules; releases; files; change requests; tasks; bug reports; baselines).
One of the major and most important SCM activities is the version control, which is defined as a combination of procedures and tools for enabling and managing different versions of CI's throughout the whole software development life cycle.
Version Control activities include:
* Check in / check out (control of sources)
* Configuration freeze (labelling)
* Configuration building (the ability to perform builds)
* Promotion / Demotion (moving up and down through the source lifecycle)
It should be emphasised that this activity marked the beginning of the CM era a couple of decades ago!
Emphatically change control is the final goal of all SCM activities. Most of the other activities being the means to reach this goal. The SCM provides ways of controlling and relating the CI's change procedures. It defines the stages comprising a CI's lifecycle, together with the roles and permissions for the CI's transition through the different stages of the defined lifecycle. It normally applies to both bug fixing and new feature creation.
* There are two basic steps to the status reporting
* Record the status of project CI's
* Report the status of project CI's
* The status reporting can be provided automatically by using a CM tool.
Configuration Review & Auditing
The review is focused on the correctness of a CI that has been modified. The audit is focused on the following:
* Physical auditing (usually using different Configuration Reports)
* Functional auditing according to defined relation between different CI's (e.g. requirements, releases, test descriptions, etc)
* CM procedures and processes auditing
In modern SCM, all the activities described above have a single point of control and common repositories. This approach is often called Process Management and most of the CM high- end tools refer to it. One of the characteristic features offered by this class of CM tools is the relation between different CI's lifecycles (e.g. `check-in' of a source file is possible if and only if the associated Software Change Request--SCR, had reached a specific pre-defined stage, like `approved').
What Can Effective CM Do?
Recent studies indicate that SCM reduces the quantity of bugs by thirty to thirty five percent and increases productivity of development by fifty percent. Other benefits include:
* Reduced development life cycle cost and easy maintenance. Increased developer productivity.
* Organised and controlled processes and artefacts of application development and deployment.
* Improved quality and support of the product and consequent customer satisfaction.
* Improved recovery capabilities.
* CI's traceability.
* Support for the definition and implementation of software development environment and process.
* Managed changes to all project components as they move through their development and approval cycles.
* Focused development process management.
* Improved working interactions between multiple developers.
* Improved build management process (especially when parallel development is involved).
Methodology for Implementing CM
Every software development organisation has a CM solution on site (even if it is only a generic, ad-hoc one). However, often this solution does not fit the organisation's business goals. Whenever such a mismatch exists, an upgraded CM solution should be implemented in order to bridge the gap. Usually this upgrade comprises three components: people, processes and automatic tools.
Each component requires a set of related activities and procedures:
Empowerment by collaboration
The five stage model of the implementation process:
* Strategy and tool evaluation (CM concept plan / gap analysis / sanity check).
* CM plan--SCM plan that defines specific development process needs and translates the defined CM concept into a working breakdown structure.
* Pilot project--the CM plan implementation with the chosen CM tool on a characteristic project.
* Full deployment of CM tool.
* CM extended support and maintenance--tool administration, deployment extension, procedures & tool updating, any on-going CM activity.
The implementation approach can be a top-down one (the five stages presented above), optimising time and resources, or a spiral one, based on an evolutionary process: address most urgent challenges, reach a steady state stage, address the next problems, reach a steady state stage, and so on, with each cycle comprising a concise version of the five stage model.
Return on Investment
Not only can a comprehensive CM process improve the quality of the end product, and vastly increase time to market by reducing the development cycles, it can also offer massive return on investment. According to IDC, implementing a CM solution offers productivity gains of between 100 and 1000 percent. Not only does the product pay for itself, the process improvements made are immensely beneficial to the development process as a whole.
There is no good reason for any organisations involved in software development not to invest in CM. The benefits speak for themselves, and the long-term cost is vastly outweighed by massive ROI. www.tescom.com
|Printer friendly Cite/link Email Feedback|
|Publication:||Database and Network Journal|
|Date:||Dec 1, 2002|
|Previous Article:||New `Kudlian Suite'. (Security).|
|Next Article:||What is software architecture? (Database and Network Intelligence).|