Software Configuration Managementvig.pearsoned.com/samplechapter/0130912972.pdfThis chapter will review SCM plan templates and provide you with a composite SCM plan template for use

1211

SoftwareConfigurationManagement

31

Software engineers usually find coding to be the most satisfying aspect of their job. This iseasy to understand because programming is a challenging, creative activity requiring extensivetechnical skills. It can mean getting to “play” with state-of-the-art tools, and it providesalmost instant gratification in the form of immediate feedback. Programming is the develop-ment task that most readily comes to mind when the profession of software engineering ismentioned.

That said, seasoned engineers and project managers realize that programmers are part of alarger team. All of the integral tasks, such as quality assurance and verification and validation,are behind-the-scenes activities necessary to turn standalone software into a useful and usablecommodity. Software configuration management (SCM) falls into this category—it can’tachieve star status, like the latest “killer app,” but it is essential to project success. The smartsoftware project manager highly values the individuals and tools that provide this service.

This chapter will answer the following questions about software configuration management.

4834_CH31i.fm Page 1211 Thursday, December 27, 2001 4:02 PM

Prentice Hall PTR

This is a sample chapter of Quality Software Project Management ISBN: 0-13-091297-2 For the full text, visit http://www.phptr.com ©2002 Pearson Education. All Rights Reserved.

1212

C

HAPTER

31

◗

S

OFTWARE

C

ONFIGURATION

M

ANAGEMENT

What Is Software Configuration Management? ________

Software configuration management (SCM) is the organization of the components of a soft-ware system so that they fit together in a working order, never out of synch with each other.Those who have studied the best way to manage the configuration of software parts havemore elegant responses.

Roger Pressman says that SCM is a “set of activities designed to control change by identify-ing the work products that are likely to change, establishing relationships among them,defining mechanisms for managing different versions of these work products, controlling thechanges imposed, and auditing and reporting on the changes made.”

1

We think that Pressman’s description is a better description because we often view SCMas meaning software

change

management.

Wayne Babich describes SCM as “the art of identifying, organizing, and controlling modi-fications to the software being built by a programming team. It maximizes productivity byminimizing mistakes.”

2

The Software Engineering Institute says that it is necessary to establish and maintain theintegrity of the products of the software project throughout the software life cycle. Activitiesnecessary to accomplish this include identifying configuration items/units, systematicallycontrolling changes, and maintaining the integrity and the traceability of the configurationthroughout the software life cycle.

Military standards view

configuration

as the functional and/or physical characteristics ofhardware/software as set forth in technical documentation and archives in a product. Inidentifying the items that need to be configured, we must remember that all project artifactsare candidates—documents, graphical models, prototypes, code, and any internal or externaldeliverable that can undergo change. In SW PM terminology, a configuration item might be aproposal/estimate or bid, project plan, risk management plan, quality assurance plan, CMplan itself, test plan, system requirements specification, system design document, reviewmetric, code, test result, tool (editors, compilers, CASE), and so on. There are basic objectsand aggregate objects to be configured. The number of relationships among them reflects thecomplexity of the configuration task.

Why Is SCM Important? ____________________________

Software project managers pay attention to the planning and execution of configurationmanagement, an integral task, because it facilitates the ability to communicate status of docu-ments and code as well as changes that have been made to them. High-quality released softwarehas been tested and used, making it a reusable asset and saving development costs. Reused


How Can Software Configuration Be Implemented in Your Organization? 1213

components aren’t free, though—they require integration into new products, a difficult taskwithout knowing exactly what they are and where they are.

CM enhances the ability to provide maintenance support necessary once the software isdeployed. If software didn’t change, maintenance wouldn’t exist. Of course, changes dooccur. The National Institute of Standards and Technology (NIST) says that software will bechanged to adapt, perfect, or correct it. Pressman points out that new business, new customerneeds, reorganizations, and budgetary or scheduling constraints may lead to software revision.

CM works for the project and the organization in other ways as well. It helps to eliminateconfusion, chaos, double maintenance, the shared data problem, and the simultaneousupdate problem, to name but a few issues to be discussed in this chapter.

Who Is Involved in SCM? ___________________________

Virtually everyone on a software project is affected by SCM. From the framers of the projectplan to the final tester, we rely on it to tell us how to find the object with the latest changes.During development, when iterations are informal and frequent, little needs to be knownabout a change except what it is, who did it, and where it is. In deployment and baselining,changes must be prioritized, and the impact of a change upon all customers must be considered.A change control board (CCB) is the governing body for modifications after implementation.

How Can Software Configuration BeImplemented in Your Organization?__________________

We used to say, “Make a plan and stick with it—never waffle,” and “Requirements must befrozen—how else will we know what to code?” Now, we say, “Plans are living documents—they will be in a continual state of change as project knowledge increases.” We now knowthat requirements are never frozen—they merge, morph, and evolve and become expanded,enhanced, and extended. As long as artifacts of software development can undergo change,we will need some method of managing the change.

Because SCM is such a key tool in improving the quality of delivered products, understand-ing it and how to implement it in your organization and on your projects is a critical successfactor. This chapter will review SCM plan templates and provide you with a composite SCMplan template for use in any of your projects. We will cover the issues and basics for a soundsoftware project CM system, including these:

• SCM principles

• The four basic requirements for an SCM system


1214

C

HAPTER

31

◗

S

OFTWARE

C

ONFIGURATION

M

ANAGEMENT

• Planning and organizing for SCM • SCM tools • Benefits of SCM • Path to SCM implementation

The concept of configuration is analogous to a bill of materials to assemble any product.Think of the product of an SCM as a system parts list, as in Figure 31–1.

Unlike hardware, software is not physical (tangible), is more complex, is easier to change,propagates change effects, and is data as well as logic.

Where We Are in the ProductDevelopment Life Cycle ____________________________

SCM is an integral task, beginning early in the life cycle. Required from the beginning of thesystem exploration phase, the project software configuration management system must beavailable for the remainder of the project. Figure 31–2 illustrates the “when” of SCM on ourfull product development life cycle.

Chapter 31 Relation to the 34 Competencies __________

Software configuration management falls within competency 8, selecting methods and tools,a product development technique. Project managers’ application of sound software develop-ment methods, techniques, and tools coupled with project management practices, determinesorganizational success or failure. A critical method in this success is formalized configurationmanagement.

Parts List3D Graphics Accelerator—1SCSI Host Adapter—1Network Interface Card—132X CR-ROM—1Tape Backup Unit—132 MB SIMMs—2

FIGURE 31–1SCM Is a “Software Parts List”


Chapter 31 Relation to the 34 Competencies 1215

ConceptExploration

SystemExploration

Requirements

Design

Implementation

Installation

Maintenance

Operationsand Support

Retirement

• Statement of Need

• System Interface Specification

• Software Requirements Specification

• Software Design Description

• Software Validation/ Verification Plan

• Software Validation/ Verification Report

• User Documentation

• Maintenance Documentation

• Archive Report• Software Configuration Management Plan

• Configuration Identification Scheme

Plan Configuration Management

Develop Configuration Identification Scheme

Perform Configuration Control

Perform Status Accounting

• Change Status

• Status Reports

Software ConfigurationManagement

FIGURE 31–2Configuration Management Occurs Throughout the Product Development Life Cycle


1216

C

HAPTER

31

◗

S

OFTWARE

C

ONFIGURATION

M

ANAGEMENT

Learning Objectives for Chapter 31 __________________

Upon completion of this chapter, readers will be able to perform the following:

• Describe sound software development methods, techniques, and tools coupled withproject management practices;

• Apply configuration management tools that support these five areas contributing to softwareproduct quality:

– Design and code inspections,

– Formal design methods,

– Configuration management tools,

– Testing methods, and

– Prototyping and modern languages;

• Define configuration management processes for use throughout the product developmentlife cycle phases of any organization;

• Evaluate commercial off-the-shelf configuration management and change control tools foruse within software development projects.

SCM Principles ____________________________________

SCM can be viewed as a pyramid, as shown in Figure 31–3. Let’s explore each of the six lay-ers, starting at the bottom and working to the top. Then we’ll look at two other faces of thepyramid—the training plan and the transition plan.

Understanding of SCM

An understanding of SCM is critical to the organization attempting to institute any system ofproduct 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 providethe needed support in its implementation. Software developers must understand the basicsof SCM because they are required to use the tool in building their software products. Withouta total understanding, a partial implementation of SCM with workarounds and back doorswill 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 productdeveloped is crucial to successful SCM implementation. Putting SCM into an organization is


SCM Principles 1217

a project like any other, requiring resources of time and money. There will be specific deliver-ables and a timeline against which to perform. The policy for the organization lays out in aclear, concise fashion the expectations that the organizational leadership has for its system. Itmust lay out the anticipated benefits and the method to measure the performance to thosebenefits.

SCM Processes

The specific processes of SCM are documented for all users to recognize. Not all SCM processesneed 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 alsomaps 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 manymanagers, this is often the first instead of the fifth stem in SCM—many organizations and

CI

Tools

Measures(Metrics)

SCM Processes

SCM Plan (Policy)

Understanding of SCM

Tran

sitio

n P

lan

Training

FIGURE 31–3The Software Configuration Management Pyramid


1218

C

HAPTER

31

◗

S

OFTWARE

C

ONFIGURATION

M

ANAGEMENT

projects simply buy a tool, plop it in place, and expect magic. Actually, it makes little sense topick the tools to use in SCM without having done all the previous work. Putting a tool inplace without training, policy, or metrics is an exercise in automating chaos. You will simplyhave 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 deliv-erables. 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 commonmanagement mistake is to arbitrarily drop an SCM requirement on a development organizationwithout a corresponding investment in training. The process of SCM and the tools used in itsinstantiation 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 effectiveSCM implementation. The introduction of configuration management is a project in and ofitself, requiring a project plan within the context of the organization. Just like planning fordevelopment, plans for improving product quality and reducing development time must befollowed to reap the benefits.

SCM definitions appear at the end of this chapter. Five of them are covered in part here sothat we can begin to use them throughout the chapter.

SCM is the identification scheme for the software components of a system. It controlschanges 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 pro-cess.

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 withother CIs into a release. Examples of software CIs include design documents, manuals and tuto-rials, 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 organizationmoves beyond just getting the job done and into an environment where a software projectmanagement process is in place, the organization sets expectations via policies, and projectshave disciplined phases and milestones. This level is described as the repeatable level, builtupon key process areas of requirements management, software project planning, softwareproject tracking and oversight, software subcontract management, software quality assur-ance, and software configuration management. The goals for SCM at maturity Level 2 are:


The Four Basic Requirements for an SCM System 1219

• 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 thedevelopment process?

The Four Basic Requirements for an SCM System _____

Identification, control, audit, and status accounting are the four basic requirements for a soft-ware configuration management system. These requirements must be satisfied regardless ofthe amount of automation within the SCM process. All four may be satisfied by an SCM tool,a tool set, or a combination of automated and manual procedures.

1. Identification

—Each software part is labeled so that it can be identified. Furthermore,there will be different versions of the software parts as they evolve over time, so a versionor revision number will be associated with the part. The key is to be able to identify anyand all artifacts that compose a released configuration item. Think of this as a bill ofmaterials for all the components in your automobile. When the manufacturer realizesthat there has been a problem with parking brakes purchased from a subcontractor, itneeds to know all the automobile models using that version of the parking brake. It isthe same with software. If we are building a multimedia system that has audio MPEG3drivers for Windows 98, Windows 2000, Windows CE, Linux, and FreeBSD operatingsystems, how do we find out which releases are impacted when we find an error in theLinux product? You must go back to your SCM system to identify all the common compo-nents in all operating system releases that are impacted.

2. Control

—In the context of configuration management, “control” means that proposedchanges to a CI are reviewed and, if approved, incorporated into the software configura-tion. The goal is to make informed decisions and to acknowledge the repercussionsassociated with a change to the system. These changes may impact budgets, schedules,and associated changes to other components. If a problem is reported in a releasedproduct, software engineers must act quickly to evaluate repercussions—a “fix” for oneclient’s version of the product may be dangerous to another. The control inherent in anSCM system shows each version in which the flawed component appears.


1220

C

HAPTER

31

◗

S

OFTWARE

C

ONFIGURATION

M

ANAGEMENT

3. Auditing

—Auditing an SCM system means that approved requested changes haveindeed been implemented. The audits allow managers to determine whether softwareevolution is proceeding both logically and in conformance with requirements for thesoftware. The SCM system should document changes, versions, and release informationfor all components of each configuration item. When such documentation is in place,auditing becomes a straightforward analysis task.

4. Status accounting

—Reports and documentation produced by the status accountingfunction are the auditable entries. All approved parts of a software configuration mustbe accounted for, and the software parts list must reflect the transition from part CIn toCIn+1. This accounting provides the historic information to determine both what hap-pened and when on the software project. Status accounting enables the auditingrequirement of the SCM. As a project manager, the status accounting holds a wealth ofinformation on the amount of effort required throughout the life cycle of the product in itsdevelopment and maintenance. This is critical to the software project manager in makingestimates for new systems based on historic information. The SCM can be used as one ofthe key components of the project managers’ metrics system.

Planning and Organizing for SCM ___________________

When planning for SCM in your product development organization, you must first understandthe classes of potential problems that can exist. Once the classes are understood, the inherentproblems that are causing configuration management issues may be easily identified.

Potential SCM Problem Classes

1. Multiple developer syndrome

—When you have a project that requires more than onedeveloper, there is the problem with multiple people working on one product base. Thiscould be a test plan, requirements specification, or code. Effort is wasted when two ormore people work on the same file and then save it. Without SCM control, the last personto save the file has those changes saved. All the other changes are lost. The simplisticmethod of locking a file while one person reads it prevents others from simultaneouslyworking on the file.

2. Multiple releases

—Enhancements to the base product should result in additionalreleases of the product containing the latest changes. Once the second release is available,some users are on an earlier release. Having an SCM makes managing those releases pos-sible. When bugs are reported, changes must be made across all impacted releases. Asnew features become available in the product, they must be made available to all currentusers, no matter what the release date.


Planning and Organizing for SCM 1221

3. Product family

—As products are built that offer the same capabilities across a heteroge-neous set of hardware platforms, both the common and the platform-specific softwarebases must be managed. If a product operates on four versions of Windows, three versionsof Unix, Red Hat Linux, and FreeBSD the user manual may be significantly the same.But there is a different installation process for all nine platforms. Without SCM, nineindividual manuals must be written and maintained. With SCM, one documentationconfiguration item with nine versions will suffice, with the differences being only theinstallation procedure.

4. Requirements change

—The first law of systems engineering is that no matter where weare in the system life cycle, the system/software will change, and the desire to change itwill persist throughout the life cycle. Dealing with this change represents a major manage-ment challenge. Having an SCM in place will ease the management of these changes tothe requirements of the products that will occur. An SCM allows the easy identificationof feature sets that group the requirements satisfied by a release or version of the product.These feature sets are tracked through development to delivery.

5. Schedule change

—As requirements change, so must the schedule. Mapping the featuresets for release to the schedule allows project managers to more accurately estimate theeffort required for generating that next release. Having the SCM in place allows theproject manager to look at historic effort levels in getting out releases. This is an enormousaid in estimating the “what if” scenarios that result from taking on new product users orproviding customized solutions to other clients.

6. Software changes

—No product developer has the luxury to write code once and forgetabout it. Along with requirements and schedules, the software being developed changesin response to those other changes. Software is not static. That is its inherent power. It

can

be changed, so it will be changed. SCM systems track those changes so that, if thewrong change is made, a previous working version is available. This capability alonehas saved enormous amounts of time as developers have tried out specific solutionsthat did not work in the product environment and were able to rapidly back up to aworking version.

7. Staff changes

—In the best of organizations, people get promoted, take other jobs, andleave. When that happens in the midst of a development project, not just the technologyknowledge goes out the door. The long-learned knowledge of how things are done isalso gone. So when a replacement person is brought on board, they may know the technol-ogy, but without a documented SCM process, they will have no real idea how to doproduct development. SCM provides the framework and knowledge base of what hasgone on before in the project. A new staff member has one place to go to understand the“how” of the organization’s development process and the “what” of the project to date.

8. System/user documentation change

—No product developer has the luxury to producein a technology or tool vacuum. All product developers use hardware microcode, operat-ing systems, tools, and documentation that are not under their control. When a major


1222

C

HAPTER

31

◗

S

OFTWARE

C

ONFIGURATION

M

ANAGEMENT

operating system change occurs (e.g., the next “best” release of Windows), an SCM willallow tracing all the CIs, components, and subcomponents that are impacted by thatchange. The change is isolated, and the amount of effort required to respond to the changecan be estimated. This provides a responsible schedule for an upgrade based on situationsbeyond the organization’s control.

A template that may be used in the creation of a software configuration management plan(SCMP) appears in Appendix F, “Project Artifact Templates.” It includes management issues(organization, responsibility, etc.), SCM activities (configuration item identification, changecontrol, status accounting, audit, and reviews), tools, techniques and methods, supplier control,and standards collection and retention.

SCM Staffing

On any given project, a few engineers or developers specialize in and become your SCMexperts. While they are the gurus, everyone on your project will be a user of the product thatthey select, develop, and maintain. It is better to have a few highly experienced people than alarge number of inexperienced people. These experienced few must be able to see congruencebetween software products and perceive what is missing from a software product.

We can group the characteristics and abilities needed by the four SCM functions: identifica-tion, control, auditing, and status accounting.

Identification

1.

Ability to see partitions

2.

Ability to see relationships

3.

Some technical ability

4.

System engineering orientation

5.

Programming

Control

1.

Ability to evaluate benefits versus cost

2.

System viewpoint (balance of technical/managerial, user/buyer/seller)

3.

An appreciation of what is involved in engineering a software change

Auditing

1.

Extreme attention to detail

2. Ability to see congruence

3. Ability to perceive what is missing

4. Extensive experience with technical aspects of system engineering or software engineering


SCM Tools 1223

Status Accounting

1. Ability to take notes and record data

2. Ability to organize data

3. Some technical familiarity

4. System engineering orientation

5. Programming

Once the staffing of the SCM function is complete and the overall organization’s SCM policyis established, the configuration control board (CCB) is identified. The CCB is the heart of thecontrol function. It infuses sustained visibility into the process of change throughout the systemlife cycle and traceability into the process of change. The membership in the CCB is not limitedto the developers or product line management. All stakeholders in the product must be repre-sented. This includes the end-user usually represented by marketing, subcontractors used inthe product development, product development funders, and the product developers. TheCCB is the final decision maker as to what bug fixes, enhancements, and feature sets getincluded in the next product release.

The CCB has periodic meetings, with the results documented. These meetings can be donein a rapid fashion, and doing them online or via email is an adequate way to gain consensusand come to a decision. Important to status accounting is the documentation of CCB meetingminutes. The basic purpose of the minutes is to provide the CCB decision makers with theinformation needed to make intelligent, informed decisions. The amount of detail varieswith the meeting frequency and technical content.

SCM Tools ________________________________________

The minimum features for SCM tools are closely related to the task of handling the differentproduct deliverables produced within the project software engineering process. Tool require-ments and selection criteria are based on a series of features that provide a consistent lookand feel with state-of-the-art software development environments. An SCM tool must havemultiuser support, an intuitive graphical user interface, conformity to the organization’sdevelopment environment, scalability, flexibility in integrating other software developmenttools, ease of setup, modifiable models, process management, extensive support for thedevelopment phase, and management of nondevelopment objects.

Basic selection criteria includes the following:

• Multiuser support—Tools are to be used concurrently by several users. They have to storeall acquired information in a central, shared repository, and the SCM tool has to allow con-trolled parallel work on the different project documents.


1224 CHAPTER 31 ◗ SOFTWARE CONFIGURATION MANAGEMENT

• Intuitive GUI—Because the tools will be used throughout the project and not only bydevelopers, an intuitive, easy-to-use graphical user interface is considered very important.

• Conformity to the organization’s development environment—The organization mustdefine up front the hardware and software development platforms used. For example, theproject may work on a heterogeneous network of Unix-based workstations (mainly SunSparc stations) and PCs. The workstations may be used for some part of the developmentand as a file server and communication server. The PCs may be using MS Windows 2000NT. PCs and workstations may be interconnected using the NFS protocol (especially SunPC-NFSpro on the PCs). The tool has to be able to store its shared repositories on a work-station and has to allow PC clients as well as workstation clients supporting the operatingsystems and protocols.

• Scalability—The tool should work equally well for smaller projects as for larger ones.

• Flexibility in integrating other software development tools—The tool must allow the inte-gration of all the other development tools to provide a highly homogeneous environment.Especially the tools for design, implementation, and testing will have to co-operate on thecommon SCM repository.

• Ease of setup—The SCM tool should allow an easy installation and setup, and should beable to run nearly “out of the box.” It should contain predefined, immediately usable modelsdescribing the types of items, the life cycle, and the roles of the different users. The impor-tance of existing projects and their directory structures should be made as easy as possible.

• Modifiable models—Though a working set of models should be predefined, each of theseshould be modifiable and extensible. This is especially important because project managersand developers want to adapt these models to the software development process asdefined for the company. Role models must be adapted to the roles assigned to the differentemployees on the project. Object-type models must be extensible to reflect different typesof objects used in the environment and especially with respect to nondevelopment objects.

• Process management—Process management comprises efficient support of object lifecycles and object promotion, together with a flexible and extensible approach to life cyclemodels. Based on a concept of object types, it should be possible to attach different lifecycles to different types of objects.

• Extensive support for the development phase—During development when checkout andupdate of objects is frequent, the tool should aid a developer in determining the set ofobjects that need an update or renewed check-in. Although this requirement seems to betrivial at first, the latest version of the tool you plan to use must be evaluated with emphasison the environment prior to the first build. These do a good job in change managementonce the first release has been produced.

• Management of nondevelopment objects—SCM tools must manage all artifacts of theproject, not just code. These will mainly be documents and their versions and releases.The tool must be able to support that.


SCM Tools 1225

• Permission management—Everyone should not have access to make changes to differentpieces of the software. In many situations, check-in and checkout only will not preventintegration from being broken by multiple people modifying code for their own designsand interfaces.

Many configuration management tools in the market promise to fulfill more or less all of therequirements. Chapter 24, “Use of Tools,” presented a general model for the selection of tools tosupport software development and project management. The keys to any tool selection areto know your project’s tool requirements, to understand how tools relate to the project’s successfactors, and to do a current market search for tools. The following is an example of using thattool selection method for an SCM tool. This is simply an example, and it must be updatedwith individual key project success factors, tool requirements, and the tools available in themarket based on the project’s schedule requirements.

A quick search of the market in SCM tools provided the list of potential candidates for thetool as shown in Table 31–1.

TABLE 31–1 SCM Tools

Name of ToolDescription and

CompanyInternet Address

AllChange 2000 SE IntaSoft www.intasoft.net/

CCC/Harvest, CCC/Manager, CCC QuikTrak

Computer Associates (formerly Platinum)

ca.com/products/ccm/

ClearCase Rational (formerly PureAtria)

www.rational.com/products/clearcase

CMVC, now VisualAge Team Connection

Configuration Management and Version Control, IBM

www-4.ibm.com/software/ad/teamcon/

Continuus Continuus www.continuus.com/

eChange Man Serena www.serena.com/html/echange.htm

Enabler aqua Softlab www.softlab.com/technology/frm_tech00.asp

Endevor Computer Associates www.cai.com/products/endevor_ws.htm

Perforce Perforce Software www.perforce.com/

(Continues)


PVCS MERANT (formed by a combination of MicroFocus and Intersolv)

www.merant.com/products/pvcs/

PVCS Dimensions MERANT (formerly PCMS Dimensions from SQL Software)

www.merant.com/products/pvcs/www.pvcs.synergex.com/

Razor Visible Software

RCE (VRCE) Revision Control Engine (Visual RCE) DuraSoft GmbH

wwwipd.ira.uka.de/~RCE/

Sablime Lucent Technologies www.bell-labs.com/project/sablime/

SCCS Source Code Control System

Comes with most Unix distributions.

SCLM Software Configuration Library Manager, IBM

booksrv2.raleigh.ibm.com/

SCM Source Code Manager, UniPress Software, Inc.

www.unipress.com/cat/scm.html

SoftBench HP www.devresource.hp.com/softbench/sb_description.html

Source Integrity MKS www.mks.com/products/scm/si/

StarTeam StarBase www.starbase.com/products/starteam/

TeamSite Interwoven www.interwoven.com

TRUEchange McCabe and Associates www.mccabe.com/products/truechange.htm

TurnOver Soft Landing Systems www.softlanding.com/turnover.html

Visual Age TeamConnection

IBM www-4.ibm.com/software/ad/teamcon/

Visual Enabler Soft Lab www.softlabna.com/pages/espages/visenable.htm

Visual Source Safe Microsoft Corp. (PC) / Metrowerks (Macintosh)

www.microsoft.com/ssafe/

TABLE 31–1 (Continued)SCM Tools

Name of ToolDescription and

CompanyInternet Address


SCM Tools 1227

From the list, four were picked as possible commercial products that would meet theproject’s requirements:

1. PCMS is an established product with strong all-round capability to manage the develop-ment of complex software projects over a wide range of platforms. Based on informationin the public domain, PCMS has shown the greatest level of product development.

2. ClearCase is the dominant commercial SCM-tool in Unix development environmentsand is rapidly moving into NT client/server market development environments. It hasachieved this principally by providing developers with transparent tools supporting theirwork environment and culture. The introduction of ClearTrack extends the all-aroundcapability of the tool set by supporting the management and documentation of changes.After the recent liaison between Rational Software Corporation and Atria Software, Inc.,an interesting merge of features between the object-oriented design tool Rational Roseand ClearCase may be expected.

3. Continuus/CM toolset is characterized by a strong embedded support for process, andits breadth of SCM coverage. The task-based process model is an intuitive approach to themanagement of change. Distributed development via direct links or over the Internet issimple to set up and operate. However, working across low-grade communication net-works is difficult to set up and administer.

4. PVCS is the market-leading system for software configuration management by numberssold. It is simple to use and has stood the test of time. Intersolv has gradually added func-tionality to Version Manager with associated products such as Tracker, ConfigurationBuilder, and Gateway, and by integrating PVCS with many third-party tools.

Following an example from SEI, we formed a ranking system for comparing the tools (Figure31–4). Table 31–2 shows the rating for the considered tools.

The result of this first ranking allows one of the potential tools, PVCS, to be dropped. Thiswould then leave three for the project manager and tool evaluation team to take a more in-depth look. Note that there has been no discussion of price at this time. Once the technicaldecision has been made, the cost decision should follow. Do not introduce price early in theevaluation. If there is discomfort with the technical capabilities and life cycle coverage of atool, adding in a cost variable will only further confuse the decision. Many software projecttools become less desirable after full life cycle cost is analyzed and estimated. Make the techni-cal decision first.

As a final note on tools, working strictly in a Microsoft development environment withMicrosoft tools working under Visual InterDev, Visual Source Safe (VSS) is included as anintegral part of the tool suite. VSS is an adequate SCM tool for small commercial productdevelopment that is strictly targeted to Microsoft platforms. If you’re developing onMicrosoft platforms and have delivery targets on Linux or Unix, investigate the use ofWinCVS. WinCVS is a shareware package that is very capable in providing large-project,multiplatform SCM. It compares favorably with most and betters some commercial SCM tools.



Benefits of SCM Process and Tools ___________________

SCM benefits an organization in four areas: control, management, cost savings, and quality(Figure 31–5). These four benefits are mapped to an organization’s overall goals and objectiveswhen the decisions are made to bring a SCM tool in-house. The features of a SCM tool furthersupport these benefits.

CRITERIA

Ease of Use

Completeness

Tailorability

Consistency

Correctness

Life Cycle Connection

IEEE

3

2

3

3

3

1

NASA

1

1

1

3

1

1

DoD

1

0

1

3

1

1

RATING KEY

0 = Does not satisfy minimum requirements1 = Satisfies requirements for average standard2 = Satisfies requirements for good standard3 = Satisfies requirements for excellent standard

Ranking CM Plans

These three standards were compared using six criteria. They were: ease of use, completeness, tailorability, consistency, correctness, and life cycle connection. The rating of the three standards is shown in the matrix above. The rating system used was 0–3. A standard received a score of 0 if it did not meet the minimum attributes for a criterion, a score of 1 if it met the minimum attributes, a score of 2 if it met the attributes associated with a good standard, and a score of 3 if it met the attributes associated with an excellent standard.

FIGURE 31–4SEI Template for Ranking CM PlansSource: SEI, from Configuration Management Plans: The Beginning to your CM Solution.


Benefits of SCM Process and Tools 1229

TABLE 31–2Comparison of Four Commercial SCM Tools

PCMS ClearCaseContinuus/

CMPVCS

Multiuser support 4 3 3 2

Intuitive GUI 3 4 3 3

Environment conformity 3 4 4 4

Scalability 4 4 4 2

Flexibility in integrating other software development tools

2 3 1 3

Ease of setup 3 3 3 4

Modifiable models 4 3 4 3

Process management 4 2 4 2

Development phase support 4 4 4 3

Nondevelopment objects 4 4 4 4

Total 36 35 34 30

These values are used to indicate ratings: 5 = Excellent; 4 = Good; 3 = Fair, 2 = Unsatisfactory; 1 = Unknown

Control

CostSavings

ManagementQuality

FIGURE 31–5SCM Benefits the Organization in Four Major Ways



Control Control in SCM provides the ability to review, approve, and incorporate changes into a config-uration item. There must be one controlling SCM tool so that there is only one set of training,license management, installation, and user procedures. All project personnel use the tool.Inherent in the tool is a standardized, measurable process for change. Integrity maintenanceof CIs is enforced throughout the product life cycle. The tool permits only controlled changeto the baseline CIs, and all changes are tracked.

Management Management in SCM is concerned with the automation of identifying and guiding configu-ration items through their life cycle to final assembly as part of product and delivery. Identi-fication of CIs through a unique naming convention allows version, release, update, and fullchange tracking. Baselining of CIs with the ability to produce product deltas from the baselinesatisfies requirement and schedule changes along with product family support. Rapidreviews and audits of CIs are accomplished through the analysis of historic information col-lected. Project status reporting is accomplished in a clear and consistent format based onSCM collected information on all CIs under configuration management.

Cost Savings Cost savings are realized across the entire product development life cycle with SCM. Main-taining product integrity through defined, tracked, and audited CIs provides a managed billof materials for the product released to customers. Cost savings scale with SCM use andapplication across applications. This scaling is dependent on the depth of control needed foreach application product release tree. Deep combinations for product families can be analyzedfor risk exposure and cost savings directly impacted by the amount of configuration manage-ment applied. Side effects are reduced through controlled change by understanding theimpact on all versions and releases. Accurate and repeatable release control is produced in arepeatable fashion over entire product families for all customers and users.

Quality Software development is a people-intensive activity, and quality must be considered at everyperson-to-tool interface. Ensuring a high-quality work environment must address the processof building software products in an automated fashion. This must include tracking CIs to thetools that produced them and the clients that ultimately receive the product. Measuring theend product to ensure high quality is done through tracking the changes made to a productthroughout its life cycle. Repeatable management and change control in a documented andmeasured fashion allows accurate estimation of future efforts. Quality is an ongoing process.The lessons learned in one product must be transferred to new, related products and entireproduct families.


Some Problems with Software 1231

Some Problems with Software ______________________

Software development has traditionally suffered from producing end products with a definitelack of inherent quality. The symptoms of this quality lack are listed here:

• Software development projects are often delivered late and over budget. • Often the delivered product does not meet customer requirements and is never used. • Software products simply do not work right.

As we look into the symptoms of our software development malaise, five principal issuesrelated to software development arise.

Lack of Visibility Software is conceptual in nature. Unlike a bridge, a building, or another physical structure, itis not easy to look at software and assess how close it is to completion. Without strong projectmanagement, “software is 90% complete 90% of the time.” Through the adoption of SCMpolicy and the definition of the configuration management model of the software underdevelopment, all CIs, components, and subcomponents are immediately visible for versions,releases, and product families.

Lack of Control Because software is inherently intangible, it is also more difficult to control. Without an accurateassessment of progress, schedules slip and budgets are overrun. It is hard to assess what hasbeen accomplished and what remains to be done. SCM provides the mechanism for controllingthe project through measuring the amount of effort compared to the project managementplan and estimating the future effort based on past work.

Lack of Traceability A lack of linkage between project events contributes to project failures. The main benefit ofSCM is providing the traceability among versions, releases, and product families. The valueof this traceability is enormous when a problem arises in one release or product family thatimpacts other client releases and products. Making one change and promoting that throughthe entire product software base is an incredible cost savings in time, money, and client goodwill. A lack of linkage between project events contributes to project failures where solvingone problem either exacerbates a problem in another area or fails to fix the same problemelsewhere. A traceability thread allows management to examine the chain of events thatcaused a project to encounter difficulty as an integral process within the auditing capabilityof SCM. A project becomes a year late one day at a time unless the effort reported on theschedule maps to the actual work being done and traced within the software configurationmanagement system.



Lack of Monitoring Without traceability and visibility, monitoring of software development projects becomesextremely difficult. Management cannot make informed decisions, and thus schedules slipfurther and costs continue to exceed budget.

There is no way to monitor a project when the project manager has no tools to look intothe actual product development within the project. SCM provides the tools that open up theprocess to external monitoring. With SCM in place and a policy of traceability and visibilityaccepted, monitoring of software development projects becomes a simple part of the overallproject management task. Management makes informed decisions avoiding schedule slipsand budget excesses through the monitoring available with SCM tools and the integralworkings of the CCB.

Uncontrolled Change Software is very malleable; it is idea-stuff, and customers constantly have new ideas for it.People would rarely ask a bridge constructor to make the kinds of changes midproject thatsoftware customers tend to request. The impact of such changes can be just as great. All SCMtools, along with the CCB, support a mechanism for appropriate change control.

Figure 31–6 shows the relationship of SCM to another integral task, verification and vali-dation (V&V).

SCM is most important, and most often neglected, during V&V activities, which includesoftware testing. It is employed in tracking which module versions are included in a particularsystem build, as well as which tests have been run. The results of the tests are tied directly tothe modules or subcomponents being tested. Many times there are “action items” resultingfrom the tests. SCM tracks the action item status, so overall system status can be assessedwell before final builds and releases are done.

Verification and validation testing are supported through the four basic SCM processes:identification, control, auditing, and status accounting. Let’s look at examples of V&V testingin the context of each of these components.

SCM Identification Benefits to V&V

• Automatic preparation of release notes

• List of changed software modules

• Definition of development baseline

• Generation of incident reports

• Definition of operational baseline

• Control of the configuration item identification


Some Problems with Software 1233

ConceptExploration

SystemExploration

Requirements

Design

Implementation

Installation

Maintenance

Operationsand Support

Retirement

• Statement of Need

• System Interface Specification

• Software Requirements Specification

• Software Design Description

• Software Validation/ Verification Plan

• Software Validation/ Verification Report

• User Documentation

• Maintenance Documentation

Develop Configuration Identification Scheme

Perform Configuration Control

Execute Verification and Validation Tasks

Collect and Analyze Metric Data

Plan Configuration Management SoftwareConfigurationManagement

Perform Status Accounting

Plan Verification and Validation

Develop Test Specification

Execute the Tests

• Evaluation Reports

Verification and Validation

• Status Reports

• Software Verification and Validation Plan

• Change Status

• Test Summary Report

• Analysis Reports

• Test Plans

• Test Specification

• Tested Software

• Software Configuration Management Plan

• Configuration Identification Scheme

Plan Testing

• Archive Report

FIGURE 31–6SCM Interacts with Verification and Validation



• Management of CCB meetings

• Prioritization of test and incident issues

• Establishment of turnover dates

• Approval of audit and test reports

• Approval of incident report resolutions

SCM Auditing Benefits to V&V

• Comparison of new baseline to previous baseline

• Assurance that standards have been met

• Audit trail of the testing process (verification, validation, and acceptance) of the softwaresystem

• Documentation of experience with technical aspects of system engineering or softwareengineering

SCM Status Accounting Benefits to V&V

• Logging and tracking of incident reports

• Publication of CCB minutes

With all of these potential benefits of SCM, project managers must address real-world consid-erations. Management commitment is the real key to implementing SCM on a specific projectin a given organization. By treating the implementation of SCM as a project, the project planmust start at the top to secure commitment to checks and balances. Now is the time to bringout the organization’s list of project disasters to draw on management experience with theirprevious software project difficulties. If there are no historic disasters in the organization, orif it is inappropriate to discuss them, refer to literature articles that provide accounts of projectdisasters (refer to the Web resources at the end of this chapter). Finally, after putting a notionalreturn-on-investment financial argument in place, explain the intangible benefits of SCM.

One of the major sources intangible benefits is auditing. Auditing can be a heavy consumerof configuration management resources, and management may question the benefit of thiskind of expenditure. Auditing pays for itself through the avoidance of larger, unnecessaryexpenses. Savings of 100:1 (large projects) or 4–6:1 (small projects) are obtained by findingand fixing problems early in the life cycle. The auditing process in SCM uncovers the areaswhere a little more effort or control will result in higher-quality software products and loweroverall project costs.

There can be audit compromises to reduce costs. As a project manager, plan audits basedon both the phases of the life cycle and the frequency of builds, versions, releases, and productfamilies. Auditing each baseline in a project while reducing the depth of each audit maintainssome traceability with loss of visibility.


Summary 1235

Eliminating one or more audits (installation baseline, for example) maintains visibility butslightly impacts traceability.

Summary _________________________________________

As shown in Figure 31–3, SCM is a pyramid consisting of six layers and three faces. The sixlayers of the pyramid shown on the front face are:

1. Understanding of SCM—Without a total understanding, a partial implementation ofSCM with work-arounds and back doors will result in disaster for an SCM system.

2. SCM plans and policies—The policy for the organization lays out in a clear, concisefashion the expectations that the organizational leadership has for its system.

3. SCM processes—The specific processes of SCM are documented for all users to recognize. 4. Metrics—These measures show where the organization is along the path to reaping the

benefits of SCM. 5. Tools for SCM—It makes little sense to pick the tools to use in SCM without having

completed all the previous layers. 6. 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 doneto implement SCM in your organization.

The second face of the SCM pyramid is the training plan and its execution while the third isthe transition plan to get to an effective SCM implementation. By following this as the processmap to SCM, an organization can meet the software configuration management KPA for anSEI CMM Level 2 organization.

In Chapter 30 we discussed the Software Engineering Institute (SEI) Capability MaturityModel (CMM) levels of maturity. At Level 2, an organization moves beyond just getting thejob 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 andmilestones. This level is described as the repeatable level, built upon key process areas ofrequirements management, software project planning, software project tracking and over-sight, software subcontract management, software quality assurance, and software configura-tion 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 thedevelopment process?

SCM is a key building block of an organization’s development process. Without it, no organi-zation can achieve the quality levels needed for basic customer satisfaction.

Problems for Review _______________________________

Take the outline for a software configuration management plan, adapted from the IEEE Stan-dard for Software Configuration Management Plans (Std. 828-1990). Tailor this to yourneeds, removing explanatory comments as you go along. Where you decide to omit a sec-tion, you might keep the header but insert a comment saying why you omit the data.

1. What are five barriers to SCM in your work organizations?

2. What are three barriers to SCM in your project’s environment?

3. Looking back on projects you have completed or are currently working on, how couldSCM have enhanced them? If SCM was used, did it perform to everyone’s satisfaction?If not, why?

4. Describe how you would perform SCM on a moderately sized Java implementationusing a code development environment in which you had 50 classes and 200 methods.

5. Define the membership of a CCB for your entire organization. Define your product lineand your current project.

6. Define 10 characteristics for CIs in your products.

7. Define the process in your organization for selecting an automated tool for SCM. Whatare the top five benefits to your organization from an automated SCM tool?

8. What SCM is different for developing a Web-based, browser-delivered softwareapplication?

9. Where does SCM fit in your product development life cycle? Provide a graphic repre-sentation of your life cycle, and identify the processes served by SCM.

Visit the Case Study ________________________________

The Chinese Railway Ministry central software development group is an all-Microsoft shop.They develop software for DOS, Windows 3.1, Windows NT, and Windows CE. For develop-ment, they use the integrated visual development environment with Visual Source Safe (VSS)


References 1237

as the configuration management tool. Their VSS repository reached 5.5 GB in size with therevision branch of one of their train maintenance scheduling programs. At this size,Microsoft advises splitting the repository into two or more pieces. You will no longer be ableto rely on the centralized VSS to handle your prototype development needs. As a matter offact, Mr. Lu has intimated that the ministry may move off of VSS completely.

Mr. Lu requests that the ministry review your configuration management plan for notonly the prototype, but for the entire system that you propose. Based on the current condi-tions at the ministry, you may not use the VSS. You must recommend a solution that will addno software licensing cost to your project and will be usable in a Microsoft development envi-ronment. Because your marketing team has already touted the extensive configuration man-agement plan that you produce for each project, Mr. Lu feels that giving you, the projectmanager, a week to update the plan and recommend a configuration management tool is morethan reasonable.

Citations _________________________________________

1Pressman, Roger S. (2001). Software Engineering: A Practitioner’s Approach, 5th ed. New York, NY:McGraw-Hill. p. 225.

2Babich, Wayne A. (1986). Software Configuration Management: Coordination for Team Productivity.Reading, MA: Addison-Wesley. p. vi.

References ________________________________________

Ayer, S.J., and F.S. Patrinostro (1992). Software Configuration Management: Identification, Accounting,Control, and Management. New York, NY: McGraw-Hill.

Berlack, R.H. (1992). Software Configuration Management. New York, NY: John Wiley and Sons.

Bersoff, E., V. Henderson, and S. Siegel (1980). Software Configuration Management. Prentice Hall.

Buckley, F. (1993). Configuration Management: Hardware, Software, and Firmware. IEEE Computer SocietyPress.

DoD (1985). DoD-STD-2167A, “Military Standard for Defense System Software Development.”Department of Defense.

DoD (1986). DI-MCCR-80030A, “Data Item Description for the Software Development Plan.”Department of Defense.

DoD (1986). MIL-STD-480, “Engineering Changes, Deviations and Waivers.” Department ofDefense.

DoD (1986). MIL-STD-483A, “Configuration Management Practices for Systems, Equipment, Muni-tions, and Computer Programs.” Department of Defense.



DoD (1989). MIL-STD-973, “Military Standard for Configuration Management.” Department ofDefense.

IEEE Std 828-1990, “IEEE Standard for Software Configuration Management Plans.” AmericanNational Standards Institute, 1990.

IEEE Std 1042-1987, “IEEE Guide to Software Configuration Management.” American NationalStandards Institute, 1987.

NASA D-GL-11, “Software Configuration Management for Project Managers.” National Aeronau-tics and Space Administration, Version 0.2, March 1987.

NASA Sfw DID 04, “Software Configuration Management Plan Data Item Description.” NationalAeronautics and Space Administration, Version 3.0, October 15, 1986.

Pressman, Roger S. (2001). Software Engineering: A Practitioner’s Approach, 5th ed. New York, NY:McGraw-Hill.

Whitgift, D. (1991). Software Configuration Management: Methods and Tools. England: John Wiley and Sons.

Web Pages for Further Information __________________

sourceforge.net/. SourceForge is a free service to Open Source developers offering easy access to thebest in CVS, mailing lists, bug tracking, message boards/forums, task management, site hosting,permanent file archival, full backups, and total Web-based administration.

www.cmtoday.com/yp/configuration_management.html. Welcome to the ‘‘Yellow Pages’’ for configurationmanagement. This page references as many Web pages related to configuration managementaround the world as possible.

www.dtkhh.de/tsr.htm. European Software and Systems Initiative (ESSI) Process Improvement Exper-iment (PIE). Improvement of process architecture through configuration and change management,and enhanced test strategies for a knowledge-based test path generator.

www.iac.honeywell.com/Pub/Tech/CM/index.html. Honeywell Inc. IAC manages and updates the fre-quently asked questions lists for the newsgroup comp.software.config-mgmt. The information con-tained in these summaries is a consolidation of data obtained from user comments, vendormaterials, and a variety of sources around the Internet. It does not represent an official position oropinion of Honeywell, Inc.

www.mks.com/products/scm/si/2134.htm. “Configuration Management and ISO 9001,” by Robert Bamfordand William J. Deibler II, Software Systems Quality Consulting.

www.sei.cmu.edu/legacy/scm/. The intent of this area is to share the configuration managementresearch done by the SEI between 1988 and 1994 and to provide pointers to other useful sources ofinformation on software configuration management.

www.sei.cmu.edu/legacy/scm/abstracts/abscm_past_pres_future_TR08_92.html. Automated support forconfiguration management is one aspect of software engineering environments that has progressedover the last 20 years. The progress is seen by the burgeoning interest in CM, many technical papersand conferences involving CM, a large number of CM tool vendors, and new software development


Web Pages for Further Information 1239

environments that incorporate CM capabilities. This paper is about future issues affecting solutionsto CM problems.

www.sei.cmu.edu/legacy/scm/papers/CM_Plans/CMPlans.MasterToC.html. The purpose of this documentis to give an understanding of the importance of the role of the configuration management plan, togive the results from a set of informal discussions that shows how such plans are used, and to providean evaluation of three standards.

www.sei.cmu.edu/legacy/scm/scmDocSummary.html. Summary of available CM related documents.



Documents

Software Configuration Managementvig.pearsoned.com/samplechapter/0130912972.pdfThis chapter will review SCM plan templates and provide you with a composite SCM plan template for use