What is CM? Software Configuration Management, SCM or CM in simple terms is a process that helps you manage changes in various components of a software product during its life cycle. The CM process is assumed to be easy to implement, but in reality it is one of the most challenging processes to achieve in a software product organization. This is an attempt to share the practical experiences while implementing CM in different software development organizations in India.
The challenge to keep track of “change” which is the only constant factor in the life cycle of a software product, entails managing change. This can be achieved with the help of CM. Many quality gurus, process experts, and project managers that I have worked with have expressed their desire to dispel the complexity of implementing CM in their work place.
One of the critical aspects of CM is that, it is a process remaining active, even after a software product is taken out of operation. In fact, this process may exist long after the product is retired. For example, when you need to re-use the source code of a retired product in one of your current development projects, you would use CM to dig out the appropriate earlier sources. The CM process is also applicable throughout the product life cycle – be it a product under development or under maintenance.
CM in a product development environment
Implementation of CM in a product environment is very different from it’s implementation in a typical project environment. The scope of the CM process in a project environment is limited to the extent of being concerned about the changes that are made, till the project is complete and handed over to the customer. Since you may not be responsible for maintaining what is delivered to the customer, you may not think of implementing a foolproof and long-term CM process in a project environment. So you could take a “short term” view here. But, in a product environment the CM process has to be implemented keeping in mind the need to develop, maintain, and support the product till it is taken out of production. Given the earlier example of reusing a source code, CM has to be alive even after the product is retired. Another key factor in a product development environment is that, the process implemented in one product can be tailored for any new product(s) that may be developed later in the same organization.
To highlight the complexities involved in a large product development environment, let us look at the dimensions involved in developing and supporting a product like Netware Operating System, a Novell product.
Product has to sustain a longlife; initial version of Netware was released in the early-80s;
Multiple versions of product supported at given point of time – currently Netware3.x, 4.x and 5.x are being supported;
Future versions of the product under development;
Millions of customers across the globe using the product;
Various components of the product dependent on each other; change in any of these should not affect the functionality of dependent components; change deployment should not affect the customers’ business even for a short time; need for ability to manage customer-
specific and hardware-specific changes;
n Couple of millions of lines-of-code, thousands of source files and other documents to be managed;
Hundreds of developers involved in maintaining and developing the product across multiple locations in various parts of the world should be able to change the same set of files at the same point of time and synchronize these appropriately.
Implementation of an effective CM system is essential to manage the typical dimensions in a product development environment, that is indicated above.
In my personal experience, having well-defined objectives for CM in an organization is an important pre-requisite to ensure its successful implementation. Besides conventional and mandatory CM objectives like ensuring reproducibility, managing, implementing and reporting changes and so on, specific CM objectives should be defined at an organizational level with the commitment of the senior management. I consider the following to be key CM objectives in a product organization:
Ensuring product integrity: In a product environment, CM is seen as the process that delivers the product to the customer. Hence the CM process must be verified for delivering the desired output by the product team. A check should be made to ensure it meets the customer’s expectations. CM plays a key interface role in this, as explained later.
Improving productivity of
product teams: When you reduce the development cycle-time, you improve the productivity and efficiency of the product team. CM being a process that supports the entire product life-cycle, it can play a crucial role in reducing the product development cycle-time. This can be achieved, by focussing on a well-defined CM organizational structure with sufficient
focus on automation and other processes.
An appropriate CM set up
The objectives, I mentioned above, may seem far-fetched or easily stated than implemented. But I have found that these can be achieved by putting together a well-defined CM organization and process in place.
When you implement CM in a product development environment, the first thing you need to do is to clearly define the role of CM. Based on my experience, this is best defined as an independent function. Often given the man-power resources and the kind of constraints that we have in hiring and retaining personnel in the Indian software industry, we tend to assume that the CM function can be managed by a full-time developer partially playing the CM role.
We may even tend to periodically rotate the role within a team of developers. I have also seen some organizations in India, combining the testing and the CM role-playing. In such cases, what will happen if there are three or four members in a development team? If we follow the above patterns, focus on CM may be lost and we will tend to stop with just meeting mandatory objectives.
My recommendation for CM staffing is to recruit CM specialists as part of an independent function. For this, one has to see the value of the CM role and the potential contribution it can make in improving productivity and cycle-time. Hiring specialists and having a functional group to guide them is fundamental to this strategy. But while adopting this strategy we are likely to face the problem of not being able to hire CM specialists due to low availability in the job market.
Possible Solutions are:
Investments in terms of training for this role;
Hiring a specialist for the CM lead role & ensuring he or she takes up the task of grooming & establishing a CM team;
Typical attributes of an independent CM function are:
Well distinguished from development functions;
Complete integration with the development team for routine needs;
High sensitivity to the needs of the development community-considers them as internal customers or users;
Success factors of CM mapped to product teams’ goals;
Well-defined interfaces with development, testing and so on, leaving no scope for ambiguity.
Some factors of the Manage-ment’s commitment for the role are:
Recognition as a critical Software Engineering role;
Attracting and retaining the best talent
Sensitivity to growth of CM specialists in the organization – career path within and outside CM, after completing a committed duration in CM role.
Implementing the CM process
The key to the success of the CM process is to allow the CM function to define a process for the organization. CM planning is an essential factor and this plan should be a part of the project plan. The CM planning process should ensure that all the dynamic requirements of the development team can be met. There should be enough buffer built into the process to handle all the project needs, whether planned or unplanned.
The CM process should define an effective build process for the
One of the main advantages of having an independent CM function is that the development team can rely on this function for their build requirements.
Based on the needs of the project, any kind of builds – feature test, integration, or system test builds can be supported by the function. In addition to the conventional Change Control procedures, a review of the check-ins prior to the build, by a team comprising the Project Manager, SQA and some key developers has proved to be very effective in practice. This is generally done to ensure that the changes are controlled. This means, the product changes that are needed to go into the build and the dependent changes are checked in, while changes not critical at that point do not go into the build. Such a review process may not be very effective during the initial phases of development, but after reaching some state of stability in the product, such a process may become a necessity.
Some of the advantages of frequent builds in a project are
Early integration of all developed modules;
Early and easy diagnosis of defects; this improves developers’ confidence in the product and in the changes made by them;
The CM process should ensure that the build status and configuration items are periodically updated in a common area, like your internal web page. This is to keep the product team informed and aware of the changes that are happening in the product. In addition to being a source of information, team members may need the information so that they proceed with the testing. Such information available in a common area also helps in resolving dependencies between various modules in the product.
Though the CM process should be tuned towards ensuring complete user satisfaction, the process should also ensure that you do not compromise on ensuring quality of check-ins. In fact, the CM process should ensure that only the reviewed and unit tested, source code, documents and others are considered for the build.
Another key aspect of an effective CM process is that, it should ensure the usage of a Release Checklist before the product goes out of the door. This is to ensure that all the product requirements are met, the product has been tested as per requirements identified in the project plan, all exceptions and known problems are documented, and the actual deliverable has been sanity tested. Even some of the trivial activities such as virus check of the product, communication of check-sum and size of the product, need to find a place in the Release Checklist.
The CM process will also need to identify a disaster recovery procedure. The CM functions as the safe custodian for the product and maintains all the product sources and other critical documents like requirements, design, test cases and plan documents. In case of a disaster, one can imagine what kind of a catastrophe organizations will face, if there is no disaster recovery process in place. Irrespective of whether the organization has such a process or not, the CM function can be proactive in defining a disaster recovery process from the CM perspective. Here we need to remember that whatever CM function keeps in its custody are really organizational assets.
The CM function can act as a facilitator for continuous improvement measures, by ensuring the collection of metrics on build cycle-time, data on change requests or problems fixed, lines of code or documents changed, added and deleted between builds and milestones. I have found such data to be very useful for improving processes and for estimating for future products. To quote one of my experiences where build data really helped – a particular product used to take around five hours to build. By focussing on causes that contributed to delays in builds, the team could build the product in around one hour. The actual effort spent on improving the process was only a couple of person-days but the value-added was tremendous.
Tools, automation and training
Implementing a CM system can be made easy, if a uniform CM tool is used across the product organization. Considering the benefits, organizations should strive to acquire a tool after evaluating various tools available in the market. The usage of multiple CM tools within the same organization will hamper and delay the process of implementing the function to a great extent. Hence, a corporate standard on the CM tool, should be seen as a long-term strategy. If a decision is made and the tool is acquired, deployment of the CM tool in the product teams is better done as a planned exercise. This will ensure that you get the required commitment from the product teams on your plan and schedule for deployment. It is often noted that, if the deployment is not done as a planned exercise, covering the whole organization may remain a distant dream and the tool will be used in isolated pockets, defeating the very purpose of acquiring a good tool.
In addition to deploying a single tool across the organization, enough focus should be provided for automation of all routine CM activities at the project level. This may be done through the usage of scripts and other means.
In practice, it has been seen that CM training is a must for the entire engineering staff including project leads, developers, SQAs, technical writers and others. The reason being that all of them use the CM process and tool in some way or the other during the course of product development. Training is better designed in a modular pattern to cover everybody and it should be well defined for each role. Needless to say, that CM Engineers would undergo all the modules of training. The training program should cover the CM process, CM tool, and automation related areas like scripts.
The challenges CM in India
The concept of software product development for the global market is relatively new to the Indian software industry. Though some organizations are trying to mature into product development companies, we have a tendency to look towards our clients or our parent US organizations to implement processes like CM. We need to resist such tendencies since our needs may be very different from theirs. From my experience, organizations in the US are not necessarily highly process-oriented. Another disadvantage is that we might acquire products that have been developed by our counterparts in the US and these would come with obsolete in-built processes. In a competitive world, we have to live with short product development and release cycles. We may have to work with development teams across different parts of the globe. Organizations working on different kind of products may have varying team sizes. There can be many more such challenges. As many of you would have realized by now, implementing a good CM system can help you face such challenges.
In future, one could see CM as an automated workflow from the stages of planning to release. I am sure that some product organizations are already working towards achieving this goal and have made substantial progress. CM as a process can provide great help in ensuring complete traceability of all software components, for example, requirements to system test cases, and enhancement requests to design. The CM tool can be integrated with other Software Engineering tools like defect tracking tool and change request databases. Some of the state-of-art tools already come with these integrations.
The last word
All the major aspects of CM mentioned in this article, have been through work as CM Lead in Novell Software Development Center in Bangalore. The kind of challenges that we have faced in a complex, large product development and support environment have been very exciting. They have helped us evolve the role into an extremely critical function for the company.
As I mentioned in the beginning, the CM implementation in a product organization is going to be an extremely critical and complex task. But it is not impossible or difficult to achieve. From experience, I would consider the following as critical factors that would go a long way in making the CM function a success:
There needs to be a high degree of committment from the senior management to implement a CM system;
All those involved in CM activities have to be committed and dedicated to the function;
One has to look at CM’s role much beyond build management and support.
While a lot of experience has been shared in this article, you may find that some of the unique environments may require more specific or tailored versions of the recommendations already discussed here.
R BADRI NARAYANAN,
Novell Software Development Center