You have been appointed a project manager for a major software products company. Your job is to manage the development of the next-generation version of its

437

C H A P T E R

22

What is it? When you build computer software, change happens. And because it happens, you need to manage it effectively. Software configuration management (SCM), also called change management, is a set of activities de- signed to manage change.

Who does it? Everyone involved in the soft- ware process is involved with change man- agement to some extent, but specialized support positions are sometimes created to manage the SCM process.

Why is it important? If you don’t control change, it controls you. And that’s never good. It’s very easy for a stream of uncontrolled changes to turn a well-run software project into chaos. As a consequence, software qual- ity suffers and delivery is delayed.

What are the steps? Because many work products are produced when software is built, each must be uniquely identified. Once this is accomplished, mechanisms for version and change control can be established.

What is the work product? A software configuration management plan defines the project strategy for change management. Changes result in updated software products that must be retested and documented, with- out breaking the project schedule or the pro- duction versions of the software products.

How do I ensure that I’ve done it right? When every work product can be accounted for, traced, controlled, tracked, and analyzed; when everyone who needs to know about a change has been informed—you’ve done it right.

Q u i c k L o o k

Software Configuration Management

baselines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 441 change control . . . . . . . . . . . . . . . . . . . . . . . .448 change management, mobility and agile . . .453 change management process . . . . . . . . . . . . 447 configuration audit . . . . . . . . . . . . . . . . . . . . .452 configuration management, elements of . . .440 configuration objects . . . . . . . . . . . . . . . . . . . 441 content management . . . . . . . . . . . . . . . . . . .455

continuous integration . . . . . . . . . . . . . . . . . .446 identification . . . . . . . . . . . . . . . . . . . . . . . . . .452 integration and publishing . . . . . . . . . . . . . . .455 repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . .453 SCM process . . . . . . . . . . . . . . . . . . . . . . . . . .448 software configuration items . . . . . . . . . . . . .438 status reporting . . . . . . . . . . . . . . . . . . . . . . . .452 version control . . . . . . . . . . . . . . . . . . . . . . . . .445

k e y c o n c e p t s

Change is inevitable when computer software is built and can lead to confusion when you and other members of a software team are working on a project. Confu­ sion arises when changes are not analyzed before they are made, recorded before they are implemented, reported to those with a need to know, or controlled in a manner that will improve quality and reduce error. Babich [Bab86] suggests an approach that will minimize confusion, improve productivity, and reduce the num­ ber of mistakes when he writes: “Configuration management is the art of identi­ fying, organizing, and controlling modifications to the software being built by a programming team. The goal is to maximize productivity by minimizing mistakes.”

438 PART THREE QUALITY AND SECURITY

Software configuration management (SCM) is an umbrella activity that is applied throughout the software process. Typical SCM work flow is shown in Figure 22.1. Because change can occur at any time, SCM activities are developed to (1) identify change, (2) control change, (3) ensure that change is being properly implemented, and (4) report changes to others who may have an interest.

It is important to make a clear distinction between software support and software configuration management. Support (Chapter 27) is a set of software engineering activities that occur after software has been delivered to the customer and put into operation. Software configuration management is a set of tracking and control activ­ ities that are initiated when a software engineering project begins and terminates only when the software is taken out of operation.

A primary goal of software engineering is to improve the ease with which changes can be accommodated and reduce the amount of effort expended when changes must be made. In this chapter, we discuss the specific activities that enable you to manage change.

22.1 so f t wa r e co n f i g u r at i o n Ma nag e M e n t

The output of the software process is information that may be divided into three broad categories: (1) computer programs (both source level and executable forms), (2) work products that describe the computer programs (targeted at various stakeholders), and (3) data or content (contained within the program or external to it). In Web design or game development, managing changes to the multimedia content items can be more demanding than managing the changes to the software or documentation. The items that comprise all information produced as part of the software process are collectively called a software configuration.

As software engineering work progresses, a hierarchy of software configuration items (SCIs)—a named element of information that can be as small as a single UML diagram or as large as the complete design document—is created. If each SCI simply led to other SCIs, little confusion would result. Unfortunately, another variable enters the process— change. Change may occur at any time, for any reason. In fact, the first law of system

Analyze Implementation

Identify Change

Control Change

Report Change

Publish/ Deploy

Figure 22.1 Software configuration management work flow

CHAPTER 22 SOFTWARE CONFIGURATION MANAGEMENT 439

engineering [Ber80] states: “No matter where you are in the system life cycle, the system will change, and the desire to change it will persist throughout the life cycle.”

What is the origin of these changes? The answer to this question is as varied as the changes themselves. However, there are four fundamental sources of change:

∙ New business or market conditions dictate changes in product requirements or business rules.

∙ New stakeholder needs demand modification of data produced by information systems, functionality delivered by products, or services delivered by a computer­based system.

∙ Reorganization or business growth or downsizing causes changes in project priorities or software engineering team structure.

∙ Budgetary or scheduling constraints cause a redefinition of the system or product.

Software configuration management is a set of activities that have been developed to manage change throughout the life cycle of computer software. SCM can be viewed as a software quality assurance activity that is applied throughout the software process. In the sections that follow, we describe major SCM tasks and important concepts that help us to manage change.

22.1.1 An SCM Scenario This section is extracted from [Dar01].1

A typical configuration management (CM) operational scenario involves several stake­ holders: a project manager who is in charge of a software group, a configuration manager who is in charge of the CM procedures and policies, the software engineers who are responsible for developing and maintaining the software product, and the customer who uses the product. In the scenario, assume that the product is a small one involving about 15,000 lines of code being developed by an agile team with four developers. (Note that other scenarios of smaller or larger teams are possible, but, in essence, there are generic issues that each of these projects face concerning CM.)

At the operational level, the scenario involves various roles and tasks. For the project manager or team leader, the goal is to ensure that the product is developed within a certain time frame. Hence, the manager monitors the progress of development and recognizes and reacts to problems. This is done by generating and analyzing reports about the status of the software system and by performing reviews on the system.

The goals of the configuration manager (who on a small team may be the project manager) are to ensure that procedures and policies for creating, changing, and testing of code are followed, as well as to make information about the project accessible. To implement techniques for maintaining control over code changes, this manager introduces mechanisms for making official requests for changes, for evaluating proposed changes with the development team, and ensuring the changes are acceptable to the product owner. Also, the manager collects statistics about components in the software system, such as information determining which components in the system are problematic.

1 Special permission to reproduce “Spectrum of Functionality in CM Systems” by Susan Dart [Dar01], © 2001 by Carnegie Mellon University is granted by the Software Engineering Institute.

440 PART THREE QUALITY AND SECURITY

For the software engineers, the goal is to work effectively. There must be a mech­ anism to ensure that simultaneous changes to the same component are properly tracked, managed, and executed. This means engineers do not unnecessarily interfere with each other in the creation and testing of code and in the production of support­ ing work products. But, at the same time, they try to communicate and coordinate efficiently. Specifically, engineers use tools that help build a consistent software prod­ uct. They communicate and coordinate by notifying one another about tasks required and tasks completed. Changes are propagated across each other’s work by merging files. Mechanisms exist to ensure that, for components that undergo simultaneous changes, there is some way of resolving conflicts and merging changes. A history is kept of the evolution of all components of the system along with a log with reasons for changes and a record of what actually changed. The engineers have their own workspace for creating, changing, testing, and integrating code. At a certain point, the code is made into a baseline from which further development continues and from which variants for other target machines are made.

The customer uses the product. Because the product is under CM control, the customer follows formal procedures for requesting changes and for indicating bugs in the product.

Ideally, a CM system used in this scenario should support all these roles and tasks; that is, the roles determine the functionality required of a CM system. The project manager sees CM as an auditing mechanism; the configuration manager sees it as a controlling, tracking, and policy­making mechanism; the software engineer sees it as a changing, building, and access control mechanism; and the customer sees it as a quality assurance mechanism.

22.1.2 Elements of a Configuration Management System In her comprehensive white paper on software configuration management, Susan Dart [Dar01] identifies four important elements that should exist when a configuration management system is developed:

∙ Component elements. A set of tools coupled within a file management sys­ tem (e.g., a database) that enables access to and management of each software configuration item.

∙ Process elements. A collection of procedures and tasks that define an effec­ tive approach to change management (and related activities) for all constituen­ cies involved in the management, engineering, and use of computer software.

∙ Construction elements. A set of tools that automate the construction of soft­ ware by ensuring that the proper set of validated components (i.e., the correct version) have been assembled.

∙ Human elements. A set of tools and process features (encompassing other CM elements) used by the software team to implement effective SCM.

These elements (to be discussed in more detail in later sections) are not mutually exclusive. For example, component elements work in conjunction with construction elements as the software process evolves. Process elements guide many human activities that are related to SCM and might therefore be considered human elements as well.

CHAPTER 22 SOFTWARE CONFIGURATION MANAGEMENT 441

22.1.3 Baselines Change is a fact of life in software development. Customers want to modify require­ ments. Developers want to modify the technical approach. Managers want to modify the project strategy. Why all this modification? The answer is really quite simple. As time passes, all constituencies know more (about what they need, which approach would be best, and how to get it done and still make money). Most software changes are justified, so there’s no point in complaining about them. Rather, be certain that you have mechanisms in place to handle them.

A baseline is a software configuration management concept that helps you to con­ trol change without seriously impeding justifiable change. The IEEE [IEE17] defines a baseline as:

A specification or product that has been formally reviewed and agreed upon, that there­ after serves as the basis for further development, and that can be changed only through formal change control procedures.

Before a software configuration item becomes a baseline, change may be made quickly and informally. However, once a baseline is established, changes can be made, but a specific, formal procedure must be applied to evaluate and verify each change.

In the context of software engineering, a baseline is a milestone in the development of software. A baseline is marked by the delivery of one or more software configura­ tion items that have been approved as a consequence of a technical review (Chapter 16). For example, the elements of a design model have been documented and reviewed. Errors are found and corrected. Once all parts of the model have been reviewed, cor­ rected, and then approved, the design model becomes a baseline. Further changes to the program architecture (documented in the design model) can be made only after each has been evaluated and approved. Although baselines can be defined at any level of detail, the most common software baselines are shown in Figure 22.2.

The progression of events that lead to a baseline is also illustrated in Figure 22.2. Software engineering tasks produce one or more SCIs. After SCIs are reviewed and approved, they are placed in a project database (also called a project library or soft- ware repository and discussed in Section 22.5). Be sure that the project database is maintained in a centralized, controlled location. When a member of a software engi­ neering team wants to make a modification to a baselined SCI, it is copied from the project database into the engineer’s private workspace. However, this extracted SCI can be modified only if SCM controls (discussed later in this chapter) are followed. The arrows in Figure 22.2 illustrate the modification path for a baselined SCI.

22.1.4 Software Configuration Items We have already defined a software configuration item as information that is created as part of the software engineering process. In the extreme, an SCI could be consid­ ered to be a single section of a large specification or one test case in a large suite of tests. More realistically, an SCI is all or part of a work product (e.g., a document, an entire suite of test cases, a named program component, a multimedia content asset, or a software tool).

In reality, SCIs are organized to form configuration objects that may be cata­ loged in the project database with a single name. A configuration object has a

442 PART THREE QUALITY AND SECURITY

name, attributes, and is “connected” to other objects by relationships. Referring to Figure 22.3, the configuration objects, DesignSpecification, DataModel, Compo- nentN, SourceCode, and TestSpecification are each defined separately. However, each of the objects is related to the others as shown by the arrows. A curved arrow indicates a compositional relation. That is, DataModel and ComponentN are part of the object DesignSpecification. A double­headed straight arrow indicates an interrelationship. If a change were made to the SourceCode object, the interrela­ tionships enable you to determine what other objects (and SCIs) might be affected.2

22.1.5 Management of Dependencies and Changes We introduced the concept of traceability and the use of traceability matrices in Sec­ tion 7.2.6. The traceability matrix is one way to document dependencies among requirements, architectural decisions (Section 10.5), and defect causes (Section 17.6). These dependencies need to be considered when determining the impact of a proposed change and guiding the selection test cases that should be used for regression testing (Section 20.3). de Sousa and Redmiles write that viewing dependency management as impact management3 helps developers to focus on how changes made affect their work [Sou08].

Project database

BASELINES: System Specification Software Requirements Design Specification Source Code Test Plans/Procedures/Data Operational System

Stored

SCIs

Extracted

SCIs

Approved

SCIs

Modified

SCIs

SCIs Software

engineering tasks

Technical reviews

SCM controls

Figure 22.2 Baselined SCIs and the project database

2 These relationships are defined within the database. The structure of the database (reposi­ tory) is discussed in greater detail in Section 22.2.

3 Impact management is discussed further in Section 22.5.2.

CHAPTER 22 SOFTWARE CONFIGURATION MANAGEMENT 443

DesignSpecifications

data design architectural design module design interface design

TestSpecifications

test plan test procedure test cases

ComponentN

interface description algorithm description PDL

SourceCode

DataModel

Figure 22.3 Configuration objects

Impact analysis focuses on organizational behavior as well as individual actions. Impact management involves two complementary aspects: (1) ensuring that software developers employ strategies to minimize the impact of their colleagues’ actions on their own work, and (2) encouraging software developers to use practices that min­ imize the impact of their own work on that of their colleagues. It is important to note that when a developer tries to minimize the impact of her work on others, she is also reducing the work others need to do to minimize the impact of her work on theirs [Sou08].

It is important to maintain software work products to ensure that developers are aware of the dependencies among the SCIs. Developers must establish discipline when checking items in and out of the SCM repository and when making approved changes, as discussed in Section 22.2.

22.2 th e scM re p o s i to ry

The SCM repository is the set of mechanisms and data structures that allow a software team to manage change in an effective manner. It provides the obvious functions of a modern database management system by ensuring data integrity, sharing, and inte­ gration. In addition, the SCM repository provides a hub for the integration of software tools, is central to the flow of the software process, and can enforce uniform structure and format for software engineering work products.

To achieve these capabilities, the repository is defined in terms of a meta­model. The meta-model determines how information is stored in the repository, how data

444 PART THREE QUALITY AND SECURITY

can be accessed by tools and viewed by software engineers, how well data security and integrity can be maintained, and how easily the existing model can be extended to accommodate new needs.

22.2.1 General Features and Content The features and content of the repository are best understood by looking at it from two perspectives: what is to be stored in the repository and what specific services are pro­ vided by the repository. A detailed breakdown of types of representations, documents, and other work products that are stored in the repository is presented in Figure 22.4.

A robust repository provides two different classes of services: (1) the same types of services that might be expected from any sophisticated database management sys­ tem and (2) services that are specific to the software engineering environment.

A repository that serves a software engineering team should also (1) integrate with or directly support process management functions, (2) support specific rules that gov­ ern the SCM function and the data maintained within the repository, (3) provide an interface to other software engineering tools, and (4) accommodate storage of sophis­ ticated data objects (e.g., text, graphics, video, audio).

22.2.2 SCM Features To support SCM, the repository must be capable of maintaining SCIs related to many different versions of the software. More important, it must provide the mechanisms

Documents

Business content

Model content

Construction content

V & V content

Project management

content

Use cases Analysis model

Scenario-based diagrams Flow-oriented diagrams Class-based diagrams Behavioral diagrams

Design model Architectural diagrams Interface diagrams Component-level diagrams

Technical metrics

Business rules Business functions Organization structure Information architecture

Project esstimates Project scchedule SCM requuirements

Change requests Change reports

SQA requirements Project reports/audit reports Project metrics

Project plan SCM/SQA plan System spec

ecRequirements spe tsDesign document cedureTest plan and pro ntsSupport documen

User manual

Source code Object code

ructionsSystem build instr

Test cases Test scripts Test results Quality metrics

Figure 22.4 Content of the repository

CHAPTER 22 SOFTWARE CONFIGURATION MANAGEMENT 445

for assembling these SCIs into a version­specific configuration. The repository tool set needs to provide support for the following features.

Versioning. As a project progresses, many versions (Section 22.5.2) of individual work products will be created. The repository must be able to save all these versions to enable effective management of product releases and to permit developers to go back to previous versions during testing and debugging.

The repository must be able to control a wide variety of object types, including text, graphics, bit maps, complex documents, and unique objects such as screen and report definitions, object files, test data, and results. A mature repository tracks ver­ sions of objects with arbitrary levels of granularity; for example, a single data defini­ tion or a cluster of modules can be tracked.

Dependency Tracking and Change Management. The repository manages a wide variety of relationships among the data elements stored in it. These include relation­ ships between enterprise entities and processes, among the parts of an application design, between design components and the enterprise information architecture, between design elements and deliverables, and so on. Some of these relationships are merely associations, and some are dependencies or mandatory relationships.

The ability to keep track of all these relationships is crucial to the integrity of the information stored in the repository and to the generation of deliverables based on it, and it is one of the most important contributions of the repository concept to the improvement of the software development process. For example, if a UML class diagram is modified, the repository can detect whether related classes, interface descriptions, and code components also require modification and can bring affected SCIs to the developer’s attention.

Requirements Tracing. This special function depends on link management and provides the ability to track all the design and construction components and deliver­ ables that result from a specific requirements specification (forward tracing). In addi­ tion, it provides the ability to identify which requirement generated any given work product (backward tracing).

Configuration Management. A configuration management facility keeps track of a series of configurations representing specific project milestones or production releases.

Audit Trails. An audit trail establishes additional information about when, why, and by whom changes are made. Information about the source of changes can be entered as attributes of specific objects in the repository. A repository trigger mech­ anism is helpful for prompting the developer or the tool that is being used to initi­ ate entry of audit information (such as the reason for a change) whenever a design element is modified.

22.3 Ve r s i o n co n t ro L syst e M s

Version control combines procedures and tools to manage different versions of con­ figuration objects that are created during the software process. A version control system implements or is directly integrated with four major capabilities: (1) a project

446 PART THREE QUALITY AND SECURITY

database (repository) that stores all relevant configuration objects, (2) a version man- agement capability that stores all versions of a configuration object (or enables any version to be constructed using differences from past versions), (3) a make facility that enables you to collect all relevant configuration objects and construct a specific version of the software. In addition, version control and change control systems often implement (4) an issues tracking (also called bug tracking) capability that enables the team to record and track the status of all outstanding issues associated with each configuration object.

A number of version control systems establish a change set—a collection of all changes (to some baseline configuration) that are required to create a specific version of the software. Dart [Dar91] notes that a change set “captures all changes to all files in the configuration along with the reason for changes and details of who made the changes and when.”

A number of named change sets can be identified for an application or system. This enables you to construct a version of the software by specifying the change sets (by name) that must be applied to the baseline configuration. To accomplish this, a system modeling approach is applied. The system model contains: (1) a tem- plate that includes a component hierarchy and a “build order” for the components that describes how the system must be constructed, (2) construction rules, and (3) verification rules.4

A number of different automated approaches to version control have been proposed over the years.5 The primary difference in approaches is the sophistication of the attributes that are used to construct specific versions and variants of a system and the mechanics of the process for construction.

22.4 co n t i n u o u s in t e g r at i o n

Best practices for SCM include: (1) keeping the number of code variants small, (2)  test early and often, (3) integrate early and often, and (4) tool use to automate testing, building, and code integration. Continuous integration (CI) is important to agile developers following the DevOps workflow (Section 3.5.3). CI also adds value to SCM by ensuring that each change is promptly integrated into the project source code, compiled, and tested automatically. CI offers development teams several concrete advantages [Mol12]:

Accelerated feedback. Notifying developers immediately when integration fails allows fixes to be made while the number of performed changes is small.

Increased quality. Building and integrating software whenever necessary pro­ vides confidence into the quality of the developed product.

4 It is also possible to query the system model to assess how a change in one component will impact other components.

5 Github (https://github.com/), Perforce (https://www.perforce.com/), and Apache Subversion also known as SVN (http://subversion.apache.org/) are popular version control systems.

CHAPTER 22 SOFTWARE CONFIGURATION MANAGEMENT 447

6 Puppet (https://puppet.com/), Jenkins (https://jenkins.io/), and Hudson (http://hudson­ci.org/) are examples of CI tools. Travis­CI (https://travis­ci.org/) is a CI tool designed for sync projects residing on Github.

Reduced risk. Integrating components early avo