SCM can be viewed as a pyramid, as shown in the above figure.Let's explore each of the six layers, starting at the bottom and working to the top.
Understanding of SCM:
An understanding of SCM is critical to the organization attempting to institute any system of product control. Understanding through training is a key initial goal, as shown in the pyramid. Executives and management must understand both the benefits and the cost of SCM to provide the needed support in its implementation. Software developers must understand the basics of SCM because they are required to use the tool in building their software products. Without a total understanding, a partial implementation of SCM with workarounds and back doors will result in disaster for an SCM system.
SCM Plans and Policies:
Development of an SCM policy for an organization and the subsequent plans for each product developed is crucial to successful SCM implementation. Putting SCM into an organization is a project like any other, requiring resources of time and money. There will be specific deliverables and a timeline against which to perform. The policy for the organization lays out in a clear, concise fashion the expectations that the organizational leadership has for its system. It must lay out the anticipated benefits and the method to measure the performance to those benefits.
SCM Processes:
The specific processes of SCM are documented for all users to recognize. Not all SCM processes need to be used within an organization or on a product. Yet, it is important to have available, in "plain sight," those processes that are used specifically in your organization. This also maps those processes to how they are implemented.
Metrics:
The measures used to show conformance to policy and product plans are important details. These measures show where the organization is along the path to reaping the benefits of SCM.
Tools for SCM :
The tools used to implement SCM are the next-to-last item on the pyramid. For too many managers, this is often the first instead of the fifth stem in SCM—many organizations and projects simply buy a tool, plop it in place, and expect magic. Actually, it makes little sense to pick the tools to use in SCM without having done all the previous work. Putting a tool in place without training, policy, or metrics is an exercise in automating chaos. You will simply have an automated way to turn out the wrong product faster
SCM Configuration Items:
The configuration items (CI) are those "things" that represent internal and external project deliverables. They are the final result of all the work done to implement SCM in your organization.
Along one face of the SCM pyramid is the training plan and its execution. A common management mistake is to arbitrarily drop an SCM requirement on a development organization without a corresponding investment in training. The process of SCM and the tools used in its instantiation are complex in concept and execution, making training a true requirement.
Along another face of the pyramid, we indicate the transition plan to get to an effective SCM implementation. The introduction of configuration management is a project in and of itself, requiring a project plan within the context of the organization. Just like planning for development, plans for improving product quality and reducing development time must be followed to reap the benefits.
SCM is the identification scheme for the software components of a system. It controls changes to the configuration and maintains integrity and traceability of the configuration. Software in this context refers to all deliverables: documentation, test scripts, test data files, code, and so on. Change control is the management of change as one part of the SCM process. Version control is the management of the product versions generated as part of the SCM process. Release control is the transformation of configuration items into a deliverable product. A configuration item (CI) is a standalone part of the product development that is combined with other CIs into a release. Examples of software CIs include design documents, manuals and tutorials, measurement data, program trouble reports, requirements, source code, and test cases.
SCM Is an SEI CMM Level 2 Key Process Area:
At CMM Level 2, an organization moves beyond just getting the job done and into an environment where a software project management process is in place, the organization sets expectations via policies, and projects have disciplined phases and milestones. This level is described as the repeatable level, built upon key process areas of requirements management, software project planning, software project tracking and oversight, software subcontract management, software quality assurance, and software configuration management. The goals for SCM at maturity Level 2 are:
Software configuration management activities are planned.
Selected software work products are identified, controlled, and available.
Changes to identified software work products are controlled.
Affected groups and individuals are informed of the status and content of software baselines.
Questions that assessors might ask include:
Is a mechanism used for controlling changes to the software requirements?
Is a mechanism used for controlling changes to the software design?
Is a mechanism used for controlling changes to the code?
Is a mechanism used for configuration management of the software tools used in the development process?
