Software Configuration Management Planning

Actually, you are already much too late! Yes, late. Some people are so picky that they recommend you start the SCM planning about the time that the proposal is being written.

Actually, that is already much too late! Yes, late. If you don't know what your SCM program will consist of before you get the Request for Proposal, you are likely to have a poor performance if you really get the job. This paper, then, tells you how to plan and prepare.

SCM requires many things, such as computers (with the right software), training, people, and a knowledge of how to perform. What, you say, can you not just assign any clerk to do it? NO, and there are those who even today persist in thinking that SCM is just entering data into the computer. NOT so.

All of the standards relating to software have some sort of requirement for a SCM plan for the project. The format may be good, but the requirement needs to be faced before then. No standard tells you how to do that. Perhaps that is why SCM is one of the most failed areas in the Software Capability Assessments using the Software Engineering Institute guidance. I will present what I teach in class, but not so long winded.

Hopefully, some individual in your organization is responsible for SCM and determining what it means to all of your projects. While I am a big proponent of a centralized SCM office, that is not required. A person whose job description specifies SCM responsibilities is required to do the function well.

Start with what I call the "General Overall SCM Plan". It is encouraged that you use the format from whatever Standard you are most likely to have required on future contracts. If there is no such standard, pick IEEE Std-828. The person responsible for the SCM program mentioned above writes a general overall plan that defines SCM in your organization according mostly to the format in the standard you choose, and with the assumption that no prior procedures, practices, or experience exist. (Since these are so rare, I assume you don't have such a document. Too bad!) If you have procedures, do not reference them or use them. Define what your Organization wishes the SCM Program to be. This must define what you want your SCM Program to be. The SCM Program is defined by this document. Make sure it is well reviewed by your project/program managers, and the highest level of software development management. If you really want to step outside of the box, have the System Engineering group review it too! Why not have the Software Quality Assurance folk peek at it while you are about coordination? When you reach a consensus (all have had their review, their comments have been heard, and they can each live with the results), this get approved by someone high in the organization management, such as the President, CEO, a General Manager or VP of Engineering. NOW you know what you want to do. Oh, and the SCM plan MAY be a Section of the General Overall Configuration Management Plan for the organization. Now, isn't THAT unique? When writing this plan, it should include any and all processes and activities that might ever be required on a project in this organization, but should make clear what is required for each and every project and what is defined for special cases.

Following the approval of this plan, the same person responsible for the SCM program must review what is in this document and decide what organizational Policies must exist for this program. The norm is one Policy for an Organization (company/division/location or government agency), but I have seen two or three. A Policy is a statement of what must be done, but in a general way. This would include almost no details. It would, for instance, require that every project developing software in the organization to use SCM, to fund it, to coordinate with other functions within the organization (Engineering, Development, Project Management, etc.), to let knowledgeable SCM practitioners include a bid on proposals, to staff it, and any other things considered important in this general overall SCM plan. Next, that (those) policy (ies) need approval. This Policy must be reviewed and updated if one already existed instead of being written, but must correctly reflect this new General Overall SCM Plan.

Now some new work begins. The person responsible for the SCM program must write or modify Organizational Procedures. There must be several of these, covering at least SCM Planning and Plans, SCM Identification, SCM Status Accounting, SCM Control, and SCM Audits. This is, of course, easier if these procedures exist and only need to be changed to reflect what is written in the General Overall SCM Plan and the Policy. I usually recommend that these procedures exist in the organizational procedures manual in the sections where applied, such as in Engineering, Quality Assurance, Development, Program Management and such, since the people in those functional organizations probably won't read procedures in the Configuration Management Section of the Manual. This does not imply that there are not several procedures in the Configuration Management Section, also, because there are. At this level, requirements that go across groups or are the responsibility of more than one functional group must be defined in a lot of detail. Duties here are stated with the responsible persons/groups stated. Or, for instance, the Software Configuration Identification Documentation (essentially the Software Configuration Identification after the project starts) must be written by the Developers and/or Systems Engineering, approved by those assigned to approve it (including SQA?) and controlled by the SCM program. For instance, the membership of a Software Configuration Control Board (by whatever name it is called where you work) must be funded, assigned by the functional group, and responsible for certain tasks. The specific detailed requirements are in these procedures, and you will need time to complete the whole task. Each procedure must fulfill the requirements in some area of the General Overall SCM plan and the Policy. These procedures will define the processes used within the organization. A process is one or more activities to achieve the goal of the plan. This is not a common definition, but it helps with the writing of these procedures. These procedures, as a collection, should define all of the desired needs defined in the General Overall SCM Plan and Policy. If there are parts of the plan or policy that are not covered in the collection of these procedures, then there is more procedure writing required. These procedures must be coordinated, reviewed, and a consensus reached with all of the groups that must work together on a project. Using these, everyone in the Organization is aware what they and all others must do, and the coordination between groups is defined. It is the responsibility of the functional groups in the organization to either have a lower level of procedures in their group or to have work instructions.

What a segue! Now, some person must define each activity with either a SCM office procedure or work instruction. It will take a few years to get this fully completed. At this level, detailed "how to implement" a certain activity is stated. One of these should exist for each activity of any process. An activity may even be contained in more than one process, but only needs defined once. I find that these are best written by a practitioner that really knows how to do the work. One activity, contained in the Software Configuration Identification process would explain how each document is assigned a number, while a different procedure would define how this document is controlled, and yet another procedure would define how changes are proposed and implemented at various life cycle stages for this same document, and a different procedure would define how numbers are assigned to Configuration Items. In my shop, we had an internal office CCB that coordinated the writing of these procedures, but the final approval was not obtained until the "stupid Manager" could take the procedure and do the activity using the procedure without verbal instructions being needed. The author watched what was happening so as to be able to further explain what I needed to achieve satisfactory completion of the activity. Of course, it makes these easier to use if the SCM Office Procedures Manual is organized in some logical way. When these are completed, each should be coordinated with the user of that activity/process before approval. Remember that these procedures will also define activities only used in special circumstances. These SCM Office Procedures/Work Instructions should reference each other and certainly the Organizational Procedures that they implement.

The work is not just in documenting how the work is currently accomplished. These procedures must be looked at to see how to improve them, make them smarter, make them less costly, make them implement changes to the General SCM Plan, and other desired improvements.

A wise SCM Manager will also cause periodic and planned reviews of the General Overall SCM Plan, Policy, Organizational Procedures, and Office Procedures/Work Instructions to keep them current. These reviews need to be scheduled.

Assuming that your SCM Office has these procedures, when a Project comes in, the first task is to create a Project SCM Plan. This is done by assuming all "required" SCM activities are to be implemented, and reviewing the contract, the proposal, and any special Project requirements to see if additional activities are required. Now, review all activities defined to see if a logical and reasonable SCM Project Program really needs all of what you have required. The result should be a documented SCM Plan for the Project that truly says what you will do, who will do it, and how you know it is done. This Plan will reference the Organizational Policy, Organizational Procedures, and Office Procedures, instead of specifically stating each of those steps used in the Project SCM Program, which makes it easy to write and use. Each person assigned any SCM responsibility (SQA?) including the Development Staff must have copies of this Plan.

So, the definition of the Organization's SCM program is contained in documentation with the following Hierarchy:

• The General Overall SCM Plan
• Organizational Policy (ies)
• Organizational Procedures
• SCM Office Procedures/Work Instructions
• The Project SCM Plan

Now, when you get notified that you have a new project, all you must do is to tailor your existing program to properly fit the Project requirements, and your initial planning is done. Of course, there is schedule coordination and other functions that need to be addressed, but that is defined elsewhere.

Dennis E. Nickle, is an experienced manager of Software Engineering, as well as managing Software Quality Assurance and Software Configuration Management at various points of his career. He has worked both Military and commercial standards, serving as Chair of the Defense Software Development Standards Advisory Board, Chair of the IEEE Std. 1074 Guide, working on the working groups of several IEEE standards, and working on many CODSIA task forces for such Mil-Stds as 973, 498, 2167, 2168, and others.  He attended San Antonio I and Orlando II as an industry representative.  Mr. Nickle had processes developed and documented for E-Systems before there was an SEI.  Mr Nickle currently consults on Software Engineering Management, Software Quality Assurance, and Software Configuration Management.  He has worked in Commercial and Military fields, usually special purpose systems, often embedded.

Trackback(0)

TrackBack URI for this entry

Comments (0)

Subscribe to this comment's feed

Write comment

Name

Comment

smaller | bigger

Subscribe via email (registered users only)

Write the displayed characters

Add Comment