Hey CM’ers! Welcome to another fun filled, fact free edition of From the Trenches, the column where we get down in the mud to talk about the basics of Configuration Management and try to avoid any incoming shells. This month we will talk about Software Configuration Management Plans (SCMP’s). What are they? Why do you need one? How do you write one? How can you delegate this task to someone else, anyone else?
I remember the first SCMP that I read. I was new to CM and I felt like I was reading the maintenance procedure for a Chinese tank. It was filled with all these unfamiliar acronyms and was about as interesting as a software license agreement (which I know you all read). However, after going through the process of writing a few, the experience has been well worth it. It has helped me learn a great deal about configuration management and the importance of planning your CM activities. Besides, I get the distinct pleasure of watching others go through a similar experience as they read one of my SCMP’s for the first time. I can tell by the tortured look on their face.
What is an SCMP?
Basically your SCMP is where you record your decisions on how you are going to use configuration management for any given project (in this case, a software project). It should be created in the early phases of the software development lifecycle to define your configuration management process. Writing this document forces you to answer many questions up front on how you will use configuration management, which will help a great deal later on when you are trying to get code out the door. It should answer such questions as what the configuration management tasks are and who will perform them. What is being controlled and how will it be controlled? How will the status of the controlled items be reported? What days of the week does the company cafeteria serve the best soups? And so on. It is also a living document that can change throughout the software lifecycle, but the Change Control Board must approve any changes to it once it goes through its official approval by the group. What’s the Change Control Board and who’s on it? Look in your SCMP! This is another item that should be included.
Why do You Need an SCMP?
I’m sure you’ve heard the old adage “those who fail to plan, plan to fail”. This certainly applies in this case. If you don’t have a plan for configuration management, how do you know that it’s being done correctly, or being done at all? Not having a written plan probably means you are not practicing configuration management at all, or maybe you think it’s being done, but no one on the team even knows what configuration management is. Lack of a plan could also mean that you’ve either “always done it this way” or you subscribe to the “CM Theory of the Month Club”, depending on who’s in charge. Groups without a plan are very likely the same ones who miss deadlines and find previously solved errors creeping back into their builds. If you want to avoid these things, you need to figure out how you are going to do it. The best place to start is your SCMP.
Another good point about the plan is that the act of writing it is just as valuable as the end product. As you write your plan, you are forced to consider situations that have never happened and things that you probably should be doing but are not. For example, is the software library being backed up? Who’s doing it? How often? Has the integrity of the backups been tested? These kinds of items should be addressed by the SCMP.
Who Writes the SCMP?
Your configuration manager typically authors it, although the whole software team should at least participate in reviewing the document. After all, they will be the ones who have to follow the process that is going