This chapter is from the book
This chapter is from the book
This chapter is from the book
SCM Principles
SCM can be viewed as a pyramid, as shown in FIGURE 31–3. Let's explore each of the six layers, starting at the bottom and working to the top. Then we'll look at two other faces of the pyramid—the training plan and the transition plan.
){kind=link}
FIGURE 31–3 The Software Configuration Management Pyramid
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 definitions appear at the end of this chapter. Five of them are covered in part here so that we can begin to use them throughout the chapter.
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
In Chapter 30, "Software Quality Assurance," we discussed the Software Engineering Institute (SEI) Capability Maturity Model (CMM) levels of maturity. At 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?